Leeha Herrera Nov 2005 L Herrera Developing a Common Telemetry Archiving Architecture Presented at: Space Telescope Scientific Institute.

Slides:



Advertisements
Similar presentations
Test Automation Success: Choosing the Right People & Process
Advertisements

HP Quality Center Overview.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Software Engineering CSE470: Process 15 Software Engineering Phases Definition: What? Development: How? Maintenance: Managing change Umbrella Activities:
SEP1 - 1 Introduction to Software Engineering Processes SWENET SEP1 Module Developed with support from the National Science Foundation.
SOFTWARE MAINTENANCE 24 March 2013 William W. McMillan.
11.1 Lecture 11 CASE tools IMS Systems Design and Implementation.
Copyright 2002 Prentice-Hall, Inc. Chapter 4 Automated Tools for Systems Development 4.1 Modern Systems Analysis and Design Third Edition.
GLAST LAT ProjectISOC CDR, 4 August 2004 Document: LAT-PR-04500Section 3.11 GLAST Large Area Telescope: Instrument Science Operations Center CDR Section.
R R R CSE870: Advanced Software Engineering (Cheng): Intro to Software Engineering1 Advanced Software Engineering Dr. Cheng Overview of Software Engineering.
Copyright © 2007 Software Quality Research Laboratory DANSE Software Quality Assurance Tom Swain Software Quality Research Laboratory University of Tennessee.
IACT 901 Module 9 Establishing Technology Strategy - Scope & Purpose.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Course Instructor: Aisha Azeem
ENVIRONMENTAL DATA MANAGEMENT & SHALE GAS PROGRAMS INTERNATIONAL PETROLEUM ENVIRONMENTAL CONFERENCE NOVEMBER 14, 2013.
November 2011 At A Glance GREAT is a flexible & highly portable set of mission operations analysis tools that increases the operational value of ground.
Capability Maturity Model
March 2004 At A Glance ITOS is a highly configurable low-cost control and monitoring system. Benefits Extreme low cost Database driven - ITOS software.
Chapter 9 – Software Evolution and Maintenance
System Design/Implementation and Support for Build 2 PDS Management Council Face-to-Face Mountain View, CA Nov 30 - Dec 1, 2011 Sean Hardman.
Android Core Logging Application Keith Schneider Introduction The Core Logging application is part of a software suite that is designed to enable geologic.
Problems with reuse – Increased maintenance costs; lack of tool support; not-invented- here syndrome; creating, maintaining, and using a component library.
The Pursuit for Efficient S/C Design The Stanford Small Sat Challenge: –Learn system engineering processes –Design, build, test, and fly a CubeSat project.
Software Engineering Muhammad Fahad Khan
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
Chapter 2 The process Process, Methods, and Tools
Dillon: CSE470: SE, Process1 Software Engineering Phases l Definition: What? l Development: How? l Maintenance: Managing change l Umbrella Activities:
N By: Md Rezaul Huda Reza n
Aerospace Testing 2006 A Centralized Approach To Ground Support Software To Reduce Technical Risk and Overall Mission Costs Thomas Hauck GSE Software,
Data Management Subsystem: Data Processing, Calibration and Archive Systems for JWST with implications for HST Gretchen Greene & Perry Greenfield.
MSF Requirements Envisioning Phase Planning Phase.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
At A Glance VOLT is a freeware, platform independent tool set that coordinates cross-mission observation planning and scheduling among one or more space.
111 Notion of a Project Notes from OOSE Slides – a different textbook used in the past Read/review carefully and understand.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
CHAPTER TEN AUTHORING.
Doug Tody E2E Perspective EVLA Advisory Committee Meeting December 14-15, 2004 EVLA Software E2E Perspective.
GEONS Ground Support System Java 7, JavaFX and the NetBeans Platform supporting NASA Missions Operations.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Middleware for FIs Apeego House 4B, Tardeo Rd. Mumbai Tel: Fax:
August 2003 At A Glance VMOC-CE is an application framework that facilitates real- time, remote cooperative work among geographically dispersed mission.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Systems Analysis and Design in a Changing World, Fourth Edition
Construction, Testing, Documentation, and Installation Chapters 15 and 16 Info 361: Systems Analysis and Design.
9 Systems Analysis and Design in a Changing World, Fourth Edition.
Concepts behind OAIS Archive Task Team WGISS 23 May 21 – 25, 2007 Hanoi, Vietnum.
March 2004 At A Glance NASA’s GSFC GMSEC architecture provides a scalable, extensible ground and flight system approach for future missions. Benefits Simplifies.
March 2004 At A Glance autoProducts is an automated flight dynamics product generation system. It provides a mission flight operations team with the capability.
March 2004 At A Glance SIMSS is a flexible & easily configurable collection of modules for mission testing, simulations, and real-time operations. Benefits.
Chapter 6 CASE Tools Software Engineering Chapter 6-- CASE TOOLS
Design and Implementation of Spacecraft Avionics Software Architecture based on Spacecraft Onboard Interface Services and Packet Utilization Standard Beijing.
Software Engineering Chapter: Computer Aided Software Engineering 1 Chapter : Computer Aided Software Engineering.
Chapter 4 Automated Tools for Systems Development Modern Systems Analysis and Design Third Edition 4.1.
August 2003 At A Glance The IRC is a platform independent, extensible, and adaptive framework that provides robust, interactive, and distributed control.
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
March 2004 At A Glance The AutoFDS provides a web- based interface to acquire, generate, and distribute products, using the GMSEC Reference Architecture.
Managing Multiple Projects Steve Westerman California Department of Motor Vehicles Steve Young Mathtech, Inc.
Advanced Software Engineering Dr. Cheng
Modern Systems Analysis and Design Third Edition
Modern Systems Analysis and Design Third Edition
Design and Implementation of Spacecraft Avionics Software Architecture based on Spacecraft Onboard Interface Services and Packet Utilization Standard Beijing.
Study of Tools for Command and Telemetry Dictionaries
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Modern Systems Analysis and Design Third Edition
Modern Systems Analysis and Design Third Edition
Capability Maturity Model
Capability Maturity Model
Modern Systems Analysis and Design Third Edition
Chapter 2: Building a System
Building a “System” Moving from writing a program to building a system. What’s the difference?! Complexity, size, complexity, size complexity Breadth.
Presentation transcript:

Leeha Herrera Nov 2005 L Herrera Developing a Common Telemetry Archiving Architecture Presented at: Space Telescope Scientific Institute

Nov 2005 L Herrera 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.

Nov 2005 L Herrera Overview Background on JHU APL ground systems The Common Ground Approach Assessment Product Line Benefits, Issues, Results

Nov 2005 L Herrera JHU/APL Ground System Software Background

Nov 2005 L Herrera 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!

Nov 2005 L Herrera Single Mission Paradigm Ground System (in development) Ground System (production version)

Nov 2005 L Herrera 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

Nov 2005 L Herrera The Common Ground Approach

Nov 2005 L Herrera 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

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

Nov 2005 L Herrera 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

Nov 2005 L Herrera Cartoon Overview += Generic Mission Y Mission X Mission Z Mission …

Nov 2005 L Herrera 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 (generic) CCSDS TelemetryPacket (MESSENGER) CCSDS TelemetryPacket (STEREO) Common Ground SW

Nov 2005 L Herrera Assessment Product Line

Nov 2005 L Herrera 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.

Nov 2005 L Herrera Context Diagram

Nov 2005 L Herrera 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

Nov 2005 L Herrera 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

Nov 2005 L Herrera System Data Flow

Nov 2005 L Herrera Benefits, Issues, Results

Nov 2005 L Herrera 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

Nov 2005 L Herrera 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

Nov 2005 L Herrera 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

Nov 2005 L Herrera 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

Nov 2005 L Herrera Comparison of Total Change Requests

Nov 2005 L Herrera Comparison Shifted for Development Phase

Nov 2005 L Herrera 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