[TR22075] BIM Execution, Custom Attribution, and a Private Cloud: The Bergen Light Rail Project

Size: px
Start display at page:

Download "[TR22075] BIM Execution, Custom Attribution, and a Private Cloud: The Bergen Light Rail Project"

Transcription

1 [TR22075] BIM Execution, Custom Attribution, and a Private Cloud: The Bergen Light Rail Project Martin Amdal ICT/BIM Manager Sweco Martin.Amdal@sweco.no Terje Glad VDC Specialist Sweco Terje.Glad@sweco.no Learning objectives Discover what is included in an ICT and BIM execution plan made for a complex transportation project Learn how to plan and control information development and level of detail Learn how to automate the creation of the federated 3D model, and how to add custom attributes to objects See how Autodesk has helped out the project team with their expertise, and how Sweco and Autodesk are developing a custom cloud solution Description Bergen Light Rail Project strategy for Building Information Modeling (BIM) was shaped by strict demands: 300-plus professional stakeholders, lots of tunnels, heavy storm events, traffic, and tracks running down the middle of Norway s second-largest city. The unique execution plan created for this project was customized from a mix of private and government guides. The resulting plan included model specifications, level of development (LOD) progressions, quality assurance criteria, and collaboration policies. The project capitalized on iconstruct, FME, and A360 cloud-based collaboration service to automatically create and compose the federated/collaboration model. A powerful set of custom information was added to objects at this collaboration stage to further facilitate the mapped processes. Autodesk Consulting and Premium Support assisted to optimize and customize workflows. And Autodesk Consulting is currently working on a joint Autodesk, Inc./Sweco cloud solution, so the entire project team will have an updated model available every day as this project moves toward completion Page 1

2 Your AU Experts Martin Amdal is currently senior engineer and BIM specialist at Sweco, Norway. Martin began his career as a construction engineer before becoming CAD manager at Sweco. This proved the perfect background for moving into BIM commissioning, coordination, and management. He is now functioning as ICT/BIM lead in the Bergen Light Rail project where he has incorporated smart ICT (information and communication technology) into the projects execution plan. Martin has extensive experience in both BIM for building and infrastructure projects. He serves on the buildingsmart Norway national consultant board. Living amongst mountains and fjords in the western part of Norway, Martin enjoys spending time outdoors all year round. Terje Glad is a specialist on the BIM Infra Expert Team in Sweco, Norway. He serves as a Building Information Modeling / virtual design and construction (BIM/VDC) strategist, manager, and coordinator, and is responsible for the implementation of new technology and processes on his team. He has worked for many years developing and enhancing the BIM experience for users across many disciplines. Before joining Sweco, Glad worked for Focus Software, where he implemented Autodesk and other BIM solutions at the enterprise level. He was trained as a civil engineer and land surveyor, and gained essential construction experience working on construction sites during and after his education. Being raised at the very far reaches of Norway, Glad is an expert skier, and now living in Oslo, in the sunnier months he enjoys sailing the Sweco race boat long into the evenings after work. Page 2

3 Introduction Combining project management and technology should be the winning recipe for most projects. Nevertheless, it is rare in the AEC industry. Why? Probably because, in our industry, technology is introduced in the projects from the bottom and upwards, while project and design management is the other way around. At some point management collide with technology, or worse, they pay no attention to each other and keep on doing their thing. One things for sure, as BIM Manager you re going to regret promising that BIM would be a more efficient way. In the Bergen Light Rail (BLR) project that is changing. With key tech personell in the management and ICT/BIM as a crucial part of the project execution plan, we are introducing new methods and the technology to make it work. In close collaboration with Autodesk, we are developing a new cloud based BIM solution for managing design tasks and issues. We automate assembly of multi-disciplinary 3D models, do checking and write information to the models before publishing into the cloud. FIGURE 1 - THE BERGEN LIGHT RAIL (PICTURE BY HAAKON RASMUSSEN) The Bergen Light Rail In 2000, the decision was made to build a light rail transit line in Norways second largest city, Bergen. The transit system was called Bybanen or the Bergen Light Rail. Topographically, Bergen is ideal for a light rail public transit. Because of the mountains, the population is concentrated in valleys, which are under 2 kilometers wide and radiate from the city centre. A light rail transit line has lots of capacity along the busiest corridor in the region and provides a great alternative to private cars. It also stimulates development within the served corridor, which is proven by the high demand for housing and commercial buildings alongside the line. Page 3

4 FIGURE 2 BERGEN CITY AND THE BERGEN VALLEY SEEN FROM NORTH-WEST (IMAGERY FROM GOOGLE EARTH) So far the project has developed through three stages. These stages took the light rail from Bergen city center to the local airport, Flesland. As a new airport terminal is currently under construction and the last station is inside the new terminal, the complete line will be opened as soon as construction at the airport is finished spring 2017, even though the tracks are already in place. FIGURE 3 FINAL STOP AT THE NEW AIRPORT TERMINAL (IMAGE (C) NORDIC - OFFICE OF ARCHITECTURE) Page 4

5 Construction of the first three stages was started in 2008 and consists of 20 km double tracks, 27 stops, lots of tunnels and bridges and a depot/workshop for all the trams (area covers sq.m.). The first two stages was designed by norwegian consultants, Norconsult and Multiconsult and the third stage was designed by MottMcDonald Ireland. FIGURE 4 - THE FOUR STAGES OF BLR (1,2,3 IN BLUE, 4 IN ORANGE) For stage 4 Sweco was hired as consultants. Stage 4 also starts in the City Center, but takes another path nearer the mountainside and into the mountain where we have an underground station servicing Norway s second largest hospital and the largest employer in the region. From there it passes Bergen College and a large area that is going to transition from industry to commercial and housing. Then through the Løvstakken mountain in a 3 km tunnel and out in a new valley and alongside a large mall before going through another shorter tunnel to the final destination and depot for the trains in Fyllingsdalen. Stage 4 has a total of 10 km of double tracks, about half of that in tunnels, with 7 stops (one of them 30 m underground). Construction is planned to start in 2018 and finish in Our client is Hordaland County represented by Bergen Light Rail Development (BLRD). An organization of 40 employees with the single purpose of building light rail in Bergen. Page 5

6 What is included in an ICT and BIM execution plan made for a complex transportation project? The ICT/BIM Execution Plan is an integral part of the Project Execution Plan that was created by the project manager, design managers and the ICT/BIM team. The ICT/BIM Execution Plan (BEP) consists of eight parts that together describes a total BIM solution for the project. 1. BIM Strategy 2. Organization 3. Processes and workflows 4. Structuring models 5. Information exchanges 6. Collaboration and communication 7. Quality Assurance 8. ICT Systems FIGURE 5 THE ICT/BIM EXECUTION PLAN In the following sections we ll walk you through what s included in the different parts of the BEP. Page 6

7 BIM Strategy The BIM strategy was formed with Penn State BIM Project Execution Planning Guide 1 (BPEPG) as underlay. The BPEPG gives a great outline on how to make a BIM Execution Plan. It encourages you to find your goals and uses for BIM before designing the execution process and developing information exchanges. The BLR BIM strategy was created by the ICT team and design managers together with our client to ensure we set the right goals and that we meet our client expectations. Goals The goals we set was: M1 Ensure quality in designed solutions M2 Secure efficient communication throughout the project M3 Designing constructible solutions M4 Increase safety M5 Reduce total costs Uses We have described how to utilize different BIM Uses to accomplish each goal. Organization When describing the organization we re not talking about the BIM organization, but the project organization needed to produce, amongst others deliveries, the 3D models and to manage all processes. As the Project Execution Plan was created at the same time as the ICT/BIM Execution Plan, planning the design and BIM processes was done in parallel. The project is organized to utilize the design and BIM processes, the workflows, the technology and to focus on collaboration. The project is too large to solve in one piece so it was split up into eight geographical areas, each with a designated design team. The design teams are put together with the competence needed to solve special challenges that they will face in their areas. They are also organized to manage the design and BIM processes. BIM is one out of eight main disciplines (and 35 sub-disciplines). The teams get their personnel from the disciplines groups, and all teams have a BIM Coordinator that, together with the design manager, implements the BEP into daily design operations, see figure beneath. 1 Computer Integrated Construction Research Program. (2011). BIM Project Execution Planning Guide Version 2.1. May, The Pennsylvania State University, University Park, PA, USA. Page 7

8 Team Sentrum Team Møllendal Team Haukeland Team Minde Team Kronstad Team Løvstakken Team Oasen Team Spelhaugen Main Discipline Groups FIGURE 6 - TEAM ORGANIZATION Processes and workflows The BLR project is evolving through a total of 13 phases, each with a specified design delivery. The phases goes through the same principal workflow as described in the figure beneath where planning, production and QA is happening inside the design teams. NO Start Planning Production Quality Assuring Client Approval DM 204 DM 304 DM 304 Client Appr.? YES End BLR Plan Deliverables Decision FIGURE 7 - PRINCIPAL WORKFLOW FOR ALL PHASES The processes has sub-processes and process descriptions. As the specified delivery differs from phase to phase so does the sub-processes and process descriptions. Page 8

9 Structuring models To keep track of the different models, we have divided them into different model areas and types. Project and model areas The project is divided into 3 main project areas and 8 sub-areas. The project areas are used both for project management and to optimize model performance. Within the different areas we create separate model areas based on the construction contracts and construction objects. The areas of the project are illustrated on the map below: FIGURE 8 - MAP OVER BLR STAGE 4 SPLIT INTO SUB-AREAS Base Models (existing conditions) In the base models we include 2D and/or 3D geometry representation of existing situation with connected metadata/information. Ex: Laserscanned existing terrain surface, existing pipe network with connection to the gov. pipeline database Page 9

10 The base models consists of either official/unofficial geodata or by data collected by the project survey team. Each discipline maintain their own base model, and the BIM / survey team coordinates and maintains the interdisciplinary base models. The disciplinary and interdisciplinary base models are stored in DWG, Civil 3D DWG, Land XML, Revit, ReCAP and IFC formats. All base models for each project area is assembled into base model NWD s. FIGURE 9 BASE MODEL Dicipline Models 2D and/or 3D geometry representation of planned and designed situation with connected metadata/information. The content inside the discipline models is divided into following categories: Planned/Designed objects (to be updated to as-built) Objects for information (text, analysis results eg.) 2D geometry for interdisciplinary drawing production FIGURE 10 - DISCIPLINE MODEL (ARCH.) Page 10

11 Interdisciplinary (federated) Models We have one Interdisciplinary Model for each project area. The different interdiciplinary models have seamless interfaces with each other and can easily be assembled into a interdiciplinary model for the entire project The following diagram shows the structure of the models, and how the Interdiciplinary Models are assembled. FIGURE 11 - MODEL TREE - INTERDISCIPLINARY MODEL The image bellow is a section from the interdisciplinary model for the DS2 Area FIGURE 12 - INTERDISCIPLINARY MODEL Page 11

12 FIGURE 13 - DATA FLOW CHART Information exchanges This part of the BEP describe how information is stored and how we move it through the different systems and application setup in the projects. System/Software ProjectWise BIM Production / Modeling Author Software BIM Coordination Software Sweco BIM Server Sweco JIRA Sweco Issue Tracking Project WEB Description ProjectWise is the main document and data storage system. It is setup with a custom project specific environment, taking care of file name conventions, workflows, permissions, QA and document metadata The Model Author software is connected to ProjectWise trough Application Integration Modules. We have also setup a direct data exchange f.ex between Revit and Civil 3D using NWC-files We are using Navisworks and Infraworks as our main 3D and BIM coordination tools The Sweco BIM server or also called The BIM Machine is used for automated tasks. It also work as a control panel / management tool for Sweco Issue Tracking In Sweco, we have setup our own JIRA environment. We use this for Issue and Task management Sweco Issue Tracking is our custom developed model Viewer and Issue/Task handling software, used by end-user to communicate trough models The Project Web Page is the main information source for the project members. We also use this to digitalize the QA-process Page 12

13 WebForum WebForum is the Project Web Hotel. Used for exchanging documents between the different parts in the project. We have also setup a direct exchange of documents between ProjectWise and WebForum Collaboration and communication Good communication is a prerequisite for the success of model-based design. Communication will take place on many levels, between different members, teams, companies and across offices. The best communication is face to face, but as offices in three countries are involved electronic communication is essential. Information availability is therefore highly prioritized by management. A key to getting information out to the 200+ project members is our project web site. FIGURE 14 - SCREENSHOT FROM PROJECT WEB SITE In the website project members will find all information necessary to work in the project from the execution plan, to step-by-step instructions on how to use Projectwise, to document templates or how to do model based quality assurance. We even have our own e-learning that all members have to go through and pass an exam to be allowed into the project. All files in the project are stored in ProjectWise, a file/document management system which securely handles all files in the project across offices and platforms. Page 13

14 In this part of the ICT/BIM execution plan you will also find information regarding facilitating collaboration through workshops, meetings and ICE sessions. Quality Assurance Quality Assurance is a high-focus area in this project. To simplify the QA-process and to allow the models to contain information about Quality and from the QA-process, we have setup a web-system to handle the entire QA Workflow. The QA system contains the following components: System/Software ProjectWise ProjectWeb Sweco BIM Server Description Used for Model Storage with related QA Workflow State Web forms for the different QA Review steps. Also includes a notification system that f.ex will notify a Discipline Lead when a Discipline Model is marked as ready for Peer Review The BIM Server is the system that is connecting everything together. By using automated tasks in iconstruct BIM flow, we are able to write QAinformation back to the objects in the different Discipline and Interdisciplinary Models Quality Assurance Flowchart FIGURE 15 - QA FLOW Example: Typical workflow for Discipline Lead (peer review) Discipline Lead (DL) receives notification from the project web, containing link to the model DL will open the link to view the model, and the web form for peer reviews Page 14

15 DL will follow the instruction in the web form and check out the different control boxes The Project Web will send a notification to either the Model Author or to the BIM Coordinator depending on the result of the review The document in ProjectWise will change it s QA-workflow state and the BIM server will write QA-information to objects in the model Page 15

16 Structure Power W/S LArch QA and SR Information development Tracks and signal Roads LArch W/S Structure Power Quality Assurance and Step Review Tracks and signal Roads Water & Sewage Landscape Architecture Quality Assurance and Phase Review Structure Power T/S Roads How to plan and control information development and level of detail (LOD) The contract specifies the delivery for each phase. Deliverables are reports and assessments, drawings, descriptions, budgets, schedules and so on, and the main design deliverables are 3D models. Each discipline is responsible for their own models and, at the end of the phase, they have to deliver those models at a LOD specified in the contract. But how would you measure information progress through the phase? Another question is how to handle dependencies between disciplines? At what time do a discipline need to hand over underlay to another discipline to prevent delays? Steps As each phase is from 3 to 12 months, we needed a way of to specify the information development through the phase. So, we introduced steps. The diagram beneath illustrates how the information development for each discipline could be. Decision Gate last phase Step 1 Step 2 Decision Gate X.1 Decision Gate X.2 Time Step N Decision Gate Phase FIGURE 16 - INFORMATION DEVELOPMENT THROUGH STEPS At the end of each step we have a milestone with a specified delivery for each discipline which is presented in step reviews where project progress is presented with the client present. It could be presented as models, reports or sketches depending on how far in the design process we are. The discipline responsible for the delivery at the milestone is involved in setting a practical LOD for the 3D discipline model. Page 16

17 The different disciplines has to deliver underlay for other disciplines. For example, Tracks need to do their design first so roads has the right heights and then construction can place their portals, bridges and such, and then landscape can fill in the blanks. As you can see in the figure above Tracks are laying down most of their efforts in step 1 so the other disciplines know where the tracks are before doing their design. Landscape often get the fill in the blanks -role and do most of their work in the final step. This should work in theory, but how could we manage in real-life design? How do we specify the different levels of development for the different disciplines and how do we uncover all the dependencies? Sprints To manage the actual design done in the teams we are doing sprints. Sprints should be familiar to all that know Scrum, which is an agile software design method. A sprint is a 2-4 week cycle and each step is from 4-8 weeks. So one step could contain 2-4 sprints. The sprints are handled inside each design team. FIGURE 17 - SPRINTS WITHIN A STEP Every sprint starts with a planning meeting in which we prioritize tasks and issues from the backlog. A task could be designing a tunnel portal to reach LOD 3, designing a solution for a cycle path through an area or accomplishing something that brings you nearer the step or phase delivery. So far we have seen that a task should not be less Page 17

18 work than half a day and no more than three days. If a task is more time consuming it should be broken down into several tasks. Issues are design review issues from the models. Issue Issue Issue Issue Task Issue Task Issue Issue Planning Issue Issue Task Task Task Task Task Task Task Area backlog Sprint X.N Sprint Scope Design Review BIM Coordinator Design Discipline lead Corrections/ Design Discipline lead Deliverables Inital Planning Team lead Sprint Review Team lead Start FIGURE 18 - THE SPRINT CYCLE The backlog is created through the step and design reviews and is contained within our Project management tool, JIRA. For the design reviews we have in collaboration with Autodesk made an issue tracker based on Autodesk latest model Viewer (formerly known as Large Model Viewer, LMV). We can, using this technology, do model reviews to find issues which are stored in the JIRA database with assignees, due dates and lots of other information. Off course, not all tasks are issues, and not all tasks can be described in the model, so the managers create tasks in JIRA and assign them to sprints, teams and team members. The creation of this cloud solution is described in a later chapter. Page 18

19 09:00 Week Prosjektering-Sprint 15-min stand-up Initial Planning min stand-up Design Design Design Design Design Design Review 16:00 Week 2 09: Prosjektering-Sprint 15-min stand-up 15-min stand-up 15-min stand-up Design Design Design Design Sprint Review 16:00 FIGURE 19 - SPRINT SCHEDULE In the initial planning meetings the sprint goals are set and the tasks for reaching these goals are defined. In addition, the different disciplines describe their need for underlay from the other disciplines in the form of tasks. All tasks are put into the backlog, prioritized and scheduled according to dependencies. In the morning stand-ups the team gathers to see what kind of work needs to be finished that day and to identify and remove bottlenecks or obstacles. Page 19

20 FIGURE 20 - PICTURE FROM PLANNING MEETING (INTERCITY) The sprint closes after a final review where the product is presented. It should be a day off after the sprint review to do any corrections. Page 20

21 How to automate the creation of the federated 3D model, and how to add custom attributes to objects Automation In order to make the above described workflows and processes to work, we are in need of a daily updated interdisciplinary collaboration model for the whole projects. To enable this within our budget and available resources, we have been obliged to automate the process of assembling the collaboration model. During the automated process, we are also writing custom attributes and information from different data-sources, into objects in the model Sweco BIM Server / The BIM Machine To run all of our automated tasks, we have set-up a HPZ620 PC in Sweco data park located in Oslo. Specs Nvidia Quadro K6000 GPU 120 GB RAM 4 x 1 TB SSD Software Autodesk Navisworks Manage PDC iconstruct for Navisworks PDC iconstruct BIM-flow Server Microsoft My SQL server Autodesk AutoCAD Civil 3D Autodesk - AutoCAD Script Pro Autodesk - AutoCAD Batch Server Safe Software FME Page 21

22 Automated tasks The diagram beneath shows the timeline with the task that the runs on Sweco BIM Server every night. FIGURE 21 - AUTOMATED TASKS Page 22

23 See how Autodesk has helped out the project team with their expertise, and how Sweco and Autodesk are developing a custom cloud solution In the early stages of the project we recognized the need for a cloud based model viewer with the ability to not only do comments and markups, but also to assign the solving of issues to project members. After contacting both Autodesk and other suppliers we could not find a product on the market that would allow us to do this. As Sweco has an enterprise business agreement (EBA) with Autodesk we explored the possibility of having Autodesk to make such a solution based on existing products like A360 team, BIM 360 Glue or BIM 360 Field with a connection to Navisworks. A project manager from Autodesk was appointed to us to help us find or develop the solution we needed. We had meetings with different expert environments within Autodesk where we explained our requirements and we got help from Autodesk consultants to establish all requirements needed from the solution. In the EBA there is substantial resources set aside to help Sweco use Autodesk products and to do development if needed. We got the approvals needed to use some of these resources and in May 2016 a team from Autodesk consisting of the project manager, consultants and software developers was assembled to develop the Sweco Issue Tracker. Sweco in Finland was already using JIRA, a scrum based software development tool/database to manage construction projects. Sweco and Autodesk examined the possibility of combining the latest model viewer technology (LMV/Forge Platform) with JIRA to create and assign issues in Navisworks and then view all the information in a web based viewer. Several workshops was held for requirements and testing and in the August a candidate for the Sweco Issue Tracker (SIT) was released for testing. Page 23

24 FIGURE 22 - JIRA DASHBOARD ON TEST PROJECT AUG 2016 At this point model based issues could be created in Navisworks and models and information could be viewed in both Navisworks and through a cloud solution on any web browser, but we wanted to move one step further and to be able to also create and assign issues in the cloud solution. The software developers accomplished this in November. And so, the Sweco Issue Tracker was released. Page 24

25 FIGURE 23 - SWECO ISSUE TRACKER - WEB INTERFACE In the SIT web interface we are able to visually identify and describe issues in the models, assign them to project teams, sprints and members with due dates and to update that information. All the information is stored and contained within JIRA as tasks. In JIRA we can update information and move tasks and issues through customized workflows as they are being solved, checked and closed. We can even do any kinds of reports to track the progress of tasks. This makes us able to communicate on a whole new level in both the BLR project and in other Sweco projects that are going to utilize this technology. Page 25

26 In conclusion The ICT/BIM execution plan is a client requirement that gives us leverage to change the way we re working in this project. It is so much easier to implement new methods when it is specified in the contract. It gives us the means to finally make BIM-based design processes and not pushing BIM out on the side of the project as something the tech guys needs to take care of. Instead we use BIM as a way of monitoring project development and ensuring that we are delivering the project on time. The creation of a project execution plan including ICT and BIM gave us new ideas and ended in a BIM cloud-based project management tool that supports our processes and workflows. Close collaboration between ICT/BIM and design management is crucial to establish BIM as the way we are working in the project, all levels has to be included, from the engineers to the project manager. Automation of repeating tasks saves lots of boring hours and leaves little room for human errors (don t mind the computer errors). Autodesk has resources to help you setting up processes and workflows. They can also help you finding the technology to support those workflows or even develop new solutions through the Forge platform. Page 26