Automotive Bus

0
605

exploded transparent carLe comunicazioni industriali si sono inizialmente sviluppate tramite bus di campo con prestazioni diversificate, per poi orientarsi sulle soluzioni Industrial Ethernet, ma restano ambiti dove i bus di campo, pur con caratteristiche particolari, restano fondamentali.

Tra gli elementi qualificanti di una rete locale, o LAN (Local Area Network), oltre a mezzo trasmissivo, a tecnica di trasmissione e metodo di accesso alle risorse della rete, vi è la topologia, con ciò intendendo il modo con cui le varie unità o “partner” o nodi della rete sono tra loro collegati. Le topologie di base sono a stella (star), ad anello (ring) e ad anello aperto (bus). Quest’ultima topologia, che prevede una linea di collegamento, o bus comune, cui sono “appesi” i vari nodi di rete, è anche indicata con il termine multidrop. Gli scambi di dati e informazioni possono avvenire  tra due nodi senza che, in prima approssimazione, sia necessaria la prezenza di un controller centrale, più propriamente di un’unità master dedicata alla supervisione complessiva delle operazioni, ma in questo caso devono essere previste nel protocollo di rete delle funzionalità atte a gestire i conflitti a livello di accessi multipli, come nel più semplice classico caso della rete Ethernet che prevede la modalità CSMA/CD, Carrier Sense Multiple Access/Collision Detection. Se è presente un master, a esso è demandata la gestione delle comunicazioni da e verso le diverse unità slave, in termini dim abilitazione e indirizzamento. Questo come sintetica introduzione al concetto di bus, più propriamente da inquadrarsi nella tematica bus di campo (fieldbus), con ciò riferendosi a implementazioni diverse di sistemi di comunicazione industriale più o meno specializzate, dedicate al collegamento di unità di campo quali sensori e attuatori, ma eventualmente anche di sistemi più complessi. Ma questa è tutta un’altra storia in quanto con questo articolo vogliamo proporre, per il bus, un’ambientazione molto specifica, quella dell’Automotive, partendo dalla considerazione che la quantità e sofisticazione di componenti elettronici presenti in un’autovettura continua a crescere, sotto forma di sensori, attuatori e unità di controllo, il tutto dedicato ad aumentare sia la sicurezza che il comfort. La varietà di funzioni che si vogliono rendere fruibili, o meglio che si possono rendere fruibili grazie a soluzioni elettroniche specificatamente studiate le autovetture, ha imposto la progettazione di nuovi sistemi bus specializzati al contesto, e si arriva così agli Automotive Bus, ovviamente derivati dalle logiche su cui i basano i fieldbus dell’automazione e del controllo di processo, ma tali da ottimizzare la comunicazione tra le parti elettroniche di un’auto. Tra gli attuali riferimenti consolidati, sono senz’altro da considerare MOST, FlexRay e LIN, senza però dimenticare che anche il ben noto bus di campo CAN, Controller Area Network, che qui non riprendiamo, era nato inizialmente proprio per utilizzo in ambito ambito automobilistico.

 

MOST, Media Oriented Systems Transport

Il bus MOST, ora alla versione MOST 150, era stato inizialmente sviluppato dalla tedesca Oasis SiliconSystems AG in cooperazione con BMW e DaimlerChrysler, per gestire applicazioni multimediali in ambito Automotive, quali audio, video, navigazione e sistemi di telecomunicazione. Va premesso che le cosiddette “in-car applications” sono in netta evoluzione, e l’obiettivo di un infotainment si sta allargando per tenere il passo con lo sviluppo dell’industria consumer e con le richieste degli utenti, oramai abituati a esperienze digitali che desiderano avere sempre e ovunque a disposizione, anche in movimento. Occorre quindi poter connettere a un’autovettura sistemi esterni e servizi quali internet e WiFi, oltre alle più usuali fruizioni di radio e CD. La risposta arriva da questo “Automotive Information Backbone” che definisce tutti i sette layer del modello di riferimento OSI, Open System Interconnection,  prevede un data rate massimo di 150 Mbps in una topologia di rete ad anello, settabile anche in topologia star virtuale, su mezzo fisico POF (fibra ottica in plastica) per le versioni MOST 25 e MOST 150 o doppino in rame non schermato per le versioni MOST 50 e MOST 150. Il data rate di MOST 25 è di 24,8 Mbps in modalità sincrona o streaming (da cui la denominazione “25”), e di 14,4 Mbps in modalità asincrona o a pacchetti, con la presenza di un canale per il trasferimento di informazioni di controllo a 700Kbit/sec, utilizzate per configurare i device MOST e i trasferimenti sincroni e asincroni. Se MOST 50 raddoppia il data rate della prima versione, con anche una maggior dimensione dei frame, fino a 1024 bit, mantenendo gli stessi canali control, streaming e packet data, ben più importante, al di là di un data rate sei volte quello di MOST 25, l’innovazione introdotta da MOST 150 che prevede un layer fisico per l’implementazione di Ethernet nelle autovetture, e questo tramite un ulteriore Ethernet Channel oltre ai tre standard. Come dettagli, in una rete MOST, che è in grado di gestire fino a 64 device MOST con funzionalità plug & play che agevola connessione e disconnessione di singole unità, un dispositivo assume il ruolo di master con la denominazione di Timing Master, con gli altri organizzati come slave. Il ruolo del master consiste nel porre continuamente sull’anello di rete dei frame MOST, con un preambolo iniziale che è utilizzato dagli slave per sincronizzarsi, da cui una rete sincrona. Questo approccio, che elimina la necessità di buffering permettendo la connessione di device anche semplici, può essere paragonato a quello di una normale rete telefonica. La sincronizzazione garantita dal master permette il trasporto di streaming data channel multipli e di un canale di controllo utilizzato per definire quali canali di streaming devono essere usati da sender e receiver. Una volta stabilita la connessione, i dati fluiscono continuamente senza necessità di ulteriore indirizzamento, con assenza di interruzioni, collisioni o rallentamento del trasporto: meccanismo ideale per il delivering di data streaming quali audio o video. Per quanto riguarda il traffico internet o le informazioni dal sistema di navigazione, questi dati sono inviati in modo asincrono in burst compatti (letteralmente a “colpi”) come pacchetti secondo un meccanismo ottimizzato che non interferisce con i canali di control e streaming. Complessivamente un soluzione di comunicazione ideale per affrontare le future richieste del mercato in materia di intrattenimento e comfort.

 

FlexRay per drive-by-wire

Il termine “drive-by-wire” (letteralmente “guida tramite fili”) si riferisce a un controllo in cui, tramite delle ECU (Electronic Control Unit) non si ha più un collegamento diretto meccanico o idraulico con le diverse parti che permettono di guidare un’autovettura, ma piuttosto tra i relativi elementi sensori. Come esempio, il pedale dell’acceleratore non è collegato meccanicamente, e a seconda della sua posizione, il sensore riconosce la coppia richiesta dal conducente, e il sistema di gestione del motore regola, in conseguenza al segnale trasmesso, valvola a farfalla, pressione di sovralimentazione e accensione. Per realizzare queste prestazioni sono state ideate ideato già nel 1999 le prime specifiche del bus deterministico FlaxRay, come versione estesa del protocollo byteflight inizialmente studiato da BMW; questo bus è caratterizzato da una sicurezza attiva basata su canali di trasmissione ridondanti e meccanismi di sincronizzazione fault-tolerant, con data rate da 500Kbps a 10Mbps. In una rete FlexRay i diversi nodi sono collegati da doppino non schermato, secondo topologie diverse: multidrop, star e hybrid. Nel primo caso, la topologia è simile a quella di un bus CAN, con un bus singolo che collega le diverse ECU, mentre in una star network, che prevede più ECU connesse a un nodo attivo centrale, si ha la garanzia che in caso un’unità sia disconnessa le altre continuino a funzionare, ma anche che sia possibile una maggiore distanza tra ECU e nodo attivo, quindi una maggiore estensione della rete. Infine la topologia ibrida, di fatto una combinazione delle due precedenti, con un bus unico su cui sono agganciate più ECU ma anche più nodi centrali dai quali possono realizzarsi altrettante ramificazioni a stella. Da aggiungere che sono possibili soluzioni single o dual channel, da cui una o due coppie di cavi in rame non schermati. Il protocollo FlexRay è definibile come “time-triggered”, con caratteristiche tali da garantire che dati deterministici arrivino in un intervallo di tempo prevedibile, e dell’ordine dei microsecondi, ma anche per gestire dati di tipo “dynamic event-driven” come avviene in CAN. Questa presenza di frame sia statici che dinamici rappresenta concettualmente una complicazione che in FlexRay viene risolta tramite un pre-set communication cycle che definisce per i dati statici e dinamici dei precisi spazi configurati insieme alla rete dallo stesso progettista: in pratica, se con un bus come CAN i nodi devono sapere solo il bit rate corretto cui comunicare, in FlexRay i nodi devono essere a conoscenza anche di come tutte le parti della rete sono configurate. Poi, nel caso di un bus multidrop è ben noto che un solo nodo alla volta può comunicare, e se due nodi cercano contemporaneamente di accedere la situzione di contesa comporta un conflitto che corrompe i dati. Sempre riferendosi a CAN, il problema è risolto con uno schema di arbitrazione basato sulla priorità dei messaggi, metodo che però non può garantire nè un alto data rate nè che determinati dati siano messi a disposizione nei tempi richiesti come esige la logica drive-by-wire. Per questo in FlexRay la gestione di nodi multipli avviene tramite uno schema TDMA, Time Division Multiple Access: ogni nodo è sincronizzato con lo stesso clock, e attende il suo turno per scrivere sul bus, garantendo determinismo. Non si trascuri il fatto che si sta parlando in sostanza di una “embedded network”, ben diversa da una rete di PC o di dispositivi in un sistema di automazione, e caratterizzata da una configurazione chiusa che non si prevede di cambiare una volta definita. Ogni nodo deve essere precisamente configurato, e come strumento a disposizione del progettista il FlaxRay Commitee ha standardizzato un format per la memorizzazione e il trasferimento dei parametri, il FieldBus Exchange Format (FIBEX), per validare e testare le unità ECU.

 

LIN, Local Interconnect Network

A differenza del precedente bus FlaxRay, concepito per applicazioni sofisticate, il bus seriale LIN nasce alla fine degli anni ’90 per reti semplici, pur sempre in ambito Automotive, dove un consolidato bus CAN, che andrebbe benissimo, sarebbe però troppo costoso, e ancora una volta tra i protagonisti della proposta troviamo BMW e DaimlerChrysler, ma anche Audi, Volvo e Volkswagen. Giusto per chiarire l’ambientazione, tipiche applicazioni di LIN riguardano il collegamento di piccoli attuatori e sensori intelligenti (tipo sensori di pioggia), o la gestione del condizionamento. LIN si basa sull’uso di un’interfaccia UART a 8 bit, con architettura a singolo master e fino a 16 slave che sono sincronizzati dal master: si tratta tipicamente sempre di microcontrollori, ma le logiche sono implementate anche in forma di hardware specializzato o di ASIC, soprattutto volendo ottimizzare spazi, costi e consumi. Il data rate è limitato a 19,6 Kbps, su collegamento single wire (usando lo chassis del veicolo come “current return path”) di 40 metri massimo. In questa broadcast serial network tutti i messaggi sono quindi iniziati dal master con almeno uno slave che risponde, una volta riconosciuto il proprio identificatore, con la particoloarità che anche il nodo master può operare da slave rispondendo ai propri messaggi: questa organizzazione è tale per cui non è necessario prevedere meccanismo di collision detection alcuno. Da evidenziare che tramite LIN si possono implementare più semplici reti, poi collegabili come sottosistemi a una rete backbone, per esempio una rete CAN.

LASCIA UN COMMENTO

Please enter your comment!
Please enter your name here