Advanced Building Simulation

196 Augenbroe
All data
Version 2
Building
Building
Model
Model
(schema) (schema)
All data
Version 3
Application A Application B Application C
Figure 8.3 File based exchange.
with other data items in the whole model is consistently reestablished. This approach
delegates the responsibility for model update and consistency management to each
application, which is an undesirable side effect of this approach.
As Figure 8.3 implies, there is an import and export interface for all applications;
in most cases this will be one and the same software program that is kept active while
the simulation application is running. The import interface performs the selection and
mapping to the native format of the application, whereas the export interface does
the reverse, and “reconstructs” the links between the processed data items and the
“untouched” data items in the complete model. To accomplish the latter, every software
application has to understand the full structure of the Building Model. This puts
a heavy burden on the interface developers, and debugging is extremely difficult
because a complete set of test cases is impossible to define upfront. Another barrier
to make the scenario of Figure 8.3 work is the fact that the data exchange scenario
has to be choreographed in a way that the rules of data availability (at input) and
data reconstruction (at output) are determinable in advance. In most cases, this will
not be possible. For instance, it may not be possible to guarantee that the required
data items are indeed available when the application is called. Calling the interface
when not all data items are available will result in the interface module to end in an
error message (“missing data”). It is usually hard to recover from this error message
as it is unclear who was responsible to populate the missing items. Avoiding this situation
to occur requires a certain level of preconditioning of the use-scenarios of the
applications. It also has to make assumptions about the data-generation process as a
whole. In-house interoperability typically allows extensive preconditioning and
choreographing. Most (if not the only) successful applications of the interoperability
according to Figure 8.3 have been implemented as local in-house solutions. For less
predictable scenarios it is obvious that more flexible approaches are necessary.
Even with the advent of PDT toolkits and the growing set of XML-based tools, the
development of an interface remains a daunting task, especially if it requires the
understanding and processing of an extensive, semantically rich model. One way to