L’Avionic Full Duplex switched Ethernet (AFDX) è uno standard che definisce interfacce elettriche e protocolli per lo scambio di dati tra sottosistemi avionici. In realtà, nell’AFDX coesistono diverse soluzioni tecnologiche: infatti, per le interfacce elettriche lo standard di riferimento è il solito IEEE 802.3, e per la definizione del protocollo è applicabile la specifica ARINC 664 parte 7. L’idea di un nuovo protocollo per i sottosistemi avionici nasce dal consorzio europeo Airbus.
Introduzione
Negli anni novanta il consorzio Airbus predispose una serie d’attività allo scopo di definire nuove tecnologie per vari domini (databus communication, controlli di volo, …) per poi utilizzarle per una nuova generazione di aerei, come l’A380. Una delle proposte era quella di sostituire il bus avionico ARINC 429 con un altro in grado di dare maggiori prestazioni. Una prima idea era quella di adottare l’ARINC 629. L’interesse primario era, in ogni caso, la sostituzione dell’ARINC 429 con una tecnologia già consolidata nel mondo delle telecomunicazioni: lo standard Ethernet. Il riquadro di approfondimento mostra le differenze di performance tra l’ARINC 429 e lo standard Ethernet. Una considerazione importante da tenere presente che i bus commerciali offrono un buon grado di performance insieme ad un alta maturità tecnologica: questo è una delle ragioni che portarono all’adozione dell’IEEE 802.3 piuttosto che definire un nuovo standard. Airbus decise di utilizzare un Full Duplex (switched) Ethernet per molteplici ragioni. Alcune di queste ragioni sono ancora oggi attuali, infatti:
- permette di mappare altri bus avionici (ARINC429 o MIL-STD-1553) sulla sua topologia;
- consente una segregazione fisica e un alto grado di integrità;
L’adozione e la modifica del Full Duplex (switched) Ethernet per le specifiche esigenze avioniche portarono alla definizione dell’AFDX (Avionic Full Duplex Switched Ethernet): lo standard Network Protocol è utilizzato per interconnettere equipaggiamenti avionici dove i vari dispositivi sono connessi attraverso uno switch.
Il modello AFDX
Come già scritto l’AFDX è basato su EEE 802.3 Ethernet e sui principi della pila TCP/IP. Per fornire le necessarie restrizioni sulla sicurezza del trasferimento dei dati e l’integrità del suo network, il protocollo AFDX recepisce specifiche indicazioni, quali il determinismo richiesto per le applicazioni aerospaziali. I principali componenti di un network AFDX sono:
- Avionic Subsystem. Con questo si identificano i sottosistemi avionici tradizionali di bordo come flight control computer, GPS. Un Avionic Computer System fornisce un ambiente “computazionale” per l’Avionic Subsystem. Ogni Avionic Computer System contiene un embedded End System che connette il sottosistema avionico ad una connessione AFDX.
- AFDX End System (End System). Fornisce un’interfaccia tra i sottosistemi avionici (Avionic Subsystem) e le interconnessioni AFDX. Quest’interfaccia dee essere in grado di garantire lo scambio dei dati con gli altri Avionic Subsystems. Esistono una serie di API in grado di fornire servizi di sampling e queuing come descritto nello standard ARINC 653.
- Interconnessione AFDX. In genere è costituito da un network di switch che permettono di instradare le trame Ethernet alle loro destinazioni.
In figura 1 possiamo vedere la struttura generale di un Avionics Computer System.
Figura 1. la struttura generale di un Avionics Computer System: per spedire e/o ricevere messaggi vengono usate delle communications ports, meccanismi software per la gestione dei messaggi
L’Avionic Subsystems usa delle communications ports per spedire e/o ricevere messaggi. Le communication ports non sono altro che dei meccanismi software per la gestione dei messaggi. Esistono due tipi di comunicazioni in un Avionics Subsystem: sampling e queuing port. Le differenze tra sampling e queuing port sono individuabili principalmente nel processo di ricezione. Infatti:
- In una porta sampling, il suo buffer di ricezione è in grado di ricevere un singolo messaggio per volta. Se il software applicativo non svuota il buffer nel tempo utile allora questo è continua mente riscritto; inoltre, il software quando legge il buffer i dati non sono cancellati. Ogni API che si rispetti deve essere in grado di dare una indicazioni sulla qualità dei dati presenti, cioè dare indicazioni di freshness dei messaggi contenuti nel buffer. Senza questa indicazione sarebbe difficile stabilire se l’Avionic Subsystems ha fermato le trasmissioni per qualche problema o se sta trasferendo lo stesso messaggio.
- In una porta queuing, nel buffer c’è spazio per un numero prestabilito di messaggi (stabiliti di solito mediante un’API di inizializzazione del sistema), i nuovi messaggi sono appesi nella coda della porta. In una porta queuing, la lettura del buffer parte del software rimuove i messaggi dalla coda (la coda è di tipo FIFO).
Tipicamente, le API per spedire e ricevere messaggi sono le seguenti:
- Send_Msg(Port_ID,message)
- Recv_Msg(Port_ID,message)
Virtual Links
Il concetto di Virtual Link è il cuore centrale dell’AFDX. Abbiamo visto che la funzione principale dell’End System è quella di fornire dei servizi per lo scambio dei dati tra una rete AFDX e più partizioni di un eventuale applicativo software. Il protocollo AFDX nasce dalla necessità di rendere deterministico un protocollo molto diffuso e standardizzato come lo standard Ethernet. Abbiamo scritto che la rete AFDX connette i vari ES attraverso uno switch. Da qui nasce il primo problema, se più sistemi sulla stessa linea trasmettono contemporaneamente cosa succede? Nella terminologia Ethernet diremmo che collidono. Lo standard Ethernet prevede che i due trasmettitori riprovino a trasmettere fino a quando la linea non è libera. In questo modo i dati che un applicativo vuole spedire arrivano al ricevitore in un tempo indefinito, non quantificabile. Potrebbe addirittura verificarsi che i due restino in retry all’infinito. Nell’AFDX si usa il concetto di Virtual Link per risolvere questo problema. Un virtual link definisce una connessione logica uni-direzionale tra un trasmettitore ed uno o più ricevitori. Nel mondo AFDX, ogni Virtual Link ha un suo identificatore. Questo viene definito mediante una rappresentazione a 16-bit. Il Virtual Link ID, così viene chiamato, è utilizzato dall’Ethernet layer per indirizzare la trama Ethernet in un network AFDX. Una linea a 100 Mbps di un End System è in grado di supportare multipli Virtual Link. Tutti questi Virtual Link condividono il bandwidth del suo link fisico. Il Virtual Link contiene le informazioni delle communication ports: così un Virtual Link ID 1 trasporta le informazioni relative alle comunication ports 2, 4, 8; mentre un altro Virtual Links ID 2 trasporta le communication ports 1, 5, 7. In figura 2 viene mostrato il caso di più End System con uno solo Virtual Link.
Figura 2. L’End System 1 spedisce i dati sul Virtual Link e lo switch, attraverso una tabella di configurazione, conosce tutte le interconnessioni (Virtual Link) tra i vari End System, in questo modo indirizza correttamente i dati agli altri End System
Dalla figura 2 possiamo notare che l’End System 1 spedisce i dati sul Virtual Link e lo switch, attraverso una tabella di configurazione, conosce tutte le interconnessioni (Virtual Link) tra i vari End System, in questo modo indirizza i dati agli End System corretti. Dato che ogni End System può trasmettere/ricevere su/da più Virtual Links, è stato introdotto un meccanismo per limitare la banda di ogni Virtual Link ed evitare effetti di saturazione. Questo permette anche di calcolare la latenza dei dati nella rete e renderla quindi deterministica. La banda di ogni Virtual Link viene limitata attraverso un meccanismo di “Bandwidth Allocation Gap”. Lo schedulatrore di un End System può essere rappresentato come in figura 3.
Figura 3. Lo schedulatore di un End System
Possiamo notare a questo riguardo che ad ogni Virtual Link vengono associati tre parametri che determinano il flusso dei dati in uscita: BAG, MaxLength e jitter. BAG, rappresenta l’intervallo di tempo minimo tra il primo bit di due frames consecutivi di uno stesso Virtual Link. Se, per esempio, un Virtual Link con VLID 1 ha un BAG di 32 millisecondi, allora un pacchetto Ethernet non può essere spedito con un tempo maggiore di 32 millisecodi. Se VLID 1 ha un Lmax di 200 bytes, allora il massimo bandwidth sul VLID 1 è 50.000 bits per secondi (200*8*1000/32). I valori di BAG ammissibili sono potenze di 2 comprese tra 1ms e 128ms (tabella 1).
Tabella 1. I valori di BAG ammissibili
MaxLength definisce la massima lunghezza di ogni pacchetto dati trasmesso per frame che può essere trasmesso su di un Virtual Link. La lunghezza massima ammissibile è di 1518 bytes.
Jitter: se un End System trasmette su più Virtual Link, i pacchetti in uscita dall’End System devono essere accodati per rispettare i vincoli di BAG di ogni Virtual Link, a questo punto lo scheduler può introdurre un jitter nella trasmissione di ogni pacchetto. Il valore di questo Jitter deve essere compreso secondo quanto stabilito nello standard Arinc 614 parte 7. Il risultato dello stream in uscita dei frame per ogni VL è riportato in Figura 4.
Figura 4. Lo stream di uscita per ogni Virtual Link
È possibile calcolare la massima banda passante utile di ogni Virtual Link:
Bmax = (Lmax/BAGmin) * 8bit =(1518 byte / 1ms) * 8bit = 12,144 Mbit/s
Per aumentare il livello di safety della rete, ogni End System trasmette su due linee fisiche ridondate. Considerando le dimensioni dell’intero frame in uscita dal Phisical Layer, è possibile stimare le bande ed il numero massimo di Virtual Link per linee a 100Mb/sec come indicato nelle tabelle 2, 3.
Tabella 2. Bandwidth per ogni Virtual Link
Tabella 3. Numero di Virtual Link Teorico per linea fisica
Dimensionamento di un Virtual Links
Ogni Virtual Link deve essere correttamente dimensionato in relazione al valore del BAG e di Lmax. La scelta del BAG di un Virtual Link dipende dai requisiti delle porte AFDX. Se per esempio supponiamo che un Avionic Subsystem deve spedire messaggi su tre porte AFDX e che condividono lo stesso Virtual Link, occorrerà, per prima cosa stabilire la frequenza dei messaggi sulle porte, per esempio, 10 Hz, 20 Hz e 40 Hz rispettivamente. La frequenza totale di questi messaggi è così di 70 Hz, la media del periodo di trasmissione di questi messaggi è quantificabile a 14,4 milliseconds. In accordo allo standard AFDX di fornire un adeguato bandwidth al Virtual Link, dovremmo scegliere un BAG con un valore minore di 14,4 milliseconds. In questo caso, la prima scelta utile è un BAG di 8 millisecondi, corrispondente ad una frequenza di 125 Hz. Con una scelta di questo tipo, noi siamo garantiti che il Virtual Link è in grado di trasportare i messaggi sulle tre porte.
Conclusioni
Per la stesura di questo articolo ci sono aspetti che non abbiamo preso in considerazione come il concetto di ridondanza o quello del Virtual Link Scheduler. Questo lavoro è una introduzione al protocollo AFDX. Certamente questo standard rappresenta un’interessante evoluzione dei bus avionici: contiene diverse considerazioni che lo rendono sicuramente “appetibile” da un punto di vista tecnologico.
L’avionica è un settore abbastanza “complicato” per quanto riguardo la progettazione, sia in termini di hardware con fattori indesiderati e ambienti difficili da tener bene in mente, ma anche aspetti software e di real time per la comunicazione attraverso vari dispositivi. Questo bus è utilizzato soprattutto in ambito civile con modalità di trasmissione half-duplex per evitare collisioni. Appartiene alla categoria di bus COTS (Commercial Off The Shelf ).