Reti per il mondo dei trasporti

• 
• Tweet
• Pin It
• Condividi per email

Sistemi e dispositivi dotati di tecnologie ‘smart’ hanno di fatto soppiantato l’utilizzo di sistemi e reti tradizionali nel settore dei trasporti. Vediamo il caso dei tre ambiti automotive, ferroviario e aerospace

La rapida evoluzione della tecnologia, unitamente all’incremento della competitività del mercato dei sistemi informatici hanno condotto a una graduale trasformazione delle dinamiche commerciali del settore trasporti, con l’adozione di tecnologie sempre più ‘smart’ destinate a soppiantare sistemi e reti tradizionali. I principali ambiti che verranno qui considerati sono: automotive, ferroviario e aerospace.

AUTOMOTIVE

Le automobili, come in generale ogni veicolo su strada, sono ormai dotate di sistemi elettronici e informatici complessi, nei quali coesistono svariati oggetti smart, che condividono informazioni e compiti. Si va dai sensori intelligenti alle vere e proprie centraline di controllo dedicate a specifiche funzioni, per esempio gestione motore, sicurezza ABS, ESP, dispositivi per l’infotainment ecc.: si parla sempre più di ‘intelligenza distribuita’. Come condividere le informazioni fra i molti dispositivi di cui è equipaggiata un’auto è un’interessante sfida progettuale, perché bisogna connettere tutti gli apparati, possibilmente senza utilizzare troppi cavi e, soprattutto, senza dover ricablare o riconfigurare la rete ogni volta che si aggiunge o rimuove un dispositivo. Inoltre, è necessario garantire che il mezzo sia sicuro e quindi siano disponibili tutti i dati in tempo reale e senza conflitti di comunicazione, in modo che qualunque azione effettuata non crei una situazione di pericolo per i passeggeri. Con l’aumento dei dispositivi di bordo con funzioni di controllo, sicurezza e comfort, si è reso necessario semplificare e ridurre il cablaggio: diminuire la componente rame significa per esempio ridurre costi e peso. Questo problema è stato affrontato negli anni ‘80 dall’azienda Robert Bosh con la definizione del bus CAN, in grado di integrare caratteristiche di semplicità, robustezza e sicurezza, tanto da divenire uno standard di fatto del mondo automotive, diffondendosi poi anche nell’ambito dell’automazione industriale.

Focus sulla rete CAN

Una rete CAN nella sua versione tradizionale è composta da un bus lineare realizzato con una coppia intrecciata di fili (schermati o meno) e da un numero teoricamente infinito di interfacce (nodi), collegate fra loro attraverso questo mezzo trasmissivo. Il bus non viene occupato secondo uno schema predefinito; tutti i componenti collegati sul bus hanno gli stessi diritti, ascoltano in parallelo tutti i messaggi, sono sempre pronti a ricevere e, quando necessario, cominciano a trasmettere se nessun altro componente sta inviando messaggi sul bus. Si tratta di una comunicazione di tipo event-driven, ossia viene inizializzata solo quando richiesto dall’applicazione (gestita dagli eventi del nodo) e trasmessa se il bus è libero. CAN appartiene alla categoria dei protocolli detti producer-consumer, in cui tutti i nodi della rete possono teoricamente essere in grado di inviare dati sul bus e tutti possono ricevere qualsiasi messaggio (si parla anche di broadcasting dei messaggi). I nodi non hanno un proprio indirizzo specifico (per questo il CAN è definito come protocollo Message-based anziché Address-based), quindi l’informazione di indirizzo è contenuta nel campo ‘Identifier’ del frame trasmesso; questo identificatore viene utilizzato da tutti i nodi della rete per controllare se i dati trasportati dal frame sono o meno di loro competenza. CAN si basa quindi sul contenuto di una comunicazione che viene contrassegnata da questo identificatore. L’identificatore trasmesso viene utilizzato anche per stabilire la priorità di trasmissione del messaggio in caso di contemporaneità di accesso al bus. Non essendoci, come detto, uno schema predefinito di accesso al bus, è necessario utilizzare una tecnica di arbitraggio che decida quale messaggio può accedere al bus per primo, nel caso di una contemporanea richiesta di accesso. Il bit rate raggiungibile dal bus è pari a 1 Mbps con una linea di circa 40 m.

 – CAN, LIN e Most

CAN (Controller Area Network) è un protocollo di comunicazione seriale asincrono in grado di gestire con elevata efficienza sistemi di controllo distribuiti, con un elevato livello di sicurezza e di integrità dei dati trasmessi (si veda figura 1). Progettato per funzionare nei sistemi distribuiti, LIN (Local Interconnect Network) è un altro protocollo di comunicazione seriale asincrono che viene normalmente utilizzato come sottorete locale alla rete bus principale. Forma così un sistema a elettronica distribuita, a basso costo, interconnettendo vari componenti, principalmente sensori e attuatori di tipo smart, soprattutto in applicazioni automotive. Il protocollo LIN non intende sostituire i protocolli esistenti, quali TTP-Time Triggered Protocol, CAN, FlexRay, Byteflight ecc., bensì completarli. Questo protocollo può essere utile quando le caratteristiche e la versatilità dei protocolli citati non sono richieste: si formano così delle sottoreti locali per gestire il traffico dati scambiato in ambito, appunto, locale. Una sottorete LIN può essere installata, per esempio, all’interno di una portiera, nei sedili, nel cofano posteriore dell’auto e via dicendo, ovvero dove si ha la necessità di gestire un traffico dati proveniente da un sistema di tipo sensore-attuatore, e dove non occorre avere elevate velocità di trasmissione. Fra gli altri protocolli presenti sui veicoli figura il Most (Media oriented systems transport), che è stato progettato per le applicazioni multimediali in campo automotive e prevede anche l’utilizzo di fibra ottica come mezzo trasmissivo, per cui il bit rate che è in grado di fornire è piuttosto elevato: circa 23 Mbps. Most rappresenta oggi una soluzione di tipo ottico per sistemi multimediali di bordo, quali lettori CD e DVD, radio e sistemi di navigazione GPS.

 – FlexRay

FlexRay invece è un bus di comunicazione ad alta velocità per reti interne al veicolo, definito nel 1999 da un consorzio di aziende fra le quali BMW, DaimlerChrysler e Freescale, partendo dalla solida base fornita dal Byteflight. Il mezzo trasmissivo prevede 2 canali di comunicazione in grado di fornire una velocità pari a 10 Mbps; questi canali possono essere utilizzati insieme, in modo da introdurre un meccanismo di ridondanza che fa di FlexRay un bus estremamente veloce e affidabile, oppure indipendentemente l’uno dall’altro, permettendo di raggiungere una velocità aggregata pari a 20 Mbps. È un protocollo con tolleranza ai guasti (fault-tolerant), con meccanismo di sincronizzazione tra i nodi di rete e ampia larghezza di banda. Importante notare il comportamento deterministico: nel protocollo FlexRay i messaggi sono divisi in sincroni, trattati in modo deterministico con una schedulazione basata su slot temporali rigidamente definiti, e asincroni, usati per gestire messaggi associati a particolari eventi non sincroni. Ogni dispositivo gestito con questo protocollo ha associato uno slot temporale che si ripete periodicamente con una schedulazione predefinita, durante la quale esso ha accesso esclusivo al bus. Queste finestre temporali sono appunto quelle utilizzate per attuare questo comportamento deterministico. Durante la configurazione di un sistema basato su FlexRay è necessario impostare la lunghezza del ‘communication cycle period’, il quale è suddiviso in due finestre temporali: statica e dinamica. La prima è riservata alle comunicazioni di tipo sincrono ed è in grado di garantire valori prefissati di latenza e jitter attraverso un meccanismo di sincronizzazione del clock tollerante ai guasti; la seconda invece è riservata ai messaggi triggerati sugli eventi, per i quali è previsto un meccanismo di priorità, simile a quello adottato dal CAN con l’identificatore, cioè impostando dei bit specifici nel campo header del messaggio. I messaggi FlexRay possono avere una lunghezza di frame variabile da 2 a 254 byte: un incremento significativo rispetto alla lunghezza di frame di 8 byte di CAN (standard). Come noto, CAN adotta una politica basata sulle priorità per la trasmissione dei messaggi, ciò significa che i messaggi di bassa priorità saranno inviati con ritardo (in caso di conflitto) rispetto ai messaggi di priorità maggiore. Con il determinismo significa che nulla avviene per caso: l’output corretto è sempre determinato dai corrispondenti input e questo in tutta la rete, facendola diventare un sistema predicibile. La sincronizzazione del clock è molto importante nell’architettura FlexRay al fine di garantire il comportamento deterministico. Quindi, grazie alle caratteristiche citate, il protocollo FlexRay è stato selezionato come il sistema maggiormente adatto a introdurre gestioni di tipo ‘x-by-wire’, in particolare ‘drive-by-wire’, ‘steer-by-wire’ e ‘brake-bywire’, sulle normali autovetture. ‘By-wire’ significa che i sistemi idraulici o meccanici tradizionalmente impiegati per svolgere le funzionalità citate vengono eliminati e sostituiti da sistemi meccatronici più leggeri, efficienti e maggiormente manutenibili. Questo tipo di tecnologia è stata introdotta per la prima volta nel settore avionico, dove è nota come ‘fly-by-wire’, con lo scopo di assistere il pilota nella guida dei velivoli. Su aeroplani militari, come l’F16, il pilota non è costretto ad agire con forza sulla pedaliera o sulla cloche, può invece agevolmente controllare il velivolo per mezzo di un joystick connesso a un bus, a sua volta connesso con attuatori meccatronici e sensori smart.

– TTP-Time Triggered Protocol

Da citare anche i protocolli TTP/A e TTP/C (Time Triggered Protocol per applicazioni in classe A e C). TTP/A si basa anch’esso su un’architettura ‘time-triggered’, cioè costituita da istanti temporali deterministici prestabiliti, utilizzando il tipo di comunicazione master-slave, dove il master impone la base dei tempi. In particolare, la tecnica di accesso al bus che viene utilizzata è Tdma-Time Division Multiple Access, cioè una tecnica di accesso multiplo a divisione di tempo di tipo deterministico a un unico mezzo trasmissivo (bus), la quale alloca, a ogni nodo, uno slot sufficiente a trasmettere un’unità informativa. Quindi, sia LIN che TTP/A utilizzano una comunicazione pianificata time triggered per ottenere comportamenti temporali predefiniti e per fornire un clock di sincronizzazione comune. Il funzionamento in tempo reale di un’architettura time-triggered rappresenta certamente la caratteristica più importante di questo protocollo. Tale architettura in automotive comprende normalmente due protocolli di comunicazione: TTP/C fault-tolerant e TTP/A low-cost.

I trend tecnologici del settore

Oggi le necessità del settore automotive sono chiare: un’architettura software-centrica basata sul paradigma SOA-Service Oriented Architecture, che sia in grado di gestire grandi quantità di dati e di resistere a cyberattacchi. Di fronte a queste necessità l’architettura CAN based, che è stata dominante per oltre 30 anni, mostra i suoi limiti, motivo per cui molti costruttori stanno migrando su tecnologie più moderne, come l’Automotive Ethernet nel campo dei bus di comunicazione e il 5G-LTE nella connettività V2X (Vehicle to Everything). Con l’avvento della guida semi-autonoma, degli Adas (Sistema Avanzato di Assistenza alla Guida), dell’infotainment avanzato e della connettività, l’automobile moderna monta una copiosa quantità di sensori e microcontrollori. Tali dispositivi presentano la necessità di collegamenti veloci e affidabili con una banda sempre più ampia, performance non soddisfacibili con standard come CAN o FlexRay. Inoltre, il trend attuale è di rendere ogni componente software di un’automobile come un SaaS-Software as a Service in analogia con il mondo del cloud computing. Si tratta di un modello di distribuzione di software in cui gli utenti accedono a un’applicazione attraverso Internet senza doverla installare o gestirla sui propri PC. Il software è ospitato su server remoti ed è gestito da un’azienda che lo offre come servizio a pagamento o gratuito tramite API. Tale paradigma in ambito automotive si chiama appunto SOA e porterà numerosi vantaggi in termini di efficienza, funzionalità, interoperabilità e riduzione dei costi della componentistica.

Parliamo del protocollo LIN

La topologia della rete LIN consiste in un singolo master e uno o più slave (le specifiche LIN raccomandano fino a 15 slave+1 master). Il master è il gestore di rete e dirige tutti i trasferimenti dati sul bus, di conseguenza non è necessario un sistema di arbitraggio (come esiste per CAN), quindi l’accesso al bus non è un problema. Ciò conduce a un comportamento di accesso al bus di tipo deterministico, garantendo tempi di latenza noti e specifici per i frame che transitano sulla rete LIN. La rete è realizzata utilizzando un cavo unico; la velocità di trasmissione non deve superare il valore specificato di 20 kbps e la maggior parte dei dispositivi dovrà sopportare velocità standard, per esempio 2.400, 9.600 e 19.200 bit/s. Il protocollo è costruito a partire dal protocollo Uart (Universal Asynchronous Receiver Transmitter): ciò significa che tutti i messaggi inviati al bus LIN sono codificati in byte in conformità, appunto, a questo protocollo.

FERROVIARIO

Storicamente le aziende di riferimento del comparto hanno costituito un oligopolio: tale condizione, anomala rispetto agli altri campi industriali, ha comportato un prolungato stallo tecnologico, che non ha agevolato lo sviluppo del settore. All’inizio di questo millennio il trend dell’automazione ferroviaria ha subito un cambio di direzione rispetto alla tendenza tradizionale, conducendo a una rapida evoluzione degli scenari. In particolare, i nuovi dispositivi installati sui rotabili hanno permesso di ottenere molte più informazioni riguardanti il sistema, fornendo così un contributo allo sviluppo gestionale del treno e apportando benefici in termini di sicurezza, affidabilità e comfort. L’apporto dei dispositivi elettronici e informatici a bordo treno ha determinato una rivoluzione del concetto di comunicazione per quanto concerne il sistema di interfaccia delle periferiche. È avvenuto, per esempio, un radicale cambiamento della filosofia di scambio dei segnali: prima avveniva per mezzo di un rigido cablaggio fisico, ora attraverso reti informatiche di comunicazione dati con la condivisione di risorse e dispositivi. Di fatto, l’applicazione di sistemi digitali per la comunicazione dati ha condotto a una drastica semplificazione dei collegamenti fisici, a fronte di un notevole incremento della complessità della programmazione software delle periferiche. Questo nuovo approccio riguarda molti fronti: dai sistemi di comunicazione a bordo treno a quelli tra treno e terra, fino ai sistemi di diagnostica, di distribuzione delle informazioni ai passeggeri e di manutenzione. Nel recente passato i produttori del settore hanno sviluppato autonomamente dei bus proprietari, atti a fornire un supporto ai sistemi Tcms-Train Control & Management System. Tuttavia, la necessaria flessibilità richiesta per accoppiare veicoli ferroviari differenti tra loro ha portato alla definizione dello standard TCN-Train Communication Network. Esso si compone di due livelli: per quanto riguarda la comunicazione tra i dispositivi di un medesimo treno, è stato definito il protocollo MVB-Multifunction Vehicle Bus, mentre per quanto riguarda l’interfaccia tra due o più treni si fa riferimento al protocollo WTBWire Train Bus (si vedano figure 3 e 4): i due protocolli hanno la possibilità di scambiarsi informazioni mediante un nodo di interfaccia denominato gateway.

– Tcms-Train Control & Management System

Il sistema Tcms costituisce il cervello e il sistema nervoso del treno: il suo scopo è far funzionare il treno con efficienza, avendo come priorità massima la sicurezza dei passeggeri. È di fatto un sistema centralizzato di supervisione di tutti i sottosistemi del treno: porte, illuminazione, condizionamento, freni, comunicazione con l’esterno, batterie, serbatoi dell’acqua, comfort e molto altro ancora. Si avvale di numerose interfacce uomo-macchina (HMI), che consentono di comunicare lo stato degli apparati del treno agli operatori umani, aggiungendo un’altra dimensione alla complessità del software Tcms. Le priorità riguardano la scelta dell’architettura più robusta e modulare, la semplificazione delle interfacce, la centralizzazione della logica di supervisione e l’utilizzo di software open source nello sviluppo. Le architetture moderne del Tcms pongono l’accento sulla modularità, cioè la capacità di inserire comodamente nella rete nuovo hardware che aggiunge funzionalità al treno. Inoltre, nuove forme di comunicazione wireless tra gli apparati del treno e le entità esterne (Train to Wayside Communication System) sono anch’esse in pieno sviluppo, in quanto consentono di implementare funzionalità avanzate di diagnostica predittiva oppure di efficienza energetica.

 – MVB-Multifunction Vehicle Bus

D’altra parte, MVB-Multifunction Vehicle Bus è il bus del veicolo e collega le apparecchiature di bordo veicolo e tra veicoli in un convoglio chiuso; offre un bit rate di 1,5 Mbps su tre mezzi trasmissivi: cavo RS485 per brevi distanze, linea bilanciata a 2 fili intrecciati accoppiati con trasformatore di linea per un massimo di 200 m, e fibra ottica per distanze fino a 2 km, soprattutto utilizzate in ambienti difficili (disturbi tipo EMC). Se è necessario aumentare la lunghezza del bus, i diversi mezzi possono essere interconnessi direttamente con dei ripetitori. MVB viene gestito da un nodo master dedicato, oppure da più master per aumentare la disponibilità dei nodi (si tratta di un sistema multi-master/multi-slave). Di conseguenza, presenta le stesse criticità operative che si riscontrano nelle reti deterministiche di quel tipo: un nodo master deve attendere di detenere il messaggio di token per comunicare, mentre un nodo slave deve attendere di essere interrogato se inserito nella lista di polling del master. MVB utilizza una robusta codifica Manchester e un Checksum evoluto per la rilevazione di errori; il protocollo è stato concepito come sistema a logica decentralizzata avente come metodo di accesso al bus quello di tipo deterministico, pertanto il bus risulta perennemente occupato e non accessibile in tempi casuali. La conseguenza principale di questo metodo è che un nodo, avente un dato considerato prioritario da trasmettere, deve attendere il proprio turno di interrogazione per poter comunicare tale informazione, rispettando i tempi di latenza stabiliti.

– WTB-Wire Train Bus

WTB-Wire Train Bus è stato progettato per interconnettere i veicoli tramite cavi e connettori di collegamento manuali o accoppiatori automatici, ideale quindi per i treni che cambiano frequentemente composizione. Un doppino intrecciato schermato permette di percorrere un massimo di 800 m di convoglio (senza ripetitore), collegare fino a 32 nodi, con un bit rate che dipende dalle costanti primarie del cavo. Considerando l’ambiente difficile della comunicazione dati, soprattutto dal punto di vista di compatibilità elettromagnetica, la presenza di connettori e conseguente discontinuità sul bus, con l’aggiunta e la rimozione di veicoli, viene normalmente utilizzato un processore di segnale digitale per la codifica Manchester del segnale. Una caratteristica saliente di WTB è la capacità di numerare automaticamente i nodi in ordine sequenziale e consentire a tutti i nodi di riconoscere quale sia il lato destro o sinistro del treno. Ogni volta che il treno presenta cambiamenti nella sua composizione, per esempio quando si aggiungono o rimuovono carrozze, i nodi del bus eseguono la procedura di inizializzazione che li connette operativamente, assegnando loro un indirizzo proprio, in ordine sequenziale; generalmente vi è un nodo per carrozza, ma potrebbero essere più di uno, oppure nessuno. Al termine della fase di inizializzazione tutte le carrozze vengono informate della nuova struttura WTB: indirizzo TCN proprio, orientamento lato destro/sinistro, posizione prima/dopo rispetto al master e numero e posizione degli altri nodi nel treno.

I trend tecnologici del settore

Recentemente, alcune analisi condotte sotto l’aspetto tecnico-economico sui protocolli di comunicazione utilizzati nel campo dell’automazione industriale hanno evidenziato che le potenzialità del protocollo CAN possono risultare vincenti anche per l’ambito ferroviario. In particolare, sono risultate adatte le peculiarità dello standard Canopen, che rende CAN deterministico, fra le quali: economicità di utilizzo, in quanto la tecnologia prevista non è proprietaria e non è richiesto alcun pagamento per la licenza; estrema affidabilità e sicurezza nello scambio di dati; flessibilità e customizzazione in base alle esigenze della singola applicazione. L’utilizzo su grande scala dello standard CAN/Canopen, dal settore trasporti a quello industriale, ha portato a un sensibile sviluppo della tecnologia e a un progressivo contenimento dei costi. Oggi, in aggiunta a canali di comunicazione tradizionali come MVB e CAN/Canopen, si studiano protocolli di nuova generazione basati su Ethernet.

Standard e normative nel ferroviario

I principali standard internazionali per il mondo ferroviario sono riferiti alle norme IEC61375 e UIC556. Nello specifico, IEC61375 (standard TCN) definisce l’architettura di comunicazione e i necessari protocolli per le comunicazioni a bordo treno e a livello di veicolo; è costituito da un sistema gerarchico a due livelli. UIC556 definisce invece la visione dell’operatore sul treno, la struttura per il coordinamento delle diverse applicazioni e la gestione operativa, per garantire l’interoperabilità tra veicoli di produttori diversi. Questa suite di protocolli è stata applicata con successo in ambito operativo su treni passeggeri e ad alta velocità, locomotive, treni suburbani, nonché tram. Negli anni ‘90 è nato un progetto congiunto fra diversi fornitori di sistemi ferroviari (ABB, AEG, Firema, Siemens ecc.) per sviluppare un prototipo comune, al fine di standardizzare una comunicazione di rete per applicazioni ferroviarie. Il risultato di questo progetto è la specifica hardware e software definita TCN-Train Communication Network. Successivamente, nel 1999, il TCN è stato definito come standard internazionale da IEC e Ieee (Ieee 1473-1999 – Standard for Communications Protocol Aboard Train). Il lavoro sulla standardizzazione del livello di applicazione è stato fatto parallelamente allo sviluppo del sistema TCN, e il codice UIC556 è stato approvato anch’esso come standard nel giugno 1999. TCN utilizza l’indirizzamento univoco, per cui ogni nodo del bus ha un proprio indirizzo: si tratta di una rete orientata al nodo. Ciascuna funzione viene eseguita da uno o più nodi/dispositivi indirizzati e ogni dispositivo può eseguire più funzioni.

AEROSPACE

Anche in campo aerospace la crescente complessità dei sistemi ha determinato la diffusione di architetture distribuite. La scelta del bus di comunicazione 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 a una precisa necessità. Un esempio piuttosto noto di tali architetture è rappresentato da Ethernet. Nel secondo caso, invece, le comunicazioni avvengono su precisa base temporale e in accordo con 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 approcci dipende da considerazioni a livello di sistema: i sistemi time-triggered garantiscono che l’occupazione del bus sia costante, evitando contenziosi di accesso tra i nodi (aspetto piuttosto utile in applicazioni di controllo in tempo reale, come nel caso dei sistemi di controllo assetto dei satelliti) e garantiscono quindi predicibilità e latenza nota nello smistamento dei messaggi. Tuttavia, presuppongono, nel caso in cui sia aggiunto alla rete un nodo, che l’intera pianificazione dei messaggi sia ridefinita. Inoltre, non utilizzano in modo efficiente la banda di trasmissione, in quanto la allocano staticamente ai nodi connessi alla rete, anche nel caso in cui questi non abbiano la necessità di trasferire dati all’interno della finestra temporale a essi associata. Nei sistemi event-triggered, invece, è possibile modificare dinamicamente l’allocazione di banda in funzione della configurazione corrente. Uno degli esempi più evidenti in questo senso è rappresentato dall’acquisizione e trasmissione di immagini: il processo tipicamente non è sempre attivo, quando però lo è, richiede elevata banda. D’altra parte, l’utilizzo di un protocollo time-triggered impone un’elevata capacità di buffering locale nel sistema di acquisizione. I principali protocolli di tipo seriale che vengono utilizzati o possono essere tenuti in considerazione per applicazioni aerospaziali sono: Mil-Std-1553, SafeBus, Arinc 659, TTP/C, FlexRay, CAN/TTCan, Spacewire, Firewire, Ethernet, Fibre Channel.

– Mil-Std-1553

Il protocollo di comunicazione Mil-Std-1553 è nato in ambito militare e la sua prima versione è stata pubblicata nel 1978; il primo utilizzo è stato a bordo degli F-16 e degli elicotteri Apache AH-64; in ambito spaziale è ancora oggi operativo su diversi satelliti, a bordo dello Space Shuttle e delle stazioni spaziali. Il protocollo, di tipo Time-Division Command/Response Multiplex, si basa su un semplice scambio domanda/risposta; la comunicazione è di tipo half-duplex ed event-triggered, e sono previsti comandi di sincronizzazione di tipo broadcast, ma non è espressamente supportata la definizione di un tempo globale di sistema. Viene usato un doppino twistato schermato per la connessione dei nodi alla rete con una topologia di tipo multidrop, ma è prevista anche una configurazione con ridondanza mediante due connessioni indipendenti. I livelli fisici del segnale trasmesso sono compresi tra 18 e 27 V, con codifica Manchester; il bit rate massimo è 1 Mbps su distanze brevi (interno veicolo). Inoltre, per le applicazioni spaziali sono già disponibili dispositivi tolleranti alle radiazioni e qualificati in accordo ai metodi Mil-Std-883, ed esistono core IP per implementazioni in 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 bit 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 bit rate fino a 10 Mbps. Inoltre, è stata studiata l’estensione Mil-Std-1773 su fibra ottica che però, limitando sempre il bit rate, non ha trovato un ampio utilizzo.

– SafeBus

Originariamente sviluppato da Honeywell per l’impiego a bordo dei Boeing 777, il protocollo SafeBus è stato successivamente 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 anche supportate da protocolli diversi. Il bus di connessione comprende due linee dati e una linea di clock con una ridondanza quadrupla; sono previsti nodi ‘ombra’ in ridondanza in grado di intervenire in presenza di errori del nodo primario. Il bit rate massimo sostenibile è 60 Mbps su distanze fino a 1,5 m, con un livello fisico Ieee 1194.1. La comunicazione è time-triggered con accesso al mezzo fisico di tipo Tdma-Time Division Multiple Access, tecnica di accesso multiplo a divisione di tempo di tipo deterministico a un unico mezzo trasmissivo, la quale alloca a ogni nodo una finestra temporale sufficiente a trasmettere un’unità informativa. È prevista una sincronizzazione dei clock ai nodi e una base dei tempi globale. Lo standard è proprietario e rappresenta attualmente la principale implementazione del protocollo Arinc 659 disponibile pubblicamente ma soggetto a licenza.

– Arinc 659

Lo standard Arinc 659, come già detto, originariamente utilizzato in SafeBus come sistema di gestione delle informazioni dei Boeing 777, successivamente è stato utilizzato, per esempio, anche nei Boeing 717N, MD-10, KC-130. Attualmente i PC impiegati per le esplorazioni spaziali, come il sistema a livelli altamente affidabile ‘Habitation Readiness Level’ della Nasa, e alcune navicelle spaziali adottano questo protocollo. Le esplorazioni spaziali richiedono prestazioni estremamente elevate del protocollo, per cui per il controller del bus Arinc 659 è necessario progettare un chip completamente personalizzato, al fine di ottimizzarne le prestazioni e la miniaturizzazione. L’architettura del protocollo (si veda figura 5) include i moduli LRM (Line Replaceable Module) con un valore massimo di 32 per linea (nodi di rete); le due unità indipendenti BIU (Bus Interface Unit) formano una struttura a doppia ridondanza in ciascuna interfaccia LRM a 4 bus (Ax, Ay, Bx, By), per doppio autocontrollo e trasmissione dei dati. I due moduli di memoria interni (IMM) in ciascun LRM realizzano l’interazione dei dati del bus tra Host e BIUx/BIUy gestiti da 2 oscillatori rispettivamente. L’utilizzo di 2 oscillatori al cristallo può aumentare la ridondanza del circuito e ridurre la possibilità di guasto causato dall’oscillatore stesso. Le sequenze dei comandi, utilizzando un apposito frame FDL (Frame Description Language), sono memorizzate nella tabella di memoria (TM). La comunicazione del nodo sul bus Arinc 659 adotta una logica di ricetrasmissione backplane ad alta velocità, che può supportare fino 30 Mbps su singolo bus. Da notare che l’Host presenta un controller con due modalità di funzionamento: il circuito può essere controllato da CPU esterna e MCU interna (si veda figura 6). Tali modalità sono selezionabili tramite i pin del circuito.

Scarica il pdf

• 
• Tweet
• Pin It
• Condividi per email