IOAS Security Cluster (IOASC)

Inteligentne rozwiązanie integrujące istniejące systemy Smart City, sieci IoT oraz systemy bezpieczeństwa miast i gmin — z analityką AI o mocy do 242 TOPS, 462+ modelami uczenia maszynowego i poziomo skalowalną infrastrukturą równoległą.

Streszczenie

IOAS Security Cluster (IOASC) to rozproszona platforma do analizy obrazu w czasie rzeczywistym z miejskich systemów kamerowych, integrująca istniejącą infrastrukturę rozwiązań Smart City, sieci czujników IoT oraz systemy bezpieczeństwa miast i gmin na Słowacji. Architektonicznie łączy dedykowany akcelerator sprzętowy AI o mocy 240 TOPS, bibliotekę ponad 462 modeli uczenia maszynowego oraz równoległy/zdecentralizowany framework obliczeniowy, który pozwala jednej fizycznej jednostce obsługiwać do 19 równoległych strumieni kamerowych z opóźnieniem end-to-end poniżej 80 ms. W tym artykule szczegółowo rozwijamy trzy filary systemu, które w pierwotnej koncepcji zostały przedstawione tylko ogólnie: (1) potok tworzenia modeli, (2) obliczenia o wysokiej wydajności (HPC) i (3) strategie obliczeń równoległych i rozproszonych.

1. Architektura klastra

IOASC to inteligentne rozwiązanie zapewniające integrację istniejących systemów Smart City, sieci IoT i systemów bezpieczeństwa miast i gmin na Słowacji. Wykorzystując komponenty klastra IOASC można wdrożyć najnowsze metody analityki i przetwarzania danych nawet w przypadku przestarzałych systemów, w tym istniejącej infrastruktury. Komponenty systemu mogą równolegle analizować dane z systemów kamerowych z mocą do 242 Tera operacji na sekundę (TOPS), tworząc szybkie i inteligentne rozwiązanie do zaawansowanej analizy obrazu z już zainstalowanych kamer.

System implementuje ponad 462 modele do przetwarzania danych, co pozwala identyfikować w czasie rzeczywistym następujące parametry jakościowe i ich wzajemne relacje:

• tablica rejestracyjna, marka i kolor pojazdu
• klasyfikacja pojazdów — karetka, straż pożarna, policja
• analityka behawioralna uczestników ruchu — pieszych, rowerzystów
• identyfikacja parametrów behawioralnych w obrębie strefy (np. obiekt w czarnej kurtce, mężczyzna 35–45 lat, z psem, w czapce z daszkiem); definicyjny zbiór świadków danego obiektu
• pomiar parametrów fizycznych obiektów — temperatura, wysokość, trajektorie
• identyfikacja incydentów — agresywne zachowanie, wypadek
• analityka behawioralna trajektorii uczestników ruchu drogowego
• jakościowy postprocessing nagrań kamerowych (denoising)

Na podstawie zastosowania poszczególnych modeli można tworzyć dowolne funkcje analityczne z wykorzystaniem uczenia maszynowego — w czasie rzeczywistym. Poszczególne jednostki fizyczne są łączone w klaster, który następnie agreguje zidentyfikowane dane i ocenia funkcje korelacyjne wyższego rzędu:

• parametry statystyczne — liczba osób dojeżdżających do pracy, liczba przejeżdżających przez miasto/gminę
• zachowanie pojazdów
• naruszenia przepisów ruchu drogowego — odcinkowy pomiar prędkości, naruszenie trajektorii, jazda na czerwonym świetle, nieudzielenie pierwszeństwa, niezatrzymanie się przy znaku STOP i inne
• prognozowanie i modelowanie sytuacji drogowych
• identyfikacja oznaczonych lub monitorowanych pojazdów z funkcjami korelacyjnymi i prognozowaniem
• identyfikacja pojazdów odbiegających od średniej trajektorii — spożycie alkoholu, awaria pojazdu

Wymienione parametry są oceniane przez system na wszystkich połączonych węzłach klastra, a decentralizacja mocy obliczeniowej gwarantuje pracę w czasie rzeczywistym nawet przy setkach równoległych strumieni. Poszczególne modele są rekurencyjnie tagowane przez sam system i operatorów (zazwyczaj funkcjonariuszy straży miejskiej), co umożliwia ciągłą adaptację klasyfikatorów i stopniowe zwiększanie zgodności wyników z rzeczywistością.

2. Tworzenie modeli: potok uczenia maszynowego

Biblioteka 462+ modeli nie jest statycznym artefaktem — jest produktem ciągłego cyklu MLOps prowadzonego przez IOAS dla każdego klienta. Potok składa się z siedmiu etapów; każdy z nich jest niezależnie konteneryzowany i poziomo skalowalny.

2.1 Akwizycja i kuracja danych

Dane wejściowe pochodzą z trzech źródeł:

1. Strumieniowanie RTSP/ONVIF z istniejących systemów kamerowych klienta — IOASC obsługuje H.264, H.265 (HEVC) i AV1, z automatycznym wykrywaniem i naprawą niespójnych klatek kluczowych lub utraty pakietów.
2. Skuratorowane korpusy — dla standardowych dziedzin (pojazdy, piesi, tablice rejestracyjne) IOAS utrzymuje wewnętrzne zbiory danych z ponad 2,4 mln oznaczonych klatek (stan na 2026 Q2), zebranych z rzeczywistych słowackich i środkowoeuropejskich środowisk miejskich (różne warunki oświetleniowe, pogodowe, pory roku).
3. Historia operatora — straże miejskie i zintegrowane służby ratunkowe dostarczają informacji zwrotnej w postaci poprawek detekcji, co rozszerza kolejkę active-learning (sekcja 2.4).

Przed treningiem wszystkie dane przechodzą przez warstwę deidentyfikacji zgodną z RODO Art. 35 — twarze osób niezaangażowanych są rozmazywane, tablice rejestracyjne nie są zapisywane jako surowe znaki, lecz jako one-hot embeddingi do dalszego przetwarzania.

2.2 Architektury modeli

Biblioteka IOASC grupuje modele w siedem rodzin według głównego zadania:

Dla każdej rodziny IOAS utrzymuje 3 – 5 wersji w różnych proporcjach dokładność ↔ opóźnienie: *-tiny dla węzłów brzegowych z ograniczonym budżetem, *-base dla standardowego wdrożenia, *-large dla krytycznych lokalizacji (główne skrzyżowania, wejścia do budynków publicznych).

2.3 Infrastruktura treningowa

Trening odbywa się w dedykowanej training cell infrastruktury IOAS o następujących parametrach:

• 8× NVIDIA H100 SXM połączone przez NVLink + InfiniBand 400 Gbps
• Rozproszony data-parallel trening przez PyTorch FSDP (Fully Sharded Data Parallel) ze sharded optimizer state (ZeRO Stage 3)
• Mixed-precision BF16 / FP8 (Hopper sparsity) — 2,1 – 2,8× szybsza zbieżność niż FP32
• Gradient accumulation z efektywnym batch size 256 – 1024 zależnie od modelu
• Stochastic Weight Averaging (SWA) w końcowej fazie dla bardziej odpornych wag
• Per-eksperyment przeszukiwanie hiperparametrów przez Optuna ze schedulerem ASHA

Trening pojedynczego modelu produkcyjnego trwa od 6 godzin (LPRNet fine-tune) do 5 dni (RT-DETR-L na własnym zbiorze 2,4 M klatek).

2.4 Optymalizacja pod wdrożenie (model serving)

Wytrenowane modele przechodzą trzystopniową kompresję przed wdrożeniem na brzegu:

1. Strukturalny pruning — usunięcie 30 – 60 % redundantnych wag przez kryteria magnitude-based + Taylor expansion; zmniejsza ślad pamięciowy zachowując > 99 % dokładności.
2. Kalibracja INT8 (post-training) — zbiór kalibracyjny 1024 rzeczywistych klatek, kwantyzacja per-channel symetryczna; typowa strata < 0,8 % mAP.
3. Layer fusion + optymalizacja grafu — fuzja Conv+BN+ReLU, eliminacja redundantnych operacji reshape, konwersja ONNX → TensorRT/Hailo-RT.

Wynik: 2,2 – 4,7× szybsze wnioskowanie przy 4× mniejszym śladzie pamięciowym w porównaniu z oryginalnym modelem FP32.

2.5 Active learning i ciągła adaptacja

W produkcji każda detekcja z pewnością poniżej 0,75 automatycznie generuje kandydata active-learning, który trafia do kolejki adnotacyjnej. Operator systemu (zwykle funkcjonariusz straży miejskiej) otrzymuje przez konsolę webową listę niepewnych przypadków i oznacza je jako true positive / false positive / false negative / re-classify. Te poprawki:

• natychmiast wpływają na silnik reguł per-tenant (np. „ten pojazd z tablicą XYZ123 to wóz strażacki, klasyfikuj zawsze jako emergency”),
• akumulują się w batch retreningu, który co 7 – 30 dni (zależnie od wielkości zbioru) zbiega do nowego cyklu inkrementalnego fine-tuningu,
• są anonimizowane dla cross-tenant federated update (sekcja 2.6).

Drift detection działa 24/7 — monitoruje rozkład wyników pewności, false-positive rate per kategoria i per kamera. Jeśli F1 spadnie poniżej progu (zazwyczaj 0,92 absolutnie lub −3 σ od baseline), system automatycznie eskaluje do zespołu MLOps IOAS.

2.6 Federated learning między klientami

Aby zmaksymalizować generalizację między różnymi miastami (Bratysława, Trenczyn, Żylina, Koszyce — odmienna architektura, kamery, wzorce ruchu), IOAS prowadzi rundy federated learning według schematu FedAvg z różnicową ochroną prywatności (DP-SGD, ε ≤ 3,0):

[Klient 1: lokalna aktualizacja] ─┐
[Klient 2: lokalna aktualizacja] ─┼─→  [Agregator (IOAS HQ)]  ─→  [Globalny model v0.N+1]
[Klient 3: lokalna aktualizacja] ─┤                                       │
                                 ...                                      ▼
                                                          [Dystrybucja z powrotem do klientów]

Surowe dane nie opuszczają perymetru klienta — odsyłane są tylko gradienty z dodanym szumem oraz metadane o wielkości aktualizacji. Zachowuje to zgodność regulacyjną z RODO i ustawą o cyberbezpieczeństwie.

3. Obliczenia o wysokiej wydajności (HPC)

3.1 Akceleracja sprzętowa (240 TOPS)

Sercem każdego węzła IOASC jest akcelerator sprzętowy AI z deklarowaną wydajnością 240 TOPS @ INT8, dostępny w dwóch fizycznych formatach:

Akcelerator udostępnia niskopoziomowe C/C++ runtime API z prymitywami do alokacji tensorów, uruchamiania kerneli, asynchronicznego memcpy oraz synchronizacji przez kolejki podobne do CUDA-stream. Wyższa warstwa (ioasc-runtime) zapewnia zero-copy połączenie DMA między dekoderem kamery (NVDEC lub dedykowany blok sprzętowy) a silnikiem inferencyjnym — cały cykl klatki nie opuszcza pamięci urządzenia aż do wyemitowania ładunku analitycznego.

Akcelerator obsługuje:

• typy danych INT8 / INT4 / FP16 / BF16 (FP8 w nadchodzącej generacji)
• Sparse tensor cores dla macierzy 2:4 block-sparse (1,8× boost na odpowiednich modelach)
• Kompilator grafu (wewnętrzna wersja oparta na MLIR/IREE) z automatyczną fuzją warstw
• Multi-tenancy — wirtualizacja jednostek obliczeniowych do równoległej pracy wielu modeli bez kosztu context-switch

3.2 Architektura pamięci i sieci

   ┌─────────────────────────────────────────────────────┐
   │ Węzeł IOASC                                         │
   │                                                     │
   │   [NPU 240 TOPS]  ←──→  [HBM3 1.2 TB/s]              │
   │         ↕                                           │
   │   [CPU host: 16-rdzeniowy ARMv9 / x86]              │
   │         ↕                                           │
   │   [DDR5 dual-channel, 51 GB/s]                       │
   │         ↕                                           │
   │   [NVMe Gen4 SSD 4 TB]   (cache modeli + metadane)   │
   │         ↕                                           │
   │   [10 GbE management]   [100 GbE backbone (klaster)] │
   └─────────────────────────────────────────────────────┘

Hierarchia pamięci jest zoptymalizowana pod strumieniowe obciążenia: NPU pracuje wyłącznie z tensorami w HBM3 (niskie opóźnienie, wysoka przepustowość), CPU trzyma metadane i logikę koordynacyjną w DDR5, NVMe służy jako lokalny cache wag modeli (zimny start z NVMe ~ 800 ms na model, ciepły switch < 5 ms).

Sieć inter-node używa 100 GbE backbone z RDMA (RoCE v2) — transfer tensorów node-to-node przebiega przez iWARP lub RoCE w trybie zero-copy, eliminując narzut TCP/IP przy rozproszonej inferencji (sekcja 4.4).

3.3 Efektywność energetyczna i zarządzanie termiczne

Dla pracy 24/7 w outdoor obudowach IP66 IOAS zoptymalizował projekt termiczny:

• Power envelope na węzeł: 65 W idle, 90 W typowy load inferencyjny, 120 W peak
• Efektywność energetyczna: 2,7 – 3,1 TOPS/W przy INT8 (porównywalne z NVIDIA Jetson AGX Orin 64 GB)
• Pasywny radiator + 2 redundantne wentylatory PWM (40 mm, 4-pin, hot-swap)
• Termiczny throttling przy 85 °C die temp — degradacja z 240 → 180 TOPS, 0 % utraty danych (kolejka klatek absorbuje skok opóźnienia)
• MTBF 95 000 godzin (10,8 lat) przy 35 °C ambient

3.4 Edge vs scentralizowane obliczenia — budżet opóźnień

Dla aplikacji czasu rzeczywistego krytyczny jest end-to-end latency budget od fizycznego zdarzenia do generacji alarmu. IOASC trzyma większość inferencji na brzegu:

Edge-first design daje 3 – 5× niższe opóźnienie i eliminuje zależność od łączności WAN — przy awarii internetu węzeł klastra kontynuuje analizę lokalnie, a alerty dostarcza zapasowymi kanałami GSM/LTE.

4. Obliczenia równoległe

Równoległość w IOASC działa na pięciu poziomach jednocześnie, co pozwala saturować NPU przy heterogenicznych obciążeniach.

4.1 Równoległość na poziomie strumieni

Podstawowa konfiguracja jednego węzła obsługuje 19 równoległych strumieni kamerowych przy 25 FPS, czyli łącznie 475 klatek/s. Strumienie są multipleksowane przez:

• Asynchroniczny demultiplekser RTSP (oparty na FFmpeg, własny port zero-copy)
• Per-stream frame queue z back-pressure (drop-newest pod przeciążeniem)
• Dynamic batching — runtime tworzy batche inferencyjne 1 – 16 klatek wg aktualnej głębokości kolejki (głębsza kolejka → większy batch, lepsze wykorzystanie GPU, nieco wyższe opóźnienie)

4.2 Pipeline parallelism

Przetwarzanie pojedynczej klatki jest rozłożone na pięć etapów pipeline, które działają równolegle na różnych klatkach (klasyczny łańcuch producent-konsument):

   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 │ Inference  ← FR-2: Preprocess  ← FR-3: Decode
                     └──┬───┘
                        ↓     ┌──────┐
                              │ FR-1 │ Postprocess  ← FR-2: Inf  ← FR-3: Pre  ← FR-4: Dec
                              └──┬───┘
                                 ↓     ┌──────┐
                                       │ FR-1 │ Publish
                                       └──────┘

W stanie ustalonym w pipeline jednocześnie znajduje się 5 klatek w różnych etapach. Przepustowość jest równa najwolniejszemu etapowi (zwykle inferencji), nie sumie wszystkich etapów — co daje 2,8 – 3,4× przyspieszenie w porównaniu z synchronicznym przetwarzaniem.

4.3 Model i data parallelism

Dla dużych modeli (RT-DETR-L, MViTv2-L), które nie mieszczą się w jednej partycji HBM, IOASC obsługuje:

• Data parallelism — każda partycja NPU trzyma identyczną kopię modelu, batch jest dzielony między nimi (default dla większości modeli detekcji).
• Tensor parallelism — warstwy z dużymi matmul (transformer attention, blok MLP) są dzielone wzdłuż wymiaru column-wise lub row-wise, gradienty agregowane przez NCCL all-reduce.
• Pipeline parallelism (model partitioning) — przy ultra-dużych modelach etapy per warstwa są rozdzielone między partycje NPU, każdy batch dzielony jest na mikro-batche płynące przez pipeline (styl GPipe / PipeDream).

Strategia jest dobierana per-model, decydowana w czasie kompilacji grafu na podstawie rozmiaru wag, batch-size i dostępnych partycji NPU.

4.4 Inter-node sharding klastra

Przy wdrożeniu na skalę, gdy miasto ma np. 12 węzłów IOASC obsługujących 228 strumieni (12 × 19), klaster realizuje funkcjonalny sharding — zamiast aby każdy węzeł uruchamiał wszystkie 462 modele, modele są rozproszone:

   Węzeł A: ANPR, klasyfikacja pojazdów                (modele 1-128)
   Węzeł B: zachowanie pieszych + rowerzystów          (modele 129-238)
   Węzeł C: detekcja incydentów + przemocy             (modele 239-310)
   Węzeł D: re-identyfikacja + cross-camera tracking   (modele 311-396)
   Węzeł E: anomalie + denoising postprocess           (modele 397-462)

Każdy węzeł publikuje swoje wyniki analityczne jako typowane zdarzenia na klastrowy event-bus (NATS JetStream z persystentnym storage). Funkcje korelacyjne wyższego rzędu (sekcja 1) działają na węźle agregującym, który subskrybuje odpowiednie tematy i stosuje:

• multi-camera person re-identification — łączenie tracking ID przez nakładające się kąty kamer
• trajectory fusion — łączenie aktualizacji pozycji z wielu kątów filtrem Kalmana
• temporal anomaly detection — wykrywanie odchyleń od historycznego zachowania (czas, lokalizacja)
• cross-modal correlation — łączenie detekcji kamerowej z czujnikami IoT (akustyczne, wibracyjne)

4.5 Asynchroniczna kompozycja funkcji analitycznych

Funkcje analityczne wyższego rzędu są modelowane jako DAG (graf skierowany acykliczny) operacji inferencyjnych, które orchestrator klastrowy planuje równolegle wszędzie tam, gdzie nie ma zależności danych:

   Klatka ──→ Detekcja ──┬─→ Tracking ──┬─→ ReID ────┐
                         │              │            ├─→ Multi-camera fusion
                         │              └─→ Behaviour┘
                         │
                         └─→ Klasyfikacja ─→ ANPR ─→ Wyszukanie w DB pojazdów

Orchestrator (wewnętrzny komponent zbudowany na Apache Arrow Flight + własny scheduler DAG) startuje każdy węzeł DAG-u w momencie dostępności jego wejść, osiągając prawie optymalną ścieżkę krytyczną. Dla typowego obciążenia 19-strumieniowego średnie wykorzystanie NPU wynosi 78 – 84 % (blisko teoretycznego maksimum batch-aware schedulerów).

5. Pojemność modelowa i rejestr

Biblioteka 462+ modeli jest wersjonowana w wewnętrznym model registry z następującymi metadanymi per model:

• model_id, version, family, task, architecture_class
• training_dataset_hash, validation_metrics (mAP, F1, latency P50/P95/P99)
• target_hardware, quantization_config, compile_target (TensorRT, Hailo-RT, ONNX-Runtime)
• tags: per-tenant, per-region, per-deployment-tier
• lineage: parent model, fine-tune dataset, harmonogram retreningu

Manifest wdrożenia klienta (ioasc-deployment.yaml) deklaruje, które modele są aktywne na którym węźle i z jakim priorytetem — runtime pobiera je automatycznie z model registry, stosuje walidację polityki (compliance check, signature verification) i aktywuje w runtime’ie bez przerywania działających strumieni (canary rollout 5 → 50 → 100 % traffic).

6. Architektura bezpieczeństwa

Rozwiązanie jest w pełni zgodne z prawodawstwem UE, ustawą o cyberbezpieczeństwie (słow. ustawa nr 69/2018 Z. z. w brzmieniu ustawy nr 366/2024 — implementacja NIS2) oraz dekretami słowackiego NBU. System oprogramowania zawiera:

• automatyczne obliczanie wartości ryzyka (model hybrydowy FAIR/CVSS)
• analizę zagrożeń (STRIDE per komponent, mapowanie MITRE ATT&CK)
• ciągłe testy penetracyjne z automatycznym raportowaniem do SOC
• autorski system monitorowania zdarzeń bezpieczeństwa i incydentów (SIEM-like)
• 24/7 Security Operations Centre (SOC)

Implementacja zawiera również peer-to-peer blockchain weryfikację uprawnień poszczególnych komponentów w sieci — każdy węzeł posiada tożsamość kryptograficzną z certyfikatem w łańcuchu zaufania klastra. Każda zmiana konfiguracji, wdrożenie modelu lub dołączenie nowego węzła jest rejestrowane w rozproszonej księdze, fundamentalnie minimalizując ryzyko wycieku informacji, nieautoryzowanej rekonfiguracji lub innej formy nadużycia.

7. Scenariusze wdrożenia

Wdrożenie jest modułowe: klient zaczyna zwykle od standalone lub PCIe add-in (szybka faza pilotażowa, ROI < 9 miesięcy), później rozszerza do pełnego klastra bez rekonfiguracji już wdrożonych węzłów.

8. Podsumowanie

IOAS Security Cluster jest konwergencją trzech trendów: akceleracji edge AI (240 TOPS @ < 90 W), wertykalnie wyspecjalizowanych modeli ML (462+ z aktywnym potokiem retreningu) oraz rozproszonych/równoległych obliczeń (5 poziomów równoległości, koordynacja P2P). Architektura jest zaprojektowana tak, aby integrowała istniejącą infrastrukturę kamer i IoT bez konieczności wymiany sprzętu, zachowując pełną zgodność z prawodawstwem UE i Słowacji.

Dla gmin, które już posiadają system kamerowy i szukają sposobu wydobycia z niego wartości operacyjnej i analitycznej, IOASC oferuje drogę od pasywnego nagrywania do aktywnej, predykcyjnej i audytowalnej platformy bezpieczeństwa.

Chcesz wiedzieć więcej? Napisz do nas.