Connecting a machine is usually a quick task today. Modern connectors support OPC UA, Modbus or Siemens S7 natively, so a new data source can often be available within minutes. However, this only solves connectivity, not interoperability. ERP, MES or data models cannot work with raw controller values alone. The data still needs context, standardized formats, units, structure and a clear place in the plant hierarchy. This is where integration projects often take weeks or even months. A self-connecting factory therefore automates more than the technical connection. It covers the entire chain: from discovering a data source to contextualizing, modeling and distributing its data. This article explains five maturity stages, the key technical bottlenecks and the role of AI along the way.
What is a self-connecting factory?
A factory is self-connecting when a new participant can join the shared data flow without a dedicated integration project. That participant can be a machine, a sensor or an IT system. The key criterion is no individual project. Simply establishing a technical connection faster is not enough. The entire process must be automated until the data is structured in a way that other systems can understand and use directly.
Plug-and-play requires IT/OT interoperability on six levels
A new participant can only be added via plug-and-play if OT and IT systems exchange data in a structured and consistent way. This is what IT/OT interoperability means. The important point is not just the physical network connection. Systems also need to understand the syntax and semantics of the data. The Data Access Model by Matthew Parris divides this requirement into six consecutive levels, from Level 0 to Level 5. Plug-and-play only works when sender and receiver are aligned across all six levels.
| Level | What it defines | Example |
|---|---|---|
| Level 0 – Transport | Transfer of bits and bytes between two endpoints | TCP/IP, UDP |
| Level 1 – Protocol | Rules for exchanging messages | OPC UA, MQTT, PROFINET |
| Level 2 – Mapping | Addressing and structure of the data within the protocol | MQTT topics, OPC UA NodeIds |
| Level 3 – Encoding | Serialization of the message | JSON, Protocol Buffers, OPC UA Binary |
| Level 4 – Values | Data types and value ranges | Boolean, integer, float |
| Level 5 – Objects | How values relate to each other in object and information models | OPC UA Companion Specifications, Asset Administration Shell |
Standard protocols mainly cover Levels 0 and 1. MQTT or NATS, for example, standardize transport and communication, while the levels above remain open. Without clear conventions, teams end up with inconsistent topics at Level 2, different payload formats at Level 3, varying data types and units at Level 4 and incompatible object models at Level 5. Many teams solve this with proprietary integrations. These may work well in the short term, but they do not create long-term interoperability.
The real integration effort therefore sits mainly in Levels 2 to 5. This is also the part that a self-connecting factory aims to automate. The article IT/OT Interoperability in the Unified Namespace (UNS) – Basics explains these levels, their typical challenges and possible countermeasures in more detail.
Three processes that enable a self-connecting factory
For a new participant to join without an individual integration project, three processes need to work together. Each one addresses different levels of the Data Access Model:
- Discovery (Level 0 to 2): The system finds a new device on the network and identifies its type and protocol. This could be a PLC (programmable logic controller), an OPC UA server or another data source. It then reads the addresses exposed by the interface, such as registers, data block addresses or NodeIds. At this point, the raw data points are reachable, but their meaning is still unknown.
- Assignment (Level 2 to 5): The system maps the discovered data points to the target model of the Unified Namespace. It defines the topic name (Level 2), sets payload format and scaling (Level 3), harmonizes data type and unit (Level 4), and finally assigns the data point to an object model and the plant hierarchy (Level 5). This is where semantics are created.
- Operation (Level 0 to 5): The system monitors the connection and the data stream. It detects failures at transport and protocol level (Level 0 and 1) and reports deviations from defined conventions. These can include changed data types, unexpected units or topics outside the naming convention (Level 2 to 4). Deviations in the object model also matter, for example when attributes disappear after a firmware update. A separate monitoring setup is no longer required for every new machine.
From Level 2 onward, automation needs a target
Standard protocols already automate much of Levels 0 and 1. From Level 2 onward, however, automation needs a clear target. The system must know what a correct assignment looks like. That requires a binding rule set for each interoperability level. Typical examples include a topic convention based on ISA-95, a consistent payload format such as JSON, harmonized data types and standardized object models such as OPC UA Companion Specifications.
Without these rules, the system has no reference point for its decisions. This is also why semantic assignment has been difficult to automate. Levels 2 to 5 require domain knowledge. Language models can help by analyzing device descriptions, tag lists and technical documentation and turning them into mapping proposals. A domain expert still validates and approves these proposals.
Five maturity stages on the way to the self-connecting factory
The path to the self-connecting factory can be divided into several maturity stages. The following model is a structuring framework rather than a formal standard. It shows how much effort is required to integrate a new machine at each stage and which limitation drives the next step.
The stages can also be mapped to the interoperability levels. Stage 1 standardizes transport and protocol (Level 0 and 1). From Stage 2 onward, the focus shifts to mapping, encoding, data types and object models (Level 2 to 5). This is where most of the integration effort sits today. Stages 3 and 4 automate this work step by step. Because each stage builds on the previous one, skipping stages is only possible to a limited extent.
Stages 0 to 2: from individual projects to contextualized data
The first three stages focus mainly on data structure and data understanding. Humans still do most of the work here.
- Stage 0 – Point-to-point: Every connection is a separate project, and systems communicate directly with each other. No interoperability level is standardized across the organization. Knowledge often lives with individual experts, in spreadsheets or in project-specific documentation. The main limitation is scalability: every additional system increases integration effort disproportionately.
- Stage 1 – Unified data space: All sources publish their data into a shared infrastructure, for example a Unified Namespace (UNS). Transport and protocol are now standardized (Level 0 and 1). However, the meaning of the data remains unclear. Anyone who wants to understand a data point still needs to know the topic structure and data schema.
- Stage 2 – Contextualized data: A consistent data model and topic hierarchy, for example based on ISA-95, add meaning, unit and plant position (Level 2 to 5). A raw value becomes useful information. The limitation at this stage is manual modeling: each machine still has to be mapped by hand. This is often where most of the project effort occurs.
Stages 3 and 4: from assistance to autonomy
From Stage 3 onward, the division of work changes. The system takes over more of the interpretation, while humans focus on review and approval.
- Stage 3 – Assisted onboarding: A human starts the integration of a specific machine. The system then analyzes the raw output and proposes names, units and a place in the data model. A human reviews and approves these proposals. The interpretation is automated, but the trigger is still manual. That is the key limitation of this stage.
- Stage 4 – Autonomous onboarding: The system detects on its own that a participant has been added or changed. It then runs through discovery, assignment and operation until the data is published. Clear cases pass automatically within defined rules, while unclear cases are escalated. Humans only intervene for exceptions. Onboarding becomes a continuous function instead of a separate project. The limitation at this stage is governance: clear roles and approval rules are required because the system writes configurations automatically.
The transition from Stage 2 to Stage 3 is especially challenging in practice. The next sections explain which infrastructure is required and why this step is difficult.
Required infrastructure for a self-connecting factory
The maturity stages describe how far the integration of new participants has been automated. Whether a factory can actually reach a certain stage depends on the infrastructure underneath. A self-connecting factory needs four building blocks that build on one another. If one is missing, further automation quickly reaches its limits.
Transport, semantics, API and approval
- Transport layer: A shared data flow replaces bilateral connections between individual systems. The Unified Namespace provides a shared, hierarchically organized data foundation. This layer corresponds to Stage 1 of the maturity model and to Levels 0 and 1 of the Data Access Model.
- Semantic layer: Transport alone is not enough. Interoperability only exists when systems interpret the same information in the same way. This includes addressing, encoding, units and semantic models (Level 2 to 5).
- API layer: IT systems and agents need consistent access to the shared data space.
- Agent and approval layer: This layer defines which actions an agent may perform independently, where human approval is required and which decisions must be logged. It enables Stages 3 and 4 of the maturity model.
Why the order of the building blocks matters
The four building blocks form a stack. Each layer depends on the one below it. Without a transport layer, there is no shared foundation. Without semantics, an API only exposes raw values that are difficult to understand. And without reliable access, an agent layer cannot operate safely.
Introducing agents before a consistent data model exists therefore creates a new risk: automation can reproduce inconsistencies faster than teams can correct them manually. The rule for a self-connecting factory is simple: define the target model and rule set first, then automate the assignment. Semantics are not bypassed. They are defined once and then reused across additional machines.
Example implementation
The four building blocks describe what needs to be in place. The OneClick UNS approach by i-flow shows how semantic assignment can be automated on top of this foundation. The transition from Stage 2 to Stage 3 has traditionally been slowed down by manual semantic work. AI can support this step by deriving assignments that follow a defined target model. The approach consists of three steps:
- Auto Discovery: i-flow identifies PLCs, OPC UA servers and other data sources on the network and connects them automatically.
- Auto Modeling: For a detected machine type, the system proposes a suitable standard schema. This schema acts as the target model for the assignment and automates part of the modeling work that would otherwise be done manually.
- Auto Publishing: After approval, the system publishes the structured data automatically to the Unified Namespace.
Human-in-the-loop: the human as reviewer
Following the human-in-the-loop (HITL) principle, no configuration goes live without approval.
This changes the role of the human. Instead of creating the entire assignment manually, the expert reviews and confirms the system’s proposals. This role shift marks the transition from manual integration to assisted and eventually autonomous onboarding. The following chart illustrates this change.
Current obstacles on the way to the self-connecting factory
Even with the right infrastructure and AI support, one major bottleneck remains: automatic discovery can only use information that an interface actually provides. This is particularly relevant in brownfield environments. Many common OT protocols transmit values but provide little information about what those values mean. Two examples illustrate the problem:
- Modbus: A register might return the address
40001and the value1450. The register itself does not tell you the signal name, unit or scaling. The information “spindle speed in revolutions per minute” is simply not included. - Siemens S7 native: With absolute addressing, a value may be accessed through an address such as
DB10.DBW4. The structure often follows a project-specific convention and does not explain its technical meaning.
Consequence: Stage 2 cannot be skipped
These examples lead to one important conclusion: many machines provide technical endpoints, but not enough semantic information. The technical connection may therefore be available within minutes, while the semantic classification takes much longer. That missing semantics has to be added at least once. Possible sources include technical documentation, existing standards or the knowledge of the machine integrator. Only then can a system automate the assignment and reuse it for additional machines of the same type.
Conclusion: the self-connecting factory starts with interoperability
The self-connecting factory describes a maturity stage of industrial data integration. A new participant can only join without a dedicated project when interoperability is aligned across all six levels of the Data Access Model.
- The main effort lies in semantics: Standard protocols already cover transport and protocol (Level 0 and 1). The real integration effort lies in mapping, encoding, data types and object models (Level 2 to 5), because many OT interfaces expose values without enough meaning.
- Define the target model before automating: The four infrastructure layers build on one another. Once the target model and rule set are defined, the assignment can be automated and reused across additional machines.
- AI interprets, humans approve: From Stage 3 onward, the system creates mapping proposals. Humans review them, approve them and handle exceptions.
A step-by-step approach is therefore the most practical path. Once the semantics are defined cleanly, each additional machine becomes less of a new integration project and more of a repeatable onboarding process.
