Requirements and System Architecture

Embedded hardware design starts with architecture, not part numbers. A good architecture defines what the product must do, what it connects to, how power and data move, what can fail, and how the design will be verified.

Learning Objectives

By the end of this lesson, you should be able to write measurable hardware requirements, create a system block diagram, define power domains and interfaces, identify design risks, and plan verification before schematic capture.

Requirements

Write requirements with numbers and conditions:

input voltage range and transient tolerance;
maximum current and duty cycle;
operating temperature range;
interface type, speed, voltage, and connector;
sensor accuracy or actuator current;
enclosure and mounting constraints;
ESD, EMC, safety, or isolation needs;
production test and programming method.

Avoid vague requirements such as "low power" unless they include a current, mode, and duration target.

System Block Diagram

flowchart LR PWR[Power input] --> PROT[Protection] PROT --> REG[Regulators] REG --> MCU[MCU or processor] MCU --> SENS[Sensors] MCU --> ACT[Actuators] MCU --> COMM[Communication] DBG[Debug and programming] --> MCU

The diagram should show power flow, signal flow, and external boundaries clearly enough for review before components are selected.

Power Domains

List each rail in a compact power budget:

VIN: connector input for protection and buck stages, 2 A maximum, 9 V to 36 V, transient rated.
5V: buck output for sensors and USB, 500 mA maximum, +/-5%, includes noisy loads.
3V3: LDO output for MCU and logic, 200 mA maximum, +/-3%, main logic rail.
VREF: precision reference for ADC, 2 mA maximum, +/-0.1%, keep quiet and local.

The power table drives regulator choice, thermal estimates, sequencing, and test limits.

Interface Definition

For every interface, record voltage level, direction, speed, connector, cable length, protection need, and test method. External interfaces need more protection and tolerance than short internal board connections.

Risk Register

Reset during motor start: caused by rail droop. Mitigate with bulk capacitance and correct brownout settings. Verify with a load-step test.
Noisy ADC: caused by poor reference layout. Mitigate with a separate reference path and quiet return. Verify with noise measurement.
Failed programming: caused by missing debug access. Mitigate with an SWD header and test pads. Verify with fixture programming tests.

Common Mistakes

Selecting an MCU before defining interfaces and power.
Forgetting programming and production test access.
Treating all external connectors as benign.
Missing startup current and worst-case temperature.
No verification plan for important requirements.

Summary

System architecture turns product intent into hardware structure. Define requirements, blocks, rails, interfaces, risks, and verification before schematic details make changes expensive.

Mind Map

mindmap root((Embedded architecture)) Core concept Requirements drive hardware Blocks show boundaries Verification starts early Applications Sensor node Motor controller IoT product Industrial module Calculations Rail current Power budget Thermal margin Interface timing Design rules Define external ports Plan debug access Separate power domains Track risks Practical checks Requirement numbers Connector table Risk register Test method Common mistakes Vague goals No test access Missing transients Late architecture