From BIM Journal. Click Here to Read Issue 4
Many enthusiasts in the manufacturing sector and beyond are of course already familiar with these terms. To the uninitiated however, the whole array of tools and options may seem baffling. As such, this article will unpick some of the common features, rumours and myths that surround the easy structuring and use of product data.
It is unsurprising that some manufacturers have had little appetite to engage with Level 2 BIM given the historic absence of a consensus on the scope and content of product data files. Yet the government requires Level 2 BIM to be the default for public sector projects and, as this sector provides 40% of the UK industry’s workload, manufacturers who continue to avoid Level 2 BIM face a loss of business to those that embrace it.
Accordingly, manufacturers need to consider the steps needed to honour data requirements for public and private sector clients, in a manner that removes the need to complete bespoke data sheets as requested from designers and contractors. This information must also be available across differing software platforms.
Now 3D geometry certainly looks nice and will always tend to steal the show, but the data that accompanies the object is what becomes the key differentiator in Level 2 BIM. Certainly many libraries of ‘generic’ products already exist, but, and this is in the Building Services industry particularly, few manufacturers offer models of their products containing the appropriate data.
Product Data Templates, ergo Product Data Sheets, go some way to address this.
Product Data Templates
Presented in an open neutral spreadsheet format, PDTs aim to anticipate the information sought by every party; from specification through operations to decommissioning and replacement. As such, their adoption and use can of course result in a huge efficiency saving for all parties involved.
Indeed at present, in any given category of product how the data is provided and what certain key characteristics are called varies not just between manufacturers but even within the same manufacturer itself. As such, by adopting a standardised approach, so designed to service the information requirements of all types of user, manufacturers can nowadays prepare a product’s data once, digitally, in a manner that satisfies all project and user purposes in a consistent and uniform manner. This is the concept of Product Data Templates (PDTs) at least, which are essentially a standard ‘questionnaire’ for each equipment type.
Indeed all PDTs follow the same standard format, which sees the first column comprising of three categories of information: Specification; Sustainability and Facilities / Asset Management. A second column sets out the parameters to be answered by the manufacturer, these answers being inputted as values in the third column, which need to correspond with the units given in the fourth column. The fifth column is simply for prompts and explanations.
Once the ‘values’ column has been completed, this changes the PDT into a PDS, a Product Data Sheet. This is because the values now of course represent one specific item, and the spreadsheet itself is no longer an empty template.
It is important to point out that PDTs only ask for the general product information. They do not contain any application-specific parameters (duty point criteria, cost, delivery, placement, etc) and obtaining this data remains part of the everyday process of enquiry and quotation. Business as usual.
PDT development groups include contractors, designers, consultants, manufacturers, building operators, maintenance specialists and clients and other industry participants such as the NBS also provide a suite of PDTs as part of the BIM Toolkit provision. These are freely available and users can pick and choose which provider they would like to use. Indeed to bring a consistent and coordinated approach the NBS have been working closely with CIBSE, CPA and BIM4M2 as part of an initiative to deliver a single set of master templates, which is a much clearer message for industry overall.
Product Data Sheets
For the other parties, the standard format of the PDS enables users to automate their data operations, such that each person is able to abstract only the information that they want. In short, answering ‘graduated’ questions posed at different project stages can be done by computers instead, and not people.
PDSs can also go some way to simplify the tasks faced by sales and technical teams as well, by obviating ‘bespoke’ questionnaires used across the industry. Many supplementary queries can also be avoided.
It is incredible that some manufacturers are still not fully on board with this but they are quite seemingly getting there. As BIM is a migration and not a race, getting everybody over the line is what really counts.
How to tackle this. Right, as software applications large and small are these days generally referred to as ‘tools’ BIMHawk is a collection of tools developed by CIBSE, to assist with the creation of Product Data Templates, Product Data Sheets, and the subsequent migration of this information into other software applications.
To begin with, it uses the logic of providing a suite of thousands of PDTs in an online repository that manufacturers can readily access and use. But it complements this offering with a suite of software programs and utilities for creating, managing and integrating PDTs & PDSs with other digital systems as well (native BIM authoring applications, for example).
As captured on the BIMHawk website, one problem is that manufacturers have set about creating BIM object libraries of their products, but many have been created prior to the development of an agreed industry standard for product datasets.
Also, and this is one for developers to worry about really, but the complexities of modern BIM systems mean that standardising product data is not the only issue faced. As mainstream BIM systems also require that each individual object ‘parameter’ must also be created with a common Globally Unique Identifier (GUID) as well. In many cases the ‘Parameter’ names are simply aliases and it is the underlying GUID that is used to manipulate and manage the data. This being a phenomenon that was examined in greater detail in BIM Journal Issue One (openBIM).
Now with this in mind, for the non-technical layman, what is especially useful about the BIMHawk tool is that when individual parameters are created within BIMHawk, it performs a dynamic check with the Building Smart Data Dictionary (bsDD) to see if the parameter name has been previously defined. If the parameter name exists in the Data Dictionary, its GUID is extracted and used within BIMHawk. If no such entry exists, BIMHawk generates its own definition and associated GUID.
Critically, once these GUID’s are mapped to parameters in BIMHawk, they remain consistent. BIMHawk tools for outputting PDT XML or generating Revit Shared Parameter files then utilise these consistent GUID’s. Simple. Sort of.
As a result of this, the BIMHawk Revit plugin for example, can directly and instantly bind a PDT dataset to any Revit Family or Project. The plugin also has the ability to update any matching parameters within existing Families to the BIMHawk standard. This feature also has the potential to correct and align any existing Revit objects created by manufacturers.
Hopefully this presents the BIMHawk toolset in a nutshell, and rest assured that work is already underway to support other popular BIM platforms. What I will now attempt to unravel is LEXiCON, which can be another important but misunderstood industry headscratcher.
LEXiCON is an initiative that works by attempting to provide a plain language dictionary and data templates, based on existing industry expertise and consensus. So while something like BIMHawk provides an online repository of PDTs, LEXiCON provides the governance to create, define and group the information that goes into them in the first place.
The key to LEXiCON is indeed the governance behind it, and ensuring that the terms are approved by industry itself and can be used and shared with confidence. To facilitate this industry wide, terms and templates will be governed by "Relevant Authorities" who will be organisations or individuals with expertise relevant to particular products or activities. By way of example, CIBSE will be a "Senior Relevant Authority" meaning that they also have other Relevant Authorities feeding into them. It is then the role of a Relevant Authority to approve proposed properties, property sets, product data templates and sources. This unique methodology will then deliver a tangible digital data exchange while also providing the collaboration that industry needs.
So LEXiCON itself is more about the "who's in a position to do what, and how" in a nutshell. Now this may well be an endeavour that takes some unpicking alone I imagine, but large steps forward like this can indeed be taken by a unified industry when the right heads are put together, so watch this space.
For citations read BIM Journal Issue 04 here.