You probably don’t know any engineers who think that “systems thinking” is a bad idea.

But do you know any engineers who think that we use too much systems thinking when designing complex and costly linear infrastructure schemes like railways, roads, pipelines and power lines?

The answer is almost certainly no because systems thinking approaches aren’t used enough.

So why is that and what kind of approaches do they use? And why does it matter so much if new infrastructure schemes get designed and built anyway?

This is the first of many pieces in which we’ll explore these questions and share some ideas of our own about how our tools can help put systems thinking into practice. All feedback welcome!

What is a system?

Let’s start with the basics. According to Wikipedia, the definition of a system is as follows:

“A system is a group of interacting or interrelated entities that form a unified whole. A system is delineated by its spatial and temporal boundaries, surrounded and influenced by its environment, described by its structure and purpose and expressed in its functioning.”

Let’s unravel this — clearly, there are a few components that make up a system:

1. “group of interacting or interrelated entities” — the basic building blocks are objects and their relationships.
2. “unified whole” — objects in relationships that come together to perform an action which is more than just the sum of its components.
3. “delineated by its spatial and temporal boundaries” — systems have defined boundaries, that’s what differentiates a system from ‘everything’.
4. “surrounded and influenced by its environment” — environment influences the system; parts of ‘everything’ that surround and influence the system are defined as ‘system environment’.
5. “described by its structure and purpose and expressed in its functioning” — function, key objects and relationships usually form the definition of the system; all three have to be present for the definition to be complete.

Now, what if these ‘entities’ or ‘objects’ are also systems themselves. If you can model and manipulate the relationships between the different systems, their boundaries and their local and global environments, then you have a system-of-systems or whole systems approach.

What is linear infrastructure?

Unfortunately, Wikipedia doesn’t have an article on ‘linear infrastructure’.

In essence though, linear infrastructure is a system of systems which includes multiple repeated sections that together transport something from A to B within a specific corridor. Good examples of this are roads, railway lines, power lines, pipelines, canals, hyperloops and so on.

The system’s location, usually represented as a 2D line on a map, determines its boundaries, surroundings and environment. In order to define a line, you need end points. Groups of end points connected with linear infrastructure are networks and conversely, a network consists of many different lines — and so linear infrastructure often comes in networks.

Linear infrastructure — a systems description

Now that we’ve got the basics out of the way, let’s get a bit more practical and talk about how we can describe linear infrastructure as a system-of-systems.

Here are two broad types of approaches:

1. “Central-global” — break down by subsystem function
2. “Distributed-local” — break down by subsystem placement

“Central-global” is a high-level approach that divides subsystems into different engineering disciplines. Broadly speaking, there are some subsystems common to all linear infrastructure:

• Alignment and geometry — requires start and end points and is constrained by geometric requirements (e.g. radius of curvature, gradients). This is the first element of the whole system that determines the 2D line on the map.
• Earthworks and structures — establishes a permanent corridor and a physical relationship with the environment. This is heavily influenced by local context and requires significant effort to design, construct and maintain.
• Power delivery and distribution — provides the energy required to move something from A to B within the corridor. This something can be water, electrons, vehicles and so on.
• Drainage and environment control — ensures proper operation and availability of the linear infrastructure asset. This keeps the conditions inside of the system within operational ranges and available to respond to changes in external conditions.
• Signage and functional control — enables the overall system to perform its function repeatedly. This can be automated or human-operated.

The complexity of these subsystems will of course vary for different kinds of linear infrastructure, but generally most are present along the entire linear infrastructure and consist of multiple similar parts.

“Distributed-local” divides different subsystems based on their location. In other words, you break the linear infrastructure into sections ‘along the line’.

This kind of systems thinking approach focuses more on the detail and immediate environment surrounding each subsystem. Linear infrastructure systems can span hundreds of kilometres, generating thousands of individual interactions between individual subsystems and their surroundings which need to be considered in the infrastructure planning and design stage.

The distributed-local approach therefore takes account of these interactions in a way that the central-global approach does not and favours precision and getting the detail right. However, it can also lead infrastructure planners and designers to miss the bigger picture that the central-global approach provides. This is a simplification, but the ability to helicopter between the big picture and precise detail throughout the design process is critical to good infrastructure design and we see too much one of one approach and too little of the other depending on the stage of design.

Why does this matter?

Have a look at the four dartboards below. The two terms to keep in mind here are accuracy and precision. Accuracy is getting the right thing, precision is getting sufficient detail.

Board A is neither accurate or precise, board D is both. Board B is where we see infrastructure design at the moment — producing a lot of precise detail and documentation to evidence design decisions, but not necessarily identifying the best designs. Board C is the stage at which infrastructure investors usually make a decision to finance linear infrastructure — big picture thinking with a central-global understanding of the system. Clearly, Board D is where we should be.

The problem is that most engineering software tools are built to provide precision and detail to design specific subsystems. The job of thinking about the big picture and decision making is left to human experience and judgement. It is rare that any individual designing a linear infrastructure system has a complete understanding of all engineering disciplines and every decision made. So as linear infrastructure projects increase in complexity and size, the difficulty of helicoptering between detail and big picture and managing the design increases rapidly.

Part of the issue is data; infrastructure planners and designers up the level of granularity as and when more data becomes available. But often, after an initial design specification and system make-up is defined, they freeze design parameters and lock in these early decisions so that they can proceed to detailed design.

In other words, the early stage design process is driven by many decisions that are made with little data about the physical context of the system. The detail is filled in later using more granular data. The process of iterating the design is manual and laborious too and so the design may not even be close to optimal by the time it is finalised. Keeping the continuity between a global picture and solving immediate problems is just hard, especially if there is no visibility of the system as a whole.

And why does this all matter? It’s simple. Most of the capital and operational costs of linear infrastructure projects are effectively decided early during the design stage (see below).

Clearly, the earlier infrastructure planners and designers can identify the detail and data that will drive the ‘optimality’ of their design decisions, the better for the project in the long-term. Using current tools and approaches to do this is prohibitively time-consuming though and so technology has to support the effort and provide some degree of design automation and optimisation for the whole system. Of course, defining what is optimal and good is tricky and it is much easier to define mistakes after the fact (see below).

A better way to design linear infrastructure

We think that the fundamental changes needed to improve the infrastructure design process must:

1. Bring as much data and detail as possible into the early design decision-making process.
2. Enable far more design options to be considered at an early stage with little additional effort.
3. Reduce the effort to re-work and iterate designs so that decisions can be re-evaluated.
4. Support multi-disciplinary approaches and helicoptering between the levels of detail.

None of this is completely original thinking and technologies like parametric and generative design, digital twins or Building Information Modelling (BIM) are helping to change this. However, many of these technologies appear to us to focus on improving the management of asset/project data and automating single-domain design processes. There is an interesting gap that doesn’t seem to be covered: using a systems thinking approach throughout the design process to integrate multi-disciplinary design with realistic, granular data, for linear infrastructure design.

This kind of approach, coupled with powerful optimisation algorithms and a high-performance computing framework, should allow infrastructure planners and designers not just to produce ‘a design that does the job’, but get closer to finding the optimal designs. More time can be spent too on making sure that there are no mistakes and that the data used is the best available. A systems approach can also be standardised and used to identify similarities across different linear infrastructure projects and more accurately determine and quantify the influence of spatial parameters and their interactions with linear infrastructure systems.

If you found that interesting, stay tuned!

In future pieces, we will reveal more detail on how we actually implement this systems thinking approach, define relationships between various disciplines and bring that together to provide tools that support design automation and optimisation for linear infrastructure.