💻 computer science

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

Dieses Paper stellt die Joint Testability Architecture (JTA) vor, ein neuartiges Framework, das das Szenario, das Testsystem und das zu testende System in einem einzigen Designobjekt vereint, welches durch Kontrollierbarkeit, Beobachtbarkeit und Isolierbarkeit charakterisiert ist, um die Validierungsangemessenheit sicherheitskritischer Software durch Szenario-Kontrakte, Fähigkeitsbewertungen und brückenorientierte Design-Aktionen zu verbessern.

Ursprüngliche Autoren: Wenyao Xue, Jiandi Wang, Yichen Wang

Veröffentlicht 2026-08-07

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Wenyao Xue, Jiandi Wang, Yichen Wang

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen zu beweisen, dass ein selbstfahrendes Auto sicher genug ist, um auf die Straße zu gehen. Sie können nicht einfach eine Liste von „Was-wäre-wenn“-Fragen schreiben und hoffen, dass das Auto sie korrekt beantwortet. Sie brauchen ein ganzes Team, das zusammenarbeitet: das Auto selbst (die Software), die Tester (die Menschen und Computer, die die Tests durchführen) und die Szenarien (die spezifischen, kniffligen Situationen, die Sie testen wollen, wie etwa ein plötzlicher Regenschauer oder ein Fußgänger, der plötzlich auf die Straße springt).

In der Welt der sicherheitskritischen Software – wie dem Gehirn hinter Flugzeugen, Zügen und autonomen Fahrzeugen – gerät dieses Team oft aus dem Takt. Das Auto ist vielleicht bereit, aber die Tester können nicht genau den benötigten Regenschauer erzeugen. Oder die Tester können den Sturm zwar erzeugen, aber das Auto „spricht“ nicht deutlich genug, um ihnen zu sagen, warum es gestoppt hat. Dieses Paper, geschrieben von Forschern der Beihang University, widmet sich einer großen Frage: Wie stellen wir sicher, dass das Auto, die Tester und die Test-Szenarien alle auf derselben Wellenlänge sind? Sie führen einen neuen Denkansatz ein, die Joint Testability Architecture (JTA). Anstatt die Software-Code isoliert zu betrachten, behandelt JTA das gesamte Trio als ein einziges, verbundenes System. Es stellt für jeden Test drei einfache, aber kraftvolle Fragen: Können wir die Situation kontrollieren? Können wir sehen, was passiert? Und wenn etwas schiefgeht, können wir genau bestimmen, wer oder was dafür verantwortlich ist?

Das Problem: Eine unterbrochene Vertrauenskette

Stellen Sie sich das Testen von sicherheitskritischer Software wie den Versuch vor, ein Rätsel in einem dunklen Raum zu lösen. Sie haben einen Detektiv (das Testsystem), einen Verdächtigen (das System Under Test, also die Software) und einen spezifischen Tatort, den Sie nachstellen müssen (das Szenario).

In der Vergangenheit konzentrierten sich Forscher hauptsächlich auf den Verdächtigen. Sie fragten: „Ist der Code so geschrieben, dass er leicht zu testen ist?“ Doch die Autoren dieses Papers argumentieren, dass dies so ist, als würde man fragen, ob ein Verdächtiger leicht zu verhören ist, ohne zu prüfen, ob der Detektiv eine Taschenlampe hat oder ob der Tatort überhaupt korrekt aufgebaut ist. Wenn der Detektiv das Licht nicht einschalten kann (Observability / Beobachtbarkeit) oder wenn der Tatort zu chaotisch ist, um ihn nachzustellen (Controllability / Steuerbarkeit), wird das beste Code der Welt nichts helfen.

Das Paper legt nahe, dass „Testbarkeit“ nicht nur eine Eigenschaft des Codes ist, sondern eine Eigenschaft der Beziehung zwischen dem Code, den Werkzeugen und dem Szenario. Wenn einer dieser drei Links schwach ist, versagt der gesamte Validierungsprozess.

Die Lösung: Die „Drei Brücken“

Um dies zu beheben, schlagen die Autoren einen Bauplan namens Joint Testability Architecture (JTA) vor. Stellen Sie sich das Szenario, das Testsystem und die Software als drei Inseln vor. Um sie zusammenarbeiten zu lassen, benötigen Sie drei Brücken, die sie verbinden.

Die Kontroll-Brücke (The Control Bridge): Diese verbindet das Testsystem mit der Software. Sie fragt: „Können wir die Software tatsächlich in diese spezifische Situation zwingen?“ Wenn Sie testen wollen, was passiert, wenn eine Drohne die Verbindung zur Fernsteuerung verliert, kann das Testsystem dieses Signal zum exakt richtigen Zeitpunkt zuverlässig unterbrechen? Wenn die Brücke unterbrochen ist, können Sie den Test gar nicht erst beginnen.
Die Evidenz-Brücke (The Evidence Bridge): Diese verbindet die Software zurück mit dem Testsystem. Sie fragt: „Können wir sehen, was passiert?“ Wenn die Drohne das Signal verliert, schreit sie um Hilfe in einer Weise, die das Testsystem verstehen kann? Hinterlässt sie ein klares Protokoll (Logs) oder nur ein verwirrendes Chaos an Daten?
Die Attributions-Brücke (The Attribution Bridge): Dies ist die entscheidende Brücke. Sie fragt: „Wenn etwas schiefgeht, wissen wir dann, warum?“ Wenn die Drohne abstürzt, lag es daran, dass das Signal unterbrochen wurde (ein echtes Problem), oder weil das Testsystem das Signal versehentlich zu früh unterbrochen hat (ein falsches Problem)? Diese Brücke stellt sicher, dass wir zwischen einem echten Fehler und einem Testfehler unterscheiden können.

Die Geheimwaffe: Der „Szenario-Vertrag“

Das Paper führt ein kluges Werkzeug ein, den Scenario Contract (Szenario-Vertrag). Betrachten Sie dies als eine strikte Checkliste oder ein Regelwerk für jeden einzelnen Test. Bevor Sie überhaupt einen Test durchführen, halten Sie genau fest, was Sie benötigen:

Was testen wir? (Das Ziel)
Wie lösen wir es aus? (Die Kontrolle)
Welchen Beweis müssen wir sehen? (Die Evidenz)
Wer ist verantwortlich, wenn es fehlschlägt? (Die Attribution)

Indem Sie diesen Vertrag zuerst ausfüllen, können Sie „blinde Flecken“ erkennen, bevor Sie Zeit mit dem Durchführen von Tests verschwenden. Wenn der Vertrag besagt, dass Sie zwischen zwei Arten von Fehlern unterscheiden müssen, Ihr Software aber keine Möglichkeit hat, sie voneinander zu unterscheiden, deckt der Vertrag diese Lücke sofort auf.

Die Fallstudie: Die ArduPilot-Drohne

Um zu sehen, ob diese Idee funktioniert, testeten die Autoren sie an ArduPilot, einem populären Open-Source-Flugsteuerungssystem, das bei Drohnen und Robotern eingesetzt wird. Sie untersuchten drei spezifische „Katastrophen“-Szenarien:

Verlust der Fernsteuerung: Die Drohne verliert die Verbindung zu ihrem Piloten.
Verlust der Bodenstation: Die Drohne verliert die Verbindung zum Computer am Boden.
Verwirrtes Gehirn: Die internen Sensoren der Drohne (die schätzen, wo sie sich befindet) liefern fehlerhafte Daten.

Was sie herausfanden:

Die gute Nachricht: Das Szenario „Verlust der Fernsteuerung“ lief eigentlich recht gut. Das Testsystem konnte das Signal problemlos unterbrechen, und die Drohne hinterließ klare Protokolle, die zeigten, dass dies geschehen war. Die „Kontroll“- und „Evidenz“-Brücken waren stark.
Die schlechte Nachricht: Das Szenario „Verwirrtes Gehirn“ war ein einziges Chaos. Das Testsystem hatte Schwierigkeiten, eine realistische „verwirrte Gehirn“-Situation zu erzeugen (schwache Kontroll-Brücke), und selbst wenn es dies tat, waren die Protokolle der Drohne zu vage, um zu sagen, ob die Verwirrung durch einen Sensorfehler oder einen GPS-Fehler verursacht wurde (schwache Attributions-Brücke).

Die Autoren berechneten einen „Sicherheitswert“ für das gesamte System. Da das Szenario „Verwirrtes Ge Brain“ so gefährlich ist (hohe Kritikalität), zog dessen Scheitern den gesamten Sicherheitswert auf nur 28,6 % herunter. Das bedeutet, dass die Drohne zwar gut darin ist, einfachen Signalverlust zu handhaben, es aber derzeit sehr schwierig ist, zu beweisen, dass sie gegen komplemxe Sensorfehler sicher ist.

Das Fazit

Das Paper behauptet nicht, die Drohnensicherheit „gelöst“ oder den ArduPilot-Code repariert zu haben. Stattdessen bietet es eine neue Art der Diagnose des Problems an. Es legt nahe, dass die Schwierigkeit nicht nur darin besteht, dass der Code schwer zu schreiben ist, sondern dass das gesamte System des Testens nicht aufeinander abgestimmt ist.

Durch die Verwendung der „Drei Brücken“ und des „Szenario-Vertrags“ können Ingenieure aufhören zu raten, warum ein Test fehlgeschlagen ist. Sie können auf ihre Checkliste schauen und sagen: „Ah, wir haben eine Lücke in der Attributions-Brücke. Wir müssen ein spezifisches Code-Label hinzufügen, um zwischen einem Sensorfehler und einem GPS-Fehler zu unterscheiden.“

Kurz gesagt: JTA verwandelt das vage Gefühl von „das ist schwer zu testen“ in eine spezifische, umsetzbare Aufgabenliste. Es verschiebt die Diskussion von „Ist der Code gut?“ zu „Ist unser gesamtes Test-Team darauf vorbereitet, zu beweisen, dass der Code sicher ist?“ Für jeden, der Software entwickelt, die Menschenleben schützt, ist das ein bedeutender Wandel.

Technisches Resümee: Joint Testability Architecture (JTA) für sicherheitskritische Software

1. Problemstellung

Die Angemessenheit der Validierung in sicherheitskritischen Softwaresystemen (z. B. Flugsteuerung, autonomes Fahren) wird häufig nicht durch einen Mangel an Testfällen behindert, sondern durch die Unfähigkeit, kritische Szenarien stabil zu konstruieren, Evidenzdaten in ein urteilsbereites Format zu organisieren oder abnormale Ergebnisse eindeutigen technischen Grenzen zuzuordnen. Die traditionelle Testbarkeitsforschung konzentriert sich primär auf das Softwareartefakt selbst und betrachtet Testbarkeit als eine statische Eigenschaft des Codes (Kontrollierbarkeit und Beobachtbarkeit). Diese artefaktzentrierte Sichtweise ist jedoch unzureichend für sicherheitskritische Szenarien, die Failsafe-Aktivierungen, Modus-Migrationen oder die Koordination mehrerer Komponenten beinhalten. Sie adresset nicht die Frage, ob die kombinierte Fähigkeit des Szenarios, des Testsystems und des Systems unter Test (SUT) ausreicht, um eine angemessene Validierung zu unterstützen. Folglich garantiert „testbarer Code“ nicht, dass die „szenariobasierte Validierung angemessen“ ist.

2. Methodik: Die Joint Testability Architecture (JTA)

Die JTA definiert Testbarkeit neu als eine szenario-konditionierte Fähigkeit eines gemeinsamen Systems. Sie schlägt eine formale Architektur und einen fünfstufigen Analyse-Workflow vor, um Kapazitätslücken zu identifizieren und zu schließen.

2.1 Formales Modell

Die Architektur wird als $JTA = \langle D_\Sigma, D_T, D_S, BC, BO, BI, L \rangle$ definiert und besteht aus:

Drei Domänen:
- Szenario-Domäne ( $D_\Sigma$ ): Organisiert Validierungsziele, Randbedingungen und Kritikalität.
- Testsystem-Domäne ( $D_T$ ): Umfasst die Fähigkeiten zur Stimulation, Evidenzsammlung und Urteilsgenerierung.
- System-unter-Test-Domäne ( $D_S$ ): Beinhaltet das funktionale Verhalten sowie die exponierten Validierungshaken (Kontrollpunkte, Evidenzpunkte, Verantwortungsbereiche).
Drei Brücken (Bridges): Architektonische Muster, die die Domänen verbinden, um Kapazitätsmismatch zu lösen:
- Control Bridge ($BC$): Übersetzt Szenario-Vorbedingungen in reproduzierbare Parameterstellungen und Fehlereinspritzungen (Fault Injections).
- Evidence Bridge ($BO$): Organisiert Rohprotokolle und Zustände in strukturierte, zeitlich ausgerichtete Evidenz für automatisierte Urteile.
- Attribution Bridge ($BI$): Ordnet anomale Ergebnisse spezifischen Auslöserquellen und Verantwortungsbereichen zu, um die Behebung zu ermöglichen.
Closed Loop ( $L$ ): Ein iterativer Prozess aus Analyse, Design, Evaluierung und Verfeinerung.

2.2 Kernkonzepte

Joint Testability System ( $JTS_\sigma$ ): Die Analyseeinheit ist nicht die Software allein, sondern das Tripel $\langle \sigma, T_\sigma, S_\sigma \rangle$ , welches ein spezifisches Szenario, die beteiligten Testfähigkeiten und den relevanten SUT-Rand darstellt.
Szenario-Kontrakte ( $SC(\sigma)$ ): Eine Acht-Tupel-Spezifikation $\langle g, p, u, e, o, r, \kappa, \Theta \rangle$ , die explizit das Validierungsziel, Vorbedingungen, Stimulationsmodus, minimale Evidenz, Urteilsregeln, eine Menge an unterscheidbaren Fehlerquellen ( $r$ ), Kritikalität sowie Mindestschwellenwerte für Kontrollierbarkeit, Beobachtbarkeit und Isoliereffektivität definiert.
Gemeinsame Kapazitätsbewertung (Joint Capability Assessment):
- Kontrollierbarkeit ( $C$ ), Beobachtbarkeit ( $O$ ) und Isoliereffektivität ( $I$ ): Werden sowohl für das SUT ($CS, OS, IS$) als auch für das Testsystem ($CT, OT, IT$) gemessen.
- Gemeinsame Kapazität ($JTCap$): Definiert als das Minimum der SUT- und Testsystem-Kapazitäten für jede Dimension (z. B. $JC = \min(CS, CT)$ ), was dem „Schwächstwert-Prinzip“ entspricht.
- Angemessenheit ($Adeq$): Ein Szenario ist nur dann angemessen, wenn alle drei gemeinsamen Dimensionen die im Kontrakt definierten Mindestschwellenwerte erfüllen.
- Blind Spots (Blinde Flecken): Szenarien, in denen $Adeq(\sigma) = 0$ gilt.

2.3 Fünfstufiger Workflow

Identifikation kritischer Szenarien: Bestimmung der Menge $\Sigma$ und Zuweisung von Kritikalitätsgewichten.
Instanziierung von Szenario-Kontrakten: Explizite Definition von Zielen, Evidenzanforderungen und der Menge der zu unterscheidenden Fehlerquellen.
Bewertung bilateraler Kapazitäten: Evaluierung von $Cap_S$ und $Cap_T$ gegenüber den Kontraktanforderungen.
Berechnung von Lücken und Identifikation von Blinden Flecken: Berechnung des Kapazitätslücken-Vektors $Gap(\sigma)$ und Identifikation von Szenarien, die die Angemessenheit verfehlen.
Brücken-Design und Re-Evaluierung: Abbildung der Lücken auf spezifische Design-Aktionen auf den Control-, Evidence- oder Attribution-Brücken, gefolgt von einer erneuten Evaluierung.

3. Wesentliche Beiträge

Joint Testability System Modell ( $JTS_\sigma$ ): Erweitert das Objekt der Validierung von einem isolierten Artefakt zu einer szenario-instanziierten gemeinsamen Entität, bestehend aus Szenario, Testsystem und SUT.
Szenario-Kontrakte mit Fehlerquellen-Sets: Führt einen formalen Kontrakt ein, der eine Menge unterscheidbarer Fehlerquellen ( $r$ ) enthält, wodurch die Isoliereffektivität von einem generischen Konzept in eine konkrete Design-Einschränkung für die Attribution transformiert wird.
Brücken-orientierte Designmethode: Schlägt ein Framework aus „drei Domänen, drei Brücken und einem geschlossenen Kreislauf“ vor, das Kapazitätslücken direkt auf ausführbare architektonische Design-Aktionen abbildet (z. B. Hinzufügen eines Timing-Controllers zur Control Bridge oder Erweiterung der Ursache-Codes zur Attribution Bridge).
Illustrative Analyse von ArduPilot: Demonstriert die Anwendung der JTA auf die Failsafe-Validierung von ArduPilot und identifiziert spezifische Blinde Flecken in Szenarien zum Verbindungsverlust und zu EKF-Schätzungsanomalien.

4. Ergebnisse: ArduPilot Fallstudie

Die Autoren wandten JTA auf drei Failsafe-Szenarien des Open-Source-Projekts ArduPilot an: RC-Verbindungsverlust (S1), GCS-Heartbeat-Timeout (S2) und EKF-Zustandsschätzungsanomalien (S3).

S1 (RC-Verbindungsverlust): Als Angemessen (1) eingestuft. Das Testsystem und das SUT unterstützen das Szenario gemeinsam, wenngielige Engpässe in der Strukturierung der Evidenz bestehen.
S2 (GCS-Heartbeat-Timeout): Als Unangemessen (0) eingestuft. Obwohl das Szenario ausgelöst werden kann, ist die Attribution Bridge schwach; die aktuellen Protokolle können nicht zwischen echten Timeouts und Fehlern im Test-Toolchain unterscheiden.
S3 (EKF-Anomalien): Als Unangemessen (0) eingestuft. Dieses Szenario offenbart Engpässe sowohl in der Kontrollierbarkeit (Schwierigkeit, die Stärke der Perturbation von deren Timing zu entkoppeln) als auch in der Isoliereffektivität (Mehrdeutigkeit bei der Unterscheidung zwischen EKF-Gesundheitsfehlern und gleichzeitiger GPS-Degradation).

Systemweite Metrik: Die kritikalitätsgewichtete Angemessenheitsabdeckung ($JT(JTS)$) für die analysierten Szenarien wurde auf 28,6 % berechnet, was verdeutlicht, dass hochkritische Szenarien (wie EKF-Anomalien) trotz reifer Infrastruktur für einfachere Szenarien signifikante Validierungs-Blinde-Flecken bleiben.

Design-Empfehlungen: Die Analyse lieferte spezifische Brücken-Aktionen, wie etwa:

Hinzufügen einer „triadischen Attributionsansicht“ (Timeout-Ereignis – Ursache-Code – Verbindungsstatus) für S2.
Implementierung von parametrisierten Perturbations-Templates und injektionsfähigen Replay-Adaptern für S3 zur Verbesserung der Kontrollierbarkeit.

5. Bedeutung und Ansprüche

Das Paper behauptet, dass JTA eine architektonische Basis für die Modellierung, das Design und die Bewertung szenariobasierter Validierung bietet, anstatt bestehende Test- oder Sicherheitsanalysetechniken zu ersetzen.

Perspektivwechsel: Der Fokus verschiebt sich von der Frage „Ist der Code testbar?“ hin zu „Ist das gemeinsame System in der Lage, dieses spezifische Szenario zu validieren?“.
Handlungsorientierte Ausgabe: Es transformiert vage technische Eindrücke von „schwer testbar“ in dimensionale, objektlokalisierbare und ausführbare Design-Lücken.
Proaktive Validierung: Es plädiert dafür, die Validierungsfähigkeit als architektonisches Qualitätsmerkmal zu behandeln, das zusammen mit der funktionalen Fähigkeit entworfen werden sollte, anstatt sie erst nach der Implementierung zu prüfen.
Komplementarität: JTA ergänzt bestehende Methoden wie STPA (die Szenarien identifiziert) und Fault Injection (die Abnormalitäten konstruiert), indem es das fehlende Bindeglied für die Bewertung der gemeinsamen Angemessenheit und Attribution bereitstellt.

Die Autoren halten sich hinsichtlich ihrer Ansprüche zurück und merken an, dass die Fallstudie illustrativ ist und auf ordinalen (H/M/L) Bewertungen anstelle von quantitativen Leistungsmetriken beruht; zudem bedarf die Anwendbarkeit auf geschlossene industrielle Systeme mit eingeschränkten Schnittstellen weiterer Validierung.