Database useful for configuring and/or optimizing a system and a method for generating the database

[0002] The aim of the invention is to support automatic modeling, analysis (verification) and real-time simulation of large-scale configuration problems on a standard computer (e.g. a personal computer). Mathematically speaking, such problems on finite domains or intervals can be expressed in terms of truth tables with M^Ncombinations, each of which can assume either of the truth-values true or false (legal or non-legal). Here we are assuming N variables, each with M elements. Thus, binary variables are to be considered as a special case with M=2.

[0003] Obviously, M^Ncombinations will cause “combinational explosion” and it is therefore not a trivial task to solve large configuration problems with a multitude of variables. Nevertheless, the present invention makes it possible to unify the seemingly contradictory requirements for completeness (all combinations must be accessible to ensure logical consistency) with compactness of representation and speed of simulation.

[0004] For example, interlocking systems for railway operation are controlled by several thousands variables representing signal values or switch positions. To illustrate, even a small interlocking system with 2000 binary variables will be characterized by the huge number of 2²⁰⁰⁰states or combinations. Some combinations are legal (allowed), while other combinations are clearly illegal because they would cause disasters. To handle these systems with conventional technology, it has been necessary to break down the system into subsystems of sufficiently small size to allow their validation, whereby not only illegal, but also a large number of legal combinations may be excluded, resulting in a less efficient utilization of the system. In general, the system variables will not be limited to binary values but will also include different data types on finite domains (e.g. multi-valued logic, integers, or finite sets of intervals). It is highly desirable to be able to handle configuration problems in systems of that size by means of computerized tools which could provide complete and correct responses almost instantaneously.

[0005] Another example is configuration of products or services (e.g. cars, computers or travels) on the Internet. Many products are available in a multitude of variants, which must be selected by the customer from a number of mutually dependent options. Thus, only some combinations of these options are possible or legal, while other combinations are illegal due to some technical or commercial constraints. It is therefore desirable to design e-commerce tools to enable the user to select interactively only the legal combinations, even from very complex product models.

[0006] While a number of computerized configuration tools have become available, e.g. the systems disclosed in WO 90/09001 and U.S. Pat. No. 5,515,524 there is still a demand for systems which fulfil the requirements for completeness and compactness and speed of response. In this context, the term “completeness” indicates the mathematical requirement that all combinations have been verified to ensure logical consistency.

[0007] The present invention provides an elegant solution to this problem without the problem of “combinational explosion”. As it will be understood from the following description, the crux of the invention is the establishment of a novel type of database, in the following termed an “array database”. While the database is an optimal tool for the complex configuration problems indicated above and described in greater in the following, it will be understood that due to its unique inherent advantages, it is also useful for a wide range of applications for which conventional database systems, typically relational databases, are used at present.

[0008] A scientific/mathematical discussion of principles relevant to the invention is given in Moller, Gert L.: On the Technology of Array-based Logic. Ph.D. thesis, Electric Power Engineering Department, Technical University of Denmark, January 1995.

[0009] In one aspect, the invention relates to a method for generating a database useful for configuring and/or optimizing a system spanned by variables on finite domains and/or intervals, said method comprising generating and storing, in a memory or storage medium of a computer, an addressable configuration space of the entire system in terms of all legal Cartesian subspaces of states or combinations satisfying the conjunction of substantially all system constraints on all variables, with all interconnected legal Cartesian subspaces being addressable as legal combinations of indices of link variables, so as to establish a database in which substantially all legal solutions in the system are stored as nested arrays.

[0010] In the following, the database generated according to the invention will be termed an “array database”, this term reflecting the fact that all legal solutions are stored in the database as one or more nested arrays.

[0011] Definitions and explanations relevant to some of the terms used in the present specification and claims are as follows:

[0012] “Configuring” means establishing substantially all legal combinations of the variables satisfying substantially all the constraints on the system. Preferably, all legal combinations of the variables satisfying all the constraints on the system are established, in which preferred case the legal Cartesian subspaces of states or combinations will satisfy the conjunction of all system constraints on all interconnected variables.

[0013] “Optimizing” means applying a heuristic selection of combinations within a set of legal combinations.

[0014] The term “a system spanned by variables on finite domains and/or intervals” indicates that each variable of the system consists of a finite set of elements or state values (e.g., logical truth values) or a finite set of intervals.

[0015] The term “An addressable configuration space” indicates that substantially all legal combinations are explicitly represented; in the preferred case, all legal combinations are explicitly represented.

[0016] “A Cartesian subspace” is a compact representation of one or more legal combinations, all combinations being derivable/calculated/ as the Cartesian product of the elements or state values for each variable.

[0017] “System constraints” are the relations (propositional functions) on variables defined for the system.

[0018] “Interconnecting variables” indicates variables present in at least two relations.

[0019] “A link variable” means a variable generated by the method according to the invention and added to a given relation with a unique index which identifies one Cartesian subspace.

[0020] “Interconnected legal Cartesian subspaces” means legal Cartesian subspaces with at least one common variable.

[0021] It is a crucial feature of the invention that all illegal states or combinations violating the system constraints are excluded from the relations. Such exclusion of illegal states or combinations can preferably be performed while the database is generated by the method according to the invention, the illegal states or combinations being excluded whenever identified. A state of contradiction or inconsistency is present in a system if just one relation of the system has no legal combination or state. On the other hand, a system is said to be consistent if at least one state or combination is legal, i.e. satisfying all system constraints. If, in the generation of the database, just one relation of a system is found to have no legal combination or state, then that whole system is in a state of contradiction or inconsistency and must be excluded.

[0022] In the following, the process of colligating relations (that is, combining relations to arrive at a more complex subsystem or system) is discussed in greater detail. It will be understood that on each level of the colligation process, inconsistencies or contradictions will be identified and will, thus, result in exclusion of the colligated subsystem or system. Thus, when the generating process has been completed, the system will be consistent, as manifested by all relations having at least one legal Cartesian subspace.

[0023] In the present specification and claims, the term “system” is used about an entire system of variables or, alternatively, about a part of an entire system of variables. In all cases relevant to the present invention, the system, understood in this manner, is completely defined in that every combination under the system is either legal or illegal with respect to all system constraints relevant to the use of the database and preferably with respect to absolutely all system constraints. Thus, the term system, used about an entire system of variables, indicates, in the context of the claims and the specification, that the entire system is completely defined with respect to all system constraints relevant to the use of the database, and preferably with respect to absolutely all system constraints. When a system of variables is not completely defined in the above sense of this term, then only that part of the system which is in fact completely defined is covered by the tern “system” as used in the claims. The term “substantially”, as used in claim 1, indicates that it is possible to have a system which is not defined with respect to system constraints that are not relevant to the use of the database. The them “substantially” can also indicate a system in which the process of colligation has not been completed, and where the runtime environment must be adapted to perform certain tests for consistency. While the latter variant is not considered ideal, it may nevertheless apply for certain applications of the invention where the realtime capability of the runtime environment is not a requirement.

[0024] As indicated above, the system constraints may be determined by conjugating one or more relations, each relation representing the legal Cartesian subspaces of states or combinations on a given subset of variables. The conjugation of the one or more relations comprises calculating the Cartesian subspaces satisfying the combined constraints of the one or more relations. If no relations have common variables, no further action is required to conjugate the relations.

[0025] According to an important preferred feature of the invention, all relations with at least one common variable are colligated. The colligation comprises conjugating the constraints of two or more relations being connected by having common variables to establish the Cartesian subspace(s) satisfying the combined constraints of the two or more relations.

[0026] The colligation of the two or more relations will normally be performed by joining the two or more relations up to a predetermined limit. Joining comprises the operation of replacing a set of relations with a single relation satisfying the combined constraints of the set.

[0027] The set of relations is not limited to two relations but can in general be any finite number of relations. In a preferred embodiment of the invention the case where three or more relations are joined is typically decomposed into a number of pairwise joins. This pairwise joining can comprise a predetermined strategy or the joining can be in a random order.

[0028] The joining process will typically reduce the number of relations, and the resulting number of relations are then colligated by linking them and grouping them into one or more cluster(s) of relation(s).

[0029] A cluster can comprise one relation or a set of interconnected relations. These clusters will be described in greater detail in the following.

[0030] The linking of the relations consists of adding link variables and adding one or more calculated relation(s) representing the constraints on the link variables.

[0031] The linking of relations can be within a cluster or between clusters. The linking between two clusters may be performed by establishing a link relation comprising two link variables, while for a linking within a cluster the link relation(s) comprises all link variables on the relations in the cluster.

[0032] If three or more relations interconnected with common variables are generating cycles or closed paths, then they are grouped into a single cluster comprising the three or more relations. As a consequence the resulting cluster(s) are interconnected without cycles, i.e. in a tree structure.

[0033] The tree structure makes it possible to ensure completeness of deduction in the run time environment by state propagation, for example when a configuration or optimization is performed.

[0034] The term “completeness of deduction” indicates that all logical consequences must be deduced on one or more variables. In important embodiments of the invention, the completeness of deduction relates to all logical consequences on all variables, but as indicated above, the invention is not limited to that.

[0035] When the array database is to be used for optimization, one or more object functions are incorporated. An object function of a given subset of variables, the object function deriving characteristics of the given subset of variables, is linked to the complete configuration space by deducing the constraints imposed by the object function on each link variable connected to the given subset of variables.

[0036] After the array database has been generated by the method according to the invention, object functions can provide information between a set of variables and a set of object function values, e.g., price, weight, color.

[0037] If a set of object function values does not have a “natural” order, e.g. as numbers, an arbitrary order can be assigned to the set of object function values.

[0038] The characteristics of the object function may be determined and the constraints on the link variables deduced on each combination of the given variables, the result being represented as a relation on the object function, the given variables, and the link variables.

[0039] These characteristics can be the values of the object function given by functional mapping of a set of independent variables or a set of constrained variables. The mapping can also be a general relation yielding one or more object function values for each combination of the variables.

[0040] In another aspect, the invention relates to a method for configuring and/or optimizing a system spanned by variables on finite domains, said method comprising

[0041] providing a database in which substantially all legal solutions in the system are stored as nested arrays and

[0042] deducing any subspace, corresponding to an input statement and/or inquiry, of states or combinations spanned by one or more variables of the system represented by the nested arrays by deriving the consequences of a statement and/or an inquiry by applying the constraints defined by the statement and/or inquiry to the database.

[0043] “Deducing” means deriving or determining all logical inferences or conclusions from a given set of premises, i.e. all the system constraints.

[0044] “Inquiry” means a question for which the array database can provide all answers.

[0045] A question could be about the legal combination(s) of a given set of variables satisfying the system constraints and possibly also satisfying an external statement.

[0046] An external statement can be a number of asserted and/or measured states and/or constraints from the environment.

[0047] Thus, a deduction of any subspace of states or combinations is performed on a given subset of variable(s) either without or colligated with asserted and/or measured states and/or constraints from the environment.

[0048] The interaction between the system represented by the array database and the environment is suitably performed by means of a state vector (SV) representing all legal states or values of each variable.

[0049] Thus, an input state vector (SV1) may represent the asserted and/or measured states from the environment, while an output state vector (SV2) may represents deduced consequence(s) on each variable of the entire system when the constraints of SV1 are colligated with all system constraints in the array database.

[0050] The deduction can be performed by consulting one or more relation(s) and/or one or more object function(s) at a time by colligating the given subset of variables in the relation with the given subsets of states in the state vector and then deducing the possible states of each variable.

[0051] The consultation of a relation can be performed by colligating, e.g. joining, the relation and the states of the variables present in the relation. The result of the consultation can be the projection (union of all elements) on each variable of the colligated relation, or the result can be the colligated relation. The colligation can of course be a joining, but it should be evident from the discussion given herein that the consultation of each relation is not limited thereto.

[0052] In a preferred embodiment of the invention two or more variables are colligated in parallel; the projection on two or more variables can similarly be performed in parallel. The invention is not limited to such parallel implementation, and the invention can just as well be implemented sequentially.

[0053] In one embodiment of the invention completeness of deduction is obtained by consulting connected relations, until no further consequences can be deduced on any link variable. This operation is termed “state propagation”. Such state propagation comprises consulting two or more relations in parallel. The invention is of course not limited to such parallel implementation, and, due to the cluster structure, the invention can just as well be implemented sequentially.

[0054] An important feature of the configuration and/or optimization according to the invention is that the state of contradiction can be identified, when no legal states or values are deduced when consulting at least one relation.

[0055] In the following the invention will be described in greater detail with reference to the figures:

[0056] The array database (to be termed ADB in the following) is a compact, yet complete representation of all legal combinations of configuration problems on finite domains or intervals. The configuration space of legal states or combinations is represented geometrically in terms of nested data arrays, and the ADB can be simulated very efficiently by simple operations on these arrays. Each step in the process of ADB modeling and simulation is explained in the Chapters 5 and 6, respectively.

[0057] The major data flow of ADB modeling is summarized in FIG. 1. Input is a user-defined specification of the system constraints in terms of a set of rules or relations on a given set of variables. The ADB is modeled in a three-step procedure as sketched in the process block ADB-MODEL in FIG. 1.

[0058] At this stage, the process of ADB modeling is finished. The entire configuration space can now be addressed by coordinate indexing and other simple operations on the nested arrays.

[0059] The major operation of ADB simulation is sketched in FIG. 2 and will be described in more detail in Chapter 6.

[0060] Each item of the state vector SV represents the state (the legal values) of the associated variable. In the input state vector SV1, one or more variables are bounded due to external measurements or assertions. SV2 represents the resulting constraints on all variables. An important technological requirement is completeness of deduction; that is, all constraints on the variables in the output state vector must be deduced.

[0061] The most important technological novelty of the ADB can be summarized as follows:

[0062] The different rule-based systems on the market today are representing rules or relations as independent items (no colligation). Thus, these rules must be manipulated individually by search rather than simple geometrical operations on arrays. Processing time therefore depends on the extent of search, which is a problem in applications where completeness of deduction must be ensured in real-time (e.g. railway interlocking systems).

[0063] Basically, the task of ADB modeling is constraint elimination; that is, all non-legal combinations must be eliminated yielding an explicit representation of all legal combinations or legal Cartesian subspaces.

[0064] Input is the user-defined system constraints in terms of variables (on different data types or scales of measurement) and rules or relations on these variables. The compilation is a two step procedure as shown in FIG. 3.

[0065] 5.1.1 Compile the Domain of Variables

[0066] The domain of each variable is any ordered finite set (a list) with n unique items. The domain {False, True} of a propositional variable is thus a special case with n=2. The list may be an explicit representation of all elements in a finite domain, or, in the case of large or maybe even infinite numerical domains, an ordered set of disjoint intervals.

[0067] As an example, we will consider the global domain of a system with six different state variables illustrated in Table 1.

[0068] A and ALARM are propositional variables with the length n=2, while COLOUR(x) is a predicate variable representing a nominal scale measurement with n=4. In the internal array representation, each measurement is given by its associated domain index. LENGTH(x) and WIDTH(x) are simple ordinal scale measurements with an explicit representation of all domain elements, while TEMP(x) illustrates an interval scale measurement given by a finite set of intervals. An interval is defined by its lower and upper boundary given by the value and type of each boundary (0=open, 1=closed).

[0069] 5.1.2 Compile Each Relation Into Standard Array Form

[0070] Each user-defined relation on a subset of domain variables is compiled into the standard array form, which is a nested array with two items. The first item is the set of legal Cartesian subspaces, while the second item is the domain indices of the associated state variables. All the succeeding processing on the relations is based on this common representation, which may be conceived as the basic component of the ADB.

[0071] EXAMPLE

[0072] Given the following relation on the variables WIDTH and LENGTH in Table 1:

[0073] R: WIDTH is less than LENGTH

[0074] That is, the complete state space of legal and non-legal combinations is:

[0075] The standard array form of Table 2 is depicted below as tables in two isomorphic forms with eight legal combinations (expanded form) or, alternatively, two legal Cartesian subspaces (compressed form):

[0076] EXAMPLE

[0077] The compiled array form of the relation TEMP(>120)→ALARM on the domain in Table 1 is:

[0078] Mathematically speaking, the constraints of the entire system are the conjunction of all relations. So far, during compilation, we have considered the user-defined relations as independent items. The configuration space of the complete system is now computed by colligating the interconnected relations (elimination of the connectivity constraints).

[0079] Simultaneously, the system is tested for logical consistency: when a local configuration space is empty, the conjunction of all system constraints yields a contradiction. Moreover, redundant and non-constrained information is eliminated automatically.

[0080] The procedure shown in FIG. 4 is adopted.

[0081] 5.2.1 Join Relations until Size Limit

[0082] The simplest operation of colligation is to join relation pairs with common variables into single relations representing the conjunction of the pair. Connected relations are joined whenever convenient; that is, when the size of the joined result is less than a given limit. When two relations have many common variables, the joined relation will be smaller than the arguments. Similarly, when the relations are sparsely connected, the joined relation may blow up in size. In the case of contradiction (logical inconsistency), the configuration space of the joined relation is empty. Isolated (non-connecting) variables without importance for the system simulation (interim variables) may be eliminated.

[0083] The strategy for joining a list of relations is shown in FIG. 5. The join factor or connectivity factor of a relation pair is used to predict the size of the joined result. The join factor of a connected pair is defined as follows: $\mathrm{JF}\equiv \frac{I_0\times I_1\times \left(A_0\times \left(1+\ln \frac{T_0}{A_0}\right)\right)\times \left(A_1\times \left(1+\ln \frac{T_1}{A_1}\right)\right)}{C^2}$

[0084] where:

[0085] EXAMPLE

[0086] Given the small system with three relations R0, R1, R2:

[0087] The compilation of each relation yields:

[0088] The relations in Table 6 may be joined into a single relation R=R0{circumflex over ( )}R1{circumflex over ( )}R2 representing the complete configuration space:

[0089] We have thus finished the colligation task on this small example; all constraints of the isolated relations as well as the connectivity constraints are represented in the joined relation. The result of modeling the system is thus an array database with the single relation depicted in Table 7.

[0090] #

[0091] In general, the array database will contain more than a single relation, when systems scale up.

[0092] 5.2.2 Group Relations Into Clusters

[0093] At this stage, it is not possible to join further relations within the user-defined size limit. The colligation strategy now depends on the properties of the colligation graph depicting the structure of interconnected relations. The relations are represented by the nodes, while an arc linking two nodes (relations) represents the common variables.

[0094] Two different kinds of graphs are particular important:

[0095] Trees (graphs without closed paths or cycles): In this case it is possible on ensure completeness of deduction by state propagation on the simple links between the relations.

[0096] Example:

[0097] Graphs with closed paths or cycles: The cycles must be eliminated to ensure completeness of deduction by simple state propagation. Example:

[0098] Before further colligation, the relations are grouped into clusters, all of which can be linked together without cycles. When the colligation graph of relations is a tree, each relation is thus associated with a single cluster.

[0099] FIG. 6 illustrates the colligation graph of a given system. Of course, we may eliminate all cycles by grouping the relations into a single cluster. However, in order to make the succeeding colligation process most efficient on large systems, it is desirable to group the relations into the maximum number of clusters. In this example, the maximum number of clusters is four as shown in FIG. 7.

[0100] In the case of input-output systems, each relation is a function (output=f(input)). The predefined flow of data from input nodes to output nodes is depicted in a directed colligation graph. When the graph is acyclic (no cycles or strong components), the data flow is complete by a simple state propagation from input to output. In the case of a cyclic digraph, the cycles must be eliminated by grouping the associated relations (functions) into clusters as shown above.

[0101] FIG. 8 illustrates a predefined dataflow on the system in FIG. 6 assuming that each relation is a function. We note that the graph is acyclic and the flow is thus complete with a state propagation from R0 to R15.

[0102] 5.2.3 Colligate Relations In Each Cluster

[0103] The major steps are sketched in FIG. 9. In order to ensure completeness of deduction, all cycles in the cluster must be eliminated (FIG. 9.1). The nested run-time cluster (FIG. 9.2) is an alternative compact and efficient representation of the cluster configuration space.

[0104] 5.2.3.1 Cycle Elimination: Determine Tree Structure of Colligated Relations (FIG. 9.1)

[0105] When a list of relations closing one or more cycles in a cluster are large and sparsely connected, the “combinational explosion” will make it impossible to join the list into a single relation. Therefore, we will generate an equivalent but much more compact list of colligated subspaces; that is, a new list of relations with the following characteristics:

[0106] Each user-defined variable (domain variable) is only present in a single relation.

[0107] The relations are linked together by system generated link variables yielding a tree structure (without cycles).

[0108] Each local Cartesian subspace of legal combinations is associated with a unique link variable with a unique index.

[0109] Thus, we will isolate variables present in a single relation and perform the colligation only on subspaces with common variables. The five-step procedure shown in FIG. 10 can be used on any set of relations, even when the colligation graph is acyclic.

[0110] EXAMPLE

[0111] Given the cluster relations R0, R1, R2 closing a single cycle:

[0112] The standard array form of each compiled relation is:

[0113] List of relation(s) on isolated (non-connecting) variables (FIG. 10.1 and FIG. 10.2):

[0114] List of relations on connecting variables (FIG. 10.1):

[0115] When the list of relations on connecting variables is joined (FIG. 10.4), we have the following result with two relations on isolated domain variables and one common link variable Link0:

[0116] The tree structure of colligated relation fulfills the requirements for completeness, compactness, and speed of simulation. Completeness of deduction is ensured by state propagation on the relations in the tree (see Section 0). The nested cluster representation to be introduced in the following is an alternative (isomorphic) representation.

[0117] Sometimes the user-defined relations are including internal system variables (interim variables), which can be eliminated. An example is network problems with input and output nodes (which are connected to the environment) and a number of internal nodes connecting input and output nodes. When the network constraints are represented in the ADB, it is desirable to eliminate the internal variables and to represent only the subspaces on the input-output variables.

[0118] 5.2.3.2 Determine Nested Run-time Cluster (Optionally)

[0119] The aim of the following task is to determine a very compact run-time cluster representation, which can be simulated by simple coordinate indexing and table look-up without state propagation—even on small scale computers and controllers like, say, electronic relays.

[0120] The run-time cluster consists of the original domain relations extended with link variables addressing the Cartesian subspaces, and a set of system relations representing the relations between link variables. The impact of each Cartesian subspace on the entire system is determined by asserting the associated link variable index and then deducing the state of each link variable. This deduction is for example carried out by state deductions on each link variable index. The state deductions may be executed in parallel.

[0121] The determination of the nested run-time cluster is shown in FIG. 11.

[0122] EXAMPLE

[0123] Let us again consider the cluster Table 10 with three relations R0, R1, R2:

[0124] The run-time cluster depicted below consists of the three domain relations (left row) and the three associated system relations (right row). For example, in system relation 0, the three indices of link variable Link0 (representing the Cartesian subspaces of R0) is used as the input to deduce the constraints on each link variable. Thus, system relation 0 represents the impact of the Cartesian subspaces in R0 on the entire system.

[0125] 5.2.4 Link Clusters

[0126] We have now finished colligation of the relation(s) in each cluster, and the final step in the process of colligation is to colligate all relation pairs, which are connecting clusters. For example, in the system sketched in FIG. 7 the relation pairs (3_duster03_duster1), (9 10) and (10 12) must be colligated.

[0127] The data flow of linking clusters is shown in FIG. 12.

[0128] The result of colligating a relation pair is a new relation (to be termed link relation in the following) on the common variables and the two link variables. When the set of link relations is added to the array database, it is possible to ensure completeness of deduction by state propagation on the clusters and the link relations.

[0129] FIG. 13 illustrates in more detail the colligation of each relation pair (FIG. 13.2).

[0130] EXAMPLE

[0131] Given the relation pair R0, R1:

[0132] Obviously, the simplest way to colligate these simple relations is to join the pair into a single:

[0133] However, to illustrate the isomorphic form of link relations, we will extend the standard array form of R0, R1 with link variables:

[0134] Colligating the subspaces on the common variables C, D yields the following link relation:

[0135] In addition to the argument relations R0,R1 the link relation makes it possible to address the entire configuration space on the indices of the link variables. On large and sparsely connected relations, this is a more compact representation than joining the relations.

[0136] #

[0137] The configuration space of legal combinations may be extended with user-defined object functions to be manipulated heuristically, e.g. a fuzzy value (for fuzzy logic computations), a weight or a price (for optimization).

[0138] An object function 0 is defined on a subset on the state variables S₀, S₁ . . . S_n: O=f(S₀S₁ . . . S_n) and is compiled into standard array form.

[0139] EXAMPLE

[0140] Given a system model with the configuration space (WIDTH, LENGTH) and the object function PRIZE=f(WIDTH, LENGTH) represented in a single relation in standard array form:

[0141] When the object function is to be optimized during system simulation, we may also represent the configuration space of large domains in terms of Cartesian subspaces on which the object function is monotonic:

[0142] The object function of each Cartesian subspace is given by an interval with the lower and upper boundary, and the associated state variables are ordered to make the object function increasing.

[0143] #

[0144] The object function may be linked to the configuration space in either of two ways:

[0145] The flow chart of adding object functions is shown in FIG. 14.

[0146] EXAMPLE

[0147] Given the following configuration space in terms of three relations:

[0148] The object function Y=f(B,E) is added to the array database by a projection on all link variables associated with the state variables B,E:

[0149] When the modeling task is finished, the array database is prepared for a very efficient simulation, which can be performed in real time. The major operation for ADB simulation is the state deduction shown in FIG. 2.

[0150] The state vector represents the state (the legal values) of each state variable. In the input state vector SV1, one or more variables are bounded due to external measurements or assertions. The deduced state vector SV2 represents the resulting constraints on all variables, when the system constraints and the constraints of the input state vector are colligated.

[0151] The state deduction is carried out by means of a few array operations (suitable for parallel processing) on the basic components of the array database:

[0152] the relations,

[0153] the relation clusters,

[0154] the interconnected (linked) relation clusters, and

[0155] the linked object functions

[0156] The state deduction on a single relation in standard array form is carried out by colligating (by intersection) the input state vector (SV1) with the relation succeded by a projection on each variable of the relation yielding the output state vector (SV2). The colligation and projection are described in greater details below.

[0157] EXAMPLE

[0158] To illustrate, we will again consider the system with the relations R0, R1, R2:

[0159] Modeling the system into a single relation (by joining R0, R1, R2) yields:

[0160] We will now deduce all consequences of the external measurement A=1 (true). The following three-step procedure is adopted:

[0161] 1. Identify all bounded variables in the Input state vector SV1.

[0162] A is bounded or constrained to 1, while the other variables are unbounded and thus assigned all the possible domain values (0 1). The input state vector SV1 is therefore:

[0163] 2. Colligate the constraints of the relation and the Input state vector SV1.

[0164] Each Cartesian subspace in the relation is intersected with SV1, item by item (variable by variable). The most efficient operation is to select only the bounded input variables and to compute the intersection axis by axis (suitable for parallel processing if desired). Non-valid (empty) Cartesian subspaces are deleted. In the present example, only the first Cartesian subspace is empty and therefore deleted:

[0165] 3. The output state vector SV2 Is the projection (union of all elements) on each axis.

[0166] This operation is also suitable for parallel processing on each axis. The axis projection on Table 27 yields the following output state vector SV2:

[0167] We conclude that A=E=1, while the other variables are unbounded (don't care or tautology).

[0168] #

[0169] This basic state deduction on a single relation is the foundation for state deduction on relation clusters and interconnected clusters. Moreover, it should be noted that this operation can be used on any data type (scale of measurement) on any relation in standard array form, including object functions. In the case of object functions, the input state vector may be constrained by optimization criteria like, say, the minimum prize of a given configuration.

[0170] The structure of the nested run-time cluster with domain relations and system relations on common link variables was introduced previously (modeling step 2.3.2). The state of the cluster can be deduced very efficiently in a five-step procedure shown in FIG. 15.

[0171] The key to the efficient state deduction is that each Cartesian subspace in the complete configuration space has a unique projection on the link variables, which can be deduced (FIG. 15.1-FIG. 15.2) and then indexed (FIG. 15.4-FIG. 15.5) one-by-one or in parallel. No heuristic search is used in this process.

[0172] The identification of bounded input variables (FIG. 15.1) is used to select those domain relations, which are candidates to be consulted (there is no reason to consult domain relations only with unbounded variables—these relations will not deduce further constraints on the state vector). However, step (FIG. 15.1) is not essential; all domain relations may be chosen as candidates for the succeeding step (FIG. 15.2). The domain relations (FIG. 15.2) may be consulted one-by-one or in parallel yielding a local output state vector, presumably with new constraints on some variables. If the link variables are still unbounded, the state deduction is completed (FIG. 15.3).

[0173] If some link variables are bounded, the impact on the complete cluster is deduced by consulting the system relations (FIG. 15.4) (one-by-one or in parallel).

[0174] Finally, the complete impact on the domain variables is deduced by consulting all domain relations with new constraints on the associated link variables (FIG. 15.5). The result is the complete output state vector.

[0175] Summing up, parallel processing may be introduced at different levels:

[0176] EXAMPLE

[0177] Given the nested cluster representation of the following system:

[0178] Moreover, given an input state vector SV1. The state deduction on the cluster is carried out as illustrated in FIG. 15:

[0179] 1. Identify Bounded Domain Variables In The Input State Vector (FIG. 15.1)

[0180] Only variable A is bounded:

[0181] 2. Consult All Domain Relations With Bounded Domain Variables (FIG. 15.2)

[0182] R0 is the only domain relation on the bounded variable A. Thus; there is no reason to consult R1 and R2. Consulting R0 yields a local output state vector with new constraints on Link0:

[0183] 3. Consult All System Relations Associated With Bounded Link Variables (FIG. 15.4)

[0184] 4. Consult All Domain Relations With Bounded Link Variables (FIG. 15.5)

[0185] The domain relations associated with bounded link variables are consulted yielding the global output state vector SV2:

[0186] State deduction on interconnected clusters is carried out by state propagation as shown in FIG. 16. All cluster relations with bounded variables are consulted and the state vector updated repeatedly, until no further information can be deduced. In practice, the propagation is controlled by the link variables: when no further constraints can be deduced on the link variables, the propagation is finished.

[0187] Completeness of deduction is ensured with state propagation, whenever the colligation graph is acyclic. Thus, state propagation can be used on the following structures:

[0188] The configuration space of interconnected clusters on common link variables

[0189] Object functions connected with the configuration space on common link variables

[0190] Dynamic systems with predefined input and output variables (acyclic digraph)

[0191] The following small examples illustrate different applications of the invention.

[0192] The constraints of the small combinational network shown in FIG. 17 are given by the interconnections of the logical gates. The input file for the array database describes the domain of variables and the user-defined relations:

[0193] RELATIONS

[0194] A=not I1;

[0195] B=(I1 and I2);

[0196] C=not I2;

[0197] D=not (A or B);

[0198] E=(D or B);

[0199] F=(B or G);

[0200] G=not (B or C);

[0201] H=not D;

[0202] I=(E or F);

[0203] J=not G;

[0204] O1=(H and I);

[0205] O2=(I and J);

[0206] Modeling the array database yields the following result with all user-defined relations joined into a single database relation with just 4 legal states or combinations:

[0207] We conclude that I1=O2 and I2=O1; that is, all gates could be removed!

[0208] In FIG. 18 an example of a simulation environment is depicted. The variable O2 is asserted/assigned the state O2=1 (true) with all consequences deduced. It is seen that any variable or combination of variables can be used as input—there is no distinction between input and output variables.

[0209] Given the following input file for a small alarm system with three state variables on different data types:

[0210] DOMAIN

[0211] ALARM, Boolean;

[0212] SIGNAL, Enum(Red, Yellow, Green, Blue);

[0213] TEMP, Interval(]11;30],[100;[);

[0214] RELATIONS

[0215] TEMP([100;[)→SIGNAL(Yellow,Blue);

[0216] TEMP(1120;[)→ALARM;

[0217] The two relations have one common variable TEMP and must therefore be colligated. Joining the relations yields the following array database with three legal Cartesian subspaces on a single relation:

[0218] Note that the relation is depicted with the legal domain values rather than the domain indices. The internal binary representation is shown in Table 37.

[0219] We will now assume that a car manufacturer wants all the possible combinations of customer options to be available on the Internet.

[0220] Given the following array database input file with the logical constraints of the cars:

[0221] DOMAIN

[0222] Model, Input, Enum(c300 “CAR 300”,

[0223] c300i cab “CAR 300 Cabriolet”,

[0224] c300_cab “CAR 300 Turbo 16 Cabriolet”,

[0225] c3000_cc “CAR 3000 CC”,

[0226] c3000_cs “CAR 3000 CS”,

[0227] c3000_cd “CAR 3000 CD”)

[0228] , “Car model”;

[0229] Engine, Input, Enum(m_—20_—16 “2,0i 16, 128 hp, 173 Nm at 3000 rpm”,

[0230] m_—21_—16 “2,1i 16, 140 hp, 180 Nm at 2900 rpm”,

[0231] m_s “2,0S 16, 145 hp, 205 Nm at 3800 rpm”,

[0232] m_turbo_—16 “Turbo 16, 160 hp, 255 Nm at 2800 rpm”,

[0233] c_—3000 “2,0 16, 130 hp, 173 Nm at 3750 rpm”,

[0234] c_—3000_—23 “2,3 16, 150 hp, 212 Nm at 3800 rpm”,

[0235] c_—3000_—23_turbo “2,3 Turbo, 200 hp, 330 Nm at 2000 rpm”,

[0236] c_—3000_—23_turbos “2,3 TurboS, 200 hp, 330 Nm at 2000 rpm”)

[0237] , “Engine type”;

[0238] Doors, Input, Integer(2 “Two doors”,

[0239] 3 “Three doors”,

[0240] 4 “Four doors”,

[0241] 5 “Five doors”)

[0242] , “Number of doors”;

[0243] PaintType, Input, Enum(Normal “Normal paint”,

[0244] Metallic “Metallic paint”)

[0245] , “The type of paint”;

[0246] PaintColour, Input, Integer(153 “Cirrus white”,

[0247] 170 “Black”,

[0248] 198 “Embassy blue”,

[0249] 214 “Cherry red”,

[0250] 219 “Talladega red”,

[0251] 223 “Odoardo grey metallic”,

[0252] 227 “Citrin beige metallic”,

[0253] 228 “Platana grey metallic”,

[0254] 229 “Le Mans blue metallic”,

[0255] 230 “Scarabe green metallic”,

[0256] 231 “Monte Carlo yellow”,

[0257] 232 “Derby grey”,

[0258] 233 “Carrara white”,

[0259] 234 “Nocturnal blue metallic”,

[0260] 235 “Eucalyptus green metallic”)

[0261] , “The paint colour”;

[0262] WheelType, Input, Enum(NoAlloy “No Alloy wheels”,

[0263] Alloy1 “Alloy wheels 15 spokes, open”,

[0264] Alloy4 “Alloy wheels, Aero design”,

[0265] Alloy6 “Alloy wheels, 15 spokes, closed”,

[0266] Alloy7 “Alloy wheels, 3 spokes, asymmetric”)

[0267] , “Wheel type”;

[0268] FrontSeat, Input, Enum(MAS “Manually adjustable front seats”,

[0269] EAS1 “Elec. adjust. left front seat”,

[0270] EAS2 “Elec. adjust. front seats”,

[0271] EAS1M “Elec. adjust. left front seat, memory”,

[0272] EAS2M “Elec. adjust. front seats, memory”)

[0273] , “Front seats type”;

[0274] SunshineRoof, Input, Enum(NoSSR “NoSSR”,

[0275] SSR1 “SSR1”,

[0276] SSR2 “SSR2”,

[0277] SSR3 “SSR3”)

[0278] , “Sunshine roof”;

[0279] GearBox, Input, Enum(Manual “Manual”,

[0280] Automatic “Automatic”)

[0281] , “Gearbox type”;

[0282] RELATIONS

[0283] Model(c300i_cab)→Engine(m_—21_—16);

[0284] Engine(c_—3000)→Model(c3000_cc,c3000_cs,c3000_cd);

[0285] Model(c3000 cc)→Engine(c_—3000);

[0286] Model(c3000_cd,c3000_cs)→not Engine(m_—20_—16,m_—21_—16,m_s,m_turbo_—16);

[0287] Model(c300_cab)→Engine(m_turbo_—16);

[0288] Engine(c_—3000_—23_turbos)→Model(c3000_cs);

[0289] Engine(c_—3000_—23,c_—3000_—23_turbo)→Model(c3000_cs,c3000_cd);

[0290] Model(c300)→Engine(m_—20_—16,m_—21_—16,m_s,m_turbo_—16);

[0291] Model(c300i_cab,c300_cab)=Doors(2);

[0292] (Model(c300) and Engine(m_turbo_—16))→not Doors(4);

[0293] Model(c3000_cd)→Doors(4);

[0294] Model(c3000_cs,c3000_cc)→Doors(5);

[0295] Engine(m_—20_—16)→FrontSeat(MAS);

[0296] Engine(m_—21_—16,m_s,m_turbo_—16)→not FrontSeat(EAS1M,EAS2M);

[0297] Engine(c_—3000_—23_turbos)→FrontSeat(EAS2M);

[0298] Model(c300_cab)→FrontSeat(EAS2);

[0299] Model(c300i_cab,c300_cab)→not FrontSeat(EAS1M,EAS2M);

[0300] (Model(c300) or Engine(m_—21_—16))→not FrontSeat(EAS1,EAS2);

[0301] Engine(m_—20_—16)→not SunshineRoof(SSR3,SSR2);

[0302] Engine(m_—21_—16)→not SunshineRoof(SSR2);

[0303] Engine(c_—3000_—23,c_—3000_—23_turbo,c_—3000_—23_turbos)→not SunshineRoof(SSR1);

[0304] Engine(m_s)→not SunshineRoof(SSR3);

[0305] Engine(m_turbo_—16)→not SunshineRoof(SSR1,SSR3);

[0306] Model(c3000_cc)→SunshineRoof(NoSSR,SSR2);

[0307] Model(c300i_cab,c300_cab)→SunshineRoof(NoSSR);

[0308] (Engine(c_—3000) and Model(c3000_cd,c3000_cs))→not SunshineRoof(SSR1);

[0309] Model(c300,c300i_cab,c300_cab)→PaintColour(223);

[0310] Model(c300)→not PaintColour(231,235);

[0311] Engine(c_—3000,c_—3000_—23,c_—3000_—23_turbo,c_—3000_—23_turbos)→not PaintColour(231,235);

[0312] Engine(c_—3000_—23_turbos)→not PaintColour(198,214,232,233,227,230,234);

[0313] Engine(m_—20_—16,m_—21_—16)→not WheelType(Alloy1,Alloy4,Alloy7);

[0314] Engine(c_—3000_—23)→not WheelType(Alloy4,Alloy6,Alloy7);

[0315] Engine(c_—3000_—23_turbos)→WheelType(Alloy4);

[0316] Engine(c_—3000_—23_turbo)→WheelType(Alloy7);

[0317] Engine(m_s)→WheelType(Alloy1);

[0318] Engine(m_turbo_—16)→not WheelType(Alloy4,Alloy6);

[0319] Model(c300_cab)→WheelType(Alloy7);

[0320] Model(c300i_cab,c3000_cc)→not WheelType(Alloy1,Alloy4,Alloy7);

[0321] (Engine(c_—3000) and Model(c3000_cd,c3000_cs))→not WheelType(Alloy1,Alloy4,Alloy7);

[0322] (Model(c300) and Engine(m_turbo_—16))→WheelType(Alloy1);

[0323] Engine(c_—3000_—23_turbos)→GearBox(Manual);

[0324] PaintType(Metallic)=PaintColour(223,227,228,229,230,234,235);

[0325] Note that the user-defined relations can be written in any order and in many different ways. In the abovementioned relations, the user has written many symbolic expressions with logical implications (IF-THEN) rather than a few tables. The modeling process is independent of the input format.

[0326] Modeling the input file yields the following array database with five relations representing the configuration space of the car. These relations are interconnected by common link variables:

[0327] The array database in Table 38 can be stored on an Internet server to make it accessible for any client on the network. This is carried out in either of two ways:

[0328] The array database is loaded to the client before simulation

[0329] The array database is stored on the server and simulated from the client through the network (only the state vector is transmitted)

[0330] To illustrate, let us assume that a customer wants a car with two doors. The deduced state vector with all consequences is depicted in FIG. 19. We conclude that only the cabriolet cars are available with two doors—and the sunshine roof is not a legal option!