The logical starting place for understanding the system design is to establish a robust definition to orientate all future development work towards supporting the top-level design.
The system design is comprised of engineering products that affect multiple delivery projects and contracts, shape the system-level solution, and should be controlled by the client organisation. They are the key technical products that form the backbone of the client design from which all lower-level design will be derived; they are typically developed by the client before the approval sanction gate and the letting of supply contracts.
System design products will vary sector to sector. In the world of major railway programmes, typical examples of system design products are as follows:
- Major electrical feeding diagrams
- General arrangement (spatial planning) diagrams
- Electrical load flow modelling
- Functional architectures and flow diagrams
- Tunnel ventilation analysis
- Operational journey time modelling
- System architecture diagrams
- Technical budgets (power, space, data traffic)
The critical challenge of major engineering programmes is developing and maintaining a consistent view of the ‘system of intent’ that binds the system design products into a cohesive, integrated package of information. The upkeep of design coherence will always be challenging throughout the lifecycle of the programme, particularly the verification of in-flight designs against the established system design.
As major infrastructure programmes gain momentum, media and political challenges are inevitable and should be planned for. Such attention may seek to question the high-level specification and scope and to test the value-for-money question. The clear demonstration of a baseline system design that is modelled against a known configuration can be very powerful to show that system design has optimised the cost and performance trade space. In addition, this close coupling allows the client to re-run the performance simulation, effortlessly showing the cause and effect of relaxing performance targets—i.e., fewer trains per hour or reduced train performance.
Too often the setting of system-level parameters is decoupled from the operational and economic case; in these instances, the full implications of a particular level of performance is only revealed much later in the lifecycle and hence very difficult to address. When the technical design and underlying performance models are closely coupled, a causal relationship is established, making the connection between performance and cost explicit and visible. This relationship between technical performance and cost can serve to demonstrate that whilst the reduction of performance may offer a capital cost reduction it may also expose a knock-on effect in another part of system, potentially creating an unrepairable break.
Control and Oversight of the Design
Over the lifecycle of a major programme, a vast quantity of engineering products is accumulated, though not all engineering products hold equal importance. The critical products that comprise the system design need to be assembled into a logical structure and placed under configuration control. This provides visibility of the whole design and promotes seeing the ‘wood for the trees’. The generation of design products will witness a step change as supply contracts are let. This effect will be persistent and increase in intensity as supply contracts progress through their lifecycles into detailed design. The system design baseline provides an initial blueprint allowing a better-structured mechanism for more effective oversight and control promoting transparency of the client-level design and level of integration. In addition, the extent of design liability can be faithfully represented and the aspects of design that will be owned and retained by the client can be articulated. This process acts as a powerful motivator to stress-test aspects of the system design that if proved inadequate would be seriously detrimental to the programme objectives.
All this activity needs to be supported with a robust and scalable set of tools. The timing of appraising and embedding engineering tools to manage the system-level design is crucially important. If they are selected too late—when contracts have been awarded and the programme organisation have become accustomed to disparate and fragmented ways of working—the chances of a failed deployment will be increased dramatically. At any given point in time, the programme organisation must precisely understand the known design configuration and what function and performance the solution is baselined against. Similarly, the programme organisation must also have a clear understanding of the future state and what changes to the system configuration are anticipated.
Visualising the Basis for Design
A common challenge is understanding how disparate design products are related to each other and how they have been used to inform delivery contracts. This is where visualisation comes in, to show the system design in a single point of reference. This presentation promotes design coherence and understanding of how the system design underpins delivery contracts, clarifying what contracts will deliver against. The assembly of the system design into a logical definition structure with a configured and stable set of products ensures that all contracts are aligned to a consistent, common and approved set of design inputs from which lower-level design will be developed.
Moreover, the bringing together of the system design products under one logical baseline structure allows insights to be drawn into the health and stability of the design. For instance, a set of metrics that look for technical changes that are associated with a particular design product can reveal underlying issues with the design. The type and quantity of deviations from the baselines can also highlight those products under threat of non-conformance.
Responding to Technical Change
The system baseline captures the critical system-level design products into a logical structure so that the system design can be viewed as a congruent whole. This provides a platform from which to rapidly test and respond to technical change and perform trade-off analysis—to understand the impact on the system design and thus the achievement of the end-state capability. The bringing together of the system design into one place enables the detection of possible conflicts within the set of information, thereby de-risking the achievement of the end-state requirements. Furthermore, a more informed view of the effects of change can be achieved by gaining clarity over what input parameters are feeding a particular model or simulation, thus dramatically reducing the likelihood of unintended effects in connecting or enabling sub-systems late in the lifecycle where rectification will be disproportionally more costly.
The ultimate success of the system design is not determined by any innate feature of the system engineering or organisation but upon the wider programme team appreciating the importance of the system design and respecting any changes to the product set and the ripple effect on dependent products. It is crucial to designate a single design authority (‘product owner’) that provides oversight of the whole design— necessary to provide an ‘eyes up’ view to drive systems integration and commercial / technical trade-off decisions. In addition, strategic communication is essential for continued cultural awareness in the programme environment to promote lasting and active engagement with the system design.
Maintaining Technical Integrity
The bringing together of numerous discrete products and viewing the set of information as a congruent whole design provides a springboard for detecting and resolving conflicting information. For example, the rolling stock parameters may become out-of-sync with the
parameters used to model the journey time performance, thereby presenting an inaccurate view of the performance that is likely to be achieved. This re-running of the simulation with up-to-date inputs is a simple step that will dramatically reduce the risk envelope.
The encapsulation and organisation of information in an overarching model (meta-model arrangement) for a given stage of development can help illustrate how all the models and simulations fit together and reinforce the consistent use of modelling parameters—for example, ambient temperature predications (example model shown below in Figure 2).
