3.1. Elementary: an ontology for stereotyping

We propose Elementary, an ontologyFootnote ⁸ 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, Reference Top and Akkermans1991)) 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., Reference Borst, Akkermans, Pos and Top1995; Tiller, Reference Tiller2001). 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., Reference Borst, Akkermans, Pos and Top1995; Preisig, Reference Preisig2021; Cessenat et al., Reference Cessenat2018), 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, Reference Top and Akkermans1991) and thus motivates refactoring the model (see (Borst et al., Reference Borst, Akkermans and Top1997; Tiller, Reference Tiller2001) 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, Reference Gruber and Olsen1994), 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.Footnote ⁹ In (Ramanathan and Mayer, Reference Ramanathan and Mayer2024), 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 FMUOntFootnote ¹⁰ 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 languageFootnote ¹¹:

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.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., Reference Borst, Akkermans, Pos and Top1995; Morbach et al., Reference Morbach, Wiesner and Marquardt2009; Pauen et al., Reference Pauen, Schlütter, Frisch and van Treeck2021). 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 ontologyFootnote ¹³ proposed in (Ramanathan and Mayer, Reference Ramanathan and Mayer2024) 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:

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

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).

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 $ :

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.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:

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 libraryFootnote ¹⁴ 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:

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).

4.5. Challenges encountered in practice

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.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., Reference Balaji, Bhattacharya, Fierro, Gao, Gluck, Hong, Johansen, Koh, Ploennigs and Agarwal2016), 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 componentsFootnote ¹⁵ 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, Reference Ramanathan and Marella2022), we applied our approach of modeling stereotypes for the components in the PVOnt ontology Footnote ¹⁶ (See Table 3). We were able to successfully model component interfaces and the underlying mechanisms. As pointed out in (Ramanathan and Marella, Reference Ramanathan and Marella2022), 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., Reference Arroyo, Fay, Chioua and Hoernicke2014) 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., Reference House, Vaezi-Nejad and Whitcomb2001). 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.

Enabling automated engineering

In an ongoing work (Ramanathan et al., Reference Ramanathan, Mayer and Ciortea2024) that builds upon (Ramanathan and Mayer, Reference Ramanathan and Mayer2024), 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.