Introduzione
Introduzione
La salvaguardia dell’ambiente e la tutela della salute umana sono questioni di fondamentale importanza per la società moderna. La maggiore consapevolezza degli effetti dell’inquinamento atmosferico sulla salute umana e sull’ambiente e la crescente attenzione rivolta verso tali problematiche hanno spinto i principali Paesi industrializzati all’approvazione di leggi per limitare le emissioni di sostanze nocive da parte degli autoveicoli.
Per evitare che, nel tempo, le emissioni del veicolo superino le soglie previste dalle norme di omologazione, da qualche anno è stato introdotto l’obbligo di segnalare eventuali malfunzionamenti del sistema elettronico di controllo e dei componenti. Ciò ha richiesto l’implementazione di funzioni di autodiagnosi (OBD, on board diagnostic) all’interno delle ECU, determinando un maggior numero di loop di controllo che esse devono gestire in funzione dei segnali provenienti dai sensori e di quelli inviati agli attuatori. Oltre ad individuare possibili guasti, le funzioni diagnostiche devono anche verificare la plausibilità dei segnali provenienti dai sensori, ossia la loro correttezza in relazione alle condizioni di funzionamento del motore. In presenza di problemi, l’unità di controllo deve compensare le anomalie attivando strategie di controllo sostitutive (strategie di recovery).
Per garantire il rispetto dei limiti di emissione tollerabili, gran parte delle attività svolte in sala prove interessa la calibrazione di mappe sperimentali di base, attraverso le quali gli algoritmi di controllo determinano, secondo quanto è stato rilevato dai sensori, il valore delle variabili manipolabili (parametri di attuazione), da cui dipende la gestione degli attuatori.
L’estrema complessità delle funzioni di controllo motore, dovuta principalmente alla necessità di soddisfare le sempre più restrittive normative antinquinamento, non permette di analizzarne il comportamento mediante la generazione di segnali elettrici in ingresso come accadeva in passato. Oggi è essenziale la presenza di segnali attendibili provenienti da tutti i sensori, per evitare l’attivazione di strategie di recovery che non consentirebbero alcun tipo di verifica degli algoritmi di controllo effettivamente impiegati in condizioni di normale funzionamento.
L’esigenza di ridurre il time-to-market attraverso lo sviluppo parallelo di ECU e veicolo e di stabilire una prima validazione del software di controllo senza ricorrere all’esecuzione di numerose e costose prove su strada, ha portato allo sviluppo ed alla diffusione di sistemi di simulazione Hardware in the loop, attraverso i quali è possibile testare un componente hardware,
2
Introduzione
come una unità di controllo, simulando il motore a combustione interna con un modello, capace di fornire in output dati plausibili in sostituzione di quelli inviati da tutti i sensori.
Questa tesi, realizzata durante uno stage svolto presso l’ente Applicazione Motopropulsori di Ferrari S.p.A., ha come obiettivo lo sviluppo di procedure automatiche finalizzate alla verifica dei software di sistemi elettronici di controllo motore in ambiente di simulazione Hardware in the loop. Queste procedure automatiche sono sostanzialmente programmi scritti nel linguaggio
Python, lo scopo dei quali è monitorare il comportamento delle funzioni di autodiagnosi e fornire indicazioni per l’eventuale delibera delle evoluzioni dei software di controllo rispetto alle versioni di base, già validate e deliberate con attività sperimentali per ottenere il miglior comportamento del motore in termini di prestazioni e riduzione delle emissioni. Dopo aver eseguito i test, questi programmi generano in output un report per permettere l’analisi delle prove.
L’esposizione è stata organizzata in sei capitoli.
Nel primo capitolo sono illustrate le normative antinquinamento dei Paesi dell’Unione Europea e degli Stati Uniti e la normativa riguardante l’On Board Diagnostic.
Nel secondo capitolo sono descritti i principali componenti dell’architettura del sistema di controllo Bosch Motronic ME7, impiegato sulle vetture Ferrari e Maserati.
Nel terzo capitolo vengono descritte le caratteristiche della simulazione Hardware in the loop e la struttura hardware e software del simulatore HIL Ferrari.
Nel quarto capitolo sono introdotti il linguaggio di programmazione Python ed i programmi utilizzati per automatizzare i test.
Il quinto capitolo riporta una descrizione dei principali problemi affrontati durante la fase di ricerca e rimozione degli errori sia della parte hardware che software del simulatore.
Nel sesto capitolo sono infine illustrati i test realizzati.
3
