CII № 01 The Substrate
The Substrate: Software-Defined Control Systems
How can AI proposals reach industrial machines? CII examines software-defined control, different execution clocks and the interfaces between AI and real-time control.
Control connects computing to physical execution
An AI application can recommend a useful action while remaining far removed from the machinery that would perform it. Industrial control systems provide that connection: they observe machine signals, execute logic and coordinate motion. The second part of CII's inaugural issue examines this underlying layer, or substrate. Its focus is the physical end of Industrial AI, where software must work through controllers and real-time execution. The question is how this foundation can make intelligence easier to connect to machines without losing the requirements of control.
Different tasks need different clocks
Reasoning, planning, motion control and servo execution operate at different timescales. A useful AI result may arrive after a variable amount of computation, while a control task must meet its deadline consistently. Putting both on one computer does not make their timing requirements identical. The issue therefore presents AI and control as separate loops that must cooperate. The architectural task is to exchange machine observations and proposed actions between them while preserving the timing and responsibilities of the control layer.
Bring compute, control and memory closer
CII examines an architecture in which AI computing and real-time control share an industrial PC, with communication through shared memory. AI can run in a general-purpose environment while control runs on dedicated real-time resources. Bringing these elements closer can provide a more direct connection between machine data and an AI application, but the connection still needs defined interfaces. Shared hardware and shared memory do not themselves establish permission to act or prove deterministic performance. Resource allocation and the behavior of the complete system remain engineering questions.
Software-defined control is an ecosystem of choices
The magazine follows the control stack from computing hardware through operating systems, control software and machine applications. It considers routes including real-time operating systems, real-time Linux, hypervisors and extensions alongside general-purpose operating systems. Soft PLCs, virtual PLCs and software motion control occupy different roles within that stack. These choices have different interfaces and constraints; they are not interchangeable deployment labels. The useful starting point is the machine's execution requirements, followed by the resources and integration work needed to support them.
Make the interface part of the problem definition
A practical conversation between AI and automation teams can begin with the proposed command. What information does the AI receive, how current is it and how does a command enter the controller? Which checks happen before execution, and how is the result observed? Describing this path makes architecture choices easier to evaluate against a real application. It also exposes the next question in the founding issue: once an action can reach the machine, what evidence and authority should determine whether it is allowed to run?
Source and citation
This introduction is adapted from “Part 02 · The Substrate: Software-Defined Control Systems”, CII № 01, pp. 12–19, published by CII NETWORK on . The original section contains the diagrams, examples and referenced sources.
Persistent identifier: ark:66356/c100047. View the publication record.
Read the original
The Substrate
Continue with the full argument, diagrams and sources in the magazine.
Open the magazine at page 12