Beheer van doelmappen: het doelsysteem bouwen en onderhouden

Een doel is geen coördinaat. Het is een gestructureerd geheel van kennis – verzamelde inlichtingen, fysieke beschrijving, functionele analyse, beoordeling van het nevenschaderisico en commandogezag – georganiseerd in een doelmap die bestaat vanaf het moment van nominatie tot en met de schadebeoordeling na de aanval. Software voor doelmapbeheer is het systeem dat deze kennis bewaart, de workflows handhaaft die bepalen hoe ze wordt opgebouwd en goedgekeurd, en de gezamenlijke doellijst (JTL) gesynchroniseerd houdt met het operationele beeld. Dit artikel onderzoekt hoe die software is gearchitecteerd, welke gegevens ze moet beheren, en hoe ze integreert met het bredere gemeenschappelijk operationeel beeld en de C2-omgeving.

De doelmap: gegevensmodel en vereiste velden

De doelmap is het gezaghebbende record voor één enkel doel gedurende de hele levenscyclus ervan in het targetingsysteem. Het gegevensmodel ervan moet meerdere categorieën informatie kunnen bevatten die verschillende classificatieniveaus, brontypes en updatecycli omspannen.

Locatie en geometrie. De genomineerde doellocatie (NTL) is een WGS84-coördinaat die tijdens de nominatie wordt toegewezen. Naarmate de ontwikkeling vordert, wordt de NTL verfijnd tot een gemiddeld inslagpunt (MPI) – de coördinaat waarop wapens worden gericht. De doelmap bewaart beide waarden, met bijbehorende nauwkeurigheidscijfers: een cirkelvormige waarschijnlijke fout (CEP) of de gelijkwaardige datum-nauwkeurigheidsverklaring uit de broninlichtingen. Als het doel een gebied beslaat (een depot, vliegveld of commandoknooppunt met meerdere functioneel significante componenten), bewaart de map een polygoonvoetafdruk naast de MPI.

Doelidentificatie en -beschrijving. Elk doel krijgt een doelserienummer (TSN) dat door de targetingsoftware bij nominatie wordt toegewezen. Aanvullende identificatievelden omvatten de doelcategorie (uit een gestandaardiseerde doelcategorielijst die is afgestemd op doctrinaire kaders voor doelsysteemanalyse), de doelnaam en kruisverwijzingen naar bestaande vermeldingen in de inlichtingendatabase voor hetzelfde object. De sectie fysieke beschrijving bevat gestructureerde velden over de grootte, het bouwtype, de bovengrondse en ondergrondse omvang van het doel, en onderscheidende kenmerken die zichtbaar zijn in beeldmateriaal.

Functionele analyse. De targetingofficier documenteert welke componenten van het doel functioneel kritiek zijn – die waarvan vernietiging of neutralisatie het gewenste effect zou bereiken – en welke redundant of secundair zijn. Deze analyse stuurt de weaponeeringstap: de selector moet weten welk richtpunt het gewenste effect oplevert, niet louter welke coördinaat het wapen binnen de doelgrens plaatst.

Records van inlichtingenbronnen. Elk gegevenselement in de map draagt een bronreferentie: het inlichtingenrapport, beeldproduct of menselijke melding die het ondersteunt. Bronreferenties omvatten classificatiemarkeringen, opsteller en datum. De software moet meerdere classificatieniveaus binnen één map ondersteunen, met toegangscontrole op veldniveau die voorkomt dat gebruikers zonder de vereiste machtiging geclassificeerde brondetails zien, terwijl ze nog steeds met het geschoonde doelrecord kunnen werken.

Gegevens voor de schatting van nevenschade. De schatting van nevenschade (CDE) is een verplichte stap voordat enig doel kan worden goedgekeurd voor inzet. De map bewaart de CDE-invoergegevens – beeldmateriaal van omliggende structuren, afstandsmetingen tot beschermde locaties, schattingen van de bevolkingsdichtheid – en de CDE-resultaten voor elke overwogen wapenoptie. Omdat CDE-resultaten ongeldig worden door coördinaatwijzigingen of veranderingen in de omliggende omgeving, moet de software CDE-records van een versie voorzien en ze markeren voor herberekening wanneer hun invoergegevens veranderen.

De gezamenlijke targetingcyclus en softwareworkflow

De gezamenlijke targetingcyclus biedt het procedurele kader waarbinnen software voor doelmapbeheer functioneert. De cyclus kent zes fasen, en de workflow-engine van de software weerspiegelt elke fase met configureerbare statusovergangen en routeringsregels.

Fase 1: Richtlijnen van de commandant. Voordat targeting begint, geeft de commandant richtlijnen die het doelsysteem definiëren (welke categorie doelen de doelstellingen van de operatie ondersteunt), de gewenste effecten, de beperkingen en eventuele doelen die verboden zijn vanwege operationele, juridische of politieke overwegingen. Deze richtlijnen worden in de targetingsoftware gecodeerd als configuratie op campagneniveau: een lijst van goedgekeurde doelcategorieën, een lijst van beperkte en niet-aan-te-vallen objecten (gevuld vanuit de beperkte-doelenlijst- en niet-aan-te-vallen-lijst-databases), en effectdrempels die de CDE-methodologie niet mag overschrijden zonder verhoogde commandogoedkeuring.

Fase 2: Doelontwikkeling. De targetingcel nomineert doelen en vult hun mappen. De software handhaaft een checklist van minimale inhoud voordat een map kan worden bevorderd van 'genomineerd' naar 'ontwikkeling voltooid' – alle vereiste velden moeten zijn ingevuld en alle bronreferenties bijgevoegd. Onvolledige velden worden in de UI gemarkeerd, en de checklist stuurt de workflow van de targetingofficier in plaats van te vertrouwen op handmatige tracking in spreadsheets of gedeelde documenten.

Fase 3: Weaponeering en capaciteitenanalyse. De weaponeeringofficier selecteert wapen-richtpuntcombinaties die het gewenste effect bereiken tegen de kritieke componenten die in de functionele analyse zijn geïdentificeerd. De targetingsoftware bewaart weaponeeringresultaten als gestructureerde records die zijn gekoppeld aan specifieke richtpunten in de doelgeometrie, met het wapentype, de ontstekerinstelling, de afleverparameters en de voorspelde effecten. CDE wordt uitgevoerd voor elke overwogen wapenoptie, en de resultaten bepalen welke opties beschikbaar zijn op het goedgekeurde commandoautoriteitsniveau.

Fase 4: Krachttoepassing. Goedgekeurde doelen worden toegevoegd aan de gezamenlijke doellijst en toegewezen aan aanvalsplatforms – vliegtuigen, artillerie of elektronische oorlogvoering – via de luchttaakopdracht (ATO) of een gelijkwaardig taakmechanisme. De targetingsoftware registreert de toewijzing en werkt de doelstatus bij om weer te geven dat inzet is gepland. Integratie met de vuurleiding-C2-laag voor artillerie is in deze fase een belangrijke interface: de targetingsoftware moet richtpuntcoördinaten, ontstekergegevens en effectvereisten doorgeven aan het vuurleidingssysteem, en uitvoeringsbevestiging terug ontvangen.

Fase 5: Uitvoeringsplanning en uitvoering. Eenmaal toegewezen, bewaken targetingofficieren de uitvoeringsstatus via de integratie van de targetingsoftware met het operationele C2-beeld. Wanneer een platform de uitvoering meldt – wapenlossing of vuuruitvoering – registreert de targetingsoftware de uitvoeringsgebeurtenis en activeert de BDA-workflow.

Fase 6: Beoordeling. Schadebeoordelingsgegevens – beeldmateriaal, signalen of grondrapportage – worden ingevoerd als een gestructureerd beoordelingsrecord in de doelmap. De beoordelingsworkflow vergelijkt de waargenomen effecten met de gewenste effecten uit fase 1, classificeert het resultaat (doel vernietigd, doel beschadigd en herhaalde aanval vereist, doel onbeschadigd) en genereert een aanbeveling voor herhaalde aanval als het gewenste effect niet werd bereikt. Het voltooide BDA-record sluit de targetingcyclus voor dat doel af; doelen die een herhaalde aanval vereisen worden teruggezet op de JTL met bijgewerkte mappen.

Doellijstbeheer: de JTL als een levende database

De gezamenlijke doellijst is geen statisch document – het is een levende databaseweergave die voortdurend verandert naarmate doelen worden genomineerd, ontwikkeld, goedgekeurd, ingezet en beoordeeld. Software voor doelmapbeheer onderhoudt de JTL als een gefilterde, gesorteerde query over de onderliggende doeldatabase, met configureerbare weergaven voor verschillende gebruikers en commandoniveaus.

De JTL-weergave toont doelen gegroepeerd per categorie, effect of geografisch operatiegebied. Targetingofficieren kunnen filteren op doelstatus, prioriteit, toegewezen platform of tijdvenster. Commandanten zien een overzichtsweergave met doelprioriteit, JTL-positie en uitvoeringsstatus. Juridisch adviseurs zien de wachtrij voor CDE- en proportionaliteitsbeoordeling. Elke rol ziet dezelfde gezaghebbende gegevens uit dezelfde database, alleen onderscheiden door toegangscontrole en weergaveconfiguratie.

De prioritering van doelen op de JTL wordt aangestuurd door een scoremodel dat de bijdrage van het doel aan de doelstellingen van de commandant, de tijdgevoeligheid (heeft het doel een beperkt venster waarin het beschikbaar of kwetsbaar is?) en de kosten van inzet in termen van platformbeschikbaarheid en risico meeneemt. De software registreert de prioriteringsrationale, wat belangrijk is voor de evaluatie na de operatie en om aan te tonen dat targetingbeslissingen werden genomen in overeenstemming met de richtlijnen van het commando en het toepasselijke recht.

Integratie van de niet-aan-te-vallen- en beperkte-doelenlijst

De niet-aan-te-vallen-lijst (NSL) en de beperkte-doelenlijst (RTL) moeten in de targetingsoftware worden geïntegreerd op de gegevenslaag, niet als een controle op UI-niveau. Elke doelmap wordt automatisch getoetst aan de NSL en RTL wanneer coördinaten worden ingevoerd of bijgewerkt. Als de MPI van een doel binnen de nabijheidsdrempel van een beschermde locatie valt – een ziekenhuis, school, cultureel erfgoed of religieuze locatie – markeert de software het potentiële conflict en vereist een uitdrukkelijke bevestiging van de goedkeurende officier voordat het doel kan worden bevorderd. De nabijheidsdrempel is configureerbaar per categorie beschermde locatie en per de toepasselijke geweldsinstructies.

NSL- en RTL-gegevens worden onderhouden als een afzonderlijke, gecontroleerde database die vanuit het hogere commando naar de targetingsoftware wordt gesynchroniseerd. Het updatemechanisme moet betrouwbaar en controleerbaar zijn: elke wijziging in de NSL of RTL wordt vastgelegd met een tijdstempel, bronautoriteit en de specifieke objecten die zijn toegevoegd of verwijderd. Doelen waarvan de NSL/RTL-nabijheidsstatus verandert door een NSL-update – niet door een verplaatsing van het doel – moeten opnieuw worden gemarkeerd voor beoordeling, zelfs als hun eigen gegevens niet zijn gewijzigd.

Softwarearchitectuur: de targetingdatabase en haar interfaces

De kern van software voor doelmapbeheer is een gestructureerde relationele database met een documentopslag voor bijlagen – beeldminiaturen, beeldproducten in volledige resolutie, CDE-werkbladen en beoordelingsrapporten. De relationele laag bevat het doelrecord met alle gestructureerde velden; de documentopslag bevat binaire en grote tekstbijlagen die gekoppeld zijn aan het doelserienummer.

De targetingdatabase moet gelijktijdige bewerking door meerdere targetingofficieren ondersteunen, met conflictdetectie en -oplossing voor de gedeelde velden (JTL-prioriteit, doelstatus, richtpuntcoördinaten). Versiegeschiedenis voor alle gestructureerde velden is een basisvereiste: targetingautoriteiten moeten de toestand van elke doelmap kunnen reconstrueren op het moment van elke goedkeurings- of uitvoeringsgebeurtenis voor juridische evaluatie na de operatie.

Integratie-interfaces verbinden de targetingsoftware met de rest van de C2-omgeving. De primaire interface is de COP-laag, die goedgekeurde doelrecords uit de JTL consumeert als geospatiale overlays – doelreferentiepunten, benoemde aandachtsgebieden of inzetzones die als kaartelementen worden gepubliceerd. Deze interface is bidirectioneel: uitvoeringsgebeurtenissen en BDA-invoer stromen terug vanuit de COP- en ISR-lagen naar de targetingdatabase. Een secundaire interface verbindt de targetingsoftware met het vuurcoördinatiesysteem voor directe overdracht van richtpuntgegevens, wapenparameters en uitvoeringsbevestiging. Zie de gerelateerde behandeling van JTAC- en CAS-coördinatiesoftware voor de workflow voor de coördinatie van nabije luchtsteun die parallel loopt met de beraadslaagde targetingcyclus.

Classificatieafhandeling en multidomein-toegangscontrole

Doelmappen bundelen gegevens uit meerdere inlichtingenbronnen die op verschillende classificatieniveaus opereren. Eén enkele map kan ongeclassificeerd beeldmateriaal van commerciële satellieten, signaalinlichtingen op geheim niveau en zeer geheime menselijke rapportage bevatten – allemaal over hetzelfde doel. De software moet classificatielabels op veldniveau implementeren en deze handhaven op de API-laag, niet alleen in de presentatielaag.

De praktische implicatie is dat een targetingofficier met een geheim-machtiging en een targetingofficier met een zeer-geheim-machtiging verschillende versies van dezelfde doelmap kunnen zien. Beiden zien de coördinaten, categorie en JTL-status van het doel. Alleen de hoger-gemachtigde officier ziet de op HUMINT gebaseerde functionele analyse. De software moet aan elke gebruiker een coherente, consistente weergave tonen op basis van zijn toegangsniveau – niet simpelweg velden leeg laten, wat verwarring creëert over de vraag of er gegevens bestaan.

Coalitieoperaties voegen een extra dimensie toe: personeel van partnernaties kan gelijkwaardige machtigingsniveaus hebben maar verschillende nationale voorbehouden die de toegang tot inlichtingen uit specifieke bronnen beperken. Het toegangscontrolemodel moet voorbehoudgebaseerde filtering ondersteunen naast classificatieniveaugebaseerde filtering, en moet configureerbaar zijn voor de deelregels van elke coalitie zonder dat softwareaanpassing nodig is.