Manufacturers already exchange information with their customers regularly, for all manner of products, in the form of manuals and data sheets. However, as well as there being no standardised presentation format, the information is often in a form that is not easily readable by the computer software that is able to contribute to the building information model. This CPD will consider the fundamental need of the production and delivery of that information to the BIM, through the application of product data templates and sheets.
BIM – variously known as ‘building information model/modelling’ or ‘building information management’, but always including the word ‘information’ – provides a single source of data for, and from, all project members. Typically, current practice is for each discipline to hold its own ‘model’ and regularly issue the model – or information from it – to a central location, where all the information is collated. In reality, for many projects, this is still undertaken with ‘marked up’ drawings as the means of communication, with either little or no digital data exchange. The basis of the maturity Level 2 BIM (see panel), as defined by the UK Government Construction Strategy, is where output from separately operated modelling systems – for example, architectural, structural, services – sometimes known as ‘lonely BIM’, is combined with the provision of a single common data environment to store and share information.
Figure 1: CIBSE holds the master PDTs for building services BIM assets, such as would be used as a basis of a PDS for these commercial boilers
The stored data gives a digital representation of the building and its systems. This can then feed contextualised interfaces for the building team, the client and end users. For the building services engineer, for example, it may provide data that drives thermal models, system simulations and sizing tools. Software can create virtual 3D models, drawing on the BIM data sets to coordinate building components with mechanical and electrical systems, and supply the data to drive fabrication tools.
By accessing the common data set provided by the BIM, an object can be selected – whether it is a building services item, such as a boiler, or a constructional item, such as a floor – and its ‘properties’ can be interrogated. This might, for example, provide performance data or purchasing information during the construction stage, or automated procurement when replacement items are needed throughout the building’s life. When collections of objects are joined to create a system, all of the objects in the system can inherit and share attributes. So, potentially, this can automatically produce a planned maintenance scheme for a whole heating system, built on the collection of its components’ needs.
Embedded financial and operational parameters can be accessed to determine total operational costs that may be projected from year to year throughout the project’s life-cycle.
It is the ‘richness’ of the data that will determine the potential effectiveness of the BIM tools. The information does not necessarily have to be any different from that provided in traditional schedules or specifications. BIM does not change what information is provided, but it does enable different ways of accessing, storing, sharing, linking, manipulating and delivering it.
COBie
An integral part of the UK’s maturity Level 2 BIM deliverables is the production of information in the construction operations building information exchange (COBie) format, as submissions – or ‘data drops’ – at key stages in the development of projects to the client. This will enable checks on progress and compliance, as well as at the handover to the building operator as an element of the as-constructed Asset Information Model. This model will include necessary information to enable those managing and maintaining the building to do so more efficiently.
The UK government has set COBie as the chosen format for the transfer of non-graphical data from the BIM model. COBie consolidates information – including the catalogue and operating manual information provided by the manufacturer of the equipment – into a single digital format. It was originally conceived in the US to capture assets within a project, especially those that will require maintenance in the operation phase, so it can help ‘the project team organise electronic submittals approved during design and construction, and deliver a consolidated electronic operation and maintenance (O&M) manual with little or no additional effort’.1
Figure 2: Anatomy of a completed PDT– a product data sheet (PDS)
But COBie is not intended to be read by the end user. It is in a suitable format (a spreadsheet that includes multiple tabbed sheets) that can, if needed, be referred to – or amended – by humans, but it is specifically for exchanging data between systems, which can then provide contextualised output to the end user.
COBie output can comprise large spreadsheets – of many tens of thousands of rows – that may be difficult, practically, for some systems to handle, so it is not considered by some as the ideal vehicle for this information.
The benefit of quality asset information goes beyond the demands of COBie, and should be seen as fundamental to the creation – and maintenance – of a truly useful building information model. The UK government mandate for COBie has acted as a stimulus to develop practically useful ways to deliver product information readily into the BIM.
Information needed for the COBie output is added at various stages of the project, from concept through to commissioning. Specific information is required for items (or ‘assets’). In COBie language, a ‘type’ is a specific asset type – such as a boiler or pump that might be used several times in a project as a ‘component’. The COBie output for a particular asset is likely to contain numerous elements (‘fields’) of data. For many COBie assets, it is likely that only a few of the many data fields that make up the COBie output are unique for each specific asset in a building (such as a pump or boiler) – the remainder will be information that is common to a range of the particular asset.
Information required by COBie does not reflect the whole rich data set that might have been needed – or even developed – throughout the design and construction process, but is limited to data particularly needed by the end-user client and the facilities management operator.
Figure 3: Installed commercial boilers
The complete data set defining a particular product comprises two types of input – ‘general product data’ and ‘project specific data’. General product data includes, for example, who made it, what it’s built from, its size and weight, applicable standards, sustainability information, and maintenance procedures. All of this is intrinsic to a product, irrespective of its specific application.
Project specific data defines the product’s actual application – for example, its operating conditions, performance and related electrical control data. This can all be delivered from the design process. This would be held by the building information model, so can be fed directly into the product data set – becoming increasingly refined as the project evolves.
Elements of both general product data and project specific data will feed into the COBie output.
Product data template
General product data may be drawn from the disparate manufacturers’ catalogues and data sheets, transcribed into a digital format. This can be both time-consuming and prone to error. To enable a far more effective – and simple – input of product data, a cross-industry group, coordinated by CIBSE, has developed the product data template (PDT). This provides an accessible way for product manufacturers to supply information in a simple common format that can then be automatically read into the building information model. The PDT provides a set of understandable questions in a spreadsheet format that, when answered, describe the operational characteristics of a product – typically, one set of answers for each product range.
The questions encompass all the needs of the COBie data set, but the repetitive fields of COBie have been removed, and extended information has been added where it would provide improved utility for the BIM.
The PDT comprises five columns – instead of the 13 used by COBie – in the form of a technical schedule, as shown in Figure 2, that, in the BIM world, is known as the product data set. This is a pro-forma that looks like the widely used technical schedule from a contractor or consultant.
In the five columns of a PDT – information category, allowable parameters, the answers that define the product, the units that should be used, and guidance notes – only the third needs to be filled in by the product manufacturer; the others are pre-completed and fixed.
The rows of a PDT are both ‘human readable’ and logical, as shown in the outline in Figure 2. The first few rows include product type, function, classification, reference and other general information. The contact information lists the manufacturer’s details, including a link to its website.
UK BIM maturity levels
Note that these are different from levels of detail, levels of information and levels of development – see BIMtalk glossary for an explanation.
Level 0 – use of 2D CAD drafting, with paper-based or electronic print information and data exchange.
Level 1 – use of a mixture of 2D or 3D CAD, backed by a common data environment for electronic sharing
of drawings and data, with a standardised data structure and format managed to
BS 1192:2007.
Level 2 – collaborative working across disciplines, with all parties using 3D BIM models, integrated but not necessarily shared. Design information is shared through a common file format such as Industry Foundation Class (IFC) or COBie. Commercial data is managed by enterprise resource planning software and integrated with the federated BIM model.
Level 3 – fully collaborative working across all disciplines, using a single, shared project model held centrally and accessible to all to modify and share data.
The remainder of the orange block contains information used directly in the specification and construction process, such as dimensions and weights, performance data and relevant electrical data.
The yellow section contains information on product sustainability, while the purple one includes maintenance procedures.
The PDTs are devised to fast-track the flow of general product information into the building information model. In a single spreadsheet, they provide standard formats for presenting general product data digitally – and comprehensively – to deliver the information needed by everyone involved in selecting, buying, installing, and operating the product.
PDTs have been – and continue to be – developed through the input of various trade bodies, institutions and practitioners, via an approval process in which they are fully reviewed before they are released. The standard PDTs are held by the responsible institution – for example, CIBSE holds the master PDTs for building services products (or ‘assets’) and the Landscape Institute maintains the standard library of PDTs associated with landscaping.
The PDTs are downloadable, at no cost, for anyone to use. The particular target users are manufacturers and suppliers looking to present catalogue information in a BIM-usable format.
Once the PDT has its data fields completed by the manufacturer or supplier of a particular product range, it becomes a ‘product data sheet’ (PDS). So, for example, the characteristics of the range of boilers, as shown in Figures 1 and 3, would be reflected in the PDS. The manufacturer would make the PDS available on its website for anyone to read into their BIM. This sheet is the manufacturer’s property to publish and use to promote its product. The manufacturer or supplier does not need any expertise in BIM, and the resulting spreadsheet can be imported simply, to any BIM platform. It provides all the general information normally required and, failing that, it offers a web link to download further data from the manufacturer or supplier to provide more information about the product’s key features.
The development of the PDT enables data-rich assets to be introduced into BIM in a simple format, and the resulting PDSs are now being produced by several manufacturers. There is no doubt that, as BIM develops, PDTs will evolve. However, PDTs already provide an essential component in the successful application of BIM, as they solve a real practical need – they are an open format, freely available and not tied to particular software.
© Tim Dwyer, 2016.
Further reading:
BIMTalk provides a glossary of BIM terminology, as well as basic explanations and links to many of web-based resources. Key standards are identified at
BIMTalk standards.
The current PDTs can be viewed on the CIBSE website and an example of a completed PDS for a boiler is available at Bosch Industrial.
References:
- www.wbdg.org/resources/cobie.php – accessed 2 May 2016.