Protocolli CAN e LIN: dall’automotive alle applicazioni industriali e domotiche

Le automobili sono ormai diventate dei sistemi elettronici complessi in cui coesistono svariate decine di oggetti “smart” che condividono informazioni e comandi. Si va dai sensori “intelligenti” alle vere e proprie centraline di controllo dedicate a specifiche funzioni (gestione motore, sicurezza come ABS, ESP, ecc. o dispositivi per l’infotainment) tanto che si parla sempre più di intelligenza distribuita. Come condividere le informazioni (ovvero i dati) fra i molti dispositivi di cui è equipaggiata un’auto è una interessante sfida progettuale perché bisogna collegare in qualche modo tutti gli apparati possibilmente senza dover utilizzare tanti cavi e soprattutto senza dover ricablare o riconfigurare la rete ogni volta che si aggiunge o rimuove un dispositivo.

Inoltre bisogna garantire che l’auto sia un mezzo sicuro e quindi siano disponibili tutti i dati in tempo reale e senza conflitti di comunicazione in modo che qualunque azione effettuata non crei una situazione di pericolo ai passeggeri (immaginiamo cosa potrebbe succedere se l’ABS interviene o, peggio, non si attiva quando serve se contemporaneamente si accende il tergicristalli o il sensore del livello carburante invia un messaggio di serbatoio in riserva).

Queste problematiche esistono da quando è iniziato l’impiego di sistemi elettronici a bordo veicolo e sono state affrontate in particolare dalla Robert Bosh GmbH, negli anni ottanta, che ha inventato un bus che coniuga caratteristiche di semplicità, robustezza e sicurezza tali che oggi è uno standard di fatto nel mondo automotive ed è inoltre utilizzato sempre più in ambito industriale ed anche domotico: il Controller Area Network (CAN).

Il bus CAN

Il bus CAN è un protocollo seriale di tipo “broadcast” cioè ogni nodo della rete trasmette a tutti e sarà compito dei riceventi scartare il messaggio se non ne sono i destinatari. Le sue caratteristiche, come vedremo più avanti consentono il controllo real-time distribuito con un livello di sicurezza molto elevato.

Un notevole punto di forza del bus CAN è la semplicità del cablaggio unito ad una elevata flessibilità:

  • la comunicazione seriale è tipicamente implementata su un doppino intrecciato (schermato o meno a seconda delle esigenze);
  • i nodi non hanno un indirizzo che li identifichi e possono quindi essere aggiunti o rimossi senza dover riconfigurare o riprogrammare il sistema: i messaggi vengono instradati mediante un identificativo che determina la priorità che il dispositivo ha nella competizione per l’accesso al bus, in base all’identificativo il ricevente può scegliere se processare il dato o meno.

Come protocollo di comunicazione di rete è molto semplice e molto robusto allo stesso tempo perché implementa solo i primi due livelli della pila ISO-OSI (PHY e Data Link) ma prevede tempi di risposta rigidi per garantire la sicurezza nel controllo real time. Inoltre la rilevazione degli errori e la richiesta di ritrasmissione sono gestiti direttamente dall’hardware.

I dispositivi che si connettono al bus CAN, quindi anche i sensori e gli attuatori, devono essere “intelligenti” ovvero dotati un sistema logico (un microprocessore quindi) in grado di produrre i dati per poi immetterli sul bus, superando il classico approccio che prevedeva una centralina per la raccolta dei dati dai sensori (o per la gestione degli attuatori) e la successiva eventuale comunicazione con ulteriori centraline.

La specifica del bus prevede che non ci sia un unico dispositivo che controlla la rete: il bus CAN è definito “multi-master” perché qualsiasi oggetto connesso può prendere il controllo della comunicazione, ovvero tutti i nodi della rete posso trasmettere e più nodi della rete possono chiedere il canale trasmissivo contemporaneamente. In pratica un dispositivo che implementa il protocollo CAN deve essere in grado di richiedere ed utilizzare i dati di un altro dispositivo intelligente.

Come avviene la comunicazione su bus CAN

I dispositivi connessi al bus CAN possono in qualunque momento trasmettere impostando il bit desiderato sul bus (ricordando che si tratta di un bus seriale e quindi si trasmette un bit alla volta). Ma cosa succede se due o più dispositivi trasmettono contemporaneamente? Se i bit immessi sono uguali non c’è problema ma se i bit sono diversi è stabilito che un solo tipo di bit (detto, appunto, dominante) può essere trasmesso mentre l’altro (recessivo) viene ignorato. Il dispositivo legge il bit presente sul bus ed interrompe la trasmissione se rileva un bit dominante dopo che aveva trasmesso un bit recessivo.

Un modo per implementare questa tecnica (si tratta di una forma di “arbitrato”) è scegliere lo zero logico come dominante ed utilizzare un AND logico fra il bit trasmesso e quello presente sul bus per decidere se continuare la trasmissione:

Il protocollo prevede che l’identificativo sia inviato in testa al messaggio in modo che con questo tipo di arbitrato sia sempre il dispositivo con l’identificativo a maggiore priorità a trasmettere, ovvero a prendere il controllo del bus.

Il bus LIN

In un sistema complesso come un’automobile non tutti i dispositivi necessitano di comunicare con tutti gli altri, così come alcuni dispositivi trasmettono limitate tipologie di dati (per esempio, in modo molto semplificato, il controllo di apertura e chiusura dello finestrino ha un comando “apri/chiudi” ed un livello di apertura da comunicare a pochi altri dispositivi) senza particolari requisiti di sicurezza.

Per esigenze di trasmissione fra pochi dispositivi (magari un collegamento diretto sensore-attuatore che non necessita di elevate velocità di trasmissione e delle altre caratteristiche di versatilità del CAN) si può pensare di organizzare sotto-reti per gestire il traffico locale utilizzando il protocollo LIN (Local Interconnect Network): un ulteriore protocollo di comunicazione seriale per sistemi distribuiti che consente una comunicazione a basso costo, robusta e affidabile fra sensori e attuatori.

Tale protocollo è di tipo master/slave con un master e fino a 15 slave, dove il master dà l’avvio alle comunicazioni sul bus e pertanto l’accesso è deterministico e non è necessario l’arbitrato come nel CAN.

La rete è realizzata con un unico cavo ed i messaggi sono codificati in byte, in conformità al protocollo UART (Universal Asynchronous Receiver Transmitter) da cui è derivato.

La comunicazione può avvenire in tre modi diversi:

  • dal master ad uno o più slave (il master trasmette sia l’ID degli slave interessati che il messaggio)
  • da uno slave al master (il master trasmette l’ID del dispositivo interrogato e questo risponde con messaggio)
  • da uno slave ad uno o più slave (il master regola solo l’uso del bus ma non necessariamente è il mittente o il destinatario dei messaggi)

Una caratteristica interessante di questo protocollo è la possibilità di gestire lo sleep mode, utile quando si verificano solo messaggi sporadici (ad esempio alla pressione di un pulsante): il master mette il bus “a riposo” con un opportuno comando e gli slave rispondono mettendo i loro transceivers nella modalità a basso consumo energetico in attesa di un segnale di sveglia che può essere prodotto dal master o da uno slave (ad esempio da un pulsante collegato ad uno slave).

​Applicazioni industriali

L’industria moderna è basata su sistemi interconnessi che scambiano dati, ad esempio fra macchinari e sistemi di supervisione e le esigenze di comunicazione non molto dissimili da quelle automotive in quanto occorre garantire sicurezza, integrità dei messaggi e flessibilità di configurazione. Tra i tanti protocolli disponibili si sta diffondendo sempre di più il bus CAN per tutte le caratteristiche di robustezza ed affidabilità viste. Inoltre il CAN consente comunicazioni veloci essendo previsto un bit rate fino a 1Mbit/s per reti lunghe meno di 40m, che ovviamente diminuisce all’aumentare della distanza.

Un altro elemento che ha favorito lo sviluppo del CAN in ambito industriale è il protocollo CANopen, che è un protocollo che implementa il terzo livello della pila ISO/OSI (Application Layer) ed è pensato proprio per garantire il soddisfacimento degli stringenti vincoli di una rete industriale.

​Applicazioni domotiche

La disponibilità di un protocollo flessibile che rende semplice realizzare (basta stendere un doppino), manutenere ed ampliare una rete di sensori ed attuatori intelligenti ha raggiunto anche il mercato domestico. Oggigiorno le abitazioni sono dotate sempre di più di dispositivi intelligenti, che magari diventano obsoleti in poco tempo e vanno sostituiti, oppure si vogliono installare nuovi apparecchi che possono essere anche di marche differenti. Di fronte a queste esigenze gli standard proprietari sono meno preferiti e protocolli come il CAN diventano via via più diffusi.

​Conclusioni

Il protocollo CAN è lo standard di fatto delle connessioni fra dispositivi intelligenti in ambito automobilistico. La complessità della rete e la grande varietà di applicazioni presenti in autoveicolo ha fatto si che al CAN si affiancasse anche un altro protocollo, il LIN, per gestire piccole sottoreti fra dispositivi che trasmettono ridotte quantità di dati e magari anche in modo sporadico.

Le caratteristiche del protocollo CAN ne hanno determinato il successo anche in ambiti diversi come quello industriale, anche grazie allo sviluppo del protocollo di CANopen, ed addirittura anche in quello domestico.

Di fatto molti micro-controllori sono ormai dotati di una periferica CAN, e a volte anche LIN, perché le applicazioni sono possibili in molti ambiti e non sono più solo di nicchia.

Gianluca Angelone
Ingegnere elettronico con la passione per l’elettronica fai da te, Gianluca ha approfondito la sua passione con un Dottorato in Automatica ed un assegno di ricerca post-doc su tecnologie innovative per veicoli a trazione elettrica. Ha iniziato la sua attività professionale in una nota multinazionale nel settore dei semiconduttori, dedicandosi alla prototipazione rapida di algoritmi di controllo per motori diesel common rail. Ha collaborato a vario titolo con aziende come ABB, AnsaldoBreda e STmicroelectronics su progetti relativi a modellistica, simulazione e controllo di circuiti elettronici. Attualmente freelance, si occupa di progetti hardware e firmware per applicazioni IoT, oltre a fornire consulenza come innovation manager.