TITAAN BIJ DE MANOEUVRE, ISIS OP BATALJONS NIVEAU

Transcriptie

1 TITAAN BIJ DE MANOEUVRE, ISIS OP BATALJONS NIVEAU Door: eerste-luitenant Hans Verboom, S6 44 Painfbat Zoals beloofd in mijn vorige artikel VERBINDINGSDIENST: DE KNOP MOET OM (Intercom ) zou ik nog een stuk schrijven over de inzet van TITAAN bij een manoeuvrebataljon, in mijn geval dus 44 Painfbat Regiment Infanterie Johan Willem Friso. Met onderstaande bijdrage los ik die belofte in en wederom hoop ik op een kritisch lezerspubliek. INLEIDING 43 Mechbrig was voor de eerste helft van 2005 aangewezen als core-eenheid voor NRF-4 (NATO Response Force), een snel inzetbare strijdmacht van de NAVO. Deze multinationale eenheid moest in voorkomende gevallen in korte tijd kunnen ontplooien om als brandweer op te kunnen treden bij brandjes waar ook ter wereld. Voor de C2-ondersteuning was besloten dat 43 (MN) Mechbrig zou gaan werken met TI- TAAN fase 2/3, en zodoende werd dit paradepaardje van de verbindingsdienst ook versneld ingevoerd bij 44 Painfbat. Dit betekende een behoorlijke revolutie op het gebied van Command & Control: hadden we vroeger ZODIAC tot brigade niveau (en zelfstandige eenheden), met TITAAN was het de bedoeling dat een WAN werd gecreëerd tot op bataljonsniveau. Dit niveau werd hierdoor voor het eerst geconfronteerd met een tactische LAN in de bataljonscommandopost (batcp), data en (point-to-point) Batcp in vaste infrastructuur voice verkeer met de brigade(eenheden). Over de invoering en de inzet van TITAAN voor de NRF en tijdens de standby-periode heeft u al het één en ander kunnen lezen in voorgaande Intercoms. In dit artikel geef ik mijn ervaringen als S6 met TITAAN bij 44 Painfbat weer. Aan de hand van verschillende oefeningen, bijna allen niveau V of hoger, wordt iets verteld over de ervaringen met een tactisch LAN in de batcp. Hierbij komt de invoering van TITAAN aan bod, de inzet in de batcp en de ervaringen met dit systeem. Ik geef aan waar de knelpunten liggen en waarom TI- TAAN maar deels geschikt is voor het manoeuvre optreden en waarom naar mijn mening ISIS niet is afgestemd op bataljonsniveau. Ten slotte geef ik aan wat er naar mijn mening verbeterd kan worden. BATCP MET TACTISCH LAN Vanaf januari 2004 heeft 44 Painfbat geoefend met een LAN-omgeving te velde. Al tijdens mijn eerste oefening als S6 van dit bataljon, een CAX (Computer Assisted Exercise, Bison Preliminary, jan 2004) van 43 Mechbrig in Amersfoort, werd gewerkt met een LAN in de batcp. Dit werd gerealiseerd door oude TALANFA (TActische LAN FAciliteiten) middelen van de voormalige 1e Divisie 7 december. Het LAN bestond uit een server (laptop) en clients middels UTP aangesloten op een LAN-accessbox. Belangrijkste applicaties die op de werkstations draaiden waren ISIS 2.5 en TMS 3.0. De link naar het hogere niveau werd gevormd door een ZODIAC-detachement van 106 Vbdbat. Op deze manier was het ook mogelijk middels CAT jes (Civiele Abonnee Toestellen) te bellen met de brigade. Tot dat moment toe was er KLbreed nog niet over nagedacht hoe binnen een batcp gewerkt moest worden met een tactisch LAN en welke consequenties dit had voor de staf en het optreden. Als ik mijn FIR (First Impression Report) over die oefening er weer bij pak dan constateer ik dat er sinds die oefening heel wat zaken verbeterd zijn. Zo was toen nog niet nagedacht over het aantal voedingskabels en stroompunten dat benodigd was voor alle werkstations, welke gebruikers allemaal een werkstation nodig hadden, enz. Heel basale zaken die toch essentieel zijn om het systeem te laten draaien. Daarnaast zijn er ook knelpunten die tot op dit moment niet (goed) opgelost zijn. Bijvoorbeeld het probleem dat op bataljonsniveau maar nauwelijks capaciteit (zowel in tijd als mankracht) aanwezig is voor het tekenen van ISIS-oleaten en dat het rendement ervan bijna alleen op brigadeniveau ligt. Voor de uitwisseling met de lagere niveaus blijven we aangewezen op het ouderwets tekenen van de operatieoleaten, omdat de subeenheden niet over digitale systemen beschikken. Dit betekent dat vooral de sie S3 dubbel werk moet doen: operatieoleaat in ISIS en op plastic tekenen. Bij de volgende brigadegeleide oefening, Bison Together, in maart 2004 op het middenterrein in Bergen (DEU) ging het al opmerkelijk beter. We hadden twee ZODIAC detachementen met enthousiast personeel onder bevel (wederom van 106 Vbdbat) waarmee de twee clusters van de batcp onafhankelijk van elkaar konden springen. Hoewel dit extra materieel (2x MSVSN en 2x MTR30) tot wanhoop van de C-batcp 37

2 een probleem gaf bij het vinden van een geschikte locatie, vormde het opbouwen en afbreken door de hoeveelheid ZODIAC-personeel geen directe belemmering voor het optreden van de batcp. Een tweetal problemen uit die oefening kan ik me nog goed herinneren. Allereerst was daar het probleem dat de oefening heel beweeglijk was; de nadruk lag op het groene optreden en dat betekende automatisch veel springen met de batcp. Uiteindelijk hebben we toen 6 keer in 5 dagen gesprongen. Op diverse momenten is vanwege de lopende actie en het op ad hoc basis vinden van een geschikte CPlocatie, besloten om het LAN niet op te bouwen. Op dat moment bleef de brigade dan ook verstoken van digitale informatie en gebeurde alles via voice (FM9000). Een belangrijke conclusie was toen dat een dergelijk C2-systeem duidelijk niet geschikt is voor hoog mobiel optreden. Een tweede obstakel vormde het toplicht van de MSVSN. Hoewel er tactisch werd gehesen was deze rode seinlamp een bron van ergernis voor de infanteristen omdat de vijandelijke verkenners onze commandopost in zeer korte tijd konden traceren. Uiteindelijk is toen ook besloten om de lamp uit te zetten. Bison Buildup, een CPX (Command Post Exercise) in mei 2004 vond plaats op het C2SC in Ede. De nadruk lag op de commandovoering (in internationaal verband) en de ondersteuning daarvan met digitale middelen. Het scenario focuste zich op een initial entry operatie in Liberia. Voor het eerst werkten we daar met de nieuwe producten van het C2SC: ISIS versie 3.0 en TMS 4.0. Een belangrijk gemis van ISIS bleek o.a. een schetsfunctionaliteit te zijn voor het uitwerken van de eigen mogelijkheden (EM n) voor de S3 tijdens het Operationeel Besluitvormingsproces (OBP). Verder werd steeds duidelijker dat ISIS niet voor bataljonsniveau is ontworpen. Als het gaat om gedetailleerde planning zoals die gewenst is op bataljonsniveau voldoet GIS niet. Bijvoorbeeld het nauwkeurig intekenen van vakgrenzen kost heel veel tijd t.o.v. de klassiek getekende oleaten. Tijd, die men tijdens een oefening of operatie zeker bij de sie S3 niet over heeft. Bovendien moet men voor de lagere niveaus nog steeds getekende plastic oleaten opleveren. Op brigadeniveau kan men een vakgrens misschien nog afdoen met een grove lijn langs een snelweg, voor een bataljon die vakgrenzen voor teams moet trekken is het heel belangrijk of de linker- of rechterkant van de straat in een dorp bij het A- of B-team hoort. Ook de tekenset (hoewel volgens NATO standaard APP 6A) strookt niet met de symbolen die men bij de manoeuvre gebruikt omdat bijvoorbeeld een S3 tijdens zijn cursus Operatiën andere eenheidstekens heeft aangeleerd. En zo zijn er nog meer zaken te noemen waarvan we hopen dat die met de invoer van BMS op bataljonsniveau opgelost worden omdat dit systeem zich veel meer leent voor het beweeglijke optreden van de manoeuvre-eenheden. De laatste oefening zonder TITAAN was de certificering van 44 Painfbat in juni 2004 op Gefechts Übungszentrum (GÜZ) in Altmark (DEU), het nieuwe oefenterrein voor de niveau 5 test voor eenheden tot bataljonsniveau. De batcp beschikte over een tactisch LAN maar niet over een directe digitale verbinding met het hogere niveau. Wel hadden we twee s HF7000 onder bevel gekregen. Volgens het personeel van deze Harris radio s hadden ze nog geen oefening meegemaakt waarin ze zoveel berichten hadden verzonden: ruim 200! Dat was de laatste oefening waarbij de HF zo intensief werd gebruikt; daarna diende de HF7000 alleen als backup voor TITAAN. TITAAN KOMT ERAAN! Met de invoering van TITAAN bij 44 Painfbat vanaf begin mei 2004 ontstond ook de C2ostgp en druppelde het verbindingspersoneel binnen. De kern werd gevormd door de oude verbindingsgroep van het bataljon die met de vorming van de C2ostgp ophield te bestaan. Overigens wil ik opmerken dat de Verbindingseenheden (toen nog 106 en 11 Vbdbat) op dat moment niet stonden te trappelen om personeel aan de nieuwe C2ostgpn bij 43 Mechbrig af te staan. Mijns inziens een gemiste kans! Daardoor kon het gebeuren dat collega s van de manoeuvre (inf/cav) op deze functies werden geplaatst. Toen de verbindingsbataljons maanden later alsnog aangaven overtallig personeel te bezitten i.v.m. reorganisatie was het te laat: alle plaatsen waren inmiddels gevuld met verse verbindelaren van de KMS dan wel wapeneigen personeel van de eenheid. Op Straalzenders TITAAN fase 1 de taken en de plaats in de organisatie van de C2ostgp wil ik in een volgend artikel verder ingaan. Hoewel de personele vulling bijna rond was beschikten we nog niet over het materieel (BAM). Dit had alles te maken met het feit dat de projectorganisatie ons nog niet van het gewenste materiaal kon voorzien omdat de hele invoering vervroegd was door de NRF. Voor opleiding en training van het C2ost-personeel leverde dit wel problemen op: zij wisten nauwelijks met wat voor soort materieel zij straks zouden gaan werken. Daarnaast kon de School Verbindingsdienst ook niet voorzien in de grote vraag naar TI- TAAN opleidingen. Veel cursussen moesten nog uitgewerkt worden en de eigen instructeurs waren ook nog maar deels opgeleid. Gezien het grote aantal opleidingen, dat voornamelijk de kaderleden van de C2ostgpn moeten volgen, zal er nog een hele tijd over heen gaan voordat deze inhaalslag is afgerond. Uiteindelijk kregen we een aantal weken voor de grote oefening Bison Prepare de server binnen. Deze moest samen met de 20 clients die aan ons waren toegewezen geprimed en gestaged worden bij het CIS Control Centre (CISCC) in Stroe. Dit was voor zowel CISCC als de C2ostgp de eerste grote klus met TITAAN (fase 2/3). Bij het proces van primen en stagen worden de parameters voor een BAM ingevoerd. Daarvoor moet o.a. door de sie S6 een User Provisioning List (USP) worden opgesteld waarin bijvoorbeeld de gebruikers met juiste mailboxen en rechten worden vastgelegd. Probleem is dat als dit primen en stagen voltooid is, de gewenste situatie voor een oefening in beton gegoten is. Mochten er tijdens een oefening of operatie belangrijke wijzigingen optreden dan is dit niet meer eenvoudig te veranderen. Voorbeeld: een TACP of een S9 wordt voor de duur van een operatie toegevoegd aan de bataljonsstaf maar kan niet met zijn eigen werkstation inloggen op het LAN; deze wijzigingen komen zeer regelmatig voor op bataljonsniveau, zeker tijdens blauw optreden. Dit maakt het systeem in belangrijke mate inflexibel. Tijdens de internationale oefening Bison Prepare (september 2004, Bergen) werd TI- TAAN (fase 2/3) voor het eerst grootschalig ingezet. Dit gebeurde overigens nog niet volgens de filosofie achter het systeem waarbij eenheden aan elkaar aanhaken, maar alle eenheden maakten contact via een knooppunt van straalzenders op de Hengstberg. Dit vanwege het feit dat het de eerste keer was en men zekerheid wilde inbouwen. Naar mijn mening was die eerste inzet van TI- TAAN zeker succesvol te noemen. Hoewel er nog hickups in het systeem zaten (telefoongesprekken die zomaar wegvielen, C2WS dat niet goed repliceerde, TITAAN end user equipment stoorde op de FM9000) 38

3 bleef TITAAN stabiel werken. Ook toen we gingen springen met de batcp leverde dat geen al te grote problemen op. Wel bleek het een tijdrovend karwei om de glasvezelkabels tussen de boxen van de verschillende clusters in de batcp veilig weg te werken (op hoogte of ingraven) vanwege het rijden met n. Het is dan ook een grote wens voor de toekomst om commandoposten die mobiel moeten kunnen optreden uit te rusten met Wireless LAN (WLAN). VOIP-telefonie bleek een middel te zijn waarvoor geen draagvlak hoefde gecreëerd te worden. Het voordeel daarvan was zó evident dat men bij het betrekken van een volgende locatie al gelijk vroeg of we verbinding hadden. Het één op één communiceren met counterparts bij de brigadestaf of met andere eenheden bleek een enorm voordeel t.o.v. het gebruik van de FM9000: iedereen luistert mee en het kanaal blijft bezet (alternatief is uiteraard selective call). Hoewel de andere digitale manier van communiceren, TMS, ook als voordeel werd ervaren, liep men daar tegen het gebruik van SIC s aan. Deze NATO-oplossing om berichtenverkeer tussen commandoposten op een juiste manier te laten verlopen kon op weinig begrip rekenen bij de staf. Vooral het aantal SIC s (al snel ongeveer 100 per oef) was een doorn in het oog. Ik wil iemand bereiken stond centraal en niet het onderwerp of de abonneering op een SIC. Dit betekent een omslag in het denken omdat men zowel thuis als op de vredeslocatie gewend is op persoon of functionaris te versturen. Een voordeel van de nieuwe TMS-versie was al wel dat intern de staf op functiegebied (S1, S4, enz.) g d kon worden. In Baumholder (DEU, Heroic Sword, november 2004) werd de staf van 43 (MN) Mechbrig NRF-4 gecertificeerd en was onze bataljonsstaf LOCON. Dit betekende dat we in gebouwen zaten en het LAN werd ontplooid in een statische omgeving. Als LO- CON kregen we play-berichten via de White-cell van de Legerkorpsstaf (1 GNC). Daarvoor hadden we de beschikking over een tweetal TITAAN fase 1 werkstations, uiteraard los van het eigen fase 2/3 netwerk. Een groot voordeel bleken de gemeenschappelijke directories. Daardoor was het mogelijk om in de shared folders van de Legerkorpsstaf de noodzakelijke informatie op te halen; iets wat bij fase 2/3 niet mogelijk is omdat elke BAM in feite een apart domein is. Dit heeft alles te maken met het feit dat men bij de ontwikkeling van fase 1 heeft gekozen voor het single forest-single domain principe. Een ander voordeel hiervan is dat het uitwisselen van werkstations tussen verschillende commandoposten (specialisten die tijdelijk onder bevel gesteld worden) geen problemen oplevert. Met multiple forest-single domain (fase 2/3) is dit - zoals hierboven ook al aangegeven - helaas niet mogelijk. Batcp in mobiele infrastructuur Tijdens Electronic Integration (december 2004) werden TITAAN en de C2ostgpn beproefd in Stroe. Deze CIS-oefening, onder leiding van G6 OPCO, was bedoeld als een officieuze operationele acceptatietest van het NRF-4 gedeelte van de TITAAN en MSC middelen (MSC: Militaire Satellietcommunicatiemiddelen). Door - voor mijn gevoel - miscommunicatie, matige voorbereiding en een dito uitvoering is deze oefening helaas niet goed uit de verf gekomen. Wat mij betreft was deze acceptatietest dan ook niet geslaagd, maar blijkbaar hangt dat af van het niveau in de organisatie hoe je daar tegenaan kijkt. TIJDENS DE NRF-PERIODE Ondanks de niet altijd positieve reacties en ervaringen bij ons bat leek het me goed om ook de compagnieën van 44 Painfbat een keer te laten ruiken aan TITAAN. Immers, op uitzending kunnen compagnieën op een eigen teambase geconfronteerd worden met deze middelen. Zodoende werd in overleg met 101 CISbat besloten oefening Titan Horse (maart 2005) uit te voeren. Eén en ander was uitvloeisel van de contacten tussen C-101 CISbat en C-44 Painfbat. Voor 101 CISbat was dit de laatste operationele test voor de belangrijke oefening Noble Javelin op de Canarische Eilanden. De compagnieën van 44 Painfbat simuleerden in deze situatie enkele internationale eenheden die aan deze oefening zouden deelnemen. Tijdens de oefening waren de compagnieën en de batcp verspreid over oefenterreinen op de Veluwe: Leusder Heide (Bcie), Ermelosche Heide (Ssvostcie), Doornspijksche Heide (Ccie) en Stroesche Zand (batcp). Gezien de afstanden was besloten de transmissie alleen via straalzenders te laten verlopen, ook omdat lang niet alle TT s (Tactische Terminals, satcom) inzetbaar waren; tijdens het verloop van de oefening is uiteindelijk wel een aantal TT s operationeel geweest maar er waren veel technische problemen. Pas op de 2e dag kregen we uiteindelijk verbinding met de Ssvostcie, met de andere compagnieën is in het geheel geen contact geweest. Ondanks verwoede pogingen van het MCCC (Mobile CIS Control Centre) en het personeel van 101 CISbat kregen we tijdens de hele week geen compleet WAN operationeel. Het verloop van de oefening op TITAAN gebied was vanuit ons bataljon gezien dramatisch. Voor het creëren van een draagvlak voor dit systeem was deze oefening een heel slechte start. Als op deze afstanden en onder relatief statische omstandigheden TI- TAAN niet werkte, hoe zou het zich dan houden als er daadwerkelijk operationeel werd opgetreden? Ik als S6 heb deze oefening dan ook als een teleurstelling ervaren. 101 CISbat keek daar heel anders tegenaan: ondanks of beter gezegd dankzij deze slechte generale voor de - internationaal veel belangrijkere - oefening Noble Javelin kon een aantal fouten opgespoord en verholpen worden. Daardoor draaide het systeem op de Canarische Eilanden vervolgens vlekkeloos... De laatste grote oefening van NRF-4, Iron Sword, vond plaats in Noorwegen (juni 2005). Ruim 4000 militairen moesten tijdens deze NRF-demonstratie laten zien waartoe deze snelle reactiemacht in staat was. Ons bataljon beschikte naast de eigen BAM over een MSVSN en een TT voor de WANconnectie van 101 CISbat (HF7000 als backup). Al in de Staging Area (SA) op Rygge Airport waren er problemen met de TT 39

4 OPTREDEN BATALJONSCOMMANDOPOST Om inzicht te geven in wat nu zo n bataljonscommandopost precies inhoudt volgt hieronder een kort overzicht. Per bataljon kan de commandopost verschillen dus wat ik hier beschrijf is zeker geen blauwdruk. De batcp s van painfbats zullen in basis overeenkomen met wat beschreven staat in HB 2-00, Handboek Pantserinfanterie- en Tankbataljon (H4, sectie 4). Daarin vinden we vermeld dat alle activiteiten in de commandopost zijn gericht op het ondersteunen van de bataljonscommandant bij zijn commandovoering. Met dat laatste (covo) hebben we gelijk de hoofdactiviteit van de batcp te pakken. Volgens de Leidraad Commandovoering bestaat covo uit de elementen besluitvorming, bevelvoering en leidinggeven. Deze zaken zien we direct terug komen in de werkzaamheden in de batcp. Om het concreet te maken: besluitvorming vindt plaats tijdens het Operationeeel Besluitvormingsproces (OBP), bevelvoering vinden we onder andere terug bij de bevelsuitgifte en leidinggeven gebeurt bijvoorbeeld direct aan de teamcommandanten over de Combat Net Radio (CNR). De informatievoorziening (tijdigheid, beschikbaarheid, juistheid) is essentieel voor de ondersteuning van dit proces van commandovoering. INDELING BATCP De batcp is mede vanwege de kwetsbaarheid verdeeld in verschillende clusters: De operationele kern (opskern) of harde kern, (bijna) alleen bestaande uit pantservoertuigen (-CO s). Belangrijkste functies: BC, S3, S6; S2; (Vuursteun Coördinatie Centrum) en eventueel toegevoegd: genie, pantserluchtdoelartillerie (palua) en TACP. De logistieke kern, meestal backup genoemd. Functies: PBC, kap opn sie S3; S1, S4; toegevoegd S2/3, toegevoegd. Het overig gedeelte, tegenwoordig voornamelijk CIS-voertuigen. Sinds de invoering van een tactisch LAN in de batcp wordt hoofdzakelijk gewerkt met 2 clusters, de harde kern en de backup. Dit heeft alles te maken met het aantal beschikbare netwerk boxen maar ook met een stukje werkbaarheid en coördinatie binnen de batcp. De commandant van de batcp is bij 44 Painfbat de bataljonsadjudant. Hij zorgt voor alle randvoorwaarden: verkenning, locaties van de clusters, verzorging, (nabij)beveiliging enz. Hij wordt daarin gesteund door de commandanten van de verschillende clusters (meestal ook onderofficieren). Tijdens de voorbereiding van de NRF bleek dat het voor sommige operaties efficiënter is de indeling van de batcp aan te passen aan het soort operatie: groen of blauw optreden. Beide zal ik hieronder kort uitwerken. GROEN OPTREDEN Bij klassieke gevechtsoperaties (aanvullen, vertragen, verdedigen) werkt de batcp in de volgende configuratie (zie figuur groen optreden). De afstanden tussen de clusters verschillen per locatie maar zijn al snel 100 m; verder staan de voertuigen binnen de clusters ook meer verspreid dan in de figuur is getekend. Om de opskern ligt een ring van concertina s en bij de ingang staat een wacht. In de harde kern staan de volgende - CO s met bemanning: 01: BC, S3, S6 31: S2 en adj GI of NBC onderofficier 36: met de VSO (Vuursteun Officier) en bijv. sm zw mrn (zware mortieren). Eventueel nog aangevuld met adviseurs van genie, palua, enz. Normaal wordt het gevecht aangestuurd vanuit de bak van de BC/S3: de S3 leidt het gevecht over de radio (batconet), de BC grijpt in op beslismomenten en de S6 neemt vaak het hogere net (brigconet) waar. Tijdens gevechtspauzes kan het voorkomen dat de BC de sectiehoofden bij elkaar roept. In de tent schetst hij op de birdtable de huidige situatie en eventueel wat de laatste wijzigingen zijn. Vervolgens wordt bekeken of het originele plan nog steeds uitgevoerd kan worden. De backup bestaat uit de volgende voertuigen: 02, van de PBC met de kap opn sie S3, toeg S6 shelters van de sie S1 en S4 shelter sie S2/3 met de sm opn (sie S3) en bijv. adj GI (sie S2) shelter Omdat dit bijna allemaal sheltervoertuigen zijn wordt de backup ook wel zachte kern genoemd. De belangrijkste taak van de zachte kern is het meelezen van het gevecht en in geval van verplaatsing van de harde kern (of bij uitschakeling daarvan) het gevecht over te nemen. Het voertuig van de sie S1 vormt meestal de ingang van de batcp, daar worden bezoekers opgevangen en moet het personeel zich in- en uitmelden. BLAUW OPTREDEN Vanwege het feit dat acties tijdens blauwe operaties nogal complex (kunnen) zijn is het belangrijk dat alle functionaliteiten in de opskern vertegenwoordigd zijn. Daardoor kan bij snel veranderende situaties vlotter gecoördineerd kunnen worden. Meestal wordt dan ook niet meer in de n maar in de tent zelf gewerkt omdat dat de communicatie binnen de staf verbetert. Bovendien vragen sommige acties om specialismen van andere niveau s, bijv. een jurist van de brigade. Deze functionarissen krijgen een plaatsje in de tent van de opskern. De backup wordt tijdens blauwe acties voornamelijk gebruikt voor parallelle planning: de opskern is bezig met een lopende operatie en tegelijk wordt ge-obp t over een nieuw binnengekomen opdracht in de tent van de backup. Tijdens de diverse NRF-oefeningen bleek de batcp behoorlijk uit te dijen door het toegenomen aantal CIS-voertuigen. Daarom is uiteindelijk besloten om van dit personeel en materieel een apart cluster te maken onder leiding van de commandant C2ostgp. Dit cluster bestaat dan uit de volgende zachte voertuigen: C2ostgp: servervtg, helpdeskvtg, lijn- en sie S6; het laatste vtg wordt door de C2ostgp gebruikt omdat zowel de S6 als zijn toeg vtgcommandant zijn op een (resp. 01 en 02); bovendien heeft de C2ostgp (0/5/4) anders niet voldoende vervoerscapaciteit. WAN-middelen van 101 CISbat: MSVSN, TT en HF7000 als backup. VOORWAARTSE COMMANDOPOST De batcp is dus niet (standaard) voorzien van een dubbele set (extra BAM) om te springen. Directe noodzaak is ook niet aanwezig omdat het niet vaak gebeurt dat de opskern en de backup onafhankelijk van elkaar optreden. Wat wel regelmatig voorkomt is dat de VCP (Voorwaartse Commandopost) eruit gaat, vooral bij groene operaties. Het gaat dan meestal om de n van de BC en bijv. de S2. Deze zouden dan via een remote cliënt toch van de belangrijkste informatie voorzien kunnen worden. Helaas is dit middel niet standaard ingedeeld bij het bataljon. 40

5 Hoe ziet de batcp GROEN eruitoptreden met Titaan? OPSkern harde kern 31 Sie 2/3 01 BC 35 AD er 4T (Event. nog aangevuld met TACP) 36 BB Genie Lua 6kW 02 PBC CIS (C2ostgp) Comms Comms: - Satcom 4/10T - Straalzender (MSVSN) - PSTN (ISDN) Backup zachte kern 34 S2/3 3kW S1 11 S HF Lijn GeTitaniseerde BLAUW batcp (2) OPTREDEN 31 Sie 2/3 01 BC 36 Comms 4/10T Hoe ziet de batcp eruit met Titaan? OPSkern harde kern Genie BB 35 AD er 4T Lua 6kW Overig S4 42 S1 11 CIS (C2ostgp) BB FAB RB Server Helpdesk Verder zijn er nog s van de cogp, sie S1, S2/3 en S Backup zachte kern 20 kw 38 Sie 6 S2/3 02 PBC 34 HF BB Lijn 3kW FAB RB Server Helpdesk VCP VOORWAARTSE optreden met remote COMMANDOPOST client OPSkern harde kern 35 AD er 4T Comms 4/10T Getitaniseerde batcp (2) VCP optreden met remote client 36 BB Genie Lua 6kW CIS (C2ostgp) (op andere loc) 01 Remote client HF Lijn 31 Sie 2/3 02 PBC BC FAB RB Server Helpdesk Backup zachte kern 34 S2/3 3kW BB kw Sie kw 38 Sie 6 S1 11 S4 42 zodat het onmogelijk was om contact te maken met het ICE (Initial Command Element) van de brigade, die zo n 250 km noordelijk zat. Daardoor waren we niet in staat om de Frago s (Fragmentation Orders) en ISIS-oleaten van het hogere niveau in te zien. Pas nadat de batcp op de volgende locatie was aangekomen - zo n 20 km ten zuidoosten van de brigcp - en een satcom expert de problemen met het ankerstation in Nederland had opgelost, kregen we verbinding. Overigens was dit niet het laatste probleem met de TT s. Op vrijwel elke nieuwe locatie hadden we problemen met dit instabiele satcom systeem. Jammer, want gezien sommige afstanden was dat ons enige middel voor koppeling op het WAN. Overigens zijn de TT s na deze oefening teruggegaan naar de fabrikant om de problemen te verhelpen. Hopelijk kunnen we daarna wel beschikken over een betrouwbaar middel want satcom is essentieel voor het onafhankelijk kunnen optreden van eenheden, zeker bij operationele inzet. Tijdens Iron Sword maakten we voor het eerst kennis met de remote client: een satcom (RBGAN) waaraan een werkstation en een VOIP gekoppeld kon worden. De RB- GAN maakte contact met het ankerstation en hing op die manier in het WAN. Een schijnbaar ideale manier om kleine groepen die op grote afstanden moeten kunnen optreden en vaak verplaatsen, aan te haken op TITAAN. Dit middel werd ingezet toen onze VCP (Voorwaartse Commandopost) ging coloceren met de batcp van 12 Infbat Lumbl. Helaas heeft deze satcom nauwelijks gewerkt. Dit had behoorlijke consequenties voor de informatievoorziening. Het achtergebleven gedeelte van de batcp (de zogenaamde backup) had namelijk een OPSEC opdracht gekregen van de brigade. Hierdoor konden zij niet bijtrekken en bleef de VCP zo n 36 uur verstoken van digitale informatie van zowel de brigade als de backup. Ondanks de problemen die onze batcp had met de WAN-middelen was de samenwerking met MCCC goed te noemen. Ook de inzet van het onder bevel gestelde personeel van 101 CISbat mag niet onvermeld blijven. De integratie met de C2ostgp verliep heel soepel wat de aansturing aanmerkelijk vergemakkelijkte. Een service gerichte houding van verbindingsdienstpersoneel is ontzettend belangrijk voor de manier waarop men tegen 101 CISbat en breder de verbindingsdienst aankijkt. LESSONS LEARNED De lessons learned van dit anderhalf jaar stoeien met nieuwe C2-middelen bij een manoeuvrebataljon splits ik op in TITAAN, VOIP/TMS en ISIS. Veel stafleden gebruiken deze termen door elkaar heen alsof ze synoniemen zijn. Het is mijns inziens belangrijk dat een S6 duidelijk maakt dat er verschil is tussen de transportweg en het 41

6 Stafoverleg informatievoorzieningsysteem. Zeker als het gaat om een juiste beoordeling van deze commandovoeringmiddelen op bataljonsniveau. TITAAN Mijn belangrijkste conclusie is toch wel dat ik TITAAN in de huidige vorm onvoldoende geschikt vind voor het groene beweeglijke optreden van manoeuvre-eenheden. Naar mijn mening is TITAAN voor het statische optreden tijdens bijvoorbeeld vredesoperaties maar ook het leiden van een SOB (schietoefening Bergen) wel een heel goed middel. Maar de tijd die het nu kost om de batcp uit te rusten met een TITAAN LAN en een aansluiting op het WAN is al gauw een uur tot anderhalf uur. Dat is te veel voor een commandopost die tijdens bijvoorbeeld het vertragend gevecht frequent moet kunnen verplaatsen. Vanaf het moment van afbreken op de vorige locatie tot de tijd dat er weer een WAN-connectie is op de nieuwe locatie vindt er geen digitale uitwisseling van gegevens plaats en daardoor ontstaat er een information gap met het hogere niveau en neveneenheden. En het groene optreden krijgt nog steeds de nadruk bij het opleiden en trainen, ondanks dat niet aan grootschalige conflicten wordt meegedaan. Zeker zo n 70% van de oefentijd van een manoeuvrebataljon wordt besteed aan de klassieke gevechtsvormen. Dat is ook logisch want tijdens missies moet men in staat zijn tot op het hoogste niveau van het geweldsspectrum op te kunnen treden. De complexiteit van operaties voor manoeuvrebataljons is wel duidelijk toegenomen, denk alleen al aan het verschijnsel 3-block warfare. Het is heel goed mogelijk dat een eenheid in zijn AOR bezig is met humanitaire hulpverlening en tegelijkertijd een opdracht als cordon & search moet uitvoeren waarbij verdachten van aanslagen worden opgepakt. Deze toegenomen complexiteit leidt tot een grotere behoefte aan informatie en zodoende grotere informatiestromen. Dus er is zeker noodzaak voor een C2-systeem als TITAAN maar deze zou dan beter op het mobiele domein moeten worden afgestemd. Zoals hierboven ook al aangegeven zou een oplossing voor het sneller ontplooien en afbreken van het netwerk het gebruik van WLAN kunnen zijn. In de uitrol en aansluiting van de kabels gaat nu namelijk de meeste tijd zitten. Begrijpelijk komt bij wireless de veiligheid van het systeem om de hoek kijken maar met de huidige technologie moet het mogelijk zijn om een secure WLAN te ontplooien. Dit zou de flexibiliteit en ontplooiingstijd van het LAN, en daarmee de inzetbaarheid èn draagvlak bij de gebruikers, ten goede komen. Qua uitstraling in het EM-spectrum mag dit ook geen probleem zijn: een batcp is door het aantal gebruikte VHF-netten veel duidelijker zichtbaar dan het relatief zwakke radiosignaal van WLAN. De nu gebruikte middelen voor WAN-connectie, straalzender of satcom (of statisch: ISDN), zijn relatief snel operationeel. Deze systemen zullen dan ook geen directe beperking betekenen als het gaat om opbouwtijd. Wel is het zo dat met de toename van alle CIS-voertuigen - met de C2ostgp inclusief een eventueel detachement van 101 CISbat kom je al snel op een aantal van 7 - de batcp groter en logger is geworden. Deze uitbreiding en het feit dat het om soft vehicles gaat, maakt een dergelijke commandopost die daadwerkelijk bezig is een gevecht te leiden, kwetsbaarder. Met de satcom (TT s) waren zoals aangegeven nog veel problemen. De verwachting is dat dit middel straks wel goed inzetbaar zal zijn. Het is immers een onmisbare schakel voor eenheden die onafhankelijk en soms op grote afstanden moeten optreden. Een ander probleem voor de S6 is het ontbreken aan informatie over het netwerk. CISman zou het tooltje worden wat inzicht zou verschaffen over het netwerk. Het gemis van dit hulpmiddel is duidelijk gebleken bij een aantal brigadeoefeningen. Als een eenheid gaat verplaatsen zijn zij middels TI- TAAN niet meer te bereiken. Hierover worden de andere commandoposten niet geïnformeerd. Deze informatie heeft men in feite alleen bij het MCCC (of CISCC) die door de S6 van een eenheid door middel van een bedrijfsvoeringbericht wordt ingelicht over een op handen zijnde verplaatsing. Op dit moment kan ik de bataljonsstaf niet informeren dat bijvoorbeeld de brigcp gaat verplaatsen en daardoor niet meer te bereiken is over TITAAN. Als nu blijkt dat er niet meer gebeld kan worden met de brigadestaf dan kan dat betekenen dat ze aan het verplaatsen zijn òf dat er een probleem is met de WAN-connectie. Dit is toch wel essentiële informatie voor een S6. Kortom: op dit moment ontbreekt het de S6 van zowel bataljon als brigade aan inzicht in het WAN en daardoor kan hij dus geen goed advies uitbrengen richting de staf en zijn commandant. Een tool als CISman is dus onmisbaar. De toegenomen complexiteit van operaties brengt ook met zich mee dat een bataljonsstaf voor een bepaalde actie tijdelijk wordt uitgebreid met extra functionarissen (van bijvoorbeeld brigadeniveau). Hierbij kan gedacht worden aan een jurist, een Tactical Psyops Team (TPT), een Tactical Air Control Party (TACP), enz. Deze functionarissen kunnen met hun werkstation niet inloggen op de BAM van 44 Painfbat (hierboven ook al aangegeven bij multiple forest-single domain ). Zij zullen dus de voor hen noodzakelijke gegevens lokaal moeten opslaan om standalone te kunnen werken. Probleem is wel dat zij geen nieuwe informatie meer ontvangen omdat ze niet aan het netwerk hangen. Hierbij komt tegelijk een ander probleem om de hoek kijken. Vanwege het feit dat men van TITAAN een NATO secret netwerk wilde maken zijn de poorten van de werkstations standaard gesloten. Middels het tooltje Sanctuary kan de C2ostgp, op aangeven van de S6, deze poorten laten openen waardoor toch data uitwisseling met stand alone laptops mogelijk wordt. Anders ontstaan er onwerkbare situaties. Dezelfde moeilijkheid doet zich voor bij de uitwisseling van gegevens met het onderlig- 42

7 gende niveau, de compagnieën. Met hen is nog geen digitale communicatie mogelijk maar de noodzaak is overduidelijk. Op dit moment nemen compagniestaven meestal hun LAN2000 laptops mee te velde waarbij ze dan ook gelijk niet meer op steun kunnen rekenen van DTO. Deze werkstations zijn uiteraard niet aansluitbaar op het TI- TAAN LAN. Echter, zeker door het werken met Team Intell Cellen (TIC) op compagniesniveau ontstaat een (digitale) informatiestroom richting het bataljon. Dit hebben we gedeeltelijk kunnen oplossen door uit de TITAAN werkstations van de bataljonsstaf een aantal te reserveren voor standalone gebruik bij de compagnieën. Als een compagniescommandant voor bijvoorbeeld een bevelsuitgifte bij de batcp moet zijn, neemt hij dat werkstation mee en kunnen alsnog gegevens worden uitgewisseld. Een structurele oplossing hiervoor zal ongetwijfeld ingevuld worden door de invoering van BMS. Ook voor de functionarissen die tijdelijk onder bevel worden gesteld is deze methode een oplossing hoewel het aantal werkstations op bataljonsniveau natuurlijk niet oneindig is. Vanwege het feit dat na het primen en stagen de configuratie van een BAM vastligt, zal de S6 dus van tevoren rekening moeten houden met (tijdelijke) uitbreiding van de bataljonsstaf. Op dit moment vul ik dit in door in de USP aan te geven dat een aantal accounts gereserveerd moet worden voor bijvoorbeeld een genieadviseur, een luchtdoelartillerist, enz. (lijkt op wat we bij ZO- DIAC noemden verwacht maken ). Verder blijft de wens bestaan om via een shared folder informatie te kunnen uitwisselen met de brigade en andere eenheden. Hopelijk kan daar ondanks de gekozen architectuur voor fase 2/3 toch een oplossing voor worden gevonden. Volgens mij kan de bandbreedte van de huidige WAN-middelen niet de bottleneck zijn voor de informatiestroom die sharing met zich meebrengt (hooguit zou de bestandsgrootte van de gedeelde bestanden beperkt moeten worden). Hoewel tijdens Iron Sword veel problemen waren met de remote client is dit middel wel een uitkomst voor het optreden van de VCP. Op deze manier kan de BC toch digitaal op de hoogte blijven van het brigadeoptreden en vooral: bellen met het achtergebleven gedeelte van de batcp of de brigadecommandant. Hopelijk wordt de RBGAN, waarmee we dus heel veel problemen hadden in Noorwegen, nog verbeterd of wordt een andere oplossing gezocht. Het is namelijk essentieel dat de VCP voorzien blijft van de laatste informatie tijdens een actie en daarom zou een remote client standaard bij de BAM van een manoeuvrebataljon moeten worden ingedeeld. De voorwaartse commandopost bestaat alleen uit n en heeft dus geen beschikking over 220 V. De remote client moet dus TITAAN gebruiker in geschikt gemaakt worden voor de voertuigspanning van de (of een omvormer in de ). Juist over dit soort kleine zaken blijkt bij de invoering van TITAAN nauwelijks nagedacht te zijn. Zonder goede randvoorwaarden en zonder kennis van het optreden van eenheden blijft ook een mooi C2-systeem als TITAAN onvoldoende inzetbaar. VOIP/TMS Zoals eerder vermeld wordt VOIP als een uitstekend middel ervaren. TITAAN heeft mijns inziens vooral ingang gevonden door het gemak en gebruik van deze telefoon. Zonder dit middel was het vele malen moeilijker geweest om binnen de staf een draagvlak voor TITAAN te creëren. Doordat functionarissen nu direct met hun contactpersoon kunnen spreken, kunnen zaken veel makkelijker gecoördineerd worden. Dit middel is hele duidelijk verbetering ten opzichte van de oude situatie met alleen maar Combat Net Radio (CNR). De mailclient TMS is ook zeker een verbetering; zoals hierboven aangegeven worden de SIC s wel als lastig ervaren. Dit spitst zich toe op welke functionaris zich op welke SIC moet abonneren en hoe men personen wil bereiken. Hier komt de IV-taak van de S6 om de hoek kijken. In overleg met de PBC stel ik meestal een lijst op welke functionaris welke onderwerpen ontvangt. De abonneering kan desnoods nog tijdens de oefening gewijzigd worden door de C2ostgp. Het liefst zou men op bataljonsniveau maar een stuk of 8 SIC s gebruiken. Dat aantal is voldoende om alle functies (op bataljonsniveau!) te benoemen en de juiste personen te bereiken. Helaas zijn we daarbij afhankelijk van wat de brigade aan SIC s voor een bepaalde oefening wil gebruiken. Op dat niveau zijn namelijk meer functionaliteiten (lees: specialismen) en daardoor meer onderwerpen dus meer SIC s. Mijn verwachting is dat de SIC s in de loop van de tijd minder problemen gaan opleveren omdat men dan gewend is aan deze manier van adressering. Het is voor de gebruikers een goede zaak dat intern de staf wel op functiegebied g d kan worden. ISIS Naar onze ervaring is het grootste probleem met ISIS dat dit systeem niet op bataljonsniveau is afgestemd. Voor dit niveau is ISIS ook nooit ontworpen. En het nut van naar beneden geschoven middelen met een bepaalde functionaliteit houdt een keer op. Als ik het altijd goed begrepen heb is ISIS bedoeld als geografische planningstool en als middel voor situational awareness. Alleen door middel van shared situational awareness ontstaat een common operational picture (COP). Een eenduidige COP is van groot belang voor de commandovoering: iedereen kijkt naar hetzelfde plaatje. En juist als middel voor verbetering van de situational awareness voldoet ISIS niet, in ieder geval niet op bataljonsniveau. Er wordt niet real-time aangegeven wat aan de situatie verandert zoals bij BMS. Daarvoor is het systeem duidelijk ook niet bedoeld. Het bijhouden van de current situatie vergt ook veel te veel tijd en mankracht voor een bataljonsstaf die bezig is een gevecht te leiden. En dat laatste gebeurt niet met ISIS maar over de radio. De CNR is nu (nog) hét middel voor de situational awareness op bataljonsniveau. Het up-to-date houden van oleaten is dan ook hooguit een bevrediging voor het hogere niveau (of neveneenheden), nau- 43

8 welijks voor een verbetering van de situational awareness binnen de bataljonsstaf. Misschien ten overvloede: richting de ondercommandanten is dus niet in een dergelijk middel voorzien en wordt ouderwets op plastic oleaten aangegeven wat het plan is. Het koppelvlak ligt dus op bataljonsniveau waar de stafcapaciteit toch al schaars is. Concreet: de S3 moet in ISIS het operatieoleaat tekenen, een arbeidsintensieve taak, en op plastic voor de bevelsuitgifte aan de ondercommandanten. Een zeer ongewenste situatie omdat de werkdruk bij de sie S3 tijdens oefeningen toch al hoog is. Overigens beschikt het bataljon sinds kort over een kleurenprinter bij de C2ostgp waarmee de oleaten ook op A3 formaat geprint kunnen worden. Dan moet het oleaat dus wel compleet klaar zijn voor de bevelsuitgifte. Afhankelijk van de tijdsdruk kan dat inhouden dat na het kiezen van een EM (Eigen Mogelijkheid) nog maar een uur tot 1,5 uur over is voor het tekenen van het complete operatieoleaat. Dan moet je dus wel over een ervaren ISIS-gebruiker beschikken. Daarnaast hebben we met ISIS te maken met info pull in plaats van info push: de gebruiker is, in tegenstelling tot voorheen via de radio, zelf verantwoordelijk voor het openen van oleaten om op de hoogte te zijn van alle plannen van de andere eenheid. Tijdens de NRF-oefeningen ging dat soms wel om meer dan 10 tot 15 oleaten over elkaar heen! Dit probleem kwam duidelijk naar voren tijdens de oefening Bison Prepare. Het oleaat van 1 (DNK) Light Recce Coy was niet geopend of niet zichtbaar. Dit leidde er uiteindelijk toe dat er een blue-on-blue situatie ontstond tussen eenheden van ons Bteam en de commandopost van deze Deense verkenningseenheid. De Deense commandopost stond namelijk wel op hun eigen oleaat maar door het niet zichtbaar zijn van dit ISIS-overlay was tijdens de bataljonsbevelsuitgifte de commandopostlocatie van de Denen onvermeld gebleven. Hadden we beschikt over een geïntegreerd operatieoleaat van de brigade dan had dit voorkomen kunnen worden. Uit bovenstaande mag duidelijk zijn dat ik geen voorstander ben van het gebruik van ISIS op bataljonsniveau. Wat dat betreft heb ik meer vertrouwen in BMS dat duidelijk meer op het operationele optreden van manbats is afgestemd. Kort wil ik hieronder nog een aantal punten over ISIS noemen die voor verbetering vatbaar zijn: Hierboven is al aangegeven, dat ISIS duidelijk voor de grote lijnen is bedoeld. Het intekenen van een teamvak langs een weg of rivier met een detail dat nodig is voor bataljonsniveau (en lager) leidt tot een onmogelijk dikke lijn. Bij vakgrenzen wordt namelijk tussen elk puntje een eenheidsteken geplaatst waardoor het zicht op de werkelijke lijn verloren gaat. Om zo n lijn in detail te kunnen tekenen moet ingezoomd worden. Bij het tekenen van de lijn scrollt de kaart echter niet mee; er moet dus steeds opnieuw begonnen worden met het tekenen van de lijn waar men gebleven is. Dit kan overigens voorkomen worden door eerst heel grof en op grote schaal de lijn te tekenen en later op detailniveau punten toe te voegen zodat de lijn verfijnd kan worden. Een tijdrovende klus. Het vinden van de juiste lijn (of object) is ook niet gemakkelijk. Uit de objectenlijst moet een hoofdcategorie gekozen worden. Middels allerlei onderliggende lagen (subsub-sub) moet dan het gewenste object gekozen worden. Dit zou makkelijker gaan met een soort wizard voor het tekenen van objecten. Ook staan niet alle objecten die bekend zijn bij de operationele gebruiker in de tekenset. Al eerder is aangegeven dat de symbolen uit PBC achter een heel secret werkstation 44

9 De uitgebreide VCP APP 6A komen, maar dat men bij de manoeuvre ook nog andere tekens gebruikt. Als de huidige symbolen niet volstaan, moet in overleg met OTCMAN/GTS voorzien worden in een aanvulling. Het niet voorkomen van objecten frustreert een gebruiker onnodig en draagt niet bij aan een positief beeld van een commandovoeringondersteunend systeem. Ik schreef al dat het in ISIS ontbreekt aan een schetsfunctionaliteit. Nu wordt dat opgelost door een printscreen van GIS in powerpoint te openen waar de S3 schetsmatig zijn EM n kan tekenen waarbij de andere secties kunnen meekijken. Juist tijdens het OBP zou ISIS een prima ondersteunend middel kunnen zijn. Snel kunnen schetsen is dan een vereiste. Tot slot wil ik de complexe Library structuur noemen. Tijdens de NRF-periode hebben we gewerkt met een uitgebreide Library met subfolders waarin de contexten een plaats kregen. Elke eenheid had zijn eigen subfolder in Own Situation en Plans. Vervolgens was ook deze submap, bijvoorbeeld bij Plans weer onderverdeeld in Current, Future en Historical. Soms was het een heel zoekplaatje om een compleet beeld te krijgen van een lopende operatie. Vereenvoudiging van de Library is met het oog op gebruikersgemak zeker gewenst. CONCLUSIE Het is voor mij nog maar de vraag of het wenselijk was de invoering van TITAAN te vervroegen voor NRF-4. Het feit dat de BAM s pas in een heel laat stadium opgeleverd werden, de opleidingen nog niet gereed waren, de veel problemen veroorzakende TT s, de -CO s niet TITAAN gemodificeerd waren (en nu nog niet), TI- TAAN niet operationeel getest was, enz. zorgde er op bataljonsniveau regelmatig voor dat het systeem niet werkte. Dit is dodelijk voor het vertrouwen van commandanten in een nieuw C2-systeem en het creëren van een draagvlak bij de gebruikers. En de S6 is er van... Voor het creëren van een draagvlak van dit soort systemen is het noodzakelijk dat ze laagdrempelig worden ingevoerd, afgestemd op de gebruiker en met voldoende implementatiebegeleiding. Ik als S6 geloof zeker dat de nieuwe commandovoering ondersteuningsmiddelen en de Network Centric Warfare filosofie achter deze systemen een bijdrage kunnen leveren aan een dominante positie ten opzichte van een mogelijke tegenstander en daarmee - met een mooi woord - een force multiplier kunnen zijn. Maar daarvoor moet men de middelen wel afstemmen op het niveau waarop ze ingezet worden. Het is daarom van het allergrootste belang dat gebruikers van deze niveaus deelnemen aan het ontwikkelproces van dergelijke producten. Ten minste moeten functionarissen die kennis hebben van het operationele optreden van de manoeuvre geraadpleegd worden. Gelukkig is dat bij bijvoorbeeld de ontwikkeling van OSIRIS, de opvolger van BMS, wel mijn ervaring. Een periode van voorbereiding en standby voor de NRF is door de vele oefeningen op hoog niveau ontzettend leerzaam. Op het gebied van C2-ondersteuning zijn duidelijk zaken naar voren gekomen die voor verbetering in aanmerking komen. Een aantal daarvan heb ik geprobeerd in dit en het vorige artikel weer te geven. Interoperabiliteit en het afstemmen van de commandovoering ondersteuningsmiddelen op het operationele optreden van de diverse eenheden, het juiste middel op het juiste niveau, zijn daarbij wat mij betreft sleutelbegrippen. TITAAN bij de manoeuvre: het kan anders en het kan beter. Daarin hebben we met z n allen nog een weg te gaan. 45