|
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.
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
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).
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.
- Queue Based: Requests for spare parts from blocks are queued and executed on a
"first come, first served" basis.
- Emergency: Emergency restock actions are performed only when a part is not
available.
- Scheduled Restocks:
Scheduled restocks are added instantaneously to the pool at the
scheduled time.
- 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.
- 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.
- 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.)
- 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.
- 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.
- 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.
- 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.
- 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).
- 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).
- 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.
- 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.
- 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.
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.
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.
Figure
6: System overview using both crews and spare part pools
The discrete system
events during that time are as follows:
- Component A fails at
100 and Crew A is engaged.
- At 110, Crew A
arrives and completes the repair by 120.
- 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.
- A scheduled
restock part is also set to arrive at 150.
- Pool [on-hand = 0,
pending: 150, 160].
- Component B fails at
121. Crew A is available and it is engaged.
- Crew A arrives by
131 but no part is available.
- The failure finds
the pool with no parts, triggering the on-condition restock. A part
was ordered and is scheduled to arrive at 181.
- Pool [on-hand = 0,
pending: 150, 160, 181].
- At 150, the first
part arrives and is utilized by Component B.
- Repair on
Component B is completed 20 time units later, at 170.
- Pool [on-hand=0,
pending: 160, 181].
- Component C fails at
122. Crew A is already engaged by Component B, thus Crew B is engaged.
- Crew B arrives at
137 but no part is available.
- The failure finds
the pool with no parts, triggering the on-condition restock. A part
is ordered and is scheduled to arrive at 182.
- Pool [on-hand = 0,
pending: 160, 181,182].
- At 160, the part
arrives and Component C is repaired by 180.
- Pool [on-hand = 0,
pending: 181,182].
- Component F fails at
123. No crews are available until 170 when Crew A becomes available.
- Crew A arrives by
180 and has to wait for a part.
- The failure found
the pool with no parts, triggering the on-condition restock. A part
is ordered and is scheduled to arrive at 183.
- Pool [on-hand = 0,
pending: 181,182, 183].
- At 181, a part is
obtained.
- By 201, the repair
is completed.
- Pool [on-hand = 0,
pending: 182, 183]
- Component D fails at
171 with no crew available.
- Crew B becomes
available at 180 and arrives by 195.
- The failure finds
the pool with no parts, triggering the on-condition restock. A part
is ordered and is scheduled to arrive at 231.
- The next part
becomes available at 182 and the repair is completed by 205.
- Pool [on-hand = 0,
pending: 183, 231]
- 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 On-Line Reference: Reliability, Availability and Optimization.
|
