# Presentation: 073079

## A Unified Model-based Systems and Software Engineering Approach to ISHM

- Michel Ingham, Gregory Horvath, David WagnerJet Propulsion Laboratory, California Institute of Technology
- Oliver Martin, Seung Chung, Paul Elliott, Brian WilliamsComputer Science and Artificial Intelligence Laboratory, MIT
- ISHEM Workshop
- 11/09/2005

## Motivation

- Spacecraft operate in a harsh, *uncertain environment*.
- Spacecraft achieve robustness by managing a *complex set of redundant subsystems*, over a range of possible *nominal and off-nominal* scenarios.
- Reasoning about interactions within and between subsystems during sensing and actuation is complex and error-prone, and requires significant* interaction between systems engineers and software programmers*.
- The traditional gap between systems and software engineering can lead to errors that manifest themselves as *software defects*.
- NASA software engineering practice has been challenged to create and verify space systems that assure ***correctness, reliability, and robustness*** in a ***timely and cost effective*** manner.

**Notes:**
Review

## Objective/Vision

***Current Practice:*** System Software is a Surrogate for Systems Engineers, and Software Engineers perform the transformation.

***Our Goal:*** Models from Systems Engineers are provided directly to the embedded system, which is capable of reasoning through them to accomplish mission objectives and manage the health of the system!

## Approach

- The State-of-the-Art is still far from fully achieving this Vision
- Yet even incremental steps toward this Vision can greatly improve on the current practice, producing software that is:
- Less error-prone,
- More robust to off-nominal situations,
- Three facets of our approach:
- Develop **representations** and **algorithms** that endow the embedded system with the requisite reasoning capabilities *(Model-based Programming and Execution)*
- Integrate these technologies into a **principled software architecture** that facilitates adaptation to a particular application *(State-based control architecture and MDS software framework)*
- Provide Systems Engineers with **methods** and **tools** that help them reason through the system design and develop models in a *rigorous* way *(State Analysis)*

-  Cheaper,
-  Easier to verify, etc...

## State Analysis

- A uniform, methodical, and rigorous approach for...
- Discovering, characterizing, representing, and documentingthe **states** of a system
- Modeling the **behavior**** **of states and **relationships** among them, including information about hardware **interfaces** and **operation**
- Capturing the mission** ****objectives** in detailed **scenarios** motivated by operator **intent**
- Keeping track of system **constraints** and operating **rules**, and
- Describing the **methods** by which objectives will be **achieved**
- For each of these design aspects, there is a simple but strict **structure** within which it is defined...

**Available**
**Power**

**Power**
**Margin**

**Module Temperature**

**Battery**
**State of**
**Charge**

- derived effects

- derived state
- (dependent state)

- independent state

- independent state

- measurement data state

- data effect

- state effect

- command data state

**RTG**
**Output**
**Current**
**Measurements**

- state

**RTG **
**Output Current**

**External**
**Temperature**

**Module Temperature**
**Measurements**

**Heater**
**Switch**
**Measurements**

**Battery **
**State of Charge**
**Measurements**

**Heater**
**Switch**
**Status**
**and Health**

**Heater**
**Power**
**Use**

**Heater**
**Switch**
**Commands**

- An exampleState EffectsDiagram

## Overview of State Analysis

**Overview of State Analysis**

- 1. System to be controlled

- 3. Model informs software design

- 2. State Analysis produces model

- 4. Model informs operations

## State-based Control Architecture

- Clear delineation between control system and system under control

- Explicit state variables

- Separation of estimationfrom control; diagnosis and recovery are integrated with nominal execution

- Models inform all aspects of control system

- System operation via overt, objective statements of intent

## Bridging the Gap betweenSystems & Software Engineering

**Common Vocabulary****Reduces Errors of Translation**

**State Analysis:**** ****Model-based Requirements ****Map Directly to Software**

**Bridging the Gap between****Systems & Software Engineering**

## Model-based Programming

-  Read sensors
-  Set actuators

*Model-based programs* interact with the system’s (hidden) state directly:
-  Read state
-  Set state

- Programmers must reason through interactions between state and sensors/actuators.

*Model-based Executives automatically* reason through interactions between states and sensors/actuators.

**Model-based Programming**

**Notes:**
Maps doesn’t communicate the right idea.

## Integrating Model-based Programmingand Execution into the Architecture

- Model-based reasoning algorithms to compute a series of commands that progress the system towards a least-cost state that achieves the goal.

**Goal Interpreter**

**Reactive Planner**

**Configuration**
**Goals**

**Goal**
**State**

**Command**

**Current**
**State**

- Model-based reasoning algorithm:
- Tracks a limited set of most-likely states
- Explores state space in best-first order

- Models are used EXPLICITLY by the control system

## Model Representation:  PCCA (Variant of Factored POMDP)

**Model Representation: **** PCCA (Variant of Factored POMDP)**

**Standby**

**Engine Model**

**Off**

**Failed**

**Firing**

- component modes...

*(thrust = full) AND*
*(power_in = nominal)*

*(thrust = zero) AND*
*(power_in = zero)*

*(thrust = zero) AND*
*(power_in = nominal)*

-  	described by finite domain constraints on variables...

- 		        with deterministic and probabilistic transitions...

- 		        		and cost/reward

- one per component ... operating concurrently

**Camera Model**

**On**

**Off**

- turnoff-
- cmd

- turnon-
- cmd

*(power_in = zero) AND (shutter = closed)*

*(power_in = nominal) AND (shutter = open)*

- 0.01

- 0.01

**Resettable**

- reset-
- cmd

## Estimation Using PCCA Models

- PCCA system model is compiled into a form suitable for reasoning (propositional logic)
- Belief State evolution visualized with a Trellis Diagram
- Complete history knowledge is captured in a single belief state by exploiting the Markov property
- For each estimation cycle, belief states are computed using the HMM belief state update equations:

## Computationally TractableState Estimation & Fault Diagnosis

- Recast Belief State Update problem as an Optimal Constraint Satisfaction Problem (OCSP)
- Solve using OPSAT engine:

- The belief state can be accurately approximated by maintain the ***k most likely estimates***
- The probability of each state can be accurately approximated by the ***most likely trajectory*** to that state
- The ***observation probability*** can be reduced to
- 1.0 for observations consistent with the state,
- 0.0 for observations inconsistent with the state

- Approximations to Estimation

- Assumptions made by Livingstone, Livingstone-2

- Assumptions relaxed by Titan Model-based Executive

## Diagnostic Algorithm Performance

- Two primary concerns regarding application of model-based reasoning onboard spacecraft are *processor throughput* and *memory limitations*
- To address this concern, we have evaluated the performance of Titan’s state estimation capability in terms of estimation time and static/heap memory utilization
- Variety of models (up to subsystem-size)
- Variety of nominal and off-nominal scenarios (auto-generated)

## Computationally Tractable State Control & Fault Recovery

**INPUT**
- Current State
- Tank = full
- Pressure = nominal
- Driver = off
- Valve = closed
- Thruster =  off
- Configuration Goal
- Thrust = on

**OUTPUT**
- Goal State
- Tank = full
- Pressure = nominal
- Driver = off
- Valve = open
- Thruster = on

**Goal Interpreter**

**Configuration**
**Goals**

**Goal**
**State**

**Current**
**State**

**OPSAT is used to generate optimal goal state that achieves the *****Configuration Goal*****!**

**Reactive Planner**

**Goal**
**State**

**Command**

**Current**
**State**

**Ensures *****progress***** toward the goal state, only generates *****non-destructive***** actions, never proposes actions that lead to dead-end plans, and operates at *****reactive time scale.***

**INPUT**
- Current State
- Tank = full
- Pressure = nominal
- Driver = off
- Valve = closed
- Thruster =  off
- Goal State
- Tank = full
- Pressure = nominal
- Driver = off
- Valve = open
- Thruster = on

**OUTPUT**
- Command
- Turn driver on

## Demonstrated Benefits

| End-to-end Lifecycle Approach | Model-based systems engineering at the core
Earlier consideration of off-nominal behavior and operations
Regular architecture allows development of accurate cost and performance models |
| --- | --- |
| Simplified estimator & controller development | Current ad-hoc algorithm implementation reduced to model development and use of pre-validated general estimation & control algorithms
Greater s/w reuse: only application-specific engineering models need to be developed; the reasoning engine is generic and reusable |
| Enhanced diagnosis and recovery capabilities | Uses complete, any-time inference algorithm to detect and respond to failures “on-the-fly”
Increased runtime performance using a precompiled model
Reasons over component interactions and “hidden” states
Tracks multiple state possibilities; prunes inconsistent states |
| Inspectable & verifiable models | Models are specified using an intuitive graphical representation (Factored POMDP)
Models are compiled offline into a set of rules that can be verified by systems engineers
Formal modeling semantics provides greater opportunity for automated verification (e.g., model-checking) |

## Next Steps

- Demonstrate integrated architecture and approach on scaled-up system
- Accommodate other modeling representations and estimation algorithms, e.g., hybrid systems (discrete modes with continuous dynamics)
- Elevate deliberative ISHM capabilities by integrating planning & scheduling based on *same models*
- Develop formal V&V approach for model-based programs
- probabilistic analysis of possible system executions
- lead to verifiably-correct system behavior for both nominal and off-nominal execution
- focus on specific validation needs of future NASA exploration missions

- Proposed DSN Array