CANaerospace è un protocollo di alto livello basato su Controller Area Network (CAN), che è stato sviluppato da Stock Flight Systemswww.stockflightsystems.com. 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 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 UAVSolutions for Avionics Networking su www.avionics-networking.com.. 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 ridondanza, 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