Implementazione di un modello simulativo per uno scheduler PROFINET-like in IEEE AVB

Transcript

1 Implementazione di un modello simulativo per uno scheduler PROFINET-like in IEEE AVB Università degli Studi di Catania Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica A. A. 2012/2013 Corso di Real Time Prof.ssa L. Lo Bello Responsabile progetto: Giuliana Alderisi Studente: Sottile Pierluigi A

2 Sommario 1. AVB Profinet... 8 Profinet IRT (Isochronous Real-Time) Obiettivi Implementazione Modifiche implementative TrafficManager Scheduler AvbQueue Simulazione Automotion industrial comunication Porting

3 1. AVB Audio Video Bridging si riferisce a uno standard tecnico sviluppato dall'ieee e nel dettaglio dal gruppo di lavoro IEEE Bridging and Network Management. Vari sottogruppi in seno all'ieee hanno lavorato per mettere a punto una serie di protocolli che consentissero il trasferimento o streaming a bassa latenza su reti IEEE 802, con cablaggio cat5 piuttosto che su fibra ottica, di programmi multicanale audio e video con garanzia di consegna sincronizzata. Il fine evidente di una simile iniziativa è la completa interoperabilità di tutta una serie di apparati aderenti agli standard AVB. AVnu Alliance, così si chiama il consorzio di aziende che lavora a tale progetto, si prefigge di promuovere applicazioni per dispositivi audio e video nelle aree automotive, consumer e professionale. I problemi riguardanti il trasferimento ethernet con cui dovevano fronteggiarsi riguardavano la sincronizzazione tra segnali audio-video e audio, e la gestione della latenza. In pratica, lo scopo della nuova serie di protocolli di trasferimento propri del sistema AVB è quello di far funzionare la rete alla stregua di un collegamento fisico in rame, ovviamente accettando un ritardo ragionevolmente contenuto, per consentire la connessione logica tra apparati con interfaccia digitale distanti tra loro. Avb si compone di vari standard, ognuno dei quali si occupa di una particolare classe di problematiche, noi abbiamo analizzato 4 di queste e in particolare: IEEE 802.1AS: Timing and Synchronization for Time-Sensitive Applications (gptp), che si occupa della sincronizzazione dei clock per ridurre i tempi di jitter; IEEE 802.1Qat: Stream Reservation Protocol (SRP), un protocollo di prenotazione delle risorse di rete per ogni singolo nodo; IEEE 802.1Qav: Forwarding and Queuing Enhancements for Time- Sensitive Streams (FQTSS), gestione delle code in modo che vengano rispettate le specifiche dell 802.1Qat; 3

4 IEEE 802.1BA: Audio Video Bridging Systems. IEEE 802.1Qat e 802.1Qav tratta di emendamenti al documento base di IEEE 802.1Q, che specifica l'operazione di "Virtual Bridged Local Area Networks", attualmente utilizzati dai dispositivi di rete tipicamente chiamati Switch Ethernet. Per fare uso di reti IT lo standard ha bisogno di soddisfare alcuni requisiti fondamentali: Deve essere possibile sincronizzare più flussi in modo che possano essere visualizzati correttamente nel tempo l uno rispetto all'altro. La latenza di trasmissione nel peggiore dei casi, e il ritardo di baffering deve essere basso e deterministico Infine, le applicazioni devono essere in grado di ottenere e prenotare le risorse di rete necessarie per mezzo di un controllo di ammissione. Quasi tutte le attuali apparecchiature di rete si basano su requisiti IT: spostare i dati attraverso la rete il più rapidamente possibile con il minimo costo e la minima gestione. Ci sono quattro principali differenze tra l'architettura Audio Video Bridging e le architetture esistenti 802: 1. Sincronizzazione precisa; 2. Traffic shaping per i flussi multimediali; 3. Ammissione controlli; 4. Identificazione dei dispositivi non partecipanti Questi sono implementati usando estensioni agli standard minimi MAC e BRIDGE. In questo modo i dispositivi AVB e non AVB comunicano tramite standard di frame 802. Ma solo i dispositivi AVB sono in grado di prenotare le risorse di rete utilizzando il controllo di ammissione e di traffic shaping e per inviare e ricevere frame temporali. 4

5 Dispositivi AVB scambieranno periodicamente delle informazioni di temporizzazione che consentiranno a entrambe le estremità del collegamento di sincronizzare il proprio orologio di riferimento in modo molto preciso. Questa sincronizzazione precisa ha due scopi: consentire la sincronizzazione di flussi multipli; fornire una base comune di tempo Il protocollo utilizzato per mantenere la sincronizzazione della temporizzazione è specificato in IEEE 802.1AS. Un dominio di temporizzazione di rete 802.1AS si forma quando tutti i dispositivi soddisfano i requisiti prescritti della norma 802.1AS e comunicano tra loro utilizzando il protocollo IEEE 802.1AS. All'interno del dominio temporizzazione c'è un unico dispositivo chiamato grandmaster che fornisce un segnale di temporizzazione. Tutti gli altri dispositivi sincronizzano i loro orologi con il master. Il master può essere selezionato automaticamente o assegnato dalla direzione, dopo che i dispositivi si scambiano telegrammi di sincronizzazione di clock. Al fine di fornire servizi professionali di AV, l'architettura AVB implementa traffic shaping utilizzando risorse esistenti d inoltro 802.1Q e meccanismi di priorità, gestendo in modo autonomo i tag di priorità, inoltro e infine il comportamento del frame per endpoint e bridge. Traffic shaping è il processo che permette di appianare il traffico per un flusso in modo che i pacchetti che lo compongono siano distribuiti uniformemente nel tempo. Se traffic shaping non è applicato alla fonte e nei bridge, i pacchetti tendono a "grappolo" in picchi di traffico che può sopraffare i buffer nei bridge successivi, switch e dispositivi di altre infrastrutture. I flussi AVB sono fatti da frame 802 con etichettatura di priorità, con normali restrizioni su formato e lunghezza. La codifica predefinita 802.1Q per un segmento di mercato particolare è stato scelto al fine di evitare potenziali conflitti con gli impieghi attuali delle variabili prioritarie 802.1Q all'interno di tale segmento di mercato. 5

6 Dispositivi endpoint sono tenuti a trasmettere in modo molto uniforme frame per un particolare flusso in base alla classe di traffico AVB e la specifica qualità di servizio (QoS) dei parametri. Le norme specifiche per la modellazione del traffico sono descritte nella specifica IEEE 802.1Qav, e sono una forma semplice di ciò che è noto come "leaky bucket" credit-based shaping. Il meccanismo di regolazione del traffico utilizzato da fonti streaming è impiegato anche da bridge AVB. I frame AVB devono essere inoltrati con una priorità maggiore rispetto al traffico Best Effort e saranno sottoposti a norme di traffic shaping. Una singola porta di un bridge viene vista come il flusso di una stazione trasmittente, quindi le norme di regolamentazione del traffico valgono anche per essa. La dimensione del buffer ha la funzione di limitare il ritardo e eliminare la congestione, permettendo stream AV anche se non sono ammesse congestioni del traffico. l meccanismo precedente può fornire dati affidabili con una latenza deterministica bassa e basso jitter, ma lo farà solo se le risorse di rete sono 6

7 disponibili lungo tutto il percorso dal Talker al Listener.Il termine Talker è usato per indicare una fonte di flusso e il termine Listener denota chi deve ricevere iel flusso. In questa architettura, è di entrambi la responsabilità di garantire il percorso, la disponibilità e la prenotazione delle risorse. Questo meccanismo è specificato dallo standard 802.1Qat " Stream Reservation Protocol " (SRP); il protocollo registra un flusso e si riserva le risorse necessarie attraverso l'intero percorso. La sequenza di azione può essere semplificata attraverso il protocollo AVB: talker invia un messaggio Talker SRP Adversing dove dichiara le informazioni di flusso come ID Stream (indirizzo MAC sorgente e Talker UID), requisiti di QoS, come classe e velocità di trasmissione dati, le informazioni accumulate e nel peggiore dei casi la latenza. La latenza nel peggiore dei casi viene ricalcolato dai Bridge. Il Talker advertaise vengono inviati per far conoscere le esigenze che il Talker ha per poter trasmettere, il bridge analizzerà le proprie risorse, e se non può soddisfare tali richieste manda un segnale di "Talker Failed" al Listener e al Talker con un codice identificativo dell errore e l identificativo del Bridge. Nel momento in cui le richieste del Talker possono essere soddisfatte, il Talker Advertice verrà inoltrato al Listener, il quale saprà se la risorsa è disponibile e la latenza del percorso,se deciderà di accetare lo stream un segnale "Listener Ready" sarà inoltrato verso il Talker. I Bridge intermedi utilizzeranno il messaggio per bloccare le risorse necessarie al traffico. I Listener invieranno anche un messaggio MVRP per dichiarare l'appartenenza alla Talker VLAN. Dopo che il talker riceverà il messaggio di pronto potrà iniziare a trasmettere il flusso dati. Il Talker può abbattere in modo esplicito la trasmissione propagando un nuovo messaggio di Talker Advertice", e il Listener può disconnettersitramite un nuovo "Listener Ready" message. La de-registrazione del messaggio viene propaga attraverso la rete nello stesso modo in cui viene creato la registrazione dello stream originale. 7

8 2. Profinet PROFINET è lo standard Industrial Ethernet (IEC 61158/61784) innovativo e aperto per l automazione industriale. Con PROFINET è possibile interconnettere in rete apparecchiature dal livello di campo fino al livello di management dell azienda. PROFINET consente una comunicazione omogenea, con un engineering esteso all intero impianto ed utilizza gli standard IT per la diagnostica fino al livello di campo. Sistemi di bus esistenti (ad es. PROFIBUS) possono essere integrati semplicemente senza necessità di modificare le apparecchiature e i software applicativi già esistenti. PROFINET si basa su Industrial Ethernet e utilizza il protocollo TCP/IP(Transport Control Protocol/Internet Protocol) solo per la parametrizzazione, configurazione e diagnostica dei dispositivi. La comunicazione in tempo reale per la trasmissione delle variabili di I/O si svolge sullo stesso cavo Ethernet ma senza utilizzare TCP/IP. Le apparecchiature PROFINET possono supportare le seguenti caratteristiche: Profinet I/O Real-Time (RT) Profinet IRT (Isochronous Real-Time) Profinet CBA (Component Based Automation) Vediamoli nel dettaglio: Profinet I/O Real-Time (RT) Questa funzionalità è utilizzata per variabili di I/O con criticità temporale ovvero per dati ciclici o per allarmi attivati su evento. Per le caratteristiche real-time, richieste nell automazione, PROFINET sfrutta un canale di comunicazione ottimizzato. Le performance di scambio dati sono superiori a quelle dei normali bus di campo e consentono tempi di reazione dell ordine dei millisecondi. Profinet I/O Real-Time (RT) è la comunicazione Real-Time per applicazioni standard, per collegare al PLC Controllore apparecchiature da campo, ad es. periferia decentrata e azionamenti. 8

9 Profinet IRT (Isochronous Real-Time) Per compiti con performance di comunicazione particolarmente critiche e necessità di sincronismo, è disponibile il profilo Isochronous Real-Time. Profinet IRT è ideale per applicazioni di Motion Control e applicazioni highperformance nell automazione di fabbrica. Con IRT il tempo ciclo arriva fino a 250 μs con un jitter (precisione di sincronizzazione sul tempo ciclo) inferiore a 1 μs.il ciclo di comunicazione è ripartito in una parte deterministica ed una aperta. Nell intervallo deterministico sono trasmessi i telegrammi IRT ciclici, mentre la comunicazione TCP/IP avviene nell intervallo aperto. Le due trasmissioni dati coesistono dunque in parallelo, senza disturbarsi a vicenda. Profinet CBA (Component Based Automation) CBA è il profilo per la comunicazione standardizzata tra macchine e la realizzazione di strutture impiantistiche modulari. Con PROFINET CBA la modularizzazione può essere estesa, mediante componenti software, alla tecnica d automazione dell impianto. La comunicazione si svolge tipicamente tramite il canale non Real-Time, data la non criticità delle informazioni di comunicazione. I componenti software possono essere combinati tra loro in modo facile e flessibile indipendentemente dalla loro programmazione interna. La comunicazione tra i componenti software si svolge esclusivamente tramite le interfacce dei componenti, accessibili dall esterno, che sono necessari per lo scambio dati. I componenti software sono configurati con STEP 7 o altri tool specifici del produttore. 9

10 3. Obiettivi L obiettivo del nostro progetto è quello di inserire un nuovo tipo di messaggio chiamato TT, in una rete precedentemente costruita per poter trasmettere dati AVBA, AVB B e Best Effort, con priorità maggiore rispetto a tutti gli altri. Tutti i messaggi una volta creati verranno inseriti in apposite liste, differenziate per tipo di priorità, in attesa di essere inoltrate. Prendendo spunto dai sistemi Profinet si è pensato di creare un CycleTime durante il quale verranno trasmessi i messaggi, suddiviso in 4 fasi, a seconda della sotto fase verranno inviati messaggi differenti. 10

11 4. Implementazione per l implementazione del progetto ho utilizzato Omnetpp 4.3rc1 e l Inet framework Innanzi tutto ho modificato i moduli Station.ned e Bridge.ned modificando il componente Traffic, AVBQueue e inserendo l elemento Scheduler. 11

12 vediamo in breve a cosa serve ogni singolo componente: HardwareClok Questo modulo simula un orologio hardware al fine di riprodurre un vero e proprio orologio, perché quello utilizzato da OMNeT + + è un "orologio perfetto", influenzato da eventuali fonti di errore. Funziona allo stesso modo sia per STATION che per BRIDGE. SoftwareClok E un semplice modulo che ha il compito di tradure il tempo di simulazione di OMNeT++ in quello corretto per l'hardware clock. Funziona allo stesso modo sia per STATION che per BRIDGE. Scheduler Serve per scandire i vari Cycle Time e le zone al suo interno, inoltre fornisce dei metodi per specificare in quale intervallo ci si trova, e l invio di un advertice all AVBQueue per sollecitare la scansione delle liste ogni volta che cambia la sezione. TrafficManager Simula il livello applicazione insieme al MACRelayUnitVlan. Esso può comportarsi come un Talker o un Listener, a secondo di come è specificato nel file di configurazione omnet.ini. Può essere anche l'orologio Grandmaster 801.1AS della rete e quindi inviare i messaggi PTP di sincronizzazione ad ogni ptpsynctimer. Ad ogni mvrptimer, verrà inviato un messaggio MVRP contenente l'id VLAN. Se il comportamento è quello di un Talker si legge da un file, il cui nome è specificato nel file di configurazione omnet.ini, il messagio Talker Advertice, viene inviato allo scadere dell srp_advertisetimer. Quando il flusso è confermato dal Listener il Traffic Manager inizia l'invio dei messaggi secondo la lunghezza e la velocità del flusso. Se il comportamento è quello di un 12

13 Listener decide di accettare il flusso segnalato dall Advertice e invia la risposta SRP appropriata. Inoltre, invia i messaggi pdelay ogni ptppdelaymeasurementtimer per misurare il ritardo di legame con il Master. I messaggi di tipo TT non sono sottoposti a questo tipo di politiche, infatti essi verranno inviati allo scadere di un TT Timer dal Talker, anche essi al primo invio leggeranno il file.txt contenente il messaggio e le specifiche necessarie per l invio. Il listener configurato tramite un file, specificato anche esso in omnet.ini, potrà accettare il messaggio se questo è presente nella lista dei Talker dal quale deve ricevere i dati. AVBQueue a. STATION: Riceve i messaggi dal modulo TrafficManager e li invia al EtherEncapVlan, per gestirli in un modo ottimale vengono inseriti, in base ai valori assunti dai vari parametri del messaggio, in una delle 8 code. L estrazione dalle varie code viene effettuata in base alla fase in cui ci si trova, inoltre per i messaggi di tipo AVB A e AVB B si utilizza il sistema del credit based shaper (802.1Qav). b. BRIDGE: funziona come per la STATION solo che riceve i messaggi dal MACRelayUnitVlan EtherEncapVlan a. STATION: Questo modulo crea i frame Ethernet 802.1Q. in fase di invio viene creato un messaggio Ethernet, che estende quello del framework Ethernet, contente tutte le informazioni provenienti dallo strato TrafficManager. In fase di ricezione vengono estratte le informazioni per ricreare il messaggio destinato allo strato TraffixcManager. b. BRIDGE: Questo modulo si occupa di inoltrare il pacchetto verso la giusta destinazione, sia che si tratti di una station sia che si tratti di un 13

14 nuovo bridge. Esegue il protocollo SRP 802.Qat e la prenotazione del canale come previsto dal protocollo 802.1QAV. Gestisce le porte del bridge effettuando la prenotazione, l invio dei messaggi e la successiva liberazione; Gestisce anche i messaggi MVRP, pdelay e Sync come descritto per il Trafficmanager. EtherMACvlan a. STATION: Fa le funzioni tipiche dello strato MAC Ethernet, ad esempio in ricezione decide se accettare o meno i fram LAN, in fase di invio se necessario completa i frame 802.1Q e li immette nella rete. b. BRIDGE: funziona con le stesse modalità, con l'eccezione che il modulo è in modalità promiscua (accetta tutti i messaggi) e non chiede messaggi al modulo AVBQueue. MACRelayUnitVlan a. BRIDGE: Questa è la parte principale del Bridge. Questo modulo previsto per ricevere il frame, è posto prima della destinazione corretta che può essere sia una singola stazione o una VLAN. esegue il protocollo SRP specificato 802.1Qat e gestisce la prenotazione della banda come descritto in 802.1Qav. E stato sviluppato come estende della MACRelayUnitPP del framework Inet che simula un bridge con molte CPU e una AVBQueues per ogni porta. Quando arriva un messaggio è accodato nella coda relativa e quando una CPU ha porta libera consuma un messaggio dalla coda dalla associata. Il modulo invia anche pdelay e messaggi MVRP come descritto per il modulo TrafficManager. 14

15 5. Modifiche implementative Dopo aver adattato tutti gli ogetti.ned alle nostre esigenze e aver inserito nel file Omnett.ini le nuove variabili di configurazione, ho creato dei timer: timersc per la gestione dei cycletime; TTTimer per sollecitare l invio di messaggi TT; DeregistrationTimer per eliminare un nodo dalla TalkerStreamTabbleRowTT. 5.1 TrafficManager Il modulo TrafficManager, come detto prima, è il punto di partenza e il punto di arrivo dei messaggi nel nodo. Tramite il metodo handlemessage, metodo dove vengono rilevati i messaggi in entrata, possiamo distinguere due categorie di messaggi: i timer e i messaggi veri e propri. Nel caso in cui riceve un Timer si comporta come un Talker, mentre nel caso in cui riceve un mess si comporta come un Listener. Per sollecitare il sistema alla trasmissione di messaggi TT ho inserito un TTTimer, che periodicamente ne sollecita l invio. La prima volta che riceve un timer di questo tipo legge il file.txt, specificato in omnet.ini, contente il messaggio e tutte le variabili necessarie per lo streaming in esso contenute, esegue dei controlli per accertarsi che la lettura del file sia fatta nel modo giusto e dopo averlo inserito nella lista TalkerStreamTableRowTT invia al livello sottostante AVBQueue il messaggio, e setta un nuovo timer per sollecitare un nuovo invio. Le volte successive che verrà ricevuto il timer verrà inviato il messaggio al livello sottostante e settato un nuovo timer. Nel caso in cui riceve un messaggio vuol dire che si trova nella condizione di dover fare il Listener. Qui ho inserito il gestore del messaggio di tipo TTMsg. Per prima cosa vengono salvate le variabili temporali riguardanti l istante di invio, estratto dal messaggio stesso, e di ricezione del messaggio salvando l istante attuale dal clock, poi vengono estratte altre informazioni tra cui l indirizzo, necessario per effettuare la verifica dello stream. Se l indirizzo del 15

16 sorgente del messaggio è presente nella lista listenerstreamtt, creata in fase di inizzializzazione leggendo il file specificato in omnet.ini, allora si passa a calcolare i valori statistici per valutare l efficienza della trasmissione se no viene scartato. Calcoliamo 4 parametri per il traffico di tipo TT: 1. Latency (ritardo punto punto): è la differenza tra l'istante in cui un messaggio lascia il livello di applicazione (TrafficManager) della stazione sorgente e l'istante in cui viene ricevuto dal livello applicazione della stazione di destinazione. Questo valore viene calcolato per ogni messaggio trasmesso. Latency = now - ttmsg->getcreationtime(); 2. Jitter1: è la differenza temporale tra la ricezione di due messaggi consecutivi appartenenti allo stesso flusso, ossia aventi stesso sorgente. jitter1 = now - lastreceptiontime; 3. Jitter2: la differenza tra il jitter1 corrente e l'ultimo jitter1 calcolato. jitter2 = jitter1 - lastjitter1; 4. Jitter di latenza: è la differenza temporale tra la latenza calcolata sull ultimo messaggio ricevuto e la latenza calcolata sul precedente messaggio ricevuto. jitterlatency = latency - lastlatency; 16

17 5.2 Scheduler Un altro elemento importante è lo Scheduler che ha il compito di scandire i cicli di invio dei messaggi. Distinguiamo anzi tutto i CycleTime, all interno del quale sono presenti 4 fasi: Red, Green, Orange e Yellow inizializzate di default nel file Scheduler.ned e poi settabili secondo le nostre esigenze dal file omnet.ini. Come detto precedentemente si è pensato di inviare messaggi differenti a secondo della fase in cui ci si trova. Andiamo ad analizzare le 4 fasi: Red verranno trasmessi solo messaggi d tipo TT fino alla fine del sub intervallo; Green previsto per l invio di messaggi di tipo TT e AVB A, prima prova a inviare messaggi di tipo TT, dopo di che se non è ancora finito l intervallo temporale prova a inviare messaggi di tipo AVB A; Orange previsto per l invio di tutti i tipi di messaggi, quindi in ordine di priorità TT, AVB A, AVB B e BE, sempre con lo stesso principio, prova a estrarre dalla coda i messaggi TT, se resta tempo passa a quelli di tipo AVB A, poi passa a quelli di tipo AVB B e infine prova con il BE; Yellow è stata pensata come una zona di sicurezza per completare l invio dei dati, dato che ogni pacchetto ha dimensioni differenti può occupare il canale per la trasmissione per periodi differenti, con questo intervallo siamo sicuri che non appena ci troviamo nella zona Red possiamo subito inviare il messaggio dato che è già stata completata la trasmissione precedente. Per scandire le varie fasi ho creato un timer, che allo scadere di ogni intervallo temporale, fa cambiare colore alla station, invia un messaggio all AVBQueue per sollecitare una nuova scansione delle code (lo vedremo meglio più avanti) e colora il nodo per far capire in che fase siamo, infine crea un nuovo timer che sarà ricevuto allo scattare del limite inferiore della fase che lo segue in modo da essere sempre sincronizzato. 17

18 5.3 AvbQueue Nella AVBQueue vengono ricevuti i messaggi dal soprastante livello Traffic manger e dallo Scheduler nel caso di una Station. Quando riceve un messaggio dal sovrastante livello, lo inserisce nella coda che lo compete, infatti abbiamo 8 code distinte per priorità, in modo che ogni tipo di messaggio sia processato in base ad essa. Prima di fare l estrazione dalla coda controlla se il sottostante livello è disponibile a elaborare la trasmissione, controllando la variabile packetrequested > 0 e quindi se è possibile effettuare lo stream, questa variabile viene incrementata ogni volta che viene concluso uno stream e decrementata ogni volta che ne viene incominciato uno nuovo. Quindi passiamo a fare il dequeue delle code, controlliamo per prima cosa in che fase colorata ci troviamo, per il motivo sopra descritto, dopo di che passiamo a scansionare le liste di competenza alla fase per ordine di priorità. Se nelle liste scansionate non sono presenti messaggi ritornerà un mess null e resterà in attesa di ricevere un nuovo messaggio dallo Scheduler che solleciti una nuova scansione delle liste per un eventuale estrazione di un messaggio che era in attesa di essere estratto nella nuova fase. Tutti gli altri file sono stati modificati al fine di supportare la trasmissione dei messaggi di tipo TT. 18

19 6. Simulazione Per le simulazioni abbiamo analizzato i seguenti scenari: 6.1 Automotion Nel file omnetpp.ini (\AVB_Ethernet_TT_ps\simulations\ETFA) sono state impostate tutte le variabili di rete, vediamo le caratteristiche più importanti Tipo Bandwid th (Mbps) Start Time- End Time 19 Payload (byte) AVB class Service rate (ms) Cameras (right, front, left, rear) [4-12] 0-60 Uniform(201,680) Class A 1,81 Camera NiVi [1-3] Uniform(201,680) Class A 1,81 LDW/TSR camera [2-6] Uniform(201,680) Class A DA_CAM Video Traffic [4-12] 0-45 Uniform(201,680) Class A Aggregated flow 4 flow DA_CAM Video Traffic [5-15] Uniform(201,680) Class A Aggregated flow 5 flow DA_CAM Warning Traffic Classe 50 ST DVD Player Class B Audio CD Player Class B 5.10 Cross Domain Traffic 1st flow Classe 5 ST Cross Domain Traffic 2nd flow Classe ST 5

20 Scheduler #set scheduler *.node1.scheduler.cycle_time = 5 #ms #la somma deve fare 100 *.node1.scheduler.red = 200 #µs *.node1.scheduler.green = 1300 #µs *.node1.scheduler.orange = 2100 #µs *.node11.scheduler.yellow = 1400 #µs Dopo aver eseguito 4 simulazioni con seed differente (nello specifico ho usati i valori: ; ; ; ;) da 60 secondi ciascuna, ho preso i valori medi riguardanti le singole trasmissioni e ho ottenuto i seguenti risultati: tipo E2E in secondi Right Camera 0, Intervallo di confidenza 2, E- LDR in secondi 0, Intervallo di confidenza 9, E- Jitter di latenza in secondi 0, Intervallo di confidenza 4, E- 2, E- 9, E- 4, E- Front Camera 0, , E- 0, , E- 03; 0, , E- 2, E- 9, E- 03; 4, E- Left Camera 0, , E- 0, , E- 0, , E- 2, E- 9, E- 4, E- Rear Camera 0, , E- 0, , E- 0, , E- 2, E- 9, E- 4, E- NIVI Camera 0, , E- 0, , E- 0, , E- 20

21 2, E- 9, E- 4, E- LDW/TSR camera 0, , E- 0, , E- 0, , E- 04 2, E- 6, E- 3, E- 04 Da-Cam 1 traffico 0, , E- 0, , E- 0, , E- 2, E- 3, E- 2, E- Da-Cam 2 traffico 0, , E- 0, , E- 0, , E- 2, E- 2, E- 1, E- Audio Player , , E- 0, , E- 1, E- 1, E- DVD Player E-5 0, ,391030E E-5 9,066763E- DA-Cam TT traffic 4, E- 05 4, E- 05; 1, E-06 1, E- 06; 8, E-07 1, E- 06; 4, E- 05; 1, E- 06; 6, E- 07; Control Unit 1 traffico TT E-5 0; 0; 0 0; 0; 0 0; 0; Control Unit 2 traffico TT E-5 2,715100E+1 1; 0 0; 0; 1, E-12 0; 0; 2,715100E+1 1; 21

22 tipo E2E max in secondi LDR max in secondi Jitter di latenza max in secondi Right Camera Front Camera Left Camera Rear Camera NiVi Camera DA-Cam 1 traffico DA-Cam 2 traffico LDW/TSR Camera Audio Player DVD DA-Cam E E E-6 Control Unit 1 flusso E Control Unit 2 flusso E E-12 Dai risultati precedenti possiamo vedere che effettivamente i messaggi di tipo TT vengono inviati non appena vengono inseriti in coda, Andiamo a controllare i valori delle singole latenze: DA-Cam TT: Pacchetti 100 B -> 800 b Quindi sapendo che trasmettiamo 100Mb al secondo impieghiamo 8 µs per ogni tratta, mentre dentro ogni bridge permane per 10 µs, considerato che viene trasmesso 3 volte e attraversa 2 bridge, impiega totalmente: 8 µs*3+10 µs*2=44 µs Che corrisponde all incirca al valore da noi ottenuto. Control Unit TT 1 traffico: Pacchetti 46 B -> 368 b Quindi sapendo che trasmettiamo 100Mb al secondo impieghiamo 3.68 µs per ogni tratta, mentre dentro ogni bridge permane per 10 µs. questa volta vengono trasmessi 2 volte e attraversa un solo Bridge, quindi avremo: 3.68 µs*2+10 µs = 17,36 µs 22

23 Control Unit TT 2 traffico: Pacchetti 92 B -> 736 b Quindi sapendo che trasmettiamo 100Mb al secondo impieghiamo 7.36 µs per ogni tratta, mentre dentro ogni bridge permane per 10 µs. questa volta vengono trasmessi 2 volte e attraversa un solo Bridge, quindi avremo: 7.36 µs*2+10 µs = µs Confrontando i valori calcolati con quelli ottenuti vediamo che all incirca corrispondono. Passiamo ad analizzare i grafici delle latenze: incominciamo analizzando quella del nodo CPU per il traffico TT: Possiamo vedere che i pacchetti hanno una latenza costante, in quanto hanno priorità massima e vengono sempre trasmessi, non è possibile distinguere le 4 fasi dato che i messaggi tipo TT vengono trasmessi ogni 5 ms che equivale al nostro Cycle_time, conseguentemente non verranno mai messi in attesa. Se analizziamo invece il traffico AVB A del Nodo DA-cam possiamo vedere che si alternano periodi di trasmissione a periodi di attesa, questo dipende dalle varie zone in cui si trova il messaggio. Ho effettuato il calcolo temporale degli intervalli di attesa (parte evidenziata nell immagine dal tracciato rosso), e degli intervalli di trasmissione (parte evidenziata in blu): 23

24 Facciamo qualche calcolo per capire il significato di tali intervalli Parte rossa: = secondi Questo valore corrisponde all incirca alle somma delle zone YELLOW e RED ( =1600 µs) periodi in cui non vengono trasmessi i messaggi di tipo AVB A e che quindi vengono accumulati, infatti si può notare che all inizio della parte evidenziata in blu abbiamo una maggiore concentrazione di messaggi trasmessi. Parte blu: = secondi Che equivale alla somma della zona GRENN e ORANGE ( =3400 µs) periodi durante i quali vengono inviati i messaggi di tipo AVB A. Possiamo fare un analisi simile anche per quanto riguarda i messaggi di tipo AVB B del nodo RSE, questa volta ci aspetto che la zona rossa (durante la quale non vengono trasmessi i pacchetti) sia più grande di quella blu (durante la quale invece vengono trasmessi) : 24

25 Anche qui possono essere fatti gli stessi calcoli fatti precedentemente: parte rossa: = secondi Che è un po più della somma delle zone YELLOW, RED e GREEN questo è dovuto al fatto che i messaggi di tipo AVB B sono quelli a priorità minore, quindi tutti gli altri tipi di messaggi vengono trasmessi prima e conseguentemente l intervallo temporale di trasmissione per questo tipo di messaggi si riduce ulteriormente, infatti vediamo che la parte blu che dovrebbe coincidere con la zona ORANGE vale: = secondi Come abbiamo visto quindi gli intervalli di trasmissione ottenuti dalla trasmissione corrispondono a quelli attesi. 25

26 6.2 industrial comunication Nel file omnetpp.ini (\AVB_Ethernet_TT_ps\simulations\ETFA) sono state impostate tutte le variabili di rete, vediamo le caratteristiche più importanti: Tipo Bandwidth (Mbps) Start Time- End Time Payload (byte) AVB class Service rate (ms) Nodo 1 [4-12] 0-60 Uniform(201,680) Class A 1,81 Nodo 2 [1-3] Uniform(201,680) Class A 1,81 Nodo 3 1 traffico [2-6] 0-25 Uniform(201,680) Class A Nodo 3 2 traffico [2-6] Uniform(201,680) Class A Nodo 5 1 traffico [4-12] 0-45 Uniform(201,680) Class A Nodo 5 2 traffico [5-15] Uniform(201,680) Class B Nodo Uniform(201,680) Classe B 50 Nodo 1 TT Classe ST 5 Nodo 4 TT Classe ST 5 1 traffico Nodo 4 TT 2 traffico Classe ST 5 26

27 *.Node6.scheduler.cycle_time = 5 #millisecondi #la somma deve fare 100 *.Node6.scheduler.red = 4 % *.Node6.scheduler.green = 26 % *.Node6.scheduler.orange = 42 % *.Node6.scheduler.yellow = 28 % Dopo aver eseguito 4 simulazioni con seed differente (nello specifico ho usati i valori: ; ; ; ;) da 60 secondi ciascuna, ho preso i valori medi riguardanti le singole trasmissioni e ho ottenuto i seguenti risultati: tipo E2E in secondi Nodo 1 2, E Intervallo di confidenza 2, E- LDR in secondi 9, E Intervallo di confidenza 9, E- Jitter di latenza in secondi 4, E Intervallo di confidenza 4, E- 2, E- 9, E- 4, E- Nodo 2 2, E 3, E- 9, E 9, E- 4, E 4, E- 2, E- 8, E- 4, E- Nodo 3 1 traffico 3, E 3, E- 6, E 6, E- 3, E 3, E- 3, E- 6, E- 3, E- Nodo 3 2 traffico 3, E 3, E- 3, E 3, E- 2, E 2, E- 3, E- 3, E- 2, E- Nodo 5 3, E 3, E- 3, E 3, E- 2, E 2, E- 3, E- 3, E- 2, E- 27

28 Nodo 5 traffico AVB B ; 0; 5, E 5, E- 5, E- 4, E 5, E- 4, E- Nodo 2 traffico AVB B 6, E -05 6, E- 05; 4, E -06 5, E- 06; 2, E -06 2, E- 06; 6, E- 05; 4, E- 06; 1, E- 06; Nodo 1 TT 2, E -05 2, E- 05; 6, E -08 7, E- 08; 3, E -08 4, E- 08; 2, E- 05; 6, E- 08; 2, E- 08; Nodo 4 TT 1 traffico 5, E -05 0; 0; 0 0; 0; 0 0; 0; Nodo 4 TT 2 traffico 6, E -05 6, E -05; 6, E -05; 0 0; 0; 1, E -12 0; 0; tipo E2E max in secondi LDR max in secondi Jitter di latenza max in secondi Nodo Nodo Nodo 3 1 traffico E E-5 Nodo 3 2 traffico Nodo Nodo 5 AVB B Nodo 2 AVB B E E E-5 Nodo 1 TT E E E-6 Nodo 4 TT 1 traffico E Nodo 4 TT 2 traffico 6,4375 E , E-12 28

29 verifichiamo ora se i valori ottenuti corrispondono a quelli attesi tenendo presente che trasmettiamo a una velocità di 100 MB/s Nodo1 TT: Pacchetti 100 B -> 800 b => impieghiamo 8 µs per ogni tratta, mentre dentro ogni bridge permane per 10 µs, considerato che viene trasmesso 2 volte e attraversa 1 bridge, impiega totalmente: 8 µs*2+10 µs=26 µs Nodo2 TT 1 traffico: Pacchetti 46 B -> 368 b => impieghiamo 3.68 µs per ogni tratta, mentre dentro ogni bridge permane per 10 µs, questa volta vengono trasmessi 4 volte e attraversa 3 Bridge, quindi avremo: 3.68 µs*4+10*3 µs = 44,72 µs Nodo2 TT 2 traffico: Pacchetti 92 B -> 736 b => impieghiamo 7.36 µs per ogni tratta, mentre dentro ogni bridge permane per 10 µs. questa volta vengono trasmessi 4 volte e attraversa quindi avremo: 3 Bridge, 7.36 µs*4+10*3 µs = 59,44 µs Quindi possiamo vedere che i valori attesi rispecchiano quelli ottenuti. 29

30 Passiamo ora ad analizzare i grafici delle latenze come fatto per la precedente simulazione. Nodo1 traffico TT : Anche questa volta possiamo vedere che il traffico di tipo TT è uniformamente distribuito e costante, questo perché i messaggi di tipo TT hanno la precedenza su tutti gli altri e non attendono mai prima di essere inviati dato che la frequenza di invio coincide con il cyle_time. Passiamo ad analizzare i messaggi di tipo AVB A. Nodo 5 traffico AVB A: 30

31 Parte rossa = secondi Parte blu = secondi Si può notare che la parte rossa corrisponde all incirca alla somma delle zone YELLOW e RED ( =1600 µs) mentre la parte blu alla somma della parte GREEN e ORANGE ( =3400 µs) durante i quali possono essere trasmessi i messaggi di tipo AVB A. Nodo 5 traffico AVB B: Parte rossa: = secondi Parte blu = secondi Anche questa volta possiamo vedere che la parte rossa corrisponde circa alla somma della parte YELLOW, RED e GREEN mentre la parte blu deve corrisponde all incirca alla parte ORANGE durante la quale vengono trasmessi i messaggi di tipo AVB B dando la precedenza a tutti gli altri tipi, dunque c è 31

32 corrispondenza tra i valori attesi e quelli ottenuti anche con questa simulazione. 7. Porting Per poter eseguire correttamente il progetto su dispositivi provvisti di Mac os bisogna modificare i parametri all interno del TrafficManager.cc nella fase di lettura da file.txt, infatti tale sistema operativo aggiunge un simbolo di fine riga in questi file. I metodi interessati da tale modifica sono: TT_readFile_msgTTFileName() TT_readFile_listenerStreamToAcceptTTFileName() SRP_selectAndsendSRPAdvertiseMessage() SRP_loadListenerStreamsToAcceptTable() All interno di ognuno di questi metodi viene fatto un controllo sul numero di token per capire se sono presenti tutti i parametri, dunque dobbiamo incrementare il valore di uno. Ad esempio nel metodo SRP_loadListenerStreamsToAcceptTable(): if (tokens.size()!= 3) deve diventare if (tokens.size()!= 4). 32