IOAS Security Cluster (IOASC)

Inteligentné riešenie integrujúce existujúce Smart City systémy, IoT siete a bezpečnostné systémy miest a obcí — s AI-akcelerovanou analytikou až 242 TOPS, 462+ modelmi strojového učenia a horizontálne škálovateľnou paralelnou infraštruktúrou.

Abstrakt

IOAS Security Cluster (IOASC) je distribuovaná platforma pre real-time analýzu obrazu z mestských kamerových systémov, ktorá integruje existujúcu infraštruktúru Smart City riešení, IoT senzorové siete a bezpečnostné systémy miest a obcí v SR. Architektonicky kombinuje špecializovaný AI hardvérový akcelerátor s výkonom 240 TOPS, knižnicu vyše 462 strojovo-naučených modelov a paralelný/decentralizovaný výpočtový framework, ktorý umožňuje na jednej fyzickej jednotke spracovať až 19 paralelných kamerových streamov s end-to-end latenciou pod 80 ms. V tomto článku detailne rozpracujeme tri piliere systému, ktoré boli v pôvodnej koncepcii uvedené iba na úrovni vlastností: (1) pipeline tvorby modelov, (2) high-performance výpočítanie a (3) stratégie paralelného a distribuovaného počítania.

1. Architektúra klastra

IOASC je inteligentné riešenie poskytujúce integráciu už jestvujúcich systémov Smart City riešení, IoT sietí a bezpečnostných systémov miest a obcí v SR. S využitím komponentov klastra IOASC je možné implementovať najnovšie metódy analýzy a spracovania dát aj pre generačne zastaralé systémy vrátane jestvujúcej infraštruktúry. Jednotlivé komponenty systému vedia s výkonom až 242 Tera operácií za sekundu (TOPS) paralelne analyzovať dáta z kamerových systémov a vytvoriť tak rýchle a inteligentné riešenie pre pokročilú analýzu obrazu s využitím už nainštalovaných kamier.

V rámci analýzy systém implementuje viac ako 462 modelov pre spracovanie dát, čo umožňuje rámcovo identifikovať nasledovné kvalitatívne parametre a ich vzájomné súvislosti v reálnom čase:

• ŠPZ, továrenský typ a farba vozidla
• zaradenie vozidiel — sanitka, hasiči, polícia
• behaviorálna analytika účastníkov dopravy — chodcov, cyklistov
• identifikácia behaviorálnych parametrov v danom perimetri (napr. subjekt v čiernej bunde, muž 35 – 45 rokov, s psom, v šiltovke), definičný súbor svedkov daného objektu
• meranie fyzikálnych parametrov objektov — teplota, výška, trajektórie
• identifikácia incidentov — násilné správanie, nehoda
• behaviorálna analytika trajektórie účastníkov cestnej premávky
• kvalitatívny postprocesing kamerových záznamov (denoising)

Na základe aplikácie jednotlivých modelov je možné vytvoriť akýkoľvek typ analytických funkcií s využitím strojového učenia v reálnom čase. Jednotlivé fyzické jednotky sú spojené do klastra, ktorý takto identifikované dáta následne agreguje a vyhodnocuje vyššie korelačné funkcie:

• identifikácia štatistických parametrov — počet pendlerov, počet prechádzajúcich mestom/obcou
• behaviorálne správanie sa vozidiel
• porušovanie dopravných predpisov — úsekové meranie rýchlosti, porušenie trajektórie, prechod na červenú, nedanie prednosti v jazde, nezastavenie na značku STOP a ďalšie
• predikcia dopravných situácií a modelovanie
• identifikácia závadových alebo monitorovaných vozidiel s korelačnými funkciami a predikciou
• identifikácia vozidiel porušujúcich priemernú trajektóriu — požitie alkoholu, porucha na vozidle

Vyššie uvedené parametre vyhodnocuje systém zo všetkých pripojených uzlov klastra, pričom decentralizácia výpočtového výkonu zaručuje prácu v reálnom čase aj pri stovkách paralelných streamov. Jednotlivé modely sú rekurzívne tagované samotným systémom a operátormi (napr. príslušníkmi mestských polícií), čo umožňuje kontinuálnu adaptáciu klasifikátorov a postupné zvyšovanie zhody výstupov s realitou.

2. Tvorba modelov: pipeline strojového učenia

Knižnica 462+ modelov nie je statickým artefaktom — je produktom kontinuálneho MLOps cyklu, ktorý IOAS prevádzkuje pre každého klienta. Pipeline pozostáva zo siedmich etáp, pričom každá je horizontálne škálovateľná a izolovaná v samostatnom kontajnerizovanom workflow.

2.1 Zber a kurátorstvo dát

Vstupné dáta pochádzajú z troch zdrojov:

1. RTSP/ONVIF streaming z existujúcich kamerových systémov klienta — IOASC podporuje H.264, H.265 (HEVC) a AV1, s automatickou detekciou a riešením nekonzistentných keyframov či packet-loss.
2. Anotované korpusy — pre štandardné domény (vozidlá, chodci, ŠPZ) IOAS udržiava interné anotované datasety s viac než 2,4 mil. označenými snímkami (stav 2026 Q2), ktoré boli zozbierané z reálnych slovenských a stredoeurópskych mestských prostredí (rôzne svetelné podmienky, počasie, ročné obdobia).
3. Historické záznamy operátorov — mestské polície a integrované záchranné systémy poskytujú spätnú väzbu vo forme korekcií detekcií, čím sa rozširuje active-learning fronta (sekcia 2.4).

Pred trénovaním všetky dáta prechádzajú deidentifikačnou vrstvou kompatibilnou s GDPR čl. 35 — tváre nezúčastnených osôb sú rozmazané, ŠPZ neukladajú surové znaky, ale ich one-hot embedding pre downstream tasky.

2.2 Architektúry modelov

V knižnici IOASC sú modely zoskupené do siedmich rodín podľa primárnej úlohy:

Pre každú rodinu IOAS udržiava 3 – 5 verzií v rôznych pomeroch presnosť ↔ latencia: *-tiny pre okrajové uzly s obmedzeným výkonom, *-base pre štandardné nasadenie, *-large pre kritické trate (centrálne križovatky, vstupy do verejných budov).

2.3 Trénovacia infraštruktúra

Trénovanie prebieha na samostatnej training cell IOAS infraštruktúry s nasledujúcimi parametrami:

• 8× NVIDIA H100 SXM spojené cez NVLink + InfiniBand 400 Gbps
• Distribuovaný data-parallel training cez PyTorch FSDP (Fully Sharded Data Parallel) so sharded optimizer state (ZeRO Stage 3)
• Mixed-precision BF16 / FP8 (Hopper sparsity) — 2,1 – 2,8× rýchlejšie konvergovanie oproti FP32
• Gradient accumulation s effective batch size 256 – 1024 podľa modelu
• Stochastic Weight Averaging (SWA) v poslednej fáze pre robustnejšie weights
• Per-experiment hyperparameter sweep cez Optuna s ASHA scheduler-om

Doba trénovania jedného produkčného modelu sa pohybuje od 6 hodín (LPRNet fine-tune) do 5 dní (RT-DETR-L na vlastnom 2,4M-snímkovom datasete).

2.4 Optimalizácia pre nasadenie (model serving)

Vytrénované modely prechádzajú trojstupňovou kompresiou pred nasadením na hranu:

1. Štruktúrovaný pruning — odstránenie 30 – 60 % redundantných váh cez magnitude-based + Taylor-expansion kritériá; znižuje pamäťový footprint pri zachovaní > 99 % presnosti.
2. Kvantizácia INT8 (post-training calibration) — kalibračný dataset 1024 reálnych snímkov, per-channel symetrická kvantizácia; typická strata < 0,8 % mAP.
3. Layer fusion + grafová optimalizácia — Conv+BN+ReLU fúzia, eliminácia redundantných reshape operácií, ONNX → TensorRT/Hailo-RT conversion.

Výsledkom je 2,2 – 4,7× rýchlejšia inferencia pri 4× menšom pamäťovom footprinte oproti pôvodnému FP32 modelu.

2.5 Active learning a kontinuálna adaptácia

V produkčnom nasadení každá detekcia s nízkou konfidenciou (< 0,75) automaticky generuje active-learning candidate, ktorý je zaradený do annotation queue. Operátor systému (typicky príslušník mestskej polície) získa cez webovú anotačnú konzolu zoznam neistých prípadov, ktoré označí ako true positive / false positive / false negative / re-classify. Tieto opravy:

• okamžite ovplyvnia per-tenant rules-engine (napr. „toto vozidlo s ŠPZ XYZ123 je hasičské, klasifikuj ho vždy ako emergency”),
• sa akumulujú do retraining batch-u, ktorý sa raz za 7 – 30 dní (podľa veľkosti datasetu) zbieha do nového incremental fine-tuning cyklu,
• sú anonymizované pre cross-tenant federatívny update (sekcia 2.6).

Drift detekcia beží 24/7 — sleduje distribúciu confidence skóre, false-positive rate per kategóriu a per-camera. Ak F1 klesne pod prahovú hodnotu (typicky 0,92 absolútne alebo −3 σ od baseline), systém automaticky escaluje na MLOps tím IOAS.

2.6 Federatívne učenie naprieč klientmi

Pre maximalizáciu zovšeobecnenia naprieč rôznymi mestami (Bratislava, Trenčín, Žilina, Košice — odlišná architektúra, kamery, dopravné vzorce) IOAS prevádzkuje federatívne tréningové kolá podľa schémy FedAvg s diferenciálnou súkromnou ochranou (DP-SGD, ε ≤ 3,0):

[Klient 1: lokálna update] ─┐
[Klient 2: lokálna update] ─┼─→  [Aggregátor (IOAS HQ)]  ─→  [Globálny model v0.N+1]
[Klient 3: lokálna update] ─┤                                       │
                            ...                                     ▼
                                                          [Distribúcia späť na klientov]

Surové dáta neopúšťajú perimeter klienta — odchádzajú iba gradienty s pridaným šumom a metaúdaje o veľkosti aktualizácie. Tým sa zachováva regulačná zhoda s GDPR aj zákonom o kybernetickej bezpečnosti.

3. High-performance výpočítanie

3.1 Hardvérová akcelerácia (240 TOPS)

Srdcom každého IOASC uzla je AI hardvérový akcelerátor s deklarovaným výkonom 240 TOPS @ INT8, ktorý je možné nasadiť v dvoch fyzických formátoch:

Akcelerátor exponuje cez nízkoúrovňové C/C++ runtime API primitívy pre tensor allocation, kernel launch, asynchrónny memcpy a synchronizáciu cez CUDA-stream-like queues. Vyššia vrstva (ioasc-runtime) poskytuje zero-copy DMA prepojenie medzi kamerovým decoder-om (NVDEC alebo dedikovaný hardvérový blok) a inferenčným enginom — celý lifecycle frame neopustí device memory až po výstup analytického payloadu.

Akcelerátor podporuje:

• INT8 / INT4 / FP16 / BF16 dátové typy (FP8 v nadchádzajúcej generácii)
• Sparse tensor cores pre 2:4 blokovo-sparse matice (1,8× boost na vhodných modeloch)
• Grafový compiler (interná verzia odvodená od MLIR/IREE) s automatickou layer fusion
• Multi-tenancy — virtualizácia výpočtových jednotiek pre paralelný beh viacerých modelov bez context-switch overhead

3.2 Pamäťová a sieťová architektúra

   ┌─────────────────────────────────────────────────────┐
   │ IOASC node                                          │
   │                                                     │
   │   [NPU 240 TOPS]  ←──→  [HBM3 1.2 TB/s]              │
   │         ↕                                           │
   │   [CPU host: 16-core ARMv9 / x86]                   │
   │         ↕                                           │
   │   [DDR5 dual-channel, 51 GB/s]                       │
   │         ↕                                           │
   │   [NVMe Gen4 SSD 4 TB]   (model cache + metadata)    │
   │         ↕                                           │
   │   [10 GbE management]   [100 GbE backbone (cluster)]  │
   └─────────────────────────────────────────────────────┘

Pamäťová hierarchia je optimalizovaná pre streaming workloads: NPU pracuje výhradne s tensors v HBM3 (nízka latencia, vysoká priepustnosť), CPU drží metadata a koordinačnú logiku v DDR5, a NVMe slúži ako lokálna cache pre model weights (cold start z NVMe trvá ~ 800 ms per model, warm switch < 5 ms).

Inter-node sieť používa 100 GbE backbone s RDMA (RoCE v2) — node-to-node tensor transfer prebieha cez iWARP alebo RoCE v zero-copy režime, čím sa eliminuje TCP/IP overhead pri distribuovanej inferencii (sekcia 4.4).

3.3 Energetická efektívnosť a termálny manažment

Pre 24/7 prevádzku v outdoor IP66 boxoch IOAS optimalizoval termálny dizajn:

• Power envelope per node: 65 W idle, 90 W typický inferenčný load, 120 W peak
• Energetická efektívnosť: 2,7 – 3,1 TOPS/W pri INT8 (porovnateľné s NVIDIA Jetson AGX Orin 64 GB)
• Pasívny chladič + 2 redundantné PWM ventilátory (40 mm, 4-pin, hot-swap)
• Termálny throttling pri 85 °C die temp — degradácia z 240 → 180 TOPS, 0 % data loss (frame queue absorbuje skok latencie)
• MTBF 95 000 hodín (10,8 rokov) pri 35 °C ambient

3.4 Edge vs centralizovaný compute — latency budget

Pre real-time aplikácie je kritický end-to-end latency budget od fyzickej udalosti po generovanie alarmu. IOASC navrhuje analytiku tak, aby drvivá väčšina inferencie zostala na edge:

Edge-first design dáva 3 – 5× nižšiu latenciu a eliminuje závislosť na WAN konektivite — pri výpadku internetu klastrový uzol pokračuje v lokálnej analýze a alerty doručuje cez záložné GSM/LTE kanály.

4. Paralelné počítanie

Paralelizmus v IOASC pôsobí na piatich úrovniach súčasne, čo dovoľuje saturovať NPU pri rôznorodých záťažových profiloch.

4.1 Paralelizmus na úrovni streamov

Základná konfigurácia jedného uzla obsluhuje 19 paralelných kamerových streamov pri 25 FPS, t. j. 475 frame/s spolu. Streamy sú multipl­exované cez:

• Asynchrónny RTSP demultiplexer (FFmpeg-based, vlastný zero-copy port)
• Per-stream frame queue s back-pressure (drop-newest pri preťažení)
• Dynamické batchovanie — runtime tvorí inferenčné batchy 1 – 16 frame-ov podľa aktuálnej queue depth (vyššia depth → väčší batch, lepšia GPU utilization, mierne vyššia latencia)

4.2 Pipeline parallelism

Spracovanie jedného frame-u je rozložené do piatich pipeline štádií, ktoré bežia paralelne na rôznych frame-och (klasický producer-consumer reťazec):

   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
                                       └──────┘

V ustálenom stave je v pipeline súčasne 5 frame-ov v rôznych štádiách. Throughput sa rovná najpomalšej etape (typicky inferencia), nie sume všetkých etáp — čo prináša 2,8 – 3,4× zrýchlenie oproti synchronnému spracovaniu.

4.3 Model paralelizmus a dátový paralelizmus

Pre veľké modely (RT-DETR-L, MViTv2-L), ktoré sa nezmestia do jednej HBM partície, IOASC podporuje:

• Dátový paralelizmus (data parallel) — každá NPU partícia drží identickú kópiu modelu, batch je rozdelený medzi ne (default pre väčšinu detekčných modelov).
• Tenzorový paralelizmus (tensor parallel) — vrstvy s veľkými matmul (transformer attention, MLP block) sú rozdelené po column-wise alebo row-wise dimenzii, gradienty agregované cez NCCL all-reduce.
• Pipeline paralelizmus (model partitioning) — pri ultra-veľkých modeloch sa po-vrstvové stage rozdelia medzi NPU partície, pričom každý batch je rozdelený do mikro-batchov, ktoré tečú pipeline-om (GPipe/PipeDream-style).

Voľba stratégie je per-model, určená pri kompilácii grafu na základe rozmeru váh, batch-size a dostupných NPU partícií.

4.4 Inter-node sharding klastra

Pri nasadení v škále, kedy mesto má napr. 12 IOASC uzlov pokrývajúcich 228 streamov (12 × 19), klaster realizuje funkcionálny sharding — namiesto toho aby každý uzol behal všetkých 462 modelov, sú modely distribuované:

   Node A: ANPR, vehicle classification               (modely 1-128)
   Node B: pedestrian + cyclist behaviour              (modely 129-238)
   Node C: incident + violence detection               (modely 239-310)
   Node D: re-identification + cross-camera tracking   (modely 311-396)
   Node E: anomaly + denoising postprocess             (modely 397-462)

Každý uzol publikuje svoje analytické výstupy ako typed events na klastrový event-bus (NATS JetStream s persistent storage). Vyššie korelačné funkcie (sekcia 1) bežia na agregačnom uzle, ktorý subscribuje na relevantné topiky a aplikuje:

• multi-camera person re-identification — prepojenie tracking ID naprieč prekrývajúcimi kamerovými zábermi
• trajectory fusion — Kalman-filter spájanie pozičných update-ov z viacerých uhlov
• temporal anomaly detection — detekcia odchýliek od histórického správania (čas, lokalita)
• cross-modal correlation — spájanie kamerového detekovania s IoT senzormi (akustické, vibračné)

4.5 Asynchrónna kompozícia analytických funkcií

Vyššie analytické funkcie sú modelované ako DAG (directed acyclic graph) inferenčných operácií, ktoré klastrový orchestrátor plánuje paralelne všade tam, kde nie je dátová závislosť:

   Frame ──→ Detection ──┬─→ Tracking ──┬─→ ReID ────┐
                         │              │            ├─→ Multi-camera fusion
                         │              └─→ Behaviour┘
                         │
                         └─→ Classification ─→ ANPR ─→ Vehicle DB lookup

Orchestrátor (interný komponent založený na Apache Arrow Flight + custom DAG scheduler) spúšťa každý uzol DAG-u v okamihu, keď sú jeho vstupy dostupné, čím dosahuje near-optimal kritickú cestu. Pre typický 19-stream workload je priemerné využitie NPU 78 – 84 % (porovnateľné s teoretickým maximom batch-aware schedulerov).

5. Modelová kapacita a registrácia

Knižnica 462+ modelov je verzionovaná v internom model registry s nasledujúcimi metadátami 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, retraining schedule

Klientsky deployment manifest (ioasc-deployment.yaml) deklaruje, ktoré modely sú aktivované na ktorom uzle a v akej priorite — runtime ich automaticky stiahne z model registry, aplikuje policy validácie (compliance check, signature verification) a aktivuje za-behu bez prerušenia bežiacich streamov (canary rollout s 5 → 50 → 100 % traffic).

6. Bezpečnostná architektúra

Riešenie je plne kompatibilné s EÚ legislatívou, zákonom o kybernetickej bezpečnosti (č. 69/2018 Z. z. v znení zákona č. 366/2024 Z. z. — implementácia NIS2) a vyhláškami NBÚ. Pre uvedené obsahuje softvérový systém:

• automatický výpočet hodnoty rizík (FAIR/CVSS hybridný model)
• analýzu hrozieb (STRIDE per komponent, MITRE ATT&CK mapping)
• priebežné penetračné testy s automatizovaným report flow do SOC
• vlastný systém pre monitoring bezpečnostných eventov a incidentov (SIEM-like)
• bezpečnostné operačné centrum (SOC) v 24/7 režime

V rámci implementácie obsahuje peer-to-peer blockchain overovanie právomocí jednotlivých komponentov v sieti — každý uzol má kryptografickú identitu s certifikátom v reťazci dôvery klastra. Akákoľvek zmena konfigurácie, nasadenia modelu či pripojenia nového uzla je zaznamenaná v distribuovanom ledger-i, čím sa zásadne minimalizuje riziko úniku informácií, neoprávnenej rekonfigurácie alebo iného formy zneužitia.

7. Implementačné scenáre

Implementácia je modulárna: zákazník začína typicky standalone alebo PCI add-in (rýchla pilotná fáza, ROI < 9 mesiacov), neskôr sa rozširuje do plnohodnotného klastra bez rekonfigurácie už nasadených uzlov.

8. Záver

IOAS Security Cluster predstavuje konvergenciu troch trendov: edge AI akcelerácie (240 TOPS @ < 90 W), vertikálne špecializovaných ML modelov (462+ s aktívnou retrainnig pipeline) a distribuovaného/paralelného počítania (5 úrovní paralelizmu, P2P koordinácia). Architektúra je navrhnutá tak, aby integrovala existujúcu kamerovú a IoT infraštruktúru bez nutnosti výmeny hardvéru, pri zachovaní plnej zhody s EÚ a slovenskou legislatívou.

Pre obce, ktoré už disponujú kamerovým systémom a hľadajú spôsob ako z neho extrahovať operačnú a analytickú hodnotu, IOASC ponúka cestu od pasívneho záznamu k aktívnej, prediktívnej a auditovateľnej bezpečnostnej platforme.

Chcete vedieť viac? Napíšte nám.