BIM is the life-cycle management of the built environment supported by digital technology. It is first and foremost the process of developing and leveraging actionable information (standardized, accurate, transparent) to efficiently manage the total cost of ownership and functional requirements of a built asset (building, infrastructure, etc.).
BIM is NOT rocket science, it is not 3D pretty pictures, it is not all about technology. BIM first and foremost about early and ongoing collaboration, continuous improvement, and robust life-cycle management process supported with integrated technology and standardized information.
Collaboration construction delivery methods such as Integrated Project Delivery for major new construction, and Job Order Contracting for renovation, repair, sustainability, and minor new construction are important, if not requisite, components of BIM. Equally important from an Owners perspective is the integration of multiple competencies, business processes, and technologies such as capital planning and management (CPMS) for capital reinvestment strategy, computerized maintenance management (CMMS) for “movable” asset inventory and routine/preventative maintenance, computer aided facility management (CAFM) for space mangement, building automation (BAS) for security/energy, and geographical information (GIS) for rapid locationing. Forget “integrated workplace management systems” (IWMS), they are attempts at BIM by single vendors. As one might expect, no single company can be expected to be competent across all knowledge domains and practices. Through the use of standardized informatoin exchanges, “best in class” technologies will finally be easily integrated as “plug-ins” to a users cloud-based technology platform.
The day is here…. you can wake up or go back to bed…your choice.
Key additional items/areas to consider:
COBie – Construction Operations Building Information Exchange – Organisation and structuring of information. This is information that is essential not only to the design and construction of a built asset, but also its operation and maintenance. Currently focused upon delivering FM information at handover, but rapidly expanding.
OMNICLASS – A standardized information classification system for the built environment. An integration and expansion of UNIFORMAT, MASTERFORMAT, etc.to incorporate all buildings spaces, equipment, processes, technologies, etc.
Standard Cost Data – Most notable example is RSMeans. Well researched cost data (material, equipment, labor) and associate construction / facility management sq. ft., assembly, and unit cost information and associated task listings. Critical for use to “benchmark” and/or “confirm” local processes/projects. Also standardized using Masterformat.
Job Order Contracting – Collaborative construction delivery method using a standardized unit price book (UPB) based upon RSMeans and/or customized cost information. Cost are best update annually or quarterly. Process has been embedded within software to enable cost effective and consistent deployment. Reducing procurement costs, mitigates change orders, and virtually eliminates legal disputes.
Integrated Project Delivery – Similar to JOC, however best suited for major new construction only.
via http://www.4Clicks.com – Premier cost estimating and efficient project delivery software solutions for JOC, SABER, IDIQ, MATOC, SATOC, MACC, POCA, BOA, BOS … featuring an exclusively enhanced 400,000 line item RSMeans Cost Database, visual estimating/automatic quantity take off ( QTO), and collaborative contract/project/document management, all in one application. Our technology is currently serving over 85% of United States Air Force bases and rapidly growing numbers of other DOD and non-DOD (United States Army Corps of Engineers, Army, GSA, Homeland Security, VA..) federal departments/agencies, as well as state/county/local governments, colleges/universities, healthcare, and airports/transportation. RSMeans Strategic Partner
Share Your Perspective on the Value of the NBIMS-US™
Take the NBIMS-US™ Survey
The Planning Committee for the nation’s building information modeling (BIM) standard is conducting a survey to obtain more information about the building industry’s use and perceived value of theNational BIM Standard – United States® (NBIMS-US™).
The three-minute survey is meant to capture information about the awareness, understanding and implementation of the NBIMS-US™ and find out what industry professionals think should be addressed in future versions of the standard.
The National Institute of Building Sciences buildingSMART alliance™ NBIMS-US™ Project Committee is currently in the process of balloting Version 3 of the standard. With the results of the survey, the Alliance will be better able to plot a path to steer future NBIMS-US™ content to address issues important to the building industry.
Today’s building professionals are increasingly using BIM in their work. The NBIMS-US™ is a consensus-based standard that supports users in their implementation of BIM. Because a BIM covers all aspects of the building process, and everyone in the construction industry will be impacted as the use of BIM becomes standard operation procedure, it is increasingly important that representatives from every segment of the industry participate in development of the standard. With more industry input, the standard can become stronger and more effective, helping the U.S. building industry to become more efficient and productive.
The survey is open until November 15. It consists of 15 multiple-choice questions and should take no more than 10 minutes to complete. The buildingSMART alliance™ will share the survey results during Building Innovations 2014: the National Institute of Building Sciences Conference and Expo, the week of January 6-10, 2014. Take the survey now.
About the National Institute of Building Sciences
The National Institute of Building Sciences, authorized by public law 93-383 in 1974, is a nonprofit, nongovernmental organization that brings together representatives of government, the professions, industry, labor and consumer interests to identify and resolve building process and facility performance problems. The Institute serves as an authoritative source of advice for both the private and public sectors with respect to the use of building science and technology.
An Authoritative Source of Innovative Solutions for the Built Environment
via http://www.4Clicks.com – Premier cost estimating and efficient project delivery technology, services, and enhanced RSMeans Cost Data – JOC, SABER, IDIQ, MATOC, MACC, POCA, BOA and more!
The OmniClass Construction Classification System (known as OmniClass™ or OCCS) is a classification system for the construction industry. OmniClass is useful for many applications, from organizing library materials, product literature, and project information, to providing a classification structure for electronic databases. It incorporates other extant systems currently in use as the basis of many of its Tables – MasterFormat™ for work results, UniFormat for elements, and EPIC (Electronic Product Information Cooperation) for structuring products.
COBie, the Construction-Operations Building information exchange, is the United States standard for the exchange of information related to manage building assets. There are over twenty commercial off the shelf software products that support COBie. These products cover the entire facility life-cycle from planning, design, construction, commissioning all the way to operations, maintenance, and space management.
While COBie provides the format for asset information, it does not provide details on what information is to be provided when, and by whom. This guide provides best-practice guidelines for these requirements. By referencing this Guide in design and construction contracts owners are now about to specify both the format and content of COBie deliverables.
COBie does not add new requirements to contracts; it simply changes the required deliverables from paper documents, or proprietary electronic formats, to an open, United States standard format. COBie and this Guide may be thought of as a performance-based specification for the delivery of building information.
1 INTRODUCTION
Building Information Modeling (BIM) technology has demonstrated its ability to reduce overall project cost through the identification of physical conflicts between building components prior to construction. Resolving such issues during design eliminates expensive tear-out and rework during that would have otherwise occurred during construction. The use of BIM for geometric collision detection has been the starting point to understand the potential use of building information.
The buildingSMART alliance has begun to unlock the non-geometric information content in BIM through the standardization of contracted information exchanges that will eventually replace the paper-based document exchanges currently specified by contracts. The goal of these standards is to provide the required information content when created, and securely share and update specified portions of that information with authorized team members as the project proceeds.
Rather than producing wasteful paper documents whose content is impractical to extract, these standard information exchanges streamline current process to eliminate waste and increase profitability. The first of these standards, the Construction-Operations Building information exchange, or COBie4, delivers facility asset information. These assets are scheduled equipment, products, and spaces. Readers unfamiliar with COBie should begin by watching the following two on-line presentations: Class 1. Overview Class 2. How To
It is assumed that readers of this document have viewed these two on-line presentations.
2 PURPOSE OF THIS COBie GUIDE
The objective of this document is to identify the specific requirements of COBie deliverables for design and construction contracts. This document is not a software user manual. There are two parts to this document. First are common requirements to be met regardless of client. The second part is the set of client-specific requirements that must be met in addition to the general requirements. Client-specific requirements may be found in “Appendix A – Owner’s Requirements.”
There are over twenty commercial off the shelf software products that support the production and/or consumption of building asset information through COBie. The results of software testing conducted by the National Institute of Building Sciences are documented on the COBie Means and Methods web page7. Given the differences in software configuration and version, those producing or consuming COBie deliverables using commercial software solutions should conduct their own test using any one of three common test models8.
Instructions on using these systems to produce or consume COBie data must be obtained directly from the software
Via http://www.4Clicks.com – Premier software for construction cost estimating and efficient delivery methods – JOC, Job order contracting, SABER, IPD, SATOC, IDIQ, MATOC, MACC, POCA, BOA …
Formal release of two Industry Foundation Class Model View Definitions for consideration by the international AECOO community. Below is an introduction, source is E. William (Bill) East, PhD, PE. F.ASCE, Research Civil Engineer, Engineer Research and Development Center, 2902 Newmark Drive, Champaign, IL 61826..
FM Handover 2011
——————————————————————————–
Facilities Management Handover for data sharing in the construction and facility management industries
Scope
ISO 16739 specifies a conceptual data schema and an exchange file format for Building Information Modeling BIM data. The conceptual schema is defined in EXPRESS data specification language (EXPRESS) as specified in ISO 10303-11.
ISO 16739 represents an open international standard for BIM data that is exchanged and shared among software applications used by the various participants in a building construction or facility management project.
ISO 16739 consists of the data schema, represented as an EXPRESS schema specification, and reference data, represented as definitions of properties and quantities.
A subset of the data schema and referenced data is referred to as a model view definition. A particular model view definition is defined to support one or many recognized workflows in the building construction and facility management industry sector. Each workflow identifies data exchange requirements for software applications.
The document represents a model view definition for facilities management.
The following are within the scope of this MVD:
■Building Information Model exchange format definitions that are required during the life cycle phases of buildings:
◦coordinated design;
◦procurement and full financial authority;
◦production information;
◦construction;
◦operation and maintenance.
■Building Information Model exchange format definitions that are required by the various disciplines involved within the life cycle phases: ◦procurement;
◦construction planning;
◦facility management;
◦project management;
◦client requirement management;
◦building authority for permits and approval.
■Building Information Model exchange format definitions including: ◦project structure;
◦physical components;
◦spatial components;
◦processes;
◦resources;
◦controls;
◦actors;
◦context definition.
The following are outside the scope of this MVD:
■exchange format definitions outside of the domain of construction and facility maintenance;
■project structure and component breakdown structures outside of building engineering;
■behavioral aspects of components and other information items.
Introduction
The Facilities Management Handover Model View contains information information describing the operations, maintenance, and assets in capital facilities.
The authoritative sources for this information include designers, builders, installers, and manufacturers. On the design side of the exchange, BIM-based design tools may be used to capture such data. From construction, information about approved submittals are included in data exchanges. Builders identify products to be installed. Manufacturers provide operating and maintenance information. Installers provide serial and tag numbers. Quality Control/Assurance staff provide test and certification reports. All these parties can capture building handover data through this standard, tying their diverse set of software together for the purpose of providing a consistent data set of operations, maintenance, and asset management to building staff.
Normative references
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 10303-11, Industrial automation systems and integration — Product data representation and exchange — Part 11: Description methods: The EXPRESS Language Reference Manual
ISO 10303-21, Industrial automation systems and integration — Product data representation and exchange — Part 21: Implementation methods: Clear text encoding of the exchange structure
ISO 10303-28, Industrial automation systems and integration — Product data representation and exchange — Part 28: Implementation methods: XML representations of EXPRESS schemas and data, using XML schemas
ISO 16739, Industry Foundation Classes (IFC) for data sharing in the construction and facilities management industries
ISO 29500, Information technology — Document description and processing languages — Office Open XML File Formats
Terms, definitions and abbreviated terms
Terms and definitions
For the purpose of this document, the following definitions apply.
Scalar values or collections including Set (unordered, unique), List (ordered), or Array (ordered, sparse) as defined in ISO 10303-11.
Note Similar to the term “field” in common programming languages.
inverse attribute
A unit of information defining queries for obtaining related data and enforcing referential integrity.
Note Similar to the term “navigation property” in entity-relational programming frameworks.
derived attribute
A unit of information computed from other attributes using an expression defined in the schema.
constraints on attributes
Data type restricting the values of attributes.
Note The most general constraint is about the existence of attribute values. There are basically two types: mandatory and optional attributes. Values of mandatory attributes must be provided whereas values of optional attributes may be omitted.
Note For aggregation data types such as Set, List, or Array, the existence constraint is often refined by a minimal and maximal number of elements, which is also known as cardinality.
entity
A class of information defined by common attributes and constraints as defined in ISO 10303-11.
Note Similar to the term “class” in common programming languages but describing data structure only (not behavior such as methods).
identification
Capability to find, retrieve, report, change, or delete specific instances without ambiguity.
instance
Occurrence of an entity.
Note Similar to the term “instance of a class” in object oriented programming.
object
Anything perceivable or conceivable that has a distinct existence, albeit not material.
type
A basic information construct derived from a primitive, an enumeration, or a select of entities.
Note Similar to the “Type” construct as defined in ISO 10303-11.
Note Similar in concept to “typedef” or “value type” in common programming languages.
select
A construct that allows an attribute value to be one of multiple types or entities.
Note Similar to the “Select” construct as defined in ISO 10303-11.
Note Similar to a “marker interface” in common programming languages.
enumeration
A construct that allows an attribute value to be one of multiple predefined values identified by name.
Note Similar to the “Enumeration” construct as defined in ISO 10303-11.
Note Similar in concept to “enum” in common programming languages.
actor
A person, an organization, or person acting on behalf of an organization.
A volume bounded by the top of a slab below, the bottom of slab(s) above, and by the surrounding walls, excluding coverings.
Note a specialization of the general term product.
room
A volume bounded by the top of a slab and floor covering below, the bottom of ceiling covering(s) above, and by the coverings of the surrounding walls.
Abbreviated terms
For the purpose of this document, the following abbreviated terms apply:
GUID
Globally Unique Identifier
IFC
Industry Foundation Classes
IFD
International Framework for Dictionaries
SPF
STEP Physical File
STEP
STandard for the Exchange of Product data
URI
Uniform Resource Identifier
Exchange requirements
Various exchange scenarios are identified spanning the lifecycle of information exchange for facilities management. Such scenarios are partitioned by user role and project stage.
The diagram below shows each exchange scenario in order of process sequence proceeding left-to-right over time, and in order of control sequence proceeding top-to-bottom over authorizing role, where higher roles generally commission and/or regulate lower roles. Communication is indicated by arrows, where the start point (circle) indicates the origination of information and the end point (triangle) indicates the destination of information. Arrows connected in sequence indicate intermediate passing of information for approval and forwarding.
NOTE Roles and exchanges are provided for illustration, and may be adapted according to requirements and contract conditions for specific projects.
PROCESS
All data is based on the schema defined by ISO 16739 (Industry Foundation Classes, Version 4). Data may be encoded in any of the following formats, including:
IFC-SPF: The ISO-10303-21 text format lists each data instance on a line, having an instance number, the type name, and direct attributes in order.
IFC-XML: The ISO-10303-28 text format lists data instances within hierarchical tags using the type name, with direct and inverse attributes contained in tags.
OOXML: The Open Office XML format organizes data into a spreadsheet, where data may be stored using pages for object types, columns for attributes, and rows for instances.
All data is based on the schema defined by ISO 16739 (Industry Foundation Classes, Version 4). Data may be encoded in any of the following formats, including:
IFC-SPF: The ISO-10303-21 text format lists each data instance on a line, having an instance number, the type name, and direct attributes in order.
IFC-XML: The ISO-10303-28 text format lists data instances within hierarchical tags using the type name, with direct and inverse attributes contained in tags.
OOXML: The Open Office XML format organizes data into a spreadsheet, where data may be stored using pages for object types, columns for attributes, and rows for instances.
Start
Project Definition
This exchange includes initial project information to describe a project and its contents.
Entities exported for this exchange include the following:
IfcProject: Directory and context of data is provided.
IfcActor: Project participants, roles, and contact information is provided.
IfcSite: Site (General) information must be provided to identify the site upon which the the facility is placed.
IfcBuilding: Facility (General) information must be provided to identify the facilities in which floors and spaces may be found.
Requirements
Space Program
This exchange includes requirements for the spatial layout of a building.
Entities exported for this exchange include the following:
IfcBuildingStorey: Provide the name of each conceptual/physical vertical level of each of the facilities identified in the project wrapper, elevation value and units above local project datum, floor to floor height and units.
IfcSpace: Provide the name and floor for each space.
IfcSpatialZone: Identify conceptual zones within the building that have a similar or grouped pattern of use. For example, zones my refer to mechanical heating zones, alarm systems zones, or groups of spaces to be used for specific clients.
IfcPropertySet: Properties may be specified to indicate requirements at particular objects.
Design
Design Early
This exchange includes building layout information and allocation of products without regard for placement.
Entities exported for this exchange include the following:
IfcBuildingStorey: Provide the name of each conceptual/physical vertical level of each of the facilities identified in the project wrapper, elevation value and units above local project datum, floor to Floor height and units.
IfcSpace: Provide the name and floor for each space.
IfcElement: Identify general requirements of elements within the building.
IfcElementType: Identify specific product model types to be considered for use.
IfcSystem: System name for each system must be identified before it can be associated with specific products and zones.
IfcPropertySet: Properties may be specified to indicate requirements at particular objects.
Design Coordinated
This exchange includes building layout information and allocation of products with placement, connectivity, and assignment to systems and project participants.
In IFC4, zones may be indicated spatially with functional designation, material constituents are supported to identify multiple materials and properties.
Entities exported for this exchange include the following:
IfcSpace: Provide the name and floor for each space.
IfcElement: Identify general requirements of elements within the building.
IfcElementType: Identify specific product model types to be considered for use.
IfcSystem: Design building systems, structural systems, and distribution systems.
IfcPropertySetTemplate: Property set templates may be specified to indicate information to be provided for product types.
IfcSimplePropertyTemplate: Property templates may be specified to describe each property within a property set.
Product Template
This exchange includes product type information for specific product models provided by manufacturers.
Product types may be declared within a project without having any occurrences in IFC4. Project composition excluded (no placeholder building is necessary). Project libraries added (to provide link to originating property set templates).
Entities exported for this exchange include the following:
IfcProjectLibrary: Referenced libraries of property set templates are indicated.
IfcPropertySet: Properties may be specified to indicate requirements at particular objects.
IfcElementType: Identify specific product model types to be considered for use.
This exchange includes bid submission information with formal documents, and amended with bid issue requests and responses.
The IfcActionRequest entity captures all reported issues (or requests to do something), for which tasks may be assigned to carry out work to address an issue.
Entities exported for this exchange include the following:
This exchange includes product type information for product models selected to be used, without regard for particular placement.
Product types may be declared within a project without having any occurrences in IFC4. Project composition excluded (no placeholder building is necessary). Project libraries added (to provide link to originating property set templates).
Entities exported for this exchange include the following:
IfcProjectLibrary: Referenced libraries of product types are indicated.
IfcElementType: Identify specific product model types to be considered for use.
IfcRelDefinesByType: Indicate product types to be used at specific occurrences.
IfcPropertySet: Properties may be specified to indicate requirements at particular objects.
System Layout
This exchange includes detailed system connectivity information for building systems and distribution systems.
Entities exported for this exchange include the following:
IfcElement: Indicate specific element placement within the building.
This exchange includes product part information, which may be used for addressing components for connectivity or replacement.
IFC4 allows product types to have assigned process types and resource types, which may indicate standard processes (i.e. manufacturer-defined) for servicing or replacing parts.
Entities exported for this exchange include the following:
IfcTaskType: Indicate product part replacement processes.
This exchange includes reporting on the condition of spaces over time.
In IFC4, all time-phased information is captured using performance-based properties on IfcPerformanceHistory. This allows for data to be recorded for multiple time periods (avoiding the single property set restriction), and to provide a uniform way of accessing and rendering time-phased data such that software applications need not be aware of particular properites. A property set should be defined for recording space conditions over time.
Entities exported for this exchange include the following:
IfcPropertySet: Properties may be specified to indicate condition details.
Product Parts Replacement
This exchange includes reporting on the replacement of product parts over time.
In IFC4, the process and resource model has been formalized, such that replacement of parts may be considered as a MAINTENANCE task with assigned resources for materials, labor, equipment, products, crews, subcontracts.
Entities exported for this exchange include the following:
IfcPropertySet: Properties may be specified to indicate details
Core data schemas
Figure 1 — Core data schema map
The core data schemas establish the most general layer within the IFC schema architecture as shown in Figure 1. Entities defined in this layer can be referenced and specialized by all entities in the shared element layer and the domain specific layer. The core layer provides the basic structure, the fundamental relationships and the common concepts for all further specializations in aspect specific models.
All entities defined in the core layer and above derive from IfcRoot, having unique identification, name, description, and change control information.
The shared element data schemas contain intermediate specializations of entities as shown in Figure 21. Entities defined in this layer can be referenced and specialized by all entities in the domain specific layer. The shared element layer provides more specialized objects and relationships shared by multiple domains.
The domain specific data schemas contain final specializations of entities as shown in Figure 26. Entities defined in this layer are self-contained and cannot be referenced by any other layer. The domain specific layer organizes definitions according to industry discipline.
The resource definition data schemas consist of supporting data structures as shown in Figure 40. Entities and types defined in this layer can be referenced by all entities in the core layer, shared element layer, and the domain specific layer.
Unlike entities in other layers, resource definition data structures cannot exist independently, but can only exist if referenced (directly or indirectly) by one or more entities deriving from IfcRoot. As resource definitions do not have a concept of identity (such as a GUID), multiple objects referencing the same instance of a resource entity does not imply a relationship. For example, two polylines (IfcPolyline) sharing the same instance for a point (IfcCartesianPoint), and two polylines using different instances for identical points (such as both having cordinates 0,0,0) are semantically equivalent. It is recommended (but not required) for applications to minimize file size by sharing identical resource definition instances where possible.
The resource definition layer should not be confused with construction resource entities (IfcResource subtypes). While the terms are similar, they are unrelated concepts.
This annex contains a listing of the complete MVD-XML view definition of the schema combining definitions of clauses 5, 6, 7, and 8 without comments or other explanatory text. These listings are available in computer-interpretable form that may be parsed by computer.
The following permission notice and disclaimer shall be included in all copies of these files (“the Schema”), and derivations of the Schema:
Permission is hereby granted, free of charge in perpetuity, to any person obtaining a copy of the Schema, to use, copy, modify, merge and distribute free of charge, copies of the Schema for the purposes of developing, implementing, installing and using software based on the Schema, and to permit persons to whom the Schema is furnished to do so, subject to the following conditions:
THE SCHEMA IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SCHEMA OR THE USE OR OTHER DEALINGS IN THE SCHEMA.
Table A.1 — File listings
Description
File
COBie MVD-XML listing describing model view scope and documentation.
This annex provides graphical diagrams of definitions in accordance with the graphical representation of EXPRESS as specified in annex D of ISO 10303-11. The figures correspond to the EXPRESS definitions in clauses 5, 6, 7, and 8.
B.2 Core data schemas
B.2.1 IfcKernel
B.2.2 IfcProcessExtension
B.2.3 IfcProductExtension
B.3 Shared element data schemas
B.3.1 IfcSharedFacilitiesElements
B.3.2 IfcSharedMgmtElements
B.4 Domain schemas
B.4.1 IfcConstructionMgmtDomain
B.5 Resource definition data schemas
B.5.1 IfcActorResource
B.5.2 IfcCostResource
B.5.3 IfcDateTimeResource
B.5.4 IfcExternalReferenceResource
B.5.5 IfcMaterialResource
B.5.6 IfcMeasureResource
B.5.7 IfcPropertyResource
B.5.8 IfcQuantityResource
B.5.9 IfcRepresentationResource
B.5.10 IfcUtilityResource
Annex C
(informative)
Exchange rules
IfcActionRequest
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Name’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActionRequest.Name’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘CreatedBy’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActionRequest.OwnerHistory.OwningUser.ThePerson.Identification’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘CreatedOn’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActionRequest.OwnerHistory.CreationDate’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Description’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActionRequest.Description’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘SheetName1’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActionRequest.HasAssignments[*].RelatingObject\’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘RowName1’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActionRequest.HasAssignments[*].RelatingObject’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘SheetName2’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActionRequest.Controls[*].RelatedObjects[*]\’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘RowName2’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActionRequest.Controls[*].RelatedObjects[*]’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘ExtSystem’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActionRequest.OwnerHistory.OwningApplication.ApplicationIdentifier’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘ExtObject’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActionRequest’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘ExtIdentifier’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActionRequest.GlobalId’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Mitigation’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActionRequest.IsDefinedBy[‘Pset_ActionRequest’]\.RelatingPropertyDefinition\IfcPropertySet.HasProperties[‘PreventiveMeasures’]’
RelatedObjects[0:?] > ‘IfcElement’
IfcActor
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Email’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.Name’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘CreatedBy’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.OwnerHistory.OwningUser.ThePerson.Identification’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘CreatedOn’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.OwnerHistory.CreationDate’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Category’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.HasAssociations[*]\IfcRelAssociatesClassification.RelatingClassification\IfcClassificationReference.Identification’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Company’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.TheActor\IfcPersonAndOrganization.TheOrganization.Name’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Phone’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.TheActor\IfcPersonAndOrganization.ThePerson.Addresses[*]\IfcTelecomAddress.TelephoneNumbers[*]’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘ExtSystem’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘TheActor.OwnerHistory.OwningApplication.ApplicationIdentifier’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘ExtObject’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘TheActor’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘ExtIdentifier’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘TheActor.GlobalId’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Department’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.TheActor\IfcPersonAndOrganization.TheOrganization.Description’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘OrganizationCode’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.TheActor\IfcPersonAndOrganization.TheOrganization.Identification’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘GivenName’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.TheActor\IfcPersonAndOrganization.ThePerson.GivenName’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘FamilyName’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.TheActor\IfcPersonAndOrganization.ThePerson.FamilyName’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Street’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.TheActor\IfcPersonAndOrganization.ThePerson.Addresses[*]\IfcPostalAddress.Street’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘PostalBox’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘ IfcActor.TheActor\IfcPersonAndOrganization.ThePerson.Addresses[*]\IfcPostalAddress.PostalBox’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Town’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.TheActor\IfcPersonAndOrganization.ThePerson.Addresses[*]\IfcPostalAddress.Town’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘StateRegion’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.TheActor\IfcPersonAndOrganization.ThePerson.Addresses[*]\IfcPostalAddress.Region’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘PostalCode’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.TheActor\IfcPersonAndOrganization.ThePerson.Addresses[*]\IfcPostalAddress.PostalCode’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Country’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcActor.TheActor\IfcPersonAndOrganization.ThePerson.Addresses[*]\IfcPostalAddress.Country’
RelatedObjects[0:?] = ‘IfcActor’
RelatedObjects[0:?] = ‘IfcActionRequest’
RelatedObjects[0:?] = ‘IfcPermit’
RelatedObjects[0:?] = ‘IfcProjectOrder’
IfcAsset
RelatedObjects[0:?] > ‘IfcElement’
IfcBuilding
.HasAssociations\IfcRelAssociatesClassification.RelatingClassification\IfcClassificationReference.Source = ‘OmniClass’ AND .HasAssociations\IfcRelAssociatesClassification.RelatingClassification\IfcClassificationReference.Identification > ’11-00 00 00′ AND .HasAssociations\IfcRelAssociatesClassification.RelatingClassification\IfcClassificationReference.Identification < ’12-00 00 00′
RelatedObjects[0:?] = ‘IfcBuildingStorey’
RelatedObjects[0:?] = ‘IfcSpatialZone’
IfcBuildingStorey
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Name’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcBuildingStorey.Name’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘CreatedBy’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcBuildingStorey.OwnerHistory.OwningUser.ThePerson.Identification’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘CreatedOn’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcBuildingStorey.OwnerHistory.CreationDate’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Category’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcBuildingStorey.HasAssociations[*]\IfcRelAssociatesClassification.RelatingClassification\IfcClassificationReference.Identification’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘ExtSystem’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcBuildingStorey.OwnerHistory.OwningApplication.ApplicationIdentifier’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘ExtObject’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcBuildingStorey\’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘ExtIdentifier’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcBuildingStorey.GlobalId’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Description’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcBuildingStorey.Description’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Elevation’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcBuildingStorey.Elevation’
.HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Name = ‘Height’ AND .HasAssociations\IfcRelAssociatesConstraint.RelatingConstraint\IfcObjective.Benchmarks\IfcMetric.DataValue\IfcTable.Columns\IfcTableColumn.Identification = ‘IfcBuildingStorey.IsDefinedBy[‘Qto_BuildingStoreyBaseQuantities’]\RelatingPropertyDefinition\IfcElementQuantity.Quantities[‘NetHeight’]\IfcQuantityLength.LengthValue’
Data within this specification may be mapped to tables found in databases, spreadsheets, or comma-delimited files.
Such spreadsheets may be imported or exported from any IFC format (IFC-SPF, IFC-XML, IFC-ZIP), containing the subset of data described within this MVD.
Standard mappings of IFC objects and attributes to tables and columns are specified at each included entity. These mappings may be encoded within IFC files as constraints related to an external association (document or library), such that application software may import, export, or synchronize content with such files or databases by understanding the mappings alone.
Annex D.2 Spreadsheet mappings
Spreadsheets in Office Open XML format (such as Microsoft Excel) may contain content described in this specification using the following conventions:
Each worksheet within a spreadsheet may contain objects of particular types or subtypes.
Each column within a worksheet may indicate a particular attribute (either direct, inverse, and/or along a graph).
Each row within a worksheet (except for the first header row) may indicate an object instance.
Each cell may indicate an attribute value.
Values for object references within a specific worksheet identify the referenced object by Name; therefore, it is required that each object have a unique name.
Values for object collections identify each by name and are separated by comma (commas are not allowed in names).
Values for object references of arbitrary types use two cells: one indicating the name of the worksheet, and another indicating the Name of the object instance.
Several columns are used throughout to provide standard behavior:
Name: This indicates the unique text identifier of an object corresponding to its Name attribute, with characters restricted as described herein.
ExtIdentifier: This provides the unique GUID identifier of an object in IfcGloballyUniqueId format.
ExtObject: This indicates the type of an object using the IFC entity name such as ‘IfcSensorType’.
The association of an IFC file to a spreadsheet may be indicated by IfcRelAssociatesDocument and IfcDocumentInformation, with mappings described by IfcResourceConstraintRelationship, IfcObjective, IfcMetric, IfcTable, and IfcTableColumn.
Annex D.3 Database mappings
Relational databases may contain content described in this specification using the following conventions:
Each table within a database may contain objects of particular types or subtypes.
Each column within a table may indicate a particular attribute (either direct, inverse, and/or along a graph).
Each row within a table may indicate an object instance.
Each cell may indicate an attribute value.
Values for rooted object references (deriving from IfcRoot) within a specific table identify the referenced object by GUID. Values for rooted object references of arbitrary types use two cells: one indicating the name of the table, and another indicating the GUID of the object instance.
Values for object collections (SET or LIST) identify each by GUID and are included in separate tables named in the form ‘{Entity}_{Attribute}’ with the GUID column ‘Value’ (and additional one-based integer column ‘Position’ for lists).
Values for non-rooted object references (not deriving from IfcRoot) and the graph of all referenced objects are serialized as XML using IFC-XML encodings. This affords efficient localized retrieval of data graphs such as geometry.
Values for STRING, BINARY, INTEGER, REAL, BOOLEAN, and LOGICAL use equivalent native database types.
Values for ENUM use strings.
The association of an IFC file to a database may be indicated by IfcRelAssociatesLibrary and IfcLibraryInformation, with mappings described by IfcResourceConstraintRelationship, IfcObjective, IfcMetric, IfcTable, and IfcTableColumn.
The duplex apartment model was originally created by a student who developed this building as part of a design competition. This model was first used at the Dec 2009 COBie Challenge event. The model provided here is the second version of this model completed by designers at Kristine Fallon and Associates.
E.2 Office
The two story office building model was developed based on the published sample floor plans for a specific type of mid-size office building built in the United States.
E.3 Clinic
The Clinic Model was developed based on an actual federal medical and dental clinic building at a location in the South-West United States. The model also comes with a set of redacted design drawings. A full set of operations and maintenance manuals are also available but have not yet been redacted, so cannot yet, be posted to this public repository.
Annex F
(informative)
Validation
F.1 Overview of mvdXML
Model View Definition XML (mvdXML) is a file format defined by buildingSMART International for describing and enforcing information exchanged using Industry Foundation Classes (IFC).
An mvdXML file is intended to be used for the following purposes:
Test servers for validating IFC files exported by applications;
Certification of software applications conforming to scope and requirements;
Software applications for enforcing valid data;
Documentation generation.
Using encoded business rules, most if not all requirements can be electronically validated.
F.2 Details of mvdXML
The following data structures are defined within mvdXML:
mvdXML: The mvdXML element comprises the scope of the mvdXML document, it includes zero-to-many model views and one-to-many concept templates (as a minimum, all concept templates that are referenced on the included model view(s)).
ModelView: The Model View Definition (MVD) that represents a subset of the IFC schema to cover the exchange requirements.
ConceptTemplate: The concept template holds the common definitions of a concept, that are independent of its use within a root concept. Concept nodes and concept leaf nodes reference a concept template to share the common description.
ConceptRoot: The root concept (called variable concept in MVD V2.0 documentation). It defines the main and independent entity that is part of a Model View Definition and also provides the root for all path information. Examples are IfcWall, IfcSpace.
Concept: The concept assigned to the root concept. It is an abstract element that can either be a concept node (called adapter concept in MVD V2.0 documentation), or a concept leaf node (called static concept in MVD V2.0 documentation). The concept is specific to the root concept and may reference a concept template for common descriptions.
ConceptNode: The ConceptNode element is an MVD specific concept, already assigned via a root concept to a model view. It has a reference to a concept template from which it re-uses the definition, it may add a specific definition that only relates to its particular usage for the root element. It has sub concepts, i.e. the information of whether it is required/optional is aggregated from its sub components.
ConceptLeafNode: The ConceptLeafNode is an MVD specific concept, already assigned via a root concept to a model view either directly, or via one or several concept nodes. It has a reference to a concept template from which it re-uses the definition, it may add a specific definition that only relates to its particular usage for the root element. It does not have any more sub contexts (it represents the leaf node).
ExchangeRequirement: The ExchangeRequirement element indicates a particular exchange for which a set of requirements at various entities may apply.
Definition: The Definition element indicates a human-readable description of the concept, with optional diagrams and external links.
Requirement: The Requirement element indicates how a concept applies to a particular exchange for import and/or export, and whether it is required, optional, prohibited, or not applicable.
AttributeRule: The AttributeRule element identifies an attribute relative to an entity, which may be either a direct attribute or an inverse attribute.
EntityRule: The EntityRule element identifies a type of entity that may be referenced by an attribute, either as a single object or within a collection.
TemplateRule: The TemplateRule element identifies parameters to be used for rules defined at re-usable templates.
Constraint: The Constraint element indicates an expression to be validated at a particular attribute.
F.3 Template Usage
Rules can be defined explicitly at concept leaf nodes (using AttributeRule), or parametrically (using TemplateRule) by using the defined template (containing AttributeRule).
The “TemplateRule.RuleID” attribute refers to an EntityRule defined on the template which is to be instantiated.
The “TemplateRule.Parameters” attribute indicates the set of parameters and values to be applied to referenced rules, each delimited by semicolon (same convention as HTML styles) or logical operator.
Each parameter-value component consists of the RuleID followed by a Constraint Expression. The RuleID identifies an AttributeRule and optional index delimiter for which the ConstraintExpression is applied.
The Constraint Expression contains an operator followed by a literal value or reference value (identified by RuleID).
The following logical operators are supported, corresponding to the IFC constraint model:
“AND”: All operands are true, alternatively a semicolon may be used as abbreviation (“;”);
“OR”: At least one operand is true;
“XOR”: Exactly one operand is true;
“NAND”: At least one operand is false;
“NOR”: All operands are false;
The following attribute index delimiters are supported:
“[0:1]”: For a SET or LIST, must be zero or exactly one instance meeting the rule.
“[1:1]”: For a SET or LIST, must be exactly one instance meeting the rule.
“[0:?]”: For a SET or LIST, must be zero or all instances meeting the rule.
“[1:?]”: For a SET or LIST, must be one or all instances meeting the rule.
“[1]”: For a LIST, the instance at the first index must meet the rule.
“[2]”: For a LIST, the instance at the second index must meet the rule (and so on).
The following comparison operators are supported, corresponding to the IFC constraint model:
“=”: equal;
“<>”: not equal;
“>”: greater than;
“>=”: greater than or equal;
“<”: less than;
“<=”: less than or equal.
The syntax of literal values varies according to the EXPRESS attribute type and follows ISO-10303-28 format:
INTEGER: The integer value; all operators supported.
REAL: The real value which must include a decimal point; all operators supported.
BOOLEAN: The boolean value as “true” or “false”; equality operators supported.
LOGICAL: The logical value as “true”, “false”, or “unknown”; equality operators supported.
ENUMERATION: The enumeration value by case-insensitive name; equality operators supported.
STRING: The string value, which may optionally be enclosed by single quotes (if escaping required); all operators supported, where comparison operators indicate alphabetical sorting (e.g. “>=” can indicate “must start with” such as the scope of a classification reference, or earliest date/time).
BINARY: The binary value encoded as hexadecimal prefixed by “%” and number of unused bits; all operators supported, where comparison operators indicate binary sorting.
ENTITY: The name of the entity type (e.g. “IfcWall”). Equality means exact type match; “>” means subtype of; “>=” means same type or subtype; “<” means supertype of; “<=” means same type or supertype.
Parameter values are indicated by specifying “#” followed by an arbitrary identifier of a shared instance. For example, a rule could indicate for IfcBeamStandardCase that an IfcProfile for an IfcExtrudedAreaSolid must match the profile defined within an associated IfcMaterialProfile, where they each equal the same value referenced as “#MP”.
E.4 Template Example
The following example illustrates the enforcement of an IfcSite object containing at least one IfcBuilding through the IfcRelAggregates relationship.
An aggregation template is defined to specify the graph of attribute and entities, where the RelatedObjects attribute has a RuleID indicated to enable referencing at leaf nodes: <mvd:ConceptTemplate uuid="02eefcc6-b26c-4f20-9c7c-c30ae74eb9a9" name="Aggregation" applicableSchema="IFC4" applicableEntities="IfcObjectDefinition">
<mvd:Definitions>
<mvd:Definition>
<mvd:Body>The object may be aggregated into components using IfcRelAggregates where RelatingObject refers to the enclosing object and RelatedObjects contains one or more components.]]</mvd:Body>
</mvd:Definition>
</mvd:Definitions>
<mvd:Rules>
<mvd:AttributeRule AttributeName="IsDecomposedBy">
<mvd:EntityRules>
<mvd:EntityRule EntityName="IfcRelAggregates">
<mvd:AttributeRules>
<mvd:AttributeRule AttributeName="RelatedObjects" CardinalityTypeEnum="OneToMany" RuleID="RelatedObjects" />
</mvd:AttributeRules>
</mvd:EntityRule>
</mvd:EntityRules>
</mvd:AttributeRule>
</mvd:Rules>
</mvd:ConceptTemplate>
The above template is then instantiated at IfcSite. The ConceptLeafNode identifies the template by UUID. The particular exchange where the concept applies is identified by the Requirement element. The TemplateRule element contains the expression “RelatedObjects[1:1]=IfcBuilding” which indicates that the rule having RuleID of “RelatedObjects” on the ConceptTemplate is to have a constraint of “=IfcBuilding”, where the “=” operator means the type must match exactly to “IfcBuilding”. Here, RelatedObjects refers to the IfcRelAggregates.RelatedObjects attribute, though the RuleID does not necessarily match the attribute name. As this attribute is a SET and the indexer is set to “[1:1]” there must be exactly one instance. <mvd:ConceptRoot uuid="3a75b425-a9fb-47a3-88ed-9ab3149d7263" name="Site" applicableRootEntity="IfcSite">
<mvd:Definitions>
<mvd:Definition>
<mvd:Body>A site is a defined area of land, possibly covered with water, on which the project construction is to be completed.</mvd:Body>
</mvd:Definition>
</mvd:Definitions>
<mvd:Concepts>
<mvd:ConceptLeafNode uuid="8a3e49b3-f8f7-4734-9b1f-3388442cc49b" name="Aggregation">
<mvd:Template ref="02eefcc6-b26c-4f20-9c7c-c30ae74eb9a9"/>
<mvd:Definitions>
<mvd:Definition>
<mvd:Body>A site may contain zero, one or more buildings.</mvd:Body>
</mvd:Definition>
</mvd:Definitions>
<mvd:Requirements>
<mvd:Requirement applicability="export" requirement="mandatory" exchangeRequirement="00000003-0001-4ac1-b901-da651988243c" />
</mvd:Requirements>
<mvd:Rules>
<mvd:TemplateRule Parameters="RelatedObjects[1:1]=IfcBuilding"/>
</mvd:Rules>
</mvd:ConceptLeafNode>
</mvd:Concepts>
<mvd:ConceptRoot>
The template may be applied to IFC files with sample data. The following data conforms to the rule (note that required attributes are omitted for brevity). <IfcSite>
<IsDecomposedBy>
<IfcRelAggregates>
<RelatedObjects>
<IfcBuilding />
</RelatedObjects>
</IfcRelAggregates>
</IsDecomposedBy>
</IfcSite>
The following data DOES NOT conform to the rule, as it contains multiple buildings. <IfcSite>
<IsDecomposedBy>
<IfcRelAggregates>
<RelatedObjects>
<IfcBuilding />
<IfcBuilding />
</RelatedObjects>
</IfcRelAggregates>
</IsDecomposedBy>
</IfcSite>
The following data DOES NOT conform to the rule, as it contains the wrong type of object. <IfcSite>
<IsDecomposedBy>
<IfcRelAggregates>
<RelatedObjects>
<IfcWall />
</RelatedObjects>
</IfcRelAggregates>
</IsDecomposedBy>
</IfcSite>
The following data DOES NOT conform to the rule, as one object is the correct type, and an additional object is of the wrong type. <IfcSite>
<IsDecomposedBy>
<IfcRelAggregates>
<RelatedObjects>
<IfcBuilding />
<IfcWall />
</RelatedObjects>
</IfcRelAggregates>
</IsDecomposedBy>
</IfcSite>
The following data DOES NOT conform to the rule, as it does not contain any IfcBuilding. <IfcSite>
</IfcSite>
” The construction industry is in the middle of a growing crisis worldwide. With 40% of the world’s raw materials being consumed by buildings, the industry is a key player in global economics and politics.
And, since facilities consume 40% of the world’s energy and 65.2% of total U.S. electrical consumption, the construction industry is a key player in energy conservation, too! With facilities contributing 40% of the carbon emissions to the atmosphere and 20% of material waste to landfills, the industry is a key player in the environmental equation.
Clearly, the construction industry has a responsibility to use the earth’s resources as efficiently as possible.
Construction spending in the United States is estimated to be $1.288 trillion for 2008. The Construction Industry Institute estimates there is up to 57% non-value added effort or waste in our current business models. This means the industry may waste over $600 billion each year.
There is an urgent need for construction industry stakeholders to maximize the portion of services that add value in end-products and to reduce waste.
Another looming national crisis is the inability to provide enough qualified engineers. Some estimate the United States will be short a million engineers by the year 2020. In 2007, the United States was no longer the world’s largest consumer, a condition that will force United States industry to be more competitive in attracting talented professionals. The United States construction industry must take immediate action to become more competitive.
The current approach to industry transformation is largely focused in efforts to optimize design and construction phase activities. While there is much to do in those phases, a lifecycle view is required.
When sustainability is not adequately incorporated, the waste associated with current design, engineering, and construction practices grows throughout the rest of the facility’s lifecycle.
Products with a short life add to performance failures, waste, recycling costs, energy consumption, and environmental damage. Through cascading effects, these problems negatively affect the economy and national security due to dependence on foreign petroleum, a negative balance of trade, and environmental degradation. To halt current decline and reverse existing effects, the industry has a responsibility to take immediate action.
While only a very small portion of facility lifecycle costs occur during design and construction, those are the phases where our decisions have the greatest impact.
Most of the costs associated with a facility throughout its lifecycle accrue during a facility’s operations and sustainment.
Carnegie-Mellon University research has indicated that an improvement of just 3.8% in productivity in the functions that occur in a building would totally pay for the facility’s design, construction, operations and sustainment, through increased efficiency. Therefore, as industryfocuses on creating, maintaining, and operating facilities more efficiently, simultaneous action is required to ensure that people and processes supported by facilities are optimized.
BIM stands for new concepts and practices that are so greatly improved by innovative information technologies and business structures that they will dramatically reduce the multiple forms of waste and inefficiency in the building industry.
Whether used to refer to a product – Building Information Model (a structured dataset describing a building), an activity – Building Information Modeling (the act of creating a Building Information Model), or a system – Building Information Management (business structures of work and communication that increase quality and efficiency), BIM is a critical element in reducing industry waste, adding value to industry products, decreasing environmental damage, and increasing the functional performance of occupants.
.Information Model Standard™ (NBIMS) is a key element to building industry transformation. NBIMS establishes standard definitions for building information exchanges to support critical business contexts using standard semantics and ontologies.
Implemented in software, the Standard will form the basis for the accurate and efficient communication and commerce that are needed by the building industry and essential to industry transformations. Among other benefits, the Standard will help all participants in facilities-related processes achieve more reliable outcomes from commercial agreements.
Thus, there is a critical need to increase the efficiency of the construction process. Today’s inefficiency is a primary cause of non-value added effort, such as re-typing (often with a new set of errors) information at each phase or among participants during the lifecycle of a facility or failing to provide full and accurate information from designer to constructor. With the implementation of this Standard, information interoperability and reliability will improve significantly. Standard development has already begun and implementable results will be available soon. BIM development, education, implementation, adoption, and understanding are intended to form a continuous process ingrained evermore into the industry.
Success, in the form of a new paradigm for the building construction industry, will require that individuals and organizations step up to contribute to and participate in creating and implementing a commonBIM standard.
Each of us has a responsibility to take action now.”
David A. Harris, FAIA President National Institute of Building Sciences
This exchange includes initial project information to describe a project and its contents.
This exchange includes requirements for the spatial layout of a building.
This exchange includes requirements for physical components of a building.
This exchange includes building layout information and allocation of products without regard for placement.
This exchange includes building layout information and allocation of products with placement and connectivity.
This exchange includes building layout information and allocation of products with placement, connectivity, and assignment to systems and project participants.
This exchange includes final design information with formal documents, and amended with design issue requests and responses.
This exchange includes definitions of properties to be captured by product templates.
This exchange includes product type information for specific product models provided by manufacturers.
This exchange includes bid submission information with formal documents, and amended with bid issue requests and responses.
This exchange includes product type information for product models selected to be used, without regard for particular placement.
This exchange includes detailed system connectivity information for building systems and distribution systems.
This exchange includes product placement information, including serial numbers at specific installations.
This exchange includes product inspection issues reported, which may require replacement of installed products.
This exchange includes construction issues reported, which may require additional labor.
This exchange includes product part information, which may be used for addressing components for connectivity or replacement.
This exchange includes product warranty information for parts and labor.
This exchange includes product maintenance information, including expected maintenance tasks and procedures.
This exchange includes system operation information, including system operation procedures and events.
This exchange includes reporting on the condition of spaces over time.
This exchange includes reporting on the replacement of product parts over time.
This exchange includes scheduling occupancy of spaces over time.
This exchange includes scheduling reconfiguration of spaces over time.
This exchange includes changing the building layout of an existing structure.
This exchange includes expanding the building layout of an existing structure.
This exchange includes demolishing an existing structure partially or in full.
LEAN Construction Project Delivery Methods - Job Order Contracting, IPD, 5D BIM 