Bus in Avionica

[MarcoGT]

Apro questo post per parlare dei bus che vengono utilizzati in avionica.

E' possibile inizialmente fare una macro distinzione

- Bus commerciali --> COTS (Commercial Off The Shelf)
- Bus "specifici"

Nei bus COTS rientrano:

- Firewire
- AFDX

1) Firewire, nome tecnico IEEE 1394, nella versione originale arriva fino a 400Mbit/s, molto diffusa sul mercato, ora vien a usata anche in ambito consumer per periferiche varie. In ambito aeronautico viene usata prevalentemente per l'IFE. Lo svantaggio principale è viene utilizzata l'architettura Daisy Chain, ossia i devices sono collegati tra di loro a cascata o ad anello. Inoltre, non è fault tolerant o solitamente non viene utilizzata per applicazioni avioniche, anche se ovviamente dipende dai requirements (F-35 infatti usa FireWire)

2) AFDX è un derivato dell'Ethernet e viene utilizzato principalmente in ambito civile (A380 usa AFDX, per esempio).
Il transmission rate di AFDX è 100Mbit/s. E' un protocollo full-duplex. AFDX è l'implementazione Airbus del protocollo ARINC664. Gli LRU (Line Replacement Unit) sono connessi tra di loro tramite due switches AFDX. Sebbene la tecnologia sia full duplex i dati sono inviati in modalità half duplex per evitare collisioni. L'avionica che ne deriva viene chiamata IMA (Integrated Modular Avionics), ossia eventuali LRU aggiuntivi possono essere aggiunti tramite racks o cabinets. Come protocollo viene usato il famoso TCP/IP, lo stesso usato per Internet, per intenderci.

Nei "bus specifici" abbiamo:

- MIL-STD-1553B, chiamato generalmente MILBUS
- ARINC429

1) MIL-STD-1553B: utilizza un collegamento elettrico per le comunicazioni (twisted pairs in rame, schermati). Le informazioni sono inviate con l'utilizzo di un clock. Supporta una ridondanza multipla. Il controllo del bus è eseguito dal BC (Bus Controller) che comunica con gli RT (Remote Terminal); gli RT possono essere fino a 31. Gli RT eseguono operazioni legate al loro subsystem. La frequenza di clock è 1MHz e la codifica è Manchester bifase (se volete, posso spiegare meglio questo tipo di codifica). I dati da inviare sono formattati in "words" che si dividono in status word, data word e command word; ognuna di esse ha una diversa formattazione. Ogni word è lunga 16bit. La larghezza di banda è pari a 1Mbit/s
Se interessati posso fare un esempio di funzionamento di questo bus.

2) ARINC429
E' un bus di tipo single source-multiple sink; è half-duplex; solitamente viene utilizzato a 100kbit/s. Viene utilizzato sia in ambito civile che in ambito militare. A330 e 767 lo utilizzano.
La topologia fa si che si possa trasmettere da una source verso più sink ed ognuno di questi receiver riceve il messaggio inviato. In una rete ci possono essere fino a 20 sink. La modulazione utilizzata è bipolare RTZ (Return To Zero). I messaggi sono trasmetti utilizzando una word di 32 bit (4 byte).

Se avete domande, chiedete pure, proverò a rispondere

[FAS]

ottimo...

beh visto che ti trovi continua con l'ARINC 629....anche questo bidirezionale che é applicato al 777

[MarcoGT]

ARINC 629:

come anticipato da FAS e' un bus bi-direzionale ed e' utilizzato sul 777.
Ha una larghezza di banda di 2Mbit/s.
Rispetto all'ARINC429 e' un grande passo in avanti in quanto elimina il concetto di master. Come detto e' un'evoluzione dell'A429 ma e' molto simile, come topologia di rete al MILBUS (MIL-STD-1553B) in quanto ogni singola unita' puo' trasmettere e ricevere e la velocita' e' maggiore rispetto all'A429.

Ovviamente sui bus ci sarebbe moltissimo da dire, se volete si puo' approfondire...

[giangoo]

grazie mille, molto esaustivo. In quanto ad approfondimento aereonautico qua si va sul vietato ai minori... Nel mio lavoro uso svariati protocolli di comunicazione, ne nascono sempre di nuovi, ma niente di cosi' critico come l'aviazione. Al massimo se qualcosa non funziona qualche migliaio di persone si incazza con me.
Potresti approfondire il livello fisico dei cavi? Ho letto che uno e' twisted pair, shielded, gli altri? Ci sono connessioni particolari o sono hardwired o "stagnati"?
Grazie ancora.

[MarcoGT]

MILBUS 1553:

i cavi utilizzati con questo bus hanno un'impedenza tra i 70 e gli 85 ohm.
L'industria ha comunque stabilito che i cavi twinax che vengono usati debbano avere una impedenza pari a 78 ohm.

Questo e' il connettore utilizzato per il 1553B



Il ritardo di propagazione su questo cavi e' pari a 4.8ns per ogni metro di lunghezza.

Il cavo e' chiamato twinaxial cable ed e' simile al cavo coassiale ma ha due conduttori interni anziche' uno.
La larghezza di banda e' pari a 1Mbit/s; per quanto riguarda le tensioni: sono diverse sui due conduttori, quando uno porta 0.32V, l'altro porta 0V.

[Mikoyan89]

Thread interessantissimo....volevo chiedere giusto due cosine...
Su arinc 429 non c'è BUS controller? e cosa si intende per master?

Se interessati posso fare un esempio di funzionamento di questo bus

se non ti porta via troppo tempo io sarei interessato

[MarcoGT]

No, su ARINC429 non c'e' alcun bus controller. Supponiamo di avere un network di 20 LRU, uno sara' il trasmitting LRU, gli altri 19 saranno i receiver...e cosi' via.

L'esempio sul MILBUS lo faccio col calma visto che e' piuttosto lungo

[tartan]

ottimo...

beh visto che ti trovi continua con l'ARINC 629....anche questo bidirezionale che é applicato al 777

Fas, aiutami, ma di cosa stanno parlando?

[MarcoGT]

Fas, aiutami, ma di cosa stanno parlando?

Anche se la risposta la conosci, te lo dico lo stesso
Si tratta di mezzi e protocolli di comunicazione utilizzati in avionica

[tartan]

Fas, aiutami, ma di cosa stanno parlando?

Anche se la risposta la conosci, te lo dico lo stesso
Si tratta di mezzi e protocolli di comunicazione utilizzati in avionica

Grazie Marco gran turismo, in effetti lo avevo immaginato, però faccio tanta fatica a seguirvi e questo mi da un fastidio che neanche immagini. Naturalmente mi riferisco alla mia incapacità di seguirvi su dettagli che non ho mai avuto modo di approfondire e quindi mi sento escluso. Mi raccomando, non è un rimprovero ma solo una dichiarazione di impotenza (teorica, ragazzi) Andate pure avanti senza curarvi di me, sono troppo fuori!
Ps Grazie veramente.

[Hartmann]

Interessantissimo

[FAS]

tartan nun fá accussí......

[Mikoyan89]

No, su ARINC429 non c'e' alcun bus controller. Supponiamo di avere un network di 20 LRU, uno sara' il trasmitting LRU, gli altri 19 saranno i receiver...e cosi' via.

L'esempio sul MILBUS lo faccio col calma visto che e' piuttosto lungo

Grazie

[Zapotec]

Fas, aiutami, ma di cosa stanno parlando?

Anche se la risposta la conosci, te lo dico lo stesso
Si tratta di mezzi e protocolli di comunicazione utilizzati in avionica

Grazie Marco gran turismo, in effetti lo avevo immaginato, però faccio tanta fatica a seguirvi e questo mi da un fastidio che neanche immagini. Naturalmente mi riferisco alla mia incapacità di seguirvi su dettagli che non ho mai avuto modo di approfondire e quindi mi sento escluso. Mi raccomando, non è un rimprovero ma solo una dichiarazione di impotenza (teorica, ragazzi) Andate pure avanti senza curarvi di me, sono troppo fuori!
Ps Grazie veramente.

Tartan, il bus più semplice è composto dall'interruttore (master) che accende la lampadina (slave) ed il filo che li collega. Ora muovi decisamente più velocemente l'interruttore (e magari con delle sequenze definite) e hai fatto un sistema di comunicazione.
Tutte le altre cose sono complicazioni da ingegneri (oh ing. scherzo ... ovviamente le cose si complicano a mano a mano che aumentanto le informazioni da trasferire e la sicurezza con cui queste devono transitare)

ciao !

PS: Bravo Marco, interessantissimo

[FAS]

schematizziamo:
per i digital data bus

Single Source - Single Sink
trasmetto da un equipaggiamento ad un altro

Single Source - Multiple Sink
trasmetto da un equipaggiamento a piú equipaggiamenti

Multiple Source - Multiple Sink
piu equipaggiamenti trasmettono a piu ricevitori/equipaggiamenti

[MarcoGT]

Ottimo schema FAS...

Sto mettendo giu' un esempio col MILBUS 1553...

[FAS]

fai un confronto con un sistema ARINC e cerca di evidenziare le difficoltá di inserire un nuovo equipaggiamento nella tipologia ARINC ed in quella MIL-S

potrebbe tornare utile per la discussione

[MarcoGT]

Come richiesto, approfondisco il MIL-STD-155B. Ovviamente sarebbe necessario un libro per entrare nei dettagli...

1553B definisce tre "terminal"

• Bus Controller (BC)
  Remote Terminal (RT)
  Bus Monitor (BM)

La funzione principale del BC e' quella di controllare il flusso di dati sul bus. Inoltre, il BC deve trasmettere, ricevere e coordinare il trasferimento delle informazioni sul data bus.
Tutte le informazioni che fluiscono sul data bus sono del tipo command/response, ossia: il BC invia un command al RT che risponde con una response.

Il BC e' l'elemento chiave del bus system. Sul bus possono esserci piu' di un BC, ma solo uno puo' essere attivo nello stesso momento.

Il controllo da parte del BC include la trasmissione di comandi ai RT ad intervalli prestabiliti (una sorta di polling). I comandi possono includere data, request for data (incluso lo status).
Il BC ha anche l'autorita' di modificare il flusso di dati se ci sono dei cambiamenti nell'ambiente in cui sta operando (per esempio una failure).

Il RT e' un dispositivo progettato per interfacciarsi con i subsystem tramite il bus 155B. L'interfaccia puo' essere embedded nel subsystem stesso.
Il RT riceve e decodifica i comandi dal BC, rileva gli errori e reagisce a questi errori. Il RT deve essere in grado di gestire sia errori di protocollo (missing word, per esempio) che errori elettrici (distorsioni, per esempio).
Su un singolo data bus possono esserci fino a 31 RT; ogni RT puo' avere fino a 31 subaddresses.
Il RT non puo' trasmettere se non interpellato dal BC.

Il BM "ascolta" tutti i messaggi e li registra. Il BM e' sostanzialmente un bus passivo che raccoglie i dati per analisi sia real time che a posteriori.

I messaggi che sono trasmitti sul MILBUS sono word; esistono, per il MILBUS ovviamente, 3 word diverse:

• Command word
  Data word
  Status word

La command word e' lunga 20 bit e' suddivisa nel seguente modo:
Bit 0-2: sync waveform
Bit 3-7: indirizzo del RT
Bit 8: T/R bit (bit utilizzato per indicare se siamo in trasmit o receive)
Bit 9-13: subaddress mode
Bit 14-18: data word count/mode code
Bt 19: parity bit

Data word (20 bit)
Bit 0-2: sync waveform
Bit 3-18: data
Bit 19: parity bit

Status word (20 bit)
Bit 0-2: sync waveform
Bit 3-7: RT address
Bit 8: Message error
Bit 9: Instrumentation
Bit 10: Service Request
Bit 11-13: Reserved
Bit 14: Broadcast command
Bit 15: Busy
Bit 16: Subsystem Flag
Bit 17: Dynamic Bus Control
Bit 18: Terminal Flag
Bit 19: Parity

Le command word sono inviate dal BC al RT per sollecitare l'invio/ricezione di dati o lo svolgimento di qualche operazione.

Senza entrare nel dettaglio di ogni singolo di bit, spiego i principali

RT address: come dice il nome e' l'indirizzo del RT a cui inviare il messaggio; NB: il messaggio viene spedito a tutti gli RT, sara' poi compito di ogni singolo RT verificare che il suo address corrisponda con quello specificato nel messaggio; se sono uguali significa quindi che il messaggio era destinato a lui...ed agira' di conseguenza

T/R: indica l'azione richiesta al RT da parte del BC.

Data Word/Count Mode: indicano la quantita' di dati che devono essere inviati (o ricevuti) al RT.

Le status word sono trasmesse da un RT in risposta ad un comando (non broadcasted, pero'). Le status word contengono quindi informazioni sugli errori (eventuali) contenuti nel messaggio ricevuto dallo stesso RT che invia la status word. Le status word sono trasmesse da un RT solo dopo aver ricevuto un comando da un BC; a cosa serve? A verificare che il corretto RT risponda alla command word e che nessun altro RT risponda (per sbaglio).

Di seguito degli "scambi" di messaggi tra BC e RT.

1) BC to RT Transfer
Il BC invia un receive command seguito dalle data words. Il RT, dopo la ricezione e validazione del messaggio, trasmette una status word al BC. Command e Data word sono inviate, dal BC, senza intervalli di interruzione.
Receive Command -- Data Word -- Data Word ..... Data Word ++ Status Word --> Next Command

2) RT to BC Transfer
Il BC invia un trasmit command al RT; l'RT, dopo la ricezione e validazione, invia una status word al BC seguito dalle data words.
Trasmit Command ++ Status Word ++ Data Word -- Data Word ... Data Word --> Next Command

3) RT to RT Transfer
BC riceve un receive command da RT A e un trasmit command da RT B. RT B, dopo ricezione e validazione, trasmette una status word seguita dalle data words; terminato l'invio delle data words da parte di RT B, RT A invia una status word.
Receive Command Transmit Command ++ Status Word Data Word -- Data Word .... Data Word ++ Status Word --> Next Command

Questi sono gli "schemi" principali, ne esistono ovviamente degli altri, come ad esempio il broadcast.

[Zapotec]

Il livello fisico com'è ?

[Maurice]

Post interessante, anche per i non addetti ai lavori.
Si riesce a fare una piccola tabella dei bus usati negli aeromobili più comuni?

Io segnalo il capitolo 2 del libro "Military Avionics System", di Ian Moir, per approfondire l'argomento dei bus avionici militari. Il libro accenna anche alla architettura JIAWG dell'F-22 Raptor (definita però già obsoleta) e considera i bus a fibre ottiche (Fibre Channel) come l'avanguardia tecnologica.

[MarcoGT]

Si, quel libro li è ottimo, lo consiglio a chi ha voglia di approfondire l'argomento

[bigshot]

Anticipato che per quanto riguarda l'aeronautica sono ancora "noob", di elettronica/informatica m'intendo per passione e professione
Mi sembra che questo in questo specifico settore si stia seguendo una logica di avvicinamento alle tecnologie informatiche più generiche, no? D'altra parte anche in diversi ambiti industriali la tendenza è quella di passare da bus meno evoluti e in qualche modo legati all'hardware specifico (chi parla di Siemens?) all'astrazione offerta dal TCP/IP...

2) AFDX è un derivato dell'Ethernet e viene utilizzato principalmente in ambito civile (A380 usa AFDX, per esempio).
Il transmission rate di AFDX è 100Mbit/s. E' un protocollo full-duplex. AFDX è l'implementazione Airbus del protocollo ARINC664. Gli LRU (Line Replacement Unit) sono connessi tra di loro tramite due switches AFDX. Sebbene la tecnologia sia full duplex i dati sono inviati in modalità half duplex per evitare collisioni. L'avionica che ne deriva viene chiamata IMA (Integrated Modular Avionics), ossia eventuali LRU aggiuntivi possono essere aggiunti tramite racks o cabinets. Come protocollo viene usato il famoso TCP/IP, lo stesso usato per Internet, per intenderci.

Mi pare che un po' tutti stiano adottando questa opzione... ho letto del 787 e ho sentito del Sukhoi Superjet (gli uffici commerciali della Joint Venture erano "dietro l'angolo" nel mio paesotto).

Ho comunque un paio di dubbi che vorrei chiederti se cortesemente puoi chiarirmi per quanto riguarda questa "edizione" un po' ritoccata dell'ethernet grazie
- Generalmente con FullDuplex s'intende un sistema che già di per se evita le collisioni (nell'ethernet liscio appunto in un cavo almeno una coppia riceve e una trasmette ed e non c'è contesa per cominciare la trasmissione di un messaggio). Tra l'altro la "FD" di AFDX mi risulta proprio Full Duplex... perché quindi tutto viene "castrato" in half-duplex? e soprattutto la limitazione riguarda sempre il primo livello ISO/OSI o è una precauzione presa a livelli superiori?
Anche perchè ho letto (in quel poco che si trova in giro) dell'uso anche di UDP... per definizione rapido e senza fronzoli ma non totalmente affidabile per l'integrità dei dati.

- In questo caso come hardware cosa si usa generalmente? Intendo cavi, plug e quant'altro... Mi fa "paura" pensare ad un cavo scollegato per colpa della solita linguetta di fermo spezzata
Immagino comunque per ora sempre si tratti di doppini in rame visto che delle fibre ottiche ne avete parlato con verbi coniugato al futuro
Dal punto di vista di switch & co. avevo letto di Honeywell per Boeing, per Airbus invece?


- Uscendo un po' dal topic, ma nemmeno tantissimo... una curiosità! Ho sentito parlare di varie installazioni *nix usate in molteplici sottoservizi su 747... ad oggi cosa si usa nei modelli più recenti?

1) MIL-STD-1553B: utilizza un collegamento elettrico per le comunicazioni (twisted pairs in rame, schermati). Le informazioni sono inviate con l'utilizzo di un clock. Supporta una ridondanza multipla. Il controllo del bus è eseguito dal BC (Bus Controller) che comunica con gli RT (Remote Terminal); gli RT possono essere fino a 31. Gli RT eseguono operazioni legate al loro subsystem. La frequenza di clock è 1MHz e la codifica è Manchester bifase (se volete, posso spiegare meglio questo tipo di codifica). I dati da inviare sono formattati in "words" che si dividono in status word, data word e command word; ognuna di esse ha una diversa formattazione. Ogni word è lunga 16bit. La larghezza di banda è pari a 1Mbit/s
Se interessati posso fare un esempio di funzionamento di questo bus.

Un semplice bit di parità!?!?!? E abbastanza weak come controllo d'integrità... lo era con gli esperimentini che facevo con arduino, su un aereo la cosa mi pare un po' più seria!


Grazie, lo so che alla fine ho scritto una mattonata piena di richieste

[noone]

Ma il Bus 429 ferma a Porta Romana?
ca**ate a parte thread molto interessante, un sacco di info anche di difficile reperibilità. A tal proposito c'è qualche libro da consigliare per farsi una cultura, soprattutto nel civile.
Avanti così!
Vanni

[MarcoGT]

Ci sarebbe questo:

"Aircraft System: Mechanical, Electrical and Avionics Subsystems Integration" (Moir - Seabridge)

ma come vedi non parla solo di bus usati di avionica.

Per il militare, invece:

"Militay Avionics Systems" (Moir - Seabridge)

[Zapotec]

Generalmente con FullDuplex s'intende un sistema che già di per se evita le collisioni (nell'ethernet liscio appunto in un cavo almeno una coppia riceve e una trasmette ed e non c'è contesa per cominciare la trasmissione di un messaggio). Tra l'altro la "FD" di AFDX mi risulta proprio Full Duplex... perché quindi tutto viene "castrato" in half-duplex? e soprattutto la limitazione riguarda sempre il primo livello ISO/OSI o è una precauzione presa a livelli superiori?

In questa tipologia di bus è solo il BusController che inizia la comunicazione, per cui non esistono comunque conflitti (non è un bus multimaster). Ritengo sia questa la scelta dell'half duplex (leggesi : se proprio devi raddoppiare il cablaggio lo fai per ridondanza e non per avere la linea delle risposte )

Anche perchè ho letto (in quel poco che si trova in giro) dell'uso anche di UDP... per definizione rapido e senza fronzoli ma non totalmente affidabile per l'integrità dei dati.

Parli già di un livello (UDP) superiore, non applicabile per questo tipo di bus

- In questo caso come hardware cosa si usa generalmente? Intendo cavi, plug e quant'altro... Mi fa "paura" pensare ad un cavo scollegato per colpa della solita linguetta di fermo spezzata

Ho visto (sfogliando cataloghi online e leggendo documentazioni varie) che sono dei BNC. A differenza di quelli ethernet che probabilmente conosci, hanno in pratica 3 connessioni, più simile al twinax. Il segnale del bus 1553 viaggia su un doppino intrecciato (quindi 2 conduttori). Il terzo conduttore è la schermatura che racchiude gli altri due segnali.

Un semplice bit di parità!?!?!? E abbastanza weak come controllo d'integrità... lo era con gli esperimentini che facevo con arduino, su un aereo la cosa mi pare un po' più seria!

Bhe intanto un bit di parità ogni 16 non è poi così poco
Comunque, non c'è solo la parità per il controllo del frame. Deve essere controllato che il segnale di sincronismo sia corretto. Ciascun bit è codificato in Manchester Bifase : deve essere rispettata la codifica. Poi il numero di bit è fisso, quindi devi aspettarti esattamente quel numero di bit. Ovviamente poi c'è anche la parità odd che deve coincidere
Questo a livello di singolo messaggio, tieni presente che poi, per informazioni particolarmente critiche, possono essere implementati altri metodi (ad esempio inserire un CRC di messaggio).
Inoltre, mi pare di aver intuito, in avionica viene spesso demandato a ciascun Terminale il filtraggio dei messaggi ricevuti : Ad esempio se un valore di AoA è di 5°, il messaggio successivo non può essere di -20 e quello successivo ancora a 5, è ovvio che il -20 è un dato errato (ovviamente esempio per semplificare)

ciao !

[Lele Venezia]

Bell'argomento!!! Fra pochi mesi affronterò il modulo 5 - Tecniche digitali e se avrò qualche dubbio, bhè... ti faccio un fischio!!!

[MarcoGT]

Modulo 5 di cosa?

[Lele Venezia]

Modulo 5 di cosa?

Il Modulo 5 - Tecniche Digitali, per conseguire la LMA B1 completa e soprattutto la LMA B2, licenze per diventare un tecnico aeronautico di alto livello.
Voglio specializzarmi, in particolar modo, in Avionica! 18 esami non son pochi!

[PizzOne]

Non mi è chiara la differenza tra LRU e IMA. L'IMA è uno sviluppo della LRU?
Le LRU collegano bus secondo un certo criterio, sono ridundanti?Se si, una LRU riduntante collega esattamente gli stessi sistemi? L'IMA è una sola? Mi servirebbe una spiegazione non troppo approfondita...

[PizzOne]

....ridundanti...riduntante...

Ho un pò sbagliato, intendevo "ridondante" , è che tra italiano, tedesco, inglese.. e stanchezza (ero entrato in modalità PizzTwo ), vabbè l'importante è trasmettere l'informazione...

[Maurice]

Non mi è chiara la differenza tra LRU e IMA. L'IMA è uno sviluppo della LRU?
Le LRU collegano bus secondo un certo criterio, sono ridundanti?Se si, una LRU riduntante collega esattamente gli stessi sistemi? L'IMA è una sola? Mi servirebbe una spiegazione non troppo approfondita...

Qui stiamo confondendo le due cose, in quanto LRU è un termine prettamente di ingegneria logistica, indicando un componente che può essere rimosso/installato al primo livello manutentivo (per esempio, in linea volo), mentre IMA indica una tipologia di architettura hardware.
Con una certa generalizzazione, si può dire che un certo numero di LRU interconnessi tra loro formano una architettura IMA.

[FAS]

Non mi è chiara la differenza tra LRU e IMA. L'IMA è uno sviluppo della LRU?
Le LRU collegano bus secondo un certo criterio, sono ridundanti?Se si, una LRU riduntante collega esattamente gli stessi sistemi? L'IMA è una sola? Mi servirebbe una spiegazione non troppo approfondita...

Qui stiamo confondendo le due cose, in quanto LRU è un termine prettamente di ingegneria logistica, indicando un componente che può essere rimosso/installato al primo livello manutentivo (per esempio, in linea volo), mentre IMA indica una tipologia di architettura hardware.
Con una certa generalizzazione, si può dire che un certo numero di LRU interconnessi tra loro formano una architettura IMA.

infatti l'origine in ingegneri é LRI

[PizzOne]

Finalmente ho capito cosa ci sta dietro LRU e IMA, ma LRI mi è nuova , cosa è?

[FAS]

Line Replaceable Item

[PizzOne]

Line Replaceable Item