IoT & Telemetrie (Industrie 4.0)
iot
core_platform
🛡️ RLS Protected
IoT & Telemetrie (Industrie 4.0) — aus Code abgeleitete Prozess- und API-Dokumentation.
⚡ Werkstromen en levenscyclus
Dieses Modul folgt dem standardisierten transaktionalen CRUD- und Event-Lifecycle.
⚙️ Fachprozesse & Capabilities (System-Fachlogik)
Registrierte Fachoperationen und System-Capabilities dieses Moduls zur Steuerung von Workflows, Kaskaden und KI-Agenten.
| Capability & Schlüssel | Fachliche Bezeichnung | Ausführung / Coverage | Risikostufe & Freigabe | Effekte & Kaskaden |
|---|---|---|---|---|
IoT-Gerät mit ERP verknüpfen
capability:iot.asset.bind
Op:
iot.asset.bind
|
Intent:
bind_device_to_erp
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Gerätebefehl anfordern
capability:iot.device.command
Op:
iot.device.command
|
Intent:
request_command
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Gerätebefehl freigeben
capability:iot.device.command.approve
Op:
iot.device.command.approve
|
Intent:
approve_command
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
IoT-Geräte auflisten & erkennen
capability:iot.device.discover
Op:
iot.device.discover
|
Intent:
discover_devices
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
read_only
|
Keine Seiteneffekte deklariert |
Live-Zustand & Telemetrie lesen
capability:iot.device.read
Op:
iot.device.read
|
Intent:
read_device_state
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
read_only
|
Keine Seiteneffekte deklariert |
IoT-Gerät registrieren
capability:iot.device.register
Op:
iot.device.register
|
Intent:
register_device
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Telemetrie-Historie abfragen
capability:iot.metric.query
Op:
iot.metric.query
|
Intent:
query_metrics
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
read_only
|
Keine Seiteneffekte deklariert |
Telemetriedatum erfassen
capability:iot.telemetry.ingest
Op:
iot.telemetry.ingest
|
Intent:
ingest_telemetry
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
business_record
|
|
Digitalen Zwilling einsehen
capability:iot.twin.inspect
Op:
iot.twin.inspect
|
Intent:
inspect_twin
Quelle:
code:capability_registry
|
⚙️ Engine |
✓ Auto
Risiko:
read_only
|
Keine Seiteneffekte deklariert |
🧠 Fachprozess-Erzählung & Dual Knowledge Architektur
Synthese aus der ideologischen Blaupause (Meta-Fachlogik / Soll), der faktischen System-Implementierung (System-Fachlogik / Ist) und No-Code Customizing für KI-Consultants.
Der durchgängige Businessprozess im Detail (End-to-End Fließtext-Erzählung)
Der funktionale Ablauf von IoT & Telemetrie (Industrie 4.0) in der Plattform-Architektur
Das Modul iot erbringt zentrale Infrastruktur- und Steuerungsdienste im Monolithen. Jeder Aufruf durchläuft die zweistufige Sicherheitsarchitektur: Zunächst verifiziert der Session-Guard die Identität des Benutzers, woraufhin die PostgreSQL Row-Level-Security (RLS) aktiviert wird. Dadurch ist garantiert, dass Datenzugriffe mathematisch und physisch ausschließlich auf den authentifizierten tenant_id-Kontext beschränkt bleiben.
Mutationen und administrative Aktionen werden über transaktionale Services ausgeführt. Bei zustandsverändernden Operationen schreibt das System simultan in die betriebliche Zieltabelle und in die transaktionale Outbox. Asynchrone Worker greifen diese Signale ab und kaskadieren Ereignisse an nachgelagerte Module, ohne den synchronen HTTP-Pfad zu blockieren. Jeder Zugriff wird unveränderbar im Audit-Trail protokolliert.
Meta-Fachlogik: Ideologische Blaupause, Soll-Weltbild & Normen
Meta-Fachlogik: Sicherheits- und Plattform-Architektur
Basiert auf den Standards ISO/IEC 27001:2022 (Informationssicherheits-Managementsysteme), den BSI IT-Grundschutz-Bausteinen (APP.3.1 Webanwendungen, SYS.1.1 Allgemeiner Server) und Art. 32 DSGVO.
-
Mandantentrennung als Primärinvariante: Keine Mandantendaten dürfen jemals ohne
tenant_id-Filter geladen oder mutiert werden. Das Soll-Modell verlangt die Durchsetzung auf Datenbankebene via PostgreSQL RLS. -
Unveränderbarkeit von Sicherheitsereignissen: Protokolldateien, Logins, Berechtigungsänderungen und Konfigurationsmutationen müssen revisionssicher und schreibgeschützt festgeschrieben werden.
Systemische Fachlogik: Faktische Umsetzung in Centurio ERP & Capabilities
Systemische Fachlogik: Die faktische Umsetzung von IoT & Telemetrie (Industrie 4.0)
In Centurio ERP wird iot als modularer Monolith-Baustein unter app.modules.iot geführt. Die Autorisierung erfolgt über die zentrale RBAC-Engine mit Berechtigungs-Prüfung gegen Rollen und Berechtigungen. Datenänderungen lösen Outbox-Events aus, die über den PostgreSQL events-Bus verteilt werden. Idempotente Requests verhindern Replay-Angriffe und versehentliche Mehrfachausführungen.
KI-Consultant Leitfaden: Customizing- & No-Code-Konzept (Soll-Ist-Synthese)
KI-Consultant Blueprint: Customizing & No-Code Leitfaden für IoT & Telemetrie (Industrie 4.0)
-
No-Code Datenmodell-Erweiterung: Bei Bedarf können kundenspezifische Zusatzfelder im No-Code Customizing Studio angelegt werden.
-
Workflow-Integration: Administrative Ereignisse können als Trigger in der Canvas No-Code DAG Engine genutzt werden.
-
Sicherheitsregeln: Vor kritischen Systemänderungen sind Human-in-the-Loop Freigabegates einzurichten.
📚 Operative Prozessbegriffe & Transaktionsschnittstellen
- Systemaufrufe über REST-API oder Web-Portal
- Hintergrund-Worker und Cron-Jobs
- Ereignisse über den Outbox-Eventbus
- Ausführungs- und Protokolldaten
- Audit-Events im Revisionsjournal
- Veränderte Systemzustände
- security_event -> admin_alert: Alarmierung bei verdächtigen Zugriffen
- config_changed -> cache_invalidation: Sofortige Aktualisierung
- Manuelle Ausnahmebehandlung durch berechtigte Sachbearbeiter
- Revisionssichere Protokollierung im Audit-Trail
- Rollen- und Berechtigungsstufen exakt an Mitarbeiteraufgaben anpassen
- Sicherheitsrichtlinien für Passwörter und Sessions aktivieren
🗄️ Datamodellen & velden
🔌 Inleidende punten (UI&API's)
| Art | Metode | Eindpunt / pad | Titel & Zweck | Aanpassing |
|---|---|---|---|---|
| ⚡ REST API | GET | /api/v1/iot/devices |
list_devices
Semantic binding: inventory_only; mutation=False
|
iot
|
| ⚡ REST API | GET | /api/v1/iot/devices/{device_id} |
get_device_detail
Semantic binding: inventory_only; mutation=False
|
iot
|
| ⚡ REST API | GET | /api/v1/iot/twins |
list_digital_twins
Semantic binding: inventory_only; mutation=False
|
iot
|
| ⚡ REST API | GET | /api/v1/iot/twins/{twin_id} |
get_digital_twin_detail
Semantic binding: inventory_only; mutation=False
|
iot
|
| ⚡ REST API | GET | /iot |
iot_dashboard_page
Semantic binding: inventory_only; mutation=False
|
iot
|
| ⚡ REST API | POST | /api/v1/iot/bindings |
create_business_binding
Semantic binding: operator_surface; mutation=True
|
iot
|
| ⚡ REST API | POST | /api/v1/iot/commands |
request_device_command
Semantic binding: operator_surface; mutation=True
|
iot
|
| ⚡ REST API | POST | /api/v1/iot/commands/{command_id}/approve |
approve_device_command
Semantic binding: operator_surface; mutation=True
|
iot
|
| ⚡ REST API | POST | /api/v1/iot/commands/{command_id}/reject |
reject_device_command
Semantic binding: operator_surface; mutation=True
|
iot
|
| ⚡ REST API | POST | /api/v1/iot/devices |
create_device
Semantic binding: operator_surface; mutation=True
|
iot
|
| ⚡ REST API | POST | /api/v1/iot/telemetry/ingest |
ingest_telemetry_point
Semantic binding: operator_surface; mutation=True
|
iot
|
| ⚡ REST API | POST | /api/v1/iot/twins |
create_digital_twin
Semantic binding: operator_surface; mutation=True
|
iot
|
| ⚡ REST API | POST | /api/v1/iot/webhooks/{device_identifier} |
handle_iot_webhook
Semantic binding: operator_surface; mutation=True
|
iot
|
🛡️ Reglementarische en compliance
Dieses Modul unterliegt folgenden gesetzlichen, regulatorischen und Revisionsstandards:
- De Commissie heeft de Commissie verzocht om een aanvullende verordening te treffen.
- De volgende functies worden toegepast: