Da sempre la ricerca tecnologica nel settore aerospaziale ha portato importanti innovazioni nelle applicazioni consumer. Tuttavia di recente, la crescente complessità di queste, da un lato, e la necessità di contenere i costi di sviluppo delle apparecchiature di volo, dall'altro, hanno spinto i progettisti dei sistemi di bordo ad attingere - ove ve ne fossero i presupposti - alle soluzioni sviluppate per i settori industriale e commerciale, eventualmente adattandone in parte utilizzi e specifiche. Uno degli ambiti in cui tale tendenza appare sempre più evidente è quello dei sistemi di controllo e comunicazione. In ambito spaziale, tali sistemi devono essere caratterizzati da una serie di proprietà che includono, ad esempio, elevato data-rate, bassa latenza, semplicità del protocollo, supporto per applicazioni real-time, facilità di installazione, affidabilità e tolleranza ai fault. In realtà tali caratteristiche si riscontrano oggi anche in molte soluzioni adottate nel settore automotive. In tale settore, ad esempio, è stato di recente definito il nuovo protocollo FlexRay che presenta interessanti proprietà proprio per lo spazio.
Considerazioni generali
Anche nel settore aerospaziale la crescente complessità dei sistemi ha determinato la diffusione di architetture distribuite. In tal caso, la selezione del bus di connessione rappresenta un aspetto cruciale per soddisfare requisisti di prestazioni e affidabilità. In generale i sistemi di comunicazione possono essere distinti in event-triggered e time-triggered. Nel primo caso, le informazioni sono trasmesse solo su richiesta di un host, in risposta ad una precisa necessità; un esempio piuttosto noto di tali architetture è rappresentato dall'Ethernet. Nel secondo caso, invece, le comunicazioni avvengono su precisa base temporale e in accordo a uno schema condiviso e riconosciuto tra tutti i nodi della rete; la stessa sequenza è ripetuta periodicamente definendo una struttura ciclica dei messaggi. I nodi condividono un segnale di sincronizzazione che può essere distribuito da un master della rete o piuttosto mediante una combinazione di messaggi dedicati inviati da diversi nodi. La scelta tra i due diversi approcci dipende evidentemente da considerazioni a livello sistema. I sistemi time-triggered, ad esempio, garantiscono che l'occupazione del bus sia costante, evitando contenziosi tra i nodi - il che è piuttosto utile in applicazioni di controllo in tempo reale come nel caso dei sistemi di controllo di assetto del satellite - e garantiscono quindi predicibilità e massima latenza nello smistamento dei messaggi; tuttavia presuppongono che nel caso in cui sia aggiunto alla rete un nodo, l'intera pianificazione dei messaggi sia ridefinita. Inoltre non realizzano l'uso più efficiente della banda di trasmissione disponibile, in quanto la allocano staticamente ai nodi connessi alla rete, i quali però potrebbero non avere necessità di trasferire dati all'interno della finestra temporale a essi associata. Nei sistemi event-triggered è possibile invece modificare dinamicamente l'allocazione di banda in funzione della configurazione corrente. Uno degli esempi più evidenti in questo senso è rappresentato dalla acquisizione e trasmissione di immagini. Il processo tipicamente non è sempre attivo ma, quando lo è, richiede elevata banda; l'utilizzo di un protocollo time-triggered impone una elevata capacità di buffering locale nel sistema di acquisizione. I principali bus di tipo seriale che vengono utilizzati o, più in generale, possono essere tenuti in considerazioni per applicazioni spaziali sono: Mil-Std-1553, SafeBus, Ttp/C, FlexRay, Can/Ttcan, SpaceWire, Ethernet, FibreChannel. Le caratteristiche principali di tali bus sono presentate di seguito.
Mil-Std-1553
Il Mil-Std-1553 è un protocollo di comunicazione nato in ambito militare; la prima revisione è stata pubblicata nel 1978. Il primo utilizzo si è avuto a bordo degli F-16 e degli elicotteri Apache AH-64A ; in ambito spaziale è ancora oggi usato su diversi satelliti, a bordo dello Space Shuttle e della Stazione Spaziale. Il protocollo - di tipo “time-division command/response multiplex” - si basa su un semplice meccanismo comando/ risposta. La comunicazione è di tipo half-duplex ed event-triggered; sono previsti comandi di sincronizzazione di tipo broadcast ma non è espressamente supportata la definizione di un tempo globale del sistema. Il mezzo di trasmissione è un doppino twistato schermato con stub per la connessione dei nodi alla rete con una topologia di tipo multidrop; è prevista anche una configurazione ridondata mediante due connessioni indipendenti. I livelli fisici sono compresi tra 18 e 27 V; è utilizzata la codifica Manchester del segnale. Il data rate massimo è 1 Mbps. Per le applicazioni spaziali, sono già disponibili dispositivi tolleranti a radiazione e qualificati in accordo ai metodi Mil-Std-883; esistono inoltre core IP per Fpga qualificate per impiego nello spazio. I sistemi Mil-Std-1553 sono sempre stati considerati piuttosto robusti e per questo utilizzati su diverse piattaforme; il data rate limitato tuttavia ne preclude l'impiego nei sistemi di nuova generazione. Recentemente è stata emessa una versione aggiornata dello standard definita Ebr-1553 che dovrebbe assicurare data rate fino a 10 MBps; è stata studiata anche una estensione Mil-Std-1773 su fibra ottica che tuttavia limita sempre il data rate a 1 Mbps e non ha quindi trovato largo utilizzo.
SafeBus
SafeBus è il protocollo originariamente sviluppato da Honeywell per il impiego a bordo dei Boeing 777; successivamente è stato standardizzato per applicazioni avioniche come Arinc 659. Prevede una connessione su backplane di fino a 8 nodi di cui 4 con capacità di elaborazione dati e 4 per operazioni di I/O per la comunicazione con periferiche che supportino protocolli diversi. Il bus di connessione comprende due linee dati ed una linea di clock con una ridondanza quadrupla. Sono previsti nodi 'ombra' in ridondanza calda in grado di intervenire in presenza di errori del nodo primario. Il data-rate massimo sostenibile è 60 Mbps su distanze fino a 1,5 metri; il mezzo fisico è rame, il livello fisico sono Ieee 1194.1. La comunicazione è time-triggered e l'accesso al mezzo fisico è quindi di tipo Tdma senza arbitraggio; è prevista una sincronizzazione dei clock ai nodi ed una base dei tempi globale. La latenza è tipicamente contenuta entro due periodi di bit. Il protocollo Arinc 659 è disponibile pubblicamente ma soggetto a licenza; lo standard SafeBus invece è proprietario e rappresenta attualmente la principale implementazione del protocollo Arinc 659.
Ttp/C
Ttp/C (Time Triggered Protocol/Class C) è un protocollo di comunicazione sincrono tollerante ai fault sviluppato dalla Università di Vienna e da TTTech per applicazioni real-time in sistemi distribuiti; è attualmente utilizzato su diverse piattaforme per veicoli con equipaggio, ad esempio nei sistemi di controllo elettronico dei motori a bordo degli aerei F-16 Lockheed Martin. Il protocollo è di tipo time-triggered. Non definisce esplicitamente un mezzo fisico di trasmissione; supporta comunicazioni su cavo con livello fisico RS485 (fino a 5 Mbps) o compatibile con le specifiche Ethernet (fino a 25 Mbps). Esistono anche implementazioni su fibra ottica. La comunicazione è half-duplex; la modalità di accesso al mezzo fisico Tdma. È prevista una sincronizzazione fine dei clock ai nodi, con una base dei tempi globale distribuita mediante una architettura fault-tolerant senza master. La latenza è programmabile e fino a 10 us. La topologia della rete è multi-drop oppure punto-punto con il supporto di hub per configurazioni a stella; il numero massimo di nodi connesso al bus è 64. È espressamente progettato per applicazioni critiche dal punto di vista della sicurezza, prevedendo una ridondanza duale che si applica anche a livello di nodi e task (ridondanza hardware/software). Può operare in modalità fault-tolerant garantendo tolleranza a singolo fault. Sono previsti meccanismi hardware di contenimento dei fault e 'bus guardian' per isolare 'babbling idiot'. Sono disponibili core IP per implementazioni in Fpga qualificate per applicazioni spaziali.
FlexRay
FlexRay è un bus per applicazioni x-by-wire in ambito automotive introdotto dall'omonimo consorzio formato nel 2000 da Bmw, Bosch, Daimler, Freescale, General Motors, Nxp Semiconductors e Volkswagen. È espressamente progettato per applicazioni critiche, come appunto i controlli di attuazione mediante filo (quali ad esempio il controllo della frenata o della sterzata nelle autovetture). Sono previsti per questo meccanismi di tolleranza e contenimento dei fault e bus guardian. Lo standard supporta meccanismi di comunicazione time-triggered ed event-triggered. Implementazioni tipiche prevedono un periodo base con una finestra temporale per l'invio di messaggi statici secondo uno schema time-triggered e una per messaggi dinamici event-triggered. Il mezzo fisico è un doppino twistato; la massima lunghezza del bus è specificata in fino a 24 metri. La topologia della rete è di tipo multidrop o punto-punto, anche in questo caso con supporto di hub per connessioni a stella. Il numero massimo di nodi che possono essere connessi al bus è 64. Per le connessioni per l'invio di messaggi statici può essere implementata ridondanza a livello fisico. Il data-rate massimo sostenuto è 10 Mbps (20 Mbps se si utilizzano connessioni ridondate). La comunicazione è di tipo half-duplex, la modalità di accesso al mezzo fisico Tdma per i messaggi statici; nelle finestre dinamiche, invece, sono previsti mini-slot di trasmissione con arbitraggio sul bus. Sono previsti una base globale dei tempi ed un meccanismo di sincronizzazione; è garantita latenza programmabile nella spedizione dei messaggi fino a 6 us. Sono disponibili core IP per Fpga qualificate per applicazioni spaziali.
Can/Ttcan
Can (Controller Area Network) è il protocollo introdotto in ambito industriale da Robert Bosch per la connessioni di Ecu in rete. Il protocollo è di tipo event triggered. Supporta diversi livelli fisici tra cui una implementazione standard su due fili con uno schema bilanciato o compatibile con le specifiche RS485; questa è diffusamente utilizzata nel settore spaziale. La massima capacità di trasmissione è tipicamente specificata in 1 Mbps; la versione low-speed opera a 125 Kbps ma è tollerante ad un eventuale fault in una delle linee di connessione. La comunicazione è di tipo half-duplex. La configurazione del bus è di tipo multidrop; è previsto supporto per applicazioni con hot-swap. Ttcan (Time-Triggered Communication on Can - Iso 11898-4) è una estensione del protocollo Can per il supporto di applicazioni time-triggered. Prevede finestre di trasmissione esclusive con accesso Tdma al mezzo di trasmissione e con arbitraggio; in questo caso l'accesso è regolato mediante uno schema Csma/CD+Amp. Sono previste modalità di sincronizzazione dei clock ai nodi, ad esempio mediante invio di messaggio di riferimento da parte di un nodo dedicato. La latenza di trasmissione è inferiore a 100 us. Il protocollo può essere utilizzato solo su sistemi Can che supportino la possibilità di disabilitare le funzionalità di ritrasmissione del messaggio.
SpaceWire
SpaceWire è il protocollo di comunicazione per applicazioni spaziali definito e correntemente supportato dall'Agenzia Spaziale Europea; diffusamente utilizzato in diversi programmi è basato sugli standard commerciali Ieee 1355 e Lvds, opportunamente adattati per il settore spaziale. La connessione è di tipo punto-punto e supporta una comunicazione bidirezionale full-duplex. Strutture switched-fabric possono essere realizzate mediante router. Il mezzo di connessione è un cavo standard con quattro doppini. Il protocollo di comunicazione è event-triggered; il controllo di flusso è basato sul concetto di 'credito' del nodo ricevente. Il data-rate massimo è fino a 400 Mbps (100 Mbps su distanze fino a 10 metri). È previsto controllo di parità sui singoli byte trasmessi. La latenza di trasmissione non è specificata, e dipende fortemente dalla topologia della rete; indicazioni generali riportano un valore massimo inferiore a 10 µs. Non è prevista alcuna ridondanza intrinseca né tolleranza ai fault; non sono previsti modi di contenimento dei fault o soluzioni per isolare nodi 'babbling idiots'. Eventuali nodi in condizione di errore possono essere riconosciuti solo mediante i meccanismi di disconnessione automatica del link; gli errori sono riportati ai livelli superiori del protocollo (non coperti dallo standard) entro 1 µs. Anche per lo standard SpaceWire, come per altri in precedenza, sono attualmente disponibili dispositivi tolleranti a radiazione che implementano controller di nodo e core IP per Fpga qualificate; le specifiche del protocollo sono liberamente accessibili e non soggette a royalties.
Ethernet
Ethernet, altrimenti noto come Ieee 802.3, è forse il più diffuso tra i sistemi di comunicazione per la realizzazione di reti Lan in applicazioni non critiche anche in ambito spaziale; è ampiamente utilizzato, ad esempio, a bordo della Stazione Spaziale. Il protocollo è di tipo event-triggered e supporta comunicazioni sia half-duplex che full-duplex. Il mezzo di connessione è un doppino twistato; l'accesso ad esso è di tipo Csma/CD (Carrier Sense Multiple Access with Collision Detection) in configurazione half-duplex, diretto in configurazione full-duplex. La connessione fisica è di tipo punto-punto; reti complesse di tipo switched o ad albero possono essere costruite mediante hub/router. La massima lunghezza di un singolo segmento di rete è fino a 100 metri; il data-rate massimo sostenibile è fino a 100 Mbps. Non è previsto alcun meccanismo di sincronizzazione dei nodi o distribuzione del tempo globale; in configurazione half-duplex la latenza di trasmissione è fino a 50 us e fortemente dipendente dall'occupazione della rete. Non sono previste o, comunque, espressamente definite procedure di gestione e contenimento dei fault; è prevista ritrasmissione automatica al livello Mac nel caso di collisioni nell'accesso al mezzo e in caso di perdita dei dati a livello Udp o Tcp. Non è previsto alcun meccanismo esplicito che permetta di comunicare consistentemente e con bassa latenza ai livelli superiori la presenza di eventuali nodi in errore. A seguito della grande diffusione dello standard, ne sono stati definiti diversi adattamenti ed aggiornamenti. Lo standard Gigabit Ethernet, ad esempio, eredita il protocollo Ieee 802.3 ma adotta il layer fisico definito dallo standard FibreChannel; consente trasferimenti dati fino a 10 Gbps in modalità half-duplex (fino a 1 Gbps) o full-duplex su distanze fino a 40 km su fibra ottica (5 km nella configurazione a 1 Gbps). L'Afdx (Avionics Full-Duplex Switched Ethernet), invece, utilizza il physical layer dello standard Arinc 664 - Part 7; la specifica è stata sviluppata da Airbus Industries per applicazioni a bordo di aeromobili commerciali (quali, ad esempio, l'Airbus A380 ed il Boeing 787).
Fibre Channel
Progettato principalmente per la realizzazione di sistemi di memoria di massa e reti distribuite in ambito industriale, lo standard FibreChannel ha successivamente trovato applicazioni anche in ambito avionico e militare; è stato selezionato, ad esempio, per l'impiego a bordo dello Join Strike Fighter. Definisce un protocollo event-triggered con capacità di trasmissione dati fino a 10 Gbps. I transceiver hanno specifiche dedicate; il mezzo di connessione è in rame fino a 30 metri o fibra ottica su lunghe distanze (oltre 2 km). Supporta configurazione punto-punto, di tipo 'arbitration loop', ad albero mediante hub o switched fabric; prevede trasmissioni broadcast. La comunicazione è full-duplex; il controllo di flusso e l'accesso al mezzo sono basati sul meccanismo dei crediti. Non è prevista sincronizzazione dei nodi; la latenza di trasmissione è piuttosto bassa ma dipende fortemente dalle caratteristiche della rete e dal traffico dati. Il numero massimo di nodi che possono essere connessi su un singolo loop di arbitraggio è 126; su una rete switched il numero massimo di unità logiche è 224 milioni.
Lo standard non prevede ridondanza intrinseca, ma comunque la rete è in grado di funzionare in presenza di un nodo in errore; non sono previsti meccanismi di contenimento del fault o di isolamento di nodi 'babbling idiot'. Esistono implementazioni del protocollo su Fpga tolleranti a radiazione; sono stati qualificati transceiver e fibre ottiche per applicazioni nello spazio.
I vantaggi dello standard FlexRay
Diversi sono i vantaggi dello standard FlexRay che ne fanno un interessante candidato per la realizzazione dei sistemi di comunicazione seriale a bordo dei satelliti di prossima generazione. Uno degli aspetti principali è ad esempio la disponibilità di una significativa capacità di trasmissione dati (fino a 20 Mbps con, come detto, una connessione ridondata) su mezzi in rame; questo consente di collassare su un'unica infrastruttura le principali comunicazione di bordo riducendo complessità e costi di installazione delle connessioni fisiche e migliorando quindi l'affidabilità dell'intero sistema. Le architetture fino ad oggi utilizzate come Can e Mil-STD-1553 sono invece limitate, come abbiamo visto, a data-rate inferiori a 1 Mbps. Tra i sistemi di connessione in rame descritti in precedenza solo Ethernet e SpaceWire raggiungono data-rate più elevati ma, come vedremo in seguito, mancano di alcune caratteristiche importanti. L'utilizzo di fibre ottiche, invece, non è ancora significativamente diffuso nel settore spaziale prevalentemente per problemi di affidabilità e qualifica. Interessante, inoltre, è la possibilità di supportare livelli fisici RS485 nei sistemi FlexRay; esistono infatti attualmente diverse implementazioni del Can bus su questa stessa tecnologia e quindi soluzioni già qualificate per applicazioni nello spazio che potrebbero essere riutilizzate. Anche il Ttp/C supporta tale livello fisico ma con data-rate fino a 5 Mbps. Esiste inoltre una implementazione Low Voltage Electrical Signaling (con segnali di ampiezza da 600 mV a massimo 2 V picco-picco) proprietaria di Philips caratterizzata da bassa dissipazione; in ogni caso la dissipazione di una rete FlexRay è inferiore a quanto si ha, ad esempio, con altri bus, quali il Mil-Std-1553. Infine, sebbene inoltre non sia espressamente richiesta dallo standard, è supportata anche una configurazione con isolamento galvanico che spesso risulta necessaria in ambito spaziale. Il supporto di un protocollo time-triggered nello standard FlexRay consente inoltre la realizzazione di una architettura time-scheduled sulla quale si basano tipicamente i sistemi di controllo; caratteristiche simili sono presenti anche nei specifiche Ttp/C e Ttcan ma non, ad esempio, nelle reti Ethernet. Diversamente dal Ttp/C, che tra quelli elencati in precedenza è forse quello più vicino per caratteristiche e prestazioni, il protocollo FlexRay consente di supportare in una stessa soluzione messaggistica di tipo sincrono ed asincrono. Nella Figura è riportato un tipico esempio di comunicazione sul bus. Come si vede, alla fase sincrona gestita in Tdma segue una fase asincrona in cui nodi che richiedano flussi dati ad elevato data-rate possono trasferire informazioni su slot temporali di lunghezza diversa. I due canali possono inoltre essere utilizzati per trasferire simultaneamente informazioni tra nodi diversi come nel caso del nodo verde che trasmette nello slot temporale 7 in contemporanea con il nodo giallo e poi da solo nell'intervallo temporale 12. Inoltre, questa stessa flessibilità consente di allocare per uno stesso nodo, anche all'interno di una comunicazione sincrona, due slot temporali consecutivi, il che evita, nel caso di dispositivi che richiedano data rate più elevato, di dover ricorrere a buffer dati di grosse dimensioni nei nodi periferici. Inoltre lo scheduling delle comunicazione sul bus non deve essere definito in ogni nodo ma viene configurato in questi al power-up del bus, il che ovviamente semplifica la realizzazione delle architetture più complesse evitando di dover riprogrammare ogni nodo qualora sia necessario modificare la sequenza dei messaggi. L'architettura FlexRay garantisce inoltre il supporto per tolleranza ai fault e contenimento di questi con una soluzione del tutto scalabile in funzione dei requisiti utente. Supporta per questo topologie di rete diverse; è inoltre prevista una distribuzione efficiente della sincronizzazione dei nodi che, grazie ad una soluzione multimaster con correzione di rate e offset, consente la sincronizzazione con precisione di 1 µs e un gap interframe di 10 µs. Lo standard Ttp/C invece implementa soltanto correzione di offset del clock per la sincronizzazione. Tali caratteristiche sono invece assenti nei sistemi Ethernet mentre sono implementate negli altri sistemi sebbene con soluzioni più semplici e meno affidabili.
