90 / 100
Luglio/Agosto 2015
n
Automazione e Strumentazione
CONTROLLO
tecnica
90
Prestazioni
È stato implementato e ottimizzato il
codec ZS per un microcontrollore NXP
LPC2468, basato su processore ARM7
con frequenza di clock pari a 72 MHz e
dotato di due controllori CAN integrati.
Tale implementazione ha consentito,
innanzitutto, un’ulteriore verifica spe-
rimentale della
correttezza
del metodo
adottato, conferma ottenuta tramite
misura dell’effettivo tempo di trasmis-
sione di un elevato numero di messaggi
(con payload generato casualmente)
codificati secondo ZS. Lo stesso proto-
tipo è stato poi impiegato per valutare
le
prestazioni
del codec, misurando i
tempi di codifica e decodifica di oltre
10 milioni di messaggi con lunghezza
massima. In entrambi i casi
le misure di tempo sono
state effettuate mediante un
timer interno al microcon-
trollore con risoluzione di
13.9 ns.
I risultati sperimentali,
riportati in
►
Tabella 1
,
confermano che i tempi
di codifica e decodifica
sono estremamente brevi,
soprattutto se si tiene conto
della limitata capacità di elaborazione
del processore usato. In particolare, il
tempo totale di codifica e decodifica per
messaggi di lunghezza massima (prima e
terza riga della tabella) è di soli 12.34 µs,
corrispondenti a circa 890 cicli di clock
del processore.
Di interesse anche maggiore sono i dati
relativi ai jitter di codifica e decodifica
(ultima colonna della tabella). Il jitter di
codifica è infatti pari a 0.47 µs con un’im-
plementazione “ordinaria” di ZS. È inol-
tre possibile ottimizzare ulteriormente il
codificatore, riducendone il jitter a soli
0.03 µs (2 cicli di clock), a spese di un
aumento del ritardo introdotto pari a 1.49
µs (seconda riga della tabella).
Sul lato del ricevitore, il decodificatore
ZS ha prestazioni del tutto analoghe
a quelle del decodificatore 8B9B ed è
esente da jitter, come dimostrato in
[3]
.
Per quanto riguarda l’occupazione di
memoria i risultati sperimentali, riportati
in
►
Tabella 2
, mostrano come i requi-
siti di supporto non volatile (destinato al
codice e alle tabelle di codifica e deco-
difica) siano pari a circa 2 KB, mentre
la memoria RAM richiesta (usata per le
variabili non inizializzate e lo stack) è di
soli 80 B.
Questo aspetto è estremamente impor-
tante per i microcontrollori a basso costo,
che dispongono di quantità di RAM
interna estremamente limitata.
Integrità dei dati
L’azzeramento completo dei jitter di
comunicazione è solo uno dei benefici
ottenibili grazie a ZS. Un secondo van-
taggio, che in diversi settori applica-
tivi come quello veicolistico è ben più
importante del primo, è legato all’inte-
grità dei dati trasmessi in rete.
Come mostrato in
[8]
, il meccanismo
di bit stuffing può interagire col calcolo
del CRC e ridurne in modo non trascu-
rabile la capacità di rilevare errori mul-
tipli. Trascurando i dettagli, una coppia
di bit errati in un messaggio, interagendo
opportunamente con il meccanismo di
bit stuffing, può portare alla traslazione
di una posizione dell’intera sequenza di
bit compresa fra i due errori, senza alte-
rare la lunghezza totale della trama, ini-
bendo quindi alcuni dei meccanismi di
rilevamento di errore di CAN basati sul
controllo del suffisso. In tali condizioni
esiste una possibilità non trascurabile
che neanche il meccanismo basato su
CRC riesca a rilevare tali errori, in par-
ticolare se gli stessi sono localizzati in
posizioni sufficientemente distanti l’una
dall’altra.
Questo implica, in pratica, un aumento
sostanziale della probabilità di errore
residua, ovvero della probabilità che un
messaggio affetto da errori sia conside-
rato corretto dai ricevitori. È facile intu-
ire come tale evenienza possa portare ad
attuazioni
indesiderate
che, in determinati con-
testi applicativi, possono
costituire un oggettivo
fattore di rischio per
persone o cose. A tale
riguardo, si noti che, in
assenza di bit stuffing, il
CRC di CAN sarebbe in
grado di identificare ogni
pattern di errore che coin-
volge fino a 5 bit comun-
que localizzati all’interno della trama.
Un’analisi approfondita, descritta in
[9]
,
mostra come l’uso della sola codifica
8B9B sia in grado di ridurre la probabi-
lità di errore residua in CAN di quasi due
ordini di grandezza. L’aggiunta del mec-
canismo ZSC, azzerando di fatto gli stuff
bit nell’intera trama, può credibilmente
migliorare ulteriormente l’integrità dei
dati. Un’analisi più circostanziata di tale
effetto è attualmente in corso di sviluppo.
Compatibilità
Il problema dell’integrità dei dati è par-
ticolarmente avvertito nel settore veico-
listico ed ha recentemente portato alla
definizione del nuovo protocollo
CAN with flexible data rate
(CAN FD)
[10]
. Oltre a permettere
velocità di trasferimento superiori
a CAN, tale protocollo affronta
anche il problema relativo all’in-
terazione fra bit stuffing e CRC
descritto in precedenza. Sfortuna-
tamente, sebbene ogni controller
CAN FD possa operare secondo
una modalità completamente com-
Memoria (B)
Codice (sola lettura)
1296
Tabelle di codifica e decodifica (sola lettura)
896
Variabili non inizializzate
12
Stack
68
Ritardo (µs)
Medio
Min
Max
Jitter
Codifica ZS (ordinaria)
8.92
8.63
9.10
0.47
Codifica ZS (basso jitter)
10.41
10.39
10.42
0.03
Decodifica ZS (totale)
3.42
3.42
3.42
0.00
Tabella 1 - Risultati sperimentali, ritardo del codec ZS
Tabella 2 - Occupazione di memoria del codec ZS