One parameter rarely comes alone.
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.
What is a parameter?
A parameter is a variable that has a constant value at runtime.
It is used during the development of a software program, in order to be able to adjust the reaction of a program in the target system. The development team can thus integrate a software program highly flexibly for different application scenarios without having to change the code basis.
The parameters are adjusted and tested by the development before the execution of the program. If unfavorable behavior is detected, other parameter value pairs are applied and tested again. The process is repeated until the software fits the selected deployment scenario.
They replace Magic Numbers in code, are mainly used for modeling limits (thresholds), as tuning parameter and for activating functional behavior.
How does a parameter differ from signals (such as temperature, velocities, etc.) and 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.
Typical examples of parameterization used in automotive:
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.
When testing parameterized software, special attention should be paid to the following topics:
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.
How can extensively parameterized software be tested 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.
For each test run, the default values of a parameter on the declaration editor are used by default.
To test variations of parameters in TPT there are the following possibilities:
1. Changing parameters when initializing a test case (in the Initial Values tab).
2. Changing parameters for a test run (in the Execution Configuration by loading a parameter set). From TPT 19 (coming soon) parameters can be defined as Multi-Execution and the combinatorics of multiple parameters with arbitrary value ranges can be iterated per test case.
3. Modification of parameters in the Mapping Editor
4. Changing parameters in the declaration editor
As if this was not enough: You can also change parameters at any time during the runtime of a test.
How the whole thing works in detail can be found in the TPT User Guide. This will be updated with every release. If you have any further questions, our support team will be happy to help you.
You don’t want to unnecessarily increase the number of your tests? Feel free to contact us and try out TPT today. We’ll be happy to help you with tips and tricks.