ASHRAE Journal - October 2024 - 33

TECHNICAL FEATURE
system ideally happens as smoothly and effi ciently
as possible, meaning that the amount of hardcoding
within the control algorithms is preferably reduced (see
" late binding " starting in the " Early and Late Binding
of Metadata " section of the September 2024 article) .1 If
it is known clearly and in advance which kind of data
and features are represented by a certain data stream,
it becomes much easier and more scalable to design
and confi gure control systems and control strategies
appropriately.
For example, if a ventilation system is designed
and engineered to respond to specifi c humidity and
temperature values in a known format (e.g., MQTT
stream at specifi ed time intervals) and in a known
context (e.g., type of room, room characteristics), then
such a control algorithm can more easily be plugged
into similar buildings and spaces. As a result, the
algorithm becomes more portable, with the downside
that more effort needs to be put into making the model
more generic in order to support this.1 Therefore, data
streams are ideally tagged and annotated, such that
control algorithms can (semi-)automatically adapt and
reconfi gure based on the input data that they receive.
These tags and annotations represent the context of
the data stream, and, as mentioned in the September
2024 article, they are typically referred to as metadata:
" data that describes other data in order to help one
understand or use it. " 2
Of course, when adding metadata in an ad-hoc and
unstructured manner (e.g., building-specifi c labels;
see " early binding " in the September 2024 article), it
still is challenging to adapt to every different situation
that has very different descriptions about the data
streams and systems in the building. In such cases, data
streams and systems are described using all sorts of ad
hoc naming conventions, often in local languages and
using primarily human-readable text.3 To make the
use of such metadata more scalable, a need exists for
more standardized and more robust schemas, typically
referred to as metadata schemas (see " late binding "
in Reference 1). Examples schemas are the Smart
Applications REFerence ontology (SAREF),4 Haystack5
and Brick,6 which focus particularly on building systems
and devices in buildings.
Several others are available as well, especially in
the architecture, engineering and construction
(AEC) industry, where the use of metadata schemas
and standardized vocabularies have been practiced
and refi ned for decades,7,8 leading to widely used
vocabularies such as the linked building data (LBD)
vocabularies,9 the Industry Foundation Classes (IFC)10
and several more. The uptake of these metadata schemas
in the design and engineering of building systems, and
control systems particularly, is not easy, yet they are very
promising because of their potential in describing the
context of data in a data-driven smart building.
This article aims to clarify what the value is that these
emerging metadata schemas can bring. To what extent
is such meta-information or contextual information
of need or of value? Do we really need such labels and
annotations, and can't we simply rely on purely datadriven
work? What is the added value of having such
metadata available and where does it fi t in?
Prediction and Control: Making, Running,
And Engineering the Model
As discussed in the September article,1 in principle
prediction and control mechanisms for building systems
themselves do not necessarily require a lot of metadata:
black-box prediction models require just enough labels
to train the model, not more, and procedural code
ideally relies on a suffi ciently limited look-up table that
represents the data streams that it can process. So both
for making a model and running a model, the amount
of metadata and context to be included is ideally not
extensive. This can also be seen in practice, where the
data is often abundant and metadata is hard to fi nd.
The labels used for the data streams (e.g., the label
for a temperature sensor or an actuator at a specifi c
device location in the building) can in many cases be
considered leading reference points for making any
kind of implementation. These labels are preferably
standardized across multiple buildings, such that the
making of the models as well as the running of the
models can be relevant for all buildings that share
similar data streams.
But, is this the only potential use of these metadata
schemas and contextual labels in data-driven smart
buildings? Is metadata just a matter of tagging data
streams " just enough so that a black-box prediction
model can be trained and used " ? No! Besides making
and running the model, a third important use can
be distinguished-engineering the control model. We
consider this here to be similar to " making the model, "
O CTO B E R 2 0 2 4 ashrae.org ASHRAE JOURNAL
33

https://www.nxtbook.com/nxtbooks/ashrae/ashraejournal_ATMAHK/index.php#/p/52 https://www.nxtbook.com/nxtbooks/ashrae/ashraejournal_ATMAHK/index.php#/p/52 https://www.nxtbook.com/nxtbooks/ashrae/ashraejournal_ATMAHK/index.php#/p/52 https://www.nxtbook.com/nxtbooks/ashrae/ashraejournal_ATMAHK/index.php#/p/52 https://www.nxtbook.com/nxtbooks/ashrae/ashraejournal_ATMAHK/index.php#/p/52 http://www.ashrae.org

ASHRAE Journal - October 2024

Table of Contents for the Digital Edition of ASHRAE Journal - October 2024