Model Requirement Checking Online: Automated Data Checking on BIM 360

STEPHEN REGISTER: With increasing volume and quality of information being required from our models, we need better quality assurance tools, then Revit schedules, Excel workflows, and other derivatives that are limited in functionality and slow due to their reliance on the Revit user interface. Imagine if you can visualize non-compliant data and correct it at its source within Revit on all your cloud models with all the compliance checking happening in the background.

As you see here, it's not delusion, but a grand tool, indeed, called the model development checker online or MDC. So welcome to the Autodesk University class, AS 500346 Automated Online Model Requirement Checking, where we will explore the MDC's contribution to data quality through its efficient validation reporting capabilities and cover how to implement and adapt it.

To walk you through all this will be myself, Richard and Paul. So let's do some quick intros and get to it. My name is Stephen Register. And I'm a design technology specialist with CollisonRTKL. I started doing the management in the previous century, which means I've seen a few things. Back then, managers, like myself, could easily BS your way through most anything. Can't do that now.

Today, data driven evidence based decisions are expected, which is something we'll build upon later. Another apropos thing about me is my interest in applying agile principles to the [? AEC ?] industry. One of those principles, that of welcoming changing requirements, even late ones, gets a little easier to do when you use the model development checker online, which we'll do for you today.

With me are two gentlemen from Autodesk, who were instrumental in getting the MDC set up for us at CollisonRTKL. Richard, do you want to tell us a little bit about yourself.

RICHARD WALSH: Thanks, Steven. My name is Richard Walsh. I'm a senior implementation consultant here at Autodesk. I joined Autodesk 10 years ago. I have a background in implementation within the AEC and structural engineering sectors. During my time at Autodesk consulting, I've been involved in the development of model development and information management tools that have been delivered to numerous customers and industries.

These aid teams to specify and validate metadata or information within their BIM models to support BIM users through construction and post construction. I'll now hand over to Paul, our third member of the team, to introduce himself. Over to you, Paul.

PAUL REED: Hi, I'm Paul Reed. And I joined Autodesk in June 2019. And prior to this, I worked for a large Civil engineering firm for over 10 years. So I started as an apprentice engineer on site, dealing with setting out quality inspections before gradually moving on to data management, using applications, such as Revit, BIM 360, and Officeworks.

I gradually worked my way up to digital construction lead for my region, given me a pretty good understanding of the data people on site need, as well as, the information our customers needed. I'm interested in getting data to where it needs to be in a format that's usable, using product APIs, automation, scripting to achieve this. And that's it for me and the intros. And I'll pass over to Steven to get started.

STEPHEN REGISTER: Right, as I mentioned earlier, the model development checker is important for data quality. So we'll start there as a backdrop. Then we'll cover some of the difficulties of ensuring data quality for all the required information on a project. And that will lead us to look at the MDC itself and how it addresses those challenges.

We'll also get into what makes the MDC work from a four generation perspective and where the flexural parts that make the MDC adaptable. So first up is data quality. Again, as I mentioned my intro, I've seen them change over the decades from something that was a benefit just internally within the architecture firms I worked with to now being integrated into the entire facility lifecycle of design, delivery, and operations, which means BIM data dependencies have gone from internal to external.

Now others outside your organization are dependent on the data you produce. This opens up contractual liabilities and creates a huge need for validating data quality. And we see the effects of this manifest itself all over the industry, via the BIM standards and requirements like ISO 19650, COBie, LOD, et cetera. Everyone is expecting to give and receive some level of reliable data and want something to measure quality data against.

Here on this slide, you can see listed some of the more prevalent external or cross organizational BIM data standards and exchanges that reflect the need for data quality. COBie, for one, addresses the need to move structured asset data across organizations from design to construction to operations. LOD defines the qualitative differences of design intent and as constructed data so that there can be a clear understanding between the author and recipient of what data resolution to expect.

Space naming standards make sure that the data that the design team produces, it gets delivered to the owner. And the owner can depend on it for their integrated workplace management systems. Even within the specific stages of facility lifecycle, like design, reliance on quality data exchanges occur, especially when dealing with facility performance.

The team doing energy analysis, it depends on the design team to properly enclose the rooms and spaces. So each discipline depends on the other's data, kind of like making sure the BIM spatial data is correct so BIM elements and clearances don't clash. And now, with digital twin tools really starting to make headway, BIM data quality is even more important, especially for those feedback loops to even work. So what are they been doing so far to validate our BIM data and what are the challenges?

So far, we've been doing interesting things with Revit schedules, highlighting elements via view filters, Excel data exchange add ins, and other manual or automated tools. But all of these come with some negatives. The biggest negative with all the tools we've used is all the time required in the Revit and BIM 360 user interfaces. I have to wait on downloads or opening times or the collaboration cash to update, our viewers and geometry to be resolved, or warnings to pop up to be addressed or resolved.

These things are OK when I'm modeling, but mostly not necessary for data validation. Do I really need Revit to resolve all the room boundaries in my model just so I can check the parameters on my [? fire rated ?] walls? No, not really. So I wound up wasting a lot of time just waiting for the next randomly timed user interface prompt, like a [? wrap, ?] that variable rewards experiment.

And then, you multiply that by all the display models, and then, again, by the multiple buildings on some of our campus projects, it's just so absorbing for me. And then, some of the add ins we use have server or client components that need a bit of upkeep to stay compatible with Revit and BIM 60 updates and Microsoft too. But some of the developers are more responsive than others.

So sometimes timing release an issue, when you want to use the latest Revit, but the add in is not ready or something breaks. And it takes a while to get resolved or the developer just goes dark. That's always fun. And then, one of the other challenges is communicating the validation results to the distributed team. We'll often send out Word Document, PDF, or spreadsheet or whatever.

And then, the design team needs to go find all those non-compliant elements in the Revit models. It's like giving them a map-- a hand-drawn map that says, turn right where the old hog shed barn to be. And then, five miles before the road dead ends, veer left. Because, I mean, these tools don't have a highlight and model feature. So you wound up having to guess your way to it.

So when we came across the MDC, it made us keenly aware of all these challenges because it answered them. So let's take a look at that answer. Richard, can you go ahead now and show us the MVC and how it works.

RICHARD WALSH: Sure, Steven. The model development checker itself started out as a desktop plugin for Revit Civil 3D and Navisworks that enables checking of parameters on model items within specified classification attribute reports. This report is a simple Excel file that acts as the instructions to the model originator as to what they're required to populate within their model. This would then be input into the MDC tool.

And they could then check their model getting an HTML report on where these items passed or failed. Further develope was then undertaken to develop switchback tool that I will talk about more soon. All of this was still very manual onerous task. So we looked for a way to take this into BIM 360 and automate it through Forge. This section we'll now look at through the following items.

So we'll have a look at the Excel classification report, the LUA scripts, which can really take the parameter check into the next level, the BIM 360 Environment set-up itself, the web client set-up, the HTML-- sorry, the XML output results, and then, onto the Revits switchback tool itself. Then we'll go through these steps in an end to end demonstration of all the moving parts.

As a high level overview of the workflow, this diagram illustrates the starting point of the owner or operator specifying the organizational information requirements. These are the specifications to the model element authors. With these specified, they develop their project models. And within the MDC online, they receive the validation of their models and continue to iterate their design through the design process, making any corrective actions that are necessary.

With certainty that the information requirements are being met, the model can then be used for field management and on into asset and operations by the owner or operator. So the first part, the classification actually report, as I said, this is a simple Excel file with no fancy bells and whistles. This outlines to the model element authors what they are responsible for on an information perspective and when it is required and what form it should take.

This also lists where the parameters are in the model, whether they're instance or type parameters and what checks will be performed on these parameters. These checks can be simple checks, like parameter is not blank or the parameter is within a range. These can also be in the form of regular expression checks. Additionally, these checks can be script checks, using the LUA scripting language.

LUA is a certified open source software. And it's a free software distributed under the terms of the MIT license. There is a huge online community with lots of information and examples of use available at Lua.org. Within the BIM 360 environment itself, there is little changes required to the standard work in progress environment but I'm sure you are all familiar with.

The additions are a folder that contains the classification attribute report Excel file and one that will contain any LUA scripts to be run within this tool. Once the BIM 360 Environment is up and running, the web client is configured to point to these work in progress model folders and the report and script folders. When you are ready to go to run your checks, these can be submitted to the job queue.

And when the jobs-- when the checks are complete, this can be quick as a couple of minutes for most jobs. After they've been submitted, the user will then receive an email notification that the job has been complete with a hyperlink back to the BIM 360 folder that contains the results XML file. This can then be downloaded by the model author and loaded into the Revit switchback tools to locate and highlight any model elements that need corrective action.

This too can be completed through the tool. The corrective action can be completed through the tool. And the parameter values passes through the specified checks. The traffic light icon can change from red to green to show that it's passed. You can now move on to the next item and work your way through the rest of the model to achieve your stage deliverable requirements. Now let's see this in action.

So firstly the BIM 360 Environment, here you can see the work in progress folders that are project discipline folders. Today we'll focus on the [? McCulloch ?] goals for this demonstration. So here you can see the complexity of the project, illustrating the impossible task of manually checking information on elements. So the reports folder, containing the classification attribute report Excel, this lists the required attributes that will be checked.

On this particular example, we use in the OmniClass classification system to identify the objects in the model and the checks that will be applied to the parameters themselves. We then move on to the script folder that contains the LUA scripts that will be used on these checks, here opening them in Notepad++ just for illustration. So now we can move on to the web client set-up.

We log in using the same credentials as the BIM 360 environment. We select the relevant project hub. And we can now add the folder where the model files are located. And now, click-- select the test folders for the report and scripts. This can then be selected and submitted to the job queue. Once the checks have been complete, you will receive email notification.

And you can click the link to the folder containing the XML reports or navigated to it within the BIM 360 Environment itself. The results will be in the report's folder within the discipline work in progress folder. These can be downloaded for use within the Revit switchback tool, and just for illustration purposes, opening this example in Notepad++ again. The modeler can then open their Revit project from the BIM 360 Environment in the usual way.

And then, open the Revit switchback from the MDS model checker tool, locating the XML report to see how well he has performed. Selecting an [? amber ?] element selects and navigate to the item in the project. So this contains green passed attribute elements together with red fail attributes. Here, red fail attributes can be changed through the switchback tool to correct the value, getting a green pass icon.

Here, illustrating that this was also now being populated to the itself in the instance properties dialog box. I'll now pass you back to Paul to take you through the technical setup side of the solution.

PAUL REED: Thanks for the demo, Richard. We're now going to cover the technical side of the app, how we bring all the aspects of the system together into one comprehensive experience. So this is the basic architecture of the app. We can see it split into quite a few components. We have the stuff on this year. This is where the front and back end is hosted, as well as, a database to help manage the app.

And finally, we have some several serverless functions to perform backend tasks. We also have the original Revit add-in. This was initially a desktop based add-in, which has been converted to work on design automation. We have Froge. This takes the converted Revit add-on and runs the code in the cloud. And this is combined with the data management and authorization APIs to manage access to BIM 360.

And finally, BIM 360 is where the model files, scripts and configuration files are located, as well as, any outputs, such as the reports generated by design automation. So as mentioned prior, we already had a working add-in, which could perform the model checking. But it could only work on individual machines on the desktop, one model at a time. So we converted this add-in to work with design automation.

To do this, we basically remove any functions which are not available in the cloud Revit engine. So this includes any user interface stuff, such as the Revit API, user interface, and any Windows [? form ?] stuff. Next, we had some functions which will get called by design automation when the code is run in the cloud. And then, we change type the add-in to the application.

With these changes made, we can compile a code and place the DLL into a folder, along with a file describing the contents. So this is a package contents XML file. These are then compressed into a zip file ready for uploading to design automation. The Forge application, we included design automation, data management, and the authorization APIs. Design automation is used to run the converted Revit plug-in.

And data management and the authorization APIs are used to manage access to BIM 360, where the inputs and outputs are stored. For the Forge application, we also need to set up an engine. This will specify which version of Revit we wish to run the code on. To do this, we register an app bundle on Forge and specify the app bundles engine or the version of Revit that we wish to use. Next, we create an activity.

This is an action which can be initiated in design automation. Activities run specific app bundles. And when creating the activity, we specify the app bundle that we created earlier. Azure is used to host the web application and its supporting services, the web application is built using TypeScript. And this includes your serverless functions. The front end is built with Angular with material design components for the user interface elements.

And the back end uses Express. We also have a database, which is used to store application information, such as the project we wish to use this on, the folders on BIM 360 we wish to monitor, and the specification files that we want to use for these folders we've selected. Finally, it contains a job queue. And this is used to store a list of folders and files, which require processing.

We have serverless functions, which perform several backend tasks, such as submitting a job to design automation or dealing with the results when design automation has completed processing, such as sending an email notification to alert the user that the job has finished processing. BIM 360 is used to store project data. This includes all the inputs, such as model files, the LUA scripts, and configuration files for checking.

And the output source is stored here, as well. So any output from design automation is stored-- is placed here, such as the output XML or HTML reports. When a user logs into the web application using their Autodesk credentials, they're presented on the Home screen, which shows the list of active projects using MDC online. Here they can select a new project. This uses a data management API to navigate through BIM 360.

The user then selects folders that contains the models that they want to check and which folder contains the check specification files that they wish to use. These locations are then saved into the database. And this is then where serverless functions take on the process. So the web application submits the job to the back end via HTT request to a job serverless function.

This then adds the folder and specification to the database, which is then in turn processed by a check folder function, which adds the files to a file queue. Next a check file serverless function sends the information to design automation for each of these files. On completion of the job, design automation will send a HTT request, which will get picked up by the job finished function.

What this will do is this will notify the user via an email and uploads any job info to the database. So this gives a summary of how Forge design automation helped us work with a lot of large files, without having to download all of these and work on each of them individually, saving a great deal of time. So on our path over, Steven, for the wrap up.

STEPHEN REGISTER: Thanks, Paul. It's all that Forge integration work that really made the Model Development Checker valuable for me. It cut up my time, messing about the user interface and moving data in and out of BIM 360. That saves me hours each week that I can use to spend on higher value BIM tasks or projects, or adding more checks to drive up the project's data quality. So, hopefully, this presentation has helped you see how valuable Modeler Development Checker online can be.

We saw how BIM data quality is increasingly important and that we need better ways to validate our work against all the various information requirements to ensure that that data is high quality. And we also looked at what it takes to set up and run the MDC online to validate in data and how to customize to meet your specific requirements. So if you want to try it out yourselves or learn more, talk to your Autodesk representative or contact me.

I'd be glad to chat with you about my experience that I've had with the tool. With that, thank you so much for your time and interest in this class.