3. The Automotive SPICE-Processes (VDA Scope)

3.19 Application parameters in Automotive SPICE

What are application parameters?

The Automotive SPICE PAM defines application parameters (also known as “calibration parameters”) as follows:

“An application parameter is a parameter containing data applied to the system or software functions, behavior or properties. The notion of application parameter is expressed in two ways: firstly, the logical specification (including name, description, unit, value domain or threshold

values or characteristic curves, respectively), and, secondly, the actual quantitative data value it receives by means of data application.”

Application parameters modify the behavior of a system. The common interpretation is that the system reads the application parameters at startup from a memory. Typical examples are:

  • Parameters are measured when calibrating the system. A typical example is an electrical steering system. Measurements are taken at the end of the production line and are written into a flash memory. When the system starts it reads the parameters and uses them in steering control.
  • The software is built in a way that the behavior of the system needs to be tuned during trials by modifying parameter sets. Typical examples are AC control or engine control (the latter with a very large number of parameters). This tuning is done either by the supplier, or the OEM, or by both parties in shared responsibility. Once the optimum parameters are found they are stored in a memory and read at startup.
  • Application parameters are to switch functionalities on or off, e.g., because of car variants or options chosen.

The definition of application parameters would also apply to compiler switches or compile time parameters which are used to generate software variants. The problems are very similar. However, this case does not happen that often.

The examples already showed that application parameters occur in a variety of forms and must be considered in different processes. Application parameters are indicated in all engineering processes as well as in configuration management (SUP.8) and in the process product release (SPL.2). Implicitly, they must also be taken into account in Problem Resolution Management (SUP.9) and Change Request Management (SUP.10).

What are the challenges of using application parameters?

There are three main challenges:
1. Configuration management
2. Variant handling
3. Testing

To 1: Configuration management can have problems with projects with many application parameters. Examples are engine or transmission control withn several thousand application parameters. The challenge lies in the combinatorial explosion of the application parameters, i.e., the number of parameter combinations becomes unmanageable. The combinations must be placed under configuration management and distinguished accordingly.

A release consists of the software and the set of application parameters.
A release consists of the software and the set of application parameters.

To 2: Variants typically exist as code variants, parameter variants or a combination thereof. If a software platform is available there is an ongoing discussion between platform project and customer project whether customerspecific functionality can be implemented without platform modifications or whether platform application parameter definitions and/or code need to be adapted. In any case the resulting variants need to be identified and managed.

To 3: The challenge for testing is the number of tests needed with respect to the parameters. It is obvious that for one parameter several tests are needed to cover the possible parameter values. A sampling strategy can be developed with respect to the design to reduce the number of values to be tested. But what if there are two parameters? In this case parameter combinations need to be taken into account. It is obvious that the increasing number of parameters and the number of possible parameter values quickly leads to a far too high number of tests required (so called “combinatorial explosion”).

Two approaches may be pursued to solve this problem:

  • It is shown that parameters are functionally independent of each other, e.g. because they affect different subsystems or software components that do not interact or the parameter combinations do not have an effect on the interaction. Then the parameter space has been segmented into smaller subspaces. A subspace then has significantly fewer parameter combinations, which are handled on the level of the component tests.
  • If this is not possible, the OEM and the supplier agree on certain parameter value combinations and only those will be tested.

Tests of parameter combinations also impact regression testing.

Which processes need to be considered?

There are explicit references to application parameters in the following processes:
SPL.2 Product release
SYS.2 System Requirements Analysis
SWE.1 Software Requirements Analysis

The most important process in this context is certainly the configuration management even though the application parameters are not mentioned there. However, the arguments above explain clearly how important the configuration management of the application parameters and their data sets are. Both for an assessment, but also for internal process improvement, a robust configuration management has to be considered, especially for the data sets of the application parameters, including variant management. Assessors will always address this in interviews, especially in the development of engine and transmission controls or in projects that build on platform projects.

Although the test processes do not mention application parameters explicitly, they are impacted if the parameters apply to the particular object under test. This should be considered in the corresponding test strategy.

If you wish to continue to the next chapter click here: