Using Maintenance Policies
In BlockSim 6, there are two methods for analyzing a reliability block diagram: analytically and via simulation. The analytical method is advantageous because you can obtain a closed-form reliability equation and duplicate the results. However, the analytical solution does not take into account any maintenance policies that you may have defined for the blocks in the diagram. One of the most important benefits of simulation is the ability to define how and when the actions are performed. In particular, the actions of interest are the part repairs and replacements. This can be accomplished in BlockSim 6 by defining maintenance policies. There are three different types of maintenance policies that can be defined for actions in BlockSim 6: corrective maintenance, preventive maintenance and inspection.
Corrective Maintenance Policies
A corrective maintenance policy defines when a corrective maintenance (CM) action is performed. Figure 1 shows a corrective maintenance policy that has been assigned to a block.
Figure 1: Corrective maintenance policy
Corrective actions can be performed either immediately upon failure of the item or upon finding that the item has failed (for "hidden" failures that are not detected until an inspection). BlockSim allows the selection of either category. If "Upon Failure" is selected, the CM action is initiated immediately upon failure. If a policy has not been set for a block, then this is the default option. If the "Upon Inspection" option is selected, then the CM action will only be initiated after an inspection is done on the failed component. How and when the inspections are performed is defined by the block's inspection properties and also by the inspection policy. This has the effect of defining a dependency between the corrective maintenance policy and the inspection policy, as shown in Figure 2.
Figure 2: Cascading dependencies present when CM "Upon Inspection" has been specified
Figure 2 shows the options available in an inspection policy within BlockSim. Inspections can be performed upon a fixed time interval. This is either based on the item's age (item clock) or the system's age (system clock). Furthermore, inspections can also be set to occur if the system goes down or if another group item goes down. Within BlockSim, items are considered to be in the same group if they have the same non-zero "Item Group #." Note that the default value for this is 0. Zero is a reserved number and it means that the item does not belong to any group. Inspections do not bring the item down by default.
Preventive Maintenance Policies
Figure 3 shows the options available in a preventive maintenance (PM) policy within BlockSim. Much like inspections, PMs can be performed upon a fixed time interval. This is either based on the item's age (item clock) or the system's age (system clock). Furthermore, PM actions can also be set to occur if the system goes down or if another group item goes down. Because PM actions always bring the item down, one can also specify whether preventive maintenance will be performed if the action brings the system down.
Figure 3: Preventive maintenance policy options
Item and System Ages
It is important to keep in mind that the system and each component of the system maintains a separate clock within the simulation. Figure 4 illustrates system and item clocks. The system clock is the simulation elapsed time while the item clock is the age of the item since last renewal. If the system clock is used, the inspection will be performed every X time units. Whereas, if the item clock is used, the inspection will be performed every time the component reaches that age. As an example, if the inspection is set to be performed at a system age of 100, then an inspection will be performed at 100, 200, 300 and so forth. If the inspection is set based on an item's age of 100, then the inspection will be performed when the item reaches an age of 100.
Figure 4: The system and each block maintain different clocks during each simulation
Rules for PMs and Inspections
All the options available on the Maintenance tab of the Block Properties window and the associated policies were designed to maximize the modeling flexibility within BlockSim. However, maximizing the modeling flexibility introduces issues that the user needs to be aware of and requires the user to carefully make selections that do not contradict one another. One obvious case would be to define a PM action on a component in series (which will always bring the system down) and then assign a PM policy to the block that has the "Do not perform maintenance if the action brings the system down" option set. With these settings, no PMs will ever be performed on the component during the BlockSim simulation. The following sections summarize some issues and special cases for the user to consider when defining maintenance properties and policies in BlockSim.
To illustrate the use of maintenance policies in BlockSim, consider the following system.
Figure 5: Example of system utilizing maintenance policies
The properties of each block are defined in the following table:
The properties of each crew are defined as follows:
The spare part pool are also defined.
The corrective and inspection settings for blocks A and D are shown in Figure 6.
Figure 6: Corrective and Inspection policies for blocks A and D
Blocks A and D:
The preventive maintenance policies for blocks A and D are shown in Figure 7.
Figure 7: Corrective and Inspection policies for blocks A and D
The item and system behavior from 0 to 300 hours is shown in Figure 8.
Figure 8: Up/down event sequence for the system and the blocks
The simulation results are shown next in Figure 9.
Figure 9: Simulation results
System Downing Events
The details for blocks A, B, C, D and F are shown in Figure 10.
Figure 10: Block details
First note that there are four downing events on block A: initial failure, inspection and CM, plus the last failure at 298. All others have just one. Also, block A had a total downtime of 41 + 2, giving it a mean availability of 0.8567. The first time-to-failure for block A occurred at 100 while the second occurred after 298 - 141 = 157 hours of operation, yielding an average time between failures (MTBF) of 257/2 = 128.5 (note that this is the same as uptime/failures). Block D never failed so its MTBF cannot be determined. Furthermore, MTBDE for each item is determined by dividing the block's uptime by the number of events. The RS FCI and RS DECI metrics are obtained by looking at the SD Failures and SD Events of the item and the number of system failures and events. Specifically, the only items that caused system failure are blocks A and F; A at 100 and 298 and F at 163. It is important to note that even though one could argue that block F alone did not cause the failure (B and C were also failed), the downing was attributed to F because the system reached a failed state only when block F failed.
On the number of inspections, which were scheduled every 30 tu, nine occurred for block A [30, 60, 90, 120, 150, 180, 210, 240, 270] and eight for block D. Block D did not get inspected at 150 because block D was undergoing a PM action at that time.
Figure 11 shows the crew results.
Figure 11: Crew results
Crew A received a total of six calls and accepted three. Specifically,
The total wait time is the time that blocks had to wait for the maintenance crew. Block F is the only component that waited, waiting 38 tu for crew A. Also, the costs for crew A were 1 per unit time and 10 per incident, thus the total costs were 30 + 100. The costs for crew B were 2 per unit time and 20 per incident, thus the total costs were 40 + 156.
Figure 12 shows the spare part pool results. The pool started with a stock level of 1 and ended up with 2. Specifically:
Overall, five parts were dispensed. Blocks had to wait a total of 126 tu to receive parts (B : 181 - 161 = 20, C : 181 - 162 = 19, D : 150 - 121 = 29 and F : 221 - 163 = 58).
Figure 12: Pool details
To illustrate some special cases that one needs to be aware of, consider the following diagram.
In this diagram, blocks A and D have the same properties as before, with the exception that the inspection duration is now set to zero. Furthermore, recall the rule that only one event is executed in the case of simultaneous events. In this case and when block A fails, the inspection on block A at 120 will find the failure of A, which will then trigger a PM event on block D at the same instant that D also gets an inspection. This causes two simultaneous events on block D. This will result in the cancellation of the PM event on block D. The reason for the cancellation is to avoid the recursive situation where the PM on D would trigger a PM on A, which is undergoing CM, which would trigger a PM on D and so forth. Different options can be used to avoid this. One is to assign a non-zero inspection duration. In this case, the PM on block D would get triggered after the inspection on block A, as seen in the prior example.
Copyright 2003 ReliaSoft Corporation, ALL RIGHTS RESERVED