Electronics and hardware engineers
Create a physical platform whose power, signals, timing, diagnostics and failure behaviour support the product’s complete safety and performance case.
After this module, you should be able to:
- Translate system behaviours into electrical design obligations
- Define testable hardware–firmware contracts
- Design for diagnostics, margins and safe energy control
- Produce evidence from analysis, review and bench testing
Study guide · Updated · About 8 minutes reading + 20–30 minutes practice
Before you start: Read TEA-102 and TEA-103. Bring a basic understanding of schematics, power and component tolerances.
Hardware shapes what software can observe and control.
Electronics engineers select and connect the sensing, processing, storage, communications, actuation and power elements that realise the system. The role includes component application, but also tolerances, environmental stress, electromagnetic compatibility, production test, fault containment and service life.
Design beyond nominal operation.
| Area | Questions to resolve | Evidence |
|---|---|---|
| Power and reset | What happens during ramp, brownout, interruption and discharge? | Power tree, sequencing analysis and scope captures |
| Signal chain | Are range, accuracy, bandwidth and noise margins sufficient? | Error budget and characterisation results |
| Digital interfaces | Are levels, timing, termination, ownership and defaults defined? | Interface contract and timing analysis |
| Actuation | How are energy, thermal load and unintended activation controlled? | Load analysis and fault tests |
| Lifecycle | Can it be built, tested, calibrated, repaired and sustained? | DFM/DFT review and component records |
Give firmware an honest model
Document register-level behaviour where relevant, but also analogue settling, conversion latency, polarity, scaling, saturation, stale-data risks, boot defaults and faults that cannot be distinguished in software.
Use margins and fault injection early.
- Start from loads and signals. Quantify what must be measured, driven and tolerated.
- Budget uncertainty. Combine sensor, reference, gain, ADC, drift and calibration effects.
- Define power states. Specify start-up, sleep, reset, brownout and shutdown behaviour.
- Design observability. Provide test points, telemetry and controllable fault paths.
- Analyse faults. Consider opens, shorts, stuck signals, leakage and component drift.
- Characterise prototypes. Test corners, transients and representative loads—not only typical values.
Worked hand-off: analogue pressure channel
Hardware supplies the transfer function, tolerances, valid electrical range, settling time and diagnostic coverage. Firmware converts counts to engineering units, schedules acquisition and applies plausibility checks. Test engineering injects boundary voltages and sensor faults while systems engineering confirms the total accuracy and response budget.
Show that the realised board matches the design intent.
Schematics, layout constraints and interface definitions.
Worst-case, thermal, derating, timing and signal-integrity work.
Approved parts, critical attributes and change monitoring.
Independent checks of safety, layout and producibility.
Measured performance across loads and environments.
Injected faults and observed diagnostic or safe responses.
Common traps
Tolerance, ageing and temperature consume an assumed margin.
Pins briefly energise an actuator during reset or boot.
A purchased subsystem hides timing, update or failure behaviour.
Production variation and real cabling are not represented.
Translate behaviour into electrical limits
A hardware interface definition should explain what the firmware can observe and control at the limits, not only at nominal voltage. Define logic thresholds, pull states, power sequencing, settling, diagnostic signals and the effect of a disconnected load. Identify conditions that software cannot distinguish electrically.
Allocate measurement error and output capability using the operating environment and component variation. A typical data-sheet plot is useful context but cannot replace a guaranteed limit when the design depends on that bound. Document where analysis relies on characterisation or supplier evidence.
Include firmware loading and manufacturing test in the design. Debug access, board identification, calibration and production credentials must be usable without leaving uncontrolled privileges or output states in shipped units.
Agree a hardware–software contract before bring-up
The contract should specify reset values, initialisation order, pin ownership and the sequence that permits an actuator to energise. If hardware needs 40 ms after a rail becomes valid, provide the condition and its tolerance, not merely a comment asking firmware to wait a while.
Review how faults appear at the boundary. An open sensor may read full scale, a short may look plausible and a supply fault may disturb several channels together. Agree diagnostic coverage and its limitations so firmware does not claim a detection mechanism that the circuit cannot support.
Keep changes visible through an interface revision and compatibility record. A substituted component or resistor value can alter the meaning of a timeout or calibration constant even when the schematic function has the same name.
| Hardware decision | Firmware needs to know |
|---|---|
| Output enable | Safe default, polarity, timing and independent inhibit behaviour. |
| ADC front end | Range, scaling, settling, saturation and expected fault signatures. |
| Power supervision | Thresholds, hysteresis and available warning time. |
| Board identity | Valid revisions, unknown-state handling and configuration selection. |
Use fault injection to test the electrical argument
Choose injections from the failure analysis: open and short signals, missing rails, stalled loads and credible output faults. Establish a safe bench arrangement and the observation that proves the intended fault was applied. A software flag simulating a sensor error cannot prove the circuit reveals an actual broken wire.
Retain traces, loading conditions, instrument settings and board identity. When a workaround moves into firmware, review its effect on timing and diagnostics with the owning engineer. A bench fix becomes product knowledge only when the design records and repeatable verification are updated.
Practical exercise
An illustrative engineering exercise; values are assumptions for this lesson.
Review a normally energised actuator enable
An enable pin is pulled high while the MCU is held in reset. Firmware drives it low early in initialisation, and the design is described as safe because this happens quickly.
- Identify the interval in which the software argument has no authority.
- Propose a hardware–software agreement for enabling the output.
- Specify start-up and fault tests, including slow supply rise.
Show the worked answer
The output is potentially enabled before the application executes, including during reset extension or failed boot. If that physical state is hazardous, an early software write is not sufficient protection. Establish a default circuit state that achieves the required behaviour and a deliberate, validated enable sequence after prerequisites are met.
Test cold start, slow and interrupted supply ramps, reset assertion during operation and a controller that never completes initialisation. Observe the actual power-stage output and load response, not only the MCU pin. Document the circuit limits, timing contract and independent inhibit assumptions, then verify that service and production tools cannot bypass them unintentionally.
Review criteria
- Behaviour before code execution is addressed.
- The enable contract includes prerequisites and failure response.
- Tests observe the physical output throughout reset and start-up.
Check your understanding
Can a firmware simulation replace a broken-wire test?
It can test software handling of a reported fault, but not whether the circuit detects the real electrical failure.
Why does component substitution need firmware review?
It may change timing, fault signatures, scaling or start-up behaviour that firmware relies on.
Further learning
- Arm CMSIS documentationStandardised interfaces between Cortex-based hardware and software.
- TEA-103 · Sensors, actuators and signal acquisitionSignal-chain and physical-interface foundations.
Design what happens at the edges.
Dependable hardware controls energy, preserves signal meaning and exposes enough diagnostic information for the complete system to respond safely.