IOAS Security Cluster (IOASC)

Eine intelligente Lösung, die bestehende Smart-City-Systeme, IoT-Netze und Sicherheitssysteme von Städten und Gemeinden integriert — mit bis zu 242 TOPS KI-beschleunigter Analytik, 462+ Machine-Learning-Modellen und horizontal skalierbarer paralleler Infrastruktur.

Zusammenfassung

IOAS Security Cluster (IOASC) ist eine verteilte Plattform für die Echtzeit-Bildanalyse aus städtischen Kamerasystemen, die die bestehende Infrastruktur von Smart-City-Lösungen, IoT-Sensornetzen und Sicherheitssystemen von Städten und Gemeinden in der Slowakei integriert. Architektonisch kombiniert sie einen dedizierten KI-Hardware-Beschleuniger mit 240 TOPS Leistung, eine Bibliothek von mehr als 462 Machine-Learning-Modellen und ein paralleles/dezentralisiertes Compute-Framework, das einer einzelnen physischen Einheit die Verarbeitung von bis zu 19 gleichzeitigen Kamerastreams mit einer End-to-End-Latenz unter 80 ms erlaubt. In diesem Artikel werden die drei Säulen, die im ursprünglichen Konzept nur angerissen wurden, im Detail ausgearbeitet: (1) die Modellerstellungs-Pipeline, (2) Hochleistungsrechnen (HPC) und (3) parallele und verteilte Rechenstrategien.

1. Cluster-Architektur

IOASC ist eine intelligente Lösung zur Integration bestehender Smart-City-Systeme, IoT-Netze und Sicherheitssysteme von Städten und Gemeinden in der Slowakei. Mit Komponenten des IOASC-Clusters lassen sich modernste Datenanalyse- und Verarbeitungsmethoden auch in generationsalten Systemen einschließlich der bestehenden Infrastruktur einsetzen. Die Komponenten des Systems können Daten aus Kamerasystemen mit bis zu 242 Tera Operations Per Second (TOPS) parallel analysieren und so eine schnelle und intelligente Lösung für fortgeschrittene Bildanalyse über bereits installierte Kameras bereitstellen.

Das System implementiert mehr als 462 Modelle zur Datenverarbeitung, sodass folgende qualitativen Parameter und ihre Wechselbeziehungen in Echtzeit identifiziert werden können:

• Kennzeichen, Werksmodell und Fahrzeugfarbe
• Fahrzeugklassifikation — Krankenwagen, Feuerwehr, Polizei
• Verhaltensanalytik der Verkehrsteilnehmer — Fußgänger, Radfahrer
• Identifikation von Verhaltensparametern in einem Perimeter (z. B. Subjekt in schwarzer Jacke, Mann 35 – 45 Jahre, mit Hund, mit Schirmmütze); Definitionsmenge der Zeugen eines Objekts
• Messung physischer Parameter von Objekten — Temperatur, Höhe, Trajektorien
• Vorfallserkennung — gewalttätiges Verhalten, Unfall
• Verhaltensanalytik der Trajektorien von Verkehrsteilnehmern
• qualitative Nachverarbeitung von Kameramaterial (Denoising)

Auf Basis der Anwendung einzelner Modelle lässt sich jeder Typ von Analytikfunktion mit Machine Learning erstellen — alles in Echtzeit. Die einzelnen physischen Einheiten werden zu einem Cluster verbunden, der die so identifizierten Daten aggregiert und Korrelationsfunktionen höherer Ordnung berechnet:

• statistische Parameter — Anzahl Pendler, Anzahl der Durchfahrten durch eine Stadt/Gemeinde
• Fahrzeugverhalten
• Verkehrsverstöße — Section Speed, Trajektorienverletzung, Rotlichtfahrt, Vorfahrtsverletzung, Nichtanhalten am STOP-Schild u. a.
• Vorhersage und Modellierung von Verkehrssituationen
• Identifikation markierter oder beobachteter Fahrzeuge mit Korrelations- und Vorhersagefunktionen
• Identifikation von Fahrzeugen mit Trajektorienabweichung — Alkoholgenuss, Fahrzeugstörung

Die genannten Parameter werden vom System über alle angeschlossenen Cluster-Knoten ausgewertet; die Dezentralisierung der Rechenleistung garantiert Echtzeitbetrieb auch bei hunderten parallelen Streams. Einzelne Modelle werden rekursiv vom System selbst und von Operatoren (typischerweise Beamten der Stadtpolizei) getaggt, was eine kontinuierliche Klassifikator-Anpassung und stetig steigende Übereinstimmung der Ausgaben mit der Realität ermöglicht.

2. Modellerstellung: Machine-Learning-Pipeline

Die Bibliothek mit 462+ Modellen ist kein statisches Artefakt — sie ist Produkt eines kontinuierlichen MLOps-Zyklus, den IOAS für jeden Kunden betreibt. Die Pipeline besteht aus sieben Stufen, jede unabhängig containerisiert und horizontal skalierbar.

2.1 Datenerfassung und Kuratierung

Eingabedaten kommen aus drei Quellen:

1. RTSP/ONVIF-Streaming aus den bestehenden Kamerasystemen des Kunden — IOASC unterstützt H.264, H.265 (HEVC) und AV1 mit automatischer Erkennung und Wiederherstellung bei inkonsistenten Keyframes oder Paketverlust.
2. Kuratierte Korpora — für Standarddomänen (Fahrzeuge, Fußgänger, Kennzeichen) hält IOAS interne annotierte Datensätze mit über 2,4 Mio. gelabelten Frames vor (Stand 2026 Q2), erhoben aus realen slowakischen und mitteleuropäischen Stadtumgebungen (verschiedene Lichtverhältnisse, Wetterlagen, Jahreszeiten).
3. Operator-Historie — Stadtpolizeien und integrierte Rettungsdienste liefern Feedback in Form von Detektionskorrekturen, was die Active-Learning-Queue (Abschnitt 2.4) erweitert.

Vor dem Training durchlaufen alle Daten eine Deidentifikationsschicht im Sinne von DSGVO Art. 35 — Gesichter unbeteiligter Personen werden unkenntlich gemacht, Kennzeichen werden nicht als Rohzeichen, sondern als One-Hot-Embeddings für Downstream-Tasks gespeichert.

2.2 Modellarchitekturen

Die IOASC-Bibliothek gruppiert Modelle in sieben Familien nach primärer Aufgabe:

Für jede Familie hält IOAS 3 – 5 Versionen in unterschiedlichen Genauigkeit ↔ Latenz-Verhältnissen: *-tiny für Edge-Knoten mit knappem Budget, *-base für Standardeinsatz, *-large für kritische Standorte (zentrale Kreuzungen, Eingänge öffentlicher Gebäude).

2.3 Trainings­infrastruktur

Das Training läuft in einer dedizierten Training Cell der IOAS-Infrastruktur mit folgenden Parametern:

• 8× NVIDIA H100 SXM verbunden über NVLink + InfiniBand 400 Gbps
• Verteiltes Data-Parallel-Training über PyTorch FSDP (Fully Sharded Data Parallel) mit shardiertem Optimizer-State (ZeRO Stage 3)
• Mixed-Precision BF16 / FP8 (Hopper Sparsity) — 2,1 – 2,8× schnellere Konvergenz als FP32
• Gradient Accumulation mit effektiver Batchgröße 256 – 1024 je nach Modell
• Stochastic Weight Averaging (SWA) in der Schlussphase für robustere Gewichte
• Pro Experiment Hyperparameter-Sweep über Optuna mit ASHA-Scheduler

Das Training eines einzelnen Produktionsmodells dauert zwischen 6 Stunden (LPRNet-Fine-Tune) und 5 Tagen (RT-DETR-L auf dem hauseigenen 2,4-Mio.-Frame-Datensatz).

2.4 Deployment-Optimierung (Model Serving)

Trainierte Modelle durchlaufen vor dem Edge-Einsatz eine dreistufige Kompression:

1. Strukturiertes Pruning — Entfernung von 30 – 60 % redundanten Gewichten über magnitude- und Taylor-Expansion-Kriterien; reduziert den Speicher-Footprint bei > 99 % erhaltener Genauigkeit.
2. Post-Training INT8-Kalibrierung — Kalibrierungsdatensatz aus 1024 echten Frames, per-channel symmetrische Quantisierung; typischer mAP-Verlust < 0,8 %.
3. Layer Fusion + Graph-Optimierung — Fusion von Conv+BN+ReLU, Eliminierung redundanter Reshape-Operationen, ONNX → TensorRT/Hailo-RT Konvertierung.

Resultat: 2,2 – 4,7× schnellere Inferenz bei 4× kleinerem Speicher-Footprint im Vergleich zum ursprünglichen FP32-Modell.

2.5 Active Learning und kontinuierliche Anpassung

In der Produktion erzeugt jede Detektion mit einer Konfidenz unter 0,75 automatisch einen Active-Learning-Kandidaten, der in die Annotation-Queue eingereiht wird. Der Systembetreiber (typischerweise ein Stadtpolizist) erhält über eine Web-Annotationskonsole die Liste unsicherer Fälle und labelt sie als true positive / false positive / false negative / re-classify. Diese Korrekturen:

• beeinflussen sofort die Per-Tenant-Rules-Engine (z. B. „dieses Fahrzeug mit Kennzeichen XYZ123 ist ein Feuerwehrfahrzeug, immer als Emergency klassifizieren”),
• akkumulieren in einem Retraining-Batch, der alle 7 – 30 Tage (je nach Datensatzgröße) zu einem neuen inkrementellen Fine-Tuning-Zyklus konvergiert,
• werden für cross-tenant federated updates anonymisiert (Abschnitt 2.6).

Drift-Erkennung läuft 24/7 — überwacht die Verteilung der Konfidenzwerte, die False-Positive-Rate je Kategorie und je Kamera. Wenn F1 unter den Schwellwert fällt (typisch 0,92 absolut oder −3 σ vom Baseline), eskaliert das System automatisch an das IOAS-MLOps-Team.

2.6 Federated Learning über Kunden hinweg

Um die Generalisierung über verschiedene Städte zu maximieren (Bratislava, Trenčín, Žilina, Košice — unterschiedliche Architektur, Kameras, Verkehrsmuster), führt IOAS Federated-Learning-Runden nach dem FedAvg-Schema mit Differential Privacy (DP-SGD, ε ≤ 3,0) durch:

[Kunde 1: lokales Update] ─┐
[Kunde 2: lokales Update] ─┼─→  [Aggregator (IOAS HQ)]  ─→  [Globales Modell v0.N+1]
[Kunde 3: lokales Update] ─┤                                       │
                           ...                                     ▼
                                                       [Verteilung zurück an Kunden]

Rohdaten verlassen den Perimeter des Kunden nicht — gesendet werden nur verrauschte Gradienten und Update-Größen-Metadaten. Das wahrt die regulatorische Konformität mit DSGVO und dem Cybersicherheitsgesetz.

3. Hochleistungsrechnen (HPC)

3.1 Hardware-Beschleunigung (240 TOPS)

Das Herz jedes IOASC-Knotens ist ein KI-Hardware-Beschleuniger mit deklarierten 240 TOPS @ INT8, einsetzbar in zwei physischen Formfaktoren:

Der Beschleuniger stellt eine niedrigschichtige C/C++-Runtime-API mit Primitiven für Tensor-Allokation, Kernel-Launch, asynchronen Memcpy und Synchronisation über CUDA-Stream-ähnliche Queues bereit. Die höhere Schicht (ioasc-runtime) liefert eine Zero-Copy-DMA-Verbindung zwischen Kameradecoder (NVDEC oder dediziertem Hardwareblock) und Inferenz-Engine — der gesamte Frame-Lebenszyklus verlässt den Device-Speicher nicht, bis das analytische Payload ausgegeben wird.

Der Beschleuniger unterstützt:

• Datentypen INT8 / INT4 / FP16 / BF16 (FP8 in der nächsten Generation)
• Sparse Tensor Cores für 2:4-Block-Sparse-Matrizen (1,8× Boost auf passenden Modellen)
• Graph-Compiler (interne Version basierend auf MLIR/IREE) mit automatischer Layer Fusion
• Multi-Tenancy — Virtualisierung der Recheneinheiten für parallelen Betrieb mehrerer Modelle ohne Context-Switch-Overhead

3.2 Speicher- und Netzwerkarchitektur

   ┌─────────────────────────────────────────────────────┐
   │ IOASC-Knoten                                        │
   │                                                     │
   │   [NPU 240 TOPS]  ←──→  [HBM3 1,2 TB/s]              │
   │         ↕                                           │
   │   [CPU-Host: 16-Kern ARMv9 / x86]                   │
   │         ↕                                           │
   │   [DDR5 dual-channel, 51 GB/s]                       │
   │         ↕                                           │
   │   [NVMe Gen4 SSD 4 TB]   (Modell-Cache + Metadaten)  │
   │         ↕                                           │
   │   [10 GbE Management]   [100 GbE Backbone (Cluster)] │
   └─────────────────────────────────────────────────────┘

Die Speicherhierarchie ist auf Streaming-Workloads optimiert: NPU arbeitet ausschließlich mit Tensoren in HBM3 (geringe Latenz, hohe Bandbreite), CPU hält Metadaten und Koordinationslogik in DDR5, NVMe dient als lokaler Cache für Modellgewichte (Kaltstart aus NVMe ~ 800 ms pro Modell, Warm Switch < 5 ms).

Das Inter-Node-Netzwerk verwendet ein 100-GbE-Backbone mit RDMA (RoCE v2) — Knoten-zu-Knoten-Tensortransfer läuft über iWARP oder RoCE im Zero-Copy-Modus und eliminiert TCP/IP-Overhead bei verteilter Inferenz (Abschnitt 4.4).

3.3 Energieeffizienz und Thermal Management

Für 24/7-Outdoor-Betrieb in IP66-Gehäusen optimierte IOAS das Thermaldesign:

• Power Envelope pro Knoten: 65 W idle, 90 W typische Inferenzlast, 120 W peak
• Energieeffizienz: 2,7 – 3,1 TOPS/W bei INT8 (vergleichbar mit NVIDIA Jetson AGX Orin 64 GB)
• Passiver Kühlkörper + 2 redundante PWM-Lüfter (40 mm, 4-pin, hot-swap)
• Thermal Throttling bei 85 °C Die-Temperatur — Degradation von 240 → 180 TOPS, 0 % Datenverlust (Frame-Queue absorbiert den Latenz-Spike)
• MTBF 95 000 Stunden (10,8 Jahre) bei 35 °C Umgebungstemperatur

3.4 Edge vs. zentrales Compute — Latenzbudget

Für Echtzeitanwendungen ist das End-to-End-Latenzbudget vom physischen Ereignis bis zur Alarmgenerierung kritisch. IOASC hält den Großteil der Inferenz am Edge:

Edge-First-Design liefert 3 – 5× geringere Latenz und eliminiert die Abhängigkeit von der WAN-Konnektivität — bei Internet-Ausfall setzt der Cluster-Knoten die lokale Analyse fort und liefert Alarme über GSM/LTE-Backup-Kanäle.

4. Paralleles Rechnen

Parallelität wirkt in IOASC auf fünf Ebenen gleichzeitig, wodurch die NPU bei heterogenen Workloads ausgelastet werden kann.

4.1 Stream-Level-Parallelität

Die Basiskonfiguration eines einzelnen Knotens bedient 19 gleichzeitige Kamerastreams mit 25 FPS — also insgesamt 475 Frames/s. Streams werden multiplext über:

• Asynchroner RTSP-Demultiplexer (FFmpeg-basiert, eigener Zero-Copy-Port)
• Per-Stream-Frame-Queue mit Back-Pressure (Drop-Newest unter Überlast)
• Dynamisches Batching — die Runtime bildet Inferenz-Batches von 1 – 16 Frames anhand der aktuellen Queue-Tiefe (tiefere Queue → größerer Batch, bessere GPU-Auslastung, leicht höhere Latenz)

4.2 Pipeline-Parallelismus

Die Verarbeitung eines Einzelframes ist auf fünf Pipeline-Stufen verteilt, die parallel auf verschiedenen Frames laufen (klassische Producer-Consumer-Kette):

   t=0 ms       t=5 ms       t=10 ms      t=15 ms      t=20 ms
   ┌──────┐
   │ FR-1 │ Decode
   └──┬───┘
      ↓     ┌──────┐
            │ FR-1 │ Preprocess     ← FR-2: Decode
            └──┬───┘
               ↓     ┌──────┐
                     │ FR-1 │ Inferenz   ← FR-2: Preprocess  ← FR-3: Decode
                     └──┬───┘
                        ↓     ┌──────┐
                              │ FR-1 │ Postprocess  ← FR-2: Inf  ← FR-3: Pre  ← FR-4: Dec
                              └──┬───┘
                                 ↓     ┌──────┐
                                       │ FR-1 │ Publish
                                       └──────┘

Im stationären Zustand befinden sich 5 Frames gleichzeitig in der Pipeline auf verschiedenen Stufen. Der Durchsatz entspricht der langsamsten Stufe (typischerweise Inferenz), nicht der Summe aller Stufen — das ergibt eine 2,8 – 3,4× Beschleunigung gegenüber synchroner Verarbeitung.

4.3 Modell- und Datenparallelität

Für große Modelle (RT-DETR-L, MViTv2-L), die nicht in eine HBM-Partition passen, unterstützt IOASC:

• Datenparallelität — jede NPU-Partition hält eine identische Kopie des Modells, der Batch wird zwischen ihnen aufgeteilt (Default für die meisten Detektionsmodelle).
• Tensor-Parallelität — Layer mit großen Matmuls (Transformer Attention, MLP-Block) werden entlang der Column-wise- oder Row-wise-Dimension geteilt, Gradienten via NCCL all-reduce aggregiert.
• Pipeline-Parallelität (Model Partitioning) — bei Ultra-Large-Modellen werden die per-Layer-Stufen über NPU-Partitionen verteilt, jeder Batch wird in Mikro-Batches zerlegt, die durch die Pipeline fließen (im Stil von GPipe / PipeDream).

Die Strategie wird pro Modell zur Compile-Zeit anhand von Gewichtsgröße, Batch-Size und verfügbaren NPU-Partitionen festgelegt.

4.4 Inter-Node-Sharding des Clusters

Im Skalierungseinsatz, wenn eine Stadt z. B. 12 IOASC-Knoten mit 228 Streams (12 × 19) betreibt, realisiert der Cluster funktionales Sharding — statt dass jeder Knoten alle 462 Modelle ausführt, sind die Modelle verteilt:

   Knoten A: ANPR, Fahrzeug­klassifikation              (Modelle 1-128)
   Knoten B: Fußgänger- + Radfahrer­verhalten            (Modelle 129-238)
   Knoten C: Vorfalls- + Gewalt­detektion                (Modelle 239-310)
   Knoten D: Re-Identifikation + Cross-Camera Tracking  (Modelle 311-396)
   Knoten E: Anomalie + Denoising-Postprocess           (Modelle 397-462)

Jeder Knoten publiziert seine Analytik-Ausgaben als typisierte Events auf dem Cluster-Event-Bus (NATS JetStream mit persistentem Storage). Korrelationsfunktionen höherer Ordnung (Abschnitt 1) laufen auf einem Aggregations-Knoten, der die relevanten Topics abonniert und folgendes anwendet:

• Multi-Camera Person Re-Identification — Verknüpfung von Tracking-IDs über überlappende Kamerabereiche
• Trajectory Fusion — Kalman-Filter-Zusammenführung von Positions-Updates aus mehreren Blickwinkeln
• Temporal Anomaly Detection — Erkennung von Abweichungen vom historischen Verhalten (Zeit, Ort)
• Cross-Modal Correlation — Verknüpfung von Kameradetektion mit IoT-Sensoren (akustisch, vibrationsbasiert)

4.5 Asynchrone Komposition analytischer Funktionen

Analytikfunktionen höherer Ordnung werden als DAG (gerichteter azyklischer Graph) von Inferenzoperationen modelliert, die der Cluster-Orchestrator parallel plant, wo immer keine Datenabhängigkeit besteht:

   Frame ──→ Detektion ──┬─→ Tracking ──┬─→ ReID ────┐
                         │              │            ├─→ Multi-Camera Fusion
                         │              └─→ Behaviour┘
                         │
                         └─→ Klassifikation ─→ ANPR ─→ Fahrzeug-DB-Lookup

Der Orchestrator (interne Komponente auf Basis von Apache Arrow Flight + eigener DAG-Scheduler) startet jeden DAG-Knoten, sobald seine Inputs verfügbar sind, und erreicht damit einen nahezu optimalen kritischen Pfad. Bei einer typischen 19-Stream-Workload liegt die durchschnittliche NPU-Auslastung bei 78 – 84 % (nahe dem theoretischen Maximum von Batch-Aware Schedulern).

5. Modellkapazität und Registry

Die Bibliothek mit 462+ Modellen wird in einer internen Model Registry mit folgenden Metadaten pro Modell versioniert:

• model_id, version, family, task, architecture_class
• training_dataset_hash, validation_metrics (mAP, F1, Latenz P50/P95/P99)
• target_hardware, quantization_config, compile_target (TensorRT, Hailo-RT, ONNX-Runtime)
• tags: per-tenant, per-region, per-deployment-tier
• lineage: Parent-Modell, Fine-Tune-Datensatz, Retraining-Plan

Das Deployment-Manifest des Kunden (ioasc-deployment.yaml) deklariert, welche Modelle auf welchem Knoten und mit welcher Priorität aktiv sind — die Runtime lädt sie automatisch aus der Model Registry, validiert die Policy (Compliance-Check, Signature Verification) und aktiviert sie zur Laufzeit ohne Unterbrechung der laufenden Streams (Canary-Rollout 5 → 50 → 100 % Traffic).

6. Sicherheitsarchitektur

Die Lösung ist vollständig kompatibel mit der EU-Gesetzgebung, dem Cybersicherheitsgesetz (slowak. Gesetz Nr. 69/2018 Z. z. in der Fassung von Gesetz Nr. 366/2024 — NIS2-Umsetzung) und Verordnungen der slowakischen NBU. Das Software-System enthält:

• automatische Risikowert-Berechnung (FAIR/CVSS-Hybridmodell)
• Bedrohungsanalyse (STRIDE pro Komponente, MITRE-ATT&CK-Mapping)
• kontinuierliche Penetrationstests mit automatisiertem Reporting in das SOC
• eigenes Monitoring-System für Sicherheitsereignisse und -vorfälle (SIEM-ähnlich)
• 24/7 Security Operations Centre (SOC)

Die Implementierung enthält außerdem Peer-to-Peer-Blockchain-Verifikation der Berechtigungen einzelner Komponenten im Netz — jeder Knoten besitzt eine kryptographische Identität mit Zertifikat in der Vertrauenskette des Clusters. Jede Konfigurationsänderung, jedes Modell-Deployment oder Beitritt eines neuen Knotens wird in einem verteilten Ledger erfasst, was das Risiko von Informationsabfluss, unberechtigter Rekonfiguration oder anderem Missbrauch grundlegend minimiert.

7. Einsatzszenarien

Die Implementierung ist modular: Der Kunde startet üblicherweise mit Standalone oder PCIe Add-in (schnelle Pilotphase, ROI < 9 Monate) und erweitert später ohne Rekonfiguration der bestehenden Knoten zum vollständigen Cluster.

8. Fazit

IOAS Security Cluster ist die Konvergenz dreier Trends: Edge-AI-Beschleunigung (240 TOPS @ < 90 W), vertikal spezialisierter ML-Modelle (462+ mit aktiver Retraining-Pipeline) und verteilten/parallelen Berechnungen (5 Parallelitätsebenen, P2P-Koordination). Die Architektur ist so ausgelegt, dass sie bestehende Kamera- und IoT-Infrastruktur ohne Hardware-Austausch integriert und dabei vollständig konform mit EU- und slowakischer Gesetzgebung bleibt.

Für Kommunen, die bereits ein Kamerasystem betreiben und einen Weg suchen, daraus operativen und analytischen Wert zu schöpfen, bietet IOASC den Pfad von der passiven Aufzeichnung zur aktiven, prädiktiven und auditierbaren Sicherheitsplattform.

Möchten Sie mehr erfahren? Schreiben Sie uns.