Add event tree analysis documentation

Issue #150

doc/description.rst

@@ -46,3 +46,4 @@ Analysis
 - :ref:`common_cause_failure`
 - :ref:`probability_analysis`
 - :ref:`uncertainty_analysis`
+- :ref:`event_tree_analysis`

doc/event_tree_analysis.rst

@@ -0,0 +1,33 @@
+.. _event_tree_analysis:
+
+###################
+Event Tree Analysis
+###################
+
+Event tree analysis [ETA]_ is an analysis of end sequences
+given an initiating event and progression of states over functional events.
+The analysis uses the gathered Boolean formula and expressions per sequence
+to supply arguments for other analysis kinds,
+such as fault-tree, probability, and uncertainty analyses.
+
+The Model Exchange Format [MEF]_ provides very flexible and powerful mechanisms
+to express event trees.
+The programming nature of event trees is achieved with a set of Instructions and Expressions
+that control the interpretation of paths leading to sequences.
+
+Event tree validation notes:
+
+    - The sequences defined in event trees are public (i.e., global).
+      In other words, two different event trees cannot define sequences with the same name,
+      but either event tree can reference each others' sequences.
+
+    - The order of functional events is deduced implicitly
+      from the declaration of the functional events in the event tree.
+      This order must be respected in event tree paths.
+
+    - Functional event states in forks can be arbitrary but unique (per fork).
+      In expressions evaluating a functional event state,
+      the state must be one of possible states declared in functional event forks.
+
+    - In general (fault-tree linking, event-tree linking),
+      there's no computationally cheap way to validate conditional independence of branches.

doc/input_file.rst

@@ -39,9 +39,9 @@ Steps in XML Input Validation
       which allows reuse of files with analysis constructs from other models.
 
 #. XML input file validation against the `RELAX NG`_ :ref:`schema`.
-#. The fault tree validation assumptions/requirements:
+#. The validation assumptions/requirements:
 
-    - Event names and references are case-sensitive.
+    - Construct names and references are case-sensitive.
     - Leading and trailing whitespace characters are trimmed.
     - Names and references should conform to the MEF recommendations.
     - Public names must be unique globally,
@@ -59,7 +59,7 @@ Steps in XML Input Validation
 
 #. Error messages (with a file name, line numbers, types of errors):
 
-    - Report a cyclic tree.
+    - Report a cyclic tree (gates or event tree branches).
     - Report a cyclic parameter with expressions.
     - Report missing element descriptions.
     - Report an error if an event or a construct is being redefined.
@@ -68,6 +68,8 @@ Steps in XML Input Validation
 
     - Orphan primary events.
     - Unused parameters.
+    - Unused initiating events or event groups. *Not Implemented*
+    - Unused functional events, branches, sequences. *Not Implemented*
 
 
 .. _schema:

doc/opsa_support.rst

@@ -53,6 +53,14 @@ to identify the supported and unsupported features.
 - Label
 - Attributes
 - Public and Private Roles
+- Event Tree Layer
+
+    * Initiating events
+    * Sequences
+    * Functional events
+    * Branches
+    * Instructions (collect-expression)
+
 - Fault Tree Layer
 
     * Components