Sintesi Tecnica: Architettura di Testabilità Congiunta (JTA) per Software Critici per la Sicurezza

1. Definizione del Problema

Nei sistemi software critici per la sicurezza (ad es., controllo del volo, guida autonoma), l'adeguatezza della validazione è spesso ostacolata non dalla mancanza di casi di test, ma dall'incapacità di costruire stabilmente scenari critici, organizzare le evidenze di esecuzione in forme pronte per il verdetto, o attribuire esiti anormali a confini ingegneristici azionabili. La ricerca tradizionale sulla testabilità si concentra principalmente sull'artefatto software stesso, trattando la testabilità come una proprietà statica del codice (controllabilità e osservabilità). Tuttavia, questa visione centrata sull'artefatto è insufficiente per scenari critici per la sicurezza che coinvolgono l'attivazione di meccanismi di failsafe, migrazioni di modalità o coordinamento tra più componenti. Essa non affronta se la capacità combinata dello scenario, del sistema di test e del sistema sotto test (SUT) sia sufficiente a supportare una validazione adeguata. Di conseguenza, il fatto che il "codice sia testabile" non garantisce che la "validazione basata su scenari sia adeguata".

2. Metodologia: L'Architettura di Testabilità Congiunta (JTA)

La JTA riformula la testabilità come una capacità condizionata dallo scenario di un sistema congiunto. Propone un'architettura formale e un flusso di lavoro di analisi in cinque fasi per identificare e colmare i gap di capacità.

2.1 Modello Formale

L'architettura è definita come $JTA = \langle D_\Sigma, D_T, D_S, BC, BO, BI, L \rangle$, composta da:

• Tre Domini:
  • Dominio dello Scenario ($D_\Sigma$): Organizza gli obiettivi di validazione, i vincoli e la criticità.
  • Dominio del Sistema di Test ($D_T$): Comprende le capacità di stimolazione, raccolta delle evidenze e generazione dei verdetti.
  • Dominio del Sistema Sotto Test ($D_S$): Include il comportamento funzionale e gli hook di validazione esposti (punti di controllo, punti di evidenza, confini di responsabilità).
• Tre Ponti: Pattern architettonici che collegano i domini per risolvere i disallineamenti di capacità:
  • Ponte di Controllo ($BC$): Traduce le precondizioni dello scenario in impostazioni di parametri riproducibili e iniezioni di guasti.
  • Ponte di Evidenza ($BO$): Organizza i log grezzi e gli stati in evidenze strutturate e temporalmente allineate per verdetti automatizzati.
  • Ponte di Attribuzione ($BI$): Mappa gli esiti anomali a specifiche sorgenti di trigger e confini di responsabilità per consentire la rimedio.
• Ciclo Chiuso ($L$): Un processo iterativo di analisi, progettazione, valutazione e raffinamento.

.2 Concetti Chiave

• Sistema di Testabilità Congiunta ($JTS_\sigma$): L'unità di analisi non è il software isolato, ma la tripletta $\langle \sigma, T_\sigma, S_\sigma \rangle$ che rappresenta uno specifico scenario, le capacità di test partecipanti e il confine rilevante del SUT.
• Contratti di Scenario ($SC(\sigma)$): Una specifica composta da otto elementi $\langle g, p, u, e, o, r, \kappa, \Theta \rangle$ che definisce esplicitamente l'obiettivo di validazione, le precondizioni, la modalità di stimolazione, l'evidenza minima, le regole del verdetto, un insieme di sorgenti di guasto distinguibili ($r$), la criticità e le soglie minime di controllabilità, osservabilità e isolabilità.
• Valutazione della Capacità Congiunta:
  • Controllabilità ($C$), Osservabilità ($O$) e Isolabilità ($I$): Misurate sia per il SUT ($CS, OS, IS$) che per il Sistema di Test ($CT, OT, IT$).
  • Capacità Congiunta ($JTCap$): Definita come il minimo tra le capacità del SUT e del Sistema di Test per ogni dimensione (ad es., $JC = \min(CS, CT)$), riflettendo il principio del "anello più debole".
  • Adeguatezza ($Adeq$): Uno scenario è adeguato solo se tutte e tre le dimensioni congiunte soddisfano le soglie minime definite nel contratto.
  • Blind Spots (Punti Ciechi): Scenari in cui $Adeq(\sigma) = 0$.

2.3 Flusso di Lavoro in Cinque Fasi

1. Identificare gli Scenari Critici: Determinare l'insieme $\Sigma$ e assegnare i pesi di criticità.
2. Istanziare i Contratti di Scenario: Definire esplicitamente obiettivi, requisiti di evidenza e l'insieme delle sorgenti di guasto da distinguere.
3. Valutare le Capacità Bilaterali: Valutare $Cap_S$ e $Cap_T$ rispetto ai requisiti del contratto.
4. Calcolare i Gap e Identificare i Punti Ciechi: Calcolare il vettore del gap di capacità $Gap(\sigma)$ e identificare gli scenari che falliscono l'adeguatezza.
5. Progettazione dei Ponti e Re-valutazione: Mappare i gap su specifiche azioni di progettazione sui ponti di Controllo, Evidenza o Attribuzione, quindi rivalutare.

3. Contributi Principali

1. Modello di Sistema di Testabilità Congiunta ($JTS_\sigma$): Espande l'oggetto della validazione da un artefatto isolato a un'entità congiunta istanziata dallo scenario che comprende lo scenario, il sistema di test e il SUT.
2. Contratti di Scenario con Insiemi di Sorgenti di Guasto: Introduce un contratto formale che include un insieme di sorgenti di guasto distinguibili ($r$), trasformando l'isolabilità da un concetto generico in un vincolo di progettazione concreto per l'attribuzione.
3. Metodo di Progettazione Orientato ai Ponti: Propone un framework "tre domini, tre ponti e un ciclo chiuso" che mappa i gap di capacità direttamente ad azioni di progettazione architettonica eseguibili (ad es., aggiungere un controllore temporale al Ponte di Controllo o estensioni di codici di causa al Ponte di Attribuzione).
4. Analisi Illustrativa di ArduPilot: Dimostra l'applicazione di JTA sulla validazione del failsafe di ArduPilot, identificando specifici punti ciechi negli scenari di perdita di link e anomalie di stima dello stato.

4. Risultati: Caso di Studio ArduPilot

Gli autori hanno applicato JTA a tre scenari di failsafe nel progetto open-source ArduPilot: perdita di link RC (S1), timeout dell'heartbeat GCS (S2) e anomalie di stima dello stato EKF (S3).

• S1 (Perdita di Link RC): Valutata come Adeguata (1). Il sistema di test e il SUT supportano congiuntamente lo scenario, sebbene esistano alcuni colli di bottiglia nella strutturazione delle evidenze.
• S2 (Timeout Heartbeat GCS): Valutata come Inadeguata (0). Sebbene lo scenario possa essere attivato, il Ponte di Attribuzione è debole; i log attuali non possono distinguere tra timeout reali ed errori della catena di strumenti di test.
• S3 (Anomalie EKF): Valutata come Inadeguata (0). Questo scenario rivela colli di bottiglia sia nella Controllabilità (difficoltà nel disaccoppiare l'intensità della perturbazione e il timing) che nell'Isolabilità (ambiguità nel distinguere tra fallimenti della salute EKF e degradazione simultanea del GPS).

Metrica a Livello di Sistema: La copertura di adeguatezza ponderata per la criticità ($JT(JTS)$) per gli scenari analizzati è stata calcolata al 28,6%, evidenziando che gli scenari ad alta criticità (come le anomalie EKF) rimangono significativi punti ciechi di validazione nonostante l'infrastruttura matura per scenari più semplici.

Raccomandazioni di Progettazione: L'analisi ha prodotto specifiche azioni a livello di ponte, come:

• L'aggiunta di una "vista di attribuzione triade" (evento timeout–codice causa–stato del link) per S2.
• L'implementazione di template di perturbazione parametrizzati e adapter di replay abilitati all'iniezione per S3 per migliorare la controllabilità.

5. Significato e Rivendicazioni

Il paper sostiene che la JTA fornisca una base architettonica per modellare, progettare e valutare la validazione basata su scenari, piuttosto che sostituire le tecniche esistenti di testing o analisi della sicurezza.

• Cambio di Prospettiva: Sposta il focus da "il codice è testabile?" a "il sistema congiunto è capace di validare questo specifico scenario?".
• Output Azionabile: Traduce le vaghe impressioni ingegneristiche di "difficile da testare" in gap di progettazione tracciabili per dimensione, localizzabili per oggetto ed eseguibili per azione.
• Validazione Proattiva: Propone di trattare la capacità di validazione come un attributo di qualità architettonica che deve essere progettato insieme alla capacità funzionale, piuttosto che essere controllato solo dopo l'implementazione.
• Complementarità: La JTA completa i metodi esistenti come STPA (che identifica gli scenari) e l'iniezione di guasti (che costruisce le anormalità) fornendo il collegamento mancante per valutare l'adeguatezza congiunta e la convergenza dell'attribuzione.

Gli autori mantengono la modestia riguardo alle loro rivendicazioni, notando che il caso di studio è illustrativo e si basa su valutazioni ordinali (H/M/L) piuttosto che su metriche di prestazione quantitative, e che l'applicabilità a sistemi industriali chiusi con interfacce ristrette richiede un'ulteriore validazione.