Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29182-4 — Sensor Networks: SNRA — Part 4: Entity Models
Layered entity model framework for sensor network architecture design
Understanding Entity Models in SNRA
ISO/IEC 29182-4 defines the entity models that form the structural foundation of sensor network architectures. An entity, in the context of the SNRA, is an abstraction of a physical or logical component that performs a specific role within the sensor network. The standard defines a comprehensive set of entity types organised into layers: the Sensor Layer, the Network Layer, the Service Layer, and the Application Layer. This layering follows the principle of separation of concerns, allowing each layer to evolve independently.
Use the entity models from Part 4 as a checklist during architecture design. For each layer, verify that you have identified the necessary entities and that their interactions are clearly specified. Missing entities at one layer often surface as integration gaps later in the project.
The Sensor Layer entities include sensor nodes, actuators, and gateways that interface directly with the physical environment. The Network Layer entities manage communication, routing, and topology control. The Service Layer entities provide middleware functions such as data storage, event detection, and service discovery. The Application Layer entities implement domain-specific logic that consumes sensor data and generates actionable insights.
Detailed Entity Specifications
Each entity type in the model is specified with a set of attributes, behaviours, interfaces, and relationships. For example, a “Sensor Node” entity has attributes (node ID, location, battery level, sensing capabilities), behaviours (sensing, processing, transmitting, sleeping), interfaces (sensor interface, network interface, management interface), and relationships (belongs to a cluster, communicates with a gateway, is managed by a network manager).
| Layer | Entity Types | Primary Function | Example Instances |
|---|---|---|---|
| Sensor Layer | Sensor Node, Actuator Node, Gateway, Sink Node | Physical phenomenon detection and actuation | Temperature sensor node, smart valve actuator, edge gateway |
| Network Layer | Router, Coordinator, Base Station, Relay Node | Data routing, topology management, QoS enforcement | Mesh router, PAN coordinator, LTE base station |
| Service Layer | Service Registry, Data Repository, Event Manager, Security Manager | Middleware functions, data storage, event processing | Sensor data platform, alarm correlation engine, identity provider |
| Application Layer | Application Agent, Visualisation Component, Decision Support Engine | Domain logic, user interface, analytics | Dashboard application, predictive maintenance engine, mobile app |
Entity models should not be confused with physical device types. A single physical device may implement multiple entities. For example, a smart industrial gateway may simultaneously function as a Sink Node (Sensor Layer), a Router (Network Layer), and a Service Registry (Service Layer). The entity model separates logical concerns, not physical boxes.
Entity Relationships and Composition Patterns
The standard defines several composition patterns that guide how entities are combined to form complete systems. The “Concentrator Pattern” aggregates data from multiple sensor nodes through a gateway. The “Hierarchical Pattern” organises entities into a tree structure with tiered processing. The “Peer-to-Peer Pattern” enables direct communication between sensor nodes without a central coordinator. Each pattern has different implications for scalability, latency, and fault tolerance.
The Concentrator Pattern is particularly effective for environmental monitoring where data volumes are moderate and the primary goal is data aggregation. In contrast, the Peer-to-Peer pattern suits real-time control applications where low latency and high availability are critical, such as industrial automation loops.
The entity model also introduces the concept of “Virtual Entities” — software abstractions that represent physical entities for the purpose of management and interaction. A virtual sensor, for instance, may aggregate readings from multiple physical sensors to provide a more reliable or comprehensive observation. Virtual entities are essential for implementing redundancy, data fusion, and sensor abstraction layers.
Over-abstraction is a real risk. Creating too many virtual entity layers introduces latency and complexity. A good rule of thumb is to limit virtualisation to two levels: one for physical-to-logical mapping and one for logical-to-service mapping. Beyond this, the performance overhead typically outweighs the flexibility benefits.
Frequently Asked Questions
Q: Can the entity model be mapped to a specific implementation technology?
A: Yes. The entity model is designed to be implementation-agnostic but can be mapped to specific technologies. For example, Sensor Layer entities can be implemented as constrained MQTT devices, Service Layer entities as RESTful microservices, and Application Layer entities as web-based dashboards.
A: Yes. The entity model is designed to be implementation-agnostic but can be mapped to specific technologies. For example, Sensor Layer entities can be implemented as constrained MQTT devices, Service Layer entities as RESTful microservices, and Application Layer entities as web-based dashboards.
Q: How does the entity model handle mobility?
A: Mobile entities (e.g., sensors on a drone or a wearable device) are handled through the concept of “dynamic association.” A mobile sensor node associates with different gateways as it moves, and the entity model tracks its location through a location service entity in the Service Layer.
A: Mobile entities (e.g., sensors on a drone or a wearable device) are handled through the concept of “dynamic association.” A mobile sensor node associates with different gateways as it moves, and the entity model tracks its location through a location service entity in the Service Layer.
Q: What is the relationship between entities in Part 4 and objects in an OOP design?
A: The entity model is at a higher level of abstraction than OOP objects. An SNRA entity may be implemented as a collection of objects, a microservice, or even a dedicated hardware module. The entity model focuses on architectural roles and responsibilities, not implementation details.
A: The entity model is at a higher level of abstraction than OOP objects. An SNRA entity may be implemented as a collection of objects, a microservice, or even a dedicated hardware module. The entity model focuses on architectural roles and responsibilities, not implementation details.
