1. March 2004 At A Glance The AutoFDS provides a web- based interface to acquire, generate, and distribute products, using the GMSEC Reference Architecture and Standards. Benefits Simplifies integration Facilitates technology infusion Supports evolving operations concepts Enables future missions Summary AutoFDS provides an executive manager and infrastructure for the acquisition, generation, and distribution of flight dynamics products required by the flight operations team (FOT) and the satellite end users (scientists). The AutoFDS performs this function by providing a web-based interface for monitoring spacecraft location and configuration of product delivery, generation of flight dynamic products, the collection and distribution of products, the scheduling of meetings and user e-mail notification. To create this vision and architecture on which to base continued ground system and flight software development efforts at GSFC over the next 10 years, AutoFDS has been developed using the GMSEC Reference Architecture and Standards. GMSEC supports the development of compatible mission support tools that can easily be integrated and made available (as tested). Features Plug-and-Play Components Standard Messages Information Software Bus Platform Transparency GMSEC Flight Dynamics Automation Overview The Flight Dynamics Analysis Branch (NASA GFSC Code 595) has partnered with the Mission Applications Branch (NASA GSFC Code 583) and a.i. solutions, Inc. in order to support TRMM Reengineering activities. This work is being undertaken using the development of the Autonomous Flight Dynamics System (AutoFDS). Work completed to date includes the additional development and enhancement of the AutoFDS, as well as participating in various meetings, presentations, and demonstrations of the AutoFDS. Work continues on the following: further enhancements of the AutoFDS in order to support TRMM Reengineering activities which includes product definition, user interface improvements, and the addition of capabilities such as file event based execution to the current system. Planned work to be carried out under the GSFC Mission Services Evolution Center (GMSEC) includes further TRMM Reengineering activities as well as the integration of the AutoFDS with the AutoProducts System, and the definition of XML based messages. NASA GSFC Mission Services Evolution Center, Code 581 Greenbelt, Maryland 20771 http://gmsec.gsfc.nasa.gov email: gmsec@nasa.gov

2. March 2004 GMSEC Flight Dynamics Automation Overview The AutoFDS uses the GMSEC Reference Architecture and its flight/ground system instantiation to have characteristics that render it an attractive choice for GSFC missions. Development Lab AutoFDS, AutoProducts and the GMSEC Reference Architecture is validated in the GMSEC Development Lab. The GMSEC Development Lab is located in Building 23 on the GSFC campus. A local area network enables connectivity of other campus labs facilitating development and testing. The GMSEC Development Lab provides multiple operating systems, languages, and communications protocols. Activities include development, bench marking, demonstrations, evaluations, system integration, functional testing, and what-if scenarios. New components can easily be brought into the GMSEC Development Lab, augmented with adapters, and be tested with other components. One of the most beneficial uses of the GMSEC Development Lab is for interested missions to try out GMSEC compliant GOTS and COTS for evaluating potential flight and ground system components. GMSEC Flight Dynamics Automation Features The Reference Architecture provides AutoFDS and AutoProducts with features that include Plug-and-Play Components, Standard Messages, and the Software Information Bus. Plug-and-Play Components can be core functional applications/ subsystems such as Telemetry & Command, Planning & Scheduling, Assessment & Archive, Guidance Navigation & Control, and Simulation & Modeling or new stand-alone functions. AutoFDS and AutoProducts are GMSEC-compliant and use components which publish/subscribe to Standard Messages with defined contents. Standard Messages are used as to request a service, to share data, or to provide status. The use of a GMSEC Applications Programming Interface (API) shields the components from dependencies on communication protocols, operating systems, and hardware platforms thus facilitating platform transparency for the components. The API interfaces with the underlying middleware to route the messages over the Software Information Bus and also to pack/unpack the message contents. The Software Information Bus provides the communications pipe used to carry information between GMSEC components. GMSEC can swap different middleware products in and out, providing additional flexibility. Legacy components interface to the Software Information Bus using an Adapter. The Adapter is custom software that translates Legacy Component messages and/or message protocols to those that are GMSEC-compliant. Additionally, legacy components may, in combination with GMSEC, continue to use legacy interconnections. ·More flexible mission component selection ·Standard message formats for component information exchange ·Improved component reuse ·Quick & easy functional component integration ·Middleware support for GOTS/COTS software ·Scalable, extensible ground & flight system architecture ·Exchangeable & dynamic component activation on operating ground or flight system ·Increased system wide automation ·Additional capabilities added to ground/flight system without impacting existing system/design ·Mission and GSFC-wide configuration management ·Security, remote & shared access ·Shared operations with another site (University, commercial provider) ·Mission critical system risk improvement ·Collaboration across missions ·Greater choice & lower cost through standardized component communications ·Anticipation of movement of some functions on-board