Embedded Systems Design

Proof required

Submit: (1) the design brief with at least six numbered, quantitative system requirements; (2) the hardware block diagram showing all components and interface protocols/voltages (draw.io is free); (3) a bill of materials (BOM) table listing each component, its function, and whether physical hardware or a free simulator (Wokwi) will be used for the proof.

What gets checked

• Requirements are quantitative and specific — 'power budget: 3.3 V supply, maximum 80 mA average current to achieve 24-hour battery life on a 2000 mAh cell' is a valid requirement; 'low power' is not
• Hardware block diagram labels every interface with protocol and signal level — 'I2C / 3.3 V logic' on the connection between the MCU and the sensor; an unlabelled arrow is not an interface specification
• BOM lists every physical component or simulated component — a BOM that omits passive components (resistors, capacitors, crystal) has not captured the full system cost and complexity

Common mistakes

• Defining requirements that are not verifiable — a requirement that cannot be tested (e.g. 'reliable operation') cannot be used to evaluate whether the design meets it; all requirements must be testable against a measurable criterion
• Producing a software architecture block diagram rather than a hardware block diagram — the M1 diagram shows physical components (ICs, sensors, connectors, power regulators) and their electrical interfaces; a software layer diagram belongs in M2

Resources

What a verifier looks for

• Engineering Design Triad: M1 produces a design artifact (hardware block diagram + BOM) — this is the first of three artifact types required across M1–M3.
• Requirements must be quantitative and testable — check that each requirement has a number, a unit, and an implied test method.
• Hardware block diagram must label all interfaces with protocol and signal level — check that no connections are unlabelled arrows.
• BOM must list all components including passives — check for completeness against the block diagram.
• Reviewer must be an electrical engineer or embedded systems engineer — hardware interface selection and power budget validity require domain expertise.

Proof required

Submit: (1) the complete source code in a public GitHub repository or Wokwi project link; (2) the verification test plan table (requirement number, test method, test condition, expected result, measured result, pass/fail) covering all six requirements; (3) a video or Wokwi simulation link showing the system operating through a complete operational cycle (all states visited, communication output visible); (4) a serial monitor or logic analyser screenshot confirming the communication protocol output for at least one interface.

What gets checked

• Verification test plan maps one-to-one with the M1 requirements — every requirement from M1 has a corresponding test row; a test plan that covers only some requirements has not verified the design
• Measured results are actual measurements, not claimed values — 'measured average current: 73 mA (multimeter reading, full operation)' is a valid measured result; 'should be within spec' is not
• At least four of six requirements pass — a system where fewer than four requirements are verified as passing has not demonstrated a functioning design; requirements that fail must be listed with the measured deviation

Common mistakes

• Writing the verification test plan after implementation to match what was built rather than testing against the original requirements — the test plan must test each numbered M1 requirement; tests that were written to describe what the system does (not what it was required to do) cannot verify requirements
• Skipping the communication interface verification — the serial monitor or logic analyser screenshot is mandatory; a claim that the communication interface works without evidence cannot be accepted

Resources

What a verifier looks for

• Engineering Design Triad: M2 produces an analysis artifact (verification test plan with measured results) and contributes to the design artifact (implemented firmware + hardware setup) — both must be present.
• Verification test plan must cover all six M1 requirements — check each row maps to a numbered requirement.
• Measured results must be actual values — 'should be within spec' fails; 'measured 73 mA, within 80 mA requirement ✓' passes.
• Communication interface verification must be a screenshot — not a verbal claim.
• At least four of six requirements must pass — check the pass/fail column; fewer than four passes means the design has not met its requirements.
• Reviewer must have embedded systems development experience — test plan quality and measurement validity require domain expertise.

Proof required

Submit: (1) the complete embedded systems design report (all sections above, 900–1300 words); (2) the verification results summary table (all six requirements with pass/fail and measured values); (3) a code review record covering the reviewer's two technical challenges and your responses (250 words minimum, attributing the reviewer by professional role and relevant background).

What gets checked

• Component selection rationale for the two critical components cites a specific datasheet specification — 'selected the DHT22 over the DHT11 because the DHT22 has ±0.5°C accuracy (datasheet Table 1) vs. ±2°C for the DHT11; the system requirement is ±1°C' is a valid rationale
• Design tradeoffs section names a specific choice and the alternative rejected — 'chose polling over interrupt-driven sensor sampling because the 100 ms sampling rate allows polling without missing samples; interrupt-driven would add complexity without benefit at this rate' is a valid tradeoff
• Reviewer challenges cover both hardware and firmware — a review that only challenges firmware (no hardware questions) or only hardware (no firmware questions) has not covered the full system

Common mistakes

• Omitting the verification results table — this is the evidence that the system meets its requirements; a report without it is an incomplete engineering document
• Presenting to a reviewer with only software experience and no embedded or hardware knowledge — the hardware design tradeoffs (power, communication protocols, component selection) require hardware domain knowledge to evaluate; a pure software reviewer cannot challenge the hardware design decisions

Resources

What a verifier looks for

• Engineering Design Triad check: M1–M3 together produce a design artifact (hardware block diagram + BOM + firmware architecture diagram), an analysis artifact (verification test plan with measured results), and a documentation artifact (embedded systems design report with tradeoffs and component selection rationale) — confirm all three types are present.
• Verification table must include all six requirements with measured values — check that the table is not a subset of requirements.
• Reviewer must have challenged both a hardware and a firmware decision — check the code review record for both types.
• Component selection rationale must cite datasheet specifications — check that the rationale references a named table, figure, or parameter from the datasheet.
• Reviewer must have embedded systems experience covering both hardware and firmware — a single-discipline reviewer cannot evaluate the full design.
• The Proof Accessibility Rule applies — Wokwi, Arduino IDE, PlatformIO, and draw.io are all free.