Monitasoinen C2-synkronointi: taktisen, operatiivisen ja strategisen tilanteen pitäminen yhdenmukaisena

Yhteinen operatiivinen kuva, joka näyttää identtiseltä jokaisella johtamistasolla, on suunnitteluongelma eikä itsestäänselvyys. Taktinen esikunta päivittää omien joukkojen sijainteja 30 sekunnin välein ja kirjoittaa samaan loogiseen tietovarastoon kuin operatiivinen esikunta, joka antaa uusia ohjausmittareita, ja strateginen taso, joka lähettää päivitettyjä tiedustelupintoja -- silti jokainen näistä tasoista toimii eri viestintäinfrastruktuurilla, eri päivitystahdissa ja eri toleranssilla tiedon vanhenemiselle. Kaikkien kolmen yhdenmukainen pitäminen edellyttää synkrointiarkkitehtuuria, joka eroaa perustavanlaatuisesti kaupallisissa hajautetuissa järjestelmissä käytetyistä replikoiduista tietokannoista. Tässä artikkelissa käydään läpi replikointimallit, ristiriitojen ratkaisustrategiat, kaistanleveyteen sopeutuva aikataulutus, toimivallan delegointimallit ja palautumismenettelyt, jotka muodostavat vankan monitasoisen C2-synkrointiarkkitehtuurin perustan, viitaten fuusio- ja jäljenhallinta-arkkitehtuuriin, joka tuottaa kuvan alun perin.

Miksi monitasoinen synkronointi eroaa arkkitehtuurillisesti yksittäisverkon synkronoinnista

Yksittäisverkon synkronointi -- kahden saman LAN- tai WAN-verkon solmun pitäminen yhdenmukaisena -- toimii oletusten varassa, jotka eivät päde tasojen välillä. LAN-solmuilla on gigabit-yhteys, yhteinen todennus ja kellonsynkronointiprotokolla, joka on tarkka mikrosekunteihin. Kaksivaiheinen sitoumus tai Raft-konsensus voi taata vahvan johdonmukaisuuden, koska todennäköisyys, että kaikki solmut ovat samanaikaisesti tavoitettavissa, on erittäin korkea ja lukon odottamisen kustannus mitataan millisekunteissa. Mikään tästä ei päde taktisen pataljoonan esikunnan ja sen kapeakaistaisen VHF-radioverkon sekä operatiivisen esikunnan välillä, joka on yhteydessä satelliitin kautta 64 kbps:n nopeudella ja 600 ms:n edestakaisella viiveellä.

Tasojen väliset linkit ovat katkonaisia operatiivisen suunnittelun eikä vian takia. Taktiset radiot menevät EMCON-tilaan (päästöjen hallinta). Satelliitti-ikkunat ovat aikataulutettuja ja rajallisia. HF-eteneminen vaihtelee aurinkoaktiivisuuden mukaan. Synkrointiarkkitehtuuri, joka estää kirjoittamisen tai nostaa johdonmukaisuusvirheitä normaalin viestintäkatkoksen aikana, on operatiivisesti mahdoton -- operaattorien on voitava lukea ja kirjoittaa kuvaa omalla tasollaan riippumatta siitä, onko yhteys ylempään tai alempaan tasoon toiminnassa. Tämä vaatimus ohjaa suunnittelua kohti lopullista johdonmukaisuutta hyvin määritellyn ristiriitojen ratkaisun kanssa sen sijaan, että käytettäisiin vahvan johdonmukaisuuden koordinointiprotokolloja, jotka edellyttävät kvorumia.

Kolmas ero on auktoriteettirakenne. Kaupallisessa hajautetussa järjestelmässä mikä tahansa solmu voi kirjoittaa minkä tahansa tietueen, ja viimeinen kirjoitus voittaa on hyväksyttävä (joskin karkea) ristiriitapolitiikka, koska tiedoilla ei ole organisatorista omistajuutta. C2-järjestelmässä taktinen yksikkö omistaa omat manööveriyksiköidensä jäljet, operatiivinen esikunta omistaa tulenjohtamisen koordinaatiotoimenpiteet, ja strateginen taso omistaa tietyt tiedustelutuotteet. Ristiriitojen ratkaisun on kunnioitettava tätä toimivaltahierarkiaa eikä vain suosia uusinta aikaleimaa. Yhteisen operatiivisen kuvan tietomallin on koodattava toimivaltarajat jokaiselle entiteettityypille jo alkuperäisessä suunnitteluvaiheessa.

Tietojen replikointistrategiat: täysi peilaus, delta-push ja tilauspohjaiset mallit

Täydellinen peilaustiedonsiirto välittää tietoalueen täydellisen tilan kaikille tasoisolmuille konfiguroidulla syklillä. Se sopii pienille, harvoin muuttuville viitetietojoukoille: yksikön tehtäväorganisaatio, taajuusmäärittelyt, kutsutunnusaikataulut ja kryptografisten avainten aikataulut. Lähetyskustannus on ennakoitavissa, vastaanottava solmu voi rakentaa paikallisen varastonsa uudelleen mistä tahansa synkrointisyklistä lähtien, eikä riippuvuutta aiemmasta tilasta ole. Haitta on ilmeinen: suuren operatiivisen kuvan täydellisen peilin lähettäminen 9,6 kbps:n HF-linkin yli on epäkäytännöllistä. Kuva, jossa on 5 000 jälkeä, kukin 200 tavun tietueena, on yhteensä 1 Mt -- yli 14 minuutin lähetys täydellä linkin kapasiteetilla, joka syrjäyttää kaiken muun liikenteen.

Delta-push-replikointi ratkaisee kaistanleveysongelman lähettämällä vain muutokset viimeisestä vahvistetusta synkrointipisteestä lähtien. Jokaiselle muutostapahtumalle annetaan monotonisesti kasvava järjestysnumero omassa tietoalueessaan. Vastaanottava solmu vahvistaa käsittelemänsä korkeimman järjestysnumeron jokaisen synkrointisyklin jälkeen. Seuraavalla syklillä lähettäjä hakee tapahtumalogikseen kaikki tapahtumat vahvistetun järjestysnumeron yläpuolelta ja lähettää vain ne. 60 sekunnin delta kohtuullisen aktiivisessa toiminta-alueessa sisältää tyypillisesti 50--200 jälkipäivitystapahtumaa, yhteensä muutaman kilotavun. Delta-push on oikea oletus jäljille, raporteille ja graafisille elementeille useimmissa tasojen välisten linkkien konfiguraatioissa. Toteutuksen monimutkaisuus on tapahtumalokimuistin hallinta: lähettäjän on säilytettävä tapahtumat takaisin vanhimpaan vahvistamattomaan järjestysnumeroon kaikissa vertaissolmuissa, mikä voi kattaa tunteja pitkittyneen linkkikatkoksen aikana.

Tilauspohjaisessa replikoinnissa delta-mallia laajennetaan sallimalla alempien tasojen ilmoittaa kiinnostuksensa tietoalueen osajoukkoon kaikkien tapahtumien vastaanottamisen sijaan. Prikaatin esikunta, joka tilaa armeijakunnan esikunnasta, saattaa ilmoittaa kiinnostuksensa vain omalle toiminta-alueelleen kuuluviin jälkiin sekä kaikkiin Taso 1 -raportteihin alueesta riippumatta. Tilaussuodatin arvioidaan palvelinpuolella armeijakunnan solmussa ennen lähetystä, mikä vähentää sekä kaistanleveyden kulutusta että vastaanottavan solmun käsittelytaakkaa. Tilausmallit ovat erityisen arvokkaita suurille kuva- ja anturilokialueille, joissa kaiken replikointi jokaiselle tasolle kuluttaisi kohtuuttomasti kaistanleveyttä. Toteutuksen haaste on suodattimen ilmaisuvoima: maantieteelliset rajoituslaatikot ovat yksinkertaisia arvioida, mutta ne saattavat jättää huomiotta taktisesti merkittävät entiteetit, jotka ovat juuri rajan ulkopuolella. Entiteettityyppi- ja prioriteettitasosuodattimet ovat luotettavampia varmistamaan, että kriittistä tietoa ei koskaan suodateta pois.

Ristiriitojen ratkaisu, kun tasot päivittävät samaa entiteettiä itsenäisesti

Ristiriidat syntyvät, kun kaksi tasoisolmua muokkaa samaa entiteettiä yhteyskatkoksen aikana eikä muutoksia voida triviaalisti järjestää aikaleiman perusteella. Aikaleimit yksin eivät riitä ristiriitojen ratkaisuun sotilaallisessa C2-ympäristössä, koska kellonsynkronointi tasojen välillä on saattanut ajautua sekuntien verran radion katkoksen aikana, ja kaksi päivitystä, joita erottaa 500 ms:n kellodrifti, on saatettu tehdä operaattorien toimesta, jotka eivät todella tienneet toistensa toimista. Versiovektori -- entiteettikohtainen tietorakenne, joka tallentaa jokaisen osallistuvan tason viimeisen järjestysnumeron -- tarjoaa osittaisen järjestyksen päivityshistorioille, joka ei riipu seinäkellotarkkuudesta. Kun vastaanotettu delta sisältää päivityksen, jonka versiovektori ei ole paikallisen versiovektorin jälkeläinen, on olemassa aito samanaikainen muutosristiriita.

Ratkaisupolitiikka riippuu järjestelmän suunnitteluvaiheessa vahvistetusta toimivaltakartasta. Entiteeteille, joilla on selkeä yksi auktoritatiivinen taso, politiikka on deterministinen: auktoritatiivisen tason päivitys sovelletaan, auktoriteettia vailla oleva päivitys arkistoidaan auditointilokiin täydellisin provenienssitiedoin (lähdetaso, operaattorin tunnus, aikaleima, ominaisuusmuutokset) ja ristiriitailmoitus lähetetään molempien tasojen operaattoreille. Ilmoitus on informatiivinen -- auktoritatiivinen ratkaisu on jo sovellettu -- mutta antaa auktoriteettia vailla olevalle tasolle mahdollisuuden arvioida, onko heidän paikallinen arvionsa syytä viedä uudella auktoritatiivisella pyynnöllä komentokanaville. Jaetun tai delegoidun toimivallan entiteeteille -- joukko, joka on tilapäisesti siirretty yhdeltä esikunnalta toiselle -- aluekohtainen yhdistämisfunktio yhdistää kaksi versiota. Sijainti otetaan uudemmasta GPS-pisteestä; ristiriitaiset tilaominaisuudet merkitään operaattorin tarkistettaviksi; jälkihistoria molemmista haaroista säilytetään haaroitettuina merkintöinä.

Kaistanleveyteen sopeutuva synkronointi heikentyneissä tasojen välisissä linkeissä

Tasojen välisen linkin laatu ei ole binaarinen ylös/alas-tila -- se heikkenee jatkuvasti. Satelliittilinkki, joka toimii 64 kbps:n nopeudella normaaliolosuhteissa, saattaa pudota 9,6 kbps:iin ilmakehän heikentymisen aikana, sitten purskemuotoisiin paketteihin 30 sekunnin välein häirinnän aikana ja palautua sitten. Synkrointimootori, joka käsittelee minkä tahansa nominaalista alhaisemman nopeuden vikana ja asettaa kaikki lähetykset odottamaan myöhempää, saapuu linkin palautumiseen massiivisella jonolla, joka tulvii linkin ja viivästyttää kriittisimpiä päivityksiä. Kaistanleveyteen sopeutuva synkronointi reagoi mitattuun linkin siirtonopeuteen reaaliajassa, jatkuvasti uudelleenpriorisoiden ja -aikatauluttaen lähetykset toimittaakseen operatiivisesti kriittisimmät tiedot käytettävissä olevan kapasiteetin puitteissa.

Prioriteettitasoluokittelu ohjaa adaptiivista aikataululuojaa. Taso 1 -- havainturaportit havituista vihollisen liikkuvista elementeistä, aktiiviset tulitehtävät, hätätappio- ja ensiapuraportit sekä välittömät tehtävänsiirrot -- lähetetään heti kun linkin kapasiteetti riittää yhdelle paketille, ja lähetystä yritetään uudelleen jokaisessa käytettävissä olevassa aikavälessä kunnes vahvistettu. Taso 2 -- omien joukkojen sijainnit, logistiikan tilapäivitykset, graafisten elementtien muutokset ja rutiinitilanneraportit -- lähetetään syklillä, joka pitenee 30 sekunnista 5 minuuttiin linkin siirtonopeuden laskiessa konfiguroitavien kynnysarvojen alle. Taso 3 -- historialliset jälkitoisinnot, täydet anturilokit, ei-kiireelliset kuvamerkinnät -- asetetaan jonoon ja lähetetään vain kun Taso 1:n ja Taso 2:n jonot on täysin selvitetty. Aikataululuoja valvoo vahvistettua siirtonopeutta passiiviisen liukuvan ikkunan estimaattorin avulla viimeisen 60 sekunnin lähetyshistoriaan perustuen, luokittelemalla aikataulun automaattisesti ilman operaattorin väliintuloa.

Hyötykuorman pakkaus on täydentävä tekniikka, joka moninkertaistaa minkä tahansa käytettävissä olevan kaistanleveyden tehokkuuden. CoT XML, monien C2-järjestelmien taktisten tapahtumien vakiokoodaus, on monisanainen: yksinäinen jälkipäivitystapahtuma, jossa on kymmenkunta ominaisuutta, saattaa ylittää 800 tavua UTF-8 XML:nä. Sama tapahtuma binaarikoodattuna protobuf-viestinä delta-pakkauksella suhteessa edelliseen jälkitilaan vie 50--120 tavua. 9,6 kbps:lla tämä pakkaussuhde muuttaa sen, tavoittaako Taso 1:n havaintoraportti operatiivisen esikunnan 0,7 sekunnissa vai 5 sekunnissa -- ero, jolla on merkitystä aikakriittisessä maalittamisessa. Tasojen väliseen liikenteeseen valitun taktisen viestiväylän tulisi tukea natiivisti binaarista serialisointia ja skeemaversioitua koodausta eikä nojata XML:ään siirtotasoformaatin tehokkuuden osalta.

Toimivallan delegointi: mikä taso omistaa mitkä jäljet ja raportit

Toimivallan delegointi on virallinen mekanismi, jolla ylempi taso tilapäisesti myöntää alemmalle tasolle oikeuden luoda, muokata tai poistaa entiteettitietueita, joita se ei normaalisti omista. Yleisin tapaus on operatiivinen esikunta, joka tilapäisesti delegoi toimivallan tulenjohtamisen koordinaatiolinjojen joukon taktiselle esikunnalle tiettyä operaatiovaihetta varten. Ilman delegointia taktisen esikunnan on reititettävä jokainen tulenjohtamisen koordinaatiopäivitys operatiivisen esikunnan kautta -- lisäten viivettä ja viestintäkuormitusta. Delegoinnin myötä taktinen esikunta kirjoittaa suoraan, ja operatiivinen esikunta vastaanottaa päivitykset tilaajana auktoritatiivisen lähteen sijaan.

Delegoinnin on oltava aikarajoitettu ja laajuudeltaan rajattu synkrointimoottorin konfiguraatiossa, ei vain operatiivisessa käskyssä. Delegointitietue määrittelee myöntävän tason, vastaanottavan tason, entiteettityypit ja maantieteellisen laajuuden, johon se soveltuu, sekä vanhenemisajan. Synkrointimootori valvoo näitä rajoja automaattisesti: delegoidun tason päivitykset laajuuden ja ajan puitteissa hyväksytään auktoritatiivisina; laajuuden ulkopuoliset tai vanhenemisajan jälkeiset päivitykset palaavat normaaliin toimivaltakarttaan. Tämä estää yleisen epäonnistumisen, jossa tiettyä vaihetta varten annettu delegointi jatkuu synkrointimoottorin noudattamana kauan sen jälkeen, kun operatiivinen tilanne on muuttunut, koska kukaan ei manuaalisesti perunut sitä.

Hierarkkinen delegointi -- jossa operatiivinen esikunta delegoi taktiselle esikunnalle, joka sitten aladelegoi komppaniatasolle -- edellyttää synkrointimoottorin ylläpitävän delegointiketjua ja tarkistavan koko ketjun ennen päivityksen hyväksymistä auktoritatiivisena. Aladelegointi ilman alkuperäisen myöntävän tason lupaa on turvallisuus- ja tietojen eheyteen liittyvä riski: komppaniankomentajan ei pitäisi pystyä väittämään toimivaltaa armeijakuntatason tulenjohtamisen koordinaatiotoimenpiteisiin rakentamalla delegointiketjua, jota ylemmällä tasolla ei koskaan hyväksytty. Delegointiskeeman tulisi sisältää maksimisyvyyskenttä, jonka myöntävä taso asettaa estääkseen luvattoman aladelegoinnin.

Palautuminen ja täsmäytys linkin palauttamisen jälkeen

Linkin palautuminen on monimutkaisin tilasiirtymä monitasoisessa synkrointijärjestelmässä, koska molemmilla solmuilla on kertynyt eriytynyttä tilaa eikä kumpikaan tiedä hajaantumisen täyttä laajuutta ennen vesimerkien vaihtoa. Palautumissekvenssin on tasapainotettava nopeus -- operaattoreiden tarvitsema kuvan lähentyminen nopeasti -- ja oikeellisuus -- yhtäkään Taso 1 -päivitystä ei saa hylätä hiljaisesti yhdistämisen aikana. Naiivi lähestymistapa, joka yksinkertaisesti toistaa kaikki puskuroidut tapahtumat järjestyksessä, epäonnistuu kun tapahtumavirta sisältää ristiriitoja, jotka tarvitsevat toimivaltaan perustuvan ratkaisun ennen soveltamistaan, koska järjestyksestä poikkeavan auktoriteettia vailla olevan päivityksen soveltaminen ennen auktoritatiivisen päivityksen saapumista aiheuttaa auktoriteettiresoluution ylikirjoittavan jo sovelletun muutoksen ilman kenenkään ilmoittamista.

Oikea palautumissekvenssi on vaiheistettu. Ensimmäisessä vaiheessa molemmat solmut vaihtavat vain järjestysnumerovesimerkkinsä tietoalueittain -- kompakti kättely, joka selvittää tarkalleen mitä tapahtumia vertaisella puuttuu ilman tapahtumahyötykuorman lähetystä. Tämä vesimerkivaihto valmistuu yhdessä edestakaisessa siirrossa. Toisessa vaiheessa suuremman deltan omaava solmu lähettää odottavat tapahtumansa prioriteettijärjestyksessä: ensin kaikki Taso 1 -tapahtumat täysin vahvistettuna, sitten Taso 2, sitten Taso 3. Vastaanottava solmu soveltaa ristiriidattomat tapahtumat välittömästi live-kuvaan ja asettaa jonoon ristiriitaiset tapahtumat auktoriteettiresoluutiovaihetta varten. Kolmannessa vaiheessa ristiriitaiset tapahtumat ratkaistaan toimivaltakartan mukaan, operaattori-ilmoitukset lähetetään ihmisen tarkistusta vaativille tapahtumille, ja auditointiloki päivitetään ratkaisutuloksella ja operaattorien tunnisteilla. Kaikkien kolmen vaiheen valmistuttua molemmat solmut vaihtavat lopullisen vesimerkin vahvistaakseen saavuttaneensa identtisen peruslinjan, ja normaali delta-push-synkronointi jatkuu siitä pisteestä.

Yksi tärkeä reunatapaus on solmu, joka oli eristetty niin pitkään, että sen tapahtumaloki on osittain karsittu tallennustilanteen vuoksi ennen linkin palautumista. Lokin karsintapolitiikat tulisi suunnitella säilyttämään ainakin Taso 1 -tapahtumat määräämättömästi ja Taso 2 -tapahtumat vähimmäiskonfiguroitavissa olevan säilytysikkunan ajan (tyypillisesti 72--96 tuntia) tallennuspaineesta riippumatta. Jos solmun loki on aidosti katkaistu vertaisen viimeisen vahvistetun vesimerkin alapuolelle, palautumisen on palattava täydelliseen peilaustiedonsiirtoon kyseisellä alueella ennen delta-pushin jatkamista. Synkrointimoottorin tulisi havaita tämä tila automaattisesti vertaamalla vanhinta saatavilla olevaa järjestysnumeroa vertaisen vesimerkiin ja käynnistää täysi peilaustiedonsiirto ilman operaattorin väliintuloa.

Monitasoisen synkronoinnin testaus irrotettuilla harjoitusverkoilla

Monitasoisen synkronoinnin testaus edellyttää verkkotopologiaa, joka voi syöttää hallittuja linkkivikoja, aiheuttaa kellodriftiä ja simuloida kaistanleveyden heikentymistä kussakin tasojen välisessä hypyssä -- olosuhteet, joita on vaikea tai mahdotonta toistaa tavallisessa integraatiotestiympäristössä. Luotettavin lähestymistapa on omistettu harjoitusverkko, jossa on kolme tai useampi solmu, joiden solmujen väliset linkit kulkevat konfiguroitavan verkkoemulaattorin (kuten Linux-pohjainen liikenteenmuokkain tc-netem:llä) kautta, joka voi soveltaa viivettä, pakettihäviötä, kaistanleveysrajoituksia ja purske-ominaisuuksia, jotka vastaavat todellisia radioita, joita järjestelmä käyttää kentällä. Tämän harjoitusverkon tulisi olla pysyvä osa testausinfrastruktuuria, ei ainoastaan ennen suuria harjoituksia koottava.

Testiskenaariossa tulisi järjestelmällisesti harjoitella tärkeimmät vikatilat: 5 minuutin linkkikatkos taktisen ja operatiivisen solmun välillä aktiivisen havaintoraporttisekvenssin aikana, 30 minuutin katkos tarkoituksellisen hyökkäyksen aikana samanaikaisilla tulenjohtamisen koordinaatiopäivityksillä ja 2 tunnin katkos simuloiden satelliittiviestinnän kieltotapahtumaa, jonka aikana kaikki kolme tasoa jatkavat normaalia toimintaa itsenäisesti. Jokaisen palautumisen jälkeen automaattiset testiväittämät varmistavat, että kaikki kolme solmua ovat lähentyneet samaan kuvatilaan, että yhtäkään Taso 1 -tapahtumaa ei näy auditointilokissa hylättynä tai auktoriteettia vailla olevan ratkaisun ylikirjoittamana, että kaikki ristiriidat on ratkaistu toimivaltakartan mukaan ja että vesimerkivaihto on valmistunut vaaditun aikarajan puitteissa. Näiden väittämien tulisi olla koneellisesti varmistettavia ilman operaattorin tarkistusta, jotta synkrointikäyttäytymisen regressiotestaus on osa jokaista build-putkistoa.

Kaostestaus -- vikojen syöttäminen satunnaisiin kohtiin itse täsmäytyksen aikana eikä vain ennen sitä -- on yhtä tärkeää. Linkin katkeaminen toisen vaiheen tapahtumien toiston aikana tai solmun uudelleenkäynnistys auktoriteettiresoluutiovaiheen aikana on jätettävä molemmat solmut johdonmukaiseen, palautumiskykyiseen tilaan. Synkrointimootori tulisi suunnitella idempotenttisen tapahtuman soveltamisen ympärille: saman tapahtuman toistaminen kahdesti on tuotettava sama tulos kuin kerran soveltaminen, jotta osittain valmistunut täsmäytys voidaan aina turvallisesti käynnistää uudelleen viimeisestä vahvistetusta vesimerkistä tuottamatta haamukaksoiskappaleta tai hiljaista tietohäviötä.