There still seems to be some confusion about what LOD levels mean, and how they should be used. I must say I have difficulty relating what I do and what I need whenever confronted with filling in an LOD table. If they are this difficult why are we using them? Are they really useful, or just a waste of our time? HISTORY OF LOD From what I can gather LOD was developed by Vicosoftware, a software company that produces construction costing software. They saw the advantages of costing straight from a BIM model, but had a problem. How do you tell how accurate, or how definitive, the model elements you are connecting to in the model are? Traditional methods of costing have a human between what was being measured and the way it was being measured. But automatic take off from the BIM model doesn't. So they developed the concept they call "Level of Detail". A measure of how definitive an element is in terms of costing it. So LOD 100 meant not very definitive, an area or volume rate is accurate enough, LOD 200 you can assume the number of items in the model is correct, but use an estimate for each, LOD 300 items are identified and actual cost can be used, LOD 400 is a measure what has actually been supplied so can be used to assess payments. Sounds very sensible, very precise. But then the AIA (American Institute of Architects) decided that this system would be a good one to apply to all uses of a BIM model, from energy analysis to 5D programming. They sensibly renamed it "Level of Development" because "Level of Detail" could get confused with the amount of information, rather than the decisiveness of the information. Although both still have an acronym of LOD so the two continue get confused (more on that later). Others have taken up the concept, and today it has become one of few common BIM concepts that is kind of understood by all (more on that later). WHAT EXACTLY IS LEVEL OF DEVELOPMENT LOD, as in "Level of Development", is a measure of how seriously you take the information represented by a BIM element. It is not necessarily a measure of the amount of information, although obviously there must be enough information to satisfy the LOD level it is at. It is also not a measure of the amount or accuracy of graphical information. The appearance of a BIM element is only one piece of information about that object, and usually the least important. A contractor doesn't need to know what a desk looks like to order it, nor to place it in the building. But they do need to know what the manufacturer and model number is. Others may need to know its dimensions to coordinate with things around it, but they too do not necessarily need to know what it exactly looks like. Therefore LOD levels for a chair might go: LOD 100 = there is a chair LOD 200 = there is a chair that has nominal space requirement of 500x500 LOD 300 = there is a chair with arm rests and wheels LOD 400 = manufacturer and model number. LOD 500 = manufacturer and model number, supplier, date purchased or in general terms: LOD 100 = there is a thing LOD 200 = there is a thing about this size LOD 300 = there is a thing with these functions and options LOD 400 = it is this particular thing. LOD 500 = this particular thing provided by this person on this date. The purpose of an LOD table is that it tells others what information they CAN USE. To put it another way, it is a measure of the certainty, or confidence, of that information. So even if a chair in the model contains information that would satisfy LOD 400, only the portion of that information that satisfies LOD 100 can be relied upon with any certainty. This means a chair family from a manufacturer could be used at LOD 100, but everyone knows (by referring to the LOD table) that this particular chair is not necessarily the one that will be actually used. LOD is also a measure of progress. At LOD 100 there is obviously more work to do to reach LOD 300. In that sense it is like the traditional percentage complete of drawings. Assuming LOD 500 is 100%, then LOD 100 = 20%, LOD 200 = 40%, LOD 300 = 60% etc. Except LOD contains more information. It tells you how decisive each element is, not just how complete its representation is on a drawing. It is more useful to know that on a plan the floor is 60% complete (LOD 300), the walls are 50% complete (LOD 250) and the service ducts are 40% complete (LOD 200), rather than the whole drawing is 50% complete (the average of all elements). SO WHAT IS LEVEL OF DETAIL Level of Detail is a measure of the amount of information provided. Because it is only a measure of quantity, the underlying assumption is that all provided information is relevant to the project and so can be relied upon with certainty. Because of the confusion between the two LODs, most BIM guides and plans use other terminology for Level of Detail. Some examples: CIC (Penn state) "Information Level of Detail" - AKA "Info" A - Accurate size & location, including material and object parameters B - General size & location, including parameter data C - Schematic size & location USACE M3 "Grade" A - 3D + facility data B - 2D + facility data C - 2D, part of an assembly or text description AEC (UK) BIM Protocol "Graded Component Creation" G0 - Schematic G1 - Concept G2 - Defined G3 - Rendered USACE is probably based on the CIC definitions, but customised to suit the current abilities of BIM software and the consultants they use. I suspect it may change over time. The AEC (UK) grades include 'Rendered' which is purely graphical, which seems to suggest it is a measure of graphical detail only. Their accompanying diagram shows 3D representation, although presumably 2D only would be acceptable. LOD TABLE STRUCTURE Typical LOD tables are a 2 dimension matrix, down the left side are Model Elements, across the top the first heading is project stage or Project Milestone - (e.g. Concept; Schematic; Documentation; Construction; As Built), below that is LOD, and any other measurable, like MEA (Model Element Author), Grade (Level of Detail) etc. Some are others loose and flexible (like AIA E-203): some are incredible long and complicated, (like Australia's NatSPEC): The most common other addition is "Model Element Author". This is, as the name suggests, the authoring party of an element. Typically this is the structural engineer for structural elements, mechanical engineer for ductwork etc. It has nothing to do with LOD but is useful information as is sets out who does what. My reading is it sets out who is the creator and responsible party in the BIM model, and not necessarily contract deliverables like drawings and schedules. For example the architect may be the MEA of structural elements because the structural engineer won't model accurately enough for the architect's purposes (see my previous post Should Engineers Model Accurately). But of course the structural engineer is still responsible for structural contract documentation for construction. Other additions include the Level of Detail (AKA Grade or Information), and really anything else that may be useful. In the past I've included method of delivery which provides a timeline for when information gets put into the BIM model. BUT THEY AREN'T CALLED LOD TABLES Although I am using the term here there is actually no such thing as an LOD table because LOD is used in tables with other things, and for slightly different purposes. Some of the names for tables include: Vicosoftware - "Model Progression Specification" (US)AIA - "Model Element Table" USACE - "Minimum Modelling Matrix" or "M3" Veteran affairs (US) - "VA Object Element Matrix" NatSpec - "BIM Object Element Matrix" So really LOD table is a generic term to describe to tables that include LODs. Is any name better than others? Again I think Vicosoftware got it right. LOD tables may describe other things, but LOD fundamentally describes how information in a BIM model will progress. How much information will be usable at each stage or milestone of the project. They use "Model Progression specification", but "Model Progression Table" or "Model Progression Matrix" are just as good. DEVELOPMENT or DETAIL - IS THERE A DIFFERENCE? Level of Development and Level of Detail are closely related. You can't have a certain Level of Development if the Level of Detail doesn't exist. Only defining the graphical level of detail seems pointless. It doesn't matter how realistic a chair looks, if you don't have the manufacturer and model data no-one can cost or order it. It just looks pretty. The level of graphical appearance doesn't necessarily progress during a project, it may actually go backwards. The realities of a project usually mean you use the highest Level of Detail at the beginning when there is the lowest Level of Development, as this is when you use rendered images to sell the design to your client and stake-holders. And to keep the complexity and size of your documentation model low during documentation you want to use a low Level of Detail, even though the Level of Development is quite high. Of course Level of Detail could explain more than just graphical appearance, but it still doesn't communicate what everyone needs to know - what information can I use with certainty? And is there any point defining Level of Detail if it is required for Level of Development? Probably not. To avoid confusion we all should always use the acronym LOD for Level of Development, and use some other term for level of detail. "Grade" is used by a few BIM guides, but it not very descriptive. To keep the metaphor going how about "Depth of Detail" (DOD), where each LOD is a level of certainty passing through the Depth of Detail. The diagram on the left below shows what is meant when you use Depth of Detail only, the one on the right when you use Level of Development (which by inference includes DOD). IS THERE A POINT TO LOD? The original restricted use for Level of Development (LOD) developed by Vicosoftware makes sense, but when you apply it to a cover all uses for BIM information it starts to loose clarity. The reality is LOD levels means different things for different uses, so now you need another table - the BIM Uses table - to explain what uses each LOD level can be used for. LOD makes sense if you link it with model elements (by putting it in a parameter for example) so your costing software can extract LOD data directly from the model. But when it is listed in a separate document where is the advantage? It seems strange (and not BIM like) to keep LOD requirements in a place separate from where those creating the information that satisfies those requirements are working. Shouldn't it be part of the model accessible to all those working and using the model, not in a separate spreadsheet or word processing document? Indeed is a better use for LOD one where it describes what level of development (or certainty) an element is after the fact? Users nominate the LOD of elements they are working on as they go. As element information becomes more definitive it's LOD increases. Then LOD would be in the model, and extractable as a schedule. When first explaining LOD to a director (an architect) his initial response was "you mean LOD is the same as a project stage". My first reaction was "well, yes and no". But when I thought about it, yes it is. By separating LODs into different project stages it is just stating the obvious. Of course at concept stage most things will be at LOD 100, at As-Built Stage LOD 400. There will be some things at different LODs, but is it worth filling in a massive table for these few exceptions? Which leads to me to my other reservation. Are they serious when they say every model element type has to be listed with it's own author and LOD? And use Uniformat or Omniclass or Masterformat? It is not just the massive amount of work to do it, who will ever refer to it? Do they really think the mechanical engineer is going refer to it to find out if he has to model duct work because some-one else might be going to do it? Going by the current BIM guides and standards an LOD table is both over complicated and yet imprecise. A lot of effort for little practical benefit. If people just followed the BIM guides and standards there is a real danger LOD tables will be a "tick the box" task. Done once and never referred to again. But an LOD table could impart some useful information. What is that information and what is it the best way to communicate it? WHAT AN LOD TABLE IS TRYING TO COMMUNICATE An LOD table is an attempt to record agreed (whether voluntarily or not) responsibilities around a BIM model. As mentioned above, it only relates to the BIM model, not other deliverables or responsibilities. For each part of the BIM model and at each stage of the project we need to know: Who is the author and responsible party. What is in and not in the BIM model. How much of the information embedded can be used with certainty. Obviously the complexity and amount of detail required for each of these will be different for different types and sized projects. The level of sophistication achievable will also depend on the BIM experience of the project team. So to have a one size fits all approach doesn't make sense. THE LOD CONCEPT So should we throw LOD tables out and come up with a better alternative? Many have made the same suggestion and even come up with alternatives. I've seen what used to be LOD tables have LOD removed and replaced by percent complete, because everyone understood what percent complete means. Some have replaced LOD with Depth of Detail (like USACE and AEC(UK)), because that is easier for people to visualise. But I think LOD is a good idea - as a concept. It holds more information then Depth of Detail or percent complete, but is still a simple concept. I don't think it is a good idea as a 'standard', if applied too rigorously LOD tables quickly become irrelevant, and a management burden on projects. So, a bit like the definition of BIM (see my previous post What does BIM mean to you?), it is best to treat LOD as a broad concept rather than a precise tool. We all need to understand what it generally means, but still appreciate it means different specific things to different people, and on different projects. FLEXIBLE LOD TABLES The (US)AIA E-203 Document uses LOD and MEA (Model Element author) in its Model Element Table. But it is not highly prescriptive about how that table might be constructed. Although Uniformat is suggested, it is not compulsory ". . . there is no single best system for classification of the Model content.", and "the user is also free to delete or alter the CSI structure and insert another guideline or a firm specific or project specific model element structure." The structure of LOD numbering, broad definitions 100 apart, leaves plenty of scope to slot in extra numbers with special meanings for your project. I've used 250 and 350 before to overcome issues around services construction design being done by D & C contractors. The (US)AIA E-203 is also not strict on LOD use itself, suggesting items not modelled be identified as "NM". This could be expanded to code where the information can be found. And just to make it really flexible the Model Element Table has a notes column for each stage plus a notes column for each model element. I believe the (US)AIA approach is the right one. Use the broad structure and concept, but tailor it for your own purposes. HOW TO MAKE LOD USEFUL The best way to make LOD useful is to think about how you can make LOD meaningful to your project and the project team, or your office if you are the BIM manager. If you are required to do an LOD table say you will comply the (US)AIA E203 document, rather than one of the other BIM guides. It gives you pretty much the freedom to create an LOD table any way you like. Don't be afraid of doing a really simple LOD table, particularly if it is your first one. If the project team is using Revit there is no reason you couldn't list Revit categories as your building elements. If you are comfortable listing trade packages, do that. Create your own LOD levels. That's why the standard ones are so far apart, it is designed to have other, in between levels. Just make sure you define what those levels mean. Do multiple LOD tables if it helps. I do a simple short one for sign off by directors, owners and sometimes the contractor, and then a more elaborate one (which aligns with the simple one) for the project team. By taking this approach you could, for example, make the AIA E-203 Model Element Table simple, so that it only sets broad requirements (and therefore flexible, always a good idea when signing a contract), yet still have the opportunity to be more precise when managing the project team via a more detailed table. And finally think of other uses for LOD. Remember, it is a concept, not a rule. Why not have an LOD parameter for objects in your model to track progress and work as a QA check? For example: - LOD 290 = preliminary construction defined; - LOD 292 = checked for functional requirements; - LOD 294 = checked for fire requirements; - LOD 296 = checked for smoke requirements; - LOD 298 = checked for acoustic requirements; - LOD 300 = final construction defined; Let's take ownership of LOD and make it our own. Postscript: A discussion on the [US]AIA E203 document LOD defintions can be found in my post LOD, are we there yet. 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 and ... men. Book one of the series, "Awakening the lost woman", is available now on Amazon, Google Books, Kobo and iBooks.