01

Firstly, this demands uniform, end-to-end variant manage-ment across all the different development stages: from the recording of the requirements in the early phase, through the draft function and system design, software and hard-ware development for the components, cable harness development, during analysis of the design for building the needed safety argument(s), and on to the definition of the test specifications. Secondly, the defined variants must be controlled beyond the development phase and on into pro-duction and service. Here again, a methodical, end-to-end approach is required. Thirdly, the specified variants have to be exchanged between vehicle manufacturers and their suppliers via established standards such as AUTOSAR or the VDA cable harness list (KBL) using clear, secure processes. Therefore, an accepted standard for variant management offers many advantages.

That is why wide-ranging concepts for variant manage-ment in the software and communication fields have been defined in AUTOSAR. Vector’s PREEvision E/E develop-ment environment embodies these approaches and also

Practically all electrical/electronic (E/E) developments in the automotive industry now use a product line approach. The development object is not just a certain vehicle model but a whole vehicle family with many different drive, body and equipment variants. This is why one often hears the terms E/E toolbox or E/E platform being used to describe the development object, or product line. Starting with this type of E/E product line, it is necessary to support the different vehicle models as variants and allocate systems and components to them. Efficient variant management is therefore essential for development.

Product Lines and Variant Management in E/E Engineering

PREEvision Technical Article

takes account of the variant management mechanisms that have proven themselves in practice in product lifecycle management systems. For users, the result is methodolog-ically new, easy-to-use variant management concepts in a single tool: for every application from requirements and test specifications, through the function and software architecture, communication and on to the hardware com-ponents and wiring harness. AUTOSAR distinguishes be-tween concepts in the solution space and concepts in the problem space. Both of these are considered in this article.

Product Line, Variation Point Sets and Variant ConditionsIn PREEvision, it is possible to model a product line on different abstraction levels: requirements, logical function architecture, software architecture, hardware architec-ture, communication and wiring harness. The product line contains all the artifacts for various different products or variants. A variant is a fully characterized product and therefore a subset of the artifacts of the product line. This can be illustrated by an example from the field of power-train (Figure 1).

02

Product Lines and Variant Management / November 2019

Let us look at a vehicle product line from the point of view of the software design, the hardware design and the map-ping between the software and hardware for two engine variants: gasoline engine and diesel engine; and two trans-mission variants: manual and automatic. Even this very simple example makes one thing clear: The definition of the subsets for the different variants is of central importance (Figure 2).

The subsets are formed by using so-called variation points. A variation point defines whether or not a model artifact in the product line is an optional component of a variant de-rived from the product line. This is done using a concept of a variation point condition that depends on system con-stants and literals. In the example we are looking at here, the following system constants are used:

> System constant Engine Type with the literals Gasoline and Diesel > System constant Capacity of the engine with the literals 2000 cm3 and 3000 cm3

> System constant Number of Cylinders with the literals 4 cylinders and 6 cylinders > System constant Transmission with the literals Automatic and Manual

AUTOSAR defines an initial state in order to keep the work involved in defining the variation points to a minimum: If no variation point is defined for an artifact then, by definition, it is common to all the variants. This means that variation points are only defined for the artifacts that can actually vary. The initial state (default) applies to the great majority of the artifacts in a product line that are common to all variants. Combining artifacts with identical variation points to form the depicted subsets makes it easier to define and maintain variation points.

Figure 1: Software/hardware design and software-hardware mapping for a vehicle product line with two engine and transmission variants.

Figure 2: Relevant subsets for creating variants.

03

Product Lines and Variant Management / November 2019

The variant condition for a set of variation points can be entered in graphical or text form and then applies for all the artifacts in the subset (Figure 3). For all the mechanical components, the decision regarding the variant is made by the vehicle build time at the latest. However, in the case of the software scopes, it is also possible to make decisions regarding variants later by means of coding or flash pro-gramming – for example at the service workshop or by the user of the vehicle. Therefore, the AUTOSAR variant man-

Figure 3: Variation point set Automatic Transmission Only with variant condition TransmissionType==Automatic.

Figure 4: Activated variant Gasoline Automatic

Variant Set of System Constant Values System Constant System Constant ValueGasoline Automatic Gasoline Engine Value Set Engine Type Gasoline Displacement 3000 NumberCylinders 6 Automatic Transmission Value Set Transmission Type AutomaticDiesel Manual Diesel Engine Value Set Engine Type Diesel Displacement 2000 Number Cylinders 4 Manual Transmission Value Set Transmission Type Manual

agement concepts distinguish between pre-build and post-build variant conditions. In the case of pre-build conditions, it is possible to define the precise time when a variant con-dition becomes fixed, the ‘binding time’. AUTOSAR has a standardized list of possible binding times: System Design Time, Code Generation Time, Pre-Compile Time, Link Time. This makes it clear that the system constants may be found again directly in the software implementation, for example in the form of pre-compiler commands.

Variants and the Values of System ConstantsTo define variants, a value is assigned to every system con-stant. This is done indirectly by means of value sets: To compute a concrete variant, these defined values are en-tered in all the variation point conditions. If a condition is evaluated as true then the artifacts of the assigned varia-tion point set are present in the variant. If a condition is evaluated as false then the artifacts are not present in the variant. If no variation point is defined for an artifact then it is also part of the variant (by definition). Following com-putation, the variant can be activated. All artifacts that are not allocated to the activated variant are then dis-played ‘grayed-out’ in PREEvision (Figure 4).

The user can then check whether the variant is fully defined and that there are no conflicts (using automated consis-tency checking) and can add new or correct existing varia-tion points. The hierarchical nesting of variants is also pos-sible: The two drive variants defined in the example could be referenced from a higher-level vehicle variant, which also references chassis or body variants. This makes it pos-

04

Product Lines and Variant Management / November 2019

> mandatory (Must Use) > alternative (Requires Xor) > multiple (Requires Or) > optional (Optional)

It is also possible to define the logical relationships excludes and requires between any given features. All the permissi-ble logical relations between the individual features are therefore defined in the Feature Model. If features are selected in the next step then this selection must comply with the Feature Model, and tool support (such as is pro-vided by PREEvision) enables the highlighting and correc-tion of incompatible selections. A Feature Selection Set corresponds to a variant in the problem space (Figure 5).

Feature MapFinally, the so-called Feature Map brings together the Feature Selection Set in the problem space and the variant in the solution space. The input variable for the Feature Map is a given Feature Selection Set. The output variable is a set of valid system constant values, which can then

sible to subdivide work across areas of responsibility. Variation points, system constants and variants are part of the AUTOSAR solution domain concept and are mandatory. They can be used for many artifacts on the software, com-munication and network level and can be exchanged via AUTO SAR ECU Extract of System Description (or ‘ECU Ex-tract’) files. ECU Extract files generated in this way do not only describe a concrete software variant. They also con-tain a set of variants that the software supplier then implements.

Feature Model and Feature Selection SetIn addition, AUTOSAR provides further concepts in the prob-lem domain that can be used if desired. For example, when it is not possible to determine whether certain subsets are mutually exclusive using the solution domain concepts presented above, then support is provided by AUTOSAR Feature Models, which are based on the Feature Oriented Domain Analysis (FODA) approach (Figure 5). Here, it is possible to model four different decomposition relations between a composition feature and its part features:

Variant Set of System Constant Values System Constant System Constant ValueGasoline Gasoline Engine Value Set Engine Type Gasoline Displacement 3000 NumberCylinders 6Diesel Diesel Engine Value Set Engine Type Diesel Displacement 2000 Number Cylinders 4Automatic Automatic Transmission Value Set Transmission Type AutomaticManual Manual Transmission Value Set Transmission Type Manual

Figure 5: Feature Model (left) and the activated Feature Selection Set Gasoline Automatic (right).

05

Product Lines and Variant Management / November 2019

again be assigned to a variant. It is necessary to take account of the following during system and software development: In the conventional division of work between vehicle manufacturer and supplier, the system constants can persist right through to the software implementation stage. That is why the software supplier is usually responsi-ble for defining the system constants.

By contrast, the vehicle manufacturer is responsible for the Feature Model and this is used globally by Marketing, Sales, Development and Production. As a result, the Feature Map must permit the necessary decoupling between the prob-lem and solution space. If necessary, a simple symbolic language can be used to define the relationship between features and sets of system constant values. In PREEvision, it is possible to export all the concepts in the problem and solution space as an AUTOSAR system description file or import the corresponding file.

Figure 6: Wiring harness diagram with variant conditions for the single wires.

SummaryUsing the functions presented here, it is possible to imple-ment an efficient, end-to-end process for variant manage-ment in the problem and solution domain: Feature Models, Feature Selection Sets and Feature Maps are defined in the problem domain. System constants and literals, varia-tion points, variants and system constant values are de-fined in the solution domain. PREEvision supports the com-putation of variants by means of three evaluation stages:

Feature selection is partially automated and is performed based on the Feature Model. The Feature Map that is used to compute a variant is then evaluated over a Feature Selection Set. In the third step, the variation points are evaluated in the context of a variant and the variant is activated. This approach is not only available for AUTOSAR artefacts that are modelled in PREEvision, but also for all artifacts on all abstraction levels. This makes possible a uniform, end-to-end variant management process for all the roles involved in the E/E development process.

Thanks to a complete library of system constants and liter-als that is used in both Production and Service, variation points may be defined for artifacts from the requirements stage through to the test specifications, from the function and software architecture through to the wiring harness. The variant conditions for wiring harness artifacts can be exchanged between the vehicle manufacturer and supplier using the KBL (cable harness list) standard (Figure 6). This ensures an end-to-end approach that goes right through to the production processes and is also applicable to this use case.

Author Dipl.-Ing. Jörg Schäufele Vector Informatik GmbH Product Manager PREEvision

Originally published in “Hanser Automotive” magazine Issue 10/2019 – October 2019