Paul Oakley, Associate Director BIM at BRE, argues that the Holy Grail for BIM relies on a plain language dictionary for the delivery of structured information

Building Information Modelling (BIM) — the Holy Grail of Digital Built Britain — has been targeted with reducing lifecycle costs of buildings by 33%, enabling the Internet of Things, and moving construction into the world of big data. While the intent is to be applauded, the reality is that this cannot be achieved in its present form, and many do not realise that there is a problem, or even what that problem is, never mind how we are going to resolve it.

The UK BIM Level 2 mandate came with a new requirement for industry: to deliver Construction Operations Building information exchange (COBie) in addition to our usual deliverables of drawings and documentation. Few have realised that this is a major change for construction. A requirement to deliver COBie is a requirement to deliver structured data — something very few designers or constructors have actually done. But while COBie provides the briefcase to carry the exchange, it fails to identify what that structured data is required to do.

But surely that is all defined in PAS1192-2:2013 and PAS1192-3:2014 you say? It is just the information defined within the Employers Information Requirements (EIR), identified by the Organizational Information Requirements (OIR) and Asset Information Requirements (AIR). Also, the digital plan of works provided within the BIM Toolkit defines when information needs to be provided and we can just use the BIM object libraries as the mechanism to deliver this.

The BIM object libraries provide the BIM equivalent of the emperor’s new clothes. They can be expensive, are often miss-sold, and deliver nothing of use to the process. Due to the marketing of early objects to the industry, there is a perception that models require the smallest of details such as door stops and hinges, which also include every specification option. This is totally misrepresentative of the BIM Level 2 requirements and will never aid to deliver the structured asset requirements identified. The liability issues mean that most designers presently create their own content, as these will ensure consistent data delivery while some may adopt aspects of published libraries.

This is where the devil in the detail lies. Which object library standard do we use as none of them meet all our requirements? Also, BIM library objects are created by differing authoring tools, with differing capabilities, as well as using different standards and definitions. Each solution uses different methods of classifying objects, and modelling capabilities mean that specific object representations are also not identified as their real world counterparts.

Then we start to come down to the BIM object data issues. Which implementation of a standard should we use? Within some software, there is a need to define if the attribute data is to be stored against the instance of an object or the type. How do we deal with inherited data from either systems or location? In reality, we have too much data on the library objects, but it is not the information we actually need.

Looking at the life-cycle requirements of a BIM object, there will be many data requirements associated with it. These will include:

•             Asset Requirements

•             Performance Criteria

•             Specification

•             Test Criteria

•             Health and Safety

•             Operations requirements

•             Maintenance

•             End of Life (Replacement)

Associated with these may be hundreds or thousands of attribute properties that may relate to the project, instance, the object type, project, manufacturer, supplier, etc. The concept that all of these can be stored on every BIM object within a project model, to be accessed by the authoring tool is ludicrous but still perceive by the uninitiated as the solution to obtaining the Holy Grail.

We then come to some of the basics of the problem. We still cannot decide what we call something as simple as the two sides of a rectangle, and therefore, cannot initiate basic data exchanges.

For some, defining the right data can be resolved by Product Data Templates (PDTs). CIBSE and others have been looking at product data and attempting to establish what information would be useful and should be applied to a manufactured product. While this helps to define a human readable solution to information exchanges and provides manufacturers with a starting list of data requirements, it fails to meet the data exchange requirements of industry, specifically if we link BIM objects with manufacturer’s datasets through the life-cycle. The parameters defined within such PDTs fail to meet the data exchange requirements of standards such as the BS8541 series which takes into account the needs of the differing authoring tools on the market.

So how can we start to resolve this problem? BRE, with various partners, have been involved with many BIM related research projects over the years,  all having reached a similar conclusion; that without a consistent data standard, it is impossible to exchange structured data as information to inform the decision-making process. The only solution is to create a standardised dictionary against which everything else is measured. However, while buildingSMART and others have established some dictionary tools, the content within these tools does not have the appropriate validation and ownership to ensure the quality of content required. Nor do they presently have the appropriate capabilities to ensure this.

BRE, along with our partners at ActivePlan, have been working on this problem for several years and have developed the BRE Templater tool. The BIM Task Group have recently issued the technical specification for defining and sharing structured digital construction product information stating:

“Product data is essential for the delivery, maintenance and operation of any physical built asset. It is important to share consistent, accurate information to enable specification, assembly and ongoing maintenance and replacement through an asset’s life-cycle and the purpose of this technical specification is to provide a framework to support the flow of information using plain language terms with a focus on the purpose of information.”

But as important as the dictionary is, it is the ownership and process of signing off the data as a verified standard that is crucial. We need to consider the purpose of information; who is best placed to provide it; what format it should be provided in, and how it can be shared or developed through the life-cycle.

While the BRE Templater was announced as the winning technology solution by the Construction Products Association, HM BIM Task Group and BIM4M2, its success will be based upon the content delivered to industry by the relevant authorities. This will initially provide the plain language dictionary against which EIR, AIRs, etc., can define the structured data needed to allow BIM authoring tools, libraries and content providers to deliver consistent, organised information. This in itself will not provide the Holy Grail, but like the Ankara it will at least point the industry in the right direction.

Paul Oakley BA(Hons) Dip Arch RIBA

Associate Director BIM

+44 (0)333 321 88 11

enquiries@bre.co.uk

www.bre.co.uk

@BRE_Group