Embedded System Design

Embedded System Design by Peter Marwedel explains how models, hardware and software combine in systems that interact with the physical world. The 2021 fourth edition develops timing, energy and dependability constraints through eight main chapters on specification, platforms, evaluation, mapping, optimization and testing. This guide pairs each chapter with a concrete design exercise.

How to use this book

Review programming, basic digital hardware and concurrency before beginning. Use one small controller as a running example so that its requirements remain connected to models, platform choices and validation. Keep functional correctness separate from timing and resource arguments. Attempt the book's exercises and state every assumption used in a schedule or performance estimate.

Chapter-wise explanations and study tasks

Chapter 1: Introduction

Marwedel introduces embedded systems as computing components integrated into larger products and connects them with cyber-physical systems and the Internet of Things. Correct behavior depends on interactions with a physical environment as well as on numerical results. Timing, energy, dependability and resource constraints make design a sequence of trade-offs rather than a simple choice of processor. The opening chapter also establishes a design flow linking requirements, models, implementation and evaluation. Use it to define what the system must achieve before choosing hardware or software. A clear description should include the environment, the observable behavior and the conditions under which that behavior is required.

Study task: Choose an embedded device and state one functional, one timing and one energy constraint. Explain how its environment influences the design.

Chapter 2: Specifications and Modeling

Models make requirements and intermediate design decisions explicit. The chapter surveys models of computation and corresponding languages, including automata, dataflow, Petri nets, discrete-event approaches and conventional programming models. Different representations reveal different aspects of behavior: state changes, concurrency, communication and time may be handled differently. Select a model because its assumptions match the question being asked, not because its notation is familiar. Abstraction removes detail to make reasoning tractable, but an omitted physical or scheduling constraint can later invalidate a conclusion. Compare what two models can express and how each would support analysis before committing to one.

Study task: Describe a small controller as a state machine and as communicating activities. Identify a timing or concurrency issue that becomes clearer in one representation.

Chapter 3: Embedded System Hardware

The hardware chapter connects information processing with the physical world through sensing, actuation and related interfaces. Processing, storage and communication components influence performance, timing, energy use and dependability. Follow the full path from a physical quantity to a sampled representation, computation and a resulting action. A component's headline speed does not by itself establish system performance because memory and communication can constrain useful throughput. Consider precision and interface behavior alongside compute capability. The design task is to select a platform that supports required system behavior under realistic limits, including the costs introduced by moving and storing data.

Study task: Draw the hardware path for a sensor-based controller. Identify a possible limitation at the interface, processor, memory and communication stages.

Chapter 4: System Software

Reusable operating-system and middleware components manage complexity, but they also affect timing and resource use. Embedded software often needs only selected functionality, while real-time requirements make predictable behavior important. The chapter examines requirements for embedded operating systems and issues such as mutually exclusive resource access and priority inversion. A high-priority task may be delayed indirectly by the way other tasks share a resource, so priority labels alone are not a complete timing argument. Map services and synchronization mechanisms to explicit requirements and account for their overhead. Reuse is valuable when the component's assumptions and guarantees fit the application.

Study task: Construct a three-task scenario illustrating priority inversion. Explain why a seemingly unrelated medium-priority task can delay the highest-priority task.

Chapter 5: Evaluation and Validation

Evaluation asks whether a proposed design satisfies its objectives before it is finalized. The chapter addresses execution-time analysis, energy, thermal behavior and dependability, matching model detail to the design question. Worst-case timing cannot be established by simply averaging observed runs, and a simulation supports only the conditions it represents. Reliability and temperature models similarly depend on assumptions that should be recorded. Different techniques offer different forms of evidence, so combine them deliberately rather than treating one successful test as comprehensive validation. The publisher provides a correction to this chapter; consult it alongside the relevant source discussion.

Study task: Create an evidence plan for a deadline-sensitive controller. Separate average measured runtime, worst-case timing evidence and a functional validation check.

Chapter 6: Application Mapping

Mapping assigns application activities to execution resources and determines when they run. Processor selection, task allocation and scheduling interact: placing tasks on multiple cores introduces communication and coordination questions as well as potential parallelism. Design-time scheduling decisions can support timing guarantees when the relevant assumptions hold. Begin with dependencies and execution requirements, then evaluate whether the available platform can accommodate them. A feasible schedule under one workload is not automatically robust to changed execution times or additional tasks. Record deadlines and resource constraints so a mapping can be reviewed when the application evolves.

Study task: Draw a dependency graph for three tasks and propose a mapping to two processors. Check one deadline and identify a communication cost that could alter the result.

Chapter 7: Optimization

Optimization improves selected objectives while preserving required behavior. Embedded design often balances execution time, energy, storage and temperature rather than minimizing one number in isolation. The chapter presents a selection of techniques, including software-oriented improvements, within this constrained design setting. Establish a baseline and define which objective is being changed before making an adjustment. A local improvement can move a bottleneck or worsen another objective, so evaluate the resulting system again. Distinguish an optimization that preserves required semantics from a change in accuracy or functionality, which needs its own justification.

Study task: Propose one software optimization and predict both a benefit and a possible cost. Specify the measurements needed to decide whether the trade-off is acceptable.

Chapter 8: Test

Testing examines whether an implemented or manufactured system operates as expected, including defects introduced during fabrication or use. The chapter introduces fault models, coverage, fault simulation and injection, together with techniques that improve testability. A test's strength depends on the faults it can reveal; passing a test suite does not establish the absence of every possible defect. Design-for-test decisions make internal behavior more observable or controllable. For fault-tolerant systems, test the recovery or resilience claim as well as normal operation. Connect each test with a requirement or a defined fault hypothesis.

Study task: Choose a plausible fault and design a test that could expose it. Explain what a passing result would establish and which faults would remain outside its coverage.

Publisher correction

The catalogue includes a separate correction to Evaluation and Validation. Consult the current chapter listing and correction link when working through Chapter 5. The correction is supplementary and is not counted as a ninth teaching chapter.

Design notebook assignment

Document a controller with requirements, environment assumptions, a behavioral model, an execution platform and a task mapping. Add an evidence table showing which claim is supported by analysis, simulation or testing. Include one rejected alternative and explain the trade-off that ruled it out. Keep estimated and measured quantities visibly separate.

Suggested study plan

1. Read Chapters 1–2 and create a requirements sheet plus a justified model of the running example.
2. Use Chapters 3–4 to propose its hardware and system-software platform, including interfaces and shared resources.
3. Apply Chapters 5–6 to construct a validation plan and a feasible mapping. Record assumptions behind timing claims.
4. Use Chapters 7–8 to assess one optimization and one fault-oriented test, checking that the change preserves required behavior.

Questions for deeper understanding

• Why can a functionally correct result still be wrong for a cyber-physical system?
• Which timing conclusions depend on the chosen model and workload?
• How can a resource-sharing decision undermine a priority-based schedule?
• What evidence is needed to establish that an optimization preserves requirements?

Edition and source coverage

Source edition: Peter Marwedel, fourth edition, Springer, 2021, DOI 10.1007/978-3-030-60910-8. This original study companion follows the verified chapter sequence and the chapter descriptions, abstracts and learning material on the official publisher's book page and linked open-access chapters. The explanations synthesize the main concepts and add original study tasks; they do not reproduce exercise solutions or claim to cover every derivation, dataset or case example. Consult the full chapters for detailed methods, evidence, figures and references.