 |
 |
|
 |
 |
|
 |
 |
 |
The underlying assumptions when performing simulations are:
Phase duration is based on calendar time.
Age is carried over from phase to phase.
All identically-named blocks of a given block type, across all diagrams and subdiagrams, refer to the same item, and results for these blocks are combined. The phases cannot contain identically-named blocks of different types (e.g., standard blocks and contained blocks). Note, however, that contained blocks are underlyingly named in the format ContainerName:BlockName, so a standard block named "MyBlock" and a contained block named "MyBlock" inside a container named "MyContainer" are not identically named and do not refer to the same item.
Maintenance tasks in progress during one operational phase can be interrupted if that phase ends before the repair is completed. For example, a crew delay or spare parts order may extend the duration of a repair beyond the duration of the phase. As described next, the software handles these interruptions differently, based on the stage in which the repair was interrupted and whether or not the failed block is present in the next contiguous phase.
If a phase ends during the repair of a failed block and the block is present in the next contiguous phase:
If the same task is present in both phases, then the task will continue as-is in the next phase. This is considered an uninterrupted event, and counts as a single unique event at both the block and the system level.
If the interrupted task is not used in the next phase, then the task is canceled and new tasks are applied as needed. In this case, all crew calls are canceled and spare parts are restocked.
If the repair has started or the crew is delayed (crew logistic delay), the call will be assumed accepted and the component will be charged for it. If the crew was occupied with another component's repair, the call will be assumed rejected and hence not charged to the component.
If the call for spare parts incurred emergency charges, those are charged to the block; otherwise, there are no other charges to the block.
If a phase ends during the repair of a failed block and the block is not present in the next contiguous phase, then the task is canceled and new tasks are applied as needed. All crew calls are canceled and spare parts are restocked.
If the repair has started or the crew is delayed (crew logistic delay), the call will be assumed accepted and the component will be charged for it. If the crew was occupied with another component's repair, the call will be assumed rejected and hence not charged to the component.
If the call for spare parts incurred emergency charges, those are charged to the block; otherwise, there are no other charges to the block.
Discontinuous events are counted as two distinct events at both the block and the system level.
When the system fails in a phase that has a failure path leading to a stop block, the system will remain down for the remainder of the simulation. From that point on, the blocks that are down are assumed unavailable and the blocks that are up are assumed operational for availability calculations.
In any of these cases, if a task is canceled while an associated part is still incoming and the current phase ends before the part reaches the pool, then if a task requiring a part from that spare part pool occurs in a subsequent phase, the task will be "aware" of the impending arrival of the part and able to use it only if the part arrives before another planned phase change occurs. Otherwise, the task will order its own part.
A system is considered down and unavailable during the execution of a maintenance phase and remains down until all components have been repaired or maintained according to the properties specified for the maintenance phase. A maintenance phase is executed when the simulation reaches the phase while progressing through the phase diagram, either following a success path or a failure path. The following assumptions apply to both cases.
When a component enters a maintenance phase in a down state, the following rules apply:
If a task is in progress for this component, the event will transfer to the maintenance phase provided that the same task is present in the maintenance phase. The rules for interrupted tasks apply as noted above.
If the component is failed but no corrective maintenance is in progress (either because the component was non-repairable in the phase where it failed or because it had a task scheduled to be executed upon inspection and was waiting for an inspection), a repair is initiated according to the corrective maintenance properties specified for the component in the maintenance phase.
Failed components are fixed in the order in which they failed.
If a block does not have a corrective task in the maintenance phase but does have an on condition task, the preventive portion of the on condition task is triggered immediately in order to restore the block.
Scheduled tasks included in the maintenance phase will be performed regardless of their setting in the Perform this task even if the item failed before this task was scheduled to occur? field.
When a component enters a maintenance phase in an operating state, the following rules apply:
Maintenance will be scheduled as follows:
Tasks based on intervals or upon start of a maintenance phase
Tasks based on events in a maintenance group, where the triggering event applies to a block
Tasks based on system down
Tasks based on events in a maintenance group, where the triggering event applies to a subdiagram
Within these categories, order is determined according to the priorities specified in the maintenance template (i.e., the higher the task is on the list, the higher the priority).
An inspection or preventive task may be initiated, if applicable, with inspections taking precedence over preventive tasks. Inspections and/or preventive tasks are initiated if one of the following applies:
Upon certain events:
The task is set to be performed when a maintenance phase starts.
The policy is set to be performed based on events in a maintenance group and one of those events occurs within the one of the specified maintenance groups. Note that such a triggered maintenance does not follow the priorities specified in the maintenance template, but is sent to the end of the queue for repair.
The task is set to be performed whenever the system is down.
At certain intervals:
The task is set to be performed at a fixed time interval, based on either item age or calendar time, and the maintenance falls within the maintenance threshold specified in the maintenance phase.
If the inspection task is not set to bring either the item or the system down, the inspection will still be considered a downing inspection.
Starting in Version 11, the on/off state of a block with state change triggers is maintained across phases (i.e., it is not reset from any previous phase). In previous versions, the state was determined at the beginning of each phase based on the Initial state specified in the block’s properties.
© 1992-2018. HBM Prenscia Inc. ALL RIGHTS RESERVED.
 |
E-mail Link |