UNIT 5: Internet of Things (ME-702 B) – Short Notes

Based on rigorous analysis of RGPV past papers (Jun 2025, Dec 2024, May 2024, May 2023, May 2022), these notes are optimized for exam success. Focus on definitions, diagrams, comparisons, and protocol mechanics.

I. IoT Fundamentals, Ecosystem, and Architectural Frameworks

IoT Definition, Characteristics, and Core Concepts

• Definition: A global infrastructure for the information society enabling advanced services by interconnecting physical and virtual things based on existing and evolving interoperable information and communication technologies.

• Core Characteristics (8 Key Attributes):

  1. Interconnectivity: Things connected to the Internet.

  2. Things-related Services: Services provided to things (control) and by things (data).

  3. Heterogeneity: Diverse hardware, software, and communication protocols.

  4. Dynamic changes: Device state (location, connectivity) changes constantly.

  5. Enormous scale: Billions of devices.

  6. Autonomy: Limited human intervention.

  7. Architectures: Not a single technology but a paradigm requiring layered architectures.

  8. Complexity: High system complexity due to scale and heterogeneity.

• IoT Ecosystem Components:

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

  • Communication: Networks (WAN, LAN, PAN), protocols.

  • Data & Analytics: Storage, processing, intelligence.

  • Services & Applications: End-user interfaces, business logic.

  • Management & Security: Device management, security frameworks.

• Role of "Things" and Internet: "Things" are physical/virtual entities with sensing/actuating/processing capabilities. The Internet provides global connectivity, standard protocols (IP), and a platform for data aggregation and service delivery.

• IoT Analytics: Process of deriving meaningful insights from massive, often real-time, IoT data streams. Involves stream processing, edge analytics, and batch processing to enable predictive maintenance, anomaly detection, and optimization.

[!TIP] Exam often asks for "role of things and Internet" separately. Define each clearly.

IoT Architectural Frameworks

• Common Reference Models:

  • Three-Layer Architecture:

    1. Perception Layer: Physical sensors/actuators for data acquisition/control.

    2. Network Layer: Data transmission via wired/wireless networks (Internet, WSN, Bluetooth).

    3. Application Layer: Delivers specific services to users (smart home, health).

  • Five-Layer Architecture (More Detailed):

    1. Perception Layer

    2. Transport Layer: Moves data from perception to processing (gateways, networks).

    3. Processing Layer (Middleware): Data storage, processing, management (cloud/edge).

    4. Application Layer

    5. Business Layer: Overall system management, business models, analytics.

  • IoT-A Reference Architecture (European): Defines IoT Domain Model, Information Model, Communication Model, and Functional Model.

• Service-Oriented Architecture (SOA) for IoT:

  • Concept: Treats every device/component as a service provider. Services are self-contained, loosely coupled, and discoverable.

  • Challenges: Resource constraints (CPU, memory, power) on devices; heterogeneity; real-time requirements; security integration.

• IoT Planes (Logical Abstraction):

  • Device Plane: Physical things and their local connectivity.

  • Communication Plane: Network infrastructure for data transport.

  • Application Plane: User-facing services and apps.

  • Management Plane: Device provisioning, monitoring, updates, security.

  • Business Plane: Analytics, monetization, business rules.

  • Interdependency: Changes in one plane (e.g., new device type) affect all others.

    DiagramSEARCH: "IoT planes architecture diagram"

Design Perspectives

• Logical Design: What the system does. Defines functional blocks, data flows, services, and interactions without specifying physical hardware. Uses UML, sequence diagrams.

• Physical Design: How the system is built. Specifies hardware (sensors, microcontrollers), communication modules, power sources, and physical layout.

• IoT Gateways:

  • Functionality: Protocol translation (e.g., ZigBee to MQTT), data filtering/aggregation, security enforcement, device management, edge computing.

  • Role: Bridge between constrained device networks (WSN) and the IP-based Internet/cloud. Acts as a "intelligent hub" reducing cloud traffic and latency.

M2M vs. IoT

• M2M Service Layer Standardization: Efforts by oneM2M (global partnership) to create a common service layer for M2M/IoT, enabling interoperability across different hardware/network platforms.

• Shifting to IoT Drivers: Need for scalability, IP ubiquity, cloud integration, advanced analytics, and new business models (vs. simple automation).

IoT System Levels (Design Abstraction)

• Level 3 (Device-Centric): Single device with basic connectivity (e.g., a smart thermostat). Data goes directly to a cloud/app.

• Level 4 (Gateway-Centric): Multiple devices connect to a local gateway. Gateway performs protocol translation, local processing, and manages device communication. Reduces cloud dependency and latency. Example: Smart home hub connecting ZigBee lights, Z-Wave locks, and Wi-Fi cameras.

• Level-Based Design: Start at Level 3 for simple applications, scale to Level 4+ for complex systems requiring local intelligence, security, and reduced bandwidth.

Development Challenges & Requirements

• Device Challenges:

  • Power: Battery life vs. performance (duty cycling, low-power modes).

  • Processing: Limited CPU/RAM for complex tasks (edge computing trade-off).

  • Memory: Storage for firmware, logs, and buffered data.

  • Sensing/Actuation: Accuracy, calibration, environmental robustness.

  • Security: Secure boot, firmware updates, key storage in resource-constrained devices.

• IoT LAN Development Issues:

  • Interference: 2.4 GHz band congestion (Wi-Fi, Bluetooth, ZigBee).

  • Topology Management: Dynamic device joining/leaving, mesh network routing.

  • Scalability: Network protocols must handle many nodes.

  • Reliability: Packet loss in noisy RF environments.

  • Coexistence: Multiple wireless protocols in same physical space.

II. Hardware Components and Enabling Technologies

Sensors

• Definition: Transducer that converts a physical phenomenon (temperature, light, pressure) into an electrical signal.

• Common Commercially Available Types:

  • Environmental: Temperature (DS18B20, DHT22), Humidity (DHT22), Pressure (BMP180), Gas (MQ series).

  • Motion/Position: Accelerometer (MPU6050), Gyroscope, Magnetometer, GPS (NEO-6M).

  • Proximity: Infrared (IR), Ultrasonic (HC-SR04), PIR (motion).

  • Optical: Photoresistor, Camera modules.

  • Flow: Water flow sensor.

• Sensor Selection Criteria:

  1. Accuracy & Precision: Required measurement tolerance.

  2. Range: Min/max measurable values.

  3. Resolution: Smallest detectable change.

  4. Response Time: Time to output change after input change.

  5. Power Consumption: Critical for battery devices.

  6. Size/Form Factor: Fit for application.

  7. Cost.

  8. Interface: Analog (voltage/current) vs. Digital (I2C, SPI, UART).

• Quantization Error: Error introduced during Analog-to-Digital Conversion (ADC). The continuous analog signal is mapped to discrete digital levels. The maximum error is ±½ of the Least Significant Bit (LSB).

$$ \text{Quantization Error}_{max} = \pm \frac{V_{ref}}{2^{n}} $$

Where $$\displaystyle V_{ref} $$ is reference voltage, $n$ is ADC resolution (bits).

• Sensor Comparison Example (Temperature):

  | Sensor | Type | Interface | Accuracy | Range | Power | | :--- | :--- | :--- | :--- | :--- | :--- | | DS18B20 | Digital | 1-Wire | ±0.5°C | -55°C to +125°C | Low | | DHT22 | Digital | Single-bus | ±0.5°C | -40°C to +80°C | Low | | LM35 | Analog | Voltage | ±0.5°C | -55°C to +150°C | Very Low |

Actuators

• Role: Convert electrical/control signals into physical action (movement, force). The "output" side of IoT.

• Types & Comparison:

  | Type | Principle | Advantages | Disadvantages | IoT Example | | :--- | :--- | :--- | :--- | :--- | | Mechanical | Electric motor (DC, stepper, servo) | High torque, precise control | Bulky, friction, wear | Robotic arm, valve control | | Pneumatic | Compressed air | Fast, clean, high power/weight | Needs air compressor, leaks | Factory automation, grippers | | Hydraulic | Pressurized fluid | Very high force, smooth | Leaks, maintenance, bulky | Heavy machinery | | Soft | Elastomeric materials, air/muscle | Safe for human interaction, flexible | Low force, complex control | Wearable robotics, grippers | | SMP (Shape Memory Polymer) | Material shape change via heat/light | Biocompatible, silent | Slow, limited cycles | Medical stents, actuators |

• Four Common Actuator Selection Characteristics:

  1. Force/Torque Output: Required mechanical work.

  2. Speed/Response Time: How fast it must act.

  3. Precision/Accuracy: Required positioning or movement control.

  4. Power Source & Efficiency: Electrical (voltage/current), pneumatic, hydraulic; energy consumption.

Microcontrollers and Single-Board Computers

• Basic Microcontroller Review: Integrated circuit with CPU, memory (RAM/ROM), and programmable I/O peripherals (GPIO, ADC, UART, SPI, I2C) on a single chip. Interfacing involves connecting sensors/actuators to these I/O pins.

• Raspberry Pi vs. Desktop Computer:

  • Raspberry Pi: ARM-based Single-Board Computer (SBC), low power, no internal storage (uses SD card), general-purpose I/O pins, designed for embedded/educational use.

  • Desktop: x86/64 architecture, high power, internal HDD/SSD, expansion slots, no direct GPIO.

• Raspberry Pi Key Interfaces:

  • GPIO (General Purpose Input/Output): Digital pins for reading sensors (input) or controlling LEDs/motors (output). Programmable.

  • SPI (Serial Peripheral Interface): Synchronous, full-duplex, master-slave. 4 wires (MOSI, MISO, SCLK, CS). Fast, for high-speed devices (displays, ADCs).

  • I2C (Inter-Integrated Circuit): Synchronous, half-duplex, multi-master/multi-slave. 2 wires (SDA, SCL). Address-based, good for many low-speed sensors (IMU, temperature).

  • Key Difference: SPI is faster but uses more pins per device; I2C uses only 2 pins for multiple devices but is slower.

Identification Technologies

• RFID (Radio Frequency Identification):

  • Principle: Uses radio waves to automatically identify and track tags attached to objects. Tag (microchip+antenna) stores ID; Reader emits RF signal, receives tag response.

  • Features: Non-line-of-sight, fast read, unique ID, durable, various form factors.

  • Implementation in IoT: Asset tracking, inventory management, access control, supply chain. Reader connects to IoT gateway which sends data to cloud.

• NFC (Near Field Communication):

  • Technology: Short-range (≤10 cm), high-frequency (13.56 MHz) wireless. Based on RFID standards. Passive (tags) and active (phones) modes.

  • Applications: Contactless payments (Google Pay/Apple Pay), access cards, device pairing (tap-to-pair), data exchange between phones.

Wireless Sensor Networks (WSN)

• Relation to IoT: WSN is a key enabling technology for the Perception Layer of IoT. WSNs provide the infrastructure for dense, low-power, wireless sensing. IoT adds Internet connectivity, cloud integration, and higher-level services on top of WSN data.

  • Example: A WSN of temperature sensors in a field (perception) feeds data to an IoT platform for agricultural analytics (application).

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

• Network Types (Physical Topology & Connection):

  • Star: All nodes communicate with a central coordinator/sink. Simple, but single point of failure.

  • Mesh: Nodes can relay data for others. Highly robust, scalable, self-healing. (Used in ZigBee, Thread).

  • Tree: Hierarchical, cluster-based. Balance between star and mesh.

  • Hybrid: Combination of above.

  • DiagramSEARCH: "WSN topologies star mesh tree diagram"

III. Communication Protocols and Network Technologies

Application Layer Protocols

• Core Purpose: Define how data is formatted, exchanged, and interpreted between applications (devices, gateways, cloud).

• Comparison Table:

  | Protocol | Model | Key Features | Best For | Transport | | :--- | :--- | :--- | :--- | :--- | | MQTT | Publish/Subscribe | Lightweight, QoS levels (0,1,2), topic-based, retained messages. | Low-bandwidth, high-latency, unstable networks. Telemetry. | TCP | | CoAP | Request/Response | RESTful (GET/PUT/POST/DELETE), UDP-based, low overhead, observe for notifications. | Constrained nodes/networks, simple web-like interaction. | UDP | | AMQP | Publish/Subscribe & Queue | Rich messaging (transactions, security), heavy, enterprise. | Financial, enterprise messaging, guaranteed delivery. | TCP | | XMPP | Publish/Subscribe & Chat | XML-based, presence, roster management, extensible. | Human-to-human & human-to-machine chat, presence apps. | TCP | | SMQTT | Publish/Subscribe | Secure MQTT. Uses Symmetric Encryption (AES) for message payload and Asymmetric (RSA) for session key exchange. | Secure IoT messaging where MQTT is used but needs confidentiality. | TCP | | WebSockets | Full-duplex | Persistent TCP connection, real-time, bi-directional. | Web-based IoT dashboards, real-time control from browser. | TCP (upgrade from HTTP) |

MQTT (Message Queuing Telemetry Transport) - HIGHEST FREQUENCY

• Concept: Lightweight publish/subscribe messaging protocol.

• Role in IoT: Ideal for constrained networks. Decouples publishers from subscribers via a Broker. Minimizes network bandwidth and device resource usage.

• Example: Temperature sensor (publisher) sends data to topic home/livingroom/temp. Multiple apps (subscriber: mobile app, cloud analytics) receive it by subscribing to that topic.

• WebSockets Support: Yes. MQTT can run over WebSockets, allowing web browsers to directly subscribe to MQTT topics without a separate backend proxy.

CoAP (Constrained Application Protocol)

• Basics: RESTful protocol for constrained nodes/networks. Mimics HTTP (GET/PUT/POST/DELETE) but optimized for low overhead.

• Operations: Uses UDP (no connection setup). Includes confirmable (CON) and non-confirmable (NON) messages. Has Observe option for long-term notifications (like a lightweight subscription).

• Use in Constrained Networks: Low header overhead (~4 bytes vs. HTTP's ~20), no head-of-line blocking (UDP), supports multicast. Perfect for sleeping sensors that need to send occasional data.

AMQP (Advanced Message Queuing Protocol)

• Features: Standardized, interoperable, rich messaging model (exchanges, queues, bindings). Supports transactions, security (SASL, TLS), and flow control.

• Components: Publisher → Exchange (routes messages) → Queue (stores messages) → Consumer.

• Frame Types: AMQP defines frames for method (commands), header (message properties), body (message content), and heartbeat.

• Message Attributes & Payload: Attributes include content-type, content-encoding, message-id, timestamp, delivery-mode (persistent/transient). Payload is the actual application data (binary/string).

XMPP (Extensible Messaging and Presence Protocol)

• How it Improves IoT Services:

  1. Presence: Know if a device is online/offline.

  2. Roster/Contact List: Manage device-to-device relationships.

  3. Extensibility (XEPs): Custom extensions for IoT (e.g., sensor data, control commands).

  4. Decentralized: No single central broker needed (federated servers).

  5. Human-readable XML: Easier debugging.

Network and Link Layer Standards

• IEEE 802.15.4:

  • Protocol: 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 foundation for higher-layer protocols like ZigBee, 6LoWPAN, and Thread. Provides basic star/peer-to-peer topologies, CSMA/CA access, and 250 kbps data rate (2.4 GHz).

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

  • Role in IoT: Enables IPv6 packets to be carried efficiently over 802.15.4 networks. Solves IPv6's large 40-byte header problem via header compression and fragmentation.

  • Difference from IPv4/IPv6: Not a new IP version. It's an adaptation layer that makes standard IPv6 usable on constrained links. Allows every IoT device to have a unique global IPv6 address.

• ZigBee:

  • Architecture (Detailed): Built on 802.15.4. Adds Network (NWK) and Application (APL) layers.

    • Device Types:

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

      • Router (ZR): Can route traffic, extend network, join as child/parent.

      • End Device (ZED): Can only communicate with parent (router/coordinator), sleeps to save power.

    • Topologies: Star (ZCs only), Tree, Mesh (most common).

  • Types: ZigBee PRO (main, for large networks), ZigBee IP (uses 6LoWPAN/IPv6), ZigBee RF4CE (consumer electronics remote control).

  • Features: Low power, low cost, large network capacity (65k+ nodes), self-healing mesh, secure (AES-128).

  • DiagramSEARCH: "ZigBee network architecture coordinator router end device"

Advanced Networking

• Software Defined Networking (SDN):

  • Concept: Separates control plane (centralized SDN controller, makes decisions) from data plane (switches/routers, forwards packets). Controller programs network behavior via open APIs (e.g., OpenFlow).

  • Maturity for IoT: Emerging/Research Phase. Promises centralized management, dynamic network slicing for different IoT traffic, and efficient resource use. Challenges: scalability of controller, security of control channel, overhead on constrained devices.

IV. Cloud Integration, Data Analytics, and IoT Platforms

Cloud Computing for IoT

• Usefulness for IoT:

  1. Scalable Storage & Compute: Handles massive, growing IoT data.

  2. Cost-Effective: Pay-per-use, no upfront infrastructure.

  3. Advanced Analytics: Built-in AI/ML services for insights.

  4. Global Reach: Low-latency access via cloud edge regions.

  5. Device Management: At scale (provisioning, monitoring, updates).

• Cloud Service Models:

  • IaaS (Infrastructure as a Service): VMs, storage, networks. (e.g., AWS EC2, GCP Compute Engine). User manages OS, middleware, apps.

  • PaaS (Platform as a Service): Runtime environment, DBs, dev tools. (e.g., AWS IoT Core, Azure IoT Hub, Google Cloud IoT Core). User manages apps & data. Most common for IoT platforms.

  • SaaS (Software as a Service): Complete applications. (e.g., Salesforce, Office 365). Vendor manages everything.

• Cloud Communication APIs: RESTful APIs (HTTPS), MQTT, CoAP endpoints provided by cloud IoT platforms for devices/gateways to connect and exchange data.

IoT Platforms

• Features & Components:

  1. Device Management: Onboarding, provisioning, monitoring, firmware updates (OTA).

  2. Data Ingestion: Connectors for MQTT, CoAP, HTTP, legacy protocols.

  3. Data Processing/Storage: Stream processing (e.g., AWS Kinesis), time-series DBs (InfluxDB), big data stores.

  4. Analytics & Visualization: Dashboards, rule engines, ML integration.

  5. Security: Authentication, authorization, encryption.

  6. Application Enablement: SDKs, APIs for building custom apps.

  • Examples: AWS IoT Core, Microsoft Azure IoT Suite, Google Cloud IoT Core, IBM Watson IoT Platform.

Data Analytics in IoT

• Role: Transform raw sensor data into actionable insights (predictive maintenance, anomaly detection, optimization, new services). The core value proposition of IoT.

• IoT Analytics Process:

  1. Data Acquisition: From sensors/gateways.

  2. Data Integration & Preprocessing: Clean, filter, aggregate, handle missing values.

  3. Analytical Modeling: Apply statistical methods, ML algorithms (regression, classification, clustering), or deep learning.

  4. Interpretation & Visualization: Present insights to users/other systems.

  5. Action/Feedback Loop: Trigger actuators or update models.

• IoT vs. M2M Analytics:

  • M2M: Typically descriptive (what happened?) or diagnostic (why?). Focused on single machine/process. Data volume lower, velocity lower.

  • IoT: Predictive (what will happen?) and prescriptive (what should we do?). Correlates multi-modal data (machine, environment, user). High volume, velocity, variety (3Vs of Big Data).

V. Security and Privacy in IoT

Security Requirements and Models

• Why Security is Required in IoT:

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

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

  3. Critical Infrastructure: Power grids, transportation.

  4. Massive Scale: One vulnerability can affect millions.

  5. Heterogeneity: Inconsistent security implementation.

  6. Resource Constraints: Hard to implement strong crypto on low-power devices.

• Security Models in IoT:

  • CIA Triad (Foundation): Confidentiality, Integrity, Availability.

  • Zero Trust Model: "Never trust, always verify." Assumes network is hostile. Requires strict identity verification for every device/user/transaction.

  • End-to-End Security: Security from sensor to cloud application, not just at network perimeter.

  • Layered Security (Defense in Depth): Security at device, network, gateway, cloud, and application layers.

Vulnerabilities and Attacks

• Kinds of Vulnerabilities Observed in IoT:

  • Hardware: Debug interfaces exposed (JTAG/UART), physical tampering.

  • Software/Firmware: Hardcoded credentials, unpatched OS/libs, buffer overflows.

  • Network: Insecure wireless transmission (no encryption), default open ports.

  • Authentication/Authorization: Weak/default passwords, no mutual auth.

  • Privacy: Excessive data collection, lack of user consent.

• Attacks on IoT Systems (Focus: Application/Service Layer):

  • DDoS (Distributed Denial of Service): Compromised IoT bots (Mirai) flood a target service/cloud API.

  • Message Spoofing/Tampering: Attacker sends false sensor data or alters commands (e.g., fake temperature reading, unauthorized actuator command).

  • Replay Attacks: Capturing and retransmitting valid messages later (e.g., "unlock door" command).

  • Man-in-the-Middle (MitM): Intercepting and altering communication between device and cloud/app.

  • API Abuse: Exploiting poorly secured cloud APIs (excessive data read, command injection).

  • Privacy Attacks: Profiling users from aggregated sensor data.

• Security & Privacy Issues: Lack of standardization, insecure default configurations, long device lifespans without updates, data ownership ambiguity, location tracking.

Secure Messaging (SMQTT)

• SMQTT (Secure MQTT): Extension of MQTT providing confidentiality.

• Secure Message Transfer Mechanism:

  1. Session Key Exchange: Uses asymmetric cryptography (RSA). Publisher encrypts a symmetric session key with the broker's public key and sends it.

  2. Message Encryption: All subsequent payloads are encrypted using the shared symmetric key (AES). Broker cannot read payloads, only routes encrypted blobs.

  3. Broker Role: Acts as a "dumb" forwarder of encrypted messages. Does not need to be fully trusted for data confidentiality.

  • Trade-off: Adds computational overhead on resource-constrained devices.

VI. Applications, Case Studies, and System Design

Smart Home and Building Automation

• Smart Home Applications:

  • Lighting control (on/off, dimming, scheduling).

  • HVAC (heating, ventilation, air conditioning) automation.

  • Security (smart locks, cameras, motion sensors, alarms).

  • Entertainment (multi-room audio, voice control).

  • Appliance control (smart plugs, fridge monitoring).

  • Energy management (smart meters, solar integration).

• Design of Smart Home with Raspberry Pi:

  • Central Hub: Raspberry Pi runs IoT platform/software (e.g., Home Assistant, OpenHAB, custom Node.js/Python app).

  • Sensors: Temperature/humidity (DHT22), motion (PIR), door/window contacts, light sensors.

  • Actuators: Relays for lights/fans, servo for locks, IR blaster for TV/AC.

  • Connectivity:

    • Raspberry Pi GPIO → Direct connection to simple sensors/actuators.

    • Raspberry Pi + USB Dongle → ZigBee/Z-Wave Coordinator to connect low-power mesh devices (sensors, switches).

    • Wi-Fi/Ethernet → For cloud connectivity, cameras, high-bandwidth devices.

  • Cloud: Optional for remote access, backup, advanced analytics.

  • User Interface: Mobile app, web dashboard, voice assistants (Alexa/Google Home via integration).

  • DiagramCANVAS: "Smart Home Architecture Sketch. Central Raspberry Pi hub. Show connections: 1) GPIO to temp sensor and relay. 2) USB ZigBee dongle to ZigBee motion sensor and smart bulb. 3) Pi's Wi-Fi to cloud and user's smartphone. Label all components clearly."

Industrial and Domain-Specific IoT (IIoT)

• Industrial IoT Examples:

  • Predictive Maintenance: Vibration/temperature sensors on motors → ML model predicts failure.

  • Asset Tracking: RFID/GPS on tools/containers in a factory/warehouse.

  • Process Optimization: Sensors on assembly line → real-time adjustment.

  • Energy Management: Smart meters, HVAC control in large buildings.

  • Safety: Gas leak detectors, wearable safety monitors for workers.

• Case Study: Difficult Cloud IoT Integration & Solution

  • Scenario: Legacy factory machinery with proprietary, non-IP protocols (e.g., Modbus RTU over RS-485). Goal: Integrate sensor data into a modern cloud IoT platform (AWS IoT).

  • Challenges:

    1. Protocol Translation: Converting serial Modbus to MQTT/HTTPS.

    2. Data Format: Mapping proprietary register values to meaningful JSON.

    3. Latency & Reliability: Real-time control vs. cloud round-trip.

    4. Security: Isolating OT (Operational Technology) network from IT/cloud.

  • Solution:

    1. Use a local industrial gateway (e.g., Raspberry Pi + USB-to-RS485 adapter + Node-RED).

    2. Gateway runs Modbus master to poll devices.

    3. Gateway runs MQTT client to publish standardized JSON payloads to AWS IoT Core.

    4. Implement VPC, security groups, and certificates for secure, isolated cloud connection.

    5. Use AWS Greengrass for local lambda functions if low-latency control is needed (edge computing).

IoT in Power Systems (Smart Grid)

• IoT-Based Monitoring in Power Plants:

  • Smart Sensors: Vibration, temperature, current/voltage (CT/PT), partial discharge sensors on transformers, generators, switchgear.

  • Communication: Wired (Ethernet) for critical, high-bandwidth; Wireless (LTE/5G, RF mesh) for remote/substation monitoring.

  • Analytics: Real-time monitoring dashboards, predictive maintenance (trend analysis of temperature/vibration), anomaly detection (early fault warning), asset health indexing.

  • Benefits: Reduced downtime, optimized maintenance scheduling, improved safety, extended asset life.

Final Exam Strategy:

1. Definitions First: Always start answers with a clear, concise definition (e.g., "MQTT is a lightweight publish/subscribe...").

2. Diagrams are Crucial: For ZigBee, IoT planes, Smart Home, WSN topologies – draw a neat, labeled sketch. Even a rough diagram with correct labels earns marks.

3. Compare & Contrast: Use tables in your mind or on paper for M2M vs IoT, protocols, sensors, actuators.

4. Protocol Mechanics: Know the core operation of MQTT (publish/subscribe, broker), CoAP (REST/UDP/Observe), and SMQTT (AES/RSA).

5. Link Topics: Connect Security to SMQTT, Cloud to IoT Platforms, WSN to IoT Perception Layer.

6. Examples: Anchor concepts with real examples (e.g., "ZigBee is used in Philips Hue smart bulbs").

\boxed{\text{Revise all diagrams and protocol message flows thoroughly.}}