Foundations of Embedded Systems and IoT

Introduction

Computing is increasingly embedded within physical objects, industrial equipment, infrastructure and consumer products. A modern device may sense its environment, execute control software, communicate with other devices or cloud services, and act upon the physical world. Embedded systems, the Internet of Things (IoT), cyber-physical systems (CPS) and machine-to-machine (M2M) communication provide related—but not interchangeable—ways of describing such systems.

For electronics and communication engineers, understanding these distinctions is essential. A successful product must do more than execute correct software: it must satisfy timing, energy, reliability, safety, cost, security, communication and lifecycle constraints. This chapter establishes the conceptual and engineering foundation needed to analyze such systems.

Learning Objectives

After completing this chapter, a student should be able to:

• define embedded systems, IoT, CPS and M2M communication;
• distinguish these concepts and explain how they may overlap;
• identify major characteristics and design constraints of embedded devices;
• interpret feedback control and IoT reference architectures;
• explain the device-to-cloud value chain;
• perform elementary timing, energy, availability and data-volume calculations;
• evaluate major IoT application domains;
• identify security, privacy, safety, governance and lifecycle concerns; and
• propose a defensible architecture for a basic connected embedded application.

1. Embedded Systems

An embedded system is a computing system integrated into a larger product or process to perform a defined set of functions. Unlike a general-purpose computer, it is normally designed for a particular application and operates under application-specific constraints.

Typical components include:

• a microcontroller, microprocessor, digital signal processor or programmable logic device;
• program and data memory;
• sensors and signal-conditioning circuits;
• actuators and power drivers;
• communication interfaces;
• power-supply and energy-management circuits; and
• real-time or non-real-time software.

Examples include a digital camera controller, automotive anti-lock braking controller, pacemaker, router, smart electricity meter and industrial motor drive.

1.1 Characteristics

Embedded systems commonly exhibit the following characteristics:

Dedicated functionality: The system is optimized for a limited set of functions rather than arbitrary user programs.

Interaction with the physical world: Sensors acquire temperature, pressure, acceleration, light or other variables, while actuators influence motors, valves, heaters or displays.

Resource constraints: Processing capacity, memory, communication bandwidth and energy may be tightly limited.

Timing requirements: Correctness may depend on producing the correct result before a deadline.

Long operational life: Industrial, automotive and infrastructure devices may remain in service for years or decades.

Dependability requirements: Failures may cause financial loss, environmental damage or injury.

Limited user interface: Many devices operate without a keyboard or conventional display.

1.2 Reactive and Real-Time Operation

A reactive system continuously responds to external events. A real-time system is one in which correctness depends on both the logical result and the time at which it is produced.

• A hard real-time deadline must not be missed because a miss may cause an unacceptable failure.
• A firm real-time result has little or no value after its deadline, although occasional misses may be tolerable.
• A soft real-time deadline can occasionally be missed with a reduction in service quality.

For a serial sensing-to-action path, an engineering latency budget may be written as:

Here, L_sense is sensor acquisition time, L_queue is waiting time, L_comm is communication delay, L_compute is computation time and L_actuate is the delay until an actuator command takes effect. All terms must use the same unit, such as milliseconds. This additive expression applies when the stages occur sequentially; parallel or pipelined execution requires a more detailed timing model.

A deadline D is satisfied only if the relevant worst-case latency, including an engineering margin, obeys L_total ≤ D. Average latency is insufficient for verifying a hard deadline.

1.3 Feedback Control

Many embedded systems form a closed feedback loop. A sensor measures the physical process, a controller compares the measurement with a desired reference, and an actuator changes the process. Disturbances can affect the process independently of the controller.

Figure: A closed-loop embedded system in which measured output is fed back to the controller.

This figure is a genuine feedback loop: information returns from the sensor to the controller, while control action travels through the actuator to the physical process.

2. IoT, CPS and M2M Communication

2.1 Internet of Things

The Internet of Things is a system of identifiable physical entities equipped with sensing, computation, communication or actuation capabilities and connected through networks to exchange data and deliver services. IoT commonly includes edge devices, gateways, Internet or enterprise networks, platforms, applications and operational processes.

An IoT system is therefore not merely a sensor connected to Wi-Fi. It includes the complete service required to transform observations into useful decisions or actions.

2.2 Cyber-Physical Systems

A cyber-physical system tightly integrates computation, networking and physical processes. Its defining feature is coordinated interaction between cyber components and physical dynamics, often through feedback loops.

CPS engineering emphasizes timing, control stability, physical models, concurrency, safety and dependable operation. Autonomous vehicles, robotic production cells and smart power grids are major examples.

Not every embedded system is a CPS. A simple electronic greeting card contains embedded computation but normally lacks substantial interaction with a dynamic physical process. Similarly, a CPS need not be connected to the public Internet.

2.3 Machine-to-Machine Communication

Machine-to-machine communication is the automated exchange of information between machines with little or no direct human intervention. M2M may use serial links, fieldbuses, private radio, cellular networks or Internet protocols.

M2M describes a communication relationship rather than a complete architecture. A programmable logic controller communicating with a motor drive over an industrial fieldbus is M2M even if neither device uses the Internet or a cloud platform.

2.4 Relationship Among the Concepts

These categories overlap but do not form a simple hierarchy.

A connected thermostat may simultaneously be an embedded system, part of an IoT service, a CPS component and an M2M endpoint. In contrast, an anti-lock braking controller can be an embedded CPS without being an IoT device. M2M communication can occur within either IoT or non-IoT systems; it should not be represented as belonging exclusively to CPS.

3. Design Constraints and Engineering Trade-offs

Embedded and IoT engineering is multi-objective. Improving one property may degrade another: stronger cryptography consumes computation and energy; frequent sampling increases observability but also traffic and power consumption; redundancy improves availability but increases cost.

3.1 Processing and Scheduling

For n independent periodic tasks on one processor, a basic utilization measure is:

Here, C_i is the worst-case processor execution time of task i, T_i is its period, and U is dimensionless. The condition U ≤ 1 is necessary for a single processor but is not sufficient under arbitrary scheduling, blocking or deadline assumptions.

For independent, preemptible periodic tasks with deadlines equal to periods and negligible scheduling overhead, earliest-deadline-first scheduling on one processor is feasible when total utilization is no greater than 1. Real systems must additionally account for interrupts, resource locking, communication and measured or analytically bounded execution times.

3.2 Energy and Battery Life

The energy consumed across operating modes is:

In this expression, P_k is power in watts during mode k, t_k is time in seconds and E is energy in joules. Since 1\ W = 1\ J/s, the equation is dimensionally consistent.

For a periodic device operating at approximately constant supply voltage, average current can be estimated by:

Here, I_k is mode current, t_k is time spent in that mode, and T = \sum t_k is the cycle duration. An approximate battery runtime is:

The battery capacity Q_usable must be in ampere-hours and I_avg in amperes, producing time in hours. This approximation assumes a compatible voltage and load profile. Temperature, self-discharge, conversion losses, battery ageing, pulse-current limitations and capacity-rate effects can reduce actual runtime.

Worked Example: Duty-Cycled Sensor

A sensor draws 24 mA for 0.2 s and 18 μA, or 0.018 mA, for the remaining 59.8 s of each 60 s cycle.

A 2400 mAh battery is derated to 80% usable capacity, giving Q_usable=1920\ mAh. Therefore:

This is a design estimate rather than a guaranteed service life.

3.3 Memory, Bandwidth and Data Volume

Memory requirements include program storage, static data, communication buffers, task stacks and retained records. Engineers should analyze worst-case buffer occupancy rather than only typical use.

If N devices each send S payload bytes at a rate of r messages per second for time t, aggregate payload volume is:

The result is in bytes when S is in bytes and t is in seconds. Protocol headers, retransmissions, acknowledgements, encryption overhead and metadata must be added separately.

3.4 Reliability and Availability

Reliability is the probability that a system performs correctly for a specified interval under stated conditions. Availability is the proportion of time that a repairable system is operational.

For a system alternating between operating and repair states, steady-state availability can be estimated as:

MTBF is mean time between failures and MTTR is mean time to repair; both must use the same time unit. The expression assumes representative long-run averages for the operating and repair intervals. It does not by itself describe safety, data integrity or failure consequences.

For example, MTBF=1000\ h and MTTR=2\ h give A=1000/1002≈0.998004, or approximately 99.8004% availability.

3.5 Additional Constraints

Other major constraints include:

• unit and development cost;
• physical size, mass and enclosure design;
• operating temperature, humidity, vibration and electromagnetic interference;
• regulatory certification;
• maintainability and remote update capability;
• interoperability with existing systems;
• safety and cybersecurity assurance; and
• component availability over the product lifecycle.

4. Reference Models and Architectures

A reference model separates system concerns so that engineers can reason about interfaces, responsibilities and threats. It is a conceptual tool rather than a mandatory implementation.

4.1 Three-Layer IoT Model

The widely used three-layer model consists of:

1. Perception layer: sensors, actuators, identification mechanisms and local acquisition;
2. Network layer: gateways, routing, communication links and transport; and
3. Application layer: domain-specific services and user-facing functions.

Its strength is simplicity, but it combines many distinct platform and business concerns.

4.2 Five-Layer Model

A more detailed model adds processing and business concerns:

1. Perception layer: observes and affects physical entities.
2. Transport layer: moves data using wired or wireless networks.
3. Processing or middleware layer: performs device management, storage, message brokering, analytics and service discovery.
4. Application layer: supports healthcare, industrial, agricultural or other applications.
5. Business layer: covers governance, policy, business processes, performance indicators and monetization.

Security, privacy, identity and management are cross-layer concerns. Treating security as a single additional layer is misleading because every component requires protection.

4.3 Edge, Fog and Cloud Computing

Edge computing performs computation at or near the data source. It reduces latency, bandwidth consumption and dependence on remote connectivity.

Fog computing distributes services across intermediate local or regional nodes, such as gateways or on-premises servers.

Cloud computing provides elastic storage, analytics and application services in centralized data centers.

A well-designed system assigns each function according to latency, privacy, availability, energy and computational requirements. Emergency shutdown should normally remain local; long-term fleet analytics may be cloud-based.

5. Device-to-Cloud Value Chain

The device-to-cloud value chain explains how physical observations become operational or economic value.

Figure: End-to-end device-to-cloud value chain with a return path for decisions and control.

5.1 Device and Perception Functions

The device converts physical variables into digital data, performs calibration and filtering, timestamps observations and may execute local control. Device identity and a hardware root of trust can support secure onboarding.

5.2 Gateway and Connectivity

A gateway may aggregate devices, translate protocols, enforce policy, cache data and provide local analytics. Connectivity choices include Ethernet, Wi-Fi, Bluetooth Low Energy, IEEE 802.15.4-based networks, cellular systems and low-power wide-area networks. Selection depends on range, data rate, power, mobility, topology, spectrum and cost.

5.3 Messaging and Platform Services

Application protocols such as MQTT, CoAP and HTTP provide different interaction models. MQTT uses a broker-mediated publish/subscribe model; CoAP is designed for constrained environments and commonly uses request/response semantics; HTTP integrates readily with web systems but can impose greater overhead.

Platforms typically provide device registries, authentication, message ingestion, digital representations, storage, rules, monitoring and over-the-air update services.

5.4 Analytics and Operational Value

Raw data has limited value unless converted into information and action. Analytics may include threshold detection, trend analysis, anomaly detection, optimization or machine learning. Value can appear as reduced downtime, lower energy consumption, improved safety, traceability or new services.

A technically functional system can still fail commercially if installation, maintenance, integration and governance costs exceed the value produced.

6. Major Application Domains

Industrial IoT

Industrial IoT supports predictive maintenance, asset tracking, quality control and production optimization. Deterministic timing, legacy integration, safety and long equipment lifetimes are important.

Smart Energy and Utilities

Applications include smart metering, demand response, distribution automation and renewable-energy coordination. Designs must protect critical infrastructure and customer consumption data.

Healthcare and Wearables

Connected medical devices can support remote monitoring, diagnostics and medication management. Accuracy, patient safety, privacy, informed consent and regulatory approval are central.

Transportation and Logistics

Fleet telemetry, intelligent transport systems, cold-chain monitoring and connected vehicles use location, environmental and diagnostic data. Intermittent connectivity and cybersecurity must be anticipated.

Smart Buildings and Cities

Building automation, traffic monitoring, lighting and environmental sensing can improve efficiency. Risks include surveillance, vendor lock-in and public infrastructure dependency.

Agriculture and Environment

Soil sensing, irrigation control, livestock monitoring and pollution measurement often require wide coverage, solar power, rugged equipment and operation with limited connectivity.

7. Illustrative Case: Connected Irrigation System

This is a fictional but technically realistic case.

Background and Problem

A cooperative operates 20 irrigation zones. Fixed watering schedules waste water because soil conditions vary. Cellular coverage is intermittent, and sensor nodes must operate for at least two years without routine battery replacement.

Analysis

Each zone has ten sensor nodes, giving 200 nodes. Every node sends a 64-byte application payload once every five minutes. There are 12 transmissions per hour and 288 per day.

Thus, daily application payload is 3.6864 MB using decimal megabytes. Actual network traffic will be greater because headers, security fields, acknowledgements and retransmissions are excluded.

Cloud-only control is unsuitable because a network outage could prevent timely valve operation. Conversely, retaining all analysis locally would make long-term optimization and fleet management difficult.

Approach and Solution

Each node measures soil moisture and battery voltage. Low-power radio connects nodes to a solar-powered field gateway. The gateway performs range validation, stores readings during outages and executes local irrigation rules. A cloud platform stores historical data, visualizes trends and recommends revised moisture thresholds.

Valve commands require authenticated messages and freshness protection to prevent replay. The gateway refuses commands outside safe duration limits. Firmware images are digitally signed, updates are staged, and devices can revert to the previous image after a failed update. Manual valve control remains available.

Outcome

The design review projects that local control will maintain basic irrigation during Internet outages, while cloud analytics will support seasonal optimization. The calculated payload is modest, but battery life remains sensitive to retransmissions and radio wake time. A pilot is required to measure link quality, soil-sensor drift and actual water savings; these outcomes cannot be inferred from architecture alone.

Learning Points

• Partitioning between edge and cloud should follow operational requirements.
• Payload calculations must not be confused with total network traffic.
• Actuation requires stronger safety controls than passive monitoring.
• Offline behavior, update recovery and manual override are architectural requirements.
• Claimed economic or environmental benefits require field evidence.

8. Security, Safety, Ethics and Governance

IoT systems expand the attack surface because physical devices, radio links, gateways, platforms, applications and supply chains can all be targeted.

Core security objectives include confidentiality, integrity, availability, authenticity and accountability. Recommended controls include unique device identities, least-privilege authorization, encrypted communication, secure boot, signed updates, protected key storage, logging, vulnerability management and secure decommissioning.

Security and safety are related but distinct. Security addresses malicious or unauthorized actions; safety addresses unacceptable physical harm, including harm produced by accidental faults. A secure system may still contain unsafe control logic, while a functionally safe device may be vulnerable to hostile commands.

Privacy engineering should apply data minimization, purpose limitation, retention controls and access transparency. Location, health and household activity data can reveal sensitive behavior even when direct identifiers are removed.

Governance defines responsibility for data ownership, algorithmic decisions, software updates, incident reporting and end-of-life support. Applicable obligations vary by jurisdiction and domain but may include data-protection law, radio-spectrum rules, electromagnetic-compatibility requirements, product safety regulation and medical or automotive certification.

Environmental governance is also relevant. Short support periods, sealed batteries and premature cloud-service termination can create electronic waste. Designers should consider repairability, energy consumption, material selection and responsible disposal.

9. Contemporary Developments

Tiny machine learning places compact inference models on microcontrollers. It can reduce latency and data transmission but is constrained by memory, energy and model robustness.

Digital twins maintain digital representations of assets or processes. Their usefulness depends on model validity, current data and clearly defined synchronization—not merely on visualization.

Matter and other interoperability initiatives seek to reduce fragmentation in connected products. Interoperability still requires consistent data semantics, lifecycle management and security policies.

Private cellular and time-sensitive networking support industrial communication requirements, although deterministic end-to-end performance depends on the complete architecture rather than a single network technology.

Post-deployment learning and adaptive systems introduce governance questions concerning model drift, validation and accountability. Safety-critical adaptation requires controlled assurance processes.

10. Engineering Best Practices

1. Begin with physical and operational requirements, not a preferred technology.
2. Define normal, degraded, offline and failure behavior.
3. Allocate timing, energy, memory and bandwidth budgets early.
4. Keep safety-critical control local when remote connectivity is not dependable.
5. Use open, documented interfaces and explicit data semantics.
6. Build security into identity, boot, communication, updates and decommissioning.
7. Measure worst-case behavior as well as average performance.
8. Design for observability through logs, health metrics and diagnostics.
9. Plan for component obsolescence, certificate renewal and long-term updates.
10. Validate claimed outcomes with representative field trials.

Chapter Summary

An embedded system is dedicated computing integrated into a larger product, whereas IoT describes connected physical entities and end-to-end services. CPS emphasizes coordinated interaction between computation and physical processes, while M2M denotes automated communication between machines. These concepts overlap, but none is universally a subset of another.

Embedded and IoT design requires simultaneous management of timing, energy, processing, memory, bandwidth, cost, reliability, safety and security. Reference models separate perception, transport, processing, application and business responsibilities, while edge, fog and cloud computing provide alternative locations for computation. The device-to-cloud value chain links sensing and connectivity to platforms, analytics, decisions and physical action. Successful systems must also address privacy, regulation, interoperability, lifecycle support and measurable stakeholder value.

Key Terms

Embedded system: Dedicated computing integrated into a larger device or process.

Internet of Things (IoT): Networked physical entities and services that sense, exchange data or act.

Cyber-physical system (CPS): Tight integration of computation, communication and physical processes.

Machine-to-machine communication (M2M): Automated information exchange between machines.

Sensor: Component that converts a physical quantity into a usable signal.

Actuator: Component that converts a command into physical action.

Real-time system: System whose correctness depends on result and timing.

Feedback: Return of measured process output to influence control action.

Latency: Time between an initiating event and the relevant response.

Duty cycle: Fraction of an operating cycle spent in a particular mode, often the active mode.

Reliability: Probability of correct operation for a specified interval under stated conditions.

Availability: Long-run proportion of time a repairable system is operational.

Edge computing: Computation performed at or near the data source.

Gateway: Intermediary that aggregates, secures or translates device communication.

Middleware: Services supporting messaging, device management, storage and application integration.

Interoperability: Ability of systems to exchange and meaningfully use information.

Secure boot: Mechanism that permits execution only of authenticated software.

Digital twin: Digital representation linked to a physical asset or process.

Data minimization: Collection and retention of only the data needed for a defined purpose.

Over-the-air update: Remote delivery of device firmware or software.

Review Questions

Short Answer Questions

1. Define an embedded system and give two examples.
2. What distinguishes a hard real-time deadline from a soft real-time deadline?
3. Why is M2M communication not synonymous with IoT?
4. State the five layers of the five-layer IoT reference model.
5. What is the role of a gateway in an IoT architecture?

Long Answer Questions

1. Compare embedded systems, IoT, CPS and M2M communication using suitable examples.
2. Explain the major design constraints of a battery-powered connected device.
3. Describe the complete device-to-cloud value chain and its return path to physical action.
4. Discuss the relative roles of edge, fog and cloud computing in an industrial system.
5. Examine the security, safety, privacy and lifecycle responsibilities associated with IoT deployment.

Analytical / Application Questions

1. Design a high-level architecture for a cold-chain monitoring system that must continue alarming during Internet outages. Justify where each function should execute.
2. A device draws 30 mA for 0.5 s and 0.02 mA for 29.5 s in each 30 s cycle. Calculate its average current and estimate runtime from 1800 mAh of usable battery capacity. State the limitations of the estimate.
3. Evaluate whether a cloud-only controller is appropriate for an automated railway crossing. Analyze latency, connectivity, safety, security and fallback operation.

Multiple Choice Questions with Answers

Question 1

Which statement best defines an embedded system?

A. A general-purpose computer intended to run arbitrary user applications

B. A dedicated computing system integrated into a larger product or process

C. Any device connected to the public Internet

D. A cloud platform used only for data storage

Correct Answer: B. A dedicated computing system integrated into a larger product or process

Question 2

Which feature most directly distinguishes a cyber-physical system?

A. Exclusive use of cellular communication

B. Mandatory dependence on public cloud services

C. Coordinated interaction between computation and physical processes

D. Absence of embedded software

Correct Answer: C. Coordinated interaction between computation and physical processes

Question 3

Which example is M2M communication without necessarily being IoT?

A. A programmable logic controller exchanging data with a motor drive over a private fieldbus

B. A person entering data into a spreadsheet

C. A standalone calculator evaluating an expression

D. A printed sensor specification sheet

Correct Answer: A. A programmable logic controller exchanging data with a motor drive over a private fieldbus

Question 4

A serial path has sensing, communication, computation and actuation delays of 4 ms, 12 ms, 7 ms and 5 ms, with no additional queueing delay. What is its total latency?

A. 19 ms

B. 24 ms

C. 28 ms

D. 35 ms

Correct Answer: C. 28 ms

Question 5

A sensor draws 20 mA for 1 s and 0.02 mA for 99 s in every 100 s cycle. What is its average current?

A. 0.2198 mA

B. 0.0200 mA

C. 1.9980 mA

D. 20.0200 mA

Correct Answer: A. 0.2198 mA

Question 6

Which function belongs primarily to the processing or middleware layer of a five-layer IoT model?

A. Measuring soil moisture

B. Driving a physical valve

C. Message brokering and device management

D. Defining radio-frequency propagation

Correct Answer: C. Message brokering and device management

Question 7

Why should an emergency shutdown function usually remain at the edge?

A. Edge systems always have unlimited processing power

B. Local execution can reduce latency and dependence on remote connectivity

C. Cloud services cannot store historical records

D. Edge execution eliminates every cybersecurity risk

Correct Answer: B. Local execution can reduce latency and dependence on remote connectivity

Question 8

If MTBF is 500 h and MTTR is 5 h, what is the estimated steady-state availability?

A. 90.00%

B. 95.00%

C. 99.01%

D. 99.99%

Correct Answer: C. 99.01%

Question 9

Which control most directly prevents a device from executing unauthorized firmware?

A. Secure boot with authenticated software

B. Increasing the sensor sampling frequency

C. Reducing the message payload size

D. Adding a larger battery

Correct Answer: A. Secure boot with authenticated software

Question 10

Why is application payload volume normally smaller than actual network traffic?

A. Payload calculations automatically remove sensor readings

B. Actual traffic also includes headers, security fields, acknowledgements and possible retransmissions

C. Networks transmit only half of every application payload

D. Gateways always compress all traffic to zero overhead

Correct Answer: B. Actual traffic also includes headers, security fields, acknowledgements and possible retransmissions