8 – Technical Forums

Train Control in 2010

System Engineering for Re-signalling Projects Jon Hulse P.Eng, Parker and Associates Inc. (A Division of Delcan Corporation) Kingston, Ontario, Canada SYSTEM ENGINEERING FOR THE SUCCESS OF RESIGNALLING PROJECTS In a study conducted by the International Council on System Engineering (INCOSE) it was found that there is an inverse correlation between cost and schedule overruns and the amount of effort invested in System Engineering (SE), with the higher the System Engineering effort the lower the schedule variance from that planned. System Engineering requires more than the application of the simple SE “V” diagram shown below. To be truly successful SE requires a process orientated approach to the Project Implementation, across the full Project life-cycle, and SE practices must be embedded in the whole organisation responsible to deliver the Project, and not just the System supply chain.

the cost, schedule and performance benefits of these projects where as a result of varying levels of SE and different approaches to implementation, there may be similar variations in results. Resignalling Projects Resignalling projects are many and varied in their application; however, in this paper two main types are addressed due to their particular relevance in North America today: 

The application of PTC to a mainline passenger or freight railroads;



The replacement of an existing signalling system in urban transit applications.

100%

0% Requirements Definition

Positive Train Control

System Level Testing (site)

System Integrator

SITE

Site test and commissioning

System Integration and Test

System Design

Subsystem Supplier Subsystem integration and test

Subsystem Design

Factory integration tests

Build (H/W and S/W)

Conventional System Engineering Approach

Figure 1: System Engineering “V” Diagram

This paper examines the application of Systems Engineering to, and reports on some lessons learnt in resignalling projects. The rapid progress in the development of Communications Based Train Control (CBTC) products, combined with the aging railway infrastructure and the initiatives to implement Positive Train Control (PTC) all lead to a growth in resignalling projects. Hence, there will be many opportunities for a Rail Transit Owner (or Agency) to obtain and compare

In the US the application of PTC has recently been mandated by the Federal Government where the Rail Safety Improvement Act of 2008 required that each Class 1 railroad carrier and each entity providing regularly scheduled intercity or commuter rail passenger transportation develop and submit a plan by April 2010 that would ensure implementation of PTC before the statutory in service date of December 31st, 2015. The application of PTC may not actually involve resignalling in all cases, but the challenges of application are equally demanding given the needs to maintain existing capacity and to limit impacts on operations during the implementation. The application of PTC is similar to the application of the European Traffic Management System (ERTMS) which began in the 1990’s and which is still progressing through its various phases to allow rail traffic to seamlessly traverse national as well as regional boundaries at increasing levels of performance. A significant requirement and major challenge for PTC, similar to the European experience, is that a PTC system for a particular railroad must provide

Page 1 of 9

8 – Technical Forums

Train Control in 2010

interoperability to allow the safe movement of trains of other railroad carriers within its System. Resignalling in Urban Transit Many Urban Transit Systems in North America, and indeed around the world, are focused on the problem of replacing an aging signalling infrastructure while maintaining continued operation. Such projects often require the resignalling equipment to be installed in existing vehicles. The Transit Systems are often also of such magnitude that they can only be implemented on a segment by segment or line by line basis. To add to their complexity, in some instances, lines or services may overlap to allow fleet from adjacent lines to operate on common sections of track. Consider the example in Figure 2 as follows:

Furthermore, in some projects the Owner may choose to maintain an underlying track circuit system throughout Line A to accommodate other unequipped trains such as maintenance vehicles, for the sharing of maintenance facilities with other lines, and as well as to provide a limited broken rail detection capability. Summary As a result of the complexity of the engineering for such PTC and resignalling projects, which are mainly “brown-field”, and particularly with the added requirements of mixed modes, interoperability and cutover, the application of SE practices becomes even more important to ensure success. System Engineering Standards and Processes

Line B

Line A

Shared Track

Figure 2: Resignalling in Urban Transit

Line A is required to be resignalled due to the aging of infrastructure and capacity constraints. Communication based train control (CBTC) is selected both to meet the operational needs and because it offers the best solution for resignalling while allowing existing operations to continue. All the vehicles that service Line A can be equipped with onboard CBTC equipment; however the operation of Line A must still accommodate Line B fleet that may be scheduled for resignalling following the successful completion of Line A. In this case, Line A must still maintain the existing signalling system on the section of shared track, and the new CBTC system must not only interface with that system, but also the interlockings on Line B, adjacent to the shared track. These latter requirements are essential in order to both maintain safe train separation between the non-CBTC equipped, unequipped trains from line B and the Line a CBTC equipped trains on the shared track section.

Consistent system engineering practices must be adopted and followed by all stakeholders in the Project to ensure consistency in the use of terminology and methodology. The IEC standard 15288 is the international standard for Systems and Software engineering - System life cycle processes. The IEC standard has been adopted by many national standards bodies, and the International Council on Systems Engineering (INCOSE) recently updated their Systems Engineering Handbook to bring it into alignment with the IEC standard. The EIA-632 standard; Processes for Engineering a System, is similar to the IEC standard. Many system and subsystem suppliers have developed their own processes that may or may not be completely consistent or compatible with each other, but in practice will follow one or other of the SE standards. However, in the same way that a supplier’s QA Manual is adapted to align with the Project QA requirements in the form of a QA Plan, so the suppliers System Engineering Practices must be aligned with the Project SE requirements, in the form of a SE Plan to ensure that a consistent approach is followed by all members of the Project team.

Page 2 of 9

8 – Technical Forums

Train Control in 2010

THE PROJECT MUST BE SEEN FROM A PROCESS PERSPECTIVE A Project is a single endeavour, with a defined objective or set of objectives (such as the implementation of a new signalling system), and with a defined start and end date. The successful execution of the Project requires the concerted application and orchestration of processes throughout the Project organisation. This is shown in the following figure found in the SE Handbook, which is in turn derived from the IEC system engineering standard 15288.

Copyright © 2010 International Council on Systems Engineering, subject to the restrictions on the INCOSE notices page

Figure 3: System Life cycle Processes Overview per ISO/IEC 15288:2008

Within the Project there will be many stakeholder relationships, both customer and supplier:  Each organisation (Owner’s and suppliers’) involved in the Project will employ its own particular Organisational Processes related to the needs and interests of that organisation; 

The Project Processes apply the assets and resources allocated by the enterprise to fulfill the Project Objectives as defined by the agreements between the organisations involved in the Project;



The Agreement Processes recognise and manage the various customer and supplier relationships;



The Technical Processes are used to manage the technical activities of the Project, while the Project Processes are used to turn the Project requirements into a system that fulfills the Project objectives.

While the processes used by each organisation will not, and do not need to be the same, they must be consistent. Certain processes may need to be adapted for the Project as defined through the Agreement Process. Moreover, an appropriate Project team organisation is essential to effectively apply the necessary processes to ensure the successful delivery of the project. It is not sufficient, for example, to appoint a System Engineering Manager without first integrating the whole project team with a common purpose and direction. For example the system design must not be driven only by the needs of a single Owner’s department, such as the operations, maintenance or engineering groups, but must consider all needs with costs and benefits assessed in the evaluation of sometimes competing requirements to provide a balanced solution. Many transit organisations are quite large and with the financial and operational demands faced on a daily basis it is often difficult to reshape an organisation to also focus on large capital Projects such as resignalling, that clearly do not occur on a regular or repeatable basis. One worthwhile step to reshape an organisation for such a capital Project, while adopting a System Engineering approach, is to develop cross-functional teams. Key staff from different functional departments would be transferred to, or share time within a System Engineering group. These staff would take ideas to and from their original departments and would help to break down barriers and ensure that common goals and consistent user requirements could be developed. At the end of the Project the members of staff are then able to move back to their previous departments or on to other projects. Defining the Project The Project must be defined from various aspects beginning with the business (economic), regulatory and social needs that often drive the Project and the concepts that must be developed include three that are most important for a PTC or resignalling project:  The Concept of Operation (ConOps); how the system is expected to work from the operator’s perspective;

Page 3 of 9



The Concept of Deployment; how the PTC or new signalling system will be deployed or installed; and



The Concept of Support; how the system infrastructure will be maintained following deployment.

8 – Technical Forums

Train Control in 2010

for the system as a whole and for each subsystem or system element;

The System Engineering Plans Within the concepts of operations, deployment and support, Figure 4 illustrates the SE plans typically required to ensure the successful implementation of the signalling system.



System Safety Plan; governing all aspects of system safety and including safety certification;



System Staging Plan; this plan is important to define and manage the staged implementation and cut-over of the new signalling system as it is gradually integrated into the existing Transit System including wayside and vehicle components;



System Verification and Validation Plan; this plan is important to ensure that all requirements, at the System and subsystem level are verified and validated through test, inspection or prior qualification, and includes inspections, production tests, qualification tests and system acceptance tests;



The Technical Management typically include, for example:

THE PROJECT CONFIGURATION MANAGEMENT RISK REQUIREMENTS MANAGEMENT MANAGEMENT SYSTEM CHANGE ENGINEERING MANAGEMENT MANAGEMENT The System SYSTEM SAFETY

TECHNICAL MANAGEMENT

RAM STAGING

INSPECTION AND TEST



Change Management Plan; this is used to manage how changes are managed contractually and commercially;



Risk Management Plan; this is used to properly identify, analyse, assign and manage the various Project risks;



System Engineering Management Plan; this ties in other plans listed below, and governs the system and subsystem design, development and integration, for both hardware and software;



Requirements Management Plan; governing how requirements are captured, analysed, allocated by subsystem, and managed through to implementation, test and final acceptance;



Reliability, Availability and Maintainability (RAM) Plan; describing how the RAM targets will be defined, allocated, achieved and validated

would

o

Electro-magnetic Compatibility (EMC) Plan; used to ensure that the existing EM environment is understood, that the system operates within that environment, and that the various system elements do not either affect the System performance or adversely affect the existing environment;

o

Shock and Vibration Plan; used for example to ensure that system components mounted on the vehicle, are not affected by the range of shock or vibration experienced;

o

Environmental Management Plan; similarly the system equipment must operate without degradation to performance or life within the intended environment including, temperature, humidity, etc; and

o

Interface Management Plan; describing how interfaces are managed, both within and external to the system, and includes civil, electrical, mechanical and software interfaces. Following from this will be the separate Interface Control Documents (ICD) for each interface defined in the plan.

Figure 4: Typical System Engineering Plans

The figure serves to illustrate that these plans cannot be seen in isolation but must be viewed as an integrated and co-ordinated collection necessary to deliver the system. These plans are further described as follows:  Configuration Management Plan; this is important to control the System implementation and governs all configurable items such as hardware, software, serialized equipment, drawings and documents, and how changes to such items are recorded and managed;

plans

The plans all inter-relate; for example, the control of shock or vibration (e.g., for vehicle mounted equipment) may require development of a mechanical interface, while the control or mitigation of electro-magnetic interference (EMI) may require an additional electrical interface. These interfaces may in turn impact maintainability, reliability or even safety. One question to be addressed for any resignalling Project is who writes these plans, or when they should be

Page 4 of 9

8 – Technical Forums

Train Control in 2010

written. The answer is that the plans should be developed at each level of the supply chain, but only to the degree necessary based on the scope of work and level of responsibility or risk that is defined for that level. The Owner should develop a set of plans that then serve as direction for the Owner’s organisation, the departments within that organisation, as well as the consultants and various system suppliers necessary to implement the Project. At the top level, the development of such plans by the Owner will provide input to the contract documents including technical specifications throughout the supply chain.

THE INTEGRATED SYSTEM The Project objective (in this case, the implementation of a new signalling system) cannot simply be viewed as a collection of equipment with some software, but must be viewed as an integral part of the full Transit System (the System) together with Passengers, Operations and Maintenance, and relating to the concepts of operation, deployment and support described above. For example when specifying a signalling system, passenger considerations will be assessed through the review of Quality of Service requirements such as:  Reliability measured through consistent on time performance;



Failure management strategies and processes; and



Safety criteria.

The subsequent analysis of the requirements may then dictate the signalling technology best able to meet the Project’s needs, where the requirements are developed first at the system level, with further development of requirements down to the subsystem, equipment and component level. It is important that at each level of requirements definition that requirements are not over-developed leading to constraints in the next stage of design and requirements development. Thus, within the parameters of the system requirements, the system designer must be allowed to develop the subsystem requirements, and so on. Thus, the system design is driven from the user requirements from the top down, with iterations in both the design and in the lower level requirements as definition is increasingly added to the system design. A View of the System A “closed” passenger Transit System can be described using the following diagram (Figure 5), with the train control or signalling system, side by side with the vehicle at the heart of the Transit System. The term “closed” is used where the Transit System does not share its track with vehicles from any other system, and is thus less complex than many resignalling or PTC examples, but serves to illustrate the many interfaces in a System.



Schedule adherence; the on-time arrivals and departures of trains at stations, etc.;



Ride comfort, e.g. the onboard train control must be able to deliver jerk limited control;



Convenience, short headways (train separation) and flexible operations meeting passenger demand;

Operations



Travel time improvements;

Trackwork



Safety; and



Interface Requirements.

Civil

Stations

These will be considered through the development of functional and performance requirements such as:  Performance criteria, e.g.:

Fare Collection

Vehicles

Signalling

Radio

Bridges and Tunnels

Communications Power Supply Depot Maintenance

o

Ride quality,

o

Headway,

o

Trip times,

o

Flexibility of operations (demand, failure management modes, special services, etc.);

PASSENGERS



Reliability and availability criteria;

Figure 5: Passenger Transit System – Closed

Many Transit Systems including freight, passenger rail and mass transit where vehicles from different railroads or Systems traverse boundaries to operate in

Page 5 of 9

8 – Technical Forums

Train Control in 2010

adjoining jurisdictions, Lines or Systems would be termed as “open”. Thus, for such “open” Systems the complexities of integration are even greater due to the need for interoperability and interfaces with adjoining Systems. When viewed as the whole it is apparent that a change to any single subsystem or system element can have an effect on the overall System. For a completely new or “green-field” project, in a closed environment, the integration is less complex because each element can be adapted during the course of the Project as requirements evolve, including the operations, maintenance and passenger interaction. However resignalling projects and most PTC projects are truly “brown-field” with many elements that are fixed or that cannot change without great disruption or cost to the System and to passenger or freight operations. In this case, the Owner must assume a greater degree of responsibility to define requirements and integrate the new system into the old. Consequently, there is a corresponding increase in risk for the Owner and this risk must be quantified and managed, and carries a real cost. The fixed elements and interfaces with the existing system are key factors in the definition of the new signalling system. These should be defined as early as possible in the project and ideally before the design work begins. The interface definitions should extend beyond physical or mechanical elements (i.e., number of conductors used in connections) but also include functional behaviours of the existing system and functions that are expected of the new equipment. Safety considerations and ownership of interface hazards also need to be defined and established early in the project so each contractor can address them early in the design minimizing cost and risk of rework. The System integrator In any SE project the role of System Integrator is critical, but especially so for a resignalling project. The System Integrator must ensure:  Removal of “silos”; to ensure the System is not seen as a collection of elements, but as a whole; 

A common approach and set of objectives between parties;



Management of risks;



Verification and validation of System Level requirements;



Management of subsystem interfaces;



Compatibility of requirements subsystems or system elements; and



Apportionment of performance requirements, such as safety, reliability and weight allocations, and the disaggregation of functional requirements that involve multiple subsystems.

between

Who is the System integrator? The PTC or new signalling system must be integrated within the overall System, but who should be responsible for that integration is often unclear. A system or subsystem supplier cannot control anything beyond their equipment interface. With a “green-field” transit project, the role is often assumed by a full turn-key Transit System supplier who takes responsibility for the full System delivery, performance and certification. With a “brown-field” project involving resignalling or the application of PTC, the System Owner must take much of this responsibility or assign it completely to a specific organisation within the Project or a competent consultant. Before preparation of any contract document an initial risk analysis is critical to identify and quantify the risks. Risks can then be assigned to each party in the overall Project organisation (Owner, consultant, or supplier), according to which party is best able to manage each specific risk, and at the lowest overall cost to the Project. Subsequently, the risk assignment is able to be allocated and managed through the contract documents, including the scope of work, the technical specifications and the contract terms and conditions. From the outset, the Owner must, as described above, also develop the high level SE plans necessary to implement the Project, and these plans will also serve to provide inputs to the various contract documents including the development of plans at each level in the supply chain.

LESSONS LEARNED FROM OTHER RESIGNALLING PROJECTS Lessons are continually learned from one project and applied to the next. The Project schedule and budget are critical, and this is true throughout the supply chain, from the Owner right down to the component suppliers. Many signalling systems now incorporate a significant amount of complex software. This is particularly true of CBTC systems. Some of the important lessons to be considered are listed below.

Page 6 of 9

8 – Technical Forums

Train Control in 2010

Develop a Pilot Project or Prototype

System Integration

Before application of a new technology with major operational, safety and financial implications, it is essential that some prototyping is conducted which could include either a demonstration or pilot project with limited impact on overall operations. This provides some assurance that the design requirements are correct, and the selected technology is validated and correctly applied. Some examples of such development and pilot activities include:  Installation and test of PTC systems on the Pueblo, CO. test track; 

 

Many Transit System suppliers have developed their own test tracks where they are able to develop and test new products, and are also able integrate signalling and vehicle systems for integrated design and qualification testing in a controlled environment; Pilot ERTMS projects were implemented in Europe before wider applications; NYCT used the Canarsie Line resignalling project as a pilot project to “service prove” the technology for broader NYCT application.

Requirements Management 

Standard requirements management tools must be used to allow integration of subsystem requirements among project team members (client, suppliers, partners, etc).



The tools used must permit effective and efficient tracing of the contract requirements to the lowest level of Subsystems Requirements Specifications and to the individual Subsystem Verification and Validation activities.



It is important that a clear scope of work is developed that defines the interfaces and demarcation lines between the Owner or Agency responsibilities and the Contractor’s responsibilities, and sets out who has the overall System Integration (SI) responsibility. This includes responsibilities for:  Software development across subsystem boundaries where there is existing and new equipment; 

Overall system safety where a combination of existing equipment (operated and maintained by the Owner) and new equipment are required to deliver the required System safety levels;



Similarly, system performance targets such as headway or trip speed that might be affected by existing infrastructure or equipment operated and maintained by the Owner or Agency.

System Staging The Project may be segmented geographically to be implemented in stages. These stages may make sense from a civil perspective (e.g. at a tunnel boundary), but do not always make sense operationally. If system resignalling cannot be accomplished in a single stage then construction and operational needs must be coordinated to make sure that where possible, as each segment of construction and installation is completed it can logically be turned over to test and commissioning and then to operations in order to minimise operational disruptions and also so that the benefits of the new installation can be realised as early as possible. Schedule (Track Access)

Analysis of the System performance and operations under the many possible failure modes that might be experienced. This analysis must be done at the early design stages, consistent with the ConOps, so that mitigation for failure modes can, wherever practical, is built into the System. If mitigation is not cost effective then the operations response must be planned to allow for a graceful degradation in performance, and efficient recovery once repairs are made.





Page 7 of 9

Sufficient access must be provided to the track and vehicles for installation and test, including: o

Mobilisation times for equipment and operations, allowing for the working practices of Agency staff assigned to support the activities (breaks, etc.) and the time required to transfer track occupancy from operations to installation, test and commissioning;

o

Restoration and hand-back to normal operations following completion of work.

A key ingredient in test planning is to minimise the amount of testing on the railroad property and to maximise the potential for factory testing

8 – Technical Forums

Train Control in 2010

or the use of a test track. Nevertheless, with the complexity of resignalling projects simulation of actual field conditions or interfaces to adequately test in the factory is difficult, and a test track may offer limited capability, and so there must be sufficient allowance in the schedule for subsequent releases of software and hardware once changes have been identified through problem identification in the field.

Mature the System 



The allocation of sufficient time on the track with both vehicles and equipment running is important to accumulate as much service experience and performance data as possible to verify and validate system performance.

The benefits are maximised if the equipment is installed fleet wide, and not just on a collection of “ideal” vehicles.

Testing Sufficient testing must be undertaken, not only of normal operations, but also of the failure modes and operational responses, and this must include emergency situations. This testing must be coordinated with the training of staff, and with any outside agencies necessary for emergency response. System Operating Requirements

For overlay systems in particular not only must the system must be designed, but also the installation must be planned to maximise the benefits from actually running the trains. This allows data monitoring and collection while at the same time the system matures. For example, where the actual test time to allow full system operation is limited it is beneficial if the onboard equipment is designed to run in a “shadow” mode (i.e. without control, but able to monitor inputs and accumulate data), with the following potential benefits: o

Elimination of infant mortality failures unearthed during this period;

o

The collection and analysis of positioning data including the accumulation of position errors, and the validation of any software maps (particularly for a communication based signalling system);

o

The operation of peripheral equipment such as sensors (tachometers, accelerometers, etc.) and the collection of sensor data

o

The operation of any on-board diagnostics and health reporting equipment provided as a part of the system where that operation can be used to validate functionality and performance and provide real life training for the operators;

o

Operation in the actual environment (shock, vibration, EMC, etc.), with validation that the equipment can operate in that environment;

o



It is difficult for suppliers to fully understand the local operations and resulting requirement; therefore additional effort must be undertaken by the Operator and signalling supplier to bridge any gaps in understanding;



Similarly the Operator may not fully understand the opportunities or capabilities offered by a new technology for both the normal and failure management modes of operation. As a result the user requirements may not be congruent with the application of such technology, or may limit the application. It is, therefore, important that all departments that contribute to the development of system requirements understand and are able to adapt to the capabilities of the proposed technologies.

Evolution of Technology Requirements, technologies and capabilities evolve, and eventually become obsolete, for example there have been many advances in recent years in RF technology, and such advances generally outpace other more conventional technologies used in railways. Therefore, open non-proprietary standards should be used that can be easily replaced and integrated into the signalling system as the technologies and standards evolve, and as equipment becomes obsolete during the life of the System. Coordination with other Capital Programs

Testing of any new data communications (train to wayside), and detection of problem areas. Page 8 of 9



Coordination with other capital programs which have critical relationships is important, as illustrated by the following examples;

8 – Technical Forums 



Train Control in 2010

Where a previous capital program has implemented a system wide communication network that may not be adequate for the network requirements of the replacement signalling system without significant modification; Where the Owner is also planning fleet upgrades and replacements; o

Ideally the new signalling equipment should be installed in new vehicles, thus greatly simplifying the system integration where the new vehicles can be designed from the start to support the signalling system, carrying significantly lower risk than modifications to an existing vehicle;

o

However when new signalling equipment must be installed in older vehicles, there must be consideration of the life remaining in the older vehicles, and whether there should be some coordination with other overhaul activities to update other subsystems at the same time.

Procurement Approach Many Owners use the contract format developed by the Construction Specification Institute (CSI), however this format and breakdown of construction elements does not always lend itself to an integrated System Engineering approach, and as a result system information may need to be duplicated or replicated throughout the contract. This, in itself requires more attention to Configuration Control at the contract preparation and tendering stages in order to define responsibilities without contradictions, gaps or omissions. One solution that has been adopted is to use the CSI format for certain elements such as the installation works, and the provision of any support infrastructure (e.g. cableways, power, grounding, etc.), but with the use of performance or functional based contract documents for the signalling system and System Engineering requirements. Consultants

SYSTEM ENGINEERING MUST BE TRULY TOP DOWN While it is widely understood that the successful application of System Engineering demands a top down approach, one key difficulty is often defining the start point. At what point in the Owner’s organisation or in the Project process do we begin to implement SE practices? The answer is that System Engineering must begin at the top of the Organisation and even while the Project is in the infant stages of planning, for it is at this point that the key decisions will be made that will define the Project organisation and the high level requirements that will affect the final outcome of the Project. Such Projects may involve capital costs measured in hundreds of millions of dollars or higher with expectations that they will have a life of 30 to 50 years. In such cases the effects of the decisions made will have far reaching and long lasting consequences. Just as a house built on a poor foundation will not last the intended lifetime, a complex re-signalling Project will only deliver the full potential benefits with the solid base of the early application of SE practices, and thereby avoid possible cost or schedule overruns, or be forced to compromise on performance. At first glance some of the lessons learned may not appear typical of System Engineering, but may appear to relate to more Project Management activities (e.g. commercial, schedule, contract, etc.). However it is often found in such complex projects that performance or schedule are often sacrificed in favour of cost, and that compromises are made when faced with difficulties. Engineering has been defined as compromise; since it is often a compromise between cost, schedule and performance. System Engineering must therefore provide a link between and involve all aspects of any Project in order to be effective. Thus, for any complex project, such as a resignalling or PTC project, a System Engineering approach must be adopted as soon as the Project is conceived in order to maximise the benefits and probabilities for success. As a result and with the right organisation and Project team in place, the Project then has a solid foundation on which to deliver the expected system performance while avoiding, or mitigating any painful cost and schedule compromises.

It is important that the Owner’s consultant team also reflects a System Engineering approach and does not adopt a departmental approach, but rather eliminates silos and brings together the necessary Engineering disciplines into an integrated Project team to ensure that the System Engineering perspective governs the design and deliverable reviews, thereby enabling the Contractor to deliver a truly integrated system. Page 9 of 9