This article looks at some key reasons why it is important to use a Systems Engineering approach when defining a major rail infrastructure project.  We begin by defining Systems Engineering before discussing four reasons why systems engineering is important in major rail infrastructure projects.

The most widely referenced image of Systems Engineering is the “Vee Model”. This view of Systems Engineering may have been around in the 1960’s but most articles point to a paper published by Barry W. Boehm in 1979.

This diagram emphasizes the role of Verification and Validation in Systems Engineering.

There is much more to Systems Engineering than can be covered in this familiar diagram. Trying to condense the topic down into a few paragraphs usually leaves the reader confused. Similarly stepping through each process is very tedious and will make for difficult reading.

Instead of trying to define the process step by step, this article discusses why you might choose to use a Systems Engineer and hopefully, by looking at the reasons to use Systems Engineering, the reader will gain more insight into the sorts of activities Systems Engineers perform. It is assumed the reader has had some exposure to the topic of Systems Engineering so will be familiar with the terms used. If not a glossary of terms is provided on our website  www.HKRP.com.au.

When thinking about why you might choose to use a Systems Engineer or a Systems Engineering approach the following reasons come to mind:

• You need to know if you have built the right system;
• You need to manage complexity;
• You need to manage the margin in the system; or
• Somebody’s life might depend on it.

Let us start with this set of reasons and explore how Systems Engineers helps to manage these issues in the context of rail engineering.

Building the right system

The first question a Systems Engineer will ask is what is the mission of this system? At the very highest level of systems analysis, we need to understand how this system will be used to achieve the mission of the business. At this stage, the system is considered as a black box, with the other parts of the business interacting with it to produce a particular result. Without a definition of the mission and business requirements of the system, it will not be possible at the completion of the project to decide if the system meets the needs of the enterprise.

It is very easy to jump straight into the solution-space that we are familiar with and define a set of requirements that solve an existing problem. Any subtle differences between the current business environment and previous situations will raise their head much later in the project when the remedy will prove to be much more expensive. We may wind up building a solution that meets its requirements (we built it right) but does not meet the needs of the owner and its stakeholders.

At this stage, descriptions which imply a particular solution will be avoided. The language will be much more focussed on outcomes or behaviour needed for the system.

The production of the Business Requirements Specification (BRS) will help us answer the question, “Did we build the right system?”  In Systems Engineering terms we call this process system validation.

Managing Complexity

The technique of system decomposition is critical to managing the complexity of large rail projects.  Unfortunately, often engineers will start the process by defining a system breakdown structure and the architecture of the solution. They then create a set of specifications to build this architecture thinking that they are following a Systems Engineering approach.

A Systems Engineering approach identifies the stakeholders of the systems and analyzes how they use the system and what capabilities they need from the system. Each capability (or Use Case) is then analyzed using scenarios to elicit the functionality that the system needs to perform. Stakeholder requirements are later translated into system requirements. Often, the system requirements need to be broken down again into derived requirements.

The scenarios can come from all parts of the system lifecycle such as acquisition, construction, operations and maintenance. Once enough scenarios have been examined the functionality of the system will remain stable and the team will know they have completed the requirements analysis. These functions are then translated into requirements statements and documented in a Systems Requirements Specification.

In Systems Engineering language we say they have defined the problem-space

By using scenario analysis, the stakeholders are in fact validating the requirements as they are generated. If you already have a set of requirements that have been created elsewhere, they can easily be validated using the same approach.

Managing the Margin

Only when the requirement analysis and definition has been completed will the Systems Engineer then start to contemplate the structure of the possible solutions (the solution-space). During the architectural definition stage of the process, the Systems Engineer will allocate requirements to system elements until they have allocated every requirement to a system element.

At this time, the Systems Engineer must also perform an interface definition process. Interfaces will define the flow of control, information, material and energy between the system elements. The last step is to breakdown these elements into even smaller packages that can be handed to the individual engineering disciplines. Armed with these handover packages, specialist engineers can begin detailed design. By following this process, highly complex needs can be transformed into deliverable packages of work.

When the Systems Engineer performs requirements allocation to different elements of the architecture, they can make decisions about whether a function will be performed by an operator or a software system, by a hydraulic system or an electrical system. They make these decisions based on the margin they have in the performance parameters of the system. Examples of these performance parameters might be weight, cost, transit time, power consumption, reliability etc. The Systems Engineer in consultation with the other engineering disciplines will move the margin in the system to optimize the system. The Systems Engineer is the advocate for the end-to-end system performance and manages the margin, while individual engineering disciplines will manage the design within the margin handed down from the system level.

In Systems Engineering terms these are called trade studies and they can be very important to justify the selection of one architecture versus another. There will always be conflicts but if the alternatives have not been studied and documented, disputes can drag on and distract from the delivery of the project. Trade studies are not perfect; however, they provide a level of objectivity when presenting a case to concerned parties.

Somebody’s life depends on it

Finally, and most importantly, lives depend on the safe operation of rail infrastructure. The mass and momentum of trains mean that they are inherently risky as the consequences of derailment or impact with other trains, vehicles or pedestrians will often result in serious injuries and fatalities. In the case of passenger trains, the risk is multiplied by the fact several hundred passengers may be travelling on a single train.

Systems Engineers work with rail safety engineers to identify hazards, capture the controls for those hazards and turn them into safety requirements.

Safety Engineers will review the architecture of the system to consider various hazards. These types of hazards are usually predictable in terms of the failure of components. Controls for these can be implemented through maintenance strategies that replace aging parts before they reach a point of failure. This is an example of how Systems Engineers need to consider the system lifecycle, identifying requirements to the design and manufacture of a component as well as the maintenance regime necessary to achieve a safe system result.

Furthermore, Safety Engineers will review the functions identified in the system definition to assess the hazards involved in the behaviour of the proposed system. These types of hazards are unpredictable and usually occur because of human error either in the design, construction, or operation, of the system. One type of control for these hazards may be to define a Safety Integrity Level. SILs are procedural requirements on software development that reduce the probability of a hazard and thereby reduce the residual risk of the hazard to a tolerable level.

It is then the Systems Engineers responsibility to ensure the requirements captured in the design definition phase are verified by test plans in the verification phase of the project. The verification process provides the evidence that safety engineers rely on to make a safety case argument for regulators.

Conclusions

In this article, we have considered four reasons why Systems Engineering adds real business value when embarking on a large rail infrastructure project. As we discussed each reason, we introduced several Systems Engineering concepts such as functional decomposition, problem-space definition, managing system margin and safety requirements.

Although we didn’t have time to discuss these Systems Engineering topics in detail, we hope that by discussing these concepts in the context of a higher-level purpose the reader has seen the benefits of engaging a systems engineer in the rail environment.

If you would like to find out more about how HKRP can assist in your next project please contact us via our website - hkrp.com.au