Autodesk Forge and SAP Bringing Sustainability to Digital Twins

PETR BROZ: Hello, everyone. My name is Petr Broz. I'm a Forge developer advocate at Autodesk. And in this presentation, I would like to share with you some of our initial results of our collaboration with SAP, where we focus on different ways of bringing sustainability to Digital Twins and business applications.

This is a collaborative research between Autodesk and SAP. And I would like to take this opportunity to thank all the people involved. On the SAP side, Oliver and Thomas have been crucial in providing technical support and help with the different SAP technologies.

And on the Autodesk side, Shakeel has been extremely helpful with providing his feedback from the business point of view. And Hassan has helped us tremendously with his expertise in the problematics in topics of carbon footprint and embodied carbon. Thank you, guys.

A quick note before we get started. During the presentation, I may make forward-looking statements regarding Autodesk or its technologies. These statements are not meant to be promises of any kind. And, therefore, business decisions should not be made based upon these.

Let's start with an agenda of our presentation today. We will start with a quick description of the problem statement and problem-- the question we're asking ourselves in our collaboration with SAP. Then, we'll move to a solution we're proposing and some of the ideas we're trying to leverage in technologies that are available today that we would like to put together to help with the problem that's been identified.

Next, we will go bit more technical and dive into the first prototype that's been implemented based on our collaboration between Autodesk and SAP. And we will show a quick demo of the application that's currently available. And finally, we will wrap up the presentation with an overview of next steps and future plans for our collaboration.

What exactly is the problem that we're trying to address? Let's start with a high-level introduction into the problematics of carbon footprint and embodied carbon. This is a quite complex topic. And I'm by no means an expert in carbon footprint. So I'm not going to try and go into too much detail. But let's try and set a context for the rest of our presentation here.

With carbon footprint, we're typically observing different types of operations and different stages, in this case, of a building life cycle and the carbon footprint that's produced during those stages. This is nicely captured in these modules provided by the New Buildings Institute.

The modules cover everything starting from the extraction of materials to their transport to a manufacturing site where building components are prefabricated. These are the modules A1 through A3. Next, modules A4 and A5 capture the construction process where the prefabricated components are transported to the construction site and put together. Modules B1 through B7 are related to the maintenance and usage of a building.

B6 and B7 are the operational modules where carbon footprint today is monitored quite nicely, whereas in the other modules, not as much. Finally, modules C1 through C4 capture carbon footprint impact during the end of life process for a specific building. That means demolishing the building and recycling or disposing waste material.

In manufacturing, a similar lifecycle is observed for a product and similar categories of carbon footprint are identified throughout this lifecycle. Again, it all starts with the extraction of raw materials and their transport to the manufacturing site. This also incurs certain amounts of embodied carbon.

Next, the manufacturing process where the product is actually created. Then, followed by logistics where the product is transported to its final destination. And finally, the recycling stage where a certain amount of carbon footprint can be observed when the product is disposed or recycled.

The question we have asked ourselves is, in business applications today, can users make sustainability-driven decisions? Or, could they make better informed decisions focused on sustainability if they had the opportunity? As far as we know, from what we can tell, this is quite rare nowadays.

And in scenarios where applications do allow their users to make sustainability-driven decisions with carbon footprint in mind, it is quite often a complex manual process. This is where we come in. We've been thinking about how to address this problem and make it easier for users to make sustainability-driven decisions.

We believe the solution lies in the connection of design data, business data, and carbon footprint information into a single, streamlined user experience where carbon footprint impact will be automatically estimated as the user makes individual decisions. And we believe that this will make-- this will help the users make better informed decisions focused on carbon footprint and sustainability.

That is why we've decided to join efforts with SAP. On our side, we're using the Autodesk Forge platform. For those of you who may not be aware, Autodesk Forge is a platform that is all about your design data. The platform can manage and process design data for you.

And it lets you connect external data sources, all sorts of data sources, to your data. It is a cloud development platform so some software development is expected. And with that-- with the platform, you can build custom solutions, putting your data at the center. And today, Forge can ingest over 60 different design file formats.

And, with a little bit of coding, you can build custom experiences where you can take external data, be it purchasing or ERP marketing data, scheduling planning data, and you can take this information and put it into the context of your designs. We believe this is a great power, a great feature that we want to leverage in our proposed solution, contextualizing external type of information in-- within your design data.

One of the common and frequently requested types of applications built with Forge are Digital Twins. This is exactly what I was mentioning earlier. With Forge, you can take your design data, be it a BIM model of your building or a manufacturing model of your jet engine, and you can use Forge to identify the individual parts of your designs to generate-- extract the metadata of your designs.

And use this information to connect external data, be it temperature or humidity measured by real-time sensors, as can be seen on the screenshot on the left. Or, whether it's retrieving information about maintenance checks or cost from ERP systems and mapping that information to your jet engine model by color coding, or annotations, or any different visual cues.

SAP is a 41 billion euro company that is a leader in business applications, especially in ERP and finance, CRM, customer experience, supply chains, HR. We have identified a relatively new offering, a product provided by SAP that we believe is a great fit for the solution we're proposing in our research. It is the Data Warehouse Cloud.

The SAP Data Warehouse Cloud is a multi-source business semantic service for analytics and planning. In other words, is a common-- it's a common environment where different types of data can be brought together and modeled in custom business data models and business data flows. The Data Warehouse Cloud also comes with its own marketplace, which allows you to bring other external types of information from third-party vendors.

This could be information such as a weather forecast or CO2 data for different types of delivery options, for example. On the other hand, the SAP Data Warehouse Cloud provides support for third-party applications that can act as both consumers and producers of the data modeled by the Data Warehouse Cloud.

Let's take a quick look at the first prototype that has been created as part of our collaboration between Autodesk and SAP. We decided to start with a smaller use case and then grow bigger. For our first prototype, we've chosen the scenario of a bike manufacturer company with potentially multiple branches and warehouses around the world or, for our first case, around Europe.

We consider the use case of this company's employee who's trying to order a bunch of replacement parts for a specific bike from multiple warehouses and have these parts shipped to its own branch in a specific city in Europe. We consider that there might be multiple delivery options with different impact on cost, delivery time, and, of course, carbon footprint.

Going back to our product lifecycle and carbon footprint diagram from earlier, the area that we're focusing on first with our initial prototype is the logistics. Again, the idea here is optimizing carbon footprint in the logistics stage of a product lifecycle by using cleaner fuels and optimizing routes.

The prototype has been built as a simple server application that is connected to both Autodesk and SAP. And it pulls and combines information from both of these cloud environments. From the Forge side, we're bringing information about the designs and the metadata of the individual design elements.

This is the important piece because design metadata may include information such as part number. And the part number is something we can later use to connect this design element to a particular data set from the SAP side, where we can have a list of facilities where a specific part with this particular part number is available.

From the SAP side, we're bringing information about the individual facilities of our bike manufacturer, about the availability of specific parts in individual warehouses, and about the different delivery options and their carbon footprint information. All of this aggregated data is then provided to the client application in form of RESTful APIs. The client application can be a simple web application or a web page that can be running on a computer or on a smart device.

On the far right, to process and manage design data, we're using the Data Management service and Model Derivative service. The Forge Data Management service is used simply to manage design data, being able to store it, track versions. What's more important is the Forge Model Derivative service.

This service is responsible for extracting information from the designs. The information can be anything like thumbnails, 3D views, interactive 3D views, 2D drawings, design structures or logical hierarchies, or, what's really important, the metadata.

Again, Forge can take your designs, more than 60 different file formats today, and extract the metadata available on the individual elements of your design, whether it's an architecture, engineering, construction, or manufacturing type of design. We can extract metadata for the individual elements. And this metadata can then be used to connect the elements to external data sources, in this case, stock availability in SAP.

On the SAP side, we're using the Data Warehouse Cloud and this modern data builder interface, where we define the actual data model for our company, for our bike manufacturer. We start by taking some of the initial tables that contain information about different facilities with their different geolocations. We take-- we read tables containing information about individual parts of a specific bike, which warehouses they're available in, things like that.

Then, using the data builder, we can combine these views and tables, these disconnected data sources together into a single view that can then be queried by our server application. In this particular case, we can also see that the View output that can be queried by our server application is parameterized.

This means that, when we want to run and query this view, we can provide a specific user-defined parameter, in our case a part number, that will define how the rest of the hierarchy and the data model here is processed. So, in this case, we may be interested in numbers of a particular part being available in different warehouses.

The server itself is implemented using Node.js and using Express.js as the main server framework. The application then also uses the official Forge SDKs and the @sap/hana-client module to be able to access information from both Forge and SAP Data Warehouse Cloud. As you can see in the code snippet on the right, the interface for accessing and querying data in the SAP Data Warehouse Cloud is really SQL.

We can make queries, SQL-like queries to obtain data from different views modeled by the data builder. And in case of the before mentioned parametric data view, we can also provide parameters to our queries using this question mark syntax.

Finally, to present the results of the aggregated data and the design information, we're using Forge Viewer and Svelte. Forge Viewer is a JavaScript component, a client-side component, that is available as part of the Autodesk Forge platform portfolio. The viewer allows you to bring any of the 2D drawings or 3D views extracted from your designs by Forge and display them in your own web page or web application. Setting up the viewer is quite easy, with many different resources that explain how it can be done.

Svelte is a relatively new UI framework. We believe this would be a good fit for our prototype because of the reactivity and the reactive nature of our user interface. We had expected that the user interface would allow the user to select different numbers of parts to be ordered from different warehouses, choose different delivery options. And based on that, different parts of the UI would have to change to reflect the different cost options, the different carbon footprint values, or delivery times.

Because of this reactive nature, we chose to try Svelte and it proved to be quite useful, a great fit. And, again, to quickly showcase how development in Svelte works, here is a quick snapshot. You can see that at the core of Svelte is a component, just like with React. You can build components and then put them together. And a single component can have a script tag that defines state of that component using the standard let keyword.

In this case, we have a state component with a single state called count, which is just a number. And we have some derived properties from this state called doubled and quadrupled, as you can see here. These will be automatically updated whenever count variable changes. And the rest of the component will get notified whenever any of these count, doubled, or quadrupled variables change.

Following the script tag is the actual HTML markup of the component that can then use a standard curly brace notation to interpolate the values, the parts of the state into the HTML markup of the component. As you can see here, as soon as the button is clicked, we change the state by incrementing the count variable. And at that point, immediately, the button's label will change as well as the two paragraphs at the bottom because these are bound to count, double, and quadruple variables.

Here's a quick demo of the prototype we've built. As you can see, the user can select a specific part of a bike and is presented with the list of warehouses where this part is available, in different numbers. And the user can then choose numbers of these parts to be ordered from individual warehouses and the delivery type, delivery option that should be used to transport these parts to the destination branch, which is currently Berlin HQ.

Choosing these will, of course, provide a summary of different price options or carbon footprint. And, in future, this could be other options as well, such as delivery time.

The source code of this sample application is available on GitHub. Unfortunately, it's quite tricky to set it up and run it locally today, especially due all-- to all the different external parts, especially the SAP Data Warehouse Cloud, where a specific data model must already exist in order for the sample application to be able to query it.

We are planning to add this information in the future. But for now, you're free to use this application and the source code as a reference or just to explore the ideas of how your own application could communicate with the SAP Data Warehouse Cloud.

Finally, what's next? This is not the end. We're planning to grow our research, continue our research and grow the different types of carbon footprint and embodied carbon modules that we want to cover in our prototypes and help users take them into account when making their business decisions.

We're considering adding more features from the SAP side. For example, when the user clicks the Purchase button in our prototype, we want to trigger a transactional operation. We want to generate invoices and use more of the transactional behavior and functionality on the SAP side.

Also, today, when choosing different warehouses to order the bike parts from, we simply compute a straight line between the two cities, between their geolocations. In future, we want to consider some of the existing distance matrix services that can provide a better estimate of distance in kilometers between two points on a map.

Also, when you think about it, we currently let the user play with the number of parts to order from different warehouses and choose different delivery options by hand. This could be optimized and auto-suggest it for the user, right? We don't have to let the user play with numbers. We can actually make some suggestions to start with. That's another idea we want to look at in a view.

Also, we want to expand the coverage and work with-- introduce some AEC or Digital Twin types of models and experiences into our prototypes. And as we mentioned earlier, we also want to consider other types of embodied carbon, not just the logistics.

Because one thing to think about is, for example, today, when the user is presented with options of ordering parts from a country that's very far but quite cheap to bring the parts from even when it comes to both price or carbon footprint, these parts may already have some embodied carbon footprint due to the fact how they were manufactured or where their construction materials were obtained.

We want to take that information and bring it into the formula as well to give the business application or this prototype user even better insight and even more information to make better informed sustainability decisions. That is all for my side. Thank you for your attention.