Protocollo CAN: come funziona davvero una rete CAN, dai segnali fisici alla diagnostica

Quando si parla di elettronica automotive, sistemi embedded, macchine industriali o veicoli speciali, prima o poi si arriva sempre al CAN.

Il CAN, cioè Controller Area Network, è un protocollo di comunicazione seriale nato per permettere a più dispositivi elettronici di scambiarsi dati su un bus condiviso in modo robusto, affidabile e deterministico. È nato nel mondo automotive, ma oggi lo troviamo ovunque: veicoli commerciali, macchine agricole, automazione industriale, robotica, motorsport, nautica, sistemi medicali, energia e dispositivi embedded.

La cosa interessante del CAN è che non funziona come una rete classica con un computer centrale che gestisce tutto. In una rete CAN, più nodi possono comunicare sullo stesso bus. In un veicolo moderno, per esempio, centralina motore, ABS, cambio automatico, quadro strumenti, servosterzo, climatizzazione, body computer e sistemi ADAS possono scambiarsi informazioni attraverso una o più reti CAN.

Il CAN però non va confuso con Ethernet, TCP/IP o reti basate su indirizzi. Non esistono indirizzi IP, non ci sono pacchetti TCP o UDP e non c'è il concetto classico di "mittente-destinatario". Sul CAN viaggiano frame identificati da un CAN ID. Tutti i nodi ascoltano il bus, ricevono i frame e poi decidono se elaborarli o ignorarli.

Questo punto è fondamentale: il CAN trasporta frame, non "valori già pronti". Il significato dei dati dipende dal livello applicativo, dal DBC o dal protocollo usato sopra il CAN.

1. Perché esiste il CAN

Prima della diffusione del CAN, collegare molti sensori, attuatori e centraline significava usare una grande quantità di collegamenti punto-punto. Ogni segnale aveva bisogno del suo cablaggio dedicato. Più funzioni significavano più fili, più peso, più complessità, più costo e più possibilità di guasto.

Il CAN nasce proprio per risolvere questo problema: invece di collegare tutto punto-punto, si crea una rete condivisa a due fili. Tutti i nodi si collegano allo stesso bus e possono trasmettere messaggi quando il bus è libero.

I vantaggi principali sono questi:

Questo è uno dei motivi per cui il CAN è ancora così usato: è semplice nella struttura, ma molto solido nel comportamento.

2. Il CAN nel modello OSI

Per capire bene dove si posiziona il CAN, conviene guardarlo nel modello OSI.

Il CAN classico definisce soprattutto due livelli:

• livello fisico, cioè cablaggio, segnali elettrici, transceiver, terminazioni, CAN High e CAN Low;
• livello data link, cioè frame, arbitraggio, CRC, ACK, gestione errori e accesso al bus.

Tutto quello che riguarda il significato applicativo dei dati, invece, viene gestito da protocolli superiori.

Schema semplificato:

Questa distinzione è importantissima: il CAN da solo non definisce il significato dei dati.

Il CAN trasporta byte. Il significato di quei byte viene definito da DBC, UDS, J1939, CANopen, OBD2 o da protocolli proprietari.

In altre parole: il CAN è il mezzo di trasporto. Il linguaggio vero e proprio spesso sta sopra.

3. Architettura di una rete CAN

Una rete CAN è composta da più nodi collegati allo stesso bus.

Un nodo può essere:

• una ECU;
• un sensore intelligente;
• un attuatore;
• un gateway;
• un data logger;
• un'interfaccia CAN-USB;
• uno strumento diagnostico;
• un display HMI;
• un modulo embedded.

Un nodo CAN tipico contiene questi elementi:

In molte MCU moderne il CAN controller è già integrato nel microcontrollore. Il transceiver, invece, è spesso un componente esterno.

Questa separazione è importante: il controller lavora a livello logico, mentre il transceiver lavora sul bus fisico. Quindi un problema CAN può nascere nel software, ma anche nel transceiver, nei cavi, nelle terminazioni o nella topologia della rete.

Una rete CAN high-speed è un bus condiviso: ogni nodo si collega tramite transceiver, mentre le due estremità della linea principale sono terminate.

Una rete CAN high-speed usa normalmente due fili:

• CAN High, abbreviato CAN_H;
• CAN Low, abbreviato CAN_L.

Spesso questi due fili sono twistati, cioè avvolti tra loro, per migliorare l'immunità ai disturbi elettromagnetici.

4. Livello fisico: CAN High, CAN Low e trasmissione differenziale

Il CAN usa una trasmissione differenziale.

Questo significa che il ricevitore non interpreta il valore assoluto di un singolo filo, ma la differenza di tensione tra CAN_H e CAN_L.

In modo semplificato:

Il punto chiave è che un disturbo elettromagnetico tende a influenzare entrambi i fili in modo simile. Il ricevitore, però, guarda la differenza tra i due segnali. Questo rende il CAN molto più resistente ai disturbi rispetto a un segnale single-ended.

Detto questo, il CAN non è immune agli errori se la rete è progettata male.

Nelle reti high-speed CAN la topologia consigliata è una linea principale con derivazioni corte. Le terminazioni sono fondamentali: normalmente servono due resistenze da 120 ohm, una per ciascuna estremità del bus.

Con due terminazioni corrette da 120 ohm alle estremità, la resistenza misurata tra CAN_H e CAN_L a rete spenta è circa:

120 ohm || 120 ohm = 60 ohm

Quindi, nella pratica:

• se misuro circa 60 ohm, le terminazioni sono probabilmente corrette;
• se misuro molto più di 60 ohm, potrebbe mancare una terminazione;
• se misuro molto meno di 60 ohm, potrebbero esserci troppe terminazioni o un corto.

È uno dei primi controlli da fare quando una rete CAN non comunica.

5. Dominante e recessivo: la logica del CAN

Nel CAN esistono due stati fondamentali:

Il bus CAN si comporta come una logica wired-AND: se almeno un nodo trasmette un bit dominante, il bus diventa dominante. Il bus rimane recessivo solo se tutti i nodi trasmettono recessivo.

Questo meccanismo è alla base di due funzioni importantissime:

• l'arbitraggio dei messaggi;
• il rilevamento degli errori tramite bit monitoring.

Un nodo che trasmette non si limita a inviare dati: legge continuamente il bus. Se trasmette recessivo ma legge dominante, capisce che qualcun altro sta imponendo un bit dominante.

Ed è proprio questa caratteristica che permette al CAN di gestire più trasmissioni contemporanee senza distruggere il messaggio vincente.

6. Arbitraggio CAN: priorità senza collisioni distruttive

Il CAN è una rete multi-master.

Non esiste un master unico che autorizza gli altri nodi a parlare. Qualunque nodo può iniziare a trasmettere quando il bus è libero.

Se due o più nodi iniziano a trasmettere nello stesso momento, il CAN usa l'arbitraggio bit a bit sul campo identificatore.

Durante l'arbitraggio, ogni nodo trasmette il proprio ID e legge contemporaneamente il bus. Poiché il bit dominante vince sul recessivo, il messaggio con l'ID numericamente più basso vince l'arbitraggio.

Il nodo che perde si ferma e riproverà più tardi. Il messaggio che vince continua senza essere corrotto. Per questo si parla di arbitraggio non distruttivo.

Esempio semplificato:

Durante l'arbitraggio, un nodo che trasmette recessivo ma legge dominante perde e si ferma, mentre il frame vincente continua.

Il Nodo A vince perché il suo ID contiene prima un bit dominante dove il Nodo B trasmette recessivo.

La conseguenza pratica è molto importante: i messaggi più urgenti devono avere ID più bassi.

In una rete automotive, messaggi legati a freni, motore, coppia, sicurezza o controllo dinamico del veicolo devono avere priorità più alta rispetto a messaggi di comfort, climatizzazione o infotainment.

7. Formato dei messaggi CAN

Il CAN trasmette dati sotto forma di frame.

Nel CAN classico esistono due formati principali:

Il frame standard a 11 bit consente 2048 identificatori teorici.

Il frame esteso a 29 bit consente molti più identificatori ed è molto usato da protocolli come SAE J1939.

Un errore comune è pensare che il CAN ID sia l'indirizzo del destinatario. In realtà, nel CAN classico il CAN ID identifica soprattutto il tipo di messaggio e la sua priorità.

Tutti i nodi ricevono fisicamente il frame, ma solo quelli interessati lo elaborano.

8. Struttura di un data frame CAN classico

Un CAN data frame classico contiene diversi campi.

SOF - Start of Frame

È un bit dominante che segnala l'inizio di un nuovo frame. Serve anche alla sincronizzazione dei nodi.

Arbitration Field

Contiene il CAN ID e i bit necessari per distinguere frame standard, frame estesi e remote frame. È il campo usato per determinare quale messaggio vince se più nodi iniziano a trasmettere nello stesso momento.

Control Field

Contiene il DLC, cioè Data Length Code. Nel CAN classico il DLC indica quanti byte sono presenti nel payload, da 0 a 8.

Data Field

Contiene i dati veri e propri. Nel CAN classico il payload massimo è di 8 byte, cioè 64 bit.

CRC Field

Serve a rilevare errori di trasmissione. Il trasmettitore calcola un codice CRC e i ricevitori verificano se il valore ricevuto è coerente con il contenuto del frame.

ACK Field

Il trasmettitore invia il bit ACK come recessivo. Se almeno un ricevitore ha ricevuto correttamente il frame, forza il bit ACK a dominante.

In questo modo il trasmettitore sa che almeno un nodo ha riconosciuto il messaggio.

EOF

Indica la fine del frame ed è formato da una sequenza recessiva.

9. Tipi di frame CAN

Nel CAN classico esistono quattro tipi principali di frame:

Nelle reti moderne il più importante è il data frame.

I remote frame sono poco usati nelle architetture attuali, soprattutto perché molti protocolli superiori preferiscono usare normali messaggi richiesta-risposta.

Inoltre, il remote frame non è supportato da CAN FD.

10. Bit timing: come i nodi restano sincronizzati

Il CAN non trasmette un clock separato.

Tutti i nodi devono quindi sincronizzarsi sui fronti del segnale. Per questo il bit timing è una parte fondamentale della configurazione CAN.

Ogni bit viene diviso in unità temporali chiamate time quanta. Questi time quanta sono organizzati in segmenti logici.

I principali segmenti sono:

Il sample point è particolarmente importante: è l'istante in cui il controller legge il valore del bit.

Un bit timing errato può causare:

• errori intermittenti;
• frame persi;
• error frame frequenti;
• bus-off;
• comunicazione instabile;
• problemi che compaiono solo con certe temperature o lunghezze cavo.

Parametri tipici da configurare in un controller CAN:

Esempi di bitrate comuni:

Il bitrate giusto non basta da solo. Anche sample point, SJW e segmenti devono essere coerenti con il bus fisico e con gli altri nodi.

11. Bit stuffing

Il CAN usa il bit stuffing per mantenere abbastanza transizioni sul bus e facilitare la sincronizzazione.

La regola è questa: dopo cinque bit consecutivi dello stesso valore, il trasmettitore inserisce automaticamente un bit complementare.

Quindi, dopo cinque bit dominanti consecutivi viene inserito un bit recessivo. Dopo cinque bit recessivi consecutivi viene inserito un bit dominante.

Esempio:

Sequenza originale:

00000

Sequenza trasmessa con stuffing:

000001

Il bit aggiunto non fa parte dei dati applicativi. Il ricevitore lo rimuove automaticamente durante la ricezione.

Se un ricevitore vede sei bit consecutivi uguali in una parte del frame dove il bit stuffing è previsto, viene generato uno stuff error.

Il bit stuffing ha anche una conseguenza pratica: la lunghezza reale di un frame può variare leggermente in base al contenuto del payload, perché alcuni dati generano più stuff bit di altri.

12. Messaggio CAN e segnale CAN: differenza fondamentale

Nel linguaggio comune si parla spesso di "segnali CAN", ma tecnicamente il bus trasporta frame.

Il segnale è un'informazione logica contenuta dentro il payload di un frame.

Quindi:

• un messaggio CAN è il frame identificato da un CAN ID;
• un segnale CAN è una variabile contenuta nel campo dati del frame.

Esempio:

Un payload CAN classico contiene al massimo 8 byte. Dentro questi 8 byte possono essere codificati più segnali, ognuno con:

• bit iniziale;
• lunghezza in bit;
• byte order;
• signedness;
• scala;
• offset;
• unità di misura;
• range valido;
• valore fisico.

Questa distinzione è una delle più importanti in assoluto: il frame è il contenitore, il segnale è l'informazione interpretata.

13. DBC: il database che dà significato ai byte

Un log CAN grezzo può apparire così:

timestamp: 12.345678ID: 0x0CF00400DLC: 8DATA: FF FF FF 68 13 FF FF FF

Senza una descrizione del contenuto, questi byte sono quasi inutili.

Per decodificarli si usa spesso un file DBC, cioè un database CAN.

Un DBC descrive messaggi e segnali, includendo informazioni come start bit, lunghezza, byte order, signedness, scala e offset.

Elementi tipici di un DBC:

La formula di conversione è:

valore fisico = valore grezzo * factor + offset

Esempio DBC semplificato:

BO_ 256 EngineData: 8 ECU_Engine SG_ EngineSpeed : 0|16@1+ (0.125,0) [0|8000] "rpm" ECU_Dashboard SG_ CoolantTemp : 16|8@1+ (1,-40) [-40|215] "degC" ECU_Dashboard SG_ Torque      : 24|16@1- (0.1,0) [-3200|3200] "Nm" ECU_Gateway

Interpretazione:

• BO_ 256 definisce un messaggio con ID decimale 256, cioè 0x100;
• EngineData è il nome del messaggio;
• 8 è il DLC;
• EngineSpeed parte dal bit 0, è lungo 16 bit, little-endian e unsigned;
• il valore fisico dei giri motore è raw * 0.125;
• CoolantTemp usa offset -40, quindi un valore raw di 90 corrisponde a 50 deg C.

Questa parte è essenziale: il CAN non dice da solo che un byte rappresenta temperatura, velocità o coppia. Il significato viene dal database.

14. Endianness: Intel e Motorola

Uno degli aspetti più delicati nella decodifica CAN è l'endianness.

Nel DBC si trovano spesso due formati:

L'endianness determina come i bit di un segnale multi-byte vengono ordinati nel payload.

Un errore di endianness può produrre valori completamente sbagliati anche se ID, scala e offset sono corretti.

Esempio:

Payload:

10 27

Se interpretato little-endian:

0x2710 = 10000

Se interpretato big-endian:

0x1027 = 4135

Il risultato fisico può quindi cambiare drasticamente.

Questa è una delle prime cose da controllare quando un valore decodificato "sembra plausibile ma non torna".

15. Acceptance filtering

Ogni nodo CAN riceve fisicamente tutti i frame presenti sul bus, ma non tutti i frame sono utili.

Per evitare di sovraccaricare il microcontrollore, il CAN controller può usare filtri hardware di accettazione.

Un filtro può accettare solo:

• determinati ID;
• range di ID;
• ID standard;
• ID estesi;
• frame con certe maschere.

Esempi:

Il filtro non impedisce al frame di circolare sul bus. Serve solo al nodo per decidere cosa portare al software applicativo.

Quindi, se un messaggio "non arriva" al software, non sempre significa che non esista sul bus. Potrebbe essere stato filtrato a livello hardware.

16. Gestione degli errori nel CAN

Il CAN è molto robusto perché integra diversi meccanismi di rilevamento errore.

I principali errori sono:

Quando viene rilevato un errore, un nodo trasmette un error frame.

Il messaggio viene invalidato e il trasmettitore tenterà di ritrasmetterlo.

Questa gestione automatica degli errori è uno dei motivi per cui il CAN è molto adatto ad ambienti rumorosi e applicazioni real-time.

17. Error active, error passive e bus-off

Ogni nodo CAN mantiene contatori interni di errore, tipicamente:

• TEC, Transmit Error Counter;
• REC, Receive Error Counter.

In base a questi contatori, un nodo può trovarsi in tre stati:

Il bus-off è una protezione importante: se un nodo difettoso genera continuamente errori, il protocollo può isolarlo per evitare che renda inutilizzabile l'intera rete.

Cause tipiche di bus-off:

• bitrate errato;
• cablaggio difettoso;
• transceiver guasto;
• assenza di ACK;
• terminazioni errate;
• disturbi elettrici;
• massa non comune;
• bug software che trasmette continuamente frame errati.

Nella pratica, quando un nodo va in bus-off, non bisogna guardare solo il firmware. Bisogna controllare anche cablaggio, terminazioni, bitrate e presenza di altri nodi attivi sul bus.

18. Frequenza messaggi e bus load

In una rete CAN i messaggi possono essere:

• periodici;
• event-driven;
• su richiesta;
• diagnostici;
• ciclici con timeout.

Esempio:

Il bus load indica quanta capacità della rete è occupata dai frame.

Una rete CAN troppo carica può introdurre ritardi, peggiorare la latenza dei messaggi meno prioritari e rendere più difficile la diagnostica.

In progettazione bisogna considerare:

• lunghezza media dei frame;
• bitrate;
• frequenza dei messaggi;
• priorità;
• numero di nodi;
• traffico diagnostico;
• margine libero per future estensioni.

Una regola prudente è evitare di progettare reti costantemente vicine al 100% di carico. Nelle applicazioni reali serve margine per ritrasmissioni, diagnostica e condizioni anomale.

Una rete che funziona in condizioni ideali ma non ha margine può diventare instabile appena aumenta il traffico o compare un errore.

19. Protocolli superiori: CAN come base, non come applicazione completa

Il CAN definisce il trasporto di frame, ma non definisce da solo il significato applicativo dei dati.

Per questo esistono protocolli superiori.

I più importanti sono:

Quindi il CAN è la base. Sopra, ogni settore costruisce il proprio modo di rappresentare dati, diagnostica, configurazioni e comandi.

20. OBD2 su CAN

OBD2, cioè On-Board Diagnostics, è il sistema diagnostico standard usato sui veicoli per accedere a parametri e codici errore legati soprattutto a emissioni e funzionamento motore.

OBD2 usa il concetto di PID, Parameter ID.

Un tester invia una richiesta e la ECU risponde con il dato richiesto.

Esempio concettuale:

OBD2 è utile, ma limitato. Espone solo una parte dei dati disponibili nel veicolo.

I dati più dettagliati sono spesso disponibili tramite UDS o protocolli proprietari.

21. UDS e ISO-TP

UDS, cioè Unified Diagnostic Services, è un protocollo diagnostico usato per diagnosi avanzata, test, lettura dati, scrittura parametri, reset centraline e aggiornamenti firmware.

UDS lavora spesso sopra CAN usando ISO-TP, cioè ISO 15765-2.

Il motivo è semplice: il CAN classico può trasportare solo 8 byte per frame, mentre molte risposte diagnostiche sono più lunghe.

ISO-TP risolve questo problema segmentando messaggi più grandi in più frame CAN.

ISO-TP usa diversi tipi di frame:

Esempio UDS:

Richiesta lettura VIN:

22 F1 90

Dove:

• 0x22 è il servizio UDS ReadDataByIdentifier;
• 0xF190 è un DID comunemente usato per il VIN.

Una risposta VIN è più lunga di 8 byte, quindi viene segmentata tramite ISO-TP.

Questo è un esempio perfetto per capire il rapporto tra i livelli: il CAN trasporta i frame, ISO-TP gestisce il trasporto multi-frame, UDS definisce il significato diagnostico della richiesta.

22. SAE J1939

SAE J1939 è un protocollo superiore basato su CAN, molto diffuso in veicoli pesanti, camion, autobus, macchine agricole, motori industriali e mezzi off-highway.

J1939 usa identificatori CAN estesi a 29 bit.

Nel mondo J1939, un concetto centrale è il PGN, cioè Parameter Group Number. Il PGN è un sottoinsieme dell'ID CAN esteso a 29 bit e rappresenta l'identificatore logico del messaggio.

Struttura semplificata dell'ID J1939:

Concetti chiave:

Esempi di PGN:

Nel mondo J1939, il DBC viene spesso costruito a livello PGN/SPN più che a livello di singolo ID fisico.

Questo rende J1939 molto strutturato e adatto a mezzi complessi dove motore, trasmissione, freni, attrezzi e moduli esterni devono comunicare in modo standardizzato.

23. CANopen

CANopen è un protocollo superiore usato soprattutto in automazione industriale, motion control, robotica, inverter, sensori intelligenti e macchine.

Concetti principali:

CANopen aggiunge al CAN una struttura applicativa completa.

Mentre il CAN definisce come trasmettere frame, CANopen definisce come rappresentare oggetti, parametri, stati e dati ciclici.

È molto usato quando serve una rete ordinata, con dispositivi configurabili e comportamento standardizzato.

24. CAN FD: evoluzione del CAN classico

Il CAN classico ha due limiti importanti:

• payload massimo di 8 byte;
• velocità massima nominale tipicamente fino a 1 Mbit/s.

CAN FD, cioè CAN Flexible Data-rate, è stato introdotto per superare questi limiti.

CAN FD permette due bitrate diversi:

• uno nella fase di arbitraggio;
• uno più alto nella fase dati.

Inoltre aumenta il payload massimo fino a 64 byte.

Differenze principali:

Campi importanti CAN FD:

Il BRS, Bit Rate Switch, permette di trasmettere la fase dati a velocità superiore rispetto alla fase di arbitraggio.

CAN FD è utile per:

• flashing ECU;
• diagnostica più veloce;
• logging ad alta quantità di dati;
• sensori con payload più grandi;
• reti automotive moderne;
• riduzione dell'overhead per byte utile.

In pratica, CAN FD mantiene molte idee del CAN classico, ma aumenta capacità ed efficienza.

25. CAN XL: evoluzione successiva

CAN XL, cioè CAN eXtended data-field Length, è l'evoluzione successiva dopo CAN classico e CAN FD.

CAN XL supporta campi dati da 1 byte fino a 2048 byte.

Confronto:

CAN XL introduce anche una distinzione più chiara tra priorità e accettazione.

In CAN classico e CAN FD, l'ID serve sia per arbitraggio sia per identificazione. In CAN XL, invece, queste funzioni vengono separate tramite un priority ID a 11 bit e un acceptance field a 32 bit.

CAN XL è pensato per casi in cui servono:

• payload molto grandi;
• maggiore efficienza;
• integrazione con architetture moderne;
• trasporto di dati complessi;
• possibile collegamento con reti IP;
• aggiornamenti software più efficienti.

CAN XL non sostituisce immediatamente CAN classico o CAN FD, ma amplia la famiglia CAN verso applicazioni più esigenti.

26. Logging CAN: dal frame grezzo al dato fisico

Per analizzare una rete CAN si registra il traffico con strumenti come:

• interfacce CAN-USB;
• data logger standalone;
• strumenti Vector;
• Kvaser;
• Peak;
• CSS Electronics;
• oscilloscopi;
• gateway CAN-Ethernet;
• software SocketCAN;
• strumenti di sniffing e reverse engineering.

Un log grezzo contiene tipicamente:

Esempio formato candump:

can0  100   [8]  10 27 5A 00 80 01 00 FFcan0  200   [8]  34 12 00 00 01 00 AA 55

Decodifica tramite DBC:

EngineSpeed = 1250 rpmCoolantTemp = 50 deg CBrakePressed = falseVehicleSpeed = 86.5 km/h

Il flusso corretto di analisi è:

• identificare bitrate e formato frame;
• registrare il traffico;
• distinguere frame standard ed extended;
• applicare il DBC corretto;
• validare scala, offset ed endianness;
• verificare frequenze e timeout;
• correlare i segnali con eventi reali;
• controllare error frame e bus load.

Questa è la differenza tra guardare byte e fare davvero analisi CAN.

27. Reverse engineering dei segnali CAN

Quando non è disponibile un DBC ufficiale, può essere necessario fare reverse engineering.

Il metodo tipico è:

Esempio per trovare il segnale freno:

• registrare il traffico con freno rilasciato;
• premere il freno;
• confrontare i payload;
• cercare bit che cambiano da 0 a 1;
• verificare la ripetibilità;
• creare il segnale nel DBC.

Esempio per trovare la velocità:

• registrare a veicolo fermo;
• registrare a 20, 40 e 60 km/h;
• cercare valori che crescono linearmente;
• stimare factor e offset;
• validare con GPS o OBD2.

Qui serve molta attenzione. In veicoli moderni il reverse engineering può avere implicazioni legali, di sicurezza e di garanzia.

Va fatto solo in ambienti controllati e senza inviare frame attivi su reti critiche, a meno di sapere esattamente cosa si sta facendo.

28. Diagnostica pratica di una rete CAN

Quando una rete CAN non funziona correttamente, bisogna analizzare sia il livello fisico sia quello logico.

Controlli fisici

Controlli logici

Oscilloscopio

Con l'oscilloscopio si possono osservare:

• ampiezza differenziale;
• fronti troppo lenti;
• riflessioni;
• rumore;
• overshoot;
• distorsioni;
• simmetria tra CAN_H e CAN_L.

Un analizzatore logico o un'interfaccia CAN può dire che ci sono errori. L'oscilloscopio aiuta a capire se la causa è fisica.

Questa differenza è fondamentale: il software può sembrare il problema, ma il bus fisico può raccontare un'altra storia.

29. Sicurezza informatica del CAN

Il CAN classico è stato progettato per reti chiuse e controllate.

Non include nativamente:

• autenticazione del mittente;
• cifratura;
• controllo permessi;
• protezione contro replay attack;
• protezione forte contro spoofing;
• isolamento automatico tra domini funzionali.

Questo significa che un nodo con accesso al bus può potenzialmente ascoltare o iniettare frame.

Nei veicoli moderni il problema viene mitigato con:

• gateway;
• segmentazione;
• firewall automotive;
• secure diagnostics;
• intrusion detection system;
• controlli a livello applicativo.

Rischi tipici:

La sicurezza non va risolta solo a livello CAN. Va pensata a livello di architettura veicolo o macchina.

Il CAN è robusto come protocollo di comunicazione, ma non è sicuro per definizione dal punto di vista cybersecurity.

30. Errori comuni da evitare

Gli errori più frequenti nella progettazione o analisi CAN sono:

• confondere CAN ID e indirizzo destinatario;
• pensare che il CAN trasporti direttamente valori fisici;
• usare un DBC sbagliato;
• ignorare endianness e signedness;
• configurare un bitrate errato;
• dimenticare le terminazioni;
• usare troppe terminazioni;
• creare derivazioni troppo lunghe;
• trasmettere frame su una rete reale senza sapere l'effetto;
• non considerare bus load e priorità;
• non distinguere CAN classico, CAN FD e CAN XL;
• usare un'interfaccia non compatibile con CAN FD su una rete CAN FD;
• ignorare error counter e stato bus-off;
• analizzare solo il software senza controllare il livello fisico.

Molti problemi CAN nascono proprio da qui: si guarda il log, ma non si controlla il bus. Oppure si controlla il cablaggio, ma si ignora il DBC. Serve sempre una visione completa.

31. Esempio completo: da frame a valore fisico

Vediamo un esempio completo.

Frame ricevuto:

ID: 0x100DLC: 8DATA: 10 27 82 00 2C 01 00 FF

DBC semplificato:

BO_ 256 EngineData: 8 ECU_Engine SG_ EngineSpeed : 0|16@1+ (0.125,0) [0|8000] "rpm" ECU_Dashboard SG_ CoolantTemp : 16|8@1+ (1,-40) [-40|215] "degC" ECU_Dashboard SG_ PedalPos    : 32|8@1+ (0.4,0) [0|100] "%" ECU_Dashboard

EngineSpeed

Byte 0-1:

10 27

Little-endian:

0x2710 = 10000

Scala:

10000 * 0.125 = 1250 rpm

CoolantTemp

Byte 2:

0x82 = 130

Scala e offset:

130 * 1 - 40 = 90 deg C

PedalPos

Byte 4:

0x2C = 44

Scala:

44 * 0.4 = 17.6 %

Risultato finale:

Questo esempio mostra il punto chiave: il frame contiene solo byte. È il DBC che permette di trasformarli in dati ingegneristici.

Senza DBC, 10 27 82 00 2C 01 00 FF resta solo una sequenza di byte. Con il DBC corretto, diventa informazione utile.

32. Confronto finale: CAN, CAN FD e CAN XL

Il CAN classico rimane ancora molto usato per comunicazioni semplici, robuste e deterministiche.

CAN FD è oggi la scelta più adatta quando servono più dati e maggiore velocità.

CAN XL rappresenta l'evoluzione più recente per architetture che richiedono payload molto più ampi e migliore integrazione con reti moderne.

Non bisogna pensarli come tre tecnologie in competizione diretta. Sono tre livelli di evoluzione della stessa famiglia, da scegliere in base al tipo di applicazione.

33. Conclusione

Il protocollo CAN è uno dei pilastri della comunicazione embedded e automotive perché combina semplicità, robustezza, priorità deterministica e gestione avanzata degli errori.

Per comprenderlo davvero bisogna distinguere tre livelli.

• Livello fisico: cavi, CAN_H, CAN_L, terminazioni, transceiver, livelli differenziali, topologia, lunghezza bus e qualità del segnale.
• Livello data link: frame, ID, arbitraggio, bit stuffing, CRC, ACK, error frame, error counter e bus-off.
• Livello applicativo: significato dei dati, segnali, DBC, diagnostica, OBD2, UDS, ISO-TP, J1939, CANopen e protocolli proprietari.

Il CAN non trasmette direttamente "velocità", "temperatura" o "coppia". Trasmette frame binari.

Il significato dei frame nasce dal modo in cui i bit sono mappati in segnali, scalati e interpretati.

Per questo, in un'analisi professionale, non basta saper leggere un CAN ID. Bisogna conoscere il livello fisico, la struttura dei frame, il timing, il DBC, gli errori, i protocolli superiori e il contesto applicativo.

In sintesi, il CAN è una tecnologia apparentemente semplice, ma estremamente raffinata.

La sua efficacia deriva dalla combinazione di trasmissione differenziale, arbitraggio non distruttivo, priorità deterministica, rilevamento errori e flessibilità applicativa.

Ed è proprio questa combinazione che lo rende ancora oggi essenziale in veicoli, macchine industriali e sistemi embedded moderni.

Ultimo aggiornamento 2026-07-06.
Sorgente dell’articolo content/blog/can_protocol.