NXP Semiconductors – Amalgamating the multiple systems in a software defined vehicle

As the industry comes to grips with the concept of software defined vehicles, there is growing awareness of the complexities involved.

There are multiple layers of electronic components collecting data, often in isolation.

However, there is a wealth of information to be mined in the data as companies seek to differentiate their models through features rather than horsepower.

Automotive Industries (AI) asked Robert Moran, Product Management & Systems Engineering for Automotive Processors at NXP Semiconductors, how to understand the complexity of a software-defined vehicle.

Moran: Today’s vehicle is made up of multiple complex systems. It is somewhat of a labyrinth of sensors, actuators, and motors that enable braking, propulsion, transmission, battery management, bi-directional charging and steering – and they must be built to seamlessly work together.

These systems are critical to the core vehicle functions and they rely on each other for safe operation.

So, when we talk about a software-defined vehicle, we need to recognize that it is  a system of complex systems.

These systems are all unique and have different requirements, and there is no one-size-fits-all chip for every system.

AI: What are some of the interesting ways software will change our experience as we know it?

Moran: Software-driven features can bring a lot of value to this system of systems, and its impact on the user experience goes beyond what autonomous driving and infotainment can provide to the overall experience.

These systems control the comfort of the ride, how you interact with your car, the EV range you get, the reliability of your car, and so on.

One of the most basic benefits of a software-defined vehicle is its ability to predict the pending failure of a component and attempt to extend its life with a software update or schedule a visit to the garage to replace the part.

AI: Will software replace sensors?

Moran: The vehicle generates enormous amounts of data that can create what we call “synthetic sensing,” which is applicable to a range of new and existing use cases.

For example, you can train models to understand the behaviors and wear of mechanical brake sensors and their use in different environments. With an accurate model, the vehicle can predict when the brake pads need to be replaced.

The challenge is getting access to this data. It is difficult if you have disparate systems that lack the infrastructure to fuse this data for new applications.

Through our own Software-defined Vehicle Engineering Labs, we focus on ways to simplify the extraction of data for new user experiences that will benefit consumers, carmakers and the entire automotive supply chain.

AI: Is a tailored approach needed to get the most out of the data?

Moran: Absolutely, because every system is unique. There are untold amounts of viable legacy software in use. Some span decades of use.

The luxury of starting with a blank sheet of paper does not always exist.

So, you need to think about how to build platforms that can not only enable these new data-driven services and features, but also provide migration paths for legacy software.

You also need to ensure you can meet the real-time safety and interface requirements of the legacy software.

Simultaneously, you need to extract new opportunities from the data within these systems. It is not an easy task, and this is where a tailored approach is needed.

AI: How will vehicle electronics evolve with the rollout of software-defined vehicles?

Moran:  This is where it gets really exciting. We will see more centralization of software related to the vehicle features.

We will need cloud-based development platforms that enable agile development. The same platform will be used to update the vehicle throughout its lifetime.

We will see more synthetic sensing, actuating and even motors in new, versatile software-driven use cases. For years we have been talking about the increasing amount of electronics in vehicles.

With the right software and the right platform, carmakers will be able to reduce the number of ECUs that enable discrete, isolated standalone features.

Keep in mind the electronics in these centralized platforms need to accommodate heterogenous software environments. They must mix legacy software and modern software technologies like containers. At the same time, they need to provide automotive safety assurance and real-time behavior.

Easing the complexity for automakers is by no means an understated priority. They need to meet rigorous safety and security requirements, whether it is hardware or software-driven capability.

So, in this software-defined era, there’s obviously more software that is running across the vehicle with dependencies from one system to the next – and it is complex.

The days of a single ECU running a single application are over. The new approach is to isolate software applications to keep user data private and vehicle operations safe.

Purpose-built compute and networking platforms that isolate software applications and the data they generate is crucial. It needs to work easily and adapt to changes in the software over time.

And ultimately, the system has to ensure vehicle safety features and user data are not compromised – even if the user plugs in an infected USB or connects their phone via Wi-Fi!

AI: How can OEMs best extract the value out of the data embedded within the vehicle?

Moran:  Gaining access to the data is not the same as creating new data. A robust and configurable communications framework between the systems must be set up for the data to be captured and processed for new data-driven use cases.

Look at it this way: Today’s tire pressure sensor tells you the tire pressure. It is fairly simple by today’s standards.

But if you could monitor and analyze the real-time data from the tire pressure, braking, accelerometer and temperature sensors, you could build a model of the real-world road conditions and how they affect tire and brake pad wear.

It could remove the need to have a mechanical sensor monitoring the brake wear or help you predict when the tires are going to wear.

To do this, you would need to bridge different communication protocols and legacy software to move data into a service-oriented framework.

There is some precision to the bridging needed with the right network acceleration across the vehicle electronics infrastructure, keeping in mind that you need to optimize cost, power and performance, and – as with most technical challenges – there are always trade-offs to be made.

In any case, once data is made available, then processing at the edge – inside the vehicle – is the start for new insights. While there is not a single recipe to create new data-driven use cases or replace mechanical components, they typically include a combination of software, machine learning and processed data from one or many sources.

AI: Can a digital twin of the vehicle help manage health and updates throughout its lifetime?

Moran:  Yes, and that is a focus for NXP. Software-defined vehicles give automakers the opportunity to decouple the software development cycle from the hardware development cycle. Keep in mind, the hardware cycle is on a much slower update cadence, so there are fewer changes in the hardware over time. With this decoupled framework, the software development and deployment can continue after the vehicle is with the consumer.

Automakers must ensure the safety of occupants and vehicles for every feature in the car and every use case. Before new software is deployed to a fleet of vehicles with consumers, automakers can be certain that they are not compromising safety. Here is where the digital twin comes in. It provides a virtual testbed to ensure any new software features will act in a reliable way across the system of systems.

But beyond the safety aspect, the digital twin provides a testbed for new features. The data captured from the vehicle over time can be used for new hypothetical services that you can test in the cloud-enabled digital twin. The digital twin becomes a safe develop-and-deploy lab for new software that is rolled out to the vehicle over time, which can  remarkably change the lengthy real-world testing cycle that associated with traditional feature roll outs.

AI: What’s next for NXP?

Moran:  We work closely with automakers and Tier 1s, and when we look into what is ahead for the automotive industry, it is clear that no matter where they are in the process of the journey with software, there’s tremendous complexity.

This has paved the way for us to focus on building a platform of system solutions that are designed for the “system of complex systems” that we talked about earlier. Couple that with the thousands and thousands of ways there are to build a car.

So, what is next for us is to continue building on the industry-recognized platform that can address any kind of vehicle architecture configuration, whether they want to fuse the core data in the center with a supercomputer at the core of the vehicle or distribute that compute across zones or domains.

No matter what, we will continue to help automakers with the hardware platform designed for a software-defined system of systems that helps them unlock new data-driven use cases and vehicle features.