Monitor Equipment Condition Using Operational Parameter Values from Connected Equipment

In this video, we demonstrate how equipment condition can be monitored using operational parameter values of connected equipment. Asset availability is an important performance indicator for the maintenance function.

Condition monitoring enables maintenance teams to quickly respond to critical issues and minimize disruption to asset operation or production. With this update, sensor values like pressure, temperature, vibration, and others are monitored to check if there are underlying conditions that may need attention. By using thresholds against the sensor attributes, maintenance work orders can be generated for values outside of tolerance. This update provides the following new functionality.

On the event ingestion side, we provide operational parameters that define values to be captured. This way, connected assets can send events with operational parameter values. In order to detect range violations, we can use those values in operational rules. We can also define the scope to which rules are applied, such as operational or location organizations. Or it could be all assets, selected items, or item categories.

Resulting from a positive evaluation of a rule, a maintenance work order, a production exception, or both can be created. In order to ignore short periods out-of-range parameters that can happen as harmless spikes or during startup, outcomes can be delayed for a certain period of time. Outcomes can be parameterized with custom condition codes and custom descriptions.

In this demo, we would like to monitor an equipment which has a temperature and a pressure sensor. We start with the creation of operational parameters for both temperature and pressure.

The new task list entry brings us to the Operational Parameter page. We give this parameter a name, a code, a description. Choose a data type, in this case, numeric unit of measure is Celsius. And give it a target value, a minimum and a maximum. Then save it. The pressure parameter will be created the same way.

Now we go to the Operational Rules page to create a new rule. We set up the rule with a name, a description, and a rule code. We want this rule to apply to equipment based in the Seattle manufacturing plant. We want to apply the rule to all equipment in Seattle. Alternatively, we can restrict it to certain assets, asset items, or item categories.

Then we define the evaluation criteria. We want operational parameter values to be used, so we use the operational parameters event type. We want to create a work order if both pressure and temperature are above a certain limit. So we set up a new condition that uses both temperature and pressure.

Only if the issue lasts longer than 10 minutes, we would like to create a work order. The first parameter defines that time period. The second parameter defines a time period after which a new issue is considered not to be related to the first event. In this example, if there would be no further threshold violations within the next 240 minutes, the issue will be ignored.

When the evaluation criteria triggers, we would like to create a work order. In this case, we would like to have the condition code of FC1, which could either be a failure code or a diagnostic code.

For the work order description, we would like to use a custom string that has both the sensor values detected, the temperature, and pressure. We use these special templates to insert temperature and pressure where we want it in the string.

The work order description should also contain the asset number so that we know which asset exposed the issue. So we use another template to insert it in the string. Finally, we hit the button to create a new rule.

The next section simulates how operational parameter values can be ingested by the equipment. The ingested events contain the asset number, the two operational parameters values for temperature and pressure, as well as an event time when these two values have been captured.

Now we send the event for the first time. After five minutes, we send the same event, now with different attribute values. At this time, no work order will be created because we entered a delayed time of 10 minutes. Finally, we send another event which is now 15 minutes after the first event. Now it creates a work order because it exceeds the delayed time of 10 minutes.

Now we look at the created work order. The work order was created for the asset contained in the event. The description contains the asset number as well as the temperature and pressure of the first and the last event. So we monitored the condition of the equipment based on operational parameter values and successfully created a work order.

This concludes the demo on how to use sensor values. We showed how sensor attributes will be ingested, how rules evaluate sensor attributes, and how to customize the outcome.