Related Topics: | ||
In Synthesis applications, maintenance activities are represented using shared resources that are available for use throughout the project 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 items in the System panel and to functions, failures and causes in the Analysis Panel.
The Maintenance Task window allows you to create, view and edit all classes of maintenance tasks. It can be accessed by double-clicking a task in the FMEA hierarchy or by clicking the Create New or View/Edit icon in the Task wizard, which is accessed from Task fields (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 > New, 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 Define 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 Synthesis 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.
The Task Name field allows you to specify a name for the task. You can replace the default name with your own name of up to 150 characters (1,000 characters for scheduled tasks), if desired. Authorized users can change the default names by choosing File > Manage Repository > Define Default Names.
The Task Type field allows you to specify the type of maintenance task (choose from a drop-down list). This field is available only for scheduled tasks. Each task type is associated with one of the task classes (i.e., preventive, inspection or on condition); the task types, including their task class association, are defined via the Task Types window. The task type determines the properties that will be available in the window and the inputs that will be used. For example, if you select a task type that is associated with on condition tasks, the properties for both the inspection part of the task and the preventive part of the task will be displayed. In addition, the task type is important if you are using the simulation and cost calculation method to compare potential maintenance strategies because the associated task class determines how the costs are calculated.
What's Changed? In previous versions, task types and the cost calculation methods associated with them were defined via the task selection logic. In Synthesis, task types are defined via the Task Types window and the cost calculation method used for each is determined by the task type's association with a task class.
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 item 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 item 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#Imperfect_Repairs.
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 allows you to enter additional identifying information that can be used to search for this resource.
History provides information about the creation and last modification of the resource. 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 resource.
You can collapse or expand all nodes in the hierarchy using the Collapse All and Expand All icons.
You can resize the columns by pointing to the column splitter. When the pointer becomes a double-headed arrow, drag the splitter to the desired location. You can restore the column widths to their original settings by clicking the Restore Column Widths icon.
For an existing resource, a link at the bottom of the properties window indicates how many times it is currently being used. If you need more information, click the link or the Trace Usage icon.
This opens the Dependency Viewer, which allows you to explore both where the resource is being used and what other resources are associated with it.
© 1992-2015. ReliaSoft Corporation. ALL RIGHTS RESERVED.