Parameters - One of the biggest challenges in automotive software development

A parameter rarely appears alone.

Many of our customers have implemented hundreds or thousands of parameters in their applications in order to parameterize (i.e. apply) the software in the vehicle. This is not only true for the development of powertrains and engines, but also for all areas of vehicle development such as driver assistance, body and comfort, and energy management.

The application of software is usually done when the software is used in multiple models and iterations of vehicles. Parameters provide the necessary flexibility for development, making the software reusable by subtly adjusting the software to compensate for system variables.

Therefore, parameters support product line-oriented software development.

Every parameter applied to software comes with an increasing complexity in the software development process. Therefore, testing software with parameters requires more attention.

What are parameters?

Parameters are variables that have constant values ​​at run time.

It is used during the development of software programs to be able to adjust the program's reaction in the target system. As a result, the development team can integrate the software program with high flexibility for different application scenarios without having to change the code base.

Parameters are tuned and tested by developers before program execution. If unfavorable behavior is detected, other parameter value pairs are applied and tested again. The process is repeated until the software is suitable for the selected deployment scenario.

They replace magic numbers in the code and are mainly used for modeling limits (thresholds), as tuning parameters and activation function behaviors.

How do parameters differ from signals (such as temperature, speed, etc.) and constants?

Signals change over time and reflect the surrounding system. Constants (or definitions) are defined when the software is built, and can then only be changed by rebuilding the software. Technically, a parameter is right in between. The value of a parameter generally doesn't change while the software is running - it's like a constant.

Parameters can be changed technically, for example, in the workshop, during a test drive or during a software update, even at runtime, thus offering a high degree of flexibility during development and operation.

Typical example of car parameterization:

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 parameter tuning.

1. Limit value or switching threshold

In many applications, physical values ​​must be calculated and modeled. Parameters as scalars are used to describe thresholds. When the threshold is exceeded, the behavior of the software changes.

In our light controller example, several parameters were used to differentiate the light intensity of the segments, such as light and dark. If you want to integrate different sensors of different vehicles in one software, you should use parameters to adapt the software.

It is also common to use multi-dimensional parameters in the form of characteristic curves or matrices. In battery controllers, the open circuit voltage characteristic is used to estimate the state of charge (SOC) of the battery cell.

1. Activation of functions

In engine development, parameters are used to achieve different performances under identical mechanical conditions and also to encode optional vehicle functions, such as the presence of an auxiliary heating system.

By adjusting parameters, the vehicle can be optimized for different working conditions or requirements, improving the driving experience and optimizing vehicle performance.

When testing parameterized software, special attention should be paid to the following topics:

1. Change the default value of the parameter: Check that the basic functionality is still there. If the parameter is heavily used across unit and module boundaries, a new full test run should be started. In case of low usage, unit tests and the next higher level software integration test are usually sufficient for verification.

2. Add new parameters or use existing parameters in other code segments: Functional testing should be used when adding parameters to check whether the parameters have the correct effect. In the test, the specific value changes of the parameters should be used to determine whether the parameters are set in the correct position.

3. Avoid parameter interference: Threshold parameters often segment the same signal. Application parameterization guidelines show the correct use of parameters and specify how a parameter should and must be set in general and in relation to another parameter. Such guidelines are sometimes not well known and can therefore lead to problems that have been addressed and eliminated in the documentation.

4. Avoid excessive testing: Testing all possible combinations of values ​​and parameters is time-consuming and often impractical, especially when there are many parameters. Instead, testers usually test only the most important or most commonly used combinations of values ​​and parameters to ensure that the software works properly.

5. Be careful with parameter changes in test cases: Sometimes the value of a parameter is changed directly in a test case. This may cause unexpected errors in the test run. So be careful when and where parameter changes are made in the test.

How to test extensively parameterized software in TPT?

In TPT, all parameters used in the software are known when the software is first connected. They are imported into the declaration editor and can therefore also be used, modified and referenced in all tests and evaluations via auto-completion.

For each test run, the default values ​​of the parameters on the declaration editor are used by default.

To test parameter changes in TPT, there are several possibilities:

1. Change the parameters when initializing the test case (in the Initial Values ​​tab).

2. Change the parameters of a test run (by loading parameter sets in the execution configuration). Starting with TPT 19 (to be released soon), parameters can be defined as Multi-Execution, and combinations of multiple parameters with arbitrary value ranges can be iterated in each test case.

3. Modifying parameters in the mapping editor

4. Changing parameters in the declaration editor

As if that wasn't enough: you can also change parameters at any time while the test is running.