AECBytes Architecture Engineering Construction Newsletters
 Analysis Research and Reviews of Architecture Engineering Construction Technology
AECbytes Feature (August 14, 2008)

Interoperability and Sustainable Design

Sid Thoo
Architect


Interoperability and sustainable design are certainly popular topics within the AEC industry at the moment. Interestingly enough, these two subjects are often discussed independently, with seemingly little in common with each other. However, the value and significance of the interoperability paradigm is perhaps most effectively demonstrated when it comes to design strategies relating to sustainability and energy efficiency.

In the recent wake of Autodesk’s acquisition of Ecotect (a program that I have written about previously in AECbytes) and Green Building Studio, and events such as the cooperative agreement announced between Autodesk and Bentley Systems, this article takes a timely look at how interoperability relates to green building design, and how innovation in the way we communicate as building design professionals will help us all design more sustainable buildings.

Simulation and the Performative Design Concept

Traditionally, many architects and engineers have relied upon rules of thumb, general principles and simplified calculations in order to design environmentally friendly buildings. However, modern buildings can be incredibly complex, and it is only through measured, quantitative analysis that we can determine whether or not these strategies will be effective at improving the environmental performance of a proposed building.

Consequently, it is critical that the use of building simulation tools forms a major part of the architectural design process, if a quantifiable “green” outcome is paramount to the success of a project. Dr. Andrew Marsh of Square One Research (developer of Ecotect) has coined the phrase performative design to describe this process, whereby analysis, evaluation and refinement of the proposed building’s performance is an integral part of the design process. This concept can actually be applied to any aspect of a building’s performance, and is best illustrated as a feedback loop diagram, shown in Figure 1.

Figure 1. The performative design feedback loop.

Note how the Simulate stage acts as the performance indicator in the feedback loop; it is only through simulation that the performance of a building or design strategy can be assessed. Thus, only when a positive or effective outcome is achieved does the architectural design process move forward to the next stage.

The Difficulty with Building Simulation

However, there are two inter-related obstacles we face when attempting to simulate the performance of a building. Firstly, how and when should building simulation be integrated into the design process? This is an important question, because often when building simulation and analysis does occur as part of the architectural process, it is after many of the project’s design and planning decisions have already been resolved; sometimes even after planning or development approvals have been issued. Consequently, if major flaws or misgivings exist in the design, it is difficult, if not impossible, to make the kind of revisions that would be necessary to significantly improve the environmental performance of the building (see Figure 2).

Figure 2. The cost of implementing performance improvements contrasted with the effect on building performance for the different stages of a building project.

Thus, it is essential that building simulation be incorporated into the design process right from the very beginning, and rather than think of it as a finite stage, it should be an iterative process not dissimilar to the act of design itself. Therefore, we consider an idea or strategy, incorporate it into the design, and then simulate its performance. Depending on the outcome, this process repeats as necessary, and through which the performance of the building is continually refined and improved.

This brings us to the second part of the building simulation hurdle—if building simulation and analysis needs to occur from the beginning of schematic design, and that it should be a recurring process, do we have the tools and workflows that make this possible? While there are numerous software applications available for building simulation, not all of them are necessarily intuitive or accessible to the building design professional, especially with respect to the iterative performative design methodology we hope to achieve.

A Brief Overview of Some Building Simulation Tools

Take, for example EnergyPlus, a building simulation application developed by the US Department of Energy. While it is regarded as being among the most accurate and comprehensive thermal and energy simulation tools available, its biggest limitation has long been that in order to perform a simulation, the proposed building must be inputted into the application as a text-based, IDF file—a laborious process, and counter-intuitive to the way in which architects design buildings (see Figure 3). And even though a SketchUp plugin has now been released that can be used to model the IDF file in 3D, it is currently a beta version, and care needs to be taken when modelling to ensure the integrity of the simulation results.


Figure 3. The text-based interface of EnergyPlus. The background window shows part of the IDF file used to describe the building.

Consequently, a number of third party developers have attempted to create more intuitive interfaces for such text-based simulation engines. One such application is DesignBuilder, a comprehensive 3D modelling front-end to EnergyPlus. It has a number of easy-to-use modelling tools (see Figure 4), an innovative way of organising the 3D model hierarchy, and also provides an OpenGL visualisation option that allows the operator to view the model with realistic materials and accurate shadow-casting.


Figure 4.The interface of DesignBuilder, which is a 3D front-end to the EnergyPlus simulation engine.

However, despite its intuitiveness and innovations, DesignBuilder is limited in its ability to import CAD/BIM files created in other applications—currently it is only possible to import 2D DWG/DXF files. Consequently, a proposed building would need to be modelled virtually from scratch within the DesignBuilder application; for practices that have adopted a BIM workflow, this would mean that time that could otherwise have been invested in the building information model would have to be allocated to creating a standalone, building simulation model. Another counter-productive consequence would be that changes in the building simulation model would then have to be recreated in the building information model, again resulting in a duplication of information and resources.

Here is where the value of interoperability becomes glaringly obvious. What we really need is the ability to create a single building model that can be used not only for architectural and engineering workflows, but also for the purposes of building simulation and analysis. It is at this nexus that we begin to approach the full potential of the building information model concept.

While the concept may seem obvious enough, currently it is not as easy to implement as it needs to be. Part of the problem lies in what defines useful building information for the purposes of simulation. This is best illustrated with how spaces are defined in an architectural model as opposed to a building simulation model (see Figure 5). Where most BIM programs consist of detailed 3D models that can be used for shading and solar radiation analysis, almost all analysis and simulation programs require relatively simple geometric representations of spaces in order to perform accurate thermal analysis and resource consumption calculations. This brings us back to the issue described previously with DesignBuilder, where inordinate amounts of time can be wasted “cleaning up” or recreating the model in the analysis application.

Figure 5. Geometry-based model, shown on the left, compared to a space-based model, shown on the right.

Applications such as Ecotect attempt to address this issue in one of two ways. Ecotect has always had its own 3D modelling interface for creating simulation models from scratch, but with the latest version 5.6 release candidate, it is now also capable of exchanging building information with other applications via gbXML and IFC (see Figure 6). This level of information exchange invites exciting possibilities for interoperability.

Figure 6. The Ecotect v5.6 gbXML/IFC import dialog box.

gbXML is a open standard that has been adopted by the AEC industry for dealing with energy analysis data. Originally developed by Green Building Studio, it is based upon Extensible Markup Language (XML), a web-based, standards-compliant specification that can be used to store and transport virtually any kind of data. It is based on a relatively simple text-based syntax not dissimilar to HTML, and in this instance is used to describe the properties of a building for the purposes of environmental analysis.

Most major BIM applications can export model data to a gbXML file—to do this, for example, Revit requires the use of Room Tags in the BIM model, while ArchiCAD uses its Zone Tool. The gbXML file generated can then be used by a compatible application to extract the data required for analysis. For example, Green Building Studio offers a web-based service whereby the gbXML file can be uploaded and analysed using a variety of simulation tools, while programs like Ecotect use the same data to create an interactive 3D model. The latter has the added bonus of allowing the user to visually check the model, to ensure that the geometry is consistent with the original BIM model.

Thus, the use of gbXML for exchanging data eliminates the need to manually create a text input file or analysis model for use with the selected simulation tool. The added beauty of using XML to do this is that the data can be used in a variety of ways, and is “readable” using nothing more than a standard text editor, as shown in Figure 7.


Figure 7. An excerpt from a gbXML file, viewed using a text editor application.

One drawback with gbXML is that it is intended specifically for storing data relating to energy analysis, and so is not a comprehensive, “all-of building” schema like IFC (which we will discuss next). Also, gbXML data that is edited or changed outside of the BIM application that created it cannot be re-imported as revisions to the original BIM model. Even though this technically means that gbXML is not truly an interoperable method of information exchange, it is still nonetheless a useful data format for building simulation.

Much has already been written about Industry Foundation Classes and the IFC schema (for example, see the AECbytes feature “The IFC Building Model: A Look Under the Hood”). From the perspective of building analysis and performative design, the use of IFCs as a standard for disseminating analysis data presents both exciting possibilities and potential hurdles. Like gbXML, because IFC is a non-proprietary, open standard, it has received a lot of support from the AEC industry and BIM vendors. However, unlike gbXML, it has the added advantage of allowing full interoperability—that is, changes can be made to the IFC model by any IFC-compliant BIM application,  and those changes will be accessible by all users of the IFC model.


Figure 8. An IFC version of the same project shown in Figure 7, viewed using the IFCTool utility.

This offers a lot of potential for promoting a performative design methodology. For example, the following illustration is a project designed by SOM, originally modelled in Digital Project. Using IFCs in conjunction with customised scripting, this model was exported as a series of 3D coordinates, representing the external shell of the building. Using Ecotect, the glazed portions of the façade were analysed for solar radiation exposure, to determine the optimal shape so as to minimise direct solar gains. The updated 3D coordinates describing the new façade geometry were then imported back into Digital Project, and used to update the more detailed BIM model in its entirety. Thus, a fully interoperable workflow was achieved indirectly using IFC, whereby an external application to the original BIM program was used to make meaningful changes to the BIM model.


Figure 9. This Ecotect model of a building designed by SOM was used to analyze the geometry of the glazing façade to determine if it could be shaped so as to provide shading to itself. The darker patches of color represent lower levels of solar radiation.

Of course, this example relied more on the capabilities of the Digital Project parametric modelling engine rather than IFC to achieve an interoperable workflow. However, there is no reason why a similar workflow could not be achieved using IFC alone. The IFC schema provides for many of the material and thermal properties, along with space definitions, that are required for building analysis. Additionally, the STEP technology upon which IFC is based allows for the building to be described as a series of relationships, which could in turn be used to manipulate the building geometry in a similar manner to that described above.

Unfortunately, the implementation of IFC for exchanging building analysis data between applications is not quite there yet. For example, the release candidate for Ecotect v5.6 can import an IFC file in its entirety (see Figure 10), but cannot yet extract just the space definitions as required to create a zonal model for thermal analysis. And while the IFC schema provides for a space boundary definition, it does not yet allow for doors, windows and other openings to be mapped in relation to the space boundary.


Figure 10 .While Ecotect can import IFC files, the resultant model is not quite suitable for building simulation and analysis.

Also, because of the multi-disciplinary nature of IFCs, they are potentially used in different ways by different people. Consequently, an IFC model may not always contain all of the building information required by an analysis program. For example, while most BIM applications will include descriptions of materials as part of their IFC output, these descriptions do not necessarily contain analysis information, such as U-Value, thermal lag, density and specific heat. It’s a minor issue that can be easily resolved, but one that certainly needs to be addressed.

Alternatively, ifcXML may provide the answer to this issue. Used in parallel with the full IFC schema, ifcXML is intended for dealing with partial building information, such as the specialised needs of thermal and energy efficiency analysis. The gbXML schema (see Figure 11) may even become the framework for this, being both comprehensive and well established in the AEC industry.


Figure 11. A snapshot of the gbXML schema reference file.

The Future of Interoperability and Building Analysis

With Autodesk’s recent acquisitions of Ecotect and Green Building Studio, it will be very interesting to see how interoperability and sustainability will develop over the next few years. Awareness of environmental and energy efficiency issues relating to building design and construction is ever increasing; Autodesk has no doubt added these two valuable assets to their technology portfolio for this reason. Conversely, these comparatively small companies now have access to significantly more development resources than they have had previously; what they do with them remains to be seen.

As we also work towards a more interoperable future within the AEC industry, it will also be interesting to see what will become the preferred standard for information exchange with respect to performative design and building analysis. In its current form, gbXML currently addresses this niche very effectively; however it lacks the mechanism for the interoperable exchange of information between the BIM and analysis models, and also doesn’t meet the needs of other types of analysis, such as acoustics. On the other hand, IFC allows for the interoperability, but is largely dependent on vendor implementation of the schema to ensure the required data is embedded into the IFC model. Square One Research has even proposed the idea of a new ecoXML standard; however, it seems unlikely that the development of yet another information exchange standard will garner the support required to make it successful.

Looking at the bigger picture, the slim possibility exists that the interoperability discussion with become moot. With Bentley and Autodesk having publicly announced their intention to work together more closely, one scenario that may occur is that a de-facto, proprietary standard emerges as the interoperability winner (similar to how the DWG and DGN file formats are supported by virtually all CAD/BIM applications). With respect to Ecotect and the Green Building Studio analysis tools, eventually these could be subsumed by one of Autodesk’s flagship products, such as Revit. If this were to occur, the need to develop a standard for exchanging building analysis information will possibly become redundant.

However, both Ecotect and Green Building Studio do have an established history of working in conjunction with other BIM vendors; for example, Ecotect was closely aligned with ArchiCAD prior to the Autodesk acquisition, while Green Building Studio had developed gbXML plugins to work with a number of BIM applications. Hopefully, if only as a goodwill gesture, Autodesk will continue with this “plays nicely with others” attitude.

In conclusion, the desired outcome comes back to the basis of the performative design methodology, whereby iterative improvement of the building’s performance becomes a major driving force during the design process. This will occur when:

  • The BIM model can be manipulated to extract the appropriate data and geometry required for analysis.
  • The analysis and simulation tools are intuitive and provide meaningful feedback.
  • This feedback can then be used to seamlessly generate change in the original BIM model.

Performative design will then become an integral part of the architectural process, and better buildings will be virtually guaranteed.

About the Author

Sid Thoo is an Australian architect with an interest in energy efficient building design, BIM technology and information management in architectural practice. The architectural practice and his baby daughter Daniella keep him very busy. He can be reached at sid@archit.com.au.

 

 


Have comments or feedback on this article? Visit its AECbytes blog posting to share them with other readers or see what others have to say.

Features > Interoperability and Sustainable Design > Printer-friendly format

 
© 2003-2009 Lachmi Khemlani, AECbytes. All rights reserved.
Site design by Vitalect, Inc