0:00 All right, I recognize it’s almost lunchtime and we’re the last to go, so thank you for giving us attention for a little bit longer, and we’re going to get started. So this session is modernizing engineering design processes with computational tools. We’ve heard a lot so far about how computational tools are helping product design, and we’re going to take a little bit different approach, we’re going to come from the viewpoint that the AEC industry, so the architectural engineering construction industry, doesn’t quite have a sophisticated computational tools stack for the type of workflows that we have, and so what we’re speaking to more is the internal building systems design, so electrical, mechanical, plumbing systems, that type of stuff.

0:42 Our presentation today is going to cover our conversion of a traditional design tool into a computational system for efficient data handling, automation, and optimization. We’re going to focus on a particular tool for our refrigeration systems design, and we’re going to highlight our methodologies, the resulting standards, and the advancements that allow for optimization in our designs. I am not presenting by myself today, although my slide isn’t going over, so with me is Dauphin Flores, he’s our lead computational engineer, my name is Sha Turner, I’m the director of innovation and research at Henderson Engineers, and let’s get started.

So, general flow, I have why modernizing engineering tools is important, how we achieve this modernization, and then what steps we took internally at Henderson to sort of set ourselves up for this capacity. All right, jumping right in, so the one thing we all want is like the perfect end product, right, we, we want the house that’s fully built, the car that’s beautiful and polished, and that’s tough. So in the AEC industry, what we think about, at least that is, right now, is how do we apply AI to our designs, and modernizing our tools establishes a solid foundation for those objectives.

2:10 It also unlocks immediate benefits of efficiency, productivity, accuracy and precision, so you get to bake all of that in when you start to apply computational design principles to these engineering tools. It also, with the automation, brings out improved reduction of techn logical manual labor, so in the engineering calculations that’s a pretty rote thing, we know how to do it, it’s all physics, oh, we do that a lot repetitively, we ask our engineers to do that, so taking that manual labor off of them hopes to give them just more time back to do the cool stuff instead of the data entry stuff.

2:48 So once we have this standardization of modernized tools, we can advance to the next level by unlocking visual data visualization and analysis, and then that would lead us into the final layer where we can do things like multivariant optimization, generative design solutions, and even using AI, ML, to predict future design possibilities. I, I have to say, after watching Mateline on the KPF thing, there’s a lot of parallelization that the, a, industry doesn’t have right now, it’s very serialized, you have to do these steps, and so these types of things aim to build a system that would allow us to work more closely in that sort of generative space.

3:33 Okay, so how to get there, I’m going to start from the top layer and go back, backwards, like a three- layered cake, so, food, the top layer is where users interact with the tool, typically indirectly or directly, so you do this without consciously engaging in your underlying systems. A good example of this in the building space is you go into a room, it’s got an automated lighting control system, you’re not going in there and like flipping the switch, and you know, saying that hey, this light is on in this room and it’s occupied, that’s just happening, so we expect the lights to illuminate upon entry, and see, let’s say the status displayed on a dashboard somewhere.

4:13 That’s a pretty basic, like, user workflow, I want to go in there, this happens, and come on out, we don’t think about, gosh, I got to go in there and touch two wires together to get the lights to turn on, or go press this button that says that we are in that space. So what happens, I feel like, is the foundational systems that we look for in these sort of advanced systems is we don’t tend to ask ourselves like, what systems support this functionality, we just experience it and it, it goes along with our day. Similarly this happens with AI solutions, there’s a lot of noise about, you know, it’s very easy, just give us your data and AI happens, and in magic, but we tend to not consider like everything that goes behind that.

And so in our house analogy here, this is what we’re going to call our final layer, our house is, is the AI layer, there’s the jump the shark there, and then we’re going to talk about the, the systems that support that, so our electrical, plumbing, heating and cooling systems. So the next layer in the middle there is what we’re going to call the organized data layer, just as our electrical, plumbing and mechanical systems enable the flow of electricity, water and air in the house, the organized data layer supports the functionality of that AI layer, basically being a pipeline for the data flow from the source to the endpoint, and it includes all of the intermediary processes there.

5:37 This space, when you get to here, is where we feel like a dedicated data team is essential, without actively collecting and organizing data, the contributions of data scientists, data architects, and data analysts becomes significantly less effective, they rely on that organized, structured data that’s thought through. And then we get to the bott, bottom layer, which is sort of the genesis of what we’re talking about today, and that is our modernized tools, so for our analogy here, our electrical, mechanical and plumbing systems, in order to be installed, you have to have a foundation, you have to have structural framing and all that, otherwise they have nowhere to go, nowhere to start, in order to distribute to.

6:16 And so that’s where our tools are coming into play, to form that foundation for data collection, and an important thing here is understanding what data you need, how much is useful, and where the sources is crucial, I’d also say how it’s structured is important too, and that was the key motivator for what we have, a yearslong projects of modernizing our engineering tools, and we’re going to focus on how this modernization establishes the groundwork for achieving automation, optimization, and analysis.

6:50 Okay, I’m going to do some quick defining, everybody has different definitions for things, so we’re going to talk about a tool, and essentially it is what we’re calling business logic and workflows, so that’s the mathematical logic, the instructions, and the sequence in which these operations occur, those are super critical, dependent on your discipline and things of that nature is how you apply those, and everything else builds upon this. So I started with this cool spectrum that I used PowerPoint to build, and then adding more detail, on the left side we’re going to say we have equations in logic that make up this spectrum, then on the right side, side, we have the UIUX and the underlying code, so this is a super foundational complete tool structure with the essential components.

At Henderson we are fortunate to actually have a full stack software development team, but they focus on our business operations tools, they don’t focus on building engineering tools, so what we tend to do is use Excel because engineers like Excel, and when we develop tools we just say, here engineer, go make a tool that does what you need it to do, and as you can imagine, it’s faded out over there, the further you get out over your skis, or outside of your domain expertise, you really start to dabble in what you’re doing instead of being an expert, so you lose following best practices and things of that nature.

8:15 Alternatively, if we just asked our software engineers to do it, they are very good at the UIUX and the underlying code, they are not great at the engineering principles, again we’re not saying either party could or could not do this, it’s just that that’s not where their domain expertise lies. So what we did is introduced computational engineers as a discipline, so using computational thinking, computational design principles, as the foundation of their expertise, and what that did is fill in our gap so that we could create an optimal team. All right, that was fast, I felt like, maybe not.

8:54 So I’ve kind of talked about the why and the how of modernization, I’m going to invite up Do Flores, our league computational engineer, to talk us through what steps we’ve took to implement these changes. Dolin, so let’s just talk about how we went about the modernization of our tools. First I want to mention the current state of our tools is that basically all of our tools for engineering are based in Microsoft Excel, and Excel has been, been the platform of choice for a long time, and kind of for good reason, although you may chuckle at it, it is flexible enough to handle a large variety of engineering calculations, and you can see the screenshot on the side here is from a refrigeration engineering tool that we’ve used on thousands of stores for our biggest client, which is Walmart.

9:56 Excel is also reusable, so it can be templatized, and that reduces the amount of work that’s repeated each time we encounter a similar situation, and it’s also been the de facto standard tool platform in engineering for decades, because it’s accessible enough for the disciplined engineers to create the tools that they need without requiring the support of software engineers, and it has the capability to handle more complicated situations through the use of BBA macros. But speaking of those capabilities, here’s a sample of some of the VBA code from that same tool, and you can start to see how some of the apparent benefits of you using Excel are really limitations.

10:54 We talked about the accessibility that allows anyone to use it, and that’s convenient, but the problem is that anyone can use it, so many of the issues that we’ve encountered are the result of not having real software developers involved, because non-programmers tend not to follow programming best practices. So some of these best practices include reliability, which is, you know, crucial aspect of programming, needing to do error handling, and a failure to implement, implement, robust air handling results in frequent crashes, and when you combine that with a lack of proper code testing, you just end up with a very fragile system.

11:50 Other best practices that are not practiced include naming conventions, and as you can see, commenting your code, and this lack of documentation becomes a major issue when you have over 12,000 lines of code in a single program that been cobbled together by numerous authors over a 20e span, and you get to the point where none of those people who have put it together are at the company. And for a sense of the scale of this problem, this is one tool among over 300 that we currently use for our engineering. So basically, Excel is not an ideal method for storing decades of institutional knowledge, which includes the business logic that we use to execute thousands of projects every year.

12:47 And if we really want the fancy house that Sean was talking about, that represents AI augmented design tools, we need the ability to, to access our data, but Excel’s inherent data isolation leaves our data trapped in individual spreadsheets. So in order to reach the potential of what those tools can be, we must be unburdened by the Excel spreadsheets that have been, thank you. First we have to build a foundation for our house by modernizing our engineering design tools in a way that ensures data accessibility and interoperability.

13:32 So we began by working with our MEP discipline experts who know how all of the current Excel tools work, and are versed in the specific discipline engineering principles and equations that make the tool functional, and we used a web-based whiteboarding app called Meo to derive the business logic from that engineering design tool, and to put it in a format that visually represents the workflow and the logic in a highlevel flow diagram, so this simple format allows us to capture the essential details, which are the inputs and outputs of every operation, and we are able to define the critical paths of these workflows.

14:25 So we applied the principles of comput ational thinking to all of the information that we collected. First we decomposed the convoluted tool into smaller and more digestible subsystems, we identified patterns within the workflows, the calculations and the data, then we abstracted away different layers of complexity to find the simplest form for each component, and finally we design the logic of our new, new tool in a more modular and efficient manner. So what did that actually look like, our computational engineers broke down that highlevel flow diagram into individual atomic modules, where we mapped the connections between each module in a graph database, and the result is a more polished version of the business logic that we derived from the legacy tool.

15:29 From each of these modular components, we created documentation with details about their operations and their relationship to other modules in the system, and then for each data variable we use throughout the system, we added extensive information such as the units, the maximum and minimum values, and the decimal precision required. So as we built out this detailed document ation of the equations, inputs, data variables, business logic and the workflows, using a graph database allowed us to track how data is used and modified throughout the system, so for example, we can zoom in to a single data variable and see all of the modules that reference or update this variable, which allows us to track the cascading effects of making any changes in the tool, and to see how other tools and other disciplines are connected and affected by each other.

16:34 So then we handed this documentation off to our software engineers, who developed our new tool in our native environment, using all of the information we provided helped them write their unit tests, and this allowed them to begin development without needing any specific discipline knowledge. So in conclusion, we think that modernizing engineering tools is an important first step to enable more advanced design methods, including the use of AI, which, as we’ve heard today, is where the architecture industry is already heading.

17:20 The process of modernizing these tools requires the use of computational thinking, therefore we have established computational engineering as its own discipline, which may sound obvious to everyone in this room, but in the AEC industry it’s important to set that distinction from the traditional disciplines for MEP, and we’ve created a framework that allows the experts to remain in their respective domains as we work towards a better engineering design process. Thank you.