# Presentation: 562181

## of theMission Data System

- 
- Bob Rasmussen, chief architect
- Dan Dvorak, deputy architect
- August 6, 2002

*Overview and Tour*

## Outline

- Overview
- Motivations, vision, themes
- A Virtual Tour
- A balloon ride down into the depths of MDS
- State Analysis Process
- Questions and answers about how things work
- MDS Implementation Status
- Questions & answers

## Challenging Future Missions

- In situ exploration
- Multi-vehicle coordination
- More complex observatories
- An interplanetary network

## Pressures for Autonomy

**Pressures for Autonomy**

- Uncertain environments
- Opportunistic observations
- More severe constraints

## More Complex Tasks

- Interact with and alter the environment
- Alter plans to achieve objectives
- Coordinate multiple competing activities
- Manage resources
- intelligently screen data before transmission

## Meeting These Needs Will Be Difficult

## Historical Gaps

- Between expressing **what operators want**	and expressing **how to get it**
- Between **flight** and **ground** software developments
- Between missions in **inheritance** of flight software
- Between ground generated **time-based sequencing**	and **fault tolerance**
- Between **systems** and **software** engineering

## Pressures for Change

- New era of more frequent launches
- Demands for lower cost
- Specter of mission-ending failuresdue to errors in software
- Success must be assured,despite large uncertainties

## What We Need

- Highly reusable core software for flight, ground, and test
- Synergistic systems *&* software engineering
- Reduced development time and cost
- Improved development processes
- Highly reliable operations
- Increased autonomy

## The MDS Vision

**The MDS Vision**

- A unified control architecture and methodsfor flight, ground, and test systemsthat enable missionsrequiring reliable, advanced software

## What is MDS ... Really?

- An **architecture**, unifying flight, ground, & test systems
- An orderly **systems engineering methodology**
- Software **frameworks** (C++ and Java)
**Processes**, tools,	and documentation
- Working **examples**	of adaptation
**Reusable software**	components

## Achieving the Vision

**Achieving the Vision**

- MDS project started in 1998
- Initial focus on analysis and prototyping
- Full implementation initiated in 2001
- Design and implementation of core frameworks near completion — continuing updates
- Current focus on maturation through application to real systems
- Running on Rocky 7 and FIDO rovers
- Baselined for Mars Smart Lander project

## MDS Themes

- Construct subsystems from architectural elements,	not the other way around
- Some things go together — others do not
- Be explicit (use goals, models, ...)
- Close the loop
- Think ahead

*A unified approach to managing interactions is essential *

## A State-Based Approach

- Formally recognize **state** as the key system concept
- Make **state** the central organizing theme for most functions
- Express all knowledge in models of **state**
- Share a common definitionof system **state** among models

## A Component-Based Approach

- The **State Architecture** establishes the elements of **functionality**, but *not* the software design
- The **Component Architecture** establishes the elements of **software design**
- Issues are raised to the levelof symbolic realization
- Software is organizedas **components**
- State-based elements arerealized as **components**
- Complexity of interactions is managed at the **component** level

## Complementary Approaches

**Complementary Approaches**

## A Virtual TourDescending into a MDS-based system

## 25 Missions in Next 10 Years

- A-3

- Next: MFRM

*(MFRM)*

- JPL

***MDS***
***Inside***

- A-4

- Next: inside

## Inside Mission MFRM

- <<deployment>>
**Lander**

- <<deployment>>
**Ground**

- <<deployment>>
**Rover**

- MFRM

- JPL

- A-5

- UML notation
- for deployments

- Next: Lander

## Inside Lander

- MFRM

- Lander

- JPL

- A-6

- Next: Thermal

## Inside Thermal, Depth 1

- MFRM

- Lander

- Thermal

- JPL

*- depth 1*

*UML notation*
*for component*

*connection*

- A-7

- Next: closer

## Inside Thermal, depth 2

- MFRM

- Lander

- Thermal

- JPL

*- depth 1*
*- depth 2*

*commands, status*

*measurements*

*state*
*estimates*

*estimate functions*

- A-8

*goals*

- Next: state architecture

*UML notation*
*for component*

## Outside a State Variable

- Camera TemperatureState Variable

*State query*

*Notification*

*State update*

*Policy control*

*UML notation*
*for interfaces*

*Direction of call*

- JPL
- MFRM
- Lander
- Thermal
*- depth 1*
*depth 2*
*state var*
*-outside*

- A-10

- Next: query interface

*UML notation*
*for component*

## Looking at an Interface

- <<interface>>
**State Query Interface**
**getState**(const Epoch& time): RefCountPtr<const EstimateType>

**Epoch**

**RefCountPtr**

*UML notation for*
*an interface class*

- JPL
- MFRM
- Lander
- Thermal
*- depth 1*
*- depth 2*
*state var*
*-outside*
*-interface*

- EstimateType

- A-11

- Next: inside SV

*Template argument*

*Operation*

*Return type*

*Arguments*

## Inside a State Variable

- JPL
- MFRM
- Lander
- Thermal
*- depth 1*
*- depth 2*
*state var*
*-outside*
*-interface*
*-inside*

*A *_*timeline*_* represents a state variable’s value as a function of time*

- A-12

- Next: back to Thermal

- Planned states
- (intent)

- Estimates states
- (knowledge)

## Inside Thermal, depth 2

- MFRM

- Lander

- Thermal

- JPL

*- depth 1*
*- depth 2*

*commands, status*

*measurements*

*estimate functions*

- A-13

*state*
*estimates*

*goals*

- Next: goal

## State Analysis 

*A gradual, methodical discovery process ...*
*... **that systems engineers use ...*
*... **to ask and answer questions about how things work*

## State Analysis is Recursive

- It is a gradual discovery process, prompted by a **standard** set of basic **questions**
- The answer to each  question  is a piece of the  model
- Each answer prompts additional questions, and so on
- The model unfolds a step at a time in terms of **common** **framework elements** until all the pieces are identified

- question

- model

## State VariablesUnderstanding the System in Terms of State

**Define a****State Variable**

**Model an Effect**

**What other states****are involved?**

- Start with a few key states
- Look at their behaviors
- Ask how and why they change
- Revisit this for every new state variable that is identified

***Each model element gets at least a name and a description.***
***Most have several other characteristics and links to other elements that must be described.***

**Do other states affect it?**

## Spacecraft States

- Dynamics
- Vehicle position & attitude, gimbal angles, wheel rotation, ...
- Environment
- Ephemeris, light level, atmospheric profiles, terrain, ...
- Device status
- Configuration, temperature, operating modes, failure modes, ...
- Parameters
- Mass properties, scale factors, biases, alignments, noise levels, ...
- Resources
- Power & energy, propellant, data storage, bandwidth, ...
- Data product collections
- Science data, measurement sets, ...
- DM/DT Policies
- Compression/deletion, transport priority, ...
- Externally controlled factors
- Space link schedule & configuration, ...
- 			... and so on

## Spacecraft Models

- Relationships among states
*Power varies with solar incidence angle, temperature, & occultation*
- Relationships between measurement values and states
*Temperature data depends on temperature, but also on calibration parameters and transducer health*
- Relationships between command values and states
*It can take up to half a second from commanding a switch to full on*
- Sequential state machines
*Some sequences of valve operations are okay; others are not*
- Dynamical state models
*Accelerating to a turn rate takes time*
- Inference rules
*If there has been no communication from the ground**in a week, assume something in the uplink has failed*
- Conditional behaviors
*Pointing performance can’t be maintained until rates are low*
- Compatibility rules
- Reaction wheel momentum cannot be dumped while being used for control
- 			... and so on

## State Value HistoriesReporting What’s Happening in Terms of State

- Choose carefully how each state will be expressed
- This is driven by need
- Uncertainty must be part of the definition
- Value histories maintain state values as functions of time
- They record the past
- They may also predict the future
- They are transported across space links to report what is happening
- Policies guide the treatment of this data
- This includes converting it into new forms

**How should the state****be represented?**

**Define**
**State Functions**

**How should state****be managed & transported?**

**Define a**
**Policy**

**Define a****State Variable**

## Sensors (Input Devices)

- Measurement models describe how measurement data is related to state
- Usually sensors measure many more states,in addition to the ones intended
- Newly identified states prompt more questions
- Measurements are also kept in value histories

**Model a Measurement**

**Can it be measured?**

**Define a Sensor**

**What measurements does it produce?**

**What other states does it measure?**

**Define a****State Variable**

**How should measurements****be managed & transported?**

**Define a**
**Policy**

## Actuators (Output Devices)

**Actuators (Output Devices)**

**Define a****State Variable**

**Model a Command**

**Can it be directly commanded?**

**Define an Actuator**

**What commands does it accept?**

**What other states does it affect?**

**How should commands****be managed & transported?**

**Define a**
**Policy**

- Command models describe changes to state
- Often commands affect other states, in addition to the ones intended
- Newly identified states prompt more questions
- Commands are also kept in value histories

## Hardware Adapters

- Sensors and actuators are input and output ports, respectively on hardware adapters
- Hardware adapters handle all communication with the hardware
- They may also augment hardware capabilities with various low level services
- Collectively, these hardware and service functions present architecturally uniform sensor and actuator ports to the rest of the software

**Define a H/W Adapter**

**Define an Actuator**

**Define a Sensor**

## State DeterminationMonitoring the System and Its Own Actions to Determine State

**Model a Measurement**

**Define a****State Variable**

**Define an Estimator**

**Model a Command**

**Model an Effect**

**How well must the state be known?**

**Define a Knowledge Goal**

**How should state knowledge be updated?**

**How will this be achieved?**

- Models suggest how states should be estimated
- Estimators often use models directly
- You may identify multiple ways to know a state, depending on circumstances and need

- Estimators are “goal achievers”

## State ControlActing on the System to Control Its State

**Define a****State Variable**

**Define a Controller**

**Model a Command**

**Model an Effect**

**How must the state be controlled?**

**Define a****Control Goal**

**How will this be achieved?**

- Controllers are also “goal achievers”

- Models can also suggest how states should be controlled
- Controllers often use models directly
- There are usually several ways to control a state

## ElaborationExpressing Intention in Terms of Desired State

- When states can’t be commanded directly, control other states that affect them instead — and don’t forget to allocate side effects
- Elaboration identifies new goals, and so on

**Define a****Goal**

**Define a****State Variable**

**Model an Effect**

**Define an Elaboration**

**Are all needed goals defined?**

**How should related states be controlled?**

**How should side effects be allocated?**

**What other states can be used to change this state?**

**What other states does this state affect?**

## Constraint Networks

- Goals elaborate recursively into constraint networks
- These are scheduled across state timelines, describing a scenario

**Goal**

**Goal**

**Goal**

**Goal**

**Goal**

**Goal**

**Goal**

**Goal**

**Goal**

**Goal**

**Goal**

***State 1***

***State 2***

***Time***

## Following Leads — An Example

**?**

**Standard Questions:**

**Common Framework****Elements:**

**Following Leads — An Example**

- What do you want to achieve?

*Move rover to rock*

***Goal***

- What’s the state to be controlled?

*Rover position relative to rock*

***State Variable***

- What evidence is there for that state?

*IMU, wheel rotations,**sun sensor, stereo camera*

***Measurements***

- What does the stereo camera measure?

*Distance to terrain features,**light level, camera power **(**ON/OFF**), camera health*

***Measurement***
***Model***

- How do you raise the light level?

*Wait until the sun is up*

***State Effects Model***

- Where is sun relative to horizon?

- ...

***Etc.***

## State Database ServerA Tool for State Analysis

- Screen display of browser during state analysis

## Summary

## Inside Thermal, depth 2

- MFRM

- Lander

- Thermal

- JPL

*- depth 1*
*- depth 2*

*commands, status*

*measurements*

*estimate functions*

- A-13

*state*
*estimates*

***goals***

- Next: goal

## Camera Temperature Goal

- JPL
- MFRM
- Lander
- Thermal
*- depth 1*
*- depth 2*
*Goal*

**Camera Temperature Goal**
- camera temperature
- between 280oK and 290oK
- from 2008-05-15T18:00:00ET
- until 2008-05-15T19:00:00ET

- A-14, click

***Adaptation***

***Framework***

- Next: ascending to Goal Net package

## A Framework Package

- MFRM

- Lander

- Thermal

- JPL

- A-15

- Next: ascending to Thermal

**Goal Net**

- NetworkTree

- GoalTree

- GoalStatus

- GoalNet

- GoalElaborator

- Goal

- Tactic

- TemporalConstraint

- XGoal

- TimePoint

**...  **

- Goal Net

## Inside Thermal

- MFRM

- Lander

- Thermal

- JPL

- A-16

- Next: ascending to Lander

## Inside Lander

- MFRM

- Lander

- JPL

- A-17

- Next: ascending to MFRM

## Inside Mission MFRM

**Lander**

**Ground**

**Rover**

- MFRM

- JPL

- A-18

- Next: summary

## 25 Missions in Next 10 Years

- A-19

- Next: outreach presentations

## MDS State/Model Architecture

- State variables hold state values, including degree of uncertainty

- Estimators interpret measurement and command evidence to estimate state

- Controllers issue commands, striving to achieve goals

- Hardware proxies provide access to hardware busses, devices, instruments

- Models express mission-specific relations among states, commands, and measurements

- A goal is a constraint on the values of a state variable over a time interval

## Advantages of State Analysis

- Captures thorough, unambiguous **requirements**
- Guides a clear **work** **breakdown**
- Aids collection of **metrics**
- Fosters a **robust design** approach
- Aids cross-checking for **coverage** and **consistency**
- Serves as an **integration** tool at many levels
- Improves **inspectability** and **testability**
- Enables principled **coordination** of the system
- Facilitates increasing **autonomy**
- Assures greater **reusability**

## Needs Addressed by MDS

**Program Managers**
- Continuity across projects
- Investments lead to savings
**Project Managers**
- Better cost estimates — greater cost control
- More reliable, efficient, and better understood systems
**Systems Engineers**
- Disciplined and thorough methodology for design
- Easy communication with software engineers — more timely, explicit, complete, and testable requirements
**Software Engineers**
- Strong formal architecture — “A place for everything, and everything in its place”
- Investment in new design, instead of rehashing old design

**Operations**
- Reduced overhead for routine operations
- Greater robustness — focus on what to do, not how to do it
**Technologists**
- More direct path to flight — narrows the TRL gap
- Easier integration with other technologies via standard architecture
**Scientists**
- Enables more complex missions with autonomy
- Reactive, intelligent data collection and processing
**Line managers**
- A place to capture institutional experience and knowledge
- Keep a competitive edge

## Questions?

## Slide 55

## “Observations” Slides

- The following slides are to be shown on a second projector, concurrently with parts of the virtual tour
- To synchronize the two screens, match the ‘B’ number with the ‘A’ number

## MDS Virtual Tour

- Watch for:
- architecture
- frameworks
- design patterns
- object-oriented design
- adaptations
- MDS terminology (in red)
- UML‡ terminology (in blue)
- Observations about thesights below will appear here
- Our “altitude” appears here
- UML: “a language for visualizing, specifying, constructing  and documenting the artifacts of a software intensive system

- JPL

- B-3,4

## Observations

- A “deployment” is:
- an executable hosted on specific hardware
- a node in an *interplanetary* network
- Ground  Lander and Lander  Rover communication handled uniformly
- “Products” flow in both directions
- value histories for samples and intervals
- goals for operation
- Protocols:
- standard CCSDS protocols, currently
- internet protocols, future
- architecture allows any protocol as a plug-in

- B-5

## Observations

- A “discipline” is an area of expertise that builds software assets, sometimes a full subsystem
- Discipline-specific software is organized into “packages” (general-purpose grouping/organizing)
- MDS provides “frameworks” from which subsystems are built
- shared problems, shared solutions
- planning, control, telemetry, storage, ...
- subsystems leverage framework software
- “A framework is an architectural pattern that provides an extensible template for applications within a domain.”

- B-6

## Observations

- The system — and its subsystems — is composed of “components”
- A component:
- is a piece of functionality
- is the unit of distribution & assembly
- interacts with other components *only* thru connectors
- Components:
- enable an *architectural* description
- eliminate hidden “usage” relations
- moves coordination/synchronization complexity into connectors

- B-7

## Observations

- Kinds of components:
- hardware proxies
- controllers
- estimators
- state variables
- Each kind plays a specific role:
- hardware proxies provide access to hardware
- controllers strive to achieve goals on state
- estimators interpret evidence to form estimates of state knowledge
- state variables hold state knowledge

- B-8

## Observation: State is Central

- State is a central concept in many mission activities
- The function of mission softwareis to monitor and control a system to meet operators’ intents
- Knowledge of the system is represented over time in **state variables**
- Operators’ intent, including flight rules and constraints,are expressed as **goals**on system states

- B-9a

*“**State Flower”,* Robert Rasmussen, 1999.

## Observations

- Estimation is separated from control
- distinct roles
- ensures consistent state seen by all
- code easier to write, easier to test
- components are more reusable
- Real-time closed-loop control systems are composed from such components
- Controllers are goal-driven

- B-9b

## Observations

- _All_ interactions with a state variabletakes place through its interfaces
- “An interface is a collection of operations that are used to specify a service of a class or component”
- Interface definitions are the end product of a lot of design thought
- pre-tested for adequacy
- pre-integrated with other components
- For each interface of a component:
- some are called from *outside* (e.g. state query)
- some are called from *inside* (e.g. notification)

- B-10

## Observations

- An interface defines one or more operations on a component
- “Smart pointers” reduce problems of object ownership and memory leaks
- Scalar quantities, such as temperature, use the “SI units” package
- not just type-safe, but also unit-safe
- checked at compile time, not runtime

- B-11

## Observations

- Timelines hold past, present and future
- Estimate functions describehow state evolved up until ‘now’
- Goals describe how operators *intend*for state to evolve in future
- Timeline is stored in a “value history”
- Data management “policies” control:
- when to checkpoint
- what to transport
- when to compress
- how much to recover upon restart

- B-12

## Observations

- We’re back in Thermal subsystem
- Recall: controllers strive to achieve goals
- Let’s look at a goal on camera temperature state

- B-13

## Observations

- A goal is a constraint on the value ofa state variable over a time interval
- Goals specify operational intent
- “what”, not “how”
- goals leave options for selecting actions
- goals enable *in situ* decision-making
- Goals live in a network that definesparent-child relationships andtemporal ordering relationships.
- Adaptations build upon framework software

- B-14

## Observations

- A *package* organizes multiple classes
- A *class* defines data and functions

- B-15

## Observations

- A *component* uses multiple packages
- A *package* organizes multiple classes
- A *class* defines data and functions

- B-16

**Component**

## Observations

- A *discipline* builds upon components and other s/w
- A *component* uses multiple packages
- A *package* organizes multiple classes
- A *class* defines data and functions

- B-17

**Component**

## Observations

- A *deployment* builds upon multiple disciplines
- A *discipline* builds upon components and other s/w
- A *component* uses multiple packages
- A *package* organizes multiple classes
- A *class* defines data and functions

- B-18

**Deployment**

**Component**

- Next: summary

## Backup Slides

## MDS Framework Packages

- OS Services
- Level 0

- Embedded web
- Server & client

- Data
- Serialization

- Adaptive Communication
- Environment

- C++ Standard
- Library

- Unit Testing
- Package

- Real Time
- Operating System

- Application Services
- Level 5

- State Services
- Level 4

- Complex Services
- Level 3

- Simple Services
- Level 2

- Primitive Services
- Level 1

- Naming
- Services

- Time
- Services

- Data Mgmt
- Policy

- CCSDS File
- Delivery Protocol

- Event Log
- Facility

- Math Library
- Linear algebra
- Probability dist.
- Polynomials
- 6-DOF classes

- Sequential
- Estimation

- Exception
- Classes

- Standard
- Utility classes

- Initialization &
- Finalization

- Components &
- Connectors

- Data Catalog
- collection, entry, event
- data product

- Value History
- sampled history
- time-interval history

- Data Transport
- sender, receiver
- session, request

- State Knowledge
- state variable
- state value

- Goal Achiever:
- estimator, controller
- Measurement, command

- Hardware
- Proxy

- Goal
- Network

- Goal Elaboration
- Language

- Graph State
- Variable

- State
- Query

- Data
- Visualization

- Simulation

- Component
- Scheduler

- Graph
- Library

- Physics Library:
- SI Units
- Coordinate systems
- Position, velocity &
-  acceleration