Definition
Protocol conversion (industrial protocol conversion) refers to converting data from different communication protocols used by industrial devices (such as Modbus RTU/TCP, OPC UA, Profibus, EtherNet/IP, BACnet, DLMS/COSEM, etc.) into a unified format (such as MQTT, HTTP, OPC UA) or target protocol, achieving interconnectivity of heterogeneous devices. Protocol conversion gateways are usually deployed at the edge, collecting data from multiple protocol devices and uploading it to the cloud platform or SCADA.
Industrial on-site devices have different brands, models, and protocols. Protocol conversion is a key step for cloud integration and data aggregation. Gateways need to support multi-protocol concurrency, data mapping, edge computing, and other capabilities.
Technical Features
The protocol conversion gateway collects device data using polling or subscription methods and supports register mapping and data point table configuration. Some gateways have edge computing capabilities, allowing for data preprocessing and alarm detection. IoT SIM cards provide uplink connections for the gateway, uploading aggregated data to the cloud platform. In scenarios without wired networks or with dispersed sites, cellular connections are the main method.
Use Cases
Protocol conversion is widely used in smart manufacturing, energy management, building automation, smart water management, distribution automation, and other scenarios. Industrial gateways and edge boxes access PLCs, sensors, electric meters, and other devices through protocol conversion, and the data is uploaded via IoT SIM cards to MES, SCADA, and cloud platforms. SimtoLink provides stable network access and dedicated APNs for industrial gateways and edge devices, ensuring multi-protocol data aggregation and remote transmission.
What an uplink means after the point list is mapped
After protocol conversion, what runs on the IoT SIM is no longer the raw frame from the field bus. It is the engineering value picked out by the point list. Register address, scale, data type, and deadband have already been interpreted in the gateway. The name the cloud sees must point back to one row of that point list. The point list and the field device version must match, read and write directions must be explicit, and only points the far end needs should go onto cellular. Forwarding a whole bus transparently onto the public network both inflates traffic and exposes field writes. The gateway may judge alarms at the edge, but the report should still keep the original engineering value and a quality flag. The quality flag says this reading is new, stale, or a communication failure. The cloud must not treat a failed reading as zero.
Air-conditioning and fan points common in buildings and mechanical plant must, after mapping, match the names of the HVAC objects. Otherwise the same device is a register number on the protocol side and a plant-room number on the operations side, and an alarm cannot be dispatched. Writes are stricter than reads. A remote change of a setpoint needs permission, a range, and a read-back. Treating a write as successful with no read-back leaves the field at the old value when the mode switch is not in remote.
Polling faster than the delay shifts the time
It is easy for the field to poll on a very short cycle while cellular cannot carry it away. Several samples pile up in gateway memory, and the time of a successful send overwrites the sample time. The moment on the cloud curve becomes the moment the link recovered, and fault analysis is matched to the wrong process step. Each point should carry its sample time. When the queue is full, the drop policy must be explicit: drop the old value or the new one, and count one overflow, rather than overwrite quietly. Another mistake is byte order and scale set backwards. Temperature is scaled up or down by ten, the trend looks like a serious breach, and the point list simply has the wrong decimal place.
Protocols update at different speeds. Merged into one message, a slow point is represented by a fast point's time. Each point should be allowed its own time. If a device address conflicts, or serial parameters change, the gateway still reads another device's registers from the old point list. The value looks "normal" and belongs to the neighbor. For acceptance, change one known register and confirm the cloud engineering value, unit, and quality flag. Then limit the uplink below the poll rate and confirm that timestamps after the pile-up are still sample times, and that overflow is counted. Finally do one remote write. If the read-back does not match, the state must be failure.
A failed quality flag must not become zero
When a field read fails, the uplink message must carry a failed quality flag. The cloud must not display that reading as zero, or hold it as a new normal value. A wrong decimal place on the point list scales temperature up. Check engineering value and unit against one known register. When the queue piles up, each point keeps its own sample time. The time of a successful send is only a transport log. Queue overflow must be counted, and it must say whether the old value or the new value was dropped.
A remote write must be read back. If the read-back does not match the target, that is a failure. It must not show success just because the request was sent. If serial parameters change and the value still looks "normal," suspect that the address now points at the neighboring machine. Slow variables and fast variables must not share one timestamp. After a known point checks out, a rate-limited pile-up checks out, and one failed write checks out, the protocol-conversion uplink means the quantity that was in the field at that time.