CAPITOLO 3

Il sistema Hardware in the loop

3.1. Le applicazioni

Prima di passare alle illustrazioni del simulatore e dei modelli, è opportuno elencare quali sono i motori destinati alla simulazione mediante lo strumento Hardware in the loop e descriverne le principali caratteristiche.

Questi motori sono essenzialmente i tre che equipaggiano la Maserati Quattroporte (Fig. 3.1), la Ferrari F430 (Fig. 3.2) ed un secondo veicolo Ferrari attualmente allo stato prototipale. Nella tabella 3.1 sono riportati i dati tecnici dei primi due. Del terzo veicolo non sono riportate le caratteristiche tecniche per motivi di riservatezza.

Fig. 3.1: Maserati Quattroporte Fig. 3.2: Ferrari F430

Maserati Quattroporte Ferrari F430

Numero di cilindri 8 cilindri a V di 90° 8 cilindri a V di 90°

Alesaggio x corsa 92 mm x 79.8 mm 92 mm x 81 mm

Cilindrata unitaria 530.5 cm3 _{538.5 cm}3

Cilindrata totale 4244 cm3 _{4308 cm}3

Rapporto di compressione 11:1 11.3:1

Potenza massima 294 kW (400 CV) a 7000 giri/min _{360.4 kW (490 CV) a 8500 giri/min}

Coppia massima 451 Nm a 4500 giri/min _{465 Nm a 5250 giri/min}

Nel seguito del testo non sarà fatto riferimento ai nomi sopra indicati, ma ciascun veicolo ed il rispettivo motore saranno contraddistinti dalla sigla che caratterizza ogni progetto all’interno di Ferrari S.p.A.. Queste sigle sono M139 per Maserati Quattroporte, F131Evo per Ferrari F430 ed F141 per l’ultima vettura.

3.1.1. Applicazione M139

In figura 3.3 è riportato uno schema che illustra la struttura ed i principali componenti di questo motore. Il collettore di scarico, per la bancata in cui esso non è rappresentato, è identico a quello dell’altra bancata e ciò è da ritenersi valido per tutti gli schemi che saranno esaminati.

Il motore è diviso in due bancate di quattro cilindri e sono presenti una unica linea di alimentazione aria per l’intero motore (dotata di una valvola a farfalla a controllo elettronico) ed una linea di scarico per ciascuna bancata.

Fig. 3.3: layout M139

La distribuzione è a due alberi a camme in testa per bancata azionati da catena e quattro valvole per cilindro comandate da punterie idrauliche. Gli alberi a camme di aspirazione sono dotati di un variatore di fase continuo.

Le sonde lambda sono due per ciascun collettore di scarico.

Una unica centralina controlla in modo differenziato le due bancate, comandando, ad esempio, due diverse durate di iniezione (indicate nella ECU con le variabili ti_b1 e ti_b2).

In seguito si parlerà, per tutti i motori, di bancata destra o sinistra impiegando questa convenzione: la bancata destra coincide con quella che si trova alla destra di un osservatore il cui sguardo è diretto verso la parte anteriore del veicolo. Ad esempio, in questo caso i cilindri numerati da uno a quattro fanno parte della bancata destra.

3.1.2. Applicazione F131Evo

Questo motore, a differenza del precedente, possiede due distinte linee di alimentazione aria, su ciascuna delle quali si trovano un filtro, un sensore di portata ed una farfalla motorizzata (Fig. 3.4). Il collettore di aspirazione termina in due plenum. Un tamburo rotante, attuato pneumaticamente dalla centralina, mette in comunicazione le capacità delle due bancate per ottimizzare i fenomeni dinamici in aspirazione.

Per quanto riguarda il sistema di scarico, è presente una linea per ciascuna bancata.

Fig. 3.4: layout F131Evo

La distribuzione è a quattro alberi a camme in testa mossi da catena, quattro valvole per cilindro comandate da punterie idrauliche e quattro variatori di fase continui.

Anche nell’F131Evo sono impiegate due sonde lambda per ciascun collettore di scarico.

La gestione del motore è affidata a due centraline elettroniche, ciascuna delle quali opera su una singola bancata e comunica con quella dell’altra attraverso una linea CAN dedicata. Considerando lo stesso esempio delle variabili che indicano le durate di iniezione, avremo adesso un valore di ti_b1 per una ECU ed un altro valore (eventualmente coincidente) della stessa variabile per l’altra.

In seguito sarà fatto riferimento al concetto di centralina master e centralina slave: in entrambe le applicazioni Ferrari, dove ogni bancata è controllata da una ECU, come master si intende quella della bancata destra e per slave quella della bancata sinistra. Questa distinzione è dovuta al fatto che, tra i compiti della prima, vi è anche la gestione della linea di scambio delle informazioni tra i due dispositivi.

3.1.3. Applicazione F141

Questo motore è un 12 cilindri a V e, analogamente all’F131Evo, possiede due diverse linee di alimentazione aria con due polmoni, mentre, per quanto riguarda la distribuzione, ha quattro valvole per cilindro, quattro alberi a camme in testa e quattro variatori di fase continui.

Una sostanziale differenza è costituita dal collettore di scarico: come si può osservare dalla figura 3.5, esistono, per ciascuna bancata, due condotti di scarico, i quali sono poi riunificati in un unico canale all’uscita del catalizzatore.

Fig. 3.5: layout F141

Le sonde lambda sono in questo caso otto, ovvero due per ciascuno dei condotti relativi ad un gruppo di tre cilindri.

Anche questa applicazione è dotata di due unità di controllo. A differenza dell’F131Evo, ogni centralina non gestisce nello stesso modo tutta la bancata di sua competenza, ma svolge la sua funzione controllando in modo differenziato due gruppi di tre cilindri: con riferimento alla figura 3.5, nella centralina master è realizzato un controllo diversificato per il gruppo di cilindri 1-2-3 e per quello 4-5-6, mentre sulla bancata sinistra accade la stessa cosa con i gruppi 7-8-9 e 10-11-12. Rifacendosi allo stesso esempio delle durate di iniezione, per ciascuna ECU saranno definite due variabili: una ti_b1 per un gruppo di tre cilindri ed una ti_b2 per l’altro.

3.2. La simulazione Hardware in the loop

Il concetto che sta alla base di un sistema di simulazione Hardware in the loop è quello di testare un componente hardware, che può essere la stessa ECU oppure un qualunque attuatore, nell’ambito del suo normale ambiente di funzionamento, riprodotto da un modello simulato in

real-time.

Il modello deve generare, verso la centralina di controllo, segnali di output come la portata di aria aspirata dai cilindri, l’indice di eccesso aria e la velocità di rotazione del motore per simulare i segnali provenienti dai sensori del motore. In input avrà bisogno di dati come la posizione della valvola a farfalla, l’angolo di accensione e le durate di iniezione. Attraverso questo scambio di dati, si può ottenere un sistema, composto dalla parte software (il modello) e da quella hardware (la ECU), controllato dalla stessa centralina in loop, in anello chiuso.

Per esempio, inviando alla ECU i valori della quantità di aria che sta entrando nel cilindro e dell’indice di eccesso aria λ in una determinata condizione di funzionamento del motore, essa può determinare, in funzione della strategia di controllo, una nuova durata di iniezione da attuare. Alla nuova durata corrisponderà una variazione dei dati di input del modello, grazie alla quale sarà possibile valutare i nuovi output.

La presenza di questi loop di controllo implica l’esigenza di impiegare un sistema di tipo

real-time, per assicurare un comportamento del modello che sia il più possibile aderente alla

realtà. Sistemi di questo tipo devono reagire agli input entro un tempo predefinito, garantendo una elaborazione corretta dei dati principalmente dal punto di vista temporale. Ciò non significa che un sistema real-time debba essere necessariamente veloce, ma è fondamentale che sia capace di rispondere agli input entro tolleranze note a priori.

La presenza di funzioni diagnostiche, che monitorano il corretto funzionamento degli attuatori del motore, comporta l’ulteriore esigenza di integrare nel sistema i componenti reali o, eventualmente, carichi elettrici equivalenti in loro sostituzione.

Per collegare il “mondo reale” della centralina e degli attuatori a quello “virtuale”, costituito dalla simulazione del modello, occorrono particolari interfacce che permettano la conversione dei dati elaborati dal microprocessore durante la simulazione in segnali elettrici da trasmettere alla ECU e viceversa. Per tale scopo sono impiegate particolari schede elettroniche, il cui funzionamento sarà descritto nel prossimo paragrafo.

La figura 3.6 illustra il meccanismo di loop che è stato descritto.

Consideriamo, ad esempio, che cosa accade per una valvola a farfalla controllata elettronicamente. La posizione del pedale dell’acceleratore può essere fissata nel modello e, in corrispondenza di essa, sarà inviato un segnale alla centralina. A questo punto la ECU, in funzione di quanto individuato dalle strategie di controllo, comanda il motore elettrico della farfalla per raggiungere l’angolo di apertura obiettivo, controllando gli effetti di questa azione con un feedback che costituisce il primo anello chiuso del sistema.

Fig. 3.6: loop tra modello e centralina di controllo

Il segnale proveniente dai potenziometri della farfalla indica l’angolo effettivo di apertura ed è inviato anche al modello, poiché da esso dipende la quantità di aria aspirata dal motore, che è calcolata dallo stesso modello. Una volta trasmessa alla centralina la portata di aria elaborata, si creano ulteriori loop che coinvolgono, ad esempio, la quantità di combustibile iniettata per adeguare i valori di λ alle nuove condizioni di funzionamento.

3.2.1. I vantaggi della simulazione HIL

I benefici offerti da un sistema Hardware in the loop sono:

• la possibilità di testare, nelle prime fasi del processo di sviluppo prodotto, sia nuove funzioni di controllo o di diagnosi sviluppate per la ECU che precedenti strategie di controllo con diverse calibrazioni dei parametri anche in assenza di veicoli prototipali, permettendo così una riduzione del time-to-market attraverso lo sviluppo simultaneo di motore e sistema di controllo;

• la sostituzione, attraverso simulazioni, di prove su strada di non immediata realizzazione oppure che costituiscono una fonte di potenziale pericolo per il collaudatore;

• la possibilità di simulare estreme oppure inusuali condizioni ambientali variando semplicemente il valore di alcuni parametri del modello, eseguendo, ad esempio, in estate prove di avviamento a freddo;

• la simulazione, attraverso apposite schede, di guasti ai componenti, che potrebbero provocare, su un veicolo reale, danneggiamenti per gli stessi componenti e rischi per l’incolumità del collaudatore;

• la possibilità di riprodurre in modo preciso ed automatico, ogni qualvolta lo si ritenga opportuno, gli esperimenti, a differenza di quanto avviene nella realtà, in cui è estremamente difficoltoso replicare fedelmente le stesse condizioni che hanno caratterizzato un test.

3.3. La struttura hardware del simulatore Ferrari

Il sistema è composto da: • un PC di controllo;

• un simulatore realizzato da dSPACE GmbH; • un break out box;

• componenti reali.

La parte hardware è stata progettata con una flessibilità tale da garantire l’utilizzo delle tre applicazioni attraverso la semplice sostituzione dei cablaggi di collegamento tra le varie parti del simulatore. In figura 3.7 è mostrata una foto del simulatore, mentre la figura 3.8 riporta uno schema generale dell’intero sistema.

Fig. 3.8: schema generale del sistema HIL

3.3.1. Il simulatore

Questo elemento è il nucleo del sistema: infatti sulle sue schede elettroniche è eseguito in

real time il modello e sono presenti le interfacce di I/O, attraverso le quali sono misurati i segnali

di input provenienti dal mondo reale e sono generati quelli di output dal modello. Il simulatore è costituito da sei componenti principali:

• scheda DS1005 con processore PowerPC 750 a 480MHz; • schede DS2210 HIL I/O;

• Failure Insertion Unit (FIU); • load card;

• ECU Connectors; • Power Supply.

Dalla figura 3.10 si può osservare uno schema generale dei collegamenti presenti tra le varie unità del sistema:

Fig. 3.10: collegamenti tra i componenti del simulatore

Oltre a questi elementi, sul simulatore si trova anche una scheda elettronica necessaria per simulare il funzionamento delle sonde lambda.

3.3.1.1. La scheda DS1005

Il processore RTP (real-time processor) della scheda DS1005 è la principale unità di elaborazione e svolge tutti i calcoli necessari all’esecuzione del modello in real-time. Esso è collegato alle schede I/O (ossia alle DS2210) attraverso il bus PHS a 32-bit ed al PC tramite le 8 porte I/O a 16-bit dell’host interface, come evidenziato dalla figura 3.11.

3.3.1.2. La scheda DS2210

Il compito della scheda DS2210 è generare e misurare i segnali automotive per collegare il modello al mondo reale. Ciascuna scheda consente di simulare solamente sei cilindri e quindi è stato necessario l’impiego di due schede per consentire la simulazione delle applicazioni Ferrari-Maserati.

Essa è suddivisa in tre principali unità funzionali (Fig. 3.12), ciascuna delle quali è costituita da vari sottogruppi: Sensor and Actuator Interface, Angular Process Unit (indicata anche con l’acronimo APU) e Communication Interfaces. Tutte e tre ricevono e trasmettono segnali al bus

PHS, comunicando in questo modo con la scheda DS1005.

Fig. 3.12: schema della scheda DS2210

3.3.1.2.1. Sensor and actuator interface

Questa unità offre una serie di funzioni I/O tipiche del campo automotive, quali conversione analogica-digitale (ADC Unit) e viceversa (DAC Unit), generazione di input e lettura di output digitali (Bit I/O Unit), creazione e misura di segnali PWM (PWM Generation e PWM

La spiegazione dettagliata del funzionamento di ciascuna unità e della struttura dei circuiti elettrici che le costituiscono non rientra tra le finalità di questa trattazione, ma per comprendere meglio il funzionamento del sistema è comunque utile descrivere una di esse a titolo di esempio. Consideriamo l’unità D/R Converter.

Questo convertitore D/R dà la possibilità di simulare sensori che forniscono alla ECU un segnale resistivo, così come realmente operano i sensori di temperatura impiegati in un veicolo. La scheda DS2210 invia, verso i connettori I/O, un segnale di uscita (notare, in Fig. 3.12, l’unidirezionalità del segnale), che è poi trasmesso verso la centralina in sostituzione di quello proveniente dal sensore reale.

Per generare il desiderato valore di resistenza in output, la scheda DS1005 invia, sulla base delle elaborazioni svolte che saranno illustrate in seguito, un segnale digitale sul bus PHS. Questo segnale finisce nel convertitore D/R, il quale simula elettricamente il valore richiesto tra i due pin di uscita del simulatore (RESx+ e RESx-). In figura 3.13 è mostrato il circuito elettrico che esegue questa operazione, andando a chiudere i vari circuiti in corrispondenza del segnale digitale di ingresso:

Fig. 3.13: schema elettrico del sottogruppo D/R Converter

Il collegamento tra ciascuna unità della scheda DS2210 e la scheda di elaborazione dati può essere implementato in modo rapido nel modello attraverso apposite librerie, come vedremo meglio nei prossimi paragrafi.

3.3.1.2.2. Angular Process Unit

La APU è la caratteristica principale del simulatore, attraverso la quale sono realizzate funzioni come la generazione dei segnali di posizione di albero a camme ed albero motore, la misura dell’istante di inizio accensione, della quantità di combustibile iniettata e dell’istante di avvio dell’iniezione e la simulazione dei segnali provenienti dai sensori di detonazione.

Tutti i sottogruppi sono connessi all’engine position bus e basano il loro funzionamento sull’engine position phase accumulator (Fig. 3.14).

Fig. 3.14: schema dell’unità Angular Process Unit

L’engine position phase accumulator restituisce, noto il valore di input della velocità di rotazione del motore, la posizione dell’albero motore, ogni 1 µs e con una risoluzione di 0,088°, all’engine position bus. Il compito di questo blocco è convertire, periodicamente, la velocità di rotazione del motore in un valore di posizione compreso tra 0° e 720°.

Fig. 3.15: schema del sottogruppo Engine Position Phase Accumulator

Il Crankshaft Signal Generator ed il Camshaft Signal Generator trasformano la posizione dell’albero motore in segnali elettrici, corrispondenti a quelli forniti al motore dai sensori posti sull’albero motore e sull’albero a camme. Questa conversione è effettuata utilizzando tabelle, che riportano l’andamento dei segnali reali in funzione della posizione dell’albero motore: queste tabelle restituiscono, ogni 0,088°, i livelli dei segnali che devono essere generati.

Fig. 3.16: schema del sottogruppo Crankshaft Signal Generator

Fig. 3.17: schema del sottogruppo Camshaft Signal Generator

Per quanto riguarda il Camshaft Signal Generator, si può osservare dalle figure 3.14 e 3.17 che una delle variabili di ingresso, proveniente dal bus PHS, è costituita dalla fase dell’albero a camme. Essa permette la simulazione dei variatori di fase, come sarà descritto nel paragrafo 3.4.2.1.

Le unità Spark Event Capture ed Injection Event Capture ricevono in ingresso, attraverso i connettori I/O, gli stessi segnali che la centralina trasmette alle bobine ed agli iniettori.

Nel precedente capitolo è stato descritto il modo mediante il quale la ECU riesce ad attuare, in un veicolo reale, i valori dell’angolo di accensione della miscela e della quantità di combustibile iniettata calcolati dalla strategia di controllo.

Per quantificare questi dati nel simulatore ed impiegarli all’interno del modello, si definiscono le ampiezze di due finestre di cattura dell’evento, in corrispondenza delle quali la

Spark Event Capture e la Injection Event Capture intercettano i segnali trasmessi dalla ECU e ne

valutano la durata e gli angoli di inizio.

Il sottosistema DSP (digital signal processor) permette di generare i segnali dei sensori di detonazione. L’avvio della simulazione dei sensori dipende dalla posizione del motore, informazione fornita dall’engine position bus.

Il segnale generato può essere espresso mediante la relazione:

2

( ) d f t cos(2 )

u t = ⋅a e− ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ + (3.1) π f t r

dove a è l’ampiezza, d lo smorzamento, f la frequenza, t il tempo, mentre r è un rumore sul segnale u(t).

3.3.1.2.3. Communication interface

Quando si ha a che fare con un sistema costituito da molti dispositivi che devono scambiare tra loro dati, conviene impiegare una struttura di interconnessione a bus: tutti i dispositivi (ciascuno dei quali è detto “nodo”) inviano su una unica linea i dati che devono trasferire e da essa prelevano quelli di cui necessitano. Sui veicoli è prevalentemente impiegato questo tipo di architettura, che prende il nome di CAN, Controller Area Network.

Fig. 3.20: schema dell’architettura CAN

Nel simulatore l’intera rete CAN può essere simulata attraverso il sottogruppo CAN

Subsystem della scheda DS2210: possono essere inseriti, all’interno del modello, i segnali inviati

alla centralina di controllo motore da una qualunque altra centralina presente sulla vettura ed automaticamente il sottosistema CAN provvede alla trasmissione dei messaggi.

3.3.1.3. La scheda Failure Insertion Unit

Attraverso tale scheda, è possibile simulare guasti nei cablaggi di uscita di una centralina, dal momento che solamente i pin del connettore ECU 2 sono collegati ad essa (si osservi in proposito la figura 3.10). I possibili tipi di guasto che possono essere simulati, agendo sui relais della scheda, sono tre: circuito aperto, cortocircuito a massa e cortocircuito al polo positivo della batteria.

Fig. 3.21: schema della scheda FIU

Attraverso una porta seriale RS232, è possibile controllare lo stato del relais di ciascun canale con programmi realizzati in linguaggio Python.

3.3.1.4. Le load card

Da un punto di vista puramente elettrico, gli attuatori sono considerati dalla centralina come dei carichi ed il loro funzionamento è continuamente monitorato. Se uno di questi carichi elettrici venisse a mancare, tagliando, ad esempio, il cavo di collegamento con la ECU, essa riscontrerebbe l’anomalia e segnalerebbe un codice di errore, adottando poi le necessarie misure previste dalle funzioni di diagnosi.

Nel simulatore tutte le uscite della ECU sono collegate a queste schede e ciò permette sia di riprodurre attuatori reali per mezzo di carichi induttivi e/o resistivi equivalenti, sia di impiegare veri componenti nel caso in cui i carichi elettrici sostitutivi non fossero pienamente soddisfacenti per caratterizzarne in modo corretto il comportamento.

La figura 3.22 mostra l’impiego di un carico simulato (Load), posto tra uno dei canali della scheda e massa (GND).

Fig. 3.22: collegamento di un carico alla load card

3.3.1.5. I connettori

Gli ECU Connectors sono indicati in figura 3.23 con i nomi ECU 1 ed ECU 2. Il compito del primo è collegare la centralina con le uscite delle schede DS2210, mentre il secondo permette di

inviare in input alle DS2210 (attraverso le load card e la scheda FIU) i segnali di uscita generati dalla ECU.

Fig. 3.23: schema di collegamento dei connettori

Sul simulatore si trova anche un connettore diagnostico CARB, che riproduce lo standard prescritto dalla normativa riguardante l’OBD II. Esso è collegato internamente ad un pin del connettore ECU 2, che a sua volta è collegato alla linea diagnostica della centralina.

Attraverso la linea diagnostica, detta linea K, è possibile accedere ad alcune celle di memoria della ECU, nelle quali sono immagazzinati i codici di eventuali errori rilevati dalle funzioni di diagnosi. Particolari strumenti di misura consentono poi di comunicare, attraverso il connettore

CARB, con questa linea diagnostica e di leggere gli errori.

3.3.1.6. L’unità Power supply

L’unità Power supply è utilizzata per simulare la tensione prodotta dal sistema di generazione dell’energia elettrica del veicolo. Essa può essere controllata direttamente dal modello e la tensione di uscita può essere variata nel range 0...20V, per simulare, ad esempio, la caduta di tensione nella fase di accensione del motore.

3.3.2. Il break out box

Sul break out box sono riprodotti tutti i pin della centralina e ciascun ponte è collegato al corrispondente pin della ECU.

Attraverso questo componente, è possibile realizzare misure dei segnali con un oscilloscopio, annullare il collegamento tra la ECU ed il simulatore rimuovendo manualmente un ponte oppure sovrascrivere il segnale collegando il pin a sorgenti esterne di tensione, a massa o alla tensione della batteria.

3.3.3. I componenti reali

Sul simulatore sono collocati due carrelli: su uno di essi (Fig. 3.25) si trovano le due ECU da testare (chiaramente nell’applicazione M139 solo una delle due è collegata al resto del simulatore), due dispositivi elettronici ETAS ES690 ed un terzo dispositivo elettronico ETAS ES600.

Fig. 3.25: carrello contenente le ECU ed i dispositivi ETAS

Le centraline non sono uguali a quelle utilizzate sulle vetture di produzione, ma sono ECU cosiddette “di sviluppo”. Ciascuna di esse è collegata ad un dispositivo ES690, che permette di comunicare con la centralina attraverso un apposito software eseguito sul PC di controllo. Nelle applicazioni Ferrari, nelle quali sono presenti due unità di controllo, il dispositivo ES600 coordina la comunicazione tra le due ES690 ed il PC di controllo.

Il software INCA (Integrated Calibration and Acquisition System), colloquiando con le ES690, consente, durante un test, la lettura e l’acquisizione di tutte le variabili della ECU, nonché la modifica dei valori di parametri (ad esempio valori di soglie) e di mappe. Permette inoltre il download dei file contenenti il software (.a2l) e le calibrazioni (.hex) nelle E2PROM, dove per software si intende il programma che realizza le funzioni di controllo del motore, mentre nel file .hex sono presenti i valori assunti dai parametri contenuti nello stesso software (detti appunto calibrazioni).

Sul secondo carrello (Fig. 3.26), sono presenti gli attuatori reali. I principali componenti che esso contiene sono le due valvole a farfalla controllate elettronicamente, dodici bobine ed iniettori e quattro valvole per l’attuazione dei variatori di fase, oltre ad altre valvole, come quella per il recupero dei vapori di benzina o la valvola del sistema di iniezione dell’aria secondaria, e

diversi relais, tra cui quello della pompa del combustibile e quello del sistema di sicurezza immobilizer.

Fig. 3.26: carrello contenente gli attuatori reali

3.4. La struttura software del simulatore Ferrari

Il modello dei motori a combustione interna è stato realizzato attraverso il programma Simulink. Per rendere possibile una simulazione real-time, è necessario convertire questo modello Simulink in un codice eseguibile dal microprocessore PowerPC della scheda DS1005. Ciò avviene attraverso l’utilizzo di Real-Time Interface (RTI) e di due tool Matlab, Real-Time

Workshop e Stateflow Coder. Real-Time Interface è il sistema che funziona da collegamento tra

Simulink e la parte hardware di input/output del simulatore, mentre gli altri due tool permettono di generare un programma, in linguaggio C, sia del modello che della parte relativa a Matlab/Stateflow. Questo programma in C contiene la descrizione dei blocchi del modello e può essere inviato al microprocessore per realizzare la simulazione real-time. L’insieme delle fasi che permettono di ottenere questo programma, è detta “compilazione del modello” (cfr. § 4.2). La figura 3.27 mostra questo processo.

MATLAB/Simulink/Stateflow Engine/Vehicle/Supervisor Model

Real-Time Workshop Generates ANSI C code

Stateflow Coder Generates ANSI C code for Stateflow

dSPACE Power PC Target

Real-Time Hardware DS1005 PPC

Real-Time Software ControlDesk/Test Automation

Real-Time I/O DS2210 HiL I/O Board

ECU

Loads Cards Failure Insertion Units (FIU)

Power Supply

Fig. 3.27: compilazione del modello

L’alternativa all’utilizzo di Simulink, sarebbe scrivere direttamente il programma in linguaggio C, riportando in esso tutta la complessa struttura del modello. Chiaramente ciò comporterebbe non pochi problemi, sia dal punto di vista della difficoltà di realizzazione, che per il tempo necessario alla creazione dell’intero codice.

3.4.2. Il modello Simulink

Il modello è unico per tutte e tre le applicazioni destinate al sistema Hardware in the loop, nonostante le notevoli differenze che esistono tra i tre motori.

Questa caratteristica è stata ottenuta attraverso la parametrizzazione del modello e l’impiego di numerosi sottosistemi configurabili: a seconda dell’applicazione scelta, certi parametri possono assumere diversi valori ed interi blocchi, come quello che simula il sistema di iniezione, possono essere sostituiti.

Il modello è suddiviso in cinque sottosistemi:

• sottosistema di interfaccia con la parte hardware: Hardware in the loop I/O (Hil); • sottosistema di controllo: Supervisor (Sup);

• modello del motore: Engine model (Eng);

• modello di trasmissione e di veicolo: Transmission and Vehicle Model (Veh); • modello dei sistemi ausiliari: Auxiliaries (Aux).

Fig. 3.29: modello Simulink

Come si può osservare dalla figura 3.29, per il passaggio dei segnali tra i vari sottosistemi è utilizzata una struttura a bus. Il nome riportato tra parentesi sta ad indicare il nome del file .m, nel quale, per ciascun sottosistema e per ciascuna applicazione, sono indicati i valori dei parametri che si trovano al loro interno.

Nel blocco Environment sono raccolte alcune costanti che riguardano l’ambiente in cui il motore si trova a lavorare, come i valori di pressione e temperatura.

Nel sottogruppo Auxiliaries sono simulati alcuni componenti, quali alternatore e motore elettrico di avviamento, di fondamentale importanza per il funzionamento di un motore. Una descrizione di questo blocco esula però dagli obiettivi di questa esposizione e non sarà affrontata.

Anche il sottogruppo Transmission and Vehicle Model non sarà esaminato, poiché il modello di veicolo e trasmissione non è abilitato nella modalità di esercizio prevalentemente utilizzata ed i suoi segnali sono esclusi dal resto del modello.

3.4.2.1. Il sottosistema di interfaccia con la parte hardware

Mediante questo blocco, il modello Simulink è collegato alle schede di input/output del simulatore, attraverso le quali può ricevere ed inviare segnali elettrici da e verso il mondo reale.

Fig. 3.30: sottosistema HIL I/O

Per collegare la simulazione real-time ai componenti reali, è necessaria l’introduzione di interfacce I/O nel modello: ciò avviene attraverso appositi blocchi Simulink, i cui nomi rispecchiano quelli delle unità hardware presenti sulle schede DS2210. Questi blocchi saranno poi tradotti dal sistema RTI nel codice C eseguito dalla scheda DS1005 e quindi alcune parti del codice serviranno per comunicare al microprocessore di interfacciarsi con le schede I/O.

Le variabili contenute all’interno del modello Simulink non sono grandezze elettriche, ma rappresentano le grandezze fisiche reali, come pressioni o temperature. Nasce quindi l’esigenza di convertire i valori dei segnali elettrici di input in grandezze fisiche e viceversa (condizionamento dei segnali). Sarebbe inutile, anche per la stessa centralina, conoscere quanto vale il segnale elettrico inviato dal potenziometro della farfalla, se non fosse nota la caratteristica che lo lega alla posizione. Per effettuare questa conversione, si fa ricorso a mappe, look-up table che riproducono le caratteristiche segnale elettrico – grandezza fisica di tutti i sensori.

Nella figura 3.31 è riportata, ad esempio, la look-up table impiegata in Simulink per la conversione della temperatura del fluido refrigerante, calcolata dal modello, in un valore di resistenza:

In figura 3.32 è mostrato, sempre per quanto riguarda la temperatura, il passaggio del segnale fisico al blocco di output del simulatore:

Fig. 3.32: condizionamento del segnale fisico di temperatura

Facendo ricorso a questo esempio per chiarire il modo attraverso il quale la ECU è in grado di ricevere segnali dal simulatore, il modello calcola una certa temperatura (HilOut_CoolantTemp) e la look-up table la converte in un valore di resistenza. Come descritto nel paragrafo 3.3.1.2, in base a tale valore è inviato un segnale digitale ad uno dei convertitori

D/R della scheda DS2210 per generare tra i due pin RESx+ e RESx- la resistenza voluta.

Considerando il caso degli input al simulatore, prendiamo in esame che cosa accade con i variatori di fase. La centralina invia alle valvole dei variatori un segnale PWM, che è trasmesso anche al modello attraverso la scheda DS2210 ed i blocchi riportati in figura 3.33. Nel modello, il segnale è prima convertito in angolo attuato ed è poi utilizzato per l’elaborazione delle variabili che realmente sono influenzate da questo valore.

Fig. 3.33: condizionamento dei segnali elettrici dei variatori di fase

Il valore di questo angolo deve inoltre essere inviato ai blocchi DS2210_APU_CAM, corrispondenti alla unità Camshaft Signal Generator (§ 3.3.1.2), per consentire la generazione del corretto segnale di posizione dell’albero a camme.

Fig. 3.34: utilizzo degli angoli attuati dai variatori di fase in output dal modello

3.4.2.2. Il sottosistema di controllo

Il supervisore gestisce le differenti modalità di funzionamento del modello, abilitando o meno differenti controllori, e permette di avviare o spegnere il motore.

Le transizioni tra i vari stati del motore, come la messa in moto, la condizione di minimo o quella di normale marcia, sono gestiti da macchine a stati realizzate in Matlab/Stateflow: nel modello sono presenti tre macchine a stati, che riguardano il sistema di accensione, la modalità manuale o quella in drive cycle.

Le possibilità offerte dal supervisore sono:

• modalità manuale (o dinamometro): il modello del motore è abilitato, mentre il veicolo è disabilitato. Essa è analoga al funzionamento di un motore sul freno dinamometrico di un banco prova. Attraverso due differenti tipi di controllo, possono essere scelte due condizioni di funzionamento: speed/pedal, nella quale la posizione del pedale dell’acceleratore è costante ed il motore è controllato ad una certa velocità obiettivo da un controllore PID che agisce sulla coppia del dinamometro, oppure speed/load, nella quale la coppia del dinamometro è costante ed il motore è controllato ad una certa velocità obiettivo da un controllore PID che opera sulla posizione del pedale.

• modalità drive cycle: sia il modello del motore che quello del veicolo sono abilitati ed un modello di pilota controlla la velocità del veicolo per portarla ad un valore obiettivo impostato. In questa modalità è possibile eseguire i diversi cicli disponibili, che sono FTP 75, ECE-EUDC, Highway ed US06.

Le seguenti figure mostrano la struttura del sistema nelle differenti modalità:

ECU

Controllore

Modello del motore

Posizione del pedale Carico Attuatori

Sensori

Velocità motore

Fig. 3.35: modalità manuale

ECU

Modello del pilota

Modello del motore Posizione del

pedale _{Velocità motore}

Attuatori Sensori Coppia erogata dal motore Modello di veicolo e trasmissione Posizione cambio

Posizione pedale freno Velocità veicolo

Fig. 3.36: modalità drive-cycle

3.4.2.3. Il modello del motore

Esso è stato sviluppato come un modello quasi stazionario, il cui comportamento è caratterizzato da mappe ottenute da prove al banco dei motori reali. La risposta in transitorio del modello è influenzata dalla simulazione della dinamica dei gas nei volumi presenti sia in aspirazione che allo scarico.

Questo modello è costituito da cinque blocchi:

• il sistema di aspirazione, in cui sono presenti il modello per il calcolo della portata di aria aspirata, quello della valvola per il recupero dei vapori di benzina (purge valve) e quello del plenum;

• il sistema di iniezione, il quale simula il comportamento degli iniettori, con un modello che tiene conto anche dell’effetto di wall wetting;

• i cilindri, nei quali sono calcolati gli indici di eccesso aria, la temperatura dei gas di scarico e la coppia erogata dal motore;

• il sistema di scarico, in cui si trovano i modelli dei polmoni posti nei collettori di scarico e dei catalizzatori;

Saranno adesso brevemente descritti i tre principali blocchi del modello, ossia il sistema di aspirazione, quello di iniezione ed i cilindri, illustrando il calcolo delle principali variabili di output che il modello deve generare.

3.4.2.3.1. Il sistema di aspirazione

In questo blocco si trovano i modelli della valvola a farfalla e del polmone di aspirazione. La principale variabile di ingresso del primo è costituita dalla posizione della farfalla, il cui valore è dato dai segnali elettrici provenienti dai potenziometri del componente reale.

Fig. 3.37: modello della valvola a farfalla

Nota la posizione effettiva (Pos) e le condizioni di temperatura a monte e di pressione sia a monte che a valle della farfalla (T_in, P_in e P_out), il blocco di figura 3.37 calcola una portata di aria in ingresso al polmone di aspirazione (W_out). I valori di temperatura e pressione a monte coincidono con quelli dell’ambiente da cui è aspirata l’aria, mentre quello di pressione a valle coincide con la pressione presente nel plenum.

Il sottoblocco del polmone è stato modellato come un sistema aperto a regime non stazionario, con una porta di ingresso ed una di uscita. Dalla prima entra la portata calcolata dal modello della farfalla, mentre in uscita si ha la portata in ingresso ai cilindri, determinata dai dati di una look-up table ricavati da caratterizzazioni dei motori al banco prova.

Wingresso motore

Wfarfalla

Polmone

Fig. 3.38: schema del modello di polmone

Uno dei principali output di questo sottoblocco è il valore di pressione all’interno del volume. Tale pressione influenza sia il calcolo della portata che passa attraverso la farfalla, sia la look-up table che fornisce la quantità di aria che entra nel motore. Appena nasce una differenza tra le due portate, la pressione varia fino a quando non viene raggiunto un equilibrio tra esse (assumendo che non sia raggiunta, nel modello della farfalla, la condizione di bloccaggio della portata).

3.4.2.3.2. Il sistema di iniezione

Il compito di questo blocco è quantificare la portata di combustibile iniettata, in base alle durate di iniezione comandate dalla centralina. Ricordando quanto detto a proposito delle unità

Injection Event Capture, nel modello sono noti i tempi di apertura degli iniettori, i quali possono

essere considerati proporzionali alla quantità di combustibile immessa nel collettore di aspirazione. Conoscendo perciò la caratteristica che lega la durata di iniezione alla portata iniettata, è possibile risalire a quest’ultima.

3.4.2.3.3. I cilindri

La velocità di rotazione dell’albero motore è utilizzata, in output dal modello, dalle unità hardware che si occupano della generazione dei segnali del sensore di giri e di quello di fase. Questi “generatori” hanno bisogno di un file .mat, nel quale è riportato l’andamento dei segnali nei 720° di durata di un ciclo. Chiaramente, è necessario che alle unità sia nota la velocità di rotazione, per poter trasformare in durate temporali le ascisse dei file .mat.

La velocità di rotazione è calcolata secondo l’equazione:

engine controllo ausiliari sistema

T T T

dt J

ω=

∫

nella quale , e sono rispettivamente la coppia erogata dal motore, quella richiesta dal sistema di controllo (dipendente dalla modalità di funzionamento, secondo quanto riportato nel paragrafo 3.4.2.2) e quella assorbita dagli ausiliari, mentre

engine

T T_controllo T_ausiliari

sistema

J è l’inerzia

equivalente del sistema.

La coppia erogata è valutata mediante alcune look-up table: attraverso due di esse, entrambe ottenute empiricamente, si ricavano il valore della coppia ottima e quello della coppia di attrito in funzione della velocità di rotazione e della portata di aria in ingresso al motore. La coppia ottima è poi moltiplicata per due rendimenti, ed , legati rispettivamente al valore dell’indice di eccesso aria λ con cui sta lavorando il modello ed alla differenza tra un angolo di accensione ottimo (ottenuto anch’esso da dati sperimentali) e quello attuato. Riassumendo, l’equazione per il calcolo di è:

lambda

η ηignition

engine

T

engine ottima lambda ignition attrito

T =T ⋅η ⋅η −T (3.3)

Oltre a quantificare la velocità di rotazione, questo blocco calcola il valore del rapporto aria-combustibile, definito mediante l’indice di eccesso aria λ. La relazione utilizzata è:

λ a _Φ s c m m =  ⋅  (3.4)

nella quale m_a è la portata di aria all’interno di un cilindro, m_c quella di combustibile iniettata e Φ_s è il valore del rapporto combustibile/aria stechiometrico. I valori così ottenuti saranno elaborati in output, trasformati in segnali elettrici ed inviati alla scheda elettronica responsabile della simulazione delle sonde lambda.