Advanced Building Simulation

Developments in interoperability 205
documents, for example, in unstructured documents such as drawings, specifications,
etc., in semi-structured documents such as CAD files, and also partly in highly structured
documents such as populated IFC models. Within a design decision, an expert may be
consulted upon which a design analysis request is generated in some formal manner
(accompanied by a contractual agreement). Upon fulfillment of the request and completion
of the analysis, an analysis report is submitted to the design team. This report is then
used to perform a multi-aspect evaluation by the design team in order to fully inform a
pending design decision. This evaluation may lead to the generation of new design variants
for which a follow-up analysis request is issued. In many instances, a comparison
of design variants may already be part of the original design request and thus part of the
submitted analysis report.
As Figure 8.10 suggests, there are multiple interactions and information flows
between design and analysis tasks, each of them constituting a specific element of the
dialogue that needs to take place between the design team and the analysis expert. In
earlier works, the main emphasis has been on support for the data connections
between the design representations and the input or native models of the simulation
tools. Little work has been done on the backend of the analysis. Backend integration
requires the formal capture of the analysis results before they are handed back to the
design team. The most relevant work in both areas is linked to the use of the IFC as
structured design representation and recent work on representation of analysis results
embedded in the IFC (Hitchcock et al. 1999).
A design analysis framework should cover all elements of the dialogue and their
implementation in a configurable communication layer that drives the interoperable
toolset. The following sections explain the basic constructs of the dialogue and its
potential implementation such as a dialogue system.
8.3.2 A workbench for design analysis dialogues
The framework should encapsulate data interoperability in order to capitalize on
efforts that have been invested in the development of building product models over
the last decennium. It should not however be based on any limiting assumptions
about the design process or the logic of the design analysis interaction flow. The
framework should offer support for the interaction between the building design
process and a wide array of building performance analysis tools. This can be realized
through a “workbench” with four layers. The workbench positions building design
information on the top layer and simulation applications (and more generically
“analysis tools”) on the bottom layers. In order to move from design information to
analysis tool (pre processing) or from analysis tool to design relevant information
(post processing) one has to pass through two intermediate layers. Those intermediate
layers provide context to a specific interaction moment by capturing information
about the process and information about the structure of the exchanged data on two
separate layers, as shown in Figure 8.12. The two intermediate layers are the key
layers of the workbench. They allow the domain expert to manage the dialogue
between the design team (top layer) and the analysis applications (bottom layer).
Interoperability typically makes a direct connection between the top and bottom
layer through a data-mapping interface. The four-layered workbench is the “fat” version
of this traditional view on interoperability. The top layer contains all building