COBie and the common language (FM3222)
Anthony Neal – Autodesk
Learning Objectives
At the end of this class, you will be able to:




Understand the importance of common language classification within BIM to provide earlier
and more accurate cost modelling as well as the value in data integration with asset
management systems.
Understand what COBie is and its value to owner operators.
Learn how to output a COBie spreadsheet with a common language classification from
Revit.
We will also examine the importance of classification for data integration between the
building model and asset management systems such as Maximo.
About the Speaker
Anthony is a solution architect within the Autodesk consulting practice. His background is
principally GIS and has been key to the successful delivery of enterprise Infrastructure GIS
solutions for the past 17 years within Utilities military and government at Autodesk and
GeoVision*. Having worked for most of his career with infrastructure outside the building
Anthony has now stepped inside the building with BIM and can see many parallels between the
“I” in GIS and the “I” in BIM. Having last year architected a successful BIM/GIS Integration at
Heathrow airport is now engaged with one of the world’s largest AEC companies to drive
efficiencies into the operate and maintain part of the their business through Autodesk solutions.
Introduction
With so many nuances and differences within our human language providing a common naming
and meaning to the things in our built environment is not straightforward. Even within the same
language we have differences, what I call a tap my cousins in America call a Faucet. The
advent of BIM and particularly the “I” in BIM has meant if we want to join our Building
Information with the rest of our business process and systems we need to be talking a common
language classification when referring to the “things” in our buildings. This lecture will examine
the Omniclass and Uniclass classification systems and why they are important to owner
operators when receiving COBie information at handover. You will also learn about the COBie
exchange format and its value to Owner Operators and why a classification system for the
assets included in this data rich model are important. Attendees will get to see the latest COBie
export tool from Revit.
Insert Class Title as per Title Page
Common language
George Bernard Shaw was an Irish playwright and political activist who interestingly was a cofounder of the London school of Economics. He said England and America are 2 countries
separated by a common language. There are several examples of this some which are quite
amusing. However one I came across recently was a reference to a Faucet which actually
comes from the French and originally Latin. I thought they were most probably referring to a tap
but I know that most English speakers outside the US would not have worked this out. So can
you see from this extreme example how even with human intelligence there is confusion in our
so called common language.
One of the benefits of BIM is the ability to make use of the I, analyse it and integrate it with other
systems and process to get harness the value from it, if we don’t do this it just remains a pretty
3D graphical model. To get value from the I in BIM it is necessary to have a common language.
This common language is required to operate on two levels: a) at a human level and b) at a
machine level. Human communication demands a universal language comprising standard
naming conventions to facilitate consistency and mitigate against the risk of misinterpretation. In
other words no matter who in the design team is defining an asset the same, consistent
terminology and unique identifier will be utilized. This strategic approach will have direct benefits
for communication between software systems which similarly will require a common file
structure to allow data from one system to be read by another.
Inconsistent language
You can see in figure 1 our humble fan coil unit named in 4 different ways in our asset
management system because on each of our projects they were specified in different ways.
This problem can also happen within a build where sub contractors haven’t followed the naming
specification, one didn’t exist or they ignored it. You may as well be talking about an apple a
sheep, Spain and a Tiger as far as the system is concerned. Unless we get into the database
and cleanse the data to make it consistent we have no way of grouping the data up so that we
can supply performance information. For example what is the failure rate within the first 90 days
on our new builds for fan coil units grouped by manufacturer and model. Querying this data
becomes more difficult if not impossible because it’s not stored consistently.
2
Insert Class Title as per Title Page
Figure 1 Inconsistent Fan Coil Unit
The need for classification in the AEC owner operator world
Projects need the participants to create, communicate and find relevant information at the
appropriate time. The larger the scale of the project, and the greater the number of participants,
the more essential it becomes to use methods and systems able to handle the associated
complexities of information exchange. Classifying information in a consistent way, agreed by all
participants, facilitates clear communication of intent and reduces the incident of
misunderstanding, conflict, and wasted resources – this is particularly important in the
construction industry because the parties involved usually change from project to project. In
essence, classification simply means the grouping together of like things according to some
common quality or characteristic. This automatically implies the separation of the unlike. In
order to be able to classify a collection of subjects it is at first necessary to define the purpose of
the classification. Then the properties of interest to the classification may be distinguished, and
finally the subjects can be sorted into classes with regard to the chosen properties.
(Natspec: Information classification systems and the Australian construction industry2008)
3
Insert Class Title as per Title Page
Classification systems
Coming from the UK the system I am most familiar with is Uniclass, however I will also focus on
the Omniclass classification system which is prevalent throughout the US.
Figure 2 Omniclass Uniclass
Uniclass (UK)
The most recent construction information classification system to be implemented in the UK is
Uniclass (Unified Classification for the Construction Industry). Uniclass notation consists of a
single capital letter followed by zero or more digits, except Tables J and K, which
have two initial capital letters to allow the incorporation of the CAWS and CESMM3 codes.
Uniclass 1 which was first published in 1997 and incorporates a number of existing systems as
follows:
• CAWS (Common Arrangement of Work Sections for building works), developed in 1987, was
adopted by the National Building Specification (NBS), the Standard Method of Measurement of
Building Works (SMM7), and the National Engineering Specification (NES). Until recently CAWS
formed the basis of Uniclass Table J Work sections for buildings.
• CESMM3 (Civil Engineering Standard Method of Measurement) forms the basis of Uniclass
Table K Work sections for civil engineering works.
4
Insert Class Title as per Title Page
• EPIC (European Product Information Cooperation) Construction Product Grouping (CPG) – or
EPIC for short, a common European classification system for construction products, was first
published in 1994. EPIC forms the basis of Uniclass Table L Construction products (Natspec)
(Natspec: Information classification systems and the Australian construction industry2008)
Issues with existing uniclass
Uniclass is currently undergoing a full scale overhaul as a result of a number of short comings in
the existing system which will be implemented as Uniclass 2
The scope of work for Uniclass 2 and issues with Uniclass 1 are documented on the CPIC
website http://www.cpic.org.uk/en/uniclass/






Scope – some Tables cover architecture (buildings and landscape) and civil and process engineering, but
others only deal with one or two of these sectors – Table F only covers architectural spaces for example, and
Table K only covers work sections for civil engineering (though some of these overlap with those in Table J).
Coding – most Tables use numeric coding below Level 1, but two use alpha-numeric coding (Tables J and
K). Most respect the ‘limit of ten’, but some use double figures at some levels on an ad hoc basis (e.g. Tables
F and L).
Depth – depth of the Tables is not consistent – some Tables comprise seven levels (Tables D, L and M), one
(Table K) has just two, for example.
Object placement – Tables J and K place the objects they are classifying at the same (lowest) level
throughout, but the other Tables may place objects at any of two to five levels. That is, in some Tables a given
level may be used both for groups of objects and for individual objects.
Granularity – in some Tables the lowest level objects differ markedly in ‘scale’, in others they are more
consistent. For example, in Table D oil refineries (D165 3) and signal boxes (D116 1) are classed as ‘facilities’
with no further subdivision.
Alignment – the tables do not align completely because they were independently developed. Component
products do not clearly map to their elements.
http://www.cpic.org.uk/en/uniclass/
Take a look at this lovely visualization to get an understanding of how the new and improved
Uniclass 2 will work. http://www.bimgateway.co.uk/uclass2/indent/
Omniclass (US)
The most recent construction information classification system to be implemented in North
America is Omniclass. A group of volunteers from organisations and firms representing a broad
cross - section of the construction industry recognised a need for classifying construction
subjects, the increased use of electronic information technology, and the expanding focus on
the complete life cycle of construction. The majority of the 15 Omniclass Tables were published
in 2006. Omniclass freely adapted and used Uniclass in its development, and therefore shares
many of the Uniclass legacy documents – for example, both use EPIC as the basis of their
construction product Tables. The most significant points of departure include:
5
Insert Class Title as per Title Page
• The adoption of Masterformat as the basis of Omniclass Table 22 Work results. In the same
way CAWS is used in the UK, Masterformat is the pre-eminent means of organising commercial
and institutional construction specifications, such as Masterspec, in North America. It is
published in by the Construction Specifications Institute (CSI) and Construction Specifications
Canada (CSC). The most recent edition was published in 2004.
• The adoption of Uniformat as the basis of Omniclass Table 21 Elements (including designed
elements). Uniformat provides a standard method of arranging construction information,
organised around the physical parts of a facility called systems and assemblies. These systems
are characterised by their function without identifying the technical or design solutions that may
comprise them. It is used for formatting documents on project scope, quality, cost and time,
such as cost estimates or reports Omniclass notation consists of numerical codes, generally of
six digits. These can be extended by adding more digits after a decimal point. The notation is
hierarchical. (Natspec)
(Natspec: Information classification systems and the Australian construction industry2008)
Consistent language
The illustration below shows the common language classification that we should have used for
our Fan coil unit.
Figure 3 Consistent Fan Coil Unit
6
Insert Class Title as per Title Page
COBie
The Construction-Operations Building information exchange (COBie) format is the international
standard for the exchange of information about managed facility assets. COBie does not add
new requirements to contracts; it simply changes the format of existing deliverables from paper
documents and proprietary formats, to an open, international standard format.
(The COBie Guide: a commentary to the NBIMS-US COBie standard by Dr. Bill East and
Mariangelica Carrasquillo-Mangual)
The COBie Process
The process of creating COBie deliverables follows the same processes used in today’s design
and construction. COBie simply transforms the information provided in paper documents into
information that can be re-used through the project. The figure below summarizes the COBie
process.
Figure 4 COBie process
During early design, Architects develop the spaces and groups of spaces needed to support the
activities required by the owner program brief. This information is delivered through the
Schematic Design drawings. COBie delivers the subset of the Schematic Design information
related to spaces, zoning, and “room data sheets.” Schematic Design stage COBie information
is used to verify that the facility being designed meets the owner’s program brief. Since COBie
is an extract from the Schematic Design deliverables, the information in COBie data files must
match. the information about spaces and architectural products and schedules found on Schematic
Design submittal.
7
Insert Class Title as per Title Page
As the design nears completion, Engineers design the systems that deliver the required
services, such as electricity, water, appropriate temperature, fire protection, security, etc… to
allow the activities to take place. This information is delivered at the Construction Documents
design stage. In addition to the updated architectural information, COBie delivers the subset of
the Construction Documents information related to the product and equipment assets that will
ultimately be managed by the owner. This asset information is found in the design drawing’s
equipment and product schedules. Since COBie is an extract from the Construction Documents
Design deliverables, the information in COBie should be a perfect match for the printed on the
drawings from that deliverable. During construction, the generic asset information found in the
Construction Documents stage is filled-in to provide the COBie construction deliverables. A
COBie submittal prior to Beneficial Occupancy allows the facility manager to begin efficiently
operating their facility upon occupancy. A COBie As-Built submittal is also provided to reflect all
final changes and as-built conditions. During construction this information is linked from other
sources such as documents containing approved submittals, warranty certificates, etc… As a
result construction information may be gleaned directly from electronic submittal records. Other
information, documenting the specific installation and testing of equipment, includes some
specific information such as serial number and installation dates for every major building asset.
The resulting data set is no more, or no less, than a set of Operations and Maintenance
Manuals that can actually be used by operations, maintenance, and asset management
personnel. Following the delivery of facility asset, maintenance and operations information the
owner will load this information directly into their COBie compatible maintenance management
system and immediately begin the efficient operation of that facility. Updates to COBie data
resulting from work orders should be documented directly in next-generation maintenance
management systems. Results of renovations simply update that subset of existing COBie data
with the changes coming from the renovation project.
(The COBie Guide: a commentary to the NBIMS-US COBie standard by Dr. Bill East and
Mariangelica Carrasquillo-Mangual)
8
Insert Class Title as per Title Page
COBie deliverables (Drops)
COBie deliverables as they are referred to in the US implementation of COBie increase in
content over time to reflect the increasing maturation of the design or completion of the
construction project.
Drop 1 (Concept design /Requirements)
Very basic information for example just the functionality of a space. So each space classified by
functional type, required performances for finishes, just basic stuff really.
Drop 2 (tendering)
List of furniture and assets for each space/room. You should be able to generate a schedule at
this stage for very approximate costings. Schedule of AHUs which would give us the numbers of
AHU’s which would help us derive an approximate cost for operating those pieces of kit even
though we don’t have the detail at this stage.
Drop 3 (Construction) 70% - 80% complete
This will have more info than the previous drop, this would now have more attributive
information for each asset class as information and building finishes as well as more detailed
information
Drop 4 Full O&M
This is the golden drop which should have full manufacturer / model information along with
detailed operational and functional information. Links to O&M manuals. Warranties, everything
complete.
9
Insert Class Title as per Title Page
Figure 5 COBie drops/deliverables
COBie data structure
COBie when materialized as a spreadsheet consists of one worksheet for each informational
type as per figure 6. I know spreadsheets are not the best way of transmitting data between
systems however you must agree that the coloured coding on individual sheets does get
peoples buy in from a human understanding level which you could never do with a boring UML
diagram. So don’t think spreadsheet when you think COBie just think of what a great database
schema and structure it provides for carrying this information.
10
Insert Class Title as per Title Page
Figure 6 COBie spreadsheet
COBie to asset management
The key to BIM is not the graphical model, but the database of information that sits behind it.
This enables different organisations working on the same project but using different software to
store and retrieve information in a consistent, shareable format. Good database design needs to
look at the output first and reverse engineer in order to provide all the required fields for FM and
asset management. Understand what you need in your FM asset management world and
specify it in your protocols, BIM execution plans, contracts, QA/QC procedures.
This video is somewhat close to the Nirvana we are trying to achieve.
http://labs.autodesk.com/utilities/revit_maximo
The video (produced by Autodesk Labs as a Maximo Integration for Autodesk Revit) details the
process of exporting data from a Revit model to Maximo. Richly attributed data about building
assets, that are developed in Revit during the building design and construction phases, can be
published directly into Maximo during commissioning or at building "handover," thus supporting
more immediate and efficient use of Maximo once the building is occupied. The Revit asset data
can be exported in the COBie data specification, if desired. In addition, the BIM/3D asset data
can be viewed inside Maximo, in context with Maximo applications and processes.
11
Insert Class Title as per Title Page
The benefits include smoother building handover with the automated data transfer and linking
into Maximo. In addition, by having more accurate asset and location data within the Maximo
database and providing access to the visual BIM model while processing work orders within
Maximo, the amount of time planning and executing work may be reduced and real cost
This integration only works if the Building information transitioning into asset management is
consistent every time. Common language classification and naming is the essential building
block for this to happen. BIM faces the same cultural, organisational and technological hurdles
to those that often hamper the introduction of collaborative approaches. Owners, designers,
contractors and supply chains need to be committed to the idea from the outset, and they need
the appropriate knowledge, processes, tools and infrastructure to help them collaborate
electronically. To be enable to realise the full benefits of BIM, a ‘Common Language’ is needed
for all to understand and to follow in order that the information in the database can be stored,
retrieved and used successfully.
The value of common language
Consistency Interoperability (Between systems)
Because the input data is in a consistent format and the output format is also consistent it we
can automate BIM into other business systems. The data model is consistent and how we refer
to an object in one system is the same way we refer to it in another. The Space/Room in my
BIM model has the same classification, naming and numbering as I use in my lease
management system. So when a new retail space is at as-built on a specific floor with a specific
classified usage type, when the data is translated it slots straights into my lease management
system without any data munging/fixing because the common language naming convention has
been established between both systems.
Performance information feedback
With this linkage between the information model of the building with its operational model within
the asset management system we can then start to provide feedback to the building
modelers/designer as to performance. For example as an MEP designers I need to place a
number of “Direct Expansion Air Handling units that are split cooling that we are potentially
operating and maintaining for 30 years once built. The Omniclass code for that rather excitingly
12
Insert Class Title as per Title Page
is 23-33 17 13 11 Air source split system heat pumps. Wouldn’t it be great if I could easily mine
my asset management system to give me performance information on the heat pumps we
currently have in commision at all our other facilities. This is not a pipe dream, because as long
as our systems (Our building models and our asset management system have the same
consistent numbering naming then it’s just a case of data linkage to provide that report)
Long lead
Identifying long lead items especially for the untrained eye is critical. The definition of a "Long
Lead" item is any piece of kit that is required to be engaged in the project with a procurement
time that is likely to affect the completion date.
Getting visibility on these long lead items as early in the project as possible is important. We
don’t know the manufacturer of our Chiller or even what type but if we have a basic
classification at the early stage (COBie drop 1 or 2) we some visibility of cost. If we can’t
consistently identify or more importantly our systems can’t identify what that thing is with a
consistent naming convention then we are shooting in the dark. Planned maintenance regimes
can be costed earlier in the lifecycle if we know what these objects are consistently.
Consistently identify assets
With classification even if you have no clue what the object is by looking at the
Omniclass/Uniclass code will give you that consistent definition and naming of that building
object. More importantly a system process can now link the consistent name of that component
with its consistent name in the asset management system and for that matter any other system.
Further with older more experienced employees retiring and outsourced work force it’s important
for a human to be able to easily identify an object without ambiguity.
Data “Munging”
Munging is my term for “converting”. Munging is what we do when we take some data from an
outside source and try to make it fit our data schema; normally this takes the form of converting
from one format to another. But in our case its more than that because we have to maybe infer
some of the information values are infer what some of the objects are. The quality of this data at
the end could be suspect as we have had to make assumptions. Munging data like this for every
project is also a cost that really multiplies up over multiple projects. So demand a common
language from the supply chain (Using a standard such as OmniClass UniClass or Natspec)
and demand a common schema from the supply chain which is COBie.
13