DE

GR

EE

THESIS

Computer Science & Engineering, 180 credits

Indirect Tire Monitoring System - MachineLearning Approach

Oskar Svensson, Simon Thelin

Degree Project in Computer Engineering, 15 credits

Helsingborg 2017-06-21

Abstract

The heavy duty vehicle industry has today no requirement to providea tire pressure monitoring system by law. This has created issues sur-rounding unknown tire pressure and thread depth during active service.There is also no standardization for these kind of systems which meansthat different manufacturers and third party solutions work after theirown principles and it can be hard to know what works for a given vehicletype. National Highway Traffic Safety Administration (NHTSA) put outa new study that determined that underinflated tires of 25% or less are3 times more likely to be involved in a crash related to tire issues versusvehicles with properly inflated tires.

The objective for this thesis is to create an indirect tire monitoring sys-tem that can generalize a method that detect both incorrect tire pressureand thread depth for different type of vehicles within a fleet without theneed for additional physical sensors or vehicle specific parameters. DrivecBridge hardware interprets existing sensors from the vehicle.

By using supervised machine learning a classifier was created for eachaxle where the main focus was the front axle which had the most issues.The classifier will classify the vehicles tires condition. The classifier willbe implemented in Drivecs cloud service and use data to classify thetires condition. The resulting classifier of the project is a random for-est implemented in Python. The result from the front axle with a dataset consisting of 9767 samples of buses with correct tire condition and1909 samples of buses with incorrect tire condition it has an accuracy of90.54% (± 0.96%). The data sets are created from 34 unique measure-ments from buses between January and May 2017.

The developed solution is called Indirect Tire Monitoring System (ITMS)and is seen as a process. The project group has verified with high accu-racy that a vehicle has been classified as bad and then been reclassified asgood over a time span of 16 days. At the first day offboard measurementswere performed and it showed that the tires of the front axle were under-inflated. The classifier indicated that the vehicle had bad classificationsuntil day 14. At this day an offboard measurement was performed and itwas concluded that they were no longer underinflated and the classifierindicated this as well. To verify the result the workshop was contactedand verified that the vehicle had changed tires of the front axle at day14. This has verified that the classifier is able to detect change and stayconsistent in the results over a longer time period.

ii

AcknowledgementsThis thesis is the result of a bachelor degree project done during thespring term 2017 for Drivec AB. The thesis is the final moment of oureducation as computer science engineers.

We would like to thank Johan Göthe and the rest of the team at Drivec forthe opportunity and the generous support throughout the whole project.

We would also like to thank our supervisors Stefan Byttner and YuantaoFan for their guidance and expert knowledge in machine learning.

Oskar Svensson & Simon ThelinHelsingborg 2017

iv

ContentsAcknowledgements iv

List of Acronyms x

1 Introduction 11.1 Purpose and goal . . . . . . . . . . . . . . . . . . . . . . 11.2 Question at issue . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1 Background and theory . . . . . . . . . . . . . . . 21.2.2 Educational phase . . . . . . . . . . . . . . . . . 21.2.3 Delimitations . . . . . . . . . . . . . . . . . . . . 3

2 Background 52.1 Current industrial solutions . . . . . . . . . . . . . . . . 5

2.1.1 Fleet management . . . . . . . . . . . . . . . . . 52.1.2 Fleet management system integration . . . . . . . 62.1.3 Vehicle health - Warnings . . . . . . . . . . . . . 72.1.4 Direct TPMS . . . . . . . . . . . . . . . . . . . . 82.1.5 Indirect TPMS . . . . . . . . . . . . . . . . . . . 9

2.2 Data driven monitoring . . . . . . . . . . . . . . . . . . . 92.3 Industrial relation . . . . . . . . . . . . . . . . . . . . . . 112.4 Industrial communication . . . . . . . . . . . . . . . . . 12

2.4.1 CAN . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.2 SAE J1939 . . . . . . . . . . . . . . . . . . . . . 132.4.3 PGN . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.4 SPN . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5 Supervised machine learning . . . . . . . . . . . . . . . . 14

3 Methodology 153.1 Project phases . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 Education phase . . . . . . . . . . . . . . . . . . 153.1.2 Visualization phase . . . . . . . . . . . . . . . . . 153.1.3 Implementation phase . . . . . . . . . . . . . . . 15

3.2 Project design . . . . . . . . . . . . . . . . . . . . . . . . 163.2.1 Implementing scrum . . . . . . . . . . . . . . . . 16

3.3 Supervised machine learning methods . . . . . . . . . . . 173.3.1 Support vector machine . . . . . . . . . . . . . . 173.3.2 Random forest . . . . . . . . . . . . . . . . . . . 193.3.3 k-nearest neighbor . . . . . . . . . . . . . . . . . 213.3.4 Critical motivation . . . . . . . . . . . . . . . . . 22

3.4 Software tools . . . . . . . . . . . . . . . . . . . . . . . . 223.4.1 WEKA . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5 Version control . . . . . . . . . . . . . . . . . . . . . . . 233.5.1 Git . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.6 Data management . . . . . . . . . . . . . . . . . . . . . . 233.6.1 Offboard measurements . . . . . . . . . . . . . . 233.6.2 AI-stats . . . . . . . . . . . . . . . . . . . . . . . 243.6.3 Filtering . . . . . . . . . . . . . . . . . . . . . . . 24

3.7 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.7.1 Scikit-learn . . . . . . . . . . . . . . . . . . . . . 253.7.2 Setting targets . . . . . . . . . . . . . . . . . . . 253.7.3 Training and evaluation of algorithm . . . . . . . 25

3.8 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . 263.8.1 Node.js . . . . . . . . . . . . . . . . . . . . . . . 263.8.2 Cloud . . . . . . . . . . . . . . . . . . . . . . . . 273.8.3 Mocha . . . . . . . . . . . . . . . . . . . . . . . . 28

3.9 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.10 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Results - Supervised Machine Learning 314.1 Data management . . . . . . . . . . . . . . . . . . . . . . 31

4.1.1 Offboard data . . . . . . . . . . . . . . . . . . . . 314.1.2 CAN bus data . . . . . . . . . . . . . . . . . . . . 31

4.2 Analysis of data . . . . . . . . . . . . . . . . . . . . . . . 324.2.1 WEKA . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4 Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.5 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.6 Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.6.1 Optimization . . . . . . . . . . . . . . . . . . . . 424.6.2 Export of classifier . . . . . . . . . . . . . . . . . 47

5 Results - Cloud Implementation 495.1 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2 Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.3 Data management . . . . . . . . . . . . . . . . . . . . . . 505.4 Data structures . . . . . . . . . . . . . . . . . . . . . . . 515.5 Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.5.1 Data structure . . . . . . . . . . . . . . . . . . . 525.5.2 Threshold . . . . . . . . . . . . . . . . . . . . . . 535.5.3 Warning rate . . . . . . . . . . . . . . . . . . . . 535.5.4 Create new incidents . . . . . . . . . . . . . . . . 535.5.5 Update existing incidents . . . . . . . . . . . . . . 535.5.6 Reset incidents . . . . . . . . . . . . . . . . . . . 54

5.6 Unit tests . . . . . . . . . . . . . . . . . . . . . . . . . . 54

vii

5.6.1 Deployment . . . . . . . . . . . . . . . . . . . . . 545.7 Output classifier - Real case scenario . . . . . . . . . . . 555.8 Summary process . . . . . . . . . . . . . . . . . . . . . . 60

6 Discussion 61

7 Conclusion And Perspectives 637.0.1 Requirements for technical product development . 64

7.1 Future optimization . . . . . . . . . . . . . . . . . . . . . 65

8 References 67

A Offboard Measurements 71

B Time Table 77

viii

List of AcronymsCAN - Controller Area Network

GPS - Global Positioning System

SAE - Society of Automotive Engineers

J1939 - Recommended Practice for a Serial Control and CommunicationsVehicle Network

ABS - Anti Brake System

Direct TPMS - Direct Tire Monitoring System - Sensor inside tires whichmeasures pressure in real time

Indirect TPMS - Indirect Tire Monitoring System - No sensors, differ-ence in pressure could be acquired from ABS-sensors or other sources

ITMS - Indirect Tire Monitoring System - No sensors, difference in bothtire pressure and tire depth, project group defined

Fleet - A group of vehicles

AI-stats - Software created to perform mapping of raw data to a formatreadable in the application

Drivec Bridge - Hardware to read CAN-bus data from a vehicle

SVM - Support Vector Machine

KNN - K-Nearest Neighbor

NPM - Node Package Manager

JSON - JavaScript Object Notation

x

Chapter 1

1 IntroductionInternet connected devices are expected to be 24 billion by 2020[13] anda part of these are in the vehicle industry. European-Union has decidedupon a law that is based on environmental grounds[27] that all new ve-hicles in class M1[31] from November 1st 2014 are equipped with a TirePressure Monitoring System(TPMS)[14]. TPMS is based upon physicalsensors installed inside the tires. Explicitly heavy duty vehicles are notincluded in the law.

Knowledge in component failures before they occur is important for theheavy duty vehicle industry. The industry demand products that workdynamically towards the customer to reduce costs and remain efficiencyin the fleet. Drivec AB1 want to be a part of this process and develop ap-plications in the heavy duty vehicle industry. TPMS solutions are an ex-citing area on the market but these solutions could be expensive and notvery dynamic. The indirect tire pressure monitoring system(ITPMS)[22]is the kind of approach this project will consider and develop.

1.1 Purpose and goalThe goal is to develop an indirect monitoring system for Drivec AB. Thissolution must be based on a supervised machine learning algorithm todetermine if the tire depth or tire pressure are below acceptable limits.Data is collected from the vehicles Controller Area Network(CAN)[17].The CAN-bus use SAE-J1939[15] protocol which is commonly used in theindustry. GPS data is collected over time and compared to the vehiclesCAN-bus data. The chosen algorithm will be implemented in Drivec’scloud service for customers. The purpose is to make it easier for bus op-erators to know the condition of the tires on their vehicles. This enablesthem to more often have correct tire pressure and tire depth which inturn leads to both economic and environmental benefits. It can also helpdetect abnormal behavior related with tire condition.

1http://www.drivec.se/

1

1.2 Question at issueQuestions surrounding the different stages in the project need to be clari-fied to show why different approaches and solutions are better than othersand to create a better understanding of the development process.

1.2.1 Background and theory

• What other problems have similar solutions encountered?

• How well do other solutions work?

• What other products are available on the market today?

• Is it possible that the predicted outcome will match the expectedresult?

• How will the cloud service receive its input data to classify?

• Is there any scientific research based on our chosen algorithm?

1.2.2 Educational phase

• What programming languages have been chosen?

• How will the algorithm be tested?

• Is it possible to classify a tire being failed in inspection based ondata from the available parameters from the J1939 CAN-bus pro-tocol?

• Which of the following methods is most suitable for this projectsissue?

– Support Vector Machine– Random Forest– k-NN

• What problems are there with the chosen algorithm?

• What benefits are there with the chosen algorithm?

2

1.2.3 Delimitations

• Not going to create a SDK

• Will not point out actual value of the tire pressure and depth

• Will not point out which wheel of the given axle that is underacceptable condition

• No software for the hardware is going to be developed by the projectgroup

• No measurement of temperatures of the wheel

3

4

Chapter 2

2 BackgroundDrivec AB is a privately owned company with its headquarters in Hels-ingborg, Sweden and was founded in 2004. Drivec develops and sellssupport systems that increase the profitability for an operator combinedwith increased safety and reduced environmental impacts. Drivec spe-cialises in collating and interpreting data, processing various in-vehiclecontrol systems data communication and engine management with focuson the areas transmission systems, power systems, systems for anti-lockbrakes (ABS) and traction control.

Drivec AB provides expert knowledge in CAN-bus interpretation on allvehicle models and algorithms that produce and present critical vehicle-related metrics and key performance indicators to customers.

2.1 Current industrial solutionsNHTSA2(National Highway Traffic Safety Administration) is an agencyof the executive branch of the U.S. government. With a mission to savelives and prevent injuries combined with reducing vehicle related crashes.They have published a report[2] that conclude that 12.4 percent of allpassenger vehicles in the U.S. of model years 2004-2011 have at least onetire that is severely underinflated as defined by FMVSS No.138[1](25%or more below what the vehicle manufacturer recommend). The reportalso found that 23.1 percent vehicles in the study without TPMS had atleast one severely underinflated tire.

Tire monitoring is time consuming and operators have problems withscheduling proper maintenance. The global market for TPMS is pro-jected to reach 4 billion US dollars by 2020[12]3. The primary goal ofTPMS is to reduce underinflation in order to make vehicles safer to op-erate together with improved fuel economy.

2.1.1 Fleet management

Fleet management includes commercial motor vehicles such as trucks andbuses. A set of vehicles is indicated as a fleet. Fleet management is asetup of functionality. Figure 1 show the work flow for a fleet manage-

2https://www.nhtsa.gov/3http://www.strategyr.com/pressMCP-6772.asp

5

Figure 1: Fleet Managment - Total Cost of Ownership

ment. Correct fuel strategy strategy will have an impact on the TCO.The biggest and most valuable assets for a operator is the fleet. Plan-ning is important to maintain maximized TCO. Vehicle maintenance alsoinclude costs for purchasing spare parts.

2.1.2 Fleet management system integration

Figure 2 show Drivec’s fundamental part of a fleet management system.Drivec AB is today an integrator of fleet management systems to provide

Figure 2: Fleet Managment System Integration

applications suitable for the customer needs. Several applications areavailable to the customer.

6

Reports:

• ECO-driving

• Fuel and Environment

• Engine Report

Vehicle Information:

• Braking System

• Map

• Vehicle Health - Warnings

• Digital Tachograph

2.1.3 Vehicle health - Warnings

Vehicle health is the application that the project group has been involvedin. Drivec AB want the service to improve vehicle diagnostics and preventfaults before they occur. The given project Indirect Tire MonitoringSystem - Machine Learning Approach focus on the tires condition and itwill become a part of the vehicle health.

7

2.1.4 Direct TPMS

Direct TPMS use physical sensors to enable the monitoring. The di-rect TPMS can be installed in two distinct ways. The first method isthat the installation is done inside the wheel. The second method is toinstall it on the valve. The legal requirement does currently not applyfor heavy commercial vehicles but responsibility for safety rests with theoperator. There are TPMS specifically for buses and trucks with sensorsfor six wheels and a monitor the price is around 6-70004 SEK. The mostimportant thing with a TPMS system is that it can save lives. NHTSAreport[3] that an estimated 414 fatalities and 10,275 non-fatal injuries to-gether with 78,392 crashes occurred annually due to flat tires or blowoutsbefore tire pressure monitoring systems were installed in light vehicles.

Continental5 is one of the leading manufactures of the TPMS market andprovide the product called ContiPressureCheck. The system consists ofa display together with a central control unit (CCU) that communicatewith the sensors. Each tire sensor is fixed on the inside of the tire. Mea-sured data will be transmitted via a radio signal to the Central ControlUnit (CCU). The analyzed data is then transmitted via the CAN bussystem to the display in the driver cabin. The system displays the re-quired information during operation and monitors the temperature andpressure of the tires continuously. In the case of a deviation from theprogrammed value of the associated recommended pressures a warningon the display will notify the driver.

Advantages:

• Increased competition advantages for operators through better or-ganized maintenance

• Increased road safety that implies better fuel economy

• No need for an existing fleet management system

Disadvantages:

• Operators can be deterred by the increased cost due to a installationof a direct TPMS

• There is no standardization, and most of the parts are dealer only

• Expensive hardware from third part retailers4http://webbshop.safetyseal.se/tpms-lv-startkit-typ-axlar-p-932.html5http://www.continental-tires.com/transport/products/contipressurecheck/about

8

2.1.5 Indirect TPMS

Indirect TPMS does not use physical sensors. It is based on softwarerelying on data from the vehicle. Such as an existing vehicle system thatcan deliver CAN-bus data.

Audi deliver an indirect TPMS on their models. The indirect TPMSuses data from the ABS and compares the rotational speed of all fourwheels. Audi has integrated their system into the electronic stabilizationprogram (ESP)6. This system also analyzes vibrational changes in thetires which allows it to detect simultaneous pressure loss.

Advantages:

• Easily integrated to existing fleet management systems

• Adjustments can be made effortlessly to the software in order tooptimize it

• Machine learning is well suited for the indirect tire pressurementsystem

Disadvantages:

• Cannot detect a condition where the pressure of all tires changesimultaneously

• Could become inaccurate and slow to respond

2.2 Data driven monitoringMachine learning implementation have various approaches and one ofthem is to implement it in Python. A group of people created a machinelearning module called Scikit-learn[19]. By creating this they bring easyaccess to non-specialists who wants to use machine learning in a generalpurpose.

This module is used by Spotify among others and their Engineering Man-ager Music Discovery and Machine Learning, Erik Bernhardsson says:"Scikit-learn provides a toolbox with solid implementations of a bunch ofstate-of-the-art models and makes it easy to plug them into existing ap-plications. We’ve been using it quite a lot for music recommendations at

6https://www.audi-technology-portal.de/en/chassis/brakes-wheels/tire-pressure-monitoring-system

9

Spotify and I think it’s the most well-designed ML package I’ve seen sofar."7

Remote diagnosis, maintenance and prognosis for advanced driver as-sistance systems is currently a hot topic. Mostafa Anwar Taie amongothers have created a framework[29] which predict the remaining usefullife for the prognosis of the advanced driver assistance system’s safetycritical components by using machine learning algorithms. This frame-work can be used during development phase but mainly after production.

Niclas Persson, Fredrik Gustafsson and Markus Drevö wrote a thesisabout Indirect Tire Pressure Monitoring Using Sensor Fusion[21]. MarkusDrevö is working at the Swedish company Nira Dynamics which is one ofthe leading companies in indirect tire pressure monitoring systems. Thisthesis explains a system based on wheel radius and vibration analysis.With both approaches combined it can detect a pressure loss of 15% inone, two, three or four tires and independently detect a pressure loss of25% within one minute. This solution does not use any supervised ma-chine learning methods but instead tests values against a predeterminedthreshold.

Stefan Byttner, Thorsteinn Rögnvaldsson and Magnus Svensson cre-ated Consensus self-organized models for fault detection (COSMO)[6].COSMO is an unsupervised approach which builds up knowledge overtime. It uses an onboard self-organized search for models to find re-lations between the vehicles data values together with an offline serverapplication which compares the parameters of the models. A significantbenefit is that the vehicles normal behavior is found under real operatingconditions and not observed in a number of tests in laboratory environ-ment. This has also formed the basis for various licentiate theses.

Rune Prytz writes "Vehicle uptime is getting increasingly important asthe transport solutions become more complex and the transport industryseeks new ways of being competitive." in his licentiate thesis Machinelearning methods for vehicle predictive maintenance using offboard andon-board data[23]. This thesis describes two different approaches for pre-dicting vehicle maintenance. One supervised approach and one unsuper-vised. The unsupervised method used is COSMO which is explained inthe paragraph above. The second method is a supervised classificationwhich uses already collected data and repair history to label data. Thismethod is used for failures of the vehicles air compressor and based on

7http://scikit-learn.org/stable/testimonials/testimonials.html

10

the database of vehicle statistics by Volvo AB.

Yuantao Fan wrote a licentiate thesis about A Self-Organized Fault Detec-tion Method for Vehicle Fleets[9]. Also in this thesis COSMO is used forunsupervised deviation detection. It is based on "wisdom of the crowd"which assumes that the majority of the group is healthy. This entailsthat the deviations from the majority can be considered as faulty. Inthis thesis the focus is on the vehicles air system and the problems asso-ciated with it.

Hillol Kargupta among others wrote a paper on On-board Vehicle DataStream Monitoring Using MineFleet and Fast Resource Constrained Mon-itoring of Correlation Matrices[16] where the problem of monitoring datastreams from vehicles in a limited-resource environment is covered. Themain focus is on computation of correlation matrices using on-board de-vices. The presented algorithm of this paper is applicable for monitoringcorrelation matrices computed from data streams.

João Pedro Lebre Magalhães Pereira has proven that a new solution forthe relationship extraction problem[20] can be developed. He describesthe problem as: "Information Extraction (IE) is the task of automati-cally extracting structured information from unstructured data, aimingto facilitate the use of said data by other applications. A typical sub-problem is the extraction of relationships from textual documents, whichaims at identifying and classifying the relationships expressed between en-tities mentioned in the texts.". The solution is based on SVM classifiersand online multiple kernel learning.

2.3 Industrial relationA major difference between this project and most of the others mentionedabove is that the approaches above are using unsupervised machine learn-ing. This project is focused on supervised machine learning where thetargets are known and the actual fault can be pin pointed to an axleof a faulty tire. There are some similarities between the dissertationregarding the extraction problem and this thesis. Both use supervisedmachine learning for a classification problem. The data sets used inthe dissertation have different relationship types compared to this the-sis. For example in the dissertation data set called SemEval there areseveral relationship types whereas the Almed data set only consists ofone relationship type, more specifically interactions between proteins ina medicine context. The dissertation show that different kernels have dif-

11

ferent performance depending on the used data set. In this thesis thereis only one thing making the data set different, which is the number ofaxles on the given vehicle. However this does not affect each classifierbecause each classifier predicts on one axle at the time not knowing any-thing about the other existing axles.

The practical study in this project is based on 34 MAN city buses withthe fuel type of compressed natural gas with different lengths and 2 to3 axles8. The buses are part of a commercial fleet operating in city andinter-city areas, during the spring of 2017. The buses used in the COSMOproject were 19 Volvo city buses. The fleet in this project are year models2005 to 2011, in the COSMO project most vehicles were from 2007[9].

Each vehicle in this fleet is equipped with Drivec Bridge9 that fetchCAN-bus data in real time, it is a part of the existing fleet managementsystem. During the process of training of the classifier data is fetchedfrom a database where the data is selected for a specific date, but whenthe whole implementation is done for the cloud service, the applicationwill analyze the data in real time from the vehicles and signal when faultsoccur. Projects mentioned above does not have a connection to an ex-isting fleet management system. COSMO use the Volvo Analysis andCommunication Tool (VACT), that is capable of recording data usingtelematics to communicate remotely, COSMO will never provide an er-ror in real time.

The existing solutions on direct TPMS and indirect TPMS does notdeliver the data to a cloud service. The information is locked withinthe vehicle. The application of this project will analyze the result andmake it viewable for the operators regardless of the vehicles location andwithout having to include the driver in the decision process.

2.4 Industrial communicationIndustrial communication with a tire monitoring system has the goal toensure greater company-wide efficiency. The different component neededfor this can be divided into different groups. Such as data layers andprotocols but also method approaches.

8http://www.laefbooklet.media-it-services.info/epaper-LionsCity_en/#/249http://www.drivec.se/browse.asp?m_id=23&m1_id=64&section=1

12

2.4.1 CAN

Controller Area Network is a communication protocol that is widely usedin the automobile industry. CAN enables nodes to communicate betweeneach other in a safe and fast way. With CAN, vehicles save a lot of weightdue to the less usage of physical cables.

2.4.2 SAE J1939

The Society of Automotive Engineers (SAE) developed the J1939 stan-dard to be the preferred CAN used in heavy duty vehicles. It is a high-level protocol that defines how communication between nodes occur onthe bus. Every message includes a 29-bit identifier that contains the pri-ority, parameter format and parameter specifics followed by the sourceaddress.

2.4.3 PGN

A Parameter Group Number (PGN) is a part of the 29-bit identifier sentwith every message. When the Electronic Control Unit (ECU) receivesa message, it uses the PGN in the identifier to recognize the type of datathat is sent in the message.

2.4.4 SPN

A Suspect Parameter Number (SPN) is a number reference that has beenassigned by the SAE committee to a specific parameter. Each parametercontain detailed information:

• Data length in bytes

• Resolution

• Offset

• Range

• Label for reference

SPNs that share common characteristics, will be grouped into a Param-eter Group (PG) and will be transmitted to the network using the samePGN.

13

2.5 Supervised machine learningSupervised machine learning[26] is the task within machine learning thatcreates an interpretation of a function from a set of labeled training datasets which hold examples of what is relevant and what is irrelevant data.To know this there need to be an analysis of the training data in orderto produce the mentioned interpreted function. Thus this function canbe used for mapping new examples where an optimal scenario will al-low for the algorithm to correctly determine the class labels for unseeninstances in a inductive bias. The target value can be divided into twocategories, classification and regression. Classification means that thetarget variable is categorical such as good or bad. In regression the tar-get is continuous such as float value.

The hypotheses have an important role in supervised machine learning.They consist of theories about which parameters are interrelated and intheory can have an impact of the fleets actual behavior. Several hypothe-ses are determined to make sure the development is kept within the givenscope and to avoid dead ends. The hypotheses are presented to both thesupervisors and the product owner for feedback and approval and lateron used when choosing parameters from the data for the supervised ma-chine learning method.

The inductive bias in machine learning[32] is a set of assumptions thatthe supervisor use to predict a certain output with a given input. Thereare several different applications within the machine learning concept.

Figure 3: Flowchart of bias role

Figure 3 concludes the role of bias in inductive generalization hypothe-sis. A strong bias is one that will focus on the actual concept; thereforestay within the given scope thus will not choose too many hypotheses.A weak bias would be one that allows the concept learner to choose rela-tively large numbers of hypotheses. A correct bias is one that will alwaysallow the learner to choose the given target concept.

14

Chapter 3

3 MethodologySeveral methods and approaches to different algorithms with evaluationof methods covered in tire monitoring system environments need to beanalyzed to figure out what works best with a provided problem.

3.1 Project phasesThe thesis project is divided into different phases. This is explained withthree major areas which is the education phase, visualization phase andthe implementation phase.

3.1.1 Education phase

The first phase is an education phase where different subjects are deter-mined, research about related works and existing products is made anda lot of knowledge about machine learning is gained. Hypotheses aboutwhich parameters under which conditions that are relevant for reachingthe desired outcome are decided. The approach with targets in super-vised machine learning is discussed for greater knowledge.

3.1.2 Visualization phase

The second phase is called visualization phase. In this phase the data isprocessed and analyzed. Python and WEKA is used for visualization ofdata. Several supervised machine learning methods are tested and theone with best result and lowest complexity is chosen to be implementedin the next phase.

3.1.3 Implementation phase

The actual training will never be implemented in the cloud, the nature ofthe training requires a lot of computation power and has for that reasonbeen set to be done outside of the cloud. When the classifier is done fromthe training it will be implemented in Drivec’s cloud service. During thisprocess there will be testing simulating when a vehicle will send data tothe cloud service and how it will behave. If there is time there will beactual tests on real devices in real vehicles but the goal is to implementthe structure that makes this possible and to also make it available toshow that it works. The results will continuously be taken back to the

15

visualization phase and the the chosen method will be modified to achievehigher accuracy.

3.2 Project designAn agile work approach is implemented in the project. Scrum is a man-agement framework for incremental product development and it implic-itly provides a structure of roles, organizing meetings, setting the rulesand artifacts.

3.2.1 Implementing scrum

The product owner is Drivec AB. Therefore Drivec is responsible forthe ROI(Return Of Investment). The product owner will validate thesolutions and verify whether the quality is acceptable or not from theend-users point of view. Johan Göthe is the scrum master, and a scrummaster will not interfere into the decisions that the team makes specif-ically about the development but rather assists the team as an adviser.The scrum master only interferes when somebody of the team or anyother participant of the project (stakeholder) does not obey the rules ofScrum.

The meeting phase consist the sprint planning. The product owner de-scribes the highest priority features to the team. The team asks enoughquestions that they can turn a high level user story of the product back-log into the more detailed tasks of the sprint backlog. Figure 4 show thisworkflow.

Figure 4: Scrum work flow

An important rule for the scrum methodology is that the sprints need tobe of the same length. This also implies that the sprint time should notexceed four weeks. The Product Backlog is refined to ensure it is ready

16

for every sprint planning meeting. The Product Backlog is an evolvingartifact where the earliest versions of it may contain only the initiallyknown and best understood requirements. The Product Backlog getsdeveloped as the product and the environment in which it will be used.The Product Backlog constantly changes to incorporate what is requiredto make it effective.

As long as a product exists the Product Backlog also exists. Trello10

is the tool that is being used during this process where all the steps arecontained.

3.3 Supervised machine learning methodsThere are several approaches to consider when solving a problem witha supervised machine learning method. Not to forget that the mainpurpose is to build a concise model from a distribution of class labels interms of predictor features. The resulting classifier is then used to assignclass labels to the testing instances where the values of the predictorfeatures are known, but the value of the class label is unknown.

3.3.1 Support vector machine

In machine learning and also in areas such as image processing there issomething called kernels[7]. Kernel functions provide a way to manipu-late data as though it were projected into a higher dimensional space byoperating on it in its original space. Which also can be explained in theway that a linear model work for nonlinear problems. Support VectorMachine(SVM)[24] is a model representation of given data points in spacewhere they are mapped so that the examples of the separate categoriesare divided by a clear gap that is as wide as possible. New examples arethen mapped into that same space and predicted to belong to a categorybased on which side of the gap they fall. The support vectors seen inFigure 5 represent the data points nearest to the hyperplane and if thepoints of a data set are removed it will alter the position of the dividinghyperplane. Therefore they can be considered as the critical elements ofa data set that would change the position of the dividing hyperplane ifremoved.

Figure 6 illustrates the hyperplane which represents a linearly separa-ble case and classifies a set of data. The further from the hyperplanethe data points are the more it proves to be correctly classified. This

10https://trello.com/

17

Figure 5: The decision function is fully specified by a subset of trainingsamples, the support vectors

mean that the data points need to be as far away from the hyperplane aspossible. If the hyperplane is known it means the data points are linearlyseparable and two parallel hyperplanes can be selected to separate thetwo classes of data. Therefore the distance between the hyperplane andthe nearest data point from either set is known as the margin. Choosethe hyperplane with the greatest possible margin between the hyperplaneand any point within the training set that provides a greater chance ofnew data being classified correctly.

Equation 1 show the linear classifier[25]:

K(~x)v = (~wT~x+ b) (1)

Where b is an intercept term and a decision hyperplane normal vector ~wwhich is perpendicular to the hyperplane. In Figure 6 r is the geometricmargin of a point r and a decision boundary q. A linear kernel is a goodchoice if the number of features is larger than number of observations.The speed could also be an issue where the linear kernel is faster thanfor example the RBF(Radiail bias function) kernel.

The Radial Basis Function(RBF) kernel[18] also known as the Gaussiankernel. Equation 2 show the RBF kernel equation.

KRBF (x, x′) = exp(γ||x− x′||2) (2)

Where γ is a parameter that set the spread of the kernel. A large γwill therefore provide a small standard deviation whereas a small γ willprovide a larger standard deviation.

The RBF kernel is well suited if the data is not linearly separable. If

18

Figure 6: Maximize the margin around the separating hyperplane

the number of features are larger than the number of observations asmentioned before the nonlinear mapping does not improve the perfor-mance. This also means that there is no need to project to a higherdimensional space.

3.3.2 Random forest

The random forest[28] is an ensemble approach that can also be thoughtof as a form of nearest neighbor predictor. Figure 7 illustrate how a tree

Figure 7: Decision tree

can advise on decision making. This example is based upon if a personshould run or not. If the outlook is sunny and the humidity is less than

19

or equal to 70 the tree advises the person to run. The random forest isa divide-and-conquer approach used to improve performance. But withthe regular tree in mind the random forest enhance this by combiningtrees. The tree may be refereed to as weak learners but when assemblingall these trees together they can possibly create a strong learner. If thereexist a sample of N cases at random with a given replacement it willcreate a subset of the given data input. How large this subset should bemay vary. At each node there should be a number X where X is the

Figure 8: Illustration of the random forest implementation

selected predictor variables at random from all the predictor variables.The predictor variable that provides the most accurate split is then lateron used to perform a binary split on that specific node which is illus-trated in Figure 8.

When running random forest the given input will go trough all the trees.The result may be different. It is crucial to know that if there is a largenumber of predictors the predictor will be more different between thenodes. One of the big benefits with random forest is that it is rapid. Therandom forest is also good at handling imbalanced data.

20

3.3.3 k-nearest neighbor

KNN is a lazy learning non parametric algorithm. It means that it doesnot make any assumptions on the underlying data distribution and itdoes not use the training data points to do any generalization. There isno explicit training phase or it is minimal which implies that the train-ing phase is fast. Lack of generalization means that KNN stores all thetraining data. The principle behind nearest neighbor is to find a prede-fined number of training samples closest in distance to the new point andpredict the label from these. The number of samples is a user definedconstant k which usually is chosen as an odd number if the number ofclasses is 2. Seen in Figure 9 is nearest neighbor with k set to 3.

Choosing a proper k value is important to the performance of K-NearestNeighbor classifier. The size of the data matters. If k value is too largethe nearest neighbor classifier may be missclassified[4]. Because the near-est neighbors may include data points that are located far away from itsneighborhood. If k is too small the nearest neighbor classifier may besusceptible to overfitting because of noise in the training data set.

Figure 9: 3-Nearest Neighbor

21

3.3.4 Critical motivation

The given methods that are being examined in this thesis can be ap-proached in different angles and in different perspectives. The SVM isan advanced and popular machine learning method that can make amodel work in a nonlinear setting. It is important to know that themost advanced algorithm is not always the best choice and therefore it isimportant to test other methods as well. In this case the project groupwill examine SVM, random forest and the k-NN methods. When thesemethods are put against each other it is clear that they have many differ-ent advantages depending on the situation they are used in. The k-NNalgorithm is fast but may not be suitable. The computational complexityscale with the number of observations for k-NN, could be a problem forthis project. Random forest compiles very fast. However it is very easy toperform overfitting. When looking at the compiling speed and accuracyon each different method, there is a need to adapt the examination ofeach method to the timetable by the project group. It has to have both agood accuracy and be possible to implement agile. Which means that theclassifier need to predict input data fast and be easy to manipulate. It isvery important that no training should take part in the cloud service. Itshould also be easy to export after the training. The SVM training is notas fast as the other two methods and therefore maybe not the best choicefor the application. The k-NN method directly learns from the traininginstances compared to the the random forest that build a classificationmodel on the training dataset before being able to actually classify un-known data. Therefore the project group believe that the random forestshould be best suited for the project when looking at compiling speedand how well it adapts to change.

3.4 Software toolsToday various software tools are available to produce applications forwork with supervised machine learning. This is the part where encodedinformation is built from the physical hardware and in this case infor-mation from vehicles. This project is going to be focused on applicationsoftware where it is connected with the hardware and the user interface.

3.4.1 WEKA

WEKA11 is an open source software used for engineers and developersto test machine learning algorithms. The software contains a collectionof algorithms for machine learning and data mining tasks. Such as data

11http://www.cs.waikato.ac.nz/ml/weka/index.html

22

pre-processing together with classification and regression. There is alsofunctionality for clustering combined with association rules and one ofthe most important features visualization. Therefore an incorrect bias isone that does not allow the concept learner to elect the target concept.

3.5 Version controlVersion control provides the opportunity to recreate what has been donebefore in recent work related areas such as documents and code. It isalso possible to trace changes that has been done in past versions. Par-allel development enables the opportunity for several people to developdifferent parts of the project at the same given time.

GitLab is being used for version control. GitLab allows the user tostore code privately and secure. It also allows old versions to be re-implemented, tested and validated if needed.

3.5.1 Git

Git provides the opportunity to manage version control of the software.There are several services git provides:

• Committed: The file has been saved in the users local database.

• Modified: The file has been changed but not committed.

• Staged: The file has been altered and signed to be saved withinthe database in its current version for the next commit.

3.6 Data managementFor the project city buses of a anonymous fleet has been sending logfilesto a Drivec server where the raw data is buffered.

3.6.1 Offboard measurements

To be able to put the logfiles in relation to actual behavior offboardmeasurements are made. Offboard measurements include tire depth inmillimeters and tire pressure in bar of all wheels of the vehicle togetherwith a timestamp for the current date and time. For the measurementof tire depth a tire depth gauge is used on the centered track of the tire.For tire pressure a digital tire pressure gauge is used for achieving asaccurate measurements as possible.

23

3.6.2 AI-stats

From the Drivec logfiles the raw data is processed through a mappingprocess to determine what PGN messages that are available from theSAE-J1939 protocol. All the vehicle in this project follow this standard.The output will be an average sum and standard deviation for each pa-rameter during a period of 10 seconds. Some vehicles may have moreSPN available than others. It could depend on e.g. the amount of axlesthey have or what year they were manufactured. AI-stats is a softwaredeveloped and provided by Drivec to determine what messages are avail-able from the CAN-bus. The logfiles are processed to make the raw datareadable and to increase a greater understanding of the data. Whenthe mapping process is done the software will create text files that canbe pasted into an excel file and used in Python for the actual trainingprocess.

3.6.3 Filtering

The filtering is done in both Python for the training and for the cloudservice in Node.js with JavaScript. The parameters that the filtering isbased upon are the vehicle speed, vehicle speed standard deviation, GPSspeed, GPS course change standard deviation, individual wheel speed perwheel and the brake signal. The filtering makes sure that the receiveddata only represent when the vehicle is driving with a constant speedwithout any heavy turns or heavy accelerations.

3.7 PythonPython is a programming language that enables integration of systemseffectively. One of Python’s strongest features is its comprehensive stan-dard library which provides a set of modules for most programming tasksincluding data parsing and manipulation, file I/O and system interaction.The greatest reason why Python was chosen was the need to be able toexport the classifier in a way that it could instantly run on the cloud inJavaScript. In addition to this Python was chosen because of followingfeatures:

• Agile training of classifiers compared to other programming lan-guages (e.g. JavaScript)

• Flexible data parsing to create the data set needed - Read in excelfiles and create data sets as CSV files with determined parameters

24

• Effective evaluation of classifier performance - Can easily extractfeatures like accuracy, standard deviation of accuracy from crossvalidation and confusion matrix.

• Scikit-learn module

3.7.1 Scikit-learn

Scikit-learn[19] is a Python module integrating a wide range of state-of-the-art machine learning algorithms for medium-scale supervised butalso unsupervised problems. With an API consistency together withthe performance and proper documentation it is widely used both foracademic and private sector purposes.

3.7.2 Setting targets

The targets are set individually per bus and day according to our offboardmeasurements. These are stored per axle in a JSON file with the followingcharacteristics:

1 {"invNr": " Vehicle A", " leftFront ": "Y mm",2 " rightFrontBar ": "X", " rightFront ": "Y mm",3 " leftFrontBar ": "X"}

Python reads the JSON file and checks the difference between left andright tire pressure and the tire depth difference for each bus used in thedata set. It then sets the target to 1 (bad) if the tire pressure differenceor tire depth is greater than the given limit and 0 (good) if it is less orequal.

3.7.3 Training and evaluation of algorithm

When the targets have been determined the training will be executedwithin Python where Scikit-learn provides the classifier. The input fromthe data set and targets will be used to call the fit method to generatethe classifier that predicts the class to which the unseen samples belong.

To optimize the classifier it is crucial to use different tools ensure thatthe outcome is as good as possible and that it behaves in the way thatis best for the given situation. Confusion matrix12 is used to evaluatethe quality of the output of a classifier on the data set. In Figure 10 theconcept is shown. The diagonal represent the number of points for which

12http://scikit-learn.org/stable/auto_confusion_matrix.html

25

Figure 10: Confusion Matrix

the predicted label is equal to the true label. While the off-diagonal el-ements are those that are mislabeled by the classifier. This will resultin a false negative or a false positive. This project requires more falsepositive mislabels than false negative since a false negative would triggera false alarm.Furthermore there is a need to evaluate how well the classifier performon unknown data sets. This can be solved by using stratified K-fold crossvalidation[11]. This is a model variation technique for assessing how theresult of a statistical analysis will generalize to an independent data set.K-fold cross validation is one way to avoid over-fitting where 90% fromthe unknown data set have good targets and 10% have bad targets.

The out-of-bag concept is used to estimate the generalization error whichis the error rate of the out-of-bag classifier on the training set. An esti-mation of the error rate can be obtained based on the training data. Thisensures that the classifier is built on about 63% of the available data andtherefore pulling away 37% for testing[8].

3.8 JavaScriptJavaScript is a high level and dynamic programming language[10]. To-gether with HTML13 and CSS14, JavaScript is one of the three core tech-nologies of World Wide Web content production.

3.8.1 Node.js

Node.js is an open-source cross-platform JavaScript runtime environmentfor developing a diverse variety of server tools and applications which are

13https://www.w3schools.com/html/default.asp14https://www.w3schools.com/css/default.asp

26

suitable for maintaining a persistent connection from the browser backto the server. Although Node.js is not a JavaScript framework[30] manyof the basic modules are written in JavaScript. This allows developers towrite new modules in JavaScript.

Use cases:

• Real time web applications

• Mobile applications backend

• API endpoints.

Anti-use cases:

• CPU-bound applications

• Simple Create, Read, Update and Delete (CRUD) applications

• Need a library in a specific language

This project will enable the use of a real time web application. Therewill be no machine learning in this part, only the usage of the machinelearning classifier from Python. The classifier is created from the traininginside Python and then exported as a module. The classifier will returna result based as a percentage from the score of the bad class. If thepercentage is greater than a threshold decided by the user it will be seenas an alarm. To ensure as few false alarms as possible are triggered themodule will check if a determined amount of alarms have been triggeredduring a certain time of samples. If this is the case it will be interpretedas an alarm.

3.8.2 Cloud

Drivec’s products are all represented on a cloud service. The cloud is100 % scalable thus ensuring almost unlimited capacity in quantity ofconnected vehicles. The cloud provides better automatic software up-dates combined with a better disaster recovery. The projects end resultwill be a classifier from the supervised machine learning method. Thiswill be implemented into the cloud service. The project group will notwork on the graphical output. The main focus is to create the back-end connection with the module that will communicate with the cloudservice.

27

3.8.3 Mocha

Mocha15 is a feature-rich JavaScript framework running on Node.js andin browsers. Asynchronous testing becomes easy and will increase qualityof code. The framework will be used to test the cloud service.

3.9 ModelThe basis for tire pressure monitoring is to compare individual wheelspeed and check if there is any wheel rotating faster than the others.This is not enough since a simultaneous pressure loss in all wheels willnot be detected. Therefore the actual vehicle speed will be comparedwith the GPS speed to see if there is a noticeable big difference. Thedata is only valid for this model if the vehicle is driving at a relativelyconstant speed and not doing any heavy course changes.

The values received from the GPS are unreliable when the speed is toolow therefore a limit has been set. This will be filtered out from old logfiles during training by looking at the standard deviation. In addition tothis the relation between the speed quotient and the tire pressure will beinvestigated to see if this can be an asset.

To ensure that the parameters are not correlated with each other thelinearity is investigated. A model based on the quotient of the vehicle

Figure 11: Model of speed quotient in relation to thread depth with arti-ficial data

speed and GPS speed and the vehicles remaining thread depth is createdto analyze if the remaining thread depth can be put into relation with

15https://mochajs.org/

28

the vehicles speed quotient. As shown in Figure 11: if a vehicles quotientis 0.974 the remaining thread depth is 13mm.

3.10 ValidationThe application is tested in two major steps. The first step will be tovalidate the classifier. Then the cloud service will be tested to make sureit does not create false alarms and that the input is valid.

The classifier will be tested through different optimizations in Pythonwhere the training take place. The features are going to be further ana-lyzed to check correlation and independence’s between parameters fromthe CAN-bus. Together with offboard measurement from the fleet tovalidate if the classifier provide the expected result.

The Node.js module will have the classifier implemented and tested throughthe framework of Mocha to make sure that it will perform well in thecloud service.

All data during the validation has gone through filtering and is validto be worked on. Drivec AB will also take part of the result to make surethat the output is valid.

29

30

Chapter 4

4 Results - Supervised Machine LearningThe result from the supervised machine learning is presented and howthe different areas have been approached to increase the understandingof the structure of the workflow.

4.1 Data managementDuring the process of the project there has two distinct sources for data.The offboard data and the CAN-bus data coming from the vehicle. Thedata has been collected from the vehicles in real time during the springof 2017.

4.1.1 Offboard data

Offboard measurements has been done at the operator fleet depot wherethe tire depth and tire pressure have been documented with actual timestamps and dates. When the tire depth had been measured the projectgroup found out that the easiest way is to measure the center tire track.This is done to make it easier to provide the needed targets. If the tracksare measured on the side tracks and not the center there could be aspectssurrounding a tire that is damaged due to bad calibration or other dam-ages surrounding the bearing of the axle which would make it harder topredict a faulty tire.

In one case the bus had issues where the driver heard loud noises fromthe back of the bus. The workshop investigated this and found out thatthe inner wheel of the driving axle was flat and mounted a new tire.The project group have the date on this occurrence and can with thisinformation analyze how our data looks like for this particular day andseveral days before the actual replacement. The workshop log has beenavailable for the project group to analyze and from this document theabove statement has been verified in the studies to understand the vehi-cles behavior.

4.1.2 CAN bus data

The data from the vehicles has been delivered from the fleet managementsystem the Drivec Bridge has been installed in. The data has been sent toa database where the project group has been able to reach the logs from

31

day to day basis from different vehicles in the fleet where the CAN-busdata has been in the SAE J1939 format.

4.2 Analysis of dataThe input data has been analyzed and mapped for different vehicles inthe fleet. At this moment the buses are only categorized as either citybuses or regional buses where the city buses are the only focus for thisproject. There will be sub segments of bus types within the super typecity buses and regional buses. The incoming data from the vehicles hasbeen analyzed and mapped individually during the training process. Theparameters are retrieved from different sources of the CAN-bus. The usedparameters are specified below:

• Vehicle speed, Vehicle speed standard deviation

• GPS speed

• Course change standard deviation

• Individual wheel speed standard deviation

• Brake status

The GPS data is currently not provided from the vehicles CAN-bus butfollows the NMEA standard[5]. Furthermore the GPS data is providedfrom the router Drivec is connected to. There are 53 available parametersthat have been mapped but the parameters above are the ones currentlybeing used when creating the data set. Shown below are sources whichthey exist from:

• Vehicle speed → PGN: 0xFEF1 → SPN: 84

• Individual wheel speed → PGN: 0xFEBF → SPN: 905-910

• brake status → PGN: 0xFEF1 → SPN: 597

4.2.1 WEKA

The software WEKA was meant to be used mainly for visualization ofdata. It did not perform as expected and was therefore not used as muchas expected. A try was made to export the trees of the forest fromWEKAbut was not successful. The visualization of data this project needed wasmade in Python with less effort and better result than in WEKA.

32

4.3 ModelThe model based on the speed quotient did not meet the expected resultand can not be used. From this hypothesis it was noticed that the classi-fier can not explicitly classify if a vehicles tire has a bad condition basedon underinflation or not enough thread depth. Therefore the outcomeof the classifier will only notify that a tires condition is bad, i.e. eitherunderinflation or bad thread depth.

As a result of the offboard measurements several hypotheses are con-cluded. The first one is based on the vehicles tire depth and tire pres-sure. Concluded by the histograms in Figure 12 and 13 is that the axlewith the highest difference in both tire pressure and thread depth is thefront axle. Therefore the focus will be to classify the tire condition of thevehicles front axle.

(a) Front axle (b) Drive axle - Inner wheels

(c) Drive axle - Outer wheels (d) Boogie axle

Figure 12: Histogram of pressure difference between left and right wheelfor corresponding axle

33

(a) Front axle (b) Drive axle - Inner wheels

(c) Drive axle - Outer wheels (d) Boogie axle

Figure 13: Histogram of thread depth difference between left and rightwheel for corresponding axle

The relation between tire pressure, thread depth and individual wheelspeed of the front axle has been analyzed. Noticed was that both threaddepth and tire pressure affect the individual wheel speed. The x axis offigures 14, 15 and 16 represent the wheel rotation difference where thevalue 10 interprets as the right wheel rotating 3% faster than the leftand -10 interprets as the left wheel rotating 3% faster than the right.In Figure 14 the individual wheel speed distribution of 309 samples ofvehicle A is shown as percentage where the highest percentage is at 0.This means that the vehicle should have correct tire pressure and threaddepth. This is correct according to the offboard measurements for thisvehicle which states following: Front Left Pressure: 8.43 bar, Front RightPressure: 8.73 bar, Front Left Depth: 10mm, Front Right Depth: 12mm.

34

Figure 14: Percentage of wheel speed distribution of 309 samples

In Figure 15 vehicle B’s distribution of individual wheel speed is shown.This has its peak around 4 which indicates that the right wheel of thefront axle has a major difference in either tire pressure or thread depth.Looking at the offboard measurements it is seen that the right wheel ofthe front axle have 7.88 bar and the left has 10.13 bar which leads tothe right wheel rotating faster than the left and the vehicle pulls to theright.

Figure 15: Percentage of wheel speed distribution of 372 samples

35

Vehicle C’s wheel speed distribution is shown in Figure 16. It has itspeak around -4 which indicates that there is an issue with the left tire ofthe front axle. According to the offboard measurements the thread depthof the left tire is 13mm while the thread depth of the right tire is 19mmand the tire pressure of the left wheel is 9.64 bar while the tire pressure ofthe right wheel is 9.61 bar. This shows that 6mm in tire depth differenceof the front axle can affect the the wheel speed of the vehicle.

Figure 16: Percentage of wheel speed distribution of 682 samples

The value of the vehicle speed that is used for the filtering is decidedby analysis of figure 17. Noted is that speeds under 30 km/h give a lessreliable value hence the filtering is set to only accept data when the speedis above 30 km/h. Linearity between individual wheel speed and vehiclespeed was found and resulted in a change of features in the classifier.

36

Figure 17: Individual wheel speed difference divided by vehicle speed

4.4 TargetsThe targets are decided according to the offboard measurements of thevehicles tire pressure and thread depth. From the beginning the targetswere decided by looking if the difference in pressure of left and righttire was greater than 0.5 bar. This would set the target as bad for thevehicle. It was discovered that 0.5 bar was too low and resulted in toomany vehicles with rather small differences being classed as bad. Theproject group decided together with Drivec that a vehicle need to have amajor difference in either tire pressure or thread depth to be classed asbad. This to avoid causing false alarms or alarms for minor issues whichdo not yet need to be resolved. The resulting value for deciding whetherthe vehicle shall be classed as bad is if it has a tire pressure differencegreater than 1.5 bar or if the difference in thread depth is greater than6mm.

4.5 FeaturesThe features need to have physical buoyancy and have therefore beenchosen as a result of the hypotheses. To calculate the feature impor-tances the method feature_importances_ in scikit-learn’s library forrandom forest classifier has been used. The importance of a feature iscomputed as the (normalized) total reduction of the criterion brought bythat feature. The distribution of the feature importances were noted asseen in Figure 18.

37

Figure 18: Feature importances of first version of classifier

The distribution was too wide and the features with highest respectivelowest importance need to be changed to receive a more even distribu-tion. The features frontRightWS and frontLeftWS represent the speedthe wheel is rotating faster or slower than the vehicle.

Vehicle speed and GPS speed were removed and two new features wereadded.

frontRightQ = (vehicleSpeed+ frontRightWS)gpsSpeed

(3)

Equation (3) also appends for the left wheel variables. These featuresgives a quotient between the total wheel speed and the GPS speed whichshould be close to 0 when driving at speeds above 30 km/h. The finalfeatures and the feature importances can be seen in Figure 19.

The distribution is more even and 4 out of 6 features have an importancebetween 20-25%. Two features have been modified since linearity be-tween vehicleSpeed and front left and right wheel speed has been found.To avoid correlation between the features the right and left wheel speedhas been divided by vehicle speed.

38

Figure 19: Feature importances of final version of classifier

frontRightWS = (frontRightWS)vehicleSpeed

(4)

Equation (4) will result in a percentage of how much faster or slowerthe wheel is rotating instead of the actual difference in km/h. Figure19 also shows that the basis of the hypothesis mentioned in 3.9 whichcompares individual wheel speed still is the most important.

Backwards selection of the features was done to confirm that the choiceof features was correct. The features frontLeftQ and frontRightQ wereremoved and the new feature importances plot is seen in Figure 20.Compared with the performance of the final classifier seen in 4.6 thisis worse. The accuracy is 90.45% (+/- 1.37%) which is lower and thestandard deviation is higher. The confusion matrix is worse as well andpredicts 11.39% false negatives and 89.47% false positives. This con-firms that the features used in Figure 19 are the ones giving the bestperformance.

39

Figure 20: Feature importances of backwards selection version of classi-fier

4.6 ClassifierThe tables below shows the performance of the supervised machine learn-ing classifiers tested with the final features, same data set and the samecross validation.

Support vector machine - Support vector classifier

• C = 1.00

• Kernel = linear kernel

– Accuracy: 83.65% (+/- 0.04%)– Time elapsed during CV: 14.05s

40

Figure 21 Confusion matrix of support vector classifier predictions

The C parameter tells the SVM optimization how much it should avoidto set a wrong classifying for each training example. For large valuesof C, the optimization will choose a smaller-margin hyperplane if thathyperplane does a better job of getting all the training points classifiedcorrectly where the kernel is a linear function.

It was discovered together with Drivec AB that SVM was not the mostefficient choice at the current time and in order to keep up with thetimetable further investigations of hyperparamters was not motivated.They are only showed here to give a comparative glance of the accuracy.

K-nearest neighbors

• Number of neighbors = 5

– Accuracy: 87.42% (+/- 1.52%)– Time elapsed during CV: 0.75s

Figure 22 Confusion matrix of k-nearest neighbor predictions

41

Random forest classifier

• Number of estimators = 10

• Max depth = 9

• Min samples split = 20

– Accuracy: 90.54% (± 0.96%)– Time elapsed during CV: 4.72s

Figure 23 Confusion matrix of random forest predictions

The classifier with best performance and lowest complexity is randomforest classifier. With a data set consisting of 9767 targets of class 0 and1909 targets of class 1 it has an accuracy of 90.54% (+/- 0.96%) afterits 10 folded cross validation. The confusion matrix shows that 10.93%of the mislabels are false negatives and 89.89% are false positives. Thisensures that more bad tires will be classed as good than the other wayaround which will avoid false alarms.

4.6.1 Optimization

Hyperparameters, filtering and data sets were changed to achieve higheraccuracy. Once random forest had been chosen as classifier the opti-mization began. During the optimization a 10 folded cross validationwas done 100 times and plotted as a histogram. First of all the filteringwas investigated.

Figure 24 (a) and (c) performs the best with both around 79.5% accu-racy. Upon closer examination it is seen that (c) has a slightly narrowerpeak and a higher frequency of the peak. This set the threshold of thevehicle speed standard deviation to be below 6 to be accepted. After

42

discussion with Drivec it was confirmed that a too large change in speedwould affect the classifier negative since it could interpret a large changeof speed as a loss of tire pressure. A too small change would not letthe classifier receive useful data which could be misleading for when itpredicts the label of the sample. A right amount of change in speed willbenefit the classifier since it will receive more useful data and not be ableto interpret the change of speed as a loss of tire pressure.

(a) Vehicle speed standard deviation < 0.5 (b) Vehicle speed standard deviation < 2

(c) Vehicle speed standard deviation < 6 (d) Vehicle speed standard deviation < 10

Figure 24: Accuracy of random forest with different filtering thresholdson vehicle speed standard deviation

43

Vehicles with more than 2 axles were excluded for the training data set.This increased the accuracy to around 82% which can be seen in Figure25.

Figure 25: Accuracy of random forest when only using data for vehicleswith 2 axles

44

The hyperparameters that have been used during optimization are num-ber of estimators, out-of-bag score and max depth of the random forest.

Hyperparameters

• Number of estimators

– The number of trees built for the forest

• Out-of-bag score

– The mean prediction error on each training sample xi usingonly the trees that did not have xi in their bootstrap sample

• Max depth

– The maximum depth of the tree

Figure 26: Accuracy of random forest with optimized hyperparameters

Figure 26 shows the accuracy of the classifier when the hyperparametershave the following values: Number of estimators: 10, Out-of-bag score:True, Max depth: 9.

45

The importance of confusion matrix was discovered and how this affectedthe predicted outcome. The confusion matrix of the predictions with thefeatures and hyperparameter values used for figure 26 are seen in Figure27.

Figure 27: Confusion matrix of random forest classifier seen in Figure26

Noticed was that 95% of the mislabels caused a good tire to be classed asbad which would cause a false alarm. This was avoided by modifying thetraining data set to include more vehicles with good targets than withbad.

To modify the data set to get more vehicles with good targets thanwith bad the targets were updated. The new targets are set to bad if thedifference in tire pressure is greater than 1.5 bar or if the thread depthdifference is greater than 6 mm. The new training data set includes 22vehicles where 18 of them have good targets and 4 of them have badtargets. The confusion matrix for the new data set is seen in Figure 28

Figure 28: Confusion matrix of final feature set

46

This shows that 89% of the mislabels cause a bad tire to be classed asgood. This behavior is preferable since it lowers the probability that amislabel will cause a false alarm.

After the new targets the final optimization was the usage of more deci-mals from the features. This change was made in the AI-stats software.The final accuracy of the classifier is seen in Figure 29

Figure 29: Final accuracy of random forest with new targets and increasedprecision on the values from the speed parameters of the datasets

4.6.2 Export of classifier

A recursive method has been created to export the trees of the randomforest in form of a JSON object to be used in JavaScript. Each node inthe tree has an attribute, a threshold and a left and right child if it is nota leaf of the tree. The leaf contain the score for class 0 respective class 1for which the one with highest value is set as label for the sample.

47

48

Chapter 5

5 Results - Cloud ImplementationThe implementation of the classifier in the cloud environment is presentedand explained together with the given approaches with results to increasethe understanding of the end result.

5.1 ModulesThe project group have implemented the module loading system that isthe core of Node.js which has been a demand from Drivec AB. Files andmodules are in one-to-one correspondence which mean that each file istreated as a separate module.

The ITMS module is a process from a vehicle instance of incoming data.The code used in the processor is written in JavaScript. In Figure 30the process of a replicating process of modules is shown. Each individual

Figure 30: Module process

ITMS process requires each classifier for each axle depending on whichones exist. NPM modules are a part of the ITMS module, it consistsof dependencies and development dependencies. In this case the devel-opment dependencies are the most interesting because it holds the test-processor framework developed by Drivec AB used by the project groupto unit test the processes before deployment. As figure 30 show the ITMSprocess can be replicated several times and therefore several vehicles can

49

be handled simultaneously. The development dependencies will not beused by the ITMS module when it is deployed at the cloud server. Theoutcome will be a predicted result if a tire is bad and therefore also good.

5.2 ClassifierThe classifier is implemented as a JSON object inside a JavaScript file asa result from the Python application that created the classifier throughtraining. The classifier is a a random forest that consists of 10 decisiontrees per classifier. In Figure 31 a deeper look into the actual part wherethe ITMS process requires the classifier module.

Figure 31: Classifier JSON module

5.3 Data managementThe ITMS process will need data to be able to classify if a tire is goodor bad. To be able to do the fetching, Drivec AB has developed anobservation functionality that will act as a listener to new incoming data.The ITMS process will do an observation and will be notified internallyas soon as a change has happened. The change is seen as an event whichthe project group catch and calculations are done from the event.

Event:

• Timestamp

• Wheel based speed

50

• Wheel based speed standard deviation

• Individual wheel based speed

• GPS speed

• GPS speed standard deviation

• GPS course change

• Brake pedal status

This event could be both triggered by the project group themselvesthrough unit testing with internal log files with the development de-pendencies or data provided from the AI-stats software inside the DrivecBridge. AI-stats will provide the data above as an average and stan-dard deviation of each value of a period of 10 seconds. However it doesnot matter from which source this is because the observation itself willbehave in the same way.

5.4 Data structuresThe ITMS module contain a data structure that the project group callsa state. This state will hold information about the vehicle instance e.g.data for different timestamps for unfiltered and filtered data.

State - General:

• First timestamp unfiltered data

• Start timestamp filtered data

• First run flag

• First filtering row flag

These timestamps are used within the process to perform predictions.This is covered under the subsection of incidents. The other part of thestate are confined to each individual axle.

State - Axles:

• Axle type

• Axle status

• Bad classes counter

51

• Bad predictions list

• FIFO(First in First out) queue good/bad classes

• Latest bad prediction

• Incident identification number

• Counter for indexing of FIFO queue

This queue store the good and bad classes from each prediction. The badpredictions list will hold the current prediction based upon the indexingof the FIFO queue. Every time a new bad prediction is made that isabove or equal to an internal threshold, the counter for bad predictionsincrements. The threshold value is discussed more under the subsectionof incidents. The prediction function is implemented in the process andprovides a result as a percentage of bad classes. To be able to performthis, the data must have been validated through a filtering function. Thisis done in the same way as in the training part in Python.

5.5 IncidentsIncidents in the ITMS processor contain the information that will bedisplayed in the reports in the cloud service. Incidents can be created andupdated depending on their state. Incidents and updates of an incidentoccur asynchronously on different vehicles and axles at the same time.The ITMS module also has a threshold value that indicate the lowestprediction value in percent to be accepted as a prediction bad enough toclassify as a bad.

5.5.1 Data structure

The data structure of an incident hold 3 major values that are interestingto display.

Incident - Data:

• Latest prediction

• Average value of prediction in the queue

• Axle type

In this data structure it does not say what vehicle it is nor what times-tamps the bad predictions happened. This is because that the actualvehicle id is already known in the incoming event. So when an incident

52

is created the cloud database already know that an incident belongs toa specific vehicle. As goes with the timesamp this is notified in the samemoment as it is sent to the cloud as an incident. There is not a needto know the timestamp of each individual bad classification because thiswould be overwhelming to analyze for the operator.

5.5.2 Threshold

The prediction value calculated from each run need to be greater than orequal to the threshold value that is set to 50%. This threshold is todayset inside the ITMS process but this could be extended to be set in thecloud service for further development.

5.5.3 Warning rate

The project group have been working with data that has been fetched bya rate of 10 seconds for each incoming event. The project group foundout that there will be a problem if the incidents are created as soon as awarning is indicated. The warning rate will represent that each predictedvalue need to have a time difference greater than 1 minute. There is nogreater time limit such as hours between each event. However if the latestprediction exceeds 1 day from the first ever registered event in this caseunfiltered the state will be reset.

5.5.4 Create new incidents

To create an incident the ITMS process need to reach the correct amountof bad predictions. The process will only accept predictions within theconditions for filtered data. The FIFO queue that hold the bad predic-tions has the size of 10. When the amount of bad predictions reach 7 theincident will be created if it does not already exist.

5.5.5 Update existing incidents

Note the FIFO queue will dynamically change size and the predictionswill be different over time. When the queue reaches 7 or more badpredictions it will update an existing incident and update the informationabout that incident.

53

5.5.6 Reset incidents

If the latest prediction exceeds the duration of a day compared to the firsttimestamp when the measurements began the ITMS process will startover and a new incident can be created on a specific vehicle. Howeverthe incident that was created before the reset will still be available in thecloud so the reset will only affect the processor.

5.6 Unit testsDuring the implementation of the modules the Mocha testing frameworktogether with the development dependencies provided by Drivec has beenused where tests have been performed in different areas.

Unit tests:

• Filtering

• Data structures

• Existing axles

• Bad class behavior

• Fake vechicle log data events

• Real vehicle log data events

5.6.1 Deployment

The unit tests have been performed under the supervision of Drivec ABand the company is currently the one in charge of when and how thedeployment will happen in the cloud. This is outside the scope of thepossible actions of this project group.

54

5.7 Output classifier - Real case scenarioThe ITMS process is proven to handle supervision in behaviour of inci-dents from bad to good on a given vehicle called A. Table 1 display theoffboard measurements used to verify the result. The workshop received

Table 1: Offboard measurements - Vehicle A

Date Timestamp Axle Wheel Tire Pressure Thread Depth17/03/03 09:07 Front Left 9.98 bar 20 mm17/03/03 09:07 Front Right 8.1 bar 12 mm17/03/17 09:32 Front Left 9.18 bar 14 mm17/03/17 09:32 Front Right 9.11 bar 15 mm

a report late in the evening the 16th of March from a bus driver thatstated that the tires of the front axle were in critically bad condition.The tires were changed the following morning the 17th of March 07:45.The project group had no information about this when it happened butit has been researched together with the data analysis from the givenvehicle.

Figure 32 show how the filtering that the ITMS process computed duringthe given time period. The yellow area is the actual amount of samplesbeing used for the predictions of the classifier. From every event row ofdata a given score will be set to conclude if the FIFO queue should addthe event as good or bad. The inner most circle represent the 3rd ofMarch followed by the 6th of March going all the way out to the 19th ofMarch. Figure 33 show the the total amount of updates each incidenthas each day. The inner most circle represent the 3rd of March followedby the 6th of March going all the way out to the 19th of March. Figure34 show the behaviour of the individual wheel speed between the frontright wheel and the front left wheel. The result indicates in this case thatthe right front wheel is rotating faster than the left. Which can be re-lated to the offboard measurements. When the tires were changed therewas a dramatic change in the behaviour. Figure 35 show the summaryof every score from each event. But not every prediction will be handledas mentioned before. But it is clear that the score has a dramatic changeon the 17 of March after the tire change. From these predictions theincidents are created and updated.

55

Figure 32: Dataset samples with results from filtering and predictionthreshold

Figure 33: Created incidents from the dataset samples

56

(a) Right wheel with left wheel speed

(b) Difference right wheel with left wheel speed

Figure 34: Individual wheel speed

57

Figure 35: Prediction on each filtered sample with a resulting score as apercentage

Figure 36: Vehicle distance per total dataset sample

58

The number of samples received depend on the driven distance by thevehicle that can be seen in Figure 36. The project group has found thatduring the weekends the distance is less for this particular vehicle andit may be hard to say that a certain distance can be represented of thenumber of incidents. This may vary depending on the vehicle.

59

5.8 Summary processFigure 37 represent the whole ITMS process which is repeated for eachaxle and for each vehicle instance.

ITMS flowchart step by step:

• Event with filtered data will go through the classifier

• Prediction is calculated and fetched

• Is the prediction greater than or equal to the threshold value?

• Append good or bad class to the FIFO queue of size 10

• Is the amount of bad classes enough to create or update an incident?

• Perform incident handling to the cloud

Figure 37: Flowchart of ITMS process

60

Chapter 6

6 DiscussionThe project group is satisfied with the outcome of the project and acase where a vehicles classification turns from bad to good has beenfound, which verifies the functionality of the classifier. The timetablehas been followed with the only exception that the JavaScript implemen-tation started one month earlier than expected to make sure the moduleused in the cloud will be ready to deploy at the end of the project.

There was a need to create a functioning system and therefore therewas no further examination of machine learning algorithms once randomforest had been chosen. We could do a whole thesis about machine learn-ing algorithms and which one suits which purpose best, but this was notthe intention during this thesis.

When doing the offboard measurements we measure tire pressure andthread depth. The tire pressure was measured by putting a tire pressuregauge over the valve of the tire. Some tires of the boogie and drive axledid not have valves to put the gauge on. This cause some measurementsof the tire pressure to be unknown. However on the boogie and drive axlethere are always two tires per side. The measuring of thread depth wasfocused on the center of the wheel, therefore there are no measurementsfor tires that are worn out at the sides, only the depth from the centeris being measured.

From the offboard measurements we look at the difference in pressurebetween left and right wheel rather than the individual pressure of thewheel. This was considered as the better choice to start with and italso prevents users from disbelieving the first version of the system whenwarnings are created, rather receiving a more accurate warning for thewhole axle than possibly incorrect warnings for the individual wheels.With the results from the classifier the warnings can be analyzed to cre-ate greater insight to solve problematic areas for further developmentwhen the time comes to try to pinpoint out specific wheel behaviour.

The system is currently an alpha version and is being tested internallyat Drivec. To deploy it the Drivec Bridge needs to get a software updatewhich adds the AI-stats software to it. AI-stats is not officially releasedyet. Once it is released it will enable our module to receive correct datafrom any given vehicle.

61

62

Chapter 7

7 Conclusion And PerspectivesIn this thesis a supervised machine learning approach of an indirect tiremonitoring system is proven. This approach is using random forest asclassifier and will receive real time data within a 10 second interval. Thetraining of the classifier is done in Python and the classifier is exportedto be used in a Node.js module in the cloud. The most common encoun-tered issue with indirect tire pressure monitoring solutions is when alltires of the vehicle loose tire pressure simultaneously. This has tried tobe avoided by using more features in addition to individual wheel speed.

The European-Union law does not apply to heavy duty vehicles hencevery few of them use a TPMS. It is difficult to say how well other solu-tions work for heavy duty vehicles but for passenger cars they work wellsince it has become a legal requirement. There is currently no producton the market that works in the same way as the tire monitoring systemdeveloped in this thesis. The most similar product on the market is anindirect Tire Pressure Monitoring System (iTPMS) where the softwareuse the vehicles ABS-system to receive data. Furthermore the data aboutthe tires is kept in the vehicle and is only displayed for the driver. Themost significant difference with the indirect tire monitoring system inthis thesis is that it will not display any information to the driver butwill be a part of the fleet management system in the vehicle and showthe data back-end for the operator.

The predicted outcome did match the expected result and a classifierfor tire condition was created. The first idea was to have 2 classifiers,one for tire pressure and one for thread depth. After discussion withDrivec we came to the conclusion that only one classifier should be cre-ated and that it should not point out if it is the tire pressure or threaddepth that is under acceptable limits. The classifier will only tell if thetires condition is bad which can depend on an underinflated tire or toolow of a thread depth.

The cloud service will receive its data from the Drivec Bridge. It col-lects and interprets data which is sent to the Ethernet port accordingto a TCP/IP protocol called DP (Drivec Protocol). In this part of thecloud service the software AI-stats mentioned in 3.6.2 will be used byDrivece Bridge to make sure the classifier in the cloud service receivesinterpreted data.

63

The chosen algorithm is random forest 3.3.2. Scientific research[28] hasbeen found and investigated about this algorithm.

The chosen programming languages are Python and JavaScript. Pythonis used for the training and analysis of the classifier. It was chosen mainlybecause of the scikit-learn toolbox which was suggested by our supervisorYuantao Fan. The cloud system is build on JavaScript and therefore thisis needed as a programming language to integrate the classifier modulewith the rest of the system.

The algorithm is tested by cross validation in Python and by unit testingin JavaScript.

The most suitable method for this project is random forest. Not onlybecause of its performance but also to avoid any type of training of theclassifier in the cloud. The solution with random forest is agile and fromPython the different trees of the forest are exported as a JSON objectand put into the module. Support vector classifier was also tried tobe implemented in JavaScript without success. The classifier would notdo any classifications without any training. By avoiding training in thecloud for random forest the process will be faster and not consume toomuch CPU power. If a new forest is needed, e.g. with new features, thiscan be done in a matter of seconds with the available Python code anduploaded to the cloud.

The most significant issue with random forest is overfitting. Randomforest generally give good results which is why it is needed to be ana-lyzed properly to avoid overfitting. Too large number of trees or too largedepth of the trees is also an issue which may make the algorithm slowfor real-time prediction.

7.0.1 Requirements for technical product development

Seen from an environmental perspective this solution is more sustain-able than the current direct TPMS solutions. The sensors used in directTPMS require a non-replaceable battery which increases the toxic elec-tronic waste. In addition to this countries with legal requirement ofwinter tires will also benefit from a indirect TPMS solution like ITMS.There is no longer a need of buying sensors and installing them into thenew tires.

To be able to use this projects ITMS solution the vehicle need to have the

64

Drivec Bridge installed and also pay a monthly fee. Having the DrivecBridge installed and paying the monthly fee not only enables the ITMSbut a variety of other functions. Even though the cost of the system theoperator will have an economic benefit by instantly receiving a warningwhen the tires pressure or thread depth are under acceptable limits. Cor-rect tire pressure leads to less tire wear, lower fuel consumption and saferdriving. Important to keep in mind is that this solution is for heavy dutyvehicles and not private owned passenger cars. The costs are fairly lowfor an operator and should never exceed the amount they save.

The solution is not oriented towards the driver of the vehicle but thevehicle itself. The driver is never exposed in the ITMS system and nei-ther a part of the incident created. Therefore the integrity issue is puton the operator.

7.1 Future optimizationFor future optimization the possibility of an incorrectly adjusted axle willbe analyzed. Some vehicles may have an equal wheel speed distributionas seen in Figure 14 even though the vehicle have incorrect tire pressure.This can be discovered by investigating energy consumption (kW/h) perkilometer. The solution is to add an individual off-set for the vehicleswith incorrectly adjusted axles in order to have correct data sent into theclassifier.

This project only use city buses. For further development all kind ofheavy duty vehicles will be used, both trucks and regional buses. Thepossibility of classifying faults of other components (e.g. ABS-sensors)with the same approach could be a part of a future solution.

65

66

8 References

[1] National Highway Traffic Safety Administration. Tire pressure mon-itoring system. FMVSS No. 138, 2001.

[2] National Highway Traffic Safety Administration. Evaluation of theeffectiveness of tpms in proper tire pressure maintenance. DOT HS811 681, 2012. (Cited on page 6).

[3] National Highway Traffic Safety Administration. Tire-related factorsin the pre-crash phase. DOT HS 811 617, 2012. (Cited on page 6).

[4] Sunil Arya, David M Mount, Nathan S Netanyahu, Ruth Silverman,and Angela Y Wu. An optimal algorithm for approximate nearestneighbor searching fixed dimensions. Journal of the ACM (JACM),45(6):891–923, 1998.

[5] National Marine Electronics Association et al. NMEA 0183–Standard for interfacing marine electronic devices. NMEA, 2002.

[6] Stefan Byttner, Thorsteinn Rögnvaldsson, and Magnus Svensson.Consensus self-organized models for fault detection (cosmo). Engi-neering applications of artificial intelligence, 24(5):833–839, 2011.

[7] Youngmin Cho and Lawrence K. Saul. Kernel methods for deeplearning. In Y. Bengio, D. Schuurmans, J. D. Lafferty, C. K. I.Williams, and A. Culotta, editors, Advances in Neural Informa-tion Processing Systems 22, pages 342–350. Curran Associates, Inc.,2009.

[8] Tarmo Remmel John R. Miller Connie Ko, Gunho Sohn. Maximizingthe diversity of ensemble random forests for tree genera classificationusing high density lidar data. 2016. (Cited on page 5).

[9] Yuantao Fan. A Self-Organized Fault Detection Method for VehicleFleets. Licentiate thesis, Halmstad University Press, 2016.

[10] David Flanagan. JavaScript: The Definitive Guide (6th ed.).O’Reilly & Associates. ISBN 978-0-596-80552-4. O’Reilly, 2011.

[11] Tadayoshi Fushiki. Estimation of prediction error by using k-foldcross-validation. Statistics and Computing, 21(2):137–146, 2011.

[12] Inc Global Industry Analysts. Tire pressure monitoring systems - aglobal strategic business report. 2015.

67

[13] Marusic S Palaniswami M Gubbi J, Buyya R. Internet of things(iot). A vision, architectural elements, and future directions. FutureGeneration Computer Systems, 29(7):1645–1660, 2013. (Cited onpage 1).

[14] W.H. Huang. Tire pressure monitoring system, July 5 2016. USPatent 9,381,778.

[15] SAE International. Surface vehicle recommended practice. J1939-71, Vehicle Application Layer, 2012.

[16] Hillol Kargupta, Vasundhara Puttagunta, Martin Klein, and KakaliSarkar. On-board vehicle data stream monitoring using minefleetand fast resource constrained monitoring of correlation matrices.New Generation Computing, 25(1):5–32, 2006.

[17] M. Barbosa M. Farsi, K. Ratcliff. An overview of controller areanetwork. Dept. of Electr. & Electron. Eng, Print ISSN 0956-3385,Online ISSN 1741-0460, 1999.

[18] Mohamad T Musavi, Wahid Ahmed, Khue Hiang Chan, Kathleen BFaris, and Donald M Hummels. On the training of radial basisfunction classifiers. Neural networks, 5(4):595–603, 1992.

[19] Fabian Pedregosa, Gaël Varoquaux, Alexandre Gramfort, VincentMichel, Bertrand Thirion, Olivier Grisel, Mathieu Blondel, PeterPrettenhofer, Ron Weiss, Vincent Dubourg, et al. Scikit-learn: Ma-chine learning in python. Journal of Machine Learning Research,12(Oct):2825–2830, 2011.

[20] Joao Pedro Lebre Magalhaes Pereira. Supervised learning for rela-tionship extraction from textual documents. 2013.

[21] Niclas Persson, Fredrik Gustafsson, and Markus Drevö. Indirecttire pressure monitoring using sensor fusion. Linköping UniversityElectronic Press, 2002.

[22] Tomas Poloni and Jianbo Lu. An indirect tire health monitoringsystem using on-board motion sensors. In SAE Technical Paper.SAE International, 03 2017.

[23] Rune Prytz. Machine learning methods for vehicle predictive mainte-nance using off-board and on-board data. Licentiate thesis, HalmstadUniversity Press, 2014.

68

[24] Bernhard Scholkopf and Alexander J Smola. Learning with kernels:support vector machines, regularization, optimization, and beyond.MIT press, 2001.

[25] Alex J. Smola and Bernhard Schölkopf. A tutorial on support vectorregression. Statistics and Computing, 14(3):199–222, 2004.

[26] Arijit Chakravarty (Editor) Anthony Davies (Associate Editor) Car-oline Shamu (Associate Editor) 978-0-470-62456-2 Page 231. StevenA. Haney (Editor), Douglas Bowman (Editor). An Introduction ToHigh Content Screening: Imaging Technology, Assay Development,and Data Analysis in Biology and Drug Discovery. Kindle Edition,2014.

[27] Sander Maas Carmen Rodarius Sven Jansen, Antoine Schmeitz. Eutender tyre road safety. TNO 2014 R11423-v2 | Final report, Studyon some safety-related aspect of tyre, 2016. (Cited on page 15).

[28] Vladimir Svetnik, Andy Liaw, Christopher Tong, J Christopher Cul-berson, Robert P Sheridan, and Bradley P Feuston. Random forest:a classification and regression tool for compound classification andqsar modeling. Journal of chemical information and computer sci-ences, 43(6):1947–1958, 2003.

[29] Mostafa Anwar Taie, Eman Magdy Moawad, Mohammed Diab, andMohamed ElHelw. Remote diagnosis, maintenance and prognosisfor advanced driver assistance systems using machine learning al-gorithms. SAE International Journal of Passenger Cars-Electronicand Electrical Systems, 9(2016-01-0076):114–122, 2016.

[30] Pedro Teixeira. Professional Node. js: Building Javascript basedscalable software. John Wiley & Sons, 2012.

[31] Distr.: General United Nations. World forum for harmonization ofvehicle regulations. Consolidated Resolution on the Construction ofVehicles (R.E.3), pages 4–6, 2014. (Cited on page 6).

[32] Paul E Utgoff. Machine learning of inductive bias, volume 15.Springer Science & Business Media, 2012.

69

70

AOffb

oard

Measurements

Figu

re38:Offb

oard

measuremen

tsof

front

axle

pressure

71

Figu

re39:Offb

oard

measuremen

tsof

front

axle

thread

depth

72

Figu

re40:Offb

oard

measuremen

tsof

driveaxle

pressure

73

Figu

re41:Offb

oard

measuremen

tsof

driveaxle

thread

depth

74

Figu

re42:Offb

oard

measuremen

tsof

boogie

axle

pressure

75

Figu

re43:Offb

oard

measuremen

tsof

boogie

axle

thread

depth

76

BTim

eTab

le

Figu

re44:Tim

etable

77

78

79

PO Box 823, SE-301 18 HalmstadPhone: +35 46 16 71 00E-mail: registrator@hh.sewww.hh.se

Oskar Svensson - Computer ScienceEngineer

Simon Thelin - Computer ScienceEngineer