1. Vehicle Network Toolbox™
L’utilizzo di VNT™ per l’implementazione
e la simulazione di una CAN
(Controller Area Network)
Antonio Mangiardi
2. Cosa tratteremo…
• Comunicazione in sistemi di automazione e
automotive
• I Bus di campo
• Il protocollo CAN
• Vehicle Network Toolbox
- Panoramica del tool
- Capacità del tool
- Utilizzo e funzionamento
3. La comunicazione nei sistemi di
automazione / automotive
• I sistemi tradizionali sono realizzati con-
nettendo dispositivi periferici, che control-
lano le varie parti di un processo, diretta-
mente a una unità centrale. La comunica-
zione è realizzata tramite collegamenti del
tipo punto-punto.
• Una soluzione più efficiente è quella di
connettere tutti i componenti sfruttando
un bus e gestire la comunicazione tramite
opportune implementazioni.
4. Il perché di una FieldBus Network
• L’elevato numero di cablaggi, la bassa flessibilità e un onerosa
manutenzione dei sistemi tradizionali con l’aumentare delle esigenze ha
spinto nella ricerca di altre soluzioni.
• L’utilizzo di Fieldbus Network offre grandi vantaggi:
Cablaggio meno complesso e meno ingombrante (si utilizza in genere
un Twisted Pair )
Tempi di installazione minori e semplicità di ampliamento
Miglioramento dei servizi che il sistema è in grado di fornire
all’utilizzatore:
Immunità agli errori, diagnostica …
5. Lo standard CAN
• CAN (Controller Area Network)
Nasce nel 1986, ad opera della Robert Bosch
GmbH su richiesta della Mercedes, al fine di
ridurre il cablaggio tra le varie apparecchiature
che iniziavano ad affollare gli autoveicoli.
Oggi viene utilizzato grazie alle sue proprietà, in
vari ambiti: dalla robotica alla domotica, dalla
elettronica marina alle macchine agricole nonché
in ambito medicale proprio grazie alla sicurezza
e all’affidabilità del protocollo.
6. Lo standard CAN
• Il protocollo CAN dall’86 a oggi ha subito
alcune variazioni.
• Oggi si fa uso dell’ultima versione ossia
CAN 2.0 rilasciata nel 1991, suddivisa in
part A e part B. (CAN 2.0 A e CAN 2.0 B)
Vediamo ora le peculiarità
7. Lo standard CAN
• Semplicità di cablaggio ed espansione: è possibile aggiungere o
rimuovere nodi (periferiche) con grande semplicità, grazie al tipo di cavo e
grazie al fatto che il CAN è MESSAGE ORIENTED e non ADDRESS ORIENTED
• Tempi di risposta rigidi: grazie a mirati artefici, si riducono le perdite di
tempo
• Immunità ai disturbi *
• Elevata Affidabilità: ogni nodo si accorge da solo di eventuali errori e
provvede alla ritrasmissione senza intervento del software
• Confinamento degli Errori: ogni nodo è in grado di autodiagnosticare
problemi e autoescludersi dal bus
• Priorità dei messaggi: la priorità è intrinseca al messaggio ed è legata alla
struttura del messaggio stesso. Il Bus implementa una WIRED-AND
( 1 && 0 = 0 lo zero è dominante)
• Protocollo Multimaster: ogni nodo può prendere il controllo del bus e gli
altri ascoltano; nel caso in cui più nodi prendano il controllo del bus, vince
chi ha identificatore più basso ossia a più alta priorità.
9. Lo standard CAN
• Tipi di messaggi “FRAME”:
1. - DATA FRAME
2. - REMOTE FRAME
3. - ERROR FRAME
4. - OVERLOAD FRAME
5. - INTERFRAME SPACE
(non è proprio un frame)
10. Lo standard CAN
Data Frame: é la struttura tramite la quale i nodi inviano l’informazione
SoF Arbitration Control DATA CRC ACK EoF
Start of Frame: unico bit dominante (0)
Arbitration: identificatore a 11 bit + RTR identificatore rtr (remote trasmission request)
Control : 6 bit che contengono l’informazione
della lunghezza dei dati in arrivo res1 res0 DL3 DL2 DL1 DL0
e due bit riservati *
DATA : ha lunghezza variabile da 0 a 8 Byte, è il dato vero e proprio
CRC (cyclic redundancy check ): contiene un codice che viene calcolato per ogni data frame, il
suo valore in 15 bit tiene conto del valore dei precedenti bit. Il nodo ricevente calcola a sua
volta, in base al data field, il CRC corrispondente il quale deve corrispondere a quello del
nodo trasmittente. Il CRC è seguito da un bit recessivo CRC Del.
detto CRC delimiter, calcolato dal nodo e non da software.
ACK : acknowledgment (riconoscimento) è composto da 2 bit uno ACK slot e ACK delimiter,
sono entrambi trasmessi recessive (1), tutti i nodi interessati al messaggio trasmettono a loro
volta un bit dominante (0) il che significa per il nodo ACK slot (1) ACK delimiter (1)
trasmittente che il messaggio è stato ricevuto *
End of Frame : consiste in 7 bit recessivi.
11. Lo standard CAN
• Interframe: non è un vero e proprio frame, pre-
cede i data frame e remote frame e viene inviato
dall’ultimo nodo che ha trasmesso.
È composto da 2 campi:
Intermission Bus idle
• Intermission: consiste di 3 bit recessivi (1)
• Bus idle: di lunghezza arbitraria
nel caso di Error Passive* tra i due campi si interpone un terzo campo
detto Suspend Trasmission. Una stazione nello stato di Error Passive,
trasmette l’intermission seguito da 8 bit recessivi prima di trasmettere un
nuovo frame o liberare il bus.
intermission Suspend trasm. Bus idle
12. Lo standard CAN
• Remote Frame
Il remote frame è strutturato in maniera quasi identica
al Data Frame: la differenza tra i due sta nell’ ID field (il
bit RTR assume valore recessivo, per questo ha priorità
minore*) e nel fatto che non possiede il data field
SoF ID con RTR = 1 Control CRC ACK EoF
Viene inviato da un nodo che necessiti di un dato. Il
tipo di dato desiderato viene specificato nell’ ID field. Il
nodo interessato risponderà trasmettendo un Data
Frame con lo stesso ID e contenente l’informazione
richiesta nel campo data field ovviamente.
13. Lo standard CAN
• Error frame: viene inviato da un nodo che rileva
un errore in un Data frame o in un Remote frame
ed è composto da due campi:
Error Flag Error delimiter
• Error flag: è costituito 6 bit che possono essere
dominanti o recessivi a seconda dello stato in cui
si trova il nodo.
• Error delimiter: consiste nell’invio di 8 bit
recessivi
In questo caso, viene violata la regola del bit stuffing
14. Lo standard CAN
• Overload Frame
viene inviato da un nodo in una delle seguenti
condizioni:
o Un nodo che rileva di essere “busy”
è ‘indaffarato’: occorre più tempo per processare i dati prima di riceverne
altri e non può quindi ricevere correttamente il frame successivo.
o Ricezione di un bit dominante in una fase di interframe:
essendo un Interframe costituito da bit tutti recessivi, il bit dominante
viene interpretato come la condizione di overload di un altro nodo, cui
rispondere con un Overload Frame.
Non possono essere inviati più di due overload frame consecutivi da
parte dello stesso nodo, inoltre i nuovi chip non prevedono la
possibilità di inviare questo tipo di frame che restano una
prerogativa dei controller obsoleti.
15. Lo standard CAN
Differenze sostanziali tra CAN 2.0 A e 2.0 B:
• Tutto quello che è stato detto sino ad ora riguarda
lo standard 2.0 A ed è valido anche per il 2.0 B.
• La differenza tra i due sta nella struttura del data
frame e remote frame:
SoF 11 bit ID RTR r1 r0 D L DATA 0 – 8 Byte EoF
• Nello standard 2.0 B l’identificativo è composto da
29 bit in particolare suddiviso in Base Id 11 bit e in
Extension Id 18 bit separati da 2 bit: SRR e IDE
SoF 11 bit ID SRR IDE 18 bit Id RTR r1 r0 DL DATA 0 – 8 Byte EoF
_ è settato a 1 in modo da dare precedenza ai messaggi standard
SRR
Il bit IDE sta per Identifier Extension Bit (settato a 1 anch’esso)
16. Lo standard CAN
La gestione degli errori
Il processo di segnalazione errori si articola in 5 fasi:
• Un nodo rileva un errore (in trasmissione o ricezione)
• Invia immediatamente un Error Frame
• Il messaggio incriminato viene ignorato da tutti i nodi
• Viene aggiornato lo stato del nodo
• Il messaggio viene ritrasmesso, competendo
eventualmente con altri
17. Lo standard CAN
• Un errore può essere rilevato in 5 modi, tre a livello messaggio e due a
livello del singolo bit
I. Stuff error: ogni 5 bit dello stesso segno viene modificato il sesto bit
(polarità opposta), questo è il bit stuffing. La regola dello stuffing viene
violata durante un error frame. Se viene rilevata una sequenza di 6 bit
uguali, viene inviato subito un error frame.
II. Bit error : ogni nodo in trasmissione monitora il bus per verificare la
corrispondenza, se viene rilevato un bit diverso da quello trasmesso
verrà segnalato un errore (non succede nella perdita di arbitraggio,
quindi non durante la trasmissione dell’ ID field)
III. CRC error: il nodo ricevente confronta il CRC ricostruito con quello
ricevuto, se non corrispondono viene inviato un messaggio di errore
IV. Frame error: qualora sia violata la struttura di un frame, si ha un frame
error
V. Ack error: qualora durante la trasmissione dell’Ack slot nessun nodo
risponde con un bit dominante, viene trasmesso un messaggio di errore
18. Lo standard CAN
Confinamento degli errori
L’autodiagnosi dei nodi avviene controllando il
valore di due contatori
Trasmit Error Count “TEC”
Receive Error Count “REC”
In pratica il valore dei due contatori viene
incrementato di 1 o di 8 a seconda del tipo di
errore che si verifica e viene decrementato di
1 se le cose vanno bene.
19. Lo standard CAN
Funziona ma
(TEC >255)||(REC>255) probabilmente
ha dei
problemi…
Il nodo si auto
esclude dal bus.
*Riabilitazione:
manda messaggi
Di 11 bit recessivi
per 128 volte
Nessuno dei due Counter ha superato il valore 127
il nodo è nelle piene funzionalità
20. Lo standard CAN
• L’alta affidabilità deriva proprio da questa politica
di controllo e gestione degli errori
• È stato calcolato che con una rete CAN che
viaggia a 1 Mbps, utilizzata al 50%, con messaggi
lunghi mediamente 80 bit, abbiamo una
probabilità residua di non individuare un
messaggio corrotto di circa 410 7 messaggi/ora.
• Avremo un guasto non diagnosticato ogni 1000
anni, nel caso di un utilizzo 8 ore al giorno per
365 giorni
21. Lo standard CAN
Sincronizzazione e temporizzazioni
• Il CAN supporta velocità di trasmissione sino ad
1 Mbps (con collegamenti non superiori a 40 m)
• Considerando che il clock non viene trasmesso,
ogni periferica deve ricostruirlo da sola.
• Esistono delle tecniche per cui i nodi riconoscono
e memorizzano la frequenza e poi sincronizzano
la fase del ck interno col nodo trasmittente.
22. Lo standard CAN
• Un primo tipo di sincronizzazione avviene allo SoB: Hard
Syncronization
• Un secondo tipo di sincronizzazione sfrutta le transizioni di bit
nel bus e il bit stuffing: Soft Syncronization
23. Lo standard CAN
• Ogni bit trasmesso può essere pensato come
composto da vari segmenti temporali
• Durante la risincronizzazione Seg1 e Seg2
possono essere modificati in base alle esigenze
del caso
24. Lo standard CAN
• Vari standard definiscono parametri su velocità,
tipo di collegamenti e connettori ed altri para-
metri non specificati dalla Bosch. Ad esempio:
• L’ISO 11898 per High Speed Applications
• Il SAE J1939 per autobus e veicoli pesanti
27. Vehicle Network Toolbox
• Collegando direttamente Matlab alla rete CAN del
veicolo, elimina la necessità di strumenti aggiun-
tivi per la connessione e crea un ambiente per
l’attività di test, verifica e analisi di una rete CAN.
• Contiene:
Funzioni Matlab per trasmissione e ricezione
Blocchi CAN per la creazione di modelli Simulink
Funzioni specifiche per la semplificazione della
codifica/decodifica di messaggi CAN
Filtraggio e registrazione di messaggi
28. Vehicle Network Toolbox
• Cosa possiamo fare:
Collegarsi a dispositivi CAN
Utilizzare dispositivi supportati *
Comunicare tra Matlab e Bus CAN
Simulare la comunicazione CAN
Visualizzare la comunicazione CAN
29. Vehicle Network Toolbox
• VNT permette dunque la connessione con dispositivi
CAN ed utilizzando un set di funzioni predefinite, si
possono trasmettere, ricevere, registrare ed analizzare
messaggi CAN (anche ritrasmettere messaggi registrati
precedentemente).
• Nella libreria Simulink sono presenti blocchi che
permettono la creazione di modelli per la simulazione
di traffico CAN o la connessione live a una rete CAN
• Con CAN Tool è possibile inoltre visualizzare tramite un
interfaccia user-friendly tutti i messaggi di un nodo
preselezionato.
VNT è un “condotto” tra MatLab e CAN
30. Vehicle Network
Toolbox
• Procedura di Trasmissione:
Crazione di un canale:
nome = canChannel ( ‘venditore’ , ’dispositivo’ , num)
Per avere informazioni sui dispositivi installati
sul PC si esegue il seguente comando:
info = canHWInfo
Vengono così visualizzate tutte le informazioni
sugli hardware installati nel proprio PC.
31. Vehicle Network Toolbox
Proprietà di un canale
Dopo aver creato il canale:
nome = canChannel ( ‘venditore’ , ’dispositivo’ , num)
• viene visualizzato un ”sommario” del canale creato:
Channel Parameters: Bus Speed is 500000.
Bus Status is 'N/A'.
Transceiver name is 'CANpiggy 251mag (Highspeed)'.
Serial Number of this device is 24811.
Initialization access is allowed.
No database is attached.
Status: Offline - Waiting for START.
0 messages available to RECEIVE.
0 messages transmitted since last start.
0 messages received since last start.
Filter History: Standard ID Filter: Allow All | Extended ID Filter: Allow All.
32. General Settings:
BusStatus = 'N/A‘
Vehicle Network Database = []
InitializationAccess = 1
MessageReceivedFcn = []
Toolbox MessageReceivedFcnCount = 1
MessagesAvailable = 0
MessagesReceived = 0
MessagesTransmitted = 0
ReceiveErrorCount = 0
Tramite il comando: Running = 0
SilentMode = 0
TransmitErrorCount = 0
get(nomeCanale) Device Settings:
Device = 'CANcaseXL 1‘
DeviceChannelIndex = 1
DeviceSerialNumber = 248110
vengono visualizzate DeviceVendor = 'Vector‘
Transceiver Settings:
tutte le proprietà del TransceiverName = 'CANpiggy 251mag ‘
TransceiverState = 16
canale che vediamo
Bit Timing Settings:
qui a fianco BusSpeed = 500000
SJW = 1
TSEG1 = 4
TSEG2 = 3
NumOfSamples = 1
33. Vehicle Network Toolbox
Per configurare alcune proprietà fondamentali, esiste una funzione apposita
configBusSpeed (nomeCanale, Velocità)
La velocità è espressa in bit/sec quindi ad esempio se devo settare la velocità a 500 Kbps, il
valore Velocità deve essere pari a 500000
configBusSpeed (nomeCanale, Velocità, SJW, tseg1, tseg2, NumberOfSamples)
consente di settare sia la velocità che il bit timing per la sincronizzazione.
SJW specifica la larghezza massima (nel tempo) che è possibile aggiungere al tseg1 (in un
trasmettitore più lento), o sottrarre tseg2 (in un trasmettitore veloce) per recuperare durante
ricezione di un messaggio.
34. Vehicle Network Toolbox
Con il comando:
start (nomeCanale)
Si mette “on line” il canale
chiamando il canale vengono infatti visualizzate tutte le proprietà del canale,
se andiamo a vedere il campo ‘STATUS’ sarà configurato ‘online’
Si può utilizzare un data base, caricandolo in Matlab tramite il comando:
db = canDatabase('filename.dbc‘)
Un data base contiene messaggi e definizioni di segnali, questo ci consente di
non dover manipolare byte grezzi.
35. Vehicle Network Toolbox
Creare un messaggio:
nomeMessaggio = canMessage(ID,Formato,Data Lenght)
nomeMessaggio =
can.Message handle ID: è l’identificativo da assegnare
Package: can
Formato: definisce il formato EXTENDED o
Properties:
ID: 500 STANDARD rispettivamente true o false
Extended: 0
Name: '' Data Lenght: è la lunghezza del dato che,
Database: [] come definito dallo standard, può variare da
Error: 0 0 a 8 Byte (il valore va definito con un intero
Remote: 0 che indica proprio il numero di byte del dato)
Timestamp: 0
Data: [0 0 0 0 0 0 0 0]
Signals: []
Methods, Events, Superclasses
36. Vehicle Network Toolbox
Pack di un messaggio
pack (nomeMsg, Val, start bit, dimensioni, ‘codifica’ )
nomeMessaggio = nome: è il nome del messaggio
can.Message handle
Package: can Valore : è il dato vero e proprio
Start Bit : è lo start bit, i valori accettati
Properties:
ID: 500 vanno da 0 a 63
Extended: 0 Dimensioni : un valore che va da 1 a 64 (bit),
Name: ''
che definisce le dimensioni del segnale
Database: []
Error: 0 Codifica il campo può assumere due
Remote: 0 valori: ‘LittleEndian’ o ‘BigEndian’
Timestamp: 0
ex:
Data: [xx xx 0 0 0 0 0 0]
se devo immagazzinare un esadecimale 0x0123
Signals: [] Little endian Big endian
|0x23|0x01| |0x01|0x23|
Methods, Events, Superclasses
37. Vehicle Network Toolbox
Trasmissione di un messaggio
transmit (nomeCanale, nomeMessaggio)
Chiamando il canale viene visualizzato il sommario che risulterà cambiato
nei seguenti campi:
…
Status: Online.
1 messages available to RECEIVE.
1 messages transmitted since last start.
0 messages received since last start.
…
38. Abbiamo altro da trasmettere..
Il workflow
ci mostra
come fare..
Andiamo
Se abbiamo finito col canale in uso, lo a vedere
disconnettiamo tramite il comando:
la
stop(nomeCanale) ricezione..
39. Vehicle Network
Toolbox
In ricezione i primi 3 passaggi
sono identici alla trasmissione:
• Creazione canale:
nomeCanale = canChannel ( ‘venditore’ , ’dispositivo’ , num)
• Configurazione proprietà
canale:
configBusSpeed (nomeCanale, Velocità)
• Avvio canale:
start (nomeCanale)
(utilizzo o meno del database)
40. Vehicle Network Toolbox
• Se abbiamo trasmesso un messaggio dal
canale X, tutti gli altri canali creati e attivi,
visualizzeranno nello status i seguenti campi:
…
Status : Online.
1 messages available to RECEIVE.
0 messages transmitted since last start.
0 messages received since last start.
…
41. Vehicle Network Toolbox
Ricezione di un messaggio
Tramite il comando:
msgIn = receive (nomeCanale, numMessaggiRichiesti)
MatLab, restituisce un array di messaggi ricevuti sul canale CAN indicato.
Il numero di messaggi restituiti è minore uguale a numMessaggiRichiesti.
Se il numero di messaggi disponibili è minore del valore indicato, la funzione
restituisce soltanto quelli disponibili, se non ce ne sono affatto, restituisce
una matrice vuota.
Se il numero di messaggi richiesti è infinito, la funzione restituisce tutti i
messaggi disponibili.
(possiamo settare numMessaggiRichiesti pari a infinito Inf )
42. Vehicle Network Toolbox
• ‘Unpack’
Dopo aver ricevuto un messaggio si deve specificare come è
codificato per poterlo interpretare:
valore = unpack (nomeMsg, startBit, dimensioni, ‘codifica’ , ‘tipoDato’)
nomeMsg: è il nome del messaggio
questa funzione ci restituisce
StartBit : è lo start bit, i valori accettati
il valore del dato contenuto vanno da 0 a 63
Dimensioni : un valore che va da 1 a 64
nel messaggio indicato, oppor- (bit), che definisce le dimensioni del
segnale
tunamente decodificato
Codifica il campo può assumere due
valori: ‘LittleEndian’ o ‘BigEndian’
Tipo di dato… ad esempio uint8 o int16
43. Vehicle Network Toolbox
• Abbiamo la possibilità di settare dei FILTRI
• filterAllowAll (nomeCanale, ‘tipo’ ) ;– ‘Standard’ o ‘Extended’
• filterBlockAll (nomeCanale, ‘tipo’ ) – ‘Standard’ o ‘Extended’
• filterAllowOnly (nomeCanale, ‘nome’ ) – si usa con un database
filterAllowOnly (nomeCanale, id , ‘tipo’ )
possiamo definire l’insieme degli identificativi permessi in vari modi:
• valori singoli
• valori multipli (es: [100,124,257] ) ,
• range di valori (es [100:200] ) ,
• range multipli (es: [100:200, 1000:1100])
• Altre : filterAcceptRange ; filterBlockRange
filterAcceptRange (nomeCanale, inizio, fine) - idem per filterBlockRange
44. Vehicle Network Toolbox
Altre funzioni:
nomeDataBase = canDatabase ( ‘..indirizzoFile.dbc’ ) – importa un database
discard ( nomeCanale ) – scarta i messaggi di un canale
msgInfo = messageInfo (nomeDataBase) – ci da informazioni sui messaggi..
Possiamo anche specificare il nome del messaggio con le forme :
msgInfo = messageInfo (nomeDataBase, ‘nomeMessaggio’)
msgInfo = messageInfo (nomeDataBase, ID, tipo)
transmitEvent (nomeCanale, nomeMessaggio, ‘On’)
transmitPeriodic (nomeCanale, nomeMessaggio, ‘On’, time)
transmitConfiguration (nomeCanale)
45. Vehicle Network Toolbox
canTool
• Tramite il canTool, è possibile monitorare il
traffico di un determinato canale.
46. Vehicle Network Toolbox
• È possibile configurare la
velocità
• È possibile configurare i
filtri
Per altre funzionalità si -
rimanda alla guida ufficiale. -
47. Vehicle Network Toolbox
Utilizzo di Simulink
Abbiamo a disposizione vari blocchi:
• CAN Configuration
• CAN Log
• CAN Pack
• CAN Receive
• CAN Replay
• CAN Transmit
• CAN Unpack
48. Vehicle Network
Toolbox
• Message Transmission
Workflow
Qui a fianco un
semplice modello
di trasmissione
49. Vehicle Network Toolbox
• Message
Reception
Workflow
Come si vede dal
modello qui a fianco,
possiamo settare
filtri per il canale in
ricezione
50. Vehicle Network Toolbox
Dopo aver aperto Simulink e creato un nuovo file
possiamo costruire un modello di trasmissione:
per aprire la libreria CAN possiamo anche
digitare il comando canlib che indirizza
immediatamente ai blocchi interessati
51. Vehicle Network Toolbox
Il blocco
CAN Configuration
Impostazioni del blocco
CAN Configuration
52. Vehicle Network Toolbox
• Importare il blocco CAN Pack e il blocco
Constant il quale servirà
per inserire il Data Field.
es: [ 0 1 2 3 4 5 6 7 ]
• Il blocco CAN Pack, ci consente di specificare
molti parametri importanti di un messaggio
CAN: Identificativo, tipo di messaggio,
lunghezza dei dati e possiamo inoltre
specificare se si tratta di un remote frame.
53. Vehicle Network Toolbox
Abbiamo la possibilità di
collegare un database o di
specificare manualmente i
segnali.
54. Vehicle Network Toolbox
• Inseriamo il blocco CAN Transmit, tale blocco
serve per trasmettere i messaggi tramite il
canale specificato:
Possiamo specificare
anche se vogliamo
svolgere una trasmissione
periodica del messaggio:
57. Vehicle Network Toolbox
• Importiamo il blocco CAN Configuration che
gia conosciamo.
• Importiamo
il blocco CAN Receive
Come vediamo dall’immagine,
possiamo settare i filtri ed
anche il numero di messaggi
che intendiamo ricevere.
58. Vehicle Network Toolbox
• Inseriamo il blocco CAN Unpack all’interno del
blocco
Function-Call
Subsystem
Per visualizzare i
risultati non
dimentichiamo di
inserire il blocco
Scope all’uscita del
sottosistema.
59. Vehicle Network Toolbox
Analizziamo i
parametri del
CAN Unpack:
ci consente di
interpretare i
messaggi in ingresso
e di restituire in
uscita non solo il dato
valido ma anche altri
parametri del
messaggio.
60. Vehicle Network Toolbox
Ecco il modello ultimato, abbiamo
ora la possibilità di trasmettere e
ricevere messaggi