C2-tietomallin standardointi: miksi suljetut skeemat pirstovat taistelutilannekuvan

Kaksi liittolaisyksikköä miehittää vierekkäisiä sektoreita. Molemmilla on nykyaikaiset C2-järjestelmät, jotka syöttävät jälkiä jaettuun operatiiviseen kuvaan. Mutta jaettu kuva on puutteellinen: yhden valtion järjestelmät raportoivat yksikön tunnisteet NATO STANAG 2019 -nimityksinä, toinen kansallisina aakkosnumeerisina koodeina. Yksi koodaa sijainnin MGRS:ssä, toinen desimaaliasteina WGS-84:ssä. Yksi aikaleimaa tapahtumat UTC:ssä millisekunnin tarkkuudella; toinen käyttää paikallista aikaa sekunnin tarkkuudella. Tuloksena on, että yhdessä järjestelmässä luotu jälki joko jää ilmestymättä toiseen tai ilmestyy duplikaattina ristiriitaisella sijainnilla. Tämä ei ole verkko-ongelma. Se on skeemaongelma, ja se toistuu jokaisessa koalitio-operaatiossa, jossa C2-järjestelmät on hankittu erikseen. Tämä artikkeli tarkastelee tuon pirstoutumisen teknisiä juuria ja standardointilähestymistapoja, jotka ratkaisevat sen, alkaen perustavanlaatuisista tietomallipäätöksistä, jotka ratkaisevat, voiko C2-järjestelmä ylipäätään olla yhteentoimiva.

Suljettujen tietomallien hinta koalitio-operaatioissa

Jokainen merkittävä koalitioharjoitus 1990-luvulta lähtien on tuottanut jälkiarviointiraportteja, joissa mainitaan tiedonjakovirheitä, jotka jäljittyvät suoraan skeemojen yhteensopimattomuuteen. Kaava on johdonmukainen: jokainen valtio hankkii C2-järjestelmän omaa vaatimustaan vasten, toimittaja toteuttaa suljetun tietomallin, joka on optimoitu kyseisen valtion doktriinille ja joukkorakenteelle, ja järjestelmä toimii hyvin kansallisissa harjoituksissa. Ongelmat nousevat pintaan sillä hetkellä, kun kahden tai useamman tällaisen järjestelmän on jaettava yhteinen operatiivinen kuva. Kentät, jotka edustavat loogisesti identtisiä käsitteitä, kuten yksikön operatiivinen tila, jäljen raportoitu sijainti tai tehtävän osoitettu prioriteetti, koodataan eri tavalla jokaisessa suljetussa skeemassa. Niiden välinen muunnos vaatii käännöskerroksen, jota kumpikaan toimittaja ei alun perin suunnitellut ja joka on suunniteltava uudelleen jokaiselle uudelle järjestelmäparille.

Operatiivinen hinta kertyy kahdella tavalla. Ensimmäinen on viive: jokainen käännösvaihe, jota ei voida automatisoida, lisää aikaa sensorista vaikuttajaan -silmukkaan. Jälki, jonka eteneminen sensorisolmusta liittolaiskomentajan näytölle kestää 45 sekuntia, on taktisesti hyödytön nopeasti liikkuvassa kohtaamisessa. Toinen hinta on uskollisuuden menetys: kentät, joilla ei ole vastinetta kohdeskeemassa, pudotetaan hiljaisesti. Operatiivinen tila, joka on koodattu "TACON":ksi (tactical control) yhdessä järjestelmässä, muuttuu toisessa tyhjäksi kentäksi tai geneeriseksi "active"-lipuksi, riistäen vastaanottavalta komentajalta tiedon, joka oli lähteessä läsnä. Suuren harjoituksen tai operaation aikana tämä kertynyt tiedonmenetys heikentää tilannetietoisuutta tavoilla, joita on vaikea mitata mutta jotka ovat operatiivisesti merkittäviä.

Myös taloudellinen hinta on huomattava. Monikansallisten C2-integraatio-ohjelmien arviot osoittavat johdonmukaisesti, että räätälöidyt kahdenväliset käännöskerrokset, jotka rakennetaan kerran kutakin järjestelmäparia kohti ja ylläpidetään erikseen jokaista versiopäivitystä varten, muodostavat 20–40 % koalition C2-ohjelman koko integraatiobudjetista. Nämä resurssit käytetään työhön, joka ei tuota uutta suorituskykyä: ne yksinkertaisesti korvaavat jaetun skeeman puuttumisen.

Vakiintuneet standardit: JC3IEDM, APP-6, MIP Data Model -- kattavuus ja aukot

Multilateral Interoperability Programme (MIP) on tuottanut laajimmin omaksutut tietomallistandardit koalition C2:lle. JC3IEDM (Joint Command, Control and Consultation Information Exchange Data Model), joka on ratifioitu ISO-standardiksi, määrittelee normalisoidun relaatioskeeman, joka kattaa yksiköt, kaluston, tilat, toimet, suunnitelmat ja niiden operatiiviset suhteet. Sen entiteetti-suhde-rakenne suunniteltiin tietokannasta tietokantaan -vaihtoon, jossa molemmat järjestelmät ylläpitävät kopioita samoista relaatiotauluista ja synkronoivat muutokset määritellyn replikointiprotokollan kautta. JC3IEDM saavutti merkittävän omaksunnan 2000-luvun puolivälissä koalition C2-integraation kanonisena skeemana, erityisesti ohjelmissa, joihin osallistui useita eurooppalaisia maavoimia.

APP-6 (NATO Military Symbols for Land Based Systems) käsittelee kapeampaa ongelmaa: kuinka esittää sotilasyksiköiden kuvakkeet ja niiden attribuutit johdonmukaisesti liittolaisten näytöillä. APP-6D määrittelee symbolin tunnistuskoodin (SIDC) rakenteen, hierarkian yksikkötyypeistä portaan tasolta alas kalustotyyppiin, ja standardimuuntimet tilalle, koolle ja kuulumiselle. Vaikka APP-6 on tiukasti symboliikkastandardi eikä täysi tietomalli, se määrittelee luettelointijoukot, joihin C2-tietomallin on tukeuduttava esittääkseen yksikkötyypit yksiselitteisesti. C2-järjestelmä, joka käyttää APP-6 SIDC:itä kanonisena yksikkötyypin tunnisteena, voi vaihtaa yksikkösymboliikkaa minkä tahansa samaa tekevän liittolaisjärjestelmän kanssa ilman luettelointikäännöstä.

MIP Data Model (MIM), JC3IEDM:n seuraaja, omaksuu UML-pohjaisen oliomallirakenteen, joka kuvautuu suoremmin nykyaikaisten C2-arkkitehtuurien sanomaperustaisiin vaihtomalleihin. Sen sijaan, että vaadittaisiin jaettua tietokantakäyttöä, MIM määrittelee XML-sidonnan, joka antaa standardinmukaisten järjestelmien vaihtaa tietoa vakiokuljetusten yli. MIM esittelee myös muodollisen versioinnin ja modulaarisen käsiteryhmärakenteen, joka yksinkertaistaa laajennusprosessia. MIM säilyttää kuitenkin merkittävän monimutkaisuuden: täysi tietomalli sisältää useita satoja käsiteluokkia, ja standardinmukaisen MIM-rajapinnan toteuttaminen vaatii edelleen kuukausien integraatiotyön. Kansalliset laajennukset, joita jokainen toteuttava valtio on lisännyt, tarkoittavat, että kaksi MIM-standardinmukaista järjestelmää voivat silti epäonnistua tiedon vaihtamisessa oikein, jos toinen käyttää kansallista laajennusta, jota toinen ei ole toteuttanut.

Miten skeemojen eriytyminen luo viivettä sensorista vaikuttajaan -silmukoissa

Polku sensorin havainnosta toimintakelpoiseen jälkeen liittolaisten näytöllä kulkee useiden tiedonmuunnosvaiheiden läpi, ja skeemojen eriytyminen voi injektoida viiveitä jokaiseen niistä. Tarkastele maatutkaa, joka havaitsee ajoneuvojäljen ja raportoi sen kansalliseen C2-järjestelmäänsä. C2-järjestelmä tallentaa jäljen suljettuun skeemaansa ja yrittää sitten jakaa sen liittolaisjärjestelmän kanssa koalitiolinkin yli. Jos koalitiolinkki käyttää määriteltyä vaihtomuotoa (kuten Link 16 J-sarjan sanomaa tai MIM XML -instanssia), kansallisen C2-järjestelmän on ensin käännettävä sisäinen skeemansa vaihtomuotoon. Jos tätä käännöstä ei ole toteutettu oikein, tai jos kansallinen skeema kantaa kenttiä, joilla ei ole vastinetta vaihtomuodossa, käännösvaihe joko epäonnistuu hiljaisesti tai menettää tietoa.

Vastaanottavalla puolella liittolaisten C2-järjestelmän on käännettävä saapuva vaihtomuoto omaan sisäiseen skeemaansa. Jos vastaanottava järjestelmä käyttää eri versiota vaihtostandardista tai on lisännyt kansallisia laajennuksia, joita lähettäjä ei täytä, vastaanotettu jälki voidaan tallentaa puuttuvilla tai oletusarvoisilla kentillä. Jäljen sijainti, joka saapuu MGRS-muodossa mutta tallennetaan sisäisesti UTM:ssä, muunnetaan oikein vain, jos muunnoslogiikka käsittelee kaikki UTM-vyöhykkeiden reunatapaukset, vaatimus, joka kuulostaa triviaalilta mutta on aiheuttanut todellisia virheitä kenttäkäyttöön otetuissa järjestelmissä vyöhykerajojen lähellä. Jokainen näistä käännösvaiheista vie aikaa: hyvin toteutettu automaattinen käännös lisää millisekunteja; huonosti toteutettu, jonka on jonotettava epävarmat tietueet ihmistarkistukseen, voi lisätä minuutteja.

Kumulatiivinen vaikutus on, että skeemasta aiheutuva viive monihyppyisessä koalition C2-ketjussa -- sensorista kansalliseen järjestelmään, kansallisesta järjestelmästä koalitioyhdyskäytävään, koalitioyhdyskäytävästä liittolaisten kansalliseen järjestelmään, liittolaisjärjestelmästä näytölle -- voi helposti yltää 30–90 sekuntiin jäljelle, jonka pitäisi edetä alle kahdessa sekunnissa. Aikakriittisille kohteille ja aikakriittisille uhkille tämä on ero hyödyllisen jäljen ja historiallisen tietueen välillä. Kuten Cursor on Target -muodon suunnitteluperusteiden yhteydessä käsiteltiin, tehokkaimmat vaihtomuodot ovat niitä, jotka minimoivat käännösetäisyyden lähdeskeeman ja siirtoformaatin välillä.

OWL/RDF-ontologiat polkuna kohti semanttista yhteentoimivuutta

Relaatio- ja UML-pohjaiset tietomallit kuten JC3IEDM ja MIM määrittelevät rakenteen -- mitä kenttiä on olemassa ja miten ne liittyvät toisiinsa -- mutta ne eivät määrittele merkitystä muodossa, josta koneet voivat päätellä. Kaksi eri tavalla nimettyä kenttää kahdessa skeemassa voi edustaa samaa käsitettä; kaksi identtisesti nimettyä kenttää voi edustaa hienovaraisesti eri käsitteitä. Näiden semanttisten yhtäläisyyksien ja erojen havaitseminen ja ratkaiseminen vaatii joko ihmisen asiantuntemusta tai muodollisen semanttisen kerroksen, joka tekee suhteista koneluettavia. OWL (Web Ontology Language) ja RDF (Resource Description Framework) tarjoavat tuon kerroksen.

Sotilaallisen C2-tiedon OWL-ontologia voi esittää JC3IEDM:n entiteettitaksonomian luokkahierarkiana, jossa on muodolliset alaluokkasuhteet. Se voi väittää, että "ARMD-REGT" (panssaroitu rykmentti JC3IEDM:n yksikkötyyppitaksonomiassa) on "LAND-UNIT":n alaluokka, joka on "MILITARY-UNIT":n alaluokka. Vastaanottava järjestelmä, joka tuntee vain "MILITARY-UNIT"-käsitteen, voi silti käsitellä oikein saapuvan tietueen, joka on tyypitetty "ARMD-REGT":ksi, koska ontologian alaluokka-aksioomat kertovat päättelijälle, että jokainen "ARMD-REGT" on "MILITARY-UNIT". Tämä päättelykyky on erityisen arvokas käsiteltäessä kansallisia laajennuksia standarditaksonomioihin: yhden valtion C2-järjestelmän määrittelemä laajennustyyppi voidaan kuvata lähimpään standardiin yläluokkaan jaetussa ontologiassa, antaen vastaanottavien järjestelmien, jotka eivät tunne laajennusta, käsitellä se sulavasti sen sijaan, että ne hylkäisivät tietueen.

OWL/RDF:n käytännön omaksuntaa operatiivisissa C2-järjestelmissä ovat rajoittaneet suorituskyky- ja työkaluhuolet. OWL-päättely suurten operatiivisten tietojoukkojen yli on laskennallisesti kallista, ja päättelyviive on yhteensopimaton reaaliaikaisen jälkien käsittelyn kanssa. Käytännöllisempi lähestymistapa on käyttää OWL-ontologioita suunnitteluaikana varmistamaan ja generoimaan käännössäännöt, jotka sitten käännetään tehokkaaksi ajonaikaiseksi koodiksi -- käyttäen ontologian muodollista semantiikkaa kuvausvirheiden havaitsemiseen ennen käyttöönottoa pikemminkin kuin operaatioiden aikana. Useat NATO:n tutkimusohjelmat ovat osoittaneet tämän lähestymistavan, tuottaen ontologiasta johdettuja käännössääntöjoukkoja, jotka ylittävät käsin kirjoitetut kuvaukset sekä täydellisyydessä että oikeellisuudessa.

API-yhdyskäytävän mallit ajonaikaiseen skeeman kääntämiseen

Riippumatta valitusta kanonisesta tietomallista, käytännön haaste on ajaa skeeman kääntämistä sillä nopeudella, jota operatiivinen ympäristö vaatii. API-yhdyskäytävän malli -- käännöspalvelu, joka sijaitsee jokaisen lähdejärjestelmän ja kanonisen skeemaväylän välissä -- tarjoaa operatiivisesti testatuimman ratkaisun. Jokaisen lähdejärjestelmän integraatio kapseloidaan erilliseen adapteriin, joka kääntää kyseisen järjestelmän natiiviskeemasta kanoniseen skeemaan reaaliaikaisesti. Adapteri on ainoa komponentti, jonka tarvitsee tuntea lähdejärjestelmän suljettu muoto; kaikki muut koalition C2-arkkitehtuurin komponentit puhuvat vain kanonista skeemaa.

Skeemarekisteri on kriittinen infrastruktuurikomponentti, joka tekee API-yhdyskäytävän mallista ylläpidettävän mittakaavassa. Jokainen skeemaversio -- sekä lähdejärjestelmille että kanoniselle mallille -- rekisteröidään versiotunnisteella. Jokainen käännössääntö merkitään tietyllä (lähdeversio, kohdeversio) -parilla, johon se soveltuu. Kun lähdejärjestelmä päivittää skeemansa, vain kyseisen järjestelmän adapteria tarvitsee päivittää; kanoninen skeema ja kaikki muut adapterit pysyvät koskemattomina. Skeemarekisteri toimii myös auditointijälkenä: jokainen käännöskerroksen läpi kulkeva tietue kantaa alkuperätietoa -- lähdejärjestelmän tunniste, lähdeskeeman versio, käännössäännön versio, aikaleima -- joka mahdollistaa minkä tahansa tiedon laatuongelman jälkikäteistutkinnan.

Koalitioympäristöissä, joissa kanoninen skeema on itse kansallisten laajennusten kohteena, API-yhdyskäytävän on myös käsiteltävä päinvastainen suunta: kääntäminen kanonisesta skeemasta takaisin kansallisen järjestelmän suljettuun skeemaan kulutusta varten. Tämä kaksisuuntainen käännösvaatimus kaksinkertaistaa käännössääntöjoukon ja tuo lisähaasteen edustaa kanonisia kenttiä, joilla ei ole vastinetta kohdejärjestelmän kansallisessa skeemassa. Vakiolähestymistapa on koodata tällaiset kentät jäsenneltyyn laajennusblobiin, joka liitetään kohdetietueeseen, säilyttäen tiedon kohdejärjestelmän mahdollista tulevaa päivitystä varten ja varmistaen samalla, että nykyinen järjestelmä voi silti siirtää tietueen ilman virheitä. Sanomaväyläarkkitehtuurin valinta vaikuttaa suoraan siihen, kuinka siististi nämä laajennusblobit voidaan liittää ja välittää eteenpäin.

Hallinto: kuka omistaa kanonisen tietomallin koalitiossa

Tekniset ratkaisut skeeman yhteentoimivuuteen ovat välttämättömiä mutta eivät riittäviä. Jokainen onnistunut koalition tietomallin standardointiohjelma on vaatinut hallintorakenteen, joka määrittelee, kuka voi ehdottaa muutoksia kanoniseen skeemaan, kuka hyväksyy ne, miten kansalliset laajennukset rekisteröidään ja jaetaan, ja mikä on prosessi kansallisten vaatimusten välisten ristiriitojen ratkaisemiseksi. Ilman hallintoa kanoninen skeema ajautuu: jokaisen valtion integraatiotiimi tekee paikallisia muutoksia järjestelmänsä vaatimusten mukaisesti, muutoksia ei koskaan propagoida takaisin jaettuun standardiin, ja kahdessa vuodessa "kanonisella" skeemalla on yhtä monta varianttia kuin on toteuttavia valtioita.

MIP-hallintomalli tarjoaa hyödyllisen viitteen. MIP toimii ohjelmajohtokunnan kautta, jossa on kansalliset edustajat, konfiguraationhallintalautakunnan kautta, joka tarkastelee ja hyväksyy skeemamuutoksia, ja julkaistun julkaisusyklin kautta, jolla on määritellyt taaksepäin yhteensopivuussitoumukset. Muutokset ydinskeemaan vaativat monikansallisen konsensuksen; kansalliset laajennukset ovat sallittuja mutta ne on rekisteröitävä jaettuun laajennusrekisteriin ja tarkasteltava mahdollista sisällyttämistä ydinskeemaan jokaisessa julkaisusyklissä. Tämä hallintomalli on ylläpitänyt JC3IEDM:ää ja MIM:ää yli kahden vuosikymmenen ajan operatiivisessa käytössä kymmenissä toteuttavissa valtioissa, mikä on todiste siitä, että malli on toimiva jopa monikansallisen ohjelman koordinointihaasteiden alla.

Pienemmille koalitioille tai kahdenvälisille ohjelmille, jotka eivät voi ylläpitää MIP-mittakaavan hallintorakennetta, kevyempi vaihtoehto on nimetty tietomallin vastuuhenkilön rooli yhdessä osallistuvista organisaatioista, jolla on muodollinen muutospyyntöprosessi, joka vaatii kaikkien vaikutusten kohteena olevien järjestelmäomistajien hyväksynnän ennen kuin mikään skeemamuutos otetaan käyttöön. Keskeinen vaatimus on, että muutoshallintaprosessi on dokumentoitu ja sitä noudatetaan johdonmukaisesti -- dokumentoimaton muutos kanoniseen skeemaan, joka rikkoo yhden valtion käännösadapterin ilman varoitusta, on juuri sellainen tapahtuma, joka murentaa luottamusta standardointiohjelmaan ja ajaa valtiot takaisin räätälöityihin kahdenvälisiin ratkaisuihin.

Vaiheittainen migraatio: vanhojen järjestelmien käärintä ilman uudelleenkirjoitusta

Useimmat C2-tietomallin standardointiponnistelut kohtaavat saman rajoitteen: vanhoja järjestelmiä, joiden on oltava yhteentoimivia, ei voida kirjoittaa uudelleen. Ne hankittiin pitkäaikaisten sopimusten alla, ne kantavat vuosien operatiivista räätälöintiä, ja niiden korvausaikataulut mitataan vuosikymmenissä. Mikään standardointilähestymistapa, joka vaatii järjestelmän täyttä uudelleenkirjoitusta, ei tule toteutetuksi. Ainoa elinkelpoinen polku on vaiheittainen migraatio adapterikerrosten kautta -- kuristajaviikuna-malli sovellettuna sotilaallisen C2:n integraatioon.

Kuristajaviikuna-lähestymistapa toimii seuraavasti. Käännösadapteri otetaan käyttöön vanhan järjestelmän rinnalle. Adapteri julkaisee standardinmukaisen API-päätepisteen -- joka puhuu kanonista skeemaa -- kaikille ulkoisille kuluttajille. Sisäisesti adapteri lukee vanhan järjestelmän tietokannasta tai sanomaväylästä, soveltaa skeema-auditoinnin aikana dokumentoituja kenttätason käännössääntöjä ja julkaisee standardinmukaiset kanonisen skeeman sanomat jaettuun välittäjään. Ulkoiset järjestelmät integroituvat adapterin kanoniseen rajapintaan, eivät koskaan suoraan vanhaan skeemaan. Vanha järjestelmä jatkaa toimintaansa muuttumattomana. Ajan myötä, kun yksittäiset toiminnalliset alijärjestelmät vanhan alustan sisällä saavuttavat elinkaarensa lopun, ne voidaan korvata uusilla toteutuksilla, jotka puhuvat kanonista skeemaa natiivisti, ja vastaavat käännössäännöt adapterissa poistetaan käytöstä. Lopulta adapteri voidaan poistaa käytöstä kokonaan, mutta ulkoiset rajapinnat ovat pysyneet vakaina koko ajan.

Tämän lähestymistavan käytännön haasteet keskittyvät skeema-auditointivaiheeseen. Vanhoilla C2-järjestelmillä on usein dokumentoimattomia kenttiä, implisiittisiä käytäntöjä, jotka on koodattu sovelluslogiikkaan eikä skeemaan, ja tiedon laatuongelmia, jotka käännösadapterin on käsiteltävä sulavasti -- typistettyjä merkkijonoja, alueen ulkopuolisia numeerisia arvoja, null-kenttiä, joiden ei koskaan pitäisi olla null. Robusti käännösadapteri on sisällettävä validointi- ja sanitointilogiikkaa, joka nappaa nämä ongelmat rajalla ja joko korjaa ne (hyvin ymmärretyissä tapauksissa kuten lopussa oleva tyhjä tila tai virheellinen kirjainkoko) tai lokittaa ne ihmistarkistukseen (tapauksissa, joissa oikea tulkinta on monitulkintainen). Tuon validointilogiikan rakentaminen vaatii suoraa pääsyä vanhan järjestelmän tietoon varjotila-operaation ajaksi -- adapterin ajaminen rinnakkain olemassa olevan vaihtoreitin kanssa ja tulosten vertaaminen kenttä kentältä, kunnes operatiivisesti kriittisten kenttien yhtäpitävyysaste on riittävän korkea oikeuttamaan vaihdon.