13.02.2013 Views

Advanced Building Simulation

Advanced Building Simulation

Advanced Building Simulation

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

200 Augenbroe<br />

Figure 8.7 Sample ExEx startup screen (from COMBINE report).<br />

Figure 8.7 shows a screenshot of the implemented Exchange Executive (ExEx)<br />

(Amor and Augenbroe et al. 1995). The event model is read by the ExEx, which is<br />

then automatically configured to assist the project manager at run time to decide<br />

which application can be executed next, and which applications are affected by<br />

changes to the <strong>Building</strong> Model and therefore need to be rerun. The state of the project<br />

moves as tokens through the network of “places” and “transitions” on the screen.<br />

It allows a team manager to decide whether a simulation software can be deployed<br />

next, based on the automatic checking of constraints.<br />

It has been stipulated in this section that interoperability requires more than a<br />

shared <strong>Building</strong> Model and a set of applications with appropriate interfaces. Two<br />

major data and process management components have been shown to be necessary<br />

to implement interoperable solutions in practice.<br />

The scoping of realizable and manageable systems remains an open issue. There are<br />

conflicting opinions on the size of integrated systems that can be built with current technology.<br />

Many attempts have suffered from a lack of well-defined scope. Figure 8.8<br />

introduces a scoping approach, which has proven to be a helpful instrument in determining<br />

the size of integration efforts in general. The figure explains the difference<br />

between unscoped approaches that emphasize the generic <strong>Building</strong> Model, versus wellscoped<br />

definition of smaller <strong>Building</strong> Models in a number of separated and fairly small<br />

process windows. Each process window or “Project Window” (PW) is defined by the<br />

actors and life cycle stage that it covers. Useful PW can be identified by detecting clusters<br />

of tightly knit software applications in a particular phase of a project, involving a<br />

relatively small set of actors. Once a set of PWs have been identified, integrated systems<br />

can be targeted at them. The exchange of data across the borders of a PW is left to userdriven<br />

(traditional) procedures, involving data filtering, translation, and population of<br />

the PW-specific <strong>Building</strong> Model. These interfaces typically do not fall in the category of

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!