NATOn C2-tietomalli: NCIM-toteutus ja tietojenvaihto

NATOn C2-tietomalli — NCIM — on kanoninen semanttinen perusta allianssin komento- ja hallintatietojen vaihtostandardien alla. Siinä missä ADatP-34:n tietorakenteet määrittelevät viestimuodot ja MIP4 IES -NATOn maastandardi maavoimien vaihtoprotokollat, NCIM sijaitsee molempia ylempänä kerroksena: se määrittelee, millaisia asioita C2-operaatiossa on, miten ne liittyvät toisiinsa ja mitä tietoa kustakin on tallennettava. Jokainen operatiivisia tietoja vaihtava NATOn toteutusstandardi kartoittaa rakenteensa NCIM:ään. NCIM:n ymmärtäminen ei siksi ole valinnaista insinööreille, jotka haluavat navigoida NATOn C2-standardien kenttää — se on yhteinen viitekehys, joka tekee NATOn yhteentoimivuuden kattavan oppaan muusta sisällöstä johdonmukaisen.

Mitä NCIM on ja miksi se on olemassa

Allianssin C2-yhteentoimivuusongelma 1990-luvulla ei ollut ensisijaisesti protokollaongelma — se oli semanttinen ongelma. NATO-maat olivat toteuttaneet C2-järjestelmiä, jotka vaihtoivat viestejä, mutta sama kenttä kahden maan järjestelmissä tarkoitti eri asioita. ”Yksikön tilan” ”OPERATIONAL”-arvo yhdessä järjestelmässä kattoi eri valmiuskynnyksen kuin toisessa. Kun järjestelmät vaihtoivat tietoja, tavut vastaanotettiin, mutta merkitystä ei jaettu. Tämä on ongelma, jonka NCIM luotiin ratkaisemaan.

NCIM (NATO C2 Information Model) on allianssin kanoninen käsitteellinen ja looginen tietomalli komento- ja hallintatiedoille. Se määrittelee entiteettityypit, jotka osallistuvat C2-operaatioihin, näiden entiteettien väliset suhteet sekä attribuutit — tietotyyppeineen ja arvoalueineen — jotka jokaisesta entiteettityypistä on tallennettava operatiivisen tietojenvaihdon tukemiseksi. Se ei määrittele siirtomuotoja, verkkoprotokollia tai serialisointia — ne ovat toteutusstandardien vastuulla, jotka viittaavat NCIM:ään semanttisena auktoriteettinaan.

NCIM:n historia voidaan jäljittää useiden edeltäjien kautta. JC3IEDM (Joint Consultation, Command and Control Information Exchange Data Model) oli allianssin ensimmäinen kattava C2-tietomalli, jonka NATO-maat kehittivät yhteistyönä 1990-luvun lopulla muodollisesti määriteltynä relationaalisena mallina, joka kattoi operatiivisen tiedon koko kirjon. JC3IEDM:n seuraaja oli NC2IEDM (NATO C2 Information Exchange Data Model), joka tarkensi entiteettimallia ja laajensi sen kattamaan yhteisoperaatiot kaikilla domeeneilla. NCIM edustaa nykyistä kehitysvaihetta: malli, joka on rakennettu erillisiksi käsitteelliseksi ja loogiseksi kerrokseksi, joka on linjattu modernien tietoarkkitehtuurin periaatteiden mukaisesti ja joka on suunniteltu kantamalliksi, josta domeenikohtaiset toteutusstandardit johdetaan profiileina.

Suhde muihin NATOn tietostandardeihin on suora. MIP4-tietomalli — joka määrittelee Unit-, Equipment-, Task- ja muut maavoimien C2-vaihdon entiteettityypit — on NCIM:n maadomeenin profiili. ADatP-34:n viestirakenteet on järjestetty NCIM-semantiikan mukaan: kukin ADatP-34-viestityyppi vastaa NCIM-entiteettiesiintymien kuviota. C-BML (Coalition Battle Management Language), konekäsiteltävien käskyjen XML-kieli, käyttää NCIM:n Activity- ja Plan-entiteettityyppejä semanttisena perustanaan. NCIM:n entiteettityyppihierarkian ja suhteiden semantiikan ymmärtäminen tarjoaa siten yhteisen viitekehyksen, jolla MIP4:n, ADatP-34:n ja C-BML:n voi nähdä johdonmukaisena järjestelmänä eikä kolmena itsenäisenä standardina.

NCIM:n entiteettityyppihierarkia

NCIM määrittelee kuusi ylätason entiteettityyppiä. Nämä kuusi tyyppiä kattavat yhdessä jokaisen NATO C2 -operaatiossa esiintyvän tietoluokan, ja jokainen toteutustason tietomallin entiteetti jäljitettään täsmälleen yhteen niistä.

Activity on entiteettityyppi suunnitelluille tai toteutuneille toimenpiteille. Operaatiot (Mission), tehtävät (Task), operaation vaiheet, taistelukosketukset ja raportoidut tapahtumat ovat kaikki NCIM:n Activity-tyyppejä. Activity-tyypillä on alatyyppejä eri toimenpideluokille: Task (Organisationille tai Resourcelle määrätty ohjattu toimenpide), Mission (useita Task-tehtäviä käsittävä ylemmän tason määräys) ja Event (itsestään tapahtunut ilmiö, joka raportoidaan eikä määrätä). Activity-hierarkia on ensisijainen rakenne, jolla operatiiviset käskyt esitetään NCIM-pohjaisissa järjestelmissä.

OperationalObject kattaa entiteetit, joita seurataan, joihin kohdistutaan tai joita valvotaan, mutta jotka eivät itse ole toimijoita. Kohteet, kiinnostusalueet, nimetyt pisteet, uhka-arviot ja vihollisyksiköitä koskevat tiedusteluraportit ovat OperationalObjecteja. Erotus Organisation- ja Resource-tyyppeihin (jotka edustavat identiteetiltään tunnettuja omia tai neutraaleja entiteettejä) on merkittävä: OperationalObjectilla voi olla epävarma identiteetti ja epävarma sijainti, ja se voi olla hypoteesi pikemminkin kuin vahvistettu havainto.

Organisation edustaa henkilöstön jäsentämiä ryhmittymiä komentosuhteineen. Sotilasyksiköt kaikilla portailla (joukkue, komppania, pataljoona, prikaati, divisioona) ovat Organisation-tyyppejä. Organisation-hierarkia tallentaa komentorakenteen Organisation-esiintymien välisten ylempi–alempi-suhteiden kautta, ja kullakin Organisationilla on vakiintunut nimitys, organisaatiotyyppi NATO ORBAT -taksonomiasta ja komentosuhde ylempään Organisationiin (komento, tuki, operatiivinen johto, taktinen johto).

Resource kattaa materiaalin ja henkilöstön yksittäisinä nimikkeinä eikä jäsenennyksinä. Tietty ajoneuvo, asejärjestelmä, viestintälaite tai tiettyyn rooliin toimiva yksittäinen henkilö on Resource. Resource-entiteetit liittyvät Organisationeihin määräys- ja varustelusuhteiden kautta — pataljoonalla (Organisation) on siihen liittyviä ajoneuvoja (Resource), ja varustelusuhde kantaa määräyksen tilan ja ajanjakson. Organisationin ja Resourcen välinen ero vastaa suunnilleen yksiköiden ja kaluston eroa taistelujärjestyksessä.

Location on entiteettityyppi kaikelle sijainti- ja geometriatiedolle. NCIM:n suunnittelupäätös tehdä Locationista ensiluokkainen entiteettityyppi — koordinaattien upottamisen sijaan attribuuteiksi muihin entiteettityyppeihin — vaikuttaa merkittävästi toteutukseen. Location-esiintymä kantaa geometrian (piste, murtoviiva, monikulmio, käytävä tai yhdistelmä), koordinaattijärjestelmän, sijainnin epävarmuusarvion, voimassaoloaikavälin ja sijainnin lähteen osoittimen. Muut entiteettityypit referoivat Locationia tunnisteella koordinaattien upottamisen sijaan. Tämä suunnittelu sallii saman Locationin referoimisen useilla entiteeteillä, tukee epävarmuus- ja voimassaolometatietojen liittämistä sijaintitietoon ja mahdollistaa sijaintihistorian mallintamisen Location-esiintymien sarjana, joka liittyy yhteen Organisationiin tai Resourceen.

Plan on entiteettityyppi operatiivisen suunnittelun tuotteille. Operaatiosuunnitelma, operationaalinen käsky, vaihdoskäsky tai operaation konsepti on Plan NCIM:ssä. Plan-entiteettityypillä on alatyyppejä eri suunnittelutuoteluokille, ja se kantaa suhteet niihin Activityihin, joita se ohjaa, niihin Organisationeihin, joita se tehtävöi, ja niihin Locationeihin, jotka se asettaa tavoitteikseen.

Perintärakenne kunkin näiden kuuden tyypin sisällä on toteutuksen kannalta merkittävä. Activity-tyypin sisällä esimerkiksi täysi perintäketju on: Activity → Task → ControlMeasureTask (tehtävä, joka ohjaa hallintatoimenpiteen asettamista tai poistamista) — kukin taso lisää sille ominaisia attribuutteja periessään kaikki attribuutit ylemmältään. Toteutusstandardit valitsevat tarvitsemansa perintäsyvyyden: MIP4 toteuttaa Taskin ja useita sen alatyyppejä; C-BML toteuttaa koko Activity-hierarkian NATO:n taktisen tehtävätaksonomian alkeistehtävätyyppeihin asti.

Operaatiosuunnitelman rakenteet NCIM:ssä

Plan-entiteettityyppi ja sen suhteet Activity-esiintymiin muodostavat NCIM:n rungon operatiivisten suunnittelutuotteiden esittämiseen. Tämän rakenteen ymmärtäminen on välttämätöntä minkä tahansa NATO C2 -järjestelmän toteuttamisessa, jonka on vaihdettava suunnitelmia, käskyjä tai niiden toimeenpanon tilaa.

Ylimmällä tasolla Plan-esiintymä edustaa täydellistä operatiivisen suunnittelun tuotetta — OPLAN, OPORD, FRAGO tai CONOPS. Plan kantaa yksilöivän tunnisteen, luokitus- ja julkaisukelpoisuusmerkinnän, auktoriteetin (Organisation, joka sen antoi), voimassaolojakson ja tilan (luonnos, hyväksytty, korvattu). Planit liittyvät toisiinsa korvausketjun kautta: olemassa olevaa OPLANia muokkaava FRAGO viittaa korvaamaansa OPLANiin ja luo suunnitelmahistorian, jonka avulla järjestelmät voivat rekonstruoida operaation suunnitelman kehityksen.

Plan jäsennetään Phase-esiintymiin — kukin Phase edustaa omaa, määritellyin siirtymäehdoin varustettua erillistä operaatiojaksoa. NCIM:ssä Phase on Activityn alatyyppi, joka liittyy Planiin planContains-suhteen kautta. Phase-esiintymät asetetaan järjestykseen siirtymäehtojen kautta: Phase B -esiintymällä on aloitusehto (startCondition), joka viittaa joko aikaan (D+3) tai tapahtumaan (Phase A:n tavoitteen saavuttaminen). Vaihetason rakenteet esiintyvät ADatP-34:n OPLAN-viestimuodossa ja on toteutettu suoraan C-BML:n käskyedustuksessa.

Kunkin Phasen sisällä Task-esiintymät edustavat määrättyjä toimia. NCIM Task kantaa: yksilöivän tunnisteen, tehtävätyypin NATO:n taktisesta tehtävätaksonomiasta (SEIZE, ATTACK, DEFEND, SCREEN, COVER, SUPPORT BY FIRE ja kymmeniä muita), tehtävöidyn Organisationin tai Resourcen, tavoite-Locationin (joka voi olla piste, alue tai nimetty sijainti), aikarajoitukset (aikaisin aloitus, myöhäisin aloitus, vaadittu valmistuminen), antavan auktoriteetin ja antavan Planin viittauksen. Task–Organisation-suhde on NCIM:n ilmaus siitä, että ”yksikkö X tehtävöidään tavoitteeseen Y” — C2-tietojenvaihdon perusasia.

Objective-esiintymät tarkentavat NCIM:ssä Taskin tarkoitusta: Objective kantaa konkreettisen operatiivisen tavoitteen, jonka saavuttamiseen Task on suunniteltu, ilmaistuna aikaansaatavana tilana (maasto vallattu, vihollinen tuhottu, reitti avattu) eikä pelkkänä maantieteellisenä sijaintina. Erot on merkityksellinen konekäsiteltävissä käskyissä: tehtävän vastaanottava C-BML-järjestelmä voi käyttää Objectiven tilatyyppiä päätelläkseen, milloin tehtävä on valmis, mikä mahdollistaa automatisoidun edistymisraportoinnin ilman ihmistulkintaa.

Constraint-esiintymät liittävät rajoittavia ehtoja Taskeihin ja Planeihin. NCIM:n Constraintit on tyypitetty: ajallinen rajoite rajoittaa toiminnon aikaikkunaa; maantieteellinen rajoite rajoittaa aluetta, jolla resurssi saa toimia; resurssirajoite rajoittaa, mitä varoja tehtävään saa käyttää. Constrainteihin viitataan sekä Task-esiintymistä (yksittäistä tehtävää rajoittaen) että Plan-esiintymistä (koko operaatioon soveltaen). NCIM:n rajoitemalli on semanttinen perusta taistelusääntöjen koodaukselle liittouman C2-järjestelmissä, joiden on sovitettava yhteen yhteentoimivuus kansallisten taistelusääntökäytäntöjen kanssa.

<!-- NCIM Plan / Phase / Task hierarchy — simplified XSD sketch -->
<xs:complexType name="PlanType">
  <xs:sequence>
    <xs:element name="planId"      type="ncim:UniqueIdType"/>
    <xs:element name="authority"   type="ncim:OrganisationRefType"/>
    <xs:element name="phase"       type="ncim:PhaseType" minOccurs="1"
                                   maxOccurs="unbounded"/>
    <xs:element name="constraint"  type="ncim:ConstraintType"
                                   minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="PhaseType">
  <xs:sequence>
    <xs:element name="phaseId"         type="ncim:UniqueIdType"/>
    <xs:element name="phaseNumber"     type="xs:integer"/>
    <xs:element name="startCondition"  type="ncim:ConditionType"/>
    <xs:element name="task"            type="ncim:TaskType"
                                       minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="TaskType">
  <xs:sequence>
    <xs:element name="taskId"        type="ncim:UniqueIdType"/>
    <xs:element name="taskType"      type="ncim:TacticalTaskCodeType"/>
    <xs:element name="taskedUnit"    type="ncim:OrganisationRefType"/>
    <xs:element name="objectiveLoc"  type="ncim:LocationRefType"/>
    <xs:element name="timeWindow"    type="ncim:TimeWindowType"/>
    <xs:element name="objective"     type="ncim:ObjectiveType"
                                     minOccurs="0"/>
  </xs:sequence>
</xs:complexType>

Resurssien ja kaluston mallintaminen

NCIM:n Resource-entiteettityyppihierarkia tarjoaa rakenteet alustojen, kalustokokonaisuuksien ja organisaatioyksiköiden edustamiseen yksittäisinä materiaalinimikkeinä ja henkilöstönä. Resurssien mallintaminen on kriittistä liittouman C2-järjestelmissä, joiden on vaihdettava taistelujärjestystietoja, mukaan lukien kaluston tila ja kykyjulistukset.

Platform on Resource-tyypin päälaji fyysisille järjestelmille — ajoneuvoille, ilma-aluksille, aluksille ja asujärjestelmille. Platform-ilmentymä NCIM:ssä kantaa alustatyyppiviittausta (hallitusta sanastosta, joka on linjattu NATO:n kalustoluokitusten kanssa), sarja- tai rekisteritunnisteen, operatiivisen tilakoodin (täysin tehtäväkykyinen, osittain tehtäväkykyinen, ei tehtäväkykyinen) ja viittauksen nykyiseen Locationiin. Platform-ilmentymät liitetään Organisation-ilmentymiin Equipage-suhteella, joka kantaa määräysjaksoa ja määräystyyppiä (orgaaninen, liitetty, operatiivinen valvonta). Tämä on NCIM:n ilmaisu taistelujärjestysmerkinnälle: Organisation on pataljoona, Platform-ilmentymät ovat ajoneuvoja, ja Equipage-suhteet kirjaavat, mitkä ajoneuvot ovat parhaillaan määrättyinä mihinkin yksiköihin.

Kun yksittäisiä alustoja ei seurata erikseen (tyypillistä pienaseille, viestintälaitteille ja osalle tukikalustoa), NCIM tarjoaa EquipmentSetin: Resource-tyypin alalajin, joka edustaa samankaltaisten esineiden määrää yksittäisten seurattavien esineiden sijaan. EquipmentSet kantaa esinetyypin, määrän, mittayksikön ja yhteenvedon valmiustilan. EquipmentSet-ilmentymiä käytetään logistiikkaraportointitilanteissa, joissa yhteismäärät ovat operatiivisesti merkityksellisempiä kuin yksittäisten esineiden seuranta.

OrganisationUnit yhdistää Resource- ja Organisation-entiteetit, kun tietty tiimi, miehistö tai osasto on esitettävä sekä resurssina (kalustoineen) että organisatorisena elementtinä (komentosuhteineen). Helikopterimiehistö on esimerkiksi OrganisationUnit: sillä on sille määrätty ilma-alus (Resource-suhde) ja raportointihierarkia (Organisation-suhde). NCIM:n OrganisationUnit-alalaji sallii tämän kaksoisidentiteetin luomatta epäjohdonmukaisuutta tietomalliin.

Kyvykkyyksien ilmoittaminen on merkittävä käyttötapaus liittoutuman Resource-mallinnukselle. NCIM tukee Capabilityä attribuuttikategoriana sekä Organisationissa että Resourcessa ja käyttää hallittua sanastoa, joka on linjattu NATO:n kyvykkyysluokituksen kanssa. Yksikön kyvykkyysilmoitus — jotka tehtävätyypit se on varustettu ja koulutettu suorittamaan — esitetään Capability-viittausten joukkona Organisation-ilmentymässä. Liittoutuman suunnittelun aikana Task-Organisation -määritysprosessi käyttää Capability-viittauksia tehtävien yhdistämiseen sopivan kyvykkyyden omaaviin yksiköihin. Automatisoiduissa C2-järjestelmissä tämä yhdistäminen voi olla koneellisesti toteutettavaa; operaattorilähtöisissä järjestelmissä kyvykkyystiedot ohjaavat operaattorin yksikönvalintaa tehtäväntukitoiminnossa.

<!-- NCIM Resource / Equipage — illustrative XML fragment -->
<ncim:Resource xsi:type="ncim:PlatformType">
  <ncim:resourceId>{a4c12f88-3e7b-4d1a-b962-9f0d55c12e34}</ncim:resourceId>
  <ncim:platformType>NATO_EQPT_CODE:CV90</ncim:platformType>
  <ncim:serialId>SE-CV90-0147</ncim:serialId>
  <ncim:operationalStatus>FMC</ncim:operationalStatus>
  <ncim:currentLocation ref="{loc-uuid-0a1b2c}"/>
  <ncim:confidentiality>NATO RESTRICTED</ncim:confidentiality>
  <ncim:releasability>NATO</ncim:releasability>
</ncim:Resource>

<ncim:Equipage>
  <ncim:organisation ref="{org-uuid-battalion-42}"/>
  <ncim:resource     ref="{a4c12f88-3e7b-4d1a-b962-9f0d55c12e34}"/>
  <ncim:assignmentType>ORGANIC</ncim:assignmentType>
  <ncim:validPeriod>
    <ncim:startDTG>2026-06-01T06:00:00Z</ncim:startDTG>
  </ncim:validPeriod>
</ncim:Equipage>

XML- ja JSON-jäsentäminen

NCIM on käsitteellinen ja looginen malli — se määrittelee semantiikan, eikä tavuja. Jäsentäminen langallisiksi muodoiksi kuuluu niille toteutusstandardeille, jotka käyttävät NCIM:ää ylämallinaan. NCIM-semantiikan kartoittaminen XML:ään ja yhä enemmän myös JSON:iin on olennaista kehittäjille, jotka rakentavat vaihtokerroksia liittoutuman järjestelmien välille.

NCIM-pohjaisen vaihdon ensisijainen jäsentämismuoto on XML. NCIM:n XML-skeema on rakennettu XSD-moduulien joukkona, yksi jokaista NCIM-entiteettiryhmää kohden, ja se on järjestetty yhteiseen nimiavaruushierarkiaan. Ylätason nimiavaruus on urn:int:nato:ncim:3 (NCIM-versiolle 3.x), ja kunkin alueen moduulilla on oma alinimiavaruutensa: urn:int:nato:ncim:3:core ydin-entiteeteille, urn:int:nato:ncim:3:land maa-alueen laajennuksille ja niin edelleen. NCIM:n profiileina olevat toteutusstandardit määrittelevät omat nimiavaruuksensa, jotka tuovat mukanaan relevantit NCIM-moduulit ja lisäävät toteutustason rajoituksia (pakolliset kentät, hallitun sanaston rajoitukset, kardinaalisuuden tiivistäminen).

Nimiavaruuksien hallinta NCIM XML:ssä on käytännön haaste. Tyypillinen liittoutuman C2-viesti, joka viittaa entiteetteihin useista NCIM-moduuleista, kantaa viidestä kahdeksaan aktiivista nimiavaruusjulistusta juurielementissä. Riskinä ovat nimiavaruusliitteiden törmäykset, kun useista lähteistä tulevat viestit kootaan yhdeksi kuvaksi: kaksi viestiä voi kumpikin julistaa liitteen ncim mutta kuvata sen eri NCIM-moduulien nimiavaruuksiin. Oikea lähestymistapa on nimiavaruusliitteiden normalisointi viestin sisäänottovaiheessa — ratkaise kaikki nimiavaruusjulistukset niiden kanoniseen URI:hin ja käytä URI-avaimisia nimiavaruuskarttoja liiteavaimisten karttojen sijaan koko käsittelyputkessa.

Taktisissa verkoissa, joissa kaistanleveys on rajallinen, XML:n sanaluonteisuus on merkittävä haitta. NCIM-entiteetti, joka on jäsennetty täydeksi XML:ksi kaikkine nimiavaruusjulistuksineen ja avaus- ja sulkumerkkeineen, voi olla neljästä kuuteen kertaa suurempi kuin olennainen kuormadata. Käytössä on kolme lähestymistapaa:

• EXI (Efficient XML Interchange): W3C:n binäärinen XML-koodaus, joka säilyttää täydellisen XML-semantiikan ja pienentää kokoa 80–95 prosentilla skeeman tiheydestä riippuen. EXI on ensisijainen lähestymistapa rajoitetuille taktisille linkeille, kun XML:n edestakainen muunnettavuus vaaditaan. NCIM-skeemat ovat EXI-yhteensopivia ilman muutoksia.
• Skeemapohjainen pakkaus: schema-tietoisen DEFLATE- tai LZ4-pakkauksen soveltaminen XML-tavuvirtaan. Saavuttaa hyviä pakkaussuhteita (60–75 prosentin koon pienenemä) alhaisemmassa laskennallisessa kustannuksessa kuin EXI mutta ilman todellista binäärimuotoista siirrettävyyttä.
• JSON-jäsentäminen: MIP4-IES:n RESTful-sidos käyttää JSONia yksittäisten objektien esittämiseen ja kuvaa NCIM-entiteettien attribuutit JSON-objektien ominaisuuksiksi. JSON-kuormat ovat 30–40 prosenttia pienempiä kuin vastaava XML, ja ne integroituvat luontevammin nykyaikaisiin REST-asiakaskirjastoihin. Hintana on, että NCIM:n JSON-skeematyökalut ovat vähemmän kypsät kuin XSD-työkalut, ja edestakainen validointi NCIM:n normatiivista mallia vastaan vaatii huolellista skeemanhallintaa.

// NCIM Organisation — JSON representation (MIP4-IES REST binding)
{
  "@type": "ncim:Organisation",
  "objectId": "b7e4a312-9c0f-4a1e-8d53-1f3a8b0c9e21",
  "creatorId": "SYS-NLD-C2-01",
  "createdDTG": "2026-06-25T08:00:00Z",
  "modifiedDTG": "2026-06-25T09:14:37Z",
  "validity": "ACTIVE",
  "designation": "42 BN 1 INF BDE",
  "organisationType": "NATO_ORG:INFANTRY_BATTALION",
  "parentOrganisation": {"ref": "org-uuid-brigade-1"},
  "commandRelationship": "ORGANIC",
  "operationalStatus": "OPERATIONAL",
  "currentLocation": {"ref": "loc-uuid-7f3c2d"},
  "capability": ["CAP:DIRECT_FIRE", "CAP:DEFENSIVE_OPERATIONS"],
  "confidentiality": "NATO CONFIDENTIAL",
  "releasability": ["NLD", "DEU", "POL", "NATO"]
}

NCIM:n toteuttaminen liittoutuman C2-järjestelmässä

Useimmat liittoutuman C2-järjestelmät saavuttavat NCIM-toteutuksen jommalla kummalla polulla: uudella järjestelmällä, joka on suunniteltu alusta alkaen NCIM-semantiikan ympärille, tai kansallisella perinteisellä järjestelmällä, jota mukautetaan liittoutuman yhteentoimivuuteen. Jälkimmäinen tapaus on paljon yleisempi ja haastavampi.

Mukauttimen suunnittelu kansallisille tietomalleille on käytännön lähestymistapa perinteisten järjestelmien integrointiin. Sen sijaan että kansallisen C2-järjestelmän sisäistä tietomallia muokattaisiin vastaamaan NCIM:ää — monivuotinen ponnistus, jossa on merkittävä operatiivinen riski — mukautinmalli keskittää kaikki NCIM-kartoituspäätökset erilliseen mukautinkomponenttiin. Mukautin kääntää kansallisen mallin ja NCIM-yhteensopivien esitysten välillä kaikessa ulkoisessa datanvaihdossa: saapuva liittoutuman data käännetään kansalliseen malliin sisäiseen käyttöön; lähtevä kansallinen data käännetään NCIM:ään liittoutuman vaihtoon. Mukautin on yhteentoimivuuden rajapinta ja ainoa komponentti, jota on muutettava NCIM-peruslinjan päivittyessä.

Mukauttimen suunnittelun tärkein päätös on sen määrittäminen, mitkä NCIM-entiteettityypit tarvitsevat täyden käännöksen ja mitkä matalan käännöksen. Täysi käännös — jossa jokaisella NCIM-attribuutilla on vastaava sisäinen esitys — vaaditaan entiteettityypeille, jotka esiintyvät kaksisuuntaisessa datanvaihdossa. Matala käännös — jossa vain avaintunnisteet ja tilakoodit kuvataan — riittää entiteettityypeille, joita järjestelmä kuluttaa mutta ei koskaan muokkaa tai luo. Suosi täyttä käännöstä Organisationille, Resourcelle (Platform), Activitylle (Task) ja Locationille; matala käännös riittää yleensä Constraintille ja Objectivelle mukautintasolla.

NCIM-CoT-kartoitus vaaditaan järjestelmille, jotka vaihtavat dataa alustojen kanssa, jotka käyttävät Cursor on Targetia (CoT), ATAKin, WinTAKin ja niiden kanssa sidoksissa olevien tilannekuvaustyökalujen käyttämää XML-skeemaa. CoT ei johdu NCIM:stä, mutta niiden välinen kartoitus on käytännössä hyvin määritelty. CoT:n <event>-elementti kuvataan NCIM:n Resourceksi (alustat ja henkilöstö) tai OperationalObjectiksi (tutkajäljet ja yhteydet), ja type-attribuutti kuvataan NCIM:n entiteettityypiksi ja alustatyyppiviittaukseksi. CoT:n <point>-elementti kuvataan NCIM:n Locationiksi (Point-alatyyppi) koordinaattimuunnoksella tarvittaessa (CoT käyttää WGS-84:n desimaaliasteita, joka on yhdenmukainen NCIM:n peruskoordinaattijärjestelmän kanssa). Rakenneero on se, että CoT upottaa paikkatiedon tapahtumaelementtiin, kun taas NCIM ulkoistaa sen Location-entiteetiksi — mukauttimen on luotava Location-ilmentymä jokaisesta CoT-pisteestä sisäänkäännön aikana ja upotettava viitatun Locationin koordinaatit CoT-pisteeseen uloskäännön aikana.

NCIM-MIP-siltaus on yleisin liittoutuman mukautusvaatimus maa-alueen C2-järjestelmille. MIP4:n tietomalli on NCIM:n maa-alueen profiili, joten kartoitus ei ole käännös toisiinsa liittymättömien mallien välillä — se on projektio laajemmasta mallista (NCIM) rajoitettuun profiiliin (MIP4). Keskeiset erot, jotka vaativat kartoituslogiikkaa, ovat: MIP4 käyttää OID:ää (UUID-pohjainen maailmanlaajuisesti yksilöivä tunniste) ensisijaisena tunnisteena, kun taas NCIM käyttää geneeristä UniqueId:ta, jolla voi olla eri koodaus muissa toteutusstandardeissa; MIP4:n BaseObject-inaktivointimalli (kelvollisuuslippu) kuvataan NCIM:n entiteetin kelvollisuusattribuutiksi; ja MIP4:n Location-malli käyttää hieman erilaista epävarmuuden esitystä kuin NCIM:n GeometricExtent-tyyppi. Nämä erot ovat silta ilman tietojen hävikkiä mutta vaativat huolellista reunatapausten toteutusta.

NCIM:n kehitys ja hallinto

NCIM:ää ylläpitää NATO C3 Board (C3B), liittoutuman viestintä- ja tietojärjestelmästandardien hallintoelin. C3B toimii työryhmämallin kautta: C2 Information Exchange Working Group (C2IEWG) on NCIM:n ylläpidosta vastaava elin, jossa ovat mukana NATO-valtioiden puolustusministeriöt, kansalliset puolustuksen ICT-virastot ja edustajat teollisuudesta NATO:n teollisuusfoorumin prosessin kautta.

NCIM-standardien elinkaari noudattaa liittoutuman vakioprosessia: muutosehdotus toimitetaan C2IEWG:lle perusteluineen ja vaikutusarvioineen; työryhmä tarkistaa ehdotuksen yhteensopivuuden riippuvien standardien kanssa (koska muutos NCIM:ssä aaltoilee MIP4:ään, ADatP-34:ään ja C-BML:ään, vaikutusarvion on katettava kaikki kolme); työryhmän hyväksynnän jälkeen ehdotus siirretään jäsenvaltioiden kommentointikauteen; ja kommenttien käsittelyn jälkeen muutos sisällytetään seuraavaan NCIM-versioon ja julkaistaan NCIA:n kautta. Suuret versiohypyt (NCIM 2.x → 3.x) vaativat monivuotisia valmisteluaikoja, koska vaikutus toteutusstandardeihin on porrastettu; pienen reväsessä saman suurversion sisällä julkaistaan vuosittain.

Profiilimekanismi on ensisijainen työkalu tehtäväkohtaisiin laajennuksiin ilman perusmallin muuttamista. Profiili on muodollisesti määritelty rajoitettu tai laajennettu näkymä NCIM:ään tietylle alueelle tai tehtävätyypille. C3B julkaisee profiilit NCIM:n liitteinä saman tarkistus- ja hyväksyntäprosessin läpikäytyään kuin perusmallin muutokset. Profiilimekanismin etuna on, että tehtäväkohtaiset vaatimukset voidaan huomioida — esimerkiksi alustyyppiattribuuttien lisääminen merelliseen C2-profiiliin tai elektronisen sodankäynnin yhteysattribuuttien lisääminen EW-kuvaan — ilman perusmallin paisuttamista tai epäyhteensopivuuksien luomista eri profiileja toteuttavien järjestelmien välille. Useita profiileja toteuttavien järjestelmien on hallittava entiteettityyppiensä joukkoa ja käsiteltävä sulavasti tilanne, jossa kumppanijärjestelmä toteuttaa vain osan käytössä olevista profiileista.

NATO Interoperability Test Toolkit (NITT) on ensisijainen työkalu NCIM-pohjaisten toteutusten vaatimustenmukaisuuden validoimiseen. NITT sisältää testiskriptejä, jotka on järjestetty NCIM-entiteettityypin ja vaihtoskenaarion mukaan (kahdenvälinen maakuva, OPORD-jako, logistiikkatilaraportointi). Jokainen testiskripti määrittelee täsmälliset NCIM-entiteetti-ilmentymät, jotka on vaihdettava, jäsentämismuodon ja väittämät, joiden on pätevän vastaanottavalla puolella. NITT-tulokset ovat CWIX-valmiusarviointien ensisijainen syöte: järjestelmät, jotka epäonnistuvat NITT:ssä skenaariosta, eivät saa siitä hyväksyntää CWIX:ään.

NCIM:n kehitystä seuraaville ohjelmatiimeille käytännön neuvo on: tilaa C2IEWG:n julkaisut kansalliselta puolustuksen standardointiviranomaiseltasi, tarkista ehdotetut muutokset vaikutuksiltaan mukautuskerrokseesi ehdotusvaiheessa (muutoksiin on paljon halvampi vastata ennen niiden hyväksymistä) ja käsittele NCIM-version yhteensovitus sopimusehtona liittoutuman harjoitussopimuksissa — kaikkien osallistuvien järjestelmien toteuttaman NCIM-peruslinjan määrittäminen estää semanttisen hajaantumisen, joka syntyy, kun kumppanit ovat eri pienissä versioissa.

NCIM-hallinnon laajempi suunta heijastaa liittoutuman siirtymää palvelukeskeisiin ja datakeskeisiin arkkitehtuureihin. Viimeaikainen NCIM:n kehitys on keskittynyt FMN:n (Federated Mission Networking) palvelukehyksen kanssa yhteensovittamiseen, JSON-jäsentämisen eksplisiittiseen tukemiseen XML:n rinnalla ja linkitettyjen tietojen mallien (RDF/OWL-esitykset NCIM-entiteettityypeistä) käyttöönottoon, jotka tukevat semanttisen webin integrointia liittoutuman datajakojen toteuttamiseen turvallisuusluokitusten rajojen yli. Nämä suunnat osoittavat, että NCIM kasvaa laajuudeltaan ja merkitykseltään, kun Naton C2-tietoinfrastruktuuri uudistuu — mikä tekee siitä yhä tärkeämmän vertailukohteen kaikille puolustusalan ohjelmille, jotka tähtäävät liittoutuman yhteentoimivuuteen.