Principles and Suitable Contexts
Modbus uses a data model that needs an accompanying register map. MQTT transports messages through a broker but does not define payload meaning. OPC UA provides information models and services according to profiles. Their suitability depends on existing systems, request-response or publish-based communication, and the security context.
A protocol defines communication rules but does not ensure everyone understands a number identically. Modbus needs each register's meaning; MQTT brokers route messages by topic; OPC UA may supply structure and quality through selected services. Consult actual-model manuals and profiles rather than treating a shared protocol name as immediate interoperability. Communication agreement and agreement about physical quantities are distinct requirements.
IEC 61850 concerns power-system information modelling and engineering, not a generic replacement for transmitting numbers. Start selection with meanings to preserve: units, time, quality and read/write authority, then examine existing-system load. Cross-protocol conversion can lose those meanings and therefore needs a mapping table. Successful message receipt alone is not a sufficient acceptance criterion for data integration.
Scroll the diagram horizontally to inspect all details.
Design and Data Preparation
Collect manuals for the actual models, including addresses, data types, byte order, scaling and units. Align device identifiers and timestamps. For MQTT, define topics, schemas and retained-message policies. Use a test network before connecting to OT, and restrict read and write access according to permissions.
An address identifies a data location, datatype its representation, byte order its byte sequence, and scale the conversion multiplier. Check all four before interpreting records. Map source locations to destination names using known examples. Begin with approved read-only permissions and never experimentally write live registers to discover what they do. Unknown register behaviour belongs in the test plan, not an unauthorised machine experiment.
For MQTT, define payload content with topic, schema version, measurement time and record identifier. For OPC UA, verify the types, quality status and service permissions actually used. When converting into a common format, document what survives and what is lost. Have an independent reviewer compare values against an authorised source before reporting them; a complete-looking record can still omit essential source semantics.
Failure Cases and Limitations
An incorrect word order may produce plausible but wrong values. Retained messages may contain old readings, and MQTT QoS does not automatically make database side effects occur exactly once. A successful connection only establishes communication; it does not establish that the receiver interprets the data correctly.
Word order describes the sequence of groups forming a multi-register value. Reversal can corrupt numbers without a communication error. A retained message is stored by the broker for new subscribers, so inspect measurement time before displaying it as current. Quality of Service, or QoS, governs MQTT delivery behaviour; it does not by itself guarantee that a destination business transaction cannot execute twice.
Excessive polling can burden legacy devices, while slow polling can miss brief events. Choose intervals within owner-confirmed constraints. If conversion loses units or quality, send an explicit limited-status record rather than a seemingly complete number. Testing must not disturb live operational technology. General-protocol monitoring must not be represented as an instrumented safety system, interlock or emergency shutdown channel.
Trial and Evaluation Methods
Test known positive, negative and fractional values. Check disconnections, duplicates and stale readings. Use tools authorised by the system owner while limiting network load. Measure completeness from the source through to the destination rather than relying only on the number of successfully transmitted packets.
Create tests with known raw messages and converted values so addresses, datatypes and byte sequences can be checked independently. Verify that retransmissions retain identifiers and do not increment totals twice. When testing new topic subscriptions, check the age of immediately received messages. Include bad-quality states to prove that the destination preserves them rather than converting them into ordinary measurements that happen to look plausible.
Acceptance should name tested profiles and device models, preserving semantic mappings and unresolved constraints. Report age and disconnect behaviour with recorded workload size. Specifications provide design rules and review methods; they do not establish that a particular product supports every listed protocol. A limited experiment neither certifies general interoperability nor benchmarks performance with other systems that have not actually been tested.
Scroll the diagram horizontally to inspect all details.
Review Checklist
- Confirm the actual model and profile.
- Maintain schemas and register maps.
- Separate measurement time from receipt time.
- Do not expose OT services directly to the public internet.
References and Further Reading
References explain technology principles or requirements. They do not establish product certification or support for every requirement.