Seminar Kuzzle Intensiv – IoT-Plattform und digitale Zwillinge

Der Intensivpfad bildet eine vollständige IoT-Kette von Geräte- und Assetmodell über Protokollanbindung, Payload-Decoding, Messwertverarbeitung und Mandantentrennung bis zu Regeln, Alerts, Geofencing und Dashboards ab. Ein durchgängiger digitaler Zwilling dient als gemeinsame Praxisbasis. Theorie, Demonstration und Laborarbeit wechseln in kurzen Zyklen. Jeder technische Schritt wird durch eine Kontrollabfrage, einen Negativtest oder eine nachvollziehbare Zustandsprüfung abgeschlossen.

Inhaltsübersicht

• Zielgruppe und Voraussetzungen
• Didaktischer Zuschnitt
• Tag 1: IoT-Zielbild, Device- und Assetmodell
• Tag 2: Protokolle, Gateways und Payload-Decoding
• Tag 3: Multi-Tenancy und Flottenbetrieb
• Tag 4: Regeln, Alerts, Scheduler und Geofencing
• Tag 5: Dashboards, Gesamtintegration und Abnahme
• Praxisprojekt und Lernerfolgskontrolle

Zielgruppe und Voraussetzungen

Kapitelinhaltsverzeichnis

• Adressierte Rollen
• Erforderliche Vorkenntnisse
• Labor- und Arbeitsmittel
• Einstiegskontrolle

Zielgruppe: IoT-Architektur, IoT-Entwicklung, Plattformteams, Data Engineering, technische Produktverantwortung und Solution Engineering.

Voraussetzungen: Grundkenntnisse in JSON, APIs, Gerätekommunikation und Datenmodellierung; Programmiererfahrung für Decoder und individuelle Erweiterungen.

Zu Beginn werden Vorkenntnisse, Laborzugang, Namenskonventionen und Sicherheitsregeln geprüft. Fehlende Grundlagen werden als konkrete Vorbereitungspunkte dokumentiert; produktive Systeme und reale Zugangsdaten werden in den Übungen nicht verwendet.

Didaktischer Zuschnitt

Kapitelinhaltsverzeichnis

• Begründung der Dauer
• Arbeitsweise
• Dokumentationsstandard
• Qualitätssicherung

Begründung der Dauer: Fünf Tage sind erforderlich, um die sechs zugeordneten IoT-Einzelthemen in einer funktionierenden Ende-zu-Ende-Lösung zu verbinden. Die Obergrenze wird eingehalten, indem fortgeschrittene Sonderfälle als optionale Vertiefung markiert und nicht auf Kosten der praktischen Integrationskette behandelt werden.

Die Lerneinheiten folgen dem Muster Analyse, Aufbau, Funktionsnachweis, Fehlerfall und Wiederholung. Konfigurationen und Testdaten werden versionierbar gehalten. Entscheidungen werden mit Annahme, Alternative, Risiko und Prüfmethode dokumentiert. Dadurch entsteht neben dem fachlichen Verständnis ein direkt nutzbares Arbeitsverfahren.

1. Tag 1: IoT-Zielbild, Device- und Assetmodell

Kapitelinhaltsverzeichnis

• Use Case und Telemetrie
• Devices und Assets
• Measure Models
• Lebenszyklus

Dieses Kapitel verbindet Use Case und Telemetrie, Devices und Assets, Measure Models und Lebenszyklus. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Den IoT-Use-Case mit Geräten, Assets, Messwerten, Befehlen und Servicezielen eingrenzen: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Geräteidentität und fachliche Assetidentität bewusst trennen: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Measure Models mit Einheit, Datentyp, Wertebereich und Qualitätskennzeichen definieren: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Provisionierung, Zuordnung, Austausch und Stilllegung als Zustandsmodell beschreiben: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Testgeräte und Assets mit nachvollziehbaren Referenzen in der Laborumgebung anlegen: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Use Case und Telemetrie ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Devices und Assets erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Lebenszyklus lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Ein digitaler Zwilling für ein überwachtes Betriebsmittel wird modelliert und durch mehrere Testgeräte gespeist. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

2. Tag 2: Protokolle, Gateways und Payload-Decoding

Kapitelinhaltsverzeichnis

• HTTP, WebSocket und MQTT
• Gateway-Verantwortung
• Payload-Verträge
• Decoder und Fehlerkanal

Dieses Kapitel verbindet HTTP, WebSocket und MQTT, Gateway-Verantwortung, Payload-Verträge und Decoder und Fehlerkanal. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Protokoll und Verbindungsmuster anhand Energie, Netz, Latenz und Zustellanforderung auswählen: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Geräte- und Gateway-Identitäten mit sicheren Zugriffsrechten ausstatten: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Rohpayloads versionieren und Pflichtinformationen für Referenz sowie Zeitstempel festlegen: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Einen Decoder implementieren, der standardisierte Messwerte erzeugt: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Ungültige oder unbekannte Payloads in einen beobachtbaren Quarantänepfad leiten: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für HTTP, WebSocket und MQTT ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Gateway-Verantwortung erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Decoder und Fehlerkanal lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Simulierte Geräte senden zwei Payloadversionen, die dekodiert, normalisiert und einem Asset zugeordnet werden. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

3. Tag 3: Multi-Tenancy und Flottenbetrieb

Kapitelinhaltsverzeichnis

• Tenant-Modell
• Gruppen und Delegation
• Datenisolation
• Provisionierung im Umfang

Dieses Kapitel verbindet Tenant-Modell, Gruppen und Delegation, Datenisolation und Provisionierung im Umfang. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Mandanten- und Untermandantengrenzen aus Organisation sowie Verantwortlichkeit ableiten: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Gruppen, Profile und delegierte Verwaltungsaufgaben standardisieren: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Datenzugriffe und Realtime-Subscriptions gegen fremde Mandanten negativ testen: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Massenprovisionierung mit idempotenten Referenzen und Teilfehlerbehandlung umsetzen: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Onboarding, Wechsel und Offboarding eines Mandanten vollständig protokollieren: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Tenant-Modell ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Gruppen und Delegation erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Provisionierung im Umfang lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Zwei Mandanten mit delegierter Administration werden angelegt und ihre Datenisolation automatisiert nachgewiesen. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

4. Tag 4: Regeln, Alerts, Scheduler und Geofencing

Kapitelinhaltsverzeichnis

• Trigger und Bedingungen
• Workflows und Tasks
• Benachrichtigungen
• Zeit- und Raumlogik

Dieses Kapitel verbindet Trigger und Bedingungen, Workflows und Tasks, Benachrichtigungen und Zeit- und Raumlogik. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Geschäftsregeln aus Ereignis, Bedingung, Aktion, Priorität und Wiederanlauf zusammensetzen: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Schwellwerte mit Hysterese und Entprellung gegen Alarmfluten absichern: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Benachrichtigungen mit Quittierung, Eskalation und Deduplizierung gestalten: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Zeitgesteuerte Prüfungen und Wiederholungsaufgaben mit dem Scheduler planen: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Geofences definieren und Eintritt, Austritt sowie Positionsungenauigkeit testen: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Trigger und Bedingungen ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Workflows und Tasks erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Zeit- und Raumlogik lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Ein kombinierter Workflow erkennt Grenzwert und Geofence-Verletzung, erzeugt einen Alert und verfolgt die Quittierung. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

5. Tag 5: Dashboards, Gesamtintegration und Abnahme

Kapitelinhaltsverzeichnis

• Kennzahlen und Zielgruppen
• Standard- und Individualwidgets
• Realtime-Visualisierung
• Ende-zu-Ende-Test

Dieses Kapitel verbindet Kennzahlen und Zielgruppen, Standard- und Individualwidgets, Realtime-Visualisierung und Ende-zu-Ende-Test. Die Arbeitsschritte werden in einer isolierten Laborumgebung ausgeführt, protokolliert und gegen einen vorher festgelegten Sollzustand geprüft. Technische Entscheidungen werden so dokumentiert, dass Umsetzung, Review und Wiederholung ohne stille Annahmen möglich bleiben.

Schritt-für-Schritt-Anleitung

1. Schritt 1 – Kennzahlen aus konkreten Betriebsentscheidungen ableiten und Datenquellen zuordnen: Vor Beginn werden Zweck, Eingaben, Abhängigkeiten und ein messbares Erfolgskriterium notiert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
2. Schritt 2 – Ein Dashboard mit Karten-, Zeitreihen-, Status- und Tabellenansicht aufbauen: Die Konfiguration wird zunächst klein aufgebaut, anschließend gespeichert und durch eine unabhängige Abfrage kontrolliert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
3. Schritt 3 – Ein individuelles Widget mit stabiler Datenabfrage und Fehlerzuständen integrieren: Der Normalfall wird mit bekannten Testdaten ausgeführt; relevante IDs, Zeitpunkte und Rückgabewerte werden festgehalten. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
4. Schritt 4 – Realtime-Aktualisierung, Mandantensicht und große Datenmengen überprüfen: Mindestens ein typischer Fehlerfall wird absichtlich ausgelöst, beobachtet und ohne verdeckte manuelle Korrektur behoben. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.
5. Schritt 5 – Die komplette Kette vom Payload bis zum Alarm und Dashboard mit Abnahmedaten testen: Zum Abschluss wird der Sollzustand erneut geprüft und als wiederholbare Checkliste oder automatisierter Test gesichert. Der Bezug zum behandelten Kuzzle-Funktionsbereich wird anhand des laufenden Praxisfalls nachvollzogen.

Kontrollpunkte

• Der Sollzustand für Kennzahlen und Zielgruppen ist durch eine reproduzierbare Prüfung nachgewiesen.
• Fehlkonfigurationen in Standard- und Individualwidgets erzeugen verständliche und protokollierte Fehler.
• Die Umsetzung zu Ende-zu-Ende-Test lässt sich ohne persönliche Einzelkenntnisse wiederholen.
• Berechtigungen, Daten und Protokolle enthalten nur die für die Aufgabe erforderlichen Informationen.

Praxisaufgabe

Das IoT-Projekt wird als digitaler Zwilling mit Live-Daten, Regelverarbeitung, Alert und rollenabhängigem Dashboard abgenommen. Die Abnahme erfolgt anhand einer kurzen Demonstration, einer Konfigurationsprüfung und eines gezielt ausgelösten Fehlerfalls.

Praxisprojekt und Lernerfolgskontrolle

Kapitelinhaltsverzeichnis

• Projektauftrag
• Zwischenprüfungen
• Fehler- und Sicherheitsnachweis
• Technische Abnahme

Das Praxisprojekt verbindet die Kapitel zu einer konsistenten Laborlösung. Vor jedem Inkrement werden Ausgangszustand, Ziel, Eingaben und Abnahmekriterien festgelegt. Nach der Umsetzung folgen Funktionsprüfung, Negativtest, kurze Dokumentationskontrolle und Rücksetzung auf einen bekannten Zustand.

1. Projektauftrag schneiden: Ein fachlich begrenzter Anwendungsfall wird in Daten, Akteure, Schnittstellen, Berechtigungen und Betriebsanforderungen zerlegt.
2. Inkremente umsetzen: Die Kapitelbausteine werden schrittweise integriert; nach jedem Inkrement bleibt die Laborlösung lauffähig.
3. Fehler nachweisen: Mindestens ein Berechtigungs-, Daten-, Verbindungs- oder Konfigurationsfehler wird kontrolliert ausgelöst und diagnostiziert.
4. Abnahme durchführen: Eine technische Checkliste prüft Funktion, Sicherheit, Wiederholbarkeit, Protokollierung und Rückfallfähigkeit.
5. Lernstand dokumentieren: Offene Vertiefungen werden als priorisierte Aufgaben mit benötigtem Nachweis festgehalten.

Die Lernerfolgskontrolle besteht aus kurzen Verständnisfragen, beobachteten Laboraufgaben, einer Fehlersuche und der technischen Abnahme des Praxisprojekts. Bewertet werden nicht nur funktionierende Ergebnisse, sondern auch Begründung, Nachweis, sichere Fehlerbehandlung und Reproduzierbarkeit.