Vehicle Health Monitoring and Predictive Maintenance

1. Problem Statement

Think about a perfectly normal day of your life. You are following all of your daily routines, happily and then suddenly you have a "heart attack". When you gain consciousness you are already in an operation theater surrounded by doctors in the green gown with a mask on their face, ready to operate. You found out that there are multiple blockages in your artery and you have to spend some significant time in the ICU after this life-threatening operation. Scared? The same thing happens ( not exactly the same ;-) ) with your vehicle when there is a surprise breakdown. If you are a vehicle fleet manager then these frequent surprise breakdowns can cost you some serious heart attacks ( seriously ). Even if the operator carries out scheduled maintenance and regularly repaired parts to prevent downtime. In addition to consuming unnecessary resources and driving productivity losses, half of all preventive maintenance activities are ineffective. This problem is not only for vehicles, but it is also for all machines.

2. Solution: Predictive Maintenance

This is a serious problem and its impact can be reduced by predictive maintenance. When the impact of a failure cannot be afforded, such as a malfunctioning airplane engine, for example, the machine is subjected to preventive maintenance, which involves periodic inspection and repair, often scheduled based on time-in-service. The challenge of proper scheduling grows with the complexity of machines: in a system with many components working together and influencing each other’s lifetime, how can we find the right moment when maintenance should be performed so that components are not prematurely replaced but the whole system still stays functioning reliably? Providing an answer to this question is the aim of predictive maintenance, where we seek to build models that quantify the risk of failure for a machine at any moment in time and use this information to improve scheduling of maintenance.

This is where Azure Sphere can help us. It can efficiently gather the data via its low-level communication protocol, for example, I2C and UART and can securely send the data to the Microsoft Azure for predictive maintenance. It also has enough horsepower to be used as an edge device in future development.

3. Why Azure Sphere?

You must be wondering, why Azure Sphere and why not any other microcontroller, for example, Arduino or Raspberry Pi? The primary reason for selecting Azure Sphere is security. Azure Sphere provides high-level security at a low cost and also follows the seven properties of the highly secured devices.

We care about our privacy( If you do not then you should ) because in this connected and constantly ad serving world our data can be used against ourselves. The same goes for our vehicles. They are also part of our life and its diagnosis data can be as important as our health data for advertisement servers. It needs to be protected at all costs.

There are many other reasons for choosing Azure Sphere which I have listed below.

• Ease of integration with Microsoft's Azure cloud services.
• 10 years of security update by Microsoft.
• Enough horsepower to handle future resource-hungry development.
• Ease of development and debugging, thanks to visual studio.

4. How it works

The circuit diagram or schematic is pretty simple. The OBD-II module is connected to the OBD ( On Board Diagnosis ) port of the vehicle and it talks to the Azure Sphere via UART protocol. The Azure Sphere then converts the data coming from the OBD-II module to human-readable form and send it to the IoT Central of Microsoft Azure cloud service.

The Azure Sphere uses the PIDs ( Parameter IDs ) to talk to the OBD-II module. When the OBD module reply, it needs to be converted into the human-readable form using specific formulas. Once converted the data is arranged in the { key: pair } format and send to the IoT Central. The template used for creating IoT central should know which { key: pair } to look for and when it finds one it immediately registers it for further processing. Once the data is registered in the IoT central, we can view it in realtime using our custom dashboard. The data is then ingested into the ML/AI toolbox to actually make sense of it and deliver useful prediction ( Currently this part is not yet implemented as my free subscription to Microsoft Azure expired ).

This design is not just limited to one vehicle. It can be easily implemented at scale, for a fleet of vehicles. Not only vehicles, but this idea/design can also be applied to other machines where security and predictive maintenance is a priority. The azure sphere integrated with IoT central makes this solution scalable. The same build provided by a developer can be used to connect multiple devices to the IoT Central using DPS (Device Provisioning Service), a service provided by the Microsoft Azure cloud platform.

Let's get started and make this project. Please follow the next segment of this tutorial to set up the Azure Sphere module.

5. Make Azure Sphere up and ready

Azure Sphere is not a super easy thing for getting started, at least not for beginners. You might need to perform some necessary steps even before you run a blink program. Thankfully there are some remarkable documents and video guides available to get you started. I am listing down some of my findings.

• https://azure.microsoft.com/en-in/services/azure-sphere/get-started/
• https://www.hackster.io/workshops/azure-sphere-course
• https://www.element14.com/community/groups/azuresphere/blog/2019/09/30/project-part-1-getting-started-with-microsoft-azure-guide-and-a-simple-azure-sphere-sensor-project

There is a possibility that as Microsoft extends development, the 3rd party documents might not provide the correct information. Prefer Microsoft's official document when the information/steps mismatch with the 3rd party document.

Make sure everything is up and ready by running the Blink Application.

• https://docs.microsoft.com/en-us/azure-sphere/install/qs-blink-application

6. Setup the OBD-II module

Note:The OBD-II module I have used here communicates using Bluetooth, which is a weak spot in this secure project. I bought this model as it was cheap and I could afford it. I thought of modifying it by bypassing the Bluetooth chip and directly connecting the UART pins with the UART port of Azure Sphere. Unfortunately, this model uses a Chip-On-Board IC which makes it extremely difficult to find the correct pins given the time constraint. So I went ahead with the Bluetooth approach.If possible please use the physical medium to connect the OBD-II module with the Azure Sphere.

Let's proceed with setting up this module. Setting up this module is very easy. You just need to find the OBD port of your car and plug this module into it. That's it.

7. Setup the Bluetooth module (HC-05) into Master role

Note:If you are using physical medium between Azure Sphere and OBD-II module then please skip this step.

We need to change the role of the HC-05 into master so that it can connect with the OBD-II module automatically as soon as it is powered up. The Bluetooth connection requires one master and one slave. The master initiates the pairing and linking request. Once the pairing is done the modules will communicate with each other irrespective of their role.

In this case, the HC-05 connected with the Azure Sphere will act as a master and will initiate the linking request to connect to the slave i.e. OBD-II module.

The default role of the HC-05 is a slave and to set it as a master, please follow the below steps.

• Connect the Bluetooth module with the PC using an FTDI module. Please refer below image for reference. Apply +5v to the KEY pin of HC-05 to put it in the AT command mode.

• Obtain the Bluetooth address of the OBD-II module. It will be useful while configuring the HC-05 module. For our reference, let us assume the address of the OBD-II module is 12:34:56:78:9a:bc
• Once the setup is complete, use any serial terminal program for example "CoolTerm" to configure the module. Set the baud rate of the serial communication software as 38400. Send below listed AT commands one by one to configure the HC-05 to act as a master.

1. AT+RESET (Reset the device)
2. AT+ORGL (Apply default configuration)
3. AT+ROLE=1 (Set role as Master)
4. AT+CMODE=0 (Force the device to connect with specific address)
5. AT+BIND=1234,56,789abc (Force to connect to this address, only useful if CMODE = 0)
6. AT+INIT (Initialize SPP profile)
7. AT+PAIR=1234,56,789abc,20 (last 2 digits mean 20 second timeout)
8. AT+LINK=1234,56,789abc

8. Connect the Bluetooth/OBD-II module with the Azure Sphere

• If you are using a physical medium to connect the OBD-II module with Azure Sphere then directly connect the Rx, Tx, GND pins of the OBD-II module with the Tx, Rx, and GND pins of Azure Sphere respectively.

• If you are using Bluetooth as a communication medium between the OBD-II module and Azure Sphere then please connect the HC-05 module with the Azure Sphere.

Note 1: Do not forget to provide GND to the KEY pin of the HC-05. This will set HC-05 in the data communication mode.

Note 2: Please use PORT 1 of the Azure Sphere for this connection. If you are planning to use PORT 2 then you also have to make changes in the code.

9. Software

The code for this project is hosted on Github platform. Please clone/download the code from this repository.

10. The Cloud ( Basically, someone else's computer )

Azure Sphere is a wonderful cloud platform but using it standalone without the Microsoft Azure is like driving a Tesla without its autopilot feature, it won't be fun. Microsoft Azure provides a whole new dimension of visualization, control, and features which might not be possible by using Azure Sphere only.

The IoT central feature of Microsoft Azure is one of the best services I have used. It is a Software-as-a-Service (SaaS) offering from Microsoft. Microsoft has made it extremely easy to connect your devices to its platform that too without any coding required. It also provides Cloud to Device(C2D) features for controlling devices via the cloud. It can be used to display telemetry data, create alerts, execute commands, and to create your own dashboard too.

In this project, I have used the template provided by Avenet Technical Training Course to design my IoT central Dashboard. It displays the telemetry data like coolant temperature, engine RPM and Throttle position on the dashboard. This template can also be used to control the device via the "settings" tab.

You can download the template by referring to the documents provided in this Azure Sphere Technical Training course. I would suggest completing this training as it is going to be extremely helpful and also it is free of cost. If you are aware of IoT Central and just want the template then please follow this link.

The fun part doesn't stop here. You can use all the data uploaded to the IoT Central to predict the potential breakdown that can happen in your vehicle and carefully plan the servicing even before it happens. This way not only you will save a lot of money but also reduce the vehicle downtime and plan better.

Microsoft Azure provides a ton of services, from IoT hub to machine learning and AI to Analytics and many more. Even the sky is not the limit for what you can do by utilizing the services provided.

11. Final Assembly

The above image represents the test environment. In the test environment, the laptop provides the power and debug environment to the device. In the final setup, the device will receive its power from the car. While testing, exercise safety at all costs.

Clone the code from here if not already done and flash it onto the board. Once the code is flashed, it will start displaying the output in the "device output" tab of the visual studio.

• If the device is connected successfully to the IoT central then the output should look like the above image. The output shows that the device is successfully provisioned by the Device Provisioning Service( point 1 ) and then it is connected to the IoT Central successfully( point 2 ).

• The above image shows the output when the device successfully uploads the telemetry data to the IoT Central. It can be seen that data is arranged in the { key: pair }. It also shows the confirmation received by the IoT Central.

If the output of your device is similar to the above images then you can say than the connection is established successfully and Azure Sphere is properly reading data from the OBD-II module and uploading it to the IoT Central.

When testing is complete, place the device in a case that will protect it and make it look clean.

Open Source is LOVE. Happy Making :-)