AEC From the Ground Up-AEC Translation and File Transfers

aecXML and Industry Foundation Classes take the stage.

AS THE AEC AND BUILDING operations industries move into the age of virtual building information models, professionals need formats that allow different software programs to share model information. Uniform external standards are the best way for this to occur.

An IFC Primer

What exactly are IFCs? They are data models developed by the IAI (International Alliance for Interoperability, www.iai-na.org) to facilitate interoperability between 3D AEC objects in the building industry. The IAI is a division of the ISO (International Standards Organization), the body that controls the IGES and STEP data standards.

The IFC system is a data representation standard and file format for defining architectural and construction CAD graphic data as 3D real-world objects, primarily to enable architectural CAD users to transfer design data between different software products. It uses the 3D object-based CAD concept that AEC software developers are calling BIM (building information modeling) or virtual modeling.

Imagine a 3D wall object made of two layers of gypsum board on either side of a wood stud. In the IFC format, all information about components, including areas, is stored in a data text file. Any software program that adheres to the IFC format can read and interpret this information, so it can be used in other programs, such as estimating and project management software. Don't confuse IFCs with programming that allows an application to transfer data within and between other products from the same vendor. IFC transfer is specifically meant for interoperability between different products.

Autodesk's Architectural Desktop and Revit, Bentley's MicroStation Architecture and Nemetschek's Allplan can all transfer data through the IFC system, and Vectorworks Architect is investigating future involvement. Several producers of more specialized software for the building and construction industry are also working with the IFC system.

The IAI's IFC system comprises a set of definitions of all the objects to be encountered in the building industry and a text-based structure for storing those definitions in a data file. A plain text file is used because it's the only truly universal computer data format. Each CAD developer can store its data in whatever compact binary file format is best suited to its system. In addition, the IAI provides Save As IFC and Read IFC options, which map the IFC object definitions to the CAD system's representations of those objects. Because this process involves no compromise, data transfer is possible between any two products that have IFC save and read facilities. Although the IFC system is essentially meant for a graphic representation or object modeling systems, there have been moves to extend its scope to support data associated with estimating and project management as well as other nongraphic data.

aecXML ABCs

On August 12, 1999, Bentley proposed another standard called aecXML. In the announcement, Bentley said it was offering the initial specification for industry review and comment. It established an independent working group to help make aecXML an industry standard with broad, vendor-neutral support in service to all segments of the AEC and building operations community. Initially it was not clear whether this was a rival to the IAI's IFC. In fact, the aecXML system is designed for all the nongraphic data involved in the construction industries and has a place alongside the IFC system, although some of the more recent moves to extend IFCs to nongraphic data seem to overlap. Indeed, the IAI has now taken over management of the aecXML standard.

Bentley developer Bhupinder Singh, who coordinated Bentley's ongoing participation in the aecXML Working Group, explained that "aecXML is for talking about things, not modeling them. We can use it to agree what door means, but aecXML won't describe doors or model them." His statement delineates the basic divide and the relationship between aecXML and the IFC system.

The primary purpose of aecXML is to establish standard ways to structure building data to enable automated processing of that data. Much of the data within the scope of the aecXML system is currently stored as arbitrarily formatted text done in word processors, spreadsheets and databases. The aecXML system provides a set of keywords and named data attributes so that all users can employ the same naming logic and groupings. Software can then use the data without it needing to be interpreted by humans or manually re-entered into each program's required form, as is currently often the case with costing systems, for example.

XML stands for extensible markup language, a term for a type of structured text data. aecXML is intended to be used as an XML namespace and to facilitate exchange of AEC data on the Internet. It's not a file format for transferring an entire CAD file, for example, nor is it designed for use as a database or design file format. aecXML is like an organized briefcase—storing packets of information required for a business transaction that are transferred or published via the Internet. The information carried by aecXML can originate from CAD files, but like a briefcase, it holds only small amounts of data to transport from one location to another.

Overlap Leads to Confusion

IFCs describe the building model, its components and the relationships between them in a single model shared by diverse applications, whereas aecXML shares limited common building components and commercial information between disparate software packages used by AEC and building operations professionals for specific commercial transactions.

Given that IFCs contain extensive attribute information about AEC components, the question becomes, "Why not just convert all the IFC objects into XML?"

First, IFCs are not designed to be small bits of information transferred via the Internet. Though IFC model servers can transmit specific parts of the model to user applications, the goal is to maintain the integrity and relationships in the entire model.

Second, an assembled IFC model defines a rich, descriptive model rather than the relatively thin layer needed for aecXML communication of common AEC and operations components between applications.

Third, aecXML supports specific business processes, some of which are outside the scope of the IFC model.

Fourth, aecXML extensively uses existing and emerging XML standards for business-to-business transactions. Using the standard XML format assures compatibility with other relevant XML initiatives that standardize general business processes.

With such diverging requirements, the challenge is to provide interoperability to project participants through coordination and harmonization of IFC and aecXML capabilities. aecXML is mining the existing IFC definitions for subsets of information that can be used as the basis of the aecXML schema. This overlap is where the aecXML domain and the IFC domains can work together in identifying these common characteristics.

aecXML and ASHRAE

During last February's meeting of the ASHRAE (American Society of Heating, Refrigerating and Air Conditioning Engineers), Technical Committee 1.5 (Computer Applications) voted to promote the formation of a guidelines project committee called XML Definitions for HVAC&R. This committee will bring together users, producers and consumers within the industry and establish an XML vocabulary to submit to the IAI for aecXML. The title, purpose and scope document outlining the proposed committee is awaiting approval from the ASHRAE standards body. Next February, ASHRAE will meet in Atlanta. For more information, check the aecXML Web site (www.iai-na.org).

AecXML may have a profound impact on the way HVACR engineers conduct business. It could become as significant to the industry in the next decade as CAD was in the early 1980s.

In the short term, the AEC and operations industries will see the Internet used to enhance real-time project planning, cost estimating and design. In the future, entire design communities may revolve around extranets—hubs for engineering projects—collaborating and sharing data on projects with selected vendors and contractors, bidding on work with user names and passwords provided by the prime or building owners. No matter what the technology, the common goal is speed and greater productivity.

GSA and IFCs

In December of 2003, the General Services Administration/Public Building Service (www.gsa.gov) issued internal guidelines to its regional staff stressing the need for on time, under-budget project deliveries in the capital construction program. It determined that new and emerging technologies such as 3D/4D and BIM have the potential to dramatically improve the outcome of projects and enhance customer satisfaction. The GSA has indicated that, beginning in July, the delivery of IFC-based BIM will be required for the preliminary design phase of all new fiscal year 2006 projects.

Bottom Line

The distinction between IFCs and aecXML is really quite simple. IFCs are best used for information transfer between different AEC programs and are not optimized for Internet transfer. AecXML is also used for information transfer between AEC and operations programs, but it's optimized for the Internet. With the GSA mandate, the IFCs have received a federal mandate, though many industry insiders prefer aecXML. The shakeout is still to come!

H. Edward Goldberg, AIA, NCARB, is a practicing licensed architect, AEC industry analyst and author of Autodesk Architectural Desktop 2005: A Comprehensive Tutorial (Prentice Hall; www.prenhall.com). Look for the 2006 version this fall. Ed also conducts online Architectural Desktop coaching sessions delivered directly to the desktop. Visit www.hegra.org for more information, or e-mail ed.goldberg@cadalyst.com.