Het overgrote deel van de defensietechnologie die momenteel wordt aangeboden aan NAVO-lidstaten is nooit ingezet in echte gevechtsoperaties. Het is ontwikkeld, getest in gecontroleerde omgevingen, gedemonstreerd aan evaluatiepanelen en gecertificeerd als voldoend aan de specificatie. Dit is niet hetzelfde als gevechtsbewezen zijn — en het verschil is van belang op manieren die van tevoren moeilijk te kwantificeren zijn maar pijnlijk duidelijk worden na inzet.
Sinds 2022 is Oekraïne 's werelds meest actieve testomgeving voor defensietechnologie geworden. De intensiteit, duur en het peer-tegenstander karakter van het conflict hebben storingsoorzaken in militaire software blootgelegd die jaren van oefeningen en demonstraties niet hadden onthuld.
Wat "gevechtsbewezen" werkelijk betekent
Gevechtsbewezen betekent niet gevechtsbeproefd in de zin van deelname aan kinetische aanvallen. Het betekent dat de software is bediend door echte militaire gebruikers, in echte operationele omstandigheden, onder echte operationele druk, gedurende een aanhoudende periode — en dat de storingsoorzaken die naar voren kwamen zijn geïdentificeerd, opgelost en de oplossingen opnieuw zijn getest onder dezelfde omstandigheden.
Dit is een cumulatieve kwaliteit. Een softwaresysteem bouwt operationele ervaring op door te worden ingezet, te falen, die storingen te analyseren en aan te pakken, opnieuw te worden ingezet, en deze cyclus te herhalen. Het resultaat is een systeem waarvan de randgevallen zijn gevonden en verwerkt — niet omdat de ontwikkelaars ze hadden voorzien, maar omdat de operationele realiteit ze aan het licht bracht.
Oekraïne: 's werelds meest actieve defensietech-testomgeving
Verschillende kenmerken maken het Oekraïense conflict uniek waardevol als technologietestomgeving. Ten eerste de snelheid: het conflict heeft aanhoudende hoogintensiteitsoperaties gezien met een tempo dat oefeningen niet kunnen repliceren, waardoor jaren aan operationeel gebruik in maanden worden samengeperst. Ten tweede de vijandelijke geavanceerdheid: Russische elektronische oorlogvoering, cyberoperaties en anti-drone-mogelijkheden hebben defensietechnologieën getest tegen een peer-tegenstander. Ten derde de snelheid van de feedbacklus.
De specifieke lessen uit deze omgeving zijn concreet. Command-and-control software die betrouwbaar werkte in oefeningen op brigadeniveau faalde wanneer gebruikt door bataljons onder vuur. Logistiekapplicaties die goed presteerden in connectiviteitsgegarandeerde omgevingen faalden onmiddellijk wanneer Russische EW communicatie verstoorde in betwiste gebieden.
Storingsoorzaken die alleen in echte operaties verschijnen
Netwerkverslechterende verwerking. De meest consistente bevinding uit operationele inzettingen is dat software ontworpen onder de aanname van adequate connectiviteit gracevol faalt in simulaties en catastrofaal in operaties. Echte tactische netwerken werken op 10–30% van de bandbreedte die beschikbaar is in een garnizoen- of oefencontext.
Operatorstress en fouttolerantie. Echte operators onder stress gebruiken software anders dan getrainde operators onder gecontroleerde omstandigheden. Ze drukken meerdere keren op knoppen omdat ze niet zeker weten of de eerste druk geregistreerd is. Ze onderbreken langlopende operaties. Ze selecteren verkeerde opties en moeten ongedaan maken.
Vijandelijke interferentie. Tegenstanders proberen actief softwaresystemen te verstoren — door jamming, spoofing en cyberaanvallen. Een systeem dat nooit is bediend in een vijandelijk betwiste omgeving heeft zijn veerkracht tegen deze bedreigingen nooit werkelijk laten testen.
Waarom labdemonstraties misleidend kunnen zijn
Een demonstratie is ontworpen om een systeem op zijn best te tonen: correct geconfigureerd, bediend door mensen die het goed kennen, draaiend op een betrouwbaar netwerk, tegen voorgeselecteerde scenario's. De evaluatiecriteria die in de meeste defensieaanbestedingsprocessen worden gebruikt, belonen demoprestaties eerder dan operationele veerkracht.
Kernpunt: De aanbestedingsvraag die gesteld moet worden is niet "kunt u demonstreren dat dit werkt?" — elke leverancier kan dat demonstreren. De vraag is: "waar is dit operationeel ingezet, hoe lang, en welke storingen traden op? Wat heeft u geleerd en wat heeft u veranderd?" Het antwoord op die vraag scheidt gevechtsbewezen van labgetest.
Wat aanbestedingsambtenaren moeten vragen over operationele geschiedenis
Enkele specifieke vragen scheiden gevechtsbewezen van labgeteste leveranciers. Ten eerste: noem de operationele inzettingen — niet pilots, niet proof-of-concept-engagementen, maar daadwerkelijke operationele inzettingen bij eenheden die echte missies uitvoeren. Hoe lang zijn die inzettingen al actief? Welke problemen werden gerapporteerd door operationele gebruikers?
Ten tweede: wat is het gedrag van het systeem wanneer het netwerk 30 minuten niet beschikbaar is? Gedurende 8 uur? Wat ziet de gebruiker? Welke data wordt bewaard?
Ten derde: beschrijf een specifieke operationele storing en wat u daaran deed. Een leverancier die geen specifieke storing kan beschrijven, heeft ofwel nooit hun systeem operationeel in gebruik gehad, of is niet openhartig.