One of the main challenges within the automotive industry today is finding a solution that allows for efficient automotive fleet management. As our vehicles become more connected and require more security and safety than ever before, it becomes extremely important to have a fleet management solution that provides seamless software updates, data analysis and other functionalities.

This implies targeting multiple components and functions on both the onboard side (the vehicle), and the offboard side (the cloud), and targeting various functions within each system. In other words, managing an automotive fleet is becoming a lot more like managing a fleet of devices. Let’s explore what this means in practice and how OEMs can apply principles used by software companies to tackle this.  

Vehicle-related APIs

There are two levels of potential Application Programming Interfaces (APIs) or abstraction layers in vehicles today. The first one is between the silicon and the onboard software; the second one is between the onboard software and the offboard software.

Having well-documented and easy to use APIs between the onboard and offboard components enables seamless and efficient software updates over-the-air throughout a fleet of vehicles.

Onboard 

On the onboard side, components need to be able to communicate with each other and with the vehicles’ cloud backend. In legacy vehicles,  components communicate using a CAN-bus. In more modern vehicles, they use an ethernet gateway. These components are usually System on a Chip (SoCs) and Electronic Control Units (ECUs).

Managing a device requires the ability to read the device’s status but also to write on the device. For example, to apply a configuration change, a security update, or an OS upgrade.

The vehicle will rely on a Telematic Control Unit (TCU) to connect to the internet and by extension to the OEM Cloud. The TCU basically acts as a modem allowing access to online services. This TCU will also require seamless security updates and upgrades.

Offboard

From the offboard point of view, the vehicle needs to be as easily manageable as possible. The more variants you have in terms of device access, the more complicated it will be to handle multiple facelifts (lifecycle changes) of a vehicle model. Ideally, this should resemble an API; all of the vehicles in a fleet should follow the same attributes and access processes regardless of the model.

This approach would also add clarity as to which type of information should be provided by each device, as the data would need to comply with specific attributes and definitions. For example, the data format would need to be the same for all vehicles, which will eliminate uploads of various units for the same data type. In a perfect world, multiple brands could use the same approach leading to a unified interface – this would be very useful for asset management by B2B companies (ie. rental companies using various vehicle brands).

If each vehicle has the right level of abstraction, it becomes fairly easy to handle millions of vehicles at a time. One major question then comes to mind: who gets access to the vehicle and its data?

Device management portals and controlled data access

OEMs and vehicle owners (whether they are corporations or individuals) need a secure way to monitor their vehicles and update their embedded components from infotainment to advanced driver-assistance system (ADAS) by way of the powertrain. One of their main difficulties is ensuring controlled access to sensitive data.

Even without taking GDPR constraints into account, car owners wouldn’t want the manufacturer to be able to access the location of their vehicle. Same for a company handling hundreds of vehicles. An OEM may not want an individual from another company to access strategic maintenance data, such as the state of charge projections on an EV’s battery or the powertrain tuning of a specific car model depending on specific conditions.

This means there needs to be pre-configured access rights for each item, with multiple levels of access. This is very similar to database rights handling. These rights will probably be changeable depending on the state of the vehicles (in the factory, at the dealership, in use by user x, owned by owner y, etc)  but will ideally rely on the same approach independently of the vehicle brand.

We can envision three main groups of users:

• Manufacturers: this includes the OEMs and their suppliers (Tier-1s, etc).
• Asset managers and B2B owners: this includes rental companies, business fleets, etc.
• Individuals: this includes the driver of the vehicle, whether they are B2B users or B2C owners.

This approach makes a lot of sense because data usage varies a lot, depending on the group of users. As an OEM,  you’ll want to access telemetry data for predictive maintenance. You’ll also want to push security updates and patches. For example, you’ll need to install patches on all concerned vehicles over the air if there are critical vulnerabilities present in autonomous driving software.

As an asset manager (let’s assume a corporation handling millions of rental vehicles), you’ll want to locate vehicles and force install key applications. For example, a rental company could benefit from finding stolen vehicles remotely and preventing access to the throttle.

We believe that using proven approaches for software updates and data ownership, like the ones being used in the computer, smartphone, or cloud industries for years, is what makes the most sense for industries that are moving towards software, including automotive.

Software is steering automotive in new directions, but you don’t have to reinvent the wheel

When you look at the computer industry, there isn’t one backend per computer brand or motherboard brand to obtain the newest version of an OS. The same goes for the drivers of said computer. When you look at the smartphone industry, you expect the same OS version to be compatible with a maximum number of devices. When you look at the cloud industry, the more agnostic you are in terms of cloud providers, the more flexible you can be in your operations.

Some OEMs will prefer to rely on their in-house proprietary solution with specific configurations for each model. Others will require an open-source holistic approach with key state-of-the-art features that all OEMs can benefit from. This second solution will most probably be more flexible, always up-to-date, and, of course, more secure as it will guarantee data readability based on data ownership. Open source can provide a shared and unique interface between hardware and software coming from multiple suppliers. Said flexibility is a key asset allowing organisations to reduce complexity in the world of software-defined vehicles.

Building a tighter connection between a fleet of devices and the servers managing them allows for more efficient device monitoring and upgrading. Simplified and seamless software updates ensure devices are always secure, hence limiting painful and costly vehicle recalls for maintenance that could be done over-the-air. The first step to achieving the right level of abstraction will rely on the deployment of software-defined vehicle principles. The second step relies on cost-effective device management solutions and controlled data access.

Contact Us

Curious about Automotive at Canonical? Check out our webpage!

Want to learn more about software-defined vehicles? Download our guide!