Internet of Things (CE-703 (A)) - Unit 3 Short Notes

UNIT 3: Internet of Things (CE-703 A) - Short Notes

I. IoT Fundamentals & Architectural Frameworks

IoT Definition & Core Concepts

• IoT (Internet of Things): A network of physical objects ("things") embedded with sensors, software, and connectivity to collect and exchange data over the Internet.

• Role of "Things": Any physical object (sensor, actuator, device) that can be assigned an IP address and provided with the ability to transfer data over a network.

• Role of the Internet: Provides global connectivity, standard protocols (IP), and cloud infrastructure for data aggregation, processing, and access.

• IoT Analytics: The process of analyzing the vast volumes of data generated by IoT devices to extract meaningful insights, enable real-time decisions, and predict future events. Its scope includes descriptive, diagnostic, predictive, and prescriptive analytics.

IoT Ecosystem

A complex system comprising:

1. Things/Devices: Sensors, actuators, embedded systems.

2. Connectivity/Gateways: Networks (LPWAN, WLAN), gateways for protocol translation and edge processing.

3. Platform/Cloud: Data ingestion, storage, management, and application enablement platforms.

4. Analytics & Applications: Data processing engines and end-user applications (dashboards, alerts, controls).

5. Business & Users: Stakeholders, business models, and end-consumers.

IoT Architectural Frameworks & Models

• IoT Reference Architectures (e.g., IoT-A): Standardized blueprints defining components, interfaces, and interactions. Examples: IoT-A (European), Cisco IoT, IBM IoT.

• Layered Models: Common 3-5 layer models:

  • Perception Layer: Physical sensors/actuators for data acquisition.

  • Network Layer: Data transmission via wired/wireless networks (Wi-Fi, ZigBee, cellular).

  • Middleware/Service Layer: Protocol translation, data management, service discovery.

  • Application Layer: Domain-specific applications (smart home, health).

  • Business Layer: Business models, policies, user management.

• Information Models: Standardized ways to describe the capabilities, data, and semantics of IoT devices (e.g., using OCF, oneM2M specs) to enable interoperability.

• IoT Planes:

  • Device Plane: Physical devices and local networks.

  • Network Plane: Communication infrastructure.

  • Application Plane: Cloud services and user apps.

  • Interdependencies: Device plane data flows through network plane to application plane; application plane commands flow back.

• IoT Enablers: Technologies (RFID, NFC, WSN), standards (IEEE 802.15.4, CoAP), platforms (AWS IoT, Azure IoT), and protocols that make IoT feasible.

• IoT Service-Oriented Architecture (SOA): Treats device functions as discoverable services. Challenges: Resource constraints of devices, service discovery in dynamic networks, security of service interfaces.

• IoT Levels/Stages:

  | Level | Description | Example | | :--- | :--- | :--- | | Level 1 | Single device, no connectivity. | Standalone thermostat. | | Level 2 | Device with connectivity (device-to-cloud). | Smart bulb connected to vendor cloud. | | Level 3 | Local network of devices (device-to-device + gateway). | Home automation system with hub. | | Level 4 | Global, interoperable system of systems. | Smart city with cross-vendor integration. |

  [!TIP] Exam Focus: Level 3 is proprietary/local (e.g., ZigBee network), Level 4 is open/global (e.g., using 6LoWPAN/IPv6 for internet-scale).

Communication Models

1. Device-to-Device (D2D): Direct communication between things (e.g., Bluetooth, ZigBee).

2. Device-to-Cloud (D2C): Device sends data directly to cloud server (e.g., Wi-Fi to HTTP server).

3. Device-to-Gateway (D2G): Device connects to a local gateway which then communicates with cloud (common for constrained devices).

4. Backend-to-Device (B2D): Cloud sends commands/updates to devices.

DiagramCANVAS: Block diagram showing the four models with arrows between Devices, Gateway, Cloud, and Backend.

Building Blocks of IoT

• Sensors/Actuators (Perception)

• Microcontrollers/MPUs (Processing)

• Communication Modules (Connectivity: Wi-Fi, BLE, LoRa)

• Power Sources (Batteries, energy harvesting)

• Software/Firmware (Drivers, OS, protocols)

II. M2M vs. IoT

Machine-to-Machine (M2M) Communication

• Definition: Direct communication between machines/ devices without human intervention, typically using point-to-point or proprietary networks (e.g., SCADA, telemetry).

• M2M Service Layer Standardization: Efforts by standards bodies (e.g., ETSI, oneM2M) to define a common service layer (middleware) for M2M to enable interoperability across verticals.

Evolution from M2M to IoT

• Key Reasons for Shift:

  1. Scalability: IoT uses IP, enabling massive device counts vs. limited M2M connections.

  2. Interoperability: IoT aims for cross-vendor, cross-domain communication; M2M is often siloed.

  3. Data & Analytics: IoT focuses on big data from diverse sources; M2M data is often for specific control/monitoring.

  4. Architecture: IoT leverages cloud/edge computing; M2M is more centralized.

  5. Internet-Centric: IoT inherently uses Internet protocols; M2M may use private networks.

• Fundamental Differences:

  | Feature | M2M | IoT | | :--- | :--- | :--- | | Connectivity | Point-to-point, proprietary | IP-based, networked | | Scale | Limited, vertical-specific | Massive, horizontal | | Data Focus | Machine data for control | Human & machine data for insights | | Architecture | Siloed, centralized | Cloud/edge, service-oriented | | Interoperability | Low (vendor-specific) | High (standard protocols) |

• Data Analytics Approaches:

  • M2M: Primarily descriptive (what is happening?) and real-time control. Data volume is lower, analysis is often at the edge/central server for immediate operational decisions.

  • IoT: Predictive & Prescriptive analytics. Large-scale historical and real-time data aggregation in cloud for trend analysis, machine learning, and automated decision-making across systems.

III. Sensors and Actuators

Sensors in IoT

• Types:

  • By Measurand: Temperature, pressure, humidity, motion (PIR), image (camera), gas (MQ-series), sound, proximity.

  • By Output: Analog (voltage/current), Digital (I2C, SPI, UART).

• Features & Characteristics:

  • Accuracy, Precision, Resolution, Range, Sensitivity, Response Time, Drift, Hysteresis.

  • Power Consumption, Size, Cost, Robustness.

• Comparison of Common IoT Sensors:

  | Sensor | Measurand | Interface | Typical Use | | :--- | :--- | :--- | :--- | | DHT22 | Temp & Humidity | Digital (1-Wire) | Weather stations, HVAC | | MQ-2 | Gas (LPG, Smoke) | Analog | Leak detection, air quality | | PIR (HC-SR501) | Motion | Digital | Security, occupancy detection | | Ultrasonic (HC-SR04) | Distance | Digital | Level sensing, proximity | | BMP280 | Pressure, Temp | I2C/SPI | Altitude, weather |

• Most Used Types: Temperature, humidity, motion (PIR), gas (MQ-series), proximity/ultrasonic.

• Quantization Error: Error introduced when converting analog signal to digital. The smallest change undetectable due to finite resolution.

$$Q_e = \frac{V_{fs}}{2^n}$$

Where $$\displaystyle V_{fs} $$ = full-scale voltage range, $n$ = number of bits. \boxed{Q_e = \frac{V_{fs}}{2^n}}

Actuators in IoT

• Role: Convert electrical/electronic control signals into physical action (motion, force, heat). They are the "effectors" of an IoT system.

• Types:

  1. Mechanical Actuators: Motors (DC, stepper, servo), solenoids, relays. Convert electrical to linear/rotary motion.

  2. Soft Actuators: Made of flexible materials (silicone, elastomers). Used in robotics for safe human interaction.

  3. Shape Memory Polymer (SMP) Based: Change shape upon external stimulus (heat, light). Used in biomedical devices, deployable structures.

  4. Pneumatic Actuators: Use compressed air to produce motion (cylinders, grippers). Fast, clean, high force-to-weight ratio.

• Four Common Selection Characteristics:

  1. Type of Motion/Force: Linear vs. rotary, force/torque required.

  2. Power Source & Consumption: Electrical (voltage/current), pneumatic, hydraulic; energy efficiency.

  3. Control Precision & Response Time: Position/velocity control accuracy, speed of actuation.

  4. Environment & Durability: Operating temperature, humidity, exposure to chemicals, shock/vibration resistance.

Microcontrollers & Interfacing

• Review of Basic Microcontrollers: Integrated circuits with CPU, memory (RAM/ROM), and I/O peripherals (GPIO, ADC, UART, SPI, I2C). Examples: Arduino (ATmega328), ESP32/8266 (Wi-Fi/Bluetooth), STM32 (ARM Cortex-M).

• Interfacing Concepts: Connecting sensors/actuators to MCUs using communication protocols (digital/analog).

• Raspberry Pi:

  • Comparison with Desktop: Pi is a single-board computer (SBC) with lower power consumption, no internal storage (uses SD card), ARM architecture (vs. x86), designed for embedded/educational use, not high-performance computing.

  • SPI (Serial Peripheral Interface): Synchronous, full-duplex, 4-wire (MOSI, MISO, SCLK, CS). Fast, master-centric. Used for displays, high-speed sensors.

  • I2C (Inter-Integrated Circuit): Synchronous, half-duplex, 2-wire (SDA, SCL). Multi-master/multi-slave, address-based. Used for low-speed peripherals (EEPROM, sensors).

  • GPIO (General Purpose Input/Output): Software-configurable pins for digital read/write (0/3.3V). Used for buttons, LEDs, simple sensor control.

IV. Identification & Positioning Technologies

Radio Frequency Identification (RFID)

• Principles: Uses electromagnetic fields to automatically identify and track tags attached to objects. Tags (passive/active/battery-assisted) store data; Reader emits radio waves and receives tag response.

• Concepts & Terminology:

  • Tag: Transponder with chip & antenna.

  • Reader/Interrogator: Transmitter/receiver.

  • Frequency Bands: LF (125-134 kHz), HF (13.56 MHz), UHF (860-960 MHz), Microwave (2.45 GHz).

  • Coupling: Inductive (LF/HF), Radiative (UHF/microwave).

  • Read Range: Passive (cm to m), Active (up to 100m).

• RFID Features: Non-line-of-sight reading, high durability, fast bulk reading, unique ID, real-time tracking.

• RFID & IoT for "Smart Things": RFID provides automatic identification and data capture (AIDC). When combined with IoT, it turns passive objects into "smart" assets by linking their unique ID to online data (location, status, history) via a gateway/cloud.

• Link to IoT Implementation: RFID tags act as the "sensory layer" for physical objects. Reader data is fed into IoT platforms for inventory management, supply chain visibility, access control—forming the perception layer of IoT.

Near Field Communication (NFC)

• Definition & Technologies: Short-range (≤ 10 cm), high-frequency (13.56 MHz) wireless technology. Based on RFID standards (ISO/IEC 14443, 18092). Enables two-way communication.

• Applications:

  • Contactless payments (Google Pay, Apple Pay).

  • Access control (smart locks, badges).

  • Data exchange (sharing contacts, URLs).

  • Device pairing (Bluetooth/Wi-Fi handover).

  • IoT: Smart posters, configuration of IoT devices (tap-to-pair).

V. Networking Technologies & Standards

Wireless Sensor Networks (WSN)

• Concepts: Self-configuring network of spatially distributed autonomous sensors to monitor physical/environmental conditions. Relation to IoT: WSN is a key enabling technology for the perception layer of IoT. IoT often builds upon WSN infrastructure but extends it with Internet connectivity and cloud integration.

• Example: A WSN of temperature/humidity sensors in a farm (nodes talk to each other) feeds data to an IoT platform for precision agriculture analytics.

• Applications: Environmental monitoring, structural health, smart agriculture, military surveillance, health monitoring.

Network Classification

• Based on Physical Topologies:

  • Bus: Single cable, all nodes share. Simple, but single point of failure.

  • Star: All nodes connect to central hub/switch. Easy to manage, hub failure breaks network.

  • Ring: Nodes in closed loop. Token passing, predictable performance.

  • Mesh: Nodes interconnect with multiple neighbors. High reliability, self-healing, used in WSN (ZigBee, 6LoWPAN).

  • Tree/Hybrid: Combination of star/bus.

  DiagramSEARCH: network physical topology diagrams bus star ring mesh

• Based on Connection Types:

  • Wired: Ethernet (IEEE 802.3), fiber optic.

  • Wireless Personal Area Network (WPAN): Bluetooth, ZigBee (short range, low power).

  • Wireless Local Area Network (WLAN): Wi-Fi (IEEE 802.11) (medium range, higher power).

  • Low-Power Wide Area Network (LPWAN): LoRaWAN, Sigfox, NB-IoT (long range, very low power, low data rate).

  DiagramSEARCH: IoT network types diagram LPWAN WLAN WPAN

IoT LAN Development Issues

• Interoperability: Diverse devices/protocols.

• Scalability: Supporting hundreds/thousands of nodes.

• Power Management: Battery life for constrained devices.

• Security: Securing low-power devices.

• Reliability & Coverage: Ensuring connectivity in large/dense areas.

• Cost: Deployment and maintenance.

Key IoT Protocols & Standards

• IEEE 802.15.4:

  • Specification: Standard for low-rate wireless personal area networks (LR-WPANs). Defines physical (PHY) and medium access control (MAC) layers.

  • Relation to IoT: It is the foundational PHY/MAC layer for higher-layer IoT protocols like ZigBee, 6LoWPAN, and WirelessHART. Provides low-power, low-data-rate, low-cost communication.

• 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks):

  • Functionality: Enables IPv6 packets to be carried efficiently over IEEE 802.15.4-based networks. Performs header compression, fragmentation/reassembly.

  • Role in IoT: Allows every "thing" to have a global IPv6 address, enabling direct Internet integration without complex translation gateways.

  • Differences from IPv4/IPv6:

    • vs IPv4: Uses 128-bit addresses (massive space), no NAT needed, built-in security (IPsec optional).

    • vs Native IPv6: Adapts IPv6 for constrained links (MTU ~127 bytes) via compression (HC1, HC2), making it feasible for low-power devices.

• IPv6 Impact on IoT:

  • Vast Address Space: $$\displaystyle 2^{128} $$ addresses allows unique addressing for every device.

  • Auto-configuration: SLAAC simplifies device onboarding.

  • Efficient Routing: Hierarchical addressing.

  • Challenges: Implementation overhead on constrained devices, transition from IPv4, security (IPsec is optional/complex).

• ZigBee:

  • Definition: A high-level communication protocol based on IEEE 802.15.4 for low-power, low-data-rate, long-battery-life applications.

  • Architecture:

    DiagramCANVAS: ZigBee stack diagram showing Application, Network (NWK), MAC, PHY layers. Highlight ZigBee Device Objects (ZDO), Application Framework (AF), and profiles (Home Automation, HA).

    • Device Types:

      • Coordinator (ZC): Forms network, stores network info, may be a trust center.

      • Router (ZR): Can route traffic, extend network range, may join as child/end device.

      • End Device (ZED): Low-power, can only talk to parent (ZC/ZR), sleeps most of time.

  • Types: ZigBee PRO (general), ZigBee Home Automation (HA), ZigBee Light Link (ZLL), ZigBee 3.0 (unified standard).

Software Defined Networking (SDN)

• Concept in IoT: Separates control plane (centralized SDN controller) from data plane (switches/routers). In IoT, the controller can manage network traffic, security policies, and resource allocation for diverse devices dynamically.

• Maturity Assessment: Maturing but not fully mature for large-scale IoT.

  • Pros: Centralized management, flexibility, programmability good for dynamic IoT networks.

  • Cons: Controller is single point of failure, scalability challenges for massive IoT, security of southbound APIs, overhead on constrained devices. More common in enterprise/cellular IoT (e.g., 5G core) than in resource-constrained WSN.

VI. Application Layer Protocols

MQTT (Message Queuing Telemetry Transport)

• Protocol: Lightweight publish-subscribe messaging protocol over TCP/IP.

• Example: Temperature sensor (publisher) publishes {"temp": 25.5} to topic home/livingroom/temp. A mobile app (subscriber) subscribed to that topic receives it.

• Role in IoT: Ideal for low-bandwidth, high-latency, unreliable networks. Minimal overhead (2-byte header), supports QoS levels (0,1,2), decouples producers/consumers.

• WebSockets: MQTT can be transported over WebSockets to enable browser-based MQTT clients (e.g., web dashboards).

CoAP (Constrained Application Protocol)

• Basic Operations: RESTful protocol (GET, PUT, POST, DELETE) for constrained nodes. Uses UDP (optional confirmable messages). Supports observe (for notifications).

• Request-Response Model: Similar to HTTP but optimized. Client sends request (CON), server responds (ACK/RST). Can be multicast.

• Use on Same Constrained Network: CoAP is designed for lossy, low-power networks (like 6LoWPAN). It uses small binary headers, low parsing overhead, and optional reliability (CON/NON messages), making it more efficient than HTTP on such networks. Justification: Minimal overhead, supports multicast, works over UDP.

AMQP (Advanced Message Queuing Protocol)

• Features & Components: Binary, message-oriented protocol with guaranteed delivery, routing, and queuing. Components: Sender, Receiver, Broker (exchanges, queues).

• Message Attributes & Payload: Message has properties (content-type, priority, timestamp) and a body (payload). Enables rich metadata.

• Frame Types: AMQP defines multiple frame types for different purposes (e.g., OPEN, BEGIN, ATTACH, FLOW, TRANSFER, DISPOSITION, CLOSE). There are 7 core frame types.

XMPP (Extensible Messaging and Presence Protocol)

• How it Improves IoT Services: Based on XML (Jabber). Provides federation (cross-domain communication), presence (device status), security (TLS/SASL), and extensibility via XEPs. Enables secure, scalable, real-time device-to-device and device-to-cloud communication with built-in discovery.

SMQTT (Secure MQTT)

• Mechanism: Extends MQTT with lightweight security for constrained devices. Uses symmetric-key cryptography (AES) for message encryption and digital signatures (ECDSA) for authentication/integrity. Manages keys via a lightweight key management scheme.

WebSockets

• Role in IoT: Provides full-duplex, persistent TCP connection between client and server. Enables real-time, bidirectional communication from web browsers to IoT servers (e.g., live dashboards, control panels), overcoming HTTP's request-response limitation.

VII. Cloud Computing & Data Analytics

Cloud for IoT

• Usefulness:

  • Scalability: Elastic resources for massive data.

  • Cost-Effective: Pay-as-you-go, no upfront infrastructure.

  • Global Access: Data and apps accessible anywhere.

  • Advanced Analytics: Built-in ML/AI services.

  • Device Management: Provisioning, monitoring, updates.

• Cloud Communication APIs: RESTful APIs (HTTP/HTTPS), MQTT/CoAP endpoints, WebSockets, vendor-specific SDKs (AWS IoT SDK, Azure IoT SDK).

Cloud Service Models in IoT Context

IoT Platforms

• Overview: End-to-end suites that connect devices, manage data, enable analytics, and provide application frameworks.

• Examples: AWS IoT, Microsoft Azure IoT, Google Cloud IoT Core, IBM Watson IoT, ThingWorx (PTC).

Data Analytics in IoT

• Role & Importance: Transforms raw sensor data into actionable insights. Enables predictive maintenance, anomaly detection, optimization, and new business models. Critical for realizing IoT value.

• IoT Analytics Definition: The application of data analytics techniques (statistical analysis, ML, stream processing) to the high-volume, high-velocity, high-variety data generated by IoT systems.

VIII. Security & Privacy in IoT

Need for Security in IoT

• Reasons:

  1. Physical World Impact: Attacks can cause physical harm (medical devices, industrial control).

  2. Privacy Violation: Sensors collect intimate personal data (location, health).

  3. Large Attack Surface: Billions of devices, often poorly secured.

  4. Critical Infrastructure: Smart grids, transportation are targets.

  5. Botnets: Compromised IoT devices used for DDoS (e.g., Mirai).

Security Models in IoT

• CIA Triad Adaptation:

  • Confidentiality: Encrypt data at rest/in transit (AES, TLS/DTLS).

  • Integrity: Ensure data not altered (HMAC, digital signatures).

  • Availability: Ensure services accessible (DDoS mitigation, redundancy).

• Extended Models: Include Authentication (device identity), Authorization (access control), Non-Repudiation, Accountability.

• Layered Security: Security must be applied across Perception, Network, Middleware, Application, Business layers.

Vulnerabilities in IoT Systems

• Hardware: Tampering, side-channel attacks, insecure debug interfaces.

• Software/Firmware: Weak/default passwords, unpatched vulnerabilities, buffer overflows.

• Network: Insecure communication (no encryption), open ports, weak protocols.

• Cloud/Application: Insecure APIs, web interface flaws, poor access control.

• Lifecycle: Lack of secure update mechanisms.

Attacks on IoT Systems

• General Types:

  • Physical Tampering: Direct access to device.

  • Side-Channel: Power analysis, timing attacks.

  • Replay: Resending valid captured messages.

  • DoS/DDoS: Flooding device/network/cloud.

  • Spoofing: Faking device identity (MAC/IP).

• Attacks Exploiting Application/Service Layer:

  • Injection Attacks: SQL, command injection via APIs.

  • Broken Authentication: Weak credentials, session hijacking.

  • Sensitive Data Exposure: Leaking data via logs, APIs.

  • XML External Entities (XXE): In XML-based protocols (XMPP).

  • Insecure Deserialization: Malicious object reconstruction.

  • API Abuse: Rate limiting bypass, improper authorization.

Security & Privacy Issues

• Security Issues: Device hijacking, data breaches, ransomware on IoT, botnets, supply chain attacks.

• Privacy Issues:

  • Data Collection: Unaware/continuous surveillance.

  • Data Usage: Secondary use, profiling, discrimination.

  • Data Sharing: Third-party sharing without consent.

  • Lack of Anonymity: Device IDs link to individuals.

  • Geolocation Privacy: Tracking physical movements.

IX. Applications & Case Studies

Smart Home Automation

• Applications: Lighting control, HVAC, security (cameras, locks), entertainment, appliance control, energy management.

• Design with Raspberry Pi:

  DiagramCANVAS: Smart home sketch. Show Raspberry Pi as central hub/gateway. Connect via GPIO to relays (for lights/fans), sensors (DHT22, PIR), and camera. Show Pi connected to home Wi-Fi router, then to cloud (e.g., Blynk, Home Assistant). Show smartphone app accessing cloud.

  • Hardware: RPi (3/4) as gateway, NodeMCU/ESP8266 for low-power nodes (sensors), relays, sensors (PIR, DHT), camera module.

  • Software: RPi runs Home Assistant or custom Python/Node.js server. Sensors use MQTT/CoAP to talk to RPi. RPi exposes REST API/WebSocket to cloud/user app.

IoT Case Studies (Detailed Example: Smart Agriculture)

• System: Network of soil moisture, temperature, humidity sensors (using LoRaWAN/6LoWPAN) across fields.

• Gateway: Aggregates data, sends via cellular to cloud.

• Cloud Platform: AWS IoT Core for ingestion, S3 for storage, Lambda for processing.

• Analytics: Predictive model for irrigation scheduling based on weather forecast + soil data.

• Actuation: Automated control of drip irrigation valves via MQTT commands.

• Benefits: Water savings (20-40%), increased yield, reduced labor.

• Challenges: Device power (battery life), network coverage in rural areas, data accuracy, farmer adoption.

IoT Platforms (as Application Enablers)

• Provide device management, data ingestion, storage, analytics, visualization, and integration APIs. Examples: AWS IoT Suite, Azure IoT Suite, Google Cloud IoT Core, IBM Watson IoT Platform.

X. Additional/Integrated Concepts

Logical vs. Physical Design of IoT

• Logical Design: What the system does. Defines functional blocks, data flows, protocols, software architecture, and use cases. (e.g., UML diagrams, sequence diagrams, data models).

• Physical Design: How it is built. Specifies hardware components (sensors, MCU, comms module), power, physical layout, installation, and networking infrastructure.

[!TIP] Exam Distinction: Logical = functions & data; Physical = hardware & wiring.

IoT Gateway Functionality & Ecosystem Working

• Gateway Functionality:

  1. Protocol Translation: Converts between device protocols (ZigBee, BLE) and Internet protocols (MQTT, HTTP).

  2. Data Filtering & Aggregation: Pre-processes data at edge (reduces cloud load).

  3. Security: Firewall, encryption, authentication for local network.

  4. Device Management: Onboarding, configuration, OTA updates.

  5. Local Processing/Control: Enables offline operation and fast response.

• Ecosystem Working:

  Sensors/Actuators → (ZigBee/BLE) → **Gateway** (Protocol translate, filter) → (Wi-Fi/Ethernet) → Cloud Platform → Analytics → Application (User Dashboard) → (Commands) → Gateway → Actuators.

Challenges & Requirements of IoT Devices

• Challenges: Power constraints, limited compute/memory, security vulnerabilities, scalability, interoperability, data privacy, physical security.

• Requirements:

  • Low Power: Long battery life (years).

  • Small Form Factor.

  • Low Cost.

  • Reliability & Robustness.

  • Security by Design.

  • Interoperability (standard protocols).

  • Easy Deployment & Management.

Pneumatic Systems (in IoT Context)

• Definition: Systems using compressed air to transmit and control energy.

• IoT Role: Pneumatic actuators (cylinders, grippers) are common in industrial IoT (IIoT). IoT sensors (pressure, flow, position) monitor system health (leaks, pressure drops), enable predictive maintenance, and allow remote control via gateways/PLC integration.

• Components: Compressor, air tank, valves, actuators, sensors, tubing.

Difficult Cloud IoT Integration Example

• Example: Integrating legacy industrial PLCs (using Modbus RTU over RS-485) with a modern cloud IoT platform (e.g., AWS IoT).

• Challenges:

  1. Protocol Gap: PLCs use serial, non-IP; cloud uses MQTT/HTTP.

  2. Data Format: PLC data is binary registers; cloud expects JSON.

  3. Latency/Reliability: Serial network may be unreliable.

  4. Security: PLCs have no built-in security; gateway must handle authentication/encryption.

• Solution:

  1. Deploy a local edge gateway (Raspberry Pi/industrial PC) with serial port.

  2. Gateway runs protocol converter (Modbus master) to poll PLCs.

  3. Gateway translates data to MQTT messages with JSON payload.

  4. Gateway uses TLS to securely connect to cloud IoT Core.

  5. Implement local buffering on gateway for network outages.

  6. Use device shadows in cloud to maintain state.