Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

Internet of Things

Introduction

The Internet of Things, usually abbreviated as IoT, is the engineering practice of connecting identifiable physical or virtual things so that they can sense, communicate, process information, and sometimes act on the physical world. A useful formal perspective from the International Telecommunication Union treats IoT as infrastructure that interconnects things through interoperable information and communication technologies. In practice, an IoT system is not just a collection of smart gadgets: it is a distributed cyber-physical system in which devices, networks, software services, data, people, and governance must work together.

For university students, IoT is best understood as a systems discipline. A successful design must balance sensing accuracy, computation, networking, energy use, latency, reliability, security, privacy, maintainability, interoperability, cost, and social impact. The same architectural choices that make a system efficient can create new risks, so technical design and responsible deployment belong together.

The image above illustrates a familiar IoT pattern: a physical device is connected through a network to software services, data analytics, and user-facing applications. As you study the course, look for this recurring flow: observe, communicate, compute, decide, and act.

The video introduces the main IoT components, including sensors, actuators, gateways, cloud services, analytics, and user interfaces. Use it as a visual overview before studying the technical layers in more depth.

Learning Goals

After completing this aiMOOC, you should be able to explain how IoT systems are structured, compare major connectivity and application protocols, reason about edge and cloud processing, design a data path from sensor to application, evaluate cybersecurity and privacy risks, and justify engineering choices for a real deployment. You should also be able to build or simulate a small IoT prototype and communicate its architecture and limitations clearly.

Foundations and System Architecture

Things, Devices, Sensors, and Actuators

A thing is an identifiable physical or virtual entity that participates in an IoT system. A device is the computing and communication equipment that makes participation possible. Many devices contain one or more sensors that measure physical quantities such as temperature, pressure, acceleration, light, sound, location, or electrical current. Actuators perform actions such as switching a relay, moving a motor, opening a valve, changing a display, or adjusting a control signal.

A sensor reading is not automatically useful information. Engineers must consider sampling rate, calibration, precision, accuracy, units, noise, drift, missing data, and the context in which a measurement was taken. Likewise, an actuator creates a physical consequence, so its commands often need stronger safety checks than ordinary telemetry.

A temperature-and-humidity sensor such as the DHT11 is a simple example of a sensing component. In a complete IoT system, its measurements might be read by a microcontroller, timestamped, validated, transmitted, stored, analyzed, and displayed.

A Layered View

There is no single mandatory IoT architecture, but a layered model is useful for reasoning:

Device and perception layer: Sensors, actuators, identifiers, microcontrollers, and embedded firmware interact with the physical world.
Connectivity layer: Wired and wireless networks move data between devices, gateways, and services.
Edge and gateway layer: Nearby computing filters, aggregates, translates, buffers, or analyzes data before it travels farther.
Platform and data layer: Services provide ingestion, storage, identity, rules, analytics, device management, and integration.
Application layer: Dashboards, mobile apps, control systems, APIs, and business processes use IoT data and capabilities.

A layered model helps you locate responsibilities, but real systems often blur the boundaries. A powerful device may perform edge analytics itself; a gateway may translate between non-IP field protocols and IP networks; an application may send commands back through the same infrastructure used for telemetry.

The Web of Things is a related approach that uses web architecture and standardized descriptions to improve interoperability among heterogeneous connected things. The W3C Web of Things Architecture 1.1 is a useful reference for studying how web concepts can sit above diverse IoT protocols and devices.

Identification and Embedded Computing

IoT devices need stable identities at several layers. A system may use hardware identifiers, cryptographic identities, network addresses, application identifiers, or combinations of them. RFID can identify tagged objects without giving every tag a full general-purpose computer.

More capable nodes use embedded computers. Microcontrollers are common when cost and energy budgets are tight, while a single-board computer can support richer operating systems, local databases, containers, or machine-learning workloads.

A board such as the Raspberry Pi can act as an edge node or gateway in prototypes and teaching laboratories. In production systems, the hardware choice should follow measured requirements for power, environmental conditions, interfaces, real-time behavior, lifecycle support, and security.

Connectivity and Networking

Choosing a Link Technology

Connectivity is an engineering trade-off rather than a contest for the fastest radio. Important variables include range, data rate, power consumption, topology, spectrum, mobility, infrastructure cost, interference, security features, and regulatory constraints.

Wi-Fi offers comparatively high throughput and easy IP integration but can consume more power than low-power alternatives. Bluetooth Low Energy is useful for short-range, battery-sensitive devices and provisioning. IEEE 802.15.4 is a low-power link technology used by several IoT stacks. LoRaWAN targets long-range, low-data-rate communication for battery-powered devices. Cellular technologies such as NB-IoT and LTE-M can provide managed wide-area coverage, while 5G can support additional industrial and low-latency use cases. Wired Ethernet and industrial field networks remain important when reliability, determinism, power delivery, or electromagnetic conditions favor cables.

IP and Constrained Networks

IP enables end-to-end addressing across heterogeneous networks. IPv6 is particularly important because of its enormous address space and its role in modern network architectures. 6LoWPAN adapts IPv6 for low-power wireless networks based on IEEE 802.15.4 by compressing headers and supporting fragmentation where links have small frame sizes.

Not every IoT device needs direct public Internet reachability. In fact, exposing devices unnecessarily increases attack surface. Gateways, private addressing, firewalls, brokers, and application-layer intermediaries are often used to control communication paths.

LoRaWAN Example

LoRaWAN uses a star-of-stars architecture in which end devices communicate by radio with gateways, gateways forward traffic toward network services, and application services consume device data. The protocol is optimized for small amounts of data from devices that may need long battery life rather than continuous high-bandwidth communication.

This Microsoft Developer video introduces LoRaWAN and The Things Network and shows why long-range, low-power networking can be attractive for IoT applications.

Messaging and Application Protocols

Telemetry, Commands, and Events

An IoT system commonly carries several kinds of application data. Telemetry reports measurements and state from devices. Commands request actions. Events represent notable occurrences, such as a threshold crossing or detected fault. Configuration changes parameters, while device-management traffic supports provisioning, health reporting, and software updates.

Designers should specify message schemas, timestamps, units, identifiers, quality indicators, and versioning rules. A temperature value of 23 is ambiguous unless the receiver knows whether the unit is degrees Celsius or Fahrenheit, when the measurement was taken, and which sensor produced it.

MQTT

MQTT is a lightweight client-server publish/subscribe messaging transport standardized by OASIS. Clients publish messages to named topics; subscribers express interest in topics; and a broker routes messages between them. This decouples message producers from consumers and supports many-to-many event-driven communication.

MQTT defines three delivery quality-of-service levels. QoS 0 aims for at-most-once delivery, QoS 1 for at-least-once delivery, and QoS 2 for exactly-once delivery between MQTT protocol peers. Higher assurance requires more protocol exchanges and state, so the best level depends on the consequence of loss, duplication, latency, bandwidth, and implementation complexity.

CoAP, HTTP, and APIs

CoAP is designed for constrained nodes and networks and follows a request-response model inspired by the web. It is commonly associated with UDP and can support observation of resources. HTTP is widely understood and integrates naturally with web services, but its overhead may be unsuitable for some constrained devices. IoT systems therefore often combine protocols: a sensor network may use CoAP or a field protocol near devices, while gateways and cloud applications expose HTTP APIs or publish events over MQTT.

The protocol choice should be justified from requirements. Avoid assuming that a protocol is secure merely because it is common; confidentiality, integrity, authentication, authorization, key management, and secure configuration must be designed explicitly.

Edge, Cloud, and Data Processing

Why Process Data at the Edge?

Edge computing places computation close to data sources. It can reduce latency, preserve operation during cloud outages, lower bandwidth consumption, and keep sensitive data local. Examples include detecting an abnormal vibration pattern beside a machine, summarizing one thousand sensor samples into a minute-level statistic, or rejecting obviously invalid measurements before transmission.

Cloud computing offers elastic storage and compute, centralized fleet management, large-scale analytics, integration with enterprise systems, and cross-site visibility. Many practical systems are hybrid: devices perform immediate control, edge nodes perform local aggregation and rules, and cloud services provide long-term analytics and coordination.

A good architecture asks where a decision should happen rather than assuming that every byte belongs in the cloud.

Data Pipelines and Semantics

A typical pipeline may include acquisition, validation, timestamping, buffering, transport, ingestion, stream processing, storage, analytics, visualization, and feedback. Failures can occur at every stage. A robust design therefore includes time synchronization, retry behavior, deduplication where necessary, back-pressure handling, schema evolution, observability, and clear ownership of data quality.

Data semantics matter as much as transport. Two systems can exchange bytes and still fail to interoperate if they disagree about units, identifiers, state models, or meaning. Standardized data models and machine-readable descriptions help reduce this semantic gap.

Digital Twins and AIoT

A digital twin is a digital representation associated with a physical asset, process, or system. In IoT, a twin may combine current telemetry, configuration, history, models, and predicted behavior. It can support simulation, maintenance, optimization, and operator training.

When Machine learning is deployed with connected devices, the combination is sometimes called AIoT. Useful applications include anomaly detection, predictive maintenance, adaptive energy control, and computer vision. However, machine-learning outputs inherit uncertainty and bias from data and models, so AI-based decisions require validation, monitoring, and appropriate human oversight.

Security, Privacy, and Safety

Security Is a Lifecycle Property

IoT security cannot be added only at the network boundary. A device may remain deployed for years, so secure design must cover manufacturing, onboarding, configuration, normal operation, software update, incident response, ownership transfer, and decommissioning.

The NIST IoT cybersecurity capability baseline emphasizes capabilities such as device identification, secure configuration, data protection, restriction of logical access to interfaces, secure software update, cybersecurity-state awareness, and device security. A 2025 NIST publication on trusted network-layer onboarding further emphasizes establishing trust before giving a device credentials to join a network.

Important design practices include unique device identities, authenticated onboarding, least privilege, encryption in transit where appropriate, protected credentials, signed update mechanisms, vulnerability handling, network segmentation, logging, secure defaults, and the ability to revoke access.

This NIST video connects IoT functionality with the need for cybersecurity. While watching, identify which risks belong to the device, network, service, manufacturer, operator, and user.

Threat Modeling

A Threat model asks what assets need protection, who might attack them, which trust boundaries exist, how attacks could occur, and what controls reduce risk. For a connected door lock, for example, the highest-impact risk may be unauthorized physical access rather than disclosure of ordinary telemetry. For an environmental sensor, availability and data integrity may matter more than secrecy. For medical or industrial control systems, safety consequences can dominate.

Security engineering should therefore be risk-based. Requiring the strongest control everywhere can waste energy and cost, but weak controls in a critical path can create unacceptable harm.

The Computerphile discussion highlights why IoT security is not only about privacy: cyberattacks can cause physical effects when networked software controls real machines.

Privacy, Ethics, and Governance

Connected devices can make data collection continuous and difficult to notice. Location traces, occupancy patterns, audio, video, energy use, and device interactions may reveal behavior that users did not expect to disclose. Responsible IoT design applies privacy by design principles such as data minimization, purpose limitation, meaningful notice, access control, retention limits, and careful treatment of secondary uses.

Governance also covers accountability. Who owns the data? Who may change device settings? Who is responsible for software updates? What happens when a manufacturer ends support? Can users delete data or transfer a device safely? These are architectural questions as well as legal and ethical ones.

Applications and Engineering Trade-offs

Smart Buildings and Cities

In a smart building, sensors can monitor temperature, humidity, occupancy, air quality, energy use, or equipment state. A building-management application may use this data to optimize ventilation and energy consumption. However, occupancy sensing can create privacy concerns, and automated control must respect safety constraints.

In smart-city systems, similar principles scale to transportation, water, lighting, waste, environmental monitoring, and infrastructure maintenance. The technical challenge is not only connecting more devices but managing heterogeneous systems, long lifecycles, procurement, cybersecurity, public accountability, and data governance.

Industry and Predictive Maintenance

Industrial IoT connects machines, sensors, controllers, and analytics to improve visibility and coordination. Vibration, temperature, current, and acoustic measurements can help detect unusual behavior before a machine fails. Yet industrial environments often require deterministic timing, safety certification, network segmentation, and strict change management. A cloud-only architecture may therefore be inappropriate for a safety-critical control loop even if cloud analytics remains useful for maintenance planning.

Agriculture, Health, and Logistics

Precision agriculture can combine soil, weather, position, and equipment data to guide irrigation or fertilization. Healthcare IoT can support remote monitoring and asset tracking but must protect highly sensitive data and avoid unsafe automated decisions. Logistics systems can use RFID, location, environmental sensors, and fleet telemetry to improve traceability and detect damaged or delayed goods.

The same technologies appear across domains, but requirements differ. An engineering team should begin with stakeholder needs and measurable constraints rather than copying an architecture from another application.

Historical and Future Perspectives

This older technology roadmap is useful as a historical artifact. Compare its expectations with present-day IoT: which ideas became routine, which shifted form, and which new concerns such as lifecycle cybersecurity, data governance, edge AI, and sustainability became more prominent?

Future IoT development increasingly overlaps with edge intelligence, digital twins, interoperable web descriptions, autonomous systems, and large-scale sensing. The core engineering question remains stable: how can distributed computational systems interact with the physical world in ways that are useful, dependable, secure, and responsible?

Case Study: A University Building Monitor

Imagine a university wants to monitor temperature, humidity, carbon dioxide, and room occupancy to improve comfort and energy efficiency. A possible prototype uses sensor nodes in rooms, a low-power wireless link, a gateway, MQTT messaging, a time-series database, and a dashboard.

A sound design begins with requirements. How often must each variable be measured? How quickly must alarms be delivered? What happens if connectivity fails? Which data could identify people indirectly? How long should data be retained? Who may access the dashboard? How will firmware be updated? How will a compromised node be removed from the network?

A strong architecture might aggregate data locally, transmit only necessary information, separate device and administrative networks, use authenticated devices, maintain update capability, log security-relevant events, and define a fallback mode if cloud services are unavailable. This example demonstrates why IoT design is a multidisciplinary systems problem rather than merely a sensor-programming exercise.

Standards and Primary References

ITU Internet of Things Global Standards Initiative: Formal IoT framing and standards context.
NIST IR 8259A: Core cybersecurity capabilities for IoT devices.
NIST trusted IoT onboarding and lifecycle management: Guidance on establishing trust when connecting devices to networks.
OASIS MQTT Version 5.0: Authoritative MQTT standard.
W3C Web of Things Architecture 1.1: Standard architecture for interoperable web-based descriptions of connected things.
LoRa Alliance developer resources: Standards and architectural material for LoRaWAN.

Interactive Tasks

Quiz: Test Your Knowledge

Which component converts a physical quantity into data that a computing system can process? (Sensor) (!Broker) (!Dashboard) (!Actuator)

What is the main role of an actuator in an IoT system? (Produce a physical action) (!Assign IP addresses) (!Store every message) (!Define radio spectrum)

Why is edge computing useful in many IoT systems? (It can reduce latency and bandwidth use) (!It removes all cybersecurity risks) (!It guarantees unlimited storage) (!It makes sensors unnecessary)

Which MQTT component routes published messages to interested subscribers? (Broker) (!Sensor) (!Actuator) (!Router table)

What does MQTT QoS 1 aim to provide? (At least once delivery) (!At most once delivery) (!Exactly once delivery) (!No network delivery)

Which technology is designed for long range low data rate communication for many battery powered IoT devices? (LoRaWAN) (!HDMI) (!SATA) (!DisplayPort)

What is a major purpose of device onboarding security? (Establish trust before network access) (!Increase sensor sampling noise) (!Remove device identities) (!Disable software updates)

Which practice best supports secure IoT lifecycle management? (Signed and maintainable software updates) (!Permanent default passwords) (!Unrestricted management interfaces) (!Shared public credentials)

Why are data semantics important for interoperability? (Systems must agree on the meaning of exchanged data) (!All devices must use the same processor) (!Every message must contain video) (!Wireless links must use one frequency)

Which question is most important when choosing an IoT architecture? (What requirements and risks must the system satisfy) (!Which device has the brightest display) (!Which protocol name is newest) (!Which cloud stores the most files)

Memory Game

Sensor	Measures a physical quantity and produces data
Actuator	Converts a control signal into a physical effect
Gateway	Connects local devices or protocols to other networks and services
Broker	Routes publish subscribe messages between clients
Edge computing	Processes data close to where it is generated
Digital twin	Represents a physical asset or system in digital form

Drag and Drop

Match the correct terms.	Topic
Sensing and actuation	Device layer
Data transport	Connectivity layer
Local filtering and control	Edge layer
Storage analytics and fleet services	Platform layer
Dashboards and domain workflows	Application layer

Match each system function to the architectural layer where it is most commonly placed. Then discuss one realistic case in which the function could move to another layer.

Crossword Puzzle

Sensor	Which component measures a physical property and produces data?
Actuator	Which component turns a control signal into a physical effect?
Gateway	Which component often links local device networks to wider networks?
Broker	Which MQTT component distributes messages by topic?
Latency	What term describes delay between an event and a response?
Firmware	What embedded software commonly requires secure update support?

LearningApps

Cloze Text

An IoT system begins when a

captures information about a physical or virtual state. A local

may translate protocols or aggregate readings before forwarding them. In MQTT, a

routes messages between publishers and subscribers. Processing near the data source is called

. A long-range low-power network option for many small sensor messages is

. Secure onboarding should establish

before a device receives network access. Maintainable devices need a protected software

mechanism throughout their lifecycle. Responsible data handling applies

so that the system collects only what its purpose requires.

Open-Ended Tasks

Easy

IoT inventory: Identify ten connected devices on a campus or in your daily environment, classify their sensors, actuators, connectivity, and users, and present the result as a one-page visual map.
Sensor data: Record a short series of temperature, light, or motion measurements with available hardware or a simulation, plot the data, and explain noise, sampling rate, and one possible source of error.
Network topology: Draw an annotated diagram of a simple sensor-to-dashboard data path and label every point where data is created, transmitted, transformed, stored, or displayed.
Data privacy: Interview a classmate about expectations for a hypothetical smart classroom, then write a short privacy notice that explains purpose, data collection, retention, and user choices.

Standard

MQTT: Build or simulate a publisher, broker, and subscriber, capture example messages, compare two MQTT quality-of-service choices, and justify which one fits your scenario.
Edge computing: Implement or model one processing task both at the edge and in the cloud, measure or estimate latency and network traffic, and explain the trade-off in a short technical report.
LoRaWAN: Design a low-power campus sensing network, create a coverage and gateway plan, estimate message frequency and battery constraints, and present the architecture in a short video.
Threat modeling: Create a threat model for a connected laboratory device, identify assets and trust boundaries, rank at least five risks, and propose controls with clear assumptions.

Advanced

Digital twin: Build a small digital-twin prototype or simulation that represents device state, history, and one predictive variable, then evaluate where model error could mislead operators.
Cybersecurity: Design a secure device lifecycle from manufacturing through decommissioning, including identity, onboarding, key management, updates, logging, revocation, and end-of-support policy.
Smart city: Visit or virtually investigate a real public IoT deployment, interview an operator or researcher if possible, and produce a policy and engineering review covering interoperability, accessibility, privacy, security, and public value.
Machine learning: Train or evaluate an anomaly-detection model on sensor data, document the preprocessing and validation process, and create a demonstration that explains false positives, false negatives, drift, and operational safeguards.

Learning Assessment

IoT architecture: Given a remote environmental monitoring scenario with intermittent connectivity and battery constraints, design an architecture and defend each placement of sensing, edge processing, storage, and user interaction.
Protocol selection: Compare MQTT, CoAP, and HTTP for a constrained device scenario and justify your preferred protocol using reliability, overhead, interaction model, security, and maintainability criteria.
Security engineering: Analyze a proposed device that uses one shared password and cannot receive updates, explain the lifecycle risks, and redesign the security model using explicit trust boundaries and controls.
Data governance: Evaluate a smart-building proposal that stores precise occupancy data indefinitely, then recommend a revised data strategy balancing operational value, privacy, accountability, and research needs.
Reliability engineering: Design the behavior of an IoT application during sensor failure, duplicated messages, network loss, clock drift, and cloud outage, and explain how users can distinguish degraded operation from normal operation.
Systems thinking: Transfer the architecture of the university building case study to an agricultural or industrial setting and explain which assumptions fail, which components remain useful, and which requirements change.

Evidence of Learning

Knowledge: You can explain device, network, edge, platform, application, messaging, security, privacy, and lifecycle concepts and relate them to one another.
Engineering skills: You can translate stakeholder needs into measurable requirements, choose components and protocols from explicit constraints, design data flows, and reason about failure modes.
Security and privacy skills: You can identify assets and trust boundaries, propose proportionate controls, plan secure onboarding and updates, and apply data minimization and governance principles.
Products: You can produce architecture diagrams, sensor datasets, prototypes or simulations, threat models, technical reports, videos, and documented design decisions.
Transfer achievement: You can adapt an IoT architecture to a new domain while recognizing that energy, safety, privacy, reliability, regulation, and lifecycle requirements may change.
Reflection: You can explain the limits of your design, identify unresolved risks and assumptions, and propose evidence that would be needed before real deployment.