<figure><img src="image_1.png" /></figure>

HAL
open science

# Comparison of Configuration Rule Visualizations Methods

Anna Tidstam, Johan Malmqvist

► To cite this version:

Anna Tidstam, Johan Malmqvist. Comparison of Configuration Rule Visualizations Methods. 10th Product Lifecycle Management for Society (PLM), Jul 2013, Nantes, France. pp.550-559, 10.1007/978-3-642-41501-2_55. hal-01461905

HAL Id: hal-01461905

https://inria.hal.science/hal-01461905

Submitted on 8 Feb 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Comparison of configuration rule visualizations methods

Anna Tidstam and Johan Malmqvist

Chalmers University of Technology, Sweden

[anna.tidstam@chalmers.se](mailto:anna.tidstam@chalmers.se)

**Abstract.** The aim of this paper is to compare matrix- and list-based configuration rule visualization methods in order to find the effects of using a certain visualization method. Especially, the visualizations' impact on readability and how the configuration rules are authored are studied. A case study was conducted at two automotive manufacturing companies. The research method included to observe users as they were authoring configuration rules, to study the visualization methods, and to interviews users of the PDM system visualizing the configuration rules. It was found that common aim for the users is to author easy to read configuration rules, which this paper shows is highly dependent on the visualization method. The conclusion is thereby that the choice of visualization method influence how the configuration rules are authored.

**Keywords:** configuration rules, visualization, authoring

## 1 Introduction

Configurable products are specified by a set of alternative product features. Cars are often configurable, with alternative product features including engine sizes and exterior colors. To assure that the specification of a configured product belongs to the developed product offering, there are logic expressions. An example of those logic expressions is that the *exterior color red* is not offered with *engine size 1.8 liters*. Such logic expressions are in this paper called *configuration rules* following the definitions in [1, 2]. Moreover, configuration rules validate the correctness are according to [1] rules for validating the correctness of customer orders and for guiding the actual assembly of these orders. A similar explanation is used in [2], where configuration rules are the rules for how the components can be combined to form a product. One of the main difficulties with large sets of configuration rules is the maintenance, in other words modifying the configuration rules following a product offering modification [3]. To be able to maintain the configuration rules, there is a user interface with a visualization of configuration rules. A visualization of configuration rules is a representation of configuration rules for communication of configuration rules to a user. The visualization of configuration rules is a kind of *information visualization*. The aim of information visualization is to create an effective representation of the information model and the information contained therein [4]. Effectiveness means that the user as quickly as possible gets an overview of the information. The effectiveness is chal-
lenged for the configuration rule visualization as there may be hundreds of thousands
of configuration rules.

Some researchers have studied different methods for visualization of configuration rules, for example matrices: K- and V-matrix [5], and trees: Product Family Master Plan [6] and the Variant Tree [7]. The mentioned previous research is however not empirical studies with configuration rules from the automotive industry. Earlier studies have shown benefits of matrix-based methods for configuration visualization [8]. For example, a matrix organizes data into a structured overview that is difficult to achieve with a list of text strings. The advantages and disadvantages specific to configuration rules have however not been fully studied. There is a list-based configuration rules visualization from an automotive company in [9], but unfortunately this visualization is not in detail described nor evaluated. If the configuration rules cannot be effectively visualized, an alternative approach is to change representation as for example mathematical equations on design parameters which was suggested in [9].

The authoring, i.e. the creation and modification, of configuration rules depends on
the user: some users prefer a set of few but long (many product features) configura-
tion rules, while others prefer a set of many but short (few product features) configu-
ration rules [8]. The main aim with this paper is to compare configuration rule visual-
ization methods in order to find the effects of using a certain visualization method,
especially the impact on how the configuration rules are authored. A second aim is to
find advantages and disadvantages for the visualization methods at the two automo-
tive manufacturing companies. The following research questions have been ad-
dressed:

RQ1: What are the characteristics of the authoring methods for configuration rules that may be derived from the use of either matrix- or list-based visualization methods?

RQ2: Which visualization method is most suitable in the cases of:

(a) high number of configuration rules

(b) high number of product features in each configuration rule?

The remaining of the paper is organized as follows: In Section 2 the research
method is described, Section 3 presents the results, Section 4 discusses the results and
in Section 5 the conclusions are stated. Finally, in Section 6 future work is proposed.

## 2 Research Method

This paper studies the configuration rules visualization methods at two major Europe-
an automotive manufacturing companies, henceforth called Alpha and Beta.

The research study was conducted during a 3 months stay at Beta in the team of
configuration rules specialists, which was an adequate time-frame for revealing the
process of authoring configuration rules as well as getting acquainted with the PDM
backbone systems at Beta. During this time, several workshops were arranged with
Alpha, which gave the possibility to compare both authoring and visualization meth-
ods. As seen in Fig. 1, the research process was structured into three phases: analysis,
testing and evaluation. In the analysis phase, the authoring and visualization of con-
configuration rules were described. Then in the testing phase, the configuration rules at Beta were tested with Alpha's visualization method. This comparison was later evaluated during the evaluation phase by interviewing three configuration rules specialists with various years of experience (4-30 years) at Beta.

<figure><img src="image_3.png" /><figcaption>Fig. 1. Overview of applied research methods.</figcaption></figure>

# 3 Results

The result section is divided into three sections: 3.1 Analysis phase, 3.2 Testing phase and 3.3 Evaluation phase.

## 3.1 Analysis phase

In this section, a use case scenario is used for describing authoring and visualization methods at Alpha and Beta. The use case describes the authoring of configuration rules for a new feature variant *a3*, e.g. *orange exterior color*. New feature variants do not have any configuration rules initially, and the use case is to author the required configuration rules. Feature variant *a3* belongs to feature family *A* (e.g. *exterior color*), which already contains the feature variants *a1* (e.g. *red*) and *a2* (e.g. *green*). Both Alpha and Beta use codes for feature families and feature variants.

**Authoring and visualizing configuration rules at Alpha.** The purpose of this section is to show the principles for how to author configuration rules at Alpha (using their matrix-based visualization method), which is then followed by another section for Beta (using their list-based visualization method).

The authoring process at Alpha consists of three steps: Step 1 is to visualize existing configuration rules, Step 2 is to update the feature family relationship, and Step 3 is to assign configuration rule values. The authoring of configuration rules is thereby prepared in Step 1, and actually performed in Step 2 and 3.

Step 1 is to visualize the configuration rule matrix for feature family *A*, as shown in Fig. 2. The systematic configuration rule value (S) indicates that only particular combinations of feature variants are allowed. The only allowing configuration rule for *a1* is IF *a1* THEN (*m1* AND *n1*), e.g. IF *red* THEN (*engine V6* AND *sport package*). The minus signs restrict feature variant combinations, e.g. NOT (*a1* AND *m2* AND *n1*).
<table><thead><tr><th rowspan="3"></th><th colspan="2">Feature families</th><th colspan="4">THEN</th></tr><tr><th rowspan="2">M<br>N</th><th colspan="2">Feature variant combinations</th></tr><tr><th>m1<br>n1</th><th>m2<br>n1</th></tr></thead><tbody><tr><th rowspan="3">IF</th><th>Feature family</th><th>Feature variant</th><td></td><td></td><td></td><td></td></tr><tr><td>A</td><td>a1</td><td>S</td><td>-</td><td></td><td></td></tr><tr><td>A</td><td>a2</td><td>-</td><td>S</td><td>-</td><td></td></tr><tr><td></td><td>A</td><td>a3</td><td>-</td><td>-</td><td></td><td></td></tr></tbody></table>

$S = \text{systematic and } - = \text{not allowed}$

<caption>**Fig. 2.** An example of Alpha's configuration rule matrix. This visualization is studied during the first step in authoring configuration rules at Alpha.</caption>

Step 2 is to update, if necessary, feature family A's relation, see Table 1. Feature family relations are the source data for the generation of any configuration rule matrix. In this use case scenario, it is assumed that feature family P is required because of the addition of feature variant a3.

<table><caption>**Table 1.** Feature family A with its relation left) before update with P and right) after the update.</caption><thead><tr><th colspan="2">Before update</th></tr><tr><th>IF</th><th>THEN</th></tr></thead><tbody><tr><th>Feature family</th><th>Feature families</th></tr><tr><td>A</td><td>M, N</td></tr></tbody></table>

<table><thead><tr><th colspan="2">After update</th></tr><tr><th>IF</th><th>THEN</th></tr></thead><tbody><tr><th>Feature family</th><th>Feature families</th></tr><tr><td>A</td><td>M, N, P</td></tr></tbody></table>

Step 3 is to assign configuration rule values, see Fig. 3. The new optional configuration rule value (O) for a3 is the feature variant combination m2 AND n1. Among optional configuration rule values, there is a default configuration value (D) which is the preferred feature variant combination. The configuration rule value for a2 also needs to be updated as it is no longer the only allowed feature variant for combination m2 AND n1.

<table><thead><tr><th rowspan="3"></th><th colspan="2">Feature families</th><th colspan="4">THEN</th></tr><tr><th rowspan="2">M<br>N<br>P</th><th colspan="2">Feature variant combinations</th></tr><tr><th>m1<br>n1<br>p1</th><th>m2<br>n1<br>p1</th><th>m1<br>n1<br>p2</th><th>m2<br>n1<br>p2</th></tr></thead><tbody><tr><th rowspan="3">IF</th><th>Feature family</th><th>Feature variant</th><td></td><td></td><td></td><td></td></tr><tr><td>A</td><td>a1</td><td>S</td><td>S</td><td>-</td><td>-</td></tr><tr><td>A</td><td>a2</td><td>-</td><td>-</td><td>D</td><td>D</td></tr><tr><td></td><td>A</td><td>a3</td><td>-</td><td>-</td><td>O</td><td>O</td></tr></tbody></table>

$S = \text{systematic, D = default, O = optional and } - = \text{not allowed}$

<caption>**Fig. 3.** Configuration rule matrix with updated configuration rule values for feature variant a3, which is done during the third and last step in authoring configuration rules at Alpha.</caption>

The authoring and visualization of configuration rules at Alpha have now been described, and now it will be shown how the same operation is performed at Beta.
**Authoring and visualizing configuration rules at Beta.** The same use case scenario is used when described in the authoring method at Beta: Step 1 is to visualize the existing configuration rules, and Step 2 is to author the configuration rules.

Step 1 in the use case is to visualize configuration rules for *a1* and *a2*, see Table 2. The purpose of Step 1 is to find frequently used feature families, for example all engine sizes can have configuration rules with gear box alternatives. The configuration rules at Beta may include both positive (AND, OR) and negative operators (NOT).

<table><caption>**Table 2.** List-based visualization of configuration rules studied for finding frequently used feature families that could be suitable to use for authoring of configuration rules for *a3*.</caption><thead><tr><th>IF</th><th>THEN</th></tr><tr><th>Feature variant</th><th>Feature variant combinations</th></tr></thead><tbody><tr><td><i>a1</i></td><td><i>m1</i> AND <i>n1</i> AND NOT(<i>a2</i>)</td></tr><tr><td><i>a2</i></td><td><i>m2</i> AND <i>n1</i> AND NOT(<i>a1</i>)</td></tr></tbody></table>

Step 2 is to author the configuration rule for *a3*, see Table 3. As the customer may choose between *a2* and *a3*, also the configuration rule for *a2* has to be re-formulated. Notice that there is no difference between default and optional feature variant combinations at Beta, as this distinction is managed the separate sales system.

<table><caption>**Table 3.** List-based visualization of configuration rules with new configuration rules for *a3*, and updated configuration rule for *a2*.</caption><thead><tr><th>IF</th><th>THEN</th></tr><tr><th>Feature variant</th><th>Feature variant combinations</th></tr></thead><tbody><tr><td><i>a1</i></td><td><i>m1</i> AND <i>n1</i> AND NOT(<i>a2</i> OR <i>a3</i>)</td></tr><tr><td><i>a2</i></td><td><i>m2</i> AND <i>n1</i></td></tr><tr><td><i>a3</i></td><td><i>m2</i> AND <i>n1</i></td></tr></tbody></table>

The analysis phase is thereby ended and the next section will describe the testing phase.

## 3.2 Testing phase

The purpose of the testing phase is to find relevant measures for the matrix- and the list-based visualization methods and thereby compare those using three real case examples. The real case examples were selected based on the users' at Beta interest in trying challenging examples, for instance configuration rules with extremely many configuration rules or extremely many feature variants within the configuration rules. One of the real case examples visualized with Alpha's matrix-based method is shown in Fig. 3. Two measurements have been established: a size measurement *G* in the growth direction (number of columns for the matrix, number of rows for the list), and a combinatory difficulty measurement *C* which is the number of feature variants combined in a configuration rule. The number of columns in Fig. 4 is 10, but note that the number of columns is here reduced, as for example the empty cells for the row of
feature family *P* could be filled with any of *p*1 or *p*2. The combinatory difficulty measurement is equal to the number of rows with feature variants in the matrix, which is 9 in Fig. 4. The number of configuration rules, could be counted as a range between 1-10, as the configuration rule values could be combined with the OR-operator.

<figure><img src="image_4.png" /><figcaption>**Fig. 4.** Alpha's configuration rule matrix with the measurements relevant for the tests (number of feature variants, number of feature variant combinations) marked out.</figcaption></figure>

The same example with Beta's original authoring of configuration rule list is shown in Fig. 5. The number of rows are 5 for measurement *G*, and the combinatory difficulty measurement *C* (number of feature variants in a configuration rule) is a range 3 to 12.

<table><caption>**Fig. 5.** Beta's configuration rule list with the measurements relevant for the tests (number of configuration rules and maximal number of feature variants) are marked out.</caption><thead><tr><th>IF</th><th colspan="7">THEN</th><th>Growth measurement</th><th>Combinatory difficulty measurement</th></tr><tr><th>Feature variant</th><th colspan="7">Feature variant combinations</th><th></th><th></th></tr></thead><tbody><tr><td>al</td><td colspan="7">(n1 AND s2) OR (n1 AND s1 AND t1) OR (n2 AND o5) OR n4 AND p2</td><td>1</td><td>10 (al, n1, s2, n1, s1, t1, n2, o5, n4, p2)</td></tr><tr><td>al</td><td colspan="7">n4 AND r1</td><td>2</td><td>3 (al, n4, r1)</td></tr><tr><td>al</td><td colspan="7">(n1 AND s1 AND t1) OR (n4 AND o4)</td><td>3</td><td>6 (al, n1, s1, t1, n4, o4)</td></tr><tr><td>al</td><td colspan="7">((n1 AND s2) OR (n1 AND s1 AND t1) OR (n2 AND (o5 OR o6) OR n4) AND q1) AND p1</td><td>4</td><td>12 (n1, s2, n1, s1, t1, n2, o5, o6, n4, q1, p1)</td></tr><tr><td>al</td><td colspan="7">n3 AND (o1 OR (o3 AND t1))</td><td>5</td><td>5 (n3, o1, o3, t1)</td></tr></tbody></table>

The test result summary for the three real case examples and the measurement in the growth direction (*G*) is shown in Table 4. The trend is that the number of matrix columns is higher than the list rows, which may be a disadvantage when using a ma-
trix-based visualization method. The combinatory difficulty measurement (C), shown in Table 5 does not show a clear trend. The matrix-based visualization can, but not necessarily, have a combinatory difficulty within the range of the list-based visualization method. It all depends on how the configuration rules are authored and which configuration rules that are visualized together.

<table><caption>**Table 4.** Test results of measurements growth direction measurement (number of columns vs. rows) for three real case examples (A-C).</caption><thead><tr><th>Company</th><th>Alpha<br>(matrix-based visualization)</th><th>Beta<br>(list-based visualization)</th></tr><tr><th>Growth measurement</th><th>Number of columns</th><th>Number of rows</th></tr></thead><tbody><tr><td>Example A</td><td>8</td><td>is more than 4</td></tr><tr><td>Example B</td><td>12</td><td>is more than 9</td></tr><tr><td>Example C</td><td>10</td><td>is more than 5</td></tr></tbody></table>

<table><caption>**Table 5.** Test results of combinatory difficulty for three real case examples (A-C).</caption><thead><tr><th>Company</th><th>Alpha<br>(matrix-based visualization)</th><th>Beta<br>(list-based visualization)</th></tr><tr><th>Combinatory difficulty<br>measurement</th><th colspan="2">Number of feature variants in combination</th></tr></thead><tbody><tr><td>Example A</td><td>3</td><td>is less than max 4</td></tr><tr><td>Example B</td><td>41</td><td>is more than max 34</td></tr><tr><td>Example C</td><td>9</td><td>is less than max 12</td></tr></tbody></table>

### 3.3 Evaluation phase

Three semi-structured interviews were held with configuration rules specialists from Beta, where they commented on the benefits and disadvantages of the matrix- and the list-based visualization method based on the real case example from the previous section. During the interviews it was found that the advantages of using the matrix-based visualization method were dominating. Arguments were that the list-based configuration rules at Beta were similar to programming with many symbols for Boolean operators and complicated use of brackets. The matrix-based visualization method does not contain any explicit Boolean algebra (signs such as OR (/), AND (,), NOT(-), AND-NOT (+-)). One quotation from an interviewee's comments is:

> Our PDM system [with list-based visualization method] contains Boolean algebra which is for few people understandable, especially since we combine so many +, - and (). The matrix [without any explicit use of Boolean algebra] is in general always easier to overview and understand.

The non-specialists at Beta have great difficulties in reading the Boolean algebra in the configuration rules. This is in contrast to the non-specialists at Alpha who are
competent to review the configuration rule matrixes at monthly meetings, and as well as soon there is a modification need.

# 4 Discussion

The main aim of this paper is to compare configuration rule visualization methods in order to find effects of how configuration rules are authored from using a certain visualization method. A second aim is to find advantages and disadvantages of the visualization methods at the two automotive manufacturing companies. The following research questions have been addressed:

**RQ1: What are the characteristics of the authoring methods for configuration rules that may be derived from the use of either matrix- or list-based visualization methods?**

Overall, people not familiar with the authoring of configuration rules may find it difficult to even compare the use of matrix- and list-based visualization methods. For experienced users, the probably most striking difference is that, in contrast to Beta, Alpha has a visualization method generated from feature family relations. The feature family relations are extremely important for the configuration rule matrix, as reducing the number of feature family relations is the only way users can prevent the number of matrix columns from becoming high. The user wants to have few matrix columns in order to have an easy overview configuration rule matrix. Few feature family relations give short but many configuration rules.

At Beta, it is instead the number of rows in the configuration rule lists that the users are trying to prevent from growing. That is another optimization objective, causing the configuration rules to differentiate from Alpha's configuration rules: Beta authors long but few configuration rules. The combinatorial difficulty is then higher for a list than for a matrix when the users aim for an easy to overview visualization of configuration rules.

**RQ2: Which visualization method is most suitable in the cases of:**

(a) high number of configuration rules

(b) high number of product feature variants in each configuration rule?

**Answering RQ2a:** A high number of configuration rules potentially cause the visualization of configuration rules to become, independently of the visualization method, unmanageable big. The disadvantage of the matrix-based visualization method is that the number of matrix columns can potentially grow faster than the number of rows in the list-based visualization. This was shown in the tests conducted in this paper, where all three tests examples had this behavior. When there is a high number of configuration rules to be visualized, the list-based method has the advantage there are many logical operators that could be used in order to prevent the number of rows to grow rapidly. The recommendation is therefore to use a configuration rule list when a high number of configuration rules are visualized.
*Answering RQ2b:* A high number of feature variants in combination causes combinatorial complexity. The benefit of the matrix-based visualization is that it does not have the OR operator; there are only the operators AND and NOT. This is a very important fact, as it is the OR operator that enables the high number of feature variants in combination. Without the OR operator, the configuration rule has to be visualized using several shorter configuration rules, with lower combinatorial difficulty and thereby easier to read. Based on this discussion, the conclusion is that the matrix-based visualization method is well suited for visualizing configuration rules with a high number of feature variants in combination.

# 5 Conclusions

The visualization method strongly influences how the configuration rules are au-
thored, as there are different optimization goals for readability (few matrix columns
vs. few list rows) and availability of logical operators (with vs. without OR operator).
There are therefore obstacles when changing visualization methods, here summarized
below.

*From a list-based visualization method to a matrix-based visualization:* the matrix
will potentially get many columns.

*From a matrix-based visualization to a list-based visualization:* the strength of the list is not shown until the configuration rule are reformulated with the introduction of the OR operator.

The interviewed configuration rules specialists however strongly preferred the ma-
trix-based visualization method even when admitting the strength of the list-based
visualization method. The main argument was that the matrix-based visualization kept
the Boolean algebra simple as it did not allow any OR operator. With a simple Boole-
an algebra, the configuration rules are becoming easier-to-read for all users working
with configuration rules and that would make the development of configuration rules
more efficient.

6 Future work

The three examples tested in this paper were selected on the basis of the users' wishes to test the visualization methods' strengths and weaknesses on challenging examples. Challenges in this context mean that the users had either a high number of configuration rules, or a high number of feature variants in each configuration rule. This is similar to a stress test, where a concept is tested under extreme conditions. A suitable continuation would be to build a prototype that the users could test under normal work conditions, which could capture more opinions of strengths and weaknesses of the two visualization methods.
**Acknowledgements.** This work was carried out at the Wingquist Laboratory VINN Excellence Centre for Efficient Product Realization at Chalmers University of Technology, supported by the Swedish Governmental Agency for Innovation Systems (VINNOVA). Further financial support was received from ProViking. For supervision during the industrial stay the first author would like to thank Hr. Eiffinger.

References

1. Barker, V.E., O'Connor, D.E.: Expert systems for configuration at Digital: XCON and beyond. Communications of the ACM 32(2):298--318 (1989)

2. Soininen, T., Niemelä, I.: Developing a declarative rule language for applications in product configuration. Practical Aspects of Declarative Languages, Lecture Notes in Computer Science, vol. 1551, pp. 305--319 (1998)

3. Bachant, J., McDermott, J.: R1 revisited: Four years in the trenches. AI Magazine 5:21--32 (1984)

4. Mackinlay, J.: Automating the design of graphical presentations of relational information. ACM Transactions on Graphics 5(2):110--141 (1986)

5. Bongulielmi, L., Henseler, P.C., Puls, C. and Meier, M.: The K- & V-Matrix-Method in Comparison with other Matrix-based Methods supporting Modular Product Family Architectures. In Sigurjonsson, J.B. (eds.) Proceedings of NordDesign, Trondheim, (2002)

6. Harlou, U.: Developing product families based on architectures – Contribution to a theory of product families, PhD thesis, Department of Mechanical Engineering, Technical University of Denmark. (2006)

7. Schuh, G., Jonas, I.: Variantenreduzierung im Verbund – Praktikable Methode zum Variantenmanagement: Ein Leitfaden zur Beherrschung der Variantenvielfalt. Verbundinitiative Automobil Nordrhein-Westfalen, Düsseldorf, Germany (1997)

8. Tidstam, A., Malmqvist, J.: Authoring and Verifying Vehicle Configuration Rules. In: (eds.) Proceedings of 8th International Conference on Product Lifecycle Management, 11-13 July, Eindhoven, The Netherlands. (2011)

9. Hami-Nobari, S., Blessing, L.: Effect-oriented Description of Variant Rich Products. In: (eds.) Proceedings to International Conference on Engineering Design (ICED2005), Melbourne, Australia, 15-18 August (2005)