This article is from the 2024 Technical Update
Autonomous flight termination systems (AFTS) are being progressively employed onboard launch vehicles to replace ground personnel and infrastructure needed to terminate flight or destruct the vehicle should an anomaly occur. This automation uses on-board real-time data and encoded logic to determine if the flight should be self-terminated. For uncrewed launch vehicles, FTS systems are required to protect the public and governed by the United States Space Force (USSF). For crewed missions, NASA must augment range AFTS requirements for crew safety and certify each flight according to human rating standards, thus adding unique requirements for reuse of software originally intended for uncrewed missions. This bulletin summarizes new information relating to AFTS to raise awareness of key distinctions, summarize considerations and outline best practices for incorporating AFTS into human-rated systems.
Key Distinctions – Crewed v. Uncrewed
There are inherent behavioral differences between uncrewed and crewed AFTS related to design philosophy and fault tolerance. Uncrewed AFTS generally favor fault tolerance against failure-to-destruct over failing silent
in the presence of faults. This tenet permeates the design, even downto the software unit level. Uncrewed AFTS become zero-fault-to-destruct tolerant to many unrecoverable AFTS errors, whereas general single fault
tolerance against vehicle destruct is required for crewed missions. Additionally, unique needs to delay destruction for crew escape, provide abort options and special rules, and assess human-in-the-loop insight, command, and/or override throughout a launch sequence must be considered and introduces additional requirements and integration complexities.
AFTS Software Architecture Components and Best-Practice Use Guidelines
A detailed study of the sole AFTS currently approved by USSF and utilized/planned for several launch vehicles was conducted to understand its characteristics, and any unique risk and mitigation techniques for effective human-rating reuse. While alternate software systems may be designed in the future, this summary focuses on an architecture employing the Core Autonomous Safety Software (CASS). Considerations herein are intended for extrapolation to future systems. Components of the AFTS software architecture are shown, consisting of the CASS, “Wrapper”, and Mission Data Load (MDL) along with key characteristics and use guidelines. A more comprehensive description of each and recommendations for developmental use is found in Ref. 1.
Best Practices Certifying AFTS Software
Below are non-exhaustive guidelines to help achieve a human-rating
certification for an AFTS.
References
