30 August 2014

The Nature of Naming

BIM is by nature a shared environment. For example in the context of Revit each discipline team work together in one file.
This new paradigm means things have to be shared, people can't isolate themselves in the CAD files they are working in and name things however they want. Nor can they create new things to suit their own purposes. Anything created in a BIM file is for everyone to use.

How things are named becomes critical, because it is how different things are recognised by different people.
Not only so people can find the things they need, but also so things that are the same are not created multiple times with different names.

Many things are named in BIM, from filenames to parameters. This post concentrates on the naming of components (families in Revit). But the principles expounded are applicable to all naming.


Who uses and relies on names in the BIM model?
Receivers of BIM information don't care what the name of an object is. The information they require comes from object parameters. You don't produce a wall schedule for the contractor that lists the Revit names of walls, you list wall code, thickness, materials, fire, acoustic ratings etc. Indeed, if you are asked to use a particular naming schema by a client or contractor in your BIM software politely refuse. It is totally unnecessary.

The purpose of names is so BIM authors can identify things when they are creating them. When confronted by a list of wall names in their software they can identify and select the one they need. Or if what they need doesn't exist they can create a new one using a naming schema that others will understand, so someone else can use the wall that they made.

If objects have so many parameters why is the name of it so important? The information is there, you just have to expose the relevant parameter value.
This is true. But the stumbling block from a practical point of view is "exposing the parameter". In an ideal world (with ideal software) you could sort and filter by all the parameters an object has rather than just its name. There are Revit add-ins that do this to varying degrees (I welcome comments suggesting such add-ins). Revit out-of-the-box does not. The other issue is even if you could select by parameter the name still has to be unique. Unless the add-in controls naming of components, you still have to come up with a way to create unique names.
That said, an add-in may be a viable solution. But for the rest of us who can't get our bosses to pay for add-ins the problem remains.


Naming was also important in CAD. Every office had a CAD Naming Standard. But there are important differences to BIM.

The most obvious difference is that the output of CAD is drawings, lines on paper. In fact many CAD standards did little no more than describe lines. Layers names like 5_PEN.

With BIM you are dealing with objects, virtual objects that represent things that exist in the real world. When you model a wall you are creating an object that has (in Revit) upwards of 24 different bits of information, or parameters (in Revit speak).
In CAD you might have three; colour, pen weight and line pattern. Enhancements like multi-lines might increase this by 3 more by adding thickness dimensions, but still no-where near the number BIM encompasses.

In reality correct naming was not that critical for CAD. If a layer (or Level in Bentley) was named WALL_BRICK in one CAD file and BRICK_WALL in another, as long as they had similar line thicknesses  and patterns the drawings produced looked the same.

In BIM if you have two wall definitions with different names that are actually the same wall (i.e. have identical parameters) not only will your schedules be misleading (i.e. identical walls with different codes), if there is a change made to one and not the other that change won't propagate across the project (e.g. MR plasterboard changed to Fibre Cement sheet).
The effect is the BIM model becomes unreliable.


CAD software started to be used back in the days of DOS (Disk Operating System). This was a text based language developed in the early 1980s when computers had very little memory. So little the length of filenames had to be restricted to 8 characters. And even then only uppercase letters (A-Z), numbers (0-9), and the underscore (_). This was because other 'punctuation characters' (including spaces) were used by DOS for programming.
Although these restrictions only applied to filenames they were usually applied to internal naming as well (early AutoCAD had restrictions on layer name length, Microstation Levels only used numbers up to 63). This was due to a mixture of software creating files hidden from users, internal memory constrictions, or just habit on the part of software coders.

It wasn't until the introduction of Windows NT & 95 (Apple always had fewer restrictions) these restrictions started to relax. Dashes (-) became permissible, the file name length increased to 31 characters, lowercase was displayed.
Now most punctuation characters are allowed, (only  \ / ? : * " > < |  can't be used), and restriction on length is 260 characters.

Many CAD standards still used today were originally created back in the days of DOS, when CAD naming schemas obsessed with the number of characters and only allowed letters, numbers and underscores.
Even today many IT and CAD managers still insist these old DOS restrictions be maintained, because back in 1998 they had an incident where it mattered. When pressed their best reason is do it "just in case".
Indeed there is still software around where it matters, but I find if this is the case invariably there are other reasons not use it (I tried an accounting package with these restrictions but stopped using it because it was like using software from 1998). To me it is an indicator of software which is ancient, or considers coding more important than usability.

In 2014 there is no practical reason to restrict naming schemas to suit computers from 20 years ago.


Apply these simple principals.


The most important criteria for a naming schema is that it is understandable by everyone who will interact with it.
This is not as onerous as you think, as mentioned above only BIM authors make use of names so this cuts down the audience considerably.
There are many ways to make a naming schema understandable. There is really no one size fits all. What works in one office may not work in another. Architects respond differently to engineers, a design office will respond differently to a documentation workhouse.

How do you make a naming schema understandable?
  • Be literal:
    call 13mm plasterboard, for example, plasterbd13 not P01 or L13.
  • Be consistent:
      brick110 and plasterbd13
      110brick and plasterbd13.
  • Use punctuation that is meaningful:
      brick110 / stud92 , insul50 / plasterbrdMR13 + tiles
  • Manage the unmanaged:
    Use a prefix and name structure to identify objects that are managed.
    For example:
    - prefix material names to separate them from rubbish that comes in with imported files:
    - name things that are standard differently:
      2.5 text   is standard;
      Black 2.5 bold   is not standard.


Naming schemas need to be capable of naming absolutely every possibility for objects they are applied to.
If they don't how do your users name something the naming schema doesn't account for? They make it up, and each one will make it up in their own unique way. To say something is hardly ever used is not a solution, it is a cop-out, what I call an excuse, not a reason.
This doesn't mean a naming schema has to be ridiculously long. By utilizing meaningful punctuation fields of information can be optional - left out if not relevant. If necessary the schema defines what the value is by default, and how it is added to the name if it is not the default.
  • Define a name schema to include all variances that are possible, not just those that are probable:
    In Revit look at all the Type parameters of the object being named and make sure the ones that will cause a new type to be created has a place within the name structure.
  • Use optional fields:
       brick110 / stud92 / plasterbrdMR13
       can be extended to
       brick110 /stud92 , insul50 / plasterbrdMR13 + tiles
  • Assume default values:
    walls are internal unless nominated otherwise,
       -/block140/- is interior wall;
       -/block140/-.e is exterior wall


There is no point creating a fabulous naming schema if no-one uses it, or uses it properly. It has to work in practice.

It is a trap to think because you have a captive audience in your office you can rely on training to enforce a naming schema.
The reality is Architects and engineers, the BIM authors, don't care about naming schemas. Nor should they be expected to. They are hired to provide their professional skills in designing a building. And that is what they want to do, not obsess over how they name things.
People new to the office, or project, also need to be considered. No boss wants their highly paid engineers spending hours learning naming schemas, they want them producing billable work.

And relying on training will only be effective if the naming schema actually works. An all too common assumption is that if only everyone used it properly there would be no problems. Whether it does what it needs to do is never challenged.

How to make a naming schema work:
  • Set general rules for name creation rather than a rigid rules:
    names follow major-medius-minor rule rather than 3 uppercase letters, underscore, 4 lowercase characters, underscore, 2 numbers.
  • Create a naming structure rather than a rigid standard:
    allow 13mm plasterboard to be named plasterboard13, plasterbd13 or pb13, not just PB13.
  • Document naming schemas:
    don't rely on people memorizing what they learnt at a training session; provide examples, cheat sheets, easily update-able and searchable documentation (i.e. web manuals or wiki)
  • Adjust naming schemas to suit particular projects:
    work with project teams to get a schema they are comfortable with.
  • Investigate how people use naming schemas:
    instead of forcing recalcitrant users into training ask them what they would change to make it useful to them.
  • Review naming schemas in the light of experience:
    don't be afraid to make changes when it is warranted.

As an example of making changes to suit users, I recently added tag codes to the front of wall and material names.
brick110 / stud92 / plasterbrdMR13
W.B201_brick110 / stud92 / plasterbrdMR13

To me this is poor practice as codes are unique to a particular project, and there is an overhead in keeping the names matching the code parameter (in our case Type Mark).
But users felt more confident selecting items clearly identified with the code used in tags. (Wall types not yet assigned a code were named: W.Bxxx_....).
From a purely data management view not ideal, but if it helps people do what they need to do so be it.

The bottom line is BIM standards, including naming schemas, should never be considered set in concrete. BIM software development is fast moving and standards need to move with them.


At the end of the day naming schemas, and office BIM standards in general are for humans, the users of BIM software, not the software itself, the IT system or those that run it.
When dealing with humans a rigid purely logical approach is rarely successful. What is called for is 'fuzzy logic' (to use a software term); simple rules that have a degree of flexibility.

Despite my examples above, (which are not from a real naming schema), I have deliberately not been specific because I don't believe there is such a thing as the perfect schema. To be practical a naming schema has to suit the people who work with it, so they (or someone in direct contact with them) need to be the ones who work it out.
What I have tried to do is reveal some of the guiding principles behind a workable naming schema.

Creating BIM standards is a hard and thankless task. You will never satisfy everyone, you will never achieve the perfect standard, and the job is never completely finished. But there are benefits to even partially successful standards. It is worth the effort.

There will always be resistance to change, but don't accept excuses masquerading as reasons:
  • I don't like it:
    - it is not an aesthetic decision so who cares what you think.
  • We have always done it that way:
    - if that was the case we would still be drawing on linen with quills.
  • People are already familiar with the current system:
    - not relevant if the current system is unsuitable for BIM.
  • It works now so why change it:
    - does it? really? let me show you otherwise . . .

Bored with BIM?
Need a present for that special woman in your life?
The Lost Woman series follows the adventures of Christina as she makes her way through a world of design, fashion, new media and ... men.

The complete series, "AWAKENING the lost woman", "CAPTURING the lost woman" & "FINDING the lost woman" is available now on Amazon, Kobo, Google Books, Barnes & Noble and iBooks.

02 June 2014

BIM is not so Real after all

In my last post, Keep your BIM Model Real, I explored the issue of relating a BIM model to the real world. One of my conclusions was to "actively include tolerances in our BIM Models".

I was wrong.


Firstly there are technical reasons 'padding' quantities is bad practice. In my previous post I tried to show that it didn't matter for quantity take-off. But accurate quantities are important for other purposes as well.
As Tim Froise pointed out in an LinkedIn discussion:
' But there are occasions where the volume is important. If the wall component is considered for its U-value, there is an additional 36% of plasterboard material, which is significant.
He also points out it will affect acoustic and thermal mass calculations.

Indeed he is right. Materials in Revit have values assigned to them that can be used for these types of calculations.

And materials with padded thicknesses make a difference.

I can't justify rationalising away all these valid uses for accurate data.

But perhaps the most pertinent comments were about why I though it OK to mess with the BIM model for my own purposes.
From Tim McDougald:
' I watched this argument at my old firm between two different Architects within the same building. One wanted everything drawn "real" and the other rounded everything off.
I recognised myself as one of those architects. And it is true, there is no consensus between architects (which is why I started analysing this issue).
The view held depends on what particular problems an architect is grappling with. For example at design stage the aim is to please the client, so architects tend to minimize construction allowances so higher usable and lettable areas can be achieved. During documentation the aim is constructability, construction allowances have to be found to ensure what has been designed can be achieved in the real world.
But this has nothing to do with the BIM model. It has to do with the competencies of the architects involved.

Embedding the solution into the BIM model risks reducing the designer's obligation to directly deal with their professional responsibilities. Architects who think their BIM model will 'take care' of constructability will feel confident they can ignore construction limitations. Engineers who let their software come up with solutions don't feel the need to explore alternatives.

And this is what my last post attempted to do. Shift architect's responsibility to consider constructability on to the BIM Model.

Another comment, this time from David Conant:
' I think the pressure to make a 114 wall at 120 is really another manifestation of "don't make me change the way I do things" without questioning why. '
The error I made is all too common. An approach that tries to embed too much into BIM models. To use them as much as possible to solve problems we encounter, ignoring how this may effect others using the model.
What we need to appreciate is that there are limits to what a BIM model (and hence BIM processes) can do, and to modify our expectations accordingly.


On "questioning why", as David suggested, I recognised the traditional  purpose of dimensioning is to provide the contractor with clear instructions, or requirements, of where things are located. By rounding dimensions we are attempting to make it easier for them through expressing requirements in a clearer manner.

This is because in traditional construction documents the purpose is to provide the contractor with sufficient information to fulfil requirements that designers (i.e. architects and engineers) identify.
This often leads to a battle between contractors and designers, where designers try to provide as little information as possible, and contractors demand specific 'how to' instructions. The architect provides a note - "fix securely", the contractor wants a drawing showing the location of every screw.

Now using BIM doesn't (or hasn't yet) overcome this. Contractors still want more in the model than designers think is necessary or reasonable (and to be honest practical). On the other hand Architects, and especially engineers, don't see why they need to model enough to create a coherent virtual building.

But the significant point here is the different ways traditional documents and BIM communicate information.
As explained above traditional documents attempt to explain what the requirements are. Those who receive them expect those documents to directly communicate requirements without interpretation.
A BIM model is a facsimile of requirements. It is a representation of the final product of those requirements (i.e. a virtual model). And as such can only every reflects what the real world requirements are, it does not specifically spell them out.

For example traditional documents might have all fire rated compartments identified on drawings with a heavy dashed line. This directly tells the contractor where fire compartments are located, and by inference which walls and doors have to be fire rated.
In a BIM model those walls have their materials and construction modelled as virtual walls and doors that meet fire rated performance requirements, they may even have data associated with them stating their required fire rating. But it will be up to the contractor to extract information from the model that identifies their location, and hence extent of fire compartments (contractors need to know this because it is not just materials that create fire isolation, it is also the way they are put together).


So to go back to my dimensioning example.
So yes, architects should represent walls correctly without padding, and not worry about dimensions that are unobtainable in the real world.

The consequence of this is that dimensions will not be as clear and instructive as found in traditional documents. The contractor will not be able to merely read off dimensions and use them directly, dimensions will have to be interpreted to make them useful on site, in the real world.

I see this as another consequence of utilizing BIM, an example of roles and responsibilities changing. Is it a bad consequence? I think not. The contractor is best placed to make decisions about what is best on site. And honestly, if architects were any good at it I wouldn't be spending so much time trying to find a fix for it!

The bigger picture here is that a BIM model - a virtual building - does not communicate information in the same way traditional documents do.
Traditional documents are designed to spoon feed relevant information, to highlight what is critical and what is not. BIM models just provide information. True, much more information, but not all of it is relevant to a particular recipient. It is the recipient's responsibility to extract the information they require, and if necessary manipulate it to make it useful.

For contractors no more "we didn't do it because you didn't specifically tell us to", with BIM it is "you should have identified the need from the model", (although "we didn't do it because it wasn't in the model" is still fair enough).

I've used contractors as an example, but the same applies right across all AECO processes. We all need to recognise that BIM is not the same as traditional delivery, and that it does not provide information in the same manner.


Great, glad we got that sorted. But what does that mean, how should this insight effect what we do now?

As I have written before in my post Can BIM alone be used for Construction, there is currently no practical way to deliver a project purely using BIM. We are in transition. We use BIM where we can but are still expected (and contractually required) to provide traditional documents.

This is where I came unstuck with dimensioning. Traditional documentation calls for rounded, padded dimensions. But we are using BIM software, and it is not designed to do this (nor should it be).
So on the one hand I'm trying to fulfil my contractual obligations, on the other trying to produce good quality BIM, both to help my processes and for others to utilize.

What is the solution? All I can think of is a hybrid.
Use real thicknesses and unapologetic actual dimensions, then add 'clear' or 'min./max.' dimensions where there are critical requirements to be met.

If you really feel the need to pad walls do it be adding a 'tolerance' layer.

But there is nothing preventing walls used at early design stages, when their construction is unknown or undecided, from being thick enough to incorporate tolerances.
For example use 150mm or 130mm for generic internal walls instead of 100mm. This is where BIM helps, it is a trivial exercise (at least in Revit) to change walls from one type to another.


'Why bother' you might ask. If we are not doing real BIM why try and do things in a BIM like manner?

The reality is BIM is not an all or nothing proposition. A lot of money is always at stake on a building project, involving lots of people with differing views. The risks are enormous, so BIM will be used where there are perceived benefits and low risk, BIM by itself will never be the most important driver.

We users of BIM know its benefits, but must be prepared to demonstrate them. And the best way to do that is to be prepared. To embed BIM practices in what we do even when we don't need to. And where necessary resist following traditional practices where they conflict with good BIM practice.

A BIM model is not, and can never be, 'Real'. It is repository of data that creates a facsimile of the real world. It is up to us, the creators and users of that BIM model, to use that facsimile to inform what we humans need to know to create the real thing, in the real world.

Bored with BIM?
Need a present for that special woman in your life?
The Lost Woman series follows the adventures of Christina as she makes her way through a world of design, fashion, new media and ... men.
Book one of the series, "Awakening the lost woman", is available now on Amazon,  Google Books,  Kobo  and  iBooks.

03 April 2014

Keep your BIM Model Real

Many of us only work in the world of our BIM models. The closest we get to something real is the drawings and schedules produced by our BIM software (even then we may never see them as physical objects, document issues are often via PDF or DWF).

Often we forget what we are doing is for the real world. That we are showing real people using real materials and real tools what we want built.

Another thing we tend to forget is that what we produce is going to be used by different people for different purposes.
An architect may only think his work is for showing what he has designed will look like, an engineer to explain the rationale of his solution. Sure, they might provide more information they think others will use, but not a lot of thought goes into it.

Conversely, those that use what has been produced don't understand why it doesn't explicitly cater for all their requirements.

None of these issues can be completely resolved. BIM software will never exactly match reality, authors will always privilege their own requirements, and a BIM model will continue to be used by multiple people for multiple purposes.

If it is always going to be a compromise what are the practical things we can do to address these issues?

An Example - WALLS

Within a BIM model walls have a number of purposes:

show what is to be built 

Walls are made from materials, with certain properties. There is an expectation there will be enough information to build them, that what walls are made from is identified, as is the order they are placed.

locate to be built 

Walls represent real objects that real people have to build. They need to know where it is located, with sufficient tolerance to make it humanly achievable.

boundary for analysis

Walls can be used as boundary elements for various software analysis. But each analysis will have different expectations. Not every wall may be required, the boundary may be at the edge of a wall or somewhere within it, particular information about what the wall is made from, or how it behaves, may be expected.

measure quantities 

Walls can be measured for costing and procurement purposes. Accurate area and volumetric information is expected.

construction schedule

Walls can be made up of different materials that are placed at different times. The expectation is that these materials can be separately allocated to different milestones.

I don't intend to go through every issue, instead I'll use accuracy as an example.
What are the expectations in terms of accuracy? It is not a two way street however, for example the cost estimator does not model walls, the architect does. So for the architect, what level of accuracy is reasonable?


We all understand a real person in the real world can not be as accurate a a computer. Let's put some numbers on that.

In our BIM software we can be precise up to 16 decimal places. This is often important to our software, but in the real (metric - millimetre) world that is accuracy to 0.1 femtometres, which is narrower than a proton (1.6 to 1.7 femtometres). If the unit is feet it becomes 30.48 femtometres, which is still smaller than the width of a hydrogen atom.

In the real world standards have been set to define what is reasonable. Some examples:

From the U.S. "Minimum Standard Detail Requirements for ALTA/ACSM Land Title Surveys 2011":
"The maximum allowable Relative Positional Precision for an ALTA/ACSM Land Title Survey is 2 cm (0.07 feet) plus 50 parts per million".
So the minimum degree of accuracy expected for land titles is 20mm.

From the Guide to Standards & Tolerances, published by the Australian Victorian Building Commission:
"Departures from documented external dimensions of buildings are defects if they exceed L/200 where L is the documented overall length of wall, or 5mm, whichever is greater."
"Departures from documented dimensions of service rooms and areas are defects if they exceed L/200 or 5mm, whichever is greater."
"Departures from documented dimensions of heights of building elements such as beams and posts are defects if they exceed L/200 or 5mm, whichever is greater."
i.e. 5mm per 1000mm (3/16" per 3' 3 1/2")
"Departures from documented dimensions of habitable rooms and areas are defects if they exceed L/100 or 5mm, whichever is greater."
i.e. 5mm per 500mm (3/16" per 1' 8")

Some allowable inaccuracies are quite large:
"Finished floor levels are defective where they depart from documented RL or FFL by more than 40mm" or depart from floors of the same level."
And there are more for specific materials:

From this it appears it is generally considered unrealistic to expect on-site measurements of less than to the nearest 5mm (3/16 inch).


Let's go back to our wall example.

A typical (metric) wall is two layers of plasterboard either side of a structural stud.
13 plasterboard + 92 steel stud + 13mm plasterboard, total thickness 118mm.

But is the built wall going to be exactly 118mm thick everywhere? Of course not.
For a start it will thicker wherever there is a joint.

It will also be thicker in corners (both internal and external), which like joints are also stopped up.

 And this is before we factor in the imprecision of on-site measuring.

If the architect is to achieve required minimum clearances then this needs to be taken into account.
You might rationalize that surely a code checker won't worry about a few millimetres. But no-one can take the risk. I have seen a building inspector insist walls tiles be removed from a toilet wall because the width he measured was slightly less than the required 900mm. There was also a court case here in Australia where the architect, building surveyor and contractor were found culpable for a balustrade 20mm less than code height (someone slid down the balustrade and fell, resulting in brain damage. Apparently, according to the court, if it was 20mm higher it wouldn't have happened).

What about rounding? We are all guilty of using dimensions that round to the nearest 5mm, or (gasp) 10mm.
The problem is Revit doesn't always round up. We always want to ensure minimum dimensions are met, we are not so worried about maximums being exceeded, so we need to round up.

Depending on the actual dimension, Revit may round up or down.

Also the 2 or 3mm rounding changes a dimension by may not be enough to account for construction tolerances. In-situ concrete requires quite large tolerances, 25mm (1 inch) is not uncommon.

Rounding generally is not good practice. Rounding errors mount up, and you can end up in the embarrassing situation where your short dimensions don't add up to longer dimensions.

The correct way is to locate things ACCURATELY. If the end walls are supposed to be 600 apart, model them 600 apart. Objects should be modelled so they are increments of 5mm apart, then actual dimensions you have in your model will be achievable in the real world.

I know it is not always possible, but just because it can't be done all the time is no excuse to never do it.

But I digress, back to our wall:

Therefore to ensure minimum dimensions are at least achievable on-site we need to increase the width of the wall. Based on the 5mm minimum measurable rule that means a multiple of 5mm, remembering that you don't want possible mis-measures to be minus 5mm.

So a 118mm wall becomes 120mm, (2mm tolerance) or to be safer 125mm (7mm tolerance).

Now, according to the Guide to Standards & Tolerances:
"Unless shown otherwise, dimensions shown on drawings for internal walls always refer to the structure's dimensions."
So we also want to rationalise the dimension of the structural steel stud.

The wall we make in our BIM software becomes:
17.5 plasterboard + 90 steel stud + 17.5mm plasterboard, total thickness 125mm.

Now it is true we could add another 'layer' into the wall for tolerance.
13 plasterboard + 4.5 tolerance + 90 steel stud + 4.5 tolerance + 13mm plasterboard.

But this adds another line into the graphic representation of the wall.
Not only is this confusing to anyone looking at the drawing (and a potential recurring RFI topic), it adds additional complexity to our BIM model. We already cope with large, slow files (in Revit that is), we don't need to make it worse.

So the architect is happy. But what about others?

When an estimator extracts quantities from the BIM model they are going to be wrong. But how wrong?

If we take volume of plasterboard, every 100sqM of 13mm plasterboard has a volume of 1.3cuM, for 17.5mm it is 1.75cuM, a difference of 35%. Not insignificant.

But something like plasterboard is measured by area, not volume. When measuring wall linings errors in area measurements will occur at corners and end walls.
Looking at internal corners (there are more internal corners than external corners or ends walls in a building), there is an under-measure if walls are thicker.
So 2 lots of 4.5mm will not be measured, and assuming 2.7m high walls, total area is 0.0243sqM.

Put another way there would need to be 41 internal corners to lose 1sqM of measured area, which is close to 10 rooms (4 corners per room). Say an average room is 3m x 3m, total wall area for 10 rooms is 324sqM. A loss of 1sqM equates to 0.3%. Which is insignificant.

So while it can be quite dangerous to rely on volumes out of a BIM model, areas are not such a problem. Of course this is not the case for every material. Mass materials like concrete are usually safe (tolerance in concrete placement is accounted for in attached linings). Structural steel may be OK if realistic structural members are used (which generally happens if the structural engineer is the modeller).

The take home point here is to not rely on thicknesses parameters to define what a material is. The above example has 13mm plasterboard, but when modelled at 17.5mm if its thickness is used to identify the type of plasterboard it could be mistaken for 16mm plasterboard, on the assumption a 1.5mm tolerance has been allowed for.

There is another reason thickness is not a good indicator of what a material is. Walls in BIM software have homogeneous layers. When materials overlap there is no way to use their real thickness in the thickness parameter.
The example below is a stud wall with insulation. The insulation is within the same 'layer' as the studs, but is not the same thickness as the studs. Therefore we have to nominate the stud layer thickness as 40mm, even though they are actually 92mm studs.

There are plenty of other parameters that can be used to define what a material is. It is not really necessary to use the thickness of a modelled material.


I've only provided limited examples here, but these lessons apply right across all things in BIM models. The specifics may be different, but the issues are the same.

Don't assume a BIM model has just been made for you and your purposes.

In particular no-one should presume, or ask for, absolute accuracy from a BIM model.
We should all expect, and actively include, tolerances in our BIM models.

And most of all, don't forget why we do the work we do. To build things in the real world.

03 March 2014

Schedules from BIM - why is it so hard?

One of the uses of BIM, and increasingly a deliverable, is that what is on drawings matches what is in schedules.
In theory it seems simple. If your BIM software is a database you just extract the data.
But just because it is possible doesn't necessarily mean it is practical. Can the people who provide the content and manage schedules do it themselves or do they require specialize computer skills (or assistance from some-one with those skills) to do it?
Do I fire the person who knows the difference between a passage and a privacy mortice latch, and replace them with some-one who knows the difference between a type and instance parameter?

Schedule creation and management is poorly supported in BIM authoring softwares. It is as if they are an afterthought, something to assist drawing creation, rather than important documents in themselves.

Why Schedules are Important in BIM

Human Comprehension

I have previously written about BIM being a deliverable for construction in its own right. The conclusion at the moment is it can't. Therefore we will continue to rely on drawings and schedules to communicate to other fellow humans. Even if you can export data from the BIM model to another database, at some point a human is going to have to read and understand that data.

Quality Assurance

Schedules are a great way to test data for errors. By manipulating how schedules are sorted and filtered obvious mistakes can be quickly identified.
They can also help rationalise design decisions by exposing similarities (or unnecessary dissimilarities) between elements.


But by far the most important reason to use BIM for schedules is consistency. By using data extracted from objects that appear on drawings there is going to be much greater consistency between drawings and schedules. This is often not appreciated as the inevitable errors in manually constructed schedules are discovered by some-one else further down the chain. As a young site engineer once told me, "BIM projects are great, I don't have to spend hours checking schedules match drawings, I just know they are going to be right".

How Schedules Work in BIM

Being of a practical mind I am going to provide a specific example - using Revit.  Not because Revit is the worst offender (I suspect other softwares don't even have the same level of functionality), but because I use and know it, as do many other people in the AEC industry.

In Revit you build a 3D model, then create views (plans, sections, elevations) of that model.
Annotation (dimensions, notes, tags etc) are added over the top of these views to create actual drawings, which are then placed on drawing sheets.

Schedules are another type of view of the model, except they just show data - values placed in parameters associated with objects in the model. This data may include dimensional information, location information, descriptive information, etc.
You can control which data to show, in what order, and include headings, totals and rudimentary formatting.
These schedules can then be placed on drawing sheets.

Schedule data can also be shared with other softwares. There are three methods:
  1. Schedules can be exported as a text file in CSV format, (comma or tab delimited), that can be imported into other spreadsheet and database software.
  2. By utilizing custom written software code data can be exported to proprietary formats like MS Excel, data can also be imported back into Revit from that proprietary software.
  3. Revit can also be connected via custom written software code to an external database, where data can be synchronised between the two.

 Is Exporting the Solution?   

Once a schedule is exported the link between drawings and the schedule is lost. Any changes made in the spreadsheet or database software will not be reflected in drawings. And any changes in drawings made after the export will not appear in the schedule.

So what, you might say,  that is how we have always done it. If someone makes a change they have to "talk" to others so they can do what is necessary to keep the two aligned (see my views on this in the comments of this epicBIM post).
But this where errors creep in. Even if this talking happens, there may be a misunderstanding, it may get forgotten, other priorities may mean it does not get done in a timely manner.
In my experience all but the very small and simplest schedules done this way are full of errors.

Which is why owners and contractors are increasingly insisting schedules be directly generated from BIM models.

So exporting schedules is not a solution. Either the schedules need to be fully managed in the BIM authoring software, or there needs to be a two way link between the BIM software and the spreadsheet and /or database software.

Both of these methods are possible. But how practical are they? Can ordinary architects, engineers, interior designers use them without requiring advanced computer skills?

Using Revit to Manage Schedules

As I said above I am using Revit as an example of BIM authoring software, I am not advocating it, nor am I inferring that it is better or worse than other BIM authoring softwares. But I believe it is necessary to be very specific to get a real understanding of the issues and problems involved.

Revit schedules are 'live'. Change a parameter in an object (e.g. a door) and it will instantly change in any schedule that includes that parameter. Change it in any schedule and it will change the object. (Note that not all BIM software works this way).

This is powerful - and dangerous. For example you can change the width of a door from within a schedule, which can lead to situations where the door no longer fits in the wall. Or change the size of a piece of equipment, which means it no longer fits in the room. As you can appreciate letting a schedule writer who is unfamiliar with how Revit works, or is not conversant with the building's design, loose in the BIM model can lead to havoc.

On the flip side those modelling need to be aware that what they do effects schedules. If they place a new type of door that door has to have the same parameters as other doors in the project. And those parameters need to be filled in.

Scheduling in BIM requires a more holistic approach by all members of the team.

But back to my original point - how practical is it to produce schedules - using Revit as an example?

Problems Creating Schedules:

Revit creates schedules based on categories - doors, windows, plumbing equipment, etc. (It is possible to create multi-category schedules, but they become complex to manage).
This means it is important objects are created in the correct category. This is not generally a problem, except when you need to create a custom object for the in-built system 'families' (Revit's name for components).
For example if you create a precast concrete panel as a stand alone object, you can't make it a 'Wall' category so it appears along with all the other walls in schedules.
(There is an undocumented work around. But it doesn't work for all categories).
Also Revit's way of managing custom objects - 'in-place families', does not support all categories. So for example if you want to model a complicated stair rather than battle with either of Revit's inbuilt stair creators you can't schedule it along with other stairs.

Inconsistent Parameters:
In schedules each column represents a parameter that appears in the objects you are scheduling. If all objects you are scheduling don't have the same parameters, or use different parameters for the same thing,  there are going to be problems with your schedules.
The user has to manage this for custom parameters ("Shared parameters" in Revit), but Revit itself is not consistent.
In Revit there are two ways of creating stairs - by sketch or by component. Even though they are the same category as far as schedules are concerned, they don't have identical parameters, so you can't consistently schedule them together.

On large projects doors are traditionally numbered after the room they open into. This practice means doors can be easily added without disrupting the numbering system, and it is easy to identify where they are.
Yet by default Revit numbers doors consecutively.
In theory you could use the 'Room To' parameter as the door number, but you can not tag this parameter in a drawing, so in practice it doesn't work.
All this makes creating door schedules unnecessarily complex - and non-BIM. As we have to resort to manually numbering doors after rooms the automatic link between drawings and schedule is lost.

The situation is actually more complex, as the the way Revit handles 'Room To' and 'Room From' is not consistent or workable, particularly since the introduction of the 'Room Calculation point' entity.

Room Finishes Schedules:
One of the most frustrating limitations is that we can not schedule room finishes in Revit. Although there are materials to all elements around a room, Revit can not gather this data into a schedule.
There are addins that attempt to do it, but really it should be native to all BIM authoring software.

Rooms in Linked Files:
Revit allows items in linked files to be scheduled, which is great. But it will only report rooms in the current file. So if you have furniture in a separate file (a common practice) which links in the building containing rooms, Revit won't report the room the furniture is in unless duplicates are made of all rooms and placed in the current file.
Once again, very un-BIM like - separate duplicates of the same thing.

Problems Editing Schedules

If you are managing schedules in Revit you need to edit them. But really all you can do in Revit is change the value of a 'cell'. There are no functions that help navigate a schedule.

  • You can't keep headings visible while scrolling through a schedule.
  • Rows aren't numbered or highlight-able.
  • Column widths of a schedule is the width printed  - which means columns are often too narrow to read their contents in a schedule view.
Where am I?

How can I edit it if I can't see it?

This lack of function makes any but the smallest schedules near to impossible to work on in Revit.

On large projects editing cells in a schedule can be very slow. Particularly materials. It seems Revit makes the changes after each cell edit. Maybe a 'Save' button would help.

Problems Printing Schedules:

The biggest issue is it is not possible to print a schedule across multiple sheets. There are work arounds, but they require messy set-ups and be actively managed to ensure schedules remain within sheet boundaries.

There is also  no in-built method to manage revisions to schedules (clouds don't work as schedules move as rows are added or deleted.). Again there is a work around - create a revision parameter and add it to schedules.

So although it is possible to do most schedules within Revit, it is not necessarily that practical.

Exchanging Data or Linking Software to Manage Schedules

Another strategy is to exchange data with, or link, another software package to Revit.
The advantage of this approach is software more suited to schedule editing and printing can be used. Software that is easier to use, and that schedule writers are familiar with.

Exchanging Data:

The most common methods with Revit is to use an addin that exports and imports to and from MS Excel. I have also seen one that does this with Google Docs (I don't think it is available any longer - pity).
Typically a schedule is exported to Excel, the Excel file is edited, then imported back into Revit where the changes are embedded into matching parameters.

Sounds simple, and works well when what you are doing is simple. But it can quickly become a web of (sticky) spaghetti if care is not taken to be consistent when setting up schedules.

This method can be very dangerous in the wrong hands. Changes in Excel are just text or numbers, and may appear benign, but once put back into Revit they can change the model in ways unintended.

Also keep in mind the process is controlled by addins and not Revit, you are relying on the skills of the addin software engineers to control this process. Some do it well, some are, well, just dangerous.
For example how does it handle objects in groups?

Do I really want to destroy my groups?

It is possible to establish a practical workflow as long as limitations are set on what can be done where. There needs to be restrictions on what can be changed in Excel, typically parameters that control geometric sizes of objects. For example the width and height of doors, (although door panel thickness and stile widths, being within the object, could be editable). Obviously no object can be added via Excel, that has to be done in Revit. Generally it is not possible to add columns in Excel that don't get written back to Revit, although there may be addins that allow this and manage that process.

The main problem at the moment is that all the addins I can find overwrite previous Excel imports. What this means is that any formatting and re-arranging done in the Excel file gets overwritten. Sounds trivial to a software engineer but a deal breaker to an interior designer or architect (maybe not so much to engineers).

The underlying disadvantage for exchanging data is it is not 'live' - maintaining the link between drawings and schedules is a manual process. This is not necessarily as bad as it sounds. Even with instant updating in Revit if you don't issue both drawings and schedules when either are changed the effect is the same - there is a mismatch in the information others have been given.

Linked Database:

It is possible to establish a 'live' link between the Revit model and a separate database. AutoDesk provide a free addin - Revit DB Link to achieve this (available via AutoDesk subscription).

But it is not a full solution. You need to set up the database you are linking to. Then you have to create an interface that humans can use to access and edit the data. This requires computer programmers (or removing some-one from billable work) to set up and manage. And on-going any change to layout or formatting has to be done by these experts (including changes beyond your control like software updates). These systems are so customised that if the person responsible leaves you may be left with a system no-one can use.

So in theory it might sound like the ideal solution but in practice it rarely works out.

A Note on External Software

Relying on external software is a valid strategy, but my concern is it removes responsibility from the BIM software houses to provide workable solutions. Instead of one group spending thousands of hours coming up with solutions many groups spend millions of hours on multiple solutions to the same problems.

And then there is the quality of addins. I have lost count of the number of unusable addins I have tested.

Another failure
If schedules from BIM models is a core requirement then the BIM software houses must provide a way to do it. A way that their ordinary users can manage on their own.


If you can find the right addin (and this is a big 'if') exchanging data is probably currently the best solution. But don't expect it to be easy. Take the time to plan, test and validate it does what you need before implementation.

At the moment it is unnecessarily difficult for the average architect, engineer or interior designer to create and manage schedules from their BIM software. Often the degree of this difficulty leads to errors in documentation that are equivalent, although different, to errors in documentation that occur when schedules are done manually.

Despite what BIM Evangelists say, BIM is dependent on software, if we don't have the tools we can't do it.
And if the expectation is that schedules are generated from BIM models, (which I believe is correct), then we need the software resources not to just make it possible, but to make it practical for the AEC professionals who create and mange them.

25 January 2014

Four Things BIM Doesn't Do

If we make the assumption that BIM contains all information about a project (or the 'index' for locating information), what is missing?  What stops us being able to issue a BIM model without drawings? (a question I asked in my post  Can BIM alone be used for Construction.)

I'm not just talking about lack of software functionality, but missing from current BIM processes.
I don't believe these missing things are intractable, a reason to not use BIM. The problem is that they don't seem to be a part of BIM discussion, let alone being addressed.

A BIM model is in theory a virtual representation of a real building. The assumption is that as long as everything is represented that is all that is required. Any shortcomings in practice is purely due to a lack of detail in the model, or poor modelling practices.

Keep in mind here that a BIM Model is not drawings. Currently we use our BIM softwares to produce drawing sets that are contract deliverables. But what about the utopian future BIM evangelists say is inevitable? What would a fully mature BIM model be like?
  • All information is in the model, one only needs to 'zoom in' to expose more detail.
  • Dimensions can be extracted from anywhere in the model.
  • All information about individual elements is available via the parameters they contain (which may include links to data outside the model).
  • Drawings are not created by the model author or contained in the model. Users create their own as they need them.

Sounds pretty good, not unlike many descriptions of what BIM is. But this is the description of a fully mature BIM model, once all the various authors and contributors have done their work.

BIM models don't start out with such comprehensive information. They can't. All construction projects are a series of decisions based on previous decisions. Decisions are iterative, a decision may cause a previous decision to be revisited and changed. Interesting the original intent of Revit (an acronym of 'Revise' and 'it') was to make it easier to change design documents, making optimization of designs more practical. Only later did Autodesk re-badge it as a BIM tool.

So when this description of what a BIM model should be is assessed against requirements during the design phase it falls short. The tools to communicate, manage and store information around decisions are missing.

So what are the four big things BIM doesn't do for designers.


Although everything is not known in precise detail during design phases there is still information that needs to be communicated. Design intent, what is important and what is not. What requirements are, and which of those are critical, optimal and desirable.

Assigning a wall as 'generic' only says a decision hasn't been made. It doesn't say what the limitations for making a decision are. And it only applies to individual elements, not to groups of elements.
Another example is dimensioning. Not all dimensions are equal in importance. The clear width of an escape stair is more important than the width of a store room. How do you convey this in a BIM model where the recipient extracts their own dimensions?

Rob Snyder, an architect and software developer at Bentley, has attempted to provide a solution. In his own words:
"A model is itself informational, while it 'lays out' an environment of information. Within that environment, we draw attention to specific things and instruct people to look at those things and to do something. These 'drawings of attention' are statements.
There are models and data. These are 'environments'.
There are drawings. Drawings are 'statements'.
I think of it like this - a statement is any means of drawing attention to something specific within an environment, and then saying something about that thing. In AEC, this has conventionally been done by making a drawing. A drawing draws one's attention toward something specific, and says something about it."
Rob Snyder, LinkedIn discussion Oct 2013

Bentely's solution to this problem is 'hypermodeling' - software functionality that provides links within a model to drawings, typically 2D details, although in practice the link can be to anything. It is basically an implementation and extension of web 'hypertext' (now usually referred to as 'links') to modelling.
What it does is provide visible 'tags' in the model that indicate points of importance, complete with links to why it is important.

Graphisoft have a similar solution, which they call 'Hyper-models' under the 'BIMx' brand name. Similar to Bentley it provides links to 2D drawings from within a 3D model.

Is this THE solution to the problem of intentionality?
Snyder, and Bentley's implementation privileges 2D drawings. Which is not surprising considering Bentley's 'evolutionary' approach of combining CAD and BIM. Graphisoft's approach is not so much a solution to intentionality as simply another way to access drawings.

But conceptually there is no reason the idea of hyper-modelling has to privilege 2D drawings. A tag could link to, say, an exploded 3D detail, a render of the architect's design intent, or a performance brief for a mechanical system.


BIM models are precise. Computer software requires precision. But the real world is not that precise, particularly where humans are involved.
It is not possible to always measure to the millimetre on a building site. Not all materials are uniform in size, even manufactured ones. Materials and elements move; concrete shrinks, bricks expand.
I discussed this issue in my post Accuracy vs Precision, but in this post my concern is the inability of BIM softwares to cater for the representation and management of tolerance.
Designers - architects and engineers, have to allow for tolerance in their designs if they are to be constructible.
But how do they do this with software that has no allowance for tolerances? Software that requires things to be exactly aligned and touching to work?

An example:

Walls are defined by the layers of materials that they are constructed from; e. g. plasterboard / stud / plasterboard. The thickness of these are set by the manufacturer's nominal thickness. In this example 13 / 92 / 13 = 118mm. But will this wall be exactly 118mm, everywhere, when measured on site?
Now say you have an escape corridor that has to be no less than 1200mm wide, with 118mm walls on either side. How do you ensure 1200mm is the dimension the building inspector measures after it has been built? You need to make a decision about where it is set out from (an intentionality issue - see above) and where construction tolerances are taken up. The question is how do you do this in a pure BIM model?

A common workaround is to add tolerance to material thickness, so 13mm plasterboard become 15mm. Problem with this is the estimator may cost 15mm plasterboard instead of 13mm, or worse the contractor orders 15mm plasterboard.
Another workaround is to model tolerances. For example add a 'tolerance' material 2mm thick to either side in the above example. The problem with this approach is you see things that are modelled. But tolerance is not something that gets built, it is an allowance that get absorbed when the design becomes real (like collapse of a quantum wavefunction). So it can get confusing for people when tolerances are modelled.

Like intentionality there are many ways this issue could be dealt with. But first it needs to be recognised a problem that requires a solution, something I have yet to see.


During the design phase there are many questions and unknowns floating around. Rather than everyone keeping separate lists placing these directly in the BIM model ensures they are available to all participants, in something you know they are going to look at.
What I like about comments in the model is the issues they point out remain in everyone's face until resolved. And in any case if in a proper BIM model they can be scheduled to create lists for those who like lists.

The problem of comments is similar to that of intentionally discussed above. The difference is intentionality is part of final deliverables, comments are part of the process of creating deliverables, but not a deliverable themselves. Nevertheless the solution to both may be similar.

Whilst it is true that elements can have comment parameters, comments do not necessary relate to individual elements. They may relate to multiple elements, elements missing, ("window required here?") or general comments not relating to any particular elements, ("redesign this area").

I find it surprising BIM software doesn't have this ability, or that people are asking for it, as it is common in lots of other softwares.

Once again there are workarounds, but they are usually annotation based rather than embedded in the BIM model. In Revit I use an annotation symbol with parameters that can be scheduled, but of course these are only visible on drawings, not really a BIM solution.


It is a normal requirement to identify changes between document issues. The method to do it on drawings is well established. But there doesn't seem to be an established method for BIM.

The method drawings use is not really suited to BIM.  It is not possible to manually flag a revision in the model. A change in the model may effect many drawings, each has to be tracked down manually to have a 'cloud' added. Revisions are added after the fact, whereas the act of making a change could in theory automatically flag a revision.

I have to admit I find the traditional method of managing revisions painfully time consuming, hard to enforce, and often uninformative (how many times have you seen "General changes").
But whenever I have suggested alternative methods that are more efficient and informative it fails to be implemented because it is not "the way revisions are done".

Other softwares keep 'histories' that could generate revisions, so it is technically feasible. (Andreas Ricke of AR Software Solutions has a Revit add-in that can track changes).

But what is missing is an agreed workflow or method that communicates changes. A few off the top of my head: Colour coding elements changed since last issue, automatic attachment of links to changed elements (like hypermodelling).

I'm not sure why a better method for managing revisions hasn't surfaced. Maybe it is a chicken and egg situation. The software houses are waiting for some agreed method from the industry, industry can't explore alternatives because the software can't do what they need.


To me these are the four big things BIM doesn't do that are holding back BIM from being a deliverable for construction in its own right.

I don't believe any are insurmountable. Although they will ultimately rely on software functionality, they require agreed workflows. Something that should come from the AEC industry. We shouldn't just wait for the software houses to make something up they think they can market.

Anyone have suggestions about where we start?

16 December 2013

Real BMP - Best Modelling Practice

In my last post I wrote about Minimum Modelling Requirements, and the lack of standards around what that encompasses. But looking at examples of Minimum Modelling Requirements, and BIM Management Plans generally, it strikes me that the majority of their content describes what I would call competent modelling practice.

I can't help thinking that if we BIM authors modelled properly all this would be unnecessary.

But is it such a big deal? Sure it annoys me that someone else is telling me how to do my job, but I could just ignore it.
The problem is the bomb shells hidden inside Minimum Modelling Requirements. Like "all walls will be modelled floor to floor", "all door hardware shall be modelled", "components shall be named as per the owners FM requirements", etc. But what do we expect when non-experts get involved in areas they know little about?

How about we BIM authors take back the initiative by setting our own Best Modelling Practices, our alternative to BIM Management Plans.

We should be doing it anyway to get our in-office teams working efficiently. Unfortunately the reality is that few firms allow the resources necessary. Management see it as an in-house overhead with no tangible benefit to the bottom line.
But what if BMP is escalated to being a requirement necessary to achieve BIM deliverables? That it is not just an office "CAD manual" but a description of the limits of your BIM deliverable. An antidote to the unlimited scope of work a BIM Execution Plan can trap the unwary player into. 

There will never be standard BIM Best Modelling Practices (despite the efforts of the standards junkies). Different BIM softwares (and different versions of the same software) require different approaches, also BIM competencies and BIM requirements differ. But really the details don't matter. If BMP cover appropriate issues and are well structured they will be adequate to achieve their aims.

What are the basics of Best Modelling Practice?


All BIM software categorizes elements. Called Categories in Revit; Layers, Levels, and the like in other softwares. It  is the name given to elements with a common function and behaviour, like Walls, Ceilings, Doors, Furniture etc.
It is fairly obvious that it is important the same things are identified together. That when you make only walls visible all you can see are walls, not kerbs, beams or parts of windows; when someone does a wall schedule it only lists walls; when thermal analysis is done walls can be identified by the thermal analysis software.
Sounds pretty straight forward yet it is amazing how often you will find a floor used for a ceiling, a floor used for beams, windows used as doors. Then there is the ambiguity that plagues furniture, joinery (casework), fixtures and equipment.

Make a list of your software's categories describing what each is to be used for. This list can be just for your office, discipline, or across all disciplines for a project. If it involves other disciplines list which discipline is responsible for which category.

If categories in your software are user defined, (Revit Categories are fixed, but ArchiCAD Layers are not), institute a method to manage parameters to prevent new ones popping up in an uncontrolled way. This can be a shared spreadsheet, project model manager, or the office BIM tyrant, (sorry . . . BIM Manager). 
If there is a hierarchy of categories (Revit has user defined subcategories), try and manage those as well.


Sometimes called attributes or properties. Basically the names of data fields used to contain data about elements, like Thickness, Material, Model Number etc. At the simplest level these are used to generate schedules, but may also be used for analysis, and to provide data to others for their purposes (e.g. FM).

There can literally be thousands of parameters in a project. For Doors alone it can run into the hundreds. Some try and list every conceivable parameter that anyone may possibly use one day. Some insist parameters follow a labyrinthine naming schema that only computer scientists understand (both of which happen if you get a "BIM consultant" involved). This is clearly ludicrous (see my COBie post).
The reality is that if you have managed parameters you can convert them to any other system. For example you don't need to use COBie names to export COBie, you just need to know which of your parameters correspond to the appropriate COBie attribute.

Start with a naming schema for your parameters. Even if they are only for internal use it is good practice to make your parameters identifiable as yours. The most common method is an abbreviated prefix, e.g. PB_is Existing.
Also insist naming be major - minor - subminor etc. so similar things list together; instead of Door Type, Frame Type, Glazing Type use Type Door, Type Frame, Type Glazing.

Next list the parameters needed to create your schedules, which, when you think about it, is just a list of schedule headings. This list forms the master list of parameters.

Then institute a method to manage parameters.  The best way is to limit who can create them, like the project model manager, or make someone responsible for schedules in your project team. 

A word of warning - don't overdo - remember every piece of data not only has to be put in, it has to be managed, checked and kept up to date.


Model Construction is about the limits on how things in a model are constructed.
This is a fairly fluid area which tends to change depending on the abilities of those working on the project, expectations of others, and limitations of software (which changes with each new version). It is also hard to make hard and fast rules. Whilst modelling down to 25mm might be OK for doors and windows, it is overkill for facade systems and equipment. Never the less it is worth establishing guidelines to help those modelling make consistent decisions and inform those receiving models what to expect.

An effective way to begin is to make a list of things that are ambiguous; the things users ask about, the things users do not do consistently. Work out what the alternative answers could be, and then pick one. Don't worry too much about being right or wrong. No-one really knows what will work or won't, we are all still grappling in the dark. And rest assured, if something doesn't work someone will tell you soon enough.

Some suggestions to start with:
  • Thicknesses: actual material thicknesses or a 'zone'?
    actual thickness mean dimensions are too precise (eg. 92 instead of 90);
    zones reflect reality - there is always tolerance, but then do you;
    - 'fake' a material thickness - which ones - structure or finish; or
    - add 'tolerance' materials.
  • Minimum size: what is the minimum size that will be modelled?
    what is identifiable on a 1:100 or 1:50 drawing; or
    actual size 50mm or  25mm;
  • Type of things not modelled:
    fixings (bolts, screws, fixing plates etc);
    materials or objects smaller than (materials thinner than 5mm, pipes < 25mm OD);
    controls (buttons, switches etc), hardware (handles, hinges, latches, hooks etc.);
    certain elements (reinforcing bar, single wire runs, etc).
    other's work (ducts if you are an architect, plant room walls if you are an engineer).
This list is not exhaustive, some projects will suggest different things.
If you are worried about the imprecision of it all, make general statements, like "model elements will generally not contain parts smaller than 25mm".


Lots of things in BIM software have user definable names. From wall types to fill patterns. If you are providing your BIM model to others your names will need to be navigable.

But that said, exact naming conventions is not that important to others outside your office. What is important to them is that naming is consistent and understandable. That the same thing does not exist under multiple names (e.g. same wall construction with different names); that names are human understandable by someone other than those that have memorized some archaic abbreviation system; that some computer friendly / human incomprehensible naming schema has not been used.

Another trap is to use project specific notation for names. Like wall type codes to name wall types. Not only do you have to be familiar with the project's wall codes to know what you are looking at, if the code changes you have to change the name. And what do you do early on in the project, before wall codes for the project have been developed? What do you call them then? And if you think you can create a master list for all projects think again. World experts can't do it (see section on Classifications below), and if they could why wouldn't you use theirs instead of making your own up?

My point is any naming schema must work during design phases, before codes, schedules etc have been established. And they should not encode information available elsewhere as a parameter. The worst case I have seen is COBie's suggestion that components have the room they are in embedded in their name. What happens if they are moved to another room?

So names of things should describe, using normal language, what they are. But be brief, you don't want names so long they don't fit on the screen. Structure names, major - minor - subminor etc. and use punctuation characters and capitalization to make them understandable.

Example Wall Type names.
<interior|exterior>.<Partition|Stud> <OA thickness> _ <exterior material structure interior>


Classification systems attempt to provide everything with a unique identifying number (or number/letter combination). The two biggest in the english speaking world are the US Omniclass and the UK Uniclass.

Classifications should probably be first on the list, but at the present time classification systems are not quite there yet. These systems were originally established for specifications and other AEC reports. As it turns out they are not that comprehensive, nor logical enough to be computer useful.

UK's Uniclass is more BIM friendly (according to them), but has many unfinished parts to it. The US's Omniclass is not as well structured for BIM, nor complete. Revit had to add non-Omniclass numbers when they introduced the ability to assign a value to Revit elements. And just to confuse everyone Omniclass includes tables called Uniformat (which is what the Assembly parameter in Revit is assigned to).

But in the long term everyone will be better off if we all just use one or other of these systems. It makes our BIM models discoverable without us having to do extra work, like follow the contractors or owners naming schemas.

I recommend getting into the habit of assigning Omniclass (incl. Uniformat) or Uniclass numbers to elements (pick one, don't mix them up!). Components (e.g. Revit families) should have them when constructed as a matter of course. Standard walls, roofs, ceilings etc. in template files should also have them filled in.
But there is no point insisting all project generated elements have a classification if it is not a deliverable. However by having pre-made elements pre-populated you will be more than halfway there when it does become a deliverable. 


To set your team up for Best Modelling Practice you need to ensure:
  • Categories are used consistently
  • Parameters are logically named, and there are sufficient to do the tasks required, but no more.
  • Model Construction limitations and practices are defined.
  • Naming of all things is structured and human legible.
  • Classification numbers are assigned, where convenient.

And the best way to do this is to document how each of these will be achieved.
Not only can this documentation be used to manage your in-house team, it can form the basis of a full BIM Execution Plan, or your contribution to a project BIM Execution Plan.

So what are you waiting for, start your BMP today.

I don't claim to be the font of all BIM knowledge. I'd be keen to hear from anyone who knows of other important Best Modelling Practices I may have missed.

15 November 2013

Minimum Modelling Requirements

The basis of BIM as a process is that information created by a participant for their purposes can be reused by others to assist them with their purposes.
For this to work 3 things have to happen:
  1. The information has to be there at the time it is required (i.e. is actually generated).
  2. It needs to be in a form useful to others (i.e. they don't need to re-create it)
  3. It needs to be reliable (at least for the purposes others will use it for).
The last is covered by LOD, the middle one is covered by designating software, or use of standards (like IFC), and the first is covered by Minimum Modelling Requirements.

The first requirement is the most important - the others have no meaning if the information doesn't exist - yet it is the least discussed and tackled by industry bodies. There is endless discussion and work being done on openBIM, COBie and the like; LOD is becoming mature and is now appearing in agreements and contracts.

But where is the clear definition of Minimum Modelling Requirements? Certainly many owner groups have tackled this issue and come up with their own solution - they have to, they operate in the real world where results are a necessity. But where are all the bureaucrats, academics and standards junkies?

Am I being unfair? - probably. I don't really believe the issue is being totally ignored. But the reality is where do I go to get practical advice on Minimum Modelling Requirements? Surely there is a better way than just referring to publicly available owner's attempts at solving the issue (and I say attempts because there is no way to assess how successful they have been).

Like all things BIM different participants have different views on what Minimum Modelling Requirements means. From owners who think it is just about ensuring they have a BIM based FM system at the end of the project to BIM mangers trying to get their team to model consistently.

Delineating Minimum Modelling Requirements

So let's start by trying to list what Minimum Modelling Requirements could include.


Who are Minimum Modelling Requirements directed at:
  • others so they can meet their own Minimum Modelling Requirements 
  • others documentation needs 
  • others analysis needs
  • construction needs (clash, sequencing)
  • costing 
  • FM 
  • your own needs (like documentation, analysis etc)


What are the types of information Minimum Modelling Requirements applies to:
  • element categories 
  • element geometry 
  • degree of detail (how much)
  • degree of precision (how small)
  • data (parameters)


What are (some of) the possible ways to define Minimum Modelling Requirements:
  • text description 
  • table / matrix 
  • no definition, just suitable for end use


How might Minimum Modelling Requirements be enforced:
  • contract deliverable (forced)
  • scope of works in agreements (offered)
  • included in BIM Execution Plan (agreed)
  • industry expectation ("reasonable professional" would provide)


Once Minimum Modelling Requirements have been established how might they be checked for compliance:
  • human sign off
  • computer checking
  • fit for purpose

Note that these lists are not all unique methods, some are alternatives that on the surface seem to have the same purposes. Nor exclusive; more than one may be utilized. But of course different methods will have different outcomes.

Different participants will use different methods to achieve what they believe are their aims. Owners like using end use / fit for purpose type methods as it shifts their responsibilities onto others. BIM managers like using highly specific software dependant requirements that can be computer checked because it makes their job easier (and they like using computers).

Current Examples

A comprehensive analysis of all attempts at Minimum Modelling Requirements would be a PHD in itself, and be out of date before it was finished. But I'll endeavour to show examples of different approaches to the issue.

MPS - VICO Software (US commercial)

VICO is an example of a number of commercial firms providing BIM planning services. They call their Minimum Modelling Requirements product Model Progression Specification (MPS). They also offer many other services around this so it is not a matter of simply purchasing a copy and using it.
I can't go into the specifics about their MPS as I have never used it, but it seems to be an elaboration of the [US]AIA E209 Document LOD table (the E209 document is actually based on VICO's MPS).
Commercial firms effectively make you pay to utilise their experience. But they also offer a service - they do some of the work someone in the team would otherwise would have to do. It is therefore hard to say if their success is due to the experience they bring or the extra manpower. I suspect it is both.

M3 - USACE (US government body)

The USACE (U.S. Army Corps of Engineers) Minimum Modelling Matrix (M3) is used by the US military to manage BIM construction projects. It is an example of owner created Minimum Modelling Requirements. It is freely available at their BIM web portal (with free registration).

The M3 relies on Uniformat 2010 codes being associated with every element. Uniformat 2010 is a hierarchical classification system that includes 'headings' that apply to multiple elements. The M3 has designated Levels 1 to 3 to these headings, with only Level 4 applying to individual elements.
As an example:
  • Level 1 is all equipment and furnishings (E);
  • Level 2 is equipment (E10) and furnishings (E20);
  • Level 3 is Commercial Equipment (E1030);
  • Level 4 is individual equipment type like Hospitality Equipment (E1030.50).
The M3 has a separate table for Levels 1 and 2 where general text descriptions of what is required are listed against each element 'heading'.

USACE M3 level descriptions

The other table has all Levels in a tabular format. Levels 1, 2 and 3 are just headings with little information against them, Level 4 is for elements, with a range of columns against them.

USACE M3 example

In terms of  Minimum Modelling Requirements the columns for LOD and Grade are of interest.
LOD means what we now expect it to mean - it indicates the level of certainty required of that element and is defined in terms of the [US]AIA E209 document. But only LOD 100 to 300 are given a definition, and in this table LOD is not associated with a milestone. Yet the other column of interest, Grade, is. But only for Construction Documents and As-Builts.

Grade sets how elements are to be graphically represented:
A   3D + facility data
B   2D + facility data
C   2D only (drafting, linework, text and or part of an assembly)
+   original grade modified
-    not included or tied to the BIM model (however is still required in the deliverable)
●   Refer to the other Levels 1 & 2 table, or is a heading (Level 3).

M3 definitions reflect strongly back to documentation. Many Level 1 and 2 requirements include
"... elements shall be depicted with necessary intelligence to produce plans, sections, elevations and schedules ...". LOD 300 includes "Accurate to the degree dimensioned or indicated on contract documents".
Other types of description are also found, although not consistently across all definitions. Things like "Small diameter (less than 1-1/2” NPS) field-routed piping is not required to be depicted in the Model", and "Slabs shall be developed in the structural model and then referenced by the architectural model".

So the M3 defines:

  • General modelling requirements (using text)
  • Type of graphic (2D or 3D) and whether data included. (using a table)
  • LOD (sort of, surely LOD changes between Construction and Record models)

As you can see it is really quite a mish-mash not only of methods, but also mixes documentation with BIM requirements.

Despite this the USACE M3 is often quoted as one of the best examples of Minimum Modelling Requirements freely available. From a practical sense I tend to agree. They are making a good attempt at encouraging BIM in an industry not yet geared up to provide it. Which is its Achilles heal when it comes to taking lessons from it. The M3 is not necessarily best practice for BIM proficient participants. In fact I believe it has the potential to hinder BIM use. But it is (so far) an evolving document and well worth keeping an eye on for future developments.

LOD Specification - BIMforum (US industry group)

BIMforum is a US based non-profit industry group. There are many of these, but BIMforum is worth a mention because they have recently released an LOD Specification.
This document was created in response to the [US]AIA E209 document and directly uses its definitions.

It lists elements using the Uniformat classification system, and against each element there is a list under the title of   "Element modeling to include:"
Like the USACE M3 it is hierarchical, but simpler. Higher order classifications contain descriptions that are typical referenced back to by lower order classification that don't require further modeling (typically for LOD100 & LOD200). Further, if an element has the same requirements as another, it references back to that earlier element rather than repeat the same information.

BIMforum LOD Specification Example

Strictly speaking I shouldn't include BIMforum's LOD Specification in a discussion on Minimum Modeling Requirements. LOD is supposed to be about what information can be used with certainty - not what information exists.

But one way to define what can be used with certainty is to describe the minimum amount of information required to meet that certainty. This method becomes a de-facto description of Minimum Modeling Requirements: if you do no more than meet the LOD Specification requirements you will have met your LOD obligations; if you have done more than that, others can only reliably use what the LOD Specification describes for that LOD.  

But BIMforum admit their LOD Specification is not intended to be for Minimum Modeling Requirements. In the LOD Definitions sections it list two examples of areas not covered: Size Thresholds and Clearances,  inferring there are others also not covered.

LOD is often mistaken for, or assumed it can be used for, Minimum Modeling Requirements. An instance of which I discussed in my last post.
That said they both make use of the same information - descriptions of element modeling. There may be a way to leverage this to reduce the amount of information necessary to define Minimum Modeling Requirements.
But I believe it is important to remember that LOD by itself is not enough to define Minimum Modeling Requirements.

DPoW  - BIM Task Group (UK government)

The BIM Task Group is a government body in the UK with the aim of "helping deliver the objectives of the Government Construction Strategy and the requirement to strengthen the public sector’s capability in BIM implementation".
I came across one of their draft documents while researching this post. Its name "Digital Plan of Work (DPoW)" [follow the links - requires registration] made me think it might be a good candidate for defining Minimum Modeling Requirements. Particularly as it may possibly be an extension of an existing body of work by the RIBA on building design and construction processes (RIBA Plan of Work).

But alas, I was disappointed, not surprised, but disappointed at another lost opportunity.
Admittedly it is a draft, but the problem is with the whole focus of the document, nothing a few tweaks are going to overcome.
Beside some items that probably should be in another document it is dominantly a proposal for computer based checking of COBie data submission.

For a start COBie is no-where near being a way of defining Minimum Modeling Requirements. COBie is only about data, not geometry, not end uses. It is a standard way of structuring data, it actually says nothing about what that data needs to include (see my post for more on COBie).

As a strategy, computer based checking is problematic. To do the checking some-one has to set up a checking system. That system will have its own requirements. So there needs to be Minimum Modeling Requirements Checking Requirements defined. And how is it checked that these Minimum Modeling Requirements Checking Requirements have been met?
Assuming the checking has fewer requirements than the actual requirements, in theory there could be a series of checking levels of reducing complexity, until a level simple enough for a human to grasp in its totality is reached.
But we all know what will happen in the real world. No-one will check the checking requirements. A template will be used from another project without being properly edited, because the person editing is not responsible for the outcome, the person being checked is. It will be left up to the parties being checked to highlight errors in the checking, creating an enormous additional work burden for everyone actually involved in getting the facility built.
Computer based checking has a place, as a tool in a kit of tools, not as a strategy for defining requirements.

The biggest problem is none of it is useful, or even close to being useful. Beside the fact it doesn't actually cover what is required for Minimum Modeling Requirements (or Plan of Works for that matter), it can't be used until the checking software is finished and tested. What does the industry do in the meantime? Keep doing it the old way then suddenly everyone switches at the same time to the new way? Are they serious?

This is a classic example of bureaucrats, academics and standards junkies tackling the Minimum Modeling Requirements problem. I just hope this is not the only attempt the UK government (or the RBIA for that matter) will make at integrating BIM into their Plan of Work concept.


At risk of being compared to bureaucrats, academics and standards junkies, I don't have any practical solution. I just don't think we are there yet.

At the moment I suspect the USACE M3 approach is the most realistic. A customised mish-mash to get the results required.
BIMforum's LOD Specification is new (released August this year) and largely untested. It is not designed to be customised so may or may not work for you. In any case it could only ever be part of a customized mish-mash as it doesn't cover everything required of Minimum Modeling Requirements.
If the money available a commercial provider is a good bet, if for no other reason than to lessen the workload and extra responsibilities a BIM delivery requirement generates for everyone involved.

But in the spirit of being practical I will offer some advice on good practices that should make complying with any Minimum Modeling Requirements easier.


  • Use your software as it was designed to be used - don't use shortcuts purely for the production of documentation.
  • Embed all the data you can into your model - then use it to generate all schedules.
  • Use categories (or their non-Revit equivalents) in consistent and transparent ways.
  • Insist on a robust co-ordinate base point.


  • Make sure all non-BIM and non-project specific elements are identifiable, and if possible remove them before issuing your model.
  • Check your model for consistency before issuing.
  • Provide documentation to others on how your model is structured.
  • Define the degree of precision you model to.
  • Create a table of LOD expectations for selected milestones.

Postscript - What's in a name

I've used the term Minimum Modeling Requirements throughout this post. But is it the best term?

  • Requirements makes it sound like an imposition. Something only the owner controls.
  • Standard? The level everyone is expected to achieve. Perhaps too soon to be meaningful.
  • Provision? The level to be provided. Bit like Requirement.
  • Contribution? The level each participant contributes to the overall BIM.

I like the last. Minimum Modeling Contribution. It can come from anyone, as an offer, or as a request. It is in the spirit of collaboration.