Component Fault Trees (CFT) provide an extension to fault trees by introducing a component and instantiation concept. These additional modeling features allow fault trees to be better structured, encapsulating fault logic where required, and enabling reuse of fault trees consistently. CFT can be used seamlessly on top of the normal FTA capabilities that are decribed in Fault Tree Analysis (FTA). Note that this feature is available behind a beta flag for now and has not the same quality level than plain fault trees. Especially the computations and evaluation of cut sets is not yet fully qualified. You can enable CFT via the project settings (i.e. FTA/RBD | FTA → Enable CFT).
CFTs are embedded into the SysML language in Ansys medini analyze and follow model-based principles. The basic idea is to define fault logic directly inside of SysML parts and instantiate them for a system analysis in the context of a system fault tree. That means, every element in the SysML model can contain fault tree components, which define the fault behavior the component exposes under given conditions:
A fault tree component can define multiple failure output events that it exposes to its environment (black triangles). Similar to failure modes, each such output event can describe a faulty behavior or simply events that are exposed by the component.
Each failure output event is defined by its own fault tree inside of the component. Thereby, the fault logic defines how internal faults and potentially external faults in combination lead to failures of the component.
Input failures such as commanded failures or external faults can be linked to a component by means of failure input events (gray triangles). These behave like undeveloped events in the first place for which detailed root causes are unknown, but which contribute to the fault behavior of the component.
Hence, a fault tree component declare a clear failure interface of a part via the input and output failure events and encapsulate the internal fault propagation logic. For a system analysis, the fault tree component can be instantiated and connected according to its context. This instantiation is creating a complex event which is essentially a virtual copy of the fault tree logic defined by the component.
Despite the original CFT definition that you might know from literature, the graphical editors do currently not yet support directed graph connections. That means that if an input failure or intermediate event needs to be referenced multiple times, you still need to use normal transfer gates as in normal fault trees.
Fault tree components can be created inside SysML parts and part definitions (blocks). Each part/part def can have multiple fault tree components to model e.g. different usage scenarios or variants of the system.
To create a component follow these steps:
First, enable CFT support at your project by opening the Project Settings and go to the page FTA/RBD → FTA. Check the option "Enable support for CFT modeling". Select "Apply and Close" and close the project settings.
Select a SysML part or part definition in the Model Browser. Open the context menu (right click) and select New → Fault Tree Component...
Provide a name in the upcoming dialog and confirm with OK.
By default, the graphical fault tree component editor opens and shows you an empty component definition (component rectangle).
Use the palette to create failure output events (black triangles), failure input events (gray triangles), or arbitrary fault tree logic inside the component.
Note that you can use drag and drop of failure modes, ports and their failure modes, or contained elements to derive events inside the component. The event creation behavior is the same as for normal fault trees (see Creation of Events from Models) with the following differences:
Events can be created only for internal parts/failures of internal parts. That means the fault tree component is the outermost scope for elements to make the fault logic self-contained.[10]
Failure modes of the containing part/part definition can be dragged either as failure output event, failure input events, or normal events into the component diagram. Note that you can drop them on the top of the rectangle to create an output event (black triangle), on the lower boundary of the rectangle to create an input event (gray triangle), or into the rectangle area to create a normal event.
If nested components have in turn a fault tree component defined, you can instantiate them as a complex event instead of a basic event. This will effectively create a cascading/nested fault tree component (see Usage of Fault Tree Components)
If you have defined fault tree components, you can instantiate them in your analysis fault tree. The instantiation is called a complex event and logically inserts the component fault logic into your application tree by virtually replicating the logic. Basically, two use cases can be distinguished:
Instantiation of component fault trees directly in your system analysis fault tree. Given a set of system design elements that have fault tree components, you can drag and drop their fault tree components and connect them with arbitrary other fault tree logic, starting at the top event.
If you define a fault tree component, you can instantiate nested fault tree components from contained elements. This will create a hierarchy of nested/cascading complex events. Later, when using the top-level component in an analysis as described above, the complete hierarchy will be virtually replicated recursively into this context fault tree.
In order to instantiate a fault tree component, do the following:
Drag and drop a fault tree component from the Model Browser into your fault tree diagram.
If you dragged a component from a SysML part definition (block), a dialog will ask you for which part the instantiation is actually created. This information will be available during cut set analysis to refer to the correct usage context.
As result, a complex event will be created with exactly the same output events (black triangles) and input events (gray triangles). These are referring to their definitions in the fault tree component.
The complex event ID will automatically be assigned by an auto-counter. This identifier will be used during the evaluation to prefix all events inside the fault tree component. Feel free to provide a descriptive ID that helps you navigating through the analysis.
You can optionally overwrite the name for the instantiation to your convenience. The name is only used as descriptive information to readers of the fault tree.
Connect your fault tree gates to the output events as desired. If certain output events are of no importance, you can delete them from the diagram to keep the analysis tidy.
Continue to connect the input events of the complex event to other parts of your fault tree or in turn to other complex event's output. If an input event is not connected, it will be treated like a basic event. In this case the probability settings will be used as described in Handling of Probabilities in CFTs.
As alternative, you can drag a SysML part or part definition (block) into the fault tree. If the element has a fault tree component defined, a complex event will be created in exactly the same way as described above. Note that if multiple fault tree components have been defined, a dialog will ask for which one to instantiate.
Important: If the component fault tree interface is changed, the complex events referring to it need to be reconciled with the changed definition. For example, if you add an output event, this will not be automatically appear at the complex event. For this purpose, you can select "Reconcile Event Interfaces" on the fault tree component to align all complex events with it. Vice-versa, you can perform a selective reconciliation for the complex event itself by triggering the same action there.
The probabilistic assessment of CFTs is fully supported, but there a couple points to be considered when working with component definitions and their instantiations as complex events:
All basic events inside fault tree components can be quantified as normal (see Event Properties and Probability Models). This includes derivation of probabilities from failure rates of SysML elements and their failure modes, "1-DC" from safety mechanisms, and so on.
Input events of a fault tree component (gray triangles) can be quantified in the same way. Note that this quantification can provide useful default values, but their real probability depends on where the component is instantiated and how the inputs are connected.
Input events at complex events inherit the settings from (2), but they can redefine the probability (if not connected). That means that the input event from the component provides a default probability for each complex event, but this value can be overwritten at the complex event.
Recall for cases (2) and (3) above that only if the input event is not connected, they will be treated as if they were basic events. During system analysis, the input event is normally becoming an intermediate event and hence its probability will be computed based on the connected input events and gates, mission time, etc.
In order to update the probability/frequency labels of a component definition, simply select a CFT definition and select Calculate Probability.... This will compute all probabilities and update the labels consistently. For more details on fault tree evaluation see Evaluation of CFTs.
The evaluation of CFTs basically works in the same way as for plain fault trees. Semantically, all complex events are replaced by their component fault tree definitions recursively. However, the navigation of cut set results as well as the probability updates of labels on diagrams are slightely different for CFTs as described in this section.
Computation of cut sets and probabilistic quantities can be accomplished via the context menu:
Select the top or intermediate event of interest and choose Evaluate fault tree... from the context menu
The option dialog opens to specify the parameters for the computation such as mission time, whether to compute unreliability and importancies and so on (see Evaluation Results of a Fault Tree for more details).
After confirmation the CFT is evaluated by recursively considering component fault tree definitions for all complex events.
As result, the events in cut sets coming from a fault tree component have a path as ID. Each event inside a complex event has a concatenated path ID in the order the complex events have been instantiated. For example, if a complex event has ID C1 than all events inside the fault tree component have IDs of the format C1/<event ID>. If in turn the component uses a complex event with, say ID CN2, the events inside this component would be referred to as C1/CN2/<event ID> and so on.
The cut set list provides a convenient navigation back to the original event by selecting Highlight Cut Set Events from the context menu. This will reveal the CFT definition diagram with the event as well as selecting all complex events in the path in the Model Browser.[11]
The probability labels of CFTs can also be updated similarly to normal fault trees. However, there is a difference in that component fault tree definitions must be separately computed whenever needed. This is due to the fact that a component definiton can be instantiated multiple time and hence have different probabilities for each context (cp. Handling of Probabilities in CFTs).
For updating the probabilty labels on a fault tree that uses component fault tree definitions via complex events you can do the following:
Select the top event to start the update via the context menu using Calculate Probability....
The normal FTA dialog for probabilities opens with the option to specify the mode of computation and the mission time. Make sure to check Calculate probability of intermediate and primary events to update all intermediate and complex events starting at the selected event of step 1 (see Probabilistic Fault Tree Evaluation for more details).
After confirming with OK, all subtree events will be updated including all complex events. That means the failure output and input ports are updated showing the correct probabilities/frequencies according to the connected inputs.
Note that this update will not change the probability labels of the CFT definitions. In order to update the probabilities there, simply select a CFT definition and select Calculate Probability....
Sometimes it is useful to convert a CFT into a classical fault tree, for example when exporting to third party tools, conducting assessments in case CFT are not recognized by authorities. This semantically fully equivalent fault tree might also be useful to understand the semantics of CFT, i.e. how complex events expands during normal evaluation. Converting a CFT essentially means to replace all component instantiations (complex events) with their CFT definitions, recursively, so that only standard FTA gates and events are left.
This conversion is supported by a seamless generation into a separate plain fault tree as follows (the original CFT is not changed):
Select the top event of interest and choose Derive → FTA from CFT from the context menu
A new fault tree will be generated named "FTA Model" in the same package of the fault tree starting with the event selected in step 1.
Note that the derived FTA model is created by replacing recursively all complex events by their component fault tree definitions.
Each event coming from a fault tree component has a path as ID concatenating the complex event IDs in the way they have been instantiated to reach the event. For example, if a complex event has ID C1 than all events inside the fault tree component have IDs of the format C1/<event ID>. If in turn the component uses a complex event with, say ID CN2, the events inside this component would be referred to as C1/CN2/<event ID> and so on. Note that the cut sets will contain the concatenated path IDs of the events.
You can visualize the tree as follows:
Create a top level diagram inside the derived FTA model
Drag the top event onto the diagram
Select Restore Subtree... from the context menu to expand the fault tree graphically up to the level of interest
Repeat this creation process until everything you want to visualize is on a diagram
Note that the generated fault tree is not connected by any means to the original tree. However, all events representing SysML elements do connect to the same underlying model elements. For example, if a failure rate of a part or failure mode is linked to a FTA event, a change to the failure rate will consistently change in the original CFT and the generated fault tree.