≡ Menu

The simple idea behind LOD in all its forms (Level of Detail/Levels of Detail/Levels of Data/Levels of…) is critical to providing benefit to Owners in today’s connected world. Managing the complexity of systems in the built environment, without such organizing structures is difficult at best. Yet, the controversies, arguments, water-cooler discussions, and positioning for personal gain related to the concept seem never ending.

The excerpt below from BIG BIM 4.0: Ecosystems for a Connected World, is an attempt to define the context in which LOD functions to support Owner needs in a BIG-BIM Ecosystem. Often, the simple ideas behind LOD have been ‘tweaked’ to support the needs of little-bim. These ‘tweaks’ have tended to create new silos of data, rather than fostering connected information that supports the longer term benefit to Owners and society. They enforce contractual requirements, limit thinking to narrow slices of the bigger picture, and take us on tangents to the real issue.

The real issues are simple to use, accessible, decision making information, when and where we need it. At a cost of time, money, and energy that we can afford, TODAY. That is what LOD is really about.

BIG-BIM 4.0, Chapter 5: Assets, Not Projects, pages 177-181

Level of Detail Origin Story

On the morning of January 15, 2004, on an airplane headed to Cleveland, Ohio, Kimon Onuma sketched out what was to become known as the concept of Levels of Detail (LOD). In the sketch, he referred to the idea as Data Repository Model, Level Definition.

The idea was to describe a sequential model development process implementable in a fiscally constrained environment. It involved first connecting existing information and making it computable. Step-by-step, over time, information was added in ways that required little new funding. As facilities changed, the process was captured to make the information in the model more complete. Until the model grew to become a virtual representation of the real-world condition.

1st LOD Sketch

Over time, the LOD conception has evolved to be a foundation of BIG-BIM and the basis of our ability to integrate data in ways that enable connected decision making.

Since the release of BIG-BIM little-bim in 2006, many have written about Levels of Detail, Levels of Development and similar structures for making Building Information Models. When you read their material, you understand the various positions that different organizations and systems have taken. For example:

Most focus on LOD as a prescriptive requirement. LOD is used to define what must be included in the model to conform to a contract or team working requirement. Others focus on LOD as a measure of capability. In this view, LOD divides users and companies to assess their competence, much as one might use a qualifications exam. Another segment uses LOD to describe the stage in the development of the model. This approach most closely aligns with the early vision.

There are also hybrid approaches that try better to define LOD and the inherent complexity of information models. These approaches either break out information from the virtual model or create new acronyms that, in their view, better describe the process of developing models.

None of the approaches accurately represents what is happening as the model develops. Each is a rough approximation of what is taking place with little-bim. In a BIG-BIM ecosystem, LOD has almost no value. There are near infinite levels of detail for many possible metrics and data in BIG-BIM.

Little Red Blob hierarchy

For most currently accepted LOD definitions, the Red Dot model would at best be the lowest level. Most LOD scales ignore the data, even though the data is arguably the most valuable part of the model, by far. The data could represent everything about the Red Dot model, up to and including the data for drawing a highly detailed graphic representation of the object the Dot represents.

Use LOD as you must. In some situations, you will have no choice if you wish to participate. Keep in mind that LOD is little more than a mechanism for assessing, controlling and paying for work modeled in desktop authoring tools. The real value and most of the power falls in other places.

You can create information models in steps, with little or no data loss in the transitions. By setting up a concept that defines a long-range plan for data, information models can be implemented much like one might implement a contacts database—over time. In a BIG-BIM environment, this is the preferred means of moving from zero to a resilient and fully realized enterprise model system.

BIG-BIM becomes beneficial very quickly, especially when created in an agile development environment that isn’t sequential, and it can be added to continuously as asset conditions change and new information becomes available.

You start with a container or little-red-blob on the site. You then collect and connect existing data. Then you add massing, then some spaces. You tag areas for costs, metrics, and type. This, and that are added because they are available, or it seems like the data might be beneficial. You throw everything you have into the little-red-blob that is quickly becoming a data rich information model.

Rich Data at an infinite number of LOD

From step one, the model is computable. It can compute areas, show relationships, generate pie charts and plans showing metrics. You can visualize blocking and stacking. Project costs are overlaid with a timeline to enable ta better understanding of the overall concept. Will the facility fit on the site? Can we afford to move forward in this direction? Can we use this approach to satisfy mandate X?

BIG information models progress through a nearly infinite number of Levels of Detail. Arguably, the graphic representation is one of the less important items on this scale. Models at any LOD can be (and are being) used to manage assets and portfolios in some of the largest enterprises. In a BIG-BIM environment, even the lowest LOD model can give an owner the ability to do capital asset planning, work order management, scenario planning and much more.

Why use sequential processes when we live in a rich multi-faceted world; and have the tools to work with the richness?

The sequential processes at the heart of most uses of LOD harken back to the siloed workflows that most BIM experts seek to eliminate. Is a step-by-step process that mirrors workflows where each trade builds their model the best way? Is this the best way to manage the life cycle of facilities?

LOD has little value beyond helping to describe processes that use little-bim authoring, analysis, and collaboration tools. Only when confined to the control of design and construction operations is LOD necessary. In this arena, LOD helps to control the sequence of events, the scope of work product and contract compliance. Outside of this area, LOD quickly falls by the wayside. LOD assumes a sequential process in the development of information models, as occurs in design and construction, some of the time. The reality is that things are complex and messy. Most of the effort does not happen sequentially.

Look at each task and stage of the BIM process. Understand that, contrary to many publications, Levels of Detail is little more than a coarse-grained approximation of what is taking place. There are too many LOD to count. This is where BIG-BIM comes to the rescue. Embrace the fact that models at all stages can simultaneously be maintained as live assets. BIG-BIM enables the data and models to be used when and where they are needed to get the job done. Across the lifecycle of built environment assets.

Explore the little-bim subset of BIG-BIM, and understand the complexity and nuances of how the connection economy is impacting the built environment and professionals everywhere. Get your copy of BIG BIM 4.0: Ecosystems for a Connected World at Smashwords, Createspace, Amazon, or the iTunes/iBook Store.

%d bloggers like this: