Independent learning for embedded-systems engineersHardware · Firmware · Software
TEA-402PRACTICAL SYSTEM EXERCISE60–90 MINUTES

The parts work.
Why does the system fail?

Investigate a connected temperature sensor at the boundaries between power, acquisition, firmware, communications and the host display.

Begin the exerciseRead the TEA-401 case study

Your engineering outputs

  • A testable interface specification with units, identity, timing and validity.
  • A recovery model that separates measurement, delivery and display state.
  • Integration tests with measurable expected results.
  • An evidence-based explanation of what remains uncertain.

Study guide · 3 October 2026 · Work individually or as a hardware / firmware / host team.

Suggested time: 15 minutes for the traces, 25 for the interface, 20 for recovery and 20 for tests. No development board is required for the paper exercise.

01 / SCENARIO

Each team can demonstrate a working component.

The sensor responds to a physical temperature change. Firmware acquires and processes samples. The BLE interface transfers data. The host parses messages and draws a graph. Yet a power interruption produces duplicate records, a reconnection makes six-hour-old data look current, and the host sometimes reports a healthy sensor immediately after a restart.

Use the battery-powered monitor from TEA-401. The node contains regulated power and reset supervision, a digital sensor on I²C, an MCU with BLE, non-volatile history storage and a local warning indicator. Here, host means the receiving gateway and its local display / database. Forwarding beyond that host is outside this exercise.

Fictional engineering investigationThe traces and limits are teaching inputs, not measurements from a tested product. The monitor provides information and a local warning; it does not control refrigeration or provide the sole protection for a hazardous process. You are specifying observable system behaviour, not certifying a protocol or selecting a component.

Draw a boundary around each owner: hardware and power; sensor acquisition; firmware processing and storage; communications; host acceptance and presentation. For every proposed fix, identify which boundary contract must change.

02 / BASELINE

Keep these case-study requirements in force.

RequirementConstraint
CS-002 / CS-003Acquire every 1,000 ms with ±10 ms release jitter. Assert the local high warning after three consecutive valid readings ≥8.0 °C, within the 3.2 s electronic response bound. Clear only after three valid readings ≤7.5 °C.
CS-004While connected, provide a live snapshot and minute summary every 60 s. The host marks a live value stale when its conservative age exceeds 90 s. Historical delivery must not refresh the live value.
CS-005A failed acquisition is invalid immediately. Three consecutive failed acquisitions indicate a sensor fault within 3.2 s. Invalid samples break warning counts and cannot clear an existing warning.
CS-006 / CS-007Keep at least 24 h of completed minute summaries. Preserve committed records through power loss; reject incomplete writes. After restart, obtain three new valid acquisitions before declaring measurements healthy.
CS-008Radio activity and recovery must be bounded. Repeated retries change the energy budget and must not delay acquisition or local warning behaviour.

Retain the case’s assumed 20 ms conversion bound and 2 ms sensor-transfer budget. Its 500 ms connected-link timing allowance is an assumption to be demonstrated, not a property guaranteed by BLE. The worked solution makes that assumption observable at the application boundary.

03 / INCOMPLETE CONTRACT

This is everything the teams originally agreed.

Prototype interface note — deliberately inadequate

“Send the temperature as JSON once per minute. The host sends OK. If nothing comes back, resend. After reconnecting, send the buffered readings. The host displays the latest received value.”

{"temperature":2500,"time":60000,"status":"OK"}

The sensor, radio and host unit tests all pass against their own assumptions.

What does 2500 mean? When did the measurement occur? Which clock owns 60000? Does OK mean bytes arrived, the value was accepted, or a record survived a host crash? Can a valid JSON message still contain invalid or stale data? What survives a restart?

Write down each uncertainty before choosing a solution. You may design a different protocol from the worked answer if it meets the same system requirements and has clear test oracles.

04 / FAILURE CARDS

Investigate the boundary, not just the symptom.

These four traces describe the flawed prototype. Times are relative to each separate test run. An observation is evidence; a proposed cause is a hypothesis until a discriminating test supports it.

A / POWER LOSS DURING TRANSMISSION

A partial message crosses a reset.

  • At 60.000 s, a completed minute record is committed locally.
  • At 60.010 s, transmission begins. The host receives only {"temperature":25.
  • At 60.020 s, the node supply collapses and reset asserts. No complete application message arrives.
  • After restart, the next message is appended to the host’s old receive buffer. The node has already marked the earlier record “sent”.

Investigate: capture supply, reset, transmitted bytes and storage commit markers together. Decide what the host may accept, what the node must retain, and how partial data is discarded across sessions. A “final fault message” is not available when power has gone.

B / INTERRUPTED COMMUNICATIONS

The host stored it. The node cannot know that.

  • At 120.000 s, the host receives record 17 and commits it.
  • The host sends OK; the communications link drops before the node receives it.
  • On reconnection, the node resends record 17. The host inserts a second database row.

Investigate: define record identity, acknowledgement meaning, timeout, retry limits and duplicate handling. What if the host commits a record and restarts before sending the acknowledgement? What if the same identity arrives with different content?

C / STALE READINGS

New traffic is mistaken for a new measurement.

  • The last genuine sample is 5.0 °C. Acquisition then times out, but the last-good buffer is reused.
  • Each minute, firmware stamps the old value with the current transmission time. The host stays green.
  • After a six-hour link outage, historical records arrive in a burst. Each receipt again resets the host’s freshness timer.

Investigate: distinguish acquisition time, processing time, transmission time and receipt time. Specify value / validity publication as one coherent object. How will the host reject both a replayed record and a freshly packaged old sample?

D / UNEXPECTED RESTARTS

Old and new identities become indistinguishable.

  • Before reset, the node uses sample sequence 900 and uptime 900,000 ms.
  • After reset, its sequence and uptime restart at zero. Its default status is OK.
  • The host either rejects new data as “out of order” or accepts a delayed old message as current.
  • The host itself is then restarted and restores yesterday’s last-good value as green.

Investigate: distinguish device identity, node boot identity, link session and sample / record sequence. Define readiness after reset, handling of delayed acknowledgements, and host start-up state.

05 / YOUR TASKS

Turn the gaps into an integration contract.

1. Identify missing requirements

For each failure card, list the missing or ambiguous rule, its consequence, its owner and the evidence needed to resolve it. Assign your own interface requirement IDs. Keep assumptions separate from verified facts.

2. Complete an interface specification

TopicDecision to record
Units and rangeTemperature scale, integer scaling, resolution, representable range and distinction from the accuracy claim.
Framing and compatibilityEncoding, complete-message delimiter / length, maximum size, fragment timeout, protocol version and malformed-message behaviour.
Identity and orderDevice, boot, link, sample and stored-record identities; rollover; duplicate and out-of-order handling.
Timing and validityAcquisition time, clock domain, age uncertainty, invalid / initialising states, live eligibility and stale threshold.
AcknowledgementsWhat is acknowledged, when, with which identity, and whether storage is durable.
Timeout and recoveryBounded retries, backoff, reconnect, brownout, restart readiness and host restart.
History and resource limitsRetention, overflow / gap reporting, priority of live data, queue limits and power / timing budgets.

3. Draw the recovery behaviour

Show measurement health separately from communications state. Include power loss, failed acquisition, reconnection, timeout, budget exhaustion and three-sample recovery. State what the host displays in each case, including when it has no trustworthy value.

4. Write integration tests

Cover each failure card and at least two boundary conditions. Every test needs a baseline, preconditions, injected fault, observation points, expected results with limits, and evidence to retain. Include one test showing that sustained communications trouble does not break local acquisition or warning timing.

5. Make a joint engineering decision

For each proposed remedy, say whether it changes hardware, firmware, host software or their shared contract. Explain what unit tests can establish and what requires the assembled system. Do not infer a power fault solely from a communications error.

06 / REVIEW

What a defensible answer contains.

  • An unambiguous conversion from transmitted value to °C, and no numeric substitute for invalid data.
  • Finite waits and retries with acquisition / local warnings protected.
  • Power-loss-safe record identity and acknowledgement after durable host commitment.
  • Freshness based on the original acquisition, with history unable to restore Live.
  • Explicit restart and synchronisation behaviour at both ends.
  • Tests that can fail, including exact age and timeout boundaries and evidence from the physical interface.

Peer review: swap specifications. Could another team implement the other end without asking what OK, latest, sent or recovered means? Record every question as a contract gap.

Ready to compare?

The worked solution includes one possible message contract, a recovery state diagram, corrected traces and integration tests with expected results.

Open TEA-403 — Worked solution

Related learning

For implementation mechanisms, use TFA-102 — State Machines and Scheduling and TFA-109 — Unit, Integration and HIL Testing.