Validazione dei Risultati di Test
per Attività in Sala Prova Motore
con Algoritmi di Intelligenza Artificiale

ATTIVITÀ DI RICERCA IN SALA PROVA MOTORI

All’albero motore è collegato, per mezzo di giunto, un freno dinamometrico elettrico o un motore elettrico con inverter.

Alla UUT (Unit Under Test) sono connessi vari sensori e strumenti di misura in grado di acquisire le principali grandezze d’interesse durante i test.

Per coordinare u banco prova così strutturato è necessario un potente Sistema di Automazione, che faccia da collettore di tutta la strumentazione di misura e che sia in grado di manovrare programmaticamente il motore e l’intera sala prova.

AVL PUMA Open è considerato lo standard mondiale per i banchi prova motore e consiste in una suite software estremamente completa e integrabile con tutta la piattaforma di test AVL.

EURINS AdaMo, basato su tecnologia HW e SW National Instruments, è un sistema modulare molto valido per attività di ricerca non solo in ambito automotive.

La qualità e la complessità dei dati acquisiti durante le prove richiedono un’importante attività di Post-Elaborazione, da condurre per mezzo di strumenti adeguati a tale scopo.

SCOPO DEL PROGETTO

ARCHITETTURA DEL SISTEMA REALIZZATO

Per ogni tipologia di prova automatica, è definito un algoritmo di test, implementato nei due sistemi d’automazione secondo le relative tecniche e linguaggi di programmazione.

L’implementazione dev’essere coerente e deve produrre un file si risultati identico, a prescindere dal sistema di automazione che lo crea.

Mentre PUMA gestisce file di risultati in formato ASM ODS, AdaMo restituisce file di output testuali, assemblati in un unico file di tipo ASAM ATF, per mezzo del FileConverter appositamente realizzato.

Nel file devono essere presenti le medesime chiavi di memorizzazione, in modo particolare V_IN, che contiene i parametri di input per la predizione di AITV

I file di risultati ATF prodotti dal FileConverter sono raccolti in un’area d’archiviazione dedicata alle quattro sale prova AdaMo, mentre entrambe le sale AVL PUMA dispongono di un proprio Database ASAM ODS.

È stato realizzato un Data Environment in AVL Concerto, che raccoglie sei Datasource corrispondenti a ciascuna sala prova, i quali forniscono un’interfaccia d’accesso ai dati dei test, definita a parte dal formato e da altre preferenze.

Il risultato è un Database Centralizzato, unico per le sei sale prova, che fornisce i medesimi metodi d’accesso ai dati, a prescindere dal formato e dal sistema d’automazione di provenienza.

Il file dei risultati è caricato mediante il corrispondente Datasource, che rende disponibile anche le librerie di formule, implementate in linguaggio Concerto (simile a VB ma con elementi C) o Python indispensabili per processare i dati.

Il processo di elaborazione die dati grezzi è realizzato mediante diversi script (in linguaggio Concerto o Python) associati a un layout che raggruppa le finestre contenenti Diagram e altre strutture grafiche in grado di rappresentare i risultati del test.

Una volta completata l’elaborazione dei dati, un sottoinsieme delle finestre del layout viene stampato e va a costituire il report finale, un documento che indica i risultati ottenuti dal test in sala prova.

Una volta ultimata la post-elaborazione, è possibile eseguire, sullo stesso file di risultati caricato, il processo di validazione di AITV (Artificial Intelligence Test Validator).

AITV esegue l’apprendimento sul training set associato alla tipologia di prova mediante l’algoritmo Gradient Descent, che restituisce una funzione ipotesi in grado di predire il risultato da validare con la Regressione Lineare Multivariata.

I dati contenuti nella chiave V_IN del file di risultati costituiscono le feature d’input della predizione parametrizzata dell’utente, da cui è ottenuto un valore predetto dal risultato da validare.

La differenza tra il valore predetto e quello realmente calcolato può indicare la validità del risultato: se è troppo elevata, è probabile che ci siano stati errori di attuazione, misura o calcolo.

Infine il Parser raccoglie i dati della chiave V_IN del file di risultati e i relativi risultati validati, che vanno a costituire nuovi campioni del training set associato alla tipologia di prova di riferimento.

CASO DI STUDIO: LAMBDA STEP

L’algoritmo di test del Lambda Step consiste in un’iterazione elementare ripetuta su 15 punti operativi (3 velocità, 5 carichi), che prevede una serie transizioni di lambda,  da <<ricco>> a <<magro>>

Supponendo di aver condotto una prova di Lambda Step in CM4, il FileConverter trasforma la cartella di risultati in un file ATF e lo rende disponibile nel corrispondente Datasource

La post-elaborazione ha come principale scopo il calcolo, per ogni punto, della Oxygen Storage Capacity (OSC) del catalizzatore, un parametro cruciale per valutarne lo stato e l’efficienza

L’algoritmo del Lambda Step prevede la memorizzazione in V_IN di un nuovo punto per ogni iterazione, nel quale sono salvati i valori iniziali di Temperatura dell’ATS, portata d’aria in ingresso al motore e concentrazione volumetrica d’ossigeno a monte dell’ATS.

Prendendo ad esempio la quarta iterazione del Lambda Step effettuato in CM4 per questo caso di studio, è stato adoperato AITV per predire il corrispondente valore di OSC e, dal confronto con quello calcolato, risulta una differenza di circa lo 0.8%.

CONCLUSIONI E SVILUPPI FUTURI