Riepilogo Tecnico: RAMS – Modello di Switching per la Risorse-Adattività e Condizionato alla Rilevazione per la Percezione Edge Embedded

1. Problematica

L'implementazione del rilevamento di oggetti su hardware embedded affronta una tensione fondamentale tra latenza di inferenza e qualità del rilevamento che è assente negli ambienti cloud. Mentre la latenza di inferenza nel cloud è limitata principalmente dalla complessità del modello e dal tempo di andata e ritorno della rete, i dispositivi embedded condividono risorse CPU e memoria con il sistema operativo host, i servizi in background e le pipeline dei sensori. Man mano che l'utilizzo del sistema aumenta, la latenza di inferenza per un modello fisso degrada sostanzialmente (ad esempio, un'inferenza YOLOv8-MEDIUM su un Intel i7-1165G7 può degradare da 448 ms in idle a oltre 1500 ms sotto carico di picco).

Il classico compromesso — passare a un modello più leggero per ridurre la latenza — introduce un costo asimmetrico. Un'inferenza a 320 px su una strada vuota incorre nello stesso penalità di accuratezza di una che contiene un pedone nelle vicinanze, ma mancare un pedone comporta un rischio per la sicurezza che non è catturato dalle sole metriche di latenza. Inoltre, i sistemi adattivi esistenti spesso si affidano a soglie fisse che non sono trasferibili tra hardware eterogenei a causa delle variazioni di pressione delle risorse in idle, o richiedono connettività cloud, che non è disponibile sui dispositivi edge.

2. Metodologia: Il Sistema RAMS

RAMS (Resource-Adaptive and Detection-Conditioned Model Switching) è un controllore runtime leggero progettato per bilanciare latenza e sicurezza senza latenza di ricaricamento del modello. Opera interamente sul dispositivo e consiste in quattro componenti:

A. Monitor della Pressione delle Risorse

Eseguito a 10 Hz, il monitor interroga i segnali a livello di OS (utilizzo della CPU, pressione della memoria virtuale, temperatura e carica della batteria) per calcolare un indice di pressione scalare $R(t) \in [0, 1]$.
$$R(t) = w_c c + w_m m + w_T \hat{T} + w_b (1 - b)$$
I pesi riflettono la dominanza empirica dell'utilizzo della CPU nei carichi di lavoro embedded. Se specifici sensori non sono disponibili, i loro pesi vengono ridistribuiti sull'utilizzo della CPU.

B. Calibrazione della Soglia Relativa all'Idle

Per garantire la portabilità tra diversi dispositivi senza una sintonizzazione manuale per ogni dispositivo, RAMS impiega una procedura di calibrazione relativa all'idle. Invece di utilizzare soglie fisse, il sistema profila il dispositivo in idle (nessun carico di inferenza) per determinare una pressione di base $R_{idle}$. Le soglie di switching sono quindi impostate come offset fissi da questa base:
$$\theta_\ell = R_{idle} + \delta_\ell, \quad \theta_h = R_{idle} + \delta_h$$
dove $\delta_\ell = 0.10$ e $\delta_h = 0.25$. Ciò assicura che il significato semantico delle soglie (ad esempio, "carico moderato") rimanga coerente tra diverse piattaforme (ad esempio, Raspberry Pi 5 rispetto a Jetson Orin).

C. Libreria di Modelli "Warm"

RAMS mantiene tre livelli YOLOv8 (NANO a 320px, SMALL a 416px, MEDIUM a 640px) residenti simultaneamente in memoria. Questo approccio "warm-tier" elimina la penalità di latenza associata al caricamento dei modelli su richiesta. L'impronta di memoria totale è di circa 81 MB per i modelli ONNX FP32 e 120–150 MB per i motori TensorRT.

D. Politiche di Switching

Il controllore implementa cinque politiche che vanno dal semplice superamento della soglia allo switching condizionato dalla rilevazione:

1. Politica di Soglia (Threshold Policy): Utilizza l'isteresi per evitare oscillazioni rapide tra i livelli basate su $R(t)$.
2. Politica Predittiva (Predictive Policy): Utilizza una media mobile esponenzialmente pesata (EWMA) per prevedere la pressione e innescare i downgrade prima che le soglie vengano superate.
3. Politica Adattiva (Adaptive Policy): Auto-sintonizza il fattore di smoothing dell'EWMA in base alla varianza delle letture di pressione recenti.
4. Politica di Sicurezza (Safety Policy): Un override condizionato dalla rilevazione che impedisce il downgrade al livello NANO entro una finestra temporale ($\Delta t_w = 0.5$s) dopo la rilevazione di un Utente della Strada Vulnerabile (VRU).
5. Politica di Sicurezza a Due Livelli (Safety2): Una versione potenziata che condiziona il livello di override in base all'area della bounding box del VRU rilevato. Le scatole grandi (oggetti vicini) innescano un blocco sul livello MEDIUM, mentre le scatole piccole (oggetti distanti) innescano un blocco sul livello SMALL.

3. Contributi Chiave

1. Indice di Pressione delle Risorse Formale: Un metodo di calibrazione relativo all'idle e portabile ($R(t)$) che permette alle stesse equazioni del controllore di operare su un intervallo di latenza di 37× su hardware eterogeneo senza sintonizzazione per singolo dispositivo.
2. Switching Condizionato dalla Rilevazione: Cinque politiche formalmente specificate, incluse due varianti reattive che ritardano i downgrade in base alle recenti rilevazioni di VRU, affrontando il costo asimmetrico della perdita di oggetti critici per la sicurezza.
3. Metrica SWAS: Lo SWAS (VRU-Weighted Accuracy Score), una metrica scalare per il confronto offline delle politiche su video non etichettati. La metrica pesa l'accuratezza in base alla presenza di VRU. Il documento introduce una variante "oracle-bounded" ($SWAS^\star$) che utilizza le etichette ground-truth per separare i benefici della ritenzione del livello dalla circolarità dell'uso dell'output del proprio rilevatore (potenzialmente imperfetto) per innescare la policy.
4. Valutazione Esaustiva: Una valutazione di dieci esperimenti su cinque target hardware (Raspberry Pi 5, Intel i7-1165G7, i7-13700F, Jetson Orin ONNX, Jetson Orin TensorRT) coprendo la sensibilità al carico, la sintonizzazione dell'isteresi e i trade-off tra sicurezza e latenza.

4. Risultati

Gli esperimenti sono stati condotti utilizzando i livelli YOLOv8 e il dataset KITTI. Le scoperte chiave includono:

• Trade-off tra Latenza e Accuratezza: Su Jetson Orin con TensorRT sotto carico pesante, la politica Safety2 ha ottenuto una latenza media di 3.41 ms (5.6× più veloce di FIXED-MEDIUM) mantenendo il 74% dell'accuratezza proxy. Ha ottenuto questo operando principalmente in modalità NANO ma bloccandosi selettivamente in modalità SMALL o MEDIUM durante le finestre con presenza di VRU.
• Miglioramenti SWAS: Sotto carico pesante, lo switching condizionato dalla rilevazione ha migliorato lo SWAS del 25.4% sotto scoring oracle (la stima conservativa che tiene conto della circolarità del rilevatore) e del 47.3% sotto scoring derivato dal rilevatore rispetto alle sole politiche di soglia.
• Portabilità Cross-Device: Le stesse equazioni del controllore hanno governato l'operatività attraverso un intervallo di latenza di 37× (da 3.41 ms su Jetson TRT a 127.52 ms su Jetson ONNX). Il sistema si è adattato con successo alla selezione del livello in base alle specifiche capacità dell'hardware senza aggiustamenti manuali delle soglie.
• Limiti di Recall: Il documento quantifica esplicitamente un limite fondamentale dei sistemi reattivi. Con il livello NANO che raggiunge solo il 24.2% di recall VRU su KITTI, l'override di sicurezza è inattivo per il 76% dei frame con presenza di VRU perché il rilevatore base ha fallito nel far scattare la condizione. Ciò evidenzia come lo switching reattivo non possa compensare i limiti intrinseci di recall del modello di livello più basso.
• Risposta Transitoria: Il controllore si impegna ai cambiamenti di livello entro 3 campioni di monitoraggio (0.3s) per le politiche di soglia e più velocemente per le politiche predittive/adaptive. Le politiche di sicurezza introducono un massimo di 5 cicli aggiuntivi a un livello superiore dopo un evento VRU prima di tornare indietro.

5. Significato e Rivendicazioni

Il documento sostiene che RAMS sia l'unico sistema che combina lo switching warm-tier, la selezione del livello condizionata dalla rilevazione, la calibrazione portabile tra i dispositivi e l'operatività completa sul dispositivo senza offload verso il cloud.

Gli autori sottolineano che il miglioramento dello SWAS oracle del 25.4% rappresenta un beneficio reale dello switching condizionato dalla rilevazione, distinto dai guadagni gonfiati dello scoring derivato dal rilevatore causati dalla circolarità dell'uso di un rilevatore a bassa recall per innescare i blocchi di sicurezza. Il lavoro dimosta che è possibile ottenere una latenza vicina a quella di NANO preservando una parte significativa dell'accuratezza dei livelli più pesanti durante le finestre critiche di sicurezza.

Tuttavia, il documento è modesto riguardo ai limiti di questo approccio. Esso afferma esplicitamente che l'override reattivo è limitato dalla recall del rilevatore base; se il livello NANO manca un VRU, il blocco di sicurezza non può scattare. Gli autori identificano questo come un vincolo fondamentale di qualsiasi sistema reattivo condizionato dalla rilevazione che opera sotto un rilevatore imperfetto, suggerendo che il lavoro futuro debba concentrarsi su rilevatori base leggeri più forti o classificatori VRU paralleli per colmare questo divario. Il sistema non rivendica la fornitura di garanzie formali di sicurezza (ad esempio, ISO 26262), ma piuttosto un meccanismo per ottimizzare il trade-off tra latenza e accuratezza in ambienti con risorse limitate.