Unified System Modeling and Simulation via Constraint Hypergraphs Free

Everything in the universe is a system; in their efforts to understand those systems, scientists and engineers fabricate models that describe their behavior. These models are defined according to the prescribed frameworks: the language of algebra, pseudocode, even visual diagrams such as circuit networks or architectural blueprints. Most frameworks are developed for a targeted domain such as geometry, artificial intelligence, or economics. Where these niche representations fall short is in the representation and simulation of systems spanning multiple domains [1], preventing modelers from understanding how a part of one domain, such as bird migrations, affects an object in another subsystem, such as the energy-production of a windmill.

To grapple with these cross-cutting interactions, systems theorists have devised general system modeling frameworks. Most of these, such as SysML or Modelica, employ an object-oriented paradigm [2,3]. They classify objects in the system, as well as interfaces for sharing information between them [4]. Object-oriented modeling is often preferred because it is easier for humans to read and understand; the cost is that models get broken into isolated subsystems where interactions between domains may not be fully captured. Because of this, object-oriented models can be difficult to integrate, with simulation limited to restricted domains [5].

Another class of model frameworks is declarative. A model following a declarative paradigm establishes the relationships comprising a system without enforcing a preferred order, connecting all system components at the same level of representation [6]. Domain-specific modeling frameworks include bond graphs for dynamic systems, the constraint networks of computer science [7], and the factor graphs applied primarily to coding theory [8,9]. Because they use functions as their underlying semantic unit, declarative models are far more interoperable than object-oriented frameworks, and consequently better suited for expressing system behavior [10]. This article describes a new declarative framework for the universal modeling of heterogeneous systems, addressing the yet-unsolved problem of providing both generalized representation and execution of a system model. This framework is termed a constraint hypergraph (CH), borrowing phraseology from the field of constraint theory [7].

A CH is composed of nodes and edges. The nodes represent system properties such as position, speed, color, weight, and are connected to each other via edges. Each edge represents an explicit constraint that maps a set of nodes to a single value of another node. This can be read as ”given values for $A$ and $B$⁠, the edge constrains the value of $C$ to be $x$⁠.” Because such constraints are often multidimensional (such as $C=A+B$⁠), an edge constraint may be derived from the values of multiple nodes resulting in hyperedges in a hypergraph. A basic example of a CH consisting of five nodes and two constraints describing a mass–spring system is shown in Fig. 1. The constraints for this dynamic system could also be represented algebraically as $x¨=kmx$⁠, where $x,k$⁠, and $m$ denote displacement, stiffness, and mass respectively. The CH in the figure shows that $x¨$ can be calculated given known values for the nodes $km$ and $x$ and that $km$ can be in turn calculated if $k$ and $m$ are known.

CHs reveal how each property in the system affects another. This is not limited to a single system; CHs also describe how systems interact with other systems, and how models of two different systems can be combined into a single whole. The composition of two CHs is the union of the set of nodes in each, joining the hypergraphs along their shared nodes. This is illustrated in Fig. 2, where the mass–spring system has been extended to include a damper.

In both of these figures, only one direction of the mapping has been made (showing relationships leading to the constraints on $x¨$⁠). Relationships in CHs are implicitly causal; acausal constraints can only be included by adding additional inverted edges. This leads to more edges and can crowd the diagrams. This makes for an important point: in contrast to a language like SysML, CHs are not diagrammatic nor intended for visual modeling. They are formulated as a robust, mathematical structure for capturing the fundamental relationships between system entities, allowing agents (both human and autonomous) to fully understand the behavior of the system and simulate its potential states.

CHs represent a new framework, but one whose structure is not entirely novel. The mathematics and methods of the framework amalgamate results from the fields of category theory, computer science, constraint theory, and logic programming. The contribution of this article is to both describe how these findings can be combined to create a useful framework, and also demonstrate how the resulting strongly-coupled, multi-domain modeling scheme can be applied to the general representation and simulation of real-world systems. This is accomplished starting by providing a background of previous work on multi-domain system modeling (Sec. 2), followed by a robust definition of a CH. This definition is used to explore how CHs represent (Sec. 3) and simulate (Sec. 4) systems, as well as their limitations (Sec. 5). Finally, a case study using CHs to represent an elevator system is provided in Sec. 6.

As long as engineers have considered systems, they have struggled to understand how objects of disjoint domains affect each other. From how forging affects the surface of a steel tool, to learning the ways in which music affects emotions, systems are by their nature heterogeneous, and consequently require methods of representing their heterogeneity. The section recounts only a fraction of the work in this field, with a focus on motivating CHs and their use by systems engineers.

A system is an arrangement of things that together exhibit behavior that the individual components do not [11]. If systems are constructs of the real world, then their corollary in the virtual domain is a system model, which relates the information known about a reified system. A system model is composed of properties approximating attributes of the real system, which are commonly represented with variables [12]. Each property is allowed to vary over a set of values. The set of possible combinations of each property is known as the state space.

What establishes a system model as representing a system is the provision of a set of relationships between the system properties, such that the possible states for a system are restricted. The restriction of system states is the definition of behavior given by Willems [5,13], and is suitable for the purposes of this article. A system model is considered in this article as a description of a system that provides rules governing the possible values for a set of properties. This general definition describes nearly every modeling framework as a system model. Geometric systems have properties of distance and orientation constrained by dimensions and geometric relationships, while finite element models have properties of nodal locations or thermal flow constrained by partial differential equations. Model frameworks applied to social [14], ecological [15], economic [16], and other domains also fit under this description.

The mathematics for describing system models are provided by category theory (see the introduction by Spivak and Fong [17]), which provides tools for defining the relationships inherent across systems. Efforts in this regard began with Fong in 2016 [18], who specifically introduced decorated cospans for deconstructing circuit networks into hypergraphs. This was built upon by Baez and Pollard, who applied decorated cospans to Petri nets [19], and by Patterson et al. in deconstructing dynamic systems [20,21]. The categories used in these works are extensions of graphs, and generalize the connections between a set of things [22]. This similarity to systems—also composed of entities connected to each other by constraints—leads to many system modeling frameworks being graph-based in nature. A selection of graph-based frameworks along with their primary domain of use is shown in 1. The diversity of modeling schemes stems from the varied interpretations of nodes and edges, where each might be assigned domain-specific system elements, relationship types, or composition rules.

With such a diversity of modeling types, establishing interoperability becomes a critical challenge in multi-domain systems. When sub-systems are modeled within a domain-specific framework, inter-framework incompatibilities can result in modeling silos: where a holistic system is composed of individual subsystem models which cannot effectively share information. The primary result of sequestered models is the inability to capture relationships between elements in different silos. This is a critical challenge for decisions makers; for instance, a systems engineer may not be able to see how changing a sensor will influence the weight distribution in an aircraft because the sensor interfaces, electric circuits, and payload models are all siloed in incompatible frameworks. Secondary effects of model silos include information loss during data exchanges, duplication (where singular entities are represented multiple times throughout a system), and challenges modifying or scaling due to the inter-system complexities not being captured in the global model.

There are two general approaches to providing model interoperability: transformation or unification [41], which relate respectively to the competing concepts of object-oriented and declarative modeling [42]. In the former, subsystems are treated as independent black boxes. Each subsystem has the ability to transform certain signals delivered via a defined interface (a port) [43,44]. This allows each subsystem to be uniquely defined according to its own domain-specific framework provided there is a standard interface for inter-component communication. The second approach is of system unification, where the components of each individual system are deconstructed and reconciled into a single holistic model. Of the two, transformer frameworks are more common, since it is simpler to define interfaces than fully deconstruct every member of a system.

Transformative frameworks, such as block diagrams, stock and flow diagrams, or entity-relation models, focus on the objects in a system. Because each class of object is unique, transformative frameworks must define unique methods for sharing information among the system [4]. These systems are often easier for designers to work with, since objects correspond to how a designer deconstructs a system [41]. Object-oriented solutions include SyDer [45], component objects [35], the functional mockup interface (FMI) standard [46]—strictly for dynamic system simulations, though standards for hybrid systems are being developed [47]—and SysML, a multi-domain modeling framework developed in 2007 [37] with the objective of supporting systems engineering tasks [48]. These weakly-coupled frameworks may struggle to simulate reactive systems featuring complex relationships between many system components [49].

Strong coupling is provided by unifying models, which do not prescribe objects, but instead deal primarily with the system constraints and the properties they relate. The relationships of a unifying framework are functions, which are common across all modeling domains. Where object-oriented frameworks are nested, the use of functions results in unifying models being flat, with every relationship elevated to the status of “first-class citizen” [6]. This makes combining models simpler since information does not need to be transformed between system components. Friedman was the first to show how functional frameworks could be used to describe universal system behavior, writing about systems of mathematical expressions constraining a set of variables [38,50]. These constraint models, as labeled by Friedman, were used to expose system complexity by representing the system behaviors, though they were not formulated to provide execution. CHs, the framework introduced in this article, are an expansion of Friedman’s work adapted to universally represent and simulate system behavior.

To motivate how system unification is accomplished by CHs, consider the example given by Gomes of a continuous and discrete system [51], where the discrete model is a state machine of a simple thermostat regulating the temperature in a room according to the following state machine:

In their survey on co-simulation [51], Gomes found that the only established methods for coupling the discrete and continuous models into a hybrid system was to interpret subsystems from one domain in terms of the other, a messy translation process prone to information loss. Alternatively, by identifying the system properties and functional constraints, the system can be fully reconciled into the CH shown in Fig. 3.

Constraint hypergraphs are not a visual framework, but to illustrate their composition, the following diagrammatic schema is followed in Fig. 3 and the rest of this article. In the figure, each circular node represents a variable, and each black box describes the function for an edge. Arrows wire nodes to edges (showing the function domain) and edges to a node (the codomain). Multiple domain arrows indicate a hyperedge, where the domain is the Cartesian product of all linked nodes. When order matters in the arguments, labels may be written on the domain arrows in the form $a,b,…,z$⁠. Finally, nodes that have only a single domain arrow are removed, replaced with wires connecting edges to edges, similar to a short circuit in an electrical diagram.

Building a CH reveals the two variables shared by the systems: $q$ and $T$⁠, allowing the systems to be connected along the respective nodes. The result is a fully coupled system, such that the relationships between the continuous and discrete models are completely expressed by the CH, exposing the behavior of the holistic system. In considering the hypergraph in Fig. 3, one notices that the discrete and continuous models are not easily distinguished. This is typical of a declarative modeling paradigm, where each model is fully deconstructed to the functional level. The categorization—and consequent isolation—of subsystems is largely a feature of object-oriented modeling, which treats each subsystem independently. Contrast this with a CH, where each function is considered and connected equally regardless of its subsystem of origin.

The general definition of a CH is given as

The structure of a CH is more explicitly described using the syntax of category theory, although having an understanding of this abstract mathematical field is not necessary to understand their structure. Consequently, the limited discussions involving category theory are supplementary in nature. In that guise, a CH $H$ is a subcategory of set with objects derived from a set $V$ where each element $v∈V$ is also a set. The objects $Ob(H)$ are given by the Cartesian product of each element of the power set of $V$⁠, or $Ob(H):={v1×v2×…×vn∀vi∈P∀P∈P(V)}$⁠. Since $Ob(H)$ is a subcategory of set, the morphisms of $H$ are functions mapping $Ob(H)→Ob(H)$⁠. Composition is then given by typical function composition, $∘$⁠, and the identity by the identity function on a set. This defines $H$ as a monoidal category.

The functions $cod$ and $dom$ follow the definitions given by Mac Lane [22], with both mapping from $E→Ob(H)$⁠, where $E$ is a set of edges. In the sequel $dom(e)$ is sometimes referred to as the domain of $e$⁠, and similarly to $cod(e)$ as the codomain of $e$⁠. Similarly, the Cartesian product of each element in an edge’s domain is referred to as $S$ (the source set), and the codomain as $T$ (the target set).

A hypergraph can be simply described as a collection of vertices connected by edges where the edges can connect any number of vertices. A CH adds to this general definition two important constraints:

1. Each vertex in $V$ is a set; and

2. Each edge in $E$ has only a single vertex in its codomain.

Note that here the definition of an edge is really that of a directed edge. This is more general than an undirected edge [52], and is important to the formulation of a CH. As non-directed graphs are not treated in this article, any such reference to a graph or hypergraph should be construed as referring to a directed graph and directed hypergraph.

The utility of a CH lies primarily in finding sequences between sets of vertices. Traversing a CH is similar to pathfinding in a graph, with the added complexity of multiple dependencies present at each edge whose domain has a cardinality greater than 1. Traversal methods are discussed in greater detail in Sec. 4.

In order for a CH to be traversable, it must be paired with a computational engine capable of identifying the mapping given by each $S→eT$⁠. Though such an engine is not required for the CH to be valid, the utility of a CH stems largely from its traversals. As such, the computational engine is a significant part of the CH. This engine may perform lookups similar to a querying agent in a relational database, or it may be a calculator capable of computing some rule that encodes the function mapping.

In addition to the description given in Definition 1, a CH is endued with several characteristics that increase its functionality. These characteristics do not alter the mathematical structure given by the more general definitions. Their inclusion is motivated by the application of CHs.

The purpose of ordering is so each vertex connected to an edge can be uniquely identified along a hyperedge during traversal of the hypergraph. The ordering of elements of $S$ by $f$ enables non-commutative relationships to be codified in an edge. For example, a function rule that does not commute such as $÷(A,B)→C$ (mapping each element of $A×B$ with the quotient of its ordered pair in $C$⁠) requires its operands to be assigned in a specific order, i.e., $÷(A,B)≠÷(B,A)$⁠.

Borrowing again from the language of category theory, an ordered CH is one in which each set $dom(e)$ is totally ordered, such that for any objects $a,b∈dom(e)$⁠, $a≤b$ is given by $idxe(a)≤idxe(b)$⁠, with $≤$ defined as the typical magnitudinal ordering operation for the set of natural numbers. Note that equivalence between $a$ and $b$ indicates a commutative relationship espoused by $e$ between the two objects. Consequently, an edge whose mapping was determined by addition might have $idxe(a)=1∀a∈dom(e)$⁠. Hence, $idxe$ is injective, not bijective.

The value mapped by the function $viae$ determines whether $e$ is viable. A non-viable edge is one that is known to exist, but for which the relationship is not currently sequenceable. This prevents traversals along a non-viable edge during simulation. A viable edge is equivalent with Definition 2.

As there are many relationships in the real world that exist for only a portion of their expressable dependent factors, such as a door permitting entrance only if it is unlocked, conditional viability has significant impact on the CH’s ability to represent realistic relationships. In more practical terms, a conditionally viable edge is one whose traversability can change during sequencing. A secondary, but no less important effect of this is the ability to form sequencable cycles in the CH. In order for a cycle to form a part of a path, there must be some mechanism by which the processing agent can exit a cycle based on values encountered at run-time. Such a requirement is fulfilled by conditional viability, with the values provided by the elements mapped from $dom(e)$⁠. A better understanding of the mathematical basis for conditional viability is covered in Sec. 4.

In addition to their formal definition, the authors aim to show that CHs can be used to represent any real system, either singular or covering multiple domains. Such a general objective can be reduced to showing the following conditions: (a) that the framework can represent any system property; and (b) that the framework can represent any interaction between the system properties.

A system property represents an identifiable phenomenon of an entity. Consider two assumptions: that every phenomenon can be represented by a set of values, and only a single one of these values may be manifest for any distinct frame of consideration. The second assumption stems from considering the system to be deterministic: where only one possible outcome may result for any set of initial inputs [12]. A system’s evolution is characterized as the manifestation of different values across unique frames of consideration. The behavior of a system is the set of restrictions on the possible values a system property can manifest for a given configuration of other system properties, following the definition given previously by Willems [5]. The goal of system representation is to express these system properties and inter-property restrictions.

A CH is composed solely of these elements. By refraining from prescribing the types of properties that can be represented, a CH is able to represent any property that can be described by a set of values. Due to the finitude of information, this should include all phenomena that can be considered, satisfying the first condition of system representation.

The second condition, considering system interactions, is motivated by the notion that a system property may manifest only a single value when considered. Consequently, any interaction between system properties must be given as the prescription of a unique value. A function is the correct mathematical construct for representing these interactions. By mapping the values of a system property to a single, distinct value of another, a function enforces the causality assumption implicit in system modeling. A CH encodes all possible system interactions by using functions to represent not just relations between a pair of properties, but also combinations of multiple properties. Consequently, any function that can be mapped between the properties of a system can be expressed by a CH, confirming the second condition.

This can be demonstrated by the example of the hybrid radiator system in Fig. 3. In that figure, there are seven properties of the system relating to temperature, settings, power flow, etc., each one represented by a node in the hypergraph. The set of every possible state for the system is given by all combinations of these properties, or $∏V$ where $V$ is the set of properties (following the definition of $∏X$ in Eq. (1)). The behavior of the system is the restriction of these combinations; for example, $q$ can not be 1 if $T$ is greater than $Tmax$⁠. These restrictions come as a direct result of the interaction of system components. As the components in a system evolve, they affect other parts, constraining the associated properties.

To represent a system, a modeling framework must capture every constraint imposed by the association of the system’s parts. It can be difficult to do this in a procedural (object-oriented) framework: trying to describe how a controller changes the continuous temperature of a room with a block diagram is possible, but not without converting the discrete controller output into a continuous signal. Contrast this to a CH, where the constraints between system properties are the natural language of the framework. The result is that a CH can not only represent any kind of real, deterministic system, but also any behavior espoused by the system.

An important purpose of representing a system is the ability to perform simulations, with simulation defined here as the measurement of a system property made without having first observed that property in reality. Under this definition, nearly every decision made by a modeler requires simulation. Before a decision is made, the state of a system is unset and cannot be observed since it does not yet exist. An architect deciding on the location of a building cannot observe that location in reality as the building has not been built. Rather, the architect simulates the system to identify the optimal setting. Consequently, any system representation that does not afford simulation is nearly useless to a decision maker. One of the principle benefits of using a CH is the ability to simulate a system generally, exposing the possible ways to simulate a property anywhere in the system as long as it has been constrained by a constraint.

Simulation of a CH is focused not on translating visual diagrams into executable scripts, but on creating a mathematical structure that aligns execution with the underlying system behavior. The purpose of simulating a constraint hypergraph is to constrain a system such that system data becomes evident. If data are generated from constraints in a model, then it is artificial, and it is called simulated data. The data that are known prior to the simulation are referred to as inputs, and the data that need to be generated are referred to as outputs. This terminology should not be confused with expressing a CH in terms of inputs and outputs. A CH model is a set of constraints and relationships. The concepts of inputs and outputs apply only during a simulation when it becomes necessary to process relationships in a certain order. The directed edges in a CH describe which direction such sequencing may occur. Figure 4 shows an example of this: the model contains multiple different dependencies from different nodes, such that it’s impossible to say which node depends on which. The exception to this is during a simulation, when a single node is set to be the input, and the graph describes which nodes can become possible outputs. The act of processing a CH from one node to another is referred to here as sequencing, and is synonymous with simulation.

The expressiveness of a CH is founded in two principles: composition and determinism. Composition is enforced in a CH by representing relationships as function. In order to be a valid mapping, a function must show how each element in one set (the domain) is associated with an element in another set (the codomain) [53]. This guarantees that if a value of each source node is known, then the target node for the edge can always be calculated by the encoded function. The solved target node can then be utilized for simulation of additional nodes. Each step in the simulation composes with the previous, allowing an agent to readily form sequences of simulation steps throughout the graph.

CHs are also weakly deterministic, in that given a single input, each linked node is constrained to manifest only a single value. The two properties of composition and determinism are the foundation to forming simulatable sequences in a CH. As shown in Fig. 5, any sequence starting in the leftmost set is guaranteed to be able to arrive at the rightmost (composition), and given an element in either of the two leftmost sets, there is only one element in a set to the right corresponding to that value (determinism).

The authors label CHs as only being weakly deterministic because the same set of inputs is not required constantly map to the same set of outputs [12]. Whether the simulation of a CH will be deterministic or not depends on how the functional relationships are defined. A deterministic function is one where every value in its domain is always mapped to the same value in its codomain. Though this is typically the case, the only mathematical requirement of the function is that it maps the values in its domain to a unique value in the codomain. If the mappings between inputs and outputs specified by a function change for repeated calls, then any simulation along the corresponding edge will be non-deterministic. This allows for stochastic modeling, including Monte Carlo simulations. In practice, deterministic models are simple to obtain by requiring all functions to provide a constant mapping.

In a CH, the fundamental construct of a simulation is a path. A path (or a chain) in a graph is some sequence of distinct vertices connected in a sequence of non-repeating edges [52]. The corollary for a hypergraph is a hyperpath, which connects a given set of vertices (the source) to another single vertex (the target) by a chain of hyperedges. In order for a hyperpath to be traversable, a value must be known or generated for every node in the path. Each edge describes a rule whose execution generates a new value, thereby advancing the simulating agent along the path.

The actual execution of this rule—e.g., performing a table lookup, or executing a sequence of mathematical operations—is performed by a simulation engine paired with each function. Part of the process of preparing a constraint hypergraph is connecting each function rule to a simulation engine that can process it. During simulation, the engine is passed the value of the source set along with the rule to be calculated. It then returns the output value, which is assigned to the target node.

Structurally, hyperpaths are constructed as trees. In a hyperpath tree, branching occurs along every edge whose domain has a cardinality greater than one. By making the output node the root, and placing the source nodes as the leaves, the tree shows all the functions and nodes which must be traversed to complete the simulation. A hyperpath (as a tree) is shown in Fig. 6 for a hypergraph with two source nodes $S1, and S2$ and a target node $T$⁠.

In addition to sequencing a hyperpath, a means for determining which hyperpath to sequence must be provided. The philosophy of a CH is that the model contains all relevant relationships between elements of the system, which can create multiple ways to travel in between the same nodes. It is a nontrivial task to discover a valid path between nodes in a hypergraph, and even more complex to find an optimal one. To do this, the modeler needs to quantify the optimality of each edge, generally by assigning weights. Ausiello et al. described ways of traversing directed hypergraphs using a modification of Djikstra’s algorithm [54,55] to identify the minimum-cost path between all nodes in the hypergraph. Though this works well for simple hypergraphs, CHs are not simple due to their inclusion of two features: cycles and conditional edges. Ausiello’s work must be adapted to handle these conditions. Since this adaptation is not straight forward, it is worthwhile to motivate the provision of these graph features in a CH.

The most intuitive way to represent these state values is by associating a variable with each switch, labeled $A,B,C$⁠. Each variable will be represented by a node in a CH, with $A,B,C:={∘,∙}$⁠.

Providing a constraint decreases the degrees-of-freedom for the system. For example, a function $f$ constraining $A$ and $B$ to be equivalent reduces the degrees-of-freedom from three to two, and the number of possible system states from eight to four, as shown below.

Because the way system states are categorized is arbitrary, oftentimes a system may exhibit behavior that does not perfectly correlate to the prescribed variables. For example, if switch $C$ is always off if switch $A$ is off, then the system behavior cannot be correctly expressed by a function mapping $A→C$⁠, as $C$ is not constrained by the $∘$ state of $A$⁠. Instead, this behavior should be represented by a function $g:A∙→C$⁠, where $A∙$ only represents the $∙$ state of $A$⁠. Accordingly, $A∙$ is a subset of $A$⁠, as shown below.

Including $A∙$ changes the paradigm of the CH by introducing nested nodes. The main value of nesting is that the intuitive sets of $A,B,$ and $C$ can be maintained while also describing relationships between individual members of $A$⁠. Duplication of entities is also avoided since every function that maps from $A$ implicitly maps from $A∙$ also, without requiring $f$ to be redefined. Nested relationships represent constraints that only hold for a limited subset of the domain’s values. This is such a common occurrence in system modeling that conditional edges were identified by Peak et al. as a fundamental requisite for system simulation [36]. An example is Hooke’s law relating the force of a spring to its deflection, which is valid only if the deflection is in the spring’s linear regime.

The complexity of conditional edges comes as a result of violating composition. Let $X′$ be a subset of a set $X$⁠. Any function $f$ that points from $X$ also points from every value in $X′$⁠. However, the inverse of this is not true: if $X′$ is the domain of a function $g$⁠, then a simulation sequence arriving at $X$ is not guaranteed to be ably to traverse $g$ unless the assigned value for $X$ happens to also be in $X′$⁠. The result of this is that the simulation path becomes conditional on the specific value solved for $X$ at runtime. This greatly increases the computational expense of simulation, as a path through the CH must be rediscovered for each unique set of inputs, in contrast with the general paths found by Djikstra’s algorithm that are optimal for any node values.

An edge is described as being conditionally viable if $viae$ is not $1$ for all values of $dom(e)$⁠. The set of values for which $viae$ is $1$ is referred to as the viable set of $e$. Conditional viability can be used for path switching, where the node a simulation sequence next reaches changes based on the values of the latest inputs. In this case, there are two or more edges with disjoint viable sets, so that only one edge is valid for any given value. In this article, conditionally viable edges are typically shown as dashed, as in the figure below (which expresses the switching example described previously).

One of the most vexing issues of a graph is dealing with cycles: a path that begins and ends on the same node [56]. In a CH, a cycle in a simulation sequence would seemingly indicate that the value of a node is in someway constrained by itself, a violation of causality not found in the real world.

Despite this, cycles are still introduced as a matter of convenience to the modeler in performing simulations. This is due to many system variables being iterations of previous system states, especially as a system evolves through time. In a procedural model, such as those espoused by Wymore, a system has several independent states which repeat at each instance of time [57]. A CH, in contrast, has no sense of state. Each instance of a system variable is considered unique and independent, and must have some sequence of hyperedges connecting it to the input values to be successfully solved for. For instance, a hypergraph representing a body moving at a constant velocity along a single dimension is shown at the top of Fig. 7, where the position at each time-step $i$ is given by $xi$⁠.

Since a modeler may wish to simulate $x$ at an arbitrary time-step, this hypergraph should arguably be extended to infinity. This impossible expression can be enabled through the use of cycles, as shown at the bottom of Fig. 7. In the cyclical hypergraph, the addition of the index $i$ as well as a conditional edge $i≥n$ provides a mechanism for exiting the cycle after $n$ iterations. Note the essential functionality of the conditional edge, without which a pathfinder would not be able to identify a valid path that exits $xi$ for only a subset of the node’s values.

Having motivated the inclusion of conditional edges and cycles, the methods of pathfinding can now be properly described. Pathfinding is the act of tracing a hyperpath from a set of source nodes $S$ to a target node $T$ in the CH. Assuming that conditionally viable edges are present in the hypergraph, pathfinding must be performed for each unique set of input values. Consequently, the first step in the pathfinding sequence is to pare down the hypergraph to a subhypergraph consisting only of the nodes and edges that are possible candidates for a path. Given $S$ and $T$⁠, a solver can perform a basic search for a subhypergraph $H′$⁠, where each node in $H′$ is reachable from at least one $s∈S$ and from which $T$ is likewise reachable. A node $b$ is reachable from (or connected to) another node $a$ if there is a hyperpath from $a$ to $b$ [56].

Once $H′$ has been prepared, a solver should be run using standard algorithms for pathfinding (such as A*). At each node, the solver calculates a step along a hyperpath through $H′$⁠. In doing so, the solver creates a hyper-dimensional search tree. Each node in the search tree corresponds to a viable edge, as depicted in Fig. 6. Additional hyper dimensions indicate parallel paths established whenever a conditional edge is encountered. This suggests that the optimal path may run through the conditional edge, but because that path cannot be guaranteed to exist during runtime, other paths must also be explored. As the solver searches $H′$⁠, these parallel path are pruned from the search tree if either of the following conditions are met:

1. There are no unprocessed edges remaining from the root node (and the root node is not $T$⁠).

2. The total cost of the branch is less optimal than another branch comprised of simple edges.

Pruning in such a way is a description of backtracking, the most common method of solving a constraint problem [39]. The result of such exploration is a tree of all possible candidates for an optimal path from $S$ to $T$⁠. If the lowest cost path is made up of simple edges then the tree will be a normal search tree optimal for any input values. Otherwise, during simulation, the solver will proceed through the tree. At any branches onto parallel paths, the solver should step down the lowest-cost branch until the solver either reaches $T$ or the path becomes non-viable. In the later case, the solver resets to the latest solved node and traverses the next-most optimal path.

Although repeated pathfinding can become computationally expensive, it provides the unexpected benefit of gracefully handling discontinuities. Rather than aborting the simulation, solvers encountering a discontinuity (such as an ill-formed mapping or missing value) are able to switch to the next viable path as long as one is available.

A heretofore undiscussed aspect of CHs is the application of weights to their edges. While weights are a common practice in graph theory, it will be useful to consider their interpretation with respect to modeling systems. Weights are primarily used to depict a cost of traversing an edge; in the classic traveling salesman problem, weights depict distances between cities on an imaginary map. Search algorithms require weights to discriminate between parallel paths, preferring the path with the lowest summed weight. In the case of a CH, the cost of traversing an edge is the cost of executing a constraint on the system model. This cost could be interpreted a number of ways, such as the computational cost of calculation, the distance to the desired target node, the cost of excluding some alternate constraint, or even the uncertainty associated with the modeling constraint.

The inclusion of weights in a CH specifies that some edges in the model should be considered of greater precedence than another. Precedence only matters in instances where there are a plurality of edges offering competing routes for reaching a node. The act of identifying an optimal model among many options is typically described as model selection. Edge weights enable automatic model selection by providing a quantitative parameter for comparing edges.

A practical example is selecting a path that minimizes a simulation’s uncertainty. The utility of interpreting edge weights as modeling uncertainty is not in the quantification; assigning uncertainty is still as arduous in a CH as any other framework. Instead, CHs provide an advantage in composing uncertainty for different simulations. A CH breaks down every relationship in a system model into a single, traceable function. For a systems engineer, each of these functions can be thought of as assumption. By listing each edge in a path, a modeler can systematically consider each assumption made in a simulation. Because each function is independent of all others, uncertainty can be assigned without having to consider side effects or duplicated calculations. And because the total uncertainty of any arbitrary path can be trivially calculated, a pathfinding algorithm can search for a simulation path that minimizes uncertainty.

When the edge weights are interpreted as computational costs, then the weighting scheme can be used to determine the least expensive simulation to compute. Weighting schemes are not exclusive either, they can be combined to compare simulation paths by different metrics. The resulting paths can then be optimized via a multi-optimization method to minimize multiple objectives.

Though constraint hypergraphs have been used to great effect, they by no means represent a silver bullet to modeling challenges. It has already been mentioned that flat, complex system models can be visually overwhelming. Object-oriented frameworks, which provide methods for abstraction and encapsulation, are often better for decomposing a system for a human modeler. It is for this reason that this article has not focused on establishing hypergraph diagrams. This section aims to set forth some of their other known limitations.

Related to the challenges of visualization, CHs are not optimal for model development. Because of their generality, any relationship can be formulated in a CH, including impossible relationships. The specificity of domain-specific frameworks discourage modelers from creating invalid systems, such as connecting gravity to a battery terminal. There is no such restriction imposed by CHs. From this the conclusion is drawn that CHs are used most effectively to unify system models that have already been developed in more specialized frameworks.

Perhaps the greatest limitation of CHs is that of syntactic interoperability. Although the semantics of a system are perfectly captured by a CH, this is dependent upon syntactic agreement between models. For instance, it may be impossible to say whether the label of “Speed” for a node in one model refers to the same data as the “Velocity” label of another. Though the use of ontologies can help prevent naming conflicts, the lack of tools for reconciling nodal identities greatly inconveniences the adoption of CHs. The authors are intrigued by the possibility of providing syntactic interoperability through reasoners based on graph similarity metrics.

Another major barrier to convenient adoption is the heavy processing time of constraint hypergraphs. Because optimal simulation paths cannot be autonomously determined a priori, path searching often must occur during each simulation run. Though constraint programming has developed great tools and methods for searching, this processing overhead can limit CHs use in real-time environments. This is especially true considering that solving a constraint problem is NP-hard [58], and CH networks can become incredibly complex. There are some instances that paths can be pre-determined, though in such cases simulation success often cannot be guaranteed unless the hypergraph contains no conditionally viable edges.

Finally, constraint hypergraphs are very good at exposing system behavior; they are less good at hiding it. There are many instances in which a modeler may which to obscure the sensitive behavior of a subsystem in a shared model, such as with proprietary technology. While it is certainly possible to form black boxes in a CH (simply by aggregating nodes into a single node and reconnecting graph edges), such actions prevent subsystem properties from being connected with other system elements. This greatly reduces the efficacy of a CH. Encapsulation and abstraction are both primary features of object-oriented systems, but they reduce the expressiveness of the more functional CHs. If such features are needed, interface-based frameworks may need to be used; privacy-motivated black boxing is one of the many use cases of FMIs [59,60].

A CH for an elevator lift system is provided to partially validate the constraint hypergraph structure. The unified model is an aggregation of a discrete-event simulation (DES), a dynamic Newtonian model, and continuous state space model (built around a PID controller). Descriptions for each node are provided in Table 3 in the  Appendix. At the risk of repetition, the reader is reminded that CHs are not generally a good choice for visualizing system models due to their high complexity and abundance of lines. However, for the purpose of communicating their use, a diagram for the CH has been provided in Fig. 8, with the model scoped to be as simple as possible without sacrificing functionality. The diagrammatic scheme follows that of Fig. 3, with the added stylizations of zigzag hashing for nodes that are shown multiple times in the figure (for clarity) and double arrows (↠) for edges that increase the iteration of a node in a cycle. There should be one such edge for every cycle in the graph; Fig. 8 has three cycles with corresponding iterative edges. The weight of every edge is set to one, resulting in the solver preferring the path with the minimum number of steps during simulation.

There are three primary subsystems represented in the CH: the dynamic system, the PID controller, and the DES of the passenger actions. The properties and edges for these subsystems are roughly gathered in the right, top left, and bottom left of the figure respectively. These classifiers for the various subsystems are only useful for a human modeler as the CH focuses solely on the holistic system. Consequently, it is not clear in Fig. 8 where one subsystem ends and another begins–at least not as clear as it would be in an object-oriented framework. The mock elevator consists of a carriage moving between three floors referenced by integers $0$⁠, $1$⁠, and $2$⁠. The forces acting on the carriage include the empty weight as well as the summed weight of each passenger (with the assumption that each passenger weighs the same). The driving force of the elevator is given by a PID controller using a first-order Euler integrator with a fixed step-size.

The number of properties comprising the system state is given by the number of nodes in the CH, which in this case is 45. There are several nodes for which constraints are not provided, these must be treated as inputs for a valid simulation, such as physical constants like gravitational acceleration. Initial properties for each passenger have also been given in Table 2. In the example, the elevator initially starts on floor $0$ and moves incrementally to floor $2$ (only ascending for simplicity).

Having visualized the CH, the next goal of this case study is to demonstrate a full system simulation. Any node in the hypergraph can be chosen to be simulated, but selecting Occupancy allows a more interesting example. The goal of a simulation is to predict the value of Occupancy at every landing to which the elevator arrives. In practice, this simulation would be conducted using a computational tool, however, this study is a demonstration of theory. The enactment of this simulation is consequently performed by a theoretical agent capable of processing a CH, which will be referred to as ch agent. The inputs to ch agent are the graph in Fig. 8, as well as a list of input values to several nodes, as tabulated in Table 3.

Assuming the inputs have been seeded correctly, a pathfinding algorithm would attempt to find a valid path from a subset of the input nodes to Occupancy. Pathfinding is conducted with some searching strategy such as a depth-first or breadth-first search, with the search starting from nodes with known values (the input set). If all nodes in the source set of an edge are known, then the edge can be traversed. Traversing an edge results in ch agent solving for the value of the target node by performing the function calculation represented by the edge. This new node is then added to the list of known values. The process repeats until ch agent is able to solve for the goal node, at which point the simulation terminates.

Because Occupancy is given as a known node, the initial simulation is trivial. However, Occupancy is included inside a cycle, meaning that additional iterations of the node can be solved for if all other values in the cycle are found. The cycle for Occupancy involves a hyperedge requiring the number of passengers boarding and exiting the carriage to be calculated, consequently, ch agent must solve for these nodes before it can find the next value of Occupancy, written here as $Occupancy2$⁠. The process for doing so is given by tracing the starting position of each passenger to determine whether they are on the carriage, boarding, or exiting while the carriage is at its initial floor, according to Eq. (3). The result is a chain of equations that ultimately transforms X Start and X Goal into $Occupancy2$⁠, which when solved returns a value of two.

Solving for $Occupancy3$ requires a much longer process. The conditional edge relating $ΔPassengers$ to Occupancy requires that the iteration of the source of Occupancy be only one iteration greater than the iteration levels of Num Boarding and Num Exiting, but the path found by ch agent includes only $NumBoarding1$ and $NumExiting1$⁠. Because no iterative edge (indicated by ↠) was encountered in the simulation path found previously by ch agent, the path cannot be reused to solve for the node’s next value. Tracing the cycle back in Fig. 8, the iterative edge is a hyperedge relating $FloorGap1$⁠, $HtTolerance1$⁠, and $Height1$ to $ElevCurrentFloor2$⁠. In order to increment the state of each node in the DES simulation just traversed, ch agent must find a path that connects through this edge, so that each source node will also be in their second iteration upon solving for $Occupancy3$⁠.

To necessary path takes ch agent through the entirety of the hypergraph, starting from $Occupancy2$ and ending on $Height2$⁠. After the iterative edge is traversed, the original path is retraced but at a higher iteration level, resulting in solving $Occupancy3$⁠. In this case, ch agent traverses 42 edges to reveal that the value of $Occupancy3$ is unchanged from the previous iteration. Along the way, values are found for $Height2$⁠, $PIDOutput1$⁠, and other nodes that are necessary for the general simulation.

By structuring the hybrid elevator system as a constraint hypergraph, ch agent demonstrates the universality of simulation, moving easily between the various subsystems without concern for ports and type specifications. It should be emphasized that this is a theoretical demonstration; computational complexity, run time, and other computing metrics are dependent upon the practical instantiation of ch agent and the specific search strategies employed by the encoded algorithms. For validation, a python-based implementation of ch agent employing a breadth-first search strategy [61] was run to calculate the Height of the elevator over 100 iterations, returning the results shown in Fig. 9. As a true instantiation of ch agent, no additional programming is employed apart from generic plotting software, conducting the simulation without any for or while loops, go-to statements, or conditional logic–all behavior of the system is encapsulated in the CH and executed by ch agent. While these results do not validate the models, which are overly simplified for demonstration purposes, they do indicate the ability of ch agent to integrate complex systems without relying on manually ported connections.

A robust, unified system model has many possible applications, some of which the authors hope to explore in future work; these include decision modeling and digital twins. Decision modeling applications stem from the fact that the decisions made by engineers and other agents often must be made before relevant information about a system is known; this is especially true early in the design stage. Constraint hypergraphs make it easier for the information that is known about a system to be understood and analyzed, but the process of quantifying uncertainty and validating simulation predictions remains a topic for further investigation.

Digital twins, defined as the virtual representation of some real system, are a confluence of data streams and models. Their popularity has driven use cases in a variety of systems, such as global environments [62] and national infrastructure [63,64]. This rich variety of system domains requires the combination of disparate models as well as the processing of heterogeneous data streams. As digital twins grow in fidelity these multifarious facets only increase. Constraint hypergraphs may promote the interoperability of digital twins [65] on both of these fronts: by unifying siloed system models and also by enabling sequencing of data across the holistic system. The author’s envision a constraint hypergraph expanding the role currently played by knowledge graphs from information banks [66] to system orchestrators: capturing and distributing information connected to system behavior with a multiplicity of connected agents.

The principle factors that contribute to a simulatable system model are composability and determinism. These two principles are embedded uniquely in various system models, but are robustly defined in constraint hypergraphs. Constraint hypergraphs, in their declarative description of property relationships, embody the structure of a system. The claim that CHs are suitable for general inter-system reconciliation was supported by showing that CHs support composability and determinism through functional composition, and further describing how every system behavior can be both represented and sequenced within the CH structure.

In the attempt to make this framework more practical, the mathematical structures have been related in the language of systems theory, showing how CHs communicate information and how the relevant notions of objects, states, and behavior are described. CHs are not only useful for semantic representation, they are also simulatable, and can be used to derive unknown system properties or solution spaces. It was shown that this depended on both the provision of functions and the representation of nodes as subsets of other nodes. A mechanism was then built out for building executable sequences and even cycles using edges with conditional viability.

In addition to establishing what CHs are, it was established how they can be used, including how weightings can represent uncertainty or computational costs, as well as applications to autonomous decision-making. These use cases were contrasted with some known limitations of CHs. Finally, these principles were demonstrated with an example of an elevator lifting system, with multiple system domains unified by a single CH. The authors hope to build upon this work through additional refinement of the CH framework, as well as the provision of integrable tools that can assist with CH modeling in established engineering applications.

A topic as general as systems modeling requires perspectives from multiple domains. As the authors are not experts in every domain, they would like to thank Dr. Wayne Goddard, Dr. Matthew Macauley, Dr. Satchit Ramnath, Edward Louis, Evan Taylor, and Nikhil Raj, as well as our anonymous reviewers, for their invaluable discussions regarding these topics and for expanding our perspectives.

There are no conflicts of interest.

The data and information that support the findings of this article are freely available online.²

Table 3 describes each node (or variable) shown in 8. Input values, useful for simulation, are provided for nodes if applicable.