 |
Related Topics: |  |
 |
 |
|
 |
 |
 |
The underlying assumptions when performing simulations are:
Phase duration is based on calendar time.
Age is carried over from phase to phase.
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 cancelled and new tasks are applied as needed. In this case, all crew calls are cancelled 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 cancelled and new tasks are applied as needed. All crew calls are cancelled 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.
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.
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.
Finally, if a block enters a maintenance phase in a failed state:
If the 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.
A maintenance phase will not end until all components are restored. Therefore, if any failed block does not have a task that restores it, the maintenance phase will not end.
© 1992-2013. ReliaSoft Corporation. ALL RIGHTS RESERVED.