Basics of product line development

As consumers, we have different requirements for the products we use every day. For this reason, manufacturers offer their products in different variants. The effort required to develop and maintain a product portfolio with a large number of different product variants is much higher. At the same time, developing product variants from scratch is impossible because it is very expensive. This is usually not necessary either, because product variants often differ only in individual aspects, i.e. a large part of the functional scope is shared between variants.

In this article, we address the systematic development of product variants, first looking at the basic process including core concepts. Concepts beyond that, as well as the technical implementation, will be explained in further blog articles.

Development processes

The development of product variants consists of two core processes: Development for Reuse (Domain Engineering) and Development by Reuse (Application Engineering). Both processes form the basis for the development of a product line, i.e. development of similar products through systematic reuse within a well-defined domain (e.g. car or smartphone).

Problem Space/Solution Space

In addition, the two areas Problem Space and Solution Space are distinguished. In Problem Space, the product line is planned and controlled: variability modeling and configuration. In Solution Space, everything revolves around the technical development of the product line: methods for implementation as well as product generation.

As an example of a product line, let’s take a car.

Domain Engineering

The goal of domain engineering is the development of a product line instead of a single product. The focus is on the development of reusable building blocks (implementation artifacts) that can be flexibly incorporated into different product variants. The artifacts do not represent a finished product because they contain more than a single product variant needs. For this reason, these artifacts are also called 150% models. For the development of the product line, the requirements of all (including potential) customers are taken into account. The basis for product line development is variability modeling. With its help, similarities and differences between product variants are captured and represented by means of features.

A feature is an optional/incremental function extension that covers a customer requirement. Typical features for a car are different powertrains (gasoline, diesel, hybrid, electric), assistance systems (e.g. cruise control, lane departure warning or hill start assist) as well as further equipment features (e.g. radio entertainment system, air conditioning or roof windows). The modeled features are developed as reusable artifacts in the implementation using different techniques. This spans all areas where variability comes into play. For example, to develop a cruise control system, the following things need to be extended:

• Concrete requirements, such as “The cruise control must be able to maintain vehicle speed independently after being turned on by the driver.”
• Architecture, i.e., embedding the cruise control in the car (including connections at the steering wheel and necessary ECU interfaces).
• Electrics/electronics, i.e. all components of the hardware with which the driver can control cruise control functions.
• Software, i.e. programs for signal control and speed display.
• Tests, i.e. ensuring that the implemented solution meets the requirements.
• User manual, i.e. instructions for use for the driver.
• Repair manual, i.e. instructions for workshops for fault diagnosis and repair.
• etc.

Application Engineering

Application engineering (development through reuse) is the process of deriving a concrete product variant from reusable domain engineering artifacts. To do this, the first step is to match the customer requirements with the existing features of the variability modeling. The matching is done manually and is typically done in a configuration tool. Most people will already have come into contact with product configurators, e.g. at automobile manufacturers or online stores, where features/product characteristics can be adapted as part of the ordering process. In our example, the customer selects the cruise control and lane departure warning features, but leaves out the roof window feature. The finished configuration, together with the reusable domain engineering artifacts, is input for product generation. In this process, a product variant is generated – ideally fully automatically – from all relevant artifacts. Because the reusable artifacts do not change, different product variants can be generated by entering different configurations. The underlying generator takes into account all the different artifacts (concrete requirements, architecture, etc.) previously created in domain engineering.

Application Engineering is connected to Domain Engineering via a feedback loop. I.e. requirements that cannot be taken into account during configuration are fed into the variability modeling. Within the modeling, new/changed requirements lead to an adjustment of the product portfolio and finally to new/changed features within the product line implementation.

Interaction of Domain Engineering and Application Engineering

The representation of Domain and Application Engineering in the first figure is detached from the individual disciplines that still take place within product development (Requirements Engineering, Design, Realization and Quality Assurance). Looking at the individual disciplines, the following picture emerges for Domain and Application Engineering:

All engineering disciplines are interconnected analogously to product development for a single product. Thus, design builds on the results of requirements engineering, realization builds on the results of design, and so on. The difference here is that the disciplines occur twice: once in Domain Engineering with e.g. Domain Requirements Engineering and once in Application Engineering with Application Requirements Engineering. The focus of the domain engineering disciplines is the creation of reusable artifacts. For example, when creating requirements specifications in Domain Requirements Engineering, it is taken into account that not all car variants contain a cruise control. That is, the requirements for cruise control are marked in such a way that they apply only to all product variants of the car with cruise control and are disregarded for all other product variants.

When the “variable” requirements are transferred from domain requirements engineering to application requirements engineering, these requirements are configured so that a concrete car can be created from them. Ideally, the transfer of variable requirements in application requirements engineering is purely by configuration. This means that no new requirements have to be created for the new product variant when it is created. The same applies to the other engineering disciplines such as Design, Realization and Quality Assurance.

Dealing with variant-specific enhancements

With the division of the engineering disciplines into domain engineering (development for reuse) and application engineering (development through reuse), variant-specific enhancements, i.e. enhancements that are potentially only needed for one product variant, can be implemented either in domain engineering or in application engineering. For implementation in the two different process areas, the following points must be considered in each case:

*Application Engineering:

• Resource commitment: The development of a product line aims at a high degree of automation regarding the derivation of product variants. As described before, there are ideally no development activities in the context of application engineering. In other words, application engineering is a lightweight process and is limited to configuration and product derivation tasks. If development activities take place in both domain engineering and application engineering, problems can arise in the organization (e.g., competitive situation/discussion about responsibilities due to “distributed development”), which impede development progress.

• Lack of reuse: If a product-specific enhancement is to be used in another product variant after all, then the enhancements must either be ported to the new product variant, or they must be incorporated into the product line itself – as part of domain engineering.

• Preplanning enhancement, integration, and post-provisioning: To implement variant-specific enhancements, provisions must already be made during product line development (domain engineering). I.e. possible extensions must be pre-planned so that after the product generation has been carried out, the extensions can be implemented as easily as possible. In addition, precautions must be taken for the technical integration and follow-up supply of the extensions. This is because with the further development of the product line in domain engineering, the basis/base (jumping off point) for the variant-specific extensions may have to be raised to a new level. See the picture below for this. Let’s assume that the implementation artifacts of domain engineering are stored in the master. With the product generation at time X, the basis a for the variant specific development (b to d). In parallel, the product line has evolved with versions 1 to 3 (new features, bug fixes, …). An “upgrade” of the variant based on the newer developments in the master has to be considered and concerns

  • the pre-planning: where will changes be made in the variant?
  • the integration: how are changes – automated if possible – integrated?
  • the post-provisioning: When are changes from domain engineering applied?

*Domain Engineering:

• Maintenance: product specifics must be maintained as part of the product line. I.e., higher efforts may be expected here.
• Variant-specific features: For control and configuration purposes, variant- or customer-specific features, e.g. ‘customer_ABC’ or ‘model_XYZ’, must be introduced and maintained as part of the development.