Preventive Tasks

Preventive maintenance is the practice of repairing or replacing components or subsystems before they fail in order to promote continuous system operation or to avoid dangerous or inconvenient failures. The schedule for preventive maintenance is based on observation of past system behavior, component wearout mechanisms and knowledge of which components are vital to continued system operation. In addition, cost is always a factor in the scheduling of preventive maintenance. In many circumstances, it is financially more sensible to replace parts or components at predetermined intervals rather than to wait for a failure that may result in a costly disruption in operations.

Preventive tasks:

Always bring the block down.
May bring the system down.
Require spare parts.

In addition to the common task properties, the following options are used to configure preventive tasks in the Maintenance Task window:

Task Class allows you to specify the kind of maintenance that the task performs: preventive, inspection or on condition. The options available in the Maintenance Task window will vary depending on your choice in this field.
Task Scheduling allows you to specify the circumstances under which the task will be performed. See the Task Scheduling topic for more details.
Basic Task Properties > Spare Part Pool allows you to choose or create a spare part pool to assign to the task. The spare part pool describes the conditions that determine whether a spare part will be available when needed and specifies the time and costs associated with obtaining the spare part. If a spare part pool is not assigned, it is assumed that unlimited free spares are always immediately available).

For corrective and preventive tasks, the simulation does not engage a crew unless/until the spare part is available. For a complete explanation of how this affects the total time for the task, see Corrective Tasks.

Task Consequences
- Does this task bring the system down?: By default, preventive tasks will not bring the system down unless having the block down brings the system down based on the reliability-wise configuration in the diagram. If you answer Yes, the task will bring the system down, even if the task has a zero duration. This forces the task to be included in the count of system downing events, regardless of the task’s duration.
- Does this task bring the item down?: It is assumed that a block will always be down when a preventive task is performed, even a task with a zero duration; thus, this option cannot be changed.
- If bringing the item down causes the system to go down, do you still perform the task?: If you answer Yes, the task will be performed even if doing so brings the system down, either because the task itself brings the system down or because the task brings the block down and the block being down causes the system to go down. If you answer No and the task brings the system down, the task will never be performed during simulation unless the system is already down for another reason. For instance, a preventive task that is specified to be performed upon system down will be performed even if it brings the system down regardless of your answer here. This is because the system is already down, which is what triggered the task in the first place.

A preventive task that does not bring the system down at the preventive maintenance time will still be factored into the simulation even if its duration will bring the system down at a later time.

For a preventive task that is scheduled to occur based on item age and for which you have answered No to this question, if the task is going to bring the system down, then it will not take place. If, however, the block reaches the age again (after restoration by a corrective action, inspection or another type of preventive maintenance) and this time it will not bring the system down, then it will be performed.

RCM properties are text-based properties that are used to keep track of details that may be helpful in reliability centered maintenance analysis, but are not used in reliability/maintainability simulations. These properties are shown only if they are enabled for the project via the interface style settings in RCM++.
- Status: The status of the task (choose from a drop-down list). This setting could be used if you want to keep track of all tasks that have been considered, regardless of whether they end up in the actual maintenance plan (e.g. recommended, rejected, assigned).
- Proposed Interval: The interval that was initially proposed for the task. This may be different from the interval that is actually assigned to the task. For example, you may wish to use this property if the team originally suggests a particular interval for the task (perhaps the calculated optimum interval) but then decides to assign a different interval (perhaps an interval that is more convenient for packaging a group of tasks).
- Reference Document: A reference to another document that provides more detailed information about the task (e.g. procedure instructions).
- Condition: A description of the condition that indicates that a failure will occur (e.g. a threshold for a measurement of wear, vibration, etc). Typically, this field is used for on condition maintenance tasks.
- Zone: The zone of the system in which the task will be performed. Typically, this field is used for aircraft MSG-3 analyses.
- Access: The access that will be required in order to perform the task. Typically, this field is used for aircraft MSG-3 analyses

Note: A preventive task with a restoration factor of 0 will generate a new failure with the current age.