IoT Interoperability in Multi-Vendor Systems

Two products displaying the same protocol logo are not yet an interoperable system. They may use different physical interfaces, protocol roles, optional profiles, address conventions, data types, units, security modes or failure behaviour. A value arriving on a dashboard proves only that one path worked at that moment; it does not prove that the value means the right thing or that the system will fail safely.

For a real project, IoT interoperability is the demonstrated ability of the selected components to exchange and use information correctly for a defined task. The evidence belongs to an exact combination of models, firmware, configuration, point definitions and receiving application. It should not be generalized to every device that shares a standard.

This guide gives buyers, integrators and operators a protocol-neutral specification and acceptance method. It is not a compatibility list and does not certify any unnamed product pair.

The interoperability problem in one example

Suppose a power meter exposes a value that another system must use as three-phase active power.

The link can succeed while the result is still wrong:

• the client reads holding register 40001 when the manual means zero-based offset 0, or offset 1;
• the source stores an IEEE 754 float across two registers in a different word order;
• the raw value is watts but the receiving point is labelled kilowatts;
• the value is total apparent power rather than active power;
• a negative sign means export at the source but fault at the destination;
• the Gateway timestamps receipt after a reconnect, making buffered data look current;
• the destination retains the last value without marking it stale; or
• a write receives a protocol acknowledgement but the equipment rejects, overrides or later reverses the command.

“We can read a register” is therefore an early integration milestone, not acceptance.

Eight layers that must agree

The layers overlap, but separating them makes gaps visible.

The W3C Web of Things architecture illustrates why these concerns are separate: a Thing Description can identify interactions, data schemas, protocol bindings and public security metadata. That description can reduce custom discovery work, but an implementation and its consumers still have to support the same profile and use the described meaning correctly.

Protocol compatibility is narrower than application compatibility

A communication protocol usually standardizes only part of the stack.

Modbus example

Modbus defines function codes and four primary data tables, but a device manufacturer still defines which application value occupies each register, its data type, scaling, byte order and writable behaviour. The official specification also distinguishes a data reference from physical device memory. A successful function-code response does not establish that a manual's 40001 notation and a client's numeric address field use the same base.

Use the register-address translator, register decoder, function and exception reference and RS-485 commissioning guide as separate checks. None can replace the current device map.

MQTT example

MQTT 5.0 defines topics, application messages, properties, sessions and three quality-of-service levels. It does not define the business meaning of an arbitrary payload. Two systems can both support MQTT and disagree about topic hierarchy, schema, point identity, units, timestamps, birth/death state, retained messages or duplicate handling.

QoS describes a delivery relationship between an MQTT sender and receiver. It does not prove that a physical sample was correct, that every sample became a message, or that a downstream database stored the result exactly once.

OPC UA example

OPC UA carries more application context than a bare register or arbitrary message. Its DataValue can associate a value with a StatusCode, source timestamp and server timestamp, and the Data Access model can expose engineering units. A consuming application must still map the intended node, check status before use, preserve the relevant time and agree what to do when the value is uncertain or bad.

Syntactic and semantic interoperability are different

Syntactic interoperability means the receiver can parse the representation. Semantic interoperability means the parties assign compatible meaning to what was parsed.

Consider this valid JSON:

{
  "point": "P_TOTAL",
  "value": 42.7,
  "unit": "kW",
  "time": "2026-09-19T10:15:00Z",
  "quality": "good"
}

It is not yet a complete contract. The receiver still needs to know:

• which physical site, asset and measurement boundary P_TOTAL represents;
• whether it is active power, an interval average or the latest instantaneous result;
• whether positive means import or export;
• how good was derived and when the value becomes stale;
• whether time is source time, calculation time or Gateway receipt time; and
• which configuration, transformer ratio and calculation revision apply.

ETSI SAREF addresses semantic interoperability through shared concepts and mappings rather than requiring every system to discard its own terminology and data model. A project does not have to adopt SAREF to learn from the principle: define a shared meaning once, then map each system to it deliberately. Pairwise field-name translations alone become difficult to govern as the number of systems grows.

Conformance, certification and project acceptance

These forms of evidence answer different questions.

NIST's Smart Grid Interoperability Framework treats conformance and interoperability testing as complementary rather than interchangeable. The oneM2M interoperability test format requires the configuration, initial conditions, event sequence and expected results to be explicit. Product programmes such as BTL Certification can provide useful independent evidence for their stated scope, but the complete project still needs its own point mapping and acceptance record.

A procurement schedule that exposes assumptions

Ask every supplier or integrator to complete the same schedule before equipment is ordered.

Leave an unknown field marked unknown. An empty cell should not silently become a supplier commitment or design assumption.

A twelve-step multi-vendor acceptance test

Run the test with the exact hardware, firmware, interface documents and receiving application intended for the project. Capture raw evidence at the source, intermediary and final destination where possible.

1. Freeze identity and configuration. Record model, serial or stable device identity, firmware, interface revision, Gateway/runtime version, connector version and configuration fingerprint.
2. Prove the physical path. Inspect wiring and topology; verify serial, link and network settings; and demonstrate that the intended endpoints, not a convenient substitute, are communicating.
3. Trace every point. Match each destination point to the source object, register, channel or message and to the physical asset label.
4. Verify encoding. Exercise at least two known non-zero values where practical and check register base, data type, signedness, byte/word order, scale and enumerations.
5. Verify engineering meaning. Confirm unit, direction, measurement boundary, calculation and expected range against a suitable reference or controlled source.
6. Verify time. Compare clocks and source/receiver timestamps, introduce a known delay, and confirm replayed data does not appear current.
7. Verify quality and stale state. Produce a source fault, invalid value and stopped update. The final application must distinguish these from a valid zero.
8. Exercise permitted writes. Test authorization, bounds and interlocks. Record the request, protocol response, observed equipment effect and final reported state; an acknowledgement alone is not proof of effect.
9. Interrupt each link. Break the field connection and onward connection separately. Observe loss detection, last-value treatment, buffering, alarms and local behaviour.
10. Recover and reconcile. Reconnect within and beyond the expected buffer window. Check ordering, duplicates, gaps, cumulative-register reconciliation and stale-state clearance.
11. Restart and restore. Restart each relevant component in turn, then restore from the documented backup. Verify identities, point mappings, clocks, credentials and queued data.
12. Repeat after a controlled change. Apply one approved firmware or configuration change, confirm the change record and rerun the affected tests. Restore or roll back if acceptance fails.

The result should name who observed each step, when it ran, the expected and actual outcome, the captured evidence, every deviation and the person authorized to accept it.

Control interoperability needs a second proof loop

Monitoring ends when the destination can use a trustworthy observation. Control also needs evidence that the permitted physical effect occurred.

A useful command lifecycle is:

1. an authorized requester creates a command with a stable identity, target, value and expiry;
2. the responsible controller validates range, mode, interlocks and current authority;
3. the protocol write or request is attempted;
4. the receiving equipment acknowledges, rejects or times out;
5. an independent readback or process observation confirms whether the intended effect occurred;
6. the system records supersession, manual override or loss of authority; and
7. a defined local state applies when the upstream requester is unavailable.

Never treat a TCP success, MQTT publication or Modbus response as proof that the plant reached the intended state. Safety, protection and equipment-control functions require their own qualified design and must not be delegated to a general monitoring path by implication.

Open standards and vendor lock-in

Open, published standards are valuable because multiple suppliers can implement them and buyers can test against a stable contract. They reduce lock-in only when the surrounding project remains portable.

Check whether the buyer can obtain and reuse:

• the complete point and object map;
• protocol and profile configuration;
• certificates, identities and credential-rotation procedures;
• data and event exports with units, timestamps and quality;
• rules, calculations and semantic mappings in a documented form;
• backups and a tested restore procedure;
• an interface to replace either side without losing historical meaning; and
• support and security-update terms for the required life of the asset.

An “open protocol” behind a proprietary semantic model, undocumented connector or non-exportable configuration can still be expensive to replace. Conversely, a project-specific adapter can be maintainable when its input, output, tests and owner are explicit.

The latest NIST manufacturer guidance also makes cybersecurity support part of the product relationship: buyers need both device capabilities and the information required to use them. Interoperability that depends on abandoned firmware, shared credentials or an unpatchable connector is not a durable result.

Applying the method with EpiSensor

EpiSensor projects can combine wireless field products, supported wired equipment, a Gateway running Edge and an external application. The exact path depends on the selected hardware and installed integrations.

For example:

• the ZMB family connects selected Modbus RTU equipment to the local EpiSensor wireless network;
• Edge can connect supported Modbus TCP/RTU, BACnet/IP and OPC UA sources using the relevant configuration;
• Edge can keep data and rules local on the Gateway; and
• onward flows can map reviewed data to MQTTS, HTTPS, files or another installed interface.

Those capabilities are building blocks, not a universal compatibility promise. Before naming an integration as supported, qualify the exact device, firmware, map, point count, poll or update requirement, write scope, security method, failure behaviour and receiving system.

Start with the BMS, SCADA and meter integration guide, then bring the equipment list and current interface documents into System Builder or a technical enquiry. The useful handoff is a testable integration brief, not a list of protocol logos.

The minimum acceptance statement

Avoid “Device A is compatible with Platform B” unless the scope is genuinely that broad. A defensible statement is narrower:

Model A, firmware X, was tested through interface Y and configuration revision Z into application B, version C. The listed read points, permitted writes, units, timestamps, quality mappings, interruption and recovery cases passed the attached acceptance record on the stated date. Untested options and later versions are not covered.

That wording gives the next integrator something reproducible. It also makes future change review possible: when one version, profile, point map or security requirement changes, the team knows which evidence must be renewed.