IIoT Platform: Architecture, Features, and Selection Criteria

An IIoT platform connects machines, control systems, sensors, and existing IT systems to form a reusable database. It collects industrial data, provides it with domain-specific context, and makes it available for monitoring, production analysis, applications, and AI.

The key difference from a standalone solution: A platform does not have to address connectivity, data models, operations, and access anew for every use case. New machines, lines, and applications can build on shared technical and business structures.

What does IIoT stand for?

IIoT stands for Industrial Internet of Things. It refers to the networking of industrial plants and systems so that data can be securely collected, processed, and utilized.

Unlike many consumer IoT applications, the industrial sector has specific requirements:

• long life cycles and heterogeneous generations of control systems;
• segmented OT networks and restrictive firewall rules;
• High standards for availability and traceable changes;
• different protocols and manufacturer-specific data models;
• Edge and on-premises operations for reasons of latency, security, or sovereignty;
• Gradual rollouts across machines, production lines, and locations.

An IIoT platform must therefore combine OT connectivity with data management and an application concept that can be operated in a production environment.

Reference Architecture for an IIoT Platform

A robust architecture typically consists of several layers.

1. Data Sources

Sources include PLCs, sensors, machine control systems, gateways, test benches, files, databases, and MES, ERP, or quality management systems. They provide live signals, events, master data, and domain-specific context.

2. Connectivity and the Edge

Adapters connect protocols such as OPC UA, Siemens S7, MQTT, Modbus, and REST. An edge component can collect, preprocess, and buffer data close to the plant when central systems are temporarily unavailable.

3. Messaging and Data Streams

A streaming or messaging layer transports events between sources, processing components, and applications. A unified namespace can standardize namespaces and topics, but it does not replace a domain-specific data model.

4. Processing and Data Quality

Raw signals are filtered, harmonized, and converted into usable events. This includes timestamp correction, unit conversion, state formation, plausibility checks, and the generation of domain-specific logs.

5. Context and Asset Model

Data is assigned to locations, lines, machines, stations, products, or processes. It is this context that enables reusable queries and comparisons across different data sources.

6. Historicization

Time series, events, and technical logs are stored according to their intended use. Retention periods, event rates, query patterns, and costs determine the storage architecture.

7. Access and Applications

Dashboards, production analytics, notifications, data science tools, and custom applications all access the same database via APIs or event streams.

8. Operations and Governance

Roles, permissions, clients, configuration, monitoring, updates, backups, and auditability transform a technical installation into a productive, usable platform.

IIoT Platform and Related Systems

An IIoT platform does not automatically replace all existing systems.

System	Primary Function	Relationship to the IIoT Platform
PLC/Control	Control the machine in real time	Provides signals and events; the platform does not interfere with the control system in an uncontrolled manner
SCADA/HMI	Operate and monitor the system	Remains at the operational level; data can also be used across platforms
Historian	Store process values long-term	Can serve as a data source or part of the storage architecture
MES	Execute orders and production	Provides order and product context; returns machine events as needed
ERP	Enterprise Resource Planning	Complements master data, orders, and higher-level business processes
Data Lake	Centralized storage of large amounts of data	Can provide long-term storage, but does not automatically address OT connectivity and business context
BI Platform	Create reports and key business metrics	Uses processed production data for reporting and management views

The exact boundary depends on the existing architecture. Clear responsibilities and stable interfaces are crucial.

Key Features

Industrial Connectivity

A platform should be able to cover the actual data sources available and monitor connections. In addition to the list of protocols, reusability, error handling, buffering, and remote configuration are important considerations.

Reusable Data Models

A connector alone does not scale. Data must be structured—using assets, metadata, and domain-specific protocols—in such a way that the same analysis can be applied to comparable machines.

Real-time and historical processing

Operational monitoring requires live data streams; root cause analyses require historical data. Both perspectives should use the same terms, units, and plant contexts.

Open Interfaces

APIs, messaging, and exportable data help reduce the creation of new data silos. Applications should be able to use data in a controlled manner without being dependent on internal platform details.

Security and Governance

Users, roles, technical services, and locations require appropriate permissions. In addition, there is encrypted communication, secrets management, logging, and regulated update processes.

Scalable Operations

The platform should be able to scale with additional data sources, event rates, users, and locations. Scalability affects not only computing power but also configuration, rollout, and support.

Edge, On-Premise, Cloud, or Hybrid?

Edge

Edge components run close to the machine or production line. They are suitable for local protocols, low latency, network segmentation, preprocessing, and controlled data sharing.

On-premises

A local platform instance handles processing and storage within its own network. This facilitates data sovereignty and integration, but shifts the responsibility for operations, updates, and capacity planning more heavily to the organization itself.

Cloud

Cloud operations enable centralized deployment and elastic resources. However, they require appropriate connectivity, security authorizations, and clear rules for data transmission and failure handling.

Hybrid and Multi-Site

In many companies, data is collected locally and selected information is made available centrally. A hybrid model must explicitly define responsibilities, synchronization, offline behavior, and central governance.

Selection Criteria for an IIoT Platform

Professional Fit

• Which specific applications should be developed first?
• Are live monitoring, historical data, production analysis, or custom applications required?
• Does the data model support asset, product, and process contexts?

Technical Integration

• Can the existing control systems, protocols, brokers, and databases be integrated?
• Can MES, ERP, Historian, and BI be integrated via documented interfaces?
• Can we add our own adapters, transformations, and applications?

Operation and Safety

• Which deployment models are supported?
• How do roles, tenants, updates, backups, and monitoring work?
• How does the platform handle power outages or faulty data sources?

Scaling and Reuse

• Can connections, data models, and dashboards be exported as templates?
• How are configurations managed across lines and locations?
• Can the architecture scale data volumes and queries in a transparent manner?

Openness and Economic Viability

• Will data remain accessible through open formats and interfaces?
• Which components are open source, proprietary, or interchangeable?
• What are the components of licensing, infrastructure, implementation, and operating costs?
• What internal capabilities are necessary for long-term operation?

Open Source and Data Sovereignty

Open source can enhance transparency, extensibility, and technological independence. However, the license alone is not the decisive factor. Data formats, APIs, export capabilities, operational knowledge, and the interchangeability of individual components also determine actual autonomy.

The following questions are therefore helpful for the evaluation:

• Does the company have full access to its raw and contextual data?
• Are the interfaces documented and usable without proprietary workarounds?
• Can the platform be operated in our own target environment?
• Is it possible to develop your own components and have them tested independently?
• Is there a clear process for updates, support, and migration?

Phased Implementation

1. Define the outcome rather than the scope of the platform

Start with a specific data source and a verifiable result, such as a status overview or cycle time analysis.

2. Clarify architectural and operational limits

Determine which components run on the OT network, at the edge, centrally, or in the cloud, and who is responsible for them.

3. Integrate the data source into the production environment

Test connection stability, timestamps, data rate, schema, and behavior during interruptions under real-world conditions.

4. Build a context model

Assign signals to a system and define units, semantics, and domain-specific models. These structures should be transferable to other machines.

5. Deploy the first application

Create a usable result for the target audience. This will help identify requirements regarding data quality, access, and usability early on.

6. Ensure Operational Security

Finalize monitoring, roles, backups, update processes, and responsibilities before rolling out the platform to other critical areas.

7. Scaling Templates and Governance

Roll out proven connectors, data models, and applications to other assets and locations in a controlled manner.

Common Mistakes

• Launching a platform without a clear initial benefit: Architectural work evolves before a result can be evaluated.
• Confusing connectivity with data modeling: Transmitted signals do not yet constitute a comprehensible database.
• Building new pipelines for every use case: This creates new silos despite the platform.
• Focus only on the pilot: Security, monitoring, updates, and rollout are addressed too late.
• Choosing Between Cloud and On-Premises in a Dogmatic Way: The operating model must align with networks, latency, governance, and organization.
• Compare only licensing costs: Integration, data modeling, and ongoing operations account for a large portion of the total costs.

Compact Checklist

• Have the initial use case and success criteria been defined?
• Are all relevant data sources and protocols known?
• Is there an asset, metadata, and permissions strategy?
• Have the responsibilities for edge, on-premises, and cloud environments been clarified?
• Can data and applications be integrated via open interfaces?
• Can configurations be transferred to other machines?
• Are monitoring, backups, updates, and support included?
• Will data access and portability be maintained in the long term?

The Bytefabrik IoT Data Hub implements these architectural principles as an open IIoT data platform. For more in-depth information, see “Building and Operating IIoT Infrastructure” and the guide on the architecture, features, and use of Apache StreamPipes.