213  Processes & Systems: Core Definitions

213.1 Learning Objectives

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

• Define Process Concepts: Explain systems, processes, and input-output transformations in IoT
• Understand Block Diagrams: Represent complex electronic systems as interconnected components
• Decompose IoT Systems: Break down IoT systems into hardware, software, and network subsystems
• Analyze System Components: Identify inputs, outputs, processes, and constraints in IoT devices
• Apply Hierarchical Design: Use modular decomposition for debugging and optimization

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

213.3 Getting Started (For Beginners)

TipWhat 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

213.3.1 The Kitchen Analogy

NoteUnderstanding 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!

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

NoteKey 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).

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

TipKnowledge Check

Test your understanding of fundamental concepts with these questions.

NoteQuiz 1: Process vs System Definition

Question 1: A smart coffee maker includes a microcontroller, temperature sensor, heating element, water pump, and runs a brewing algorithm. Which statement correctly distinguishes the process from the system?

💡 Explanation: A process is a series of actions or steps that transform inputs into outputs—in this case, the brewing algorithm (heat water → pump through grounds → produce coffee). A system is the complete collection of interacting components (sensors, microcontroller, actuators, software) working together toward a goal. The system executes the process. You can simulate the process logic without hardware, but you need the system to actually brew coffee.

NoteQuiz 2: System Decomposition

Question 2: An IoT-enabled greenhouse monitoring system includes: temperature sensors, humidity sensors, ESP32 microcontroller, Wi-Fi module, relay for fans, cloud database, and mobile app dashboard. Which represents correct hierarchical decomposition?

💡 Explanation: Proper IoT system decomposition follows the Device-Network-Cloud hierarchy. The Device subsystem includes sensing (temperature, humidity sensors), processing (ESP32 MCU), actuation (relay, fans), and power management. The Network subsystem handles communication (Wi-Fi module, protocols). The Cloud subsystem provides storage (database) and user interface (mobile dashboard). This decomposition enables modular design—you can upgrade the cloud platform without changing device hardware, or swap Wi-Fi for LoRaWAN without modifying sensor logic.

InlineKnowledgeCheck = FileAttachment("/assets/js/iotclass-inline-knowledgecheck.js").text().then(text => {
  eval(text);
  return window.InlineKnowledgeCheck;
})

InlineKnowledgeCheck({
  id: "process-scheduling-priority-inversion",
  question: "An IoT gateway runs three processes: **Critical sensor polling** (Priority 1, highest), **Data compression** (Priority 2), and **Network sync** (Priority 3, lowest). The network sync process holds a mutex lock on the network buffer when it gets preempted by the data compression process (Priority 2). The critical sensor process then tries to acquire the same mutex but blocks because the low-priority network sync holds it. Meanwhile, data compression continues running. What problem is occurring?",
  options: [
    "Deadlock - two processes are waiting for each other's resources",
    "Priority inversion - high-priority task blocked by lower-priority task holding shared resource",
    "Race condition - processes accessing shared memory without synchronization",
    "Starvation - low-priority process never gets CPU time"
  ],
  correctIndex: 1,
  explanation: "This is **priority inversion**: The highest-priority sensor process (Priority 1) is blocked waiting for a mutex held by the lowest-priority network sync (Priority 3), while the medium-priority compression (Priority 2) runs freely. Priority inversion occurs when a high-priority task must wait for a low-priority task to release a shared resource, while medium-priority tasks prevent the low-priority task from running. **Solution**: Use **priority inheritance protocol** where network sync temporarily inherits Priority 1 while holding the mutex, allowing it to finish and release the lock quickly. Real-world example: The Mars Pathfinder rover experienced this bug in 1997—high-priority meteorological tasks were delayed by low-priority communication tasks holding shared resources.",
  difficulty: "Intermediate"
})

InlineKnowledgeCheck({
  id: "ipc-message-passing-vs-shared-memory",
  question: "An IoT smart factory controller has two processes: **ProcessA** (sensor data acquisition running at 100Hz) and **ProcessB** (data logging to SD card at 10Hz). They need to exchange 4KB sensor buffers. Which inter-process communication (IPC) mechanism is MOST appropriate?",
  options: [
    "Message passing via named pipes - explicit data copying ensures isolation",
    "Shared memory with mutex protection - high-speed zero-copy data transfer",
    "Socket communication over localhost - standardized TCP/IP protocol",
    "File-based IPC - write sensor data to temporary files that logger reads"
  ],
  correctIndex: 1,
  explanation: "**Shared memory with mutex** is optimal here: ProcessA writes 4KB buffers to shared memory region, ProcessB reads when ready. **Why shared memory wins**: (1) **Zero-copy**: 4KB×100Hz = 400KB/s data rate—copying overhead via message passing would waste 10-20% CPU cycles; shared memory avoids copying. (2) **Speed**: Shared memory is 5-10× faster than message passing for large buffers. (3) **Bandwidth**: High-frequency sensor acquisition (100Hz) needs minimal latency. **Mutex is critical**: Protects against race conditions where ProcessA writes while ProcessB reads corrupted partial data. **When to use alternatives**: Message passing is better for small, infrequent messages (better isolation, simpler code). Sockets add unnecessary network stack overhead for local communication. File-based IPC is slowest due to filesystem overhead. **Real IoT example**: Linux shared memory (`shmget/mmap`) is standard for high-bandwidth sensor pipelines in robotics and industrial automation.",
  difficulty: "Intermediate"
})

213.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 diagram

Figure 213.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:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TD
    START([System Receives<br/>Input Signal]) --> SENSE[Sensor Layer<br/>Measure physical value]

    SENSE --> CONVERT{Valid<br/>Reading?}

    CONVERT -->|Yes| PROCESS[Processing Layer<br/>Execute algorithm]
    CONVERT -->|No/Error| RETRY[Retry or<br/>Use default]
    RETRY --> SENSE

    PROCESS --> DECIDE{Output<br/>Required?}

    DECIDE -->|Yes| ACTUATE[Actuation Layer<br/>Drive output device]
    DECIDE -->|No change needed| WAIT[Wait for<br/>next cycle]

    ACTUATE --> FEEDBACK{Closed-Loop<br/>System?}

    FEEDBACK -->|Yes| MEASURE[Measure Output<br/>Compare to setpoint]
    FEEDBACK -->|No| COMPLETE([Cycle Complete])

    MEASURE --> ADJUST{Error<br/>Acceptable?}

    ADJUST -->|No| PROCESS
    ADJUST -->|Yes| COMPLETE

    WAIT --> START

    style START fill:#16A085,color:#fff
    style SENSE fill:#2C3E50,color:#fff
    style PROCESS fill:#2C3E50,color:#fff
    style ACTUATE fill:#E67E22,color:#fff
    style COMPLETE fill:#16A085,color:#fff
    style MEASURE fill:#7F8C8D,color:#fff

Figure 213.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.

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph Physical["Physical Layer"]
        direction LR
        ENV[Environment<br/>Temperature, Motion, Light]
        ACT[Physical Actions<br/>Movement, Heat, Sound]
    end

    subgraph Sensing["Sensing Layer"]
        direction LR
        SENS[Sensors<br/>Convert physical to electrical]
        TRANS[Transducers<br/>Signal conditioning]
    end

    subgraph Processing["Processing Layer"]
        direction LR
        ADC[ADC<br/>Analog to Digital]
        MCU[Microcontroller<br/>Algorithm execution]
        DAC[DAC<br/>Digital to Analog]
    end

    subgraph Control["Control Layer"]
        direction LR
        LOGIC[Control Logic<br/>Decision making]
        STATE[State Machine<br/>Mode management]
    end

    subgraph Actuation["Actuation Layer"]
        direction LR
        DRV[Drivers<br/>Power amplification]
        ACTS[Actuators<br/>Motors, valves, heaters]
    end

    ENV --> SENS
    SENS --> TRANS
    TRANS --> ADC
    ADC --> MCU
    MCU --> LOGIC
    LOGIC --> STATE
    STATE --> DAC
    DAC --> DRV
    DRV --> ACTS
    ACTS --> ACT
    ACT -.->|Feedback| ENV

    style Physical fill:#7F8C8D,color:#fff
    style Sensing fill:#16A085,color:#fff
    style Processing fill:#2C3E50,color:#fff
    style Control fill:#E67E22,color:#fff
    style Actuation fill:#16A085,color:#fff

Figure 213.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

213.6 Block Diagram Representation

⭐ Difficulty: Foundational

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

Figure 213.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.

NoteExample: Coffee Pot System

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

Flowchart diagram

Figure 213.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

213.7 IoT System Decomposition

⭐⭐ Difficulty: Intermediate

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

Graph diagram

Figure 213.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

InlineKnowledgeCheck({
  id: "process-synchronization-semaphores",
  question: "A smart home hub runs three processes that share a sensor data buffer (max 10 entries): **Producer1** (temperature sensor - writes data), **Producer2** (humidity sensor - writes data), and **Consumer** (data logger - reads data). Which semaphore configuration correctly prevents race conditions and buffer overflow/underflow?",
  options: [
    "One binary semaphore (mutex) protecting buffer access",
    "Two counting semaphores: empty_slots=10 (tracks available space), full_slots=0 (tracks available data), plus one mutex for buffer access",
    "Two binary semaphores: one for producers, one for consumer",
    "No semaphores needed - use busy-waiting with a flag variable"
  ],
  correctIndex: 1,
  explanation: "This classic **producer-consumer problem** requires **two counting semaphores + one mutex**: (1) **empty_slots semaphore** (initialized to 10): Producers must `wait(empty_slots)` before writing—blocks when buffer full. After writing, `signal(full_slots)` to notify consumer. (2) **full_slots semaphore** (initialized to 0): Consumer must `wait(full_slots)` before reading—blocks when buffer empty. After reading, `signal(empty_slots)` to free space. (3) **mutex** (binary semaphore): Protects actual buffer manipulation—prevents Producer1 and Producer2 from writing to same slot simultaneously. **Why single mutex fails**: Doesn't prevent buffer overflow (producers write when full) or underflow (consumer reads when empty). **Why binary semaphores fail**: Can't count available slots/data—only signal occupied or free. **Why busy-waiting fails**: Wastes CPU cycles and still has race conditions without atomic operations. **Real IoT example**: FreeRTOS uses `xQueueSend/xQueueReceive` which implement this pattern internally for inter-task communication.",
  difficulty: "Advanced"
})

InlineKnowledgeCheck({
  id: "deadlock-prevention-banker-algorithm",
  question: "An IoT edge server runs three processes competing for two resources: **UART1 port** (1 instance) and **I2C bus** (1 instance). Process A holds UART1 and requests I2C. Process B holds I2C and requests UART1. Process C is waiting for either resource. What deadlock prevention strategy is MOST practical for resource-constrained IoT systems?",
  options: [
    "Resource ordering - always acquire UART1 before I2C to prevent circular wait",
    "Banker's algorithm - dynamically check if resource allocation leaves system in safe state",
    "Timeout-based deadlock detection - if lock acquisition times out, release all held resources and retry",
    "Resource preemption - forcefully take resources from lower-priority processes"
  ],
  correctIndex: 0,
  explanation: "**Resource ordering** (Option A) is best for IoT: Enforce a global acquisition order (e.g., always acquire UART1 before I2C). This breaks **circular wait** (one of four deadlock conditions), preventing deadlock entirely with minimal overhead. **Why banker's algorithm is impractical**: Requires advance knowledge of maximum resource needs and complex runtime calculations—too CPU/memory-intensive for microcontrollers. **Why timeouts work but are suboptimal**: Detects deadlock after it occurs (not prevention), causes wasted work retrying, and requires careful timeout tuning (too short = false positives, too long = long delays). **Why preemption is problematic**: Resources like UART/I2C are **non-preemptible**—you can't safely take them mid-transaction without corrupting communication. **Implementation**: Define acquisition order in coding standards: `#define RESOURCE_ORDER 1:UART, 2:I2C`. Any code needing both must acquire in this order. **Real example**: Linux kernel uses lock ordering to prevent deadlock (see `include/linux/lockdep.h`).",
  difficulty: "Advanced"
})

WarningDesign 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

TipCross-Hub Connections

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

NoteRelated Chapters

This Series: - Processes & Systems: Control Types - Open-loop vs closed-loop control - Processes & Systems: PID Control - PID controller theory and applications

Deep Dives: - Process Control and PID - Advanced feedback control systems - Processes Labs and Review - Hands-on implementations

Foundation: - IoT Reference Models - System architecture layers - Architectural Enablers - IoT technology stack

Sensing & Actuation: - Sensor Fundamentals - Input devices - Actuators - Output devices

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

213.9 What’s Next

The next chapter explores Control Types: Open-Loop vs Closed-Loop, introducing the fundamental distinction between systems that operate without feedback and those that continuously measure and adjust based on output. You’ll learn how feedback mechanisms enable systems to self-regulate and maintain desired behaviors automatically.