Machine Learning — Diagnosing faults on vehicle fleet trackersThis article presents a data-driven solution to diagnose faults on vehicle fleet tracking modules.
Luis MeazziniBlockedUnblockFollowFollowingApr 8Figure 1: https://www.
shortlandinsurance.
com/module_resources/page_management/36/Fotolia_37500680_L.
jpgIntroductionMany transport and logistics companies use modules to track their vehicles, and it is not unusual that some modules are not working as expected.
The tracker might need to be discarded, wrong data from the vehicle can be collected, or technical support can be sent a long distance away to analyze the problem, for example.
Thus, it is essential to conduct a remote fault diagnosis on those modules since, when they show failures, financial losses can occur.
Since these modules continuously send data to a database, the aim of this research is using this data to diagnose faults on the modules.
It was necessary to develop a methodology to pre-processing the collected data sent by the vehicle modules.
After this, machine learning techniques were applied to create models, which were analyzed and compared.
However, what is a fault?Faults are an unallowed deviation of at least one property or a characteristic parameter of the system [1].
And, there are three steps to diagnose faults, which are:Fault Detection: is the most basic task of fault diagnosis, it is used to check for malfunction or failure in the system and to determine when the fault occurs;Fault Isolation: the isolation serves to detect the location of fault or which is the defective component;Fault Identification: the identification is used to determine the type, format and size of the fault.
Generally, the fault identification process consists only of Fault Detection and Isolation (FDI).
This does not negate the utility of fault identification.
However, this process may not be essential if no reconfiguration action is involved [2].
DevelopmentFirst of all, to perform any machine learning solution, data is needed.
For this case study, a Brazilian logistics company provided some data sent by many trackers, so all the data used is real.
Problem descriptionThe modules installed in the vehicles send data during their entire period of operation.
The company provided 12586 registries.
The company provided 12586 registries.
A registry is composed of all the data transmitted by one module in one day period.
On average, each module sends 1116.
67 points per day.
Each point has eight attributes:Battery Voltage: Float value for voltage of the vehicle battery;Longitude: Float value for the vehicle longitude;Latitude: Float value for the vehicle latitude;Ignition: Boolean value indicating whether the ignition isswitched on;Odometer: Float value for the vehicle odometer;GPS Signal: Boolean value indicating whether the GPS signalis valid;Velocity: Float value for the vehicle speed;Memory index: Integer value for the memory position that thepoint is saved in the module.
Since the modules send data regularly and on different frequencies according to each module, each registry has a different size.
This way, the size of each registry is the number of points sent multiplied by 8 (quantity of attributes).
The aim is identifying the faults that a registry can have or if it is working correctly.
This way, this is a multi-class classification problem, where there are eight classes; one class for the registries without faults, and seven possible faults, listed below:Fault 1: Wrong pulse set up;Fault 2: Odometer locked;Fault 3: GPS locked;Fault 4: Ignition wire released;Fault 5: Accelerometer defective;Fault 6: Module buffer with problem;Fault 7: GPS with jumps in location;Some of these faults have several occurrences too low.
The flaws that had less than 3% were all labeled as “Others”.
The quantity of data of each failure can be seen on the left.
Data pre-processingSince the feature extraction process is an extensive pieceof work and dramatically impacts the final result [3].
This approach uses knowledge from the system to perform a data transformation to significantly reduce the data dimensionality.
The initial attributes are time series (battery voltage, latitude, etc.
), and from them, I have created 21 new attributes shown on the table below.
After this, data transformation converts the original data from 2-D to just one dimension.
Most of these new attributes can be calculated easily and, therefore, there is no complicated formula or algorithm for this.
New Attributes description table.
Most of the attributes are binary, so they do not require normalization.
However, attributes such as the number of points, data regarding battery voltage and jumps in the memory index can be normalized.
Since an analysis of the outliers has not been done, a traditional normalization can cause the data to be suppressed by some high value, so RobustScaler is used.
This scaler uses the first and third quartiles as constraints and not the maximum and minimum values, so this normalization is more robust and maintains the outliers.
Since some attributes can have a high correlation to others, all the possible correlations were calculated.
The Longitude and the Latitude Variation have a Pearson correlation of 0.
996315, which in most ML projects suggest we should discard one of these attributes.
However, since the objectives of the models are diagnosing faults in the GPS of the module, both attributes are useful despite the high correlation.
Furthermore, there is a high correlation between the number of points and the number of points with invalid GPS, 0.
962769.
This occurs since the number of points is the sum of the number of GPS points that are valid with the number of invalid GPS points.
Therefore, due to this linear combination, the attribute “number of points” was discarded.
Finally, the date and serial fields are also discarded, as they are to identify the vehicle and module and do not provide any information about the module operation.
Training the ML modelsIn order to run the algorithms, the datasets were separated into a training and a test set.
For every experiment, 20% of the registries were for testing and 80% for training.
I wanted to figure out what traditional algorithm works better for this data, so I tested each one oversampling the data and undersampling.
Considering the ML techniques, all Random Forests were made using 100 estimators and all MLPs were done with architecture (5, 10, 5), lr = 0:001 and 200 maximum iterations.
The obteined metrics can be seen on the table below:The normalized confusion matrix for the Random Forest, with oversampling can also be seen below:In addition to the evaluation metrics for ML techniques, the training and evaluation time of the models was also calculated.
This time was, in the worst case, 0.
37ms, what can be considered a real-time response for the applicationin this case study.
ConclusionsAs proposed, these models can detect and identify faults on vehicle fleet tracking modules with high-performance metrics.
However, there was extensive feature engineering, which could be performed automatically by an LSTM or CNN.
I also, made some CNN’s models to make this fault diagnosis, maybe I’ll detail it in the next article.
The limitations of the employed methods includes the inability of the models to discover faults that are not mapped, so any faults which have not been learned would be mis-classified to be one of the known ones.
As in the article, there was not any code, feel free to check it out on my GitHub repository.
lmeazzini/Tracker-fault-diagnosisFault Diagnosis models the detect and identify faults on vehicle fleet tracking modules.
…github.
comReferences[1] D.
van Schrick, “Remarks on terminology in the field ofsupervision, fault detection and diagnosis,” IFAC ProceedingsVolumes, vol.
30, no.
18, pp.
959–964, 1997.
[2] D.
Wang and W.
T.
Peter, “Prognostics of slurry pumps basedon a moving-average wear degradation index and a generalsequential monte carlo method,” Mechanical Systems andSignal Processing, vol.
56, pp.
213–229, 2015.
[3] L.
Wen, X.
Li, L.
Gao, and Y.
Zhang, “A new convolutionalneural network-based data-driven fault diagnosis method,”IEEE Transactions on Industrial Electronics, vol.
65, no.
7,pp.
5990–5998, 2018.
.