So, Clive is going to demystify Level of Development (LOD) for us and teach us about the connections with Level of Information Need. So, without further ado, I'm going to welcome Clive and bow out and let him lead us on this journey. Welcome, Clive. Thank you again. Thank you so much for having me. Hey, everyone. Yeah, today we're going to talk about LOD in its various different guises and Level of Information Need. and how that 17412 and the ISO 19650 (standards) and Level of Development (LOD), detail, definition, and also Level of Accuracy (LOA), all that comes together to hopefully be simplified and make some sense. So we'll talk about the origins and how those concepts have evolved and why you should care about that. We'll talk about the benefits of each piece and then how all of those can be combined into a cohesive framework. Easy for you to say. and then we'll talk about practical and i'll show you real examples of this and then i'll end with a bunch of links and resources that will help our industry adopt all of these in a very simple way and then if you've got questions we'll tackle those at the end so be prepared there are some scary acronyms and it's been a pretty roller coaster ride over the last 20 years but yeah hopefully we'll clarify and we'll make them a lot more simple for you guys the key terms that we will cover LOD starting with Level of Detail, referring to geometric detail, moving on to Development, and then even Definition, and the concept of improving that, but actually adding more to it in a way that maybe it wasn't perfect. And then Level of Accuracy (LOA) coming in and understanding that there was an additional set of aspects that we might want to understand about model and development and accuracy and as built. And then also the combination of Level of Information Need, not to be abbreviated as LOIN, but I think a lot of people... You see that a lot, so we're just adding that. That's the 17412 standard that's actually now combining geometry, documentation, and information. Lots of acronyms, but we'll cut through that. So let's start from the beginning. The origins of LOD started with the graphical 3D modeling in the 80s, and it was all about trying to optimize performance and complexity of these models. And it was about geometric descriptions of those. We started to then use those terms for BIM. and the origin in 2005. Actually, I was very fortunate to be part of that team in the Graphisoft and the VICO SOFTWARE days where we were really interested in how elements were defined in their geometric representation so that we could then calculate the quantities that was the real purpose of the LOD when it first was generated. And then it evolved as more and more people around the world started to adopt this concept. and there was the need for some standardization. And as you look at a building, it's quite obvious if you think about the one on the left-hand side and the one on the right-hand side, one of them takes more time, more commitment, more resources, more cost to actually develop, but it might not be needed. So if you need to define a scope, a specification for a 3D model, an output, you really need to understand what geometry... what definition, what reliability, what accuracy, what information, all of these different aspects. And if you can define that in a clear way, you'll really cut through all of the noise and make sure that the output is reliable and actually can be used for what you need. So when you look at it like this, it makes sense. LOD could be or the concept of a progression of a model could be one of these three states. and when this LOD 100 through 500 came out, obviously that makes sense. Easy peasy, lemon squeezy. You can define something at an LOD of 200, and everybody should understand exactly what is required of them and how they are going to produce it, how long it's going to take them, etc. Well, it wasn't so simple because we had a very inconsistent interpretation of LODs across the industry. They were really kind of misaligned from between what was asked for or what was given. So whether it's design intent or whether it's a requested model development level. And then understanding the information started to become a complexity. BIM is all about information. So when we are trying to define geometry and information and trying to keep it all in one specific number, it just became a little bit more confusing, a little bit more difficult. But there's a lot of resources. And when we look at the geometry, defining that clearly and early on would help teams to actually know what they're creating. So there's lots of really historical artifacts here. This is one from the Trimble days about understanding how you can develop a model, this for a wall and then for a slab, a composite slab. And what we started to understand was that there were so many aspects and one of them was the amount of detail in the model, the amount of components in the model. And as you break these down, potentially, it might be that it's not just one specific. linear scale. It's actually multiple things. In this example, this is not one to be used, but it's an example where it was broken into the model development and then information for estimating and information for scheduling, scheduling, programming, planning, timelines. And that became really important to understand how you would use the model for the aspects of estimating and the aspects of understanding program and timeline. So there became this shift from just... the traditional, what started as in the 80s, the detail of a model through to the understanding of the degree of development and how reliable was the information. So instead of it just being about geometry, we started to see a lot more parts to that puzzle. And when we first started the LOD concept numbers 100 through 500, there was a gap that was presented to introduce a progression in between. In the BIM Forum updates along the way, there were times where certain standards would or would not recognize 100 and 500. And then there were also instances where in 350 came in, it was more about model development that would be according to coordination needs. Unfortunately, what happened is we really combined a lot of the other pieces, the other aspects into these numbers. and components were included, which information requirements were included, what the purpose was. All of this started to be combined. And then we realized that. as an industry, level of development as a concept crammed a lot of information, a lot of requirements into a single number and a numerical scale. And the LOD framework was subjective because then we had to always refer to something else to be able to try and understand what it was that we were required to do. And therefore, we started to see the progression in the industry of other aspects being defined and level of accuracy came out. which enabled us to focus on what was either measured or represented accuracy of objects based on survey that was a certain degree of accuracy so that you could understand whether you could maybe fabricate from it or whether it was something that could be used in a renovation, for example, or if you were needing the gap exactly for a prefabricated component to go in, you could start to understand that. It was about trying to use. other aspects of specification to define exactly what was required. Accuracy, however, didn't fit in this scale very well because when we look at the degree of geometry accuracy and information as you progress through the scale of this LOD concept, at 500, we weren't necessarily wanting additional accuracy or additional geometry. We weren't necessarily wanting additional accuracy. Sometimes we were wanting more information as a handover. And this concept of LOD... at 500 for as-built conditions, there was a lot that was really important to be captured, but it wasn't necessarily this progressive scale. So there was a misinterpretation of the scale. And summarizing this so well, the progression through our industry, Marzia Bolpagni shared a great graphic a number of years ago now that shows where we started back in that 2004, 2005 with the original LOD concept. And then each different country and different year and different status starting to build out lots of different ways of interpreting it. It's an incredible graphic. It really depicts the story very well. And as we in each country started to explore what we needed, we started to realize that there were things that may be the original setting out of the requirements did not include. So then we started to see things like level of level of information. a level of geometry, and a whole bunch of ways of understanding LOD. So that really presented challenges for our industry. And what needed to happen, we needed a clearer way to define requirements about the data and the documentation. We needed to be able to align on a purpose. So we needed to be able to really describe why we were asking for information. We needed clearer ways of defining this in more robust setups, and also an emphasis on... not just the geometry, but also the reliability, the quality of the expectation of the deliverable. So there are in steps level of information need. Apologies for all of the abbreviations as LOIN, but it's a long phrase. The concept of Level of Information Need started because LOD was not sufficient and it was part of the milestones of our progress in our industry towards better information management standards. and Building Information Modeling (BIM) and the use in the 19650 series, a lot more on that. And there are many other resources that we can share specifically on ISO 19650. But the benefits of incorporating a new way of working enabled us to have a framework that broke down all of these aspects so that we can be more clear in defining each one of them. And it would support our decision making a little bit easier. Unfortunately, We've always got loads of changes in our industry when it comes to implementing something new, and the adoption needs somewhat of a simplification. Unfortunately, what happens if we just start expanding Excel spreadsheets and creating more and more columns and more and more rows of data, it doesn't become easier to understand, it doesn't become easier to implement, and it's certainly not machine-readable. So... there were lots of other things that we did. And Level of Information Need in its most simple approach, what we saw was a framework that defined a set of prerequisites. So we needed to know the purpose, why, why is the information needed? When is it needed? So when is it going to be delivered? What's the milestone that it's going to be delivery? And what the date is required? Who's going to create it? What it is? So what the actual object is, whether it's a... a specific piece of information or whether it's geometry on certain elements. And then if you break down that from a level of information need perspective into a framework, the key three components are geometry, information and documentation. Inside of geometry, when we thought about level of detail or level of development, it was really showing one part of this and then combined with a reliability concept. So as we went from level of detail to level of development, level of development was really about the combination of what the amount of detail was with. combination of the components and the reliability of them. So what we were really saying was, this is what you can use this set of objects for based on a level of development. And what we realized is that there were so many other aspects to that. And it could be that we need to understand whether the location is relative or absolute. It could be that we need to understand whether we are requiring parametric behaviour, whether we... want something to move with something else or whether we want it to just specifically be that object as a blob and not be intelligent as it gets adapted. We also understand that this concept of accuracy can be included in the package of geometry. So when we start to say how accurate is it based on a set of requirements and whether it's measured accuracy or whether it's represented accuracy. that's always going to be important for something from an as-built perspective in the end. So lots and lots of different pieces. Don't worry, I'm going to really simplify this and we'll go through them one by one and how you can actually create this. But the key concept in the level of information need perspective was to split these so that the information could be clearly defined. And as we incorporate more of the open BIM concepts with buildingSMART, we're able to define these in a way that can also be machine readable so that we can check information and whether that information requirement meets the original intent. There's a lot to cover, but if we look at this in a breakdown, we talked about purpose. And one of the things that Level Information Need does so well is says we must have a purpose because if we start to create information where there's no customer, there's no purpose for that information. we're generating a lot of waste. So one of the key things is to develop a purpose, which starts with the milestone, why we need the information. And then we need to understand what the scope is, what the set of requirements are. And that's not just the set of elements, but it's also the definition of project tasks. And that could be the requirement to appoint an information manager. It could be the requirement to complete a BIM execution plan or something along those lines. But this list of requirements of all of the activities and deliverables that are required for each of these milestones. is defined as a list. And then we start to see how much is required. So when we look at it and we think about. the concept of LOD, we might see that something is a lower level of development. And maybe we're representing that with a 2D object, or we're representing it as a 3D object or set of 3D objects. And as we progress through, it might be that we need more information related to some of these at handover, at the asset handover, but maybe less of the components. So we start to become able to define. what we really require for this HVAC system as a coordination set of elements, and then maybe an asset handover (AIM). We only need certain objects, certain assets, part of the asset information model, and certain properties on each of those. So how much is required of each of these aspects at each milestone is incredibly important. And then we also need to understand that these are progressing through a group of teams. And sometimes that responsibility transfers over. Maybe early on, the architect might be responsible for something that then transfers over to the structural team. Understanding who is responsible is incredibly important. And the handover of that responsibility is even more important sometimes to be able to track. So we start to see this management of information in a set of classifications and over a certain number of purposes, milestones in the project. and the details required for all of the tasks, not just the BIM, not just the elements, the model, but also and the responsibility of who actually has to carry those things out. So when you click on each one of these in a database, you might be presented with more information for each one of these cells. The unfortunate nature of an Excel spreadsheet, which we typically use in our industry, which are Excel fantastic tools, but using a database, you can really have a lot more behind each one of those cells without getting an overly complex and unmanageable set of spreadsheets, columns, and rows of data. So one of the things that I'll show you is how to build this up. and how to start to embed really detailed information. In this example, we're showing that it's appointing an information manager. There are specific requirements just described. There are things that we need to go through as a set of checklist items. We can describe even with a video that says, hey, this is how you carry out this task. So we're not just assigning a task to somebody. We're actually helping them to carry it out. Assignment of a team, a team member. the status of the task, the dates on the task, the milestone that it's in, all of that really, really rich information needs to be defined. So level of information in the framework, let's take a quick look at how we might go about defining all of these aspects. We're going to jump into the software side of things quickly. So one of the things that we would want to be able to do is add a... a specific actually i think i might be doing this in a slightly different order but let's say that we're adding some walls and we want to define what they are so they are a specific wall type and we could define what this information is required for for engineer something along those lines and we are defining a milestone and the milestone might be for a specific purpose so if we are looking for coordination on that milestone and we're looking for specific dates when that milestone starts and finishes and then we can describe coordination you'll have to forgive my spelling for the underground systems and x y z what we're able here to do is start to define the purpose of the information start to define the classification and the requirements and even down to the types for entity types if you're following IFC standards. And then we can start to define the requirements for this at a geometric level. And when we click into a cell, this is the part where if you were working with a spreadsheet, there would be many columns for every single piece of this data. What the great thing about many of the databases that you can use now is that you can start to click into and start to describe more. adding detail for this, adding checklists for things like, I need this to be appearance, realistic appearance. I need this to be location that is absolute. And I need to have it fully parametric. And then I need to define certain information requirements like. I need it to be combustible or not combustible. I need it to have a status of one of these types and I need to have a fire rating. I need to then define who is going to do it. So which team is going to be responsible and what person is going to be accountable. And then down to the dates for when this specific task inside of this milestone is going to occur. And also what the status of this task is, whether it's proposed, approved, etc. And then. The really requirements is to understand exactly what has happened on each of these tasks. So we can track everything occurring through from who started it to who finished it. And the Golden Thread of information captured for each of these. And then we might have requirements for files and attachments that can be also added. In the example I shared, it was showing a video, a set of videos. So very quickly, we're defining a purpose, a column, a milestone for that. So it's describing the purpose. Why are we doing it? We're doing it for coordination. It's required for this type of coordination for this set of requirements. The teams and the actors, the specific object in this example, it was a wall. We were generating, we're showing the detail required. And actually, one of the parts was being able to represent that with an image. So another thing that. is challenging running database versus spreadsheets. In a database, you can actually reference an image. In a spreadsheet... trying to manage images in a spreadsheet is quite difficult so that's sometimes why it's not done understanding what the object is going to be presented at so in our example we can throw up a 3d cube and represent that as a 3d whether it's relative or absolute what the appearance is going to look like so it's something whether it's symbolic or whether it has to be realistic do you need that to be parametric how accurate actually that was one of the things that we didn't do just now so if i was going to represent this and say I need as-built accuracy, and then I am able to pick what that level of accuracy is. So an LOA 30 is less than 15 millimeters, less than five-eighths of an inch, the accuracy, and we need to have detailed elements for that representation. So we start to define more and more of these and also how reliable. So in our example, whether it's proposed or whether it's coordinated and defining these in a really clear way. The information requirements we saw, not just what the identification of those are, and actually this is to represent there could be many other aspects that you want to capture as well. When we look at the information requirements as well, we might want to say whether it's true or false or whether it's a status. This is a status and it has to be one of these, whether it's new, existing, demolished or temporary. And these start to become the information requirements as the content. And one of the... key things in setting and defining these information requirements you must have a set of rules so that you can check as automatically as possible as to whether that has been met or not so if you're wanting to define something and saying that the number has to be between this number and this number you want to be able to define that in a way that is structured enough and known what the units are for each of those elements so that you can go about checking that as automatically as possible And then the set of requirements, whether it's a document uploaded or as a video that's linked to it, or whether it's a set of documentation that you need as an upload as a placeholder, that's all defined in that set of requirements for level of information need. So level of information need is this all encompassing framework that starts to add the requirements for what the level of development are. what the accuracy and what the really everything from what is defined to what it's going to be used for, to what information is required, what documentation would come out of that process as well. So that's the level of information need framework. The importance of combining all of these aspects is that we are able and I'll share these slides afterwards. But because there's a lot of text on some of these slides. But the principle of combining these is that we can create a more collaborative, a more efficient. A process that really helps that quality assurance and combining into level of accuracy that will really facilitate the seamless handoff to the as-built conditions and through to the facilities management and keeping that process alive as the whole life cycle of that built asset is managed. If you manage these as completely separate standards, we really run the risk of having a lack of alignment. We can have a lot of information in silos and maybe some teams following parts of standards. and some teams following parts of other standards. And that really increases the likelihood that there's going to be disconnects, more complexity, and there's problems in that misalignment. So there's a lot of rework and that cascading delay, the cascading effect of cost and potentially legal disputes. So this is really what we're saying and suggesting here is that having the opportunity to have a more flexible to be able to combine all of these for the benefit of our industry would be incredible. It would mean that we can have one focused set of requirements that has a really clear framework that will enhance the collaboration, efficiency, and everyone can benefit from that standardization. But how do we deliver this? How do we deliver these requirements? Today, as I mentioned, unfortunately, we have a lot of these spreadsheets and spreadsheets are great, but spreadsheets do, unfortunately, create an opportunity for everyone to go in a completely different direction. And so the traditional results are that... people end up having an antagonistic and dispute based on the problems that are encountered because people are talking potentially different languages. So what's the better way? What's the better way to combine all of these principles? Well, the openBIM approach is certainly the better way. And a lot of the team on the call are maybe very familiar with the openBIM approach. What we're really pushing for is the combination. Because of the opportunity of having a data dictionary that you can define machine readable and human readable information requirements in what's called the IDS, the information delivery specification, which can be used to create better information and then used to check information. And anything falling out can go through the BIM Collaboration Format (BCF) for reporting of these as quality challenges ("Topics") throughout that workflow. This Open BIM. and my focus here on the IDS is that already we are defining requirements in the information delivery specification that can be automatically checked inside of many applications. And it's how can we take the best parts of all of these aspects? So all of the excellent work that has been done in the past on the LOD specifications, all of the fantastic graphical representations that have been created. How do we combine that with the Level of Information Need framework so that you have a really key, clear set of requirements that builds on everything from purpose to how you check the information and into a specification that is actually a really, really fantastic technical framework. So buildingSMART has created this information delivery specification (IDS), which really allows us to start applying some of these other aspects in a way that teams can define clearly and other teams can receive and understand it in exactly how it's supposed to be interpreted. So IDS is pretty simple. Let's take an example of that. In this example here, where we've got a wall, let me bring that in here. Let me just delete this folder. So we just get this wall. We have a set of requirements, which are combustible, whether the property is in this pset wall common and whether it's true or false, and then fire rating and then the status and the status needs to be one of those values. In order to define an information delivery specification, we would export that from the tool that you're using and we would maybe filter those requirements and choose the format that you would like to use and create. And if we create an IDS example and then we download that example and we show you what it looks like, this is the part where I don't want you to get scared, but there are. There are specifications in here that are applied to a wall that is of this specific classification. And it's saying that my requirements are these properties and in this property specifically, which is. pset wall common and the status must be one of these values so the status property must be one of these values and the reason i'm bringing this up is not everyone can read this so so clearly but you don't have to as long as you can read it how it's represented here in a human readable way and you can export it from a tool that supports information delivery specifications you will be able to then ingest it in another tool of your choice in another part of your workflow, whether you're using that IDS file to create properties on objects inside of Archicad or inside of Revit. And yes, inside of Revit, we actually there is an add on available. And actually, I just jumped off of another meeting this morning about another that is incorporating this to be able to inject properties from a specification like this. into the objects to make it easier to model. So without totally confusing you and saying that this IDS is so simple, I've been working with it for a while. So reading that set of what looks like code and hieroglyphics is easier for me right now. But you might not need to even understand that. It's just about creating it in a tool that can then export an IDS that can be imported somewhere else. The impact of integrating all of these into a one single framework is a massive improvement in collaboration, efficiency, risk mitigation and improving facilities management and lifecycle management of these built assets. Not going to go into details. As I said, I'll share these with you as a set of slides afterwards. I also wanted to share a bunch of resources. Building Smart has some really fantastic resources about the Open BIM workflow here, Leon. is talking about that workflow and showing you examples of using IDS and creating requirements in that workflow. This is a great video. Some more resources for level of information need. I'm not sure why that was not shown. We've got some great videos in our YouTube channel that I can refer you to and things about combining the level of detail, level of development, level of information need concepts into a single place. The concepts of level of information need broken down in a really practical way so you can start identifying understanding this as a concept hopefully this is an introduction to it it will be clearly explained in some of these videos that we can share the links to i mentioned this overarching framework that is starting to become the international building information modeling and information management standard which is the ISO 19650 standard - a five minute video here about why we should care you and what it means to us. That will be another link. If you're interested in more detail on the ISO 19650 workflow, here are some training videos. There's actually a six-series episode of this. More IDS resources that I will share, and also lots more about the Building Smart Data Dictionary (bSDD) and how you can use that in your workflow to create IDS. Resources coming out of our ears, the information delivery specification can look daunting, but lots of videos on that and simplifying that workflow. So hopefully you'll be able to understand that set of hieroglyphics. And then we also have a bunch of training videos that incorporate that, everything from the basics of creating a BIM execution plan to understanding Exchange Information Requirements (EIR) and also how to access a bunch of templates for all of those things as well. I'm hoping that there's a bunch of A bunch of questions queued up, but the key points that I wanted to share during this short introduction to all of these different aspects. Level of Detail (LOD) started off by focusing on how do we define geometry? Because the team that created it was more interested in evaluating geometry to create quantities for estimating and scheduling. That then evolved into the concepts of development and definition. as standards. And we also saw, because of the requirement to understand the maturity, the reliability of that set of geometry as well. But we realized that the limitations and the combining of information requirements, even into a single LOD number scale, really did mean that it was difficult to package, difficult to interpret, and sometimes led to some owners requesting an LOD 400 model and nobody really understanding what that meant. So this led to the need for the Level of Information Need framework. The Level of Information Need framework could actually benefit from an aspect of what the geometry is and how detailed that geometry is. And the benefit could be really incorporating all of that fantastic work that the BIM Forum and the teams that have been developing the LOD specs through the years have created. So combining those also with the added benefit of Level of Accuracy (LOA), this concept of how reliable, essentially, do you want to create this model? If I'm going to measure based on this accuracy, am I going to measure with a tape measure or with a laser scanner? And then when I'm going to represent that in the model, how much am I going to want to represent? If the wall isn't specifically flat, am I going to represent the undulating surface or am I going to represent a straight wall? And then my hope is, and I think we're on the right course, combining all of these aspects into the framework of Level of Information Need but also delivering it using the Information Delivery Specification (IDS) It means that not only can we define something that humans understand, but it's also something that all of the machines that we use in the BIM workflow, all of the tools, we're able to export and import and still understand exactly what has been required. it will assist us in creating deliverables. It will assist us in automatically checking those deliverables. And it really will make everyone's life a lot easier as we incorporate more of that into our workflow. Thank you for listening. My contact details are there if you want to get in touch. We love talking about this stuff. Apologies if I've thrown many acronyms at you. And hopefully some of them are now a little bit more familiar. but there's a long journey for understanding in our industry. And we hope that you come along with us and tell us what we can do to improve as we all build better standards and better workflows for the built environment.
