Protocollo CANopen

Per poter gestire una rete CAN a livello di applicazione tramite un computer, occorrono degli ulteriori strati nella pila ISO/OSI che forniscano un’interfaccia di programmazione semplificata verso l’utente, e che mascherino le differenze di interfacciamento sul bus CAN. Un computer, infatti, può scegliere varie alternative per interfacciarsi sul bus CAN: le più comuni sono costituite da schede PCI/PCIe o PCMCIA, dispositivi USB, Bluetooth oppure Ethernet.

Una implementazione molto diffusa dello strato Applicazione della pila ISO/OSI è costituita dal protocollo CANopen, che fornisce l’insieme di API (Application Programming Interface) e definisce i profili di comunicazione ai quali devono attenersi le applicazioni ed i dispositivi al fine di consentire una corretta interpretazione dei messaggi.

In altre parole, lo standard ISO 11898 indica come effettuare lo scambio dei messaggi, i livelli di tensione, le temporizzazioni dei segnali, le regole di accesso al mezzo condiviso e i meccanismi per il recupero da errore, mentre il protocollo CANopen, che giace sul primo, indica quali sono i messaggi che possono essere inviati ed i loro significati.

Figura 18 Divisione dei compiti tra CAN e CANopen

Il protocollo CANopen definisce 6 tipi di messaggi che, vista l’assenza di informazione su mittente e destinatario, vengono visti come degli oggetti dai nodi che se li scambiano e pertanto assumono proprio il nome di oggetto. Le tipologie di oggetto previste dal protocollo CANopen sono:

• NMT – Network ManagemenT, utilizzati per comandare singolarmente o simultaneamente tutti i nodi della rete, solitamente per attivarli/disattivarli portandoli dallo stato pre-

operational a quello operational e viceversa o per verificarne lo stato di funzionamento;

• PDO – Process Data Object, utilizzati per inviare comandi o valori asincroni tramite uno specifico ID nella rete;

• SDO – Service Data Object, utilizzati prevalentemente per effettuare richieste di lettura/scrittura di parametri di configurazione;

• Sync Objects, utilizzati da dispositivi master nelle reti con comunicazione sincrona per segnalare la possibilità di invio di oggetti da parte dei nodi slave;

• Time Stamp Objects, utili per mantenere aggiornate le informazioni di temporizzazione tra i dispositivi;

• Emergency Object, inviati in modo asincrono dai dispositivi al verificarsi di gravi condizioni di errore.

Gli oggetti possono essere distinti tramite il valore del campo ID contenuto al loro interno, secondo la seguente suddivisione:

Figura 19 Tipi di oggetto CANopen e relativi ID

Con riferimento a quanto detto precedentemente riguardo alla priorità degli identificatori CAN, detti COB-ID (Can OBject IDentifier), è possibile verificare che gli oggetti Network Management di controllo dei moduli sono quelli a più alta priorità, seguiti dai segnali di sincronizzazione, dagli oggetti Emergency e dai Timestamp.

Gli identificatori dedicati ai PDO, i quali costituiscono il cuore del funzionamento di una rete CAN, sono suddivisi in più gruppi per poter riunire i dispositivi all’interno di livelli di priorità differenti. Gli SDO, consentendo l’accesso alla memoria non volatile dei vari dispositivi, vengono utilizzati quasi esclusivamente in fase di configurazione iniziale per il salvataggio dei parametri di funzionamento e hanno vincoli temporali meno stringenti e tempi di elaborazione relativamente lunghi rispetto agli altri e non richiedono, quindi, priorità elevate.

Un oggetto CANopen ha la seguente struttura:

Figura 20 Struttura di un oggetto (messaggio) CANopen

In una rete CAN gli oggetti più frequenti sono i PDO che trasportano solitamente i valori letti dai sensori, i comandi inviati da un nodo agli altri, segnalazioni di inizio o fine operazione, o altri tipi di contenuto. Questi oggetti possono trasportare al massimo 8 byte di dati, come si può vedere dalla dimensione del membro data della struttura CMSG.

Figura 21 Esempio di PDO

Nell’esempio di Figura 21 si sta utilizzando il secondo gruppo PDO di trasmissione per l’invio di 3 byte di dati.

Alcuni dispositivi necessitano di una configurazione iniziale all’accensione, o qualche correzione di parametri di tanto in tanto, o addirittura la sovrascrittura di interi programmi. Per questo tipo di trasferimenti, a bassa priorità e talvolta di dimensioni variabili, si ricorre agli SDO. Solitamente, in

unità Server. Il trasferimento dall’unità Client all’unità Server (scrittura di dati sulla memoria del dispositivo CAN) si chiama Download, mentre il contrario prende il nome di Upload.

I parametri sui dispositivi sono organizzati secondo un dizionario, nel quale ad ogni indice corrisponde un certo oggetto. Ogni oggetto, a sua volta, può avere o meno degli elementi al suo interno distinti da un sotto-indice.

La struttura base di un SDO è la seguente:

Figura 22 Struttura base di un messaggio SDO

La struttura di un messaggio contenente un segmento di trasmissione, invece, è la seguente:

Figura 23 Struttura di un segmento in un SDO

Per iniziare la scrittura di un oggetto nell’Object Dictionary si utilizza il comando Initiate Domain

Download, con il quale possiamo inviare fino a 4 byte di dati, oppure la lunghezza complessiva del

trasferimento in caso di parametri di lunghezza superiore ai 4 byte.

Figura 24 Initiate Domain Download

Nel messaggio inviato dal client al server, i flag presenti hanno i seguenti significati: s: Size – se attivo, indica che il campo n contiene una dimensione valida;

e: Expedit – indica che il trasferimento trasporta un parametro di al più 4 byte e che quindi il suo valore è contenuto dal byte 4 al byte 8-n;

n: Number of invalid bytes – valido se s=1 e e=1, indica il numero di byte che non contengono dati nel corpo del messaggio. Se n è diverso da 0, i byte da 8-n a 7 non sono significativi.

In caso di messaggio di tipo expedit, il server risponde con un messaggio dello stesso tipo e la comunicazione termina correttamente. Se il parametro da scrivere fosse più lungo di 4 byte, occorrerebbe lasciare, nel messaggio iniziale, il flag e non settato ed indicare, nei 4 byte liberi del messaggio, la lunghezza complessiva del trasferimento. In tal caso il server risponderebbe con un messaggio di conferma e si metterebbe in ascolto di ulteriori messaggi fino al completamento del trasferimento. Le fasi successive del trasferimento vengono realizzate con il comando Download

Domain Segment:

Figura 25 Download Domain Segment

Con sequenze di messaggi come quello di Figura 25, il client continua ad inviare parti di parametro al server che risponde confermando la corretta ricezione. In questo caso i flag hanno i seguenti significati:

c: Closing – indica che il messaggio corrente è l’ultimo della sequenza, e che quindi il contenuto del parametro è stato completamente inviato;

n: Number of invalid bytes – come nel caso precedente, indica il numero di byte che non contengono dati nel corpo del messaggio. Se n è diverso da 0, i byte da 8-n a 7 non sono significativi. Avendo a disposizione 7 byte per i dati all’interno di un segmento, questa volta sono necessari 3 bit per rappresentare valori tra 0 e 7;

t: Toggle – inizialmente 0, viene settato o resettato alternativamente ad ogni nuovo segmento, e deve coincidere con quello indicato nella risposta proveniente dal server.

Un meccanismo del tutto equivalente si ha in fase di lettura dei parametri, per la quale si utilizzano i messaggi Initiate Domain Upload e Upload Domain Segment nei quali, però, è il server ad indicare la quantità di dati ed i dati stessi.

Figura 26 Initiate Domain Upload

Figura 27 Upload Domain Segment

In ogni momento, a causa di eventuali errori, sia il client che il server possono interrompere un trasferimento utilizzando il comando Abort Domain Transfer:

Figura 28 Abort Domain Transfer