29 April 2017

BIM Model Safety

Over the last decade or so the construction industry has become more concerned with safety. With good reason, building sites can be dangerous places. 
A building site can be made safer by keeping it clean and orderly. Store rubbish where it is out of the way, remove rubbish in a timely manner; store materials in an orderly fashion; sign post and label so the workforce knows what is going on.   

BIM models are virtual computer simulations of real buildings, so to an extent the process of creating a BIM model mimics that of constructing a real building.

So just like real buildings keeping models clean and ensuring clear labelling leads to models less likely to suffer from accidents.
Mind you the accidents that happen in a model won't kill you (although the BIM Manager may threaten to), they nevertheless cause unnecessary extra work and stress.

In the good old CAD days it wasn't as critical, although still pretty frustrating. All we had to worry about was layers and filenames. 

Now in BIM models everything has a name. From Fill Patterns to Views to Groups to Parameters. Revit thankfully doesn't have that amorphous thing called Layers which can mean whatever anyone wants it to mean. But never the less there are many, many more things that have names. (ArchiCAD has the misfortune of many things to name as well as Layers). 

Another difference is that BIM models, just like real building sites, have multiple people working in the same space on the same elements. 
This wasn't a problem in CAD. One person would draw a wall in plan in their own CAD file, another person would draw the same wall in elevation in their own CAD file, another person draw it in section, another person schedule it, etc.
Now in a BIM model that wall is shared by everyone, including people who didn't create the wall in the first place.

So the need for model cleanliness and clarity is just as critical as it is on a real building site.

I would go as far as saying it is impossible to create an accurate, error free model (and by extension documentation) with an unclean model. And that is because it is extremely difficult to check such a model with any degree of certainty. When I come across a messy model I know no-one has checked it properly, and by extension that the drawings and schedules produced by that model will be full of errors and missing information.

The Principals of  Cleanliness

A clean model is a model that:

Doesn't contain things that are not used or will never be used.
e.g.  Asbestos Insulation

Has only one type of element for the same thing.
e.g.  CONC 200  and  Core Wall  and  S_CO_IN_3  which are all 200mm concrete walls 

Has names for things that clearly identifies what they are or what they are for.
e.g. doesn't have names like  Section 59  or  Generic 100

Look familiar?

Now these are not hard and fast rules, they are more principles that need to be intelligently applied.

Often you will want to keep things not currently used in the model in case they will be needed in the future. For example title blocks of different sizes. And at the beginning of a project there will be a lot of thing is that haven't been used yet but might be used - that is the reasoning behind Project Templates. 
But as things are locked down it is important to get rid of things that aren't going to be used. If this is not done there is the risk that people will pick out unused things and place them in the project. This extends from non-standard section reference heads to non-compliant doors and walls.

It may seem an oxymoron to state that it is important the same thing be used for elements that are the same, but it is surprising how often this doesn't happen. To be fair sometimes it is necessary due to software limitations. For example in Revit the way a wall wraps its materials at wall ends is driven by a type parameter so you end up with two wall types for the same wall; one that wraps and one that doesn't.
But otherwise if duplicates are not eradicated error free tagging and scheduling is nigh impossible.

Both of these issues hinge on the third principal of cleanliness - name things clearly. If you can't identify what something is it is difficult to know if it is likely be used or not on the project, nor whether it is a duplicate or not. It is also difficult for modellers to select the correct thing if they can't tell what things are from their name. Indeed they are more likely to create a new thing rather than trawl through an ever increasing list of things to select from, leading to multiple definitions for the same type of element.

Naming is the Key

Modellers interact with the model through the names of things. When creating something or looking for something they are looking through lists of names. Lists of views, lists of Wall types, lists of Line Styles, lists of Beam types, etc. While it is true there are other parameters (names are just one of many parameters an object has) that could better identify things they are not immediately visible to the modeller - they have to interrogate each object to see its parameters. 

This is not the case for other users of a model. They are not interested in what something is called within the BIM model, they just care about the data that is contained in it. A contractor may use the object's type code it has been tagged with, FM the manufacturer and model number, QS the material code. Indeed for the reasons outlined above it would be dangerous for them to rely on the names of things in a BIM model.

Therefore the names of things in a model are purely for the purposes of modelling. They don't have to suit anyone else but the team working at creating the model. I treat this as sacrosanct and refuse to follow naming conventions that contractors or clients try and impose. Happy to add extra parameters, but sorry, names belong to us.

Naming Strategy

I'm not a fan of hard and fast rules (probably because I also believe rules are made for breaking). 
My preferred approach is to define naming structures rather than codes to use for naming. Divide a name into fields with particular purposes, but give people the freedom to decide what to put in those fields.
The most basic structure is to follow a major-medius-minor form.
e.g. Door Swing Glazed  instead of  Glazed swing door
       Detail Section Wall
  instead of  Wall section detail

I'm not a fan of over-abbreviation, or being too rhetorical.  CO  is too ambiguous,  Concrete  is overkill,  CONC  is about right.

But the most important thing is to be literal. Name things so that someone who knows nothing about the project will understand what it is. This overrides all other rules.
I'd rather have a wall named  92 stud wall with 13 plasterboard both sides and 75mm insulation  than named  PSI03.

If you have these three features, a clear structure, minimal abbreviation, and literal descriptions, your naming system will be understandable just through examples. 
See if you can understand how this wall naming scheme works:


Now it could be:


and still be fine. Or even:


and still be understandable.

An alternative strategy is to name things after what they are for, rather than what they are. In the above example you might call the wall Standard Internal Partition Wall.
This works on very simple projects or at the beginning during early design, but I find it becomes difficult to manage once a project gets more complex. It becomes hard for all modellers to consistently name things.  For similar wall types you could end up with names like Standard Internal Partition Wall 1,   Standard Internal Partition Wall Level 4,   or    Standard Internal Partition Wall  Dean's office.

That said some elements are best named after what they represent. If Line Styles are named that way you can safely make global changes as well as select all being used for the same purpose. Use model lines named Control Joints for all representations of Control Joints and you can globally change their appearance, turn them off in specific views, and select them all in one go.

For a more detailed discussion on naming see my post The Nature of Naming

Management Strategies

This is all fine in theory but how can cleanliness be managed?

Office BIM Manual

Obviously a comprehensive BIM manual easily accessible to all users is critical.
Everything, and I mean EVERYTHING, that can be named must have a defined strategy on how to name it.
A BIM manual HAS to be on-line, and searchable. A dump of separate PDFs doesn't work. A paper manual you might as well hang in the toilet because it will get more use there.

Office Standard Templates

Good, up to date template files for your BIM software of choice are very valuable. It is impractical to think it is possible to pre-load them with every element that might be used, or that it is possible to restrict modellers to using only pre-approved elements.
What is practical is to provide a few examples of every kind of element named to conform with your office standard. If that standard follows the principles above them just seeing the names should provide modellers with enough information to understand and mimic them when naming new elements.

Don't forget Designers

When people think of office manuals they invariably assume it is a documentation manual. Yet it is at the design stage when models get really messy. And it is usually designers, (or clueless graduates), who originally set projects up.

It is important to include strategies that modellers can use during design, and VERY clear instructions on how to set projects up.

It is best to assume designers will be messy and attempt to minimise rather than prevent. A rule of being literal gives them freedom to do things on the fly while still providing meaningful names. Getting them to name things after what they are for will have more success than forcing them to comply with specific rules. Remember the aim is to have an understandable model, not a model that strictly follows particular rules.


BIM newbies and wannabes will by now be saying "don't you just follow the standards". Well, you might if any of them were actually usable.

Don't get me wrong, l don't have a problem with following standards, it is just that I have yet to come across anything adequate. Some are just silly like the naming standard in the NBS National BIM Object Standard. Some are archaic and are nothing more than regurgitated CAD standards.

The best I've found are invariably software specific. For example the AEC UK BIM standards (https://aecuk.wordpress.com) which has Revit, ArchiCAD and other specific software standards. The ANZ Revit Standard (http://www.anzrs.org) is also pretty good, although doesn't seem to be very active lately.

So by all means have a look at public standards to see if they are useful. But keep in mind it is unlikely you will find a standard that will adequately address every naming requirement you have, so I recommend integrating the bits that are useful. Following a standard for the sake of following a standard is always a bad idea.


Geometric design and data extraction are the headline uses for Dynamo and Grasshopper. But they can also be used for model management including automated cleanup tasks.

For example I've written a Dynamo routine that can extract the username of the person who created an element. One of the uses is to rename views to include the user name of who created it.
Another I've created renames layered elements like walls with what materials they are made from.

There are also model checking softwares and add-ins. The open source Revit Model Checker (http://www.biminteroperabilitytools.com/modelchecker) is quite good, if a bit clunky.

Solbri is a dedicated model checker but the overhead of setting up checks and having to export to a different format for checking tends to kills its ROI.


Of course regular auditing is vital. The trick to make auditing work is to not make it too onerous. It is better to do a manageable audit that might miss some things than a comprehensive one that rarely gets done.

Audits should be treated as an active management tool done while work is being undertaken rather than an after the fact tick the box exercise that is too late to be helpful.
A regular quick look over view and type names in a model with some quiet words of advice will be more beneficial than creating a 20 page audit report at the beginning and end of a project.

I'm a fan of getting those doing the work to do the checking and report the results. This makes them more responsible for mistakes and gives them an incentive to avoid them. One way to do this is to ask for regular schedules that demonstrate the model is clean.

The Stature of Cleanliness

Just like a real worksite one of the biggest issues is getting everyone to take cleanliness seriously; that it is not a low priority, that "I didn't have time" is not a valid excuse.

It is important that it is appreciated that a messy model is an indicator of incompetence that leads to mistakes and inefficiencies and ultimately loss of profitability.

That means those at the top have to take it seriously as well and make cleaning up models, keeping them clean, and checking they are clean a part of everyone's job description, even if they do not directly use models.

Directors responsible for a project need to ask whether models are clean;
Project leads need to be confident their project models are clean;
BIM managers must regularly audit or oversee auditing all models;
Model manager must actively clean their model;
Those working in models must follow standards and protocols.

Assuming the BIM Manager is solely responsible for cleanliness will never be enough.
Although appointing a dedicated BIM Safety Officer is perhaps a step too far.

28 February 2017

The Axioms of BIM

BIM can seem complicated at times, but is it really?
Certainly BIM processes and procedures can end up being complicated, just try and and understand some of the standards that are being pushed.

If only there was a way to cut through the guff, to have a simple set of principles that could be applied in any situation where BIM is at issue.

Like in Mathematics. Mathematics is all about logic, but that logic has to be based on something, has to start somewhere. This is where Axioms come in. An Axiom is "a self-evident truth that requires no proof". Maybe that is a step too far for BIM. But what about a "universally accepted principle or rule".

Axioms have to be basic otherwise they are hard to apply. Euclid's first for geometry is "A straight line segment can be drawn joining any two points.", the second "Any straight line segment can be extended indefinitely in a straight line."

Could we do the same for BIM? Have some "universally accepted principles."


First we need to be clear about what we are talking about, what we mean by BIM.

I wrote a post about this back in 2012 - What Does BIM Mean to You?
Hopefully by now we are beyond arguing about personal interpretations. Also back then discussion was more centered on buildings and the particular form of model used. BIM has moved on since then so I think a more universal definition is warranted.
BIM is a generic term for anything that involves software that directly associates data with geometric information.
The term BIM is used to describe the thing - the Building Information Model, the process - Building Information Modelling and management - Building Information Management.
Usually BIM applies to buildings, or facilities, but may be applied to other things like infrastructure and GIS (Geographical Information System). Really anything in the built environment that has a physical form and meaningful data.


So now we are on the same page what are the essential axioms we can use to apply to BIM topics and issues.

1.    BIM can be used by anyone for anything.

BIM is not limited to certain purposes or particular groups.
BIM is not just for design, construction or operation. It is not just for design analysis, clash detection, facilities management. Nor is is just for buildings, infrastructure or GIS. The data in BIM models is agnostic, it doesn't care who uses it or for what purpose.
It can be used to educate, to inform, in contracts, to create VR, for disaster planning, even preparing terrorist attacks (hence the need for PAS1192-5).

Allied with this is there is no theoretical limit to the type of data. If there is data that you would find useful you can add it (or pay someone to add it). Just don't expect someone else to do it for free - see Axiom 2.

2.    The BIM you do directly benefits what you do.

If not, you are doing someone else’s work for them.
The reason you use BIM software and processes is to improve the efficiency and quality of the work you do and are responsible for.

If you don't think you are, apply Axiom 1 - BIM can be used for anything, and work out how it could benefit what you do.

This Axiom is not just about personal gain. This is an important aspect of BIM. Processes where each participant is benefiting will always be more robust, have greater take up, and longevity.

But more importantly it is critical participants only work within their area of expertise and responsibility. Architect's should not use BIM to do structural analysis. Design professionals and contractors should not be responsible for providing data that is specifically structured for FM purposes.
Providing data to others is fine, but providing data that is fit for someone else's purpose is a step too far.
And unnecessary. Structured data is accessible no matter how it is structured. Standards may help if those standards are adequate, but lack of standards does not make it an impossible task.

Contractors should be responsible for extracting the data they need for construction from design consultants data, FM consultants should be responsible for extracting the data they need for operations from contractor's data, realtors responsible for extracting the data they need for sales from FM data, etc...

So if you find yourself in a situation where what you are doing is of no benefit to what you do, you are within your rights to say no, - we don't do that, or demand to be paid to do it.

Conversely, if you are doing it for your own purposes and someone else is benefiting from it, you give them free access to it, after all it is not costing you anything.

3.    BIM replaces or enhances something you already do.

BIM is something you do instead of other less efficient and less accurate methods.
If you are following Axiom 2 - you are using BIM for your own benefit, you will be using it to do things you were already responsible for.

You don't draw in Autocad AND model in ArchiCAD, you don't manually create a schedule in Excel AND create the schedule in Revit.
You don't do a structural design by linking an analysis package to your model AND calculate it all out with pen, paper and calculator.
You don't use a BIM model and a total station to set out ceiling hangers AND measure them out with a measuring tape.
You don't have a room full of drawings & folders AND have an integrated FM database.

This also applies to management. There may be a new position called BIM Manager, but it isn't a new profession. It's a manager who uses BIM to do the things managers do already.

BIM is a tool to get things done. It is not a thing in itself. If you are doing BIM for no measurable purpose you are wasting your time.

4.    BIM is not possible without BIM capable software.

BIM is fundamentally a technology of a particular type of computer software.
BIM capable software is software that, as a minimum, can store and manipulate geometric information and associate data to that geometry. Software that only does geometry (CAD, SketchUp, Rhino, etc) or just manages data (databases, spreadsheets, etc) are not BIM capable.

BIM is often described as a process, but it is a process of managing BIM capable software. It may involve only managing the output and exchange of that software, but to do that effectively you need an understanding of the abilities and limitations of the software involved. BIM Management ignorant of software issues is nothing more than management by wishful thinking.

There are some who think mandating "OpenBIM" means software becomes irrelevant.
OpenBIM may be developed by committees with high ideals, but it is still software (or software format), it still has a fixed form that people have to try and use to get things done. BIM softwares that are used in the real world have to be able to interact with "OpenBIM" formats or BIM processes will not be possible.

When it comes to BIM you always have to consider the impact of the softwares being used.

5.    BIM works best with Collaboration.

Sharing your data means others share their data with you.
BIM works best if your combine it with collaboration with others, but you can still use BIM without any collaboration.

An architect can use Revit to just create drawings and schedules but never give the model to anyone. The architect is still doing BIM, benefiting from it by being more efficient and accurate, even though there is no collaboration.

If you think about it BIM can't just be collaboration. If none of the collaborators produce or can offer BIM, how can there be any collaboration? There is nothing to collaborate with.

Collaboration is a secondary consideration. Establishing what BIM will be done (Axiom 1), that there is a benefit (Axiom 2), and that it is doing something that it is required because it is already being done (Axiom 3), has to be done first.

But once that happens collaboration is definitely low hanging fruit.

Consider the example above. If the architect share their model with, say, a quantity surveyor who uses the model to measure quantities, the architect will get costing advice much quicker and more often (as will the client), leading to the architect wasting less time on abortive work.


Of course there are other considerations than just the Axioms when looking at BIM.
Some examples I've seen are:
  • Whether the effort or expense is worth the outcome.
  • Whether it is possible with current technology and skill sets.
  • Whether there enough time in the program for implementation.

But these are not principles about BIM, they are problems to overcome.
  • If it is not worth the effort, how could the effort be reduced, or the outcome enhanced to make it more valuable? 
  • If it is not currently possible when will it be possible, or what is possible now, what is practical now?
  • Compare how much extra time is required against the benefits. Can the program be adjusted to allow more time upfront?


So next time you are in a discussion about BIM keep in mind the BIM Axioms, they may provide a quick answer to a silly proposition.

To recap the BIM Axioms are:

  1. BIM can be used by anyone for anything.
  2. The BIM you do directly benefits what you do.
  3. BIM replaces or enhances something you already do.
  4. BIM is not possible without BIM capable software.
  5. BIM works best with collaboration.

Have a go at this quiz to see how easy it is (answers below).

Which axiom applies to each of the following:

A.   You wouldn't use BIM for that.
B.   It's your job to give me the data I need.
C.   BIM is a whole lot of extra work.
D.   It doesn't matter which software you use for BIM.
E.   We can't use BIM because the contract doesn't have collaboration clauses (is not IPD).

(A=1, B=2, C=3, D=4, E=5)

Supplementary quiz for the dedicated:

A.   You can do BIM with CAD software.
B.   It is extra work to get our schedules out of Revit.
C.   The primary purpose of BIM is for facility operations.
D.   We can't use BIM because there is no BIM Execution Plan.
E.   COBie doesn't cost anything.

(A=4, B=3, C=1, D=5, E=2)