What types of assets are supported?
You can use Asset Risk Predictor (ARP) with any assets that can be monitored using sensors.
Some examples include (but are not limited to):
- Industrial machinery, such as pumps, motors, and gearboxes, to monitor for abnormal vibrations that may indicate a mechanical failure or unbalance.
- HVAC systems, to monitor temperature, humidity, and air flow.
- Electrical systems, to monitor current, voltage, and power usage.
- Motors and generators, to monitor speed (RPM) and power output and consumption.
- Manufacturing equipment, to monitor temperature and humidity levels in the production environment.
- Automotive, to monitor temperature, humidity, speed and vibration, of engine, transmission and wheels.
- Wind turbines and other renewable energy systems, to monitor for abnormal vibrations, temperature changes and power output.
- Robotics, to monitor temperature, humidity, vibrations, speed, current and voltage for safety and performance optimization.
How does this solution scale? For example, could we use it for 1000 assets?
Yes, because it is a scaled cloud solution and it can technically be enabled for 1000 assets. If you want to enable ARP for a large number of assets, contact your Fiix representative to discuss your options.
Is non-continuous manufacturing supported?
Yes, batch manufacturing is supported. This process relies on the machine having an indicator of when the machine is running. ARP uses an IsRunning variable to let it know which data points occurred when the machine was online or offline. We also recommend using the Fault variable in the payload, which allows us to understand the running condition of the machine when the operator has it enabled. For example, maybe the operator is running the machine and it is in a slow cycle state or an overloaded state. ARP considers this and adjusts how it interprets the data and risk score.
Are operations with different load supported?
Yes, we support operations with different loads. Any recipe information we receive is used alongside sensor data in the training model. This ensures that prediction results include the recipe details, allowing the algorithm to accommodate different loads without mislabeling them as anomalies.
Can I add or change assets later?
Yes, you can add or change the assets (and sensors) included in ARP. The process for adding or changing assets and sensors is similar to the initial setup. To learn more, see Overview: Asset Risk Predictor setup.
Note
There is a cost associated with adding or changing assets and sensors.
To add or change the assets in ARP, contact your Fiix representative.
Do I have to pay to include recipes, fault codes, and machine statuses in my data stream?
No, you only pay for sensors/tags. Recipes, fault codes, and machine statuses are included for free.
The following is an example of a payload that is considered one sensor input:
{
“sensorId”: “V6-API-TEST”,
“arpData”: [
{
“eventTime”: “{{timestampUtcIso8601}}“,
“isRawData”: false,
“avgValue”: 2.5,
“minValue”: 1.0,
“maxValue”: 5.5,
“stddevValue”: 1.6,
“message”: “V6 Public API”,
“isMachineRunning”: true,
“recipe”: “Recipe Test new “,
“fault”: “Fault1"
}
]
}
What if I have rotating assets that get an inconsistent amount of use? Will this impact the results in ARP?
Not always. ARP waits for the “IsOnline” flag to be true before using the data, so if an asset is offline, it should not be sending data or this flag should be false.
If we are swapping components on a machine, we are monitoring with ARP and this action is causing false high-risk events, there are a few options. The easiest way is to incorporate this machine setup into the recipe field in the data package, and ARP develops a custom model for this specific setup. For example, if the recipe looks like “ModelXYZ” we can adjust this to “ModelXYZ-Setup1”, “ModelXYZ-Setup2”, etc. Now, ARP detects a change in the recipe based on the rotating assets or setups, and creates a custom model for each one.
Are there any types of assets that aren’t a good fit for ARP?
Low-run assets are a bad fit, as we need (more or less) continuous data. To keep the system running optimally, we need at least 2400 minutes of data over 7 days. Therefore, if the machine does not run for 2400 minutes a week where the “IsOnline” flag is not true, and there are no faults, the system will begin to skip data points. These 2400 data points can be in a row or broken up, but must occur in a 7-day running span.