Manufacturing Informed Design API On Autodesk Forge

ANDY AKENSON: Welcome to my presentation today on Manufacturing Informed Design API On Forge. I'm Andy Akenson, distinguished software architect here at Autodesk focusing on industrialized construction.

Here's our safe harbor statement. I'll be making statements about the future development of our products and services in this presentation that do reflect our current plans, but things can change.

If we look at the agenda today for this session, we're going to look at productization for construction, manufacturing informed design, well-formed Revit families, an example of manufacturing informed design with an API, and then looking ahead at what's next.

So looking at industrialized construction here at Autodesk, our mission statement is to deliver new connected solutions and services, enabling the AECO industry to achieve industrialized construction and improve certainty, productivity, and sustainability.

We're out learning from companies leading the way with industrialized construction to make sure that we're focused on the right problems and solutions that create real value. This is [INAUDIBLE] precast concrete facility in Coventry UK. I was there a few months ago, and it was amazing to look out over their production facility. It's a $200 million investment automating the panel from setting and concrete pouring. They also automate rebar cutting, forming, and welding and have over 20 station curing oven panels. This really doesn't look like construction. This is a lot more like manufacturing in action.

So looking at productization for construction, the fundamental problem is that building and design decisions are made in a vacuum without any information about what can actually be made. The workaround is to capture intent to successfully add detail into regular review with all the stakeholders. This is manual, slow, and reactive. The process used in the industry are disconnected, so data cannot be acted on automatically and cannot scale.

Looking at the current building workflow of design, plan, build, and operate, we think that there is a new productization stage in the front of the process. Here we see building products coming in to inform the design. We see a new persona emerging. The actual job titles might vary from company to company, but the job is similar-- engineering building products.

We can now connect to a much broader Autodesk portfolio to bring productization to building design with products like Inventor, Fusion, Vault, and UPCHAIN. Productization for construction is the bridge between our building designs and what we can make to include in those buildings. Fabricators need to prepare engineering models for the assemblies they make a lot of across many different projects.

They need to identify what is standard and what varies and capture the rules to include in those models. What distinguishes this approach from previous attempts at content libraries for architects is that the content is dynamic and not static. Designers can interact with this content and customize it for fitness in their projects because a fabricator defines the constraints they allow to be made. By building out our solutions on Forge with API access, this will enable connecting into automation pipelines as well.

Productization means you can deliver the right information to the right people right away. When using a dynamic product template, an architect specifies the desired inputs to meet their needs for customization. These are used to generate all the needed information into outputs required for downstream processes such as LOD 100, 200 models, bills of material, and renderings for quoting, material ordering, shop drawing, and more. This is all built on a common API so that we can provide end product experiences in tools like Inventor in Revit as well as seamless web experiences with the Forge Viewer.

Now, let's look at an example of a highly engineered product in Inventor showing a sample steel staircase product. Here I'm in Inventor with my staircase. I've got my parts. I've got an iLogic form here that allows me to change things like the height, the width, the rise, the run.

Here I'm going to make my staircase taller. Let's make it wider. And I'll change the target rise to something invalid. You'll see here it rounds it up to the maximum. So those rules enforce the fabrication rules that I have in place.

So change the tread thickness, and we can turn off the riser. All done within Inventor. And here in iLogic, you can see we have some rules that are run to constrain the inputs as well as push down parameters and do things like calculation on the actual rise versus the target rise.

By creating products in Inventor, we're able to create highly flexible models that can contain rules to constrain those options to known manufacturable values and drive downstream automation. For a customer case study of Inventor productization in action, check out the Viewrail story on Autodesk.com.

Now, let's look at manufacturing and form design capabilities. So what has been working well in manufacturing can now be applied to construction and inform building design with the right information at the right time. So connecting design and make-- architects use tools that don't capture fabrication level of detail, which forces subcontractors to define those details for every project. Subcontractors define these details and would benefit from using Autodesk Inventor for these processes. Manufacturing informed design connects these two tools to enable automation and accelerate the process. Importantly for this class, we also provide an API for seamless automation.

If we look at the solution, the product pillar of our solution is comprised of three major elements. The first element is enabling dynamic products for our maker customers. This allows them to define their construction products, including input, rules, and constraints that ensure any requested variations still remain manufacturable.

The second is intelligent design decisions. This allows the architect to discover and view dynamic products, customize them for their needs, include many unique instances as are required, and it makes the "I" in BIM more intelligent.

The last is enabling automated outputs. The maker can extract dynamic product information from the project to do things like automatically creating shop drawings, bills of materials, models, and more. Combining these three capabilities make manufacturing informed design possible for our customers.

Taking a look at our solution architecture for manufacturing informed design, we're building out a core platform service in Forge as well as building on top of existing Forge capabilities to drive the workflow through common dynamic content service. By taking an API first approach, both the desktop add-ins and web application will leverage common functionality.

Going back to our staircase example, as a maker of stairs, I want to provide a template with inputs, rules, constraints to define the construction project. And I want to publish it so that it's discoverable. As an architect designing a building, I need to include stairs. I want to search a template just like I do today, but I want to find one that's customizable in the cloud.

And I want to bring in appropriate stair products for my building design. And as the maker who defined the stairs, I want to know that everything in the Revit project is manufacturable, it is based on what I defined in my dynamic product, have all the information they need to create quotes, fabrication, documentation, and more. Again, built on Forge with an API, we can now drive this workflow and connect to the products and services.

As a product engineer, I have a highly engineered staircase product that I want to make available for architects to use in their design and make sure that they can configure within limits of what can be fabricated. Here we have a manufacturing informed design add-in in Inventor that does just that. Let's see a demo.

Here in Inventor I'll create a new product template, specify the source model, the top level assembly, and project file. Now, I'll pull the inputs out of the Inventor model. Parameters and iProperties are available. I can filter by something like key parameters. I'm going to select height, run, width, tread thickness, whether or not it has a right or left rail, some materials, as well as whether or not it has a riser. I'll add these. These are the parameters that will be surfaced to the architect.

I can provide extents for things like minimum and maximum values and increment. So here in the width, maybe I want to provide a 1/4 inch increment. I can provide user friendly labels. I can go and provide things like if it doesn't have a riser, I don't want to show the riser material. I can also bring in tables to specify rules so that, based on the material, I can provide different tread thicknesses.

And then I can do a low code approach on rules. So we provided various code blocks here to be able to glue together rules. So I want to create a rule here that's going to provide different extents for my width based on my height of my product.

So here I'll bring in the height as an input. I'll provide a comparison operator and say, anytime my height is less than 48, I want to select different extents than if my height is greater than 48. You can imagine all sorts of capabilities that you can do gluing these code blocks together with conditions, with math, and different logic to provide endless possibilities on your input rules to guarantee your manufacturing constraints.

So now that I've specified different inputs and set up my various rules, I'm able to go now to my outputs. And here's what I'm going to publish is available. I can publish a model state or a level of detail. I'll select what Revit category this is going to end up in-- so stairs, we'll put it in stairs category-- and a family name. And I'll publish that. This goes to a construction cloud account and project. And I've created a stairs folder here for all my stairs.

Now that I've published my stairs, I can do the same thing for something like balconies. So here I'll select the source content and go through the same steps for the balcony as well.

So as an architect, I need to include some stairs and balconies in my design from a supplier. I want to know that what I pick will work with my design and be flexible enough for me. Again, with manufacturing informed design, we have a Revit add-in to find, customize, and insert products in a project.

Here in Revit we'll launch the add-in. We'll select the account and project. We'll go to the stairs folder and select the stairs that I published as the product engineer and customize it. And here you'll see all of the inputs that I published are available. I'm able to change things like the height and width of my stairs within the rules specified.

So here you can see that it only goes up to the min and max that I specified when I published. I'm going to create a short version of these stairs for two outside doors, go ahead and insert that directly in Revit at the appropriate level. So put these two entry stairs in.

Now that I have my entry stairs in, I want to create some stairs for the main hall. And these stairs I want to make taller and wider, turn off the handrail and riser. So here let's make it 78 inches tall, make it 68 inches wide. We'll go ahead and turn off the rails, turn off the riser. And here you see the riser material's been removed based on those rules we published. And I end up with a Revit representation of those stairs with the right configuration.

Now, once I'm done adding stairs to the building, I can go and add some balconies as well. So I'll go through the same process, select the balconies, insert a couple of instances into our building. And for some of my smaller rooms, I'm going to create some smaller balconies. So we'll go back to the add-in, change the width, and add those smaller balconies into our building.

Now, as a project manager, I want to be able to see what products are used in my project and produce a bill of materials for every product in the building. I don't use Inventor or Revit, so I can just log in to the manufacturing informed design web app to get access to this. We're using the same Forge API that both the Revit and Inventor add-ins are using for the web app to connect the workflow with the Inventor templates that are stored on Forge.

So now, if we look at the web app, once I'm logged in as a project manager, I'm able to see things like my products, the outputs that I've generated, and insights so that I can see things like the number of products used in my project, the number of variants that have been created, maybe some other project information. I'm able to get access to where those are in BIM Docs. I'm able to see models in the instances. So let's go ahead and open that Revit project I was working on. This has to be in construction cloud, so I'll open that model right off of construction cloud and be able to see all of my staircases and balconies that were added to that model.

I can select them either from the model or from the list here on the left. So I'm going to select four of these stairs, and I can generate bills of material for all four of those stairs. I can do the same thing for my balconies as well. So here in the web app experience, I'm able to completely automate the downstream experience as well as gain project insights into what products have been used.

Connecting these use cases results in much broader solution that delivers significantly more value than each product on their own. We're delivering services that anticipate how adjacent users will access and use some data to create connections, even for things like downstream workflows, like connecting directly to the shop floor in Fusion 360 for manufacturing. Building the right foundational services is key to our success, and providing APIs allows you to focus on your automation workflows, not having to carry along all this extra data yourself.

Connecting workflows is really important, but only if you have the right data. With today's products, services, and platform, there's still not enough of the right data in the Revit families produced in manufacturing tools to be useful in design. We want to improve this in Inventor first with an approach that then gives automation workflows usable Revit families with the right data to be used, just like any other Revit content the architect needs, without having to build another representation of that product. So what does that mean in action? Our product manager, [INAUDIBLE] will walk us through what this means to the architect.

PRESENTER: MID utilizes current BIM exchange capabilities to generate true geometric representations of a product model in Inventor as Revit loadable families, or RFA files. Along with its simplified mass geometry, the RFA file can contain information like OmniClass data, orientation in space, and a few other basic properties like seen here. But we need to go a step further to provide BIM compliant models and data that can be accessed throughout the lifecycle of a project by Revit users like architects, designers, and engineers and consumed by other downstream processes.

Loadable Revit families is the proper way to go to represent a manufacturable product in Revit. But we need to make sure that a file that is being generated by MID's add-ons is as close as possible to the real thing as if it was altered inside Revit's family editor. When you create a family, you are prompted to select the family template that corresponds to the type of element that the family will create. The template serves as a building block containing the information that you need to start creating the family and that Revit needs to place the family in projects.

As examples, a template can be host-based, like using walls, ceilings, roofs, or floors as hosts, or a simple line or face of an element in the project. The templates and the group of properties that follow them play an important role in the proper organization and utilization of elements in a project. But when we take a look at these examples of families created by the current automatic family generator, we can see that this and other important data is missing.

Imagine a simple task as a designer wanting to select an element inside the project and trying to figure out the category of this element, organizing them in a folder structure of the project browser. They might also want to know if a part inside an assembly of elements has a particular type of material or manufacturing information as if it was generated by multiple nested components or using shared parameters. We need to provide options to add this and other metadata when autogenerating the families. This will ensure that MID users can maintain basic and important capabilities from Revit without disrupting the way that it's currently being used.

ANDY AKENSON: Starting with BIM information in Inventor, informing design is only useful if the designer has usable building components and systems. We're looking at how to provide a way for the product engineer to add the right context so that the BIM data is useful in design. We want to make sure that existing functionality makes it seamlessly into the Revit family, things like user coordinated systems and MEP connectors. We're also working on a way to define more BIM data at design time in Inventor, so things like insertion points, BIM categories, and BIM parameters that are mapped directly to Inventor parameters.

When we're talking about well-formed Revit families, we're looking at this in three buckets of work-- the basics, things like insertion points, UCS, MEP connectors, BIM categories, and parameters. But we think we can do better than basics by adding capabilities like family type name, BIM parameter mappings, extensible BIM parameters, instance parameters, and materials, building out then to a best-in-class solution for things like placement plans for hosted families, void bodies, subcategories, and alternate insertion points.

Moving beyond the manufacturing informed design, we see a vision for productization for construction here at Autodesk. We think MID and well-formed Revit data together make productization feasible for the construction space. We can build the foundational capabilities that convert our customers' tools and data into connected workflows. This will unlock productivity, help drive business at scale, and enable process optimization. Architects can now focus more time on building function and aesthetics and less time on designing commodity or repetitive building systems. Fabricators will get more requests for standard products that are known manufacturable and can focus on building and delivering better products and less time engineering every project to order.

Now, let's look at an API example. So what we looked at before with the manufacturing informed design solution architecture tied together the two add-ins from Inventor and Revit in our app via an API on Forge. By providing this Forge-based API, customers and partners can also extend our solution to build their specific bespoke engagement on top of our platform. I'll show a demo of an application built on top of this API, displaying a product catalog directly embedded into a website, leveraging the product templates and manufacturing informed design APIs on Forge. The dynamic content service manages things like access, product templates, and caching.

My fictional stair and balcony company wants to be able to provide a catalog for the product templates published embedded directly into my website. All of this is done in a web app. No service is needed. Just connect to the manufacturing informed design APIs. The login you'll see for the construction cloud is optional. This may be a case where you're working with a customer where you want to give them specific access. You could also omit this and provide access directly on your website page for all of your customers.

So here I'll log into the account. You'll get a list of the projects that have product templates uploaded. Here I have a balcony with the inputs. And I have two stair products, a simple wooden stair and my metal stair that I uploaded earlier. You can see all of the inputs here. You could also edit directly here in this web form and be able to download the resultant RFA directly here in my web app or my product catalog.

All of this was built out on top of our API. This organized into three main areas-- the projects, which allow organization and access control for the products, the product template definition in the products, which include things like inputs, rules, levels of detail, and the variants, which are the instances of a product based on specific inputs and access to any resulting outputs.

So if we look at the project API, from the API demo example I showed accessing the project, there's one endpoint we have right now, which returns a list of projects with published templates. So you may have access to hundreds of construction cloud projects. But we're only going to show you the projects that have published product templates.

Taking a look at the product API, this lets you interact with your published product templates via the API on Forge. So these are the kinds of things you can do with your products. You can publish a new product with all of the product definition. You can update an existing product. You can get a list of all of the published products for this project. You can get an existing product by ID. Or you can delete a product that's been posted.

Variants allow updating the inputs and access to the outputs. So here you can post a new variant, which includes all of the inputs that you want for that specific instance of a product template. You can get all of the product variants that have been posted. You can get a specific variant by the variant ID. Or you can get the output for a specific variant. So in the case above, you could get a Revit family based on a specific variant ID for those inputs.

Now that you've seen what we can do with the API today, let's take a look at what's next. Looking at some things that are next, we're looking at building out an API on Forge with official documentation, support, and integration for things like data [INAUDIBLE] and usage, building out more sample apps to see what you can do with manufacturing informed design, and quickly get up and get started. We're looking at an SDK beyond the basic REST APIs that allow you to work in the languages that you're comfortable in. Looking at potential Fusion Team integration so that you can publish product templates and access products beyond the construction cloud. And we're looking at potential PDM and PLM integrations for things like Vault and UPCHAIN for product template management and downstream automation.

So to wrap it all up, we've covered what productization is and how manufacturing informed design is an important part of our industrialized construction strategy here at Autodesk. Just connecting workflows isn't enough if there isn't enough data. We're looking at how we can get the right data connected across tools, services, and the Forge platform with well-formed Revit families.

I've also shown you an example of one of the many things that can be done with API access to manufacturing informed design with a demo app and a tour of our API. With that, reach out to us if you'd more information on manufacturing informed design here at Autodesk. Thank you.