Design a Highway in a Day: Using REM, Our "Rapid Engineering Model”

PHIL LANGLEY: Hi, everyone. My name is Phil Langley. And today, I'm going to talk about how to design a motorway in a day using our rapid engineering model. I'm a director at Bryden Woods. We are an integrated architecture and engineering practice with offices all around the world.

We have architects, engineers, creative technologists, of which I am one, and I'll talk more about that in a second, as well as designers and analysts. And we're working together to build a better built environment.

Now, I'm actually an architect by background. So even though today I'm going to talk to you about highway design, I'm actually an architect. But I lead our creative technologies team within Bryden Wood, which is our specialist software development and design automation group. And here we are.

So within this team of around 30 people, we're not software developers, but we do make software. Most people you see on screen here are architects or engineers with experience of designing in the built environment. And together, we are focused on building design automation technology.

Lots of people talk about design automation. And there's lots of different ways in which you can achieve it, but what do we mean by it? So from Bryden Woods point of view, and from our team point of view, we're interested in automating because of these kinds of reasons.

So there's unnecessary variation and complexity within design proposals that we see. This provides or creates unsustainable levels of cost and time delay, which is really a function of a lack of control and transparency within the design making process.

And also, kind of interestingly, I think the domain knowledge is being lost within our industry. There's a huge amount of domain knowledge across all sorts of different design and engineering teams. And we're just not capturing that. It's not being reused. And ultimately, at some point, that will leave our industry and then we will struggle. Not just to automate anything, but just to design something full stop.

And fundamentally, we're looking for consistency of outcome. Automation deals with that current state of inconsistency, which is inconsistent in terms of quality, safety, but also sustainability. And all sorts of other different factors that drive the quality, and ultimately, the performance of our built environment assets.

So actually, we said design automation. But really, ultimately design automation for me means configuring. So not designing, but configuring. As I said, I'm an architect by background. So I understand the challenges and difficulties of manual design. And configuring is a much more beneficial and much better way of going about the delivery of our infrastructure and built environment assets.

So configuration for us means the capture of patterns. So human readable design rules and physical components. And turning them into something that's machine readable ultimately. So as I say, domain knowledge exists everywhere in our industry. And through our patterns approach, we're trying to capture that domain knowledge.

That's typically something human readable. Very often, kind of maybes, sometimes, could bes within design decisions. And trying to turn those into more hard logical operators like yes, no, if, these kinds of statements. And we've built these kinds of configuration technologies across all sorts of different sectors. I'm going to talk about roads today. But we've applied this methodology and this approach in apartments, schools and education, health care, as well as data centers and rail.

So that's a high level idea of the approach. What might that mean for the people involved in configuration? So this changes a little bit the assembly of what people do if you're able to automate design. And we're talking about speed benefits here within orders of magnitude and going from one year to one day in the case of a road. It changes a lot what we do and how we organize ourselves.

And so this diagram is explaining a little bit what that process can look like. And so a configurator sitting in the middle of our diagram here is basically connecting project specific inputs with project specific outputs. So you still have your project specific team and feeding in those specific contexts, the data, the constraints that might be relevant for that project.

And they're looking for the same kind of outputs from a design automation or configuration process. They need geometry models, they need metrics, they need data as well. So really, in the middle what we're trying to do is build a configuration system around an automation logic that is consuming products, rules, and all sorts of business drivers in the form of data, really. And those are being provided by client stakeholders.

So it's interesting, I think, important to note here is this is not simply about a piece of software that is applied into a design problem. This is about an assembly of domain knowledge of stakeholders, but in a slightly different way than we might traditionally see on a design and delivery of a project.

So here's a quick overlay of that. So the project level design engineering team sitting either side of the diagram connected by configuration engineers. So we have configuration technology. We need some designers and engineers to operate that tool.

The purple box is the design automation dev team, which you could understand as Bryden Woods creative tech team, in this case, creating the design automation itself. And then, working in collaboration with the programmatic design engineering team who are providing that domain knowledge in concert with those client stakeholders. And actually, ultimately, the client themselves.

So this is really kind of the state we tried to get to through the application of design automation and ultimately configuration technology. So repeatability in terms of content, rigor in terms of rules, and transparency and evidence-based approach that is accessible to the same kinds of stakeholders that you see in conventional projects. But the organization of those stakeholders is slightly different.

And so that's the general approach. Now we're going to dive into the specific example of the rapid engineering model. So with apologies to Michael Stipe and the team, REM is something we've been developing with National Highways in the UK over a number of years in order to automate the design of major infrastructure assets. And that includes new build projects as well as upgrades to the existing network.

So for those of you that don't know, National Highways is the UK government agency with the responsibility for the strategic road network in the UK. And they deliver billions and billions of pounds worth of upgrades and new projects to the existing road network in England.

And we were brought in-- Bryden Wood were brought in to provide innovation and somewhat, you could say, disruption and that's conventional way of delivering those projects in order to drive consistency in order to remove error and reduce costs and time delay. But also to increase quality and safety and predictability. Clearly, safety is the single biggest driver in the transport infrastructure project. And it's very easy for us to talk about costs and time. But really, working with a client is the owner operator of something like a strategic road network, safety is clearly paramount.

And so they are looking for new ways of delivering the road assets for the future, which is really also in a change in context as well. The application of electric vehicles, self-driving technology, all these kinds of things as well as different changes in capacity and the use of the network more broadly from let's say logistics point of view versus simply kind of people and passengers.

All of these kinds of challenges are something that the Rapid Engineering Model was developed to contribute a solution towards. So as I say, this is not just a software project, this is a people project as well. So we've worked very, very closely with National Highways. But also with Jacobs Engineering Capability team in UK based in London because they bring the sector knowledge. I've mentioned a couple of times already that I'm an architect by background, not a highways engineer or civil engineer.

And similarly, in Bryden Wood, we don't involve-- we don't get involved in the-- historically, the design engineering of roads. So we work very closely with Jacobs team as well as other teams on the National Highways supply chain umbrella, but especially Jacobs to apply their sector knowledge, their domain knowledge into our design automation and configuration technology.

So how does that really work? As I keep saying, don't design roads. So someone's got to help me understand how you design a road. And the first part of that is rules. So rules are fundamental to all design automation. Rules are fundamental to all configuration technology, not just that we build ourselves, but anything that you might see in the industry or beyond.

So this is a list. I'm not going to go through every single document here. Don't worry. it's not like I'm going to click on a link to each one of these documents. But this is to give you a flavor of the kind of rules that we're able to embed within the Rapid Engineering Model.

So what we're trying to do here is take all of that domain knowledge, all that experience, and all that design requirements and build out into the algorithms that operate the design automation software. So as I say, I won't go through every single one of these. But there's a whole ton of stuff that deal with all sorts of different aspects of the road design, whether that's about the carriageway itself or drainage or any other kind of safety aspects as well. The list is quite extensive.

So all of these things we're working-- we've been working with to capture from documents, but also from experienced designers and engineers who've actually already had to apply these rules in specific contexts. And that really is the basis of what we do.

And that feeds into this process. So REM is really a technology that takes a bunch of inputs and provides a bunch of outputs in the middle running through an analysis, evaluation, and automation and optimization process. So the inputs, they're always consistent. We're always looking for the same kind of inputs. We want to have a digital survey that captures the road asset we want to have. Environmental data that describes the wider context and situation that the project is located in. And we need the existing asset data.

And actually, whether or not that's an upgrade of existing piece of road infrastructure or if that is a brand new road, there is always existing asset data because we're always connecting into something. The REM process generates a standardized set of outputs as well, so a design layout in 2D and in 3D. So it can be consumed in a whole different range of products, whether that's Civil 3D or even Revit, actually, as well as more coordination type software like Navisworks or Cloud Collaboration Tools.

We're also generating Geospatial Data. So GIS data that connects to various different client stakeholder systems as well as supply chain systems. And also performance and metric data, again, whether that's about cost and program schedule or environmental sustainability issues or safety itself.

And the REM process really runs through these kind of relatively explainable steps to create something that's quite sophisticated and quite interesting and important. So analysis is really about just picking up all the input data and measuring it. So trying to understand what, for example, the curvature of an existing alignment might be, or what the gradient or topography or embankment condition might be in any given situation.

That's really just about measuring those inputs. And evaluation in a process is trying to understand what those measurements mean. So what do they mean from a rules point of view? What do they mean from a business performance point of view?

So as an example for that, what you're trying to do is say, OK, well in an embankment condition, I might have a very steep embankment that ultimately would require a lot of earthworks in order to make it more suitable for construction. But there's a threshold there that decides whether this is good, bad, or indifferent location for any kind of construction to happen.

So that evaluation is really something that is very, very closely linked to the rules capture that I showed earlier. There's really embedding those design drivers, which ultimately are business drivers, right? And trying to understand from that soup of digital inputs that we then measure, trying to turn that into something that is meaningful to the client stakeholders, but also meaningful to an automated computational design routine.

So step three and four in this diagram, we're really trying to consume something that is meaningful for any kind of generative or parametric design process. So those inputs, digital survey data, maybe a point cloud or LiDAR capture, quite difficult for a computer to operate on that in a productive way. So the analysis and evaluation process is really about turning those inputs and making them into something useful. Optimizing a design that is operating on those evaluated inputs to create a standard set of predictable outputs that everybody expects to see.

So analysis and evaluation. So this is the kind of, I would say, the core method of the Rapid Engineering Model. So what we're doing here, this is actually a real road. This is an alignment somewhere in the UK. And each of those lines that you see segmenting the road, each one of those is what we call a frame point. So there are 10 meter increments.

And we are sampling the road at 10 meter increments for analysis and evaluation purposes. So that means we are taking into consideration curvature gradient, verge width, side grading, 34 different topographic layers, 32 different layers of data around visibility and safety, tons of environmental risk data. And this has grown over time as we've developed the tool.

And ultimately, each one of those 10 meter increments on either side of the carriageway, we're storing more than 500 unique data points that are analyzed and evaluated, and therefore, directly comparable to operate within our automation process and reusable by the system itself. So this is what that sort of looks like really.

So what we're trying to do here is extract useful information from the soup of various kinds of digital inputs and turn it into a common language, actually. A common data language. So whether the data is visibility or topography or environmental factors, we want to apply risk level.

So the risk of making a construction based intervention in that level in that location. So whether that's from a safety point of view, from a capital cost point of view, from a maintainability point of view, or any of those kinds of things, we're building a data model of any given road here that understands the suitability of any 10 meter increment for the kind intervention, whether that's a Gantry or a piece of technology cabinetry or drainage.

The implications for that are a whole range of different criteria, which allows us to automate and optimize designs against any number of factors. So any given road in the UK can have all sorts of different constraints, right? You can sometimes-- it's much, much more challenging to optimize the design for sustainability or low environmental impact.

Sometimes, it's actually quite straightforward to do that because of the nature of the particular site location. So this is giving the designers and the client themselves a readout of what the suitability of a road-- any road situation is before they even build anything.

So that's what you see here on this graph. Obviously, there's a kind of tyranny of dashboards. You can imagine we generate tons and tons of data in this process. But I just want to highlight the graph at the top here, the one that's the bar chart at the top, which is really the road suitability. So what we're doing here is visualizing 30, 40 kilometers of road against hundreds and hundreds of different data points in order that the client can get a visual appreciation immediately of how challenging or otherwise that road context might be for any given project intervention.

And again, this is the same method for whether it's kind of upgrade of existing assets or a whole new alignment or connection between the two. So there's a kind of value here before we even automate the design process. We're able to evaluate the suitability or the risk factor of the project context itself.

And obviously, we can run this not in a linear way, not in sequence, but actually in parallel. So you can run this kind of process against 10 schemes at a time or maybe 100 schemes or maybe all of the schemes. So you get a very of interesting insight into the current state of the asset and the asset portfolio in relation to a whole bunch of other business drivers.

And actually, this kind of analysis and evaluation, even before we run design processes, naturally creates the opportunity to revisit and revise some of those design rules and to challenge maybe some of the assumptions that have been embedded in highways engineering for the last number of decades. And maybe the application of new thinking, whether that's practical innovation or otherwise, into different parts of the design requirements can have a material effect on how easy or challenging it is to deliver any given road infrastructure project.

So I'm going to do a little bit more of a deep dive into-- well, into one of the specific cases just to illustrate the scale, really, of what we're doing here. And as I said before, this is really the heart. This kind of analysis and evaluation is really what allows the design automation to happen.

And so this is about visibility analysis, these diagrams that you see on screen here. So what we're doing here is trying to analyze and evaluate every potential position for any given piece of equipment along the highway-- the proposed project. Again, project can be anywhere between 30 and 40 kilometers in length. So that's split into 10 meter frame point increments.

So what we're doing here is not analyzing a design that we have produced. Instead, we're coming up with every possible location for a Gantry, every possible location for a piece of signage, or a piece of technology, cabinetry, or one of these things.

And then, we're mapping that against every single lane position. So obviously, this is not-- these are typically not single carriageway highways. You can see in the diagram in the top right they're either three or four lanes in either direction. So there's multiple different driver positions we want to check to see if that driver can really see the Gantry and the signage in any given-- any possible location.

And also, the driver isn't always driving a car. They might be driving a truck or any different vehicle, which gives the driver a different physical height on the carriageway. Again, checking for that visibility gives us an appreciation of the suitability of any given location along 40 kilometers of road before we even think about designing something.

And so these are all the things we take into consideration. There are all sorts of different pieces of equipment that go roadside. So whether that's signage in terms of something that the driver has to see, which is obviously governed by those design rules that we talked about earlier, or whether it's about CCTV, which is looking to have maximum coverage of the road network itself from a safety point of view.

We're checking against all of these different things, against all these different kinds of vehicle types in different lane positions. So there's a lot of automation required to go through this. Simply not possible to do this manually. And we do it across all sorts of different conditions. So this is just a small section of the array of methodological diagrams we have for these kinds of calculations that are going on in the background.

And that really is one specific example, an incredibly valuable example, I think, because it's about safety of the power of this kind of approach of taking that human-- there's nothing in this tool, nothing in these diagrams that the current engineering community in the UK doesn't understand or doesn't know about or is not aware of. In fact, we work very closely to apply these rules to build out this functionality.

But the human part of this simply does not have the time to make all these calculations manually nor, more importantly, actually, they don't have the time to do anything with it, to interpret this, to turn it into something insightful, something meaningful.

So this is just one aspect of the analysis and the evaluation process that we're building or we have built that is then multiplied across environmental factors, across constructability, and cost and these kinds of things to give an incredibly sophisticated picture of the viability of suitability of any given road context and also to drive the automation.

So this is what it ends up looking like. So on the video earlier, we showed the kind of red, amber, green. Here is the yellow, amber, green in this particular location. This is overlaid in some geospatial software. And the lines that you see on the left and right here are those frame points, the extended nature of the line is just for visual clarity, let's say, within the platform.

But you can see this is a kind of data model-- visual data model of the analysis and evaluation process that is generated and is incredibly valuable at a network scale as well as a project scale.

And this is what it looks like in 3D. This is a Navisworks model. Again, this is a real scheme with everything sort of smashed together all in one. So just to give you a flavor of the amount of data that's really in here. This is, as I say, it's a real scheme, although spiky, wackily colored lines represent different data points on frame points along 10 meter increments the road.

All of the analysis and evaluation captured in one single place, in one single model, actually, which is in itself is already incredibly powerful. We go from that array of inputs into this kind of singular source of the truth in a 3D environment that is meaningful to highways engineers as well as client stakeholders, supply chain, neighboring properties, anybody that has an interest in how this project emerges and gets delivered.

All the information everybody knows is stored in this file for anybody to interrogate and consume. And I think this is, somehow, one of the most powerful parts of what we do in REM is to try and make this data transparent, to make the process transparent, to make the decision making process evidence-based.

Because this is a single model file of evidence. And it's also analogous to a digital twin, right? This is the existing asset before an intervention. You could imagine once we create a design or generate a design for any given context, this data is updated to reflect the new or the proposed situation or even during delivery situation.

So this is a kind of digital twin logic runs all the way through this as well. So each one of these project models represents a digital twin of a discrete project. Connected together is a digital twin of not necessarily-- not only the live data of an operational asset, but the underlying physical condition of that asset as well.

And so then we take all of that wacky colored data and we do some design automation. Finally, we get to the design automation part. But this is as simple as it gets, really. So we take a road scheme, the starting reference point. And we're basically trying to place physical components on one of these frame points. And you see the red, yellow, green colorization here.

So the initial placement is based on the rules-- the ideal placement based on rules. And then, we look for alternative positions that are better. So upgrading from red to yellow, upgrading a yellow from a yellow to a green according to the evaluation criteria and checking against the rules thresholds.

And obviously, this is a very simplistic snapshot of it. But this process is more or less as repeated across all sorts of different asset types in parallel in order to then negotiate the space. Clearly, there's not always-- not every rule can be complied with on the first iteration. So there's, again, there's a design loop going on here that's trying to resolve as many of these things as possible.

And again, REM is a very open system. So these kinds of red, amber, greens the implication of that is very flexible. So different projects might say, OK, red is no go, absolutely not, we never make an intervention on red. But we will tolerate green or yellow. And you can make that slack.

Or depending on your suitability analysis, you can say, actually, let's go for it. Let's go for everything green. Let's see if we can minimize construction in the verge. Let's see if we can really minimize the impact on sustainability. Let's see if we can really build the safest section of road and really push the tools to try and solve it for only green points.

And that's the design automation. This slide is-- that diagram is as simple as it looks. It's the analysis and evaluation that really allows us to make an algorithmic process that looks like this.

And then, of course, in the end, there's some Excel files, right? Some tabular data that you get out of all that. So going from that array of digital inputs, that's soup of data through the analysis and evaluation. Ultimately, what I'm trying to get to is, where am I going to put my Gantry? Where am I going to put my signage? Where is the CCTV pole?

And I want to drive the development of the creation of an actual layout in a 3D environment. So this is a snapshot from the database that sits behind REM. These are all the-- can't even remember what scheme this actually is. But one of the many schemes we run REM on, the different types of roadside asset, the location, the orientation, the elevation, everything down to the last inch really of where this thing needs to go.

And this is what we can position. So the REM connects to something that National Highways have also developed called the Digital Product Catalog. The REM sends that data that I just previously showed to the digital product catalog which returns, then the suite of products that are in 3D format that are required to resolve that scheme, whether that's, as I said, Gantry or signage, technology assets, drainage, barriers, retaining wall systems, and all of these things are also populated within the model.

And so the DPC, Digital Product Catalog, populates the Civil 3D model. And therefore, the REM is providing the data points, really, along the alignment that is then populated from that product catalog, that parametric product catalog. But you can see the level of consistency and standardization. This is driving. It's all of these items are pulled from a standard library.

They're all being placed according to the same set of rules that are implied in the same kind of analysis and evaluation criteria. This means that the scheme that you're designing today will still be comparable to a scheme that you design with a completely different team in three years time or five years time even.

And that you can move from the question of what if we did-- what if we made an upgrade to the stretch of road? To a level of detail here, a digital twin data model with 3D BIM asset information to go with it, you can do this in, well, a day rather than 12 months or 36 months.

And that's a really, really [INAUDIBLE]. So it goes without saying that that's a really powerful benefit of what we're doing. Being able to get to a level of information in order to make decisions so much earlier in the process gives the client just so much more agility to respond to changing environments, whether that is around the introduction of new technology, the potential change to the network itself, whether that's about funding, whether that's about behavior of the general public and what they want their road to be like, capacity modeling, any change. This tool REM allows the client to think completely differently about the timeline for asset delivery.

Because not just then about a 3D model, it also has the data behind it persistently. So you're always able to understand the why nothing is lost throughout the design process. And in fact, what we're doing is really pulling all of that information that emerges over the long timeline of the project delivery and bringing it much, much earlier in the process, right? We're bringing it within 24 hours, in fact, of having those inputs and wanting to start thinking about designing a road or delivering a road.

And that means your last responsible moment from a client stakeholder point of view is just pushed way, way out. You can understand all this information cheaply, quickly before you've even had to engage a full design team, before you've had to even secure funding, actually. And so it's incredibly powerful way for a client to organize their asset portfolio.

And what we're really, then, delivering is a completely different way of thinking about design, right? So the diagram that I showed before where we kind of switch around the idea of configuration logic and these different types of rules. So actually, that manifests in these kind of big three characteristics of a process. There's a rule-based choice point optionality.

I said we can design one road in a day, but you can design as many as you like in a day. We're not designing series anymore. Designing in parallel. So we can develop many, many, many different possible solutions, optimize against all sorts of different criteria that really relate directly to business drivers. As I say, as I've kept saying, safety, cost, schedule, sustainability, all of those business drivers are intrinsically linked. And this makes it explicitly clear.

And how to navigate, then, a solution space by which I mean multiple solutions that are all quantified in the same way, they're all represented in the same way. And I've used the phrase mass customization here now. That's often applied in a way to buildings. But I think that's, for me, I don't really care. I think the road or transport infrastructure project is also about mass customization.

We have a product set-- we have a set of rules and we're applying it within a context. And we want that product set to evolve to deal with those different contexts and we need a method to apply that customization at scale. And so this is why, I think, mass customization is also valid in the roads context.

And then, having a solution space that is not just one solution moving through design gateways through maturity to construction. Having a solution space that has tens, maybe even hundreds of possible layouts that is able to then really inform decision making, also really inform the application of in different places.

What if we could make a change to the rule set? What if we could have a different entry product that would unlock all of these different solutions? There's a completely different way of thinking about how design benefits the delivery and operation of assets.

And ultimately, you can have as many solutions at the design stage as you want. But at some point, you've got to build one. This is also the nature of our industry, digital or otherwise. And if you're going to choose one, you want it to be evidence-based, right? You want to down select from that mass of data all that insight. You want to be able to have a thread that takes you all the way through the decision process, the one that everybody agrees on to get to the most applicable solution.

And here is one of those solutions. This is a drive-through. Again, this is a real project in the UK. This is one of the outputs of REM. This is everything outputted from REM on screen. This drive-through is completely automatically generated. There is no human intervention apart from me pressing play.

But all the wacky colors, the lines, the colors on the road, they represent the analysis and evaluation that sits behind the REM process. And all the roadside assets that you see, gantries, different kinds of products that are appearing along the side of the road, they're automatically positioned according to the design automation rules that we've built into REM.

And to get to a level of model 3D representation such as this, it might typically take 12 months, maybe longer, actually, in a National Highways Project. This is generated automatically within a day. And it can be generated for any number of rows, any number of projects, and any number of different design options for the same projects.

Yeah, at the press of a button, really. And you can imagine this is kind of very, very impactful. It's hugely change making for this sector in the UK. And for us, it's incredibly heartening to see the application of design automation from a client organization that sees the need for change. This actually wouldn't really be possible without National Highways taking the lead to support the application of this kind of innovation and to create a collaborative environment that's necessary to bring the sorts of disruptive thinking that myself and my team from Bryden Wood brought and pairing that with the domain knowledge that sits within the supply chain and National Highways.

And really challenging how roads can be designed, and in fact, are designed. This technology has been applied on a number of projects in the UK, more than 30 different projects at different stages of design, both validating existing designs analyzing suitability of different projects, and generating design layouts that have gone through to more detailed design stages as well.

And the process continues with National Highways to keep adding more and more granularity, more and more applicability to all sorts of different contexts, all sorts of different design problems. And again, I think that's the real value or the really interesting part of the value that this brings. Client organization is directly involved working with us to build this.

It's not us coming up with a proposition that then is simply kind of forced into that context. It's developed collaboratively. It's developed together in order that it really is always tracking their business needs and their value drivers in order to deliver better road transport infrastructure for the UK. So thank you, everyone.