Wichtig: Hart vs. weich echtzeitnah. Viele Edge-Linux-Setups erreichen “soft real-time” zuverlässig, aber Safety-Funktionen gehören in SPS/TSN und werden nur vom KI-System getriggert, nicht implementiert. Trennung von Safety und Quality-Intelligence ist Designpflicht.

4) Flottenmanagement: Tausende Edge-Geräte ohne Chaos
Skalierung beginnt bei Geräte-Identität und endet bei deterministischen Updates. Ein erprobtes Muster:

  • Geräteidentität und Vertrauensanker:
  • Hardware-gebundene Schlüssel (TPM/SE), mTLS überall.
  • Interne PKI mit kurzen Zertifikatslaufzeiten; Enrollment via Onboarding-Stationen (kein “Factory Default Password”-Wildwuchs).
  • Rollenbasierte Autorisierung für Topics/Endpunkte; Prinzip der minimalen Rechte.
  • Versions- und Konfigurationsverwaltung:
  • Immutable Images/Container, A/B-Partitionen mit Health-Checks und Auto-Rollback.
  • Deklarative Konfiguration (z. B. GitOps-Prinzipien), drift detection und Reconciliation-Loop on-device.
  • Canary-Rollouts in Wellen (1% → 10% → 100%), mit Telemetrie-Gates (Error-Rate, Latenz, Ressourcen).
  • Orchestrierung auf Edge-Nodes:
  • Leichte Container-Orchestrierung (k3s/microk8s) oder dedizierte Supervisoren für Geräteklassen.
  • Ressourcen-Isolation (cgroups), Priorisierung kritischer Dienste, Watchdogs.
  • OTA über segmentierte Netze, optional air-gapped via Wechseldatenträger mit kryptografisch signierten Paketen und attestierter Installation.
  • Observability:
  • Metriken, Logs, Traces lokal sammeln (OpenTelemetry/Prometheus) und on-prem aggregieren. Exporte nach “zentral” nur whitelisted.
  • Kardinalitäts-Disziplin: Label-Explosion vermeiden, ansonsten bricht Telemetrie unter Flottenlast.
  • SLOs definieren: Latenz p95/p99 der Pipelines, Erfolgsraten von Inferenzjobs, OTA-Rollout-Dauer, Mean Time to Recovery.
  • Sicherheits-Updates als First-Class-Citizen:
  • Security-Patches über denselben OTA-Kanal wie ML/Anwendungsupdates.
  • SBOM pro Release, signierte Artefakte, verifizierbare Builds; nur so bestehen sicherheitskritische Audits.

5) Hybrid-Architekturen: Edge-Inferenz, zentrales Training – ohne Souveränität zu verlieren
Der gängige Kompromiss: Entscheidungen am Rand, Lernen in der Mitte. Technischer Kern:

  • Datenreduktion am Edge:
  • Selektieren statt streamen: Nur “Interesting Events” (z. B. NOK-Fälle, Out-of-Distribution, driftsuspekte Fenster) und verdichtete Features exportieren.
  • Pseudonymisierung/Maskierung vor Export, konsequente Trennung von Identitäts- und Sensordaten.
  • On-Prem-Trainingscluster:
  • GPU-Knoten im Werksrechenzentrum für inkrementelles Training/Fine-Tuning. Artefakte werden versioniert (Model Registry), inklusive Trainingskonfiguration und Datensatz-Snapshots.
  • Automatisierte Eignungsprüfung: Gegen Golden-Set, Robustheitstests (z. B. Beleuchtungsvariation), Performance-Budgets.
  • Optional: Europäische Cloud nur für nicht-sensible Aggregation:
  • Wenn regulatorisch zulässig, können ausschließlich anonymisierte, aggregierte Statistiken in eine europäische Cloud für Flotten-Insights fließen.
  • Schlüssel verbleiben on-prem; Exportpfade sind einseitig (Pull nicht möglich) und auditiert.
  • Active Learning und Human-in-the-Loop:
  • Edge markiert Zweifelsfälle; Annotation findet on-prem im gesicherten Netz statt.
  • Feedback-Loop: Neue Labels triggern Retraining-Jobs; Rollout erst nach Canary-Verifikation.

6) Governance und Nachvollziehbarkeit für KI/LLM-Komponenten
Sobald KI nicht nur klassifiziert, sondern handelt (z. B. Maintenance-Agent, der Workflows und Tools orchestriert), braucht es Governance – speziell on-prem:

  • Policy-Grenzen und Tooling:
  • Whitelists für erlaubte Aktionen, Rate-Limits, Zwangsbestätigungen für risikoreiche Operationen.
  • Entscheidungsgraph pro Run: Prompt, Kontext, Tool-Aufrufe, Ergebnisse, finale Aktion – alles lokal protokolliert, revisionssicher.
  • Datenlokalität:
  • Vektorspeicher/RAG on-prem; Retrieval-Konnektoren nur zu lokal autorisierten Wissensquellen.
  • Keine Abhängigkeit von externen Foundation-Model-APIs bei sensiblen Vorgängen; stattdessen lokal gehostete Modelle oder dedizierte On-Prem-Model-Serving-Layer.
  • Evaluierung und Red-Teaming:
  • Szenario-basierte Tests mit vordefinierten Risikoprompts, Messung von Halluzinations- und Tool-Misuse-Raten.
  • Gatekeeping vor Rollout: Policies als Code, automatisierbare Checks; Fail-Closed bei Unsicherheit.

Anmerkung: Genau dieses Observability- und Governance-Thema adressieren wir bei AlpiType produktiv – weil ohne Auditfähigkeit jede “Agentik” in Industrieumgebungen nicht zulassungsfähig ist.

7) Sicherheitsarchitektur: Zero Trust innerhalb des Standorts
Werksnetze sind keine sicheren Zonen. Zero-Trust-Prinzipien gelten auch on-prem:

  • Ende-zu-Ende-mTLS mit gegenseitiger Authentisierung; keine impliziten Vertrauenszonen.
  • Fein granulare Netzwerksegmente, Policy Enforcement Points nahe am Workload.
  • Remote Attestation: Bevor ein Gerät Keys oder Konfiguration erhält, attestiert es seinen Zustand (Messwerte, Signaturen). Nur attestierte Zustände bekommen Zugangstoken.
  • Secrets-Management: On-Prem-KMS/HSM; kurze Token-Lebensdauer; kein “Shared Secret” über die Flotte.
  • Supply-Chain-Hygiene: Gepinnte Registries, Content Trust (Signaturen), minimalistische Base-Images, SBOM-Validierung beim Deploy.

8) Datenmodellierung und Schema-Evolution
Skalierung bricht meist am Datenmodell, nicht an der Rechenleistung:

  • Einheitliche Namensräume: site/line/station/device metric/event; Topics/Streams spiegeln physische Hierarchien.
  • Schemas als Verträge: Avro/Protobuf in Kafka mit Schema Registry; kompatible Evolution (backward/forward).
  • Zeitreihen-Grundlagen: Einheitliche Zeitbasis (NTP/PTP), Uhrendrift-Monitoring. Ohne konsistente Zeitstempel sind Analysen wertlos.
  • Idempotenz und Deduplication: Producer-IDs, Sequenznummern; Konsumenten bauen deterministische Zustände wieder auf.

9) Betriebsmodelle: Wer betreibt was?
Souveränität heißt nicht “alles selbst machen”, sondern “Kontrolle behalten”:

  • Kunde betreibt: Edge-Nodes, Broker (MQTT), On-Prem-Kafka/DBs, KMS/HSM.
  • Partner betreibt unterstützend: Tooling für OTA, Observability, Modellregistries – aber innerhalb der Kundendomäne oder in europäischer Cloud mit klarer Datenabgrenzung.
  • Vertragswerk: Schlüsselhoheit beim Kunden, Exit-Strategien (Datenformate offen, keine proprietären Lock-ins), Reproduzierbarkeit dokumentiert.