Looking at how my career started… From a young age, computer programming has been something I have enjoyed with great interest. What we do is use logic that works precisely based on data. Making it… Especially at the system kernel level, details like how to operate for optimization… So I wasn’t very interested in data coming in from outside, nor was I used to doubting the data itself.
But… Data center? Upon entering the world… A little later, about DCIM… What is the newest thing you learned while getting to know it… How difficult it is to make the data itself accurate and stable at the desired level. “Preparing accurate data (numbers).”
Moreover. Now, at AI DC… From the perspective of expanding automation to respond to larger, high-density, and high-volatility… “Is that data (number) accurate?” “Is the explanation of that data (number) accurate?” is the most important thing above all. This is the beginning of everything.
There’s something I often say.
In the past, in “1+1=0,” we used to do +,= (calculation)… I never knew it would be so difficult for this guy to get even one ‘1’ so accurate.”
As expected, the more you know, the harder the world becomes. Sometimes I just want to do programming I liked—or maybe maybe I want to create something on my own…. That’s just a temporary thought… What I liked was about making things, and I know very well that we have to work together for that. Now, 🙂
Data & Knowledge Driven AI Agent for Data Center Operations
This illustration describes how data center operations can evolve from facility data → operational knowledge → AI Agent → automated operations.
The key message is not simply that AI controls data center equipment.
Rather, it shows how AI Agents can connect operational data with accumulated human knowledge, understand operational situations, reason about incidents, and support or automate operational actions.
1. Facilities & Systems
The process starts with the physical infrastructure and operational systems of the data center.
The illustration represents:
Power
Cooling
Network
IT / GPU
Security
Environment
Sensors and systems continuously generate operational information.
Systems such as DCIM, NMS, BMS, and log platforms collect this information.
In simple terms:
Facilities generate information, and systems collect it.
2. Data — From Information to Metrics
Facility information is transformed into measurable operational data.
For example:
Temperature → 42.3°C
Power Load → 12.6 MW
Water Flow → 3.2 m³/h
Utilization → 78%
The important point is that the AI Agent uses both:
Real-time Data + Historical Data
Real-time data tells the Agent what is happening now, while historical data provides the operational context and previous experience.
3. Event — Turning Numbers into Meaning
Raw numbers are not always meaningful to operators.
Therefore, data is transformed into understandable events.
For example:
GPU Inlet Temperature is high (42.3°C)
Now the numerical value has become a meaningful operational event.
The event also contains context such as:
What happened + Where + When + Severity + Impact
This is important because the AI Agent does not need to operate only on raw numbers. It can reason about meaningful operational situations.
4. Response — Operational Knowledge
When an event occurs, traditional operations rely on manuals and experienced operators.
The illustration represents this knowledge through:
Runbook
MOP
EOP
SOP
Best Practices
A typical response process can be:
Check → Analyze → Execute → Verify
This represents the transformation of human experience into reusable operational knowledge.
Human Experience → Documentation → Operational Knowledge
This knowledge becomes one of the most important assets for the AI Agent.
5. Final Decision — Judgment & Action
The final stage goes beyond detecting an event.
The operational process becomes:
Root Cause → Action Plan → Service Restore → Record
Traditionally, experienced operators perform much of this reasoning manually.
With an AI Agent, operational data and knowledge can be combined to support:
Root-cause analysis
Action recommendations
Runbook execution
Operator guidance
Controlled automation
In a real data center, however, autonomous action should be governed by policies, safety controls, and human approval where required.
The Center of the Illustration — AI Agent
The AI Agent sits at the center because it connects Data and Knowledge.
Data
Operational Data
Facility & Asset Data
Event & Incident Data
Historical Cases
Asset / Relationship Data
Knowledge
Manuals
Runbooks
SOP / MOP / EOP
Domain Knowledge
Best Practices
Past Cases & Lessons
The Agent combines these two layers to perform:
Learn → Reason → Act
A simple way to express the concept is:
Data tells the Agent what is happening. Knowledge tells the Agent what it means and what to do.
The Core Message
The most important point of the illustration is that the AI Agent itself is not the foundation.
The real foundation is:
Data → Knowledge → AI Agent → Operations
Without accurate data, the Agent cannot reliably understand the current state.
Without structured operational knowledge, the Agent cannot reliably determine what the situation means or what response is appropriate.
Therefore, the real objective of AI-enabled data center operations is not simply:
“Deploy AI.”
It is:
“Make operational data and knowledge usable by AI.”
The Transformation of Data Center Operations
The bottom of the illustration shows:
Data-Driven → Knowledge-Centric → AI-Powered
This represents the evolution of operational models.
Traditional Operations
Human → Data → Manual Analysis → Manual Action
AI Agent-Based Operations
Data + Knowledge → AI Agent → Reasoning → Recommended / Controlled Action
The role of people does not disappear.
Instead, it changes.
AI handles repetitive monitoring, analysis, and operational assistance, while people focus more on judgment, decision-making, exception handling, and continuous improvement.
This is why the final concept is:
People + AI
rather than simply AI replaces People.
One-Sentence Summary
By connecting data generated from data center facilities with operational knowledge, an AI Agent can understand, reason, and support or automate operational actions—transforming human-centered operations into data- and knowledge-driven intelligent operations.
Response Speed: Ranges from microseconds to 1 second, offering the most immediate reaction.
Independence: Highest (Enables standalone operation even if communication drops entirely).
Failure Impact: Results in an immediate shutdown of the specific equipment.
Responsible Scope: Handled by the equipment manufacturer.
PLC / DDC
Response Speed: Milliseconds to several seconds.
Independence: High (Base operations continue even if the upper layer stops).
Failure Impact: Can cause power outages or temperature increases.
Responsible Scope: Handled by electrical and mechanical contractors.
BAS / EPMS
Response Speed: Takes 1 to 30 seconds.
Independence: Medium (Field-level control survives even if the upper system stops).
Failure Impact: Causes “blindness” (loss of monitoring visibility), though physical operation continues.
Responsible Scope: Managed by automation system integrators (SIs).
DCIM
Response Speed: Operates on a time scale of minutes.
Independence: Low (The facility can continue operating even without it).
Failure Impact: Leads to management inefficiencies such as increased electricity costs rather than immediate outages.
Responsible Scope: Handled by IT solution companies.
Core Message
The note at the bottom highlights a critical paradigm shift: rather than debating whether to choose PLC or DDC based on theory, engineering teams must focus on empirically verifying worst-case latency through actual measurements.
Summary
Automation control architectures are strictly layered by response speed and independence, requiring engineers to prioritize measured worst-case latency verification over conventional component selection debates.
The image is a structured chart titled “Data Center Protocols (2, Application Layer)”. It categorizes various communication protocols used within a data center into three main operational paradigms based on their purpose and characteristics. The chart outlines the protocol name, communication method, data format/security, and typical use cases for each category.
Key Categories and Descriptions
1. Device-Centric This section covers traditional, hardware-specific protocols used for direct communication with physical infrastructure equipment. The primary communication paradigm here is ‘Polling’ (master/slave or with events).
Modbus RTU/TCP: Used for UPS, PDU, and power meters. It uses raw registers with no typing and lacks built-in security.
BACnet IP-MS-TP-SC: An object-oriented protocol used for Chillers, CRAH, cooling towers, and BMS (Building Management Systems).
SNMP v2c/v3: Utilized for Smart PDUs, environmental sensors, and network gear, relying on a MIB (OID tree) structure.
Redfish (replaces IPMI): Designed for Server BMC, power, and thermal management using REST polling and JSON schemas.
DNP3 / IEC 61850: Used for switchgear, HV substations, and gensets, featuring time-stamped event reporting.
2. Data-Centric This area focuses on protocols designed to collect, route, and distribute large volumes of sensor and telemetry data. These protocols primarily utilize the ‘Publish/Subscribe (Pub/Sub)’ mechanism.
MQTT (+Sparkplug B): Ideal for high-volume telemetry and monitoring liquid-cooling flow & temperature, featuring free payloads (with models added by Sparkplug).
OPC UA: Used for heterogeneous normalization and gateway-to-DCIM communication, offering a semantic info model and built-in security.
Kafka (optional): Acts as a central ingestion bus for stream logs, providing partitioning, retention, and SASL-TLS security.
3. Integration-Centric This tier deals with protocols meant for linking high-level application systems, web services, and user interfaces.
REST API (JSON): The standard request/response method used for DCIM integration and generating tenant power reports over HTTPs.
gRPC: Based on HTTP/2 and Protobuf, it enforces schemas and is used for internal Microservices Architecture (MSA), AI, and RAG pipelines.
WebSocket / Webhook: Provides persistent duplex communication and event callbacks, perfect for live dashboards and real-time fault alerting.
💡 Summary
The chart illustrates that modern data center communication is strategically divided into three architectural layers: hardware control (Device-Centric), massive data ingestion and routing (Data-Centric), and high-level system connectivity (Integration-Centric). Each layer employs specifically optimized protocols to meet its distinct requirements for speed, payload structure, and security.The chart illustrates that modern data center communication is strategically divided into three architectural layers: hardware control (Device-Centric), massive data ingestion and routing (Data-Centric), and high-level system connectivity (Integration-Centric). Each layer employs specifically optimized protocols to meet its distinct requirements for speed, payload structure, and security.
This image is a detailed table titled “Data Center Protocols (1, Physical Layer)”. It breaks down the hardware communication methods used in data center facilities into four main categories: Contact & Analog, Serial, Ethernet, and Wireless, detailing their technical specifications, limitations, and primary use cases.
Contact & Analog:
Analog DI/DO (Dry Contact): Uses voltage-free open/close signals for basic alerts like rack door sensors, leak detection, and UPS alarms. It notes that “1 point = 1 signal,” making the wiring heavy and complex.
AI/AO: Uses 0–10V or 4–20mA continuous signals, typically for legacy temperature, humidity, and pressure sensors, but is vulnerable to noise and distance attenuation.
Serial:
RS-485: A 2-wire half-duplex system supporting multi-drop topology (up to ~32 nodes). It is the standard for CRAC/CRAH units, PDUs, and power meters.
RS-422 & RS-232: RS-422 is used for legacy instrumentation, while RS-232 is strictly for point-to-point local console debugging over very short distances (~15m).
Ethernet:
UTP (RJ-45) / Fiber: Offers high bandwidth and shares existing IT infrastructure, requiring OT/IT network segmentation. It is the go-to for modern Smart PDUs, UPS systems, chillers, and BMS. A prominent blue arrow on the right highlights a major industry shift, indicating that “Ethernet support is expanding” from traditional serial devices.
Wireless:
LoRaWAN / Zigbee: Ideal for retrofit mass sensor rollouts in existing facilities without adding new cables, though they are constrained by bandwidth and collection interval limits.
Summary
This reference chart provides a comprehensive overview of the physical data collection mediums essential for Data Center Infrastructure Management (DCIM). It effectively contrasts the limitations and specific use cases of legacy analog and serial connections with modern networking solutions. Crucially, it highlights the ongoing industry trend of migrating traditional facility equipment toward high-bandwidth, Ethernet-based communication.This reference chart provides a comprehensive overview of the physical data collection mediums essential for Data Center Infrastructure Management (DCIM). It effectively contrasts the limitations and specific use cases of legacy analog and serial connections with modern networking solutions. Crucially, it highlights the ongoing industry trend of migrating traditional facility equipment toward high-bandwidth, Ethernet-based communication.
This architecture outlines the closed-loop logic flow of the Linux kernel’s powercap framework. It details how the kernel enforces strict energy limits on hardware to manage heavy AI workloads while coordinating with the datacenter’s external power grid and infrastructure.
Stage 1: Workload Surge & Power Grid ConstraintsWhen high-intensity AI or HPC workloads are dispatched, the hardware immediately attempts to draw maximum electrical current. Concurrently, external factors—such as peak-hour electricity pricing, facility power limits, or a Datacenter Infrastructure Management (DCIM) directive—may impose strict power constraints on the server rack.
Stage 2: Polling & Energy SensingTo monitor power draw, the kernel’s powercap framework utilizes hardware interfaces like Intel RAPL (Running Average Power Limit) or AMD Node Manager. It continuously polls and calculates real-time energy consumption, tracking the exact wattage and joules consumed across specific hardware domains (CPU, memory, GPU) over defined time windows.
Stage 3: Power Limit (Cap) ActivationIf the real-time power consumption hits predefined hardware thresholds (such as PL1 or PL2 limits), or if an external DCIM system injects a strict upper power limit via the /sys/class/powercap/ interface, the kernel’s power capping governor is instantly triggered into action.
Stage 4: Dynamic Hardware Throttling (Local Mitigation)To enforce the mandatory power budget, the kernel immediately intervenes at the hardware level. It aggressively utilizes DVFS (Dynamic Voltage and Frequency Scaling) to force the processors into lower P-states, dropping clock frequencies and voltages within milliseconds to physically restrict the electrical current draw.
Stage 5: Infrastructure Telemetry Sync (Global Mitigation)As the kernel throttles the hardware, it continuously exports real-time power telemetry back to the datacenter’s control plane via IPMI/Redfish agents. The rack’s Power Distribution Unit (PDU) or DCIM system uses this data to verify compliance with the power cap, allowing the facility to dynamically reallocate power budgets across different server racks.
Stage 6: Power Equilibrium / Performance Degradation
Normal Outcome: The system successfully stabilizes at or below the enforced power cap, achieving Power Equilibrium. The workload continues to execute stably, though at a dynamically calculated, power-efficient pace.
Emergency/Degraded Outcome: If the datacenter imposes an extreme power cap (e.g., during a facility power emergency), the kernel will relentlessly throttle the hardware. This causes severe Performance Degradation for the workload, but it successfully prevents catastrophic outcomes like tripping the datacenter’s power breakers.
Summary
The Linux kernel uses frameworks like RAPL to continuously monitor and calculate the exact energy consumption of server components during heavy workloads.
When hardware limits are reached or external datacenter power caps are applied, the kernel instantly throttles CPU/GPU frequencies and voltages to restrict electrical draw.
This system ensures the server stays strictly within its assigned power budget, sacrificing raw performance if necessary to protect the datacenter’s physical power grid from failing.
