IoT gateway: Assigning device data to the work step

What the gateway connects

A gateway mediates between technical systems. Depending on the setup, it can bring interfaces together or translate protocols. OPC UA describes a Gateway Server as an intermediary for one or more servers; protocol conversion is one possible function.^[2]

This involves two decisions: How does the message reach the application, and how is it understood there? A working connection does not establish whether a weight entry represents material dispensed, material returned or a check measurement. That meaning belongs in the process context model.

Start with the task, then choose the device

The following overview groups typical devices by their task at the workplace. The final column lists information to specify for the particular setup.

For industrial smart glasses, display and interaction are central. A sensor reading and a human inspection judgement serve different purposes. Each process needs to specify which information is received automatically and where assessment or confirmation remains necessary.

Example: Weighing into the correct operation

In this fictional example, material is weighed for order A-204. Scale W-03 reports 1.250 kg. The active step requires the quantity for container B-17. Assignment connects the device, value and task.

This setup should be tested for whether B-17 is actually selected, whether the unit matches the instruction and whether the measurement belongs to the active step. A value arriving late must not be used simply because the same workplace has moved on to the next order.

The diagram illustrates this design task. It is neither a screen workflow nor a device approval.

Consider value, time and status together

A reading needs a clear time reference. Time at the source and arrival in the application can differ. An OPC UA DataValue includes a value, StatusCode and timestamps; SourceTimestamp represents the data source timestamp. When forwarded between OPC UA servers, that source timestamp is preserved.^[3]

This leads to specific application questions: Is the value still current for this step? Is its source known? Does the status received indicate that it can be used? Technical data integrity and fitness for the task should be assessed separately.

When messages are missing or arrive more than once

A lost connection, a delayed message and a retransmitted value require different handling. MQTT 3.1.1 QoS 0 permits message loss; QoS 1 permits duplicate delivery. Protocol acknowledgement concerns message transport.^[4]

The work step also needs a decision about when an entry counts as accepted. Trials should therefore show how missing values are displayed, whether repeated delivery is recognised and how work can resume after an interruption. Two deliveries of the same message should not silently become two measurements.

The resulting process events must show which entry was actually used in the process. A receipt acknowledgement alone does not describe that use.

Include an outage in the trial

A first trial can cover a limited work step with a clearly identified source. Test normal operation, an incorrect object selection, an old message, an interruption and a repeated delivery. In each case, the question is whether the process makes the condition clear and enables the person to continue in a controlled way.

What does the person at the workplace see when the expected device value is missing — and how do they recognise that the value used belongs to the current step?