Back to top

Example - Adding failure data


Next, we need to add failure data to the architecture model. This needs to be done for each component and, where appropriate, each state.

Fuel Tanks

Fuel tank

The tanks are identical and have only one failure mode:

Component Failure Failure Rate Repair Rate
leak 1e-5 5e-4


The tanks have a single output port (out) with a single output deviation, omission (O):

Failure Class Port Cause
Omission out this:leak

Here we specify the output deviation (O@out) to be caused by the “leak” failure mode defined earlier. In this way, we have told Dymodia that an omission of output from this port will be caused by the given failure mode. More complex logic is also possible, as will be seen later.

Since the failure behaviour of the tanks is the same irrespective of which state the system is in, we define the above for the “Default” state, which means it applies in all states.



Left and Right Valves

Normal valve

The left and right valves are identical. Each has two possible failure modes: “jammed”, where the valve is jammed in the closed position, and “blocked”, where flow has been obstructed by some kind of blockage.

Component Failure Failure Rate Repair Rate
jammed 1e-5 5e-4
blocked 1e-5 5e-4

We add this information as usual using the Component Failure Data dialogue:

Adding basic events

As with the fuel tanks, the valves have a single output port. For now, we can define a single output deviation, omission (O):

Failure Class Port Cause
Omission out this:blocked OR this:jammed OR O@this[in]

Note how the cause this time is a logical combination of three possibilities: the “jammed” failure mode, the “blocked” failure mode, or an omission of input to the valve (from the fuel tank); any one is sufficient to cause an omission of output.

Again, the failure behaviour here is the same irrespective of which state the system is in, so we only need to define it once, for all states.



Centre valve

Centre valve

The centre valve is similar to the other valves in its internal failure modes.

Component Failure Failure Rate Repair Rate
jammed 1e-5 5e-4
blocked 1e-5 5e-4

The main difference here is in the output deviations. During normal operation – in the “UseBothTanks” state – this component is dormant; it neither takes input nor provides output, because the valve is closed. Its failure behaviour is only relevant in one of the two degraded modes. As such, we must specify this behaviour directly for each state by selecting it at the top:

Adding output deviations for a state

State Failure Class Port Cause
UseLeftTank Omission right_out this:blocked OR this:jammed OR O@this[left_in]
UseRightTank Omission left_out this:blocked OR this:jammed OR O@this[right_in]

Note how the failure behaviour here depends on the current state; in other words, it is dynamic behaviour. When using the left tank, only output deviations at right_out are possible; when using the right tank, only output deviations at left_out are possible (with appropriate causes in each case).



Left and Right Pumps

Pump

The left and right pumps are identical. Each has only a single generic failure mode:

Component Failure Failure Rate Repair Rate
failed 5e-4 5e-4

However, the output deviations are again dependent on state:

State Failure Class Port Cause
UseBothTanks Omission out this:failed OR FuelSystem:::PowerCut OR O@this[in1]
UseLeftTank Omission out this:failed OR FuelSystem:::PowerCut OR O@this[in1]
UseRightTanks Omission out this:failed OR FuelSystem:::PowerCut OR O@this[in2]

One extra addition here is a common cause failure: “PowerCut”. This is defined at the system architecture level and can then be referenced from any component:

Adding common cause failures



Engines

Engines

To keep things simple, we do not consider failure of the engines directly; instead we use them only as the “outputs” of the system:

Failure Class Port Cause
Omission out O@this[in]

In other words, omission of engine power is caused only by an omission of fuel to the engine.


Next: Linking models
Back to overview