2 Systems Thinking: Boundaries and Processes

2.1 Start With the Decision

This section: Start With the Decision — A greenhouse fan can run while the room stays hot.

A greenhouse fan can run while the room stays hot. A system boundary must include the open door and the result that matters.

2.2 Route Overview

This section: Route Overview — This is part 1 of 2.

This is part 1 of 2. Continue with Systems Thinking: Decision Records and Communication.

2.3 Part Objectives

This section: Part Objectives

• Draw inputs, process, outputs, boundary, and feedback.
• Decompose an IoT service without hiding interfaces.

2.4 Chapter Roadmap

This section: Chapter Roadmap

• Start With the System Boundary
• In 60 Seconds
• Overview: Start With the Boundary
• Practitioner: Build the Decision Record
• Why Boundary Failures Spread
• Quick Check: System Boundary Decisions
• MVU: Minimum Viable Understanding
• Prerequisites
• System, Process, Boundary, and Interface
• Input-Process-Output Thinking
• Block Diagrams
• Decomposing an IoT System
• Where Feedback Fits

2.5 Start With the System Boundary

This section: Start With the System Boundary — Picture a greenhouse fan that should cool the air.

Draw the Boundary Before Choosing the Parts

Picture a greenhouse fan that should cool the air. The sensor changes, the controller sends a command, and the fan turns, yet the room stays hot because an open door sits outside the team’s drawing. A list of working parts did not explain the whole outcome.

Start with the result that matters. Draw what enters the system, what changes inside, what leaves, and what sits outside but can affect the result. Name the people, physical process, stored state, information, and energy that cross each edge. Assign an owner wherever a handoff changes meaning or responsibility.

Run one normal case, then block the output, delay the measurement, add an outside disturbance, remove power, and restart with saved state. Record what changes, what remains hidden, and which sign reveals the fault. Check that the model supports a decision instead of merely naming boxes.

This first boundary is a useful simplification, not a complete model. The deeper sections show how input-process-output views, block diagrams, decomposition, state, and feedback refine it without losing sight of the physical result.

A process only becomes controllable when its boundary is clear. Before choosing a sensor, dashboard, or controller, ask what enters the system, what leaves it, what state changes inside it, and who is responsible when the change crosses an edge.

That plain boundary view is the starting point for everyday IoT work: pumps, heaters, conveyors, alerts, and gateways all fail in confusing ways when the team cannot say where the process ends. Start with one input, one output, and one state change, then build the system model around that proof.

2.6 Learning Objectives

This section: Learning Objectives

By the end of this chapter, you will be able to:

• Distinguish systems, processes, boundaries, interfaces, inputs, and outputs.
• Draw input-process-output block diagrams for IoT devices and services.
• Decompose an IoT solution into device, network, edge, and remote service responsibilities.
• Place feedback and control choices in context without treating them as the whole design.
• Build a process-and-system decision record that supports later debugging, upgrades, and chapter routing.

2.7 Overview: Start With the Boundary

This section: Overview: Start With the Boundary — If you only need the intuition, this layer is enough: a system is the owned boundary, and a process is the ordered change inside or across that boundary.

If you only need the intuition, this layer is enough: a system is the owned boundary, and a process is the ordered change inside or across that boundary. IoT design becomes easier to inspect when the team can say what enters, what changes, what leaves, and who owns each crossing.

Use Figure 2.1 to separate the owned system boundary from the ordered process that turns inputs into decisions, outputs, and verification.

+

Read Figure 2.1 first across the system view, where device, gateway, service, and operator sit inside or outside an owned boundary. Then follow the process view from input through decision and action to output and verification. The first view answers what is included and who owns each crossing; the second answers what happens next and where evidence is produced. Keeping them separate prevents a cloud box from obscuring an operational handoff or a tidy sequence from omitting an accountable component. Both views should name interfaces, failure states, and review evidence.

For a cold-room monitor, the system boundary includes the door sensor, temperature measurement, local controller, message path, dashboard, and alert owner. The process is the ordered path from a door-open input to validation, alarm decision, message delivery, maintenance action, and proof that the door returned to normal.

That distinction keeps a team from treating a dashboard message as the whole system. A door reed switch, thermistor or RTD, ESP32 or PLC input, gateway, MQTT message, dashboard alarm, and staff acknowledgement can all be part of one system. The process record explains which step validates the reading, which step starts the open-door timer, which step sends the alert, and which step proves someone acted.

The boundary should also name what is outside the design. If building power, a cloud notification service, or a human response team is a dependency rather than an owned block, the record should say so. That makes fallback decisions visible before a late outage or staffing change exposes them.

When the boundary is explicit, later chapters have a stable starting point: feedback discusses correction, networking discusses delivery, and operations discusses response without changing the original promise.

2.8 Practitioner: Build the Decision Record

This section: Practitioner: Build the Decision Record — A process-and-system record should be small enough to keep current, but specific enough that another engineer can replay the decision.

A process-and-system record should be small enough to keep current, but specific enough that another engineer can replay the decision. Start with one operating promise, then write down the boundary and the outputs that prove the promise.

Reject records that only say "use an IoT gateway" or "send data to the cloud." Those labels do not prove input trust, process ownership, output verification, or degraded behavior.

A useful record reads like a replayable incident trace. For the cold-room example, it can say that door_open=true starts a timer only after the input passes freshness and range checks, that a local alarm sounds after the allowed duration, that the gateway buffers an MQTT event if the WAN is down, and that the dashboard state is not accepted as resolved until a maintenance note or acknowledgement closes the loop.

Keep the record short, but make each field testable. The boundary field should list owned blocks and excluded responsibilities. The interface field should name signal, power, data, mechanical, service, and human handoffs. The fallback field should say whether the system continues locally, queues records, enters a safe state, or asks for manual intervention.

Review it after each meaningful change. A different sensor position, alarm threshold, gateway firmware, notification service, or staffing model can change the process even when the block diagram still looks familiar. The record should make that comparison routine rather than political.

2.9 Why Boundary Failures Spread

This section: Why Boundary Failures Spread — The deeper layer explains why process-and-system thinking prevents late-stage surprises.

The deeper layer explains why process-and-system thinking prevents late-stage surprises. Most IoT failures are not isolated to one component. A wrong sensor assumption can create a bad control decision, a missing gateway buffer can erase evidence, and an unclear alert owner can turn a correct measurement into an unresolved incident.

• Input trust: a sensor value needs calibration, freshness, range, and validity checks before a process can rely on it.
• State ownership: timers, retries, buffers, manual overrides, and fallback states must belong to a named block.
• Output proof: a message sent by a device is not the same as an action completed by an operator, actuator, or service.
• Change impact: moving a sensor, gateway, placement boundary, target threshold, or alert workflow can invalidate the original record.

Boundary failures spread because neighboring blocks often make assumptions without owning the evidence. If a gateway assumes the controller already filtered stale readings, it may forward bad data as a valid incident. If the dashboard assumes an alert means staff responded, it may hide an unresolved local problem. If the controller assumes the gateway will always be reachable, it may skip the local alarm path exactly when connectivity fails.

Use small checks to expose those assumptions. Test the sensor input with missing, stale, noisy, and moved-sensor cases. Test the timer and alarm rule without the dashboard. Test the gateway buffer with WAN loss and recovery. Test the close-out record with a real acknowledgement path. The integrated process should then prove the same ownership chain in order.

This is also why decomposition matters. A block that owns validation should not also silently own operator response. A block that owns delivery should not rewrite the business meaning of the alert. Keeping those responsibilities separate makes defects local enough to diagnose.

Practitioner Knowledge Check

2.10 Prerequisites

This section: Prerequisites

Before this chapter, revisit:

• IoT Reference Models: layered responsibility models and architecture vocabulary.
• Feedback Mechanisms: how measurement becomes correction.
• Open vs Closed Loop: when feedback is needed.
• Process Control and PID: how process behavior leads into controller selection.

2.11 System, Process, Boundary, and Interface

This section: System, Process, Boundary, and Interface

A system view answers “what is included?” A process view answers “what happens next?” Both are needed because the same IoT product can be described as physical equipment, firmware, messages, services, support workflow, or a control loop.

2.12 Input-Process-Output Thinking

This section: Input-Process-Output Thinking — A useful first diagram names the inputs, the process that transforms them, and the outputs that should be produced or verified.

A useful first diagram names the inputs, the process that transforms them, and the outputs that should be produced or verified. Inputs can be physical, electrical, informational, or human. Outputs can be actions, data, alerts, material movement, state changes, or records.

Use Figure 2.2 to determine which physical, informational, and human inputs a process transforms and how its outputs will be validated.

+

Follow one input through the process. Check the output. Read Figure 2.2 from physical and information inputs into the process steps that filter, decide, communicate, or actuate. Outputs may be physical actions, records, alerts, or state changes, and each needs an expected condition rather than a box label alone. The validation path compares observed output with that expectation and returns evidence to the decision owner. A useful record names units, timing, source, transformation, destination, failure response, and acceptance limit. This ordering makes hidden human commands, power constraints, and support actions visible alongside sensor data and software logic.

• Inputs: sensor readings, commands, configuration, power, materials, environmental conditions, and operator actions.
• Process: filtering, validation, decision logic, communication, actuation, logging, escalation, and fallback behavior.
• Outputs: physical action, stored data, messages, dashboard state, alarms, reports, and records that the result was checked.
• Constraints: timing, energy, memory, safety, connectivity, accuracy, maintenance access, and ownership boundaries.

2.13 Block Diagrams

This section: Block Diagrams — Block diagrams are useful because they hide implementation detail while preserving responsibility and flow.

Block diagrams are useful because they hide implementation detail while preserving responsibility and flow. The goal is not to draw every wire. The goal is to make the important boundaries, interfaces, and dependencies visible enough for a decision.

Use Figure 2.3 to decide which system, subsystem, interface, and evidence details belong at the current abstraction level before implementation wiring is introduced.

+

Start at the outer boundary. Open only the needed block. Read Figure 2.3 from the top-level system boundary into the subsystem blocks that own sensing, decision, communication, or action. Interfaces between them should name what crosses, in which direction, and under whose control, without collapsing immediately into pins and code. The measured state, event, and safe action show how an evidence path can remain visible at this level. Expand a block only when a review question requires more detail, and carry its assumptions, failure behaviour, owner, and verification back to the parent diagram so abstraction does not sever accountability.

Good block diagrams answer these questions:

• What does each block own?
• What crosses each interface?
• Which input is trusted, filtered, or rejected?
• Which output is verified?
• Which dependency can stop the process?
• Where does the design enter fallback or manual intervention?

2.14 Decomposing an IoT System

This section: Decomposing an IoT System — Hierarchical decomposition helps teams discuss a system at the right level.

Hierarchical decomposition helps teams discuss a system at the right level. A device engineer, network engineer, service owner, operations team, and learner may all need different views of the same design.

A useful review of Decomposing an IoT System must preserve the sequence implied when “Hierarchical decomposition for IoT systems” is explicit in the diagram. Figure 2.4 gives that sequence named checkpoints.

+

Follow the labeled evidence in Figure 2.4: sense, act establishes context, message format exposes the decisive step, and review trigger shows where the result lands. That reading explains “Hierarchical decomposition for IoT systems” is explicit in the diagram. The chapter can now use Decomposing an IoT System as an engineering criterion.

2.15 Where Feedback Fits

This section: Where Feedback Fits — Feedback is one process pattern inside a larger system.

Feedback is one process pattern inside a larger system. A feedback loop measures an output, compares it with a target or band, and corrects the next action. The system still needs boundaries, interfaces, trust checks, and fallback behavior.

Practitioner Knowledge Check

Figure 2.5 places the greenhouse fan loop inside its physical system.

+

The controller compares a measured output with a cooling target or band and changes the fan command. That local feedback loop can make the next action, but the plant response must still be checked: air movement and temperature can lag or change with outside conditions. The diagram separates the command boundary from the physical result and shows where disturbances enter. A log of sensor values and fan state can show whether the loop behaved as designed; a separate observation confirms whether the greenhouse actually cooled. Keep both kinds of evidence before treating the control rule as a system success.

Feedback context should identify:

• The controlled variable and where it is measured.
• The target, band, or policy that defines the intended state.
• The actuator and whether it has enough authority to correct the process.
• The loop timing from measurement to verified response.
• The safe behavior when measurement, actuation, or communication is unreliable.

2.16 Continue to the Next Part

This section: Continue to the Next Part — Carry this evidence into Systems Thinking: Decision Records and Communication, which begins with Decision Records.

Carry this evidence into Systems Thinking: Decision Records and Communication, which begins with Decision Records.