Maintenance Scheduling at Engeman®: 5th – By Event – Condition-Based Maintenance (CBM)

Learn all about the By Event Scheduling at Engeman®!

event-scheduling-condition-based-maintenance

You who follow our blog followed our series on Maintenance Scheduling. In the last articles of this series, we talked about the forms of scheduling that can be performed at Engeman® which are: Periodic, Specific Dates, Cumulative and Trend.

Finally, the time has come to talk about scheduling by Events and then end this series of articles on the forms of scheduling.  Continue to learn all about this type of scheduling and how to perform it in the Engeman® software.

Share this!

What is an event in Engeman® software?

Before we jump straight to the point to talk about the schedule itself, let’s first understand what an event is in the maintenance area and how we can identify it.

We could define it as a defect or failure in itself, but, although it may be classified as such, the best definition for the Event within Engeman® is to treat them as symptoms of an imminent defect or failure.

Thus, we will be able to frame them not only in a corrective or corrective maintenance schedule but in a somewhat more effective type, which is detective/autonomous maintenance.

By definition, the word detection already gives an idea of what we are talking about, because detection means to reveal or discover what is covered or hidden.

Maintenance does not always have a deep understanding of how a particular machine behaves until it reaches failure, and as a result, serious and unexpected failures occur, which in some cases could be minimized or even avoided.

In this way, it is not enough just to find problems and failures, but also to have an action plan to correct them as soon as possible.

Detective maintenance protects them from these issues. The diagnosis of failures at an early stage, constantly evaluating events or symptoms that occur. Minimizes wear and tear and avoids defects in machinery and equipment, avoiding work accidents or situations that put the safety of employees at the operating place at risk.

Root Cause Analysis (RCA)

So, we already know that events are symptoms of a possible failure and that in response to them we need to have good action plans. However, to understand the symptoms that led to failure, we usually need to answer the question, “Why did it fail?” element.

To answer the question “Why did it fail?” we need to determine the sequence of events that lead to the failure. Root cause analysis (RCA) is a process for determining this chain of events.

The cause may be a defect in material or assembly, damage, or design error. It can also include poor decisions and human errors. Generally, we look for the physical or chemical reason for the failure.

We must also explore the customer’s design, assembly, supply chain, and related processes to know where an error or weakness in the process contributed to the failure.

With these symptoms or events – frequently monitored through collection processes, as is also done for cumulative and trend schedules – and with the Maintenance Plans in Engeman®, it is possible for us to create occasional and eventual schedules/services. See below the application of each of them in Engeman®.

By Event Scheduling at Engeman®

In by event scheduling, it will be controlled through measurements (collections) of any type of event related to the asset or subcomponent:

  • Physical or chemical variables;
  • Production status or quality.

Upon reaching the established goal, Engeman® will indicate the need for maintenance through the W.O. Generation screen.

Measurement of data can be performed through manual notes or through equipment intended for this purpose. The measurement and data collection equipment can be connected directly to the maintenance asset point (integration with SCADA systems) or can be portable for use at various points (instrumentation and detective/autonomous maintenance).

event scheduling 1024x255 - Maintenance Scheduling at Engeman®: 5th – By Event – Condition-Based Maintenance (CBM)

A small example: A home fire alarm can fail because of a dead or nonexistent battery, faulty wiring, a faulty detector, or a faulty doorbell, among other possibilities.

Therefore, we realize that monitoring these eventual variables will ensure that the chances of failure of this equipment are significantly reduced. Also note that this event variable is not quantitative, which differentiates it from trend variables, often used for classic predictive maintenance.

We are collecting an event, a symptom, a situation of compliance or non-conformity, and through rules we can establish the performance of an action plan: “If in 1 week we find 2 events of defective wiring, we must perform the revision and replacement of the wiring for a more resistant one.” Here we have the Collection of Events and the Action Plan, which Engeman® can generate automatically if the established rule is reached.

Necessary precautions for the application of by event scheduling:

  • Measurements must be made systematically, which will require greater demand for resources and control of actions. You can create plans with periodic scheduling to control this process. 
  • Maintenance services may be requested at any time, whenever an event occurs, without allowing the visualization of future dates, thus requiring availability and readiness of resources.
  • In the case of automatic measurements, check the reliability of data collection and predict contingencies.
  • If periodic cycles are detected in the occurrence of events, the scheduling process must be changed to periodic.
  • To Rationalize the number of processes measuring points.
  • To Create approved documents for the manual data collection process.
  • In the case of event-based scheduling, the system does not predetermine consecutive Work Orders calculated for the same event over a longer period requested by the user. The scheduled date for maintenance will only be calculated when the event takes place.

Screen Operations:

  • Schedule status: active or not – if it is active, the system calculates the W.O. for the schedule.
  • Asset: equipment to which the maintenance plan will be applied.
  • Location (TAG): place where the maintenance plan will be applied, regardless of asset. If there is more than one asset in the same location, one or more W.O.s will be generated for each of them.
  • Group: (this field is not mandatory). Indicates the asset group where events will be searched. The asset mentioned above does not necessarily need to belong to this group. The research will cover the entire collection of data on the assets mentioned above and on all assets whose group is hierarchically descended. E.g.: 001. will cover assets from groups 001., 001.01., 001.02, 001.01.01 … and so on.

Startup Generation Event:

  • Period in which the W.O. generating events will be counted, expressed in days.
  • Number of failures: refers to the number of events required to generate W.O.
  • Last maintenance date: date from which the plan will be started.
  • DOW (Day of the Week): This field is informational only. Indicates the day of the week on which the last maintenance occurred.

W.O. Generation Type:

  • Generation Screen: The system will only generate W.O. on the W.O. generation screen.
  • Event Collections: With each collection posted, the system will check if that event has reached the amount in the informed time interval.

Action:

  • Alarm: Only for the Event Collection type. Upon reaching the goal, the system will display an alarm message and ask if the system should generate an early W.O. for this maintenance plan. After the W.O. is generated, the user can still print the generated W.O. or view it on the screen.
  • To generate W.O.: The system will generate an W.O. without emitting any visual warning, only an audible warning.
  • To Generate and Print W.O.: Only for the Collect Events type. The system will generate W.O. and then print it automatically.
  • To Generate and View W.O.: Only for the Collect Events type. The system will generate W.O. and then display it automatically. This option is important in the case of giving feedback to the user on the W.O. generation, it also allows the user to send the W.O. by email or even print on another printer other than the standard. 

By Event / Services at Engeman®

In the scheduling by Eventual/Services in the Engeman® software, you will be controlled through measurements of any type of event linked to a service performed in the asset:

  • Occurrence related to a component;
  • Service performed.

When reaching the established value, Engeman® will indicate the need for maintenance through the W.O. Generation screen.

Data source for analysis is the service register itself. There is no need to perform any other type of data collection.

service event scheduling 1024x253 - Maintenance Scheduling at Engeman®: 5th – By Event – Condition-Based Maintenance (CBM)

Necessary precautions for the application of by event scheduling:

  • Maintenance services may be requested at any time, whenever an event occurs, without allowing the visualization of future dates, thus requiring availability and readiness of resources.
  • If periodic cycles are detected in the occurrence of events, the scheduling process must be changed to periodic.
  • Create approved documents for the manual data collection process.
  • In the case of event-based scheduling, the system does not predetermine consecutive Work Orders calculated for the same event over a longer period requested by the user. The scheduled date for maintenance will only be calculated when the event takes place.

Screen Operations:

  • Schedule status: active or not – if it is active, the system calculates W.O. for the schedule.
  • Asset: equipment to which the maintenance plan will be applied.
  • Location (TAG): place where the maintenance plan will be applied, regardless of asset. If there is more than one asset in the same location, one or more W.O.s will be generated for each of them.
  • Group: (this field is not mandatory). Indicates the group of assets where services will be searched. The assets mentioned above do not necessarily need to belong to this group. The search will cover all W.O. service records released for the assets informed above and in all assets whose group is hierarchically descending. E.g.: 001. will cover assets from group 001., 001.01., 001.02, 001.01.01 … and so on.
  • Number of failures: refers to the number of events required to generate WO.
  • Period: time interval in which the W.O. generating events will be counted, expressed in days.
  • Record of the event-generating service: occurrence, service, material, cause. The quantity and unit fields refer to the material. You do not need to specify the material quantity if you want the system to calculate the occurrence each time the material is acknowledged, regardless of the quantity used in the service.
  • Last maintenance date: date from which the plan will be started.
  • DOW (Day of the Week): This field is informational only. Indicates the day of the week on which the last maintenance occurred.

W.O. Generation type:

Generation Screen: The system will only generate W.O. on the W.O. generation screen.

Service Collection: The collection to be posted will be on the Work Order screen in the Service Register. For each registered service, it will be verified if it is in the period informed, if it used the same material, if the same service was performed, and with the same number of failures that is informed in the plan.

Action:

  • To Emit Alarm: Only for the Service Collection type. Upon reaching the goal, the system will display an alarm message and ask if the system should generate an early W.O. for this maintenance plan. After the W.O. is generated, the user can still print the generated W.O. or view it on the screen.
  • To Generate W.O.: The system will generate an W.O. without emitting any visual warning, only an audible warning.
  • To Generate and Print W.O.: Only for the Service Collection type. The system will generate W.O. and then print it automatically.
  • To Generate and View W.O.: Only for the Collection Services type. The system will generate W.O. and then display it automatically. This option is important in the case of giving feedback to the user on the W.O. generation, it also allows the user to send the W.O. by e-mail or even print on another printer other than the standard.

Conclusion

Detective maintenance is a key asset management strategy, regardless of whether your maintenance is deeply involved in RCM (Reliability Centered Maintenance), or whether TPM (Total Productive Maintenance) is your way of life, or whether only the three basic types of maintenance (preventive, predictive, and corrective) are well established.

Remember that anyone who works with machines of any type can be a “detective.” Each operator and supervisor can quickly learn what to hear, look at, or touch to determine if a problem may be starting to develop.

And don’t forget the “clean to inspect” aspect preached by TPM. A clean machine is a healthy machine and is safer and easier to operate, maintain, set up, and adjust. The act of cleaning a machine (autonomous/detective maintenance) has proven to be one of the best ways to identify issues and take corrective action BEFORE something fails. So, use By Event Scheduling whenever possible.

I hope that this series of articles has helped to guide you about the many possibilities that Engeman® has to offer for its maintenance, in order to simplify it and at the same time make it more modern and reliable. Simple changes like these can make a big difference as a whole.

If you haven’t seen the other articles in the series, follow along through the links below:

To receive more topics like this that will help your maintenance management be more assertive, subscribe to our newsletter!

    WATCH AN ENGEMAN® PRESENTATION!