Reasoning about physical processes in buildings through component stereotypes

Abstract

Buildings employ an ensemble of technical systems like those for heating and ventilation. Ontologies such as Brick, IFC, SSN/SOSA, and SAREF have been created to describe such technical systems in a machine-understandable manner. However, these focus on describing system topology, whereas several relevant use cases (e.g., automated fault detection and diagnostics (AFDD)) also need knowledge about the physical processes. While mathematical simulation can be used to model physical processes, these are practically expensive to run and are not integrated with mainstream technical systems ontologies today. We propose to describe the effect of component actuation on underlying physical mechanisms within component stereotypes. These stereotypes are linked to actual component instances in the technical system description, thereby accomplishing an integration of knowledge about system structure and physical processes. We contribute an ontology for such stereotypes and show that it covers 100% of Brick heating, ventilation, and air-conditioning (HVAC) components. We further show that the ontology enables automatically inferring relationships between components in a real-world building in most cases, except in two situations where component dependencies are underreported. This is due to missing component models for passive parts like splits and join in ducts, and hence points at concrete future extensions of the Brick ontology. Finally, we demonstrate how AFDD applications can utilize the resulting knowledge graph to find expected consequences of an action, or conversely, to identify components that may be responsible for an observed state of the process.

Impact Statement

We have shown how a simplified model of physical mechanisms can be integrated into existing system design descriptions. This is relevant for use cases where automated reasoning requires knowledge about the system’s physical effects and technical design. Our approach will significantly save software programmers’ effort working on applications like automated fault detection and diagnostics (AFDD). Instead of having to manually program the reasoning about the physical processes and mechanisms in code, they can now use generic semantic knowledge queries to correlate actions and observed states. This will lead to faster program development and wider reuse, as the programs will be loosely coupled to the technical system’s implementation. The machine-understandable knowledge of stereotypical component behavior can furthermore be used to select input features in a more context-relevant manner, e.g. for machine-learning methods or for reinforcement learning where this effectively restricts the search space for actions when finding optimal policies. The bottom-up integration of knowledge about physical processes directly into the system design is important because it avoids the later need to manually reconstruct it using out-of-band knowledge or having to learn it tediously by observing the system.

1. Introduction

Technical systems in a building are complex compositions of subsystems and their components that work in tandem to carry out physical processes like heating, ventilation, and air conditioning. Traditionally, such systems were described in human-understandable ways like texts and diagrams; however, driven by the need to make such system knowledge more directly accessible to software applications, we are seeing more and more machine-understandable specifications in recent years.

A large part of this development builds on top of active and cross-cutting research in the engineering and Semantic Web communities, where several ontologies like Brick ¹ (Balaji et al., 2016), IFC ² (Beetz et al., 2009), SSN/SOSA ³, SAREF ⁴, and so forth have made it possible to describe buildings and their systems in a manner that permits the creation of interoperable software using machine-understandable knowledge (Mayer et al., 2017).

Today, system design ontologies are used in the building automation domain to describe systems as compositions of topologically related subsystems. For example, using the Brick ontology, we can describe a heating system as a composition of subsystems for heat generation, distribution, etc., each consisting of interconnected components like pumps, valves, and so forth In such models, components (sometimes called equipment) are the functional units that carry out a well-defined transformation or transport of substance, effort, or energy. Finally, the granularity of the decomposition of systems using these abstractions—systems, subsystems, and components—varies from scenario to scenario. It depends on the granularity and abstraction level for which the system description is required. For example, a fan together with its motor and drive might be considered as a single component when viewed from the perspective of a control program whose goal is to “modulate the speed of the fan” and therefore is not interested from a more subsystem viewpoint (e.g., “actuating the drive which controls the speed of the motor and consequently the speed of the impeller of the fan”).

In addition to the structural relationships between subsystems and components, it is often desired to also encode knowledge about how the system functions. We see this need in several existing use cases like AFDD (see (Ramanathan et al., 2021)), plausibility checking (Gwerder et al., 2022), or control optimization (Delgoshaei et al., 2017). Such knowledge further enables matching automation program strategies to system deployments, synthesizing control interlocks (Koziolek et al., n.d.), and may support autonomous software agents to control and coordinate a building automation system (Ramanathan, 2021). For this purpose, we argue that machine-understandable system descriptions should incorporate not only structural descriptions but also descriptions of the functioning of the system’s components and their effects on the observable physical states. For example, although we know that the supply fan of the air handling unit (AHU) shown in Figure 1 is an instance of Brick class Supply_Fan, one has to rely on textual descriptions to understand that it functions by transferring kinetic energy from the impeller to the air resulting in increased air pressure and flow. In a system like the AHU, for a software agent to answer the question “Which components and which of their actions influence the supply air temperature?,” it would require access to common knowledge (in machine-understandable form) of the physical mechanisms of each component of the AHU is involved in.

Figure 1. An example of a system: This AHU takes in fresh air and filters and heats it before supplying it to a room. The value of tsu in this example is determined by toa, da, va, and fa.

Traditionally, physical mechanisms are described using semiformal diagrams, formal mathematical equations, logical rules, state machines, or simulation models. Simulation models created using tools like Modelica and Matlab can be compiled into a reusable module called the Functional Mockup Unit (FMU). Mitterhofer et al. (2017) have proposed an OWL-based ontology to describe such FMUs such that their purpose and interfaces can be queried and discovered by software agents. However, creating such models for systems deployed in buildings is prohibitively expensive due to the effort involved in modeling the mechanisms and their mathematical equations. On the other hand, among the use cases that can benefit from knowledge of physical mechanisms and processes, several of them, like AFDD, failure mode and effect analysis (FMEA), plausibility checking, and reasoning about control functions, do not require full simulation models but would already benefit from more abstract knowledge in terms of dependencies between variables that represent the process mechanism. Such information would informally read like “The supply temperature is determined by the airflow rate (influenced by the fan and the damper), the energy input to the heating coil (influenced by water temperature and the flow rate determined by the valve), and the intake air temperature (which is not under system control)”—this would permit a human to for instance understand that too low supply temperature could be remedied by modulating the damper actuator, supply fan speed actuator, or the valve actuator of the heating coil. Such a rule could further clarify (or integrate) more fundamental knowledge (e.g., that the heating coil is the component that most directly influences supply air temperature). Such knowledge can be further generalized by simplifying the description of the underlying physical mechanism: heating coils use the same physical mechanism as economizers or condensers—on this abstraction level, we may hence refer to all of these types of components as heat exchangers.

Towards permitting practically feasible functional description of components, we formulate the following questions:

1. 1. How can we describe physical mechanisms in a simplified abstraction that is widely valid for components of a kind?

2. 2. How can we link such (simplified) descriptions of a component’s mechanism to its technical interfaces so that we can understand which interfaces are relevant in the functioning?

3. 3. How can we enable reasoning about the role of interlinked components in a process?

Our aim is, hence, to capture such common knowledge of physical processes in a building automation system and thereby enable the automated answering of queries about a system’s overall behavior by permitting software programs (e.g., AFDD) to use formal reasoning on top of this knowledge. To do this, we propose a method to create stereotypical behavioral descriptions of physical mechanisms like heat exchange or pressurization. The stereotype would describe the process variables and their inter-relationship in a high-level abstraction instead of a complete mathematical equation. Such a fundamental description may be referred to and, hence, reused by various component kinds—for example, the mechanism of heat exchange is used by heating/cooling coils, evaporators, condensers, and so forth in HVAC systems. Further, to couple a component kind to the description of the physical mechanism(s) it uses, we propose a method to create stereotypical descriptions of its technical interfaces and couple them to the variables of the physical mechanism—for example, the heating coil in the AHU has inlet and outlet ports for air and hot water. The temperatures and flow rates observed or manipulated at these ports can be related to the variables involved in describing the heat exchange mechanism that the heating coil uses. We contribute the concept of such stereotypes and position it with respect to related work (see Section 2); we then provide the concepts and relationships required to model stereotypes of physical mechanisms and technical interfaces of system components (see Section 3). The necessary concepts and relationships are provided in an ontology, which we name Elementary. ⁵ Elementary is modeled using OWL, which is a part of the Semantic Web technology stack and is widely used to create formal specifications of concepts and relationships. In Section 5, we demonstrate the integration of our stereotypes with structurally oriented concepts of system components from the Brick ontology. We show how structural knowledge can be combined with functional knowledge about the system components and also illustrate the usage of our ontology by providing several examples of stereotypes along with a complete mapping of Brick HVAC components to proposed stereotypes. Finally, we also evaluate our approach in a real setting: an office building with about 180 rooms across six floors. We identify systems in the building that represent different levels of complexities in terms of topology and processes. We then identify queries found in AFDD use cases and show that our approach enables these to be answered without resorting to the use of full-fledged physics models.

2. Related work

In most domains, systems engineering involves the design of a system through the decomposition of requirements to find functional abstractions, which are then organized into a hierarchy of sub-systems (see (Nielsen et al., 2015) for an in-depth treatment of this topic). Existing and in-use ontologies such as Brick, IFC, SSN/SOSA, SAREF, and so forth can be used to describe the subsystems, their components, and interdependencies (e.g., in (Pauen et al., 2021)). More recent efforts such as the draft versions of Ashrae 223p standard ⁶ and the Information Modeling Framework (IMF) ⁷ are extending technical system design descriptions with more detailed description of the connections between the components.

Such ontologies model one or more of the following key aspects of structural descriptions in systems engineering (Van Ruijven, 2013; Borst et al., 1995):

1. 1. The mereological (compositional) relationships in terms of subsystems and components. For example, an AHU consists of a heating coil, which in turn, has a control valve.

2. 2. The topological relationships (i.e., the physical process relationship between mereological entities. For example, using the Brick ontology, one can state that a brick:Radiation_Hot_Water_System consists of a number of instances of brick:Radiators which are of type brick:Heat_Exchanger are placed in Rooms, and these are fed by an instance of a brick:Boiler.

3. 3. The domain-specific taxonomy to convey the functional abstraction of a component (see (Yang et al., 2019) for an extensive survey). For example, the class brick:Fan intends to describe all things that function like a stereotypical fan.

While ontologies such as Brick capture a component’s functional abstraction and integrate this with mereological and topological relationships, they do not seek to describe the physical manifestation of the behavior of a component, which is what we claim to be required to answer the questions posed in the introduction. We hence seek to further integrate (in a way that is compatible with Brick and other widely used ontologies) knowledge about relevant aspects of this stereotypical behavior. We acknowledge (and support) that this knowledge might be further integrated with full simulation models of a component (e.g., towards realizing verifiably safe cyber-physical systems, see (Garcia et al., 2019)); however, we propose that an abstraction on the level of functional stereotypes permits the automated query-answering across a broad range of relevant topics (such as AFDD) while remaining simple enough to be deployed in typical building automation systems.

Physical processes are typically described as sequences of physical mechanisms, each of which is managed by a component in the system (Borst et al., 1995; Benjamin et al., 1996). Several ontologies (such as OntoCape (Morbach et al., 2009), TSO (Pauen et al., 2021), and PhysSys (Borst et al., 1995)) have been created for the purpose of describing physical processes and mechanisms. These ontologies, which are grounded in standard physics and engineering knowledge, principally define a physical process as a series of physical mechanisms involving the transformation of energy, substance, or work. According to Borst (Borst et al., 1995; Borst et al., 1997), these transformees are referred to as physical stuff, and the transition of stuff between process mechanisms is referred to as flow. Examples of such flow of stuff include flow of air in a duct, electric current in a wire, heat through a conductor, or force transmitted through a mechanical linkage. Therefore, the term streams or process pathways is meant for describing and distinguishing the semantics of flow of stuff that occurs through a complex chain of components—for example, supply, extract, and so forth To accomplish the automated inference of answers to questions such as those presented in the introduction, we hence require compatible ways of modeling the process mechanisms and associating them with the respective technical components in a specific deployment.

The association of a technical component with a process mechanisms is a commonality in these ontological approaches, which also stems from their origin in process and systems engineering theory. Therefore, when components are connected to one another through their terminals or ports, their mechanisms are deemed to influence one another such that stuff flows between them—thereby creating a physical process; however, today, in building automation, neither the technical system description nor the physical process ontologies capture this coupling.

Furthermore, our approach needs to provide a way of describing each process mechanism to convey knowledge about the transformation it performs. This is typically done using mathematical equations where the state of the physical mechanism is represented using process variables, which are measurable quantities. The behavior of individual mechanisms which are described using mathematical models (for example, using the EngMath (Gruber and Olsen, 1994) ontology) can then be used by solvers to determine static and dynamic state changes in the process. The mathematical models are constructed either from first principles of the physics involved or using system identification, which is an approach where dynamical systems are observed, and a model of their behavior is built using statistical methods. However, creating such models for systems deployed in buildings is typically too expensive in practice due to the effort involved in modeling the mechanisms and their mathematical equations (Wetter, 2019); this is due to models for real-life subsystems often requiring extensive parameterization together with the computational effort required to simulate them.

On the other hand, engineering design primarily relies on considerably simplified representations of these equations, which are presented in the form of tables and graphical plots in datasheets and design handbooks, and these are sometimes referred to as operational model (Yoshioka et al., 2004). For example, the datasheet of a centrifugal fan contains characteristic curves depicting the fan’s operation under different conditions. In addition to such information about a specific product’s characteristics, an engineer has generalized heuristic knowledge about the physical principles involved—for example, affinity laws (see (Stewart, 2018)) state the dependency between the speed of a fan’s impeller and the resulting flow rate. At an even more abstract level of understanding, from such theory of widely applicable physical principles, one can recognize the independent and dependent variables (DVs) involved in a physical mechanism. Although such a simplistic understanding is rarely sufficient when designing a system, it does provide valuable knowledge to gain a high-level understanding of a deployed system’s functioning. Past work on enabling automated fault detection has emphasized the importance of modeling physical mechanisms (House et al., 2001; Chitkara, n.d.; Ramanathan et al., 2021; Bi et al., 2024). For example, the knowledge that the speed of a fan’s impeller determines the outlet flow rate, when coupled with structural knowledge that the fan feeds a heat exchanger, and that a heat exchanger’s output (stereotypically) is influenced by rate of air flowing in, serves to link the behavior of the fan to that of the heat exchanger. An approach to model such an elementary abstraction of the physical principles and their link to the technical components in a building automation system is missing today. While in (Hodges, 1995) understanding of simple mechanics is captured using an ontology, this is limited to understanding human interactions with mechanical tools and does not address physical processes.

In (Ramanathan and Mayer, 2024), we showed that linking knowledge about physical processes to technical system design enables the automated selection of control programs in dynamically changing systems. Further to this, in (Ramanathan et al., 2024), we describe an ongoing research where software agents use Hypermedia interactions to discover and use models which can be used to infer (or simulate) the behavior of technical systems.

We address this gap in our approach by modeling stereotypical knowledge about the physical mechanisms that a system component is involved in and by integrating this knowledge in a way that is compatible with widely used ontologies for building automation components. We claim that this enables the system to know enough about its functioning by allowing formal reasoning on top of this knowledge. This would, for example, enable automatically reasoning about the potential effects of an automation program on the physical process, or to determine faults in the system that lead to unexpected functioning of a control program. The integration of mathematical models, which would permit deeper inspection of the system’s behavior (at higher cost), remains possible with our approach.

3. Component stereotypes

In the previous Section, we pointed out that physical mechanisms managed by components can be described in a generalized manner by solely identifying their independent and DVs and their inter-relationships. Such a description would already offer valuable knowledge for several use cases that require a high-level understanding of the system functions. We also highlighted that current ontologies for structural description of systems provide domain-specific taxonomies to classify components according to functional abstraction and describe their interconnections in the system topology. However, we argue that an approach to interlink structural descriptions and knowledge of physical mechanisms is missing—i.e., an approach is required that goes beyond component classification and topological description to include knowledge of physical mechanisms such that we understand how a component, and further, a system of interconnected components functions. Figure 2 illustrates the high-level concepts in the two aspects that would be involved in the bridging and integration towards enabling automated reasoning by software agents.

Figure 2. The figure shows a high-level view of the concepts used in descriptions of system design and models of physical mechanism modeling. We show that stereotypes of components can be described by interlinking the two aspects. The stereotypes enable software agents to infer the physical behaviour of individual components and the system as a whole in a qualitative manner.

To address the bridging of structural description of a component to it’s underlying physical mechanism, we introduce the idea of stereotypes. To illustrate our idea of a stereotype, let us consider the supply fan in our AHU example (Figure 1). We can imagine a stereotypical fan as having an air inlet, outlet, and impeller shaft; these form the fan’s technical interfaces. We further know that a fan uses centrifugal pressurization mechanism, whereby the speed of the impeller (caused by torque applied at the shaft) determines the air flow rate (observable at the air outlet and inlet). Now, when presented with an actual fan instance, we may integrate this stereotypical knowledge to gain insight into how this instance can be acted upon and how it would behave in response. We can further use this to investigate the relationships between the fan instance and other technical components in a system, such as the heating coil in the AHU.

The idea of a component stereotype which we put forward encompasses stereotypical knowledge of (1) the technical interfaces typically provided by the component kind and (2) the underlying physical mechanism such a component uses. Physical mechanisms, such as heat exchange or pressurization, may apply to more than one component kind. For example, centrifugal pressurization, where input kinetic energy is transferred to a fluid, causing its static and dynamic pressure to rise, is a general physical mechanism that is applicable to both fans and pumps. Our proposed approach allows for the description of such general physical mechanisms in a way that it can be reused in multiple component stereotypes. The resulting component stereotype is also agnostic of the exact context in the process. For example, the stereotype of a fan applies regardless of whether it is used to drive airflow for heat exchange or ventilation. In other words, a stereotype is a reusable artifact for the domain. It is not specifically crafted for a particular instance of a component, a system, or the role a component plays in a system. This supports practical applicability of our approach—when supplied with a topological model of component instances, the only remaining task during engineering is to link these instances to suitable stereotypes.

Based on the possibility of describing the stereotypical behavior of individual components, we show that the topological relationships between the components described in the system design can be used to infer the influence components have on each other. In other words, based on the stereotypes of the individuals, we can progress toward describing the collective behavior of the interconnected components of a system.

In the following subsection, we describe in detail the ontology we developed to support the formal representation of the component stereotypes. Then, in Section 4, we show how this ontology can used in real-life systems.

3.1. Elementary: an ontology for stereotyping

We propose Elementary, an ontology ⁸ to support the creation of stereotypes and the interlinking with topology-oriented system descriptions such as those based on Brick.

The design of our ontology specifically targets supporting the use cases of AFDD and plausibility checking where the principal needs are to be able to automatically infer (1) the cause of change in the state of physical stuff observed at a given position in the process and (2) the expected physical effect (in the system) of manipulating a quantity of stuff at an interface of a component.

To serve this purpose, Elementary addresses three key aspects that are involved in integrating knowledge regarding physical mechanisms, technical interfaces of components, and physical processes managed in a system of connected components:

1. 1. A way to describe physical mechanisms that will enable us to infer how it affects the physical stuff flowing through it.

2. 2. A way to describe the technical interfaces of the stereotypical components so that we can link them to the description of the physical mechanisms. The links will enable us to infer at which technical interfaces quantities of stuff can be observed or manipulated.

3. 3. Concepts that enable inferring effect of interactions between the components that are part of a process.

In the following subsections, we elaborate on the above requirements, refining them into more specific design objectives. To serve these objectives, we propose ontological classes, relationships, and semantic queries. Later in Section 4, we describe how to integrate elementary into existing system descriptions. In that Section, we also show that the concept of component stereotypes is generally relevant for use cases where understanding the high-level behavior of the components in a system is required.

3.2. Physical mechanisms

In this Subsection, we will first explain the design objectives for semantic modeling of physical mechanisms. Following this, we will briefly describe the concepts known in the traditional modeling methods. These concepts are not only valuable for addressing our requirements but also form the foundation for our model, which we will detail in Section 3.2.1. Then, in Section 3.2.2, we highlight the challenge of expressing the trajectory of the response of the mechanism and propose a solution to it. Finally, in Section 3.2.3, we show how our model enables semantic queries to be constructed, which address the requirements that we started off with.

Based on our study of the use cases, our objectives for modeling physical mechanisms are:

• • PM1: It should be possible to infer which physical stuffs (and their quantities) flowing into a mechanism will influence a given physical stuff flowing out of it. This is required for automated diagnostics programs to track causation. For example, this will enable us to know that the temperature of air flowing out of the heat exchange mechanisms is influenced by the flow rate and temperature of water flowing into the heat exchange.

• • PM2: Vice versa to PM1, it should be possible to infer the expected effects of manipulating a quantity of a given physical stuff flowing into the mechanism of physical stuff flowing out of it. This is required for fault detection programs that need to verify if a manipulation resulted in the expected effect.

We consider that indicating (1) the quantity of the physical stuff that is affected, and (2) the trajectory (also known as qualitative proportionality) (Top and Akkermans, 1991)) in terms or increase/decrease of the quantity as being sufficient to address the needs of our use-cases.

In order to develop an ontological model that can permit semantic queries to answer the above needs, we studied existing ways in which physical mechanisms are specified today. Numerical models are based on established physical laws and are expressed using equations composed of variables representing physical quantities. For example, the outlet air temperature $ {T}_{aout} $ in the heat exchange mechanism shown in Figure 3 is given by the algebraic equation:

$$ {T}_{aout}=\frac{\eta \cdot \left({c}_w\cdot {Q}_w\cdot \left({T}_{win}-{T}_{wout}\right)\right)}{\left({Q}_a\cdot {c}_a\right)}+{T}_{ain} $$

Figure 3. The stereotypical mechanisms of a valve and a heat exchange and their associated variables. The yellow circles represent the terminals or ports of the component which uses the mechanism. We show that our proposed model for physical mechanisms provides a qualitative understanding of both the individual mechanisms and the effect they have on each other. For example, it will enable us to infer that both $ {P}_w $ and $ \theta $ can influence $ {T}_{aout} $ .

The above equation includes the physical parameters for the heat transfer efficiency $ \eta $ , and $ {c}_w $ and $ {c}_a $ , the specific heat capacities of water and air.

In simulation models, variables represent the quantity of physical stuff that flows in/out of the mechanism. The models can be configured with the required physical parameters. Internally, a simulation model may employ mathematical equation solvers, dynamic programming, finite element analysis, etc.

In both numerical and simulation models, a variable is stated in terms of the physical stuff (i.e., the substance, effort, or form of energy) and its quantity. Quantities represent observable properties such as flow rate, pressure, height, active energy, and temperature. They are based on quantity kinds that are expressed in terms of more fundamental physical dimensions. For example, radius is a quantity, whereas the underlying quantity kind is length. The measurement units accompanying the statement of variables’ numerical values are based on the underlying quantity kind. Where the phase of a substance (i.e., solid, liquid, gas, or plasma) or form of energy or effort (e.g., thermal, electrical, mechanical forces, etc.) can be transformed by the mechanism, the variable is additionally annotated with the information regarding the phase or form.

A variable is related to a physical mechanism through two attributes: (1) by stating its position with respect to the boundary of the mechanism, and (2) by stating its role in the mechanism. In process engineering, the position of a variable with respect to a mechanism is enumerated as being at its inflow, outflow, across, or as remaining contained (i.e., the substance does not physically flow out of a containment). Variables with position across carry a significant physical meaning: they represent effort, which causes the flow of substance (Borst et al., 1995; Tiller, 2001). For example, voltage across a resistor causes the flow of current (i.e., electrical charge).

Some examples of descriptions of variables based on the above concepts include “flow rate of fluid at the inflow of heat-exchange mechanism”, “pressure difference across a throttle”, and “the temperature of the substance contained in a heat-transfer mechanism”.

The role of a variable is classified as independent variable (IV) and dependent variable (DV)—in mathematical equations, IVs appear as parameters of a function whose output is one or several DVs. In other words, by changing the values of IVs, the mechanism’s response can be observed as changes in the DVs. Though several IVs may influence a single DV, only a subset of them is meant to be manipulated, i.e., changed by external action)—in controls engineering theory, such a variable is called a manipulated variable (MV).

In summary, in numerical and simulation models, variables are described by: (1) the physical stuff whose state a variable represents, (2) the quantity the variable conveys (e.g., temperature, energy content, pressure, or force) (Borst et al., 1995; Preisig, 2021; Cessenat et al., 2018), and (3) their position with respect to the physical mechanism. In the context of the AHU example, Figure 3 shows the process variables associated with the process mechanism of heat exchange, i.e., the stereotypical mechanism underlying the heating coil’s functioning. Here, $ {T}_{aout} $ is a DV which is influenced by $ {Q}_a $ , $ {Q}_w $ , $ {T}_{ain} $ , and $ {T}_{win} $ —that is the IVs, among which $ {T}_{win} $ are $ {Q}_w $ are the MVs.

Although most physical mechanisms in building systems exhibit one-to-one relationships between MVs and DVs, there are several cases where a single MV influences more than one DV (e.g., compression can cause a decrease in volume and increase in temperature), or vice versa, where several MVs influence a single DV (e.g., in a heating coil where both flow rate and water inlet temperature influence the air temperature). On the other hand, the disjointness of MVs and affected DVs in a mechanism indicates the presence of two distinct underlying mechanisms (Top and Akkermans, 1991) and thus motivates refactoring the model (see (Borst et al., 1997; Tiller, 2001) for a more thorough treatment of this topic).

3.2.1. Modeling mechanisms and their variables

Based on the concepts that we identified in numerical and simulation models of process mechanisms, we created OWL classes and relationships in the Elementary ontology (see Figure 4). The concepts are centered around the classes elem:PhysicalMechanism and elem:ProcessVariable.

Figure 4. Left: The principal classes in the Elementary ontology for modeling physical mechanisms. On the right is an example illustrating the use of the concepts to describe the variable $ {T}_{aout} $ of the heat exchange mechanism that was shown in Figure 3.

A elem:ProcessVariable represents an observable property of a physical stuff involved in the elem:PhysicalMechanism.

In Elementary, the relationships elem:dealsWithStuff, elem:hasProcessPosition, and elem:hasQuantity are provided for describing a elem:ProcessVariable. Individuals of class elem:ProcessMechanism are then related to one or more instances of elem:ProcessVariable through the relationships elem:hasIndependentVariable (or its sub-type elem:hasManipulatedVariable) and elem:hasDependentVariable. To describe the physical stuff, we reuse terms from the Brick and QUDT ontologies (In Section 4.2, we explain in more detail the integration to other ontologies).

To illustrate the above-described classes and relationships, the following snippet in RDF/Turtle shows part of a stereotype for the heat exchange mechanism:

:heat-exchange rdf:type owl:NamedIndividual, elem:PhysicalMechanism ;

elem:hasDependentVariable:outlet-air-temperature;

elem:hasIndependentVariable:inlet-air-temperature;

elem:hasIndependentVariable:inlet-air-flowrate;

elem:hasManipulatedVariable:inlet-water-flowrate;

elem:hasManipulatedVariable:inlet-water-temperature;

# An example variable:

:oulet-air-temperature rdf:type owl:NamedIndividual, elem:ProcessVariable ;

elem:dealsWithStuff brick:Air; elem:hasProcessPosition elem:outflow;

elem:hasQuantity brick:Temperature.

3.2.2. Trajectory of DVs

To express the expected trajectory in terms of being directly or inversely proportional to the response of a DV to changing an MV in the mechanism, we need to address two challenging situations. First, in many process mechanisms, the direction of response also depends on the state of IVs other than the MVs. In the heat-exchanger example in Figure 3, the trajectory of the DV $ {T}_{aout} $ , in response to changing the MV $ {Q}_w $ , depends on the difference $ \Delta {T}_{wa}={T}_{ain}-{T}_{win} $ ; if $ \Delta {T}_{wa}>0 $ , then $ {T}_{wout} $ would be inversely proportional to $ {Q}_w $ , else, it would be directly proportional. Second, the response curve may not be monotonic. For example, in AC circuits, the power peaks at the resonance frequency and then begins to drop. Also, where the physical system has inertial elements, the trajectory of the DV may not immediately change, or it may depend on how the MV is changed (e.g., in an adiabatic process). In contrast, in other mechanisms (e.g., power dissipation in a resistor), the relationship between the MV and DV is monotonic and dependent only on MVs. In such cases, the trajectory follows a simple algebraic (e.g. Ohm’s law) or differential equation.

We considered two possible approaches to address the above challenges: (1) to describe numerical models of the response trajectories in RDF using the EngMath ontology (Gruber and Olsen, 1994), or (2), to link the description of the mechanism to a software simulation model which simulates the static and dynamic tendencies of the mechanism.

Description of numerical models in RDF and their usage (which involves a solver) by the client application would require complex engineering. The effort is especially disproportional when we require only the qualitative indication of the trajectory. Therefore, following the second variant, we introduce a novel way to semantically describe and link functional mock-up units (FMUs) to the description of mechanisms. FMUs are portable simulation programs whose interfaces are defined using the functional mock-up interface (FMI) specification. ⁹ In (Ramanathan and Mayer, 2024), we showed that FMUs (as software artifacts) could be linked to the semantic description of the components. Software programs, when they need to understand the physical effects of invoking an action on the component, follow the link to download and execute the FMU. An FMU, when supplied with values of the input variables, can provide both instantaneous output values based on a static model or time-series data obtained using a dynamic model.

FMUs can be semantically described using the FMUOnt ¹⁰ ontology. In our approach, we bridge FMUOnt (fmu:) to Elementary in such a way that an FMU appears to be a PhysicalMechanism. The FMU’s input and output variables are mapped to instances of PhysicalVariables using a set of simple semantic rules. For example, the following rule maps the IVs of a physical mechanism to the inputs of an FMU:

$$ {\displaystyle \begin{array}{l}\forall m,f\;\left( Physical\; Mechanism(m)\right)\hskip0.3em \wedge \hskip0.3em SimulationModel(f)\hskip0.3em \wedge \hskip0.3em hasSimulationModel\left(m,f\right)\\ {}\hskip-10.5em \wedge \exists {i}_m,{i}_f,s,q,u\;\Big(\wedge PhysicalStuff(s)\hskip0.3em \wedge \hskip0.3em PhysicalQuantity(q)\hskip0.3em \wedge \hskip0.3em Unit(u)\wedge \\ {}\hskip7.12em hasIndependentVariable\left(m,{i}_m\right)\hskip0.3em \wedge \hskip0.3em dealsWithStuff\left({i}_m,s\right)\hskip0.3em \wedge \hskip0.3em hasQuantity\left({i}_m,q\right)\wedge \\ {}\hskip7.12em elem: hasUnit\left(q,u\right)\hskip0.3em \wedge \hskip0.5em fmu: hasInput\left(f,{i}_f\right)\wedge \\ {}\hskip7.12em fmu: hasMedium\left({i}_f,s\right)\hskip0.3em \wedge \hskip0.3em fmu: hasUnit\left({i}_f,u\right)\to owl: sameAs\left({i}_m,{i}_f\right)\end{array}} $$

The following listing shows an example FMU of a heat-exchange mechanism written in Modelica language ¹¹:

model HeatExchange “Transfer of heat between two fluids”

parameter Modelica.Units.SI.Efficiency u = 0.8; //arbitrary value

parameter Modelica.Units.SI.SpecificHeatCapacity c_w = 4182.0;

parameter Modelica.Units.SI.SpecificHeatCapacity c_a = 1.0;

Modelica.Thermal.HeatTransfer.Interfaces.HeatPort_a port_pa;

Modelica.Thermal.HeatTransfer.Interfaces.HeatPort_b port_pb;

Modelica.Thermal.HeatTransfer.Interfaces.HeatPort_a port_sa ;

Modelica.Thermal.HeatTransfer.Interfaces.HeatPort_b port_sb ;

equation

port_pa.Q_flow + port_pb.Q_flow = 0 “Conservation of mass”;

port_sb.Q_flow + port_sa.Q_flow = 0 ;

port_sa.T = u * (c_w *(port_pa.T - port_pb.T) * port_pa.Q_flow) / (c_a * port_sa.Q_flow) - port_sb.T “Heat transfer equation”;

end HeatExchange;

The following RDF snippet shows the description of an example FMU:

:fmu-heat-exchange rdf:type owl:NamedIndividual, fmu:FMU;

elem:hasTarget <http://server/fmus/heat-exchanger.fmu>;

fmu:hasInputVariable :port_sa.T;

fmu:hasOutputVariable :port_sb.T;

fmu:hasInputVariable :port_pa.T;

fmu:hasInputVariable :port_pa.Q_flow.

# An example variable:

:port_pa.Q_flow rdf:type owl:NamedIndividual,fmu:InputVariable ;

fmi:hasIdentifier “port_pa.Q_flow”;

fmu:hasMedium fmu:Water; # same-as brick:Water;

fmu:hasUnit fmu:m3/s. # same-as qudt:M3-PER-SEC.

The above FMU is related to the elem:PhysicalMechanism through the property elem:hasSimulationModel:

:heat-exchange rdf:type owl:NamedIndividual, elem:PhysicalMechanism;

elem:hasSimulationModel :fmu-heat-exchange;

At run time, a software agent (e.g., for AFDD) that wants to reason about a physical mechanism can download the linked FMU binary and automatically match its inputs and outputs to the physical variables. Following this, the software agent can feed the model with the actual observed or hypothetical values of IVs and examine the changes in the outputs to determine if there was an increase or decrease in their values.

Apart from the approach of semantically describing FMUs and linking them to physical mechanisms, for cases where the response of DVs is monotonically and independently related to MVs, we provide the properties directProportion and inverseProportion to relate an MV to a DV. The following example shows its usage:

:pressurization rdf:type owl:NamedIndividual, elem:PhysicalMechanism;

elem:hasManipulatedVariable :inflow-impeller-speed;

elem:hasDependentVariable :outflow-fluid-staticpressure;

:inflow-impeller-speed elem:directProportion :outflow-fluid-staticpressure.

3.2.3. Semantic queries

Machine-understandable descriptions (in RDF) of physical mechanisms modeled using the ontological concepts we proposed can now be used to answer semantic queries that address the requirements we started out with. In the case of PM1, we required determining the MVs that influence a given DV. Given a mechanism $ m $ , the following query ¹² returns the variables that can be manipulated in order to affect the quantity $ q $ of a stuff $ s $ that flows out(representing the DV):

SELECT ?mv ?effect ?fmu WHERE {

:m a elem:PhysicalMechanism.

:m elem:hasDependentVariable ?dv; elem:hasManipulatedVariable ?mv.

?dv elem:dealsWithStuff :s; elem:hasQuantity :q.

{?mv ?effect ?dv} UNION {:m elem:hasSimulationModel ?fmu}.

}

In addition to the MVs, the query above returns how the MV influences the DV either as the relationship in known in RDF (that is the predicate elem:direct/inverseProportion) or the IRI of the description of an FMU that corresponds to the mechanism $ m $ .

In the case of PM2, we need to find the potential effect of varying the quantity $ q $ of a stuff $ s $ that flows in to a mechanism $ m $ . Here, the $ s $ and $ q $ may be either represented by an IV or MV.

SELECT ?iv ?dv ?effect ?fmu WHERE {

:m a elem:PhysicalMechanism;

:m elem:hasDependentVariable ?dv; elem:hasIndependentVariable ?iv.

?iv elem:dealsWithStuff :s; elem:hasQuantity :q.

{?iv ?effect ?dv} UNION {:m elem:hasSimulationModel ?fmu}.

}

3.3. Components and their Interfaces

Several technical systems ontologies, such as OntoCape, PhysSys, TSO, and the draft versions of Ashrae 223p and IMP already define the concept of a terminal, connection point, or port to refer to a physical interface offered by a (concrete) component through which flow of physical stuff can be observed or effected (Borst et al., 1995; Morbach et al., 2009; Pauen et al., 2021). Such a port is specified in terms of the physical stuff that flows through it, together with the direction with respect to the component in which it flows (e.g., an “air inlet” of a heating coil).

We shall see in Section 3.4 that physical variables of the underlying mechanism of a component can be linked to its interfaces so that a software agent can know at which interface the variables can be observed (or manipulated). Further in Section 3.5, we shall see that ports also play an essential role in helping to infer process relationships between components.

Further, in a system whose function is automated, physical stuff flowing through a component is monitored and manipulated at its ports by sensors and actuators of a controller. Consequently, the context of the sensors and actuators, and the data point representing them, are specified in terms of the component’s ports. For example, it is common to see informal descriptions of data points like “temperature at the air outlet of the heating coil” or “position of valve at the water inlet of the heating coil”. The PhyDiT ontology ¹³ proposed in (Ramanathan and Mayer, 2024) provides concepts to model such contextualization formally.

Our requirements for a model of component interfaces are, therefore:

• • CI1: It should be possible to infer the physical stuff that flows in/out of or contained in the component.

• • CI2: It should be possible to relate a component’s ports to physical variables of the underlying mechanism.

• • CI3: It should be possible to query the data point (i.e., of the sensor/actuator) related to the quantity of physical stuff at a component’s port.

We propose the class elem:Stereotype(See Figure 5) to capture the concept of component stereotypes. An instance of a elem:Stereotype is defined to be also an instance of specific component kind (e.g., a brick:Boiler). A concrete instance of a component (e.g., a particular boiler in a building) can be linked to its stereotype using the relation elem:hasStereotype.

Figure 5. The principal classes in the Elementary ontology for modeling a component and its ports.

We reuse the class tso:Connection_Point to represent a port along with the newly added relation elem:deals_WithStuff, which links a port to individuals of elem:PhysicalStuff. These individuals could be of type brick:Substance, elem:Effort (from PhySys), or tso:Energy .

Since ports are semantically qualified as inlet or outlet depending on the direction of the flow, we propose the sub-classes elem:InletConnectionPoint and elem:OutletConnectionPoint. Bi-directional ports would then be modeled as instances of both these classes. Further, some components have storage or containment for substance. For example, the tank for fluid in a thermal storage or for the chemical substance in a battery. In Elementary, we provide the class elem:Container, which can be a partOf a elem:Component. An instance of a elem:Container, by being also a subclass of a elem:Stereotype, can have inlet and outlet connection points. In addition to this, a elem:Container can have elem:Measurement_Ports to which sensors that monitor the state of the contained substance can be related (e.g., “sensor monitoring the temperature of water in the tank”).

The following example in RDF illustrates how the above-described concepts can be used to describe a stereotypical electric boiler and its ports:

hvac:stype_electric_ boiler rdf:type owl:NamedIndividual,

elem:Stereotype, brick:Electric_Boiler;

elem:hasConnectionPoint :water-inlet; elem:hasConnectionPoint :water-outlet;

elem:hasConnectionPoint :electrical-power-inlet; elem:hasPart :boiler-tank.

:water-inlet rdf:type owl:NamedIndividual, elem:InletConnectionPoint;

elem:dealsWithStuff brick:Water.

:electrical-power-inlet rdf:type owl:NamedIndividual, elem:InletConnectionPoint;

elem:dealsWithStuff elem:electrical_energy.

:water-outlet rdf:type owl:NamedIndividual, elem:OutletConnectionPoint;

elem:dealsWithStuff brick:Water.

:boiler-tank rdf:type owl:NamedIndividual, elem:Container;

elem:dealsWithStuff brick:Water;

elem:hasConnectionPoint :measurement-port.

:measurement-port rdf:type owl:NamedIndividual, elem:MeasurementPort;

elem:dealsWithStuff brick:Water.

A concrete instance of a boiler can now “inherit” the description of its stereotype by simply linking to it:

:boiler-01 rdf:type owl:NamedIndividual, elem:Component, brick:Electric_Boiler;

elem:hasStereotype hvac:stype_electric_ boiler.

3.3.1. Semantic queries

Description of stereotypical component interfaces such as the one shown above can be used, for example, to query ports of a concrete component $ c $ through which a given stuff (e.g brick:water) flows in/out:

SELECT ?port WHERE {

:c a elem:Component; elem:hasStereotype ?sc.

?sc elem:hasConnectionPoint ?port.

?port elem:dealsWithStuff brick:water.

}

Further, the following query determines if a substance (e.g brick:water) is contained in a component, and if so, retrieves the ports through which its state can be observed:

SELECT ?port WHERE {

:c a elem:Component; elem:hasStereotype ?sc.

:sc elem:hasPart* ?part.

?part a elem:Storage; elem:dealsWithStuff brick:water.

?part elem:hasConnectionPoint ?port.

?port a elem:MeasurementPort.

}

Finally, the following query addresses our requirement CI3, where we can list the data points corresponding to a port $ p $ :

SELECT ?point WHERE {

:c a elem:Component; elem:hasStereotype ?sc.

:sc elem:hasConnectionPoint :p.

:p elem:dealsWithStuff ?stuff.

{?point a brick:Sensor.} UNION {?point a brick:Command}

?point elem:relatedTo :p.

?point brick:hasSubstance ?stuff.

}

Inferring the relationship of the component interfaces to variables (i.e., CI2) will be addressed in Section 3.4.

Having created the means to specify process semantics for a component’s ports, we now describe our approach to linking it to the stereotypes of the physical mechanism and variables we achieved in the previous step.

3.4. Linking Components Interfaces to Mechanisms

The description of a general physical mechanism achieved in Section 3.2 allows us to query which IVs can be manipulated and the corresponding DVs that are influenced by the manipulation. Next, we require a way that permits us to link ports of a stereotypical component to the description of the physical mechanism it uses. For example, heating coils, such as the one in the AHU, use the heat exchange mechanism described in Section 3.2. Now, we need a way to infer which port of the heating coil is involved in manipulating the MV representing the water flow rate. A domain expert would, in this case, know that this interface is the water inlet port, similar to the case of a fan, where an expert would know that mechanical force input at the shaft manipulates the fan speed.

Considering the example of the fan in the left part of Figure 6, a typical domain expert would be aware of these facts:

• • The fan uses the process mechanism stereotype of pressurization;

• • the air pressure and volumetric flow can be observed at the inlet and outlet connection points; and

• • the shaft of the fan’s impeller (i.e., another port) can be supplied with torsional force to increase its speed; and

• • increasing the speed of the impeller will result in increased air flow through the fan.

Figure 6. An example of a fan with its stereotypical physical mechanism, associated variables, and relation to the connection points.

This association is illustrated on the right side of Figure 6.

Based on these observations, to enable the automatic inference of such knowledge, we link the interfaces of a component kind to the (stereotypical) process mechanism the component uses. Therefore, our requirement toward the ontological concepts is as follows:

• • CL1: Given a ConnectionPoint of a stereotypical component, it should be possible to infer the associated PhysicalVariable in the underlying PhysicalMechanism. And vice versa, given a variable, it should be possible to identify the port at which it can be monitored or manipulated.

• • CL2: It should be possible to find the inlet ports and the physical quantities that can be manipulated to influence a quantity of physical stuff at a given outlet port. And vice versa, it should be possible to determine which physical quantities (and the ports) would be influenced in response to manipulation of a quantity at an inlet port.

In the fan example, linking the process variables to the corresponding ports enables software agents to automatically infer that changing the mechanical force input to the impeller shaft will result in a change in the volumetric flow rate at the fan’s air outlet. Therefore, a component stereotype (like hvac:centrifugal-fan) should link the description of its typical technical interfaces to the description of a general physical mechanism (like hvac:centrifugal-pressurization) that is used by it (Figure 7).

Figure 7. Concepts to link physical mechanisms to components.

To accomplish this, we provide the relationship elem:isRelatedToVariable with elem:ConnectionPoint as domain and elem:ProcessVariable as range. In many cases, the designer of the component stereotype furthermore knows if an elem:ConnectionPoint is meant to be used to manipulate a process variable. In such cases, the relationship can be specified using the property sub-type elem:manipulates. Where a variable has position across, a port is related to it either as elem:hasMinuendOf or elem:hasSubtrahendOf. This helps to list the ports across which the differential value of the variable can be observed or manipulated.

Our model needs to furthermore consider that a DV of a mechanism might also affect upstream mechanisms—for example, a flow caused by a centrifugal pressurization mechanism in a fan results in a suction effect at the inlet port, which in turn will cause air to flow through upstream components. We model this through the relationship elem:upstreamEffect, which relates a PhysicalMechanism to a PhysicalVariable that represents the stuff and its quantity that can be affected upstream of the component.

The following snippet shows an example of these relationships applied in the context of the definition of a stereotypical fan (in RDF/Turtle).

:centrifugal-fan rdf:type owl:NamedIndividual, elem:Stereotype, brick:Fan ;

elem:hasConnectionPoint :cp_fan_air_inlet, :cp_fan_air_outlet, :cp_fan_shaft;

elem:hasMechanism hvac:pressurization.

:cp_fan_air_outlet rdf:type owl:NamedIndividual, elem:OutletConnectionPoint ;

elem:dealsWithStuff brick:Air; elem:isRelatedToVariable hvac:inlet-air-pressure.

:cp_fan_shaft rdf:type owl:NamedIndividual, elem:InletConnectionPoint ;

elem:dealsWithStuff elem:torsional_force; elem:manipulates hvac:shaft-speed.

3.4.1. Semantic queries

Towards addressing CI2, CL1, and CL2, the following SPARQL query finds the port and the variable that can be manipulated to influence the quantity $ q $ of stuff $ s $ flowing out of the component:

SELECT ?inlet ?iv ?outlet ?dv WHERE {

:c elem:hasStereotype ?sc. ?sc elem:hasProcessMechanism ?m.

?m elem:hasIndependentVariable ?iv; elem:hasDependentVariable ?dv.

?iv elem:affects ?dv.

?dv elem:dealsWithStuff :s; elem:hasQuantity :q.

?sc elem:hasConnectionPoint ?inlet.

?inlet elem:manipulates ?iv.

?outlet elem:realtedTo ?dv.

}

3.5. Inferring process relationships

In this section, we explain how the stereotypes of the individual components that are interconnected in a system collectively help infer the process relationships. For example, in the AHU (Figure 1), increasing the air flow rate (by increasing the fan speed) affects the air outlet temperature of the heating coil (assuming constant energy input to the heating coil). To infer this relationship, we require an approach that automatically links the DVs of one component to the IVs of other affected components.

Often topological descriptions of technical systems, like those based on Brick or IFC, do not model connection points of components (like, for example, in TSO) explicitly but instead link the components with one another using a generic relationship such as brick:feeds. On the one hand, using a generic relationship between components makes it easier to create system design descriptions. Still, on the other hand, it is not expressive enough when we want to understand the process relationships—Figure 8 illustrates this situation.

Figure 8. Modeling a connection between two components (fan and heating coil) using a generic feeds relationship is insufficient to infer which specific connection points are connected (e.g., it is not clear whether the fan air outlet is connected to the heating coil’s water inlet or its air inlet). However, by considering the characteristics of the connection points, inferences can be drawn about their relationship (orange dashed line), and further, about relationship between the variables (green dashed line).

In a system scenario, components are parts of streams (see Section 2): a concept that is essential in describing the semantics of a connection point and process relationships between components. For example, an AHU economizer has two air inlet ports, one for the fresh-air stream, while the other for the extract-air stream. These two ports cannot be distinguished solely based on the description of the related variables because they both have the same stuff, quantity, position, and role. The distinguishing factor here, i.e., “fresh air” and “extract air”, are not physical properties of the air itself, but are the labels assigned to the streams. Application domains define well-known stream kinds. In HVAC, for example, supply, extract, exhaust, bypass, recovery and so forth are well-known stream kinds.

Our ontology supports the integration of streams by providing a class elem:Stream and permits assigning these to domain-specific elem:StreamKind (through the property elem:hasStreamKind). Component instances may be assigned to one or more elem:Streams through the elem:isPartOf relationship (See Figure 9). A elem:ConnectionPoint may be specified to be suitable for a particular elem:StreamKind using the relationship elem:suitableFor.

Figure 9. Elementary offers a novel way to specify (and therefore, distinguish) the process role of ports by including the concept of streams. In the example on the right, the air-inlet is stated to be suitable for supply stream.

In order to infer connection between ports described by the respective stereotypes of two components (in a feeds relationship), we match the following characteristics of the ports:

1. 1. Matching Stream: Both components should be part of the same elem:Stream

2. 2. Compatible Directionality: Only an elem:OutletConnectionPoint of the source component can connect to an elem:InletConnectionPoint of the target component.

3. 3. Compatible Stuff: Both connection points should deal with the same (or compatible) physical stuff.

4. 4. Matching StreamKind: In case multiple ports of a component stereotype have the same attributes in terms of directionality and physical stuff, the elem:StreamKind of the ports should match.

We define a symmetric property elem:isCompatibleTo that is inferred if two ConnectionPoints deal with the same physical stuff. Additionally, the subproperty isFlowCompatibleTo is inferred if the domain is an OutletConnectionPoint and the range an InletConnectionPoint.

Using the classes and properties, the above matching rule can be expressed formally as

$$ {\displaystyle \begin{array}{l}\hskip-21em \forall x,y\;\left( Component(x)\hskip0.3em \wedge \hskip0.3em Component(y)\wedge feeds\left(x,y\right)\right)\to \\ {}\hskip-13em \exists s,k\;\Big( Stream(s)\hskip0.3em \wedge \hskip0.3em streamKind\left(s,k\right)\hskip0.3em \wedge \hskip0.3em partOf\left(x,s\right)\hskip0.3em \wedge \hskip0.3em partOf\left(y,s\right)\wedge \\ {}\hskip-13.1em \exists {p}_x,{p}_y\;\Big( OutletConnectionPoint\left({p}_x\right)\hskip0.3em \wedge \hskip0.3em InletConnectionPoint\left({p}_y\right)\wedge \\ {}\hskip6em hasConnectionPoint\left(x,{p}_x\right)\hskip0.3em \wedge \hskip0.4em hasConnectionPoint\left(y,{p}_y\right)\wedge \\ {}\hskip6.12em suitableFor\left({p}_x,k\right)\hskip0.3em \wedge \hskip0.3em suitableFor\left({p}_y,k\right)\hskip0.3em \wedge \hskip0.4em isFlowCompatibleTo\left({p}_x,{p}_y\right)\Big)\to connectedTo\left({p}_x,{p}_y\right)\end{array}} $$

For two elem:ConnectionPoints which are inferred to be connected using this set of rules, the DV of the elem:OutletConnectionPoint is consequently inferred to elem:manipulates the IV related to the elem:InletConnectionPoint to which it connects. If a component has a DV that is also an elem:upstreamEffect of the mechanism, then it is inferred that the component elem:manipulates IVs on the upstream component which are in terms of physical stuff and quantity same as the DV. For example, a DV representing volumetric flow rate of air at the outlet of a fan can be stated to affect IVs in upstream components. In the case of our AHU example in Figure 1, this feature can used to infer that changing the air flow at the fan outlet will also change the air flow through the damper, filter, and the heating coil.

Expressed formally:

$$ {\displaystyle \begin{array}{l}\hskip-2em \forall {p}_x,{p}_y\;\left( OutletConnectionPoint\left({p}_x\right)\hskip0.3em \wedge \hskip0.3em InletConnectionPoint\left({p}_y\right)\hskip0.3em \wedge \hskip0.3em connectedTo\left({p}_x,{p}_y\right)\right)\\ {}\hskip-11.12em \wedge \exists {v}_x,{v}_y,{m}_x,{m}_y,s,q\;\Big( PhysicalMechanism\left({m}_x\right)\hskip0.3em \wedge \hskip0.3em PhysicalMechanism\left({m}_y\right)\wedge \\ {}\hskip4em hasDependentVariable\left({m}_x,{v}_x\right)\hskip0.3em \wedge \hskip0.3em hasIndependentVariable\left({m}_y,{v}_y\right)\hskip0.3em \wedge \hskip0.3em isRelatedToVariable\left({p}_x,{v}_x\right)\wedge \\ {}\hskip4em isRelatedToVariable\left({p}_y,{v}_y\right)\hskip0.3em \wedge \hskip0.3em PhysicalStuff(s)\hskip0.3em \wedge \hskip0.3em PhysicalQuantity(q)\hskip0.3em \wedge \hskip0.3em dealsWithStuff\left({v}_x,s\right)\wedge \\ {}\hskip4em hasQuantity\left({v}_x,q\right)\hskip0.3em \wedge \hskip0.3em dealsWithStuff\left({v}_y,s\right)\hskip0.3em \wedge \hskip0.3em hasQuantity\left({v}_y,q\right)\left)\right)\to manipulates\left({v}_x,{v}_y\right)\end{array}} $$

Hence, we propose to infer process dependencies between actual components with the help of their respective stereotypes. For example, using this approach, we come to know that the outlet air temperature of an instance of a brick:Heating_Coil is influenced by the connected instances of brick:Fan (influences air flow) and brick:Heating_Valve (influences inlet water flow).

The following query lists all components that can influence quantity $ q $ of stuff $ s $ at port $ p $ of a component $ x $ :

SELECT ?y WHERE {

:x a elem:Component; elem:hasStereotype ?sx.

?sx elem:hasDependentVariable ?dv; elem:hasIndependentVariable ?iv.

?dv elem:hasPhysicalStuff :s; elem:hasQuantity :q.

?iv elem:hasPhysicalStuff ?siv; elem:hasQuantity ?qiv.

?sx elem:hasConnectionPoint ?px.

?px elem:isRelatedToVariable ?iv; elem:suitableFor ?stream.

?y a elem:Component; elem:hasStereotype ?sy.

{:x brick:feeds* ?y} UNION {?y brick:feeds* :x}.

{?sy elem:hasDependentVariable ?dv_y} UNION {?sy elem:upstreamEffect ?dv_y}.

?dv_y elem:hasPhysicalStuff ?siv; elem:hasQuantity ?qiv.

?sy elem:hasConnectionPoint ?py.

?py elem:isRelatedToVariable ?dv_y; elem:suitableFor ?stream.

}

This enables both automatically inferring potential influences of manipulating a component interface on system functioning (e.g., in fault detection) and tracing potential causes of an observed effect on components and their interfaces. We now describe some practical aspects, use cases, and challenges faced during the application of our approach. Then, in Section 5, we evaluate how concepts in elementary can be mapped successfully to existing domain models and test its effectiveness in reasoning about the physical processes.

4. Practical application of our approach

4.1. The scope of elementary

To understand the general concepts required to model physical mechanisms, we studied several applications in the building systems and factory automation domain. These include (1) heat generation, exchange, and transfer, (2) refrigeration, (3) humidification, (4) fluid (air and water) transportation and pressurization, and (5) electrical power distribution and control. From a more generalized view of the mechanisms, our model addresses continuous and discrete processes. Similarly, the variables can be instantaneous values or time derivatives (this generalization is achieved by utilizing the concept of quantity and quantity kinds from the QUDT ontology when specifying the variables).

However, our simplified approach towards qualitative modeling of physical mechanisms is limited to only providing an understanding of how quantities of physical stuff are influenced. It does not explain changes in a substance’s chemical structure or phase. For example, the phase of a refrigerant changes from liquid to gas while flowing across an evaporator. In this case, the phase transformation is an intrinsic effect of change in the refrigerant’s temperature under particular pressure conditions.

Therefore, by focusing on high-level concepts involved in modeling physical mechanisms and aiming to provide broad classification of the responses (or by linking to more elaborate simulation models), the concepts in our ontology become applicable to other domains with similar use cases.

4.2. Integrating with existing systems

One of our goals while developing Elementary was to ease its integration into systems that are based on existing engineering ontologies like Brick. Therefore, we reuse and bridge the terms and relationships from the several openly available engineering ontologies. An overview of Elementary and its relationship to other ontologies is shown in Figure 10. From TSO, OntoCape, and PhySys, we reuse concepts concerning physical processes, mechanisms, and flow of physical stuff. We bridge to Brick to reuse abstract concepts related to system design and to QUDT to use RDF instances depicting substance and quantities. To evaluate the ease of integration, we created a library of stereotypes for HVAC component kinds (prefix: hvac) available in the Brick ontology. The systems we used for our evaluation (see Section 5) are modeled using the Brick ontology and are linked to stereotypes in this library. The following example, as a snippet in RDF, illustrates how two of the components of our AHU example that are modeled using Brick can be linked to their corresponding stereotypes:

urn:fan_01 a brick:Fan;

urn:fan_01 brick:feeds urn:heating_coil_01;

urn:fan_01 elem:hasStereotype hvac:centrifugal-fan.

urn:heating_coil_01 a brick:Hot_Water_Coil;

elem:hasStereotype hvac:heat-exchanger;

brick:feeds urn:fan_01.

Figure 10. The Elementary ontology and its relation to other ontologies. Actual systems are modeled using Brick, and each component instance in the system is linked to a stereotype in the domain-specific library of stereotypes for HVAC components.

In the above snippet, we see two instances which are classified as brick:Fan and brick:How_Water_Coil and topologically linked using the brick:feeds relationship. The structural description of a fan feeding a heating coil is extended by solely linking the components to the description of their stereotypes. We have shown how the stereotypes hvac:centrifugal-fan and hvac:heat-exchanger are created and how they lead us to infer the semantics of the process. The above example enabled us to infer that the temperature of air at the outlet of the heating coil is influenced both by the speed of the fan and the rate and temperature of water flowing into the heating coil.

4.3. Design and engineering life-cycle

For concrete application of our approach, we foresee that reusable component stereotypes are created by a domain expert who then shares them in a library (e.g., like the HVAC component library ¹⁴ shared by us). Creating the stereotype of a component, such as a fan shown in Figure 6, is a three-step process:

1. 1. A stereotypical instance of the component class (e.g., brick:Fan) is created, and its physical ports are modeled as instances of elem:ConnectionPoints.

2. 2. Physical mechanisms the component manages are modeled through an instance of elem:PhysicalMechanism, which is then linked to dependent and independent physical variables. Such a mechanism model can be reused for stereotypes of other component kinds.

3. 3. Finally, the physical variables are linked to the connection points of the component.

Therefore, in terms of the physical process model, the domain expert needs to solely identify the dependent and IVs of the mechanism.

After creation, employing a stereotype is straightforward: An instance of the (real) component in the system design can be linked to a corresponding stereotype using the relationship elem:hasStereotype. This linking can also be accomplished automatically by adding a constraint to the component class (i.e., every brick:Fan elem:hasStereotype hvac:Fan). In a real-life example of an air-handling unit (AHU) resembling the one in Figure 1, the system was modeled using the Brick ontology. On the knowledge graph containing the description of the AHU, the following SPARQL statements were used to insert the stereotype relationships automatically:

INSERT {?component elem:hasStereotype ?stereotype} WHERE {

?component a brick:Equipment.

?stereotype a elem:Stereotype.

?component a ?type. ?stereotype a ?type.

?type owl:subClassOf+ brick:Equipment.

}

Application example

A commonly used fault-detection rule employed for AHUs is to check if a change in valve position or inlet temperature of water to a heating/cooling coils results in a noticeable response in supply air temperature (House et al., 2001). Viewed from the perspective of the underlying physical mechanism, i.e., heat-exchange, the fault detection rule aims to verify if change in thermal energy input also results in a change of air temperature (given a constant flow rate). Our approach helps generalize such rules by addressing the underlying mechanism. In the case of the heating/cooling coil, the following semantic query returns the MVs corresponding to the DV of an outlet air temperature of a heat exchanger. Therefore, for such cases, software programs can use a generic rule to check if the change in any of the MVs resulted in an expected change in the DV.

SELECT ?mv ?dv ?effect ?fmu

WHERE {

?c a brick:HeatExchanger.

?c elem:hasStereotype ?sc.

?sc elem:hasConnectionPoint ?p.

?p elem:relatedToVariable ?v.

{?m elem:hasManipuatedVariable ?mv} UNION {?m elem:hasIndependentVariable ?dv}

{?mv ?effect ?dv} UNION {?m elem:hasSimulationModel ?fmu}

}

4.4. Use cases

Our approach was applied in practice for two use cases in the industry: (1) To test and detect if electro-mechanical actuators in buildings are stuck in a fixed position and (2) to add diagnostic hints to alarms related to HVAC systems that are shown on a building management system (BMS).

Detecting stuck actuators

Electro-mechanical actuators such as those for valves and dampers are (also) prone to failures. One of the common fault modes is failure of the gear train, where the effect is that the physical actuation fails, and the valve or the damper remains stuck at a fixed position. This fault can remain undetected for a long time and often results in energy wastage or under-performance that is not immediately noticeable by the building occupants (Chitkara, n.d.; Gwerder et al., 2022). To detect such faults automatically, an AFDD program needs to know which physical variables are expected to be influenced by the actuator. More precisely, the physical variable can be one that is directly manipulated by the actuator (e.g., flow rate) or one that is consequently affected (e.g., air temperature). Sensors may be installed to observe either or both of the variables. Furthermore, a variable may be influenced by multiple actuators. Through the integration of a component stereotype with the system description, an AFDD program can find the physical variable, and further, the sensor that observes the variable. This enables creating fault detection rule that is not tightly bound to a specific installation or configuration of components.

Supplementing alarm messages

BMS are configured to notify the operator when the value of a physical variable (observed by a sensor) is out of pre-defined bounds. Often, the variable in question is influenced by a complex chain of physical mechanisms whose states the operator has to examine to determine the possible cause. This process requires the operator to understand how the components and their actions influence the variable in question. Our approach helps identify the possible actuations (and the involved components) automatically and adds this inference to the alarm message. This results in a smaller subset of components that the operator must investigate. Therefore, an alarm notification (e.g., caused by low temperature in a room) can be augmented with knowledge about the components that might have a fault. For example, to an alarm message “Room 1: temperature low”, we add a further hint “Heated by VAV unit. Check damper and valve for malfunction.”. Such hints could further be refined based on reasoning about the state of the control program. In (Ramanathan and Mayer, 2024), we have shown that, similar to component stereotypes, the behavior of standard control logic can also be semantically described in a qualitative manner. With such additional knowledge, we can, for example, infer that the control program was indeed trying to operate the actuators, and therefore, the fault lies in the electro-mechanical parts of the system.

4.5. Challenges encountered in practice

Accounting for the influence of control systems

In a process with interconnected components, say $ {c}_i $ and $ {c}_j $ , the observed influence of $ {c}_i $ on $ {c}_j $ (upstream or downstream) is subject to the reactions of control programs that may be operating on $ {c}_j $ . Taking the AHU as an example, increasing the fan’s speed will cause an increased air flow rate through the heating coil. If we go according to the (uncontrolled) mechanism of heat exchange in the coil, the temperature of the air at the outlet should decrease in response. However, a closed-loop control designed to maintain the outlet air temperature of the coil would have reacted by increasing the water flow rate, thereby maintaining the air temperature (almost) unchanged. With knowledge about the actions of the control program, it is possible to infer whether the heating coil is functioning correctly. Our approach allows AFDD and plausibility checking programs to know the potentially counter-acting effects of control programs because the link between MVs and actuators (and further the control program) can be inferred (the ontological concepts proposed in (Ramanathan and Mayer, 2024) enables integration of description of control programs).

Modeling branching and merging of flows

A physical mechanism that is challenging to model is that of branching and merging of flows. In branching, the quantity that flows out of each branch depends on the influence of the branches’ downstream component(s). For example, consider the case of two fans $ {fan}_1 $ and $ {fan}_2 $ in a parallel flow configuration shown in Figure 11. If the speed of $ {fan}_1 $ is increased, it will cause the expected increase in air flow rate through the upper branch. But, it will also cause a decrease in airflow in the lower branch. Similarly, in the case of merging, increasing the flow through a branch will cause flow in the parallel branch to be reduced because of increased head pressure on $ {fan}_2 $ . We addressed this challenge by adding new classes hvac:Splitter and hvac:Joiner as component types in our HVAC ontology. Corresponding to these, we modeled mechanisms hvac:substance-flow-splitting and hvac:substance-flow-merging. In these mechanisms, the flow through a branch is dependent on the IV representing pressure difference across the inflow and the branch/merge. In this way, any upstream mechanism that influences the pressure at the branch/merge can be inferred to change the flow rate in the branch. Further, since splitting and merging mechanisms ideally conserve mass, energy, and momentum, the sum of quantities at inflow(s) is considered to be equal to the quantities at the outflow. In Section 5, while evaluating the results of a test case, we point out that system design ontologies like Brick need to include splits and joins in conduits as components.

Figure 11. On the left, a stream of air is split and supplied to two branches. Without an explicit model of the mechanism (splitter) shown on the right, it is not possible to infer that increasing the flow rate $ {Q}_1 $ by $ {fan}_1 $ can potentially affect $ {Q}_2 $ through $ {fan}_2 $ . The model on the right allows us to state that both $ {P}_1 $ and $ {P}_2 $ are upstream effects (shown shaded) of pressurization occurring in the fans. Additionally, the explicit mechanism of the splitter relates to the flow rates.

Modeling building spaces

In HVAC systems, air and thermal energy are supplied to or extracted from rooms (i.e., spaces in general) for the purpose of maintaining temperature, humidity, pressure, and air quality. The spaces, when viewed as containment (of air and thermal energy), have several physical mechanisms that are active. Heat is lost or gained through the walls, air leaks in or out of the space, and gasses like ( $ {CO}_2 $ ) are added or extracted from the air. Therefore, models of mechanisms like heat and mass transfer are applicable when modeling the behavior of spaces. To apply such mechanisms, we need to model spaces as “components” with “ports”, such as those for air inlet/outlet, and heat gain/loss to the surrounding. Further, the surrounding, i.e., the outside ambient, needs to be modeled as a generic component representing a sink or a source of physical stuff (See Figure 12). The Brick ontology models rooms or spaces as purely location elements (to which equipment can feed substance). To overcome this situation, that is without having to sub-class brick:Room as brick:Equipment, in our HVAC ontology we create a stereotypical hvac:Space as a elem:Component which has a elem:Container as part. In this way, it can be assigned as a stereotype of an instance of brick:Room—this, for example, enables a software agent to infer that the temperature of air contained in the room is influenced by temperatures of both outdoor air and the hot water flowing into a radiator placed in the room.

Figure 12. By modeling building spaces as components, we can define a stereotype to which mechanisms like heat transfer (e.g., equation shown in gray box) can be related. The space is then connected to other upstream and downstream components and the ambient (modeled as source/sink).

5. Evaluation

We report on two types of evaluations we have performed on our approach: (1) To examine the expressivity and generalizability (see Section 5.1) and (2) to study its effectiveness when reasoning about the component’s role in a process (see Section 5.3).

5.1. Applying stereotypes to brick components

The use of the Brick ontology to model technical systems in real buildings has shown that its component classes are sufficient to cover common HVAC applications in buildings (Balaji et al., 2016), and we use this result to demonstrate that our proposed approach can be used to describe the component stereotypes for these classes. From the subclasses of brick:HVAC_Equipment, we identified all classes that represent components—i.e., those which use a distinct physical mechanism.

After the identification of all such components ¹⁵ in the Brick ontology, we created stereotype definitions consisting of descriptions of physical mechanisms and technical interfaces. This creation of stereotypes was done together with a HVAC domain expert, and we then related these definitions to the classes of components in Brick. Table 1 shows that our proposed stereotypes can be applied to all Brick components and can hence be used to describe what action can be taken on a component together with its physical effects.

Table 1. Classes of components available in Brick and the proposed mechanism that the stereotype is related to. The ports (IP: inlet port and OP:outlet port) are mapped to variables in the mechanism

For the stereotypes which we associated with the Brick classes, we then verified if it is possible to find out the relationships between the input interface, the process variable it manipulates, the process variable that will be affected, and the output interface of the component where the effect can be observed.

To evaluate this, we used the SPARQL queries listed in Section 3 to run on the HVAC stereotypes ontology, and presented the results (see Table 2) to three HVAC domain experts. The domain experts confirmed that our system’s results were correct and sufficient to gain a high-level understanding of the IVs, MVs, and DVs in the components and to identify the connection points where the MVs can be manipulated.

Table 2. Querying the stereotype mechanism description suggests which port(s) of the component (that uses the mechanism) can be acted upon. It further links this manipulation to the MVs and gives the outlet ports at which this effect can be observed

5.2. Applying stereotypes to photovoltaic system components

For a practical application involving AFDD for small-scale photovoltaic (PV) systems (Ramanathan and Marella, 2022), we applied our approach of modeling stereotypes for the components in the PVOnt ontology ¹⁶ (See Table 3). We were able to successfully model component interfaces and the underlying mechanisms. As pointed out in (Ramanathan and Marella, 2022), the configuration of PV systems varies from one installation to another, and this makes it challenging to define fault detection rules that is common to all. The advantage of modeling the underlying mechanisms is that rules can be formulated based on fundamental physics quantities and laws (such as conservation of energy). For example, the following query in SPARQL is used to find the total outflowing current from batteries connected to a controller so that it can be matched to the total current flowing to the loads:

SELECT SUM(?batcur_val) as ?total_output SUM(?lodcur_val) as total_input

Table 3. The component classes in PVOnt ontology which we modeled as stereotypes using Elementary. The table shows the interfaces of the components (primarily electrical terminals) and the underlying physical mechanism corresponding to the components.

WHERE {

?bat a pvont:Battery. ?con a pvont:Controller. ?lod a pvont:Load.

?con brick:feeds ?bat. ?con brick:feeds* lod.

?bat elem:hasStereotype ?sbat. ?lod elem:hasStereotype ?slod.

?sbat elem:hasVariable ?batcur. ?batcur elem:quantity qudt:Ampere.

?batcur elem:hasPosition elem:outflow. ?batcur elem:value ?batcur_val.

?slod elem:hasVariable ?lodcur. ?lodcur elem:quantity qudt:Ampere.

?loadcur elem:hasPosition elem:inflow. ?loadcur elem:value ?loadcur_val.

}

The above query is agnostic of the system configuration (e.g., the number of batteries, the circuit, and the loads). This reinforces our premise that the concepts proposed in Elementary are generic and can be applied to several domains. Also, by allowing domain experts to focus on the underlying physical mechanisms, we enable the creation of more generally usable analytic programs.

5.3. Understanding processes using stereotypes

To identify topologies of physical processes commonly seen in building systems, we studied the following systems: boilers, chillers, AHUs, air- and water-distribution systems, and low- and medium-voltage electrical systems (including captive power generation). These cover the sub-classes of brick:System. From this study, we identified four characteristic topologies: (1) Flow of a single primary stuff through a linear sequence of mechanisms with energy being added or removed to lateral streams; (2) splitting or merging of streams involving the same stuff; (3) transfer of energy between stuff (of same or different kind) flowing in two separate streams; and (4) splitting a stream into multiple parallel processes, which then later re-join.

To evaluate whether our approach in reasoning about a component’s role in a real process, we examined the HVAC subsystems in an office building consisting of about 180 rooms located across six floors which are served by central plants like AHUs, boilers, and chillers. From the system’s engineering data available to us in this context, we found that AHUs in several configuration variants were present, each of which displayed one or more of the four characteristic topologies we identified before. We identified the following four system kinds (SKs), in increasing order of complexity, under which the AHUs (see Figure 13) could be classified:

1. 1. SK1: Fresh-air AHU (FAHU). Topologically and process-wise, this represents a simple sequence of components and their physical mechanisms in a single stream.

2. 2. SK2: Recirculation AHU (RAHU). In addition to the features of a FAHU, a RAHU also has the merging and splitting of air streams. This hence extends the simple sequence of components to a situation where components in different streams influence each other.

3. 3. SK3: Energy-recovery AHU (ERAHU). In this case, an energy recovery component (heat exchanger) influences two process streams by transferring energy from one to another. This represents systems where an individual component manages flows of physical stuff (and, hence, dependencies) across different streams: Other than in the RAHU where the recirculated air stream enters the supply-side components directly, the ERAHU only transfers heat (and not air mass) between the two streams.

4. 4. SK4: Parallel-Fan AHU (PFAHU): This case introduces the parallel operation of two components (fans), which separate from a stream and later rejoin. This represents systems that feature parallel mechanisms that are stereotypically equivalent and feed jointly into a downstream component.

Figure 13. The four system kinds identified for our evaluation. The labels on different components (like oad or sufan) and process positions (like exair) are referred to in our results. The red triangles represent the test points (TP) identified in our evaluation.

We wish to emphasise here that though these SKs are based on different configurations of AHUs, the process topology kinds they represent are also seen in other systems such as in chiller and boiler plants.

We defined three test cases to evaluate if topological descriptions where components are associated with stereotypes of their process mechanisms can be used to infer (1) the process dependencies between the components, (2) the effect of a component on a process variable observed at a given position in the stream, and (3) the trajectory of a DV in response to manipulation of a MV. We now describe the three test cases and the results in further detail.

Test Case 1: Given two components whose connection is described using a generic feeds relation (such as brick:feeds), can our approach identify the physical process relationship between them?

Results: Table 4 summarizes the results for each pair connected components in each of the SKs. For each of the connections, our approach helps to identify which process variables are affected on the upstream and downstream sides. A HVAC domain expert examined the results and confirmed that the inferences were correct, and no connection or associated effects were missing.

Table 4. Interconnection of components identified by HVAC domain expert and the downstream effects (DSE) and upstream effects (USE) they have on each other in terms of process variables they influence. The components corresponding to labels like csp (conditioned space) can be found in Figure 13

Test Case 2: Find component(s) of a system which play a role in modulating a process variable observed at specified test points (TPs) in the process (e.g., “Which components influence the supply temperature observed at the outlet of the heating coil?”).

This test case is motivated by the use case of system diagnostics where a maintenance engineer attempts to identify components whose operation is likely to influence the process variable under question (see (Arroyo et al., 2014) for further details). To aid the evaluation, our approach permits the definition of TPs at various locations in each of the SKs chosen for evaluation (see TP markers in Figure 13). The TPs were chosen based on key process positions which are relevant for an AFDD use case (House et al., 2001). We asked a HVAC domain expert to list all components both upstream and downstream of the TPs, which would influence temperature and air flow rate at each TP. We then formulated SPARQL queries to automatically find instances of elem:Components that influence the temperature and airflow at each TP, and applied these queries to each of the four AHU configurations SK1-SK4.

Results: Our proposed automatic approach achieved 100% matching accuracy of influencing components in SK1 and SK3. At all TPs in these system kinds, our approach correctly identified the chain of dependencies between the components (we will refer to the components using the labels (e.g., suair) shown in in Figure 13). For example, in TP3 in SK1, the dependencies for air flow are sufan and oad, and the dependencies for air temperature are oa, oad, hcl, vlv, and sufan. Our approach performs equally well for SK3 because the energy transfer between two streams (supply and extract) is captured in the mechanism of the energy recovery component (erc), and therefore the flow of air in the streams is independent.

However, in SK2, our approach fails to correctly identify the influencing components at TP2, i.e., at one of the seven TPs; and in SK4, it fails with respect to two TPs—for all these errors, our approach underreported influencing components, i.e., while its precision remained at 100%, its recall dropped to 20% for TP2 in SK2 and to 66%/66% for TP3/TP4 in SK4.

Regarding SK2, our approach correctly identified that at all TPs flow is influenced by oad, sufan, exfan, and ehd. However, at TP2, our approach identifies only the outdoor air (oa) temperature as the variable that influences temperature, while an expert identifies five additional factors: exair, exfan, sufan, ehd, and oad; these determine how much air from the bypass will mix with outside air, and thereby influence the temperature at TP2. The reason for this underreporting of dependencies is that we are missing models of two mechanisms that play an important role in the upstream processes that determine the temperature at TP2: (1) a model of the conditioned space (csp), which would have led to inferring that return air (exair) temperature will influence temperature at TP2, and (2) a model of the mixing of physical stuff from the two streams after which TP2 appears. This problem could be remedied in our HVAC stereotypes ontology by modeling a conditioned space as a stereotypical component with thermal (e.g., for heat gain) and hydrodynamic (e.g., for air flow) physical mechanisms (see Section 4.5. Similarly, in Section 4.5, we have shown that the mechanism of splitting and merging of substance streams can be described.

However, for our evaluation, we chose to use a system that is modeled exclusively based on an already available ontology—in this case, Brick. An important learning in this regard is that entities that may not directly appear as components in a system topology (such as spaces, splits or joins in ducts, etc.) may play an important role in physical processes—these should, hence, be added to ontologies such as Brick.

With respect to TP3 and TP4 in SK4, our approach of chaining variable dependencies in upstream and downstream directions does not handle a case where the operation of one component affects the IV of another component in a parallel stream. Concretely, the expert identified that the operation of sufan1 will affect the inlet pressure of sufan2 (and vice-versa), and hence, the flow rate at both, TP3 and TP4, are dependent on both fans. This issue could be remedied in the same way as for SK2—that is, by modeling the splitting and joining of streams as explicit components.

Test Case 3: Given two directly connected components, find the trajectory of response due to change in MV of one on the DV of the other.

In this test case, we limit ourselves to a pair of directly connected components in a stream because otherwise a process involving splitting and merging of streams would require cosimulation to solve for steady state. This test case addresses scenarios where plausibility checking programs need to verify if design requirements involving two inter-connected components are effective at run time. For example, in an AHU designed for variable volume flow, the air flow rate through the heating/cooling coil is varied for fast response in temperature control. Therefore, changing the speed of the fan should elicit a corresponding response (i.e., increase or decrease of temperature depending on water temperature).

We considered three deployment scenarios (see Figure 14): S1: An electric motor with variable speed control driving a centrifugal fan, S2: a fan drawing air through a heating/cooling coil, and S3: a cooling coil feeding air to a heating coil for the combined purpose of dehumidification.

Figure 14. Three scenarios for testing combined effect on trajectory due to inter-connected components. In each case, we wish to infer the effect of a quantity manipulated at the port of a component (marked green) at the port of another (marked red). In S2 and S3, the trajectory depends on the temperature difference between ports marked blue.

In S1, we expect that increasing the frequency of the AC waveform for power input to the motor should result in an increase in airflow through the fan. In case of S2, we expect that, depending on the difference in inlet water and air temperature ( $ \Delta {T}_{wa} $ ), changing the speed of the fan should result in outlet air temperature changing with a slope that is proportional to $ \Delta {T}_{wa} $ . In case of S3, decreasing the inlet water temperature to the cooling coil should result in a decrease in relative humidity at the outlet of the heating coil if the $ \Delta {T}_{wa}>0 $ , else, it should result in an increase. For S2 and S3, an FMU, similar to the one described in Section 3.2.2, was used to model the heat-exchange mechanism (common for both heating and cooling coils). In these cases, the plausibility checking program obtains the FMU and matches the input and output variables. It then makes a step change in the input variable and then finds the slope of the response of the output variable.

Results: In all three scenarios, the plausibility checking program was able to automatically infer the response trajectories which matched with the expected values. For S2 and S3, the SPARQL query listed in Section 3.2.2 correctly matched the variables to the input and outputs of the FMU. Then, by providing the value of $ \Delta {T}_{wa} $ for the heat exchangers, the response trajectory was correctly adapted by the FMU.

6. Future work

Integrating Failure Modes and Effects into Stereotypes: FMEA is a widely used method for fault detection and diagnostics in industrial systems. In principle, this method describes the possible ways in which a component can fail and its effect on dependent components. For example, failure of a valve actuator will result in uncontrolled flow. The consequence of this effect is then analyzed in the context of dependent components (both upstream and downstream). We believe that this model can be integrated as a part of the component’s stereotype itself. Here, we seek to describe fault modes in terms of the states of the IVs, while the effect is described in terms of the states of the DVs.

Modeling Physical Laws: Several fundamental laws in classical mechanics, such as the conservation of energy and mass, can be applied widely and used to reason about both the individual mechanisms and the system as a whole. For example, we can assert that at run time, the total amount of a substance flowing into a mechanism input must be equal to the sum of that at the outlet(s) and the increase in the containment. We intend to extend Elementary with a description of such rules.

Assisting AI Methods: Integrating the models of technical systems and physical mechanisms through stereotypes not only enhances our understanding of these systems but also paves the way for innovative applications in AI-assisted methods. For instance, in an exploratory experiment, we trained a large language model with the verbalization of the system’s semantic description and the Brick ontology. The addition of component stereotypes significantly improved the model’s accuracy in responding to queries such as ‘What can cause temperature to drop at the air supply to the room?’ This demonstrates the practical value of integrating component stereotypes into AI-assisted methods. Component stereotypes can also help in a more targeted selection of input features for machine learning models (e.g., for neural networks) by discarding variables that do not influence the behavior we wish to analyze. Similarly, mathematical models (i.e., a PDE modeling the mechanism) can be linked to the stereotypes (similar to what we achieved with the FMUs) to automate the deployment of physics-informed neural networks.

Enabling automated engineering

In an ongoing work (Ramanathan et al., 2024) that builds upon (Ramanathan and Mayer, 2024), we are making component and system stereotypes available as Web resources so that autonomous automation agents can discover these at run time using Hypermedia interactions. Such interactions would enable autonomous software agents in a multi-agent system to discover means (i.e., systems and components) to achieve their goals (decomposed from requirements). Further, by reasoning about the behavior of the components and systems, the agents can synthesize or search for suitable control and coordination strategies.

7. Conclusions

Our approach introduces a novel method of ontology-guided modeling of the stereotypical behavior of components commonly used in building systems. We have shown that with this approach, we can create stereotypes corresponding to HVAC component classes in Brick, which can then be associated with actual instances of components in the system. Further, we validated using real-life engineering information that the stereotypes capture a high-level abstraction of the underlying physical mechanisms, which is sufficient to correlate possible actions on the component to the observable effects. This knowledge about the local behavior of each component in a system then helps us infer their cumulative effect on the physical process conducted by the system. We evaluated our approach on systems deployed in real life, which displayed largely positive results; however, in process topologies containing mixing mass flow streams, we identified the need and extended our system with a way to model physical laws that apply to the system in its entirety. Our work seeks to bring together research on semantic modeling of system design and physical processes. This opens up the possibility for software programs such as AFDD and plausibility checking to use machine-understandable knowledge to reason about a system’s behavior. For higher-fidelity system simulation, our approach is compatible with attaching complete simulation models to building automation components.