Embedded Systems Foundations and Design Context

Introduction and Context

Embedded systems are computing systems designed to perform dedicated functions within larger products, machines, or infrastructures. Unlike general-purpose computers, which are intended to execute a wide variety of applications, an embedded system is optimized for a defined operational purpose. It may control a motor, monitor a patient, regulate a vehicle engine, manage a communication link, or coordinate an industrial process.

Modern embedded systems are rarely isolated digital circuits. They interact with sensors, actuators, communication networks, users, physical processes, and cloud services. Consequently, embedded-system design is increasingly understood through the broader concept of the cyber-physical system (CPS): a system in which computational components monitor and influence physical processes through tightly integrated feedback loops.

The subject therefore involves more than microprocessors and programming. It includes requirements engineering, hardware–software co-design, real-time behavior, dependability, security, energy management, verification, manufacturing, maintenance, and regulatory compliance. At postgraduate level, embedded systems should be viewed as multidisciplinary engineered systems whose technical decisions are constrained by physical, economic, safety, and societal considerations.

Learning Objectives

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

1. Define embedded systems and cyber-physical systems and distinguish them from general-purpose computing.

2. Classify embedded applications according to function, timing, connectivity, criticality, and scale.

3. Explain major constraints and quality attributes that shape embedded-system architecture.

4. Interpret important design metrics, trade-offs, and terminology.

5. Describe the evolution of embedded computing and its industrial significance.

6. Analyze a representative embedded-system design problem using a systematic framework.

7. Recognize contemporary issues involving security, safety, sustainability, artificial intelligence, and regulation.

1. What Is an Embedded System?

An embedded system is a programmable or partly programmable computing system incorporated into a larger product or environment to perform one or more dedicated functions. Its identity is determined not merely by the presence of a processor, but by the relationship between computation and the host system.

Four characteristics are especially important:

• Functional specialization: The system is designed around a defined set of functions.
• Integration: Computing hardware and software are embedded within a larger electrical, mechanical, or cyber-physical product.
• Resource constraints: Processing capacity, memory, energy, physical space, and cost are often limited.
• Interaction with the environment: The system commonly receives inputs from sensors and produces outputs through actuators, displays, networks, or control interfaces.

A washing-machine controller, for example, measures water level and temperature, interprets user commands, drives valves and motors, and enforces safety conditions. The controller is not normally used to run arbitrary desktop applications; its computing capability is organized around appliance operation.

The term embedded does not imply that a system must be small. A vehicle electronic control unit, a telecommunications base station, and an aircraft flight-control computer may contain substantial computing resources while still being embedded because their computation is dedicated to a larger system.

Embedded, General-Purpose, and Application-Specific Computing

A general-purpose computer is designed to support changing applications selected by users. An embedded system is designed around the requirements of its host product. The boundary is not absolute: smartphones, routers, industrial PCs, and edge-computing devices combine general-purpose operating environments with specialized embedded functions.

An application-specific integrated circuit (ASIC) implements a function in dedicated hardware. A microcontroller unit (MCU) combines a processor core, memory, timers, input/output, and peripherals on one integrated circuit. A microprocessor unit (MPU) generally requires external memory and peripheral components and is used when higher performance or richer operating systems are required. A field-programmable gate array (FPGA) permits hardware functionality to be configured after manufacture, allowing parallel processing and flexible interfaces.

These technologies form a design spectrum:

• Software on a general-purpose processor offers flexibility.
• An MCU offers low cost and integrated control.
• An FPGA offers configurable hardware parallelism.
• An ASIC offers high efficiency and potentially high volume economies, but has high non-recurring development cost and limited post-manufacture flexibility.

2. Cyber-Physical Systems

A cyber-physical system combines computational elements with physical processes through sensing, computation, communication, and actuation. The physical process evolves according to natural laws, while the cyber component observes and influences it.

A useful conceptual loop is:

physical process → sensors → computation and decision-making → actuators → physical process

Communication networks, human operators, and supervisory software may participate in the loop. Examples include autonomous vehicles, smart electrical grids, robotic manufacturing cells, medical infusion systems, and intelligent building controls.

The central difficulty in CPS design is that correctness has both computational and physical dimensions. A controller may produce logically correct output but still fail if the sensor is miscalibrated, an actuator saturates, communication is delayed, or the physical process changes faster than the controller can respond. Timing, uncertainty, noise, and failure modes therefore become integral design concerns.

A CPS should not be confused with an Internet of Things (IoT) device. IoT emphasizes connected sensing and communication among devices and services. CPS emphasizes the interaction between computation and physical dynamics. A device may be IoT-connected without exercising meaningful physical control, while a CPS may operate locally without Internet connectivity.

Feedback and Closed-Loop Behavior

In an open-loop system, commands are issued without using measured output to correct operation. In a closed-loop system, sensors measure the process and the controller adjusts the actuation based on the measured state. Closed-loop control can improve accuracy and disturbance rejection, but it introduces requirements for sensor quality, timing, stability, and fail-safe behavior.

For example, a thermostat compares measured temperature with a desired temperature and switches heating equipment accordingly. The embedded controller must account for measurement delay, actuator limits, hysteresis, and abnormal conditions such as a failed temperature sensor.

3. Classification of Embedded Applications

No single classification captures all embedded systems. Several dimensions are useful in architecture and requirements analysis.

By Application Domain

1. Consumer electronics: cameras, audio equipment, smart appliances, wearables, and entertainment systems.

2. Automotive systems: engine control, braking, airbag deployment, driver assistance, battery management, and infotainment.

3. Industrial automation: programmable controllers, motor drives, process instrumentation, robotics, and condition monitoring.

4. Avionics and aerospace: flight control, navigation, mission computers, satellite payloads, and spacecraft power management.

5. Medical systems: patient monitoring, imaging, infusion pumps, prosthetics, and diagnostic instruments.

6. Telecommunications and networking: routers, switches, radio units, optical transport systems, and base stations.

7. Energy and infrastructure: smart meters, protection relays, renewable-energy converters, and grid controllers.

8. Defense and security: radar, guidance, surveillance, secure communications, and unmanned systems.

By Timing Requirements

A hard real-time system must meet specified deadlines because a late result is considered a system failure. Airbag deployment and certain protection functions are examples. In a firm real-time system, an occasional late result may have no value, although the system may continue operating. In a soft real-time system, late results degrade quality but do not necessarily cause failure, as in multimedia streaming.

Real-time does not mean “fast” in an unrestricted sense. It means that the correctness of an operation depends on both its logical result and the time at which that result is produced. A slower system with a predictable worst-case response can be more suitable than a faster but unpredictable system.

By Scale and Complexity

Small systems may use an 8-bit or 32-bit MCU, bare-metal firmware, and a small number of peripherals. Medium-complexity systems may use an RTOS, multiple communication interfaces, and a graphical user interface. Large systems may use multicore processors, virtualization, Linux or another rich operating system, distributed networks, and hardware acceleration.

By Connectivity

Systems may be stand-alone, locally networked, Internet-connected, or distributed across edge and cloud platforms. Connectivity increases functionality but also creates attack surfaces, dependency on communication availability, and requirements for secure updating and identity management.

By Criticality

A non-critical system may tolerate malfunction with inconvenience or economic loss. A safety-critical system can cause injury or death if it fails. Mission-critical systems threaten the success of a mission, while business-critical systems can cause major financial or operational damage. Criticality influences assurance activities, redundancy, testing, documentation, and regulatory obligations.

4. Constraints and Quality Attributes

Embedded-system design is fundamentally a constrained optimization problem. Improving one attribute often harms another. Increasing processor frequency may reduce execution time but increase energy consumption, heat, and cost. Adding redundancy may improve availability but increase mass, complexity, and verification effort.

Principal Constraints

• Cost: Includes component cost, tooling, software development, certification, manufacturing, maintenance, and disposal.
• Size and mass: Important in wearables, aerospace, portable medical equipment, and automotive installations.
• Energy: Battery-operated products require low active and sleep power; energy harvesting systems may have intermittent supply.
• Performance: Includes computation rate, data throughput, response time, and latency.
• Memory: Includes program memory, data memory, buffer space, and nonvolatile storage.
• Thermal limits: Heat generation affects reliability, packaging, and permissible operating frequency.
• Time to market: Architecture should support predictable development and maintainability.
• Environmental conditions: Temperature, vibration, humidity, radiation, electromagnetic interference, and shock may affect operation.
• Regulatory requirements: Medical, automotive, avionics, industrial, and radio products are subject to domain-specific standards.

Quality Attributes

Reliability is the probability that a system performs its required function for a specified time under stated conditions. Availability concerns the proportion of time a system is operational, including the effects of repair and recovery. Safety concerns freedom from unacceptable risk of physical harm. Security protects confidentiality, integrity, authenticity, and availability against intentional or accidental threats.

Other important attributes include usability, maintainability, portability, scalability, interoperability, testability, upgradeability, and sustainability. These attributes must be expressed as measurable requirements wherever possible. “Low power” is inadequate unless accompanied by conditions such as a maximum active current, sleep current, duty cycle, or battery-life target.

Safety and security are related but distinct. A safety failure may arise from random hardware faults or design errors; a security failure may be deliberately induced by an adversary. A compromised device can create a safety hazard, so modern CPS engineering increasingly treats safety and security as interacting properties.

5. Design Metrics and Trade-Off Analysis

Design metrics provide a basis for comparing architectures. Common metrics include:

• execution time and worst-case response time;
• throughput and communication bandwidth;
• memory utilization;
• energy per operation and average power;
• unit cost and non-recurring engineering cost;
• physical dimensions and mass;
• reliability, availability, and fault coverage;
• development time and lifecycle cost.

For a device operating at power \(P(t)\) over an interval from \(t_0\) to \(t_1\), energy is

\[

E = \int_{t_0}^{t_1} P(t)\,dt.

\]

If power is constant, this becomes \(E=P\Delta t\). Here, power is measured in watts, time in seconds, and energy in joules. For a battery-powered device, the usable energy is limited by battery characteristics, conversion losses, temperature, aging, and discharge conditions; therefore, the equation estimates consumption and does not by itself guarantee battery life.

If a system has active power \(P_a\) for fraction \(D\) of the time and sleep power \(P_s\) for fraction \(1-D\), its ideal average power is

\[

P_{avg}=D P_a+(1-D)P_s,

\]

assuming only these two operating states and a steady duty cycle. Transition energy and other modes must be included when they are significant.

Worked Example: Duty-Cycled Energy

An environmental sensor consumes 80 mW while measuring and transmitting, and 0.8 mW in sleep. It is active for 2% of each cycle. Under the two-state assumption,

\[

P_{avg}=0.02(80)+0.98(0.8)=1.6+0.784=2.384\text{ mW}.

\]

Over 24 hours, the ideal energy consumption is

\[

E=2.384\text{ mW}\times24\text{ h}=57.216\text{ mWh}.

\]

Actual battery duration will be lower or otherwise different if regulator losses, battery self-discharge, temperature effects, or additional operating modes are present. The example illustrates why duty-cycle management is often more effective than optimizing only active-mode power.

Multiobjective Decisions

A design should not optimize a single metric without considering constraints. A useful engineering approach is to identify mandatory limits first—for example, a deadline, maximum temperature, safety integrity target, or battery life—and then compare feasible alternatives using cost, flexibility, and maintainability. Weighted scoring can support early trade studies, but weights are engineering judgments rather than universal truths. Sensitivity analysis is advisable when a decision depends strongly on uncertain assumptions.

6. Essential Terminology and Architectural Concepts

Firmware is software stored in nonvolatile memory and closely associated with hardware operation. Bare-metal software runs without a general-purpose operating system, although it may use interrupt handlers, drivers, and scheduling code. An RTOS provides services such as task scheduling, synchronization, timers, and inter-task communication with attention to temporal behavior.

A device driver mediates between software and a hardware peripheral. An interrupt is an event that causes the processor to suspend its current execution and invoke a service routine. Polling repeatedly checks a condition in software. Interrupts can improve responsiveness and reduce unnecessary checking, but excessive interrupt activity can create jitter and analysis difficulty.

A sensor converts a physical quantity into a measurable signal; an actuator converts a control signal into physical action. An ADC converts an analog signal into a digital representation, while a DAC performs the reverse conversion. DMA transfers data between peripherals and memory with limited processor involvement.

A real-time operating system, middleware, bootloader, board support package, and hardware abstraction layer separate different concerns and can improve portability. However, abstraction can introduce memory use, execution overhead, hidden timing behavior, and debugging complexity. The correct abstraction level depends on requirements rather than fashion.

7. Evolution of Embedded Computing

Early embedded controllers were built from dedicated logic and electromechanical components. The development of microprocessors enabled programmable control, while microcontrollers integrated processor, memory, timers, and I/O into economical single-chip devices. This integration reduced board size and cost and enabled mass-market products.

Later generations introduced 16-bit and 32-bit architectures, digital signal processors, advanced timers, communication peripherals, and low-power modes. Real-time kernels and embedded operating systems supported larger applications. FPGAs and system-on-chip devices enabled programmable hardware, multicore processing, graphics, and specialized accelerators.

The current evolution has several themes:

• Networked embedded systems: Devices exchange data locally and through cloud services.
• Edge computing: Processing is moved close to sensors and users to reduce latency, bandwidth, or privacy exposure.
• Heterogeneous computing: CPUs, GPUs, DSPs, neural-processing units, and programmable logic cooperate.
• Software-defined functionality: Features are increasingly changed through firmware and secure updates rather than hardware replacement.
• Digital twins: A physical asset is represented by a computational model that supports monitoring, diagnosis, and optimization.
• AI at the edge: Machine-learning inference is performed near the data source, subject to memory, energy, explainability, and safety constraints.
• Open architectures and reusable platforms: Standard instruction sets, interfaces, middleware, and reference designs can reduce development effort while introducing supply-chain and integration considerations.

This evolution also increases system complexity. A connected product may contain millions of lines of software, third-party libraries, multiple processors, wireless interfaces, and a long operational lifetime. Traditional functional testing alone is insufficient; lifecycle security, update mechanisms, observability, formal analysis where appropriate, and systems engineering become increasingly important.

8. Design Context and Development Process

A robust embedded project begins with the operational context rather than immediate component selection. Engineers should identify stakeholders, physical processes, operating environments, hazards, interfaces, maintenance assumptions, and lifecycle obligations.

A typical process includes:

1. Requirements analysis: Define functions, timing, performance, energy, environmental, safety, security, and regulatory requirements.

2. System decomposition: Partition functions among sensors, actuators, processors, programmable logic, networks, and human interfaces.

3. Architecture selection: Compare MCU, MPU, FPGA, ASIC, and distributed alternatives.

4. Hardware–software partitioning: Decide which operations require hardware acceleration, deterministic firmware, an RTOS, or a rich operating system.

5. Implementation: Develop hardware, firmware, drivers, communication protocols, and diagnostic facilities.

6. Verification and validation: Verify that implementation satisfies specifications and validate that the complete product solves the intended operational problem.

7. Deployment and lifecycle management: Support production programming, secure updates, monitoring, maintenance, decommissioning, and incident response.

Requirements should be traceable from stakeholder needs to tests. Interface specifications must define units, ranges, timing, error behavior, synchronization, and ownership of resources. Early prototypes should expose uncertainty, but prototypes should not be mistaken for evidence of production readiness.

9. Case Study: Safety-Oriented Battery Management Controller

The following is an illustrative case, not a description of a particular commercial product.

Background

A lithium-ion battery pack for an electric mobility platform requires monitoring and control. The embedded battery-management controller measures cell voltages, pack current, temperature, and insulation-related conditions. It estimates state of charge, balances cells when appropriate, controls contactors, communicates with a vehicle controller, and prevents unsafe operation.

Problem

The design must operate from a constrained energy budget, respond within specified time limits, tolerate sensor faults, resist unauthorized commands, and remain dependable across temperature and battery aging. A failure could cause loss of mobility, battery damage, fire, or injury.

Analysis

The system is both embedded and cyber-physical: it computes decisions while influencing a physical energy-storage process. It has hard or firm timing requirements for protective actions, while state-of-charge estimation may be soft real-time. Safety and security interact because an attacker who alters measurements or commands may create a physical hazard.

Key requirements include bounded measurement latency, detection of overvoltage and overtemperature, controlled contactor operation, diagnostic coverage, nonvolatile event logging, authenticated communication, and a defined safe state. The architecture must also account for ADC accuracy, sensor plausibility checks, isolation, electromagnetic interference, and degraded operation when communication is unavailable.

Approach and Solution

A layered design separates measurement acquisition, signal validation, estimation, protection logic, communication, and diagnostics. Independent plausibility checks compare related measurements—for example, pack current with expected contactor behavior. Protection paths are designed to move the system to a safe state even if higher-level estimation software becomes unavailable. A watchdog detects selected classes of software nonresponse, while carefully analyzed reset behavior prevents unsafe repeated switching.

The development process uses hazard analysis, fault-injection testing, boundary-value tests, hardware-in-the-loop simulation, code review, and traceability from safety requirements to verification evidence. Security controls include authenticated firmware updates, protected debugging interfaces, secure communication, key management, and event logging.

Outcome

The resulting design is not judged only by nominal state-of-charge accuracy. It is evaluated by response deadlines, safe behavior under sensor and communication faults, resistance to unauthorized modification, thermal performance, maintainability, and evidence supporting applicable safety and cybersecurity requirements.

Learning Points

1. Embedded design begins with operational hazards and interfaces, not only processor selection.

2. A CPS requires reasoning about physical dynamics, timing, uncertainty, and computation together.

3. Safety, security, reliability, and maintainability must be addressed across the lifecycle.

4. Redundancy and diagnostics are useful only when their failure behavior is understood and verified.

5. A technically sophisticated algorithm cannot compensate for poorly specified sensors, actuators, or system boundaries.

10. Challenges, Ethics, and Governance

Embedded products increasingly collect personal, location, biometric, and operational data. Designers must apply data minimization, access control, secure storage, transparent consent, and appropriate retention policies. A device should not collect information merely because collection is technically possible.

Safety-critical and medical systems require disciplined risk management, controlled changes, documentation, and evidence-based verification. Radio devices must satisfy spectrum and electromagnetic-compatibility requirements. Connected products require vulnerability disclosure, patch processes, software bill of materials practices, and end-of-support policies. Exact obligations vary by jurisdiction and application domain, so engineers must consult applicable standards and regulators rather than treating compliance as a generic checklist.

Artificial intelligence introduces additional concerns: data quality, distribution shift, explainability, adversarial inputs, uncertain confidence, and difficulty demonstrating deterministic behavior. An AI classifier may assist diagnosis or predictive maintenance, but safety decisions may require independent monitoring, bounded fallback behavior, and human or rule-based oversight.

Sustainability includes energy efficiency during operation, repairability, long-term software support, material selection, supply-chain impacts, and responsible recycling. A low-power product that becomes unusable because its software cannot be updated may have poor lifecycle sustainability.

Best Practices

• Define measurable functional, temporal, safety, security, and environmental requirements.
• Select architecture using lifecycle metrics, not processor performance alone.
• Separate safety mechanisms from ordinary convenience functions where justified by hazard analysis.
• Make timing, resource use, faults, and degraded modes observable and testable.
• Use modular interfaces and traceable configuration management.
• Treat update, credential, logging, and end-of-life provisions as design requirements.
• Validate assumptions with measurement, worst-case analysis, and representative environmental testing.
• Consider repair, reuse, energy, and disposal during early architecture decisions.

Chapter Summary

An embedded system is a computing system integrated into a larger product to perform dedicated functions. Its design is shaped by specialization, physical interaction, resource constraints, timing, cost, environmental conditions, and lifecycle obligations. A cyber-physical system extends this idea by emphasizing feedback between computation and physical processes.

Embedded applications range from consumer products and vehicles to industrial, medical, aerospace, energy, and telecommunications systems. They can be classified by timing behavior, criticality, scale, connectivity, and domain. Important quality attributes include performance, energy efficiency, reliability, availability, safety, security, maintainability, and sustainability. These attributes compete, so architecture requires explicit trade-off analysis.

The evolution from dedicated logic to microcontrollers, real-time operating systems, networked devices, heterogeneous system-on-chip platforms, edge computing, and AI-enabled systems has increased capability and complexity. Effective design therefore requires systems engineering, hardware–software co-design, requirements traceability, verification, secure lifecycle management, and awareness of ethical and regulatory responsibilities.

Key Terms

Embedded system: A computing system integrated into a larger product for dedicated functions.

Cyber-physical system: A system integrating computation, communication, sensing, actuation, and physical processes.

Microcontroller unit: An integrated circuit containing a processor, memory, and peripheral interfaces for control applications.

Microprocessor unit: A processor generally requiring external memory and peripherals.

FPGA: Reconfigurable digital hardware used to implement flexible parallel logic.

ASIC: Application-specific integrated circuit designed for a particular function.

Firmware: Software closely associated with and stored in embedded hardware.

Real-time system: A system whose correctness depends on producing results within specified timing constraints.

Hard real-time: Timing class in which a missed deadline constitutes system failure.

Soft real-time: Timing class in which lateness degrades performance but is not necessarily catastrophic.

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

Actuator: Device that converts a control signal into physical action.

RTOS: Operating system providing services designed for predictable, time-constrained execution.

ADC: Analog-to-digital converter.

DMA: Direct memory access, allowing data transfer with limited processor intervention.

Reliability: Probability of performing a required function for a stated period under stated conditions.

Availability: Fraction or probability of time that a system is operational and accessible.

Safety: Freedom from unacceptable risk of harm.

Security: Protection against unauthorized access, alteration, disclosure, or disruption.

Edge computing: Processing performed near data sources or users rather than exclusively in a remote cloud.

Review Questions

Short Answer Questions

1. What distinguishes an embedded system from a general-purpose computer?

2. Define a cyber-physical system and identify its principal feedback loop.

3. Differentiate hard, firm, and soft real-time systems.

4. State four constraints commonly encountered in embedded-system design.

5. Why are safety and security related but distinct properties?

Long Answer Questions

1. Explain how MCU, MPU, FPGA, and ASIC technologies occupy different positions in the embedded-computing design spectrum.

2. Discuss the major quality attributes of an embedded system and explain why they create architectural trade-offs.

3. Describe a systematic embedded-system development process from requirements analysis through lifecycle management.

4. Explain how the evolution of networked, heterogeneous, and AI-enabled embedded systems changes verification and maintenance.

5. Discuss the relationship between embedded systems and cyber-physical systems using examples from two industrial domains.

Analytical / Application Questions

1. A battery-powered sensor is active at 60 mW for 5% of its duty cycle and consumes 1 mW otherwise. Calculate its ideal average power and explain two reasons why actual battery life may differ from an estimate based on this value.

2. Propose an architecture for a networked industrial motor controller. Justify processor, timing class, communication, safety, diagnostic, and security choices.

3. Analyze the illustrative battery-management case from the perspectives of sensing, control, real-time behavior, safety, security, and lifecycle sustainability.

Multiple Choice Questions with Answers

Question 1

Which characteristic most directly distinguishes an embedded system from a general-purpose computer?

A. It always uses an 8-bit processor

B. It performs dedicated functions within a larger system

C. It cannot communicate over a network

D. It never runs an operating system

Correct Answer: B. It performs dedicated functions within a larger system

Question 2

What is the defining concern of a hard real-time system?

A. Maximum user interface quality

B. Unlimited computational throughput

C. A missed deadline can constitute system failure

D. Operation exclusively without an operating system

Correct Answer: C. A missed deadline can constitute system failure

Question 3

Which sequence best represents a typical cyber-physical feedback loop?

A. Actuator, sensor, cloud, battery

B. Sensor, computation, actuator, physical process

C. Memory, compiler, display, keyboard

D. Network, processor, file, printer

Correct Answer: B. Sensor, computation, actuator, physical process

Question 4

Which technology generally integrates a processor, memory, timers, and I/O on one chip?

A. MCU

B. ASIC only

C. Mechanical relay

D. External hard disk

Correct Answer: A. MCU

Question 5

A sensor consumes 80 mW for 2% of its time and 0.8 mW for the remaining 98%. What is its ideal average power?

A. 1.60 mW

B. 2.384 mW

C. 8.00 mW

D. 40.40 mW

Correct Answer: B. 2.384 mW

Question 6

Which quality attribute primarily concerns freedom from unacceptable physical harm?

A. Portability

B. Usability

C. Safety

D. Scalability

Correct Answer: C. Safety

Question 7

Why can a faster processor be unsuitable for an embedded product?

A. Higher speed always prevents communication

B. It may increase energy consumption, heat, and cost

C. It cannot execute firmware

D. It eliminates all timing predictability

Correct Answer: B. It may increase energy consumption, heat, and cost

Question 8

What is the principal role of an actuator in a cyber-physical system?

A. To convert a physical quantity into a measured signal

B. To store program instructions permanently

C. To convert a control signal into physical action

D. To authenticate a firmware image

Correct Answer: C. To convert a control signal into physical action

Question 9

Which statement best describes edge computing?

A. All processing is performed in a distant cloud

B. Processing is performed near the data source or user

C. Processing is replaced by analog circuitry

D. Only offline systems can use it

Correct Answer: B. Processing is performed near the data source or user

Question 10

Which practice most directly supports secure embedded-system lifecycle management?

A. Disabling all diagnostics permanently

B. Avoiding software updates after deployment

C. Authenticated firmware updates and vulnerability processes

D. Using the highest possible processor frequency

Correct Answer: C. Authenticated firmware updates and vulnerability processes