How Automated and AI-Powered Structural Engineering Accelerates Building Design

DAGMARA SZKURLAT: Hi. Welcome, everyone, to our class, "How automated, AI-powered structural engineering accelerates building design." My name is Dagmara Szkurlat. I'm a Senior Research Manager at Autodesk in London.

And my background is actually mechanical engineering and software development, but over the last few years, I've been focusing on research in generative design and the AEC industry. At this point, I also wanted to give a quick shout-out to my whole research team, who's really made this project possible, but in particular, Kosala, Gareth, and Sebastian, without whom none of this collaboration that we will talk to you about today could have happened.

TOM KOMON: Hi. Tom Komon, Design Technology Manager at WSP Canada in the Buildings group. Our primary focus is on structural, mechanical, and electrical, but previous to that, I spent around 15 years in the BIM space as a structural BIM modeler and manager.

DAVID CARNOVALE: And I'm David Carnovale, Digital Solutions Manager for WSP. I'm, similar to Tom, working across structures, mechanical, electrical to implement digital solutions in the Property and Buildings team and just elevate WSP's position in that space, including research collaborations like this one. By my background, I'm a structural engineer with 10-plus years of experience.

DAGMARA SZKURLAT: Right, so before we get started proper, just need to make you aware of this safe harbor statement. Please, take a moment to read it. If you need to pause, pause here. Basically, it kind tells you to not make any purchasing decisions based on what you will see, and that's particularly important given we will be talking to you about research a lot here.

With that out of the way, let's jump right in. We're going to give you some context both from the Autodesk side and the WSP sides to this whole collaboration, and then we'll discuss a little bit about our collaborations timeline. We also want to address some of the promises and fears around technology, such as the one that we'll be talking about today, and finally, we'll wrap up with a few ideas on what's next from the Autodesk side.

Right, our story, and Autodesk's, starts some four years ago, when a group of us at Autodesk Research started considering if we could bring over concepts from generative design and manufacturing to structural engineering. Why structural engineering? Well, at the time, Autodesk was really leaning in to the promises of technology and helping connect workflows throughout building design, from architecture all the way to construction.

And we, having spent some time learning about the industry and our customers in AEC, really felt like engineering was key to making that vision true. We saw engineering as the connector, the translator between architectural concepts and construction plans. Of course, that is why the E is in the middle of AEC, right?

This is where Project Kratos started, and that's just our codename for it, if you will. We set off to build an engine capable of creating structures from floor plans sketched out in Revit and a few extra pieces of information that are saved in JSON file. These included some details like required building type or desired structural material. An engineer could, with this engine, quickly get a sense of what different options were available for a given building.

We initially looked at low and mid-rise structures, and then we slowly expanded to high-rises, different structural systems, various types of loading conditions. We would optimize the grid layout, then we would size the column slabs and beams. We mixed different interdependent algorithms for the various subsystems and worked to make the calculation process as fast as we could. We also looked at different ways to visualize the results, trying to figure out what level of detail and what kind of metrics would be most helpful for engineers to analyze the solution.

Now, in the title of our talk, we mention AI, and at this point, I must explain that our approach was not of the sort used by technologies like ChatGPT. We did not take a bunch of existing buildings and try to learn directly from them, and we made this choice because we knew the best design today is not the best design tomorrow. So instead, we ended up mixing expert systems, generative design, and machine learning together, but structural engineering being one of the oldest engineering disciplines, it has a lot of existing domain knowledge, so we capitalized on that by creating a series of expert systems.

Then we combined generative design with those expert systems to not simply automate the creation of a structure but, crucially, to optimize the designs, too. And finally, we used machine learning to predict solutions of repetitive calculations and to look for patterns and solution clusters. This really helped us reduce the generation time.

Now, we hoped that by building the engine up in this manner, its users, structural engineers, could customize the expert systems and override various inputs like costing models, section and material databases, and create really novel solutions. So with that brief intro to the technology of this talk, I will hand it over to Tom now, who'll give you some context from the WSP side.

TOM KOMON: Thanks, Dagmara. I wanted to give a little bit of context toward where we're coming from at WSP and, with that, give a little bit of a brief introduction as to who we are, what our team is, and where we fit within the large company that is WSP. Our Digital Solutions group is split between Digital Delivery and Design Technology, and our team develops workflows and tools for the structural, mechanical, and electrical disciplines in Canada.

Established in 2020 after leadership realized the necessity to invest in digital transformation, we were given a budget and a unique opportunity to make change. Even within a company of WSP's size, this was not usual practice, and it gave us the opportunity to explore new ideas and solutions to bring to the business.

If you go back one year further to 2019, at Autodesk University, generative design was buzzword of the conference. And I know Dagmara's going to go a little bit into the timeline around our relationship and how we met and our further workings together, but I wanted to give a little sort of context to where we first sort of were introduced to generative design. Leading up to AU in 2019, AI was really just considered Skynet, and generative design was what you see on the screen, essentially an architectural phenomenon for space planning and freeform complex designs.

We didn't know how we could apply it to our projects, but we did understand the potential benefits. Initially, it was productivity. We could run the same number of options or studies in less time, which is great for our bottom line but wasn't directly impacting the overall project. Optioneering wasn't enough. The designs needed to be optimized, and it needed to be done earlier in the design timeline.

Throughout a project's life cycle, there's a crucial period at the beginning where design choices have the greatest impact on the final product, not just in its finished state but also operations. As a project moves through the life cycle, the resistance to change and the cost of change increase, resulting in the potential for change to decrease. Structurally, it's very difficult and cost prohibitive to take on too many desktop structural rapid optioneering studies at concept stages.

Engineers usually feel they know the answer in most areas and building based on conventional building technologies, and they study one or two targeted unique areas of the building. This also happens after crucial architectural designs have made limiting the ability to optimize by constraining the design. We saw generative design as the way to evolve the structural design earlier in the impact zone being included in those early stages not just in design, but also in planning. If we could present those optimized options to the architect and client early enough, could we influence their decisions regarding shape, size, and material?

Another buzzword, and a very meaningful one in the last few years, has been carbon, and specifically in AEC, embodied carbon. This is where we believe generative design and AI will have the greatest impact on how we design buildings. In many cases, architectural programming have baked in certain structural solutions, but as Dagmara mentioned, the best design today is not the best tomorrow. The baked-in solutions are there out of necessity due to time it would take to go back and forth between architect and engineer. The practice of utilizing rules of thumb does not make optimization a priority, and it is hard to argue that it is clever or efficient.

The stats on the left are indicators of where we currently are and what is possible. In a recent report on the AEC industry, we contribute to over 37% of the global carbon emissions, from a construction and design perspective. Based on our own benchmark studies at WSP, the average embodied carbon for mass timber construction is almost half of steel. If we had the ability to present different material options earlier enough in the planning stage, there's no guarantee that it would be selected, but it doesn't mean that it wouldn't, either.

The goal is to promote awareness of the impact of early-stage designs on cost, carbon, focusing on the structural artifact. The graph on the right shows the carbon reduction potential on any project. Obviously, building nothing or less would have the greatest impact on our business, but we are in a service where we need to provide our designs. So where we can most impact is we can be clever and we can be efficient in our choice of materials and technologies.

None of this is new, visionary thinking. Structural engineers are aware of the change they can make in these designs, but project constraints, in most cases, make it impossible to achieve this. This is the reason we were interested in generative design, Kratos, and AI-powered structural engineering.

Something I wanted to show briefly in this slide deck is that we had a parallel experience at WSP as we were working with Dagmara's team on creating a tool for a client where we wanted to demonstrate the-- or provide some insights around the capabilities of using different material systems and what that could mean to a project, both from a cost perspective and an embodied-carbon perspective. While not generative design or AI, it was just meant to be a conversation starter that could lead to potential optioneering which previously wouldn't have been considered. It was released this past summer. If anyone's interested in playing around with it, it's available to everyone. As happy as we were with that final product, it was obvious how much of a need there was for a more robust tool.

DAGMARA SZKURLAT: Thanks, Tom. So with that context established, we'd like to tell you more about our research collaboration itself, and the title on the slide will quickly become obvious, as to why we chose it. Right, so we actually worked together in earnest for about a year, and this was triggered by some initial conversations at AU 2019.

So though our Autodesk Research team was pretty damn great at the algorithmic and technical side of things, there was a critical aspect to this whole project that only working with actual engineers could help us get right. This was understanding how structural engineers were even going to use this engine that we were developing. So to paint a little bit more detail of how we got to understand that better, let me walk you through this timeline you see here of our collaboration in a little more detail.

So as I mentioned, we first met at AU 2019 at the Idea Exchange, which was organized by the Autodesk Research Community. My team was running a VR demo of the generative structural engine. In the demo, we showed how the solutions could be explored in an immersive environment or even regenerated on the fly, because, say, maybe you're having a conversation with the architect, and they're like, you have to move this column grid because we need a bigger bay here and more space. So in VR, you could actually try that out and get some feedback from the engine on cost and carbon immediately. Do you remember that meeting, Tom, by the way?

TOM KOMON: I do, actually. Probably my-- you know, what I was looking for was a free T-shirt, because at the time, you guys were handing out a lot of swag for any of these research experiments. But also, as the title slide said, you guys had me at VR. You know, any sort of combination with structural engineering and VR, you had me hooked right away.

DAGMARA SZKURLAT: And we didn't even have very good swag, I would think. Research never had swag, I'm sorry. But anyway, Tom and David still reconnected with us at the virtual AU 2020, and again, this was through the Idea Exchange. And again we couldn't give them swag because it was all virtual.

However, at this point, our engine had really advanced, and now we were increasingly keen to understand how to build an interface around it, and especially one that would help engineers evaluate the proposed solutions. So from our conversations at AU 2020, it really started becoming very clear to us that we both wanted to collaborate more closely together. However, the tricky part, of course, was figuring out all the practical details, agreements, legal, and that sort of thing, so that took us a little while.

Finally, with the legalese over, we spent the next two quarters meeting regularly to discuss various concepts about how this engine we were working on could be leveraged and what aspects was WSP most excited about. Tom and David also graciously spent the time to provide us with real massing models to test the engine on. They, of course, stripped them of any specific details.

And we went deep in our conversations on a number of topics. One key one for us in Autodesk to understand was at what stages of a building project Tom and David saw themselves leaning in to this kind of technology for. And here, I'm going to hand over to Tom again to share a bit about how he saw things and maybe, especially, more about that vision of how this kind of technology could unlock perhaps even new businesses at early stages of design.

TOM KOMON: Sure. Thanks, Dagmara. I think a major thing that happened was Dave and myself were transitioning from working on the structural team, you know, being an engineer, being a modeler, into this sort of design consultant role or design advisory role for our teams, so we were obviously excited to have left sort of the lawyers behind and really get into the nitty-gritty of the technology and how we could utilize it. We knew we needed to lean in on those early insights that would have had-- that we could have at the planning phase impact.

But in addition to that, we started thinking about other business opportunities that could be available with this technology, like TimberX. Could we develop solutions in the form of add-ins and plugins, similar to what you're seeing today with ChatGPT? Shifting our role in the project from engineer/modeler to digital consultant, in addition, we started thinking about the entire design life cycle. Dave, maybe this is something you could touch on?

DAVID CARNOVALE: Yes, thanks, Tom. Yeah, definitely, I think it's very easy to think of those applications for something like this, at the schematic stage with the early insights. But one of the things we definitely wanted to explore in the collaboration was where that value does lie as the project increases and as we increase accuracy as the project goes on. You know, as engineers, we we're always trying to manage budgets and schedules, leave as much of the detailed design as late as possible so that we're adapting to changes and not necessarily burning our budgets.

So what if we can explore ways that we can have an AI engine that can kind of go along with us through that process? So instead of having to run the risk of repeating complex analysis that's very labor intensive, instead have the AI engine do some of that work for us and give those insights to the architect as we go on. Definitely very attractive to me, and definitely something that I think would present a business opportunity to most engineers out there as well.

So what that might look like is, at a very early stage, as it's shown on the left of the slide here, you're dealing with global optimization of the full geometry of the building. But as you carry on, your studies are getting more detailed and more localized and also more regional in terms of the context of the design that you're carrying out. So you could have very accurate design at the kind of middle stages of a project, but somewhat semi-approximate analysis and somewhat local optimization, and then as you get into the final stages of design, full, accurate design of very specific single elements.

One other thing we discussed that was interesting in our collaboration was having workflows that can take what you produced at the schematic stage of using Kratos and inject that into the BIM model for production. So you are carrying that process through the life cycle. We're also injecting into FEM models for more accurate analysis as we get to those final stages of the project.

DAGMARA SZKURLAT: Thanks, David and Tom. I definitely couldn't have said any of that better myself. So after all that, following months of discussions at this point, we, on the Autodesk side, were eventually ready to come to the WSP team with some more concrete mockups of interface ideas, and in this situation, we actually focused just on that schematic early design phase because we needed a starting point, quite simply. So my colleague Sebastian ran a series of workshops trying to discern the details of how to make the human-AI interaction most effective. And one thing that kept coming up was this topic of trust here, and again, I'll pass over to David, who will walk you through some of the key points that we discussed in those workshops.

DAVID CARNOVALE: Yeah, thanks again, Dagmara. This was a very fun part of the collaboration for me, for sure. And in order to understand the output of any system like this, whether it's AI or whether it's an FEM model, an engineer needs to be able to build a good understanding of what the tool is doing and have transparency on what it's being provided-- what the engineer is being provided from the tool.

So one of the many items we discussed in the collaboration was ways to provide that transparency in a user interface and user experience for the AI engine. So we talked about things like the engineer being able to set custom goals and custom constraints to target based on the condition, and also being able to very quickly sort through and filter through the options that the engine is producing, to eliminate those nonviable solutions that just shouldn't even really be considered, going as far as doing things like being able to pin components of a certain design that the engine generated that were feasible and, you know, that the engineer liked, but then allowing the AI engine to continue to kind of learn from those areas that have been pinned and keep kind of generating that optimal full-building solution. This includes ideas like not only just being able to view the generated results in real time, but also being able to invite individuals into that space, so to speak, and work collaboratively in reviewing those results, and the engine also providing instant feedback of where there's issues that might arise as these changes and things are happening.

This next slide here was an example of something that was implemented into the engine that came directly from our collaboration, so, similar to what I was mentioning on the last slide, rather than validating the whole building and a whole, optimized solution in one go, it can be very unfeasible for us to be able to do that and just really have confidence in the result. So we talked about being able to group the building maybe by floor types or by architectural program and do more local optimizations on the grid for those conditions, even going as far as splitting the floorplate into different areas. As you can see, the Autodesk logo here makes for a rather complicated building form, so being able to split that down and optimize locally and review those local optimizations individually, allowed the engine to overall produce a more optimized result than the full building, which I think was a result that we were all happy with and excited about through the collaboration.

DAGMARA SZKURLAT: Yeah, that was definitely a major point for us, and kind of a turning point in how we were thinking about the engine altogether as well. So thank you so much, David, for sharing that. Now, our collaboration came to an end at that point, roughly around last year's AU, actually. But aside from the details related to the Kratos project specifically, in our conversations over the course of the whole collaboration and even a little bit before or after, we touched on some more universal AI automation topics.

David and Tom agreed to share some of their points of view on these today, in this bit of a mini panel format that we'll try out in a minute. I have three major questions for them, and I think many of you watching may have asked yourselves one of these at some point. So my first question is, having spent so much time exploring this kind of tech with us, how do you think an engineer's role will evolve to incorporate AI?

DAVID CARNOVALE: Yeah, I love this question, especially as someone who's moved from hands-on engineering calculations to working in full-scale building analysis and design models to now working in the digital development realm over an 11-year career, it really shows how quickly these things are advancing and how much evolution there is in this space. You know, and one thing I think we all can hang our hat on is that technology is not going to slow down, and so those who are able to adapt and find ways to introduce new technologies into their workflows will get ahead. And like we talked about earlier, it's all about building trust and leveraging that technology where it's intended and for the right purpose.

So in terms of some things that could happen in that evolution of the role, as we've discussed at various points, maybe the engineer's getting more and more involved in option-generation phases with the architect at an earlier stage, and that presents a business opportunity almost pre-schematic design. I also see the engineer being able to add additional layers of insights to the architect and building owner as the project goes on and as they're making decisions that could have large impacts, especially on the cost, embodied carbon, and advanced materials, like we've talked about. I also foresee that as our design advances, our adaptability to those changes will increase as well, as discussed earlier.

However, that all being said, every engineer knows the devil is in the details, and while there could be an evolution of AI, not Kratos AI, but other AIs to mine all of your project libraries in a firm and pull out similar details and kind of suggest those details on the project that you're working on, there still will be that component of an engineer making sure that everything is coming together.

But forget what I have to say. I actually asked this question of ChatGPT as well, just in preparation for this conversation, and I'll just read out or kind of paraphrase what it said here. "But while has the potential to enhance the work of structural engineers in numerous ways, it's important to note that human expertise will remain critical and crucial. Engineers will need to understand AI systems, interpret their outputs, and make informed decisions based on AI-generated insights."

And it carries on to kind of indicate the changes in roles and expertise that a structural engineer might experience. So along the same lines of what I'm saying here, so the structural engineer is not going away. But to a degree, the function and how we kind of deliver that role or fill that role on a project may evolve, and I think that's exciting stuff.

DAGMARA SZKURLAT: Well, we really hope so, too. And it kind of dovetails nicely into the topic we've already touched upon a little bit, you know, around trust, but it's this question of, well, how are you supposed to trust and sign off on something that an AI generates?

DAVID CARNOVALE: Yeah, and you know, I think a lot of it comes back to that transparency and the UI discussions that we had in our collaboration and earlier in this talk. As with any current design office, there's various practices in place, procedures, quality assurance checklists, peer reviews, et cetera, to give a stamping engineer that trust that what the junior engineers or intermediate engineers are doing is to the correct standard and that the tools they're using are producing the right results. You know, we've even all developed probably very simple validation calculations that we ask people to produce along with their models.

I see it being no different in this case. It's just having those processes in place that allow the stamping engineer to understand what the AI is producing. I'd like to add here as well that since the AI engine Kratos that we're talking about is based on direct code calculations and not simply generative, I think that makes the validation exercise that much easier and that trust built that much easier.

The UI could be constructed in such a way that as you've reached your final solution of the project, you could select and view the elements, view the detailed calculations of those elements, and again, build that faith. There could also be things like global building level, say, flow-of-force diagrams or load-path diagrams that the UI could spit out for the engineer to, again, understand that the way the AI has put the building together makes sense. There could also be things like integrations with Autodesk Robot to perform more detailed calculations in platforms that the engineer trusts. So, yeah, all that to say, using AI and other tools to automate monotonous and repetitive tasks will also give the engineer back some time to help perform those validations as well, so I think there's a lot of opportunities to build that trust and then be able to stamp the project, with AI being a key component of how that project comes together.

DAGMARA SZKURLAT: It's an optimistic view, but one that I definitely share, for sure. Right, my final question, of all the possible benefits of AI what do you feel would have the biggest practical impact on the industry?

TOM KOMON: Thanks, Dagmara. You know, we've obviously talked about the impact on decarbonization. You know, globally, a lot of AEC firms have made promises around delivering "net-zero embodied carbon" buildings. Without the technology, without AI, it's going to be a very difficult task.

So one of the other impacts is just accessibility to the tools. As that grows, the impact is going to grow and hopefully have that positive effect. Dave mentioned the impact that it's going to have on jobs and engineers, in particularly as they shift from their traditional way of doing things into this newfound way of hopefully having this trust in this solution that's going to help them make those proper choices as they continue to design buildings.

But outside of that, one of-- probably the most practical impacts it's going to have, and as we increase the accessibility to the tools, it's going to have the ability to reuse data that essentially is our container of experience and knowledge within our firms. As this industry moved or transitioned from flat, 2D Autodesk drawing-- AutoCAD drawings into BIM models, the data retained increased exponentially. We built these large data-rich models, but at the end of the construction phase, in most cases, these models just sit on networks, BIM360, AEC, whatever CD you use, never really to be opened again.

So I think AI is going to allow us to reuse that data. Similar to the way ChatGPT has these large language models, let's turn these datasets of BIM information models, to then enhance our experience when we're designing new buildings, not just to reuse but also to learn on previous experiences. Imagine a Revit assistant that is making recommendations or completing very large repetitive tasks that previously needed to be done manually by the modeler or engineer. All of this is to say, and something that Dave mentioned briefly already is that AI is going to give engineers and designers back valuable time that they can use to optimize, optioneer, explore other solutions, and at the end of the day, deliver better designs not only to their clients but also to the environment.

DAGMARA SZKURLAT: Very well said. Thank you so much, Tom and David. So hopefully, that was some really great food for thought for everybody, and I'll just wrap up here with a few words from us on the Autodesk side around kind of what happens next.

So for starters, I'm really pleased to say that all of this research we talked about has made its way into the hands of the Autodesk Forma team. And though, of course, I can't talk about any specifics or timelines, I would like to point you to their talk "AI-Based Total Carbon Analyses." I think you'll find that quite intriguing if you've enjoyed this session.

From the research side, we've wrapped up the research on the structural engineering automation piece itself. However, something that is really top of our minds is this issue of renovation and recycling, and we could see some really interesting applications where we might be able to build on top of some of this structural AI research in that space. So who knows? We might be looking for some help in figuring that out in the near future.

On which note, I would love to invite anybody who is not yet a member of the Autodesk Research Community to please join. It is a great place to share your feedback and influence the Autodesk experience as well as the Autodesk developments. You will engage with Autodesk product managers, designers, and also folks from Autodesk Research like myself.

And then who knows? Perhaps one day you'll find yourself in the middle of a whole involved collaboration the way Tom and David have with us. So thank you very much for listening, from the three of us.