Thursday 6 April 2017

Publishing your specification - Post 2 of 3 (COBie)

This is the second of three posts looking at publishing information from NBS so that it can be used by the wider project team. The first of these posts looked at exporting to Microsoft Word to improve the aesthetics of the published output. This post looks at the other end of the spectrum - publishing just the data regarding the systems and products that make up the built asset so that this data can then be transferred to other software applications such as FM systems. 

When publishing data with interoperability in mind, it is essential that the data format is to an agreed public standard. Figure 1 below illustrates this in a simple non-construction-industry example. To take contact information from Google into Apple products there is a basic agreed data schema called vCard. 99.9% of the world needn't know anything about this. But the software developers at Google and Apple do. They can then make great products and transfer information reasonably smoothly with the complexity hidden from the 99.9%.
Figure 1 - Interoperability and vCard
Of course, in the construction industry it is much, much, more tricky to digitally model an entire built asset than it is to model someone's contact details. The open data schema that is defined by the UK's Level 2 BIM to do this job is the Construction Operation Building Information Exchange format (or COBie for short).

For more on COBie - please see one of the websites below:
- The 'What is?' page on theNBS website: www.thenbs.com/knowledge/what-is-cobie

Figure 2 - Concept diagram from UK BIM Task Group
Not one tool models the entire built asset. Costs may be contained in cost databases, spaces and instances in 3D models, maintenance manuals on an extranet etc... So no software tool can claim to have a 'big COBie button' that produces a complete data file. Figure 3 below simplifies the data schema of a built asset and indicates in red the information that is contained within a specification. Figure 4 shows how by exporting to an open data format then this information can then be imported into another software application. In this example it shows the information from an 'as built' specification at stages 4/5 of a project then being imported into an FM system for stages 6/7 of a project.

Figure 3 - Where the specification fits


Figure 4 - Taking information from one software package into another
Recently introduced functionality in NBS Create has greatly improved the 'Publish to COBie' feature within the product. Previously it has been possible to generate a collection of CSV files that could then be manipulated into COBie format.

Now it is possible to generate a COBie data file in the properly formatted Microsoft Excel template. Figure 5 shows this option in NBS Create.
Figure 5 - Export to COBie format
At the point of export it is possible to select what codes are required for the Category field within COBie. Figure 6 shows that either the NBS reference codes or Uniclass 2015 classification codes may be selected. The organisation generating this information may also specify their contact details which will be stamped against each row of data.
Figure 6 - Select your classification
Figure 7 shows that a user-friendly report is generated highlighting exactly what information has been exported. All types of activities (such as surveys), systems (such as heating systems) and products (such as air curtains) are exported. If exporting to Uniclass 2015, any items without a Uniclass 2015 code are highlighted. This would typically include product clauses detailing prototyping or samples.
Figure 7 - Export report
Figure 8 below shows the COBie overview worksheet - the contact, system, type and attribute worksheets can be seen to be well populated. Worksheets on Spares, Spaces, Resources, Jobs are empty as this information is not typically modelled in a specification.
Figure 8 - The COBie overview worksheet
The concluding figures below show 'the data' in a format that can be then used for any workflow that supports COBie. The sorting and filtering functionality in Microsoft Excel is also useful for querying this data in the native file.
Figure 9 - The manufacturer contact details

Figure 10 - All of the 'types' of systems and products

Figure 11 - Filtering the attributes to display the information about a specific type
For more information on NBS Create and COBie please see our page on theNBS.com:
www.thenbs.com/support/cobie-mappings-in-nbs-create

For more information about NBS for BIM projects please see the page below:
www.thenbs.com/services/bim-projects

This is part of a three post blog series:

Post 1 - Publishing your specification to Microsoft Word

Post 3 - Publishing your coordinated specification and model to the cloud

2 comments:

  1. This really is cart before the horse. You guys have a massive amount of work to do to link specification clause values to object parameter values in a model. The beta development of this appears to have stalled. If these values are not linked in software, there is no value in publishing COBie from the NBS document, as unvalidated, unverified COBie is worthless.

    ReplyDelete
  2. Chris,

    Thanks for the feedback. Linking specification properties to parameter values in a model is something that we're certainly interested in. A consistent database/dictionary of terminology to define construction items is potentially the answer to this.

    It wouldn't be easy - but it's definitely something we'll look into going forward.

    S

    ReplyDelete