A common misconception in industrial IoT (IIoT) is that complex production processes require a wide variety of data types to be represented effectively. In reality, the opposite is often true. With a carefully chosen set of Data Types in the Unified Namespace (UNS), it is possible to build a scalable and future-proof data architecture that supports efficient IT/OT integration. By reducing unnecessary complexity, companies gain consistency, reliability, and better performance at the critical interface between IT and OT. This article explains why in the UNS, “less is more”, highlights the advantages of a lean data type strategy, and explores where its limitations lie. For readers new to the topic, we recommend our introduction to IT/OT interoperability here.
Variety of Data Types: Advantages and Disadvantages
In industrial IoT (IIoT), it is often assumed that the more data types there are, the more precisely production data can be represented. And indeed, a broad set of data types brings certain advantages at the OT level (Level 2 and below):
- Robustness and type safety: Errors are detected early, often at compile time instead of during operation.
- Real-time capability: Specific data types can increase performance in time-critical processes.
- Memory efficiency: Especially in resource-limited control systems, selecting the optimum data type helps to save memory space.
However, when shifting from OT to the IT/OT integration level (Level 3 and above), the situation changes. A multitude of Data Types in the unified namespace (UNS) is less beneficial and often becomes a hindrance. Since the UNS thrives on standardization and simple integration, too much variety creates challenges:
-
- Greater system complexity: More data types mean more rules, exceptions and handling effort.
- Higher error risk: Different interpretations of data types increase misunderstandings between systems.
- Integration difficulties: A heterogeneous type set complicates the smooth onboarding of new systems and applications.
This complexity has a negative impact on scalability and maintainability, especially in data-driven IIoT architectures.
OT vs. IT/OT – Different Requirements
The requirements for data types in Industrial IoT (IIoT) differ significantly depending on the system level. While Operational Technology (OT, Level 2 and below) is dominated by efficiency and real-time capability, the priorities at the IT/OT integration and Unified Namespace (UNS) level (Level 3 and above) shift towards standardization and interoperability.
Operational Technology (Level 2 and below): At the control and machine level, the focus is on real-time capability, precision, and memory efficiency. A broad spectrum of data types is useful here. For example, float16, int8, or special numerical types for high-precision measurements. The result: maximum efficiency in a local context, adapted to the individual requirements of a machine or controller.
IT/OT integration (UNS level, level 3 and higher):At the integration level, other priorities dominate. Here the focus is on standardization, scalability, and interoperability across the entire IIoT stack. Instead of variety, the goal is a reduction to a few universal data types in the Unified Namespace (UNS) such as Integer, String, Boolean, and Timestamp.
The Right Strategy: Less Is More in the UNS
Based on the different requirements of OT and IT/OT, two distinct data type strategies emerge. The rule of thumb is clear: OT (Level 2 and below) → data type diversity for local efficiency, UNS (Level 3 and above) → minimum types for global scalability.
| Requirement | OT (level 2 and below) | IT/OT integration (UNS level) | Data type strategy |
|---|---|---|---|
| Real-time capability | Hard latency budgets; optimized computing paths. | No hard real-time requirements in the backbone. | OT: Data type diversity (e.g. int8, float16) UNS: Minimal data types (e.g. integer, string) |
| Robustness & type safety | Strict, narrowly typed models to avoid errors at compile/deploy time. | Consistency through standard schemas more important than narrow machine typing. | OT: Data type diversity US: Minimal data types + schema registry |
| Memory/resource efficiency | Smallest possible widths to conserve CPU/RAM (e.g. uint16). | Resources are less critical than readability & standardization. | OT: Data type diversity US: Minimal data types |
| Standardization | Device/manufacturer-specific; high variance accepted. | Strict standardization across domains (UNS as “common language”). | OT: Use of type standards (e.g. OPC UA) UNS: Minimal data types to reduce mapping effort |
| Interoperability | Locally optimized, often proprietary. | High; cross-system exchange (MES, ERP, data lake, cloud). | OT: Use of type standards (e.g. OPC UA) UNS: Minimum data types |
| Integration effort | Low within the cell, high during the transition to IT. | Low due to consolidation to a few, clear types. | OT: Data type diversity (local fit) UNS: Minimal data types (global fit) |
| Susceptibility to errors | Low due to narrow typing in the local context. | Low due to standardized minimal types with unambiguous field definitions. | OT: Data type diversity US: Minimal data types + validation rules |
| Scalability & maintainability | Scaling limited by heterogeneous type worlds. | High scalability thanks to standardized data types in the UNS. | OT: Use of type standards (e.g. OPC UA) UNS: Minimal data types (simpler pipelines & governance) |
Limits of the Minimal Type Approach
As effective as the strategy of using minimal Data Types in the Unified Namespace (UNS) is, there are scenarios in Industrial IoT (IIoT) where a broader variety of types remains essential. Typical exceptions include: High-precision energy measurements – often requiring float64, since smaller types are not sufficient – or image and sensor data. These cases should always be treated as specific exceptions, not as the rule. The UNS must remain lean and standardized, with additional data types allowed only where there is a clear technical necessity.
Data Formats and Their Impact on Data Types
Beyond the choice of data types themselves, the exchange format plays a crucial role in determining efficiency, readability, and interoperability in the UNS. Different serialization formats handle typing in distinct ways:
- XML: Strongly typed, but very verbose. Useful for complex structures, but inefficient for a lean UNS strategy.
- JSON: Widely used in UNS implementations, as it supports a minimal data type approach with just a few primitives (number, string, Boolean, null).
- Protobuf (Protocol Buffers): Binary, highly efficient and strictly typed. Ideal for performance and low bandwidths, but requires a predefined scheme. Here, type reduction is ensured by clear field definitions and numerical IDs.
The choice of format therefore influences how “tight” or “loose” data types are handled in the UNS. JSON encourages simplification with fewer types, while Protobuf enforces strict type safety. Regardless of the format, reducing complexity to a few basic data types is key to achieving higher interoperability across IT and OT systems. Further details on data formats and their areas of application can be found here.
Practical Example
In practice, most IIoT use cases can be represented with just a few Data Types such as Object, Array, Integer, Boolean, String, and Timestamp. The following example illustrates how data flows from a machine sensor to an analytics dashboard:
1. OT Sensor (level 1-2)
- A vibration sensor provides raw data as int64 for vibration strength.
- It also sends a status bit as a string (normal, alarm).
2. i-flow Edge: reads the OT data and converts it to a simplified schema for the UNS
- int64 → Integer
- String becomes Boolean (true=normal, false=alarm)
- Addition of a timestamp (UTC, ISO 8601) for temporal correlation.
3. Unified Namespace (UNS, e.g. MQTT/JSON): data is published in a standardized format
4. Dashboard: standardized data types enable further processing
- Integer → Time series analysis (trend, threshold exceeded).
- Boolean → Classification (OK/Alarm).
- Timestamp → Correlation with other events.
5. Validation & Governance: Clear rules and central control (governance) are required to ensure that the strategy works in the long term. In practice, this is done via schema and topic governance in a central management tool for a schema registry and validation.
Conclusion: As Much as Necessary, as Little as Possible
A scalable Unified Namespace (UNS) does not require a wide variety of data types. Instead, a minimal data type approach reduces complexity, improves interoperability, and ensures consistent data quality in the Industrial IoT. While the OT level benefits from fine-grained types for real-time processing and efficiency, IT/OT integration gains clarity, scalability, and consistency by reducing Data Types in the Unified Namespace.
