Autonomous Flight Safety System
We are developing an in-house Autonomous Flight Termination System (AFTS), based on the Autonomous Flight Termination Unit (AFTU) developed by Kennedy Space Center and DARPA and made available to the commercial sector. A first test flight of our system prototype is currently targeted for 2020 onboard a suborbital-sounding rocket. The system is a critical safety component of the Helios small launch vehicle.
The AFTS is an independent, self-contained subsystem mounted onboard a launch vehicle. The AFTS autonomously makes flight termination/vehicle destruct decisions using configurable software-based rules implemented on redundant flight processors using data from redundant navigation sensors. The ability to perform this function on the launch vehicle results in tremendous cost savings by eliminating the need for ground personnel, transmitters, telemetry receivers, and radars historically used for this purpose. It also provides global coverage because launch vehicles using AFTS no longer need to be launched from a dedicated range. AFTS can also support multiple vehicles simultaneously, such as flyback boosters.
A necessary companion to the AFTS, Kennedy Space Center and the Air Force combined their expertise to jointly develop the Core Autonomous Safety Software (CASS) that is flown on any launch vehicle utilizing the AFTU technology. CASS is mission-critical for any launch vehicle equipped with an AFTS because it contains the mission rules and parameters used by the AFTS to make flight termination/vehicle destruct decisions. This cooperative joint effort was key to the development of CASS software that meets all safety-critical requirements for operational use.
The main benefit of the AFTS is to decrease the need for permanent ground-based range safety assets with a corresponding saving in operational costs, and to increase the number of potential launch sites and corridors. The ultimate goal of this project is to produce an autonomous flight safety reference design that may be commercialized for industry use.
The system uses a commercial off-the-shelf (COTS) chassis, a NASA-designed custom board, NASA-developed wrapper interface software, and the Core Autonomous Safety Software (CASS) running on a COTS processor. The range requires that the AFTS system consists of redundant chassis with redundant sensor inputs. The sensor inputs can be GPS, INS, IMU, accelerometers, or any combination thereof. All sensor inputs can be available to both chassis.
The AFTS can augment or replace the functions of the traditional human in-the-loop system. Redundant AFTS processors evaluate data from onboard Global Positioning System (GPS) and inertial measurement unit (IMU) navigation sensors. Configurable rule-based algorithms are used to make flight termination decisions. The mission rules are developed by the local Range Safety Authorities using the inventory of rule types taken from current human-in-the-loop operational flight safety practices.
Features
Traditional ARM then FIRE destruct command sequence
- One master firing circuit with four inhibits in line with initiator during normal ground operations
- No (known) single-point failures that could produce inadvertent firing
- Multiple single point logic gate failures that could inhibit FIRE command — two CSLIC units in parallel required for total system compliance to RCC319
- Majority voting performed in hardware to activate FIRE
- Unanimous `voting’ performed in hardware for RTL
- Continued use of redundant/parallel CRD and
- ADS must be supported external to AFSS
- CSLIC is the only custom hardware used by AFSS.
Independence-from-vehicle systems as much as practically possible
- Configurable hardware architecture (fixed for a specific vehicle)
- Configurable mission rules (fixed for a specific flight profile)
- NAV sensor redundancy management performed in software
- Redundancy management provides for graceful degradation as sensors and processors fail (within constraints set by Range Authorities)
- Flight Processor/Command Function redundancy management performed in hardware via redundant CSLIC architecture
- Processor-to-processor communications minimized
- Mission rules evaluated against one selected navigation solution
- Majority voting on ARM/FIRE with tie resulting in function
- AFSS application must generate a square-wave pulse train monitored by a circuit independent of the processor
Mission Rules
- Parameter Threshold Violation — a trajectory value that exceeds an allowed limit
- Rocket stage ignition and burnout detection
- Physical Boundary Violation — present position or Instantaneous Impact
- Point (IIP) is out of a corridor or in an exclusion zone Gate Rule
- Two-Point Gate Rule — determines if a current position or IIP has crossed a gate formed by two points
- Moving Gate Rule — determines if the current position or IIP is in front of or behind a moving two-point gate
- Green-Time Rule — determines how long the rocket can safely fly without receiving valid updated tracking data
All mission rules can be dependent upon other mission rules.
A rule violation does not need to result in a flight termination action.
