MIP4-IES: NATO-interoperabiliteitsnorm voor grondstrijdkrachten voor softwareontwikkelaars

C2-interoperabiliteit voor grondstrijdkrachten is een van de moeilijkste problemen in defensiesoftware. Luchtoperaties hebben Link 16; maritieme operaties hebben Link 22 en AIS. Maar C2 voor grondstrijdkrachten — de uitwisseling van eenheidposities, taakopdrachten, logistieke status en operationele bevelen tussen nationale landstrijdkrachtsystemen in een coalitie — is historisch gezien een interoperabiliteitszwart gat, waarbij het systeem van elke natie zijn eigen datataal spreekt en informatie-uitwisseling menselijke transcriptie vereist. MIP (Multilateral Interoperability Programme) is specifiek opgericht om dit probleem op te lossen, en MIP4-IES is de huidige implementatienorm.

Wat MIP is en de geschiedenis van MIP4-IES

MIP is een multinationaal programma waarbij vertegenwoordigers van ministeries van defensie en de defensiesoftware-industrie uit meer dan 20 landen betrokken zijn. De missie is het definiëren en onderhouden van het datamodel en de uitwisselingsservicespecificatie waarmee nationale C2-systemen voor landstrijdkrachten operationele gegevens automatisch kunnen uitwisselen — zonder menselijke transcriptie — over coalitie-netwerken. MIP is actief sinds de late jaren negentig en heeft zich ontwikkeld door meerdere grote versies naarmate de omvang en technische aanpak zijn gerijpt.

Het oorspronkelijke datamodel van het programma was JC3IEDM (Joint Consultation, Command and Control Information Exchange Data Model) — een uitgebreid relationeel datamodel dat alle aspecten van landmachtoperaties bestrijkt, van order of battle tot logistiek. JC3IEDM was technisch solide maar praktisch moeilijk te implementeren: de volledigheid en normalisatie maakten zelfs eenvoudige queries complex, en de SOAP-gebaseerde webservice-interface die in vroege MIP-versies was gedefinieerd, was zwaar voor tactische netwerken. MIP4 loste deze problemen op door een vereenvoudigd datamodel te introduceren (het MIP4-datamodel, afgeleid van JC3IEDM maar geoptimaliseerd voor operationeel gebruik) en een moderne service-interface (de Information Exchange Service, IES) — wat ons MIP4-IES geeft.

MIP4-IES is momenteel de verplichte uitwisselingsnorm voor C2-systemen voor landstrijdkrachten in de verwervingsprogramma's van de meeste deelnemende naties. Nieuwe nationale C2-programma's voor landstrijdkrachten die coalitie-interoperabiliteit vereisen, zijn verplicht MIP4-IES te implementeren als voorwaarde voor acceptatie. Dit maakt MIP4-IES-implementatie een verplichte vereiste, geen optionele verbetering, voor elk C2-systeem voor landstrijdkrachten dat bestemd is voor coalitieoperaties.

MIP-datamodel: BaseObject, Unit, Equipment, Task

Het MIP4-datamodel is een objectgeoriënteerd model — een hiërarchie van objecttypen, elk met gedefinieerde attributen, die samen de informatie dekken die nodig is voor C2-interoperabiliteit bij landstrijdkrachten. De wortel van de hiërarchie is BaseObject, waarvan alle andere MIP-objecttypen zijn afgeleid. Het begrijpen van de BaseObject-overerving structuur is de eerste stap in MIP4-datamodelimplementatie.

BaseObject definieert de attributen die gemeenschappelijk zijn voor alle MIP-objecten: een wereldwijd unieke objectidentificatie (OID — een UUID toegewezen bij aanmaak en persistent voor de levenscyclus van het object), de objectmaker-identificatie (welk systeem dit object heeft aangemaakt), aanmaak- en wijzigingstijdstempels, en een geldigheidsvlag (waardoor objecten als inactief kunnen worden gemarkeerd zonder verwijdering). Elk MIP-object in elk systeem dat MIP4 implementeert, heeft deze attributen, die de basis vormen voor deconflictie en synchronisatie tussen systemen.

Unit is het centrale entiteitstype in het MIP-grondstrijdkrachtenmodel. Een Unit-object vertegenwoordigt een organisatorische eenheid — een compagnie, bataljon, brigade of elk ander element van de militaire strijdkrachtstructuur. Belangrijke Unit-attributen zijn onder meer: bovenliggende eenheidsreferentie (de commando-hiërarchieverband), standaardaanduiding (de doctrinaire identifier van de eenheid, zoals "1 BN 22 INF"), operationele status (toegewezen vs. operationeel vs. vernietigd) en locatie (huidige gerapporteerde positie). Het positie-attribuut van het Unit-object is een verwijzing naar een Location-object in plaats van een inline coördinaat — een ontwerp dat de koppeling van onzekerheids informatie, geldigheids tijdvensters en positiehistorie aan de locatiegegevens ondersteunt.

Equipment-objecten vertegenwoordigen individuele materieelobjecten — voertuigen, wapensystemen, communicatieapparatuur — en zijn via een Equipage-relatie geassocieerd met Units. Equipment-objecten bevatten platformtype, operationele status (volledig missiegeschikt, gedeeltelijk missiegeschikt, niet-missiegeschikt) en huidige locatie als het materieel apart van de bovenliggende eenheid wordt gevolgd. Materieel gegevens vormen de basis voor sterkte- en gereedheidsberekeningen in de logistieke planningslaag.

Task-objecten vertegenwoordigen toegewezen missies — de operationele bevelen die de bedoeling van de commandant vertalen naar specifieke eenheidsopdrachten. Een Task-object verwijst naar de betrokken Unit, het taaktype (uit een gedefinieerde opsomming afgestemd op de NAVO-doctrinaire taaxtaxonomie), de doellocatie, de tijden (vroegste start, laatste start, vereiste voltooiing) en de uitgevende autoriteit. Taakgegevens maken de weergave van toegewezen doelstellingen op de COP mogelijk en ondersteunen geautomatiseerde deconflictie van overlappende missieopdrachten.

MIP4-IES service-implementatie: SOAP en REST-interface

De MIP4-IES-servicespecificatie definieert de netwerkinterface waarmee MIP-systemen gegevens uitwisselen. De oorspronkelijke IES-specificatie gebruikte SOAP (Simple Object Access Protocol) webservices — een redelijke keuze voor de periode waarin het werd gespecificeerd, maar een keuze die slecht is verouderd. De huidige MIP4-IES-evolutie omvat een RESTful-binding die sterk de voorkeur verdient voor nieuwe implementatie vanwege de lagere implementatiecomplexiteit en betere prestatiekenmerken op tactische netwerkverbindingen.

Het IES-servicemodel is gebaseerd op gegevensreplicatie in plaats van query-respons. Elk MIP-systeem houdt een lokale kopie bij van de gedeelde gegevensopslag en synchroniseert wijzigingen met peer-systemen via de IES. Wanneer een systeem een MIP-object aanmaakt, wijzigt of inactiveert, publiceert het de wijziging via de IES; peer-systemen ontvangen de wijziging en werken hun lokale gegevensopslagen dienovereenkomstig bij. Dit replicatiemodel is geschikt voor de niet-verbonden en intermittent verbonden netwerkomstandigheden van tactische operaties — elk systeem heeft altijd een lokale kopie van de gegevens en kan blijven functioneren als de netwerkverbinding met peers tijdelijk niet beschikbaar is.

De kernoperaties van IES zijn: GetByOID (een specifiek object ophalen op basis van zijn OID), GetByFilter (alle objecten ophalen die overeenkomen met een filteruitdrukking), PutObject (een nieuw of gewijzigd object publiceren naar peer-systemen) en DeleteObject (een object als inactief markeren). De filtertaal in GetByFilter is een XPath-achtige uitdrukking die wordt geëvalueerd op de MIP XML-objectrepresentatie — implementators dienen filtertekenreeksen programmatisch te genereren vanuit getypte queryparameters in plaats van ze te construeren door tekenreeksaaneenschakeling, wat foutgevoelig is en een potentieel injectiekwetsbaarheid vormt.

Test- en certificeringsproces

MIP4-IES-implementatie wordt gevalideerd via het formele conformiteitstestproces van het programma. Conformiteitstesten worden uitgevoerd bij MIP Working Group-evenementen (IATE's — Interoperability Assessment and Testing Events) waarbij programmadeelnemers hun implementaties meebrengen en bilaterale en multilaterale interoperabiliteitstesten uitvoeren. Het slagen van IATE-testen is vereist voordat een systeem als MIP4-IES-conform kan worden verklaard en geaccepteerd kan worden in coalitie-oefeningen.

De IATE-testsuite dekt datamodelconformiteit (alle verplichte objecttypen en attributen zijn correct geïmplementeerd), service-interface-conformiteit (IES-operaties gedragen zich correct voor alle gedefinieerde testscenario's) en deconflictiegedrag (OID-beheer, conflictoplossing bij gelijktijdige wijzigingen). Voorbereiding op IATE-testen vereist het implementeren van een testclient die alle verplichte MIP-objecttypen kan genereren, alle IES-operaties kan uitvoeren en testresultaten kan rapporteren in het formaat dat vereist is door het MIP-testevaluatiekader.

Ontwikkelteams die MIP4-IES voor het eerst implementeren, moeten aanzienlijke inspanning budgetteren voor testvoorbereiding. Het MIP-datamodel is groot, en het waarborgen van correcte implementatie van alle verplichte attributen en relaties vereist systematische dekkingstesten — niet alleen het testen van het gelukkige pad van de meest voorkomende objecttypen. De meest voorkomende oorzaken van IATE-mislukking bij eerste implementaties zijn: onjuist OID-beheer, onjuiste tijdstempelafhandeling (MIP-tijdstempels gebruiken een specifiek UTC-formaat dat afwijkt van gangbare bibliotheekstandaarden) en onvolledige implementatie van het datamodel voor objecttypen die minder frequent voorkomen bij basisoperaties maar wel worden getest in de IATE-suite.