CANopen Trasmissone e monitoraggio

Introduzione

CANopen è un protocollo di comunicazione aperto standard del settore e specifica del profilo dispositivo (EN 50325-4) basato sul protocollo Controller Area Network(CAN). Il protocollo "Layer 7” è stato sviluppato per le applicazioni di rete integrate e definisce le comunicazioni e le funzioni del dispositivo per sistemi CAN.

CANopen supporta sia le comunicazioni cicliche sia dettate da eventi, consentendo di ridurre al minimo il carico del bus e di mantenere tempi di reazione brevi.

PDO (Process Data Object, Oggetto dati di processo)

I PDO sono oggetti che forniscono l'interfaccia di comunicazione con i dati di processo, permettendone lo scambio in tempo reale. L'insieme di PDO su un dispositivo CANopen descrive gli scambi impliciti tra tale dispositivo e i relativi partner di comunicazione sulla rete. Lo scambio di PDO è autorizzato quando il dispositivo è nella modalità "OPERATIONAL".

Sono disponibili due tipi di PDO:

• PDO di trasmissione (TPDO): PDO trasmesso dal dispositivo

• PDO di ricezione (RPDO): PDO ricevuto dal dispositivo

Modalità di trasmissione

Ai PDO attivati da evento sono associate due ulteriori opzioni:

• Inhibit Time: l'utility Inhibit Time consente di definire un ritardo minimo prima della trasmissione di un nuovo PDO. Si evita così di sovraccaricare il bus laddove si verifica un significativo numero di eventi in rapida successione. L'Inhibit Time viene espresso in multipli di 100 μs.

  Questa funzionalità è disponibile per il trasferimento di Tipo 255 (Asincrono).

• Tempo evento il Tempo evento consente di definire una scadenza laddove la trasmissione di un PDO viene forzata, anche in assenza di modifiche di stato. Il Tempo evento è espresso in millisecondi.

  Questa funzionalità è disponibile per il Tipo 255 (Asincrono).

SDO (Service Data Object)

Uno SDO consente di accedere ai dati del dispositivo tramite richieste esplicite. Il servizio SDO è disponibile quando il dispositivo si trova nello stato "OPERATIONAL" o "PRE-OPERATIONAL".

Sono disponibili due tipi di SDO:

• SDO di lettura (SDO di download)

• SDO di scrittura (SDO di caricamento)

Il protocollo SDO si basa su un modello client/server. Per uno SDO di download, il client (in genere il controller) invia una richiesta che indica l'oggetto da leggere. Il server (in questo caso, l'accoppiatore bus) restituisce i dati contenuti nell'oggetto. Per uno SDO di caricamento, il client (in genere il controller) invia una richiesta che indica l'oggetto in cui scrivere e il valore desiderato. Dopo l'aggiornamento dell'oggetto, il server (in questo caso, l'accoppiatore bus) restituisce un messaggio di conferma.

Se uno SDO non può essere elaborato dal server (accoppiatore bus), il server restituisce un codice di errore (Codice di annullamento). Questa situazione è valida per SDO di download e caricamento. Se il server non risponde entro un periodo di tempo pre-configurato (Timeout SDO), il client emette un codice di annullamento di timeout SDO.

Protocolli di controllo errori

I protocolli di controllo errori consentono di rilevare gli errori di comunicazione sulla rete. Sono disponibili due protocolli: node guarding ed heartbeat. Questi due meccanismi di monitoraggio sono particolarmente importanti nel sistema CANopen. I dispositivi collegati al bus non indicano regolarmente la loro presenza in modalità operativa, in particolare se comandati da Evento.

Node Guarding

In questo protocollo, il master NMT (in genere, il controller) interroga ciascuno slave NMT (accoppiatore bus, ad esempio) a intervalli di tempo regolari, denominati Guard Time. Lo slave risponde con il proprio stato NMT. Lo slave, se non riceve un'interrogazione dopo un periodo definito denominato Lifetime, passa allo stato configurato nell'oggetto 1029H e genera un evento life guarding. L'accoppiatore bus, invece, passa allo stato configurato nell'oggetto 1029H (se l'oggetto 1029H viene lasciato come predefinito), viene attuata la gestione del posizionamento di sicurezza e generato l'evento Guarding. Lifetime è definito nel modo seguente: Lifetime = Guard Time x Lifetime Factor. L'oggetto 100CH contiene il parametro Guard time espresso in millisecondi. L'oggetto 100DH contiene il parametro Lifetime factor. Guard Time e Lifetime Factor possono essere configurati in modo diverso per slave differenti.

Quando uno dei due parametri Lifetime Factor o Guard Time viene impostato a 0 (configurazione predefinita), lo slave non effettua il monitoraggio. Per attivare il monitoraggio nel tempo, occorre immettere un valore (minimo 2) nell'oggetto 100DH e specificare una durata in millisecondi nell'oggetto 100CH.

I valori tipici per il parametro Guard Time sono compresi tra 200 ms e 2 s.

Per mantenere un funzionamento più affidabile e sicuro, occorre specificare un Lifetime Factor (oggetto 100DH) con un valore pari a 2 o superiore. Se si utilizza il valore 1 e si verificasse un ritardo dovuto all'elaborazione di messaggi ad alta priorità o all'elaborazione interna sul master node-guarding, lo slave può passare inavvertitamente allo stato configurato nell'oggetto 1029H.

Meccanismo Heartbeat

In questo protocollo, il generatore trasmette periodicamente un messaggio Heartbeat, in base al parametro Producer Heartbeat Time (in millisecondi) configurato nell'oggetto 1017H. I dispositivi responsabili del monitoraggio di questo messaggio avranno un parametro Consumer Heartbeat Time (in millisecondi), configurato nell'oggetto 1016H. Se il messaggio Heartbeat del generatore non viene ricevuto entro il tempo configurato dei dispositivi utilizzatori, i dispositivi generano un evento Heartbeat. Per l'accoppiatore bus, avviene il passaggio allo stato CANopen come configurato nell'oggetto 1029H, la gestione del posizionamento di sicurezza viene attivata e generato l'evento Heartbeat.

Il messaggio Heartbeat indica lo stato del dispositivo su un byte, composto da:

• Il bit più significativo è riservato e sempre a 0

• I 7 bit meno significativi forniscono lo stato per il dispositivo che genera il messaggio Heartbeat