If you’re struggling to cope with the excessive use of TLAs (Three Letter Acronyms) in BIM circles, then you may throw your hands up in the air when faced with the above formula. You might argue it is mathematically incorrect, unless LOI = 0; or you might suggest it is completely nonsensical presented as it is. And that last point I will concede. So many aspects of BIM, or at least the definitions or implementation of BIM, make very little sense. Anyone would think it’s another language entirely, invented just to bemuse the majority and keep so-called BIM experts safe in their black arts.
If you do a Google search for BIM LOD, you will get a number, a plethora even, of hits for “Level Of Development” of a BIM model. The AIA (not a BIM-specific acronym, but referring to the American Institute of Architects) has publicised this term in its 2008 publication “AIA E202-2008: Building Information Modeling Protocol Exhibit” to help define, essentially, the content of any part of a BIM project. The UK also uses LOD, but here it is defined as “Level of Definition”. What does either actually mean? First let me explain the problem LOD is trying to resolve…
Expectations and understanding of what BIM is varies greatly. While a common consensus is obvious to those “in the know”, the majority of the construction industry is still fighting to comprehend what it is they will produce, issue and receive. Even for those who had begun work on BIM projects, it was still a matter of subjective opinion what would be included in the model. In the example of an air conditioning system, a structural engineer might be expecting to receive dimensionally accurate ducting layouts to ensure their structural openings would be an adequate size, an architect may only need an approximation of zoning in order to work up their circulation layouts and minimum headroom, while the reality is that the services engineer is only working on 2D schematics oblivious to the others’ expectations. This lack of communication and common perspective leads to delays, friction and in many cases error. The CIC BIM protocols in the UK detail a “Model Production and Delivery Table”, more commonly referred to as a “Responsibility Matrix”, to clarify what information is going to be produced at any stage and by who. Simply put, you assign an LOD code against each building component or system at each progressive stage of the project so the complete team knows what to expect. The basic codes differ between the US and UK conventions, which only serves to further confuse the issue:
|Brief: a model communicating the performance requirements and site constraints. Building models would be block models only.
|Concept: a conceptual or massing model intended for whole building studies including basic areas & volumes, orientation, cost.
e.g. for an HVAC system, this might include block models of the plantroom locations and distribution risers.
|A design development model, “generalized systems with approximate quantities, size, shape, location and orientation.”
e.g. for an HVAC system, this would be more what the architect above expected: duct runs modelled to approximate routes, but at an accurate overall size to include maximum potential sizes without detail of flanges or accurate radii of bends.
|Production, or pre-construction, “design intent” model representing the end of the design stages. Modelled elements are accurate and coordinated, suitable for cost estimation and regulatory compliance checks.
This LOD would typically be a model suitable for production of traditional construction documents and shop drawings.
e.g. for an HVAC system, this is what the structural engineer was hoping for: accurate duct sizes & locations.
|Installation: an accurate model of the construction requirements and specific building components, including specialist sub-contract geometry and data.
This model would be considered to be suitable for fabrication and assembly. Architects or engineers would rarely produce objects at this level.
e.g. for an HVAC system, the cut lengths of duct runs, fixings; a CAM model.
|An “as built” model showing the project as it has been constructed. The model and associated data is suitable for maintenance and operations of the facility.
|Asset Information Model used for ongoing operations, maintenance and performance monitorin
The UK convention can be better visualised as:
The problem with a single LOD code is that not all objects graphical representation relate directly to the information they need to contain. It is a simplification of intent that does not allow for the iterative design stages when modelling a visually accurate object might actually be counter-productive and overload a model with unnecessary detail. Take the simple example of a door: while the architect may prefer to see visually correct detail (including vision panels, recessing, handles and hinges) none of that is needed for LOD 4 / 300, “a model suitable for production of traditional construction documents”. All you need for that is a location, an accurate width and two rectangles joined by a line and arc to denote swing direction. Without a doubt, to be able to produce accurate quantities and schedule the items correctly, that data is going to need to be included. An electrical lighting system may never need to be modelled at LOD 4 / 300 level, as the locations of switches and fittings might be totally symbolic; their data would be anything but. Conversely, at earlier stages it may be critical to develop geometry to a high level of visual development in order, for example, to resolve complex details or clash detection purposes when little is yet known about the performance or exact specification of any objects.These definitions can be found in numerous places on the web. What isn’t specifically stated is the amount of non-graphical data contained in any of the components or systems. In both the AIA and UK definitions it is implied by the “allowable uses” of each LOD model; the data contained in or linked by an object reflects the analytical use. For LOD 2 / 100, basic attributes would be included: cost per metre (or foot depending on your location). Continuing with the HVAC example LOD 3 / 200 would see that increased to include flow rates, expected dimensions which would extend into more accurate data through LOD 4 / 300. By LOD 5 / 400, the object might include its constituent materials, accurate cost or performance specification. LOD 6 / 500 would have maintenance schedules, safety monitoring, and so on.
A better approach to this, and one designated in a number of example BIM Execution Plans from around the world and the AEC (UK) BIM Protocols, is to define graphical and non-graphical attributes separately.
Coding for graphical representations, the Level Of Detail, is easy enough. The AEC (UK) BIM Protocols define the graphical appearance as:
G0 Symbolic. Not to scale, merely a “suggestion“ of where the object will exist. In terms of doors, this might simply be a black rectangle in a 2D wall.
G1 Placeholder. While it may be to scale, the object may not represent the appearance of the final component. In terms of doors this would be a simple, plain object without frames, vision panels or hardware.
G2 Suitable for construction. This is where you would provide geometry representative of the final component. It may still not include hardware (as this would typically be specified separately) but could be a manufacturers downloaded object.
G3 High resolution, fully detailed object. Typically only used for visualisation, or in fact, manufacturing.
Visual representation has always been understood and is easy to group into basic expectations (although architects will still insist on G3 objects when G1 would serve perfectly well). An alternative method is to specify LOD as the related drawing scale the graphics will be presented at. This is a much easier to understand approach, inherent in many designers’ thinking. The difference between a door at 1:100 and 1:20 is simple to visualise. LOD defined as drawing scale leave much less room for ambiguity.
The Level Of Information is harder to codify as each project might be drastically different, and will vary greatly per component or system throughout the work stages. As outlined in last month’s BIM Brief, the most accurate way to deal with what attributes will be included is to list them in a tabular format. It should be a fairly easy task to identify what information will be needed at any stage, as this would be the contractual information you would normally produce. It doesn’t mean that the other stakeholders in the BIM project would need that data (none of the engineers would ever care about vision panels) but it does help rationalise in your own minds what information you need to deliver and when. As you prepare for BIM production, it’s always worth remembering that you don’t need to include the data just because you can; more often than not it is better to simplify.
At any stage then, the Level Of Definition – less confusingly becoming referred to as LOMD, Level Of Model Definition in the UK – of each component or system is totally explicit and can be as flexible as necessary. The Level Of Model Definition is a combination of graphical “Level Of Detail”, and non-graphical “Level Of Information”. The formula should now be clear:
LOMD = LOD + LOI