Het selecteren van command-and-control-software is een van de meest ingrijpende aanbestedingsbeslissingen die een defensieorganisatie neemt. De verkeerde keuze — een platform dat faalt bij verslechterde communicatie, uw sensorfeeds niet kan integreren of u vastzet in een propriëtair ecosysteem — heeft operationele gevolgen die een decennium aanhouden. Anders dan bij commerciële bedrijfssoftware wordt de prijs van een slechte C2-aanbesteding niet gemeten in verspild budget, maar in verminderd situationeel bewustzijn op het moment dat het er het meest toe doet.

Dit artikel biedt een gestructureerd evaluatiekader op basis van 12 criteria die aanbestedingsteams moeten beoordelen vóór de contractgunning. Voor elk criterium geeft het kader aan waar u op moet letten, welke rode vlaggen een leverancier diskwalificeren en hoe u het criterium kunt testen in een gecontroleerde demonstratie. Het kader is van toepassing op zowel maatwerkontwikkelingsprogramma's als commercieel-van-de-plank (COTS) C2-platformaankopen.

Criterium 1: Latentie bij real-time data-ingestie

Waar u op moet letten. Trackupdate-latentie — de tijd van het moment dat een positierapport het systeem binnenkomt tot het moment dat het bijgewerkte symbool verschijnt op het common operational picture — mag onder representatieve belasting niet meer dan 500 ms bedragen op het 95e percentiel. Voor snel bewegende luchtcontacten of tijdkritisch doelwitselectie zijn lagere drempelwaarden (≤200 ms) van toepassing. End-to-end-latentie moet worden gemeten bij operationele trackdichtheden, niet in een licht belaste demo-omgeving.

Rode vlaggen. Leveranciers die geen latentiemetingen kunnen verstrekken onder gespecificeerde belasting, of die alleen gemiddelde latentie opgeven zonder percentieldistributies, zijn ofwel ongetest of verhullen degradatie bij schaal. Gemiddelde latentie is als operationele maatstaf nagenoeg zinloos — een systeem dat gemiddeld 300 ms haalt maar piekt naar 8 seconden bij 2.000 tracks is operationeel onbetrouwbaar.

Demotest. Vereis dat de leverancier een geautomatiseerde lastgenerator laat draaien die positie-updates injecteert op uw opgegeven tracktelplafond (bijv. 3.000 gelijktijdige tracks met elk 0,1 Hz). Meet end-to-end-latentie met tijdstempelberichten van injectie tot kaartweergave. Vraag de p50-, p95- en p99-latentiewaarden op.

Criterium 2: Breedte van multi-bronintegratie

Waar u op moet letten. Operationele C2-systemen moeten tracks samenvoegen van heterogene bronnen: UAV-grondcontrolestations (via Cursor on Target of MAVLINK), SIGINT-feeds, OSINT-aggregators, logistieke beheersystemen en verouderde sensornetwerken. Beoordeel de breedte van native adapters en de inspanning die nodig is om een nieuwe bron toe te voegen. Een platform met twintig gecertificeerde integraties maar geen open SDK voor aangepaste connectoren is een langetermijn-integratieverplichting.

Rode vlaggen. Integratieroadmaps die connectoren opsommen als "gepland" of "op aanvraag beschikbaar" zijn niet hetzelfde als verzonden code. Vereis demonstratie tegen ten minste twee databronnen die u daadwerkelijk gebruikt. Gesloten, propriëtaire berichtformaten zonder gepubliceerde schemadocumentatie duiden op toekomstige leveranciersafhankelijkheid.

Demotest. Stel de leverancier een live of opgenomen datafeed beschikbaar van een van uw huidige sensoren in het oorspronkelijke formaat. Observeer of de integratie native verloopt of een door de leverancier gefactureerde professionele dienstverlening vereist.

Criterium 3: Offline- en degraded-mode-mogelijkheden

Waar u op moet letten. Veld-C2-systemen opereren in gecontesteerde elektromagnetische omgevingen waarbij connectiviteit met een centrale server intermitterend of afwezig is. Het systeem moet een bruikbaar operationeel beeld handhaven op basis van lokaal gecachede gegevens tijdens netwerkstoringen, de toestand automatisch synchroniseren wanneer de verbinding is hersteld, en uitgaande opdrachten in de wachtrij plaatsen zonder gegevensverlies. Beoordeel de maximaal ondersteunde offline-duur en de getrouwheid van toestandsreconciliatie na reconnectie.

Kernpunt: Offline-mogelijkheden zijn het criterium dat het meest consequent ondergewaardeerd wordt in aanbestedingsscorerubrics, omdat evaluaties plaatsvinden in goed verbonden kazernomgevingen. Veel platforms die hoog scoren in demo's falen bij de eerste veldoefening wanneer netwerktoegang wegvalt. Vereis een live degraded-communications-scenario bij elke C2-softwaredemonstratie.

Rode vlaggen. Systemen die een persistente serververbinding vereisen om de kaart te weergeven of opdrachten uit te voeren. Elke architectuur waarbij het operatordisplay puur een thin client is zonder lokale toestand is operationeel kwetsbaar in een gecontesteerde omgeving. Bevestig of de mobiele of dismounted client een onafhankelijke trackdatabase onderhoudt of alleen streamt van de server.

Demotest. Koppel tijdens de demonstratie het clientknooppunt fysiek los van de server. Observeer of het operatordisplay functioneel blijft, welke gegevens degraderen en of opdrachten die in de wachtrij zijn geplaatst tijdens de storing automatisch worden verstuurd bij herverbinding.

Criterium 4: NATO-interoperabiliteitsnormen (STANAGs)

Waar u op moet letten. Programma's die binnen of naast NATO opereren moeten voldoen aan relevante Standardization Agreements. Sleutel-STANAGs voor C2-interoperabiliteit zijn onder meer STANAG 5522 (tactische datalinkverbindingen), STANAG 4677 (NFFI vriendelijke strijdkrachtinformatie), STANAG 4559 (NSILI beeldbibliotheekinterface) en APP-6D (NATO militaire symbologie). Verifieer naleving met specifieke edities, niet alleen de naam van de norm — APP-6C en APP-6D hebben aanzienlijke symbolenreeksverschillen die de interoperabiliteit bij coalitie-oefeningen beïnvloeden.

Rode vlaggen. Leveranciers die STANAG-naleving claimen zonder een conformiteitstestrapport of CWIX-deelnamecijfers (Coalition Warrior Interoperability eXploration, eXperimentation, eXamination, eXercise) te verstrekken. Zelfverklaard nalevingsbeleid zonder validatie door derden is onvoldoende voor gebruik in coalitie-programma's.

Demotest. Vraag de meest recente CWIX-deelnemingssamenvatting van de leverancier of conformiteitstestresultaten op voor de specifieke STANAGs in uw vereisten. Verstrek voor symbolweergave een set APP-6D-testcases en verifieer correcte weergave aan de hand van de referentiesymbolenset.

Criterium 5: Verwerking van gegevensclassificatie

Waar u op moet letten. C2-systemen die gerubriceerde informatie verwerken moeten gegevenslabeling, toegangscontrole en beperkingen op cross-domain gegevensstromen afdwingen op objectniveau — niet alleen op de netwerkperimeter. Elk track, document en bericht moet classificatiemetadata bevatten die bepaalt wat elke gebruiker kan zien en exporteren. Evalueer het gedrag van het systeem wanneer een gebruiker op een lager classificatieniveau probeert een track te bekijken of te exporteren die op een hoger niveau is gemarkeerd.

Rode vlaggen. Classificatie die alleen bij inloggen wordt afgedwongen (alle geauthenticeerde gebruikers zien alle gegevens) is onvoldoende voor elke multi-classificatieniveau-operationele omgeving. Het ontbreken van auditlogs voor gegevenstoegang, export- en downgrade-gebeurtenissen is een nalevingsdiskwalificatie voor de meeste defensie-accreditatiekaders.

Demotest. Maak testaccounts op twee verschillende classificatieniveaus. Verifieer dat het account met lagere classificatie geen objecten kan bekijken, exporteren of waarschuwingen kan ontvangen over objecten die boven hun niveau zijn gemarkeerd. Inspecteer het auditlog om te bevestigen dat de toegangspoging wordt vastgelegd.

Criterium 6: Granulariteit van rolgebaseerde toegangscontrole

Waar u op moet letten. Operationele C2 vereist fijnmazige toegangscontrole over functionele rollen: een inlichtingenofficier die SIGINT-tracks kan bekijken maar geen bewegingsopdrachten kan uitvaardigen, een verbindingsofficier van een geallieerde natie die gedeelde tracks kan bekijken maar geen toegang heeft tot de dispositie van binnenlandse strijdkrachten, een logistiekcoördinator die bevoorradingsoverlays ziet maar geen doelwitselectiegegevens. Evalueer of het RBAC-model op attributen gebaseerde beleidsregels ondersteunt die deze beperkingen kunnen uitdrukken, of dat het beperkt is tot grove roltoewijzingen.

Voor uitgebreidere technische informatie over RBAC-architecturen in defensieplatforms, zie het artikel over rolgebaseerde toegangscontrole in defensie-C2-systemen.

Rode vlaggen. Systemen met minder dan vijf vooraf gedefinieerde rollen en geen ondersteuning voor het aanmaken van aangepaste rollen. RBAC-modellen die de toegang niet op dataobjectniveau kunnen beperken (alleen op UI-functieniveau) creëren hiaten waarbij een gebruiker gevoelige gegevens kan benaderen via een API of exportfunctie die de UI-beperking omzeilt.

Demotest. Definieer een aangepaste rol — bijvoorbeeld een coalitie-partner met leestoegang tot blauw-krachttracks in alleen een specifiek geografisch gebied — en verifieer of het systeem deze beperking kan uitdrukken en afdwingen zonder professionele dienstverlening van de leverancier.

Criterium 7: Schaalbaarheid bij hoge trackdichtheid

Waar u op moet letten. Evalueer de prestatiekenmerken van het systeem over drie schaalbaarheidsafmetingen: trackdichtheid (gelijktijdige objecten op het C2-dashboard), gelijktijdige gebruikers (operators die het systeem tegelijkertijd gebruiken) en berichtdoorvoer (inkomende datasnelheid van alle gecombineerde bronnen). Vraag benchmarkresultaten van de leverancier op en reproduceer ze waar mogelijk onafhankelijk tijdens de evaluatie.

Kernpunt: Schaalbaarheidsclaims in marketingmateriaal van leveranciers worden bijna altijd gemeten onder ideale omstandigheden — één databron, geen verwerkingsoverhead voor classificatie, geen gelijktijdige gebruikers die complexe zoekopdrachten uitvoeren. De relevante vraag is niet "wat is het maximale trackaantal" maar "wat is de latentie bij uw operationeel trackaantalplafond met uw aantal gelijktijdige gebruikers en uw werkelijke sensormix."

Rode vlaggen. Leveranciers die geen prestatiegegevens kunnen verstrekken bij trackaantallen boven 1.000 of gelijktijdige gebruikersaantallen boven 20. Een architectuur die afhankelijk is van één databaseknooppunt zonder horizontaal schalingstraject is een capaciteitsplafond dat het programma zal beperken naarmate het groeit.

Demotest. Gebruik de lastgeneratietest uit Criterium 1, uitgebreid met meerdere gelijktijdige gebruikerssessies die elk actieve kaartinteracties uitvoeren (zoomen, filteren, opvragen). Meet of de per-gebruiker-latentie lineair of niet-lineair degradeert naarmate het aantal gelijktijdige gebruikers toeneemt.

Criterium 8: Beveiligingscertificeringen van de leverancier

Waar u op moet letten. Minimaal aanvaardbare beveiligingscertificeringen zijn afhankelijk van het accreditatiekader dat uw programma beheert. Veelgebruikte referentiepunten: ISO/IEC 27001 (informatiebeveiligingsbeheer), SOC 2 Type II (relevant voor cloud-gehoste oplossingen), Common Criteria EAL-certificering (voor systemen die formele beveiligingszekerheid vereisen) en programmaspecifieke accreditatie (bijv. DISA STIG-naleving, FedRAMP voor Amerikaanse federale programma's, NCSC-richtlijnen voor Britse programma's).

Rode vlaggen. Certificeringen die verlopen zijn, beperkt zijn in reikwijdte tot een subset van het product, of gebaseerd zijn op een versie die aanzienlijk ouder is dan de huidige release. Een leverancier met ISO 27001-certificering voor zijn bedrijfs-IT-omgeving maar niet voor de C2-productleveringspijplijn biedt beperkte zekerheid. Vraag de reikwijdteverklaring van de certificering op.

Demotest. Vraag het feitelijke certificaatdocument op met uitgiftedatum, reikwijdte en vervaldatum. Vraag voor STIG-naleving het STIG Viewer-resultatenbestand op, niet een samenvattingstabel. Neem contact op met de certificerende instantie om de geldigheid te verifiëren.

Criterium 9: Implementatieflexibiliteit

Waar u op moet letten. Evalueer of het platform alle implementatiemodellen ondersteunt die uw programma in zijn levenscyclus vereist: commerciële cloud (voor oefeningen en trainingsomgevingen), on-premises in een geharde datacenter, tactische rand (draaiend op geharde hardware in het veld) en volledig air-gapped (geen externe netwerkverbinding). Veel platforms zijn geoptimaliseerd voor één implementatiemodel en degraderen in andere — een cloud-native SaaS-platform heeft mogelijk geen haalbaar traject naar air-gapped werking.

Rode vlaggen. Afhankelijkheid van externe services (licentieservers, updateservers, telemetrie-eindpunten) die niet kunnen functioneren in een air-gapped omgeving. Licentiemodellen die periodieke cloud-check-in vereisen om actief te blijven, zullen stil falen bij niet-verbonden operaties. Bevestig of offline werking een speciale licentietier vereist.

Demotest. Verzoek specifiek om een demonstratie van de air-gapped implementatievariant als uw programma dit vereist. Veel leveranciers demonstreren de cloudversie en beweren air-gapped-mogelijkheid — test het feitelijke implementatiemodel, niet de mogelijkheidsbewering.

Criterium 10: UI/UX onder stressomstandigheden

Waar u op moet letten. Een C2-interface die wordt gebruikt door een operator onder tijdsdruk, met onvolledige informatie en in een lawaaierige omgeving heeft fundamenteel andere gebruiksvereisten dan bedrijfssoftware. Evalueer informatiedichtheid (kan de relevante gegevens worden gevonden zonder door menu's te navigeren), meldingsvermoeidheid (maakt het systeem onderscheid tussen kritieke meldingen en routinenotificaties) en voltooitijd voor operationele taken voor veelvoorkomende acties: een specifieke eenheid lokaliseren, een taakopdracht uitvaardigen en een track als vijandig markeren.

Rode vlaggen. Interfaces die meer dan twee klikken vereisen om een tijdkritieke actie uit te voeren (de affiliatie van een track wijzigen, een contactrapport sturen). Systemen met ongedifferentieerde meldingsstromen die prioriteitsarme systeemgebeurtenissen naast kritieke operationele notificaties presenteren, worden door operators genegeerd en missen kritieke gebeurtenissen.

Demotest. Stel een evaluator voor die het platform nog nooit heeft gezien en vraag hem drie gedefinieerde taken te voltooien zonder assistentie van de leverancier. Meet de taakvoltooidtijd en foutrate. Deze gestructureerde bruikbaarheidstest onthult workflowwrijving die een door de leverancier geleide demo verbergt.

Criterium 11: Ondersteuning en SLA-voorwaarden

Waar u op moet letten. Operationele C2-software vereist ondersteuningsvoorwaarden die zijn afgestemd op operationele beschikbaarheidsvereisten — niet op commerciële SaaS-SLA's. Evalueer: beschikbaarheidsgarantie (99,9% uptime staat toch nog 8,7 uur jaarlijkse downtime toe), incidentresponstijd voor kritieke defecten (uren, niet werkdagen), patchlevertijdlijn voor beveiligingskwetsbaarheden en het vermogen van de leverancier om gerubriceerde implementaties te ondersteunen onder beperkte toegangsomstandigheden.

Kernpunt: Ondersteunings-SLA's worden onderhandeld vóór de contractgunning maar worden cruciaal erna. De standaard-SLA in de commerciële productovereenkomst van een leverancier is bijna nooit adequaat voor operationeel defensiegebruik. Vereis SLA-voorwaarden die responstijden in uren specificeren voor severity-1-incidenten, patchlevertijdvensters voor CVE's en een benoemde ondersteuningscontact met de juiste veiligheidsmachtiging voor gerubriceerde programmaondersteuning.

Rode vlaggen. Ondersteuningsniveaus die snellere respons bieden alleen tegen aanzienlijk hogere kosten, waardoor ondersteuning van operationele kwaliteit feitelijk een premiumbijlage wordt. Leveranciers die geen eerdere ervaring kunnen aantonen met het ondersteunen van gerubriceerde implementaties met gescreende medewerkers zijn een risico voor programma's met classificatievereisten.

Demotest. Vraag geredigeerde voorbeelden op van eerdere incidentresponsregistraties voor severity-1-problemen. Neem specifiek contact op met referentieklanten om te vragen naar de responsiviteit van de ondersteuning tijdens werkelijke incidenten, niet over algemene tevredenheid.

Criterium 12: Totale eigendomskosten

Waar u op moet letten. C2-software-TCO over een vijfjarig programmatraject omvat: initiële verwervings- of ontwikkelkosten, jaarlijkse licentie- of onderhoudskosten, infrastructuurkosten (cloudabonnementen of on-premises hardware), integratiekosten (verbinding met bestaande sensor- en logistieke systemen), trainingskosten voor operators en beheerders, en geschatte upgradekosten. Open-architectuurplatforms met gepubliceerde API's en overdraagbare gegevensformaten hebben aanzienlijk lagere langetermijn-integratie- en migratiekosten dan propriëtaire systemen.

Rode vlaggen. Prijsstructuren die per seat rekenen voor elke gelijktijdige gebruiker, wat leidt tot escalerende kosten naarmate het programma groeit. Propriëtaire gegevensformaten zonder exportmogelijkheid creëren overstapkosten die het programma feitelijk vastzetten bij contractverlenging. "Basisprijs"-offertes die verplichte ondersteuningsniveaus, infrastructuur of integratiemodules uitsluiten, onderschatten de TCO doorgaans met 40–60%.

Demotest. Vraag van elke leverancier een gedetailleerd vijfjaars-TCO-model op aan de hand van uw opgegeven programmagegevens (gebruikersaantal, trackaantalplafond, implementatieomgeving). Vereis dat het model alle kostencomponenten itemiseert, inclusief infrastructuur, ondersteuning en integratie. Vergelijk de totale levenscycluskosten, niet de aanschafprijs.

Hoe voer je een C2-software-evaluatie uit in 6 weken

Een gestructureerde 6-weekenevaluatie comprimeert de technische beoordeling tot een verdedigbaar, documenteerbaar proces zonder aan nauwkeurigheid in te boeten.

Week 1: Eisen en rubric. Vertaal operationele eisen naar kwantitatieve drempelwaarden voor elk van de 12 criteria. Ken gewichten toe. Publiceer het rubric naar de evaluatiecommissie vóór enig leverancierscontact. Pas gewichten niet aan nadat demo's zijn begonnen.

Week 1–2: RFI en screening. Stuur een gestructureerd verzoek om informatie dat verplichte reacties vereist gekoppeld aan uw 12 criteria. Filter reacties op een minimale drempel — leveranciers die uw latentie-, certificerings- of implementatievereisten schriftelijk niet kunnen halen, gaan niet door naar de demo.

Week 2: Ontwerp van demoscenario's. Schrijf drie tot vier gescripte scenario's die uw hoogste-risico criteria dekken: een degraded-network-scenario, een scenario met hoge trackdichtheid, een classificatiegrenstest en een multi-bronintegratietest. Geef scenarioscripts van tevoren aan leveranciers. U evalueert de software, niet het vermogen van de leverancier om rond zijn zwakke punten te improviseren.

Week 3–4: Gestructureerde demonstraties. Leid elke leverancier door identieke scenario's met dezelfde evaluatoren aanwezig. Score criteria onmiddellijk na elke demo. Neem sessies op voor afwezige commissieleden. Dwing een gestructureerd Q&A-formaat af — ongescripte open-ended demo's stellen leveranciers in staat zwakke punten te omzeilen.

Week 4–5: Documentatie- en referentieverificatie. Valideer geclaimde certificeringen bij uitgevende instanties. Neem onafhankelijk contact op met referentieklanten. Vraag feitelijke SLA-documenten op, geen marketingsamenvattingen. Vraag STIG-resultatenbestanden op, geen nalevingstabellen.

Week 5–6: Scoring en source-selection-documentatie. Aggregeer evaluatorscores. Koppel elke score aan specifieke observaties of documentatiebewijs. Stel een source-selection-beslisdocument op. Dit dossier is essentieel voor het bezwaardicht maken van de gunning en voor de basislijn van post-gunningsprogrammabeheer.

Hoe Corvus.Head aan deze criteria voldoet

Corvus.Head is een ISR command-and-control-dashboard dat specifiek is gebouwd voor de operationele criteria die in dit kader worden beschreven. Het verwerkt multi-bronfeeds — UAV-telemetrie, SIGINT-overlays, OSINT-lagen en logistieke gegevens — via een open adapterarchitectuur die de ontwikkeling van aangepaste connectoren ondersteunt zonder betrokkenheid van de leverancier. Trackupdate-latentie is gemeten op sub-300 ms op het 95e percentiel onder trackbelastingen op brigadeomvang. Het platform ondersteunt air-gapped, on-premises en cloud-implementatie vanuit dezelfde codebase, met offline werking en automatische toestandsreconciliatie bij herverbinding. Rolgebaseerde toegangscontrole ondersteunt op attributen gebaseerde beleidsregels tot op het niveau van individuele trackobjecten.

Voor aanbestedingsteams die een gestructureerde evaluatie uitvoeren, kan Corvus Intelligence benchmarkdatapakketten, referentiearchitectuurdocumentatie en gestructureerde demosessies verstrekken die zijn gescript op uw evaluatiecriteria in plaats van een standaard marketingpresentatie.

Veelgestelde vragen

+Hoe schrijf je een C2-software-RFP?

Een C2-RFP moet kwantitatieve prestatiedrempels specificeren (latentiemaxima, minimale trackdichtheid), vereiste STANAG- of MIL-STD-nalevingsnormen, beveiligingsaccreditatieniveau, beperkingen voor de implementatieomgeving (cloud, on-prem, air-gapped) en verplichte scenariodemonstaties. Voeg een gescoord evaluatierubric bij zodat leveranciers begrijpen welke criteria het zwaarst wegen. Vermijd vage vereisten zoals "real-time" — vervang ze door specifieke getallen (bijv. trackupdate-latentie ≤500 ms op het 95e percentiel).

+Wat is de typische aanbestedingstijdlijn voor militaire C2-software?

End-to-end aanbesteding van C2-software duurt doorgaans 12–24 maanden van het definiëren van eisen tot de gunning voor programma's die formele aanbestedingsregels volgen. Een gestroomlijnde technische evaluatiefase van 6 weken (RFI → demo → scoring → shortlist) kan worden ingebed in een breder programma. Urgente operationele behoefte (UON) of other-transaction authority (OTA)-trajecten kunnen de totale tijdlijn aanzienlijk verkorten, maar vereisen toch een gestructureerde technische evaluatie om het inzetrisico te beperken.

+Wat is het meest over het hoofd geziene C2-evaluatiecriterium?

Offline- en degraded-mode-mogelijkheden worden consequent ondergewaardeerd in evaluatierubrics omdat demonstraties altijd plaatsvinden in goed verbonden omgevingen. Veel systemen die goed presteren in de kazerne falen in het veld wanneer de netwerkverbinding wegvalt. Vereis van leveranciers dat zij een gesimuleerd communicatie-ontkend scenario demonstreren tijdens de evaluatie.

+Hoe moet de totale eigendomskosten worden berekend voor C2-software?

TCO voor C2-software moet omvatten: initiële licentie- of ontwikkelkosten, jaarlijkse onderhouds- en ondersteuningskosten, infrastructuurkosten (servers, cloudabonnementen, hardware voor air-gapped implementaties), integratiekosten (verbinding met bestaande sensorfeeds en verouderde systemen), trainingskosten voor operators en beheerders, en geschatte upgradekosten over de programmalevencyclus. Een systeem met een lagere aanschafprijs maar hoge jaarlijkse licentiekosten en verplichte door de leverancier beheerde infrastructuur heeft vaak een hogere 5-jaars-TCO dan een open-architectuuralternatief.

+Hoe kunnen aanbestedingsteams de C2-software-UI onder stressomstandigheden evalueren?

Verzoek om een gestructureerde scenariodemonstratie waarbij operators die niet bekend zijn met het systeem gedefinieerde taken moeten voltooien — een bevriende eenheid lokaliseren, een taakopdracht uitvaardigen, een track als vijandig identificeren — binnen een tijdslimiet. Observeer waar operators aarzelen, fouten maken of aanwijzingen van de leverancier nodig hebben. Dit is diagnostischer dan een gepolijste door de leverancier geleide demo. Aanvullende oogbewegings- of taaktiijdstudies worden gebruikt bij formele human-factors-evaluaties voor grotere programma's.

Gerelateerde lectuur: Voor een uitgebreidere technische uiteenzetting van wat de prestaties van C2-systemen bepaalt, zie de artikelen over C2-dashboardarchitectuur, testen en verificatie van C2-systemen en rolgebaseerde toegangscontrole in defensie-C2-systemen. Voor achtergrondinformatie over normen behandelt het artikel over de complete gids voor C2-systemen de operationele en architecturale context die ten grondslag ligt aan deze evaluatiecriteria.