Introduzione al protocollo AFDX

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

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

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

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

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

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 2. Bandwidth per ogni Virtual Link

Tabella 3. Numero di Virtual Link Teorico per linea fisica

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.

 

 

Una risposta

  1. Maurizio Di Paolo Emilio Maurizio Di Paolo Emilio 25 gennaio 2017

Scrivi un commento

ESPertino è la nuova scheda per IoT compatibile ARDUINO.
Scopri come averla GRATIS!