Workflows on Rails

ADAM SHEATHER: I just want to quickly-- quick on me. Who am I? Adam Sheather. I look after Badmonkeys Australia. There's a number of us Badmonkeys running around. We have a presence in Norway, presence in the US, here in New York. And so in Australia, our key focuses are software development and automation, so really just focusing on automation with workflows that actually make sense for people. There's a human involved in a lot of pretty much everything we do, so not really trying to replace everyone.

Typical clientele for us is software companies, contractors, subcontractors-- which are who we were with on this particular project. Prior to that, I used to be in architecture and construction, and worked everywhere until I thought I'd work for myself.

We do a number of different things-- digital transformation. I really hate that-- just do things with computers, basically. So a process that wasn't done with computers is now done with computers. It's pretty magical. And then some enterprise solutions, so we do a fair bit of forge development, integrations with Azure and cloud environments with people who haven't dealt with that type of thing before-- REST API implementations, where people who sort of set things up in a database want to share the information. And then occasionally, we get suckered into these big projects.

So where we are, we're all over the world. I'll stop yapping about us now, and just get into the project. So on this particular job, this was a pretty large project. It was a single contractor that was engaged for four years. This was about 200 kilometers in Malaysia. And so the key parts of this project were 197 kilometers of dual track electrified. So there was a single existing track that was already there. And so that had to be replaced with dual, because the single existing had the design speed of 80 kilometers an hour. And the client wanted to update that.

11 brand new stations, obviously, to be aligned with the new system. The depots, the OLE, the permanent way, the utilities, and some auxiliary structures around that too. So the client-- so, yeah. There you go. So that's the type of details that we're expecting in terms of traffic. Because this line already exists, it has to remain operational pretty much at all time, as we're building the line through it as well. So I did have some-- and still having some-- additional challenges. So for those who are more on the rolling stock side, that was the type of the amount of traffic we're expecting along this line.

And so the Ministry of Transport, when everything's BIM-- you're going to do all the BIMs, and even more BIMs with the BIMs. And so we were engaged when we started looking at the team from the contractor side, and we started working with all the consultants, there was a bit of understanding of what the capabilities were. And this is where we're at. So contractually, we had to provide a Civil3D and an InfraWorks model for the entire project, Revit as well.

So when we started getting in there, there as no Civil3D experience amongst the engineers at all. There's a bit of a Bently MX. No one knew how to use InfraWorks. I don't think most of the team was aware of what it was. So Autodesk had done a really good job on marketing to these transport dudes.

And then the Revit experience was pretty minimal. So the sort of typical things that we see in Malaysia is you get some models, no documentation, no schedules. There's not a lot of post data being generated out of it. It's more here's a model, and then we'll hack things off, send it to CAD, and do it the old way. And definitely, no Revit experience for civil projects, where a lot of things we were going through, we decided to go down to keeping Revit rather than move to Civil-- reason being because at least we had some Revit experience.

And yeah, very minimal Navis, and virtually no Dynamo. So that was the type of constraints we were dealing with with this team. So the size of the job, when we started breaking down, I've got 9 kilometers of viaduct, overhead bridges, underhead bridges. There's another road sitting beside it, personal bridges, and then there are 288 culverts as well on top of the stations and the other bits and pieces. So reasonably complex project.

So what we're going to talk about-- I'll go quickly through the good and bad of the BEP that the government had given us. I was working on behalf of the contractor, so some of the cheats that we put in there. Some of the things we've set up on the project setup, getting into some of the model breakdowns and some of the things that we automated. And then just some tricks that we found along the way, that maybe if you're using InfraWorks, will help you. We found InfraWorks falling down in terms of presentations for stakeholders and things like that. So especially in the rural areas, we were able to come up with some cheats to enhance the presentation, and a few other things. So hopefully, there's a combination of high level and low level.

So our official role, so we were engaged a year or half ago, I think. So we were originally brought in to advise on the contractual arrangement, because the contractor wasn't confident with what the government was talking about in this document. Developed the response BEP for the client as well. We also had to do a separate BEP for the consultants. And then we really moved into a role of supporting the BIM management team. We didn't take that role. That's not really what we do. There were two people that we selected, and then we really just gave them the tools that they needed to start managing the job and take ownership of the project.

So in between us and the ministry, there was an independent review group that was hired. They also had limited BIM capability. So they engaged a reseller to be their BIM consultant. So that was quite interesting, because they clearly had done some Navis works coordination. But that was about the limit of their capabilities. So as a result, we had some real struggles going back and forth on what was going to be modeled, and what wasn't going to be modeled.

So the other weird issue that we had is they had told the independent review-- because they were hired before we were-- that the BEP that they shared with the client-- the BIM execution plan-- could not be shared with us. And they refused to hand it over. So they had agreed to the client what we were going to do. But then they wouldn't share it with us. So we had to write our own BIM execution plan to share with them that they would share with the client, and then they could disagree on ours but not tell us what they had agreed to do.

So the best We haven't got out of a meeting was we had one meeting where they had taken a photo of one of the pages and put that up in a PowerPoint presentation. So it was quite a complicated thing. For some reason, there was this feeling that what they developed as a contract was quite valuable. And as a result, everyone else would just steal it. So they sort of created a lot of friction.

So the key parts of their employee information requirements-- if you want to call it that, or scope-- the things that they wanted to take in BIM from a goal point of view was seeing the planning, how you're actually planning this design using BIM. How are you monitoring the design, and so on, and so on-- as you can see here. So each of these, these were the things that they wanted to see-- some sort of BIM involvement, or some sort of usage of the models and the data or the drawings to execute all these things. So today, we really only got to pretty much here. We have a plan for this. But just due to the size and longevity of the project, this is where we are in reality anyway.

So there was some good stuff in there from the BIM execution plan. I guess I'll just cover a couple of things. So the collaborative project environment-- so everyone's working together, coordinating the project documents, getting that working-- which was a challenge. Utilizing 4D technology, which was a waste of time. And we'll get to the reason why on a job like this, especially the early stuff. There's stuff for later, but as you'll see, that wasn't as useful straight upfront.

This is where we start getting the less good, collaborate with the facility management. And it was like, well, we don't have a team. We don't have any software. We don't have any solutions. So there really wasn't a way forward from that. And then the quantity take-offs as well, that was quite useful.

So where we started running into trouble, though, was we had this contract. You know, we've got this BIM manager. And he'll build it up to LAD 300. And you have to use these tools. That's about it. That was just demanded. The weird thing is this original alignment was done in MX. The original alignment was done in MX, it had to be all converted over to Civil3D to work. And for those who have ever used Civil3D for rail alignment design, it's pretty spotty.

So the bad stuff, as I said, is two different contracts-- one between the reviewer, one between the JV guys, and then we had a separate BEP. Because the contract I was working for, the thing that we wrote for-- the independent reviewer-- was also really important. So we couldn't share that with the consultants and the architects and the engineers. So we then wrote a separate, more technical scope to share with them.

So we had three plans that I don't think really aligned. And then there was these other things, where we basically had to write pretty defensive statements. So client requirement was whoever had written the client thing had just said, you know, you'll have these plans and these controls, and all of these exchange protocols and guidelines provided by the SO-- who was especially officer. And no one was ever appointed.

So the real important parts of the original contract we agreed to weren't actually documented at all. They were handed off to this imaginary future person who no one ever hired. And I'm sure you guys have dealt with this, you know. So you have to come back and be like, well, if there's no guidelines, we're just going to interpret this how we want. And luckily, they signed off on that. So we got pretty lucky where, as a contractor, we just went, here's the rules. Deal with it. And they were like, yeah, that's a great idea. So it gave us a lot of power.

Like, we assume the contractor himself has pushed pretty well on this. He's been pretty proactive as well. So it wasn't announced in terms of, sweet, let's go back to CAD and screw all BIM stuff. It really was more of, we just want to be in control of the things that, when it comes at risk and we're unable to do it, that we could manage that risk.

And the other bad thing, there's paper-based. I don't know if anyone deals are these BEPs. But every single one of one had to be signed separately and printed separately. And after like seven iterations of this thing, you've got, like, just pieces of paper everywhere. And yeah, I'm pretty sure the day we signed it was the last time anyone ever looked at that document ever again.

So these things, you know, there's a bit of planning and help involved. But when you go back and look at the contents, sometimes, you're usually like, well, is that what it's designed for? Is this meant to be like a contract that you put away? Or is it meant to be a useful document?

So the good part is, it took about three or four months. We got it done. They did have some other really weird things, like telling us how powerful the computers had to be. But we were like, this is a four year job. So we'll probably be changing those computers. So we don't want to keep using them. But yeah, we got it done eventually.

So what we got is quite interesting. When we first got the design team submission from the original engineer, we got this awesome thing. And I don't know if you guys have ever seen a 200 kilometer bridge animation. It's amazing. Now this goes on for about 25 minutes.

And this is probably one of the most exciting parts of the job right here. So you got this little bit of a road overpass and a pedestrian way there. Yeah, there you go. So some other things I learned early on is, like, these type of workflows that work great in architecture, not so good in the silver realm.

And if you do it too fast, in like two minutes, you're just going past everything. So it doesn't really make sense there either. So this was quite an interesting challenge. So the first thing that we had to do from-- I guess-- a delivery point, was to figure out how we were going to split this up in terms of multiple deliverables. Being 200 kilometers, the contractor decided to split it up into five sections. And then each one of those sections was split into three subsections. So we decided to match the Civil3D, the stations, and everything around that piece. So really going through with the contractor and seeing how they're planning to break up the scope of works from their early schedules really helped us inform how we were going to pull apart the models and structure them in a similar way.

From the job in the terms of a construction point of view, they're working both ends coming together. So starting at section 1, section 5, section 2, section 4, and then section 3, so starting it back in order to deliver this in four years. And then we've got the survey data. And it was pretty bad. It was created six years ago. Because this is next to a highway, there had been new roads. It was all 2D.

And that original model that we saw with the exciting 20 minute walkthrough was never shared with us. So the original design was like no, you can't. You can't have this model. So again, we had to recreate everything from scratch. So yeah, a typical sort of thing. You get something like this, with just a long amount of data. So there was a massive conversion process to get this off and across to Civil3D.

So what we started doing is when we started compiling all this information, we're trying to figure out a way to put it all together. And so what we started with, is we started the original survey and some of the information we got. And as we started to put it all together in a way that made sense for the stakeholders, we tried doing it in InfraWorks. But we actually found that not very useful as a way to engage with the stakeholders.

We did look at Esri, but we had no capability there. But we had one guy who was phenomenally good with Google Earth. And so I started working with him when we started putting this thing together. And it actually became pretty cool. So this is the Google Earth project itself. So what we did is we started loading all the new assets in across the alignment. So these are all the CAD files, taking the pictures of each of the existing bridges. This is just for phase 1. And then even getting in-- a bit too far. There we go. I'll play the little--

The cool thing is, you can play these little videos and stats should start. There we go. So you're able to sit through and talk through with the client all these bits and pieces. We loaded in a few SketchUp 3D models into this as well, just taking them out of Revit quickly, smashing them as SketchUp 3Ds for some of the stations. But this actually became a pretty powerful way for us to engage with the stakeholder and talk them through, and then leave them with the file that they had. Because the problem-- again, in InfraWorks-- is client's got to have a copy of it. And clients don't really use those type of tools.

So this was something that we're able to really present some information. And like I said, InfraWorks can do this. But you can't send these models to them through InfraWorks, because then they don't have the copies. So this is all free, all easy to do. And I'll stop playing the cool little animation now.

I'll see if I can quickly find a station. But I think everyone's seen a SketchUp model. The blue line is the rail possession. So that was the actual alignment area that we were allowed to construct within. And then, yeah, each of these, you can actually get down to individual chainage points, if you needed to, to go and investigate that particular area. So it's quite an easy way to get around and build something up, if you're ever working within InfraWorks, an infrastructure package. So anyway, I just wanted to highlight, if you ever have to do something like this, all of that stuff's all great. But sometimes, there's some pretty good stuff just out and about.

So when we started getting up into the rail corridor possession, we started doing some terrible, terrible value engineering that the contractor likes to do. So we're starting to look at how we were processing this together. So we had this 2D survey. We spent a while getting that into Civil3D. We then generated that Tin because we couldn't get the original design file. We then had to use InfraWorks Model Builder to basically pull that across. Has everyone seen InfraWorks model builder? A couple.

But essentially, it just brings in a whole area. Now it actually has a 200 kilometer square limit. But if you go and stitch them together, you can create KMZs for each 200 and square, because we had a bit over a million square kilometers. I don't know what that is in feet, sorry. But we know that that was combined. We basically stitched each of these models together and then aggregated the map into a master file. So if you're finding that you're ever running into that limit, just create multiples and then link the new ones back into the master. And you can get unlimited size in terms of that.

And then the alignment setup and redesign. So we had the original MX alignment that we pushed through to the Google KMZ for the presentation. That, we then brought into a software. It's a European software called ProV, which sits on top of CAD. And it designs all the rail line according to the European codes, which is what Malaysia uses. So we were taking that, bringing that alignment into Civil3D, and pulling it back in, and then feeding the survey tin up for the setup there as well.

So as I said, each of these projects was then split into each of these sections. So outside the master InfraWorks which had the original model builder mass in it, each of these was broken down into the individual Civil3D models being around 10, 15 kilometers. Even that's quite heavy. Have we got Civil3D guys in here? A couple. A couple. So we found that quite heavy. In Australia, we use a product called 12D quite a lot. And as like a simple comparison, like a 50 kilometer road in 12D is about 4 megabytes. And it opens ridiculously fast. So we had this interesting-- just slower issues, where we had to upgrade a lot of the hardware.

So as I said, quickly, for those who haven't ever seen Model Builder before, it's pretty much just a tool that sits inside of InfraWorks. You go into InfraWorks itself. There we go. We click. We zoom around an area. This is where I live, so I thought I'd pick this one here. Zoom into a spot. Go and select your lines. Yeah, you've got to draw out the area that you actually want. There we go. Click, click, click. And then that then gets converted. It definitely doesn't go that fast, but we're talking two minutes to generate this.

And then depending on the area you're at, you can get some pretty good base-level geometry, especially if it's a bigger project where you want the context. The real value, I think, for Model Builder is just having extra context in your project. I don't think I'd trust the data. I don't know if you can see those bridges. They're like doing this sort of stuff. But as a starting point, and when you start bringing your other data over the top, it overlays really, really well.

So once you start adding your more accurate data that's going to sit on top, it does cause interesting problems at the intersections. But I'll show you a couple of those later. I hope they're not finishing. That was early.

So I wish I had some magic for the ProV, but we had to do it pretty dodgy. Basically, clean up the AutoCAD data and pull out the line and convert it across. And the only way that we could do that was with SHP files. So literally, it was like a slow bring it across, convert it back in, and then eventually, customizing each of those from the subsections of those profiles. So I wish I could say I had some automated awesome solution to do that. But there was just no way to convert those subsections from ProV. It just had a really bad transfer.

But the point was, we got to this point. So again, for those who aren't familiar with Civil3D, essentially, we started with a pretty basic daylight benching layout for the corridor run. And then this was just the section view of each of those as well. So due to the guys not having really good Civil3D experience, the way we started taking them through was doing some basic training and just starting to use the basics. And then we got them heavily focused on looking at how to optimize a sub assembly. Because what we found is in the initial phases, they we're making hundreds of these little sub assemblies. And the similar Revit-- if we've got some Revit guys, here-- I guess, the more flexible you make a family, the more options it could deal with. And sub-assemblies are essentially the same. You can build some really interesting parametrics into that, and rules.

But where this got us was this was really easy to start looking at the rail possession. So the problem that we had is this area here, this outline, that's the existing rail segment. So this was the one that was already there. And then this was in our new line going across.

Now the original designer had put in 94, I think, interfaces while we were crossing over, which means we had to add additional cuts. And it was a lot of operational hassle. So we got that down to about 75 and had to go back with the client and start reviewing that. So this was a really good way to start doing that. Because without changes to the alignment, it was using this simple drawing here, to quickly show that even though we're editing the terrain, we're still within the possession. So we were focusing on areas where we were coming really, really close-- making sure it wasn't near property and things like that-- and justifying that to the client.

And then eventually, we got to have our own awesome 25 minute walkthrough to convince the client of our sections. And so you can see, first, it's pretty ugly. Like, where's all my textures? The problem with InfraWorks is if you're in a rural area-- because I use Bing Maps. And Bing Maps are too low res. It won't actually bring them in. So this was just showing where we had decided the new alignment should go, and showing all the different interface points. And again, we could watch this forever. But I think we'll move on.

And then, the bridges and stuff. We were just using the out-of-the-box InfraWorks ones to start getting that sort of stuff across. So, yeah, where are the maps? So what we had to do-- because it uses Bing, the buses went back and went, there's no way we're showing that to the client. It looks rubbish.

So how do we actually get that across? So what we found is there's this free product out on the web called Terra Incognita. And it has all these different multiple source maps. It's a free product, which is great. So what it is, it literally is just like, you come in here. You have all your different map sources available. So you can actually select any source from anywhere. So if I want to change it to Google Maps, it'll swap it out with the new map across that location, or if you want to use any other system.

But once you've selected the area that you're interested in-- let's do satellite. Oh, this is satellite labels and things like this. So you can go and create what's called a-- where are we here? A rectangular section, just similar to InfraWorks. And it will save all those out as images. But when you actually save the images out, you can save them out as ARC views, which is Esri's format. And those can be just linked straight back into InfraWorks.

So we found this quite useful for doing things like if people wanted to see Google Street views rather than the full on satellite maps that Bing automatically brings in, and you wanted to be able to load them both in the same time and swap. You could line up with the concept engineering view and the proper engineering view.

The other thing that this made really useful is for those who know, InfraWorks reloads in your Bing maps every single time. It's always pulling them fresh from the internet. So if you're looking over a large data set, this thing's just churning. Whereas this just loads all of those images in an instant.

So again, if you're ever struggling with that-- and you can see, this is the typical issue that you run into. So you'd be using a source of data. And then all of a sudden, you're coming across a bunch of clouds or really low res stuff and things like that. So, swapping all that out of the way and getting the right image stacks in there. So if you ever have that issue, just look up Terra Incognita. It's from our source forge. Download it and get it going.

So obviously, attribute your copyrights if you need to. We're in Malaysia, so we didn't have to. So as I said, we started then focusing really on the assemblies. So after we created and got the basic corridor approved, the client was happy with our new corridor, we really wanted to spend the time getting into the flexibility of this. So I'm not going to go in depth with what we did. I'll just touch on if you ever get into this situation.

So here's where we started with, and then this is, I think, one of the last iterations before it went through again, just for the single one. But again, you can see what you get at a basic level. But if you really get in there and customize these. You can add all these sort of rules. So as it encounters different terrains and grades, it will automatically reshape itself. So we went down the track. And unfortunately, to start with, the guys were just constantly redrawing them and adding them to tiny sections of the corridor.

And so as a result, you basically don't get flexibility if the designers make a change. So getting back and spending time, if you're ever in this situation of managing Civil3D guys on this, I found it a lot more common than I imagined, that they just wouldn't develop good assemblies. They'll just do very static ones. And then you end up with this problem with just hundreds of these things being hand drawn out.

So make sure, if you've got civil guys and they don't know how to do this, send them to training or really make sure they spend the time. Because definitely, when you start dealing with the interfaces of different changes, it makes all the difference in the world if you can get Civil3D to figure it out, versus people will do this to a point and then they'll hack to terrain with all these break lines and other things to make it work. So if you ever get in that spot, try and minimize the number of assemblies by adding the flexibility, which is the same as Revit content.

So moving forward with the network, so what we got is once we get to the lack of Civil3D models experience, we had the guys just on the corridor that were quite good. But our piping guys and all that had no experience in this. They were all Revit guys. So we started going down the route of piping/conduit networks being all done in Revit, the bridges being done in Revit, and then the culverts and the overhead electrical.

So we made a choice to just keep the line split at that. So Civil3D, we kept the rail in terms of the actual rail lines and stuff. I've seen other projects where they'll actually go and redo the ballast and everything in Revit. We made a choice just to leave it all in Civil3D. But these pieces were then modeled on top of that. So usual stuff, bit of training around it, getting them thinking about lots and-- I don't know. Has everyone here model bridges in Revit? A couple?

So I wish I could say that we built an awesome, dynamite tool to do it. But we didn't have the time for that. We managed to agree on a couple of systems for this. But most of this was hard modeling. When we first started getting the models back from the consultants because we had a certain quantity spec to meet, it was really sending that back and retraining them. So they started off with this as one giant in-place family.

And so then we said, no. We need to break that into pieces, and so starting to split that up. So the way we did that-- I'll show you some of the model checking stuff we did. But using that to basically-- there's a couple of tools out there that will quickly check these models for in-place objects and stuff. And we would just reject the models on that premise.

So again, simple, simple ideas. But just make sure you're splitting it down to those key objects. They did get a lot better. So getting later on in the game, we were doing viaducts and things like that. So the team slowly increased the complexity of the work that they're able to do. Unfortunately, I wish I could say the drawings were also produced out of Revit. But it was very much the team was still able to draw first and model second, which unfortunately does cause a few issues in terms of the coordination.

So one area where we did do some automation was the culverts. So because there was 289 of them, which was a lot-- and the engineering team was currently managing the culverts themselves. So they looked at two different systems for culverts. And they finally agreed on one. And everyone standardized on it, which was great. So the way we did it, each one of these was in an individual file. We were just sucking in all of this data here. This was a Revit project file.

And then we just had global parameters just stretching the walls and floors and reference planes everywhere. So we didn't do it as an individual family. The reason is, is because if any of the culverts updated, they had their own drawing set that was pre-attached to that as well. So we needed to revision all that too. So we didn't want to have the risk of it getting in a file of like 200 of these things. And then the other thing is then having them really far away in a single Revit project.

Like, you have one there, and then a kilometer later, you have another one. And then how do you manage? Like, do you set them up in batches of 10, or 5, or 2? So at the end, we ended up using-- there's a tool out there called Dynamo automation. And so what that allows you to do is create master and slave graphs for Revit models. And so each time, you can set it up so it'll go through a folder of models and run a script on each one of those files automatically.

So if you've got a batch process Revit models with Dynamo, as a tool that echoed Dynamo Automation. It's open source. It's from Andreas Dickman, who also writes Clockwork. And it will actually batch process that type of work. So we had really good success for this, only because everyone agreed to build the same culvert over and over again, which was nice.

And then the stations as well. So the stations, we got pretty good alignment with everyone being in Revit. All the disciplines mostly aligned pretty well. We then started using Revizto to start using that for the design checking process. So with the Revizto stuff-- hopefully, everyone's seen Revizto. It's built on Unity platform, loads all your models in, a bit of issue correction. The key thing that we were interested in, though, is the 2D sheet checks. Because with the Revit stations, we got a relaxation on the bridges. But the team was very keen to make sure the models matched up with the drawings here.

And so Revizto has this nice sort of compare tool. And it's quite interesting, where you start doing this type of work with the overlays, that you can see, OK. We've got the tanks in there. We got the pump. I guess someone didn't want to draw these pipes. And so then when you started laying the other disciplines over the top with the mac work stuff, when you found this issue constantly of people just not modeling everything, it really made coordination quite easy to check and feedback to the team. So we found the 3D model compare valuable to guys who need to put that pipework in there so we can coordinate it.

And then finally, each one of those models were pushed back into the InfraWorks model. So again, we had this master stakeholder presentation model to work with. So each of those. With InfraWorks-- I mean, with Revizto, the reason we chose it just as a stations is it's not really good at dealing with colossally massive infrastructure. It can bring in Civil3D models and things like that. But we found it not very useful for that larger civil work itself.

So again, our model's slowly getting better. Again, this one goes for way too long, so we weren't going to do the whole thing. But you can see now where we started bringing-- I don't know why, someone really liked the ambulances-- started bringing in the terrains. And even then, you can see the scale, the updated Civil3D terrain itself. Because we thought we'd embed it all within the image. But the problem was we found-- and sorry these aren't very sexy. This is exactly what we were presenting.

But we actually found it quite useful not to overlay the image for the final, so that the design team-- I mean, the stakeholders and the client-- could actually see the impact we were having in their possession corridor.

So originally, we did have it all overlay. But it became quite hard to see this level of interference and have discussions around these areas. So in this space here, it obviously doesn't really matter if we're over by a little bit because we're not impacting any settlements. But in other areas where we've got-- again, using the satellite views, we've found, provides a much better sort of interface for really seeing the difference between the road and that sort of thing. So, oops, come on. Keep going.

So from there on, we started cranking out a lot of models. Everyone started going nuts. So in terms of the total models, we had the five InfraWorks models going. We had the 15 Corridor models. We had 150 Earthworks models, and so on, and so forth. We'd rather we ended up with 1,004. Because even with the consultants, we would find-- I don't know why, but people over there have this weird rule where Revit models have to be 10 megabytes. So we kept going back and saying that's not a real rule. But we would seriously get a model with like, one piece of pipe and like, four bends.

And that was linked into another model, and another model for the hydraulics model. So we had this massive, colossal amount of information to deal with. So 300 of those are the culvert models as well. But yeah, we really had to get through this rule of the 10 meg thing. So you'd have a model where it was just like a stair, just like one stair. And then another model for-- ah, it's painful.

So anyway, where we started going-- we started this thing off in Google Drive. And I'll touch on a bit of cloud software we used for that. Eventually, that's started falling over. So we've moved to BIM 360 Docs for about six months. That worked pretty good for the design uploads, but it really started falling apart on the project control. So then we moved it across to Aconex. And I know I didn't fill out these bottom parts.

But Aconex is a platform owned by Oracle. And it just has a lot more-- it has a lot better information and traceability management on really large scale jobs. So the problem we had with Docs was it worked really good at the beginning as a design interfacing piece and getting everyone bulk uploading their models every week. But we started struggling with the whole version management to revision management, because the versions of Docs are individually updated every single time. And a revision isn't a version change. So sometimes, we'd be getting work in place stuff, not real revision stuff. And so that became too hard to control on the job of this size. So that was the reason that we started switching to Aconex about three months ago, just on the cost group construction.

The transfer wasn't too bad. The Aconex team's actually pretty good at mass moving data. And then it was just getting the team to shut down the BIM 360 Docs side. So, yeah, as I said, gDrive. I don't know if anyone's used gDrive. It's like $10 a month. And we still use it at the moment. It actually holds all the point clouds. So I covered, like, some of the point cloud work that we're doing.

But it's really, really easy to get up and running, dump massive amounts of large sets of data. Because you can actually hold up to 5 terabyte files in gDrive. And only one person has to pay $10 a month for it, so other platforms I haven't seen that manage that type of information for that price. We did look at it with a couple of other tools, like Pointerra for the point clouds, and things like that. But they were way too expensive.

Obviously, it sucks you can't view the models. You can't view the drawings. BIM 360 Docs is good, until you really have seriously a large amount of models. And then you're just constantly going through these files trying to figure it all out. And we tried using the model, some of the other things, but kept finding we had to keep creating these model folders and moving files between folders. And it's all very cumbersome at the end of the day.

So I want to get into just where we started getting to the automation stuff. So the key things. One of the things we had to deal with was with file services, we were only getting CAD data from them. No matter what we did, the sprinkler guys like were like, no, not doing this. And then the model's not meeting the BEP. Especially for the first three months, we just couldn't get them to model how we needed to, to meet the quantities and the basics of the BEP.

And due to the amount of information that was being generated, we had to put systems in place to start automating those checks. So a couple of major-- the Dynamo ones, we started doing some existing condition scripts and some piling stuff. There's a lot of piling, obviously, on these bridge areas and some of those bits and pieces. The culvert designer was huge. The piling one was pretty easy, just depth by terrain checks. So it hit a point, figure it out, and then extend the pile to that length. So nothing super fancy there. CAD 2 Revit-- sorry, I've just got to find that file. Because it's a pretty big GIF, but it won't play in there. But where is it?

I'm blind. It should be right in front of me. OK, maybe not. Ah, here we are. So this was an example. So what we started doing, when it came to the fire project, we were bringing in those files, rerunning them over the template. That would actually read the AutoCAD data directly, and then generate these as a live 3D component.

So the reason we decided to do not reading the whole model, but do it in pieces, is because it's easy to QA the work. So this just made it really easy to bring these things across when the team wasn't playing, which the fire guys just refused to. And we couldn't do anything out of that.

We also used it for the conduits. So anything we got from the survey that just had the conduit files, get that, project it onto the terrain. In that area, basically, we wrote a rule about putting it 600 mil below the ground. And then we'd just run that through. So we found those pretty handy ways to quickly move survey data to Revit data.

And then the model auditing process, as I said. So we had the Revit visual, the Revizto visual, and then really bringing it back into Navis for the stations and doing clashes. And then for the individual files, we'd be running through model checker. We did a little bit of Dynamo, but not as much as I thought we'd end up doing, and then pushing that into PowerBI.

So with the model checker, I don't know if anyone's used this tool before. You can write some pretty extensive rule-naming conventions. So when we started getting into it, we started breaking this thing right down and going, OK, you start off with the basics. Knowing place, families, know this, and know that. But then we started delving right into it, going, OK. Well, columns that are outside of a floor-to-floor bounds. And make sure there's architectural flaws and structural flaws are separate, and sheets, and so on.