Unifying Runtime Monitoring Approaches for Safety-Critical Machine Learning: Application to Vision-Based Landing

1. Enunciato del Problema

L'integrazione dell'Apprendimento Automatico (ML), in particolare delle Reti Neurali Profonde (DNN), in sistemi critici per la sicurezza (ad esempio, aviazione, guida autonoma) introduce sfide significative in termini di affidabilità. Le DNN mancano di robustezza, spesso falliscono sotto input imprevisti ed esibiscono una fiducia eccessiva in previsioni errate. Sebbene esistano monitor di sicurezza in tempo reale per mitigare questi rischi, la ricerca attuale è frammentata tra diverse comunità (affidabilità vs. apprendimento automatico).

• Il Divario: I metodi di monitoraggio esistenti operano in silos con terminologie e ambiti diversi. Alcuni si concentrano sui vincoli operativi a livello di sistema, altri sugli spostamenti statistici della distribuzione dei dati e altri ancora sugli stati interni del modello.
• La Conseguenza: Questa mancanza di unificazione porta a una copertura parziale della sicurezza, a metodologie sovrapposte e alla difficoltà di confrontare o combinare diversi monitor utilizzando metriche comuni. Non esiste un quadro unificato per categorizzare sistematicamente le minacce e selezionare strategie di monitoraggio adeguate.

2. Metodologia: Il Framework SwMF

Gli autori propongono un quadro unificato chiamato SwMF (Safety-critical ML Monitoring Framework). Questo framework ridefinisce lo spazio di input ML e categorizza gli approcci di monitoraggio in base alle specifiche "minacce ai dati" che affrontano.

A. Decomposizione dello Spazio di Input

Gli autori proiettano tre concetti chiave sullo spazio di input ML (ad esempio, immagini) per definire domini e minacce distinti:

1. Dominio di Progetto Operativo (ODD): L'insieme delle condizioni in cui il sistema è progettato per operare (ad esempio, meteo, altitudine, visibilità della pista).
   • Minaccia: Violazioni dell'ODD. Input al di fuori delle condizioni operative previste.
2. Dominio In-Distribution ($D_{ID}$): Dati estratti dalla stessa distribuzione dei dati di addestramento.
   • Minaccia: Minacce Out-of-Distribution (OOD). Input che rientrano nell'ODD ma sono statisticamente diversi dai dati di addestramento (ad esempio, spostamenti di covariate come cambiamenti di illuminazione, o spostamenti semantici come nuove classi di oggetti).
3. Ambito del Modello ($D_f$): Il sottoinsieme di input in cui il modello ML specifico $f$ produce previsioni corrette.
   • Minaccia: Errori In-Distribution (ID). Input che rientrano in $D_{ID}$ ma causano comunque il fallimento del modello (ad esempio, attacchi avversari, difetti fisici sottili o limiti di generalizzazione del modello).

B. Categorizzazione dei Monitor

Sulla base di queste minacce, il framework definisce tre categorie complementari di monitor:

1. Monitor ODD: Monitor basati su regole che verificano le variabili di sistema (ad esempio, GPS, IMU, sensori meteorologici) rispetto a vincoli predefiniti. Rifiutano gli input prima che raggiungano il modello ML se le condizioni operative non sono valide.
2. Monitor OOD: Monitor basati sui dati che rilevano anomalie statistiche nei dati di input (ad esempio, luminosità, entropia, densità dei bordi) rispetto alla distribuzione di addestramento. Rifiutano gli input che si discostano dalla distribuzione di addestramento ma che rientrano ancora nell'ODD.
3. Monitor OMS (Out-of-Model-Scope): Monitor post-hoc che analizzano le caratteristiche interne del modello ML (ad esempio, logit, attivazioni dei neuroni) o le uscite per rilevare comportamenti anomali. Mirano specificamente agli input in cui il modello è probabile che fallisca, anche se l'input appare "normale".

C. Configurazione Sperimentale

• Applicazione: Atterraggio basato sulla visione (VBL), specificamente il sottocompito di Rilevamento della Pista (VBRD).
• Dataset: Il dataset LARD (immagini sintetiche generate tramite Google Earth Studio).
• Modello: YOLOv5-n (un rilevatore di oggetti a stadio singolo).
• Architettura: Una pipeline di monitoraggio seriale in cui i monitor ODD vengono eseguiti per primi, seguiti dai monitor OOD e infine dai monitor OMS dopo la previsione del modello.
• Metriche di Valutazione: Metriche orientate alla sicurezza proposte da Guerin et al.:
  • Guadagno di Sicurezza (SG): Proporzioni di situazioni pericolose filtrate correttamente.
  • Rischio Residuo (RH): Proporzione di situazioni pericolose mancate.
  • Costo di Disponibilità (AC): Proporzione di situazioni sicure rifiutate erroneamente (falsi allarmi).

3. Contributi Chiave

1. Terminologia Unificata: Il documento chiarisce le definizioni di ODD, OOD e OMS, risolvendo l'ambiguità in cui questi termini sono spesso usati in modo intercambiabile nella letteratura. Distingue esplicitamente tra spostamenti della distribuzione dei dati (OOD) e regioni di fallimento del modello (OMS).
2. Classificazione Basata sulle Minacce: Introduce una mappatura formale tra specifiche minacce ai dati (violazioni ODD, spostamenti OOD, errori ID) e la categoria di monitoraggio appropriata, fornendo una guida di progettazione sistematica per gli ingegneri della sicurezza.
3. Dimostrazione di Complementarità: Attraverso esperimenti, gli autori dimostrano che questi tre tipi di monitor affrontano modalità di fallimento diverse e sono intrinsecamente complementari, piuttosto che ridondanti.
4. Valutazione Unificata: Il framework consente il confronto di monitor diversi utilizzando un unico insieme di metriche di sicurezza (SG, RH, AC).

4. Risultati Sperimentali

Lo studio è stato condotto in due esperimenti:

Esperimento 1: Set di Test Nominali (Dati Sintetici)

• Baseline: Il modello YOLOv5-n ha avuto un Rischio Residuo (RH) di ~20% (il che significa che il 20% delle immagini ha causato errori).
• Prestazioni Individuali:
  • I monitor ODD hanno rilevato ~4,6% degli errori (SG).
  • I monitor OOD hanno rilevato ~4,1% degli errori.
  • I monitor OMS hanno rilevato ~4,0% degli errori.
• Prestazioni Combinate: Quando tutti e tre i monitor sono stati applicati in sequenza, il Guadagno di Sicurezza è aumentato al 9,7% e il Rischio Residuo è sceso al 10,5%.
• Compromesso: L'approccio combinato ha aumentato il Costo di Disponibilità (AC) a ~31%, il che significa che circa il 30% delle immagini sicure è stato rifiutato. Questo evidenzia il compromesso "sicurezza vs. disponibilità".

Esperimento 2: Dati Corrotti (Test di Robustezza)

• Configurazione: Le immagini sono state corrotte con cambiamenti di luminosità, sfocatura, nebbia e rumore.
• Monitor OOD: Altamente efficace nel rifiutare immagini corrotte (alto SG), agendo come un filtro "precauzionale". Tuttavia, ciò ha comportato alti Costi di Disponibilità (AC) perché ha rifiutato dati anche quando il modello avrebbe potuto gestirli correttamente.
• Monitor OMS: Meno efficace sui dati corrotti rispetto all'OOD. Ha funzionato meglio su input "puliti" ma difficili (errori ID).
• Conclusione: I risultati validano l'architettura seriale. I monitor OOD dovrebbero filtrare per primi gli spostamenti di distribuzione ovvi, permettendo ai monitor OMS di concentrarsi sui fallimenti sottili del modello all'interno della restante distribuzione "sicura".

5. Significato e Conclusione

• Progettazione Sistematica della Sicurezza: Il framework SwMF fornisce un approccio strutturato per la progettazione di sistemi di monitoraggio in tempo reale, garantendo che tutti i principali vettori di minaccia (operativi, statistici e specifici del modello) siano coperti.
• Colmare il Divario tra Comunità: Colma con successo il divario tra la comunità dell'affidabilità (sicurezza a livello di sistema) e la comunità del ML (distribuzione dei dati e comportamento del modello).
• Implicazioni Pratiche: Lo studio conferma che, sebbene la combinazione di monitor migliori significativamente la sicurezza (riducendo il rischio residuo), aumenta inevitabilmente il tasso di falsi allarmi (costo di disponibilità). Il lavoro futuro deve concentrarsi sull'ottimizzazione di questo compromesso e sul miglioramento della selezione dei dati per l'addestramento di questi monitor per rappresentare meglio le minacce operative.

In sintesi, il documento sostiene che una strategia di monitoraggio unificata e multilivello è essenziale per il dispiegamento sicuro del ML in sistemi aeronautici critici, superando soluzioni isolate per abbracciare un'architettura di sicurezza olistica.