Maavoimien C2-yhteentoimivuus on yksi puolustusohjelmistojen vaikeimmista ongelmista. Ilmaoperaatioilla on Link 16; merioperaatioilla on Link 22 ja AIS. Mutta maavoimien C2 — yksiköiden sijaintien, tehtävänantojen, logistiikkatilanteen ja operatiivisten käskyjen vaihto koalition kansallisten maavoimajärjestelmien välillä — on historiallisesti ollut yhteentoimivuuden musta aukko, jossa kunkin maan järjestelmä puhuu omaa datakieltään ja tiedon jakaminen edellyttää ihmisen tekemää uudelleenkirjausta. MIP (Multilateral Interoperability Programme) perustettiin nimenomaan ratkaisemaan tämä ongelma, ja MIP4-IES on sen nykyinen toteutusstandardi.
Mikä MIP on ja MIP4-IES:n historia
MIP on monikansallinen ohjelma, johon osallistuu yli 20 maan puolustusministeriöitä ja puolustusohjelmistoteollisuuden edustajia. Sen tehtävänä on määritellä ja ylläpitää tietomallia ja vaihtopalveluspesifikaatiota, jonka ansiosta kansalliset maavoimien C2-järjestelmät voivat vaihtaa operatiivista dataa automaattisesti — ilman ihmisen tekemää uudelleenkirjausta — koalitioverkkojen yli. MIP on ollut toiminnassa 1990-luvun lopulta lähtien ja kehittynyt useiden suurten versioiden kautta sitä mukaa kun sen laajuus ja tekninen lähestymistapa ovat kypsyneet.
Ohjelman alkuperäinen tietomalli oli JC3IEDM (Joint Consultation, Command and Control Information Exchange Data Model) — kattava relaatiotietomalli, joka kattaa maavoimien operaatioiden kaikki osa-alueet kokoonpanosta logistiikkaan. JC3IEDM oli teknisesti pätevä, mutta käytännössä vaikea toteuttaa: sen täydellisyys ja normalisointi tekivät yksinkertaisistakin kyselyistä monimutkaisia, ja varhaisissa MIP-versioissa määritelty SOAP-pohjainen web-palvelurajapinta oli raskas taktisille verkoille. MIP4 ratkaisi nämä ongelmat ottamalla käyttöön yksinkertaistetun tietomallin (MIP4 Data Model, joka on johdettu JC3IEDM:stä mutta optimoitu operatiiviseen käyttöön) ja modernin palvelurajapinnan (Information Exchange Service, IES) — jolloin syntyi MIP4-IES.
MIP4-IES on tällä hetkellä määräysten mukainen vaihtostandardi maavoimien C2-järjestelmille useimpien osallistujamaiden hankintaohjelmissa. Uusien kansallisten maavoimien C2-ohjelmien, jotka edellyttävät koalitioyhteentoimivuutta, on toteutettava MIP4-IES hyväksynnän ehtona. Tämä tekee MIP4-IES:n toteutuksesta pakollisen vaatimuksen — ei valinnaisen lisän — mille tahansa maavoimien C2-järjestelmälle, joka on tarkoitettu koalitio-operaatioihin.
MIP-tietomalli: BaseObject, Unit, Equipment, Task
MIP4-tietomalli on olio-orientoitunut malli — hierarkia objektityyppejä, joista jokaisella on määritellyt attribuutit ja jotka yhdessä kattavat maavoimien C2-yhteentoimivuuteen vaadittavan tiedon. Hierarkian juuri on BaseObject, josta kaikki muut MIP-objektityypit johdetaan. BaseObject-perintärakenteen ymmärtäminen on ensimmäinen askel MIP4-tietomallin toteutuksessa.
BaseObject määrittelee kaikille MIP-objekteille yhteiset attribuutit: globaalisti yksilöllisen objektitunnisteen (OID — luontihetkellä määritetty UUID, joka säilyy objektin koko elinkaaren ajan), objektin luojan tunnisteen (mikä järjestelmä loi tämän objektin), luonti- ja muokkausaikaleimat sekä voimassaolomerkinnän (jonka avulla objektit voidaan merkitä epäaktiivisiksi ilman poistamista). Jokaisella MIP-objektilla missä tahansa MIP4:ää toteuttavassa järjestelmässä on nämä attribuutit, jotka muodostavat perustan järjestelmien väliselle ristiriitojen poistamiselle ja synkronoinnille.
Unit on MIP-maavoimamallin keskeinen entiteettityyppi. Unit-objekti edustaa organisatorista yksikköä — komppaniaa, pataljoonaa, prikaatia tai mitä tahansa muuta sotilasvoiman rakenteen osaa. Keskeisiä Unit-attribuutteja ovat viittaus ylempään yksikköön (komentohierarkialinkki), standardinimitys (yksikön opin mukainen tunniste, kuten "1 BN 22 INF"), operatiivinen tila (alistettu vs. operatiivinen vs. tuhottu) ja sijainti (nykyinen ilmoitettu sijainti). Unit-objektin sijaintiattribuutti on viittaus Location-objektiin eikä sisäänkirjattu koordinaatti — ratkaisu, joka tukee epävarmuustiedon, voimassaoloaikaikkunoiden ja sijaintihistorian liittämistä sijaintitietoon.
Equipment-objektit edustavat yksittäisiä materiaaliesineitä — ajoneuvoja, asejärjestelmiä, viestintävälineitä — ja ne liitetään yksiköihin Equipage-suhteen kautta. Equipment-objektit kantavat alustatyyppiä, operatiivista tilaa (täysin tehtäväkykyinen, osittain tehtäväkykyinen, ei tehtäväkykyinen) ja nykyistä sijaintia, jos kalustoa seurataan erikseen sen emoyksiköstä. Equipment-data on perusta vahvuus- ja valmiuslaskelmille logistiikan suunnittelukerroksessa.
Task-objektit edustavat annettuja tehtäviä — operatiivisia käskyjä, jotka muuntavat komentajan tahdon yksittäisiksi yksikkötehtäviksi. Task-objekti viittaa tehtävän saaneeseen yksikköön, tehtävätyyppiin (määritellystä enumeraatiosta, joka on linjassa NATOn opin mukaisen tehtävätaksonomian kanssa), tavoitesijaintiin, aikoihin (aikaisin aloitus, viimeisin aloitus, vaadittu valmistuminen) ja antavaan viranomaiseen. Task-data mahdollistaa annettujen tavoitteiden näyttämisen COP:lla ja tukee päällekkäisten tehtävänantojen automaattista ristiriitojen poistamista.
OID-hallinta on kriittistä: Globaalisti yksilöllinen objektitunniste (OID) on MIP4:n ristiriitojen poistamisen kulmakivi. Jokaisen MIP-federaation järjestelmän on taattava, että sen määrittämät OID:t ovat globaalisti yksilöllisiä — ei vain yksilöllisiä kyseisessä järjestelmässä, vaan koko federaation laajuisesti. Vakiintunut lähestymistapa on koota OID:t järjestelmäkohtaisesta nimiavaruusetuliitteestä (jonka MIP-ohjelma määrittää) sekä paikallisesti yksilöllisestä tunnisteesta. Järjestelmät, jotka generoivat OID:t ilman asianmukaista nimiavaruuden hallintaa, aiheuttavat ristiriitojen poistamisen häiriöitä, joita on vaikea diagnosoida ja jotka voivat turmella operatiivisen tilannekuvan kaikkien federaation jäsenten osalta.
MIP4-IES-palvelun toteutus: SOAP- ja REST-rajapinta
MIP4-IES-palveluspesifikaatio määrittelee verkkorajapinnan, jonka kautta MIP-järjestelmät vaihtavat dataa. Alkuperäinen IES-spesifikaatio käytti SOAP (Simple Object Access Protocol) -web-palveluita — kohtuullinen valinta sille aikakaudelle, jolla se määriteltiin, mutta valinta, joka on ikääntynyt huonosti. MIP4-IES:n nykyinen kehitysvaihe sisältää RESTful-sidonnan, jota suositellaan vahvasti uusiin toteutuksiin sen alhaisemman toteutusmonimutkaisuuden ja paremman suorituskyvyn vuoksi taktisilla verkkoyhteyksillä.
IES-palvelumalli perustuu datan replikointiin eikä kysely-vastaus-malliin. Jokainen MIP-järjestelmä ylläpitää paikallista kopiota jaetusta tietovarastosta ja synkronoi muutokset vertaisjärjestelmien kanssa IES:n avulla. Kun järjestelmä luo, muokkaa tai poistaa käytöstä MIP-objektin, se julkaisee muutoksen IES:n kautta; vertaisjärjestelmät vastaanottavat muutoksen ja päivittävät paikalliset tietovarastonsa vastaavasti. Tämä replikointimalli soveltuu taktisten operaatioiden katkonaisiin ja ajoittain yhdistettyihin verkko-olosuhteisiin — jokaisella järjestelmällä on aina paikallinen kopio datasta ja se voi jatkaa toimintaansa, vaikka yhteys vertaisjärjestelmiin olisi tilapäisesti poikki.
IES:n ydintoiminnot ovat: GetByOID (hae tietty objekti sen OID:n perusteella), GetByFilter (hae kaikki suodatinlauseketta vastaavat objektit), PutObject (julkaise uusi tai muokattu objekti vertaisjärjestelmille) ja DeleteObject (merkitse objekti epäaktiiviseksi). GetByFilterin suodatinkieli on XPath-tyyppinen lauseke, joka evaluoidaan MIP:n XML-objektiesitystä vasten — toteuttajien tulisi generoida suodatinmerkkijonot ohjelmallisesti tyypitetyistä kyselyparametreista eikä rakentaa niitä merkkijonojen yhdistämisellä, mikä on virhealtista ja potentiaalinen injektiohaavoittuvuus.
Testaus- ja sertifiointiprosessi
MIP4-IES:n toteutus validoidaan ohjelman muodollisen vaatimustenmukaisuustestauksen kautta. Vaatimustenmukaisuustestaus suoritetaan MIP-työryhmän tapahtumissa (IATE — Interoperability Assessment and Testing Events), joihin ohjelman osallistujat tuovat toteutuksensa ja suorittavat kahden- ja monenvälistä yhteentoimivuustestausta. IATE-testauksen läpäiseminen vaaditaan, ennen kuin järjestelmä voidaan julistaa MIP4-IES-yhteensopivaksi ja hyväksyä koalitioharjoituksiin.
IATE-testikokonaisuus kattaa tietomallin vaatimustenmukaisuuden (kaikki pakolliset objektityypit ja attribuutit on toteutettu oikein), palvelurajapinnan vaatimustenmukaisuuden (IES-toiminnot käyttäytyvät oikein kaikissa määritellyissä testiskenaarioissa) ja ristiriitojen poistamisen käyttäytymisen (OID-hallinta, ristiriitojen ratkaisu samanaikaisille muokkauksille). IATE-testaukseen valmistautuminen edellyttää testiasiakasohjelman toteuttamista, joka pystyy generoimaan kaikki pakolliset MIP-objektityypit, suorittamaan kaikki IES-toiminnot ja raportoimaan testitulokset MIP-testinarviointikehyksen edellyttämässä muodossa.
Kehitystiimien, jotka toteuttavat MIP4-IES:n ensimmäistä kertaa, tulisi varata merkittävästi työtä testivalmisteluihin. MIP-tietomalli on laaja, ja kaikkien pakollisten attribuuttien ja suhteiden oikean toteutuksen varmistaminen edellyttää järjestelmällistä kattavuustestausta — ei pelkästään yleisimpien objektityyppien onnellisen polun testaamista. Yleisimmät IATE-virheiden syyt ensitoteutuksissa ovat virheellinen OID-hallinta, virheellinen aikaleimakäsittely (MIP-aikaleimat käyttävät tiettyä UTC-muotoa, joka eroaa yleisten kirjastojen oletuksista) ja tietomallin epätäydellinen toteutus niille objektityypeille, jotka esiintyvät harvemmin perustoiminnassa mutta joita testataan IATE-kokonaisuudessa.