You’ve all heard the news by now, I presume. I certainly hope you have. The UK Government will require all its projects to be delivered using BIM by 2016. If you’ve not read it, I suggest you download a copy of the Construction Strategy and take a look. If your company is involved in public sector work, you’re going to need to. Even if you’re not, this Construction Strategy has become a catalyst; BIM is becoming far more prevalent in private sector work. Many, certainly of the larger sized companies, are defining their BIM strategies regardless of which sector they are based and even those companies who previously shunned BIM are realising they have to shape up or ship out.
There have clearly been changes since the phrase “BIM” was first heard, coined by Autodesk as a term to standardise what this “object-based modelling”, this “virtual prototyping”, this “n-dimensional” concept was all about. BIM is now about as generic as “CAD” – it’s just an acronym applied in a multitude of scenarios, with a multitude of meanings and applications. The first problem with BIM was the “Building” part of it. A large proportion of the construction industry isn’t about buildings, it’s about infrastructure (roads, railways) and many other non-building orientated activities. So what crept in was a series of other terrible acronyms: BrIM (Bridge Information Model), RIM (Rail Information Model), collectively known as PIM (Project Information Model). What we are seeing now is the dropping of the first letter altogether. It’s now Information Modelling, which makes far more sense. It also helps solve the issue of the representation of a model – there is a certain presumption that a BIM model (excuse the tautology) has to exist as a 3D model with added non-graphical data. Using “Information Model” doesn’t carry the same pre-conception. It could be 3D, but equally it could be textual, or a database, or even 2D CAD data. The power of BIM is how these datasources are coordinated.
“The right information to the right person at the right time” still stands strong. That’s the basic premise of BIM success. The right information is not always going to come from the same model – hopefully we’re way past the days of a “Single Building Model” – but that data can be referred to and linked from another datasource. Consider a simple example of a door and its associated specification. There was an assumption, up until very recently, that to be BIM, this non-graphical data should be included with the geometric definition of the door. It can be, but is that the most effective way of communicating the specification data? Unless you have some way of exporting the spec, or own software that can interrogate the geometry model, the specs will not be easily accessible. Instead, a specification is better stored as a document, or a spreadsheet, or XML data that can be interpreted by many different people in many different ways. A simple link to the specification from the geometric representation of the door means that it too provides the correct data, and if the spec is updated, none of the geometric objects need to be updated or replaced; the link to the spec is sufficient (and much more efficient).
A sign of how far we’ve come is the plethora of BIM-related conferences, focus groups, committees guides and standards being published, many of them somewhat “elitist” and highly overpriced. It reminds me of the advent of video cassettes when every company had to have their own “standard”; first there was Betamax, then VHS and V2000 (the double-sided cassette – anyone remember that, or owned one?). Eventually one format wins the race and becomes the de facto standard. The trouble is, without guidance, without non-competitive planning, you end up in a scenario where individuals are using individual standards during the initial stages of BIM adoption – and a standard should be singular. If not, there is a great risk that inconsistencies and incompatibilities occur, risking the progress that is being made. But more on standards in a future column. What is important for now is that there are many activities underway. BS1192:2007 is firmly embedded in many company’s workflows, as are the AEC (UK) BIM Standards (soon to be renamed BIM Protocols), based on the recommendations in BS1192:2007, and specifically tailored to Autodesk Revit and Bentley Building products.
Another important aspect of modern BIM is the importance of “Open BIM” (sic), that is not being tied into a specific file format or software. Of all the areas that will make or break BIM adoption in the UK is the ability to communicate and exchange data between disparate software packages. I’m not just talking the (seemingly) age old RVT to DGN debate, but non-authoring tools, even non-graphical software as well. If BIM is “information” then it needs to exist as accessible data and be interrogated by tools as disparate as 3D BIM modelling software, CAD systems, coordination/collaboration tools, database software, Excel, web browsers, project management software, procurement systems, facilities management tools, ad infinitum. One good thing, as mentioned before, is that no-one (or at least no-one who knows what they’re talking about) is expecting all this data to be maintained in one single model. The data can – and should – exist in a multitude of locations and formats. Linking it all together is the concept of Open BIM (or even the dreaded Level 3). Conversely, Closed BIM would be proprietary data, internally focussed and exchangeable only within a limited environment using specific software. The fact we can have discussions about version and change control – the true BIM process – points to the conclusion that we’ve come a long way since the days of Teamwork 2000 (a great success at the time, and so desperately needed again to trial and prove the concepts of collaborative BIM).
But have we come far enough? The impetus is there now, which wasn’t previously. Technically though, we’re still somewhat stuck in the idealistic viewpoint of the early 20th Century, where software vendors have no commercial interest in interoperability, where IFC is still touted as the answer to all our communication challenges, and where confused or misunderstood solutions (did anyone mention COBie?) may well waste a lot of effort for little actual gain. With bodies like the RIBA re-publishing their Plan of Work to coincide with the government’s “data drops” there is further pressure to provide a solution that is far more reliable than what we have. It is not totally clear how these “data drops” will function in practice, except to those involved in their definition, or whether the data will even be used. Take, for example, the COBie “Attribute” worksheet – the section where full details of each object’s properties are listed. Not only will full listings of each property and value result in an unfeasibly large and unwieldy spreadsheet (1481 lines for a simple two prison cell example in this useful COBie document), unless the “Name” and measurement of “Values” are standardised, they become meaningless. A “Tag” in Revit is certainly not a “Tag” in AECOsim Building Designer. If properties such as “Head Height” are not measured from the same position in all software the mistakes that BIM is supposed to reduce are in fact built in. This is something the AEC (UK) BIM Protocols have addressed, and should be one of the purposes of a BIM Project Execution Plan, but it isn’t clear how well appreciated this is outside of a BIM authoring environment.
IFC is part of the answer – as anyone who has understood how to exchange models in this format will testify. There are still fundamental differences (and errors) in IFC importers and exporters, but the concept is sound.. It’s not the fault of the IFC specification, instead it is its interpretation and implementation where the confusion and disparities arise.
The AEC industry needs to be constantly questioning the “solutions” being dictated, asking whether they are plausible at each stage of each project, rather than blindly trying to make it work because someone says it has to. But what is the alternative? The industry doesn’t yet have the answer, but it’s something that will come when the right questions are asked: What information do you need? What do you need it for? When do you need it?
We’ve made more progress in the last 18 months than I’ve seen in 18 years, which can only be a good thing. Thankfully many contractors and clients are becoming BIM-savvy and working to the principles of data rather than dogma, Open BIM rather than Closed, unheard of in the age of DWG, and even in BIM up to even as recently as a year ago. Provided we don’t get nonsensical contracts being blindly copied from one project to the other asking for formats which are both impractical and unnecessary, provided we can change the mindset of the many, following a path they don’t know how to navigate, provided people are not so blinkered as to believe their way is the only way, provided we can communicate, challenge and concur, it shouldn’t be such a difficult aim to achieve. After all, it’s not like we’re working in an industry of outdated principles and entrenched, inefficient processes, is it?
Photo by patricia serna on Unsplash