An IoT Based Predictive Connected Car Maintenance Approach

— Internet of Things (IoT) is fast emerging and becoming an almost basic necessity in general life. The concepts of using technology in our daily life is not new, but with the advancements in technology, the impact of technology in daily activities of a person can be seen in almost all the aspects of life. Today, all aspects of our daily life, be it health of a person, his location, movement, etc. can be monitored and analyzed using information captured from various connected devices. This paper discusses one such use case, which can be implemented by the automobile industry, using technological advancements in the areas of IoT and Analytics. ‘Connected Car’ is a terminology, often associated with cars and other passenger vehicles, which are capable of internet connectivity and sharing of various kinds of data with backend applications. The data being shared can be about the location and speed of the car, status of various parts/lubricants of the car, and if the car needs urgent service or not. Once data are transmitted to the backend services, various workflows can be created to take necessary actions, e.g. scheduling a service with the car service provider, or if large numbers of care are in the same location, then the traffic management system can take necessary action. ’Connected cars’ can also communicate with each other, and can send alerts to each other in certain scenarios like possible crash etc. This paper talks about how the concept of ‘connected cars’ can be used to perform ‘predictive car maintenance’. It also discusses how certain technology components, i.e., Eclipse Mosquito and Eclipse Paho can be used to implement a predictive connected car use case.

T he automobile and fleet management industries, majority of the consumers and the car service companies are following the 'periodic maintenance' for their automobiles. In periodic maintenance, car owners are advised to take their cars for regular service and maintenance either after certain specified time period or distance covered. For example, it is generally advised to get car serviced within three months of the last service date or after travelling 10000 kilometers, whichever comes first. Another instance where the car can be taken out for emergency service/maintenance is after some breakdown or malfunctioning of any part in the vehicle.
The way periodic maintenance works, is depicted in Fig. 1. [15] A. Periodic Car Maintenance Fig. 1 summarizes Periodic car maintenance. It can be explained as a service/maintenance model, where a car undergoes a service/ maintenance either after a certain specified time period or on the basis of distance covered, e.g. as shown in Fig. 1, during the lifetime of a vehicle, regular services are carried out, as advised by the car manufacturer. Similarly, a car can be serviced/repaired, if there is any of the part gets faulty. [15] Some of the major drawbacks of periodic car maintenance are listed below:

B. Drawbacks of Periodic Car Maintenance
• Higher cost of service, as vehicles are required to be get serviced as per the schedule • Even if vehicle/parts are in perfect health, still service needs to done and parts to be replaced

II. alTeRnaTe appROach TO peRIOdIc caR maInTenance
Instead of getting a car serviced periodically, if a system developed using sensors and IoT [9] technology stack is used, which collect and analyze fitness and running condition of different parts of the car, and send this data to a centralized system. In this centralized system, data received from these connected cars, can be analyzed further and if any service is needed, a service request can be raised. This proposed system can also generate emergency alerts, in case any part is about to break down, thus avoiding car/part failure [15] [17] A. Advantage of Proposed system [18] • Reduction in service and maintenance costs, as only parts which needs to be replaced or serviced A common practice, generally followed in automobile world is 'periodic car maintenance'. In this, the car is supposed to undergo periodic service and maintenance routine. When to get a car serviced, is generally decided by either a specified time period or distance covered. For example, it is generally advised to get the car serviced within six months of the last service date or after travelling 10000 kilometers, whichever happens first. Now, the problem with 'periodic car maintenance' is that nobody is sure if any part or lubricants really needs to be serviced/replaced. This normally leads to parts/lubricants, which are in good condition, getting changed/serviced. Another problem, which is generally faced is that though scheduled 'periodic car maintenance' is still some time away, there is some problem with a part, which needs immediate attention. 'Periodic car maintenance' cannot solve this problem, and only way to know about this is after break down. So, two problems, associated with this model of car servicing can be summarized as: • Higher service costs, as parts which are fine, will also be replaced • Unable to generate any alert, if any part needs immediate attention/ service, resulting in breakdown/outages This is where 'Connected Cars' and 'Predictive car Maintenance' can help [15] [16]. Connected cars can collect data, from different sensors installed in the car, related to the health status of different parts, and send it over the internet to backend applications, for analytical and decision making purposes. One of the backend analytical application, based on the health status of different parts, can invoke a workflow and schedule an appointment with the service provider, if some part needs immediate attention. Similarly, real time alerts can be sent to concerned parties, in case something need immediate attention.
This can result in considerable savings in terms of service and maintenance charges of the car [18]. Now, only the parts which actually need replacement, will be serviced. This data will be collected and transmitted by different sensors fitted on the car for performing health check of different parts oil health check, tire and pressure health check, filters health check and so on.

IV. hOW ThIs WORk dIffeRs fROm OTheR WORk dOne In ThIs aRea
Good amount of research work is done on the Predictive maintenance topic [1][4] [6]. Some of the work talk about how to collect or read sensor data (from cars, from manufacturing industrial machines etc.), or propose a model to perform predictive analysis and so on [2] [3] [5] [7]. This work proposes an IoT based approach [15] to collect this data, send it to the cloud and perform predictive analytics on this huge amount of data. The proposed approach is based on industry proven protocols and products, some of which are Eclipse IoT's [11] Eclipse Mosquitto [13], Eclipse Paho[12] and MQTT [10] protocol. High level IT architecture is also provided, so that same can be referenced by people to build, extend and further improve the system based on this architecture.
Finally, a simulation of the proposed architecture model is also given, where a client GUI utility simulates the car sensor, and sends data to the cloud.

V. pROpOsed TechnOlOgy fOR ImplemenTIng pRedIcTIVe cOnnecTed caR maInTenance
This section introduces some of the important technology components, which will be used in the proposed implementation of 'Connected car' use case for predictive maintenance.

A. MQTT Protocol
Message Queue Telemetry Transport (MQTT) is a light-weight messaging protocol based on publish-subscribe model. MQTT uses a client-server architecture where the client (such as a sensor device on cars) connects to the MQTT server (called a broker) and publishes messages to server topics. The broker forwards the messages to the clients subscribed to topics. MQTT is well suited for constrained environments where the devices have limited processing and memory resources and the network bandwidth is low.

B. Deeper look into MQTT
MQTT is an extremely lightweight messaging protocol. Its publish/ subscribe architecture is designed to be open and easy to implement. Single MQTT server can support up to thousands of remote clients. These characteristics make MQTT ideal for use in constrained environments where network bandwidth is low or remote devices that might have limited processing capabilities and memory, need to be supported. The MQTT protocol is based on publish/subscribe model. Publishers can send the messages to the topics, configured on the MQTT server (also called MQTT broker). Clients can subscribe to these topics and receive whatever messages are published on those topics.

Fig. 2 depicts the publish/subscribe model of MQTT
Though MQTT's publish-subscribe model is identical to any existing enterprise messaging systems, the main advantage of MQTT has over fully blown "enterprise messaging" systems are that its low footprint makes it ideal for developing IoT applications with small sensors, devices and other low-capacity things. For example, Facebook uses MQTT for its messenger product on the mobile platform, to ensure that battery usage of this application is minimized.

C. Eclipse Mosquitto
Eclipse Mosquitto is an open source MQTT broker/server. Based on the lightweight MQTT protocol, Mosquitto is ideal for devices, sensors and other 'Internet of Things' devices, with low processing capacity. MQTT clients can connect to a given Mosquitto broker and publish/ subscribe the messages from a topic.
Eclipse Mosquitto's main responsibility is to provide a communication channel between publishers/senders and subscribers/ receivers. Any publisher, using the Eclipse Paho MQTT Client API can publish the messages to an MQTT Broker. These MQTT clients should specify the topic, on which they want to publish the message. These topics are configured on MQTT broker. Any subscriber or receiver, that want to receive the message, subscribe to that particular topic. It is the responsibility of the broker to deliver all the messages arriving on a topic to all interested clients. As different clients (both publishers as well as subscribers) need to know only broker/topic details, both are decoupled from each other. This architecture pattern has many advantages, e.g. highly scalable solution, where subscribers needn't to be overwhelmed by publishers sending messages at a rate faster than what a subscriber can process.

D. Eclipse Paho
Eclipse Paho is an EclipseIoT project and is implementation of MQTT protocols. Eclipse Paho provides MQTT client libraries in multiple languages including Java/C++, C#, .NET and Python. Eclipse Paho also has utilities for MQTT-SN (sensor networks). Both publishers and subscribers (as shown in Fig. 2) can use API's provided by Eclipse Paho MQTT Client library, and send/receive messages to/ from MQTT broker (e.g. Eclipse Mosquitto).

VI. Why mQTT and OTheR pROpOsed TechnOlOgy cOmpOnenTs In cOnnecTed caR ImplemenTaTIOn
• Suitable for low capacity devices like sensors fitted on connected cars • Provides Quality of services to handle connectivity and other errors, which can be quite common in the case of cars and automobiles, which are on the move, and n/w connectivity can be an issue • Supports wide variety of languages, so compatibility will not be an issue for any existing technology platform of a car manufacturer • Also integrated with proven and well adopted industry leading messaging systems like WebSphere MQ and ActiveMQ • Message formats can be customized, allowing manufacturer to customize and innovate the solutions Details of MQTT protocol and its specification can be found on the MQTT site, given in the reference section.

VII.
pROpOsed aRchITecTuRe Of 'pRedIcTIVe caR maInTenance' usIng eclIpse mOsQuITTO and eclIpse pahO Fig. 3 shows the simplistic high level architecture context diagram of a system implementation of 'predictive car maintenance' using Eclipse Mosquitto and Eclipse Paho.
Flow of context diagram (Fig. 3) can be explained as follow: • 'Connected Cars' send data in predefined format to IoT Gateways like Eclipse Kura.
• Cars can use any possible way to send the data, i.e. via Wi-Fi, Telco services etc.
• IoT Gateway would send this data to MQTT based Eclipse Mosquitto Broker hosted in a cloud environment • In many scenarios, there can be additional components like coordinator/controller nodes in the architecture, which do some kind of pre-processing/aggregation of data collected from various devices, before sending it to the cloud • Once data is received by Eclipse Mosquitto, subscribers will receive this message, using Eclipse Paho API • After doing basic validations and any data conversion, subscribers can send this message to downstream systems, using services exposed by the Data Integration component of the architecture • It could be that these messages are sent to a messaging system, e.g. Apache Kafka, where these messages can be consumed by the workers • These workers can push these messages to Apache Hadoop or other such data processing service, for analytical purpose • These messages can also be consumed by data processing services, handling real time stream of messages e.g. Apache Storm • These real time stream of messages can be used for real time analytics purpose e.g. sending alerts in case something needs immediate attention 'Workflow' component can be used to define and execute different workflows, based on some conditions For example, to schedule a service appointment, invoke a REST based service of the car service provider, in case some parts need to be replaced.
There can be various visualization tools to view reports of summarized data and perform analytical queries. Note that, in real life complex scenarios, there can be many more components involved in the architecture (e.g. configuration services, policy manager, rule engine and so on), but for simplicity's sake, those have not been included in this paper.

VIII.
sample ImplemenTaTIOn Of pRedIcTIVe caR maInTenance use case WITh eclIpse mOsQuITTO and eclIpse pahO clIenT uTIlITy In this section will use Eclipse Paho Client utility to simulate a connected car, which will send city where the car is (can send exact location also), speed and current car health check, including if any part needs to be replaced or not.
In the real world, devices like connected cars might be sending data first to a IoT gateway, as shown in architecture diagram in Fig. 3 in last section, where this data will be processed and aggregated, before being fed to further downstream applications. Depending upon the actual requirement, applications can be designed to take appropriate actions based on the data being received e.g. Send alerts if speed is too high or schedule an appointment with the car service agency, if some part/ lubricants needs to be replaced.
Sample format of the MQTT message, transmitted by sensor fitted on the car is shown on Fig. 5. Some of the information, which can be sent by the connected car is shown in Table 1. In this paper, we will be simulating the behavior of connected car, using Eclipse Paho MQTT Utility, a Java Swing based GUI application, to connect to a Mosquitto server, publishing message to a topic on Mosquitto server. The client will receive this message and for simplicity, will display this message content in the GUI.
Once the utility is launched, screen as shown in Fig. 6 will appear. Specify the address of the MQTT Mosquitto server and port and connect to the server. We are using a cloud based test Mosquitto server, available for public, at the address "test.mosquitto.org", port 1883.
After specifying the address, click "Connect". If everything goes right, you will be connected to server, else you will get error message.
Once connected, enter the name of the topic, and click subscribe. Now, any message, published on this topic will be displayed in the text area of the subscriber. Fig. 7 shows a subscriber, connected to a topic named 'CarHealth'.    Enter the message payload in the 'Publish Messages -text display' area and click publish. Fig. 8 shows the step to publish a message onto MQTT topic.
Once the message is published, all clients who have subscribed to this topic, will receive this message. In our scenario, this will be displayed in the utility GUI. Fig. 9 shows the scenario of a subscriber receiving the message.

Ix. cOsT benefIT Of pRedIcTIVe caR maInTenance
Predictive car maintenance can help address the issues of traditional periodic car maintenance approach. Some of the advantages it provides are • Reduction in service and maintenance costs, as only parts which needs to be replaced are serviced • Target advertisements for monetization of data received from connected cars (e.g. offering service discounts for car which needs to be serviced etc.) Table 2 shows the cost comparisons of periodic vs predictive maintenance for a medium sedan car. Periodic service cost figures are taken from a leading automobile web site (see reference). As most of the car vendors provide first two services as free services, zero cost is taken for these two services. For predictive maintenance, it is assumed that service cost will go down by 30%. Sample calculation for 3 rd service is as follow Cost of 3rd periodic service -2465 INR [21] Cost with predictive maintenance with 30% saving = 2465 *((100-30)/100) = 1726 INR Fig. 10 represents another view of the service cost comparison data of Table 2. During the first eight services (scattered across 5 years) of the car, total costs incurred on periodic maintenance is 29500 INR. This cost will come down to 20653 INR (assuming 30% reduction in service cost), with the help of predictive car maintenance.
To understand the outage costs of a fleet/transport organization, let us take an example of a company with a fleet strength of 100 cars. If a car of such commercial organization is out of service because of breakdown or faulty part, there will be various costs associated with it e.g. pay for an unutilized driver and support staff, rental of the car for that day, fixing and service cost, need to ensure alternate vehicle for the customer to ensure company's commitment, else loses on reputation part in the consumer market and so on.
Assume that the total outage cost for one vehicle going out of service is Rs. 5000 per day. So, for a company with one vehicle out of service, associated costs can be calculated as follows  Table 3 shows the outage cost per year for multiple number of vehicles going out of service on a given day. For a company with a fleet size of 100, number of vehicles going out of service can be much higher, but for simplicity, table 3 shows costs for maximum three vehicles going out of service.  Fig. 11 represents another view of the outage/breakdown cost data of Table 3. Assuming that per day cost of a vehicle going out of service is 5000 INR. As shown, on average with only one vehicle out of service, cost per year is 1.8 million INR and with three vehicles going out of service, this will increase to 5.4 million INR per annum.   Table 4 shows the outage cost comparison with 30% improvement in outage scenarios.
Original Outage cost of 1 vehicle out of service = 1825000 Rs ( B) Cost after 30% improvement in outage situations = 1825000 * ((100-30)/100) = 1277500 Rs.  Fig. 12 represents another view of the outage/breakdown cost comparison data of Table 4. Even 30% assumed reduction in downtime will provide considerable savings for the organization. For three vehicles out of service, cost of breakdown will come down from 5.4 million INR to 3.8 million INR. Fig. 13 depicts a sample portal/dashboard to view the status of a given car. Any authorized person can view, whether any part needs replacement or not, current status of different parts, historical information, including details of any alert that was sent.
For example, the second row in this dashboard shows that an alert was raised for a particular part. Though the current value of this part is within a valid range (between 0-1), but as it is almost on the threshold to breach the value, a pro-active alert was sent, thus avoiding any possible outage and associated costs This dashboard can also be used to trigger additional workflows. For example, a request to book a service appointment with the car service provider can be raised using this portal.
x. challenges In The pRedIcTIVe maInTenance Of cOnnecTed caRs Some of the challenges in successful implementation of predictive maintenance and connected cars are as follows [ xI. cOnclusIOn 'Connected car' concept is getting lots of traction with automobile companies these days. There are multiple benefits of 'Connected Car' ecosystem, and one such benefit is Predictive Car Maintenance. This paper talked about what predictive car maintenance is all about, which problems it could solve. MQTT, a popular protocol for IoT is also discussed, followed by an introduction to Eclipse Mosquitto and Eclipse Paho, an implementation of MQTT. This paper also presented a high level architecture of how Connected car use can be implemented, using Eclipse Paho and Eclipse Mosquitto. A simulation of 'connected car' sending sensor's data to the cloud is also discussed. Finally, cost saving of a predictive car maintenance system over a traditional periodic car maintenance system is shown. This paper concluded by sharing of some of the challenges in implementing predictive maintenance of connected cars.