COMPREDICT Platform Architecture — Part 2: in-car logging software
By: Vitalij Funk
Tags: Artificial Intelligence, Predictive Maintenance, Platform, Machine Learning, Automotive

Co-written by Simon Sander

Nowadays, collecting data from every kind of components and systems has already moved in the focus of several industry areas. The automotive industry is one of the pushing sectors accelerating the data logging of millions of cars. This data can contain information about the electrical, mechanical or thermal state of several different vehicle components. The challenge is to not only log and store this data but rather to log the big amount of information over a car’s life without information loss and with high sampling rate. Further challenge is to extract the right information from this large amount of data.

in-car logging hardware

We at COMPREDICT are able to not only collect data from vehicles in an accurate way but also to pre- and post-process, stream, save, analyze and visualize it. To demonstrate our real-time algorithms to our customers, we applied our Tesla Model 3 with our in-car logging hardware and some additional analog sensors. In the following, we will give an overview of the software parts which are running on our in-car logging hardware. Starting with the overview of the software services, a short introduction to our engineering capabilities like virtual sensors, load spectra computation and damage prediction follows. Then, we will explain the real-time visualization and analytics interface which is used to showcase our proprietary algorithms. Finally, we will introduce the connection to our datalake and analytics platform.

Pipeline

Our in-car logging software distributes the measurements of physical conditions in a vehicle over an inter-process communication mechanism to process the data, visualize the outputs of our algorithms in real-time and upload the data to our datalake. The following picture describes the basic flow of our in-car logging software.

in-car logging software overview

At the beginning of the logging process, physical conditions of the car are recorded from different sources, in our case the Control Area Network (CAN bus) and some additional analog sensors. Therefore we built small software packages (logging services) which collect these data and distribute them over an inter-process communication.

We went for an inter-process communication to have a clear interface for further program parts on the one hand and not to suffer any loss of speed on the other hand. Here we use the ZeroMQ messaging library due to its high distribution and third-party bindings for many popular programming languages. Furthermore, we standardized the data structure of our distributed data with Protocol Buffers to achieve a simple and high-performance serialization and deserialization of the data records.

Since the data of the CAN bus and the analog sensors are sent at different sampling rates, the data is synchronized centrally in the logging services. This synchronization is implemented with a zero-order holding block, so that all data records belonging to a sample interval are broadcasted in an atomic step. All other services that want to process this data can subscribe to the data via the Publisher/Subscriber pattern and always receive the most current data at an evenly spaced exact interval.

The collected data is currently subscribed by three data-processing services, which are discussed in detail in the following sections.

Virtual sensors, load spectra computation and damage prediction

In the Algorithm-Module Service, we pre- and postprocess the available signals with precompiled models. These models represent the basis for our virtual sensors, load spectra computation and damage prediction. As described in detail in the previous article, we at COMPREDICT develop virtual sensors. That means that we are fusioning already available signals in order to generate additional information, which is either non-measured or non-measurable. The reason why we are doing this is simple.

Let us take an example. Cars are very complex systems, full of electronic and mechanic devices. In order to perfectly control or assess the current status of the entire system, sensors are required that measure physical quantities such as torque, force, temperature, pressure, friction, wear etc. However, due to high costs, space limitation or reliability issues, dedicated physical sensors are not implemented for every component and system in series-production cars. In most passenger cars, the signal transmission and communication between control units, sensors or actuators takes place via CAN bus. To close the gap of limited physical sensor application and to be able to have sensing capabilities on all damage-relevant vehicle components without running in above-mentioned aspects, we have developed a strong expertise in the AI-based virtual sensor technology over the last years (see an example of virtual sensor in the following figure).