Realizzazione del sistema di acquisizione dati per banco prova del

Realizzazione del sistema di acquisizione dati per banco prova del motore EJ200
"L’impiego della tecnologia CompactRIO ha
permesso di acquisire in real-time e memorizzare
una grande quantità di segnali provenienti da
sensori diversi, inoltre l’impiego delle schede
PXI-DAQ ha permesso di ridurre problemi di
sincronizzazione concentrando in un’unica unità
l’acquisizione di tutti i segnali analogici, digitali e
seriali, provenienti dal DECU"
- M. Antinori, LEONARDO SISTEMI (http://www.leonardosistemi.com)
La sfida:
Realizzare un sistema di acquisizione dati per un banco prova motore aeronautico in grado di effettuare tutte le misure richieste dai requisiti di
collaudo anche in condizione di alto disturbo ambientale. Ottenere un'alta affidabilità e manutenibilità del sistema per mezzo di un'architettura
distribuita RT e rendere disponibili i dati acquisiti in corso di prova per un modello di calcolo delle prestazioni del motore sotto collaudo.
La soluzione:
Si è scelta una configurazione hardware costituita da tre NI CompactRIO e da un NI PXI equipaggiati con gli opportuni moduli I/O, che hanno la
funzione di acquisitori e da due PC commerciali, con funzione di host server sui quali è implementata l’interfaccia uomo-macchina (HMI). Gli apparati
sono tutti dotati di processore on-board e collegati attraverso una LAN ethernet. L'uso di NI LabVIEW Real-Time nello sviluppo del software ha
permesso una progettazione improntata alla massima robustezza e modularità in linea con le criticità del sistema realizzato.
Autore (i):
M. Antinori - LEONARDO SISTEMI (http://www.leonardosistemi.com)
M. Baioni - LEONARDO SISTEMI
M. Curti - LEONARDO SISTEMI
Breve riassunto
In questo articolo si descrive l’architettura e il software di un sistema di acquisizione dati per un banco prova motori aeronautici, che acquisisce in
Real-Time i segnali generati da un gran numero di sensori alloggiati nell’area di test e i dati provenienti dal motore. Tutti i dati acquisiti sono trasferiti, sia
durante lo svolgimento della prova che alla sua conclusione a un software che esegue il calcolo delle prestazioni del motore. Leonardo Sistemi ha
realizzato un Sistema di acquisizione dati per il banco prova dei motori EJ-200 cercando di sfruttare al meglio l'innovazione tecnologica di questi anni.
L’architettura scelta per questo sistema è basato su una rete LAN alla quale sono collegati unità di acquisizione real-time CompactRIO, PXI e PC
industriali per il monitoraggio dei dati e la gestione delle procedure di collaudo. Tutto il software applicativo è stato sviluppato in LabVIEW e LabVIEW
Real-Time, la comunicazione tra i processi attivi all'interno del sistema è ottenuta tramite il protocollo NI-DataSocket.
Articolo
Requisiti principali per un sistema di Acquisizione dati per Banchi prova motori aeronautici
In un banco prova per motori aeronautici vi è la necessità di acquisire una vasta gamma di segnali: pressioni, temperature, giri motore, vibrazioni, spinta
del motore e flusso del carburante. I relativi sensori sono distribuiti su di un’ampia superficie che comprende la “Test Cell”, in cui è alloggiato il motore
sotto test e gli impianti esterni ausiliari. Il sistema di acquisizione dati ha la funzione di acquisire tutti questi segnali in real-time correlandoli con un i dati
messi a disposizione da una centralina elettronica alloggiata a bordo del motore (Digital Engine Control Unit, DECU) e interfacciata per mezzo di alcuni
apparati proprietari presenti nella “control room”.
Lo scopo del DAS è quello di raccogliere i dati generati nelle sessioni di collaudo e metterli a disposizione del modello di calcolo delle prestazioni del
motore sia durante il corso della prova sia off-line per la post-analisi del collaudo stesso.
Il modello prestazionale del motore è stato implementato dal costruttore del motore e risiede su di un PC alloggiato in control room. Il compito del DAS è:
• Fornire, a fine prova, tutti i dati acquisiti durante l’esecuzione del test al software di calcolo delle prestazioni del motore
• Fornire, durante la prova su indicazione dell’operatore, degli snap-shot dei dati in acquisizione.
Oltre alla necessità di acquisire in real time e in maniera sincronizzata una grossa quantità di dati, considerando l’elevato costo di ogni test eseguito, è
indispensabile evitare l’accidentale perdita dei dati acquisiti che comprometterebbe l’esecuzione della prova in corso.
Il DAS ha anche il compito di gestire le interfacce per gli operatori presenti in control room. Uno schema a blocchi del banco prova motore e del DAS è
rappresentato in figura 1.
Architettura del Sistema Acquisizione Dati
Per rispondere alle necessità illustrate nel paragrafo precedente, si è deciso di realizzare un sistema di acquisizione dati composto da quattro unità di
acquisizione real-time indipendenti, ciascuna dedicata ad una diversa tipologia di segnali, e da due PC che hanno la funzione di host remoto per gli
operatori. I PC e le unità di acquisizione comunicano tra loro tramite una rete LAN ethernet dedicata su cui gli apparati di real- time trasmettono in
broadcast i dati acquisiti, gli allarmi legati ai range delle misure e gli eventuali messaggi di errore. Nella direzione opposta la rete ethernet viene utilizzata
dai PC per inviare comandi alle unità di acquisizione.
Le quattro unità di acquisizione real-time sono state realizzate utilizzando due piattaforme hardware: una unità PXI e tre unità CompactRIO (Figura 2). Si
è scelto di dedicare alla acquisizione dati dagli apparati di interfacciamento con il motore un mainframe PXI, con scheda controller PXI-8106, equipaggiata
con dei moduli I/O DAQ e delle schede di interfaccia RS-422, per rispondere alla necessità di avere un gran numero di canali di acquisizione disponibili
sullo stesso apparato di acquisizione. Le unità CompactRIO, sono state dedicate all’acquisizione dei segnali da campo (Test cell e impianti ausiliari), infatti
grazie alle loro alte prestazioni in dimensioni molto contenute e alla loro alta resistenza alle vibrazioni e alle alte temperature possono essere impiegate
vicino ai sensori, minimizzando così la distanza da coprire con i cavi elettrici. Inoltre l’ampia disponibilità di schede strumento permette di equipaggiare
ciascuno dei tre MainFrame CompactRIO con le più appropriate risorse per effettuare le letture da: termocoppie, RTD, Trasduttori di pressione, Strain
Gauge e Flussometri.
Le quattro unità di acquisizione real-time sono continuamente in acquisizione, ad una frequenza di 20 Hz. Alla ricezione del comando di avvio test sulla
rete LAN e di un segnale hardware di sincronizzazione i dati acquisiti vengono memorizzati su file a bordo dei controller CompactRIO e PXI e, alla
ricezione del comando di fine test, questi file vengono trasferiti via FTP sul PC di Test Monitoring. In maniera del tutto analoga i quattro acquisitori
real-time generano un file contente uno snap-shot di dati quando ricevono il relativo comando e segnale di sincronizzazione. I file generati, sia in corso
che a fine prova, sono inviati via FTP al PC host con funzione di Test Monitor,il quale provvede a organizzare le misure real-time in un unico file del
formato richiesto dal software di calcolo delle prestazioni; il file così ottenuto è quindi trasferito sul PC che ospita il modello prestazionale attraverso una
connessione ethernet dedicata.
La sincronizzazione delle quattro unità real-time è garantita da degli appositi segnali di trigger Hardware che vengono acquisiti insieme alle misure
provenienti dai sensori da tutti e quattro i sistemi real-time.
Si noti come questa architettura distribuita permetta di conservare sugli acquisitori real-time i file delle misure prodotte durante il test. In caso di
malfunzionamento della rete LAN o di malfunzionamenti dei PC di supervisione i dati possono essere comunque recuperati ed analizzati off-line.
I software applicativi del sistema acquisizione dati
Tutti i software applicativi degli apparati real-time sono scritti in LabVIEW Real-Time, le interfacce utente residenti nei due PC host sono scritti in LabVIEW
e girano sotto sistemi operativi MS Windows XP Professional. I processi attivi nei vari processori che compongono il sistema di acquisizione dati
comunicano tra loro attraverso il protocollo NI-DataSocket, le unità di acquisizione aggiornano continuamente le variabili condivise sui loro Data Socket
Server (DSS) rendendo così disponibile ai PC Hosts i dati acquisiti e lo stato degli allarmi relativi al superamento dei range previsti. Analogamente i PC si
1/5
www.ni.com
Server (DSS) rendendo così disponibile ai PC Hosts i dati acquisiti e lo stato degli allarmi relativi al superamento dei range previsti. Analogamente i PC si
servono di una variabile condivisa per inviare comandi alle unità di acquisizione.
I dati acquisiti dagli apparati real-time sono quindi continuamente a disposizione dei due PC Host, che li presentano agli operatori in control room
attraverso due apposite interfacce uomo-macchina.
Il PC con funzione di Data monitor implementa l’interfaccia per l’operatore che ha il compito di monitorare lo stato dei segnali critici per la sicurezza
dell’impianto. Una logica di accessi al sistema permette di definire due livelli di utentenza: Un livello super user e un livello operatore. L'interfaccia grafica
è composta da tre pagine e permette di:
• Leggere il valore corrente di tutti i dati acquisiti raggruppati per tipologia di segnali e selezionabili attraverso un menù a tendina (pagina principale, Figura
3).
• Monitorare gli andamenti temporali e i valori correnti di un sub-set di grandezze critiche per la sicurezza, selezionabili dall’utente super user, (schermata
di data safety, Figura 4)
• Controllare lo stato dei quattro apparati di acquisizione attraverso una pagina di status che per ciascuno di essi permette di verificare la presenza in rete
e lo stato di esecuzione di un comando.
Il PC con funzione di test monitor implementa l’interfaccia per l’operatore che supervisiona l’esecuzione del test del motore. Come si vede dalla Figura 5
questa schermata grafica presenta un numero limitato di controlli e indicatori con le informazioni essenziali, una serie di LED per le condizione principali di
allarme e tutte le facility necessarie all’operatore:
Il Software di Test monitor si occupa anche di inviare ai moduli real-time il comando di inizio test, fine test e di snap-shot dei dati e comanda i segnali di
trigger hardware. I file di Log e i file di snap-shot creati dalle procedure attive sulle unità di acquisizione vengono scaricati via ftp dal software, che si
occupa anche di costruire i file di dati da inviare al software di calcolo delle prestazioni del motore. La procedura infine registra gli allarmi relativi ai segnali
fuori range che vengono rilevati e li scrive in uni file di report che viene memorizzato su di un HD esterno a fine prova.
Conclusioni
L’impiego della tecnologia CompactRIO ha permesso di acquisire in real-time e memorizzare una grande quantità di segnali provenienti da sensori diversi,
inoltre l’impiego delle schede PXI-DAQ ha permesso di ridurre problemi di sincronizzazione concentrando in un’unica unità l’acquisizione di tutti i segnali
analogici, digitali e seriali, provenienti dal DECU.
Inoltre l'uso di un'architettura distribuita ha ridotto notevolmente la complessità di ciascun componente software considerato separatamente, riducendo di
conseguenza i tempi di sviluppo e di messa a punto del sistema nel suo complesso, oltre ad aumentarne la robustezza e la scalabilità.
Informazioni sull'autore:
M. Antinori
LEONARDO SISTEMI (http://www.leonardosistemi.com)
[email protected] (mailto:[email protected])
Schema a blocchi del banco prova motore
2/5
www.ni.com
Schema a blocchi del sistema di acquisizione dati
Data Monitor - Schermata principale
3/5
www.ni.com
Data Monitor - Schermata di data safety
4/5
www.ni.com
Test Monitor
Informazioni Legali
Questo case study (questo "case study") è stato fornito da un cliente di National Instruments ("NI"). QUESTO CASE STUDY È FORNITO SENZA NESSUN TIPO DI
GARANZIA ED È SOGGETTO AD ALCUNE LIMITAZIONI PIÙ SPECIFICATAMENTE DESCRITTE NEI TERMINI D’USO DI NI.COM
5/5
www.ni.com