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.

There are restrictions on the tasks that can be performed simultaneously on the same block. Please refer to Multiple Tasks on the Same Block in the BlockSim documentation.

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 Task Scheduling.)
• Basic Task Properties > Spare Part Pool allows you to choose or create the spare part pool(s) that will be used in performing the task. A 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.
  
  You must specify a quantity of parts requested from the pool by the task. All requested parts must be delivered before the task can be performed. The default value in the Quantity requested by task field is 1.
  
  You can assign multiple spare part pools to a task. In this case, the task is assumed to require all requested parts from all requested pools. In other words, the pools are in an AND relationship, not an OR relationship.
  
  For corrective and preventive tasks, the simulation requests a team as soon as a task is initiated; however, the team does not begin performing the task unless/until all required spare parts are 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.

• Perform this task even if the item failed before this task was scheduled to occur?: If you answer Yes, the task will be performed even if the item has already failed. This option is available only for the following tasks:
  • Preventive tasks and inspection tasks (including the inspection portion of on condition tasks) that are scheduled based on item age. In this case, the item's "clock" is not stopped upon failure, and the item's "virtual age" is used to trigger the task.
  • Inspection tasks (including the inspection portion of on condition tasks) that are scheduled upon system down or events in a maintenance group.
  • The inspection portion of on condition tasks scheduled based on calendar age.

Note that this setting is not relevant when a task is scheduled to be performed as part of a maintenance phase in a phase diagram; all such tasks are performed regardless of whether the item has failed.

• 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.