Embedded & cyber-physical systems

Observe the world. Act before the deadline.

Co-design electronics, firmware, real-time behavior, sensing, control, power, communications, safety, and verification around the physics of a product.

Trace the control loop Practice an interview → Choose another track

11thinking steps
6verification levels
2worked cases

control.loop

# Correct value, correct time, safe outcome
sample   = sensor.read(timestamped)
state    = estimate(sample, uncertainty)
command  = controller(state, deadline)
actuator.write(command)

if health.invalid() or deadline.missed():
    enter(defined safe state)

verify(model → software → processor → plant)

01 · Cyber-physical thinking flow

Trace information and energy around the loop

Correct computation delivered too late can be incorrect system behavior. Design timing, uncertainty, and failure into the main path.

01Define mission + environment
Users, operating modes, physical range, hazards, lifetime, maintenance, and misuse.
Output: scenarios + boundaries
02Set timing + quality
Sample rate, deadline, jitter, accuracy, response, availability, and safe state.
Output: measurable requirements
03Model the plant
Dynamics, disturbances, sensor/actuator limits, latency, uncertainty, and observability.
Output: control assumptions
04Characterize plant + I/O
Measure response, noise, bandwidth, delay, saturation, dead zones, power, and environmental corners; fit uncertainty and a validity domain.
Output: measured profiles + model bounds
05Partition functions
Allocate sensing, control, acceleration, communications, safety, and UI to hardware or software.
Output: HW/SW boundary
06Schedule + communicate
Tasks, interrupts, DMA, buffers, buses, priorities, clocks, and synchronization.
Output: timing architecture
07Design modes + faults
Startup, active, sleep, update, degraded, emergency, recovery, and shutdown.
Output: state machines
08Implement + integrate
Bring up power, clocks, reset, drivers, subsystems, the critical loop, and external interfaces in controlled gates.
Output: integrated baseline + traces
09Verify + validate
Prove requirements, then demonstrate the complete mission with representative users, environments, faults, and units.
Output: traced acceptance evidence
10Transition + sustain
Provision, calibrate, acceptance-test, commission, monitor, service, and update through a recoverable release path.
Output: supportable fielded system
11Retire safely
Make outputs safe, revoke identity, erase protected data and keys, preserve required records, and dispose or recycle responsibly.
Output: verified decommission

Memory hookMission → requirements → model → characterize → partition → schedule → modes → integrate → V&V → sustain → retire.

Setpointdesired state + limits

Estimator + controllerfilter, fuse, decide, bound output

Actuator + plantphysical response + disturbances

Sensorsample, condition, convert, timestamp

↖ Feedback closes the loopsensor value + timestamp + health + uncertainty return to the estimator

SamplingFast enough, not merely frequent

Choose rate and anti-alias filtering from plant dynamics; define clock accuracy and timestamp location.

Delay + jitterBound end-to-end age

Sensor integration, bus transfer, scheduling, compute, output update, and actuator response all consume the deadline.

Range + uncertaintyRepresent what is not known

Resolution, noise, bias, drift, calibration, saturation, missing data, and cross-sensor disagreement.

Stability + safetyControl the corners

Analyze worst delays, gain changes, actuator limits, recovery transitions, and what happens when confidence is low.

02 · Hardware / software partition

Allocate by deadline, data rate, change, and assurance

Hardware is not automatically faster and software is not automatically flexible once interfaces, copies, validation, and updates are counted.

Start with one functionWhat makes this function difficult?Profile the complete path, including conversion and movement.

Hard deadline?Bounded response dominates

Use timers, capture/compare, DMA, FPGA/fixed logic, dedicated cores, or a verified high-priority software path.

Prove worst-case timing

High regular data rate?Work is repeated and parallel

Use DSP, SIMD, GPU/NPU, FPGA pipelines, or fixed function when transfer and launch overhead still fit.

Count bytes between engines

Likely to change?Policy or algorithm evolves

Prefer software, tables, microcode, or programmable acceleration with a stable hardware abstraction.

Preserve update and rollback

Independent safety boundary?Failure must be contained

Separate power, clock, reset, memory protection, supervisor, or simple monitor when common-cause failure matters.

Independence must be real

Hardware usually ownsPrecise edges + bulk movement

Clocking, ADC/PWM, safety cutoff, packet framing, DMA, encryption primitives, and stable high-rate transforms.

Software usually ownsPolicy + evolution

State machines, orchestration, calibration logic, diagnostics, product behavior, networking policy, UI, and update.

Contract between themMake timing and failure explicit

Registers, queues, ownership, units, ranges, timestamps, interrupts, errors, reset, versioning, and observability.

03 · Real-time scheduling selector

Choose a policy you can analyze

Real time means meeting deadlines predictably. High average CPU performance does not guarantee that.

Simple + static periodsCyclic executive

A repeating table is easy to inspect and deterministic when activities are few, known, and fit cleanly.

Watch: poor flexibility + long task blocking

Periodic / sporadic critical tasksFixed-priority preemptive

Assign priorities from criticality and analyzed relative deadlines. The classic rate-monotonic optimality and utilization guarantees apply only under their independent, periodic, preemptive, deadline-equals-period assumptions; period-based priorities can still be used outside that model when an applicable response-time analysis proves schedulability. Include blocking, ISR interference, release jitter, and overload.

Watch: priority inversion + starvation

Job-level absolute deadlinesEarliest Deadline First

Schedule the ready job with the earliest absolute deadline. Periodic and sporadic tasks may have fixed relative deadlines; priority still changes from job to job. Under the classic independent, preemptible, single-core model EDF is optimal, but a real implementation must include blocking and overhead and define overload behavior.

Watch: overload behavior + implementation and assurance cost

Soft background workBest effort below the critical lane

Run logging, uploads, UI, and maintenance at bounded lower priority or under a server/budget.

Watch: background backpressure + memory growth

Scheduling decision tree

Move from workload facts to an analyzable policy

Classify each activity or lane independently; one product may combine a fixed-priority critical lane with budgeted background work.

Gate 01 · characterize firstAre release behavior, WCET, deadline, blocking, and relevant overhead bounded?No: measure and bound them before selecting a policy. Yes: continue through the gates.

Gate 02 · static-table fitCan a small, fixed periodic set fit a maintainable worst-case repeating table?Every frame, job, and transition must fit under the declared timing model.

Yes · candidate Cyclic executive

Inspect every slot and transition; recheck the table after each timing or task change.

Best fit: few known activities with stable periods and dependencies.

No · Gate 03

Which priority semantics can you state and analyze?

Static task-level priorityFixed priority + response-time analysis

Use a justified priority assignment; include blocking, ISR interference, release jitter, and scheduler overhead.

Per-job absolute deadlineEDF + demand analysis

Use when the task model, implementation, and assurance case support dynamic priority; include blocking, overhead, and overload behavior.

If neither model fits, repartition the work or select another analyzable scheduler and proof method; do not silently demote hard-deadline work to best effort.

Independent soft laneBudgeted best effort

Place logging, UI, upload, and maintenance below the critical lane or inside a server/budget so their processor demand is bounded; prove shared-resource interference separately below.

Proof follows the selected policy

Cyclic executiveShow every job fits its frame/table, precedence and transition constraints, including overhead and exceptional modes.
Fixed priorityUse an applicable response-time recurrence with blocking, release jitter in the interference model, ISR/scheduler cost, and R_i ≤ D_i.
EDFShow demand plus blocking and implementation overhead does not exceed available processor supply over every required interval; define overload behavior.

A CPU budget bounds processor demand only. Also bound interference through locks, memory, buses, DMA/I/O, interrupts, and power or thermal throttling.

The tree selects a candidate policy, not a schedulability result. Accept it only after analysis under the stated task model and measured implementation costs.

Fixed-priority response-time anchorresponse=execution + blocking + applicable interference(response, release jitter)≤deadline

Practical anchor: FreeRTOS documents fixed-priority preemptive scheduling as its default policy, with time slicing among equal priorities. A policy name is only the start; the application still needs measured execution times and schedulability analysis.

04 · Interrupts, DMA, and ownership

Capture quickly. Move efficiently. Process outside the ISR.

The interrupt path protects timing; the task path owns complex work. In a pre-armed streaming path, the peripheral request—not an initial ISR—drives DMA. Avoiding a copy still requires compatible shared buffers, explicit ownership, mappings, synchronization, and any required cache maintenance.

Own + preparereserve buffer · map/sync · set descriptor
Arm pathconfigure DMA + peripheral before data arrives
Peripheral requesthardware moves data without per-item CPU work
Completion / error IRQDMA reports terminal count or fault
ISR publishesack · timestamp · status · wake task
Task + recyclesync · validate · process · unmap/return/rearm

CPU-driven path

Good for tiny, infrequent register transfers. Cost grows with interrupt rate, copies, and per-item overhead.

DMA-driven path

Good for blocks and streams. Needs descriptors, alignment, direction, ownership, cache maintenance, error handling, and completion.

Bound

Keep ISR work short and non-blocking. Define a maximum arrival rate and nesting policy.

Defer

Signal a task with a queue, notification, or event; do parsing, allocation, and logging later.

Own

Use explicit buffer states such as free, DMA-owned, ready, processing, and returning.

Recover

Handle overrun, missed completion, bus error, corrupt descriptor, timeout, and peripheral reset.

05 · State and power modes

Transitions are first-class behavior

Most bugs and energy surprises live between steady states: boot, wake, update, brownout, reset, degraded operation, and recovery.

OFF / SHIPPINGEnergy isolatedwake: charger, button, install event
BOOTTrust + initializeverify image, rails, clocks, memory, self-test
ACTIVEMission workfull sensing, compute, communication, actuation
IDLE / SLEEPRetain useful contextgate clocks, park buses, arm wake sources
DEEP SLEEPMinimum leakagelose most context; longer wake and restore

Entry guard

No transfer in flight; output safe; queues persisted or discarded intentionally.

Wake source

Timer, GPIO, comparator, radio, sensor, watchdog, charger—qualified against false wakes.

Example restore order

One common dependency chain is rails → clocks → retained memory → buses → devices → tasks → external outputs. Derive the actual sequence from the selected silicon and system hazards.

Fault escape

Every state has timeout, reset, rollback, or safe-state behavior if entry/exit fails.

Daily load energyΣ(load-side state power × residency)+Σ(load-side transition energy × transition count)

Keep one energy boundary: if powers are measured load-side, convert each state and transition with efficiency at its actual battery voltage, load, and converter mode, and include converter quiescent loss exactly once. A single η is acceptable only when it is a declared load-profile-weighted effective value. Alternatively, integrate energy at the battery terminal directly. Derate usable battery capacity separately for temperature, aging, self-discharge, depth-of-discharge limits, cell variation, and a named product reserve.

06 · Protocol selector

Choose the link from the physical context

Nominal bitrate alone ignores distance, wiring, topology, determinism, noise, power, software ecosystem, and failure handling.

Common starting points. Final electrical limits and timing come from the selected controller, transceiver, board, cable, and current specification.
Protocol	Best fit	Strength	Watch closely
I²C	Short board-level control and low-rate sensors.	Few wires, static addressing, broad device ecosystem.	Passive pull-ups, capacitance, clock stretching, stuck bus, and static-address conflicts.
I3C	Board-level sensors needing higher rates, a low-pin-count bus, and richer bus management.	Dynamic address assignment, in-band interrupts, and push-pull phases; selected legacy I²C targets may coexist when they satisfy the specified electrical/protocol restrictions.	Controller/target feature levels, legacy-target compatibility, mixed open-drain/push-pull timing, hot-join roles, and error recovery.
SPI	Short board-level sensors, converters, displays, and flash.	Simple, full-duplex, low protocol overhead, higher rates.	Chip-select count, no universal framing/error recovery, signal integrity.
UART	Point-to-point debug, modules, bootloaders, simple links.	Minimal hardware and easy observability.	Clock mismatch, framing, flow control, no native multi-drop contract.
CAN / CAN FD	Robust multi-node control networks in noisy environments.	Nondestructive arbitration, error detection, fault confinement, and identifier-based priority. Within one frame format, the lower numeric CAN-ID has higher priority; when base and extended data frames share the same first 11 identifier bits, the 11-bit base frame wins at the IDE arbitration bit.	Worst-case bus load, base/extended format mix, identifier design, bit timing, termination, error states, and latency under contention.
Ethernet	High-rate, longer-reach, routable or switched systems.	Large ecosystem, diagnostics, scale, power/data options.	Stack complexity, queues, switch delay, synchronization, security.
USB	Host-controlled peripherals, cameras, storage, service ports.	Standard classes, power, high bandwidth, broad hosts.	Host/device roles, enumeration, cabling, suspend, certification.
Bluetooth LE	Low-power personal-area links and phone-connected products.	Phone ecosystem, profiles, discovery, low-duty-cycle operation.	Connection interval, radio coexistence, pairing, privacy, variable latency.

Payloadbytes + rate

Deadlinelatency + jitter

Topologypoint · bus · switched

Physicalreach · noise · wires

Energyactive + idle + wake

Failuredetect · retry · isolate

07 · Safety, watchdogs, and recovery

Detect, contain, and reach a defined outcome

A watchdog is not a safety argument by itself. State what it observes, which failures it can detect, what remains independent, and what reset or safe action accomplishes.

InputSense + validaterange · plausibility · redundancy · freshness

DecisionControl + boundsstate validity · command limits · deadline

OutputDrive + observecommand versus feedback · open/short · saturation

OutcomeNormal or safe statestop · hold · isolate · degrade · alert

Supervisor lane with justified independenceWindowed watchdog, clock/power monitors, memory protection, heartbeat, external cutoff, and fault latch can force the defined outcome only when power, clock, software, sensing, and actuation common-cause dependencies are analyzed and verified.

Sensor stuckDetect

Freshness, rate-of-change, cross-sensor comparison, stimulus/self-test.

Task hangsContain

Deadline monitor, watchdog window, task/partition restart, bounded queue.

Output wrongObserve

Independent feedback, command envelope, actuator current/position sensing.

Recovery failsEscalate

Retry budget, subsystem reset, full reset, hardware cutoff, latched service state.

FMEA memory hook: failure mode → local effect → system effect → detection → control → residual risk → verification evidence.

08 · Verification-in-the-loop ladder

Add realism without losing observability

Move from fast models to the real plant in stages. Keep requirement IDs, acceptance limits, seeds, inputs, traces, and versions so failures are reproducible.

Implementation + integration gate

Assemble one observable thread at a time

Integration order is different from verification fidelity: each gate establishes a controlled baseline before the next interface can hide its failure.

01Power · clock · reset · safetyrails, sequencing, brownout, monitor and safe-output smoke tests
02BSP + driversregister, interrupt, DMA, timing and error-path contracts
03Subsystem threadone sensor, processor, buffer and actuator or sink
04Critical loopphysical event through timestamped command and feedback
05External interfacesnetwork, storage, charger, service and dependent systems
06Mission threadcomplete scenarios, transitions, overload, recovery and support path

Gate evidence: pin board revision, firmware, bootloader, configuration, calibration, tools and test fixture; name the owner, stimulus, expected trace, entry/exit criterion, anomaly disposition and rollback point.

MILModel-in-the-loop
Controller and plant are models.
Catches: algorithm, stability, scenario logic
SILSoftware-in-the-loop
Production-like code against a simulated plant.
Catches: numeric, generated code, state logic
PILProcessor-in-the-loop
Code executes on target processor or representative core.
Catches: precision, timing, compiler, memory
HILHardware-in-the-loop
Target electronics interact with real-time plant and I/O simulation.
Catches: modeled buses, clocks, timing, and injected electrical faults
SystemPhysical integration
Real sensors, actuators, mechanics, environment, and users.
Catches: interfaces + emergent behavior
FieldOperational evidence
Controlled rollout, telemetry, service diagnostics, and feedback.
Catches: diversity, aging, misuse, rare combinations

Nominal

Typical mission sequence at expected loads and environments.

Boundary

Min/max voltage, temperature, rate, timing, range, storage, and network.

Fault

Open/short, corrupt data, stale sample, bus timeout, clock drift, brownout, reset.

Transition

Boot, wake, sleep, update, rollback, degraded entry/exit, and repeated recovery.

Verification asksDid we build it to the requirements?→Validation asksDoes it solve the real operational need?

TransitionMake each delivered unit ready

Provision identity and keys, calibrate and acceptance-test the production configuration, record unit pedigree, commission site interfaces and safe defaults, and deliver operator/service instructions.

Operate + serviceTurn evidence into action

Monitor safety, energy, timing, sensor/actuator health and reset causes. Define alert, degraded-mode, inspection, repair, recalibration, spare and end-of-support ownership.

Update + recoverProtect, detect, recover

Authenticate releases; check bootloader, firmware, configuration and calibration compatibility; stage rollout; confirm health before commitment; and retain a tested recovery path without promising unsupported downgrade behavior.

RetireEnd authority and energy safely

Fence commands and make outputs safe, revoke cloud/device identity, erase protected data and keys, export or retain required records, isolate the battery, and follow the applicable reuse, recycling and disposal process.

09 · Timing and reliability workbench

Prove value, time, ownership, and recovery

Averages are useful for sizing, but real-time correctness depends on worst credible interference, blocking, transitions, and fault behavior. Keep the task model and hardware assumptions beside every schedulability claim.

Worked example · single-core control lane

Build the task model before choosing priorities

Illustrative conservative execution-time bounds under declared measurement corners: sensor capture 80 μs every 1 ms, estimator 350 μs every 5 ms, control update 250 μs every 5 ms, and communications service 800 μs every 20 ms. For a reproducible baseline, set each relative deadline equal to its period, use the fixed-priority order capture → estimator → control → communications, assume a fully preemptive single core, and initially set blocking and release jitter to zero with no ISR, context-switch, cache, flash, or bus overhead. Treat observed maxima as provisional—not automatic WCET—until analysis and corner evidence justify each bound.

Compute a screening loadUtilizations are 0.08 + 0.07 + 0.05 + 0.04 = 0.24. That is encouraging capacity evidence, but not a schedulability proof.
Run the explicit baselineWith B = J = 0 and the stated priority order, fixed-priority iteration gives response times of 0.08 ms for capture, 0.43 ms for estimator, 0.68 ms for control, and 1.56 ms for communications. Each is below its 1, 5, 5, or 20 ms relative deadline; the estimator/control tie order is part of the model.
Add missing interference and rerunMeasure ISR execution and arrival bursts; include critical sections, DMA completion work, cache or flash stalls, release jitter, context switches, bus arbitration, and non-preemptive regions. Iterate again and check every task—not only total utilization—against its relative deadline.
Size ownership queuesBound the backlog accumulated while a consumer is unavailable; define free, DMA-owned, ready, processing, and returning states so timeout/reset cannot create aliasing or reuse a live buffer.
Measure on the targetTrace release-to-completion latency and jitter at voltage, temperature, clock, memory, and bus corners. Inject overrun and missed-completion faults; confirm the stated degraded or safe behavior.

Analysis anchors

Use the formula that matches the model

Periodic utilization screenU = Σ(Cᵢ ÷ Tᵢ)Useful for first-pass capacity. It does not by itself include deadlines, priorities, blocking, jitter, ISR work, or multiprocessor effects.

Jitter-aware fixed-priority responsewᵢ⁽ᵏ⁺¹⁾ = Cᵢ + Bᵢ + Σⱼ∈hp(i) ceil((wᵢ⁽ᵏ⁾ + Jⱼ) ÷ Tⱼ) CⱼA common single-core fixed-priority model in which higher-priority release jitter enters interference. Add the task’s own jitter only when the measured boundary begins at arrival rather than release, and extend the model to match shared resources, scheduler policy, sporadic interference, and implementation overhead.

Buffer backlog estimatearrivals during worst consumer gap + burst/retry marginValidate with arrival and service traces. A large buffer delays overflow; it does not repair an unstable average producer/consumer rate.

Battery-terminal energyE_battery ≈ Σ(E_load,s ÷ η_s(V_bat, I_s, mode)) + E_quiescent,not-yet-countedUse state- and transition-specific converter behavior; add quiescent loss only if the efficiency/input-power measurement does not already include it. Or integrate at the battery terminal. Then derate usable capacity separately for temperature, aging, self-discharge, depth of discharge, cell variation, and product reserve.

Worked interview case · sampled-data motor control

A deadline can pass while the stability screen fails

Design a speed loop for a small motor. The candidate must connect sampling, software response time, I/O latency, jitter, and the continuous plant model instead of treating them as separate checklists.

f_s500 Hz
T_s2.00 ms
f_c20 Hz
PM_nom60°

Boundary: Start when the physical signal enters the sensor/filter path; stop when the new PWM command reaches the driver. Mechanical settling remains in the plant model.
Model: Single-rate periodic loop, zero-order-held output, 20 Hz nominal gain crossover, and 60° nominal continuous-design phase margin.
Evidence: Each number is a worst-credible bound at declared voltage, temperature, bus, cache, and interference corners—not a mean benchmark.
Limits: The screen omits quantization, saturation, nonlinear friction, model error, and multi-rate effects. Those require discrete analysis and plant simulation.

01Sense + filtergroup delay + conversion
02Timestamp + DMAmove one coherent sample
03Release + schedulebounded start jitter
04Estimate + controlresponse under interference
05PWM latchnext 20 kHz update edge
06Driver transportcommand reaches power stage

Hard timing ledger

Budget the complete sensor-to-command age

Sensor + anti-alias filterincludes conversion/group-delay bound
0.30 ms
Timestamp + DMA transfersample remains coherent
0.10 ms
Release/scheduling jitterADC complete to task release
0.15 ms
Controller responseexecution + blocking + interference
0.55 ms
PWM update alignmentone worst 20 kHz edge wait
0.05 ms
Driver command transportexcludes motor dynamics
0.15 ms

Path bound1.30 ms≤deadline1.50 ms0.20 ms slack

Frequency-domain screen

Convert delay to phase at crossover

Sampling T_s = 1 ÷ 500 Hz = 2.00 ms That is 25 samples per 20 Hz crossover period. Nyquist is only a lower bound; sampled-data fidelity and phase margin still need analysis.

Implementation delay φ_path ≈ −360 f_c τ_path = −9.36° A pure time delay contributes phase proportional to frequency.

Zero-order hold φ_ZOH ≈ −360 f_c(T_s ÷ 2) = −7.20° The half-sample delay is a low-frequency approximation. Do not add it again if the discrete plant analysis already models the hold.

Rough remaining margin PM ≈ 60° − 9.36° − 7.20° = 43.44° This misses the interview’s provisional 45° robustness target even though the 1.50 ms deadline passes.

Keep jitter visible

The 0.15 ms release-jitter allowance is included in the 1.30 ms path bound and spans up to 360 × 20 Hz × 0.00015 s = 1.08° of timing-dependent phase at crossover. A separate ±20 μs sample-aperture jitter assumption contributes about ±0.14°. These conversions are intuition, not a substitute for a jitter-aware sampled-data robustness analysis.

Task timingPass1.30 ms ≤ 1.50 ms

20 Hz phase screenReview43.44° < 45° target

One defensible decisionRedesign near 15 HzIf the redesigned continuous loop still provides 60° nominal margin at 15 Hz, the approximate penalty is 12.42° and 47.58° remains. Or retain 20 Hz only after reducing latency/sampling delay and re-running the discrete model.

Pressure-test the reasoning

Interview follow-ups

Answer with an equation, a decision, and the evidence you would collect.

The release jitter doubles to 0.30 ms. What changes?

The path becomes 1.45 ms, leaving only 0.05 ms deadline slack. With the same 2 ms hold, the delay-equivalent phase penalty becomes about 17.64°, leaving a rough 42.36° margin. The timing deadline still passes, but the phase screen worsens and the tiny slack is fragile.

The filter group delay rises from 0.30 to 0.60 ms. Is the loop acceptable?

No under this contract: the path bound becomes 1.60 ms and misses the 1.50 ms deadline before considering stability. Diagnose why the filter changed, then trade anti-alias attenuation, sample rate, filter topology, controller bandwidth, or deadline—with a new discrete analysis.

An interviewer requests a 35 Hz crossover without changing hardware. What do you say?

The same 2.30 ms delay equivalent contributes about 29.0°, leaving only about 31.0° even if a redesigned continuous loop retained the assumed 60° nominal margin at 35 Hz. Sampling falls to 14.3 samples per crossover period. Reject an unsupported promise; redesign or measure the plant and controller in discrete time.

What should happen when one update misses its deadline?

Define this from the hazard analysis: a benign speed loop might hold a bounded last command for one stale-data interval, while a hazardous actuator may need an independent cutoff or controlled ramp. Detect age with source timestamps, count consecutive misses, avoid integrating stale error, and verify recovery in HIL.

Simplified interpretation: subtracting delay and ZOH phase from a nominal continuous phase margin is an interview screening calculation, not a stability proof. Close the claim with a discrete plant/controller model, uncertainty and nonlinear limits, frequency/step analysis, worst-case execution evidence, and target/HIL testing.

A response-time claim is only as good as its task model. Record the assumptions beside the result so a later software or hardware change can invalidate it visibly.
Model field	What to record	Common miss	Evidence
Release	Periodic/sporadic source, minimum inter-arrival time, burst limit, phase, release jitter, and mode.	Using average sensor or network rate when arrivals can burst.	Timestamped arrival traces plus a justified bound for unobserved corners.
Execution	WCET or conservative bound by path, cache/flash state, voltage/frequency, compiler, inputs, and instrumentation overhead.	Treating a benchmark mean or isolated hot-cache run as WCET.	Static analysis where applicable, target measurements at corners, and code/configuration identity.
Interference	Higher-priority tasks, ISRs, non-preemptive sections, DMA completion work, bus/memory contention, and multicore effects.	Counting only RTOS tasks while drivers and shared hardware steal service.	Response-time analysis matched to the scheduler and measured contention tests.
Blocking	Mutex/resource protocol, maximum critical section, priority inversion control, and lower-priority non-preemptive work.	Assuming high priority means “never waits.”	Lock/critical-section traces, ceiling/inheritance configuration, and worst-holder injection.
Acceptance	Relative deadline, end-to-end chain deadline, allowed misses, safe/degraded response, and measurement points.	Proving each task separately while the sensor-to-actuator chain still misses.	Target trace from physical event through actuation and recovery at operating corners.

Transitions deserve the same rigor as steady states. Define entry guard, authority, timeout, cleanup, output validity, and proof for every edge.
Transition fault	Required behavior	What can remain ambiguous	Test
DMA timeout during capture	Fence rearm, mark the buffer invalid, stop/disable the peripheral and DMA channel in the documented order, and keep ownership and storage pinned until an idle indication—or the target’s containment/reset sequence plus any required posted-write drain—proves the device cannot write again. Only then clear/reinitialize, revoke ownership, recycle the buffer, and rearm.	Without quiescence proof, a late write or completion can corrupt a buffer already returned to another task.	Delay/drop completion and inject bus faults at every descriptor and reset boundary; assert that reuse never precedes proven quiescence.
Brownout during flash write	Hold outputs safe, protect boot metadata, detect incomplete records, and recover the last committed state.	Torn data may look structurally valid without CRC/version/commit markers.	Sweep power removal across each program/erase and metadata update phase.
Wake dependency fails	Bound each rail/clock/device wait, clean up partially enabled domains, log the failing dependency, and enter a defined low-power or service state.	One powered device may back-power another or leave the bus stuck.	Stuck-ready, missing clock, false wake, repeated wake, and power-sequence injection.
Watchdog reset loop	Persist bounded reset history, prevent unsafe output replay, escalate after the retry budget, and expose a diagnosable latched state.	A reset can repeatedly recreate the hazardous condition before monitoring is ready.	Hang each supervised layer, corrupt progress signals, and fail the recovery itself.
Update interrupted or incompatible	Authenticate, enforce version policy, select a bootable compatible image, confirm health before commitment, and retain recovery access.	Firmware, configuration, calibration, secure storage, and rollback counters can disagree.	Power-cut matrix across download/install/boot/confirm plus forward/backward compatibility tests.

Sampling

Protect the signal contract

State bandwidth, sample rate, aperture/jitter, synchronization, anti-alias filtering, quantization, calibration, stale-data timeout, timestamp source, and what the controller does when confidence is lost.

Concurrency

Make ownership explicit

Use bounded queues and immutable descriptors; define who may read, write, cancel, recycle, or reset a buffer. Pair data publication with the memory ordering required by the CPU and device.

Recovery

Layer watchdogs deliberately

Monitor progress, not merely task liveness. Use an independent clock or external supervisor when the hazard requires it; log reset cause and prevent reset loops from repeatedly driving unsafe outputs.

Evidence

Test timing faults in context

Combine MIL/SIL/PIL/HIL with bus delay, clock drift, corrupt samples, brownout, partial update, stuck actuator, thermal throttling, and repeated recovery. Preserve seeds, traces, versions, and acceptance limits.

Primary trailLiu–Layland scheduling ↗Joseph–Pandya response time ↗Jitter-aware response time ↗University of Michigan digital control + ZOH ↗MathWorks delay analysis ↗Zephyr scheduling ↗Zephyr power management ↗FreeRTOS scheduling ↗Linux DMA ownership ↗TI pulsed-load battery budgeting ↗MIPI I3C integration ↗CiA CAN arbitration and frame formats ↗MCUboot image + recovery design ↗Linux watchdog contract ↗

10 · Embedded interview practice

Design a battery smart camera

Commit to requirements, an energy budget, task timing, states, and failure behavior before revealing the coaching notes.

45-minute prompt

Design a six-month battery smart camera

A weather-resistant camera wakes on motion, classifies locally, stores an encrypted clip, and uploads confirmed events. It must remain useful when Wi-Fi is unavailable.

8 Wh battery
180 days
20 wakes/day
2 confirmed/day
wake < 500 ms
−10–50 °C
secure update

PIR / wake sensoralways-on µW lane
Power managersequence rails + clocks
Image sensorcapture + timestamp
ISP + NPUscreen motion locally
MCU policyclassify event + mode
Flashencrypted ring buffer
Wi-Fi / BLEupload + setup + health

00–07 minClarify mission and privacy
Ask about detection classes, missed/false event cost, clip length, image quality, night operation, connectivity, local retention, response, tamper, and user controls.
Reveal coaching notes
Define “six months” with event and temperature assumptions. Separate wake detection from confirmed event recording. Ask what images may leave the device and what the product does when storage, battery, or connectivity is constrained.
07–15 minCreate the energy budget
Convert 8 Wh over 180 days into a daily and average-power envelope. Budget load-side sleep, wakes, confirmed captures, and uploads; translate each state and transition to the battery boundary with its applicable converter behavior, then derate usable capacity for temperature and aging.
Reveal coaching notes
The nameplate envelope is about 44.4 mWh/day, or 1.85 mW average before conversion and capacity derating. Keep the always-on lane far below that. Use efficiency and quiescent current at each state’s battery voltage, load, and converter mode—or integrate battery-terminal energy directly—because a radio burst and a microamp sleep state do not share one nominal efficiency. Budget energy per wake and per upload, not just active watts; reduce false wakes because their count multiplies every active cost.
15–25 minPartition hardware and tasks
Choose wake sensing, MCU/RTOS, image/ISP path, accelerator, memory, storage, radios, security element, and power domains.
Reveal coaching notes
Keep a tiny always-on controller or wake sensor. Power the main image/AI/radio islands only when needed. Use DMA for frames, fixed function for ISP, an accelerator for supported inference, and software for policy and recovery. Avoid waking Wi-Fi for rejected events.
25–33 minSchedule the event path
Trace wake interrupt, rail/clock sequencing, sensor readiness, capture DMA, inference deadline, storage, radio association, upload, and return to sleep.
Reveal coaching notes
Assign deadlines to stages and reserve buffers before enabling capture. Keep ISR work to acknowledge/timestamp/defer. Bound every wait with a timeout and make cancellation safe if battery, thermal, or privacy policy changes mid-event.
33–40 minDesign modes and failures
Cover shipping, setup, armed, capture, upload, offline, low battery, update, degraded, over-temperature, tamper, and recovery.
Reveal coaching notes
Store clips locally with a retention and wear policy when offline; upload later under an energy/data budget. Use signed A/B images with anti-rollback policy, old/new schema and bootloader compatibility, post-boot confirmation, bounded retry, a recovery image/path, unique device identity, encrypted storage, protected keys, and explicit factory reset.
40–45 minVerify, transition, sustain, and retire
Name requirement and mission-validation evidence, then explain how each unit leaves the lab, is commissioned, monitored, serviced, updated, recovered, and safely decommissioned.
Reveal coaching notes
Automate event-cycle energy integration across temperature and battery state; replay labeled scenes; inject transition faults; HIL-test power and sensor interfaces; then run accelerated long-duration and controlled field trials. Factory-provision identity and keys, calibrate and acceptance-test the released configuration, record unit pedigree, and commission privacy and safe defaults. Roll out compatible signed firmware in stages, require post-boot health before commitment, monitor energy, false wakes, storage, resets and sensor health, and keep a tested recovery/service path. At retirement, stop capture and actuation, revoke identity, erase clips and protected keys, preserve required audit/service records, isolate the battery, and follow the applicable reuse or recycling process.

200 wakes/day

Protect the battery with sensor tuning, cooldown, local low-cost screening, rate budgets, and abuse detection.

Wi-Fi offline for 7 days

Size encrypted storage, choose eviction priority, batch retry with backoff, and preserve battery.

Update loses power

Boot verified previous image, leave recoverable metadata, and never brick the secure update path.

Sensor gives stale frames

Use frame counters/timestamps, freshness deadline, pipeline reset, user-visible health, and degraded state.

Strong closeShow the event timeline, daily energy equation, state machine, integration gates, V&V evidence, field thresholds, recoverable update path, and safe retirement contract.

11 · Primary references

Ground the design in implementation contracts

Read the exact silicon, RTOS, protocol, and safety requirements for the product. These references provide durable starting points.

SchedulingFreeRTOS task scheduling

Official description of fixed-priority preemption, equal-priority time slicing, AMP, and SMP policies.

FreeRTOS documentation ↗

InterruptsLinux generic IRQ handling

Reference implementation documentation for interrupt descriptors, flow handlers, affinity, and threaded interrupts.

Kernel documentation ↗

DMALinux DMA Mapping Guide

Addresses, IOMMU mapping, coherent and streaming buffers, directions, lifecycle, and failure checks.

Kernel documentation ↗

MCU interfacesArm CMSIS 6

Common processor, driver, RTOS, DSP, and neural-network software interfaces for Cortex-based systems.

CMSIS documentation ↗

Product realizationNASA Systems Engineering Handbook

Verification methods, validation, integration, transition, evidence, and requirement closure in complete systems.

NASA product realization ↗

Power managementZephyr power management

System and device power states, policies, residency, wake latency, and runtime device power concepts.

Zephyr documentation ↗

Foundational schedulingLiu and Layland

The classic single-processor periodic-task model, rate-monotonic priority assignment, utilization bound, and earliest-deadline-first result—with assumptions that must be stated.

Read via ACM DOI ↗

RTOS behaviorZephyr Scheduling

Official details for cooperative and preemptive threads, static priorities, time slicing, scheduler locks, deadlines, and power-management interaction.

Zephyr documentation ↗

Sensor busMIPI I3C System Integrator Guide

Dynamic address assignment, in-band interrupts, mixed I²C/I3C operation, arbitration, roles, and integration responsibilities.

MIPI application note ↗

RecoveryLinux Watchdog API

A concrete reference for timeouts, pretimeouts, boot status, nowayout behavior, and the limits of assuming every watchdog implementation behaves identically.

Kernel documentation ↗

BackendDistributed softwareAPIs, data, caching, queues, reliability. Systems engineeringWhole lifecycleNeeds, requirements, interfaces, risk, V&V. HardwareComputer systemsCompute, memory, fabric, PPA, thermal, reliability. NPU + ACiMHardware/software co-designCompiler, mapper, runtime, calibration. AtlasChoose by system boundaryReturn to the visual track selector. DSA AtlasAlgorithms and data structuresReturn to the original visual learning map.