%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
gantt
title Response Timeline: Local vs Cloud Control
dateFormat X
axisFormat %s sec
section Fish Emergency
DO drops below 5 mg/L :milestone, e1, 0, 0
section Arch A: Local
Sensor reads (local) :a1, 0, 1
PID calculates :a2, after a1, 1
Pump activates :crit, a3, after a2, 1
Fish safe :milestone, safe_a, after a3, 0
section Arch B: Cloud
Wait for sample window :b0, 0, 30
LoRa uplink :b1, after b0, 2
Cloud processing :b2, after b1, 1
LoRa downlink :b3, after b2, 2
Pump activates :crit, b4, after b3, 1
Fish status? :milestone, status_b, after b4, 0
228 Control Systems Understanding Checks
228.1 Learning Objectives
By the end of this chapter, you will be able to:
- Apply Control Concepts: Use process vs. system thinking for real IoT products
- Evaluate Open vs. Closed-Loop: Choose appropriate control architectures based on requirements
- Analyze PID Behavior: Predict controller response in various scenarios
- Design Distributed Feedback: Architect reliable control systems for critical applications
- Calculate ROI: Quantify the business value of closed-loop control investments
228.2 Prerequisites
Required Chapters: - PID Control Simulation Lab - Hands-on PID experience - Processes and Systems - Control theory fundamentals
Estimated Time: 45 minutes
TipFor Beginners: How to Use Understanding Checks
What are Understanding Checks? Scenario-based exercises that test whether you can apply control system concepts to real-world situations.
Why are they important? - Bridge theory to practice - Reveal common misconceptions - Build engineering intuition - Prepare for real-world design decisions
How to use: 1. Read each scenario carefully 2. Think through the problem BEFORE expanding the answer 3. Compare your reasoning with the solution 4. Note any gaps in understanding
228.3 Understanding Checks
Test your understanding of processes, systems, and PID control through real-world scenarios:
TipUnderstanding Check: Process vs System Architecture
Scenario: Your startup is building a smart thermostat. The technical lead says, “We need to separate our process logic from our system architecture,” but the team is confused about what this means in practice.
Your $500,000 production run depends on understanding this distinction:
System Components (Hardware + Software): - ESP32 microcontroller ($8) - DHT22 temperature sensor ($3) - Relay for heater control ($2) - LCD display ($5) - Wi-Fi radio (built-in) - Power supply ($4) - Enclosure ($3) - Total BOM: $25/unit
Process (Temperature Control Algorithm): - Read temperature every 10 seconds - Compare to setpoint (22°C) - Calculate PID control output - Activate heater if output > threshold - Update display and cloud - This code runs ON the system
Think about: 1. Modularity: Can you swap the DHT22 sensor for a BME280 without changing the process logic? 2. Testing: Can you test the PID algorithm in simulation before building hardware? 3. Scalability: What changes when you deploy 10,000 units vs. 1 prototype?
Key Insight: The system is the physical embodiment (all the hardware and software components working together). The process is the logical flow of operations (the algorithm that transforms sensor readings into control actions). You can simulate the process without the system, but you need the system to deploy the process.
Verify Your Understanding: - If the relay fails (system problem), does the PID algorithm need to change (process logic)? No—same logic, different actuator - If you want to add anti-windup to the PID controller (process change), do you need new hardware (system change)? No—code update only
TipUnderstanding Check: Open-Loop Economics
Scenario: An agricultural co-op serves 50 farms with irrigation systems. They debate two approaches:
Open-Loop System (Current): - Timer-based: Water 10 minutes every morning at 6 AM - No soil moisture sensors - Equipment cost: $500/farm (just timer and valves) - Water consumption: 500 gallons/day per farm = 25,000 gallons/day total - Annual water cost: 25,000 gal/day × 365 days × $0.004/gal = $36,500/year - Crop issues: 30% of farms report over-watering, 20% report under-watering - Yield loss: ~15% average due to suboptimal watering
Closed-Loop System (Proposed): - Soil moisture sensor triggers irrigation only when moisture < 25% - Equipment cost: $1,200/farm (sensor + controller + valves) - Water consumption: 180 gallons/day per farm = 9,000 gallons/day total (64% reduction) - Annual water cost: 9,000 gal/day × 365 days × $0.004/gal = $13,140/year - Crop improvements: 15% yield increase from optimal watering - Additional capital: 50 farms × $700 upgrade = $35,000 one-time
Think about: 1. Payback period: Water savings: $36,500 - $13,140 = $23,360/year. Upgrade cost: $35,000. Payback in 1.5 seasons 2. Hidden costs: Open-loop wastes 16,000 gallons/day. At 30 farms over-watering, what’s the erosion/runoff damage cost? 3. Adaptation: When a heat wave hits (soil dries faster), open-loop keeps watering 10 min/day. Closed-loop increases frequency automatically
Key Insight: Open-loop systems are only “cheaper” if you ignore operational costs. The $700 per farm for feedback sensors pays for itself in 18 months through water savings alone—before considering yield improvements ($15K/farm value) and reduced crop loss.
Verify Your Understanding: - If it rains heavily overnight (2” rainfall), what does open-loop do at 6 AM? Still waters for 10 minutes (wastes 500 gallons) - What does closed-loop do? Measures 95% soil moisture, skips irrigation (saves 500 gallons)
TipUnderstanding Check: Derivative Control in High-Inertia Systems
Scenario: Your smart oven is heating up to 180°C for baking. At t=60s, temperature reaches 160°C and is rising at 5°C/second. The system has 20 seconds of thermal inertia (heat stored in walls continues affecting temperature even after heater turns off).
PID Configuration Test:
Controller A (P-only: Kp=2.0, Ki=0, Kd=0): - Error at t=60s: 180 - 160 = 20°C - P output: 2.0 × 20 = 40% heater power - Result at t=65s: Temperature reaches 182°C (overshoots by 2°C) due to stored thermal energy - Oscillation: System bounces 178-182°C for 2 minutes before settling - Baking quality: Uneven (temperature swings)
Controller B (PI: Kp=2.0, Ki=0.5, Kd=0): - Error at t=60s: 20°C - P output: 40%, I output: 8% (accumulated error) - Total: 48% heater power - Result at t=65s: Temperature reaches 185°C (even worse overshoot!) - Integral term added more heat during approach, amplifying overshoot - Settling time: 3 minutes
Controller C (PID: Kp=2.0, Ki=0.5, Kd=1.0): - Error at t=60s: 20°C (decreasing from 40°C at t=58s) - P output: 40% - I output: 8% - D output: 1.0 × (20-40)/(60-58) = 1.0 × (-10) = -10% (braking!) - Total: 40 + 8 - 10 = 38% heater power (vs 48% for PI) - Result at t=65s: Temperature reaches 180.5°C (only 0.5°C overshoot) - Settling time: 45 seconds
Think about: 1. Why D matters here: The 20-second thermal inertia means oven continues heating after heater turns off. D term “sees” the rapid approach and applies predictive braking 2. Cost of overshoot: Professional baking requires ±1°C accuracy. 2°C swings ruin soufflés, bread crusts, and pastries 3. When to skip D: High-frequency noise (e.g., boiling water with bubbles) causes D term to oscillate wildly. Use D only for smooth, high-inertia processes
Key Insight: Derivative control is essential for high-inertia systems where momentum carries the process past the setpoint. The faster the approach rate and the higher the inertia, the more critical D becomes. Without it, you’re flying blind into the target.
Verify Your Understanding: - At 170°C rising at 3°C/s, what does D=1.0 output? Error decreasing at -3°C/s → D = 1.0 × (-3) = -3% braking power - Why doesn’t P term provide braking? P only responds to current error magnitude (10°C), not rate of change—it doesn’t “know” you’re approaching fast
TipUnderstanding Check: Steady-State Error Elimination
Scenario: You’re deploying 100 smart aquarium heaters for a commercial fish breeding facility. Each tank must maintain precisely 25.0°C ±0.2°C. Your P-only controller (Kp=3.0) stabilizes at 24.3°C, leaving a persistent 0.7°C steady-state error.
The facility manager says: “Just increase Kp to 10.0—stronger proportional gain will close that 0.7°C gap!”
Let’s analyze three options:
Option A (Increase Kp: 3.0 → 10.0): - At equilibrium (24.3°C): Error = 0.7°C - P output (Kp=3.0): 3.0 × 0.7 = 2.1% heater power → maintains 24.3°C - P output (Kp=10.0): 10.0 × 0.7 = 7.0% heater power → new equilibrium at 24.7°C - Result: Steady-state error reduced from 0.7°C to 0.3°C, but not eliminated - Problem: Now system oscillates ±1.2°C around 24.7°C (too aggressive Kp causes overshoot) - Cost: $0 (software change), but fish stress from oscillations costs $5K/year in losses
Option B (Add Integral Control: PI with Kp=3.0, Ki=0.1): - At 24.3°C: Error = 0.7°C persists - Integral accumulates: ∫0.7 dt = 0.7 × 60s = 42 cm·s after 1 minute - I output after 60s: 0.1 × 42 = 4.2% additional heater power - Integral keeps growing until error = 0 - Result: System reaches exactly 25.0°C in ~90 seconds, stays there - Minor overshoot: 25.2°C briefly, then settles - Cost: $0 (software change), fish thrive at stable temperature
Option C (Add Derivative: PD with Kp=3.0, Kd=1.0): - At steady state (24.3°C): Error constant (de/dt = 0) - D output: 1.0 × 0 = 0% (contributes nothing!) - P output: 3.0 × 0.7 = 2.1% heater power - Result: Still stuck at 24.3°C—derivative doesn’t help steady-state error - D only helps during transients (approach phase), not at equilibrium
Think about: 1. Why P-only fails: At 24.3°C, the 2.1% heater output exactly balances heat losses. To reach 25.0°C requires more power, but smaller error means smaller P output—a catch-22 2. Integral’s superpower: Accumulates even tiny persistent errors into large outputs. Error of 0.7°C for 1 minute = 42 cm·s → forces system to overcome the equilibrium trap 3. Industry standard: 95% of commercial PID controllers use PI (not PID) because most processes don’t need D, but all need I for zero steady-state error
Key Insight: Proportional control can only reduce steady-state error, never eliminate it. The fundamental limitation: when error decreases, proportional output decreases, so system settles below setpoint. Integral control breaks this cycle by accumulating persistent error into ever-increasing output until error = 0.
Verify Your Understanding: - At 24.8°C (error = 0.2°C), why doesn’t Kp=10.0 reach 25.0°C? P output = 10.0 × 0.2 = 2.0% is insufficient to overcome heat losses—system re-equilibrates below setpoint - How long does integral need to accumulate 0.2°C error to generate 2% additional output if Ki=0.1? I = Ki × ∫error·dt → 2.0 = 0.1 × (0.2 × t) → t = 100 seconds
TipUnderstanding Check: Distributed Feedback Architecture
Scenario: A commercial fish farm spans 50 ponds with dissolved oxygen (DO) monitoring. When DO drops below 5 mg/L, fish begin to die within 15 minutes. The engineering team debates two control architectures:
Architecture A (Distributed Control - Closed-Loop): - Each pond: DO sensor + local controller + aeration pump (all at pond) - Local PID controller runs on ESP32 at 1 Hz - Setpoint: 5 mg/L (turns on pump when DO < 5) - Response time: <2 seconds (sensor → controller → pump, all local) - Network dependency: None (operates without internet) - Cost per pond: $350 (sensor $80, ESP32 $15, pump $200, enclosure $55) - Total system: 50 × $350 = $17,500 - Reliability: If cloud/network fails, all 50 ponds continue operating autonomously
Architecture B (Cloud Control - Distributed Closed-Loop): - Each pond: DO sensor only ($80) - Sensors transmit readings to AWS IoT Core every 30 seconds - Cloud Lambda function evaluates DO < 5 mg/L threshold - Cloud sends actuation command back to pond’s actuator node - Actuator node activates pump - Response time: 10-45 seconds (sensor → cloud → actuator, plus 30s sampling interval) - Latency breakdown: - Sensor reading: 30s (worst case—just missed the 30s sampling window) - LoRaWAN uplink: 2s - Cloud processing: 0.5s - LoRaWAN downlink: 2s - Actuator response: 1s - Total worst case: 35.5 seconds - Network dependency: If internet/LoRaWAN fails, pumps don’t activate (fish die) - Cost: Sensors $4,000 + actuators $10,000 + 10 LoRaWAN gateways $3,000 + cloud $500/year = $17,500 initial + $500/year - Benefit: Centralized dashboards, historical analytics, ML-based predictions
Real-World Incident (Architecture B): - Month 3: Internet outage (ISP fiber cut) for 4 hours - Pond #23 DO drops to 3.2 mg/L (sensors detect, but can’t reach cloud) - Pumps never activate (waiting for cloud command that never arrives) - 2,500 fish (worth $15,000) die from hypoxia - Total loss: $15,000 fish + $8,000 reputation/customer trust
Think about: 1. Latency tolerance: Can fish survive 35-second response delay? (Borderline—DO crashes can be rapid) 2. Single point of failure: Cloud architecture centralizes intelligence, creating catastrophic failure mode 3. Cost of failure: $15K fish loss >> $350 local controller. Why optimize for cheapness on critical control loops?
Hybrid Architecture C (Best of Both): - Local closed-loop control: Each pond has sensor + ESP32 + pump (autonomous, <2s response) - Cloud telemetry: ESP32 reports DO readings to cloud (monitoring, alerts, analytics) - Autonomy: If cloud fails, local loops continue operating - Intelligence: Cloud provides dashboard, trend analysis, predictive alerts (“Pond #12 DO declining faster than normal—check aerator”) - Cost: $17,500 (same as others) + $200/year cloud (lower traffic—telemetry only, not control)
Key Insight: Distributed IoT systems can have closed-loop feedback at the system level, but architectural decisions determine reliability. Architecture B is technically closed-loop (sensor → cloud → actuator → environment → sensor), but the distributed nature introduces latency and failure modes unacceptable for critical control. For life-safety applications, close the loop locally and use cloud for monitoring/analytics.
Verify Your Understanding: - Is Architecture B closed-loop or open-loop? Closed-loop—feedback path exists from sensor through cloud to actuator back to environment. But it’s a fragile closed-loop. - Why can’t you “just add a timeout” to Architecture B? Timeout would trigger false alarms every internet hiccup. Real solution: local autonomy.
228.4 Summary
This chapter tested your understanding of control system concepts through real-world scenarios:
Key Concepts Reinforced:
- Process vs. System Separation
- System = physical hardware + software components
- Process = logical algorithm running on the system
- Separation enables modularity, testing, and scalability
- Open-Loop Economics
- Open-loop only “cheaper” when ignoring operational costs
- Closed-loop often pays for itself in 12-18 months
- Adaptation to disturbances justifies sensor investment
- Derivative Control Purpose
- Essential for high-inertia systems
- Provides predictive “braking” to prevent overshoot
- Skip for noisy or low-inertia processes
- Integral for Steady-State
- Only integral term can eliminate steady-state error
- Proportional can reduce but never eliminate offset
- PI is the most common industrial configuration
- Distributed Architecture Trade-offs
- Local loops for critical/life-safety control
- Cloud for monitoring, analytics, dashboards
- Hybrid gives autonomy + intelligence
Next Step: Apply these concepts using the decision frameworks in the next chapter.
NoteRelated Chapters
Prerequisites: - PID Control Simulation Lab - Hands-on PID experience - Processes and Systems - Control theory fundamentals
Continue Learning: - Decision Guidance - Practical decision frameworks - Edge Compute Patterns - Processing at the edge
228.5 What’s Next?
Now that you’ve tested your understanding with real-world scenarios, continue to the decision guidance chapter for practical frameworks you can apply to your own IoT control system designs.