Introduzione
Francesco Cozzi 7
Oggi sempre di più l’elettronica è un elemento fondamentale delle moderne
automobili ed incide in maniera importante su prestazioni, sicurezza e non ultimo i costi di
produzione e manutenzione. Si pensi ad esempio che in talune automobili esistono fino a tre
bus di comunicazione diversi per collegare tra loro le numerose centraline che controllano
tutte le funzionalità dell’auto: controllo del motore, ABS, stabilità, comfort, ecc...
Nel campo della diagnostica per auto un grosso problema è quello di costruire
strumenti automatici di diagnosi (scan tool) capaci di interfacciarsi con un elevato numero di
centraline diverse. Queste non raramente comunicano con l’esterno mediante protocolli di
comunicazione proprietari e anche nel caso di protocolli standard vi è la possibilità di optare
fra numerose possibilità.
Figura 0-1 Strumentazione per diagnosi auto
Una soluzione a questo problema consiste nell’utilizzo di scan tool riconfigurabili
capaci di adattarsi, di volta in volta, al protocollo richiesto. Questa politica è quella scelta da
BrainBee s.p.a., azienda di Parma attiva nel campo della progettazione di strumenti per la
diagnostica nel settore automotive. In particolare lo scan tool di BrainBee si basa su
un’architettura costituita essenzialmente da due parti:
• la prima è la parte di controllo e gestione dell’applicazione, ruolo svolto praticamente
da un MicroControllore;
Introduzione
Francesco Cozzi 8
• la seconda è l’interfaccia verso la centralina dell’auto da sottoporre a diagnosi;
questa è implementata da una FPGA la quale viene riconfigurata in maniera
opportuna in base al protocollo di comunicazione selezionato.
FPGA
TR.
Scan-Tool
µ
Figura 0-2 Scan-Tool
Questa tesi nasce da una collaborazione avviata fra la BrainBee S.p.a. ed il
Dipartimento di Ingegneria dell’Informazione (DII) con lo scopo di progettare ed
implementare un controllore per il protocollo di comunicazione CAN Bus. Questo controllore
è stato realizzato mediante un Linguaggio di Descrizione Hardware (VHDL), sintetizzato ed
implementato su FPGA Xilinx.
Nel primo capitolo si illustra lo stato dell’arte in relazione all’utilizzo del CAN Bus
nel settore automotive, focalizzando l’attenzione sulle diverse possibilità che si presentano in
questo ambito riguardo alle politiche di gestione delle centraline di controllo sulle
autovetture.
In seguito viene presentata una descrizione dettagliata del protocollo CAN Bus, delle
sue proprietà e specifiche.
Vengono poi analizzati gli strumenti progettuali di questo lavoro di tesi:
il VHDL, caratteristiche fondamentali del linguaggio;
le FPGA, architettura e proprietà.
In ultimo viene esposto in maniera esaustiva il progetto realizzato con le ipotesi
semplificative di lavoro, le simulazioni realizzate, i risultati e i possibili sviluppi futuri.
Un capitolo di conclusioni chiude questo lavoro.
1 Il Controller Area Network (CAN-Bus)
Capitolo 1 – Il Controller Area Network (CAN-Bus)
Francesco Cozzi 10
Il protocollo di comunicazione CAN-Bus è stato creato nella prima metà degli anni
’80 dalla Bosch per applicazioni automobilistiche ma col tempo per le sue caratteristiche di
affidabilità e prestazioni si è affermato sempre più come protocollo per reti di campo per
l’automazione industriale e nei più disparati settori: aerospaziale, navale, ferroviario.
Il CAN Bus [4][16] ha permesso di cambiare radicalmente la filosofia di progetto dei
nodi di controllo in tutti i settori dove è stato applicato. I primi sistemi di controllo
elettronico erano di tipo centralizzato dove un nodo di elaborazione centrale “main frame”
con una elevata capacità di calcolo era collegato ad attuatori e sensori. Inoltre compito del
nodo centrale era quello di elaborare tutte le politiche di controllo sul processo.
Naturalmente i collegamenti tra i vari dispositivi distribuiti sul processo e il “main frame”
erano complessi e qualsiasi modifica al sistema, come ad esempio l’applicazione di un nuovo
dispositivo, richiedeva grosse modifiche all’impianto. Questa realtà tecnologica era presente
fino a pochi anni fa, sia nei processi industriali che nei sistemi di controllo delle autovetture.
Riferendoci in particolare al settore automobilistico il “sistema” automobile era
suddiviso in numerosi sottosistemi autonomi e indipendenti, ognuno gestito da una propria
centralina (ECU: Electronic Control Unit).
Ad esempio l’ABS funzionava con un proprio sistema di controllo, così come il
controllo motore, il sistema di climatizzazione o la gestione del cambio automatico. Le
procedure di diagnosi per la rilevazione dei guasti erano senza dubbio più localizzate, poiché
limitate ai componenti del solo sistema in esame che non condivideva con altri alcun
dispositivo (per esempio i sensori di temperatura): si trattava in pratica di tanti sistemi chiusi
che non si scambiavano alcun tipo di informazione, spesso portando alla scelta obbligata di
sensori ridondanti.
Lo sviluppo dei microprocessori e la diminuzione del loro costo hanno permesso di
decentrare nei sensori e negli attuatori capacità di elaborazione, che possono essere
condivise da più controllori. La condivisione avviene collegando le diverse unità tra di loro,
tramite CAN Bus. In questo modo non è più necessario riutilizzare uno stesso elemento in
diversi apparati che non sono perciò più isolati tra loro.
Capitolo 1 – Il Controller Area Network (CAN-Bus)
Francesco Cozzi 11
Figura 1-1Esempio di rete CAN all'interno di un'autovettura
Questo metodo di distribuzione delle risorse ha portato alcuni vantaggi derivanti dalla
riduzione e semplificazione complessiva dei cablaggi e dall’eliminazione di hardware
ridondante nell’intero sistema.
In sostanza, in luogo di una serie di collegamenti analogici fra sensori e ECU troviamo
sensori intelligenti, capaci di trasformare le informazioni analogiche in digitali, che
dialogano con tutta la rete del “sistema” automobile. Di conseguenza le operazioni di
diagnosi dei guasti non potranno più avvenire nel modo tradizionale, ma necessiteranno di
sistemi più sofisticati in grado di dialogare con i “network” all’interno dell’auto.
II sistema di controllo che era centralizzato diventa ora con l’introduzione del CAN
Bus di tipo distribuito (DCS = Distributed Control System).
Capitolo 1 – Il Controller Area Network (CAN-Bus)
Francesco Cozzi 12
Figura 1-2 Centraline che gestiscono: Powertrain (iniezione, accensione, sonda Lambda), Transmission
(Controllo trazione, ASR, ESP), Cruise control (drive by wire), formano un network distribuito ad alta velocità
connesso con rete CAN.
Figura 1-3 Sensore intelligente sulla pinza freni, in grado di inviare informazioni su temperatura, usura,
pressione del circuito franante per ogni mozzo ruota.
Sempre nel caso specifico dell’elettronica di bordo delle autovetture analizziamo
quali sono sostanzialmente i settori in cui vengono applicate le linee CAN:
Capitolo 1 – Il Controller Area Network (CAN-Bus)
Francesco Cozzi 13
1. tra le centraline di controllo del sistema di motopropulsione: ABS, ESP, ASR,
ecc...;
2. tra elementi di carrozzeria e quelli di comfort: vetri elettrici, controllo sedili,
tettuccio apribile, ecc...;
3. tra i sistemi di comunicazione: telefonia, GPS, AUDIO-DVD, ecc... .
Nel primo campo e cioè nel collegamento tra centraline controllo motore, controllo
trazione (ASR) e controllo dispositivi di drive by wire, le linee CAN devono garantire una
velocità di trasmissione dati compresa tra i 125 Kbit/sec e 1 Mbit/sec, in modo da assicurare
una risposta in tempo reale di tutti dispositivi coinvolti nella comunicazione.
Figura 1-4 drive by wire
Nel secondo campo di applicazione il Controller Area Network deve garantire velocità
di trasmissione comprese tra 10 Kbit/sec e 100 Kbit/sec per collegare tra loro dispositivi
quali il controllo dell’illuminazione del veicolo, la regolazione elettrica con memoria della
posizione dei sedili, l’impianto di climatizzazione e strumenti di bordo con interfacce utente.
Nel terzo campo, la linea CAN deve operare con velocità comprese tra 50 Kbit/sec e
100 Kbit/sec per permettere la trasmissione di segnali ad un display di visualizzazione e la
ricezione dei comandi immessi dall’utente per azionare radio, telefono e sistema di
navigazione. Si noti che tali segnali sono relativi solo ai comandi di controllo poichè una rete
CAN non è adatta al trasporto di dati AUDIO o VIDEO.
La velocità [15][7] di trasmissione dei frame è comunque strettamente legata alla
lunghezza della rete. Se si usano velocità di 1Mbit/sec occorre avere una rete non più lunga
di 40 metri, se la velocità e di 500 Kbit/sec la rete deve essere al massimo di 100 metri, se la
Capitolo 1 – Il Controller Area Network (CAN-Bus)
Francesco Cozzi 14
velocità e di 250 Kbit/sec la lunghezza può salire fino a 200 metri, se invece e di 125
Kbit/sec si può arrivare a 500 metri. Ciascun bit infatti, deve propagarsi fino alle due
estremità della rete, in un tempo che sia inferiore alla durata del bit stesso, avendo perciò la
certezza, che tutti i nodi lo abbiano registrato.
Figura 1-5 Le due reti CAN High Speed e Low Speed di un autovettura sono connesse con un gateway che
permette lo scambio di informazioni.
1500
1000
100
10
5
100 1000 10000
Lungh.Bus
[m]
Data Rate
[Kbit/s]
Figura 1-6Il grafico mostra il legame tra la lunghezza del bus fisico e il data rate
La velocità di trasmissione (e perciò la lunghezza del bus) è fondamentale nella rete
CAN, dove non si utilizzano strutture master slave, ma viene impiegata una topologia a Bus
condiviso. Quindi ogni frame trasmesso è ricevuto da tutti i nodi collegati al bus. Mediante
Capitolo 1 – Il Controller Area Network (CAN-Bus)
Francesco Cozzi 15
poi opportune funzioni di filtraggio ogni nodo sarà capace di discriminare i frame di effettivo
interesse e quelli che non lo riguardano.
La diffusione e il successo del Controller Area Network sono anche dovuti alla
disponibilità di un consistente numero di dispositivi integrati non eccessivamente costosi, in
grado di svolgere tutte le funzioni necessarie per operare sul Bus. Alcuni di questi sono già
incorporati nei microcontrollori, politica seguita ad esempio da Motorola, Hitachi, Philps con
alcuni loro prodotti, altri invece funzionano solo da interfaccia tra Bus e microcontrollore.
2 Il protocollo CAN
Capitolo 2 - Il protocollo CAN
Francesco Cozzi 17
Il sistema CAN è costituito da un unico bus a due fili che abbraccia tutti i nodi
connessi in rete, fornendo loro un canale seriale molto veloce. I nodi non sono uniti con una
classica topologia punto-punto ma su un unico bus sul quale immettono o dal quale
prelevano i messaggi[45][47].
Process Bus
Drive
uC
Interf.
Sensor
uC
Interf.
Drive
uC
Interf.
Drive
uC
Interf.
Gateway CPU
Interface
Field Bus
Figura 2-1 Configurazione di un sistema CAN, Un tipico sistema CAN comprende diversi micro controllers per
l’interfacciamento con i sensori e gli attuatori ed una CPU per il controllo dell’intero sistema. La
comunicazione avviene principalmente fra la CPU ed i microcontrollori. La CPU è inoltre connessa ai livelli
più alti della gerarchia del controllo.
Richiamandosi al modello di riferimento ISO/OSI per le comunicazioni dati, il
protocollo CAN occupa i primi due livelli, cioè il livello fisico e il livello data link.
Quest’ultimo viene poi diviso dal protocollo CAN in due sottolivelli : LLC (Logical Link
Control), che gestisce lo scambio dei messaggi, e MAC (Media Access Control), che controlla
gli errori.
Capitolo 2 - Il protocollo CAN
Francesco Cozzi 18
Application Layer
Physical Signalling
(Bit –coding, -timing, -synchron.)
Physical Medium Attachment
(Transmitter/Receiver-Spec.)
Medium Dependent Interface
(Cable, Plug...)
Physical
Layer
Logical Link Control
Error -detection, -handling;
Control of data-flow;
Acceptance filtering.
Medium Access Control
Bit-Stuffing, Framing,
Arbitration
Data
Link
Layer
M
a
n
a
g
e
m
e
n
t
Process-Application
Layer
7
2
1
CAL,
CANopen (CiA)
DeviceNet
SDS (Honeywell)
etc ...
CAN
(ISO
11898)
Bosch
Figura 2-2 Il protocollo CAN Bus si occupa di descrivere i primi due livelli del modello ISO OSI
Il sistema CAN i dati sono trasmessi e ricevuti usando sequenze di bit (message
frames). I frames di messaggio trasportano i dati da un nodo trasmettitore ad uno o più nodi
ricevitori. Il pacchetto CAN è diviso in alcuni frames di cui i principali sono:
• SOF: Start of Frame
• ID: Identificatore
• DLC: Lunghezza campo dati in bytes
• DATI: Bytes di dati
• CRC: Cyclic Redundancy Check
E’ da notare che il il numero contenuto nel campo ID si riferisce univocamente al nodo
trasmettente. In sostanza cioè in ogni pacchetto non è specificato l’identificatore del nodo a
cui il pacchetto è destinato ma al contrario solo quello del nodo trasmittente. In ricezione poi
sarà un opportuno meccanismo di filtraggio che permetterà di discriminare i pacchetti utili
da quelli inutili.
Capitolo 2 - Il protocollo CAN
Francesco Cozzi 19
Il protocollo Standard CAN (v. 2.0A) supporta messaggi con identificatore di 11 bit;
Il protocollo Extended CAN (v. 2.0B) supporta sia identificatori ad 11 bit che identificatori a
29 bit. La maggior parte dei controllori 2.0A trasmettono e ricevono solo messaggi Standard
CAN, benché alcuni, noti come 2.0B passivi, possono ricevere messaggi Extended CAN
ignorandoli. I controllori 2.0B possono invece inviare e ricevere messaggi in entrambi i
formati.
L’identificatore unico determina inoltre anche la priorità del messaggio: più basso è
il valore numerico dell’identificatore, più alta è la sua priorità.
In situazioni dove due o più nodi tentano di trasmettere un messaggio nello stesso
istante, una tecnica di arbitraggio non-distruttivo garantisce che i messaggi siano inviati in
ordine di priorità e che nessun messaggio vada perso.
2.1 Il bus fisico
I due fili del bus sono tipicamente un doppino intrecciato (schermato oppure no). Può
essere usata anche una piattina (tipo quella telefonica), ma è più rumorosa e può essere più
suscettibile a fonti esterne di rumore.
Il doppino inoltre viene terminato alle estremità per eliminare le onde riflesse.
CAN_H
CAN_L
Node A
CAN_H
CAN_L
U
diff
v
t
=30cm
@ 1MHz
<
Node B Node C
El.Mag.
Interference
(EMI)
120Ω
surge impedance for
suppressing line reflections
120Ω
surge impedance for
suppressing line reflections
10...
100nF
62Ω
62Ω
Migliore
immunità
ai disturbi
Figura 2-3: Il doppino con terminatori per il bus fisico
Impedenza di carico per
eliminare le onde riflesse
Capitolo 2 - Il protocollo CAN
Francesco Cozzi 20
2.2 Robustezza
Un bus CAN si troverà ad operare in ambienti estremamente rumorosi e critici ed il
meccanismo di controllo dell’errore assicura che qualsiasi errore nella trasmissione venga
rilevato (vedi la sezione errori per maggiori dettagli).
-5V
-4V
-3V
0V
1,5V
2,5V
3,5V
7V
8V
9V
10V
11V
12V
t
CAN_H
CAN_L
recessive
dominant
Transmitter-
Signal
CAN_H
CAN_L
CAN_H
CAN_L
electric potential shift
caused by EMI
electric potential shift
caused by EMI
Figura 2-4: segnali di tipo differenziale
Inoltre la trasmissione dei segnali elettrici è fatta in modo differenziale per migliorare
l’immunità alle fonti di interferenza di tipo elettromagnetico (EMI).
Lo standard ISO11898 "raccomanda" che i chips di interfaccia siano progettati in
modo tale che la comunicazione possa continuare, seppur con un rapporto segnale/rumore
ridotto, anche se:
- uno dei due fili del bus è interrotto
- un filo o l'altro è in cortocircuito con l’alimentazione
- un filo o l'altro è in cortocircuito con la massa
Differenza di potenziale
causata da EMI
Differenza di potenziale
causata da EMI
Segnale del
Trasmetitore
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
