¶ XML Representation
The RNC schema for the XML description of fault trees is given in Fault Tree.
This description deserves some comments.
- It leaves for now the tags “define-parameter” and “expression” unspecified. We shall see in the next chapter how these tags are used to define the probability distributions.
- Similarly, the tag “define-component” will be explained in the next section.
- Although the Model Exchange Format adopts the declarative modeling paradigm, it is often convenient to use variables in formulae before declaring them. The Model Exchange Format, therefore, refers to variables with the generic term “event”, possibly without a “type” attribute.
- By default, the value of a house event is “false”, so it is not necessary to associate a value with a house event when declaring it. We saw in the Event Tree Layer instructions section how to change the value of a house event.
- Although events are typed (they are either gates, house events or basic events), two different events cannot have the same name (within the same name space), even if they are of different types. This point will be explained in the next section.
- A “pass-through” gate can be defined without a connective but with a single argument event for its formula.
fault-tree-definition =
element define-fault-tree {
name,
label?,
attributes?,
(substitution-definition
| CCF-group-definition
| event-definition
| component-definition
| parameter-definition
| include-directive)*
}
component-definition =
element define-component {
name,
role?,
label?,
attributes?,
(substitution-definition
| CCF-group-definition
| event-definition
| component-definition
| parameter-definition
| include-directive)*
}
role = attribute role { "private" | "public" }
model-data =
element model-data {
(house-event-definition
| basic-event-definition
| parameter-definition
| include-directive)*
}
event-definition =
gate-definition | house-event-definition | basic-event-definition
gate-definition =
element define-gate { name, role?, label?, attributes?, formula }
house-event-definition =
element define-house-event {
name, role?, label?, attributes?, Boolean-constant?
}
basic-event-definition =
element define-basic-event {
name, role?, label?, attributes?, expression?
}
formula =
event
| Boolean-constant
| element and { formula+ }
| element or { formula+ }
| element not { formula }
| element xor { formula+ }
| element iff { formula+ }
| element nand { formula+ }
| element nor { formula+ }
| element atleast {
attribute min { xsd:positiveInteger },
formula+
}
| element cardinality {
attribute min { xsd:nonNegativeInteger },
attribute max { xsd:nonNegativeInteger },
formula+
}
| element imply { formula, formula }
event =
element event {
reference,
attribute type { event-type }?
}
| gate
| house-event
| basic-event
event-type = "gate" | "basic-event" | "house-event"
gate = element gate { reference }
house-event = element house-event { reference }
basic-event = element basic-event { reference }
Boolean-constant =
element constant {
attribute value { Boolean-value }
}
Boolean-value = "true" | "false"
The attribute “role” is used to declare whether an element is public or private, i.e., whether it can be referred by its name everywhere in the model or only within its inner most container. This point will be further explained in the next section. This attribute is optional, for by default, all elements are public.
The fault tree pictured above is described in :numref:xml_fault_tree. In this representation, the house event “h1” has by default the value “true”. Basic events are not declared, for it is not necessary, so no probability distributions are associated with basic events.
¶ Extra Logical Constructs and Recommendations
¶ Model-Data and Components
The Model Exchange Format provides a number of extra-logical constructs to document and structure models. Labels and attributes are introduced in :numref:definitions_labels_attributes. They can be associated with a declared element in order to document this element. Fault trees are a first mean to structure models. A fault tree groups any number of declarations of gates, house events, basic event, and parameters.
It is sometimes convenient to group definitions of house events, basic events, and parameters outside fault trees. The Model Exchange Format provides the container “model-data” to do so.
The Model Exchange Format makes it possible to group further declarations through the notion of component. A component is just a container for declarations of events and parameters. It has a name and may contain other components. The use of components is illustrated by the following example.
The figure below shows a fault tree FT with three components A, B, and C. The component B is nested into the component A. The XML representation for this Fault Tree is given in :numref:xml_fault_tree_with_components. With a little anticipation, we declared basic events. Note that components and fault trees may also contain definitions of parameters. Note also that the basic event BE1, which is declared in the component A, is used outside of this component (namely in the sibling component C).
A Fault Tree with Three Components
¶ Solving Name Conflicts: Public versus Private Elements
By default, all elements of a model are public: they are visible everywhere in the model and they can be referred by their name. For instance, the basic event “BE1” of the fault tree pictured in :numref:xml_fault_tree_with_components can be just referred as “BE1”. This principle is fairly simple. It may, however, cause some problem for large models, developed by several persons: it is hard to prevent the same name to be used twice, especially for what concerns gates (some software allow actually this possibility).
The Model Exchange Format makes it possible to declare elements of fault trees either as public or as private (to their inner most container). Unless declared otherwise, an element is public if its innermost container is public and private otherwise. For instance, if the component “A” of the fault tree pictured in :numref:xml_fault_tree_with_components is declared as private, then the component “B” (and its two basic events “BE2” and “BE3”), the gates “G1” and “G2”, and the basic event “BE1” are private by default. There is no difference between public and private elements except that two private elements of two different containers may have the same name, while public elements must be uniquely defined.
There is actually three ways to refer an element:
- An element can be referred by its name. This works either if the element is public or if it is referred inside the container (fault tree or component) in which it is declared. For instance, if the basic event “BE1” is public, it can be referred as “BE1” anywhere in the model. If it is private, it can be referred as “BE1” only inside the component “A”.
- An element can be referred by its full path (of containers), whether it is public or private. The names of containers should be separated with dots. For instance, the basic event “BE2” can be referred as “FT.A.B.BE2” anywhere in the model.
- Finally, an element can be referred by its local path, whether it is public or private. For instance, if the gate “G1” can be referred as “FT.A.G1” outside of the fault tree “FT”, as “A.G1” inside the declaration of “FT”, and finally as “G1” inside the declaration of the component “A”. If the basic event BE1 is private (for a reason or another), it should be referred either as “FT.A.BE1” inside the component “C”. In this case, the definition of the gate “G3” is as follows.
<define-gate name="G3">
<and>
<basic-event name="FT.A.BE1"/>
<basic-event name="BE4"/>
</and>
</define-gate>
The important point here is that it is possible to name two private elements of two different containers with the same identifier. For instance, if components “B” and “C” are private, it is possible to rename the basic-event “BE4” as “BE2”. Outside these two components, the two basic events “B2” must be referred using their (local or global) paths.
¶ Inherited attributes
Attributes associated with a container (fault tree, event tree or component) are automatically inherited by all the elements declared in the container. It is indeed possible to change the value of the attribute at element level.
¶ Recommendations
¶ Layered Models
In PSA models, fault trees are in general layered, i.e., arguments of connectives (and, or, etc.) are always either variables or negations of variables. Although there is no reason to force such a condition, it is recommended to obey it for the sake of clarity.
¶ Use Portable Identifiers
In the XML description of fault trees, we intentionally did not define identifiers. In many fault tree tools, identifiers can be any string. It is, however, strongly recommended for portability issues to use non problematic identifiers, like those of programming languages, and to add a description of elements as a comment. This means not using lexical entities, such as spaces, tabulations, “.” or “/”, in names of elements, as well as realizing that some old tools cannot differentiate between capital and small letters.
The following is a general, recommended format that is likely to produce portable identifiers.
- Consistent with XML NCName datatype (XML Schema Part 2: Datatypes Second Edition, Derived datatypes, Section 3.3.7)
- The first character must be alphabetic.
- May contain alphanumeric characters and special characters like _, -.
- No whitespace or other special characters like :, ,, /, etc.
- No double hyphens –
- No trailing hyphen
- No periods . (reserved for references)
References to constructs, such as gates, events, and parameters, may include names of fault trees or components to access public or private members. This feature requires a period . between names; thus references may follow the pattern fault_tree.component.event.
In addition to the identifier format, the following is a set of recommendations for conforming tools to maximize the input acceptability:
- Avoid restricting the word character set (e.g., ASCII-only, English-only)
- Support popular character encodings (e.g., UTF-8, UTF-16)
- Provide case-sensitive identifier processing (e.g., no capital-letters-only restrictions)
- Sanitize input leading and trailing whitespace characters (i.e., insensitive to noise)
¶ Role of Parameters, House Events, and Basic Events
Parameters, house events, and basic events should be always public, in order to facilitate their portability from one tool to another.