Process centric data models are needed for BIM and ….

BIM, the life-cycle management of the built environment supported by digital technology is all about the integration of PEOPLE and PROCESSES and INFORMATION.

The following are MANDATORY on any BIM implementation checklist.  Please add to the list and/or comment!

1. Collaborative construction/project delivery method:  Integrated project delivery (IPD), job order contracting (JOC), private-public partnership (PPP) …

2.  A robust ontology – clearly defined terms, definitions, metrics, benchmarks and their inter-relationships with each other and associated processes.

3.  Linkage for multiple “competencies” and/or “knowledge domains” associate with strategic and capital planning, design, procurement, construction, project management, repair, maintenance, sustainability, operations, and deconstruction/re-use.

 

Examples of domain specific technologies/processes:

CPMS – Capital Planning and Management Systems

CMMS – Computerized Maintenance Management Systems

CAFM – Computer-aided Facility Management

BAS – Building Automation Systems

GIS – Geographical Information Systems

Visualization/QTO – 2d/3d visualization, pattern search,

Procurement/Project Management – IPD, JOC, Cost Estimating, Scheduling ..

 

To date,  ongoing efforts continue relative to the specification of batch and transactional exchanges, upon which this process models can be based.   The concept of a model view defintion (MVD) and or a facility management handover model view defintion (FM MVD) are “pioneering” attempts to add structure to previously disparate and ‘ad-hoc’ methods.   Industry Foundation Classes (IFC) are open and neutral data formats,  and the IFC View Definition and the MVD are synonymous.   The MVD is a subset of IFC intended to provide implementation guidance for classes, attributes, relationships, property sets, quantity sets, etc., however, the issue that these have yet to be adequately described.    Omniclass, for example, is far from complete, and MasterFormat and Uniformat, while both are robust, do not have fully defined relationships.

The FM MVD specifically is an attempt to transform paper-based deliverables into a rich dynamic electronic information repository.  The attempt however will fail without are robust ontology and clear definition of all requisite competencies, information, processes, and their inter-relationships.

COBIe ( Construction-Operations Building information exchange0 and its offshoots LCie, SPARKie, etc.  are schema/data architectures intended to provide an open framework for the exchange and delivery of construction handover information, and eventual life-cycle management of the built environment.  Great care, however, must be takes not to “reinvent the wheel”, or to “automated existing ad-hoc or inefficient AEC practices.    COBIe and its peers MUST be applied and used with fundamental changes in construction delivery methods and standardized ontologies spanning all “competencies”.   In short, keep what is good, through out what is bad, and do so in an open/transparent manner using commonly defined terms, metrics and benchmarks.

While the “COBie model” does fairly well at showing b the relationships among  model entities and the  overall staging of COBie information delivery, it does little to advance fundamental process changes.   It does not clearly define the concept of life-cycle management of the built environment nor COBie’s role in the endeavor.

Planning, design, procurement, construction, repair, maintenance, operations.. can no longer be thought of a discrete.  All are interdependent relative to total cost of ownership and life-cycle management.

via http://www.4Clicks.com – Premier cost estimating and efficient project delivery software solutions for JOC, SABER, IDIQ, MATOC, SATOC, MACC, POCA, BOA, BOS … featuring an exclusively enhanced 400,000 line item RSMeans Cost Database, visual estimating/automatic quantity take off ( QTO),  and collaborative contract/project/document management, all in one application.   Our technology is currently serving over 85% of United States Air Force bases and rapidly growing numbers of other DOD and non-DOD (United States Army Corps of Engineers,  Army, GSA, Homeland Security, VA..) federal departments/agencies, as well as state/county/local governments, colleges/universities, healthcare,  and airports/transportation.  RSMeans Strategic Partner

BIM Level of Development Specification – LOD

The Level of Development (LOD) Specification as created and presented by BIMForum.org ” is a reference that enables practitioners in the AEC Industry to specify and articulate a high level of clarity the content and reliability of Building Information Models (BIMs) at various stages in the design and construction process. The LOD Specification utilizes the basic LOD definitions developed by the AIA for the AIA G202-2013 Building Information Modeling Protocol Form1 and is organized by CSI Uniformat 2010. It defines and illustrates characteristics of model elements of different building systems at different Levels of Development. This clear articulation allows model authors to define what  their models can be relied on for, and allows downstream users to clearly understand the usability and the limitations of models they are  receiving.  The intent of this Specification is to help explain the LOD framework and standardize its use so that it becomes more useful as a
communication tool. It does not prescribe what Levels of Development are to be reached at what point in a project but leaves the  specification of the model progression to the user of this document. To accomplish the document’s intent, its primary objectives are:

• To help teams, including owners, to specify BIM deliverables and to get a clear picture of what will be included in a BIM deliverable
• To help design managers explain to their teams the information and detail that needs to be provided at various points in the design process
• To provide a standard that can be referenced by contracts and BIM execution plans.

It should be noted that this Specification does not replace a project BIM Execution Plan (BIMXP), but rather is intended to be used in  conjunction with such a plan, providing a means of defining models for specific information exchanges, milestones in a design work  plan, and deliverables for specific function,”

Download 2013 LOD Specification

LOD is sometimes interpreted as Level of Detail rather than Level of Development. There are important differences.
Level of Detail is essentially how much detail is included in the model element.

Level of Development is the degree to which the
element’s geometry and attached information has been thought through – the degree to which project team members may rely on the  information when using the model. In essence, Level of Detail can be thought of as input to the element, while Level of Development is reliable output.

Fundamental LOD Definitions 
LOD 100 The Model Element may be graphically represented in the Model with a symbol or other generic representation, but does not satisfy the requirements for LOD 200. Information  related to the Model Element (i.e. cost per square foot, tonnage of HVAC, etc.) can be  derived from other Model Elements.
LOD 200 The Model Element is graphically represented within the Model as a generic system, object, or assembly with approximate quantities, size, shape, location, and orientation. Non-graphic information may also be attached to the Model Element.
LOD 300 The Model Element is graphically represented within the Model as a specific system, object or assembly in terms of quantity, size, shape, location, and orientation. Non-graphic information may also be attached to the Model Element.
LOD 350 The Model Element is graphically represented within the Model as a specific system, object,  or assembly in terms of quantity, size, shape, orientation, and interfaces with other building  systems. Non-graphic information may also be attached to the Model Element.
LOD 400 The Model Element is graphically represented within the Model as a specific system, object  or assembly in terms of size, shape, location, quantity, and orientation with detailing,  fabrication, assembly, and installation information. Non-graphic information may also be  attached to the Model Element.
LOD 500 The Model Element is a field verified representation in terms of size, shape, location,  quantity, and orientation. Non-graphic information may also be attached to the Model  Elements.
Example – light fixture:
100 cost/sf attached to floor slabs
200 light fixture, generic/approximate size/shape/location
300 Design specified 2×4 troffer, specific size/shape/location
350 Actual model, Lightolier DPA2G12LS232, specific size/shape/location
400 As 350, plus special mounting details, as in a decorative soffit

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

The “I” in BIM, OMNICLASS, and the Criticality of Getting it RIGHT…. Now!

In order to efficiently manage the life-cycle of the build environment, robust process, terms, and decision support tools are required that deal with physical and functional conditions, costs, priorities, risks, etc.

Business Case –  The classification and identification of equipment assets within a facility has to-date typically been accomplished through the use of internally developed legacy systems that do not integrate with other similar systems in use in other facilities, or new or existing technologies. Without an industry standard, users have been unable to cross reference data between organizations, agencies, industry, disciplines, and software solutions, creating inaccuracies and inefficiencies that have a major impact on effective maintenance, operations, and management of assets and facilities. There are shortcomings in all existing industry standards that define or classify objects in a way that allows facility life cycle capture of data. – Inter-agency Federal Asset Classification Team (IFACT)

The ability to define a “thing”, and recall that “thing”, and be able to discuss that “thing”, and all of its attributes, and track it’s changes…both planned, and unplanned, is critical.   Yet, the capability is NOT present at this time.    Here’s a short list of what is holding us back.   The good news is that it’s not “rocket science”.    The bad news is that is will REQUIRE SIGNIFICANT CULTURAL CHANGE with the Architectural, Engineering, Construction, Operations, and Owners sector.

1. Faceted vs. Hierarchical Data Structures / Architectures
2. Object-oriented technology to support Faceted and/or Hybrid classifications
3. Collaborative, cloud-based systems that are multi-language, multi-currency, secure, fast, and never delete information.
4. A life-cycle vs. first cost mentality/approach for planning, decision-making, and resource allocation.

OMNICLASS and cloud-computing will enable BIM leap to the next level, that is…. life-cycle management of the built environment, vs. pretty pictures.

Here’s some related work on the Government side:

A National Building Information Model Standard Project Fact Sheet Inter-agency Federal Asset Classification Team
(IFACT) –   The National Building Information Model Standard (NBIMS) is a set of interoperable standards for exchange of facility and infrastructure data through the life-cycle of a project. NBIMS is a joint project coordinated by National Institute of Building Sciences (NIBS) in conjunction with the buildingSMART Alliance (bSA) and many other facilities-related associations and software companies.

Results to Date

• Progress towards complete revision of OmniClass Table 23 – Products
• Progress towards compiling new abbreviations to submit to the United States National CAD Standard® consensus process.
• Construction Specification Institute is the key authoring authority on project.
• Participating Agencies: General Services Administration, Department of Veteran Affairs, Department of State, Department of Homeland Security
• Future Applications – Enhancements to OmniClass and the United States National CAD Standard® will allow a higher degree of data integration for all related software solutions and facility management systems.

BIG DATA = BIM

via http://www.4Clicks.com – via 4Clicks.com – Premier cost estimating and efficient project delivery software featuring visual estimating, best representation of RSMeans Cost Data, contact, project and document management, for facility renovation, repair, sustainability, and minor new construction : JOC, SABER, IDIQ, IPD, SATOC, MATOC, BOCA, BOA, ….

BIM and High Performance Buildings

 

The High-Performance Building Council adopted the following defi nition for high performance buildings:

High-performance buildings, which address human, environmental, economic and total societal impact, are the result of the application of the highest level design, construction, operation and maintenance principles—a paradigm change for the built environment.

There is simply NO WAY we will achieve higher performance buildings across our existing inventory of building stock without and/or new buildings  the adoption of more efficient construction delivery methods and process like IPD (integrated project delivery) and JOC (job order contracting), and the associate adoption of standardized cost data and cost data architectures, common taxonomies/frameworks (UNIFORMAT, MASTERFORMAT, COBIE, OMNICLASS) and the integration of various supporting domains and tgechnologies (CPMS, CMMS, CAFM, GIS,  BAS, Cloud ….).

via www.4clicks.com

 

MasterFormat / MasterFormat2004 Changes

MasterFormat® Updates:

Did you know CSI and CSC have a new annual revision cycle?

Did you know there is a new Division?

The major updates to MasterFormat2004 are:

• A new division, Division 46 – Water and Wastewater Equipment, which significantly expands the document’s coverage of environmental engineering specifications
• Revisions to Division 44 – Pollution and Waste Control Equipment, so that it complements the addition of the new Division 46
• New specifications related to polished concrete (Division 03)

CSI and CSC designed the 50-division format of MasterFormat 2004 so that it can accommodate additional divisions and changes as the industry evolves. The 50-division format is now used in a majority of commercial projects in North America.

The MasterFormat revision process is conducted by the MasterFormat Maintenance Task Team (MFMTT), a committee of volunteers appointed by CSI, CSC and MasterFormat Sponsors (ARCAT, ARCOM, Building Systems Design, Inc., the Construction Sciences Research Foundation, Inc., McGraw-Hill Construction, and Reed Construction Data).

What is COBIE ?

COBIE is a process framework for collecting llife-cycle building information.  COBIE requires OmniClass,  a CSI data architecture/classification/taxonomy.  (Uniformat is a part of OmniClass).

The COBIE framework can be used with BIM or independent of BIM.

COBIE is intended to allow repair/maintenance/renovation task data to be electronically exchanged.

The Construction Operation Building Information Exchange (COBIE) is an “international standard format” intended to improve the transfer of  design and construction information to the operation and management team.