ARINC 429, test case #1

Nei sistemi di test automatici che coinvolgono apparati avionici, è praticamente onnipresente la verifica del corretto funzionamento del bus ARINC 429, sia dal lato funzionale che da quello elettrico. Vi riassumo, nel modo più sintetico che posso, cosa è l'ARINC 429 (da qui in poi ometterò il numero). Ad ogni modo qui trovate la pagina Wikipedia dedicata all'argomento.

Si tratta dello standard che definisce le interfacce fisiche ed elettriche di questo BUS e il protocollo di dati che vi transitano. Elettricamente (e fisicamente) il bus è composto da due cavi (H e L) per canale, dove solo un dispositivo è in grado di trasmettere e tutti gli altri ricevono.

Illustrazione 1: Bus ARINC 429
llustrazione 1: bus ARINC 429

 

I dati trasmessi sono racchiusi in una longword (32 bit), dove i campi sono:

  • Label: è una “etichetta” numerica, come se fosse il nome di una variabile;

  • SDI: sorgente (o destinazione); è usato spesso per indicare destro/sinistro e primario/secondario;

  • Data: è il valore (della variabile);

  • SSM: è una specie di segno del valore;

  • P: bit di parità.

Illustrazione 2: Formato longword
Illustrazione 2: formato longword

 

La verifica del corretto utilizzo del bus ARINC da parte della UUT (unità sotto test, acronimo in inglese) in genere si compone in tre test:

  1. trasmissione delle label;

  2. ricezione delle label;

  3. analisi elettrica dei segnali (H e L) generati.

Illustrerò in questo articolo il primo caso di test (in italiano suona male; test case è tutta altra musica). Gli altri due casi saranno trattati in articoli successivi.

Usare le funzioni primitive, messe a disposizione dal driver a corredo della scheda ARINC, non è una di quelle cose che definirei semplice. Innanzitutto, occorre conoscere, bit a bit, il protocollo e, a seguire, avere un po' di dimestichezza con la nomenclatura utilizzata dalla libreria stessa. Vi assicuro che non è cosa da poco; piuttosto che rischiare di annoiarvi, preferisco parlare di come si possono impostare ed effettuare dei test, utilizzando dreamTest di CBL e TestStand di NI (Per chi non lo sapesse, dreamTest è un ambiente software di gestione strumentazione e misure, mentre TestStand è “un sofware pronto all'uso per la gestione di test”).

Useremo TestStand per editare ed eseguire la sequenza di test e dreamTest per attingere alla sua libreria della gestione del bus ARINC 429. Questa libreria è composta in totale da sei funzioni; potrebbero sembrare poche, ma in realtà permettono di coprire integralmente le necessità più frequenti in questo genere di test.

Affrontiamo il primo caso: verifica della corretta trasmissione delle label. Ipotizziamo di avere già configurato dreamTest per gestire il canale in ricezione ARINC (attualmente sono supportate le schede AIM e AIT) e di avere già scritto la parte di sequenza automatica che attiva la trasmissione della UUT.

La prima cosa da fare, magari in un punto iniziale della sequenza, è definire la velocità di trasmissione (high o low) e fare una pulizia del buffer di ricezione (che è sempre buona pratica). Quindi, dove occorre, verifico che la label richiesta sia stata ricevuta in modo corretto.

Utilizzo i tre seguenti codestep:

Illustrazione 3: Settiamo la velocità (high o low)
Illustrazione 3: settiamo la velocità (high o low)

Illustrazione 4: Puliamo il buffer
Illustrazione 4: puliamo il buffer

Illustrazione 5: Leggo la label
Illustrazione 5: leggo la label

 

I parametri di ingresso e uscita dovrebbero essere chiari, riporto la loro descrizione:

  • nick: è il soprannome che abbiamo dato in configurazione del canale ARINC di ricezione;

  • label in input: indico l'identificativo e SDI della label di mio interesse (in questo caso il campo value è un “non mi importa”);

  • label in output: riporta, assieme a identificativo e SDI, l'ultimo valore letto e il rate di ricezione.

Dopo tanta fatica (13 righe), siamo diventati esperti di mezza libreria ARINC di dreamTest (tre funzioni su sei è pur sempre una metà). È ora di mettere a frutto la nostra conoscenza e scrivere la sequenza in TestStand. Inserisco tre step:

  • due step Action per impostare la velocità e pulire il buffer;

  • uno step Multiple Numeric Limit Test, per verificare la corretta ricezione della label.

Illustrazione 6: Sequenza di test automatico
Illustrazione 6: sequenza di test automatico

 

Potrebbe bastare ma c'è dell'altro. L'interattività di dreamTest vi permette di fare le stesse operazioni da pannello, manualmente, dalla finestra dedicata o vedere le label scorrere mentre il test è in esecuzione.

Illustrazione 7: finestra interattiva
Illustrazione 7: finestra interattiva

 

Per questo articolo è tutto, nei prossimi affronteremo gli altri due test case: trasmissione e test elettrico. Prima di congedarmi, vi ringrazio del vostro tempo e vi chiedo una cortesia: se vi è piaciuto questo articolo lasciate un like, fa sempre piacere. Se siete interessati, o avete delle domande, non esitate a contattarmi, sarò felicissimo di rispondere ai vostri messaggi o anche alle eventuali critiche.
Grazie per l'attenzione e condividete, se volete.

Antonio Costantino

 

Share this post

Su di noi

CBL è un’azienda giovane, ma con una solida esperienza, che ha nel proprio DNA la passione per l’innovazione continua. Ci piace pensare che i clienti che si rivolgono a noi, ma anche i nostri collaboratori, trovino nella nostra organizzazione un porto sicuro.

Vantiamo una consolidata esperienza nel fornire soluzioni complete per la produzione e lo sviluppo di apparecchiature di test (ATE, STTE, EGSE), lo sviluppo di programmi di test (Cloudless, Dreamtest), il test di schede elettroniche e il supporto ai test di affidabilità.