Realizzazione del sistema di acquisizione dati per banco prova del motore EJ200

Transcript

1 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 ( 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 ( 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

2 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 ( renato.sciamplicotti@leonardosistemi.com (mailto:renato.sciamplicotti@leonardosistemi.com) Schema a blocchi del banco prova motore 2/5

3 Schema a blocchi del sistema di acquisizione dati Data Monitor - Schermata principale 3/5

4 Data Monitor - Schermata di data safety 4/5

5 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