Systems Engineering ‘in motion’

In infrastructural projects, parties such as Rijkswaterstaat and ProRail are increasingly using Systems Engineering (SE). SE describes the client’s and contractor’s processes to be performed in order to successfully complete a project. The use of SE has a background in civil engineering (Dutch: Grond-, Weg- en Waterbouw). With the emergence of extensive, integral projects that are regularly outsourced to market parties, the world of installation- and information technology becomes increasingly involved in the SE-approach as well.

While the civil engineering sector is growing accustomed to Systems Engineering, the world of the dynamic systems still has to begin discovering the practical application of SE.

Martin van den Beukel, systems consultant at TriOpSys, has gained the necessary experience with Systems Engineering in recent years in major projects of Rijkswaterstaat. In the following, he describes the challenges in the dynamic field of work, the approach followed and the interaction with other ‘worlds’.

Challenges

My discovery began in 2009, when I became involved for the contractor in the design of the Tunnel Technical Installation (TTI) for the Leidsche Rijn Tunnel. With my background in software developing, I struggled with the function-tree and object-tree according to Systems Engineering. In civil engineering, an object-tree is relatively simple to conceptualize because it only describes one type of relationship: ‘x consists of y’. However, the dynamic field is also familiar with a relationship such as ‘x controls y’. However, the question that remains is x above or below y in the tree?

At the same time, the National Tunnel Standards (Dutch: Landelijke Tunnelstandaard) was ‘under construction’. This has provided a supported structure of services and functions, but this has not evolved into a classic function-tree. The LTS describes the TTI and defines the dynamic field of operation of a tunnel. In the project A9 Gaasperdammerweg (A9GDW), I was confronted with the interfaces of the TTI with the civil construction, road design, aesthetic aspects and safety aspects. During the A9GDW, I was part of the project team at the side of Rijkswaterstaat and faced the challenge of conceptualizing an integral reference design.

Approach

At the end of 2011, I initiated a procedure to achieve an output specification for the TTI. The TTI output specification is part of the output specification for the entire road-track, including a tunnel. The basis for the procedure was the so-called cookbook in the basic specification of the TTI of the LTS.

The principle of the approach was in conceptualizing a difference analysis: what are the characteristics of the Gaasperdammertunnel and for which of these characteristics is the LTS insufficient? Based upon all the interfaces of the TTI with its surroundings, I have listed the characteristics. Which put me in the blue S-processes in the ‘Process Description System Engineering for the RWS-projects’, see the figure below. Soon after, it became apparent that the other disciplines were occupied as well; it became an iterative and interdisciplinary process!

 

Figure 1. Process description systems engineering for RWS projects

Structuring Project (Green)
P1 Analyzing project assignment
P2 Structuring work packages and products
P3 Structuring organization
P4 Managing baselines
Conceptualizing and actualizing project plan
P5 V&V paragraph for project plan
P6 Managing scope and project plan

Analyzing and determining customer demands (Yellow)
K1 Analyzing problems and project aims
K2 Analyzing stakeholders
K3 Making an inventory of customer demands
K4 Honoring customer demands
K5 Compiling customer demands specification
K6 Checking quality customer demands specification
K7 Managing customer demands specification

Designing and specifying the system (Blue)
S1 Make an inventory and recording baseline situation
S2 Using basic-specification, norms and guidelines
S3 Analyzing
S4 Structuring and allocating
S5 Designing
S6 Conceptualizing system-specification
S7 Checking quality system-specification
S8 Verifying and validating the system
S9 Managing system-specification

Elaborating contract-specification (Red)
C1 Determining solution space contract-specification
C2 Determining scope contract-specification
C3 Conceptualizing contract-specification
C4 Checking quality contract-specification

This is emphasized by the Conceptual Traffic Management Plan (Dutch: Conceptueel Verkeersmanagementplan). In order to determine the numbers and locations of, inter alia, the barriers, traffic lights and emergency access routes for the output specification (SE process S6), it was necessary to gain more insight into road design (SE process S5). For this, I used the ‘traffic-based guidelines for highway instrumentation’ (Dutch: Verkeerskundige richtlijnen autosnelweginstrumentatie). These served as the base specification as mentioned in SE process S2. The road design did not offer sufficient foundation; it was necessary to gain knowledge regarding the traffic flow conditions in different scenarios: for example, in which direction should the traffic go if a calamity happens in the traffic tube in front of the ongoing traffic in the direction of junction Diemen? In the Conceptual Traffic Management Plan (Next: CTMP), I have visualized all the desired traffic flows for the different scenarios in all the possible locations; SE processes K1 and K3. Based upon this data, I could determine the numbers and locations in the relevant systems and record these demands in the contract.

During this iterative process, I tracked the project-specific requirements in the ‘A9GDW TTI System-specification’ and laid a foundation by referring to issues, decision memos and, of course, the CTMP. The last versions of this System-specification kept up with versions A through D of the contract. In this manner I could shape SE processes S7, S8 and S9.

In Motion

While working on the project A9 Badhoevedorp – Holendrecht (A9BaHo), I was responsible for the specifications of, among others, the Schiphol bridge. In this case, Systems Engineering was literally about movement. For this project too, I started conceptualizing a procedure. In addition, I used the Process description SE to describe the activities that had to be executed.

The products identified by the Process Description SE had been assigned to a limited amount of actual documents. Henceforth, the process would be interactive and iterative, but the results would be recorded in a fixed and logical place. The names belonging to the documents was based upon the topdocuments of the LTS.

In the System Definition, the scope was defined; what parts of the entire A9BaHo project are relevant and what are the objectives for the parts within the project? The requirements were derived for the Schiphol bridge in the System-specification. This is based upon the basic specifications, such as the ‘Basic Specification Movable Bridge’ (Dutch: Basisspecificatie beweegbare brug’) and the ‘National Bridge and Lock Standard’ (Dutch: Landelijke Brug- en Sluisstandaard), as well as on the specific characteristics of the Schiphol Bridge and its surroundings. The specific features had been collected in the System Design with references to the sources. In the combination of the System-specification and System-design the iterative process can be recognized.

Figure of Schiphol bridge within its context

Figure 2: Schiphol bridge within its context

It turned out to be particularly useful to work with a fixed structure of information in a limited set of documents. Over time, the conversation reports had been drafted in memos and reports. In these documents, I have referred to these and have copied the results and conclusions.

Interactions

  • Phasing – How do you build a new, larger bridge at the same place the existing bridge is positioned while the road- and waterway traffic has to continue?
  • Machine safety – What aspects are important if a bridge has to comply with the Machine Guidelines?
  • Performance – To what standard should a tunnel or bridge function; how do you record this in demands and measure this during its utilization?

These practical topics had to be dealt with interdisciplinary with a significant input and impact on the dynamic field of work. For each of these subjects, boundary conditions applied, starting points were chosen or imposed, and choices were made. Each choice limits the subsequent choices and options, and it had to be decided which of these can be filled in by the contractor. For these, and other subjects, I got involved. For example, by conceptualizing a Machine Safetyplan and analyzing the opening hours of the current Schiphol Bridge.

Conclusion

Within the dynamic field of work, Systems Engineering is less common than in civil engineering. While working on various projects, knowledge is increased. It is advisable to conceptualize a plan in which SE-products are adapted to fit the world of mechanical engineering, installation technology and software.