14. GlossaryΒΆ

This section defines various technical terms that are used throughout the report.

Building Information Model (BIM)
A Building Information Model (BIM used as a noun) is an instance of a data model that describes a building and its components unambiguously, e.g. a digital footprint of a building and its properties, represented over its entire life cycle.
Building Information Modeling (BIM)
Building Information Modeling (BIM used as a verb) is a collaboration method to consistently acquire, manage, exchange and hand-over information of a building which are relevant over its entire life cycle, using digital models and targeting a consistent communication between parties.
Business Process Modeling Notation (BPMN)
Graphical notation to structure and display processes to formally and descriptively describe tasks, responsibilities and informations within IDM. So-called swim-lanes are used to graphically group elements, which belong to an actor respectively.
Industry Foundation Classes (IFC)
Object oriented data format for digital description of building information models. Open BIM data exchange standard developed by buildingSMART published as ISO 16739. Physical data exchange as Step (Express) or ifcXML data file.
Information Delivery Manual (IDM)
Method standardized as ISO 29481 to capture and specify processes and to define information exchange requirements in BIM. Usually as formal description of planning processes using Busines Process Modeling Notation (BPMN).
Model View Definition (MVD)
Part or subset of the IFC scheme which is defined in order to fulfil a single or multiple domain-specific exchange requirements. Typically, IDM serves as method to define these exchange requirements.
In Modelica, a package is a collection of models, functions, or other packages that are used to hierarchically structure a Modelica library.
In Modelica, a class is a term that includes models, blocks, functions and packages.
In Modelica, a connector is an instance of a class that is used to connect models and blocsk with each other. Connectors can contain constants, parameters and variables, but no equations.
Co-simulation refers to a simulation in which different simulation programs exchange run-time data at certain synchronization time points. A master algorithm sets the current time, input and states, and request the simulator to advance time, after which the master will retrieve the new values for the state. Each simulator is responsible for integrating in time its differential equation. See also model-exchange.
In Modelica, a block is a special case of a model in which all connectors are either inputs or outputs.
An event is either a time event if time triggers the change, or a state event if a test on the state triggers the change.
In Modelica, a model is a special class in which the causality of its connector need not be specified.
Model-exchange refers to a simulation in which different simulation programs exchange run-time data. A master algorithm sets time, inputs and states, and requests from the simulator the time derivative. The master algorithm integrates the differential equations in time. See also co-simulation.
zero-crossing function

A zero crossing function is a function that is used by solvers to indicate when variables cross a threshold. For example, suppose a thermostat should switch off a heater when the room temperature \(T_r(t)\) crosses a set point \(T_s(t)\). For this case, a zero crossing function is \(f(t) = T_r(t) - T_s(t)\).

Zero-crossing functions are used by numerical solvers to detect where such discrete changes in a model occur. Specifically, at \(t=t_1\), they search for \(\tau \in \arg \min \{ t > t_1 \, | \, f(t) = 0 \}\).

direct dependency

A variable is said to directly depend on another variable if there is an algebraic constraint between these variables. For example, consider the model shown in Fig. 14.1. If the input \(u\) changes, then the output \(y_3\) immediately changes, whereas \(y_1\) and \(y_2\) only change after time is advanced. Hence, the output \(y_3\) is said to have a direct dependency on \(u\). Similarly, the state derivative \(\dot x_1\) directly depends on the input \(u\), and \(\dot x_2\) directly depends on the state \(x_1\). The outputs \(y_1\) and \(y_2\) directly depend on the states \(x_1\) and \(x_2\), respectively. Hence, unless time is advanced, if \(u\) is updated, only \(y_3\) needs to be updated, whereas if \(y_1\) and \(y_2\) need not be updated. Such information is useful to detect the existence of algebraic loops, and to implement certain numerical time integration methods such as the QSS methods.


Fig. 14.1 Signal flow diagram that illustrates direct dependency.

Functional Mockup Interface
The Functional Mockup Interface (FMI) standard defines an open interface to be implemented by an executable called Functional Mockup Unit (FMU). The FMI functions are called by a simulator to create one or more instances of the FMU, called models, and to run these models, typically together with other models. An FMU may either be self-integrating (co-simulation) or require the simulator to perform the numerical integration.
Functional Mockup Unit
Compiled code or source code that can be executed using the application programming interface defined in the Functional Mockup Interface standard.
We say that a simulator is doing a rollback if its model time is set to a previous time instant, and all its state variables are set to the values they had at that previous time instant.
time event

We say that a simulation has a time event if its model changes based on a test that only depends on time. For example,

\[\begin{split}y = \begin{cases} 0, & \text{if } t < 1, \\ 1, & \text{otherwise,} \end{cases}\end{split}\]

has a time event at \(t=1\).

state event

We say that a simulation has a state event if its model changes based on a test that depends on a state variable. For example, for some initial condition \(x(0)=x_0\),

\[\begin{split}\frac{dx}{dt} = \begin{cases} 1, & \text{if } x < 1, \\ 0, & \text{otherwise,} \end{cases}\end{split}\]

has a state event when \(x=1\).