Our journey with model data update

A question was asked on Linked in about experience of creating COBie data and software used. Rather than post a reply, solely in Linked-In, I thought it would be good to make our experience public.


Here is a sketch of our experience and developments linking models with external data.

We developed a briefing application “IMPACT” for the Education Funding Authority one feature outputs their brief as a COBie drop briefing stage. This a web-based application which we have added a web data service onto. We have developed a Revit Add-in that allows a model to be connected to the brief via the web data service.

The Add-in can map to existing rooms in the model and or add new ones. Once connected, when a user clicks on the room an information window inside Revit displays the brief requirements. We have extended this to compare fixtures placed in the room with those required in the brief and this is displayed in Revit by RAG (Red, Amber, Green) on the plan.

In addition room data in the model can be compared with the brief and the spaces RAG on the plan.

The user can edit their solution values from with inside Revit because they have connected using their login details so IMPACT knows who they are and what rights they have.

When COBie is produced either by using the Revit tool kit or by using IFC then getting a COBie model view we have attributes against each space this allows us to map back to the Briefing COBie data and federate them.

As a recipient of Handover data we are very concerned about who is creating attribute values. In early design stages any attribute information should be about requirement and when products are selected these should be compared against those requirements. For this to be done digitally it required specifications to matched up with product data.

Product Type templates produced by BuildingSMART UK and the US are the starting point for product manufacturers. However Organisations like CIBSE have developed Product Data Templates for product types which are specification orientated. We view these 2 templates as being part of one, just different ways of display and describing a single product type data set. To test this we have built a template application and populated it with 700 UK product template types from the COBie task force site. Then looking at some of the draft PDT’s created a PDT export to spreadsheet for any of those templates.

The stage I’m currently working on is the Product Library all based on the IFC Product Data model. This is an application that stores all the product information and associated media including models, photographs, maintenance and specification data. Rather than being just a product library it will be able to harvest other product libraries using web data services. It will also be able to extract data from suppliers IFC models, import from spread sheets. (I’ve already had a play at doing this). This application uses a relational database and any large organisation will be able to either map their data into it or import their data .

The concept is that each organisation runs their own product library. A supplier will run it as a data-service from which others can harvest data. For designers, contractors and building owners they will harvest data. Some organisations may offer a hosting service and because it is an open source project developers will be able to enhance and integrate it into their existing offerings.

So far, in the Product Library, we can create suppliers, products, catalogues, maintenance regimes, attach media and most importantly fill-in attribute data. This week I have been creating a PDS (completed PDT) and COBie output spreadsheet. A very important part of this work has been to ensure the Master Template can be extended with other attributes and property sets that are important to other parties as we are working in an imperfect world and no template will be perfect.

I have a working export of a product data into the COBie Spread sheet format populating Contact, Type, Attribute, Job, Resource and Spare sheets. It is will be easy for this application to generate COBie data export to the project specific naming convention if the TYPE Name in the project is known for example [Lochinvar_Copper_Fin_CB_1435] becomes [Boiler].


The final stage is to then work on the Project Service which will use products from the product library and store key locational information which is managed from the modelling applications. Systems and Product types can then be mapped and managed from either end using web data services liberated from any single application.

In Revit we know how to add keys to families and instances elements in the model and we have experimented with connecting these to the Project database via the web service. This over comes any upgrades to the model and reliance on the instance keys changing. It maybe that we only focus on key manageable assets rather than the whole model but this is a step by step approach.



2 thoughts on “Our journey with model data update

  1. Hello Timaikin,

    I really like your idea and Model Data workflow by using PDTs to collect as-built information of the components (pumps, tanks, AHUs, etc.). When I was exploring CIBSE and seeing several draft PDTs, I had the same idea that you have as well.

    I’m currently working for a GC in the US and typically, the GC and subs are the ones who collect the as-built information of the components during the construction process. Looking at the draft PDTs, I see they are not user-friendly for us, as information miners, to input the data. To solve that problem, I’m working on modifying the PDT to match with one of our client’s BIM guideline (i.e. USC BIM Guideline, COBie section) and hopefully will be more user-friendly and customer-oriented.

    Also, during the construction submittal process, for example, pump submittal, the as-built information of the pump is presenting in the submittal documents for approval by the designers (mechanical engineers). I see implement the modified PDT into this pump submittal document as a summary table on the first page will definitely help gathering the required data for the PDT. Using this process can control the quality and accuracy of the data because it is checked by the engineers and also eliminate any double entry or re-gathering data down the road.

    I’m really glad that we have the same great idea and would love to learn more from you. Please send me an email at oceanv@dpr.com if we can work together on the PDTs.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s