IOAS Security Cluster (IOASC)

En intelligent løsning som integrerer eksisterende Smart City-systemer, IoT-nett og sikkerhetssystemer i byer og kommuner — med inntil 242 TOPS KI-akselerert analyse, over 462 maskinlærte modeller og en horisontalt skalerbar parallell infrastruktur.

Sammendrag

IOAS Security Cluster (IOASC) er en distribuert plattform for sanntidsanalyse av bilder fra kommunale kamerasystemer. Den integrerer eksisterende infrastruktur i Smart City-utrullinger, IoT-sensornett og sikkerhetssystemer i byer og kommuner i Slovakia. Arkitektonisk kombinerer den en dedikert KI-maskinvareakselerator som leverer 240 TOPS, et bibliotek på mer enn 462 maskinlærte modeller og et parallelt og desentralisert beregningsrammeverk som lar én fysisk enhet behandle inntil 19 samtidige kamerastrømmer med ende-til-ende-forsinkelse under 80 ms. Denne artikkelen utdyper de tre pilarene som det opprinnelige konseptet bare berørte: (1) modellproduksjonslinjen, (2) høyytelsesberegning og (3) strategier for parallell og distribuert beregning.

1. Klyngearkitektur

IOASC er en intelligent løsning som integrerer eksisterende Smart City-systemer, IoT-nett og sikkerhetssystemer i byer og kommuner i Slovakia. Med IOASC-komponentene er det mulig å ta i bruk moderne metoder for dataanalyse og databehandling selv i systemer som er utdaterte generasjonsmessig, inkludert eldre infrastruktur. Systemets komponenter kan analysere — parallelt — data fra kamerasystemer med inntil 242 Tera Operations Per Second (TOPS), og skaper dermed en rask og intelligent løsning for avansert bildeanalyse på allerede installerte kameraer.

Systemet implementerer mer enn 462 modeller for databehandling, noe som gjør det mulig å identifisere følgende kvalitative parametere og sammenhengene mellom dem i sanntid:

• skiltnummer, fabrikkmodell, kjøretøyets farge
• klassifisering av kjøretøy — ambulanse, brannvesen, politi
• atferdsanalyse av trafikanter — fotgjengere, syklister
• identifisering av atferdsparametere i et perimeter — f.eks. person i svart jakke, mann 35–45 år, med hund, med lue; definering av vitnegruppe for et objekt
• måling av objektets fysiske parametere — temperatur, høyde, bevegelsesbaner
• identifisering av hendelser — voldelig atferd, ulykke
• atferdsanalyse av trafikantenes bevegelsesbaner
• kvalitativ etterbehandling av kameraopptak (støyfjerning)

Ved å kombinere de enkelte modellene er det mulig å bygge en hvilken som helst analysefunksjon basert på maskinlæring, alt i sanntid. De enkelte fysiske enhetene kobles deretter sammen i en klynge, som aggregerer resultatdataene og evaluerer korrelasjoner av høyere orden:

• statistiske parametere — antall pendlere, antall som passerer gjennom en by eller kommune
• kjøretøyenes atferd
• trafikkovertredelser — strekningsfart, brudd på kjørebane, kjøring mot rødt lys, manglende vikeplikt, manglende stopp ved STOPP-skilt med mer
• prediksjon og modellering av trafikksituasjoner
• identifisering av etterlyste eller overvåkede kjøretøy med korrelasjonsfunksjoner og prediksjon
• identifisering av kjøretøy som avviker fra gjennomsnittlig kjøremønster — alkoholbruk, teknisk feil

Disse parameterne evalueres av systemet på tvers av alle tilkoblede klyngenoder; desentraliseringen av regnekraften garanterer sanntidsdrift selv med hundrevis av parallelle strømmer. De enkelte modellene merkes rekursivt av systemet selv og av operatørene (typisk kommunale politibetjenter), noe som muliggjør kontinuerlig tilpasning av klassifikatorene og en jevn økning i samsvaret mellom resultat og virkelighet.

2. Modellproduksjon: maskinlæringslinjen

Biblioteket med 462+ modeller er ikke et statisk produkt — det er resultatet av en kontinuerlig MLOps-syklus som IOAS drifter for hver kunde. Produksjonslinjen består av sju trinn, hvert av dem uavhengig containerisert og horisontalt skalerbart.

2.1 Innhenting og kuratering av data

Inndata kommer fra tre kilder:

1. RTSP/ONVIF-strømming fra kundens eksisterende kamerasystemer — IOASC støtter H.264, H.265 (HEVC) og AV1, med automatisk deteksjon og gjenoppretting ved inkonsistente nøkkelbilder eller pakketap.
2. Annoterte korpus — for standarddomener (kjøretøy, fotgjengere, skilt) vedlikeholder IOAS interne annoterte datasett med mer enn 2,4 millioner merkede bilder (status 2026 Q2), samlet inn fra reelle slovakiske og sentraleuropeiske kommunale miljøer (varierende lys, vær og årstider).
3. Operatørhistorikk — kommunalt politi og nødetater gir tilbakemelding i form av korrigerte deteksjoner, noe som utvider køen for aktiv læring (avsnitt 2.4).

Før trening går alle data gjennom et avidentifiseringslag i tråd med GDPR art. 35 — ansikter på uvedkommende personer sløres, og skiltnumre lagres ikke som rå tegn, men som one-hot-embeddinger for videre oppgaver.

2.2 Modellarkitekturer

IOASC-biblioteket grupperer modellene i sju familier etter primæroppgave:

For hver familie vedlikeholder IOAS 3–5 versjoner med ulike avveininger mellom nøyaktighet ↔ forsinkelse: *-tiny for kantnoder med begrenset budsjett, *-base for standard utrulling og *-large for kritiske steder (sentrale kryss, innganger til offentlige bygg).

2.3 Treningsinfrastruktur

Treningen kjører i en dedikert treningscelle i IOAS-infrastrukturen med følgende parametere:

• 8× NVIDIA H100 SXM koblet sammen med NVLink + InfiniBand 400 Gbps
• Distribuert dataparallell trening via PyTorch FSDP (Fully Sharded Data Parallel) med oppdelt optimalisatortilstand (ZeRO Stage 3)
• Blandet presisjon BF16 / FP8 (Hopper sparsity) — 2,1–2,8× raskere konvergens enn FP32
• Gradientakkumulering med effektiv batchstørrelse 256–1024 avhengig av modellen
• Stochastic Weight Averaging (SWA) i sluttfasen for mer robuste vekter
• Hyperparametersøk per eksperiment via Optuna med ASHA-planleggeren

Trening av én produksjonsmodell tar mellom 6 timer (finjustering av LPRNet) og 5 døgn (RT-DETR-L på det egne datasettet med 2,4 mill. bilder).

2.4 Optimalisering for utrulling (model serving)

Ferdigtrente modeller går gjennom en trestegs komprimering før de rulles ut på kanten:

1. Strukturert beskjæring — fjerning av 30–60 % overflødige vekter ved hjelp av magnitudebaserte kriterier og Taylor-utvikling; reduserer minnebruken samtidig som > 99 % av nøyaktigheten beholdes.
2. INT8-kalibrering etter trening — kalibreringsdatasett på 1024 reelle bilder, symmetrisk kvantisering per kanal; typisk mAP-tap < 0,8 %.
3. Lagsammenslåing + grafoptimalisering — sammenslåing av Conv+BN+ReLU, fjerning av overflødige reshape-operasjoner, konvertering ONNX → TensorRT/Hailo-RT.

Resultatet er 2,2–4,7× raskere inferens med 4× mindre minnebruk sammenlignet med den opprinnelige FP32-modellen.

2.5 Aktiv læring og kontinuerlig tilpasning

I produksjon genererer hver deteksjon med konfidens under 0,75 automatisk en kandidat for aktiv læring som legges i annoteringskøen. Systemoperatøren (typisk en kommunal politibetjent) får tilgang til en annoteringskonsoll med listen over usikre tilfeller og merker dem som sann positiv / falsk positiv / falsk negativ / omklassifiser. Disse korreksjonene:

• påvirker umiddelbart regelmotoren per leietaker (f.eks. «dette kjøretøyet med skilt XYZ123 er et brannvesenkjøretøy, klassifiser alltid som utrykning»),
• akkumuleres i en gjentreningsbatch som munner ut i en ny inkrementell finjusteringssyklus hver 7.–30. dag (avhengig av datasettets størrelse),
• anonymiseres for fødererte oppdateringer på tvers av kunder (avsnitt 2.6).

Driftsavviksdeteksjon kjører døgnet rundt — den overvåker fordelingen av konfidensverdier og andelen falske positive per kategori og per kamera. Dersom F1 faller under terskelen (typisk 0,92 absolutt eller −3 σ fra grunnlinjen), eskalerer systemet automatisk til IOAS’ MLOps-team.

2.6 Føderert læring på tvers av kunder

For å maksimere generaliseringen på tvers av ulike byer (Bratislava, Trenčín, Žilina, Košice — ulik arkitektur, ulike kameraer, ulike trafikkmønstre) kjører IOAS fødererte treningsrunder etter FedAvg med differensiell personvern (DP-SGD, ε ≤ 3,0):

[Kunde 1: lokal oppdat.] ─┐
[Kunde 2: lokal oppdat.] ─┼─→  [Aggregator (IOAS HQ)]  ─→  [Global modell v0.N+1]
[Kunde 3: lokal oppdat.] ─┤                                   │
                          ...                                 ▼
                                        [Distribusjon tilbake til kundene]

Rådata forlater aldri kundens perimeter — kun støytilsatte gradienter og metadata om oppdateringens størrelse overføres. Dette ivaretar etterlevelse av GDPR og den slovakiske cybersikkerhetsloven.

3. Høyytelsesberegning

3.1 Maskinvareakselerasjon (240 TOPS)

Hjertet i hver IOASC-node er en KI-maskinvareakselerator med oppgitt kapasitet på 240 TOPS @ INT8, tilgjengelig i to fysiske formfaktorer:

Akseleratoren eksponerer et lavnivå C/C++-kjøretids-API med primitiver for tensorallokering, kjernestart, asynkron memcpy og synkronisering via køer i stil med CUDA-strømmer. Det høyere laget (ioasc-runtime) sørger for en zero-copy DMA-forbindelse mellom kameradekoderen (NVDEC eller en dedikert maskinvareblokk) og inferensmotoren — hele bildets livssyklus forblir i enhetens minne inntil den analytiske nyttelasten sendes ut.

Akseleratoren støtter:

• datatypene INT8 / INT4 / FP16 / BF16 (FP8 i neste generasjon)
• sparse tensorkjerner for 2:4 blokk-sparse matriser (1,8× ytelsesøkning på egnede modeller)
• grafkompilator (egen versjon avledet fra MLIR/IREE) med automatisk lagsammenslåing
• flerleietakerdrift — virtualisering av regneenheter slik at flere modeller kan kjøre parallelt uten overhead ved kontekstbytte

3.2 Minne- og nettverksarkitektur

   ┌─────────────────────────────────────────────────────┐
   │ IOASC-node                                          │
   │                                                     │
   │   [NPU 240 TOPS]  ←──→  [HBM3 1,2 TB/s]              │
   │         ↕                                           │
   │   [CPU-vert: 16-kjerners ARMv9 / x86]               │
   │         ↕                                           │
   │   [DDR5 tokanals, 51 GB/s]                           │
   │         ↕                                           │
   │   [NVMe Gen4 SSD 4 TB]   (modellcache + metadata)    │
   │         ↕                                           │
   │   [10 GbE administrasjon]  [100 GbE ryggrad (klynge)]│
   └─────────────────────────────────────────────────────┘

Minnehierarkiet er optimalisert for strømmende arbeidslaster: NPU-en arbeider utelukkende med tensorer i HBM3 (lav forsinkelse, høy båndbredde), CPU-en holder metadata og koordineringslogikk i DDR5, og NVMe fungerer som lokal cache for modellvekter (kaldstart fra NVMe tar ca. 800 ms per modell, varmt bytte < 5 ms).

Sambandet mellom noder bruker en 100 GbE ryggrad med RDMA (RoCE v2) — tensoroverføring mellom noder går over iWARP eller RoCE i zero-copy-modus, noe som fjerner TCP/IP-overhead under distribuert inferens (avsnitt 4.4).

3.3 Energieffektivitet og termisk håndtering

For døgnkontinuerlig utendørs drift i IP66-kabinett har IOAS optimalisert den termiske konstruksjonen:

• Effektbudsjett per node: 65 W i tomgang, 90 W ved typisk inferenslast, 120 W topp
• Energieffektivitet: 2,7–3,1 TOPS/W ved INT8 (sammenlignbart med NVIDIA Jetson AGX Orin 64 GB)
• Passiv kjøleribbe + 2 redundante PWM-vifter (40 mm, 4-pinners, hot-swap)
• Termisk struping ved 85 °C brikketemperatur — reduksjon fra 240 → 180 TOPS, 0 % datatap (bildekøen absorberer forsinkelsestoppen)
• MTBF 95 000 timer (10,8 år) ved 35 °C omgivelsestemperatur

3.4 Kant kontra sentralisert beregning — forsinkelsesbudsjett

For sanntidsanvendelser er ende-til-ende-forsinkelsen fra fysisk hendelse til utsendt alarm avgjørende. IOASC holder hoveddelen av inferensen på kanten:

En kant-først-konstruksjon gir 3–5× lavere forsinkelse og fjerner avhengigheten av WAN-tilkobling — når internettlinjen er nede, fortsetter klyngenoden den lokale analysen og sender varsler via reservekanaler på GSM/LTE.

4. Parallell beregning

Parallelliteten i IOASC virker på fem nivåer samtidig, slik at NPU-en holdes mettet også under heterogene arbeidslaster.

4.1 Parallellitet på strømnivå

Grunnkonfigurasjonen for én node betjener 19 samtidige kamerastrømmer ved 25 FPS, altså 475 bilder/s totalt. Strømmene multiplekses via:

• asynkron RTSP-demultiplekser (FFmpeg-basert, egen zero-copy-port)
• bildekø per strøm med mottrykk (forkast nyeste ved overbelastning)
• dynamisk batching — kjøretiden setter sammen inferensbatcher på 1–16 bilder etter gjeldende ködybde (dypere kø → større batch, bedre utnyttelse, litt høyere forsinkelse)

4.2 Rørledningsparallellitet

Behandlingen av ett enkelt bilde er delt opp i fem rørledningstrinn som kjører parallelt på ulike bilder (en klassisk produsent-konsument-kjede):

   t=0 ms       t=5 ms       t=10 ms      t=15 ms      t=20 ms
   ┌──────┐
   │ FR-1 │ Dekoding
   └──┬───┘
      ↓     ┌──────┐
            │ FR-1 │ Forbehandling  ← FR-2: Dekoding
            └──┬───┘
               ↓     ┌──────┐
                     │ FR-1 │ Inferens   ← FR-2: Forbehandling  ← FR-3: Dekoding
                     └──┬───┘
                        ↓     ┌──────┐
                              │ FR-1 │ Etterbeh.  ← FR-2: Inf ← FR-3: For ← FR-4: Dek
                              └──┬───┘
                                 ↓     ┌──────┐
                                       │ FR-1 │ Publisering
                                       └──────┘

I stabil drift er 5 bilder samtidig underveis i ulike trinn. Gjennomstrømningen tilsvarer det tregeste trinnet (typisk inferensen) og ikke summen av alle trinn — noe som gir 2,8–3,4× hastighetsøkning sammenlignet med synkron behandling.

4.3 Modell- og dataparallellitet

For store modeller (RT-DETR-L, MViTv2-L) som ikke får plass i én HBM-partisjon, støtter IOASC:

• Dataparallellitet — hver NPU-partisjon holder en identisk kopi av modellen, og batchen deles mellom dem (standard for de fleste deteksjonsmodeller).
• Tensorparallellitet — lag med store matrisemultiplikasjoner (attention i transformere, MLP-blokken) deles langs kolonne- eller radaksen, og gradientene aggregeres via NCCL all-reduce.
• Rørledningsparallellitet (modelloppdeling) — for svært store modeller fordeles trinnene per lag mellom NPU-partisjonene, og hver batch deles i mikrobatcher som flyter gjennom rørledningen (i stil med GPipe / PipeDream).

Strategien velges per modell, avgjort ved grafkompilering ut fra vektstørrelse, batchstørrelse og tilgjengelige NPU-partisjoner.

4.4 Oppdeling av klyngen mellom noder

Ved utrulling i stor skala — en by kan f.eks. ha 12 IOASC-noder som dekker 228 strømmer (12 × 19) — realiserer klyngen funksjonell oppdeling: i stedet for å kjøre alle 462 modellene på hver node, fordeles modellene:

   Node A: ANPR, klassifisering av kjøretøy            (modell 1-128)
   Node B: atferd hos fotgjengere og syklister         (modell 129-238)
   Node C: hendelses- og voldsdeteksjon                (modell 239-310)
   Node D: re-identifisering + sporing på tvers av kamera (modell 311-396)
   Node E: avvik + etterbehandling med støyfjerning    (modell 397-462)

Hver node publiserer sine analyseresultater som typede hendelser på en hendelsesbuss for klyngen (NATS JetStream med varig lagring). Korrelasjonsfunksjoner av høyere orden (avsnitt 1) kjører på en aggregeringsnode som abonnerer på relevante emner og anvender:

• re-identifisering av personer på tvers av kameraer — kobling av sporings-ID-er mellom overlappende kameravinkler
• banefusjon — sammenslåing av posisjonsoppdateringer fra flere vinkler med Kalman-filter
• temporal avviksdeteksjon — påvisning av avvik fra historisk atferd (tid, sted)
• kryssmodal korrelasjon — kobling av kameradeteksjon med IoT-sensorer (akustiske, vibrasjon)

4.5 Asynkron sammensetning av analysefunksjoner

Analysefunksjoner av høyere orden modelleres som en DAG (rettet asyklisk graf) av inferensoperasjoner som klyngeorkestratoren planlegger parallelt overalt hvor det ikke finnes dataavhengighet:

   Bilde ──→ Deteksjon ──┬─→ Sporing ──┬─→ ReID ────┐
                         │             │            ├─→ Fusjon på tvers av kamera
                         │             └─→ Atferd ──┘
                         │
                         └─→ Klassifisering ─→ ANPR ─→ Oppslag i kjøretøyregister

Orkestratoren (en intern komponent bygget på Apache Arrow Flight + en egen DAG-planlegger) starter hver DAG-node i det øyeblikket inndataene er klare, og oppnår dermed en tilnærmet optimal kritisk vei. For en typisk arbeidslast med 19 strømmer er gjennomsnittlig NPU-utnyttelse 78–84 % (nær det teoretiske maksimum for batch-bevisste planleggere).

5. Modellkapasitet og register

Biblioteket på 462+ modeller er versjonert i et internt modellregister med følgende metadata per modell:

• model_id, version, family, task, architecture_class
• training_dataset_hash, validation_metrics (mAP, F1, forsinkelse P50/P95/P99)
• target_hardware, quantization_config, compile_target (TensorRT, Hailo-RT, ONNX-Runtime)
• tags: per leietaker, per region, per utrullingsnivå
• lineage: overordnet modell, datasett for finjustering, plan for gjentrening

Kundens utrullingsmanifest (ioasc-deployment.yaml) angir hvilke modeller som er aktive på hvilken node og med hvilken prioritet — kjøretiden henter dem automatisk fra modellregisteret, kjører policyvalidering (etterlevelseskontroll, signaturverifisering) og aktiverer dem i drift uten å avbryte pågående strømmer (kanarieutrulling 5 → 50 → 100 % av trafikken).

6. Sikkerhetsarkitektur

Løsningen er fullt forenlig med EU-lovgivningen, cybersikkerhetsloven (slovakisk lov nr. 69/2018 som endret ved lov nr. 366/2024 — gjennomføringen av NIS2) og forskrifter fra Slovakias nasjonale sikkerhetsmyndighet. Programvaresystemet omfatter derfor:

• automatisert beregning av risikoverdi (hybrid FAIR/CVSS-modell)
• trusselanalyse (STRIDE per komponent, kobling mot MITRE ATT&CK)
• kontinuerlige penetrasjonstester med automatisert rapportflyt inn i SOC-en
• eget overvåkingssystem for sikkerhetshendelser og -avvik (SIEM-liknende)
• døgnbemannet sikkerhetsoperasjonssenter (SOC)

Implementeringen omfatter også peer-to-peer blokkjedeverifisering av autoritet for de enkelte komponentene i nettet — hver node bærer en kryptografisk identitet med sertifikat i klyngens tillitskjede. Enhver konfigurasjonsendring, modellutrulling eller tilkobling av en ny node registreres i en distribuert hovedbok, noe som i vesentlig grad minimerer risikoen for informasjonslekkasje, uautorisert omkonfigurering eller annen form for misbruk.

7. Utrullingsscenarier

Implementeringen er modulær: kunden starter typisk med en frittstående enhet eller et PCIe-kort (rask pilotfase, ROI < 9 måneder) og utvider senere til en full klynge uten å måtte omkonfigurere allerede utrullede noder.

8. Konklusjon

IOAS Security Cluster representerer konvergensen av tre utviklingstrekk: KI-akselerasjon på kanten (240 TOPS @ < 90 W), vertikalt spesialiserte ML-modeller (462+ med aktiv gjentreningslinje) og distribuert og parallell beregning (5 nivåer av parallellitet, P2P-koordinering). Arkitekturen er utformet for å integrere eksisterende kamera- og IoT-infrastruktur uten å tvinge fram utskifting av maskinvare, samtidig som den er fullt forenlig med slovakisk lovgivning og EU-regelverk.

For kommuner som allerede eier et kamerasystem og leter etter en måte å hente ut drifts- og analyseverdi fra det på, tilbyr IOASC veien fra passivt opptak til en aktiv, prediktiv og etterprøvbar sikkerhetsplattform.

Vil du vite mer? Ta kontakt.