설명
주요 학습
- Explore a solution that avoids duplicate data storage by connecting Vault and Autodesk Construction Cloud more effectively.
- Discover our Autodesk Construction Cloud extensions for efficient CAD-drawing management, regardless of Vault experience.
- Gain insights into our change management support for introducing a platform with few advantages for CAD drafters.
발표자
- MBMarion BehrensMarion has created her first BIM model 25 years ago during her architecture studies. Later on, she also completed a degree in computer science. Since then, her professional focus is on digitalization in the construction sector. At DB Engineering & Consulting, she manages the CAD & BIM Competence Center within the IT unit, where she drives cloud migration and development topics for the design phase of rail infrastructure construction. Passionate about the implementation of open APIs and data-centric concepts, she is working with Autodesk Platform Services since its first release.
MARION BEHRENS: Hi there. Are you ready to join for a train journey? So we are moving forward. We are navigating the shift from Vault to the Autodesk Construction Cloud.
If you're involved in the introduction of ACC in your company, you have come to the right session. So you're on the right track. Do you have a history with Vault? Then, even more so.
So welcome on board. My name is Marion. I'm your speaker today. I was a first-generation BIM student. So I created my first BIM model more than 25 years ago. And, well, it wasn't called BIM at that time, obviously.
And so this is my second Autodesk University. You see a photo here of mine from last year in Las Vegas in the Venetian. And it's my first time as a speaker, and I'm really excited about that-- and, yeah, quite a little nervous.
So I have a degree in architecture and a degree in computer science. And with that background, my professional focus for many years already is on digitalization in the AEC industry. I am working with the Autodesk Platform Services since the Forge Viewer was released in one of its earliest versions. And I'm really passionate about open cloud APIs and about developing data driven concepts.
I work at DB Engineering and Consulting since the beginning of last year. So DB, that is Deutsche Bahn, so the national railway company of Germany. I live in Stuttgart, Germany, and my hobbies are traveling-- ideally by train, of course-- and also cycling and coding. So you can easily find me programming a whole weekend.
So back to our journey plan. Please let me first briefly introduce my company, then next where this company is coming from after 10 years with Vault as the data management system. Then let me explain why we need to shift from Vault to ACC and how we plan to do that. And it's a lot about XREF. And more details about that I will present when we stop over at Stage 1 and Stage 2 of our project. And in the end, I will also explain some other topics beyond XREF and will outline how we approach them.
So DB Engineering and Consulting, Railways for the World of Tomorrow. So DB E&C is an independent company within the DB group with more than 6,000 employees. At DB E&C, we offer a very wide range of services within design and planning of railway infrastructure, as well as construction supervision, environmental and geoservices, also project management and consulting.
And with this wide range of services, we use a large number of very specialized software applications. And my team and me, we are responsible for about 200 engineering applications and use for cut and. We are Autodesk EBA customers since 2015, and we have 14 applications that are based on AutoCAD or AutoCAD Map 3D, especially those customized for rail infrastructure design. We also have more than 45 Revit add-ins and, additionally, our own in-house development team for AutoCAD and Revit extensions.
And we have Vault as our data management system for 10 years already, hosting more than 2,000 projects that sum up to a total of 40 terabyte filestore, all within one Vault. And with that, our Vault is the biggest Vault in the world. That had been confirmed also by the Vault product team, and it's still growing by 7 terabytes per year.
So if you think we're proud of that, actually, we are not. But yeah, how did that happen? Yeah, why did we DB E&C, end up with the biggest Vault in the world? I'm pretty new in that company, but did a little research on that. So let's get into a time machine and look back to the year 2013.
So the AU icon in that year was stylish green, and Wikipedia claimed that "Vault is intended to be the core data management strategy for Autodesk design products." When we look at the timeline here, the integration of Vault with Revit was just released in that year. And at DB E&C, we had almost 100% AutoCAD users, but an increase in Revit usage was expected for the future.
Cloud platforms had been mentioned at AU 2013 as some future development. They were still too far away and not available for a quite long time to come. And it was exactly this year that decisions had to be made for a very important project, which was the Doha Metro, Qatar-- so the railway network of the Doha Metro connecting the airport with the city center and the soccer stadiums for the FIFA World Cup 2022.
Since 2008, DB E&C was involved in building the Qatar Integrated Railway Project. And when, in 2013, they were engaged for the project management, they had the challenge to establish a collaboration with teams in Germany and Qatar. Therefore, a shared project platform was needed, and they chose Vault.
So just very briefly, one slide about what is Vault. So Vault is a client-server system that consists of the central Vault server application and the locally-installed Vault client applications to access the central data storage. Vault has integrations with Inventor, with AutoCAD, and the Revit integration, unfortunately, was not developed any further after it's been introduced in 2013.
The Vault server has APIs that allow automation-- for example, our clear trash script that's running on a so-called job processor, and it's deleting files from our trash folders once a week. And also, the Vault client has APIs so that we can extend it with add-ons on the user side and combine it with a job processor. And for example, our validation, that works like that. So the user has a button to request a validation report for one or multiple files, and then the job processor does all the work.
And additionally, we can store our company-specific plot style tables on a job processor for PDF creation. Again, the user has a button to request PDF creation for one or multiple files, and again, the job processor does all the work. The benefits are that the users are not blocking their machines, and we can make sure that our standards are always applied.
We use the job processor with a setup on a basic framework for from Google Orange. So when Vault was first introduced at DB E&C in 2013, it's been a change process, definitely. But today, we have 2,500 users enrolled, and we look back at 10 years with Vault.
And I would like to explain how world has shaped the way we work at DB E&C with four short examples. So first, Vault has a feature that metadata are synchronized with AutoCAD title blocks. That means that we don't need naming conventions for populating metadata. And, of course, we do work a lot with metadata, and it's super easy because you must just maintain it in your title blocks. And you have to maintain it there anyway.
And, of course, the file name is something very visible to the user. And the project managers have the freedom to decide how to use it in their projects until the file name becomes, again, important for the handover when files have to be stored on a folder structure and file drives. So the second example, Vault has a very powerful reference manager that can be used to check dependencies. And because it is so simple, it has caused extensive use of XREFs in our company.
Third example is the Naming Wizard. So Vault has a Renaming Wizard that makes renaming of files is super easy task, and the dependencies are always preserved. And as a result, renaming of files has become part of our process, and it's our culture. And our users would be very upset if renaming was not possible or if renaming of files breaks their dependencies.
And fourth example, extensions are possible with APIs on the server side and also on the client side. And as a result, we have many custom enhancements in use. So after all, Vault is really cool, and the Vault Product Team has also developed a browser-based client and a mobile app. And yeah, in the end, Vault is great for cut data management and perfect for mechanical engineering, especially when Inventor is in use and AutoCAD.
But for a company where BIM is being implemented, it is not a suitable collaboration and project platform. So it is not a CDE And this is where ACC comes in. So we're now leaving Vault behind, keeping in mind that it has shaped us shifting to ACC.
So as BIM methods become more common in our projects and BIM standards are established in our company, we need a modern collaboration platform that enables subs and client access to data, that makes design data available to project controllers, that combines specific BIM functions all in one platform for better consistency and integrity, et cetera. So all the benefits of the ACC, but this is not meant as a promotional campaign, so let's skip them. I guess there are other sessions on that, just like my personal goal. So the benefit that I want to bring to my company to open the path towards excellence, if I can put it like that, to reduce boundaries with third-party systems, to bring CAD and BIM and GIS together all in one platform, to use data instead of data being trapped in files, and to unlock the potential of the new Cloud APIs. So the ACC data model API, the Data Exchange API, they'll be only useful if all design data is located in ACC.
So why is it just now shifting to ACC? The rail network in Germany is in a bad condition, and delays and train cancelations are the order of the day. And jokes about Deutsche Bahn have to take this with humor. The reason for this situation is that for decades, too little had been invested in rail infrastructure. But now, it seems that the bottom has been reached and that there is a shift.
So remember that DB was involved to build the Doha Metro Railway for the FIFA 2022. Just two years later, 2024, The UEFA European Football Championship took place in Germany this summer. It was a huge event, and many foreign football fans have visited Germany and were badly surprised or even shocked by the unreliability of German rail.
But the day after the final, when all teams and fans had left, the Riedbahn construction site started. So Riedbahn is the main railway line between Frankfurt and Mannheim, with more than 300 trains per day, usually. And everything is being refurbished in this period. So all these construction works, 170 kilometers of rail tracks, a lot of switches, overhead lines, stations, and much more.
And this is all done in parallel in only five months, instead one after the other. And like that, it would otherwise have taken more than six years. And this project is just a pilot for 40 more projects until 2030. So most of the long-distance network will be renewed, and that's all the red lines on the map, as a so-called master plan for the renewal of Germany's major rail routes, so-called "corridor projects."
And in these upcoming 40 projects, due to the tight time schedules, we expect extreme pressure on productivity, and we expect that large project consortiums need to collaborate efficiently within minimum time. And therefore, a modern, cloud-based project platform was needed. And we chose ACC.
So again, the request comes from a set of special projects, but the introduction of ACC should happen for the whole company. So far, so good. So what's the problem?
In a company with Vault in use for more than 10 years, there is a certain level from which to take off. And we are not using Group Drives or Shared Folders. We left them behind a long time ago. And none of our problems with ACC would exist if we were still using Group Drives today.
Instead, we have 1,600 CAD drafters. So all the AutoCAD and Vault users, they have more disadvantages of ACC as compared to Vault for their daily job with CAD data management. In total, of course, ACC is the preferable solution. But for most of our users, it is the opposite.
Their problems are in descending order of importance, the XREF problem-- so our showstopper, that AutoCAD plot-style tables are not supported. Therefore, PDF creation only works on local devices. That they can't populate metadata from AutoCAD title blocks. They have to do double work to fill in metadata, and they need individual access to each project. And then, waiting time is always necessary before you can work on a project instead of just being there by default, as we have configured it in Vault.
So we will come to this point later. We start with our hardest issue, the XREF problem. And now, we are slowly getting into the more technical part of my presentation.
So we have a common setup. As in many projects, we have AutoCAD DWG files that have references to other CAD or image files-- so-called "XREFs," so abbreviation for "eXternal REFerences." And we also have Revit files that have links to CAD files, image files, IFC files, or even other Revit files. And both setups can be in Vault or can be in ACC-- or even in many other data storage locations, but that is not our scope.
Vault has its strengths working with references, and it resolves all changes in relative paths of linked files for AutoCAD and for Revit. But the XREF problem for AutoCAD files is that dependencies are getting lost in ACC when somebody is renaming or moving reference files or somebody is moving the host file-- so basically, when the relative path between the host file and the child file is changing. For Revit files, somehow ACC resolves all the changes in relative paths of linked files within ACC.
Well, to understand how big the problem actually is, we extracted some numbers from Vault. And the result is that within all almost 40,000 files that have been created in Vault in 2023 that have a reference, so like some parent file that has a reference pointing on these files. In total, it shows there are more files created in Vault in one year.
So within these-- actually almost 34,000 files-- there are more than 7,000 files that were renamed or moved in that year at least once. Assuming it takes 10 to 15 minutes to fix one broken reference manually, it wouldn't even be enough to hire one person or one full-time equivalent only for that-- for repairing relative paths manually.
And a quite obvious question here is, why can't we just change the workflow so that a file, once created, always remains there-- same location, same name? Answer is. No, unfortunately, these processes are deeply rooted in our company after 10 years with Vault. And reasons for renaming and moving of files are that naming structures are defined or completed just after a project was started, and many files were already created. So they all have to be renamed.
Other reasons might be reorganizations of the content, especially in projects that are running for a long time. For example, there are some organizational restructuring, which is quite common at Deutsche Bahn. And then, from a large scale, that reflects down to the smallest detail, such as the file names. Or, very common scenario, permissions are changing when external drafters join the project and files need to be moved to folders with different permission settings.
So it is the XREF problem that is defining our roadmap of introducing ACC. Today, all AutoCAD and Revit users in our company work with Vault. In Stage 1, we let the Revit users work with ACC already as they are not affected by the XREF problem. And in Stage 2, we have the XREF problem solved somehow, and all AutoCAD and Revit users can work with ACC. So that's a timeline, but it's pretty irrelevant, so we will introduce each phase as soon as it is safe to do so. And in the worst case, the entire rollout will take until 2027.
We are about to start with Stage 1 early next year. But at the same time, we are preparing for Stage 2 already. So let's start with Stage 1. We are introducing ACC, but only as a second system beside Vault.
In Stage 1, We are not solving the problem, but we enable Revit users to work with ACC while AutoCAD users keep managing their files in Vault. So the problem that arises here is that we have to manage the same projects in two platforms, and references are pointing from files on one system to files on the other system-- normally, from a Revit file to ACC, to a CAD file in Vault.
Then, the problem is that changes in the reference CAD files in Vault are not updated in the host files in ACC. That's not even a way to be notified that the referenced file must be updated. So in the end, there's a risk of the Revit users continuing to work with outdated design data, which might lead to various types of chaos in the project.
To avoid that, our first idea was, why not sync files from Vault to ACC? When two platforms are needed as an intermediate solution, so common solution to synchronize from one platform to the other. And here's our first concept. So the synchronization is in one direction from Vault to ACC, so that references will be only within the same system.
The problem we found when we started working more intensively on this concept was about duplicate files. It's difficult for the users to know what is the original and what is the copy. And there are some write protection necessary on the copy.
So the more we discussed the solution, the more edge cases we found. What if a file in Vault is deleted, renamed, or moved? What if special notifications or special permissions are configured? So long discussion short, there was a commitment, and my team finally better refer to the original; don't copy. And we developed the XREFresher concept for upgrading references to Vault instead of synchronization.
Starting conditions are, again, Revit files are in ACC. CAD, especially DWG files, are in Vault. And Revit users create references to files from Vault.
Then, the problem to be solved is that updates on the referenced files in Vault are not reflected to Revit files in ACC, or basically anywhere outside of Vault. Requirement for a solution is that updates of the referenced files in Vault must be automatically reflected in the Revit files, including renaming and moving of files-- also deletion, by the way. The solution is not to synchronize all CAD, especially DWG files from Vault to ACC, but to develop a Revit add-on that updates references pointing to Vault via the Vault API using the Vault file IDs.
We already know there are limitations to this solution. So the Revit files must be loaded locally, And the Vault client must be installed. And tokens will be charged.
So a guy from my team in Germany together with a girl from another team in India implemented the XREFresher with the following basic functionality. So after a link is created in Revit, there's a request sent to the Vault API for the file ID, version ID, and other metadata from Vault. And this is saved inside the Revit extensible storage, connected with the referenced file.
So with that, everything is stored in the Revit file, and anybody at any time can open the Revit file again, assuming that the add-in is installed. The XREFresher add-in will send a request to the Vault API for available updates, manually or automatically. At the moment, we have implemented both. And the response will be processed. And available updates are highlighted in a list view, as you can see here on the screenshot. And then, the user can do the actual updating.
This solution is tested, and it's currently in use in the pilot project. And I'm not going to dive deeper into the implementation. But if you are interested in this solution, no matter whether it's for an intermediate solution as we do, or you have a permanent setup with some CAD files in Vault that you want to reference from Revit files, please reach out to me by email, LinkedIn, whatever. We are really happy to share more details of this solution.
So now that we have sorted everything out for Stage 1, we move to Stage 2, when all AutoCAD and Revit users will store their data in ACC. So back to the XREF problem that must be solved, otherwise Stage 2 won't happen. Again, a first approach that has led us to a dead end. An approach just to make it work in ACC is automation with Webhooks and using Design Automation API.
And the setup is the following. The user cannot rename or move a file in ACC. And then, second, we have a webhook listening on this action that's sending notification to our web service. So this web service has a so-called CTO table-- so a list of all of the constantly-tracked objects. So that's the DWGs and their references, and then checking from the table whether there exists a parent file for the file, which had just been renamed.
If so, the web service will take that file, send it to the Design Automation for AutoCAD, and there, the parent file will be modified with replacing the extra saved path attribute. The result will be sent back to the web service, and then, in the last step, the web service will upload a new version of the parent DWG to ACC Docs.
So we were partnering with Martin Luca from IOLabs on this topic, and he developed a proof of concept that was working for one file and one host file. Then we got into the discussion how to get from this PoC to a universal solution. And there were problems and topics that are still unsolved-- for example, how to deal with mass renamings, which is quite common if there is some restructuring, for example.
What to do if Webhooks are failing? And they are failing, so a constant re-scanning is necessary, needs to be implemented. Then, what if the parent DWG is locked because somebody is working on that? So very realistic setup, I would say. And finally, how to keep the CTO table updated?
So all of that perhaps solvable, but extremely costly. So we had to step back then and check out other options. And our idea was to reuse the XREFresher concept-- so to let references get lost when files are being renamed and provide a repair tool for the broken references.
Like for the Revit add-in, can we always save ACC file info with a reference inside the DWG file? And the XDATA, that might be the place where to store that in the DWG file, and then to repair the broken references locally with AutoCAD. And because, in this case, both host file and referenced file are in ACC, extensions are possible to do with some automation-- for example, so automatic detection of affected DWG files with broken references. And even automatic repair might be possible again with design automation.
So we are currently investigating in this direction. And at the same time, our Customer Success Team At Autodesk did a lot of investigation for us on the XREF problem. They found a solution architect who knows a lot about Vault, AutoCAD, about ACC and Platform Services, and he presented basically the same concept to us like that-- references getting lost when files are being renamed-- and developed a repair tool for the broken references.
Because Vault does it in the same way, and the improvement to our concept is that we don't need to store any information about the linked files inside the DWG file. Instead, ACC stores the relationships already. And here's the API. In the slides, it's linked to the documentation page for the data management API.
And in the response, You Will find a so-called tool ID. And that is the URL to the referenced file. And that is never going to change.
So at this point, we are still investigating further into this direction. We just started with implementing a first proof of concept on that. But we already know as a solution, it has limitations. It won't work for AutoCAD Web, and it won't be available in the ACC Viewer.
And that's going to be OK for our colleagues as it's covering what Vault is doing. However, we expect a final solution, and that's our third and best option. And from Autodesk, we expect a solution that covers AutoCAD Desktop, AutoCAD Web, and the ACC Docs Viewer. And as we know that ACC stores the necessary data about references, we believe that it's doable.
But that's it about the problem for this year's AU, and a good chance that I'll come back with the XREF topic next year. And I promise to outline at least those other main challenging topics we are facing for ACC-- again, in a company that was using Vault for more than 10 years. Our first challenge is that AutoCAD plot style tables are not consistently supported by ACC, but the federal railway authorities require approval plans, usually PDF formats, with strictly defined layouts. And I'm sure it's not only in Germany. In other countries, it's the same as well. And we can't create a PDF through ACC with a proper layout. And we cannot display a DWG layout properly with ACC or with AutoCAD Web.
One possible solution is really a very ugly workaround. That is to keep our Vault job processors alive and combine a Vault job processor with ACC Docs only for PDF creation-- and definitely, only for some transitional period. As a proper solution. It would be perfect if a plot style file could be defined for one ACC project, or even for a project template. And that solution we can't build ourselves. We depend on Autodesk. If it's not going to be solved, we have to do it in the very ugly way.
The second challenge is that we can populate metadata in Docs from AutoCAD title blocks. And so the ACC concept is quite different, and in AC, you should use a file name plus naming conventions to populate your metadata. And we are discussing different solutions. And one option might be to implement a SEC extension to automate metadata updates from values within a DWG title block.
But, attention, there's a potential conflict with the naming conventions, as outlined in this triangular relationship chart. So if anyone already has a solution to this problem, or just an idea of how to solve it, please let me know. So from our side, we still have a little way to go on this topic.
Third challenge is about the project setup and the fact that users need individual access to each project. Problem one is that if a user is not invited, user cannot see whether a project was created. But we strictly need to avoid duplicate project creation. And as a solution, we think about an external project creation tool where, independent of the personal access, a user can see all the available projects in ACC.
And problem 2, that if a user is not invited, a user cannot access a project. But we cannot tolerate any delays while waiting for activation in ACC. So if a user has to help out in some project, he must be able to do that immediately. And as a solution, we are thinking about some external self-service app for joining and leaving projects in ACC.
And we found a possible way to implement our solution in a presentation from last year's Autodesk University. Title was "Implementation of Optimized User Management" and was presented by SSOE Group. And so there's no need to go any more in depth here, so we simply proceed in a very similar way. Absolute recommendation to look at the slides and handout of that presentation, by the way.
I'm skipping our fourth challenge here today because it's about data protection and it's too heavy at the end of a session. It's in the slides. And better we come to a conclusion now.
I hope you found something to learn from our solutions and ideas, and also from those approaches that didn't get us anywhere. And here's what we believe are our main findings so far. So synchronization often sounds like the best solution too quickly. Are there alternatives to duplicate data storage? Think in all directions, listen to all concerns, and highlight only the most relevant issue, and be persistent. So the XREF problem is blocking DB from working with ACC. Only since we've been filling 80% of our presentations with this topic, we have started to make progress with that at all.
So I'm here alone in this recording. So my final slide is to mention all those who have contributed, and that's the end of my slide deck. And if this was live, we would move on to see if there are questions. And here's the final slide.
Downloads
태그
제품 | |
산업 분야 | |
주제 |