The Johns Hopkins University Applied Physics Laboratory (APL) developed a flight software system which has been used for multiple NASA missions. One fundamental component of this software system is a centralized command executive that has been successfully demonstrated on four ongoing missions: Thermosphere, Ionosphere, Mesosphere, Energetics and Dynamics (TIMED), MErcury Surface Space EN vironment GEochemistry and Ranging (MESSENGER), New Horizons, and most recently Solar TErrestrial RElations Observatory (STEREO). Through the development and operations of these missions, developers and operations personnel gained a significant amount of experience with this flight software system. This system provides all of the command capabilities required to meet the common requirements of these missions. In order to support mission requirements of long round trip light time or long periods between command contacts, all of these spacecraft perform normal operations through onboard command sequences and incorporate autonomous fault protection capabilities. This paradigm introduces requirements to provide some degree of command prioritization and the need to guarantee command execution order. The centralized command executive meets these requirements. Plug-and-play architectures break this paradigm in that they often require each component to be capable of handling its own commands. In order to truly distribute functionality into plug-in modules or applications, each module or application needs to be self sufficient. This paper details efforts to prototype a centralized command management application to be used within a plug-and-play flight software architecture. This prototype was created for evaluation for the Radiation Belt Storm Probes (RBSP) mission and implements much of the functionality of the existing STEREO command executive flight software within a plug-and-play messaging architecture. Within this prototype application, the familiar aspects of command priorities are maintained, and command execution order is guaranteed where required. This paper discusses the performance of this prototype as well as approaches to reduce the overhead required to support centralized command management, while still providing for distributed command execution.
展开▼
