Een C2-Systeem Bouwen Vanaf Nul, Deel 1: Grondslagen en Architectuur

De literatuur over command and control is rijk aan aanbesteding, doctrine en afkortingen; ze is schaars aan het antwoord op de vraag die een ingenieur daadwerkelijk wil: hoe bouw ik er één? Deze vierdelige reeks behandelt de bouw van een defensie C2-systeem van een leeg archief tot operationele implementatie. Deel 1 legt de grondslagen vast — scope, architectuur, schema's en techstack. Delen 2 tot en met 4 werken fusie, weergave en de interop-en-beveiligingswerkzaamheden door die het platform gereed maken voor uitlevering.

De reeks vormt een aanvulling op de architecturale Complete Gids voor Command and Control (C2)-Systemen, die het volledige vakgebied bespreekt. De reeks gaat smaller en dieper: één voorbeeldplatform, met genomen beslissingen, uitgelegd afwegingen en blootgelegde engineeringredenering. Het voorbeeld is generiek genoeg om toe te passen over echelons; de principes zijn overdraagbaar.

Stap 1: Kies een Scope en Commit Eraan

De eerste beslissing is de meest overgeslagen, en het is de beslissing die bepaalt of het platform operaties bereikt. Een C2-systeem dat is ontworpen om elk echelon te dienen — tactisch, operationeel, strategisch — dient doorgaans geen enkel echelon goed. Kies er één.

De bepalende vragen:

Echelon. Brigade en lager betekent latentiebudgetten in seconden, een plat datamodel en een UI voor gestresste operatoren met handschoenen op een tablet in het zonlicht. Divisie tot en met legerkorps betekent langere latencies, rijkere planningstools en stafofficieren aan werkstations. Gezamenlijk en nationaal betekent hiërarchische modellen, gecompartimenteerde intelligence en een desktopklasse analist-ervaring. De volledige behandeling van hoe echelon de architectuur vormgeeft staat in Wat Is een C2-Systeem?.

Domein. Land, maritiem, lucht of gezamenlijk domein. Elk heeft andere sensorfamilies, berichtstandaarden en operatorworkflows. Een multi-domeinplatform is een zwaarder engineeringinspanning dan een enkeldomeinsplatform en is zelden gerechtvaardigd voor een eerste build.

Coalitie vs. nationaal. Coalitie-implementatie betekent dat NATO-interoperabiliteit vanaf dag één een aanbestedingspoort is. Nationaal-only staat een soeverein datamodel toe met later gebouwde NATO-bridging. De interop-afwegingen staan in De Complete Gids voor NATO-Interoperabiliteit.

Classificatieplafond. De hoogste classificatie die het platform zal verwerken, bepaalt de accreditatie-inspanning, de netwerktopologie en de toolingkeuzes. Een NATO RESTRICTED-platform is ongeveer een orde van grootte gemakkelijker te bouwen dan een NATO SECRET-platform.

Schrijf de scopebeslissingen op. Tag elke architecturale ticket met welke scopebeslissing het dient. Scope creep — de geleidelijke toevoeging van echelons, domeinen of classificaties tijdens ontwikkeling — is de grootste oorzaak van programmafalen.

Voor het doorlopende voorbeeld in deze reeks kiezen we: brigade-level tactisch C2, multi-domein (land + lucht situationeel bewustzijn), NATO-interoperabel, classificatieplafond NATO SECRET. Andere keuzes zouden specifieke beslissingen door de reeks heen verschuiven maar niet de algemene architectuur.

Stap 2: Kies de Vierlagenarchitectuur

Elk operationeel C2-platform convergeert naar dezelfde vierlagenarchitectuur. Sensor, verwerking, weergave, communicatie. De naamgeving varieert; de verantwoordelijkheden niet. De architectuurregel is eenvoudig: elke laag heeft één verantwoordelijkheid, de interfaces tussen lagen zijn expliciet en geen concept lekt over laagsgrenzen.

Sensorlaag. Adapters die sensornatieve formaten (ASTERIX, STANAG 4586, CoT, AIS NMEA, ADS-B) vertalen naar het interne kanonieke spoor van het platform. Adapters zijn eenrichtingsdataconverters; ze nemen nooit beslissingen over sporen.

Verwerkingslaag. Spoorfusie, normalisatie, het gezaghebbende spooropslag. Het spoor is de gegevenseenheid waarop de rest van het platform opereert. Deze laag is het onderwerp van Deel 2.

Weergavelaag. Het Common Operational Picture en de omringende tooling. Taakverdeling, berichtenuitwisseling, planning. Webgebaseerde frontend die WebSocket- en REST-API's van de verwerkingslaag verbruikt. Het onderwerp van Deel 3.

Communicatielaag. Berichtbussen, opslaan-en-doorsturen-replicatie, cross-enclave-bridges, tactische radiointegratie. Het onderwerp van Deel 4 samen met interop en beveiliging.

Leg dit uit als daadwerkelijke archieven en services vanaf dag één. Weersta de verleiding om "met één service te beginnen en later te extraheren" — de extractie verloopt nooit soepel, en de laagsgrenzen vervagen op manieren die een jaar werk kosten om te repareren.

Stap 3: Ontwerp het Kanonieke Spoorschema

Het spoor is de centrale datastructuur van elk C2-platform. Elke adapter produceert sporen. Elke fusiebeslissing werkt sporen bij. Elke COP rendert sporen. Elk auditlog verwijst naar sporen. Zorg dat het schema klopt en het grootste deel van de rest van het platform is rechttoe rechtaan; zorg dat het fout gaat en de kosten cumuleren over jaren.

Het minimale levensvatbare spoorschema omvat:

• Spoor-ID. Stabiel, wereldwijd uniek, nooit hergebruikt. UUIDv7 of een getypt voorvoegsel plus UUID is een veilige standaard.
• Identiteit. Wat het spoor is. Type-taxonomie (vaartuig, luchtvaartuig, voertuig, persoon, eenheid) plus subtype en staartcijfer/scheepsnummer/callsign waar bekend. Identiteit wordt in de loop van de tijd gefuseerd; verwerk het niet in het ID.
• Positie. Breedtegraad, lengtegraad, hoogte. Coördinatenstelsel expliciet (WGS84 is de veilige standaard). Onzekerheidsellips — geen enkel getal; covariantiematrix of hoofd-/asas met peiling.
• Kinematische toestand. Snelheid (vector), draaisnelheid, afgeleid koers/vaart. Tijdgestempeld.
• Bronnenset. Welke adapters hebben bijgedragen aan dit spoor. Bronclassificatie, uitgeefbaarheid, vertrouwen.
• Tijdstempels. Drie afzonderlijke tijden: observatietijd (wanneer de sensor het zag), rapporttijd (wanneer het bericht de sensor verliet), ingesietijd (wanneer het platform het ontving). Deze samenvoegen is een veelvoorkomende foutenbron.
• Levenscyclusstatus. Tentatief, bevestigd, volwassen, vervaagd, verloren. Aangestuurd door de fusiemotor; zichtbaar voor de COP.
• Classificatie-envelop. Effectieve classificatie berekend uit de bronnenset. Uitgeefbaarheids-tags. Compartimentmarkeringen indien van toepassing.
• Vertrouwen en zekerheid. Vertrouwen op spoorniveau; per-attribuutzekerheid waar het van belang is (bijv. positie heeft hoge zekerheid maar identiteit is tentatief).

Versioner het schema additief. Nieuwe velden zijn optioneel; bestaande velden veranderen nooit van betekenis. Ingrijpende wijzigingen worden alleen over grote platformreleases geaccepteerd met een gedocumenteerde migratie. De gedetailleerde behandeling, inclusief patronen voor identiteitsnormalisatie en schema-evolutiestrategieën, staat in Defensie Data-integratieUitdagingen.

Stap 4: Kies de Techstack

De techstack voor een defensie C2-platform moet vier beperkingen in evenwicht brengen: operationele overleving (levenscyclus van 20 jaar), vriendelijkheid voor accreditatie (nationale goedkeuringslijsten), de bestaande vaardigheden van het team en de engineering-ergonomie die de sprintsnelheid bepaalt. De onderstaande keuzes zijn één verdedigbare set, niet de enige.

Backend-services: een getypte taal met een volwassen gelijktijdigheid-verhaal. Go en Rust zijn de twee sterke keuzes voor nieuwe programma's; Java blijft een verdedigbare incumbent. Vermijd nichemtalen met één onderhoudseenheid — het platform overleeft de taalgemeenschap.

Berichtbus: Kafka of NATS JetStream als het duurzame gebeurtenislogboek; de keuze daartussen staat in Berichtwachtrijen voor Defensiedatapipelines. Voor kleine implementaties is NATS lichter; voor grote implementaties is Kafka operationeel bewezen.

Geospatiale database: PostGIS op PostgreSQL is de standaard. Volwassen, accreditatievriendelijk, schaalbaar naar miljarden punten met juiste indexering. De engineeringdetails staan in PostGIS voor Defensie Geospatiale Data.

Tijdreeksdatabase: TimescaleDB als uitbreiding op PostGIS, of InfluxDB als aparte opslag. Sensorhistories en telemetrie horen hier, niet in de operationele spooropslag.

Frontendstack: React of Vue, getypt (TypeScript). Cesium voor 3D- en globusweergaven; Mapbox GL of MapLibre voor 2D. Gedetailleerde kaartweergave-afwegingen in Realtime Kaartweergave voor Militair C2.

Realtime-transport: WebSocket voor de browser, MQTT voor de tactische rand, gRPC voor service-naar-service binnen het datacentrum. Elk heeft een duidelijke toepassing en ze bestaan naast elkaar.

Authenticatie en autorisatie: OpenID Connect voor menselijke gebruikers (met nationale PKI-integratie waar vereist), service-naar-service mTLS met kortlevende certificaten. RBAC en classificatie gelaagd via een dedicated beleidsmotor — Open Policy Agent is een verdedigbare keuze. Het gedetailleerde patroon staat in Rolgebaseerde Toegangscontrole in Defensie C2-Systemen.

Implementatie: Containers (OCI), georchestreerd door Kubernetes in cloud of grote on-prem; systemd of k3s voor tactische randknooppunten. Dezelfde artefacten draaien over het spectrum; de orkestratie wijzigt.

Weersta overengineering. Een eerste build heeft geen service mesh, een multi-cloudabstractie of een zelfgebouwd framework nodig. De saaie keuzes — goed ondersteund, breed ingezet, met volwassen accreditatiebewijzen — zijn de juiste keuzes voor defensie.

Stap 5: Stel de Archiefstructuur In

Beslis vroeg over monorepo vs. multi-repo. Voor een nieuw platform met één team is een monorepo doorgaans correct: gedeelde bibliotheken (schema, RBAC-client, telemetrie) leven naast services, wijzigingen stromen atomair en het buildsysteem dwingt consistentie af. Multi-repo wordt aantrekkelijk alleen wanneer teamgrenzen uiteenlopen.

Een verdedigbare topniveaustructuur:

• schemas/ — kanoniek spoorschema, berichtschema's, API-contracten. Codegegenereerde bindingen voor elke consumertaal.
• adapters/ — sensoradapters, één per brontype.
• services/ — fusiemotor, spooropslag, beleidsmotor, auditservice.
• frontend/ — de COP en ondersteunende UI.
• tools/ — operationele tools, testframeworks, simulatoren.
• deploy/ — Kubernetes-manifesten, Helm-charts, Ansible-playbooks voor tactische randknooppunten.
• docs/ — architectuurbeslissingen (ADR's), runbooks, accreditatiebewijzen.

Behandel de documentatiemap als code: beoordeeld, geversioneerd, verplicht. ADR's (Architecture Decision Records) behoeden het platform voor het opnieuw bespreken van dezelfde afwegingen elke zes maanden wanneer een nieuwe ingenieur toetreedt.

Wat Volgt

Deel 1 heeft het platform omschreven. Scope gekozen, vierlagenarchitectuur vastgelegd, kanoniek spoorschema ontworpen, techstack gekozen, archief gestructureerd. Het skelet bestaat; er wordt nog niets van een sensor ingevoerd of een spoor gerenderd.

Deel 2: De Fusiemotor neemt het schema en bouwt de laag die sensorrapporten verwerkt, ze correleert in sporen en ze blootstelt aan de rest van het platform. Het is het engineeringhart van het C2-systeem, en het is hier dat de architectuurbeslissingen van Deel 1 worden getest tegen de realiteit.

Leg, voordat u doorgaat naar Deel 2, de scopebeslissingen vast en schrijf het kanonieke spoorschema op. De reeks gaat ervan uit dat beide voorhanden zijn.