Reliability, Safety, Security, Ethics, and Governance

Introduction and Context

Microprocessors and microcontrollers now control aircraft systems, medical devices, industrial drives, vehicles, access-control systems, energy infrastructure, and domestic appliances. Their failure may cause inconvenience, financial loss, environmental damage, injury, or loss of life. Their software may also expose private information or permit unauthorized control. Consequently, embedded-system engineering is no longer limited to selecting a processor and writing application code. It requires a lifecycle approach that combines reliability engineering, functional safety, cybersecurity, electromagnetic compatibility (EMC), ethical judgment, and governance.

Reliability asks whether a system performs its intended function for a specified time under stated conditions. Safety asks whether hazards are controlled so that unacceptable harm is avoided. Security protects assets and functions against intentional misuse. These properties overlap but are not identical. A random memory fault is primarily a reliability concern; an attacker deliberately modifying firmware is a security concern; both may produce unsafe actuator behavior.

This chapter develops practical foundations for designing trustworthy microprocessor- and microcontroller-based systems. It emphasizes threat-aware architecture, secure boot, cryptographic fundamentals, access control, safe failure handling, defensive coding, standards, privacy, sustainability, and professional accountability.

Learning Objectives

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

• distinguish reliability, availability, safety, security, privacy, and resilience;
• explain secure boot, firmware authenticity, cryptographic hashing, encryption, and digital signatures;
• design basic access-control and firmware-update strategies;
• apply defensive coding, watchdogs, diagnostics, redundancy, and fail-safe principles;
• explain functional-safety concepts and the relevance of standards such as IEC 61508, ISO 26262, IEC 62443, ISO/SAE 21434, IEC 62304, ISO 13849, and EMC standards;
• analyze privacy, surveillance, sustainability, e-waste, accountability, and responsible engineering obligations;
• evaluate a complete embedded-system scenario using technical, ethical, and governance criteria.

1. Trustworthiness as a System Property

A trustworthy embedded system has several related properties:

These properties can conflict. Encrypting every communication may increase computation and latency. A rapid automatic update may improve security but create availability risk if the update is defective. A fail-safe shutdown may protect people but interrupt a critical process. Engineering therefore requires explicit requirements, hazard analysis, threat modeling, verification, and documented trade-offs.

A useful reliability model for a constant failure rate is:

Here, R(t) is the probability of surviving without failure until time t, λ is the constant failure rate in failures per unit time, and t is operating time in the same unit. The model assumes statistically independent failures and a constant hazard rate; it is not generally valid during early-life or wear-out periods. The corresponding mean time to failure for this idealized model is MTTF = 1/λ. For repairable systems, availability also depends on mean time to repair, so reliability and availability must not be treated as synonyms.

For a simple series system, where all components must operate and component failures are independent:

The product is appropriate only for the stated series and independence assumptions. Redundancy can improve reliability, but common-cause failures, shared power supplies, common software defects, and environmental stress can defeat nominal redundancy.

2. Threat Modeling and Security Architecture

Security begins with identifying assets, adversaries, entry points, and consequences. Assets may include firmware, cryptographic keys, sensor data, personal information, calibration constants, safety parameters, and control commands. Threat modeling asks what an attacker can do, what capabilities are required, and how the system can prevent, detect, contain, and recover from the attack.

A practical analysis follows these steps:

1. Define system boundaries, interfaces, users, trust zones, and assumptions.
2. Identify assets and rank their confidentiality, integrity, and availability requirements.
3. Enumerate threats, including malicious firmware, debug-port abuse, replay, denial of service, physical tampering, supply-chain compromise, and insecure updates.
4. Estimate impact and likelihood qualitatively or quantitatively.
5. Select controls and verify that residual risk is acceptable.
6. Maintain the threat model as hardware, software, suppliers, and operating conditions change.

The principle of least privilege gives each task, user, peripheral, and communication channel only the permissions necessary for its function. Defense in depth avoids dependence on one barrier. Secure defaults mean that a new or failed configuration is restrictive rather than permissive. Fail-safe and fail-secure are context-dependent: a door may be designed to unlock during a fire for evacuation, while a cryptographic key store should normally remain inaccessible during a fault.

Secure Boot and the Chain of Trust

Secure boot establishes that only authorized firmware executes. A typical chain begins with immutable or hardware-protected ROM code. The ROM verifies a first-stage bootloader; the bootloader verifies the operating system or application image; the application verifies selected modules where necessary. Each stage is trusted because it verifies the next stage using a protected public key or key hash.

A digital signature provides authenticity and integrity. The producer computes a cryptographic hash of the firmware and signs that hash with a private key. The device verifies the signature using the corresponding public key. A hash alone detects accidental or deliberate modification only when the expected hash is itself protected; it does not identify the authorized signer.

A secure-boot design should address:

• protection and lifecycle management of root keys;
• rollback prevention, often through a monotonic version counter or secure fuse;
• recovery if an update is interrupted;
• separation of development, test, and production keys;
• debug-port locking or authenticated debug access;
• measurement and attestation when a remote party must evaluate device state;
• physical attack assumptions and secure storage for secrets.

Secure boot does not prove that software is safe, bug-free, or privacy-preserving. It proves only that the device accepts software authorized under the chosen trust policy.

Cryptographic Fundamentals

Cryptography supports several distinct goals:

• confidentiality: unauthorized parties cannot read data;
• integrity: unauthorized modification is detected;
• authentication: an identity or origin is verified;
• non-repudiation or accountability: evidence links an action to a signing key, subject to key control and legal context.

Symmetric encryption uses one shared secret key for encryption and decryption. It is efficient for bulk data, but securely distributing the key is difficult. Asymmetric cryptography uses a public/private key pair. Public-key methods support signatures and key establishment but generally require more computation. Authenticated encryption, such as an approved AEAD construction, combines confidentiality and integrity and should normally be preferred to encryption without authentication.

A cryptographic hash maps arbitrary-length input to a fixed-length digest. It is designed to make finding collisions computationally difficult, but it is not encryption. Passwords should not be stored as ordinary hashes; they require a password-specific, salted, deliberately expensive derivation method. Random numbers used for keys, nonces, and challenges must come from an appropriate cryptographic random source.

Nonce reuse can be catastrophic for some authenticated-encryption modes. Nonces must satisfy the algorithm’s uniqueness requirements, and key rotation, expiry, and compromise procedures must be specified. “Home-made cryptography” is inappropriate for production safety- or security-critical systems.

Access Control

Access control includes identification, authentication, authorization, and accountability. A robust embedded design may use:

• unique device and user identities rather than shared default passwords;
• role-based or capability-based permissions;
• secure storage of credentials;
• rate limiting and lockout for repeated failures;
• mutual authentication for device-to-server communication;
• explicit authorization checks at every sensitive command boundary;
• audit records that avoid storing unnecessary personal information.

A communication channel may be encrypted yet still be insecure if an authenticated user is authorized to issue dangerous commands. Authorization must be checked according to context, operating state, safety interlocks, and command validity.

3. Firmware Updates and Vulnerability Management

Field updates are essential because vulnerabilities are discovered after deployment. A secure update process verifies the image before installation, protects transport where appropriate, handles interruption, supports recovery, and records version and status. The device should reject unsigned, malformed, incompatible, or unauthorized images.

A robust update sequence is:

1. Obtain the image through an authenticated channel.
2. Verify image format, size, version, target identity, and signature.
3. Store the image in a separate region while the existing image remains recoverable.
4. Validate dependencies and configuration compatibility.
5. Atomically select the new image using an integrity-protected boot record.
6. Boot the new image in a trial state.
7. Confirm successful operation and commit; otherwise roll back.
8. Record the result and support incident response.

Updates can create safety hazards if timing, calibration, control-loop behavior, or regulatory approval changes. Safety-related changes require impact analysis and regression testing, not merely a successful cryptographic check. End-of-support policies should be communicated before deployment.

4. Reliability Engineering and Fault Handling

Embedded faults arise from hardware aging, noise, radiation, power interruption, software defects, timing errors, invalid inputs, memory corruption, and environmental conditions. Good design assumes that faults will occur and defines controlled responses.

Important techniques include:

• watchdog timers that reset or transition the system when software stops making progress;
• brownout detection and power-on reset supervision;
• memory protection units, parity, ECC where supported, and stack guards;
• range, plausibility, rate-of-change, and timing checks on sensor data;
• CRCs for detecting communication or storage corruption;
• redundancy, diversity, voting, and independent monitoring;
• bounded execution time and protection against resource exhaustion;
• event logs with integrity protection and a defined retention policy;
• graceful degradation and a known safe state.

A watchdog is not a substitute for correctness. If it is periodically serviced by a malfunctioning task, it may fail to detect a dangerous condition. Service should therefore depend on evidence that critical tasks have completed their checks, and watchdog configuration should be protected from accidental or unauthorized change.

Defensive code validates every external input, checks return values, avoids unchecked buffer operations, handles integer overflow and conversion, initializes variables, uses explicit state machines, and fails closed at security boundaries. Concurrency requires attention to race conditions, interrupt interactions, priority inversion, and atomic access to shared data. Static analysis, code review, unit testing, integration testing, fuzzing, and hardware-in-the-loop testing complement one another.

5. Functional Safety and Standards

Functional safety concerns hazardous failures of electrical, electronic, and programmable systems. It is not identical to cybersecurity: safety often addresses random hardware failures and systematic design faults, while security addresses intentional misuse. Security can nevertheless be a safety mechanism when an attack could produce a hazard.

A safety lifecycle commonly includes hazard analysis, safety requirements, architectural design, implementation, verification, validation, operation, maintenance, and decommissioning. Traceability connects hazards to requirements, design elements, tests, and evidence.

The risk concept is often expressed qualitatively as a function of severity, probability of occurrence, and possibility of avoiding harm. Such classifications are domain-specific; a risk matrix is a decision aid, not a universal scientific law. Safety integrity levels or performance levels must be selected using the applicable standard and evidence, not by intuition alone.

Relevant standards include:

Standards do not guarantee safety. Compliance requires correct scope, competent interpretation, documented evidence, configuration control, and independent review where required. Applicable national law, certification rules, and contractual obligations must also be considered.

EMC Awareness

Electromagnetic compatibility means that equipment neither emits unacceptable interference nor suffers unacceptable degradation from its electromagnetic environment. Sources include fast switching edges, clock harmonics, motors, relays, radio transmitters, electrostatic discharge, and conducted disturbances.

Mitigation may involve grounding and bonding, controlled return paths, filtering, shielding, cable segregation, slew-rate control, decoupling, transient protection, and suitable PCB layout. EMC is a system property: a compliant integrated circuit can become part of a noncompliant product because of enclosure, cable, connector, or installation design. Testing should include realistic operating modes and external interfaces, not just a laboratory idle state.

6. Ethics, Privacy, Sustainability, and Governance

Engineering ethics requires protection of public safety, honesty about limitations, competence, respect for privacy, avoidance of conflicts of interest, and willingness to report unacceptable risk. A technically feasible feature is not automatically ethically justified. Engineers should ask who benefits, who bears risk, whether consent is meaningful, and whether less intrusive alternatives exist.

Privacy protection begins with data minimization: collect only what is necessary, retain it only as long as justified, and restrict access. Privacy-by-design includes local processing where feasible, encryption in transit and at rest, clear user notice, deletion mechanisms, purpose limitation, and careful treatment of metadata. A sensor that records location, voice, biometrics, or behavior can create significant risks even if the original product purpose appears benign.

Surveillance systems require proportionality, transparency, lawful authority, accuracy controls, human review, and mechanisms for correction and appeal. Automated classification or AI-assisted decisions can reproduce bias from data or design assumptions. An embedded system should not silently convert a probability into a definitive accusation or safety decision without appropriate validation and oversight.

Governance assigns responsibility across the manufacturer, integrator, operator, maintainer, cloud provider, and end user. A useful governance record identifies system owner, data owner, safety authority, security response contact, update authority, approval gates, incident process, and end-of-life responsibility. Logging supports accountability, but excessive logging can itself violate privacy and consume limited storage.

Sustainability includes energy efficiency, repairability, long service life, modular updates, material selection, supply-chain due diligence, and responsible disposal. Secure devices may become unusable if keys or update services disappear; therefore, sustainability and security planning should include escrow or migration strategies where appropriate. E-waste contains recoverable materials and hazardous substances. Product design should support disassembly, recycling, safe battery handling, and data sanitization before reuse or disposal.

7. Applied Case: Connected Industrial Pump Controller

Background

Consider an illustrative case involving a microcontroller controlling a chemical-process pump. The controller reads pressure and flow sensors, drives a motor inverter, records maintenance data, and accepts authenticated service commands over Ethernet. A pump failure can cause production loss; uncontrolled pressure can injure personnel or release hazardous material.

Problem

The initial design used a shared service password, unsigned firmware updates, an exposed debug connector, no independent pressure limit, and a watchdog serviced by the main loop regardless of task health. EMC testing also showed intermittent resets near the motor inverter.

Analysis

The hazard analysis identified overpressure, loss of flow, unintended start, and failure to stop. Threat modeling identified password compromise, malicious firmware, replayed service commands, and physical access to the enclosure. Reliability analysis identified resets from conducted transients and sensor corruption. Governance analysis found no named owner for update approval or incident response.

Approach and Solution

The revised architecture used a hardware root of trust and secure boot with signed images and anti-rollback protection. Each controller received a unique credential; service access required mutual authentication and role-based authorization. Commands included sequence numbers or freshness checks to reduce replay risk and were accepted only in permitted operating states.

Two independent pressure limits were implemented: the control loop regulated normal operation, while a separate monitored path initiated a safe shutdown when a validated limit was exceeded. Sensor plausibility checks detected open circuits, impossible rates of change, and disagreement between redundant measurements. The watchdog was serviced only after supervised tasks reported successful completion. Brownout reset, protected configuration, CRC-checked parameters, and a recovery image improved fault handling.

The PCB and enclosure were redesigned with improved decoupling, cable segregation, filtering, shielding, and grounding. Verification included unit tests, static analysis, fault injection, power interruption, EMC immunity tests, penetration testing, update interruption tests, and independent safety review. A documented change-control board approved firmware releases, and an incident process defined vulnerability reporting, containment, patching, and customer notification.

Outcome

The system rejected unauthorized and downgraded firmware, recovered from interrupted updates, detected sensor faults, and entered a documented safe state during pressure-limit violations. EMC resets were eliminated under tested conditions. The design did not claim absolute security or zero risk; instead, it produced evidence that identified risks were reduced and that remaining limitations were communicated to operators.

Learning Points

Security controls must be integrated with safety and maintenance rather than added at the end. Independent protective functions are valuable when a shared software defect could defeat the primary controller. A cryptographic feature is effective only when keys, authorization, recovery, and operational governance are also managed.

8. Design and Review Checklist

Before release, an engineering team should be able to answer the following:

• Are safety hazards, security threats, privacy impacts, and environmental conditions documented?
• Is every external input validated, and is every failure response defined?
• Can only authorized and compatible firmware execute?
• Are keys generated, stored, rotated, revoked, and retired securely?
• Are update interruption, rollback, recovery, and end-of-support addressed?
• Are watchdogs, reset circuits, memory protection, diagnostics, and logs independently verified?
• Has the product been evaluated for EMC emissions and immunity in realistic configurations?
• Are safety and security requirements traceable to tests and evidence?
• Are users informed about data collection, limitations, maintenance, and residual risk?
• Are repair, reuse, recycling, data deletion, and supply-chain responsibilities assigned?

Chapter Summary

Trustworthy microcontroller systems require coordinated treatment of reliability, safety, security, privacy, maintainability, and sustainability. Reliability models are useful only under their assumptions. Secure boot establishes a chain of authorized software, while signatures provide authenticity and integrity and encryption provides confidentiality. Access control must enforce least privilege and context-sensitive authorization. Secure firmware updates require signature verification, anti-rollback, recovery, and lifecycle governance.

Defensive coding, watchdog supervision, diagnostics, memory protection, redundancy, fault injection, and safe-state design reduce the consequences of faults. Functional-safety standards provide lifecycle and evidence frameworks, while EMC engineering prevents interference-related malfunction. Ethical and governance responsibilities extend beyond technical performance to privacy, surveillance, accountability, sustainability, e-waste, and responsible disclosure. The central professional obligation is to make risks visible, reduce them systematically, and communicate residual uncertainty honestly.

Key Terms

Reliability: Probability that a system performs its required function for a stated time and conditions.

Availability: Probability that a system is operational and ready when required.

Functional safety: Prevention of unacceptable risk caused by malfunctioning safety-related systems.

Cybersecurity: Protection against unauthorized access, misuse, alteration, disruption, or destruction.

Secure boot: Boot process that permits execution only after software authenticity is verified.

Digital signature: Cryptographic evidence that binds data to a signing private key and detects modification.

Hash: Fixed-length digest produced from input data for integrity checking.

Authenticated encryption: Encryption that provides confidentiality and integrity/authentication.

Nonce: Value intended for one-time or controlled-use cryptographic operation.

Least privilege: Granting only the permissions necessary for an authorized function.

Threat model: Structured description of assets, adversaries, attack paths, and impacts.

Watchdog timer: Hardware timer that initiates recovery when expected software activity is absent.

Fail-safe: Transition to a state intended to minimize hazard after a fault.

Defense in depth: Use of multiple independent or partially independent protective controls.

EMC: Ability to operate satisfactorily without causing or suffering unacceptable electromagnetic interference.

Traceability: Documented linkage among hazards, requirements, implementation, tests, and evidence.

Privacy by design: Incorporating privacy protection throughout system architecture and lifecycle.

E-waste: Discarded electrical and electronic equipment and its components.

Residual risk: Risk remaining after controls have been applied.

Review Questions

Short Answer Questions

1. Distinguish reliability, safety, and security using one embedded-system example.
2. Why does a digital signature provide a capability that a plain hash does not?
3. State two purposes of a watchdog timer and one limitation.
4. What is meant by least privilege?
5. Why must EMC be considered at product level rather than only at integrated-circuit level?

Long Answer Questions

1. Explain a secure-boot chain of trust and discuss key management, rollback prevention, and recovery.
2. Describe a secure firmware-update lifecycle, including verification, interruption handling, trial boot, and governance.
3. Compare functional safety and cybersecurity, explaining why a product may require both.
4. Discuss how privacy, surveillance, accountability, and sustainability influence embedded-system design.
5. Explain how defensive coding, diagnostics, redundancy, and safe-state design work together in fault handling.

Analytical / Application Questions

1. Design a threat model for a connected medical sensor. Identify assets, adversaries, attack surfaces, impacts, and at least six controls.
2. A motor controller resets intermittently when a nearby inverter switches. Propose a structured investigation covering firmware, power integrity, grounding, PCB layout, filtering, and EMC testing.
3. Evaluate whether an industrial controller should accept an emergency remote-stop command when its network authentication service is unavailable. State assumptions, safety arguments, security risks, and a justified design decision.

Multiple Choice Questions with Answers

Question 1

Which statement best describes secure boot?

A. It encrypts all application data stored by the device.

B. It permits execution only after authorized firmware is verified.

C. It guarantees that authorized firmware contains no defects.

D. It replaces the need for access control.

Correct Answer: B. It permits execution only after authorized firmware is verified.

Question 2

What is the principal purpose of a cryptographic hash in firmware verification?

A. To provide confidentiality by hiding the firmware.

B. To increase processor clock frequency.

C. To detect changes to the firmware data.

D. To assign user permissions.

Correct Answer: C. To detect changes to the firmware data.

Question 3

Which control most directly implements least privilege?

A. Giving every task administrator access for convenience.

B. Allowing each task only the permissions required for its function.

C. Disabling all authentication on a trusted network.

D. Using one shared password for all service engineers.

Correct Answer: B. Allowing each task only the permissions required for its function.

Question 4

For the constant-failure-rate model R(t) = e^(−λt), which assumption is required?

A. The failure rate changes continuously with age.

B. Failures are impossible during operation.

C. The hazard rate is approximately constant over the interval considered.

D. All components are connected in parallel.

Correct Answer: C. The hazard rate is approximately constant over the interval considered.

Question 5

Why is a watchdog timer alone insufficient to establish system safety?

A. It can only be used with mechanical switches.

B. A malfunctioning program may continue servicing it without being correct.

C. It prevents all electromagnetic interference.

D. It provides cryptographic authentication.

Correct Answer: B. A malfunctioning program may continue servicing it without being correct.

Question 6

Which feature is most important for preventing installation of an older vulnerable firmware image?

A. A larger display.

B. Anti-rollback version control.

C. A faster UART.

D. A higher speaker volume.

Correct Answer: B. Anti-rollback version control.

Question 7

Which statement about encryption and digital signatures is correct?

A. Encryption primarily provides confidentiality, while signatures support authenticity and integrity.

B. Digital signatures eliminate the need for key management.

C. Encryption proves that the sender is authorized to issue every command.

D. A hash and encryption are identical operations.

Correct Answer: A. Encryption primarily provides confidentiality, while signatures support authenticity and integrity.

Question 8

What is a major EMC design objective?

A. Ensure that equipment neither emits nor suffers unacceptable interference.

B. Maximize cable length without considering signal integrity.

C. Remove all grounding connections.

D. Guarantee that software has no logical defects.

Correct Answer: A. Ensure that equipment neither emits nor suffers unacceptable interference.

Question 9

Which practice best supports privacy by design?

A. Collecting all available sensor data indefinitely.

B. Using shared accounts so users cannot be identified.

C. Collecting only necessary data and restricting retention and access.

D. Publishing raw logs for transparency.

Correct Answer: C. Collecting only necessary data and restricting retention and access.

Question 10

What does traceability in a safety lifecycle connect?

A. Only processor speed and memory size.

B. Hazards, requirements, implementation, tests, and evidence.

C. Only supplier invoices and purchase orders.

D. User passwords and network bandwidth.

Correct Answer: B. Hazards, requirements, implementation, tests, and evidence.