Developing AUTOSAR- and ISO 26262-Compliant Software for a Hybrid Vehicle Battery Management System with Model-Based Design

When our team developed the battery management system (BMS) for the Volvo XC90 plug-in hybrid, the use of AUTOSAR was a Volvo requirement, but we were free to choose our own development methodology and tools. We saw this project as an opportunity to establish a workflow based on Model-Based Design. Using this workflow, we can leave development of hardware-specific modules in the basic software layer to vendors with expertise in that area and focus on modeling, simulating, and verifying the control logic in the application layer.

Model-Based Design with MATLAB^® and Simulink^® has enabled us to increase component reuse, reduce manual coding, improve communication with our customers, and deliver a higher-quality BMS. Following the introduction of Model-Based Design, the number of software issues identified in each software release dropped from about 22 to fewer than nine—well below our target for the project.

Why Model-Based Design?

We chose Model-Based Design in part because it enables us to model and simulate the complex algorithms and behaviors that make up the core of the BMS. We wanted to automate quality checks and thoroughly verify our design with software-in-the-loop (SIL) and hardware-in-the-loop (HIL) tests prior to customer acceptance testing.

The algorithms we needed to develop required contributions from engineers from diverse disciplines and backgrounds, including electrochemistry, mathematics, control design, and software engineering. We knew that Model-Based Design would give them a common platform and a shared language to collaborate on the design.

Reusability was another key factor driving our decision. We had already assembled a library of components that we wanted to use on the Volvo BMS project, and we wanted to continue to develop this library to speed development of future projects with OEMs. So far on the Volvo project, we have used the core library across five variant models. With this core library it takes us much less time to initiate a new variant model, and even a new project.

Developing the AUTOSAR Software Components

We began our top-down development approach by modeling the system architecture and defining software component descriptions in an AUTOSAR authoring tool. We then imported the component descriptions (exported as ARXML files) into Simulink.

Working in Simulink and Stateflow^®, we modeled the control logic and algorithm behavior of the BMS using the skeleton model that was automatically created during the import process. We also mapped signals in the Simulink model to those in the AUTOSAR component descriptions. During this phase, we reused Simulink components for SoC (state-of-charge) estimation, SoH (state-of-health) estimation, control logic, diagnostic logic, and so on, from a core library that we had assembled from earlier projects. We added custom logic to meet Volvo’s requirements for this specific project, including the PHEV’s motor arbitration logic.

While developing the controller model in Simulink, we frequently checked compliance with style guidelines and modeling standards using the Model Advisor. We also checked for dead logic, divide-by-zero errors, and other design errors in our models using Simulink Design Verifier™.

An electrochemical simulation team at LG Chem created a mathematical model of the battery pack’s electrochemical cells. We incorporated this team’s MATLAB code into a Simulink plant model, which we used to simulate our controller model.

Generating Code and Automating Tests

Once we had completed the initial design, our goal was to automate as much of the remaining workflow as possible, including code implementation and test execution. We generated AUTOSAR-compliant C code from our controller models using Embedded Coder^® and the Embedded Coder Support Package for AUTOSAR Standard.

To validate the generated code, we performed SIL testing with test cases focused on three areas: the core library components, mapped signals, and the custom logic.

During the automated SIL tests, we measured execution coverage, modified condition/decision coverage (MC/DC), lookup table coverage, and cyclometric complexity using Simulink Coverage™. These metrics enabled us to ensure that our tests were exercising the entire design. It can be almost impossible to diagnose hard-to-debug issues identified in integration testing with a development process that relies on hand coding, particularly for systems in which output from a software component (SWC) is processed by a second SWC and then fed back into the original SWC. With Model-Based Design, we could display the signal at each level during simulation and see how errors propagate through the SWCs in the feedback loop, which makes the underlying problems easier to identify and correct.

We deployed the generated code to our target embedded processor for HIL tests in which the full electric powertrain of the vehicle is simulated. These final tests lead to vehicle validation tests conducted by our customer. If the customer tests uncover an error, we can use the test log files to reproduce the problem in Simulink, identify the root cause via simulation, and adjust the model to address the issue. The extensive testing that we conducted as part of our workflow led to a marked reduction in software issues (Figure 1).

Next Steps

The BMS we developed for Volvo using AUTOSAR and Model-Based Design has achieved ISO 26262 functional safety–based certification for Automotive Safety Integrity Level C (ASIL C). For this initial project, we completed most certification tasks manually. We have since automated many of the tasks and reduced the resources needed to generate reports for certification.

Our team is now using the workflow that we established for the Volvo BMS to develop AUTOSAR software components for a growing number of automotive OEM customers.