Parameters: A Major Challenge in Automotive Software Development

Understanding Parameters: An Introduction

Many of our customers have implemented hundreds to thousands of parameters in their applications in order to parameterize (i.e. apply) the software in the vehicle. This is not only done in powertrain and engine development, but rather in all domains of automotive development, such as driver assistance, body and comfort, and energy management.

The application of software is mostly done when the software is to be used over several vehicle variants and generations. Parameters give development the necessary flexibility to make software reusable by compensating for system variants through clever adaptation of the software.  

Parameters thus enable product line-oriented software development. 

Each parameter implemented into a software comes along with a growing complexity in the software development process. Therefore, testing software with parameters requires even more attention. 

Parameters vs. Signals vs. Constants

Signals change continuously over time and reflect the surrounding system. Constants (or defines) are defined when the software is built and can then only be changed by rebuilding the software. Technically speaking, parameters lie exactly in between. During operation of the software, the value of a parameter is normally not changed – it acts like a constant. 

A parameter can be technically changed, for example, in a workshop, during a test drive or during a software update, even during runtime, and thus offers a high degree of flexibility during development and operation.  

Parameterization in the Automotive Industry: Examples

1. Closed-loop controller 

PID controllers are often used in automotive systems. The gain K_p of the proportional component is a typical example of tuning parameters.

2. Limit values or switching thresholds 

In many applications physical values have to be calculated and modeled. Parameters as scalar quantities are used to characterize threshold values. When threshold values are exceeded, the behavior of the software changes. 

In our lights controller example several parameters are used to distinguish the light intensity in segments, such as light and dark. If you have different sensors for different vehicles that you want to integrate in one software, you should use parameters to be able to adapt the software. 

Also common is the use of multidimensional parameters in the form of characteristic curves or matrices. In battery controllers, open circuit voltage characteristics are used to estimate the state of charge (SOC) of battery cells.

3. Activation of functionalities 

Parameters are used in engine development to enable different performances for the same mechanics and also used to code optional vehicle features, such as the presence of an auxiliary heating system.  

By adjusting the parameters, the vehicle can be optimized for different conditions or requirements to enhance the driving experience and optimize vehicle performance.

Key Considerations for Testing Parameterized Software

1. Changing default value of parameters: check if the basic functionality is still present. If parameters are used intensively across unit and module boundaries, a new and complete test run should be initiated. In case of low usage, a unit test and the next higher level of software integration test is usually sufficient for verification.

2. Adding new parameters or use existing parameters in other code segments: Functional tests should be used when adding to check if the parameter has the right effect. In the test, specific value variation of the parameter should be used to find out whether the parameter has been built in at the right place. 

3. Avoid parameter interference: threshold parameters often segment the same signal. An application parametrization guideline shows the right use of parameters and specifies how a parameter should and must be set in general and in relation to another parameter. Such guidelines are sometimes not known, which can lead to problems that have already been dealt with and excluded in the documentation.

4. Avoid too many tests: Testing all possible values and combinations of parameters is very time consuming and often impractical, especially when there are many parameters. Instead, only the most important or most commonly used values and combinations of parameters are usually tested to ensure that the software is working properly. 

5. Be careful with changing parameters in the test case: Sometimes the value of a parameter directly changed in a test case. This can lead to unexpected bugs in a test run. So be careful when and where you change parameters in the test. 

Strategies for Testing Extensively Parameterized Software in TPT

All parameters used in a software are known when the software is connected the first time in TPT. They are imported in the declaration editor and can thus also be used, modified and referenced via automotive completion in all tests and evaluations.