Advanced Building Simulation

Import
DT data
Export
DT data
DT schema
DT schema
Meshing
Stripping
Figure 8.6 Data exchange with off-line applications.
Developments in interoperability 199
IDM schema
IDM schema
The export and import management is handled according to predefined subschemas
for each application. This requires special functionality that needs to be added to the
data transaction functionality offered by commercial database systems.
Figure 8.6 shows how this was handled in the COMBINE project through a novel
data exchange kernel (DEK) which performs a bidirectional data mapping between a
global Building Model and the subschema of the application. The process of importing
data from the application exported STEP file into the DEK is referred to as
“meshing”, because it merges a partial model into a richer model. Analogous to this,
the process of exporting data from the DEK to an application subschema is referred
to as “stripping”, since it maps from a richer view of a building to a more limited
view and some entity types and relationships need to be stripped off.
The primary function of the added process management component is to manage
the data transaction events. Two forms of control must be regarded:
– rules and conditions determining when a specific actor can perform a particular
(simulation or design) operation (this is a type of temporal control);
– rules and conditions to ensure that the Building Model instance remains in a consistent
state while the design progresses (this is a type of data integrity control).
The approach that was taken in the COMBINE project implemented the two forms of
control as separate components. Data integrity control was implemented as “constraint
sets” in the database. The temporal control was based on the control logic embedded
in a so-called “Project Window” modeling formalism (based partly on Petri-Nets). The
models contain information about all communicating “actors” in the system (software
applications and other tools) and their input and output schemas. In addition, they
contain a formal description of the order in which these entities are allowed to execute
certain operations during design evolution, that is, obeying logic dependency rules.
The resulting event model formally defines the exchange event control. The
“Exchange Executive” component then uses the event model to control the transitions,
for example, check constraints and inform a simulation application about the data
availability and the ability to perform a simulation as the next step in the process.
DEK