Unit-1
1) Define IoT
Definition:
The Internet of Things (IoT) is a network of uniquely identifiable physical objects (“things”) embedded
with sensors, actuators, processing, and connectivity that allow them to sense, exchange, and act on
data—often autonomously—over IP-based or non-IP networks, integrated with cloud/edge services to
deliver business value.
Key characteristics:
1. Sensing and actuation of the physical world.
2. Connectivity (short-range, LPWAN, cellular, satellite).
3. Edge computing plus cloud analytics.
4. Identity and device management at scale.
5. Security end-to-end (device ↔ network ↔ cloud).
6. Interoperability via standard protocols and data models.
7. Automation and closed-loop control.
Example flow: Thing → Gateway/Edge → Ingestion/Broker → Storage/Analytics → Application/Control
→ Actuator.
--
2) Write about RFID
What it is: Radio-Frequency Identification uses tags (with a chip + antenna) and readers to identify
objects wirelessly.
Components:
1. Tag: chip, memory (EPC/UID + user memory), antenna; passive/active/semi-passive.
2. Reader/Interrogator: RF front-end, controller, comms to backend.
3. Middleware/DB: filtering, aggregation, event rules.
Frequency bands & ranges:
1. LF (125–134 kHz): short range (≤10 cm), animal ID, anti-metal friendly, slow data rate.
2. HF (13.56 MHz, includes NFC): range up to ~10–30 cm, tickets, access.
3. UHF (860–960 MHz): 1–10 m (passive), fast inventory, supply chain.
4. Microwave (2.45/5.8 GHz): special apps, tolling.
Protocols/Standards: ISO 14443/15693 (HF), ISO 18000-6C / EPC Gen2 (UHF), ISO 18000-3 (HF),
NFC-A/B/F.
Anti-collision: ALOHA/tree-based algorithms allow reading many tags.
Advantages: fast, line-of-sight not needed, bulk read, robust.
Limitations: interference (liquids/metal), privacy concerns, cost for active tags, regulations.
Use-cases: retail inventory, asset tracking, e-passports, library, tolling, livestock
3) General framework of IoT for hyper-connected devices
Layered reference (end-to-end):
1. Physical/Things: sensors, actuators, IDs, power.
2. Connectivity: PAN/LAN (BLE, Zigbee, Wi-Fi), WAN (LoRaWAN, NB-IoT, LTE-M, 5G, satellite).
3. Edge/Gateway: protocol translation (e.g., Modbus↔IP), filtering, local analytics, security offload.
4. Ingestion/Messaging: brokers and APIs (MQTT, AMQP, Kafka, HTTP, CoAP).
5. Data Platform: storage (time-series/NoSQL), stream/Batch analytics, digital twins, rules.
6. Applications & Integration: dashboards, mobile apps, enterprise integration (ERP/SCM/CRM),
automation.
7. Management & Security (cross-cutting): identity & access, device lifecycle (provision/OTA), secrets,
PKI, monitoring, governance, compliance.
Data life-cycle: sense → preprocess at edge → secure transport → ingest → store → analyze → visualize
→ decide → act (close loop).
---
4) IoT conceptual frameworks by Oracle and IBM
Oracle IoT Reference (concepts you should write):
1. Device virtualization and digital twins.
2. Gateways for protocol adaptation (fieldbus↔IP).
3. Secure message ingestion (REST/MQTT) into Oracle IoT/streaming.
4. Event processing, analytics, and rules for automation.
5. Enterprise integration (SOA, APIs) to ERP/SCM/HCM.
6. Cross-cutting: identity/PKI, policy, OTA, monitoring.
IBM (Watson/IoT) conceptual view:
1. Devices connect using MQTT to a message broker.
2. IoT platform handles device registry, auth, data routing.
3. Stream analytics + rules + ML services.
4. APIs to apps and back-office; dashboards.
5. Security by design: TLS, IAM, audit.
Difference to mention: Oracle emphasizes enterprise app integration and device virtualization; IBM
stresses MQTT pub/sub at scale with analytics and cognitive services. Both insist on security and lifecycle
mgmt.
5) IoT architectural view by Cisco
Cisco’s 7-layer IoT Reference Model (+ fog):
1. Physical Devices & Controllers – sensors/actuators, PLCs.
2. Connectivity – access networks (wired/wireless).
3. Edge/Fog Computing – local processing, aggregation, policy enforcement.
4. Data Accumulation – persist/queue to decouple producers/consumers.
5. Data Abstraction – normalize, index, expose via APIs.
6. Application – visualization, control, analytics apps.
7. Collaboration & Processes – people and business workflows.
Security and management span all layers. Fog brings compute closer to devices to reduce latency and
bandwidth.
6) IoT architectural view by Oracle
Write the following blocks:
1. Devices/Embedded OS (drivers, sensors).
2. Gateways/Edge (protocol bridging, local persistence, rules).
3. Secure Ingestion (REST, MQTT) into Oracle Stream/Service Bus.
4. Processing (Stream analytics, CEP, batch analytics, ML).
5. Enterprise Apps (ERP/SCM/Asset Mgmt) via APIs/integration cloud.
6. Device Mgmt (onboard, provision, OTA update, diagnostics).
7. Security/IdM (PKI, OAuth, policy).
8. Monitoring & Governance (logs, metrics, SLA).
7) Different components of an IoT system
1. End devices: sensors, actuators, microcontrollers/SoCs, power.
2. Connectivity: radios, stacks (BLE, Wi-Fi, LoRa, LTE-M, NB-IoT), SIM/eSIM.
3. Edge/Gateways: CPUs, fieldbus interfaces (CAN, RS-485, Modbus), protocol adapters.
4. Cloud/Platform: message brokers, device registry, digital twins, storage (TSDB), analytics, rules engine,
functions.
5. Applications: dashboards, mobile/web apps, alerts, control loops.
6. Security: hardware roots (TPM/SE), PKI, TLS/DTLS, access control, secure boot.
7. Operations: device management, OTA, monitoring/observability, ticketing.
8. Integration: APIs, webhooks, ETL to data lakes, ERP/SCADA.
8) What is an embedded application? Relation with IoT platform
Embedded application: software tailored to run on dedicated hardware (MCU/MPU) with constrained
resources to perform specific functions (e.g., temperature logger, motor control).
Relation with IoT platform:
1. The embedded app collects data, applies local logic, and exposes it via protocols (MQTT/CoAP/HTTP).
2. IoT platform provides secure onboarding, device twin, data pipelines, rules, visualization, and OTA
updates.
3. Together they form a closed loop: device logic ↔ cloud intelligence.
Example: ESP32 firmware (embedded app) publishes sensor data via MQTT to a platform that stores,
detects anomalies, and pushes OTA firmware.
---
9) About M2M (Machine-to-Machine) communication (long 14-mark answer)
Definition: M2M is direct data exchange between machines without human intervention, typically over
cellular, wired, or short-range links, often using specialized modules/SIMs and middleware.
Typical architecture:
1. Devices/RTUs/PLCs with sensors/actuators.
2. Communication module (GSM/3G/LTE-M/NB-IoT), sometimes SMS/USSD or circuit-switched data in
legacy.
3. APN/Private network or VPN to backend.
4. M2M Application Server for data collection, alarms, remote commands.
5. BSS/OSS for SIM lifecycle, billing, diagnostics.
Protocols: SMS, USSD, TCP/UDP over cellular, MQTT/HTTP over IP, OMA DM/LwM2M for device mgmt,
SNMP/Modbus for legacy.
Key features:
1. Always-on low-bandwidth, store-and-forward.
2. Remote monitoring & control (telemetry + telecommand).
3. Scalability to thousands/millions of endpoints via SIM mgmt.
4. High reliability (SLA with operators), fallback networks.
Advantages: wide coverage (cellular), mature modules, QoS options, private APNs, OTA reach.
Disadvantages: recurring connectivity cost/SIM mgmt, power draw (cellular radios), operator lock-in,
latency variability.
Security: private APN, IPsec/GRE tunnels, TLS, IMEI/ICCID whitelisting, eUICC (eSIM), device
authentication and secure boot.
Use-cases: smart metering, POS terminals, fleet/telematics, remote ATMs, vending machines, elevator
monitoring, oil & gas pipelines.
M2M vs IoT:
M2M is connectivity-centric (point solutions); IoT is platform-centric (data + analytics + APIs).
M2M often proprietary; IoT tends to use web/IT standards, device twins, open APIs, and integrates with
analytics/AI.
Design considerations: power profile (PSM/eDRX for NB-IoT), message size, retry/backoff strategy, FOTA,
physical ruggedness, compliance (PTCRB/GCF/CE).
---
10) Explain any examples of IoT applications + wireless communication used
a) Smart Agriculture (Precision Farming):
Sensors: soil moisture, EC, temperature; Actuators: valves/pumps.
Connectivity: LoRaWAN on fields to a gateway → backhaul via 4G/5G.
Logic: threshold-based irrigation + weather-aware scheduling.
Benefits: water saving, yield increase, labor reduction.
b) Smart Home Energy:
Sensors: smart plugs, smart meters.
Connectivity: Zigbee/Thread mesh inside home, Wi-Fi to router, cloud via broadband.
Logic: anomaly detection, load shifting to off-peak.
Benefits: lower bills, safety.
c) Cold-chain Logistics:
Sensors: temp/humidity + door open.
Connectivity: BLE beacons to a telematics hub; hub uses LTE-M.
Logic: geofenced alerts, excursion alarms; proof of compliance.
Benefits: reduced spoilage, regulatory compliance.
d) Predictive Maintenance in Industry:
Sensors: vibration, current, temperature on motors.
Connectivity: wired (4–20 mA/Modbus) to gateway; gateway publishes MQTT over TLS.
Logic: edge FFT + cloud ML.
Benefits: reduced downtime.
---
Unit-2
1) Define communication technology and its types (IoT context)
Definition: Set of physical/media layers, link/MAC, network, and transport/application protocols that
carry data between IoT entities under constraints of power, range, cost, bandwidth, and latency.
Major types (with where they fit):
1. NFC/HF RFID: centimeters; tap-and-go; provisioning, payments.
2. Bluetooth Classic/BLE: meters; peripherals, wearables; BLE for low power and GATT profiles.
3. Zigbee/Thread/802.15.4: mesh, home/industrial sensing; low power.
4. Wi-Fi (2.4/5/6 GHz): high throughput; cameras, firmware updates.
5. LPWAN (LoRaWAN, Sigfox): kilometers; very low power, tiny payloads.
6. Cellular IoT (2G/3G/4G, LTE-M, NB-IoT, 5G): ubiquitous coverage; mobility; QoS.
7. Satellite IoT (LEO/GEO): remote areas.
8. Wired (Ethernet, RS-485, CAN): reliability/EMI immunity.
---
2) Explain in detail NFC, RFID, Bluetooth, Zigbee, Wi-Fi
NFC: 13.56 MHz, ~<10 cm, reader/writer + card emulation + P2P; used for pairing, access, contactless
pay; data via NDEF; powered by magnetic induction.
RFID: already covered; stress passive vs active, anti-collision, inventory at UHF.
Bluetooth:
Classic (BR/EDR): audio/data, piconet topology.
BLE (Bluetooth Low Energy): advertising/scanning, GATT services (Heart Rate, Battery), very low power;
range 10–100+ m; channel hopping; privacy features; 2M PHY, Coded PHY (long-range).
Zigbee:
IEEE 802.15.4 at 2.4 GHz (also sub-GHz variants), mesh networking (coordinator/router/end-device), low
data rate (20–250 kbps), low power sleeping nodes, profiles (Home Automation, Light Link).
Thread: IP-based (6LoWPAN) mesh sibling, works with Matter.
Wi-Fi:
802.11 b/g/n/ac/ax; high throughput (tens to hundreds Mbps), range 20–50 m indoors; power-hungry vs
BLE/Zigbee; supports WPA2/WPA3 security; ideal for cameras, gateways, OTA updates.
---
3) Explain wide(-area) communication technologies (when to choose what)
LPWAN (LoRaWAN, Sigfox): long range (2–15 km), payload ~12–51 bytes typical, battery life 5–10 years,
low cost; best for metering, environment sensing; not for real-time control/video.
Cellular IoT:
NB-IoT: deep coverage, very low bandwidth, long battery with PSM/eDRX, stationary sensors.
LTE-M (Cat-M1): mobility + voice (VoLTE), higher throughput than NB-IoT; wearables, asset tracking.
Cat-1/4/…/5G: higher data/video/low latency; gateways, mobile robots.
Satellite IoT: ubiquitous coverage for maritime, mining, deserts; higher latency/cost; small burst
messaging.
Choosing: consider coverage, power budget, throughput/latency, mobility, CapEx vs OpEx, regulatory
band, TCO.
---
4) CoAP protocol in detail
What it is: Constrained Application Protocol—RESTful web transfer over UDP for constrained
nodes/networks (RFC 7252).
Model & Methods: Client/Server like HTTP; methods GET/POST/PUT/DELETE; resources identified by
URIs.
Message types: Confirmable (CON), Non-Confirmable (NON), Acknowledgement (ACK), Reset (RST).
Header fields: version, type, token, code, message ID; options (Uri-Path, Content-Format, Accept,
Observe, Block1/2).
Key features:
1. Observe (server push/subscribe to resource changes).
2. Block-wise transfers for large payloads.
3. Multicast support.
4. Proxying and caching similar to HTTP.
Security: DTLS for CoAP/UDP; OSCORE for object-level E2E security.
Pros: tiny overhead, fits sleepy devices, maps naturally to REST.
Cons: UDP traversal issues, needs DTLS/OSCORE knowledge, less ubiquitous than HTTP.
Use: sensors/actuators, LwM2M management, local networks with gateways.
---
5) LwM2M (Lightweight M2M) in detail
What it is: OMA Spec for device management and telemetry for constrained devices, typically using
CoAP.
Functional blocks:
1. Bootstrap (initial credentials/config).
2. Registration (device → server keepalive).
3. Device Management & Service Enablement (read/write/execute resources, firmware update).
4. Information Reporting (observe/notify, attributes for thresholds).
Object model: hierarchical Object / Instance / Resource (e.g., Object 3 = Device, Object 5 = Firmware).
Reusable, standardized resource IDs.
Transport/Security: CoAP/UDP (also TCP/Non-IP bearer variants), DTLS; queue mode for sleepy devices.
Why use it: open standard, interoperable DM/OTA, efficient over constrained links (NB-IoT, LoRaWAN
via UDP gateways).
---
6) MQTT protocol in detail
What it is: Lightweight publish/subscribe messaging over TCP (sometimes over WebSockets) via a
broker.
Core concepts:
1. Topic hierarchy (plant/motor/1/vibration).
2. Clients publish/subscribe; broker routes messages.
3. QoS levels: 0 (at most once), 1 (at least once), 2 (exactly once).
4. Retained messages (last known value).
5. Last Will and Testament (LWT) to signal unexpected disconnects.
6. Sessions and persistent subscriptions.
Security: TLS, username/password, client certs; ACLs per topic.
Strengths: very low overhead, scalable fan-out, decouples producers/consumers, works well on
unreliable networks.
Limitations: requires broker, no built-in schema, ordering per-topic only.
Variants: MQTT-SN for non-TCP stacks (maps to UDP/802.15.4) using numeric topic IDs.
Typical use: telemetry uplink, commands downlink, event buses at edge and cloud.
---
7) Various data formats used in IoT
1. JSON: human-readable, ubiquitous; good with REST/MQTT; larger than binary.
2. CBOR: compact binary JSON-like; great with CoAP/OSCORE.
3. MessagePack: binary JSON alternative; small overhead.
4. Protocol Buffers (Protobuf): schema-based, compact, fast; needs compilation.
5. Avro: schema with dynamic resolution; big-data pipelines.
6. XML: verbose, but used where schemas/validation (XSD) matter.
7. CSV: simple logs; no schema.
8. SenML (RFC 8428): sensor measurement lists over JSON/CBOR (fields bn, bt, bu, v).
Example (SenML JSON):
[{"bn":"dev123/","bt":1710000000,"bu":"C"},{"n":"temp","v":24.8}]
---
8) Messaging/communication protocols in detail & which formats they support
Application layer (typical payload formats):
1. MQTT – carries JSON/CBOR/Protobuf freely as bytes.
2. CoAP – Content-Format option declares JSON/CBOR/SenML.
3. HTTP/REST – JSON/XML/Protobuf via media types.
4. AMQP – enterprise queues, routing; arbitrary payload; good for server-side.
5. DDS (Data Distribution Service) – real-time pub/sub, QoS-rich, used in robotics/industrial.
6. XMPP – XML-based messaging; IoT profiles exist.
7. WebSockets – full-duplex upgrade for browsers/gateways.
Transport/Network: TCP/UDP; for constrained 6LoWPAN over 802.15.4 compresses IPv6; DTLS/TLS for
security.
Matchups you can write:
MQTT + JSON/SenML for telemetry;
CoAP + CBOR/SenML for constrained sensors;
HTTP + JSON for REST APIs;
Protobuf over MQTT/HTTP for compact, typed payloads.
---
9) Web communication in IoT & explain any two web applications
Web comms used:
1. HTTP/HTTPS REST APIs for device APIs and cloud services.
2. WebSockets for real-time dashboards and command channels.
3. gRPC (HTTP/2) for efficient microservice comms.
4. GraphQL for flexible queries on IoT data.
5. Server-Sent Events (SSE) for one-way event streams to browsers.
Two example web applications:
a) Real-time Plant Dashboard: Browser uses WebSockets to subscribe to brokered events (via a
gateway), shows KPIs, lets engineers send commands (HTTP POST) to change setpoints. Role-based auth
via OAuth2.
b) Smart Parking Portal: REST APIs aggregate sensor slots; users view availability on map, pay online;
admins get analytics and anomaly alerts; mobile app uses HTTPS + push notifications.
---
Unit-3
1) Explain sensor technology in detail
Working chain: measurand → transduction → electrical signal → conditioning → digitization →
filtering/feature extraction → calibration/compensation.
Transduction types:
1. Mechanical: strain gauges, piezoelectric accelerometers, MEMS pressure.
2. Thermal: thermocouples, RTDs, thermistors.
3. Optical: photodiodes, LIDAR, IR thermopiles.
4. Magnetic: Hall effect, magnetoresistive.
5. Chemical/Bio: pH, gas (MOS, electrochemical), glucose biosensors.
6. Position/Proximity: encoders, ultrasonic, capacitive.
Key specifications: range, resolution, accuracy vs precision, sensitivity, linearity, hysteresis, drift, noise,
sampling rate, response time, cross-sensitivity.
Signal conditioning: Wheatstone bridges, instrumentation amplifiers, anti-aliasing filters, excitation,
temperature compensation, calibration (one-point, multi-point), sensor fusion (e.g., IMU—
accelerometer+gyro+mag).
Digital interface: I²C/SPI/UART, 1-Wire; timing, pull-ups, addressing.
Packaging & reliability: ingress protection (IP67/IP69K), conformal coating, EMC/ESD protection,
vibration and shock ratings, intrinsic safety (ATEX/IECEx) for hazardous zones.
Power & energy: duty cycling, low-power modes, energy harvesting (solar, vibration, thermal).
---
2) List various components of embedded computing
1. Processing: MCU (ARM Cortex-M, AVR, RISC-V), MPU (Cortex-A).
2. Clocking: crystal/RC oscillators, PLLs.
3. Memory: Flash/ROM (program), SRAM (data), EEPROM/FRAM (non-volatile), external SDRAM/Quad-
SPI flash.
4. Power: regulators (buck/boost/LDO), battery management/charging, PMIC, power domains, sleep
states.
5. I/O & Peripherals: GPIO, ADC/DAC, PWM, timers, watchdog, DMA.
6. Comms: UART/USART, I²C, SPI, CAN, USB, Ethernet, RF radios.
7. Sensors/Actuators: the real-world interfaces.
8. Security: secure elements/TPM, crypto accelerators, true RNG, secure boot, debug lock.
9. Software: bootloader, BSP, drivers, RTOS/bare-metal app, middleware stacks (TCP/IP, TLS, MQTT, file
system).
10. Dev & Test: toolchains, debuggers (SWD/JTAG), logic analyzers, oscilloscopes, emulators, CI for
firmware.
---
3) Bootloader & RTOS
Bootloader: the first code that runs after reset; initializes clocks/memory/peripherals, authenticates and
loads application images, and often provides firmware update (UART/USB/OTA) and recovery.
Key boot features:
1. Secure boot chain: verify signature (RSA/ECDSA), check version (anti-rollback).
2. A/B partitions: safe updates with fallback.
3. Device provisioning: write keys/certificates, lock debug.
4. Minimal drivers & comms: just enough to fetch new firmware.
RTOS (Real-Time Operating System): lightweight OS for deterministic task scheduling. Examples:
FreeRTOS, Zephyr, ThreadX, RTX.
Q: Difference between IoT and Cloud Computing
Answer:
IoT (Internet of Things) Cloud Computing
IoT is a network of physical devices (sensors, actuators, appliances) connected to the internet for data
collection and communication.
Cloud computing is the delivery of computing resources (storage, servers, software, networking) over
the internet on demand.
Focuses on connecting devices and collecting real-time data.
Focuses on processing, storing, and managing the data generated by IoT and other sources.
Deals with edge devices like smart homes, wearables, industrial machines, vehicles, etc.
Deals with data centers and virtual servers where data is processed and stored.
Works at the device and network layer of communication.
Works at the infrastructure and service layer of computing.
Generates huge amounts of raw data from sensors and devices.
Provides scalability and analytics to handle IoT-generated data.
Examples: Smart home (Alexa, smart fridge), connected cars, healthcare sensors. Examples: AWS,
Microsoft Azure, Google Cloud, IBM Cloud.
4) Various embedded platforms in detail
a) Arduino (Uno/Nano/MKR):
MCU 8-bit AVR or 32-bit ARM; simple IDE; rich shields.
Best for quick prototyping, education, basic sensors/relays.
Connectivity via Wi-Fi (MKR WiFi 1010), BLE, LoRa (MKR WAN).
Example (pseudo): read temp on analog A0 → publish via MQTT.
b) ESP32/ESP8266:
Low-cost Wi-Fi + BLE SoC; dual-core (ESP32), plenty of RAM; FreeRTOS-based SDK (ESP-IDF).
Great for Wi-Fi sensors, edge nodes; supports TLS, OTA, MQTT.
c) Raspberry Pi (Zero/4/5):
Linux SBC with GPIO; runs Python/Node/containers; camera support.
Used as gateways, vision analytics, edge servers; not ultra-low power.
d) BeagleBone Black/AI:
AM335x/AI SoCs with PRUs for real-time I/O; industrial control, robotics.
e) STM32 Nucleo/Discovery (Arm Cortex-M):
Professional MCU kits; HAL/LL drivers; Mbed/Zephyr support; rich peripherals (ADC, timers, CAN).
Ideal for low-power, certified industrial designs.
f) Arm Mbed OS ecosystem:
RTOS + networking + security stack; supports many MCUs; cloud connectors.
g) Intel Galileo/Edison (historical in syllabi):
Linux-capable boards; now discontinued but worth mentioning for history of maker SBCs in IoT.
How to compare (write as points): CPU class, RAM/Flash, power draw, OS (bare-metal/RTOS/Linux),
connectivity, peripherals, ecosystem, cost, and typical applications.
Mobile & tablet computing systems (bonus line): Android architecture—Linux kernel → HAL → Android
Runtime (ART) → Framework (Activities, Services) → Apps; useful for IoT HMI apps and gateways.