Buildings Civil Infrastructure

COBie for All
Required Information for Facility Ownership
Buildings & Civil/Infrastructure

Understanding How COBie Works in the UK Infrastructure Market

V1.3
11th October 2013
COBie for All : Building and Civil / Infrastructure Facilities
Version Control
Date Version Lead Author

12-07-2012 V0.1 First report Paul Scarponcini
24-07-2012 V0.2 Reviewed against COBie 2.4 Nick Nisbet
29-07-2012 V0.3 Agreed content Paul Scarponcini
Nick Nisbet
01-08-2012 V0.4 Formatted for presentation to UK BIM Nick Nisbet
Task Group and BIM4Infragroup
13-09-2012 V1.1 UC1 results included Nick Nisbet
10-10-2012 V1.2 UC2 results (provisional) included Nick Nisbet
15-10-2013 V1.3 Document Review & Introduction Mark Bew
section
Status: DRAFT Public Release for Comment

Version: 1.3
Confidentiality: Unclassified
Copyright: © 2013 BIM Task Group
Abstract: An assessment is made of the requirements to use the COBie standard to
address information exchanges for Civil / Infrastructure projects.
Important note:
This draft manual and downloads available from the ‘Labs’ area of the BIM Task Group website
are for educational use and comment only. They are not yet available for production use and
should not be used for contract use.
This document is technical in nature and is not aimed at Lay Users but Design and Data
Professionals.
Please comment at www.bimtaskgroup.org/comments.
1 v1.3 October 2013

Contents
Contents 2
Authors & Acknowledgements 4
Introduction 5
1 Summary 6
2 Introduction 9
2.1 Problem Overview 9
2.2 About This Report 10
2.3 Acronyms 11
3 COBie Overview 13
Problem Decomposition 15
3.1 Problem 1: COBie Spread Sheet Format 16
3.1.1 Problem Identification 16
3.1.2 Discussion 16
3.1.3 Recommendation 17
3.2 Problem 2: COBie Schema 18
3.2.2 Discussion 18
3.3 Problem 3: COBie Versions 22
3.4 Problem 4: COMPONENT Geospatial Location 24
3.4.2 Discussion 24
3.5 Problem 5: COMPONENT Linear Location 27
3.5.2 Discussion 27
3.6 Problem 6: Continuous Objects 31
3.6.2 Discussion 31
3.7 Problem 7: Variable Asset Values 32
3.7.2 Discussion 32
3.8 Problem 8: IFCs 34
3.8.2 Discussion 34
3.9 Problem 9: Classifications 35
3.9.2 Discussion 35
3.10 Problem 10: Schedules 36
3.10.2 Discussion 36
3.11 Problem 11: Stakeholder Requirements 37
3.11.1 Crossrail 37
3.11.2 Tube Lines 37
3.11.3 Highways Agency 38
3.12 Problem 12: Software Products 39
3.12.2 Discussion 39
4 Use Cases 40
2 v1.3 October 2013

4.1 Introduction 40
4.2 Use Case – Problem Mappings 41
4.3 Use Case Descriptions 42
4.3.1 UC 1: As-Is COBie 42
4.3.2 UC 2: Geospatial Location 44
4.3.3 UC 3: Linear Location 47
4.3.4 UC 4: Linear Identity and Attribution 47
4.3.5 UC 5: Asset-oriented COBie 48
5 Conclusions: C/I information exchange 50
5.1 Problem Identification 50
5.2 Discussion 50
5.3 Recommendation 50
6 References 51
7 Appendix A – COBieLite Extract 54
8 Appendix B – Linear Referencing 57
3 v1.3 October 2013

Authors & Acknowledgements

The process of developing this work has been undertaken collaboratively between the UK BIM
Task Group, Bentley Systems and AEC3 Ltd. There have been a significant number of
individuals and organisations involved as many as possible are mentioned below.
However the principal authors of this work were
Paul Scarponcini
Bentley Systems, Inc.
paul.scarponcini@bentley.com
Nicholas Nisbet
BIM Task Group of UK Government Department, Business Innovation
and Skills
AEC3 Ltd
nick.nisbet@aec3.com
Other Participants
Julian Schwarzenbach Crossrail

Jon Kirby HS2
Ross Dentten Crossrail
Phil Jackson BIM Task Group (HA)
Mark Bew BIM Task Group
Iain Miskimmin COMIT
David Philp BIM Task Group
Malcolm Taylor Crossrail
John Woollett Tube Lines
Mark Houghton Crossrail
Neill Pawsey Crossrail
Ian Childs Tube Lines
Nasir Khawaja Tube Lines
James Folley Tube Lines
Anne Kemp Atkins (EA)
4 v1.3 October 2013

Introduction
When we designed the concept of Level 2 BIM as a key stepping stone on the journey to the
interoperable digital economy of Level 3 and beyond, we identified the need for a straight
forward data structure that could be simple enough to be understood, but comprehensive
enough to be useful. Our goals were to not only allow the effective transfer of information
between the supply chain and client, but also to provide training and awareness of the principles
of shared data to the 1.9 million people employed in our industry.
As the BIM program has developed and gathered pace to its 2016 target of all public sector
projects being delivered using Level 2 BIM, the need to integrate building and infrastructure has
become more and more obvious.
The age old divide between our buildings and civils businesses stretches from culture to
language, but as the UK leads the way to the digital economy, construction as a whole sector
has to lead the way to a new collaboration between disciplines so we can continue to deliver
ambitious integrated hybrid programmes such as HS2, Crossrail and Thames Tideway. Nowhere
is this need to share greater than in the creation, use and storage of data.
“COBie for all” is a project that has taken a close look at the technical issues surrounding the
structural storage of data for both buildings and infrastructure. The work already done by the
BIM Task Group has delivered a UK specific COBie (COBie-UK-2012) (based and compliant
with COBie 2.4). The work of the “COBie for all” team is resourced in a joint team of BIM Task
Group, Bentley Systems, HA, HS2 and Crossrail who posed the question;
‘’Will COBie Work for Infrastructure?’’
The work initially identified 15 ‘’issues’’ all of which are described in this document. The solutions
and explanations derived satisfied the team sufficiently to say ‘’we think it will’’. So to test these
findings, five “Use Cases” or scenarios have been developed to test our work.
The purpose of this document is to share the findings to date with the industry and seek views
and comments. On behalf of the BIM Task Group, I would like to thank you or taking part in this
exercise and thank the team that have been working hard on this project for the last six months.
Mark Bew
Chairman BIM Task Group

October 2013
5 v1.3 October 2013

1 Summary
The UK government has mandated 3D BIM by 2016 on new government construction projects
including Civil/Infrastructure (C/I). The expected deliverables comprise 3D models, 2D
documents, and COBie UK 2012 data.
Originally created for buildings, the Construction-Operations Building information exchange
(COBie) does not address C/I projects. This report outlines how COBie can be used to
exchange information about C/I projects and how COBie could to be extended to further support
such projects.
Interviews were held with the UK Highways Agency, Crossrail Limited, and Tube Lines to
determine their asset management requirements that would dictate the COBie C/I content.
Additional documentation supplied by the interviewees as well as extensive background
information was used to obtain an understanding of the problem.
After a brief introduction to COBie, the problem is broken down into a dozen smaller, more
manageable problems. Each is identified and explained along with a discussion about possible
solutions. A simplified, expedient recommendation is made for turning each problem into an
opportunity for short term enhancement to COBie, whilst a longer term approach can be
identified and pursued.
1. COBie Spread Sheet Format – the COBie spreadsheet format spans across upto 20 sheets
and so may need to be complemented with an XML machine readable schema and/or a
concise human readable summary presentation.
2. COBie Schema – the COBie schema may need development to support asset requirements
tracking and their fulfilment.
3. COBie Versions –clarity is needed as to whether COBie2.26 or COBie 2.4 is the preferred
version
4. COMPONENT Geospatial Location –investigates support for locating assets with geospatial
coordinates or with geospatial features by extending the use of the coordinates spread
sheet and by generalizing the current location specification (building-floor-space hierarchy)
common to buildings but not applicable to most C/I projects;
5. COMPONENT Linear Location – proposes support for linearly locating project components
along the linear assets (roads, rail lines) common to most C/I projects;
6. Continuous Objects –proposes a solution for segmenting continuous assets so they can be
tagged and treated similarly to the discrete assets common to buildings;
7. Variable Asset Values – adds the ability to allow attributes of linear assets to vary in value
along the length of the linear asset without necessitating further segmentation;
8. Relationship to IFCs – COBie is based on Industry Foundation Classes which are currently
focussed on buildings with limited support for C/I with long term efforts to develop C/I IFCs
have begun;
9. Use of Classifications – COBie mandates the use of standardized classification schemes for
categorizing facilities, spaces, types, systems and organizational roles; these may need
extension or replacement with C/I classifications;
10. Schedules – COBie addresses manageable equipment, products, and spaces that appear
in schedules (on design drawings or elsewhere). C/I assets tend to be implicit from the
linework;
11. Other Stakeholder Requirements – interviewed stakeholder concerns and emerging
solutions are discussed;
12. Supporting Software Products – civil has lagged behind building and plant in implementing
BIM and 3D modeling; C/I software products may be able to automatically generate or
consume COBie compliant files with some configuration for mapping the data ahead of time
6 v1.3 October 2013

Five Use Cases are proposed that will explore these problems and the recommended solutions.
The use cases are based on actual stakeholder scenarios and will use their sample data.
An initial report [PXS-3] was distributed with limited circulation. Subsequent meetings with the
interviewees provided further clarification of their requirements and feedback on the proposed
solutions. Meetings with HM Government provided additional insight into their 2016 mandate.
The UK mandate covers all capital improvement projects, including C/I.
COBie has been adopted as the medium for information exchange to the Client from tier 1
partners such as lead engineers and constructors for all built assets. The COBie deliverable may
be expected at several stages during the project, culminating at handover, or after an extended
transfer process. COBie also allows other tiers to supply information in a consistent way. Once
with the client, the information is intended for use in portfolio, asset and facility management
systems. A separate COBie for C/I would be confusing and cause problems for projects like
Crossrail that contains buildings and C/I, and for the supply chain in general.
The challenge is to find a way to support C/I using the existing COBie entity relationship
structure shown below. This may be made more amenable if using more generic names for
some of the “boxes”. It would accommodate a single “COBie for All” solution, thereby supporting
projects like Crossrail that contain buildings and C/I.
Figure A Generic COBie Data Structure (Entity - Relationship Diagram)
7 v1.3 October 2013

Figure 1: The COBie data structure (buildings)
It has been seen from the discussions that the seven types of manageable aspects (grey) are
encountered throughout the built environment, but the naming of these seven aspects may
cause difficulties from specific professions (such as cost consultancy) or sectors such as C/I. In
order to explore the important issues and help understanding, we propose exploring some
synonyms. If these synonyms prove acceptable, then the support of some synonyms could be
suggested to the COBie implementers.
Figure 2: Possible COBie synonyms for C/I
8 v1.3 October 2013

2 Introduction
2.1 Problem Overview
“The [UK] Government Construction Strategy (GCS) requires that: Government will require fully
collaborative 3D BIM (with all project and asset information, documentation and data being
electronic) as a minimum by 2016. This refers to all centrally procured Government projects as
outlined in the GCS including new build and retained estate, vertical and linear.” [HMG-3]. The
UK mandate covers all capital improvement projects, including C/I.
The HM Government BIM Task Group identifies three key deliverables: the individual domain 3D
models in their native file formats, the 2D reviewable design deliverables cut from the models,
and COBie UK 2012 data.
The Construction-Operations Building information exchange (COBie) was designed and named1
to focus on buildings. It delivers information about “the scheduled equipment, products, and
spaces that appear on design drawings.” [NIBS-6]. It uses a buildings-oriented spatial structure
hierarchy of facility / floor / space to establish placement of components. The content of the
information exchange is prescribed by the Facility Management Handover [NIBS-4] Model View
Definition (MVD) in accordance with ISO 16739 [ISO-1]. This ISO standard specifies Industry
Foundation Classes (IFCs) for building construction information [NIBS-2]. COBie advocates the
use of standard classification systems (OmniClass is mandated in the US in [NIBS-4] but is
substitutable according to other documents such as [NIBS-5]) for categorizing facilities, spaces,
types, systems and organizational roles [NIBS-5].
Other than perhaps rail and subway stations, Civil/Infrastructure2 (C/I) projects are not about
buildings. Most of what will become managed assets do not appear in schedules on design
drawings. Objects tend to be continuous like roads, rather than discrete like windows and doors.
Attributes of these continuous objects often change in value along the object. Location of
objects typically is via linear referencing or geospatial coordinates or feature geometries.
There are no IFCs in ISO 16739 specifically for C/I, such as for road and rail, except generic
Geographic and Civil elements, introduced at IFC4 (2013). The FM Handover documents the
relationship between COBie and IFC and so notes that “project structure and component
breakdown structures outside of building engineering...are outside of the scope of this MVD.”
OmniClass in the US and Uniclass in the UK contain limited classes for C/I categorization,
though work is underway to include C/I classes in Uniclass2. So the question to be addressed is
“how can COBie be used to exchange information about C/I projects?”
1 unless we accept “Building” as a verb rather than a noun

2 Civil/Infrastructure is chosen to expand the common notion of “COBie for Civil” to include all infrastructure projects,
even if they are not Civil (such as electrical power networks)
9 v1.3 October 2013
2.2 About This Report

This report attempts to answer the problem stated above. Because of the current focus of
COBie on buildings and the fact that C/I projects lag behind buildings and plant facilities in the
application of BIM, this most certainly needs to be a long term objective. The focus of this
report is on short term solutions that would comprise the initial steps in achieving the longer term
goal.
Use cases are proposed that will demonstrate the proposed solutions.
The content of this report has been derived from information obtained from the following
sources:
1. Background information from buildingSMART, HM Government, The Institute of Asset
Management, the National Institute of Building Sciences, and the U.S. Army Corps of
Engineers, obtained from the internet and included in the References section above,
2. Formal interviews (London, March 25-28 and June 19-26, 2013) and follow up
discussions and emails with, and additional documentation collected from the following
individuals, to which appreciation is hereby acknowledged:
a. Iain Miskimmin: COMIT
b. Neill Pawsey, Ross Dentten, Mark Houghton: Crossrail Limited,
c. Phil Jackson, consultant to UK Highways Agency and Bentley Systems, Inc.,
d. Julian Schwarzenbach, Data and Process Advantage (consultant to Crossrail
Limited),
e. Ian Childs, Nasir Khawaja, John Woollett, Alex Berry, James Foley: Tube Lines,
f. Mark Bew: Engineering Construction Strategies Ltd,
g. Jon Kerbey: hs2, and
h. Anne Kemp: Atkins
3. Standards from the International Organization for Standardization (ISO).
a. ISO 16759:2012 IFC
b. ISO 15926 Process plant
c. ISO 10303 Express and step standard
The report was initially prepared by Paul Scarponcini and then developed with Nick Nisbet. It is
published as a working paper for industry discussion, and for implementers involved with the
use-case demonstrations and involved with Government departments.
10 v1.3 October 2013

2.3 Acronyms
AD4 (CRL) Asset Data Dictionary Definition Document
ADMM (HA) Asset Data Management Manual
AIMS (CRL) Asset Information Management System
AM Asset Management
AMO (HA) Asset Management Office
BIM Building Information Modeling
bSa buildingSMART alliance
bSI buildingSMART International
C/I Civil / Infrastructure
CERL (USACE) Construction Engineering Research Laboratory
COBie Construction-Operations Building information exchange
CRL Crossrail Limited
CRS Coordinate Reference System
DBMS Data Base Management System
DfT (UK) Department for Transport
ELR Engineering Line of Reference
ERDC Engineering Research and Development Center
GIS Geographic Information System
FM Facilities Management
GCS (UK) Government Construction Strategy
HA (UK) Highways Agency
HMG Her Majesty's Government
IAM The Institute of Asset Management
ie information exchange
IFC Industry Foundation Class
ifcXML, ifc4XML Alternate XML representations for IFC2X3 and IFC4
IM Information Modeling
IS International Standard
ISO International Organization for Standardization
LCS (LU) Location Coding System
LRM Linear Referencing Method
LRS Linear Referencing System
LU London Underground
MMHW (HA) Method of Measurement for Highway Works
MVD Model View Definition
NBIMS (US) National Building Information Modeling Standard
NIBS (US) National Institute of Building Sciences
NIEM National Information Exchange Model
SDO Standards Developing Organization
SPFF (IFC) STEP Physical File Format
STEP Standard for the Exchange of Product model data

TL Tube Lines
UC Use Case
UML Unified Modeling Language
USACE United States Army Corps of Engineers
XML eXtensible Markup Language
XSLT eXtensible Stylesheet Language Transformations
XSP Cross Section Positions

3 COBie Overview
COBie is “an information exchange specification for the life-cycle capture and delivery of
information needed by facility managers” [NIBS-1]. COBie provides a format for the publication
of a subset of a building model referred to as a "model view." The definition of this model view
(Model View Definition - MVD) is contained in the Facilities Management Handover [NIBS-4].
COBie information can be contained in any of three formats: the IFC STEP Physical File Format
(IFC SPFF), ifcXML, or SpreadsheetML. The latter is used by Microsoft Excel™ and most other
spreadsheet tools including OpenOffice. Long term, the expectation is that COBie type data
would be held in a Data Base Management System (DBMS) from which a spread sheet or other
view (report) could be extracted. But as a first step, it was felt that, for people not familiar with
the concept of BIM data, spread sheets provide a simple introduction.
Though the expectation is that the spread sheets would be written and read by software, the
reason this format was chosen was that it is the easiest to read by humans of the three. But this
is relative – the COBie spread sheets are certainly not easily read, especially by novices.
A COBie file (workbook) contains information about a single facility. The COBie Responsibility
Matrix [NIBS-5] lays out the spread sheet schema. The schema is spread out across 20 work
sheets in the workbook. For newcomers to COBie, it may be easier to look first at one of the
three filled out examples [NIBS-8]. The spread sheets include3:
INSTRUCTION – header information and instructions
CONTACT – information about people who create COBie information or act as a SPARE
supplier or a TYPE manufacturer, parts warranty guarantor, or labor warranty guarantor
(IfcPersonAndOrganization)
FACILITY – project, site, and building (IfcProject, IfcSite, IfcBuilding) - a distinct operational
unit, along with the project and site details.
FLOOR – vertical levels and exterior areas (IfcBuildingStorey) - a primary spatial subdivision
SPACE – spaces on a floor (IfcSpace) - a location for activity such as use, inspection or
maintenance.
ZONE – sets of spaces sharing a specific attribute (IfcSpatialZone)
TYPE – types of equipment, products, and materials (IfcTypeObject)
COMPONENT – individually named or schedule items (IfcProduct)
SYSTEM – sets of components providing a service (IfcSystem)
ASSEMBLY – constituents for TYPES, COMPONENTS (IfcRelAggregates)
CONNECTION – logical connections between COMPONENTS (IfcRelConnectsElements)
SPARE – onsite and replacement parts (IfcConstructionProductResource)
RESOURCE – required materials, tools, and training (IfcConstructionEquipmentResource)
JOB – PM, safety, and other operational plans (IfcTask)
IMPACT – economic, environmental and social Impacts at various stages in the life cycle
(IfcProperty)
DOCUMENT – all applicable document references (IfcDocumentInformation)
ATTRIBUTE – properties of referenced item (IfcProperty)
COORDINATE – spatial locations in box, line, or point format for FLOOR, SPACE or COMPONENT
(IfcCartesianPoint)
ISSUE – other issues remaining at handover (IfcApproval)
PICKLISTS – fixed enumerations and customizable code lists (IfcClassificationReference)
3 Package names appear in upper case; spread sheet / COBie concept names appear in UPPERCAMELCASE
SMALLCAPS; spread sheet column names appear in LOWERCAMELCASE SMALLCAPS.
Some of the literature [e.g., NIBS-3] presents these worksheets into DESIGN (FACILITY, FLOOR,
SPACE, ZONE, TYPE, COMPONENT, SYSTEM), BUILD (extending TYPE, COMPONENT and SYSTEM
and adding SPARE, RESOURCE, JOB), and COMMON (CONTACT, DOCUMENT, ISSUE, COORDINATE,
ATTRIBUTE, CONNECTION, IMPACT). These are deliberately overlapping boundaries since some
COMPONENT data is not entered until the BUILD life-cycle phase. Data is collected into the
spread sheets at various steps along the building life-cycle process culminating in the
Construction-Operation handover. The essential spread sheets are those contained in DESIGN
and BUILD with COMMON spread sheets containing supplementary information.
Within each spread sheet, the columns are pre-defined. They are color-coded to signify whether
the column content is required, a reference to another sheet or pick list, an external reference, if
specified as required, or secondary information when preparing product data. “Regional, owner,
or product specific data may be added as new columns to the right of standard template
columns” according to the example spread sheets but information in any such supplementary
columns is not checked by the standard quality assurance programs.
The Responsibility Matrix [NIBS-5] workbook contains a Spreadsheet Schema spread sheet with
the following information for each COBie spreadsheet column: sheet, column letter, column
name, unique key (primary or compound), foreign key, requirement on value (required, system,
or as-specified), allowed values (type and maximum length), constraints/notes, IFC object,
description, IFC 2.4 URL, and IFC to COBie Notes (issue, object iterations, alternative
processing). Though extremely helpful in understanding the COBie schema, it should be noted
that the Responsibility Matrix is informative only (not normative).
Optionalities and multiplicities for COBie spread sheet rows are not always obvious nor easily
ascertainable from the documentation. For example, the FACILITY spread sheet can only contain
a single row – multiple facilities must each appear in its own workbook. A FLOOR can contain
multiple SPACES but each SPACE can only exist on a single FLOOR.
A UML model of the COBie spread sheet schema is being developed [PXS-1] to capture these
relationships in a single document. As a Physical Model, it depicts the COBie concepts as they
are implemented in the spread sheets. Packaging is introduced for clarity, though again, the
boundaries are fuzzy:
class Overview Packages
Design Build
Design:: Build::Job
Facility
0..*
1..* 1..* +resourceNames

0..*
Design::Floor Design::Type #typeName Build::

Resource
+typeName
+typeName 1 1
1 +floor
1..*
Design:: 1 Design:: Build::
Space Component Spare
+space
#spaceNames 1..* #componentNames 1..*
0..* 0..*
Design::Zone Design::
System
(from COBie2.4) (from COBie2.4)

Common
Common::Contact Common::Coordinate
Common::Document Common::Attribute
Common::Impact Common::Issue Common::Connection
(from COBie2.4)

Problem Decomposition
The easiest way to solve a complex problem (like the one in Clause 2 above) is to decompose it
into smaller, more easily solvable problems. Once these are solved, one can check to see if the
original problem has been solved. The Problem Statement is therefore decomposed into a set
of smaller problems. Each problem is identified and explained. A discussion about possible
solutions follows. Finally, a recommendation is made. The recommendation is based on a
simple, short term expedient, typically flagged as short term by the keyword “initially”. Longer
term, more complex solution direction may also be included.

3.1 Problem 1: COBie Spread Sheet Format

3.1.1 Problem Identification
COBie information can be contained in any of three formats, the IFC STEP Physical File Format
(IFC SPFF), ifcXML, or SpreadsheetML (open XML schema used by Microsoft Office Excel 2003
and other spreadsheet applications such as OpenOffice.). When people think of COBie, it is
usually about the spread sheet version. Compared to IFCs, the COBie spreadsheet is easier to
grasp and is therefore often portrayed as a good first step in capturing asset information. It is at
least potentially human readable, checkable and editable, though most production is achieved
through software mappings and tools.
Because Excel spread sheets are most often used to show COBie data, it is easy to confuse this
“view” with the actual internal schema as defined by the FM Handover.
3.1.2 Discussion
With COBie, each facility requires up to 20 spread sheets combined into a single workbook file.
Users must realize that the first sheet you see when you open the file is one of many, each
accessible by a tab along the bottom of the screen.
Many of the spread sheets are too wide and long to be readable on screen or in print, unless
columns and rows are filtered or hidden. Related information may be spread out across multiple
spread sheets. To find all of the information relevant to a single COMPONENT, for example, it
may be necessary to visit upto10 other sheets: CONTACT, SPACE, TYPE, SYSTEM, ASSEMBLY,
CONNECTION, , IMPACT, DOCUMENT, ATTRIBUTE, and ISSUE.
If an attribute of an entity in COBie is not pre-defined as a column on any of the spread sheets,
the attribute name and value can be added as a row in the ATTRIBUTE spread sheet along with
the entity (spread sheet row) the attribute is attached. This means that attributes from any of the
rows in all of the other spread sheets appear in this single ATTRIBUTE spread sheet.
There is the potential for redundant or overriding information. Consider a property of a TYPE
(e.g., COLOR) held in a column of the TYPE spread sheet. An instance of TYPE (row in that table)
might have a COLOR of “blue”. Perhaps at construction time, only “red” ones are available. It is
possible to override the COLOR value by creating a COLOR ATTRIBUTE for the TYPE in the
ATTRIBUTE spread sheet and giving it a value of “red”. Then the contractor purchases instances
of this TYPE (called COMPONENTS) for installation. To record these instances, rows in the
COMPONENT spread sheet are created. There is no COLOR column for these rows since the
COMPONENT refers back to the TYPE spread sheet for COLOR. However, if you look there, you
find “blue”. You may also look in the ATTRIBUTE spread sheet for the override.Suppose one of
the purchased items is actually “green”. Then a COLOR ATTRIBUTE needs to be added to the
ATTRIBUTE spread sheet for just that one COMPONENT. Unless you find the TYPE, COMPONENT,
and ATTRIBUTE rows, you have no idea what the color of each instance is.
Having information structured across different sheets may make it hard to visualize the overall
content, especially if the current practice compounds component and type, or system and
system classification. Different kinds of data may need to be entered in multiple places.
Therefore, if human data entry and review is to be supported, then a more intuitive user-friendly
front end needs to be developed. All of the information about an asset, including the lists of
supplementary information could be presented to the user as if it were contained on a single
spread sheet. This is not the case with the proposed Crossrail AD4’s and the Tube Lines TLF-
447’s.

Clearly, where possible COBie content should be generated by the contractor’s software and
then read by the owner’s software, with minimal direct human intervention4. If this is indeed the
intent, then XML might be a better choice than a spread sheet. It provides a more cohesive
structure to the data (albeit it mostly hierarchical) and therefore the information is less scattered.
It may be easier for software to interact with an XML file. For example, most civil design
software can read and write LandXML. XSLT (Extensible Stylesheet Language
Transformations) can be used to translate XML documents into another XML document and thus
accommodate schema differences. Transformations and tools exist for mapping ifcXML to and
from COBie spread sheets.
COBieLite is a candidate XML representation of COBie designed as an alternative to ifcXML,
though closer to ifc4XML. It was born out of a need to support hand-held and remote sensing
devices. It “is a National Information Exchange Model (NIEM) compliant XML specification for
COBie that simplifies the delivery and use of facility asset information for those outside the
typical architects, engineers, builders, and managers who already use COBie in IFC or
SpreadsheetML formats.” [NIBS-9].
The Clinic building from the 2012 COBie Challenge [NIBS-8] has been formatted using the
COBieLite XSD schema definition. The resultant XML document is about ten times the size as
the spread sheet version file and is over 200,000 lines long. Though complex at first glance, the
stripped down version included in Appendix A appears relatively straight forward. It obviates the
concern about scattered data that is apparent in the spread sheet version. The extract in
Appendix A demonstrates all of the schema structure but eliminates all but one occurrence of
each COBie concept. Further simplification of the XML schema should be investigated.
COBieLite contains the same information as the spread sheet file. COBieLite’s similarity to
ifc4XML may make its future uncertain if it is transferred to buildingSMART International (see
Problem 3: COBie Standard, Discussion, below).
3.1.3 Recommendation
Given the interoperability of IFC, COBie, ifcXML, ifc4XML, COBieLite , other XML schemas such
as LandXML, and of generic spreadsheet arrangements, it is of decreasing importance which
structured form data is originated in. However the supply chain and demand side need a
common target and COBie may fulfil that role. It might be advisable to use any of the above
forms as a short term expedient to collect the information to demonstrate how COBie can be
used to exchange information on C/I projects from construction to operations.
4 The BIM Task Group believes that “on small projects COBie UK 2012 may also be created or updated by hand directly
in the spreadsheet version of the COBie UK 2012 data” [HMG-3]
3.2 Problem 2: COBie Schema

Two issues have been raised about the COBie schema which relate to C/I, as well as to
buildings. Firstly, packaging into DESIGN, BUILD, and COMMON may be an oversimplification
of incremental data drops. Secondly, the asset management view supported may not be
consistent with the requirements voiced by the interviewed stakeholders.
3.2.2 Discussion
3.2.2.1 Packaging
[NIBS-3] uses the following graphic to provide a high level view of when each COBie concept
(spread sheet) is relevant during the facility life-cycle:
Treating DESIGN, BUILD, and COMMON as packages may be inappropriate, as they are not
mutually exclusive, and not all inclusive. It makes sense to have TYPE and COMPONENTS under
DESIGN because TYPE provides the requirements for COMPONENTS. COMPONENTS are
instances which eventually get serial numbers and installation date and therefore logically are
also included in BUILD which is why orange BUILD overlaps into DESIGN. Similarly TYPE
assets may become products with known manufacturer and model numbers.
The COMMON items are intended to be “supplementary” and include ASSEMBLY and IMPACT at
COBie 2.4. CONNECTIONS can connect either TYPES or COMPONENTS. ASSEMBLY aggregates
TYPES or COMPONENTS. CONNECTION and ASSEMBLY are “supplemental” in the sense that they
are optional, and reference the DESIGN and BUILD assets. Various Operations such as
maintenance, start-up, shut-down, inspection and so on) are documented in the JOB package.
This reflects the constructor’s responsibility to handover the operational information for the
products in the facility.
Some of these questions are answered in the FM Handover [NIBS-4] which provides further
refinement of the life-cycle processes and allocates schema content based on this further
refinement.

3.2.2.2 Asset View
Perhaps the biggest complaint about the COBie schema, is that it does not support the asset
management perspective voiced by the interviewed stakeholders. Both CRL [CRL-1] and Tube
Lines speak in terms of a requirement for an asset vs. the fulfillment of that requirement with an
actual asset instance. This separation enables the installation of any of a set of supplied assets
anywhere that they fulfill the requirement. More significantly, this separation supports the notion
of substitution of asset instances over time (temporary or long-term) when the requirements
themselves have not changed. The key to the success of this strategy is to not over specify the
requirement (e.g., mandating a particular manufacturer’s model) but to allow “approved equals”
to meet a more loosely defined requirement.
The requirement for an asset includes classification of the asset type. This is implemented in
COBie as TYPE.CATEGORY and SYSTEM.CATEGORY. TYPE.CATEGORY is specified by
OmniClass Table 23 (category-product PICKLIST) or Uniclass L classification, supporting a
maintenance view.
However, from the interviewed stakeholders’ perspective, an asset requirement also specifies
function. Function is the duty performed by the asset (e.g., building structure) and supports an
operator’s view. In COBie, SYSTEM is a functional aggregation of COMPONENTS.
SYSTEM.CATEGORY is specified as OmniClass Table 21 (category-element PICKLIST), or
Uniclass G/H supporting a functional view.
Also from the client perspective, an asset requirement also specifies location. This is discussed
below.
CRL calls the combined classification (TYPE category) / function (SYSTEM category)/ location
(SPACE) requirement an Asset Tag. So a boiler TYPE (with product category) to be located in
the basement SPACE (location) is required to provide heating SYSTEM (with function category).
Most of the information defining an asset tag is held in COBie in each COMPONENT row: the
COMPONENT, the TYPE, the SPACE. Only the SYSTEM assignment(s) are held separately,
pointing to the COMPONENT.
A COMPONENT can have a serial number and an installation date so it also behaves as an asset
instance fulfilling a particular asset requirement at some point in time. It has a COBie TYPE as
the asset requirement with a product classification and it is in a SPACE (location) as part of a
SYSTEM (function). It can be substituted for another like COMPONENT if necessary, without
changing the asset requirements defining its classification, location and function. This matches
the CRL notion of a Serialization: a specific instance of Equipment (TYPE) that exists at the
Asset Tag location at a particular point in time and characterized by a serial number or batch
number.
Equipment (TYPE) ultimately may represent a specific manufacturer’s model which can fulfill the
requirements defined by the Asset Tag. Equipment will therefore have a manufacturer and
model. COBie holds the manufacturer and model with the TYPE, not COMPONENT. What you
really want to be able to do is swap out a piece of equipment (not just a serialization) that
satisfies the Asset Tag requirement. In other words, you may wish to use the same type of
thing, an “approved equal” that has a different model number and is from a different
manufacturer. This takes substitutability beyond just being a new instance of the same
manufacturer/model but having a new serial number. With COBie, this would need to be a new
TYPE so you have to go back and re-define the asset requirement, not just the fulfilling asset
instance. So perhaps COBie TYPE is over specified.
A distinction is being made regarding cast-in-place assets. They have classification, location,
and function so constitute what CRL is calling an Asset Tag. However, the notion of
substitutability does not apply. Because they were cast in place, there are no equivalent items
from a manufacturer that can be brought in to replace them. In this case, CRL would not have
an Equipment or Serialization for this Asset Tag [CRL-2].
The Figure below shows a correspondence between COBie TYPE, COMPONENT, SYSTEM, and
SPACE and CRL Asset Tag, Equipment, and Serialization.

Bottom line is that all of the client required information is in the COBie schema, but not
necessarily in the preferred place.
The disparity in where information is located, as seen in the above figure, is exacerbated by the
already scattered nature of the spread sheet layout presented as Problem 1: COBie Spread
Sheet Format above. It is further complicated when an attempt is made to aggregate assets
into nestable groups.
COBie 2.4 introduces ASSEMBLY as an aggregation of either TYPES or COMPONENTS. It is defined
as having a single parent TYPE or COMPONENT with multiple child TYPES or COMPONENTS,
respectively. The parent is itself either a TYPE or COMPONENT, appearing in that spread sheet.
This enables nesting of ASSEMBLIES.
CRL has Functional Units as aggregations of Asset Tags. Since Functional Units are Asset
Tags themselves, nesting is possible. Furthermore, as an Asset Tag, they represent an asset
requirement which can then be fulfilled: “If a system has been supplied as a single entity and
has a specific manufacturer’s number, for example, lifts and escalators, then Equipment will be
created against the Functional Unit to record these details.” [CRL-1]
On the surface then, it appears that a COBie ASSEMBLY is equivalent to a CRL Functional Unit.
However, because of the differences between the COBie TYPE, COMPONENT, SYSTEM, and SPACE
and the CRL Asset Tag, Equipment, and Serialization, the relationship between COBie
ASSEMBLY and CRL Functional Unit is even less straight forward from an asset management
point of view.
One could argue that COBie is only an information exchange and therefore, as long as it
contains all of the necessary information, it fulfills its role. It is the responsibility of the
contractor’s software to create the COBie file and the owner’s software to be able to read it.
Therefore, it is the responsibility of the CRL software to map COBie TYPES, COMPONENTS,
SYSTEMS, SPACES, and ASSEMBLIES into CRL Asset Tags, Equipment, Serializations, and
Functional Units.

However, if an asset-oriented view is being introduced earlier on in the life-cycle, then designers
and contractors should be aware of the distinction between asset requirement and fulfilment.
This then means they are forced to distribute the asset-oriented information across incompatible
COBie spread sheets. Because this will be less intuitive to them, there would be higher risk for
error. This is further exacerbated by the data fragmentation enforced by the COBie spread
sheet layout. It does not make sense to map from an asset view into a COBie view when writing
the COBie file only to have to map back to the asset view when reading it.
One proposal considered would be that Columns of MANUFACTURER and MODELNUMBER should
be moved from TYPE to COMPONENT, or else they should be relabeled as
EXAMPLEMANUFACTURER and EXAMPLEMODEL. EQUIPMENT (and perhaps CAST-IN-PLACE) needs
to be added, preferably as part of a new Operate package. Serial number would then be moved
from COMPONENT to EQUIPMENT. Then COMPONENT truly does become the asset requirement
(Asset Tag) and EQUIPMENT and CAST-IN-PLACE are the fulfillment of that requirement.
However The following two short term recommendations are made to use the COBie schema to
better suit the requirements voiced by the interviewed stakeholders.
Firstly to address the desire to separate the requirements on a Component from the fulfilment
1. TYPE can hold both requirement Types and product TYPES: Extend the AssetType
enumeration to offer Requirement in addition to the current Fixed (Cast-in-place) or
Moveable (Equipment). A ‘requirement’ type is not expected to be purchased, but may
be compared against the available TYPES.
Secondly to document the allowed substitutions of one Component for another, or for one Type
for another.
2. Add column to the TYPE.AllowableSubstitutions
a. This field then documents equivalent product TYPEs that satisify the
requirement
b. This is only expected on ‘Requirement’ TYPEs
c. This is blank for cast-in-place TYPEs
d. This is blank for manufactured product TYPEs
3. Add column to the COMPONENT rows to document COMPONENT.RequirementType
a. COMPONENT TypeName remains the installed Type
Long term, a proper data modeling exercise should be done for the information exchange,
including accommodation for the impact of C/I projects and an asset management view. If
multiple schemas persist, then perhaps ISO 15926 should be evaluated as a possible solution
for handling them.

3.3 Problem 3: COBie Versions

It is difficult to say what exactly constitutes the COBie standard. It suffers from distributed,
dynamic documentation, suspect version control, and distributed governance.
3.3.1.1 Documentation
COBie has not been formally standardized as an ISO standard. Meanwhile aspects of the
COBie standard are distributed across the internet. The references section of this document
attempts to capture the most significant of these various documents. [NIBS-1] introduces
COBie. [NIBS-3] provides an overview and links to other relevant internet sites. [NIBS-2]
Clause 4.2.4 appears to be the official balloted COBie 2.26 standard in the US but is at too high
a level to be implementable by itself. Instead, it cites the ISO/PAS 16739:2005 [ISO-1] industry
foundation class (IFC) model and the FM Handover MVD [NIBS-4] as normative references. An
extensive Bibliography includes (non-normative) references to some 38 other documents,
describing the development and application of COBie. Critical among these are the COBie
Responsibility Matrix [NIBS-5] and the COBie Guide [NIBS-6], but these are assumed to be
informative only.
The COBie Responsibility Matrix [NIBS-5] lays out the spread sheet schema but is missing some
key optionality’s and cardinalities between concepts (spread sheets). It also enables the
allocation of responsibility for populating the spread sheets at different stages in the project life-
cycle. Unfortunately, it keeps getting updated (now at version 16) with no indication (or
availability) of the version that goes with the balloted COBie 2.26.
The COBie Guide [NIBS-6] is extremely helpful for elucidating schema details missing from the
Responsibility Matrix. Unfortunately it remains a document in progress. Being non-normative, it
suggests further requirements (e.g., provision of CURRENT, VOLTAGE, and FREQUENCY attributes to
electrical TYPES).
It has been suggested that “the open standard Schematron-based source code for the COBie
tool kit that shows the -exact- testing of data integrity checks that are being done in the COBie
Tool Kit” would be a good source for further information about the schema. This source has yet
to be checked. If different to content elsewhere then this content should be included in a part of
the normative standard. It would not have been voted upon as part of the standard’s
acceptance by NBIMS-US since was developed after [NIBS-2].
3.3.1.2 Version Control
COBie version 2.26 was adopted last year as a standard in the US as part of the National BIM
Standard-United States™ Version 2 [NIBS-2]. It is based on the FM Handover which uses IFC
2x4. However, this version of IFC was not approved until this year.
For International acceptance, additional functionality has been added (e.g., ASSEMBLY and
IMPACT worksheets) as COBie 2.4 (sometimes cited as 2.405) [NIBS-7]. The additions are
backward compatible with COBie 2.26, and do not alter the existing structure. COBie 2.4 is
being balloted in the US as part of NBIMS-US V3 during the summer of 2013. COBie UK 2012
[HMG-2] expects COBie 2.4, although some documentation references to earlier COBie 2.26
material. Versions of the Responsibility Matrix do not appear to be coordinated with versions of
the standard.
The following changes were introduced between COBie 2.26 and COBie 2.4 . There is
1. Additional columns on the Type sheet .
2. Introduction of the Issues sheet for H&S and other concerns
3. Introduction of the Impact sheet for cost, carbon and other environmental measures
affecting stages of the asset life-cycle.
5 Excel would show 2.40 as 2.4 if the cell format specified one decimal place. This may be the origin of this confusion.
Or it could really be 2.4 since it implements IFC 2x4. From a versioning viewpoint, it is confusing that 2.4 would
follow 2.26.
3.3.1.3 Governance
COBie is jointly controlled by buildingSMART alliance (North America) and buildingSMART UKI
(UK and Ireland) under a Memorandum of Understanding. It was originally developed in the US
at the US Army Corps of Engineers (USACE) Engineering Research and Development Center
(ERDC) Construction Engineering Research Laboratory (CERL) and approved as a NBIMS-US
V2 standard under the buildingSMART alliance, a council of the National Institute of Building
Sciences.
The COBie UK 2012 site [HMG-1] is hosted by the Building Information Modelling (BIM) Task
Group, a part of HM Government Department for Business Innovation & Skills. The SDO for
COBie UK is buildingSMART UKI. The site directs you to [NIBS-1], [NIBS-4], and [NIBS-5] for
details on the standard. Discussion
COBie 2.4 includes international input.
The FM Handover is updated for COBie 2.4. It is derived from the full ISO 16739:2013 IFC
standard by:
1) filtering out only those IFC’s needed for the COBie information exchange
2) adding appropriate constraints
The new FM Handover is interactive, facilitating search and internal links. As a normative
reference for COBie 2.4, it should provide the complete COBie schema definition.
An NBIMS US Technical Committee member has stated that CERL funding has been reduced
and therefore buildingSMART International (bSI) will be taking over COBie. Neither bSa, bsUKI
or bSI has not yet adopted COBieLite, an XML version of COBie.
buildingSMART International have their own ifc4XML, which implements an international
standard ISO-10303 part28 ed2. . There has a mechanism for creating simplified subsets
reflecting selected hierarchies and relationships. It is not apparent what will happen to COBieLite
if COBie moves to bSI.
It appears as though COBie 2.4 may become a more proper standard. It would therefore seem
prudent to focus on it instead of 2.26. This will also form the basis for the proposed
BS1192:4:2014 document.

3.4 Problem 4: COMPONENT Geospatial Location

C/I projects also tend to have larger spatial extents than individual building projects. Individual
C/I managed assets typically exist across a much broader spatial extent than do building assets.
It is no surprise then that Geographic Information Systems (GIS) play a more significant role in
C/I asset management [IAM-1].
C/I components may be located at a geospatial position or by using a geospatial feature. Use of
a geospatial position requires the specification of a Coordinate Reference System (CRS) which
is typically more global than a local Cartesian building coordinate system.
COBie needs to be able to store information about geospatial locations for use in locating
components. Examples of geospatial features include station footprints, areas of interest or
sensitivity (e.g., sound levels), and buffers around linear features.
Also from the client perspective, an asset requirement also specifies location. Location defines
where the asset is to be located in support of the building manager’s view. COBie specifies
locations as SPACES.
3.4.2 Discussion
The FM Handover MVD, upon which COBie is based, is limited to “non-geometric building
information” [NIBS-2], but nonetheless does support some geometric information. Alternatively
This information may be held separately in a GIS or geospatial database, like Oracle Spatial, just
as CAD drawings and 3D building models are held in external systems separate from the COBie
spread sheets.
COBie currently allows the locating of components in both a spatial hierarchy and also in a
coordinate hierarchy. Geospatial support needs to be added.
3.4.2.1 Existing Spatial Hierarchy

COBie needs to be able to specify where COMPONENTS are located. In accordance with IFCs,
containment is achieved via an assignment of a COMPONENT to a SPACE, where SPACES are
contained on FLOORS without defining their precise geometry.
In order to respect the generalized spatial hierarchy, COBie for C/I could retain the Facility-Floor-
Space structure and allows C/I projects to use Floor as a synonym for Region and Space as a
synonym for Location. As an example, The COBie Guide [NIBS-6, pg. 20] offers the following
recommendation for site features:
For each facility compound or campus with shared site work, a separate COBie file shall be
submitted. A single COBie.Floor row will be created for this site file and identified as a
COBie.Floor.FloorType of “Site.” Definable areas within that site will be identified in rows in
the COBie.Space worksheet. Examples of typical COBie.Space rows within
COBie.Floor=Site’s are parking lots, utility pads, loading docks, etc… The default list of Site
spaces that shall be included for a given client are identified in Appendix A.
This informative advice is in direct contrast to the normative FM Handover which states that
“Spaces are areas or volumes that provide for certain functions within a building.” [NIBS-4,
5.3.3.43 IfcSpace], and “A building storey has an elevation and typically represents a (nearly)
horizontal aggregation of spaces that are vertically bound.” [NIBS-4, 5.3.3.5 IfcBuildingStorey] –
(underlining added for emphasis). Elsewhere the generalized concept of the spatial hierarchy
makes clear that spaces may occur within the site.
It should be noted that all COMPONENTS must be located in a SPACE, even if they are located
more precisely with COORDINATES.
3.4.2.2 Existing Coordinate Support
Currently in COBie, COORDINATES can be defined for SPACES , FLOORS AND COMPONENTS.
Coordinate types as an enumeration are limited to “point”, “line-end-one”, “line-end-two”, “box-
lowerleft”, and “box-upperright”. Any type of point can be used with any of these objects.

3.4.2.3 Geospatial Coordinates

The identified need is to use a single point location, specified by its coordinates, to locate a
COMPONENT. This can be solved by the COORDINATE spread sheet. This sheet includes
specification of X, Y, and Z coordinates for COORDINATETYPE = “point”.
This leaves the Coordinate Reference System(s) – CRS. This could be done as a property at
the facility level if all points have the same CRS. Otherwise this could be specified as the facility
default geospatial CRS which can then be overridden with a property of the coordinates for
individual points.
These CRS properties can either be added as columns to the FACILITY and COORDINATES spread
sheets or as attached attributes in the ATTRIBUTE spread sheet. But it is probably reasonable to
expect that there is some area within which these COORDINATES exist and this can be used to
satisfy the COMPONENT SPACE requirement.
On a similar note, COBie says that SPACES occur on a FLOOR in a FACILITY. Renaming FLOOR to
REGION with floor as one type of REGION would allow the preservation of the COBie spatial
hierarchy whilst still supporting this C/I requirement. Even in C/I, there is most likely some
physical area breakdown of a FACILITY before getting to the more specific LOCATION.
3.4.2.4 Geospatial Feature Location

Following the advice in the Guide, the geospatial locations should be treated as COBie SPACES.
COMPONENTS can then be specified as occurring in these geospatial “spaces”. Perhaps SPACE
can be renamed LOCATION. This would accommodate geospatial locations that are points,
curves, surfaces, solids, and collections of these. This would also help with linear locations (see
4.5, Problem 5: COMPONENT Linear Location, below).
Again, by renaming FLOOR to REGION with floor as one type of REGION would allow the
preservation of the COBie spatial hierarchy whilst still supporting this C/I requirement. Even in
C/I, there is most likely some physical area breakdown of a FACILITY before getting to the more
specific geospatial feature LOCATION.Fortunately, most GIS and geospatial databases today
conform to ISO TC211 and OGC software standards. These standards prescribe a feature
model where a feature instance is the representation (abstraction) of some real world
phenomenon, such as a building, a road or a catch pit. Hierarchically structured feature classes
define properties for features. Geometry/location is one of these properties and can occur zero
or more times per feature instance. Feature instances have a unique id within some scope. The
result of this is that the geometry/location can be kept in the GIS or geospatial database and
then be referenced by COBie via the feature id. Though multiple geometry/locations can exist
for the same feature id (e.g., a tube station can be represented as a point or a polygon), COBie
probably does not need to concern itself with this level of detail.
Mandatory columns in the SPACE spread sheet are: NAME, CREATEDBY, CREATEDON, CATEGORY,
FLOORNAME, and DESCRIPTION. The NAME would be the COBie name used to refer to the
geospatial feature. It would be the SPACE name contained in the COMPONENT spread sheet. It
may not be the same as the geospatial feature name in the GIS or geospatial database (see
external discussion below).
The FLOORNAME refers to the building floor in the FLOOR spread sheet. As suggested above, if
FLOOR is renamed REGION, then this column becomes REGIONNAME. The allowable values for
the CATEGORY column in the FLOOR spread sheet will need to be expanded, but currently does
include “floor”.
The CATEGORY is currently limited to the SpaceFunctionClassification code list for Category-
Space. This most likely will need to be expanded beyond just building-oriented spaces.
The remaining mandatory columns are already sufficiently generic to support C/I.

Optional columns are ROOMTAG, USEABLEHEIGHT, GROSSAREA, NETAREA, EXTSYSTEM,

EXTOBJECT, and EXTIDENTIFIER. The first four of these are building-oriented but are not a
problem since they are optional and can therefore be ignored for C/I. The external columns can
be used as the (GIS or geospatial database) source of the SPACE information. The EXTSYSTEM
column could be used to specify the GIS or geospatial database. Then EXTOBJECT could be
used to specify the feature class except that it is currently restricted to ifcSpace Class Name so
the pick list would have to be extended for C/I. The EXTIDENTIFIER could be used to specify the
feature id in the GIS or geospatial data which may or may not be the same as the SPACE NAME.
i.e., the COBie geospatial feature name.
Because the geometry of the geospatial feature is retained in the GIS or geospatial database, it
may not be necessary to include the CRS in the COBie file. This could be problematic anyway,
if a feature has multiple geometric representations and they are not all in the same CRS.
The short (and long) term recommendation is to work within the existing COBie schema
structure:
1. Provide more generic names for the Floor and Space spread sheets to support C/I
facilities by supporting synonyms:
a. spread sheet FLOOR and REGION;
b. column FLOORNAME AND REGIONNAME;
c. spread sheet SPACE to LOCATION;
d. column SPACENAME AND LOCATIONNAME
2. For locating a COMPONENT by geospatial point coordinates:
a. the coordinates shall be entered into the COORDINATES spread sheet and
attached to that COMPONENT
b. an optional FACILITYCRS column needs to be added to the FACILITY spread
sheet or as an ATTRIBUTE of the FACILITY
c. an optional overriding CRS column may be needed to be added to the
COORDINATES spread sheet.
3. For locating a COMPONENT using a geospatial feature:
a. the feature shall be uniquely named in COBie
b. the feature shall be entered as a row in the SPACE/LOCATION spread sheet
c. then referenced in the COMPONENT SPACE/LOCATION column
d. the feature geometry and CRS will not be copied into the COBie file
e. the EXTSYSTEM, EXTOBJECT and EXTIDENTIFIER columns in the SPACE/LOCATION
spread sheet can reflect the geospatial database or GIS from which the feature
geometry (and CRS) can be obtained.

3.5 Problem 5: COMPONENT Linear Location

Many C/I managed assets tend to be linear (roads, rail) and project components consequently
tend to be linearly located along existing or proposed linear assets, instead of within spaces on
floors in buildings. Such locations can be specified using linearly referenced locations. In
accordance with ISO 19148 [ISO-2], a linearly referenced location requires the specification of
the linear entity along which a measurement is made, the method of measurement called a
Linear Referencing Method (LRM), and the measured value along (and optionally offset from)
the linear entity. See Appendix B for examples.
COBie would need to store information about linear entities along which COMPONENTS are
located and possibly about LRMs. The COMPONENTS being located would then require an “at”
linearly referenced location or else “from” and “to” linearly referenced locations as alternatives to
space or geospatial locations.
3.5.2 Discussion
A linearly referenced location requires three components (linear element, LRM, and measured
value which may include offsets) [ISO-2]. To use linear referencing to locate a COMPONENT, that
is, with respect to a linear entity, one or two linearly referenced locations are required. The
COMPONENT may either be at a single linearly referenced location or from one linearly referenced
location to another. In the latter case, this may be simplified by adding constraints on the two
linearly referenced locations, such as requiring a common LRM or even a common linear
element, but this is not without compromising the full flexibility of ISO 19148.
3.5.2.1 Linear Element
Linearly referenced locations must specify the linear element along which the measurement is
made. This is similar to an axis in a CRS (though the LRM and measurement can be quite
different than just a single numeric value). Somewhere COBie will need to keep a list of
allowable linear elements. These may be assets (COMPONENTS) such as a road. More likely,
they will be some reference line, such as an Engineering Line of Reference (ELR) in the case of
Network Rail, a London Underground (LU) Location Coding System (LCS) coded entity in the
case of Tube Lines, or a Section [HA-2] in the case of the UK Highways Agency.
In keeping with the COBie Guide’s strategy of using SPACES to locate COMPONENTS regardless
of the location type, linear elements would end up in the SPACES spread sheet. Aside from
needing to expand the list of allowable SPACE categories, this would work if you can live with the
notion of one-dimensional spaces. However, ISO 19148 [ISO-2] requires that linear elements
support a measurability interface which, in the case of a data-only representation, would entail
certain mandatory attributes. These include a default LRM, default (overall) length, and start
values for each expected LRM. The type of linear element (feature, geometric curve, or
topological edge) must also be specified. These would have to be added as ATTRIBUTES.
Alternatively, a LINEARELEMENTS spread sheet could be proposed as an additional spread sheet
in the COBie workbook, with columns for NAME, CREATEDBY, CREATEDON, CATEGORY (“feature”,
“curve”, or “edge”), DESCRIPTION, EXTSYSTEM, EXTOBJECT, EXTIDENTIFIER, DEFAULTLRM,
DEFAULTLENGTH, and STARTVALUES. The last one is tricky, as it would need to be a list of (LRM,
startValue) pairs. Assigning a FLOORNAME to SPACES would be problematic, since the linear
element may not be wholly contained within the Site defined by the FACILITY, for example, I-95 or
the M-1. Perhaps a more global region beyond the scope of the facility should be allowed?
If a relative LRM (e.g., reference post) is to be used to measure along a linear element, then the
referents from which the measurements are made must be at known locations along the linear
element. ISO 19148 prescribes that these referents be “owned” by the linear element. If, as
part of an automated reading of a COBie file, linearly referenced locations need to be translated
into locations that use a different LRM or linear element, referent locations along their owning
linear elements need to be available, presumably from the COBie file.

3.5.2.2 LRM
The Linear Referencing Method (LRM) specifies how measurements are made. The LRM
provides a context for the measured value, specifying how (absolute, relative, interpolated) the
measurement is made (including the unit of measure).
During design and construction and often in maintenance/operation of railways, an absolute type
of LRM called stationing is common. This says that a measured value of 1+05 means 105 feet
measured along a linear element such as an engineering survey line or ELR, measured from its
beginning (or 105 meters for a metric stationing LRM). Another absolute type of LRM is
chainage which says that a measured value of 1023 means 1023 meters along a linear element
such as a roadway or LCS section, measured from its beginning. In some cases, a more literal
interpretation of “chainage” is used such that the unit of measure is “chains”.
A relative type of LRM, milepost, says to interpret a measured value of 2+.50 as one half (.50)
mile beyond milepost 2, the post being exactly 2 miles from the start of the linear element being
measured. More likely, another relative type of LRM called reference post would be used
because it would allow reference post 2 to be something other than exactly 2.000 miles from the
start of the linear element perhaps due to realignment. This demonstrates the need to have pre-
defined the location of the referent (referent post 2 in this case) from which the measured along
incremental distance (.50) is to be measured.
Percentage is an interpolated type of LRM which says that a measured value of .50 means 50%
of the distance along the linear element. This would be based on the default length value of the
linear element.
For greatest flexibility, the LRM of each linearly referenced location should be specified as part
of that location specification. However, this is typically simplified by adopting a default LRM for
each linear element or even for the FACILITY at large. This decision will impact where LRM is
held: with each linearly referenced location, with each linear element, or with the FACILITY.
Though ISO 19148 is adamant about de-coupling the LRM from the linear element, the standard
will allow a linear element to have a default LRM which will be used to measure the linear
elements in the absence of an explicitly stated LRM.
In accordance with ISO 19148, the specification of an LRM includes the following attributes:
name, type (“absolute”, “relative, “interpolative”), units, constraints, and, if it supports offsets,
then additionally offset units, positive lateral offset direction, and positive vertical offset direction.
Unfortunately, there is no universal agreement on what LRMs are called or what each one
means. If they are to be defined in COBie, an LRM spread sheet would need to be added, with
the normal COBie columns like CREATEDBY plus columns to support the above listed attributes.
Otherwise, like geospatial location CRSs, the definition can be held outside of COBie proper,
perhaps even in a COBie DOCUMENT. This decision would be dependent upon the variety of
LRMs used and the requirement that, as part of an automated reading of a COBie file, linearly
referenced locations need to be translated into equivalent locations that use a different LRM.
3.5.2.3 Measured Value
Based on the LRM, the value of the distance measured along the linear element might be a
numeric value (e.g., chainage LRM) or an alphanumeric string (e.g., reference post LRM). The
units of measure are defined by the LRM.
Presumably, the measured distance along would be an attribute of the COMPONENT, either as a
newly added COMPONENT column or as an ATTRIBUTE with a SHEETNAME = “Component” and a
ROWNAME equal to the COMPONENT.NAME. ATTRIBUTE.UNIT would only be used to override the
LRM units value.
3.5.2.4 Offsets
Once the measured value is measured along the linear element, it is possible to then measure
an offset distance to arrive at the linearly referenced location. ISO 19148 supports optional
lateral (perpendicular left or right) offsets and vertical (up or down) offsets or offset vectors
measured in any direction. The first two can be measured absolutely from the linear element
position established by the measured along distance or can be relative from some offset
referent, such as “five feet back of sidewalk” [see ISO-2].

Presumably, the offset would also be an attribute of the COMPONENT, either as a newly added
COMPONENT column or as an ATTRIBUTE with a SHEETNAME = “Component” and a ROWNAME
equal to the COMPONENT.NAME. Depending on the level of offset sophistication supported (if at
all), this might be a single positive value specifying an absolute lateral measure in the direction
of the positive lateral offset direction or a negative value in the opposite direction, measured
from the linear element as the simplest extreme. Alternatively it might require up to four
attributes (lateral offset measure, lateral offset referent, vertical offset measure, and vertical
offset referent) or up to three offset vectors. ATTRIBUTE.UNIT would only be used to override the
LRM offset units value.
3.5.2.5 COMPONENT Linearly Referenced Location
Putting this all together, to specify the location of a COMPONENT by using at or from/to linearly
referenced locations, the linearly referenced location(s) must be added to COMPONENT. Each
includes a linear element, an LRM, a distance along, and perhaps offsets. Additional
information about linear elements, their referents, and LRMs may also have to be added to new
COBie spread sheets, especially if, as part of an automated reading of a COBie file, linearly
referenced locations need to be translated into locations that use a different LRM or linear
element. A spread sheet that accommodates LINEARELEMENTS would facilitate referential
integrity checking, insuring that any linear element used in a linearly referenced location exists.
ISO 19148 is a very comprehensive standard for linear referencing. Based on a well-
documented, theoretical model, it is quite sound. But there is no reason to have to support all of
its capabilities as a first step, especially since some of these capabilities are optional in the
standard.
To simplify the support for linear locations the following recommendations are made:
1. Columns are needed in the COORDINATES spread sheet to specify linearly referenced
locations for each COMPONENT and SPACE/LOCATION. These columns shall be:
a. REFERENCEDCORDINATE – the linear element along which the linearly
referenced locations are specified. There is no need to make any simplifying
assumption that, if there is to be both from and to linearly referenced locations,
they will be along the same linear element. The linear element here is likely to
be a reference line, like ELR or LCS entity, so it may be reasonable to assume
that assets do not cross linear element boundaries.
If the SPACE spread sheet is generalized to LOCATION, as is proposed above for

geospatial features, then linear elements are LOCATIONS. The COMPONENT
SPACE attribute is synonymous with LOCATION, consistent with geospatial
features and this obviates the need for a separate LINEARELEMENT column. It
also facilitates referential integrity checking of linear elements used in the
COMPONENT spread sheet. The differentiation between feature, geometry, and
edge or component and reference linear element could be accommodated with
the SPACE CATEGORY. If LOCATION is used to specify linear elements, then it will
be mandatory that from and to linearly referenced locations be measured along
the same linear element.
b. DISTANCEALONG1 – the distance along the linear element for the first linearly
referenced location, measured either from the start of the linear element or
additionally contained referent. This needs to be alphanumeric to be able to
support either absolute or relative LRMs. This first location will be for either an
“at” or a “from” location value.
c. OFFSET1 – the start offset at the first location. Values will initially be limited to
lateral offsets or “n/a” if an offset is not specified. For numeric values, the sign
will indicate whether it is to the right or left, based on the positive lateral offset
direction specified by the LRM. Supporting alphanumeric values will be needed
for Highway Agency XSPs and Network Rail ELR/Track offset requirements.
d. Actual data from use case UC 3: Linear Location proposed below may
indicate preference for which, if any, approach is preferable.

2. These columns would support the definition of a COMPONENT OR SPACE/LOCATION

linearly referenced location equal to either:
a. A point location as a single “at” point An example is the location of a street sign
post.
b. A linear location as a curve starting at DISTANCEALONG1, OFFSET1, and ending at
DISTANCEALONG2, OFFSET2, The exact geometry of the curve is not defined in
the COBie file – the two linearly referenced locations merely specify the extent
of the curve. An example is curbing.
c. An area location as an area is defined using the top/eft and botton right points
each having a DISTANCEALONG1, OFFSET1 and ending at DISTANCEALONG2,
OFFSET2. The exact geometry of the area is not defined in the COBie file – the
two linearly referenced locations merely specify the extent of the area. An
example would be a section of pavement.
3. Add a Facility Attribute for a default Facility LRM. It is highly likely that all Components
will be linearly referenced using the same LRM and therefore this can be carried at the
Facility level, i.e., specified once per COBie workbook. Alternatively, a Location column
or Attribute could be used to specify an LRM of a specific linear element.
4. The definition and details of the LRM can initially be documented in a DOCUMENT or
ATTRIBUTE attached to the FACILITY.
5. Synonyming SPACE to LOCATION would accommodate linear elements as SPACE/
LOCATION NAME attribute of a COMPONENT.
Figure 3: Coordinates expanded to offer actual and/or LRM
One of the use cases proposed below (UC 3: Linear Location) will test if this proposal is a
reasonable first step towards integrating COMPONENT linear location in support of C/I.

3.6 Problem 6: Continuous Objects

Building elements (floor and spaces) and components tend to be discrete entities. With C/I,
linear entities are “continuous” – there is no agreement as to where a road for example stops
and the next one begins. This is typically based upon each person’s view which includes only a
subset of the attributes of the road of interest to that person. The pavement engineer
decomposes a road into pavement sections, of uniform pavement type. A traffic engineer may
decompose the same road into sections of equal traffic volume, regardless of pavement type. It
has been demonstrated that decomposing a road into very small sections based on any of all of
its attributes changing value is unreasonable: the resultant sections are too small, redundant
information is required since all attributes for all sections must get a value for each resultant
section, even if it is unchanged from the previous section, and it is unstable because it is
impossible to identify every possible attribute a priori.
It is obviously impossible to tag continuous assets without first establishing a reasonable
segmentation scheme. The discretized assets can then be tagged based on an identity
established by their physical location limits.
3.6.2 Discussion
The most reasonable solution to continuous entities has proven to be to decompose them based
on one (any consistent) reasonable sectioning scheme (intersection to intersection, control
section, Engineering Line of Reference (ELR), Location Coding System (LCS) coded section,
etc.). It is then possible to define discrete assets as parts of continuous entities by specifying
the start and end position of the discretized asset as linearly referenced locations along a
reference linear entity. Only then can the resultant discretized assets be tagged.
In COBie, there is an implicit assumption that all COMPONENTS are discrete elements. When one
is referenced by name, the reference is to the COMPONENT in its entirety, for example, a single
pump or door. With C/I, part of the identification of the discretized assets would need to be the
start and end location as specified along some pre-stored linear entity. Identifying a section of
track as a single, constructible or manageable COMPONENT requires knowledge about its start
and end delimiting locations. This can be specified using linearly referenced locations along
some reference line (linear element), similar to what was used for locating COMPONENTS above
in Problem 5: COMPONENT Linear Location.
Pavement cross-section can vary across the width of a carriageway as well as along the length
of the carriageway. To specify a pavement section as a single discrete COMPONENT for
construction or maintenance then would require from and to linearly referenced location distance
along values as well as from and to offset values for each.
It seems reasonable to combine the notions of locating a COMPONENT with the notion of
delimiting it for discretization for identification sake. So the proposal to add from and to linearly
referenced locations as specified in Problem 5: COMPONENT Linear Location above should
also solve Problem 6: Continuous Objects.
See 4.5.3

3.7 Problem 7: Variable Asset Values

Another problem with linear entities is that their attributes can change value along their length.
Let us assume that we began with the continuous linear entity called Interstate I-95 or the M-1
highway. We can discretize it into sections based on junctions. Each stretch of highway
between two junctions is then a tagged, discrete asset. There is no guarantee that all of the
attributes of this highway section asset will have a single value. Speed limit, for example, might
change at some location between the two junctions. Rather than further segmenting the asset, it
is better to just record the start and end locations along the section where each speed limit value
applies. Once more, these locations would be specified using ISO 19148 linearly referenced
locations.
3.7.2 Discussion
This would necessitate adding start and end locations to those attributes whose values might
possibly change along the length of the tagged linear asset. The options are whether the
linearly referenced start and end locations use a localized LRM or the global one. In the first
case, the COMPONENT being attributed becomes the linear element and the LRM must be
specified somewhere. In the second case, the attribute value locations are specified using the
reference linear element that was used to identify and locate the COMPONENT. The LRM
specified for the FACILITY then applies.
Consider an example, where an ELR is the reference line (linear element) used to specify the
extent of the COMPONENT, a section of track, using a stationing LRM. It is possible that track
attribute values could be located by positions along the track itself (as a linear element), using a
chainage LRM.
An initial, simplifying assumption would be to select between the COMPONENT and the reference
LINEARELEMENT as the linear element, and therefore the LRM, but this is a difficult choice to
make. The simpler approach seems favorable – use a local linear reference system based on
the COMPONENT. This would allow measurement along a track section in the example. If the
ELR linear referencing system were instead to be selected, it could very well complicate the
linearly referenced location for the start and end locations, necessitating offsets to specify the
track.
The default local (COMPONENT) LRM could be added as an ATTRIBUTE of FACILITY if it applies for
all COMPONENTS. Otherwise, it would be necessary to add the COMPONENT instance to the
proposed linear element document or spread sheet discussed in Problem 5: Component
Linear Location.
Since it is not possible to add ATTRIBUTES to ATTRIBUTES, the only alternative would be to add
start and end location columns to the ATTRIBUTE spread sheet. The ATTRIBUTE which requires
the start and end locations for its value would most likely apply to a COMPONENT.
As an initial approach, the COMPONENT will be used as the linear element for specifying the start
and end locations. The default, local LRM will be added as a FACILITY ATTRIBUTE called
COMPONENTLRM. Initially, this LRM can be limited to absolute or interpolative types to obviate
the need for referents and to enable the distance along values to be numeric.
This leaves only two columns to be added to the ATTRIBUTE spread sheet: STARTLOCATION and
ENDLOCATION. Each would be a numeric, distance along value.
Longer term, attributes could be attached to the LOCATION linear element instead of the
COMPONENT. Expanding the ATTRIBUTE STARTLOCATION and ENDLOCATION to include offsets
would support the notion of an ELR distance along with a track offset.

A solution may be to use the IfcPropertyListValue or IfcPropertyTableValue. Within COBie, the

Table values are presented as a list of bracketted pairs (or triples etc) of values.
a. For example “(60, 1.5, 7.5),(45, 7.5, 20.5)” with the units specified as “mph,
miles, miles”, which handles gaps.
b. Or “ (1.5, 60),(7.5, 45),(20. 5, 60)” with the units specified as “miles, mph”
c. Or “ (1.5, 60) with the units specified as “miles, mph” for located measures.

3.8 Problem 8: IFCs

There are numerous general purpose Industry Foundation Classes already defined (e.g.,
IfcElement, IfcProduct, IfcTypeObject, etc.) in the FM Handover MVD that will most likely work
for C/I as well. There are also numerous building-specific classes, like IfcBuildingStorey,
IfcBuilding, IfcDoor, etc. What are missing are C/I-specific IFCs as well as an assessment of the
general purpose classes to see if they are complete and able to support the C/I-specific ones.
3.8.2 Discussion
buildingSMART International - bSI (formerly International Association for Interoperability - IAI) is
the developer of Industry Foundation Classes. These have been accepted as an international
standard by ISO, with the most recent version published this year [ISO-1]. The scope statement
clearly states that “project structure and component breakdown structures outside of building
engineering” were out of scope.
bSI has announced that it is “now committed to the development of open data standards for
infrastructure and the built environment in co-operation with the Open Geospatial Consortium for
the GIS standards. The aim is to have the ability to model infrastructure by 2016, with earlier
support for bridges as the first use case.” [bSi-1]. It has created OpenINFRA as an international
initiative to improve interoperability for infrastructure facilities, such as roads, bridges and
tunnels. OpenINFRA is currently working on IFC-BRIDGE, an extension to IFC 2x4 (ISO
16739:2013).
In October, 2012, buildingSMART International commenced a project to develop a Model View
Definition for LandXML-1.2 under its OpenINFRA umbrella project. The project proposal [bSi-2]
says that “the LandXML-based exchange definitions and experiences are expected to provide
valuable input to future IFC extension developments and thus supporting also the long term
goals of OpenINFRA...This project does not directly aim at changes in IFC schema or
property/quantity sets, but may identify such needs when developing formal mapping to IFC.”
At their December meeting in Munich last year, OpenINFRA gave, as a long term goal, the
development of IFCs for C/I. The LandXML project was viewed as a short term expedient. It
would also provide insight into the requirements for defining the geometry of roadway and rail
alignments perceived as being necessary for supporting new C/I IFCs. Nonetheless, if an IFC
approach is to be adopted for C/I BIM, then buildingSMART’s OpenINFRA would be the logical
place for this to happen.
There is no short term solution to having C/I IFCs. buildingSMART plans to develop them but
admits that this may take up to five years to achieve. So any short term COBie effort will have to
proceed in parallel with them.
This is where the ISO 15926 RDL based approach might be considered from a Standards
development perspective. The core data model does not need to change in order to model
different asset types. It is an entirely different approach to standardization through collaborative
federated reference data development.
It is expected that the work undertaken in this project will inform the specification of the IFC
additions and modifications needed to deliver the required functionality.

3.9 Problem 9: Classifications

COBie advocates the use of standard classification systems (OmniClass is mandated in the US
in [NIBS-4] but is substitutable according to other documents such as [NIBS-5]) for categorizing
facilities, spaces, types, systems and organizational roles [NIBS-5].
What are missing are standardized classification taxonomies for C/I.
3.9.2 Discussion
This is not a show stopper for a short term adoption of COBie. Lack of such taxonomies for C/I
does not affect the COBie schema structure – only the content. At least outside of the US,
contractors and owners can negotiate any classification scheme acceptable to both of them.
This does not support interoperability beyond a single project or team but will at least facilitate
COBie adoption across an entire project.
There may be no short term solutions to having standardized C/I classification taxonomies. So
any short term COBie effort will have to proceed without them.
Work streams are in place to complete the work required to complete the Uniclass (2) standard
in the UK.

3.10 Problem 10: Schedules

The COBie Guide limits the scope of COBie to information about “the scheduled equipment,
products, and spaces that appear on design drawings.” [NIBS-6] – Underlining added for
emphasis. Schedules6 are a widely used approach for documenting attributes about building
and some C/I components. There is most likely a correlation between the things that are the
subject of schedules and the things that are treated as manageable assets.
This is not always the case in C/I. Managed assets include things like pavement which is not
scheduled on civil design drawings nor even easily discernible from the models, if only line
geometry is available,.
3.10.2 Discussion
Interpreting the COBie Guide statement above too literally may be the problem. It has been
suggested that the intent instead was to merely provide an example of the kind of information
appropriate to COBie. Furthermore, the Guide is only informative. Therefore “schedule” should
not be taken as a requirement but instead as a suggestion. Still, this does not help C/I much
since schedules there are not as prevalent as for buildings.
Perhaps the closest C/I analogy to the schedules used in buildings might be the “pay items” that
are used to quantify, estimate, bid, track and pay during design and construction [HA-1]. The
breakdown of the pay items varies with the life-cycle stage. A designer may use linear feet of a
particular diameter and type of drainage pipe as a single pay item. The contractor may need to
break this down into excavation based on depth, bedding, pipe, backfill and possible restoration,
each constituting a separate construction phase pay item. The asset manager may have yet a
different view.
Can pay items be used to formulate the notion of C/I managed assets? Or conversely, should
an asset management approach, introduced earlier in the life-cycle, dictate a need to schedule
more C/I pay items?
This is an industry issue involving civil design/construction documentation. Advances in design
modelling, particularly in 3D will impact this, as it begins to focus on the “things” that comprise
the model, rather than just the “lines” on a 2D drawing that are hard to interpret automatically as
managed assets.
6 Schedules are tables which document component attributes, typically included on design drawings for buildings.
Herein, “schedule” follows this definition as opposed to the notion of scheduling activities along some project
timeline.
3.11 Problem 11: Stakeholder Requirements

Several representative stakeholders have been interviewed to gain their C/I requirements for
COBie. Most of their concerns have already been included the initial 10 problems. This section
discusses some of them in greater detail to provide a context for the previous discussions.
3.11.1 Crossrail
Crossrail is the largest infrastructure project currently underway in Europe. Crossrail Limited
(CRL) is a (temporary) company positioned between the project design and construction
contractors and the eventual owners of the constructed facilities. As such, CRL is responsible
for the construction-operation handover information exchange for the project.
CRL has developed an asset identification standard [CRL-1]. In addition to laying out the asset
requirement / fulfilment dichotomy discussed above in Problem 2: COBie Schema, it contains
location codes and a functional hierarchy extension to Uniclass.
CRL is in the process of developing Asset Data Dictionary Definition Document (AD4)’s for
functions (e.g., Building Structure [CRL-2]) and asset classes (e.g., Pumps [CRL-3]). The former
specify which asset classes are assigned to each function and how those assets will be
identified and labelled. The latter define what information the contractors must supply to CRL for
each asset of that class beyond the generic attributes [CRL-4] required for all assets. CRL will
then pass along this information to the future owners and operators.
CRL is assessing options for how to supply asset information to the operators and maintainers of
Crossrail. One option was presented at Fiatech last year as illustrated below [CRL-5]:
Specific, system generated spread sheets are being used to transfer information to/from Tier 1/2
Contractors. CRL is discussing options for linear assets with the various stakeholder
organizations.
3.11.2 Tube Lines

Tube Lines owns and operates three of the subway (tube) lines in London. They are developing
Asset Capture Forms (447). Assets are grouped together based on the type of information
stored for each. There is a single spread sheet design for each group. All of the information
about an individual asset occupies a single row in the appropriate Tube Lines 447 spread sheet.
As evidenced by the TLF-447 spread sheet [TL-1], Tube Lines has already realized the need for
locating components by linear referencing. Their asset spread sheets include columns for LCS
coded sections, start and end chainage (distances along based on a chainage LRM), and start
and end offset. They are currently assessing what would be the best LRM for their data
suppliers as well as for their asset management system (see Appendix B).

Tube Lines has also already tried to address the C/I classification problem (Problem 9:
Classifications). They have developed an extension to the Uniclass classification system to
address rail [TL-2].
3.11.3 Highways Agency

The UK Highways Agency is the Executive Agency of the Department for Transport (DfT) that is
responsible for operating, maintaining and improving the strategic road network in England on
behalf of the Secretary of State for Transport.
The Highways Agency has published a comprehensive list of contract pay items, based on their
Method of Measurement for Highway Works (MMHW) [HA-1]. This certainly could be the basis
for classification of C/I roadway entities.
The Highways Agency has established an Approved Network of their highways, segmenting
them into Sections based on uniform criteria [HA-2]. Offsets are defined using Cross Section
Positions (XSPs).
The agency’s Asset Data Management Manual Provider Requirements (ADMM) “sets out the
Provider’s mandatory deliverables to achieve the Employer’s asset data management
outcomes.” [HA-3]. For example, Appendix E covers Carriageway Inventory Assets:
Carriageway Inventory Assets refer to those assets that appear on or alongside the
carriageway excluding structures, drainage and geotechnical assets. The IAM IS is the
master data set for Carriageway Inventory Assets inventory, construction and condition
data.
Appendix E specifies that point Carriageway Inventory Assets are located by geospatial point
location (XY) and linear referencing (section, chainage, and XSP). Polygon assets are located
similarly, where the point is the centroid of the polygon asset. Linear assets are located using
linear referencing (section, start and end chainage, and XSP).
Appendix E then lists the types of Carriageway Inventory Assets and provides a list of
characteristics about each asset type. These include whether it is a point or continuous (linear)
asset, whether an XSP offset is required, whether geographical coordinates are required,
whether it is contiguous, replaceable or exclusive, and whether it can have multiple disparate
locations.
[HA-4] has a complete list of asset types and the information about each that is kept in IAM IS.

3.12 Problem 12: Software Products

If COBie is to be an information exchange file for transferring information from a contractor to a
facility owner (asset manager), then the contractor, or designer before him, must have software
that can automatically generate the COBie file (Export to COBie). The possibility of doing this
manually has already been discussed in Problem 1: COBie Spread Sheet Format where it was
determined that this would be most feasible with a more user-friendly software front end to the
COBie file. Similarly, the owner must have software that can automatically read the file and
ingest its content into the owner’s asset management system (Import from COBie).
3.12.2 Discussion
Several software products successfully completed the January 2012 COBie Design Challenge
for Architectural Design and Coordinated Design by automatically populating a COBie workbook
from design drawings, a 3D model, and related business data [NIBS-10]. These products were
specific to buildings as was all of the data. Many building design software packages already
support IFCs, so the mapping to COBie is relatively straightforward.
A separate FM Challenge was held in March 2012 to test whether any asset management
software was able to read and make sense out of the data contained in the spread sheets.
At that time C/I facilities were outside of the scope of both of the challenges, both from a read
and write perspective.
Once the necessary COBie C/I augmentation is defined and validated by the interviewed
stakeholders, then work on the demonstration use cases can proceed. Eventually future COBie
Challenges could be held to determine how successful the proposed changes are and how well
C/I design/construction and asset management software can read and write the new files.

4 Use Cases
4.1 Introduction
Five use cases (UC 1-UC 5) are proposed to demonstrate the feasibility of using COBie for
Civil/Infrastructure (C/I) projects. They have been selected and ordered so as to incrementally
build on the COBie 20 spread sheet workbook with minimal impact on the structure vs. its
content (attributes and pick lists vs. new spread sheets or columns).
The five use cases proposed are:
UC 1: As-Is COBie
UC 2: Geospatial Location
UC 3: Linear Location
UC 4: Linear Identity and Attribution
UC 5: Asset-oriented COBie
Problem 3: COBie Standard applies across all use cases, as it is equally difficult to understand
what the standard requires in addressing any of these cases. Similarly, Problem 12: Software
Products also applies across all use cases, though the selected software packages may differ
by use case, since some favour road (UC 4) over rail (UC 1,UC 3, UC 5) or GIS (UC 2) over
CADD (UC 1, UC 3, UC 4, UC 5). The road / rail split would also hold for Problem 11: Client
Requirements though both road and rail stakeholders expressed many similar concerns.

4.2 Use Case – Problem Mappings
UC 4: Linear Identity and Attribution
UC 5: Asset-oriented COBie
UC 2: Geospatial Location
UC 3: Linear Location
UC 1: As-Is COBie
P1: COBie Spread Sheet Format X

P2: COBie Schema X
P3: COBie Standard X X X X X
P4: Component Geospatial Location X
P5: Component Linear Location X
P6: Continuous Objects X
P7: Variable Asset Values X
P8: IFCs X X
P9: Classifications X X
P10: Schedules X
P11: Client Requirements X X X X X
P12: Software Products X X X X X

4.3 Use Case Descriptions

4.3.1 UC 1: As-Is COBie
A C/I tube (subway) station is quite similar to a building so it is used as the first use case. UC 1:
As-Is COBie includes various COMPONENTS contained in the SPACES on various FLOORS within a
station FACILITY, all supported by the existing COBie structure. Only COMPONENTS contained in
SPACES (vs. geospatial or linear locations) will be included and they will all be discrete (vs.
continuous) COMPONENTS.
Though no changes to the list of spread sheets are required, some content changes on some of
the sheets are proposed. For example, the PICKLIST classifications for Categories-Facility, etc.,
need to be expanded to support C/I. No changes to support an asset management view are
included in this first use case (see UC 5: Asset-oriented COBie), but we should be able to
demonstrate how an asset management view (asset tag / equipment / serialization) could be
derived from the existing TYPE and COMPONENT specification.
From the resultant spread sheets, it will be possible to witness the scattered content identified as
Problem 1: COBie Spread Sheet Format. The recommendation to try XML would also be
delayed until UC 5: Asset-oriented COBie.
UC 1: As-Is COBie will also provide input for solving Problem 8: IFCs and Problem 9:
Classifications because of the current absence of IFCs and classification schemes for railway
facilities.
The outcome focussed on a mapping of Crossrail AIMS sheets into COBie.
Figure 4: Expansion of the Crossrail diagram to include Types, Systems and Locations

• Key ideas
o COBie structure is near universal, but terminology varies
o Component->System->category generalises AssetTag->Functional-category
o Component->Type->category generalises AssetTag->Product-category
o Component->Space->Region/Floor->Facility generalises AssetTag->Location
o Component->Assembly->Component generalises AssetTag->Functional Unit
• Suggested changes and implementaiton agreements

o Accept Region as synonym for Floor
o Accept Location as synonym for Space
o Accept Uniclass Tables G/H
until Uniclass2 SS acceptable for example incorporating CRL functional
breakdown
o Accept Uniclass Table L
until Uniclass2 PR acceptable
o Include CRL AD4 sheets into BimTaskGroup Demand Matrix and Template
publication
Detail
(a) CRL ‘Summary’ sheet identifies Components

a. CRL ‘Tag Code’ field identifies Component name
b. CRL ‘Name’ field taken as description
c. Component ‘TagNumber’ field holds the text of the CRL white label
d. CRL ‘Function’ field identifies a System
i. ’ System 1’ appended to System name
ii. System is given the category code
e. CRL ‘Class’ field identifies Type
i. Type name and category set
ii. ’ Type A’ appended to Type name
iii. Type category determines IFC object and IFC type object
iv. Attribute ‘ObjectType’ is set to ‘class’
f. CRL ‘Location’ identifies Space Floor and Building name and description
i. ‘XRL’ and ‘Crossrail’ used as Facility (Project, Site,) name and
description
(b) CRL ‘Assets’ and ‘Functional Unit’ sheets create Assemblies
i. CRL ‘Functional Unit’ and ‘Asset Tag’ are Components
(c) Attributes
a. Ownership
i. CRL ‘Responsibilities’ sheet fields are used were given
ii. Default values used elsewhere
b. Except where used above, all attributes are mapped into property sets from
i. General sheets
ii. ‘Class’ Specific AD4 sheets

4.3.2 UC 2: Geospatial Location

The buildings-oriented spatial structure hierarchy does not apply to most C/I projects. Most C/I
COMPONENTS are located either within geospatial coordinates or features or along linear entities.
UC 2: Geospatial Location proposes adopting the Problem 4: COMPONENT Geospatial
Location recommendations. For geospatial point coordinate location specification,
COORDINATES can be expanded to apply to COMPONENTS. For geospatial feature locations, the
SPACE column (renamed to LOCATION) in the COMPONENT spread sheet can be used to
accommodate geospatial locations. The geospatial locations will then be entered into the SPACE
spread sheet (renamed to LOCATION). The EXTSYSTEM, EXTOBJECT and EXTIDENTIFIER columns
in the SPACE/LOCATION spread sheet will reflect the geospatial database or GIS from which the
geospatial feature geometry/location can be obtained.
Figure 5: Use case 2 test case
Figure 6: Selected assets with a 60m grid overlaid

• Key ideas
o Facility has a Lat, Long, Elevation, TrueNorth and other attributes
o Region/Floor is located relative to the Facility
o Location/Space is located relative to the Region/Floor
o Facility, Region/Floor, Space/Location CRS is named Coordinates
o Component have Coordinates located relative to a Space/Location
o Components are then located cartesian bottom left and top right Coordinates
• Suggested changes and implementation agreement

o Give CRS as the name of a Coordinate assigned to a Facility, Region/Floor,
Space/Location?
o Components or Coordinates AssetIntentifer field or ExtIdentifier field can be a
GIS key
Implementation (Provisional)
Figure 7: Facility

Figure 8: Coordinate sheet with both Cartesian space and GIS referencing

4.3.3 UC 3: Linear Location

UC 3: Linear Location proposes to capture linear entities (called linear elements in ISO 19148)
which can be used to linearly locate COMPONENTS. For example, London Underground has
established LCS codes to identify stations and the tunnels connecting them. Assets along the
track (in the tunnel) can then be located using a chainage Linear Referencing Method (LRM) to
specify the distance along (and possibly laterally offset from) the LCS-specified tunnel centerline
linear elements.
Similarly, the UK Highways Agency has established highway Sections as linear elements.
Assets along the highway are located using a chainage LRM with XSP offsets to specify the
distance along (and possibly laterally offset from) the Section linear elements.
UC 3: Linear Location will implement the short term recommendations from Problem 5:
COMPONENT Linear Location which proposes to specify linear elements in the SPACE spread
sheet (renamed to LOCATION). The SPACE column in the Component spread sheet (renamed to
LOCATION) would then refer to this LOCATION. Additional columns in the COMPONENT spread
sheet to accommodate the linearly referenced locations include DISTANCEALONG1, OFFSET1,
DISTANCEALONG2, OFFSET2 and WIDTH. It also proposes to specify linear element referents and
LRMs (such as chainage) in separate documents outside of COBie but which will be registered
in the DOCUMENTS spread sheet and attached to the FACILITY. Finally, a FACILITY ATTRIBUTE for a
facility-wide default LRM for locating COMPONENTS in that FACILITY and an overriding linear
element LOCATION ATTRIBUTE default LRM will be added.
• Key ideas
o LRM is pseudo-orthogonal
• Suggested changes and implementation agreement

o Accept that orthogonal coordiates in COBie may be in bent space ?
o Components AssetIntentifer field or ExtIdentifier field can be a GIS key
4.3.4 UC 4: Linear Identity and Attribution

UC 4: Linear Identity and Attribution further extends the role of linear referencing in two
respects. First, it can help solve the “continuous” entity problem common to many C/I projects.
Things like roads and rail have no agreed upon limits, like discrete building objects such as
doors and windows. In order to define an individual COMPONENT or asset as a part of a linear
entity, then, it is necessary to establish a start and an end. This can be achieved by specifying a
start and end location along a reference linear entity. For example, you can define a section of
track as a COMPONENT or asset by giving its start and end chainage location along an LCS-
specified tunnel centerline or a section of roadway by giving its start and end reference post
location along I-95 or the M-1.
Once continuous entities are discretized into individual COMPONENTS or assets, it becomes
necessary to deal with their attribution. Again, unlike doors and windows, linear entity attributes
can change in value along the length of the linear entity. Each section of I-95 defined above, for
example, may have different speed limits, depending on where you are along this section of
road. The extents of each speed limit value can be defined by specifying the start and end
location of each speed limit zone using linearly referenced locations along the roadway section.
In addition to the proposed COBie changes in UC 3: Linear Location, UC 4: Linear Identity
and Attribution requires the addition of columns to the COBie COORDINATE spread sheet.
A sampling of Highways Agency asset types [HA-4] will be used to demonstrate this proposed
COBie augmentations.

UC 4: Linear Identity and Attribution will demonstrate the recommended solutions contained
in both Problem 6: Continuous Objects and Problem 7: Variable Asset Values. It will also
provide input for solving Problem 8: IFCs, Problem 9: Classifications and Problem 10:
Schedules because of the current absence of IFCs, classification schemes, and schedules for
roadway facilities.
4.3.5 UC 5: Asset-oriented COBie

All of the above use cases assume that the content of the COBie workbook is based on a design
or construction view of the information. If an asset management perspective is adopted,
whereby asset managers are involved early in the design and construction process, then it
would be appropriate to introduce the dichotomy of asset requirement vs. fulfillment of that
requirement as espoused by CRL.
It appears that all of the CRL asset tag / equipment / serialization / functional unit information
already exists in TYPE, COMPONENT, SYSTEM and ASSEMBLY. It is just not organized as asset
requirements and fulfillment of those requirements.
UC 5: Asset-oriented COBie revisits the tube (subway) station from UC 1: As-Is COBie, but
proposes possible changes to the COBie schema to support an asset management view based
on the recommendations in Problem 2: COBie Schema.
Before proceeding with this use case, it will be necessary to study the full impact of using COBie
for several data drops throughout the facility life-cycle and not just for the construction to
operations handover.
• Key ideas
o Both ‘Asset tags’ and ‘Installed Equipment’ are Components
o Both ‘Asset class’ and ‘Equipment’ are Types
o Component->Assembly->Component generalises ‘Asset tag’->’Installed
Equipment’
• Suggested changes and implementation agreements

o Use ElementType Attribute to distinguish ‘Asset Tag’ Types and ‘Equipment’
Types

o Use ObjectType Attribute to distinguish ‘Asset Tag’ Components and ‘Installed

Equipment’ Components.
o Extend the Types AssetType fixed/moveable field enumeration to distinguish
requirement/fixed/exchangable/moveable assets.
o If known, give ‘asset tag’ Components an Attribute ‘SatisfyingTypes’ listing valid
‘Equipment’ Types.
Detail
CRL ‘Installed equipment’ and ‘Equipment’ sheet identifies Components

a. CRL ‘Equipment Number’ and ‘Serial fields identifies Component name
b. Attribute ‘ObjectType’ is set to ‘installation’
c. CRL ‘Serial/Batch’ field is held in the Component SerialNumber
d. Component TagNumber holds the text of the CRL yellow label
e. CRL ‘Equipment Number’ field identifies Type name
i. Attribute ‘ObjectType’ is set to ‘equipment’
ii. CRL ‘Manufacturer Code’ and ‘Model’ are held on the Type
Manufacturer and ModelReference fields
iii. CRL ‘Equipment Class’ field identifies Type category
iv. Type category determines IFC object and IFC type object
v. Attribute ‘ObjectType’ is set to ‘class’
f. The ‘Equipment’ Component is Assembled to satisfy an ‘Asset Tag’ Component
i. The ‘Asset Tag’ Component has Attribute ‘SatisfyingTypes’ listing
potential equipment Types.

5 Conclusions: C/I information exchange

5.1 Problem Identification
Once all of these problems and recommendations are debated and the total impact is assessed,
it would be appropriate to step back and decide whether or not it makes sense to use COBie as-
is for C/I information exchange. The two extreme views that have been voiced are:
1. COBie is flexible enough that it can handle C/I projects without any changes and
therefore no changes beyond 2.4 are planned [NIBS-7], versus
2. COBie was designed and developed specifically for buildings and since C/I
projects are very different, they need their own solution [USACE-2].
A middle view says that it may be feasible to enhance COBie within its currently published
flexibility to extend applicability and improve effectiveness and usability for C/I projects.
5.2 Discussion
It should be clear from this report that COBie did not address the unique requirements presented
by C/I facilities. If necessary changes are found that move COBie beyond version 2.4, then
iteration will need to be made, leading to a formal proposal to NBIMs, currently formalising
COBie 2.4. Considering the identified problems with COBie and the uncertainties surrounding its
future, a strategy would be to hold off on immediate demonstration development. Instead, focus
would be on developing a fuller conceptual model that would better support all types of
construction as well as asset management and thus define the desired end state. It would then
be possible to develop a roadmap to get to this desired end state incrementally over time. This
option has risks. It may be more difficult to achieve consensus on the proper direction without
having demonstrated the problems with the current COBie approach and the viability of the
recommended solutions.
A better solution might be to retain the COBie approach and all of its strengths. The
recommended solutions can be prioritized and the use case driven demonstration of some of
them can begin immediately. This would elucidate the current gaps in the COBie solution and
provide an opportunity to test out some of the assumptions made herein in support of the short
term recommendations. It would provide a learning experience regarding what needs to be
done with C/I software products to make them IM-ready. This option is not without risk.
Hopefully the recommendations offered herein will not prove to be tangential to where the
industry decides to go in the long term.
5.3 Recommendation
It is recommended that
(1) this report be reviewed by as wide an audience of potential stakeholders as possible. A
revised report can then be generated from their feedback.
(2) Use case studies can be undertaken to illustrate the current capability. The use cases
need to be prioritized so that work can begin on developing use case demonstrations.
(3) C/I software products can then be assessed with respect to their ability to write the
augmented content.
(4) Concurrent with this, work can begin on the longer term effort of creating a fuller
conceptual model that would better support all types of construction as well as asset
management and thus define the desired end state. It would then be possible to
develop a roadmap to get to this desired end state incrementally over time, taking
advantage of IFC and ISO 15926 developments.

6 References
[bSI-1] Grobler, Francois, buildingSMART to develop open standards for
infrastructure, buildingSMART International, Ltd., October 1, 2012,
http://www.buildingsmart.org/news/buildingsmart-to-develop-open-
standards-for-infrastructure (cited 19-Apr-2013).
[bSI-2] Hyvärinen, Juha, buildingSMART MVD for LandXML v1.2, buildingSMART
International, Ltd., October 1, 2012.
[CRL-1] Schwarzenbach, J., CR-STD-015 Asset Identification Standard, v 1.1,
Crossrail Limited, October 28, 2011.
[CRL-2] Schwarzenbach, J., Asset Data Dictionary Definition Document AD4): BSR
– Building Structures, Crossrail Limited, v 1.0, June 11, 2012.
[CRL-3] Schwarzenbach, J., Asset Data Dictionary Definition Document AD4):
L7171 – Pumps, v 1.0, Crossrail Limited, November 9, 2012.
[CRL-4] Houghton, M., Asset Data Dictionary Definition Document AD4): L0 –
Generic Attributes, v 1.0, Crossrail Limited, January 30, 2013.
[CRL-5] Pawsey, N., Crossrail Data Interoperability Strategy
(BIM/ISO15926 Harmonization), Crossrail Limited, Fiatech presentation,
San Diego, 2012.
[HA-1] Highways Agency, Manual Of Contract Documents For Highway Works:
Volume 4 Section 3: Library Of Standard Item Descriptions For Highway
Works, UK Highways Agency, March, 1998,
http://www.dft.gov.uk/ha/standards/mchw/vol4/index.htm (cited 22-Apr-
2013).
[HA-2] Highways Agency, Highways Agency Network Management Manual Part 2 –
Asset Management Records, version 1, UK Highways Agency Asset
Management Office, July 2009,
http://www.dft.gov.uk/ha/standards/nmm_rwsc/docs/nmm_part_2.pdf (cited
22-Apr-2013).
[HA-3] Highways Agency, Asset Data Management Manual ASC Area 2 Provider
Requirements, edition 1, Version 1.4, UK Highways Agency Asset
Management Office, October 2012.
[HA-4] Highways Agency, IAM IS Inventory Specification (AMO), UK Highways
Agency Asset Management Office, undated.
[HMG-1] HMGovernment, “Building Information Modeling: The Digital Plan of Work &
Assemblies”, v 7.1, HMGovernment, March 5, 2013.
[HMG-2] HMG BIM Task Group, “COBie UK 2012”, BIM Task Group,
HMGovernment, 2013, http://www.bimtaskgroup.org/cobie-uk-2012/ (cited
14-Apr-2013).
[HMG-3] HMG BIM Task Group, “Frequently Asked Questions”, BIM Task Group,
HMGovernment, 2013, http://www.bimtaskgroup.org/bim-faqs/ (cited 20-
Apr-2013).
[IAM-1] The Institute of Asset Management, Asset Management – an anatomy,
version 1.1, February 2012 (cited 28-Mar-2013)
[ISO-1] ISO 16739:2013, Industry Foundation Classes (IFC) for data sharing in the
construction and facility management industries, International Organization
for Standardization, Geneva, 2012.
[ISO-2] ISO IS 19148:2012, Geographic information — Linear referencing,
International Organization for Standardization, Geneva, 2012.

[ISO-3] ISO 15926, Industrial automation systems and integration -- Integration of

life-cycle data for process plants including oil and gas production facilities,
Parts 2, 4, 7, 8, International Organization for Standardization, Geneva,
2003-2011.
[NIBS-1] East, E. William (2012) "Construction-Operations Building information
exchange (COBie)," buildingSMART alliance, National Institute of Building
Sciences, Washington, DC.
http://www.buildingsmartalliance.org/index.php/projects/activeprojects/25
(cited 14-Apr-2013).
[NIBS-2] National Institute of Building Sciences buildingSMART alliance,
“Construction Operations Building Information Exchange – Version 2.26”,
National BIM Standard – United States Version 2, 2012,
http://www.nationalbimstandard.org/nbims-us-v2/chapter.php?id=20 (cited
4-Mar-2013).
[NIBS-3] East, E. William, “Construction Operations Building Information Exchange
(COBie)”, Whole Building Design Guide, National Institute of Building
Sciences buildingSMART alliance, February 8, 2013,
http://www.wbdg.org/resources/cobie.php (cited 24-Feb-2013).
[NIBS-4] East, Bill and Tim Chipman, Facilities Management Handover, National
Institute of Building Sciences buildingSMART alliance, December 29, 2011,
http://www.buildingsmartalliance.org/docs/BSADOC_COBIE/index.htm
(cited 4-Mar-2013).
[NIBS-5] East, E. William, Love, Danielle, Bogen, Chris, Nisbet, Nicholas (2011)
COBie Responsibility Matrix, v13, August 25, 2011,
http://projects.buildingsmartalliance.org/files/?artifact_id=4093 (cited 27-
Feb-2013)
[NIBS-6] East, Bill and Mariangelica Carrasquillo-Mangual, The COBie Guide: a
commentary to the NBIMS-US COBie standard, National Institute of
Building Sciences buildingSMART alliance, October 1, 2012,
http://buildingsmartalliance.org/index.php/projects/cobieguide/ (cited 25-
Feb-2013).
[NIBS-7] Nisbet, Nicholas and William East, “Construction Operations Building
Information Exchange (COBie): Version 2.40 Update”, National Institute of
Building Sciences buildingSMART alliance, 2012,
http://www.buildingsmartalliance.org/index.php/projects/cobiev24 (cited 13-
Apr-2013).
[NIBS-8] East, E. William, “Common Building Information Model Files and Tools”,
National Institute of Building Sciences buildingSMART alliance, 2012,
http://buildingsmartalliance.org/index.php/projects/commonbimfiles/ (cited
14-Apr-2013).
[NIBS-9] East, Bill, “COBieLite: A lightweight XML format for COBie data”, National
Institute of Building Sciences buildingSMART alliance, 2012,
http://buildingsmartalliance.org/index.php/projects/cobielite/ (cited 16-Apr-
2013).
[NIBS-10] East, Bill, “buildingSMART alliance January 2013 Challenge”, National
Institute of Building Sciences buildingSMART alliance, 2012,
http://buildingsmartalliance.org/index.php/newsevents/proceedings/buildings
martchallenge13/ (cited 1-May-2013).
[PXS-1] Scarponcini, Paul, COBie 2.4 UML Physical Model, Draft Version 0.1, March
1, 2013.
[PXS-2] Scarponcini, Paul, “Generalized Model for Linear Referencing in
Transportation,” Geoinformatica, March 2002.
[PXS-3] Scarponcini, Paul, COBie for Civil/Infrastructure Requirements, Draft Version
0.2, May 10, 2013.
[TL-1] Tube Lines, TLF-447, version 8, 2013, (cited 19-Mar-2013).

[TL-2] Tube Lines, Computer Aided Design Level Coding and Methodology,
November 2012.
[USACE-1] East, E. William, Construction Operations Building Information Exchange
(COBIE) - Requirements Definition and Pilot Implementation Standard, U.S.
Army Corps of Engineers, August 2007,
http://www.wbdg.org/pdfs/erdc_cerl_tr0730.pdf (cited 4-Mar-2013).
[USACE-2] East, Bill, “Rooms and COBie Data”, LinkedIn COBie Discussion Group,
July 14, 2013.

7 Appendix A – COBieLite Extract

COBieLite XML document extraction – Clinic Challenge
<?xml version="1.0" encoding="UTF-8"?>

<cob:Facility xmlns:cob="cobielite.cobie.erdc.org">
<cob:FacilityName>PN 0001</cob:FacilityName>
<cob:FacilityCategory>11-13 24 14: Clinic</cob:FacilityCategory>
<cob:ProjectAssignment cob:externalEntityName="IfcProject" cob:externalID="3eM8WbY_59RR5TDWry5aRV"
cob:externalSystemName="Autodesk Revit Architecture 2011"/>
<cob:SiteAssignment cob:externalEntityName="IfcSite" cob:externalID="3eM8WbY_59RR5TDWry5aRT"
cob:externalSystemName="Autodesk Revit Architecture 2011"/>
<cob:FacilityDefaultMeasurementStandard>Autodesk Revit Architecture 2011 BIM Area</cob:FacilityDefaultMeasurementStandard>
<cob:FacilityDescription>Medical-Dental Clinic</cob:FacilityDescription>
<cob:FacilityDeliverablePhaseName>Handover</cob:FacilityDeliverablePhaseName>
<cob:Floors>
<cob:Floor cob:externalEntityName="IfcBuildingStorey" cob:externalID="3eM8WbY_59RR5TDWs3wwJP"
cob:externalSystemName="Autodesk Revit Architecture 2011">
<cob:FloorName>First Floor</cob:FloorName>
<cob:FloorCategory>Floor</cob:FloorCategory>
<cob:FloorDescription>First Floor</cob:FloorDescription>
<cob:FloorElevationValue>
<cob:DecimalValue>0.0</cob:DecimalValue>
</cob:FloorElevationValue>
<cob:FloorHeightValue>
</cob:FloorHeightValue>
<cob:Spaces>
<cob:Space cob:externalEntityName="IfcSpace" cob:externalID="0ztdC3L1HAzhbhMHypqcZz"
cob:externalSystemName="Autodesk Revit Architecture 2011">
<cob:SpaceName>1A01</cob:SpaceName>
<cob:SpaceCategory>13-11 11 31: Reception Space</cob:SpaceCategory>
<cob:SpaceDescription>PATIENT ADMIN. RECEPT.</cob:SpaceDescription>
<cob:SpaceSignageName>n/a</cob:SpaceSignageName>
<cob:SpaceUsableHeightValue>
</cob:SpaceUsableHeightValue>
<cob:SpaceGrossAreaValue>
</cob:SpaceGrossAreaValue>
<cob:SpaceNetAreaValue>
</cob:SpaceNetAreaValue>
<cob:ZoneAssignments>
<cob:ZoneAssignment>
<cob:ZoneName>Administration</cob:ZoneName>
</cob:ZoneAssignment>
</cob:ZoneAssignments>
<cob:Attributes>
<cob:Attribute cob:externalEntityName="n/a" cob:externalID="n/a" cob:externalSystemName="n/a"
cob:propertySetExternalIdentifier="n/a" cob:propertySetName="n/a">
<cob:AttributeName>FloorColor</cob:AttributeName>
<cob:AttributeDescription>Clinic_076-078_Finish Schedule</cob:AttributeDescription>
<cob:AttributeCategory>Requirement</cob:AttributeCategory>
<cob:AttributeValue>
<cob:AttributeStringValue>
<cob:StringValue>INTERFACE - CARIBBEAN #3080 ANTIQUA</cob:StringValue>
</cob:AttributeStringValue>
</cob:AttributeValue>
<cob:Issues/>
</cob:Attribute>
</cob:Attributes>
<cob:Documents/>
<cob:Issues/>
</cob:Space>
<cob:Zones>
<cob:Zone cob:externalEntityName="IfcPropertySingleValue" cob:externalID="n/a" cob:externalSystemName="n/a">
<cob:ZoneName>Administration</cob:ZoneName>
<cob:ZoneCategory>Occupancy Zone</cob:ZoneCategory>
<cob:ZoneDescription>Administration Department</cob:ZoneDescription>
<cob:Attributes/>
<cob:Documents/>
<cob:Issues/>
</cob:Zone>

<cob:AssetTypes>
<cob:AssetType cob:externalEntityName="IfcCondenserType" cob:externalID="n/a" cob:externalSystemName="n/a">
<cob:AssetTypeName>AC Unit Type 1</cob:AssetTypeName>
<cob:AssetTypeCategory>23-75 10 24 21 27: Unitary Air Conditioning Equipment</cob:AssetTypeCategory>
<cob:AssetTypeDescription>Horiz. D.X. Fan Coil</cob:AssetTypeDescription>
<cob:AssetTypeModelNumber>PC24EK1</cob:AssetTypeModelNumber>
<cob:AssetTypeReplacementCostValue/>
<cob:AssetTypeExpectedLifeValue/>
<cob:AssetTypeNominalLength/>
<cob:AssetTypeNominalWidth/>
<cob:AssetTypeNominalHeight/>
<cob:AssetTypeAccessibilityText>n/a</cob:AssetTypeAccessibilityText>
<cob:AssetTypeCodePerformance>n/a</cob:AssetTypeCodePerformance>
<cob:AssetTypeColorCode>n/a</cob:AssetTypeColorCode>
<cob:AssetTypeConstituentsDescription>n/a</cob:AssetTypeConstituentsDescription>
<cob:AssetTypeFeaturesDescription>n/a</cob:AssetTypeFeaturesDescription>
<cob:AssetTypeFinishDescription>n/a</cob:AssetTypeFinishDescription>
<cob:AssetTypeGradeDescription>n/a</cob:AssetTypeGradeDescription>
<cob:AssetTypeMaterialDescription>n/a</cob:AssetTypeMaterialDescription>
<cob:AssetTypeShapeDescription>n/a</cob:AssetTypeShapeDescription>
<cob:AssetTypeSizeDescription>n/a</cob:AssetTypeSizeDescription>
<cob:AssetTypeSustainabilityPerformanceDescription>n/a</cob:AssetTypeSustainabilityPerformanceDescription>
<cob:Assets>
<cob:Asset cob:externalEntityName="IfcEnergyConversionDevice" cob:externalID="n/a" cob:externalSystemName="n/a">
<cob:AssetName>AC Unit Type 1 AC-1</cob:AssetName>
<cob:AssetDescription>AC Unit</cob:AssetDescription>
<cob:AssetSerialNumber>YNC54980</cob:AssetSerialNumber>
<cob:AssetInstallationDate>2011-04-22</cob:AssetInstallationDate>
<cob:AssetWarrantyStartDate>2011-04-22</cob:AssetWarrantyStartDate>
<cob:AssetTagNumber>n/a</cob:AssetTagNumber>
<cob:AssetBarCode>n/a</cob:AssetBarCode>
<cob:AssetIdentifier>n/a</cob:AssetIdentifier>
<cob:AssetLocationDescription>AC Unit</cob:AssetLocationDescription>
<cob:SpaceAssignments>
<cob:SpaceAssignment>
<cob:FloorName>First Floor</cob:FloorName>
<cob:SpaceName>1B21</cob:SpaceName>
</cob:SpaceAssignment>
</cob:SpaceAssignments>
<cob:SystemAssignments>
<cob:SystemAssignment>
<cob:SystemName>HVAC System</cob:SystemName>
<cob:SystemCategory>21-51 51 16: Air Distribution</cob:SystemCategory>
</cob:SystemAssignment>
</cob:SystemAssignments>
<cob:Attributes>
<cob:Attribute cob:externalEntityName="n/a" cob:externalID="n/a" cob:externalSystemName="n/a"
cob:propertySetExternalIdentifier="n/a" cob:propertySetName="n/a">
<cob:AttributeName>Frequency</cob:AttributeName>
<cob:AttributeDescription>Clinic_245_HVACSChedules.PDF A.C. Unit Schedule, Column 12
</cob:AttributeDescription>
<cob:AttributeCategory>Requirement</cob:AttributeCategory>
<cob:AttributeValue>
<cob:AttributeDecimalValue>
<cob:UnitName>Hertz</cob:UnitName>
</cob:AttributeDecimalValue>
</cob:AttributeValue>
<cob:Issues/>
</cob:Attribute>
</cob:Attributes>
<cob:Documents>
<cob:Document cob:externalEntityName="n/a" cob:externalID="n/a" cob:externalSystemName="n/a">
<cob:DocumentName>Field Test Report-Air Handling Units-Equipment Tests AH1-
3</cob:DocumentName>
<cob:DocumentCategory>Test Reports</cob:DocumentCategory>
<cob:DocumentDescription>n/a</cob:DocumentDescription>
<cob:DocumentURI>documentV2-SD-09-AirHandlingUnits-EquipmentTests AH1-
3.pdf</cob:DocumentURI>
<cob:DocumentReferenceURI>01 20 01.00 10</cob:DocumentReferenceURI>
<cob:Attributes/>
<cob:Issues/>
</cob:Document>
</cob:Documents>
<cob:Issues/>
</cob:Asset>

<cob:Systems>
<cob:System cob:externalEntityName="n/a" cob:externalID="n/a" cob:externalSystemName="n/a">
<cob:SystemName>Direct Digital Control System</cob:SystemName>
<cob:SystemCategory>21-81 61 62 21: HVAC Measurement and Control Equipment</cob:SystemCategory>
<cob:SystemDescription>Direct Digital Control System Overall</cob:SystemDescription>
<cob:Attributes/>
<cob:Documents>
<cob:DocumentName>Direct Digital Control System Description</cob:DocumentName>
<cob:DocumentCategory>Design Data</cob:DocumentCategory>
<cob:DocumentURI>documentV4-SD-03-DDCS.pdf</cob:DocumentURI>
<cob:DocumentReferenceURI>01 78 23</cob:DocumentReferenceURI>
<cob:Attributes/>
<cob:Issues/>
</cob:Document>
</cob:Documents>
<cob:Issues/>
</cob:System>
<cob:Contacts>
<cob:Contact cob:externalEntityName="n/a" cob:externalID="n/a" cob:externalSystemName="n/a">
<cob:ContactEmail>bill.east@us.army.mil</cob:ContactEmail>
<cob:ContactCompanyName>Engineer Research and Development Center</cob:ContactCompanyName>
<cob:ContactPhoneNumber>217.352-6511</cob:ContactPhoneNumber>
<cob:ContactDepartmentName>n/a</cob:ContactDepartmentName>
<cob:ContactGivenName>Bill</cob:ContactGivenName>
<cob:ContactFamilyName>East</cob:ContactFamilyName>
<cob:ContactStreet>2902 Newmark Dr.</cob:ContactStreet>
<cob:ContactPostalBoxNumber>PO Box 9005</cob:ContactPostalBoxNumber>
<cob:ContactTownName>2902 Newmark Dr.</cob:ContactTownName>
<cob:ContactRegionCode>IL</cob:ContactRegionCode>
<cob:ContactCountryName>USA</cob:ContactCountryName>
<cob:ContactPostalCode>61826</cob:ContactPostalCode>
<cob:ContactURL>n/a</cob:ContactURL>
<cob:Attributes/>
<cob:Documents/>
<cob:Issues/>
</cob:Contact>
<cob:Documents>
<cob:DocumentName>Basis of Design</cob:DocumentName>
<cob:DocumentCategory>Design Data</cob:DocumentCategory>
<cob:DocumentURI>documentV1-SD-05-BasisOfDesign-OCR.pdf</cob:DocumentURI>
<cob:DocumentReferenceURI>01 11 00</cob:DocumentReferenceURI>
<cob:Attributes/>
<cob:Issues/>
</cob:Document>

8 Appendix B – Linear Referencing

ISO 19148 defines linear referencing as the “specification of a location relative to a linear
element as a measurement along (and optionally offset from) that element” [ISO-2]. The ISO
standard is based on the Generalized Model for Linear Referencing. The Generalized Model
has been well documented [e.g., PXS-2] and widely discussed because of its acceptance in a
dozen software standards.
There are numerous disparate methods of specifying a linearly referenced location. The
Generalized Model captures the essential concepts found in these various approaches. By
viewing any of these approaches from this generalized context, it enables the translation of
locations from one to another, rather than dictating that everyone use the same method.
The basic premise of the Generalized Model is that a linearly referenced location can be
specified by:
– the linear element being measured (e.g., Alignment, Route)
– the Linear Referencing Method (LRM) used (e.g., stationing, chainage,
reference post, percentage)
– the measured value as a “distance along” the linear element
– optional offsets (lateral, vertical, vector) from the distance along location
Following this specification allows for the simple linear interpolation transformation between
linearly referenced locations based on differing linear elements and/or LRMs. These
transformations are closed, commutative, and transitive.
Linear elements (LE) can be features (e.g., a particular road), 1-dimensional geometries, or
topological directed edges. LRMs can be absolute (measure from the start of the LE), relative
(measure from some known location (a mile, kilometer, or reference post), or interpolative (e.g.,
percentage of the overall LE length). These two things provide the context for the measured
value: you need to know if a measured value of .50 is one half mile from the start of Route 66 or
half of the way to the end of the route.
Rather than constrain COBie to support a specific linear referencing approach (linear element
type and LRM), the Generalized Model approach is proposed. It is helpful to look at some of the
approaches used by the interviewed stakeholders to see how they can be viewed from the
Generalized Model view.
Consider a hypothetical tube line called the Eastern Line. It passes through Waterloo Station
(LCS Level 1 Code = E007) on its way to London Bridge Station (E009). Waterloo Station is 20
km from the start of the Eastern Line, London Bridge is 22.
One way to specify the linear referenced location of Waterloo Station would be (“Eastern Line”,
“chainage”, 20000) where “Eastern Line” is the linear element along which measurement is
made, “chainage” is the LRM which says that measurements are made in meters from the
beginning of the linear element, and 20000 is the distance along the Eastern Line from its
beginning to Waterloo Station, measured in meters. London Bridge would be (“Eastern Line”,
“chainage”, 22000).

Looking closer, it becomes apparent that the stations themselves have length of track:
The ramp at Waterloo Station is 500 meters long, London Bridge is 400. It is now possible to
treat these as linear elements. Waterloo Station would be the LCS coded section “E007-E-
EBLO” linear element, where “E0007” is the LCS Level 1 Code for station, “E” is the LCS Level 2
Code for the Eastern line, and “EBLO” is the LCS Level 3 Code for the EastBound LOcal
road/route. The eastbound local track between the stations would be linear element “E008-E-
EBLO”.
It is now possible to specify linearly referenced locations along “E008-E-EBLO”. If a chainage
LRM is again chosen, a linear referenced location specified as (“E008-E-EBLO”, “chainage”,
100) would be 100 meters along the track between these two stations measured from the start
of this track section (i.e., the end of the Waterloo Station ramp).
The contractor who is constructing just this local section of the Eastern line might specify an
asset (e.g., signal) location as (“E008-E-EBLO”, “chainage”, 100) or even as (“E008-E-EBLO”,
“metric stationing”, 0+100). The eventual owner of the Eastern Line might prefer to see this
same location as a linearly referenced location along the Eastern Line instead of the more local
LCS coded section.
To accomplish this, the LCS coded sections first need to be located along the Eastern Line”:
LCS coded linear element LRM from distance to distance

section
E007‐E‐EBLO EASTERN LINE chainage 20000 20500
It is now easy to see that the signal that was located by the contractor as (“E008-E-EBLO”,
“chainage”, 100) would be located by the owner as an equivalent (“EASTERN LINE”, “chainage”,
20600).
The possible methods of specifying this location is limitless because of the flexibility of linear
element and LRM. As long as they are all specified using the Generalized Model, it is easy to
translate between them. In the COBie proposal, EASTERN LINE would be a row in the
LOCATION (formerly SPACE) spread sheet. Each LCS coded section would be rows in the
COMPONENT spread sheet having a LOCATIONNAME of EASTERN LINE and having from and to
distance along measures specifying their limits along the Eastern Line. The LCS coded sections
would also be rows in the LOCATION spread sheet. The contractor could enter the signal as a
COMPONENT with a LOCATIONNAME equal to the LCS coded section and a from distance along as
the chainage measure from the start of the localized LCS coded section. When the owner reads
the COBie file, he could transform this localized linear location to the absolute measure along
the Eastern Line.
A totally different approach using a “relative” type of LRM is being investigated by Tube Lines.
With a relative type of LRM, distance along measures are made from a known location (referent)
along the linear element, instead of absolutely from the beginning of the linear element.
Milepost, kilometer post, and reference post are examples. A linear referenced location of
(“Track1”, “kilometer post”, 6+.500) signifies a location 500 meters beyond kilometer post 6
along Track1. If all kiloposts are exactly one kilometer apart, this is equivalent to the absolute
linear referenced location (“Track1”, “chainage”, 6500).
Due to reconstructions, posts are typically not equidistant over time and are more properly called
reference posts. They are handled in a similar fashion but it is necessary to know a priori the
exact location of each of these posts. The location be specified as an absolute distance from
the linear element start or as a relative distance from the previous post. The latter choice
minimizes changes due to local construction-caused changes in the alignment length.
The Tube Lines proposal being considered is to make the start point of each LCS coded section
above an Eastern Line referent from which relative measures can be made. The referent
locations would be defined as in the Table below.
Referent location
Linear Element Referent Linear
LRM distanceAlong
Element
EASTERN LINE E007‐E‐EBLO EASTERN LINE chainage 20000
relative
EASTERN LINE E008‐E‐EBLO EASTERN LINE chainage E007‐E‐EBLO + 500
relative
EASTERN LINE E009‐E‐EBLO EASTERN LINE chainage E008‐E‐EBLO + 1500
Now the signal location can be specified as (“EASTERN LINE”, “relative chainage”, “E008‐E‐
EBLO + 100”), or 100 meters beyond the start of E008-E-EBLO. Since E008-E-EBLO is 500
meters beyond E007-E-EBLO, which is at absolute 20000, then the signal location once again is
20000+500+100=20600 from the start of the Eastern Line.

Buildings Civil Infrastructure

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Buildings Civil Infrastructure

Uploaded by

Copyright:

Available Formats

COBie for All

Required Information for Facility Ownership

Buildings & Civil/Infrastructure

Date Version Lead Author

Status: DRAFT Public Release for Comment

Please comment at www.bimtaskgroup.org/comments.

1 v1.3 October 2013

2 v1.3 October 2013

3 v1.3 October 2013

Authors & Acknowledgements

However the principal authors of this work were

Julian Schwarzenbach Crossrail

4 v1.3 October 2013

‘’Will COBie Work for Infrastructure?’’

Chairman BIM Task Group

5 v1.3 October 2013

6 v1.3 October 2013

Figure A Generic COBie Data Structure (Entity - Relationship Diagram)

7 v1.3 October 2013

Figure 1: The COBie data structure (buildings)

Figure 2: Possible COBie synonyms for C/I

8 v1.3 October 2013

1 unless we accept “Building” as a verb rather than a noun

2.2 About This Report

10 v1.3 October 2013

STEP Standard for the Exchange of Product model data

12 v1.3 October 2013

1..* 1..* +resourceNames

Design::Floor Design::Type #typeName Build::

#spaceNames 1..* #componentNames 1..*

(from COBie2.4) (from COBie2.4)

Common::Impact Common::Issue Common::Connection

14 v1.3 October 2013

15 v1.3 October 2013

3.1 Problem 1: COBie Spread Sheet Format

16 v1.3 October 2013

3.2 Problem 2: COBie Schema

18 v1.3 October 2013

3.2.2.2 Asset View

19 v1.3 October 2013

20 v1.3 October 2013

21 v1.3 October 2013

3.3 Problem 3: COBie Versions

23 v1.3 October 2013

3.4 Problem 4: COMPONENT Geospatial Location

3.4.2.1 Existing Spatial Hierarchy

24 v1.3 October 2013

3.4.2.3 Geospatial Coordinates

3.4.2.4 Geospatial Feature Location

25 v1.3 October 2013

Optional columns are ROOMTAG, USEABLEHEIGHT, GROSSAREA, NETAREA, EXTSYSTEM,

26 v1.3 October 2013

3.5 Problem 5: COMPONENT Linear Location

27 v1.3 October 2013

28 v1.3 October 2013

If the SPACE spread sheet is generalized to LOCATION, as is proposed above for

29 v1.3 October 2013

2. These columns would support the definition of a COMPONENT OR SPACE/LOCATION

Figure 3: Coordinates expanded to offer actual and/or LRM

30 v1.3 October 2013

3.6 Problem 6: Continuous Objects

31 v1.3 October 2013

3.7 Problem 7: Variable Asset Values