Control, Gateways & Networked Systems · Study deck
Systems Thinking: Boundaries and Processes
A greenhouse fan can run while the room stays hot.
Gateway Gus is your guide for this deck.
After studying this chapter
Learning objectives
Describe responsibility and sequence before selecting the implementation.
- A system boundary identifies the design’s owned parts and responsibilities.The greenhouse drawing needs outside influences such as the open door as well as the sensor, controller, and fan.
- A process is an ordered change from input to output.The cold-room example connects a door reading to validation, an alarm, staff action, and evidence that the door returned to normal.
- An interface is a contract for a crossing between responsibilities.Signals, commands, power, data, and human handoffs need explicit owners wherever the process crosses an edge.
- Feedback can correct a process within a wider system.A measured error still needs actuator authority, suitable timing, and fallback when sensing, actuation, or communication becomes unreliable.
Major section
Start With the System Boundary
A turning fan proves movement, while the greenhouse needs evidence of cooling.
- A turning fan does not establish that the greenhouse is cooling.An open door outside the original drawing can explain why functioning equipment still misses the intended result.
- Outside influences can change the physical outcome.The model needs environmental conditions alongside the inputs, internal state changes, and outputs that the team directly owns.
- Each boundary crossing needs an owner for its handoff.People, stored state, information, physical processes, and energy can cross an edge where meaning or responsibility changes.
- Delayed measurements and blocked outputs can expose hidden model assumptions.The chapter also tests disturbances, power loss, and restart with saved state to see which signs reveal a fault.
Major section
Overview: Start With the Boundary
Compare the owned components in the system view with the ordered steps in the process view.
- The system view has device, gateway, service, and operator responsibilities.Those blocks identify the owned components and people involved in the cold-room warning before implementation details are chosen.
- The process view is an ordered path through input, decision, and output.The same warning needs a sequence from a door-open reading through validation and alarm delivery to maintenance action.
- Verification needs evidence that the intended result occurred.The final observation must establish response or closure rather than treating a sent dashboard message as the whole system.
- The two views can connect each action with its responsible owner.A process step without ownership can leave fallback undefined when an external service or human response becomes unavailable.
Major section
External dependencies and fallback ownership
A boundary record also identifies dependencies beyond the owned design.
- Building power and notification services can remain external dependencies.The boundary record must distinguish those outside services from owned blocks even though their failure can interrupt the alarm process.
- An unavailable dependency needs a named responder.A late outage or staffing change can reveal missing responsibility unless the design records fallback before deployment.
- The interface contract identifies what crosses each edge.A signal, command, data record, power supply, or human handoff needs a clear meaning at the boundary.
- Fallback planning needs the complete set of boundary crossings.The cold-room promise must state whether failure leads to local operation, queued records, a safe state, or manual intervention.
Major section
From door reading to incident closure
Trace a cold-room alarm all the way from the door input to closure evidence.
- The door reading must pass validation before the timer starts.The chapter’s door_open input needs freshness and range checks before the controller can rely on its state.
- The alarm decision needs a delivery path to a named responder.Sensor, controller, gateway, dashboard, and staff responsibilities are separate steps in the same cold-room warning process.
- A dashboard notification does not establish maintenance action.A delivered message can coexist with an unresolved local problem if the team assumes that staff have already responded.
- Incident closure needs acknowledgement and evidence of normal door state.The process must reach service action and a close-out record rather than ending at message delivery.
Major section
Practitioner: Build the Decision Record
A short decision record should let another engineer replay the operating promise.
- The operating promise must say when staff need a warning.The chapter’s cold-room door alarm is tied to an allowed open duration and the risk to product quality.
- The record needs sensor, controller, alarm, gateway, dashboard, and recipient ownership.Each block must have a testable responsibility from the validated reading through message acknowledgement and maintenance close-out.
- Failures need defined local operation, buffering, safe states, or manual intervention.The gateway must queue the MQTT event during WAN loss while the local alarm follows its controller rule.
- Changes to placement, thresholds, firmware, services, or staffing need review.The original process promise can change even when the familiar block diagram still has the same boxes.
Activity 1 · Draw it
✎ Trace the cold-room promise
I want you to draw who owns the alarm from reading to resolution.
On paper, sketch the door sensor, controller, local alarm, gateway, dashboard, and responder. Connect the path from a validated reading to a closed maintenance record. Mark where a WAN outage needs buffering.
4 minutes · Pen and paper · Answer: Activity 1
Major section
Why Boundary Failures Spread
Failures spread when one block trusts a condition that nobody has checked.
- Input trust requires calibration, freshness, range, and validity checks.A gateway can forward stale data as a valid incident if it assumes the controller already checked the sensor reading.
- Timers, retries, buffers, and overrides need named owners.The local controller cannot rely on an always-reachable gateway instead of owning the alarm behaviour during connectivity loss.
- Message delivery needs separate evidence from operator or actuator response.The dashboard must not hide an unresolved door incident by interpreting a sent alert as proof that staff acted.
- Separate responsibility checks can support an integrated process test.The chapter tests input, alarm logic, buffering, and acknowledgement individually before verifying the same ownership chain in order.
Major section
Delivered alerts and missing response evidence
Successful delivery can still leave the original incident unresolved.
- A sent alert cannot establish that staff have responded.The dashboard can otherwise hide an unresolved local problem by assuming message delivery completed the human response.
- A missing gateway buffer can erase evidence during an outage.The cold-room event needs queued delivery during WAN loss and a recovery test that proves the record survives.
- Moving a sensor can change the process despite continued message delivery.The original input assumptions and alarm timing need review when sensor position or another meaningful boundary changes.
- Workflow changes require a fresh check of the operating promise.Different thresholds, notification services, gateway firmware, or staffing can invalidate a decision record that still looks familiar.
Major section
Validation, local alarms, and integrated fault tests
Make validation, delivery, and response separate responsibilities with explicit evidence.
- A gateway can forward stale data when validation has no owner.Assuming another block checked the reading can turn bad sensor input into an apparently valid incident.
- The local alarm needs defined behaviour when the gateway is unreachable.The controller must not skip its local warning path because the design assumes connectivity will always be available.
- Delivery logic must preserve the business meaning of the alert.The block that carries a cold-room event must not silently take over validation or operator-response responsibility.
- Fault tests must locate ownership and then verify the integrated chain.Separate input, timer, buffer, and close-out tests need a final process observation that proves the same responsibilities work in order.
Activity 2 · Predict
✎ Remove the WAN connection
I want you to predict which parts of the door alarm should survive an outage.
On paper, cross out the WAN connection during a door-open incident. Predict the local alarm, gateway record, and dashboard close-out behavior. Name evidence needed after connectivity returns.
3 minutes · Pen and paper · Answer: Activity 2
Major section
System, Process, Boundary, and Interface
Use the component view for ownership, then the process view for the order of change.
- The system view identifies device, gateway, service, and operator ownership.These components and people are the bounded collection responsible for the product’s purpose, beyond any single controller or dashboard.
- The process view is the sequence from input to verified output.The cold-room door event needs ordered validation, timing, delivery, action, and closure across those responsibilities.
- A boundary separates owned work from environment and dependencies.Building power or an external notification service can affect the outcome while remaining outside the design’s owned blocks.
- An interface is the contract where responsibilities meet.Signals, power, data, messages, physical movement, or human handoffs need an explicit meaning when they cross the boundary.
Major section
Input-Process-Output Thinking
Read from the physical and information inputs through process steps to verified outputs.
- The input side includes physical, informational, electrical, and human inputs.Readings, commands, power, materials, environmental conditions, and operator actions can all enter the system rather than arriving only as sensor data.
- The process needs validation and decisions before communication or actuation.The cold-room input must be trustworthy before the timer and alarm rule can turn the reading into an action.
- Outputs can be actions, messages, alarms, state changes, or records.The system’s result can include physical movement as well as a stored event or dashboard state.
- Verification needs an observation that the intended output occurred.A sent warning alone cannot establish staff response, so the cold-room process also needs a close-out record.
Major section
Block Diagrams
Move from the top-level system to subsystem interfaces to locate responsibility.
- The top-level blocks identify sensor, controller, actuator, and service responsibilities.The diagram can show the important flow without exposing every wire or implementation detail inside the equipment.
- The expanded controller has input checks, state, policy, and fallback.These responsibilities make it possible to ask which input is trusted and what happens when a dependency fails.
- Subsystem interfaces must preserve ownership and flow.A boundary must remain clear enough for a decision even when engineers view the same design at different levels of detail.
- Every block needs input-trust and output-verification responsibilities.The diagram must identify trusted or rejected inputs, checked outputs, and the point where fallback or manual intervention becomes necessary.
Major section
Decomposing an IoT System
Follow the hierarchy from device duties to network, edge, and remote responsibilities.
- The device owns sensing, local checks, actuation, and immediate fallback.Its responsibility includes power state and local logs alongside physical input and action at the equipment.
- The network path owns translation, retries, buffering, and delivery records.The gateway’s cold-room event buffer is part of delivery evidence during WAN loss and recovery.
- Edge coordination can keep nearby decisions available through outages.Cached policy, short-term history, and equipment limits support local coordination when remote services cannot be reached.
- Remote services and operations have different record and response responsibilities.Long-term history and dashboards support the service view, while acknowledgement and maintenance records must establish that someone responded.
Major section
Where Feedback Fits
Trace the local correction loop, then inspect the surrounding policy and operator handoffs.
- The measurement path carries observed process output to the controller.The controlled variable and its measurement location must be known before that observation can support a correction.
- The controller compares measured state with a target or band.The loop can then correct the next action, while the wider system still owns policy, interfaces, and operator handoffs.
- The actuator needs enough authority and time to correct the process.A turning greenhouse fan alone does not establish cooling, so the measurement-to-response path needs verification.
- The surrounding system needs fallback when loop components become unreliable.Measurement, actuation, or communication failure must have a defined safe behaviour beyond the local correction sequence.
Deck summary
Key takeaways
A useful system model connects an owned boundary with an observable result.
- The design needs inputs, outputs, process, and external influences.The greenhouse fan can turn while the room stays hot if the drawing omits the open door’s effect on the result.
- Every interface and fallback state needs a named owner.Power, network, sensor, dashboard, or recipient failure must lead to a defined response instead of an assumption between blocks.
- Delivered messages cannot establish that someone acted.The cold-room dashboard needs acknowledgement or a maintenance record before treating an incident as resolved.
- A changed boundary or workflow needs the decision record replayed.Placement, timing, thresholds, firmware, services, and staffing can alter the original promise even when the block diagram looks unchanged.
Retrieval practice
Recall check 1 of 2
Gateway Gus says: answer from memory, then check your reasoning.
Q1A site moves a cold-room door sensor to a new hinge position. The dashboard still receives messages, but alarms now arrive late. Which process-and-system record should be reviewed first?
Show answer
Answer: A The physical sensor move can change input timing, validation, alarm timing, and the proof that the process still meets its promise.
Retrieval practice
Recall check 2 of 2
Gateway Gus says: answer from memory, then check your reasoning.
Q2A team draws one box labeled 'smart pump system' and starts coding; in testing, no one can tell which part owns each decision. What should they ask for first?
Show answer
Answer: A Before coding, a process-and-system block diagram should name boundaries, inputs, outputs, interfaces, and fallback behavior.
Print reference
Answers
Answer key.
- A · The physical sensor move can change input timing, validation, alarm timing, and the proof that the process still meets its promise.
- A · Before coding, a process-and-system block diagram should name boundaries, inputs, outputs, interfaces, and fallback behavior.
Print reference
Activity 1 answer
Model answer.
Draw it: The sensor feeds validation and the timer at the controller. The controller drives the local alarm and sends an event through the gateway to the dashboard and responder. The gateway buffers during WAN loss. Acknowledgement or a maintenance record closes the response path.
Print reference
Activity 2 answer
Model answer.
Predict: The local alarm follows its controller rule without the dashboard. The gateway buffers the event during WAN loss. Delivery can resume after recovery, but closure still needs acknowledgement or a maintenance record. Test the buffer through loss and recovery and check the response record.