Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29182-5 — Sensor Networks: SNRA — Part 5: Interface Definitions
Standardised interface specifications for interoperable sensor network entities
Interface Architecture in SNRA
ISO/IEC 29182-5 defines the interfaces between entities in the Sensor Network Reference Architecture. Interfaces are the contract points where entities interact, exchanging data, control commands, and management information. The standard identifies several categories of interfaces: sensor interfaces (between physical sensors and processing elements), network interfaces (between communication entities), service interfaces (between middleware components), and application interfaces (between applications and the sensor network platform).
Clear interface specification is the single most important factor in successful multi-vendor sensor network integration. Part 5 provides templates and guidelines for specifying interfaces at the right level of detail — enough to ensure interoperability without constraining implementation freedom.
Each interface in the SNRA is defined by its syntax (message format, encoding, protocol), its semantics (the meaning of exchanged information), and its non-functional characteristics (latency, reliability, throughput). The standard emphasises the importance of semantic interoperability: two entities may use the same protocol syntax but interpret the data differently if the semantics are not standardised.
Interface Categories and Specifications
The Sensor Interface category covers the connection between physical sensing elements and the processing subsystem. This includes analog-to-digital conversion parameters, sampling rates, calibration data exchange, and trigger mechanisms. The Service Interface category defines how service-layer entities interact — for example, how a service registry communicates with a service consumer, including discovery messages, subscription requests, and notification delivery.
| Interface Category | Entities Involved | Key Specifications | Typical Protocol |
|---|---|---|---|
| Sensor Interface (SI) | Sensor element → Sensor node processor | Signal type, sampling rate, resolution, calibration | I2C, SPI, UART, analogue voltage |
| Network Interface (NI) | Sensor node → Router/Gateway | MAC protocol, addressing, QoS marking, security | IEEE 802.15.4, LoRaWAN, BLE, Wi-Fi |
| Service Interface (SvI) | Service registry ↔ Service consumer | Discovery, subscription, notification, security token exchange | REST/HTTP, CoAP, MQTT, OPC UA |
| Application Interface (AI) | Application ↔ Service platform | Data query, command injection, event subscription, data format | REST API, WebSocket, gRPC, GraphQL |
| Management Interface (MI) | Management entity ↔ Managed entity | Configuration, status monitoring, fault reporting, software update | NETCONF, SNMP, LwM2M, TR-069 |
A frequent source of integration failures is mismatched interface assumptions. The sensor vendor might assume a 10 Hz sampling rate while the application expects 100 Hz, or the network interface might support only unicast while the service layer requires multicast. Part 5 mandates explicit documentation of all interface assumptions in an Interface Assumption Table.
Interface Design Patterns and Best Practices
The standard advocates for several design patterns in interface specification. The “Layered Interface Pattern” separates interfaces into technology-dependent and technology-independent layers, allowing the core service interface to remain stable even when the underlying communication technology changes. The “Callback Pattern” enables asynchronous notification delivery, which is essential for event-driven sensor applications. The “Proxy Pattern” allows an intermediary entity to translate between different interface protocols, enabling legacy device integration.
The Layered Interface Pattern has proven particularly valuable in smart city projects where communication technologies evolve rapidly. By separating the application interface (stable REST API) from the network interface (adapting as LPWAN, 5G, or Wi-Fi technologies change), cities have avoided costly application rewrites.
Interface versioning is another critical aspect covered in Part 5. The standard recommends semantic versioning (major.minor.patch) for all interfaces, with clear rules for backward compatibility. A major version change indicates breaking changes that require coordinated upgrades across all dependent entities, while minor versions add functionality without breaking existing consumers.
Never deploy a new major interface version without a coexistence strategy. Part 5 recommends running the old and new interface versions in parallel for at least one full maintenance cycle. Several industrial accidents have been traced to interface version mismatches during rolling upgrades.
Frequently Asked Questions
Q: Does ISO/IEC 29182-5 define specific wire protocols?
A: No. Part 5 defines interface semantics and requirements but does not mandate specific protocols. It provides guidance on protocol selection and defines the information elements that must be exchanged, leaving the concrete protocol choice to implementers.
A: No. Part 5 defines interface semantics and requirements but does not mandate specific protocols. It provides guidance on protocol selection and defines the information elements that must be exchanged, leaving the concrete protocol choice to implementers.
Q: How does Part 5 handle security at the interface level?
A: The standard requires that each interface specification include a security section covering authentication, authorisation, integrity protection, and confidentiality. The specific security mechanisms (TLS, DTLS, OSCORE, etc.) are selected based on the interface’s threat model and performance constraints.
A: The standard requires that each interface specification include a security section covering authentication, authorisation, integrity protection, and confidentiality. The specific security mechanisms (TLS, DTLS, OSCORE, etc.) are selected based on the interface’s threat model and performance constraints.
Q: Can new interfaces be added to the SNRA?
A: Yes. The interface framework is extensible. Organisations can define domain-specific interfaces following the same specification templates. The key requirement is that custom interfaces must not conflict with or duplicate the functionality of standard interfaces.
A: Yes. The interface framework is extensible. Organisations can define domain-specific interfaces following the same specification templates. The key requirement is that custom interfaces must not conflict with or duplicate the functionality of standard interfaces.
Q: What documentation is required for each interface?
A: The standard recommends an Interface Specification Document containing: interface identifier, entities involved, message formats, data types, sequence diagrams, error handling, security provisions, QoS guarantees, and version history.
A: The standard recommends an Interface Specification Document containing: interface identifier, entities involved, message formats, data types, sequence diagrams, error handling, security provisions, QoS guarantees, and version history.
