As mentioned in Section 4.3.2 some car manufacturers must introduce virtual nodes and completeness constraints in order to enable the fully automated qualitative analysis of their BOM. Considering that a BOM can have tens of thousands of material nodes, this can be a tedious process. Generation of virtual nodes can sometimes be automated because usually there is additional information for the material nodes like material family, material category, etc. But the generation of completeness constraints is not as easy. This section presents an algorithm which was developed by this thesis’ author for generating completeness constraints for the BOM of BMW.
The usual process is that a documentation expert defines a new virtual node which is intended to be consistent, i.e. she chooses a set of material nodes which should occur exactly once in any valid vehicle. This set is then the input to the algorithm that generates a proposal for a completeness constraint. We look at the flow of the algorithm with the help of an example of a virtual node for different variants of a switch for the radio system. The involved customer options are given in the following table.
4.3 Analyzing the BOM Option Description r1 Radio System 1 r2 Radio System 2 r3 Radio System 3 b Board Computer
We also assume that there are two type determining options involved: the steering side of the vehicle which can be left-hand (LH) or right-hand (RH), and the continent- version of the car which can be USA (US), or Europe (EU).
The expert chose the following material nodes to be together in a virtual node:
Number Description Usage Constraint
n1 Switch 1 (EU1) ¬b ∧ r1∧EU ∧ LH
n2 Switch 2 (EU2) ¬b ∧(r2∨ r3) ∧EU ∧ LH
n3 Switch 3 (EU3) ¬b ∧(r1∨ r2∨ r3) ∧EU ∧ RH
n4 Switch 4 (US1) ¬b ∧ r1∧US
n5 Switch 5 (US2) ¬b ∧(r2∨ r3) ∧US
Looking at the usage constraints, in this easy example it is obvious when one of these radio switches should be in the vehicle:
1. There has to be no board computer: ¬b 2. There has to be a radio: r1∨ r2∨ r3
If there is a board computer chosen by the customer or if she did not choose a radio system, we do not expect a switch of this virtual node. So an expert might come up with a completeness constraint ¬b ∧ (r1∨ r2 ∨ r3). The question is whether an algorithm can generate such a completeness constraint automatically. The naïve approach is just to use the disjunction of all involved usage constraints as completeness constraint. Obviously we only expect a switch if one of the switches is really selected by an order. So we could just use
(¬b ∧ r1∧EU ∧ LH) ∨ (¬b ∧ (r2∨ r3) ∧EU ∧ LH) ∨ (¬b ∧ (r1∨ r2∨ r3) ∧ EU ∧ RH) ∨ (¬b ∧ r1∧US) ∨ (¬b ∧ (r2∨ r3) ∧US) as usage constraint. Even if we simplify this completeness constraint, it is not very useful as it does not describe the real technical constraint. E.g. there are TDOs like US, EU, RH, or LH in it, but they do not really play a role in the completeness constraint. So the algorithm must in some way abstract of the details and try to get at the technical core of the virtual node.
The algorithm which was implemented at BMW works in two steps: 1. Computation of necessary literals
We illustrate both steps on the example. First, necessary literals are computed. This means we search for literals with positive or negative phase which must be satisfied for every single usage constraint in order that a material node is selected. In our example we find the literal ¬b which must hold, otherwise no switch is selected. The necessary literals are then propagated through the usage constraints in order to eliminate them. After this step we have a completeness constraint ¬b and the following usage constraints (where ¬b was propagated).
Number Description Usage Constraint
n1 Switch 1 (EU1) r1∧EU ∧ LH
n2 Switch 2 (EU2) (r2∨ r3) ∧EU ∧ LH
n3 Switch 3 (EU3) (r1∨ r2∨ r3) ∧EU ∧ RH
n4 Switch 4 (US1) r1∧US
n5 Switch 5 (US2) (r2∨ r3) ∧US
In the next step we eliminate the TDOs. The observation is that the values of TDOs often do not influence whether a part of a node is selected but only influence which part is selected. Our example is an illustration of such a case. We take the disjunction of all usage constraints
ϕ=(r1∧EU ∧ LH) ∨ ((r2∨ r3) ∧EU ∧ LH) ∨ ((r1∨ r2∨ r3) ∧EU ∧ RH) ∨ (r1∧US) ∨ ((r2∨ r3) ∧US)
and eliminate the variables EU, US, LH, and RH. Formally speaking we construct the existential QPL formula
ϕ0=∃EU ∃US ∃LH ∃RH [ϕ]
and compute the quantifier free equivalent with one of the approaches presented in Section 2.6.1. Since usually we do not have to eliminate more then 20 or 30 variables in this step, the substitute & simplify (SUSI) approach is a good choice in practice. It is the only approach which does not convert the input or the result into any normal form and therefore the resemblance to the original input formulas is higher than with the other approaches. Since the completeness constraint proposal of the algorithm has to be verified by a documentation expert, this is a very important point. If we compute qe_susi(ϕ0)in our case, the result is (r1∨ r2∨ r3). Thus, together with the result of Step 1, the algorithm computed the completeness constraint ¬b ∧ (r1∨ r2∨ r3) which is exactly the constraint which we found by hand earlier.
Of course the algorithm does not always work as perfectly as in this situation. Espe- cially when there are very big virtual nodes with over 50 involved options and tens of TDOs the proposals tend to become very big and cease to be helpful anymore. But according to experts from BMW, the approach yields good proposals in many cases and it was implemented in the production system.
Algorithm 4.13 summarizes the algorithm sketched above. Step 1 is performed in Lines 1–16. The unit literals are determined with the help of a SAT solver. The units are then propagated through the disjunction of usage constraints (Line 17). The