A requirement we heard very often from our industrial partners was to count the number of constructible vehicles of a certain product type, i.e. computing the model
count of the respective PDF. This gets especially interesting if combined with arbitrary selection criteria. E.g. one can compute how many different cars of a certain product type and a given color can be built for the US market. This information can be combined with certain statistics and pick rates and yield important management insight into the whole product variety.
However, one can not only count all satisfying assignments of the PDF—this number would be far too large and not the number which the management is interested in. The problem is that many options in a vehicle are not really customer-selectable but are used to control the production process or to control other aspects of the vehicle. E.g. there are special options for vehicles used in movie productions or vehicles for display at a car dealer. The number which is of real interest however is the number of vehicles a customer can actually order.
Speaking in terms of Section 3.2 the interesting question is how many valid ve- hicles are there for a product type t restricted to the customer-selectable options OC. So we do not only want to compute the model count #sat(PDF(t)) but the model count of the PDF where the options from OM= {o1, . . . ,on}are eliminated: |{β | β |=∃o1. . .∃onPDF(t)}|.
In Section 2.4 we have seen two different approaches to model counting: (1) the DPLL like model counting, and (2) the knowledge compilation based model counting. Also in Section 2.6 we have seen six different approaches to existential quantifier elimination. In order to compute the projected model count we have to combine these two techniques. First we have to compute the projected product description formula before we can count its models. Figure 5.1 illustrates the situation.
PDF(t) eliminate 9o1. . .9on compute #sat
PDF(t) projected to
relevant options projectedmodel count
Figure 5.1 |Computing the projected model count
5.1.1 Counting Models in the Automotive Scenario
If we take the approach described above, we have to assure that the output format of the quantifier elimination and the input format of the model counting approach are compatible. DPLL-style model counting (cf. Section 2.4.1) requires the input formula in CNF. Knowledge compilation based model counting (cf. Section 2.4.2) with BDDs can handle arbitrary input formulas. Since all available tools for d-DNNF compilation can only handle CNF, we have to restrict input formulas for DNNF-based model counting to CNF. Our own experiments with compiling automotive formulas to DNNFs [Hildebrandt, 2012] were far better than BDDs [Matthes et al., 2012], therefore we use d-DNNFs for the knowledge compilation based approach. Thus we can restrict the format of the model counting input to CNF. Of course each formula ϕ
5.1 Computing the Number of Constructible Vehicles
can be transformed to a CNF ϕ0, however, one has to take care that the transformation method preserves the model count of the formula, i.e. |{β | β |= ϕ}| = |{β | β |= ϕ0}|. This is only the case for the Tseitin transformation (cf. Section 2.1.2).
In [Kübler, 2009] the DPLL-style model counters RelSAT, sharpSAT, and Cachet were compared with the d-DNNF-based approach with c2d on product configuration formulas of Daimler. The outcome was that all DPLL-style implementations have large problems with the stability and correctness of the results. The model counts of c2d and RelSAT were the same. However, since RelSAT does not use component caching, it could only handle very small formulas. The counts of sharpSAT and Cachetoften differed from the ones of RelSAT and c2d and from each other. Verifying the results of model counts on large formulas is often not possible, but the fact that RelSATand c2d yielded the same results is a strong argument in favor of these two tools. Summarizing, only the d-DNNF-based approach with c2d was stable enough to be used for industrial-size formulas. In Section 7.2.2 we will look at some results from the BMW case study.
5.1.2 Projecting Formulas in the Automotive Scenario
In Section 2.6.1 six different approaches for existential quantifier elimination for QPL formulas were summarized. Looking at Table 2.2 obviously (MEPI), (CD), and (DDS) are possible choices for the projection step since their output format is already CNF which is required for the model counting step. Of course also (MEP), (SUSI), and (DNNF) could be used if the result is transformed to CNF with Tseitin. However, the resulting formulas often contain thousands of newly introduced variables which make the d-DNNF compilation very hard and often not possible. In the BMW case study it turned out that the (MEPI) approach is not suited at all for our industrial-size formulas, leaving only the clause distribution and the dependency sequences based approaches as viable alternatives. With both approaches we could project large formulas to their relevant options. A further insight in the results and benchmarks is presented in Section 7.3.2.
PDF(t)
PDF(t) projected to
relevant options projectedmodel count Quantifier Elimination
with (CD) or (DDS) d-DNNFCompilation
Figure 5.2 |Computing the projected model count (refined solution)
Figure 5.2 shows a refined version of Figure 5.1 with the solution which proved to be most stable and efficient. This section is concluded with an example.
Example 5.1 Consider the following HLC for a product type t. We have two families:
1. G = {oG
1,oG2,oG3}for GPS systems, and 2. E = {oE
4,oE5}for entertainment systems and three options without a family:
1. o6for support for Chinese characters in the headunits, 2. o7for special Japan support, and
3. o8for speech assistance in the vehicle.
o6and o7are not customer-selectable. Therefore we have: OC(t) = {oG1,oG2,oG3,oE4, oE
5,o8}and OM(t) = {o6,o7}. R(t) = {r1,r2,r3,r4,r5,r6,r7}contains seven rules: 1. r1= oG1 −→ oE4 2. r2= oE4 −→ ¬oG2 3. r3= oE5 −→ ¬oG3 4. r4= ¬(o6←→ o7) 5. r5= o8−→ (oG1 ∧ oE4) 6. r6= oG1 ∨ oG2 ∨ oG3 7. r7= oE4 ∨ oE5
The model count for PDF(t) is eight: 1. {oG 1,oE4,o6, ¬o7, ¬o8}, 2. {oG 1,oE4,o6, ¬o7,o8}, 3. {oG 1,oE4, ¬o6,o7, ¬o8}, 4. {oG 1,oE4, ¬o6,o7,o8}, 5. {oG 2,oE5,o6, ¬o7, ¬o8}, 6. {oG 2,oE5, ¬o6,o7, ¬o8}, 7. {oG
3,oE4,o6, ¬o7, ¬o8}, and 8. {oG
3,oE4, ¬o6,o7, ¬o8}.
The formula ∃o6∃o7PDFhas a model count of four: 1. {oG 1,oE4,o8}, 2. {oG 1,oE4, ¬o8}, 3. {oG 2,oE5, ¬o8}, and 4. {oG 3,oE4, ¬o8}.