Unleashing Data-Driven Workflows and Collaboration Using the Fusion Data API

NEM KUMAR: Hi, guys, I present today on the topic Unleashing Data-Driven Workflows and Collaboration using Fusion Data APIs, which has been renamed to Manufacturing Data Model APIs. I'm Nem Kumar, director of consulting.

Before we go ahead, there are some statements. There are some things, which are in progress. So that's why a Safe Harbor Statement is there.

I'm Nem Kumar. I head consulting division at CCTech. My role involves connecting to companies and helping them architect their new products in the direction of digital transformation. We ourselves are building cloud and hybrid solutions for AEC, Manufacturing, Renewable, and Sustainable Energy focused industries.

I have been associated to Autodesk Forge Platform since its inception. And I have been currently collaborating with Autodesk for its future. I'm passionate about technology and love making modular robust, and future proof software systems.

What would I talk today? I would actually talk about, in general, starting from a very top, Autodesk Data Strategy, and then introduce cloud information models, and a very important tool to connect to cloud information models are GraphQL, query language. Then I'll actually talk about the main theme Manufacturing Data Model. There will be some cases with implementation and more applications or demos would be there.

So from the very top, we have seen desktop age, and we have also seen Autodesk Platform Services coming in the cloud movement has started. What is the data strategy? They want to move-- all the products would be moved towards slowly to provide more automation so that it provides more collaboration.

There would be convergence of technologies. They should be able to talk to each other. Different systems should be able to talk to each other.

Granularity would be provided. This set of data are smaller and smaller, should be able to access it through them interoperability. Again, different systems able to interact and talk with each other.

Accessibility from anywhere. You should be able to access the data. So this is the main core, philosophy, behind the data strategy.

Going a little more inside, working with files is painful. Not everybody knows that because the collaboration is not standard. The files have to be stored somewhere, and those are costly. There is no versioning provided, and, yes, the IP of the product, which are making, if it's in a file.

You cannot expose your collaborators. Otherwise, your IP may get lost. So definitely we need a better design to make data management. We want a standardized collaboration model, easier, efficient way to access data and manipulate it, accessing the right data at the right time, and also with sharing the data with the right people.

This is done with Autodesk Data Models. What is all this data model do? It actually solves all of this by breaking up the files into valuable bits of data that is stored and managed on the cloud. So an individual file, which has, a 3D model, for example, it would have a lot of parts and assemblies. Your individual parts and its properties would be saved somewhere in the cloud, and it will be managed on the cloud.

It would help to reduce the complexity of the applications because many people would be able to work on the same set of data. So a single source of truth will come now.

It will also help to increase your productivity by manipulating and accessing only that relevant data. You would have seen sometimes, to make a small change, you have to download your 3D file, a large 3D file from the network, and then modify that particular small instance, and then again save it to that network so that it is accessible to other people. But now with this cloud data model, cloud information model, it will be possible to only change that particular bit of data.

The Autodesk Data Model is also building trust in it, trust in the sense who we share to, and the right version at the right time. So the trust is now built into the system. This should help to reduce users anxiety because you have not unnecessarily or by mistaken shared anything to the wrong person. And so whenever you share anything, it will be only that particular set and not the whole model. So only required people would have access to the right data.

So we are saying this, as cloud information models, it will be, I think as it was launched last year back, media and entertainment, manufacturing, and architecture, engineering, construction. All three have these cloud information models, and they all are available through Autodesk Platform Services.

Why cloud information model? We saw that it is very easily accessible from anywhere. It will break down data sets. It will break down large models into granular subsets, which can be read, written, and even extended to. You wouldn't need a full-fledged desktop authoring tool, and you will be able to connect your ERP systems, cost management systems, and other systems to the data.

So before we go into connecting to the cloud information model, and today, as we'll be talking about manufacturing data model, I would like to go into a quick intro to GraphQL. So what is GraphQL? It's a query language for the API, and it is independent of the database or the storage engine.

If you are a web developer or you have been dabbling with different systems on web, whenever you connect with the system, you mostly would use REST protocol. Now accessing REST, this is a new way of writing your data. So first what you have to do is you have to describe your data, like for example, the project. And then exactly ask what you want, and the result is a predictable one. Because you were interested in getting projects tagline, the GraphQL projects tagline, and you have got exactly only the tagline of that particular project.

So just a quick comparison between REST and GraphQL, so data fetching in REST actually happens through multiple [? inner ?] requests. Like for example, if you want to get followers, first of all, your first request would go for the user, a particular user with the ID. And then once you receive that users ID. Then you will ask for the posts, and once you get the post, you will ask who are the followers on that post.

So for getting the followers, you have to communicate three times. Whereas in GraphQL, you will actually do it through only once. On the top, what you see is a query, where you say the user ID, and you also mentioned last three followers, and you just need names, actually. And once you send it to the GraphQL backend, the server, what you get is exactly what you wanted. There is no extra data which comes out from the server. You're pretty exact in what you want, and also you don't have to do multiple round trips for getting a particular data.

It's very much helpful for a data which has to communicate with multiple servers. It is also helpful for those systems in which the data is hierarchical in nature. GraphQL, that way is a pretty interesting language and a very helpful one and a very performant one also.

So in REST we Have been hearing about CRUD, Create, Read, Update, and Delete. How does that happen in GraphQL? At the end of the day, we want to read data and also modify, update, and delete data. So it should be possible through GraphQL also.

So from the read side, if you see it's a very simple query. It says persons, and you would ask for a name and an age. And on the create, update, and delete side, these are called mutations because you are modifying the data. So there would be functions which are specific, like createPerson, updatePerson, and deletePerson. So there is one query, syntax, and then there is a mutation syntax.

Now that we are equipped with a little bit of GraphQL, let's dive into what is Manufacturing Data Model. Like CIM, the Cloud Information Model, Manufacturing Data Model has been designed, architecturally designed, to satisfy certain properties. It should be granular. It should have easy access. You should be able to read, write, and extend data, and it should be the source of truth.

Now we'll go towards understanding each of these properties. So how will it be granular? So whatever you see in Fusion, like a tree structure of your model from the database when you access through GraphQL, you get the same structure. And if you want only one part or maybe the whole assembly, the GraphQL APIs helps in doing both of them. So it's pretty granular.

What else you can access? So in this, if you have used Fusion teams, you would see their hubs, their projects, their folders, and their components, and drawings inside. And obviously, there are a lot of properties on top of them. So now with this Manufacturing Data Model, you will be able to access your hubs, [? direct ?] inside their projects, their folders, and reach to the components, and even access their properties, for example, material and other things. Similarly you will also be able to access extension properties, revision numbers, change orders, et cetera.

A very interesting part, you will be able to generate step files of individual components. OBJ, STL is also in progress, in the version two. So you should be able to get triangulated models like OBJ, STL for a quick view, or for a quick post-processing to a simulation system or some other systems. You would be able to access a full assembly structure, and it's quite performant. So retrieving a BOM hierarchy from the manufacturing data model is now so easy.

Obviously, the granularity goes down, down to the component level. We can access its physical properties, mass, volume, density, surface area, bounding box properties, which are automatically available. And other than this, you could add collaborators to your project, add users to your project. These are the specific project admin tools. Those we'll get in when we access Manufacturing Data Model.

So easy access, how does it provide an easy access? So the moment you upload your model to Fusion Teams, it automatically has its data structure filled. So what you need is just the GraphQL client. For example, here mfgdatamodel, if you go there, you can actually add your app and add your credentials, and you'll be able to browse your Fusion Teams, hubs, projects, everything.

And while accessing this explorer, it automatically gives you GitHubs and GitProjects, those kind of UIs. Those kind of queries are ready made. You can use, other than the Manufacturing Data Model, you can actually use Postman, Insomnia, or VS Code plugins to access GraphQL database data. And if you are good into code, you can actually jump to the GitHub repo, which is shown here. You can quickly build and access your repo, access your data from the Manufacturing Data Model.

One of the most beautiful part of easy access is your Fusion Teams, Google Sheets, Slack, Fusion 360, anything, now can access Manufacturing Data Model. The only thing which is required is you need to have a query language available for that particular platform.

Moving on to the next property, read, write, and extend. I think read and write is quite understood. It's a manufacturing data. It's some kind of database. So we should be able to query using query, read-- actually using query syntax, and we should be able to write, update, or delete using mutation syntax, using GraphQL.

But extend, how do we extend? So here comes the very interesting property, I would say, custom properties. So these custom properties are feature into the Manufacturing Data Model.

So what you can do with that, now you should be able to attach custom data to Fusion 360 components or drawings, like data-like work, metadata, manufacturing or process information. IDs from external systems, for example SAP system, has a corresponding ID, which you want to map to that particular part. Those kind of IDs can now be attached to a particular part into the model hierarchy. You should be-- I mean it's in progress, but you should be able to access these custom data inside your Fusion 360 product.

A sample of workflow scenario, suppose for a 3D printing, whenever you send a file or design for printing, it would be great if you could have been able to send some information about the job. So that when the 3D printer is able to read that and actually incorporate it, for example, a number of quantities, for example, five, and which material you want to print, so 3D printer software would be able to read the material and the number of quantities of print, and it will do it automatically.

So this gets associated and a particular information can be tied or attached through custom properties to that model. This opens up new avenues.

We'll move deeper into custom properties. So how do you add custom properties to your model? First of all, you have to create a property definition collection, which would be associated to your app.

You can take multiple collections. Once you have your collections ready, then you would associate property definition to it. You can have multiple property definitions in a collection obviously.

Once you have property definitions defined, you can actually set a property on a particular component by linking that collection to the hub. Once you connect your collection to the hub, you will be able to set properties to it. So it's like a company can decide to-- for example, for cost, every part would have a cost. So a company decides that it would create a collection, cost collection, and there will be a property related to cost, and it will be part of every component.

So once this cost gets attached to the whole hierarchy, whenever will be querying that model will be able to get the total cost of the whole assembly. So that kind of possibilities are there, infinite possibilities, actually, whatever you want to link to as custom property. We'll actually see some of the possibilities in some slides coming ahead.

I want to summarize now a bit about custom properties. I feel like this actually, so you go to Walmart, and you're looking at the products, and you see that the product does not have a price sticker attached to it. And instead, you have to look through a book and find out what is the price. Just imagine how difficult it would be and how time consuming it would be.

Today's manufacturing data actually travels in this way. Manufacturing Data Model changes this totally and brings the price stickers back on the product. So whatever information, which is part of manufacturing, would now be able to stay with the product, with that part, with that assembly, very nearest to the manufacturing design.

The last property, source of truth. So with ease of access and APIs exposed, it's like a database, so your manufacturing data model is now a source of truth, and this information can be accessed from different softwares. It brings up new opportunities to connect different systems, very good for system integration people. But its Fusion Themes, very [INAUDIBLE] systems like Google Sheets, Slack, Fusion 360 can access data in the workflow.

So we talked about-- we started from Autodesk Data Strategy and then turning into Cloud Information Model, and we have been talking about what is Manufacturing Data Model. And we also saw a quick GraphQL introduction. Now actually, while you would have got a sense of it, what it means, we can do a quick tour for developers actually.

So, very simple, you have to create an APS app, then you have to have an access to Fusion Teams, definitely should have some models. Once you have these two compulsory things, you either can go to mfgdatamodel-demo link, or you can actually go to Autodesk GitHub, where you can find APS Fusion data samples. If you open MFG Data Model demo, then you're lucky. It has already some graph tables, scripts written, query language written. Query is written, and you just have to press play button, and it will access your data.

So it is as clean-- it may take not more than probably 20 to 30 minutes to reach here. If you are a coder, obviously without knowing much of GraphQL still, you will be able to access the data from the existing queries that MFG Data Model Explorer has. But you want to go a little more deeper, then you can access-- you can clone APS Fusion data samples, provide the required credentials in the index.js, and, yes, npm install, npm start, and you're done.

The moment you run npm start, it has a by default query. You will be able to see it in the terminal the example that you would run. So running a very quick one, it doesn't take more than 30 minutes. And once you have done this round, I would suggest you to go through a quick GraphQL understanding from either how-to GraphQL website or probably GraphQL.org. it will help you to understand more about query mutations and how you can query, passing parameters, and different things.

Now we'll talk about different applications, which this technology or this approach enables. So I've been thinking about, from Manufacturing Data Model what do we get? We actually get a step file with some OBJ or STL models. We can extract thumbnails. We can extract BOM We can extract different custom properties, which we have set.

So using this four things, what are the possibilities? So I started thinking all around, and I could draw a very kind of applications and the areas. So step-by-step, we'll quickly go through some of them.

For example, let's take the first one as online catalog. So online catalog can be created, obviously, even if Manufacturing DM was not there. But the beauty part is that you have the model, which is an OBJ, which is ready and readable. It has thumbnails.

And in any online catalog, you want information. And these information, which you see here, for example, name, category, material, et cetera, they can be part of the custom property. So Manufacturing Data Model is actually your backend. You can actually use it for populating your store, the website, where you can have all of your parts or assemblies, which you are offering for sale, selling.

How does the back-end look like? People in the company can actually be able to upload more thumbnails or more information the moment they access. So this is the way they are accessing Manufacturing Data Model. So when they make modifications here, automatically the source of truth changes, and automatically the website and your store gets updated.

A kind of a quick diagram to show that-- so if you want to add another part, or you want to update a part, you will have to first search through. And so inside Manufacturing Data Model, you have a possibility of searching. And because it's a textual model and the searching is better-- you will be able to search like with volume properties or some other custom properties that you would have actually associated in to the models in your company.

Once your search is done, you can actually select a particular one, and then you can update it. And moment your update happens-- so if it is a kind of a bigger update, so STEP, OBJ, or STL needs to be modified, or it's a smaller one like textual information. Your PIM, your website would be accessing a PIM system or maybe a CMS system, or probably directly through a code.

So as I said, Manufacturing DM is like a back-end. So your code or your PIM system, actually, fetches information and rolls it into a website, which is then published to your website store. You can imagine this for a 3D printing company, they want to publish a lot of models, print 3D printable models. So with all the information and the price and everything, this seems to be very quick way to create the whole system.

Another example I would take is of sales proposals. So this is a real case example where I've seen whenever you have to provide a proposal for a requirement, you, again, actually search through 3D models. You have to remember, actually, you have to remember something similar, which I had actually created for some other client, you then access your model on the file system, on your Windows system, or the Mac system. And then you do modifications, and then you send it for drawings.

But you know now what is possible is? You already have everything stored on Manufacturing DM, which you can actually browse through. You can search through. You can actually create project folders for your proposals. And you can actually populate models from other projects.

So the moment you do that, you have a BOM, you have a step file, notes, cost, and everything ready. You do the necessary modification. And if there are some minor changes or maybe major changes into the model, then design automation would run, and it will create a PDF proposal, a drawing in which you will have the right drawings, and as well as the notes, particular notes.

Now I'd like to go through this once more. Let's imagine you have a part for which you want to associate. If that part is there, then only that note should be present. So this becomes easier now because we are associating notes as a custom property to that part.

So if it is part of the BOM, then automatically that notes would also appear. So inside design automation, we'll access the whole model. We'll access the whole properties of the model, and we'll look for instances of notes. Once we gather all the notes, we'll actually create a [? DWG ?] using design automation and convert into PDF for proposal.

So this enables quite an interesting workflow because we have been able to put, for example, notes here, a task specific to the particular part. Or, for example, there were surface roughness, so you just need to change surface roughness directly in Manufacturing Data Model, and the whole workflow would be easily synced till the proposal creation.

Let's take another example of ERP systems. So most of the ERP systems actually access Bill of Material, BOM. And Manufacturing Data Model readily has BOM available. And if you want to send some notes to the ERP system, that is also possible. And these ERP systems probably would be part of the cost management system. And hence, this also could lead to sending proposals.

Technical documentation, another example. The technical documentation what it means is, for your parts, many times you probably have to create animation videos. Sometimes you have to create a 3D or XR model, or sometimes you have to create a PDF.

So how Manufacturing Data Model actually is helpful here, so we already know OBJ still is available. We can quickly extract from the data model. And we have information tagged to the parts. So just imagine you are able to get this OBJs, and you are able to associate the information attached to that parts, and you're able to see that in the base viewer, either in an XR or 3D.

So no more you have to rely on some other database and then find out through IDs iterate through, that's not required now. It's like in the moment you have a task to your information to the path, which you're utilizing, it's there. So no more iterations required. It should be quick and better.

Similar cases, for example, in your animation system, you want balloons to appear in only on some parts while your animation system is creating animation. So what you can do is, the CAD designer actually attaches a custom property called if-balloons. And it's true and false can be used, and this would help the animation system to automatically decide whether I should be attaching a balloon to it or not. And obviously, this animation system can also use other things like x-direction, y-direction, rotation information so that the CAD designer is able to suggest, and the animation system automatically is able to create videos out of it.

Similarly, one of the same scenario can be used for creating PDFs, which are used for manufacturing. So whatever you want to associate, like again the balloon case, you want to provide some surface roughness to particular parts. You only provide those. And while your drawing is being made, a script actually reads through it and only assigns balloons for which it was asked.

So again, in all of these three cases, what you have understood is that we are now not talking to multiple databases or multiple information packets. We're actually bringing the right information to the right place, and we are able to access it. And if anybody changes that, you know about that change.

So now I have not talked about there are certain properties, like in a standard, dynamic, dynamic app version, timeless, or so. They're different type of properties, different type of custom properties, which you can associate to components and component versions, actually, and they have different lifelines, life cycle, I would rather say. And it provides a very beautiful approach towards attaching information and flow of that information from start to the end and probably again, it [? reading ?] towards.

Another example would be of a simulation system. So whenever you make a CAD model, these CAD models are not exactly compatible for running an FV simulation or FVM solution, Finite Volume Solutions, like CFD. Most of the times you have to remove parts or features, which are of no use or which are of so small that unnecessarily they will disturb the calculations because they are not part of the simulation.

So now we can actually do a very simple thing. We can access it whether it's part of [INAUDIBLE] information or [? not, ?] the [? DV ?] [? stream. ?] So we can say yes or no. And this way whenever your CAD modular-- whenever he associates those information, this information as a step file or as a Fusion file can go or [INAUDIBLE] file can go, and it will actually remove those features. And automatically, we are making a CAD model, which is De-featured. That means no more it has features which are useless for simulation.

So that was a kind of workflow. And this workflow can be used for [? numerical ?] other things, like if you have some expected properties of pressure that has to be achieved in CAD, you can actually keep that into the custom properties. And the CAD person will be able to have this information not in some other docs or somewhere in some Word document, but it's there where he has to optimize the pressure. So it also opens up no new avenues.

This is not very-- but if you're making multiple digital twins, and so obviously you would need a model. So you have a model, and then digital twins also needs data to be streamed from those sensors. So you can actually attach sensor IDs or tracker IDs, and those would be available in your digital twin.

And you could also access link to it. So if you have a plant, and you have multiple walls, so each wall will have a different tracker ID. And each wall would have a link to the IOT-stream. And hence, your digital twin application can benefit from the information, which we can store in the model as custom properties.

Nearing to the end, so what others? There are some possibilities that is coming from the thumbnails and the 3D files, OBJ, STLs, Step, and different custom properties, which people would save in their company. So definitely, I can see two opportunities or two possibilities.

Design for manufacturing system-- so because most of the times if you're designing for manufacturing, you would need a lot of correlations, past correlations. And if this gets populated, we can use definitely some machine learning or some quick queries to estimate costs and problems. And obviously, it would be accompanied by some particular databases and other kind of databases.

The other example I can think of is, as a large language models have been too prominent and everywhere, so Enterprise LLMs becomes a possibility. The multi-modal, one where it's not only text, but actually it's images, or probably, I'm not sure, voice and everything. If people can store-- due to Manufacturing Data Model, if we have a large database storing information, physical properties, manufacturing information, cost, thumbnails, it feels like some enterprise may be able to use those information for creating an app for the benefit of their internal automation. So definitely some possibilities are there

Some references, as I said, to learn Manufacturing Data Model, you actually do not need much of learning. Only if you knew how to query the database using GraphQL, you are good. So these are some of the links, which you can follow. Thank you.