Il protocollo Flexray: caratteristiche e funzionamento

I sistemi elettronici sono sempre più presenti nel settore automotive. oggi si tende a sostituire i classici sistemi idro-meccanici con sistemi puramente elettronici che siano più affidabili e faulttolerant. un esempio sono i sistemi x-bywire. per implementare tali tecnologie sono indispensabili protocolli affidabili e flessibili. tra quelli emergenti sicuramente il protocollo flexray riveste un ruolo preminente.

Con il termine FlexRay si intende un protocollo di comunicazione per sistemi distribuiti. Esso è stato sviluppato esclusivamente per applicazioni automotive, sebbene possa essere utilizzano anche in altri campi (per ulteriori informazioni si faccia riferimento all’approfondimento “Requisiti nel settore automotive”). È stato sviluppato dal consorzio FlexRay fondato nel 1999. Tra i membri iniziali si ricordano BMW, Bosch, DaimlerChrysler, Freescale Semiconductor, General Motors, NXP Semiconductors e Volkswagen. A questi si sono poi aggiunti altri marchi come Fiat, National Instruments, Renault e Fujitsu Microelectronics Europe GmbH. Lo scopo era quello di sviluppare un protocollo di comunicazione flessibile e fault-tolerant. Un sistema FlexRay è costituito da alcune unità di controllo elettronico, dette ECU, ciascuna con un controller che gestisce l’accesso ad uno o due canali di comunicazione. Un tale sistema è detto cluster FlexRay e rappresenta un sistema distribuito di tipo real-time.

Figura 1: logo flexRay. FlexRay è un protocollo di comunicazione per sistemi distribuiti di tipo fault-tolerant, appositamente sviluppato per sistemi automotive.

Figura 1: logo flexRay. FlexRay è un protocollo di comunicazione per sistemi distribuiti di tipo fault-tolerant, appositamente sviluppato per sistemi automotive.

Topologia di rete

Esistono diverse topologie di rete. Un cluster FlexRay consiste di uno o due canali. Il  primo tipo è chiamato single-channel ed il secondo dual-channel. Un cluster, inoltre, può essere realizzato tramite un bus, una rete a stella o con una configurazione cosiddetta ibrida. In una topologia dual-channel, ciascuna ECU può essere connessa sia ad un solo canale che ad entrambi. Alcuni esempi di configurazione a bus e a stella sono illustrati in figura 2.

Figura 2: la topologia di rete di un cluster FlexRay può essere di tipo a bus oppure a stella.

Figura 2: la topologia di rete di un cluster FlexRay può essere di tipo a bus oppure a stella.

In una topologia a stella, il punto di connessione centrale è detto star coupler. Una rete ibrida è una combinazione di una rete a bus e di una a stella. Questo significa che un canale è realizzato come un bus e l’altro come una stella. Un tipico esempio di tale configurazione è mostrato in figura 3.

Figura 3: topologia di rete ibrida di tipo singlechannel.

Figura 3: topologia di rete ibrida di tipo singlechannel.

Opzionalmente, possono essere aggiunti i cosiddetti bus guardian che consentono di incrementare la tolleranza ai guasti. Essi permettono di fronteggiare le principali cause di guasti che si possono presentare in una topologia a bus o a stella. Si tratta di dispositivi che sono posizionati tra il controller  del bus ed il canale nel caso di configurazione a bus, mentre sono posizionati nel centro stella nell’altra topologia di rete. Essi disconnettono la ECU dal canale, quando non è consentito loro di trasmettere dati.

ECU e Bus Controller

Un’unità di controllo elettronico (ECU) consiste di un processore con un blocco per la gestione della memoria ed una interfaccia di I/O. Il  controller del bus è collegato a quest’ultima interfaccia come un dispositivo di I/O, dotato delle seguenti porte:

➤ porta di controllo/stato (c/s).

➤ porta dati (data).

➤ Porta di configurazione (config).

L’intera struttura è mostrata in figura 4.

Figura 4: struttura completa di un nodo FlexRay: l’unità di controllo elettronico è collegata al controller del bus tramite le linee di configurazione, controllo e dati. Opzionalemente, possono essere anche presenti i bus guardian.

Figura 4: struttura completa di un nodo FlexRay: l’unità di controllo elettronico è collegata al controller del bus tramite le linee di configurazione, controllo e dati. Opzionalemente, possono essere anche presenti i bus guardian.

Come si nota, oltre al controller ed alla ECU, possono essere presenti anche i bus guardian.

Il  controller del bus è strutturato in sei componenti principali:

Interfaccia con l’host. Questo modulo fornisce l’interfaccia tra la ECU ed il bus controller.

Controllo operativo protocollo. Gestisce tutti i comandi del procollo FlexRay ed i relativi  stati.

Controllo di accesso al mezzo. Ha il compito di programmare l’assemblaggio dei messaggi e la trasmissione.

Elaborazione simboli e frame. Gestisce i messaggi  ricevuti e separa l’header dal payload.

➤ Unità di codifica e decodificaEsegue fisicamente l’accesso in scrittura e lettura al bus. Inoltre, l’unità decodifica un messaggio ricevuto e codifica un messaggio da trasmettere.

Sincronizzazione del clock. Questo blocco ha il compito di fornire un orologio locale per l’intero sistema. Ovviamente, esso deve essere sincronizzato con tutti gli altri.

Interfaccia con l’host

Il  blocco controller host interface (CHI) fornisce l’interfaccia tra il controller  del bus e la ECU. Come mostra la figura 5, il CHI consiste di tre parti fondamentali:

➤ l’interfaccia messaggi per la porta dati

➤ l’interfaccia di configurazione per la porta config

➤ l’interfaccia di controllo e stato per la porta c/s.

Figura 5: controller host interface.

Figura 5: controller host interface.

All’interno dell’interfaccia messaggi, sono presenti due buffer: uno in trasmissione (SB) ed uno in ricezione (RB). Nel primo, l’host deposita il payload per i messaggi che devono essere inviati sul bus. L’host riempie  il buffer scrivendo tramite la porta dati. Oltre a questo buffer, è utilizzato un puntatore a questa area di memoria (SBP); si tratta di un contatore utilizzato come indirizzo per accedere a SB. Quando l’host scrive dalla porta dati, i dati sono memorizzati all’indirizzo a cui punta SBP. Quindi SBP è incrementato di uno. In sostanza SBP indica il primo indirizzo libero in SB. Dal secondo buffer, l’host legge i  dati che sono stati ricevuti. Analogamente a quanto fatto per il buffer di ricezione, è mantenuto un puntatore (RBP) all’area di memoria RB. L’interfaccia di configurazione conserva alcuni parametri fondamentali. Essi sono scritti solo durante la fase di avvio, attraverso la porta di config. Durante  il funzionamento normale, tali parametri non vengono cambiati. Infine, l’interfaccia c/s fornisce all’host utili informazioni circa lo stato di ricezione dei frame. Inoltre, l’host può interagire con lo stato del bus controller inviando dei comandi tramite la porta c/s.

Controllo  operativo protocollo

Lo scopo principale del protocol operation control (POC) è rispondere ai comandi dell’host o a particolari condizioni, come stati di errore. Il POC imposta gli altri componenti nella condizione operativa appropriata. La macchina a stati che descrive il funzionamento  di un nodo FlexRay è mostrata in figura 6.

Figura 6: macchina a stati che descrive il funzionamento di un nodo FlexRay.

Figura 6: macchina a stati che descrive il funzionamento di un nodo FlexRay.

All’avvio,  il POC parte dallo stato di default config, per poi passare alla configurazione  del nodo nello stato config. Solo in questi due stati, il controller è configurabile tramite la porta config. Dopo la configurazione, il POC entra nello stato ready. Dipende poi dall’attività del canale di comunicazione se il  controller andrà in wakeup o in startup. In quest’ultimo stato, il controller si integra nel cluster. Finchè non si verifica nessun errore, esso rimane nello stato normal active. In caso di errore, il POC entra in normal passive e cerca di reintegrarsi nel cluster. Se, invece, si verifica un fatal error il controller blocca qualsiasi attività del nodo, mandandolo nello stato halt. Inoltre, all’host è concesso di modificare lo stato del controller. In ogni caso, il controller deve decidere se tale comando può o non può essere eseguito, in base allo stato attuale; per esempio, un comando di halt inviato dall’host è consentito solo se il nodo si trova in normal active o normal passive.

Controllo  di accesso  al mezzo

Il media access control (MAC) è il componente che gestisce la trasmissione dei dati dall’host verso il  bus. Esso programma l’accesso in scrittura al bus ed aggiunge l’header al payload. Nel protocollo FlexRay, a ciascuna ECU è concesso di trasmettere un messaggio solo all’interno di un certo intervallo temporale, chiamato slot. In ogni slot il MAC verifica se la relativa ECU può trasmettere. In caso affermati vo, il MAC importa il payload  dal buffer di trasmissione  (SB) e genera l’header del messaggio. Sarò poi l’unita di codifica/decodifica a segnalare quando il messaggio può essere scritto.

Elaborazione simboli  e frame

Il  componente frame and symbol processing (FSP)  gestisce la ricezione dei dati. È l’unità di codifica/decodifica a segnalare se un frame valido è stato ricevuto. Dopo la ricezione, il messaggio  viene suddiviso in header e payload. Quest’ultimo è copiato nel buffer di ricezione (RB). Inoltre, FSP fornisce lo stato all’host dopo ogni slot. Questa informazione è relativa all’ora locale per la sincronizzazione ed allo stato di ricezione del frame (per esempio, se è stato ricevuto un frame errato nello slot precedente).

Unità  di codifica/decodifica

L’unità coding/decoding (CODEC)  è il componente che fisicamente accede al bus. Quando il MAC segnala al CODEC di volere trasmettere un messaggio, quest’ultimo aggiunge il campo CRC per il controllo degli errori. A questo punto il messaggio viene codificato con gli opportuni valori di tensione. Per la ricezione dei frame, il CODEC è in ascolto sul bus. Quando arriva un messaggio, innanzitutto viene verificata l’integrità dei dati, tramite controllo del CRC e se tutto risulta corretto, è notificato ad FSP l’arrivo del messaggio.

Sincronizzazione del clock

Il  componente di sincronizzazione del clock esegue due modi di sincronizzazione e genera un’unità per la scansione del tempo locale, detta macrotick. In questo modo il controller dispone di una base temporale per la schedulazione dei messaggi e degli interrupt verso l’host. Tramite  il processo di sincronizzazione, si cerca di rendere uguale la lunghezza di tutti i macrotick nel cluster, evitando così che due nodi trasmettano nello stesso momento. Tale compito non è banale in sistemi distribuiti, poiché l’oscillatore locale può subire un drift dovuto a condizioni operative o di fabbricazione. Lo standard FlexRay prevede una variazione massima di 0.15% rispetto al clock di riferimento. Questo significa che il clock di due nodi possono differire tra loro al massimo di 0.3% . La sincronizzazione viene effettuata tramite messaggi di sync. La correzione è effettuata secondo due criteri: correzione dell’offset e del rate.

Figura 7: struttura di una communication round nel protocollo FlexRay. La presenza di un segmento statico con un numero fisso di slot garantisce una comunicazione con tempi deterministici.

Figura 7: struttura di una communication round nel protocollo FlexRay. La presenza di un segmento statico con un numero fisso di slot garantisce una comunicazione con tempi deterministici. Scheduling

Il  protocollo FlexRay utilizza una schedulazione dei messaggi di tipo time-triggered. Diversamente da un sistema event-triggered (come per esempio il protocollo CAN), uno time-triggered garantisce tempi di trasmissione deterministici. Questo è fondamentale per sistemi automotive critici, come lo sono per esempi gli x-by-wire. L’accesso al bus è programmato tramite uno schema TDMA (Time-Division Multiple Access), in cui la scrittura sul bus è consentita solo in intervalli prestabiliti, detti slot. A ciascuna ECU è assegnato un certo numero di slot. Il protocollo FlexRay prevede che ogni controller conosca i suoi slot di trasmissione, ma non sa nulla riguardo agli altri controller. Una programmazione completa di tutti i nodi è detta communication round. Esso contiene un segmento statico con un numero fisso di slot, una symbol window ed un tempo di inattività della rete. La symbol window è utilizzata per trasmettere messaggi speciali come simboli di wakeup. Durante  il periodo di inattivita della rete, il componente per la sincronizzazione del clock calcola ed esegue la correzione.

Processo di wakeup/startup

Una strategia di avvio è richiesta dopo l’accensione di un bus controller. In questo momento, infatti, il suo clock non risulta sincronizzato con gli altri. Inoltre, è richiesta una procedura per il riavvio dopo un fatal error, poiché lo stato halt può essere lasciato solo passando per il default config. Per soddisfare queste richieste, all’interno di un cluster FlexRay sono previste alcune ECU, dette coldstart node. Esse sono in grado di inviare messaggi broadcast contenenti l’informazione di sincronizzazione. Dopo l’accensione, un algoritmo di elezione sceglie il nodo leader fra tutti i coldstart node. Il  leader invia in broadcast l’informazione del tempo e gli altri bus controller possono integrarsi nei cluster sincronizzando  i loro orologi.

Come costruire un nodo FlexRay

In figura 8 è mostrato un semplice ed economico nodo FlexRay, realizzato utilizzando il  microcontrollore Fujitsu MB91F467D come host ed il dispositivo Fujitsu MB88121B come controller del bus.

Figura 8: schematico di un semplice ed economico nodo FlexRay utilizzando il micro MCU MB91F467D e il controller FlexRay MB88121B.

Figura 8: schematico di un semplice ed economico nodo FlexRay utilizzando il micro MCU MB91F467D e il controller FlexRay MB88121B.

Inoltre, il trasceiver  TJA1080 è un ottimo candidato per essere utilizzato come bus-driving. Il micro è stato appositamente sviluppato per soddisfare gli stringenti requisiti delle applicazioni automotive; tra le interfacce di cui dispone si possono ricordare CAN, LIN-UART e I2C. Una soluzione alternativa a quella appena presentata è quella di utilizzare un unico dispositivo con host e controller integrati. Un esempio è il modello del micro Fujitsu MB91F465XA. Per semplificare lo sviluppo del software, i progettisti possono far riferimento ad un ampia scelta di tool di differenti vendor. Tra questi si ricordano DECOMSYS, TZM e Vector CANtech.

 

 

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend