Il protocollo CAN è stato impiegato inizialmente per ridurre il cablaggio all’interno degli autoveicoli, ma ben presto ha trovato utilizzo, con il CANopen, anche nel settore industriale, dove attualmente è uno standard specialmente quando servono requisiti real-time.
Ormai moltissimi ambienti fanno uso di reti locali con estensioni che da pochi centimetri possono arrivare a qualche chilometro. Le reti sono utilizzate fondamentalmente per condividere delle risorse e per lo scambio delle informazioni, tra le diverse tecnologie adibite allo scopo il CAN è stato progettato come una rete di comunicazione di ambito industriale, quindi un bus di campo. Quest’affermata tecnologia di rete è stata impiegata inizialmente per ridurre il cablaggio all’interno degli autoveicoli, ma ben presto ha trovato utilizzo con il CANopen anche nel settore industriale, dove attualmente è uno standard specialmente quando servono requisiti real-time. Per realizzare la comunicazione, si devono considerare una serie di elementi tali da garantire il collegamento tra i dispositivi, l’integrità delle informazioni, la velocità della comunicazione. I principali fattori da considerare sono:
» la capacità d’interconnessione: la rete deve supportare dispositivi differenti, chiamati nodi, ed eventualmente deve avere la possibilità di collegarsi ad altre reti;
» l’espandibilità, la possibilità di ampliamento del sistema in maniera relativamente semplice e con costo contenuto;
» le prestazioni, intese come velocità di trasmissione, numero di utenze, distanze di comunicazione supportate;
» l’affidabilità, considerata come corretto funzionamento del sistema nel suo complesso e capacità nella rete stessa di confinare i guasti sul componente per non portare al collasso il resto del sistema.
Nel processo di comunicazione ci sono due aspetti di fondamentale importanza: la corretta e tempestiva trasmissione e ricezione dell’informazione e la riconoscibilità sotto il profilo di sintattico e semantico. Per risolvere questi due problemi di comunicazione sono nate le architetture a strati, sull’indicazione del modello ISO per i sistemi aperti (OSI). CANopen (Controller Area Network) è un protocollo di comunicazione seriale di tipo “broadcast” che permette il controllo real-time distribuito con un livello di sicurezza molto elevato. È stato introdotto dalla Bosch nei primi anni ‘80 per applicazioni automotive, per consentire la comunicazione fra i dispositivi elettronici montati su autoveicoli, ma si è diffuso ormai in molti settori dell’industria, compresa quella elettromedicale. Sono sorti anche consorzi di aziende che ne promuovono la diffusione come CiA, CAN in Automation (http://www.can-cia.org): è un esempio di organizzazione che adatta l’hardware CAN in ambienti dalle caratteristiche variabili. La diffusione ha subito una notevole accelerazione grazie a due situazioni favorevoli:
» la crescente domanda di elettronica nel settore automotive, che ha indotto i fabbricanti di semiconduttori ad integrare il protocollo su un numero sempre crescente di chip. L’ampia gamma di trasmettitori, ricevitori, microcontrollori e tool di sviluppo che utilizzano la tecnologia CAN ha messo quindi i progettisti di altri settori di fronte ad una tecnologia ormai matura e standardizzata, a differenza di altre reti per l’automazione (bus di campo) dove l’accordo fra le case produttrici è ancora lontano dall’essere raggiunto;
» le specifiche comuni che un bus di comunicazione deve soddisfare nelle applicazioni automotive e in quelle di automazione civile ed industriale: temporizzazione rigida, elevata affidabilità anche in ambienti particolarmente ostili, semplicità di cablaggio e costi contenuti.
Sono in molti a vedere nel bus CAN lo standard dominante nelle reti industriali del prossimo futuro, grazie ai notevoli vantaggi tecnologici che offre:
» tempi di risposta rigidi, specifica fondamentale nel controllo di processo: la tecnologia CAN prevede molti strumenti hardware e software e sistemi di sviluppo per protocolli ad alto livello (il bus CAN implementa solo i primi due livelli della pila ISO/OSI) che consentono di connettere un elevato numero di dispositivi mantenendo stringenti vincoli temporali;
» semplicità e flessibilità del cablaggio: CAN è un bus seriale tipicamente implementato su un doppino intrecciato (schermato o no secondo le esigenze). I nodi non hanno un indirizzo che li identifichi e possono quindi essere aggiunti o rimossi senza dover riorganizzare il sistema o una sua parte;
» alta immunità ai disturbi: lo standard ISO 11898 raccomanda che i chip di interfaccia possano continuare a comunicare anche in condizioni estreme, come l’interruzione di uno dei due fili o il cortocircuito di uno di essi con massa o con l’alimentazione;
» elevata affidabilità: la rilevazione degli errori e la richiesta di ritrasmissione è gestita direttamente dall’hardware con cinque diversi metodi (due a livello di bit e tre a livello di messaggio). Complessivamente questi controlli portano la probabilità di er-13 rore non rilevato sotto 10;
» confinamento degli errori: ciascun nodo è in grado di rilevare il proprio malfunzionamento e di autoescludersi dal bus se questo errore è permanente. Questo è uno dei meccanismi che consentono alla tecnologia CAN di mantenere la rigidità delle temporizzazioni, impedendo che un solo nodo metta in crisi l’intero sistema;
» maturità dello standard: la larga diffusione del protocollo CAN in questi venti anni ha determinato un’ampia disponibilità di chip ricetrasmettitori, di microcontrollori che integrano porte CAN, di tool di sviluppo, oltre che una consistente diminuzione del costo di questi sistemi.
Il modello ISO/OSI
Il modello “de iure” nell’ambito delle reti è il modello ISO/OSI, introdotto dell’International Standard Organization (ISO) ente di standardizzazione internazionale, è un modello per l’Open System Interconnection (OSI) cioè per l’interconnessione aperta tra sistemi. L’obiettivo di tale standardizzazione è definire un modo per descrivere opportunamente i sistemi di comunicazione, facendo in modo che nel descriverli in maniera standard, questi sistemi prodotti da aziende diverse potessero comunicare tra loro. Esso prevede 7 livelli come evidenziato in figura. Prima di chiarire l’importanza di ogni singolo livello bisogna chiarire due importanti questioni:
» come tali livelli interagiscono all’interno di tali entità;
» come tali entità interagiscono tra loro; Al primo quesito si può rispondere dicendo che in un modello puramente funzionale l’interazione è libera e non c’è organizzazione gerarchica, mentre qui si introduce la regola dell’adiacenza secondo la quale ogni livello può interagire solo con i livelli adiacenti. Interagire significa chiedere al livello inferiore di sviluppare un servizio o acquisire una richiesta di sviluppare un servizio dal livello superiore. Al secondo quesito possiamo rispondere ipotizzando di avere a disposizione due entità protocollari identiche nell’ambito della stessa rete, vogliamo creare la comunicazione tra le due entità, i due terminali sono collegati attraverso un mezzo fisico e l’interazione potrà avvenire solo tra livelli omologhi (peer layer). Ogni livello di una entità può comunicare solo con il livello omologo dell’altra entità. Il motivo per cui si lavora con tale regola è sicuramente la necessità di ordine, ma c’è anche un motivo logico, se ogni livello ha delle funzionalità non ha senso far parlare in remoto livelli che sviluppano funzioni diverse. Bisogna sottolineare che la comunicazione tra livelli omologhi in ogni caso avviene a livello logico e non fisico in quanto per la regola dell’adiacenza ogni informazione passa attraverso tutti i livelli sottostanti in entrambe le entità per arrivare quindi al livello fisico dove avviene l’unica comunicazione di tipo orizzontale. Definiamo in breve i vantaggi e gli svantaggi della realizzazione a livelli secondo il modello ISO/OSI. Sicuramente se pensiamo ai livelli il primo vantaggio è l’interoperabilità esterna tra entità della rete, ma a questo si può facilmente aggiungere l’interoperabilità interna, considerando la standardizzazione delle interfacce tra livelli, con la possibilità di sostituire un livello con un altro omologo in modo trasparente.
Un altro vantaggio è l’astrazione con cui si realizzano le diverse funzionalità nell’ambito del singolo livello, tale aspetto si trasforma in uno svantaggio ai livelli più alti come il livello trasporto, dove il canale di comunicazione è visto come insicuro e poco affidabile per quanto riguarda perdita e duplicazione dei pacchetti, insomma si perde contatto con quanto succede al di sotto e non si realizza la particolare situazione della rete. Arriviamo quindi ad una brevissima descrizione dei diversi livelli:
» Livello Fisico: si occupa di trasmettere sequenze binarie sul canale di comunicazione. A questo livello sono specificate da un punto di vista convenzionale, le tensioni 0 e 1, tipi, dimensioni, impedenze dei cavi, tipi di connettori. Il livello fisico è nel dominio dell’ingegneria elettronica;
» Livello Data Link: ha come scopo la trasmissione affidabile di frame (pacchetto dati di livello 2), verifica la presenza di errori attraverso l’aggiunta di una sequenza di controllo detta FCS (Frame Control Sequence). Può gestire meccanismi di correzione di errori tramite ritrasmissione;
» Livello Rete: Questo livello definisce l’instradamento dei messaggi (pacchetti). Determina quali sistemi intermedi devono essere attraversati da un messaggio per giungere a destinazione. Quindi vengono gestite tabelle di instradamento per ottimizzare il traffico sulla rete;
» Livello Trasporto: E’ il primo livello non implementato nei nodi intermedi della rete, fornisce servizi per il trasferimento dei dati end-to-end, cioè indipendenti dalla rete sottostante. In particolare il livello 4 può: frammentare le informazioni da inviare per raggiungere dimensioni idonee al livello 3, rilevare e correggere gli errori, controllare il flusso, controllare le congestioni;
» Livello Sessione: è responsabile dell’organizzazione del dialogo e della sincronizzazione tra due programmi applicativi e del conseguente scambio di dati;
» Livello Presentazione: gestisce la sintassi dell’informazione da trasferire, e garantisce la portabilità dei dati, in quanto si adopera a trasformare le grandezze secondo il formato di rappresentazione della rete, per poi garantire a destinazione l’operazione duale di traduzione nei formati di rappresentazione caratteristici della macchina destinataria.
» Livello Applicazione: è il livello in cui sono definiti i protocolli su cui sono costruite le principali applicazioni, come http per i web browser o SMTP e POP3 per i programmi di posta elettronica ecc. Ognuno di questi livelli aggiunge un header al dato da trasmettere, mentre l’unico livello che aggiunge sia in testa che in coda (trailer) è il livello Data Link, dove aggiungiamo in coda la Frame Control Sequence.
Figura 1: stack ISO/OSI.
Figura 2: i due livelli definiti dal CAN.
I bus di campo, il CAN ed il CANopen
In riferimento allo standard ISO-OSI il CAN Bus può essere rappresentato come in figura 3.
Figura 3: livelli dello stack ISO/OSI definiti nel CANopen.
Sono definiti solo i livelli 1 e 2, i livelli dal 3 al 6 non sono presenti e il livello 7 è definibile liberamente (in figura è indicato quello relativo al CANopen). Inizialmente questo aveva portato diverse aziende a sviluppare il proprio protocollo cercando poi di diffonderlo il più possibile; sono nati così degli standard de facto e tra quelli che più si sono affermati troviamo il DeviceNet della AllenBradley, l’SDS della Honeywell ed il SeleCAN della Selectron. Contemporaneamente in Germania si era formata un’altra organizzazione a sostegno del CAN nell’automazione denominata CiA (CAN in Automation), indipendente dai prodotti delle aziende e con lo scopo iniziale di divulgare la conoscenza del CAN. In questo gruppo formato inizialmente da aziende di piccola e media importanza, era nato il desiderio di adottare una strategia comune per non dover sottostare ai protocolli proprietari che si stavano diffondendo; si sono attivati dei gruppi di lavoro che hanno definito così un nuovo protocollo denominato CAL (CAN Application Layer). Sviluppato con l’obiettivo di soddisfare tutte le aspettative possibili e di poter essere completato con specifiche particolari, il CAL è risultato piuttosto elaborato e dispendioso nell’implementazione, anche se la sua modularità ne facilitava la personalizzazione. In seguito è nata così l’esigenza di sviluppare un protocollo avente la stessa flessibilità del CAL ma che rispondesse solo ad alcuni sottoinsiemi della norma completa. Partendo da una versione sperimentale realizzata con il progetto Esprit sotto la presidenza di Bosch, si giunge così al 1995 con l’emissione da parte della CiA della specifica CANopen. Inizialmente il profilo di comunicazione deriva dal CAL (CiA DS-201...DS-207) e solo nel 1999 viene realizzata la nuova specifica CiA DS-301; oltre a questa troviamo le linee guida per cavi e connettori (CiA 303-1), per dispositivi programmabili (CiA 302) e per unità di misura e prefissi (CiA 303-2). L’integrazione di funzionalità relative a dispositivi, interfacce e applicazioni specifiche sono facilitate dalle presenza di profili standard (CiA DS-4xx) che interagiscono con i livelli sottostanti relativi alla comunicazione. Possiamo tentare di chiarire in dettaglio quanto viene definito a livello applicazione e le sovrastrutture astratte al di sopra in ambito CANopen. A livello applicazione vengono principalmente definiti:
» “Communication Profile” che definisce i servizi per ricevere e trasmettere gli oggetti sul bus: variabili, parametri, numeri o altro vengono chiamati “oggetti” nel mondo del CAN; tra questi troviamo PDOs, SDOs, Special Objects, NMT Objects;
» “Object Dictionary” che rappresenta l’interfaccia verso il software applicativo: descrive tutti i tipi di dati, gli oggetti di comunicazione e di applicativo, definisce il formato dei dati scambiati attraverso la rete e il loro significato, nonché le regole per la codifica e la rappresentazione del loro valore; i bit vengono trasmessi in sequenza di ottetti (byte), dal byte meno significativo al più significativo (stile little endian) ad esempio [b7...b0] [b15...b8] [b23...b16]
» “Frameworks” rappresenta un livello aggiuntivo specifico ad esempio per dispositivi programmabili: nei dispositivi PLC gli oggetti standard previsti non sono sufficienti per gestire i processi di configurazione e salvataggio delle impostazioni; nella specifica DS-301 vers.4.02 è presente una normativa in allegato (Annex A) che era originariamente specificata in “CiA DSP-302 Framework for programmable CANopen devices” che descrive dei tipi di dati specifici e oggetti di comunicazione aggiuntivi per la verifica dell’integrità dei dati, la loro memorizzazione con un Electronic Data Sheet (EDS), un prompt comandi, multiplexed PDOs ecc. Tutti i “Profile” descrivono le caratteristiche e le funzionalità opzionali del dispositivo :esistono Profile già definiti ad esempio per moduli di I/O (DS-401), misurazione e controllo temperatura e pressione (DS-404), gestione encoder (DS-406), controllo trasmissione idrostatica (DS-408), controllo posizione (DSP-402), controllo porte automatiche (DSP-416), controllo ascensori (DSP-417) ecc…
Figura 4: particolare dei livelli implementati dal CANopen.
Elementi fondamentali del Modello di Programmazione CANopen
In ambito industriale esistono diversi dispositivi equipaggiati di elettronica integrata e pilotabili, controllabili o acquisibili via CANopen, la varietà di prodotti in cui viene impiegato rende d’interesse capire quali sono i principali costrutti e strumenti che permettono di programmare questi dispositivi. Il CANopen è stato progettato in origine sia per i sistemi industriali di controllo dei movimenti che delle manipolazioni, ma le reti CANopen sono anche usate nei seguenti campi di applicazione:
» Grandi macchine operatrici da fuori strada,
» Sistemi di controllo di grandi camion per trasporti speciali,
» Treni per passeggeri e per merci,
» Elettronica marittima,
» Automazione civile (domotica),
» Automazione industriale,
» Controllo di macchine industriali,
» Apparecchiature mediche e accessori,
» Ascensori e scale,
» Controlli non industriali,
» Controlli di apparecchiature non industriali.
Il concetto centrale di CANopen è basato sull’uso di un “dizionario di oggetti” (Object Dictionary), che raccoglie i dati relativi alla comunicazione ed all’applicazione. Nello strato d’applicazione di CANopen (Application Layer) i dispositivi si scambiano oggetti di comunicazione e di applicazione (Object at Index). Tutti questi oggetti sono accessibili tramite un indice a 16 ed un sub-indice ad 8 bit. Questi ‘Communication Object (COB)’ sono inseriti in una o più sequenze CAN con identificatori predefiniti o appositamente configurati. In pratica un’applicazione fa richiesta al CANopen Application Layer di un determinato Object, questa richiesta si traduce in un messaggio CAN con una ben determinata sintassi che viene spedito al destinatario che opera il processo di decodifica della richiesta e d’invio della risposta secondo lo stesso meccanismo. Possiamo qui riassumere la disposizione dei diversi dati nel Dizionario Oggetti (tabella 1).
Tabella 1: la disposizione dei diversi dati nel Dizionario Oggetti
Tutti i parametri sono contenuti nel Dizionario Oggetti, che nella forma completa è formato da sei colonne: Index, Object, Name, Type, Attribute, M/O.
» La colonna Index indica la posizione nel dizionario;
» La colonna Object indica il nome simbolico dell’oggetto (es. DOMAIN, VAR, ARRAY, RECORD);
» La colonna Name contiene una descrizione testuale;
» La colonna Type indica il tipo di dato (es. BOOLEAN, UNSIGNED8, SIGNED16);
» La colonna Attribute indica il tipo di accesso visto dal bus verso il dispositivo (es. Read/Write, ReadOnly, WriteOnly);
» La colonna M/O significa obbligatorio (Mandatory) o opzionale (Optional). Per accedere a questi dati sono previsti due meccanismi di trasferimento di dati (SDO/PDO), che hanno caratteristiche molto diverse e sono concepiti per coprire l’intera gamma delle esigenze proprie delle applicazioni d’automazione.
» I SDO – Service Data Object secondo cui la trasmissione degli Oggetti di servizio è aciclica ed è usata specificamente per configurare dispositivi in rete CAN, con messaggi a bassa priorità. Il meccanismo di indirizzamento dei singoli parametri è costituito da un indice a 16 bit ed un sub-indice di 8 bit. Con questa modalità, i trasferimenti di dati per più di 8 byte si fanno utilizzando più messaggi CAN.
» I “PDO” in base ai quali la trasmissione degli Oggetti di processo è normalmente usata per trasferire ad alta velocità dati con alta priorità. In un messaggio PDO i dati sono limitati ad 8 byte o meno. Il formato ed il contenuto del messaggio può essere fisso o può essere configurato dinamicamente con la trasmissione di SDO.
“SDO”: Service Data Objects
Gli Oggetti di servizio (SDO-Service Data Objects) sono normalmente usati per la configurazione dei dispositivi, così come per settare i parametri di dispositivo o scaricare programmi. Si usano anche per definire il tipo ed il formato delle informazioni trasmesse con i PDO (Oggetti di processo). Gli Oggetti di servizio offrono le seguenti funzioni:
» Trasmissione di dati di qualsiasi dimensione (dai simboli booleani ai grandi file);
» Servizi a conferma (domanda/risposta)
per lettura e scrittura di qualsiasi dato;
» Trasferimento celere di dati con lunghezza complessiva fino a 4 byte;
» Trasferimento a segmenti, di dati con lunghezza complessiva maggiore di 4 byte;
» Annullamento (abort) di trasferimento di dati da Client o da Server con ritorno opzionale di messaggio d’errore.
Tutti gli Oggetti del Dizionario possono essere sia letti sia scritti tramite SDO. Per mezzo di un SDO si può stabilire tra due dispositivi un canale di comunicazione peer-to-peer. Il nodo che possiede il dizionario degli oggetti cui è stato dato l’accesso è il servente dell’SDO, mentre il nodo che fa richiesta di accesso ad un determinato oggetto di un dizionario con una richiesta è il cliente.
“PDO”: Process Data Objects
Gli Oggetti di processo (PDO-Process data Objects) non hanno alcun esplicito protocollo che li amministri e ciò permette uno scambio di dati molto veloce e flessibile tra le applicazioni nei nodi. I PDO possono esser trasmessi direttamente da un qualsiasi dispositivo ad un qualsiasi numero di altri dispositivi. Questa facoltà di trasmissione diffusa (multicasting) è una delle prestazioni specifiche del CAN ed è sfruttata in pieno dal CANopen. Si può descrivere la comunicazione di PDO con il modello “Produttore/Consumatore“. I dati di processo possono essere inviati da un dispositivo “produttore” ad un dispositivo “consumatore“ o lo diffonde (broadcasting) a molti altri dispositivi. Per i PDO non esiste handshaking, quindi non c’è conferma ad ogni messaggio. Il produttore invia un PDO da trasmettere - trasmit PDO - T_PDO - con uno specifico identificatore (ID) che corrisponde all’identificatore del PDO da ricevere - receive PDO - R_PDO di uno o più utilizzatori.
CAN Object Identifier, COB-ID
I messaggi scambiati durante la comunicazione sfruttano un numero limitato di identificatori (CAN Object Identifier, COB ID), i quali sono definiti per difetto secondo un preciso schema di allocazione riportato in tabella 2.
Tabella 2: gli identificatori
degli oggetti.
Gli oggetto relativi al controllo della rete (NMT,SYNC ecc.) hanno la priorità più alta, seguiti dai PDOs e quindi dagli SDOs; infatti la priorità viene stabilita in “AND wired mode” sui livelli del bus al momento di invio dell’identificatore (CarrierSenseMultipleAccess / CollisionDetection) in cui il livello basso (dominante) prevale rispetto al livello alto (recessivo).
Figura 5: interazione tra nodi CANopen.
Figura 6: catena di codifica di un messaggio CANopen.
Figura 7: comunicazione sincrona via SDO
Devices Profiles
Il CANopen utilizza la nozione di Profilo di dispositivo (Device Profile), che aiuta l’assemblaggio di sistemi e la standardizzazione dei dispositivi. I fabbricanti hanno la possibilità di produrre dispositivi standardizzati se si attengono alle prescrizioni di un ben determinato profilo di dispositivo standard CANopen. I vantaggi relativi sono numerosi e forse il più rilevante è quello di ottenere alla fine da produttori differenti oggetti intercambiabili in quanto dotati d’interfaccia standard. Ciò permette di allestire reti con dispositivi realizzati da produttori tra loro indipendenti, senza dover scrivere speciali ed appositi software per l’interconnessione dei dispositivi stessi. Lo sviluppo dei profili di dispositivo CANopen è sempre ‘working in progress’ per tutta una gamma di dispositivi diversi, compresi moduli I/O analogici e digitali, comandi (drives), azionamenti (motion controllers), codificatori di posizione (encoders) e quadri di comando (operator displays). Possiamo riepilogare alcuni dei più comuni Device Profiles CANopen:
» CiA DSP 401 I/O Modules
» CiA DSP 402 Drives and Motion Control
» CiA DSP 403 Human machine Interface
» CiA DSP 404 Measusuring Device
» CiA DSP 406 Encoders
» CiA DSP 408 Proportional Hydraulic Valves
» CiA DSP 4xx ... Interface Profiles Specification CiA DSP 405 IEC 1131 Programmable Devices:
» CiA WDP 410 ASAM /GDI
» CiA XXX 4xx...
» … Application Profiles Specification:
» CiA WD 407 Public Transportation
» CiA WDP 412 Maritime Appliocations
» CiA XXX 4xx ...
Figura 8: comunicazione asincrona con PDO.
Conclusioni
In questo articolo sono stati approfonditi a partire da pochi riferimenti al CAN le principali caratteristiche di una tecnologia di bus molto affermata in diversi campi, il CANopen. Nella trattazione sono stati trascurati molti interessanti meccanismi previsti per la sincronizzazione di diversi dispositivi, per la pubblicazione su rete in broadcasting (pdo mapping) ecc..., si rimanda per approfondimenti al sito http://www.can-cia.org dove è possibile trovare tutto quanto legato a queste tecnologie che girano intorno la mondo CAN in automazione industriale.
