Il CAN è stato per decenni uno dei linguaggi più affidabili delle macchine. Controller, sensori, attuatori, pannelli operatore e moduli di sicurezza hanno potuto scambiarsi informazioni con priorità prevedibili e con una robustezza adatta a contesti industriali e automotive. Oggi, però, una macchina non trasmette più soltanto pochi comandi e stati: deve gestire diagnostica più ricca, feedback ad alta frequenza, HMI evolute, aggiornamenti, dati di più sensori e componenti software distribuiti.
In questo scenario CAN XL non rappresenta semplicemente un CAN più veloce. È la terza generazione del protocollo CAN, progettata per aumentare in modo rilevante la quantità di dati trasportabili senza abbandonare i principi che hanno reso il bus così diffuso nei sistemi di controllo.
La notizia che rende il tema particolarmente attuale arriva dagli Stati Uniti. Il 12 agosto 2026 Texas Instruments ha annunciato il TCAN6062, presentato come il primo transceiver CAN XL disponibile commercialmente. Il componente porta il protocollo dalla standardizzazione alla concreta disponibilità di hardware per prodotti industriali, robot, sistemi HMI e architetture di controllo di nuova generazione.
Per chi sviluppa una macchina, un dispositivo embedded o un prodotto con più nodi elettronici, la domanda non è quindi “dobbiamo sostituire il CAN?”. La domanda più utile è: la nostra architettura di comunicazione continuerà a essere sufficiente quando aumenteranno dati, funzioni software, sensori e richieste di diagnosi?
Da CAN classico a CAN XL: perché l’evoluzione non riguarda solo la velocità
Il CAN classico è nato per reti di controllo nelle quali messaggi brevi e prioritari devono arrivare in modo affidabile. CAN FD ha già esteso questa logica, aumentando la dimensione del campo dati e permettendo di gestire meglio firmware più ricchi, diagnostica e funzioni aggiuntive.
CAN XL compie un passo ulteriore. Secondo CAN in Automation, l’associazione internazionale che cura l’ecosistema CAN, il protocollo può utilizzare campi dati fino a 2.048 byte e throughput configurabili fino a 20 Mbit/s. La stessa organizzazione indica CAN XL come la terza generazione CAN, insieme a CAN classico e CAN FD, nelle specifiche ISO 11898-1:2024.
| Tecnologia | Ruolo tipico | Limite del campo dati |
|---|---|---|
| CAN classico | Comandi, stati e segnali di controllo essenziali. | 8 byte per frame. |
| CAN FD | Reti con più diagnostica, dati applicativi e necessità di maggiore efficienza. | 64 byte per frame. |
| CAN XL | Architetture con flussi dati più ampi, robotica, HMI evolute e integrazione con reti IP. | Fino a 2.048 byte per frame. |
La differenza ha un effetto pratico importante. Quando un dato deve essere frammentato in molti messaggi CAN FD, non aumenta soltanto il tempo di trasmissione: crescono anche il carico sul bus, la complessità del firmware, il numero di casi da verificare e la difficoltà di mantenere prevedibili i tempi di risposta sotto carico.
CAN XL consente di ragionare su pacchetti più grandi senza perdere il principio di arbitraggio del CAN. I messaggi più importanti possono continuare a ottenere priorità, mentre la rete dispone di maggiore spazio per diagnostica, parametri, dati sensore e aggiornamenti.
Perché robot, HMI e macchine industriali stanno creando un nuovo problema di rete
Una macchina industriale moderna non è più una catena lineare nella quale un PLC invia un comando e un attuatore restituisce uno stato. È sempre più spesso un sistema distribuito: azionamenti, moduli I/O, pannelli HMI, controllori di sicurezza, gateway, telecamere, sensori intelligenti e software di assistenza devono convivere senza trasformare la rete in un collo di bottiglia.
Nei robot industriali, ad esempio, il controllo del movimento richiede priorità e tempi prevedibili. Parallelamente, il sistema può dover raccogliere dati da encoder, sensori di coppia, temperature, diagnostica degli azionamenti e dati utili alla manutenzione. Nelle HMI, invece, aumentano configurazioni, ricette, log di servizio, parametri di processo e informazioni visualizzate all’operatore.
La necessità non nasce soltanto dall’intelligenza artificiale o dal cloud. Anche senza inviare ogni dato all’esterno, l’edge computing porta più elaborazione vicino alla macchina. Questo significa che nodi locali devono scambiarsi informazioni più ricche, mantenendo però una base di controllo affidabile e comprensibile per chi dovrà assistere il prodotto negli anni.
Texas Instruments cita proprio robot umanoidi, robot industriali e sistemi HMI tra gli scenari d’uso del nuovo transceiver. Il valore dell’annuncio non è quindi legato a un singolo componente: indica che le architetture CAN ad alta capacità stanno iniziando a diventare un’opzione concreta anche fuori dalla sola discussione teorica sul protocollo.
Il primo hardware commerciale cambia il momento della valutazione
CAN XL non è una tecnologia nata nell’agosto 2026. La parte protocollo e il livello fisico sono già stati standardizzati. La novità è che la disponibilità di un transceiver commerciale rende possibile costruire una reale catena di valutazione: controller compatibile, transceiver, topologia di rete, firmware, strumenti di test e prototipo.
Il TCAN6062 dichiara supporto ai requisiti fisici CAN XL dell’ISO 11898-2:2024. Il datasheet ufficiale specifica inoltre modalità pensate per ridurre gli effetti di ringing nelle topologie complesse e per gestire la fase dati veloce. Questo non elimina il lavoro di progettazione della rete; al contrario, conferma che a velocità elevate cablaggio, terminazioni, lunghezza delle diramazioni e qualità del segnale diventano parte integrante del progetto, non dettagli da correggere alla fine.
È importante evitare un equivoco: sostituire il transceiver non trasforma automaticamente una macchina esistente in un sistema CAN XL. Il controller deve supportare il protocollo, il firmware deve gestire il nuovo stack, la rete deve essere verificata sul piano fisico e il comportamento dei nodi esistenti deve essere progettato con attenzione. TI evidenzia la compatibilità del componente con reti CAN FD e CAN SIC in modalità mista, ma il percorso reale dipende dall’architettura del prodotto e non può essere ridotto alla sostituzione di un singolo chip.
CAN XL non sostituisce automaticamente Ethernet
Quando crescono i dati, la prima reazione è spesso introdurre Ethernet. In molte applicazioni è una scelta corretta: Ethernet resta adatta quando servono grandi flussi, reti IP complete, telecamere, collegamenti a PC industriali, gateway e infrastrutture aziendali.
CAN XL affronta però un problema diverso. Mantiene l’arbitraggio non distruttivo del CAN, quindi la possibilità di assegnare priorità ai messaggi che non possono aspettare. Può essere una soluzione interessante quando controllo, sensori e diagnosi devono condividere la stessa architettura senza imporre a tutti i nodi la complessità di una rete Ethernet completa.
Le due tecnologie possono anche convivere. CAN in Automation descrive la possibilità di mappare frame Ethernet in frame CAN XL, mentre Texas Instruments indica il supporto al tunneling TCP/IP in architetture miste. Questo non significa che CAN XL renda Ethernet superflua. Significa che un prodotto può usare Ethernet dove serve ampia connettività e utilizzare CAN XL dove sono più importanti priorità, controllo distribuito e continuità con il patrimonio esistente di nodi CAN.
La scelta non dovrebbe essere “CAN XL oppure Ethernet?”, ma “quali dati devono essere trasmessi, quali hanno priorità, quali nodi devono restare semplici e quale architettura potrà essere mantenuta dopo la consegna?”
Quando ha senso valutare CAN XL in un nuovo prodotto
CAN XL non è necessario per ogni scheda con un microcontrollore. Un sensore semplice, un attuatore a bassa frequenza o una macchina con pochi messaggi brevi possono continuare a funzionare in modo ottimale con CAN classico o CAN FD.
Il tema diventa interessante quando il team sta già incontrando limiti concreti: il bus è molto carico, la diagnostica viene ridotta per non rallentare il controllo, dati utili vengono trasferiti su una seconda rete non ben integrata, oppure l’HMI richiede una quantità crescente di informazioni dai moduli periferici.
| Domanda da porsi | Perché è rilevante |
|---|---|
| I messaggi CAN FD devono essere continuamente frammentati? | La frammentazione aumenta overhead, complessità applicativa e casi da testare. |
| Il controllo deve condividere la rete con diagnostica e dati sensore più ricchi? | Serve garantire priorità ai messaggi critici senza rinunciare alla visibilità del sistema. |
| Il prodotto evolverà con nuovi moduli, HMI o funzioni software? | Una rete dimensionata solo sul prototipo può diventare un limite durante l’industrializzazione. |
| Esistono già nodi CAN FD da preservare? | La migrazione può essere graduale, ma deve essere pianificata a livello di architettura. |
La decisione non dovrebbe derivare dal dato di picco dichiarato dal protocollo. Una rete progettata per 20 Mbit/s non garantisce automaticamente 20 Mbit/s in qualsiasi topologia. Il risultato dipende dalle caratteristiche fisiche della macchina: numero dei nodi, lunghezza dei cavi, diramazioni, connettori, disturbi elettromagnetici, alimentazione e condizioni ambientali.
È qui che il proof of concept è più utile di una scelta a catalogo. Prima di definire la PCB definitiva, è possibile simulare il carico, analizzare il traffico previsto, costruire una rete rappresentativa e misurare latenza, errori, comportamento degradato e capacità di diagnosi.
La migrazione non è un aggiornamento del bus: è una decisione di architettura
In un prodotto già esistente, migrare verso CAN XL richiede di valutare insieme hardware, firmware e processo di assistenza. Il primo passo non è scegliere il componente: è capire cosa oggi attraversa la rete, con quale frequenza, quali dati sono realmente indispensabili e dove stanno nascendo i colli di bottiglia.
Successivamente devono essere confrontate le opzioni. In alcuni casi sarà sufficiente ottimizzare il protocollo applicativo. In altri sarà più adatto mantenere CAN FD per il controllo e aggiungere Ethernet per una specifica funzione. CAN XL diventa particolarmente interessante quando serve ridurre la frammentazione, aumentare il margine evolutivo e conservare la logica di priorità del CAN in una rete più capace.
architettura esistente → misura del traffico reale → requisiti futuri → topologia → prototipo → verifica firmware e fisica → scelta industrializzabile
Questo approccio evita due errori opposti. Il primo è adottare una tecnologia nuova solo perché disponibile, senza un beneficio misurabile. Il secondo è mantenere una rete satura perché “ha sempre funzionato”, scoprendo il limite quando il prodotto deve integrare una nuova HMI, un gateway, una funzione di assistenza o un modulo con più sensori.
Un esempio: macchina modulare con HMI, azionamenti e diagnostica
Immaginiamo una macchina modulare con più assi, un pannello operatore, moduli di acquisizione e un gateway per l’assistenza. Il CAN FD viene usato per inviare comandi e stati. Con il tempo, l’azienda aggiunge parametri di lavorazione, diagnostica degli azionamenti, ricette, dati di qualità e richieste di manutenzione predittiva.
Ogni nuova funzione sembra inizialmente piccola. Il risultato, però, è che le informazioni vengono spezzate in molti messaggi, la diagnostica viene limitata durante le fasi più cariche e il firmware deve coordinare canali di comunicazione sempre più numerosi. Il problema non è che CAN FD sia “sbagliato”: semplicemente l’architettura iniziale non era stata dimensionata per l’evoluzione effettiva del prodotto.
Un’analisi CAN XL può verificare se i flussi di diagnostica e configurazione possano essere trasportati in modo più efficiente, preservando i messaggi di controllo prioritari. Può anche chiarire se l’uso combinato di CAN XL ed Ethernet permetta di separare correttamente controllo locale, HMI e collegamento al gateway.
Il risultato utile non è la promessa di una rete “più moderna”. È un’architettura che indica quali nodi aggiornare, quali mantenere, quali dati spostare, quali vincoli fisici rispettare e come verificare la stabilità del sistema prima della produzione.
Domande frequenti su CAN XL
CAN XL è già utilizzabile nei prodotti commerciali?
Il protocollo e il livello fisico sono standardizzati nella famiglia ISO 11898:2024. L’annuncio del transceiver TCAN6062 da parte di Texas Instruments rende disponibile un componente commerciale per iniziare valutazioni e nuovi progetti. La disponibilità del sistema completo dipende comunque da controller, toolchain, firmware e requisiti del prodotto.
CAN XL sostituisce CAN FD?
No. CAN FD rimane una soluzione molto valida per numerose reti embedded. CAN XL va valutato quando la maggiore dimensione dei frame, il throughput e l’evoluzione dell’architettura portano un beneficio misurabile rispetto alla complessità della migrazione.
Qualsiasi microcontrollore può diventare CAN XL con un nuovo transceiver?
No. Il transceiver gestisce il livello fisico; il controller e il firmware devono supportare CAN XL. Per questo la fattibilità deve essere verificata sulla specifica MCU, sul sistema operativo real-time eventualmente utilizzato e sulla disponibilità dello stack necessario.
CAN XL è una tecnologia solo automotive?
No. L’origine del CAN è fortemente legata al mondo automotive, ma la nuova disponibilità hardware viene proposta anche per robot industriali, HMI e sistemi di controllo. La valutazione deve partire dal caso d’uso, non dal settore nel quale il protocollo è nato.
Può sostituire Ethernet in una macchina?
Non in modo generalizzato. Ethernet può restare indispensabile per collegamenti ad alta capacità, PC industriali, gateway, telecamere e reti IP. CAN XL è utile quando si vogliono conservare le logiche di priorità del CAN e aumentare la capacità di una rete di controllo distribuita.
Come Silicon Logix può supportare la valutazione
Silicon Logix può affiancare aziende e team tecnici nella valutazione dell’architettura di comunicazione di macchine, dispositivi embedded e sistemi modulari. L’attività può partire da una rete CAN o CAN FD esistente, da un nuovo prodotto in definizione oppure da un prototipo che deve evolvere verso l’industrializzazione.
Il lavoro non consiste nel proporre CAN XL a prescindere. Parte dall’analisi dei flussi dati, delle priorità, della topologia, delle MCU disponibili, del firmware e delle esigenze future di HMI, diagnostica, gateway o assistenza remota. Da questa base si può definire un proof of concept misurabile e un percorso tecnico realistico per il prodotto.
Quando serve, la valutazione può proseguire con lo sviluppo di firmware embedded, integrazione di protocolli, interfacce HMI, gateway Linux o strumenti di diagnostica. L’obiettivo è mantenere coerenti dispositivo, comunicazione e software di supporto, senza introdurre complessità non necessaria.
Conclusione
Il primo transceiver CAN XL disponibile commercialmente segna un passaggio rilevante: una tecnologia già definita dagli standard inizia a diventare una scelta concreta per chi deve progettare le prossime generazioni di prodotti industriali.
CAN XL non cancellerà CAN classico, CAN FD o Ethernet. Ogni tecnologia continuerà ad avere il proprio spazio. Il suo valore sta nell’occupare una zona oggi sempre più importante: reti che devono trasportare più dati, ma non possono rinunciare a priorità, robustezza e continuità con l’ecosistema CAN.
Per un’azienda, la scelta migliore non è adottare il protocollo più recente. È progettare una rete che abbia margine per l’evoluzione reale del prodotto, che possa essere verificata prima della produzione e che resti manutenibile quando macchina, firmware e requisiti del cliente cambieranno.
La domanda non è soltanto:
“Quanti dati riusciamo a trasmettere oggi?”
Diventa:
“La nostra architettura saprà gestire la prossima HMI, il prossimo modulo e le prossime funzioni senza dover essere riprogettata da zero?”
Riferimenti ufficiali
- Texas Instruments, TI advances next-generation industrial systems with the first commercially available CAN XL transceiver, 12 agosto 2026.
- Texas Instruments, TCAN6062 CAN XL Transceiver with Standby Mode – datasheet, requisiti fisici ISO 11898-2:2024 e caratteristiche del componente.
- CAN in Automation, CAN XL, descrizione ufficiale della terza generazione CAN, payload e throughput.
- CAN in Automation, CAN XL (extended data-field length), struttura del frame XL e relazione con CAN classico e CAN FD.
- CAN in Automation, ISO 11898-1:2024 released, standardizzazione delle generazioni CAN classico, CAN FD e CAN XL.
- CAN in Automation, Physical layer options, caratteristiche della parte fisica CAN SIC XL e vincoli di progettazione della rete.
Stai progettando una macchina, un’HMI o un dispositivo con più nodi e più dati da gestire?
Silicon Logix può effettuare una valutazione tecnica dell’architettura di comunicazione, analizzando traffico, priorità, nodi, firmware, topologia e margine di evoluzione del prodotto.
L’attività può partire da una rete CAN o CAN FD esistente oppure da un nuovo progetto, con un proof of concept mirato prima della progettazione definitiva dell’hardware.
Richiedi una valutazione tecnica del tuo progetto
