Mission Data System A Unified Model-based Systems and Software Engineering Approach to ISHM Michel Ingham, Gregory Horvath, David Wagner Jet Propulsion Laboratory, California Institute of Technology Oliver Martin, Seung Chung, Paul Elliott, Brian Williams Computer 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.

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 documenting the 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 Margin Module Temperature Battery State of Charge derived effects derived state (dependent state) independent state measurement data state data effect state effect command data state RTG Output Current Measurement s 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 example State Effects Diagram

Msmt: Ant_N Pointing Msmt: Ant_N Motor Current Msmt: Ant_N Mech OpMode Msmt: Ant_N Mech Power Msmt: Array Correlator Power Simple: Ant_N Mech OpMode & Health Cmd: Ant_N Mech D.S. Cmd: Signal Inclusion D.S. Simple: Array SP Correlator & Combiner State Simple: Background & Noise Signal State Target Signal State Msmt: Ant_N Received Signal Simple: Ant_N Received Signal Msmt: Correlation matrix Msmt: Signal Weights Simple: Combined Signal State Msmt: Combined Signal SNR Overview of State Analysis 1. System to be controlled 3. Model informs software design 2. State Analysis produces model 4. Model informs operations Ant_N Mech OpMode & Health: Healthy, Tracking & On-point Target Signal: Always Present Noise & Background: Unconstrained Received Signal 1: Target Signal present Received Signal 1: Is Known Received Signal 1: Transition to Target Signal Present If Ant_N Mech OpMode & Health = not shutdown or offline if Target Signal State = present and Ant_N Mech OpMode & Health = on-point then: Target + Noise + Background else: Noise + Background Goal Supporting Goal Min to Max Power off Stowed or go-idle End-of-profile or go-idle Power on Shutdown Idle Off-pnt msmt On-pnt msmst Tracking On-pnt Off-pnt Power off Go to Stowed Begin Tracking Offline & ready Come online cmd Go offline cmd Repaired msmt Offline & not ready Stowing Ant. N Mech. Controller Ant. N Hardware Adapter Ant. N Mech. Estimator Measurements & Commands Commands State Functions State Values Ant. N Mech. State Variable Models

State-based Control Architecture System Under Control State Control Hardware Adapter Mission Planning & Execution Control Goals Sense State Estimation Act Measurements & Commands Commands State Functions State Values Knowledge Goals State Knowledge Models Clear delineation between control system and system under control Explicit state variables Separation of estimation from control; diagnosis and recovery are integrated with nominal execution Models inform all aspects of control system System operation via overt, objective statements of intent

Goals State Variables Estimators Controllers Measurements Commands Various Models Resources Allocations State Constraints Time Constraints Scenario Fragments Time EWS/EWC Serialization ACE C++ Standard Library Unit TestingRTOS NamingTimeDM/DT/PolicyCCSDSELF MathEstimationExceptionUtilityInitialization Components/ConnectorsData CatalogValue HistoryData Transport State KnowledgeGoal Achiever:H/w AdapterGoal Network GEL Graph State Variable State Query VisualizationSimulationScheduler GraphPhysics: Common Vocabulary Reduces Errors of Translation State Analysis: Model-based Requirements Map Directly to Software Bridging the Gap between Systems & Software Engineering System Under Control State Control Hardware Adapter Mission Planning & Execution Control Goals Sense State Estimation Act Measurements & Commands Commands State Functions State Values Knowledge Goals State Knowledge Models

Embedded programs interact with the system’s sensors/actuators: Read sensors Set actuators Model-based programs interact with the system’s (hidden) state directly: Read state Set state Embedded Program State Plant Obs Cntrl Programmers must reason through interactions between state and sensors/actuators. Model-based Executives automatically reason through interactions between states and sensors/actuators. Model-based Embedded Program State Plant Estimated State Model-based Executive ObsCntrl Model-based Programming

Integrating Model-based Programming and Execution into the Architecture System Under Control State Control Hardware Adapter Mission Planning & Execution Control Goals Sense State Estimation Act Measurements & Commands Commands State Functions State Values Knowledge Goals State Knowledge Models 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) 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… off-cmd standby-cmd standby-cmd fire-cmd 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) 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: tt+1

Computationally Tractable State Estimation & Fault Diagnosis  Recast Belief State Update problem as an Optimal Constraint Satisfaction Problem (OCSP)  Solve using OPSAT engine: conflict-directed best-first search most-likelycandidate most-likely state estimate conflicts (infeasible modes) consistent with model & obs? consistent with model & obs? conflict database conflict database  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 fail Goal fail driver = on cmd = open idle driver = on cmd = close Current Open Closed Stuck Open Closed Goal cmd = onidle cmd = off Current On Off Resettable On Off cmd = resetcmd = off

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 closed part. open stuck closed stuck open Flow Regulator Discrete modes Continuous state: flow x Proposed DSN Array