Developing and Delivering the New Generation of Software-Defined Vehicles

The next generation of vehicles will be the first in which brand-distinctive features and customer value are delivered through software. New technologies—in connectivity, autonomy, and electrification—at the heart of these software-defined vehicles (SDVs) are emerging in response to rapidly evolving customer expectations for mobility. The software behind these innovations—both customer-facing and under-the-hood—requires a significant investment. It also represents a generational opportunity as companies develop their ability to deliver add-on apps and services—not to mention security and other critical updates.

Of course, software has been playing a major role in enhanced vehicle performance and safety for many years. Closely tied to the physical systems and deployed on ECUs, this embedded software requires high reliability. It often must also conform to process models, including Automotive SPICE^®, and functional safety standards, such as ISO^® 26262. Many automotive OEMs and suppliers are adept at using Model-Based Design to accelerate the delivery of this software through early validation of designs via simulation followed by code generation and verification (Figure 1).

With SDVs, software takes an even more prominent role. Organizations need to plan for continuously improving and updating software after the vehicle is in production. They will need to incorporate operational data collected from connected vehicles to drive this continuous improvement. In addition, they will need to expand the set of key performance indicators (KPIs) used to measure success, complementing traditional metrics, such as development velocity, with more metrics from the operations side of DevOps, including change failure rates and mean time to recover from incidents.

Doing these requires a shift in mindset. The question for many automotive companies is: How do our software development and system development teams and processes need to change, and how is Model-Based Design evolving to address those changes?

How Model-Based Design Is Evolving for SDV

To date, engineering teams have used Model-Based Design most often to target embedded systems. In many cases, this means the hard real-time implementation of algorithms—expressed in terms of signal flow—on resource-constrained ECUs or microcontrollers. Now, in addition to ECUs, targets include central or zonal computers in the SDV as well as the cloud. Also, instead of being invoked by a real-time scheduler, the algorithms may be deployed as part of a service-oriented architecture and invoked via API calls. With this transition, the tools for Model-Based Design have been updated to support service-oriented architecture in addition to signal-based interfaces.

Those same engineering teams are accustomed to using Model-Based Design with a focus on design, implementation, and verification, working with tools packaged for the desktop in interactive, human-driven development workflows. Going forward, automation will be a key focus and play a bigger role via continuous integration (CI) pipelines, Kubernetes-orchestrated flows, and similar mechanisms. Many organizations are already integrating Model-Based Design and CI, with automated pipelines that perform model verification, code generation, static code analysis, and other tasks when changes to the model are committed.

Similarly, the relatively narrow focus on the management of tools and assets using product lifecycle management (PLM) systems is also expanding. Now teams are much more likely to employ trunk-and-branch approaches with Git™ and Artifactory repositories as an agile way to store, iterate, and rapidly improve software artifacts. The more agile, more granular approach is what software development teams use. In addition, those teams are no longer only delivering their software systems to a bill of materials for start of production (SOP), they will also be streaming them to SDVs over the air after SOP. Model-Based Design is evolving to address these emerging development paradigms.

Bridging the SDV Cultural Divide

Of course, any story of innovation—including the SDV story—is not just about a set of tools and processes that have evolved. It’s also about the people using the tools and processes and, frequently, the organizational cultures that separate them. In many ways, the teams who have used Model-Based Design for system engineering and delivery of embedded software work in a very different world from more code-centric teams, who are more likely to be using DevOps practices.

Some organizations have already started bridging the divide between these often disjoint groups (Figure 2). In these organizations, the system engineering teams have begun adopting a DevOps perspective. When they create a system model or scenario model, for example, they have processes in place for handing that model off to others who will incorporate it into downstream automation. On the other side, the code-centric teams in these organizations have started to view systems and models as important to their work. They recognize the value of simulation in delivering the software and systems needed for SDVs as a coherent whole, and they are learning how to incorporate it in their processes. Further, these organizations are taking steps to bring together teams via common platforms, including their continuous integration/continuous delivery (CI/CD) platform. This shared technology stack is easier to scale and maintain, and it helps streamline the tracking of shared KPIs for flow, velocity, software robustness, and system rigor.

A Real-World Use Case

To better understand what teams can do today to accelerate the delivery of software for SDVs, consider the following use case. An engineering team has been tasked with delivering an update to an electric vehicle already in production. The update will enable a new feature—Sport + mode—that reduces the time it takes the vehicle to accelerate from 0 to 60 mph (100 kph) per hour by 10 percent.

This example focuses on three key workflows that the team uses to achieve this goal:

• Conducting system analysis with simulation in the cloud
• Using CI to automate testing and code generation
• Performing virtual ECU deployment and testing

System-Level Studies. As a first step, the team needs to identify the key software parameters that can be varied to achieve the required acceleration and then quantify the effects of changing these parameters at the component and system level. They use the Virtual Vehicle Composer app to interactively configure and build a virtual vehicle in Simulink^® (Figure 3). They then run a series of parameter sweeps, varying model parameters such as maximum battery current and braking regeneration limits while monitoring acceleration, MPGe, and other system-level and component-level metrics. To speed up the simulations, the team uses MATLAB Parallel Server™ on AWS^® to run the parameter sweeps on an EC2 instance, cutting the time needed to perform hundreds of simulations from hours to minutes. The required acceleration increase may require algorithm changes in addition to parameter optimization. These changes can be quickly implemented in the model and verified via model-in-the-loop (MIL) and software-in-the-loop (SIL) tests.

CI for Automated Testing and Code Generation. Once the system-level studies are complete, the team begins to modify the component models, updating parameter values and making other changes as needed to increase the vehicle’s acceleration. Because in many cases multiple engineers may work on different features and components in parallel, the team componentizes their models and places them under source control. This enables engineers to share assets and synchronize work with their teammates. Just as importantly, it enables the team to use a scalable Jenkins^® or GitLab^® CI pipeline to automate testing and code generation when changes are committed (Figure 4). The tests can be run at the model level and at the application software level (including MISRA C™ checks and other static analyses), and they can be configured to run in a variety of environments and containers.

Virtual ECU Deployment and Testing. After code is generated and tested, the team’s next step is to verify the application software on a virtual ECU. In this case, the generated code is deployed as application software components on AUTOSAR Classic and Adaptive platforms. To verify that the components can be integrated with middleware before testing on target hardware and potentially sent to vehicles as an over-the-air update, the team uses a virtual ECU running on an AWS EC2 instance (Figure 5). For this particular application, they integrate the components with Elektrobit (EB) corbos middleware for Adaptive AUTOSAR and EB tresos basic software for AUTOSAR Classic. After running tests on the virtual ECUs, the team compares the results of the tests with the results of (MIL) and (SIL) tests conducted earlier via Simulink. Having confirmed the integrated production software is ready to test-drive, the team is ready to deploy the software.

The Path Forward

MathWorks engineers have worked with thousands of customers across the automotive industry and around the world, helping teams use Model-Based Design in new ways within their organization. We are continuing that work as more companies take early steps in their SDV journey, adding new capabilities designed to drive further automation and close the feedback loop that brings more operational data from production vehicles into system engineering, design, and development activities (Figure 6).

We’re also continuing to help customers align the software development and system engineering practices within their organizations to help them cost-effectively deliver the enhanced performance, reliability, safety, and security expected of next-generation vehicles. For established automotive companies, this often means adding or enhancing the software development team’s capabilities in a way that makes use of the system engineering team’s expertise. For tech startups and younger companies, it’s an opportunity to gain an edge by integrating proven Model-Based Design practices—including modeling, simulation, and code generation—into their DevOps oriented workflows.