Analysis

BIM and Brexit – there’s more in common than you might think

Engineering consultant Tony Marshallsay finds commonalities between the problems facing BIM – and those facing the UK if we do leave the EU.

BIM’s biggest problem is the same one the EU had: lack of common standards. Over decades, the EU has gradually managed to harmonise most of the important national industrial standards and trade documentation, making just-in-time collection of parts and assemblies from all over Europe (not to mention the rest of the world) for assembly in the UK feasible and profitable.

If Brexit now succeeds and the UK secedes from the EU, all that good work will have been for nothing, because separate new UK standards will threaten to undo those solutions by encouraging other countries – those the Brexiteers are looking to for support – to do the same.

The BIM community has started to follow the example of the EU by beginning to harmonise project documentation, but it has yet to take the next and arguably most important step: standardisation of common, open data file formats – not only for 3D BIM objects and related 2D working (aka “shop”) drawings, but also for all the other types of documentation needed for a fully digital construction project.

As I wrote in an article for BIM+ previously, standardisation is hugely important. Why you may ask? For the answer, we need to learn a little history.

CAD – Computer-Aided Design (sometimes seen as CADD, because originally designers designed and sketched, leaving draftspersons to develop tidy drawings) – originated in the 1950s, when airplane and automobile manufacturers were the only commercial organisations that could afford the big, expensive mainframe computers needed to produce and view even simple wireframe designs. Each computer manufacturer developed its own software (and proprietary file formats).

Then came transistors, ICs (aka chips) and PC workstations that became so capable the mainframe CAD software migrated to them, eventually being spun off, together with the proprietary file formats.

That wouldn’t matter, if an architectural and engineering consultant (AEC) in the construction world could produce a whole design in-house, using its chosen software partner’s proprietary ecosystem, but today projects have grown so big and complicated that AECs have had to specialise in particular sectors: architecture, structure, M&E services, finishes and so on.

Since these specialist AECs have usually been spun off from previously fully-capable AECs, they have often stuck to their heritage CAD software, now posing the problem of how to create a federated BIM model using objects created in a multiplicity of incompatible proprietary file formats.

Yes, it is possible and yes, it does work, but at what cost?

The specialist AEC has to export the data in a format acceptable by the AEC hosting the federated model, and/or the host must be able to read all incoming data, whatever its format.

This means:

CAD software packages are bloated with format translation modules, which must be updated whenever any proprietary format is modified/updated. If such updates are not performed promptly, there is a good chance of errors occurring.
Processing time and the associated electrical energy are both wasted in performing the format translation (not to mention any parasitic encryption and decryption because people are paranoid about data security).
Display refresh latency is increased, because any real-time changes made by remote specialist AECs must also be translated, reflected by the host, then the updated model image re-translated before transmission back to the editor.

It is almost impossible to create a distributed federated model, with each specialist AEC responsible for hosting its own content, because the amount of format translation required would increase latency so much as to be intolerable. The alternative – the specialist’s model segment being held as copies in each of the various formats used on the project – multiplies the server space required.

Now, look at what could happen if all AECs were using the same file format, or a specialist formats designed to be compatible with a common, open standard but incorporating additional, specialist information:

Since all AECs would be using the same format, or one compatible with the common standard, they could freely read and exchange the standard information.
Updates to the standard format could reach all parties by simultaneous prompted download from the common standards host, meaning that everyone is always up-to-date.
No processing time or energy wasted in translation, so display latency would be minimised (but any encryption overhead would remain, perhaps becoming a bottleneck).
In the hopefully not too long term, it would be possible for software vendors to offer cheaper “standard formats only” packages, with add-in translation modules as optional extras.
Most importantly, a distributed, federated “cloud” model, with 24/7/365 access from anywhere – essential in today’s world – would become a practical reality, with these benefits:

Each specialist AEC would become responsible for their own portion of the project BIM model, having to “vet” all external requests for viewing or editing, as any failure to do so resulting in a contractual consequence would incur clearly identifiable liability.
The specialist’s model segment would only need server space for data held in the single, common format.
Segmentation has the potential to accelerate updates to the federated BIM model, as there would be no need to lock the whole model for editing an object in one specialist segment, so multiple updates could take place simultaneously.

But what about all those jealously guarded proprietary file formats that have created, protected and supported the big vendors’ software ecosystems for decades? Wouldn’t common file formats for drawings (and project schedules, costing, manpower and logistics…) destroy that business model?

No, because what makes users keep buying into proprietary ecosystems is not the file formats, because they don’t see them (unless they’re creating their own special-purpose interfaces to them, which the vendors usually deprecate), it’s what they see as ease of use: the user interface (UI) and the associated user experience (UX). “One person’s meat is another’s poison” holds as true for construction and CAD software ecosystems as it does for Apple and Windows.

So, in my opinion, the software vendors have nothing to fear from ditching their proprietary file formats and moving to a single, open format for each category of construction data, to take the brakes off BIM and let it fly.