Multimission Ground Systems & Services MOS 2.0: A View of the Next Generation in Mission Operations...

Multimission Ground Systems & Services

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.


Outline

• Background• Motivation

– Why architect and model

• Example – Process identification & modeling• Example – Model-based approach to scenarios• Future Work

Improving Space Operations Workshop Bindschadler – 2


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




MOS in Context



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



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


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




Layered Reconciled MOSProcess Example



Activity Model – high level



Activity Model – next level



• 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

Concept and Technology Development Phase

Example: Scenarios



Why Build Scenarios?

• 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

Preliminary Design and Technology Completion Phase



Figure 2. Scenario development process.

Scenario Process



• 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

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.




• 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.



Requirements in Context




• 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.


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



Backup Material


MOS & AMMOS




MOS Functional View



Goals and Objectives


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



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



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



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

Improving Space Operations Workshop Bindschadler– 27


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).



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.




Proposed AMMOS Functionality

Multimission Ground Systems & Services MOS 2.0: A View of the Next Generation in Mission Operations...

Documents

Transcript of Multimission Ground Systems & Services MOS 2.0: A View of the Next Generation in Mission Operations...