Developing a Common Telemetry Archiving Architecture

1. Developing a Common Telemetry Archiving Architecture Presented at: Space Telescope Scientific Institute

2. Introduction It is possible and desirable to support multiple missions with a common code infrastructure. For example, a common telemetry archiving system for creating a long-term repository telemetry in packet format to support science and mission operations was developed. With a common approach, development costs, staff, and testing can be shared across multiple missions. The initial cost is significant but is then drastically reduced for subsequent missions.

3. Overview • Background on JHU APL ground systems • The Common Ground Approach • Assessment Product Line • Benefits, Issues, Results

4. JHU/APL Ground System Software Background

5. Single Mission Paradigm • A Dedicated Teams was formed for each mission. + No conflicts in resource scheduling across programs + Responsive to the specific needs of the mission - Knowledge transfer & sharing between teams not inherently facilitated - Potential for redundant tasking • A Snapshot of a previous system was used as basis for next mission No requirement to design for reuse + A new mission did not have to start from scratch + Users were familiar with overall functionality of applications - Not a simple or straight forward task - Modifications for some areas could be comparable to complete rework - Occasional need for complete rework or creation of new applications - Fixes or enhancements could easily shared between active missions • Approximately the same efforts was required to provide the same fundamental functionality for each mission!

6. Single Mission Paradigm Ground System (in development) Ground System (production version)

7. Need for Change JHU/APL was awarded with three NASA missions with overlapping schedules. A Snapshot approach for re-use works for missions with dovetailed schedules, where teams can easily transition between projects. We needed a solution to address limited resources for three active mission. Would like to: Reduce overall development costs Reduce required staff per mission Improve quality Improve estimations in scheduling and cost

8. The Common Ground Approach

9. Overview The primary objective was to support the simultaneous development of multiple NASA missions. • Effort to develop applications that can be used on all missions with little to no customization Staff was reorganized into teams centered around “Product Lines.” • Reduce redundancy by dividing into common functional areas vs. traditional mission-based teams • 4 Product Lines Created: Assessment, Commanding, Planning, Telemetry

10. Simplified MOC Overview POC Commanding Wrapped Telecommand Packets Mission Operations Center Telemetry Transfer Frames Planning Inputs Commanding Planning (Commanding Pre-Processing) CLTU’s Scripts Deep Space Network Planning Inputs Planning Products MOC status Telemetry Spacecraft Users CLCW’s Assessment (Telemetry Post-Processing) Telemetry Supplemented Telemetry Packets Data Products Telemetry Frame SFDU’s Telemetry Packets POC or SSC Data Processing STEREO Ground Software Peer Review: Ground Software Presentation – P. Mckerracher 10/4/2002

11. Initial Steps and Planning The legacy code was evaluated for reuse. • Identify adaptable areas of code A design was established for a new code infrastructure to handle variations in missions but support common core development. • Establish approach to encapsulate mission specific details • Definition of base classes to support new software pattern: Parallel Classes • Used across all functional areas for all missions Risk areas were identified. • Example: Telemetry Archiving Architecture

12. Cartoon Overview Mission X Mission Y Mission Z Mission … + = Generic

13. Code Organization Parallel Class Pattern Ex: Other classes use the TelemetryPacket class without knowing which implementation it is. Classes abide by the interface defined in the generic version. The Configuration Management Tool associates the correct version of classes for a particular build. CCSDS TelemetryPacket (MESSENGER) CCSDS TelemetryPacket (STEREO) Common Ground SW CCSDS TelemetryPacket (generic)

14. Assessment Product Line

15. Assessment Charter Encompasses all activities and applications used to archive, play back, and interpret telemetry for assessing spacecraft health and state, identifying trends, and providing telemetry data to external processes and customers for further analysis and processing. Primary users of the data products include Subsystem Developers, Guidance and Control (G&C) analysts, the Integration & Test team, and the Mission Operations team. The primary users of the data access libraries and higher level data access tools are MOC and testbed software developers and G&C analysts. Responsible for providing historical data from telemetry (e.g., command histories, voltages, temperatures) in forms appropriate for the tasks being performed by its customers (e.g., trend analysis for MOPS). It is additionally responsible for providing access tools in the form of software libraries for use by developers and stand-alone utilities for data consumers.

16. Context Diagram

17. Goals for the Archiving System Faster and consistent response and processing A robust and flexible system • Key for development for multiple missions • Allow mission specific modifications • Lower maintenance costs and support time Allow mission specific requirements and configurations Support wide variety of users: Developers, I&T, MOps, Science Centers Interface with EPOCH T&C

18. Key Design Decisions Provide 3 types of access to data Real-time, Instant Playback, Long-term Playback Ability to “plug in” different processes to convert data from multiple sources and formats Long running, file based processing vs. sockets Applications monitor input directories for new files Archive built from real-time and off-line file processing Access to available archive data while new data is added

19. System Data Flow

20. Benefits, Issues, Results

21. Component Based Architecture Allows for flexibility in configuration Each mission can customize the system Only necessary “plug in” components used Small components focused on a single function have proven to be easier to develop, test, and maintain Future components can be added to create additional layers of functionality

22. Archiving Architecture Seamless merging of data from multiple sources with configurable filtering capabilities Allows multiple points of access to data while processing it into the long term archive Archive files can be used directly as data products to science centers Ability to archive by ground receipt and/or spacecraft time Efficient processing & quick turn around of large amounts of data

23. Common Ground Approach • Challenges • Increased cost of initial development • Increased difficulty in coordinating resources across simultaneous program schedules • Increased resources & staff over commitment on occasion • Increased need to negotiate requirements among multiple missions • Sophisticated configuration management system is needed • Tightly manage modifications to “generic” classes • Complexity of system configuration remains an issue Problems now reported due to configuration

24. Common Ground Approach • Benefits • Shared cost of development across multiple NASA missions • MErcury Surface, Space ENvironment, GEochemistry, and Ranging (MESSENGER) • Solar-Terrestrial Relations Observatory (STEREO) • New Horizons • Reduced redundancy & capitalized on domain knowledge • Supports the needs of all current missions • Increased reliability through repeated testing & use • Increased familiarity among users • Solid base to free up resources to add new levels functionality to be layered on top • Decreased development time & cost for subsequent missions • A telemetry archiving system can be brought on-line for a new mission in a week

25. Comparison of Total Change Requests

26. Comparison Shifted for Development Phase

27. What To Tackle Next • Release of complete Ground SW Infrastructure • Address next level of functionality for Assessment PL • Rely on a sound infrastructure of telemetry data flow & archiving • Advance satellite/spacecraft State of Health (SOH) assessment tools • Search for solutions & technologies offered by other organizations • Identify emerging technologies that JHU/APL could help cultivate