Storia della Tecnologia CAN

Di seguito i documenti pubblicati da Bosch che descrivono il protocollo CAN (CAN Specification 1.0), il modello C Reference CAN e il documento SAE
Nel febbraio del 1986, Robert Bosch GmbH ha presentato il sistema di bus seriale Controller Area Network (CAN) al congresso della Society of Automotive Engineers (SAE). Fu l'ora della nascita di uno dei protocolli di rete di maggior successo di sempre. Oggi, quasi ogni nuova autovettura prodotta in Europa è dotata di almeno una rete CAN. Utilizzato anche in altri tipi di veicoli, dai treni alle navi, così come nei controlli industriali, CAN è uno dei protocolli di bus più dominanti - forse anche il principale sistema di bus seriale a livello mondiale.

Dall'idea al primo chip

All'inizio degli anni '80, gli ingegneri della Bosch stavano valutando i sistemi di bus seriali esistenti riguardo al loro possibile utilizzo nelle autovetture. Poiché nessuno dei protocolli di rete disponibili era in grado di soddisfare i requisiti degli ingegneri automobilistici, Uwe Kiencke iniziò lo sviluppo di un nuovo sistema di bus seriale nel 1983.

Il nuovo protocollo bus doveva principalmente aggiungere nuove funzionalità - la riduzione dei cablaggi era solo un sottoprodotto, ma non la forza trainante dello sviluppo del CAN. Gli ingegneri della Mercedes-Benz furono ben presto coinvolti nella fase di specificazione del nuovo sistema di bus seriale, così come Intel per fornire i semiconduttori. Il professor Dr. Wolfhard Lawrenz dell'Università di Scienze Applicate di Braunschweig-Wolfenbüttel (oggi: Università di Scienze Applicate di Ostfalia), Germania, che era stato assunto come consulente, diede al nuovo protocollo di rete il nome 'Controller Area Network'. Anche il professor Dr. Horst Wettstein dell'Università di Karlsruhe fornì assistenza accademica.

Nel febbraio del 1986 nacque CAN: al congresso SAE di Detroit, il nuovo sistema di bus fu presentato come 'Automotive Serial Controller Area Network'. Uwe Kiencke, Siegfried Dais e Martin Litschel introdussero il protocollo di rete multi-drop. Era basato su un meccanismo di arbitraggio non distruttivo, che concedeva l'accesso al bus con la massima priorità senza alcun ritardo. Non c'era un'istanza centrale che arbitrava l'accesso alla rete. Inoltre, i padri del CAN - gli individui menzionati sopra più i dipendenti Bosch Wolfgang Borst, Wolfgang Botzenhard, Otto Karl, Helmut Schelling e Jan Unruh - avevano implementato diversi meccanismi di rilevamento degli errori. La gestione degli errori includeva anche la disconnessione automatica dei nodi del bus difettosi al fine di mantenere la comunicazione tra i nodi rimanenti. I frame trasmessi non erano identificati dagli indirizzi dei nodi del trasmettitore di frame o dei ricevitori di frame (come in quasi tutti gli altri sistemi bus), ma piuttosto dal loro contenuto. L'identificatore che rappresenta il carico utile del frame aveva anche la funzione di specificare la priorità del frame all'interno del segmento di rete.

Seguirono molte presentazioni e pubblicazioni che descrivevano questo innovativo protocollo di comunicazione, finché a metà del 1987 - due mesi prima del previsto - Intel consegnò il primo chip controller CAN, l'82526. Era la primissima implementazione hardware del protocollo CAN. In soli quattro anni, un'idea era diventata realtà. Poco dopo, Philips Semiconductors introdusse l'82C200. Questi due primi antenati dei controller CAN erano abbastanza diversi per quanto riguarda il filtraggio dell'accettazione e la gestione dei frame. Da un lato, il concetto FullCAN favorito da Intel richiedeva meno carico di CPU (unità di elaborazione centrale) dal microcontrollore collegato rispetto all'implementazione BasicCAN scelta da Philips. D'altra parte, il dispositivo FullCAN era limitato per quanto riguarda il numero di frame che potevano essere ricevuti. Il controller BasicCAN richiedeva anche meno silicio. Nei controller CAN di oggi, viene implementato un misto di entrambi i concetti di filtraggio dell'accettazione e di gestione dei frame. Questo ha reso i termini fuorvianti BasicCAN e FullCAN obsoleti.

Standardizzazione e conformità

La specifica CAN di Bosch (versione 2.0) è stata presentata per la standardizzazione internazionale nei primi anni '90. Dopo diverse controversie politiche, soprattutto per quanto riguarda la "Vehicle Area Network" (VAN) sviluppata da alcuni grandi produttori di automobili francesi, lo standard ISO 11898 è stato pubblicato nel novembre 1993. Oltre al protocollo CAN, ha anche standardizzato uno strato fisico per bit-rate fino a 1 Mbit/s. In parallelo, un modo a bassa potenza e tollerante ai guasti di trasmissione dati via CAN è stato standardizzato in ISO 11519-2. Questo non è mai stato implementato a causa di debolezze nello standard. Nel 1995, lo standard ISO 11898 è stato esteso da un addendum che descriveva il formato di frame esteso usando un identificatore CAN a 29 bit.

Sfortunatamente, tutte le specifiche e le standardizzazioni CAN pubblicate contenevano errori o erano incomplete. Per evitare implementazioni CAN incompatibili, Bosch ha fatto in modo che tutti i chip CAN siano conformi al modello di riferimento Bosch CAN. Inoltre, l'Università di Scienze Applicate di Braunschweig/Wolfenbüttel, Germania, ha condotto test di conformità CAN per diversi anni, guidati dal Prof. Lawrenz. I modelli di test utilizzati sono basati sulla serie di standard ISO 16845 conformance test plan. Oggi, diverse case di prova offrono servizi di test di conformità CAN.

Le specifiche CAN riviste sono state standardizzate. ISO 11898-1 descrive il 'CAN data link layer', ISO 11898-2 standardizza il 'Non fault-tolerant' CAN physical layer', e ISO 11898-3 specifica il 'Fault-tolerant CAN physical layer'. La serie ISO 11992 (interfaccia camion e rimorchi) e la serie ISO 11783 (macchine agricole e forestali) specificano profili applicativi basati sull'approccio di rete SAE J1939 non sono compatibili, perché le specifiche del livello fisico sono diverse.

Il tempo dei pionieri CAN

Anche se il protocollo CAN è stato originariamente sviluppato per essere utilizzato nelle autovetture, le prime applicazioni provenivano da diversi segmenti di mercato. Specialmente nel nord Europa, il protocollo CAN è stato popolare fin dal suo esordio. In Finlandia, il produttore di ascensori Kone usava il bus CAN. L'ufficio di ingegneria svedese Kvaser suggerì CAN come protocollo di comunicazione all'interno delle macchine ad alcuni produttori di macchine tessili (Lindauer Dornier e Sulzer) e ai loro fornitori. A questo proposito, sotto la guida di Lars-Berno Fredriksson, queste aziende fondarono il 'CAN Textile User's Group'. Entro il 1989, avevano sviluppato principi di comunicazione che hanno contribuito a formare l'ambiente di sviluppo 'CAN Kingdom' nei primi anni '90. Anche se il CAN Kingdom non è un alto livello di applicazione rispetto al modello di riferimento OSI, può essere considerato come l'antenato dei protocolli di livello superiore basati sul CAN.

Nei Paesi Bassi, Philips Medical Systems decise di usare il CAN per la rete interna delle loro macchine a raggi X. La 'Philips Message Specification' (PMS), sviluppata principalmente da Tom Suters, rappresenta il primo livello di applicazione per le reti CAN. Il professor Konrad Etschberger dell'Università di Scienze Applicate di Weingarten, in Germania, aveva idee quasi identiche. Nel Centro di trasferimento Steinbeis per l'automazione dei processi (STZP), di cui era responsabile, ha sviluppato un protocollo simile.

Nonostante il fatto che i primi protocolli standardizzati di livello superiore cominciassero ad emergere, la maggior parte dei pionieri CAN usavano un approccio monolitico. Le funzioni di comunicazione, la gestione della rete e il codice dell'applicazione erano un unico blocco di software. Anche se alcuni utenti avrebbero preferito un approccio più modulare, avrebbero comunque avuto lo svantaggio di una soluzione proprietaria. Gli sforzi necessari per migliorare e mantenere un protocollo CAN di livello superiore erano stati sottovalutati - il che è ancora parzialmente vero oggi.

L’inizio degli anni  '90 segna il momento giusto per fondare un gruppo di utenti per promuovere il protocollo CAN e per favorire il suo utilizzo in molte applicazioni. Nel gennaio del 1992, Holger Zeltwanger, a quel tempo editore della rivista VMEbus (editore: Franzis), ha riunito utenti e produttori per stabilire una piattaforma neutrale per il miglioramento tecnico del protocollo CAN. Due mesi dopo, il gruppo internazionale di utenti e produttori "CAN in Automation" (CiA) fu ufficialmente fondato. Fu l’inizio della pubblicazione della Newsletter CAN.

La prima pubblicazione tecnica, rilasciata dopo poche settimane, riguardava lo strato fisico: Il CiA raccomandava di usare solo transceiver CAN conformi alla ISO 11898. Oggi, i ricetrasmettitori EIA-485 specifici del produttore, che erano abbastanza usati nelle reti CAN a quel tempo e non erano sempre compatibili, dovrebbero essere completamente scomparsi.

Uno dei primi compiti del CiA era la specifica di un livello di applicazione CAN. Usando il materiale esistente di Philips Medical Systems e STZP, insieme all'aiuto di altri membri del CiA, fu sviluppato il 'CAN Application Layer' (CAL), chiamato anche 'Green Book'. Mentre si sviluppavano le specifiche utilizzando il CAN, uno dei compiti principali del CiA era quello di organizzare lo scambio di informazioni tra gli esperti CAN e quelli che volevano diventare più informati. Pertanto, dal 1994, si tiene la conferenza internazionale CAN (iCC).

Un altro approccio accademico è stato perseguito nella LAV: l'associazione tedesca dei veicoli agricoli. Dalla fine degli anni '80, era stato sviluppato un sistema di bus basato su CAN per veicoli agricoli (LBS). Ma prima che il lavoro potesse essere completato con successo, il comitato internazionale decise a favore di una soluzione statunitense, J1939 (ISO 11783). Questo profilo di applicazione, che è anche basato su CAN, è stato definito dai comitati della SAE Truck and Bus Association. J1939 è un approccio non modulare che è molto facile da usare, ma è anche abbastanza inflessibile.

Una standardizzazione del CAN è stata sviluppata anche per i camion. Il collegamento in rete tra camion e rimorchio è standardizzato come ISO 11992. Questo protocollo è basato su J1939 e viene usato in Europa dal 2006. La tendenza per i veicoli automobilistici va verso OSEK-COM e OSEK-NM, un protocollo di comunicazione e una gestione di rete. Entrambi sono stati presentati per la standardizzazione internazionale. I costruttori di automobili, tuttavia, usano soluzioni software proprietarie.

Dalla teoria alla pratica

Naturalmente, i fornitori di semiconduttori che hanno implementato il protocollo CAN nei loro microcontrollori sono principalmente concentrati sull'industria automobilistica. Dalla metà degli anni '90, Infineon Technologies (ex Siemens Semiconductors) e Motorola (esternalizzata come Freescale e poi acquisita da NXP) hanno spedito grandi quantità di controller CAN ai produttori europei di automobili e ai loro fornitori. Come ondata successiva, i fornitori di semiconduttori dell'Estremo Oriente hanno anche offerto controller CAN dalla fine degli anni '90. NEC è uscita con il suo leggendario chip CAN 72005 nel 1994, ma era troppo presto - il componente non è stato un successo commerciale.

Dal 1991, Mercedes-Benz ha usato il CAN nelle sue autovetture di classe superiore. Come primo passo, le unità di controllo elettronico che si occupano della gestione del motore sono state collegate via CAN. Nel 1995, la BMW ha usato una topologia ad albero/stella della rete CAN con cinque ECU (unità di controllo elettronico) nelle sue auto della serie 7. Sono state implementate due reti CAN fisicamente separate, spesso collegate tramite gateway. Altre case automobilistiche hanno seguito l'esempio dei loro colleghi di Stoccarda e hanno implementato due reti CAN nelle loro autovetture. Oggi, tutti implementano più reti CAN nei loro veicoli.

All'inizio degli anni '90, gli ingegneri dell'azienda americana di ingegneria meccanica Cincinnati Milacron iniziarono una joint venture con Allen-Bradley e Honeywell Microswitch per un progetto di controllo e comunicazione basato sul CAN. Tuttavia, dopo poco tempo, membri importanti del progetto cambiarono lavoro e la joint venture andò in pezzi. Ma Allen-Bradley e Honeywell continuarono il lavoro separatamente. Questo portò ai due protocolli di livello superiore "Devicenet" e "Smart Distributed System" (SDS), che sono abbastanza simili, almeno nei livelli di comunicazione inferiori. All'inizio del 1994, Allen-Bradley girò la specifica Devicenet alla 'Open Devicenet Vendor Association' (ODVA), che aumentò la popolarità di Devicenet. Honeywell non è riuscita a percorrere una strada simile con SDS, il che fa sembrare SDS più una soluzione interna di Honeywell Microswitch. Devicenet è stato sviluppato specialmente per l'automazione di fabbrica e quindi si presenta come un avversario diretto a protocolli come Profibus-DP e Interbus. Fornendo funzionalità plug-and-play off-the-shelf, Devicenet è diventato il sistema bus leader in questo particolare segmento di mercato negli Stati Uniti.

In Europa, diverse aziende hanno cercato di usare CAL. Anche se l'approccio CAL era accademicamente corretto ed era possibile utilizzarlo in applicazioni industriali, ogni utente aveva bisogno di progettare un nuovo profilo perché CAL era un vero livello applicativo. CAL può essere visto come un necessario passo accademico verso una soluzione CAN indipendente dall'applicazione, ma non ha mai guadagnato un ampio consenso.

Dal 1993, nell'ambito del progetto Esprit Aspic, un consorzio europeo guidato da Bosch, stava sviluppando un prototipo di quello che sarebbe diventato CANopen. Si trattava di un profilo basato su CAL per il collegamento in rete interno delle celle di produzione. Dal lato accademico, il professor Gerhard Gruhler dell'Università di Scienze Applicate di Reutlingen (Germania) e il dottor Mohammed Farsi dell'Università di Newcastle (Regno Unito) hanno partecipato a quella che è stata una delle attività Esprit di maggior successo di sempre. Dopo il completamento del progetto, la specifica CANopen è stata consegnata al CiA per un ulteriore sviluppo e manutenzione. Nel 1995, il profilo di comunicazione CANopen, completamente rivisto, fu rilasciato e in soli cinque anni divenne la più importante rete embedded standardizzata in Europa.

Le prime reti CANopen furono usate per la comunicazione interna delle macchine, specialmente per gli azionamenti. CANopen offre una flessibilità e una configurabilità molto elevate. Il protocollo di livello superiore, che è stato usato in diverse aree di applicazione (automazione industriale, elettronica marittima, veicoli militari, ecc.) è stato nel frattempo standardizzato a livello internazionale come EN 50325-4 (2003). CANopen viene utilizzato soprattutto in Europa. Macchine per lo stampaggio a iniezione in Italia, seghe e macchine per il legno in Germania, macchine per sigarette in Gran Bretagna, gru in Francia, macchine per la movimentazione in Austria e macchine per la produzione di orologi in Svizzera sono solo alcuni esempi nell'ambito dell'automazione industriale e della costruzione di macchine. Negli Stati Uniti, CANopen è stato raccomandato per i carrelli elevatori e viene utilizzato nelle macchine di smistamento lettere.

CANopen non definisce solo il livello di applicazione e un profilo di comunicazione, ma anche una struttura per sistemi programmabili e diversi profili di dispositivi, interfacce e applicazioni. Questa è una ragione importante per cui interi segmenti dell'industria (per esempio macchine da stampa, applicazioni marittime, sistemi medici) hanno deciso di usare CANopen alla fine degli anni '90.

Con Devicenet e CANopen, sono disponibili due strati applicativi standardizzati (IEC 62026-3 e EN 50325-4/5) che si rivolgono a diversi mercati dell'automazione industriale. Devicenet è ottimizzato per l'automazione di fabbrica e CANopen è particolarmente adatto per le reti embedded in tutti i tipi di controllo delle macchine. Questo ha reso obsoleti gli application layer proprietari; la necessità di definire application layer specifici per l'applicazione è diventata storia.

Comunicazione temporizzata

All'inizio del 2000, una task force ISO che coinvolgeva diverse aziende ha definito un protocollo per una trasmissione temporizzata dei frame CAN. Bernd Mueller, Thomas Fuehrer e altri dipendenti Bosch, insieme ad esperti dell'industria dei semiconduttori e della ricerca accademica, hanno definito il protocollo 'Time-triggered communication on CAN' (TTCAN).

Questa estensione CAN ha permesso la trasmissione “time-equidistant” dei frame e l'implementazione del controllo ad anello chiuso via CAN, ma anche l'uso di CAN in applicazioni x-by-wire. Poiché il protocollo CAN non è stato alterato, è possibile trasmettere frame time-triggered e event-triggered attraverso lo stesso sistema di bus fisico. Tuttavia, l'industria automobilistica non ha adottato il TTCAN. Inoltre, gli utenti industriali hanno raramente fatto uso dell'estensione del protocollo time-triggered. Hanno invece utilizzato funzioni di trasmissione sincrona, specificate in CANopen, per così dire un metodo “soft time-triggering”.

Approvazione da parte delle autorità

Alla fine degli anni '90, sono stati inventati diversi protocolli di sicurezza proprietari basati su CAN. Sopravvissuto ha il Safetybus p da Pilz, Germania. Nell'anno 1999, CiA ha iniziato a sviluppare il protocollo CANopen-Safety, che è stato approvato dal TÜV tedesco. Dopo pesanti deleghe politiche negli organismi di standardizzazione, questa estensione CANopen (CiA 304) è stata standardizzata a livello internazionale in EN 50325-5 (2009).

Devicenet utilizza l'estensione del protocollo CIP Safety. Germanischer Lloyd, una delle principali società di classificazione a livello mondiale, ha approvato il quadro CANopen per le applicazioni marittime (CiA 307). Tra le altre cose, questo framework specifica la commutazione automatica da una rete CANopen predefinita a un sistema di bus ridondante. Queste funzioni sono oggi generalizzate e specificate nella serie CiA 302 di funzioni aggiuntive del livello di applicazione CANopen.

Sviluppo di CAN FD

All'inizio del 2011, General Motors e Bosch hanno iniziato lo sviluppo di alcuni miglioramenti del protocollo CAN per quanto riguarda il throughput più elevato. L'industria automobilistica ha sofferto in particolare per il download di pacchetti software sempre più numerosi nelle unità di controllo elettronico (ECU). Questo compito che richiede tempo doveva essere abbreviato da un sistema di comunicazione più performante. L'idea di aumentare la velocità di trasmissione di CAN introducendo un secondo bit-rate non era nuova. Diversi accademici avevano pubblicato approcci dall'inizio del 2000. Ma nessuno di essi era abbastanza maturo da convincere le case automobilistiche. In collaborazione con altri esperti CAN, Bosch ha pre-sviluppato la specifica CAN FD, presentata ufficialmente nel 2012 alla 13a conferenza internazionale CAN nel castello di Hambach, in Germania.

Durante il processo di standardizzazione all'interno di ISO, sono state trovate diverse debolezze accademiche nei meccanismi di rilevamento degli errori proposti. Questo ha richiesto una revisione del protocollo CAN FD e l'introduzione di salvaguardie aggiuntive (ad esempio il contatore di bit). Questo è il motivo per cui esiste un protocollo non-ISO CAN FD, che è incompatibile con il protocollo ISO CAN FD standardizzato in ISO 11898-1.

Il Dr. Mark Schreiner della Daimler ha fornito un sacco di suggerimenti e di pieghe per progettare reti CAN FD. Molte delle sue idee sono incorporate nella serie CiA 601 di raccomandazioni e specifiche di progettazione di nodi e sistemi CAN FD.

Il futuro di CAN è luminoso

La vita della tecnologia CAN è stata prolungata con l'introduzione del protocollo CAN FD. L'industria automobilistica ha già iniziato ad adottare il protocollo CAN FD per la prossima generazione di reti in-vehicle. Ci si può aspettare che tutte le applicazioni future faranno uso del protocollo CAN FD. Non importa se richiedono una maggiore larghezza di banda o meno. È ancora possibile utilizzare CAN FD con un'unica impostazione di bit-timing. La lunghezza del payload è comunque configurabile da 0 byte a 64 byte.

Per coloro che hanno bisogno di una maggiore larghezza di banda e richiedono topologie ibride, il CiA ha sviluppato la cosiddetta specifica SIC (signal improvement circuitry) transceiver (CiA 601-4). L'idea originale è venuta da Denso, un fornitore giapponese Tier-1.

CiA ha anche sviluppato il protocollo CANopen FD, che è basato sugli strati inferiori CAN FD. In particolare per le applicazioni di controllo del movimento industriale, velocità di trasmissione più elevate e carichi utili più lunghi (fino a 64 byte) sono molto apprezzati. CiA è anche coinvolta nello sviluppo di un livello applicativo basato su CAN FD per i veicoli commerciali utilizzando i gruppi di parametri esistenti come specificato nella serie SAE J1939.

La terza generazione CAN

Alla fine del 2018, CiA ha iniziato lo sviluppo di CAN XL, la terza generazione di protocolli di collegamento dati basati sul CAN. È stato avviato su richiesta di Volkswagen. Carsten Schanze e Alexander Mueller hanno fornito molte delle prime idee. Il carico utile massimo (campo dati) del CAN XL è di 2048 byte. Un'altra nuova caratteristica è la separazione della funzione di priorità (campo di priorità a 11 bit) e la funzione di indirizzo/contenuto (campo di accettazione a 32 bit). Il Dr. Arthur Mutter (Bosch) e Ralf Hildebrand (Fraunhofer) hanno contribuito insieme ad altri esperti con molte nuove idee.

Nel frattempo, diversi gruppi tecnici CiA hanno sviluppato una serie di documenti CiA relativi al CAN XL. Questo include anche un nuovo approccio di collegamento dei media fisici utilizzando la codifica PWM invece della tradizionale codifica NRZ. Gli esperti della NXP, in particolare Matthias Muth, hanno presentato la proposta originale per la codifica PWM.

Oltre alle specifiche del livello inferiore del CAN XL, compresi i piani di test di conformità, ci sono raccomandazioni per la progettazione del dispositivo e della rete CAN XL, specifiche del protocollo di livello superiore CAN XL e specifiche per la gestione del livello. Inoltre, i membri del CiA specificano un protocollo di sicurezza del livello di collegamento dati CAN XL.

Comunicazione temporizzata

All'inizio del 2000, una task force ISO che coinvolgeva diverse aziende ha definito un protocollo per una trasmissione temporizzata dei frame CAN. Bernd Mueller, Thomas Fuehrer e altri dipendenti Bosch, insieme ad esperti dell'industria dei semiconduttori e della ricerca accademica, hanno definito il protocollo 'Time-triggered communication on CAN' (TTCAN).

Questa estensione CAN ha permesso la trasmissione time-equidistant dei frame e l'implementazione del controllo ad anello chiuso via CAN, ma anche l'uso di CAN in applicazioni x-by-wire. Poiché il protocollo CAN non è stato alterato, è possibile trasmettere frame time-triggered e event-triggered attraverso lo stesso sistema di bus fisico. Tuttavia, l'industria automobilistica non ha adottato il TTCAN. Inoltre, gli utenti industriali hanno raramente fatto uso dell'estensione del protocollo time-triggered. Hanno invece utilizzato funzioni di trasmissione sincrona, specificate in CANopen, per così dire un metodo soft time-triggering.

Approvazione da parte delle autorità

Alla fine degli anni '90, sono stati inventati diversi protocolli di sicurezza proprietari basati su CAN. Sopravvissuto ha il Safetybus p da Pilz, Germania. Nell'anno 1999, CiA ha iniziato a sviluppare il protocollo CANopen-Safety, che è stato approvato dal TÜV tedesco. Dopo pesanti deleghe politiche negli organismi di standardizzazione, questa estensione CANopen (CiA 304) è stata standardizzata a livello internazionale in EN 50325-5 (2009).

Devicenet utilizza l'estensione del protocollo CIP Safety. Germanischer Lloyd, una delle principali società di classificazione a livello mondiale, ha approvato il quadro CANopen per le applicazioni marittime (CiA 307). Tra le altre cose, questo framework specifica la commutazione automatica da una rete CANopen predefinita a un sistema di bus ridondante. Queste funzioni sono oggi generalizzate e specificate nella serie CiA 302 di funzioni aggiuntive del livello di applicazione CANopen.

Sviluppo di CAN FD

All'inizio del 2011, General Motors e Bosch hanno iniziato lo sviluppo di alcuni miglioramenti del protocollo CAN per quanto riguarda il throughput più elevato. L'industria automobilistica ha sofferto in particolare per il download di pacchetti software sempre più numerosi nelle unità di controllo elettronico (ECU). Questo compito che richiede tempo doveva essere abbreviato da un sistema di comunicazione più performante. L'idea di aumentare la velocità di trasmissione di CAN introducendo un secondo bit-rate non era nuova. Diversi accademici avevano pubblicato approcci dall'inizio del 2000. Ma nessuno di essi era abbastanza maturo da convincere le case automobilistiche. In collaborazione con altri esperti CAN, Bosch ha pre-sviluppato la specifica CAN FD, presentata ufficialmente nel 2012 alla 13a conferenza internazionale CAN nel castello di Hambach, in Germania.

Durante il processo di standardizzazione all'interno di ISO, sono state trovate diverse debolezze accademiche nei meccanismi di rilevamento degli errori proposti. Questo ha richiesto una revisione del protocollo CAN FD e l'introduzione di salvaguardie aggiuntive (ad esempio il contatore di bit di roba). Questo è il motivo per cui esiste un protocollo non-ISO CAN FD, che è incompatibile con il protocollo ISO CAN FD standardizzato in ISO 11898-1.

Il Dr. Mark Schreiner della Daimler ha fornito un sacco di suggerimenti e di pieghe per progettare reti CAN FD. Molte delle sue idee sono incorporate nella serie CiA 601 di raccomandazioni e specifiche di progettazione di nodi e sistemi CAN FD.

Il futuro di CAN è luminoso

La vita della tecnologia CAN è stata prolungata con l'introduzione del protocollo CAN FD. L'industria automobilistica ha già iniziato ad adottare il protocollo CAN FD per la prossima generazione di reti in-vehicle. Ci si può aspettare che tutte le applicazioni future faranno uso del protocollo CAN FD. Non importa se richiedono una maggiore larghezza di banda o meno. È ancora possibile utilizzare CAN FD con un'unica impostazione di bit-timing. La lunghezza del payload è comunque configurabile da 0 byte a 64 byte.

Per coloro che hanno bisogno di una maggiore larghezza di banda e richiedono topologie ibride, il CiA ha sviluppato la cosiddetta specifica SIC (signal improvement circuitry) transceiver (CiA 601-4). L'idea originale è venuta da Denso, un fornitore giapponese Tier-1.

CiA ha anche sviluppato il protocollo CANopen FD, che è basato sugli strati inferiori CAN FD. In particolare per le applicazioni di controllo del movimento industriale, velocità di trasmissione più elevate e carichi utili più lunghi (fino a 64 byte) sono molto apprezzati. CiA è anche coinvolta nello sviluppo di un livello applicativo basato su CAN FD per i veicoli commerciali utilizzando i gruppi di parametri esistenti come specificato nella serie SAE J1939.

La terza generazione CAN

Alla fine del 2018, CiA ha iniziato lo sviluppo di CAN XL, la terza generazione di protocolli di livello di collegamento dati basati su CAN. È stato avviato su richiesta di Volkswagen. Carsten Schanze e Alexander Mueller hanno fornito molte delle prime idee. Il carico utile massimo (campo dati) del CAN XL è di 2048 byte. Un'altra nuova caratteristica è la separazione della funzione di priorità (campo di priorità a 11 bit) e la funzione di indirizzo/contenuto (campo di accettazione a 32 bit). Il Dr. Arthur Mutter (Bosch) e Ralf Hildebrand (Fraunhofer) hanno contribuito insieme ad altri esperti con molte nuove idee.

Nel frattempo, diversi gruppi tecnici CiA sviluppano serie di documenti CiA relativi al CAN XL. Questo include anche un nuovo approccio di collegamento dei media fisici utilizzando la codifica PWM invece della tradizionale codifica NRZ. Gli esperti della NXP, in particolare Matthias Muth, hanno presentato la proposta originale per la codifica PWM.

Oltre alle specifiche del livello inferiore del CAN XL, compresi i piani di test di conformità, ci sono raccomandazioni per la progettazione del dispositivo e della rete CAN XL, specifiche del protocollo di livello superiore CAN XL e specifiche per la gestione del livello. Inoltre, i membri del CiA specificano un protocollo di sicurezza del livello di collegamento dati CAN XL.