💻 computer science

JTA: Joint Testability Architecture for Scenario-Based Validation of Safety-Critical Software

Dit artikel introduceert de Joint Testability Architecture (JTA), een nieuw framework dat het scenario, het testsysteem en het te testen systeem verenigt in één enkel ontwerpobject dat wordt gekenmerkt door controleerbaarheid, observeerbaarheid en isoleerbaarheid om de validatieadequaatheid van veiligheidskritische software te verbeteren door middel van scenario-contracten, capaciteitsbeoordeling en brug-georiënteerde ontwerpacties.

Oorspronkelijke auteurs: Wenyao Xue, Jiandi Wang, Yichen Wang

Gepubliceerd 2026-08-07

📖 7 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Wenyao Xue, Jiandi Wang, Yichen Wang

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je probeert te bewijzen dat een zelfrijdende auto veilig genoeg is om de weg op te gaan. Je kunt niet gewoon een lijst met "wat als"-vragen schrijven en hopen dat de auto ze correct beantwoordt. Je hebt een heel team nodig dat samenwerkt: de auto zelf (de software), de testers (de mensen en computers die de tests uitvoeren) en de scenario's (de specifieke, lastige situaties die je wilt testen, zoals een plotselinge regenbui of een voetganger die plotseling de weg op springt).

In de wereld van veiligheidskritische software — zoals de hersenen achter vliegtuigen, treinen en autonome voertuigen — raakt dit team vaak uit de pas. De auto is misschien klaar, maar de testers kunnen niet precies de benodigde regenbui creëren. Of de testers kunnen de storm wel creëren, maar de auto "spreekt niet" duidelijk genoeg naar hen toe om te vertellen waarom hij stopte. Dit artikel, geschreven door onderzoekers van de Beihang Universiteit, pakt een grote vraag aan: Hoe zorgen we ervoor dat de auto, de testers en de testscenario's allemaal op één lijn zitten? Ze introduceren een nieuwe manier van denken die Joint Testability Architecture (JTA) wordt genoemd. In plaats van alleen naar de softwarecode in isolatie te kijken, behandelt JTA het hele trio als één enkel, verbonden systeem. Het stelt bij elke test drie eenvoudige maar krachtige vragen: Kunnen we de situatie controleren? Kunnen we zien wat er gebeurt? En als er iets misgaat, kunnen we dan precies aanwijzen wie of wat daarvoor verantwoordelijk is?

Het Probleem: Een Gebroken Keten van Vertrouwen

Denk aan het testen van veiligheidskritische software als het proberen op te lossen van een mysterie in een donkere kamer. Je hebt een detective (het Test Systeem), een verdachte (het Systeem Onder Test, oftewel de software) en een specifieke plaats delict die je moet recreëren (het Scenario).

In het verleden richtten onderzoekers zich voornamelijk op de verdachte. Ze vroegen: "Is de code zo geschreven dat het makkelijk te testen is?" Maar de auteurs van dit artikel stellen dat dit is alsof je vraagt of een verdachte gemakkelijk te ondervragen is, zonder te controleren of de detective een zaklamp heeft of of de plaats delict überhaupt correct is opgezet. Als de detective het licht niet aan kan doen (Observability/Waarneembaarheid), of als de plaats delict te chaotisch is om te recreëren (Controllability/Controleerbaarheid), dan helpt de beste code ter wereld niet.

Het artikel suggereert dat "testbaarheid" niet alleen een eigenschap is van de code; het is een eigenschap van de relatie tussen de code, de instrumenten en het scenario. Als een van deze drie schakels zwak is, faalt het hele validatieproces.

De Oplossing: De "Drie Bruggen"

Om dit op te lossen, stellen de auteurs een blauwdruk voor genaamd Joint Testability Architecture (JTA). Stel je het Scenario, het Test Systeem en de Software voor als drie eilanden. Om ze samen te laten werken, heb je drie bruggen nodig die hen verbinden.

De Controlebrug: Deze verbindt het Test Systeem met de Software. Het vraagt: "Kunnen we de software daadwerkelijk in deze specifieke situatie dwingen?" Als je wilt testen wat er gebeurt als een drone zijn afstandsbedieningssignaal verliest, kan het testsysteem dat signaal dan betrouwbaar op exact het juiste moment verbreken? Als de brug gebroken is, kun je de test niet eens starten.
De Bewijsbrug: Deze verbindt de Software terug met het Test Systeem. Het vraagt: "Kunnen we zien wat er gebeurt?" Wanneer de drone het signaal verliest, roept hij dan om hulp op een manier die het test systeem kan begrijpen? Laat hij een duidelijk spoor van logs achter, of slechts een verwarrende bende aan gegevens?
De Toeschrijvingsbrug: Dit is de meest cruciale. Het vraagt: "Als er iets misgaat, weten we dan waarom?" Als de drone crasht, kwam dat omdat het signaal werd onderbroken (een echt probleem), of omdat het testsysteem per ongeluk het signaal te vroeg verbrak (een vals probleem)? Deze brug zorgt ervoor dat we een echt falen kunnen onderscheiden van een testfout.

Het Geheime Wapen: Het "Scenario Contract"

Het artikel introduceert een slim instrument genaamd het Scenario Contract. Beschouw dit als een strikte checklist of een regelboek voor elke individuele test. Voordat je zelfs maar een test uitvoert, schrijf je precies op wat je nodig hebt:

Wat testen we? (Het doel)
Hoe triggeren we het? (De controle)
Welk bewijs moeten we zien? (Het bewijs)
Wie is verantwoordelijk als het misgaat? (De toeschrijving)

Door eerst dit contract in te vullen, kun je "blinde vlekken" opsporen voordat je tijd verspilt aan het draaien van tests. Als het contract zegt dat je onderscheid moet maken tussen twee soorten fouten, maar je software heeft geen manier om ze uit elkaar te houden, dan onthult het contract de tekortkoming onmiddellijk.

De Casestudy: De ArduPilot Drone

Om te zien of dit idee werkt, hebben de auteurs het getest op ArduPilot, een populair open-source vluchtcontrolesysteem dat wordt gebruikt voor drones en robots. Ze keken naar drie specifieke "ramp-scenario's":

Verlies van Afstandsbediening: De drone verliest de verbinding met de piloot.
Verlies van Grondstation: De drone verliest de verbinding met de computer op de grond.
Verward Brein: De interne sensoren van de drone (die raden waar hij zich bevindt) beginnen foutieve gegevens door te geven.

Wat ze ontdekten:

Het Goede Nieuws: Het scenario "Verlies van Afstandsbediening" deed het eigenlijk best goed. Het testsysteem kon het signaal gemakkelijk verbreken en de drone had duidelijke logs om aan te tonen dat dit gebeurde. De "Controle"- en "Bewijs"-bruggen waren sterk.
Het Slechte Nieuws: Het scenario "Verward Brein" was een puinhoop. Het testsysteem worstelde met het creëren van een realistische "verward brein"-situatie (zwakke Controle-brug), en zelfs wanneer het dat wel deed, waren de logs van de drone te vaag om te kunnen onderscheiden of de verwarring voortkwam uit een sensorfout of een GPS-glitch (zwakke Toeschrijvingsbrug).

De auteurs berekenden een "veiligheidsscore" voor het hele systeem. Omdat het scenario "Verward Brein" zo gevaarlijk is (hoge kritikaliteit), trok het falen ervan de score van het hele systeem omlaag naar slechts 28,6%. Dit betekent dat hoewel de drone goed is in het afhandelen van simpel signaalverlies, het momenteel erg moeilijk is om te bewijzen dat hij veilig is tegen complexe sensorfouten.

De Conclusie

Het artikel beweert niet dat het de veiligheid van drones heeft "opgelost" of de ArduPilot-code heeft gerepareerd. In plaats daarvan biedt het een nieuwe manier om het probleem te diagnosticeren. Het suggereert dat de moeilijkheid niet alleen is dat de code moeilijk te schrijven is; het is dat het gehele systeem van testen niet op elkaar is afgestemd.

Door gebruik te maken van de "Drie Bruggen" en het "Scenario Contract", kunnen ingenieurs stoppen met gissen waarom een test is mislukt. Ze kunnen naar hun checklist kijken en zeggen: "Ah, we hebben een gat in de Toeschrijvingsbrug. We moeten een specifieke code-label toevoegen om het verschil tussen een sensorfout en een GPS-fout aan te geven."

Kortom, JTA verandelt het vage gevoel van "dit is moeilijk te testen" in een specifieke, actiegerichte takenlijst. Het verplaatst de discussie van "Is de code goed?" naar "Is ons volledige testteam in staat om te bewijzen dat de code veilig is?". Voor iedereen die software bouwt die mensenlevens beschermt, is dat een zeer belangrijke verschuiving.

Technisch Overzicht: Joint Testability Architecture (JTA) voor Veiligheidskritische Software

1. Probleemstelling

De validatie-adequaatheid in veiligheidskritische softwaresystemen (bijv. vluchtbesturing, autonoom rijden) wordt vaak gehinderd, niet door een gebrek aan testgevallen, maar door het onvermogen om kritieke scenario's stabiel te construeren, executiebewijs te organiseren in verdict-klare vormen, of abnormale uitkomsten toe te schrijven aan actiegerichte engineering-grenzen. Traditioneel onderzoek naar testbaarheid richt zich primair op het software-artefact zelf, waarbij testbaarheid wordt beschouwd als een statische eigenschap van de code (controleerbaarheid en observeerbaarheid). Deze artefact-gecentreerde visie is echter onvoldoende voor veiligheidskritische scenario's die betrekking hebben op failsafe-activatie, modus-migratie of coördinatie tussen meerdere componenten. Het adresseert niet of de gecombineerde capaciteit van het scenario, het testsysteem en het te testen systeem (System Under Test, SUT) voldoende is om adequate validatie te ondersteunen. Bijgevolg garandeert "code die testbaar is" niet dat "scenario-gebaseerde validatie adequaat is."

2. Methodologie: De Joint Testability Architecture (JTA)

JTA herformuleert testbaarheid als een scenario-geconditioneerde capaciteit van een gezamenlijk systeem. Het stelt een formele architectuur en een vijfstaps analyse-workflow voor om hiaten in capaciteiten te identificeren en te overbruggen.

2.1 Formeel Model

De architectuur wordt gedefinieerd als $JTA = \langle D_\Sigma, D_T, D_S, BC, BO, BI, L \rangle$ , bestaande uit:

Drie Domeinen:
- Scenario-domein ( $D_\Sigma$ ): Organiseert validatie-objectieven, restricties en kritikaliteit.
- Test-systeem-domein ( $D_T$ ): Omvat stimulatie, bewijsvoering en de capaciteit voor verdict-generatie.
- Systeem-onder-test-domein ( $D_S$ ): Bevat het functionele gedrag en de blootgestelde validatie-hooks (controlepunten, bewijspunten, verantwoordelijkheidsgrenzen).
Drie Bruggen: Architecturale patronen die de domeinen verbinden om capaciteitsmismatches op te lossen:
- Control Bridge ($BC$): Vertaalt scenario-precondities naar reproduceerbare parameterinstellingen en foutinjecties.
- Evidence Bridge ($BO$): Organiseert ruwe logs en staten in gestructureerd, temporeel uitgelijnd bewijs voor geautomatiseerde verdicts.
- Attribution Bridge ($BI$): Koppelt abnormale uitkomsten aan specifieke triggerbronnen en verantwoordelijkheidsgrenzen om remediëring mogelijk te maken.
Closed Loop ( $L$ ): Een iteratief proces van analyse, ontwerp, evaluatie en verfijning.

2.2 Kernconcepten

Joint Testability System ( $JTS_\sigma$ ): De eenheid van analyse is niet de software alleen, maar het triplet $\langle \sigma, T_\sigma, S_\sigma \rangle$ dat een specifiek scenario, de participerende testcapaciteiten en de relevante SUT-grens vertegenwoordigt.
Scenario Contracts ( $SC(\sigma)$ ): Een achttallige specificatie $\langle g, p, u, e, o, r, \kappa, \Theta \rangle$ die expliciet de validatie-objectieven, precondities, stimulatiemodus, minimaal bewijs, verdict-regels, een set van onderscheidbare foutbronnen ( $r$ ), kritikaliteit en minimale drempelwaarden voor controleerbaarheid, observeerbaarheid en isolatie definieert.
Joint Capability Assessment:
- Controleerbaarheid ( $C$ ), Observeerbaarheid ( $O$ ) en Isolatie ( $I$ ): Gemeten voor zowel de SUT ($CS, OS, IS$) als het Test-systeem ($CT, OT, IT$).
- Joint Capability ($JTCap$): Gedefinieerd als het minimum van de SUT- en Test-systeem-capaciteiten voor elke dimensie (bijv. $JC = \min(CS, CT)$ ), wat het "zwakste schakel"-principe weerspiegelt.
- Adequaatheid ($Adeq$): Een scenario is alleen adequaat als alle drie de gezamenlijke dimensies voldoen aan de minimale drempelwaarden gedefinieerd in het contract.
- Blind Spots: Scenario's waar $Adeq(\sigma) = 0$ .

2.3 Vijfstaps Workflow

Identificeer Kritieke Scenario's: Bepaal de verzameling $\Sigma$ en wijs kritikaliteitsgewichten toe.
Instantiëer Scenario Contracts: Definieer expliciet de objectieven, bewijseisen en de set van foutbronnen die onderscheiden moeten worden.
Beoordeel Bilaterale Capaciteiten: Evalueer $Cap_S$ en $Cap_T$ tegen de contractvereisten.
Bereken Gaten en Identificeer Blind Spots: Bereken de capaciteitsgat-vector $Gap(\sigma)$ en identificeer scenario's die falen op adequaatheid.
Bridge Design en Re-evaluatie: Koppel gaten aan specifieke ontwerpacties op de Control, Evidence of Attribution bruggen, en evalueer opnieuw.

3. Belangrijkste Bijdragen

Joint Testability System Model ( $JTS_\sigma$ ): Breidt het object van validatie uit van een geïsoleerd artefact naar een scenario-geïnstantieerd gezamenlijk entiteit bestaande uit het scenario, het testsysteem en de SUT.
Scenario Contracts met Foutbron-sets: Introduceert een formeel contract dat een set onderscheidbare foutbronnen ( $r$ ) bevat, waardoor isolatie wordt getransformeerd van een generiek concept naar een concrete ontwerpbeperking voor attributie.
Bridge-georiënteerde Ontwerpmethode: Stelt een "drie domeinen, drie bruggen en een closed loop" raamwerk voor dat capaciteitsgaten direct koppelt aan uitvoerbare architecturale ontwerpacties (bijv. het toevoegen van een timing controller aan de Control Bridge of cause-code extensies aan de Attribution Bridge).
Illustratieve Analyse van ArduPilot: Demonstreert de toepassing van JTA op de ArduPilot failsafe-validatie, waarbij specifieke blind spots worden geïdentificeerd in link-loss en state-estimation anomalie scenario's.

4. Resultaten: ArduPilot Case Study

De auteurs pasten JTA toe op drie failsafe-scenario's in het open-source ArduPilot-project: RC link loss (S1), GCS heartbeat timeout (S2) en EKF state-estimation anomalies (S3).

S1 (RC Link Loss): Beoordeeld als Adequaat (1). Het test-systeem en de SUT ondersteunen het scenario gezamenlijk, hoewel er enkele bottlenecks bestaan in de structurering van bewijs.
S2 (GCS Heartbeat Timeout): Beoordeeld als Inadequaat (0). Hoewel het scenario kan worden getriggerd, is de Attribution Bridge zwak; de huidige logs kunnen geen onderscheid maken tussen echte timeouts en fouten in de test-toolchain.
S3 (EKF Anomalies): Beoordeeld als Inadequaat (0). Dit scenario onthult bottlenecks in zowel Controleerbaarheid (moeilijkheid in het ontkoppelen van perturbatiekracht en timing) als Isolatie (ambiguïteit in het onderscheiden tussen EKF-gezondheidsfouten en gelijktijdige GPS-degradatie).

Systeem-niveau Metriek: De kritikaliteit-gewogen adequaatheidsdekking ($JT(JTS)$) voor de geanalyseerde scenario's werd berekend op 28,6%, wat benadrukt dat hoog-kritieke scenario's (zoals EKF-anomalieën) significante validatie-blind spots blijven ondanks een volwassen infrastructuur voor eenvoudigere scenario's.

Ontwerpaanbevelingen: De analyse leverde specifieke brug-niveau acties op, zoals:

Het toevoegen van een "triadic attribution view" (timeout event–cause code–link status) voor S2.
Het implementeren van geparametriseerde perturbatie-templates en injectie-geactiveerde replay-adapters voor S3 om de controleerbaarheid te verbeteren.

5. Betekenis en Claims

Het artikel claimt dat JTA een architecturale basis biedt voor het modelleren, ontwerpen en beoordelen van scenario-gebaseerde validatie, in plaats van het vervangen van bestaande test- of veiligheidsanalysetechnieken.

Verschuiving in Perspectief: Het verlegt de focus van "is de code testbaar?" naar "is het gezamenlijke systeem in staat om dit specifieke scenario te valideren?"
Actiegerichte Output: Het vertaalt vage engineering-indrukken van "moeilijk te testen" naar dimensie-traceerbare, object-lokaliseerbare en actie-uitvoerbare ontwerp-gaten.
Proactieve Validatie: Het pleit voor het behandelen van validatie-capaciteit als een architecturale kwaliteitsattribuut die gelijktijdig met de functionele capaciteit ontworpen moet worden, in plaats van pas na de implementatie gecontroleerd te worden.
Complementariteit: JTA vult bestaande methoden zoals STPA (die scenario's identificeert) en fault injection (die abnormaliteiten construeert) aan door de ontbrekende schakel te bieden voor het beoordelen van gezamenlijke adequaatheid en attributie-convergentie.

De auteurs blijven bescheiden over hun claims en merken op dat de case study illustratief is en steunt op ordinale (H/M/L) beoordelingen in plaats van kwantitatieve prestatie-metrieken, en dat de toepasbaarheid op gesloten industriële systemen met beperkte interfaces verdere validatie vereist.