As complete and accurate as a BIM model can be, at the end it is only a recipient of information, it can’t speak for himself; so in order toget the message through you need something else, you need to tell the story. BFC files do exactly that: they tell the story.
BCF files tell stories about Design by providing clear communication. The way it works is by creating “issues” with “comments” written by “authors”, then adding snapshots and then linking the issue to building elements. These comments form the body of the discussion and the story of a design issue; the author field or parameter helps recreating the dialogue and the snapshots helps everyone to see the issue graphically. All of this helps design managers to keep track of issues as design evolves and gets fine tuned, and it saves time by sending a clear message about changes across disciplines.
Again, clear communication is critical as many interpretations can be given to badly modeled elements. Models can’t certainly speak for the elements that are not in place; and even with software that can differentiate new and modified elements from the rest you still need to provide a contextual argument to enrich the message and reveal the design intention. It is true as well that at some point you will have to discuss, mark up and register the changes and issues of every design iteration between trades. You already know that design coordination goes beyond clash detection, and you should know how important is to keep track of changes. BCF files also do that: they keep track of issues – regardless of software authoring platforms.
An acronym inside an acronym
BCF is an acronym for BIM Collaboration Format, and what the file format does is to store the history of design Issues as a database without storing model elements of any kind. In essence it is a list of Issues (by name) of the models, enriched with Snapshots (images), Comments (by authors) and Status, that can be linked to building elements (via GUID).
The file format is actually BCFzip not BCF and it’s based on the XML schema . It is similar to the AGCxml format for RFIs developed by the Associated General Contractors of America, the similarities may be intentional. Being XML based makes it “modular” so it can grow by adding to it without having to overwrite it completely, and it have been proved reliable and useful by the AGCA. BCFzip files can be open /saved only from a bunch of applications for now (as per May 2014) including: Tekla BIMSight, Solibri, Graphisoft ArchiCAD18, DDS-CAD natively, and by Plug-ins like KUBUS BCF Manager or Matteo Cominetti’s BCF plugin for Graphisoft ArchiCAD and Autodesk Revit and Navisworks respectively.
The origins of this file type are not completely clear to me, but I have found that Trimble Tekla and Solibri have developed the BCFzip until now. Other companies have jumped in and are adopting it and developing software to work with it. At the time I’m writing this, Tekla and Solibri are willing to transfer the rights to BuidingSmart Intl Ltd for adoption as an Open Standard like the IFC. If it happens it would fortify the OpenBIM movement and process, reaching out not only to designers, but to project managers as well.
A model Messenger
The BCF is a Communication tool not a model container. When you use it for Coordination between disciplines it offers a “BIM-like” communication flow: it relies on the Model to reveal issues while enriching the discussion with full size text comments. As comments gets added to the file by different parties the file documents the history of the discussion without actually containing any model elements. A particular feature that makes it great for collaboration purposes is that the Issues save their Views both as image and a camera position, so by clicking on an issue your software will take you to the view where the issue is happening*. It can also be linked to the Building/Model element, so it will also select/highlight the problematic elements. You can see BCF files to be Messengers that work on top of Building Models not from inside, this very feature makes it almost software-brand indifferent.
Use and Impact on Projects
Enhancing team communication with BCF files proves to be very helpful to project coordination, and this applies to most project stages, size and teams. Technically speaking you could exchange BCF files as soon as you start exchanging IFCs; that is as soon as different disciplines start to get involved. If we are in a IPD project, this could be as soon as Schematic Design; or in a more traditional design process, the exchange may happen in the Design Development stage or even as late as Construction Documentation.
The size and location of the design team may be a factor to be considered, BCF files may be more valuable for larger teams where tracking design issues is more difficult. Same applies to design teams located in different cities, combining teleconferencing and screen-sharing with the use of BFCs helps tracking design issues.
Design issues followed up with BFC files are probably easier to solve and close than those followed by means of e-mail for example, and it provides an industry standard format for design coordination.
Using BFC files in a practical example.
Let’s simulate the lifecycle of a design/coordination issue using a BCF file from an architect using ArchiCAD, and Engineer using Revit and a Project manager using BIMSight. We will start an Issue from the Project Manager (PM) side using BIMSight doing a visual check of the project by checking the Architectural model with the Structural model, both on IFC format. Then we will send the BCF file to the Engineer for comments and then to the Architect, then finally back to the PM for closure.
Before we start, here is a short list of the software we have used for this example:
- Graphisoft ArchiCAD 17, with KUBUS BCF manager ( Add-in)
- Autodesk Revit 2014, with Matteo Cominetti’s BCF Manager (Add-in)
- Tekla BIMSight
And here are a few assumptions in order to be able to work with BCF files :
- All the parties have access to shared models in IFC format, or
- Have their own model located in exactly the same coordinates as the IFC model (likely using the IFC for Reference).
- The discussion will be started, continued and solved trough the same BCF file.
Let’s start the exercise, here we are with a project I’m working on at the moment, trying to coordinate the Structure and the Facade:
Now, we’re creating an Issue to send it to both the architects and the engineers.
As the Engineer, here we have the working file natively in Revit and we will open the received BCF file ( via e-mail) with Matteo Cominetti’s add-in BFC Manager.
Then we will respond by adding a comment, committing to a fix for the next file exchange and sending a screen shot of how it may look.
The reply is now sent to the Architect for comment, here the native file is in ArchiCAD, and we will review both comments: the initial from PM then the response from the Engineer.
Now we add a comment to check the actual distance and request additional changes to the Engineers.
We have sent this comments to all parties, and now from the PM we will review and close the issue, expecting changes from a new ifc file.
On the good side, the flow seems to be fairly simple, there are no strange commands or features difficult to learn. On the bad side, some of the features available in one software are not translated to the others, the most critical one being the fact of not being able to re-create the cutting planes, or section boxes to cut the model in 3D and be able to give the counter part an exact live point of view in their model, they will have to rely on the snapshot and try to make it work from their software.
Some features are very nice in BIMSight, like the possibility of creating several snapshots of the same issue. Sadly when saved as BCFzip only the first snapshot is saved. The views are often saved in Perspective or camera view – as this is the native way of working in BIMSight, Solibri and ArchiCAD- Revit in the other hand is limited with camera views, being easier to work with Axonometrical views it sometimes takes long to open a view from the BCF. Note that nothing prevents you from doing it all in axonometric, but still not the most common / easier way to detect most issues.
Overall it looks promising specially for tracking issues after along period and/or among a large amount of them. If the developers manage to get a cleaner workflow that ensures a complete transmission of what you can see on the screen, then this will be a hit.
Let see if it stands the test of time and users.
*quoted from Sydney Harris