Exchanging data on a BIM project can be traumatic to say the least. At least in the CAD world, the majority of information was exchanged via graphics only. With BIM there is a whole other dimension (sic) of data, either linked or embedded into the objects. The challenge is especially obvious during the iterative design phases of a project, when information is fluid and disparate tools are being used, but continuity is essential. The following is a guide to various “collaboration” formats that can be used to exchange data between “incompatible” software.
Firstly, I should note that I will not cover “collaboration tools”, the collective name for review software including Navisworks, Navigator, Solibri and others. These are not really part of the data exchange process; they are typically used as an end point (there is rarely export back out from these tools) for review, coordination and clash detection, to aid in the design process but not exchange data. The definition used for a BIM format is “a format which allows exchange of model or non-graphical data between two or more BIM tools”.
The Industry Foundation Class format was developed by the International Alliance for Interoperability (now BuildingSmart) as an “open format… it is neutral and independent” and is detailed in ISO/PAS16739. It is a text-based format that simplifies proprietary element types into standardised classes of object. Geometrically this can be both an advantage, as it typically means dealing with re-import of data is fairly straightforward, and a disadvantage, as bespoke components cannot always be classified as the generic IFC classes require. Even in terms of common components this simplification can “group” dissimilar items as one. For example IFC has only an IfcColumn member, and cannot differentiate between steel and concrete, despite either type requiring totally different structural treatment. Architecturally, IFC has no way of classifying a partition wall from an external brick wall.
It should be noted though, that the big advantage of IFC is the data it provides with these basic classes. The analytical or performance data of either example above is maintained within the objects in a consistent structure, allowing any IFC-compliant software to read and utilise it. IFC is a far more robust way of exchanging metadata than it is geometry.
IFC files can be large compared to the original model, as much as 4 to 6x larger than their DWG or DGN equivalents. Various IFC optimisers can be downloaded to reduce this increase in file size, although IFC will always remain larger. For example, a free IFC Optimiser is available from Solibri (http://www.solibri.com/solibri-ifc-optimizer.html). IFC editors are also available, such as SimpleBIM (http://www.datacubist.com) to “tidy up” or “fix” troublesome IFC files before sharing.
WORD OF ADVICE:
IFC is very rarely the most accurate method of exchanging BIM files and data. Because of the interpretations of the IFC schema, the results, including the coordinate location of the IFC model, can differ when importing an identical IFC into different software.
Yes, these two “CAD” formats are perfectly acceptable for exchange of BIM data. The main advantage they offer is that they are widely adopted, providing in most cases, excellent preservation of geometry even when translated to the other. The ubiquitous DWG is imported and exported by all major software, with DGN now close on its heels. Certainly between the Autodesk and Bentley worlds, the choice is no longer limited, and in fact the smaller and robust DGN format is often more reliably imported into Autodesk products than Bentley is able to export a DWG. Food for thought indeed, when most DGN-based practices spend many unnecessary hours trying to convert their data into an identical DWG.
On the data side, DGN and DWG both support hyperlinks, meaning that additional data can be linked into the model and maintained through translation. Hyperlinks, rather than adding metadata directly to an object, allow models to remain lightweight, and also provide advantage for easier management on specification data outside of an expensive BIM authoring tool. When it is more efficient to store data with an object, Attributes and Tags can be used. Both translate well into the other format and can be easily exported to Excel.
With the release of Revit LT, which doesn’t support IFC, it may be that smaller projects see a resurgence in the use of CAD files to exchange data. Either that or we’ll see a return to the days of it being a contractual requirement to use the RVT format for data exchange.
WORD OF ADVICE: Do not use DGN and DWG as an issue format for drawings; for that use PDF. DGN and DWG are most successful when sharing model data as references.
The I.DGN format, or i-model, is a recent offering from Bentley, designed as a compact, read-only method of exchanging models and metadata between their own authoring tools and review software. I.DGN is totally self-contained, offering dgn-based geometry that can be ported out to mobile devices as well as referenced or imported (as cells) into a wide range of products. The data can be interrogated very effectively through MicroStation’s Item Browser, from which it can be exported to Excel.
With a free plug-in (downloadable fromhttp://www.bentley.com/en-US/Promo/Revit/i-model.htm), I.DGN can be exported from Revit, providing a trustworthy method of integrating Revit models into a Bentley-based system.
WORD OF ADVICE:
Do not be fooled by the “.dgn” extension. An I.DGN is not compatible with products that can read DGN.
RVT is the native format of Autodesk Revit. It is a proprietary database rather than a traditional file which typically contains a complete project rather than a floor or component. For communicating between the various flavours of Revit (Architecture, Structures and MEP), RVT is the natural choice as the data will remain in the format it was created in, with full graphics and data integrity.
Because it is a database, objects can be managed in a very flexible manner. Revit users are familiar with the concept of “Worksets”, the method by which a large RVT model can be “broken down” and shared out between a project teams. Coordinating the changes back, however, may be more challenging.
Beyond the Revit suite, there is currently no software that will import or even reference RVT files. Autodesk is keeping the format strictly to itself which on one hand is a shrewd business strategy, “encouraging” the market to purchase Revit should full integration be required, but on the other – the reality of day-to-day BIM projects – it limits communications and collaboration. Model and data exchange needs to be carried out through other formats.
WORD OF ADVICE:
Converting between RVT format and other software packages via an intermediary format needs careful testing before deciding on the best route to take. In all situations it is highly unlikely you will find a single satisfactory round-tripping option, but then it is also rare that design data needs to round-trip. Typically referencing (linking) data is perfectly adequate.
COBie stands for “Construction Operations Building information exchange” (no, I don’t know why information exchange is lower case) and is intended for the complete lifecycle of a project. Simply put, COBie is an Excel spreadsheet of all the project data.
Having the data in a universally, or virtually universally, accessible format provides, in theory at least, major advantages as it allows data – only data, there is no graphical aspect of COBie – to be exchanged regardless of authoring software, technological complexity or size of the project. In reality, producing a COBie file can be something of a major challenge, not only with the formatting of the 20 worksheets in a COBie file, knowing what should go where and the sheer size of a large project listed out as individual components in a single spreadsheet, but also with regard to terminology. Rationalising object names and mapping them to something understandable when importing the data into other software might prove to be difficult. I say “might” as I am currently unaware of any projects where this has been done.
Tools are in production for converting models to COBie: there is a Toolkit for Revit that assists users with producing COBie output; Bentley are working on an exporter; and converters to build COBie from IFC files are in production. It is still early days, and the challenge isn’t only restricted to export, but importing the data once in COBie format. As it is an Excel-based format, all it requires is a person versed in any programming language to be able to take advantage of the data within the file.
WORD OF ADVICE:
As with all things BIM, consider your requirements for any form for data exchange. COBie is a means to an end, not an end in itself.
Linked to directly to IFC, and also developed by BuildingSmart in its “OpenBIM” guise, the BIM Collaboration Format is an extension to an IFC file that “introduces a workflow communication capability” – markups to you and me. What BCF proposes is the ability to exchange only the issues rather than the whole BIM, but is currently only supported in very few software packages.
WORD OF ADVICE:
For the comments contained in a BCF to be of any use, it would require a single collective review of all disciplines’ models. To do that you’d need to exchange the full BIM geometry anyway.
- IFC
- DGN & DWG
- I.DGN
- RVT
- COBie
- BCF
There are many other exchange formats, designed with certain tasks in mind: CIS2 for steel exchange, gbXML for energy analysis, and so on. With these and so many other formats, the utopian idea of a “single building model” is further and further from the reality.
In all cases, and to be fair, continually asserted by BuildingSmart as essential, is a well-defined data exchange requirement. Most problems related to BIM exchange occur when requirements are not clearly defined. It is all too easy to naively request information that is either unimportant or not known at the current stage. Adoption of BIM requires at least some consideration be given to the typical “inputs” that your company requires for progression of design “outputs”. If these requirements can be set out prior to work beginning, they can form the basis of a project BIM Execution Plan, the document that “defines how the modelling aspect of the project is to be carried out and how the model and data are formatted” (from the AEC (UK) BIM Protocol v2.0). More on this next time.
It is too easy to believe “just because you can” that you should. Yes, it may be necessary to use multiple formats, as there is no single definitive BIM format, only formats better suited to particular tasks.
Identify your requirement, and that will allow you to identify the best format(s) to use. QED.
Photo by Neven Krcmarek on Unsplash