Ukraina ei rakentanut yhtä tilannekuvajärjestelmää. Se rakensi tusinan rinnakkain, tulen alla, ja käytti sitten kolme vuotta niiden yhdistämiseen toisiinsa. Lopputulos ei ole siisti arkkitehtuurikaavio — se on ekosysteemi pilvialustoja, tablettisovelluksia, tykistölaskureita ja lennokkivideoputkia, joista jokainen on optimoitu eri tappoketjun kerrokseen, löyhästi yhdistettyinä kourallisella siltoja ja dataformaatteja. Länsimaisille insinööreille, jotka ovat tottuneet yhden päätoimittajan vuosikymmenen kestäviin C2-ohjelmiin, kiinnostava kysymys ei ole se, onko tämä ekosysteemi elegantti. Se ei ole. Kiinnostava kysymys on, miksi se toimii, ja mikä siitä säilyy käännettäessä liittoutumakontekstiin.

1. pino yhdellä silmäyksellä — monta työkalua, yksi tavoite: lyhentää sensori-ampuja-silmukkaa

Jokainen Ukrainan tilannekuvapinon komponentti on olemassa tiivistääkseen aikaa siitä, kun sensori näkee kohteen, siihen, kun ase vaikuttaa siihen. Se on järjestävä periaate, ja se selittää näennäisen pirstaleisuuden. Delta tarjoaa toiminta-alueen tason yhteisen tilannekuvan. Kropyva pyörittää tiedustelu- ja tulenkäyttötyönkulkua pataljoonan tabletilla. GIS Arta -perhe koordinoi hajautettua tykistöä. Lennokkien maa-asemat syöttävät reaaliaikaista videota ja koordinaatteja ylöspäin. Brave1-klusteri on hankinta- ja integrointimoottori, joka jatkaa uusien työkalujen tuottamista.

Mikään näistä ei alkanut suurena yhtenäisenä ohjelmana. Ne kasvoivat vapaaehtoisprojekteista, kansalaisjärjestöjen ponnisteluista ja pienistä yrityksistä, joista jokainen ratkaisi kiireellisen ongelman edessään olevalle joukolle. Standardointi tuli myöhemmin, takautuvasti, käytännön tarpeen ajamana saada lennokkioperaattorin kohdenimitys laskeutumaan samaan kuvaan, jota tykistökomentaja jo katsoi. Tuo järjestys — kyky ensin, integrointi toiseksi — on koko ekosysteemin yksittäinen tärkein rakenteellinen tosiasia.

2. Delta — pilvipohjainen tilannekuvakerros, yhteinen tilannekuva, NATO-harjoitusnäkyvyys

Delta on lähinnä sitä, mitä Ukrainalla on toiminta-alueen laajuisena yhteisenä tilannekuvana. Puolustusministeriön innovaatio-osaston alaisuudessa kehitettynä se on web- ja mobiilialusta, joka kokoaa omat ja vihollisen sijainnit, tiedusteluraportit, sensorisyötteet ja joukkojen tilan yhdeksi kartaksi, joka skaalautuu prikaatin esikunnasta yleisesikuntatasolle. Arkkitehtuuriltaan se on pilvinatiivi: selainasiakas, mobiilisovellukset ja taustajärjestelmä, joka ottaa vastaan raportteja niin ihmisiltä kuin koneilta ja sovittaa ne yhteiseen kohdetietokantaan.

Mikä tekee Deltasta kiinnostavan yhteentoimivuusinsinöörille, on sen datamalli. Sen sijaan että se kytkeytyisi tiukasti johonkin yksittäiseen asiakkaaseen, Delta tarjoaa Delta-formaatin — strukturoidun esityksen entiteeteistä, havainnoista ja päällekkäisistä tasoista, joista muut järjestelmät voivat lukea ja joihin ne voivat kirjoittaa. Tämä irrottaminen on se, mikä antaa tablettisovelluksen, lennokkiaseman ja esikuntaselaimen kaikkien myötävaikuttaa samaan kuvaan jakamatta koodia. Delta on esitelty NATO-yleisöille liittoutuman harjoituksissa, joissa sen standardienmukaiset rajapinnat antavat sen vaihtaa kohteita koalitiojärjestelmien kanssa sen sijaan, että se eläisi kansallisessa siilossa.

3. Kropyva — tykistö- ja tiedustelusovellus, tulenjohtomatematiikka, tablettipohjainen työnkulku

Siinä missä Delta on toiminta-alueen kuva, Kropyva on taistelevan pataljoonan työpinta. Vapaaehtoispohjaisen Army SOS -ponnistuksen rakentamana se toimii ruggeroidulla Android-tabletilla ja niputtaa kaksi tehtävää, jotka länsimaiset armeijat yleensä jakavat erillisiin järjestelmiin: digitaalisen karttapohjaisen tiedusteluraportoinnin ja tykistön tulenjohtolaskennan.

Tulenjohtopuoli on se osa, jonka länsimaiset insinöörit aliarvioivat. Kropyva tekee ballistisen matematiikan — kantaman, atsimuutin ja korjaukset — muuttaen havaitsijan ruutuviitteen ja tunnetun aseaseman ampumaratkaisuksi sekunneissa. Havaitsija merkitsee kohteen karttaan; sovellus laskee ase-kohde-geometrian, soveltaa meteorologiset ja lähtönopeuskorjaukset ja tuottaa datan, jonka tykkimiehistö asettaa. Sama tabletti, joka piirsi tiedustelutason, tuottaa tulitehtävän, romahduttaen työnkulun, joka muualla sisältää eturintaman havaitsijan, tulenjohtokeskuksen ja useita radiovälityksiä, yhdeksi laitteeksi ja yhdeksi operaattoriksi.

Tuo integrointi on tarkoituksellinen. Pitämällä tiedustelun ja tulenkäytön yhdessä sovelluksessa yhdellä tabletilla Kropyva poistaa luovutukset, joissa aika ja tarkkuus vuotavat pois. Sen kohteet ja kohdenimitykset voidaan työntää ylös laajempaan kuvaan, joten paikallisesta tulitehtävästä tulee myös myötävaikutus toiminta-alueen tilannekuvaan.

Keskeinen oivallus: Ukrainan pinon etu ei ole mikään yksittäinen sovellus — se on se, että tykistölaskuri, lennokkisyöte ja esikunnan kartta kaikki kirjoittavat jaettuun entiteettimalliin toistensa sijaan. Datamalli on integrointipiste, ei sovellus. Jokainen sovellus on korvattavissa; kuva ei ole.

4. GIS Arta -suku — hajautettu tulen koordinointi, "tykistön Uber" -malli

GIS Arta on järjestelmä, joka antoi ekosysteemille sen tunnusomaisen mallin. Ennen täysimittaista hyökkäystä suunniteltuna se tarttui vaikeaan hajautettujen järjestelmien ongelmaan: kun on monta sensoria, jotka generoivat kohteita, ja monta erityyppistä ja eri valmiusasteessa olevaa tykkiä, miten sovitat jokaisen kohteen parhaiten sijoittuneeseen, parhaiten soveltuvaan aseeseen nopeasti, ilman inhimillistä pullonkaulaa?

Vastaus tuli tunnetuksi analogiana "tykistön Uber". Kohde tulee järjestelmään mistä tahansa havaitsijalta — tiedustelijalta, lennokilta, tutkalta. Ohjelmisto arvioi, mitkä tuliyksiköt ovat kantaman sisällä, käytettävissä ja sopivia, ja reitittää tehtävän optimaaliselle tykille, aivan kuten kyytipalvelualusta sovittaa matkustajan lähimpään kuljettajaan. Tämän sovittamisen raportoitu vaikutus oli sitoutumisaikajanan dramaattinen tiivistyminen manuaalisen koordinoinnin tyypillisistä kymmenistä minuuteista muutamaan minuuttiin tai vähemmän.

Suvulla on merkitystä, koska GIS Arta -malli — kohtele tulta hajautettuna lähetysongelmana, optimoi jako ohjelmistossa, pidä ihmiset hyväksynnässä reitityksen sijaan — levisi siihen, miten muu ekosysteemi ajattelee kohteen luovutuksesta. Myöhemmät työkalut perivät oletuksen, että kohdenimitys on strukturoitu viesti, joka reititetään, ei puhelu, joka välitetään.

5. lennokkisyötteet ja Brave1 — puolustusteknologiaklusteri, tiedusteluvideo, kohdenimitys

Tämän ekosysteemin sensorikerros on ylivoimaisesti miehittämätön. Tuhannet tiedustelu- ja iskulennokit tuottavat valtaosan tuoreesta kohdedatasta, ja niiden maa-asemat ovat tilannekuvapinon ensiluokkaisia osallistujia, eivät jälkikäteisajatuksia. Lennokkioperaattori, joka katsoo reaaliaikaista videota, voi merkitä koordinaatin ja työntää kohdenimityksen suoraan kuvaan, jossa se tulee tulen koordinoinnin käyttöön sekunneissa.

Brave1 on klusteri, joka teollistaa tämän. Hallituksen tukema koordinointialusta, joka käynnistettiin yhdistämään kehittäjät, sotilasyksiköt ja rahoitus, Brave1 toimii sekä markkinapaikkana että integroinnin pakotteena ukrainalaiselle puolustusteknologialle. Se on paikka, jossa uudet työkalut löydetään, testataan oikeita yksiköitä vastaan ja — ratkaisevasti — työnnetään kohti yhteisten dataformaattien noudattamista, jotta ne voivat liittyä Deltaan ja tulikerrokseen sen sijaan, että niistä tulisi toinen saari. Brave1- ja Delta Marketplace -kanavat ovat se, missä suuri osa tämän ohjelmiston lähteestä ja jakelusta nyt asuu.

Vaikutus on takaisinkytkentäsilmukka: yksikkö tarvitsee kyvyn, pieni tiimi rakentaa sen, Brave1 auttaa ottamaan sen käyttöön ja integroimaan sen, ja säilyvät työkalut konvergoivat yhteiseen datamalliin. Valintapaine, ei keskitetty suunnittelu, tuottaa integroinnin.

6. miten kerrokset vaihtavat dataa — sillat, CoT, API:t, integraatiosaumat ja niiden kitka

Federointi näiden järjestelmien välillä kulkee pienen mekanismijoukon yli. Delta-formaatti ja sen API:t ovat ensisijainen selkäranka: järjestelmät lukevat ja kirjoittavat entiteettejä ja päällekkäisiä tasoja dokumentoitujen rajapintojen kautta. Kun mukana on kolmannen osapuolen ja koalition työkaluja, Cursor-on-Target (CoT) — kevyt XML-tapahtumaskeema, jonka ATAK teki suosituksi — toimii lingua francana, ja sillat kääntävät CoT-tapahtumien ja natiivin Delta-entiteettimallin välillä.

Nämä sillat ovat se, missä kitka asuu. CoT on tapahtumakeskeinen ja löyhästi tyypitetty; Delta-malli on entiteettikeskeinen ja rikkaampi. Toisen kartoittaminen toiseen tarkoittaa päättämistä, miten ohimenevästä CoT-merkistä tulee pysyvä seurattu entiteetti, miten identiteetti ja seurannan laatu säilyvät käännöksessä ja miten välttää päällekkäiset entiteetit, kun kaksi järjestelmää raportoi saman objektin. Jokainen silta on käytännössä mielipiteellinen kääntäjä, ja kaksi siltaa voivat tuottaa hienovaraisesti erilaisia kuvia samoista tapahtumista. Latenssi, kaksoiskappaleiden poisto ja identiteetin sovittaminen ovat toistuvia teknisiä ongelmia — sama ongelmaluokka, jonka mikä tahansa monilähteinen fuusiojärjestelmä kohtaa, ratkaistuna täällä pragmaattisesti ja saumakohtaisesti yhden suuren skeeman sijaan.

7. NATO-yhteentoimivuus — Delta liittoutumalle näkyvänä pintana, standardien yhdenmukaistaminen

Kun ekosysteemin täytyy puhua liittoutumalle, Delta on pinta, jonka se esittää. Sen standardienmukaiset rajapinnat ja harjoitusnäkyvyys tekevät siitä luonnollisen välittäjän kansallisten työkalujen ja koalition C2:n välillä. Sen sijaan että pyydettäisiin NATO-kumppaneita integroitumaan tusinaan ukrainalaista sovellusta, malli on integroitua Deltaan ja antaa Deltan federoida alaspäin Kropyvaan, tulikerrokseen ja lennokkiasemiin.

Tämä on tervettä NATO-yhteentoimivuuskäytäntöä: yksi, hyvin määritelty federointipiste on paljon helpompi sertifioida ja akkreditoida kuin kahdenvälisten integraatioiden verkko. Yhdenmukaistaminen liittoutuman datanvaihtostandardien kanssa — viestiformaattien ja entiteettimallien, joita koalitiojärjestelmät jo käyttävät — on se, mikä antaa ukrainalaisen kohteen näkyä kumppanin kuvassa ja päinvastoin. Työ on käynnissä ja epätäydellistä, mutta arkkitehtoninen vaisto on oikea: keskitä liittoutumalle näkyvä rajapinta yhteen paikkaan ja kovetaa se.

8. opit länsimaiselle C2:lle — iteroi reunalla, oleta heikentyneet yhteydet, irrota sovellukset datamallista

Kolme oppia siirtyvät puhtaasti. Ensinnäkin, iteroi reunalla. Ukrainalaiset työkalut paranivat, koska yksiköt käyttivät niitä päivittäin ja syöttivät korjaukset takaisin pienille tiimeille, jotka toimittivat päivityksiä päivissä, eivät ohjelmasykleissä. Länsimainen päätoimittaja ei voi toistaa sotaa, mutta se voi toistaa silmukan: vie ohjelmisto operaattorien eteen aikaisin ja lyhennä takaisinkytkentäsykliä armottomasti.

Toiseksi, oleta heikentyneet viestiyhteydet. Jokainen tämän pinon sovellus on suunniteltu jatkamaan toimintaansa, kun verkko on häiritty, katkonainen tai poissa — paikallinen laskenta tabletilla, tallenna-ja-välitä-synkronointi, sulava heikkeneminen. Länsimainen C2, joka olettaa luotettavan selkärangan, rakentaa ympäristöön, jota elektroninen sodankäynti ei tarjoa. Suunnittele ensin katkennutta tapausta varten ja kohtele yhteyttä bonuksena.

Kolmanneksi, ja tärkeimpänä, irrota sovellukset datamallista. Syy, miksi tämä pirstaleinen ekosysteemi federoituu lainkaan, on se, että entiteettimalli on sopimus, ja sovellukset ovat vaihdettavissa olevia asiakkaita sille. Länsimainen ohjelma, joka antaa toimittajan protokollan tai käyttöliittymän vuotaa ydintoimialamalliinsa, ostaa itselleen repi-ja-korvaa-ongelman ensimmäisellä kerralla, kun vaatimukset muuttuvat. Ukrainan pragmaattinen, joskus sotkuinen pino sai yhden asian rakenteellisesti oikein — kuvan omistaa datamalli, ei mikään sovellus — ja se on opetus, joka eniten kannattaa tuoda kotiin.