IoT Architectural Models

Introduction

The Internet of Things (IoT) is not a single technology. It is a coordinated system of physical objects, sensing and actuation devices, communication networks, computing resources, data platforms, applications, and human or machine users. An IoT architecture provides a conceptual structure for understanding how these elements interact.

Architecture is important because IoT systems are distributed, heterogeneous, resource-constrained, and often safety-critical. A temperature sensor may use a low-power radio, an edge gateway may filter its measurements, a cloud platform may store and analyse them, and an application may display an alert to a plant operator. If the relationships among these components are poorly designed, the system may be insecure, unreliable, expensive, or impossible to scale.

This chapter examines the principal architectural layers and compares major architectural models: the three-layer model, five-layer model, service-oriented architecture, event-driven architecture, and reference architectures including IoT-A, oneM2M, and the Industrial Internet model.

Learning Objectives

After studying this chapter, you should be able to:

1. Explain the roles of device, network, edge, platform, and application layers.
2. Distinguish logical layers from physical deployment locations.
3. Compare three-layer and five-layer IoT models.
4. Describe service-oriented and event-driven architectural principles.
5. Explain the purpose of IoT-A, oneM2M, and Industrial Internet reference architectures.
6. Select an appropriate architecture for a practical IoT application.
7. Identify important security, governance, interoperability, and scalability concerns.

1. Why IoT Needs Architecture

Traditional information systems commonly involve user interfaces, application logic, databases, and networks. IoT systems add physical processes and devices. They must deal with imperfect sensors, intermittent connectivity, constrained processors, physical safety, time-sensitive events, and data generated at a large scale.

An architecture provides:

• Abstraction: complex implementation details are grouped into understandable layers.
• Modularity: a communication technology can be changed without redesigning every application.
• Interoperability: devices and services from different vendors can exchange information.
• Scalability: the system can grow from a laboratory prototype to thousands or millions of devices.
• Security: trust boundaries and protection responsibilities can be identified.
• Maintainability: faults and upgrades can be isolated to appropriate components.

An architectural layer is a logical responsibility, not necessarily a separate physical computer. For example, a gateway may perform device, network, edge, and platform functions simultaneously. Similarly, a cloud service may contain platform and application functions.

2. Core IoT Layers

A practical five-part view consists of the device, network, edge, platform, and application layers.

Figure: Logical relationships among five common IoT layers. Data commonly moves upward; commands and control decisions move downward.

2.1 Device Layer

The device layer contains the physical “things” that sense, identify, compute, or act. Typical components include temperature sensors, cameras, RFID readers, industrial controllers, smart meters, motors, valves, and wearable devices.

A device may include:

• a sensing or actuation element;
• a microcontroller or processor;
• memory and firmware;
• power management;
• a local communication interface; and
• a device identity or credential.

Sensors convert physical conditions into measurements. An actuator converts a command into a physical action. Measurements are not automatically facts: they may contain noise, bias, missing values, calibration errors, or incorrect timestamps. Device design must therefore consider calibration, sampling, power consumption, environmental protection, and safe failure behaviour.

2.2 Network Layer

The network layer transports data between devices, gateways, platforms, and applications. Technologies may include Ethernet, Wi-Fi, Bluetooth Low Energy, IEEE 802.15.4-based networks, cellular networks, LPWAN technologies, and the Internet Protocol suite.

Important network responsibilities include addressing, routing, connectivity management, congestion handling, and sometimes quality-of-service support. Application protocols such as MQTT, CoAP, HTTP, and AMQP operate above basic link and Internet technologies. The choice depends on payload size, power limits, latency, reliability, security, and communication pattern.

Connectivity does not guarantee interoperability. Two devices may both use IP but still disagree about data representation, identity, commands, or semantics. Interoperability therefore exists at several levels: network, syntactic, semantic, and organisational.

2.3 Edge Layer

The edge layer performs computation near the devices or near the source of data. An edge node may be a gateway, industrial PC, local server, smartphone, or capable controller.

Edge processing can:

• filter redundant measurements;
• aggregate data;
• translate between protocols;
• detect events locally;
• continue operating during cloud disconnection;
• reduce bandwidth and response time; and
• keep sensitive data within a local site.

Edge computing is particularly valuable for closed-loop control. A safety shutdown should not depend entirely on a distant cloud service. However, edge nodes increase the number of systems that require patching, monitoring, backup, and physical protection.

2.4 Platform Layer

The platform layer provides reusable IoT capabilities. It commonly includes device registration, identity management, message ingestion, digital representations of devices, storage, rules, analytics, software update mechanisms, API management, and monitoring.

A platform separates application developers from the details of every sensor and network. For example, an application may request the latest machine temperature through an API without knowing whether the value came from Modbus, Bluetooth, or a cellular device.

Platform design must address data life cycles: collection, validation, storage, processing, sharing, retention, archival, and deletion. It must also distinguish raw data from derived information and preserve provenance when decisions depend on measurements.

2.5 Application Layer

The application layer delivers domain-specific value. Examples include smart irrigation, predictive maintenance, energy management, logistics tracking, remote healthcare monitoring, and building automation.

Applications may present dashboards, generate alarms, recommend actions, issue commands, or integrate IoT data with enterprise systems. A good application expresses the meaning of data in a domain context. “Vibration = 8” is less useful than “bearing vibration exceeds the maintenance threshold.”

Application designers must consider human factors. Excessive alarms create alarm fatigue; unclear visualisations can cause incorrect decisions; and automated control must provide appropriate authority, override, and audit mechanisms.

3. Major Architectural Models

3.1 Three-Layer Architecture

The classic three-layer model contains:

1. Perception layer: sensing, actuation, identification, and interaction with the physical world.
2. Network layer: transmission and routing of data.
3. Application layer: services delivered to users or organisations.

Its strength is simplicity. It is useful for introductory analysis and for showing the basic path from physical observation to application service. Its weakness is that it hides important functions such as edge processing, data platforms, management, security, and business processes inside broad layers.

3.2 Five-Layer Architecture

The five-layer model refines the three-layer model by separating transport, processing, and business concerns. A common version consists of perception, transport, processing, application, and business layers. In practical engineering discussions, the processing layer is often divided into edge and platform functions.

The five-layer model supports more detailed reasoning about storage, analytics, device management, and organisational outcomes. It should not be treated as a universal standard; different textbooks and standards use slightly different names and boundaries.

3.3 Service-Oriented Architecture

Service-oriented architecture (SOA) treats capabilities as services accessible through defined interfaces. A temperature service, device-registration service, identity service, or analytics service can be used by several applications.

Core principles include:

• Loose coupling: consumers depend on interfaces rather than internal implementation.
• Reusability: a service can support multiple applications.
• Composability: larger processes can be formed from smaller services.
• Discoverability: services and their capabilities can be identified through metadata.
• Contract-based interaction: interfaces specify operations, data, errors, and security expectations.

SOA is suitable for heterogeneous IoT environments because it separates device-specific mechanisms from application needs. It also introduces governance requirements. Versioning, service ownership, service-level expectations, authentication, and failure handling must be managed explicitly.

3.4 Event-Driven Architecture

In an event-driven architecture, components communicate through events representing changes or occurrences. Examples include TemperatureExceeded, VehicleArrived, DoorOpened, or MotorFaultDetected.

A producer publishes an event, and one or more consumers respond. A broker may receive, route, persist, and distribute events. This model supports loose coupling and asynchronous operation. Producers do not need to know every consumer, and consumers can be added without modifying the sensor firmware.

Event-driven systems require careful treatment of:

• event identity and timestamps;
• ordering and duplicate delivery;
• delivery guarantees;
• retention and replay;
• schema evolution;
• idempotent processing; and
• security of publishers and subscribers.

An event is not the same as a command. “High temperature detected” reports a condition, whereas “open cooling valve” requests an action. Confusing these concepts can produce unsafe designs.

SOA and event-driven architecture are complementary. A system may expose synchronous services for device management and use asynchronous events for telemetry and alarms.

4. Reference Architectures

A reference architecture is a reusable conceptual structure, vocabulary, and set of design principles. It is not a complete product design. It helps organisations compare systems and avoid incompatible assumptions.

4.1 IoT-A

The Internet of Things Architecture (IoT-A) is a European reference architecture approach that emphasises architectural views, models, and interoperability. Its concepts include the physical entity, virtual entity, IoT service, and service organisation. A physical entity is a real-world object; a virtual entity is its digital representation; and an IoT service exposes capabilities or information related to that entity.

IoT-A is valuable because it separates concerns and encourages semantic descriptions, architectural viewpoints, and systematic analysis of security and trust. It is particularly useful during requirements analysis and conceptual design. Its level of abstraction means that developers still need to select concrete protocols, platforms, and deployment technologies.

4.2 oneM2M

oneM2M is a global standards initiative for a common service layer for machine-to-machine and IoT systems. Its architecture commonly distinguishes application entities, common services entities, and network services entities.

• Application Entity (AE): implements an IoT application, such as fleet monitoring.
• Common Services Entity (CSE): provides reusable functions such as registration, discovery, device management, subscription and notification, data storage, and security.
• Network Services Entity (NSE): provides network-related services to the common service layer.

oneM2M uses a resource-oriented approach. Data and capabilities are represented as addressable resources, and applications interact with common services through standard interfaces. This can reduce dependence on a single network technology or vertical application platform.

4.3 Industrial Internet Reference Architecture

The Industrial Internet Reference Architecture (IIRA), developed through the Industrial Internet Consortium, focuses on industrial systems such as manufacturing, energy, transport, and healthcare. It uses viewpoints to address different stakeholder concerns, including business, usage, functional, and implementation viewpoints.

Industrial systems require more than connectivity. They must address safety, reliability, real-time behaviour, operational technology, information technology, lifecycle management, and cybersecurity. The IIRA therefore encourages analysis of system characteristics, functional domains, communication flows, and deployment decisions.

A typical industrial arrangement may include control devices, an edge or control domain, an operations platform, an enterprise system, and external users. Not every function should be moved to the cloud: hard real-time control and safety functions generally remain close to the process.

5. Comparing the Models

The models answer different questions:

These models should not be selected as mutually exclusive alternatives. A factory may use an IIRA-inspired system structure, oneM2M-like common services, SOA interfaces, event-driven telemetry, and a five-layer implementation view.

6. Selecting an Architecture: An Applied Method

A practical architecture process can follow these steps:

1. Define the physical process and stakeholders. Identify what is being sensed or controlled and who depends on the result.
2. Define quality requirements. Consider latency, availability, safety, privacy, energy, throughput, and cost.
3. Classify data and actions. Separate telemetry, events, commands, configuration, and firmware updates.
4. Place functions. Decide what must occur on the device, at the edge, in a platform, or in an application.
5. Choose interaction styles. Use request-response for direct queries and commands; use events for asynchronous changes and notifications.
6. Specify identity and trust. Assign identities to devices, users, services, and data flows.
7. Plan lifecycle management. Include provisioning, monitoring, updates, replacement, decommissioning, and data deletion.
8. Test failure modes. Consider loss of power, network failure, invalid data, compromised devices, and unavailable cloud services.

7. Illustrative Case: Cold-Chain Pharmaceutical Monitoring

Background

A logistics company transports temperature-sensitive vaccines in refrigerated vehicles. Regulations and product quality require temperatures to remain within a specified range. The company wants real-time visibility without draining battery-powered sensors.

Problem

A simple device-to-cloud design sends every measurement over a cellular connection. It creates high communication costs, depends on coverage, and may not identify a dangerous excursion until the vehicle reaches an area with connectivity.

Analysis

The system has several types of information:

• periodic temperature telemetry;
• immediate temperature-excursion events;
• vehicle location;
• battery status;
• configuration commands; and
• audit records.

Temperature excursions require local action, while long-term analytics can occur in a platform. The system must preserve evidence of measurements and configuration changes.

Approach and Solution

At the device layer, calibrated temperature sensors measure the cargo area and store readings during temporary disconnection. A secure device identity prevents unauthorised devices from joining the system.

At the network layer, a low-power local connection links sensors to a vehicle gateway, while cellular connectivity links the gateway to the platform. The gateway buffers data when coverage is unavailable.

At the edge layer, the gateway validates readings, detects excursions, and activates a local alarm. It publishes a TemperatureExcursion event immediately and aggregates routine readings before transmission.

At the platform layer, device management, data storage, access control, dashboards, notification services, and audit logs are provided. An event broker distributes alerts to logistics staff and quality personnel.

At the application layer, staff view vehicle status, investigate alerts, generate compliance reports, and acknowledge incidents.

Outcome

The architecture reduces unnecessary traffic, provides local response during network outages, and separates operational alerts from historical analytics. It also makes responsibilities clear: sensor calibration belongs to device management, local safety response belongs at the edge, and reporting belongs to the platform and application.

Learning Points

1. Logical layers can be distributed across the same gateway or across many systems.
2. Events are appropriate for urgent excursions, while telemetry supports trend analysis.
3. Edge processing improves resilience but adds maintenance responsibilities.
4. Auditability and data provenance are essential where safety and regulation are involved.

8. Security, Governance, and Ethical Issues

Security must be designed across all layers rather than added only at the application. Important controls include secure boot, signed firmware, unique credentials, encryption in transit, access control, network segmentation, vulnerability management, logging, and secure decommissioning.

Architectures should apply least privilege: a temperature sensor should not have authority to reconfigure an entire fleet. Commands should be authenticated, authorised, validated, and logged. Safety-related commands should fail in a controlled manner and may require human confirmation.

Privacy is also architectural. Location, health, occupancy, and behavioural data can identify individuals. Data minimisation, purpose limitation, retention rules, transparency, and appropriate consent or legal basis should be considered. Organisations must clarify data ownership, processor responsibilities, cross-border transfer requirements, and incident reporting duties according to applicable law and sector regulation.

Artificial intelligence may be used in the platform layer for anomaly detection or predictive maintenance, but it does not remove the need for reliable sensing and human accountability. Models can inherit bias from incomplete data, produce false alarms, or drift when equipment changes. High-impact automated decisions require validation, monitoring, explainability appropriate to the context, and an override process.

9. Contemporary Developments and Best Practices

Current IoT architectures increasingly combine cloud, edge, and device computing rather than choosing one location exclusively. Digital twins provide structured digital representations of physical entities, although a digital twin should not be confused with a simple dashboard or database record. Containerisation and orchestration can package edge services, but constrained devices may require lighter mechanisms.

Interoperability increasingly depends on semantic models, consistent information schemas, open APIs, and strong identity management. Architectures should avoid unnecessary vendor lock-in by documenting interfaces and migration options.

Best practices include:

• begin with physical-process and stakeholder requirements;
• separate logical architecture from deployment architecture;
• use standard, documented interfaces;
• design for intermittent connectivity;
• distinguish telemetry, events, commands, and configuration;
• make services observable through logs, metrics, and traces;
• use secure-by-default provisioning and updates;
• validate time, units, calibration, and data provenance;
• design explicit failure and recovery behaviour; and
• test the complete lifecycle, including retirement.

Chapter Summary

IoT architecture organises devices, communications, computing, data, applications, and organisational processes into understandable responsibilities. The device layer interacts with the physical world; the network layer transports information; the edge layer provides local processing and resilience; the platform layer supplies reusable data and management services; and the application layer delivers domain value.

The three-layer model is simple and foundational, whereas five-layer models provide a more detailed decomposition. SOA emphasises reusable capabilities and contracts, while event-driven architecture emphasises asynchronous communication through events. IoT-A provides conceptual and viewpoint-based guidance, oneM2M standardises common service functions, and IIRA addresses the complex requirements of industrial systems. These models can be combined rather than treated as competitors.

Effective architecture requires attention to latency, availability, energy, security, privacy, interoperability, lifecycle management, safety, and governance. The cold-chain example demonstrates how device, edge, platform, and application responsibilities can be combined to create a resilient and auditable IoT system.

Key Terms

Actuator: A component that produces a physical action in response to a control signal.

Application layer: The layer that provides domain-specific functions and user or organisational services.

Common Services Entity: In oneM2M, a component providing reusable IoT service capabilities.

Device layer: The layer containing sensors, actuators, embedded processors, and physical things.

Digital twin: A digital representation of a physical entity or process, maintained for a defined purpose.

Edge computing: Processing performed near the source of data or physical action.

Event: A recorded occurrence or state change that may be consumed by other components.

Event-driven architecture: An architecture in which components communicate primarily through events.

Gateway: A device that connects networks, protocols, devices, or processing environments.

Interoperability: The ability of systems to exchange and meaningfully use information.

IoT-A: A reference architecture approach for modelling IoT entities, services, and viewpoints.

IIRA: Industrial Internet Reference Architecture for analysing industrial systems and stakeholder concerns.

Network layer: The layer responsible for communication, addressing, and transport.

oneM2M: A standards initiative for a common service layer for M2M and IoT systems.

Platform layer: Reusable services for ingestion, storage, analytics, device management, and APIs.

Reference architecture: A reusable conceptual model that guides system design without being a complete implementation.

Service-oriented architecture: An architecture based on reusable capabilities exposed through defined interfaces.

Sensor: A component that detects or measures a physical condition.

Telemetry: Measurements transmitted from a device or system for monitoring or analysis.

Review Questions

Short Answer Questions

1. What are the principal responsibilities of the edge layer?
2. Why is a logical layer not necessarily a separate physical device?
3. State two differences between telemetry and an event.
4. What is the role of a Common Services Entity in oneM2M?
5. Why are industrial IoT systems often designed with local control functions?

Long Answer Questions

1. Explain the device, network, edge, platform, and application layers using a smart-building example.
2. Compare the three-layer and five-layer IoT architectural models, including their strengths and limitations.
3. Explain how service-oriented and event-driven architectures can operate together in one IoT system.
4. Describe the main concepts and value of IoT-A, oneM2M, and IIRA.
5. Discuss security, privacy, lifecycle, and governance requirements in a large-scale IoT architecture.

Analytical / Application Questions

1. Design a layered architecture for a smart irrigation system. Identify which functions should remain at the edge and justify your decision.
2. A factory loses cloud connectivity for two hours. Analyse which services should continue locally and propose an appropriate event and data-handling strategy.
3. Compare two architectures for fleet monitoring: direct device-to-cloud communication and gateway-based edge processing. Evaluate them for cost, resilience, latency, security, and maintainability.

Multiple Choice Questions with Answers

Question 1

Which layer directly interacts with physical conditions through sensors and actuators?

A. Device layer

B. Platform layer

C. Application layer

D. Business layer

Correct Answer: A. Device layer

Question 2

What is a principal benefit of edge computing in an IoT system?

A. It eliminates the need for device identities

B. It enables local processing and faster responses

C. It guarantees unlimited storage

D. It replaces all application software

Correct Answer: B. It enables local processing and faster responses

Question 3

Which model is primarily associated with reusable capabilities exposed through defined interfaces?

A. Three-layer architecture

B. Event-driven architecture

C. Service-oriented architecture

D. Perception architecture

Correct Answer: C. Service-oriented architecture

Question 4

Which statement best distinguishes an event from a command?

A. An event reports an occurrence, while a command requests an action

B. An event is always synchronous, while a command is always wireless

C. An event can only contain numeric data, while a command cannot

D. An event requires a human, while a command never does

Correct Answer: A. An event reports an occurrence, while a command requests an action

Question 5

In oneM2M, what is the main role of a Common Services Entity?

A. To manufacture sensors

B. To provide reusable IoT service functions

C. To replace every network router

D. To perform only physical actuation

Correct Answer: B. To provide reusable IoT service functions

Question 6

Which reference architecture is specifically focused on industrial systems and stakeholder viewpoints?

A. IIRA

B. HTML

C. Bluetooth architecture

D. Three-layer model

Correct Answer: A. IIRA

Question 7

A gateway detects a dangerous temperature excursion while cellular service is unavailable. Which architectural capability is being demonstrated?

A. Local edge resilience

B. Application-only processing

C. Removal of all network requirements

D. Database normalisation

Correct Answer: A. Local edge resilience

Question 8

Which issue is most directly related to semantic interoperability?

A. Whether systems assign compatible meaning to exchanged data

B. Whether a battery is physically rechargeable

C. Whether a screen has sufficient brightness

D. Whether a cable is the correct colour

Correct Answer: A. Whether systems assign compatible meaning to exchanged data

Question 9

Why should an IoT architecture distinguish commands from telemetry?

A. Commands request actions, whereas telemetry reports measurements or states

B. Telemetry is always encrypted, whereas commands cannot be encrypted

C. Commands are used only in consumer devices

D. Telemetry never requires timestamps

Correct Answer: A. Commands request actions, whereas telemetry reports measurements or states

Question 10

Which design practice best supports secure IoT lifecycle management?

A. Using shared permanent passwords for all devices

B. Disabling software updates after deployment

C. Using unique identities and signed firmware updates

D. Allowing every device unrestricted network access

Correct Answer: C. Using unique identities and signed firmware updates