High-Voltage Battery System: A Model-Based Design Example for Automotive SPICE and ISO 26262:2018

This example uses:

Open Live Script

This example shows how to develop a battery system that complies to ASPICE v4.0 and ISO 26262:2018 ASIL D requirements. The example covers two implementations, one for an AUTOSAR classic platform and the other targeting a non-AUTOSAR platform.

Electrical vehicles use a high voltage battery system (HVBS) to power the electric motor by storing and supplying electrical energy. High voltage batteries, which are typically comprised of lithium-ion cells, offer high energy density, longevity, and efficient energy management. For optimal performance and safety, a battery management system (BMS) monitors and regulates the battery's state of charge, temperature, and overall health. High voltage batteries are engineered to support fast charging and deliver significant driving range, addressing consumer demands for convenience, safety and reliability.

You can apply MathWorks® products in a Model-Based Design approach to comply with automotive standards like Automotive SPICE (ASPICE) and ISO 26262:2018. ASPICE focuses on assessing and improving engineering processes within the automotive industry, while ISO 26262: 2018 addresses functional safety of electrical and electronic systems. Compliance with both standards helps assure that automotive systems are high-quality and safe.

Use the example to explore the system and software development and verification/validation activities called out by both standards. Use the example to review the sample work products for the project, such as artifacts, models, requirements, tests, and pregenerated results.

Automotive SPICE Processes

You can use ASPICE to evaluate the quality and efficiency of your organization's system and software engineering processes, including:

System Engineering Processes (SYS) — Processes to assess that the system requirements translate effectively into a working product. In this example, use the live scripts to perform tasks that are relevant to process, including:

SYS.1 Requirement Elicitation — Gathering and understanding stakeholder requirements. Assures that stakeholder needs are accurately captured and documented. In this example, use the live scripts to:

  • Review sample stakeholder requirements.

  • Add/edit custom attributes and IDs for the requirements.

  • Use the diff utility to view changes in a requirements set.

  • Import requirements from an external source.

  • Generate the requirements report for a specific requirement set in the project

  • Perform ISO 26262-3:2018 activities, including item definition, hazard analysis and risk assessment (HARA), and functional safety (FuSA) specification.

SYS.2 System Requirement Analysis — Eliciting, analyzing, and documenting system requirements. Confirms the requirements are complete, consistent, and traceable. In this example, use the live scripts to:

  • Review the system requirements and project glossary.

  • Programmatically update the attributes of the requirement.

  • Review traceability of the system requirements (including technical safety requirements) upstream to the stakeholder and functional safety requirements and downstream to the system architecture and software requirements.

  • Perform ISO 26262-4:2018 activities, such as generating a diagram of the system requirements to trace technical safety requirements to system requirements.

SYS.3 System Architecture Design — Creating a high-level design of the system architecture. Checks that the architecture meets the requirements and is feasible for implementation. In this example, use the live scripts to:

  • View the functional, logical, and physical, and component architecture.

  • Explore allocations between architectural models.

  • Import a component pin-out from an Excel spreadsheet.

  • Derive views from the architecture model based on attributes added by using profiles.

  • Review a sample activity diagram to analyze the architectural design.

  • Perform ISO 26262-4:2018 activities, such as specifying the Hardware-Software Interface (HSI) and importing the specification into Requirements Toolbox.

SYS.4 System Integration and Integration Verification — Integrating the system components and testing the integrated system. Verifies that the integrated system meets the specified requirements. In this example, use the live scripts to:

  • Review a sample test specification file.

  • Review a sample integration verification specification report.

SYS.5 System Verification — Verifying and validating the system against its requirements. Confirms that the system is ready for delivery and meets quality standards. In this example, use the live scripts to:

  • Review a sample test specification file.

  • Review a sample system verification specification report.

Software Engineering Processes (SWE) — Processes to assess the quality and capabilities of the software development and verification activities in a software lifecycle. This example provides live scripts for these processes:

SWE.1 Software Requirement Analysis — Deriving, analyzing, and specifying software requirements based on the system requirements. Assures that software requirements are complete, consistent, and testable. In this example, use the live scripts to:

  • Review sample software requirements.

  • Programmatically import requirements.

  • Perform ISO 26262-6:2018 activities, including specifying the software safety requirements, generating a traceability matrix of the software safety requirements and software requirements, and reviewing the Hardware-Software Interface (HSI) specification.

  • Review the software safety requirements using a checklist.

SWE.2 Software Architecture Design — Creating a software architecture that fulfills the software requirements. Establishes traceability between software requirements and architectural components. In this example, use the live scripts to:

  • View the layers of the software architecture.

  • Review two architectural designs of the application software.

  • Open a data dictionary and review the application interfaces and data types.

  • Create an instance of the software architecture based on metadata.

  • Generate a traceability matrix to review links between the architectural design and the software and software safety requirements.

  • Perform ISO 26262-6:2018 activities, such as adding ASIL information to the components.

SWE.3 Software Detailed Design and Unit Construction — Designing and implementing software units that meet the software architecture. Establishes traceability from detailed design to software units. In this example, use the live scripts to:

  • Review the detailed design of atomic software components.

  • Generate code for a specified model/software component and review code generation reports.

  • Perform an impact analysis for changes to the model and code.

  • Import legacy code into Simulink for integration with software components intended for code generation.

SWE.4 Software Unit Verification — Verifying that each software unit meets its design specifications and requirements. Establishes traceability between unit tests and requirements. In this example, use the live scripts to:

  • Verify the software at the model level by using modeling standards checks, design error detection, and MIL simulation.

  • Verify the software at the code level by using coding standard checks and SIL/PIL simulation for source code verification.

  • Generate tests cases to achieve full structural coverage.

SWE.5 Software Component Verification and Integration Verification — Integrating the software units and verifying the integrated software. Establishes traceability between integration tests and software requirements. In this example, use the live scripts to:

  • Run back-to-back tests to verify a single software component.

  • Execute integration tests to verify the application software.

SWE.6 Software Verification — Confirming that the integrated software satisfies the software requirements. Establishes traceability between verification tests and software requirements. In this example, use the live scripts to:

  • Review methods for verifying the integrated software based on the software requirements.

AUTOSAR and Non-AUTOSAR Implementations

This example demonstrates two distinct implementation approaches for the high voltage battery system: one utilizing the AUTOSAR Classic platform and the other following a non-AUTOSAR based implementation. The differences between these approaches impact software engineering processes SWE.2 to SWE.5.

In an AUTOSAR implementation:

  • (SWE.2) Standardized AUTOSAR components and interfaces influence the software architecture, which helps confirm modularity and interoperability.

  • (SWE.3) Software detailed design and unit construction adheres to AUTOSAR specification and guidelines. These guidelines dictate specific design patterns and configurations, including configurations for generating code from AUTOSAR-based models. Code generation leverages toolchains that help you achieve compliance with the AUTOSAR specification.

  • (SWE.4) Software unit verification (in the AUTOSAR context) includes static and dynamic verification at the model level, as well as at the code level for generated AUTOSAR C code.

  • (SWE.5) Software integration and testing for AUTOSAR systems focuses on verifying the AUTOSAR components and verifying the integration of these components, which helps confirm that the system meets the defined functional criteria.

In contrast, the non-AUTOSAR implementation allows for more flexibility in design and integration.

ISO 26262:2018 Activities

This example highlights some ISO 26262:2018 considerations for product development at the system and software levels. A special focus is given in this project to safety activities during the concept phase.

The project includes examples for:

  • Item definition (by using stakeholder requirements and a preliminary architecture of the HVBS)

  • Hazard identification and risk assessment

  • ASIL determination

  • Safety goals and functional safety concept

Open the Example Project

The example requires a local installation of Git. For more information, see Use Source Control with MATLAB Projects. If you receive a Git error about a file path exceeding the maximum length, run this command from the MATLAB command window.

!git config --global core.longpaths true

To open the example project, at the MATLAB command line, enter

openExample('iec_certkit/CertAutosarExample')

If you receive a MATLAB error about the report path exceeding the Windows path length limit of 259 characters, the longest relative path in the project is 186 characters. To resolve the error, consider moving the project to a directory with a total path length of fewer than 70 characters.

The example project, AR_BMS.prj, opens and automatically displays the main live script for the project (runRefWorkflow.mlx). From this file you can:

  • Review a list of required and recommended MathWorks products for running this example.

  • Explore the project along the system and software engineering processes of ASPICE process reference model (PRM).

  • Review the impact to the ASPICE processes when using the AUTOSAR Classic platform vs. a non-AUTOSAR implementation approach.

  • Review additional considerations at the system and software level for compliance with ISO 26262:2018.

  • Use the Model-Based Design reference workflow to learn about applying MathWorks products to fulfill the development and verification/validation activities that are called out by ISO 26262:2018.

Using Live Scripts in the Project

In this example, you run the workflow and generate reports by using live scripts. Some live scripts in this example depend on artifacts and reports created by running other live scripts. To navigate the workflow examples with the correct dependencies available, use the buttons in the task window of the runRefWorkflow.mlx file. Clicking a button opens a live script for each ASPICE process. Do not open the live scripts by using the project browser or file explorer. Clicking on any button in the live script automatically unzips the reports, tests, and src_pregen archives that are referenced in the example.

This example includes pregenerated reports and artifacts. If you do not have the product required to perform a task in a live script, use the hyperlinks in the live script to open the relevant, pregenerated artifact. Some of these prepregenerated files are available only after you open and run the live script files.

See Also

Model-Based Development Approach - AUTOSAR + Functional Safety + ASPICE.

10 Best Practices for Deploying AUTOSAR Using Simulink

MATLAB and Simulink for ISO 26262 Compliance

MATLAB and Simulink for AUTOSAR

What is Automotive SPICE

What is AUTOSAR? (AUTOSAR Blockset)

Model AUTOSAR Classic Component and Elements in Simulink (AUTOSAR Blockset)