Fault-tolerant Control
•
•
•
•
•
•
•
•
•
Motivation
Definitions
A general overview on the research area.
Active Fault Tolerant Control (FTC)
FTC- Analysis and Development procedure
Supervisor architecture
Logic realization
Design and development tools
Implementation
Fault Tolerant Control
• Motivation:
– Demand for higher autonomy and reliability requires considering
all possible situations to guarantee correct and consistent operation
• Purpose:
– Using a logically sound stepwise guideline to achieve
•
•
•
•
Complete coverage of possible single faults.
Supportive software tools.
Avoiding unnecessary plant modelling.
Automatic code generation.
• Initial Prerequisites:
– Initial system concept is established.
– Systems requirements are specified: (operating modes and
functions, required performance, environmental, safety, or
regularity requirements)
Approaches to achieve FTC
Fault-tolerant
Control
Passive
Robust
control
Active
FDI or SID +
reconfiguration
Projection-based
or switching
on-line redesign
or adaption
FTC development procedure - I
Analysis
1
Component
failure
modes
2
Fault modelling
Fault propagation analysis
FPA
data base
3
Desired effects
to be handled
4
Functional
structure
model
List of
possible
effects
Causal relation analysis
Faults/effects
to be detected
Severity assessment
Location for
reconfiguration
5
Possible detectable faults
+ sensor fusion
possibilities
Structural analysis
ARRs
6
Reconfiguration Remedial action selection
condition
Remedial
actions
Commands and
monitoring
Detector
design
Supervisor
design
7
9
Effector
design
8
Design
FTC Development procedure - II
Fault Modelling
Failure Mode and Effect Analysis -FMEA
FMEA scheme for the
Wheel system
FMEA – Other examples
FMEA scheme for the GPS
Fault assessment - I
• Severity Occurrence Index (SO)
– Severity
Potential harm that fault effect inflicts the system;
Severity is quantified by severity scale from 1 to 10.
– Occurrence; the frequency of fault occurrence during
expected operational time interval; is quantified by by
scale from 1 (unlikely to occure) to 10 (persistent
failure)
– SO index:
SO = Severity . Occurrence
Fault Assessment II
Severity and Occurrence analysis of the Wheel system
Fault Assessment III
Evaluation guidelines and identification of severe failures that
need to be handled
Fault Assessment – List of faults
Periority assignment to different fault types
Fault Assessment – Causality Analysis
Identifying possible causes of failures by backward
search through the Wheel system
FMEA analysis and Structural Analysis
Knowledge representation
Component's
abnormal
function
Knowledge formulation and manipulation
FMECA
(Hazard analysis)
Faults to be
handled
Remedial
action selection
&
Components
Component's
normal
function
Abstraction
Monitorable
Parts
Structural analysis
Implementation & analysis
Detailed
FDI design
Nonmonitorable
Parts
Decision & design
Chosen approaches to detailed design
(algorithms)
Fault-tolerant
Control
Passive
Robust
control
Active
FDI or SID +
reconfiguration
Projection-based
or switching
on-line redesign
or adaption
Supervisory Control - Definitions
• To supervise:
To oversee and guide the work or activities of a group of
people/system, etc.
• Supervision:
– Monitoring a physical system and taking appropriate actions to
maintain the operation in the case of faults
– The ability to monitor whether control objectives are met. If not,
obtain/calculate a revised control objective and a new control
structure and parameters that make a faulty closed-loop system
meet the new modified objectives. Supervision should take effect if
faults occur and it is not possible to meet the original control
objective within the fault-tolerant scheme.
Supervisor Architecture
Plant wide control / operator
Command &
set points
Interface
State info. &
alarms
Supervisor/decision logic
Decision
Action
Set points
Detections
Effectors
Filtering &
validity check
Detectors
Control
algorithms
Data/info.
Actuators
Sensors
Control level
Logic realization
•Language approach - a component based method
•State-event machines
Redundancy
possibilities
Responsibility/task
Control systems hierarchy
Int.
cond.
(sub)systems
Int.
cond.
Actuators
Ext.
cond.
Int.
cond.
Controllers
Ext.
cond.
Sensors
Ext.
cond.
Evolving/developing
Hardware
redundancy
Performing action
Hardware
&
software
redundancy
Information manipulation
and decision taking
Information
acquisition
Int.
cond.
Figure- Control system hierarchy consists of four principle components
Ext.
cond.
Constructing the logic - Language approach
fB
Fig.1
IB21
IB22
IB23
fA
IA31
IA32
IA33
.
C
Controller
IA1
IA2
IA3
Component
A
A
P
Actuator
Plant
.
(a) with loop
C
Controller
P
Actuator
Plant
S
(b) without loop
Sensor
OB
OP
OP=HCP.HCA.HCC.HCS.
HCP.HCA.HCC.HCS.
....................
=[HCP.HCA.HCC.HCS]
OP
OP = HCP.HCA.HCC.HCS..
Sensor
A
Component
B
OA
S
Fig.2
IB3
IB2
IB1
1
= [HCP.HCA.HCC.HCS]
Constructing the logic - State-event machines
Re-configurable control systems hierarchy
(sub)system
(sub)system1 2
Actuator
Actuator1 2
Controller
1
Controller
Controller2 3
Sensor
setset1 2
Sensor
Sensor
set 3
FSM representation
Logic design - Knowledge aquisition
External conditions
(environment)
Faults
Affected
goals
Reconfiguration
possibilities
Logic design
Affected
subsystems
Upper level/operator
messages
Design Tools and implementaion
• Tools
– Statecharts
• Hierarchy/depth
• Concurrency
• Comunication
– Stateflow (Matlab)
– Beologic (B&O)
• Consistency/correctness
– Beologic
• Implementation
– IF-THEN rules
– Object Oriented structure
Exercise and next lecture
• Exercise
• Objectives:
» System analysis and knowledge acquisition about
faults and their effect on the system operation.
» Consider reconfiguration possibilities
• Next lecture
• Structural analysis approach:
– Monitorable vs. non-monitoravble part of the systems