IoT System Architecture and Engineering Design

Introduction and Context

An Internet of Things (IoT) system in mechatronics connects physical machines, sensors, actuators, controllers, communication networks, software services, and human operators. Its engineering challenge is not simply attaching a sensor to the Internet. The challenge is allocating functions across devices, gateways, edge computers, and cloud services so that the complete system is safe, responsive, maintainable, secure, scalable, and economically justified.

A mechatronic IoT architecture must bridge two engineering worlds. The physical world is continuous, time-dependent, energy-constrained, and subject to mechanical wear. The digital world is distributed, software-controlled, and vulnerable to communication delay, cyberattack, data loss, and changing interfaces. Good architecture therefore begins with requirements and system behavior, rather than with a fashionable platform or protocol.

A useful architecture separates four computational locations:

1. Device level: sensors, actuators, embedded controllers, and local firmware.
2. Edge level: computation close to machines, often on an industrial computer or embedded server.
3. Gateway level: protocol translation, aggregation, buffering, and secure connection between local networks and wider networks.
4. Cloud or enterprise level: fleet management, long-term storage, analytics, dashboards, model training, and business integration.

These levels are logical roles, not necessarily four separate physical products. A gateway may also perform edge analytics, and a controller may implement limited cloud connectivity. The engineering task is to assign each function to an appropriate location.

Learning Objectives

By the end of this chapter, students should be able to:

• translate stakeholder needs into verifiable IoT system requirements;
• decompose a mechatronic system into functional and physical elements;
• design device–edge–gateway–cloud architectures;
• evaluate latency, bandwidth, availability, resilience, safety, security, and maintainability trade-offs;
• represent architecture using interfaces, deployment views, and data flows;
• apply basic availability and capacity calculations;
• develop a lifecycle-oriented design and validation plan; and
• explain the professional, ethical, and governance responsibilities associated with connected machines.

Requirements Engineering for IoT Systems

Stakeholders and operational context

Stakeholders include machine operators, maintenance technicians, production managers, safety engineers, information-technology staff, customers, regulators, and owners. Each group views the system differently. An operator may require a clear alarm within one second; a maintenance team may require vibration history for twelve months; an IT department may require identity management and network segmentation; and a safety engineer may require that a loss of communication cannot create a hazardous actuator state.

Requirements should describe the required outcome, not prematurely prescribe a technology. “The system shall provide an authenticated maintenance record within five seconds” is more useful than “the system shall use a particular cloud platform.”

Requirement categories

A good requirement is specific, measurable, achievable, relevant, and testable. Each requirement should have an identifier, rationale, owner, verification method, and priority. Requirements also need traceability to architecture elements and tests.

Quality attributes and constraints

IoT projects frequently fail because functional requirements are collected while quality attributes remain implicit. Latency, jitter, availability, energy consumption, cybersecurity, data sovereignty, updateability, and total cost of ownership should be recorded early. Constraints may include an existing programmable logic controller, a restricted wireless spectrum, hazardous-area certification, legacy protocols, or a prohibition on sending production data outside a country.

Functional Decomposition and Allocation

Functional decomposition transforms a broad purpose into smaller functions. For an automated pumping station, the top-level function may be “control and supervise fluid transfer.” It can be decomposed into:

• measure pressure, flow, level, current, and vibration;
• condition and validate measurements;
• control pump speed and valve position;
• detect abnormal states;
• execute local protective actions;
• buffer and transmit records;
• display status and alarms;
• manage identities, configurations, and software updates; and
• analyze historical behavior for maintenance planning.

A function is not the same as a component. “Detect overspeed” is a function; a controller, edge computer, or safety relay may realize it. Allocation should consider timing, safety, connectivity, computational demand, data volume, privacy, and failure consequences.

Allocation principles

Device level is appropriate for deterministic sampling, closed-loop control, signal conditioning, interlocks, and immediate protective action. It minimizes network dependence and usually provides predictable timing.

Edge level is appropriate for machine-learning inference, high-rate signal processing, local dashboards, event correlation, and coordination among nearby devices. It can continue operating during cloud disconnection.

Gateway level is appropriate for protocol conversion, address translation, message normalization, store-and-forward buffering, certificate handling, and traffic filtering.

Cloud level is appropriate for fleet-wide comparisons, long-term storage, model training, enterprise resource planning integration, and software distribution. It is usually unsuitable for a safety-critical control loop because wide-area latency and availability are outside the machine’s immediate control.

A robust rule is: place a function at the lowest level that can satisfy its requirements, then use higher levels for coordination, optimization, and historical insight. This rule is not absolute; cost, maintainability, and certification may change the allocation.

Reference Architecture

Figure: Logical device–edge–gateway–cloud architecture with bidirectional data and control flows.

The reference architecture contains both a data plane and a management plane. The data plane carries measurements, events, commands, and acknowledgements. The management plane handles identities, configuration, certificates, software updates, logging, and policy. Separating these concerns improves security and maintainability.

A typical telemetry path is: sensor → controller → gateway → message broker → time-series storage → analytics dashboard. A command path should include authorization, validity checks, acknowledgement, timeout behavior, and a safe response to failure. Commands should not be treated as ordinary telemetry in either design or security policy.

Interfaces and information models

An interface defines more than a transport protocol. It should specify data types, units, timestamps, quality codes, update rates, error behavior, versioning, and ownership. For example, a temperature value without a unit, sensor location, calibration status, or timestamp is not a dependable engineering datum.

An information model gives consistent meaning to data. “Motor temperature” should identify the motor, measurement point, unit, accuracy, sampling method, and validity state. Semantic consistency allows systems from different vendors to interoperate and prevents dashboards from displaying numerically correct but physically misleading values.

Engineering Trade-offs

Architecture is an optimization problem with competing objectives. Centralized cloud processing simplifies fleet-wide management but depends on connectivity and may increase latency. Edge processing reduces latency and bandwidth but creates more distributed software to maintain. Wireless links reduce installation cost but introduce interference, battery limitations, and variable availability. Redundant equipment improves resilience but increases cost, power consumption, and configuration complexity.

Latency and bandwidth

For a transaction, approximate end-to-end latency can be decomposed as:

Here, each term is a time in seconds: sensor acquisition, computation, queueing, network transmission, remote service processing, and return communication. The expression is an engineering budget, not an exact law. It applies when the stages are sequential and their delays can be estimated. Parallel paths, retransmissions, and scheduling can require a more detailed model. A cloud dashboard may tolerate seconds, whereas a motion-control loop may require deterministic millisecond-scale behavior and therefore belongs locally.

For sampled telemetry, an approximate uncompressed data rate is:

where R is the bit rate in bit/s, N is the number of channels, f is the sample frequency in samples/s per channel, and b is the number of bits per sample. Protocol overhead, headers, retransmissions, and encoding increase the actual rate. If 12 channels are sampled at 100 Hz with 16 bits per sample, the payload rate is 12 × 100 × 16 = 19,200 bit/s, or 19.2 kbit/s, before overhead.

Availability and resilience

Availability is the proportion of required time that a service is operational. For a repairable component under steady conditions:

MTBF is mean time between failures and MTTR is mean time to repair or restore, both measured in the same time unit. The approximation assumes stable failure and restoration behavior and does not capture planned maintenance, common-cause failures, or dependencies.

For two independent components arranged in parallel, where the service works if at least one works:

This formula assumes independent failures and correct switching. It must not be used blindly when both components share power, software, network infrastructure, or environmental hazards.

Worked example. A gateway has an MTBF of 4,000 h and an MTTR of 10 h. Its availability is 4000 ÷ (4000 + 10) = 0.9975, or approximately 99.75%. Two such gateways in genuinely independent parallel operation provide 1 − (1 − 0.9975)² ≈ 0.999994, or approximately 99.9994%. In practice, shared power or a common configuration error may make the real result much lower.

Resilience is broader than availability. It includes resistance to faults, graceful degradation, detection, recovery, adaptation, and learning. Techniques include local autonomy, watchdogs, health monitoring, redundant sensors, fail-safe states, retry limits, store-and-forward queues, backup power, tested recovery procedures, and geographically separate services.

Safety and security

Safety asks whether the system prevents unacceptable physical harm; security asks whether assets and functions are protected from unauthorized or malicious action. They overlap but are not identical. A compromised cloud account may affect production scheduling without directly affecting a safety interlock, while a faulty sensor may create a safety hazard without any cyberattack.

Safety-related functions should be identified through hazard analysis. Typical techniques include preliminary hazard analysis, failure mode and effects analysis, fault-tree analysis, and hazard-and-operability studies. A network-connected monitoring system should never be assumed to replace a certified safety function unless the complete safety lifecycle and applicable standards support that claim.

Security architecture should include unique identities, least privilege, secure boot where appropriate, protected keys, encrypted communication, network segmentation, signed updates, vulnerability management, logging, incident response, and secure decommissioning. Threat modeling should consider spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.

A safe design defines what happens when data are missing, stale, contradictory, or outside physical limits. For example, a controller may reject a command whose timestamp is expired, limit its magnitude and rate of change, and revert to a locally defined safe state when communication is lost.

Systems Modeling and Verification

Architecture descriptions should use multiple complementary views:

• Context view: system boundary, users, external systems, and physical environment.
• Functional view: transformations from inputs to outputs.
• Logical view: software services, data stores, and interfaces.
• Physical or deployment view: processors, networks, sensors, and locations.
• Operational view: normal operation, startup, shutdown, maintenance, and fault response.
• Security and safety views: trust boundaries, hazards, protective barriers, and assumptions.

SysML or UML can represent block definitions, internal blocks, activities, state machines, sequence interactions, and requirements traceability. The notation is less important than consistency. Every important requirement should trace to an architectural element and to a verification activity.

Verification asks whether the system was built correctly; validation asks whether the correct system was built for its intended operational need. Tests should proceed from component and interface tests to integration, system, performance, cybersecurity, environmental, safety, and acceptance testing. Digital twins and simulation can expose timing and control issues before deployment, but simulation models must be validated against physical evidence.

Maintainability and Lifecycle Engineering

IoT systems are socio-technical products with long operational lives. Design must include installation, commissioning, calibration, monitoring, patching, spare parts, training, migration, and retirement. A device that is inexpensive to purchase but difficult to update may create a high lifecycle cost.

Maintainability improves when systems use modular interfaces, documented configurations, remote diagnostics, replaceable components, standardized naming, versioned schemas, automated deployment, and backward-compatible interfaces. A practical design should answer: How is a failed sensor identified? How is a replacement enrolled securely? How is historical identity preserved? How is a bad update rolled back? How is data exported if the vendor service ends?

Total cost of ownership includes acquisition, installation, communications, energy, cloud processing, licenses, cybersecurity, maintenance, downtime, training, and disposal. Open interfaces can reduce lock-in, but they do not automatically guarantee interoperability; semantic definitions and conformance testing remain necessary.

Illustrative Case: Predictive Monitoring of an Industrial Conveyor

Background and problem

A packaging plant operates several conveyors driven by induction motors and gearboxes. Unexpected bearing failures stop the packaging line, while collecting every high-frequency vibration signal continuously to the cloud would consume excessive bandwidth and storage. The plant requires early warning, continued basic operation during Internet outages, and a clear separation between monitoring and emergency protection.

Analysis

Requirements are established as follows: vibration and temperature shall be sampled locally; a preliminary anomaly score shall be generated within two minutes of a scheduled analysis; the conveyor shall continue normal control if the cloud is unavailable; an emergency stop shall remain effective without the IoT platform; and maintenance records shall be traceable to a particular motor and sensor.

The control PLC remains responsible for speed control and interlocks. Sensors connect to an industrial edge computer through a gateway. The edge computer calculates root-mean-square vibration, temperature trends, and anomaly features. Only features, alarms, and selected waveform windows are transmitted to the cloud. The cloud compares assets across the plant and supports model retraining.

Approach and solution

The design uses a local buffer so that records are retained during communication loss. The gateway authenticates devices and applies protocol translation. A command from the cloud cannot directly bypass the PLC’s local limits. The dashboard distinguishes measured values, estimated values, stale values, and alarm states. Software updates are signed, staged on one conveyor, monitored, and capable of rollback.

A failure analysis identifies loss of the edge computer as a monitoring outage but not a loss of emergency stopping. A second edge computer is justified only if the business impact of lost monitoring exceeds its cost; it is not presented as a substitute for a safety system. Acceptance tests inject missing data, excessive vibration, clock errors, network loss, invalid commands, and sensor replacement.

Outcome and learning points

The architecture reduces bandwidth and preserves local operation while enabling fleet-level analysis. Its principal lesson is allocation: time-critical and protective functions remain close to the machine, while computationally intensive and comparative functions are placed at the edge or cloud. The case also demonstrates that an IoT architecture is successful only when operational procedures, cybersecurity, data semantics, and maintenance are designed together.

Contemporary Developments and Professional Practice

Edge artificial intelligence is increasingly used for anomaly detection, machine-vision inspection, and adaptive maintenance. It can reduce latency and protect sensitive raw data, but models may drift as machines, products, and environments change. Engineers should monitor false positives, false negatives, explainability needs, training-data provenance, and safe fallback behavior. An AI prediction must not be treated as a safety decision without suitable assurance.

Event-driven architectures, digital twins, private industrial 5G, time-sensitive networking, and open industrial information models are expanding design choices. These technologies are useful when their measurable benefits justify their complexity. Engineers should avoid technology-first design, untestable claims of “real time,” and cloud dependence for functions that require local determinism.

Governance includes privacy, ownership, retention, access rights, cross-border transfer, auditability, accessibility, and environmental impact. Sensor data may reveal worker behavior or production capability. Collection should be proportionate to a legitimate purpose, and retention should be defined rather than unlimited. Applicable machinery safety, functional safety, electromagnetic compatibility, radio, cybersecurity, data-protection, and industrial-control requirements must be identified for the deployment jurisdiction.

Design Checklist

A preliminary architecture review should ask:

1. Are stakeholders, assumptions, operating modes, and failure consequences explicit?
2. Is every requirement measurable and traceable to a test?
3. Are control, monitoring, safety, and management functions clearly separated?
4. Can the system operate safely during cloud, gateway, sensor, and power failures?
5. Are latency, bandwidth, storage, time synchronization, and capacity budgets quantified?
6. Are interfaces versioned and data units, quality, and timestamps defined?
7. Are identities, trust boundaries, update mechanisms, logs, and recovery procedures designed?
8. Can technicians diagnose, replace, update, and retire components without unsafe improvisation?
9. Have common-cause failures and hidden dependencies invalidated claims of redundancy?
10. Is the architecture economically and environmentally sustainable over its full lifecycle?

Chapter Summary

IoT system engineering in mechatronics is the disciplined allocation of sensing, control, communication, analytics, and management functions across devices, edge computers, gateways, and cloud services. Requirements engineering establishes measurable functional and quality needs, while functional decomposition and allocation determine where each function should execute. Time-critical control and protective functions generally remain local; edge systems provide responsive analytics and autonomy; gateways provide translation and buffering; and cloud systems provide fleet-wide storage, comparison, and enterprise integration.

Architecture decisions must balance latency, bandwidth, availability, resilience, safety, security, maintainability, cost, and lifecycle risk. Availability calculations are useful only when their independence and failure assumptions are realistic. Modeling, traceability, hazard analysis, threat modeling, interface definition, and staged verification convert an architectural concept into an engineered system. Finally, lifecycle governance, secure updates, data semantics, AI limitations, privacy, and decommissioning are part of engineering—not administrative additions.

Key Terms

Requirements engineering: Systematic elicitation, analysis, specification, validation, and management of requirements.

Quality attribute: A non-functional property such as latency, security, availability, or maintainability.

Functional decomposition: Breaking a system purpose into smaller functions and subfunctions.

Device level: The level containing sensors, actuators, embedded controllers, and local firmware.

Edge computing: Processing performed close to the physical source of data.

Gateway: A system that connects networks or protocols and often performs filtering and buffering.

Cloud computing: On-demand remote computing and storage used for scalable services and analytics.

Data plane: Components and paths that carry operational measurements, events, and commands.

Management plane: Functions for identity, configuration, updates, policy, and monitoring.

Information model: Structured definitions that give data consistent meaning and context.

Latency: Time between an event, its processing, and the resulting response.

Availability: Proportion of required time that a service is operational.

Resilience: Capacity to withstand, recover from, and adapt to disruption.

Fail-safe state: A condition designed to reduce hazard when a fault occurs.

Safety: Protection from unacceptable physical harm.

Cybersecurity: Protection of information and systems from unauthorized or malicious actions.

Traceability: Ability to link requirements, design elements, implementation, and evidence.

Digital twin: A digital representation connected to a physical asset or process.

Store-and-forward: Temporary local retention followed by transmission when connectivity returns.

Total cost of ownership: Complete lifecycle cost of acquiring, operating, maintaining, and retiring a system.

Review Questions

Short Answer Questions

1. What are the principal roles of the device, edge, gateway, and cloud levels?
2. Why should safety-critical control generally not depend on cloud connectivity?
3. Distinguish verification from validation in IoT system engineering.
4. What information should accompany a measured temperature value to make it useful?
5. State two differences between safety and cybersecurity.

Long Answer Questions

1. Explain how stakeholder needs can be transformed into traceable and testable IoT requirements.
2. Discuss the factors that should guide allocation of functions between device, edge, gateway, and cloud levels.
3. Explain how resilience differs from availability and describe practical resilience mechanisms.
4. Describe a complete modeling and verification strategy for a connected robotic workcell.
5. Evaluate the lifecycle, governance, and maintainability issues created by dependence on a cloud IoT platform.

Analytical / Application Questions

1. A remote analytics service has an estimated 2 s round-trip delay, while a machine must respond to an overload within 100 ms. Propose an allocation of sensing, decision, and protective action, and justify it.
2. Two gateways each have availability 0.99, but both use the same power supply and network switch. Explain why the parallel availability formula may overestimate system availability and propose mitigations.
3. Design a failure-response sequence for a connected pump when sensor data become stale, the gateway loses Internet access, and a cloud command arrives during the outage. Identify safe states, local functions, logging, and recovery actions.

Multiple Choice Questions with Answers

Question 1

Which function is most appropriately allocated to the device or local controller level?

A. Fleet-wide maintenance comparison

B. Long-term cloud data archiving

C. Immediate protective interlock

D. Enterprise resource planning integration

Correct Answer: C. Immediate protective interlock

Question 2

What is the main purpose of a gateway in a reference IoT architecture?

A. To replace every local safety function

B. To provide protocol translation, buffering, and network connection

C. To eliminate the need for device identities

D. To guarantee that cloud latency is zero

Correct Answer: B. To provide protocol translation, buffering, and network connection

Question 3

A system has 12 channels sampled at 100 Hz with 16 bits per sample. What is the payload rate before overhead?

A. 1.92 kbit/s

B. 19.2 kbit/s

C. 192 kbit/s

D. 1.92 Mbit/s

Correct Answer: B. 19.2 kbit/s

Question 4

In the availability expression A = MTBF ÷ (MTBF + MTTR), what does MTTR represent?

A. Maximum transmission time rate

B. Mean time to repair or restore

C. Mean total routing requirement

D. Minimum tested transfer response

Correct Answer: B. Mean time to repair or restore

Question 5

Which assumption is required by the simple parallel availability formula?

A. All components must fail simultaneously

B. Failures and switching behavior are sufficiently independent and effective

C. The system must have no redundancy

D. Repair time must be zero

Correct Answer: B. Failures and switching behavior are sufficiently independent and effective

Question 6

Which statement best distinguishes validation from verification?

A. Validation asks whether the intended operational need is met; verification asks whether the system was built correctly

B. Validation tests cables only; verification tests users only

C. Validation applies only to cloud systems

D. There is no distinction in systems engineering

Correct Answer: A. Validation asks whether the intended operational need is met; verification asks whether the system was built correctly

Question 7

Why is an information model important in an IoT system?

A. It increases motor torque directly

B. It gives data consistent meaning, units, context, and validity information

C. It removes the need for cybersecurity

D. It guarantees unlimited storage

Correct Answer: B. It gives data consistent meaning, units, context, and validity information

Question 8

Which measure most directly supports secure and controlled software updates?

A. Unsigned firmware downloaded from any source

B. Signed updates with staged deployment and rollback

C. Disabling all system logs

D. Using the same password for every device

Correct Answer: B. Signed updates with staged deployment and rollback

Question 9

In the conveyor case, why are selected features sent to the cloud instead of all high-frequency vibration data?

A. To prevent any local processing

B. To reduce bandwidth and storage while retaining useful diagnostic information

C. To make emergency stopping cloud-dependent

D. To remove the need for sensor calibration

Correct Answer: B. To reduce bandwidth and storage while retaining useful diagnostic information

Question 10

Which statement about artificial intelligence at the edge is most appropriate?

A. An AI prediction automatically qualifies as a safety function

B. Model drift, false decisions, data provenance, and safe fallback must be considered

C. Edge AI eliminates the need for testing

D. AI models never require updating after deployment

Correct Answer: B. Model drift, false decisions, data provenance, and safe fallback must be considered