La fase di ricerca e rimozione degli errori
5.1. Introduzione
I problemi riscontrati durante questa fase possono essere suddivisi in tre categorie: • problemi di natura elettrica;
• problemi di modellazione; • problemi di sintonizzazione.
I primi riguardano anomalie dei segnali in ingresso ed in uscita dalle schede DS2210. I secondi sono relativi a non corrette modellazioni della parte software del simulatore. I terzi fanno riferimento alla messa a punto del sistema in termini di caratteristiche I/O (§ 3.4.2.1) di conversione da segnale fisico calcolato a segnale elettrico e viceversa.
La soluzione di molti problemi ha richiesto la realizzazione di varie simulazioni ed un attento esame delle funzioni diagnostiche per permettere l’identificazione delle cause di errore. Per non rendere però la trattazione eccessivamente laboriosa, saranno riportate soltanto le cause individuate e le correzioni apportate.
La maggior parte dei problemi affrontati riguardano l’applicazione M139, che è stata la prima ad essere implementata sul simulatore. Quindi, a meno che non sia diversamente specificato, sarà fatto riferimento ad essa. Nell’ultimo paragrafo sarà considerata solo questa applicazione, dal momento che problemi di altra natura sui modelli più recenti di F131Evo e F141 hanno reso impossibile una verifica ed una regolazione delle caratteristiche di conversione.
5.2. Problemi di natura elettrica
5.2.1. Il pedale dell’acceleratore
Un test è stato eseguito variando la posizione del pedale nel modello da zero a 100% con un certo passo ed acquisendo, ad ogni step, il valore della corrispondente variabile dalla centralina (wped_w). Da tale prova, sono emerse sensibili differenze tra le due posizioni, nonostante la coincidenza tra la caratteristica del sensore reale ed i dati della look-up table per la conversione della posizione del pedale in segnale elettrico (Fig. 5.1).
0 10 20 30 40 50 60 70 80 90 100 0 10 20 30 40 50 60 70 80 90 100 pos iz io ne pe da le ac qu is it a da ll a E C U %
posizione pedale comandata da modello %
caratteristica ottenuta caratteristica ideale
Fig. 5.1: esito della prima prova
La figura 5.2 mostra uno schema elettrico del sensore reale. I pin GND P1 e GND P2 sono le masse dei segnali inviati dai pin Segnale P1 e Segnale P2 dei due potenziometri.
Nel sistema HIL questo sensore è simulato. La posizione del pedale è convertita in due segnali di tensione, ciascuno dei quali simula un potenziometro. Queste tensioni sono poi trasmesse alla ECU da due unità hardware DAC (digital/analog converter) della scheda DS2210 (Fig. 5.3).
Fig. 5.3: unità DAC
Il pin DACx coincide con quello che, nel sensore reale, dà la misura del segnale di un potenziometro, mentre /DACx è la massa del segnale, utilizzata in sostituzione di GND.
Dopo una analisi dei segnali in output dalla scheda DS2210, la causa di questo problema è stata individuata negli errati valori di tensione nelle masse. Dopo aver apportato opportune modifiche, la stessa simulazione ha restituito i risultati riportati in figura 5.4. Da questa figura si può notare una migliore corrispondenza tra la caratteristica ideale e quella ottenuta nella prova.
0 10 20 30 40 50 60 70 80 90 100 0 10 20 30 40 50 60 70 80 90 100
posizione pedale comandata da modello %
p o si zi one peda le acqui si ta dal la E C U % caratteristica ideale caratteristica ottenuta
Fig. 5.4: esito della prova dopo la modifica
5.2.2. La temperatura del fluido refrigerante
Durante una simulazione di warm-up, sono stati monitorati il valore di temperatura elaborato dal modello e quello valutato dalla ECU in corrispondenza del segnale di output dal simulatore (tmotlin). Nonostante la caratteristica di conversione resistenza – temperatura fosse identica a
quella del sensore reale, i risultati della simulazione hanno evidenziato due principali problemi (Fig. 5.5). 0 20 40 60 80 100 120 140 160 180 200 20 40 60 80 100 120 140 tempo [s] te m per at ur e [ °C ] temperatura modello tmotlin ECU
Fig. 5.5: esito della prima prova
Il primo riguarda l’offset tra il valore calcolato dal modello e quanto letto dalla ECU. Il secondo è relativo alla dinamica di tmotlin, con gradienti anche di 20°C in un secondo non corrispondenti alla realtà (Fig. 5.6).
60 62 64 66 68 70 72 74 76 78 80 105 110 115 120 125 130 tempo [s] te m p er at u ra [ °C ] tmotlin
Fig. 5.6: particolare dell’andamento di tmotlin
La figura 5.7 riporta l’andamento delle due grandezze con il modello di warm-up disabilitato ed una temperatura del fluido refrigerante costante pari a 90°C.
0 20 40 60 80 100 120 140 160 180 200 85 90 95 100 105 110 115 120 tempo [s] te m p er at ur e [ °C ] temperatura modello tmotlin ECU
Fig. 5.7: esito della prova con il modello di warm-up disabilitato
Dopo aver effettuato alcune misure, le cause dei due problemi sono state individuate nei disturbi elettrici sul segnale di riferimento inviato dal convertitore D/R alla centralina. Nel simulatore, il pin di massa del sensore reale (GND in figura 5.8) è sostituito dal pin RESx- del convertitore.
Fig. 5.8: schema elettrico del sensore reale Fig. 5.9: convertitore D/R
Apportando modifiche alla massa, è stato possibile ridurre l’entità dei disturbi e le stesse simulazioni hanno fornito una migliore correlazione tra le due variabili (Figg. 5.10 e 5.11).
30 40 50 60 70 80 90 30 40 50 60 70 80 90 tempo [s] te m per a tur e [ °C ] temperatura modello tmotlin ECU
Fig. 5.10: esito della prova dopo la modifica
0 5 10 15 20 25 30 35 40 45 50 87.5 88 88.5 89 89.5 90 90.5 91 91.5 tempo [s] te m p e ra tur e [ °C ] temperatura modello tmotlin ECU
Fig. 5.11: esito della prova dopo la modifica con il modello di warm-up disabilitato
5.2.3. Le sonde lambda
Da alcune prove, è emerso un comportamento della scheda elettronica che simula le sonde lambda non corrispondente alla realtà. Tutti i test che saranno illustrati sono stati eseguiti nelle stesse condizioni di regime di rotazione e carico. Nelle prove in cui il titolo è controllato in anello chiuso, ossia con la ECU che fornisce correzioni nella quantità di combustibile iniettata per riportare il titolo al valore desiderato, l’indice di eccesso aria λ obiettivo è sempre pari a 1.
Dalla figura 5.12 è possibile osservare, in caso di anello chiuso, che i due valori di λ (indicati in figura con il nome della variabile della ECU, lamsoni) non hanno oscillazioni attorno a λ = 1 come realmente accade, ma rimangono circa costanti, con escursioni attorno a questo valore dell’ordine dello 0,4%. Inoltre, in tale prova, i valori di fr delle due bancate (fattori correttivi di tipo moltiplicativo della quantità di combustibile da iniettare per riportare il titolo al valore
obiettivo, calcolati dalla ECU in anello chiuso) si mantengono circa stabili intorno a 1,25, corrispondente al valore massimo che tale variabile può assumere (Fig. 5.13).
0 20 40 60 80 100 120 140 160 180 200 0.9995 1 1.0005 1.001 1.0015 1.002 1.0025 1.003 1.0035 1.004 1.0045 tempo [s] lamsoni bank 1 lamsoni bank 2
Fig. 5.12: andamento di λ in anello chiuso
0 20 40 60 80 100 120 140 160 180 200 1 1.05 1.1 1.15 1.2 1.25 1.3 1.35 tempo [s] fr bank 1 fr bank 2
Fig. 5.13: andamento di fr nella stessa simulazione
Successivamente, sono stati svolti altri due test in anello aperto, nei quali è stato modificato manualmente il valore del parametro FRKAP, un fattore moltiplicativo della quantità di benzina da iniettare: in un caso è stato imposto FRKAP = 0,8 (smagrimento del 20%) e nell’altro FRKAP = 1,2 (arricchimento del 20%).
0 20 40 60 80 100 120 140 160 180 200 1.002 1.0025 1.003 1.0035 1.004 1.0045 tempo [s] lamsoni bank 1 lamsoni bank 2
Fig. 5.14: andamento di λ in anello aperto con FRKAP = 0,8
0 20 40 60 80 100 120 140 160 180 200 0.997 0.9975 0.998 0.9985 0.999 0.9995 1 1.0005 1.001 tempo [s] lamsoni bank 1 lamsoni bank 2
Fig. 5.15: andamento di λ in anello aperto con FRKAP = 1,2
Dall’analisi delle figure 5.14 e 5.15, si può notare che non esiste alcuna risposta delle sonde lambda alla variazione del titolo, ma esse continuano a fornire alla centralina, in entrambi i casi, un segnale corrispondente al rapporto stechiometrico.
Accertato che, nel modello, i valori di λ calcolati seguivano correttamente le variazioni del titolo in base ai tempi di iniezione, si è resa necessaria una verifica del circuito della scheda elettronica. Dopo che sono state apportate modifiche sia a questo circuito che al modello, sono state ripetute le stesse prove.
Nelle figure 5.16 e 5.17, relative alla nuova prova in anello chiuso, si può osservare un comportamento più simile alla realtà, con oscillazioni delle variabili lamsoni ed fr attorno al valore obiettivo analoghe a quelle che si hanno in un veicolo reale.
0 5 10 15 20 25 30 35 40 45 0.95 1 1.05 1.1 tempo [s] lamsoni bank 1 lamsoni bank 2
Fig. 5.16: andamento di λ in anello chiuso dopo le modifiche
0 5 10 15 20 25 30 35 40 45 0.95 1 1.05 1.1 tempo [s] fr bank 1 fr bank 2
Fig. 5.17: andamento di fr nella stessa simulazione
Le figure 5.18 e 5.19 mostrano il comportamento del sistema in anello aperto e con valori di
FRKAP identici a quelli delle prove precedenti. In entrambi i casi, esiste una risposta delle sonde
alla variazione del titolo, con oscillazioni attorno a λ = 1,2 nel caso di FRKAP = 0,8 e attorno a λ = 0,8 con FRKAP = 1,2.
0 5 10 15 20 25 30 35 40 45 0.8 1 1.2 1.4 1.6 1.8 2 2.2 tempo [s] lamsoni bank 1 lamsoni bank 2
Fig. 5.18: andamento di λ in anello aperto dopo le modifiche con FRKAP = 0,8
0 5 10 15 20 25 30 35 40 45 0.72 0.74 0.76 0.78 0.8 0.82 0.84 0.86 0.88 0.9 tempo [s] lamsoni bank 1 lamsoni bank 2
Fig. 5.19: andamento di λ in anello aperto dopo le modifiche con FRKAP = 1,2
5.2.4. L’autoapprendimento della valvola a farfalla
Ogni volta che viene trasferito un nuovo software nella memoria della centralina di controllo, la ECU comanda il motore elettrico che movimenta la valvola a farfalla per autoapprenderne l’escursione di funzionamento e far fronte alle inevitabili differenze di produzione.
Nelle applicazioni F131Evo e F141 accadeva, durante questa fase di autoapprendimento, che la farfalla della bancata destra completava la procedura, mentre quella della bancata sinistra non era capace di fare altrettanto.
Durante l’autoapprendimento, la farfalla è mossa in step. Per osservare lo svolgimento di questa operazione, è possibile far riferimento alla variabile lrnstep_c, che è un contatore di questi passi. Se essa raggiunge il valore 11, significa che l’operazione ha avuto successo, altrimenti qualche condizione non ha permesso alla ECU di autoapprendere.
Nelle figure 5.20 e 5.21 sono riportate la variabile lrnstep_c e le tensioni rilevate dai potenziometri delle farfalle udkp1_w e udkp2_w.
12 13 14 15 16 17 18 19 20 0 2 4 6 8 10 12 tempo [s] lrnstep bank 1 lrnstep bank 2
Fig. 5.20: andamento di lrnstep_c durante un autoapprendimento
Come si può vedere, l’autoapprendimento per la bancata destra è completato, mentre per quella sinistra lrnstep_c si ferma al valore tre.
Dalla figura 5.22 si può osservare un andamento del segnale udkp1_w, per la farfalla sinistra, abbastanza disturbato durante la fase di autoapprendimento rispetto a quanto avviene realmente. Ciò ha indotto alla verifica dei collegamenti elettrici delle due farfalle.
12 13 14 15 16 17 18 19 20 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 tempo [s] tensi one [ V ] udkp 1 bank 1 udkp 1 bank 2 udkp 2 bank 1 udkp 2 bank 2
13 13.5 14 14.5 15 15.5 16 16.5 17 17.5 18 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 1 tempo [s] te nsi o ne [ V ] udkp 1 bank 2
Fig. 5.22: particolare dell’andamento di udkp1_w per la farfalla sinistra
Ciascuna ECU deve fornire, ad uno dei pin della propria farfalla, una tensione di 5V per l’alimentazione dei potenziometri (come accade per i sensori della posizione pedale, cfr. Fig. 5.2). Nel simulatore, questa tensione proveniva dalla stessa ECU per entrambi i componenti, causando problemi di interferenza e l’arresto dell’autoapprendimento. Il problema è stato risolto riproducendo la situazione reale, collegando cioè ciascuna farfalla con la propria centralina.
5.3. Problemi di modellazione
5.3.1. La sincronizzazione tra il sensore di giri e quelli di fase
Una diagnosi dell’unità di controllo riguarda l’allineamento tra il sensore di posizione dell’albero motore e quello dell’albero a camme.
In un veicolo reale, la ECU fa riferimento alla variabile wnwkwas_w per valutare la posizione del sensore di fase. Essa esprime, in gradi, la distanza tra il fianco discendente del secondo dente dopo i due denti mancanti nel sensore di giri e ciascuno dei quattro fianchi discendenti del segnale elettrico proveniente dal sensore di fase (Fig. 5.23).
Fig. 5.23: definizione delle variabili della ECU
I parametri WNWSPS_0, WNWSPS_1, WNWSPS_2 e WNWSPS_3 individuano la fasatura teorica. Per compensare le tolleranze di lavorazione delle ruote dei due sensori, esiste una funzione che autoapprende l’allineamento tra i due alberi: le variabili wnwspas_w e wnwi_ad_w sono rispettivamente il valore di posizione autoappreso e la differenza tra la fasatura teorica e quella effettiva, ossia tra wnwspas_w (il cui valore inizialmente coincide con quello di
WNWSPS) e wnwkwas_w. Tale differenza deve essere minore di pochi gradi e deve tendere a
diminuire, poiché il valore di wnwi_ad_w viene autoappreso nella variabile wnwspas_w. Se così non fosse, un bit assumerebbe il valore di 1 e sarebbe segnalata la presenza di un errore.
Nel simulatore, in tutte le tre applicazioni, era impostato questo errore sull’allineamento tra i due alberi, a causa di un non corretto posizionamento dei segnali memorizzati nei file .mat utilizzati dalla Angular Process Unit (§ 3.3.1.2).
Per modificare questi file, sono state fatte alcune acquisizioni su tutti i veicoli, con una speciale strumentazione che permetteva di visualizzare l’andamento dei segnali generati dai due
sensori. In base ai segnali acquisiti, sono stati ricostruiti tutti i file .mat dei sensori di fase, risolvendo il problema della sincronizzazione.
Nelle seguenti figure sono riportati gli andamenti dei segnali dei sensori di fase prima delle modifiche (in blu) e dopo le modifiche (in rosso). Si può osservare uno sfasamento tra i segnali di circa 10° nell’M139, di 30° nell’F131Evo sia sull’aspirazione che sullo scarico ed una di 23° sull’aspirazione e di 30° sullo scarico per l’F141.
Fig. 5.24: confronto tra i file .mat del sensore di fase per l’applicazione M139
Fig. 5.26: confronto tra i file .mat dei sensori di fase per l’applicazione F141
Queste acquisizioni hanno permesso di notare anche un errato posizionamento dei due denti mancanti della ruota del sensore di giri rispetto al caso reale. Perciò sono state apportate modifiche ai file .mat che descrivono l’andamento del segnale di posizione dell’albero motore.
285 290 295 300 305 -1 -0.8 -0.6 -0.4 -0.2 0 0.2 0.4 0.6 0.8 1
angolo albero motore [°]
am pi ez ze nor m al iz z a te nuovo segnale segnale originario
Fig. 5.27: confronto tra i file .mat del sensore di giri per l’applicazione M139
5.3.2. I variatori di fase
Attraverso alcune mappe, la ECU calcola un valore di posizione obiettivo per i variatori. Questi valori sono indicati nella centralina con le variabili wnweos per i variatori delle valvole di aspirazione e wnwass per quelli delle valvole di scarico. In base ad essi, è inviato agli attuatori un segnale PWM con un certo duty-cycle. Considerando i variatori in aspirazione, per valutare l’angolo di cui è stato attuato il variatore (wnwise), la ECU fa riferimento alla variabile wnwkwas (§ 5.3.1). Essendo il sensore solidale all’albero a camme, i valori di wnwkwas variano in proporzione all’attuazione. Una volta note le quattro posizioni dei fianchi discendenti con variatori non attuati (memorizzate con i nomi WNWSPS_0, WNWSPS_1, WNWSPS_2 e
WNWSPS_3), la ECU riesce pertanto a valutare l’entità dell’attuazione.
Nella centralina esiste una diagnosi sui variatori, secondo la quale è impostato un errore se la differenza tra valore obiettivo e valore attuato è maggiore di 12° per più di 2 secondi.
Durante l’esecuzione dei drive-cycle, i segnali PWM provenienti dalla centralina erano esclusi nel modello ed erano utilizzati, al loro posto, valori registrati durante un ciclo reale su vettura e memorizzati in una look-up table. Non essendoci perciò alcun collegamento tra gli obiettivi ed i dati registrati, era generato l’errore. Il problema è stato risolto modificando il modello ed utilizzando i segnali PWM di output della ECU.
Nella modalità manuale, l’inconveniente era legato ad un blocco impiegato nel modello Simulink: questo blocco (rate limiter, Fig. 5.29) limitava il fronte di salita del segnale, agendo da saturazione della derivata prima.
Fig. 5.29: conversione del segnale PWM in angolo attuato
In questo caso, l’errore era dovuto alla lenta traslazione del segnale generato dal sensore di fase in uscita dal simulatore: l’angolo attuato, acquisito dalla ECU, aveva un andamento molto diverso da quanto accade nella realtà (Fig. 5.30) e talvolta veniva superata per più di 2 secondi la soglia di 12° di differenza.
510 520 530 540 550 560 570 580 590 600 0 2 4 6 8 10 12 14 16 18 tempo [s] angol o [ °] wnwise wnweos
Fig. 5.30: andamento di angolo obiettivo ed angolo attuato in un veicolo reale
822 824 826 828 830 832 834 836 0 5 10 15 20 25 tempo [s] ango lo [ °] wnwise wnweos
Fig. 5.31: andamento di angolo obiettivo ed angolo attuato nel simulatore
Il problema è stato risolto eliminando il rate limiter e sostituendolo con un filtro passa basso del primo ordine. La costante di tempo del filtro è stata calcolata in base ad acquisizioni fatte su veicolo, per modellare in modo realistico la dinamica del sistema (Figg. 5.32 e 5.33).
130 135 140 145 150 155 2 3 4 5 6 7 8 9 10 11 tempo [s] angol o [ °] wnwise wnweos
Fig. 5.33: andamento di angolo obiettivo ed angolo attuato dopo la modifica
5.3.3. I messaggi CAN
Noti gli identificativi, le lunghezze e i valori dei messaggi, la scheda elettronica che simula il funzionamento della rete CAN genera automaticamente i segnali da trasmettere. Identificativi, valori e lunghezze devono essere definiti all’interno del modello Simulink, negli appositi blocchi I/O che si interfacciano con questa scheda.
Inizialmente nel modello era presente solamente il blocco dei messaggi provenienti dalla centralina di controllo della trasmissione. Quindi comparivano errori relativi all’assenza di comunicazione con le altre unità di controllo che inviano messaggi alla ECU. Per esempio, la centralina che controlla l’impianto frenante (nodo freno) calcola la velocità del veicolo mediante sensori che misurano la velocità di rotazione delle ruote. Questo valore è poi inviato, tramite CAN, alla centralina di controllo motore. Altri messaggi, che sono trasmessi sulla rete CAN alla ECU, sono la temperatura dell’aria esterna, misurata da un sensore posto su uno degli specchietti retrovisori, oppure il livello di combustibile nel serbatoio.
Una delle attività durante questa fase ha riguardato l’implementazione, per tutte e tre le applicazioni, del pacchetto di messaggi trasmessi dalle centraline presenti in vettura a quella di controllo motore.
Fig. 5.34: blocchi CAN implementati nel modello Simulink
5.3.4. Il controllo incrociato delle sonde lambda
Una diagnosi ha lo scopo di verificare se vi è corrispondenza tra i connettori delle sonde lambda ed i pin della ECU ai quali sono trasmessi i segnali. Potrebbe infatti accadere, per un errato montaggio, che il connettore della sonda sinistra sia collegato al pin nel quale dovrebbe giungere il segnale della sonda destra. Questo controllo è eseguito, dalla centralina, differenziando per qualche istante i tempi di iniezione delle due bancate e verificando se la corrispondente variazione dei valori di indice di eccesso aria λ misurati è in accordo o meno con i tempi di iniezione comandati.
Ricordando quanto detto nel capitolo 3, nell’applicazione M139 sono presenti due distinte variabili per indicare le durate di iniezione, ti_b1 per la bancata destra e ti_b2 per quella sinistra: esse dovranno essere utilizzate nel modello per calcolare due valori di λ. Anche nell’F131Evo abbiamo due valori diversi, una variabile (ti_b1) per la centralina master ed una (sempre chiamata ti_b1) per quella slave, da impiegare per il calcolo di due differenti valori di λ. Nell’F141, in ciascuna bancata, sono presenti una variabile ti_b1 per un gruppo di tre cilindri ed una ti_b2 per l’altro gruppo e nel modello dovranno essere perciò calcolati quattro valori distinti di λ.
L’unità Injection Event Capture (§ 3.3.1.2) del simulatore valuta, per ciascun cilindro, la durata dell’iniezione, intercettando i segnali elettrici che la ECU invia agli iniettori. Nel modello Simulink, è poi calcolato un tempo medio per ogni bancata, da cui si ricava la quantità di combustibile iniettata ed il valore di λ di ciascuna bancata.
Nelle applicazioni M139 e F131E vi era un errore nella selezione dei cilindri delle due bancate. Per ciascuna di esse, erano selezionati due cilindri della bancata destra e due della sinistra, perciò le medie dei tempi di iniezione erano identiche, causando l’errore durante il controllo incrociato delle sonde lambda. Nell’F141 si sono resi necessari interventi sul modello, poiché esso era concettualmente errato. Infatti, anziché quattro durate di iniezione e quattro
valori di λ, se ne avevano solo due, essendo calcolata una unica durata di iniezione media e quindi un solo λ per ogni bancata. Questo unico valore era poi utilizzato in output per simulare entrambe le sonde e, ai pin della ECU, era inviato lo stesso segnale per i due gruppi di tre cilindri della stessa bancata, provocando in questo modo l’errore.
Le modifiche hanno riguardato tre parti del modello:
• il blocco per il calcolo della quantità di combustibile, che è stato riorganizzato suddividendo il motore in gruppi di tre cilindri;
• il blocco che simula l’aspirazione, il quale calcolava una unica portata di aria per ogni bancata;
• il blocco in cui vengono calcolati gli indici di eccesso aria λ per permettere la valutazione di quattro differenti valori.
5.3.5. Gli eventi di accensione ed iniezione
Sia l’Injection Event Capture che la Spark Event Capture di una scheda DS2210 hanno in ingresso 6 linee, denominate INJ1...INJ6 e IGN1...IGN6 e collegate, attraverso le load card, ai pin di output della ECU. Nel modello, i cilindri sono numerati in base ai collegamenti con queste linee: ad esempio, se i pin relativi all’iniettore ed alla bobina del cilindro numero 8 fossero collegati alle linee INJ2 ed IGN2, ad esso sarebbe attribuito il numero 2.
Durante le prime simulazioni, accadeva che i valori letti nel modello per anticipo di accensione, durata ed inizio di iniezione, fossero notevolmente diversi da quelli della centralina. Le grandezze che facevano riferimento a questi dati non potevano perciò essere ritenute plausibili. Dopo una verifica dei collegamenti elettrici tra ECU e simulatore, la causa del problema è stata individuata nell’errato ordine di accensione. Tale ordine è necessario per stabilire la corretta posizione dei PMS dei vari cilindri e deve essere indicato nel modello tra le proprietà del blocco per la generazione del segnale del sensore di giri. Le finestre di cattura dell’evento (§ 3.3.1.2) dell’Injection Event Capture e della Spark Event Capture fanno riferimento al PMS di ciascun cilindro.
Consideriamo, ad esempio, un motore con quattro cilindri ed un ordine di accensione 1-4-2-3. Per evitare incomprensioni in seguito tra il numero dei cilindri reali e i numeri che sono loro assegnati nel modello, indichiamo i cilindri con lettere, da A (che corrisponde al cilindro 1) a D (che corrisponde al 4). Quindi l’ordine di accensione, con questa assunzione, diviene A-D-B-C. Prendendo come riferimento il PMS del cilindro A, quello del cilindro D sarà 180°, quello del cilindro B 360° e quello del cilindro C 540° dopo il riferimento. Se il collegamento elettrico tra i pin della ECU e le linee INJ ed IGN riproducesse l’ordine di accensione, cioè:
Cilindro reale Linea INJ Linea IGN Numero assegnato al cilindro nel modello
Cil. A INJ1 IGN1 Cil. 1 Cil. D INJ2 IGN2 Cil. 2 Cil. B INJ3 IGN3 Cil. 3 Cil. C INJ4 IGN4 Cil. 4
risulterebbe che, inserendo nel modello lo stesso ordine di accensione reale (ossia 1-4-2-3), le finestre di cattura sarebbero aperte con l’ordine A-C-D-B anziché A-D-B-C.
Il problema nel simulatore era causato da tale motivo e, conseguentemente, le finestre di cattura erano aperte in modo errato sui vari cilindri. Questo problema è stato risolto modificando opportunamente tutti gli ordini di accensione.
5.3.6. Il modello di warm-up
Dopo uno studio svolto sul blocco di warm-up originariamente presente nel modello, sono stati rilevati i seguenti aspetti negativi:
• errati valori calcolati di potenza termica introdotta dalla combustione: il modello si basava sull’utilizzo del potere calorifico inferiore per valutare questa potenza, ma non vi era alcuna correlazione tra i dati elaborati e quelli sperimentali;
• impiego di un coefficiente costante di rilascio calore verso il fluido refrigerante: si ipotizzava che una certa percentuale (pari al valore di questo coefficiente) della potenza introdotta dalla combustione fosse ceduta al fluido refrigerante e ne andasse ad aumentare la temperatura;
• crescita della temperatura durante la fase di riscaldamento non corrispondente alla realtà; • assenza del contributo dovuto alle ventole;
• impossibilità di simulare guasti del termostato;
• errato valore di temperatura inviato al pin della ECU cui corrisponde il segnale della variabile tka: in un veicolo reale, esso proviene da un sensore posto subito dopo il termostato e prima del radiatore, mentre nel modello era inviato alla ECU il valore di temperatura calcolato in uscita dal radiatore.
Per risolvere questi problemi, è stato deciso di modificare il blocco.
Nel nuovo modello di warm-up (Fig. 5.35) si è voluto mantenere l’impostazione di quello originario, cioè un modello basato sul concetto di rilascio del calore per la valutazione della potenza termica trasferita al fluido refrigerante.
Fig. 5.35: nuovo modello di warm-up
Il modello è diviso in sei sottogruppi, Potenza termica, Radiatore, Portata fluido
refrigerante, Termostato, tmot e tka (a questi ultimi due, nei quali sono elaborati i segnali di
output, è stato assegnato lo stesso nome usato dalla ECU per designare i valori di temperatura misurati dai sensori). Gli input del modello sono la velocità di rotazione del motore (omega), la posizione della valvola a farfalla (throttle_position), la velocità del veicolo (vehicle_speed), lo stato delle ventole (fan_status) ed un vettore che indica se c’è stata o meno iniezione nei cilindri (Inj_flag).
Per quanto riguarda la variabile fan_status, nel modello sono utilizzati gli stessi segnali inviati alle ventole dalla ECU per comandarne l’attuazione. Essendoci un collegamento tra unità hardware Bit I/O ed i pin che trasmettono questi segnali, è stato possibile inserire in input al modello due nuove variabili ed attribuire loro il valore uno o zero, a seconda che sia richiesto o meno l’intervento (Fig. 5.36).
Fig. 5.36: interfaccia software per i segnali elettrici inviati dalla ECU alle ventole
Nel sottogruppo Potenza termica sono state create tre look-up table che restituiscono, in funzione della velocità di rotazione del motore e della posizione della valvola a farfalla, la potenza termica introdotta dalla combustione, il coefficiente di rilascio del calore verso il fluido refrigerante ed il coefficiente di rilascio del calore per convezione ed irraggiamento. Queste tabelle sono state ricavate da dati sperimentali dei motori reali.
Dal prodotto dei coefficienti di rilascio e della potenza introdotta dal combustibile sono calcolate due potenze termiche (Qdot_tmot e Qdot_tka), una relativa al fluido refrigerante circolante nell’impianto ed una che va ad aumentare, quando il termostato è ancora chiuso, la temperatura del fluido che si trova tra la valvola termostatica ed il radiatore. Nel calcolo di queste due potenze è inoltre considerato il numero di cilindri in cui si è verificata l’iniezione. Se essa avvenisse solamente in qualche cilindro, la potenza termica introdotta dalla combustione sarebbe minore e nel modello si tiene conto di ciò moltiplicando le due potenze per il rapporto tra i cilindri in cui è avvenuta l’iniezione ed il numero di cilindri totali.
Fig. 5.37: sottogruppo Potenza termica
Qdot_tmot e Qdot_tka sono poi utilizzati per il calcolo delle due temperature, secondo le
relazioni:
_ _
_
Qdot tmot Qdot rad
tmot dt MC tmot − =
∫
(5.1) _ _ Qdot tka tka dt MC tka =∫
(5.2)I valori di MC_tmot e di MC_tka sono ottenuti da look-up table in funzione della velocità di rotazione del motore: i dati inseriti nelle tabelle sono stati ricavati da una serie di acquisizioni di warm-up sul veicolo a differenti regimi di rotazione, in modo da riprodurre quanto realmente accade.
L’equazione (5.2) è valida solamente durante le fasi in cui il termostato è ancora chiuso. Appena esso apre, l’uscita del blocco tka assume lo stesso valore di tmot (Fig. 5.39), con un filtro passa-basso per simulare la dinamica di salita del segnale al valore di regime. La costante di tempo con cui è riprodotta questa salita è stata ottenuta dalle stesse acquisizioni ed è funzione della velocità di rotazione del motore.
Fig. 5.38: sottogruppo tmot
Fig. 5.39: sottogruppo tka
Nel sottogruppo Termostato (Fig. 5.40), è calcolato lo stato di apertura del termostato (A_stat), in accordo alla relazione ricavata da [26]:
_ min _ _ max _ min tmot Tstat A stat Tstat Tstat − = − (5.3)
dove è la temperatura alla quale comincia ad aprire il termostato, mentre
è la temperatura alla quale il termostato è completamente aperto. _ min
Tstat
_ max
Tstat
In questo sottogruppo, è possibile simulare un guasto del termostato modificando il valore della costante Fault termostato. Può essere impostata una posizione permanente di apertura oppure di chiusura mediante la costante Posizione termostato.
L’uscita del blocco Portata fluido refrigerante (Fig. 5.41) coincide con la portata che circola nel radiatore ed è data dal prodotto tra lo stato di apertura del termostato e la portata che si avrebbe in condizioni di piena apertura dello stesso.
Fig. 5.41: sottogruppo Portata fluido refrigerante
Nel blocco Radiatore (Fig. 5.42), è calcolata, in funzione della velocità del veicolo e dello
stato delle ventole, la potenza termica estratta al fluido refrigerante , che è utilizzata
per il calcolo della temperatura del fluido refrigerante nel blocco tmot. _
Qdot rad
Fig. 5.42: sottogruppo Radiatore
Per il calcolo di questa potenza è utilizzata la seguente equazione:
(
)
_ _ _ _ _ ( _
Qdot rad =A rad h rad⋅ +h rad fan ⋅ tmot T ambient− ) (5.4)
I coefficienti di scambio termico del radiatore e dipendono dalla portata di
fluido refrigerante e dalla portata di aria che attraversano il radiatore. Nel caso di , la
portata di aria è generata dal movimento del veicolo e quindi è funzione della velocità della
vettura, mentre nel caso di dipende dallo stato delle ventole e dalla portata di aria
che esse sono in grado di convogliare. è la superficie di scambio del radiatore, mentre
è la temperatura dell’aria ambiente. _
h rad h rad_ _ fan
_ h rad _ _ h rad fan _ A rad _ T ambient
In questo blocco è presente una logica di attivazione (Fig. 5.43). Il suo scopo è assegnare, alla variabile di output, il valore calcolato con l’equazione (5.4) oppure zero qualora la velocità del veicolo fosse tale e le ventole non fossero attive oppure la valvola termostatica fosse chiusa.
Fig. 5.43: logica di attivazione del blocco Radiatore
In figura 5.44 è mostrato un confronto tra due simulazioni eseguite con il nuovo modello e con quello originale nelle stesse condizioni di funzionamento motore. Il tempo per l’apertura del termostato è aumentato di circa 100 secondi, riproducendo in modo più esatto ciò che accade nel veicolo reale. Anche l’andamento di tka è più simile a quello reale.
5.4. Problemi di sintonizzazione
Dopo aver risolto i problemi di tipo elettrico e di modellazione, dall’esame di alcune simulazioni sono state rilevate differenze tra i valori delle variabili all’interno del modello e quelli delle corrispondenti variabili della ECU. Queste differenze potevano essere attribuite alle caratteristiche di input/output per la conversione delle grandezze fisiche calcolate in segnali elettrici e viceversa.
Utilizzando infatti un numero limitato di punti nelle look-up table e le caratteristiche reali dei sensori, possono sorgere due problemi: in primo luogo, una possibile fonte di imprecisione può essere l’interpolazione eseguita dal microprocessore della scheda DS1005 in corrispondenza di una ascissa diversa da quelle indicate per la costruzione delle tabelle; in secondo luogo, disturbi elettrici, anche di modesta entità, presenti nei cavi di collegamento tra la ECU e la scheda DS2210 possono alterare l’ampiezza di un segnale corretto, inviando alle schede I/O del simulatore oppure alla centralina di controllo un segnale leggermente diverso.
La soluzione che è stata individuata consiste nell’infittimento dei punti utilizzati per la costruzione delle look-up table e nell’utilizzo di nuove caratteristiche, non più identiche a quelle dei sensori reali, ma calcolate con la procedura che sarà descritta nel paragrafo 5.4.2. Per questo motivo, sono state realizzate due procedure automatiche, una per la verifica delle caratteristiche ed una per la loro eventuale rimappatura nel caso in cui la verifica ne evidenzi la necessità.
Entrambe le prove sono state realizzate attraverso tre script Python ed una interfaccia grafica, o layout, creata con ControlDesk (§ 4.3). Lo scopo del layout è avviare il test ed inizializzare il collegamento con la ECU per acquisire da essa le variabili opportune. Uno degli script è associato a questo layout e permette di gestirne gli “eventi”, ossia le interazioni dell’utente con gli strumenti del layout. Una serie di righe di questo script sono eseguite in corrispondenza di una certa azione. Attraverso gli eventi è possibile, ad esempio, avviare una prova semplicemente premendo un tasto nel layout. Un altro script permette di aprire la comunicazione con la centralina, mentre il terzo script definisce lo specifico test.
La struttura di questo layout e dello script di eventi è identica per tutti i test nei quali vengono acquisite variabili dalla centralina. Una descrizione più dettagliata di entrambi e dello script per il collegamento con la ECU sarà data nel prossimo capitolo.
5.4.1. Verifica dei dati di input/output
Nonostante l’impiego di questo test abbia riguardato sinora solo l’applicazione M139, lo script è già stato predisposto anche per le altre applicazioni.
Il programma Python che realizza la verifica è un modulo (§ 4.2.1.5), verifica_io.py, ed è importato dal layout attraverso lo strumento in figura 5.45.
Fig. 5.45: tasto del layout per l’avvio della verifica
I seguenti estratti dello script di eventi mostrano il meccanismo attraverso il quale è avviato il test. Nella prima riga è importato il modulo, mentre nella seconda è definita una associazione tra l’evento Click ed un tasto, al quale è stato assegnato il nome AVVIA_TEST, che si trova nel
layout (avente il nome layout_verifica_io).
import verifica_io
def On_Instrumentation_layout_verifica_io _AVVIA_TEST_Click():
software_selezionato = sel_box_soft_1.ActiveItem.Text calibrazione_selezionata = sel_box_calib_1.ActiveItem.Text
verifica_io.test_verifica_io(fold,software_selezionato,calibrazione_selezionata)
Nell’ultima riga è eseguita la funzione presente nel modulo mediante la notazione punto (§ 4.2.1.5) e ad essa sono passati in input i parametri specificati nella sua definizione. La variabile
fold corrisponde al nome dell’applicazione selezionata nel layout (“M139”, “F131Evo” o
“F141”).
Le prossime righe di programma appartengono al file verifica_io.py. Il principale parametro di ingresso dello script è vettura, al quale è associata la variabile fold. In base ad essa, sono scelte le liste di variabili da monitorare durante il test, sia del modello che della ECU:
def test_verifica_io(vettura,soft,cal): ... if vettura == "M139": lista_var_test = lista_var_m139 lista_nmot_test = lista_nmot_m139 var_modello_test=elenco_var_modello_m139 istanze_modello_test=elenco_istanze_modello_m139
elif vettura == "F131Evo":
lista_var_test_m = lista_var_f131_master lista_var_test_s = lista_var_f131_slave
lista_nmot_test = lista_nmot_f131 var_modello_test=elenco_var_modello_f131_master+elenco_var_modello_f131_slave istanze_modello_test=elenco_istanze_modello_f131_master+elenco_istanze_modello_f131_slave elif vettura == "F141": lista_var_test_m = lista_var_f141_master lista_var_test_s = lista_var_f141_slave lista_var_test = lista_var_test_m+lista_var_test_s lista_nmot_test = lista_nmot_f141 var_modello_test=elenco_var_modello_f141_master+elenco_var_modello_f141_slave istanze_modello_test=elenco_istanze_modello_f141_master+elenco_istanze_modello_f141_slave
Alcune righe dello script selezionano direttamente la modalità di funzionamento (speed/pedal) e comandano le azioni di “key-on” e “crank” mediante il modulo rtplib.
Nel programma sono definite due liste, una che contiene i regimi di rotazione da indagare (lista_nmot_test), mentre nell’altra sono presenti le posizioni del pedale da zero a 100% con uno step di 5% (lista_pedale).
Il test è realizzato fissando un preciso regime di rotazione del motore ed impostando tutte le posizioni del pedale nella lista. Raggiunta la posizione di 100%, essa è portata nuovamente a zero, viene variata la velocità di rotazione ed il ciclo del pedale da zero a 100% è eseguito nuovamente fino a quando non è stata esaminata tutta la lista lista_nmot_test.
Per ogni coppia di valori (posizione pedale, velocità di rotazione), sono acquisite dal modello tutte le variabili delle quali si vuole monitorare la caratteristica I/O, mentre dalla ECU sono acquisite le corrispondenti variabili. Alcune di esse sono la stessa posizione del pedale, l’apertura della farfalla, la portata di aria calcolata e la temperatura del fluido refrigerante.
Per monitorare il comportamento del simulatore, sono presenti altre variabili che non necessitano della conversione in una look-up table, come le durate di iniezione (da cui dipende il consumo di combustibile calcolato nel modello) e l’anticipo di accensione.
Inoltre, non essendo possibile una acquisizione contemporanea dal modello e dalla centralina, lo script è stato realizzato per fare una doppia acquisizione delle variabili del modello, intervallate da quella delle variabili della ECU. Successivamente è calcolato un valore medio tra le due acquisizioni del modello. Durante lo svolgimento della prova, i valori acquisiti sono automaticamente riportati in un documento Excel.
Di seguito è mostrato il blocco principale che esegue la verifica:
while i<len(lista_nmot_test): nmot.Write(lista_nmot_test[i]) time.sleep(5) j = 0 while j<len(lista_pedale): pedal.Write(lista_pedale[j]) time.sleep(2) acquisizione_dati_modello(istanze_modello_test,lista_valori_modello_old)
val = connessione_ecu.interfaccia.GetOnlineValue() acquisizione_dati_modello(istanze_modello_test,lista_valori_modello_new) elaborazione_dati(vettura,var_modello_test,lista_var_test,val,lista_valori_ECU,wessot) media_modello(lista_valori_modello_old,lista_valori_modello_new,lista_valori_modello) scrivi_valori_excel(lista_valori_ECU,lista_valori_modello,doc,k) j = j+1 k = k+1 i = i+1 k = k+1
Alla fine della prova, per tutte le variabili, è calcolato un errore relativo ε:
ECU modello ECU 100 valore valore ε valore − = ⋅ (5.5)
Tutti gli errori sono poi riportati in un foglio di lavoro dello stesso documento Excel e le caselle contenenti un errore superiore al 5% sono evidenziate in rosso. Nelle figure 5.46 e 5.47 è mostrato il report realizzato durante una prova.
Fig. 5.47: elaborazione dei dati acquisiti durante la verifica
5.4.2. Mappatura delle caratteristiche di input/output
Le uniche differenze tra il layout di questa prova ed il precedente riguardano la presenza di uno strumento per la selezione del componente da esaminare ed il diverso modulo importato dal tasto per l’avvio.
Fig. 5.48: strumenti per la selezione del componente da esaminare e l’avvio del test
Nel modulo, è sfruttata la presenza di un blocco del modello che permette di sostituire i valori dei segnali elettrici calcolati (Oride_In) con un valore che può essere impostato manualmente (Oride_Val, Fig. 5.49).
Fig. 5.49: blocco Simulink per la modifica dei segnali calcolati
L’idea che sta alla base di questa procedura è sovrascrivere il segnale elettrico di output del modello con un valore noto e costante e quindi leggere dalla ECU il valore della corrispondente variabile. Considerando, ad esempio, la caratteristica del pedale, con questa prova si vuole imporre un certo valore di tensione in uscita dal modello ed acquisire il valore della variabile che indica, nella centralina, la posizione del pedale (wped_w). In questo modo, impostando una serie di valori compresi tra quello minimo e quello massimo del segnale elettrico, può essere ricostruita la caratteristica.
I parametri di input del programma sono due, l’applicazione ed il componente, che dipendono dalle selezioni effettuate prima di avviare la prova.
Il programma è articolato con una serie di condizioni if...elif basate sul nome del
componente. In seguito, attraverso un ciclo while, sono impostati di volta in volta i valori dei
segnali elettrici presenti in una lista e per ciascuno di essi è acquisito dalla ECU il valore assunto dalla variabile corrispondente. In realtà, per tenere conto di eventuali disturbi, vengono eseguite più acquisizioni (comando GetOnlineValue) a distanza di 5 secondi l’una dall’altra e ne viene calcolata la media: tmp = connessione_ecu.interfaccia.GetOnlineValue() time.sleep(5) tmp_1 = connessione_ecu.interfaccia.GetOnlineValue() time.sleep(5) tmp_2 = connessione_ecu.interfaccia.GetOnlineValue() time.sleep(5) tmp_3 = connessione_ecu.interfaccia.GetOnlineValue() time.sleep(5) tmp_4 = connessione_ecu.interfaccia.GetOnlineValue() valori[i] = (tmp[1][0]+tmp_1[1][0]+tmp_2[1][0]+tmp_3[1][0]+tmp_4[1][0])/5
Il programma realizza, durante lo svolgimento della prova, un documento Excel contenente i nuovi dati da inserire nelle look-up table del modello.
5.4.3. Risultati delle prove
L’utilizzo del test di verifica ha evidenziato la necessità di modificare sia le caratteristiche di output del pedale e della temperatura del fluido refrigerante, che la caratteristica portata iniettata – durata di iniezione.
Per il pedale, nella figura 5.50 è mostrato un confronto tra la posizione letta dalla ECU e quella comandata dal modello dopo la modifica: la correlazione tra il comportamento ideale e quello reale è notevolmente migliorata rispetto alla stessa acquisizione fatta precedentemente alla modifica (Fig. 5.4). 0 10 20 30 40 50 60 70 80 90 100 0 10 20 30 40 50 60 70 80 90 100
posizione pedale comandata da modello %
pos iz ione pedal e ac qui s it a d a ll a E C U % caratteristica ideale caratteristica ottenuta
Fig. 5.50: correlazione tra la posizione del pedale comandata dal modello e quella acquisita dalla ECU dopo la modifica
Nella figura 5.51 è riportato un confronto tra la nuova e la vecchia caratteristica tensione – posizione pedale. 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 posizione pedale [%] tensi one pot enzi o m e tr o 1 pe dal e [ V ] caratteristica originaria nuova caratteristica
Fig. 5.51: confronto tra le caratteristiche tensione in output – posizione pedale prima e dopo la modifica
Per quanto riguarda gli iniettori, oltre alle differenze tra il consumo calcolato nel modello e quello stimato dalla ECU evidenziate dai test di verifica, alcune simulazioni, eseguite con il controllo lambda disabilitato, hanno mostrato una tendenza del motore a lavorare magro (Fig. 5.52). 0 5 10 15 20 25 30 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2 tempo [s] lamsoni bank 1 lamsoni bank 2
Fig. 5.52: andamento di λ in anello aperto
Sulla base dei dati raccolti durante le prove, è stata fatta una modifica del coefficiente angolare della retta portata – durata. Nella figura 5.53, per ciascuna coppia di valori (posizione pedale, velocità di rotazione), è mostrato l’errore relativo ε (eq. 5.5) tra il consumo stimato in centralina e quello calcolato dal modello, sia prima che dopo la modifica della caratteristica. L’errore relativo medio è diminuito da 13,86% a 0,62%.
80010001250150017502000 2500 3000 3500 4000 4500 5000 5500 6000 -20 -10 0 10 20 30 40
vel rot motore [rpm]
e rro re re la ti v o %
caratteristica iniettori originaria caratteristica iniettori modificata
Fig. 5.53: confronto tra gli errori relativi ε del consumo di combustibile prima e dopo la modifica della caratteristica
Nella figura 5.54 si può osservare l’andamento dei valori dell’indice di eccesso aria, ottenuto nelle stesse condizioni motore della simulazione precedente e con controllo disabilitato. Adesso l’oscillazione del segnale è attorno al valore stechiometrico anziché attorno a 1.1.
5 10 15 20 25 30 0.92 0.94 0.96 0.98 1 1.02 1.04 1.06 1.08 1.1 tempo [s] lamsoni bank 1 lamsoni bank 2
Fig. 5.54: andamento di λ in anello aperto dopo la modifica della caratteristica
Nella figura 5.55 è riportato l’andamento temporale della temperatura del fluido refrigerante acquisita dalla ECU e di quella elaborata nel modello dopo la modifica della caratteristica. Anche in questo caso è possibile osservare un sensibile miglioramento della corrispondenza tra le due rispetto al caso precedente (Fig. 5.10).
30 40 50 60 70 80 90 30 40 50 60 70 80 90 tempo [s] te m p er a tur e [ °C ] temperatura modello tmotlin ECU
Fig. 5.55: confronto tra gli andamenti di temperatura calcolata dal modello e quella acquisita dalla ECU dopo la modifica
