60  Processes: Core Definitions

In 60 Seconds

IoT systems are decomposed into interconnected subsystems (sensing, processing, networking, actuation) represented as block diagrams with defined inputs, outputs, and transfer functions. Hierarchical decomposition enables independent debugging and optimization – a failing actuator can be isolated without disrupting the entire sensing pipeline.

60.1 Learning Objectives

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

  • Distinguish between processes (algorithms transforming inputs to outputs) and systems (interconnected components) in IoT contexts
  • Construct block diagram representations of IoT systems showing inputs, processing, and outputs
  • Decompose IoT systems into hardware, software, and network subsystems using hierarchical design
  • Identify inputs, outputs, processes, and constraints for a given IoT device scenario
  • Apply modular decomposition principles to isolate failures and optimize specific subsystem performance

60.2 Prerequisites

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

  • Sensor Fundamentals and Types: Understanding how sensors measure physical phenomena is essential for grasping how systems transform inputs into meaningful data
  • Actuators: Knowledge of actuators helps understand how systems produce physical outputs in response to control signals
  • IoT Reference Models: Familiarity with layered IoT architectures provides context for where processes operate within the device-to-cloud stack

60.3 Getting Started (For Beginners)

What Are Processes and Systems? (Simple Explanation)

Analogy: A process is like following a recipe—you have ingredients (inputs), cooking steps (the process), and a finished dish (output). A system is the entire kitchen setup that makes cooking possible.

Simple explanation:

  • Process: Any action that transforms inputs into outputs
  • System: A collection of parts working together toward a goal
  • Control: How you adjust the process to get the desired output

60.3.1 The Kitchen Analogy

Understanding Systems Through Cooking

KITCHEN (System) - Baking a Cake:

Component Role Examples
INPUTS Raw materials & energy Eggs, Milk, Flour, Butter, Electricity
PROCESS Transformation Mixing & Baking
OUTPUT End product Cake
CONTROL Regulation Temperature Setting

Flow: INPUTS → PROCESS → OUTPUT (with CONTROL regulating the process)

Key insight: The temperature dial is your “control”—you adjust it to get the right output!

60.3.2 Self-Check Questions

Before diving into the technical details, test your understanding:

  1. Basic Concept: What’s the difference between a process and a system?
    • Answer: A process is the transformation (input → output). A system is everything that makes it work together.
  2. Real-World: Can you identify the inputs, process, and outputs of a smart light bulb?
    • Answer: Input: power + command signal. Process: interpret command, adjust LED driver. Output: light at specified brightness/color.
Key Takeaway

In one sentence: Systems are collections of components that work together, while processes are the transformations that systems perform on inputs to produce outputs.

Remember this: Every IoT device can be analyzed as a system with inputs (sensors, user commands), processes (algorithms, logic), and outputs (actuators, displays, data).

60.4 What is a Process and What is a System?

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

⭐ Difficulty: Foundational

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.

Knowledge Check

Test your understanding of fundamental concepts with these questions.

60.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.

Flowchart showing basic IoT input-process-output flow: sensors provide input data, microcontroller executes processing algorithm, actuators generate physical outputs, with optional feedback loop returning measured output to the input for closed-loop control.

Basic input-process-output flow in IoT systems
Figure 60.1: Basic input-process-output flow showing how sensors provide inputs, microcontrollers execute processing algorithms, and actuators generate outputs, with optional feedback loop for closed-loop control

Alternative View:

Decision tree diagram of IoT system processing flow showing input validation branch (valid or invalid?), algorithm execution steps, output determination, and feedback loop decision point for closed-loop control, illustrating the decision points where the system chooses different control paths.
Figure 60.2: Decision tree showing system processing flow: Input validation, algorithm execution, output determination, and feedback loop for closed-loop control. This view emphasizes the decision points where the system chooses between different paths based on sensor readings and control requirements.
Layered architecture diagram showing vertical abstraction of IoT system from bottom physical environment layer, through sensing layer, processing layer, control layer, to top actuation layer, with arrows showing how each layer transforms information upward and control signals flow downward.
Figure 60.3: Alternative view: Layered architecture showing vertical abstraction from physical environment through sensing, processing, control, and actuation layers, emphasizing how each layer transforms and processes information

60.6 Block Diagram Representation

⭐ Difficulty: Foundational

Conceptual diagram showing relationship between IoT Processes (sequence of operations transforming inputs to outputs) and Systems (collection of interconnected components) with examples of process types (sensing, computing, actuation) and system boundaries.
Figure 60.4: Conceptual diagram showing the relationship between processes (sequence of operations) and systems (interconnected components) in IoT architectures
Block diagram of coffee pot system with inputs (water, coffee grounds, filter, power), processing unit containing heating element and control logic, and outputs (hot coffee, status indicators, completion signal)
Figure 60.5: Block diagram of a coffee pot system showing inputs (water, coffee, power), processing unit (heating element, control logic), and outputs (hot coffee, indicators)

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.

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

Flowchart of coffee brewing system process: inputs (water, coffee grounds, filter, power, start command) flow through processing stages including heat water to 92-96°C, pump water through grounds, and monitor temperature, producing outputs of hot brewed coffee, status indicator lights, and brewing completion signal.

Coffee brewing system process flow
Figure 60.6: Coffee brewing system diagram showing inputs (water, coffee grounds, filter, power, start command) flowing through processing stages (heat water to 92-96°C, pump through grounds, monitor temperature) to produce outputs (hot coffee, status lights, completion signal)

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

60.7 IoT System Decomposition

⭐⭐ Difficulty: Intermediate

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

Hierarchical graph diagram decomposing an IoT system into three main subsystems: Hardware subsystem (microcontroller, sensors, actuators, power supply), Software subsystem (firmware, device drivers, control logic, communication stack), and Network subsystem (protocol handler, security layer, cloud interface) with bidirectional interaction arrows.

Hierarchical IoT system decomposition diagram
Figure 60.7: Hierarchical decomposition of IoT system showing three main subsystems: Hardware (microcontroller, sensors, actuators, power supply), Software (firmware, device drivers, control logic, communication stack), and Network (protocol handler, security layer, cloud interface) with bidirectional interactions

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

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

Interactive Learning Tools:

  • Simulations Hub - Try the Network Topology Explorer to visualize how processes flow through different system architectures
  • Videos Hub - Watch process control demonstrations showing real systems in action
  • Quizzes Hub - Test your understanding of system decomposition and component interactions

Knowledge Resources:

  • Knowledge Gaps Hub - Common misconceptions about systems vs processes explained
  • Knowledge Map - See how processes & systems connect to sensors, actuators, and architectures

This Series:

Deep Dives:

Foundation:

Sensing & Actuation:

Scenario: Design a IoT-enabled coffee maker with app control, scheduling, and brew strength customization. Decompose into process and system components with quantified performance metrics.

System Requirements:

  • Brew 1-12 cups (150-1800 mL) in 8-15 minutes
  • Maintain water temperature 92-96°C during brew
  • Mobile app control via Wi-Fi
  • Scheduling (wake-up coffee ready at 6:30 AM)
  • Brew strength: weak/medium/strong (water-to-coffee ratios)

System Decomposition:

Hardware Subsystem (Physical Components):

Component Spec Cost Function
Water reservoir 2L capacity, float sensor $8 Store cold water, detect level
Heating element 1200W, 120V AC $12 Heat water to 92-96°C
Temperature sensor NTC 10K thermistor, ±0.5°C $2 Monitor water temperature
Water pump Peristaltic, 150 mL/min $15 Pump heated water through grounds
Grind container 500g capacity with load cell $18 Measure coffee grounds (±1g)
ESP32 microcontroller Dual-core 240 MHz, Wi-Fi $8 Execute control algorithms
Relay board 4-channel, 10A $6 Switch heater, pump, valve
Power supply 12V 3A + 5V 2A $8 Power electronics
Total BOM $77

Software Subsystem (Processes):

Process Algorithm Inputs Outputs Timing
Brew Control State machine (IDLE→HEAT→BREW→KEEP_WARM→DONE) User command, temp, level Heater on/off, pump speed 1 Hz
Temperature PID Kp=15, Ki=0.5, Kd=5 Setpoint 94°C, measured temp Heater duty cycle (0-100%) 2 Hz
Brew Strength Logic Weak=1:18, Med=1:15, Strong=1:12 ratio Selected strength, cup count Pump duration (seconds) Once per brew
Scheduling RTC alarm + delayed start User schedule, current time Brew trigger at scheduled time Event-driven
Wi-Fi Comm MQTT client to AWS IoT App commands, device status Brew status, alerts 5-second heartbeat

Process Flow - “Brew 6 Cups Medium Strength”:

Step-by-Step with Timing:

  1. T=0s - User triggers via app (MQTT message: {"cups": 6, "strength": "medium"})
    • System: IDLE → HEAT state
    • Calculate: 6 cups × 150mL = 900mL water needed
    • Coffee needed: 900mL ÷ 15 (medium ratio) = 60g coffee grounds
    • Check reservoir: Float sensor reads HIGH (>1L available) ✓
    • Check grounds: Load cell reads 180g (>60g available) ✓
  2. T=0-300s - Heating phase
    • Target: Heat 900mL water from 20°C to 94°C
    • Energy needed: 900g × 4.18 J/g°C × 74°C = 278,388 J
    • Heater power: 1200W → Time = 278,388 J ÷ 1200 W = 232 seconds
    • PID controller maintains 94°C (overshoot <1°C, settles in 240s)
    • App status update: “Heating water… 45°C… 68°C… 92°C… Ready!”

Heating time from thermodynamics: \(Q = mc\Delta T\) where mass \(m=900g\), specific heat \(c=4.18 J/(g \cdot °C)\), and temperature rise \(\Delta T = 74°C\). Worked example: Required energy is \(Q = 900 \times 4.18 \times 74 = 278,388J\). With heater power \(P=1200W = 1200 J/s\), heating time is \(t = Q/P = 278,388/1200 = 232s \approx 3.9\) minutes. Upgrading to 1800W would reduce this to \(t = 278,388/1800 = 155s\), a 33% speed improvement.

  1. T=300-480s - Brewing phase
    • Pump activates: 150 mL/min flow rate
    • Total water: 900 mL → Pump time = 900 ÷ 150 = 6 minutes
    • Water flows through 60g grounds in filter basket
    • Temperature maintained at 94±1°C during entire brew (PID active)
  2. T=480-540s - Finalization
    • Pump stops, remaining water drips through (gravity)
    • Heater switches to keep-warm mode (85°C, reduces power to 300W)
    • Load cell confirms 60g grounds consumed (reservoir now 120g)
    • System: BREW → KEEP_WARM state
  3. T=540s - Complete
    • MQTT message: {"status": "complete", "volume": "900mL", "time": "9min"}
    • App notification: “Your coffee is ready!”
    • Keep-warm active for 30 minutes, then auto-shutoff

System Performance Metrics:

Metric Target Achieved Notes
Brew time 10-12 min 9 min Faster due to 1200W heater
Temperature accuracy 92-96°C 94±0.8°C PID controller with thermistor
Brew strength consistency ±5% coffee dose ±1g (±1.7%) Load cell precision
App latency <2 sec 1.2 sec avg MQTT over Wi-Fi
Energy efficiency <0.2 kWh/brew 0.15 kWh Heating (0.09 kWh) + keep-warm (0.06 kWh)
Failure modes detected Reservoir empty, no grounds 100% detected Sensors prevent dry heating

Key Insight: The system (hardware) enables the process (software algorithm). You can simulate the brew process in Python without hardware, but you need the physical system to actually make coffee. System decomposition reveals that the heating element (1200W) is the bottleneck—upgrading to 1800W would reduce brew time to 6.5 minutes but requires 15A circuit instead of 10A.

When to Prioritize Process (Software) Over System (Hardware):

Scenario Reasoning Example
Requirement changes frequently Software updates easier than hardware redesign Brew algorithms (strength, temperature profiles) change based on user feedback
Hardware is commodity Use off-the-shelf components, differentiate with software Generic heating element + thermistor; custom PID tuning
Scaling to high volume Software scales to millions at near-zero marginal cost Mobile app + cloud backend serves 10 or 10M users
Rapid prototyping needed Iterate on algorithms faster than PCB redesigns Test 5 temperature profiles in 1 day vs 4-week PCB fab

When to Prioritize System (Hardware) Over Process (Software):

Scenario Reasoning Example
Performance bottleneck Hardware physics limits (1200W heater = max heat rate) Can’t brew faster without more powerful heater
Cost-sensitive high volume $1 BOM savings = $1M at 1M units Replace ESP32 ($8) with ESP8266 ($3) for basic control
Power constraints Battery life dictated by hardware efficiency Low-power MCU (STM32L) vs high-power (Raspberry Pi) for sensors
Reliability requirements Hardware redundancy needed (dual sensors, backup power) Medical devices, industrial safety systems

Balanced Approach Decision Table:

Design Aspect Process Focus System Focus Balanced
Temperature control PID algorithm tuning (Kp, Ki, Kd) Heater wattage, sensor accuracy Both: Good sensor + tuned PID
Brew strength Coffee-to-water ratio logic Load cell precision, pump flow rate Both: Accurate load cell + calibrated flow
User interface App features (scheduling, notifications) Display hardware (LCD vs OLED) App primary, minimal display
Connectivity Protocol choice (MQTT, HTTP), retry logic Wi-Fi module selection (ESP32 vs CC3200) Reliable module + robust protocol

Quick Decision Test:

  • Can software fix this problem? → Prioritize process (e.g., temperature overshoot → tune PID)
  • Do we need more power/precision? → Prioritize system (e.g., slow heating → upgrade heater)
  • Is this a cost vs feature tradeoff? → Analyze: hardware cost is one-time per unit, software cost is amortized across all units

Real-World Application: Smart thermostats (Nest, Ecobee) differentiate primarily through software (learning algorithms, occupancy detection, scheduling) using commodity hardware (generic temperature sensors, relays). The system (hardware) is “good enough”; the process (software) provides competitive advantage.

Common Mistake: Confusing Process Complexity with System Complexity

The Mistake: Engineers add complex algorithms (processes) to compensate for inadequate hardware (system), or conversely, over-engineer hardware when simple software would suffice.

Example 1 - Process Complexity Masking System Inadequacy:

Scenario: Smart thermostat using a cheap ±2°C accuracy thermistor attempts to maintain ±0.5°C temperature stability through aggressive PID tuning.

What Happens:

  • PID sees “temperature” jump from 21°C to 23°C (actually just ±2°C sensor noise)
  • Controller responds aggressively → turns heater on full blast
  • Actual temperature overshoots to 24°C (real change)
  • Sensor reads 22°C (within ±2°C of 24°C) → PID turns heater off
  • Result: Oscillates between 20-24°C despite sophisticated control algorithm

The Fix: Replace $2 thermistor with $8 DHT22 (±0.5°C accuracy). Simple P-only control (Kp=5) achieves ±0.5°C stability. Lesson: Good hardware makes software easier.

Example 2 - System Over-Engineering When Process Would Suffice:

Scenario: LED dimmer uses expensive 16-bit PWM generator ($12 component) to achieve “ultra-smooth” dimming, but human eye can’t distinguish beyond 8-bit resolution.

What Happens:

  • 16-bit PWM: 65,536 brightness levels (0.0015% steps)
  • Human perception: ~100 distinguishable levels (logarithmic, not linear)
  • 8-bit PWM: 256 levels more than sufficient for smooth perceived dimming
  • Cost waste: $12 component vs $3 component for identical user experience

The Fix: Use 8-bit PWM with gamma correction curve (software):

// 8-bit PWM with perceptual linearity
uint8_t gamma_table[256] = {0, 0, 0, 0, 1, 1, 1, 2, 2, 3, 3, 4, 5, 6, ... , 255};
pwm_value = gamma_table[user_brightness]; // Maps 0-255 input to perceptually linear

Lesson: Smart software compensates for “just adequate” hardware.

Decision Framework:

Problem Process Solution System Solution Right Choice?
Noisy sensor Kalman filter, moving average Higher-precision sensor System (filter can’t remove ±2°C noise)
Slow response Predictive control, feedforward More powerful actuator Depends (if at power limit → system; if control lag → process)
User experience Sophisticated UI, animations Higher-res display Process (good UI on basic display > bad UI on 4K)
Power consumption Duty-cycling, sleep modes Lower-power MCU Both (best results combine both)

Key Principle: Process cannot overcome fundamental system limitations (you can’t extract 0.1°C precision from a ±2°C sensor), but process can maximize system potential (gamma correction makes 8-bit PWM look smooth). Analyze the bottleneck first: is it hardware physics or software logic?

Key Concepts

  • Physical Process: The real-world system being controlled — characterized by its transfer function relating control input to measured output, including time constants, gain, and dead time that determine controllability
  • System Time Constant (τ): The time for a first-order process to reach 63.2% of its final value after a step input — determines minimum achievable closed-loop settling time and constrains maximum control bandwidth
  • Process Gain (Kp): The ratio of steady-state output change to step input change in an open-loop process — determines how aggressively the controller must act to achieve setpoint changes
  • Dead Time (θ): The delay between a control action and when its effect first appears in the measured output — caused by transport delays in pipes, conveyors, or communication networks — the most challenging process characteristic for PID control
  • First-Order Plus Dead Time (FOPDT): The standard simplified process model with three parameters (Kp, τ, θ) sufficient to design PID controllers for most industrial processes using established tuning rules
  • Block Diagram: A graphical control system representation using blocks for subsystems (controller, process, sensor) connected by signal flow arrows, with summing junctions for feedback subtraction

Common Pitfalls

Treating the time delay before any response and the exponential rise time as the same parameter. Dead time (θ) is the pure delay before any response; time constant (τ) describes the exponential rise after delay. PID tuning rules use both independently — FOPDT characterization requires separating them.

Running a step test at one operating point and assuming the identified Kp and τ apply across the full operating range. Most real processes are nonlinear — a valve with equal-percentage characteristic has process gain that varies 10:1 from 0% to 100% opening. Test at multiple operating points.

Calculating process gain from noisy step response data without filtering. A 5% noise-to-signal ratio causes 5% error in identified gain, leading to proportionally incorrect PID gains. Filter the step response data (moving average or low-pass filter) before parameter extraction.

Setting PID gains by intuition without running step tests to characterize the process. The process time constant determines maximum control bandwidth; the dead time determines stability limits. Without these, PID tuning is trial-and-error with risk of instability.

60.8 Summary

This chapter covered the core definitions of processes and systems in IoT:

  • System Definition: Understanding systems as collections of interacting components that transform inputs into outputs with defined boundaries
  • Process Definition: Recognizing processes as series of actions or steps that add value by transforming inputs (materials, energy, information) into outputs
  • Block Diagram Representation: Using abstraction to represent complex IoT systems as interconnected black boxes for analysis at multiple levels
  • Hierarchical Decomposition: Breaking down IoT systems into hardware, software, and network subsystems for modular design and debugging
  • Input-Output Transformations: Analyzing how electronic systems gather information through sensors, process it via microcontrollers, and produce outputs through actuators
  • Design Considerations: Evaluating input validation, process robustness, output verification, error propagation, and resource constraints

Every smart device is a SYSTEM made of parts working together, and every system follows a PROCESS to do its job!

60.8.1 The Sensor Squad Adventure: Building a Weather Station

The Sensor Squad was building a weather station for their school. But they needed to understand how all the pieces fit together!

“Think of it like a SANDWICH!” said Max the Microcontroller. “Every sandwich has INPUTS (the ingredients), a PROCESS (putting it together), and an OUTPUT (the yummy sandwich you eat).”

Sammy the Sensor was excited. “I’m the INPUT! I measure things – like how hot it is, how much it’s raining, and how fast the wind is blowing!”

“And I’m the PROCESS!” said Max. “I take all of Sammy’s measurements and figure out what they mean. Is it going to rain? Is a storm coming? I do the THINKING!”

Lila the LED jumped up. “I’m the OUTPUT! I display the weather on a screen so everyone can see: ‘Sunny today, 24 degrees, light breeze!’ I also send alerts to your phone if a storm is coming!”

Bella the Battery smiled. “And I make sure everyone has the ENERGY to do their job. Without me, the whole system stops!”

“See?” said Max. “Together, we’re a SYSTEM – all the parts working together. My weather prediction algorithm is the PROCESS – the step-by-step recipe I follow. The SYSTEM is everything: Sammy, me, Lila, Bella, the wires, the box we live in – the whole team!”

60.8.2 Key Words for Kids

Word What It Means
System All the parts working together as a team – like a band with different instruments
Process The step-by-step recipe the system follows – like a cooking recipe
Input Information coming IN – what the sensors measure
Output What comes OUT – the display, the alert, the action
Block Diagram A picture that shows how the parts connect – like a map of the system

60.8.3 Try This at Home!

Draw Your Own Block Diagram:

  1. Pick any device in your house (toaster, TV remote, alarm clock)
  2. Draw boxes for: INPUTS (what goes in?) –> PROCESS (what happens inside?) –> OUTPUT (what comes out?)
  3. For example, a TV remote: INPUT = you press a button –> PROCESS = remote sends an infrared signal –> OUTPUT = TV changes channel!

Challenge: Can you draw the block diagram for YOUR school’s fire alarm system? What are the inputs, process, and outputs?

60.9 What’s Next

If you want to… Read this
Learn about control types Control Types
Study PID control implementation PID Control Fundamentals
Explore PID system fundamentals PID Control System Fundamentals
Review processes overview Processes and Systems Overview
Practice with the PID simulation lab PID Simulation Lab