Virtual Tabulation

The 3. Generation Configuration Technology

[Abstract]

Henrik Hulgaard
Virtual Tabulation
© Copyright 2019 Configit A/S

Contact information
Configit A/S
Kristianiagade 7
DK-2100 Copenhagen Ø
Denmark
Tel.: +45 7022 6700
Fax: +45 7022 6711
Mail: info@configit.com
www.configit.com

Legal notes
This document is © Copyright Configit A/S and may not be distributed without permission from
Configit. The content is strictly confidential and only intended for those receiving this directly
from Configit.
Configit, the Configit logo, Virtual Tabulation, Configit Product Modeler, Configit Runtime,
Configit Quote for SAP and other Configit product names are trademarks or registered trade-
marks of Configit A/S. All other product and service names mentioned and associated logos
displayed are the trademarks of their respective companies.
Contents
1. Introduction......................................................................................................................... 1
2. The Interactive Configuration Problem ............................................................................ 1
3. The Product Model ............................................................................................................. 2
4. Three Generations of Solving the Configuration Problem ............................................. 3
5. A Simple Example .............................................................................................................. 4
6. Compilation Statistics ........................................................................................................ 6
7. Advantages of the Compilation-Based Approach ........................................................... 7

iii
Virtual Tabulation

1. Introduction
Configit’s software products are all based on the patented configuration technology Virtual
Tabulation. Virtual Tabulation solves the difficult part of the configuration problem once, where
traditional approaches solve it over and over again. Because of this key difference, Configit
offers significant improvements in the way configuration solutions are created, maintained,
deployed and used. This white paper describes the virtual tabulation approach to solving the
configuration problem and presents some of the benefits of using this technology.

2. The Interactive Configuration Problem

The development and use of product configurators has been touted as one of the more
important IT enabled technologies to facilitate mass customizations of large numbers of
product variants. The configurator supports the process of selecting values for the parameters
that control the product variant. Typically, there are hundreds of such parameters and what
significantly complicates the problem is that the parameter values must satisfy a number of
rules that describe the inter-dependencies between parameter values. The rules come from
several different sources: from legal regulations, from engineering constraints and from
marketing. A configurator guides the user to find a combination of the parameter values that
satisfy all rules. Furthermore, a customer that uses a web-site or an iPad application to
investigate what options are available will only be interested in a few of the parameters and
he/she should only see those combinations that are available in the relevant market and that
satisfy all the rules.
A configuration solution provides two basic functionalities:
• a framework for rule authoring:
o Define the rules, i.e., what values are valid for the parameters and their inter-
dependencies.

o Support for analyzing and testing the rules to ensure the correctness of the rule-
set before releasing to downstream systems.

• Provides the runtime components (rule-engine) that are used by configurators. A

configurator is the software that guides a user to select values for all the parameters
such that all rules are satisfied. The configurator may only show a few of the parameters
to the user, but should always ensure that if a value can be selected by the user, it will
be possible to set values for all remaining parameters satisfying all the rules.
Configurators may look quite different, depending on technology and platform. Figure 1 shows
a few examples of configurator applications developed for some of Configit’s customers.
 Figure 1: Examples of configurator applications

3. The Product Model

A product model is a logical representation of the product variants and it forms the foundation
for building a configurator solutions. A product model consists of a set of variables (also called
parameters, characteristics, features or feature families), a set of possible values for the
variables (also called features or options), and rules describing dependencies among the
values.
Formally, the configuration problem C is a triple (X,D,F) where

─ X is a set of variables x1, x2, … ,xn

─ D is the Cartesian product of their finite domains D = D1 ´ D2 ´ … ´ Dn

─ F = {f1,f2,…,fm} is a set of propositional formulas (rules) over atomic propositions xi = v,

where v Î Di, specifying the conditions that the variable assignments must satisfy. Each
formula is inductively defined by

f º xi = v | f Ù g | f Ú g | ¬f

representing a Boolean expression over the variables in the model.

A configuration is a set values assigned to the variables. If all variables are assigned a value,
the configuration is complete, otherwise it is a partial configuration. A valid configuration
satisfies all rules in F. A partial configuration is only considered valid if it can be extended into
a valid and complete configuration.
The purpose of an interactive configurator is to:

1. Ensure that the user ends with a valid configuration and

2. Guide the user towards the goal.

The configuration problem is inherently computationally difficult. The problem of simply
determining whether there exists any valid configuration (which clearly is easier than guiding
the user towards a valid configuration) belongs to a complexity class called NP-complete
problems. This means that no algorithm exists with a guaranteed good performance: the worst-
case performance is exponential in the size of the problem, i.e., in the number of variables.
Thus, the best we can hope for are techniques that work well most of the time. The VT-based
approach solves this inherently difficult problems once during the compilation process,
whereas traditional techniques have to solve the difficult problem for each configuration
request.

4. Three Generations of Solving the Configuration Problem

In the 1970’s and 80’s, the configuration problem was solved using (production) rule-based
systems, originally developed for AI and expert systems. Such 1st generation solutions can
only guide the user in very simple cases where all rules are written as ”if condition then
conclusion” and the conclusion is a conjunction of simple propositions. The SAP Variant
Configurator (LO-VC) and SAP Internet Pricing Configurator (IPC) are examples of 1st
generation configuration solvers.
In the 80’s and 90’s, the configuration problem is solved based on constraint solving engines.
These engines can handle the full set of rules as described above, but are complex and difficult
to get to perform well. Each time the user makes a selection, the constraint solver provides
guidance by initiating a rules search and use the search results to update the information the
configurator provides to the user. Although constraint solvers have many useful applications,
there are problems with this approach: performance of the search approach is unpredictable,
and the formulation of rules has a direct influence on the performance of the searches.
Therefore, in order to obtain reasonable performance, an expert must re-engineer the rules
until acceptable performance has been obtained. This results in maintenance errors due to the
model conforming to suit the search software rather than the intended and intuitive product
structure. That is, the model does not reflect how the persons having product knowledge and
responsibility view the product. As a consequence, there is a high risk of errors being
introduced in re-engineering and that maintenance of the model is expensive. Even after re-
engineering, it is impossible to guarantee good performance in all circumstances. This is often
tackled by setting a timeout of, for instance, 1 second, and then terminating the search after
the timeout without having found the exact answer and instead using an approximate answer.
Around year 2000, Configit started to develop the compilation-based approach where the rules
are compiled into a representation of all valid configurations. This approach is called Virtual
Tabulation® (VT) and is a development of Binary Decision Diagrams for configuration
problems. The set of all valid configurations is typically very large. It is not uncommon that
there are 10100 valid configurations for a given product model. This is a very big number (hence
the term “virtual” since actually listing all valid configuration is completely infeasible), yet the
VT-representation is typically very good at representing such large configuration spaces
compactly. In a real-world example, a product model with 1800 rules and 8000 variables that
defines 1050 valid configuration is represented in a 3 MB VT-file.
When using the virtual tabulation technology, there are no guarantees that it is possible to
construct the virtual table, due to the underlying problem being NP-complete. But if it is possible
to construct it, we can provide response-time and memory consumption guarantees (both are
linear in the size of the VT-file). The introduction of a compile step before the configuration
step is a significant improvement because it allows the hard NP-complete configuration
problem to be solved in the compilation step and eliminating the need to solve the NP-complete
problem at runtime. This is illustrated in Figure 2. Performance improvements are several
orders of magnitude. For additional reading on the performance of Virtual Tabulation, see the
article “Comparing Two Implementations of a Complete and Backtrack-Free Interactive
Configurator.” Configit has developed, owns and has patented the compact, in-memory, VT-
based configuration engine.

Figure 2: Comparing the traditional approach (Constraint Solvers) with the compiled approach (Virtual Tabulation)

5. A Simple Example
We will illustrate the compilation based approach using an example: configuring a T-shirt. In
this academic example, there are three variables: Color, Size and Print. There are four
colors (black, white, red, and blue), three sizes (small, medium and large) and two
prints (“Men-in-Black” MIB, and “Save-the-Whales” STW). There are only two rules:

• If the print is MIB, the t-shirt must be black (as a MIB t-shirt must be black)
• If the print is STW, the size cannot be small (as the large print otherwise won’t fit)
The product model is shown in Figure 3.
 x1 Î { black, white, red, blue } : Color
x2 Î { small, medium, large } : Size
x3 Î { MIB, STW } : Print

f1 º (x3 = MIB) Þ (x1 = black)

f2 º (x3 = STW) Þ (x2 ¹ small)
Figure 3: Product model of T-shirt

Assume the customer selects small for the size. The second rule then states that the print
cannot be STW and since there are only two values for the print, the print must be MIB and
thus, from the first rule, color must be black. So the expected behavior of the configurator is
to select MIB and black once the customer has selected the small size. This scenario
illustrates how the rules work “backwards” – rules are declarative, not procedural as software
code is; that is, they state a relationship which must be satisfied, not how to achieve this.
Consider another example: The customer selects a white t-shirt. From the first rule, the print
cannot be MIB and thus must be STW. The second rule then eliminates the small size. In this
scenario the customer will still have to choose among the remaining sizes (medium or large).
The truth-table for the t-shirt model contains 24 rows (4*3*2). Figure 4 shows the valid t-shirt
configurations, i.e., those of the 24 rows that satisfy the two rules. For example, the first row
(black, small, STW) is invalid as it violates the second rule f2.

Figure 4: Truth-table showing the valid configurations for the product model in Figure 3.

It is simple to make a configurator given the truth-table:

1. Determine the valid values by: for each column in the truth table, iterate through all
rows that have not been crossed out and collect the possible values.
2. Let the user select a valid value and cross out any rows with a different value
3. Repeat step 1 and 2 until there is just one row left.
From Figure 4, we can see that initially all colors, sizes and prints are available. As in the
second scenario, assume the customer selects a white t-shirt. We remove all rows with other
colors, leaving just two rows left, see Figure 5. From these, we can see that only the print STW
is available, but there is a choice of selecting size to either medium or large.
 Figure 5: Selecting the color "white" reduces the selectable rows to just the two indicated.

The challenge with this approach is that the size of the truth-table becomes extremely large
for real models which typically contains hundreds of variables. For example, a model with 100
variables, each with just two values, have 2100 = 1,267,650,600,228,229,401,496,703,205,376
rows in the truth table!
A Virtual Table is a compact representation of the truth-table. It is constructed by building a
representation of the solution space of each rule and then combining the rules to form the
combined result. Figure 6 shows a VT representation of the set of valid configurations to the t-
shirt model. Each variable in the model is represented by one or two Boolean variables (2
variables for color and size, 1 for print). Every path from the root to the 1-terminal is a valid
configuration and the paths to the 0-terminal represent invalid configurations, corresponding
to the rows that had been crossed out in Figure 4. The dashed arrows are traversed when the
variable is false, the full arrows are traversed when the variable is true.

Figure 6: Virtual Table representation of the solution space for the T-shirt

6. Compilation Statistics
The compilation step solves the difficult part of the configuration problem by computing the VT-
representation of the set of all valid configurations. This step may use significant computer
resources in terms of CPU-time and memory. However, real-life models have a lot of structure
which the compiler uses to quickly compute the VT-file. Table 1 shows statistics for some
models from our customers, ranging from a few hundred variables to a few thousand (these
are typical sizes of product models). The table shows that the VT-file typically is calculated in
a few seconds and the VT-file size is in the order of a few megabytes.
Table 1: Compilation times and size of VT-files for typical models. The VT-files are compiled on a PC with an Intel
Core 2 Quad CPU (Q9950@2.83GHz) with 8 GB memory and running Windows 7 x64.

Model Name Num Num Size of VT Compilation

Vars Rules file (kB) time (sec)
ELION 299 190 477 4.9
cooling_2 302 81 96,420 20.9
Dooria_Almeria_999+mst-cstob 310 18 5,735 8.7
Smaarulle 455 98 1,679 9.4
ADC_FIBER_PATCHCORDS_FIBER_PATCHCORD 471 76 1,170 5.6
_PROFILE
EVOS 510 1,152 5,664 6.1
3940000000_KONFIGURATIONSPROFIL_394 514 297 1,668 22.9
MECR_MECR_NEMA 564 320 1,513 12.8
DHI-Software-2007 1,447 1,517 2,545 9.2
DHI-Software-2008 1,741 1,833 3,083 5.9
VMP5000_2_2.06 1,893 1,380 2,359 5.6
ADC_FDF_FRAMES_FDF_FRAMES_PROFILE 2,147 1,527 3,295 6.2
IntegrationTurbine 15,734 15,458 28,857 23.8

7. Advantages of the Compilation-Based Approach

There are five key advantages to the 3rd generation compilation-based approach when
compared to traditional technologies for solving the configuration problem:
1. Authoring of Master Data: the compilation-based approach is quite insensitive to the
form and shape of the data in the product model. This allows the modeler to write the
rules in the most natural and understandable way, without having to take into account
what form the rules should have to make the configuration engine perform. Often,
master data comes from several data sources (Excel sheets, databases, etc.) and is
combined into a single product model. We have examples of models that are
transformed from an ERP system, generating rules consisting of 20,000+ lines of code,
yet the compilation to the VT-file (and subsequent solve performance) is efficient. Other
technologies such as constraint solvers struggle to handle auto-generated rules as the
rules cannot be optimized to the configuration engine.

2. Quality Assurance of Rules: Since the VT-file represents every valid configuration,
it is possible to perform detailed analyses at modeling time. Similar to what is known
from software development, it is possible to express tests that are checked each time
the product model is modified. Such a test can express that when certain variables
have given values, other variables must be set to or cannot take certain values. Unlike
normal software-test where the input-combinations are non-exhaustive, it is possible to
prove that the test holds for every valid configuration. Such tests can be very useful to
ensure that the BOM is correct, i.e., that for every valid configuration, the BOM is not
missing any parts and there are not too many parts (e.g., two engines selected for a
given configuration)
3. User Experience: Configurators based on VT-files are complete and backtrack-free.
This means that when the user gets to select a value, he is guaranteed that there is a
valid configuration containing this value. And vice-versa, if the configurator disallows a
value, it is because there is no way to complete the configuration to a valid configuration
with the disallowed value in combination with the previously selected values. In other
words, the user is guided towards a valid configuration and will not get into trial-and-
error scenarios.

Performance, i.e., the response-time from the configurator, is another important

element to obtain a good user experience. By using the VT-file based approach, the
response-time is predictable since it is guaranteed to be linear in the size of the VT-file.
VT-files have very good response-times, typically in the 5-20 ms range which means
that a single server can provide acceptable response-times for hundreds of concurrent
users.

The user is not bound to select values in a pre-defined sequence. Interacting with the
configurator, the user can start by selecting the values which are of highest relevance
in the current configuration scenario.

The technology supports automatic conflict resolution. Should a user want to choose a
value which is in conflict with a set of previously chosen values, the configurator will
automatically resolve any conflicts. This is done by providing an interactive conflict
resolution, allowing the user to select which values to keep, ensuring that the
configuration is always valid.

4. Multi-Channel: A single VT-file may contain rules ranging from highly internal technical
or engineering rules (e.g., specifying the emission standards, frequencies etc. based
on market) to marketing rules about what values are available in what markets, to rules
that map high-level customer requirements to more technical variables. A VT-file may
have hundreds of variables, some of which are very technical and others very
customer-related, but due to the complete knowledge of the solution space, the
configurator can expose only a subset of the variables. This makes it possible to
develop specialized configuration applications for specific channels (web-sites, order
entry, manufacturing) based on a single VT-file. There may be one configurator
application for mobile devices (e.g., iPad), another configurator with more variables on
the web-site and a third configurator application for the order entry process with even
more choices. But even when the customer uses the mobile configurator and makes
just a few choices, since the VT-file has the full set of valid configurations, it can be
guaranteed that it is always possible to make choices for the remaining variables. This
is a very strong property which ensures that all configuration logic can be combined in
one system (“single source of truth”) instead of being spread around in a production
configurator, a sales configurator and in specialized mobile applications, causing mis-
alignment of data and difficulties keeping the configurators up-to-date.

5. Cross-Platform: The configurator runtime component is quite small and simple. The
Configit runtime component is available in .NET and JavaScript, thus ensuring a
ubiquitous use of configuration knowledge. The JavaScript version makes it possible
to run the configuration logic in a browser, making it possible to make the configurator
run on mobile devices and offline.