{'fraction_non_alphanumeric': 0.02880658436213992, 'fraction_numerical': 0.0, 'mean_word_length': 5.443708609271523, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Component-Based, Run-Time Flight Software Modification

Missions involving robotic space flight typically have a way to change the software that controls the flight system, or some part of it, such as an instrument, after launch. Usually this is accomplished by uplinking small sets of binary machine instructions and writing them to known locations in memory. We present an approach, used on the Aquarius mission, that involves replacing running components of, or adding components to, the running software at a higher logical level, specifically at the software architecture level, and on the C++ rather than machine-language level. This approach provides significant advantages in flexibility, robustness, reliability, and testability. We present the component-based flight software (FSW) design features that enable these capabilities. We then discuss the approach used to verify the robustness and reliability of these techniques, and finally describe usages to date.