Advanced Building Simulation

Trends in building simulation 19
that a particular building system has towards a given function of that system or a
larger system of which it is a part. The quantification of a PI requires a (virtual)
experiment on the system under study. Every PI comes with exactly one experiment,
which describes exactly one system type, a particular experiment on that system, and
a way to aggregate the results of the experiment. One should keep in mind that a particular
function of a building system may have multiple ways of measuring the performance
of that system towards that function. Each different way of defining an
aspect or measuring method of that aspect leads to one unique PI.
The quantification of a PI is linked to a precisely defined experiment, which can be
conducted in whatever form as long as it generates the output states of the object that
need to be observed, analyzed and aggregated for the PI quantification process. In
fact, any form of aggregation that leads to a relevant measure of the behavior of the
building system is a candidate for a PI. The main qualification test on a PI is that it
can be unambiguously linked to a desired function of the object, can be reproduced
in repeated experiments and is meaningful to a design decision.
This provides an “artificial” framework for “interpretation-free” simulations with
the biggest proclaimed benefit that such simulations could be easily automated as
simulation agents in performance dialogues. This would not only underpin dialogues
during design evolution but also in commissioning and in-use building performance
monitoring (e.g. for continuous commissioning). Although many are trying to codify
performance indicators into standards, the link to a “pre-configured” set of simulation
functions seems as yet unlikely. After all, in order to deliver a reproducible
PI value, its associated analysis function (the “experiment”) needs to be executed in
an objective way hence its outcome must be independent of the expert and his tools.
This demand is necessary as it creates independence of the performance dialogue
from any particular simulation software. If this demand cannot be met, the result of
the design analysis dialogue becomes dependent on the particular software user
combination. Although this is clearly unwanted, it is not totally unavoidable. After
all, even under exactly defined circumstances, different tools provide slightly
different answers due to differences in modeling assumptions, solver accuracy, etc.
To support a PI-based dialogue adequately by simulation tools, one would have to
“accredit” a software tool for a given set of PIs. Different types of experiments will
require different “accreditation” methods. In a real experiment, it is not always
possible to control the input variables, whereas in a virtual experiment, one has only
limited control over the process assumptions and schematizations that the software
deploys for its native representation of the experiment. A thought experiment
seems even more subject to “biases” as too many judgment calls raise doubts on the
reproducibility across experts. It should be kept in mind, however, that the use of
virtual experiments is the very basis of the current design analysis practices. Indeed,
in order to support the expression of functional requirements by the design team
some behavioral experiment must be assumed and known to both the design team
and the experts. The introduction of the PI concept does not radically change
the fundamentals of this design analysis dialogue, it just makes it more precise
through formal specification and quantification of its elements. Use of a standard
PI guarantees that the purpose of the experiment (the performance) is understood
by all those engaged in the dialogue. This in itself is a tremendous step forward
from the current situation, where too much depends on interpretation of an