11. Embedded System Design and Hardware–Software Co-design

Introduction and Context

An embedded system is a computing system designed to perform a bounded set of functions within a larger electrical, mechanical, or cyber-physical product. Unlike a general-purpose computer, it is normally optimized for a particular application, constrained by cost, energy, physical size, response time, reliability, and environmental conditions. A washing-machine controller, motor drive, automotive airbag controller, smart electricity meter, medical infusion pump, and industrial protection relay are all examples of embedded systems.

Embedded-system design is not simply the selection of a microcontroller and the writing of firmware. It is a systems-engineering activity in which requirements are translated into an architecture, functions are distributed between hardware and software, interfaces are defined, timing is analyzed, and the resulting product is verified under realistic operating conditions. Hardware and software decisions are strongly coupled. A faster processor may simplify software but increase power and cost; a hardware accelerator may improve performance but reduce flexibility; a real-time operating system may improve modularity but introduce memory and scheduling overhead.

Hardware–software co-design provides a disciplined way to make these decisions. It treats the embedded product as one system rather than as two independent engineering projects. The central question is not whether a function can be implemented in hardware or software, but which implementation gives the best balance of performance, cost, energy, reliability, safety, development time, and maintainability over the product life cycle.

Learning Objectives

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

1. Translate product requirements into embedded-system specifications and measurable constraints.

2. Develop a system architecture involving sensors, actuators, processors, memory, communication interfaces, and power circuits.

3. Select a suitable microcontroller, processor, FPGA, or system-on-chip using technical and commercial criteria.

4. Partition functions between hardware and software and justify the partition using trade-off analysis.

5. Model control logic using state machines and design firmware around timing, events, and resources.

6. Plan prototyping, verification, validation, and design iteration.

7. Evaluate cost, performance, power, reliability, security, maintainability, and regulatory implications.

8. Apply co-design principles to an industrial embedded-system scenario.

From Product Requirement to Engineering Specification

The design process begins with a problem expressed in product language. A customer may request a motor controller that is quiet, inexpensive, safe, and capable of maintaining speed under changing load. Such statements are meaningful, but they are not yet sufficient for engineering. They must be converted into measurable requirements.

A useful requirement distinguishes the function, operating condition, performance target, and method of verification. For example, “the controller shall regulate motor speed to within ±1% of the commanded value for loads between 20% and 100% of rated load” is more useful than “the controller shall provide accurate speed control.” Requirements should also identify response time, allowable overshoot, startup behavior, fault response, operating temperature, supply variation, communications protocol, service life, and constraints on size and cost.

Requirements are commonly classified as follows:

• Functional requirements state what the system must do.
• Performance requirements specify speed, accuracy, throughput, latency, or control quality.
• Safety requirements define conditions under which injury, damage, or hazardous operation must be prevented.
• Interface requirements describe electrical, mechanical, communication, and user interfaces.
• Environmental requirements cover temperature, vibration, humidity, electromagnetic interference, and ingress protection.
• Quality requirements address reliability, availability, diagnostic coverage, maintainability, and service life.
• Business constraints include unit cost, development budget, production volume, certification, and schedule.

Traceability is important. Each requirement should be linked to an architectural element, an implementation item, and one or more verification tests. This prevents an attractive prototype from being mistaken for a complete product.

Architectural View of an Embedded System

A typical embedded architecture contains a physical plant, sensors, signal-conditioning circuits, a computing unit, actuators, communication interfaces, power conversion, and human or supervisory interfaces. The processor executes application logic, but dependable operation also depends on reset circuits, clocks, watchdogs, memory protection, non-volatile storage, isolation, grounding, and thermal design.

A useful early model separates the system into four interacting domains:

1. Physical domain: motors, valves, switches, batteries, loads, and environmental conditions.

2. Sensing and actuation domain: transducers, analog front ends, ADCs, DACs, PWM units, drivers, and protection circuits.

3. Computational domain: microcontroller cores, memories, timers, interrupt controllers, accelerators, and operating-system services.

4. Communication and management domain: wired or wireless networks, diagnostics, bootloader, configuration, cybersecurity, and service tools.

The architecture should make data flow and control flow explicit. A temperature sensor may produce an analog voltage, which is filtered, sampled by an ADC, converted into engineering units, checked for plausibility, and used by a control algorithm. A fault may interrupt normal control, enter a safe state, record diagnostic data, and notify a supervisory controller. Such behavior cannot be inferred only from a block diagram; timing and failure behavior must also be modeled.

Selecting the Processing Platform

The choice among an 8-, 16-, or 32-bit microcontroller, digital signal processor, FPGA, application processor, or system-on-chip depends on the application rather than on processor word length alone. Relevant criteria include:

• required computation, interrupt rate, and worst-case execution time;
• RAM, non-volatile memory, peripheral, timer, and communication needs;
• analog resolution and conversion speed;
• hardware security features, debugging support, and safety mechanisms;
• operating voltage, power modes, package, thermal behavior, and lifecycle availability;
• toolchain maturity, software libraries, documentation, and engineering support;
• unit price, development cost, supply-chain risk, and second-source possibilities.

A processor with abundant features is not automatically the best choice. Unused peripherals can increase cost, software complexity, and attack surface. Conversely, selecting a device with little memory or inadequate timer capability can force expensive redesign. Selection should therefore use a weighted decision matrix. For each candidate, the team scores criteria such as real-time capability, cost, power, ecosystem, security, and availability, assigning weights according to project priorities.

Hardware–Software Partitioning

Partitioning determines which functions are implemented as electronic hardware and which are executed by software. Hardware is generally preferred when a function requires very high speed, deterministic timing, parallel operation, continuous signal processing, or direct protection independent of the processor. Software is attractive when algorithms may change, control logic is complex, configuration is frequent, or reuse and maintainability are important.

A protection comparator that disconnects a power stage during overcurrent may be implemented in hardware because a processor interrupt may be too slow or could fail. A diagnostic log, communication protocol, or configurable control law is usually more suitable for software. Functions such as pulse-width modulation may be generated by dedicated timer hardware while the duty cycle is calculated in software.

Partitioning is iterative. The initial architecture is evaluated through timing estimates, memory budgets, power calculations, cost models, and prototype measurements. A function may move from software to hardware if profiling shows that it consumes excessive processor time. It may move in the opposite direction if a hardware implementation becomes difficult to test or cannot accommodate future changes.

Important partitioning questions include:

• Is the required response time hard or soft real-time?
• What is the worst-case, not average, computational load?
• Does the function require precise synchronization with an external signal?
• Will the algorithm change after product release?
• What are the consequences of hardware failure or software failure?
• Can the function be tested independently?
• Does the choice affect cybersecurity, certification, or intellectual property?

The distinction between hard and soft real-time behavior is central. In a hard real-time function, missing a deadline can cause unacceptable or hazardous operation. In a soft real-time function, occasional delay may reduce quality but not cause immediate failure. A motor overcurrent trip is generally hard real-time; updating a maintenance display is usually soft real-time.

Modeling Behavior with State Machines

Many embedded products are reactive: they wait for events, examine inputs, and change behavior. A finite-state machine is therefore a valuable design model. A state represents a mode with defined outputs and permitted events. A transition occurs when an event or condition is detected, and an action may be performed during the transition or on entry into the new state.

Consider a battery-powered controller with the states Off, Startup, Active, Fault, and Shutdown. A valid power command moves the system from Off to Startup. Successful self-test leads to Active. An undervoltage or overtemperature event leads to Fault, where outputs are disabled and a diagnostic code is stored. A reset or authorized recovery command may return the controller to Startup. The model must specify what happens if an event occurs during each state, not merely the normal sequence.

Hierarchical state machines are useful when several states share behavior. For example, a communication-monitoring function may operate in both Active and Service modes, while a common timeout transition leads to a communication fault. State models reduce ambiguous logic, support test-case generation, and make safety behavior visible. They should be accompanied by timing diagrams, interface definitions, and assumptions about event priority.

A common implementation error is to mix long blocking delays with event handling. A better approach is to use timers, scheduled tasks, interrupts for short urgent events, and explicit state transitions. Interrupt service routines should normally capture data or signal an event rather than perform lengthy calculations.

Real-Time Firmware Architecture

Firmware may be organized as a cyclic executive, interrupt-driven program, cooperative scheduler, or real-time operating system. A cyclic executive is small and predictable: tasks execute in a planned sequence. It is suitable when the number of functions is limited and timing is regular. An interrupt-driven design responds quickly to asynchronous events but requires careful control of shared data and interrupt priorities.

A real-time operating system can provide tasks, queues, semaphores, timers, memory protection, and structured communication. It is beneficial when the application contains multiple activities with different rates and priorities. However, an operating system does not automatically make a system real-time. The designer must analyze scheduling, blocking, priority inversion, interrupt latency, stack use, and worst-case execution time.

A robust firmware architecture commonly includes:

• a hardware-abstraction layer for registers and device drivers;
• a board-support package for clocks, pins, memory, and startup;
• middleware for communication, files, diagnostics, or security;
• application services for control, monitoring, and state management;
• a safety or fault-management layer;
• bootloader and update mechanisms.

Clear interfaces between layers improve portability and testing. Coding standards, static analysis, version control, peer review, automated builds, and unit testing are professional necessities rather than optional refinements.

Prototyping, Verification, and Validation

Prototyping reduces uncertainty, but different prototypes answer different questions. A simulation can evaluate an algorithm before hardware exists. A breadboard or development board can test sensor interfaces and processor peripherals. An engineering prototype can investigate thermal, electromagnetic, mechanical, and enclosure issues. A production-intent prototype is needed to validate manufacturability and compliance.

Verification asks whether the design was built correctly against its specification. Validation asks whether the resulting product solves the intended user and system problem. Testing should proceed from unit level to integration, hardware-in-the-loop, environmental, stress, fault-injection, and system-level testing. For real-time systems, tests must include worst-case combinations of interrupts, communication traffic, computation, and sensor activity.

A useful verification plan contains requirement identifiers, test conditions, instrumentation, expected results, acceptance criteria, and records of deviations. Boundary values are especially important: minimum and maximum supply voltage, sensor range, memory capacity, temperature, communication loss, and recovery after reset.

Trade-off Analysis Across the Product Life Cycle

Design decisions should be evaluated over the full life cycle. The lowest component price may not produce the lowest total cost if it requires extensive firmware development, difficult certification, or frequent field service. Similarly, maximum performance may be undesirable if it increases energy consumption or thermal stress.

A practical trade-off matrix can compare alternatives against weighted criteria such as:

| Criterion | Questions to ask |

|---|---|

| Performance | Are throughput and worst-case deadlines satisfied? |

| Cost | What are unit, tooling, development, and maintenance costs? |

| Power | What are active, standby, startup, and fault-mode demands? |

| Reliability | What failures are likely, and how are they detected or contained? |

| Maintainability | Can firmware, components, and diagnostic tools be updated or serviced? |

| Security | Can unauthorized access, modification, or data disclosure be prevented? |

| Supply continuity | Are components available throughout the intended product life? |

| Compliance | Can safety, EMC, radio, or sector-specific requirements be demonstrated? |

Quantitative analysis is preferable where possible. A processor utilization estimate can be expressed as the sum of execution time divided by task period. If utilization approaches the scheduling limit, the design needs margin for variation, diagnostics, communication bursts, and future features. Power budgeting should include conversion losses and transient conditions rather than only nominal consumption.

Applied Case: Illustrative Smart Pump Controller

Background

A manufacturer plans a compact controller for a variable-speed water pump used in a building-services application. The controller must maintain pressure, protect the motor, communicate with a supervisory system, and operate reliably in a warm electrical cabinet. The product is expected to remain serviceable for many years, and the design team has limited development time.

Situation and Problem

The initial proposal uses a low-cost microcontroller and software polling for all measurements. Early tests show that pressure regulation becomes unstable when communication traffic increases. An overcurrent event is also detected too late to protect the power stage consistently. The team must revise the architecture without making the product unaffordable.

Analysis

The requirements reveal two different timing classes. Pressure control requires periodic sampling and bounded control-loop latency. Overcurrent protection requires an immediate independent response. Supervisory communication and display updates are less time-critical. Profiling shows that polling consumes processor time and introduces variable delay. The design also lacks a clear fault state and has no traceable recovery behavior.

Approach and Solution

The team selects a microcontroller with hardware PWM, multiple ADC channels, timer-triggered conversion, a fast comparator input, watchdog support, non-volatile diagnostic storage, and the required communication interface. A hardware comparator disables the gate-driver enable line when current exceeds a safe threshold. The comparator also signals the processor so that the event can be logged.

The pressure-control loop is scheduled at a fixed rate using a timer-triggered ADC sequence. Software filters the measurement, checks plausibility, executes the control algorithm, and updates the PWM duty cycle. Communication is handled through interrupt-driven buffering and a lower-priority task. A hierarchical state machine defines Off, Starting, Running, Limiting, Fault, and Service states. Every state specifies actuator behavior, accepted commands, timeout response, and diagnostic records.

The team conducts processor-utilization analysis, fault-injection tests, thermal tests, communication-loss tests, and hardware-in-the-loop testing. The design includes a watchdog, brownout reset, startup self-test, protected configuration parameters, and a bootloader that validates firmware before activation.

Outcome

The revised architecture separates urgent protection from configurable control functions. Control-loop timing becomes predictable, communication no longer disrupts regulation, and fault behavior is observable and testable. Although the selected microcontroller costs more than the original device, the total design is less expensive because it avoids an external timing circuit, reduces debugging effort, and improves service diagnostics.

Learning Points

The case illustrates that component cost alone is an inadequate optimization target. Correct partitioning places safety-critical, time-sensitive protection in dedicated hardware while retaining adaptable control and communication functions in software. It also demonstrates the value of explicit state modeling, traceability, profiling, and verification under abnormal conditions.

Risks, Common Mistakes, and Professional Responsibilities

A frequent mistake is beginning implementation before requirements and interfaces are stable. Other errors include designing for average timing instead of worst-case timing, ignoring startup and brownout behavior, using blocking delays, failing to protect shared data, and treating watchdog reset as a complete fault-management strategy. Insufficient memory margin, undocumented assumptions, obsolete development tools, and unverified third-party libraries create additional risk.

Security must be considered even in systems that are not connected directly to the internet. Debug ports, firmware-update paths, communication buses, configuration memory, and service interfaces can become attack points. Appropriate measures may include secure boot, signed updates, access control, key protection, input validation, logging, and disabling unused interfaces. Security controls must be balanced with recovery and maintenance requirements.

Safety-related systems require hazard analysis, risk reduction, independence of protection mechanisms, evidence of verification, and suitable standards for the application domain. Engineers have a professional obligation to report unsafe assumptions, preserve design evidence, protect user data, and avoid claiming compliance without objective justification. Environmental responsibility also matters: long product life, repairability, energy efficiency, and responsible component selection reduce the broader impact of embedded products.

Emerging Directions and Best Practices

Contemporary embedded designs increasingly combine microcontrollers with secure elements, wireless connectivity, machine-learning accelerators, and cloud-connected maintenance services. Tiny machine-learning models can support anomaly detection locally, reducing communication latency and protecting raw data. Digital twins and hardware-in-the-loop platforms allow control algorithms and failure scenarios to be evaluated before field deployment. Automated requirements traceability, continuous integration, static analysis, and automated regression testing are becoming standard in disciplined development environments.

These technologies do not remove the need for engineering judgment. A connected system enlarges the attack surface; an artificial-intelligence model may be difficult to explain or validate; and an update mechanism creates long-term operational responsibility. The most durable practice remains a structured flow from requirement to architecture, partition, implementation, verification, validation, and field feedback.

A strong co-design process therefore follows these principles:

• define measurable requirements and maintain traceability;
• analyze timing, memory, power, safety, and security early;
• select components using life-cycle rather than purchase cost alone;
• keep safety protection independent where appropriate;
• model behavior, faults, and recovery explicitly;
• prototype the highest technical risks first;
• automate builds and tests while retaining engineering review;
• design for diagnostics, updates, maintainability, and end-of-life support.

Chapter Summary

Embedded-system design is a coordinated systems-engineering process. Product requirements must be converted into measurable functional, timing, safety, environmental, and business constraints. Architecture then connects the physical plant, sensing and actuation circuits, processing platform, communications, power, and supervisory functions.

Hardware–software co-design evaluates the best location for each function. Hardware provides speed, parallelism, deterministic response, and independent protection; software provides adaptability, algorithmic complexity, configurability, and maintainability. State machines, real-time scheduling, profiling, and interface abstraction support disciplined implementation. Prototyping and verification must cover normal, boundary, fault, environmental, and timing conditions. Final decisions should balance performance, cost, power, reliability, security, supply continuity, compliance, and life-cycle maintenance. The smart pump case demonstrates how explicit partitioning and fault modeling can improve both technical performance and total product value.

Key Terms

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

Hardware–software co-design: Joint development and optimization of hardware and software as one system.

Requirement traceability: Linking each requirement to design elements, implementation, and verification evidence.

Real-time system: A system whose correctness depends partly on producing results within specified time limits.

Hard real-time: A timing constraint whose violation may cause unacceptable or hazardous operation.

Soft real-time: A timing constraint where occasional deadline violation degrades performance but is not necessarily catastrophic.

System architecture: The organized structure of components, interfaces, functions, and interactions.

Hardware–software partitioning: Allocation of system functions to physical hardware or executable software.

Finite-state machine: A behavioral model consisting of states, events, transitions, and actions.

Worst-case execution time: The maximum time a task can require under defined conditions.

Cyclic executive: A firmware organization in which tasks execute in a predetermined repeating schedule.

Interrupt service routine: A short program executed in response to an interrupt event.

Watchdog: A timer that initiates recovery when software fails to service it within a specified interval.

Hardware-in-the-loop: Testing in which real hardware interacts with a simulated plant or environment.

Fault injection: Deliberate introduction of faults to evaluate detection, containment, and recovery.

Bootloader: Startup software that initializes a device and may verify or update application firmware.

Secure boot: A process that permits execution only of authenticated and authorized firmware.

Total cost of ownership: The complete cost of development, production, operation, maintenance, and retirement.

Review Questions

Short Answer Questions

1. Why must product requirements be converted into measurable engineering specifications?

2. Distinguish between hard and soft real-time behavior with one example of each.

3. What factors should be considered when selecting a microcontroller?

4. Why are finite-state machines useful in embedded firmware design?

5. Differentiate verification from validation.

Long Answer Questions

1. Explain a systematic process for translating product requirements into an embedded-system architecture.

2. Discuss the principles and trade-offs of hardware–software partitioning.

3. Describe how a real-time firmware architecture can combine interrupts, scheduled tasks, and an operating system.

4. Explain how cost, performance, power, maintainability, reliability, and security should be evaluated together.

5. Discuss the role of prototyping, hardware-in-the-loop testing, fault injection, and traceability in embedded-system development.

Analytical / Application Questions

1. A controller misses a motor-protection deadline whenever a communication message is received. Propose a revised hardware–software partition and justify it.

2. Develop a finite-state-machine outline for a battery charger containing Idle, Charging, Complete, Fault, and Service states. Specify at least two transitions and the associated safety actions.

3. Two processors meet computational requirements, but one has poorer tool support and uncertain long-term availability. Construct a decision framework for selecting between them.

22. Multiple Choice Questions with Answers

Question 1

Which function is most suitable for implementation in independent hardware rather than ordinary application software?

A. Displaying a maintenance message

B. Logging operating hours

C. Immediate overcurrent shutdown

D. Updating a configurable control parameter

Correct Answer: C. Immediate overcurrent shutdown

Question 2

What is the primary purpose of requirements traceability?

A. To increase processor clock frequency

B. To link requirements with design, implementation, and verification evidence

C. To eliminate the need for system testing

D. To reduce the number of sensors

Correct Answer: B. To link requirements with design, implementation, and verification evidence

Question 3

A function is hard real-time when

A. it uses a 32-bit processor

B. it must always produce a result within a specified deadline

C. it communicates through a network

D. its algorithm can be changed after deployment

Correct Answer: B. it must always produce a result within a specified deadline

Question 4

Which design choice best improves predictability of a periodic control loop?

A. Polling all devices in an uncontrolled loop

B. Using timer-triggered sampling and scheduled execution

C. Adding display updates to the highest-priority interrupt

D. Using indefinite blocking delays

Correct Answer: B. Using timer-triggered sampling and scheduled execution

Question 5

In a finite-state machine, a transition represents

A. the physical size of a memory device

B. a change from one defined behavior mode to another due to an event or condition

C. the conversion of analog data into digital data

D. a compiler optimization

Correct Answer: B. a change from one defined behavior mode to another due to an event or condition

Question 6

Why may a more expensive microcontroller reduce total product cost?

A. It always consumes more power

B. It can reduce external circuitry, development effort, and service cost

C. It removes the need for requirements

D. It guarantees that software cannot fail

Correct Answer: B. It can reduce external circuitry, development effort, and service cost

Question 7

Which activity is an example of validation rather than verification?

A. Checking whether source code follows a coding rule

B. Measuring whether an ADC meets its specified resolution

C. Determining whether the finished pump satisfies the intended pressure-control need

D. Confirming that a watchdog timer resets the processor

Correct Answer: C. Determining whether the finished pump satisfies the intended pressure-control need

Question 8

What is a major risk of relying only on average processor utilization?

A. Average utilization measures package temperature exactly

B. It can hide deadline violations during worst-case task combinations

C. It prevents use of interrupts

D. It automatically increases memory capacity

Correct Answer: B. It can hide deadline violations during worst-case task combinations

Question 9

Which feature most directly supports authenticated firmware updates?

A. Secure boot and digital-signature verification

B. A larger heatsink

C. A faster ADC

D. A lower-resolution timer

Correct Answer: A. Secure boot and digital-signature verification

Question 10

In the smart pump case, communication was assigned lower priority mainly because

A. communication is never needed

B. pressure regulation and protection have more stringent timing requirements

C. communication cannot be implemented in software

D. the supervisory system controls the motor directly

Correct Answer: B. pressure regulation and protection have more stringent timing requirements