Adapters, gateways, and protocol translation
Define whether the component forwards transport data, translates a protocol or maps application meaning. Document the fields and behaviour it changes or preserves.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Protocol neutral gateway architecture; exact translation semantics, security properties, capabilities, and failure behaviour come from selected standards and product profiles.
On this page
Overview#
An adapter translates one implementation into a stable internal interface. A gateway additionally terminates trust, identity, sessions, policy, and failure behaviour between zones. Transparent forwarding isn't automatically simpler or safer.
Layered design#
| Layer | Owns | Must not own |
|---|---|---|
| Transport | Connection, TLS, serial/network framing, deadlines | Door/alarm/media business meaning |
| Protocol codec | Message framing, parsing, serialisation, version rules | Vendor independent authorisation policy |
| Session/state | Negotiation, sequence, subscriptions, retry and reconnect | UI specific representations |
| Vendor adapter | Product capability and version quirks | Canonical cross system state |
| Domain service | Cameras, doors, alarms, credentials, events and commands | Raw wire values without provenance |
| Policy/audit | Identity, authorisation, side effect gating, evidence | Silent fallback or protocol guessing |
Canonical capability model#
Represent capabilities explicitly: supported, unsupported, conditionally supported, unknown, disabled by policy, or unavailable in current state. Don't infer a capability from the presence of an endpoint alone. Bind observations to model, firmware, profile/API revision and configuration.
Translation rules#
- Preserve original source, identifiers, times, sequence, quality, units and raw status reference.
- Map only meanings supported by both sides; expose lossy translation as a first class limitation.
- Never invent success when a downstream protocol has only delivery acknowledgement.
- Normalise identifiers without discarding the vendor/native value needed for diagnostics.
- Separate unknown from false, closed, inactive or healthy.
- Define round trip behaviour before supporting configuration writes.
Gateway security#
Terminate and independently authenticate both sides. Apply per direction, per operation authorisation and schema/size validation. A secure upstream protocol doesn't make an unauthenticated downstream bus secure; document the trust breakpoint and compensating controls.
Failure behaviour#
Define startup discovery, partial inventory, downstream outage, upstream outage, stale cache, split brain, duplicate messages, upgrade/version mismatch, queue overflow, clock loss and gateway restart. Physical actuation must default to simulation in documentation examples.
Sources#
- NIST 800 82, NIST SP 800-82 Rev. 3, zones, conduits and OT gateway context, accessed 25 August 2026.