MVD Releases

IFC4 Reference View

The IFC4 Reference View targets all work flows that are based on reference models. It is a buildingSMART Final Standard:

Name: IFC4 Reference View Version 1.0 Abbreviation: IFC4 RV V1.0 Quick links for users:

objectives of the IFC4 RV scope of the IFC4 RV comparison of objectives of IFC4 RV and DTV Quick links for developers:

IFC4 RV V1.0 specification online IFC4 Add 1 Release comparison of IFC4 RV and DTV entity tables

IFC4 Reference View - Version 1.0

The IFC4 Reference View V1.0 has been released as a buildingSMART Final Standard on 10.07.2015. The documentation is available at:

(online) http://www.buildingsmart-tech.org/mvd/IFC4Add1/RV/1.0/html/ (download) IFC4 RV V1.0 specification package

NOTE The IFC4 Reference View is based on the IFC4 Addendum 1 release.

In order to support the ongoing improvement process, issues and comments, both technical and editorial shall be logged within the buildingSMART International "IFC4 Issue Database".

access to the "IFC4 Issue Database" is provided »here« reading existing issues that have been logged under "IFC4 Issue Database" is open for all, in order to add your issue and comments, you need to be a registered user. For instructions, see »here«. we recommend to you to subscribe to the ifc4 mailing list that is hosted »here« (use this link to subscribe and maintain your account), after subscription, you will receive an automatic notification with the mailing address and you will receive further announcements and information.

Purpose of the IFC4 Reference View

The main purpose of the IFC4 Reference View is to define a standardized subset of the IFC4 schema, a Model View Definition MVD, that is particularly suitable for all BIM work flows that are based on reference models, where the exchange is mainly one-directional. Here requested modifications of the BIM data, mainly of the shape representation, are handled by a change request to the original author, and changes not executed upon the imported IFC data to be sent back to the original source.

Examples of this reference workflow are:

Coordination planning (combining different discipline specific IFC models for visual checking) Clash detection (finding clashes between different discipline specific IFC models) Background reference (loading an IFC model, usually from a different discipline) as a linked model Quantity take-off (determine the quantities of the various model elements with the IFC model) Construction sequencing (taking the IFC model and associating it to a construction schedule) Visual presentation (for presenting the IFC model to a broad audience)

Common characteristics of the workflow using reference models are:

The source of the BIM information remains with the originator The full parametric behaviour, and thereby the intellectual engineering property, remains with the originator The ownership of the model, and responsibility for its correctness, remains with the originator The original model is published as IFC4 Reference View model reflecting the as-is status The receiver of the IFC4 Reference View model has access to the full model content The receiver of the IFC4 Reference View is not supposed to modify the model The receiver of the IFC4 Reference View can analyse and extract the information of the model If the receiver demands a change, it has to be communicated as a change request to the originator The buildingSMART standard BCF is developed to efficiently support these change requests.

The Level of Detail of the shape representation and the Level of Information for the property content of the actual reference models depends on the source model. The buildingSMART standard IDM (Information Delivery Manual) can be used to determine the minimum content for a particular workflow support. The IFC4 Reference View allows rich content to be published, see next chapter Objective for more details.

IFC4 RV Objective

The IFC4 Reference View targets all work flows that are based on reference models. Read more:

Objective of the IFC4 Reference View

The main objective of the IFC Reference View is the widest possible proliferation of IFC BIM data across a big range of software application types supporting different communication and collaboration workflows.

The IFC Reference View is characterized by the ability to publish BIM data following that subset of IFC definitions that enables semantically rish content of building data, and to some degree also other built environment data, to be exchanges with a streamlined geometric representation that is optimized for analysis and display, but excludes dimension-driven geometric parameters. The geometric representation is therefore suitable for all workflow scenarios, where the imported IFC model is displayed, analysed, compared, clashed, but not parametricly modified for futher work processes.

Semantic building data models being exchanged using the IFC4 Reference View would typically include:

physical elements with explicit geometry, properties, quantities, material, and classification types of elements with associated physical elements to group common definitions (geometry, properties, material, and classification) spatial elements (spaces, zones) with explicit geometry, properties, quantities, and classification spatial structure elements (site, building, story), but also spatial zones for non-vertical construction element breakdown structure between physical elements (assemblies, sub-assemblies, parts) spatial breakdown structure between spatial elements (spatial decomposition of building, story or zones) spatial containment structure between spatial elements and physical elements (elements in spatial zone) logical system structure and assignment (physical elements assigned to systems and sub systems) topological structure of system networks (element to port, and port to port, relationship) common context of the building model, providing units, coordinate system and GIS positions general object identification using globally unique identifier Additional capabilities for enriching the semantic information exposed by the IFC4 Reference View can be defined as an Add-on Model View Definition. Forseeable examples are capturing 4D models with the addition of the work schedule related entities, or 5D models with the addition of construction resource related entities.

Workflow support by the IFC4 Reference View

The overall goal of the IFC Reference View is to provide workflows where building information models are to be consumed by the widest array of software applications that do not require modifying geometry. Such applications enable viewing, estimating, building, operating, and other downstream analysis.

ReferenceModel_Berlo

Figure: Reference model approach (by courtesy of Leon van Berlo, TNO)

EXAMPLE One target scenario is an architect providing building design information to a contractor or facility manager. It is expected that the resulting geometry would reflect sufficient realism for viewing in software (dimensions, normals, colors, textures), but not of rendering quality for artistic presentations (lighting, shader effects, curve interpolation, rasterizing). To support the widest array of consuming applications, the resulting schema should be as limited as possible for representing geometry in the interest of minimizing resources required of application developers. Such schema should also be as compact as possible to enable downstream use on mobile devices with limited network bandwidth. It is proposed that the resulting geometry is limited to triangles with normal vectors, color and texture coordinates and simple sweept solids with applied color and texture.

Compatibility Concerns for the IFC4 Reference View

As the IFC4 Reference View is new (there is no corresponding concept in the IFC2x3 Coordination View), there is no constraint for compatibility, and the resulting schema will leverage new triangulation definitions in IFC4 to support more efficient data transfer.

The second Model View Definition that is proposed in parallel to the IFC4 Reference View, the IFC4 Design Transfer View, is an extension of this model view. In other words, the IFC4 Reference View is a true subset of the IFC4 Design Transfer View.

Complying software interfaces, that implements import of the IFC4 Design Transfer View, shall also be able to correctly import IFC4 Reference View data sets. But not vice versa, a complying software interface, that implements import of the IFC4 Reference View will not be capable to import IFC4 Design Transfer View data sets. It is however required that a compliant software interface for importing IFC4 Reference View displays an agreed error message showing the IFC version, and the IFC Model View Definition of the imported IFC file, that does not match "IFC4 Reference View" with an explanation, that a non-compatible IFC file has been received.

NOTE The correct error message and the link to further information on the buildingSMART website explaining the purpose of the different IFC Model View Definitions need to be agreed upon. See next chapter Scope for more details.

IFC4 RV Scope

General scope of the IFC4 Reference View

The general scope defines the main functionalities of the IFC4 Reference View as an overview. It includes a complete listing of the model elements and model element types that are included in the IFC4 Reference View Model View Definition.

NOTE The Model elements are referred to as "Root Concepts" within the Model View Definition specification, being the individual root elements, that contain the attributes, geometric shapes, dynamic property sets and other semantic information that are combined and expressed as "Concepts". The common definition of a "Concept", that is applicable to many "Root Concepts" is called a "Concept Template". The detailed scope of the IFC4 Reference View is determined by the concept templates that are included. A detailed description of each concept template is provided by Chapter 4 "Fundamental concepts and assumptions" listed in the MVD specification delivery.

Model elements included in the IFC4 Reference View

Model elements The main components of the IFC4 Reference View are the semantic model elements that carry a predefined meaning. The complete breakdown of all model elements declared in IFC4 are also known as the IFC4 built-in classification following an element by function classification.

In addition to each of the model elements shown here in the subsequent tables, each Model element maybe further specialized by its "PredefinedType", or even a user defined type.

EXAMPLE An IfcFireSuppressionTerminal is a specific model element, that may be further specialized using its PredefinedType enumeration being: a sprinkler, a hose reel, a fire hydrant, or a breeching inlet. If a proper predefined type is not yet included in the specification, a user defined type can be assigned as well. Model element types Model element types are part of the IFC4 Reference View. They enable to describe and share common model element information that are shared by multiple occurrences of the same type. Sharable type information includes:

Geometric shape representation; Property information; Material information. EXAMPLE A particular air outlet as an article, with its shape, its material and its manufacturer information being described once as a type and then having several occurrences, each placed within the building, referencing the same type and hence its shape, material and properties.

MVD concepts included in the IFC4 Reference View

Object attribute All model elements, listed in the previous section, are defined by several generic and direct object attributes, some specific model elements do carry additional direct attributes. The usage of the direct generic attributes is defined within the following concept templates (see also Chapter 4 "fundamental concepts and assumptions"):

"Software Identity", it defines how to apply the Globally Unique Id and how to compress it during exchange; "User Identity", it defines the meaning of Name, Description, LongName, and Tag attributes; "Object Occurrence Predefined Type", it defines how to use the PredefinedType and in case of user defined types, how to assign the user defined type information within the ObjectType attribute for occurrences of model elements; "Element Type Predefined Type" it defines how to use the PredefinedType and in case of user defined types, how to assign the user defined type information within the ElementType attribute for types of model elements. Project context There is a single instance of IfcProject within each IFC data set. It sets the context for the exchange, including units, geometric context, global positioning and classification systems used within the data set. The usage of the project context is defined within the following concept templates (see also Chapter 4 "fundamental concepts and assumptions"):

"Project Units", declaration of the units used within this data set, all geometric representations are forced to use the global units (e.g. for length measure and plane angle measure), property values may override global unit declarations; "Project Representation Context", declaration of the 3D and 2D representation contexts, including precision factors; "Project Global Positioning" (new in IFC4), positioning the project engineering coordinate system (right handed Cartesian coordinate system) within a global coordinate reference system; "Project Classification Information", providing the name and version information about the classification systems used within the data set. Object definition A main objective of the IFC4 Reference View is to enable rich information content for each model element. Model element occurrences can refer to their model element types for sharing common information. General properties are attached to model elements as property sets, either directly to the model element occurrence, or to its type. Individual model element occurrences can hold their quantities, if those are pre-calculated by the sender of the IFC data set. The usage of the object definition is defined within the following concept templates (see also Chapter 4 "fundamental concepts and assumptions"):

"Object Typing", associates the Model element occurrences with the corresponding element type; "Property Sets", assigns dynamically defined property sets, holding set of individual properties, to the model element occurrences of element type; "Quantity Sets", assigns dynamically defined quantity sets, holding set of individual quantities, to the model element occurrences. Object typing The concept template describes the mechanism of associating model element occurrences to the corresponding type and the way and restrictions of overriding type based properties by properties directly assigned to the model element occurrences.

Property sets Property sets hold, as the name suggests, a set of properties grouped by a common theme. Each individual property has:

a name an optional description a value, or number of values, of a given datatype a unit or the information of being unitless The semantic meaning of each property is provided by its name. Properties, that are semantically declared within the scope of the IFC4 Reference View, are based on a property definition template that is published as an instrinct part of the Model View Definition. Extensions to the property definitions can also be defined outside the property definition scope of the IFC4 Reference View, however the name prefix for property sets "Pset_" is restricted to properties defined within the original scope of IFC.

There are two ways to declare property templates:

using the Property Set Definition PSD schema, an XML schema developed independent of the IFC specification, using the newly introduced IFC4 property set template and property template NOTE The PSD Schema has been used since many earlier versions of the IFC standard and has a broad legacy. The newer property set template definitions are now part of the IFC schema and can therefore be embedded within an IFC data set directly. Both schemas can be mapped without information loss. Quantity sets Quantity sets hold, as the name suggests, a set of quantities pre calculated for the model element occurrence. Each individual quantity has:

a name an optional description a value of a given datatype corresponding to the quantity measure (length, area, volume, weight, time a unit a quantity formula, describing how the quantity value was calculated The semantic meaning of each quality is provided by its name. Quantities, that are semantically declared within the scope of the IFC4 Reference View, are based on a quantity definition template that is published as an instrinct part of the Model View Definition. Extensions to the quantity definitions can also be defined outside the quantity definition scope of the IFC4 Reference View, however the name prefix for quantity sets "Qto_" is restricted to quantities defined within the original scope of IFC.

Object association In addition to the Property sets and the Quantity sets, also a classification reference to an external classification system can be assigned, and material as either single material, a material constituent sets or an material layer sets or material profile sets combining material information with dimensions can be associated to one or many model elements.

NOTE Material dimensions are layer thicknesses, or profile geometries for e.g. a column with an embedded steel profile and a concrete protection. Within the IFC4 Reference View, such material dimensions are used exclusively as alphanumeric information, and not as part of a dimension driven parametric shape representation. The usage of the object association is defined within the following concept templates (see also Chapter 4 "fundamental concepts and assumptions"):

"Material Association"; assigns a material (or material set - constituent, layer, profile) to one or several model elements (either to element occurrences, or as shared material information to element types). "Classification Association"; assigns a classification reference to one or several model elements. Product shape The first main objective of the IFC4 Reference View is to enable the exchange of highly accurate, not non-parametric, geometric representations of the model elements. Each model element is placed directly or indirectly within the project coordinate system, defining its own object coordinate system. The geometric representation items describing its shape are positioned within this object coordinate system.

In order to minimize the effort for receiving and interpreting the geometric representations by the receiving software systems, in terms of development effort, processing power and loading times, the complexity and variety of geometric models has been minimized for the IFC4 Reference View.

Product placement Each model element defines its own object coordinate system. The placement is defined by the following concept template:

"Product Local Placement", creating an object coordinate system for the shape representation of the model element, either absolutely to the project engineering coordinate system, or relatively to another object coordination system. Product geometric representation In scope of geometric shape representations of the 3D body geometry of physical and spatial elements are the following concept templates:

"Body Tessellation Geometry", using tessellated geometry in form of triangulated tessellations for describing the body shape of the model element; "Body SweptSolid Geometry"; using extruded solid geometry or revolved solid geometry for describing the body shape of the model element; "Body AdvancedSweptSolid Geometry"; using advanced swept solid geometry of circular cross sections for describing the body shape of the model element, only the swept disk solid is in scope; It is the default geometric representation of all model elements, allowing for a surface model representation with an indicator for closed shells (and therefore true volumes). The tessellated representation offers a very efficient way of exchanging 3D shape date, both for data set sizes and for processing time. Optionally the face normals can be exchanged as well.

Since curved shapes would lead to very densely triangulated areas, the following swept solid based representations are also in scope of the IFC4 Reference View, balancing simplicity and compactness of representation:

All other geometric models are out of scope of the IFC4 Reference View, in particular Boolean operations required for Constructive Solid Geometry CSG.

NOTE The IFC2x3 Coordination View included CSG capabilities, the IFC4 Reference View therefore imposes a more restricted geometric representation of model elements. The IFC4 Design Transfer View should be used, if more complex geometric representations are required by the workflow. In particular, if a dimension-driven parametric representation, used by the IFC4 standard case elements, is needed. The geometric shape representation can either be directly assigned to a model element, or to its type. In case of type-based geometry, a the following representation type is used at the model element using the following concept template:

" Mapped Geometry", mapped representation defined at the corresponding element type. A mapped representation uses Cartesian transformation operations to place the type-based geometry within its object coordinate system. As an exception, the following elements, IfcGrid, IfcSpace, and IfcSpatialZone may have an additional foot print 2D geometry (in case of IfcGrid this is the only geometric representation. It is described in the following concept template:

" FootPrint Geometry", defining a 2D shape representation within the XY plane of the object coordinate system. Geometric presentation Visual appearance is an important factor for the communication process using BIM data. The objective is not to support photo-realistic rendering of reference models, but to use color, basic rendering, and texture information to add visually accessible meaning to the model elements.

In scope of presentation capabilities for the appearance of model element shapes are the following partial concept templates:

" Surface Style Shading", applying a single coloring for each solid; " Surface Style Rendering", applying a single rendering (color, transparency, reflection, etc.) for each solid; " Surface Style Textures", applying a single texture for each solid according to a texture mapping based on the solid type; " Suface Style Tessellation", applying a color and/or texture for each face of a tessellated solid. The visually adequate presentation of model elements is constraint by the shape representation

for tessellated geometry: color per face, texture per face for swept solid geometry: color and rendering information per solid, texture applied to solid using standard mapping Object Composition The object composition functionality describes the product breakdown structure of model elements within an IFC data set, with separate breakdown structures for physical elements and spatial elements. Physical element structures describe parts and assemblies, spatial element structures describe vertical structures (for buildings) and horizontal structures (for other assets - as a stub in this release). A specific type of decomposition is the voiding - a subtraction of a void from a physical element. Another specific type is the nesting of ports within a distribution elements.

The usage of the object association is defined within the following concept templates (see also Chapter 4 "fundamental concepts and assumptions"):

"Element Decomposition", creating a hierarchical product breakdown structure relationship between assemblies and parts; "Spatial Decomposition", creating a hierarchical spatial decomposition relationship between spatial structure elements; "Element Voiding", creating a voiding relationship between a physical element and penetrating voids - within the scope of the IFC4 Reference View this relationship is a logical relationship, the void is already part of the geometry of the physical element, "Port Nesting", creating an 1:N relationship between the physical element and one or many ports defining inlets or outlets - used for distribution elements. Object Assignment The object assignment defines the assignment of objects, such as a link between model elements to groups, tasks or resources. Only the grouping assignment is in scope of the IFC4 Reference View and defined within the following concept template:

"Group Assignment", Assignment of one or several model elements to a group. It includes the more specific assignments of Grouping General, Grouping to System, and Grouping to Zones. Object Connectivity The object connectivity defines the interlinkage between model elements. Examples are the link between physical elements and the spatial structure, where they are located, of the connection between the two ports of two consecutive distribution elements.

The usage of the object association is defined within the following concept templates (see also Chapter 4 "fundamental concepts and assumptions"):

"Spatial Structure", defines the containment of a physical element within a spatial container; "Port Connectivity", defines the connection and the direction of flow between two ports of consecutive distribution elements; "Building Service Connectivity", links a spatial or distribution system to a spatial structure (such as a building section); "Element Filling", links a filling (usually a door or window) to an opening (usually in a wall or slab).

Comparison RV & DTV

Comparison of the objectives and target work flows

comparison of the objectives and target work flows IFC4 Reference View IFC4 Design Transfer View goals

satisfy the referencing work flow, i.e. the result of the import is a “read-only” (not modifiable)

satisfy the handover work flow, i.e. import for further editing (import into native elements) scenario includes

background reference clash detection any viewer based work flow

takeover architecture in structural import spaces into MEP takeover a previous design expected user experience

ownership remains with the sender frequent updates fast export / import times 100% validity, no rework expected

ownership handed over to receiver low frequency, sometimes “one of” longer export / import time tolerable some rework accepted, if limitations well known

IFC4 Design Transfer View

The IFC4 Design Transfer View targets all work flows based on models that are handed over to perform in next work flows, allowing modifications of its content. It is a buildingSMART Final Standard:

Name: IFC4 Design Transfer View Version 1.0 Abbreviation: IFC4 DTV V1.0 Quick links for users:

objectives of the IFC4 DTV scope of the IFC4 DTV comparison of objectives of IFC4 RV and DTV Quick links for developers:

IFC4 DTV V1.0 specification online IFC4 Add1 release comparison of IFC4 RV and DTV entity tables

IFC4 Design Transfer View - Version 1.0

The IFC4 Design Transfer View V1.0 has been released as a buildingSMART Final Standard on 10.07.2015. The documentation is available at:

(online) http://www.buildingsmart-tech.org/mvd/IFC4Add1/DTV/1.0/html/ (download) IFC4 DTV V1.0 specification package

NOTE The IFC4 Design Transfer View is based on the IFC4 Addendum 1release.

In order to support the ongoing improvement process, issues and comments, both technical and editorial shall be logged within the buildingSMART International "IFC4 Issue Database".

Purpose of the IFC4 Design Transfer View

The purpose of the Design Transfer View is to provide building information with support for editing of interconnected elements. Such applications enable inserting, deleting, moving, and modifying physical building elements and spaces. An example of a target scenario is an architect providing building design information to an engineer for a particular discipline, where geometric modifications may need to be made.

To enable such editing, higher-level design parameters must be preserved for those elements that affect multiple disciplines, and applications must generate downstream geometry consistently according to such parameters. The scope of parameters is limited to those that impact interconnected elements: for example, increasing window dimensions impacts composition of walls; moving walls impacts geometry of connected walls, adjoining spaces, coverings, and embedded elements; adjusting pipes or ducts may require resizing openings.

Examples of this design transfer workflow are:

Coordination planning and execution (combining different discipline specific IFC models for collaboration) Integrated reference (loading an IFC model, usually from a different discipline) as an integrated model Integrating and editing the spaces from an architectural IFC model into an MEP model Integrating and editing the load bearing elements of an architectural IFC model into a structural model Handover the complete discipline model for further work or archiving Enhanced support for use cases already identified for the IFC4 Reference View Clash detection and resolution (finding clashes between different discipline specific IFC models) Quantity take-off (determine the quantities of the various model elements with the IFC model) Construction sequencing (taking the IFC model and associating it to a construction schedule)

Common characteristics of the workflow using design transfer models are:

The source of the BIM information may be shared The basic parametric behavior, and thereby the intellectual engineering property, can be transfered The scope of parametric exchange is limited to dimension-driven standard case elements The ownership of the model, and responsibility for its correctness, can be transfered The original model that is published as IFC4 Design Transfer model reflects the as-is status The receiver of the IFC4 Design Transfer View does not need to have access to the full model content The receiver of the IFC4 Design Transfer View can analyze and extract the information of the model The receiver of the IFC4 Design Transfer View may modify the model If the receiver suggests or demands a change, it may be made to the model directly Round-trip, i.e. making changes and send the full updated model back to continue, is out of scope Use BCF-2 instead to communicate individual change requests and proposals back to the originator

The Level of Detail of the shape representation and the Level of Information for the property content of the actual reference models depends on the source model. The buildingSMART standard IDM (Information Delivery Manual) can be used to determine the minimum content for a particular workflow support. The IFC4 Design Transfer View allows rich content to be published. See next chapter Objective for more details.

Workflow support by the IFC4 Design Transfer View

The overall goal of the IFC4 Design Transfer View is to provide work flows where building information models may be edited by design software platforms. It is not intended to capture all design parameters, but rather a limited subset affecting major building elements, along with the design results for all components within a building.

To support the best way to exchange rich geometry preserving parameters, the resulting schema includes several additional geometry types, such as advanced B-rep (NURBS), faceted B-rep and surface models, Constructed solid geometry (CSG), and advanced sweeps, including tapering. presentation styles, such as colors and textures, can be added to these geometries.

Compatibility Converns for the IFC4 Design Transfer View

The IFC4 Design Transfer View is the successor of the IFC2x3 Coordination View. The Design transfer View is intended to be compatible with the IFC2x3 Coordination View for import. Exceptions to compatibility are made for the export to support new features and remove obsolete data structures.

General scope of the IFC4 Design Transfer View

The general scope defines the main functionalities of the IFC4 Design Transfer View as an overview. It includes a complete listing of the model elements and model element types that are included in the IFC4 Design Transfer View Model View Definition.

NOTE The Model elements are referred to as "Root Concepts" within the Model View Definition specification, being the individual root elements, that contain the attributes, geometric shapes, dynamic property sets and other semantic information that are combined and expressed as "Concepts". The common definition of a "Concept", that is applicable to many "Root Concepts" is called a "Concept Template". The detailed scope of the IFC4 Design Transfer View is determined by the concept templates that are included. A detailed description of each concept template is provided by Chapter 4 "Fundamental concepts and assumptions" listed in the MVD specification delivery.

Model elements included in the IFC4 Design Transfer View

Model elements All model elements, that are included in the IFC4 Reference View, are also included in the IFC4 Design Transfer View. The following additional model elements are added to enable basic parametric capabilities.

Standard-case entities are defined by material configuration at type definitions (either IfcMaterialLayerSet, IfcMaterialProfileSet, or IfcMaterialConstituentSet, which are applied to an axis path or footprint area. Material profiles define cross sections of materials that are swept along a curve. Material layers define thicknesses of materials that fill a bounded area.

Standard-case entities include the following:

Entity Material Representation IfcSlabStandardCase IfcMaterialLayerSetUsage 'Footprint' IfcPlateStandardCase IfcMaterialLayerSetUsage 'Footprint' IfcWallStandardCase IfcMaterialLayerSetUsage 'Axis' IfcColumnStandardCase IfcMaterialProfileSetUsage 'Axis' IfcBeamStandardCase IfcMaterialProfileSetUsage 'Axis' IfcMemberStandardCase IfcMaterialProfileSetUsage 'Axis' IfcDoorStandardCase IfcMaterialConstituentSet 'Profile' IfcWindowStandardCase IfcMaterialConstituentSet 'Profile' IfcOpeningStandardCase IfcMaterialConstituentSet 'Profile'

Elemented-case entities are defined by compositions of elements, where each composed element is defined by material configuration at type definitions. Elemented-case entities include the following:

Entity Components IfcSlabElementedCase IfcBeamStandardCase (joists) IfcPlateStandardCase (sheathing) IfcWallElementedCase IfcMemberStandardCase (studs, track) IfcPlateStandardCase (panels) IfcBuildingElementPart (insulation)

Model element types All model elements types, that are included in the IFC4 Reference View, are also included in the IFC4 Design Transfer View, no additional model element types are added.

IFC2x3 Coord.View Version 2.0

Cordination View Version 2.0

The Coordination View targets the coordination between the architectural, mechanical and structural engineering tasks during the design phase. The official designations for the Coordination View V2.0, applicable to IFC2x3 TC1, are:

Name: Coordination View Version 2.0 Abbreviation: CV V2.0

Quick links for developers:

IFC2x3 CV2.0 official certification program IFC2x3 CV2.0 implementer agreements

Purpose of Coordination View Version 2.0

The Coordination View has been the first view definition developed by buildingSMART International and is currently the most implemented view of the IFC schema.

The main purpose of the Coordination View is to allow sharing of building information models between the major disciplines of architecture, structural engineering, and building services (mechanical). It contains definitions of spatial structure, building, and building service elements that are needed for coordinating design information among these disciplines.

The shared building information model is supposed to be re-editable by the receiving application. It includes the definition for spatial structure, building, and building service elements with shape representations, including both, parametric shapes for a limited range of standard elements, and the ability to also include non parametric shape for all other elements. Property sets, material definitions and other alphanumeric information can be assigned to those elements.

The support of round-trip scenarios is excluded from the support of the coordination view.

Documents for the Coordination View Version 2.0

CV V2.0 File header : Coordination View Version 2.0 declaration in IFC file header section CV V2.0 Formal sub schema: Coordination View Version 2.0 formal IFC2x3 sub schema, includes: List of all IFC2x3 entities included in CV 2.0, IFC2x3 EXPRESS schema for CV 2.0, and IFC2x3 EXPRESS-G Diagram for CV 2.0) CV V2.0 Concepts : Coordination View Version 2.0 scope definition by model view concepts being supported, includes: List of concept templates (list of re-usable concepts) utilized by CV 2.0, List of concept roots (list of all supported elements, like wall, furniture, fastener, or distribution element) with applicable concepts, and List of rules applied to the supported elements (Attribute list with rules assigned to each attribute path definition) Property Set scope : Coordination View Version 2.0 property sets (Pset List) Questions & Answers

The Coordination View has been first developed (as a binding) implemented for the IFC2x release, later adopted for the IFC2x2 release and is available as the Coordination View (Version 1.0) for the IFC2x3(TC1) release. It has been used for IFC Certifications until 2009. It is currently replaced by the Coordination View Version 2.0. Main targets of the new Version 2.0 are:

to provide a full and syntactically complete and correct sub model of the IFC2x3 TC1 schema to be compatible with extension by so called "Add-on" views to be more strictly defined and suitable to automatic checking. to fix issues and scope creep that have been detected with the previous version 1.0

The Coordination View Version 2.0 is defined as a single Model View Definition, MVD. It should support several exchange requirements:

Exchange Requirement "Architecture" (Architectural Model for Coordination) for exporting the IFC2x3 file corresponding to the Coordination View Version 2.0 from an architectural software application Exchange Requirement "BuildingServices" (Building Services Model for Coordination) for exporting the IFC2x3 file corresponding to the Coordination View Version 2.0 from an MEP software application Exchange Requirement "Structural" (Structural Model for Coordination) for exporting the IFC2x3 file corresponding to the Coordination View Version 2.0 from a structural engineering software application

Root concepts for IFC2x3 Coordination View V2.0

The definition of the root concepts for the coordination view version 2.0 includes the selection of applicable attributes and relationships. It represents the "variable concepts" and the individual IFC2x3 bindings of the various concepts that need to be supported for export and import of CV V2.0 IFC files depending on the exchange requirements. The following definitions apply::

Root concept is an IFC entity that represents a spatial element, building element, building service element or structural element that is fully described by its attributes and relationships. It is named "variable concept" within the Model View Definition approach adopted by buildingSMART International. Each root concept has to satisfy a series of concepts (or units of functionality) that needs to be fulfilled for the purpose of the Coordination View Version 2.0. Each concept is verified during the certification process as an item within the check list assigned to each applicable test case.

The IFC2x3 Coordination View V2.0 detailed Model View Definition is represented as

Graphical representation of the IFC2x3 Coordination View V2.0 (upcoming) List of root concepts in IFC2x3 Coordination View V2.0 (below) List of Implementation Agreements applicable to the IFC2x3 Coordination View V2.0 (link)

Space boundary Addon View

The space boundary add-on view is an extension of the IFC2x3 Coordination View 2.0. It describes the additional IFC support required to fulfill the exchange requirements between the architectural and building service modeling software and the thermal analysis software. This includes

proper export of the architectural building information model with some level of preprocessing for thermal analysis main focus hereby is the correct definition and processing of space boundaries (also called thermal boundaries) space boundaries can be defined as 1st level space boundaries, or 2nd level space boundaries other requirements for spaces, zones, and thermal properties of building elements

Guidelines

In addition to the definition of proper Model View Definition 's MVD the following implementation guidelines are published.

Basic FM Handover View

FM Handover Aquarium

The buildingSMART Facility Management (FM) aquarium aims at improving the life-cycle building information interoperability using commercially available releases of Building Information Modeling (BIM) planning, design, construction, and commissioning software and the Computer Aided Facility Management (CAFM) and Computerized Maintenance Management System (CMMS) applications used in facilities management for the operation phase. The main goal of the project is to prove that the use of open standards is an enabler for the intended process integration.

The scope of work is defined as (see figure below):

Handover from planning and design applications to CAFM and CMMS applications Handover from construction and commissioning software to CAFM and CMMS applications

FM Handover use cases

The FM Aquarium work is based on the results of previous projects by buildingSMART or affiliated and supportive organizations:

The Construction-Operations Building information exchange (COBie) work led by the US Army Corp of Engineers The FM-10 buildingSMART IFC extension project led by buildingSMART German speaking chapter The ZukunftBAU IFC/FM research projects funded by the Federal Ministry of Transport, Building and Urbain Affairs. The following sections define the content (requirements, test cases, specific information details and an extensive questions and answers collection) of the FM Handover aquarium:

Exchange requirements, model view definitions, and software requirements for the Basic FM Handover Reference files and test cases to develop and test the Basic FM Handover Criteria for quality assessment and verification for the Basic FM Handover Specific additional explanations and exchange requirements for COBie2 Questions and Answers

FM Basic Handover

The Basic FM Handover View defines the general requirements for design applications to enable the handover of facility management information. These requirements have been consolidated in previous buildingSMART projects and are now formulated in the following requirement specs for data exchange.

The basic scope can be summarized as the space and equipment list (room book) for the spatial and technical systems of a facility.

Exchange Requirements & Model View Definition

The Exchange Requirements (ER) defines the common data needed between two processes. The processes for the "Basic FM Handover" have been defined as the planning and design process and the start of the operation process. The ER are given in detail for all objects and attributes needed for the handover, but still neutral to the actual format of the exchange.

The Model View Definition (MVD) translates the Exchange Requirements into a specification for a given exchange format, here the buildingSMART international standard IFC. The MVD is directly linked to the ER table, and also provided using the buildingSMART graphical representation.

(final !) Exchange Requirements with linked Model View Definition - tabular form (2009-10-07) (update) Exchange Requirements with linked Model View Definition - tabular form (2009-11-05) small improvements highlighted in yellow, no change to the ER itself changes relate to the mapping to COBie attributes and better explanation of IFC binding (final !) Model View Definition - graphical form (2009-10-07) (final !) Model View Definition - graphical form with implementation guidance (2009-10-07)

Software Requirements Software companies participating in the FM aquarium process are asked to provide the following support for the Basic FM Handover within their products:

for architectural BIM/CAD applications:

having already support for the IFC2x3 coordination view extending the support by the following additional items ability to assign a location to the project site (address, geographic location) ability to assign components (furniture, fixture and equipment) to spaces ability to assign spaces to zones ability to assign a classification to spaces and components ability to assign manufacturer base properties to components ability to assign doors and windows to spaces (directly or through space boundaries) ability to export base quantities (following the combined German/AECOO base quantity definitions) ability to export type information (styles, families, etc.) for the components see exchange requirements & model view definition for exact (per object & attribute) export requirement definition of the Basic FM Handover for architectural BIM applications

for MEP BIM/CAD applications:

having already support for the IFC2x3 coordination view extending the support by the following additional items ability to assign a location to the project site (address, geographic location) ability to assign MEP components to spaces ability to assign MEP components to technical systems ability to assign a classification to spaces and components ability to assign a classification to zones and technical systems ability to assign manufacturer base properties to component ability to export type information (styles, families, etc.) for the components see exchange requirements & model view definition for exact (per object & attribute)

for CAFM and CMMS applications:

utilizing the space list and component lists, including the hierarchies, the assigned properties, quantities and classification for creating an inventory for O&M processes import the project structure (site, building, stories) import the spaces (with classification, quantities and properties) import the FFE and MEP components (with classification, properties and quantities) import the FFE types and MEP component types (with classification and properties) assign the FFE and MEP components to spaces (only for import from MEP) import systems and assign MEP components to system use of geometric representations that may be assigned to spaces and components is possible, but not required see exchange requirements & model view definition for exact (per object & attribute) import requirement definition of the Basic FM Handover for CAFM and CMMS applications

FM Aquarium Reference Files

The FM HandOver Aquarium is set up to test the data handover between the design and construction CAD/BIM tools and the CAFM/CMMS applications. For testing the exchange and the correct implementation within the participating software systems a series of test models are prepared and made available (first to the participants, then also to all following the aquarium process).

The first test model is the aquarium reference file. The reference file is characterized as:

a reference for data to be handed over between a CAD/BIM design application and a CAFM/CMMS application. The COBIE2 xml spreadsheet format, and the BIM service tool to convert IFC into COBIE2 is seen as one receiving application within this scenario. a reference for each data exchange requirement as defined in the exchange requirement table and the model view definition for the FM HandOver. a reference for the correct export file structure according the the FM HandOver view definition The first reference file is a simple house with a spatial structure, rooms, zones, furniture, technical systems and technical components, including the needed quantities, manufacturer information and other essential properties. The reference file contains most of the requirements from the exchange requirements and model view definitions. It is provided as:

A reference IFC file (2009-10-07) A reference ifcXML file (2009-10-07) A COBIE import of the reference file (2009-10-07) The Exchange Requirement table with a column to show coverage of reference file (2009-10-05) The reference file has a graphical representation (see figure below - click for full size). However only the spatial structure with the included FFE and MEP elements are mandatory for the Basis FM HandOver view.

FM Handover Quality Criteria

The main goal of the FM Handover Aquarium project is to prove that the use of open standards is an enabler for the intended process integration. This proof requires two parts a Certification and a Challenge.

The Certification ensures compliance with the international standard, namely that portion of the Industry Foundation Classes (IFC) model needed to support Facility Management, this portion has been identified as the buildingSMART International “Basic FM Handover View”. The requirements for information exchanges needed for the FM Handover domain are documented in an internationally finalized Exchange Requirements (ER’s). The definition of that portion of the IFC model required to support those exchanges are documented in an internationally finalized FM Handover Model View Definition (MVD). A certification issued by the international buildingSMART indicates that those firms providing the FM MVD information in the IFC format meet the format and quality requirements of the FM MVD. The certification includes an export certification for delivery of the Basic FM Handover information and an import certification for consuming those in an CAFM and CMMS application. The Challenge ensures that the information content, either in the IFC model format or equivalent formats, may be created by typical end-users with today’s commercial products and instructions provided by software companies. One of the formats through which FM Handover information may be exchanged, that has begun to be used in the United States is the Construction-Operations Building information exchange (COBie) format. COBie is an XML format that may be directly viewed with commercially available spreadsheet software. As part of the FM Aquarium, COBie has been simplified and updated to ensure compliance with the international MVD. Those firms meeting the COBie2 Challenge will have demonstrated their ability to produce and/or consume the required COBie2 information as relevant to that firm’s position with the project life-cycle. Those supplying COBie2 information will be evaluated against automated COBie2 format and quality checks. Those consuming COBie2 information will be evaluated against a quality control/assurance review of that software’s use of COBie2 information. The following document describes in detail the criteria for quality assessment and verification. It is based on the exchange requirements and model view definitions as the guiding specifications to assessing the quality of the solutions.

buildingSMART FM Aquarium - criteria for quality assessment and verification (2009-09-13)

FM aquarium COBie2 description

The FM HandOver Aquarium includes the refinement of COBie as COBie2 (with the major goal of internationalize and consolidate COBie as the receiving handover format) as defined by the buildingSMART alliance North America, the US Chapter of buildingSMART. It also involves the development and distribution of COBie2 tools, including bimServices to transform the FM Handover data sets between IFC and COBie2 xml spreadsheet. Background information on the overall COBie effort may be found on the U.S. National Institute of Building Sciences, Whole Building Design Guide COBie page.

COBie2 Examples Example files to introduce the new COBie2 xml spreadsheet format:

COBie2 test case model “Railyard Maintenance Facility" (version 1.24 from 2009-11-16) COBie2 Blank Template (2009-12-04) spreadsheet for starting afresh More examples include the COBie2 import file of the FM Handover aquarium reference files.

Checking COBie2 files Rules are developed to verify that COBie2 xml spreadsheets have correct data sets (either by automatic transformation from IFC files, following the FM Handover view definition, or by entering the data manually). The rules used for checking compliance to COBie2 are available here. Users can use the spreadsheet (.xml) as a reference.

COBie2 rule sets (2009-08-18)

COBie2 transformation tools The ifc (STEP), ifcXML (XML) and COBie2 spreadsheet (XML) formats for the IFC Basic IFC HandOver View do capture the same information content and can be transformed forth and back across the different formats.

Different tools can be used to execute the transformations, including:

IFC toolboxes for the ifc (STEP) files, see overview General XML/XSLT engines for the ifcXML (XML) files, examples include Saxon (open source) or Altova (commercial) Dedicated tools, like the AEC3 bimServices (see below) AEC3 bimServices, developed for the COBie FM Handover project, includes the transforms tool and the configurations to map IFC data to COBie2 and map COBie2 to IFC. The bimServices accept for the IFC-to-COBie transformation both, .ifc and .ifcXML files, and generates also for the COBie-to-IFC transformation .ifc and .ifcXML files.

Therefore IFC Express, ifcXML, and COBie2 XML spreadsheet formats are interchangeable from the point of view of the COBie2 perspective. All express the same handover data with the same logic.

The AEC3 bimService tool was created by AEC3 at the request of the Engineer Research and Development Center ERDC of the US Army Corp of Engineers USACE who has authorized the release of bimServices and associated COBie2 transformations at no cost.

The AEC3 bimServices package can be downloaded from the AEC3 website. No warranty or support is offered with these tools, but comments to the AEC3 developer are welcomed.

For example to map COBie2 to IFC the command is (depending on your installation) "C:\program files\aec3\bimservices\transform1.exe" _fromCOBIE2.ifcxml.xsl MyCobieSpreadsheet.xml For example to map IFC to COBie2 the command is (depending on your installation) "C:\program files\aec3\bimservices\transform1.exe" _asCOBIE2.xml.xsl MyFacilityModel.ifc

A COBie2 training course. COBie is designed to help designers, builders, commissioning agents, facility managers, facility owners, and federal agency representatives understand how COBie2 can reduce the cost of doing business today. To achieve this goal, the rational for the COBie2 project and the contents of COBie2 deliverables are described in detail.

There are no prerequisites for this course. Those new to COBie2 should take the course in order. Once you have taken the course, or are familiar with COBie2, you can jump directly to the specific section of interest. This training does not describe or require specific software. While commercial software systems can and do support COBie2, the specific requirements

Introduction Information Delivery Specifications COBie2 Specification How to use COBie2 Organization of COBie2 spreadsheet Contact Worksheet Facility Worksheet Floor Worksheet Space Worksheet Zone Worksheet Type Worksheet Component Worksheet System Spare Resource Worksheet Job Worksheet Document Coordinate Specifications

FM Handover Aquarium Questions & Answers

General explanations and answers to frequently asked questions about the goals, requirements to participate, and other inquiries about the buildingSMART FM Handover aquarium project, including the technical questions about the IFC FM Handover View Definition and the mapping into the COBIE2 handover format.

General Q&A about the process, participation and goals Technical Q&A about the FM handover data format Technical Q&A about the FM Handover target COBIE2 format

General Q&A about the process, participation and goals

Q: Are there fees required from software developers to participate in the aquarium?

A: The participation in the aquarium process is free for software developers, they bear their own costs for involvement (time, internal testing, participation in the final event). The costs incurred by the aquarium process (facilitation, running the teleconferences, website maintenance, questions and answers, etc.) are covered by the problem owners (sponsoring organizations). If participants opt to go further with the certification process (in advance to the challenge) then the buildingSMART certification fee applies.

Q: Is the aquarium a practical exercise to see what works already?

A: Partially as it does not define the process, nor the buildingSMART IFC interoperability support from scratch. It does however include areas of improvement and adaptation to the particular needs for the FM Handover process. These adaptations are defined using a subset of the IFC structures that are already implemented and certified as IFC2x3 coordination view. A few additional requirments, specific for the FM handover process, are added in correspondance to that.

Q: What are the data formats to be used for the interoperability (design to CAFM/CMMS, and construction detailing to CAFM/CMMS) within this buildingSMART aquarium?

A: For the buildingSMART certification and the international requirements for demonstration (challenge) the applicable data formats are IFC and ifcXML. For the US market challenge for COBIE the export can be shown in addition using the excelXML format of COBIE.

Q: What level of expertise is required to participate? Do we need a knowledgeable application user to drive our software in the aquarium, or would we expect to have a software developer as well to deal with issues that arise?

A: If you are a solution provider (software company) the requested participation would typically include a product manager (for limited time) to discuss the necessary process support and a software engineer to add and verify the support to the IFC interoperability component of the software.

Q: The FM aquarium process seems to deal with the handover of architectural data (space lists, FFE lists) and MEP data (MEP components and systems linked to the spatial system), is a participant required to support both?

A: No, it depends on the software portfolio and the business area of the participant. It is expected to have different data flows from architectural BIM and MEP applications. Participants having solutions for both areas may opt to participate with architectural and/or MEP solutions.

Q: Is this exercise a precursor to proposing a certification of the work flow?

A: Yes one goal of the FM Handover aquarium is to prepare a buildingSMART IFC certification for the design and construction to operation and maintenance work flow. The certification is based on the IFC model view definition MVD being based on the coordination view and currently available as a final draft. One additional goal of the aquarium process it to finalize the MVD with input by the participants and get it finally adapted by buildingSMART International.

The certification involves FM Handover export from BIM applications, and FM Handover import into CAFM and CMMS applications. The actual certification process will be carried out under the supervision of buildingSMART international.

Q: What is the deadline for the demonstration (challenge) and the certification process?

A: The deadline for this year is the 08.-10.12.2009, the AEC/ST and buildingSMART alliance conference in Washington DC.The challenge will take plac during this time with all participating companies that are ready at this time. The certification will start few days earlier (the quality of the results will determine whether the certification award can be awarded already or whether further test rounds are required).

The next challenge is planed for the following year in December 2010.

Technical Q&A about the FM handover data format

Q: What is a Zone (IfcZone) and how does it differ from Space (IfcSpace)?

A: Zones are aggregations of spaces that can be used for a number of purposes, such as public/private circulation, departmental allocation, or distinct servicing. They are essentially aggregations of spaces for any reason other than the assignment of spaces to the spatial structure of a facility (building -> story -> space). Zones can span across floors, and need not be contiguous in space. Any space can be aggregated in zero, one, or several zones. For IFC definitions see IfcZone and IfcSpace.

Q: Can zones and systems include other sub-zones and sub-systems?

A: Yes, both zone and system can include other zones and systems, however the relationships have to be hierarchical. Therefore systems and zones can be defined recursively.

Q: Coverings, e.g. a flooring, can be defined either as an attribute at the space, or as an individual object contained in the space. What are the rules for using an attribute or an object approach.

A: Yes, both representations are possible. The prefered representation is using the object approach, i.e. IfcCovering assigned to a space through IfcRelContainedInSpatialStructure. The IfcCovering can then hold own properties and quantities (GrossArea, NetArea). There are some cases where using IfcCovering object is mandatory: (1) there are more then one flooring (ceiling, cladding) in a space, (2) the thickness, material layer information, etc are essential, (3) an own shape representation is important (as for suspended ceilings).In these cases an IfcCovering instance is to be used that is assigned to an IfcSpace using the IfcRelContainedInSpatialStructure relationship.

The use of attributes (FloorCovering, WallCovering, CeilingCovering within Pset_SpaceCommon) at IfcSpace is allowed, if there is only one flooring, cladding, and/or ceiling and the quantities can be obtained from the base quantities of IfcSpace (NetFloorArea, NetCeilingArea, NetWallArea). In those cases (particularly in the design phase) no instance of IfcCovering is used.

Q: How are doors and windows assigned to spaces. Is an internal door and window already assigned to a single space?

A: The FM Handover View recognizes the different views of an construction oriented BIM view, where a door or window is seen as inserted into a wall, and the FM view, where a door or window is managed as an furniture from a single space. The selection of which of the two spaces bounding a door or window becomes the single space assigned in FM depends on local or project specific rules.

The FM Handover View therefore allows both methods: (1) the door or window is already assigned to a single space in the BIM application, then it is exchanged with the single door/window to space assignment (IfcRelContainedInSpatialStructure) and (2) the door or window is bound by two spaces (two instances of IfcRelSpaceBoundary).

Q: How are internal and external doors and windows distinguished?

A: In addition to (and in absence of) a distinction by the associated classification system, like DIN276 334 (for external doors and windows) and DIN276 344 (for internal doors and windows), a classification independent property attached to IfcDoor and IfcWindow common property sets, IsExternal, has to be used. An internal door or window is identified by IsExternal=FALSE, an external door or window by IsExternal=TRUE.

Q: What tools are available to support the mapping between IFC and COBIE2?

A: The IFC<->COBIE mapping command line utilities are now available and will be published soon. The COBIE2 checker command line utilities will be made available shortly.

Technical Q&A about the FM Handover target COBIE2 format

Q: Is the COBIE2 xml format now stable (as of August 2009)?

A: The COBIE2 xml spreadsheet format is now fixed. The more condensed format of COBIE2 is intended to make it easier to use COBIE with clients and users. There have been few changes over the recent several weeks. The last changes were to make System and Zone rows consistent with a unique name and a comma delimited list on their contents, and to remove the FacilityName columns from Systems, Zones and Floors, as the assumption is now that there will be only one Facility.

Q: Can the COBIE2 PickLists be changed?

A: COBIE2 is intended to be standardised but configurable for regional and project practice and so the only changeable columns in the PickLists are the national/regional classifications (shown in green). Other lists should NOT be changed because there are the obvious risks that applications reading the sheet will not find expected terms or that applications writing out spreadsheets will not use any novel terms. For example, the values for 'FloorType' is always one of the three values 'Site', 'Floor', or 'Roof' and coordinates are taken from the 5 values that describe a point, line, or box.

Q. What is required to be unique within COBIE2?

A: There is an unique implied key for rows in each table. In all cases making the Name (or Email) unique is sufficient. Key names should match regardless of case. This applies for:

“Contact”, Email “Facility”, Name “Floor”, Name, “Space”, Name, “Zone”, Name, “System”, Name, “Type”, Name “Component”, Name “Spare”, Name “Resource”, Name “Job”, Name “Document”, Name “Attribute”, Name, SheetName, RowName “Coordinate”, Name “Connection”, Name “Issue”, Name

In general, Names should avoid unusual punctuation. Numeric keys used by other applications can be stored in ExternalSystemId if no other IFC GlobalId is avilable. Using text based keys makes cut-and-paste operations valid. For example each worksheet can be prepared from reports produced by disparate applications. Also character names have been preferred as a miss-typed character is more likely to make a key invalid, whereas a mistyped number is more likely to be a valid but wrong key.

Q: How are Spaces, Components and Resources assigned to Zones, Systems and Jobs?

A: In each case a single cell contains a comma-delimited list of the names.

Q. How do the comma-delimited list of the names work?

A: Name lists are comma separated. The final comma is optional. These occur in the following columns:

ComponentNames for a System, SpaceNames for a Zone, ResouceNames for a Job Space(s) of shared Components (such as doors).

It follows that Space and Component and Resources names should not contain commas. Using this convention, a Component may span between two (or more) spaces. This does NOT allow Components to be duplicated in two (or more) Spaces. Additionally, in the Description of a Job, one may optionally created a comma delimited list of tasks.

Q: Is there documentation of the COBIE2 fields and other rules?

A: The rule set is available. Further documentation will follow. In summary text fields may be up to 255 characters. Dates shall be in ISO format.

Q: How is the Attribute sheet used?

A: The attribute sheet can theoretically refer to any other sheet, but it is most commonly used to record the attributes of the Components, Types, Systems, Zones and Spaces. Only one value should be recorded for a given Attribute Name, SheetName and RowName. Values held for a Type and System may be overridden by values held against an individual Component. Values held for a Zone may be overridden by values held against an individual Space.

Q: How is the Register of submittals held?

A: The Register is held within the Document catalogue. An expected document can be recorded, before the actual delivered file name is known, so a BIM application could create a “Product Data” Document record for each Type.

Q: Can spaces contain other spaces ?

A: No. Spaces cannot contain other spaces. Zones should be used instead as super elements that may contain multiple spaces.

Q: Must COBie-compliant applications handle components assigned to more than one space ?

A: Listing multiple spaces for a component signifies spanning, not duplication. Where an application has a need to assign it to one single space, then it may take the first space in the list.

Structural Analysis

The buildingSMART model view definition "Structural Design to Structural Analysis" covers the exchange requirements to send the structural analysis model, created in a structural design application by a structural engineer to one or many structural analysis applications. It supports, among other purposes, that the same structural analysis model can be analyzed by many analysis applications (using different analysis methods or codes, or being specialized to either steel, concrete or timber structures).

The structural analysis model view itself is independent of the main construction type (i.e. whether it is a steel, concrete, or timber construction). It comprises the structural analysis model with loads, load groups and combinations, structural analysis curve and surface members, connections and boundary conditions and material and profile information.

Structural Analysis View Overview

The figure shows some of the information items that are in scope of the structural analysis model view. The following structural analysis model view documents are available:

the Structural Analysis MVD overview the Structural Analysis MVD generic definitions the Structural Analysis MVD IFC2x3 bindings The document are also available for online access at the IFC solution factory, an external database environment supporting MVD development.

Credits:

the main scope, concepts and implementation agreements had been developed by the buildingSMART International Structural Engineering Domain group in 2005-07 the work has been formalized and completed according to the MVD methodology by Tampere University of Technology in 2007-08 Specifications

Coordination View Version 1.0

Coordination View V1 Summary

The Coordination View (Version 1.0) has been used from 2005 (publication of IFC2x3) until 2009 for implementation and certification of IFC2x3 coordination view IFC support.

Official Name: Coordination View (Version 1.0) Keyword in Header: CoordinationView

These documents show the definition of the IFC2x3 extended coordination view prior to the improvement process leading to the IFC2x3 improved coordination view certification of 2010. They are provided for informational purposes.

download the Excel representation of the IFC2x3 Extended Coordination View link to the online documentation of the Extended Coordination View concept diagrams