Vehicle Modeling

The hardware of our cars—parts and assemblies—is expected to hold together fast, and in this spirit automobile manufacturers have bolted and welded firmly for more than a hundred years. Our decade, though, sees a radical shift with the advent of the software-defined vehicle, and with software things are different. The paradigm here is to loosely couple modules, a topic we have written about in a previous blog post.

This article series covers the role of software for the future of the vehicle and the vehicle of the future. Today our topic is an aspect in the maintenance of software that is in fact connected to loose coupling, configuration management.

Loose Coupling

The term of coupling refers to the degree of interdependence between modules, or in other words, the measure of how much a change in one component affects other components in the system. Loose coupling implies clear contracts among elements of a system, defining their interactions. When properly implemented, the inner workings of units, assemblies, even whole systems do not play a role any more for many operations because they are abstracted away.

An example of loose coupling that has become ubiquitous in recent years is application programming interfaces (APIs). Requests and responses use standardized formats and everyday users are relieved of concerns about what happens beyond this interaction.

Configuration Management

Configuration management, on the other hand, has the entire system in view. Configuration management evaluates proposed changes, tracks the status of changes, and maintains an inventory of system and support documents. It can be defined as the practice of handling changes systematically so that a system maintains its integrity over time. 

Configuration management considers the entire system, regardless of coupling. While a loosely coupled system provides benefits like less risk in enhancing the product or software and better speed to market, this system of independent elements still needs to be properly managed, and knowledge of the current state and relationships in the system is a necessity. Properly implemented, the concepts together can yield optimum results.

The advent of the software-defined vehicle necessitates and enables a higher rate of iteration through processes like updates, patches, and new features. Keeping the integrity of the whole system intact is an important overarching goal. Components of this goal are to leave the system in a known correct state, to be able to have an accurate record of the changes made, and to always have a live/current state of all systems.

This sounds clear enough, but given the massive scale in the vehicle industry, with the presence of phenomena like vehicle sub variants, trim classes, and new features which might all require different configurations of hardware and software to be maintained, it is not trivial in practice.

The Situation in Automotive OTA

While updates of a single electronic control unit (ECU) will often work just fine on the workbench, real-world conditions render updates, and configuration management with them, a challenge in the automotive sector, in particular when done over the air.

Let us consider a scenario that involves a fleet of ten thousand vehicles with 70+ ECUs or independently updatable applications in each vehicle—a very small fleet size by OEM standards. Among the problems that arise in such a framework is that any number of vehicles may not be in reach at any given time. They might be out on the road in a remote area, sit disabled in a shop, or be subject to some other circumstance that disconnects them. These circumstances are beyond the control of anyone responsible for rolling out new software. For such reasons, software rollouts rarely reach completion and the software version state of a given vehicle may differ from what is expected.

An even more important aspect is that vehicle architectures may vary, even with vehicles of the same type. In such a fleet, many permutations and combinations of hardware and software might be found, which means in turn that appropriate permutations and combinations of software updates are to be applied. While theoretically it may be feasible to roll out updates only to subgroups of vehicles with strictly identical architectures, it would create unnecessary effort. Another approach would be to dictate the right software for every unique permutation, but this option is highly complex and too time consuming.

Together, these factors mean that, when rolling out an update, any number of possible in-vehicle software and even hardware permutations have to be covered by the system. Compare this to an update of a unit on the workbench—a unit that is in reach, the architecture of which is clearly defined and the update status of which is known—and it becomes clear that a vastly different toolset is needed.

Now, how to put this into practice? On a high level, we have identified three key steps to achieve proper software configuration across a fleet of vehicles as new software is developed:

1. New software is made available for a component or for multiple components of vehicles in a fleet.
2. The determination is made as to which vehicles in the fleet should receive the update based on compatibilities in vehicle architecture, vehicle parameters, or business goals and objectives.
3. To then update software across a fleet, it should only be necessary to specify the target state for the chosen vehicles, and the system should automatically create a plan for the most efficient way to bring vehicles to the target state based on each vehicle's current configuration or combination of parameters.

The Task

To sum it up, a desired target state has to be defined and achieved, even given an unknown current state and a variety in hardware architectures. Every single ECU will have to be considered and verified against this target state to keep the integrity of the system intact. The tool that is used will, so to speak, have to be agnostic to what it finds out there. Additional goals are to handle the rollout in a way that keeps the complexity and costs under control.

What is needed is a precise definition of what vehicles are eligible for an update and then a proper mapping of the software to the target units. With this structure it is additionally accomplished that, even though the fleet consists of many unique vehicle and software configuration variants, and while it cannot be ensured that the fleet is 100% up to date with the latest software, subsequent rollouts will properly attempt for vehicles of different starting configuration, whether the vehicles were not reached in previous rollout(s) or otherwise, to reach the desired state. A configuration agnostic approach is the answer here.

The Solution

First Step: Create a Model

A first step on this path is to precisely define the target, that is, the targeted vehicles and their architectures. Sibros achieves this by virtually defining the system through a tool we call Vehicle Model. 

The Vehicle Model is a representation of existing system architectures and their updatable ECUs. In other words, the Vehicle Model comprises vehicles that share a subset of elements, such as ECUs or associated software files. As such, any fleet is clearly demarcated into discrete subsets without overlap and with exact delineation of the architectures to be reached. 

The Vehicle Model is the foundation for the demarcation of vehicles and other resources on the Sibros Platform. With a Vehicle Model, the foundation for the correct mapping of software is laid.

Second Step: Create a Software Package

The software configuration on vehicles is then managed by mapping software images to each ECU or updatable domain that is included in the Vehicle Model. Once software is mapped, software packages that represent target software configurations can be deployed to vehicles.

A software package is a set of software images (or files) bundled together into a single unit. A software package contains all software and configurations for all ECUs in a Vehicle Model. The package defines the target state of software on vehicle ECUs at a specific point in time. It is important to note that vehicles do not download the entire package. Sibros’ Deep Updater, implemented on the vehicle, downloads only the files that are necessary, considering the exact vehicle architecture and the update status of the in-vehicle ECUs. This saves time, memory space, and data transmission costs.

Sibros takes a holistic perspective on vehicle software updates. Following the Uptane philosophy, a vehicle is viewed as a versioned state; in other words, as a complete set of ECU software versions and configurations that fully define the vehicle state. With a software update, a vehicle fully transitions to another known state representing a new combination of software versions.

Configuration Management with Sibros

This way, Sibros enables scalable “explicit configuration management” through validated full vehicle software packages instead of ECU-by-ECU updates that lack context for the full updatable system. The notion of explicit software configuration management implies that users specify packages with software for all modules in the system

The result is a much smaller, controlled set of software permutations in the field. Additionally, configuration complexity is abstracted away from the rollout creator and towards the update system that manages configurations on a per-vehicle basis. Fewer possible permutations of software mean that tests and validation prior to deployment are faster and more efficient, and that fleets are safer and more homogenized. Relieving the rollout owner from the configuration complexity means that rollouts can be generically applied across a fleet with varied update needs. The update system is trusted to ensure the fleet reaches the appropriate and correct end state most efficiently.

Using these steps and tools, Sibros’ Deep Connected Platform can provide effective configuration management capability via OTA software updates. Updates are handled safely and efficiently through the use of delta updates with small memory footprint and metadata targeting. Updates can be run as “erase and replace” (E/R) or “dual bank” (A/B). Pre- and post-condition safety checks are available along with the implementation of Uptane and further security standards.

Conclusion

The goal for OEMs and Tier 1 suppliers these days must be to deliver seamless and flawless software operation to improve safety, reduce cost, monetize innovation, minimize downtime and optimize the driver experience. To patch, update, and further develop the ever-growing in-vehicle software, loose coupling is the tenet and proper configuration management an important part. Sibros’ Vehicle Model, in turn, is the conducive tool to implement these processes. Maximum precision of updates allows OEMs to excel with their software.

Sibros’ Vehicle Model and software packages will maintain the integrity of the system and do this at scale, by abstracting away from unnecessary individual aspects and enabling reach to every single architecture and ECU—regardless of the current state.

The expectations of the software-defined vehicle are growing rapidly. OEMs that deliver safe, well-controlled updates without interruption for driver and vehicle pave the way for the future of connected mobility and modern vehicles. If you want to be recognized for this, talk to us today.