Model-Based Concrete Design at the Fornebu Metro Line

VETLE BIRKELAND: Welcome to this case study session called Model-Based Concrete Design at the Fornebu Metro Line where we will be showing parts of our project and we will try to answer whether our model-based project's worth it for the structural discipline.

The agenda for today, we will introduce ourselves. And we feel like it's also important to introduce our definition of what a model-based project is because it's not a fixed term. We will go over our model deliveries, some of our key workflow components. And at the end, try to list some pros and cons of a model-based project, and some key takeaways and lessons that we've learned.

What we will not discuss is interdisciplinary process, the nitty-gritty of how we coordinate our solutions. That's more VVC material. We will not go into the overall BIM requirements and list out all parameters and go super into in-depth into our model maturity indexes. And we will not give a detailed description of our organization and our workflows.

MATS BJERVA: So my name is Mats Bjerva. I'm a structural engineer with a taste for BIM and digitalization. I graduated with a master's degree in structural engineering in 2016. And I've been working on some of the biggest-- Norway's biggest BIM projects for the last few years of my career as a BIM coordinator and design engineer. So mostly of my career I've been working model-based and haven't printed the drawing for the last five years.

VETLE BIRKELAND: I'm Vetle Birkeland. I have four years of experience working in [INAUDIBLE]. And I'm here because I manage some of our in-project developed tools in Dynamo. And I, unfortunately, have printed in the last five years.

So firstly, a bit of context. The project, our client is Oslo [INAUDIBLE], Oslo Municipality. And we're in the capital of Norway, Oslo. And the project is called Fornebubanen. So we're in the south of Norway in the innermost part of the Oslo Fjord.

And the capital of Oslo is expanding in the southwest direction. And the government has decided that we need to extend the metro system with an 8-kilometer-long stretch and six stations towards Fornebu. The new line connects to the existing metro system just outside the city center. And it goes underground from there.

Like I said, there are six stations, and they are architecturally ambitious. And for us working on it, it's a prestigious project. And also, I think, for our client, which is Olso Municipality. And on Norwegian scale, it's a pretty big project. It has approximately 200,000 meters of concrete, and that's not including the tunnels. There's also steel and timber, which is in the model-based project. The tunnels are not included in this presentation because it's a different contract.

The design started in 2017. Construction started in 2020, and it's expected to be finished in 2029. And to cost approximately 3 billion US dollars.

MATS BJERVA: So first, we're going to talk about model-based design and how we define it. Most products, they are somewhat model-based. We normally collaborate in using BIM 360 or Autodesk Collaboration Cloud, and we use 3D modeling tools to model and to coordinate ourselves.

But the one thing that stands out with Fornebubanen is that we also deliver mainly models. In Norway, we have, for the last few years, had a term called no-drawing project, which-- or drawing less projects. But as we have matured, this kind of project, we have figured out that a model-based project or model-based design is a better term because not everything can be conveyed in a good way through a model, or it can be very time-consuming to do so.

So we deliver IFC models. That's the main format that the structure discipline delivers. Other disciplines can deliver IFC or DWGs. The main reason for IFC for us is that it's an open file format that can be used by everyone. As you can see on this example here, we have a lot of different software being used.

And there is a lot of different requirements that needs to be met. And IFC is also open for the contractor, so we have-- there's a bigger chance that they can use this format. We are now open to deliver other formats if that's better for the client and the customer in the end.

So the bread and butter of what we deliver is the IFC model for the geometry. This is the first place to look and it contains almost all the necessary information to build, and it contains links to both the tender and the details. It's a centerpiece of what we deliver.

Our focus is on making it correct enough both for construction and also for tender. We'll go a little bit further in detail of how the model looks for when it's issued for construction later. But here, you can see an example of one of the stations, for the geometry model for one of the stations, which is a sample, the parameter set for a generic concrete slab.

Alongside the geometry bar model, we have the rebar model. So we're going to also touch a bit more detail about this later on, but here, you can see, on the IFC model for the part of the station we just looked at, and an example property set for rebar.

One thing to note here, this is the only thing we deliver for the rebar. So we don't deliver any bending schedule. The contractor themselves have to export that out from the IFC models using Information Takeoff or other tools for that.

There's a lot of information that's needed for proper construction, and a lot of it is standardized or can be standardized, and it's the same for the whole or the majority of the model. So therefore, to reduce the amount of repetitive information in the model, we have this annotation drawing.

So here, we group information that can be on parameters, but they are the same. So we group them here and keep it the same for all the structure. An example of that are tolerance classes and chloride classes. We also have some general principles for rebar. For example, overlap lengths for rebar and shape codes.

But one of the most important aspect is that our models aren't perfect. So we try to model as perfect as possible, but as a fail safe, we have to emphasize that there are things in the rebar model specifically that won't always be correct. So therefore, we have-- on this annotation drawing, we have general principle that should always be followed whether or not they are modeled-- they are like that in the model or not.

An example of that is rebar in bends. So this is a critical-- if this is done wrong on the site, it can be a critical error even though it's very hard to see in a model containing thousands of rebars. So we also have other examples of this, but this is probably one of the most important ones to note.

And the third thing we deliver is the detail sheet. We try to model as much as possible in the model, but sometimes details are just the best. This tends to be the case for membrane and joint details, as well as steel connection details, we will have a lot of annotations and a lot of text to explain what is going to be built. You can just look in the model and see the geometry you need, the actual specific information regarding how it's built up.

So you can see here is an example of a joint element in the model, which we then reference to the detail sheet where we have this detail that explains the build-up of the detail. This is generally also very applicable when we have contractor design or prefabricated elements that we only model or detail halfway and the contractor themselves finish the details for the elements, or if there are places where we know there's a lot of room for changes.

For example, when we need to change our details to the existing bedrock but we don't know it before because in the previous enterprise, that isn't finished yet. Or if there are things that are very time-consuming to model for the tender. So this is also an important to note, that if you would have all these details in our models, they would become very heavy and contain a lot of complex information that, in worst case, can be very hard to work on a small handheld device.

So the fourth thing we deliver is a BIM letter. There are, sadly, for all software that we have witnessed, there are still some issues when you export to IFC or to DWG, for that matter, to any format. And the same can happen for a PDF export. You don't-- you can never trust that the export is done correctly.

And there are some specific issues that we have noted that are fixed now in the newest version of Revit, but we have to list all of these issues in this BIM letter and if we can't fix them easily in the model. So you can see here an example of a slanted wall that was exported wrongly in the previous versions of Revit, but that's fixed now. So we list-- we make this list if we can't fix it easily in the model.

So also, it's important to note that there are still some drawings that we need to make due to requirements from the Norwegian government. For example, if there's something connected to a road, we require to deliver more or less fully detailed 2D drawings of this structure. This is something we-- there's already talk about change in this aspect, but for now, we still have to keep it like this.

There is no standard for what model-based design means, and so therefore, to connect all these things together, we have made what we call the BIM Execution Plan for Construction. This explains how the IFC models are built up and how the contractor can use them.

It also gives direct requirements for how the contractor should give back the as-built data to us and to check that whether or not all of the structures they have built are within the tolerances that we have set for them. This is considered a legal document and is part of the tender and the contract between the contractor and the building owner.

So now we're going to go into some more detail about our model deliveries. We're going to touch upon what it means to deliver right quality at right time in a model-based project, and we're going to show you an example of a geometry and a rebar model for when it's issued for construction.

So all projects have this in some way-- or should have this in some way, a plan for the maturity of the model and the interdisciplinary coordination, and the timeline for the project. But it's even more important for model-based project to have control over this, I think, because if you don't do this correctly, you can end up with a way to detail model in the early phases and you spend a lot of extra time doing changes that you shouldn't have done.

And so we have developed this status, these seven statuses that are a simplified version of the Model Maturity Index System, which, each of these stages represent a critical milestone in the maturity of the models. And in the earlier phases-- so S0 and S1, which is the pre-project or before we just know that there's going to be a stage, but we don't really know how it looks, we end up modeling very roughly.

So we can group several components-- for example, slabs, insulation, and membranes-- into one element. You can look at it as a volume reservation. That we, on the structural discipline model, and then other disciplines, their own elements, and we get the rough look of the building.

But then as we mature, we split these elements into-- each component into their own element. So we end up with specific elements for concrete and for membranes and insulation. So it's easier both for the contractor to look and see the model and you can use it for detailing, and you also have direct link to the tender. So you have one element is one work assignment, so to say.

So we move through these statuses or this phase in the project over several years. Right now, we are between S4, the tender process, and S5, issues for construction for the majority of the project.

This is very important to have correctly defined early in the project because as I said, you will end up modeling a lot more details early on that are simply just a waste of time in the early phases. So at the bottom here, you can see an example of the detailing of a column where we, in the earlier phases of what we call the interdisciplinary freeze, S3. We just have the geometry element of the concrete. And then from S4 for the tender and the issue for construction, we model details in rebar.

So the geometry model issued for construction, or S5, as we call it, we're going to show you a little bit of example of how the models look, what we end up delivering to the client and the contractor. So it's important to note that the model will be built as is. There is no rounding of measurements in an IFC export like you can do on a 2D drawing. So it's very important to know that-- to use the axis in Revit and model-- set things out with the measurements and not just draw freehand.

It can be very time-consuming to read this-- do this if you-- later in the project if you do this early. So always start on a good basis and follow the axis system properly, and generally we use the measurements rounded to 5 or 10 millimeters.

This is also very important for when you generate rebar so that you end up having automatically proper lengths for the rebar unless you use some kind of rounding tool for the rebar. So the casting joints between elements needs to be modeled correctly. This is easier to do if you turn off of the joint function in Revit, but this is something that needs to be done 100% before the model-- the rebar is modeled. If not, we're going to end up with a lot of tiny small changes and you will end up also wasting time doing something that you shouldn't do.

So the parameters are also a very important part of the geometry model. There are things that you need to know for proper construction on parameters. For example, comments and references to details and material grades, and also surface treatments or finish for concrete slabs and et cetera. So the parameters are very vital part of the model, as it always is in the I in BIM.

So our models can be quite large, and they contain work for a long period of time, both for the designers, us, and the contractors. So therefore, we split the models into delivery or delivery packages, which are their own mini-projects with their own deadlines and their own process for interdisciplinary freezes and collision controls, and their own deadlines and deliveries to both the client and the contractor.

So ideally, this is split after the plan progress on the site. As for this example, you can see here, this is colored by the different delivery packages in this station. For this station, it will be very easy for us to guess what they will build first because we know that they need to start in the bottom and build upwards. But for other stations, we have a more flat design. This can be very hard to guess. So we do our best guess with the building owner, and then we do the final planning when the contract is signed.

So even though we have split the model into delivery packages, they are still quite large and contains thousands of elements and months of work. So we split these delivery packages into even smaller pieces called production units. This is ideally planned with the contractor so that the production unit coincide with the planned casting joints and the progress on-site.

But unfortunately for this project, we do not have a contract yet, so we have to do a best guess and split the elements where we structurally need them and model casting joints where we need them. And for large elements like slabs and long walls, we don't split them into separate small elements because we don't know how the contractor will cast them on-site. That's something we can do later when we have this input.

So the production is the main thing that makes it possible to understand our models. Without them, it will be 1,000 of elements floating around with no way of knowing what goes where. So production contains everything that's going to be casted or introduced, built at the same time.

So for a concrete element, that would be rebar, and also, of course, the shape or the geometry, and embedment inside the concrete, both for our own structural discipline and also for from other disciplines. We also use this term for steel and timber elements in this project.

So here, you can see an example of a production unit. This is a medium-sized wall with the rebar colored by the position number, and also some embeddings from both the-- but mostly from the electrical discipline with regards to the door.

So the rebar model, that's something we don't start working on generally before after we have finished the tender process and where we are in this the final detail phase of the project. We do model some-- remodeling sometimes where we have to communicate complexity for the tender. If something is rather complex compared to what you normally would believe, we can deliver these models. But normally, we do also do that in 2D details because it's easier to do quickly and finish up.

Our models are not perfect in any way, or they're not collision-free. We're trying to duplicate the level that we would have on a 2D drawing, because delivering perfect rebar is very costly. So we let out collision that can easily be fixed on-site we don't fix in the model. You can see an example here of some rebar colliding with the U-bars of the concrete-- in the concrete. And this can easily be moved on-site without any major issues.

But critical collisions we do fix in our models. This has been made it a lot easier in Revit 2022 and 2023 with the newest features, move Rebar in set and propagate the rebar. We use real diameters with the tolerances for the actual creation of the bars when we model this rebar. So we put this into the model bar diameter parameter, that's also rather new, to ensure the believability of the structure. So you can see also, here is an example of bending schedule that you can take directly from the IFC model.

So now we're going to touch a little bit upon the key workflow components, how we ensure quality and efficiency in how we work. We're going to touch a little bit upon standardization, organization, automation, and quality assurance.

So as I mentioned, there is still no official standard for what modal-based means for structural models. For the contractor, we have made the BIM execution plan, but for us engineers, we need an even more detailed standard for how things should look. So therefore, we have made this digital production manual that tries to explain how everybody should work.

Our models should look the same regardless of whom worked on it. So in this manner, we have requirements for how the geometry and the rebar should be modeled, how it should look, and also set up how families should be named and the parameters used for them.

So there's no more loading of families from another project you have locally saved. Everything has to be standardized. So we create this database that contains all the families that can be used in the project. We don't include each and every type of a family, but we do have families for almost everything that you need. And if you won't have it, we create them with the proper parameters and the proper naming scheme so it fits into the entire project BIM requirements instantly.

We also have requirements for the IFC exporter and which version needs to be used. So we are in tight dialogue with Autodesk through the GitHub with new updates for the open source IFC Exporter.

So one thing that's a little bit different or new in 3D model is the wall orientation. You don't have-- it's harder to define what's interior or exterior in a 3D model than you would do on a section. So therefore, we base the sides of a wall on the cardinal directions of the wall.

So as you can see here, we still use the Revit exterior/interior in side definitions, but we moved the walls of the exterior and interior are either facing towards north or south depending on the side on the orientation of the wall.

VETLE BIRKELAND: During the lifetime of the project, we've had somewhere between 50 and 100 structural engineers depending on their level of engagement in the project. And every time we onboard a new person, we have to be-- it's most likely that they're encountering something new. A new level of attention to detail in the model and a new way of working.

And in that respect, we have to be crystal clear about what we are trying to achieve and how we're going to do it. And this is what we're trying to do with some of these documents that gave guidelines for how we use information in the project. And so to reduce some of that initial friction that arises when you encounter something new.

And as we mentioned, we have six different stations and in the project. And each of these stations is like a mini-project unto its own.

But since we're trying to standardize across these-- the project in its entirety, we have to try to reconcile some of these different skills and experiences that these different stations have with the people that are working there to create a consensus on how to do specific tasks, which specific families to use, s and how to design a specific thing. And decision-making can be a little bit tough because there are a lot of opinions that go into that.

And the interesting thing about this project is that we have people who started their careers on drawing boards when AutoCAD was the new thing in town. And some of these people are foremost experts in the materials that we use to build and how we build them. They're just not necessarily the most Revit-capable. And the challenge that we have is to try to translate that experience into our Revit models to increase the quality.

And also an interesting thing is that we place very high requirements on our modelers. They not only need to know how to work efficiently in the model, they also need to know how the tender process works and how the contractor may want to build and what other disciplines-- what their concerns are and vice versa.

So typically that might be something-- a skill set than an overview associated with a project manager-level position, but it's so much easier and this goes so much smoother when these modelers are proactive and can see things for themselves and make independent decisions.

In a model-based project, the models, they grow very large and detailed. And we introduce, actually, a number-- a higher number of repetitive tasks because we have to model everything. And so the need arises to try to automate some of these repetitive tasks.

And in that respect, we first have to try to decide where to put in that effort to complement our software with essentially our own code. And there are two key considerations that we have to make.

Firstly, we are construction engineers and not software engineers, which basically means we should not tackle anything too complex. We're looking for problems that look that are simple on the surface because those problems are typically easier to solve algorithmically.

Also, we have to identify the highly repetitive tasks, the low-hanging fruit. Where can we do the most good with the least amount of effort? And we have to make this code on a scalable format so that it's easy to propagate in our organization.

So naturally, we have almost fully automated the enriching of parameter values on our elements in the project. And that's not so strange because we basically have a recipe for that in our project documents. If this element is placed here and has that classification, it should have this element. It's a logic that's very easily translated into code.

For the form modeling part, we haven't done as much. And the reason for that is, if you think about any building you've ever been in, it's not very easy to spot a programmable pattern. Why is that column placed there? Why is that wall placed there? There's a lot of contextual knowledge that goes into the placement of all of those elements, which is hard to code.

It's much easier to program the creation of elements that go inside other elements or attach to them, which is why we have made an effort in the detailing phase where we add rebar, fire insulation, embedments, and so forth and so on. And so I thought I'd go a little bit into detail on one example.

We have a script that generates general reinforcement in walls and slabs. And the entry point for this code is the area reinforcement class in the Revit API. And what we basically just done is to augment that, the Revit area reinforcement macro in Revit, so that it creates new bars.

Coding-wise, it's not a very ambitious project. It's not very hard to make and it's an easy code to read. It's not very complex. But it gives us a lot in return. So it's an easy text input that anyone can assign, and it adheres to the standard direction symbol for floors, and uses the rebar cover parameter to assign the cover.

So I thought I'd show a video. As you can see in the video, this script does not produce 100% finished results. I'd like to say that you're somewhere between 70 and 95% finished with reinforcement in an element after we run the script depending on the complexity of the element.

And so we have other scripts to do the rest. Parts of it, at least. But what you gain from that is that you're more-- you're sure that you can use this script for more elements. You can get some parts of the way for 80 to 90% of the walls and slabs that you have in your model because you try to account for all variability in one element, you exclude most-- a lot of variability in other elements. So it's about predictability and scalability.

So as you've noticed, we use Dynamo to create these automated tools. And that is simply because you get a lot of things for free. Again, we're not software engineers. We don't want to make custom user interfaces. With Dynamo Player, you get a user interface template that's very easy to adapt to the needs that you have, and it's also very easy to distribute.

One specific thing that we've done, though, is to eliminate all use of third-party packages in Dynamo. Not because they don't work, but because we want to make these scripts independent of the configuration on the end user PC. So if you have 20 different users of one script and you have to have the exactly the right packages installed to use them, you introduce a lot of uncertainty and you increase the threshold for many people to use it.

Also, it's transparent. We can be ready and anticipate changes in the API when we go to a new release of. Revit so it's efficiency improvements not only by improving efficiency, but also by securing continuity and scalability of what we make.

So I've added some picture examples of some of the other things that we've done. On the top-right corner, you can see, we have a finite element model with a satisfying degree of accuracy so that we can assign the rebar intensity parameter automatically using the firm design data automatically.

Under that-- underneath that, we have an example where you can assign the delivery package parameter which is coded based on the element's placement in space, and its classification. And it's a one click and assigns the parameter to the entire model.

Under that, we have modeled all the formwork for the in situ concrete, which is done algorithmically. And if we hadn't made some tool to do that, I don't think it would be viable for us to model all the formwork. And under that, again, we have an automatic creation of fire installation of steel elements. The key idea is to simplify the problem, not make it too complicated because then the code will be complicated and you will have more problems.

So quality assurance has also been-- is a little bit new when it comes to model-based projects. Firstly, we require new checklists that incorporate checks on element information, and that's because it doesn't say necessarily on the drawing element-specific information, it's assigned to the element itself. And some of this information is critical for how it's going to be built.

And also important to note is that when you have a level of automation in your project, that also requires a special attention to the quality assurance. Imagine if you've made a tool that mass-produces something and that tool is flawed, then you have essentially mass-produced an error if you didn't catch it early on, so it could be critical.

One interesting thing about doing quality assurance on a 3D model is that people feel that the quality of the check that they do is directly linked to their capabilities in a 3D model. How good are they at navigating it, rotating it, and filtering out what they need? So that's something that people need to get used to. But we feel like with the tools they get to help them, that it works.

We use Solibri for QA of the models, and we have rule sets to check for collisions, duplicates, rebars within-- that rebars are within the cover, information takeoffs to check our parameters, and we do visual controls with the ITOs to filter out to filter the information.

You can use other software to do this, but it's important that you do the last quality assurance on the file format that you deliver to the client and to the contractor simply because there is no guarantee that it will look the same after you've exported it, and you want to catch all of those.

MATS BJERVA: Yes. So lastly, we're going to talk a little bit how about how the contractor can use the models. We do not yet have a contractor for the station enterprises. We have already done some of these for the tunnels, but what we are-- the idea behind our model is that they're easy to use in serving equipment and for machine guidance and robotization.

So you can directly get the coordinate-- for example, a point of wall or opening directly from the model without measuring it on the site. In addition to that, the model, if we have split up the model correctly using productions after how the contractor is going to build it, they can use our models directly in their planning-- their logistical planning for how are they going to work.

For example, they can take off take out information from a production unit and order all the rebar and all the embedments that they need per day or how-- for a week in advance. It can be especially viable if you have a low storage space on site and you need to you can only keep as many materials as you need without problems.

In addition to that, it's also possible for the contract to add further information back into the model. For example, on the status on-site, have they ordered these material? Have they built it? Is it finished checking? They finished their own process?

So both us and the building owner can have a live view of their progress on-site, and we know that if we need to make a change, we can see how far along they've come in the process and we can more easily filter out what we can do or can't do of changes late in the project.

So, the pros and cons of model-based project and how we have worked on the metro line. I think the biggest pro is we generally have better quality and less errors in our models. You have the potential to check out the buildability and the collisions in the 3D model, which generally results in less errors on-site. So of course, this does require proper QA protocol or QA process to ensure that these things are checked out.

It can also provide, as we talked about, a lot of benefits for the contractor if their needs are met, but that is a-- generally in the kind of contracts we have where we have a contract between us, the designers, and the building owner and they have a contract later on between the contractor, this might be very hard to do because you generally are finished designing before the contract is even on board.

Or especially you designed some part of the structure that you can't really do any changes to that unless the client themselves pay for it or the contractor themselves pays for it.

But if you have a contract directly with the contractor, then we can, from the start of the project, plan this in and know exactly what they need to build it perfectly on-site. We can plan it after their formwork-- the standardized formwork they use. We can provide the shape codes and the shapes they ideally want to use for the different structures to make it as efficient as possible to build.

Automation can also-- so speed up the design time for a lot of things. But it can also, as I said, complicate things. So we have to find the middle ground for what we can automate and what we can't automate, but this is generally considered a pro if you do it properly.

And we no longer need to both have a model and to separately make drawings. You don't have two different pieces of information that should be equal or combined. You have everything in one place. So it's a lot easier and better, I would say, to have it in the model because you know, if you check that, then everything else is OK.

If you check the length of a rebar, you know that the bending schedules is automatically correct unless there is an error that the measurements for the rebar is not the same as the model-- the model representation of the element, which generally, as far as I have seen, has never happened before.

But there is, as we talked about, some cons as well, especially with finding the resources and having an organization that's able to do all these things properly. So they will probably be some development and training costs that needs to be included for a proper model-based project.

This is still very new, and in Norway, we have had a few of these projects, but we still are missing this proper knowledge across the whole organization for what it means to work model-based.

Errors that are hidden on 2D drawings may now be exposed. As we talked about, you can't do something and round something off. You can't hide something easily on the 2D drawing, so you have to have, again, a proper quality assurance and know what you have modeled properly. If not, things can be very quickly go wrong in the model.

And lastly, everything is more interconnected, especially when we model rebar. If we make a change to the form element, you suddenly have also the geometry element have several rebars that also needs to be changed.

So if this is done correctly, you do you have a lot of automated-- now interconnected between the rebar and the cover and the constraints of the element, but it's still-- late changes may be very costly. So it's very important to have a good plan in the project for when things should be done from other disciplines, where we need the input. Because if you get these things too late, it will probably end up costing more than if we get these changes early on.

So , finally some key takeaways and the lessons learned. The most important thing that we have noticed is that we need you need to know what should be delivered from the start. You need to start in the end and work backwards. So-- yeah, like last planning.

You need a good red line for the maturity of the models so you don't waste time or have-- in the early phases or have to redo things later. So again, this needs to be planned with the project managers. And all disciplines should know this. You need to know what needs to be ready when for the proper interdisciplinary coordination and know each other's needs.

A good example of this is openings, which is generally the main interface we have with the MEP disciplines. If these things are done wrongly, you can end up with a lot of unnecessary work that can be pretty costly.

Model-based design does not necessarily decrease the actual time for the designers, but generally, it does increase the quality if done correctly. You could, of course, do model-based with the focus on decreasing design time, but that would be the same as you would probably see a lot of errors that you wouldn't want to fix because you do see a lot more things in the 3D model that you otherwise wouldn't be able to see in 2D drawings.

So the detail level and the quality are, therefore, normally increased. And I think that's probably a-- if you look at it in the total cost of a project. It's easier for us to find errors or mistakes than for the contractor to find them. If the contractor have spend one month longer and building it, the cost is probably 10 times as much as spending on another month designing it.

So our models-- our deliveries in general include more. So we have 5-- 4 or 5 or 6D BIM with the time and the cost and also the use directly in the planning. And also for the CO2 budgeting and the digital twin part of the project. So we tend to deliver more than we used to do in 2D projects.

So therefore, it's very important to know that things can also become too detailed. So you need to have a clear guidelines for how things should model, how things should look. This goes back to the execution plan. You need to have a very good idea of how things should look until we have this-- yeah, this standard for how model-based projects should be delivered in the end.

There's also a lot of potential errors with software capability. So it's very important that you have good control of this, especially in this project where we have two different firms which have their own IT routines and when updates are pushed, which can cause errors that suddenly we're not compatible with working with each other or that, as you talked about, the exporter is different than them. Suddenly, the model looks different depending on who has exported it.

And again, model-based deliveries work better when a contractor is on board early. And some training is almost certainly needed for this to work properly. But overall, I would say that the pros outweigh the cons long-term, especially if you look in the future with AI and the potential for even more streamlined design and construction process.

And if you have a client that sees this overall picture and are willing to maybe increase the cost for the designers but to see the overall value for a-- yeah, less errors on site in a quicker and better building process, then this is a sure bet, I would say. So personally, I would never go back to making drawings again. That's it from us. So thank you for viewing this presentation.