To answer the question posed by this article requires some understanding of systems engineering and what we mean by an ‘engineered system’.
An engineered system is not necessarily a technological one. It is a system which has been, or will be, engineered for a specific purpose. It is a composite of people, products, services, information, and processes (and possibly natural components) that provides a capability that satisfies a stated customer need or objective. Without people there is no need so all systems should have the needs of people as their focus. Information is at the interface and the services are outcomes that satisfy the need.
Systems engineers typically have a healthy paranoia about what can go wrong. They are generalists, architects, and fire fighters. They work with all stakeholders, those with the need, to those that design and test the products to be integrated to meet that need. They are team players and are intellectually curious.
In the case of tunnels, our interest is systems that include technology products. There is a common tendency for first thoughts of technology to be of a computer or a phone, maybe an aircraft or train, possibly a bicycle, but unlikely a bridge or a tunnel. Yet all are technology products that are a system and part of a system. Technology products are those associated with the branch of knowledge that relies on engineering or applied sciences for their creation.
Systems engineering is an approach focused on use and users – the mission. From the acquirer’s need, breaking that down, analysing and translating into parts that can be realistically developed into something tangible. This breakdown enables the systems engineer to zoom in on packages and lots, carefully defining parts of a design solution that can be ‘plugged’ together with a high degree of certainty that when integrated they will work as intended.
To provide confidence of success, we need to explore ways we could fail to integrate the system; using methods to avoid emergent problems in the evolving system; find out early to avoid possible failures, learning from our own and others’ experiences.
Researching past failures of tunnels does not reveal many that were too small for the vehicles. Most evidence suggests the vehicles are too big. It appeared that tunnellers consistently build the right tunnel. Is there another possibility?
A tunnel build is typically socio-economically motivated and might be why the publicity is biased in its favour. The tunnel is a fixed constraint, not the problem, requiring restrictions on vehicles that have incompatible interfaces, i.e those too big for the tunnel.
Reports on Dublin Port Tunnel suggested that the Irish Government did not want, “too big” supertrucks on its roads; but there are hints suggesting the tunnel was meant to take supertrucks.
Vehicle restrictions should only be reserved for vehicle types that were not reasonably foreseeable as using the tunnel at the time of design. The Dublin Port Tunnel height restriction is 4.65m, supertrucks are 4.8m. Hauliers complained the standard height for bridges and tunnels has been 5m for the past 30 years. No claim is made of who was right, the government or the hauliers, but it highlights that we must continually consider what the end use is if we are to get a tunnel right.
Understanding early that the tunnel size is ‘wrong’ reduces the chance that the mission needs to be unnecessarily restricted later.
Are late compromises acceptable if better diligence could have been applied to understand the end-user need, the mission, earlier in the system lifecycle? The tunnel is the first part of the system to be realised, could there be an approach that gives improved confidence that the tunnel meets the user need? Defining and designing the whole system, not just dividing into discrete packages or lots to be delivered in isolation.
It is not as simple as stating systems engineering is the answer; this might not be practical or necessary across all parts of the system. Those that deliver the ‘last fix’ systems complain of being blamed for a late finish as they finalise system integration. Conversely, at the start, the urgency to show progress, break ground, compacts the time to investigate and analyse, to get the requirements right for the first design, the tunnel. Tunnellers would get the blame for the late start. But which has the biggest risk to budget and schedule – early clarity on the mission or identifying compromises later? We all have an opinion but often there are other factors, political or economic, that mean decisions are made to proceed at risk for non-technical reasons which are not necessarily wrong but may consciously risk the assurance of the end mission.
But what if we could improve with a more focused and integrated approach? Systems engineering needs to involve everyone, not just the systems engineers. It is a systematic approach to managing complexity, an effective way to de-risk an agreement between an acquirer and a supplier. They both want to be assured that the risk of not getting what is needed is minimised.
What could we learn from those who develop mission-critical systems, who know the cost of failure? They should have relevant learnings to reduce the likelihood of experiencing misfortune firsthand – organisations like NASA. Indeed, NASA faces some of the highest stakes if it gets the mission wrong; in space, there is no emergency recovery plan.
In a high-stakes environment, all efforts focus on risk controls to assure the mission that is reliant on an engineered system. Early and evolving understanding of the mission is key. Planning, replanning, designing, redesigning, testing, and retesting seems obvious, at least with something that has never been done before.
NASA is renowned as an expert in systems engineering. Yet even NASA is actively searching for ways they could fail, seeking out lessons to be learnt.
NASA’s Office of Safety and Mission Assurance publishes ‘safety messages’ in its news section. Interestingly, the safety messages are predominantly from non-space incidents, showing that even NASA sees value in learning from others.
Systems engineering as an idea has been around for a long time but has evolved faster as technology has become more complex. In this author’s opinion, the 1980s was a pivotal point in its evolution, including for NASA.
The 1980s was a decade where integration complexity – with new software and control technologies – was emerging as more mainstream. The understanding of the ‘whole of life’ management of those systems was not yet so mainstream; there were risks not yet experienced and not identified for consideration in the design. Increased complexity inevitably led to an increase in the likelihood of failures, more ways for the mission to go wrong, more need for improved diligence and checks. It is quite possible it was not coincidental that the increased complexity of systems contributed to a spike in disasters around that time. These include:
- 1986 Chernobyl nuclear disaster, Russia
- 1986 Challenger disaster, US.
- 1987 Zeebrugge ferry sinking, English Channel
- 1988 Piper Alpha oil rig explosion, North Sea
- 1988 Clapham Rail accident, UK.
- 1989 Kegworth air disaster, UK.
Each disaster revealed lessons that improved design derived from better understanding of the system use in its integration context might have avoided the disaster.
The Challenger disaster made NASA pay attention. Its approach to systems engineering, recognises that it is not just the engineers who are able to impact the success of the mission.
Systems engineering good practice has progressively integrated collective learnings, as documented in the NASA Systems engineering Handbook and a related reference ‘ISO 15288 Systems and software engineering – system life cycle processes’.
NASA has full financial backing to do whatever it needs to get the mission right first time. So, how do we pragmatically get the best return on investment (RoI) when applying systems engineering to infrastructure projects? Where the stakes are lower and for those parts of the system where there is high confidence in familiar designs, then probably not much needs to change. But there could be good RoI using systems engineering for those parts of the system that have high criticality, novelty or low knowledge and confidence, in particular across interfaces, having a new operator and maintainer with their particular needs and constraints.
A misconception about systems engineering is that it is just for projects, designed to apply, as long as the system exists, through all its fixes, with maintenance and upgrades sustaining it through its operating life and any changes. Consider the whole lifecycle, typically referred to as the V-lifecycle.
So, do we follow the infamous V-lifecycle? An internet search reveals hundreds of versions and varieties, with each trying to accurately convey the complexity of systems engineering in simple terms. Indeed, too simple, a model that belies the deeper understanding that would make it useful. The V-lifecycle is not linear, and if treated as such will disable a project, restrict discovery and stunt innovation.
The V-lifecycle can mislead some into thinking they understand systems engineering. Zoom in on something complex and it can give the impression of being straightforward: the V-lifecycle is a zoom-in of systems engineering. Paradoxically, that is what systems engineers are aiming for: zoom in far enough so that part solutions become more attainable. But it is also necessary to consider the simplicity in the overall context of the complexity.
At the start of a system life, or change lies the concept that underpins designing the right system. We need a clear understanding of the system’s uses and how that usefulness will be sustained in its integration context – an understanding that matures for all stakeholders through the system lifecycle. System engineering is about assuring we do not build the wrong thing (more typically, not quite the right thing) and that what we build is built right.
A project to build a complex system will consist of a system of systems, each system and each element that is born of a higher-level need has its own V-lifecycle and each change to that system through its life has its own V-lifecycle. In the case of a tunnel, it might be part of a rail system which has its own integrated systems which is part of a wider transport system which is part of a functioning economy. All these things must integrate to provide the necessary functions, for people. The more complex, novel, or critical a system is, or part of, the more checks and balances are needed to assure we get it right.
NASA learnt the strategy to assure the mission should involve everyone who could impact its success. That is why systems engineering relies on more than just ‘requirements’ engineering, verification and validation of requirements. It is an integrated approach to managing delivery of the system, not a siloed activity undertaken by only the system engineers.
So, what is systems engineering? Using the reference ‘ISO 15288 Systems and software engineering — system life cycle processes’ the following is a brief overview of a systems engineering approach.
Success of a system is dependent on effective process implementation tailored to the project or business context. Figure 3 shows the systems engineering lifecycle processes; not all belong to systems engineers, but they will rely on all of them being effective in order to assure the system.
The Agreement Processes, Figure 4, rely on the other processes and are typically managed by business development, sales teams and procurement teams, not systems engineers. Examples show their relevance to a tunnel boring machine (TBM).
A TBM is essential to bore the right tunnel. Tunnellers, the end user, need to be confident that the acquired TBM is deemed to be fit to bore the tunnel being designed.
TBM designers need, or assume they know, what tunnellers need? Should they consult them? How can they design it fit for the ground conditions without collaboration with the tunnellers? Are TBM designers or tunnellers to blame if it turns out wrong? Or should the acquisition process enable consultation, collaboration, and detailed agreement of the need to assure understanding of the purpose of the TBM. How well stakeholders engage and collaborate through the lifecycle links strongly to assurance that what is supplied is acceptable.
The agreement processes rely on all the other processes in the operating model.
Figure 5, shows the organisational enabling process, most of which is familiar to those working in a quality management framework. Complex, critical, or novel systems may need refinement to better support systems engineering. They are typically owned by operations managers or general managers, not systems engineers.
They are not typically business processes, but if you are in the business of supplying technology products then they are important.
These processes are focused on an enabling operating model. They are integral to the effective operations, ensuring the business has the infrastructure and resources to enable business success, assuring supply agreements are secured and fulfilled. The approach is aimed at driving efficiency, creating a business portfolio, and exploiting knowledge that enables reuse of solutions for business sustainment and assured customer satisfaction.
Figure 6 illustrates the technical management processes, which are all about effective control and management over the change from the current state to the new state of system configuration. They are typically owned by project managers and asset managers, not systems engineers.
They are like project management or asset management processes but are tailored to an engineering viewpoint; their aim is to support decisions and control to assure the right system is built and maintained correctly, not just on time and budget. Systems projects need to be on point, on time (or available) and on cost. ‘On point’ means it meets the need, not just the quality checks.
Most of these are familiar and, done well, can be enablers to good systems engineering, leading to a lower risk of the system not fulfilling the intended need. Done poorly, there will be poor or missing information leading possibly to unsound decisions.
One particularly important process is configuration management, which is primarily focused on assuring the compatibility of the system interfaces to ensure it will integrate, even when there is a change. For example, change the size of the tunnel (tunnel configuration) and the train might not fit. Will changing the configuration of a train’s emergency exits still allow enough space in the tunnel to escape the train?
Changing the configuration of one part could have unintended consequences for whole-of-life management. Any stakeholder that could be affected needs to have their say to get to an agreed decision on change. Not just the change initiator. The later that change is proposed, the bigger the risk of unacceptable impact. There could be reasons why a change might not be acceptable right now.
Change assessment might cause delay, but better to invest the effort assessing the impact, so that all stakeholders can come to a fully informed agreement, rather than discover the impact at a later stage, with even more delay. A small impact on one stakeholder could be huge on another.
The technical processes, those typically thought of as systems engineering, are not all owned by systems engineers, some belong to business analysts, designers and constructors.
Each one of the technical processes is written for use throughout the system lifecycle, not just in a particular phase (Figure 7). To explain these processes, consider blast design, written from the viewpoint of a systems engineer, not a blasting expert.
The mission analysis, stakeholder needs, requirements definition, some of the tunnel system requirements, architecture definition and design definition all probably started before the blast design. An understanding of what is envisaged is important to define the appropriate blast zone if blasting is one of the viable options for excavating the tunnel.
The client knows what type of traffic will use the tunnel, ‘the mission’, but is probably not expert in excavation, so they may not even know how big the tunnel should be. Maybe they know how to operate and maintain the tunnel and the assets in it for the proposed train service. The specification for design will be left to engineers to translate the stakeholder needs into a set of system requirements; systems engineers will create the architecture definition for the tunnel as part of the railway system.
The architecture definition is a reference set of information updated and maintained as the system evolves. It aids decision making, explains the system in ways that suit everyone. It includes information that the blast engineer wants to know, with early versions considering options for design and build. It could be made up of documents, models or point of reference systems similar to the one required.
Derived from functional needs, system requirements and architecture are the basis for the design; this is the downwards tracing of requirements into the design enabling package definition – the parts of the puzzle that will be put back together to create the system. Agreement on the architecture and requirements as complete and correct is critical to validating that the right system is being supplied. Validation starts at the design input not at build output.
The validated basis for design is critical as a reference for upwards tracing to verify that requirements are met and the design supports the mission.
If the excavation size specified is not validated, a perfect blast might be achieved, but the wrong size might result. Too small and more excavation might be needed, or vehicle restrictions will be imposed on the finished tunnel. Too big and it might be wasted money, causing change to other designs and perhaps increasing whole-life costs.
The system analysis process supports the technical decision making. It is employed throughout the lifecycle at any point where there may exist a set of competing technical options. Tunnel excavation methods are selected based on the available geotechnical information. The level of certainty of the geotechnical structures and impedances to the excavation varies from context to context. Geotechnical (system) analysis is required for excavation design.
Where there is low certainty of the geotechnical information, a pilot tunnel might be used to allow progressive assessment of ground conditions. The pilot allows for progressive verification and validation of the right tunnel built right for the ground conditions, adapting the design and methods as the geotechnical knowledge increases.
This example shows that the V-lifecycle is an iterative model: each time there is more information, the previous understanding of requirements and constraints need to be revisited, analysed and adapted. Adaptation always happens through the system lifecycle for complex systems. It is not typically possible to fully understand the system and its emerging challenges at the start. The analysis process is critical for adaptation as the system understanding matures and becomes clearer. A systems engineering approach aims to reduce the potential for change or discovers the need for change early-on as part of risk mitigation.
Although often not considered relevant by a project team, the operation and maintenance processes start at what is needed in the design for effective and efficient whole-of-life management; part of that is making it safe for those who interact with the system in all reasonably foreseable circumstances. Is it OK for lack of O&M provision in the design to be someone else’s problem after handover? Safety obligations are a designer’s problem to solve; an asset manager will not accept a system that they cannot safely maintain and so are likely to be reluctant if disruptive closures are needed to achieve safe performance. Which brings us back to the point: we must begin our design with the end in mind.
So, what does NASA know about building a tunnel? Maybe nothing specifically, but we can learn from their systems engineering approach and adapt it to the tunnelling process, particularly for any parts of the design that are novel or uncertain. This can increase the likelihood that the end user gets the right tunnel for their operation.
Learning from the holistic systems engineering approach typically advocated by NASA, it is entirely possible to reduce the spectre of the train being too big for the tunnel.
