Transcript FACT/SEC May 02 - Vanderbilt University

Lecture 2
Model-based Diagnosis of Hybrid Systems
Gautam Biswas
Dept. of EECS and ISIS
Vanderbilt University
[email protected]
http://www.vuse.vanderbilt.edu/~biswas
Acknowledge
Gabor Karsai, Pieter Mosterman, Sriram Narasimhan, Eric Manders,
Nag Mahadevan, John Ramirez
Supported by DARPA SEC, NASA-IS, NASA-ALS, & NSF-ITR
Copyright © Vanderbilt University, 2006.
Overview
• Lecture 1: Diagnosis of continuous (dynamic)
systems
• Lecture 2: Diagnosis of hybrid systems to
accommodate more real-world applications
(physical processes with supervisory (discrete)
control)
• Lecture 3: Online diagnosis? What’s the use –
extend to fault-adaptive control
– Look at the bigger picture – fault-adaptive control,
different fault profiles, prognosis, maintenance, safety,
etc. …
2
7/17/2015
Lecture 2
• Hybrid Modeling and Diagnosis of Hybrid
Systems
• Combining Qualitative FDI with Quantitative
parameter estimation methods for more
informed and more refined diagnosis
• Example Applications
• Generation of Toolsuite
• Simulation experiments
• Run time system
3
7/17/2015
Fault Adaptive Control Technology
The FACT Paradigm
Overview
• FACT – Fault Adaptive Control Technology
– Goal: systematic model-based approaches to maintain
system operations under degraded and failure conditions
Expanded goals: reliable, safe, autonomous operation for
long-duration missions
– Approach: Develop the technology and required toolsuite using Model-Integrated Computing approach to
achieve this
– Components:
• Modeling Approaches – hybrid dynamic processes of the plant +
reconfigurable controllers
• Online monitoring of system behavior
• Online fault detection, isolation, and identification
• Adaptive models – update plant model after failure
• Model-predictive fault-adaptive control
5
7/17/2015
Definitions
•
FACT =
Toolsuite for constructing software that performs
fault diagnostics and reconfigurable control
– Fault Diagnostics + Reconfigurable Control
•
Fault Diagnostics =
– Fault Detection + Fault Source Isolation
•
Reconfigurable Control=
– Controller alternatives + Reconfiguration Logic
•
Fault-Adaptive control
– controller adapts its strategy to changing model of system
•
Toolsuite =
– Design time tools + Run-time support system
•
Application areas:
– Fault detection/Isolation/Reconfiguration/Adaptation
– Intelligent Vehicle Health Management
– Intelligent System Health Management
6
7/17/2015
Model-based Tools and
System Development
Visual modeling tool for creating:
•Hybrid bond-graph models
•Timed failure propagation graph models
•Controller models (including reconfiguration)
Hybrid
Diagnostics
Active
Model
Failure Propagation
Diagnostics
Modular run-time environment contains:
•Hybrid observer and fault detectors
•Hybrid and Discrete diagnostics modules
•Controller and reconfiguration strategy
model library
•Controller selector and reconfiguration
manager
•Active controller modules
Modules can be used standalone
Can use an RTOS as the platform
Fault Detector
Hybrid Observer
Interface & Controllers
Controller
Models
Strategy
Models
Controller
Selector
Plant
Models
Reconfiguration
Manager
Run-time Platform (RTOS)
7
7/17/2015
Fault-Adaptive Control Architecture
Active State Model
Hybrid Bond Graph
(HBG) Models
s1
s2
Models
s3
State
Space
Process
Controller
1
Controller
2
Modes
Hybrid
Observer
Controller
3
Temporal
Causal
Graph
Discrete
Time
Fault
Detector
Fault Diagnoser
Qualitative
Fault Isolation
Parameter
Estimation
Supervisor
8
7/17/2015
FACT Components
•
Modeling environment: Plant + controllers
–
–
hierarchical, multi-aspect
Three views
•
•
•
–
–
•
•
HBG view
Plant I/O view: Sensors + Actuators
Controller view (finite state machine, extend to MPC)
parameterize faults
TFPG view: specialized discrete-event diagnosis approach
with time intervals
Simulation environment: simulates physical system
behavior including fault scenarios
Run-time environment: implements fault detection,
isolation, identification, and fault adaptive control
algorithms
9
7/17/2015
Model building using GME
Building HBG models for
diagnosis
Bond Graphs Models
Impacting Trains
Sf1
Two tank system
V1
Tank1
Engine
R12
F(t)
1
2
Snubber
R12
C2
F(t) V1
Se
1
R: R12 C: C2
0
R23
1
1
C: C1
Vg
R2
V2
1
0
V3
1
C3
R3
I1
Sf: Sf1
3
C2
C1
Lumped
parameter
Topological
Modeling
V3
Tank2
C1
R1
V2
0
R: R1
1
I2
I3
0
Compact Representation
across domains
R: R2
Two Tank System
11
7/17/2015
Hybrid Bond Graph Models
Notion of Switched junctions
Operate in two modes:
(1) On: traditional junction
(2) Off: deactivated, inhibit transfer of
energy
CSPEC:
Local control mechanism implemented
OFF
C1
as finite state automata
C2
Two types:
ON
(1) Controlled – by external signals
(2) Autonomous – switching function
depends on system variables
12
7/17/2015
Hybrid Bond Graph
Models (contd…)
Notion of Switched junctions
Autonomous Junction –
switching function depends on system
variables
Flow between tanks depends on height
of fluid in the two tanks.
Four conditions:
(1) h1 , h2  h0  no flow
(2) h1  h0 ; h2  h0  flowfromtank1 to 2
flow  f(h1 )
(3) h2  h0 ; h1  h0  flowfromtank 2 to1
flow  f(h2 )
(4) h1 , h2  h0  flow between tanks
flow  f(h1  h2 )
13
7/17/2015
Formal Definition of HBGs
• Based on Hybrid Bond Graphs
– Bond graphs – generic elements (C, I, R, TF,
GY), sources, junctions, and bonds
– Hybrid Bond Graphs – allow for discrete
changes in model configuration (at meta
level): idealized switches at junctions that turn
energy connections on and off
HBG  {BG , M ,  }; BG  continuous m odel;
M  {M 1 , M 2 , M k }; M i  M assigned to switched junctioni
M i  (Qi ,  i , ,  , q0 );  m appingbetweenBG junctions& M i ' s
Qi  set of states;  i   i a   i c
 : Qi   i   i ;  : Qi  {on, off }
q0  Qi initial state
14
7/17/2015
Building Models in GME
• Define modeling paradigm (Hybrid Bond
Graphs, in our case) as a meta language
• Create model fragments for typical components
• In and Out ports defining input to and output
from components (both energy transfer and
signal communication)
• Build system components from model
fragments by composition
• Establish connections between in and out ports
of different components to specify interactions
• Switching signals for hybrid systems (controlled
+ autonomous)
http://www.isis.vanderbilt.edu/Projects/gme/default.html
15
7/17/2015
Modeling Language
Physical system models
Hybrid Bond Graphs
A topological model
containing dissipative,
storage, and source
elements, connected as a
reconfigurable network.
(discrete changes in model
configuration (at meta level):
idealized switches at
junctions that turn energy
connections on and off)
Bonds = energy flows
Signal flows = information
Fault model:
Abrupt changes in plant parameters (C,R,I,.. values)
Diagnostic problem:
Given the deviation between the predicted and observed behavior,
which plant parameter has changed?
16
•Components
•C,R,I,Gy,Tr Sf,Se
•Variables: e/f, u/x/y
•Energy/Signal ports
•Switched junctions
7/17/2015
Specifying Modeling Paradigm
for HBGs
Define HBG elements - (Sf, Se, R, C, I, Tf, Gy, 0, and 1) as
atoms
Associated properties – e.g., parameter values; C, I have initial
values
Define Bonds as connections
Restrictions on what connects to what
Define control signals as atoms and switching connection to
0 or 1 junction
Define autonomous signals as boolean decision functions
Decision functions can include variables from the system
17
7/17/2015
Modeling Paradigm Example
18
7/17/2015
Bond Graph Aspect:
Model building
19
Component: subsystem block
with I/O ports; component –
HBG fragment
Control Signal: continuous value
link between components or
external input to system
DecisionIn(Out)Port: transmits
switching values (binary) between
signals
EnergyIn(Out)Port: BG connections
In/OutPorts: pass real values into
or out of subsystem
ModFunction: Modulates BG component parameter values
Plant: Collection of components +
sensor & actuator elements
(appear as ports)
SwitchingSignal: Boolean value that
7/17/2015
turns junction on/off
HBGs: Switching Junctions +
Decision Signals
BG DecisionFunction.
Switching 1-Junction
Modulating Function
20
7/17/2015
Modeling Fluid System
Components
Typical components -Tanks, Pipes, and Pumps
Tanks – C (Capacitance) connected to 0 junction
Pumps – energy source (Se) + transformer (TF) connected
via 0 junction
Pipes – R (Resistance) connected to 1 junctions
Two ports for pipes
One port for tanks
Switching Signal for valves
21
7/17/2015
Water Recovery System
Reverse
Osmosis
22
7/17/2015
Model Building Environment
 Graphical Componentbased Modeling
environment (GME)
 Under each component
model
– hybrid bond graph model
 Modeling environment:
compositional
tools for generating
simulation models,
hybrid observers, &
diagnosis models
23
7/17/2015
ALS – HBG model
Conductivity
Conductivity
calculations
 Topological
 Compact
 Multi-domain
 First principles
 Incorporates
nonlinearities
Feed Pump
Membrane
 Easily linked to
 Supervisory
(event-based
controller models)
can be easily
integrated
Feedback
Loop
Recirc Pump
Purge to
AES
Mechanical
Hydraulic
24
7/17/2015
FACT
Fault Diagnosis +
Reconfiguration/Fault Adaptive Control
Model-Predictive Control Architecture
TRANSCEND + Utility-Based Control
Fault-Adaptive Control
Reconfigurable
Control
Utility-based
Control
<par, mag>
Discrete-Time
Simulator
Residual Evaluation (Qualitative)
u
Switching ŷ
EKF
Process
+
Symbol
Generation
s3
s2
f1
Parameter
Estimation
f2
s
Temporal Causal Graph
Hybrid Bond Graph (HBG)
Mode 1
Mode 2
Mode 3
Qualitative
Fault
Isolation
r
y
s1
Quantitative
Fault
Detection
Residual Generation
State Space
EKF – Extended Kalman Filter
26
7/17/2015
Run-time System
Hybrid Observer
HYBRID OBSERVER
FINITE
AUTOMATON
MODELS
2N modes
CONTROL
EVENTS
RECALCULATE AUTONOMOUS
EVENTS
EXTENDED
KALMAN FILTER
uk
CONTROLLER
•Tracks plant behavior,
estimates discrete and
continuous state
•Handles modulated (nonlinear components
•Observer is constructed from
component models
automatically
EST:
xk ,yk
yk
PLANT
27
7/17/2015
Run-time System
Fault Detection
Faults
System

+
n
+
+ residual

Model

•Residual: Gaussian
white with zero mean
•To detect a fault, the
generalized likelihood
ratio test (LR) is used for
hypothesis testing
Extended Kalman
Filter
Residuals deviate from zero because of
– Noise (n)
– Modeling errors ()
–
Sensor inaccuracies ()
–
Faults
X
Separation
of effects
necessary!
!
28
7/17/2015
Run-time System
Hybrid (TCG) Diagnostics
Plant Models
(Hybrid Bond Graphs)
TCG
Diagnostics
State Space Models
+
Hybrid Automaton
Fault Isolation
Fault
Detector
Residual
Hybrid
Automaton
Mode change
Hypotheses
Generation
Roll Back
Fault
Identification
Symbol
Generation
Hybrid
Observer
Kalman Filter
Parameterized
State Space
Model
Temporal
Causal Graph
Signature
Generation
Progressive Hr
Monitoring
Parameter
Estimation
Hypothesize
Autonomous
Roll Forward Transitions
29
7/17/2015
Hybrid Diagnosis Problem
Piecewise linear hybrid dynamical systems
Presence of fault invalidates
tracked mode trajectory
Tracked Trajectory
Actual Trajectory
Mode 1
Mode 2
T1
Mode 3
T2
Time
Line
Mode 5
Mode 4
Fault
Occurs
Mode 7
Mode 6
T3
T4
T5
Roll Back to find fault hypotheses
Known Controlled Transition
Hypothesized Autonomous
Transition
Possible current
modes
Hypothesized
fault mode
Hypothesized
intermediate modes
Roll Forward to confirm fault hypotheses
30
T6
Fault
Detected
Fault Hypothesis: <mode,parameter>
Catch up to current
system mode to verify
hypotheses against
measurements
Note: Controller transitions
known
Autonomous transitions have
to be hypothesized
7/17/2015
Hybrid Diagnosis: Issues
• Sometimes fault detection occurs after mode change
occurs
– Requires fast roll back process to identify correct model for fault
isolation
Lemma 1: If controller model is “correct”, fault must have
occurred in one of the modes in the mode trajectory
• k-diagnosability: system is k-diagnosable if the effects
of a fault manifest themselves in k mode transitions.
• Issues:
– Fast roll back process up to k modes
– What to propagate across mode-change
boundaries?
31
7/17/2015
Hybrid Diagnosis: Issues
• To compare against current behavior, fault
signatures have to be generated by a
quick roll forward process
• Issue: Autonomous changes cannot be
correctly predicted.
Tracking process invokes multiple paths
32
7/17/2015
Fault Isolation & Identification
Hypothesis Generation
Candidate Set
<fault,mode>
Signal to Symbol
Generator
(Back Propagation)
Past Mode
Trajectory
Mode
mi
Qualitative Hypotheses Refinement
Forward Prop + Prog Monitoring
Quick Roll Forward
From Hybrid
Bond Graphs
Refined
Candidate Set
Temporal Causal
Graphs (TCGs)
<fault,mode>
current mode
Observations
Quantitative Hypotheses
Refinement
State Space
Models
Parameter Estimation
Refined
Candidate Set
33
<fault,mode>
current mode
7/17/2015
Roll Back Process
Fault: Leak in
Drain Pipe
•Qualitative Hypotheses Generation
• Back propagate through TCG in current mode to identify candidates
• Back propagate across mode transitions using transition conditions (need to account for reset
conditions, and change in plant configuration – invert qualitatively)
• Repeat same process for previous modes to identify more candidates
Transition
Fault Occurred
Fault Detected
- Tank 1 Pressure
- Tank 2 Pressure
- Tank 3 Pressure
System Autonomous Transition
At time of fault detection,
Current Mode Candidates = C2+(0-+ ,-+- ,000 ), C1+(-+- ,0-+ ,000 ), R1- (0-+ ,00- ,000 ), R12- (0-+ ,0+- ,000 )
34
7/17/2015
Quick Roll Forward
•
In continuous case, mismatch implies fault hypothesis is not consistent. However, in
hybrid tracking, it may imply that we are not in the right mode. We need to identify the
current mode (roll forward)
•
All controlled transitions are known, but we have to hypothesize autonomous
transitions since observer can no longer predict them correctly
•
Use fault signatures to hypothesize mode transitions
Transition
Fault Occurred
Fault Detected
- Tank 1 Pressure
- Tank 2 Pressure
- Tank 3 Pressure
System Autonomous Transition
At time of fault detection,
Current Mode Candidates = C1-(+-+ ,000 ,000 ), R1+ (0+- ,000 ,000 )
No Previous mode candidates
35
7/17/2015
Real-life example:
Aircraft Fuel System
• New models built based on feedback from Boeing
• MATLAB simulation for the system
• Experiments in tracking and FDI
Model:
•22 components
•6 state variables
•7 measured variables
•6 control signals
•60+ symbolic equations
36
7/17/2015
Fuel System Experiments:
Parameter values
Component
Parameter
Name
Parameter
Value
Sensor Accuracy
0.05
Modeling Error
0.001
Fault Detection Threshold
2-3
Window Size (Variance Estimation)
50
Window Size (Mean Estimation)
5
Fault Isolation:
Symbol Generation
Slope Detection Sensitivity
1
Window Size
11
Fault Identification:
Parameter Estimation
Number of Samples
<=400
Error Function
Parabolic
Kalman Filter
Fault Detector
FDI system: Design Parameters
37
7/17/2015
Real-life example:
Aircraft Fuel System
Left Wing Tank Pump Degradation at t = 150
Pump fault
detected @
433 sec
Transfer manifold
pressure
Typical Fuel System Configuration
Right Wing Tank
P
P
P
P
Right Feed
Tank
LV
FEED
Right Transfer Tank
Initial Set
= 13 candidates
Left Wing Tank
pressure
P
P
Transfer Pump
LV
Level Control Valve
IV
Interconnect Valve
Boost Pump
Flow Meter
BP
FM
FM
IV
TRANSFER INTER- IV
CONNECT
Left Transfer Tank
LV
Right Engine
BP
FM
BP
P
P
P
Left Feed
Tank
Left Engine
Left Wing Tank
Fuel Quantity Sensor
38
7/17/2015
Real-life example:
Aircraft Fuel System
Left Wing Tank Pump Degradation at t = 150
Typical Fuel System Configuration
Right Wing Tank
Left Wing Tank
Pressure: - (below nominal)
P
P
P
P
Right Feed
Tank
LV
FEED
Right Transfer Tank
P
P
LV
Level Control Valve
IV
Interconnect Valve
Boost Pump
Flow Meter
BP
FM
FM
BP
P
Transfer Pump
FM
IV
TRANSFER INTER- IV
CONNECT
Left Transfer Tank
LV
Right Engine
BP
P
P
Left Feed
Tank
Left Engine
Left Wing Tank
Fuel Quantity Sensor
4 candidates
39
7/17/2015
Real-life example:
Aircraft Fuel System
Left Wing Tank Pump Degradation at t = 150
After parameter estimation
True fault: LWTTFvalue=0.66
Observer updated: Tracking
Again successful
Typical Fuel System Configuration
Right Wing Tank
P
P
P
P
Right Feed
Tank
LV
BP
FEED
Right Transfer Tank
P
P
Transfer Pump
LV
Level Control Valve
IV
Interconnect Valve
Boost Pump
Flow Meter
BP
FM
FM
IV
TRANSFER INTER- IV
CONNECT
Left Transfer Tank
LV
Right Engine
FM
BP
P
P
P
Left Feed
Tank
Left Engine
Left Wing Tank
Fuel Quantity Sensor
40
7/17/2015
Real-life example:
Aircraft Fuel System
Left Wing Tank Pump Degradation at t = 150
TCG LOG
Typical Fuel System Configuration
Right Wing Tank
P
P
P
P
Right Feed
Tank
LV
BP
FEED
Right Transfer Tank
P
P
Transfer Pump
LV
Level Control Valve
IV
Interconnect Valve
Boost Pump
Flow Meter
BP
FM
FM
IV
TRANSFER INTER- IV
CONNECT
Left Transfer Tank
LV
Right Engine
FM
BP
P
P
P
Left Feed
Tank
Left Engine
Left Wing Tank
Fuel Quantity Sensor
41
7/17/2015
Aircraft Fuel System
Left Wing Tank Pump Degradation at t = 150
Time
Measured
Deviation
Fault Set
433
Transfer Manifold
Pressure (XMP)
13 candidates
Summary of
434
XMP: discontinuous
10 candidates
Results
439
465
469
471
489
528
528
Mode Change: Left Feed Tank
Mode Change: Left Feed Tank Off
LWT_Pipe.R+, LWT.TFLWT.R+, Leg26.R-
Left Wing Tank
Pressure ++
Mode Change: Left Wing Tank: Pump On
LWT_Pipe.R+, LWT.TFLWT.R+
Left Feed Tank
Pressure --
Mode Change: Left Feed Tank On
Parameter Estimation
started
42
LWT.TF-: fault
coefficient: 0.658
7/17/2015
Fuel System: Experimental
Results
Faults
Performance Parameters
Fault Type
Fault
Fault Detection
Fault
Initial/Final
Parameter
Magnitude
Time
Isolation Time Candidate Set Estimation Error
Noise level
2%
3%
2%
3%
2%
3%
2%
3%
LTT-Pump
Efficiency
Drop
33%
422
555
225
398
14/3
13/4
2.19
5.43
60%
182
183
144
240
13/4
13/4
1.28
1.79
80%
134
134
124
197
13/4
13/5
0.88
1.49
RWT-Pump
Efficiency
Drop
33%
117
285
170
211
13/4
13/4
2.15
6.11
60%
83
93
139
183
13/4
13/4
1.52
1.67
80%
5
5
55
106
13/3
13/4
0.68
0.68
 1.5
63
65
97
103
25/2
25/2
0.62
0.5
 1.75
51
63
58
86
25/2
23/1
0.28
0.46
 2.00
51
52
46
79
23/1
25/2
0.2
0.2
 1.5
99
100
136
350
14/3
14/3
1.58
1.65
 1.75
95
95
90
303
14/2
14/3
0.78
0.57
 2.00
93
93
76
202
14/2
14/2
0.19
0.34
RLCV –Block
(valve)
Leg21-Pipe
(Block)
43
7/17/2015
Aircraft Fuel System
Typical Fuel System Configuration
Diagnosability of Faults
Right Wing Tank
Using simulated data
P
P
P
P
Right Feed
Tank
BP
LV
FEED
Right Transfer Tank
P
P
Transfer Pump
LV
Level Control Valve
IV
Interconnect Valve
Boost Pump
Flow Meter
BP
FM
FM
IV
TRANSFER INTER- IV
CONNECT
Left Transfer Tank
LV
Right Engine
FM
Measured Variables for experiment:
output pressures at the wing,transfer, and feed tanks,
& pressure at transfer manifold.
2% noise in measured signals (Gaussian)
BP
P
Left Feed
Tank
P
P
Left Engine
WTP WTR TTP TTR TMR SPR FTP FTR
WTP
Left Wing Tank
Fuel Quantity Sensor
WT – Wing Tank
TT – Transfer Tank
WTR
TTP
TTR
TM – Transfer Manifold
TMR
FT – Feed Tank
SPR
P: Pump, R: Resistance
FTP
FTR
–
X






X
–








–
X
X





X
–
X





X
X
–








–


Using TCG diagnostics -- cannot differentiate between pump degradation and pipe leak on a segment
Need additional measurements: e.g., flow rates, pump output
44






–
X






X
–
7/17/2015
Summary
• Modeling of Physical Hybrid Systems using Hybrid
Bond Graphs
– Computational models derived –
• Hybrid Automata
• State Space Equations
• Temporal Causal Graph
• Fault Diagnosis: Process parameter based using
qualitative + quantitative methods
–
–
–
–
Hybrid Observers
Robust Fault Detection + Symbol Generation
Fault Isolation (Qualitative)
Fault Identification (Parameter estimation)
• Toolset for modeling, tracking, FDI, and fault-adaptive
control
45
7/17/2015
Software Components
Tool chain development
Software Generation
Model Database
for
Plant, Components,
and Controller
FML file:
Compact, textual
representation of
the models
Desktop
Run-time
package
Generator
(Model
Interpreter)
CPP/H files:
Models in the form
of executable C++
code
Generator produces
•Loadable model file for desktop
experiment environment
•Executable C++ code for
embedded platform
47
Platform
Run-time
package
7/17/2015
Tool Operations
2. Desktop experimentation,
validation
1. Modeling
3. Feedback
Model
Interpretation
4. Deployment on embedded
platform
48
7/17/2015
Application options
Hybrid diagnosis in a user
application
Component
failures,
magnitudes
Data
Collection
Fault Diagnostics Application:
IVHM Monitoring and Fault Isolation
49
7/17/2015
Application options
Fault diagnostics, monitoring, and
control
Data
Collection
Output
Interface
Component
failures,
magnitudes
Application:
IVHM Fault Diagnostics,
Monitoring and Control
50
7/17/2015
Application options
Fault diagnostics and reconfigurable
control
Root failure
modes
Data
Collection
Output
Interface
Component
failures,
magnitudes
Application:
IVHM – Fault-adaptive Control
51
7/17/2015
FACT
Integration with other tools
FMECA
Diagnosability Analysis
•Detectability
•Distiniguishability
•Ambiguity sets
Simulation Tools
•Discrete-event:
•Failure propagation
•Continuous time:
•Hybrid system (Simulink/Stateflow)
Modeling Tool
Desktop Environment
Import
Translator
•Failure modes
•Monitors
•Components
Memory usage estimator
•Based on platform
Deployment Platform
Integration with autocoder
•Connection towards Matrix-X
FACT Toolsuite
52
7/17/2015
FACT: Interpeters
• Generate task specific analysis tools and
synthesize software components from the
models
• Simulink/Stateflow models for simulation/
experimental testbed
Models
• Hybrid automata (state-space)
models for system observers
Interpreters
• Hybrid TCG models for FDI
• Discrete Time models for
Systems
Tools
model-predictive control
53
7/17/2015
Building Simulation Models
using Simulink (original method)
 Preserves component based hierarchy of the model
 Utilizes bond graph component model library
 Mode switching triggers new causal assignments in
the model using the SCAP algorithm
 Fault scenarios easily created using graphical
utility
 Sensors in the model mapped to Simulink scopes
 Collect nominal + fault data for experimental
studies
Problems with this approach:
Junction switching implemented as standard
Simulink switches
All input output signals had to rerouted dynamically
at all junctions
Number of switches required very large
Solution:
Clean separation between continuous simulation
and control structure for model reconfiguration
Implement switching function as C S-functions
54
7/17/2015
Bond Graphs (BG) 
Computational Models
• BG to Block Diagram Computational Model
– Constituent element blocks + algebraic relations at
junctions
• Facilitated by exploiting causality in BG structure
– Well defined causality assignment procedures (e.g.,
SCAP: Rosenberg and Karnopp, and others)
• Determining Bond (DB)
– One per junction, derived from causality at junction
– Determines algebraic relations
55
7/17/2015
BG  block diagram conversion
(Ignore switching junctions)
e2 / f 2 : de te rminin
g bond
 e3  e4  e2
f 2  f3  f 4
Assumptions:
(i) no algebraic loops
(ii) no elements in
derivative causality
– Each BG element, i.e., sources, capacities,
inertias and resistive elements replaced by a
block expressing effort-flow relations
– Each bond replaced by two links
– Each junction replaced by block that models
algebraic constraints imposed by bond
56
7/17/2015
Example
BG  Block Diagram
Bond Graph Model
BG Component Library
Computational Structure: BG Junction
Translated Block Diagram Model
57
7/17/2015
Issues in HBG  Block Diagram
Translation Process
• HBG Complexities
– Junction switches (on and off) may cause causality changes
at runtime, thus block diagram may change
– Only changes in DBs will change algebraic relations at
junction
– These changes can propagate
Both Junctions, a and b On
Junction a turned Off
Determining bond for adjacent 0
junction changes
Changes propagate through all other
junctions
58
7/17/2015
Possible Approaches
to Simulation Model Generation
GME HBG
Model
• Pre-generation of model
configurations results in 2n
possibilities
• Online generation of models at
every mode change can be
computationally expensive
• Our approach: derive new block
diagram incrementally from old
– Start with block diagram in initial mode
– Look for changes in DBs
• Update block diagram at changes
Intermediate Block
Diagram
Representation
MDL Code
Generator
MDL
Model
SCAP
Simulate
Did a mode
switch occur?
No
Yes
Propagate
causality changes
Update Simulink
model
59
7/17/2015
Our Approach
Details
• Model Creation in Simulink
– First build library of BG components as
Simulink blocks: implemented as Matlab scripts
– Implement Junctions as C S-function
– Use add-block function to build hierarchy of
connected component models along with
determining bond information (SCAP algorithm)
• Run time
60
7/17/2015
I-Element Component
Construction
% I-Element
% Input Port
add_block('built-in/Inport',[sys,'/','Effort'])
set_param([sys,'/','Effort'],...
'Port','1',...
'position',[30,30,50,45])
% Output Port
add_block('built-in/Outport',[sys,'/','Flow'])
set_param([sys,'/','Flow'],...
'Port','1',...
'position',[435, 142, 455, 158])
% Initial Condition
add_block('built-in/Constant',[sys,'/','InitialCondition'])
set_param([sys,'/','InitialCondition'],...
'position',[30, 110, 50, 130])
% Product2
add_block('built-in/Product',[sys,'/','Product2'])
set_param([sys,'/','Product2'],...
'position',[320, 132, 350, 163])
% Inertia
add_block('built-in/Constant',[sys,'/','Inductance'])
set_param([sys,'/','Inductance'],...
'position',[30, 220, 50, 240])
% Add connections
add_line(sys, 'Effort/1','Integrator/1')
add_line(sys, 'InitialCondition/1','Product1/1')
add_line(sys, 'Inductance/1','Product1/2')
add_line(sys, 'Product1/1','Integrator/2')
add_line(sys, 'Integrator/1','Product2/1')
add_line(sys, 'Inductance/1','Reciprocal/1')
add_line(sys, 'Reciprocal/1','Product2/2')
add_line(sys, 'Product2/1', 'Flow/1')
% Math Function (Reciprocal)
add_block('built-in/Math',[sys,'/','Reciprocal'])
set_param([sys,'/','Reciprocal'],...
'Function','Reciprocal',...
'position',[125, 215, 145, 245])
% Product1
add_block('built-in/Product',[sys,'/','Product1'])
set_param([sys,'/','Product1'],...
'position',[120, 112, 150, 143])
% Integrator
add_block('built-in/Integrator',[sys,'/','Integrator'])
set_param([sys,'/','Integrator'],...
'InitialConditionSource','External',...
'position',[210, 72, 250, 123])
61
7/17/2015
Junction implementation
1  determining bond
Junction switching on  off
/* Function: mdlOutputs
* Abstract:
* This function computes the outputs of the S-function block.
* Generally outputs are placed in the output vector, ssGetY(S).
*/
static void mdlOutputs(SimStruct *S, int_T tid)
{
const real_T *in1 = (const real_T*) ssGetInputPortSignal(S,0);
const real_T *in2 = (const real_T*) ssGetInputPortSignal(S,1);
real_T
*out1 = ssGetOutputPortSignal(S,0);
real_T
*out2 = ssGetOutputPortSignal(S,1);
real_T
*control_output = ssGetOutputPortSignal(S,2);
const mxArray *determiningbonds;
double *dbdata;
int dbond;
// First, get the determining bond:
determiningbonds = mexGetVariablePtr("global", "determiningbonds");
// determiningbond == -1 means junction is off
if(dbond == -1) {
…} else { …
// get array of effort/flow inputs:
…
// sum all dependent inputs with appropriate signs
…
}
// output resulting sum on determinte bond,
// determinite bond's input on remainding:
…
// put outputs to out#:
out1[0] = outputs[0];
….
}
7/17/2015
62
}
Our Approach
Details
• Model Creation
– ….
• Run time
– If junctions change state at a particular time
step (implemented as a separate Simulink
block)
– Apply causality propagation update function,
i.e., find new determining bonds (efficient
algorithm)
– Send new information to junction blocks &
simulate next time step
63
7/17/2015
•
Causality Propagation
Details
Causality update triggered by change in discrete state
– Start at junctions which switch
– If they cause changes in adjacent junction DBs then
• update DB’s algebraic constraints
– Continue till no DB change or all junctions visited
• For efficiency, junctions implemented as S-functions; use global
variables (cf. Ptolemy’s director function)
Causality
Update
one
1
S-function
1
System.one
1
zero
1
one
2
S-function 2
S-function 3
System.zero
2
64
one
3
zero
2
S-function 4
System.one
3
System.zero
4
S-function 5
System.one
5
7/17/2015
Example – Junction Switching
65
7/17/2015
Conclusions and Future Work
• Successful demonstrations of FACT – Hybrid Diagnosis on
desktop environments
Desktop simulation environments using Simulink as a design and analysis tool
Now working on interface to hardware systems ( instrumented 3 tank system)
• Next: Multi-level decision-theoretic controller for managing
resources in hierarchical, distributed, interacting subsystems
Global system operates system within resource constraints while optimizing
performance of subsystems
Safety, robustness, and reliability based on dynamic models
Tighter bounds on sizing problems at design time
• Other Work
Incipient fault diagnosis
Distributed diagnosis
Diagnosis of multiple faults
66
7/17/2015
References
•
•
•
•
•
•
•
•
•
•
•
P. J. Mosterman and G. Biswas, “A theory of discontinuities in physical system models,” Journal of the Franklin
Institute: Engineering and Applied Mathematics, 335B(3):401-439, January 1998.
P.J. Mosterman and G. Biswas, “Building Hybrid Observers for Complex Dynamic Systems using Model
Abstractions,” Hybrid Systems: Computation and Control, Lecture Notes in Computer Science, vol. 1569, Springer
Verlag, The Netherlands, pp. 178-192, March 1999.
E.J. Manders, G. Biswas, P.J. Mosterman, L. Barford, and J. Barnett, ``Signal Interpretation for Monitoring and
Diagnosis: A Cooling System Testbed,’’ IEEE Trans. on Instrumentation and Measurement, vol. 49(3), pp. 503-509,
2000.
S. McIllraith, G. Biswas, D. Clancy, and V. Gupta, ``Hybrid Systems Diagnosis,'' Hybrid Systems: Computation
and Control -- Third Intl. Workshop, HSCC 2000, Lecture Notes in Computer Science, vol. 1790, N. Lynch and B. H.
Krogh, eds., Springer Verlag, Berlin, Germany, pp. 282-295, March 2000.
P.J. Mosterman and G. Biswas, “A Hybrid Modeling and Simulation
Methodology for Dynamic Physical Systems, SIMULATION: Transactions of
the Society for Modeling and Simulation International, vol.78, no.1, pp.5-17,
Jan. 2002.
S. Narasimhan and G. Biswas, “An Approach to Model-Based Diagnosis of Hybrid Systems,'' Hybrid Systems:
Computation and Control, Fifth Intl. Workshop, Stanford, CA, Lecture Notes in Computer Science, vol. LNCS 2289,
C.J. Tomlin and M.R. Greenstreet, eds., Springer Verlag, Berlin, pp. 308-322, March 2002.
S. Narasimhan, G. Biswas, G. Karsai, T. Szemethy, T. Bowman, M. Kay, and K. Keller, “Hybrid Modeling and
Diagnosis in the Real World: A Case Study,'' Intl. Workshop on Principles of Diagnosis, Simmering, Austria, May
2002.
G. Karsai, G. Biswas, S. Narasimhan, T. Szemethy, G. Peceli, G. Simon, and T. Kovacshazy, “Towards FaultAdaptive Control of Complex Dynamic Systems,” Software-Enabled Control: Information Technologies for
Dynamical Systems, T. Samad and G. Balas, eds., IEEE Press, pp 347-368, 2003.
E.J. Manders and G. Biswas, “FDI of abrupt faults with combined statistical detection and estimation and qualitative
fault isolation,” 5th IFAC Symposium on Fault Detection, Supervision and Safety of Technical Processes
(SAFEPROCESS), Washington, D.C., pp. 347-352, June 2003.
S. Narasimhan and G. Biswas, “Model-based Diagnosis of Hybrid Systems,” to appear IEEE Transactions on
Systems, Man, and Cybernetics, Part A, to appear Sept. 2006.
E.J. Manders, G. Biswas, N. Mahadevan, G. Karsai, "Component-oriented modeling of hybrid dynamic systems
using the Generic Modeling Environment," pp. 159-168, Fourth Workshop on Model-Based Development of
Computer-Based Systems and Third International Workshop on Model-Based Methodologies for Pervasive and
Embedded Software (MBD-MOMPES'06), 2006. 67
7/17/2015
Lecture 3
• Limited Lookahead + Hierarchical Control
• Distributed Diagnosis
• Diagnosis of Incipient Faults
68
7/17/2015