Manufacturers are countering the increasing complexity in modern cars with new approaches in the field of verification and validation. KPIT Technologies has now developed a test environment that can be used to integrate and simulate virtual battery management systems. In this way, BMS testing is possible within a SIL environment.

Today’s vehicles are becoming more and more complex. Topics such as electromobility, autonomous driving, or even connected vehicles mean that software development is increasingly the dominant factor when manufacturers are working on a new car. Traditional development test methods such as model-in-the-loop (MIL), hardware-in-the-loop (HIL), and software-in-the-loop (SIL) quickly reach their limits because timelines are tight when there are multiple software integration points.

To address this problem, manufacturers are turning to a more comprehensive approach to software verification and validation. This article describes a method for managing the complexity of new technologies in today's automobiles by using virtual validation. Specifically, it involves a virtual test bench developed by KPIT that uses the dSPACE tool chain to verify a 48 V battery management application.

Challenges in Integrated Software Validation

If you want to increase the quality of embedded software, you might wonder whether you can achieve this simply with more testing (regression). However, since testing already takes up a large portion of a project's time and resources, this is not a viable path. An organization’s testing and debugging processes affect an entire software platform (e.g., shared software libraries), which increases testing complexity. For example, a single software function or component may be used in dozens of variants (low-/mid-/high-end, country-specific, etc.). In the end, this leads to thousands of tests, with the disadvantage that if a bug is fixed in one variant, this change also affects all other variants.

Another disadvantage is that software integration tests are performed sequentially and on a HIL test bench. Software integration errors are therefore only discovered later in the development cycle, which can throw the entire schedule off track. Hardware-in-the-loop (HIL) environments are also difficult for software teams to access because integration and test teams typically share HIL environments. Each team may require a slightly different HIL configuration, which can be error-prone and time-consuming to configure. This also increases the overall testing time for the entire program.

Figure 1: Integrated virtual test bench setup for multi-ECU/domain testing.

Integrated Software Testing for Agile Development

All these challenges have made purely virtual test benches with a virtual electronic control unit (ECU) more and more popular. Leading automotive manufacturers already use this approach for integrated software development and software testing. For more than a decade, virtual test benches have therefore been developed that allow the real ECU to be replaced by a virtual ECU (V-ECU). The Indian company KPIT Technologies is one of the leading suppliers in this field and supports its customers in setting up virtual test benches at the component, subsystem, and system level, thus enabling them to change test strategies.

“Our Virtual Test Bench (VTB) uses solutions provided by dSPACE to recreate HIL test benches virtually at the component level to test, for example, the vehicle supervisory system, the e-drive inverter, and the battery management system,” explains Priyanshi Gupta, Tech Lead Virtual Test Bench of KPIT. These virtual test bench sets are created by integrating the dSPACE simulation software VEOS, the architecture software SystemDesk, the plant model as dSPACE Automotive Simulation Models (ASM), and the restbus simulation containers. In addition, standard test tools are connected to the VTB to enable consistent execution of tests across the VTB and HIL.

“This approach enables a faster development, integration and validation process that is scalable across the entire vehicle and available to every engineer in the company,” adds Gupta. “In the process, the test environment can be set up and updated with just one click and expanded as needed without delay. It also integrates easily with various OEM-specific tools and continuous integration/continuous deployment pipelines, maximizing the benefits.”

Application Example for a Virtual HIL Test of a Battery Management System

The main focus of the battery management system (BMS) test is on all functions that might be distributed across multiple software and hardware components. Typically, these tests are performed with a HIL setup that requires real hardware, peripherals, physical connections, and that lets the operator disconnect hardware and peripherals during run time. A good example of this test method is verifying algorithms after injecting a peripheral fault (hardware-level fault injection) and then validating the battery algorithms.

In electric vehicles (EVs) or hybrid electric vehicles (HEVs), the battery packs must be consistently monitored and managed to ensure the safety, efficiency, and reliability of the entire electric vehicle system. This requires a BMS that includes monitoring of the battery's state of charge, an optimal charging algorithm, and circuit functions for cell and thermal balancing. Not only does the BMS have to work with other onboard systems. It also has to function in real time under rapidly changing charge and discharge conditions, for example, when the vehicle is accelerating or braking.

The state of charge (SOC) is measured as available capacity, which depends on cell chemistry, aging factors, etc. The SOC estimation for the BMS involves various application components, software code for basic software (BSW) and complex device drivers (CDD), and inputs from application specific integrated circuits (ASICs). Given the increased complexity of such functions and the multiple interactions between the various software layers, the overall complexity of the software and the impact of software errors are much more pronounced than a purely local impact generally captured in a MIL test.

To meet the requirements for safety, robustness, and quality of the BMS software, a virtual BMS ECU test environment (VTE) provides the right tool for analyzing and validating the effects and design changes, not only at the unit level, but for the entire software.

Figure 2 clearly illustrates how a design flaw in one of the sensor filtering components affects the entire software, impacting algorithms, controls, and continuous diagnostics. This problem occurred during the validation of the KPIT BMS software platform and was detected in the VTE. “In total, we were able to successfully validate 90% of our BMS software platform with the dSPACE tool chain and environment,” says Debango Chakrobarty, Solution Architect BMS Controls & Software, KPIT.

Figure 2: BMS architecture - impact analysis.

Scaling and validation of diagnostic service protocols 

Diagnostics services are usually performed by multiple groups and in concentrated phases of functionality or protocol. However, the flexibility of the dSPACE environment helped KPIT scale up and validate diagnostics service protocols such as Unified Diagnostic Services (UDS) and the associated functionalities. KPIT identified and solved diagnostics authoring and software development issues by testing standard test suites such as Open Test sequence exchange (OTX) and custom features for its BMS software.

The VHIL component was used to generate errors by changing the inputs of the plant models during run time. This ensured that the software triggered the correct diagnostic error codes. In addition, KPIT integrated a third-party tool to perform OTX execution to confirm compliance with the standard. In doing so, the response of the BMS was validated.

In another test, all physical parameters were kept within their normal range ensuring that the contactors have been successfully closed so that the BMS can report the power-on status of the high voltage via the high-voltage request from CAN. A cell overvoltage failure was injected by the battery plant model by increasing the cell voltage until it exceeded the critical overvoltage threshold. In response, the BMS opened the contactors affected by the overvoltage fault, and the status was monitored via CAN. With this, a closed-loop validation of fault injection was ensured.

In the last test case, KPIT injected a cell temperature sensor with an undertemperature failure at a battery plant model. The power limit values transmitted by the BMS on the virtual CAN bus were monitored. The BMS power limits indicated a downward ramp, which meant that the system had entered limp-home mode. In response to the thermal system outputs, the BMS thermal conditioning commands were displayed.

In addition to the tests described above, KPIT's virtual test environment enabled regression testing for all communication frames, integrated function validation, and expansion to a vehicle-level virtual test bench.

Furthermore, the execution of the virtual test bench is integrated into the continuous integration/continuous testing (CI/CT) workflow. Throughout the development cycle, more than 100 data pipelines are defined to ensure testing of all consumers from the component to the system level. A simplified version of the test execution process is shown in figure 3. The implementation for the BMS test bench is set up using Jenkins CI. These pipelines have been implemented at different KPIT customers with different technologies.

Figure 3: CI/CD workflow.

The Advantages of a Virtual Test Environment

As the platform-based approach is becoming more popular in today's product development landscape, a virtual test bench like the KPIT VTE provides the perfect environment for scaling, adapting, and transforming component platforms into more variants while maximizing test efficiency.

“Together with dSPACE, we have developed this test environment, which can be used to perform tests at component, subsystem, and vehicle level for all OEM vehicle programs,” reports Neeraj Patidar, Architect Virtual Test Environment, KPIT. “The advantages are obvious: Virtual HIL setups and environments at the component level enable faster validation of ECU software and a 90% increase in test coverage throughout the V-cycle.” KPIT offers its customers VTE components as accelerators for OEM-specific implementations. The VTE provides accurate and stable co-simulation orchestration for thousands of concurrent users who can submit multiple test jobs simultaneously.

Courtesy of KPIT Technologies Ltd 


About KPIT

KPIT Technologies is a global partner to the automotive and mobility ecosystem for making software-defined vehicles a reality. It is a leading independent software development and integration partner helping mobility leapfrog towards a clean, smart, and safe future. With 9000+ automobelievers across the globe specializing in embedded software, AI, and digital solutions, KPIT accelerates its clients’ implementation of next-generation technologies for the future mobility roadmap. With engineering centers in Europe, the USA, Japan, China, Thailand, and India, KPIT works with leaders in automotive and mobility and is present where the ecosystem is transforming.



Enable form call

At this point, an input form from Click Dimensions is integrated. This enables us to process your newsletter subscription. The form is currently hidden due to your privacy settings for our website.

External input form

By activating the input form, you consent to personal data being transmitted to Click Dimensions within the EU, in the USA, Canada or Australia. More on this in our privacy policy.