CANaerospace

Il Logo

CANaerospace^[1] è un protocollo di alto livello basato su Controller Area Network (CAN), che è stato sviluppato da Stock Flight Systems^[2] nel 1998 per applicazioni aeronautiche. Grazie al suo approccio open source si è velocemente propagato all'interno di progetti di ricerca aerospaziali e aeronautici e ha promosso nuovi protocolli aeronautici basati sul CAN-Bus (vedi anche ARINC 825).

Background

CANaerospace supporta i sistemi di bordo utilizzando il concetto di Line Replaceable Units (LRU) per condividere i dati attraverso il CAN e garantisce l'interoperabilità tra CAN LRUs definendo le caratteristiche dello strato fisico CAN, gli strati di rete, i meccanismi di comunicazione, tipi di dati e sistemi di coordinate e assi aeronautiche. CANaerospace è un progetto open source, è stato avviato per standardizzare l'interfaccia tra LRU CAN a livello di sistema e ha influenzato in modo importante il nuovo standard ARINC 825. CANaerospace è in continuo sviluppo ed è anche stato pubblicato dalla NASA come il "Advanced General Aviation Transport Experiment (AGATE)" NASA-Standard^[3] nel 2001. CANaerospace ha trovato ampio utilizzo nel settore della ricerca aeronautica in tutto il mondo. Un progetto aeronautico di importanti dimensioni, che si avvale di una moltitudine di computer e reti di interconnessione in tempo reale CANaerospace, è l'Stratospheric Observatory for Infrared Astronomy (Sofia), un Boeing 747SP con un telescopio astronomico di 2,5 m. CANaerospace è anche frequentemente usato in simulatori di volo e interconnette interi cockpit (per esempio in simulatori Eurofighter Typhoon) verso i computer host di simulazione. In Italia CANaerospace viene utilizzato come bus dati per tecnologia UAV^[4]. Inoltre, CANaerospace funge da rete di comunicazione in vari sistemi avionici di Aviazione Generale.

Particolarità di base

La definizione dell'interfaccia CANaerospace chiude il gap tra lo standard ISO / OSI di livello 1 e 2 del protocollo CAN (che è implementato nel controller CAN stesso), e le esigenze specifiche per sistemi distribuiti in aeromobili. Può essere usato come rete avionica primaria o di accessori ed è stato progettato per soddisfare i seguenti requisiti:

Rete democratica: CANaerospace non richiede alcun rapporto master / slave o un "bus controller" tra le LRU, evitando così una potenziale fonte di guasto. Ogni nodo della rete ha gli stessi diritti di partecipazione al traffico sul bus.

Formato del messaggio a identificazione automatica: ogni messaggio CANaerospace contiene informazioni sul tipo dei dati e il nodo di trasmissione. Questo permette ai dati di essere interpretati in modo inequivocabile da ogni nodo ricevente.

Numerazione di messaggi continuo: ogni messaggio contiene un numero CANaerospace continuamente incrementato, che consente un trattamento coerente dei messaggi nelle stazioni di ricevente.

Messaggio codice di stato: ogni messaggio contiene le informazioni sulla integrità dei dati CANaerospace. Questo consente alle stazioni riceventi di valutare la qualità dei dati ricevuti e di reagire di conseguenza.

Evento segnalazione di emergenza: CANaerospace definisce un meccanismo che consente ad ogni nodo di trasmettere le informazioni riguardanti situazioni di eccezione o di errore. Queste informazioni possono essere utilizzate da altre stazioni, per determinare la salute di rete.

Intercommunicazion tra nodi selezionati: CANaerospace supporta lo scambio di messaggi sul bus tra utenti selezionati tramite una interfaccia di comando comune. Questo serve, per esempio, per controllare l'integrità della rete o utenti, scambi di messaggi block-oriented o di operazioni simili che richiedono l'interazione tra due o più utenti sul bus, senza che utenti non desiderati vi partecipano.

Lista CAN-Identifier predefinita: CANaerospace offre per i dati operativi un elenco predefinito di identificatori CAN, simile allo standard ARINC 429. In aggiunta alla lista predefiniti, è possibile l'utilizzo di identificatori CAN definiti dall'utente.

Facilità di implementazione: la quantità di codice software necessario per implementare CANaerospace è molto bassa, al fine di minimizzare lo sforzo per operazioni di testing e certificazione di sistemi mission critical.

Espandibile: Tutte le definizioni CANaerospace sono espandibili da parte dell'utente, per fornire così la maggiore flessibilità per future migliorie e di consentire adeguamenti alle esigenze di applicazioni specifiche.

Disponibilità senza costi: l'uso del protocollo CANaerospace è esente da costi e royalities. La specifica può essere scaricata da Internet.

Livello Fisico (Physical Layer)

L'aspetto forse più interessante della specifica Can, è rappresentato dall'affidabilità del protocollo. La probabilità di una corruzione dei dati non rilevata, infatti, è 10-3 per messaggio, il che equivale a 2,910-6 errori non rilevati per ora in condizioni di massimo utilizzo del bus. Tale figura di merito è migliore di quella caratteristica di un qualunque altro sistema. Per garantire l'interoperabilità e questa affidabilità di comunicazione, CANaerospace specifica le caratteristiche elettriche, i requisiti per i bus transceiver e le velocità di trasmissione dati con le relative tolleranze basate alla norma ISO 11898. Il calcolo del bit timing (precisione baud rate, definizione sample point) e la resistenza alle interferenze elettromagnetiche sono di particolare rilievo. Vengono anche definiti connettori CAN, considerazioni di cablaggio e linee guida di progettazione per massimizzare la compatibilità elettromagnetica.

Strato di Comunicazione (Communication Layer)

La specifica CAN di Bosch permette la transmission dei messaggi sia periodici che aperiodici ma non copre specifiche di rappresentazione dei dati, indirizzamento dei nodi o protocolli connection-oriented. CAN si basa interamente sulla comunicazione "Anyone-to-Many" (ATM) che significa che i messaggi CAN sono sempre ricevuti da tutte le stazioni presenti sulla rete. Il vantaggio del concetto CAN è inerente alla coerenza dei dati tra tutte le stazioni, lo svantaggio è che non permette di indirizzare un nodo specifico, che è la base per la comunicazione Peer-to-Peer (PTP). L'utilizzo di reti CAN in applicazioni aeronautiche, tuttavia, richiede una norma mirata alle specifiche esigenze dei sistemi avionici di bordo, il che implica la possibilità di comunicazione tra singole stazioni sulla rete per permettere il livello di monitoraggio del sistema richiesto. Di conseguenza, CANaerospace definisce ulteriore funzioni ai livelli ISO / OSI 3, 4 e 6 per supportare l'indirizzamento dei nodi e meccanismi di comunicazione ATM/PTP unificati. la comunicazione PTP permette di instaurare interazioni client / server tra le singole stazioni della rete in modo temporaneo o permanente. Più di una di queste interazioni possono essere in vigore in un ogni momento e ogni nodo può essere client per una sola operazione e server per un'altra allo stesso momento. Questo meccanismo CANaerospace si chiama "Node Service Concept" e permette per esempio la distribuzione di funzioni di sistema su diverse stazioni della rete o per controllare la riconfigurazione dinamica del sistema in caso di guasto. Il concetto Node Service supporta sia le interazioni orientato alla connessione e senza connessione, come con il protocollo TCP / IP e UDP / IP per Ethernet.

Permettendo entrambe le comunicazioni sia ATM e PTP per il CAN, richiede l'introduzione di livelli di rete indipendenti per isolare i diversi tipi di comunicazione. Per CANaerospace questo è realizzato generando gruppi di identificatori CAN come mostrato nella Figura 1. La struttura risultante crea Canali di Comunicazione Logica (LCC) e assegna un tipo specifico di comunicazione (ATM, PTP), a ciascuno dei LCC. LCC definiti dall'utente forniscono la necessaria libertà per i progettisti per consentire in base alle esigenze di applicazioni specifiche l'implementazione di CANaerospace.

FIGURA 1: I canali di comunicazione logici per CANaerospace

Come effetto collaterale in caso di arbitraggio del bus, i gruppi di identificatori CAN nella Figura 1 hanno un differente impatto sulla priorità della trasmissione di messaggi. I canali di comunicazione sono quindi disposti secondo la loro relativa importanza:

Emergency Event Data Channel (EED): Questo canale viene utilizzato in situazioni che richiedano azioni immediate (esempio degrado del sistema o riconfigurazione); EED usa esclusivamente il tipo di comunicazione di tipo ATM.

High/Low Priority Node Service Data Channel (NSH/NSL): Questo canale di comunicazione è usato per interazioni client/server utilizzando la comunicazione PTP. Il servizio corrispondente può essere di natura orientata alla connessione o senza connessione. I canali NSH/NSL vengono impiegati anche a supporto di funzioni di test e manutenzione della rete.

Normal Operation Data (NOD: Questo canale viene utilizzato per trasmettere messaggi di dati di stato e operativi aeronautici, normalmente generati dai sistemi di bordo descritti nella lista di identificatori CANaerospace. Questi messaggi possono essere di tipo sincrono o asincrono e inviati in intervalli predefiniti dal sistema. Tutti i messaggi, non attribuiti ad altri canali di comunicazione, devono utilizzare questo canale.

High/Low Priority User-defined Data Channel (UDH/UDL): Questi canali di comunicazione sono a disposizione per messaggi asincroni o sincroni e con formato variabile secondo quanto specificato dall'utente e non attribuibili ad altri canali senza ferirne la loro definizione. Sono ammessi comunicazioni del tipo ATM e PTP. Per non limitare troppo l'interoperabilità si consiglia, quanto possibile, l'utilizzo degli altri canali di comunicazione. L'impiego di messaggi definiti dall'utente dovrebbe essere considerata un'eccezione.

Debug Service Data (DSD): Sono messaggi trasmessi per scopi di debug e operazioni di download di applicativi software e non inviati in condizione di operatività del sistema. Il contenuto dei relativi messaggi è totalmente definito dall'utente.

Formato dati CANaerospace

La maggior parte dei sistemi di controllo real-time usato in aeronautica impiegano processori con architetture "big endian". Questo formato dei dati è stato quindi specificato anche per CANaerospace. Con il formato di dati big endian, il bit più significativo di ogni dato è disposto al lato più a sinistra del datum e inviato via CANaerospace come primo bit, come illustrato nella Figura 2. CANaerospace si basa sullo Standard (11 bit) Identifier, può essere anche implementato sulla base Extended (29 bit) Identifier. I bit 12-28 dei CAN-Identifier, erano riservati fino alla versione 1.7 di CANaerospace per scopi di rendundanza, a partire dalla versione 1.8, i bit vengono suddivisi alla compatibilità con ARINC 825.

Figure 2: Formato CANaerospace "Big Endian"

CANaerospace utilizza un formato di messaggio di identificazione automatica che si presenta strutturando il payload del messaggio, come mostrato nella Figura 3. Questa struttura definisce l'intestazione del messaggio di 4 byte e una sezione parametro 4 byte.

Figura 3: Formato di messaggio di identificazione automatica CANaerospace

A prima vista, l'impiego del 50% del payload del messaggio CAN per scopi diversi da quelli di trasmissione dati operativi, può sembrare inefficiente e uno spreco di banda. Tuttavia, l'intestazione (header) del messaggio CANaerospace fornisce preziose informazioni che comunque richiederebbero l'uso di payload bytes del messaggio se realizzato in altri modi: L'intestazione consente alle stazioni riceventi di analizzare immediatamente i messaggi ricevuti rispetto alla provenienza, il tipo di dati, l'integrità e ora di creazione. Per realizzare questo, è necessaria alcun´altra informazione, se non la conoscenza del identificatore CAN per il particolare sistema. I byte di intestazione dei messaggi hanno il seguente significato:

Node ID: Indica l'indirizzo del nodo trasmettitore nel caso di messaggi EED/NOD (comunicazione ATM) e in caso di comunicazioni PTP, del destinatario per messaggi NSL/NSH. Node ID "0" viene utilizzato per messaggistica del tipo broadcast.

Data Type: Specifica come il payload del messaggio deve essere interpretato in relazione al suo tipo di dati (ossia dati a virgola mobile o il numero di byte nel caso di dati intero). Il corrispondente data type è tratto dalla lista CANaerospace Data Type che permette anche data types definito dall'utente.

Service Code: Per il normale funzionamento dati (NOD) il Service Code fornisce informazioni circa l'integrità dei parametri trasmessi con il messaggio. Questo può essere il risultato di un continuo built-in test di un sensore, il flag di validità corrente di un segnale di navigazione o di altre informazioni di parametri specifici. In caso di comunicazione PTP, il Service Code specifica il servizio corrispondente alla interazione cliente/server.

Message Code: Per il normale funzionamento dati (NOD), il Message Code viene incrementato di uno per ogni messaggio con un particolare identificativo CAN del nodo trasmittente. Dopo aver raggiunto il valore di 255, il Messaggio Code torna a zero. Questo consente alle stazioni riceventi di determinare messaggi mancanti o in ritardo e di reagire di conseguenza. Per quanto riguarda la comunicazione PTP (NSH, NSL) il Message Code è usato in combinazione con il Service Code per specificare in modo più dettagliato il servizio corrispondente alla interazione cliente/server

Le suddette informazioni contenute nell'intestazione del messaggio CANaerospace contiene informazioni importanti per determinare l'integrità dei parametri per l'uso in sistemi mission critical del volo e supporta la ridondanza del sistema. Inoltre, migliora in modo significativo l'interoperabilità tra le LRU di produttori differenti e consente il monitoraggio delle reti CANaerospace relativa allo status dei LRU collegato ad esso. Per incrementare l'interoperabilità, CANaerospace definisce assi specifiche aerospaziali con le convenzioni segno corrispondente e unità fisiche. Insieme con la lista predefinita di identificatore CAN, queste definizioni descrivono il traffico in una rete CANaerospace in modo univoco. La lista assegnazione di identificatori standard CANaerospace riserva gli identificatori CAN tra 300 e 1799 e assegna a loro i parametri come illustrato nel esempio di questa lista (Figura 4).

Figura 4: Esempio dalla lista assegnazione di identificatore standard di CANaerospace V 1.7

I progettisti di sistemi possono utilizzare liste di assegnazione di identificatore auto definite. L'obbligatorio "Node Identification Service", a cui ogni LRU CANaerospace deve rispondere, permette di eseguire la scansione della rete per la ricerca di LRU e il loro relativo codice di lista di identificativi al fine di evitare incoerenze. La lista assegnazione di identificatori standard CANaerospace, nonché le liste per i tipi di dati e unità fornisce sezioni definite dall'utente che possono essere utilizzati da progettisti di sistemi per espandere tali liste in base alle loro esigenze.

Gestione larghezza di banda

Una caratteristica essenziale dei sistemi mission e safety critical di volo è che il loro comportamento deve essere definito con precisione, analizzati e testati per soddisfare i requisiti di certificazione formali. Il grado di precisione richiesta per il timing è specifica per ogni applicazione e deve essere quantificata mediante l'analisi del sistema. L'obiettivo finale da raggiungere, tuttavia, è che si possa dimostrare alle autorità di certificazione (cioè FAA, EASA) che un sistema safety critical si comporta come previsto in circostanze prevedibili. Utilizzando CANaerospace, questa prevedibilità può essere raggiunta.

CANaerospace espone un concetto di gestione della larghezza di banda disponibile su una rete CAN multi-drop per garantire un comportamento prevedibile per comunicazioni ATM e PTP che si chiama Time Triggered Bus Scheduling. Time Triggered Bus Scheduling si basa su una limitazione del numero di messaggi CAN che ogni nodo della rete può trasmettere in un arco di tempo minore (Minor Time Frame). L'arco di tempo minore viene definito durante la progettazione iniziale del sistema. Il numero massimo di messaggi trasmessi entro un lasso di tempo minore potrebbe essere diverso da nodo a nodo e contenere il potenziale di crescita, se garantito e previsto allo stadio iniziale di progettazione del sistema. È fondamentale per il concetto di Time Triggered Bus Scheduling che in ogni momento durante la generazione del traffico di rete ogni nodo della rete aderisce al proprio elenco di trasmissione. Non è richiesto ne vietato, comunque, che nodi della rete sincronizzino altri nodi riguardanti l'ordine di trasmissione del loro messaggio o tempi di trasmissione.

CAN error frames possono portare a comportamenti imprevedibili se la larghezza di banda è consumata da pacchetti danneggiati attribuiti a difetti della rete o nodi collegati ad essa. Pertanto, CANaerospace raccomanda di limitare il consumo di banda al 50% della larghezza di banda massima in modo che l'imprevedibilità sia mitigata. Mentre il Time Triggered Bus Scheduling richiede margini e non ottimizza l'utilizzo della banda di rete, fornisce un approccio sicuro e semplice per sviluppare e costruire sistemi certificabili. Per garantire questo in condizioni di guasto, il progettista del sistema deve definire il comportamento in queste condizioni (pacchetti danneggiati e evitare l'inversione delle priorità). Applicando il concetto di Time Triggered Bus Scheduling, può essere dimostrato che una rete CANaerospace si comporti come previsto. In Figura 5 viene mostrato la schedulazione di trasmissione di una rete CANaerospace con due nodi che trasmettono i loro messaggi in modo asincrono, in modo alternato e, a volte casuali nel loro arco di tempo minore (caso peggiore). Questo esempio utilizza il 50% della larghezza di banda massima.

Figure 5: Schema semplificato della trasmissione CANaerospace

Con l'utilizzo del Time Triggered Bus Scheduling, nessun messaggio in questo elenco di trasmissione ha una latenza superiore al 50% di un arco di tempo minore più la durata del messaggio più lungo. Time Triggered Bus Scheduling riduce l'impatto sulle priorità di messaggio dovuta al fatto che i nodi della rete sono tenuti a contare le loro trasmissioni di messaggi. Time Triggered Bus Scheduling garantisce una flessibilità sufficiente per aumentare il traffico di rete durante la vita del sistema in caso è previsto un potenziale di crescita. Per esempio, il sistema permetterà l'integrazione di nuovi nodi nella rete senza influenzare i nodi esistenti. Inoltre, il comportamento prevedibile applicate dal Time Triggered Bus Scheduling consente ai sistemi con diverso livello di criticità di coesistere sulla stessa rete.

Note

1. CANaerospace Specification, su stockflightsystems.com, Stock Flight Systems. URL consultato il 17 dicembre 2010.
2. www.stockflightsystems.com.
3. NASA AGATE Data Bus Specification, su stockflightsystems.com, NASA. URL consultato il 17 dicembre 2010.
4. Solutions for Avionics Networking su www.avionics-networking.com.

Portale Aviazione: accedi alle voci di Wikipedia che trattano di aviazione