Virtual sensors are preferable when one or more of the following are true: the desired physical quantity is very complex to measure, the hardware sensors might fail in the targeted operating conditions, the hardware sensor is too expensive to be implemented at large scale, the desired information is not measurable continuously and directly.

Once they are trained, virtual sensors require no maintenance, as they are software-based. They do not break or fail even in harsh environmental conditions. They can be scaled conveniently at a small incremental cost.

While such technology exists, COMPREDICT focusses on virtual sensors based on time series data, i.e. data points of quantities like force, voltage, current, temperature, pressure etc.

The virtual sensors use standardly available signals and data from the given vehicle or device.

Any mechatronic device can benefit from virtual sensors: vehicles as well as stationary assets.

Any motor vehicle which is suitable to transfer data or to be equipped with telematics for data transmission. This includes scooters, passenger cars, light trucks, long haul trucks, other industrial vehicles and even trains.

Some of our virtual sensors, like 12/24V battery monitoring, tire wear or vehicle mass, work off the shelf after automated self-parameterization. For typical R&D applications like steering forces, wheel torques, chassis forces, and general automotive component load and fatigue, the virtual sensors usually need to be initially trained.

In case of a customer specific R&D application, you can provide us with data already gathered in one of your test vehicles, or you would start with performing reference measurements with the physical sensors that you would like to replace in order to collect data. Based on your sample data, we can then check the feasibility and expected quality of the requested virtual sensor.

Virtual sensors show excellent reliability when interpolating within known operating conditions. They are less predictable when extrapolating to conditions on which they have not been trained. For this reason, we suggest to always include in the reference measurements the operating conditions that are important to you.

Virtual sensors should be trained under all operating modes that you want to be covered and that are relevant for your application case. You would ideally seek to train them in conditions where the targeted physical quantity shows high variation.

Harsh operating conditions should be included in the training campaign, at least during short measurements, if they must be part of the validity domain. Examples of rough but interesting conditions are slipping wheels, corrugated roads, emergency braking or harsh braking.

Both is possible: We can train virtual sensors on historical data. While this is possible, we recommend involving us already during the physical measurements campaign, so that we can take appropriate action quickly in case e.g. one data acquisition channel fails or is missing.

It is of course possible to train a virtual sensor only in dry weather conditions and still have a good quality for other weather conditions. Depending on which physical quantity you are looking at, we would check together with you the potential impact on the validity domain of the virtual sensor.

Training a virtual sensor on a test stand and deploying it for road tests is an excellent example of the power of virtual sensors, because they do not rely on lab conditions. The opposite example is not always true: training a virtual sensor on the road and using it in laboratory conditions requires special attention, typically because the virtual sensor cannot then rely on signals like acceleration when operated in a stationary lab.

According to good engineering practice, the frequency of the input data should be at least twice the frequency of the physical phenomenon you want to investigate. A higher data frequency will yield a higher precision of the virtual sensors. Having said this, we have already demonstrated that we can work with infrequent or oversampled data. Get in touch with us to discuss if this can be applied to your specific use case.

Our virtual sensors require time series data, typically but not limited to CAN-bus, FlexRay signals or similar. These raw data can be decrypted with a so-called DBC file (CAN database file). Typical channels for a use case in vehicle longitudinal dynamics would be vehicle speed, engine speed and torque, wheel speeds and the like. When looking at the battery and E/E system, we would rather need voltage, current, and temperature signals. In the best case, you give us access to all the data that you can access to, and we select the best ones with our feature selection pipeline. Alternatively, we can also define a tailored short-list according to our expertise on the given application case.

We can, under certain conditions and unless we are bound by a non-disclosure agreement, perform reverse engineering of the raw CAN-bus signals of a vehicle. This is what we have actually done on our Tesla Model 3 demo car. Contact us for a quick feasibility check.

Just send us a set of sample data, together with what insights you want to obtain, and our data science and domain expert teams will check it and get back to you. We are very much used to adapting to variable input data quality.

Signals from heavy duty vehicles are standardized to a certain extent. Interfacing and interpreting signals from such vehicles is usually more straightforward than for passenger cars.

Either your vehicles are already equipped with a telematics device or some sort of data connection, we would adapt to the interface you provide us. If such an interface is not available, we can provide similar dataloggers than the one in our demo car, in limited numbers, for pilot projects and R&D applications.