MOS 2.0: A View of the Next Generation in Mission Operations Systems

1. MOS 2.0: A View of the Next Generation in Mission Operations Systems Duane L. Bindschadler, Carole A. Boyles, Carlos Carrion, and Chris L. Delp Jet Propulsion Laboratory, California Inst. Of Technology Pasadena, CA, U.S.A.

2. Outline • Background • Motivation • Why architect and model • Example – Process identification & modeling • Example – Model-based approach to scenarios • Future Work

3. Background • Multimission Operations • A multi-mission operations capability is engineered so as to require minimal work effort to adapt across the defined range of customers (deep-space robotic missions). This includes consideration across the lifecycle of the customer and of the capability itself. • Multiple success 1990 – early 2000’s • Range of applicable missions limited • Faster-better-cheaper (not maintainable long term) • Competitive pressures motivate search for more efficient methods • Operations Revitalization Initiative will help to create those methods • Architected, model-based MOS 2.0

4. MOS in Context

5. Why Architect & Model? • Systems and enterprises have architectures, whether or not they are explicitly documented and maintained • Architectural approaches identify and address stakeholder concerns • Enterprise-wide to very fine-grained • Distinct viewpoints address concerns • Model-based approaches enable • More formal, explicit specification • Management of complexity • More evolvable systems

6. Why Architect & Model? • ”Right" time to do it. • MBSE/architecture initiatives and interest taking hold at JPL and across NASA • Standards are maturing • Modeling tools are becoming able to support formal, rigorous description of highly complex systems • Piece-meal approaches have not been as effective as anticipated

7. Advantages • Less work effort in documenting • Less time in Word or Powerpoint • Increased focus on engineering design work • Improved ability to make accurate predictions about the impact of changes • Ability to model even complex processes • Clearer path for automation

8. Layered Reconciled MOS Process Example

9. Activity Model – high level

10. Activity Model – next level

11. Example: Scenarios Concept and Technology Development Phase Assess requirements’ completeness Assist in identifying ‘missing’ requirements Validate requirement intent Identify operational (process) and software interfaces Identify constraints on mission operations and assess operability Identify any outstanding issues

12. Why Build Scenarios? Preliminary Design and Technology Completion Phase Documenting Science Goals Identifying Mission Operations Phases Identify Flight System and Ground System Constraints Baselines Science and Mission Capabilities Used in Support of Proposal and Cost efforts

13. Scenario Process

14. Scenario Tool Attributes • Managing the Scenario Process-- The scenario tool was designed with the intent to support the process owner in facilitating the operations scenario process. The attributes specific to managing the Scenario Process are: • Status • Automatic email • Electronic Signatures • Action Items • Revision Capability • Copy Capability • Attachments • Search capability on any field

15. Scenario Tool Attributes Scenario Accessibility -- Scenarios are maintained in a web accessible environment that provides a structured set of scenario fields. Online Collaboration -- The scenario tool allows for collaboration through the use of a comments field. The comment is instantly visible.

16. Scenario Tool Attributes • Interleaving Requirements -- The scenario tool has the ability to embed requirements into the scenario description. • Linking to Interfaces -- Operational Interface Agreements (OIA’s) are created to communicate agreements between teams. With the Advanced Multi-Mission Operations System (AMMOS) at JPL, the OIA’s are maintained in a web based tool similar to the scenario tool.

17. Requirements in Context

18. Scenario Tool Attributes • Copy a Scenario – The tool allows key fields of a scenario be copied and stored for use on other missions. • Revise a Scenario – Revision Capability helps supports the lifecycle of a scenario by finalizing the scenario at each key decision point in the lifecycle then assigning a revision naming convention and moving forward key fields.

19. Next Steps • Full lifecycle architecture for MOS 2.0 • Development (~Phase A – D) • Deployment (transition from Development to Ops) • Operations (Phase E) • Continuous improvement and maintenance • Flow-down of system level to development of composable services • Mission Planning & Sequencing • Mission Control • Other services follow • Coordinate & unify with software-focused architectural effort

20. Backup Material

21. MOS & AMMOS

22. MOS Functional View

23. Goals and Objectives

24. Common Business Architecture • Consist of • Business Process • High-level Information Architecture • Related Products • Unified information concepts (“timeline”) • Uncover essential, unstated needs (reconciliation) • Documented common conceptual processes

25. Sustainability & Maintainability • Information stored in a database, not individual files or documents (Word, PowerPoint, Visio, Excel, etc.) • Leverage non-proprietary standards • Multimission information in single source • Less “re-inventing the wheel” • Utilize models to impact and assess changes • Allow for evolution of the system & its components • Assess & impact changes needed for specific missions

26. Ease of Adaptation • Compose services at “right” level of granularity • Make explicit relationships between software and processes/procedures • Create and maintain standard interface descriptions • Facilitate creation of new or (when needed) mission-unique capabilities

27. Effective Capture of Knowledge Base • Have already captured wealth of information via operational scenarios • See Delp & Carrion presentation 1500 Thurs in Interoperability session • As-Is portions of Architectural model

28. System-Level Products • AMMOS system-level Operations Requirements & Scenarios • AMMOS Process Architecture and Design • Team Charters and Functions (components) • System-level process designs (components) • Interface definitions (connections) • AMMOS Operational Standards (constraints). • Training standards and materials (constraints).

29. Team-Level Products • Team-level Ops requirements & scenarios • Team Design Descriptions • Team Processes, Procedures • Operational Interface Agreements (OIAs) • Team Management Plans • Team Training Materials and Certification criteria. • Designed with Project adaptation in mind.

30. Proposed AMMOS Functionality