In the last post, I briefly talked about the importance of issue tracking, and the current limitations of issue tracking within modern AEC applications. Now I’d like to take a look at one of the proposed improvements to issue tracking, the BIM Collaboration Format, or BCF if you are cool. Advocates of OpenBIM argue that this format will allow us to more easily exchange and manage issues in AEC applications, but I’m not so sure…

What up BCF?

In 2010, Tekla and Solibri collaboratively developed the BIM Collaboration Format (BCF) in an attempt standardize how issues are shared between various authoring and analysis software used in the building industry. Essentially, it is an exchange format with xml roots that contains images, camera positions, comments, and basic meta-data like status, assignee, elements involved, and authors. In theory you should be able to identify an issue in Tekla, save it as a BCF file, open the file in Solibri, and see exactly the same issue appear on screen with the ability to add a comment that can then be shared back to Tekla.

The original BCF concept is fantastic! However, in the last two years or so, BCF has transformed from a simple format that transfers comments attached with views, into a format that is fully capable of documenting and sharing issues found throughout the building process. We see a lot of potential in BCF as an exchange format, but not as the solution to track the lifecycle of issues.

We see BCF playing a huge role in carrying a ton of valuable information about an issue between a database and various applications. Is BCF ready to do that now? In my opinion, it’s too limited right now. Could BCF become the widely adopted format for exchanging issues throughout the project? Absolutely. The current limitation of BCF, specifically version 1.0, lies in both its schema and its implementation by vendors.

BCF Schema Limitations

There is always room for improvement. The highest priority when BCF was developed was to prove the format could transfer issues between software, so I understand why there are some loose ends; however, with the BCF 2.0 under development, I hope there is a serious review of 1.0. We have been developing applications that generate a BCF over the past year and we have ran into numerous limitations with the schema, which has caused us to extend the schema by not only adding fields, but also accounting for the deficiencies in BCF 1.0 and for the poor implementations of BCF within Tekla and Solibri.

The BCF schema is really straightforward. A “BCF” file is actually a filetype of .bcfzip which is a zipped folder of folders. The folders inside the bcfzip are named after each issue’s GUID. Inside those folders are 3 files – a markup.bcf, a snapshot.png, and a viewpoint.bcfv. The markup.bcf is where most of the information about an issue resides. In a markup.bcf, you can access information about the models used, about the issue, and about each comment on the issue. The viewpoint.bcfv contains all the information about the camera, about the elements in the view, and the software used. An example of both the markup.bcf and viewpoint.bcfv under the BCF 1.0 schema generated by Solibri look like this:

Markup.bcf

Viewpoint.bcfv

Opportunities For Improvement

So how can the schema be improved? Well the following are just a handful of opportunities for improvement. Lets start with the Markup.bcf.

Markup.bcf

• Issue title / Topic does not have a property to order the issue in a sequential way. Instead, the only ID for the Issue is a GUID, which when sorted it sorts in a random order. Since this does not exist, there is no way to refer someone to a specific issue like Issue #24 no matter if the issue is in Solibri, Tekla, Revit, etc.
• Comments have statuses instead of the issue having the status. A lot of the time, the properties of the last comment drive the properties of the issue. This requires a high degree of confidence of any person that makes a comment on an issue. If they make a comment and keep the default status or choose the wrong status, that wrong status will now replace any status set before the comment was added.
• Status is a bit confusing and is often not used. There are four predefined values for Status – Info, Error, Warning, and Unknown. Neither Tekla or Solibri actually use this property, which begs the question – should it be deleted? In replace of Status, most software vendors use Verbal Status because it is more helpful and can be set to any value the user defines.
• Priority of an issue is not supported. During coordination, there are issues that are critical and issues that are very minor. Having the ability to attach a priority to an issue in BCF would be useful. Without priorities, you are left to sift through a larger collection of issues that may be irrelevant to you.

Viewpoint.bcfv

• Component information is captured in the Viewpoint.bcfv to allow the isolation or selection of components involved in an issue. There is however no distinction of whether the component captured is a Selected component, a Visible component, or a Highlighted component. I think there needs to be support for all three of these options instead of the option being left up to the vendor to decide which to implement. As you will see in the implementation inconsistencies below, this does not work out well.
• Camera information is also captured that helps define whether the view is an orthogonal or perspective view. One property that is very undefined is the “ViewToWorldScale.” Currently it is a single value to represent the scale, but as you can guess the scale of a view in Solibri is very different from the scale of a view in Tekla which then does not exist for a view in Revit and Navisworks. A lack of definition around this requires workarounds to get the view mostly identical.
• 2d views are not supported, but it seems to be an area that 2.0 will support. Currently there are a few tools, including the tools Matteo has built that extend the schema to support 2d views. These BCFs though would not work with any other platform that supported BCF without having a plugin that understood the extended version of BCF.
• Markup information is not supported. Orienting a camera is valuable, but you often have to add text, bubbles, and dimensions to the view to further explain what the real issue is. Capturing those markups can add a lot of value when transferring from platform to platform. If the markup information is only captured in a single image, there is a risk that the markup information can be deleted by updating the snapshot. Supporting markup information though can be a tough task as it requires the platforms to expose that information. It gets even more complex when you realize that some tools markup views in 3d while others markup directly on the camera plane.
• Multiple Viewpoints and Snapshots are not supported. This for me is a big one. No one likes to review thousands of issues when they are essentially 10 issues. I talked about this in the previous post about the granularity of an issue. A picture is worth a thousand words but 2-5 pictures tells a story. It also lessens the load of managing issues.

BCF Implementation Inconsistencies

Even though Tekla and Solibri were the original developers, the two vendors implemented BCF in different ways! What do I mean? For example, if you export a BCF of the same model of the same issue from Tekla and from Solibri, the BCF will have different values and structured slightly differently. Even worse, if you export a BCF from Solibri and import it right back in, data is lost and issues are sorted in a random order.

• Camera: When sending a BCF between Solibri and Tekla, camera positions do not match due to a fundamental difference between how the two software generate camera views.
• Components: Solibri and Tekla also differ on what elements are captured in the viewpoint.bcfv file. For example, Solibri captures the Element IDs of all Visible Elements in the view (could be 10,000) while Tekla captures the Element IDs of all the Selected Elements.
• Issue Title: Solibri has no Issue Title. Instead it takes the value of the first comment on a slide. Because comments can be long, Solibri takes a maximum of 20 characters from the comment and applies it as the Issue Title when exported as a BCF. Tekla’s Issue Title is labeled Comment.
• Issue Status: Both Solibri and Tekla use Verbal Status instead of Status. In Tekla, the Issue Status is labeled as Tag.
• Issue vs Note: The name of a BCF issue varies. Solibri appropriately calls it an Issue, but Tekla calls an Issue a Note.

It is very surprising that though the two originally developed the schema, they interpret it differently. This causes confusion when both working within the various platforms and when developing workflows between them. Is this an issue with the schema or an issue with the implementations?

Unfortunately, both Revit and Navisworks do not natively support BCF. There have been a few addins that have been created though. Matteo’s free Revit addin and CASE’s free Navisworks addin (by Matteo) both tap into the software’s API in order to create and read a BCF. I just wish Solibri had an API.

Latest BCF Developments

As I mentioned before, we are interested to see how BuildingSmart will improve BCF as they flush out the 2.0 schema. We know how we would fix it. A number of the issues I mentioned above with the 1.0 schema are being addressed in 2.0. We are particularly excited about the multiple viewpoints per issue and support for issue markups, although the issue markups is in 3d instead of 2d. The documentation for BCF 2.0 can be found here: https://github.com/BuildingSMART/BCF/tree/master/Documentation

Another development in the works is a project called BCF Server by the OpenSource BIM Collective. Equipped with a web service API, it is a plugin for WordPress that allows you to use WordPress, a content management system, as a makeshift BCF repository. I have to say I am interested to see where this one goes, especially since it is connecting to BIMserver.org.

Soooo… what are you saying?

At the end of the day, as great as BCF is, it is just a file format and not a central repository. It is the way we structure issues as xml data and not how we track issues. We need to be able to rely on it to move our issues, and any data we find worthy to ship with them, to the application of our choice. In BCF’s current state, it requires extending the schema and developing exceptions to account for poor implementations.

The resting place of an issue and its data belong in a database where we can gain a higher understanding of the project by analyzing the interrelated data. Next I’ll show you how we at CASE approach issue tracking by extending the software we use to find the issues, using BCF where we have to, and by customizing tools used by other industries.