View
3
Download
0
Category
Preview:
Citation preview
Safety Assessment of an Electrical System with AltaRica 3.0
Hala MORTADA (LIX, Ecole Polytechnique)
Tatiana PROSVIRNOVA (LIX, Ecole Polytechnique)
Antoine RAUZY (LGI, Ecole Centrale)
2 IMBSA 2014 , October 27 – 29, 2014
• Case study: an Electrical System
• Structural constructs
• Behavior modeling
—Block diagrams
—Common cause failures
—Repairs, on demand failures and reconfigurations
—Shared resources
Outline
Starting from the same root model, different variants can be obtained by successive refinements.
3 IMBSA 2014 , October 27 – 29, 2014
• Case study: an Electrical System
• Structural constructs
• Behavior modeling
—Block diagrams
—Common cause failures
—Repairs, on demand failures and reconfigurations
—Shared resources
Outline
Starting from the same root model, different variants can be obtained by successive refinements.
4 IMBSA 2014 , October 27 – 29, 2014
Case study: an Electrical System
Transformer TR1
Transformer TR2
Diesel Generator DG
Circuit breaker CBD1
Circuit breaker CBD2
Circuit breaker CB3
Busbar
Grid GR
Circuit breaker CBU1
Circuit breaker CBU2
Backup Power Supply Primary Power Supply
Line1 Line2
5 IMBSA 2014 , October 27 – 29, 2014
• Case study: an Electrical System
• Structural constructs
• Behavior modeling
—Block diagrams
—Common cause failures
—Repairs, on demand failures and reconfigurations
—Shared resources
Outline
Starting from the same root model, different variants can be obtained by successive refinements.
6 IMBSA 2014 , October 27 – 29, 2014
• Blocks represent components having a unique occurrence in the model
• They are the basic construct to group model elements
• A model is thus a hierarchy of nested blocks
• Blocks come from prototype-oriented languages
Blocks
block DieselGenerator block CircuitBreaker
block BackupPowerSupplySystem
block BackupPowerSupplySystem block DieselGenerator // elements of the diesel generator end
block CircuitBreaker // elements of the circuit breaker end
/* elements to connect the diesel generator and the circuit breaker*/
end
7 IMBSA 2014 , October 27 – 29, 2014
• A class is a separately defined, reusable (“on-the-shelf”) block
• A block can aggregate (contain) other blocks as well as instances, i.e. copies, of classes
• A class can aggregate blocks and instances of classes
• Definitions of classes cannot be recursive nor circular
• Classes come from object-oriented modeling languages
Classes
class DieselGenerator // elements of the diesel generator
end class CircuitBreaker // elements of the circuit breaker end block BackupPowerSupplySystem DiseselGenerator DG; CircuitBreaker CB3; /* elements to connect
the diesel generator DG and the circuit breaker CB3*/
end
DieselGenerator DG CircuitBreaker CB3
block BackupPowerSupplySystem
8 IMBSA 2014 , October 27 – 29, 2014
• The semantics of AltaRica 3.0 is defined by means of flattening rules, i.e. that the hierarchy of blocks and instances of classes is collapsed into a single block
• Flattening rules depend on the type of hierarchical links:
—Aggregation
—Inheritance
—Reference (“embeds” clause)
Flattening
9 IMBSA 2014 , October 27 – 29, 2014
• A hierarchical link: the is-a-part-of link
— e.g. the left-front wheel is a part of the car
• In AltaRica 3.0, a block or a class can aggregate blocks and instances of classes
• Flattening rules:
—Elements of the nested block (or the instance of class) are copied;
—Names of the elements are prefixed with the name of the block (or the instance of class)
Aggregation
class DieselGenerator Boolean working (init = true); event failure; transition failure : working -> working :=false; end block BackupPowerSupplySystem DieselGenerator DG; end
block BackupPowerSupplySystem Boolean DG.working (init = true); event DG.failure; transition DG.failure : DG.working -> DG.working :=false; end
flattening
10 IMBSA 2014 , October 27 – 29, 2014
• A hierarchical link: the is-a-kind-of link
— e.g. a car is a kind of vehicle
• In AltaRica 3.0, a block or a class can inherit from another class.
• Flattening rules for inheritance are the same as those for aggregation, with the exception that the elements of the inherited components are copied without any prefix
Inheritance
class NonRepairableComponent Boolean working (init = true); event failure; transition failure : working -> working :=false; end class Pump extends NonRepairableComponent Boolean inflow (reset = false); Boolean outflow (reset = false); assertion outflow := inflow and working; end
class Pump Boolean working (init = true); Boolean inflow (reset = false); Boolean outflow (reset = false); event failure; transition failure : working -> working :=false; assertion outflow := inflow and working; end
flattening
11 IMBSA 2014 , October 27 – 29, 2014
• Hierarchical decompositions are often thought only as tree-like structures. But in practice it is often convenient for two branches to share a component (especially when reasoning in functional terms).
• AltaRica 3.0 makes it possible to share blocks and instances of classes through the “embeds” clause.
Reference: the “embeds” clause
block PrimaryPowerSupplySystem
Transformer TR1
Grid GR
Transformer TR2
block Line1 block Line2
block PrimaryPowerSupplySystem Grid GR; block Line1 embeds GR; Transformer TR1; end block Line2 embeds GR; Transformer TR2; end end
Grid GR
12 IMBSA 2014 , October 27 – 29, 2014
System architecture
block ElectricalSystem block PrimaryPowerSupplySystem Grid GR; block Line1 embeds GR; CircuitBreaker CBU1, CBD1; Transformer TR1; end block Line2 embeds GR; CircuitBreaker CBU2, CBD2; Transformer TR2; end end block BackupPowerSupplySystem DieselGenerator DG; CircuitBreaker CB3; end Busbar BB; end
Class instances Blocks
13 IMBSA 2014 , October 27 – 29, 2014
• Case study: an Electrical System
• Structural constructs
• Behavior modeling
—Block diagrams
—Common cause failures
—Repairs, on demand failures and reconfigurations
—Shared resources
Outline
Starting from the same root model, different variants can be obtained by successive refinements.
14 IMBSA 2014 , October 27 – 29, 2014
Behavior modeling
Block Diagram
Common cause Failures
Repairs, on demand failures and
reconfigurations
Shared resources
block ElectricalSystem block PrimaryPowerSupplySystem Grid GR; block Line1 embeds GR; CircuitBreaker CBU1, CBD1; Transformer TR1; end block Line2 embeds GR; CircuitBreaker CBU2, CBD2; Transformer TR2; end end block BackupPowerSupplySystem DieselGenerator DG; CircuitBreaker CB3; end Busbar BB; end
1
2
3
4
15 IMBSA 2014 , October 27 – 29, 2014
Block diagram: modeling 1
domain ComponentState { WORKING, FAILED } class NonRepairableComponent ComponentState s (init = WORKING); event failure (delay = exponential(lambda)); parameter Real lambda = 0.001; transition failure: s == WORKING -> s := FAILED; end class Transformer extends NonRepairableComponent; Boolean inFlow, outFlow (reset = FALSE); assertion outFlow := (s == WORKING) and inFlow; end
failure
s == WORKING
s == FAILED
inFlow outFlow
All the components are represented by the class NonRepairableComponent with input and output flows
16 IMBSA 2014 , October 27 – 29, 2014
Block diagram: modeling 1
block ElectricalSystem Boolean outFlow (reset = false); block PrimaryPowerSupply … block Line1 … assertion CBU1.inFlow := GR.outFlow; TR1.inFlow := CBU1.outFlow; CBD1.inFlow := TR1.outFlow; end block Line2 ... // similar to Line1 end assertion outFlow := Line1.outFlow or Line2.outFlow; end ... assertion outFlow := PrimaryPowerSupply.outFlow or BackupPowerSupply.outFlow; end
17 IMBSA 2014 , October 27 – 29, 2014
• Static model
• Is compiled into Fault Trees
• Calculated Minimal cutsets (MCS):
Block diagram: assessment 1
MCS MCS
GR.failure, DG.failure GR.failure, CB3.failure
CBU1.failure, CBU2.failure, DG.failure CBU1.failure, CBU2.failure, CB3.failure
CBU1.failure, TR2.failure, DG.failure CBU1.failure, TR2.failure, CB3.failure
CBU1.failure, CBD2.failure, DG.failure CBU1.failure, CBD2.failure, CB3.failure
TR1.failure, CBU2.failure, DG.failure TR1.failure, CBU2.failure, CB3.failure
TR1.failure, TR2.failure, DG.failure TR1.failure, TR2.failure, CB3.failure
TR1.failure, CBD2.failure, DG.failure TR1.failure, CBD2.failure, CB3.failure
CBD1.failure, CBU2.failure, DG.failure CBD1.failure, CBU2.failure, CB3.failure
CBD1.failure, TR2.failure, DG.failure CBD1.failure, TR2.failure, CB3.failure
CBD1.failure, CBD2.failure, DG.failure CBD1.failure, CBD2.failure, CB3.failure
18 IMBSA 2014 , October 27 – 29, 2014
• Consider that the two transformers have a common cause failure due to a fire propagation.
• Assume that the CCF failure rate lambdaCCF =1.0e-5.
Common cause failures
Fire propagation Failure of both transformers
2
19 IMBSA 2014 , October 27 – 29, 2014
block PowerSupplySystem
block PrimaryPowerSupplySystem
Grid GR;
block Line1
…
end
block Line2
…
end
event TransformersCCF (delay = exponential (lambdaCCF));
parameter Real lambdaCCF = 1.0e–5;
transition
TransformersCCF: ?Line1.TR1.failure & ?Line2.TR2.failure;
…
end
…
end
Common cause failures: modeling 2
20 IMBSA 2014 , October 27 – 29, 2014
• Static model
• Is compiled into Fault Trees
• Two additional minimal cutsets:
Common cause failures: assessment 2
MCS
TransformersCCF, DG.failure
TransformersCCF, CB3.failure
21 IMBSA 2014 , October 27 – 29, 2014
• Consider that —The circuit breakers can be open, closed and can have on demand
failures (failure to open or failure to close) with a given probability gamma = 10-3.
—The diesel generator can be started or stopped and can have on demand failure (failure to start).
—In the initial state the power is transmitted to the Busbar via the Line 1, i.e. the circuit breakers CBU1 and CBD1 are closed, the circuit breakers CBU2 and CBD2 are open, the diesel generator DG is stopped, the circuit breaker CB3 is open.
—If the Line 1 fails, the system should be reconfigured to use the Line 2 (i.e. the circuit breakers CBU2 and CBD2 should be closed). If both lines are failed, the diesel generator DG is attempted to start and the circuit breaker CB3 is attempted to close.
Repairs, on demand failures and reconfigurations 3
22 IMBSA 2014 , October 27 – 29, 2014
Repairs, on demand failures and reconfigurations: modeling
class RepairableComponent extends NonRepairableComponent; Boolean failed (reset = false); event repair (delay = exponential(mu)); parameter Real mu = 0.1; transition repair: s == FAILED -> s := WORKING; assertion failed := s == WORKING; end class Grid extends RepairableComponent; Boolean outFlow (reset = false); assertion outFlow := s==WORKING; end
repair failure
s == WORKING
s == FAILED
How to model a repairable component?
3
The grid GR and the transformers TR1 and TR2 are repairable components
23 IMBSA 2014 , October 27 – 29, 2014
Repairs, on demand failures and reconfigurations: modeling
class CircuitBreaker extends RepairableComponent; Boolean isClosed (init = true); Boolean demanded (reset = false); event failToOpen (delay = 0, expectation = gamma1); event failToClose (delay = 0, expectation = gamma2); event open (delay = 0, expectation = 1 - gamma1); event close (delay = 0, expectation = 1 - gamma2); parameter Real gamma1 = 0.001; parameter Real gamma2 = 0.001; transition failToOpen: isClosed and (s == WORKING) and not demanded-> s := FAILED; open: isClosed and (s == WORKING) and not demanded-> isClosed := false; failToClose: not isClosed and (s == WORKING) and demanded-> s := FAILED; close: not isClosed and (s == WORKING) and demanded-> isClosed := true; assertion outFlow := isClosed and s == WORKING and inFlow; end
How to model a circuit breaker?
outFlow
demanded
inFlow
failure
s == WORKING isClosed
s == FAILED isClosed
s == WORKING not isClosed
s == FAILED not isClosed
failure
failToClose
close open
failToOpen
repair
repair
3
24 IMBSA 2014 , October 27 – 29, 2014
Repairs, on demand failures and reconfigurations: modeling
domain SpareComponentState {STANDBY, WORKING, FAILED} class SpareComponent; SpareComponentState s (init = STANDBY); Boolean failed (reset = false); Boolean demanded (reset = FALSE); parameter Real lambda = 1.0e-4; parameter Real mu = 0.1; parameter Real gamma = 0.001; event failure (delay = exponential(lambda)); event repair (delay = exponential(mu)); event stop (delay = 0); event start (delay = 0, expectation = 1-gamma); event failureOnDemand (delay = 0, expectation = gamma); event repair (delay = exponential(mu)); transition stop: s == WORKING and not demanded -> s := STANDBY; start: s == STANDBY and demanded -> s := WORKING; failureOnDemand: s == STANDBY and demanded -> s := FAILED; repair: s == FAILED -> s := STANDBY; failure: s == WORKING -> s := FAILED; assertion failed := s == FAILED. end
How to model a spare component? demanded
failure
s == WORKING
s == FAILED repair
s == STANDBY
stop
start
failureOnDemand
3
The diesel generator DG is represented by a spare component
25 IMBSA 2014 , October 27 – 29, 2014
Repairs, on demand failures and reconfigurations: modeling
How to represent reconfigurations?
block PowerSupplySystem block PrimaryPowerSupplySystem Boolean failed, demanded (reset = false); Grid GR; block Line1 Boolean failed, demanded (reset = false); … assertion CBU1.demanded := demanded; CBD1.demanded := demanded; failed := GR.failed or CBU1.failed or TR1.failed or CBD1.failed; end … assertion Line1.demanded := not Line1.failed and not Line2.outFlow; Line2.demanded := not Line2.failed and not Line1.outFlow; … end
Lin
e1
Lin
e2
demanded demanded
failed failed
outFlow outFlow
PrimaryPowerSupplySystem
demanded
failed outFlow
3
26 IMBSA 2014 , October 27 – 29, 2014
• Dynamic model
• Is compiled into Markov chains
• Assessment of the generated Markov chain: unavailability calculation
On demand failures and reconfigurations: assessment
3
0.02E-06
0.02E-06
0.02E-06
0.02E-06
0.02E-06
0.02E-06
0.02E-06
0.02E-06
0.02E-06
0.02E-06
0.02E-06
20 30 40 50 60 70 80 90 100 200 300 400 500 600 700 800 900 1000
Pro
bab
ility
Mission time
Unavailability
27 IMBSA 2014 , October 27 – 29, 2014
Shared resources
TR1 TR2 R
(Repair crew) GR
GR.failure
GR_startRepair
CCF
TR1_startRepair
GR_endRepair
TR2_startRepair
GR.startRepair R.startJob
TR1.failure TR2.failure
TR1.startRepair R.startJob
GR.endRepair R.endJob
TR1_endRepair TR1.endRepair R.endJob
TR2.startRepair R.startJob
TR2_endRepair TR2.endRepair R.endJob
4
Consider that a limited repair crew can work on at most two components at a time
28 IMBSA 2014 , October 27 – 29, 2014
Shared resources: modeling
class RepairCrew Integer numberOfBusyRepairers (init = 0); parameter Integer totalNumberOfRepairers = 2; event startJob, endJob; transition startJob: numberOfBusyRepairers < totalNumberOfRepairers -> numberOfBusyRepairers := numberOfBusyRepairers + 1; endJob: numberOfBusyRepairers > 0 -> numberOfBusyRepairers := numberOfBusyRepairers - 1; end
0 1 N …
startJob startJob startJob
endJob endJob endJob
How to model a repair crew?
4
29 IMBSA 2014 , October 27 – 29, 2014
Shared resources: modeling
endRepair
failure
s == WORKING
domain RepairableComponentState {WORKING, FAILED, UNDER_REPAIR} class RepairableComponent RepairableComponentState s (init = WORKING); Boolean failed (reset = false); event failure (delay = exponential(lambda)); event startRepair; event endRepair (delay = exponential(mu)); parameter Real mu = 0.; parameter Real lambda = 1.0 e-4; transition failure: s == WORKING -> s := FAILED; startRepair: s == FAILED -> s := UNDER_REPAIR ; endRepair: s == UNDER_REPAIR -> s := WORKING; assertion failed := s == FAILED or s == UNDER_REPAIR; end
s == FAILED
s == UNDER_REPAIR startRepair
How to model a repairable component?
4
30 IMBSA 2014 , October 27 – 29, 2014
Shared resources: modeling
block PowerSupplySystem block PrimaryPowerSupplySystem … end block BackupPowerSupplySystem … end … RepairCrew R(totalNumberOfRepairers = 2); event GR_startRepair; event GR_endRepair; … transition GR_startRepair: !R.startJob & !PrimaryPowerSupplySystem.GR.startRepair; GR_endRepair: !R.endJob & !PrimaryPowerSupplySystem.GR.endRepair; hide R.startJob, R.endJob; hide PrimaryPowerSupplySystem.GR.startRepair, PrimaryPowerSupplySystem.GR.endRepair; … end
How to synchronize events?
4
31 IMBSA 2014 , October 27 – 29, 2014
Shared resources: assessment
0.00E+00
0.02E-06
0.04E-06
0.06E-06
0.08E-06
0.10E-06
0.12E-06
0.14E-06
0.16E-06
20 30 40 50 60 70 80 90 100 200 300 400 500 600 700 800 900 1000
Pro
bab
ility
Mission time
Unavailability for different number of repairers
Proba (n=1) Proba (n=3) Proba (n=infinite)
ʎ 10-4
ɤ 10-3
µ 10-1
4
Dynamic model
Is compiled into Markov chains
Assessment of the generated Markov chain: unavailability calculation
32 IMBSA 2014 , October 27 – 29, 2014
• Different variants of models of the case study have been defined
—The first series targeting a compilation into Fault Trees
—The second series targeting a compilation into Markov chains
• Each of these variants captures a particular aspect of the system under study
• A model is always a trade-off between the accuracy of the description and the ability to perform calculations
• Refining a model in successive variants is a good way to seek a good trade-off
• The approach made of successive derivation of variants is a solid ground to build a modeling methodology
Conclusion
Recommended