Embedded Systems: Communication

Transcript

1 Politecnico di Milano Embedded Systems: Embedded Systems: comunicazione real-time Lecturer: Prof. William Fornaciari

2 Sommario La comunicazione RT Introduzione Il bus CAN Il livello fisico Il livello dati Gestione degli errori Il bus TTP Il bus ByteFlight Estensioni RT per ethernet RTNET Rether - 2 -

4 Introduzione La comunicazione basata su bus soffre di un problema nella garanzia dei vincoli real-time La causa principale è dovuta all arbitraggio Se l arbitraggio favorisce l attore sbagliato, una comunicazione può non avvenire nei tempi previsti e si verifica un fallimento Le prestazioni massime di un bus sono fisse Se arrivano troppe richieste, il bus può risultare inadeguato Gestione con code di priorità Le ritrasmissioni modificano i tempi di trasmissione in modo impredicibile - 4 -

5 Introduzione In generale, vi sono due approcci alla gestione realtime di un bus Gestione ad eventi (CAN) event driven Gestione a tempo (TTP) time driven Oltre a queste due filosofie, se ne affianca una mista che cerca di riunire i vantaggi dei due approcci Si sovrappone una gestione time driven con una parte event driven - 5 -

6 Introduzione Il protocollo ethernet non ha nessuna garanzia realtime La politica di accesso al link, la CSMA/CD, non garantisce caratteristiche di determinismo Le contese sono risolte con ritardi generati su base statistica Non ci sono garanzie sui tempi di attesa Si presenteranno due approcci che estendono ethernet fornendo garanzie real-time RTNET protocollo TDMA Rether protocollo a token - 6 -

8 Il bus CAN Il protocollo CAN Controller Area Network è uno standard ISO ISO per le comunicazioni seriali Nasce per il settore automotive, ma al giorno d oggi è usato anche in altri settori, tra cui quello dell automazione industriale Lo standard, in riferimento alla pila ISO-OSI, copre solo il livello fisico e e il livello dati. Le altre funzionalità vengono demandate ad altri protocolli di livello superiore (Higher Level Protocol) Il livello fisico non è strettamente specificato, ma sono suggerite alcune realizzazioni di riferimento - 8 -

9 Il bus CAN il livello fisico Lo standard prevede due possibili livelli fisici High speed CAN Low speed CAN Entrambi questi standard utilizzano una trasmissione differenziale su una coppia di cavi Esiste uno standard, legato all automotive, suggerito in SAE J2411, caratterizzato da un singolo filo Comunque è previsto un riferimento di massa comune - 9 -

10 Il bus CAN il livello fisico La codifica prevista è la Non Zero Returning Riduce la banda necessaria Necessita di bit di stuffing Per motivi di sincronizzazione, ogni 5 bit uguali viene inserito un bit opposto (il bit di stuffing) che dovrà essere riconosciuto ed eliminato dal ricevitore Lo standard definisce i bit come recessivi e dominanti rispetto alle operazioni logiche AND e OR A seconda del tipo di cablaggio il bit dominante sarà 0 o 1 Si rendono possibili entrambe le implementazioni Tratteremo l OR wiring, utilizzando 1 come bit dominante e 0 come bit recessivo

11 Il bus CAN il livello fisico High speed CAN Trasmissione fino a 1 Mbit/s su distanza massima di 40m Doppino intrecciato Impedenza di 120 Ohm per annullare la rilfessione dei segnali Low speed CAN Trasmissione fino a 125 Kbit/s Doppino intrecciato I dispositivi collegati gestiscono in modo completo tutti i problemi che possono sorgere a livello fisico Detto anche CAN Fault Tolerant Single wire CAN Trasmissione fino a 33Kbit/s su un solo filo Necessario un riferimento a massa comune

12 Il bus CAN il livello dati Il punto chiave del bus CAN è la gestione delle comunicazioni orientata al contenuto A questo livello le comunicazioni sono tutte in broadcast non è previsto un indirizzamento diretto vero una particolare periferica Ogni messaggio ha una intestazione che contiene un identificatore di messaggio, che rappresenta la priorità del messaggio rispetto agli altri Le priorità sono: stabilite in fase di progetto sono statiche, non dinamiche devono essere univoche per ciascun tipo di messaggio Due diverse stazioni non devono poter trasmettere messaggi con lo stesso identificatore (priorità)

13 Il bus CAN il livello dati Vi sono due tipi di messaggio, oltre a diversi messaggi di segnalazione RF Remote Frame Frame senza campo dati che sollecita l invio di un valore DF Data Frame Frame di trasmessione dati EF Error Frame Rileva un errore e provoca la ritrasmissione OF Overload Frame Viene inviato da un nodo sovraccarico per ritardare la trasmissione del pacchetto successivo IS Interframe Space Precede ogni DF e RF e ha una funzione separatrice

14 Il bus CAN il livello dati I messaggi Data e Remote Frame sono composti da: Start Of Frame un solo bit 1 con due scopi distinguere i Data e Remote Frame dagli altri messaggi sincronizzare i ricevitori Arbitration Field contiene l identificatore del messaggio Remote Trasmission Request distingue tra RF e DF, con priorità al DF Control Field specifica la lunghezza del Data Field (4 bit) e 2 bit sono riservati per usi futuri Data Field (solo DF) contiene i dati e può avere una dimensione tra 0 e 8 bytes CRC Field sequenza di controllo d errore (16 bit) ACK campo che può essere sovrascritto da qualsiasi nodo per segnalare un errore di ricezione e chiedere la ritrasmissione del dato End Of Frame 7 bit uguali a zero per segnalare la fine della trasmissione

15 Il bus CAN il livello dati L arbitraggio avviene direttamente sul bus a livello di identificatore di messaggio (Arbitration Field) Ciascuna stazione trasmittente, mentre trasmette, monitora il bus Qualora ci fosse un conflitto con un identificatore più alto (basso), l OR (AND) wiring cambia il valore presente sul bus Tutte le stazioni trasmittenti che perdono l arbitraggio diventano ricevitori del messaggio Questo meccanismo garantisce tempi di trasmissione certi ai messaggi con più alta priorità La priorità deve essere scelta opportunamente dal progettista

16 Il bus CAN la gestione degli errori La gestione degli errori avviene al livello dati La presenza di diversi tipi di protezione dagli errori insiti nel protocollo stesso, ha garantito una larga diffusione del protocollo CAN Protezione sul messaggio CRC ACK Frame check Protezione a livello di bit Monitoring Bit stuffing Autoesclusione delle stazioni riceventi Se presentano una percentuale di errori elevata, per non compromettere l intero bus con continue ritrasmissioni, le stazioni riceventi possono autoescludersi

17 Il bus CAN la gestione degli errori La protezione sul messaggio CRC a 16 bit Nel messaggio viene incluso un codice a correzione d errore di 16 bit calcolato sui dati inviati ACK Il segnale di ack chiede la ritrasmissione del messaggio nel caso in cui il controllo CRC o l identificazione delle componenti del messaggio falliscano Protezione sui bit Il monitoring dello stato del bus permette al trasmettitore attivo di identificare propri errori, nonchè errori globali Il bit stuffing garantisce la sincronizzazione in caso di sequenze di bit identici superiori a 5 elementi

18 Il bus CAN la gestione degli errori Autoesclusione Ogni stazione gestisce due contatori Errori rilevati o segnalati da altri durante la trasmissione Errori in ricezione I contatori vengono incrementati da ciascun errore identificato con le metodologie precedenti assegnando anche una gravità In base al valore assunto dai due contatori, la stazione si pone in uno dei seguenti stati Error active: il numero di errori è accettabile e la stazione partecipa alla trasmissione Error passive: la stazione commette un numero elevato di errori; la segnalazione di errore non genera automaticamente la ritrasmissione Bus off: la stazione commette un numero di errori che comprometterebbe la rete. La stazione non partecipa alla rete, ma si mette in modalità di ascolto. Può riprendere le trasmissioni solo quando il bus è libero e non partecipa alle contese. Il nodo resta in attesa di 11 o più bit recessivi consecutivi che costituiscono lo spazio minimo tra due frame consecutivi

19 Il bus CAN TTCAN TTCAN è un protocollo di alto livello che, basandosi su un infrastruttura CAN, gestisce la trasmissione dei dati sia in modalità time-triggered sia in modalità event-triggered TTCAN è l acronimo di time-triggered CAN È definito nello standard OSI L utilizzo di TTCAN permette di gestire i controlli in catena chiusa mediante CAN e di migliorare le prestazioni di CAN caratterizzando le esigenze temporali di ciascun tipo di segnale Segnali periodici Segnali associati ad eventi

20 Il bus CAN TTCAN Ogni stazione possiede un livello software che gestisce la sincronizzazione mediante il riconoscimento di un reference frame Tutte le stazioni sono sincronizzate e ogni stazione sa dopo quanto tempo dal reference frame deve iniziare a trasmettere Il periodo di tempo che intercorre tra due reference frame è detto frame cycle e non è necessariamente costante Si possono servire le diverse esigenze con periodi differenti La somma dei diversi frame cycle fornisce il tempo di ciclo

21 Il bus CAN TTCAN Frame Cycle 0 Reference Message Message A Msg C Message M Message M Msg C Frame Cycle 1 Reference Message Message A Msg R Arbitration Message D Msg C Frame Cycle 2 Reference Message Message A Arb Message M Message M Msg C Frame Cycle 3 Reference Message Message A Msg U Arbitration Message D Msg C Il singolo frame cycle è suddiviso in finestre Alcune dedicate a particolari messaggi o stazioni Altri lasciati all arbitraggio per l invio di messaggi event-triggered

22 Sommario La comunicazione RT Introduzione Il bus CAN Il livello fisico Il livello dati Gestione degli errori Il bus TTP Il bus ByteFlight Estensioni RT per ethernet RTNET Rether

23 Il bus TTP Il TTP (Time Triggered Protocol) è basato su TDMA (Time Driven Multiple Access) statico al bus da parte delle diverse stazioni Questo approccio si contrappone al bus CAN Il bus CAN gestisce l accesso in modo event-triggered attraverso la risoluzione delle contese Lo scheduling statico delle trasmissioni garantisce ad ogni stazione di poter comunicare, ed essere quindi ascoltata, ad intervalli predefiniti Non si corre il rischio di rinvii indefiniti Lo scheduling statico può portare a un tempi di bus inutilizzati e a un basso utilizzo della risorsa

24 Il bus TTP Il bus TTP è stato ottimizzato sia per una topologia a stella sia per una topologia ad anello Ad ogni modifica della topologia deve seguire una riconfigurazione di tutte le stazioni Nel caso di un nuovo nodo trasmittene, è necessario riconfigurare tutti i nodi al fine di riservare uno slot di trasmissione per il nuovo nodo Viste le caratteristiche principali del bus TTP, si intuisce che questo protocollo è indicato per le applicazioni mission critical In queste applicazioni non è fondamentale lo sfruttamento del bus, ma deve essere garantito il ritardo massimo da quando un nodo vuole trasmettere a quando il nodo può effettivamente comunicare

25 Il bus TTP il livello fisico Il bus TTP è stato implementato e testato su diversi tipi di livello fisico (tra cui anche sul bus CAN) Attualmente, è stato definito uno standard specifico per la realizzazione di un bus TPP Lo standard, purtroppo, non è disponibile pubblicamente, ma se ne conoscono le caratteristiche principali Tensione di funzionamento compresa tra -12 V e +20 V Throughput: 25Mbit/s in modalità sincrona, 5Mbit/s in modalità asincrona Funzionalità di wake-up e sleep integrate nel livello fisico Autodiagnosi e sezionamento della rete in caso di probelmi elettrici a livello fisico Disponibile anche con comunicazione su fibra ottica

26 Il bus TTP il livello fisico La sincronizzazione del clock non è gestita in modo centralizzato La sincronizzazione si basa sulla conoscenza a priori delle durate della trasmissione Ogni stazione può calcolare la deviazione tra il proprio clock e quello del trasmettitore ed allinearsi Sono state testate topologie sia a stella che a bus Per aumentare la robustezza ai guasti, sono state testate anche architetture a stella con più centri stella, in modo tale da scongiurare il blocco del sistema per un guasto al controller di centro stella (Single Point of Failure)

27 Il bus TTP arbitraggio In un bus con gestione TDMA pura, non esistono casi di contesa e l arbitraggio avviene in modo puramente statico e deterministico L arbitraggio è stabilito nella fase di progettazione del sistema Ad ogni nodo è assegnata una parte della banda disponibile, suddividendo in time slot di durata differente ciascun round TDMA. Ogni stazione può trasmettere solo nel time slot ad essa assegnato Ogni stazione ha quindi garanzie di banda e ritardi di trasmissione certi

28 Il bus TTP gestione degli errori Un guasto ad una stazione corrisponde al suo time slot inutilizzato Il sistema di interfacciamento al bus fa sì che una stazione guasta non posso scrivere nei time slot a lei non assegnati, evitando di bloccare tutto il bus in caso di singolo malfunzionamento (nodi fail silent) La protezione sui dati trasmessi viene affidata ai livelli di comunicazione superiori La garanzia di continuità di funzionamento del bus è dimostrata nell ipotesi di guasto singolo Un solo errore grave si verifica nello stesso istante nel sistema

30 ByteFlight ByteFlight è un bus seriale ad alta velocità sviluppato per applicazioni automotive da: BMW Motorola ELMOS Infineon Siemens EC Steinbeis IXXAT Attualmente è utilizzato da BMW nella produzione di serie delle vetture serie 7 È utilizzato ad Avidyne per la produzione di materiale avionico

31 ByteFlight il livello fisico Il bus, studiato per la fibra ottica con topologia a stella, unisce le caratteristiche di un protocollo event-driven e di uno time-driven, sfruttando i vantaggi di ciascuna soluzione Le prestazioni (10Mbit/s) e il campo applicativo per cui è stato studiato, mostrano un collegamento fisico particolarmente soggetto a disturbi di natura elettromagnetica Per questo motivo, il livello fisico si base su POF fibre ottiche plastiche in half-duplex e con topologia a stella

32 ByteFlight il livello fisico Nonostante il notevole costo e la complessità nella gestione dei segnali ottici, i vantaggi che se ne derivano giustificano le scelte effettuate L isolamento elettrico dei vari componenti L immunità del sistema da blocchi dovuti a guasti sorti in una stazione A patto di ridurre le prestazioni, è possibile utilizzare normali connessioni in rame con doppino ritorto Esistono anche controllori commerciali che fungono da bridge tra più bus CAN e ByteFlight

33 ByteFlight FTDMA L accesso al bus è definito FTDBA Flexible Time Division Multiple Access Tutti gli elementi che accedono al bus hanno una base temporale comune, generata dal segnale di SYNC che contraddistingue l inizio di un ciclo Ogni stazione può essere configurata come SYNC Master e gli altri si allineano al segnale ricevuto Il tempo di ciclo è suddiviso in time slot L utilizzo dello slot è regolato dal protocollo e implementato in hardware Durante ogni slot viene incrementato un contatore, che ogni stazione confronta con l identificativo assegnato al messaggio che deve trasmettere Se l identificativo corrisponde, la stazione impegna il bus e trasmette Se nessuna stazione ha un messaggio da trasmettere con quell identificativo, dopo un breve periodo di tempo di attesa, il contatore viene incrementato e la procedura si ripete

34 ByteFlight FTDMA I messaggi con ID basso sono serviti in tempi brevi, mentre quelli con vincoli meno stringenti sono serviti solo quando il bus è libero Si riesce a garantire un tempo di risposta deterministico per i messaggi con priorità alta e un utilizzo elevato del bus da parte degli altri messaggi quando è libero In altre parole, il tentativo di ByteFlight è quello di fornire il determismo dei protocolli time-driven con lo sfruttamento del bus dei protocolli event-driven

35 ByteFlight FTDMA A SYNC B A trasmette un messaggio con ID 4, mentre B trasmette due messaggi con ID 1 e 7 Le attese per gli ID 2,3,5,6 sono molto brevi

36 ByteFlight formato dei messaggi ID LEN D0 D11 ID CRCL I messaggi sono formati da: 6 bit di start Un byte per l ID La lunghezza del messaggio Il payload max 12 byte Due CRC finali Questi due CRC garantiscono una distanza di Hamming pari a 6 Ogni byte di dati è separato da un bit di stop e un bit di start La fine del messaggio è composta da due bit posti a zero

37 ByteFlight gestione degli errori Poichè non si possono effettuare ritrasmissioni immediate, la gestione degli errori viene effettuata a livello di messaggio e di sistema A livello di messaggio ne viene controllata l integrità e la rispondenza alle specifiche Se è il caso, viene generato un messaggio d errore e la ritrasmissione avviene dopo il minimo intervallo di idle Se si è persa la sincronizzazione tra i vari elementi, non avviene alcuna ritrasmissione fino a quando il sistema non si è risincronizzato nuovamente Il centro stella partecipa attivamente effettuando controlli di sistema, escludendo stazioni che violano il time slot di trasmissione e controllando le prestazioni del canale ottico Ogni transceiver si autoesclude in caso di violazione dei vincoli fisici

39 Estensioni RT su ethernet Ethernet è un protocollo non real-time Il suo meccanismo di arbitraggio per la risoluzione delle contese non fornisce garanzie di determinismo La risoluzione delle contese avviene ripetendo la trasmissione dopo un tempo di attesa casuale Statisticamente, le due stazioni che si contendono il bus aspettano due tempi diversi Scaduto il tempo di attesa e si riprova a trasmettere Non si può escludere, almeno dal punto di vista teorico, che le stazioni possano soffrire di rinvii indefiniti Si analizzeranno due estensioni per ethernet che forniscono alcune garanzie real-time RTNET Rether

40 RTNET RTNET è un protocollo OpenSource, con caratteristiche real-time basato su RTAI, un estensione RT di Linux RTNET sfrutta hardware ethernet classico, non richiede interfacce particolari Realizza UDP/IP, ICMP e ARP in modo deterministico Fornisce un socket BSD standard per l utilizzo con il kernel RTAI e processi utente real-time La gestione delle contese avviene attraverso RTmac, un protocollo a livello mac che gestisce l accesso alla risorsa

41 RTNET RTNET gestisce il traffico non real-time (TCP/IP) sulla stessa interfaccia di rete sulla quale passa il traffico real-time Permette di realizzare su un unico cavo entrambe le tipologie di traffico senza però impattare le prestazioni real-time Ovviamente, l impatto è limitato alle prestazioni non real-time Il progetto ha natura accademica, anche se è maturato e, oggi, si può considerare piuttosto stabile

42 RTNET - RTmac RTmac realizza un sistema che fornisce garanzie temporali di risposta su una struttura fisica già esistente e che non fornisce nessun tipo di determinismo temporale La tecnica utilizzata da RTNET è quella di costruire un sistema TDMA sopra il CSMA/CD esistente In altre parole, si istruiscono le diverse perficerche imponendo un tempo preciso di trasmissione, in modo da evitare che accadano contese e il CSMA/CD introduca l indeterminismo temporale

43 RTNET - RTmac Il protocollo RTmac consta di tre fasi: Distribuzione da parte di un master di un invito a tutti i client contenente la configurazione di RTmac Scambio degli indirizzi fisici (i MAC address) e delle configurazioni arbitrarie di ciascun client Sincronizzazione finale dopo le fasi di inizializzazione Tutte le periferiche interfacciate sulla rete devono essere compatibili con RTNET A priori deve essere stabilito, assegnato e implementato il ruolo di master La rete deve essere quindi dedicata, non è possibile miscelare diverse reti La rete è quindi dedicata a messaggi RT La trasmissione di messaggi non real-time avviene incapsulandoli in messaggi RT L header MAC è molto semplice e contiene solo le informazioni essenziali Tipo di pacchetto Il pacchetto realizza un tunnelling di messaggi non RT

44 RTNET TDMA v2.1 Il protocollo TDMA usato prevede la sincronizzazione iniziale dei vari membri della rete mediante un pacchetto speciale Start Of Frame - SOF Dopo il SOF, tutti i partecipanti calcolano il tempo che deve intercorrere prima del proprio time slot La divisione in time slot, le loro durate e il loro assegnamento viene stabilito durante la fase di inizializzaione e resta immutata fino ad una nuova inizializzazione dell intera rete Se è previsto il tunnelling di dati non RT, si riservano un certo numero di time slot Il numero di questi time slot viene stabilito in modo da rispettare tutte le richieste temporali dei nodi RT

45 RTNET RTcfg RTcfg è il protocollo che realizza la configurazione di RTNET nella fase di inizializzazione della rete Gli ultimi sviluppi, hanno introdotto in RTNet la capacità di hot-plugging e quindi la configurabilità dinamica dell intera rete In caso di guasto di un nodo, non è necessario far ripartire il sistema I messaggi di configurazione di RTcfg sono inviati da un gestore centralizzato che rileva, gestisce e segnala ogni situazione particolare, comprese le fasi iniziali

46 Rether Rether Realtime ETHERnet si propone di gestire il problema delle collisioni mediante un meccanismo di token, che viene passato tra le varie stazioni della rete In questo modo, Rether può garantire una certa banda a ciascuna stazione Il protocollo si propone di essere assolutamente trasparente verso il software di alto livello Il protocollo è integrato nei driver di accesso allo hardware ethernet standard Garantisce la compatibilità con i protocolli UDP, TCP e RTP

47 Rether Vengono fornite una serie di primitive (API) che permette l utilizzo da parte degli applicativi utente delle caratteristiche real-time Le applicazioni non real-time sfrutteranno la parte di banda non occupata dalle applicazioni real-time Il protocollo ha la possibilità di cambiare la propria modalità di funzionamento da token a CSMA/CD quando non sono presenti comunicazione RT Ovviamente, tutte le stazioni presenti nella rete devono avere dei driver che supportano Rether La rete viene idealmente suddivisa in nodi RT (real-time) e nodi NRT (non real-time) I nodi non corrispondono necessariamente a nodi fisiciamente separati I nodi RT possono mandare un messaggio in broadcast che richiede il passaggio alla modalità di funzionamento a token, ovvero real-time

48 Rether modalità RT I nodi real-time sono numerati in sequenza Il primo nodo della sequenza genera il token di trasmissione RT Il protocollo stabilisce due tempi: Tempo di token: tempo durante il quale un nodo può trattenere il token Tempo totale tra la creazione e la distruzione del token Questi tempi sono generati per garantire La banda richiesta da ciascuna stazione I tempi di risposta richiesti

49 Rether modalità RT Il nodo RT che detiene il token Se deve trasmettere, effettua la trasmissione per una durata massima pari al tempo di token, passando poi il token al nodo RT successivo nella sequenza di numerazione Se non deve trasmettere, il nodo RT passa subito il token al nodo RT successivo nella sequenza di numerazione Il passaggio dei token avviene in questo modo fino al raggiungimento dell ultimo nodo RT L ultimo nodo RT inoltre il token al primo nodo NRT Il token è contrassegnato da un suo tempo di validità, entro il quale le trasmissioni NRT devono essere terminate

50 Rether modalità RT Il token viene fatto girare tra le varie stazioni NRT fino allo scadere del suo tempo di validità o al raggiungimento dell ultimo nodo NRT Se una stazione NRT non riesce a concludere la trasmissione entro il tempo di validità del token, sarà la prima a ricevere il token nel round successivo Le sezioni del protocollo più complesse riguardano Inizializzazione dei tempi Variazione dei tempi

51 Rether inizializzazione Quando un nodo RT ha terminato la propria trasmissione, invia in broadcast un messaggio di fine RT Quando tutti i nodi RT hanno terminato la trasmissione, la rete torna in modalità CSMA/CD Il meccanismo si basa sul fatto che tutti i nodi dispongono di una lista dei nodi RT, che mantengono aggiornata ad ogni ricezione dei messaggi di broadcast di fine RT

52 Rether inizializzazione Quando la rete si trova in modalità standard, il messaggio di switch-to-rt viene gestito in CSMA/CD I token inizia a girare e quando i nodi RT lo ricevono, stabiliscono quanta banda riservarsi comunicandola in broadcast Se un nodo NRT necessita di trasmissione RT, lo può annunciare in broadcast quando riceve il token Ogni nodo, nel riservarsi la banda, esegue dei test di ammissibilità Se la banda non è sufficiente, la richiesta di trasmissione RT fallisce

53 Bibliografia M. Inzaghi, Protocolli e reti Real-Time, dispensa per il corso di Sistemi Embedded, AA 2004/