Tasks

To properly analyze repairable systems, we first need to understand how components in these systems are restored (i.e., the maintenance activities that are performed on the components). In general, maintenance is defined as any action that restores failed units to an operational condition or keeps non-failed units in an operational state. For repairable systems, maintenance plays a vital role in the life of a system. It affects the system's overall reliability, availability, downtime, cost of operation, etc.

In ReliaSoft applications, maintenance activities are represented using tasks, which are resources that can be shared among analyses and can be managed via the Resource Manager. There are two basic kinds of tasks, which comprise four task classes:

Corrective tasks are the action(s) taken to restore a failed component to operational status. These cannot be scheduled, as the component's exact failure time is not known before it happens.
Scheduled tasks can be performed on a known schedule, based on time, component condition or other factors. These include:

Tasks are assigned to URDs, which are in turn used to represent a set of properties that can be applied to standard blocks in RBDs and to events in fault trees.

The Maintenance Task window allows you to create, view and edit all classes of maintenance tasks. It can be accessed by clicking the Create New or View/Edit icon in the Task wizard, which is accessed from Task fields in properties windows (e.g., the Corrective Maintenance Task field in the Universal Reliability Definition window).

It can also be accessed from the Corrective Tasks and Scheduled Tasks pages of the Resource Manager by choosing Home > Edit > Add, by selecting a task and choosing Home > Edit > View or by double-clicking a task.

For a new resource, a name will be proposed automatically based on the default naming criteria established for the current database (see Default Name Formats window). You can replace this with your own name of up to 150 characters, if desired. Remember that the name and identifiers are the primary way in which your team will be able to find the resources you need for your analyses.

The following options must be configured for all classes of tasks. Configuration options that are specific to particular task classes are presented in the corresponding sections.

Basic Task Properties
- Task duration allows you to assign a model, which may represent a fixed time or a distribution, to describe the duration of the task. You can choose an existing model or create a new one. If no model is assigned, it is assumed that the task has a duration of zero (i.e., immediate repair).
- Crew for task allows you to choose or create one or more crews that can perform the task. If multiple crews are assigned to the task and a crew is needed, they will be checked for availability in the order in which they are displayed in this list. Use the Priority Up and Priority Down arrows that appear when you click a crew name in the list to move it up and down in the list. If a crew is needed and all crews are engaged, the crew with the shortest wait time is chosen to perform the task.

If no crew is assigned, it is assumed that the work will be done by some undefined crew that is always available.

Restoration These properties allow you to specify the degree to which the block will be restored after the performance of the task. In the How much does this task restore the item? field, you can specify that the item will be returned to as good as new condition (i.e., full repair, equal to a restoration factor of 1), to the same condition it was in when it failed (i.e., "as bad as old" or minimal repair, equal to a restoration factor of 0), or you can choose Partial restoration. This option provides you with the ability to model maintenance involving "used parts" or imperfect maintenance. The Restoration amount field will appear; you can specify the amount of restoration achieved by the task either by entering the value as a percentage or by clicking the arrow and using the slider bar that appears. If you specify anything other than 0% or 100%, you will need to specify what the restoration effect applies to (i.e., the restoration type). You can select:
- Only damage accumulated since last repair: Each repair will remove only the damage since the last repair (i.e., the nth repair cannot remove the damage incurred before the (n-1)th repair). Note that in this context any task is considered a repair and any damage that has occurred since the last event (corrective task, preventive task, inspection or on condition task) will be reduced.
- All accumulated damage: Each repair can reduce any damage accumulated up to that failure.

For simulation, the application uses the restoration factor to determine the new age of the block after the maintenance action.

For example, consider an automotive engine that fails after 6 years. If the engine is rebuilt and the rebuilding task has a 50% restoration factor:

- If Only damage accumulated since last repair is selected, the initial rebuild has the effect of rejuvenating the engine to a condition as if it were 3 years old.

The engine fails again after 3 years (when it again reaches the effective "age" of 6 years), but the rebuild this time affects only the age accumulated after the first rebuild. Thus the engine has an effective age of 4.5 years after the second rebuild (3 + 3 x (1 - 0.5) = 4.5).

After the second rebuild, the engine fails again after a period of 1.5 years (when it again reaches the effective age of 6 years) and a third rebuild is required. The effective age of the engine after the third rebuild is 5.25 years (4.5 + 1.5 × (1 - 0.5) = 5.25).

- If All accumulated damage is selected, the initial rebuild has the effect of rejuvenating the engine to a condition as if it were 3 years old.

The engine fails again after 3 years (when it again reaches an effective age of 6 years) and another rebuild is required. This rebuild also rejuvenates the engine by 50%, thus making it effectively 3 years old again.

After the second rebuild, the engine fails again after a period of 3 years (when it again reaches the effective age of 6 years) and a third rebuild is required. The effective age of the engine after the third rebuild is 3 years.

Compare the following tables to see how the two options differ.

Only Damage Accumulated Since Last Repair

Time	Time Since Last Repair	Effective Age Before Repair	Effective Age After Repair
Start = 0	0	0	0
6 years	6	6	3
9 years	3	6	4.5
10.5 years	1.5	6	5.25

All Accumulated Damage

Time	Time Since Last Repair	Effective Age Before Repair	Effective Age After Repair
Start = 0	0	0	0
6 years	6	6	3
9 years	3	6	3
12 years	3	6	3

The ReliaWiki resource portal has more information on restoration factors at: http://www.reliawiki.org/index.php/Repairable_Systems_Analysis_Through_Simulation.

Additional Costs to Consider allows you to choose or create models to represent costs that are always associated with the task. Cost per task uses a cost model, and Downtime rate uses a cost per unit time model. If no models are assigned, it is assumed that there are no additional costs.

Identifiers contains additional identifying information that can be used to search for this resource.

History provides information about when the record was created and last updated. If the history log has been activated at the project level, you can click the View Item History icon to open the Record History Log for the record.

Watch allows each individual user to subscribe to receive an alert (via e-mail, SMS text message or portal message) when the resource is changed.

Trace Usage. For existing resources, the link at the bottom of the window indicates how many times the resource is currently being used. If you need more information, click the link or the icon to open the Dependency Viewer.

E-mail Link