Reliability HotWire: eMagazine for the Reliability Professional
Reliability HotWire

Issue 30, August 2003

Reliability Basics
Using Pools and Crews in System Analysis (Part II)

In July's issue of the HotWire, utilizing crews in system analysis was presented in the Using Pools and Crews in System Analysis (Part I) article. In this month's issue, we will continue with Part II of this discussion as it pertains to spare part pools. We will also examine how spare part pools and crews can be used together in system analysis.

ReliaSoft's BlockSim software also allows you to specify spare part pools (or depots). Spare part pools allow you to model and manage spare part inventory and study the effects associated with limited inventories. Each component can have a spare part pool associated with it. If a spare part pool has not been defined for a block, BlockSim's analysis assumes a default pool of infinite spare parts. To speed up the simulation, details on pool actions are not kept during the simulation if the default pool is used.

Pools allow you to define multiple aspects of the spare part process, including stock levels, logistic delays and restock options. Every time a part is repaired/replaced under a CM or PM action, a spare part is obtained from the pool. If a part is available in the pool, then it is used for the maintenance action. Spare part pools perform their actions based on the simulation clock time.

Spare Properties
Figure 1 displays the Spares page of the Spare Part Pool Properties window. A spare part pool is identified by a name. The general properties of the pool are its stock level (which must be greater than zero), cost properties and logistic delay time. If a part is available (in stock), the pool will dispense that part to the requesting block after the specified logistic time has elapsed. One needs to think of a pool as an independent entity. It accepts requests for parts from blocks and dispenses them to the requesting blocks after a given logistic time. Requests for spares are handled on a "first come, first served" basis. In other words, if two blocks request a part and only one part is in stock, the first block that made the request will receive the part. Blocks request parts from the pool immediately upon the initiation of a CM or PM event.

Spares page of Spare Part Pool Properties window

Figure 1: Spares page of the Spare Part Pool Properties window

Restocking the Pool
If the pool has a finite number of spares, restock actions may be incorporated. Specifically, a pool can restock itself either through a scheduled restock action or based on specified conditions. Figure 2 shows the Pool Restock Properties page of the Spare Part Pool Properties window. 

Figure 2: Pool Restock Properties page of the Spare Part Pool Properties window

Figure 2: Pool Restock Properties page of the Spare Part Pool Properties window

A scheduled restock action adds a set number of parts to the pool on a predefined scheduled part arrival time. For the settings in Figure 2, one spare part would be added to the pool every 100 time units, based on the system (simulation) time. In other words, for a simulation of 1000 time units (tu), a spare part would arrive at 100 tu, 200 tu, etc. The part is available to the pool immediately after the restock action and without any logistic delays.

In an on-condition restock, a restock action is initiated when the stock level reaches (or is below) a specified value. In Figure 2, five parts are ordered when the stock level reaches 0. Note that unlike the scheduled restock, parts added through on-condition restock become available after a specified logistic delay time. In other words, when performing a scheduled restock, the parts are pre-ordered and arrive when needed. Whereas, in the on-condition restock, the parts are ordered when the condition occurs and thus arrive after a specified time. For on-condition restocks, the condition is triggered if and only if the stock level drops to or below the specified stock level, regardless of how the spares arrived to the pool or were distributed by the pool. In addition, the restock trigger value must be less than the initial stock.

Lastly, a maximum capacity can be assigned to the pool. If the maximum capacity is reached, no more restock actions are performed. This maximum capacity must be equal to or greater than the initial stock. When this limit is reached, no more items are added to the pool. For example, if the pool has a maximum capacity of ten and a current stock level of eight and if a restock action is set to add five items to the pool, then only two will be accepted.

Obtaining Emergency Spares
Emergency restock actions can also be defined. Figure 3 illustrates the Emergency Spare Provisions page of the Spare Part Pool Properties window. An emergency action is triggered only when a block requests a spare and the part is not currently in stock. This is the only trigger condition. It does not look at whether a part has been ordered or if one is scheduled to arrive. Emergency spares are ordered when the condition is triggered and arrive after a time equal to the required time to obtain emergency spare(s).

Emergency Spare Provisions page of the Spare Part Pool Properties window

Figure 3: Emergency Spare Provisions page of the Spare Part Pool Properties window

Basic Logic Rules
The following rules summarize some of the logic when dealing with spare part pools.

  1. Queue Based: Requests for spare parts from blocks are queued and executed on a "first come, first served" basis.
  2. Emergency: Emergency restock actions are performed only when a part is not available.
  3. Scheduled Restocks: Scheduled restocks are added instantaneously to the pool at the scheduled time.
  4. On-Condition Restock: On-condition restock happens when the specified condition is reached, e.g. when the stock drops to two or if a request is received for a part and the stock is below the restock level.
    1. For example, if a pool has three items in stock and it dispenses one, an on-condition restock is initiated the instant that the request is received (without regard to the logistic delay time). The restocked items will be available after the required time for stock arrival has elapsed.
    2. The way that this is defined allows for the possibility of multiple restocks. Specifically, every time a part needs to be dispensed and the stock is lower than the specified quantity, parts are ordered. In the case of a long logistic delay time, it is possible to have multiple re-orders in the queue. (Note: This logic was modified after BlockSim's initial release, CRV 6.0.6 or higher. The logic before CRV 6.0.6 was to restock only when the stock level dropped and not if it was below. However, the modification was made because this could "starve" the pool, i.e. get to a point where no parts are ordered and the pool drops to zero.)
  5. Parts Become Available After Spare Acquisition Logistic Delay: If there is a spare acquisition logistic time delay, the requesting block will get the part after that delay.
    1. For example, if a block with a repair duration of 10 fails at 100 and requests a part from a pool with a logistic delay time of 10, that block will not be up until 120.
  6. Compound Delays: If a part is not available and an emergency part (or another part) can be obtained, then the total wait time for the part is the sum of both the logistic time and the required time to obtain a spare.
  7. First Available Part is Dispensed to the First Block in the Queue: The pool will dispense a requested part if it has one in stock or when it becomes available, regardless of what action (i.e. as needed restock or emergency restock) that request may have initiated.
    1. For example, if Block A requests a part from a pool and that triggers an emergency restock action, but a part arrives before the emergency restock through another action (e.g. scheduled restock), then the pool will dispense the newly arrived part to Block A (if Block A is next in the queue to receive a part).
  8. Blocks That Trigger an Action Get Charged With the Action: A block that triggers an emergency restock is charged for the additional cost to obtain the emergency part, even if it does not use an emergency part (i.e. even if another part becomes available first).
  9. Triggered Action Cannot Be Canceled: If a block triggers a restock action but then receives a part from another source, the action that the block triggered is not canceled.
    1. For example, if Block A initiates an emergency restock action but was then able to use a part that became available through other actions, the emergency request is not canceled and an emergency spare part will be added to the pool's stock level.
    2. Another way to explain this is by looking at the part acquisition logistic times as transit times. Because an ordered part is en-route to you after you order it, you will receive it regardless of whether the conditions have changed and you no longer need it.

Simultaneous Dispatch of Crews and Parts Logic
Some special rules apply when a block has both logistic delays in acquiring parts from a pool and when waiting for crews. BlockSim dispatches requests for crews and spare parts simultaneously. The repair action does not start until both crew and part arrive, as shown in Figure 4.

Simultaneous dispatch of crews and parts

Figure 4: Simultaneous dispatch of crews and parts

If a crew arrives and it has to wait for a part, then this time (and cost) is added to the crew utilization time.

Example Using Both Crews and Pools
Consider the following example, using both crews and pools.

Example of system utilizing crews and pools

Figure 5: Example of system utilizing crews and pools

The properties of each block are defined in the following table: 
(Note: Blocks do not operate when the system is down.)

The properties of each crew are defined as follows:

The spare part pool is also defined.

The behavior of this system from 0 to 300 is shown graphically in Figure 6.

System overview using both crews and spare part pools

Figure 6: System overview using both crews and spare part pools

The discrete system events during that time are as follows:

  1. Component A fails at 100 and Crew A is engaged.
    1. At 110, Crew A arrives and completes the repair by 120.
    2. This repair utilizes the only spare part in inventory and triggers an on-condition restock. A part is ordered and is scheduled to arrive at 160.
    3. A scheduled restock part is also set to arrive at 150.
    4. Pool [on-hand = 0, pending: 150, 160].
  2. Component B fails at 121. Crew A is available and it is engaged.
    1. Crew A arrives by 131 but no part is available.
    2. The failure finds the pool with no parts, triggering the on-condition restock. A part was ordered and is scheduled to arrive at 181.
    3. Pool [on-hand = 0, pending: 150, 160, 181].
    4. At 150, the first part arrives and is utilized by Component B.
    5. Repair on Component B is completed 20 time units later, at 170.
    6. Pool [on-hand=0, pending: 160, 181].
  3. Component C fails at 122. Crew A is already engaged by Component B, thus Crew B is engaged.
    1. Crew B arrives at 137 but no part is available.
    2. The failure finds the pool with no parts, triggering the on-condition restock. A part is ordered and is scheduled to arrive at 182.
    3. Pool [on-hand = 0, pending: 160, 181,182].
    4. At 160, the part arrives and Component C is repaired by 180.
    5. Pool [on-hand = 0, pending: 181,182].
  4. Component F fails at 123. No crews are available until 170 when Crew A becomes available.
    1. Crew A arrives by 180 and has to wait for a part.
    2. The failure found the pool with no parts, triggering the on-condition restock. A part is ordered and is scheduled to arrive at 183.
    3. Pool [on-hand = 0, pending: 181,182, 183].
    4. At 181, a part is obtained.
    5. By 201, the repair is completed.
    6. Pool [on-hand = 0, pending: 182, 183]
  5. Component D fails at 171 with no crew available.
    1. Crew B becomes available at 180 and arrives by 195.
    2. The failure finds the pool with no parts, triggering the on-condition restock. A part is ordered and is scheduled to arrive at 231.
    3. The next part becomes available at 182 and the repair is completed by 205.
    4. Pool [on-hand = 0, pending: 183, 231]
  6. End time is at 300. Because the last scheduled part at 300 coincides with the simulation end time, the part is not added to the pool.

For additional information on repairable systems analysis, read the  Repairable Systems Analysis Through Simulation chapter of the System Analysis Online Reference: Reliability, Availability and Optimization.

ReliaSoft Corporation

Copyright 2003 ReliaSoft Corporation, ALL RIGHTS RESERVED