Indice
Indice... 1
Introduzione ... 3
1 Controller Area Network... 6
1.1 Fieldbus Network... 6
1.2 Protocollo CAN... 7
1.3 Struttura di una rete CAN ... 9
1.4 Struttura dei Frame... 12
1.5 Uso degli Identificatori ... 15
1.6 Rilevamento e gestione degli Errori... 18
2 Analisi del traffico su rete CAN ... 22
2.1 Sistemi in tempo reale... 22
2.2 Politiche di Scheduling ... 25
2.3 Analisi del Tempo di Risposta ... 28
2.4 RTA statistica... 31
2.5 Implementazione di un Canale Vocale su rete CAN ... 32
2.6 Modello del traffico presente su una rete CAN ... 33
2.6.1 Messaggi periodici ad alta priorità... 34
2.6.2 Messaggi aperiodici e casuali a priorità massima ... 37
2.7 Traffico introdotto dall’interfono... 39
3 Analisi del set-up sperimentale ... 42
3.1 Panoramica sul set-up sperimentale... 42
3.2 Interfono... 47
3.3 Generatore di traffico periodico... 52
3.4 Generatore di traffico casuale ... 57
3.4.1 Analisi del programma Genera Intervalli... 61
3.4.2 Analisi del programma Traffico_casuale... 70
3.5 Analizzatore di traffico ... 75
4 Risultati sperimentali ... 77
4.1 Validazione della generazione del traffico casuale... 77
4.2 Introduzione al lavoro sperimentale... 79
4.3 Prove effettuate con traffico di controllo periodico ... 82
4.3.1 Prove oggettive... 83
4.3.2 Prove soggettive... 86
4.4 Prove effettuate con traffico di controllo periodico e casuale... 91
Conclusioni ... 101
Appendice A... 103
A-2 Istruzioni del programa Traffico Casuale ... 109 Bibliografia ... 113
Introduzione
Nell’ultimo decennio si sta largamente diffondendo la tendenza a sfruttare le reti di comunicazione dati, Data Network, per la trasmissione della voce in formato digitale. I vantaggi offerti da questo tipo di soluzioni consistono nella possibilità di integrare uno o più canali vocali all’interno di una rete dati già esistente. In questo modo è possibile, per esempio, creare delle postazioni telefoniche in diversi punti della stessa linea di comunicazione utilizzata per la trasmissione dati senza la necessità di un ulteriore cablaggio dedicato alla sola trasmissione dei segnali vocali.
A causa della presenza del traffico dati, i segnali vocali possono tuttavia subire dei ritardi in fase di trasmissione e questo fenomeno può causare una degradazione della qualità della voce o addirittura la perdita di intelligibilità. Nel caso di internet, ad esempio, le problematiche relative a VoIP (Voice over IP) vengono affrontate mediante l’utilizzo di sofisticati algoritmi di compressione della voce e routing dei pacchetti che sfruttano le numerose risorse computazionali presenti in ciascun nodo della rete.
Lo scopo di questo lavoro è quello di indagare e caratterizzare sia teoricamente che sperimentalmente la trasmissione di segnali vocali in una rete basata sul protocollo di comunicazione Controller Area Network (CAN) per lo scambio di informazioni all’ interno di un sistema di controllo distribuito.
Le reti CAN trovano largo impiego in sistemi (come quello automotive) in cui è necessario collegare in modo semplice e flessibile vari dispositivi di controllo; tale collegamento viene effettuato attraverso un unico bus dalla struttura lineare. L’introduzione di un canale vocale può quindi avvenire semplicemente
connettendo al bus nuovi nodi in grado di interfacciare tipicamente un microfono e un auricolare e trasmettere e ricevere i dati audio in formato digitale sul bus CAN. E’ tuttavia necessario garantire che il traffico vocale introdotto dall’interfono non alteri i tempi di risposta dei messaggi, costituiti dai dati di controllo, già presenti sul bus. Basti pensare infatti che la maggior parte di questi ultimi rappresenta lo scambio di informazioni in tempo reale fra i sensori e gli attuatori del sistema e costituisce, per questo motivo, un insieme di messaggi a priorità elevata la cui trasmissione non può essere ritardata nel tempo.
La soluzione adottata in VoCAN (Voice over CAN) per risolvere tale problema, è quella di assegnare basso livello di priorità ai messaggi vocali nella rete; per questo motivo la loro trasmissione può avvenire soltanto quando il bus è libero. Il traffico di controllo della rete influenza quindi il ritardo di trasmissione dei dati vocali e conseguentemente la qualità della voce riprodotta dall’interfono.
Per eseguire un’analisi quantitativa del segnale vocale trasmesso su rete CAN, è quindi necessario sviluppare un modello del traffico presente in tale rete. La campagna sperimentale è stata effettuata per valutare i limiti di disturbo e di intelligibilità del segnale vocale al variare del carico di lavoro complessivo del bus. Gli esperimenti sono stati svolti simulando sul bus CAN una condizione di traffico di controllo più generale possibile ed attivando la trasmissione dei messaggi vocali provenienti dall’interfono; i limiti suddetti sono stati quindi espressi in funzione del valore del carico di lavoro totale del bus.
L’esposizione del lavoro compiuto è stata suddivisa in quattro capitoli: o Il Capitolo 1 fornisce una definizione dei Fieldbus Network ed introduce
in modo generale le differenze fra sistemi di tipo Producer/Consumer e sistemi Master/Slave. Vengono quindi analizzate in particolare le caratteristiche delle reti CAN. La parte finale descrive in dettaglio le specifiche di tale protocollo di comunicazione.
o Il Capitolo 2 analizza le caratteristiche del traffico presente in una rete CAN. Nella prima parte vengono introdotti i concetti relativi alle politiche di scheduling ed all’analisi del tempo di risposta dei messaggi. Nella
seconda parte viene descritto ed analizzato un modello di traffico realistico dei dati di controllo del sistema.
o Il Capitolo 3 prende in considerazione il set-up sperimentale utilizzato. Viene descritto in modo generale il funzionamento dei nodi che costituiscono l’interfono e dell’analizzatore di traffico della rete. Viene inoltre effettuata un’analisi accurata dei generatori di traffico (periodico e casuale) giustificando le scelte progettuali adottate.
o Il Capitolo 4 descrive gli esperimenti compiuti sul sistema ed espone i dati ricavati dalle prove interpretando i risultati ottenuti.
1 Controller Area Network
1.1 Fieldbus Network
Una soluzione efficiente, impiegata soprattutto in ambito industriale, per collegare dispositivi che controllano singole parti di un processo produttivo è quella di connettere tutti i componenti del sistema con un unico bus dalla struttura semplice e flessibile. In particolare, una Fielbus Network [1] è una speciale rete locale dedicata alle applicazioni nel campo dell’acquisizione dati e del controllo di sensori ed attuatori, ottimizzata per lo scambio di messaggi di comando e di stato, cioè di frame di dimensioni normalmente modeste.
La grande diffusione delle Fieldbus Network dipende dai numerosi vantaggi offerti dall’utilizzo di un unico bus che è condiviso da tutti i dispositivi presenti nel sistema. In primo luogo il cablaggio risulta drasticamente meno complesso e ingombrante rispetto all’approccio tradizionale di una connessione punto-punto con conseguente riduzione dei costi e dei tempi d’installazione. Inoltre l’approccio a bus conferisce al sistema una notevole flessibilità nell’introduzione di nuove stazioni e nel riutilizzo del sistema.
Poiché lo scopo principale per cui si adotta questo tipo di reti è quello di ridurre la complessità dei collegamenti fra i vari dispositivi, il trasferimento dei dati avviene in modo seriale ed è gestito da un apposito protocollo che stabilisce la velocità di trasmissione, la struttura dei singoli messaggi (codifica dell’informazione nei singoli frame), l’assegnazione di identificatori, le modalità di accesso al bus e di risoluzione dei conflitti, il controllo e la gestione dei possibili errori.
o Sistemi di tipo Producer/Consumer
o Sistemi di tipo Master/Slave
Nel primo caso all’interno della rete non ci sono dispositivi dedicati a gestire l’accesso al bus: qualunque nodo può acquisirne momentaneamente il comando ed iniziare una trasmissione mentre tutti gli altri si attivano in ricezione. In tali sistemi il trasmettitore non specifica l’indirizzo del dispositivo a cui inviare il messaggio (consumer) ma fornisce informazioni sul mittente (producer) o sul contenuto del messaggio stesso. Nel caso di accesso simultaneo al bus da parte di due o più nodi, il conflitto può essere risolto in base al tipo di protocollo di comunicazione adottato.
Nei sistemi di tipo Master/Slave, invece, la rete è dotata di uno o più nodi (master) che svolgono la funzione di arbitri per l’accesso al bus; tutti gli altri (slave) risultano semplici utilizzatori del canale di comunicazione.
1.2 Protocollo CAN
Controller Area Network (CAN) è un protocollo di comunicazione seriale in grado di gestire con elevata efficienza la comunicazione di un sistema di controllo distribuito di tipo real-time garantendo un alto livello di affidabilità [1]. E’ stato creato agli inizi degli anni ‘80 da R. Bosch GmbH in Germania [2] per applicazioni in ambito automotive; a partire dal 1985 la collaborazione con Intel ha permesso ulteriori miglioramenti delle specifiche del protocollo stesso e la sua integrazione su silicio; nel 1993 è stato standardizzato a livello internazionale (ISO 11898) e realizzato su silicio da diversi produttori di semiconduttori.
Ad oggi il suo principale settore di applicazione [3] rimane quello automotive vista l’importanza sempre più crescente che l’elettronica assume all’interno dell’autoveicolo; basti considerare l’elevato numero di dispositivi elettronici che si scambiano informazioni all’interno di un’autovettura per capire come un tradizionale sistema di collegamento possa diventare troppo ingombrante. La scelta di utilizzare una Fieldbus Network risulta invece molto più conveniente: le connessioni punto-punto sono sostituite da un’unica linea (bus) che percorre tutto il veicolo e a cui si collegano le interfacce e le centraline ed
inoltre l’introduzione di nuovi dispositivi volti a migliorare le prestazioni del sistema viene notevolmente facilitata dalla grande flessibilità della rete di collegamento.
Anche nei mezzi di trasporto pubblico il CAN trova un largo impiego: molti treni lo utilizzano ad esempio per la connessione delle centraline di controllo dei freni e dei meccanismi di apertura e chiusura delle porte presenti in ogni vagone.
Nella produzione di strumentazione medica [1] si fa largo uso di tale protocollo soprattutto in applicazioni di monitoraggio (collegamento di sonde o sensori posti in ambienti differenti) e conseguente trasferimento dei dati da analizzare.
In campo industriale viene ampiamente impiegato sia a livello di singolo macchinario che all’interno dell’impianto stesso per lo scambio di informazioni ed il controllo del processo di produzione.
Un altro settore di impiego è rappresentato dal home automation dove il CAN viene usato in sistemi che controllano l’illuminazione, l’apertura delle finestre, il riscaldamento (i sensori sono posti nei vari ambienti), la distribuzione dell’aria condizionata, etc.
La possibilità di introdurre un canale vocale all’interno di una rete CAN già esistente può quindi risultare piuttosto vantaggiosa visto il largo impiego dei sistemi che sfruttano tale protocollo di comunicazione; l’interfono può essere realizzato senza dover introdurre una nuova linea dedicata alla comunicazione audio ma utilizzando semplicamente il bus già presente per collegare i nodi vocali.
All’interno dell’autovettura, ad esempio, la rete CAN che collega i vari dispositivi elettronici, che inviano i segnali di stato e di controllo del sistema, può essere anche impiegata per effettuare il trasferimento di pacchetti vocali (o più in generale di segnali audio). In questo modo è possibile integrare l’impianto sonoro dell’auto all’interno del sistema CAN e quindi realizzare un interfono che permetta il collegamento del telefono cellulare direttamente agli altoparlanti attraverso l’unico bus presente nel veicolo.
L’invio di segnali vocali su rete CAN può risultare vantaggioso anche all’interno di mezzi di trasporto più grandi come il treno, l’aereo o la nave. In questi casi l’introduzione di un interfono può consentire la diffusione del segnale audio nei vari ambienti (carrozze, gabine, sala macchine…) oltre che il collegamento telefonico fra singoli apparecchi posti in diversi punti.
Inoltre, anche nella home automation l’introduzione di un interfono all’interno del sistema CAN già esistente può far fronte alla necessità di creare un collegamento telefonico fra i diversi ambienti utilizzando semplicemente il bus che permette ai vari dispositivi connessi alla rete lo scambio dei dati di controllo.
1.3 Struttura di una rete CAN
Una rete CAN consente di collegare fra di loro un numero teoricamente infinito di dispositivi, che costituiscono i nodi della rete, in modo da garantire lo scambio di informazioni all’interno di un sistema. Nella sua versione più tradizionale, mostrata in Figura 1.1, il bus è costituito da un doppino intrecciato (schermato o no in base alle applicazioni) terminato con impedenze pari a 120 Ω ma, poiché le specifiche del protocollo non si occupano della descrizione del mezzo fisico, la linea di trasmissione può essere realizzata anche con fibre ottiche e sistemi wireless via radio o infrarossi [1].
I dati da trasmettere sono raggruppati in messaggi di lunghezza limitata (un messaggio CAN può trasportare da 0 a 8 byte come contenuto informativo) e inviati sul bus in modo seriale con la possibilità di stabilire la velocità di comunicazione fino a 1 Mbps.
L’informazione viene codificata attraverso due livelli logici: o 0 logico, detto dominante
o 1 logico, detto recessivo
Quando nessun nodo della rete è attivo in trasmissione, il bus è mantenuto nello stato recessivo; questa condizione viene definita bus idle.
Il protocollo di comunicazione utilizza la codifica NRZ (No Return to Zero) in cui il livello elettrico della linea rimane costante sulla linea per tutto il tempo di bit; tale codifica ha il vantaggio di avere una larghezza di banda inferiore rispetto ad altre sebbene non permetta di sincronizzare i nodi della rete in caso di lunghe sequenze con la stessa polarità. Infatti la frequenza degli oscillatori locali dei vari nodi può essere leggermente diversa e quindi, dopo un certo intervallo di tempo, è necessario risincronizzare l’istante in cui tali nodi effettuano il campionamento del segnale ricevuto. Per questo motivo si utilizza la tecnica del bit stuffing che consiste nell’inserire un bit di polarità opposta (bit di stuffing o stuff bit) ogni volta che ne vengano rivelati 5 uguali e consecutivi all’interno della stessa trama. La sincronizzazione può avvenire infatti quando si verifica una variazione di livello elettrico sul bus.
I dispositivi che hanno accesso al bus, detti nodi, non sono individuati da uno specifico indirizzo e quindi il protocollo di comunicazione risulta di tipo Message-based anziché Address-based; per questo motivo i messaggi inviati non contengono informazioni sul destinatario ma vengono contraddistinti da un apposito identificatore che (come vedremo in seguito) permette di stabilire la priorità della trasmissione e ne codifica il contenuto; in questo modo i messaggi che transitano sul bus vengono ricevuti da tutti i nodi della rete che, attraverso l’identificatore, possono riconoscere e selezionare quelli utili.
Ogni nodo è composto da tre parti principali [4] (Figura 1.2):
o Il Transceiver che rivela lo stato del bus valutando la differenza di tensione ∆ tra le due linee CAN_H e CAN_L:
∆ < 0.5 V stato recessivo
∆ > 0.9 V stato dominante
ed interfaccia il controllore CAN con il bus.
o Il CAN Controller che trasmette e riceve dati via seriale con il transceiver e comunica col microcontrollore.
o Il Microcontrollore che gestisce le operazioni da svolgere.
Figura 1.2: Struttura base di un nodo CAN.
Lo sviluppo della tecnologia per i circuiti integrati ha permesso di realizzare su un unico chip il CAN Controller ed il microcontrollore riducendo notevolmente l’ingombro ed i costi di ciascun nodo. L’integrazione del transceiver all’interno dello stesso chip, invece, risulta ancora in fase di progetto [4].
La soluzione integrata appare inoltre più vantaggiosa nel ridurre i tempi di comunicazione fra i dispositivi che costituiscono ciascun nodo. Il microcontrollere interagisce infatti con il CAN controller attraverso un insieme di registri chiamati SFR. Nel caso in cui i dispositivi non vengano realizzati sullo stesso chip, il microcontrollore può accedere a tali registri utilizzando un bus indirizzi/dati esterno o un collegamento seriale e ciò rallenta notevolmente le operazioni di lettura/scrittura rispetto al sistema single-chip.
Tutti i controllori CAN hanno una struttura comune rappresentata principalmente da un controllore del protocollo, un filtro hardware, una memoria interna e un’interfaccia verso la CPU come mostrato in Figura 1.3.
Il controllore del protocollo CAN svolge la funzione di gestire i messaggi che transitano sul bus e compie operazioni di sincronizzazione, controllo degli errori, arbitraggio, e serializzazione/deserializzazione dei dati.
Il filtro hardware effettua la selezione dei messaggi che giungono al nodo: impostando il contenuto di alcuni registri del CAN controller è possibile specificare l’identificatore e quindi il tipo del messaggio da ricevere reiettando tutti gli altri.
Figura 1.3: Architettura del CAN controller.
1.4 Struttura dei Frame
Su una rete CAN possono transitare 4 tipi di messaggi o frame come riportato di seguito [5].
o Data Frame è il messaggio con il quale vengono scambiati i dati sulla rete. o Remote Frame permette a un nodo di richiedere la trasmissione di un data
frame con un particolare identificatore.
o Error Frame è inviato da un nodo quando rileva la presenza di un errore sul bus.
o Overload Frame è utilizzato per inserire un ritardo aggiuntivo tra due data
o remote frame successivi.
Per i frame di tipo Data e Remote esistono due specifiche del protocollo CAN che si differenziano per la lunghezza del campo identificatore dei messaggi: CAN 2.0 A (formato standard) con identificatori di 11 bit e CAN 2.0 B (formato esteso) con identificatori di 29 bit (sistemi con specifiche 2.0 B sono per altro compatibili con moduli che fanno uso dell’altro formato).
La struttura di un Data Frame con identificatore standard è mostrata in Figura 1.4 ed è costituita dall’insieme di 6 campi:
o Start Of Frame (SOF) è 1 bit dominante che, a partire dalla condizione di bus libero, individua l’inizio di una trasmissione e permette la sincronizzazione tra i vari nodi.
o Arbitration Field è lungo 12 bit ed è costituito dai due campi IDentificatore (11 bit per il formato standard) e RTR (che vale 0 per un data frame ed 1 per un remote frame).
o Control Field è costituito da 6 bit, tra i quali IDE serve per riconoscere se il formato è standard (bit dominante) o esteso (bit recessivo) ed i 4 bit Data Lenght Code (DLC) specificano il numero di byte che costituiscono il Data Field del messaggio stesso.
o Data Field è il campo che contiene il contenuto informativo del messaggio e la sua lunghezza può essere compresa tra 0 a 8 byte in base a quanto specificato nel campo DLC.
o Cyclic Redundancy Check Field (CRC) è lungo 16 bit, 15 di CRC code ed 1 di delimitatore. CRC contiene una sequenza di bit opportunamente elaborata da chi trasmette in base al contenuto della trama da inviare; anche il nodo che riceve il dato esegue lo stesso calcolo per ottenere il CRC ed in caso di discordanza viene rivelata una condizione di errore. o Acknowledge Field lungo 2 bit: ACK Slot e ACK Delimiter entrambi
recessivi; ACK Slot viene sovrascritto come dominante da ogni nodo che riceve il messaggio in maniera corretta. In questo modo il trasmettitore sa che almeno un dispositivo collegato al bus ha ricevuto correttamente il dato (ma questo non significa che il messaggio è arrivato a destinazione!).
o End OF Frame (EOF) che rappresenta una sequenza di 7 bit recessivi con
la funzione di terminare il frame.
0
SOF
11-bit
Identifier
0 0 0 4-bit 0-8 bytes 15-bit 1 0 1 1 1 1 1 1 1 1 1 1 1
RT R IDE r0 DLC
CRC delimiter
coded by bit stuffing method fixed form Arbitration Field Control Field Data Field CRC Field ACK
Field End of Frame Int. Bus Idle Bus Idle
Figura 1.4: Struttura di un Data Frame (ID standard).
Alla fine del campo EOF è presente un Interframe Space che serve a separare due frame successivi ed è costituito da 3 bit recessivi (Intermission) che determinano l’inizio della condizione di bus idle (rappresentata da una sequenza di bit recessivi arbitrariamente lunga).
Analizzando la struttura di un Data Frame con ID standard è possibile notare come l’effettivo contenuto del messaggio, rappresentato dal campo Data Field lungo al massimo 64 bit, venga quasi raddoppiato per l’aggiunta di 47 bit di “servizio” legati alle caratteristiche del protocollo di trasmissione.
Bisogna inoltre tener presente che il procedimento di bit stuffing può incrementare ulteriormente la lunghezza del frame; poiché tale operazione riguarda soltanto i primi 34 bit di controllo ed il Data Field, il numero massimo di bit aggiunti è dato da:
+ − 4 1 8 34 Li
dove Li∈{0,1,…,8} rappresenta il numero di byte del campo dati. In
bit, mentre quello più lungo (Li = 8 e il massimo numero di bit di stuffing che è
pari a 24) può includerne fino a 47+64+24 = 135.
Per quanto riguarda i Remote Frame, essi hanno la stessa struttura e la stessa composizione dei Data Frame. Le uniche differenze sono rappresentate dal fatto che il bit RTR assume il valore recessivo e dall’assenza del Data Field. Questo messaggio viene inviato da un nodo della rete per richiedere un certo tipo di dati: se la stazione che lo riceve è in possesso di Data Frame con lo stesso ID è “invitata” a trasmetterlo.
1.5 Uso degli Identificatori
Poiché il bus CAN appartiene alla classe dei bus di tipo Message-Based, un messaggio non contiene né l’indirizzo del nodo che lo ha trasmesso, né quello del nodo destinario, ma specifica quale informazione è trasportata attraverso il campo ID dell’Arbitration Field. Perciò, ad ogni messaggio presente sulla rete è assegnato in modo univoco un identificatore) che ha le seguenti funzioni [6]:
o codifica il tipo di informazione contenuta nel campo dati o assegna la priorità di trasmissione del messaggio
o permette di risolvere in modo non distruttivo i conflitti per l’accesso al bus
Per comprendere meglio come avviene lo scambio di informazioni all’interno di un rete CAN, supponiamo che i messaggi periodici provenienti da un sensore di temperatura siano codificati, in formato standard, con un ID pari a xxxxxx10110, dove il pattern 10110 identifica quindi l’informazione “temperatura” mentre x rappresenta un bit non utilizzato nella codifica. Tutti i nodi interessati alla temperatura fornita da tale sensore devono predisporre (attraverso l’apposito filtro hardware) una maschera che riconosca la presenza del pattern 10110 nei 5 bit meno significativi dell’ID del messaggio. Questo procedimento prende il nome di filtraggio e permette ai dispositivi collegati al bus di selezionare soltanto i messaggi che contengono i dati a cui sono interessati.
Analizziamo ora il ruolo degli identificatori nel meccanismo di arbitraggio del bus CAN che è un bus di tipo CSMA/CD (Carrier Sense Multiple Access/Collision Detection). Ciò significa che ciascun nodo della rete deve monitorare il bus attendendo che questo si porti nella condizione idle prima di iniziare la trasmissione di un messaggio (Carrier Sense). Quando il bus è nello stato idle ogni nodo può tentare di accedere al bus (Multiple Access). Nel caso che più nodi inizino la trasmissione di un messaggio contemporaneamente, si può generare una condizione di conflitto che è rivelata dai nodi stessi (Collision Detection).
Infatti se più nodi stanno trasmettendo contemporaneamente ed uno di essi invia un bit “0” (bit dominante), allora tutti gli altri, monitorando il bus, leggeranno “0”; invece, solo se tutte le stazioni trasmettono un “1” (bit recessivo), monitorando il bus, si vedrà “1”.
Il bus CAN si comporta perciò come un’unica porta AND di cui ogni nodo può vedere l’uscita. Tale proprietà viene utilizzata per risolvere in modo non distruttivo le contese per l’accesso al bus. Quando il bus è libero, ogni nodo inizia a trasmettere il proprio messaggio a partire dal bit più significativo dell’identificatore. Se un nodo trasmette un bit recessivo ma, controllando il bus, ne individua uno dominante, allora ha perso la contesa per il controllo della linea e quindi interrompe la trasmissione, si pone in ricezione e attende finché il bus non ritorna libero per provare nuovamente a trasmettere il messaggio. Se invece un nodo individua sulla linea il livello logico che sta trasmettendo (recessivo o dominante), può inviare il bit successivo del campo ID. Poiché il protocollo di comunicazione richiede che gli identificatori siano unici nel sistema, un nodo che riesce a trasmettere l’ultimo bit del campo ID, sta certamente inviando il messaggio con priorità più alta e quindi può continuare nella trasmissione dei campi successivi.
E’ interessante osservare che la contesa per l’accesso al bus viene vinta dal nodo che sta trasmettendo il messaggio con ID più basso che quindi ha priorità maggiore. Inoltre il messaggio che vince la contesa per l’accesso al bus non è alterato dalla fase di arbitraggio e quindi non deve essere ritrasmesso. Questo meccanismo permette di non creare tempi morti nell’utilizzo del bus e garantisce
inoltre che i messaggi a priorità più alta vengano trasmessi senza alcun ritardo legato alla fase di arbitraggio [1]. Si osserva infine che le specifiche del protocollo CAN proibiscono identificatori con i 7 bit più significativi uguali ad 1 e quindi stabiliscono l’esistenza di 2032 tipi di messaggi differenti (nel formato standard) [7].
La Figura 1.5 mostra un esempio di conflitto sul bus: il nodo 3, trasmettendo un messaggio con ID più piccolo, vince la contesa e guadagna il controllo del bus.
Figura 1.5: Esempio di conflitto per l’accesso al bus.
Inoltre è utile notare che su una rete CAN possono circolare insieme sia messaggi in formato standard che in formato esteso. Per questo motivo la trama estesa prevede che il campo identificatore sia diviso in due sezioni rispettivamente di 11 e 18 bit separate da 2 bit aggiuntivi (come mostrato in Figura 1.6):
o SRR sempre recessivo
o IDE dominante se la trama è di tipo standard ma recessivo nel caso di formato esteso
Se si verifica l’accesso simultaneo di due messaggi con formati differenti ma con la stessa priorità (primi 11 bit uguali), la contesa viene risolta sempre a
favore del frame di tipo standard. In caso di Data Frame il bit RTR del formato standard risulta dominante mentre SRR è recessivo. In caso di richiesta di trasmissione remota (RTR recessivo), la priorità è stabilita dal bit IDE ed è minore nel frame con formato esteso (IDE recessivo).
Figura 1.6: Struttura del campo identificatore nei formati 2.0 A e 2.0 B.
1.6 Rilevamento e gestione degli Errori
Una delle caratteristiche più importanti del protocollo CAN è la sua efficienza nella rilevazione e gestione degli errori che lo rende particolarmente adatto in applicazioni critiche nelle quali è richiesta un’alta affidabilità dei dati trasmessi.
Le principali cause per le quali si verifica un errore in fase di trasmissione o di ricezione sono [1]:
o Ogni nodo può avere un diverso istante di campionamento del segnale e quindi a causa di un disturbo può verificarsi che due nodi leggano due livelli logici diversi.
o Due diversi nodi possono avere soglie diverse di riconoscimento dei livelli logici.
o Il segnale lungo la linea si attenua e quindi si può avere una degradazione eccessiva dei livelli elettrci.
Il procedimento con cui vengono gestite le possibili condizioni di errore ed il conseguente isolamento dei guasti prende il nome di Error Detecting e si articola in più fasi.
Ciascun CAN controller è in grado di riconoscere e gestire 5 tipi differenti di errore [5]:
o Bit Error: un nodo in trasmissione controlla sempre il bus per verificarne lo stato e se rivela sulla linea un bit differente da quello che sta trasmettendo e non siamo in fase di competizione per il bus (l’invio dell’Arbitration Field è stato completato con successo) allora si è verificato un errore
o Bit Stuffing Error: è avvenuta una violazione delle regole di Bit Stuffing o CRC Error: ogni nodo in ricezione ricalcola il CRC e lo confronta con
quello ricevuto, se sono diversi viene rivelato un errore
o Format Error (o Frame Error): sono stati violati dei campi di un frame che devono avere sempre lo stesso formato
o ACK Error: in fase di trasmissione il campo ACK Slot è sempre recessivo ma viene sovrascritto con un bit dominante dalle stazioni della rete che ricevono correttamente il messaggio. Se neanche un nodo della rete conferma al trasmettitore la corretta ricezione del dato appena inviato (ACK Slot risulta sempre recessivo) allora si è verificato un errore.
Per garantire la consistenza della rete, gli errori locali devono essere resi noti a tutti i dispositivi e ciò avviene grazie ad una violazione della regola di bit stuffing. Infatti, quando un nodo riconosce una delle condizioni di errore precedenti, invia sul bus un Error Frame composto da 2 campi: Error Flag ed Error Delimiter (8 bit recessivi). L’Error Flag è costituito da una trama di 6 bit della stessa polarità. Tutte le stazioni in ascolto rivelano quindi un Bit Stuffing Error e notificano l’errore inviando anch’essi un Error Frame. Poiché i nodi abilitati a segnalare gli errori individuati sul bus inviano Error Flag costituiti da bit dominanti, il messaggio corrotto in fase di trasmissione viene quindi sovrascritto ed annullato; il CAN controller responsabile dell’errore provvederà inoltre a ritrasmetterlo.
La trama d’errore complessiva risulta quindi dalla sovrapposizione dei diversi Error Flag inviati in quanto i vari nodi della rete si possono accorgere dell’errore in istanti differenti.
Tale sovrapposizione può essere costituita al massimo da 6 bit e quindi un Error Frame assume la forma generale rappresentata in Figura 1.8.
Figura 1.8: Struttura di un Error Frame.
L’Error Flag, costituito da 6 bit della stessa polarità, identifica inoltre il tipo di trama d’errore: 6 bit dominanti corrispondono ad una trama attiva, 6 recessivi ad una passiva.
Un CAN controller possiede ed aggiorna continuamente due contatori di errore: TEC (Trasmit Error Counter) e REC (Receive Error Counter). Tali contatori servono al controllore per distinguere guasti o malfunzionamenti temporanei del nodo da quelli permanenti. Il contenuto di tali contatori viene infatti incrementato di 1 ogni volta che il nodo compie (incremento di TEC) o rivela (incremento di REC) un errore di trasmissione sul bus. Quando il valore di uno dei due contatori supera 127, il nodo diventa di tipo Error Passive e può inviare soltanto Error Flag costituiti da 6 bit recessivi. Ogni volta che un messaggio viene correttamente inviato (o ricevuto) dal nodo, il contenuto di TEC (o di REC) viene invece decrementato di 1. Per questo motivo, in mancanza di errori di trasmissione nella rete, il nodo può ritornare ad essere Error Active e quindi inviare Error Frame con i primi 6 bit dominanti. Se invece il malfunzionamento del nodo perdura nel tempo ed il valore di TEC supera 255, il
dispositivo viene definitivamente scollegato dal bus. Questo meccanismo è stato studiato per evitare che un nodo malfunzionante saturi (o induca gli altri nodi a saturare) il bus con messaggi di errore [1].
Il valore assunto da TEC e REC determina lo stato del nodo come indicato dalla Figura 1.9.
2 Analisi del traffico su rete CAN
Come detto nel capitolo precedente, all’interno di un sistema CAN la priorità dei dati viene stabilita attraverso l’uso degli identificatori; i messaggi con identificatore più piccolo ottengono infatti priorità maggiore e, in caso di conflitto fra i nodi della rete, vengono inviati sul bus per primi. Per questo motivo, i messaggi a priorità minore possono subire dei ritardi in fase di trasmissione; l’entità di tali ritardi dipende dal tempo che il bus risulta occupato dal traffico a priorità più alta. Prima di prendere in considerazione i diversi tipi di messaggi che possono transitare sul bus CAN e fornire un modello del traffico della rete, è utile quindi analizzare i meccanismi con cui viene stabilita la priorità dei dati e l’assegnazione dei vari identificatori (politiche di scheduling); viene inoltre introdotta l’analisi del tempo di risposta dei messaggi (Reponse Time Analysis) che permette di stimare il ritardo con cui un dato viene trasmesso sul bus in presenza di trasmissioni a differente priorità.
2.1 Sistemi in tempo reale
Una rete CAN appartiene alla categoria dei sistemi che operano in tempo reale RTOS (Real Time Operating System) per i quali la condizione di buon funzionamento del sistema non dipende soltanto dalla correttezza dei risultati, ma anche dal tempo al quale tali risultati sono prodotti [7]. L’espressione “in tempo reale” indica che la reazione del sistema agli eventi esterni deve avvenire durante la loro evoluzione e può essere formalizzata introducendo il concetto di deadline che rappresenta l’intervallo di tempo dopo il quale la risposta del sistema a uno stimolo esterno risulta non solo in ritardo, ma a volte inutile o persino dannosa.
Per esempio, nel caso di dati periodici la deadline può rappresentare l’istante di tempo in cui un nuovo campione viene inviato dalla sorgente e, sovrascrivendo il vecchio dato, ne determina la scomparsa. Per i messaggi più urgenti (periodici e non), ritardare la trasmissione può significare impedire al sistema di reagire in modo adeguato alle sollecitazioni esterne con conseguenze a volte disastrose.
I sistemi RTOS sono quindi suddivisi in due categorie:
o Hard-RTOS in cui il mancato rispetto della deadline comporta conseguenze catastrofiche sul sistema stesso
o Soft-RTOS in cui è preferibile rispettare le varie deadline per ottenere una buona qualità del servizio senza che, in caso contrario, il sistema risulti seriamente compromesso
Le reti CAN sono tipicamente Hard RTOS (basti pensare al settore automotive o alle applicazioni mediche). La realizzazione di un interfono nella rete è invece un’applicazione di tipo Soft RT.
Nella terminologia dei sistemi in tempo reale, le azioni svolte da ciascun dispositivo sono chiamate processi o task. In una rete CAN ciascun task consiste nell’invio di un messaggio sul bus da parte di un nodo. Da questo punto in poi task, processo e messaggio verranno utilizzati come sinonimi. Per questo motivo un processo periodico determina una sequenza periodica di messaggi, mentre i task aperiodici occupano il bus in modo casuale.
Nel caso più generale, i messaggi che transitano in una rete CAN possono essere classificati nel seguente modo [8].
o Messaggi periodici.
o Messaggi aperiodici a breve deadline. o Messaggi aperiodici non in tempo reale.
Un tipico esempio di messaggio periodico può essere rappresentato dal segnale trasmesso da un sensore di posizione (o di velocità) montato, per esempio, in un macchinario che effettua il taglio delle pelli in un’industria manifatturiera. Tale dispositivo invia periodicamente ad un controllore i dati che notificano la posizione della lama sul campione di materiale da tagliare. In base alle informazioni inviate dal sensore, il controllore provvederà a modificare la posizione della lama per eseguire correttamente l’operazione.
Tale processo determina quindi un traffico periodico sul bus e poiché la risposta del controllore deve essere la più rapida possibile, i messaggi inviati dal sensore avranno in questo caso breve (o brevissima) deadline e quindi elevato livello di priorità.
Il traffico aperiodico viene invece generato al verificarsi di avvenimenti casuali che possono essere descritti mediante una distribuzione di Poisson. E’ questo il caso, ad esempio, dei messaggi inviati da un sensore di temperatura che segnala il superamento di una soglia prestabilita. L’urgenza del messaggio e la necessità di una reazione immediata da parte del sistema determinano ancora breve deadline ed elevata priorità di trasmissione.
Per semplificare l’analisi dei tempi di risposta dei messaggi trasmessi su una rete CAN, può risultare utile far riferimento al traffico sporadico [9] anziché aperiodico. I messaggi sporadici rappresentano un sottinsieme di quelli aperiodici in quanto la loro trasmissione viene sempre attivata in modo casuale, ma senza che si possano verificare due o più attivazioni contemporaneamente. Per questo motivo è possibile stabilire un tempo minimo fra due eventi successivi che generano messaggi casuali e quindi considerare il traffico sporadico alla stregua di quello periodico con periodo pari al minimo intervallo di tempo che può separare due messaggi casuali consecutivi.
In questo modo si considera lo scenario peggiore di occupazione del bus da parte dei messaggi sporadici. Se da un lato questa assunzione permette di calcolare il tempo massimo di trasmissione di ciascun messaggio e quindi la valutazione del rispetto di ogni deadline in ogni condizione operativa, dall’altro risulta in molti casi reali veramente pessimistica e quindi inadeguata quando si vogliono analizzare sistemi di tipo Soft RT. In quest’ultimo caso, che poi è quello che si verifica quando si considera la trasmissione di segnali vocali su rete CAN, non si può prescindere dalla natura statistica dei messaggi aperiodici o sporadici e quindi è necessario sviluppare un differente approccio per la loro analisi come sarà mostrato nei paragrafi successivi.
Infine i messaggi aperiodici non in tempo reale rappresentano un flusso di dati di servizio non soggetto a vincoli temporali e quindi a basso livello di priorità. Un esempio di questo tipo di messaggi è costituito dai messaggi di stato,
come per esempio il numero di lavorazioni effettuate o lo stato di un macchinario (attivo, stand-by, pieno regime etc.) in un sistema per il controllo di una lavorazione in un’industria manifatturiera. Questi messaggi non hanno caratteristiche real-time e quindi possono essere trasmessi quando il bus non è occupato dai messaggi a più alta priorità e tollerare, perciò, notevoli ritardi.
Come abbiamo già visto, all’interno di un sistema CAN gli identificatori assegnati ai messaggi svolgono una duplice funzione in quanto permettono di codificare l’informazione contenuta nel campo dati attraverso 11 o 29 bit (in base al formato utilizzato) e ne stabiliscono inoltre il livello di priorità. Per questo motivo essi assumono una notevole importanza sia in fase di filtraggio del traffico in arrivo al nodo sia durante le contese per l’accesso al bus. Inoltre, poiché il protocollo assegna priorità maggiore agli identificatori più piccoli, è evidente che i messaggi più urgenti, con deadline minore, debbano ottenere gli dentificatori più bassi del sistema. Nel prossimo paragrafo saranno richiamate alcune strategie con le quali possono essere assegnati gli identificatori in modo tale da rispettare tutte le deadline.
2.2 Politiche di Scheduling
Un insieme di processi è definito schedulabile se esiste almeno un algoritmo (o politica) che permetta la loro esecuzione rispettando tutte le deadline [7]. Una politica di scheduling rappresenta quindi l’insieme delle regole che stabiliscono l’ordine secondo il quale i differenti processi sono eseguiti.
All’interno di una rete CAN tali politiche individuano i meccanismi con cui gli identificatori vengono assegnati ai messaggi in funzione dell’urgenza della loro trasmissione.
Esistono due categorie principali di scheduling: preemptive e non-preemptive. Nel primo caso l’esecuzione di un certo task può essere interrotta per garantire quella dei processi a priorità maggiore; nel secondo invece è necessario completare l’esecuzione di ciascun processo prima di poter utilizzare nuovamente il sistema.
Il protocollo CAN permette uno scheduling non-preemptive in quanto un nodo che vince la fase di arbitraggio e guadagna l’accesso al bus può completare l’invio del proprio messaggio senza essere interrotto da altre trasmissioni anche se più urgenti. In questo caso un qualsiasi messaggio (o processo) in attesa di essere trasmesso si definisce accodato.
La priorità assegnata a un processo può essere costante nel tempo, oppure può essere fatta variare dinamicamente per tenere conto del fatto che, allo scorrere del tempo, si avvicina la scadenza entro cui tale processo deve essere eseguito.
La più comune politica di scheduling a priorità fissa è detta RM (Rate Monotonic) e viene generalmente utilizzata per schedulare un traffico costituito da messaggi periodici e sporadici.
La RM assume che la deadline sia uguale al periodo del task e quindi assegna priorità maggiore ai messaggi con periodo più breve. Molto spesso però può accadere che la deadline di un processo sia minore del suo periodo. In questo caso la migliore politica di scheduling risulta essere la DM (Deadline Monotonic) che assegna priorità più alta ai messaggi (periodici o sporadici) con deadline minore. Per questo motivo i dati in tempo reale ricevono gli identificatori più bassi del sistema mentre i rimanenti livelli di priorità vengono assegnati al traffico non in tempo reale.
Tra le politiche di scheduling in cui l’identificatore di un messaggio è aggiornato in modo dinamico col passare del tempo, una tecnica molto diffusa è la ED (Earliest deadline).
In questo caso, ciascun identificatore viene suddiviso in tre parti [8] come mostrato in Figura 2.1:
priority deadline uniqueless
Il campo deadline rappresenta la scadenza del messaggio e viene decrementato all’inizio di ogni fase di arbitraggio per aumentarne la priorità; il campo uniqueless diversifica gli identificatori con lo stesso campo deadline ed identifica inoltre il tipo di dato in fase di filtraggio; il bit priority vale 0 per i messaggi in tempo reale, 1 altrimenti.
Esistono anche politiche di scheduling miste come per esempio l’MTS (Mixed Traffic Scheduler). In questo caso i dati in tempo reale ad elevata priorità seguono l’ED ed hanno il campo priority pari a 0. I messaggi in tempo reale a priorità più bassa sono organizzati secondo la politica DM con i primi due bit dell’identificatore pari ad 10 (priorità inferiore rispetto al gruppo precedente). I dati non in tempo reale hanno invece priorità fissa ed i primi due bit dell’ID pari a 11 [8].
Un esempio di scheduling MTS è mostrato in Figura 2.2.
0 deadline Uniqueless
1 0 DM
1 1 priorità fissa
Figura 2.2: Struttura degli identificatori nell’MTS.
Ogni volta che un messaggio viene trasferito dal microprocessore al CAN controller per essere trasmesso (accodamento), il suo identificatore risulta definito e invariabile. Perciò, una politica di sheduling a priorità fissa (con identificatore costante nel tempo) appare la soluzione più naturale da adottare. In questo modo ciascun messaggio ha un proprio ID che ne codifica il contenuto e che gli assegna statisticamente la sua priorità [6].
2.3 Analisi del Tempo di Risposta
Come già detto in precedenza, affinché la rete funzioni correttamente è necessario che ogni messaggio accodato sul bus raggiunga il ricevitore prima della sua deadline. Consideriamo la situazione nella quale un nodo della rete vuole inviare un messaggio sul bus che però risulta occupato da una trasmissione in corso e nella quale altri messaggi (accodati) attendono di essere trasmessi. Poiché il protocollo CAN consente uno scheduling non-preemptive, la trasmissione corrente non può essere interrotta (anche se a più bassa priorità) e quindi la contesa per l’accesso alla comunicazione è rimandata di un periodo di tempo compreso fra 55*Tbit (trasmissione del messaggio più breve) e 135*Tbit
(durata del messaggio più lungo).
Si definisce tempo di risposta Ri del messaggio i la differenza fra l’istante
in cui l’informazione da trasmettere è disponibile al nodo di origine e quello in cui tale informazione viene ricevuta dalla stazione di destinazione [6] [10]. Tale grandezza viene indicata con Ri epuò essere espressa come somma di 3 termini.
i i i
i J q C
R = + +
Ji rappresenta il jitter di accodamento, ossia l’intervallo di tempo tra il momento
in cui il dato da trasmettere è disponibile e l’istante al quale il messaggio relativo è reso disponibile al CAN controller per la sua trasmissione (accoramento del messaggio sul bus) d; qi indica l’effettiva durata dell’accodamento ossia il tempo
di attesa prima che la trasmissione abbia effettivamente luogo; Ci è il tempo di
trasmissione del messaggio.
Per capire il significato di Ji immaginiamo che il messaggio da trasmettere
sia periodico con periodo pari a Ti. Quando la sorgente (per esempio un sensore)
invia un dato al microprocessore del nodo CAN, quest’ultimo impiegherà un certo tempo, che può variare di volta in volta, per riceverlo, elaborarlo e trasmettere il relativo messaggio al CAN controller. Ji rappresenta proprio questo ritardo
rispetto all’evento esterno che ha generato il dato, e può essere interpretato come una variazione di periodicità del messaggio stesso.
Un esempio di jitter (o finestra) di accodamento è indicato in Figura 2.3.
Figura 2.3: Esempio di jitter di accodamento.
Nel caso peggiore, Ji assume valore massimo e viene indicato con Ji max.
Il ritardo di accodamento qi è composto da due termini: il tempo più lungo
durante il quale un messaggio a più bassa priorità può occupare il bus (tempo di blocco) e il tempo più lungo in cui i messaggi a priorità maggiore occupano il bus prima che il messaggio i sia trasmesso (interferenza). Il valore di qi può essere
espresso dalla seguente formula:
h i hp h h bit h i i i C T T J q B q ⋅ + + + =
∑
∈ () dove:o Tbit rappresenta il tempo di trasmissione di un singolo bit sul bus (e.g.
Tbit=1 µs se il bus lavora a 1 Mbps)
o Jh indica il jitter di accodamento del messaggio h e nel caso peggiore vale
Jh max
o Th indica il periodo del messaggio h
o Ch rappresenta il tempo più lungo impiegato per inviare fisicamente il
controllo e di quelli extra dovuti al meccanismo di bit stuffing. La seguente formula permette di calcolare Ch (Lh rappresenta il numero di
byte del campo dati del messaggio):
bit h h h L T L C + + + − = 47 8 4 1 34 8
o hp(i) è l’insieme dei messaggi a più alta priorità rispetto ad i
o Bi = max k∈lp(i) Ck rappresenta il tempo di blocco del bus nel caso peggiore;
lp(i) è l’insieme dei messaggi a priorità minore di i;
Bi vale 135 µs se il bus lavora a 1 Mbps ma può arrivare fino a 1 ms per un
bit rate di 125 kbps.
E’ importante notare che l’equazione che fornisce il ritardo di accodamento non può essere risolta in forma chiusa. Si utilizza quindi un procedimento iterativo basato sulla seguente relazione:
h i hp h h bit h n i i n i C T T J q B q ⋅ + + + =
∑
∈ − ) ( ) 1 ( ) (Iniziando dal valore qi(0)= 0, il procedimento iterativo continua finché
qi(n+1) = qi(n).
L’analisi del tempo di risposta o RTA (Response Time Analysis) assume una notevole importanza nella valutazione della schedulabilità dei messaggi. Infatti conoscendo il valore massimo di Ri (che rappresenta una stima della
situazione peggiore) è possibile stabilire a priori se ciascun dato in tempo reale riesce a giungere a destinazione prima della sua deadline oppure no.
Se Di indica allora la deadline del messaggio i, condizione necessaria e
Ri<= Di
Se tale disequazione è valida per ogni i (cioè per ogni messaggio) allora il sistema si definisce schedulabile.
Esiste un altro limite al valore massimo di Ri. Poiché un messaggio
accodato deve essere trasmesso prima del successivo accodamento (per evitare che il dato venga sovrascritto), deve valere:
Ri<= Ti - Ji
dove Ti e Ji rappresentano il periodo ed il jitter del messagio i.
Da tale formula si può dedurre che il valore del jitter deve necessariamente essere minore del periodo del messaggio per garantirne la schedulabilità.
Si osserva infine che per un sistema in tempo reale in cui sia stata scelta la politica di scheduling DM (che sappiamo essere la migliore forma di ordinamento delle priorità), il messaggio con il più piccolo valore di Di ha la priorità più alta ed
ottiene quindi l’identificatore più basso.
2.4 RTA statistica
L’analisi condotta fino ad ora permette di valutare a priori se un dato messaggio risulta schedulabile e cioè se la sua deadline viene rispettata in ogni condizione di funzionamento. Infatti, una volta stabilita la priorità dei messaggi in accordo alla politica di scheduling adottata, utilizzando le formule viste in precedenza è possibile calcolare il valore di Ri nel caso peggiore. Confrontando
quindi il risultato ottenuto con la deadline del messaggio corrispondente è possibile stabilire se quest’ultimo è schedulabile o meno.
Questo tipo di analisi, detta analisi deterministica, va senza dubbio applicato nel caso di sistemi in tempo reale “critici”, in cui cioè il mancato rispetto della deadline, anche una sola volta, può determinare gravi conseguenze.
Da un altro punto di vista, tale approccio risulta decisamente pessimistico in quanto permette di valutare Ri nel caso peggiore (situazione limite) ed assume
che la trasmissione del messaggio non possa essere effettuata mai se tale valore eccede la rispettiva deadline. Va osservato inoltre che in molti sistemi la probabilità che si manifesti tale condizione limite è decisamente bassa.
Quindi, nei casi in cui è possibile accettare una certa probabilità p che la deadline di un messaggio non venga rispettata si può applicare un’analisi di tipo statistico decisamente meno pessimistica. Infatti alcuni sistemi che risultano non schedulabili secondo l’approccio deterministico, lo diventano per quello statistico. In particolare, nel nuovo tipo di analisi [10] viene rimossa l’assunzione che il numero dei bit di stuffing sia quello massimo possibile e ne viene valutata la distribuzione statistica.
Anche il tempo di risposta dei messaggi viene caratterizzato da una distribuzione statistica e quindi la condizione di schedulabilità non è più del tipo 0/1 ma viene espressa in termini di probabilistici.
Applicando i risultati dell’analisi probabilistica ad un modello di traffico proposto in un benchmark della SAE (Society of Automotive Engineers) è possibile valutare l’efficienza di tale metodo rispetto all’approccio tradizionale: scegliendo una probabilità di violazione della deadline p pari a 10^(-24) si ottiene una stima di Ri decisamente inferiore rispetto a quella ricavata nell’analisi del caso
peggiore e ben più vicina ai valori ottenuti da una simulazione del traffico.
2.5 Implementazione di un Canale Vocale su rete CAN
Il traffico presente in una rete CAN risulta nella maggior parte dei casi costituito da messaggi periodici o aperiodici in tempo reale che trasportano dati di controllo del sistema. Per tale motivo la priorità di trasmissione di questi dati risulta elevata e la necessità di garantire l’invio dei messaggi prima della loro deadline rende il sistema di tipo Hard-RT. L’analisi della shedulabilità deve essere quindi effettuata utilizzando l’approccio deterministico per evitare che il mancato rispetto di una deadline anche una sola volta possa compromettere in modo irrimediabile il funzionamento dell’intero sistema di controllo.
Per quanto riguarda la trasmissione dei messaggi vocali il sistema risulta invece di tipo Soft-RT dato che l’eventuale perdita di campioni audio può
determinare un peggioramento della qualità della voce ricostruita in ricezione senza però creare alcun danno ad altri dispositivi. I messaggi vocali vengono quindi considerati “a bassa priorità” e la politica di scheduling adottata stabilisce per essi gli identificatori più alti. Inoltre, per valutare la schedulabilità di questo tipo di messaggi è possibile utilizzare l’analisi statistica e tollerare che una certa quantità di campioni non rispetti la propria deadline. Tale fenomeno determina un effetto di “intermittenza” nella voce riprodotta ma, se il ritardo (o la perdita) dei pacchetti vocali non risulta eccessivo, non pregiudica l’intelligibilità del segnale.
Appare evidente che, affinché l’implementazione di un canale audio su una rete CAN già esistente sia possibile, la trasmissione dei messaggi vocali non deve degradare le prestazioni in tempo reale del sistema di controllo. Nel caso in cui i messaggi di controllo siano considerati Hard RT e quelli vocali Soft RT e si applichino le politiche di scheduling relative, la condizione sopra esposta risulta verificata. Infatti, se si assegna la priorità più bassa possibile ai messaggi vocali, allora i tempi di risposta, nel caso peggiore, dei messaggi a priorità più alta non risultano modificati dalla trasmissione dei messaggi vocale. Quindi, se i messaggi di controllo erano schedulabili nel senso deterministico prima dell’introduzione di quelli vocali, lo saranno anche dopo.
Si osserva che i messaggi vocali, essendo a priorità più bassa, possono essere inviati solo quando il bus non è occupato dal traffico di dati a più alta priorità e quindi la loro trasmissione può essere casualmente ritardata nel tempo.
Per poter analizzare la qualità della comunicazione vocale è quindi necessario costruire un modello di occupazione del bus da parte dei messaggi di controllo.
2.6 Modello del traffico presente su una rete CAN
L’insieme dei messaggi di controllo inviati dai vari nodi di una rete CAN possono essere suddivisi in due categorie principali:
o Messaggi periodici e deterministici ad alta priorità o Messaggi aperiodici e casuali a priorità massima
La prima classe di messaggi rappresenta le informazioni inviate regolarmente dai sensori collegati alla rete per notificare ai dispositivi di controllo le condizioni del sistema e i comandi per gli attuatori prodotti dai controllori. I messaggi aperodici costituiscono invece il traffico legato al verificarsi di avvenimenti casuali e generalmente critici come ad esempio l’invio di un segnale di allerta..
Entrambi i tipi di messaggi rappresentano il traffico prioritario della rete ma, data la particolare urgenza di trasmettere i segnali aperiodici e la necessità che il sistema risponda il più velocemente possibile agli eventi che li generano, la politica di scheduling adottata assegna a tali messaggi identificatori più piccoli rispetto a quelli periodici.
Analizziamo ora in dettaglio il modello relativo ai due diversi tipi di traffico.
2.6.1 Messaggi periodici ad alta priorità
I dispositivi che generano questo tipo di traffico suddividono i dati da trasmettere in uno o più messaggi di lunghezza variabile inviati con scadenza fissa in modo continuo e deterministico. Ciascun dispositivo genera il proprio stream di dati e accede al bus indipendentemente dagli altri e ciò rende possibile la contesa per la trasmissione fra due o più nodi. In questo caso la politica di scheduling e le specifiche del protocollo CAN stabiliscono le modalità di risoluzione del conflitto: viene inviato per primo il messaggio con identificatore minore e di seguito tutti gli altri rispettando l’ordinamento delle priorità.
Data la periodicità dei singoli stream, la distribuzione di traffico complessiva, risultante dalla sovrapposizione di ciascun messaggio, risulta ancora periodica come mostrato in Figura 2.4:
T3
T1
T2
Figura 2.4: Esempio di stream periodici e loro risultante.
I primi due grafici rappresentano stream periodici con periodo T1 e T2 e
tali che il primo ha priorità maggiore del secondo; il terzo mostra la distribuzione di traffico risultante con periodo T3.
Tale distribuzione di traffico risulta del tutto equivalente, almeno dal punto di vista dell’occupazione di banda, a un treno (burst) di messaggi di lunghezza opportuna che si ripete con periodo pari a T3 e, come mostrato in
B.P. B.L.
T3
Figura 2.5: Modello di traffico equivalente ai due messaggi periodici.
L’insieme dei messaggi periodici può essere quindi modellato attraverso un burst di messaggi i cui parametri sono:
o B.P. (Burst Period) che rappresenta il periodo dello stream equivalente alla distribuzione di traffico data.
o B.L. (Burst Length) che indica la lunghezza del burst di messaggi all’interno del periodo di ripetizione.
Inoltre l’occupazione percentuale del bus dovuta all’intero traffico periodico, indicata con W.L.periodico (Work Load), può essere ricavata dalla
% 100 * . . . . . . = P B L B L W periodico
2.6.2 Messaggi aperiodici e casuali a priorità massima
A differenza dei messaggi periodici e deterministici, il modello del traffico aperiodico può essere ricavato soltanto attraverso un’analisi statistica.
I nodi che inviano questo tipo di messaggi non accedono al bus con scadenza fissa e prestabilita ma si attivano in trasmissione in corrispondenza di un evento casuale che accade all’interno del sistema. E’ possibile quindi utilizzare una distribuzione statistica per caratterizzare gli istanti di tempo in cui si verifica l’accodamento di ciascun messaggio sul bus.
L’ipotesi fondamentale da cui partire è che l’evento che genera l’attivazione di un singolo messaggio sia del tutto casuale e le sue ricorrenze avvengano indipendentemente le une dalle altre; a questo punto la probabilità che in un periodo di tempo t si verifichino k ricorrenze dello stesso evento (e quindi k accodamenti dello stesso messaggio sul bus) può essere espressa da [11]:
! ) ( } { k t e k K P k t λ λ − = =
dove la variabile aleatoria K, che rappresenta il numero di ricorrenze indipendenti dello stesso evento, prende il nome di v.a. di Poisson e λ indica il parametro della distribuzione. E’ possibile dimostrare [11] che, se la v.a. X rappresenta l’intervallo di tempo fra due punti di Poisson (ed assume quindi i valori x = tn – tn-1) allora la
sua distribuzione di probabilità risulta:
F(x) = 1 - e -λx
X prende il nome di v.a. esponenziale e 1/λ ne rappresenta sia il valor medio che la deviazione standard cioè: E[X] = σ(X) = 1/λ.
La densità di probabilità di X risulta quindi:
f(x) = λe -λx
Inoltre, date n v.a. indipendenti e di Poisson con parametri λ1, λ2,…, λn, la
loro somma rappresenta ancora una v.a. di Poisson con λtot = λ1 + λ2 +…+ λn [12]
e quindi la distribuzione dei tempi di attesa di un insieme di eventi aleatori risulta di tipo esponenziale con valor medio E[Xtot] = 1/λtot.
Poiché gli eventi che attivano la trasmissione dei messaggi aperiodici sono indipendenti fra di loro e ciascuno di essi corrisponde ad una v.a. di Poisson, l’insieme del traffico casuale del sistema viene modellato attraverso una sola v.a. di Poisson, con parametro λtot, data dalla somma delle singole v.a..
Il modello del traffico casuale è quindi rappresentato da un unico messaggio attivato in modo non deterministico secondo una distribuzione di Poisson e sintetizza l’insieme delle trasmissioni casuali che avvengono nel sistema.
Tale modello risulta caratterizzato da due parametri:
o 1/λtot che rappresenta il valor medio (e la deviazione standard) degli
intervalli di tempo che intercorrono fra due attivazioni successive. o Lmes che indica la durata della trasmissione del messaggio aperiodico.
normalizzati rispetto a λtot .
Poiché la trasmissione di tale messaggio non è deterministica, è possibile esprimere l’occupazione di banda complessiva, dovuta al traffico casuale, mediante il suo valore medio:
W.L.casuale = (Lmes*λtot*100)%
Infine per rispettare l’ordinamento delle priorità all’interno dei dati di controllo, il messaggio aleatorio che rappresenta l’insieme delle trasmissioni casuali ottiene un identificatore più piccolo rispetto al modello periodico e deterministico.
2.7 Traffico introdotto dall’interfono
Per effettuare alcune valutazioni teoriche sull’occupazione del bus da parte di tutti i nodi (controllo e vocali) della rete è necessario conoscere anche il modello di traffico introdotto dai nodi vocali. In questo modo è possibile analizzare l’interazione fra i messaggi di controllo e quelli audio e prevedere (in prima approssimazione) la qualità della comunicazione vocale.
La trasmissione dei messaggi vocali dipende tuttavia dalle caratteristiche dell’interfono e quindi il modello di traffico risultante non può prescindere da come sono stati implementati i nodi vocali del sistema. Nel nostro caso, l’interfono è stato realizzato utilizzando le stesse risorse di una rete CAN di controllo.
Ciascun nodo vocale è costituito da una scheda interfono che effettua le operazioni di conversione del segnale audio in pacchetti di bit e da un nodo CAN che li invia sul bus secondo le specifiche imposte dal protocollo di trasmissione. Tale struttura (che sarà analizzata un po’ più dettagliatamente nel prossimo capitolo) permette di trasmettere i segnali vocali attraverso un messaggio periodico con periodo T pari a 2 ms e lunghezza variabile da 112*Tbit (col minor
numero di stuff bit) fino a 131*Tbit (col numero massimo di stuff bit).
L’interfono presente in laboratorio è realizzato da due nodi vocali di tipo full duplex e quindi il traffico audio sul bus risulta costituito da due stream periodici di uguali caratteristiche come mostrato in Figura 2.6.
T
T T
L’occupazione di banda complessiva dovuta ai segnali vocali può essere calcolata con la seguente formula:
% 100 * 2 * 5 . 114 * 2 . . = ms T L W audio bit
dove il fattore 2 tiene conto del fatto che entrambi i nodi audio trasmettono sul bus un messaggio ogni 2 ms e 114.5 rappresenta il numero medio [13] di bit per messaggio in seguito al procedimento di bit stuffing.
I dati vocali rappresentano inoltre il traffico a priorità più bassa del sistema ed hanno, di conseguenza, gli identificatori più alti.
Prima di entrare nel merito degli esperimenti effettuati per valutare la qualità dei segnali audio trasmessi su rete CAN è possibile fare alcune considerazioni teoriche.
I dati di controllo che occupano il bus costituiscono il traffico prioritario del sistema ed hanno la precedenza rispetto ai messaggi vocali provenienti dai nodi dell’interfono. Se il carico di lavoro complessivo della rete indicato con W.L.tot e pari a W.L.periodico+W.L.casuale +W.L.audio risulta notevolmente inferiore al
100%, non si verifica la perdita di nessun dato ed il segnale vocale riesce a viaggiare indisturbato nel sistema.
All’aumentare di W.L.tot il traffico sul bus tende a “congestionare”
causando l’inevitabile perdita di campioni. Poiché i messaggi vocali hanno priorità più bassa nel sistema, tale fenomeno riguarda principalmente il traffico audio.
La perdita di campioni si può inoltre verificare per valori di W.L.tot un po’
inferiori al 100% in quanto il traffico casuale può determinare un’occupazione di banda istantanea superiore al valore di W.L.casuale.
Infatti la distribuzione dei tempi di trasmissione dei messaggi casuali è di tipo esponenziale e quindi, anche se W.L.casuale risulta piccolo, si può verificare
Per questo motivo l’occupazione del bus da parte dei dati di controllo può eccedere la deadline del traffico vocale anche se il carico di lavoro medio del bus risulta inferiore al 100%.
Inoltre è ragionevole supporre che la perdita di campioni audio determini un effetto di “intermittenza” nella voce ricostruita dai nodi dell’interfono ma che, entro certi limiti, tale fenomeno non pregiudichi l’intelligibilità del segnale
3 Analisi del set-up sperimentale
3.1 Panoramica sul set-up sperimentale
Gli esperimenti effettuati per analizzare la qualità del segnale vocale trasmesso su rete CAN in presenza del traffico di controllo (a priorità più alta) della rete, sono stati compiuti realizzando, nel laboratorio di Sistemi Elettronici dell’Università di Pisa, il sistema mostrato in Figura 3.1:
NODO 2 Scheda Interfono NODO 5 Generatore di traffico casuale NODO 3 Analizzatore di traffico NODO 4 Generatore di traffico periodico Scheda Interfono NODO 1 BUS CAN
I nodi 1 e 2 costituiscono l’interfono realizzato sul bus CAN e trasmettono il traffico costituito dai messaggi vocali. Ciascuno di essi è collegato ad una scheda interfono che esegue le operazioni di conversione e codifica/decodifica del segnale audio.
I nodi 4 e 5 costituiscono i due generatori di traffico e simulano l’invio dei dati di controllo (a più alta priorità) di un sistema reale . Il nodo 4 invia sul bus un messaggio periodico di lunghezza variabile che rappresenta l’insieme delle trasmissioni periodoche dei vari dispositivi collegati al bus CAN. Il generatore al nodo 5 invia sul bus il traffico casuale che costituisce l’insieme dei messaggi attivati in modo non deterministico all’interno di un sistema CAN. Ciascuno dei due nodi realizza quindi uno dei modelli di traffico analizzati nel capitolo precedente.
Il nodo 3 rappresenta lo strumento di analisi con cui vengono valutate le caratteristiche dei messaggi che transitano sul bus. Attraverso l’analizzatore di traffico è possibile ad esempio ricavare la struttura dei singoli messaggi trasmessi ed avere informazioni riguardanti i vari campi (ID, DLC, Data Field, etc) oppure selezionare, in base all’identificatore, il tipo di messaggi da ricevere e valutarne gli istanti di arrivo al nodo. In questo modo è possibile misurare i parametri del traffico reale (ad esempio T dei messaggi periodici o λ di quelli casuali) e confrontarli con le specifiche imposte dal modello teorico.
Tutti i nodi del sistema utilizzano il T89C51CC01 della Atmel che costituisce un esempio di microcontrollore (µC) a 8 bit dedicato ad applicazioni su rete CAN. Tale dispositivo fornisce numerose periferiche di diverso tipo integrate in un unico cip e la sua struttura interna viene mostrata in Figura 3.2 attraverso uno schema funzionale a blocchi.
Senza scendere nel dettaglio [14] è possibile analizzare le caratteristiche di alcuni di questi dispositivi ed i relativi meccanismi di funzionamento a cui faremo riferimento nella trattazione successiva.
Figura 3.2: Struttura interna del T89C51CC01.
o SFR. L’uso di alcuni registri chiamati SFR (Special Function Register) permette di gestire la quasi totalità delle periferiche del microcontrollore. Nel caso del T89C51CC01, 34 di essi vengono utilizzati per gestire il CAN controller integrato. Ogni SFR risiede nella memoria dati interna al sistema ed è accessibile in tempi molto brevi; per questo motivo la struttura single-cip risulta particolarmente efficiente nella gestione della comunicazione fra la CPU e le varie periferiche.
o Message object. Un message object o “canale” è un’area di RAM che viene gestita dal CAN controller per memorizzare le informazioni relative ai messaggi che il micro deve inviare o ha ricevuto. Ogni canale occupa 20 byte: identificatore e maschera (4+4), dati (8), timestamp (2), registro di configurazione (1), registro di stato (1). Nel T89C51CC01 sono presenti 15 canali differenti che possono essere gestiti attraverso un sistema di paginazione per mezzo di alcuni SFR. Ogni message object può essere configurato indipendentemente dagli altri in modalità di trasmissione, ricezione o disabilitata; è inoltre prevista la modalità di buffer di ricezione. o UART. Il T89C51CC01 dispone di una porta di comunicazione seriale di tipo full duplex in cui ricezione e trasmissione possono avvenire
