BIM and the data challenge


In developing data solutions for BIM Maturity Level 2, we also need to have in mind the future needs of Level 3 and beyond. Steve Thompson, Chair of BIM4M2 and Market Manager for Construction & Infrastructure at Tata Steel evaluates the product information required and how it can be delivered

One of the most interesting aspects of digitisation of the construction industry for me is the potential to see a more complete picture of the reasons for a project and how an asset can be delivered, operated and maintained to maximum benefit. With my architect’s hat on I see the BIM process as potentially providing a more complete and detailed brief to work with, with access to the information I need to make real-time decisions. With my product manufacturer’s hat on I see it as a way of helping project teams ensure they have the right product to meet their specific needs, as defined by the whole project team throughout the asset’s lifecycle. This may sound idealistic, but on both counts these scenarios have already been achieved many times over, they’re just not yet the norm.

To illustrate the bigger picture and the direction of travel, it’s worth looking at the number of things connected to the Internet, and how this is predicted to increase exponentially over the coming years. There are already significantly more things connected to the Internet than there are humans on the planet, and the impact of this is that things and humans can more easily communicate and interact.
In addition to the predicted significant increase in connectivity, the United Nations are predicting a global urban population growth of over 2.5 billion between 2014 and 2050 (United Nations Population Division, 2014). In short, that means that if we house the increase in population at an average of 100 people per building, we will need to build just under 2,000 residential buildings every single day for the next 35 years.

The reason for this slight detour is to highlight the point that when BIM maturity Level 2 becomes the norm, we are still only at basecamp in terms of the potential that can be achieved. It also means that in developing data solutions for Level 2, we need to have in mind the future climb to make sure we don’t keep heading back to basecamp and starting again. From a delivery perspective, it means that with the scale of the physical construction challenge ahead, we need those tasked with delivery to be involved in defining the information that they will need to succeed, working with those who have the product data (manufacturers) to identify the data available and its potential benefits.

To get to the Level 2 basecamp we need structured, accurate, reliable and accessible product data that not only clearly describes what a product is and how it performs, where it comes from and how it needs to be maintained, but also helps in the specification, supply and construction stages of its lifecycle. The challenge for the manufacturer amongst others, is to provide the right information in a suitable format to support a vast range of players, across different sectors and in different territories, using different approaches. If that is going to be achieved, there are a few key issues to address:
• Clearly defining what a product is, so that everyone and everything knows what they are looking at;
• Understanding the information requirements of different players (e.g. architects, engineers, supply chain partners, contractors, clients) and providing answers to those requirements;
• Understanding the most suitable format for exchange and use of information;
• Understanding how information requirements change in different countries or applications;
• Delivering the information required to address all of these issues, and understanding the potential resources and investment required.
It is certainly crucial that product information can be exchanged across software platforms and regions, so there needs to be clear mapping to open standards, including IFC (the Industry Foundation Classes). In addition, there needs to be clear mapping to any nationally mandated or required exchange formats such as COBie in the UK. The terminology used in these systems is still inaccessible to a large proportion of those who need to use them, including the majority of product manufacturers. Describing the thickness of a profiled composite cladding panel highlights the need for clear descriptions and definitions of parameters. Whilst generally described to the same ISO standard, a quoted panel thickness can mean the core thickness (without the depth of the profile), or overall thickness (including the profile depth). This means that if a parameter is simply described as thickness, there may be two very different values used in comparisons, potentially leading to incorrect specifications.

This is where the concept of Plain Language Questions (PLQs) comes in. If a manufacturer understands the questions they are being asked and in a language that they are familiar with, they are much more likely to be able to provide the right information to answer the question.

This is the concept behind PDTs and PDSs (Product Data Templates, which become Product Data Sheets when completed with a manufacturer’s product information). Originally developed by CIBSE, the PDT Steering Group now consists of representatives from other professional institutes, content providers, BIM4M2, BIM4 Fit Out, BIM4Water and BIM4DC (Data Centres). The focus is on having a cross-project team that has experience of a product or system type to develop templates based on what is required to effectively deliver that product, in commonly used language that is accessible to all. The BIM4M2 Data Working Group is working with others to significantly broaden out the reach of the templates to other product types.

In developing PDTs, the starting point is always COBie or SPie (Specifiers Product Information Exchange) templates where they already exist to ensure the minimum information requirements are met, and direct links to open standards. However, to maintain accessibility the complexity of mapping from the Plain Language Questions to these standards can, and is dealt with away, from the simplicity of the main data sheets.

The sheets are developed in a controlled environment between members of the design, manufacturing, contracting and FM communities, and then opened out to industry for wider consultation, meaning that the templates are created for industry, by industry.

There can be location-specific or sector-specific PLQs, all which are completed in Excel, and can then be used across all software platforms.

One of the key benefits of this approach is that the information only needs to be supplied by the manufacturer once for every product, and it can then be used in many applications, with project teams defining what information they require at each project stage.

The format can also be used as part of the selection process to filter products that meet the specified requirements. This may be achieved in the UK through the likes of the forthcoming Digital Plan of Works (DPoW), which whilst not mandated is likely to be used on public projects and will be a useful tool. However, as manufacturers who supply products into different territories, we need to provide data in a way that can be used in several formats and platforms, thus supporting both the Government’s 2025 Strategy to increase exports of construction products and those private sector clients in the UK that are already using alternative approaches to developing MIDPs (Master Information Delivery Plans), and different formats of information. By providing information in a format that can be easily mapped to suit these differing requirements we are likely to arrive at a more efficient solution all round.

For more information on Product Data Templates, visit or the BIM4M2 website.
Steve Thompson RIBA
BIM4M2 – BIM4 Manufacturers and Manufacturing


Please enter your comment!
Please enter your name here