IoT - Chapter 2: IoT Systems

Summary: IoT Systems (Chapter 2)

1) What an “IoT system” is (vs. “IoT”)

• An IoT system is the complete set of hardware + software components needed to run a specific IoT application.
• Multiple IoT systems can exist in parallel (often one per application).
• The goal is to use the underlying IoT to realize the application while minimizing overhead by reusing components as much as possible.
• To reduce development/run costs, developers use an IoT system platform (market offerings that package reusable parts).

2) IoT system platforms: horizontal vs. vertical

Horizontal IoT platforms

• General-purpose, offered by large cloud providers.
• Provide broadly reusable services/components.
• Typical structure (conceptual “layers”):
  • Thin horizontal platform layer
  • Connects many types of IoT devices
  • Provides base services and lets applications implement more advanced, app-specific logic
• Advantage: tightly integrated with the provider’s cloud; easier to leverage cloud services.

Vertical IoT platforms

• Domain/application-specific, offered by domain experts.
• Less generic, but often provide:
  • Better analytics for that domain
  • More sophisticated ML capabilities
  • Specialized data models
• Tradeoff: optimized for one area—switching domains may require changing platforms.

Examples of horizontal platforms mentioned

• Amazon AWS IoT
• Microsoft Azure IoT Suite
• Google (IoT platform)
• Smaller examples: CARIOT (open/closed variants mentioned), Relayr (middleware platform)

3) Example: Microsoft Azure IoT (and Azure Sphere hardware)

• Azure IoT Suite is framed as an extension of the Azure cloud.
• Mentions components like:
  • IoT Hub
  • Event Bus
• Also includes Azure Sphere:
  • A ready-made hardware platform (device + software components)
  • Automatically integrates with Azure IoT Suite
  • Requires adding only embedded code
  • Emphasizes security guarantees and ongoing patching/support (described as a “24/7 security team” concept)

4) Software architecture questions + reference architectures (standards)

Because there is no single widely adopted “software stack,” IoT software design is framed around three core questions:

1. Which software functional blocks exist? (what capabilities/services exist)
2. Where do blocks execute? (placement on device/gateway/cloud)
3. How are blocks connected? (APIs + protocols)

Reference architectures/models

• Multiple competing standards exist; none is universally accepted.

ITU IoT Reference Model (2012)

• Layers for applications, service/application support, network, devices, plus management and security capabilities.

IoTA / EU project architecture model (2013)

• Similar core parts (communication, device, application, management, security) but reorganizes/splits responsibilities (e.g., “service organization,” “process management,” “virtual entity/digital twin,” “IoT service”).

Lecture’s course-oriented layered view

• Application-specific parts vs. generic parts
• Security always present
• Communication present
• Management/run-time optimization concept
• Emphasizes layered services to support both system operation and application development

5) Simplified IoT software stack used in the course

The lecture proposes a simplified stack with three parts:

1. Networking

   • Connecting devices/gateways/services using various communication technologies.
   • (Deep dive planned for Chapter 3.)

2. Data Management

   • Measurements, storage, publishing/querying data.
   • Often distributed due to scale (can’t centralize billions of devices).
   • Focus on energy/resource efficiency for battery-powered “smart things.”
   • (More detail planned for Chapter 4.)

3. Data Processing

   • Using stored data for predictions/ML/visualizations (visualization said to be skipped later in the course).
   • Includes tooling/APIs for programmers and ML techniques.

6) Data processing: human vs. algorithm, and processing levels

Who processes data

• Humans: mainly need visualization to detect trends manually.
• Algorithms/ML: need streaming APIs + ML libraries to detect trends automatically.

Processing levels

• Descriptive: observe what happened; may infer higher-level context/events from raw sensor signals
• Diagnostic: explain why it happened
• Predictive: anticipate what will happen (e.g., predictive maintenance)
• Prescriptive: decide/act (e.g., schedule a technician)

Human-in-the-loop at prescriptive level

• Even if systems decide automatically, legal/financial responsibility often requires a human approval step.

Example scenario: machine breakdown

• Descriptive: detect vibration and infer breakdown event risk/context
• Diagnostic: explain why it broke down
• Predictive: predict time to failure (e.g., “in a week”)
• Prescriptive: automatically schedule maintenance (often still approved by humans)

7) Software placement: cloud-based vs. edge-based vs. mesh-based

Components can be placed across:

• Smart objects (embedded devices)
• Gateways
• Online services / cloud

Resource tradeoff

• More compute from cloud → down to devices, but device count increases massively downward:
  • Cloud: fewer systems, more power
  • Devices: billions of nodes, constrained power

A) Cloud-based IoT (classical)

• Devices and gateways do minimal work:
  • Devices: sensing + update/sending
  • Gateways: forwarding
• Cloud hosts networking, data management, and data processing.

B) Edge-based IoT (modern trend)

• Gateways take over more responsibilities from the cloud:
  • Gateways communicate with each other
  • Gateways may store data and do pre-processing
  • Can run ML to derive higher-level context
• Cloud receives context rather than raw data.
• Motivation: reduce cloud load and overcome cloud capacity constraints.

C) Mesh-based IoT (future vision)

• Move computation further into the devices themselves:
  • Devices communicate directly (peer/mesh)
  • Devices perform part of data management + processing
  • A gateway/cloud remains available for fallback or heavy cooperation
• Benefits:
  • Even less work for gateways/cloud
• Limitations/realism:
  • Not all workloads fit mesh (e.g., city-wide distributed statistics may be inefficient).
  • Hierarchical partitioning may still be better (local clusters → gateway/partial → cloud).

8) Connectivity (APIs/protocols) as the “hardest” part

• The lecture highlights that how blocks are connected (APIs/protocols) is the most complex aspect, and it is addressed for the rest of the course.

9) How to choose an IoT platform (course goal)

• There are many platforms; they differ by internal technologies (protocols/APIs).
• Choosing well requires:
  • Understanding application requirements
  • Understanding platform technologies to estimate performance and developer effort
• The lecture notes current dominance of cloud-based platforms, with increasing adoption of edge, moving toward mesh.
• Example motivation for mesh/edge: reliability/security—cloud outages or attacks can break smart home functionality (e.g., lights don’t respond if cloud is down), which people won’t tolerate long-term.

---

Main speakers/sources (as referenced in the subtitles)

• Lecturer/host: the primary speaker; no name given in the subtitles

Mentioned external entities/sources

• ITU (International Telecommunication Union) – reference model mentioned
• EU researchers / iota project (2013) – reference architecture mentioned
• Cloud providers/platforms: Amazon (AWS IoT), Microsoft (Azure IoT Suite / Azure Sphere), Google
• Middleware/others: CARIOT, Relayr
• Textbook/class references: “lecture by embedded systems at EUD” (name not fully specified)