B) Data Modeling in the Unified Namespace: From Topic Hierachies over Payload Schemas to MQTT/Kafka

In manufacturing, the Unified Namespace (UNS) is a powerful tool for facilitating communication between nodes in a network. This event-driven architecture operates on the principle that all data should be made available for consumption, regardless of whether there is an immediate consumer. This means that any node in the network can act as either a producer or a consumer, depending on the system's needs at a given time.

Any manufacturing company intending to implement a UNS-based architecture should follow a series of steps:

Step 1: Connecting to Operational Technology (OT)

The data utilized in manufacturing can be broadly categorized into three types: relational, time-series, and semi-structured or unstructured.

Time-series data can be dispatched through two primary methods:

1. Transmitting at consistent intervals to the message broker. This method includes details such as device uptime, but it can generate a substantial volume of data.
2. The "report-by-exception" approach. Here, data is transmitted only when changes occur, effectively reducing the data volume. However, this method necessitates additional uptime information. For instance, it's crucial to determine whether the value didn't change or if the device was offline.

The conversion of relational data into events for transmission via a Unified Namespace (UNS) is recommended. This process entails subscribing to all changes in the existing relational table (inserts, updates, deletes) and transmitting these changes to the UNS. Examples of these events are "addOrder," "changeOrder," and "deleteOrder."

SQL triggers or Change Data Capture (CDC) tools like Debezium can be utilized to generate data change events. In some cases, Programmable Logic Controllers (PLCs) or shop floor systems may directly emit these change events. This strategy enables event replay, allowing for the reproduction of the exact SQL table state.

Just like relational data, semi-structured / unstructured data should be transmitted when changes occur. Contrary to popular belief, there are no restrictions on sending images through MQTT. The MQTT standard allows up to 256 MB per payload, while Kafka's default is 1MB, extendable to 10MB without significant performance issues. This capacity is sufficient for most semi-structured or unstructured data.

If data size exceeds these limits, consider splitting larger data, like videos, into smaller segments to ensure compatibility. Alternatively, if large payloads are required, store the data in blob storage like file disk or S3 compatible systems. Then, process only the data reference, such as the file path, via Kafka.

Ensure that no data modification occurs between the OT producer and the message broker to maintain modularity. Some industries, like pharmaceuticals, even mandate this due to regulatory requirements, such as GxP compliance. Downsampling or altering the data before sending it to the UNS could create issues. For example, if someone wants to access the raw data for a different analysis or a new AI model, modification would render this impossible.

Step 2: Topic Hierarchy

The second step in the process requires the creation of a topic hierarchy. Ideally, this hierarchy should closely mirror the physical structure of the manufacturing plant or any existing asset naming system for two main reasons:

1. Enhancing data point visibility and facilitating data browsing for OT engineers.
2. Bolstering security. For instance, in multi-plant scenarios, access of a certain device could be restricted to specific plants or even more granular levels.

A large number of enterprises adopt the ISA-95 model, thus forming their topic structures based on this standard. However, it's important to note the existence of Sparkplug-B, a standard that outlines potential payload and topic structures. Despite its benefits, Sparkplug-B focuses solely on "Device Management" and doesn't align with the ISA95 model. Also, it relies on ProtoBuf, which, while straightforward for IT professionals, may complicate matters for those in OT. Given that most manufacturing devices are connected via Ethernet cables, the bandwidth savings provided by Sparkplug-B hardly justify the increased complexity.

Consider including the following elements in your topic structure for enhanced functionality:

1. A version number to facilitate future changes.
2. The client ID for granular access control, allowing a device to send data only to its own topics.
3. The client ID for tracing and lineage purposes to pinpoint the exact source of each message.
4. The tag name, and for larger quantities, tag groups, which can improve performance. For example, if a device sends large amounts of varied data, a specific microservice may only require a subset of this data. By filtering through tag groups, unnecessary burdens can be avoided.

Example from the United Manufacturing Hub

In the United Manufacturing Hub (UMH), we organize data using a specific topic structure that adheres to the ISA95 model. This structure looks like this:

umh/v1/enterprise/site/area/productionLine/workCell/originID/_schema

Topic Names and Rules: All parts of this structure, such as 'enterprise', 'site', 'area', etc., are flexible in terms of their naming. They can include letters (a-z, A-Z), numbers (0-9), and certain symbols (- and _). However, symbols like ., +, # or / are not used as they have special meanings in MQTT or Kafka.

Versioning Prefix: The umh/v1 at the beginning is obligatory. It ensures that the structure can evolve over time without causing confusion or compatibility issues.

ISA95 Compliance: The terms like 'enterprise', 'site', 'area', etc., are aligned with the ISA95 model, which is a standard for industrial systems. 'Enterprise' is the only mandatory term; others can be skipped if they don't apply, e.g., a room temperature sensor for a specific area.

Origin ID: This part identifies where the data is coming from. It could be a serial number, a MAC address, or even a software component like a Docker container. If multiple sources are involved, they're separated by underscores. Examples of originIDs: E588974, 00-80-41-ae-fd-7e, VM241_nodered_mes

The _schema Field: This is where IT and OT professionals need to pay close attention. The '_schema' field, identified by its leading underscore, is crucial for defining the type of data or the format being sent. In the UMH, we have default schemas like '_historian', '_analytics', and '_local', but users can add more as needed. The underscore is important for clarity in parsing the structure, especially when some elements like 'workCell' might be omitted.

1. Schemas _historian and _analytics:
   • Validation of Messages: The United Manufacturing Hub (UMH) is programmed to process messages under the _historian and _analytics schemas only if they adhere to a valid schema format (see further below)
   • Handling Invalid Messages: Any message that is not in JSON format or does otherwise not meet the schema, even if sent to these schemas, will not be saved in the database nor forwarded to another broker. This ensures data integrity and consistency in processing.
2. Schema _local:
   • Non-Processing Policy: Messages sent under the _local schema will not be processed by UMH. This schema is reserved for data that is intended to remain local and is not meant for forwarding or storing in the database.
3. Other Schemas:
   • Forwarding without Storage: Messages falling under schemas other than _historian, _analytics, and _local will be forwarded to other brokers via bridges.
   • Independence from Structure and Payload: This forwarding occurs regardless of the specific topic structure following the _schema marker and irrespective of the payload format. However, UMH will not store these messages in its database.

Default schema: _historian

Data under this schema gets stored in TimescaleDB, useful for time-series data analysis aka the Historian Feature.

Topic Structure:

• The basic topic format under this schema is .../_historian or .../_historian/<tagGroup1>/<tagGroup2>/.../<tagGroupX>/<tagname>.
• The use of tag groups (<tagGroupX>) is optional and allows for better organization of large numbers of tags (e.g., 10,000 tags from an asset). This organization facilitates easier navigation and reduces system load.
• The <tagname> part of the topic is optional and can be used for more specific data categorization.

Payload Format:

• Payloads in this schema are in JSON format.
• Essential keys include:
  • timestamp_ms: A Unix timestamp in milliseconds, indicating when the message was created.
  • At least one additional key representing the data value, which can be Number, boolean or string. Note: the boolean must NOT be in quotes as it will be treated a string instead

Tag Grouping Methods:

1. Using Underscores in Key Names: For example, spindle_axis_x. This results in the tag 'x' being categorized under the group 'axis', which is part of the 'spindle' group.
2. Using Tags / Tag Groups in the Topic: The tag is placed before the key name, allowing for multiple group formations.
3. Combining Both Methods: For instance, a message to .../_historian/spindle/axis with key x_pos will categorize 'pos' under 'x', which is under 'axis' and 'spindle'.

Examples:

• Example 1: Sending a message with payload { "timestamp_ms": 1680698839098, "x_pos": 123, "x_speed": 456, "y_pos": 789, "y_speed": 001 } to the topic umh/v1/dcc/aachen/shopfloor/wristband/warping/_historian/spindle/axis will result in storing four tags for the given timestamp: spindle_axis_x_pos, spindle_axis_x_speed, spindle_axis_y_pos, and spindle_axis_y_speed
• Example 2: A message with payload { "timestamp_ms": 1680698839098, "temperature": 23 } to umh/v1/dcc/aachen/_historian stores the temperature tag for the site 'aachen' for the given timestamp.

2. _analytics

Step 3: Payload Structure

This step involves determining the structure of your payload data, which is subject to your production environment's specific needs such as speed, compatibility, simplicity, and capacity to handle complex data structures. Payload data can be defined using various data formats, including JSON, Protobuf, XML, or any other suitable data format.

Binary formats like Protobuf or Avro offer a structured and compressed approach, leading to bandwidth transmission savings. However, for instances where direct readability is crucial, XML, JSON, or YAML structures are preferred.

We recommend using JSON payloads, as in manufacturing bandwidth is rarely a concern. JSON enhances the capability of OT professionals to work with and understand messages. It enables you to directly open and interpret the messages in tools like MQTT Explorer or Node-RED. With formats like protobuf, such direct understanding isn't possible.

Example from the United Manufacturing Hub

See also the example further up

Step 4: Bridging data efficiently between MQTT and Kafka

Because we opted in for using MQTT and Kafka, we also need to ensure that data is bridged between those. As this is an article about data modeling, we just leave the ADRs here, and proceed quickly to the other topics.

Step 5: Enforcement

The final step in this process is enforcing the established standards and conventions throughout your system. This consistency ensures system integrity. The enforcement involves outlining security requirements, managing state and data flow, setting boundaries, and confirming that each device has the necessary authorization to exchange information.

Currently, enforcing message and topic schemas is not a feature available by default in MQTT. However, efforts are underway to introduce this functionality. HiveMQ, an MQTT broker, is actively working on providing such features. For more details, you can refer to their documentation: https://docs.hivemq.com/hivemq/4.15/data-governance-hub/index.html.

For Kafka, this feature is known as a 'schema registry'. It's an integral part of the protocol. If a message doesn't comply with the established standard, the MQTT/Kafka broker won't receive it, and it will be rejected.

A few other features in MQTT, such as last will and state, are less relevant for manufacturing contexts. These features are typically more applicable in use-cases involving globally scattered devices, such as connected cars. We recommend focusing on features that most directly apply to your specific manufacturing requirements to ensure the optimal setup for your system.