Building in the Clouds: Uncovering the Transformative Power of Custom-Made, Cloud-Based Tools Through the Asset Generator

NURIA ESTIVILL MANZANARO: Welcome, everyone, to this industry talk, a session called Building in the Clouds, a session where we are going to uncover the transformative power of custom-made cloud-based tools through the Asset Generator, a digital tool developed within Arcadis. So we are three members of the Asset Generator team. And first of all, let's go for some introductions. Alan.

ALAN LEVY: Thanks, Nuria. I'm Alan Levy. I'm a Senior Engineer at Arcadis. I've been here about 17 years. And I primarily focus on the design of wastewater treatment facilities and pumping stations, typically doing the design and construction phase of those projects. I'm also involved in Asset Generator, as far as the design automation aspect of it is concerned, and I also work on the plugin development for that product. Chirine.

CHIRINE CHIDIAC: Hello, everybody. My name is Chirine. I am a Water Engineer at Arcadis. My design work has focused mostly on wastewater treatment and conveyance facilities, but I also do a lot of stormwater regulation work in New York City, where I'm based. With the Asset Generator, I am one of several product designers. And I also help on board projects onto the tool and support them with any project specific needs.

NURIA ESTIVILL MANZANARO: So back to me. I am Nuria Estivill Manzanero. So I'm a Senior Engineer based in the UK. And I have expertise in water engineering integrated with BIM. And the reason why I'm here today is because I'm the Asset Generator product owner. That means that I'm responsible for the development and the implementation of the tool following the business and the users requirements.

So a little introduction on Arcadis, the company that we work for-- so we are a global consultancy firm, leader in data driven, sustainable design for natural and built assets. We are spread all over the world. And we are more than 30,000 colleagues dedicated to improving quality of life.

And with the introductions done, let's have a look to the learning objectives. What are we going to be learning here today? So we have three learning objectives I'm going to read for you, one, evaluate the key capabilities of Autodesk Platform Services, form a forge, to improve workflows, collaborate collaboration, and visualization, two, identify digital tools that offer industry specific benefits and integrate them into centralized, cloud-based platforms, and three, we're going to develop skills in change management and success measurement.

And we're going to do all of these while driving you through our journey, developing the asset generator. So if we put our work in a timeline, it will look like the years that you can see on the screen, so many years of work and lessons learned that we're excited to share with you here today. We have split the presentation in different chapters that align with different stages of the development of the tool. We will start by defining the dream, so why we wanted to create the Asset Generator.

We will explain how we implemented the tool, so how do we get from dream to reality? We will talk about the weaknesses and strength analysis that we did on the tool on the first iteration of the tool, which we called AG 1.0. And we will jump and explain how we build the second iteration of the tool, AG 2.0. We will finish talking about change management and success measurement, so talking about the challenges while sharing the dream.

So we're mentioning the Asset Generator here and there. But what it is? So the Asset Generator is a design automation and master planning tool aimed at rapidly developing visual and data driven solutions for early stage engineering projects. So it's a web app which runs in the browser with no need to have any software licenses or any 3D modeling knowledge requirements. So if we have a video here for you to have an overview of the tool. So this is the main components of the tool. We have the map, where you can explore your site and develop your project layout.

We have on the bottom the asset explorer, where you can access to the 3D assets from the global library from Arcadis. And you can also upload your own 3D models, or you can also auto generate your parametric models with using the design automation feature of the tool. If you don't want to use 3D models, you can simply sketch your solution. We use the GIS analysis tools in order to get an idea of areas, volumes, topography and adding GIS layers.

And the objective of all of this is to compare and create different alternatives so we can improve decision making in our teams. And all of this happens in the cloud. So we improve collaboration with other members of the team. We also leverage the BIM capabilities in order to view and explore the 3D models on the map. And we have a few other features in order to improve internal and external collaboration. So we'd like to say that this is the 3D tool that you need. Design, display, and differentiate your work. Well, and the big question is, well, how do we get there? And I'm going to hand over to Chirine in order to crack on with it.

CHIRINE CHIDIAC: Thank you very much, Nuria, for that wonderful overview. The asset generator is a tool that we're very proud of. It's a comprehensive planning and design tool that leverages many of the more traditional softwares that we use as engineers and then combines them into the centralized platform. The ultimate result was very powerful for our work.

But it's not like we woke up one day with an exact idea of what we wanted to build and how we were going to do it. It was really our industry specific challenges that drove us to developing this tool. So before we get into the technical elements of how we built the AG, we wanted to take some time to walk through our own challenges as water engineers and look at how these challenges helped us to narrow down the specific features that we wanted to combine into our tool.

So let's dive right in. At the beginning of our presentation, we all introduced ourselves as water engineers. And like all engineers, we are problem solvers and our problems all pertain to water. Our industry can really be boiled down to solving four key problems. The first is ensuring sufficient water quantity based on available water resources and population needs. So do we have enough water? The second is related to storing and transporting water so that it can be used and taken to all the places where it is most needed.

The third involves treating it for the necessary level of service. So this can mean making sure that it is safe for human consumption, clean enough to discharge to the environment, or usable for its industrial purposes when that applies. The fourth is managing water whenever extreme precipitation events occur or water levels rise to mitigate some of the devastating impacts that can occur as a result of flooding. So these are the four baseline problems that our industry is tasked with solving.

However, in recent years, we have seen our jobs become increasingly complicated by a number of different challenges, some of which are shown on the screen over here. So one of the key challenges that we've been facing is an increase in regulatory stringency, particularly as it relates to very difficult to treat contaminants in drinking water. We're also seeing an increase in project complexity as a result of supply chain interruptions and extreme weather events as a result of climate change.

In cities across the world, we're seeing exponential growth that is putting a strain on water resources. And then our industry is also seeing a much needed transition to more data rich technologies, or technologies that produce a lot of data, which is necessary and improves our efficiency, but also requires some additional data management considerations in terms of where to store, analyze, and secure the data.

So what does this all mean? The introduction of those complex challenges into our industry does not diminish our need to meet our baseline goals. So as we're experiencing these challenges, we wanted to find ways to think clearer about the things that our industry has been doing over decades and even centuries, so that we can think bigger about some of these newer problems that we are facing.

And in order to do this, we had to take a big step back and look at our overall approach to our work so that we could really see the forest and not just the trees. So here's a quick overview of the engineering process. The first step in the engineering process is to establish the project scope. So the owner of some water facility will identify a need and put out a call for proposals to solve whatever problem that they're facing.

This is where we as the engineers come in. We will gather a team of experts, analyze the site where the problem is occurring, break down the problem into manageable pieces, and then propose an approach at a high level using whatever existing data is already public about the site. And then finally, the owner selects the design that they want to move forward with, and the owner and the engineer come into agreement, and that's when really the work begins.

Step two involves a deep dive into the requirements that a project has to meet in terms of legal requirements and specific regulations. So that may be laws that are promulgated at the federal level, all the way down to local. It can also mean permits that a facility needs to acquire. But once all of those specific regulations are established, we'll dive into using some key industry standard documents that allow us to develop our design using best practices.

So at the bottom of the screen right now, you'll see some of the main institutions that put out engineering standards in the water industry in the US. But there are equivalent standards across the world. And the key point here is that these standards are specific and generally are all the same on projects in a given region.

So once the standards and the regulations are established, step three involves a highly iterative design process that goes a little bit like this. First, you'll pull out the standard, the applicable requirements from the engineering standards, that are necessary to your project. You'll convert them into a calculation sheet of some sort or a more dynamic engineering tool that can be used to size equipment based on a set of inputs.

And then you'll take the output of that tool and start developing engineering documents, like starting with sketches into 2D engineering drawings, sometimes 3D models. And then you'll go through an iterative loop that essentially creates the final design. And on traditional engineering projects, this is a very involved iteration loop. It can happen up to six times between establishing a basis of design and coming out with a conformed set. So it's a very involved process.

Finally, once the design is done, the project can go into construction using a set of contract documents that typically includes both drawings and specifications. And we won't go into this step in the process too deeply. We were really just focused on design when we were looking at finding a solution to streamline our work. But there are a lot of opportunities to do that in the construction phase as well that we touch on a little bit in the handout and would like to explore further as we develop our tool.

So looking at the process in the stepwise way, it becomes very easy to identify specific inefficiencies or opportunities to streamline. And maybe as you were watching this presentation, some inefficiencies already jumped out at you as an audience member. So we'll go ahead and step through some of the key things that we identified.

Our first inefficiency was a result of disconnected workflows. So during early stage design, which is that third step in the slide, we tend to repeat a lot of the site analysis work and regulatory review that happens earlier in the process, like in the proposal development stage, but we don't always leverage that earlier work.

Our second inefficiency was seeing a lack of 3D visualizations in early stage design, which might have helped us identify project complexities earlier on and improve our communication with our team and our client. So it's important to note, some projects do use 3D visualizations early, but this is a very resource intensive process. So we really need to weigh the costs and benefits before we invest in developing 3D visualizations early on in a project.

The third, and maybe one of the most obvious ones, is a high reliance on standards without streamlining the effort to pull out information from those standards. And then along that same vein, the calculation process is pretty repetitive, but our resources are quite diffuse. So people don't always know where to find a centralized single source of truth for where the calculations are and what they're referencing.

And then finally, the high level of iteration and repetition in our work became really visible to us as we were doing this review. Now, we want to emphasize that this iteration is very important, particularly for an industry that impacts public health and that builds infrastructure to last 50 to 100 years or more. So we really didn't want to compromise on our quality. But what we noticed in our review was a lot of the variability in our projects actually happened later on in the project. So we wanted to find ways to maybe streamline those earlier portions to make our solution flexible in the future.

So looking at all of these steps together, three main ideas came to us. The first was very simple. We needed to standardize our standards. This means taking all of the guidance material that already exists in industry standards and converting them into a usable engineering tool that is saved in some central location that everybody can have access to and everyone can know what standards are being referenced.

And then taking that a step further, we wanted to see, well, if we have all of those calculation sheets centralized and they're all in the same format, is there a way to pull out the outputs from those calculation sheets and automate that very first step of creating a 2D drawing or a 3D model? And then finally, how can we integrate the work that we do very early on in a project into the design iteration steps that happen a little bit later on? And that's how we got to our goal.

So we wanted to streamline these repetitive processes and address inefficiencies in early stage project design using the three steps that I just highlighted in the previous slide. As water engineers, our focus initially was to do this for every asset in a wastewater treatment train. So that's all those little blocks that you see on the right of the screen. But eventually, we decided to broaden our ambitions to do this across all of the disciplines at our company so that everybody could have access to this resource.

So once this broad goal was set, we wanted to establish some tenants that ensured that we would be building something that provides a maximum amount of value. So our three core tenants are the ones that you can see on this slide. The first thing we wanted to do is make sure that our tool was accessible to everyone at the company without them needing any specialized skills or licenses.

The second, and one of the most important, was that we had to have a lot of transparency in our tool. Engineers can't just take a set of black box calculations and then put them in a design. They really need to know what are the standards being referenced. They need to be able to verify the calculations so that they can ultimately sign and seal a viable design. And then the third is to really center efficiency in our process. We really didn't want to reinvent the wheel here. We wanted to pull features from existing tools that people were used to using and from resources that we had already started developing within our company.

So as a result, our building blocks were building information modeling, pulling some BIM tools into the asset generator, geographic information systems for some of the more spatial analysis components. And then we also wanted to pull in an in-house repository of 3D models that we had been building at Arcadis. And the idea here is by using existing tools, we could grow our own tool alongside these existing ones so that our tool wouldn't become obsolete if there are developments in BIM or in GIS. It would just grow with them.

And so this was the culmination of the first steps in our journey. You can see here the Asset Generator 1.0. And it contains a lot of those tenants and building blocks that I just talked about. So we have this design automation tool, where you can download an Excel spreadsheet, input a set of parameters and learn more about what goes into the design of an asset. And then you would re-upload that sheet, select the Revit model that you want to create your parametric model in, name it, organize your work, and so on, and then autogenerate your asset. Then ultimately, you could drop it on a map and use some GIS site analysis features.

So hopefully this gives you an idea of how deconstructing your process can allow you to build something better that you and your colleagues can take advantage of. And with that, I'll turn it over to Alan to give us a little bit more technical detail about how we got here.

ALAN LEVY: Thanks, Chirine. So now, I'll cover how we turned our dream into reality, building Asset Generator 1.0. So at the core of the automated design process was these parametric models that we developed. Now, to develop the models, we needed to find representative projects for each facility type. And then what we would do is kind go through these facilities and classify all the various dimensions that governed how the facility operated.

Then we would take those dimensions and inputs into how that facility operates, so in terms of how much flow the facility sees, what the recycle is, how much pressure there is, and determine how those inputs would affect those governing dimensions. So once we have that, we could develop those design spreadsheets or design calculations that turn those inputs into varying values for the governing dimensions. And we could then develop these spreadsheets, like Chirine had talked about.

In parallel, we also needed to model these facilities, so we'd have modelers go into Revit and build out these facilities with all these governing dimensions kind of placed in them so that we could modify them. But once we have this procedure or spreadsheets or design calculations and models, now we need to link them together. So to do that, first we developed a prototype using Dynamo. And what this did was take what was in the spreadsheet and pull out the relevant parameters and then push them into the model so that your model could be updated, depending on what's in the spreadsheet.

And that's great. But the problem is that it's very local. This is kind of an example of what that workflow would look like. An engineer would have to send the spreadsheet to a Revit user, if the engineer doesn't use Revit themself, and then go through putting the spreadsheet into Dynamo, Dynamo does its work, gives the revised file back to the user. And then that person needs to send it back to the engineer, which ends up being very slow because it depends on a person sending to another person to then run some program. And as Chirine had alluded to earlier, we want to make this available to everyone and browser based. So what we did was look into the capabilities of Autodesk Platform Services.

So what is Autodesk Platform Services? Well, it's a web service that lets you do many things. But in this case, what I show here is using that web service to modify those Revit project files. So in this case, now, instead of the Revit user being the one to initiate this process once they receive the spreadsheet, we have a web application that would take the spreadsheet and then provide it to Autodesk Platform Services, or I'll refer to it as APS from now on. So it sends it to APS, and then APS will send the revised file back, which ends up being a lot quicker because you're not waiting for someone to do something. It just happens automatically once the engineer provides the document.

So that kind of talks about what APS is. But how does it work? And what are APIs, for those that might not be technical? So one way of thinking about this is the analogy of a restaurant. You're a customer at a restaurant, and you don't talk to the kitchen directly. You don't go to the kitchen if you want a hamburger and fries and tell them how to cook the burger, what you want. You'll say what you want on it, but not to the kitchen directly, and how to pull all the ingredients together. No.

The customer will interface with a waiter, who takes the instructions, and then the waiter will then provide those instructions to the kitchen. The kitchen knows basically, based on those instructions, what they need to do, and then they can provide an output back to the customer or food in this case. So similarly, like with the APIs, the web application provides some instructions. It doesn't go right into the web service and figure everything out for itself. The APIs give instructions on what to do. And then the web services, or APS, gives the result back to the web application.

So what can APS do? Well, there are a lot of things that it could do. This is a very small subset of it, but there are a lot of different APIs that let you interface with your BIM 360 or ACC sites, lets you modify model files or automate the creation of Revit projects or Revit models. And it also provides-- associated with APS are some software development kits, or SDKs, that help you develop web applications further.

So what did we need APS to do? So as you can see here, the web services that we interface with needed to modify pre-made Revit files. So to do that, we use the design automation API, which also requires a design automation bundle that I'll get into a little bit later. We also needed to load and save to BIM 360 sites, so we use the BIM 360 API to do that. And then we wanted to be able to view models in our web application, which use the viewer SDK that I alluded to earlier, and also the Model Derivative API, which modified the models so that they could be used in the viewer SDK.

So that kind of shows how we link the input and output. And like I had said, also, we use the Revit API to help develop this process. So Dynamo can interface directly with APS, or at least it didn't earlier at the time. So we had to develop a plugin that basically took the parameters from the spreadsheet and then modified the Revit project file based on those parameters and values.

But now that we have this plan in place, we needed to develop the web application. So like I'd said, or like I alluded to, we use BIM 360 for our asset storage. So that includes the model files and the spreadsheets. Then we also needed to develop the user interface and the hosting.

So basically, that means how people are accessing our website, how they're moving things around, how they were downloading spreadsheets and deciding what model they wanted to interact with or pick or design. And then we also realized early on that having a GIS connection so that we could see where assets need to go and move them around was going to be very helpful. So we used ArcGIS Online and Esri Map Services in order to accomplish that.

So what does this look like overall? This is kind of a quick animation that shows the process for something that you might want to do. This is our web application. Like I said, it's cloud based, hosted on Azure. We interface with Esri Map Services and the viewer SDK.

Now, let's say we have a user. That user want wants to request the design spreadsheet because they want to make something. So they make that request, hit the Download button. Then our web application goes out to BIM 360 with BIM 360 API and then pulls down that spreadsheet so the user can download it. Now, the user kind of goes into the spreadsheet, makes some modifications, and then they upload it back to the web application.

So what happens now in parallel is that you have the web application modifies that spreadsheet to pull out all the inputs that we need. And in parallel, the parametric model that's associated with that spreadsheet is pulled via BIM 360 API from the BIM 360 site. Then those inputs are sent to APS with the design automation API.

Now, APS does its thing and modifies the file and then sends it back to the web application. This is the same web application that's in the center. I just have it off to the side so it doesn't look like spaghetti all over the place on the screen. And now, a couple things happen, once it receives the file back. We actually send it back to APS to give us a different version of the model so that we can view it using the viewer SDK. And we use Model Derivative to make that change.

Then we also save the Revit file to the BIM 360 site that's associated with the project, and the user could also use this to save it wherever they want in terms of BIM 360. And then we process the Revit file additionally on top of this so that we could view it in Esri Map Services, which requires a different file format than the viewer SDK. So this all seems great, right? But what were the issues that we had getting everyone to use it after we've built this great system? And I'll pass it back to Chirine to discuss that.

CHIRINE CHIDIAC: Thank you very much, Alan, for that wonderful overview. As you all can see, a lot of work went into building the Asset Generator 1.0. And really, at this point in the process, we had successfully addressed a lot of the inefficiencies that we had identified earlier on in our process. So on the left of the slide, you can see those five bullets that I had highlighted when I was speaking a little earlier today. And then on the right, you can see some of the solutions offered by the asset generator.

So really, at this point, the asset generator brought together all of the necessary features from BIM, GIS, and our own engineering processes into the centralized and functional tool. So we thought we had accomplished our goal and we were ready to revolutionize everybody's workflows. But unfortunately, that's not exactly what happened. In practice, our colleagues were very excited to hear about the tool, but after that initial excitement and after they logged on and started playing around with it, we saw that usage actually dropped off significantly.

So talking to our users, they highlighted two major issues that they were facing when using the Asset Generator. The first is an unintuitive interface. So people through our own communication by hearing about it from other people, knew that the tool had a lot of features that would be useful in their work. But they didn't necessarily know what the specific clicks or what the specific processes that they needed to go through in the tool, in the Asset Generator, were. So they didn't know how to find what they needed.

In addition to that, they were reporting an inconsistent quality in the functionality of the tool. So in some cases, the tool would be slow to load, or it would have errors in the background that weren't properly communicated. And ultimately, they would get frustrated and go back to their original ways of working.

So as engineers typically do, we took another step back and said, let's solve this problem. Let's rebuild. So the first step we had to go through here was really recentering the users' needs and our overall process. This was accomplished by applying some UI/UX principles for web design. And UI/UX stands for user interface and user experience.

So the first step that we took is identifying a primary persona, really narrowing down the characteristics of who is going to be using our tool. And then we described their overall journey from the very beginning, from the discovery of the tool, how they even heard about it in the first place, all the way through to finding every single feature that they needed to complete their work.

Once we identified all of those needs, we started the process of building a new prototype using a tool called Figma, which allows you to create an interactive prototype that you can click through, but it doesn't have any back-end capabilities, meaning you don't have to invest fully in recreating a new website, but you're able to see how a user might respond to it if they were exposed to the tool before it was built.

And so that's exactly what we did. We set up some user interviews. We created a list of tasks that we wanted our users to very easily do. And then we identified some people that fit our description of our primary persona and had them go through these steps as we watched, but without giving them any guidance so that we could see what is the most intuitive way of approaching a specific task.

And this is what led us to our rebuilt front end. So this was the interface of the new Asset Generator 2.0. As you can see, it's a much sleeker design. It's clearly more intuitive. And it's even more gamified. So at the bottom of the screen, you have all of the 3D asset development features, including uploading your own asset, generating one through the parametric model, auto generation that we just described earlier. And then we have our pre-built library of assets also shown in those little icons in the bottom right of the Asset Explorer.

We have all our site analysis tools concentrated to the right of the screen. That's where you pull in your GIS features. We have the capability more clearly organizing our work through the alternatives development dropdown menu. And then all of that comes together in this much clearer 3D layout environment in the AG 2.0.

So that was to address the user interface issues. To address the tool's reliability, we really had to focus on rebuilding the back-end to make it a lot more efficient in the way that it was processing the commands that we gave it. And Alan will get into that in just a moment when he takes the mic from me again.

But another key thing that we had to do in terms of ensuring a reliable quality to the tool was reorganizing our approach to making updates to the Asset Generator. So in the past, we had been adding features in somewhat of a piecemeal way, where a user would report an issue and we would immediately run to resolve it without really thinking bigger picture about how that might affect the overall functioning of the tool and the processing of different commands.

So instead, this time around, we turned to a more prioritized and categorized backlog, where we would input all of the potential needs that a user had into this backlog, and we would categorize it based on the urgency of the request and the applicability it would have to other users, as well as the level of effort that it would take from our development team to actually implement that change. That way, we were always balancing need with our capability to actually keep growing the tool and keep developing it.

And then finally, once we released the AG 2.0, we had to keep a team of maintenance developers nimble and ready to address bugs. And so what we really focused on was making sure that our errors were communicated within the tool itself. So you can see in the image here on the right, an asset failed pop-up. That can inform the user that something is wrong. And then we had a bunch of different help links located at the top of the screen, where you see that little question mark. That really creates a better line of communication between the development team and the user. And with that, I'll turn it back over to Alan to talk us through what changes we made the second time around.

ALAN LEVY: Thanks, Chirine. Do you want to advance to the next slide? So let's dive in. This new version of Asset generator 2.0 is very similar to AG 1.0. Conceptually, it has all the same building blocks. But we really need to start over and have a new execution for how we combine those building blocks together.

So one of these aspects was we revised how things were connected. We had revised the Revit API plugin for the design automation aspect of the tool to allow us more flexibility in terms of what we could build and what we could change. So originally, we were just changing parameters. We built these parametric models and basically said, this parameter needs to be 10 inches. This parameter needs to be 10 feet. And then the model would update accordingly.

Now, the plugin allows us to place families wherever we want, to place walls, floors, ceilings, to actually build up a model from scratch, how a modeler might build it, rather than just doing everything solely parametrically, which gave us much more flexibility and much more power to build the models that we want. We still kept the ArcGIS connection. And that pretty much remained unchanged. But as far as Autodesk Platform Services is concerned, we removed that connection to BIM 360 API in favor of using Azure and binary large object or Blob storage to store all our assets and spreadsheets because we found that to be a little bit more responsive to our needs.

So now that we have that plan in place, now we need to develop the website or the web application, like I mentioned before. So Chirine already kind went over the UI/UX emphasis. And then as far as that Azure focus, that's really moving things, in terms of storage, off of BIM 360 and on to Azure to get a little better response time. We also used Application Insights from Azure to get a better idea of how people were using the program and get better metrics on it. And then we redeveloped the back-end of the web application again using C#. It was originally in JavaScript. And that provided a little better performance for us as well.

Finally, we worked to develop tools to better support our ability to create for Asset Generator. So I had mentioned the Revit API design automation bundle, but we also developed a method of being able to upload revisions very easily and quickly, when before, the file needed to go to developer. The developer needs to place it somewhere. And it just like I mentioned earlier in terms of a person was involved when there didn't need to be, so we kind of automated that process. We also automated the process of uploading to our global library to make it much more easier to fill that out. Next slide.

So just to give a quick overview, this is pretty much the same as what I described before, but you could see wherever we were interfacing with file storage, we kind of used Azure to do that, which gave us a much better response time, like I said earlier. And then I'll pass it back to Nuria to give us an overview of how we got people interested in the tool and then also give us a quick case study and then discuss how we measured success in terms of people using the tool.

NURIA ESTIVILL MANZANARO: Amazing. Thank you, Alan. So yeah, as he mentioned, let's talk about change management and success measurement, what it takes to share the dream. So if we go to the next slide, please. So if any of you have tried to roll out a new workflow, I'm sure that you've experienced the resistance of the workforce. So how we did this transition a bit smoother? And the answer for us was like, as you said, sharing is caring, so having a supportive product team. And our project support started from the beginning of the developing the tool.

So every 15 days, we had these sprint reviews, where we invited the stakeholders to the meeting. And in there we will share with them the features that have been developed. We will ask for testing and feedback. We will also discuss the features that will be coming in the future. So we will make sure that what we were building is what the teams were needing.

After the development stage, we carry on spreading the word of the Asset Generator and doing internal meetings and making sure that in these calls we had project specific demos. So we were not only showing what is the tool and what the capabilities are, but also how to implement them in real world projects. And finally, we created a centralized website for user guidance, case studies, and support. So it was clear for the user where to go if they had any questions or any feedback.

So putting all this effort in, finally, we got to a point where our teams are using the Asset Generator. And we do this internally as well, so we like to share the case studies and the success stories. I wanted to share one case study with you today. So I brought the Knap Mill Water Treatment Works case study that is based in the UK in Bournemouth. And I want you to have in mind that engineering process that Chirine talked at the beginning of the presentation. And you will see how the Asset Generator streamlines, especially the two in the middle.

So what was the scope for this project? We had to develop a concept design for the client to engage with the stakeholders and contractors. Without getting into the technicalities of the project, let me give you a bit of an overview. So the Water Treatment Works is an existing facility. And it's an aging facility. So it needs some upgrades, as they are not meeting the current water regulations anymore.

It is located in a protected area, so we have some planning requirements as to minimize the visual impact. And the client has already undertaken a feasibility study. And they have a reference design that they have provided to us, as they think that that's the optimal solution for them. So this is quite a frequent case in Europe, where we have an aging facility that needs some upgrades. So if it's key to understand the constraints of the project and work around them. And this is where the Asset Generator shines.

So now in five steps, I'm going to show you how we use the asset generator to create this concept design. So step one, we assess the site constraints. You can see in the slide a section of the existing site from Google Maps. And then what we did is model all of this in Revit and upload it into the Asset Generator. So if we can click for the next slide, yeah.

So now, you can see how these white modeling that we created in the Asset Generator-- sorry, in Revit, the simple boxes was uploaded into the asset generator, and we use the ground transparency in order to see also the below ground services. So those are all the lines that you can see on the screen. So clearly, you can see that, well, we are working in a congested site, crowded with below ground services. We're going to have some space constraints. And we're going to have to be building on this site while the water treatment works is operating.

So let's jump into step two. So we wanted to understand the reference design to establish the viability of the solution and its constraints. So we rapidly developed and displayed the reference design into the map. How do we do this? So first of all, we browse in the Asset Explorer to find the assets that are suitable from the global library.

We don't want to be reinventing the wheel or doing the 3D models once again and once again. We want to reuse the existing knowledge from our teams. So that is a key capability that we have in the Asset Generator. And we are able to find the suitable assets as we maintain the information on them. So we push them so they are lightweight, but we maintain their data that is usable for future projects, let's say.

So with that, we managed to get the units process that we needed and put them on the map. When that was not possible, we went back to our teams and maybe upload our own 3D models. And when that was not applicable for any of them, we just had the sketch on the map with the 2D shapes or the 3D volumes that we have available on the asset generator.

So you can see the roads and some volumes on the screen. So you can see there's nothing sophisticated, but this is not enough for us to understand the scale of the solution and how it fits on the real world. And the important bit in here is that we don't need any license or any modeling knowledge. So the benefit is that the technical lead of this project was able to create this view himself.

So we jump into step three. So let's assess the constraints. Then let's overlay the existing services with the reference design. And doing so, we could detect the clashes. We could identify construction and operational risks. And we undertake a preliminary assessment of health and safety on the project in an early stage of the design.

And we were not very happy with what we could see. We thought, well, it's going to be tricky to be building in this site, so let's look for alternatives. And that's what we did in step four. We had our blocks, and we have the boundary of ownership of the client. So let's move them around the site. And you can see on the screen that we created around eight alternatives, just moving the blocks around. So having this ability to look for different alternatives highly improved our decision making.

And also mentioning that all of this, we didn't do it alone. We collaborate the project with other members of the team. So we added mechanical engineers, civil engineers, process engineers, so we could all brainstorm, looking at all the information that we had on the map.