10  Lab: IoT Reference Architecture

10.1 Start With the Review Record

In the lab, the architecture becomes real when the review record has something concrete to inspect. A diagram alone is not enough; it needs a flow trace, a boundary decision, a test result, a risk note, and a reason the current design is acceptable.

Treat the lab as a small architecture review. Pick one design, record the claims it makes, attach evidence for each claim, and leave clear limits so the next change can reopen the review without starting from scratch.

In 60 Seconds

This lab turns the reference architecture model into evidence. You will define a small device scenario, separate sensing, message formatting, local decision logic, storage-ready records, and operator review, then prove each boundary with test output. The goal is not to memorize a demo board. The goal is to practice building a lab record that shows where each layer owns responsibility and how the design behaves when readings are valid, invalid, delayed, or outside limits.

Minimum Viable Understanding

• The lab is about boundaries. Device input, payload formatting, local decision logic, durable records, and operator response should be separate enough to test independently.
• Proof matters more than the tool. You can use a simulator, a bench microcontroller, or a mocked input script if each layer produces inspectable output.
• Validation protects higher layers. A failed sensor reading should become a marked data-quality condition, not an accidental alert.
• A lab record is a design artifact. Capture assumptions, inputs, outputs, test cases, failures, and review conditions.
• Production needs more layers. This lab starts small, then shows what would be added for storage, abstraction, dashboards, operations, and updates.

45-60 min | Intermediate | Reference architecture lab

10.2 Learning Objectives

By the end of this lab, you should be able to:

• build a small layered IoT flow using device input, message formatting, local decision logic, and a review record;
• explain which code or test artifact belongs to each architecture layer;
• validate data-quality, threshold, and fallback behavior without relying on a specific board or cloud service;
• extend the lab design toward accumulation, abstraction, application, and operations layers;
• record evidence that another learner or reviewer can reproduce.

Reference Lab Boundaries

10.3 Lab Route

Start with a narrow physical scenario and move one boundary at a time.

Reference architecture lab route showing the scenario, device input, payload contract, local decision, evidence capture, and acceptance record that make the lab reviewable.

Use this route:

1. Define the scenario and the physical outcome.
2. Choose the device inputs and output indicators.
3. Create a payload format with timestamp, quality, and source fields.
4. Add local decision logic that does not depend on message formatting.
5. Run test cases for normal, alert, invalid, delayed, and manual-trigger behavior.
6. Capture evidence: input, payload, decision, output, and notes.
7. Write the lab review record and extension plan.

10.4 Scenario and Setup

Use a simple environmental monitor as the lab scenario. The device observes temperature, humidity, and a manual trigger. It produces a structured message, makes a local alert decision, and records enough evidence for review.

Device Input

Temperature, humidity, and manual trigger state. Use physical sensors, simulator controls, or mocked readings.

Payload

Structured record with device id, timestamp, readings, units, quality flag, and error reason when needed.

Decision

Alert state based on threshold and manual trigger rules. The decision consumes validated readings, not raw pins.

Lab Record

Captured input, payload, decision, output, failed case, and reviewer note for each test run.

Allowed tooling: Use a bench microcontroller, a circuit simulator, or a local script. The tooling is acceptable only if it lets you observe the layer evidence listed in this chapter.

10.5 Layer Map

The lab begins with three active layers, then documents how it would grow into the full reference architecture.

Reference architecture lab layer map separating core input, payload, and decision boundaries from later accumulation, abstraction, application, and operations responsibilities.

Layer 1: Device Input

Reads temperature, humidity, and manual trigger state. Also marks invalid or missing readings.

Layer 2: Message Format

Builds a payload that can be logged, sent, stored, or replayed without exposing hardware details.

Layer 3: Local Decision

Applies threshold, quality, and manual-trigger rules to create a visible output or alert state.

Extension Layers

Add storage, abstraction, dashboards, operator workflow, update records, and support ownership after the core lab passes.

10.6 Build the Lab Flow

Use the following compact structure. Adapt names and syntax to your chosen tool, but keep the boundaries.

Run it: Warm up the layer thinking this flow depends on by playing the architecture game below. Start the quiz to reason through reference-model scenarios, then use the layer builder to place each IoT component into the layer that owns it – device input, message format, or local decision – and press Check Builder to see misplacements. Carry the same boundary discipline into the read, format, decide, and capture functions you write next.

read_device_input()
  -> returns readings, manual trigger, timestamp, quality flag

format_payload(input_record)
  -> returns structured message with readings and quality information

evaluate_local_decision(input_record)
  -> returns normal, alert, invalid, or manual-trigger state

capture_evidence(input_record, payload, decision)
  -> records test id, observed output, notes, and pass/fail result

Do Not Collapse the Layers

Avoid a single long loop that reads inputs, builds payloads, checks thresholds, drives outputs, and prints review text in one block. That design is hard to test and hides responsibility boundaries. Each layer should be callable and inspectable on its own.

10.7 Payload Contract

The payload should be boring and stable. Keep it easy to inspect.

Identity

Device id, firmware or lab version, and scenario name.

Time

Timestamp or monotonic run counter so test evidence can be ordered.

Readings

Temperature, humidity, manual trigger, and units.

Quality

Valid flag, error reason, stale flag, or missing-reading note.

Example payload shape:

{
  "device_id": "lab-node-01",
  "scenario": "environment-monitor",
  "run_id": "run-03",
  "readings": {
    "temperature_c": 31.5,
    "humidity_percent": 68,
    "manual_trigger": false
  },
  "quality": {
    "valid": true,
    "reason": "ok"
  }
}

10.8 Test Matrix

Run the lab as a set of tests, not as a one-time demonstration.

Reference architecture lab test matrix showing normal, high-threshold, manual-trigger, invalid-reading, delayed-reading, and reset-recovery runs with the evidence required for each row.

Normal Reading

Valid readings stay inside limits. Payload is valid. Local decision remains normal.

High Threshold

A reading crosses the threshold. Payload remains valid. Local decision becomes alert.

Manual Trigger

The trigger is active. Local decision shows manual alert even if readings are inside limits.

Invalid Reading

A sensor value is missing or invalid. Payload quality is marked invalid. Threshold logic does not fire from bad data.

Delayed Reading

A reading is stale or delayed. The lab record shows whether the system suppresses, marks, or holds output.

Reset Recovery

Restart the lab target and verify it returns to known state with a new evidence record.

Pass rule: A test passes only when the input, payload, decision, output, and reviewer note agree. A visible LED, print line, or dashboard value by itself is not enough.

10.9 Lab Record Board

Capture the evidence the same way each time.

IoT lab evidence board showing test id, input, payload, local decision, output, reviewer note, pass result, and review condition.

For each run, record:

• test id and scenario;
• input values and how they were produced;
• payload text or captured message;
• local decision state;
• output state or alert state;
• evidence location, such as serial log, simulator screenshot, or bench note;
• pass/fail result and reason;
• condition that would require a retest.

10.10 Common Implementation Pitfall

The most common failure is mixing layer responsibilities.

bad_loop()
  read sensor
  build message
  compare threshold
  drive output
  print review text

That structure makes every change risky. A payload-format change should not alter threshold behavior. A sensor replacement should not alter operator workflow. A dashboard change should not alter device input validation.

Use this structure instead:

input_record = read_device_input()
payload = format_payload(input_record)
decision = evaluate_local_decision(input_record)
output_state = apply_output(decision)
capture_evidence(input_record, payload, decision, output_state)

10.11 Extension Plan

After the core lab passes, extend it one layer at a time.

Reference architecture lab extension route from the core input-payload-decision lab through accumulation, abstraction, application, operations, update evidence, and retest ownership.

Data Accumulation

Store accepted payloads with timestamps, quality flags, and run ids for later review.

Data Abstraction

Expose a stable reading or zone record so applications do not depend on device-specific fields.

Application View

Show normal, alert, invalid, stale, and manual-trigger states in a human-readable view.

Operations Record

Define who responds, how a failed reading is triaged, and what evidence closes the lab issue.

Update Record

Record firmware or configuration version, change reason, rollback expectation, and retest result.

10.12 Knowledge Check

Quiz: Lab Boundary Proof

Match Lab Artifact to Architecture Role

Order the Lab Record Flow

Common Pitfalls

1. Treating a Demo as a Lab

A demo shows that something can happen once. A lab proves behavior across normal, alert, invalid, delayed, manual-trigger, and recovery cases.

2. Hiding Data Quality Problems

Do not replace missing readings with normal-looking values. Mark the quality condition and prove the decision layer handles it.

Tool Steps Are Not Proof

Clicking a simulator button or flashing a board is setup work. Architecture proof is the captured input, payload, decision, output, and review record.

4. Mixing Format and Decision Logic

A change from JSON to another payload format should not require rewriting local threshold logic. Keep formatting and decisions separate.

5. Ending Without Reopen Triggers

A lab record should say what would require retesting: new sensor, new threshold, new payload field, new storage path, or failed recovery behavior.

Key Concepts

• Lab evidence: The captured proof that input, payload, decision, output, and notes agree for a test case.
• Payload contract: The message structure that carries readings and quality information across layer boundaries.
• Quality flag: A field that marks whether a reading is valid, missing, delayed, stale, or otherwise unsafe for normal decision logic.
• Local decision: Logic that acts on validated input before storage, dashboard, or operations layers are involved.
• Review condition: A condition that makes the lab result no longer sufficient, such as a new device input, changed threshold, or failed recovery case.

10.13 Overview: Evidence Is The Architecture

This lab is not finished when the device produces a normal-looking output. It is finished when the evidence shows which layer accepted the input, which layer shaped the payload, which layer made the local decision, and which record lets another reviewer replay the result.

The architecture claim is therefore a proof chain. A good run can show normal behavior, but a useful lab also proves invalid input, delayed input, manual override, reset recovery, and the exact boundary that owns each failure.

Use a small environmental monitor to keep the proof concrete. The device-input layer can be an ESP32 reading a DHT22-style temperature and humidity sensor, a Wokwi simulation, or a Python script that feeds the same fields from fixtures. The important point is that each run produces a raw input record before anything else changes it. That record should include timestamp or run counter, source, units, manual-trigger state, and quality status such as valid, missing, stale, or out-of-range.

The payload layer then turns that input into a stable JSON-like contract with device id, scenario, readings, units, quality reason, and run id. The decision layer reads validated input, not raw pins or display text, and produces normal, alert, invalid, stale, or manual-trigger state. The lab-record layer stores the input, payload, decision, visible output, note, pass/fail result, and review condition. When those artifacts line up, the architecture is visible instead of implied.

Keep the artifacts beside the chapter or lab notebook rather than relying on memory. A fixture file, serial transcript, simulator screenshot, expected payload schema, and short acceptance note let the same run be compared after a sensor swap, library upgrade, threshold edit, or dashboard change.

Use the modern layer map inside the depth review to keep the lab focused on input, payload, and decision evidence before adding storage, dashboards, or operations workflow.

10.14 Lab Record

Before extending the lab toward storage, dashboards, or operations, make the core record replayable. A reviewer should be able to read one row and know what happened without asking which script, sensor board, or simulator button produced it.

Input Proof

Record the reading source, timestamp or run counter, raw value, quality flag, and any manual trigger state.

Boundary Proof

Record the payload fields, validation result, local decision, output state, and the layer that owns the next action.

Review Proof

Record pass or fail, evidence location, reviewer note, and the review condition that would make the result stale.

This is why the invalid-reading and delayed-reading cases are as important as the alert case. They prove that the lab does not silently convert bad input into a confident application decision.

A useful lab row is specific enough to rerun. For example, run-04 might inject temperature_c: null, humidity_percent: 63, manual_trigger: false, and quality.reason: missing_temperature. The expected payload keeps the missing value visible, the local decision returns invalid rather than alert, the output shows a fault indicator rather than a threshold alarm, and the reviewer note points to the serial log or simulator capture. If the same row only says “LED on” or “test passed,” it is not architecture evidence.

Keep the normal and alert cases equally explicit. A normal case proves units, timestamp, payload shape, and non-alert output. A high-temperature case proves threshold ownership. A manual-trigger case proves that operator input has a separate path from sensor thresholds. A reset case proves the first record after restart does not inherit hidden state from the previous run.

Name artifact paths in the row, such as fixtures/run-04.json, logs/run-04-serial.txt, captures/run-04.png, and the commit or build id. Then write the acceptance criteria as observable facts: payload marks the missing field, decision is invalid, alert threshold is not evaluated, and the output uses the fault indicator.

10.15 Boundary Collapse Hides Defects

When input reading, payload formatting, threshold logic, output control, and review text live in one long loop, a lab can pass by accident. A payload-format change can alter decision behavior. A missing sensor value can look like a normal reading. A dashboard label can become the only evidence that an alert happened.

Separated functions make defects visible. The device-input layer can mark bad readings, the payload layer can carry quality evidence, the decision layer can refuse invalid data, and the lab-record layer can show which case failed.

The failure mode is usually an implicit dependency. A function that formats JSON might also clamp values, so the decision layer never sees an out-of-range input. A display routine might translate invalid into the same red LED used for a high threshold, so the reviewer cannot distinguish a sensor fault from a real alert. A reset routine might clear output state but leave the last payload in memory, so the next record looks current when it is stale. Each of those defects hides because the lab observes the final output instead of the boundary evidence.

Make the checks small enough to isolate. Unit-test read_device_input() with valid, missing, stale, and manual-trigger fixtures. Test format_payload() without driving outputs. Test evaluate_local_decision() with validated input objects, including invalid quality states. Then test capture_evidence() to confirm it records the source fields, not only the final output. The integrated run should prove the same boundaries in order, not replace them.

Regression fixtures also guard against well-intended refactors. A payload-format change should preserve decision outcomes for the same validated input. A threshold change should alter only the decision cases it names. A parser change should not convert null, stale, or missing readings into numeric values just because the display layer expects a number.

10.16 Summary

This lab demonstrates layered architecture through evidence, not through a specific board or simulator. A clean lab separates device input, payload formatting, local decision logic, and evidence capture. It proves normal, alert, invalid, delayed, manual-trigger, and recovery behavior. It then explains how the same core flow can grow into accumulation, abstraction, application, operations, and update evidence without collapsing responsibility boundaries.

10.17 Key Takeaway

Reference-architecture labs should map real requirements to layers, responsibilities, data flows, security boundaries, and validation evidence.

10.18 What’s Next

Interactive Quiz and Game

Test reference-architecture reasoning after completing the lab evidence flow.

Worked Example: Smart Building System

Apply the same evidence-first thinking to a full scenario mapping.

Architecture Interview Prep

Practice explaining lab evidence as an architecture interview answer.