Content Level: Overview / Implementation considerations
Principles and Suitability
Industrial IoT connects equipment data through a gateway to applications. Edge describes processing near the equipment. Sensors may supply digital measurements directly, while vision must acquire images and convert them into values with quality information before integration into a data model.
IIoT means industrial data connectivity, not direct internet access to equipment. A gateway coordinates routes and formats; edge identifies where computation occurs near the source. A tag is a shared data name and needs a clear owner and unit. Identical numbers from a sensor and an image reader may have different quality and reference times. Preserve their provenance before combining them so users can interpret the values correctly.
Engineers define a model containing value, unit, source, timestamp, quality, and version, with read access separated from control. OPC UA provides structural and communication guidance; MQTT transmits messages using the designed format. QoS describes message delivery service, not physical measurement correctness. Applications must also check duplicates and ordering. Standard protocols do not automatically correct wrong units or stale data.
Scroll the diagram horizontally to inspect all details.
Illustrative Industrial Example
Design example: a gateway combines OPC UA measurements and gauge readings as tags with values, units, source timestamps, and quality, then sends MQTT messages. This does not implicitly permit cloud commands to a PLC.
Suppose one channel uses a different unit from the image reader. Similar tag names do not justify combining the values into one series without a verifiable conversion. When the camera cannot read, transmit an appropriate quality state rather than zero. Storing and forwarding data after network recovery must preserve original source time. A new reception timestamp must not make historical measurements appear to describe current equipment conditions.
Engineers check mappings with instrument and data-system owners, then test disconnection and store-and-forward using simulated data. Check duplicate message identifiers and sequence gaps indicating missing intervals. Limit gateway permissions to the reads required by the task. Successful communication is not a reason to add PLC write access, and actual commands that could affect machinery must not be used simply to demonstrate connectivity.
Study and Trial Workflow
- 1 Map data flows and separate reading channels from control channels.
- 2 Define tag mappings, units, timestamps, quality, and schema versions.
- 3 Test disconnection, store-and-forward, and retries without creating duplicate events.
Evaluation and Metric Definitions
Measure completeness, freshness, and correct tags and units, together with sequence gaps and recovery. Applications must handle duplicates allowed by the chosen QoS level.
Completeness must be compared with what should have been sent, not only messages observed by the receiver. Freshness uses attributable capture or measurement times. Correctness requires checking units together with equipment names. Report duplicate, missing, and incorrect-state data separately. A large message count can reflect retries rather than good source quality or usable measurements.
Engineers use reference messages to check transformations and destinations, including rules for full queues and inconsistent clocks. Test recovery without treating backlog as current data, and verify roles that must not write to OT systems. OPC UA or MQTT specifications guide communication design; they do not certify security or compatibility with every device. They also do not establish which protocols or QoS levels a product currently supports.
Limitations and Failure Cases
MQTT QoS does not guarantee physical correctness of measurements. Legacy systems may lack security features adequate for direct internet connection.
Complete delivery can still carry wrong units, incorrect names, or inaccurate instrument readings. Separate transport evaluation from measurement quality. Some older systems have authentication or update limitations. OT owners must define suitable boundaries and connection paths. Convenience in sending data is not justification for directly exposing equipment or changing operational settings without an approved plan and recovery procedure.
Combining sources provides context but increases namespace, clock, and version management. Retries improve completeness while adding deduplication work, which must be designed at the application level and tested against reference data. This example explains IIoT and edge concepts, not current product connectivity services or standards certification. Read access must not automatically expand into cloud control before risks to the actual system have been assessed.
Practical Checklist
- Is ownership of the tag namespace defined?
- Is stale data distinguished from normal readings?
- Are the OT boundary and gateway permissions specified?