55  Processes and Systems: Overview

In 60 Seconds

Process control is the foundation of IoT automation: sensors measure process variables (temperature, pressure, flow), controllers compute corrective actions, and actuators execute them. Feedback loops maintain stability – without feedback, open-loop systems drift. Key performance metrics: settling time (how fast the system reaches setpoint), overshoot (how far it exceeds setpoint), and steady-state error (permanent offset from target). Typical IoT control loops sample at 1-100 Hz depending on process dynamics.

55.1 Learning Objectives

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

• Explain the fundamentals of process control systems and their role in IoT architectures
• Distinguish between processes (algorithms transforming inputs to outputs) and systems (interconnected components)
• Construct block diagram representations of IoT systems at multiple levels of abstraction
• Decompose IoT systems into hierarchical subsystems (device, network, cloud) for modular design
• Evaluate system response characteristics including settling time and overshoot
• Map sensing and actuation components within closed-loop control architectures

Key Concepts

• System: A collection of interacting components that transforms inputs into outputs, with boundaries defining what’s inside versus outside the system
• Process: A series of actions or steps that transform inputs (materials, energy, information) into outputs with added value
• Feedback Loop: A mechanism where system outputs are measured and compared to desired setpoints, generating control signals that adjust inputs
• Closed-Loop Control: Systems that automatically adjust based on feedback to maintain desired behavior without human intervention
• Open-Loop Control: Systems that operate according to predetermined inputs without measuring or responding to actual outputs
• System Stability: The ability of a system to return to equilibrium after disturbances, critical for reliable IoT device operation

Chapter Overview

This chapter explores the fundamental concepts of processes and systems in IoT architectures. Understanding how electronic systems transform inputs into outputs through controlled processes is essential for designing robust IoT solutions. We’ll examine feedback mechanisms that enable systems to self-regulate and maintain desired behaviors.

Learning Objectives:

• Define processes and systems in the context of IoT devices
• Distinguish between open-loop and closed-loop control systems
• Analyze feedback mechanisms and their role in system stability
• Understand PID (Proportional-Integral-Derivative) control theory
• Apply control system principles to IoT device design
• Evaluate trade-offs between different control strategies

55.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• Sensor Fundamentals and Types: Understanding how sensors measure physical phenomena is fundamental to grasping how systems gather inputs and monitor outputs for feedback control
• Actuators: Knowledge of actuators that convert control signals to physical actions helps understand how systems produce outputs in response to processed inputs
• IoT Reference Models: Familiarity with the layered IoT architecture provides context for where processes and systems operate within the broader device-to-cloud continuum

55.3 What is a Process and What is a System?

⏱️ ~10 min | ⭐ Foundational | 📋 P04.C22.U01

⭐ Difficulty: Foundational

For Beginners: Control Systems in IoT

Every thermostat, automatic door, and cruise control uses control systems—mechanisms that automatically maintain desired behavior without human intervention.

Simple example: Room thermostat. You set target temperature (22°C). Thermostat measures actual temperature (18°C), calculates error (4°C too cold), turns on heater. Room warms up, thermostat measures again (20°C), adjusts heater output. Eventually reaches 22°C and maintains it. This is a feedback loop.

Two types of control:

1. Open-Loop: Execute predetermined actions without measuring results (toaster timer—doesn’t check if bread is actually toasted, just runs for set time)
2. Closed-Loop: Measure output, compare to target, adjust inputs based on error (thermostat—continuously checks temperature and adjusts heater)

PID Controller (Proportional-Integral-Derivative): The gold standard for smooth control. Three components:

• P (Proportional): React to current error (room is 4°C cold → use 4× heater power)
• I (Integral): React to accumulated past error (been cold for 10 min → increase heater more)
• D (Derivative): React to rate of change (temperature rising fast → reduce heater to avoid overshoot)

Term	Simple Explanation
System	Collection of components working together (sensors + processor + actuators)
Process	Series of actions transforming inputs to outputs (algorithm running on microcontroller)
Feedback Loop	Measuring output and using it to adjust input (thermostat reading temperature, adjusting heater)
Setpoint	Desired target value (22°C for room temperature)
Error	Difference between setpoint and actual value (setpoint - measured)
Actuator	Device that does physical work (heater, motor, valve)

Why it matters for IoT: Every smart device uses control systems. Smart thermostats (temperature control), irrigation systems (soil moisture control), autonomous vehicles (speed/steering control), robotic arms (position control). Understanding PID helps you design stable, responsive IoT devices.

Common mistake: Setting PID gains too aggressively causes oscillation (heater rapidly turns on/off, room temperature swings wildly). Conservative tuning is smoother but slower to respond. It’s an art.

Real example: Sous vide cooker maintains water at exactly 57.0°C for 2 hours. Without PID, it would oscillate ±3°C. With PID, stays within ±0.1°C. Same hardware, smarter control algorithm.

For Kids: Meet the Sensor Squad! 🌟

A control system is like having a helper who keeps checking and adjusting things to make them JUST RIGHT - like Goldilocks, but for machines!

55.3.1 The Sensor Squad Adventure: The Perfect Porridge Problem

The Sensor Squad was helping Grandma’s Smart Kitchen make the perfect porridge for breakfast. But there was a problem - the porridge kept coming out wrong!

“Too hot! Too cold! Too hot again!” cried Sammy the Temperature Sensor as he watched the porridge temperature bounce up and down. Bella the Battery was getting tired from all the work. “We need a better plan!”

Max the Microcontroller had an idea. “Let’s use something called a FEEDBACK LOOP! Sammy, you keep watching the temperature. Tell me if it’s too hot, too cold, or just right. I’ll adjust the stove based on what you say!”

The team got to work. Sammy watched the porridge: “It’s 50 degrees - way too cold! We need 80 degrees!” Max turned the stove up HIGH. A minute later, Sammy reported: “Now it’s 95 degrees - TOO HOT!” Max turned the stove DOWN.

But something was still wrong. The temperature kept going up and down like a seesaw: 95… 65… 90… 70… The porridge was never staying at the perfect 80 degrees!

Lila the LED had a clever observation: “Max, you’re being too dramatic! When we’re close to 80 degrees, don’t change the stove so much. Make TINY adjustments instead of BIG ones!”

Max tried Lila’s advice. When Sammy said “78 degrees,” Max turned the heat up just a TINY bit. When Sammy said “82 degrees,” Max turned it down just a LITTLE. Soon the temperature was steady at exactly 80 degrees!

“HOORAY!” cheered the Squad. “The porridge is PERFECT!”

“That’s called PID control,” explained Max proudly. “We look at how far we are from our goal (that’s the P), we remember if we’ve been wrong for a long time (that’s the I), and we notice if we’re getting hotter or colder quickly (that’s the D). Put them all together, and we can control ANYTHING perfectly!”

55.3.2 Key Words for Kids

Word	What It Means
Feedback Loop	Checking the result and adjusting based on what you see - like tasting soup while cooking and adding more salt if needed
Setpoint	The perfect target you’re trying to reach - like 80 degrees for porridge
Error	How far away you are from perfect - like “we’re 10 degrees too cold”
PID Controller	A smart helper that uses three tricks (P, I, D) to reach the perfect target smoothly without overshooting

55.3.3 Try This at Home!

The Blindfolded Temperature Game!

1. Fill a cup with warm water (have a grown-up help!)
2. Put a thermometer in the water and note the starting temperature
3. Your goal: Get the water to EXACTLY 30 degrees Celsius (or pick any target)
4. One person watches the thermometer and calls out: “Too hot!” or “Too cold!” or “Perfect!”
5. Another person (blindfolded or looking away) adds tiny amounts of hot or cold water based on the calls
6. See how long it takes to reach exactly 30 degrees and STAY there!

What you’ll discover:

• If you add too much water at once, you’ll overshoot (just like Max did at first!)
• Small, careful adjustments work better than big, dramatic ones
• The person watching (like Sammy) is the “sensor” - the person adjusting is the “controller”

This is EXACTLY how your home thermostat, your refrigerator, and even cruise control in cars work - they’re all using feedback loops to stay at the perfect temperature or speed!

Cross-Hub Connections

This chapter connects with multiple learning resources across the module:

Interactive Learning:

• Simulations Hub: Experiment with PID control simulators to see real-time effects of changing Kp, Ki, and Kd parameters. Adjust gains and observe overshoot, settling time, and steady-state error interactively.
• Videos Hub: Watch PID tuning tutorials showing real hardware implementations. See Ziegler-Nichols tuning method demonstrated on actual temperature control systems.

Self-Assessment:

• Quizzes Hub: Test your understanding of open-loop vs closed-loop systems, PID term identification, and control system design trade-offs with immediate feedback.
• Knowledge Gaps Hub: Address common misconceptions about steady-state error (why P-only control can’t eliminate it), integral windup (when and why it occurs), and derivative noise sensitivity.

Practical Application:

• Try the interactive PID simulators in the Simulations Hub—modify Kp to see overshoot changes, adjust Ki to eliminate steady-state error, and tune Kd to reduce oscillations. These hands-on experiments reinforce the mathematical concepts.

Most electronic systems, particularly IoT devices, are designed to perform specific tasks. These can be broken down into two fundamental components: the process and the system.

Related Chapters

Deep Dives:

• Processes Labs and Review - Hands-on PID implementation
• Sensor Fundamentals - Feedback sensors
• Actuators - Control outputs

Comparisons:

• Edge Fog Computing - Distributed control systems
• M2M Fundamentals - Machine control architectures

Products:

• Application Domains - Industrial automation
• Prototyping Hardware - Arduino/ESP32 controllers

Learning:

• Simulations Hub - Control system simulators
• Videos Hub - PID tuning tutorials

55.4 Knowledge Check

Test your understanding of these architectural concepts.

Quiz 1: What is a Process and What is a System?

55.5 Key Definitions

Process

A series of actions or steps taken to achieve a particular end. In IoT devices, this is typically implemented by the program running on the microcontroller. The process defines how the device accomplishes its goal.

System

A set of things working together as parts of a mechanism or interconnecting network; a complex whole. In IoT, a system comprises the microcontroller, sensors, actuators, and their interactions working together to perform a specific function.

An electronic system is a physical interconnection of components that gathers information, processes it, and produces output. The sensors provide input, actuators provide output, and the microcontroller executes the process that transforms inputs into outputs.

Figure 55.1: Sensor-to-actuator data flow with environmental feedback loop

Electronic System Components: Sensors gather environmental inputs, microcontroller processes data through algorithms, actuators produce physical outputs, and feedback loops enable system adaptation.

55.5.1 Block Diagram Representation

Figure 55.2: Conceptual diagram showing the relationship between processes (sequence of operations) and systems (interconnected components) in IoT architectures

Complex electronic systems can be represented as interconnected “black boxes” where each box represents an individual component or subsystem. This block-diagram representation allows us to analyze systems at different levels of abstraction without getting overwhelmed by implementation details.

Example: Coffee Pot System

Consider a simple coffee maker as an IoT-enabled system:

Figure 55.3: Coffee pot input-process-output flow with monitoring

Coffee Pot System Flow: Materials (coffee, water, filter) and energy (electricity) inputs are processed through heating, pumping, and monitoring subsystems to produce hot coffee and status outputs.

Inputs:

• Ground coffee (material)
• Water (material)
• Filter (material)
• Electricity (energy)
• Start command (signal/control)

Process:

• Heat water to optimal temperature (92-96°C)
• Pump water through coffee grounds
• Monitor temperature and flow rate
• Execute brewing algorithm

Outputs:

• Hot brewed coffee (primary output)
• Status indicators (LEDs, mobile notifications)
• Brewing completion signal

Constraints:

• Physical size of coffee maker
• Quantity of coffee and water available
• Power consumption limits
• Brewing time requirements

Mechanisms:

• User must load filter with coffee
• User must fill water reservoir
• System must detect water level
• Safety shutdown if reservoir empty

55.5.2 IoT System Decomposition

Modern IoT systems can be decomposed into hierarchical blocks at multiple levels:

Figure 55.4: IoT system decomposition: device, network, and cloud layers

Hierarchical System Decomposition: IoT systems break down into device, network, and cloud layers. The device layer further decomposes into sensor, microcontroller, actuator, and power subsystems, each with specific components.

This hierarchical view helps engineers: - Identify component boundaries and interfaces - Isolate problems during debugging - Design modular, reusable subsystems - Optimize specific subsystem performance

Alternative View: Control System Timing Perspectives

This variant shows the same control system concepts from a temporal perspective, illustrating how control actions and responses unfold over time.

Figure 55.5: Alternative view: Control system timing varies dramatically by application. Fast control (motor position, power electronics) operates in microseconds to milliseconds. Medium control (temperature, pressure) operates in seconds. Slow control (building HVAC, chemical processes) operates over minutes to hours. The control loop period must be faster than the system dynamics—sampling too slowly causes instability, too fast wastes resources.

Quiz 2: Feedback Loop Function

Putting Numbers to It

Using the greenhouse example, trace how error signal drives control decisions:

t=0: Setpoint = 25°C, measured = 27°C → Error = \(25 - 27 = -2\)°C (cooling needed) t=5min: Vents opened, measured = 26°C → Error = \(25 - 26 = -1\)°C (less cooling) t=10min: Measured = 24.5°C → Error = \(25 - 24.5 = +0.5\)°C (close vents, maybe heat) t=15min: Measured = 24°C → Error = \(25 - 24 = +1\)°C (activate heater)

If setpoint suddenly changes to 22°C at t=15min while measured=24°C: new error = \(22 - 24 = -2\)°C, immediately switches from heating to cooling. The sign of error determines action direction: positive error (too cold) → add energy, negative error (too hot) → remove energy.

Quiz 3: System Decomposition

Worked Example: Decomposing a Smart Irrigation System

Scenario: You are designing a smart irrigation system for a 5-acre farm. The system must automatically water crops based on soil moisture levels, weather forecasts, and crop type. Use block diagram decomposition to analyze the system and identify key components.

Step 1: Top-Level System View

At the highest level, the smart irrigation system has:

Inputs:

• Soil moisture readings (from sensors in field)
• Weather forecast data (from cloud API)
• User preferences (crop type, watering schedule)

Process:

• Determine optimal watering schedule
• Activate irrigation zones as needed
• Monitor water flow and adjust

Outputs:

• Water delivery to crop zones
• Status dashboard for farmer
• Alerts for issues (low water pressure, sensor failures)

Step 2: Device-Level Decomposition

Breaking down the device layer into subsystems:

Subsystem	Components	Function	Interfaces
Sensor Subsystem	12× soil moisture sensors (capacitive), 1× flow meter	Measure soil moisture (0-100%), water flow (GPM)	I2C/analog to MCU
Controller Subsystem	ESP32 microcontroller, SD card for logging	Run control algorithm, log data, manage communication	UART, SPI, I2C buses
Actuator Subsystem	4× solenoid valves (12V, 1” diameter), relay board	Control water flow to 4 zones independently	GPIO pins to relays
Power Subsystem	12V 5A power supply, voltage regulator (3.3V)	Provide power to all components	Power rails
Communication Subsystem	Wi-Fi module (built-in ESP32), LoRa (optional)	Send data to cloud, receive commands	MQTT over Wi-Fi

Step 3: Network-Level Decomposition

The network layer connects device to cloud:

Component	Protocol	Function	Data Rate
Local Gateway	MQTT broker on edge (optional)	Aggregate multiple field controllers	10 KB/hour per controller
Internet Connection	4G LTE (cellular fallback if no Wi-Fi)	Reliable cloud connectivity	50 KB/hour total
Cloud Endpoint	AWS IoT Core / Azure IoT Hub	Receive telemetry, send commands	MQTT over TLS

Step 4: Cloud-Level Decomposition

The cloud layer provides intelligence and user interface:

Service	Function	Technology	Cost
Data Ingestion	Receive and store telemetry	IoT Hub + time-series DB	$15/month
Weather Integration	Fetch forecasts, adjust watering	Weather API (OpenWeather)	$40/month
Control Logic	Calculate optimal irrigation schedule	Lambda/Functions (Python)	$5/month
Dashboard	Show soil moisture, water usage, costs	Web app (React)	$0 (static hosting)
Alerting	Send SMS/email for failures	SNS / SendGrid	$2/month

Step 5: Control Flow Analysis

Tracing a typical control loop through the decomposed system:

1. Sensor Subsystem (Device): Capacitive sensor measures 35% soil moisture in Zone 2
2. Controller Subsystem (Device): ESP32 reads sensor via I2C, compares to threshold (40%)
3. Communication Subsystem (Device): ESP32 sends MQTT message: {"zone": 2, "moisture": 35, "status": "dry"}
4. Network Layer: MQTT message routed through cellular gateway to cloud
5. Cloud Control Logic: Python function checks weather forecast (no rain predicted), calculates watering duration (15 minutes based on crop type and deficit)
6. Cloud Response: Sends MQTT command: {"zone": 2, "action": "water", "duration": 900}
7. Controller Subsystem (Device): ESP32 receives command, activates GPIO pin 14
8. Actuator Subsystem (Device): Relay closes, solenoid valve opens, Zone 2 waters for 15 minutes
9. Flow Meter (Sensor): Confirms 22 gallons delivered (1.47 GPM × 15 min)
10. Dashboard (Cloud): Updates display showing Zone 2 watered at 3:45 PM

Step 6: Identify Failure Modes Using Block Diagram

Failure	Affected Subsystem	Impact	Mitigation
Sensor wire cut	Sensor Subsystem	Controller reads invalid data	Sanity check (moisture > 100% → alert)
Wi-Fi outage	Communication Subsystem	Cannot send telemetry to cloud	Local edge control logic (water if <30%)
Cloud API timeout	Cloud Control Logic	No watering commands sent	Edge fallback timer (water daily at 6 AM)
Solenoid valve stuck open	Actuator Subsystem	Continuous watering, water waste	Flow meter timeout (alert if >20 min)
Power failure	Power Subsystem	Complete system down	Battery backup for controller + cellular (8-hour capacity)

Key Design Decision Revealed by Decomposition:

The block diagram reveals that cloud dependency creates a single point of failure. If cloud logic fails, crops do not get watered. The fix: add local edge fallback logic in the Controller Subsystem:

// Edge fallback if cloud unavailable for 4+ hours
if (soil_moisture < 30 && time_since_cloud_command > 4 * 3600) {
    activate_zone_watering(zone, 600); // Water for 10 min
    log_local_action("fallback_watering", zone);
}

Result: System remains functional even during extended internet outages, with local logic providing basic watering based on moisture thresholds.

Key lesson: Hierarchical block diagram decomposition exposes system dependencies and failure modes that are not obvious from a monolithic design view. Identifying subsystem boundaries enables targeted debugging (flow meter issue → Actuator Subsystem only), independent upgrades (swap soil sensor type → Sensor Subsystem only), and resilient fallback logic (edge control when cloud unavailable).

Match System Concepts to Their Definitions

Order the IoT System Decomposition Steps

Label the Diagram

55.6 Key Takeaways

• Systems are collections of interacting components (sensors, processors, actuators) that work together to perform a function
• Processes are the algorithms and steps that transform inputs into outputs within a system
• Block diagrams enable analysis at multiple levels of abstraction without getting lost in implementation details
• Hierarchical decomposition (Device-Network-Cloud) enables modular design, independent debugging, and targeted optimization
• Every IoT device can be analyzed as an input-process-output system with optional feedback loops for self-regulation

Design Consideration

When designing IoT systems using block diagrams, consider:

1. Input validation: What happens if inputs are missing or invalid?
2. Process robustness: How does the process handle edge cases?
3. Output verification: How do we confirm outputs are correct?
4. Error propagation: How do errors in one block affect others?
5. Resource constraints: Power, memory, processing capacity

55.7 Interactive: Control Loop Sampling Rate Calculator

The sampling rate of your control loop must be matched to the process dynamics. Calculate the recommended sampling interval and check if your current sensor rate is adequate.

viewof tau_proc = Inputs.range([0.01, 3600], {value: 60, step: 1, label: "Process time constant τ (seconds)"})

viewof sampling_rule = Inputs.select(["10x faster than τ (rule of thumb)", "Nyquist: 2x fastest frequency", "Ziegler: τ/10 period"], {label: "Sampling rule"})

viewof sensor_max_hz = Inputs.range([0.001, 1000], {value: 0.5, step: 0.001, label: "Sensor max update rate (Hz)"})

{
  let rec_interval_s;
  if (sampling_rule === "10x faster than τ (rule of thumb)") {
    rec_interval_s = tau_proc / 10;
  } else if (sampling_rule === "Nyquist: 2x fastest frequency") {
    rec_interval_s = tau_proc / 20; // conservative: 10x bandwidth
  } else {
    rec_interval_s = tau_proc / 10;
  }
  const rec_hz = 1 / rec_interval_s;
  const sensor_interval_s = 1 / sensor_max_hz;
  const actual_interval = Math.max(rec_interval_s, sensor_interval_s);
  const ok = sensor_max_hz >= rec_hz;
  const color = ok ? "#16A085" : "#E74C3C";
  const status = ok ? "Sensor is fast enough for this process" : "Sensor too slow — control will be degraded";
  return html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid ${color}; margin-top: 0.5rem;">
    <p style="margin:0 0 0.4rem 0;"><strong>Control Loop Timing Analysis:</strong></p>
    <p style="margin:0;">Process time constant: <strong>${tau_proc < 60 ? tau_proc.toFixed(1) + ' s' : (tau_proc/60).toFixed(1) + ' min'}</strong></p>
    <p style="margin:0;">Recommended sampling interval: <strong>${rec_interval_s < 1 ? (rec_interval_s*1000).toFixed(0) + ' ms' : rec_interval_s.toFixed(1) + ' s'}</strong> (${rec_hz.toFixed(3)} Hz)</p>
    <p style="margin:0;">Sensor max rate: <strong>${sensor_max_hz.toFixed(3)} Hz</strong> (${sensor_interval_s.toFixed(2)} s interval)</p>
    <hr style="margin: 0.4rem 0;">
    <p style="margin:0; color:${color};"><strong>${status}</strong></p>
    <p style="margin:0.3rem 0 0 0; font-size:0.85em; color:#7F8C8D;">Actual loop period: ${actual_interval < 1 ? (actual_interval*1000).toFixed(0) + ' ms' : actual_interval.toFixed(1) + ' s'} (limited by ${actual_interval === sensor_interval_s ? 'sensor rate' : 'process dynamics'}).</p>
  </div>`;
}

55.8 What’s Next

If you want to…	Read this
Study feedback mechanisms in detail	Feedback Mechanisms
Explore control types	Open vs Closed Loop Control Types
Learn about PID control implementation	Processes and Systems: PID Control
Study core process fundamentals	Processes and Systems Fundamentals
Practice with the PID simulation lab	PID Simulation Lab

Common Pitfalls

1. Treating Process Control as Only for Chemical Plants

Assuming PID and feedback control only apply to industrial processes. IoT systems control room temperature, drone altitude, motor speed, and battery charging — all are process control problems. The concepts apply whenever any measured variable must be driven toward a target.

2. Skipping Block Diagram Analysis

Jumping directly to code without drawing the system block diagram. Block diagrams reveal the signal flow, identify loop gains, expose sign errors (positive vs negative feedback), and clarify where delays exist. Draw the block diagram before writing any control code.

3. Ignoring Sample Rate Selection

Implementing a digital control loop without explicitly setting the sample rate. The sample rate must be at least 5–10× the desired closed-loop bandwidth. An ad-hoc Arduino loop() without timer-based sampling produces variable timing that makes integral and derivative gains unpredictable.

4. Not Distinguishing the Process from the Controller

Confusing the physical plant (room, motor, boiler) with the control algorithm (PID). They are separate: the plant has fixed dynamics; the controller is designed to compensate for those dynamics. Understanding the plant is a prerequisite to designing the controller.

💻 Code Challenge