SIMBYKE - Auconel

SIMBYKE
Luigi Pantani
Auconel – R&D – Project Manager
1 - GENERALITA’
L’obbiettivo del progetto SIMBYKE è stato quello di
realizzare un sistema in grado di riprodurre il più possibile
le condizioni motore cui è sottoposta normalmente una
centralina moto in ambito racing, partendo da un concetto
semplice
di
“riproduzione
fedele”
di
quanto
precedentemente registrato o impostato, con funzionalità
automatica di misura delle principali attuazioni della
centralina.
L’architettura Hardware scelta è prevalentemente di
commercio, espandibile e versatile per consentire di
evolvere facilmente il sistema verso un simulatore di tipo
Closed-loop .
SIMBYKE
è rivolto ai tecnici del settore la cui
professionalità, però, non deve necessariamente risiedere
nell’abilità di utilizzo di un computer.
Si è pertanto posta l’enfasi sulla facilità di utilizzo,
sull’immediatezza dell’interfaccia grafica utente, sulla
intuitività dei comandi e degli indicatori.
La finestra di base dell’interfaccia grafica illustra tutti i
parametri di simulazione in modo comprensibile e senza
alcun sforzo di apprendimento da parte dell’utente finale.
Il numero dei comandi è ridotto al minimo e utilizza una
terminologia immediata e inequivocabile (PLAY / PAUSA /
STOP / LOAD / SAVE).
All’avvio della applicazione l’utente viene guidato
attraverso una serie di finestre e di pop-up, dall’ordine
predefinito, fino all’inizio della simulazione vera e propria.
Le varie scelte di configurazione che l’utente è chiamato
ad effettuare sono presentate con la massima chiarezza, a
partire dalla scelta di un modello ECU, passando
attraverso la visualizzazione (facoltativa) dei parametri
caratteristici dei principali sensori, alla scelta di un file di
play tra un insieme fissato, fino all’inizio della simulazione,
sia essa statica o dinamica secondo il file preselezionato.
E’ infine possibile salvare un file contenente un set di
valori impostati manualmente (un punto motore) e caricarlo
successivamente.
2 – USO E FINALITA’
Allo stato attuale, in ambito SuperByke ad esempio, lo
strumento descritto è utilizzato sostanzialmente per la
generazione di pattern di test (modificando tramite play file
i valori degli ingressi centralina nel tempo) per valutare il
comportamento di nuova strategia oppure di una modifica
significativa della stessa. Questo approccio consente di
fare un debug prima di metterla in moto e farla provare al
pilota.
Allo stesso modo è possibile anche la riproduzione tramite
CAN di un play-file contenente i segnali acquisiti
precedentemente in gara dal logger ECU via
CAN attraverso i sensori intelligenti, per analisi del
prodotto delle elaborazioni di nuove strategie i cui valori di
output vengono memorizzati nel logger per una successiva
analisi.
In generale, perciò, tale sistema sia allo stato attuale sia in
una sua successiva edizione/evoluzione rappresenta ed è
destinato a rappresentare in modo sempre più efficace un
importante
strumento il cui valore aggiunto è
evidentemente quello di debuggare il software e quindi le
strategie di centralina (riducendo i rischi di un impiego di
nuovi contenuti), verificare l'efficacia di eventuali
modifiche ed eventualmente consentire di percorrere altre
strade per la soluzione di un problema o lo sviluppo di
nuove prestazioni senza i costi di veicolo, pilota e pista
(affrontati solo a livello di prova generale quando il tutto è
stato scelto e sviluppato).
firmware realizzata su FPGA National è stato sviluppato in
ambiente LabView 8.2 National Instruments.
3 - ARCHITETTURA DEL SISTEMA
Dal punto di vista Hardware Il sistema è costituito da una
architettura commerciale “PXI” National Instruments cui è
stato aggiunto uno strato di condizionamento ad “hoc” che
rappresenta l’interfaccia verso la centralina. E’ stata anche
realizzata una scheda carichi (LoadBoard) anch’essa
mirata alla simulazione dei principali attuatori che la ECU
pilota.
3.1
FPGA
Il livello FPGA è quello che permette la generazione e la
misura dei segnali in frequenza più critici , a questo livello
vengono svolte le eleborazioni “time-critical” relative
soprattutto ai segnali CranckShafts e CamShafts. (Engine
Revolution and Phase sensors). Questi sensori, i cui
segnali sono sostanzialmente dei pattern pseudo-periodici
sono ottenuti mediante strutture dati vettoriali visitate
elemento per elemento con una frequenza idonea in
relazione diretta al numero di giri motore. Tipicamente il
sistema è in grado di lavorare su un range da 700 Hz a
oltre 20 KHz.
Esistono tre layers principali che costituiscono il sistema
Hw e che assolvono a precisi e separati compiti:
3.2
RT – HOST
La gestione dell’intera simulazione è ottenuta a questo
livello. Prima della simulazione la sequenza delle
operazioni che vengono eseguite è: Ricezione parametri
dei sensori veicolo in base alla configurazione scelta;
configurazione delle schede elettroniche di interfaccia e
degli stadi di condizionamento elettrico in accordo con gli
stadi elettronici della centralina; download dei parametri di
lavoro della FPGA. A questo punto il sistema entra in stato
di simulazione.
Il sistema implementa 4 task real-time parallele che si
occupano delle funzioni fondamentali di simulazione.
•
•
•
PC-HOST:
GUI,
operator’s
commands,
configuration and simulation data.
RT-HOST layer: signal management, general
system control, electric conditioning board runtime
configuration.
FPGA layer: input/output driving, critical
elaboration, time-critical signal generation.
Tutto il software, sia inerente l’interfaccia grafica a livello
pc-host , sia relativo al “Core Real Time”, sia la parte
1. Lettura grandezze motore e output nei
corrispondenti segnali elettrici [Scansione delle
strutture dati playfile].
2. Lettura grandezze motore e trasformazione nei
corrispondenti pacchetti CAN.
3. Lettura segnali e misura delle attuazioni ECU
4. Gestione delle interazioni utente dalla “main GUI”
e aggiornamento Display
3.3
PC-HOST
L’applicazione di livello PC permette all’utente la gestione
dell’ambiente di simulazione.
Per la confugurabilità il sistema utilizza un data-base ed
una applicazione server esterna con cui comunica che
permette di richiamare il set di sensori che il simulatore
deve impiegare. Il data-base e l’applicazione dedicata
permettono di memorizzare e modificare le caratteristiche
dei sensori rappresentandone anche l’andamento , a scopo
di verifica, su diagrami cartesiani.
Il simulatore, in sintesi, lavora con un “playfile” su cui
risiedono tutti i punti motore relativi ad un profilo
precedentemente registrato o creato a partire da dati di
base (i.e. instant pictures of the engineering values read by
every sensor connected to the ECU in a given time). Il
playfile viene preventivamente letto e messo in memoria
a bordo del processore RealTime (256 Mbyte memoria
esp. a 1GByte ). Ogni punto motore è trasformato
correttamente o nel segnale elettrico relativo o in un
predestinato pacchetto CAN mediante i parametri già
residenti che sono stati precedentemente scaricati all’avvio
dell’applicazione secondo la scelta eseguita. In ogni
momento l’utente può fermare o mettere in pausa
l’esecuzione di un playfile e intervenire manualmente
modificando qualsiasi variabile ingegneristica, rendere
operative le modifiche e poi eventualmente tornare ad
eseguire il play file.
E’ possibile inoltre salvare un numero qualsiasi di punti
motori e/o caricarli e metterli in esecuzione.
Le figure che seguono illustrano il pannello grafico
dell’ambiente di simulazione.
La tabella seguente descrive il panorama dei segnali
elettrici relativi ai sensori che il sistema è in grado di
simulare:
NTC PT1000
Sign.0-5000mV
Sign.0-5000mV
Sign.0-5000mV
Sign.0-5000mV
Sign.0-5000mV
Sign.0-5000mV
Sign.0-5000mV
Hall Effect
Pick Up
Temperature (Air,Water,Fuel, Oil etc..)
[deg/Ohm] [deg/mV]
Pressure (AirBox , Oil , Brake etc..)
[mbar/mV] [bar/mV] [mbar/V]
Gas (1,2,..n) [%/mV]
Throttle ( 1,2,..n) [%/mV]
Gyro (1,2,..n) [deg/sec/mV]
Suspention (1,2,..n) [mm/ mV]
Switches (1,2,..n) [bool]
Knock Amplitude (1) [bool] *Necessario
Hw esterno supplementare
Up to 5 PWM Output - Counter Frequency
40MHz(FPGA)
Smot , Scam Profili configurabili Counter
Frequency 40MHz (FPGA)
Il loop di generazione è in grado di riprodurre un profilo
motore a frequenza f=1KHz vale a dire che un
campionamento tipico di una centralina può essere
riprodotto fedelmente.
La costruzione dei segnali in frequenza (Hall Effect / Pick
up etc..) avviene con il clock della FPGA pari a 40MHz. Si
riescono a generare molto bene segnali giri-motore oltre
20000 RPM
e si generano segnali di fase con la
precisione di un decimo di grado.
4 - SEGNALI ELETTRICI DEL SIMULATORE E
CARATTERISTICHE DI STIMOLAZIONE
Lo schema rappresentato sotto fornisce una indicazione di
massima dei moduli hw sia commerciali che proprietari e
delle interconnessioni previste tra tali elementi costituenti il
simulatore e quelli esterni della centralina motore e delle
sue alimentazioni elettriche.
5 - SEGNALI ELETTRICI MISURATI AI CARICHI
DELLA CENTRALINA E CARATTERISTICHE DI
MISURA
Il sistema può essere dotato di un modulo di
condizionamento per la rilettura dei segnali di attuazione
della centralina sui carichi motore simulati dalla LoadBoard
per l’effettuazione di misure temporali. Questo modulo
implementa dei trigger a soglia e serve a rileggere i segnali
di attuazione come segnali digitali su cui eseguire le
seguenti tipiche misurazioni:
H-Bridge1/2
Injectors Ton
Ignition
Lambda Heater 1/2
PWMs
LowSideLoads
HighSideLoads
Misura Duty Cycle
Tempi di iniezione x 4
Anticipi di accensione x 4
Misura Duty Cycle
Misura Duty Cycle
Stati segnale
Stati segnale
La scheda di condizionamento in ingresso introduce un
max rise/fall-time di 3 µs. Per il resto la precisione sulla
lettura è estremamente buona. Sullo stesso ordine di
grandezza si trovano infatti le risoluzioni della misura.
6 - SIMULAZIONE NODI CAN
Il sistema come già accennato, è in grado, nella sua
configurazione minima (n. 1 scheda CAN su PXI con 2
porte High Speed), di inviare sino a un massimo di 20
pacchetti CAN periodici a max 10mS su un canale
rimanendo contemporaneamente in ascolto sull’altro
canale.E’ ovvio che l’impiego di ulteriori schede consente
di aumentare il numero di pacchetti e/o di gestire più linee
di comunicazione CAN diverse.
Il sistema è configurabile e permette all’utente di definire i
pacchetti e il loro formato in relazione alle grandezze
ingegneristiche contenute nel Play- File. Il risultato è un
sistema particolarmente flessibile in grado di produrre
pacchetti CAN in accordo alla definizione contenuta nei file
di configurazione.
Ciò che accade è che le grandezze di processo contenute
nel play file che hanno destinazione “CAN” vengono
impacchettate e correttamente veicolate con la periodicità
preconfigurata.
7 - CONCLUSIONE
Il sistema che è stato brevemente e sinteticamente
illustrato è il frutto di numerose applicazioni effettuate in
ambiti analoghi per esigenze diverse in contesti sia R&D
sia di Produzione.
E’ in continua evoluzione ed è componibile e
personalizzabile sulla base delle esigenze specifiche e
sulla base anche delle nuove funzionalità e prestazioni che
costantemente pensiamo implementiamo e collaudiamo.
Auconel si offre infatti, prevalentemente, come partner
operativo per condividere progetti , obbiettivi e risultati.
GLOSSARIO
FPGA: Field Programmable Gate Array
BIST: Built In Self Test
ECU: Engine Control Unit
Playfile: A pre-recorded set of engine points
CONTATTI
Auconel srl – Automazione e controlli elettronici
v.le Kennedy, 230 – 10040 Leinì (TO) – Italy (EU)
Tel . +39 011 9910306
Fax. +39 011 9910837
auconel@auconel.com
http://www.auconel.com
Luigi .Pantani - R&D - Project Manager
Tel . +39 011 9910306
Fax. +39 011 9910837
pantani@auconel.com

Download Report