89 / 100
Automazione e Strumentazione
n
Luglio/Agosto 2015
CONTROLLO
tecnica
89
essere “condizionato” utilizzando una
piccola porzione del campo dati D, indi-
cata come campo di
regolazione
(T).
Come illustrato in
[6]
, 3 bit sono suffi-
cienti per far sì che il CRC calcolato non
richieda l’inserimento di alcuno stuff bit.
Poiché una parte di D viene riservata per
codificare T, la porzione effettivamente
utile per trasportare informazioni a
livello applicativo, indicata come campo
di
dati effettivi
(E), risulta leggermente
ridotta. Complessivamente, vale la rela-
zione:
D = E \ T
Codifiche ZSD
Sebbene l’adozione di una codifica ZSD
per prevenire gli stuff bit nel campo dati
non sia in teoria un prerequisito per il
meccanismo ZSC, ha tuttavia poco senso
rimuovere gli stuff bit unicamente dal
campo CRC.
Il comportamento di 8B9B [3] può essere
schematizzato nel modo seguente: si
indichi con P
i
il byte
i
-esimo del pay-
load originale (con 0 <
i
≤
m
, dove
m
è la
dimensione in byte di P):
P = P
1
\ P
2
\ … \ P
i
\ … \ P
m
Ogni singolo byte P
i
è codificato separa-
tamente in una
codeword
C
i
usando una
forward lookup table
(FLT) modellata
come una funzione
f
(•):
C
i
=
f
(P
i
)
Le codeword sono poi concatenate
seguendo lo stesso ordine di P
i
, cioè:
C = C
1
\ C
2
\ … \ C
i
\ … \ C
m
Al fine di prevenire l’insorgere di stuff
bit al confine fra H e D, può essere neces-
saria l’aggiunta di un bit di
break
(B) in
testa a D in dipendenza del contenuto del
campo DLC. Il valore di B è pari all’op-
posto del bit finale di detto campo.
Il campo di regolazione T, codificato su
3 bit, si trova nella parte terminale di D.
Poiché B, C (la cui lunghezza comples-
siva è pari a 9 .
m
bit) e T non occupano
necessariamente un multiplo intero di 8
bit, parte dell’ultimo byte in D (la por-
zione compresa fra C
m
e T), indicata
come campo di
padding
(PAD), può
rimanere inutilizzata. PAD viene inizia-
lizzato con una stringa di bit a valore
alterno, che inizia con un bit a valore
opposto rispetto al bit finale di C. Il pay-
load codificato, che viene copiato nella
porzione effettiva E del campo dati, è
ottenuto concatenando B, la sequenza di
codeword C e il padding:
E = B \ C \ PAD
É bene notare come 8B9B sia solo una
fra le possibili codifiche ZSD disponibili.
Per esempio, VHCC [7] permette di
gestire anche informazioni a livello
applicativo espresse su porzioni di byte.
Nel seguito, le operazioni relative alla
codifica del payload verranno sintetica-
mente modellate tramite una funzione
e
(•) che, a partire dall’intestazione H e
dal payload originale P, genera la stringa
di bit corrispondente ad E:
E =
e
(H, P)
Meccanismo ZSC
Come dimostrato in
[6]
, sfruttando la
linearità dei CRC è sempre possibile tro-
vare un valore di T nell’intervallo da 1
a 6 (cioè, nell’insieme {001
2
, 010
2
, 011
2
,
100
2
, 101
2
, 110
2
}) che, a prescindere da
H e da P (o, in modo equivalente, E), per-
mette di prevenire l’inserimento di stuff
bit nella concatenazione di T ed R.
Il calcolo di T, a partire da H ed E, può
essere modellato come una funzione
z
(•):
T =
z
(H, E)
Da un punto di vista pratico, il calcolo
può essere effettuato secondo l’algoritmo
seguente: si considera dapprima la
sezione
iniziale
del messaggio (L), ovvero quella
che precede T, che contiene le informa-
zioni a livello logico del
messaggio:
L = H \ E
e se ne calcola il con-
tributo RL al CRC
complessivo:
R
L
=
c
(L \ 000
2
)
Quindi, per ogni possi-
bile valore di T scelto
fra le stringhe T
i
sopra elencate, il relativo
contributo
c
(T
i
) viene valutato e combi-
nato in XOR con R
L
, al fine di determi-
nare agevolmente il valore complessivo
R
i
del CRC derivante dall’uso di detta
stringa di regolazione:
R
i
= R
L
⊕
c
(T
i
), T
i
= 1…6
dove “
⊕
” rappresenta l’operatore di
XOR bitwise.
Sia
g
(•) una funzione booleana in grado
di determinare se una data sequenza
di bit include più di 4 bit adiacenti allo
stesso valore. Ogni valore T
i
per il quale
g
(T
i
\ R
i
) =
false
può essere utilizzato come risultato di
z
(•). Per quanto dimostrato in
[6]
esiste
sempre almeno uno di tali valori. Nel
caso esistano più valori accettabili, la
scelta su quale utilizzare è irrilevante dal
punto di vista della capacità di inibire il
bit stuffing, e incide solo sulle caratteri-
stiche del codec.
Funzionamento complessivo
Complessivamente, l’algoritmo ZS per
prevenire l’inserimento di stuff bit in una
trama CAN è piuttosto semplice. Come
schematizzato nella
►
figura 3
, viene
innanzitutto invocato il codec 8B9B che,
a partire dall’intestazione H e dal pay-
load P, calcola il payload codificato E.
Utilizzando H ed E, il meccanismo ZSC
determina quindi una stringa valida per
T. Il valore da fornire al controller CAN
per il campo dati D è pari alla concatena-
zione di E e T. Operando in questo modo
si ha la certezza matematica che nessuno
stuff bit venga inserito dal controller
CAN nei campi dati e CRC, azzerando di
fatto ogni jitter di trasmissione.
Figura 3 - Funzionamento complessivo del meccanismo ZS