C.13_Program_System_Eng,_Testing,_and_Commissioning_Reqs.pdf

IFB No.: HSR25-12 Fresno Station Early Works

C.13 Program System Engineering, Testing, and

Commissioning Requirements Rev. 1.0

Revision(s) Date Description 0 12/10/2025 Initial Release

IF

B

N o.

: H S

R

-1

IN

IT

IA

L

R E

LE

A

S E

2/

/2

California High-Speed Rail Authority

Standard Specifications REQS-0018 – Program System Engineering, Testing, and

Commissioning Requirements Rev. 1.0

Authored: 12/9/2025 Mohamed El-Guindy / Stefan Oberthuer Date

Checked: 12/9/2025 Rik Lor, Certification and System Safety Lead Date

Checked:

R Greenwood

12/9/2025 Rubina Greenwood, Deputy Director Network Integration Date

Approved: 12/9/2025 Ryan Scott, Director of Rail Engineering Date

Released: 12/9/2025

Amit Joshi, Configuration Manager Date

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 2 of 35

Document Revision History – Program System Engineering, Testing, and Commissioning Specifications

Second Edition

December 2025

Revision Date Revision Description

0.0 October 2025 First edition

1.0 December 2025 Review and updates for clarity

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 3 of 35

TABLE OF CONTENTS

1 SCOPE OF THE DOCUMENT

1.1 SCOPE DESCRIPTION

2 REFERENCE STANDARDS AND DOCUMENTS

2.1 OVERVIEW

2.2 PROJECT PHASE DEFINITION

2.3 DEFINITIONS

3 SYSTEM DEVELOPMENT LIFE CYCLE (SDLC) REQUIREMENTS

3.1 SYSTEM ENGINEERING MANAGEMENT PLAN (SEMP)

3.2 SYSTEMS DEVELOPMENT LIFE CYCLE

3.3 SCOPE MANAGEMENT

3.4 TIME MANAGEMENT

3.5 ORGANIZATIONAL MANAGEMENT

3.6 RISK MANAGEMENT

3.7 SYSTEM DEVELOPMENT LIFE CYCLE MODEL

3.8 PROJECT INITIATION PHASE

3.9 CONCEPT PHASE

3.10 SYSTEM DEFINITION AND OPERATIONAL CONTEXT PHASE

3.11 RISK ANALYSIS AND EVALUATION, SPECIFICATION OF SYSTEM REQUIREMENTS, ARCHITECTURE &

APPORTIONMENT OF SYSTEM REQUIREMENTS

3.12 DESIGN AND IMPLEMENTATION PHASE

3.13 MANUFACTURE / CONSTRUCTION PHASE

3.14 SYSTEM INTEGRATION

3.15 SYSTEM VALIDATION

3.16 SYSTEM ACCEPTANCE PHASE

3.17 CROSS CUTTING SYSTEMS ENGINEERING METHODS

3.18 SPECIALTY ENGINEERING INTEGRATION

3.19 REVIEW MILESTONES AND ASSOCIATED DELIVERABLES

4 INTERFACE MANAGEMENT REQUIREMENTS

4.1 INTERFACE MANAGEMENT

4.2 PROJECT LIFECYCLE PHASES

4.3 SYSTEM ARCHITECTURE AND INTERFACE DEFINITION

4.4 INTERFACE VERIFICATION, TESTING AND CLOSURE

4.5 REQUIREMENTS FOR INTERFACE MANAGEMENT TOOLS AND TECHNIQUES

5 SYSTEM INTEGRATION REQUIREMENTS

5.1 SYSTEMS INTEGRATION GENERAL REQUIREMENTS

5.2 INTEGRATED RAILWAY FUNCTIONS MANAGEMENT

5.3 SYSTEMS INTEGRATION ROADMAP

6 TESTING AND COMMISSIONING REQUIREMENTS

6.1 GENERAL

6.2 TEST AND COMMISSIONING MANAGEMENT PLAN

6.3 INTEGRATION TESTING FACILITIES

6.4 T&C DOCUMENTATION

6.5 T&C STAGES

6.6 TEST ENVIRONMENT AND READINESS

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 4 of 35

1 SCOPE OF THE DOCUMENT

1.1 Scope Description

1.1.1 The scope of this Technical Specification is to set the Authority’s Requirements for

System Development Life Cycle (SDLC), interface management, integration management and Testing & Commissioning processes.

1.1.2 This Technical Specification is based on the following reference Plans:

o Interface Management Plan (PLAN-1022) o Program Integration Management Plan (PLAN-1029) o Testing & Commissioning Strategy (GUIDE-00005) o Systems Development Life Cycle (SDLC) (REQS-003) o System Engineering Management Plan (PLAN-1025)

1.1.3 This Technical Specification provides non-functional (or process) requirements applicable to the Contractor for system development, system integration, system interfaces, Testing and Commissioning and system engineering in general. The Contractor should also refer to the Plans referred in Clause 1.1.2 for additional details on how the Authority expects the related tasks to be performed.

1.1.4 These requirements shall be implemented and managed in conjunction with the scope of work as outlined in the Contract Technical Requirements.

1.1.5 The requirements are formulated using the following words and their meanings:

“Shall”: Indicates mandatory requirement that must be strictly implemented. Any impossibility to fulfil this requirement must be agreed through a derogation case (see change management procedure).

“Must”: Indicates an obligation or a mandatory requirement.

“Should”: Indicates preferred course of action, recommendations. No agreement of derogation is necessary, there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course - for example the same goal is reached by other solutions, which are permissible within the binding standards or documents.

“May”: Indicates a permissible course of action within the limits of the standards, but which is not mandatory to be fulfilled.

The Schedules define the technical scope of the Work for the Project. The requirements set out in these Schedules are mandatory. The Contractor is obliged to comply with these requirements, subject to any waivers and variations from specific requirements that the Authority may grant in its sole discretion, or for which the Contractor may apply through the Design Variation Request (DVR) process.

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 5 of 35

2 REFERENCE STANDARDS AND DOCUMENTS

2.1 Overview

2.1.1 The Contractor shall review the documents listed in the following table and ensure that the work complies with the objectives of these standards. Where applicable, the Contractor shall demonstrate alignment through referenced requirements, mapped evidence, or objective fulfillment within the assurance Case.

TABLE 1 - REFERENCE STANDARDS & DOCUMENTS

ID Reference Document Details

European Union (EU) – Agency for Railways (ERA) – Technical Specifications for Interoperability

(TSI):

Technical Specifications for Interoperability (TSIs) are the technical and operational standards set by the European Union Agency for Railways (ERA) to ensure the interoperability of the European Union's railway system.

INCOSE Systems Engineering Handbook Rev. 5: A Guide for System Life Cycle Processes and Activities

A comprehensive guide to systems engineering activities across any number of possible projects. From automotive to Defense to healthcare to infrastructure.

EN 50126:2017: Railway Applications

– The Specification and Demonstration of Reliability, Availability, Maintainability and Safety

EN 50126:2017: Railway Applications – The Specification and Demonstration of Reliability, Availability, Maintainability and Safety

ISO/IEC/IEEE 15288:2023: Systems and Software Engineering – System Life Cycle Processes

EEE/ISO/IEC 15288-2023 provides a common framework for system life cycle processes, from conception to retirement, and covers acquiring and supplying systems.

ISO/IEC/IEEE 29148:2018: Systems and Software engineering – Life Cycle Processes – Requirements Engineering

ISO/IEC/IEEE 29148:2018 specifies processes for requirements engineering in systems and software life cycles and provides guidelines for applying requirements.

Project Management Institute: Project Management Body of Knowledge, Rev 7.0

The Project Management Institute's (PMI) PMBOK® Guide, Seventh Edition is the latest version of its project management standard, focusing on enabling desired outcomes rather than just following a rigid process. It shifts from a process-based approach to one based on 12 project management principles and structured around eight project performance domains.

7 U.S. DOT FRA, MP 54: Readiness for Revenue Operations

U.S. DOT FRA MP 54 is a monitoring procedure for the Federal Railroad Administration (FRA) that outlines the requirements for evaluating a rail project's readiness for revenue service. It ensures that all systems, equipment, and personnel are in place for safe, reliable, and efficient public operation, covering areas like safety, integration of all components, operational capability, and the management capacity of the grantee.

SO/IEC/IEEE 42010 - Systems and Software Engineering - Architecture Description

An international standard that specifies how to document the architecture of systems, software, and enterprises, providing a framework for creating, analyzing, and sustaining architecture descriptions (ADs).

9 REQS-0003 – System Development Life Cycle (SDLC)

The purpose of this document is to describe the Authority’s California High Speed Rail approach for the Systems Development Life Cycle (SDLC) specific to track and system procurements to provide guidance for System Engineering Activities.

10 PLAN–1022 – Interface Management Plan (IMP)

The objective of the Interface Management Plan (IMP) is to ensure that all elements of the California High-Speed Rail Authority (Authority) system, REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 6 of 35 which are procured under different contracts and between different disciplines, will meet the contract(s) requirements.

11 GUIDE-0005 – Testing and Commissioning Strategy

The Authority developed a formal Testing and Commissioning (T&C) Strategy in place, which highlights a clear vision and direction for the validation of the System of Systems (SoS) including dedicated system and subsystem levels.

12 PLAN-1025 – System Engineering Management Plan

This Systems Engineering Management Plan (SEMP) serves as a foundational document to ensure the successful implementation of the California High-Speed Rail System (CHSRS) in alignment with established systems engineering processes.

13 PLAN-1038 – Project Configuration Management Plan

The Configuration Management Plan ensures that project deliverables are accurately documented, controlled, and maintained throughout their lifecycle, providing consistency, quality, and a clear record of changes.

14 PLAN-1027 – Submittal Review Management Plan

The Submittal Review Management Plan describes the submission and review of engineering documentation, including (but not exclusively) drawings, reports, plans, schedules, calculations, technical notes, software design reviews, and sketches associated with the California high-speed rail program. It includes requirements for design reviews, process workflows, and the revision and finalization of designs at all stages in the engineering product’s lifecycle.

15 PLAN-1004 – Safety and Security Management Plan (SSMP)

The Safety and Security Management Plan defines the process for identifying, evaluating, and resolving safety hazards and security vulnerabilities associated with future railroad operations of the system prior to the start of revenue service.

16 PLAN-1032 – Rail System Safety Plan (SSP)

An appendix to the Authority SSMP, the Rail System Safety provides a comprehensive executive framework for implementing safety management across all California High-Speed Rail (CHSR) CORE SYSTEMS during procurement, design, construction, testing, and commissioning phases.

17 FRA CFR title 49, Parts 200-299 U.S. Department of Transportation, Title 49 Code of Federal Regulations, Parts 200 to 299

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 7 of 35

2.2 Project Phase Definition

TABLE 2 - PROJECT PHASE DEFINITION

EN50126 Phase SDLC Review Milestone Definitions

Project Initiation Phase

Project Initiation Review

(PIR)

Before the V-lifecycle phase “Concept” begins the SDLC has its phase “Project Initiation” where the Contractual requirements baseline (CBL) is developed. The concept phase can only start when the contractor knows the contractual requirements including the technical contractual requirements (TCR). This will include also the project plans, where the contractor must demonstrate how to perform the project (contractor submittals such as SEMP, System Safety Plan, RAM Plan, etc.)

Concept System Definition Review

(SDR)

After the contractor understands the technical contractual requirements, the concept can be developed, the System Requirements Baseline (SBL) can be started during this phase. This will ensure a sufficient understanding of the system.

System Definition and Operational Context

System Requirements Review

(SRR)

At this phase the concept and the SBL will be further developed also through additional technical requirements that are analyzed from given contractual Standards (Requirements Analysis). At the end of this phase the SDLC review milestone SRR is accomplished with its dedicated SBL.

Additionally, a description of essential characteristics and functions of the system, and clarification of the interfaces to other systems.

Risk Analysis and Evaluation

In this V-lifecycle phase, the SDLC will perform their Engineering analyses for developing new requirements important for further design progress. The engineering analysis may be but not limited to safety risk analysis, RAM analyses, design report, etc.). Additionally, to the development of the SBL, the System and Interface Breakdown Structure will be developed.

Specification of System

Requirements

From the SDLC point of view the engineering analyses will continue, and all further new requirements will flow down into the parallel developed Allocated Requirements Baseline (ABL). The System and Interface Breakdown Structure will be also further developed.

Architecture & Apportionment of

System Requirements

Preliminary Design Review

(PDR)

During this V-lifecycle the same activities are performed. At the end of this V-life cycle phase the SDLC has developed their full System and Interface Breakdown Structure, and the ABL. The engineering analyses have been finished. The design is at a preliminary stage and the SDLC milestone PDR has been reached.

Design and Implementation

Detailed Design Review

(FDR)

Subsystems and components should be designed according to the allocated requirements. At the end of this V-life cycle phase the SDLC has reached the review milestone FDR with its key deliverable FBL.

Manufacture / Construction

• Factory Acceptance Testing Review (FAR)

• Site Acceptance Testing Review (SAR)

According to the SDLC, manufacturing of a subsystem is finished with the Factory Acceptance Testing Review (FAR), where the manufacturer must show that the produced systems meet the required performance. After the FAR the subsystem can be built on site, which is part of this V-lifecycle milestone. After field construction the subsystem will be tested on-site.

This is given through the SDLC review milestone Site Acceptance Testing Review (SAR).

Integration

• System Integration Testing Review (SIR)

• Dynamic Testing

Review (DYR)

All subsystems will be delivered and installed on site to form the complete high-speed rail (HSR) system. At this stage the following testing of the entire HSR-system can be performed:

• System Integration Testing (SIT); and, REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 8 of 35

EN50126 Phase SDLC Review Milestone Definitions

• Dynamic Testing (DYT)

System Validation Trial Running Testing Review (TRR)

After all subsystems are integrated and dynamic testing with the trainset has been accepted the performance of the entire system can be tested in the Trail Running Testing Phase (TRT). The TRT is completed with the Trail Running Testing Review (TRR).

System Acceptance System Certification & Acceptance Review

The V-Life Cycle phase symbolized the last SDLC review milestone. It is the System Certification & Acceptance Review (SCR), which should demonstrate compliance of complete system.

Operation, Maintenance Performance Monitoring

N/A This phase is not part of the project SDLC and is not under the responsibility of the design and build contracts. This phase has no influence on the SDLC scope.

Decommissioning N/A This phase is not part of the project SDLC and is not under the responsibility of the design and build contracts. This phase has no influence on the SDLC scope.

2.3 Definitions

TABLE 2 – SYSTEM DEVELOPMENT LIFE CYCLE AND INTEGRATION DEFINITIONS

Term Definition Contract The Contractor’s respective agreement with the Authority.

Contractor A contractor or consultant that has executed an agreement with the Authority, the contents of which require compliance with this SDLC document. The reader should interpret any mention of the term “Contractor” as directly applicable to their position.

Intra HSR sub-system, intra-site testing

Applies the interfaces between system elements of the same HSR sub-system installed at the same site that have not previously been tested during factory acceptance and/or field / site testing (e.g., at an ATC interlocking site, within operations control center [OCC], maintenance facilities)

Intra HSR sub-system, inter-site testing

Applies to interfaces between the same HSR sub-system installed at different sites (e.g., between an ATC interlocking site and the OCC)

Inter-HSR sub-system, intra-site testing

Applies to interfaces between the different HSR sub-systems installed at the same site (e.g., between the wayside power cubicle and the ATC system at the same ATC interlocking site)

Inter-HSR sub-system, inter-site testing

Applies to interfaces between the different HSR sub-systems installed at different sites (e.g., between traction power equipment and traction power facilities and Supervisory Control and Data Acquisition [SCADA] equipment at the OCC)

Subsystem

Subsystems of the HSR system are for example: Traction Power, OCS, Track, Signaling, Trainset, Communication, etc.

System The entire California High-Speed Rail System including the installed HSR subsystems

TCR Any contract requirements specifying the operational and technical requirements of CHSRS.

TCS

Any submittal that addresses TCR(s) through the SDLC, including but not limited to operational and maintenance plans, requirements documents, system architectures, interface documents, preliminary and/or final/detailed designs, specifications, quality, inspections, testing, commissioning plans, procedures, records, certifications, etc.

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 9 of 35

3 SYSTEM Development Life Cycle (SDLC) Requirements

3.1 System Engineering Management Plan (SEMP)

3.1.1 The Contractor shall prepare, submit and implement a Systems Engineering

Management Plan (SEMP).

3.1.2 The Contractor shall ensure that the SEMP is consistent with all other documentation related to the project.

3.1.3 The Contractor’s SEMP shall be maintained as the overall controlling document governing all phases of the project.

3.1.4 The Contractor shall ensure that the SEMP covers, but is not limited to, the following aspects:

• System design;

• Interface Management;

• Procurement and manufacturing;

• Testing, integration, and commissioning;

• Requirements Management;

• Verification and Validation;

• Reliability, Availability, and Maintainability;

• System & Security Acceptance; and

• Digital Integration.

3.1.5 The SEMP shall include a description of the System Engineering processes; activities, tools, techniques and procedures applied to:

• Design Management;

• Requirement Management;

• Performance analysis and RAM analysis;

• System design;

• Software design;

• Human Factors;

• EMC; and

• Grounding & Bonding.

3.1.6 The Contractor shall provide Method statements describing the processes, procedures and activities to be implemented under the SEMP.

3.1.7 The SEMP shall include the overall structure, governance, roles and responsibilities to manage system engineering activities across the track and systems subsystems.

3.1.8 The SEMP shall include the interaction with Design, Construction, T&C, Project Management, and RAM and Safety activities and processes.

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 10 of 35

3.1.9 The SEMP shall include system engineering processes and activities throughout the project Lifecycle, including:

• Management of Requirements;

• Management of Verification and Validation;

• Management of Configuration;

• Management of Change activities;

• Management of System Architecture; and

• Management of Interfaces.

3.1.10 The SEMP shall include system engineering systems and tools, including if applicable DOORS, MBSE, BIM and Maximo.

3.1.11 The Contractor’s SEMP shall define the processes, tools, responsibilities, and timelines for system engineering activities.

3.1.12 The Contractor shall deliver the SEMP during the Project Initiation Phase.

3.1.13 The Contractor shall follow the same review, approval process for any update or modification to the Contractor’s SEMP.

3.1.14 The Contractor shall resubmit any updated SEMP to the Authority as per the Project Configuration Management Plan (PLAN-1038).

3.1.15 The Contractor’s SEMP shall describe their Model Based System Engineering (MBSE) approach.

3.1.16 The Contractor’s SEMP shall describe the process to integrate all systems architecture into the Authority IBM Rhapsody MBSE environment.

3.1.17 The Contractor’s SEMP shall include detailed technical and management processes.

3.1.18 The Contractor shall describe in the SEMP the planned System Development Life Cycle (SDLC) methodology and proposed efforts for planning, executing, monitoring and controlling a systematic engineering effort.

3.1.19 The Contractor shall describe in the SEMP the following for each applicable SDLC phase:

• Inputs;

• Outputs [Deliverables];

• Activities, tools and methods used to create the deliverables;

• Roles and responsibilities;

• Stakeholder coordination;

• Submittal and review milestones; and

• Performance metrics and reports.

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 11 of 35

3.2 Systems Development Life Cycle

3.2.1 The Contractor shall develop, implement, and maintain a SDLC describing the processes, organization, tools, and resources used to execute all SDLC activities in the corresponding scope of work.

3.2.2 The Contractor shall submit the SDLC as part of the Contractor’s SEMP for Authority approval.

3.2.3 The Contractor shall follow the same review and approval process for any update or modification to the Contractor’s SDLC.

3.2.4 The Contractor shall resubmit any updated Contractor’s SDLC to the Authority as per

PLAN-1038.

3.2.5 The Contractor shall plan and execute the SDLC requirements to deliver their contract as fully compliant HSR component that can be readily integrated into the overarching HSR system.

3.2.6 The Contractor shall follow PLAN-1027 for any Contractor submittal.

3.3 Scope Management

3.3.1 The Contractor shall develop, submit and implement a hierarchical and deliverable based Technical Work Breakdown Structure (TWBS).

3.3.2 The Contractor’s TWBS shall identify all TCS required in the Contract.

3.3.3 The Contractor’s TWBS shall identify the following for each Technical Contract Submittal

(TCS):

• Contract reference;

• Unique TCS identifier;

• TCS name;

• SDLC phase;

• SDLC milestone; and

• Due date.

3.3.4 The Contractor shall follow the same review and approval process for any update or modification to the Contractor’s TWBS.

3.3.5 The Contractor shall resubmit any updated TWBS to the Authority as per the PLAN- 1038.

3.3.6 The Contractor shall develop, submit and implement a hierarchical and deliverable based Contractor’s Work Breakdown Structure (WBS).

3.3.7 The Contractor shall follow the same review, approval process for any update or modification to the Contractor’s WBS.

3.3.8 The Contractor shall resubmit any updated WBS to the Authority as per the PLAN-1038.

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 12 of 35

3.3.9 The Contractor shall integrate the TWBS with the overall Contractor’s WBS.

3.4 Time Management

3.4.1 The Contractor shall develop, submit and implement a baseline schedule including all

TWBS deliverables in accordance with the Contractor’s Project Management Plan.

3.4.2 The Contractor’s baseline schedule shall include

• SDLC phase;

• SDLC milestones;

• TWBS deliverables;

• Assigned owner for each TWBS deliverable; and

• Associated activities for each TWBS deliverable.

3.5 Organizational Management

3.5.1 The Contractor shall prepare and submit an Organizational Breakdown Structure (OBS) subject for Authority approval.

3.5.2 The Contractor’s OBS shall present organizational and reporting relationships, including any joint venture partners, subcontractors, and suppliers as applicable.

3.5.3 The Contractor’s OBS shall identify each owner of deliverables identified in the TWBS.

3.5.4 The Contractor’s OBS shall identify each owner of HSR sub-systems, systems elements down to the lowest configuration item, and associated interfaces.

3.5.5 The Contractor’s OBS shall include a clear description of roles and responsibilities for each position.

3.5.6 The Contractor shall follow the same review, approval process for any update or modification to the Contractor’s OBS.

3.5.7 The Contractor shall resubmit any updated OBS to the Authority as per the PLAN-1038.

3.6 Risk Management

3.6.1 The Contractor shall develop, submit, and implement a Risk Management Plan and

Matrix subject for Authority approval.

3.6.2 The Contractor’s Risk Management Plan shall include the following:

• Risk Management Process and Methodology

• Risk Register and Risk Matrix

• Risk Review and Reporting Process

• Monthly Risk Review Meetings

• Integration with V&V and Configuration Activities

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 13 of 35

3.6.3 The Contractor shall treat technical risk mitigations as Technical Contract Requirements (TCR) following the requirement management process.

3.6.4 The Contractor shall follow the same review, approval process for any update or modification to the Contractor’s Risk Management Plan.

3.6.5 The Contractor shall resubmit any updated Risk Management Plan to the Authority as per the PLAN-1038.

3.7 System Development Life Cycle Model

3.7.1 The Contractor’s SDLC shall be in compliance with the EN 50126 V-lifecycle model.

3.7.2 The Contractor’s SDLC shall be in compliance with the INCOSE Systems Engineering Handbook.

3.7.3 The Contractor’s SDLC shall be in compliance with the FRA requirements to demonstrate readiness for revenue operations.

3.8 Project Initiation Phase

3.8.1 The Contractor shall submit the following during Project Initiation Phase:

• Contract Requirements Baseline (CBL);

• System Certification & Acceptance Plan (SCAP);

• Project Management Plan;

• Project Schedule; and

• Other key project plans, strategies, policies, as specified in the Contract.

3.8.2 The Contractor shall follow the same review and approval process for any update or modification to the Contractor’s CBL.

3.8.3 The Contractor shall resubmit any updated CBL to the Authority as per the PLAN-1038.

3.8.4 The Contractor shall capture the Contract requirements in the Requirements Management (RM) tool using the requirements management process.

3.8.5 The Contractor’s CBL shall capture the results of TCR analysis that is undertaken during this phase.

3.8.6 The Contractor shall develop, submit, and implement a SCAP describing the Contractor’s planned strategy to demonstrate that the HSR system is safe, secure, and ready to operate referring to Section 3.5 of Schedule-2: SCAP requirements document.

3.8.7 The Contractor shall follow the same review and approval process for any update or modification to the Contractor’s SCAP.

3.8.8 The Contractor shall resubmit any updated SCAP to the Authority as per PLAN-1038.

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 14 of 35

3.9 Concept Phase

3.9.1 The Contractor shall perform and submit a requirement’s analysis of the Standards and

Regulations that are stated in the Contract.

3.9.2 The Contractor shall identify new technical requirements from these standards and regulations that are applicable for the project and include these new technical requirements into the System Requirements Baseline (SBL).

3.10 System Definition and Operational Context Phase

3.10.1 The Contractor shall develop and submit a System Breakdown Structure (SBS), preliminary system design from a set of systems and sub-system.

3.10.2 The Contractor shall perform requirements analysis transforming the TCRs into well-formed system requirements.

3.10.3 The Contractor shall submit:

• SBL; and

• Trial Running Testing Plan (TRTP).

3.10.4 The Contractor shall allocate and baseline requirements on a system level based off the Contractor’s SBS in the RM Tool.

3.10.5 The Contractor’s SBL shall identify and allocate the operational requirements to be included in the RM Tool.

3.10.6 The Contractor shall develop, submit, and implement a TRTP describing the Contractor’s planned strategy to perform pre-revenue operation testing.

3.10.7 The Contractor’s SBL shall identify the complete set of stakeholder requirements and applicable TCRs subject to testing during the pre-revenue operation phase.

3.10.7.1 For each requirement, the Contractor’s SBL shall define the planned Verification and Validation (V&V) methods as defined in IEEE 29148.

3.10.8 The Contractor’s TRTP shall maintain a log of all tests performed during the pre-revenue testing period.

3.11 Risk Analysis and Evaluation, Specification of System Requirements, Architecture & Apportionment of System Requirements

3.11.1 The Contractor’s SBS shall be updated to develop a high-level, preliminary system design from a set of sub-systems and system elements that meet the system requirements and work together as a system.

3.11.2 The Contractor shall submit an updated SBS.

3.11.3 The Contractor shall submit the Allocated Requirements Baseline (ABL).

3.11.4 The Contractor shall submit System Architecture based on the Authority requirements.

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 15 of 35

3.11.5 The Contractor shall submit a Dynamic Testing Plan as a part of the Testing and Commissioning Plan.

3.11.6 The Contractor shall submit a System Integration Testing Plan (SITP).

3.11.7 The Contractor’s ABL shall allocate and baseline requirements on a sub-system and system element level in the RM Tool based off the Contractor’s updated SBS.

3.11.8 The Contractor shall submit the demonstration that the system’s behavior will satisfy the functional system requirements by providing at least one behavioral view or diagram (i.e., activity, sequence, or state machine diagram) for each system function.

3.11.9 The Contractor’s SITP shall describe how the HSR sub-systems and system elements will be integrated to form the complete HSR system as presented in the system architecture.

3.12 Design and Implementation Phase

3.12.1 The Contractor shall develop and submit the final design of the HSR sub-systems, system elements, and associated interfaces, including:

• Demonstrate that HSR sub-systems and system elements conform to the allocated requirements;

• Create the final design baseline; and,

• Develop a sub-system testing plan.

3.12.2 The Contractor’s FDL shall include evidence that the HSR sub-system, system elements, and the associated interfaces conform to the allocated requirements.

3.12.3 The Contractor’s FDL shall include the V&V methods identified for the allocated requirements following the verification and validation management process.

3.12.4 The Contractor shall submit:

• Final design;

• Final design with Objective evidence (Evidence that final design has closed all open points related to safety, interfaces, and functional requirements);

• Final Design Baseline (FDL);

• Factory acceptance testing plan; and

• The Site Acceptance Testing Plan.

3.12.5 The Contractor shall submit the final Design Safety Case and certification per the SCAP.

3.12.6 The Contractor shall submit a Contractor Self-Certificate (System Certification Report) per the SCAP, certifying that the final design is complete and conforms to the contractual requirements.

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 16 of 35

3.13 Manufacture / Construction Phase

3.13.1 The Contractor shall implement the HSR sub-systems, system elements, and associated interfaces.

3.13.2 The Contractor shall submit:

• Factory Acceptance inspections and/or demonstration; and

• Site Acceptance and other SDLC-phase related tests.

3.13.3 The Contractor shall perform and submit the following tests: First Article Inspection, Production run testing, Factory Acceptance Testing and the Site Acceptance Testing.

3.13.4 The Contractor shall submit the final Construction Safety Case and certification per the

SCAP.

3.13.5 The Contractor shall submit a Contractor Self-Certificate per the SCAP, certifying that the manufactured work and or construction is complete and conforms to the contractual requirements.

3.14 System Integration

3.14.1 The Contractor shall integrate the different systems based on the following tests: Static

Integration Testing and Dynamic Testing.

3.14.2 The Contractor shall submit:

• Test plans, including schedules, and test procedures;

• Test reports of HSR system interfaces; and

• Test reports of Integrated HSR system.

3.14.3 The Contractor shall demonstrate the integration of subsystems and software components progressively into the complete system environment.

3.14.4 The Contractor shall submit the Testing Safety Case and certification per the SCAP.

3.14.5 The Contractor shall submit a Contractor Self-Certificate per the SCAP, certifying that the manufactured work and or construction is complete and conforms to the contractual requirements.

3.15 System Validation

3.15.1 The Contractor shall perform pre-revenue operation testing, demonstrating conformance to the applicable requirements as identified in the system operations testing plan in the digital environment.

3.15.2 The Contractor shall submit the demonstration of conformance.

3.15.3 The Contractor shall submit:

• HSR system operations and procedures;

• Trial running test scenarios, schedules, test procedures, and test results;

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 17 of 35

• Testing and Integration Case.

3.16 System Acceptance Phase

3.16.1 The Contractor shall certify the HSR System is safe, secure, and ready for revenue service to the Authority.

3.16.2 The Contractor shall submit:

• Operational Readiness Safety Case; and

• System certification per the SCAP.

3.17 Cross Cutting Systems Engineering Methods

3.17.1 Interface and Integration Management

3.17.1.1 The Contractor shall submit an Interface and Integration Management Plan that will create an interface and integration program.

3.17.1.2 The Contractor shall execute, monitor, and control the Contractor’s interface and integration program that will result in a fully integrated HSR System that satisfies the system integration, system test, pre-revenue operation, certification, and acceptance requirements.

3.17.1.3 The Contractor shall submit:

• Interface and Integration Management Plan;

• Interface Matrix

• Interface Register;

• Interface Control Documents; and

• Interface Status Reports.

3.17.1.4 The Contractor shall coordinate and integrate the interface and integration management process with the integration and interface requirements described throughout the Project.

3.17.1.5 The Contractor shall perform MBSE services on behalf of the Authority, to integrate requirements allocation, V&V evidence, define operating scenarios, allocate test cases to subsystems/ system elements and ultimately to act as a model-based repository of technical information.

3.17.1.6 The Contractor shall develop its System Architecture, for systems and all subsystems such as Train Control, Comms, SCADA, Traction Power, etc., within the Authority IBM Rhapsody MBSE Environment in accordance with the SysML language rules defined by the Object Management Group (OMG).

3.17.1.7 The Contractor’s System Engineering team shall submit evidence of proficiency and/or experience in undertaking work using IBM Rhapsody, or similar SysML language-based software tool.

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 18 of 35

3.17.1.8 The Contractor shall integrate all contractually applicable rail systems /subsystems /system elements into the wider enterprise architecture by developing and identifying sub system level architecture and interfaces.

3.17.1.9 The Contractor shall submit the test reports verifying ICD conformance during the static integration testing phase.

3.17.1.10 The Contractor shall provide a monthly interface status report.

3.17.2 Testing and Commissioning Management

3.17.2.1 The Contractor shall develop, submit, and control a testing and commissioning plan that creates a testing and commissioning program.

3.17.2.2 The Contractor shall execute and monitor the Contractor’s testing and commissioning program that demonstrates that the complete set of the applicable TCRs, stakeholder requirements, system requirements, allocated requirements, interface requirements, and associated baselines are satisfied by the implemented HSR system, its sub-systems, system elements, and the associated interfaces.

3.17.2.3 The Contractor shall submit:

• Testing and Commissioning (T&C) program;

• T&C Plans [TCP] including test schedules;

• T&C procedures; and

• T&C reports.

3.17.2.4 The Contractor shall prepare the following T&C plans, including:

• Factory Acceptance Testing Plan;

• Site Acceptance Testing;

• SITP;

• Dynamic testing plan;

• TRTP; and

• Operations and maintenance plan.

3.17.2.5 The Contractor shall submit a T&C procedure for each of the specific inspections, analyses, demonstrations, and tests, including:

• Procedure name;

• Purpose and objective;

• System under test;

• Covered requirements, interfaces, and baselines;

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 19 of 35

• Expected results;

• Pass/fail criteria;

• Pre-requisites;

• Triggers;

• Step-by-step description of procedure;

• Post-condition(s);

• Tester(s), user(s), and witness(es); and

• Remarks.

3.17.2.6 The Contractor shall document and submit the testing and commissioning results in testing and commissioning reports.

3.17.2.7 The Contractor shall repeat failed tests once the underlying issues have been resolved.

3.17.2.8 The Contractor shall utilize a failure reporting, analysis, and corrective action system (FRACAS).

3.17.3 System Certification Management

3.17.3.1 The Contractor shall develop, submit, and control a structured system certification process supporting a set of certification cases throughout the SDLC that the HSR System:

• Conforms to Contract requirements as detailed in the Contract and as reasonably inferred therefrom:

• Is safe;

• Is secure; and,

• Is ready for revenue service.

3.17.3.2 The Contractor shall execute and monitor the Contractor’s system certification process.

3.17.3.3 The Contractor shall submit:

• System certification and acceptance plan;

• Certification cases;

• System certification metric; and,

• System certification reports.

3.17.3.4 The Contractor shall coordinate and integrate the system certification process with system certification requirements.

3.17.3.5 The Contractor shall provide the following types of certification cases:

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 20 of 35

• Design Case;

• Construction Case;

• Test Case;

• Operating Case; and,

• System Safety Case.

3.17.3.6 The Contractor shall provide the certification cases supported by objective evidence in form of V&V submittals.

3.17.3.7 The Contractor shall provide a system certification report for each certification case, including:

• Executive Summary;

• System Certification Form;

• System Certification Metric; and,

• Objective Evidence.

3.18 Specialty Engineering Integration

3.18.1 The Contractor shall perform Specialty Engineering activities as described in other

Contract documents.

3.18.2 The Contractor shall include Specialty Engineering Integration:

• Human System Integration;

• Interoperability Analysis;

• Reliability, Availability and Maintainability;

• Safety and Security Management;

• Network and Computer (Cyber) Security;

• Electromagnetic Interference and Compatibility; and,

• Asset Management.

3.18.3 The Contractor shall describe for each of the specialty engineering processes:

• Governing regulations, codes, and standards;

• Application/Tailoring to this Contract;

• Specialty engineering activities [e.g., safety/hazard analyses, threat and vulnerability assessments, RAM analyses, studies]; and

• Resulting mitigations and/or requirements serving as inputs into the SDLC phases.

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 21 of 35

3.18.4 The Contractor shall manage any resulting specialty engineering mitigations and/or requirements as stakeholder requirements transforming them into system requirements following the requirements management process.

3.19 Review Milestones and Associated Deliverables

3.19.1 The Contractor shall submit the following System Engineering submittals for the

Project Phase “Project Initiation Phase” and Milestone “Project Initiation Review (PIR)”:

Technical Contract Submittals Contractual Requirements Baseline (CBL) System Certification and Acceptance Plan Systems Engineering Management Plan Technical Work Breakdown Structure Technical Schedule Configuration Items Organizational Breakdown Structure Technical Risk Mitigations

3.19.2 The Contractor shall submit the following System Engineering submittals for the

Project Phase “Concept” and Milestone “System Definition Review (SDR)”:

Technical Contract Submittals Requirements Management Plan RM Tool Installed RM Tool Database Interface and Integration Management Plan Interface Register Interface Status Reports Testing and Commissioning Plan

3.19.3 The Contractor shall submit the following System Engineering submittals for the Project Phase “System Definition and Operational Phase” and the Milestone “System Requirements Review (SRR)”:

System Definition System Requirements System Requirements Baseline (SBL) Trial Running Testing Plan

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 22 of 35

3.19.4 The Contractor shall submit the following System Engineering submittals for the Project Phases “Risk Analysis and Evaluation Phase/ Specification of System Requirements Phase/ Architecture & Apportionment of System Requirements Phase” and the Milestone “Preliminary Design (PDR)”:

System and Interface Breakdown Structures

Allocated Requirements

Allocated Requirements Baseline (ABL)

System Architecture

Dynamic Testing Plan (Strategy included)

System Integration Testing Plan (SITP)

3.19.5 The Contractor shall submit the following System Engineering submittals for the

Project Phase “Design and Implementation” with the Milestone “Detailed Design Review (FDR)”.

Final Design

Final Design Demonstration

Final Design Baseline (FDL)

Factory Acceptance Testing Plan (Strategy included)

Final Design Safety Case

Final Design Self-Certificate

3.19.6 The Contractor shall submit the following System Engineering submittals for the Project Phase “Construction and Manufacture” with the milestone “Factory Acceptance Testing Review (FAR)”.

Technical Contract Submittals

First Article Inspections & Demonstrations (if applicable)

Production Run Tests

Factory Acceptance Tests

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 23 of 35

Construction Inspections and Tests

Construction Safety Case

Construction Phase Self-Certificate

3.19.7 The Contractor shall submit the following System Engineering submittals for the Project Phase “Construction and Manufacture” with the milestone “Site Acceptance Testing Review (SAR)”.

Technical Contract Submittals Site Installation Tests Site Performance Tests Construction Safety Case Construction Phase Self-Certificate

3.19.8 The Contractor shall submit the following System Engineering submittals for the Project Phase “Integration” with the milestone “System Integration Testing Review (SIR)”.

Technical Contract Submittals Intra HSR sub-system, Intra-Site Testing Intra HSR sub-system, Inter-Site Testing Inter HSR sub-system, Intra-Site Testing Inter HSR sub-system, Inter-Site Testing Test Safety Case

3.19.9 The Contractor shall submit the following System Engineering submittals for the Project Phase “Integration” with the milestone “Dynamic Testing Review (DYR)”.

Technical Contract Submittals Normal HSR system Mode Testing Abnormal/Degraded HSR system Mode Testing Maintenance HSR system Mode Testing Integration Safety Case

3.19.10 The Contractor shall submit the following System Engineering submittals for the Project Phase “System Validation” with the milestone “Trial Running Testing Review (TRR)”.

Technical Contract Submittals O&M Rules and Procedures Safety, Security & Emergency Response Program

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 24 of 35

Asset Management & Maintenance Regime Public Education & Safety Awareness System Validation Safety Case

3.19.11 The Contractor shall submit the following System Engineering submittals for the Project Phase “System Acceptance” with the milestone “System Certification & Acceptance Review”.

Technical Contract Submittals System Certification Operational Safety Case

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 25 of 35

4 INTERFACE MANAGEMENT REQUIREMENTS

4.1 Interface Management

4.1.1 General

4.1.1.1 The Contractor shall submit and implement an Interface Management Plan

(IMP).

4.1.1.2 The Contractor’s IMP shall establish and maintain an Interface Management process that ensures systematic identification, documentation, coordination, and resolution of interfaces throughout the Project Lifecycle.

4.1.1.3 The Contractor’s shall integrate design, construction, and system implementation activities across all contract packages.

4.1.1.4 The Contractor shall coordinate Interface Management activities with the Authority and align them with Program milestones and delivery requirements.

4.1.1.5 The Contractor’s IMP shall minimize integration risks, ensure regulatory compliance, and support system-wide readiness for operation.

4.2 Project Lifecycle Phases

4.2.1 The Contractor’s IMP shall define and document interface activities across the following life-cycle phases:

• Project Initiation Phase

• Concept Phase

• System Definition and Operational Context

• Risk Analysis and Evaluation

• Specification of System Requirements

• Architecture and Apportionment of System Requirements

• Design and Implementation

• Manufacture

• Integration

• System Validation

• System Acceptance

• Operation, Maintenance and Performance Monitoring

• Decommissioning

• Handover

4.2.2 The Contractor shall make all interface outputs for each life-cycle phase traceable in the Interface Register (IFR).

4.2.3 The Contractor shall document and submit interface requirements, design dependencies, and risk mitigation actions at each phase in accordance with the SDLC process.

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 26 of 35

4.3 System Architecture and Interface Definition

4.3.1 The Contractor shall define all system boundaries and identify internal and external interfaces within the System Architecture model.

4.3.2 The Contractor shall use the Authority’s MBSE environment to document and maintain all identified interfaces.

4.3.3 The Contractor’s IFR shall categorize interfaces as Internal or External (Third-Party) in accordance with the System-of-Systems Architecture.

4.3.4 The Contractor’s IFR shall ensure that each interface is associated with:

• Interface Type (mechanical, electrical, data/functional).

• Lead and Match Parties.

• System and Subsystem Allocations.

• Location (station, trackside, trainset, facility, OCC).

• Description and requirements reference.

4.3.5 The Contractor shall develop and submit an Interface Control Document (ICD) for each interface to capture requirements, design descriptions, and verification evidence.

4.3.6 The Contractor shall coordinate all interface definition and validation activities with the Authority prior to ICD approval.

4.4 Interface Verification, Testing and Closure

4.4.1 The Contractor shall perform Verification and Validation (V&V) of each interface in accordance with the approved V&V Plan.

4.4.2 The Contractor shall develop Interface Test Procedures (ITP) and Interface Test Reports (ITR) to verify and document the performance of each interface.

4.4.3 The Contractor shall record and submit all interface test results and ensure that non-conformances are tracked to closure during the Static Integration Test.

4.4.4 The Contractor shall demonstrate interface completion through validated ICDs, approved ITRs, and as-built records.

4.4.5 The Contractor shall formally close each interface after verifying that:

• All requirements are satisfied;

• The ICD is finalized and baselined; and

• All open actions are resolved and approved by the Authority.

4.5 Requirements for Interface Management Tools and Techniques

4.5.1 General

4.5.1.1 The Contractor shall use Authority-approved tools to manage, record, and control interfaces throughout the Project Lifecycle.

4.5.1.2 The Contractor shall maintain consistency between MBSE models and DOORS ICD requirements data.

REQS-0018 – Program System Engineering, Testing, and Commissioning Requirements Page 27 of 35

4.5.2 Interface Register

4.5.2.1 The Contractor shall develop and maintain an IFR documenting all interfaces identified in the System Architecture.

4.5.2.2 The Contractor’s IFR shall include, at a minimum:

• Unique Interface ID;

• Interface Name and Description;

• Interface Category and Type;

• Lead and Match Parties;

• System / Subsystem Allocation;

• Applicable Lifecycle Phase;

• Requirements References (links to RM Tool);

• Design Document References;

• Risk Level and Mitigation Actions;

• Interface Status (Identification, Definition, Resolution, Closed);

• Change History, Key Dates, and Approvals; and

• Dependencies and Comments.

4.5.2.3 The Contractor shall update the IFR throughout the project to reflect current status and ensure traceability to requirements and design outputs.

4.5.3 Interface Coordination and Workshops

4.5.3.1 The Contractor shall establish and maintain structured communication channels for interface coordination meetings and workshops.

4.5.3.2 The Contractor shall organize periodic Interface Coordination Workshops with the Authority and adjacent contractors at key project milestones.

4.5.3.3 The…