OMNICLASS vs. UNICLASS / UNICLASS2 – BIM Ontology

OmniClass™ Work Results: a critique (source: NBS.com)

It has been suggested by some that, rather than developing or implementing Uniclass2, we in the UK should switch to OmniClass, used in North America. John Gelder, Head of content development and sustainability, takes a critical look at the OmniClass Work Results Table, comparing it throughout with the Uniclass2 Work Results Table.

OmniClass is the North American equivalent of Uniclass2 and is promulgated by CSI (Construction Specifications Institute) and CSC (Construction Specifications Canada).

Broadly speaking OmniClass is in a similar position to Uniclass 1997, with much the same general limitations, though it is rather more unified. Uniclass articles corresponding to this one include Reclassification and The new Uniclass Work sections table. For a review of OmniClass in general, refer to the separate article OmniClass: a critique.

Scope

Like Uniclass Table J (aka CAWS), the OmniClass Work Results Table (aka MasterFormat) is geared mostly to the specification of systems and products, and so is focused on the construction phase. It doesn’t serve the whole project timeline, as it doesn’t have homes for high-level (early-stage) objects such as Complexes, Activities and Elements. This means that the Table can’t properly serve design-build and design-build-operate procurement (which, in the latter case, typically requires the contractor to be involved from the very beginning of the project, as part of a consortium). Other Tables within OmniClass must be used to structure specifications for Entities, Spaces and Elements. Tables outside OmniClass must be used for other object classes. These would then need to map to each other and to the Work Results Table, in order to properly integrate the specification component of the building information model (BIM) along the project timeline. Given the lack of congruence, this won’t be easy.

The Uniclass2 Work Results Table has homes for objects of all classes from Regions down to Products, so can fully serve the project timeline, and all procurement routes. See Table 5.*

Even mapping between systems and products is problematic because, read with the non-OmniClass SectionFormat, there are no homes for System outline (or compositional) specifications. Indeed, Systems and Products are conflated. This means that the Work Results Table, plus SectionFormat, can’t properly serve BIM, which requires mapping between objects of different classes in the object hierarchy (e.g. this product is part of that system, this system comprises those products). Making this explicit in the specification requires outline specifications. We can’t rely on this mapping being delivered through the geometrical part of BIM (CAD) since many systems and products are not modelled geometrically at all.

The Uniclass2 Work Results Structure Table provides for outline (compositional) specifications all down the object hierarchy, including Systems-to-Products, so fully supports BIM. Table 5 illustrates this (left-hand column).

Table 5: OmniClass and Unclass2 Work Results Tables – scope

Item OmniClass Table 22 Work Results 2011 & SectionFormat 2008 Uniclass2 Work Results Table & Work Results Structure Table
Project management Division 00 Procurement and contracting requirements + Division 01 General requirements Group 00 Project management + Management Table
Region outline Not included Group 02 Regions + Regions Table
Region performance
District outline Group 04 Districts + Districts Table
District performance
Complex outline Group 06 Complexes + Complexes Table
Complex performance
Entity outline Group 08 Entities + Entities Table
Entity performance
Activity outline Group 10 Activities + Activities Table
Activity performance
Space outline Group 12 Spaces + Spaces Table
Space performance
Element outline Group 14 Elements + Elements Table
Element performance
System outline System sections: System outline subsection + Systems Table
System performance Work sections: SF Products subsection System sections: System performance subsection
Products System sections: Products subsection + Products Table
Custom-made products System sections: Custom-made products subsection
Execution Work sections: SF Execution subsection System sections: Execution subsection
System completion Sub-group XX 08 00 Commissioning System sections: System completion subsection
System FM Sub-group XX 01 00 Maintenance System sections: System FM subsection

SectionFormat has a home for the specification of performance and design criteria of products, which in turn are defined as including systems, assemblies, manufactured units, equipment, components, product types and materials. That is, SectionFormat doesn’t really distinguish between products, systems and materials, though OmniClass at large does (in the Products, Work Results and Materials Tables). ‘Performance’ at a higher level was in sub-group 01 80 00 Performance requirements in the 2004 edition of this Table, but this has been dropped in the 2011 edition. As it was actually mostly about elements rather than systems (e.g. 01 83 16 Exterior enclosure performance requirements), the idea is probably that this is specified using a specification aligned to the Elements Table.

The Uniclass2 Work Results Structure Table provides for performance specification of objects all down the object hierarchy, so fully supports contractor (and other) design. It also makes a clear distinction between Elements, Systems and Products (and so on) – this is essential for a rational approach to hierarchical object modelling. Table 5 illustrates this (left-hand column).

In the OmniClass Work Results Table, the commissioning and maintenance of systems (elements, actually) are not described in the system sections, but in separate sections in sub-groups 08 and 01 of each group, respectively, e.g. sub-group 09-08-00 Commissioning of finishes and section 09-01-70 Maintenance of wall finishes (see Table 6). This is rather inconvenient for those wanting to have everything about a given system collected together (though of course this could be managed through reporting in a digital specification tool such as NBS Create).

All aspects of each system, from design to operation, are collected in each of the System sections in the Uniclass2 Work Results Structure Table. Table 5 illustrates this (right-hand column).

Sequence

The general sequence of sections within each Group doesn’t fully reflect construction sequence. For example, operation and maintenance should be last, and commissioning should be second-last, but this isn’t the structure at all. All of this is held in sections that precede those describing the thing yet to be designed and built. See Table 6.

The System section structure in the Uniclass2 Work Results Structure Table fully reflects construction sequence. See Table 5 (right-hand column).

Table 6: OmniClass Work Results Table – section sequence

Fabric example Services example
08-00-00 Openings 23-00-00 Heating, ventilating and air conditioning (HVAC)
• 08-01-00 Operation and maintenance of openings • 23-01-00 Operation and maintenance of HVAC systems
• 08-05-00 Common work results for openings • 23-05-00 Common work results for HVAC
• 08-06-00 Schedules for openings • 23-06-00 Schedules for HVAC
Not used • 23-07-00 HVAC insulation
• 08-08-00 Commissioning of openings • 23-08-00 Commissioning of HVAC
Not used • 23-09-00 Instrumentation and control for HVAC
08-10-00 Doors and frames 23-10-00 Facility fuel systems
Not used 23-20-00 HVAC piping and pumps
08-30-00 Specialty doors and frames 23-30-00 HVAC air distribution
08-40-00 Entrances, storefronts and curtain walls 23-40-00 HVAC air cleaning devices
08-50-00 Windows 23-50-00 Central heating equipment
08-60-00 Roof windows and skylights 23-60-00 Central cooling equipment
08-70-00 Hardware 23-70-00 Central HVAC equipment
08-80-00 Glazing 23-80-00 Decentralized HVAC equipment
08-90-00 Louvers and vents Not used
Conclusion

The OmniClass Work Results Table has deficiencies, specifically with respect to serving the entire project timeline and all procurement routes, and supporting BIM. It has a construction phase focus, and so has no homes for the specification of high-level objects such as Complexes, so it can’t deal with early project stages. System operation and maintenance specifications are isolated from descriptions of the systems themselves, so it doesn’t serve the occupancy phase as well as it might. Together this means that the Table is not well-suited to non-traditional modes of procurement, such as design-build and design-build-operate.

The Work Results Table conflates systems and products, and has no homes for outline or compositional specifications. Together these mean that the Table doesn’t support hierarchical object mapping, a key requirement for a BIM specification. This is exacerbated by the Table – and OmniClass as a whole – not supporting classification of high-level object classes and systems. Without these object classes we cannot produce a complete ‘building’ information model.

Finally, the basic design-build-operate sequence is not implemented fully in the Work Results Table, nor in SectionFormat (e.g. a proposed FM subsection has not eventuated; system-wide performance requirements are not distinguished from those for ‘mere’ products). This makes the default structure rather messy.

BIM requires a unified approach to classification if it is to work well, e.g. with simple mapping between classification Tables. OmniClass cannot deliver this, as it stands. Uniclass2 can.

* Note: Tables 1 to 4 are available in OmniClass™: a critique

via http://www.4Clicks.com – Leading cost estimating and efficient project delivery software software solutions for JOC, SABER, IDIQ, MATOC, SATOC, MACC, POCA, BOA, BOS … featuring and exclusively enhanced 400,000 line item RSMeans Cost Database, visual estimating / automatic quantity take off ( QTO), contract, project, and document mangement, all in one application.

When is BIM not BIM?

BIM, Building Information Modeling, actually consists of three M’s…. BIM3 if you will…  Modeling, Models, and Management.

Since the “accepted” definition of BIM is the life-cycle management of the built environment supported by digital technology, it’s easy to see that BIM is part process and part technology, with the goal of developing and using current, accurate, shared information to optimize proactive decision-making.

Unfortunately the AECO sector (Architecture, Engineering Construction, Operations) sector is currently “silo” and “first cost” centric, not to mention relatively technophobic.   Major culture change across all stakeholders must take place before BIM can be understood, let alone practiced, on a widespread basis.

Building Information Modeling: A BUSINESS PROCESS for generating and leveraging building data to design, construct and operate the built environment during its life-cycle.  Stakeholders  have access to accurate, shared information  on demand, enable via interoperability between technology platforms and common terms, definition, metrics and benchmarks.

Building Information Model: The DIGITAL REPRESENTATION of physical and functional characteristics of the built environment.  As such it serves as a shared knowledge resource for information about a facility, forming a reliable basis for decisions during its life-cycle from inception onwards.

Building Information Management: The strategic vision for ORGANIZATION, COLLABORATION, andCONTROL of the business process by utilizing principles and guidelines for Information  Architecture  (i.e.a digital prototype) to effect the sharing of trustworthy information over the entire life-cycle of a physical asset. The benefits include centralized and visual communication, early exploration of options, sustainability, efficient design, integration of disciplines, site control, as-built documentation, etc.– effectively managing the digital decision support model of an asset from conception to retrofitting to final retirement over the course of a century or more.

Thoughts? Comments?

BIMF - Building Information Management Frameworkvia http://www.4Clicks.com – Leading cost estimating and efficient project delivery software – JOC, SABER, MATOC, IDIQ, BOA, POCA, BOA … featuring exclusive 400,000+ RSMeans Cost Database, visual estimating, document management, project management.. all in one application.

Construction Disruption – BIM, Cloud Computing, and Efficient Project Delivery Methods

By Peter Cholakis
Published in the March 2013 issue of Today’s Facility Manager

Emergent disruptive technologies and construction delivery methods are altering both the culture and day-to-day practices of the construction, renovation, repair, and sustainability of the built environment. Meanwhile, a shifting economic and environmental landscape dictates significantly improved efficiencies relative to these facility related activities. This is especially important to any organization dependent upon its facilities and infrastructure to support and maintain its core mission.

The disruptive digital technologies of building information modeling (BIM) and cloud computing, combined with emergent collaborative construction delivery methods are poised to alter the status quo, ushering in increased levels of collaboration and transparency. A disruptive technology is one that alters the very fabric of a business process or way of life, displacing whatever previously stood in its place. BIM and cloud computing fit the profile of disruptive technologies, individually, and when combined these stand to create a tidal wave of change.

BIM is the life cycle management of the built environment, supported by digital technology. While a great deal of emphasis has been placed upon 3D visualization, this is just a component of BIM. The shift from a “first cost mentality” to a life cycle cost or total cost of ownership is a huge change for many. Improving decision making practices and applying standardized terms, metrics, and cost data can also prove challenging. An understanding and integration of the associated knowledge domains important to life cycle management is required, resulting in what is now being referred to as “big data.”

Cloud computing is also a disruptive technology, and it’s one that impacts several areas. The National Institute of Standards and Technology (NIST) definition of cloud computing is as follows, “Cloud computing is a model for enabling ubiquitous, convenient, on demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. The cloud model is composed of five essential characteristics, three service models, and four deployment models.”

It is perhaps helpful to define cloud computing in terms of its benefits. Cloud computing enables far greater levels of collaboration, transparency, and information access previously unavailable by traditional client/server, database, or even prior generation web applications. Multiple users can work on the same data set with anyone, anywhere, anytime, in multicurrency, multilanguage environments. All changes can be tracked to “who did what” within seconds (potentially the best form of security available), and information is never deleted.

The disruptive technologies of BIM and cloud computing will accelerate the adoption of emergent construction delivery methods and foster new frameworks. Design-bid-build, the traditional construction delivery method for decades, is inherently flawed. As a lowest bid deployment it immediately sets up adversarial relationships for involved parties. Owners prepare a solicitation for construction projects based on their understanding of them1, with or without third-party A/E assistance, and in most cases they go out in search of the lowest bidder. Then without a thorough understanding of the owner’s facility, bidders base their responses on the owner’s solicitation, plans, and specifications. Owners typically allow a period of time for bidders’ questions and clarifications; but the quality of this interchange is at best questionable if based solely on a written scope, plans and specifications, and/or a meeting with suppliers.

Design-build, arguably a step in right direction, falls short of bringing all stakeholders together. More responsibility of design and construction is shifted to the contractor and/or A/E. However, the dual level participation structure doesn’t assure the interests of all parties are equally addressed. Furthermore, the design-build process is typically reserved for major new construction projects versus the numerous sustainability, repair, renovation projects, and minor new construction projects typically encountered by facility managers (fms).

Because BIM brings together previously disparate information into a framework that enables decision support, using the technology requires a collaborative construction delivery method. The integration of the domain knowledge and robust processes required to allow fms, A/Es, and other stakeholders to achieve heightened levels of information sharing and collaboration is enabled by methods that include Integrated Project Delivery (IPD) and Job Order Contracting (JOC).

Key characteristics of these emergent construction delivery methods include: choices based on best value; some form of pricing transparency; early and ongoing information sharing among project stakeholders; appropriate distribution of risk; and some form of financial incentive to drive performance.

Both IPD and JOC allow, if not require, owner cost estimators and project managers to “partner” with contractors, subcontractors, and A/Es to conceptualize, create, cost, prioritize, start, and report upon projects—in the very early phases of construction.

IPD, JOC, and Simplified Acquisition of Base Civil Engineering Requirements (SABER)—the U.S. Air Force term for applying JOC practices—are practiced simultaneously by a growing number of organizations and supported by digital technologies. These construction delivery processes are embedded within software to allow for rapid, cost-effective, and consistent deployment as well as the associated level of collaboration and transparency.

BIM and cloud computing are disruptive technologies that will accelerate the adoption of emergent construction delivery methods such as IPD and JOC. Construction delivery methods set the tone and level of interaction among project participants and can be viewed as the management process framework. When supported by BIM and cloud computing, the life cycle management of the built environment, and the associated management of big data, can be expected to become commonplace for many construction projects.

1303 profdev a 150x150 Professional Development: Construction Disruption

Cholakis

Cholakis is chief marketing officer for 4Clicks Solutions, LLC, a Colorado Springs, CO provider of cost estimating and project management software. With expertise in facilities life cycle costs and total cost of ownership in various market segments, he is involved in numerous industry associations and committees including the American Society of Safety Engineers, Association for the Advancement of Cost Engineering, Society of American Military Engineers, BIM Library Committee-National Institute for Building Sciences (NIBS), and National Building Information Model Standard Project Committee.

1 “The Art of Thinking Outside the Box;” Vince Duobinis; 2008.

The Current Status of OMNICLASS – A Critical BIM Requirement

(source: OmniClass Development Committee Status Report – April 16, 2013)

To:        OmniClass Development Committee members
From:   Dianne Davis, OmniClass Development Committee Chair
Kelly Sawatzky, OmniClass Development Committee Vice Chair
Greg Ceton, OmniClass Secretariat

These OmniClass Status Reports will be issued every few months through this review cycle. They are
designed to keep you apprised of ongoing OmniClass development work and afford you the opportunity
to ask questions or get involved. The report is organized to give updates on the development work
being performed by the three Working Groups (WGs) that are each independently working on a
different area of OmniClass development.

We are just commencing the 2012-2014 review cycle. Generally speaking, WGs are just beginning to
identify review issues and set priorities for areas of work needed.

OmniClass Spaces WG (Lead: Alan Edgar)
(Table Responsibilities: 13 – Spaces by Function and 14 – Spaces by Form)
The Spaces WG is charged with reviewing Table 13 – Spaces by Function and Table 14 – Spaces by Form
to determine the nature of any development work needed to expand or modify Table 13 contents, to
provide a baseline review of Table 14, as it has not been reviewed in depth since its initial
publication in 2006, and to harmonize the work of other existing space classifications with the revised contents
of both Tables.  The Working Group has commenced review work on both Table 13 – Spaces by Function and Table 14 –
Spaces by Form.  Table 13 review has been focused on laboratory space organization to start. Additional review of
medical spaces is also anticipated.
Table 14 review has begun with comparison of form-based aspects of other classification systems,
including those used as references in the prior work on Table 14. Some simplification of the table
to address purely formal concerns may be needed.
If you would like to participate in review work on either of these tables or have any comments to
share, please send them to Spaces WG lead Alan Edgar at alan.edgar@rsparch.com and to Greg Ceton at
gceton@csinet.org

OmniClass Products WG (Lead: Robert Keady)
(Table Responsibilities: 23 – Products)
The Products WG is charged with examining the structure of Table 23 – Products and confirming that
the contents and organization support the needs of users.

Work has commenced with the examination of Table 23 – Products. The WG Lead, Robert Keady, has
started cross-referencing Table 23 with Tables 21 (Elements) and 22 (Work Results). Additionally,
there have been equipment additions (200 to date) proposed to Table 23. Currently there is an
effort being made to identify Work Group members who will focus on specialized areas for review
within Table 23. This review cycle, the Work Group will also be focusing on adding definitions for
Table 23 entries.
If you have any comments or resources to lend to this effort, please send them to Properties WG
Lead Robert Keady at robertkeady@hotmail.com and to Chris Gummo at cgummo@csinet.org
OmniClass Activities and Processes WG (Lead: Dianne Davis)

The Properties and Materials WG is charged with examining and revising content and organization of
Table 32 – Services, Table 35 – Tools, and Table 36 – Information in light of recent work on Table
31 – Phases, Table 33 – Disciplines, and Table 34 – Organizational Roles.

Work has commenced with the examination of Table 32 – Services. The WG has tapped Robert Keady,
CEM, CDSM, FMP for his specialized knowledge of tasks, and how they may be fit into the structure
of Table 32 while limiting the impact on the table as a whole. The group has agreed that any
changes to Tables 32 and 36 must be in response to intended or known table usage that currently not
being met. Adding content or improving the tables without reference to a real improved process will
not satisfactorily address the WG charge.
Definition creation and harmonization with existing OmniClass Tables and creation of transition
matrix for each reviewed table will be commenced further along in the review cycle.
Work on other tables will be initiated after the work on Table 32 – Services has progressed
further.
If you have any comments or resources to lend to this effort, please send them to Properties WG
Lead Dianne Davis at  d.davis@aecinfosystems.com and to Rob Holson at rholson@csinet.org

If the work of any of these Working Groups interests you, or you would like to participate
in their development work, please contact Greg Ceton at gceton@csinet.org

Building Information Management Framework – BIMF – People, Process, Technology

While at first perhaps a bit intimidating…  illustrating the life-cycle management within a BIM context is relatively straightforward.

BIM – Life-cycle Management Perspective

BIMF - Building Information Management Framework

 

The purpose of this Framework is to provide  a general guide that your team can quickly customize to your specific requirements.   Like a restaurant menu or a travel guide, you can visualize the resources available and decide on an appropriate strategic configuration of options.

Just begin in the Center and work thru this Action Agenda using, when available and appropriate, tested  processes and templates.   Using these guidelines, set up a BIM Management structure with your stakeholders.

 The Building Information Management Framework (BIMF) illustrates a how people, processes, and technology interact to support the built environment throughout its life-cycle.  Based upon the associated level of detail, an operating model can be developed to more efficiently identify,  prioritize, and meet the current and future needs of built environment stakeholders (Owners, AE’s, Contractors, Occupants, Oversight Groups…)

More specifically, modular, Model View Definitions (MVD), associated exchange specifications and common data architectures [for example: Industry Foundation Class (IFC), OMNICLASS] can  help to integrate multi-discipline Architecture, Engineering, Construction (AEC) “activities”,  “business processes”, “associated competencies” and “supporting technologies”  to meet overall requirements with a goal of continuous improvement.

WORK GROUP FORMATION – Roles and Relationships;

PROCESS MAP – who does what, in which sequence, and why;

EXCHANGE REQUIREMENTS & BASIC BUSINESS RULES – Overall guidelines for information integration

EXCHANGE REQUIREMENT MODELS – Specific information “maps”

GENERIC MODEL VIEW DEFINTION (MVD) – Strategic approach incorporating guidelines for information format, content, and use;

MODEL VIEW DEFINTION & IMPLEMENTATION SPECIFICATIONS   – Specific format, content, and use

PROJECT AGREEMENT REQUIREMENTS – LEVEL OF DEVELOPMENT (LOD) – Defined “project” deliverables

(Adapted from: IMPROVING THE ROBUSTNESS OF MODEL EXCHANGES USING PRODUCT MODELING ‘CONCEPTS’ FOR IFC SCHEMA –Manu Venugopal, Charles Eastman, Rafael Sacks, and Jochen Teizer – with ongoing assistance/input from NBIMS3.0 Terminology Subcommittee)

Model View Definitions (MVD) and associated exchange specifications, provide the best benefit if they are modular and reusable and developed from Industry Foundation Class (IFC) Product Modeling Concepts.   Model views and overall life-cycle management are similar in this regard.

Building Information Modeling (BIM) tools serving the Architecture, Engineering, Construction (AEC) span multiple  “activities”,  “business processes”, “associated competencies” and “supporting technologies”, and each may required different internal data model representation to suit each domain.  Data exchange is therefore a critical aspect.   Inter and intra domain standardized data architectures and associated adoption of matching robust processes are really the first step toward successfully managing the built environment.

The Process Side of BIM = Collaboration: People, Process, & Technology

Open BIM Standards – COBIE, OMNICLASS – IFC / COBIE Report 2012

BIM adoption remains a challenge due to the fact that its many supporters don’t focus upon it’s true relevance, the efficient life-cycle management of the built environment.

While any new technology has  barriers to adoption, changing the “status quo”, the fundamental nature of how a business sector does business requires a major event.   The cultural and process changes associated with BIM, namely the need for all stakeholders to collaborate, share information in a transparent manner, and share in risk/reward, remain chasms to be crossed by many/most.    Fortunately, those currently or previously involved with Integrated Project Delivery and Job Order Contracting (the latter a form of IPD specifically targeting renovation, repair, sustainability, and minor new construction) have experience with these “novel” business concepts.  Both IPD and JOC have proven track records and have clearly demonstrated the ability to get more work done on-time and on-budget to the benefit of all involved parties.

A key aspect of BIM, collaboration, can only be efficiently accomplished with a commonly understood and shared taxonomy including terms, definitions, and associated metrics.

So called “open BIM”, such as buildingSMART International’s Industry Foundation Classes (IFCs), are important to enabling collaboration as well as interoperability between BIM software applications.     COBie, a naming convention for facility spaces/components, etc., and its counterparts OMINCLASS, including MASTERFORMAT and UNIFORMAT,  etc. … can be leveraged and generated by IFC appears a goal worth additional focus on a local and global level.   That said, support for COBie, OMNICLASS, IFC, etc. varies and,  far from mainstream.

As noted in the IFC / COBIE Report 2012, BIM’s success depends upon the ability to:

  1. Create model data in a consistent format
  2. Exchange that data in a common language
  3. Interrogate the data intelligently.

There are multiple knowledge domains, technologies, and process involve in the life-cycle management of the built environment, all of which need a common data architecture, taxonomy, set of metrics, etc.

The IFC / COBIE Report 2012 correctly points out that pressing needs remain:

  1. The need for standards

  2. The need for guidance

  3. The need for enhanced IFC import export routines from BIM applications

  4. The need for agreed descriptions of who requires what data and when

  5. The need for an improved audit trail to allow greater confidence in collaboration.

Also, and I paraphrase / embellish…

  1. “Enforcement” of IFC by buildSmartalliance and all BIM “proponents”  is required.
  2. Domain experts must leveraged and queried to deliver structured data templates accordingly.  The industry needs well defined model view definition for each COBie data drop. From this can come clear guidance on the “level of detail” required at each COBie data drop. This will give a shared understanding of what information is required from and by whom and at what stage.  For example needs of Facilities Managers are required to inform the content of the COBie data drops. Facility management must be considered as early as the briefing process.
  3. Weaknesses in the IFC import /export processes exist in current software product implementation. These weaknesses make manual checking necessary and reduce confidence.  Improvement  is vital here.
  4. While IFC can be used when generating COBie data, people will use whatever works and is available. The market requires.  complete flexibility to choose what systems they use. Innovation should not be stifled by mandating a process to achieve the required data.
  5. COBIE is far from complete, but a good starting point.
  6.  Microsoft Excel  provides a view of the structured info of COBie data and one way 0f reporting data, however, in NOT a good authoring tool, nor does it support hierarchal relational data schema.

IFC_COBie-Report-2012

BIG DATA = BIM
BIG DATA = BIM

 

 

Facility Life-cycle Costs and BIM

Understanding facility life-cycle costs is a core component of any BIM strategy for Owners, AE’s, Contractors, Subs, Business Product Manufacturers, Oversight Groups, Building Users, … or any stakeholder.

There are many components of life-cycle costs:

  • First Costs – Planning, Selection, Acquisition, Construction
  • Maintenance, Repair – Routine, Preventive, Unscheduled (typically expenditures of $10,000 per job or less)
  • Capital Renewal (major system/subsystem cyclical replacement)
  • Renovation, Adaptation (altering, updating spaces based upon functional needs)
  • Operations (utilization, utilities, security, safety, sustainability, waste, cleaning, grounds management )
  • Deconstruction, Transition, Disposition

BIM is just now beginning to lay the foundation for new processes and supporting technologies to enable more efficient life-cycle management of the built environment.   An important challenge is the establishment of common terms, definitions, metrics, and ‘best-practices’.   Some off these will be new, however, many/most  will likely be existing… the latter simply better shared, communicated, and consistently applied.

Facility Lifecycle Costs
Facility Lifecycle Costs