Product Data Templates (PDTs) Frequently Asked Questions

Here is a list of common questions that have been asked about the PDTs with answers provided by the PDT development group that includes contractors, designers, consultants, manufacturers, building operators, maintenance specialists and clients.

What is the purpose of the Product Data Templates (PDTs)?

PDTs are born out of the desire to have consistent product data. Today, within a given category of construction industry manufactured products, how the data is provided, where is it to be found, and what key product characteristics are called, varies by manufacturer and, at times, even within a given manufacturer.

PDTs are also the source of consistent data to be used in the management of the constructed asset, allowing facilities managers to find the information they require for operation and maintenance of the facility in a structured and standardised format, improving the efficiency and productivity of the FM process, and supporting automation in the management of asset information.

Our industry is embarked in a process to increase efficiency, and productivity — parallels are often drawn between construction and more production-focused industries, like the car and aerospace industries. Improvement in any of these metrics lies within automation. And with thousands of manufacturers, providing millions of products, consistency of data is key to automation.

Building Information Modelling (BIM) is part of this process, and it increases the need for clear communication and sharing of data. With product data underpinning many of our processes, the PDTs provide a consistent, and reliable format for manufacturers to share product data for use by all other disciplines.

What is a Product Data Template (PDT), exactly?

A template to help generate, for a given manufacturer’s product, within a given category, a set of information about the product. The output of this process is a product data sheet (PDS), that the manufacturer can then make available to any party.

More specifically, a PDT for a given product category is an electronic spreadsheet containing a set of parameters — fields, (or questions, if you want) — covering every bit of information that can be reasonably expected to be provided (answered) by a product manufacturer.

By way of an example, a PDT exists for Isolation Valves. An isolation valve manufacturer wishing to provide information, in a consistent format, to anyone within the construction industry, will enter data for each of the questions — fields, or parameters — within the PDT. Once all the information has been entered, the result can be saved and shared as a PDS.

What information is required to fill in a PDT?

All general product information that could reasonably be expected to be provided by its manufacturer.

As such, and to avoid asking for information from a manufacturer that is not relevant to their products, there are different PDTs for different product categories. Some fields within a PDT are common to all PDTs, e.g. Manufacturer, and Manufacturer Website. Others are specific to a given group of PDTs, e.g. for the Isolation Valves PDT, Maximum Test Pressure, and Maximum Working Pressure.

The total number of fields — questions, or parameters — varies from PDT to PDT, and can be anywhere from a few dozens to over a hundred.

How do the Product Data Templates (PDTs) work?

The Product Data Templates are to be used by product manufacturers to compile general information about their products. A manufacturer will start from the relevant PDT. A PDT is an electronic spreadsheet, and it contains a set of required fields — questions, or parameters — in a column, with another column being provided to enter the answers to the questions.

Once a PDT is completed, following the instructions, the result can be saved, and shared. This new document is what we refer to as a product data sheet (PDS). The information is now consistent with PDSs provided by other manufacturers of the given product category.

Who is the data for?

The data generated from completing a PDT is for anyone interested in a particular product. The aim is to compile consistent product data for use within the construction industry.

Why would someone want to fill out the data?

Manufacturers already provide this data variously in catalogues and other outputs. Adopting the PDT format offers manufacturers a single, standard way of providing this information, thereby reducing their cost and helping their customers. Reduced costs and happy customers are powerful reasons to fill out the data.

Why would someone want to use the data?

The demand for this data already exists and keeps on growing. PDTs and the product data sheets generated from them facilitate the access and use of this data.

The CIBSE website has a random list of architectural PDTs. When will the list of PDTs on the CIBSE website be updated?

CIBSE’s list of architectural (and other disciplines’) PDTs was primarily to define boundaries between its MEP PDTs and other parties’ PDTs. CIBSE is updating this list with BIM4M2, BIM4FitOut and other stakeholders.

Who is in charge of the architectural PDTs? Are the RIBA and/or RIBA Enterprises on board with the selected representatives?

While CIBSE has engaged in discussions with RIBAe, and NBS on PDTs, there are other players involved with architectural ones (see above) that follow the CIBSE structure and principles. Meanwhile, RIBAe/NBS has developed alternative forms of PDTs (see on) so there is a process of reconciliation outstanding.

Will the PDTs, and their terminology align with Uniclass 2015 Classification?

Uniclass is a non-mandatory classification system for the construction industry. It is the UK implementation of BS ISO 12006-2, providing a structured approach to classifying building information by organising it on common characteristics. The recently released revision, Uniclass 2015, provides 7 core tables so far, one of which covers products to which the PDTs need to be aligned. We have not yet studied Uniclass 2015 in detail but we consider that often alignment will be readily achieved by mapping but there will be some differences in object definitions which will need more work to align.

How do the CIBSE and NBS BIM Toolkit PDTs relate?

Currently the references within the NBS Toolkit to PDTs have little in common with the CIBSE PDTs, aside from the name. As the NBS Toolkit was prepared in only six months, whilst CIBSE’s PDTs were still a work in progress, its PDTs inevitably reference the pre-existing NBS Create and NBL proformas, which predate standards that inform CIBSE’s PDTs. It was therefore a common understanding that product descriptors could not be aligned in the time scale of the NBS Toolkit’s genesis. CIBSE intends to remedy this with RIBAe in the future.

How will CIBSE data be verified if the data is different to the NBS BIM Toolkit?

CIBSE’s product data sheets provide general product information, prepared and certified by manufacturers. How do the data fields in the PDTs relate to IFC, COBie, and other information exchanges? Many fields within IFC, and COBie, are a direct input of manufacturer data. Information provided by means of the PDTs can be mapped to their respective IFC, or COBie fields, in an automated manner.

Could CIBSE clarify the methods for using the data? Is the data expected in an authoring tool? Can it be linked?

See answers to the first three questions. As stated above, this data can be programmatically interrogated, but the nature by which this is achieved will be down to the consumer of the data, as CIBSE do not propose to be prescriptive about use as there are too many platforms across which this data may be used and each user may choose a different method. Where is the information on required Property Set naming in relation to IFC and COBie? There is no direct relationship.

Also which information is at Type level and which at Component level?

Component information would be project (application) specific, and not something that a product manufacturer would be able to provide as general product data. The information provided by the PDTs would be categorized as Type level information. Why do the CIBSE PDTs deviate in terminology from COBie? The PDTs have been created with the help of many organizations, including manufacturers and their trade associations. Initially COBie terminology was employed in CIBSE’s draft PDTs. However, the consensus of these stakeholders, was that PDTs should employ the normal terminology of the UK industry to facilitate use and understanding, rather than the transatlantic, machine readable, text of COBie. Care has been taken to harmonize naming between parameters in different PDTs. While this generates some deviation from standards like COBie, mapping between parameters in PDTs and such other formats can be readily automated.

Why do the CIBSE PDTs not include all the COBie fields? (for example AssetType)

As above, PDTs generate a subset of the data required in COBie, but exclude project specific data. AssetType, which is general product data is covered by the name of the PDT. However, it should be noted that PDTs also generate more product data than COBie, based on a consensus of the wider information requirements of the industry. (Please also see answer to first question about the purpose of the PDTs).

Can the fields also align with the NBS BIM Object Standard? I.e Manufacturer Website compared to ManufacturerURL.

See previous answer about COBie terminology. CIBSE has endeavoured to follow current international standards.

Read lots more about PDTs here