1.1 The Evolution and Limits of Industrial Software
This book tells one story — from industrial software to AI agents. To understand that evolutionary path, we must first be clear about where industrial software stands, what it can do, and what it cannot.
1.1.1 The Landscape: The ISA-95 Pyramid
Industry has long organized its software systems around the ISA-95 (IEC 62264) standard. The standard divides a manufacturing enterprise's information systems into five levels, forming a pyramid from the bottom up:
- Level 0 (physical process): sensors, actuators, motors, valves — they run no software; they only generate and receive signals.
- Level 1 (basic control): the runtime logic of PLCs (Programmable Logic Controllers) and DCSs (Distributed Control Systems). A PLC executes ladder-logic or structured-text programs on a fixed scan cycle and reacts extremely fast to deterministic rules like "shut down if temperature exceeds 85 °C" — but the program itself cannot learn. An engineer writes it once, and it runs forever unless someone reprograms it.
- Level 2 (supervision): SCADA (Supervisory Control and Data Acquisition) and HMI (Human-Machine Interface). They perform acquisition, monitoring, alarming, historical recording, and some degree of supervisory control; their exact capabilities vary widely by product and project. The shared boundary of traditional deployments is not that they "only display data," but that device semantics, cross-system context, and advanced analytics generally require additional integration.
- Level 3 (manufacturing operations management): MES (Manufacturing Execution System). The MES manages production scheduling, work-order dispatch, quality traceability, and material tracking. Modern MESs can process near-real-time events; the real difficulty is that field, operations, and enterprise systems use different data models and time scales, so cross-level problems often require interfaces, master data, and event contracts to be solved together.
- Level 4 (business planning): ERP (Enterprise Resource Planning). Purchasing, finance, and sales — two or three levels away from the shop floor, with information measured in days or even weeks.
This architecture took its definitive shape in the 1990s and has governed the industrial software landscape for the three decades since. The core problem it solved was bringing the physical production process into management information systems — letting managers see what happens in the factory. But its design assumption is that data is viewed by people, decisions are made by people, and commands are issued by people.
Figure 1-1 shows the complete ISA-95 pyramid — five levels bottom-up, with each level's key systems and time scales visible at a glance.
1.1.2 What Industrial Software Does Well — and Why It Cannot Be Replaced
To judge what the next-generation platform should add — and what it must not touch — we need to be clear about what industrial software already does well enough.
Deterministic, real-time control is the bedrock of industrial software. A PLC's scan cycle is typically on the order of milliseconds, and its program logic is binary — a condition is true, so it executes; false, so it skips. There is no ambiguous "probabilistic output." The safety interlock of a stamping press, the emergency venting of a reactor, the e-stop of a conveyor — their essential requirement is to "execute a defined action, deterministically, within a defined time window." This layer is guaranteed by the IEC 61131-3 programming languages and hardware redundancy; no intelligence layered on top should ever replace it.
Structured data modeling already has mature paradigms. The OPC UA (OPC Unified Architecture) information model, the ISA-88 batch-control standard, the IEC 61850 power-automation model — these standards let devices from different vendors understand each other at the semantic level. They give Internet of Things (IoT) platforms an engineering foundation for thing models, rather than making platforms start from zero.
The industrial-grade reliability and safety certification system is comprehensive. SIL (Safety Integrity Level) certification, the ATEX explosion-proof directive, the functional-safety standard IEC 61508 — these are not feature checklists; they are legal market-entry thresholds for industrial equipment. Any new technology claiming to "transform industry" must prove itself inside these constraint frameworks.
Figure 1-2 places these three capabilities side by side — together they mark the boundary of what cannot be replaced.
1.1.3 The Structural Limits of Industrial Software
In the 21st century, this five-level pyramid has exposed three architectural contradictions that no version upgrade can resolve.
The first crack: inconsistent data models and responsibility boundaries. A production line's vibration data may reside in SCADA, its maintenance records in MES or CMMS, and its spare-part costs in ERP. ISA-95 provides levels and object models for integrating enterprise and control systems, but it neither prohibits cross-level exchange nor requires all data to pass only through adjacent levels. Fragmentation in practice comes from product boundaries, legacy interfaces, master data, and inconsistent organizational responsibilities; what an IoT platform must solve is governed cross-domain integration, not "breaking ISA-95."
The second crack: deterministic rules and changing operating conditions require different governance. PLC logic, SCADA alarms, and MES schedules can all be parameterized, versioned, and continuously optimized; calling all of them "hard-coded" understates modern industrial software. The real tension is that safety interlocks must remain verifiable and deterministic, whereas diagnosis, prediction, and cross-system investigation need to update hypotheses from historical data. AI can assist the latter kind of work, but its ability to "learn" is not a reason to replace the former kind of control.
The third crack: systems are closed islands, and external intelligence cannot get in safely. Industrial software runs in closed environments — private networks, private protocols, private data formats. Before an IoT platform layer standardizes access, an external AI model that wants to query device status, pull historical data, or issue a validated command needs one adapter per PLC brand, one SQL dialect per SCADA database, and one wrapper per MES API. That is not "technical integration" — it is a Tower-of-Babel semantic translation project.
Figure 1-3 marks these three cracks on the pyramid — the ones no version upgrade can fix.
1.1.4 From Industrial Software to the IoT Platform: The Force Behind the Leap
These three cracks are exactly what pushed the industry one step forward — from industrial software to the IoT platform. What an IoT platform solves is not "getting devices onto the network" — industrial sites have had Modbus and Profibus for decades. It solves three things:
- Unified data: replace per-level data formats with a unified abstraction — the thing model and the point value. The thing model declares, for each class of device, "which attributes it has and which operations it supports," while a point value is the value of a given point in a single acquisition, with its unit and timestamp (formal definitions in Section 2.3 and Section 3.7).
- Open capabilities: replace proprietary protocol adapters with standardized REST/gRPC/MQTT interfaces, so external systems — AI included — can access device data and control capabilities in one uniform way.
- Closed-loop automation: upgrade the "human reads data → human decides → human operates the device" chain into a continuous cycle of "collect → understand → decide → execute → feed back."
With this in mind, the chapters that follow — the four-layer IoT architecture (Chapter 2), multi-protocol access (Chapter 4), the data loop (Chapter 5), and finally the AI agents (Chapter 7) — all share one set of questions: what did industrial software leave behind, and what must be added?
Figure 1-4 compresses this leap into one side-by-side comparison.