EP2869257A1 - Configuration de produit - Google Patents

Configuration de produit Download PDF

Info

Publication number
EP2869257A1
EP2869257A1 EP20130005167 EP13005167A EP2869257A1 EP 2869257 A1 EP2869257 A1 EP 2869257A1 EP 20130005167 EP20130005167 EP 20130005167 EP 13005167 A EP13005167 A EP 13005167A EP 2869257 A1 EP2869257 A1 EP 2869257A1
Authority
EP
European Patent Office
Prior art keywords
variables
product model
values
scope
rules
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP20130005167
Other languages
German (de)
English (en)
Inventor
Sathia Moorthy Subbarayan
Henrik Reif Andersen
Henrik Hulgaard
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Configit AS
Original Assignee
Configit AS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Configit AS filed Critical Configit AS
Priority to EP20130005167 priority Critical patent/EP2869257A1/fr
Publication of EP2869257A1 publication Critical patent/EP2869257A1/fr
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]
    • G06Q30/0621Item configuration or customization
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/08Logistics, e.g. warehousing, loading or distribution; Inventory or stock management

Definitions

  • the present invention generally relates to the task of solving complex product configuration problems. More specifically, it is directed to providing efficient answers to queries regarding the configuration of complex products.
  • Customizable products e.g. cars
  • Customizable products generally exhibit various variables (e.g. Country a car is to be sold in, Steering Wheel indicates whether the steering wheel is to be mounted on the lefthand or the right-hand side, Fuel Type of a car, etc.), for each of which a user has to select a particular value out of a set of values (e.g. Diesel, Petrol for the variable Fuel Type ) in order to configure the product.
  • a set of values e.g. Diesel, Petrol for the variable Fuel Type
  • Product configuration is the task of finding a valid configuration for a configurable product, i.e. finding a combination among the values and variables of the product for which all rules between these variables and values are fulfilled.
  • a computer-implemented method of configuring a product based on an initial product model comprises variables, wherein each variable is associated with a set of values, and wherein at least one of the variables is defined as a scope variable, and rules representing inter-dependencies among the variables and values.
  • the variables and rules define a product configuration problem to be solved.
  • the method comprises
  • a computer system for configuring a product based on a initial product model as described above is provided.
  • a non-transitory computer readable storage medium having computer program instructions stored therein, which, when executed on a computer system, perform the method as described above, is provided.
  • the present invention generally relates to computer implemented methods of configuring a product based on a product model.
  • product is to be understood broadly to cover any product article or goods as well as processes (e.g. manufacturing processes, business processes) which occur in more than one setup or configuration.
  • process models may not only be used to represent configuration problems of tangible goods, but more generally to represent any kind of configuration problem such as process configuration problems.
  • configurable products are characterized by various variables (by the skilled person also referred to as parameters, feature families, or option groups), representing the various dimensions of the product to be configured.
  • Each variable has an associated set of values (by the skilled person also referred to as domains, types, features, or options).
  • a particular value has to be selected out of the respective set of values in order to obtain a complete product configuration.
  • a product model including its variables, value sets and rules is established in a structure form processible by a computer.
  • a computer-based configuration of a product on the basis of a product model is generally performed by iteratively selecting values for the various variables and, e.g. after the value of one or several variables has been fixed, the computer checking the current configuration for consistency by applying the rules.
  • the product model represents an entirety of variables, with associated sets of values, and rules which defines a product configuration problem.
  • at least one variable of the product model is defined as "scope variable" (as will be described in detail below).
  • the product model can further contain sub-structures, in which e.g. various variables or rules are grouped together. Additionally, several more features, like e.g. default values for some of the variables or mathematical functions depending on some variables might be provided in the product model.
  • An example of a consumer product that might be subject to product configuration is a t-shirt.
  • the variables (associated set of values) of the t-shirt product model are its color (black, white, red, blue), its size (small, medium, large), and a particular print ("Men in black"-MIB, "Save the Whales "-STW) on the front of the t-shirt.
  • Men in black "Men in black”-MIB, "Save the Whales "-STW)
  • the process of product configuration i.e. the task of finding a combination among the values of all the variables included in the product model for which all rules of the product model are fulfilled, is important in many areas, as e.g. automotive, aerospace, high-tech, industrial machinery, industrial components, consumer products, medical equipment, mill products, chemicals, building and construction, software, energy, insurance, utilities, telecommunication, life sciences, or media, and fields of operations, as e.g. during the development and manufacturing of a product, for price calculations of a product, for canvassing, or customer relationship management.
  • a method of product configuration i.e. the task of finding a combination among the values of all the variables included in the product model for which all rules of the product model are fulfilled.
  • a typical car consists of several thousand parts, which are the potential variables of the car product model. For many of these parts, various different choices exist, which form the sets of values associated with the variables. Out of these choices car developers or manufacturers pick one for each part in order to develop/assembly the car. However, not all choices are compatible, e.g. if choices from different suppliers are used, they might not fit together. Additionally, there might be restraints regarding the costs of the car.
  • the variables, associated values, and rules of the car product model define a car model representing the solution space of a car development or car assembly configuration problem. For a typical car development or car assembly configuration problem the complete car model represents more than 1 x 10 20 valid combinations.
  • product configuration is used in various respects. For example, it is used during the actual manufacturing of a car in order to ensure that the car is assembled according to a valid configuration and to supply an assembly line with the correct parts.
  • an assembly line utilized for car manufacturing is usually arranged to execute the manufacturing process within pre-determined time intervals, also the car configuration employed within the assembly process is subject to time constraints.
  • a product configuration utilized within an automated or semi-automated manufacturing process is required to meet given response or calculation times.
  • product configuration is also used for offering products to potential customers.
  • Well-known examples are the websites of car manufacturers which enable potential customers to configure a car according to their desires.
  • the product configuration mechanisms used for such online configurations offered to end customers also have to respond within reasonable time intervals because long waiting times are not acceptable.
  • the method of product configuration presented herein is particularly directed to handle complex configuration problems in a more efficient manner in terms of computing resources and response times in comparison to the approaches known in the prior art.
  • the general idea of the invention is to perform the iterative configuration as described above on a reduced and therefore - compared with the product model of the product to be configured - simpler product model (for reasons of clarity, the complete product model prior to reduction is referred to as "initial product model” hereinafter).
  • Such a reduced simplified product model is obtained by pre-defining a specific set of variables within the product model, herein referred to as "scope variables".
  • scope variables are determined first resulting in a remaining, simplified product model, and the iterative further configuration is only performed subsequently, thereby effectively dividing the process of product configuration into two stages.
  • the values for scope variables are selected by the user by using a computer implementing the configuration process.
  • the scope variables are pre-defined e.g. by a configuration expert (not the user of the product configuration) as a specific subset of variables of a product model. Hence, this subset of scope variables is defined in the product model, i.e. the designation of certain variables of the product model as scope variables forms an integral part of the product model.
  • the computer implementing the configuration indicates the scope variables and associated values for selecting by the user.
  • the selection of values for the scope variables during the first stage of the configuration process is, in some embodiments, an iterative process by itself.
  • the values for the scope variables are selected one after another and consistency, i.e. the rules relating to the scope variables, is checked by the computer. The iteration ends once values for all scope variables are selected and one or several consistent and valid scope variables are returned by the computer.
  • the values of all scope variables are selected in a single activity, i.e. without any consistency checks in between. In this case, a consistency check is applied by the computer after all scope variable values have been chosen. If it turns out that an inconsistent, invalid set of scope variable values has been selected (i.e. the rules relating to the scope variables are not fulfilled), the selection of scope variable values is repeated.
  • scope variables are selected first, before the values of all other variables not being scope variables are selected.
  • non-scope variables are iteratively selected only during the second stage of the configuration process.
  • the scope variables are generally pre-determined and defined in the initial product model by taking into account their potential or effect of restriction and simplification of the complete product model. Variables leading to a substantial restriction of the initial product model are referred to as high-impact variables.
  • high-impact variables defining high-impact variables to be scope variables implies that the selection of a value for such a scope variable results in a more significant simplification of the product model as compared to defining low-impact variables as scope variables.
  • scope variables could be variables that define a particular market or market region of a product, a particular point in time associated to a product, or a general product type.
  • the number of scope variables is to be determined in the course of defining the initial product model. While at least one scope variable is required for the simplification of the product model, the number of scope variables should not be too high, either. In the case too many scope variables exist the simplification of the product model based on the scope variables itself becomes challenging in terms of required computation resources, which results in long response times for the computer calculating the transition to the simplified product model. Consequently, the number of scope variables is a trade-off between the achievable simplification of the product model and reasonable response times for the transition from the initial to the simplified product model and more efficient iterative further configuration in the second stage of the configuration process on the basis of the simplified product model.
  • the number of scope variables has to be reasonable and depends on the particular product model. For a rather complex product model such as a car product model, a reasonable number of scope variables is e.g. in the range of two to five.
  • the selected values of the scope variables are used by the computer to restrict the complete product model, which includes all variables, sets of values and rules of the product configuration problem, to a simplified product model.
  • the simplified product model the selected values for the scope variables are reflected. Consequently, the simplified product model generally includes fewer variables and/or associated subsets of values as the initial product model since the scope variables are not included as variables in the simplified product model anymore (the scope variables with selected values can still be included in the simplified product model though, however, not as a selectable variable).
  • scope setting based on the selection and setting of values of the scope variables (hereinafter referred to as "scope setting") the rules of the simplified product model are restricted, compared to the rules of the initial product model.
  • the variables, associated sets of values, and rules of the simplified product model effectively define a simplified product configuration problem.
  • the simplified product model might still include default values for variables, mathematical functions or other features, as defined in the complete product model.
  • each individual rule of the initial product model may be checked regarding a possible influence of the scope setting on the rule.
  • the rule is revised in order to be consistent with the scope setting. Since the simplified product model includes fewer variables than the complete product model, it can be expected that the restricted rules are generally less complex than the original rules. As a result of the scope setting, some rules can even become redundant; these rules are deleted in the process of restricting the rules.
  • variable size of the above mentioned t-shirt configuration problem is defined as a scope variable.
  • the variable size is set to the value large.
  • the second rule If the small size is chosen, then the print STW cannot be chosen ) of the complete t-shirt product model becomes redundant. This rule is not included anymore in the simplified product model of the t-shirt configuration problem.
  • the restricted rules generally are of reduced complexity in terms of causing computational calculation effort compared to the rules of the complete product model.
  • complex rules which have been part of the initial product model can be processed in a more efficient manner in terms of computational resources in the remaining process of a product configuration.
  • configuration problems can be very complex and include a large number of variables and rules.
  • a plurality of these rules can be interlinked with each other, forming a complicated network of inter-dependencies.
  • some embodiments apply propagation/synchronization methods between the rules during their restriction.
  • An exemplary propagation method frequently used in this context is the so called unary constraint propagation, in which a constraint that is defined only over one variable (a so called "unary-constraint") is conjoined (logical AND) with any other rule depending on this this variable. After such an operation the unary-constraint becomes redundant and is removed.
  • the number of rules in the simplified product model may change with respect to the complete product model.
  • the number of rules can either decrease (the number of rules can also decrease during restriction of the rules without propagation/synchronization methods being employed, due to redundant rules) or also increase.
  • the simplified product model arising from the computer-implemented restriction based on the scope setting is generated in a structured, computer-readable and computer-processible form, as it serves as the basis for the second stage of the configuration, the computer-based iterative selection of variables not being scope variables (from here on referred to as "non-scope variables") and iterative computer-implemented further narrowing down the solution space of the configuration problem.
  • the values for the non-scope variables are selected and set, i.e. the values of the variables are fixed.
  • the selection of the non-scope variables is an iterative process. This means that the values for the non-scope variables are selected (either by a user or automatically) one after another and respectively set by the computer performing the configuration process. The iteration ends at the latest once values for all non-scope variables are selected, i.e. if the product configuration is completed.
  • the method of product configuration includes the conversion of the initial product models into an initial Boolean product model (which is one example of a computer-readable and computer-processible representation of the variables and associated values of the initial product model).
  • the result of this conversion is an initial Boolean product model including all variables, associated values, and rules of the initial product model, wherein all variables are Boolean, i.e. the values associated to the variable are the Boolean values true and false (or 1 and 0).
  • the rules of the product model are converted as well, into being Boolean rules over the Boolean variables.
  • a Rule Binary Decision Diagram is built for each Boolean rule included in the Boolean product model; a Binary Decision Diagram (BDD) is a rooted directed acyclic graph with two terminal nodes marked as 0 and 1, respectively.
  • An R-BDD is a logical description of a rule included in the initial product model based on the dependent variables of the respective rule.
  • the entirety of generated R-BDDs represents the rules of the initial product model.
  • the generation of R-BDDs based on a Boolean product model is described, for example, in the above mentioned US 7,584,079 B2 .
  • the R-BDDs are established in a computer-readable and computer-processible form in order to be processed by the computer implementing the configuration method.
  • the R-BDDs representing the rules of the initial product model may be restricted based on the selected values of the scope variables. This restriction results in restricted R-BDDs representing restricted versions of these rules.
  • These restricted R-BDDs are hereinafter referred to as Scope Restricted Rule Binary Decision Diagrams (SRR-BDDs).
  • SRR-BDDs Scope Restricted Rule Binary Decision Diagrams
  • the selected values for the scope variables which generally are presented to the user in a readable, non-Boolean form
  • the R-BDDs are restricted based on the scope values in Boolean form.
  • the above, more general, remarks on restricting the rules of the initial product model to obtain the rules of the simplified product model analogously apply to the restriction of the R-BDDs to the SRR-BDDs.
  • the R-BDDs are a representation of the rules of the initial product model, while the SRR-BDDs represent the restricted rules of the simplified product model.
  • the restriction may not merely restrict each individual R-BDD one-to-one to an SRR-BDD.
  • the optional use of propagation/synchronization methods between various rules further simplifies the rules and generally results in a change (decrease or increase) of the number of SRR-BDDs as compared to the number of R-BDDs.
  • a particular (computer-readable and computer-processible) representation of the simplified product model obtained by the restriction achieved by selecting values for the scope variables is established, namely a Tree of BDDs (ToBDDs).
  • ToBDDs is a representation of the rules of the simplified product model; the valid solutions of the product configuration problem represented by the simplified product model are incorporated into the ToBDDs.
  • the generation of a ToBDDs is described in detail further below or, for example, in the above mentioned [ToBBDs2005]. If a ToBDDs is generated, the iterative selection of values for variables not being scope variables during the second stage of the configuration process is based on the ToBDDs.
  • a particular (computer-readable and computer-processible) representation hereinafter referred to as a Scope Binary Decision Diagram (S-BDD) is generated if at least two variables of an initial product model are defined as scope variables.
  • S-BDD is provided in order to support a user of the configuration method in iteratively selecting a combination among the values of the scope variables for which the complete product configuration problem has at least one valid solution.
  • the S-BDD is a representation of the valid solutions of the small configuration problem.
  • the S-BDD might be understood as a projection of the solution space of the complete product configuration problem onto the scope variables, i.e. the valid solutions of the "small" configuration problem represented by the S-BDD are compatible with all the rules included in the complete product model.
  • the S-BDD After the selection of a value of a first scope variable out of a plurality of scope variables during the scope setting the S-BDD is used to determine a subset of valid values out of a set of values associated to a second scope variable.
  • the subset of valid values determined for the second scope variable may be provided to the user before selecting a value for the respective scope variable.
  • the selection of values for the non-scope variables includes so-called partial configurations.
  • a partial configuration is a subset of some non-scope variables.
  • the values of the variables included in a partial configuration are selected before the values of the other non-scope variables not being part of the partial configuration are selected.
  • activities may be performed. These activities include a variety of queries performed by the computer implementing the configuration method, in which the simplified product model may be queried to:
  • This activity verifies, by consulting a representation of the simplified product model, if the selected values of the variables of the partial configuration are valid, i.e. if they fulfill all rules included in the simplified product model; in other words, the partial configuration is valid, if the solution space of the simplified product model includes at least one combination of values which has all values of the partial configuration in it.
  • the answer to this activity might be yes, in the case the partial configuration is valid, or no, in the case the partial configuration is not valid.
  • the complete product configuration includes the selected values of the scope variables, the selected values of the variables of the partial configuration, and additionally values of all non-scope variables which are not part of the partial configuration.
  • the values of the latter variables are selected automatically. On the basis of the solution space of the simplified product model it is thereby assured that the generated complete configuration is valid. If default values for some of the non-scope variables which are not part of the partial configuration are specified in the complete product model, these values (which are also part of the simplified product model) might be automatically selected for the variables, in the case they do not conflict with the already selected values of other variables.
  • the answer to this activity might be the generated complete product configuration.
  • information can be provided whether the value of a variable of the complete configuration was selected and set during the scope setting, during the partial configuration, or automatically during the automatic solution. It might also be indicated if a value selected during the automatic solution was specified as default value or not. If no valid complete configuration can be generated automatically on the basis of the selected values of scope variables and variables of the partial configuration, the answer to the query may be empty, an error message and/or may include information concerning the invalidity of the configuration.
  • This activity generates subsets of values for variables not being selected variables (a selected variable is a variable for which a value was already selected).
  • Non-selected variables are, in this context, generally non-scope variables and also not part of the partial configuration.
  • the subsets of values only include values for which at least one valid solution of the configuration problem exists.
  • the generated subsets of values may be updated after each selection of a value for a variable previously not being selected.
  • the answers to this activity might be the generated subsets of values associated to non-selected variables.
  • Such a subset may be provided together with those values of the respective non-selected variable leading to an invalid configuration. In this case it is indicated which values are part of the generated subset and which not.
  • This activity checks the current partial configuration for inconsistencies and, if such inconsistencies are found, provides respective reasons. If it is found that a partial configuration is inconsistent with the rules of the simplified product model, an explanation for the inconsistency of the partial configuration may be provided by this activity.
  • the explanation can include a list of values and/or variables, the values associated with the variables conflicting with the rules of the simplified product model.
  • the values and/or variables included in the list may correspond to a minimum set of values that needs to be changed in order to resolve the inconsistency of the partial configuration, i.e. to obtain a consistent, i.e. valid, partial configuration.
  • the answer to this activity might be the generated list of values and/or variables corresponding to those values of the partial configuration which need to be changed in order to obtain a valid partial configuration.
  • the answer to this activity might be the determined absolute number of valid complete configurations that are possible on the basis of the partial configuration.
  • This activity uses a mathematical function included in the simplified product model in order to calculate a result.
  • the mathematical function might depend on some scope variables and/or some variables of the partial configuration. The selected values for these variables are required in order to calculate the result.
  • These queries may be initiated by user supervising the configuration or may be performed automatically by the computer. In either case, the computer performs the queries, makes the necessary determinations and, optionally, returns the results back to the supervising user.
  • a rule included in an initial product model or in a simplified product model is split into a plurality of rules.
  • the resulting plurality of rules replaces the rule in the complete product model.
  • the rule included in the initial product model may generally depend on a plurality of variables of the complete product model.
  • the splitting of a rule into a plurality of rules, each of the plurality of rules depending on fewer variables than the rule, might help to further decrease the computational complexity of a product configuration problem.
  • the rule splitting potentially results in a reduced tree-width of the ToBDD representing the simplified product model. Since the computational methods of solving a product configuration problem based on a ToBDD are - in a worst case scenario - exponential in the tree-width, rule splitting may encompass handling more complex product models that cannot be handled using the methods known in the prior art within reasonable time constraints (assuming availability of similar computation resources).
  • a rule included in an initial product model is assigned with a time interval defining the validity of the rule.
  • the rule might only be effective, if the product configuration is defined to be valid only within this predefined time interval.
  • a plurality of different rules may define the relations between the same variables, the different rules being effective for disjoint time intervals and/or points of time.
  • Other rules may define a dependency of variable values on a date or time interval. For such time-related rules, a particular handling of the time-domain-related variables and their usually broad value ranges/sets is proposed, which is explained in more detail below.
  • default values for some of the variables are provided in the product model. If default values for scope variables are provided, these default values might be automatically assigned to the scope variables. However, a user of the configuration method can manually overwrite the default values and select other values for the scope variables during the scope setting.
  • the product model includes default values for one, a plurality or all variables not being scope variables. These default values are presented to the user while iteratively performing the further configuration during the second stage, i.e. the configuration based on the restricted, simplified product model which is e.g. represented by a ToBDDs as explained above. In each iteration, the user is free to accept the default value of a variable or to overwrite it with the desired different values. Furthermore, the default values for non-scope variables might be used while attempting an automatic solution in the case of a partial configuration (see above).
  • the mechanisms of product configuration as described above are at least partly performed on a configuration server.
  • the configuration server is accessible to end users e.g. via a wide area network (WAN) such as the Internet or a local area network (LAN), the end users being equipped with client devices such as personal computers (PCs), laptops or smartphones with respective client software.
  • WAN wide area network
  • LAN local area network
  • the end users being equipped with client devices such as personal computers (PCs), laptops or smartphones with respective client software.
  • client devices such as personal computers (PCs), laptops or smartphones with respective client software.
  • the selection of values for the scope variables as well as for the non-scope variables, and the restriction of the initial product model to the simplified product model might be performed on such an online accessible configuration server.
  • Online accessible configuration allows several people to participate in configuring a product, either subsequently or in parallel, effectively resulting in a collaborative configuration environment allowing distributed configuration.
  • client devices may be logged in to the configuration server at the same time for a particular configuration, one client device actively driving the configuration while the other client devices tracking/monitoring the configuration results. This might be desirable in the case of complex configuration problems, e.g. the above mentioned development of a car.
  • Figure 1 shows a flowchart of an embodiment of the method of configuring a product described above.
  • the starting point for applying the method of product configuration is a complete configuration problem 101.
  • Such a configuration problem could, for example, be the configuration of a car.
  • the complete configuration problem is defined by an initial product model 102. All variables of the configuration problem, for each of which a value has to be selected out of an associated set of values, are included in the product model. The inter-dependencies among variables and values of the initial product model are represented as rules, and also included in the initial product model 102. Several more features, e.g. default values for variables, mathematical functions depending on variables of the product model (such as functions implementing price (re-)calculations of the product), etc., are included in the initial product model 102 as well. Some variables of the product model are defined as scope variables 102a. An exemplary initial product is described more specifically with reference to Figures 2 to 14 .
  • Figure 2 illustrates an exemplary initial product model 102 of a car configuration problem.
  • Six variables for which a user of the configuration method may select values are included in the product model, namely:
  • scope variable 102a is defined as scope variable 102a in the initial car configuration product model 102, as it is discussed in more detail further below.
  • a seventh variable, named Date, is included in the initial product model 102 as well. This variable is used to specify a time when a generated car configuration is valid, for example, in order to determine the set of date-dependent rules which is to be applied to the variables. The value for this variable is selected either automatically (e.g. by taking the current time at which the configuration is being made) or manually by the user.
  • the car product model displayed by Figure 2 further includes four textual rules listed in the "Rules” section, named EmissionEuro, EmissionUS, GearBox, and US_Petrol.
  • Textual rules are rules defined by a text in any preferred programming language.
  • two relational rules are listed in the ""Relation” section of the product model, named CurrencyFuel, and FuelEngine. Relational rules are defined by a table of allowed combinations over some variables of the product model.
  • the car product model features a mathematical function named Price.
  • Figure 3 indicates the sets of values associated to each of the variables of the product model of Figure 2 :
  • Figure 4 depicts a screenshot of the textual rule EmissionEuro of the product model of Figure 2 .
  • the rule is valid for DK and UK. Based on the value of the variable Date of the configuration this rule specifies the appropriate EmissionStandard.
  • the format used to represent time is a datetime-string (YYYY-MM-DD HH:NN:SS), where YYYY refers to a year, MM to a month, DD to a day, HH to an hour, NN to a minute, and SS to a second.
  • Figure 5 shows a screenshot of the textual rule EmissionUS of the product model of Figure 2 .
  • This rule which is constructed in an analog manner to the EmissionEuro rule, represents the appropriate EmissionStandard for the US in dependence of the variable Date.
  • Both of the above mentioned emission rules of the product model ensure that a configured car corresponding to a valid car configuration always meets at least a minimum legal emission standard, e.g. the standard at the time of the car configuration or at a point of time in the past or in the future. If a user of the configuration method selects a value not corresponding to the valid rule for the variable EmissionStandard, the resulting car configuration will not be valid (as it does not fulfil said valid emission rule).
  • these datetime-strings occurring in a rule are handled in a specific way.
  • Time is divided into discrete time intervals based on the definition of datetime-strings in the rule, thereby splitting the time domain into relevant points of times and/or time intervals for a particular time-related variable referred to by a rule.
  • a rule might specify or utilize one or more points of time.
  • the EmissionEuro rule uses time-related " if " clauses on the value of the Date variable in order to determine the correct value of the EmissionStandard variable.
  • a list of time intervals is established for such a rule. For each point of time, e.g. in form of a datetime-string, referred to by the rule, a time-stamp (e.g. again in form of a datetime-string: YYYY-MM-DD HH:NN:SS) is added to the list of time intervals. If X different points of time occur in the rule, then X time-stamps are added to the list of time intervals.
  • time intervals defined by these time-stamps are added to the list.
  • the first time interval defined by the first point of time might be an open interval starting at minus infinity or a closed interval starting at an arbitrary point of time (not specified by the rule).
  • the last time interval defined by the last point of time might be an open interval ending at infinity or a closed interval ending at an arbitrary point of time (not specified by the rule).
  • X+1 time intervals are generated. Consequently, there are in total 2X+1 entries on the list of time intervals.
  • the generated entries in the list of time intervals are used as discrete values for the Date variable.
  • the points of time are merged with the previous or following time interval.
  • time interval " ]-inf;1992-06-30 23:59:59] " refers to the time period before 1 st of July 1992 (without specifying an arbitrary lower boundary, "]-inf” referring to minus infinity and thus specifying an open lower end), and the time interval " [2014-09-01 00:00:01; inf[ " refers to the time period starting from 1 st of September 2014 00:00:01.
  • the 21 entries in the list of time interval effectively decompose the time domain, e.g. for the variable Date of the car product model of Figure 2 , into relevant intervals/points.
  • This handling of time is, for example, useful for a compiler to re-encode the whole time domain (as a time-related variable may be assigned with a value indicating any arbitrary point of time) as a finite list of time intervals and points.
  • a time-related variable may be assigned with a value indicating any arbitrary point of time
  • the usually vast value set/range of a time-related variable can be decreased to certain relevant short list. This enables efficient pre-computation of solutions to the configuration problem.
  • it is also useful for constructing product models in the first place, prior to any configuration. A modeling person can inspect the relevant time intervals and points of time resulting from the rules analysis. Unexpected dates or intervals may point to potential inconsistencies or mistakes in rules.
  • Figure 7 displays a screenshot of the relational rule CurrencyFuel of the car configuration problem.
  • the allowed combinations of values of the variables Currency and Fuel are specified for each Country. According to this rule it is, for example, excluded to configure a car which is supposed to be sold in Denmark, paid in Euros, and to be fueled with Petrol (the reason for that might be that for a particular car manufacturer the market for Petrol-cars is too small, so that it has decided not to offer any Petrol-cars in Denmark).
  • Figure 8 depicts a screenshot of the textual rule GearBox.
  • the rule uses " if " clauses to define that the 2.0 TDI ( Engine ) and the 3.2 TDI ( Engine ) can only be used with a 6 Shift ( GearBox ) .
  • Figure 9 shows a screenshot of the textual rule US_Petrol.
  • the rule uses "if” clauses to define that the only valid Fuel in the US ( Country ) is Petrol.
  • Figure 10 illustrates a screenshot of the relational rule FuelEngine.
  • the rule indicates that the 2. 0 TDI ( Engine ) and the 3.2 TDI ( Engine ) can only be fueled with Diesel, while the 2.0 TFSI ( Engine ) can only be fueled with Petrol.
  • the initial product model 102 will generally first exist in a descriptive, potentially informally defined format that is neither readable nor processible by a computer. In order to serve as the basis of a computer-implemented configuration, it is transformed into a formal representation such as a initial Boolean product model 103.
  • a formal representation such as a initial Boolean product model 103.
  • all variables are Boolean, i.e. the values associated to the variables are the Boolean values true and false (or 1 and 0, or high or low).
  • the rules of the initial Boolean product model 103 are also Boolean, depending on the Boolean variables.
  • Figure 11 provides an overview of the Boolean encoding of the variables of the car product model of Figure 2 .
  • the variables of the car product model are encoded by 17 Boolean variables (numbered 0 to 16 ), in total.
  • the number of Boolean variables required to encode a particular variable of the product model depends on the amount of values associated to the variable.
  • the four Boolean variables used to encode the EmissionStandard rule are the variables 9, 10, 11, and 12 .
  • FIG 12 exemplary illustrates the generation of the R-BDD for the US_Petrol rule of the initial product model of Figure 2 .
  • the US_Petrol rule defines the dependency between two variables, Country and Fuel.
  • the Boolean encoding of the values of the respective variables is displayed in Figure 12 b) .
  • the Boolean variables 5 and 6 are used, while for the Boolean encoding of the Fuel variable with its two associated values Diesel and Petrol one Boolean variable, 13, is sufficient.
  • the R-BDDs 104 representing the rules of the initial product model 102 are subject to an optional Rule splitting 104a.
  • Rule splitting 104a In this process, complex rules defining dependencies between a plurality of variables are decomposed into sets of simpler rules possibly defining dependencies between only fewer variables than the original rules.
  • Rule splitting 104a generally reduces the computational complexity of the configuration problem in the subsequent parts (i.e. the second stage) of the configuration process, as a reduction of dependent variables in rules might reduce the tree-width of the ToBDDs 108.
  • relational rule CurrencyFuel depicted by Figure 7 is split into two simpler rules.
  • the rule splitting process including screenshots of the original CurrencyFuel rule and of the two simpler rules resulting from this split, is displayed in Figure 13 .
  • the original CurrencyFuel rule is more complex as it defines a relationship between values of the three interrelated variables Country, Currency, and Fuel. It stipulates that if the value of the variable Country is set to DK, the valid values of the variable Currency are DKK and EUR and the valid value of the variable Fuel is Diesel. If, however, UK is selected as Country, the only valid value for Currency is GBP , while Fuel may take the values of Diesel and Petrol.
  • rule splitting 104a is mainly employed to complex rules depending on a plurality of variables.
  • a complex (textual) rule is split into several resulting rules based on the structure of the Boolean function encoded by the R-BDD representing the rule.
  • An R-BDD representing a rule is taken as input, and a list of R-BDDs representing the resulting rules is returned by the rule-splitting algorithm.
  • rule splitting 104a might look as follows:
  • the following pseudo-code illustrates a particular implementation example for splitting an R-BDD into two R-BDDs.
  • the splitting-process is an iterative application of this method on each resulting R-BDD. It ends, if no resulting R-BBD can be split anymore by the method.
  • the input to the Rule Splitting Method is an R-BDD r .
  • the method attempts to split the R-BDD r into two resulting R-BDDs such that the conjunction of the resulting R-BDDs is identical to the input R-BDD r (condition 1).
  • Another condition (condition 2) of the splitting method is that each of the resulting R-BDDs depends on fewer variables than the input R-BDD r , i.e. if the input R-BDD r has k dependent variables, each of the resulting R-BDDs has at most (k-1) dependent variables.
  • V r the variables in r are denoted as V r .
  • any two random variables a and b included in V r are picked.
  • the variables a and b are split-candidates, if the condition at line 3 is satisfied.
  • the two R-BDDs Proj(r, V r ⁇ b ⁇ ) and Proj(r, V r ⁇ a ⁇ ) satisfy the two conditions mentioned above.
  • the sets of variables V a and V b are defined. These are the sets of variables on which the resulting R-BDDs will depend on. In lines 7-13 it is attempted to remove further variables from any of the two resulting R-BDDs.
  • the resulting R-BDDs are returned.
  • the S-BDD 105 is generated subsequent to the generation of the R-BDDs 104.
  • the S-BDD 105 is utilized to support a user during the subsequent scope setting 106.
  • the S-BDD 105 is a representation of the valid combinations among the values of the scope variables, i.e. the "small" configuration problem as we called it above.
  • Figure 15 a) depicts a screenshot of the valid combinations among these scope variables.
  • the relation of Figure 15 a) is a projection of the solution space of the initial car product model on the three scope variables, i.e. for any combination of scope variables displayed in Figure 15 a) the configuration can be extended to a valid complete configuration fulfilling all rules included in the initial product model.
  • Figure 15 b) displays the S-BDD corresponding to the relation of Figure 15 a) .
  • the combinations among the values of the variables Country (Boolean variables 5, 6 ), Engine (Boolean variables 14, 15 ) and GearBox (Boolean variables 16 ) are arranged in a way that the valid combinations among these variables correspond to a path starting at the root node (here 5 ) that ends at the 1-terminal node, while the path for all forbidden combinations ends at the 0-terminal node.
  • an S-BDD 105 representing the valid combinations among values of scope variables can be a complex task.
  • the following method of generating an S-BDD 105 is employed:
  • Partition variables are target variables which are used to partition the solution space given by the initial product model in order to generate the S-BDD.
  • the partition variables are formed by a subset of the scope variables defined in the product model, although it is also possible to include non-scope variables in the set of partition variables.
  • high-impact variables are selected as partition variables.
  • a variable is a high-impact variable, if selecting a value for the variable and simplifying the R-BBDs based on the selected value results in drastic restriction of the R-BDDs.
  • Measures to quantify the impact of a particular variable could be the number of other variables having only a single valid value due to the selection of a value for the particular variable, or the magnitude of reduction in required BDD-nodes in the R-BDDs due to the selection of a value for the particular variable.
  • the set of partition variables V P could be specified upfront in the product-model or automatically determined as a small subset of one to five high-impact variables of V.
  • the input to the S-BDD method is a product model (V, R) along with a set of scope variables V S and partition variables Vp.
  • V, R a product model
  • V S scope variables
  • Vp partition variables
  • the S-BDD S is initialized to represent the Boolean false value.
  • a for-loop reaching from line 2 to line 6 is executed for each possible combination of values for the variables in V P (The number of possible combinations of the values of the partition values can quickly grow with increasing size of V P . Hence, only a limited number of variables in V P , more specifically, a limited number of valid combinations of their values, is selected in order to perform the S-BDD calculation within a reasonable amount of time).
  • the selected values for V P are used to simplify the R-BDDs of R.
  • the resulting simplified R-BDDs are denoted as R'.
  • a ToBDDs T for the resulting (V, R') is generated (see e.g. [ToBBDs2005]).
  • a projection of the ToBDDs' Boolean function on the scope variables is generated in b.
  • the BDD b is embedded in S-BDD S with a disjunction operation at line 6.
  • the S-BDD S is returned.
  • values for the scope variables are selected out of the respective sets of values associated to the scope variables and set accordingly.
  • the S-BDD 105 might be used to guide a user during this scope setting process.
  • This guidance takes the following form: After selecting a value for a first scope variable, a subset of values is suggested to a user prior to the selection of a value for any further scope variable.
  • the suggested subset of values is generated based on the S-BDD 105 and represents the first restriction effected by the selection of the value of the first scope variable. It includes only those values of a scope variable which are compatible with the already selected scope variables.
  • the selections made based on the S-BDD 105 will automatically represent valid combinations of the complete configuration problem.
  • the initial product model 102 is simplified in the further process of the configuration method depicted in Figure 1 .
  • the R-BDDs 104 are restricted in order to reflect the selected values of the scope variables 102a.
  • the number of SRR-BDDs (C 1 - C n ) may differ from the number of R-BDDs (B 1 - B m ).
  • unary-constraint In unary constraint propagation a constraint that is only defined over one variables (a so called "unary-constraint") is conjoined (logical AND) with any other rule depending on that variable. Afterwards, provided that the variable occurs in another rule, the unary constraint becomes redundant and is removed.
  • the simplified product model 107 of the exemplary car configuration problem is illustrated in Figure 17 . It should be noted that the selected values of the variables of the initial car configuration product model of Figure 2 might still be included in the simplified product model of Figure 17 ; however, these constants do not form part of the simplified configuration problem anymore.
  • time domain subdivision for time-related variables which is derived from the rules defining dependencies for such time-related variables as explained above with reference to Figure 6 .
  • a time domain subdivision performed in the initial product model is propagated on the basis of the restricted rules and generally reduced set of variables and values.
  • time domain subdivision for time-related variables generally differs from that of the initial product model.
  • a ToBDDs 108 is generated on the basis of the simplified product model 107 .
  • the concept of connected components is employed to generate a ToBDDs 108.
  • a first rule is regarded to be connected to a second rule, (a) if both of the rules share a variable, or (b) if there is a third rule which is connected to the first/second rules, and this third rule shares a variable with the second/first rule; the connected rules and the variables associated to the connected rules form a connected component.
  • the ToBDDs includes a tree for each set of connected components included in the simplified product model.
  • Each tree is generated based on a tree decomposition, in which the respective rules of the simplified product model 107 are arranged at the tree-nodes of the tree decomposition based on pre-defined tree-decomposition properties.
  • the entirety of rules, represented by corresponding SR-BDDs, attached to each single node is then merged, resulting in a single BDD at each node of the tree-decomposition.
  • the resulting structure of all trees with attached BDDs at the nodes of the tree decomposition is called Tree of BDDs (ToBDDs).
  • the ToBDDs 108 can be regarded as a representation of the valid solutions of the configuration problem defined by the simplified product model 107.
  • the first tree representing the EmissionUS rule and the variables EmissionStandard and Date includes only one node (n1), as only one rule is represented by this tree.
  • the BDD attached to the n1 node is identical to the R-BDD of the simplified EmissionUS rule of Figure 16 .
  • the second tree with its only n2-node represents the GearBox variable.
  • the GearBox variable is independent of any rule, the BDD attached to the n2 node is a so called "True-BDD" indicating that each of the values of the GearBox variable is valid.
  • Figure 18 b shows the hypothetical ToBDDs corresponding to the initial car configuration product model of Figure 2 , as it would have been generated without any simplification resulting from a scope setting.
  • All rules of the initial product model are connected to each other, and each variable of the initial product model is associated to at least one rule (as can be seen in the table of Figure 18 b) ), only one connected component exists for the initial product model. Consequently, the ToBDD of this configuration problem includes only one tree.
  • the tree itself includes four nodes, n1 to n4.
  • the rules and variables of the initial product model which are associated to each node in the form of a BDD are displayed in the table of Figure 18 b) . If more than one rule is attached to a certain node, the R-BDDs of the rules are merged to generate the respective BDD of a node (in the case of g1 and g2), otherwise, the BDD associated to a node is identical to the R-BDD of the respective rule (in the case of g3 and g4).
  • the values for the non-scope variables are selected (manually by the user or automatically by the computer) in order to complete the product configuration.
  • the computer sets the values of the non-scope variables according to the selection.
  • the selection and setting of the non-scope variables is an iterative process. It terminates, at the latest, if values for all non-scope variables are selected and set.
  • the ToBDDs 108 may be consulted to assure that the selection of the non-scope variables results in a valid configuration.
  • the process of selecting and setting values for the non-scope variables includes forming a partial configuration 109.
  • several activities 110 might be performed by the computer. These activities might include a variety of queries (see above), which may be answered under consideration of the ToBDDs 108.
  • the mathematical function Price is defined in the product model.
  • Fuel this function which is displayed as source-code implementation in Figure 19 , might be used to calculate the price of a configured car.
  • a car has a base price of 10000 EUR.
  • additional costs emerge (for Petrol : 5000 Euro, for Diesel : 7500 Euro).
  • the base price and the additional costs (variant price) add up to the total price of the car.
  • This total price is finally displayed to a user, if respective query is performed. If a different value for the variable Currency such as DKK, GBP, or USD was selected during the car configuration process, the total price of the car is converted to the selected Currency based on a predefined currency conversion factor before it is displayed to the user.
  • the segments from 101 to 105 are performed offline, e.g. by one or more servers which are generally not accessed by end user configuration requests. User input is not necessary in this first phase of the configuration.
  • the offline phase is generally performed only once per product model and might be repeated in the case of a product model adaption. Due to the absence of user interaction, time constraints for the offline calculations are more relaxed.
  • the segments 106 to 110 are performed on an online accessible configuration server, as indicated in Figure 1 .
  • this online accessible configuration server differs from the server(s) performing the offline calculation, the product model representations, e.g. the R-BDDs and the S-BDD, are transferred from the offline to the online server.
  • Segment 106 is generally the starting point of the interactive selection of the scope and non-scope variables supervised by the user. This interactive selection is generally performed multiple times on the basis of the same product model representation established by the segments 101 to 105.
  • the method terminates at segment 111, either by having achieved a complete configuration or premature abort, e.g. by manual termination command issued by the user.
  • Figure 20 is a diagrammatic representation of the internal structure of a computer or server 120 which implements the product configuration mechanisms described herein.
  • the computer or server 120 is arranged to execute a set of instructions, to cause it to perform any of the methodologies explained above.
  • the computer or server 120 includes a processor 121, a main memory 122 and, optionally, a wireless network interface 123 (such as a Wi-Fi and/or Bluetooth interface) and/or a 2G/3G/4G mobile network interface device, all of which communicate with each other via a bus 124. It further includes a static memory 125, e.g.
  • non-removable flash and/or solid state drive and/or a removable Micro or Mini SD card which permanently stores the software enabling computer/server 120 to execute its functions, such as storing a product model including pre-determined scope variables, generating Rule BDDs, allowing the selection of values for the scope variables, restricting the product model e.g. to a Tree-of-BDDs and allowing a user to iteratively select values for non-scope variables in order to finish configuration, etc. and to optionally communicate with client computers/devices within a local or wide area network via its wired and/or wireless network interface device 123.
  • computer/server 120 includes a display 127, a user interface control module 129 and an alpha-numeric and cursor input device 128.
  • I/O interfaces 126 such as card reader and USB interfaces may be present.
  • the software 130 may further be transmitted or received as a propagated signal 132 through the wired or wireless network interface device 123 from/to a software server within the local area network or the Internet.

Landscapes

  • Business, Economics & Management (AREA)
  • Economics (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
EP20130005167 2013-10-31 2013-10-31 Configuration de produit Withdrawn EP2869257A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP20130005167 EP2869257A1 (fr) 2013-10-31 2013-10-31 Configuration de produit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP20130005167 EP2869257A1 (fr) 2013-10-31 2013-10-31 Configuration de produit

Publications (1)

Publication Number Publication Date
EP2869257A1 true EP2869257A1 (fr) 2015-05-06

Family

ID=49552145

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20130005167 Withdrawn EP2869257A1 (fr) 2013-10-31 2013-10-31 Configuration de produit

Country Status (1)

Country Link
EP (1) EP2869257A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3627346A1 (fr) 2018-09-20 2020-03-25 Amadeus S.A.S. Traitement de séquence d'appels de fonction

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002046980A2 (fr) * 2000-12-08 2002-06-13 Configit Software A/S Procede de configuration d'un produit

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002046980A2 (fr) * 2000-12-08 2002-06-13 Configit Software A/S Procede de configuration d'un produit
US7584079B2 (en) 2000-12-08 2009-09-01 Configit Software A/S Method of configuring a product

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ATTARDI G ET AL: "Web-based configuration assistants", ARTIFICIAL INTELLIGENCE FOR ENGINEERING DESIGN, ANALYSIS ANDMANUFACTURING, LONDON, GB, vol. 12, no. 4, 1 September 1998 (1998-09-01), pages 321 - 331, XP002902516 *
S. SUBBARAYAN: "CP-AI-OR Conference", vol. 3524, 2005, SPRINGER, article "Integrating CSP Decomposition Techniques and BDDs for Compiling Configuration Problems", pages: 351 - 368
S. SUBBARAYAN; L. BORDEAUX; Y HAMADI: "Knowledge Compilation Properties of Tree-of BDDs", AAAI CONFERENCE, 2007, pages 502 - 507
SABIN D ET AL: "PRODUCT CONFIGURATION FRAMEWORKS - A SURVEY", IEEE EXPERT, IEEE SERVICE CENTER, NEW YORK, NY, US, vol. 13, no. 4, 1 July 1998 (1998-07-01), pages 42 - 49, XP000791757, ISSN: 0885-9000 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3627346A1 (fr) 2018-09-20 2020-03-25 Amadeus S.A.S. Traitement de séquence d'appels de fonction
FR3086424A1 (fr) 2018-09-20 2020-03-27 Amadeus S.A.S. Traitement d'une sequence d'appels de fonction
US11157308B2 (en) 2018-09-20 2021-10-26 Amadeus S.A.S. Function call sequence processing

Similar Documents

Publication Publication Date Title
US10049396B2 (en) Product configuration
US20210034990A1 (en) Rule Assignments and Templating
JP5957580B2 (ja) ベクトルフィールドを用いるデータ処理
JP6395680B2 (ja) データセット要素のマッピング
Gutierrez Integration analysis of product architecture to support effective team co-location
Cressent et al. Designing the database for a reliability aware Model-Based System Engineering process
Chtourou et al. An expert system for manufacturing systems machine selection
US8942963B1 (en) Directed design updates in engineering methods for systems
US20190392349A1 (en) Simplified product configuration using table-based rules, rule conflict resolution through voting, and efficient model compilation
Van der Aalst et al. Process modeling and analysis
Park et al. A goal-oriented big data analytics framework for aligning with business
US20150331974A1 (en) Product configuration
Hettab et al. A graph transformation approach for automatic test cases generation from UML activity diagrams
EP2869257A1 (fr) Configuration de produit
Mumtaz et al. Modeling iteration’s perspectives in software engineering
Losavio et al. Graph modelling of a refactoring process for product line architecture design
Jurack et al. Sufficient criteria for consistent behavior modeling with refined activity diagrams
US9996795B2 (en) Generating a non-deterministic model of a process for a goal
Kissel et al. System architecture change decisions in multi-variant product portfolios
US7603363B2 (en) Systems and methods for controlling transaction participation for groups of steps in a workflow
BOUSETTA et al. Generating operations specification from domain class diagram using transition state diagram
JP7039232B2 (ja) 技術情報共有システム及び技術情報共有方法
Valvas et al. Requirement elicitation using business process models
US9430362B1 (en) System, method, and computer program for generating a fully traceable test design
Sellier et al. Managing requirements inter-dependency for software product line derivation

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20131031

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

R17P Request for examination filed (corrected)

Effective date: 20151014

RBV Designated contracting states (corrected)

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

17Q First examination report despatched

Effective date: 20151202

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APBX Invitation to file observations in appeal sent

Free format text: ORIGINAL CODE: EPIDOSNOBA2E

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20220719