BIM is the acronym for Building Information Modelling – the integration of non-graphical information into the 3D design of a building: right-click (or maybe just hover the mouse pointer over) any BIM object in the model and you can find out everything about it.
However, since the term was originally coined to describe what is covered by that narrow definition, its scope has rapidly expanded to encompass not only the design of the building, together with the planning and costing of its execution and all the related documentation, including building and occupation permits, but also the associated design of the surrounding landscape and of the infrastructure serving it and with which it must be interfaced.
It would therefore seem appropriate to redefine BIM as Building Information Management, to properly reflect this expanded remit.
But there is a further expansion of scope which must also be considered. Since “smart” BIM has become more widely adopted as a replacement for the 2D designs which have been the norm for centuries, it is now used not only to describe projects comprising more than one building, but also civil and municipal engineering, transportation, communications and other projects which may have no “buildings” at all.
Consequently, it is time to consider introducing yet another TLA (Three-Letter Acronym): PIM – Project Information Management – which would allow the original definition of BIM to be retained.
Why? Because, although the general concept of BIM is agreed and has been codified by various interested bodies – in UK as PAS 1192, and in US as the National BIM Standard-United States (NBIMS-US) – in the real world commercial interests rear their ugly heads.
The long-established players in the 2D and 3D CAD design market have now incorporated BIM packages into their respective “eco systems”. But unfortunately, because each eco system and purchased software package typically has its own proprietary data storage format (a padlock on the exit gate), assimilation of the latter into the former has often been fraught with difficulty.
Thus, the BIM packages offered by the big names in CAD are generally in the same position as regular CAD packages offered by competitors: at the opposite end of a translation process which, although necessarily converting the indispensable basic design information from the source data storage format to that of the destination, will inevitably lose any additional information which was not considered essential by both parties.
At present, in order not to lose market share, the major players must grudgingly provide for export into and import from at least the most widely used competing industry standard formats, together with the few “open” formats which have been developed.
Large projects, which may consist of several sections and buildings, are now commonly designed by a consortium of designers with their construction managed by a general contractor and executed by a multiplicity of specialist subcontractors, all of which may be using different BIM and ancillary software packages.
If the now obvious gains in speed and efficiency, together with cost and waste savings, achievable through BIM on an individual building are to be maintained when that building is part of a larger scheme, industry-wide adoption – not just acceptance – of common, open data formats is essential to optimise information exchange, coordination and management of all the individual project modules.
Read related articles
The evolution of BIM brought to the forefront two major issues: the scope, size and manageability of the Common Data Environment (CDE); and maintaining its integrity while facilitating reference to it.
It seems quite clear that the CDE of any project should contain everything directly related to it – but it is also unreasonable to expect any one software package to be a “jack of all trades and master of all” or the parties to a contract to put all their eggs in one basket with a huge data server in one location.
The solution, already being implemented, is to have a federated CDE, with major divisions being held on large, high-speed servers, either at locations under the control of the major parties or, increasingly as time goes on, in the cloud at secure data centres.
To maintain the integrity of the CDE, it is important that direct access to any part of it is only granted to those responsible for its maintenance and continual updating. Consequently, it is advisable to have working copies of the CDE files held locally at agreed centres, to be updated according to recent new information or documents and verified, prior to being used to update the CDE itself.
To prevent unauthorised tampering with the information in the CDE, it is also best if reference is not made directly to the local working copy in its original format, but rather to a facsimile which has all the functionality necessary for a given purpose – for example, review of the 3D layout of medical equipment within a hospital Operating Room – but permits the addition of markups and remarks.
This second-order copy functionality has for many years been provided by PDF (portable document format), a formerly proprietary but now open standard, which has been continually evolving to keep pace with the development of BIM. Pdfs can now display images of BIM models and associated documents, still preventing alteration of the original, but with extensive capability for viewing, interrogation and markups.
Unfortunately, however, there are now cloud software packages which, while claiming the capability to be able to convert “seamlessly” to and from the open PDF format and the various proprietary design and document formats, actually store the BIM information in their own proprietary internal format. Thus, we are again seeing attempts to entrap unwary users into ultimately expensive closed eco systems, with further security concerns.
It is therefore of utmost importance for the widespread and effective implementation of BIM and PIM that only one or two open data file formats are agreed for each type of construction activity – with enforcement by legal standards if necessary. Some already exist and must be actively promoted, while others must be swiftly developed.
Because BIM/PIM involves the handling of much bigger quantities of data than were customary with the previous fragmented 2D designs, it is essential for high performance that unnecessary processing is eliminated as far as possible.
One simple way to do this would be to require each software package to use only the appropriate “open” data format appropriate to its scope. While this would no doubt raise howls of anguish from those developers with a highly proprietary mindset, one might well ask whether they were justified.
Looked at from the software user’s point of view, what is important is the functionality of the software, not how it is implemented within the computer “black box” behind the screen, nor how the necessary data is stored. Thus, what is really proprietary is the software’s user interface: its ease of use; the time-saving facilities it provides; and, in particular for BIM/PIM, its speed.
There’s really no reason whatever to hang on to proprietary data formats, so let’s have a level playing field – one common, open data format for each information sector – and let each user decide which software vendor’s package has the right characteristics, suitability and performance for the task in hand.
Then no worries at all about data exchange or waiting for file conversion – and “sorry, it’s been lost in translation” will be a thing of the past.
