Sistema di controllo/acquisizione del banco prova di fuoco dei motori spaziali "Zefiro"

Author(s):
N. De Liguori - AVIO
G. Desiderio - ARTS

Industry:
Government/Defense, Aerospace/Avionics

Products:
Real-Time Module, Digital I/O, PXI/CompactPCI, SCXI-1190, SCXI

The Challenge:
Realizzare il sistema elettrico di controllo/monitoraggio del banco statico per le prove di fuoco dei motori "Zefiro". I motori forniscono la spinta propulsiva di secondo e terzo stadio del lanciatore spaziale "VEGA".

The Solution:
L'hardware è costituito da un certo numero di PC commerciali e da alcuni PXI 1042, corredati di opportuni moduli di I/O. Le macchine sono collegate fra loro in una LAN ethernet. Il software è stato interamente realizzato in LabVIEW, sia sui PC (host) che sui PXI (target).

La Avio S.p.A. sta sviluppando, nell'ambito del programma "VEGA", i motori a propellente solido "Zefiro", che forniranno la propulsione al secondo e al terzo stadio di un vettore di lancio per piccoli satelliti. I motori verranno provati e qualificati con un certo numero di "prove di fuoco statiche". In queste prove i motori vengono accesi e osservati durante la loro combustione, tramite la misura di un certo numero di grandezze fisiche. Durante la prova i motori sono vincolati a terra, in modo che ne sia impedito ogni movimento. Nelle prove si farà uso di un opportuno banco statico, il cui controllo/monitoraggio è affidato ad un complesso sistema elettrico/informatico, simile a quelli usati nelle basi di lancio. Il sistema elettrico/informatico è basato su una LAN ethernet a cui sono collegati dei computer Real-Time e dei PC commerciali. I computer Real-Time svolgeranno le funzioni di controllo di processo a basso livello, e si interfacceranno direttamente con gli apparati di bordo del motore. I PC svolgeranno la funzione di stazioni di controllo remote per gli operatori che condurranno la prova dal bunker di comando. Il sistema è stato progettato dalla Avio S.p.A.., usando prodotti NI. Il software, scritto in LabVIEW, è stato sviluppato dalla ARTS s.r.l..

Il programma "VEGA" si propone di sviluppare un vettore per la messa in orbita di piccoli satelliti. Il VEGA, a cui partecipa un consorzio di industrie europee coordinate dalla ELV S.p.A. in qualità di Prime Contractor e dall'ESA (European Space Agency), dovrà essere realizzato in tempi brevi ed a basso costo, dato che uno dei suoi obiettivi principali è la competitività sul mercato mondiale. La Avio S.p.A. è impegnata da diversi anni nello sviluppo del motore "Zefiro", che fornisce la propulsione di secondo e terzo stadio del vettore. Il motore "Zefiro" viene provato in alcune prove di combustione, in una particolare configurazione "statica" di test. In queste prove il motore viene ancorato in una gabbia metallica che lo mantiene fermo e vincolato ad un bastione, quindi viene acceso ed osservato durante il suo funzionamento. I gas di scarico, che forniscono la spinta propulsiva del motore, fuoriescono da un ugello mobile, il quale viene pilotato da una opportuna unità di controllo elettronica che vettorizza la spinta verso delle direzioni programmate. Durante la prova vengono acquisiti un certo numero di sensori, che misurano le caratteristiche tecniche del motore.
Per la conduzione del test è stato allestito, nel poligono militare in cui viene eseguito il tiro, un opportuno Banco Prova di Fuoco Statica (SFTB). Il banco è costituito da una parte meccanica, da varie attrezzature di supporto, da un sistema elettrico e da alcune infrastrutture edili.
Il sistema elettrico del banco di prova (TBES), simile ai sistemi elettrici usati nelle basi di lancio, svolge principalmente le seguenti funzioni:
1. Controllare la sequenza di fuoco e gestire il tiro (armamento e accensione motore, movimentazione ugello durante la combustione, gestione sicurezze, distruzione del motore in caso di grave anomalia);
2. Acquisire e registrare i dati provenienti dai sensori installati sul motore, i quali ne misurano le caratteristiche e le prestazioni;
3. Supportare e automatizzare le varie attività della campagna di tiro (aquisizione dati metereologici, gestione procedure, consensi e autorizzazioni, allarmi, monitoraggio area, video riprese, ecc.).
Il TBES è stato strutturato in quattro segmenti:
1. FTCC: Firing Test Control Console, il quale svolge le funzioni del punto 1;
2. IDMS: Instrumentation and Data Management Subsystem, il quale svolge le funzioni del punto 2;
3. TFCC: Test Facility Control Console, il quale svolge le funzioni del punto 3;
4. EPGDS: Electric Power Generation and Distribution Subsystem, il quale fornisce l'energia elettrica agli altri sottosistemi.
Le prove verranno condotte in un poligono militare opportunamente attrezzato per lo scopo.
Dal punto di vista logistico, si identificano le seguenti aree/locali sul sito di prova:
1. TCR: Bunker di comando - Sala controllo (è il locale dal quale gli operatori conducono la prova di fuoco).
2. IER: Locale strumentazione elettronica (è un locale, situato in prossimità dell'area di tiro, nel quale viene alloggiata la strumentazione elettronica, come ad esempio i sistemi di acquisizione, che non possono stare troppo distanti dal motore; il locale si trova a circa 150 m dal bunker di comando).
3. TB: Area di tiro (è la zona in cui è situato il banco, e che comprende il bastione, la gabbia e il motore).
Dal punto di vista organizzativo, il team che conduce il tiro è strutturato nel modo seguente: 
-

FUNZIONE	RESPONSABILITA'
Ufficiale Poligono	Coordinamento delle attività del Poligono
Direttore di Tiro	Responsabilità decisionale del Firing Test
Direttore Operativo/ Operatore Distruzione	Coordinamento e conduzione del Firing Test
Responsabili di area / supervisori tecnici	Supporto tecnico su attività specifiche
Operatori	Personale tecnico operativo alle Stazioni di Controllo
1) Operatore al fuoco 2) Operatore impianti 3) Operatore acquisizioni 4) Operatore TVC (movimentazione ugello) 5) Operatore allarmi e monitor 6) Operatore procedura di fuoco
Clienti e osservatori	Personale non operativo

Ognuno degli operatori è dotato di una propria stazione di controllo (RCS), e svolge una funzione specifica. Il Direttore di Tiro e i vari responsabili presenti in sala controllo seguono su uno schermo proiettato su una parete le azioni che gli operatori compiono dalle loro postazioni remote.
La disposizione del personale (tecnici, operatori, supervisori, ecc.) in sala controllo durante il tiro è riportata nella seguente figura:
La architettura del TBES è riportata nel seguente schema semplificato:

Il sottosistema FTCC è realizzato con una unità PXI e con un certo numero di PC. Il PXI svolge le funzioni di controllo di processo a basso livello, e si interfaccia direttamente con gli apparati di bordo del motore tramite dei moduli I/O DAQ e dei moduli switches SCXI. I PC fungono da stazioni di controllo remoto (RCS) per gli operatori. Il SW applicativo del PXI è scritto in LabVIEW RT e gira sotto il sistema operativo Pharlap. Il SW applicativo dei PC è scritto in LabVIEW base e gira sotto il sistema operativo MS Windows 2000 Professional. Gli hosts (PC) e il target (PXI) comunicano tra di loro tramite una LAN ethernet dedicata, con protocollo UDP/IP, in cui il PXI trasmette in modalità broadcast i suoi dati ai PC. In questo modo le RCS sono sempre allineate tra loro, e riportano dati coerenti ai vari operatori. Il numero di PC collegati al PXI può essere variato a discrezione, permettendo infinite configurazioni multi-operatore. Una opportuna logica di accessi al sistema permette di definire e di gestire diverse tipologie di operatore. Configurando diversi account è possibile associare abilitazioni, privilegi e inibizioni particolari a ciascuna figura di operatore. Il sistema è dotato di una specie di "scatola nera", che registra tutti gli eventi di rilievo e tutte le operazioni eseguite dagli operatori, e su richiesta compila un report con la cronologia degli eventi. Il sistema è in grado di eseguire sia la sequenza automatica nominale di fuoco, sia un certo di numero di sequenze di emergenza, nel caso in cui si verifichino delle anomalie o dei malfunzionamenti. Oltre alla configurazione/esecuzione della sequenza automatica di fuoco, il FTCC consente di eseguire una diagnostica sul sistema e di generare degli allarmi in caso di anomalia.
Il sottosistema IDMS è realizzato con un PC, che funge da stazione di controllo remoto per l'operatore, connesso ad un certo numero di unità PXI, i quali eseguono a basso livello la acquisizione/registrazione delle misure. Come per il SW FTCC, il SW applicativo del PXI è scritto in LabVIEW RT e gira sotto il sistema operativo Pharlap, mentre il SW applicativo dei PC è scritto in LabVIEW base e gira sotto il sistema operativo MS Windows 2000 Professional. Anche in questo caso l'hosts (PC) e i targets (PXI) comunicano tra loro tramite una LAN ethernet dedicata. L'hardware del sistema (numero di PXI, schede di I/O DAQ, eventuali moduli di condizionamento SCXI, ecc.) possono essere variati a discrezione, in infinite configurazioni. Il sistema va configurato a due livelli. Il primo livello descrive la configurazione HW, e quindi le risorse fisiche di cui è dotato il sistema (PXI, SCXI, schede DAQ, ecc.), e viene fatto con il software standard NI MAX. Il secondo livello definisce la configurazione di acquisizione (canali di misura e loro caratteristiche fisiche, raggruppamento canali in tasks di acquisizione, modalità di acquisizione e parametri associati, ecc.), e viene fatto dal programma applicativo. Il sistema, alla accensione, legge la configurazione HW (quella generata con MAX), e comunica all'operatore le risorse hardware disponibili. Sulla base di queste risorse, l'operatore può creare diverse configurazioni di acquisizione, che possono essere caricate dinamicamente sul sistema per poter essere eseguite. La acquisizione può essere avviata in diverse modalità (manuale, triggerata HW, con o senza registrazione dati, ecc.). Alcuni canali acquisiti possono essere visualizzati in tempo reale sulla stazione dell'operatore. Anche in questo caso, il sistema registra tutti gli eventi di rilievo (malfunzionamenti, comandi operatore, trigger, ecc.) e su richiesta genera automaticamente un report. In caso di malfunzionamento, il sistema invia un segnale ad altri sottosistemi, che possono così gestire la situazione nel modo più adeguato. Ad acquisizione terminata, il sistema provvede a convertire i dati salvati in un formato ASCII standard, e a presentarli all'operatore in varie modalità (visualizzazione a video, stampa tabulare e grafica, reportistica, ecc.).
Il sottosistema TFCC è costituito dall'insieme di singoli componenti HW e SW, ognuno dei quali svolge una funzione specifica. Una delle funzioni più importanti del TFCC è la gestione della procedura di fuoco. La procedura di fuoco consiste in una complessa serie di operazioni manuali e automatiche (integrazione di componenti, verifiche, misure, predisposizione di impianti, attivazione di servizi, evacuazione area tiro, armamenti, abilitazioni, operazioni varie, ecc.) che devono essere eseguite con il massimo rigore prima del test. Il controllo di questa procedura, includente anche gli interventi di ripristino necessari in caso di anomalia, sono stati affidati ad un opportuno sistema informatico, che fornisce una specie di "guida" agli operatori che conducono la prova. Il SW, scritto in LabVIEW ed eseguito su un PC, permette quindi di visualizzare i vari step della procedura, di smarcarli una volta che siano stati eseguiti, di registrare tempi e parametri, di indirizzare la procedura nel percorso più opportuno in caso di anomalia, e di generare un report in un formato standard, con la cronologia degli eventi associati alla procedura. L'automazione della procedura di fuoco facilita il rispetto dei requisiti di sicurezza, affidabilità e qualità del test, molto rigorosi in campo aerospaziale.
La realizzazione del TBES è uno dei punti di verifica più importanti del programma VEGA. La sua realizzazione fa seguito alla esperienza della ECU, usata in passato per il tiro "Zefiro 16", e allo sviluppo dell'EGSE del VEGA, ed è in linea con le scelte tecniche già fatte per questi prodotti. Queste scelte si sono rivelate adeguate ed hanno dimostrato come la qualità e le prestazioni del prodotto si possano conciliare con successo con i vincoli di tempi e costi imposti dal programma.

Author Information:
For more information on this Case Study, contact:
N. De Liguori
AVIO
Tel: 06/97285456
nicola.deliguori@service.aviogroup.com

Browse All Case Studies »