Introduction

“Systems Engineering” describes an approach to the design and implementation of a project in an integrated fashion. It does not, contrary to common misconception, describe an engineering discipline associated with the design of any particular subject. As explained by the International Council on Systems Engineering (“INCOSE”), “instead of just focusing on one part, Systems Engineering uses a big-picture mindset to oversee the entire life cycle of a project”.¹

With Ontario’s 10-year infrastructure capital plan totaling more than $210 billion (of which approximately $63 billion is for public transit),² we need solutions to avoid the scale of cost and schedule overruns experienced on Ottawa’s Confederation Line and Toronto’s Eglinton and Finch lines. The use and proper implementation of Systems Engineering is part of that solution.

Implemented properly, Systems Engineering ensures that all the separate components of a complex system – such as a major rail infrastructure project – properly integrate and function together as required for proper performance of the system.

Although Systems Engineering is not exclusive to rail or transit systems – it was created and used first in the aerospace and missile defence industries – this article focusses on the use of Systems Engineering in the transit context.

Systems in Transit Infrastructure Projects

Systems Engineering is an approach to interdisciplinary design and implementation focussed on the ultimate use of the system – i.e. the operating railway. The final product is viewed as a “system” comprised of numerous “subsystems”. Therefore while the operating railway is the “system”, the “subsystems” typically include civil, track, rolling stock, power, signalling, and communications. The points at which these subsystems connect or interact are known as “interfaces”. Managing these interfaces to ensure integration between subsystems requires the design teams to identify what each subsystem needs from the others and ensure that those requirements are reflected in their designs.

Of course, irrespective of the approach taken, any design-builder must design individual components with appropriate consideration for the effects on other components. For example, the signaling system requires cables to run between two locations and so the civil design must accommodate the necessary cable routing. Where these elements are designed by separate teams (as is always the case), delivered under separate contracts (as is often the case), and the design of each is not equally progressed (as is generally the case), coordination becomes even more complex.

Systems Engineering is a structured approach developed to avoid the break down in the coordination and integration of designs between disciplines. In the authors’ significant transit experience, many delays and cost overruns can be traced back to failures to properly and robustly address the interfaces early in the design process.

Systems Engineering V-Model

The “V-Model” of Systems Engineering is a widely recognized framework that provides a structured approach to the lifecycle of a design-build project. Figure 1 below presents a version of the “V-Model” framework for a transit project. While the specific items in the “V-Model” are not dictated and can be adapted to the specific needs of the project, standards such as the International Organization for Standardization’s ISO 15288 provide a common framework for describing the life cycle of systems. Irrespective of the specific items, the process is always the same insofar as it begins with the left side which represents the development stage, including the design process, and concludes with the right side which represents the progressive stages of the integration and assessment of the resulting system (ultimately achieving commissioning). The actual construction portion is the one box at the apex of the “V”.

Concept and System Definition

The starting point is to establish what the railway is intended to do, who will use, operate and maintain it, and the conditions in which it must function. This stage identifies the relevant stakeholders, defines the system’s scope and boundaries, and establishes its operating concept, including its relationships with existing infrastructure and external systems.

System Requirements Specification

The system requirements specification stage begins with identification of the output requirements which are typically contained in an Owner’s Statement of Requirements or an Output Specifications document. But this is just the starting point; the delivery team must thereafter begin deriving further requirements which includes identifying requirements within standards and codes applicable to the project but also requirements based on the ultimate needs of the system during its operation and maintenance process. They must also address reliability, maintainability, safety, and interfaces, including requirements arising from hazard analyses. Each requirement must remain traceable to its source.

System Architecture and Requirements Allocation

The system architecture is the division of the system into subsystems, establishing the functions each will perform and the interfaces between them. Architecture and requirements development inform one another, so allocations need to be refined and iterated as the interfaces and technical solutions become more detailed.

Once the system requirements are identified, those requirements must be allocated to the different subsystems. As a simple example, if a system requirement is that the train must be driverless, such requirement must be allocated to any rolling stock subsystem and any signalling or train control subsystem.

The subsystem disciplines must then derive further requirements specific to their subsystem. Maintaining the same example, the train control subsystem will identify the specific requirements it needs to achieve in order to have a driverless system. The subsystem requirement phase is therefore a more detailed requirement definition phase than the system requirements.

The next step, still before moving to the system specification and design phase, is an iterative process where the derived subsystem requirements are carried up into the system requirements and new requirements allocated down to the different subsystems again. For example, as depicted in Figure 2 below, if the train control subsystem identifies that its driverless train control system requires a device every 100m of track, that requirement must be allocated to the civil subsystem requirements to ensure that duct-bank/conduit and conduit stub-ups are designed as required.

System/Subsystem Specification and Design

With requirements defined, a designer can develop a set of specifications intended to achieve those requirements and with proper allocation of requirements between subsystems, the designer is able to focus only on those requirements applicable to their subsystem.

In practice, system specification is completed at the subsystem level, with each subsystem discipline developing the set of specifications applicable to their subsystems. In this stage, the verification step is the process of verifying that each subsystem requirement can be achieved through the specifications.

With all of the requirements defined and allocated to the required subsystems and with the subsystem specifications complete, the detailed design process can begin unhindered by the need to coordinate with other subsystems as the key integration steps were completed during the requirements phase. Of course, this is not to suggest that changes and missed requirements won’t arise – they likely will and they must be managed in a robust fashion (referred to as configuration control or configuration management) so that any change which is properly coordinated with all affected subsystems and components.

Procurement, Construction, Manufacture, and Implementation

This step is self-explanatory and receives little attention in the Systems Engineering procedure despite it representing the most significant expenditure of time and money. Inspections and tests, including factory acceptance tests where applicable, provide evidence that equipment and completed work meet the relevant requirements and are ready for installation or further integration.

Subsystem Integration

With the installation complete, 3³ the subsystem components are connected and tested to check their internal interactions and performance against the design. These checks establish whether the subsystem is functioning as intended, but in isolation from the other subsystems. Where a subsystem connects with another subsystem (as is often the case) a subsystem integration test may use simulated interfaces to represent those connections. By properly completing subsystem integration before proceeding with system integration, the project team can ensure that system integration issues are isolated to the interfaces between systems.

System Integration

It is in the system integration process where the success of the Systems Engineering approach will be put to the greatest test. The subsystems are progressively connected and tested together to check that they integrate as intended. If the interfaces between the subsystems were not properly identified and defined, the system integration process will find it.

System Validation and Acceptance

System validation and acceptance testing is the most critical step. This is when the integrated system is tested against its performance requirements. Tests typically assess passenger capacity, intervals between trains, journey times, stopping/braking distances, and performance under specified fault conditions.

Commissioning into Service

With the acceptance testing completed, the stakeholders have validated that the system was designed and constructed as intended and therefore is ready to be commissioned into operations.

Verification and Validation (The Paths across the V)

The connecting paths link requirements to design outputs, to satisfy the requirements, and to the products, equipment, and systems installed to comply with the design. Verification establishes whether a design or completed work satisfies its specified requirements while validation establishes whether the implemented solution actually achieves the requirement.

Decision Gates and Controlled Change

For Systems Engineering to be successful, it is absolutely critical that the V-Model process is followed and that short-cuts are not taken. Accordingly, Systems Engineering requires the team to implement “Decision Gates” which seek to establish when work is sufficiently developed to proceed to the next stage. As set out by INCOSE, “Decision gates represent major decision points in the system life cycle. They ensure that new activities are not pursued until the previously scheduled activities, on which new ones depend, are satisfactorily completed and placed under configuration control.” ⁴

By using Decision Gates at each stage, the process can ensure that, for example, the civil subsystem designers do not proceed to design the guideway and ductbank systems without first knowing all of the train control subsystem’s requirements that they need to design for. Without properly defined and implemented Decision Gates, the civil designers may not account for the conduits required or, worse, the constructor actually completes the construction without the required conduits.

Of course, each gate needs defined criteria, a decision-maker with authority, supporting evidence and a process for resolving outstanding issues or managing authorised exceptions.

This is not to suggest that the Systems Engineering approach is a rigid, linear process. Design development remains iterative and flexible to changing conditions. However, Systems Engineering controls this through what is called “configuration control”. Once a Decision Gate is reached, all activities completed for that gate must be placed under configuration control so that there is a centralized database and process for identifying the implication of a change in one subsystem on all others. In this process, a subsystem discipline cannot unilaterally make changes without going through the configuration control and change process, ensuring that any such change is properly coordinated with all impacted interfaces.

When the Systems Engineering process is not properly implemented and Decision Gates not strictly enforced, relatively small issues or changes can quickly snowball into significant impacts on the project, driving delay, cost overruns, and claims.

Conclusion

Systems Engineering, robustly implemented, is one tool in the toolbox that can help improve complex project delivery. However, it cannot be given lip service. It is not simply a box to tick. Importantly, robust implementation can be impacted by the manner in which the procurement agency delivers the project and how the stakeholders are or are not brought into the requirement development process.

There are two key examples of how transit infrastructure construction in Ontario has been plagued by decisions made by the procurement agencies – being how they treat and integrate operators and third-party stakeholders into the process:

1. Operators. As mentioned, the “system” is the operating railroad. Therefore, the operator’s operational plans are critical to the effective design of the ultimate “system”. If they are not part of the requirements development process, then a system will be defined, designed, and implemented without regard for how it is actually to operate in the real world. This is antithetical to the very concept behind Systems Engineering – which is to look at the whole lifecycle of the system.

2. Third Party Stakeholders. There are numerous third party stakeholders which can and have had significant impacts on transit project delivery, including principally municipalities and utility companies. These parties are not involved in the requirements development process and later impose unexpected requirements on contractors during the detailed design process.

When implemented properly, Systems Engineering can drive significant improvements to complex project delivery. But the contracting community can only do so much without control over the delivery model or the relationship between the authority and the third parties. Therefore, even if Systems Engineering is properly implemented within a design-build contractor, without buy in from the public sector to address some of the structural issues with procurement models, the private sector can only go so far.

1. INCOSE – About Systems Engineering ↩︎
2. 2026 Ontario Budget: A Plan to Protect Ontario, Ontario’s Economic and Fiscal Outlook in Brief. ↩︎
3. Critically, the subsystem integration stage can proceed on individual subsystems or components independently from others as it is confined within the subsystem itself. Accordingly, the subsystem integration process does not need to begin after all construction is complete and indeed ought to begin far earlier. ↩︎
4. Section 3.2.2, INCOSE Systems Engineering Handbook, INCOSE-TP-2003-002-03. ↩︎