INTEROPERABILITEIT VIA MIP Door: majoor Hans Baltzer, C2SC
In de vorige Intercom zijn de algemene aspecten van MIP (Multilateral Interoperability Programme) vernoemd . Hierin werden o.a. de historie, de organisatie en de ontwikkelcyclus binnen MIP beschreven. In dit artikel wil ik ingaan hoe MIP binnen de KL toegepast wordt om interoperabiliteit tussen de C2-Systemen van verschillende landen te bereiken. Het gaat daarbij vooral om de daadwerkelijke inzet van MIP tijdens combined en joint operaties. Eerst ga ik in op de voorwaarden waaraan een land moet voldoen om mee te kunnen doen met het MIP programma. Daarna komen de aspecten naar voren waar we mee te maken krijgen als men een internationale oplossing gaat koppelen met zijn nationale C2-systeem. Vervolgens komt het punt aan de orde hoe we dit allemaal aan de eindgebruiker willen voorschotelen zodat deze er ook effectief mee kan werken. Als laatste licht ik toe hoe wij binnen het C2 Support Centre de aanloop voor een eventuele inzet van de MIP Gateway zien.
MIP NORMEN
HET MIP CONCEPT
Als Full member heeft Nederland aangegeven de intentie te hebben om de MIP Block 2 oplossing operationeel in te willen zetten. De Block 2 oplossing zal per juli 2006 de fase ingaan van ‘in service’ en dit zal duren tot eind 2008. Voordat MIP ingezet kan worden dienen een reeks van internationale testen doorlopen te worden. Als laatste test is de ‘Operational Level Test’ (OLT) gepland in februari 2006. Als alle testen succesvol zijn afgerond hebben we voldaan aan alle criteria voor Block 2 (zie artikel over MIP testen van majoor Hans Postma).
Eerst wil ik ingaan op de technische aspecten waar je mee te maken krijgt wanneer je gaat werken met MIP. MIP heeft niet als eindproduct een applicatie, maar geeft jou een aantal tools (lees: specificaties) om interoperabiliteit tot stand te brengen. Deze tools zijn ontstaan uit de operationele requirements die zijn opgesteld door de OWG (Operational Working Group) waarin alle full MIP members vertegenwoordigd zijn. Hieruit wordt de SRS (System Requirement Specification) samengesteld door de SEAWG (System Engineering and Architecture Working Group) om dit uiteindelijk om te zetten in de Technische Specificaties
Figuur 1: Concept MIP oplossing
INTERCOM 2006-1
die nodig zijn voor de nationale implementaties. MIP schrijft niet voor welke tools (bv. Oracle of SQL Server 2000) men moet gebruiken of hoe de uiteindelijke user interface eruit moet zien. Dat is allemaal een nationale verantwoordelijkheid, als men uiteindelijk maar voldoet aan de specificaties van MIP. In figuur 1 kan men zien hoe Nederland de MIP oplossing heeft geïmplementeerd. De primaire focus van MIP is interoperabiliteit tot stand te brengen door data uitwisseling via een IP-netwerk. Als basis wordt hiervoor het MIP datamodel ofwel het C2IEDM gebruikt (Command and Control Information Exchange Data Model). Het datamodel beschrijft exact de structuur en het formaat waarin land A met land B data kan uitwisselen. Elk land heeft zijn eigen MCI (MIP Common Interface) met daarbinnen het C2IEDM en het replicatiemechanisme (het rode gearceerde vlak). Nationaal gebruikt Nederland ISIS als Command & Control Systeem. ISIS heeft een eigen datamodel dat niet hetzelfde is als het C2IEDM. Dit houdt in dat we alle data die we uit willen wisselen via MIP moeten ‘vertalen’ van ISIS naar MIP en ook andersom. De complexiteit van deze vertaalslag hangt af in hoeverre de beide datamodellen van elkaar verschillen. Ondanks dat MIP officieel niet verder reikt dan de nationale MCI’s is de laatste jaren de focus van MIP zich toch aan het verbreden en worden de nationale C2-systemen meer betrokken bij de uiteindelijke MIP oplossing. Dit wordt vooral duidelijk uit de uitgebreide testen waarbij ook de nationale C2systemen systemen betrokken zijn (OLT). MIP is gebaseerd op een zogenoemd ‘push’ mechanisme: de zender bepaalt welke informatie hij stuurt, naar wie en wanneer. De ontvanger kan nationaal bepalen dat hij maar beperkt gebruik maakt van de aangeboden informatie. De oorzaak kan zijn omdat het nationale C2-systeem bepaalde informatie niet ondersteunt, dit is een nationale verantwoordelijkheid. Eén van de resultaten van de testen binnen MIP is een capability matrix waarin men kan zien wat bepaalde systemen wel of niet kunnen uitwisselen met het nationale C2-systeem. Van C2IEDM naar C2IEDM moet elk land regelen dat
61
men alles foutloos kan verzenden en ontvangen. Internationaal (via MIP) zijn de specificaties duidelijk. Doordat binnen MIP de intensiteit van het testen vrij hoog ligt worden de specificaties - indien hiertoe aanleiding is steeds verder verfijnd. Vooral de testen waarbij de grenzen van de specificaties worden getest zijn zeer nuttig gebleken. Nederland heeft ervoor gekozen om het nationale C2-systeem ISIS niet rechtstreeks te bouwen op het MIP datamodel. Dit heeft vooral te maken met de complexiteit van het C2IEDM. Het C2IEDM heeft wel als basis gediend voor het ISIS datamodel. Maar doordat de evolutie van ISIS sneller ging dan die van MIP zijn de datamodellen in de loop van de jaren uit elkaar gegroeid. Daar komt bij dat men binnen ISIS ook andere functionaliteiten wilde gebruiken die niet ondersteund werden door MIP of daar nog niet voldoende uitgespecificeerd waren. Het gevolg hiervan is dat we als Nederland de data moeten ‘vertalen’. Als de datamodellen onderling verschillen kan men wel nagaan dat deze vertaalslag een aantal moeilijkheden met zich meebrengt welke niet altijd helemaal opgelost kunnen worden. Wanneer op dit moment nieuwe functionaliteiten binnen ISIS worden geïntroduceerd wordt wel eerst naar het MIP datamodel gekeken zodat de vertaling niet onnodig complex wordt. Momenteel zijn we bezig om nationaal te bekijken wat exact de verschillen tussen de twee datamodellen zijn. Hierna kunnen we kijken wat er veranderd moet worden om ze beter op elkaar af te laten stemmen. Dit kan inhouden dat we nationaal bepaalde zaken moeten aanpassen, maar het kan ook als gevolg hebben dat we vanuit Nederland gaan voorstellen om het MIP datamodel aan te passen. Een bijkomend maar niet onbelangrijk probleem is dat ons nationale datamodel object georiënteerd is en dat het C2IEDM relationeel is. Nationaal gezien kan men MIP binnen de C2WS architectuur zien als TITAAN op het nationale netwerk. Het grijpt in op alle lagen van de architectuur. Het is niet een tool die alleen te maken heeft met de GIS-applicatie (ISIS), maar het grijpt ook in op het Framework en het C2WS datamodel. Het is niet eenvoudig om MIP geïntegreerd binnen het C2WS te laten werken en kleine aanpassingen kunnen grote gevolgen op natio-
Figuur 2: Operationeel gebruik MIP Gateway
62
naal gebied hebben.
KOPPELEN MIP geeft niet aan hoe we nationaal met de MIP Gateway moeten werken; dit is een nationale verantwoordelijkheid. Als bouwer van een bepaalde applicatie wil je graag input hebben van de uiteindelijke gebruiker. Een van de problemen is dat de uiteindelijke gebruiker nog geen ervaring heeft met het digitaal uitwisselen van informatie op internationaal niveau en MIP (nog) geen bekend begrip is bij deze eindgebruikers. Daar komt bij dat men MIP graag geïntegreerd binnen C2WS wil zien en dat het transparant voor de eindgebruiker zou moeten zijn. Dat houdt in dat de gebruiker niet om wil schakelen om zowel met ISIS als met MIP te werken op hetzelfde werkstation. Ik heb het al eerder gehad over de verschillen tussen de beide datamodellen. We hebben ook te maken met verschillende business rules tussen ISIS en MIP (bijvoorbeeld verschil in geometrie van objecten). Het is niet eenvoudig om dit transparant voor de gebruiker te houden.
SYMBOLOGIE Vanuit Nederland leggen we momenteel de nadruk op het uitwisselen van visuele informatie zoals eenheden, activiteiten en plannen. Het uitvoeren van de symbologie testen is een tijdrovende zaak. In deze testen worden alle binnen MIP afgesproken symbolen tussen de C2 systemen uitgewisseld en stuk voor stuk gecontroleerd. Complicerende factor hierbij is dat binnen MIP geen symbologie standaard is afgedwongen: sommige systemen gebruiken APP6a (de NATO standaard), anderen MilStd 2525b (de USA standaard, NLD gebruikt deze standaard ook) en enkele systemen hebben een eigen standaard. Daarnaast zijn de diverse standaarden helaas niet altijd duidelijk genoeg om in een C2 systeem te implementeren. Binnen MIP is daarom veel tijd besteed om een eenduidige omschrijving te maken over onder andere de toegestane geometrie van objecten (lijn, punt, polygon area, etc). Soms kunnen symbolen door de verschillende standaarden/implementaties er verschillend uitzien en toch voor de operationele gebruiker hetzelfde betekenen.
Onderstaand een voorbeeld van een vijandelijke eenheid conform APP6a/MilStd 2525b (links) en de Duitse symbologie standaard (rechts). Een ander plaatje, maar voor de eindgebruikers van de respectievelijke systemen is duidelijk wat de betekenis is. Voor MIP Block 2 is het voldoende als uiteindelijk de beide eindgebruikers een ‘Common Understanding’ hebben over de uitgewisselde informatie.
Figuur 3: Common understanding symbolen
GEBRUIKERS Wanneer we werken met de MIP Gateway hebben we te maken met twee groepen eindgebruikers. Operationele gebruikers De eerste groep gebruikers zijn de operationele gebruikers, de mensen binnen de secties 2/3. Zij zullen moeten werken met de MIP overlays, de zogenaamde OIG’s. Elk land heeft de beschikking over 6 OIG’s (Operational Information Groups): G Friendly and Neutral (Organisational); G Friendly and Neutral (Non-Organisational); G Uncorrelated Enemy and Unknown; G Correlated Enemy and Unknown; G Globally Significant; G Composed (Single) Plan. Technisch gezien kan in iedere OIG elk symbool geplaatst worden. Binnen de OWG is echter afgesproken welke symbolen in welke OIG’s uitgewisseld worden. Technisch beheer De tweede groep gebruikers vinden we binnen de S6 sectie, de technische en management bedienaar van de MIP Gateway. Zij voeren het technisch beheer over de MIP Gateway. Het gaat daarbij om het tot stand brengen van de connectie, het opzetten van informatie contracten met andere landen en het creëren van nieuwe OIG’s. Het eerder genoemde ontbreken van input van de eindgebruikers heeft tot gevolg dat de user interface van de MIP Gateway momenteel minder gebruikersvriendelijk is. Op korte termijn zal dit in samenspraak met de eindgebruiker verbeterd worden. De ‘in service’ periode van een bepaald MIP Block duurt 2 jaar. Nationaal wordt elk jaar een nieuwe suite van het C2-systeem uitge-
INTERCOM 2006-1
men alles foutloos kan verzenden en ontvangen. Internationaal (via MIP) zijn de specificaties duidelijk. Doordat binnen MIP de intensiteit van het testen vrij hoog ligt worden de specificaties - indien hiertoe aanleiding is steeds verder verfijnd. Vooral de testen waarbij de grenzen van de specificaties worden getest zijn zeer nuttig gebleken. Nederland heeft ervoor gekozen om het nationale C2-systeem ISIS niet rechtstreeks te bouwen op het MIP datamodel. Dit heeft vooral te maken met de complexiteit van het C2IEDM. Het C2IEDM heeft wel als basis gediend voor het ISIS datamodel. Maar doordat de evolutie van ISIS sneller ging dan die van MIP zijn de datamodellen in de loop van de jaren uit elkaar gegroeid. Daar komt bij dat men binnen ISIS ook andere functionaliteiten wilde gebruiken die niet ondersteund werden door MIP of daar nog niet voldoende uitgespecificeerd waren. Het gevolg hiervan is dat we als Nederland de data moeten ‘vertalen’. Als de datamodellen onderling verschillen kan men wel nagaan dat deze vertaalslag een aantal moeilijkheden met zich meebrengt welke niet altijd helemaal opgelost kunnen worden. Wanneer op dit moment nieuwe functionaliteiten binnen ISIS worden geïntroduceerd wordt wel eerst naar het MIP datamodel gekeken zodat de vertaling niet onnodig complex wordt. Momenteel zijn we bezig om nationaal te bekijken wat exact de verschillen tussen de twee datamodellen zijn. Hierna kunnen we kijken wat er veranderd moet worden om ze beter op elkaar af te laten stemmen. Dit kan inhouden dat we nationaal bepaalde zaken moeten aanpassen, maar het kan ook als gevolg hebben dat we vanuit Nederland gaan voorstellen om het MIP datamodel aan te passen. Een bijkomend maar niet onbelangrijk probleem is dat ons nationale datamodel object georiënteerd is en dat het C2IEDM relationeel is. Nationaal gezien kan men MIP binnen de C2WS architectuur zien als TITAAN op het nationale netwerk. Het grijpt in op alle lagen van de architectuur. Het is niet een tool die alleen te maken heeft met de GIS-applicatie (ISIS), maar het grijpt ook in op het Framework en het C2WS datamodel. Het is niet eenvoudig om MIP geïntegreerd binnen het C2WS te laten werken en kleine aanpassingen kunnen grote gevolgen op natio-
Figuur 2: Operationeel gebruik MIP Gateway
62
naal gebied hebben.
KOPPELEN MIP geeft niet aan hoe we nationaal met de MIP Gateway moeten werken; dit is een nationale verantwoordelijkheid. Als bouwer van een bepaalde applicatie wil je graag input hebben van de uiteindelijke gebruiker. Een van de problemen is dat de uiteindelijke gebruiker nog geen ervaring heeft met het digitaal uitwisselen van informatie op internationaal niveau en MIP (nog) geen bekend begrip is bij deze eindgebruikers. Daar komt bij dat men MIP graag geïntegreerd binnen C2WS wil zien en dat het transparant voor de eindgebruiker zou moeten zijn. Dat houdt in dat de gebruiker niet om wil schakelen om zowel met ISIS als met MIP te werken op hetzelfde werkstation. Ik heb het al eerder gehad over de verschillen tussen de beide datamodellen. We hebben ook te maken met verschillende business rules tussen ISIS en MIP (bijvoorbeeld verschil in geometrie van objecten). Het is niet eenvoudig om dit transparant voor de gebruiker te houden.
SYMBOLOGIE Vanuit Nederland leggen we momenteel de nadruk op het uitwisselen van visuele informatie zoals eenheden, activiteiten en plannen. Het uitvoeren van de symbologie testen is een tijdrovende zaak. In deze testen worden alle binnen MIP afgesproken symbolen tussen de C2 systemen uitgewisseld en stuk voor stuk gecontroleerd. Complicerende factor hierbij is dat binnen MIP geen symbologie standaard is afgedwongen: sommige systemen gebruiken APP6a (de NATO standaard), anderen MilStd 2525b (de USA standaard, NLD gebruikt deze standaard ook) en enkele systemen hebben een eigen standaard. Daarnaast zijn de diverse standaarden helaas niet altijd duidelijk genoeg om in een C2 systeem te implementeren. Binnen MIP is daarom veel tijd besteed om een eenduidige omschrijving te maken over onder andere de toegestane geometrie van objecten (lijn, punt, polygon area, etc). Soms kunnen symbolen door de verschillende standaarden/implementaties er verschillend uitzien en toch voor de operationele gebruiker hetzelfde betekenen.
Onderstaand een voorbeeld van een vijandelijke eenheid conform APP6a/MilStd 2525b (links) en de Duitse symbologie standaard (rechts). Een ander plaatje, maar voor de eindgebruikers van de respectievelijke systemen is duidelijk wat de betekenis is. Voor MIP Block 2 is het voldoende als uiteindelijk de beide eindgebruikers een ‘Common Understanding’ hebben over de uitgewisselde informatie.
Figuur 3: Common understanding symbolen
GEBRUIKERS Wanneer we werken met de MIP Gateway hebben we te maken met twee groepen eindgebruikers. Operationele gebruikers De eerste groep gebruikers zijn de operationele gebruikers, de mensen binnen de secties 2/3. Zij zullen moeten werken met de MIP overlays, de zogenaamde OIG’s. Elk land heeft de beschikking over 6 OIG’s (Operational Information Groups): G Friendly and Neutral (Organisational); G Friendly and Neutral (Non-Organisational); G Uncorrelated Enemy and Unknown; G Correlated Enemy and Unknown; G Globally Significant; G Composed (Single) Plan. Technisch gezien kan in iedere OIG elk symbool geplaatst worden. Binnen de OWG is echter afgesproken welke symbolen in welke OIG’s uitgewisseld worden. Technisch beheer De tweede groep gebruikers vinden we binnen de S6 sectie, de technische en management bedienaar van de MIP Gateway. Zij voeren het technisch beheer over de MIP Gateway. Het gaat daarbij om het tot stand brengen van de connectie, het opzetten van informatie contracten met andere landen en het creëren van nieuwe OIG’s. Het eerder genoemde ontbreken van input van de eindgebruikers heeft tot gevolg dat de user interface van de MIP Gateway momenteel minder gebruikersvriendelijk is. Op korte termijn zal dit in samenspraak met de eindgebruiker verbeterd worden. De ‘in service’ periode van een bepaald MIP Block duurt 2 jaar. Nationaal wordt elk jaar een nieuwe suite van het C2-systeem uitge-
INTERCOM 2006-1
INZET MIP Indien in de toekomst een mogelijke inzet van de MIP Gateway tijdens een combined en joint operatie gaat plaatsvinden hebben we binnen het C2 Support Centre een visie hoe dit het beste kan geschieden. Hierbij kan worden gedacht aan een mogelijke inzet van Nederlandse eenheden in het kader van ISAF en samenwerking met Canada en het Verenigd Koninkrijk. Een mogelijke configuratie tijdens een operatie kan men in onderstaand figuur zien.
Figuur 4: MIP Gateway Manager
Zodra bekend wordt dat de MIP Gateway met een bepaald land wordt ingezet zullen we zo spoedig mogelijk alle elementaire testen (nogmaals) uit gaan voeren met dat land over het internet (de SLT 1 en SLT 2 testen, zie artikel majoor Hans Postma). Als deze succesvol afgerond zijn (na ongeveer 1 á 2 weken) gaan we beide systemen op een bepaalde locatie fysiek aan elkaar verbinden met de nationale C2-systemen aan de MIP Gateway’s gekoppeld. De operationele bedienaars worden hierbij betrokken zodat zij kunnen zien welke informatie daadwerkelijk uitgewisseld kan worden en er ervaring en vertrouwen in de applicatie wordt opgedaan. Vervolgens kunnen zij aan de hand van de testresultaten al gaan werken om de SOP’s op te stellen voor de komende operatie. De MIP Gateway zal niet eerder operationeel worden ingezet voordat de beschreven testen met succes zijn uitgevoerd door het personeel dat uiteindelijk met de MIP Gateway zal gaan werken. Figuur 5: Contract Management
bracht. Dat houdt in dat het nationale MIP ontwikkelteam te maken gaat krijgen met drie verschillende versies van de MIP Gateway. Block 2 is vanaf januari 2006 operationeel inzetbaar dus de NLD MIP Gateway is daar op afgestemd. Eind 2006 komt er een nieuwe versie van C2WS en omdat wij werken met een ‘vertaalslag’ zullen we de MIP Gateway aan moeten passen op de nieuwe Suite 2007. Verder start in januari 2006 het nieuwe MIP Block 3 met nieuwe functionaliteiten en eventuele veranderingen, dus dat is de derde versie voor het team. Het team bestaat momenteel uit 3 ontwikkelaars en een teamleider die ook alle testen uitvoeren. De testen vinden over het internet en voornamelijk in Duitsland plaats. In vergelijking met andere landen hebben we het kleinste ontwikkelteam maar we hebben in de loop van de jaren op internationaal niveau een goede naam opgebouwd. Nederland is het enige land binnen MIP die de MIP Gateway ‘in house’ ontwikkelt en dit niet uitbesteedt aan een firma buiten defensie. Hierdoor houden we de volledige controle en zijn we ook meer flexibel vergeleken met de andere landen.
INTERCOM 2006-1
CONCLUSIE Als er op dit moment internationaal over interoperabiliteit wordt gesproken hoor je direct MIP naar voren komen. Op dit moment
Figuur 6: Voorbeeld MIP deployment
63
is MIP het enige programma dat zich bezighoudt met internationale interoperabiliteit tussen C2-Systemen. Ik denk dat we MIP operationeel kunnen inzetten maar niet met alle functionaliteiten. Om te beginnen kunnen we ons beperken tot het uitwisselen van de binnen MIP afgesproken symbolenset. Hierna kan evolutionair de MIP oplossing verder worden uitgebreid. Het zal altijd afhangen van de functionaliteiten die de partners binnen de operatie in hun MIP Gateway hebben geïmplementeerd. Hoewel de MIP Gateway de mogelijkheid biedt om met een aantal landen gelijktijdig te koppelen, denk ik dat de Block 2 oplossing in eerste instantie bilateraal ingezet zal worden en dat
later het aantal connecties uitgebreid kan worden, afhankelijk van de opgedane ervaringen. MIP zal een uitstekende rol kunnen innemen om de commandanten de juiste informatie te kunnen laten uitwisselen in het kader van Network Centric Warfare. Een van de voordelen van het werken met MIP is dat de stafofficier nu zelf kan bepalen welke informatie, wanneer en met wie wordt uitgewisseld. Daarnaast beschikken alle landen over een actueel beeld van de operationele situatie (Situational Awareness). In de oude situatie moest de liaison officier vaak op afstand proberen te inter-
preteren wat de opsteller nu precies bedoelde te zeggen en men werkte vaak met verouderde informatie. Alle operaties waaraan Nederland deelneemt zijn multinationaal en door middel van koppeling / interfacing met TITAAN kan MIP een zeer goede bijdrage leveren aan het Command en Control proces. Het zal altijd afhankelijk zijn van het partnerland of partnerlanden en de soort operatie in hoeverre MIP zijn bijdrage kan leveren maar de snelheid en inhoud van het overbrengen van de informatie zal de operationele commandanten veel mogelijkheden kunnen bieden tijdens de uitoefening van hun taak in de toekomst voor combined en joint optreden.
MIP TESTEN Door: majoor Hans Postma, Exchange Officer bij US Army/PM GCC2
In de vorige uitgave van Intercom heb ik beloofd wat dieper in te gaan op het testen zoals dat binnen het Multilateral Interoperability Programme (MIP) plaats vindt. In die uitgave is door lkol b.d. Kees Ebling reeds een uitgebreid artikel over MIP geschreven, waar ik voor een algemene inleiding over MIP kortheidshalve naar verwijs.
Ik ben namens de USA voorzitter van de MIP Test and Evaluation Working Group (TEWG), een groep met 24 leden van de diverse full- en associated MIP members. De TEWG is verantwoordelijk voor het plannen, organiseren, uitvoeren en evalueren van het MIP testprogramma. Door deze testen dient aangetoond te worden dat MIP toegevoegde waarde heeft voor de interoperabiliteit tussen C2 systemen en het bereiken van common understanding tussen de diverse gebruikers van C2 systemen. Namens Nederland is majoor Hans Baltzer afgevaardigd in TEWG. Hij zal elders in deze Intercom ingaan op de Nederlandse implementatie van MIP. In dit artikel zal ik achtereenvolgens ingaan op de diverse soorten testen, de verschillende exit-/entrance criteria, het huidige test programma en ik zal afsluiten met het beoogde eindproduct van al deze test inspanningen, de capability matrix.
wordt onderscheid gemaakt in Implementation Level Testing (ILT), System Level Testing (SLT) en Operational Level Testing (OLT). Het volgende plaatje verduidelijkt de scope van de diverse testen binnen de MIP architectuur. Deze diverse soorten testen zal ik onderstaand meer in detail toe-
lichten. De opbouw van de testen is dusdanig dat ieder (sub)level eerst volledig getest moet zijn voordat naar een volgend (sub)level gegaan kan worden. De reden hierachter is dat daardoor op een gestructureerde manier door de ‘technische’ lagen van de MIP Gateway gegaan wordt.
IMPLEMENTATION LEVEL TESTING (ILT) Deze ILT is een test die unilateraal (alleen en onder nationale verantwoordelijkheid) uitgevoerd wordt voordat men aan de System Level Testen kan beginnen. Men dient
DIVERSE TESTEN Het merendeel van de testen wordt uitgevoerd via het internet of in Greding (Duitsland). Daarnaast vinden er testen/demonstraties plaats in grote internationale oefeningen (zoals Combined Endeavor (CE) en Coalition Warfighter Interoperability Demonstration (CWID)). Binnen MIP
64
Figuur 1: MIP testoverzicht
INTERCOM 2006-1
voor deze test gebruik te maken van twee nationale MIP gateways (back to back gekoppeld). Het is feitelijk een alphatest van SLT1.
SYSTEM LEVEL TESTING (SLT) SLT is op te splitsen in drie sublevels: SLT1, SLT2 en SLT3. SLT1 is ‘Technical Level Testing’ en richt zich op data transmissie en communicatie protocollen tussen de nationale Data Exchange Mechanism (DEM) en het uitwisselen/opslaan van informatie in de nationale C2IEDM databases. Onderdeel van de test is het genereren van fouten door een testpartner, waarop adequaat gereageerd dient te worden (bijvoorbeeld door een sessie te verbreken met een bepaalde foutcode). SLT1 testen worden bilateraal via het internet uitgevoerd. Voor SLT1 is door NATO ACT/NC3A een MIP Reference System (MRS) ontwikkeld. Dit systeem is niet een volwaardig Command and Control Information System (C2IS), maar geschikt om uitsluitend de data transmissie en communicatie protocollen te testen. Ieder ander systeem dient met dit MRS te testen. Op deze manier wordt zeker gesteld dat systemen geschikt zijn om zonder problemen met andere systemen te testen. SLT2 is ‘Data & Procedural Level Testing’ en richt zich meer dan SLT1 op de correcte informatie uitwisseling tussen en de juiste opslag van data in de nationale C2IEDM databases. Ook wordt het compleet opbouwen van een sessie en het afsluiten van een contract met diverse Operational Information Groups (OIG’s, MIP naam voor contexten) procedureel getest. Op dit level
wordt ook met behulp van door MIP beschikbaar gestelde test data enige stress testen voor de database uitgevoerd. Enige SLT2 testen zijn multilateraal en worden in Greding (Duitsland) uitgevoerd: met drie of vier MIP Gateways wordt onder andere het doorsturen van data getest. De overige testen worden bilateraal via het internet uitgevoerd. SLT3 is ‘C2IS Level Testing’ en richt zich op de complete C2IS-MIP Gateway keten. Veel tijd wordt tijdens SLT3 besteedt aan het uitvoeren van symbology testen, het uitwisselen van de binnen MIP overeengekomen belangrijke tactische symbolen. Ook hier zijn enkele testen multilateraal: met maximaal zes systemen wordt de werking van de OIG’s tussen de nationale C2IS getest. Door ook in SLT3 gebruik te maken van MIP test data kunnen enkele testen unilateraal uitgevoerd worden. Zo hebben we test data om landen de vertaling tussen hun nationale (C2IS) database en hun C2IEDM database te laten testen. Door deze test unilateraal voor de overige testen te doen, wordt bij de bi- en multilateraal testen veel tijd bespaard. Doordat veel testen het vergelijken van de C2IS beeldschermen vereist, worden de bi- en multilateraal testen in Greding (Duitsland) uitgevoerd.
OPERATIONAL LEVEL TESTING (OLT) De OLT is het ‘paradepaardje’ van het MIP test programma en vindt plaats aan het einde van de test cyclus in Greding (Duitsland). Hier wordt de complete C2IS-MIP Gateway keten door operationele gebruikers aan een test in een semi-operationele omgeving onderworpen. De gebruikers kijken naar za-
Figuur 2: Operational Level Testing in Greding, oktober 2005
INTERCOM 2006-1
ken als gebruikersgemak, betrouwbaarheid, performance, documentatie en meest belangrijk: kan er common understanding met andere C2IS gebruikers verkregen worden door gebruik te maken van een MIP compliant C2IS? Wat in deze OLT niet getest wordt, is het gebruik van nationale communicatie apparatuur, gebruik in een voertuig/CP, etc. Dit soort testen zou bijvoorbeeld tijdens Combined Endeavor uitgevoerd kunnen worden, maar valt voor Block 2 buiten de scope van MIP testen.
CRITERIA Binnen MIP werken we met entrance-/exit criteria per level. Zo dient ieder systeem SLT1 met vijf andere systemen te testen. Na het testen met deze vijf systemen mag men naar SLT2 indien geen grote problemen (systeem loopt vast, geen work around mogelijk, etc) tijdens het testen gevonden zijn. Kleinere problemen (bijvoorbeeld een sessie wordt correct verbroken bij het ontvangen van fouten, maar de verzonden foutcode is verkeerd) dienen uiteraard ook gecorrigeerd en opnieuw getest te worden, maar dat vormt geen belemmering om naar een volgend level te gaan. Voor SLT2 dient met drie andere systemen getest te worden en SLT3 met twee andere systemen. Tijdens de OLT zijn meerdere systemen aanwezig en wordt een operationeel scenario doorlopen. Ieder systeem dient minstens één maal aan een OLT deel te nemen. De test resultaten worden door de MIP Test Controllers (TC) verzameld en verwerkt. Zij adviseren de PMG of een land deel kan nemen aan testen in een volgend level.
TESTPROGRAMMA Gedurende Block 2 is door de MSG/PMG besloten het concept van ‘flexibel testen’ toe te passen. Dit houdt in dat systemen uit meerdere test periodes kunnen kiezen wanneer een bepaald level te testen, een en ander afhankelijk van hoe ver dat land is met hun systeemontwikkeling. Voor de testorganisatie was dit besluit een uitdaging om de test periodes zo te plannen dat ieder land aan de entrance-/exit criteria per level kan voldoen. Landen zijn zelf verantwoordelijk om het minimum aantal test partners te zoeken. Tijdens iedere test periode heeft men ook de gelegenheid om gecorrigeerde problemen van een vorig level opnieuw te testen. In het bijgaande overzicht zijn de diverse test periodes van Block 2 aangegeven. Voor Block 3 is gekozen voor een andere systematiek: er is één test periode per level en ieder land wordt geacht in die periode te testen. Problemen dienen voor een volgende periode gecorrigeerd te worden en worden dan opnieuw getest. De gedachte is dat wederom alle bilaterale SLT1 en SLT2 testen via het internet gedaan kunnen worden. Op deze manier wordt het aantal test dagen
65
worden. Het is aan de landen zelf om de capability matrix in een SOP/SOI op te nemen en opleiding/training voor deze materie te ontwikkelen. Wellicht dat sommige systemen zo flexibel/configureerbaar zijn dat bijvoorbeeld bepaalde symbolen niet voor de eindgebruiker beschikbaar zijn indien niet alle internationale partners in een bepaalde operatie ze kunnen ontvangen!
Figuur 3: Block 2 test periodes
in Greding sterk verminderd.
CAPABILITY MATRIX Het eindproduct van al deze test inspanningen is het opleveren van een capability matrix. Deze matrix kan door de eindge-
bruiker van een C2IS als handleiding gebruikt worden om te zien of een bepaalde functionaliteit (bijvoorbeeld plan OIG’s) ondersteund wordt of dat een bepaald symbool al dan niet door een ander systeem via de MIP gateway verstuurd/ontvangen kan
Figuur 4: Onderdeel van een capability matrix
Voor meer informatie:
[email protected]
VERENIGING OFFICIEREN VERBINDINGSDIENST REDACTIE WEBSITE De vertegenwoordigers van de leden in besturen en redacties veranderen regelmatig; niet alleen omdat mensen van functie veranderen, maar ook om het ‘inslijten’ van gewoonten te vermijden. De redactie van de website van de VOV was aan ‘nieuw bloed’ toe en daarom heeft de voorzitter van de VOV drie leden gevraagd om in de redactie plaats te nemen. Zij stellen zich hierbij aan u voor: Paul Benschop Na een militaire carrière bij de Verbindingsdienst ging Paul in 1995 over in burgerdienst bij de Landmacht. Zijn militaire plaatsing bij -destijds- de Voorbereidende Technische Opleiding (VTO) op het Verbindingsdienst Opleidingscentrum beviel hem zo goed, dat hij graag als burgerdocent bij dit onderdeel een bijdrage wilde leveren aan de opleiding van collega’s van de Verbindingsdienst. Intussen is de VTO opgegaan in de instructiegroep Voortgezette Opleidingen van de School Verbindingsdienst. Hij verzorgt daar lessen in ICT-vakken in het algemeen en netwerktechnieken in het bijzonder. Zijn belangrijkste hobby’s zijn fotografie en video; het op allerlei manieren grafisch bewerken van de foto’s en het verwerken tot mooie plaatjes voor op het internet.
66
Peter Harmsen Ook Peter is na een militaire carrière overgegaan in burgerdienst. Hij is begonnen als sergeant-instructeur bij de Verbindingsdienst en door studie opgeklommen tot kapitein, met als specialisme ontwerp en implementatie van netwerken bij defensie. Hij heeft een belangrijke bijdrage geleverd aan LONET en KLIM. Sinds drie jaar werkt hij als docent bij de zelfde instructiegroep als Paul. Zijn specialisaties zijn netwerkbeveiliging en IP telefonie. In zijn vrije tijd houdt hij zich onder andere bezig met doe-het-zelf projecten. Wie een bouwplan nodig heeft voor een duurzaam konijnenhok kan bij hem terecht. Hans Vaneman Hans is een collega van Peter en Paul. Na de dienstplicht bij de Verbindingsdienst is hij als burger in dienst getreden bij de toenma-
lige Directie Materieel Koninklijke Landmacht, daar bekleedde hij diverse logistieke en technische functies. Sinds 1988 werkt hij als docent bij wat nu de School Verbindingsdienst is. Hij geeft niet alleen les in netwerktechnieken, hij is ook het aanspreekpunt voor alles wat betrekking heeft op de Cisco Networking Academy. Zijn hobby’s zijn Tosca, zijn chow chow en lezen (favoriete schrijvers: L.P. Boon, John Irving en J.M. Coetzee).
INTERCOM 2006-1
