C’è un momento che la maggior parte degli ingegneri automobilistici conosce bene. Durante un giro di prova si verifica un guasto: un’anomalia termica, un messaggio inaspettato sulla rete del veicolo, un comportamento transitorio del sistema che non dovrebbe verificarsi. L’ingegnere se ne accorge. Il giro di prova termina e, quando qualcuno esamina i dati, la finestra temporale rilevante dei segnali è già scomparsa, sepolta in registri indistinti o semplicemente mai acquisita. Quindi il team programma un altro giro per riprodurre il problema.
Non si tratta di un problema legato ai dati. Gli ingegneri raramente si trovano a dover fare i conti con una carenza di dati. Si tratta di un problema di architettura — che si manifesta non solo nei laboratori di validazione, ma in ogni fase del ciclo di vita del veicolo, dai test sui prototipi alla gestione della qualità sul campo dopo il lancio.
Ho trascorso anni lavorando all’intersezione tra software per veicoli e sistemi di intelligenza, e il quadro è sempre lo stesso: l’industria automobilistica ha costruito una sofisticata infrastruttura di dati senza sviluppare il livello di intelligenza che la renda utilizzabile. Raccogliamo. Archiviamo. Analizziamo in un secondo momento, se ci riusciamo. Consideriamo l’intelligenza come qualcosa che avviene dopo l’acquisizione dei dati — in un report o in un dashboard — piuttosto che come qualcosa che emerge continuamente dal veicolo stesso.
Il problema dell'intelligenza episodica
Il modello dominante odierno per l'analisi dei dati dei veicoli è di tipo episodico: cattura un momento ma non la causa, e richiede il giudizio umano per collegare i due elementi.
Nella fase di validazione, questo si manifesta come il “problema del re-drive”. Un team di collaudo sottopone un prototipo a uno scenario complesso — comportamento in fase di immissione in autostrada, cicli termici con avviamento a freddo, casi limite ADAS in condizioni di traffico misto — e si verifica un’anomalia. Il data logger non era configurato per acquisire quel segnale. Oppure lo era, ma la finestra di acquisizione era troppo ristretta. Oppure semplicemente non era stato raccolto il contesto cross-domain corretto insieme ad esso. Il team si trova di fronte a un sintomo ma non conosce la causa principale, quindi deve ripetere il test. Con una flotta di prototipi limitata, in cui ogni veicolo rappresenta un investimento significativo e i programmi di test sono già serri, il costo di una ripetizione del test non si limita al carburante e alle miglia percorse. Comprende anche il tempo dedicato dagli ingegneri, la disponibilità dei prototipi e il rischio di non rispettare la scadenza prevista per l’entrata in produzione (SOP), che è un fattore critico da evitare.
Sul campo, gli stessi limiti architettonici si manifestano in modo diverso. Emerge un problema di qualità della flotta: le richieste di intervento in garanzia iniziano a concentrarsi su una specifica modalità di guasto, oppure nei dati di servizio si delinea uno schema ricorrente. Quando il team di ingegneri ha raccolto le prove necessarie per diagnosticare la causa principale, il guasto ha già colpito un numero consistente di clienti. Le informazioni sono arrivate troppo tardi per cambiare l’esito della situazione.
Entrambi i problemi hanno la stessa causa: il sistema è stato progettato per archiviare dati, non per generare comprensione. C’è una differenza sostanziale tra avere accesso ai dati e avere accesso all’intelligenza — e colmare questo divario è proprio lo scopo per cui è stato creato l’Agentic Loop.
Vi presentiamo l’Agentic Loop
L'Agentic Loop è un'architettura di intelligenza a ciclo chiuso in cui ogni fase alimenta e perfeziona quella successiva, in modo continuo, senza richiedere un intervento manuale per avviare il ciclo.
Cinque fasi. Ognuna precisa e ponderata:
- Rilevare — Monitorare costantemente i segnali provenienti dai vari sistemi del veicolo per identificare in tempo reale anomalie, deviazioni e condizioni che meritano di essere approfondite.
- Raccogli — Attiva l'acquisizione di dati mirata e ricca di contesto esattamente quando e dove serve — non una registrazione in massa, ma una raccolta intelligente legata agli eventi rilevati.
- Motivo — Applicare un'analisi assistitAI a su dati provenienti da più fonti per formulare ipotesi, identificare i fattori che contribuiscono al fenomeno e trarre conclusioni causali.
- Agire — Fornire approfondimenti su Surface all’ingegnere giusto, inviare un aggiornamento di configurazione o attivare un suggerimento di assistenza — in modo autonomo e appropriato.
- Impara — Reinserire i risultati nei modelli di rilevamento e ragionamento, in modo che ogni ciclo successivo sia più preciso del precedente.
L’uso del termine “sistema operativo” è intenzionale. Proprio come un sistema operativo non esegue l’applicazione — ma crea le condizioni affinché le applicazioni funzionino in modo efficace — l’Agentic Loop non sostituisce il giudizio ingegneristico. Esso astrae la complessità dei dati del veicolo in modo che gli ingegneri possano concentrarsi sulle decisioni piuttosto che sulla gestione dei dati. Gli ingegneri addetti alla validazione, i responsabili della qualità e le operazioni post-vendita possono tutti operare all’interno dello stesso ciclo di intelligenza — proprio come diverse applicazioni girano su un sistema operativo condiviso — ottenendo ciascuno ciò di cui ha bisogno da un’infrastruttura condivisa.
Ecco come si presenta l’argomentazione. Ma il concetto di “sistema operativo” è una metafora facile da enunciare e molto più difficile da giustificare. Regge solo se ogni fase del ciclo fa effettivamente ciò che è stato descritto sopra.
Nella seconda parte di questo articolo del blog, esaminiamo una per una le fasi di “Rilevazione”, “Raccolta”, “Ragionamento”, “Azione” e “Apprendimento”, illustrando cosa cambia in ciascuna di esse.
