Connected Product and Service Design · Study deck
IoT Design Patterns: Responsibility Boundaries
A building light can fail after one part changes because no one knows which part owns state.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- define component boundaries that hide implementation details but expose the evidence a system needs
- explain when Gateway, Digital Twin, Command, and Observer patterns fit an IoT design problem
- combine patterns without hiding ownership, stale state, duplicate commands, or event-ordering problems
- use model-driven design when repeated deployments need consistent generated artifacts
Major section
Start Simple
The team needs to know which part owns the command, which part stores state, and which part reports the result.
- A pattern is useful when it makes that duty clear.
- A gateway is a device or service that joins one system boundary to another.
- A design pattern is a reusable way to assign a job.
- It sits at a boundary.
Major section
Start Simple (continued)
A gateway may translate and buffer.
- A digital twin may hold a known view of device state.
- A command record may track an asked-for action.
- An observer may pass an event to listeners.
- Each choice needs a clear owner, input, output, fault state, and test.
Major section
Overview: Patterns Assign Responsibility
IoT patterns are useful when they make a responsibility testable.
- A gateway is not just a box between devices and the cloud.
- A digital twin is not just a database row.
- A command is not just a function call.
- An observer stream is not just a list of subscribers.
Major section
Overview: Patterns Assign Responsibility (continued)
The room twin then represents occupancy and freshness rather than owning the sensor itself.
- Each pattern should clarify who owns state, what crosses the boundary, what fails visibly, and what support can inspect.
- It may need commands because physical actions must be accepted, rejected, retried, or audited.
- The pattern record should also show rejected alternatives.
Major section
Overview: Patterns Assign Responsibility (continued)
It may need observers because dashboards, logs, alerts, and support views should receive events without becoming hidden controllers.
- A light sensor sends a reading through the gateway, where the MQTT contract names the topic, schema, units, timestamp source, and retry rule.
- A command follows a separate route back toward the device, where local fallback and the result must be visible.
- That distinction is needed when a repeated command or stale reading reaches the dashboard.
Major section
Overview: Patterns Assign Responsibility (continued)
For a building-control system, a gateway may translate Modbus, BACnet, Zigbee, or BLE data into MQTT topics.
- A room twin may represent occupancy, freshness, confidence, and actuator relationships.
- A command handler may validate authorization and preconditions before changing ventilation.
- Observer events may feed dashboards, logs, alerts, and support tools without turning every subscriber into a controller.
Major section
Practitioner: Make Contracts Concrete
Pattern reviews should leave behind contracts that engineers and support teams can test.
- For a gateway, that means the device-side protocol, normalized field names, units, timestamp source, queue limit, retry policy, and local fallback rule.
- For a twin, it means desired state, reported state, last update time, confidence, relationship fields, schema version, and authority for conflict resolution.
- The pattern choice should explain why the selected option fits the user promise and operating burden.
Major section
Boundary Drift in Models
A gateway and cloud service may both rewrite device state.
- A command queue and direct API may both actuate the same relay.
- A digital twin may store desired state while the dashboard treats it as measured state.
- An observer may publish an event that one subscriber treats as a fact and another treats as a command.
Major section
Boundary Drift in Models (continued)
The technical cause is usually a missing authority rule.
- Telemetry, state, command intent, command result, alert, and support diagnosis are different facts even when they share a device ID.
- A robust pattern model separates them before code is written.
- Each one needs a timestamp, version, and failure label.
- Under the hood, the safest pattern combinations are traceable.
Major section
Boundary Drift in Models (continued)
A source model can generate MQTT topics, JSON Schema payloads, OpenAPI documentation, dashboard labels, test fixtures, or support checklists.
- A sensor event can be followed through topic, schema, gateway log, twin update, observer event, dashboard render, and support record.
- A command can be followed from issuer, permission check, precondition, queue, actuator acknowledgement, retry decision, and user feedback.
- Version contracts: version schemas, events, commands, and generated artifacts so old devices and new services can coexist safely.
Deck summary
Key takeaways
The team needs to know which part owns the command, which part stores state, and which part reports the result.
- A gateway may translate and buffer.
- IoT patterns are useful when they make a responsibility testable.
- The room twin then represents occupancy and freshness rather than owning the sensor itself.
- It may need observers because dashboards, logs, alerts, and support views should receive events without becoming hidden controllers.
Retrieval practice
Recall check 1 of 4
UX Uma says: answer from memory, then check your reasoning.
Q1A team chooses a gateway, digital twin, command handler, and observer stream for shared building controls. Which pattern record makes the boundary decision reviewable?
Show answer
Answer: D A reviewable pattern decision ties the product promise, boundary, selected pattern, rejected alternative, interface contract, state or command behavior, failure mode, evidence, owner, open issue, and change condition together before implementation.
Retrieval practice
Recall check 2 of 4
UX Uma says: answer from memory, then check your reasoning.
Q2A gateway service can be replaced, but the new service may drop duplicate commands. What must its component boundary specify?
Show answer
Answer: B Inputs, outputs, state owner, duplicate-command behavior, errors, and test evidence.
Retrieval practice
Recall check 3 of 4
UX Uma says: answer from memory, then check your reasoning.
Q3Several sites use generated device topics and dashboard labels. A label is wrong in every site. What should the team fix first?
Show answer
Answer: C Correct the reviewed source model, regenerate the artifacts, and trace the model version.
Retrieval practice
Recall check 4 of 4
UX Uma says: answer from memory, then check your reasoning.
Q4A small monitor needs only its last known room state. No team needs simulations or linked assets. Which design is easiest to justify?
Show answer
Answer: A A simple state path can meet the reviewed need without an extra twin service.
Print reference
Answers
Answer key.
- D · A reviewable pattern decision ties the product promise, boundary, selected pattern, rejected alternative, interface contract, state or command behavior, failure mode, evidence, owner, open issue, and change condition together before implementation.
- B · Inputs, outputs, state owner, duplicate-command behavior, errors, and test evidence.
- C · Correct the reviewed source model, regenerate the artifacts, and trace the model version.
- A · A simple state path can meet the reviewed need without an extra twin service.