Reliability HotWire: eMagazine for the Reliability Professional
Reliability HotWire

Issue 48, February 2005

Hot Topics

Using BlockSim to Analyze Systems That Do Not Operate 24 Hours per Day

In many production lines, the manufacturing operation is not a 24-hour operation, but a partial-day operation (e.g. 8 hours or 16 hours per day) in which maintenance crews are required to continue their work even beyond the end of a shift. In this article, we will discuss using BlockSim to model and simulate such systems. The key for modeling this type of scenario is to incorporate a time block that handles the "clock" of the system and makes the operation stop for a certain duration (or percentage) of the time, while allowing the crews to continue their work.

Example

Let us consider the following simple repairable production line (corrective/preventive maintenance and inspections are applied).

 Operation line example

Figure 1: Operation line example

When simulating this RBD, all the machines are assumed to be running around the clock. In case of a non-continuous operation, one can specify a simulation end time that reflects this fact. For example, if an 8 hours/day shift is the actual operating time, then in order to model a year's worth of operation, the simulation end time would be 365 days x 8 hours/day= 2920 hours. This approach suggests that the end of a shift would interrupt the tasks of the crews and that the crews would need to continue the unfinished tasks the next day (or at the beginning of the next shift). In other words, under this model all downtime is accumulated during the operating hours, whereas in the actual application only a portion of this downtime will occur during the operating hours. In many situations, a crew would be required to continue the task at hand even beyond the end of the shift. This requires another approach to modeling the system.  

Solution

First, we need a way to stop all operations for 16 hours/day and to stop the machines from aging during those non-working hours. A simple way to achieve this task is to create a block that would bring the system down for 16 hours/day and to put it in series with the whole system, as illustrated in Figure 2.

 Incorporating shifts into the system operation

Figure 2: Incorporating shifts into the system operation

The Shift block reliability properties are displayed in Figure 3. The chosen distribution is Normal with mean = 20,000 (it should be much larger than the simulation end time). The purpose for this large value is to avoid having the block fail during the system's life time. Note that the Shift block should "operate" even if the system is down; this is specified by checking "Item operates even if system is down" on the General tab of the Block Properties window. Otherwise, when a machine is down, the days end of operation would be shifted by the duration the machine was down for. On the other hand, the other blocks should not accumulate any age during the non-working hours of the day; this means that "Item operates even if system is down" should be unchecked for the other blocks in the system (unless there are some blocks that also operate during off-hours).

  Shift block  properties

 

Figure 3: Shift's failure distribution properties

 The Shift's "corrective" action is irrelevant, because the Shift block will not go down during the specified simulation end time, but it needs to be specified in order to allow access to the inspection property of the block; to accomplish this, we enter a 0 hour fixed duration for the corrective action time. No preventive maintenance is specified, since it does not apply in this case. An inspection fixed duration of 16 hours is specified (see Figure 4) to allow the system to cease operation for 16 hours/day. Also note that the Inspection brings system down option should be checked in order to make sure that the entire system shuts down during the off-hours. In order to specify that the system is up for 8 hours/day (meaning that the Shift does not go down until 8 hours have elapsed since the beginning of the shift), an inspection policy with the properties defined in Figure 5 needs to be associated with the Shift block.



Figure 4: Shift's inspection properties



Figure 5: Shift's inspection policy

Note that the other system components' properties are omitted in this article, since they are not the main focus in this discussion. Figure 6 shows the results of 1000 simulations of 1 year (8760 hours) of operation.

 

Figure 6: Simulation Results

 

Notice that the Mean Availability reported is not the correct number, since it includes all the off-hours downtime. In this setup, the off-hours downtime is inspection downtime. This means that the actual Mean Availability is the one that does not include the inspection downtime. This is the "Mean Availability (w/o PM & inspection)" presented in row 5, equal to 98.17%.

Some adjustments are necessary in order to interpret the results appropriately. Because we know that the system is down for 16 hours/day due to the off-hours, not due to failures, we should add back the 16 hours/day to our results. The simulation results state that the uptime was 2819.96 hours during the year. If we add back 16 hours/day x 365 days = 5840 hours, then our actual uptime is 8659.96 hours or 98.85% uptime. As a final remark, note that other modifications for interpreting the simulation results could be needed depending on the particularities of the scenario.

 

ReliaSoft Corporation

Copyright 2005 ReliaSoft Corporation, ALL RIGHTS RESERVED