Article

Data Center Floor Space Management: Transforming Rack Elevations into Data



Implementation Methods for Floor Space Management Solution Polestar DOMS



When a failure alarm sounds, operators first check the equipment name, and then look for where that equipment is located. However, in many data centers, the answer to this second question still lies within Excel rack elevation diagrams separated by center and floor. The problem is that these elevation diagrams do not accurately reflect the real-world site. As equipment expansions, relocations, and removals are repeated, document updates get pushed back, and the elevation diagrams in Excel and the actual equipment placement in the racks begin to diverge gradually.

IT operations systems each know their assigned information well. ITAM/CMDB knows equipment ownership, contracts, and configuration; EMS (SMS/NMS) knows status and performance; and FMS knows facility status such as power and HVAC.[1] However, in many cases, no single system takes definitive responsibility for which rack and which U a specific piece of equipment is located in. Filling this gap is precisely what data center floor space management does. On site, it is also referred to as a Rack Management System.

In this article, we will technically examine why floor space management is necessary for data centers and how Enkia's floor space management solution, Polestar DOMS, constructs floor space data through two methods: Excel upload and system integration.

Moving from the stage of viewing an equipment list,
to the stage of viewing where the equipment is placed.




Without location information, operations return to on-site visits


When location is not managed as data, humans must fill in on-site what the system cannot provide. In actual operations, the following scenarios recur:


Incident Response

To locate faulty equipment, on-site personnel check labels one by one in front of racks. What can be known remotely ends at the equipment name, and there is no search mechanism to locate the position using that name.


Installation Planning

Whenever new equipment arrives, personnel manually calculate available U space, power headroom, and rack load capacities separately. Situations even arise where two teams simultaneously schedule installation plans for the exact same U in the same rack.


Asset Auditing

For every physical audit, the task of cross-referencing Excel sheets with the physical site starts from scratch. The results of the previous audit cannot serve as a baseline for the next audit.


Data center design standards also define space hierarchically. ANSI/TIA-942 divides computer rooms into zones and rack rows, and rack height is expressed in units of 1U (1.75 inches, 44.45 mm) as defined by EIA-310.[2][3] Floor space management is the act of mapping this physical structure directly into a data model. In the domain of Data Center Infrastructure Management (DCIM), floor space and rack management is the most fundamental pillar alongside power and cooling management.




Floor space data connects through a hierarchy


Floor space data follows a hierarchical structure: Center → Floor → Zone → Rack → U → Asset. The preceding tiers that make up the location are modeled directly by the floor space management system based on floor plans, while the asset attributes and status at the very end are retrieved from existing systems.

Figure 1. Rack locations are populated by DOMS, assets and alarms by ITAM/EMS, and facility status by FMS.


The rack is the point where location and asset converge. A single 42U rack is expressed as a set of U-unit intervals, and equipment occupies part of that interval with a start U and height (U). Once this structure is in place, rack utilization, empty space, and installable locations can be calculated. The fact that the owner of the data differs for each tier serves as the starting point for determining the implementation methods discussed later.


Operational Question

Manual Management (Excel/Drawings)

Floor Space Management System

Location of faulty equipment

Search Excel then verify on site

Highlight unified search results on 3D floor plan

Installation space for new equipment

Manually calculate available U per rack

Display available Units on layout and reserve installation

Rack utilization / capacity

Consolidate reports at month-end

Query utilization per rack and export to Excel

Placement by client/purpose

Managed in separate sheets

Color-coded distinction via monitoring mode

Check equipment status

Navigate to EMS screen

View alarms and performance together in rack details

Table 1. Differences between manual management and a floor space management system for the same operational questions




Architecture of Floor Space Management Solution Polestar DOMS


Polestar DOMS (Datacenter Operation Management Suite) is Enkia's asset management-based integrated floor space management solution. It receives data from integrated systems, maps it to the floor space model, and presents the results through a 3D interface in a web browser.

Figure 2. DOMS architecture where the Loader collects and ingests integration data and serves it to the WebGL viewer (table names are examples).


Integrated Systems

Asset data to be placed on the floor plan is retrieved from ITAM (CMDB), EMS, or Excel files. FMS is not used for configuring floor space data; it is selectively integrated only to display the status and key metrics of facility equipment such as CRAC units, UPS, and temperature/humidity sensors. DOMS reads only the necessary data without modifying the source systems.


POLESTAR Loader

A rule-chain-based ETL. It executes periodic collection via Scheduling, and the Rule Engine transforms each system's table structure to match the DOMS model. Collection targets are defined in Data Set units, and real-time queries are processed via REST API.


Repository

Stores floor space models, asset mappings, and reservation/authorization information in PostgreSQL.


Viewer

An HTML5 and WebGL-based 3D screen. It operates in major browsers without separate plug-ins and supports switching between ISO and Top View, as well as panning, zooming, and rotating. Because the 3D scene is generated directly from data, additions of racks or equipment are reflected on screen without redrawing floor plans.




Floor Space Management Unified Search Answering "Where is it?"


This article started with the question, "Where is that equipment?" No matter how well floor space data is structured, if operators cannot reach that location quickly, they will revert to Excel and physical checks. DOMS's Unified Search is the feature that answers this question most directly.

Figure 3. Even when entering only part of an equipment name, the location is confirmed in the autocomplete list, and upon selection, the corresponding rack and U position are highlighted in the 3D floor plan.


Conditional Search

Search by multiple criteria such as rack/equipment code, name, type, and mount location. Whether it is a hostname indicated in an incident alarm or an asset number on an on-site label, operators can search immediately with the information in hand.


Autocomplete

Input-based autocomplete displays candidate lists along with the center, floor, rack, and U location of each device, even if only part of the name is known. Even if multiple devices have similar names, they can be distinguished by location.


Floor Space Highlighting

Selecting a result highlights the searched rack and equipment in the 3D floor plan to display its location, seamlessly leading to rack details to verify asset information and alarms all at once.


For searches to be accurate, the previously discussed data structure must first be established. When asset keys are unified and rack and U locations are attached to all equipment, the search results directly represent physical locations. The floor space data configuration determines search quality.

From a single equipment name to its rack and U location.
Complete on screen what used to require checking labels on site.





Floor Space Management Implementation Methods: Excel Upload vs. System Integration


The floor space model (center, floor, zone, and rack layout) is configured in DOMS based on floor plans. What differentiates the implementation methods is where the source of truth for the asset information to be placed in the racks resides. DOMS supports three paths: Excel upload, ITAM integration, and EMS integration.




Excel Upload: Ingesting Rack Elevation Diagrams As-Is


This method suits centers that lack an ITAM or EMS to integrate with and have been managing elevation diagrams via Excel. Uploaded data is managed by DOMS as the source of truth, and after deployment, racks and equipment are directly registered, modified, and deleted in Asset Information Edit Mode on screen. Asset editing is provided only in this method.

Because on-site Excel formats vary by center, columns must be aligned to a standard template prior to upload. To determine the location of racks and equipment, the following columns are required at a minimum:


Column

Example

Description

Center / Floor

DC-A / 3F

Must match the center and floor codes of the floor space model.

Rack Number

B-07

Key linking to the rack position on the floor plan.

Start U / Height

22 / 2

Creates the U interval [22, 23] occupied by the equipment.

Asset Key

SV-2026-00412

Asset number or hostname. Must not contain duplicates.

Equipment Attributes

Model, Owner, IP

Items to display on the rack detail screen.

Table 2. Minimum columns for Excel upload template


Figure 4. Example of an Excel elevation diagram being placed into racks after verification. Merged cells and notation discrepancies are corrected, while U overlaps and duplicate asset numbers are rejected.


DOMS designates the bottom-most unit of the rack as 1U and numbers upward, and this standard is fixed. Counting from the bottom up is standard practice across the industry; the telecommunications infrastructure management standard ANSI/TIA-606-B also illustrates labeling patch panel locations by rack unit numbers counted from the bottom of the rack.[4] Therefore, the uploaded Excel elevation diagrams must be authored using the bottom of the rack as 1U. If on-site documents follow a different method, they must be adjusted to this standard prior to upload.

Overlapping U intervals within the same rack can be detected by sorting equipment by start U and comparing only adjacent equipment. For a rack with n devices, the entire overlap check can be executed with a sort cost of O(n log n).

// Sort equipment in the same rack by start U, then compare only adjacent intervals

slots.sort((a, b) => a.start - b.start);

for (let i = 1; i < slots.length; i++) {

  const prev = slots[i - 1], cur = slots[i];

  if (prev.start + prev.height > cur.start) {

    reject(cur.row, `U${cur.start}: Interval overlap with ${prev.assetKey}`);

  }

}


While the Excel method has the lowest barrier to entry, because DOMS serves as the single source of truth, an operational procedure for reflecting on-site changes into DOMS must be established. Using the Excel export feature from the rack utilization view as an asset audit template makes it easy to institutionalize this procedure.




ITAM Integration: Keeping the Source of Truth in Asset Management


If an asset management system like Polestar ITAM is already in place, the source of truth for asset information remains in ITAM. The Loader periodically collects asset and configuration tables, matches them with DOMS equipment via asset keys, normalizes location attributes, and ingests the data. Equipment newly registered in ITAM is automatically added to the floor space.

Figure 5. The process of converting free-text locations in ITAM into DOMS coordinates through a rule chain. Rules are examples for conceptual understanding.


The most time-consuming task in an integration deployment is location normalization. This is because locations in ITAM often exist as free-form text, such as "Main Bldg 3F Row B No. 7 22-23U." Center, floor, and rack code conversion rules are defined in the Rule Engine, and assets that do not match the rules are separated into an unassigned list so operators can correct the source data.

Maintaining a single source of truth is also critical. In the integration method, asset editing within the DOMS UI is not provided. When locations change, they must be edited in the source system, which will reflect in the floor space during the next collection cycle. This aligns with the single source of truth principle emphasized by asset management standards.[5]




EMS Integration: Monitored Targets Become Floor Space Assets


If there is no asset management system but equipment is monitored using Polestar EMS (SMS/NMS), configuration information can be integrated by defining rack and U location columns per device via EMS's custom table feature. Because monitored targets directly become floor space assets, there is no need to maintain a separate asset list, and alarm and performance information link directly via identical equipment keys.

Even in ITAM integration scenarios, EMS is often integrated concurrently. Asset attributes are fetched from ITAM, while alarms and performance are retrieved from EMS to be displayed together on the rack detail view. FMS can also be integrated if necessary. However, FMS is not a path for populating floor space data; it serves to display status conditions and key metrics for facility equipment such as CRACs, UPS, and temperature/humidity sensors directly on the floor space.




Choosing the Right Floor Space Management Implementation Method

Category

Excel Upload

Excel → DOMS

ITAM Integration

CMDB → DOMS

EMS Integration

SMS/NMS → DOMS

Asset Source of Truth

DOMS

ITAM (CMDB)

EMS Configuration Info

Data Freshness

■□□

At upload/edit time

■■■

Synced every collection cycle

■■■

Synced every collection cycle

UI Asset Editing

Provided

Not Provided

Modify in source

Not Provided

Modify in source

New Equipment Ingestion

Manual registration

Automatic addition

Automatic reflection

Initial Setup Effort

■□□

Centered on data cleansing

■■□

Location normalization rules

■■□

Defining location columns

Suitable Environment

Centers managing elevation

diagrams via Excel

Organizations with an

asset management system

Organizations operating

primarily around EMS

Table 3. Comparison of implementation methods. A higher count of ■ indicates higher freshness or greater initial effort.




Case Studies of Floor Space Management Solution Implementation


Looking at actual deployment cases, the choice of method is mostly determined by the systems clients already operate.

Client Type

Method

Scale

Key Implementation Highlights

Financial Firm A

ITAM + EMS Integration

4 centers, 7 floors

Approx. 700 racks

Real-time integration of asset info and alarms, followed by AI center floor space expansion

IT Service Provider B

Excel Upload

8 centers, 16 floors

Approx. 900 racks

Transitioned manual elevation diagrams to dedicated floor space management, operational screen editing

Financial Firm C

ITAM Integration

2 centers, 13 floors

Approx. 1,600 racks

Replaced third-party solution, 3D/2D switching and tenant-specific monitoring

Credit Card Company D

EMS Integration

4 centers, 6 floors

Approx. 200 racks

Built automated floor space management based on EMS configuration information

Table 4. Polestar DOMS Implementation Cases (Client names undisclosed)




Checklist Prior to Implementing Floor Space Management


Drawings

Prepare 2D floor plans per floor including rack layouts, tile sizes, and positions of columns and entrances. If cold/hot aisle containment is defined, include it.[1][2]


U Standard

Author Excel elevation U numbers according to the DOMS standard (rack bottom = 1U), and decide how to represent 0U equipment such as PDUs.[3][4]


Asset Keys

Verify non-duplicate unique keys (asset number or hostname) for each device, and ensure that Excel, ITAM, and EMS reference the same equipment with the same key.


Permission Scope

Define who should have access to what at the center, floor, and menu levels.


User PCs

Requires a graphics environment supporting 3D acceleration and OpenGL 3.3 or higher. For VDI environments, conduct preliminary operation tests and use 2D View as default if necessary.




Conclusion


In a data center, floor space is the hardest resource to expand. Servers can be swapped out, but floor area, racks, and power/cooling capacities cannot be easily scaled once decided. As high-density servers and AI equipment increase, accurately knowing remaining U space and power headroom forms the basis for deciding expansion timing and investment scale.

Without floor space management, these decisions rely on Excel and physical inspections. When an incident occurs, staff wander on site because they cannot search for locations by equipment name; installation planning relies on manual calculation; and audit results cannot serve as a baseline for subsequent audits. Only when location is managed as data can incident response, installation planning, capacity management, and asset auditing connect through a unified standard.

Floor space management is not merely drawing the data center;
it is establishing the foundation to evaluate remaining space and future expansions.

Whether starting with Excel or integrating with ITAM/EMS, the starting point is identical: organize asset keys and U standards, and convert locations into data one rack and one floor at a time. Enkia's floor space management solution, Polestar DOMS, starts here.




References

[1] ASHRAE TC 9.9, Thermal Guidelines for Data Processing Environments, 5th Edition, 2021.

[2] TIA, ANSI/TIA-942-C, Telecommunications Infrastructure Standard for Data Centers, 2024.

[3] ECIA, EIA/ECA-310-E, Cabinets, Racks, Panels, and Associated Equipment.

[4] TIA, ANSI/TIA-606-B, Administration Standard for Telecommunications Infrastructure, 2012. (Labeling patch panel locations by rack units referenced to rack bottom)

[5] ISO/IEC 19770-1:2017, Information technology — IT asset management — Part 1: IT asset management systems — Requirements.







TS Lee | Enkia R&D Center, Research Team 3