Automotive Predictive Maintenance [IIoT CAN Data Loggers]

If you're new to predictive maintenance, consider below simple definition:

The goal of predictive maintenance is to forecast and prevent equipment failure.

To make it slightly more concrete, we can put it into context:

Reactive maintenance: "If it's not broken, don't fix it". Best for cases where equipment failure is rare, easy to fix and with limited impact - e.g. switching a lightbulb in a warehouse.

Preventive maintenance: Also known as planned maintenance, this uses routine maintenance to diagnose equipment for failure. It works and is widely employed - but it is costly and does not capture asset-specific conditions.

Predictive maintenance: This involves collecting data from assets and using it to predict failure. This way, repairs can be done when needed (and avoided when not). It offers the best upside, but at the cost of complexity.

Equipment may include vehicles (trucks, cars, cranes, ships, tractors, ...) or machinery (robotics, conveyor belts, ...). As such, many target assets for predictive maintenance are based on CAN bus protocols (CANopen, J1939, OBD2, NMEA 2000, DeviceNet).

Further, predictive maintenance can be split into tiers (1.0-4.0).

At the basic level, predictive maintenance has been around for ages: When a technician inspects an asset and makes a change to avoid future failure, it is predictive maintenance.

The key change with '4.0' is the amount of data used, the update frequency and prediction models. Today, predictive maintenance 4.0 is achieved via IoT, big data and cloud analytics. This is also the type of predictive maintenance we will focus on in this article.

With the CANedge, predictive maintenance typically involves below steps:

#1 Setup your server: Set up your local/dedicated/cloud server via our guide in <5 min

#2 Configure: Configure your device with your server and WiFi or SIM details - and e.g. filters, triggers or transmit lists

#3 Record: Connect the device in your vehicle/machine to log raw CAN data

#4 Transfer: The device connects to your WiFi access point (CANedge2) or via 3G/4G (CANedge3) to auto-push log files to your server

#5 Process: Use the free Python API to DBC decode your data and set up your prediction model/logic - e.g. analyzing parameters vs. historical patterns

#6 Visualize: Finally, you can also visualize your data and set alerts via free, customizable browser dashboards. These alerts can serve as a simple predictive maintenance solution

The 'process' step is often further split into two steps for predictive maintenance:

• Predict: This involves using incoming data to predict the future, e.g. using linear regression models or simple thresholds. For example, if a specific parameter crosses a certain threshold, it may be considered 'predictive' of a potential future issue
• React: Once an issue has been predicted, the script should react - e.g. by sending a warning/notification by SMS, e-mail, slack, dashboard or similar to the relevant persons. A reaction can also be to e.g. auto-schedule maintenance or order spare parts.

Within CAN bus data logging, diagnostic trouble codes (DTC) are important indicators of issues within a vehicle. It is possible to request and record diagnostic codes across cars (OBD2 telematics), trucks (J1939 telematics), ships (marine telematics) and most other CAN use cases. The DTC information is recorded by the CANedge together with other raw CAN data and can be decoded via DBC files to human-readable form (e.g. an OBD2 DBC for cars or a J1939 DBC for heavy-duty vehicles).

You can use the DTC info for predictive maintenance in multiple ways:

• Alert: You can trigger alerts in your Grafana dashboard based on DTCs to send notifications
• Troubleshoot: DTC alerts can be visualized in your dashboard, letting you quickly diagnose issues by reviewing related data
• Automate: You can also use DTCs in scripts to e.g. trigger events (e.g. e-mailing data or scheduling maintenance)
• Train: The DTC information can be used to label 'issue states' in your data at scale for training predictive AI algorithms

Simple/advanced use of diagnostic trouble codes

Note that the use of diagnostic trouble codes in your predictive maintenance model will probably differ based on the issue you're trying to predict and your sophistication level.

For simple use cases, it may suffice to monitor the DTC information in near real-time and reacting swiftly upon them. In such a case, your predictive maintenance model is basically outsourced to the vehicle's existing diagnostic solution.

For more advanced applications, you'll probably instead aim to predict the issues that would trigger a DTC - before the DTC is actually triggered. Here, collecting raw CAN bus data signals (speed, temperatures, SoC, pressure variables etc) together with DTC information over longer periods can help in determining correlation patterns.

To make the 'prediction' in predictive maintenance more clear, consider the below practical examples:

Example #1 - The Oil-Sensitive Truck: In this Google Sheets illustrative example we consider a vehicle where the only possible failure is from not refilling the oil. Over time, the oil level decreases to 10% and the vehicle breaks down - i.e. the 'Remaining Useful Life' (RUL) is zero. For simplicity, we pretend that we observe the true RUL and adapt a simple linear regression. With this we predict the RUL out-of-sample and decide a time for warning - which in the example is ~17% off vs. the true RUL. You can copy and try the example yourself.

Example #2 - NASA Turbofan Engine: We strongly recommend reading this practical intro by Ben Everson. In short, he takes outset in NASA's 2008 Turbofan Engine Degradation simulation data set), which contains training & test data on 10 engines equipped with 20+ sensors. The goal is similar to Example #1, but in a more realistic context. In particular, this is helpful if you're about to get started with the basic data cleaning & statistical considerations. Check out both his intro and follow-up!

As established, predictive mainteinance can yield massive benefits - in particular within vehicle fleet management. Despite this, few fleet managers have implemented any form of predictive maintenance for a number of reasons:

• Lack of CAN data: Most vehicle fleet telematics solutions only monitor GPS data with limited predictive applications
• Proprietary CAN data: While a lot of data is often accessible via OBD2/UDS/J1939/FMS, critical data may be proprietary
• No requests: DTCs are often key to predictive maintenance, but most telematics devices do not enable request of these
• Reactive data usage: Some vehicle fleets do record FMS/J1939 data, but only use it reactively (e.g. to track fuel usage)
• System lock-in: The under-utilization of data is often linked to vendor lock-in and restrictive outdated telematics platforms

The CANedge2 is ideal for fleet management solutions where access to CAN data is required. It lets you record all the raw CAN data and auto-push it to your own server. Here, you'll be able to decode the data via DBC files, which makes it flexible in case you e.g. later need to added additional parameter decoding rules (for example from reverse engineering efforts).

Further, the CANedge software/API tools are 100% free and designed for interoperability. This means your team can start small and gradually increase the sophistication level of your predictive maintenance solution - while ensuring zero vendor lock-in.

To learn more about using the CANedge2 for predictive maintenance fleet management, contact us.

The 'prediction' examples illustrate that adding more data quickly adds complexity. For this reason, using machine learning (ML) has become popular in predictive maintenance models.

Machine learning is a natural fit as predictive maintenance involves failure classification using huge amounts of sensor data. We won't dive deeper into this here, but consider reading this InfoQ technical intro or this Azure AI article using the NASA Turbofan data with ML.

Further, if you're interested in a bit more detail on the predictive models for PdM, check out this article by BigData Republic - it's a great read, in particular to provide context for the RUL modelling strategy in the 'prediction' examples above.

The key to begin your predictive maintenance journey is to start small. Below we provide 9 steps to get started:

1. Identify a pain point: select an asset that is known to break down regularly and is based on CAN bus
2. Set a team : Dedicate 1-3 persons to implement the PoC, including one with expertise on interfacing with the asset
3. Define a prediction model: Identify which failure you'll predict and set up a basic model (e.g. based on parameter thresholds)
4. Source IoT device: Get 1-2 CANedge2 units to test the basics (logging raw data, decoding it via a DBC, setting up WiFi/server)
5. Start collecting: Install the CANedge2 and establish a basic data collection flow to your server
6. Train the model: Based on incoming data (incl failure data), "train" your model (e.g. adjusting parameter thresholds manually)
7. Predict 1st breakdown: With your basic model in place, the next step is to actually predict a breakdown before it happens
8. Add reaction: Set up a basic reaction flow - e.g. set your script to trigger an email if an issue is predicted
9. "Sell" solution: Present the proof of concept & results internally to get the buy-in and funding to scale-up

Yes - we work with several end users that deploy various forms of predictive maintenance in practice. As such, we're happy to provide free sparring on your specific use case. Just contact us to set up an initial conference call.