Secure, Connected and Intelligent Embedded Systems

Introduction and Context

Embedded systems have evolved from isolated controllers into networked, software-defined products. A modern vehicle, medical monitor, smart meter, industrial controller or wearable device may contain several microcontrollers, wireless interfaces, sensors, machine-learning software and cloud services. This connectivity creates value, but it also creates new responsibilities. A controller that once operated locally may now be exposed to malicious firmware, counterfeit commands, privacy violations, unsafe updates and failures caused by poorly governed artificial intelligence.

This chapter examines the engineering foundations required to design embedded systems that are secure, connected, intelligent, energy-efficient and safe. Security protects assets and commands; connectivity enables monitoring and coordination; intelligence supports local decisions; low-power design extends operating life; and functional safety limits the consequences of faults. These properties must be designed together rather than added independently at the end of a project.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Explain secure boot, hardware roots of trust and device authentication.
2. Describe secure firmware-update mechanisms and their failure risks.
3. Compare common IoT architectures and communication patterns.
4. Explain edge AI and select suitable inference locations.
5. Analyse power consumption and energy requirements in embedded devices.
6. Distinguish functional safety from cybersecurity and describe their interaction.
7. Discuss privacy, ethics, governance, sustainability and emerging processor trends.
8. Apply these ideas to the design of a connected embedded product.

1. Security Foundations for Embedded Systems

1.1 Security objectives

The traditional security objectives are confidentiality, integrity and availability. Confidentiality prevents unauthorised disclosure, integrity prevents unauthorised alteration, and availability ensures that legitimate users can obtain service. Embedded systems add authenticity, accountability and safety. A motor controller, for example, must verify that a command came from an authorised source, preserve trustworthy logs and enter a safe state if communication becomes unreliable.

Important assets include:

• boot code and application firmware;
• cryptographic keys and device identities;
• sensor readings and user data;
• actuator commands and configuration settings;
• debug interfaces and manufacturing tools; and
• availability of the physical process.

A threat is a potential cause of harm, whereas a vulnerability is a weakness that can be exploited. Risk is commonly assessed by considering the likelihood and impact of an adverse event. This is a planning model, not a precise law: numerical risk scores should be supported by engineering evidence.

1.2 Hardware root of trust

A hardware root of trust is a small set of hardware-supported mechanisms that establishes initial confidence in system identity, keys or software state. Examples include a secure element, trusted platform module, protected key storage, one-time programmable memory, a hardware random-number generator and memory-access controls.

The root of trust should be small, difficult to modify and isolated from ordinary application software. A microcontroller may provide:

• immutable boot ROM;
• a device-unique key or protected key store;
• cryptographic accelerators;
• secure and non-secure execution regions;
• debug authentication; and
• tamper or fault-detection mechanisms.

Hardware does not automatically make a system secure. Poor key provisioning, exposed debug pins, insecure software and weak recovery procedures can still defeat the design.

1.3 Secure boot and the chain of trust

Secure boot verifies software before execution. The first trusted component, normally immutable ROM, verifies a bootloader. The bootloader verifies the operating system or application, which may verify additional components. Each stage begins only after checking the next stage.

A digital signature provides authenticity and integrity. During manufacturing, the vendor signs a firmware image using a private signing key. The device stores or securely references the corresponding public key. At boot, it calculates a cryptographic hash of the image and verifies the signature. Encryption is not required for authenticity, although encryption may be needed to protect confidentiality.

A secure design must also prevent rollback. If an attacker installs a legitimately signed but vulnerable older image, signature verification alone will succeed. A monotonic version counter, anti-rollback fuse or protected minimum-version value can reject obsolete firmware.

A typical secure-boot sequence is:

1. Reset and execute immutable boot ROM.
2. Establish clock, memory and security boundaries.
3. Validate the bootloader signature.
4. Validate the firmware signature and version.
5. Measure or record the software state where attestation is required.
6. Transfer control only if all checks succeed.
7. Enter a recovery or safe state if validation fails.

The recovery path is part of the security boundary. It must not provide an unauthenticated method for bypassing verification.

1.4 Authentication and authorisation

Authentication answers, “Who or what is communicating?” Authorisation answers, “What is that entity allowed to do?” A device certificate may authenticate a sensor to a gateway, while an access-control policy determines whether the sensor may upload readings but not change actuator settings.

Common mechanisms include pre-shared keys, certificates based on public-key cryptography, signed tokens and challenge–response protocols. A challenge–response exchange avoids sending a reusable secret directly. The verifier sends a fresh random challenge; the claimant returns a cryptographic response based on that challenge and its secret. Freshness prevents simple replay of an old response.

Credentials should be unique per device. Shared fleet-wide passwords make revocation and forensic analysis difficult. Keys must be generated with a suitable random source, protected in storage, rotated when appropriate and revoked when a device is compromised or decommissioned.

2. Secure Firmware Updates

Firmware updates correct defects, patch vulnerabilities and add capabilities. However, the update mechanism itself is a high-value attack surface. A secure update system should provide:

• authenticated source and signed images;
• integrity checking during download and installation;
• confidentiality when intellectual property or sensitive data requires it;
• version and anti-rollback control;
• power-loss tolerance;
• recovery from an interrupted or invalid update;
• staged deployment and monitoring; and
• a documented key-revocation process.

A common implementation uses two firmware partitions, often called A/B slots. The device continues running slot A while downloading and verifying a new image into slot B. It switches to slot B only after verification. A boot-success marker is written after the new system operates correctly for a defined period. If the device resets repeatedly before that marker is written, the bootloader returns to slot A.

The update image should be signed before distribution, but transport-layer security should also be used to protect the delivery channel. These controls solve different problems: a secure channel protects communication in transit, while an image signature allows the device to verify the object independently of the network path.

Worked example: energy required for an update

Suppose a battery device downloads 2.0 MB at an average electrical power of 0.30 W for 80 s. The energy used by the download is:

where E is energy in joules, P is power in watts and t is time in seconds. Therefore:

This estimate excludes flash-programming, verification and radio start-up energy. It is applicable when average power is reasonably constant during the interval. A production design should measure the complete update sequence and reserve sufficient battery capacity for interruption recovery.

3. IoT Architectures and Communication

An Internet of Things system connects physical objects, computation and services. A useful architecture has several logical layers:

1. Device layer: sensors, actuators, microcontrollers and local control loops.
2. Network layer: wired or wireless links, routing, addressing and gateways.
3. Edge or fog layer: local aggregation, protocol translation, filtering and inference.
4. Cloud or platform layer: fleet management, storage, analytics and model training.
5. Application and governance layer: user services, policies, audit, compliance and business processes.

These layers are conceptual rather than mandatory physical divisions. A gateway may perform edge inference and also provide network security. A small system may omit a cloud service entirely.

Communication patterns

• Device-to-device: useful for local control, but discovery and trust must be managed.
• Device-to-gateway: reduces device complexity and can provide protocol translation.
• Device-to-cloud: simplifies central management but depends more heavily on connectivity.
• Gateway-to-cloud: supports aggregation, buffering and local operation during outages.

Protocols should be selected according to data rate, latency, range, power, reliability and security requirements. MQTT commonly uses a broker and publish–subscribe topics. CoAP provides a constrained-device approach based on request–response concepts. Industrial systems may use fieldbus or industrial Ethernet for deterministic control. No protocol is secure merely because it is popular; authentication, authorisation, encryption and safe failure remain necessary.

A resilient design specifies behaviour during network loss. A thermostat may continue local control using its most recent valid schedule. A safety interlock should not depend on cloud availability. Data should be buffered with bounded storage, timestamps and protection against duplicate or out-of-order messages.

4. Edge AI and Embedded Intelligence

Edge AI means executing machine-learning inference near the data source rather than sending all raw data to a remote server. Examples include detecting abnormal vibration, recognising a spoken wake word, classifying images from a camera or estimating occupancy from sensors.

The principal benefits are lower latency, reduced bandwidth, improved privacy and continued operation during intermittent connectivity. Limitations include restricted memory, processing power, energy and model-update capability.

The embedded AI workflow

1. Define the decision and acceptable error costs.
2. Collect representative and legally permissible data.
3. Label, clean and partition the data.
4. Train and validate a model, normally on more capable hardware.
5. Compress or optimise the model using quantisation, pruning or distillation.
6. Deploy an inference runtime on the microcontroller or edge processor.
7. Test accuracy, latency, energy, robustness and failure behaviour.
8. Monitor drift and govern model updates.

Quantisation may represent parameters and activations with 8-bit integers instead of 32-bit floating-point values. This can reduce memory and improve efficiency, but accuracy must be measured rather than assumed. A model should not be evaluated only on average accuracy. False negatives may be more dangerous than false positives in predictive maintenance or medical monitoring.

AI must be treated as a component with uncertainty. An embedded classifier should provide confidence information or an abstention path when the input is outside its training distribution. Safety-related decisions should have deterministic fallback logic and human or supervisory control where appropriate.

5. Low-Power Embedded Computing

Battery life depends on both average power and available energy. The fundamental relationship is:

where E is energy in joules, P(t) is instantaneous power in watts and t is time in seconds. If power is constant, this reduces to E = P × t. For a battery with usable energy E_b, the ideal operating time is:

where P_avg is average power. Real operating time is lower because of regulator losses, temperature, battery ageing, discharge-rate effects and energy reserved for safe shutdown.

Average power over repeated operating states can be estimated by:

where P_i is the power in state i and D_i is the fraction of time spent in that state. The duty fractions must sum to one. For a sleeping controller, reducing sleep leakage and shortening radio-active periods may be more effective than optimising a brief computation.

Low-power techniques include:

• clock gating and power gating;
• deep-sleep modes with wake-on-interrupt;
• dynamic voltage and frequency selection;
• batching sensor readings and radio transmissions;
• local processing to reduce communication;
• efficient regulators and appropriate voltage domains; and
• selecting processors with suitable accelerator and memory characteristics.

Power optimisation must preserve timing, security and safety. Disabling a watchdog, reducing sampling below the control requirement or sleeping through a critical alarm is not an acceptable optimisation.

6. Functional Safety and Dependability

Functional safety is the ability of a system to achieve or maintain a safe state in response to faults. It differs from cybersecurity. A safety failure may result from random hardware faults, systematic design errors or environmental conditions; a security failure may be caused deliberately by an attacker. The two disciplines overlap because a cyberattack can create a safety hazard.

A safety-oriented process generally includes:

1. hazard identification;
2. risk assessment;
3. allocation of safety requirements;
4. architecture with independence or redundancy where justified;
5. verification and validation;
6. diagnostic coverage and fault handling; and
7. evidence, traceability and change control.

Examples of safety mechanisms include watchdog timers, lockstep processors, range checks, plausibility checks, memory protection, redundant sensors, emergency shutdown and fail-safe output states. A watchdog should detect a failure of expected software progress, but its timeout must be selected carefully. A timeout that is too short creates nuisance resets; one that is too long delays hazard mitigation.

Safety integrity requirements are domain-specific. Automotive, industrial, medical, aviation and railway sectors use different standards and terminology. Engineers must consult the applicable standard rather than transferring a safety claim from one domain to another without analysis.

7. Privacy, Ethics and Governance

Connected embedded systems can collect location, voice, biometric, health, behavioural and household data. Privacy should be designed into the architecture through data minimisation, purpose limitation, access control, retention limits and transparent user communication.

A privacy-conscious design asks:

• Is each data item necessary?
• Can processing occur locally rather than in the cloud?
• Is consent meaningful and revocable?
• Who can access raw and derived data?
• How long is data retained?
• Can a user inspect, correct or delete it where applicable?
• What happens when the device is transferred or discarded?

Ethical concerns include discriminatory model performance, manipulative surveillance, inaccessible security updates, unsafe automation and unequal distribution of benefits or harms. Governance assigns responsibility for security ownership, incident response, supplier assurance, model changes and end-of-life support.

Regulatory obligations vary by jurisdiction and product class. Relevant areas may include data protection, product safety, radio regulation, cybersecurity requirements, accessibility, environmental rules and sector-specific certification. Compliance is not identical to good engineering: a compliant design can still be unsafe or unfair, while a robust design still requires documented conformity evidence.

8. Sustainability and Emerging Processor Trends

Sustainability includes energy use during operation, manufacturing impacts, repairability, software longevity and disposal. A highly efficient device that cannot receive security patches may create premature replacement and electronic waste. Design choices should consider modularity, long-term component availability, recyclable materials, battery replacement and responsible data-centre usage.

Contemporary processor developments include:

• heterogeneous systems combining efficient and performance cores;
• microcontrollers with integrated neural-network and digital-signal accelerators;
• hardware virtualization and trusted execution environments;
• chiplet-based systems and specialised domain accelerators;
• open instruction-set architectures such as RISC-V;
• non-volatile memory and compute-near-memory research; and
• processors designed for deterministic real-time and safety workloads.

These trends create trade-offs. More integration can reduce board area and energy but increase supply-chain dependence. Accelerators improve performance for selected workloads but may complicate verification and software portability. Open architectures can encourage customisation, but ecosystem maturity, tool support and security governance must be evaluated.

Applied Case: Illustrative Smart Irrigation Controller

Background

A small agricultural enterprise wants a battery-assisted irrigation controller. The device measures soil moisture, controls a valve, communicates through a low-power wide-area network and uses a local model to identify abnormal flow.

Problem

The original prototype accepts commands using a shared password, stores firmware in one partition and sends all sensor data to a cloud service. It has poor performance during network outages, consumes excessive energy during communication and cannot distinguish a blocked pipe from a sensor fault.

Analysis

The assets include valve control, firmware, farm data and device identity. Threats include replayed valve commands, unauthorised firmware, stolen credentials and denial of service. Safety concerns include continuous watering, dry-running pumps and incorrect operation after a sensor failure. Privacy concerns arise because soil and production data may reveal business practices.

Approach and solution

Each controller receives a unique cryptographic identity during manufacturing. Secure boot verifies signed firmware and rejects versions below a protected minimum. An A/B update design supports rollback after power loss. Commands are authenticated, include freshness information and are authorised by device role. The controller limits valve-on duration locally, even if a remote command requests a longer period.

The device samples sensors locally, performs anomaly detection at the edge and transmits summaries rather than raw high-frequency data. A gateway buffers data during network outages. The controller enters a defined safe state when moisture readings are implausible or communication is unavailable beyond a configured interval. A watchdog, sensor plausibility checks and manual override are included.

Power is reduced by sleeping between measurements and batching transmissions. Updates are staged first to a small test group. Monitoring records update success, resets, rejected commands and unusual energy consumption without collecting unnecessary personal data.

Outcome

The revised architecture reduces exposure to shared credentials, continues basic irrigation during network loss, limits unsafe valve operation and reduces communication energy. It also creates evidence for maintenance and incident response. The design does not eliminate risk: physical tampering, supply-chain compromise and incorrect anomaly models still require controls.

Learning points

Security is a system property rather than a single encryption feature. Local control improves both resilience and safety. Edge intelligence must have a fallback. Update, identity, power, privacy and safety decisions should be made together during architecture design.

Best-Practice Design Checklist

Before releasing a connected embedded product, the engineering team should be able to answer yes to the following questions:

• Is there a documented threat model and asset inventory?
• Does immutable or protected code establish a root of trust?
• Are firmware images authenticated and protected against rollback?
• Does every device have a manageable identity and revocation path?
• Are debug, test and manufacturing interfaces controlled?
• Can the product operate safely during network loss and update interruption?
• Are privacy, retention and user-control requirements documented?
• Are AI accuracy, uncertainty, drift and fallback behaviour tested?
• Have average and peak power been measured in realistic conditions?
• Are hazards, fault responses and verification evidence traceable?
• Is there a vulnerability-reporting and end-of-life support process?
• Have repairability, energy, materials and disposal been considered?

Chapter Summary

Secure, connected and intelligent embedded systems require coordinated engineering. Secure boot establishes a chain of trust from protected startup code to application firmware. Authentication, authorisation, key management and anti-rollback controls protect devices and updates. IoT architectures distribute sensing, networking, edge processing and cloud services, but local operation remains essential for resilience and safety.

Edge AI reduces latency, bandwidth and privacy exposure, yet constrained hardware and uncertain model behaviour require careful optimisation, validation and fallback logic. Low-power design is based on energy over time, duty cycle and measured operating states. Functional safety addresses hazards and safe responses to faults, while cybersecurity addresses intentional misuse; both must be considered together. Privacy, ethics, governance and sustainability determine whether a technically successful product is socially and environmentally responsible. Emerging processors offer greater efficiency and specialisation, but also introduce verification, supply-chain and lifecycle challenges.

Key Terms

Secure boot: A startup process that verifies software before execution.

Root of trust: A protected hardware or software foundation used to establish confidence.

Digital signature: A cryptographic proof of origin and integrity produced with a private key.

Authentication: Verification of the identity of a user, device or service.

Authorisation: Determination of which actions an authenticated entity may perform.

Anti-rollback: Protection that prevents installation of an older, vulnerable firmware version.

Firmware update: Replacement or modification of software stored in an embedded device.

IoT gateway: A node that connects devices to other networks or services and may process data locally.

Edge computing: Processing performed near the physical data source.

Edge AI: Machine-learning inference executed on an edge device or gateway.

Quantisation: Representing numerical model values with reduced precision.

Duty cycle: The fraction of time a system spends in a particular operating state.

Average power: Power averaged over an operating interval or set of operating states.

Functional safety: Ability to achieve or maintain a safe state in response to faults.

Watchdog timer: A timer that initiates recovery when expected software progress is not observed.

Threat: A potential cause of harm to an asset or system.

Vulnerability: A weakness that can be exploited by a threat.

Privacy by design: Incorporating privacy protections into architecture and operation from the beginning.

Secure element: A tamper-resistant component for protected cryptographic operations or key storage.

Model drift: Degradation in model performance because real-world data changes over time.

Review Questions

Short Answer Questions

1. What is the purpose of a hardware root of trust?
2. Distinguish authentication from authorisation.
3. Why is anti-rollback protection needed in secure firmware updates?
4. State two benefits and two limitations of edge AI.
5. How does a watchdog timer contribute to functional safety?

Long Answer Questions

1. Explain the stages of a secure-boot chain and discuss what should happen when verification fails.
2. Compare device-to-cloud and gateway-to-cloud IoT architectures for a battery-powered monitoring system.
3. Explain how duty cycling, local processing and communication batching reduce embedded-system energy use.
4. Discuss the relationship between cybersecurity and functional safety, using an actuator controller as an example.
5. Develop a governance plan for privacy, firmware support, vulnerability reporting and end-of-life management of a connected product.

Analytical / Application Questions

1. Design a secure update strategy for a remote sensor that may lose power during installation. Identify storage, authentication, rollback and recovery mechanisms.
2. A wearable device has limited battery capacity but must detect an abnormal physiological pattern within one second. Decide which processing should occur locally and which may occur in the cloud, and justify the decision using latency, privacy and energy considerations.
3. Analyse the smart irrigation case. Identify three remaining risks after the proposed controls and recommend additional technical or organisational mitigations.

Multiple Choice Questions with Answers

Question 1

Which mechanism establishes a trusted starting point for verifying later firmware stages?

A. Hardware root of trust

B. User interface theme

C. Data compression

D. Polling interval

Correct Answer: A. Hardware root of trust

Question 2

Why is anti-rollback protection used?

A. To increase radio range

B. To prevent installation of an older vulnerable image

C. To encrypt every sensor reading

D. To reduce flash memory size

Correct Answer: B. To prevent installation of an older vulnerable image

Question 3

In an A/B firmware-update design, what is the main purpose of the second partition?

A. To store unauthenticated passwords

B. To hold a candidate image while the current image continues operating

C. To replace the device identity

D. To disable recovery after power loss

Correct Answer: B. To hold a candidate image while the current image continues operating

Question 4

Which statement best distinguishes authentication from authorisation?

A. Authentication determines identity; authorisation determines permitted actions

B. Authentication compresses data; authorisation encrypts data

C. Authentication measures power; authorisation measures latency

D. Authentication updates firmware; authorisation boots hardware

Correct Answer: A. Authentication determines identity; authorisation determines permitted actions

Question 5

A controller consumes 0.25 W continuously for 40 s. Using E = P × t, what energy does it use?

A. 0.00625 J

B. 10 J

C. 40.25 J

D. 160 J

Correct Answer: B. 10 J

Question 6

Which is a principal advantage of edge AI?

A. It guarantees perfect predictions

B. It removes the need for model validation

C. It can reduce latency and raw-data transmission

D. It always consumes less energy than any cloud design

Correct Answer: C. It can reduce latency and raw-data transmission

Question 7

If a device spends 90% of its time at 0.01 W and 10% at 0.50 W, what is its estimated average power?

A. 0.011 W

B. 0.059 W

C. 0.255 W

D. 0.510 W

Correct Answer: B. 0.059 W

Question 8

Which example is primarily a functional-safety mechanism?

A. A watchdog that detects failed software progress

B. A marketing dashboard

C. A larger product logo

D. A public discussion forum

Correct Answer: A. A watchdog that detects failed software progress

Question 9

Which practice best supports privacy by design?

A. Collecting all possible data indefinitely

B. Using shared passwords for convenience

C. Processing necessary data locally and limiting retention

D. Disabling access logs

Correct Answer: C. Processing necessary data locally and limiting retention

Question 10

Why should an edge-AI system include a fallback or abstention path?

A. Models can encounter uncertain or unfamiliar inputs

B. It guarantees that the model never needs updates

C. It eliminates all sensor faults

D. It makes cryptographic authentication unnecessary

Correct Answer: A. Models can encounter uncertain or unfamiliar inputs