8 Organization of a Model¶
This chapter discusses the organizations of models. It includes the definition of two additional constructs: the notions of consequence, consequence group, and alignment.
8.1 Additional Constructs¶
8.1.1 Consequences and Consequence Groups¶
It is often convenient to group sequences of event trees into bins of sequences with similar physical consequences (e.g., Core Melt). The Model Exchange Format provides the notion of consequence to do so. A consequence is characterized by an event tree, a particular initiating event for this event tree, and a particular sequence (end-state) of the same tree. Consequences are given a name. Groups of consequences can be defined as well. They are also given a name, and can include sub-groups. The RNC schema for the XML representation of declarations of groups of consequences is given in Listing 8.1.
consequence-definition =
element define-consequence {
name,
label?,
attributes?,
element initiating-event { name },
element sequence { name }
}
consequence-group-definition =
element define-consequence-group {
name, label?, attributes?, (consequence | consequence-group)*
}
consequence = element consequence { name }
consequence-group = element consequence-group { name }
Note that consequences and consequence groups can be used as initiating events (see Section 7.2.2). This mechanism makes it possible to link event trees.
8.1.2 Missions, Phases¶
Phases are physical configurations (e.g., operation and maintenance) in which the plant spends a fraction of the mission time. Phases are grouped into missions. The time fractions of the phases of a mission should sum to 1. House events and parameters may be given different values in each phase. The RNC schema for the XML representation of phase declarations is given in Listing 8.2.
alignment-definition =
element define-alignment {
name, label?, attributes?, phase-definition+
}
phase-definition =
element define-phase {
name,
attribute time-fraction { xsd:double },
label?,
attributes?,
instruction*
}
8.2 Splitting the Model into Several Files¶
So far, we have written as if the model fits completely into a single file. For even medium size PSA models this assumption not compatible with Quality Control. Moreover, such a monolithic organization of data would be very hard to manage when several persons work together on the same model.
A first way to split the model into several files is to use the XML notion of entities: in any XML file, it is possible to declare file entities in the preamble, and to include them in the body of the document. This mechanism is exemplified below.
<?xml version="1.0" ?>
<!DOCTYPE SMRF [
<!ENTITY file1 SYSTEM "file1.xml">
<!ENTITY file2 SYSTEM "file2.xml">
]>
<smrf>
...
&file1;
...
&file2;
...
</smrf>
This mechanism, however, has the drawback that XML tools have to actually include the files into the document, hence, making its manipulation heavier.
The Model Exchange Format proposes another simple mechanism to achieve the same goal: the tag include. This tag can be inserted at any place in a document. Its effect is to load the content of the given file into the model.
<opsa-mef>
...
<include file="basic-events.xml"/>
...
</opsa-mef>
8.3 Organization of a Model¶
The Model Exchange Format introduces five types of containers: models at the top level, event trees, fault trees, components, and model-data. The Model Exchange Format introduces also eighteen constructs. Fig. 8.1 shows the containers and the constructs they can define.
Fig. 8.1 Containers and the constructs they can define
Listing 8.3 gives the RNC schema of the XML representation of a model.
model =
element opsa-mef {
name?,
label?,
attributes?,
(model-data
|event-tree-definition
| alignment-definition
| consequence-group-definition
| consequence-definition
| rule-definition
| initiating-event-group-definition
| initiating-event-definition
| fault-tree-definition
| substitution-definition
| CCF-group-definition
| include-directive)*
}