FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See Section 10 and Rule 13)
Title of invention:
METHOD AND SYSTEM FOR VALIDATION OF CONFIGURATION CONSTRAINTS AND PRODUCTION CONSTRAINTS FOR FEATURE VIABILITY
Applicant
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th floor,
Nariman point, Mumbai 400021,
Maharashtra, India
Preamble to the description
The following specification particularly describes the invention and the manner in which it is to be performed.
2
TECHNICAL FIELD
[001]
The disclosure herein generally relates to product planning, and, more particularly, to a method and system for validation of configuration constraints and production constraints for feature viability. 5
BACKGROUND
[002]
Product planning involves one or more internally focused decisions, steps, and tasks necessary to develop a successful product. In many manufacturing 10 domains, such as automobile industry, a product such as a vehicle, is often offered in multiple product variants. These variants are offered considering various factors such as engineering constraints, user preferences of features, availability of parts, production constraints, cost, and market competitive factors. Considering the scale, complexity and uncertainty of these factors, the product planning continues to be a 15 challenging task for the manufacturers. One of the key problems in the product planning and manufacturing is to identify the key product variants along with their respective production volumes. While product planning, it is often required to run multiple scenarios, each with different sets of configuration constraints and production constraints. Moreover, as business requirements change, the constraints 20 also undergo change, and the constraints set need to be frequently updated. This allows the possibility of introducing conflicting constraints leading to one or more feature variants becoming unviable. However, most business applications require that all the feature variants appear in either of its product variants. Although there are many constraints solvers to solve such a set of constraints, they do not address 25 the problem of feature viability. They do not check if a given feature is unviable due to conflicting constraints. A skilled domain expert would typically inspect the constraints manually and assume that the feature variants remain viable. This process is quite ad-hoc and subject to errors especially when the constraints set is large and complex. 30
3
SUMMARY
[003]
Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one 5 embodiment, a method of validating one or more constraints to obtain a valid set of constraints is provided. The processor implemented method includes receiving, via one or more hardware processors, a product configuration scenario (S) associated with a product, as an input; generating, via the one or more hardware processors, a constraints network to obtain a valid product configuration scenario (T); and 10 updating, via the one or more hardware processors, the constraints network with an updated valid product configuration scenario that includes a valid set of updated constraints based on at least one of: (a) addition of one or more new configuration constraints, or (b) modification of the existing production constraints. The product configuration scenario (S) associated with the product includes: (a) a set of feature 15 families, (b) a set of configuration constraints, and (c) a set of production constraints. Each feature family from the set of feature families includes one or more feature variants. Each configuration constraint from the set of configuration constraints is modeled as a logical clause of premise and implication between two or more feature variants. The set of production constraints corresponds to: (a) a set 20 of take rate constraints, and (b) a set of availability constraints, for each feature variant of the product. The valid product configuration scenario (T) includes a valid set of constraints. The valid set of constraints is obtained by validation of (a) the set of configuration constraints, (b) the set of take rate constraints, and (c) the set of availability constraints in a sequential order. A set of constraints is considered to be 25 valid if they do not render any feature variant of the product as unviable.
[004]
In an embodiment, the step of validation of the set of configuration constraints includes: (a) generating, via the one or more hardware processors, the constraints network that includes two nodes for each feature variant; (b) generating, via the one or more hardware processors, two lists for each node; (c) processing, 30 via the one or more hardware processors, one configuration constraint from the
4
given set of configuration constraints, at a time
; (d) determining, via the one or more hardware processors, if the given configuration constraint is consistent with the previously validated set of constraints by computing transitive closure over the set of configuration constraints by employing the source list, and the destination list of each node in the constraints network; and (e) updating, via the one or more 5 hardware processors, the constraints network if the given configuration constraint is consistent with the previously validated set of constraints, or else the given configuration constraint is discarded. In an embodiment, the two nodes for each feature variant correspond to: (i) a positive node, and (ii) a negative node. In an embodiment, the two lists for each node correspond to: (i) a source list, and (ii) a 10 destination list. In an embodiment, the source list of a given node corresponds to a set of nodes that lead to the given node through a directed path in the constraints network. In an embodiment, the destination list of a given node corresponds to a set of nodes that are reachable from the given node through a directed path in the constraints network. In an embodiment, each source list and each destination list 15 are updated after validation of each configuration constraint. In an embodiment, the step of validation of the set of take rate constraints includes: (a) modelling, via the one or more hardware processors, one take rate constraint associated with each feature variant of the product, as a real interval, that represents (i) a minimum take rate value, and (ii) a maximum take rate value, for the given feature variant; (b) 20 processing, via the one or more hardware processors, one take rate constraint from the given set of take rate constraints, at a time; (c) updating, via the one or more hardware processors, the take rate interval of the given take rate constraint based on the previously validated set of constraints; and (d) updating, via the one or more hardware processors, the constraints network if the given take rate constraint is 25 consistent with the previously validated set of constraints, or else the given take rate constraint is discarded. In an embodiment, the set of availability constraints is validated based on the validated set of take rate constraints. In an embodiment, the step of validation of the set of availability constraints includes: (a) modelling, via the one or more hardware processors, one availability constraint associated with 30 each feature variant of the product, as a real interval, that represents (i) a minimum
5
availability
value, and (ii) a maximum availability value, for the given feature variant; (b) determining, via the one or more hardware processors, the validity of each availability constraint from the given set of availability constraints by checking if the minimum availability value, and the maximum availability value are sufficient to accommodate the minimum take rate value, and the maximum take 5 rate value of the corresponding feature variant; and (c) adding, via the one or more hardware processors, the valid set of availability constraints to the constraints network. In an embodiment, each availability constraint that is found to be inconsistent with the previously validated set of constraints is discarded.
[005]
In another embodiment, there is provided a system for validation of 10 one or more constraints to obtain a valid set of constraints. The system includes a memory storing instructions; one or more communication interfaces; and one or more hardware processors coupled to the memory via the one or more communication interfaces, wherein the one or more hardware processors is configured by the instructions to: receive, a product configuration scenario (S) 15 associated with a product, as an input; generate, a constraints network to obtain a valid product configuration scenario (T); and update, the constraints network with an updated valid product configuration scenario that includes a valid set of updated constraints based on at least one of: (a) addition of one or more new configuration constraints, or (b) modification of the existing production constraints. The product 20 configuration scenario (S) associated with the product, includes: (a) a set of feature families, (b) a set of configuration constraints, and (c) a set of production constraints. Each feature family from the set of feature families includes one or more feature variants. Each configuration constraint from the set of configuration constraints is modeled as a logical clause of premise and implication between two 25 or more feature variants. The set of production constraints corresponds to: (a) a set of take rate constraints, and (b) a set of availability constraints, for each feature variant of the product. The valid product configuration scenario (T) includes a valid set of constraints. The valid set of constraints is obtained by validation of (a) the set of configuration constraints, (b) the set of take rate constraints, and (c) the set of 30
6
availability constraints
in a sequential order. A set of constraints is considered to be valid if they do not render any feature variant of the product as unviable.
[006]
In an embodiment, the one or more hardware processors are configured by the instructions to validate the set of configuration constraints, includes: (a) generate, the constraints network that includes two nodes for each 5 feature variant; (b) generate, two lists for each node; (c) process, one configuration constraint from the given set of configuration constraints, at a time; (d) determine, if the given configuration constraint is consistent with the previously validated set of constraints by computing transitive closure over the set of configuration constraints by employing the source list, and the destination list of each node in the 10 constraints network; and (e) updating, via the one or more hardware processors, the constraints network if the given configuration constraint is consistent with the previously validated set of constraints, or else the given configuration constraint is discarded. In an embodiment, the two nodes for each feature variant correspond to: (i) a positive node, and (ii) a negative node. In an embodiment, the two lists for 15 each node correspond to: (i) a source list, and (ii) a destination list. In an embodiment, the source list of a given node corresponds to a set of nodes that lead to the given node through a directed path in the constraints network. In an embodiment, the destination list of a given node corresponds to a set of nodes that are reachable from the given node through a directed path in the constraints 20 network. In an embodiment, each source list and each destination list are updated after validation of each configuration constraint. In an embodiment, the one or more hardware processors are configured by the instructions to validate the set of take rate constraints, includes: (a) model, one take rate constraint associated with each feature variant of the product, as a real interval, that represents (i) a minimum take 25 rate value, and (ii) a maximum take rate value, for the given feature variant; (b) process, one take rate constraint from the given set of take rate constraints, at a time; (c) update, the take rate interval of the given take rate constraint based on the previously validated set of constraints; and (d) update, the constraints network if the given take rate constraint is consistent with the previously validated set of 30 constraints, or else the given take rate constraint is discarded. In an embodiment,
7
the one or more hardware processors are configured by the instructions to
validate the set of availability constraints based on the validated take rate constraints, includes: (a) model, one availability constraint associated with each feature variant of the product, as a real interval, that represents (i) a minimum availability value, and (ii) a maximum availability value, for the given feature variant; (b) determine, 5 the validity of each availability constraint from the given set of availability constraints by checking if the minimum availability value, and the maximum availability value are sufficient to accommodate the minimum take rate value, and the maximum take rate value of the corresponding feature variant; and (c) add, the valid set of availability constraints to the constraints network. In an embodiment, 10 each availability constraint that is found to be inconsistent with the previously validated set of constraints is discarded.
[007]
In yet another embodiment, there are provided one or more non-transitory machine readable information storage mediums comprising one or more instructions which when executed by one or more hardware processors causes at 15 least one of: receiving, a product configuration scenario (S) associated with a product, as an input; generating, a constraints network to obtain a valid product configuration scenario (T); and updating, the constraints network with an updated valid product configuration scenario that includes a valid set of updated constraints based on at least one of: (a) addition of one or more new configuration constraints, 20 or (b) modification of the existing production constraints. The product configuration scenario (S) associated with the product includes: (a) a set of feature families, (b) a set of configuration constraints, and (c) a set of production constraints. Each feature family from the set of feature families includes one or more feature variants. Each configuration constraint from the set of configuration 25 constraints is modeled as a logical clause of premise and implication between two or more feature variants. The set of production constraints corresponds to: (a) a set of take rate constraints, and (b) a set of availability constraints, for each feature variant of the product. The valid product configuration scenario (T) includes a valid set of constraints. The valid set of constraints is obtained by validation of (a) the set 30 of configuration constraints, (b) the set of take rate constraints, and (c) the set of
8
availability constraints
in a sequential order. A set of constraints is considered to be valid if they do not render any feature variant of the product as unviable.
[008]
In an embodiment, the step of validation of the set of configuration constraints includes: (a) generating, the constraints network that includes two nodes for each feature variant; (b) generating, two lists for each node; (c) processing, one 5 configuration constraint from the given set of configuration constraints, at a time; (d) determining, if the given configuration constraint is consistent with the previously validated set of constraints by computing transitive closure over the set of configuration constraints by employing the source list, and the destination list of each node in the constraints network; and (e) updating, the constraints network if 10 the given configuration constraint is consistent with the previously validated set of constraints, or else the given configuration constraint is discarded. In an embodiment, the two nodes for each feature variant correspond to: (i) a positive node, and (ii) a negative node. In an embodiment, the two lists for each node correspond to: (i) a source list, and (ii) a destination list. In an embodiment, the 15 source list of a given node corresponds to a set of nodes that lead to the given node through a directed path in the constraints network. In an embodiment, the destination list of a given node corresponds to a set of nodes that are reachable from the given node through a directed path in the constraints network. In an embodiment, each source list and each destination list are updated after validation 20 of each configuration constraint. In an embodiment, the step of validation of the set of take rate constraints includes: (a) modelling, one take rate constraint associated with each feature variant of the product, as a real interval, that represents (i) a minimum take rate value, and (ii) a maximum take rate value, for the given feature variant; (b) processing, one take rate constraint from the given set of take rate 25 constraints, at a time; (c) updating, the take rate interval of the given take rate constraint based on the previously validated set of constraints; and (d) updating, the constraints network if the given take rate constraint is consistent with the previously validated set of constraints, or else the given take rate constraint is discarded. In an embodiment, the set of availability constraints is validated based on the validated 30 take rate constraints. In an embodiment, the step of validation of the set of
9
availability constraints
includes: (a) modelling, one availability constraint associated with each feature variant of the product, as a real interval, that represents (i) a minimum availability value, and (ii) a maximum availability value, for the given feature variant; (b) determining, the validity of each availability constraint from the given set of availability constraints by checking if the minimum 5 availability value, and the maximum availability value are sufficient to accommodate the minimum take rate value, and the maximum take rate value of the corresponding feature variant; and (c) adding, the valid set of availability constraints to the constraints network. In an embodiment, each availability constraint that is found to be inconsistent with the previously validated set of 10 constraints is discarded.
[009]
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
15
BRIEF DESCRIPTION OF THE DRAWINGS
[010]
The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles: 20
[011]
FIG. 1 illustrates a block diagram of a system for a constraints network based validation of one or more constraints to obtain a validated product configuration scenario (T) with a valid set of constraints, according to some embodiments of the present disclosure.
[012]
FIG. 2A and FIG. 2B are functional block diagrams of the system of 25 FIG. 1 illustrating the validation of the one or more constraints to obtain the validated product configuration scenario (T) with the valid set of constraints, according to some embodiments of the present disclosure.
[013]
FIG. 3A through FIG. 3C are exemplary functional block diagrams illustrating configuration constraints between feature variants of three feature 30
10
families
of a vehicle product, according to some embodiments of the present disclosure.
[014]
FIG. 3D is an exemplary functional block diagram illustrating various types of configuration constraints, according to some embodiments of the present disclosure. 5
[015]
FIG. 4 is an exemplary graphical representation illustrating the validation of the configuration constraints and generation of the corresponding constraints network, according to some embodiments of the present disclosure.
[016]
FIG. 5A through FIG. 5C are exemplary flow diagrams illustrating a method of validating one or more constraints to obtain the validated product 10 configuration scenario (T) with the valid set of constraints, according to an embodiment of the present disclosure.
DETAILED DESCRIPTION OF EMBODIMENTS
15
[017]
Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are 20 described herein, modifications, adaptations, and other implementations are possible without departing from the scope of the disclosed embodiments.
[018]
In product planning, there is a need for a framework to efficiently validate configuration constraints and production constraints for feature viability. Embodiments of the present disclosure provide a constraints network based 25 constraint validation approach that returns a set of non-conflicting constraints by pruning away any conflicting constraints that render any feature variant unviable. The embodiment thus provides a framework which efficiently validates, and updates a given set of configuration constraints and production constraints for viability of features. The configuration constraints describe the association rules 30 between two or more feature variants of a product variant. The product variants
11
corresponds to one or more variants of
a given product that includes a set of feature variants, wherein each feature variant belongs to a distinct feature family. The feature family corresponds to a feature of the given product that includes the feature variants of corresponding feature. The feature variant corresponds to a particular variant of the given feature family. The feature families are denoted by uppercase 5 alphabets, i.e., A, B, C etc. The feature variants within a given feature family are shown as a notation of a corresponding feature family followed by a numeric index as a subscript, such as the feature variants of the feature family A are denoted as A1, A2, A3, etc. The production constraints corresponds to a take rate constraint and an availability constraint associated with each feature variant of the product. The take 10 rate constraint is a constraint that specifies a lower bound and an upper bound on the take rate of a given feature variant, which indicates a fraction of the total production volume of the given product that demands the given feature variant. The availability constraint is a constraint that specifies a lower bound and an upper bound on the availability of a given feature variant, which indicates a fraction of 15 the total production volume of the given product for which the given feature variant is available. A constraints network is built by employing one or more techniques e.g., a transitive closure, a reachability testing, and constraint propagation for analyzing the consistency of constraints. Considering an input set of configuration constraints, and production constraints, denoted by CP, the output is a maximal 20 valid set of constraints, denoted by CPv, where CPv is a subset of the CP, that is consistent, i.e., does not render any feature variant as unviable, and addition of any constraint from the set CP – CPv to the set CPv, renders one or more feature variants as unviable. Alternatively, a set of constraints that are inconsistent i.e., the constraints that render one or more feature variants unviable, are pruned out. The 25 maximal valid set of constraints is NOT unique, i.e., there may exist more than one maximal valid set of constraints.
[019]
Referring now to the drawings, and more particularly to FIGS. 1 through 5C, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments, and 30
12
these embodiments are described in the context of the following exemplary system
and/or method.
[020]
FIG. 1 illustrates a block diagram of a system 100 for a constraints network based validation of one or more constraints to obtain a validated product configuration scenario (T) with a valid set of constraints, according to some 5 embodiments of the present disclosure. In an embodiment, the system 100 includes one or more processor(s) 102, communication interface device(s) or input/output (I/O) interface(s) 106, and one or more data storage devices or a memory 104 operatively coupled to the one or more processor(s) 102. The memory 104 includes a database (Not shown in Figure). The one or more processor(s) processor 102, the 10 memory 104, and the I/O interface(s) 106 may be coupled by a system bus 108 or a similar mechanism. The one or more processor(s) 102 that are hardware processors can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational 15 instructions. Among other capabilities, the one or more processor(s) 102 is configured to fetch and execute computer-readable instructions stored in the memory 104. In an embodiment, the system 100 can be implemented in a variety of computing systems, such as laptop computers, notebooks, hand-held devices, workstations, mainframe computers, servers, a network cloud, and the like. 20
[021]
The I/O interface device(s) 106 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface device(s) 106 may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse, an external memory, a camera device, and a printer. Further, 25 the I/O interface device(s) 106 may enable the system 100 to communicate with other devices, such as web servers and external databases. The I/O interface device(s) 106 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, local area network (LAN), cable, etc., and wireless networks, such as Wireless LAN 30 (WLAN), cellular, or satellite. In an embodiment, the I/O interface device(s) 106
13
can include one or more ports for connecting number of devices to one another or
to another server.
[022]
The memory 104 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random-access memory (SRAM) and dynamic random-access memory (DRAM), and/or 5 non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, the memory 104 includes a plurality of modules 110 and a repository 112 for storing data processed, received, and generated by the plurality of modules 110. The plurality of modules 110 may include routines, programs, objects, 10 components, data structures, and so on, which perform particular tasks or implement particular abstract data types.
[023]
Further, the database stores information pertaining to inputs fed to the system 100 and/or outputs generated by the system (e.g., data/output generated at each stage of the data processing) 100, specific to the methodology described 15 herein. More specifically, the database stores information being processed at each step of the proposed methodology.
[024]
Additionally, the plurality of modules 110 may include programs or coded instructions that supplement applications and functions of the system 100. The repository 112, amongst other things, includes a system database 114 and other 20 data 116. The other data 116 may include data generated as a result of the execution of one or more modules in the plurality of modules 110. Further, the database stores information pertaining to inputs fed to the system 100 and/or outputs generated by the system (e.g., at each stage), specific to the methodology described herein. Herein, the memory for example the memory 104 and the computer program code 25 configured to, with the hardware processor for example the processor 102, causes the system 100 to perform various functions described herein under.
[025]
FIG. 2A and FIG. 2B are functional block diagrams of the system of FIG. 1 illustrating the validation of the one or more constraints to obtain the validated product configuration scenario (T) with the valid set of constraints, 30 according to an embodiment of the present disclosure. FIG. 3A through FIG. 3C
14
are exemplary functional block diagrams illustrating configuration constraints
between feature variants of three feature families of a vehicle product, according to some embodiments of the present disclosure. FIG. 3D is an exemplary functional block diagram illustrating various types of configuration constraints, according to some embodiments of the present disclosure. The system 200 may be an example 5 of the system 100 (FIG. 1). In an example embodiment, the system 200 may be embodied in, or is in direct communication with the system, for example the system 100 (FIG. 1). The system 200 includes a constraints validation unit 202, a constraints network 204, and a constraints updation unit 206. The constraints validation unit 202 is configured to receive a product configuration scenario (S) 10 associated with a product, as an input. The product configuration scenario (S) associated with the product, includes (a) a set of feature families, (b) a set of configuration constraints, and (c) a set of production constraints. In an embodiment, the product configuration scenario enables planning of a product i.e., a plan to manufacture one or more product variants, along with corresponding feature 15 configurations and production volumes. In an embodiment, the product is generally available in multiple variants, each having a unique set of components, each belonging to a specific component class, which corresponds to the set of feature families. For example, a vehicle variant includes one or more feature families such as an engine (E), a body (B), a wheel (W). Each feature family from the set of feature 20 families includes one or more choices, referred to as the feature variants. For example, the engine (E) may be available in three variants E1, E2, and E3, that forms the feature variants of the feature family E. In an embodiment, each configuration constraint represents a logical association between the feature variants of two or more feature families of the product. 25
[026]
In an embodiment, three types of configuration constraints are considered, namely, positive, negative, and disjunctive. A positive configuration constraint indicates a positive association between the corresponding feature variants which is represented as Ai→Bj, i.e., if Ai is present, then Bj must be present. A negative configuration constraint indicates a negative association between the 30 corresponding feature variants which is represented as Ai→~Bj, i.e., if Ai is present,
15
then
Bj must be absent. A disjunctive configuration constraint indicates a disjunctive association between corresponding feature variants which is represented as Ai→Bj ∨ Bk, i.e., if Ai is present, then either Bj or Bk must be present. The feature variants that occur on the two sides of the → must belong to different feature families, i.e., there is no constraint such as Ai→Aj. In addition, for a disjunctive 5 configuration constraint, the feature variants that lie on the same side of →, must belong to the same feature family, i.e., there is no constraint e.g., Ai→Bj ∨ Ck. FIG. 3A shows the configuration constraints between the feature families, the engine (E) and the body (B) through a constraint matrix that represents the following constraints: E1→~B2, E2 →B3. Similarly, FIG. 3B shows the configuration 10 constraints between the feature families, the engine (E) and the wheel (W). FIG. 3C shows the configuration constraints between the feature families, the wheel (W) and the body (B). For the given set of constraints shown through FIG. 3A, FIG. 3B, and FIG. 3C, (E1, B1, W1) is an example of a feasible product variant as this configuration satisfies all the constraints, and (E1, B2, W1) is an example of an 15 infeasible product variant this configuration violates the constraint: E1→~B2.
[027]
The configuration constraints are characterized with a transitive association, i.e.,
if Ai→Bj and Bj→Ck, then Ai→Ck.
If Ai→Bj and Bj→~Ck, then Ai→~Ck. 20
If Ai→Bj and Bj→ Ck ∨ Cl, then Ai→ Ck ∨ Cl.
If Ai→Bj ∨ Bk, such that Bj→Cl and Bk→Cl, then Ai→Cl.
[028]
Henceforth, the set of configuration constraints is assumed to be transitively closed, i.e., all possible transitive constraints are considered to be added to the constraints set. 25
[029]
The set of production constraints corresponds to (a) a set of take rate constraints, and (b) a set of availability constraints for each feature variant of the product. The take rate constraint for a feature variant Ai specifies a range for a take rate value of Ai, that is modelled as a closed interval, denoted by [minTR(Ai), maxTR(Ai)], and where minTR(Ai) and maxTR(Ai) denote a minimum take rate of 30 Ai, and a maximum take rate of Ai, respectively, where 0 ≤ minTR(Ai) ≤ maxTR(Ai)
16
≤ 1. The
availability constraint for a feature variant Ai specifies a range for an availability value of Ai, that is modelled as a closed interval, denoted by [minA(Ai), maxA(Ai)], and where minA(Ai) and maxA(Ai) denote a minimum availability of Ai, and a maximum availability of Ai, respectively, where 0 ≤ minA(Ai) ≤ maxA(Ai) ≤ 1.
[030]
In an embodiment, the following conditions are necessary for 5 viability of feature variants: (a) since each product variant is composed of exactly one feature variant from each feature family, hence, there should not be constraints such that Ai→Bj and Ai→Bk, because Ai can be installed along with either Bj or Bk, but not both together. For the same reason, there should not be constraints such that Ai→Bj and Ai→Bk ∨ Bl; (b) there should not be constraints such as Ai→Bj and 10 Ai→~Bj; (c) there should not be a constraint Ai→Bj, ∨ Bk, such that both Bj and Bk are unviable; (d) for any constraint Ai→Bj, the take rate values should not be such that minTR(Ai)> minTR(Bj) and maxTR(Ai)> maxTR(Bj); (e) for any constraint Ai→Bj, ∨ Bk, the take rate values should not be such that minTR(Ai )> maxTR(Bj)+ maxTR(Bk); and (f) for any feature variant Ai, the availability values should not be 15 such that either minA(Ai)< minTR(Ai) or maxA(Ai) < maxTR(Ai). A set of constraints is said to be valid or consistent if all of the above conditions are satisfied, else considered invalid or inconsistent.
[031]
The constraints validation unit 202 is configured to generate the constraints network 204 to obtain a valid product configuration scenario (T). The 20 valid product configuration scenario (T) corresponds to a maximally valid set of constraints i.e., a maximal set of constraints that does not include any conflicting constraint such that one or more feature variants become unviable. The valid set of constraints is obtained by validation of: (a) the set of configuration constraints, (b) the set of take rate constraints, and (c) the set of availability constraints in a 25 sequential order. In an embodiment, each configuration constraint from the set of configuration constraints is modeled as a logical clause of premise and implication between two or more feature variants.
[032]
The constraints validation unit 202 further includes a configuration constraints validation unit 202A. The configuration constraints validation unit 30 202A is configured to validate the set of configuration constraints. The constraints
17
network
204 is generated that includes two nodes for each feature variant. The two nodes for each feature variant correspond to: (a) a positive node, and (b) a negative node. In an embodiment, if there is a directed path from node A to node B, and directed path from node B to node C then transitivity property implies that there is a directed path from node A to node C. The process is initialized with an empty 5 constraints network. For example, for each feature variant Ai, the positive node is created with a label Ai, and the negative node is created with a label ~Ai. For each configuration constraint Ai→Bj, a directed edge is created from node Ai to node Bj. Similarly, for each configuration constraint Ai→~Bj, a directed edge is created from node Ai to node ~Bj. Further, two lists for each node are generated where the two 10 lists for each node correspond to: (a) a source list, and (b) a destination list. The source list of a given node corresponds to a set of nodes that lead to the given node through a directed path in the constraints network 204. The destination list of a given node corresponds to a set of nodes that are reachable from the given node through a directed path in the constraints network 204. The constraints validation 15 unit 202 is configured to process each constraint from the given set of configuration constraints in an incremental manner, i.e., one constraint at a time. In an embodiment, a total ordering is imposed on the set of constraints to deterministically report a unique answer set, i.e., the constraints are processed in a fixed order. In an embodiment, the constraints validation unit 202 relies on an order 20 of the input, i.e., the constraints are processed exactly in the same order as given in the input which allows flexible input ordering. The same order is followed even while updating any constraint. In an embodiment, at any stage of validation, the constraints validation unit 202 and the constraints updation unit 206 maintains the set of constraints that are consistent with each other. 25
[033]
The constraints validation unit 202 is configured to determine if a given configuration constraint is consistent with a previously validated set of constraints by computing transitive closure over the set of configuration constraints using the two lists i.e., the source list, and the destination list of each node in the constraints network 204. The source list and the destination list are updated after 30 validation of each configuration constraint to maintain the transitive closure. For
18
each node A
i, the source list of Ai, denoted by Source (Ai), includes Ai and the set of nodes that reach up to Ai through a directed path in the constraints network 204. Similarly, the destination list of Ai, denoted by destination (Ai), which includes Ai and the set of nodes that are reachable from Ai through a directed path in the constraints network 204. As constraints are validated and added, the source list and 5 the destination list of each node in the constraints network 204 are updated accordingly. The constraints network 204 is updated, if a given configuration constraint is consistent with the previously validated set of constraints, or else the given configuration constraint is discarded.
[034]
In an embodiment, each consistent configuration constraint is added 10 to obtain the valid set of configuration constraints and corresponding effect is propagated to the constraints network 204, or else discarded. In an embodiment, before adding any new configuration constraint, a validation check is performed to determine whether such an addition would lead to inconsistency, that renders one or more feature variants to become unviable. The validation check is performed by 15 testing if such an addition would lead to either of the following conditions, there are directed paths from any node Ai to any node Bj, and Ai to ~Bj or, there are directed paths from any node Ai to any node Bj, and Ai to Bk, where j ≠ k and Bj, Bk belong to the same feature family. The former condition requires that if the feature variant Ai is installed in a product, then the feature variant Bj must be present as 20 well as absent, which is a contradiction. The latter condition requires that if the feature variant Ai is installed in a product, then both the feature variants, Bj and Bk must be present. However, since only one feature variant from a feature family can be installed in a product, and Bj and Bk belong to the same feature family B, therefore, Ai can be installed with either Bj or with Bk but not both. Hence, this 25 condition is a contradiction. If any of the above inconsistency arises, the given constraint is discarded; else the given constraint is deemed to be valid and added to the valid set of constraints.
[035]
FIG. 4 is an exemplary graphical representation illustrating the validation of a set of configuration constraints and generation of the corresponding 30 constraints network, according to some embodiments of the present disclosure.
19
Considering
the given set of configuration constraints as depicted in FIG. 4, the configuration constraints validation unit 202A is configured to process the constraints in the same order as specified in the input and the corresponding constraints network is shown in FIG. 4. As configuration constraints are validated, the source list and the destination list of each node in the constraints network, are 5 suitably updated. The constraint F2→ ~D1 is rejected because else this leads to directed paths from A1 to D1 and A1 to ~D1, rendering the feature variant A1 to become unviable. The constraint A1→ ~E2 is rejected because else this leads to directed paths from A1 to E1 and A1 to E2, rendering the feature variant A1 to become unviable. 10
[036]
An exemplary pseudo code illustrating the validation of the one or more configuration constraints is as stated below:
1. While there are configuration constraints to be validated
A.
If the new constraint is Ai→Bj
i.
If nodes Ai and Bj are present in the constraints network 15
a.
For any node X ⋲ Source(Ai), and any node Y ⋲ Destination(Bj), if Destination(X) contains both Y and ~Y, then discard the constraint and go to Step 1.
b.
For any node X ⋲ Source(Ai), and any node Yk ,Yl ⋲ Destination(Bj) such that k ≠ l and Yk , Yl belong to 20 the same feature family, if Destination(X) contains both Yk and Yl, then discard the constraint and go to Step 1.
ii.
Else for each X ⋲ {Ai, Bj} that is not present in the constraints network, add X to the constraints network, and initialize 25 Source(X) and Destination(X) to contain X. Go to Step 1.
iii.
Add the given constraint Ai→Bj to the constraints network.
iv.
Update Source (Ai) and Destination (Bj) as follows: for each X ⋲ Source (Ai) and for each Y ⋲ Destination (Bj), add Y to Destination(X) and add X to Source(Y). 30
B.
If the new constraint is Ai→~Bj
20
i.
If nodes Ai and ~Bj are present in the constraints network
a.
For any node X ⋲ Source(Ai), and any node Y ⋲ Destination(~Bj), if Destination(X) contains both Y and ~Y, then discard the constraint and go to step 1.
b.
For any node X ⋲ Source(Ai), and any node Yk,Yl ⋲ 5 Destination(~Bj) such that k ≠ l and Yk, Yl belong to the same feature family, if Destination(X) contains both Yk and Yl, then discard the constraint and go to Step 1.
ii.
Else for each X ⋲ {Ai, ~Bj} that is not present in the 10 constraints network, add X to the constraints network, and initialize Source(X) and Destination(X) to contain X. Go to Step 1.
iii.
Add the constraint Ai→~Bj to the constraints network.
iv.
Update Source(Ai) and Destination(~Bj) as follows: for 15 each X ⋲ Source(Ai) and for each Y ⋲ Destination(~Bj), add Y to Destination(X) and add X to Source(Y).
C.
If the new constraint is Ai→Bj ∨ Bk
i.
If the nodes Ai, Bj, and Bk are present in the constraints network 20
a.
For any node X ⋲ Source(Ai), and any node Y ⋲ Destination(Bj) ⋂ Destination(Bk), ), if Destination(X) contains both Y and ~Y, then discard the constraint and go to Step 1.
b.
For any node X ⋲ Source(Ai), and any node Yp,Yq ⋲ 25 Destination(Bj) ⋂ Destination(Bk) such that p ≠ q and Yp, Yq belong to the same feature family, if Destination(X) contains both Yp and Yq, then discard the constraint and go to Step 1.
ii.
Else for each X ⋲ {Ai, Bj,Bk} that is not present in the 30 constraints network, add X to the constraints network, and
21
initialize
Source(X) and Destination(X) to contain X. Go to Step 1.
iii.
Add the constraint Ai→Bj ∨ Bk to the constraints network.
iv.
Update Source(Ai), Destination(Ai), Source(Bj), Destination(Bj), Source(Bk) and Destination(Bk) as 5 follows: for each X ⋲ Source(Ai) and for each Y ⋲ Destination(Bj) ⋂ Destination(Bk), add Y to Destination(X) and add X to Source(Y).
[037]
The constraints validation unit 202 further includes a take rate constraints validation unit 202B. The take rate constraints validation unit 202B is 10 configured to validate the take rate constraints based on the validated set of configuration constraints. The take rate constraints validation unit 202B is configured to model each take rate constraint for each feature variant as a real interval that represents (a) a minimum take rate value, and (b) a maximum take rate value, for the given feature variant. The take rate constraints validation unit 202B 15 is configured to scan one take rate constraint from the given set of take rate constraints, at a time. The take rate interval from a given take rate constraint is updated based on the previously validated set of constraints. The constraints network 204 is updated, if the given take rate constraint is consistent with the previously validated set of constraints, or else the given take rate constraint is 20 discarded. In an embodiment, each consistent take rate constraint is added to obtain the valid set of take rate constraints and corresponding effect is propagated to the constraints network 204. In an embodiment, before addition of any take rate constraint, the following conditions are evaluated to determine the consistency of the constraints: (a) for any constraint Ai→Bj in the constraints network 204, if 25 minTR(Ai)> minTR(Bj) and maxTR(Ai) > maxTR(Bj) then there is a conflict, and (b) For any constraint Ai→Bj, ∨Bk in the constraints network 204, if minTR(Ai) > maxTR(Bj)+ maxTR(Bk), then there is a conflict. Further, after the validation step, the following conditions are satisfied: (a) for each constraint Ai→Bj in the constraints network 204, minTR(Ai) ≤ minTR(Bj) and maxTR(Ai) ≤ maxTR(Bj), (b) 30
22
f
or each constraint Ai→Bj, ∨ Bk in the constraints network 204, minTR(Ai) ≤ maxTR(Bj) + maxTR(Bk).
[038]
Before the take rate validation step begins, initially, for each feature variant Ai, default values of minTR(Ai) and maxTR(Ai) are set as 0 and 1 respectively. As the take rate constraints are added, the values are updated 5 accordingly. Further, after addition of each take rate constraint, consequent effect is propagated to all those nodes that are connected with the given node (i.e., associated with the given constraint that is being added) in a transitive manner. Given the constraints network 204, the take rate interval of each feature variant Ai, modelled as [minTR(Ai), maxTR(Ai)] needs to be validated. Firstly, any new take 10 rate interval of Ai can be added only if the given interval is a sub-interval of the current take rate interval of Ai. Next, if for any Bj ⋲ Destination (Ai), if minTR(Bj) < minTR(Ai) and maxTR(Bj)< maxTR(Ai), then reject the given constraint as this constraint is not consistent with the existing constraints. Similarly, if for any Ck ⋲ Source (Ai), if minTR(Ai) < minTR(Ck) and maxTR(Ai) < maxTR(Ck), then reject the 15 given constraint. If both these conditions are false, then the constraint is valid and thus added to the valid set of constraints.
[039]
Once a take rate constraint is added, corresponding effect is propagated to the constraints network 204. For each Bj ⋲ Destination (Ai), if minTR(Bj)< minTR(Ai), then minTR(Bj) is updated as: minTR(Bj) ← minTR(Ai). 20 Similarly, if maxTR(Bj)< maxTR(Ai), then maxTR(Ai) is updated as: maxTR(Ai) ← maxTR(Bj). In a similar manner, for each Ck⋲ Source (Ai), if minTR(Ai)< minTR(Ck), then minTR(Ai) is updated as: minTR(Ai)← minTR(Ck). And finally, if maxTR(Ai)< maxTR(Ck), then maxTR(Ck) is updated as: maxTR(Ck)← maxTR(Ai). Since the given constraint is already validated, the propagation step does not lead 25 to any feature variant having an empty take rate interval.
Round
Input constraint
Validated/
Discarded
A1
B1
C1
D1
E1
F1
F2
23
0
Initial cond.
-
[0,1]
[0,1]
[0,1]
[0,1]
[0,1]
[0,1]
[0,1]
1
C1: [0.3,0.6]
Validated
[0,0.6]
[0,0.6]
[0.3,0.6]
[0.3,1]
[0,1]
[0,1]
[0,1]
2
A1: [0.2,0.5]
Validated
[0.2,0.5]
[0.2,0.6]
[0.3,0.6]
[0.3,1]
[0.2,1]
[0,1]
[0,1]
3
B1: [0.4,0.7]
Discarded
[0.2,0.5]
[0.2,0.6]
[0.3,0.6]
[0.3,1]
[0.2,1]
[0,1]
[0,1]
4
D1: [0.4,0.7]
Validated
[0.2,0.5]
[0.2,0.6]
[0.3,0.6]
[0.4,0.7]
[0.2,1]
[0,1]
[0,1]
TABLE 1
[040]
In an exemplary embodiment, the take rate validation for the constraints network 204 shown in FIG. 4, is given in TABLE 1. Assuming that the set of configuration constraints is already validated. Starting from round 0, proceeding till round 4, where in each round, one take rate constraint is validated 5 as given in column 2 of the TABLE 1. In column 2, a take rate constraint is specified as a feature variant, followed by the corresponding take rate interval. As a result of addition of one new take rate constraint in each round, the consequent updated take rate intervals of all the feature variants in the network are also shown in TABLE 1, for each round. For example, in round 1, the take rate constraint of C1 is validated 10 and added. Consequently, the take rate intervals of A1, B1 and D1 get updated, as shown in TABLE 1 alongside the round 1. In the next round, the take rate interval of A1 is validated and added. In the subsequent round, the take rate interval of B1 is processed but found to be inconsistent because the given interval [0.4,0.7] is not a sub-interval of current take rate interval of B1, i.e., [0.2,0.6]]. Finally, the take rate 15 interval of D1 is validated and added to the constraints network 204.
24
[041]
The constraints validation unit 202 further includes an availability constraints validation unit 202C. The availability constraints validation unit 202C is configured to validate the set of availability constraints based on the validated set of take rate constraints. The availability constraints validation unit 202C is configured to model the availability constraint for each feature variant as a real 5 interval that represents (a) a minimum availability value, and (b) a maximum availability value, for a given feature variant. The availability constraints validation unit 202C is configured to determine, the validity of each availability constraint from the given set of availability constraints by checking if the minimum availability value, and the maximum availability value are sufficient to 10 accommodate the minimum take rate value, and the maximum take rate value of the corresponding feature variant. The availability constraints validation unit 202C is configured to add the set of valid availability constraints to the constraints network 204. In an embodiment, each availability constraint that is found to be inconsistent with the previously validated set of constraints is discarded. 15
[042]
In an embodiment, for each feature variant Ai, there is an associated availability constraint, specified by an interval [ minA(Ai), maxA(Ai)]. The availability constraints are also processed one at a time and if a constraint is found to be valid, then the constraint is added to the constraints network 204, else the constraint is discarded. Once the take rate constraints are validated, for each feature 20 variant Ai, the availability validation unit 202C is configured to check whether the minimum and the maximum availability values are sufficient to accommodate the minimum and the maximum take rate values, respectively. More formally, for viability of feature variant Ai, the following condition is necessary to hold: minA(Ai)≥ minTR(Ai) and maxA(Ai)≥ maxTR(Ai). 25
[043]
If this is not the case, then the corresponding inconsistent availability constraint is discarded, and corresponding corrective availability interval is recommended. For example, if the take rate constraint of a particular feature variant is [0.2,0.4], and the availability constraint of the corresponding feature variant is [0.1,0.3], then the availability constraint is discarded and following corrective 30 availability constraint is recommended: [a1, a2], where 0.2 ≤ a1 and 0.4 ≤ a2.
25
Round
Input constraint
Validated/
Discarded
A1
B1
C1
D1
E1
F1
F2
0
Initial cond.
-
[0.2,0.5]
[0.2,0.6]
[0.3,0.6]
[0.4,0.7]
[0.2,1]
[0,1]
[0,1]
1
C1: [0.5,0.7]
Validated
[0.2,0.5]
[0.2,0.6]
[0.5,0.7]
[0.4,0.7]
[0.2,1]
[0,1]
[0,1]
2
A1: [0.2,0.6]
Validated
[0.2,0.6]
[0.2,0.6]
[0.5,0.7]
[0.4,0.7]
[0.2,1]
[0,1]
[0,1]
3
B1: [0.2,0.5]
Discarded
[0.2,0.6]
[0.2,0.6]
[0.5,0.7]
[0.4,0.7]
[0.2,1]
[0,1]
[0,1]
4
E1: [0.1,0.7]
Discarded
[0.2,0.6]
[0.2,0.6]
[0.5,0.7]
[0.4,0.7]
[0.2,1]
[0,1]
[0,1]
TABLE 2
[044]
In an exemplary embodiment, the TABLE 2 shows validation of the availability constraints for the constraints network shown in FIG. 4, and the take rate validation shown in TABLE 1. The availability constraints are specified in column 2 in the same manner as the take rate constraints are specified in TABLE 5 1, i.e., feature variant followed by corresponding availability constraint. The initial availability interval for each feature variant is same as the final take rate interval as returned after the take rate validation phase, shown in TABLE 1. This is because the minimum and the maximum availability must be at least the minimum and the maximum take rate, respectively. TABLE 2 shows that if the above condition is 10 satisfied, the corresponding availability constraint is accepted, or else discarded.
[045]
The constraints updation unit 206 is configured to update the constraints network 204 with an updated valid product configuration scenario that
26
corresponds to
a valid set of updated constraints based on either (a) addition of one or more new configuration constraints, or (b) modification of the existing production constraints, and combination thereof. The set of constraints are considered to be valid if they do not render any feature variant of the product as unviable. The constraints updation unit 206 adds a new configuration constraint in 5 exactly same manner as the constraints validation unit 202 validates any configuration constraint. In an embodiment, while modifying an existing take rate constraint, a new take rate interval is allowed only if the new take rate interval is a sub-interval of the existing take rate interval.
[046]
FIG. 5A through FIG. 5C are exemplary flow diagrams illustrating 10 a method of validating one or more constraints to obtain the validated product configuration scenario (T) with the valid set of constraints, according to an embodiment of the present disclosure. In an embodiment, the system 100 comprises one or more data storage devices or the memory 104 operatively coupled to the one or more hardware processors 102 and is configured to store instructions for 15 execution of steps of the method by the one or more processors 102. The flow diagram depicted is better understood by way of following explanation/description. The steps of the method of the present disclosure will now be explained with reference to the components of the system as depicted in FIGS. 1, 2A, and 2B.
[047]
At step 502, a product configuration scenario (S) associated with a 20 product is received as an input. The product configuration scenario (S) associated with the product includes: (a) the set of feature families, (b) the set of configuration constraints, and (c) the set of production constraints. Each feature family from the set of feature families includes one or more feature variants. Each configuration constraint from the set of configuration constraints is modeled as a logical clause 25 of premise and implication between two or more feature variants. The set of production constraints corresponds to: (a) the set of take rate constraint, and (b) the set of availability constraint, for each feature variant of the product. At step 504, the constraints network 204 is generated to obtain the valid product configuration scenario (T) by validation of: (a) the set of configuration constraints, (b) the set of 30 take rate constraints, and (c) the set of availability constraints in a sequential order.
27
The
valid product configuration scenario (T) includes the valid set of constraints such that each feature variant remains viable.
[048]
The validation of the set of configuration constraints includes the following steps. At step 504A, the constraints network 204 is generated that includes two nodes for each feature variant. The two nodes for each feature variant 5 correspond to: (i) the positive node, and (ii) the negative node. At step 504B, two lists for each node are generated. The two lists for each node correspond to: (i) the source list, and (ii) the destination list. The source list of a given node corresponds to a set of nodes that lead to the given node through a directed path in the constraints network 204. The destination list of a given node corresponds to a set of nodes that 10 are reachable from the given node through a directed path in the constraints network 204. Each source list and each destination list are updated after validation of each configuration constraint. At step 504C, one configuration constraint from the given set of configuration constraints is processed at a time. At step 504D, whether the given configuration constraint is consistent with a previously validated set of 15 constraints is determined by computing transitive closure over the set of configuration constraints by employing the source list, and the destination list of each node in the constraints network 204. At step 504E, the constraints network 204 is updated if the given configuration constraint is consistent with the previously validated set of constraints, or else the given configuration constraint is discarded. 20
[049]
The validation of the set of take rate constraints includes the following steps. At step 504F, one take rate constraint associated with each feature variant of the product is modelled as a real interval, that represents (i) a minimum take rate value, and (ii) a maximum take rate value, for the given feature variant. At step 504G, one take rate constraint from the given set of take rate constraints is 25 processed at a time. At step 504H, the take rate interval of the given take rate constraint is updated based on the previously validated set of constraints. At step 504I, the constraints network 204 is updated if the given take rate constraint is consistent with the previously validated set of constraints, or else the given take rate constraint is discarded. 30
28
[050]
The set of availability constraints is validated based on the validated set of take rate constraints. The validation of the set of availability constraints includes the following steps. At step 504J, one availability constraint associated with each feature variant of the product is modelled as a real interval, that represents (i) a minimum availability value, and (ii) a maximum availability value, for the 5 given feature variant. At step 504K, the validity of each availability constraint from the given set of availability constraints is determined by checking if the minimum availability value, and the maximum availability value are sufficient to accommodate the minimum take rate value, and the maximum take rate value of the corresponding feature variant. At step 504L, the valid set of availability 10 constraints is added to the constraints network 204. Each availability constraint that is found to be inconsistent with the previously validated set of constraints is discarded.
[051]
At step 506, the constraints network 204 is updated with an updated valid product configuration scenario that includes a valid set of updated constraints 15 based on at least one of: (a) addition of one or more new configuration constraints, or (b) modification of the existing production constraints. The set of constraints are considered to be valid if they do not render any feature variant of the product as unviable.
[052]
The embodiments of present disclosure herein addresses the 20 unresolved problem of validation of configuration constraints and production constraints that arise in product planning and manufacturing. The embodiment thus provides a framework which efficiently validates, and updates a given set of configuration constraints and production constraints. The embodiment herein thus provides the constraints network based constraint validation approach that returns 25 a set of non-conflicting constraints by pruning away any conflicting constraints that render any feature variant as unviable. The constraints network is built by employing one or more techniques such as transitive closure, reachability testing and constraint propagation for analyzing the consistency of the constraints. Given a set of input constraints, the output is a maximal valid set of consistent constraints 30 that ensures each feature variant remains viable, which is generated by pruning
29
away the
set of inconsistent constraints. The proposed framework does one shot validation of constraints for feature viability, and further allows continuous updation of the constraints, still avoiding conflicting constraints.
[053]
The proposed framework can efficiently handle addition of new configuration constraints, as well as changes to the existing set of production 5 constraints. The updation is performed in a manner that always ensures that the constraints network remains consistent after each update. The embodiment herein allows both validation and updation of constraints in any order which allows a flexibility to input the constraints in any user-defined order. For example, a user may input the constraints in a prioritized manner. Since the validation step 10 processes the constraints in an incremental manner, i.e., one at a time, which ensures that higher priority constraints are validated before a lower priority constraints. Consequently, if a constraint is found to be inconsistent, the constraint is likely to be a lower priority constraint. The algorithm used in the proposed constraints validation offers a high performance both in terms of a running time and a memory 15 footprint. The proposed constraints validation helps in better planning of product variant configurations and production volumes, which in turn, can lead to potential business gains.
[054]
The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the 20 subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims. 25
[055]
It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device 30 can be any kind of device which can be programmed including e.g., any kind of
30
computer like a server or a personal computer, or the like, or any combination
thereof. The device may also include means which could be e.g., hardware means like e.g., an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g., an ASIC and an FPGA, or at least one microprocessor and at least one memory with software 5 processing components located therein. Thus, the means can include both hardware means, and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g., using a plurality of CPUs. 10
[056]
The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various components described herein may be implemented in other components or combinations of other components. For the purposes of this description, a 15 computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[057]
The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological 20 development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are 25 appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are 30 intended to be equivalent in meaning and be open ended in that an item or items
31
following any one of these words is not meant to be an exhaustive listing of such
item or items or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[058]
Furthermore, one or more computer-readable storage media may be 5 utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or 10 stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any 15 other known physical storage media.
[059]
It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.We Claim:
1. A processor implemented method (500), comprising:
receiving (502), via one or more hardware processors, a product configuration scenario (S) associated with a product, as an input, wherein the product configuration scenario (S) associated with the product, comprises: (a) a set of feature families, (b) a set of configuration constraints, and (c) a set of production constraints, wherein each feature family from the set of feature families comprises one or more feature variants, wherein each configuration constraint from the set of configuration constraints is modeled as a logical clause of premise and implication comprising two or more feature variants, and wherein the set of production constraints corresponds to: (a) a set of take rate constraints, and (b) a set of availability constraints, for each feature variant of the product;
generating (504), via the one or more hardware processors, a constraints network (204) to obtain a valid product configuration scenario (T) by validation of: (a) the set of configuration constraints, (b) the set of take rate constraints, and (c) the set of availability constraints in a sequential order, and wherein the valid product configuration scenario (T) comprises a valid set of constraints; and
updating (506), via the one or more hardware processors, the constraints network (204) with an updated valid product configuration scenario comprising a valid set of updated constraints based on at least one of: (a) addition of one or more new configuration constraints, or (b) modification of the existing production constraints, and wherein a set of constraints is considered to be valid if they do not render any feature variant of the product as unviable.
2. The processor implemented method (500) as claimed in claim 1, wherein
the step of validation of the set of configuration constraints comprises:
(a) generating (504A), via the one or more hardware processors, the constraints network (204) comprising nodes for each feature variant, and wherein the two nodes for each feature variant correspond to: (i) a positive node, and (ii) a negative node;

(b) generating (504B), via the one or more hardware processors, two lists
for each node in the constraints network (204), wherein the two lists for each node
correspond to: (i) a source list, and (ii) a destination list;
(c) processing (504C), via the one or more hardware processors, one configuration constraint from the given set of configuration constraints, at a time;
(d) determining (504D), via the one or more hardware processors, if the given configuration constraint is consistent with the previously validated set of constraints by computing transitive closure over the set of configuration constraints by employing the source list, and the destination list of each node in the constraints network (204); and
(e) updating (504E), via the one or more hardware processors, the
constraints network (204) if the given configuration constraint is consistent with the
previously validated set of constraints, or else the given configuration constraint is
discarded.
3. The processor implemented method (500) as claimed in claim 2, wherein the source list of a given node corresponds to a set of nodes that lead to the given node through a directed path in the constraints network (204), wherein the destination list of a given node corresponds to a set of nodes that are reachable from the given node through a directed path in the constraints network (204), and wherein each source list and each destination list are updated after validation of each configuration constraint.
4. The processor implemented method (500) as claimed in claim 1, wherein the step of validation of the set of take rate constraints comprises:

(a) modelling (504F), via the one or more hardware processors, one take rate constraint associated with each feature variant of the product, as a real interval, that represents (i) a minimum take rate value, and (ii) a maximum take rate value, for the given feature variant;
(b) processing (504G), via the one or more hardware processors, one take rate constraint from the given set of take rate constraints, at a time;

(c) updating (504H), via the one or more hardware processors, the take rate interval of the given take rate constraint based on the previously validated set of constraints; and
(d) updating (504I), via the one or more hardware processors, the constraints network (204) if the given take rate constraint is consistent with the previously validated set of constraints, or else the given take rate constraint is discarded.
5. The processor implemented method (500) as claimed in claim 1, wherein
the set of availability constraints is validated based on the validated take rate
constraints, wherein the step of validation of the set of availability constraints
comprises:
(a) modelling (504J), via the one or more hardware processors, one availability constraint associated with each feature variant of the product, as a real interval, that represents (i) a minimum availability value, and (ii) a maximum availability value, for the given feature variant;
(b) determining (504K), via the one or more hardware processors, the validity of each availability constraint from the given set of availability constraints by checking if the minimum availability value, and the maximum availability value are sufficient to accommodate the minimum take rate value, and the maximum take rate value of the corresponding feature variant; and
(c) adding (504L), via the one or more hardware processors, the valid set of
availability constraints to the constraints network (204), and wherein each
availability constraint that is found to be inconsistent with the previously validated
set of constraints is discarded.
6. A system (100), comprising:
a memory (104) storing instructions;
one or more communication interfaces (106); and
one or more hardware processors (102) coupled to the memory (104) via the one or more communication interfaces (106), wherein the one or more hardware processors (102) is configured by the instructions to:

receive a product configuration scenario (S) associated with a product, as an input, wherein the product configuration scenario (S) associated with the product, comprises: (a) a set of feature families, (b) a set of configuration constraints, and (c) a set of production constraints, wherein each feature family from the set of feature families comprises one or more feature variants, wherein each configuration constraint from the set of configuration constraints is modeled as a logical clause of premise and implication comprising two or more feature variants, and wherein the set of production constraints corresponds to: (a) a set of take rate constraints, and (b) a set of availability constraints, for each feature variant of the product;
generate a constraints network (204) to obtain a valid product configuration scenario (T) by validation of: (a) the configuration constraint, (b) the set of take rate constraints, and (c) the set of availability constraints in a sequential order, and wherein the valid product configuration scenario (T) comprises a valid set of constraints; and
update the constraints network (204) with an updated valid product configuration scenario comprising a valid set of updated constraints based on at least one of: (a) addition of one or more new configuration constraints, or (b) modification of the existing production constraints, and wherein a set of constraints is considered to be valid if they do not render any feature variant of the product as unviable.
7. The system (100) as claimed in claim 6, wherein the one or more hardware
processors (102) is configured by the instructions to validate the set of configuration constraints, comprises:
(a) generate the constraints network (204) comprising two nodes for each feature variant, and wherein the two nodes for each feature variant correspond to: (i) a positive node, and (ii) a negative node;
(b) generate two lists for each node, wherein the two lists for each node in the constraints network (204) correspond to: (i) a source list, and (ii) a destination list;

(c) process one configuration constraint from the given set of configuration
constraints, at a time;
(d) determine if the given configuration constraint is consistent with the
previously validated set of constraints by computing transitive closure over the set
of configuration constraints by employing the source list, and the destination list of
each node in the constraints network (204); and
(e) update the constraints network (204) if the given configuration constraint
is consistent with the previously validated set of constraints, or else the given
configuration constraint is discarded.
8. The system (100) as claimed in claim 7, wherein the source list of a given node corresponds to a set of nodes that lead to the given node through a directed path in the constraints network (204), wherein the destination list of a given node corresponds to a set of nodes that are reachable from the given node through a directed path in the constraints network (204), and wherein each source list and each destination list are updated after validation of each configuration constraint.
9. The system (100) as claimed in claim 6, wherein the one or more hardware processors (102) are configured by the instructions to validate the set of take rate constraints, comprises:
(a) model one take rate constraint associated with each feature variant of the
product, as a real interval, that represents (i) a minimum take rate value, and (ii) a
maximum take rate value, for the given feature variant;
(b) process one take rate constraint from the given set of take rate
constraints, at a time;
(c) update the take rate interval of the given take rate constraint based on the previously validated set of constraints; and
(d) update the constraints network (204) if the given take rate constraint is consistent with the previously validated set of constraints, or else the given take rate constraint is discarded.

10. The system (100) as claimed in claim 6, wherein the one or more hardware
processors (102) is configured by the instructions to validate the set of availability constraints based on the validated set of take rate constraints, comprises:
(a) model one availability constraint associated with each feature variant of the product, as a real interval, that represents (i) a minimum availability value, and (ii) a maximum availability value, for the given feature variant;
(b) determine the validity of each availability constraint from the given set of availability constraints by checking if the minimum availability value, and the maximum availability value are sufficient to accommodate the minimum take rate value, and the maximum take rate value of the corresponding feature variant; and
(c) add the valid set of availability constraints to the constraints network (204), and wherein each availability constraint that is found to be inconsistent with the previously validated set of constraints is discarded.