Rules and Assumptions

Rules and Assumptions when Transferring Interrupted Maintenances Across Phases

Maintenance actions in progress during a phase may be interrupted if that phase ends before the repair is completed. For example, a crew delay, a spare part's order or the duration of the repair itself may result in the repair action extending beyond the duration of the phase. Such events continue in the next phase where the component in question is present again. BlockSim deals with these interruptions differently depending on the stage in which the repair or maintenance was interrupted and also on whether or not the failed block is present in the next contiguous phase. For example, given three phases in an airplane's mission (i.e. take-off, cruising and landing), the presence of an engine would be continuous, as it would be needed in all three phases. The rules on transferring an interrupted maintenance in such a case are described next under the first set of assumptions. However, in the case where there is gap between the phases where the component appears (e.g. for the example mentioned previously, the landing gear would only be needed for take-off and landing) different rules apply and are described under the second set of assumptions.

Assumptions when transferring interrupted maintenances through continuous phases:

A call to a crew will be cancelled if the crew is not associated with the block in the next phase. It will count as a rejected call in the phase when the crew was called and the component will make a new request in the next phase.
A crew will continue the maintenance action as-is if the repair has not started but the crew is on its way (applies when there is a logistic delay associated with the crew).
If a spare part was not received by the end of the phase in which it was ordered, it will still be used upon arrival in the next phase, even if a different or no spare pool is associated with the component in the new phase.
If the repair has not started, a repair time based on the properties of the new phase will apply. If the repair has started, it will finish as-is in the next phase. (There will be no change in repair distribution even if different repair distributions apply in the next phase.)
Only continuous, uninterrupted events count as one unique event, both at the block and at the system level. An uninterrupted event is one where the repair continues as-is in the next phase. Otherwise, BlockSim will assume that these are two separate events.

Assumptions when transferring interrupted maintenances if a gap exists between phases:

All calls to crews will be terminated. If the repair has started or the crew is delayed (crew logistic delay), the call is assumed to be accepted and the component will be charged for it. If the crew was tied with another component's repair, the call is assumed to be rejected and hence not charged to the component.
If a spare part was not received by the end of the phase in which it was ordered, it will still arrive at its scheduled time in one of the succeeding phases, even if the component's repair cannot be performed at that time (due to the absence of the component in that phase). Please note that this delay will not count as downtime for the block, since the block is not defined in the phase contiguous to the one in which the spare parts order was initiated. The delay will only count against the pool results for the phase.
A repair time based on the properties of the new phase will apply.
Discontinuous events are counted as two distinct events both at the block and at the system level.

Rules and Assumptions for the Start New Simulation Option

When a system failure occurs in a phase with the option to Start New Simulation, the simulation is aborted. Once this failure occurs, the following assumptions apply to the results:

Components that are under repair or maintenance remain down and unavailable for the rest of the simulation.
Components that are operating remain up for the rest of the simulation.

Rules and Assumptions for a Maintenance Phase

A system is considered down and unavailable during the execution of a maintenance phase. The system remains down until all components in the phase have been repaired or maintained as per the maintenance properties specified by the user for this phase. A maintenance phase can be executed for two reasons. It can either be reached as the simulation progresses in the phase diagram from one phase to the next or it can be initiated by a system failure in a previous phase that has the Go to Maintenance Phase option set for the On System Failure Property. BlockSim handles these two scenarios in the same manner as per the rules and assumptions described next.

When a component enters a maintenance phase in a down state the following rules apply:

If a maintenance or repair is in progress for this component, the event will be transferred to the maintenance phase according to the rules described above.
If the component is either non-repairable in the phase where it failed or has a policy to be corrected upon inspection, a repair is initiated according to the CM properties specified for this component in the maintenance phase.
Any other component that fails before this component takes priority for the repair actions before this component.

When a component enters a maintenance phase in an operating state the following rules apply:

Maintenances will be scheduled according to the priorities specified by the user.
An inspection or PM may be initiated, if applicable, with inspections taking precedence over PMs. Inspections/PMs are initiated if one of the following applies:

Policy is set to be performed Upon Start of a Maintenance Phase.
Policy is set to be performed upon a fixed Item Age and the component age exceeds the value specified by the user.
Policy is set to be performed Upon Maintenance of another Group Item, and an item in the same group is being maintained. Note that such a triggered maintenance does not follow the priorities specified by the user but is sent to the end of the queue for repair.

If the user did not select to bring the item or the system down upon inspection and an inspection is initiated, the inspection will still be considered as a downing inspection.

Go to weibull.com
Go to ReliaSoft.com