2 Systems Thinking: Boundaries and Processes

2.1 Start With the Decision

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 is part 1 of 2. Continue with Systems Thinking: Decision Records and Communication.

2.3 Part Objectives

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

2.4 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

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

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

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.

Before accepting act/log as the starting point for overview: start with the boundary, inspect Figure 2.1 against Output. Together, act/log and Output frame the overview: start with the boundary claim: use the system/process distinction before choosing controller details, cloud services, or implementation technology.

Trace Figure 2.1 from act/log toward Output; that hand-off expresses use the system/process distinction before choosing controller details, cloud services, or implementation technology. Those labels identify boundary and transformation in overview: start with the boundary, then use act/log for feedback, ownership, and review evidence at Output. At Figure 2.1, record act/log beside Output; without act/log, overview: start with the boundary loses the checkpoint paired with Output.

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

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

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.

2.10 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

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.

Before accepting Output as the starting point for system, process, boundary, and interface, inspect Figure 2.1 against Operator. Together, Output and Operator frame the system, process, boundary, and interface claim: system and process views in iot design.

Trace Figure 2.1 from Output toward Operator; that hand-off expresses system and process views in iot design. Those labels identify boundary and transformation in system, process, boundary, and interface, then use Output for feedback, ownership, and review evidence at Operator. At Figure 2.1, record Output beside Operator; without Output, system, process, boundary, and interface loses the checkpoint paired with Operator.

2.12 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. Inputs can be physical, electrical, informational, or human. Outputs can be actions, data, alerts, material movement, state changes, or records.

Before accepting evidence as the starting point for input-process-output thinking, inspect Figure 2.2 against Validate. Together, evidence and Validate frame the input-process-output thinking claim: input-process-output map for an iot system.

Trace Figure 2.2 from evidence toward Validate; that hand-off expresses input-process-output map for an iot system. Those labels identify boundary and transformation in input-process-output thinking, then use evidence for feedback, ownership, and review evidence at Validate. At Figure 2.2, record evidence beside Validate; without evidence, input-process-output thinking loses the checkpoint paired with Validate.

• 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

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.

Before carrying Block Diagrams into implementation, check the visual evidence for this claim: “Block diagram abstraction levels” is explicit in the diagram. That is the reason Figure 2.3 appears at this point in the narrative.

Figure 2.3 first identifies measured state, then distinguishes event, before reaching safe action. This is not a generic flow: the three labels show “Block diagram abstraction levels” is explicit in the diagram. That sequence connects Block Diagrams to evidence a reviewer can name and retest.

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

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

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.

Before accepting Process as the starting point for where feedback fits, inspect Figure 2.5 against correct. Together, Process and correct frame the where feedback fits claim: feedback loop inside a larger system context.

Trace Figure 2.5 from Process toward correct; that hand-off expresses feedback loop inside a larger system context. Those labels identify boundary and transformation in where feedback fits, then use Process for feedback, ownership, and review evidence at correct. At Figure 2.5, record Process beside correct; without Process, where feedback fits loses the checkpoint paired with correct.

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

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