1. Dynamic Domain Architectures for Model Based Autonomy MoBIES Embedded Software Working Group Meeting April 10-11 2001 B. Williams, B. Laddaga, H. Shrobe, M. Hofbaur MIT Artificial Intelligence Lab Space Systems Lab

2. Mode Estimation and Fault Diagnosis Karl Hedrick in Automotive Powertrain OEP Overview: “Powertrain control system software for automotive application is becoming more and more complex due to increasing functionality as well as ever more wide-ranging onboard diagnostic systems mandated by state and federal governments.” Challenge Problem: Model-based synthesis of an onboard monitoring and diagnostic engine that determines the (fault) mode of the powertrain system based on sensor data and the powertrain model. Model-based: Mode estimates (diagnoses) generated from component-based models. Handles multiple faults and multiple symptoms. Focuses on most likely modes (faults). Handles un-modeled failures / situations.

3. Fault Scenarios: Intake System Throttle/Intake Faults: (partially) clogged stuck-at intake leak … EGR Valve Faults stuck-at valve leak Intake Manifold Pressure Sensor binary faults: stuck-at soft faults: drifting, noise … VDL powertrain model

4. Diagnostic Approaches: 1.Livingstone (Mode Estimation and Repair) Models = probabilistic automata + discrete constraints. Performs extensive deduction online. 2.MiniMe (Miniature Mode Estimation) –Component models = discrete constraints –Precompiles diagnoses of individual symptoms. –Combines diagnoses on line. 3.HybridME (Hybrid Mode Estimation) –Models = probabilistic hybrid automata –detects degradation and incipient faults

5. Experiments for FY01 Milestones Implement MiniME and HybridME v1 modules. Validate Livingstone and MiniMe based on the simulated Intake Subsystem of the Powertrain OEP: –Intake/Throttle faults –Pressure and Airflow sensor faults Extend HybridME to concurrent automata. Validate HybridME based on the simulated Intake Subsystem of the Powertrain OEP model Validate intake subsystem diagnosis experiments on real-world data. FY02 Program Milestones

6. Success Criteria: Detection of incipient failures Detection of novel failures Real-time performance Use of both discrete and continuous models Demonstration on simulated data. Demonstration on real world data

7. Open Issues Need: sensor / actuator models Realistic fault scenarios and fault models Realistic sensor placement for power train Model of linkage from actuator to engine (e.g, by wire?) Model for EGR control Faults that may be injected within the real world OEP powertrain (e.g., valve and intake leaks)?

8. Temporal planner Livingstone Command goals Observations Flight System Control RT Control Layer State Thrust Goals Attitude Point(a) Engine Off Delta_V(direction=b, magnitude=200) Power Livingstone: Model-based Mode Estimation and Reconfiguration

9. Model Temporal planner Livingstone Command goals Observations Flight System Control RT Control Layer State Thrust Goals Attitude Point(a) Engine Off Delta_V(direction=b, magnitude=200) Power Closed Valve Open Stuckopen Stuckclosed OpenClose 0. 01 0.01 0.01 inflow = outflow = 0

10. Model Temporal planner Livingstone Command goals Observations Flight System Control RT Control Layer State Thrust Goals Attitude Point(a) Engine Off Delta_V(direction=b, magnitude=200) Power mode = open  high pressure = high flow; nominal pressure = nominal flow;... mode = closed  Zero flow

11. Model Temporal planner Livingstone Command goals Observations Flight System Control RT Control Layer State Thrust Goals Attitude Point(a) Engine Off Delta_V(direction=b, magnitude=200) Power State estimates Mode Reconfiguration Mode Estimation Configuration goals

12. Model Temporal planner Livingstone Command goals Observations Flight System Control RT Control Layer State Thrust Goals Attitude Point(a) Engine Off Delta_V(direction=b, magnitude=200) Power Reactive Model-based Programming (RMPL) Fire backup engine Valve fails stuck closed Open four valves

13. Model based Diagnosis (GDE) –Conflict Recognition A symptom is a discrepancy between the model and observations. A conflict is a minimal set of component modes that is inconsistent with the observations. Conflict Recognition produces ALL conflicts. –Candidate Generation A diagnosis is an assignment of component modes that resolves all conflicts. A kernel diagnosis is a minimal set of component modes that resolves all conflicts. Candidate generation produces the likely kernel diagnoses

14. Miniature Mode Estimation (MiniME) Compile time: - Given component models and interconnections. - Generates rules mapping observations to conflicts. Run time: - Rules select conflicts based on current observations. - Generate most-likely kernel diagnoses from conflicts. Idea: Generate Conflicts offline:

15. MiniME – Compile Time Model components specified in RMPL modeling language. –Initially will use Livingstone language to exploit heritage. Compiler receives models and outputs Concurrent Constraint Automata to the Rule Generator. Rule Generator compiles CCA to rules (called dissents) that map sensor values to conflicts, using an instance of a prime implicate algorithm. –Prime Implicates Relay everything that must be true about the model without being redundant. –Dissent Special case of a prime implicate that relates sensor values to component modes.

16. MiniME – Run Time Uses current observations and full set of dissent rules to extract the conflicts that currently hold. Candidate Generation is viewed as tree search: The branches at a level select component modes from some conflict. A kernel diagnosis is a tree path that selects a mode from all conflicts. The cost of a branch is the mode’s probability. The most likely diagnosis corresponds to the shortest path in the tree.

17. HybridME Compiler A Hybrid Probabilistic Automata (HPA) encodes a hidden Markov model. Modes exhibit a continuous dynamical behavior, expressed by differential or difference equations. Hybrid Probabilistic Automata model M … set of discrete modes x, u, y … continuous state, input, output F … continuous dynamics for each mode (ODE) T … probabilistic transitions between modes Probabilistic transitions: Go to a nominal or failure mode Are conditioned on continuous variables Compiler maps RMPL Model to concurrent Hybrid Probabilistic Automata.

18. HybridME Mode Estimator Hybrid State Estimator maintains a set of likely hybrid state estimates as a set of trajectories. Hybrid mode estimator determines possible mode transitions for each trajectory. selects candidate trajectories to be tracked by the continuous state estimators. HMM belief state update is used to determine the likelihood for each traced trajectory

19. Techsat-21 Mission 3 spacecraft reconfigurable constellation High relative positioning accuracy (3mm-1cm) 28.5 inclination orbit (+/- 20 deg lat) 90 minute orbit, 1-day ~repeat track Each spacecraft has an X-band radar Est. 1m resolution (range and x-range) Non-repeat pass interferometry possible due to simultaneous emission and receipt of all 3 s/c using orthogonal waveforms –Not used for ASC demonstration due to computational cost of onboard processing Backscatter of X-band wavelength can easily distinguish water, ice, land (fresh v. old lava)

20. Autonomous Science Constellation Mission Concept 1. Target Imaged 5. New Science Images taken (repeat track) 2. Science Event Detected 3. Re-Plan 4. Constellation Reconfigured

21. Key Technologies Cluster Management (PSS/AFRL) –Enables single interface to cluster Robust Execution (ICS/AFRL) –Enables plans to deal wit run-time uncertainties Model-based Mode Identification and Reconfiguration (MIT SSL) –Enables timely state estimation and low level control Onboard Science (JPL) Feature detection & pattern recognition Change detection Enables onboard science decision-making Onboard Replanning (JPL) –Enables onboard development of new plans to perform observations

22. Technology Impact Enable vast improvements in science for fixed downlink –Downlink only highest science value images Enable observation of short-lived science events Reduce downtime due to anomalies Reduce setup time via exploitation of execution feedback

23. ASC Demonstration Software Message Detail Diagram CASPER Solaris s/w bus OSE s/w bus SCL SIM OA 5. Cancelled goals to SCL (ACTIVITY_DELETE) 8. Activity commits to SCL (ACTIVITY_EXECUTE) 8.1 Request to OA (COMPUTE_FORMATION) 10. Time to all (TIME) 4. Goals from SCL (ACTIVITY_CREATE) 8.1 Response from OA (FORMATION) 8.4 Goals from SCL (UPDATE_GOALS) 9. r/s/a updates from SCL (RESOURCE_UPDATE, STATE_UPDATE, ACTIVITY_UPDATE) Bus mirroring provided by ICS 9. r/s/a updates to SCL 8.3 Commands from SCL (SAR_ON, CALIBRATE, TAKE_DATA) 2. Goals from ground (UPDATE_GOALS) 6. Cancelled goals from CASPER (ACTIVITY_DELETE) 8. Commits from CASPER (ACTIVITY_EXECUTE) 8.1 Maneuver commands from OA (TBD) 8.1 Response from OA (FORMATION_COMPLETE) 8.2 Radar point commands from OA (TBD) 8.2 Response from OA (RADAR_POINTED) 8.4 Response from Science (IMAGE_FORMED, IMAGE_PROCESSED) 8.4 Goals from Science (IMAGE, DOWNLINK, CACHE_IMAGE) 9. r/s/a updates from SIM SolarisOSE r/s/a = resource, state, activity 8.1 Responses to CASPER (FORMATION) 8.1 Responses to SCL (FORMATION_COMPLETE) 8.1 Maneuver commands to SCL (TBD) 8.2 Response to SCL (RADAR_POINTED) 8.2 Radar point commands to SCL (TBD) 8.1 Request from CASPER (COMPUTE_FORMATION) 8.1 Command from SCL (CHANGE_FORMATION) 8.2 Command from SCL (POINT_RADAR) Science 8.4 Response to SCL (IMAGE_FORMED, IMAGE_PROCESSED) 8.4. New goals to SCL (IMAGE, DOWNLINK, CACHE_IMAGE) 8.4. Commands from SCL (FORM_IMAGE, PROCESS_IMAGE) 3. Goals to CASPER (ACTIVITY_CREATE) 8.1 Command to OA (CHANGE_FORMATION) 8.1 Maneuver commands to Broadreach (TBD) 8.2 Command to OA (POINT_RADAR) 8.2 Radar point commands to Broadreach (TBD) 8.3 Commands to SIM (SAR_ON, CALIBRATE, TAKE_DATA, METROLOGY) 8.4 Commands to Science (TRANSFER_SAR_DATA, FORM_IMAGE, PROCESS_IMAGE) 8.4 Goals to CASPER (UPDATE_GOALS) 9. r/s/a updates to CASPER (RESOURCE_UPDATE, STATE_UPDATE, ACTIVITY_UPDATE) Dynamics SIM Burton

24. Validation Plan CASPER Planner SAR Image Formation Onboard Science SCL Execution Autonomy ObjectAgent TeamAgent Cluster Mgmt ASC Experiment Study Phase Refinement Phase Techsat-21 Flight Integration on Workstations System Testing on relevant data Unit Testing on relevant data ASC Transition to AFRL Testbed ASC Transition to Flight Hardware ASC Flight Demonstration Gates System Demonstration on AFRL Techsat-21 Testbed System Demonstration on Techsat-21 Flight Hardware ASC System Demonstration on Workstations Broadreach Low-level FSW Sep 2000 March 2002 September 2003 September 2004 9-02 April 2000 Burton FDIR