In order to perform preventive maintenance, you need to define PM actions. For a PM action you should at a minimum, enter information such as object ID, action and maintenance organization.
In order for the PM actions to generate work orders on a regular basis (calendar-based generation), or based on the condition of the object (condition-based generation), or because of a certain type of event that has occurred (event based generation), you need to enter one or several generation criteria on the PM action. You can define one generation criteria, or combine several generation criteria on one PM.
To generate work orders for due PM actions, the Calendar generation, Event generation and Condition generation jobs need to be run on a regular basis (you decide how often). You can also generate work orders manually for a specific PM action.
Calendar-based generation
For PM actions that should generate work orders on a regular basis you would use calendar criteria to define when to start generating work orders, and how often.
When you define the calendar criteria you have several alternatives to specify start date, interval, and unit of measure. The alternatives and possible combinations are shown in the table below.
Start Unit | Start Value | Interval Unit | Interval | Explanation |
Day | 08-Aug-2019 | Day | 1 | 1 day later |
Day | 08-Aug-2019 | Week | 1 | 7 days later |
Day | 08-Aug-2019 | Month | 1 | Next month, the same date |
Day | 08-Aug-2019 | Year | 1 | Next year, the same date |
Week | 1932 | Week | 1 | Next week, Monday |
Week | 1932 | Year | 1 | Next year, same week, Monday |
Month | 1908 | Month | 1 | Next month, first available date |
Month | 1908 | Year | 1 | Next year, first available date |
Combinations of calendar-based PM supported by the system.
When the calendar criteria is defined, a PM Plan is automatically created. The length of the PM plan is determined by either the PM_PLAN_HORIZON system parameter (defined in IFS/Application Services) or the valid dates entered on individual PM actions. The PM_PLAN_HORIZON is common for all calendar based PM actions, regardless of whether a valid date is entered for the PM actions. The valid dates serve as a method to limit (or to cap) the longevity of individual PM actions.
Example of calendar-based generation.
You can generate work orders for calendar-based maintenance as often, and as far ahead in time as you wish. Longer planning time allows you to analyze resource requirements early and coordinate maintenance with other activities. By connecting Generated Work Time Calendars (defined in IFS/Application Services) to PM actions, you can make sure that the planned date of the PM actions generated will always be on a working day. For example, the figure above illustrates a monthly calendar-based generation where the planned date of each PM action falls on the first of each month. In reality, the first of each month does not always fall on a working day. Assume that 980501 falls on a Saturday. If a calendar is connected, the planned date for the generated PM action will be moved to the closest working day which in this case would be 980503 (Monday).
Event-based generation
If you wish to generate work orders based on a certain type of event such as 'Yearly shutdown', 'Power outage', 'Breakdown', 'Revision', etc you can use the event-based generation criteria.
When you create a new maintenance plan with event-based generation, specify after how many event occurrences the PM action should start generating work orders, and specify with what event interval a work order should be created thereafter, for example every second time. See the example in the picture below.
Example of event-based generation with an interval. In this case, the action should occur for every other revision, starting with the third one.
Condition-based generation
In situations where you wish that a certain condition of the equipment object should determine when work orders should be generated, you can use condition-based criteria. For example, you can use a condition-based PM so that a work order is generated to inspect a machine if the machine's measured temperature rises above 100 degrees. Or a work order is generated to lubricate a machine when it has run for 40 hours.
In order to create a condition-based PM action, a parameter must have been defined and connected to the object id. A parameter can measure one of two types of values; Accumulated or Limit values. An accumulated parameter can for example be 'Operation time' or 'Produced quantity'. A limit parameter can be 'Temperature', 'Oil level', 'Pressure', 'Water flow', etc.
If any cumulative criteria is registered, a criteria line is shown on the Maintenance Plan tab even before any measurement is registered. You can manually generate work orders having this line only. When two or more accumulated measurements are registered, it generates a condition based forecast PM plan by calculating the average use per day under the assumption of linear use of the equipment object.
IMPORTANT: Upon registering accumulated measurements, the condition based forecast PM plan will be regenerated accordingly. The user can choose to run the regeneration as a background job by setting the system parameter PM_CON_PLAN_SYNC to BATCH. The Plan Out of Sync flag in the PM Action/Condition tab will indicate if the condition based forecast PM plan is in conflict with the latest measurement entered for the object. When the condition based forecast PM plan is in conflict, it will not be allowed to generate Work Orders from the affected PM Action. If the parameter PM_CON_PLAN_SYNC is set to ONLINE, the regenerate plan process will run immediately, and this might take a few minutes.
On the PM action you define what values are outside what is acceptable for the object's parameter. When a measurement is recorded against an object parameter, and the measurement value falls outside the acceptable values defined on the PM action, a work order will be generated when the condition generation is run.
The process of defining a parameter and PM action, recording measurement and generate work order is described in the picture below.
The chain of events for condition-based PM actions.