Advanced Building Simulation

16 Augenbroe
their performance in a particular case. A recent “postmortem” analyses on a set of
design projects revealed an ominous absence of the building performance analysis
expert in the early stages of the design process (de Wilde et al. 2001). The study shows
that, once the decision for a certain energy saving technology is made on the grounds
of overall design considerations or particular owner requirements and cost considerations,
the consultant’s expertise is invoked later for dimensioning and fine-tuning.
By that time the consultant is restricted to a narrow “design option space” which limits
the impact of the performance analysis and follow-up recommendations. In the light
of these observations, it appears a gross overstatement to attribute the majority of
energy efficiency improvements in recent additions to our building stock directly to the
existence of simulation tools.
In order to become an involved team player, the simulation profession needs to
recognize that two parallel research tracks need to be pursued with equal vigor:
(1) development of tools that respond better to design requests, and (2) development
of tools that are embedded in teamware for managing and enforcing the role of
analysis tools in a design project. One way to achieve the latter is to make the role of
analysis explicit in a so-called project models. A project model is intended to capture
all process information for a particular building project, that is, all data, task and
decision flows. It contains information about how the project is managed and makes
explicit how a domain consultant interacts with other members of the design team. It
captures what, when and how specific design analysis requests are handed to a
consultant, and it keeps track of what downstream decisions may be impacted by
the invoked expertise. Design iterations are modeled explicitly, together with the
information that is exchanged in each step of the iteration cycle. Process views of
a project can be developed for different purposes, each requiring a specific format,
depth, and granularity. If the purpose of the model is better integration, an important
distinction can be made between data and process integration. Data-driven tool interoperability
has been the dominant thrust of the majority of “integrated design
system” research launched in the early 1990s. It is expected that process-driven
interoperable systems will become the main thrust of the next decade.
1.4 New manifestations of simulation
Building simulation is constantly evolving. This section deals with three important
new manifestations. As so many other engineering disciplines, the building simulation
profession is discovering the WWW as a prime enabler of remote “simulation services.”
This will be inspected more closely in Section 1.4.1. Since the start of the development
of large simulation tools, there has been the recurring desire to codify
templates of standardized simulation cases. These efforts have had little success as
a framework for the definition of modular simulation functionality was lacking. This
may have changed with the advent of performance-based building and its repercussions
for normative performance requirements. Section 1.4.2 will describe these
developments and contemplate the potential consequences for the automation and
codification of simulation functions. Building automation systems, sensory systems,
and smart building systems (So 1999) will define the future of the “wired” building.
Embedded real time control and decision-making will open a new role for embedded
real time simulation. This is the subject of Section 1.4.3.