Unmanned Space Vehicle Program: Electrical Ground Control Equipment (EGCE

Author(s):
M. Ciaccini - VITROCISET
R. Richiello - CIRA
M. Mazzoccanti - VITROCISET
A. Costantino - VITROCISET
G. Emiliani - VITROCISET
F. Innocenti - VITROCISET
D. Mancuso - VITROCISET
G. Milano - VITROCISET
A. Podda - VITROCISET

Industry:
ATE/Instrumentation

Products:
Data Acquisition, Digital Multimeters, LabVIEW, PXI/CompactPCI, Signal Conditioning

The Challenge:
Supply the Electrical Ground Control Equipment (EGCE) system for the CIRA (Italian Aerospace Research Centre) program PRORA-USV (Unmanned Space Vehicle). The EGCE had to provide an integrated equipment environment suitable for Electrical Ground Support Equipment (EGSE) and Mission Control Center (MCC) activities. During Assembly, Integration and Validation (AIV) Program of the USV the different components of the reusable vehicle are assembled to form the subsystems and the payload support instruments, and then the whole vehicle is integrated. The process is validated at all levels through a series of check-out and test activities, culminating with the system level validation tests. The equipment used to support this long and crucial phase of the mission preparation can be described as Mechanical and Electrical Ground Support Equipment (EGSE). The operation phase of a mission starts with launch of the vehicle. The equipment necessary to support this phase is located in the ground stations and in the Mission Operations Centre (MOC), in charge of the monitoring and control of USV and ground segment functions. The core of the MOC is the Mission Control Center (MCC).

The Solution:
The EGCE system architecture was designed taking into account the following specifications: - Modularity & Scalability: the equipment and the software used for the launcher check-out phase and for the mission operations phase perform similar functions, therefore a common core system can be used in both environments. To this purpose EGCE was designed as a system based on modular components, communicating on distributed client/server TCP/IP architecture, in order to guarantee an easy addition of new components/functionalities. - Minimize development costs using HW/SW Commercial Off the Shelf (COTS) components (HW: PCI/PXI/SCXI, MIL-1553, TM/TC CCSDS CORTEX baseband unit; SW: Windows OS, IDE: LabVIEW, MSVC, MSSQL). - Usability and Versatility: to provide the end user Customers with an Application Environment, which can be programmed through user friendly guided-wizards in order to tune functionalities of the EGCE.

EGCE
The EGCE consists of the following components, balanced in back ends, also known as High Level Control Systems (HLCS) and front ends, also known as Special Check Out Equipment (SCOE):
 WIRING.SCOE: providing Hard-wired I/O, A/D Sensors Simulation and external USV Power Supply.
 Battery Charge SCOE (BC): providing functionality for both Flight Test Bed (FTB) and Carrier Located Avionics Vehicle (CLAV) systems.
 TELEMETRY.SCOE (TM): providing the uplink and downlink communication functionality
 1553.SCOE: providing either a Bus Controller (BC), a Bus Monitoring (BM) and a Remote Terminal simulation (RT) functionalities over the MIL-1553 bus interface.
 EGSE.DB: providing both a Configuration and an Archive Database.
 HLCS.TCS: a suite of tools providing a Graphical User Interface (GUI) to the EGSE.DB, usually used for the definition of parameters, packets, monitoring limits, Test Procedure (TP) and Customized User Interface (CUI).
 HLCS.TES: SCADA environment dedicated to the TPs execution providing step by step, breakpoints and free running mode functionalities.
 HLCS.PAS: Post Analysis Tools for DB query and report generation.

MCC
The MCC is provided with a dedicated link with the Redù Ground Station (Belgium) which provides USV telemetry and telecommanding through S-Band geo-stationary communication satellite ARTEMIS.
The MMC is composed of the following components:
 TM.SCOE: it handles CCSDS Band S link through TM downlink & TC uplink.
 MCC CONSOLE (MCCC): an operational console to monitor and control the on-board activities.
 TRAJECTORY (TRJ): a 2D/3D GUI Application used to monitor the USV trajectory during flight to detect the splash down area.

PRORA – USV Technologies and Flying Laboratories for Future Generations Reusable Launchers
The Unmanned-Space-Vehicle is a multi-mission, re-usable vehicle under development in CIRA, oriented towards future generations of reusable space vehicles. Reusability aims to drastically reduce costs making access to space easier and faster and will also contribute to the reduction of “space debris”. The new launchers will be autonomous, highly reliable and will require greatly reduced maintenance from one launch to another. They will be made of innovative materials, resistant to very high thermal loads characteristic of trajectories of re-entry phase into the atmosphere, capable of having the vehicle land on any spaceport on the Earth’s surface.

The morning of February 24th 2007 the first Unmanned Italian Space Vehicle successfully completed its first mission. The mission was carried out by the first Flight Test Bed (FTB1) conceived as a Flying Laboratory. The launch took place at 8:30 a.m. from Tortolì airport in Sardinia Italy, closed to the Poligono Interforze of Salto di Quirra (PISQ). The mission ended at 10:30 a.m. with the splash-down of the space vehicle, in an isolated sea zone controlled by PISQ

The first mission, aimed at experimenting the transonic flight of a re-entry vehicle, is basically composed of a Flight Test Bed and a Carrier based on a stratospheric balloon. The basic operation consist of tree main phases: the Ascent phase during which the carrier bring the Flight Test Bed at the release altitude by means of the balloon; the Flight phase in which the FTB1 leaves the carrier and starts flying accelerating to achieve the required velocity to perform the experiments; the Deceleration phase in which the FTB1 open the parachute and ends its mission by water splash down.
The FTB1 is a slender, not-propelled, winged vehicle able to perform experiments on Structure and Aeroelasticity behavior identification, Autonomous Guidance Navigation and Control and Thermo-Aerodynamics.

WIRING SCOE
The list of main features is shown hereunder:
 Time synchronization through IRIG-B signal.
 100 Hz max acquisition rate and conditioning of 16 temperature sensors, 16 pressure sensors, 24 strain sensors, 24 acceleration sensors.
 96 channels acquisition for Voltage, Current, Resistor with 6½ digit multiplexed multimeter.
 Out of limit check and signal calibration (linear, mesh and polynomial).
 Two 1500 watt power supplies management for USV services.
 Generation of 6 voltage and/or current signals in order to simulate the sensors: accelerometers, strain gages, pressure, and temperature.
 Real time logging.
 External cable set for interfacing.

The CIRA team, which took care of setting up the aircraft, the details of the mission and directing operations inside the airport, has been ready for the launch since 24th January; awaiting suitable weather conditions in order to give the green light to the operations. The right weather conditions occurred last Saturday of February month when it was decided to begin the stratospheric balloon inflating to transport the aircraft, without propeller, up to an altitude of 20 km. Set up in a vertical position, through a verticalization system, the aircraft was hooked up to the balloon and started its ascent, which lasted 2 hours, and which took it first to a floating altitude of 20 km and, once the safety area had been reached, to the established releasing altitude. Here the aircraft was released and reached a Mach 1.07 speed. The experimental phase was carried out, or rather a manoeuvre in transonic conditions carried out fully automatically by the on-board computer with the acquisition of great deal of aero-structural and aerodynamic scientific data. The aircraft is equipped with more than 500 sensors (among pressure heads, structural sensors and accelerometers) which enabled the registration and the transmission to earth of an enormous amount of data, which will be extremely useful for further expected developments of the program.

 

BC SCOE
The list of main features is shown hereunder:
 Management Power and Command lines of USV Electronic Power Supply (EPS) through relays and custom interfaces.
 Handling of USV battery charge, through a two phase A/V configurable algorithm. Each string of eight of the two battery-packs, is monitorized through hard-wired lines and a RS232 of EPS microprocessor port, and is checked in term of voltage, current, temperature and charge time duration.
 Management of 8 external programmable power supplies (750 Watt each). Through GPIB port and its internal circuit protection and compensation the output are controlled in order to prevent V/C out of limit and to balance the voltage loss due cables impedance.
 Detailed report production on charging cycles.

TM SCOE
The TM SCOE is composed of 4 subunits:
 TM Server is based on Server where all the application tasks of TM SCOE run.
 Command Ranging & Telemetry Unit (CORTEX NT) in charge of: processing satellite telemetry (up to six telemetry chains for low-rate applications), satellite telecommanding and satellite ranging.
 Up/Down Converter (TX Frequency: 2255 MHz, RX Frequency: 2025 MHz).
 IF Transceiver used as TM/TC router between a RS422 synchronous and IF 70 MHz.
The TM SCOE can be configured in order to be used in 3 different link scenarios: Ethernet/RS422 Async, RS 422 sync/IF70 MHZ and RF S Band in silent radio mode. Telemetry and telecommand communications are compliant with CCSDS and COP1 standards (Viterbi and Reed Solomon, descrambling). All TM parameters are processed with Out of limit, Out of Range check and signal calibration (linear, mesh and polynomial) and Real time logging.

1553 SCOE
Based on single board stream MIL-1553, produced by AIM, provides BC, BM and RT functionalities:
 Simulation of missing USV RT devices (RTU, EPS and PEX) providing a response to the Bus Controller (OBDH) through a coherent Status Word, and providing the requested loop back between received data (configuration data and command data) and transmitted data (configuration status and simulated measurement data).
 Monitoring the traffic on the bus when some or all subscribers are connected. Providing an archive containing the decomposition of all transfers in terms of parameters, that is their raw values tagged with an accurate time stamp. All 1553 parameters are processed with Out of limit, Out of Range check and signal calibration (linear, mesh and polynomial).

HLCS.TES
HLCS TES allows the execution of one or more instances of the Customizable GUI defined during HLCS.TCS phase. The user can monitor the real time parameters both through graphical object representation (gauges, icons, buttons, labels, graph, etc.) and on a tabular grid. All parameters are qualified with graphical special effects indicating Out of limit, Out of range, Time Stamp and signal quality. User can send single command or run previously defined TPs in automatic or manual mode (step by step, break point, pause stop, start).

TRAJECTORY VISUALIZATION SCOE
 Cartographic 3D real time visualization.
 Instantaneous values of measured parameters (i.e. altitude, velocity, pitch, roll, etc.).
 Historical graphs representation.
 Cartographic 2D representation for predictable splash area.
 Plug-in functionality (capacity of integration of dedicated customer algorithms fed with raw data and output visualization).

MCC
The MCC Control Station realizes the ground control of the USV during the flight mission. According to 'MissionTimeLine' schedule, it allows to keep under control a series of parallel trials:
 the evolution of USV 'On Board Data Handler' (OBDH) machine status
 the state of the communication links
 computes the master alarm of all USV subsystems through aggregation of warning parameters
 traces the execution status of all control procedures
 controls the evolution of the trajectory both nominal and actual
 handles through an internal scheduler manual or programmatic commands, with their default or run time valorised value.

The “MCC Automa Control” is composed of three principal processes:
AutomaHandler:
 manages the state transitions of Automa by examining Telemetry and marks any difference between the expected on board status (its own status) and the actual on board status of Automa;
 schedules and shows to the user the status of Cyclic Control Procedure, TimeLine Control Procedure respecting the start times.
TriggerEventListener:
 manages the presentation of an asynchronous Event during the mission;
 controls Telemetry and user iterations, continuously, and eventually sends commands to the Virtual Machine (all kind of priority).
Virtual Machine:
 The “Virtual Machine” is an entity that can execute commands coming from TriggerEventListener and AutomaHandler processing the CPU script.

MCC “CPU Script” (Control Procedure USV Script) is a language that generates Control procedures like a sequence of a Macro-Language’s instructions.
“CPU Script” allows to build complex sequences using sound instructions as following:
 IF <cond.> THEN GOTO <LABEL_true> ELSE GOTO < LABEL _false>;
 EXECUTE <TC>;
 BECOME <STATUS>;
 WAIT <ms>;
 NOTIFY <message>;
 DEFINE LABEL <LABEL_NAME>;
 END LABEL;
The MCC CPU Script has an Interpreter, that works at run time, named “CPU Interpreter”. The “CPU Interpreter” is in charge of writing the “CPU Script” instructions in a format suitable for the “Virtual Machine”.
At run time, the interpreter reads the Script from the text file, line by line, and puts the simple instructions in a vector, ready to be executed by the “Virtual Machine” in a consecutive order.

Browse All Case Studies »