Propulstion Test Facility
Rocket Propulsion Test System
Project details
Nammo UK, a leading provider of spacecraft propulsion solutions, operates several Rocket Engine Test Facilities, which includes two firing sites at J-Site. As part of the National Space Propulsion Test Facility (NSPTF), developed with the UK Space Agency, the J3 site can test engines up to 1,500N in vacuum. The J4 site, being a Sea Level facility, operates at thrust levels up 7,500N. Nammo UK commissioned Avazia to develop a robust SCADA system to control and monitor the J3 Site Valve Control, Vacuum, Cooling Systems, and Site Instrumentation. The system would also be required to perform instrument calibrations to scale raw sensor data and continuously log data and system actions for traceability.
Project challenge
This project required the development of a robust monitoring and control system with safety at its core. The main challenge was creating a control system capable of rapid response to site condition changes to preventor abort engine firing. This system had to interface with four main independent subsystems using different protocols:
- Vacuum System, Cooling System and Site Instrumentation: Connected via Modbus TCP/IP.
- Site Valve Control: Connected using an NI CompactRIO 9040 with 2 NI 9401 C-Series Modules used for firing signals as well as valve control and feedback.
The system needed continuous monitoring, logging, data fidelity checks, and alarm/ warning communication, with an intuitive user interface that clearly displayed system states and prioritized important warnings and alarms for quick safety responses.
Project solution
The NSPTF SCADA System was divided between Real-Time (RT)software on the cRIO and an HMI on a connected Windows PC. The RT software handled primary functionality, while the HMI was for system configuration and operation. While the SCADA was not designed to run headless without the HMI connected, handling all subsystems on the RT provided a robust centralised mechanism for monitoring warnings and alarms and taking any necessary action as a result without the uncertainty that can be introduced by PC based operating systems. Subsystems were monitored asynchronously, with a watchdog on the FPGA to prevent or abort arming/firing if the HMI connection was lost.
Key features included:
- Alarm and Warning Configurability: Alarms and warnings for all channels were configurable via the HMI, and the RT software immediately checked the alarm/ warning criteria for each channel immediately after acquisition.
- Data Display: Subsystem data such as pressure, temperature and valve states were sent to the HMI for display on subsystem schematics.
- User-Friendly Calibration: Users could easily calibrate channels by acquiring data points and performing polynomial curve fitting.
- Flexible Configuration Files: These files allowed Nammo to modify system behaviour and define compound alarms without changing the software.
Additionally, the software and code architecture were meticulously designed to ensure both robustness and flexibility:
- Modular Architecture: The SCADA system was built using a modular approach, allowing each subsystem to operate independently. This separation ensured that issues in one part did not affect the overall system functionality.
- Distributed Processing: Alarm and warning evaluations were distributed across the software rather than being centralised. This approach minimized latency and improved response times, crucial for safety-critical operations.
- Asynchronous Monitoring: By monitoring subsystems asynchronously, the system could handle data acquisition and processing without bottlenecks. This design choice enhanced the system's ability to respond to real-time changes promptly.
- Watchdog Implementation: A watchdog on the FPGA ensured that any loss of connection with the HMI would automatically prevent or abort arming/firing, thereby protecting the system from potential software or hardware failures.
- User Interface Design: The HMI was designed for ease of use, with clear visual indicators and intuitive navigation. Color-coded borders and prioritized alarm lists helped operators quickly assess and respond to system states.
This architecture allowed the system to be highly adaptable, making it suitable for various testing scenarios without requiring software changes.
