Résumé Technique : Architecture de Testabilité Conjointe (JTA) pour les Logiciels Critiques pour la Sécurité

1. Énoncé du Problème

Dans les systèmes logiciels critiques pour la sécurité (ex. : contrôle de vol, conduite automatisée), l'adéquation de la validation est souvent entravée non pas par un manque de cas de test, mais par l'incapacité à construire de manière stable des scénarios critiques, à organiser les preuves d'exécution sous des formes prêtes pour le verdict, ou à attribuer les résultats anormaux à des limites d'ingénierie exploitables. La recherche traditionnelle sur la testabilité se concentre principalement sur l'artefact logiciel lui-même, traitant la testabilité comme une propriété statique du code (contrôlabilité et observabilité). Cette vision centrée sur l'artefact est insuffisante pour les scénarios critiques impliquant l'activation de modes de sécurité (failsafe), la migration de mode ou la coordination multi-composants. Elle ne permet pas de déterminer si la capacité conjointe du scénario, du système de test et du système sous test (SUT) est suffisante pour soutenir une validation adéquate. Par conséquent, le fait qu'un « code soit testable » ne garantit pas que la « validation basée sur des scénarios soit adéquate ».

2. Méthodologie : L'Architecture de Testabilité Conjointe (JTA)

La JTA recadre la testabilité comme une capacité conditionnée par le scénario d'un système conjoint. Elle propose une architecture formelle et un flux de travail d'analyse en cinq étapes pour identifier et combler les écarts de capacité.

2.1 Modèle Formel

L'architecture est définie comme $JTA = \langle D_\Sigma, D_T, D_S, BC, BO, BI, L \rangle$, comprenant :

• Trois Domaines :
  • Domaine du Scénario ($D_\Sigma$) : Organise les objectifs de validation, les contraintes et la criticité.
  • Domaine du Système de Test ($D_T$) : Englobe les capacités de stimulation, de collecte de preuves et de génération de verdicts.
  • Domaine du Système Sous Test ($D_S$) : Inclut le comportement fonctionnel et les points d'accroche de validation exposés (points de contrôle, points de preuve, limites de responsabilité).
• Trois Ponts : Motifs architecturaux qui connectent les domaines pour résoudre les décalages de capacité :
  • Pont de Contrôle ($BC$) : Traduit les préconditions du scénario en paramètres reproductibles et en injections de fautes.
  • Pont d'Évidence ($BO$) : Organise les journaux bruts et les états en preuves structurées et temporellement alignées pour des verdicts automatisés.
  • Pont d'Attribution ($BI$) : Mappe les résultats anormaux à des sources de déclenchement spécifiques et à des limites de responsabilité pour permettre la remédiation.
• Boucle Fermée ($L$) : Un processus itératif d'analyse, de conception, d'évaluation et de raffinement.

2.2 Concepts Clés

• Système de Testabilité Conjointe ($JTS_\sigma$) : L'unité d'analyse n'est pas le logiciel seul, mais le triplet $\langle \sigma, T_\sigma, S_\sigma \rangle$ représentant un scénario spécifique, les capacités de test participantes et la limite pertinente du SUT.
• Contrats de Scénario ($SC(\sigma)$) : Une spécification en huit éléments $\langle g, p, u, e, o, r, \kappa, \Theta \rangle$ qui définit explicitement l'objectif de validation, les préconditions, le mode de stimulation, l'évidence minimale, les règles de verdict, un ensemble de sources de fautes distinguables ($r$), la criticité, et les seuils minimaux de contrôlabilité, d'observabilité et d'isolabilité.
• Évaluation de la Capacité Conjointe :
  • Contrôlabilité ($C$), Observabilité ($O$) et Isolabilité ($I$) : Mesurées à la fois pour le SUT ($CS, OS, IS$) et pour le Système de Test ($CT, OT, IT$).
  • Capacité Conjointe ($JTCap$) : Définie comme le minimum des capacités du SUT et du Système de Test pour chaque dimension (ex. : $JC = \min(CS, CT)$), reflétant le principe du « maillon faible ».
  • Adéquation ($Adeq$) : Un scénario est adéquat uniquement si les trois dimensions conjointes respectent les seuils minimaux définis dans le contrat.
  • Zones Aveugles (Blind Spots) : Scénarios où $Adeq(\sigma) = 0$.

2.3 Flux de Travail en Cinq Étapes

1. Identifier les Scénarios Critiques : Déterminer l'ensemble $\Sigma$ et assigner des poids de criticité.
2. Instancier les Contrats de Scénario : Définir explicitement les objectifs, les exigences d'évidence et l'ensemble des sources de fautes à distinguer.
3. Évaluer les Capacités Bilatérales : Évaluer $Cap_S$ et $Cap_T$ par rapport aux exigences du contrat.
4. Calculer les Écarts et Identifier les Zones Aveugles : Calculer le vecteur d'écart de capacité $Gap(\sigma)$ et identifier les scénarios échouant à l'adéquation.
5. Conception de Ponts et Réévaluation : Mapper les écarts à des actions de conception spécifiques sur les ponts de Contrôle, d'Évidence ou d'Attribution, puis réévaluer.

3. Contributions Clés

1. Modèle de Système de Testabilité Conjointe ($JTS_\sigma$) : Étend l'objet de la validation d'un artefact isolé vers une entité conjointe scénarisée comprenant le scénario, le système de test et le SUT.
2. Contrats de Scénario avec Ensembles de Sources de Fautes : Introduit un contrat formel incluant un ensemble de sources de fautes distinguables ($r$), transformant l'isolabilité d'un concept générique en une contrainte de conception concrète pour l'attribution.
3. Méthode de Conception Orientée Ponts : Propose un cadre « trois domaines, trois ponts et une boucle fermée » qui mappe les écarts de capacité directement à des actions de conception architecturale exécutables (ex. : ajouter un contrôleur de timing au Pont de Contrôle ou des extensions de codes de cause au Pont d'Attribution).
4. Analyse Illustrative d'ArduPilot : Démontre l'application de la JTA sur la validation des modes de sécurité (failsafe) d'ArduPilot, identifiant des zones aveugles spécifiques dans les scénarios de perte de liaison et d'anomalies d'estimation d'état.

4. Résultats : Étude de Cas ArduPilot

Les auteurs ont appliqué la JTA à trois scénarios de failsafe du projet open-source ArduPilot : perte de liaison RC (S1), expiration du battement de cœur (heartbeat) du GCS (S2), et anomalies d'estimation d'état EKF (S3).

• S1 (Perte de liaison RC) : Évalué comme Adéquat (1). Le système de test et le SUT soutiennent conjointement le scénario, bien que certains goulots d'étranglement existent dans la structuration des preuves.
• S2 (Expiration du Heartbeat GCS) : Évalué comme Inadéquat (0). Bien que le scénario puisse être déclenché, le Pont d'Attribution est faible ; les journaux actuels ne peuvent pas distinguer les expirations réelles des erreurs de la chaîne d'outils de test.
• S3 (Anomalies EKF) : Évalué comme Inadéquat (0). Ce scénario révèle des goulots d'étranglement tant dans la Contrôlabilité (difficulté à découpler la force de la perturbation et le timing) que dans l'Isolabilité (ambiguïté entre les échecs de santé de l'EKF et une dégradation concomitante du GPS).

Métrique au Niveau du Système : La couverture d'adéquation pondérée par la criticité ($JT(JTS)$) pour les scénarios analysés a été calculée à 28,6 %, soulignant que les scénarios à haute criticité (comme les anomalies EKF) restent des zones aveugles de validation significatives malgré une infrastructure mature pour les scénarios plus simples.

Recommandations de Conception : L'analyse a produit des actions spécifiques au niveau des ponts, telles que :

• L'ajout d'une « vue d'attribution triadique » (événement de timeout – code de cause – statut de la liaison) pour S2.
• L'implémentation de modèles de perturbation paramétrés et d'adaptateurs de rejeu activés par injection pour S3 afin d'améliorer la contrôlabilité.

5. Signification et Revendications

L'article affirme que la JTA fournit une base architecturale pour modéliser, concevoir et évaluer la validation basée sur des scénarios, plutôt que de remplacer les techniques existantes de test ou d'analyse de sécurité.

• Changement de Perspective : Elle déplace l'attention de « le code est-il testable ? » vers « le système conjoint est-il capable de valider ce scénario spécifique ? ».
• Résultat Actionnable : Elle transforme les impressions d'ingénierie vagues de « difficile à tester » en écarts de conception traçables par dimension, localisables par objet et exécutables par action.
• Validation Proactive : Elle préconise de traiter la capacité de validation comme un attribut de qualité architecturale qui doit être conçu parallèlement à la capacité fonctionnelle, plutôt que d'être vérifié seulement après l'implémentation.
• Complémentarité : La JTA complète les méthodes existantes comme la STPA (qui identifie les scénarios) et l'injection de fautes (qui construit les anormalités) en fournissant le lien manquant pour évaluer l'adéquation conjointe et la convergence de l'attribution.

Les auteurs font preuve de modestie concernant leurs revendications, notant que l'étude de cas est illustrative et repose sur des évaluations ordinales (H/M/L) plutôt que sur des mesures de performance quantitatives, et que l'applicabilité aux systèmes industriels fermés avec des interfaces restreintes nécessite une validation supplémentaire.