Description:
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 EVALUVATING LOCAL CONSISTENCY FOR PRODUCT CONFIGURATION SCENARIOS

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.
TECHNICAL FIELD
The disclosure herein generally relates to production planning, and, more particularly, to method and system for evaluating local consistency for product configuration scenarios.
BACKGROUND
Product planning is an important process in which strategic decisions are made to determine optimal product strategy, resource allocation, and volume mix to meet customer requirements and organizational goals. This encompasses comprehensive analysis of what products needs to be produced when and in what quantities. One of the most consistent challenges in business is predicting what future holds and impact it may have on current product plans . Product scenario planning provides cross impact analysis of today’s decisions in future production systems for organizations involved in the product planning processes.
Conventional scenario technique predicts multiple future growth trajectories at the strategic level of an organization. This generates multiple future predictions systematically considering various influential factors and disruptions. The result is a number of equally valid future developments consistent in their explanatory product plans or updates thereof. However, existing techniques lack the ability to provide a universal relationship between fundamental elements of production system appropriate for future predictions within the scope of product planning.
Planning of product offerings continues to be a challenge for manufacturers because of the underlying scale, complexity and uncertainty of supply and demand. Planners need to consider multiple scenarios that consider factors such as portfolio of product offerings, expected demands, availability of the parts, user preferences of features, engineering constraints among the features, production constraints, production volumes and production costs, to name a few. Moreover, as business requirements change, the manufacturers need to regularly transform their product offerings. This requires effective and efficient planning of product offerings.
SUMMARY
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 embodiment, a method for evaluating local consistency for product configuration scenarios is provided. The method includes receiving a product configuration scenario for product planning that includes a plurality of product feature families, and at least one of the following: a plurality of configuration constraints and a plurality of production constraints. Here, each product feature family among the plurality of product feature families comprise a plurality of feature variants. The plurality of configuration constraints represents one or more logical associations among the plurality of feature variants of two or more product feature families, and the plurality of production constraints comprises a take rate constraint and an availability constraint for each feature variant of the product. Firstly, a plurality of transitively closed configuration constraints is determined by analyzing the transitive dependencies among the plurality of configuration constraints.
Further, the plurality of transitively closed configuration constraints is determined by analyzing the transitive dependencies among the given plurality of configuration constraints. Following this, each product feature family is mapped to a discrete variable whose domain is the plurality of feature variants of the corresponding product feature family. Subsequently, those feature variants that are inconsistent with the previously computed plurality of transitively closed configuration constraints are identified and pruned. Then the plurality of transitively closed configuration constraints and the plurality of production constraints are mapped to an equivalent plurality of feature compatibility constraints that specify the compatibility among the feature variants of two or more feature families. Finally, the local consistency is evaluated for the product configuration scenario by pruning the feature variants that are locally inconsistent with the previously computed feature compatibility constraints.
In another aspect, a system for evaluating local consistency for product configuration scenarios is provided. The system includes receiving a product configuration scenario for planning the product variants that includes a plurality of product feature families, and at least one of the following: a plurality of configuration constraints and a plurality of production constraints. Here, each product feature family among the plurality of product feature families comprise a plurality of feature variants. The plurality of configuration constraints represents one or more logical associations among the plurality of feature variants of two or more product feature families, and the plurality of production constraints comprises a take rate constraint and an availability constraint for each feature variant of the product. Further, a plurality of transitively closed configuration constraints is determined by analyzing the transitive dependencies among the plurality of configuration constraints.
Further, the plurality of transitively closed configuration constraints is determined by analyzing the transitive dependencies among the given plurality of configuration constraints. Following this, each product feature family is mapped to a discrete variable whose domain is the plurality of feature variants of the corresponding product feature family. Subsequently, those feature variants that are inconsistent with the previously computed plurality of transitively closed configuration constraints are identified and pruned. Then the plurality of transitively closed configuration constraints and the plurality of production constraints are mapped to an equivalent plurality of feature compatibility constraints that specify the compatibility among the feature variants of two or more feature families. Finally, the local consistency is evaluated for the product configuration scenario by pruning the feature variants that are locally inconsistent with the previously computed feature compatibility constraints.
In yet another aspect, a non-transitory computer readable medium for evaluating local consistency of product configuration scenarios is provided. The system includes receiving a product configuration scenario for planning the product variants that includes a plurality of product feature families, and at least one of the following: a plurality of configuration constraints and a plurality of production constraints. Here, each product feature family among the plurality of product feature families comprise a plurality of feature variants. The plurality of configuration constraints represents one or more logical associations among the plurality of feature variants of two or more product feature families, and the plurality of production constraints comprises a take rate constraint and an availability constraint for each feature variant of the product. Further, a plurality of transitively closed configuration constraints is determined by analyzing the transitive dependencies among the plurality of configuration constraints.
Further, the plurality of transitively closed configuration constraints is determined by analyzing the transitive dependencies among the given plurality of configuration constraints. Following this, each product feature family is mapped to a discrete variable whose domain is the plurality of feature variants of the corresponding product feature family. Subsequently, those feature variants that are inconsistent with the previously computed plurality of transitively closed configuration constraints are identified and pruned. Then the plurality of transitively closed configuration constraints and the plurality of production constraints are mapped to an equivalent plurality of feature compatibility constraints that specify the compatibility among the feature variants of two or more feature families. Finally, the local consistency is evaluated for the product configuration scenario by pruning the feature variants that are locally inconsistent with the previously computed feature compatibility constraints.
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.
BRIEF DESCRIPTION OF THE DRAWINGS
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:
FIG.1 illustrates an exemplary system for evaluating local consistency according to some embodiments of the present disclosure.
FIG.2 is a functional block diagram of an example system for configuring production scenarios using the system of FIG.1, in accordance with some embodiments of the present disclosure.
FIG.3 is a flow diagram illustrating example process of evaluating local consistency for configuring production scenarios using the system of FIG.1, in accordance with some embodiments of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS
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 described herein, modifications, adaptations, and other implementations are possible without departing from the scope of the disclosed embodiments.
Product planning is vital for any manufacturing process. It requires a holistic approach that considers various aspects of the manufacturing process, such as planning, agility, technology adoption, supply chain collaboration, continuous improvement, human capital development and the like. When implemented correctly, product planning strategies can help manufacturers to improve their operations, decrease production costs, increase customer satisfaction, and maintain a competitive advantage.
In product planning and manufacturing, one of the most difficult challenges is to determine the key product variants and their required production volumes. Such product variants often have to comply with several configuration and production constraints. As part of product planning for one or more new product variants, manufacturers need to execute one or more configuration scenario(s). Each scenario has its own set of configuration constraints, production constraints, and range of available features. However, solving the given set of constraints of a configuration scenario is challenging and often requires large computational resources, both in terms of time and capacity. Typically, there are many constraint solvers that can be used to solve such a configuration scenario problem. However, they can take several hours to provide a single solution, which is a major computing bottleneck that impedes efficient and effective planning of product offerings.
In addition, existing approaches do not provide much insight into why the configuration scenario is not feasible, whether there are conflicting constraints, and how they impact feature viability. The planning scenario described above is extremely difficult to solve in general because it is a generalization of the boolean satisfiability problem which is a well-known computationally hard problem. Therefore, when the size of the problem is large, any constraint solution requires prohibitively large computational time and space.
Furthermore, existing approaches typically rely on one or more of the following approaches such as exhaustive search, backtracking constraint propagation, local search, and the like. Each of these approaches are dependent on size of the feasible space which in turn is dependent on the number of feature variants in each product feature family. Therefore, pruning the feasible space is the best way to reduce the search space. Pruning the solution space directly reduces the amount of computational time and memory required. In the present disclosure, several such pruning strategies are evaluated to address the problem of local consistency for product configuration scenarios that arise in product planning and manufacturing.
Embodiments herein provide a method and system for evaluating local consistency for product configuration scenarios. The method of the present disclosure enables evaluating local consistency for a given product to be configured in production planning having at least one scenario. A typical product configuration scenario includes a plurality of product feature families, a plurality of configuration constraints and a plurality of production constraints. Each product feature family includes a plurality of product feature variants that can be installed in a product variant. The method of the present disclosure prunes out the feature variants that are locally inconsistent with respect to the given set of constraints. Further, the method determines if the given product configuration scenario is infeasible due to the presence of locally inconsistent feature variants. The most important benefit of the present disclosure is reduced computational overhead, which enables execution of more configuration scenarios resulting in better product planning and potential business gains. The disclosed system is further explained with the method as described in conjunction with FIG.1 to FIG.3 below.
GLOSSARY :
Product planning provides a plan to manufactures for development of a new product with its product variants along with their feature configurations and production volumes.
Product configuration scenario provides inputs necessary for product planning for developing the product with one or more different configurations.
Product variants refers to one or more variants of the given product.
Feature variant refers to a particular variant of the given product feature family.
Product feature family refers to a feature of the given product that comprises a plurality of feature variants of the corresponding feature.
Configuration constraint represents logical association among feature variants of two or more product feature families.
Production constraint is a constraint that specifies the take rate constraint and the availability constraint imposed on each feature variant of the product.
Take rate constraint is a constraint that specifies a lower bound and an upper bound on the take rate of a given feature variant, that in turn indicates the fraction of the total production volume of the given product that demands the given feature variant.
Availability constraint is a constraint that specifies a lower bound and an upper bound on the availability of a given feature variant, that in turn indicates the fraction of the total production volume of the given product for which the given feature variant is available.
Referring to the drawings, and more particularly to FIG.1 through FIG.3, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments, and these embodiments are described in the context of the following exemplary system and/or method.
FIG.1 illustrates an exemplary system for evaluating local consistency according to some embodiments of the present disclosure. Referring to the components of the system 100, in an embodiment, the processor (s) 104 can be one or more hardware processors 104. In an embodiment, one or more hardware processors 104 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 instructions. Among other capabilities, the processor(s) 104 is configured to fetch and execute computer-readable instructions stored in the memory. 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.
The I/O interface(s) 106 can include a variety of software and hardware interfaces, for example, a web interface, a graphical subject interface, and the like and can facilitate multiple communications within a wide variety of networks N/W and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface (s) 106 can include one or more ports for connecting a number of devices (nodes) of the system 100 to one another or to another server.
The memory 102 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 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 102 includes a plurality of modules 108 can also include various sub-modules as depicted in FIG.2, such as a transitive closure 202, a domain validator 204, a feature compatibility analyzer 206, and local consistency evaluator 208. The plurality of modules 108 include programs or coded instructions that supplement applications or functions performed by the system 100 for executing different steps involved in the process of evaluating local consistency of the system 100. The plurality of modules 108, amongst other things, can include routines, programs, objects, components, and data structures, which performs particular tasks or implement particular abstract data types. The plurality of modules 108 may also be used as, signal processor(s), node machine(s), logic circuitries, and/or any other device or component that manipulates signals based on operational instructions. Further, the plurality of modules 108 can be used by hardware, by computer-readable instructions executed by the one or more hardware processors 104, or by a combination thereof.
The memory 102 may comprise information pertaining to input(s)/output(s) of each step performed by the processor(s) 104 of the system 100 and methods of the present disclosure. Functions of the components of system 100, for identifying malicious agent while handling subject request having at least one sensitive attribute, are explained in conjunction with FIG.2 and FIG.3 providing flow diagram, architectural overviews, and performance analysis of the system 100.
FIG.2 is a functional block diagram of an example system for configuring production scenarios using the system of FIG.1, in accordance with some embodiments of the present disclosure. The system 200 may be an example 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 transitive closure 202, a domain validator 204, a feature compatibility analyzer 206, and a local consistency evaluator 208.
The transitive closure 202 of the system 100 receives a product configuration scenario for product planning that includes a plurality of product feature families, and at least one of the following: a plurality of configuration constraints and a plurality of production constraints as input.
During production planning for the product, the manufacturer(s) typically considers one or more configuration scenarios. In the given product configuration scenario, a product variant may comprise a plurality of feature variants {A_i,B_j,C_k,…} where one feature variant is chosen from each product feature family. The product variant is considered feasible when corresponding feature variants satisfy all the constraints imposed on them. The solution to the above product configuration scenario consists of one or more feasible product variants. For the received input the transitive closure 202 of the system 200 computes a plurality of transitively closed configuration constraints.
The domain validator 204 of the system 200 prunes those feature variants that conflict with the plurality of transitively closed configuration constraints, computed in the previous step. Further, to map the product configuration scenario problem to an equivalent constraint satisfaction (CSP) problem, the domain validator 204 generates a required set of discrete variables with their respective domains.
The feature compatibility analyzer 206 identifies the compatibility between the feature variants of two or more product feature families of the given product configuration scenario.
The local consistency evaluator 208 of the system 200 obtains local consistency over the plurality of product feature families. The local consistency evaluator 208 discards infeasible feature variants that are locally inconsistent with the underlying compatibility constraints. Here, if any product feature family runs out of all its feature variants, then the given product configuration scenario is deemed infeasible.
FIG.3 is a flow diagram illustrating example process of evaluating local consistency for configuring production scenarios using the system of FIG.1, in accordance with some embodiments of the present disclosure.
In an embodiment, the system 100 comprises one or more data storage devices or the memory 102 operatively coupled to the processor(s) 104 and is configured to store instructions for execution of steps of a method 300 by the processor(s) or one or more hardware processors 104. The steps of the method 300 of the present disclosure will be explained next with reference to the components or blocks of the system 100 as depicted in FIG.1 through FIG.2, and the steps of flow diagram as depicted in FIG.3. Although process steps, method steps, techniques or the like may be described in a sequential order, such processes, methods, and techniques may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps to be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously.
Referring to the steps of the method 300, at step 302 a one or more hardware processors receive a product configuration scenario for product planning that includes (i) a plurality of product feature families, and at least one of the following: (ii) a plurality of configuration constraints and (iii) a plurality of production constraints. Each product feature family among the plurality of product feature families comprise a plurality of feature variants. The plurality of configuration constraints represents one or more logical associations among the plurality of feature variants of two or more product feature families. The plurality of production constraints comprises a take rate constraint and an availability constraint for each feature variant of the product.
Referring to an Example (referring to Table 1), The transitive closure 202 of the system 200 receives the product configuration scenario as input for local consistency evaluation. The product configuration scenario for the product comprise the plurality of feature variants for each product feature family. For example, a vehicle may include one or more product feature families such as a body (B), engine (E), wheels (W), and the like. Each product feature family for example, the engine may have one or more feature variants, such as engines of different types, E_1,E_2,…,E_n and the like.
While planning the product for example a vehicle, a manufacturer typically considers one or more configuration scenarios. The product configuration scenario (as referred in Table 1) having a product variant may comprise the plurality of feature variants {A_I,B_j,C_k,…} such that exactly one feature variant is selected from each product feature family. Therefore, if there are n product feature families defined in the configuration scenario, each product variant has exactly n feature variants such that each feature variant belongs to a distinct product feature family. Each product variant is considered feasible if its feature variants meet all the underlying constraints. The solution to the above configuration scenario is one or more feasible product variants.
Each of the product feature family is denoted using an alphabetical index such as A,B,C,…,N. The plurality of feature variants of the given product feature family are denoted using the index of respective feature family followed by a numerical index. For instance, each feature variant of the feature family A may be represented as A_1,A_2,…,A_n. If a given product has 3 feature families, A,B and C that have 4, 3 and 4 feature variants respectively, the feasible space consists of 4*3*4 = 48 possible solutions.

Table 1- Example product configuration scenario S
Input
Feature Family Feature Variants Configuration constraints
A A_1,A_2,A_3,A_4
A_1?B_1, A_2?B_2, A_3?B_3,A_4?B_3
B B_1,B_2,B_3
B_1?C_1, B_2?C_2, B_3?C_3?C_4
C C_1,C_2,C_3,C_4
A_1??~C?_1, A_2?C_3, A_3?C_3

Input
Production Constraints
Feature variants Take rate constraints Availability constraints
A_1 [0.2,0,3] [0.3,0.4]
A_2 [0.2,0,3] [0.3,0.4]
A_3 [0.4,0,6] [0.4,0.7]
A_4 [0.2,0.3] [0.3,0.4]
B_1 [0.3,0.4] [0.3,0.4]
B_2 [0.3,0.4] [0.3,0.4]
B_3 [0.3,0.4] [0.3,0.4]
C_1 [0.3,0.4] [0.3,0.4]
C_2 [0.3,0.4] [0.3,0.4]
C_3 [0.3,0.4] [0.3,0.4]
C_4 [0.3,0.4] [0.3,0.4]

In one embodiment, the plurality of configuration constraints includes a positive configuration constraint, a negative configuration constraint, and a disjunctive configuration constraint.
The positive configuration constraint indicates a positive association between the two or more feature variants. It is represented as A_i?B_j, where if A_i is present, then B_j must be present.
The negative configuration constraint indicates a negative association between the two or more feature variants. It is represented as A_i?~B_j, where if A_i is present, then B_j must be absent.
The disjunctive configuration constraint indicates disjunctive association between the two or more feature variants. It is represented as A_i?B_j?B_k, where if A_i is present, then either B_j or B_k must be present.
Two or more feature variants that occur on the two sides of the entities ? must belong to different feature families, representing there is no constraint such as A_i?A_j. In addition, for the disjunctive configuration constraint, the feature variants that lie on the same side of the entities ? must belong to the same feature family where there is no constraint such as A_i?B_j?C_k.
In another embodiment, the plurality of production constraints includes the take rate constraint and the availability constraint for each feature variant A_i of the product.
A take rate constraint imposed on a feature variant A_i specifies a lower bound and an upper bound on the take rate of the feature variantA_i, that in turn indicates the fraction of the total production volume of the given product that demands the feature variant A_i. The minimum take rate bound and the maximum take rate bound for the feature variant A_i are denoted by minTR(A_i) and maxTR(A_i ) respectively.
An Availability constraint imposed on a feature variant A_i specifies a lower bound and an upper bound on the availability of the feature variant A_i, that in turn indicates the fraction of the total production volume of the given product for which the feature variant A_iis available. The minimum availability bound, and the maximum availability bound for the feature variant A_i are denoted by minS(A_i) and maxS(A_i) respectively.
The take rate constraint and the availability constraint for the feature variant A_i are represented by closed intervals , [minTR(A_i ),maxTR(A_i )] and [minS(A_i ),maxS(A_i )] respectively.
The take rate constraint values and the availability constraint values are normalized in the range of [0, 1]. Hence, 0 = minTR(A_i) = maxTR(A_i) = 1,and 0 = minS(A_i) = maxS(A_i) = 1.
Referring to the steps of the method 300, at step 304 one or more hardware processors determine a plurality of transitively closed configuration constraints by analyzing the transitive dependencies among the plurality of configuration constraints.
Referring to the above Example (as in Table 1) the transitive closure 202 computes the plurality of transitively closed configuration constraints by analyzing the transitive dependencies based on the below stated rules. The plurality of configuration constraints may have one or more transitive dependencies as shown below and as referred in Table 2, depicting the plurality of transitively closed configuration constraints.
If A_i?B_j and B_j?C_k , then A_i?C_k .
If A_i?B_j and B_j?~C_k, then A_i?~C_k.
If A_i?B_j and B_j?C_k ? C_l, then A_i?C_k ? C_l.
If A_i?B_j ? B_k, such that B_j?C_l and B_k?C_l then A_i?C_l.
Table 2 – Working of transitive closure
Input Output
Configuration constraints Plurality of Transitively closed Configuration constraints
A_1?B_1, A_2?B_2, A_3?B_3,A_4?B_3 A_1?B_1, A_2?B_2, A_3?B_3,A_4?B_3
B_1?C_1, B_2?C_2, B_3?C_3?C_4 B_1?C_1, B_2?C_2, B_3?C_3?C_4
A_1??~C?_1, A_2?C_3, A_3?C_3 A_1?C_1,A_1??~C?_1, A_2?C_2, A_2?C_3, A_3?C_3, A_4?C_3?C_4

The product configuration scenario (PCS) problem is hard because it is a generalization of the boolean satisfiability problem that is a well-known computationally hard problem. Most of the existing PCS techniques are based on backtracking, local search, and exhaustive search, so they are highly dependent on the size of the search space. Therefore, it is desirable to reduce the search space as much as possible. This not only leads to faster solutions, but also helps to avoid infeasible scenarios that arise due to local inconsistency. To address the above requirement, the local consistency validation provides necessary condition for feasibility of the given production configuration scenario. However, before applying local consistency the PCS problem is mapped to an equivalent constraint satisfaction problem (CSP).
Constraint Satisfaction Problem (CSP): Given a plurality of discrete variables X1,X2,…,Xn, such that each variable Xi¬ takes values from its given finite discrete domain Di, and a plurality of constraints C defined over the variables, the CSP problem checks whether there exists a solution which is an assignment to the plurality of discrete variables X1,X2,…,Xn such that the plurality of constraints in C are satisfied.
Referring to the steps of the method 300, at step 306 the one or more hardware processors map each product feature family to a discrete variable whose domain is the plurality of feature variants of the corresponding product feature family.
For the above example, the domain validator 204 of the system 100 obtains the plurality of transitively closed configuration constraints as input and maps the product configuration scenario (PCS) problem S to the equivalent constraint satisfaction problem (CSP) P. This mapping is performed in two phases. The plurality of discrete variables and their corresponding domains are computed by the domain validator 204 and the corresponding constraints are generated by the feature compatibility analyzer 206 of the system 200 (to be discussed in the next embodiment). The domain validator 204 of the system 200 computes the discrete variables along with their domains and performs one round of pruning. If there are conflicts within configuration constraints, such conflicts are resolved by appropriately pruning the discrete variable domains.
For each product feature family, A in S a discrete variable X_A is defined in P. The plurality of feature variants available in each product feature family A form the domain D_(A )of the discrete variable X_A. For each variable domain D_(A ) in P, the domain validator 204 performs one round of pruning. This eliminates the domain values (or feature variants) that engage in conflicting constraints. For the given plurality of transitively closed configuration constraints, there is a conflict, if one or more of the following conditions hold:
If there are configuration constraints, such that A_i?B_j, andA_i??~B?_j, then there is a conflict.
If there are configuration constraints, such that A_i?B_j, andA_i?B_k, then there is a conflict, because once A_i is installed, both B_j andB_k. Cannot be installed in the same product variant.
Since such conflicting constraints cannot be satisfied, the associated feature variant must be pruned. Hence, to resolve such conflicts, each such A_i feature variant is pruned from each domain D_A in P.
Table 3 - Working of domain validator
Input Output
Plurality of Transitively closed configuration constraints Domain Values
A_1?B_1, A_2?B_2, A_3?B_3,A_4?B_3 D_A A_3,A_4

B_1?C_1, B_2?C_2, B_3?C_3?C_4 D_B B_1,B_2,B_3

A_1?C_1,A_1??~C?_1, A_2?C_2, A_3?C_3, A_4?C_3?C_4 D_C C_1,C_2,C_3,C_4

Referring to the steps of the method 300, at step 308, one or more hardware processors prune those feature variants that are inconsistent with the plurality of transitively closed configuration constraints.
Referring to the example as shown in Table 3, the given PCS problem S is mapped to the CSP P, that has 3 variables XA, XB and XC whose respective domains are given as follows: D_A={A_3,A_4}, D_B={B_1,B_2,B_3}, and D_C={C_1,C_2,C_3,C_4}. The feature variants A_1 and A_2 are pruned from D_A as they participate in conflicting constraints. Since A_1?C_1,A_i??~C?_1 therefore A_1 is not viable. Further, since A_2?C_2,A_2?C_3, therefore A_2 is not viable because both C_2 and C_3 cannot be installed with the feature variant A_2. Due to this, A_1 and A_2 are pruned out from the domainD_A. It is noted that the above pruning step reduces the size of the feasible space from 4*3*4 = 48 to 2*3*4 =24.
Referring to the steps of the method 300, at step 310, one or more hardware processors map the plurality of transitively closed configuration constraints and the plurality of production constraints to an equivalent plurality of feature compatibility constraints that specify the compatibility among the plurality of feature variants of two or more product feature families.
Referring to the above Example and Table 4, the feature compatibility analyzer 206 of the system 200 analyzes the compatibility between two or more product feature families. The feature compatibility analyzer 206 generates the feature compatibility constraints necessary to transform an instance of the PCS problem S to the equivalent CSP problem P.
The above mapping is performed by sequentially analyzing the plurality of transitively closed configuration constraints, followed by the plurality of take rate constraints, and finally, the plurality of availability constraints.
The compatibility of the product feature family A with the product feature family B is denoted by C(A,B). Let the feature variants of the product feature family A be given as {A_1,A_2,…,A_m} and the feature variants of the product feature family B be given as {B_1,B_2,…,B_n}. If the two feature variants A_i and B_j can be installed together in any product variant, then A_i and B_j are said to be compatible with each other. Else, they are incompatible with each other.
Further, if the product feature variant A_i is compatible with B_j, then B_j is said to be support for A_i with respect to the constraint C(A,B), and B_j is added to a support set of A_i, denoted by ?sup(A?_i). By the above definition, A_i is also the support for B_j is thus added to the support ?sup(B?_j). Thus, the support sets sup(A_i) are symmetric. Moreover, the pair ?(A_i,B?_j) is said to be part of the compatibility constraint C(A,B).
Initially, without loss of generality each product feature family A_i is assumed as compatible with each product feature family B_j for i =1, 2,…, m, and j =1, 2,…, n. Thus, for each i =1, 2,…, m,, ?sup(A?_i)={B_1,B_2,…,B_n}.
Table 4 - Working of feature compatibility analyzer
Input
Plurality of Transitively closed configuration constraints Domain Values
A_1?B_1, A_2?B_2, A_3?B_3,A_4?B_3 D_A A_3,A_4

B_1?C_1, B_2?C_2, B_3?C_3?C_4 D_B B_1,B_2,B_3

A_1?C_1,A_1??~C?_1, A_2?C_2, A_3?C_3, A_4?C_3?C_4 D_C C_1,C_2,C_3,C_4

Output
Compatibility constraints Values
C(A,B) (A_3,B_3),(A_4,B_3)

C(B,C) (B_1,C_1),(B_2,C_2 ), (B_3,C_3),(B_3,C_4 )

C(A,C) (A_4,C_1),(A_4,C_2 ), (A_4,C_3),(A_4,C_4 )

In one embodiment, to determine the compatibility among the feature variants, the plurality of transitively closed configuration constraints are analyzed as follows:
If there is a configuration constraint A_i? B_j. Then, B_j is the only support for A_i. Thus, Sup(Ai)= {B_j}.
If the configuration constraint A_i? ~Bj. Then, B_j is not a support for A_i. Thus, Sup(Ai)= Sup(Ai)– {B_j }.
If the configuration constraint A_i? B_j?Bk. Then, B_j and B_k are the only supports for A_i. Thus, Sup(Ai)= {B_j,B_k }.
In another embodiment if there exists a configuration constraint A_i ?B_j, and the take rate constraints are such that maxTR(B_j) < minTR(A_i), then the take rate of feature variant A_i is not compatible with that of the feature variant B_j. Hence, B_jcannot support A_i. In other words, Sup(Ai)= Sup(Ai) - {Bj}.
Further, if the availability constraint for any feature variant Ai is such that the following condition is false, then the supply of A_i is not sufficient to meet its take rate. Hence, A_i is pruned out from the domain D_A.
minTR(Ai) = minS(Ai) AND maxTR(Ai) = maxS(Ai).
After analyzing the plurality of configuration constraints and the plurality of production constraints in the above manner, the desired feature compatibility constraints along with the updated variable domains of the CSP P are obtained.
For the above example, Table 4 shows the working of the feature compatibility analyzer 206, it is observed that since A_3?C_3,A_3 must be compatible with C_3. However, referring to the Table 1, it is noted that the take rate constraints of A_3 and C_3 are such that maxTR(C_3) =0.3 < minTR(A_3)=0.4. Hence, A_3 is not compatible with C3. Having reduced the PCS problem to the CSP problem, now the local consistency validation is applied as described in the next step.
Referring to the steps of the method 300, at step 312 one or more hardware processors evaluate the local consistency of the given product configuration scenario by pruning one or more feature variants that are locally inconsistent with the feature compatibility constraints.
For the given example of the product configuration scenario, the local consistency is evaluated as depicted in Table 5.
In one embodiment, the local consistency for the given product configuration scenario is evaluated by computing the support set for each feature variant with respect to the feature compatibility constraints induced on corresponding product feature family. This is followed by pruning the feature variants that do not have any support. with respect to the feature compatibility constraints. The effect of pruning is propagated to all the necessary product feature families. This process terminates when there are no more locally inconsistent feature variants to be pruned.
Table 5 – Working of local consistency evaluator
Input
Domain Values

+ Compatibility Constraints Values
D_A A_3,A_4
C(A,B) (A_3,B_3 ),(A_4,B_3 )

D_B B_1,B_2,B_3
C(B,C) (B_1,C_1 ),(B_2,C_2 ),(B_3,C_3 ),(B_3,C_4 ),

D_C C_1,C_2,C_3,C_4
C(A,C) (A_4,C_1 ),(A_4,C_2 ),(A_4,C_3 ),(A_4,C_4 ),

Output
Domain Values
D_A A_4
D_B B_3
D_C C_3,C_4

There are various local consistency measures such as node consistency, arc consistency, k-consistency, or path consistency. The k-consistency is a generic local consistency measure.
k-wise consistency (or k-consistency): Considering the CSP P defined over n variables, P is said to be k-wise consistent (or k-consistent in short), if there exists an assignment to any k out of n variables, such that the constraints induced over the chosen k discrete variables are all satisfied. A CSP P is feasible if it is n-consistent which is also referred to as globally consistent. Here, the node consistency and the arc consistency are same as k-consistency for k=1, and k=2, respectively. The local consistency evaluator 208 selects any local consistency measure (as described above) as all of them are designed to prune the search space. However, higher the degree of local consistency, higher is the pruning effectiveness, and higher is the computational cost.
In another embodiment, the arc consistency is selected as the local consistency measure since it offers fairly good pruning with reasonably low computation cost.
Arc Consistency: Given the CSP P, if each domain value Ai in each of the variable domains D_A, has a non-empty support set sup(Ai) ? ? for each constraint imposed on it, then P is said to be arc consistent. Else it is arc inconsistent. The task of an arc consistency technique is to identify arc inconsistent domain values, prune them and propagate its effect to all other domain values for which they were acting as the support. The process terminates when there are no more arc inconsistent values to be pruned.
Referring to the example shown in Table 5, the local consistency is evaluated as follows. Before invoking the local consistency evaluation, D_A= {A_3,A_4},D_B = {B_1,B_2,B_3} and D_c= {C_1,C_2,C_3,C_4}.. It is noted that since A_3 does not have a support in D_C,A_3 gets pruned out from D_A. In a similar manner, B_1 and B_2 get pruned out from D_B as they do not have any support in the domain D_A. Finally, C_1 and C_(2 ) are pruned out from D_C and B_2 as they do not have any support available in D_B. At the end, D_A= {A_4},D_B = {B_3} and D_c= {C_3,C_4}. Thus, the above pruning strategy reduces the size of the feasible space from 4*3*4 = 48 to 1*1*2 = 2. Incidentally, both these feasible choices, namely, (A_4, B_3,C_3) and (A_4, B_3,C_4) are solutions to the CSP P, or equivalently, to the PCS problem S. Hence, the present disclosure is highly efficient in reducing the search space.
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 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.
The embodiments of present disclosure herein addresses unresolved problem of production planning. The embodiment, thus provides method and system of evaluating local consistency for product configuration scenarios. Moreover, the embodiments herein further provides product planning and manufacturing to identify the key product variants along with their respective production volumes. The present disclosure employs local consistency which is necessary condition for feasibility of the given product configuration scenario. However, before applying the local consistency the product configuration problem is mapped to the constraint satisfaction problem.
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 can be any kind of device which can be programmed including e.g., any kind of 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 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.
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 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.
The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological 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 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 intended to be equivalent in meaning and be open ended in that an item or items 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.
Furthermore, one or more computer-readable storage media may be 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 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 other known physical storage media.
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

.
, Claims:We Claim:
1. A processor implemented method (300) for evaluating local consistency of a product configuration scenario, comprising:
receiving (302) via one or more hardware processors, a product configuration scenario for planning product variants that includes (i) a plurality of product feature families, and at least one of the following: (ii) a plurality of configuration constraints and (iii) a plurality of production constraints,
wherein each product feature family among the plurality of product feature families comprise a plurality of feature variants,
wherein the plurality of configuration constraints represents one or more logical associations among the plurality of feature variants of two or more product feature families, and
wherein the plurality of production constraints comprises a take rate constraint and an availability constraint for each feature variant of the product;
determining (304) via one or more hardware processors, the plurality of transitively closed configuration constraints by analyzing the transitive dependencies among the plurality of configuration constraints;
mapping (306) via one or more hardware processors, each product feature family to a discrete variable whose domain is the plurality of feature variants of the corresponding product feature family;
pruning (308) via one or more hardware processors, one or more feature variants that are inconsistent with the plurality of transitively closed configuration constraints;
mapping (310) via one or more hardware processors, the plurality of transitively closed configuration constraints and the plurality of production constraints to an equivalent plurality of feature compatibility constraints that specify the compatibility among the plurality of feature variants of two or more product feature families; and
evaluating (312) via one or more hardware processors, the local consistency of the given product configuration scenario by pruning one or more feature variants that are locally inconsistent with the feature compatibility constraints.

2. The processor implemented method as claimed in claim 1, wherein the product configuration scenario is mapped to an equivalent constraint satisfaction problem, where each product feature family is mapped to a discrete variable whose domain consists of one or more feature variants of the corresponding product feature family, the plurality of transitively-closed configuration constraints and the plurality of production constraints are mapped to an equivalent plurality of feature compatibility constraints.

3. The processor implemented method as claimed in claim 1, wherein the local consistency of the given product configuration scenario is evaluated by,
computing a support set for each feature variant of the feature compatibility constraints induced on the corresponding feature family;
pruning one or more feature variants that are not compatible with any feature variant of one or more product feature families;
propagating the effect of pruning to all the necessary product feature families; and
terminating when there are no locally inconsistent feature variants to be pruned.

4. The processor implemented method as claimed in claim 1, wherein the feature compatibility constraints among the feature variants of two or more product feature families are identified by sequentially analyzing the plurality of transitively closed configuration constraints, followed by the plurality of take rate constraints, and finally, the plurality of availability constraints.

5. The processor implemented method as claimed in claim 1, wherein the given product configuration scenario is evaluated for infeasibility due to locally inconsistent feature variants.

6. A system (100) for evaluating local consistency for one or more product configuration scenarios, comprising:
a memory (102) storing instructions;
one or more communication interfaces (106); and
one or more hardware processors (104) coupled to the memory (102) via the one or more communication interfaces (106), wherein one or more hardware processors (104) are configured by the instructions to:
receive a product configuration scenario for planning the product variants that includes (i) a plurality of product feature families, and at least one of the following:(ii) a plurality of configuration constraints and (iii) a plurality of production constraints,
wherein each product feature family among the plurality of product feature families comprises a plurality of feature variants,
wherein the plurality of configuration constraints represents one or more logical associations among the plurality of feature variants of two or more product feature families, and
wherein the plurality of production constraints comprises a take rate constraint and an availability constraint for each feature variant of the product;
determine the plurality of transitively closed configuration constraints by analyzing the transitive dependencies among the plurality of configuration constraints;
map each product feature family to a discrete variable whose domain is the plurality of feature variants of the corresponding product feature family;
prune one or more feature variants that are inconsistent with the plurality of transitively closed configuration constraints;
map the plurality of transitively closed configuration constraints and the plurality of production constraints to an equivalent plurality of feature compatibility constraints that specify the compatibility among the plurality of feature variants of two or more product feature families; and
evaluate the local consistency of the given product configuration scenario by pruning one or more feature variants that are locally inconsistent with the feature compatibility constraints.

7. The system as claimed in claim 6, wherein the product configuration scenario is mapped to an equivalent constraint satisfaction problem, where each product feature family is mapped to a discrete variable whose domain consists of one or more feature variants of the corresponding product feature family, the plurality of transitively-closed configuration constraints and the plurality of production constraints are mapped to an equivalent plurality of feature compatibility constraints.

8. The system as claimed in claim 6, wherein the local consistency of the given product configuration scenario is evaluated by,
computing a support set for each feature variant of the feature compatibility constraints induced on the corresponding feature family;
pruning one or more feature variants that are not compatible with any feature variant of one or more product feature families;
propagating the effect of pruning to all the necessary product feature families; and
terminating when there are no locally inconsistent feature variants to be pruned.

9. The system as claimed in claim 6, wherein the feature compatibility constraints among the feature variants of two or more product feature families are identified by sequentially analyzing the plurality of transitively closed configuration constraints, followed by the plurality of take rate constraints, and finally, the plurality of availability constraints.

10. The system as claimed in claim 6, wherein the given product configuration scenario is evaluated for infeasibility due to locally inconsistent feature variants.

Dated this 16th Day of November 2023

Tata Consultancy Services Limited
By their Agent & Attorney

(Adheesh Nargolkar)
of Khaitan & Co
Reg No IN-PA-1086