Focus on Reusability

Enhancing Agile Automotive Software Product Line Development by Similarity Analysis

3. August 2017 | Software & Testing Solutions

In the automotive domain, the complexity of software functions and the demanded quality standards, e.g. CMMI, ISO 26262, are still growing, while in the meantime the expected release cycles get shorter and shorter. In addition, the vehicle starts to turn into a smart device which is able to interact with its environment and to react autonomously. As a consequence, further aspects, such as security or privacy, receive a higher prioritization.

This up-to-date scenario is a great example for the frequently changing and hardly predictable demands in today’s automotive industry.

  • Who can ensure that features which are identified as necessary today will be required in a similar form tomorrow?
  • What is the adequate time frame for long-term strategies in the context of shorter and shorter release periods?

FEV’s PERSIST (powertrain control architecture enabling reusable software development for intelligent system tailoring) was established to give first answers to these questions. This approach introduces agile methods to be able to react flexibly on requirement changes and to reduce the duration of one development cycle and project quality risks due to continuous integration. Nevertheless, the establishment and maintenance of a Software Product Line (SPL) in the context of the daily work of a supplier has to face several ongoing projects in parallel. As a consequence, an approach is required which allows the project teams to focus on the implementation of the required product, while it is possible to continuously establish and maintain a SPL in parallel with minimized effort. Therefore, it is necessary to further extend the collaboration between Agile Software Development (ASD) and Software Product Line Engineering (SPLE), resulting in Agile Software Product Line Engineering (APLE).

Software Product Line Development Focused on Application Engineering

FEV searched for a SPL development method which provides essential feedback for the SPL during daily project work but reduces the additional effort for the projects to a minimum. The method does not require long-term decisions, keeps the SPL up-to-date and identifies new potential for reusable components is needed.

The main important development artifacts used during this process are the reference architecture, project architecture, component specification, test cases and the component implementation. The proposed method follows a component-based project-first approach: This means that the main item of the software architecture is a component and any specification for a component is first raised during project development. A component will only be considered to be redesigned in a more general way, if it is proven that a corresponding demand is given and a general component is a realistic opportunity within several projects. In addition, AE shall gain most benefit from the already established product line and components which are currently developed in different projects, without being slowed down by the burden of being dependent of generalized components.


Step by Step Process

1 In the first step, a new component is specified. This is done by performing a first draft of the interface with a related functional description.

2 In addition, its position in the software architecture is estimated. This is done by considering the reference architecture of the SPL. In the context of PERSIST, components are hierarchically arranged in a set of compositions. If a suitable component can be identified, which seems to be similar or identical to the specified component, the name and location of the component will be adapted to the reference architecture. This is the first step, where the SPL supports the project development. Complex architectural decisions can often be supported by experiences from the past which are stored in the reference architecture.

3 In case the component cannot be mapped, a specific position in the project’s software architecture needs to be defined.

4 In a second step the decision made in step 3 is reevaluated by the SPL team to avoid any false negatives.

5 If the component cannot be matched, the complete implementation will be performed from scratch. The new component is added to the reference architecture after its location has been agreed on.

6 If the component specified in the context of the project can be mapped to a component an extrinsical equality regarding the reference architecture can be established. This connection cannot only be used to compare the component under development with general components of the SPL but also to compare it with other individual, but extrinsical, equal components from different projects.

In addition further analysis can be performed on structural (interfaces) and semantical (test cases, function models) level.

7 If a candidate with a similarity lower than 100% is identified, this candidate can be used by the project team to finalize their own specification and the implementation can be based on the provided development artifacts.
The project team does not spend any additional effort on implementing a reusable component which is able to fulfil the requirements of both or more similar components. The identified similarities are only used to speed up the project development.

8 In a parallel step the SPL team evaluates if the identified similarities provide enough potential for a general reusable component. Based on the amount of similar components and the degree of similarity on structural and semantical level a decision has to be made whether to implement the component based on a similar component [7] or to proceed to step [9]: If the potential is high enough, the SPL team will implement a general component which can then be reused in further projects [9].

9 The proposed steps ensure that the project teams always specify components which are as close as possible to the already established reference architecture and available components. In the best case general components can directly be reused. Additionally all derivations of the reference architecture can automatically be spotted and the degree of variation can be evaluated. Therefore the potential degeneration of an established product line can be observed continuously and a synchronization between product and product line can be performed iteratively.


Activities 1 to 5 are already well established, while for activity 6 and 8 the necessary automatization is currently being finalized. General components, which are used in several projects, have already been established, but are always based on intensive manual reviews or a proactive approach. The possibility to investigate a given reference architecture during the specification of a new component is not noticed as an additional effort. Instead the reference architecture provides helpful information to perform architectural decisions.

In the current status the reference architecture consists of 219 components, whereas 125 (57%) components have no extrinsically equal match. 94 (43%) components of the reference architecture are part of more than one project and 61 (28%) of these components are also part of at least three projects.

Method for agile soft ware product line development: The colored activities represent activities which are performed by the SPL team, while the white ones are performed during projects.


The proposed approach provides the possibility of realizing the project-driven implementation work directly in the project without losing the benefits of a corresponding SPL. Each project team can benefit from the established reference architecture to speed up architectural decisions, while the similarity analysis can provide additional foundations for the actual implementation.