0:00
The identification of risk through component inspection can be
made more systematic by the use of Risk Trees.
Risk Trees organize failures,
causes, and consequences along causal links.
You can also create fault trees that cover
safety or you can make threat trees for security.
They are all very, very similar.
In any of these types of trees,
there are two types of nodes – failure and logical.
Logical nodes capture your causal links.
Failure nodes represent independent failure events or
conditions and can be decomposed into finer grained nodes.
And/or links work through logical nodes.
The "and" nodes are ones that show that all child nodes
must occur for the parent node in order to occur as a consequence.
In "or" nodes only one child node needs to occur for the failure node to occur.
As an example, here's a portion of a fault tree for a train door control system.
For the risk that the door opens while the train is moving that could happen
because the train is moving and all these other parts of the tree occur.
The door actuator could fail.
The speedometer could fail or a passenger could force the door to open.
In this diagram, these are listed as leaf nodes and do not need to be decomposed.
We don't need them anymore because we are mainly working on the software controller.
We assume that those leaf nodes are things basically out of our control.
If the software controller fails,
it could be due to a number of reasons that can all be clarified.
In this small example, we're going to keep it really really simple.
We have that the reasons there are for a wrong requirement,
a wrong assumption, a wrong specification, or wrong implementation.
Obviously, each of these could be decomposed further.
But, the next question is how we can identify the failure nodes themselves.
In order to identify failure nodes,
start by considering existing risk checklists like those
provided by NIST and the Software Engineering Institute.
Also, look for guide words that can help you to
capture patterns of failure in the risk tree.
Very simple patterns that can be looked for are words associated with no,
more, less, before, or after.
Combinations of these patterns are often more dangerous.
Leading to difficult requirements and also ambiguous requirements.
Problems frequently are due to combinations of basic failure events and conditions.
Once a Risk Tree is built,
you can enumerate all minimal and combinations of leaf events or conditions.
Each of which is sufficient for causing a root failure node.
Here on the left,
we see an abbreviated version of the fault tree that we just discussed.
On the right side, we have a Cut-Set Tree.
A Cut-Set Tree represents all combinations of
leaf events and conditions that are sufficient for causing the root failure node.
This is just a translation.
It is derived from top down from the original tree,
"or" nodes get expanded and "and" nodes get
expanded into single aggregated nodes composed of the children.
Leaf nodes of the Cuts-Set Tree are conditions that will cause root failure.
Take a minute to analyze this Cut-Set Tree.
L1 is the root risk.
For that risk to occur,
the train has to be moving plus something from L2.
This means that the train must be moving and the door actuator
malfunctions or the train is moving and the speedometer
fails or the train is moving and a passenger forces the door
open or we could have that the train is moving and something from L3 occurs.
Where if you recall L3 is that there's a wrong requirement,
a wrong assumption, a wrong specification or a wrong implementation.
From this tree, we can write a cut set of all leaf nodes
representing all points of failure and you can
see this in the bottom statement on the slide.
Kristen Walcott-JusticeAssistant Professor
