Si riporta in appendice la struttura generale del codice Labview implementato, con l’obbiettivo di fornire un quadro generale, evidenziando sia le parti alle quali sono state apportate modifiche sia nuove parti di codice introdotte.
Struttura del codice ad inizio lavoro
Il codice, come già sottolineato in precedenza, è sviluppato su tre livelli: FPGA, Real- Time ed host PC. Ogni livello si occupa della gestione di più task in parallelo. Il codice ereditato all’inizio del lavoro svolto, si sviluppava secondo i seguenti schemi a blocchi, riportati per i tre livelli di implementazione.
Figura A-1: schema a blocchi del codice FPGA
99
Figura A-3: schema a blocchi codice host PC
Per una descrizione più dettagliata dei singoli blocchi si rimanda ai lavori [1] ed [8].
Implementazione del codice a livello FPGA
L’implementazione degli algoritmi sviluppati ha portato ad una rivisitazione di molte parti di codice FPGA. Innanzi tutto le evoluzioni riguardanti la fasatura (capitolo 2) hanno portato alla modifica della parte di rilevazione della posizione angolare:
• Conteggio denti • Riconoscimento cava • Determinazione della fase corretta • Monitoraggio errori di conteggio • Determinazione dei tempi dente Nuovo algoritmo di
conteggio denti per far fronte a tipi di ruote foniche con doppia cava simmetrica
Nuovo algoritmo di
riconoscimento della
cava per far fronte a cave
di dimensione non
standard (da 1 a 3 denti mancanti)
Upgrade dell’algoritmo in maniera da eseguire il controllo di fase ad ogni ciclo motore e per renderlo compatibile
con i due nuovi
algoritmi di conteggio denti e riconoscimento cava
100
Anche l’introduzione di nuove tipologie di pegging (capitolo 3) ha portato all’introduzione di nuove parti di codice a livello FPGA, all’interno della sezione di calcolo delle grandezze indicating:
Per quanto riguarda il tracking delle attuazioni (capitolo 4) è stato necessario introdurre una parte di codice totalmente nuova per l’esecuzione dell’algoritmo e allo stesso tempo modificare parti di codice per far fronte alle necessità di filtraggio differenziato tra i canali di pressione e i canali attuazioni. (vedi paragrafo 4.6).
• Associazione del volume al singolo campione • Calcolo dei parametri indicating IMEP IMEPH … Recupero componente media Determinazione offset mediante algoritmo della politropica Campionamento segnale pressione collettore CHR max MFB Determinazione pressione collettore mediante sensore MAP Ricezione valore pressione di riferimento da CAN
101
L’introduzione di nuovi parametri e di nuovi algoritmi ha portato obbligatoriamente alla modifica della sezione di invio dei dati a real-time e di gestione delle configurazioni, proprio per far fronte alla spedizione dei nuovi parametri calcolati e nuovi settings ricevuti. La sezione di invio dei dati a real-time ha subito forti cambiamenti anche a causa della necessità di spedire i risultati al livello real-time al termine di ogni singolo ciclo motore relativamente ad ogni TDC, per far fronte alla spedizione dei dati CAN combustione per combustione (vedi paragrafo 5.3)
Implementazione del codice a livello Real Time
Qualsiasi modifica venga introdotta nel codice a livello FPGA implica obbligatoriamente una revisione, implementazione od aggiornamento del codice real-time, in quanto i nuovi dati calcolati o le nuove configurazioni necessarie devono transitare attraverso il real-time per poter raggiungere l’FPGA. Si evita la descrizione delle singole modifiche introdotte per ogni aggiornamento di configurazione o di dati aggiunti in FPGA, nonostante abbiano
• Associazione del volume al singolo campione • Calcolo dei parametri indicating • Determinazione
dei punti angolari di attraversamento soglia
Campionamento evitando il filtraggio solo per i canali di tipo attuazione, in funzione dei settings impostati dall’utente Introduzione, nel blocco
di conversione da tempo ad angolo, di un recupero dei ritardi differenziato per i canali di tipo
attuazione che non
102
richiesto sforzi di sviluppo e di debug, evidenziando solo le modifiche macroscopiche più importanti introdotte durante il lavoro svolto.
Gli sviluppi più importanti sono quelli relativi alla comunicazione dei dati verso il mondo esterno mediante protocolli standard, cioè CAN e XCP (capitoli 5 e 7). Per quanto riguarda invece il tracking attuazioni, in real-time è stata introdotta una nuova sezione all’interno del blocco di completamento dell’analisi combustione che si occupa dell’interpolazione dei valori di attraversamento soglia (paragrafo 4.4).
Implementazione del codice a livello host
Gran parte del lavoro svolto a livello host è stato scrivere codice che permettesse all’utente di interfacciarsi in maniera semplice ed intuitiva con le funzioni di visualizzazione dei dati e di setting dei parametri. Ovviamente ogni nuova funzionalità
Loop di gestione CAN 1 in lettura Loop di gestione CAN 0 in lettura e scrittura
Gestione dei trigger CAN Gestione della comunicazione XCP Gestione dei raster XCP per l’invio dati Scrittura dei
dati nei raster di misura XCP opportuni
Interpolazione per la determinazione dei parametri relativi all’algoritmo di actuation tracking
103
introdotta ha richiesto l’introduzione di modifiche al codice in maniera da gestire e visualizzare i nuovi dati prodotti, permettendone anche il salvataggio. Questa parte è già stata messa in evidenza nel capitolo 1.4.
In aggiunta è stato introdotto codice per consolidare la comunicazione ethernet tra host e real-time (e il ripristino della comunicazione in caso di errori), e per la gestione del salvataggio dei dati, introducendo la possibilità di gestire un buffer di dati pre-evento (vedi paragrafo 6.2). Oltre a questo sono state introdotte funzionalità utili all’utente per semplificare l’inizializzazione e l’avvio delle prove riducendo il rischio di errori di configurazione o mancate connessioni.
Overview dei codici host e real-time
Per completezza si riportano i block diagram dei VI (Virtual Instrument file) del codice host e real time (per motivi di riservatezza non viene riportato quello FPGA). Si può
< Consolidamento della comunicazione e del ripristino in caso di errori Buffer di memoria pre-evento < Ricerca automatica dell’hardware < Determinazione automatica tipologia ruota fonica < Visualizzatore dati offline < Creazione automatica A2L ed HEX file per comunicazione XCP Gestione intuitiva dei pop-up di configurazione e delle variabili scambiate Registrazione evoluta, con possibilità di impostare trigger esterni
104
intuitivamente capire la struttura a blocchi costituita da vari loop temporizzati, all’interno dei quali sono presenti ulteriori sub VIs contenenti gli algoritmi sviluppati (non si entrerà all’interno dei singoli subVI, sempre per motivi di riservatezza). Il quadrato bianco con bordo rosso in figura rappresenta le dimensioni dello schermo del PC.
Figura A-4: block diagram host main VI
106
BIBLIOGRAFIA
[1] Solieri L., tesi di dottorato: Sviluppo di algoritmi di analisi e diagnosi combustione
in tempo reale per motori endotermici alternativi, 2009
[2] Valbonetti M., tesi di dottorato: Sviluppo di sistemi per l’analisi della combustione
in tempo reale per motori endotermici alternativi, 2013
[3] ASAM, XCP Version 1.1, 2008, ASAM e. V.
[4] ASAM, ASAM MCD-2 MC (ASAP2 / A2L) Data Model for ECU Measurement and
Calibration, 2015, ASAM e. V.
[5] Heywood J. B., Internal Combustion Engine Fundamentals, 1989, McGraw Hill
[6] Ferrari G., Motori a Combustione Interna, 1992, Il Capitello
[7] Corti E., Moro D., Solieri L., 2008, Measurement Errors in Real-Time IMEP and
ROHR Evaluation, SAE 2008-01-0980
[8] Bovicelli P., tesi di laurea: Implementazione di una Piattaforma Software Modulare
per l’Analisi della Combustione, 2013
[9] Brown B. R., final year project: Combustion Data Acquisition and Analysis, Loughborough University