Description
Principaux enseignements
- Gain a greater understanding of the connection between desktop and cloud solutions at a design level.
- Learn how to apply automation within Dynamo scripts for the modeling of complex design elements in Revit, saving production time.
- Learn how to implement the right CDE, get models coordinated, and enhance design collaboration among different teams.
Intervenant
- MBMarta BetancorMarta Betancor Falcón is a civil engineer with a master's degree in civil engineering, infrastructure, and GIS. With several years of experience as a BIM Manager, she has significantly contributed to high-profile infrastructure projects such as Rail Baltica's new railway line, the Detailed Design of train depots in Spain, and currently, the tunnel electrical and mechanical contract (TEM) for Fehmarn Belt Fixed Link. Her leadership in BIM implementation at the Bizkaia Regional Council has established her as a key figure for clients, ensuring compliance with BIM standards and optimizing workflows using the latest software capabilities, leading to consistently achieving successful project outcomes. Additionally, Marta collaborates with the University of Cantabria (Spain) and is part of the teaching staff in the Master´s Degree BIM in Civil Engineering. This is her first time attending and speaking at Autodesk University.
MARTA BETANCOR: So hi, everyone. Thanks for joining. My name is Marta Betancor. I am a BIM manager at IDOM, and I am currently [INAUDIBLE] responsible for the TEM contract in the Fehmarn Belt Fixed Link project. And I am really excited to share the insights on how we are implementing BIM and using automation in our contract.
So the agenda for today's session is based on seven points. I will be introducing the tunnel for you, and also I will be talking about the TEM contract, the companies involved, and our scope of work. But the key topics will be focused on the BIM strategy, organization, and coordination before finishing with some final thoughts. So for those that don't know what the Fehmarn Belt Fixed Link is, we are going to watch a brief video that highlights the main purpose and significance of the tunnel.
[VIDEO PLAYBACK]
[MUSIC PLAYING]
- Welcome to the Fehmarn Belt. As life in the sea continues as usual, something new has appeared just beneath the seabed-- an 18-kilometer link consisting of the world's longest immersed tunnel between Denmark and Germany-- between Scandinavia and the rest of Europe. The Fehmarn Belt tunnel is the cornerstone of a new green transport route for cars and trains that will connect businesses and people.
The tunnel will provide a sea of new opportunities, opportunities for growth and jobs, opportunities for efficient and climate friendly transport, opportunities to free up time. Time to spend the way you decide and with people you care for. Time for exploring new avenues. Time for reconnecting. Time for reflection.
The time is yours. The choice is yours. The tunnel will be there whenever you need it every day all year round. The Fehmarn Belt tunnel will open in 2029. See you on the other side.
[END PLAYBACK]
So why a fixed link? This tunnel will improve travel connections between the countries of Germany and Denmark. It will reduce travel time 10 minutes by car and seven minutes by train. And the cities of Copenhagen and Hamburg will be connected in only 2 and 1/2 hours compared to [? 5:30 ?] that is nowadays. And this will save a total of 160 kilometers compared to the previous route.
So for the design and construction of the Fehmarn Fixed Link, many European companies have come together to define not only the tunnel itself, but also all the necessary landside works that are required to ensure the connections to the tunnel and also to supply all the necessary resources for its operation. So you can see on screen the different contracts involved. We have one for the tunnel, portals, and ramps which are located in the landside areas, one particular for trenching and reclamation, and several railway contracts.
But today, we will be focusing on the installations, which is the TEM contract. So let's see the companies involved and our scope of works. So the joint venture, SICE-COBRA, was awarded with the design and build of all the mechanical, electrical, and ICA systems. ICA stands for Instrumentation Control and Automation.
These are Spanish-based companies. On one side, we have SICE. SICE specialized in the integration of technologies for public infrastructure, but also covers other areas such as ITS, tunnels, transportation, mobility, smart cities among others. While COBRA is more focused on the development of industrial infrastructure, but also covers other fields such as utilities, gas, electricity, communications, facilities for mechanical and electrical systems, and integrated projects for oil and gas, and power generation.
On the other side, we have IDOM. IDOM is a 67-year-old company. It is also based in Spain. We are present all over the globe with 45 offices. And we have participated in relevant projects around the world in over 125 countries. And the different areas of expertise that we cover are industry, infrastructure, consulting, and architecture, which is the role of IDOM in the contract.
So IDOM is working for FSC. While SICE is focused on the definition of all the ICA systems, IDOM leads the design for all the mechanical and electrical installations. So for us, FSC is our main client, but we also have the final client, which is Fehmarn AS, or what we also known as the owner of the project. So Fehmarn is a public Danish company that is in charge of the planning and achieving a successful result of the different contracts that are involved.
So in terms of our scope of work, we know that we need to define three main disciplines, but these are further divided into several subdisciplines for a better managing of the design. So for example, we have a mechanical, ventilation, walls and flooring, daylight screens, doors, emergency doors, access doors. For the electrical part, we have power supply from low to medium voltage, cable management systems among others. And also for ICA, we have other several disciplines such as data transmission, communication systems, traffic management, and so on.
So these result in a total number of subdisciplines of 15, 7, and 16, of which 14, 7, and 13 are developed using BIM methodology. So in terms of design teams, we have a total of four team members that cover the mechanical systems, 13 the electrical, and also 13 for the ICA. However, these numbers do not cover any management, quality assurance, engineering support, drafting, and BIM teams. So if we add all of this together, more than 100 people are involved in the contract.
So regarding implementing the BIM implementation scope, we cover a level of detail from 300 in basic design up to 400 in detail design. So the elements must be defined from their maximum extent and location to their actual size and placement once it is constructed or installed. Also, these elements must contain all the necessary information depending on the level of detail in each project stage. We need to consider clearances for operation and maintenance purposes to ensure coordination width.
And also we need to produce and deliver 2D drawings. So the information shown in the drawings must also always come from the 3D models. However, there are a few exceptions, such as schemes, diagrams, or if we are representing details for construction and installation. So at the beginning of the year, we completed basic design. And we are currently in the midst of detailed design, where we are defining a level of detail of 325.
So as we can see, the Fehmarn Belt Fixed Link is a big project itself. But also the TEM contract, we need to define several disciplines and subdisciplines. And there are many challenges that we need to face and that we are currently facing. The first is that we need to ensure that the companies involved offer the same high quality standards. So for this, collaboration is key.
We need to be able to define a modeling and production strategy. So based on the softwares that are on the market, we need to be able to select those that not only will help us meet the Fehmarn requirements, but also will provide flexibility to the different systems that we need to define. Communication is going to be a really key aspect in the project.
We need to have a unique and centralized source of information where all of the designers have real-time access to the latest information. We need to be able to manage any kind of changes that may come from other contractors that can affect our assumptions and calculations. And we need to be able to respond swiftly without affecting the integrity of our work. And finally, we need always to stay on top of our deadlines. We need to produce, submit, and provide any kind of additional responses to our clients on time, on schedule.
So the learning objectives of this session are the ones that are shown on screen. And my goal is to provide you with a better understanding on the connections between desktop and cloud solutions. How to apply Dynamo to save production time-- in this case, with Dynamo. Implement the right CDE, get models coordinated, and enhance design collaboration.
So let's talk about the BIM strategy. So throughout the different project stages, we need to comply with several BIM use cases, like the classification and identification of each of our elements, extracting all the necessary data from the models, especially quantities. Ensuring 3D coordination not only between our systems, but also with other contractors. Producing these 2D drawings as I said before. Running simulations, planning simulations, or particular-- for ventilation, lighting, evacuation. Creating visualizations. And by the end of the contract, produce and submit all the as-built documentation.
So in this session, we will be focusing on the design and coordination aspects. So in terms of software, from the beginning, we knew that Autodesk Revit was the best software that meet our modeling needs, and that we were going to use Autodesk Navisworks as our coordination software. So the Revit files were going to be our go-to format for exchanging information between the different designers, while the [? IFC ?] was going to be used for coordination purposes and also for quality assurance.
So selecting the software was a pretty quick task. Our main issue, or question, was how we were going to manage all of this information? Where we are going to store it and exchange it with the different designers without any loss? So which CDE we must select. So what we were looking for in a Common Data Environment-- so firstly, this CDE is going to be our main hub of information. We're going to store it and exchange all the information between the different designers without any loss.
We also need access control. So depending on your role in the project and your company, you will have total limited access to certain information. This CDE must also support cloud-based models and, as a plus, contain a model viewer. So for us, Autodesk Construction Cloud ticked all of the boxes. And with the use of Desktop Connector, we ensure that we can work on our desktops while still connected to the online data. I must say here that for the non-BIM-related documents, we also used SharePoint as our CDE and also to manage the different submissions to our clients. Therefore, we had to download all the BIM information from the ACC and transfer it to the SharePoint for this purpose.
So the BIM organization-- so before we start defining our models, we need to decide how we're going to define our installations in the different areas of the tunnel and landside areas. So this means how we are going to section the models and how many models I need to create per subdiscipline or per package. So in this sense, we based our decision on how the Civil Works models were defined and structured.
So in this sense, the 18-kilometer tunnel is composed of 89 concrete elements. 79 are standard elements. These consist of 9 elements of 24 meter long each, a total of 217 meters. They have only one level, which is the traffic level. And in the models we received, they were usually grouped in segments of 3 to 8. So there were a total of 11 models that cover all of these standard elements.
We have 10 spatial elements. These are pieces of 39 meters long each. They are placed periodically along the tunnel. And they have a second level below the traffic, where we can find technical rooms for installation and also for maintenance access.
At both ends of the tunnel, we have the two portal buildings for the operation of the tunnel. And in terms of land site models, we received over 120 models. However, for the purpose of our design of our scope of works, we only created two models that covered each of the land sites. So we had one landside model for the Danish site and another one for the Germans.
So once the production strategy is set, it's time to define our basis. So firstly, from the Civil Works model we received, we import the IFC format in our Revit file. We always need to make sure that the coordinate system is correct after the importation because in some models, we noticed that they were off. So for this, we usually took or selected a reference point in Autodesk Navisworks that helps us move our model in Revit to its correct position.
And once everything was aligned, we saved this Revit file as a cloud-based model in ACC through Desktop Connector. On the other side, it is important to set our Revit template so each of the designers start with the same standardized information. So we set our title blocks for the 2D drawings, our splash screens for the 3D models. And also we created our shared parameters file with all of the data that was required for that particular project stage. So once everything is set and is shared in ACC, we can start defining our model. So for this, in our Revit project, we link the Civil Works model through Desktop Connector, and we use this as a basis on which we can start building on.
So for the basic design, we followed a focused approach in specific areas of the tunnel and landside areas if it was required, depending on the packaging-- on the package, sorry. So in this sense, a spatial element and a standard element has the same section across the tunnel. So we focused our design, and we started defining and coordinating our designs in one spatial, one standard, and the two portal buildings. This way, we streamline discussions between the different designers. And we reached agreements with the owner, Fehmarn.
And once Fehmarn initially approves the layout, we replicate the design in the different areas of the tunnel. In detail design, however, we still prioritize these areas, but just for internal coordination because we had to ensure that all of the design was covered in the total areas that we cover in our scope of work. So following this approaches in basic design, we delivered 30 packages which resulted a total of 752 models, a combination of 3D models and the 2D drawing production model per package.
And in digital design, we are aiming to submit 46 packages, which resulted out of 862 models-- again, a combination of these 3D and 2D models. So as we can see, there is a lot of information that is being managed and needs to be produced. And creating efficient workflows is really a key aspect in our contract. So now, we have seen how we define our production strategy, how we set the basis for our modeling.
And now it's time to see how we transfer the designers, ideas, and layouts into a 3D model. So we are going to have a look at two examples. The first is the firefighting system suppression. So for this, we usually extract plant use and sections directly from the Civil Works models that the designers use as a basis to define the different layouts and elements positioning.
So a really key aspect here is also to define the families in Revit, the elements that we need to represent. So for this is-- if the standardized families in Revit do not fit the designers' needs, then we require technical data sheets that we can use as a basis to define our elements. So of course, the families in Revit will contain all the necessary data in terms of sizes and dimensions.
And we usually go for parametric families to ensure that we can-- to ease any kind of minor adjustments in the future. So once everything is set, we can start defining our models. So as I said before, we link the Civil Works models as a basis. But we can also link any kind of package that we know can affect our designs.
So thanks to the use of-- sorry, of course, before that, we are not going to link all of the models that we are developing in our scope of work. So for this, usually, the manager or the BIM coordinator helps the modeler to focus on specific coordination issues. So thanks to the use of ACC and cloud-based models through Desktop Connector, we ensure that we are always linking the latest information from other designers. So this way, the designers can detect any kind of missed coordination at early stages on the modeling and can reach agreements with other designers.
Also I would like to say that our BIM team is multidisciplinary. So this means that each of our members work in their own views and sections. We do not want any members of our team to be focused on a specific system or package. This way, we guarantee that our productions and submissions work smoothly without being disrupted by the availability of a particular member.
So again, once the models are approved and are validated by the designers, they are shared in ACC. They are published through Desktop Connector in the web folder in ACC. And once everything is updated, they are then transferred into the shared folder, where we prepare a transmittal to the different members of the design and BIM teams. And we also define the main changes that we have done in the model since the last version that we shared. I think we are looking now at the final steps of how we created and submitted.
So I think we can skip to the next example, which is access systems, doors and hatches. So in this package, the position of a door is provided by the openings that are left in the Civil Works models while the door type is provided directly from Fehmarn-- from the owner. So it is up to the designer to define the characteristics of the fire-resistant material and the opening mechanisms of the door.
So when we are defining our door family in Revit, we consider that one single door type have multiple opening options. So these options are represented by this red solid with certain transparency, which we call clearances. We will show it later. And we proceeded this way because once the door is positioned, we can easily select the clearance that has that particular door in that particular placement.
So something to take into account is that in order to place a door in Revit, previously, we had to have a wall in the model. So a challenge here is that walls and doors are handled in different packages in our project. So we usually need to work with these packages at the same time to ensure that they are coordinated.
So both of these models are a replica from each other. However, in the access systems, we need to hide the doors and not export it and vice versa in the work package. So we do it like this because, in the drawings, we are showing mixed information. So the walls that we show comes from the work package and the doors from the access system package. And if this is not done correctly, then we will show mismatching information or the wrong information. [INAUDIBLE].
So once everything is validated by the designer, they are again shared-- they are published in the web folder. And then they are shared in the shared folder where we prepare the final transmittal for the rest of the designer, design teams and the BIM members. And always we define the main changes from the previous version of this models.
So in terms of clearances, clearances regarding operation installations and maintenance are a mandatory request to ensure a soft clash evaluation. So in order to ease this process, we decided that the best approach was to include these clearances as part of the family in Revit. So these clearances are always represented in these red solids with certain transparency throughout the different packages of our scope of work.
And as we can see on screen, we have several examples. For example, for the opening and closing of a cabinet, for the valves, and for medium distribution switch gears, among others. As we can see, these are represented with different sizes and shapes. And unfortunately, if we only had to review soft clashes using Autodesk Navisworks options, we will not reach such level of detail, and we will not get the results that we are achieving with this approach.
So let's talk about automation. So given the fast-paced nature of our project, where several packages and subdisciplines are being developed at the same time or progressing at the same time, we need to be mindful of our limited work hours. So to address the need of efficiency, we applied automation using Dynamo. So a key aspect was to identify the main tasks that ate up most our time, including reference points in all of our models.
This was something to be done as a mandatory request by Fehmarn to ensure that everything is positioned in the correct coordinate system-- something to be done in our contract and in others just to ensure coordination in the overall project. Adding or modifying any kind of information in the models, in the parameters, defining changes for particular elements that are positioned along the tunnel, along the alignment, positioning these elements in certain areas of the tunnel and portal buildings, and also transferring views and sheets from one drawing production to another.
So in this sense, in basic design, we had several packages that were prepared and submitted individually. But now in basic-- in detailed design-- sorry-- they are part of the same submission. And therefore, all the works that were done previously in terms of drawings needed to be gathered together into one new 2D drawing production. So for this, we used Dynamo.
So now, we are going to see two examples of how we have positioned elements along the tunnel. So the first case, the placement and location of the aesthetic lighting-- that is the case-- are provided directly by Fehmarn through a 2D drawing. As we can see, there are many. They are placed in particular areas of the tunnel in the cladding.
And we also received from our designers an Excel file with particular tables for each area where these lightings must be placed with certain details, like the ID of the light, the chainage, and the elevation from the road pavement. So in Dynamo, it is important to select our main inputs that we are going to use. These were the 3D alignment that was provided by the Civil Works contractor in Civil 3D, also the Excel file that we received from the designers, and a link to the Civil Works model.
So before using this alignment, we need to convert or transform the coordinates from Civil 3D to Revit. As we know, these softwares do not work with the same coordinate system. So once everything is converted, we then replicate the geometry of the alignment in Revit. At the same time, from the Civil Works model, we extract the main elements that we are going to use as a basis. For this, we use filters with information that was already included in the Civil Works model. So these elements were the road pavement, [INAUDIBLE] and the cladding.
So to define the insertion point of the aesthetic lighting, we use the alignment as a basis. And we used referen-- sorry, we traced reference lines based on the chainage and elevation. So horizontal line for the chainage, and vertical lines as we are seeing for the elevation. So once we define the insertion point, we simply insert then the particular family of the aesthetic lighting. And we also included several control parameters to make sure that all of the lights that were supposed to be modeled are included after the script has run.
So another key aspect here is to ensure coordination with other designs, with other packages. So for this, we linked all the necessary packages that we thought could affect the positioning of these lights. For example, the directional signs, the cabinets, and also emergency doors. In this package, if we encountered any hard clashes, we did not delete these aesthetic lighting. We simply recategorized them in a new family in Revit-- for example, with the same family name, but with a suffix of deleted-- because we had to show also these deleted elements in our drawings so the owner, Fehmarn, knew why we were not going to consider them as part of our designs.
We also did a little bit of manual work just in those cases where the Dynamo did not work correctly. And as always, once the models are validated, they are shared in ACC through Desktop Connector following the same approach as the previous examples. So another example is the emergency signs and lightings. Emergency signs had to be placed at both sides of the compartment and gallery. A compartment gallery is a small room that connects the road tubes through the emergency doors but does not allow access to the gallery.
So in this sense, we follow three key steps. So the first is identify our elements that we're going to use as a basis. These were elements that were already defined in our scope of work-- for example, the directional signs and also the compartment [INAUDIBLE] door. We replicate their geometry, and we define the insertion point.
And as always, after the script is run, we always double-check that everything is placed correctly and we do not have any major clashes with the rest of the design of the packages. So the next example is the emergency lightings. These are lights that are placed above all emergency doors in both the road and rail tubes.
And as before, we follow the three main key steps in Dynamo. We identify the elements that we are going to use as a basis for our design. We are going to extract their geometries. And then we are going to define the insertion point and place the correct family in this insertion point.
And as always, as I keep saying, we need to ensure coordination between the different packages. So for this, we link not only the structure model from the Civil Works model, but also any kind of packages that can affect. And we double-check that everything first is well positioned and then that we do not have any major clashes with others. And once everything is validated, it's shared in ACC following the same approach as in previous videos.
So applying automation in our design processes has allowed us-- for example, in the lighting package-- to position almost 19,000 elements in basic design. So a work that will typically take us 10 days of manual work only took three days. So three days to define the Dynamo script, to test it, to run it, and also for to do minor adjustments in the model. For example, in those places where the Dynamo did not work, or maybe for coordination and so on. This cut our production time in almost 70%. So this really shows how the critical role that this tool, Dynamo, has had in meeting our project demands.
So now, let's have a look at the coordination-- how we are applying coordination or proceeding with coordination in our contract and also with others. So to give you an overview, the main contracts we exchange information with are the tunnels, portals, and ramps which are developed by the same contractor, and TPS, which is the Tunnel Power Supply. These mainly define the substations in the landside areas.
So these exchanges are managed through different interfaces where each contractor shares information or specific design details that can affect others' calculations, assumptions, also 2D drawings, 3D models, among others. So we basically rely on the [? IFC ?] format as our unique source of information for the 3D design. And as I explained earlier, we convert this [? IFC ?] into a Revit file for our modeling and coordination process in Revit.
And of course, if we receive this Revit file as the [INAUDIBLE] format of another contractor, we will use this directly, but always making sure that both the Revit and the [? IFC ?] file contain the same information. They are consistent because the [? IFC ?] will be used for the coordination in Navisworks. All of this information is shared and available in ACC for the different designers and BIM team.
And also we share in the CD our coordination models in Revit and also our aggregate models in Navisworks, where we perform the clash detection. Also we need to consider that each contractor has their own design processes, submission schedules, potential delays, and also modifications and agreements with the owner. So we have encountered situations where the BIM that we have from another contractor is no longer the latest information, and instead we have received the 2D drawings with the latest updates.
There are other areas also that we require information from, but they are being developed in a different project stage, so in a different level of detail as we require, or areas that their design have not even started. So as a result, if we do not have the 3D information, but we have the 2D, we will base our design in these 2D drawings. And then once we receive these 3D models, we simply adjust our designs accordingly. And if we do not have 3D models, we simply define our or our systems in the traditional way using CAD in 2D, which is not the best way to proceed. But sometimes we had to do so to not interrupt our design process.
So as I said before, the clash detection process is performed in Navisworks. However, we have defined several coordination models in Revit in different areas of the tunnel and the portal buildings. These models are cloud-based models as well as all of the links. So this way, we ensure that we are always looking to the latest information from the different designers.
And of course, they are available for all of the designers and BIM teams. As we can see, there are different graphic views and visibility options, just depending on how you want the information to be displayed. If you want to review our installations with the clearances or if you want to gray the colors of the tunnels for a better view of our systems, or simply if you want to focus on specific areas of the tunnel, such as the tunnel gallery.
So now, let's go in to see how we perform clash detection in Navisworks. But before that, I would like to say a few things that we need to consider. So firstly, we have a specific requirement from Fehmarn that states that no file size should exceed 150 megabytes. However, if we consider all of the models that we need to produce and that we need to add into our models, plus all of the models that we are receiving from other contractors that we need to ensure coordination with, it is difficult to stick to this limit.
So we agreed with the owner to increase this up to 300 megabytes. Also all of our clashes should be classified according to the level of severity. So we have three different levels. We have low. These are clashes that can be easily solved by the relocating or eliminating a particular element, or they can be easily solved on site.
Then we have moderate clashes. These are interferences that affect functionality. So they can also be solved by eliminating or relocating an element, but affects others from the same system or elsewhere. And critical clashes are those that have a significant impact in the design and also have financial implications.
So clashes are defined by tolerances. We can see on screen a table which shows the tolerances that have been applied in basic design, and the ones that we are currently using in detail design. So the aim is that these tolerances get tighter as we go through the different project stages. However, from issue for construction onwards, these are values that are yet to be discussed and agreed with the owner.
So last but not least, we have the clash detection matrix. This matrix helps us define the different sets that we need to evaluate in our crash detection process. And as the design is progressing, also the crash detection is updated. So we will see later on why.
So to ensure that we comply with the file limit, we proceeded with the sectioning of the aggregate models. So for this, as before, we follow the same approach based on the-- well, we follow the-- I will start again. We followed the same composition and structure of the tunnel. So in this sense, in basic design, we split the tunnel by half.
The middle section was a common piece for both aggregate models. This way, we ensure that all of the models are-- all of the areas are covered. And at first, initially, we thought that we were going to comply with the file size limit. However, as the design progressed, and more and more models were included in these aggregate models, we soon realized that we exceeded this file size limit.
I think the maximum we reached was 318 megabytes. However, this was not a big issue to the owner. But taking this into account, and also the fact that, in detail design, we were going to increase the level of detail in our models, we decided to split even further our aggregate models. And we developed a total of four different aggregate models that covered all of the tunnel. So again, these aggregate models have a common piece to ensure that all of the areas are covered.
For the landside areas, we follow the same approach in both basic and detailed design. So we have only developed one aggregate model that covers both sides of the landside areas. So for the clash detection matrix, we can see how it started-- very generic descriptions of the main disciplines and subdisciplines that are involved with the elements from the Civil Works contractor we needed to ensure coordination with.
However, as I said before, as the design is progressing, we also included further details in our matrix. So it was necessary to include further divisions into our subdisciplines, and also included a set number just to ease the identification of each set within the matrix and also in our reports. And as I said before, as the design is progressing, also the clash detection is being updated as we have a more clear picture of what the final result of the final design will look like. And so potential clashes that were considered are no longer like so. So we are always defining these sets again and redefining these sets, and so the clash detection matrix is evolving.
So now, in the software, we usually work with search sets. So these sets help us to define or select specific elements of the models or packages [INAUDIBLE] For our clash evaluation. And in each of our aggregate model, we have preset coordination views that allow us to navigate through the different areas of the tunnel and portal areas to help us define or detect any kind of clashes that may not be detected due to the tolerances that are being applied in that particular project stage.
So if we encountered any clashes, we simply save them as a saved viewpoint. We give a brief description of the clash, and then we classify them in different folders. These folders are named after the packages that are affected by the clash.
So this is the final result of the crash detection process itself. So we can see the list of part of the sets that we have-- that we need to review, sorry. And then we can see the final results. As I said before, all of the clashes need to be classified according to the level of severity. But also when we are reviewing the clash, we always look for further descriptions that can help us further divide or further classify these clashes-- for example, if these clashes are in a particular area of the channel, or a particular area of the project, or if they involve a specific elements, as we are seeing.
Each of the clashes individually, or in their groups, need to have a comment. This comment usually refers to the design team that must take action. And also we can define any kind of justification of why a particular number of clashes can be validated, and so approved from our side and not be considered as clashes.
So coordination efforts are also undertaken even though we do not have 3D information. So in this case, for the tunnel railway contract, we do not have a direct interface with. However, based on the information we received at early stages of our contract through Fehmarn, we noticed that in particular areas of the tunnel-- of the spatial elements-- sorry-- and the portal buildings, we noticed that there were areas that were reserved for this contract.
So proactively, we decided to transfer this information from the 2D into our 3D models to ensure coordination with and avoid any kind of further implications in the future. So this process is not easy and it still isn't-- has not been easy and it still isn't. For example, the first case is that we need to update each aggregate model individually.
So in this sense, if I need to update a search set or clash set, we cannot update it automatically in all of our aggregate models. We need to do it individually. Also due to the sheer volume of information that is always being reviewed when the clash detection is running, we have encountered situations where a group of clashes have been removed from the original group even though the update of the model has not been affected by these packages that are involved in the clash set.
So in this sense, if we are talking about 10 clashes, it is still a consuming task, but it's still manageable. But if we are talking about more than 100 clashes, this becomes a problem because now, we need to spend time again repeating work that was done previously before. And now, we need to review each individual clash again and regroup it. Also, personally, I would like to say that, for me, the clash detection options in Navisworks lack of significant improvements in the last year.
So I think that including features such as classification rules and automatic grouping really will help these kind of projects where we are managing lots of information, lots of clashes, and also will reduce manual work and improve efficiency overall. So we are coming to an end. I would like to share some final thoughts that I would like you to retain from this session. The first is that the use of cloud-based models in ACC through Desktop Connector really ensures seamless exchange between the different design teams and also enhances design collaboration, as all of the design members and BIM teams have real-time access to the latest information or the latest design from each other's teams. And also it really enhances coordination at early stages of the modeling.
The use of automation tools, such as Dynamo, have enhanced efficiency in repetitive tasks. So saving your production time by 70% really shows the critical role that these advanced tools have in meeting fast-paced project demands. 3D modeling [INAUDIBLE] have improved coordination and communication not only between different designers of our contract, but also with other contractors and Fehmarn as they have a better understanding or a clearer view of what the main issues are in design and the different design solutions that have been done.
In general, Fehmarn has key objectives for the Fehmarn Belt Fixed Link project, such as the data management, the collaboration between the different stakeholders, and also the use of advanced tools to enhance the quality and the consistency of the models, as well as ensuring a successful handover once the contract is finished. So in this, FSC is having a critical role in achieving.
So thank you very much for your attention. I leave my contacts here just in case you have any questions you would like to discuss about. So thank you very much and take care. Bye.
Downloads
Étiquettes
Produit | |
Secteurs d'activité | |
Thèmes |