1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
<?xml version="1.0"?>
<!--
This input demonstrates whether module handling is lazy.
The input must be run with cut-off 6 on the cut set order.
Some very expensive module must be given for gate "r1" in this input.
If the "r1" gate is analyzed,
the analysis is strict with modules and doing unnecessary work.
If the "r1" is not analyzed,
the analysis is lazy.
Note that preprocessing techniques may prune the graph
and correctly handle this demonstration.
In this case, the analysis algorithms
may not have a chance to demonstrate the lazyness.
Also note that gate coalescing techniques may mess the demonstration.
-->
<opsa-mef>
<define-fault-tree name="r">
<define-gate name="r">
<or>
<and>
<event name="event1"/>
<event name="event2"/>
<event name="event3"/>
<event name="event4"/>
<event name="event5"/>
<event name="event6"/>
<gate name="r1"/> <!-- Stick some expensive module here -->
</and>
<event name = "event7"/>
</or>
</define-gate>
<define-basic-event name="event1"/>
<define-basic-event name="event2"/>
<define-basic-event name="event3"/>
<define-basic-event name="event4"/>
<define-basic-event name="event5"/>
<define-basic-event name="event6"/>
<define-basic-event name="event7"/>
</define-fault-tree>
</opsa-mef>
|
