buildingSMART allianceOpen Geospatial Consortium, Inc.
Date: 2010-06-04
OGC document: OGC 10-003r1
bSa document: TBD
Version: 0.3.0
Category: Engineering Report
Editors: Louis Hecht, Jr., Raj Singh

Summary of theArchitecture, Engineering, Construction, Owner Operator
Phase 1 (AECOO-1) Joint TestbedbuildingSMART alliance (bSa)andThe Open Geospatial Consortium, Inc. (OGC)

Copyright © 2010 buildingSmart alliance and The Open Geospatial Consortium, Inc.
To obtain additional rights of use, visit http://www.opengeospatial.org/legal

Warning
This document is not an OGC Standard. This document is an OGC Public Engineering
Report created as a deliverable in an OGC Interoperability Initiative and is not an official
position of the OGC membership. It is distributed for review and comment. It is subject tochange without notice and may not be referred to as an OGC Standard. Further, any OGC
Engineering Report should not be referenced as required or mandatory technology inprocurements.

License Agreement
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below,
to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property
without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish,
distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to
do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual
Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above
copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTSTHAT MAY BE IN FORCE ANYWHERE IN THE WORLD.
THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULARPURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDEDIN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILLMEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE
UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT
THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OFINTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY
DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTINGFROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH
THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all
copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except asprovided in the following sentence, no such termination of this license shall require the termination of any third party end-user
sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual
Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent,
copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license
without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy orcause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual
Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without
prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may
authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any
LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United
Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of thisAgreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable,
and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be
construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported inviolation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction
which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any
regulations or registration procedures required by applicable law to make this license enforceableii

Copyright © 2012 Open Geospatial ConsortiumPreface
The Architecture, Engineering, Construction, Owner Operator, Phase 1 (AECOO-1) Testbed
developed and implemented methods to streamline communications between parties in theconceptual design phase to get an early understanding of the tradeoffs between construction costand energy efficiency. To that end, the project developed the interoperability components
required for these analyses in collaborative team settings. These were Information Delivery
Manuals (IDMs) for quantity takeoffs and energy analysis business processes, and used these todefine Model View Definitions (MVDs)—standards-based subsets of Industry Foundation
Classes (IFCs). AECOO-1 was conducted in response the felt need that overall productivity loss
and fragmentation in the capital facilities development industries is no longer tolerable. All
stakeholders need to practice the best way they know, and practice profitably; softwareinteroperability problems must not hold them back. Non-interoperable software and data is cause
for loss of competition across the market.
The AECOO-1 Testbed was jointly led by the buildingSMART alliance (bSa) and The Open
Geospatial Consortium, Inc. (OGC®). The Testbed was conducted using the OGC
Interoperability Program Policy and Procedures for a Testbed initiative. All results of thisTestbed have been submitted to bSa for consideration as candidate specifications and bestpractices under the National Building Information Model Standard (NBIMS) Rules ofGovernance.
Should bSa and other AEC-related standards bodies adopt the results of AECOO-1 as approved
standards via their respective consensus processes, then software providers will be positioned toprovide products and services that employ these specifications to their users to streamline
communications and information exchanges and lower risks and costs between project
participants during the conceptual design phase of capital projects.
The Sponsors of the AECOO-1 Testbed were:
Architecture Firms: HOK, Burt Hill and Ellerbe Becket
General Contractors: Webcor and Gilbane
Government Agencies: US General Services Administration and Statsbygg (Norway)
Trade Associations: American Institute of Architects and Large Firm Roundtable
The main outcomes of AECOO-1 were:

Application of the interoperability Testbed process to the AECOO community was
accomplished through coordination of ten sponsoring organizations. The Sponsors and four
affiliated standards organizations developed and issued a Request for Quotation/Call for
Participation (RFQ/CFP) released in May of 2008.



Twenty-seven organizations participated in some aspect of AECOO-1, including
Sponsors and affiliated standards organizations.



Two Information Delivery Manuals for Energy Analysis and Quantity Takeoff weredeveloped, based on the AIA Integrated Project Delivery Process.
Two Model View Definitions for Energy Analysis and Quantity Takeoff were developed,
based on the AIA Integrated Project Delivery Process

iOGC Document: OGC 10-003r1
bSa Document:



AECOO-1 Summary

Two demonstrations that iterate through a series of changes to a ―test building‖ highlighting
energy cost reduction (building performance) and building materials‘ quantity and cost. The
demonstrations used a number of different software products that interchanged IFC
information using existing commercial off-the-shelf software.

The use of the methods and processes developed in AECOO-1 facilitate earlier understanding of
the tradeoffs between construction quantities take off, cost, and energy efficiency. The process
for design change, energy evaluation, and change approval were shown to reduce timeframes
from weeks to hours.
Chapters 1 through 5 detail the background for and work completed over the life of the Testbed.
In Chapter 6 of the Report, we present an analysis of the work accomplished and discuss lessons
learned. In addition we put forward six recommendations for future progress. Supporting theserecommendations are two Annexes. Annex A delves more distinctly into the means for closing
communication gaps along the AEC lifecycle.
In late 2009 the American Institute of Architects, one of the sponsors of AECOO-1 issued aposition request on interoperability related to project delivery. The request suggests
interoperability in the AEC market is best accomplished using professional, public and privatesector adoption of open standards. The results of the AECOO-1 Testbed are to be seen as apartial contribution in meeting AIA‘s position statement. The full position statement is made partof this Summary Report and can be found in Annex B.
For more information, contact Louis Hecht (lhecht@opengeospatial.org) or Raj Singh(rsingh@opengeospatial.org) of the OGC and/or David Morris(david_morris@emcorgroup.com) of the buildingSMART alliance.

ii

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

TABLE OF CONTENTS
SUMMARY OF ARCHITECTURE, ENGINEERING, CONSTRUCTION, OWNER, OPERATORTESTBED 1 (AECOO-1) ......................................................................................................................................... 1
1

OVERVIEW ...................................................................................................................................................... 1
1.1
ORGANIZATIONS IN AECOO-1 ............................................................................................................................. 2
1.1.1 Sponsoring Organizations ..................................................................................................................................2
1.1.2 AECOO-1 Interoperability Program (IP) Team .........................................................................................3
1.1.3 Complete List of Organizations ........................................................................................................................3
1.2
SCHEDULE ................................................................................................................................................................. 4
1.3
TESTBED ACCOMPLISHMENTS .............................................................................................................................. 5

2

INTEROPERABILITY IN THE AEC MARKET.......................................................................................... 7
2.1
INTEROPERABILITY STANDARDS IN THE BIM MARKETPLACE........................................................................ 93

AN ARCHITECTURE FOR INTEROPERABLE PROJECT DELIVERY .............................................. 10
3.1
ELEMENTS OF BIM STANDARDS FOR INTEROPERABILITY............................................................................. 10
3.2
INTEROPERABILITY STANDARDS FOR BUSINESS PRACTICES AND DESIGN MATURITY ............................. 11

4

AECOO-1 THREADS AND WORK AREAS............................................................................................. 13
4.1
IDM FOR BUILDING PERFORMANCE AND ENERGY ANALYSIS (BPEA)....................................................... 14
4.1.1 Cyclical Design....................................................................................................................................................... 14
4.1.2 IDM BPEA Information Exchanges .............................................................................................................. 16
4.1.3 2nd Level Space Boundaries ............................................................................................................................. 18
4.1.4 MVD For Building Performance and Energy Analysis (BPEA)........................................................ 20
4.2
IDM FOR QUANTITY TAKEOFF FOR COST ESTIMATION (QTO) ................................................................... 20
4.2.1 Cyclical Design....................................................................................................................................................... 21
4.3
MVD FOR QUANTITY TAKEOFF FOR COST ESTIMATION ................................................................................ 22
4.4
COMMUNICATIONS PROJECT DELIVERY AND DECISION SUPPORT (CPD)................................................... 225

DEMONSTRATIONS AND WEBCAST .................................................................................................... 23

6

LESSONS LEARNED & RECOMMENDATIONS .................................................................................... 25
6.1
THE DIMENSIONS OF BIM – PRODUCT, FILE AND CONCEPTUAL .................................................................. 25
6.2
INFORMATION INTEROPERABILITY AND DATA EXCHANGE ACROSS BIM ................................................... 27
6.3
THE BIM CONCEPT NEEDS A MESSAGE-BASED, WEB SERVICES APPROACH ............................................. 28
6.4
IFC SHOULD BE XML ........................................................................................................................................... 29
6.5
FUTURE TESTBEDS................................................................................................................................................ 30

ANNEX A: A THEORY FOR BRIDGING COMMUNICATION GAPS AMONG AEC STAKEHOLDERS 33
ANNEX B: AIA STATEMENT ON INTEROPERABILITY (PROPOSED)................................................... 37

TABLE OF FIGURES

Figure 1 – AECOO-1 Testbed Process ........................................................................................... 5
Figure 2 – Interoperable information exchange relies on standardized business processes being
codified in IDMs and MVDs .................................................................................................. 11iii

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

Figure 3 – MVDs relationship to information exchange between heterogeneous software and/or
firms ....................................................................................................................................... 13
Figure 4 - Concept Design Phase Energy Analysis ...................................................................... 16
Figure 5 – Concept Design Phase Quantity Take-Off .................................................................. 22
Figure 6 – AECOO-1 Demonstration flow of events ................................................................... 24
Figure 7 – IFC Data Exchange in Demonstration ......................................................................... 25
Figure 8 – The Corporate Example for Authoring, Analysis and Information Exchange Acrossthe Building Life Cycle .......................................................................................................... 31

iv

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

ForwardAttention is drawn to the possibility that some of the elements of this document may be thesubject of patent rights. The Open Geospatial Consortium Inc. shall not be held responsible for
identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any
relevant patent claims or other intellectual property rights of which they may be aware thatmight be infringed by any implementation of the standard set forth in this document, and toprovide supporting documentation.

v

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

Summary of Architecture, Engineering, Construction, Owner,
Operator Testbed 1 (AECOO-1)
The buildingSMART alliance (bSa)1 (a Council of the National Institute of Building Sciences)and the Open Geospatial Consortium (OGC)2 conducted a Testbed, based on OGC‘s
Interoperability Program (IP) to develop candidate specifications and best practices to meetsponsor requirements. The AECOO-1 Testbed looked at streamlining communications andinformation exchanges between project participants during the criteria design phase to get anunderstanding of the tradeoffs between construction quantity take off, cost and energy efficiency.
The OGC Interoperability Program is a global, hands-on and collaborative prototyping programfor rapid development of proven candidate specifications. In this Testbed, international
technology developers and providers and sponsors teamed together to solve specific AECOO
interoperability problems posed by the initiative‘s sponsoring organizations. Testbeds and other
Interoperability Program modes of interaction between users and developers are designed toencourage rapid development, testing, validation and adoption of open, consensus-based
standards.
Engagement of multiple standards organizations and professional associations in a common
Testbed activity also helps to address increasingly challenging standards issues that could not be
solved by one organization alone.

1 Overview
The AECOO-1 Testbed began in July 2008 and was formally completed on May 26, 2009. Prior
to Testbed execution was a concept development effort as well as a published Request forTechnology (RFT) that provided interested parties an opportunity to comment on proposed
Testbed requirements prior to releasing the AECOO-1 Testbed‘s Request for Quotation/Call for
Participation.
There were 2 primary focus areas for AECOO-1 Testbed activity.
First, was to provide a demonstrable and operational set of processes and procedures for bSa takeup - to advance their mission to develop an implementable National Building Information
Standard (NBIMS). In this Testbed, bSa and OGC were not only focusing on specific operational
issues for how to do standards, but also to demonstrate and transfer operational processes and1

This council provides industry-wide, public and private leadership and support for the development,
standardization, and integration of building information modeling technologies to provide for full automation of theentire lifecycle of buildings. The alliance, in association with the American Institute of Architects and theConstruction Specifications Institute, develops and publishes the consensus-based United States National CAD
Standard®. The alliance also sustains the consensus-based National BIM Standard. The alliance coordinates projects
establishing best business practices, enterprise architecture, education transformation, research and development
throughout the industry. The alliance acts as the North American chapter of buildingSMART International a
consortium of 30 countries with like goals. See http://www.buildingsmartalliance.org/
2

The Open Geospatial Consortium, Inc.® (OGC) is a non-profit, international, voluntary consensus standards
organization that is leading the development of standards for geospatial and location based services. See
http://www.opengeospatial.org/

1

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

procedures for bSa to use as the members move forward in advancing requirements identified in
the National Building Information Standard, Part 1, Version 1 issued in late 2007. The specificprocesses and procedures that were designed as part of this Testbed involved developing astandards based approach for Information Delivery Manuals, as well as for the companion
document for Model View Definitions. In implementing these processes, bSa and OGC usedgeneral guidance documented throughout Chapter 5 of the NBIMS (December 7, 2007)3,
combined with procedures and processes for Testbeds within OGC‘s Interoperability Program(see http://www.opengeospatial.org/ogc/policies/ippp).
The second focus area was to apply these processes so that bSa may establish it‘s direction about
using rapid standards development processes to foster faster, better and cheaper informationexchanges and best practices during collaborative work inside the NBIMS program, and that canreadily transferred to project teams using NBIMS-based software. With this in mind we appliedthese processes and procedures to advance interoperability for three areas of business andtechnical interest by the sponsors:

Building Performance and Energy Analysis
Quantity Takeoffs for Cost Estimation
Requests for Information (Communications Project Delivery and Decision Support).

The first two technical areas of interest participants received sponsor funding. The final area ofinterest was only briefly explored with in-kind participation only, and was largely dealt withinside demonstration planning and preparation. Within this context of the work undertaken, theIntegrated Project Delivery Process (as designed by the American Institute of Architects (AIA))
was used as the business cycle platform for information exchange.
1.1

Organizations in AECOO-1

1.1.1 Sponsoring Organizations
The Sponsors of the AECOO-1 Testbed are:Architecture Firms: HOK, Burt Hill and Ellerbe Becket
General Contractors: Webcor and Gilbane
Government Agencies: US General Services Administration and Statsbygg (Norway)
Trade Associations: American Institute of Architects and Large Firm Roundtable

Testbed Alliance Partners4 for AECOO-1 are:

BuildingSmart International

3

The National Building Information Model Standard, Part 1, Version is available at:
http://www.wbdg.org/bim/nbims.php. The vision for NBIMS is ―an improved planning, design, construction,
operation, and maintenance process using a standardized machine-readable information model for each facility, newor old, which contains all appropriate information created or gathered about that facility in a format useable by all
throughout its lifecycle.‖ The organization, philosophies, policies, plans, and working methods that comprise the
NBIMS Initiative and the products of the Committee will be the National BIM Standard (NBIM Standard), which
includes classifications, guides, recommended practices, and specifications.
4

Alliance Partners are organizations that contribute resources and relevant documents towards advancement of
Testbed goals and have reciprocal standards roles across the community.

2

OGC Document: OGC 10-003r1
bSa Document:






AECOO-1 Summary

US National Institute of Standards (NIST)
Associated General Contractors of America
International Code Council
Construction Specification Institute

1.1.2 AECOO-1 Interoperability Program (IP) TeamThe IP Team is an engineering and management team to oversee and coordinate OGC
Interoperability Initiatives. The IP Team facilitates architectural discussions, synopsizes
technology threads, and supports the specification editorial process. The IP Team for the
AECOO-1 Testbed was comprised of OGC staff and representatives from bSa member
organizations. The AECOO-1 Team was as follows:







Interoperability Program Executive Director: George Percivall, OGC
Initiative Director: Raj Singh, OGC
Thread Architects and Consultantso Energy Performance and Building Analysis: Benjamin Welle, Stanford Center for
Integrated Facility Engineeringo Quantity Takeoff and Costing: Thomas Wiggins, Faithful and Gould, Inc.
o Communications Project Delivery and Decision Support – Raj Singh, OGC
Project Development: Louis Hecht, OGC
Demo Capture: Greg Buehler, OGC

1.1.3 Complete List of Organizations
The following organizations played one or more roles in AECOO-1 as participants, sponsors
and/or observers and were actively involved in contributing to and editing of Testbed
deliverables, as well as the demonstrations.

















AGC (Association of General Contractors of America)
ARBA Studios LC
ASHRAE (The American Society of Heating, Refrigerating and Air-Conditioning Engineers)
Bentley Systems
BuildingSmart International
CSI (Construction Specification Institute)
Digital Alchemy
ICC (International Code Council)
Eppstein Uhen Architects
Faithful & Gould
GranlundGraphisoft
LBNL (Lawrence Berkley National Laboratory)Onuma
OSS Nokalava
OSCRE (Open Standards Consortium for Real Estate)

3

OGC Document: OGC 10-003r1
bSa Document:









AECOO-1 Summary

PhiCubed/Sofi Exec
Nemetschek North America
NewForma
NIST (US National Institute of Standards and Technology
Tokmo Systems
TU Berlin
University of Florida, Department of Building Construction

1.2

Schedule

The AECOO-1 Testbed Execution Phase was preceded by a Concept Development Phase that
included the release of a Request for Technology (RFT). Responses to the RFT from industry
were used by the Sponsors to identify requirements for the RFQ. The overall process of the
Testbed is shown in Figure 1. The dates for the various milestones were:
AECOO-1 Concept Development Phase:

Sponsor Meetings
RFQ development
RFQ response period

October 2007 - March 2008
March 2008 – April 2008
May 2008 – June 2008

AECOO-1 Execution Phase*:









Kickoff Meeting
Interim Information Delivery Manual (IDM) Deliveries
Final Delivery
Interim Model View Definition (MVD) Deliveries
Final MVD Deliveries
AECOO-1 Demonstration
AECOO-1 2nd Demonstration
Web based Demo Release

30 June – 3 July 2008
December 2008
January 2009
March 2009
May 2009
March 2009
May 2009
June 2009*After the Kickoff Meeting, design, development and public review of IDMs, testing of AECOO-1 MVDs were conducted in a
distributed fashion supported by the collaborative development resources of telecoms, a web portal, web collaboration tools, email and weekly telephone conferences.

Each participant had an agreed to Statement Of Work milestones and deliverables. A limited
number of Engineering Reports delivery dates were extended as the inputs needed to complete
some work items were not available in a timely manner or other participant time constraints wereagreed to.

4

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

Figure 1 – AECOO-1 Testbed Process

1.3

Testbed Accomplishments

Ten sponsoring organizations defined Testbed requirements for AECOO-1. The sponsors‘
requirements were first documented in an RFT that was issued in February 2008. OGC
received 20 AECOO industry responses and those responses were used as input to develop
and publish the Request for Quotation/Call for Participation (RFQ/CFP) documents that werereleased by the OGC in May of 2008.

Four affiliated standards organizations provided pre RFQ/CFP advice, technical assistance.
During the execution of the Testbed they were provided an opportunity for their membershipto review interim documents in their various stages of drafting. Many of the four affiliatedstandards organizations regularly attended weekly conference calls for each technical thread.



27 organizations (including Sponsors and affiliated standards organizations) participated insome aspect of AECOO-1. Roles for organizations in AECOO-1 include sponsors,participants and information architects, building architects, cost estimators, application
providers and building energy analysts. Additionally, many organizations were observers, as
provided for under the OGC‘s Interoperability Program‘s Testbed Processes and Procedures.



Major technical achievements and demonstrations of AECOO-1 results include thefollowing:

5

OGC Document: OGC 10-003r1
bSa Document:



AECOO-1 Summary

Energy Analysis Thread: Information Delivery Manual (IDM) for Building Performanceand Energy Analysis (BPEA) 5 was developed and then used for development andimplementation of the companion Model View Definition (MVD)6. The MVD, based on the
IFC standard 2.3 was then implemented in vendor IFC toolboxes within their respective
solutions.
The IDM for Building Performance and Energy Analysis is available at:
http://portal.opengeospatial.org/files/?artifact_id=29385
The MVD for Building Performance and Energy Analysis is available at:
http://portal.opengeospatial.org/files/?artifact_id=34060 (for IFC 2.3) andhttp://portal.opengeospatial.org/files/?artifact_id=34059 (for Generic)http://63.249.21.136/IAI-MVD/reporting/listMVDs.php?SRT=&MVD=BSA002&DV=2 (online)
Concept Development, MVD and Implementation Guide for 2nd Level Space Boundaries
are available at:Space Boundary Concept and Implementation Guideline:
http://portal.opengeospatial.org/files/?artifact_id=35079
Space Boundary MVD: http://portal.opengeospatial.org/files/?artifact_id=29375



Quantity Takeoff Thread: Information Delivery Manual (IDM) for Quantity Takeoff wasdeveloped and then used for development and implementation of the companion Model View
Definition (MVD). The MVD, based on the IFC standard 2.3 was then implemented in
vendor IFC toolboxes within their respective solutions.
The IDM for Quantity Takeoff is available at:
http://portal.opengeospatial.org/files/?artifact_id=32567
The MVD for Quantity Takeoff is available at:
http://portal.opengeospatial.org/files/?artifact_id=34062 (for IFC 2.3) andhttp://portal.opengeospatial.org/files/?artifact_id=34061 (for Generic)http://63.249.21.136/IAI-MVD/reporting/listMVDs.php?SRT=&MVD=BSA001&DV=2 (online)Communications Project Delivery and Decision Support involved development of a series
of user scenarios that enabled users and software providers to demonstrate theaccomplishments brought forward in the BPEA and QTO threads with a test building.

5

Information Delivery Manual defines the business processes and information flows for any topical issue involved
with the design, construction and operation of a building. IDM specifies the process definition including the context
and purpose of the exchange, the originating and consuming actors, and the information created and consumed. An
approved IDM standard can become the basis of a contract between two parties for data interchange, thereby,
treating information as an asset, enabling BIM-based methods, and regulating the information sharing between
project participants.
6

Model View Definitions provide information to software providers so that they may satisfy business process
information flows that are required and defined within one or more IDM‘s. MVD‘s are usually designed to be
stakeholder specific in regard to information to be exchanged. MVDs collectively aggregate information flows
between a sender, a receiver along with a purpose for that particular exchange. MVDs can be generic or specific to adata model such as IFC 2.3.

6

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 SummaryDemonstrations and webcast: Two demonstrations were completed as part of the Testbed.
The demonstration comprised a number of different energy and building performancecomponents of the ―test building‖, the results of energy analysis using EnergyPlus and theeffect those changes had on quantity of building materials and cost. The demonstrations used
a number of different software vendor products that interchanged IFC information using
existing commercial off-the-shelf software to perform the necessary calculations and results.
The first demonstration was held in Washington at the National Building Museum in Marchof 2009. The second demonstration was via a webinar in May of 2009.
An on-line version of the webcast demonstration is available at:
http://www.opengeospatial.org/pub/www/aecoo-1/index.html
Participants in the Demonstration included the following organizations:

BentleyDigital AlchemyFaithful and Gould



Graphisoft

Lawrence Berkeley National LaboratoryNemetschek, NAPhi Cubed/Sofi Exec

Stanford Center for Integrated Facility Engineering



Tokmo

2 Interoperability in the AEC Market
The AEC market is closely tied to global financial and real property markets. Since 2007 the
AEC, real property and financial markets can be described as stressed and in disarray, however
this has not impeded prospects for innovation in these large segments of the real economy. In
fact, it is quite the opposite as we continue to witness a consistent and overarching characteristicof innovation in these fields of business, which is that work is increasingly focused on
information systems that can work together, or “interoperate”7.
Much has been written about the nature of and context for interoperability in the AEC market
and many see the fractionated nature of the market to be too large a hurdle to overcome8. But
7

Interoperability can mean different things to different people and communities. Interoperability generally is aproperty referring to the ability of diverse information systems and organizations to work together (inter-operate).
The term as used in this Report is a technical system engineering term as well as social, political, and organizational
factors that impact system to system performance. A distinction must be drawn between interoperability andinteroperation, with the former referring to creating a common fabric of interaction that everyone can connect toequally, and the latter being defined piecewise between particular systems (often through the creation of specificsoftware adapters). It is our experience that it is far easier to do interoperation first, but it is interoperability thatbuilds a real commodity with maximal benefits to the market.
8Managing Dynamic Life-Cycle-Dependent Building Objects in a Distributed Computing Environment;
Construction Informatics Digital Library http://itc.scix.net/ paper w78-1997-443.
7

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

again, when these doubts are parsed far enough we can begin to derive an interoperability
quotient, or IQ that technologists and practitioners alike can see from their distinct perspectives –that discrete components and systems, when conjoined with the ability to speak with each other,
constructively influences the behavior of other systems and components in that market.
In the AEC market the tiny IQ has for some time increasingly impacted the economic value of
information that can be used across the building lifecycle. The AEC market‘s low IQ indicates
innovations that follow conventional norms are destined to underachieve and will continue
fostering non-value added economic cost, lost productivity and lessened competitiveness.
Information that plays well with other information across different and competing software
applications is quickly becoming the new metric for innovation excellence, market take up andrevenue growth.
Look no further than the Internet for inspiration about interoperable innovation. The
misunderstood genius of the Internet is that interoperability makes ―networks of networks‖
possible. Standards that permit diverse data and applications to mingle creatively explain why
the Internet‘s influence as a multimedia, multifunctional and multidisciplinary environment for
innovation remains unsurpassed. Consider ―mash-ups‖ as a model: Google Maps can easily bemixed and mashed with property, seismic or epidemiological data to produce novel applications
that might launch a company or an industry. Greater interoperability invites greater innovation –and vice versa. It is this characteristic that this Testbed and the combined efforts andcollaboration between bSa and OGC are addressing.
Over the last 10 years the concept of merging CAD, data management, requirements forextending the shelf life of information and repurposing previously collected information helped
to create what we now know to be Building Information Model (BIM) software. A BIM is adigital representation of physical and functional characteristics of a facility. As such it serves as ashared knowledge resource for information about a facility forming a reliable basis for decisions
during its lifecycle from inception onward.
Many organizations over the past 5 years have jumped on the BIM bandwagon, and to those who
did, suddenly realized the extent to which technology, business practice and process are jointly
and materially impacted. The business opportunity space and production possibilities curves
when employing BIM technologies are naturally pushed out, which implies that to receive themaximum benefit of the technology and new applications, the idea of paving over old cow paths
does not suffice. Inherent in this mix of integrated application software and data sharing
capabilities is the opportunity for AEC businesses to not automate old and outmoded processes,
but rather to evaluate and institute processes that increase efficiencies, productivity and add
value. If BIM, through its technological advancement facilitates realizing process improvements,
then reasonable economic and business judgments can be made about adoption.
BIM technological components help organizations to overhaul their business processes because
the overall scope of the technology is broad. Currently BIM can be described as a product or as
an intelligent digital representation of data about a capital facility. BIM authoring tools
encompass CAD and are used to create and aggregate information, which, before BIM, were
offered as separate software with non-machine interpretable information in a paper-centric
process.

8

OGC Document: OGC 10-003r1
bSa Document:

2.1

AECOO-1 Summary

Interoperability Standards in the BIM Marketplace

Users also desire to extend the value proposition of BIM beyond its role as simply a product – tosee it and use it as a mechanism to carry out collaborative processes throughout the lifecycle ofthe facility. This value proposition covers business drivers, automated process capabilities andother network messaging and communications advantages. Currently, the opportunities to use
BIM as a collaborative resource are largely dependent on project team members deciding which
single vendor software to use for that project, and this decision customarily requires additional
investments for transfer technology (along with related financial, training and support costs).
Forcing AEC companies to change software on a project-by-project basis, and to continuously
invest in new software and training negatively impacts the larger gains that BIM can offer andoften means that businesses must continuously change the way in which they operate toaccommodate the way that particular software works on a project-by-project basis.
So now the market is increasingly demanding that open information standards be more broadly
applied to BIM technologies so that each partner in a project can comfortably adapt their internal
processes, so that they can share project information across their chosen software and otherpartner‘s chosen and possibly heterogeneous software platform(s), while preserving information
sustainability and fidelity across the lifecycle and minimizing their and their client‘s risk. This
demand targets software providers to offer capabilities to exchange information seamlessly.
When BIM (and all its associated data categories and attributes) is successfully standardized
across a set of numerous, but commonly defined data and information service levels andshown to work in run time conditions, the full utility of the technology as a collaborative tool
and a facility lifecycle management tool can be realized. It involves gaining agreements about
well-understood information exchanges, workflows, and procedures at not only the human level,
but also the machines human use - where teams use and rely on repeatable, verifiable,transparent, and sustainable information throughout the building lifecycle.
Thus, the basic premise of standards for BIM is to foster collaboration by different stakeholders
at different phases of the lifecycle of a facility to insert, extract, update, or modify information in
their software of choice and to support and reflect the roles of that stakeholder no matter what
provider‘s software is used by any member in a project team. When BIM software from any
provider can be thought of and used as a shared digital representation founded on open standards
we then have achieved a level of interoperability like that suggested on page 7.
The National BIM Standard promotes the idea of the market undertaking and defining business
requirements for standards that can result in interoperable software across the market. Softwareinteroperability is seamless data exchange at the software level among diverse applications, eachof which may have its own internal data structure. Interoperability is achieved by mapping partsof each participating application‘s internal data structure to a standards-based data model andvice versa. If the employed standards-based data model is open, any application provider canparticipate in the mapping process and thus become interoperable with any other application
provider‘s offering that participated in the mapping. Interoperability eliminates the costly
practice of integrating every application (and version) with every other application (and version).
The NBIM Standard maintains that viable software interoperability in the capital facilities
industry requires the acceptance of an open data model and the use of service interfaces
contained within provider‘s software to bring the capabilities of the data model to workflows
within the project delivery work cycle. If the data model is accepted as the lingua franca and9OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

industry-wide means of communication and can be represented in its appropriate parts along theentire facility lifecycle, then every software application used across the lifecycle can become
interoperable.

3 An Architecture for Interoperable Project Delivery
Given the mix of technical and business issues confronting the AEC market and the potential
benefits interoperability through standards offers, the goal of AECOO-1 was to develop a
process for standards development whereby more efficient sharing of building information
between participants in a project team, and between the heterogeneous software products theyuse can be realized.
In the Concept Development stage of AECOO-1 (development of and comments on the RFT),
we found that most of the industry that responded thought information sharing about buildings as
an issue that involved transmitting complete information about a building between two design
software packages. However, once a discussion on this topic was initiated during the kickoff
meetings and later parts of the Testbed execution phase, we found that design-software-todesign-software was the least useful information sharing case to address. In the course of adesign project, there is little need to share all aspects of the design between project participants.
What is more important is to exchange relevant elements of the design between the leadarchitecture firm or lead general contractor and subcontractors with specific expertise in areas
such as lighting, energy usage, building cost, HVAC, circulation, etc.
3.1

Elements of BIM Standards for Interoperability

The design elements needed by these specialists are highly diverse, and so is the software they
use to do their jobs. AECOO-1 found that there are few, if any, standard business practices
addressing fundamental information exchange requirements between the design team and area
specialists. Technology cannot provide solutions until the business practices are firmly in place.
This is why the information sharing challenge has been so difficult to solve, and many in theindustry feel that technology standards efforts have not been as successful as they should.
Therefore, in order to make progress on the technology front, AECOO-1 also had to advance theprocess for developing business information practices associated with sponsor requirements.
The National Building Information Model Standard, Part 1, Version 1 provided us with theconcepts of an Information Delivery Manual (IDM), which articulates what building informationis required to accomplish a particular specialty analysis (e.g. lighting design, energy
performance, materials cost, etc.), and a Model View Definition (MVD), which is the smallest
set of Industry Foundation Classes (IFCs) that are needed to express the information
requirements of a particular IDM. We found that specialists do their work to varying degrees of
specificity depending on how fully developed the building model is at a point in time. In otherwords, the accuracy of the lighting study, energy analysis, or cost estimate changes as the design
evolves.
It is impossible to create software that will work as needed with any building at every stage ofdesign, so our task became one of limiting the degrees of freedom in the design process so thatsoftware designers have a reasonable expectation of how much detail and definition they can
expect to find in a building at a particular stage of design.
10OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

AECOO-1 made two significant contributions in this area. First, we agreed upon a universal
definition of project phases, and what level of detail was captured in building design at eachproject phase9. This was a critical first step to characterize what information could be expected to
be present—and therefore what types of analyses could be performed—at a particular stage ofdesign. Second, we brought into the discussion the groups responsible for standardizing
nomenclature for building materials and other aspects of the design process such as theConstruction Specification Institute‘s OmniClass and Uniformat nomenclatures. Utilizing
standard definitions of building materials, sizes, etc., is a prerequisite for creating standardized
design interchange files in a standard data model for AEC – Industry Foundation Class (IFC)
format. This aspect of standardization will need to occur often within the NBIMS process going
forward. It is a conclusion implied in NBIMS Version 1, Part 1 and now verified by work donein AECOO-1.
With our analysis of information flows from the business perspective of the sponsor‘srequirements complete, we could then apply what was learned to the technology realm. The
essential steps taken are graphically depicted in Figure 2. Following the figure we explore in
more detail the actual activities that were undertaken.

Figure 2 – Interoperable information exchange relies on standardized business processes
being codified in IDMs and MVDs

3.2

Interoperability Standards for Business Practices and Design Maturity

There is currently little standardization of the stages of design maturity during a project lifecycle,
and therefore it is difficult to develop software that can work generically with any building.
Therefore our first task of limiting the degrees of design freedom was to pick a project stage, and9―Organizing the Development of a Building Information Model‖, Jim Bedrick, November, 2008 (unpublished) and
Integrated Project Delivery: A Working Definition, AIA California Council, 2007.

11

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

define fully what design information would be present in the IDM for the building model at any
stage.
We chose to work at the conceptual design stage, as this is the point in time at which significant
changes can still be made to positively impact cost, energy performance, and other key factorsthat inform final design. This choice resulted in the following definition of early, or conceptual
design:

Level of Detail 200: Approximate geometry10
Design & Coordination (function / form / behavior): Generic elements shown in three
dimensions (maximum size, purpose).
Authorized use for 4D Scheduling: Time-scaled, ordered appearance of detailed
assemblies.
Authorized use for Cost Estimating: Estimated cost based on measurement of genericelements (e.g. generic interior wall).
Authorized use for Program Compliance: Specific room requirements.
Authorized use for Environmental (lighting, energy use, air movement
Analysis/Simulation): Conceptual design based on geometry and assumed system
types.

With this definition in place, we could then begin to define the information requirements for the
IDMs that would support our two target business cases, energy performance and materials costestimation. And then it became a simple matter to create the MVDs (see Figure 3 below) thatdefined what IFCs were needed to articulate the IDMs. The software vendors could then write
code to translate their internal, proprietary building information models into interchangeable IFC
models for energy analysis at the conceptual design stage, and materials cost estimation at theearly design stage.
For perspective, creating the definition of conceptual design took about 2 project months, and the
IDMs took 2-3 project months. The MVD creation took less than 2 weeks, and the actual
software development amongst the participating providers took under 2 months.
This underlines strongly the importance of having the industry agree to standardized businesspractices before we can have any hope of standardized information flows between software
packages. This was by far the most important lesson of AECOO-1.

10

From ―Organizing the Development of a Building Information Model‖, Jim Bedrick, November, 2008
(unpublished).

12OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

Figure 3 – MVDs relationship to information exchange
between heterogeneous software and/or firms

4 AECOO-1 Threads and Work Areas
The development of the AECOO-1 Testbed was organized around the following 3 threads:

Building Performance and Energy Analysis (BPEA)
Quantity Takeoff for Cost Estimation (QTO)
Communications Project Delivery and Decision Support (CPD)

A summary of each thread is provided below.

13

OGC Document: OGC 10-003r1
bSa Document:

4.1

AECOO-1 Summary

IDM For Building Performance and Energy Analysis (BPEA)

Energy analysis is concerned with predicting the usage profile and cost of energy consumption
within buildings. Conceptual design phase energy modeling is used to provide the design teamwith first order of magnitude feedback about the impact of various building configurations onannual energy performance. Conceptual phase energy modeling requires the designer to makeassumptions for a wide of range of simulation input if information is not yet available. It takes
into account as input data:










Building geometry including the layout and configuration of spaces,
Building orientation,
Building construction including the thermal properties of all construction elements including
walls, floors, roofs/ceilings, windows, doors, and shading devices,
Building usage including functional use,
Internal loads and schedules for lighting, occupants, and equipment,
Heating, ventilating, and air conditioning (HVAC) system type and operating characteristics,
Space conditioning requirements,
Utility rates, andWeather data.

The output results of energy analysis may include:Assessment of the space and building energy performance for compliance with regulations
and targets,
Overall estimate of the energy use by space and for the building and an overall estimate of
the energy cost,
Time based simulation of the energy use of the building and time based estimate of utility
costs, andLifecycle estimate of the energy use and cost for the building.

For the purposes of this process map, conceptual phase energy analysis is considered to include
the assessment of heating and cooling demand within a building during peak periods.
Various types of analyses are within the scope of this process map, including:






Setting comfort criteria for spaces including minimum and maximum required indoor air
temperatures (summer and winter), minimum fresh air requirements,
Heat loss/gain calculations using well defined analytical methods,
Energy performance rating system and/or energy code requirement compliance,
Analysis of energy consumption in meeting the building energy demands, andOptimization of energy performance related to equipment or system type and related
equipment/system performance characteristics considering lifecycle cost, environmental
impact issues, and comfort aspects.

4.1.1 Cyclical Design
Energy analysis is now a critical path workflow throughout the design stages of a project. Two
key parts of energy analysis were considered in the Testbed:

14

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

4.1.1.1 Conceptual Design
This is the analysis work undertaken during the programming and concept design stage of the
project. It is about providing advice on the potential energy performance of a building and its
systems to other design roles. The aim of this analysis is to have an impact on the overallbuilding design, determine the feasibility of concepts in an energy context and to establish
energy targets. Conceptual analysis may be undertaken in the absence of detailed geometric
information about the building layout, though frequently general spatial layout is included during
this stage. The designer is more concerned with relative performance values between the design
options being considered, rather than absolute performance values. Though assumptions
typically must be made at this stage, maintaining consistent assumptions between the options
being evaluated allows for relative performance to be evaluated.
4.1.1.2 Detailed Design
This is the analysis work undertaken during the schematic and design development stages of the
project and assumes the availability of geometric and building system information for the design.
The overall process is the same at each stage of work, the difference being simply about theextent of the information available and the level of certainty that can be applied to theinformation. These factors impact the analysis methods used, which may range from relatively
simple at the earlier design stages to detailed dynamic simulations at the later design stages.
Within this process map, the conceptual design phase for Building Performance and Energy
Analysis is shown in Figure 4.

15

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

Figure 4 - Concept Design Phase Energy Analysis

4.1.2 IDM BPEA Information Exchanges
For Conceptual Design, the scope of the exchange of information is primarily about spaces withassociated energy information and about proposed energy analysis zones. The purpose of theexchange requirement is to support the coordination of energy analysis requirements withgeneral in building zoning and spacing requirements. Information requirements were defined as―required‖ or ―optional‖. Data parameters and units of measurement were also defined. Also it
was presumed that information exchanges took place between the role of Architect and a
Mechanical Engineer and/or Energy Consultant.
The exchange requirement assumes that a building model is available from which relevantgeometric information required for energy analysis can be derived. It is anticipated that thebuilding model will provide context information about the project including units to be used,
coordinate systems to be adopted and the direction of true north.
The building model will provide specific information about:
16

OGC Document: OGC 10-003r1
bSa Document:






AECOO-1 Summary

The building, its location, composition, overall shape and orientation
The shape and location of adjacent buildings to enable shading effects to be determined
Building stories within the building
Spatial configuration

Information that is provided by this exchange is to enhance the initial set of building model
information including:







Space type and function identification with type data being obtained from a project space
type library (which is in turn derived from an industry space type library). This data will
drive assumptions on internal loads, conditioning requirements, etc.
Building elements construction type data with type data being obtained from a project
construction type library (which is in turn derived from a industry construction type library).
This data will provide information on the thermal characteristics of the building envelope andinternal constructions.
Space boundaries that define the relation between spaces and building elements and thegeometry that describes the space boundary connection.
Energy targets.
HVAC zoning, day lighting, and the use of photovoltaics.

For energy simulation and analysis, the scope is about the exchange of information related toenergy demand, comfort, and annual energy consumption. The purpose of the exchange
requirement is to enable coordination of energy analysis with other design roles based on the
results of energy analysis and the ability to comply with set energy targets. The exchange
requirement assumes that information about the building has been satisfied.
Information that is provided by this exchange requirement to includes:







Ventilation requirements,
Peak thermal loads,
Energy demand,
Annual energy consumption,
Utility rates, andEnergy costs.

17

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

4.1.3 2nd Level Space Boundaries
At the Conceptual Design level of the building process as defined by IPD, the notion of spaceboundaries11 plays a role in energy analysis and quantity takeoff for cost estimation. There aredefined three levels of space boundaries. The IDM developed in the BPEA Thread accounts forthe first level. To provide for a more complete energy analysis and cost estimation, 2nd level
space boundaries need to be calculated and work to define this component for conceptual design
energy analysis was initiated in the Testbed.
4.1.3.1 Ist Level Space Boundaries
1st level space boundaries are the boundaries of a space defined by the surfaces of building
elements bounding this space (physical space boundaries) or by virtual surfaces provided by anadjacent space with no dividing wall. Other characteristics that are part of a 1st level spaceboundary include:

1st level space boundaries do not consider any change of material in the bounding building
elements, or different spaces/zones behind a wall or slab (floor or ceiling).
1st level space boundaries are differentiated in two ways: virtual or physical and internal orexternal.
1st level space boundaries form a closed shell around the space (so long as the space iscompletely enclosed) and include overlapping boundaries representing openings (filled ornot) in the building elements (see implementers agreement below).
Implementers' Agreements -Connection geometry for 1st level space boundaries may contain arcs (i.e. creating
cylindrical surfaces), or polygons (i.e. creating extruded surfaces with orientation
changes).
1st level space boundaries representing building elements (wall, slabs, columns, beams)
do not include inner loops to create voids (e.g. for openings). Instead, there are
separate 1st level space boundaries representing such openings (with or without
contained doors and windows) -- which overlap and are coplanar with the spaceboundaries representing the host wall, slab, column, or beam.

11

Space boundaries are virtual objects used to calculate quantities for various forms of analysis related to spaces orrooms in buildings. Analyses that use space boundaries include: Quantity takeoff for Cost Estimating – In earlystages of design, many objects have not yet been modeled. In this phase of a project, space boundaries (and othermeasurements based on the space object) are used to estimate such things as finish materials (i.e. carpeting, tile,
paint) and casework. Facilities Management Work Package Estimating – During the operations phase of a building‘slife cycle, space boundaries can be used to estimate areas for facilities management work packages such as repainting, carpet cleaning, and cleaning of other building element surfaces. Energy Analysis – that is, estimating theamount of energy that will be used by a building during operation. Space boundaries need to be calculated to capture
more accurate energy flow between a space and other spaces or the outside air.

18

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

4.1.3.2 2nd Level Space Boundaries
2nd level space boundaries still represent building elements that bound the space, but are moregranular in that they are subdivided in any of the following cases:









Contained openings (with or without fillings like doors and windows)
Differences in materials and/or material assemblies (e.g. a wainscote or paneling on thelower portion of a wall).
Differences in spaces or zones on the other side of the building element (or virtual boundary)represented by the space boundary (e.g. two different spaces on the other side of a wall)
Differentiation between physical / virtual boundaries and internal / external boundaries is thesame as for 1st level space boundaries.
2nd level space boundaries represent both sides of a heat transfer surface separated by the
thickness of the building element. They can be used by thermal analysis software, but
require, that the two adjacent surfaces are found and be combined to form a single heattransfer surface. This is required even where the two surfaces are of different length (e.g.
non-rectangular wall connections and curved walls). See also 3rd level space boundaries.
2nd level space boundaries (including the 3rd level subtype described below) form a closed
shell around the space (so long as the space is completely enclosed).
Implementers' Agreements -The connection geometry of 2nd level space boundaries is restricted to planar surfaces
only. This means that curved surfaces must be segmented.
The connection geometry of 2nd level space boundaries of walls/slabs/columns/beams andincluded openings/doors/windows do not overlap.

4.1.3.3 3rd Level Space Boundaries
3rd level space boundaries are special types of 2nd level space boundaries.








Type 3a - The most common type occurs where the element behind the boundary is abuilding element, rather than a space or zone. For example: the end of a wall (wall butt) that
divides two spaces on the other side of a wall.
Type 3b - a second type occurs where path based building elements intersect and overlap.
Type 3c - The third type occurs at non-orthogonal intersections of building elements where
the two sides of the element have different lengths (e.g. angled wall connections). The extra
length on one side or the other is defined to be a 3rd level space boundary.
3rd level space boundaries are typically ignored in heat transfer calculations for energy
analysis because the transfer in these cases is negligible. Identification of such boundaries, as
3rd level, enables energy analysis software to ignore them.
The combination of 2nd level and 3rd level space boundaries form a closed shell around thespace (so long as the space is completely enclosed).
Similar to 1st and 2nd level space boundaries, 3rd level space boundaries are a differentiation
into virtual or physical and internal or external space boundaries.
Implementers' Agreements --19

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

The connection geometry of 3rd level space boundaries is restricted to planar surfaces
only (same as for 2nd level). This means that curved surfaces must be segmented.
The connection geometry of 3rd level space boundaries of walls/slabs/columns/beams andincluded openings/doors/windows do not overlap (same as for 2nd level).
The Implementation Guide developed as part of this Testbed and completed under further
USGSA guidance defines a stepwise approach for calculating space boundaries in buildings. A
companion MVD provides software developers the means for implementation in software using
IFC structured data.
4.1.4 MVD For Building Performance and Energy Analysis (BPEA)
Two MVD‘s were constructed for the BPEA IDM: a Generic and a Model View Binding for IFC
2.3 version along with an Implementation Guide.
The Generic Model View presents a collection of diagrams documenting the concepts based on
the Exchange Requirements defined in the Information Delivery Manual (IDM). Note thatgeneric concepts are documented and cataloged in the MVD coordination database for reuseacross multiple MVDs.
The Model View Binding presents a collection of diagrams documenting how each genericconcept will be represented in the IFC 2.3 information model schema to be used for the exchange
Binding concepts are documented and cataloged in the MVD coordination database for reuse inmultiple MVDs that will use the same schema for exchange for other MVDs using IFC 2.3.
The Implementation Guide provides instructions for programmers about how to implement
specific concepts defined in the IDM and includes 3 parts:





4.2

Data instantiation diagrams - These diagrams document the exact information model entities
that will be used to represent the concept (e.g. IfcObject) and parameters that must be used
(e.g. property values),
Implementer agreements - Generally, these are agreed limitations to be used in thisrepresentation of the concept where the underlying information model schema would allow a
broader range of possibilities (e.g. agreement to use 3D facet geometry where the schema
would allow for other types of 3D geometry).
Reference data - in many cases, an MVD will make use of existing industry standards todefine value ranges (e.g. classification systems or enumerations defined in a reference
standard). If the exchange only allows values from such a reference standard, a URL or
information sufficient to access that reference standard will be provided.
IDM For Quantity Takeoff for Cost Estimation (QTO)

Quantity Take-Off is a precursor to completing a cost estimate to determine whether the design
meets the project budget. In the early design (conceptual) design phase, quantities used for
estimating are building or elemental level quantities as more detailed design information are notavailable. For example, the conceptual phase allows:Walls and slabs by area,
Windows by count by size,
Spaces by area,
20

OGC Document: OGC 10-003r1
bSa Document:



AECOO-1 Summary

Structural system by facility area,
Heating system by facility area,
Cooling system by facility area,

The output of the quantity take-off may be the result of a report produced by the cost estimating
application, which shows quantities. Other than a valid IFC file for use by cost estimating
applications, the QTO process does not produce any output.
Throughout the estimating process the estimator typically communicates through various media
with the design team, and perhaps the owner, to understand the design intent fully providing anappropriate estimate of building costs. Often, this post model output interaction among thevarious actors / roles is not captured formally. For Communication, Process and Decision (CPD)
Making functionality, the BIM must be able to document the actors / roles interacting with themodel. The various actors and roles mentioned specifically in the IDM are not indicative of all
potential actors / roles at early design stages.
4.2.1 Cyclical Design
The process of outputting a quantity take-off is cyclical to match the design submittal
requirements. It supports the cost estimating requirements to verify that the project design iswithin the established budget. The quantity take-off will have increasing complexity as thedesign progresses from early concept through final design.
4.2.1.1 Conceptual
This is the analysis work undertaken during the programming and concept design stage of the
project. It is about providing advice on the potential construction cost of a building to designroles and the client. The aim of this analysis is to determine the feasibility of concepts in acapital cost context. Conceptual analysis may be undertaken in the absence of detailed geometric
information about the building layout, though frequently general spatial layout is included during
this stage. Assumptions typically must be made at this stage, maintaining consistent assumptions
between the options being evaluated allows for evaluation of relative cost performance.
4.2.1.2 Detailed
This is the analysis work undertaken during the schematic; design development and construction
document stages of the project and assumes the availability of geometric and building system
information for the design. The overall process is the same at each stage of work, the difference
being simply about the extent of the information available and the level of certainty that can beapplied to the information. These factors impact the analysis methods used, which may range
from relatively simple area and elemental quantities at the earlier design stages to detailed
quantity take-off at the later design stages.
Within this process map below, the conceptual design phase of the project is shown. The process
map generically refers to the Design Team, Client – Client Staff and Client – Technical Staff orConsultants. For CPD integration, OmniClass Table 33 Disciplines provides a classification for
the actors and OmniClass Table 34 Organizational Roles provides a classification for the roles.
Any specific project team may require expanding the generic roles shown in process map todefine in greater detail the actors and roles of the project.
Figure 5 depicts the Concept Design business processes for Quantity Take-off.

21

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

Figure 5 – Concept Design Phase Quantity Take-Off

4.3

MVD for Quantity Takeoff for Cost Estimation

The same procedures as discussed in Section 4.1.4 were applied to the QTO IDM to develop the
QTO MVDs – both generic as well as for IFC 2.3.
4.4

Communications Project Delivery and Decision Support (CPD)This thread involved the development of a series of user scenarios and situations that enabledusers and software providers to demonstrate the accomplishments brought forward in the BPEA
and QTO threads with a test building. It involved the development of the test building in multiple
provider BIMs, a charrate that involved making changes to the building that impact energy
performance, quantities and costs.

22

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

5 Demonstrations and Webcast
Two demonstrations were completed as part of the AECOO-1 Testbed. The demonstrations
comprised a number of different energy and building performance components of the ―testbuilding‖, the results of energy analysis using EnergyPlus and the effect those changes had on
quantity of building materials and cost. The demonstrations used a number of different software
vendor products that interchanged IFC information using existing commercial off-the-shelf
software to perform the necessary calculations and results. The first demonstration was held in
Washington at the National Building Museum in March of 2009. The second demonstration wasvia a webinar in May of 2009.
A streaming webcast of the May 28 AECOO-1 webinar is available for review:
http://www.opengeospatial.org/pub/www/aecoo-1/index.html.
The webcast demonstrates results from the AECOO (Architecture, Engineering, Construction,
Owner and Operator industry) Phase 1 Testbed.
The demonstrations focus on early design for a new building. The owner of the new building isinterested to explore more energy efficient design alternatives and to have the building perform
more cost effectively for the next 30 years.
The owner hires a design team composed of architecture firm and a general contractor,
mechanical engineer and other professionals to conduct conceptual and early design services
with the objective exploring these facets as part of the overall design process. In preliminary
scoping meetings with the architect and general contractor team an established working budget
was established. The building owner enters into an Integrated Project Delivery (IPD) contract
with the architecture firm and general contractor to develop a schematic design package for thebuilding. The architecture firm/general contractor is tasked to evaluate several design
alternatives, providing estimates of energy performance, quantities and cost related to those
design alternatives. This input will allow the owner to calculate a return-on-investment for the
project, and predict long-term building operating costs. Given that this is early design, theschematic design package and work to be undertake is to better understand cost and explore costin terms of LEED building certification with relative performance options rather than absolutevalues
The iterative process of design, energy analysis, cost estimation and owner analysis that wasused in the demonstration is shown in Figure 6.

23

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

Figure 6 – AECOO-1 Demonstration flow of events

The demonstration highlighted four important conclusions of the Testbed:






Technology standards for interoperability provide a compelling approach for addressing
owners' business requirements for better communication, process management, decision
support and performance simulation of design alternatives;
Integrated Project Delivery (IPD) is realizable with interoperable technologies that enable
faster, cheaper, and more effective information processes;
Project design teams can bring both energy and economic impact analysis upstream (i.e.,earlier phases of design) using software that can seamlessly exchange data among
different vendors' building information model (BIM) software applications, such as BIM
authoring tools, quantity takeoff, value engineering, energy simulation, project anddocument management, and decision support; andMultidisciplinary project teams that work together with data-sharing tools and common
information models can indeed achieve better results faster than teams each working intheir respective stovepipe application settings.

The exchange of data using IFCs was accomplished as shown in Figure 7.

24

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

Figure 7 – IFC Data Exchange in Demonstration

The process and software of the demonstrations prove that the following are achievable today:a)Quantitative cost and performance justification of design decisions early in the design
process, resulting from parallel, partially automated and near-real-time cost estimating andbuilding energy performance simulation;b)Standardized process definition that indentifies tasks and information requirements for allparticipants and stakeholders, and unambiguously defines all data exchange requirements acrossthe process;c)Effective electronic information management and dissemination that serves all processes
and project participants and stakeholders; andd)Limited use of Industry Foundation Classes (IFC - ISO Standard 16739).

6 Lessons Learned & Recommendations
AECOO-1 provided bSa and OGC with a Petri dish in which to experiment with provenapproaches to standards development that are recognized globally as efficient, capable andtargeted and apply them to AEC market requirements. Given we were integrating a Testbed
process designed for rapid development of web services standards to the AEC market we draw
some conclusions for further discussion and follow-on testing by members of both organizations.
6.1

The Dimensions of BIM – Product, File and Conceptual

The belief that a Building Information Model is a way to organize information over the course ofthat facility‘s lifecycle is accepted in the market. The belief that BIM can and should be thesingle, unifying resource for a project is a key and essential conceptual objective going forward
25

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

for market efficiency is also accepted, but the idea that a BIM for any single project or portfolio
of projects can be explicitly represented by s single data model, file type and/or single vendor
software or suite of software packages is unrealistic. The AIA in its recent position statement12
about interoperability aptly describes today‘s situation:
Not all architects (or consultants, contractors, subcontractors, suppliers or owners) use thesame software packages for their work, nor should they: each should use the best tool forthe job in their particular business enterprise. But industry stakeholders do not work in a
vacuum: they must share information in order to complete projects, and the amount ofnecessary information sharing is increasing at a dramatic pace…
There are many dimensions to the data or information contained in software packages
used in the AEC industry today. Begin by considering a building information model:
every single object in a model has dozens or hundreds of discrete pieces of associatedalphanumeric or geometric data. Multiply that by the hundreds or thousands of objects inthe model. Then layer on possible other uses of the data beyond the model, like
performance analysis of the design (structural, thermal, lighting, etc.), project
management, estimating or facility management software, or sharing of the data between
different BIM applications, and so on. Acknowledge that some of the data is timesensitive and may change over the life of the model. The complexity of ensuring those
hundreds of thousands of pieces of data be shared between packages in an accurate,consistent, complete and effective fashion, especially when one acknowledges the
proprietary nature of the software packages, is mind-boggling.
The areas of expertise that flow into the design, development, and execution of a building project
and/or a portfolio of properties are so diverse and distinctive that the industry must continue toplan for a scenario where firms use the best software for the particular job at hand, whether thatjob is design, energy utilization, project management, RFI tracking, code compliance, etc.
We now witness products being offered as BIM by individual vendors that offer users an array of
one-stop, integrated offerings, often tied together by a proprietary data model(s) to support thefull range of requirements identified above.
We also must acknowledge that due, in part to the lack of widely accepted and used applicationand data interoperability processes that are standardized across the marketplace, vendors andusers have developed symbiotic relationships to satisfy business practice.
Finally, we need to acknowledge that a standard information model for building information
classes is available. This standard, while still evolving to capture new requirements, has notbeen seen as an adoptable counter response to current vendor and user relationships and theperceived efficiencies of proprietary data structures. For the most part the standard is treated as
more of an exotic framework for information exchange than as market driven best practice. The
buildingSMART alliance and the NBIMS project exist to correct these market failures and raiseawareness about the negative impacts and costs vendor lock-in creates throughout the market,
and undertake necessary at the standards level for the market to gain the confidence and

12

New Position Statement Request On Interoperability and Project Deliver – Submitted by the Board of Integrated
Practice Discussion Group, 2009.

26

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

experience the benefits open standards information exchange provides not unlike in other fields
such as emergency response, geospatial information, finance and healthcare.
We begin by accepting that BIM is a concept, not a product per se, nor a single file type that canbe stored in a database or on a hard drive. The BIM is the digital representation of a project.
Therefore, it is unreasonable to ever expect the whole BIM to be interoperable, and exchanged
between software packages. The BIM is distinctive, and unique to every project.
Recommendation: bSa and allied national and international standards bodies should clarify
market confusion regarding the term BIM, and set out in well defined, well coordinated andunderstandable ways to define the full utility of BIM and BIM-related standards and to shiftproviders business practices to deliver market driven, standards-based collaboration andfacility lifecycle management tools. The next two recommendation define a way forward forachieving this end state.
Recommendation: Standards for BIM exist in piece parts; there is no underlying base thatserves as the foundation for information exchange. Architecting (in the information sense)
where BIM standards are needed should start with abstract concepts using well-known
methods for Reference Architecture and Reference Model13. Key assumptions to be defined
include resources that are distributed across ownership boundaries, people and systems
interactions, security, management and governance. Interactions between people and systems
is primarily through exchange of messages with reliability that is appropriate for the intended
users and purposes.
Recommendation: The essence of information standards for BIM (and all its associated data
categories and attributes) is based on 1) standards bodies organizational structures whose
focus are responsibility for elements of the types of architectures listed above; and 2)
development of “successful” standardized business practices and modeled informationexchanges. (Successful is meant to mean that the practices and exchanges are connectedacross a set of numerous, but commonly defined data and information service levels andshown to work in run time condition).
6.2

Information Interoperability and Data Exchange Across BIM

Information interoperability needs to occur when two people using different software need tocommunicate effectively and efficiently. This idea may seem simplistic, but it helps clarify andconstrain the problem. A structural steel cost estimator doesn‘t need the entire BIM to do his/herwork. In fact, it would be a waste of money for the cost estimation software vendor to build
whole BIM support into their product, and if they did, every time that BIM was delivered to theestimator and brought into the costing software, more money would be wasted carrying aroundinformation that had no bearing on the problem at hand.
13

See for example: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, Std
IEEE 1471-2000 and OASIS Reference Architecture for Service Oriented Architecture Version 1.0, Public Review
Draft 1, 23 April 2008. IEEE 1471 is the short name for a standard formally known as ANSI/IEEE 1471-2000,
Recommended Practice for Architecture Description of Software-Intensive Systems. Within IEEE parlance, this is a
Recommended Practice, the least normative of the kinds of IEEE standards. In 2007 this standard was adopted by
ISO/IEC JTC1/SC7 as ISO/IEC 42010:2007, Systems and Software Engineering -- Recommended practice forarchitectural description of software-intensive systems. (see: http://www.iso-architecture.org/ieee-1471/ieee-1471faq.html.

27

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

Lesson: What the industry must focus on- if an information architecture framework is agreed
to be found necessary and then developed- is creating as part of that architecture aninteroperability layer for major processes, or sub-tasks, that are common to every building
project, and require information exchange between specialized software packages (whether
between firms or within the same firm). The IDM as was constructed for topics in the
AECOO-1 Testbed begins to fulfill this role
The interoperability challenge can therefore be described as the ability to extract the smallest,
most directly relevant information required to execute a particular task, and share that
information in a manner that is understandable by a wide range of users that use a wide range ofsoftware packages. This information will come from a BIM, but the BIM is conceptual, and partsof it may (and usually do) reside in a host of different software database and application systems,
but the BIM and its conceptual requirements are likely to be needed where combinations ofdesign, project management, and communications management (e.g. email or Microsoft
Outlook) software are in constant use.
Lesson: Migrating the requirements of IDM into interoperability standards that can be
implemented by providers happens in the MVD. Once an IDM is agreed to the process forbringing those practices and exchanges into the world of software is fairly straight forward.
This interoperability level for BIM information exchange is called a Model View Definition(MVD) level in buildingSMART parlance. MVDs match up with project functions horizontallyand vertically in the AEC lifecycle. We do not see a need to make any one provider‘s BIM
package and related offerings interoperable with other providers, except at the point where theMVDs are constructed for purposes of information exchange. When well-devised businesspractices and processes are articulated in strong Information Delivery Manuals (IDMs) as weredeveloped in this Testbed, good MVDs can be created. And only then can interoperability be
expected from software providers.
Testing software providers‘ implementations of MVDs should be built into the standards
development process, and should take place before an MVD is approved. The exchange
requirements documented in one or more IDMs and their corresponding MVD may also need tobe re-examined during testing.
There are sets of MVDs that persist along the entire lifecycle, such as cost. Cost information isthe business of every stakeholder along the lifecycle. However, given the latitude and approaches
that cost estimators play at any given point, it may well be more efficient to provide a costestimator with tools that best enable their individual processes and choices. The issue of
messaging about cost information, and the ability to view that information along with supporting
attributes in other application‘s environments is the distinguishing interoperability requirement.
6.3

The BIM Concept Needs a Message-based, Web Services ApproachThis Testbed showed what is possible when MVDs are shared between parties using file
exchange via project management software, or simply email. The next step is to pass messages
that can act as a means for access, display, edit and seamless integration. So, in considering whatneeds to be accomplished by the market over the coming years are:
1. An agreement on an information architecture that encourages stakeholders to have
conversations among and between project team members with messaging.

28

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

2. A standards-based means for enabling messages to pass between the systems ofapplication providers in accordance with MVD requirements.
Recommendation: IFC is currently the lingua franca of MVD. Migrating from the file-based
nature of IFC to a messaging context about project details, management and coordination iswhat BIM information architecture is about. With this focus the enormity of the job is brought
down several notches in scale.
The market seems ready and willing to embrace an IT message-based architecture for the AEC
market that is purpose based, and matches the way people in the market want to work. There isroom for a shared vision, which resides in the databases of each provider, and provides any
stakeholder the ability to view their concept of those databases depending on their respective
expertise and responsibility. Conversations can then happen between organizations andindividuals at the MVD level of detail.
6.4

IFC Should Be XML

The market will eventually need to decide whether it wishes to pass files via Express or passmessages via XML. Each requires different skill sets and industry architecture. Maintaining both
requires providers to maintain two standards based libraries. Providers currently support boththeir internal data structure libraries as well as IFC/Express. Currently, IFC is seen as an exotic
format for providers to maintain and is not present in their core product offerings. Continuing torely on Express raises the probability that attribute data needed for information fidelity, using
IFC will continue to be marginalized.
The industry is already moving towards the exclusive use of XML for standards. Efforts withgood momentum include Green Building XML (gbXML), Automating Equipment Information
Exchange (AEX), aecXML, agcXML and Open Building Information Xchange (oBIX). XML
encodings such as those listed above are ready made for web services integration to BIM
software. Technically speaking, the Express language could be used to pass information in a web
services environment, but it is a poor fit and insufficient mainstream market adoption. XML is
designed to work with web services, and there is a wealth of mature supporting software andsoftware standards to facilitate the adoption of existing AEC-based XML encodings and schemawith existing web services standards to adapt AEC software offerings. Simply put, Express
creates an extra cost barrier whose value is questionable at best.
If IFC classes are to become a widely used and accepted industry standard, then the viewpoint ofthem being seen as exotic will need to end, and that signal can only come from the market. If thatsignal does appear, then interest and resources from the wider IT industry will be stimulated toaddress, maintain and further enhance interoperable open data models.
Leadership from the IT industry will also be helpful so that the myriads of attribute data products
from groups such as the Construction Specification Institute (e.g., OmniClass) can be rapidly
built out for software adoption using agreed upon transport and messaging frameworks.
In the demonstration, participants stretched their respective internal IFC toolboxes to enableslightly more interoperability among their proprietary BIM software applications and dataprocessing engines. In doing so, the teams discovered that some aspects of the IFC data model
are not amenable for interoperability as the word is commonly defined and practiced byindustrial communities that rely on collaboration via network processing, cloud computing, anddistributed data repositories to achieve results for decision support faster.
29

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

Recommendation: The IFC structure, first developed in the 1990's, should be modernized sothat a more complete suite of benefits from interoperability reaches critical mass and market
adoption. With IFC modernization, a far more open, comprehensive and intelligent life-cycle
data model for buildings can be achieved.
IFC modernization working in parallel with highly efficient network-based communication,
process management, decision support, and performance simulation of design alternatives is the
sweet spot for achieving benefit in real property industry projects. IFC modernization will also
tend to reduce the costs and inefficiencies that now result when builders and owners attempt tomaintain consistent and unambiguous use of original project information by all project
participants and stakeholders.
Annex A provides additional explanation about what can be done by bSa and other AEC-related
standards bodies to address the means to introduce messaging and web services forinteroperability. This annex explains and defines the mutual and supporting roles for the IT and
AEC communities about how they may come together to work these challenges.
6.5

Future Testbeds

At the outset of the AECOO-1, bSa and OGC set out a number of goals for this effort. They
included the following:







Develop wide ranging and reusable technology solutions that support community business
transformation;
Create a cost-effective and resource-efficient environment for industry to create standards
and implement and adopt market driven solutions;
Foster a vibrant and knowledgeable AECOO community of practice that builds industry
capacity to sustain transformation goals;
Induce software developers to meet broad user requirements with enhanced software
capabilities;
Promote market driven targets of opportunity for academic research; andPilot a repeatable industry process that with success leads to continuous requirements
definition and use of lessons learned.

Industry stakeholders, driven by economic necessity and global competition, desire applications
that can be knitted together and mate according to their individual practices and processes toprovide client with their brand of architecture, construction and building products and services.
Companies have also long sought to more effectively integrate information systems across theirorganization to better support business processes that cover all present and prospective
requirements needed to run the business end-to-end.
No one vendor has the best software for everything needed to author and/or evaluate a building‘sdesign, its cost, possible energy consumption, thermal comfort, lighting, acoustics, etc. The
industry requires the ability to seamlessly exchange and share building information among thesesets of information technology tools. These facts are what drove this testbed. A generalized
illustration of these problems is illustrated in Figure 8 below.

30

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

Figure 8 – The Corporate Example for Authoring, Analysis and Information Exchange Across the
Building Life Cycle

Given the broad and well accepted, but inefficient, ways that buildings and other capital facilities
are defined and constructed, the Sponsors have identified a few concerns about how virtual
building models need to perform with cost estimating and energy information analysis practices
during the iterative definition of space, design intent and construction quantities and theircharacteristics.
Let‘s presume for the moment that the NBIMS project is operational, and there exist operating
committees, working groups, that there are procedures for taking inputs and requirements in tothat body for defining candidate standards, and there is in place a voting mechanism forconsensus adoption. Where should Testbeds (as defined by this Report) be used? Where in theoverall process can their use be most helpful (by that we mean addressing requirements in theform of IDM‘s and MVD‘s that are shown to work and seamlessly exchange information acrossvendor products)?
Lesson: From our experiences in AECOO-1 we witnessed that many private businesses andpublic sector organizations have similar, if not the same requirements. This lesson should be
accounted for going forward in future work of NBIMS.
Lesson: a more clear delineation will need to be made about the role and place of bSa
fostering “ad hoc projects and aquariums” and formal Testbeds (that we presume will happen
within in the NBIMS project). We found bSa members confused by the purposes for each.
Each does have a distinct purpose and each can and usually does involve the expense ofresources (both cash and in-kind), however, the important difference for members to consider
is about the payoffs, as well as the longer-term status of standards development using accepted
consensus approaches and adoption throughout the market.
Formal Testbeds are the best known way to address both national and international requirements
where outcomes could result in the formal adoption of standards. Only through standards, can

31OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

the organizations across the AEC market reasonably address broader issues of risk. The Testbed
processes summarized here demonstrate that organizations can come together and work common
areas of interest, and by pooling their resources, achieve expected results with less individual
outlay, while providing a more rapid timeframe for success than with other means.
Recommendation: In considering the use of Testbeds and other rapid prototyping standards
development procedures that bridge gaps in communication across the AEC market, it is animperative that bSa and associated standards bodies create an underlying framework for theirwork. This underlying framework (or architecture) needs to be tailored to identifying gaps incommunication between AEC information systems and define what processes and tools in thestandards bodies inventory can be applied in particular instances. Generally, in the case of
IDM’s, AECOO-1 provides a template for future development of these kinds of documents thatenables those specifications to be brought into the IT arenas for software development.
However, Testbeds and other rapid prototyping activities are thought not the right venue for
their development per se. IDM’s comprise the information requirements that are thespecification that define what Testbeds ought to undertake with subject matter experts and IT
specialists working together to formulate an exactified representation of those specifications insoftware. MVD’s that are shown to work in running code of provider’s software are the mostefficient outcome of Testbeds. Both IDM’s and their companion MVD’s should have anarchitectural framework that covers both syntactics and semantics so that interoperability isrealized. (The reader is directed to Annex A for additional information and detail about thisrecommendation.)

32

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

Annex A: A Theory for Bridging Communication Gaps
Among AEC Stakeholders
Open software and data standards are the interlocking parts that enable interoperability
standards. For standards to be risk reducers, efficient and adoptable there needs to be anarchitecture on which the standards rest. This framework is developed using reference models
developed by non-exclusive industry consortia and task forces (like the OGC, Organization for
the Advancement of Structured Information Standards (OASIS), the World Wide Web
Consortium (W3C), the Open Mobile Alliance (OMA), the Internet Engineering Task Force(IETF) and others). These organizations' frameworks guide developers and integrators indesigning community-based and customer-specific open standard architectures for systems
implementation, based on community open data models, information exchange standards, open
interfaces, protocols, etc. that are intended to meet the needs of business enterprises, their userneeds, business models and workflows. The same must be in place for the AEC industry.
One of the characteristics present in the AEC market today is the lack of a clear separation
concerns between AEC business practices and domains and the means by which information
technology is supplied. The concept of separation is necessary so that systems and applications
meet their intended expectations. Separation of concerns comes from exact philosophy,
mathematics, programming and systems thinking that is the culmination of a shared exercise
between stakeholders in the AEC market and IT experts. These shared exercises are describedusing reference models to document the architectures that bind international information
standards, domain information standards, and agreed to means for communication andmessaging.
It is time to apply disciplined approaches to BIM standard making. As we consider more
explicitly the build out and structural aspects for BIM standards in more disciplined manners,
requires all stakeholders to exactifiy concepts and approaches that elicit understanding andspecify the semantics of what are non-trivial facility design, construction and management
practices and their respective IT system requirements. Creating these joint concepts across theindustry is the basis for successful communication between business professionals in the AEC
market and IT experts that build interoperable systems AEC professional want.
Throughout the Summary Report we have used the term interoperability and have defined thatterm in its broadest sense. Now we must place adjectives in front of that term so that we candefine more explicitly the kinds of disciplined work that lies ahead for both community
stakeholders and the IT providers that deliver systems and applications.
Let start with ―Syntactic Interoperability‖, which is all about parsing data correctly, and―Semantic Interoperability‖ which is all about the action of mapping terms and content analysis.
These two expressions have important ramifications for NBIMS standards -- syntactics is what
the MVD is about, and semantics is what the IDM is about.
Semantic interoperability requires formal and explicit specifications of domain information
models, and agreed to definitions of the terms used, their relationships and expected behaviors ofthat information. (Note another word for these kinds of models and which is often used in thework to define IFD is ontology.)

33

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

These expressions may be used not only for dealing with computer-based information
systems but also — and perhaps more importantly — for dealing with human stakeholders
communicating with other humans with computer-based systems.
The AECOO-1 Testbed has shown that communication gaps exist between AEC industry
practice stakeholders and IT experts. So, bSa‘s role and purpose in developing NBIMS can beexactified to correct instances where there is an absence of interoperability.
Firstly, without syntactic interoperability AEC business stakeholders are with their choice of
applications unable to parse data, so providers often resort to their own independent means toprovide that capability without the community‘s agreement. Of course, business experts cannot(and should not!) read code, but they also often cannot read specifications written by IT experts
using notations (or terminology) that are overly complicated or alien to business terminologies.
As we repeated often in the Summary Report, we need to understand the domain before
addressing software. Business models are the basis of an organization‘s entire activity. They are
to be understood by CEO and CFO, not just by CIO and explained without ‗method calls to
XML representations‘.
Using the same natural (colloquial) language as a notation is not sufficient since in order topreserve meaning we need also to preserve the same context, the same language experience,
language norms, cultural tradition, and so on, and often these properties of different people
acting in the AEC market are often implicit and different at the same time. For the information
technologist, also at the same time, there needs to be a restrictive artificial language with
precisely defined semantics that does not have context, cultural traditions, and so on, but still
guarantee an adequate transmission of a message‘s semantics, provided, of course, that it can beadequately represented in that language. This is both the conundrum and opportunity for the
AEC industry to apply a level of discipline to its information handling approaches.
An AEC Industry Architecture makes it possible (although not trivial!) to formulate
understandable specifications in a disciplined manner. Specifications will be read by people whoare non-experts in technology specification and especially applies to business specifications thatare all too often reduced to ―business rules‖ encased in software code.
Discipline means precision and abstraction. Precision means (among other things) that adeveloper will not have to invent business rules that have not been described and agreed to, or
have been described in ambiguous or incomplete ways. Abstraction means (among other things)
that the subject matter expert (e.g., architect, structural engineer, etc.) will not waste time andeffort trying to understand business rules in terms of a particular computer-based
implementation. Business rules (and a business enterprise in general) should be specified using
abstract and precise concepts understandable to any subject matter expert, analyst, developer,
or non-IT manager.
An AEC Industry Architecture uses these concepts for all kinds of specifications — thus
providing an excellent foundation for interoperability — and has been formalized by ANSI,IEEE, OASIS and ISO. This concept, if applied can describe the traditional businesses within
AEC, as well as describe the essentials of any existing or to-be-created information system
where interoperability is a requirement. In this manner, the business and IT stakeholders are able
to use a common system of concepts and therefore to communicate in a meaningful manner. Of
course, the syntactic representations used by different stakeholders to represent the same
semantics may and often does differ, and also of course, different stakeholders may be interested
34

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

in different levels and viewpoints when describing the same system, but the underlying semantic
framework still remains the same.
While using this concept for all kinds of specifications, we should explicitly separate businessfrom IT system specifications because traditional business and IT ontologies are different. (As awell-known example, a patient is not the same as the patient‘s records.) The Architecture offers
us the means to separate concerns. (For example, when we see that a specification becomes toocomplex for human understanding and is in danger of having ―too much stuff‖. ―Precise‖ is not
the same as ―detailed‖, and therefore being abstract does not mean being imprecise. Good
specifiers, in the same manner as good engineers, postpone decisions so as to not get drowned indetails. The higher the level of abstraction the more important it is to be precise).
Precision (exactification) is not sufficient for human understanding. Indeed, hundreds or
thousands of pages of precise material are useless if the material is not well-structured. In otherwords, understanding requires abstraction — ―suppression of irrelevant detail‖, so that essential
aspects of a specification are clearly separated from accidental ones. Clearly, this is not a new
approach, but it has not been stressed in most work undertaken in the AEC market, and it isinstructive that the concepts of abstraction, levels and viewpoints are among the first issues
described in the application of reference models to industry architecture .
Industry architectures use abstraction within the context of levels. Industry architecture also uses
abstraction within the context of viewpoints — form[s] of abstraction achieved using a selected
set of architectural concepts and structuring and sub-setting rules, in order to permit stakeholders
the room to focus on particular concerns within a system.
All viewpoints in any of the Reference Models are based on the same basic concepts ofviewpoints — enterprise, information, computational, engineering, and technology. It is possible
to define correspondences between viewpoints and Reference Models show how this isaccomplished, but often, one viewpoint cannot be defined in terms of another. Of course, the fivebasic viewpoints are not the only ones that may be used to describe a system. In accordance withthe definition of a viewpoint, any reasonable set of architectural concepts and structuring rules
may be chosen to focus our attention on particular concerns within a system; and therefore wemight simplify the work by defining business viewpoint and information system viewpoint which
are analogous to IDMs and MVD‘s, but at higher levels of abstraction. In this manner, forexample, we can exactify the slogan ―no requirements in terms of solutions‖ since requirements
and solutions belong to different viewpoints.
Creating and elucidating an AEC Industry Architecture domain model cannot be automated.
There is no algorithm (or tool) to do that. The architecture is created and elucidated by teams
consisting of domain subject matter experts and analysts who would work in NBIMS
committees. Even when the subject matter experts are experienced in formulating semantics andontologies of their domain in an abstract (that is, understandable) and precise manner, analysts
are still essential to discover, elucidate and exactify tacit assumptions common to all, or some,subject matter experts. (We found this particularly evident in our work on Quantity Take-off).
Ignorance — real or perceived — of the subject matter cannot be present if a specification
includes tacit assumptions that need or should become explicit. As early as the 1960‘s (incomputing technology history) IT experts would comment ―Get some intelligent ignoramus toread through your documentation; [...] he will find many ‗holes‘ where essential information has

35

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

been omitted. Unfortunately intelligent people don‘t stay ignorant too long, so ignorance
becomes a rather precious resource.‖
It is not sufficient to discover, formulate and use reference model concepts and structures
essential for a good architecture. The intent is to start communicating these discoveries, both forcommunicating an understanding of the architecture and for its usage, but to let evolve. If we
begin the architecture work using a concise and elegant suite of basic concepts then this provides
the foundation for the standards that follow.
In this context, it is instructive to reinforce the thought that ―requirements always change, andtherefore it is useless to formulate them‖. Indeed, business processes often change. Such changes
may lead to a competitive advantage for a segment of the industry or they may even be perceived
as necessary for the industry to survive. Similarly, decisions about using IT systems to automate
business processes may also change. At the same time, the basics of a business — its ontology— have usually remained the same for centuries. The changes due to modernity are minimal andare mostly additions to or refinements of the existing classical semantics and their use.
These considerations apply to any kind of business architecture initiative as well as torequirements about information discovery and specification, independently of whether acomputer-based IT system will be created, or bought to automate some business processes orworkflow steps. As noted earlier, a crisp business architecture is used to make demonstrably
effective business decisions only some of which are IT-related. Nonetheless, when viewed
holistically the concepts, constructs and ultimate standards created based on that architecture
define the art and science of effective reasoning.
From over 50 years of systems development experience It is now well understood that attempts
to comply with a specification that has incomplete or unclear semantics will not guarantee
interoperability because important information will be lost. Use of reference models and theirconcepts makes it possible to completely and precisely define the essential aspects of theuniverse of discourse, be it to describe a business or an information management system.
Using the approach suggested for NBIMS standards using the semantics of the appropriate
domain rather than on existing products or solutions, standards can be devised based on anarchitecture that itself is defined in a clear and crisp manner. If so, then the specifications can beread, understood, and thus agreed or disagreed upon by all stakeholders confidently. Moreover,
specifications of existing products or systems, including legacy systems, can be introduced backinto architecture and lead to demonstrably justified user decisions about acquiring such systems.

36

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

Annex B: AIA Statement on Interoperability (Proposed)
NEW POSITION STATEMENT REQUEST ON INTEROPERABILITY (Related to
Project Delivery)
Request for new Position Statement Submitted by the Board Integrated Practice Discussion
Group 2009 (IPDiG)
Interoperability Position Statement
The American Institute of Architects believes that all industry-supporting software must
facilitate, not inhibit project planning, design, construction, and commissioning and lifecycle
management. This software must support non-proprietary; open standards for auditable
information exchange (such as the building SMART International Industry Foundation Classes(IFC); open XML schemas; CIS/2; and other widely accepted open standards that may emerge
over time) and allow for confident data exchanges across applications and across time.
This is best accomplished through professional, public- and private- sector adoption of open
standards. The American Institute of Architects recognizes that it and its members have asignificant role in the ongoing development of open standards.
Interoperability Position Statement Explanation
Why Interoperability?
Not all architects (or consultants, contractors, subcontractors, suppliers or owners) use the same
software packages for their work, nor should they: each should use the best tool for the job intheir particular business enterprise. But industry stakeholders do not work in a vacuum: theymust share information in order to complete projects, and the amount of necessary information
sharing is increasing at a dramatic pace. Transforming business processes require datainteroperability. Data interoperability demands clear definition of necessary business informationexchanges. Not every exchange must contain all data; however, business information exchanges
required to facilitate the project should contain the information appropriate and necessary to
perform the function of the exchange or task at hand.
There are many dimensions to the data or information contained in software packages used in the
AEC industry today. Begin by considering a building information model: every single object in amodel has dozens or hundreds of discrete pieces of associated alphanumeric or geometric data.
Multiply that by the hundreds or thousands of objects in the model. Then layer on possible otheruses of the data beyond the model, like performance analysis of the design (structural, thermal,
lighting, etc.), project management, estimating or facility management software, or sharing of thedata between different BIM applications, and so on. Acknowledge that some of the data is timesensitive and may change over the life of the model. The complexity of ensuring those hundredsof thousands of pieces of data be shared between packages in an accurate, consistent, complete
and effective fashion, especially when one acknowledges the proprietary nature of the software
packages, is mind-boggling. It‘s also hugely wasteful and ineffective: a 2004 study by the
National Institute of Standards and Technology suggests that $15.8 billion is lost annually in the
AEC industry due to the lack of accurate and effective information exchange. The 2007 McGraw
Hill SmartMarket Report on Interoperability states that on average, 3.1% of the cost of every
project is waste due to lack of interoperability. The AIA must assume a leadership role in37

OGC Document: OGC 10-003r1
bSa Document:

AECOO-1 Summary

seeking a solution to this problem and should work with other organizations to reach effective
and positive outcomes.
Why open standards?
Effective information exchange requirements in other technologically intensive fields such as
emergency response, GIS, finance and healthcare are demonstrating the fundamental value of
open standards based information exchange. The AEC industry is not an exception and may
anticipate benefits similar to those experienced in other fields. Consider:
Every AEC software package is based on a particular, unique data schema (data organization
framework—how content is organized). This data schema is typically proprietary and hidden.
To accurately exchange information between any two software packages, one of the following
must be true:
1) Package B must be based on the same schema as package A; or
2) Package B must be able to directly import (map) data into its schema from the schema of
package A; or
3) Package A must be able to export (map) data from its schema into a transfer format or neutral
exchange schema, from which package B must be able to import (map) the same data into its
schema.
Condition 1 is uncommon; schemas are typically unique to every software package, and areprotected as proprietary information. Condition 2 involves close collaboration of the developersof the two software packages but limits an exchange to just those implemented. Condition 3 ispotentially the most robust, but requires that the two developers agree to the specifics of theneutral exchange schema.
If the example is expanded to include not just two packages but the larger world of software
packages used by all project participants, and the complexity of the hundreds of thousands ofpieces of necessary data exchange outlined above is layered on top, it becomes clear that twodevelopers agreeing on a neutral exchange schema is insufficient and that the AEC industry as awhole needs to agree on and support a neutral transfer schema. This is most practical throughindustry-wide adoption of an open data-sharing standard (exchange schema), visible andtransparent to all, supporting business workflows defined as much as possible by users.
Why should AIA members care?
Overall productivity loss and fragmentation in the capital facilities development industries is nolonger tolerable. Architects need to practice the best way they know, and practice profitably;
software interoperability problems must not hold them back. Potential of loss of competition in
the software market is not acceptable.
Without software interoperability:

Expense to the AEC and Owner in training and re-training in multiple platforms will
increase;
Waste in time, materials, energy and money will increase;
AEC and Owner productivity will continue its decline as data re-entry, document versioning
and checking, and other workflow problems increase;38

OGC Document: OGC 10-003r1
bSa Document:









AECOO-1 Summary

The capital facility industry may segment again, this time around software solutions;
Collaborative delivery models such as Integrated Project Delivery will not deliver the
benefits the profession anticipates;
Architects may not be able to access files in the future without fear of loss of data or loss ofwhole file;
Lack of competition may yield fewer affordable software solutions necessary to support
architects‘ business practices;
Architects may lose future commissions and necessary collaboration partners;
The software industry will not achieve the robust development of the analysis and simulation
tools and interfaces necessary to serve the rapidly changing industry;
New software concepts, tools and opportunities may be marginalized if dominant software
companies release interoperability features following their own agendas.

A large, competitive, interoperable software market is needed for innovation to flourish.

39