În interiorul Corvus.Head: Arhitectura tabloului de bord pentru fuziunea datelor ISR în timp real

Datele de informații, supraveghere și recunoaștere ajung la un post de comandă din douăsprezece direcții simultan. Telemetria UAV se transmite printr-un link radio dedicat. Senzorii de război electronic trimit evenimente de interceptare printr-un flux TCP criptat. Observatorii de artilerie înregistrează referințe de grid vocal sau prin mesagerie digitală. Platformele SIGINT produc rapoarte de entitate îmbogățite la intervale neregulate. Fiecare dintre aceste surse are propriul format, propria cadență de actualizare și propriul profil de fiabilitate. Provocarea nu este achiziționarea datelor — ci interpretarea lor în timp util pentru ca informațiile să influențeze deciziile.

Corvus.Head este tabloul de bord de informații operaționale al Corvus Intelligence, conceput pentru a consolida exact acest tip de date de câmp de luptă multi-sursă într-o singură interfață structurată pentru conducerea militară, echipele de informații și planificatorii operaționali. Acest articol este o prezentare tehnică a modului în care este arhitecturat sistemul: pipeline-ul de ingestie care normalizează fluxuri eterogene, integrarea PowerBI care conduce vizualizările analitice, motorul geospațial care randează hărți termice și puncte fierbinți, stratul de prognoză a tendințelor și topologia de găzduire Azure care menține latența în limite operaționale.

Stratul de ingestie a datelor: normalizarea fluxurilor eterogene de senzori

Prima decizie arhitecturală în orice sistem ISR multi-sursă este cum să absorbi diversitatea formatelor de date din amonte fără a permite ca acea diversitate să se propage în straturile de procesare și vizualizare. Corvus.Head folosește un model de adaptor de sursă: fiecare tip de senzor sau flux primește un serviciu adaptor dedicat a cărui singură responsabilitate este să se conecteze la sursă, să analizeze formatul nativ al acesteia și să emită evenimente canonice normalizate pe o magistrală de mesaje internă.

Schema canonică de evenimente este intenționat minimală. Fiecare eveniment conține: un identificator unic de entitate, un tag de tip sursă, latitudine și longitudine în grade zecimale WGS-84, altitudine în metri deasupra nivelului mediu al mării (null dacă sursa nu raportează altitudinea), direcție și viteză acolo unde sunt disponibile, o etichetă de clasificare (prietenos, ostil, necunoscut, neutru, în așteptare), un marcaj de timp UTC la originea evenimentului și un obiect de metadate în format liber pentru câmpurile specifice sursei care nu se mapează la schema de bază. Câmpurile pe care o sursă nu le poate furniza sunt setate la null, nu estimate — fabricarea datelor la stratul de normalizare este mai periculoasă decât gestionarea valorilor null în aval.

Adaptorii se conectează la sursele lor prin socket-uri TCP, abonamente MQTT, bucle de poll REST sau observatori de file-drop, în funcție de ceea ce suportă fiecare sursă. Eșecul conexiunii este gestionat în interiorul adaptorului cu backoff exponențial; un adaptor eșuat nu blochează niciodată alți adaptori sau magistrala de mesaje. Fiecare adaptor publică pe propriul topic denumit de pe magistrală, astfel încât consumatorii din aval se pot abona selectiv după tipul sursei. Tehnologia magistralei este Apache Kafka pe Azure Event Hubs: semantica grupului de consumatori Kafka permite motorului de fuziune, pipeline-ului analitic și motorului geospațial să consume același flux în mod independent, fără coordonare.

Integrarea PowerBI: de ce a fost ales pentru tablourile de bord de apărare

Stratul de vizualizare analitică al Corvus.Head — grafice, linii de tendință, comparații de perioade și distribuții pe domenii — este construit pe Microsoft PowerBI Embedded rulând pe Azure. Alegerea de a folosi PowerBI în loc de un stack de grafice personalizat este deliberată și merită explicată, deoarece este contraintuitivă pentru inginerii care asociază PowerBI cu business intelligence mai degrabă decât cu aplicații de apărare.

Argumentul practic se reduce la trei capacități. În primul rând, motorul DAX al PowerBI oferă un strat de calcul matur și bine testat pentru metrici calculate: rate de evenimente per celulă de grid pe oră, scoruri de fiabilitate ale surselor, modificări procentuale perioadă-la-perioadă și medii mobile. Replicarea semanticii de calcul la nivel DAX într-un stack de grafice JavaScript personalizat este un efort de inginerie de mai mulți ani care deturnează resursele de la lucrările de integrare a senzorilor care diferențiază cu adevărat platforma.

În al doilea rând, PowerBI Embedded suportă modul DirectQuery împotriva Azure Synapse Analytics, ceea ce înseamnă că tabloul de bord poate interoga tabele analitice pre-agregate fără a încărca date brute de evenimente în browser. Acest lucru menține timpii de răspuns la interogări sub 1,5 secunde pentru ferestre analitice de 90 de zile cu milioane de evenimente — performanță care ar necesita investiții semnificative de infrastructură pentru a fi obținută cu o abordare bespoke.

În al treilea rând, versionarea modelului de date PowerBI și calea de actualizare a rapoartelor sunt înțelese de managerii de programe de apărare care trebuie să mențină rapoarte analitice pe contracte multi-anuale. Definiția raportului PowerBI (.pbix) devine un artefact versionat care poate fi actualizat, revizuit și aprobat fără a reimplementa software-ul de platformă de bază.

Arhitectura de integrare folosește SDK-ul JavaScript PowerBI Embedded pentru a randa rapoarte în interiorul iframe-urilor în shell-ul Corvus.Head. Filtrele de securitate la nivel de rând sunt aplicate la momentul embed-ului folosind atributele de autorizare ale utilizatorului din token-ul de sesiune, asigurând că rapoartele PowerBI afișează doar datele pe care utilizatorul solicitant este autorizat să le vadă — chiar dacă setul de date PowerBI în sine conține corpusul complet.

Motorul geospațial: hărți termice, puncte fierbinți și densitatea evenimentelor

Stratul de afișare geospațial servește un scop diferit față de graficele analitice. Acolo unde PowerBI arată modele agregate în timp, stratul hărții arată unde se întâmplă lucrurile chiar acum și unde s-a concentrat activitatea în ultima perioadă de veghe. Corvus.Head randează trei tipuri de suprapuneri geospațiale deasupra unui strat de hartă de bază: urmele de poziție ale entităților (actualizate prin WebSocket push), hărți termice de densitate a evenimentelor și markere discrete de puncte fierbinți.

Hărțile termice de densitate a evenimentelor sunt calculate pe server folosind un grid de hash spațial cu dimensiune de celulă configurabilă (implicit 500 de metri). Fiecare eveniment care ajunge prin pipeline-ul de ingestie incrementează scorul de densitate al celulei care conține locația sa, ponderat de o funcție de descompunere a recentității — evenimentele mai vechi de șase ore contribuie exponențial mai puțin la scorul celulei. Descompunerea previne ca activitatea istorică să distorsioneze permanent harta termică și asigură că vizualizarea reflectă tabloul operațional actual, nu cel cumulativ istoric.

Grila de hartă termică este recalculată la un interval configurabil (implicit la fiecare 60 de secunde) și trimisă clienților ca un GeoJSON FeatureCollection de poligoane de celule cu atribute de densitate. Browserul randează aceasta folosind un strat de hartă WebGL cu un gradient de culoare cu cinci puncte de la albastru închis (densitate scăzută) prin chihlimbar la roșu (densitate ridicată). Operatorii pot aplica filtre de domeniu — afișând doar evenimentele EW sau doar observațiile UAV — care declanșează o recompilare a gridului pe server filtrată la tipurile de surse selectate. Aceasta evită re-randarea completă a geometriei hărții de bază în browser.

Markerele de puncte fierbinți sunt puncte discrete generate automat când un cluster de evenimente dintr-o singură celulă de grid depășește un prag configurabil în cadrul unei ferestre temporale glisante. Detectorul de puncte fierbinți rulează ca un microserviciu separat care se abonează la magistrala canonică de evenimente și evaluează un algoritm de clustering varianta DBSCAN asupra unei ferestre de evenimente de 30 de minute în derulare. Când un cluster depășește pragul, o înregistrare de punct fierbinte este scrisă în baza de date și transmisă clienților tabloului de bord conectați prin canalul WebSocket push. Punctele fierbinți expiră automat când activitatea clusterului scade sub prag pentru o perioadă susținută.

Prognoza tendințelor: perioade zilnice, săptămânale și lunare

Prognoza tendințelor oferă comandanților o bază cantitativă pentru a anticipa ritmul operațional, mai degrabă decât a reacționa la el. Corvus.Head furnizează prognoze pentru activitatea evenimentelor pe trei perioade — zilnică, săptămânală și lunară — calculate folosind un model de descompunere sezonieră aplicat datelor de serie temporală per celulă.

Pipeline-ul de prognoză rulează pe Azure Databricks în mod programat (orar pentru prognoze zilnice, nocturn pentru săptămânale și lunare). Recuperează ultimele 90 de zile de numărături de evenimente agregate per celulă de grid per interval de timp din Azure Synapse, aplică descompunerea STL (Seasonal-Trend decomposition using LOESS) pentru a extrage componentele sezoniere și de tendință și generează proiecții înainte cu intervale de încredere derivate din varianța reziduală. Rezultatele sunt scrise înapoi în Synapse ca coloane de prognoză pre-calculate pe care PowerBI le poate interoga prin DirectQuery fără a rula descompunerea live.

Alegerea de a pre-calcula mai degrabă decât a calcula la cerere este deliberată. Descompunerea STL pe 90 de zile de date din mii de celule de grid este costisitoare din punct de vedere computațional — rularea la cerere ca răspuns la o interogare a tabloului de bord ar produce o latență inacceptabilă. Pre-calculul mută costul la un job batch programat și menține timpii de răspuns ai interogărilor tabloului de bord sub 1,5 secunde pentru orice interogare de prognoză pe care un utilizator ar putea-o emite.

Arhitectura de filtrare: detalierea pe domeniu și interval de timp

Un tablou de bord care arată totul este la fel de inutil din punct de vedere operațional ca un tablou de bord care nu arată nimic. Arhitectura de filtrare determină dacă comandanții pot izola rapid semnalul relevant pentru decizia lor curentă din zgomotul înconjurător al unui tablou multi-sursă complet.

Corvus.Head implementează filtrarea pe două axe: domeniu (tipul sursei sau clasificarea entității) și interval de timp (ultima oră, ultimele 6 ore, ultimele 24 de ore, ultimele 7 zile sau interval personalizat). Filtrele sunt aplicate pe trei straturi: stratul de interogare API (care preia doar evenimentele corespunzătoare din Synapse), stratul de abonare la magistrala de mesaje (care se abonează doar la topicurile relevante de tip sursă pentru fluxul live WebSocket) și stratul raportului PowerBI (care aplică contextul de filtru DAX tuturor măsurilor). Această abordare pe trei straturi asigură că modificările de filtru sunt reflectate consistent în toate componentele vizuale fără a necesita post-procesarea în browser a unui set de date complet.

Starea filtrului este menținută în shell-ul tabloului de bord ca un obiect de stare serializabil în URL, permițând comandanților să marcheze și să partajeze vizualizări filtrate specifice cu personalul lor. Un ofițer de informații de brigadă poate trimite subordonaților o vizualizare filtrată specifică — evenimente EW, ultimele 6 ore, sectorul nordic — ca URL, iar destinatarii văd o vizualizare filtrată identică când deschid link-ul.

Topologia de găzduire Azure și considerații privind latența

Corvus.Head este găzduit pe Azure Government Cloud (Azure for Government în SUA, regiuni de cloud suverane echivalente pentru națiunile partenere). Topologia de găzduire este proiectată în jurul a trei bugete de latență: aproape în timp real pentru actualizările de poziție ale entităților (țintă: sub 3 secunde end-to-end), răspunsul la interogări analitice (țintă: sub 1,5 secunde pentru interogări pre-agregate) și livrarea de plăci de hartă (țintă: sub 500ms pentru plăcile memorate în cache).

Adaptorii de ingestie și magistrala de mesaje (Azure Event Hubs în modul compatibil Kafka) rulează în aceeași regiune Azure ca sursele de date clasificate, minimizând hopul de rețea dintre sistemele de senzori și stratul de normalizare. Motorul de fuziune și gateway-ul WebSocket sunt implementate ca sarcini de lucru Azure Kubernetes Service în aceeași regiune. Capacitatea PowerBI Embedded și spațiul de lucru Azure Synapse Analytics sunt provizionate în aceeași regiune pentru a evita latența de transfer de date între regiuni la apelurile DirectQuery.

Livrarea plăcilor de hartă folosește Azure Blob Storage cu accelerare Azure CDN pentru plăcile stratului de bază neclasificate. Plăcile de suprapunere clasificate — straturi de adnotare a informațiilor, suprapuneri ale dispozitivului forțelor proprii — sunt servite de la un server de plăci dedicat în interiorul perimetrului securizat care nu folosește CDN. Țintele de timp de răspuns ale serverului de plăci sunt impuse de un monitor de sănătate care alertează echipa de operațiuni dacă livrarea plăcilor p95 depășește 800ms.

Pentru configurațiile implementate înaintat unde conectivitatea Azure este indisponibilă sau nesigură, Corvus.Head suportă un mod de implementare containerizat pe un singur server folosind Docker Compose. În acest mod, stack-ul complet — adaptori de ingestie, motor de fuziune, server de plăci, un broker Kafka local și o bază de date PostgreSQL înlocuind Synapse — rulează pe un server consolidat în cadrul rețelei tactice. PowerBI este înlocuit de un motor analitic ușor folosind specificații de grafice Vega-Lite pre-construite sprijinite de un REST API local. Profilul de latență se schimbă semnificativ în acest mod: fără serviciile gestionate Azure, echipa de operațiuni este responsabilă pentru monitorizarea și scalarea infrastructurii locale, iar unele caracteristici analitice cu adâncime istorică de 90 de zile sunt reduse la un cache local de 30 de zile.

Pas cu pas: integrarea unei noi surse de date în Corvus.Head

Arhitectura adaptorului face din integrarea de noi tipuri de senzori un proces de inginerie repetabil, nu un proiect de integrare bespoke de fiecare dată. Pașii următori descriu calea standard de integrare.

Pasul 1 — Definiți schema sursei și cadența de actualizare. Documentați formatul de date (CoT XML, JSON, protocol binar), rata de actualizare așteptată în mesaje pe secundă și numele de câmpuri autoritare pentru poziție, timp, tip entitate și clasificare. Această definiție a schemei devine contractul pentru adaptor.

Pasul 2 — Implementați adaptorul de ingestie. Scrieți un adaptor specific sursei care se conectează la flux și emite evenimente canonice normalizate pe magistrala de mesaje. Adaptorul gestionează reîncercările de conectare, reasamblarea mesajelor parțiale și autentificarea specifică sursei. Nu trebuie niciodată să blocheze magistrala la eșecul conexiunii.

Pasul 3 — Mapați câmpurile la schema canonică de evenimente. Transformați fiecare mesaj de intrare în formatul canonic de eveniment Corvus.Head. Câmpurile care nu se mapează sunt eliminate la adaptor. Câmpurile pe care sursa nu le poate furniza sunt setate la null, nu fabricate.

Pasul 4 — Configurați regulile de asociere ale motorului de fuziune. Adăugați noul tip de sursă în tabelul de reguli de asociere al motorului de fuziune. Specificați pragul de proximitate spațială și fereastra temporală folosite pentru a asocia rapoartele din această sursă cu urmele existente și setați ponderea de precizie a sursei pentru estimatorul de poziție.

Pasul 5 — Înregistrați sursa în modelul de date PowerBI. Adăugați noul tip de sursă ca valoare de dimensiune în tabelul SourceType. Verificați că filtrele și măsurile DAX existente gestionează noua valoare fără a deteriora rapoartele existente.

Pasul 6 — Validați latența și debitul în staging. Rulați adaptorul împotriva unui replay de date istorice ale sursei la viteză 2x față de timp real. Măsurați latența end-to-end de la primirea mesajului la afișarea pe tabloul de bord. Confirmați că latența p99 rămâne sub 3 secunde și că adâncimea cozii magistralei de mesaje nu crește nelimitat sub sarcină susținută.

Pasul 7 — Activați și monitorizați în producție. Implementați adaptorul cu control prin fanion de caracteristică, astfel încât să poată fi dezactivat fără un rollback dacă apar probleme. Monitorizați coada de mesaje moarte, rata de evenimente per sursă și rata de asociere urmă-raport a motorului de fuziune. O scădere a ratei de asociere sub 80% indică de obicei o nepotrivire de schemă introdusă de o actualizare de firmware a sursei.

Întrebări frecvente