Advanced RBD Modeling Using State Change Triggers
A state change trigger is a powerful new modeling option in
BlockSim 8 that can be used to model scenarios of cold standby with complex configurations, or scenarios where a failure of a component
will result in the deactivation of other components
in the same system. In this article, we will illustrate the use of state change triggers through a reliability modeling example of a mining plant.
In BlockSim 8, state change triggers are available for standard blocks and contained load sharing blocks in simulation RBDs, and for events and dependent load sharing events in simulation fault trees.
The state change triggers are activated via the Block
Properties window of the selected block, as shown in the
Block Properties Window
When state change triggers are enabled, the following options become available.
- Initial State
- ON. When simulation starts, the block will be active.
- OFF. When simulation starts, the block will remain inactive until it is activated by a state change trigger.
- State upon repair
- Always ON. After a block is repaired it will always become active.
- Always OFF. After a block is repaired it will always remain inactive.
- Default ON unless SCT overridden. After a block is repaired it will become active unless a request is made by a state change trigger to deactivate the block while the block is down for repair.
- Default OFF unless SCT overridden. After a block is repaired it will remain inactive unless a request is made by a state change trigger to activate the block while the block is down for repair.
- Add a state change trigger. When an item from an associated maintenance group(s) goes down or is restored, then the block will be activated or deactivated. A block can contain multiple state change triggers.
Consider a mining plant comprising two production lines that include conveyors, crushers, stackers, reclaimers and classification equipment.
The following figure shows the reliability block diagram
(RBD) of the plant (for simplicity, only a part of the plant is modeled here).
RBD of a Mining Plant
In a real operation, when any of the two lines goes down due to a failure of one piece of equipment, all equipment in that line
will stop operating.
However, when performing reliability and throughput
analysis with a traditional RBD (without the use of
state change triggers), the assumption is that when a
block in one line fails, and given that the system is
still operational, all other blocks in that line
continue to accumulate age and produce throughput. This
violates the real-life operation assumptions. This
problem can be addressed by using state
With a state change trigger, a failure of any block
within a maintenance group leads to the state change;
therefore, the first step is to create a maintenance group that
contains the appropriate blocks.
The following figure shows the maintenance group for the first
production line. The group is named Line 1 and
it contains the blocks called Conveyor 1, Crusher 1, Stacker 1, Reclaimer
1 and Classification 1.
Maintenance Group Manager
A similar maintenance group, named Line 2, is created for the second
production line. Note that the blocks called Conveyor 3, Conveyor 4 and Conveyor 5 were not added
to the Line 1 maintenance group. The same applies for Conveyor 6, Conveyor 7 and Conveyor 8
for the Line 2 maintenance group. The reason
is that those conveyor blocks are in a parallel configuration and, therefore, a failure of only one block does not result in
a line going down. For example, in order for the first
production line to go down, either Conveyor 3 and
Conveyor 5 or Conveyor 4 and Conveyor 5 need to fail
those conveyer blocks need to be treated separately.
One way to model the scenario is to create a
subdiagram for the Conveyor 3, 4 and 5 blocks, and another subdiagram for
the Conveyor 6, 7 and 8 blocks. Each conveyor block
in the subdiagrams is then mirrored to its corresponding
block in the mining plant diagram
so that it will have no effect on the reliability and throughput
results of the analysis.
The following figure shows the diagram that contains the
Conveyor 3, Conveyor 4 and Conveyor 5 blocks. The gray
square in the block indicates that the block is
mirrored. The Mirror Group Manager
in the figure provides an example of how Conveyor 3 in
the subdiagram is mirrored to its corresponding block in the
mining plant diagram.
of Parallel Connected Conveyors and the Mirror Group Manager
Showing the Conveyor 3 Block
The next step is to create a maintenance group for each subdiagram.
This will allow you to create a state change that will be triggered only when the diagram as a whole goes down (in this case, only when Conveyor 3 and Conveyor 5 fail together or Conveyor 4 and Conveyor 5 fail together).
The following figure shows the Block Properties window
of the Conveyor 3-4-5 subdiagram. This
subdiagram is part of the maintenance group named MG
Block Properties Window of the Conveyor 3-4-5 Subdiagram
Now we add a state change trigger to the appropriate blocks in the
mining plant diagram.
The following figure shows the state change trigger for
State Change Trigger Window
In this case, the block will be deactivated if any block
in the maintenance group called Line 1 goes down or if any
blocks in the maintenance group called MG Conveyor 3-4-5 goes down. A second trigger is then added in order to activate the block when the line becomes operational again.
The following figure shows the Block Properties window of Conveyor 1, with the state change triggers highlighted.
Block Properties Window of Conveyor 1
The state change triggers are set the same way for the rest of the blocks
in the production lines.
The following figure shows the RBD that includes the state change triggers.
RBD of Mining Plant
That Includes State Change Triggers
The red circle denotes that the block belongs to a maintenance group,
while the blue diamond denotes that the block contains state change triggers. Also, note the addition of the two subdiagrams
called Conveyor 3-4-5 and Conveyor 6-7-8. These subdiagrams will not affect the system in terms of reliability or throughput, but are added just for the purpose of state change triggers as described above.
The following figure shows an Up/Down
plot for a scenario where production line 1 goes down.
Notice that all other equipment in the same production
line remain down (indicated by the dotted line) while
Crusher 1 is down for repair (indicated by the thick
In this article, we illustrated the use of state change triggers
by modeling a mining plant. State change triggers
allow you to model cases where the failure of one piece
of equipment will result in other equipment being shut down. A similar modeling approach
may also be used for various other applications,
such as in the case of complex cold standby configurations.