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?

CATEGORIES

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.

PARAMETERS

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

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".

NAMING

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 

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. 

SUMMARY

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.

Postscript:
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.