Breaking Barriers: Using Data Exchange to Connect Native Revit and Tekla Data

JAN KULESSA: Welcome, everybody, to our Autodesk University class, Breaking Barriers: Use Data Exchange to connect native Revit and Tekla Data. First of all, let me introduce you to your speakers.

So Jan, and I'm currently a Solution Architect with focus on Autodesk cloud technologies, obviously BIM and process automation. I have over 8 years experience in software engineering and also more than 12 years in the AEC industry. Now, please let my colleague introduce himself and our company.

ALEXANDER STIRKEN: Yeah, hello everyone. My name is Alexander Stirken. I'm actually a structural engineer and a former research assistant in digital engineering. And that's where actually fell in love with software engineering. And I have now, over 4 years of experience as a Software Engineer at GOLDBECK. And currently, I'm working as an IT Project Manager BIM, with a focus on configurators and Autodesk cloud technologies, about which we want to talk with you today.

So before we dive into the topic, let me introduce you to our company GOLDBECK. So we are actually the largest family-owned German construction company. And we now exist for over 50 years. And what makes us unique is that we see our buildings as products. So we build our building halls, offices, multi-story parking garages, and residential buildings.

And when you are a customer at GOLDBECK, you will get everything from one hand, so from the first idea through design planning, up to services during operations. And as mentioned, we are a family-run business. And we exist for more than 50 years now, in the second generation. And we have delivered over 570 projects to our customers last year. That's more than two projects per working day that we hand over.

And that was made possible because we have 14 plants, where we produce our parts in-house, and over 100 locations across all Europe. And together with my 12,000 colleagues, we made a turnover of 6.7 billion Euros last year. And what makes us unique in this industry is that we have an integrated digital design approach, with over 2000 Revit users and actually, over 6000 BIM 360 users.

And what is the key concept of our success? We build element-based in our construction process. So our idea is to have a modular standardized construction approach. So we build our components in-house in our own factories. And this allows us to build incredibly fast and cost efficient. So you can see that at as building blocks in big.

Before we dive into the technical topic, let us quickly go over the challenges we are facing currently in the market. And before I want to go to the technical challenges, let us start with the bigger picture. So currently in Europe and especially in Germany, we are having a problem with apartments and housing. So we are missing a lot of opportunities for people to live.

And because of that, the German Federal government decided to have a goal to build more than 400,000 new apartments per year. And if we are looking at the numbers, we can see that we are lacking more than 100,000 apartments last year. So the question that we are having here at GOLDBECK is, how can we solve these problems if we still are having challenges in our industry, like the increase of labor cost and also the increasing interest rates currently?

And this is where our idea at GOLDBECK comes into play. So our idea is to build fast, affordable, and sustainable, and to ensure that we have implemented. Our BIM method, 15 years ago, already with the introduction of Revit into the company. And for us, actually, building information modeling is our primary digital design method that we use in all our phases.

So in GOLDBECK, we are doing all the construction phases from design, early design, to detailed design, to the engineering phase, and also to construction. We are doing everything in-house. So our long-term goal is to have our model as a digital twin. I guess a lot of companies are having this goal. But with our fully integrated digital process chain, for us, we see that that's a goal that we can definitely reach.

But when we have a deeper look into the method, we have introduced it 15 years ago. But we are still having some issues in our digital process. So first of all, there is a wide variety of native software solutions around the globe.

So you may know that for every different phase-- so for example, for the design phase and for the engineering phase, you are using different tools like Revit and Tekla or Inventor. And all of these tools are actually using their uniform description or their description of component data. So a uniform description does not exist. Even that you are describing a general column, in Revit and in Tekla, they are described differently.

And because of that, we have implemented a lot of connectors that we are actually using to bring native data from one software solution to another. So inside GOLDBECK we try to not use the IFC data format, but to transfer data natively from one side to another. And also, when you look at our automation tools, those tools are using the data model of this respective native software solution.

So for example, if I'm having add-in done with the Revit API, this uses the data model of Revit, obviously. And with that being said, when you have changes in your business logic, you have to make these changes to all the components in the different systems. And that's very time-consuming.

And also in general, there is no cross-system data master. So we have that in sub-areas. Like for Revit, we have a family service, where we can track our Revit families. But it's not existent for all our data families and component families that are living in other software solutions.

With that being said, I hand over to Jan, because we participated in the Private Beta Program for Autodesk Data Exchange to tackle some of these problems. And that's what will Jan introduce you now to.

JAN KULESSA: Thank you, Alex, for explaining who we are, where we came from, what we're actually doing, and what our problems are. So let me introduce you to the Autodesk Data Exchange Program. To do that, we have to look a bit on the technology side.

So Autodesk Data Exchange is a new technology introduced by Autodesk. Think about the data exchange stores, detailed design data in the cloud, and it's enabling you granular data access and neutral sharing amongst stakeholders for collaborative workflows. So what you actually need to keep in mind that the data exchange is extensible, flexible, and federated.

So the question is, how can you access the data? And Autodesk provides us some solutions here. You can create your own custom connectors. We can explain later. And also, you can use Autodesk connectors that we're also going to show you today.

And you can access the data also with GraphQL and your web application or anywhere you want. So GraphQL is also a game changer here. You can use that for retrieving data and only the data you need. So think about the flexible point.

And one improvement of this API, so you can navigate now through your complete account and retrieve data and hubs. So it's even easier than before. And one of the benefits also, is you can retrieve different types of versions. And you can compare this data. So you can see what have changed in my data to exchange, what have changed in my design and see what happens.

And a few use cases you can imagine, for example, if you retrieve the elements and properties-- you can generate quantity takeoffs, schedules, dashboards, and etc. And you're not limited to your initial design application. So with that being said, let's have a deeper look on the data ontology of the data exchange.

The data exchange provides you with a structured data model with defined relationships and parameters. You can write. You can access the data you get from, for example, Revit. And as explained already, you can use versions and have a reusability of the data and information.

And also, you get quite complex possibilities for analysis and identifying relationships. These are called common references. And on top of all of these, you get geometrical information of elements. You heard right. You get geometrical information. So let's look on the right.

So as explained, you start with a design file. In our case, this is Revit. It could be also Inventor or other tools.

And you start with a view. And with your view you have created and just the parts you have selected, you can create a data exchange. This is uploaded to the cloud. And a version is created, or the version is updated.

Inside of a data exchange, you have a lot of elements. So think about the elements and have a deeper look. Inside the element, you have reference parameters like a level or a grid or other information. And you have the normal parameters with all the definitions, how they are described in the initial design tool. And as we already mentioned, you have the geometry here.

So the question is, how can you access this data? As we mentioned already, you have two possibilities. Let's talk about the GraphQL API here.

One of the reasons why GraphQL API is great, again, you get the possibility to get the presentation of complex relationships and the connected data. And you can traverse the data. And in the end, you get a huge increase of the interoperability of the data because of this easy-to-use system of Autodesk.

So now, have a look on the right. So if you think about a building and you think about the data as a graph, there's a building with structural elements which contains columns, beams. And columns contains other columns and parameters, which are possibly instance parameter you might know. And in the end, there is for example, a length or a custom parameter. In our case, it got big status with even the value inside of it. We all this here meta data.

So the second approach to access the data is the Data Exchange SDK. So Autodesk provides you with a possibility to create custom connectors, custom implementations. This is the same technology Autodesk uses for their connectors. So with this technology in mind, you can get all the metadata and geometry Information. And you can even share this data with everyone. And it's also nice that you can today get BREP and data container for them.

So if you look on the right, you will see that we have here, a simple example of a column created in Revit. Create an exchange using the Autodesk Construction Cloud. And on the last part, you can see it in a third party application, in our case, in Tekla.

So the question is, do we stop here? And the answer is no. So we ask ourselves, how can we transfer native data to the programs? Therefore, we talked, in the introduction, about barriers. Let me explain the barrier here.

So in our complete company, we have the explained complete digital process chain. And Anna is participating here as a construction manager. Anna is currently using BIM 360 for our collaborative work. So she is one of the 6,000 users. But Anna has no access to Revit.

But Anna has questions. So Anna is interested about the elements and the status of the building. So what we need here with it is, are they produced, are they constructed, or are they even on delivery, or are they already on site? So she wants to track and compare it to a model in BIM 360.

And why would she want that? She wanted to do tech planning with this model. So in the end, Anna want to track the state of every element in the building in real time in one place. And Anna is not alone. There are a few more people, like Mike and Tom, they would say it's helpful too.

Now let's get deeper and have a look on our use case 1 because. We call it the status update. So we want to change the status of an element from everywhere. And what we get-- we get model interaction on parameter level without Revit. I think this is quite cool.

Therefore, we need a workflow. First of all, we somehow need to create the data exchange, as mentioned. We do this here in Revit, because Revit is the initial tool and the foundation for the planning phase. And also, we want to further improve that.

So if you create the Revit exchange, you push it to the Autodesk Construction Cloud. And from there, you can read and write status from everywhere. So to do that today, you have to create a web app to track and change the status. This is something I'm going to show you later.

With this in mind, you can even embed that to existing native solution. In our case, we will show you that with Tekla. And in the end, if you have changed the status in Tekla or for example, in the web application or anywhere, you want to re-import this to Revit in our case, to just parameters updates in the Revit native model. Here are some remarks to remember-- what we need is an external element ID to be tracked as identifier. And in our use case here, we just exchange pure semantic data.

And here, we have our video. So this is a mentioned, web application. On the right side, we're loading the data exchange in the background with our SDK, provided by Autodesk. On the left, we have the viewer technology integrated to show the visual elements. And you can see, if you select an element, you get a few parameters. In our case, we changing the status because we missed it in the early phase.

But we want to change the status to construct it in this case. So after we are ready, we create a new exchange. Now, what happens in the background is the data is processed. So we're creating a data exchange from a geometrical and a metadata perspective. And also, we're creating a new viewable, which is also accessible in the cloud.

As you can see is everything processed. We do a reload on the model. And again, we do need wait a bit. So after the data exchange is completely loaded, you can go back to your elements. And now you see that the values are set or changed in this case.

You might notice that there was not a complete workflow we showed you. And there are limitations today, to be honest. So what we couldn't achieve our complete workflow is quite simple or quite complicated, depends on the view.

So we have a bidirectional transfer back to Revit. It's not possible yet with the Revit connector. And Autodesk knows that. And Autodesk is improving that.

So what you get right now, if you just change one exchange and try to import it back to Revit, you just get reference information. So you do not really update the existing elements. And the same applies to other connectors like Tekla.

To be honest, it's possible to do your own mapping if you create your own custom connector for Revit. But I think this is something no one wants to do. And on the other hand, you might notice if you go to the ACC viewable, the data is missing. So right now, you don't can see the properties in the ACC viewable. We made it possible by integrating the SDK and the Graph API to our custom solution.

So what about geometry, you might ask? So therefore, we talk about the next barrier and our next colleague. So Tom is a construction engineer. And Tom uses Tekla for modeling-based engineering planning. And his colleagues also use Trimble Connect for Coordination.

Now on Autodesk Class, other technologies. OK, but we will explain it. So there are also some more facts about Tom. Tom, most of the time starts the engineering phase as soon as possible after the design phase is completed, or in our case, as Alex explained in our process, is that the phases can overlap.

So this is tricky. And Tom is new to Tekla. He used Bocad before at GOLDBECK.

And one important information about Tom is he don't want to always start from scratch. So he's asking himself, why do you have, generate grids, beams, columns, and other simple geometry that has already been designed correctly in Revit? This is a good question, whether our use case 2 starts.

So we at GOLDBECK want to transfer a native element from Revit to Tekla. And to target that, we want a seamless exchange of model data between native software. But here is the history at GOLDBECK. And Alex is going to explain to you, our history at GOLDBECK.

ALEXANDER STIRKEN: Yeah, thank you Jan, for the presentation of the second use case. And as Jan mentioned, we are having a history here. And this use case that we are having here is existent at GOLDBECK 15 years already. Because we started with the integration of BIM 15 years ago.

And because of that, we have already made an application to solve this problem. And what you can see here is basically a Revit add-in that we are using. It is called the GOLDBECK connector. And you are selecting some elements from your design model. In this case these, are parking garage concrete slabs.

And as you can see, all the elements are getting imported to our application, where we are using a custom data format, which we have done by ourselves, which we have defined by ourselves, which is called the [INAUDIBLE] data, GOLDBECK model. And what you can see here is actually that we are transferring all these geometrical information to the Tekla API, and then bringing these elements into Tekla with our own custom connector.

And as you can see, in addition to the geometry that is getting transferred, we also get automatic reinforcement here. So you can bring the native geometry from Revit to Tekla. And you can also trigger automations like automatic reinforcement and reborrowing for our parking garage slabs. Because according to our system, we know what to expect. We know how they are getting reinforced. And that's what we have trained the algorithm on.

So what is actually happening here, just to summarize it? We are doing a model extraction with our custom Revit add-in, just like the data exchange. And then, we are pushing this data with the Revit API into our own custom format from of the GOLDBECK connector. And from there, we then use our own connectors in the native software solutions like Tekla and Inventor to bring the data back to native geometry. So we are not using IFC here. We are using our own data format.

So you might ask yourself, that is already quite good. So you have solved this problem already? Yes. And to some point, that is correct. So we can already transfer our native geometry from Revit to our engineering applications, but just one direction.

And we can do a mapping of native properties, according to our logic. So what are the properties on the Revit side for a column? We can map that to the Tekla side. And also, as you have seen, we can trigger automation components like automatic reinforcement.

So to summarize it, we have currently streamlined one-way workflow, but with a fire and forget approach. So everything is running locally on the machines of the engineers. And as soon as the data extraction is done, that's it.

So what do we want to have in the future? First of all, it would be fantastic to have bidirectional transfer from Revit to Tekla, and then back to Revit again, as Jan mentioned before. This is what we have not implemented yet.

And also, it would be fantastic to have version tracking for our models. So no fire and forget. Who has changed what, and in which state? So we can keep track of that.

And also currently, we are doing the mapping completely from our own logic. But let's take a regular column that has the same idea on the Revit side as on the Tekla side. So we are talking about the regular column.

We should not do the mapping ourself for elements like this, for these common elements. And lastly, we want to have a cloud implementation to make data available everywhere and also to use the performance in the cloud to speed up our process. And because of that, Jan will now show you what we have come up with a solution for that in the Autodesk Private Beta Program.

JAN KULESSA: Thank you, Alex, for explaining where we come from in our history. So until now, we talked a lot about data connectors. And we do not stop here. So we showed you where we came from, we showed you our GOLDBECK connector. And now, we're going to show you the Autodesk connector, which is available today.

Here, we have the Data Exchange add-in for Revit. And we have some columns and beams here. And we now select what we want to export here. And we want to store this in our ACC account. So it takes some time on processing.

It's doing the same here. So we're creating the data exchange in the background. The view that is generated after that, we skipped a bit. We do the same on Tekla.

So we have, again, a connector from Autodesk. You can select and preview your exchange here. So you see the geometry. It's like the same in Revit. And then you can load it.

This also might take some time, despite how big or small. Now, you can select different options for importing. We keep it here, simple. And we just import it to geometry. You can also view again, the geometry here, with the Tekla connector. So it's the same geometry.

Now, have a look on the element in Tekla. So for the ones not familiar here, we see reference geometry. This means there are no properties. This is just simple geometry.

And this is not what we want to achieve. So what have we seen here? So we did extract Revit element with a data exchange connector from Autodesk. It's quite cool. Then, we import this element and import it with Tekla connector. And then we get reference elements.

And we can track it. We can change. We can see what happens between the versions. But to be honest, we only get geometry linking with versioning so far and no meta data on elements. And if we are honest, we can do this with Revit. And we would get the better import without the cloud tracking.

But we do not stop here. So we took the SDK and said, OK we are used to the kind of import. So you might remember the application here. We again, loading the data exchange of version 4. And we have our model here.

So in the background, you see Tekla, which is already running. So this is add-in, where we host a web application. And as a user, I can select elements and view. And if I'm good with it, I can import it. And you see, it's quite fast here, and we create geometry.

So we created two columns and two beams. And the user can decide, I want more geometry, maybe four, maybe even on another level. We sometimes miss select, so you might would be a nice opportunity for category import. So you can see, we create new geometry with different information. And maybe, we also want to select some types on the other side and also import this data.

So I think, going to the last ones on another side, you can see, there's no stages, just some quantity information for our ERP system. And now we import the data. So I think it's good for today was importing data.

Let's have a deeper look on this element. So for the people that are not familiar with [INAUDIBLE], we now see, that is created as a native element. So it's a column here with a profile imported in the name from Revit. And also, we have the data status and the external ID imported to map the data.

For the ones who are excited as me, let's see what have we seen. So we created native geometry mapping with Data Exchange SDK implementation. And also, we did semantic mapping of parameters, according to the implementation logic. So these were just two parameters. But you could add a lot of more.

And again, here are also some downsides. So you have to do a custom implementation of the mapping logic with Tekla API. That's required. And actually, you have someone to do the work for the bidirectionality here. So with this in mind, I think there is some improvements for the future, as this is where I hand over to Alex.

ALEXANDER STIRKEN: Yeah, thank you very much, Jan, for the introduction to our second use case. And I want to go to the outlook. And let's have a brief a look at what can happen in the near future.

And why we were using these APIs in the beta program. At some point, we were asking ourselves OK, this is super powerful. We are getting granular data. We can have version tracking. If we want to do it, we can make native connectors with the SDK and the Graph API.

So we ask ourselves, is this the next big thing in AEC sector? And actually for us at GOLDBECK, yes, it might be. Because we have the full process, digital process in-house. So it's not like we have to exchange models. But we can have the full process in-house.

And for us then, it came to our mind, OK, we can have one project with one model for all the phases, and that, as granular data, that can everyone access in the company. And that's super interesting and powerful for us. And that's where we want to drive to.

And how can we get there, was the question we are still having. And first of all, we see building up a single source of truth, just on a semantic way, possibly, actually with the current connectors. Yes, they have limitations. Because currently, the native imports, back to Revit, for example, as Jan mentioned, is not working. But I guess Autodesk is definitely working on that.

And secondly, with this data model now available the Autodesk data model, now we have an actual foundation with the potential for AI. Because now, you have a data format where you can rely on, where you can build your applications on. And you know that this is processable in the cloud and super interesting for us.

And also, to have just a semantic approach, as Jan showed with the GOLDBECK status and the IPs, you can use this as a foundation for as-build models. So actually, if we are not talking about geometry, just about semantic information, you can bring all the information from everywhere via web app into your model.

So you can just think of it as you're having an ICC model. And you can somehow bring information into it without opening Revit. And that's a super new approach.

But then, there are still some limitations. So native geometry mapping will be a real challenge, bidirectional. So because, do you really want to import fully engineered elements that are very detailed back into Revit into your design models? We cannot answer that today.

So here, from a technical and also from a methodically perspective, that will be hard to say at the current point. But what we can definitely think about is, and what we definitely want to think about in the future as well is, to have native models per phase. So you have a native design model, you have a native engineering model. And maybe in the end, you also have a native as-build model with bidirectional semantic mapping, so that you have at least a semantic single source of truth of your model in your ACC model.

OK, so what would be the next steps to take? First of all, let's have a look at what has to be done for the data exchange. First of all, the bidirectional native semantic connector capabilities have to be extended. We have talked about this. Let's bring native semantic information back to the Revit model.

We don't want to have reference elements there. We want to bring the data directly back to the native model. That's important for us.

And secondly, it would be super nice to have the possibility to do a property mapping. For us, just as we do it for our own connector, where we have to maintain it ourself, maybe there can be an interface, where you can say, OK, I have this property in my Revit family. And I have this property on my Tekla component. And I want to link them together. And that, I want to push to a database. And there it is stored and secured.

And then, we have to further investigate the native geometry transfer possibilities. And from our perspective, we should start there with common building components. Because we have a lot of families also in-house that go back, which are consisting of a lot of small elements. But why not start with the general components, like regular steel beams, regular steel columns?

They exist in Revit. And they exist in Tekla. So they are kind of easy to map, even from a native geometry perspective.

And then, what do we, as GOLDBECK want to do in the future and what we definitely will do in the future is, first of all, we want to bring together, the two use cases that we have shown you. So bring together the status mapping and the native geometry transfer into our GOLDBECK connector. As soon as data exchange capabilities are there, we will definitely switch over our GOLDBECK connector to the cloud. And that will be a huge step for us.

And in the long term, we definitely want to think about a single source of truth for every project at GOLDBECK with the use of Autodesk data model and Autodesk Data Exchange. And in the end, what drives us at GOLDBECK is, yeah, to drive this cloud transformation with federated data in AEC. So these are currently exciting times, and we are happy to participate. And then, with that being said, I want to hand over to Jan for the last words.

JAN KULESSA: So, thank you. You already got Alex excited, me is excited. And a lot of people at GOLDBECK are excited about what we told you today. So if you're also excited and you have investigate similar use cases, or you're tackling technologies problems, or you have other technologies use cases with Autodesk cloud, please connect. We are happy to connect with you and talk about data exchange and other Autodesk cloud models. So if you question how you can contact us, feel free to send us an email, or just contact us on LinkedIn. So we thank you very much for hearing to our Autodesk University class. And we say bye.