ertms ccm process - european union agency for railways€¦ · era ertms unit ertms change control...

EUROPEAN RAILWAY AGENCY

File : ERA_ERTMS_0001_V20.Doc PAGE 1 OF 31

ERTMS UNIT

ERTMS CHANGE CONTROL MANAGEMENT

Reference: ERA_ERTMS_0001 Document type:

Version : 2.0

Date : 03/06/10

Edited by Quality review Approved by

Name A. HOUGARDY A. CHIAPPINI P. GUIDO

Position ERTMS Unit Project Officers ERTMS Unit Quality Manager ERTMS Acting Head of Unit

Date

&

Signat.

ERA ERTMS UNIT


ERA_ERTMS_0001

Version 2.0 PAGE 2 OF 31

AMENDMENT RECORD

Version Date Section number Modification/description Author(s)

0.4 05/09/05 - First Draft PG

0.7 25/11/05 All Incorporation in ERA template, addition of new chapters, incorporation of informal comments received after ERA CCM CG meeting #02

AH, EL

0.8 30/11/05 - Editorial changes, according ERA internal review

AH, EL

0.9 19/12/05 - According to review comment sheet “ERA_ERTMS_C0022v1_Review Comments on ERTMS CCM.doc”

AH, EL

1.0 09/02/06 - Final version amended and approved during the CG meeting held on the 9

th

February

AH, EL

1.1 02/05/06 3.2.2.2.1, 4.2.1, 4.2.2.9.3

Modifications according action 06.05 of ERA CCM CG

AH

1.2 11/05/06 3.2.2.2.1, 4.2.2.9.3 Wording improvement agreed during ERA CCM CG meeting #07

AH

1.3 11/05/07 3.2.3.2.9, 3.2.3.2.10

3.2.3.2.14

Modification according to SVM WG proposal

New clause for creation of ad-hoc workshops helping CG decisions (e.g. “triage”)

AH

1.4 24/05/07 3.2.3.9 a), 4.2.2.7

Table 4.3.1

Incorporation of references to document “Methodology of Economic Evaluation for ERTMS Change Control Management”

Missing field added in CR content

AH

1.5 02/02/10 All Introduction of new definitions, clarifications on the maintenance of baselines and of specific good practice rules for the ETCS CR’s

AH

1.6 19/02/10 All According to ERA internal review AH

1.7 23/04/10 All According to review comments from CER, EIM, UNIFE

AH

1.8 07/05/10 All According to review performed during ERA CCM CG #45

AH

2.0 03/06/10 1.2.4, 3.2.1, 3.2.3, 3.2.4, figure 1,

4.2.2.2.3, 4.2.3.2.11, annex

A.1

Release version agreed during ERA CCM CG meeting #46

AH

ERA ERTMS UNIT


ERA_ERTMS_0001


TABLE OF CONTENTS

Amendment record 2

Table of contents 3

Table of figures 4

Table of tables 4

1. INTRODUCTION 5

1.1. Foreword 5

1.2. Scope & field of application 5

1.3. Document description 5

2. REFERENCES, TERMS AND ABBREVIATIONS 6

2.1. Reference documents 6

2.2. Terms & abbreviations 6

3. DEFINITIONS 8

3.1. Baseline 8

3.2. BASELINE release 8

3.3. Change Control Management 9

4. ORGANISATION OF THE CCM 10

4.1. Overall structure 10

4.2. Involved parties 11

4.2.1. CR submitter 11

4.2.1.1. Who 11

4.2.2. Board 11

4.2.2.1. Who 11 4.2.2.2. Roles and responsibilities 12

4.2.3. Control group 12


4.2.4. Core team 14


4.2.5. Technical working groups 14


4.2.6. Quality manager 15


4.2.7. Standardisation Bodies 15


ERA ERTMS UNIT


ERA_ERTMS_0001


5. CHANGE REQUEST PROCESS 16

5.1. Introduction 16

5.2. Change Request workflow 17

5.2.1. Flowchart 17

5.2.2. Description of main steps 18

5.2.2.1. STEP 10 - Submission of the Cr by a recognised organisation 18 5.2.2.2. STEP 30 - Is the CR correctly filled? 19 5.2.2.3. STEPS 50 & 51 - Is the CR related to an error or an enhancement? 19 5.2.2.4. STEP 60 - Assessment of the priority level 20 5.2.2.5. STEPS 75 & 80 – Resolution of the CR 20 5.2.2.6. STEP 90 – is an economic evaluation needed for the CR? 21 5.2.2.7. STEP 110 – Economic evaluation of the CR 21 5.2.2.8. STEP 130 – Decision by the Control Group for the CR 21 5.2.2.9. STEP 150 – Decision by the board for the CR 22 5.2.2.10. STEP 62 – Unfreezing of the CR 22

5.2.3. Overlapping of CRs 23

5.3. Change Request content 23

5.4. Change Request state transitions 24

6. MANAGEMENT OF DOCUMENTATION CHANGES 25

ANNEXES 26

A.1 Maintenance of baselines 26

A.1.1 Foreword 26

A.1.2 Workflow 26

A.2 Specific rules for the management of ETCS CR’s 30

A.2.1 Preamble 30

A.2.2 Management of CR’s involving several WG’s 30

A.2.3 Management of CR’s in relation to subdocs 30

TABLE OF FIGURES

Figure 1: Example of evolution of ETCS baselines and baseline releases ........................................ 9 Figure 2 : Organisational structure of the CCM. .............................................................................. 10 Figure 3 : CR workflow.................................................................................................................... 17

TABLE OF TABLES

Table 1 : Reference documents ........................................................................................................ 6 Table 2 : Terms ................................................................................................................................ 6 Table 3 : Abbreviations ..................................................................................................................... 6 Table 4 : CR content. ...................................................................................................................... 23

ERA ERTMS UNIT


ERA_ERTMS_0001


1. INTRODUCTION

1.1. FOREWORD

1.1.1. ERTMS is an “enabling” technology to allow exploitation of new business opportunities, operational improvements and efficiency streamlining. Ideally, evolution capability should be “built-in” in the system, and it must not become a constraint or a barrier.

1.1.2. On the other hand, promotion of international traffic requires end to end seamless service. Interoperability is core to fulfil this objective. The need to ensure interoperability, combined with the long renewal cycles in railway signalling, establish the obligation to protect the investments in ERTMS systems.

1.1.3. To reach those objectives the European Railway Agency, in its role as system authority for ERTMS, must establish the transparent process to manage the system changes, with the contribution of the sector’s representatives.

1.1.4. Finally, it will be the sole responsibility of the Agency to hand over to the Commission a proposal for an amended version of the specifications, for appropriate embodiment in the European legislation.

1.2. SCOPE & FIELD OF APPLICATION

1.2.1. This document defines the organisation and the process of the Change Control Management for the reference specifications and documents listed in the Annex A of the officially published TSI CCS, excluding those not related to ERTMS/ETCS or ERTMS/GSM-R. In addition, the Change Control Management of the Annex A of the TSI OPE (ERTMS/ETCS and ERTMS/GSM-R operating rules) is also covered by this document.

1.2.2. Change Requests directly raised against the TSI CCS text itself are outside the scope of the ERA ERTMS CCM process; the need to update clauses in different chapters of the TSI CCS text may however arise as a consequence of a Change Request against its annex A.

1.2.3. The Change Control Management must ensure that all the issues not yet finalised will be covered by appropriate provisions and specifications: hence, also the content of the Annex G (“Open Points”) of the current TSI CCS can be affected as a consequence of a Change Request against the TSI CCS annex A.

1.2.4. Note: so far this Change Control Management procedure has not been applied for ERTMS/GSM-R. When used, the return of experience could trigger the need for GSM-R specific provisions/rules, which will be added to this document.

1.3. DOCUMENT DESCRIPTION

1.3.1. Chapter 3 gives definitions for the basic terms baseline, baseline release and Change Control Management (CCM).

1.3.2. Chapter 4 defines the general organisation of the ERTMS CCM and the roles and responsibilities of the different involved parties.

1.3.3. Chapter 5 details the Change Request process, focusing on the lifecycle of Change Requests from their submission to the presentation to the EC.

1.3.4. Chapter 6 introduces the relationship between the CR process itself and the management of documentation changes.

ERA ERTMS UNIT


ERA_ERTMS_0001


2. REFERENCES, TERMS AND ABBREVIATIONS

2.1. REFERENCE DOCUMENTS

Table 1 : Reference documents

Ref. N° Document

Reference

Title Last

Issue

[1] 881/2004

1335/2008

Regulation of the European Parliament and of the Council 29th

April 2004 establishing a European Railway Agency amended by the Regulation of the European Parliament and of the Council 16

th

December 2008

-

[2] SUBSET-023 Glossary of Terms and Abbreviations 2.0.0

[3] SUBSET-104 ETCS system version management 3.0.0

[4] ERA_EE_000521 Methodology of Economic Evaluation for ERTMS Change Control Management

4.0

[5] 04/881-DV01EN02 List of representative bodies from the railway sector referred to in article 3 paragraph 2 of Regulation (EC) n° 881/2004

-

[6] ERA_ERTMS_029802

Management of ERTMS unit documents 1.0

2.2. TERMS & ABBREVIATIONS

2.2.1. For general terms, definitions and abbreviations refer to document [2]. New terms and abbreviations used in this document are specified here.

Table 2 : Terms

Term Definition

Agency The European Railway Agency (ERA)

Core Team The ERA ERTMS Core Team

Board The ERA CCM Board (currently fulfilled by the ERA CCS WP)

First draft release, consolidation release

Intermediate baseline releases prior to the first legal release, not to be published in the Official Journal

Legal release Baseline release, which is published in the Official Journal

Maintenance release Baseline release consisting only of errors corrections, which is published in the Official Journal after the first legal release.

Table 3 : Abbreviations

Abbreviation Definition

CCM Change Control Management

CCS Control Command and Signalling

CG Control Group

CR Change Request

ERA ERTMS UNIT


ERA_ERTMS_0001


Table 3 : Abbreviations

Abbreviation Definition

DB Data Base

EC European Commission

EE Economic Evaluation

IM Infrastructure Manager

NSA National Safety Authorities

NoBo Notified body

OPE Operation

RISC Railway Interoperability and Safety Committee

RU Railway Undertaking

TSI Technical Specification for Interoperability

WG Working Group

ERA ERTMS UNIT


ERA_ERTMS_0001


3. DEFINITIONS

3.1. BASELINE

3.1.1. A baseline is defined by a stable kernel in terms of system functionality, performance and other non-functional characteristics.

3.1.2. Conversely, the definition of a new baseline necessarily implies that significant changes (enhancements) are brought to the above mentioned kernel: an enhancement may consist in adding a new function, keeping the functionality of the previous baseline unchanged, or may consist in changing some functionality, performance or non-functional characteristics of the previous baseline.

3.1.3. Important note: the ETCS and GSM-R parts of ERTMS can be regarded as two separate systems in terms of baseline. Of course some changes to one of them may impact the other one, but this does not mean that the evolutions of the ETCS and GSM-R systems have to be synchronised: it is only necessary, when processing the changes to one of them, to identify and log their possible impacts to the other one.

3.1.4. If these changes impact the ETCS part of ERTMS, the ETCS system version number (X.Y) is always incremented when defining a new baseline: in case of X increment only the train to track backward compatibility is ensured, while in case of Y increment, both the train to track upward and backward compatibilities are ensured (see document [3] for details).

3.1.5. A baseline is not defined by a specific release of the TSI CCS/OPE annex A.

3.2. BASELINE RELEASE

3.2.1. A baseline release is defined by a specific version of each of the documents that are listed in the TSI CCS annex A or included in the TSI OPE annex A and that are relevant for the concerned part of ERTMS (ETCS or GSM-R).

3.2.2. During the whole lifetime of the system, several releases of the same baseline can be issued:

(a) the first draft release, including the first subset of annex A documents (e.g. the FRS and the SRS) in which an agreed set of changes to the stable kernel of the previous baseline is specified

(b) optionally, one or more consolidation releases, consisting of intermediate releases in order to progressively build the full and coherent set of annex A documents attached to the baseline

(c) the first legal release, which is enforced in the Official Journal once the consolidation phase is completed.

(d) further on, one or more maintenance releases published in the Official Journal. They consist only of errors fixed after the publication of the first legal release.

3.2.3. Note: the first draft and consolidation releases are not published in the Official Journal and can be deemed necessary according to the number and the complexity of the changes. They are made available through the Agency website as work in progress for information only.

3.2.4. The natural consequence of the above is that it cannot be excluded to issue a maintenance release of a baseline, after one or more subsequent new baselines have been created (see example in Figure 1) and enforced in the Official Journal. In all circumstances, the Agency will use its best endeavours to ensure that the corrections in different baselines are fully consistent in order to maintain

ERA ERTMS UNIT


ERA_ERTMS_0001


interoperability. For details regarding the maintenance of baselines, refer to annex A.1.

3.3. CHANGE CONTROL MANAGEMENT

3.3.1. The Change Control Management consists of the management of activities, which allow moving from one baseline release to another one. The Change Requests (CR’s) offer a transparent, formal and ordered processing of the changes leading to new releases (see chapter 5 for details).

3.3.2. The CCM process defined hereafter is baseline independent, i.e. it is valid for any step made in the lifetime of a given baseline, starting from the last legal release of the previous baseline to the first draft release, the consolidation release(s), the first legal release and the further maintenance release(s) (see example in Figure 1).

1st

Dr.

Rel.

Cons.

Rel.

1st

Leg.

Rel.

Maint.

Rel.

Maint.

Rel.

System lifetime

CR’s CR’s CR’s CR’s

1st

Dr.

Rel.

CR’s Cons.

Rel.

1st

Leg.

Rel. CR’s CR’s

1st

Dr.

Rel.

CR’s 1

stLeg.

Rel. CR’s

Maint.

Rel. CR’s

Maint.

Rel. CR’s

Baseline n+2

Baseline n+1

ETCS System version

Baseline n

X.Y

X+1.0

X+1.1

*

*

**

***

Figure 1: Example of evolution of ETCS baselines and baseline releases

*: arrows indicate that updated documents in the maintenance release of a baseline are incorporated in the newer baseline **: synchronised releases in the frame of the maintenance of different baselines (see annex A.1) ***: there is only one set of documents listed in the Official Journal. If necessary, maintenance releases of older baselines will be implemented using a specific document (e.g. like the SUBSET-108)

ERA ERTMS UNIT


ERA_ERTMS_0001


4. ORGANISATION OF THE CCM

4.1. OVERALL STRUCTURE

4.1.1. The organisational structure is shown in Figure 2, which outlines the main information flows and the interactions of the parties involved in the CCM; their tasks and interfaces are described in the subsequent sections.

CR SUBMITTER

Core Team

monthly report

steering

package

BOARD (incl. NSA, NoBos)

File/update

dispatch

Standardisation Bodies

coordinate with

official position

Quality Manager

Control Group (incl. EE)

CR tool

WG n WG n+1

submission

Figure 2 : Organisational structure of the CCM.

ERA ERTMS UNIT


ERA_ERTMS_0001


4.2. INVOLVED PARTIES

4.2.1. CR SUBMITTER

4.2.1.1. WHO

4.2.1.1.1. Each of the representative bodies listed by the RISC in its meeting of the 07/10/2009 (see document [5]) can submit a Change Request to ERTMS:

(a) Union of European Railway Industries (UNIFE)

(b) Community of European Railways and Infrastructure Companies (CER)

(c) European Infrastructure Managers (EIM)

(d) International Association in Public Transport (UITP)

(e) International Union of Private Wagons (UIP)

(f) International Union of Combined Road-Rail Transport Companies (UIRR)

(g) European Rail Freight Association (ERFA)

(h) European Transport Federation (ETF)

(i) Autonomen Lokomotivführer-Gewerkschaften Europas (ALE)

(j) European Passengers Train and Traction Operating Lessors' Association (EPTTOLA)

4.2.1.1.2. The following parties can also submit a CR:

(a) The Network of the National Safety Authorities

(b) Each Member State

(c) The European Commission

4.2.1.1.3. In addition, CR can be internally originated by the Agency e.g. as a consequence of the process of drafting or updating other TSI’s or safety recommendations, or in general in the scope of its activities.

4.2.1.1.4. The GSM-R suppliers are not included in the official list of representative bodies. However, they can raise CR either via the ERA WG in which they participate, or via agreements with one of the other representative bodies.

4.2.1.1.5. The Notified Bodies, via their coordination structure, could also submit CR’s: rather than forcing them to use the ERA CCM tool, it is preferable that those requests are discussed in the frame of the coordination between Control Group and NB-Rail, and then, after the proposed clarification, they can be entered as “internally originated” CR’s.

4.2.1.1.6. The representative bodies, the Network of NSA’s, the Member States, the European Commission and the Agency are the recognised organisations, which are allowed to submit CR’s.

4.2.2. BOARD

4.2.2.1. WHO

4.2.2.1.1. The Board is composed of persons mandated by the representative bodies, of representatives of the Network of National Safety Authorities and of NB-Rail, and of staff from the Agency. The role and responsibilities of the Board are currently fulfilled by the ERA CCS Working Party.

ERA ERTMS UNIT


ERA_ERTMS_0001


4.2.2.2. ROLES AND RESPONSIBILITIES

4.2.2.2.1. The main responsibility of the Board is to endorse the proposed dossier for system changes and express the position of their organisations. Two types of endorsements can be requested to the Board:

(a) endorse a CR package to assess whether to proceed with the required additional work to define the detailed specifications, or complete required additional studies;

(b) endorse a CR package embodied in a complete proposal to assess whether to endorse its submission to the Commission;

4.2.2.2.2. While this endorsement is not bound to be by unanimity, since the Agency retains its full responsibility and independence to finally present proposals to the Commission, the objective of the process is to reach a common position regarding all aspects of the proposal. If it is not possible to reach a unanimous decision, a justification for the rejection by one or more organisations represented in the Board should be added to the proposal to the Commission.

4.2.2.2.3. The Board meetings will be called either when the proposals for the first legal release of a new baseline of the system are ready, complete with the Cost Benefit Analysis and recommended time-planning, or in the context of the maintenance release of a baseline.

4.2.2.2.4. The Board will receive the proposed dossier in advance, and the members can comment and ask clarifications. The Board collectively can recommend additional actions and propose to re-examine their results with the updated dossier at a later time.

4.2.2.2.5. It is the specific task of the Board to evaluate the cost/compensations provisions, linked to the release and deployment policy, and if necessary to prepare an argumentation for funding.

4.2.2.2.6. When the Agency presents a proposal for changes to the Commission, it will include the positions expressed by the Board and their recommendations.

4.2.2.2.7. The Board also endorses the planning and policy for any future baseline of the system.

4.2.3. CONTROL GROUP

4.2.3.1. WHO

4.2.3.1.1. The Control Group is composed of experts invited by the Agency, of persons mandated by the representative bodies and of Agency staff. The Agency will ensure adequate and balanced participation (IM and RU, UNIFE/UNISIG and GSM-R suppliers).


4.2.3.2.1. The Control Group must ensure the steering of the ERTMS activities, identifying the most effective actions to deal with the outstanding issues in coherence with the overall system planning, resources and priorities.

4.2.3.2.2. The resolution of blocking points among WG’s is also part of the Control Group task, whenever raised by the Core Team.

4.2.3.2.3. The Control Group members will proactively define, conveying the consolidated information and requests from their respective organisation, the planning and policy

ERA ERTMS UNIT


ERA_ERTMS_0001


for any future legal release of the TSI CCS/OPE annex A specifications. This includes the proper synchronisation of the timing of the legal releases for different baselines

4.2.3.2.4. The planning must also include proposals for allocating costs/compensations: this important issue could in fact influence the entire CR process since their submission, and the general principles must be clarified in advance.

4.2.3.2.5. The Control Group will define the necessary intermediate steps (first draft and consolidation releases), in order to build progressively the consistent set of TSI CCS/OPE annex A specifications, which will lead to the first legal release of a new baseline..

4.2.3.2.6. The Control Group will endorse the need to create specific technical WG’s, and define their remit and the required expertise profile. The Control Group will hear regular and specific reports from the Core Team, and will offer guidance and provide for the necessary organisational coordination.

4.2.3.2.7. The Control Group will define in advance an overall work plan estimate for the activities up to 12 months in the future, to help the Agency with its resource planning.

4.2.3.2.8. Depending on the specific issue, the development of the detailed solution for a CR could entail a significant amount of time/resources. In this case, the Control Group will seek the endorsement of the Board before committing to the additional activities.

4.2.3.2.9. The Control Group will define the aggregation of different CRs in packages, proposed for specific baseline release and or deadlines.

4.2.3.2.10. In case of first legal release of a new baseline, the Control Group will ensure that the CR package is integrated with its impact assessment:

(a) benefit analysis , feasibility/cost of development, feasibility/cost of deployment (see second and third steps in document [4] for details)

(b) ETCS System Version Management: compatibility with previous baseline (X or Y increment), modification of the envelope of X versions if any, migration parameters (see document [3] for details)

(c) proposed time-plan and/or migration strategy for the adoption

(d) if necessary, the proposal for the financing scheme to ensure the development/deployment

4.2.3.2.11. In the context of the maintenance of a baseline (see annex A.1 for further details), the Control Group will also have the possibility to define “Error” CR packages only, which will lead to a maintenance release published in the Official Journal.

4.2.3.2.12. The Control Group will submit a CR package to the Board, for endorsement. If it is not possible to reach a unanimous decision, a justification for the rejection by one or more representative bodies represented in the Control Group should be added to the proposal to the Board.

4.2.3.2.13. If necessary, the Control Group will take active part in the coordination of specific ERTMS issues between the Agency and the Joint Programming Committee Rail of CEN/Cenelec/ETSI.

4.2.3.2.14. In principle, the Control Group will have scheduled monthly meetings.

ERA ERTMS UNIT


ERA_ERTMS_0001


4.2.3.2.15. The Control Group may also appoint short lifespan workshops or taskforces, in the view to help its decision making in the frame of the CR process (see section 5.2. Change Request workflow, steps 60, 62, 90, 130) or in the frame of the maintenance of baselines (see annex A.1).

4.2.4. CORE TEAM

4.2.4.1. WHO

4.2.4.1.1. It is composed by Agency staff members only, providing key system competence.


4.2.4.2.1. It receives, filters and classifies the CR’s received from the submitters via the ERA CCM tool. To be accepted into the CCM process, the CR’s must be formally correct; they are then provisionally assigned to one of the existing technical WG when possible, and properly filed in the Agency DB.

4.2.4.2.2. The Core Team will report at each meeting of the Control Group about the current state of the CR’s, their progress, the workload of the different technical WG’s.

4.2.4.2.3. If it becomes obvious that neither the Core Team itself nor an existing working group has the competence to solve the problem exposed in the CR, the Core Team can request the creation of additional WG or ad-hoc workshops for this specific CR.

4.2.4.2.4. The Core Team will lead the process to identify the experts needed for specific WG, and retain the entire responsibility for their nomination.

4.2.4.2.5. The task of the Core Team is also to ensure the necessary technical coordination among the technical WG’s.

4.2.4.2.6. The Core Team enables the Agency to fulfil its role as ERTMS System Authority.

4.2.5. TECHNICAL WORKING GROUPS

4.2.5.1. WHO

4.2.5.1.1. Each technical Working Group is composed by external experts and is chaired or followed up by a representative of the Agency staff.

4.2.5.1.2. Following the decision to create a WG, the representative bodies, which are likely to provide the profile of the required expertise, are contacted by the Core Team.

4.2.5.1.3. After collection of proposed names from the representative bodies, the Agency will then select and invite the relevant experts.

4.2.5.1.4. Independent experts may also be invited by the Agency to join Working Groups, if deemed necessary.


4.2.5.2.1. Together with its creation, the remit for a WG is defined by the Agency, after consultation of the Control Group, identifying when necessary the specific CR’s assigned. Additional CR’s can be afterwards assigned by the Control Group or the Core Team.

4.2.5.2.2. The remit for each WG is described in detail in a dedicated document, issued by the Agency.

ERA ERTMS UNIT


ERA_ERTMS_0001


4.2.6. QUALITY MANAGER

4.2.6.1. WHO

4.2.6.1.1. The Quality Manager is an Agency staff member.


4.2.6.2.1. The Quality Manager is in charge of ensuring the quality of the overall CCM process, including the specific software tools and database.

4.2.6.2.2. He also ensures that the specifications are delivered with proper configuration control and quality assurance. For that sake, he will coordinate with counterparts in the involved entities.

4.2.6.2.3. The Quality Manager will ensure that the CCM process is implemented and periodically reviewed with ever increasing effectiveness.

4.2.7. STANDARDISATION BODIES

4.2.7.1. WHO

4.2.7.1.1. The Standardisation Bodies, mentioned in Figure 2, are the CEN, CENELEC, and ETSI.


4.2.7.2.1. The Standardisation Bodies do not have any direct role or responsibility in the ERA ERTMS CCM process.

4.2.7.2.2. They only coordinate with the Control Group, allowing this latter to ensure that:

(a) new standards are considered properly in the TSI CCS/OPE Annex A;

(b) if new standards are needed the requests are properly initiated and the result of the work verified.

ERA ERTMS UNIT


ERA_ERTMS_0001


5. CHANGE REQUEST PROCESS

5.1. INTRODUCTION

5.1.1. The following CR workflow describes the whole lifecycle of a Change Request, from its submission to its final acceptance by the Board.

5.1.2. However, further steps after a package of CR’s has been forwarded to the Commission are not covered by this CR process description.

5.1.3. It must be emphasised that this CR workflow is applicable to individual CR’s and neither to CR packages nor to the documents referenced in the TSI CCS/OPE annex A.

5.1.4. The management of the editorial work for updating the TSI CCS/OPE annex A documents is considered as not being part of the CR process itself, but only a consequence of it; in other terms, the documentation update must be driven by the CR process, and not the contrary.

ERA ERTMS UNIT


ERA_ERTMS_0001


5.2. CHANGE REQUEST WORKFLOW

5.2.1. FLOWCHART

< 20 >

The submitted CR

is stored

in the ERA/CCM

database

< 10 >

Submission of the CR

by a recognised

organisation

< 30 >

Is the CR

correctly filled ?No

< 50 >

Is the CR

related to

an error ?

< 51 >

Is the CR

related to an

enhancement ?

No No

Yes

< 90 >

Is an EE needed

for the CR ?

< 130 >

Decision by the CG for

the CR

Yes

< 150 >

Decision by the Board

for the CR

< 140 >

The CR is

incorporated

in a package

Yes

: ERA ERTMS Core Team

: Representative Organisation

: Working Group(s)

: ERA EE Group

: Control Group

: Board

< 40 >

The CR is

recorded as valid

< 100 >

The CR is waiting

for an EE

< 120 >

The CR analysis is

completed

< 62 >

Unfreezing of the CR

< 61 >

The CR is

postponed

< 110 >

Carrying out the EE for

the CR

< 31 >

The CR is

rejected

No

< 80 >

The solution is worked

out by the WG(s)

< 70 >

The CR is

assigned

No

Yes

< 60 >

Assessment of the

priority level

< 160 >

The CR is

presented to the EC

< 75 >

Solution

proposal

complete ?

Yes

Figure 3 : CR workflow

ERA ERTMS UNIT


ERA_ERTMS_0001


5.2.2. DESCRIPTION OF MAIN STEPS

5.2.2.1. STEP 10 - SUBMISSION OF THE CR BY A RECOGNISED

ORGANISATION

5.2.2.1.1. A Change Request shall only be submitted by one of the recognised organisations listed in section 4.2.1.1.

5.2.2.1.2. The information relevant for the submission of the CR is listed here below (where an asterisk is put, it shall be mandatory to fill the related field):

(a) Headline:* which gives a textual unequivocal identification and indicates the

general topic of the CR, not exceeding a few words,

(b) Reference baseline release(s) for ETCS and/or for GSM-R:* to which the

CR refers,

(c) Documents and/or References:* which indicates directly which documents

and/or references are concerned by the CR,

(d) Error/Enhancement:* the rationale of the CR shall be given, so does the CR

relate to either the need for debugging the specified baseline or to the need for functional or performances improvement (see section 5.2.2.3. for criterion used by ERA Core team to check this field),

(e) Project1 name and starting time:*

2 to which the CR is related shall be

indicated, followed by the related date (month and year) to which corresponds the first implementation test before the revenue service,

(f) Problem/need description:* which gives a detailed overview about the

problem/need. The reason for the CR shall be clearly indicated and the description should preferably not exceed one page. In any case, any mixing of the problem with the solution description must be avoided,

(g) Supporting documents for problem/need description: lists all files which

are attached to the CR, in relation with the CR problem/need,

(h) Solution proposal by submitter: which indicates the solution preferred by

the submitter,

(i) Supporting documents for solution proposal: lists all files which are

attached to the CR, in relation with the proposed CR solution,

(j) Preliminary assessment of the benefits: which provides, in case of an

enhancement, as a first step the order of magnitude of the benefits resulting from the expected improvement of performances, safety, reliability and maintainability,

(k) Supporting documents for preliminary assessment of the benefits: lists

all files which are attached to the CR, in relation with the preliminary assessment of the benefits,

(l) Submitting Recognised Organisation:*: one of them listed in section 4.2.1.1.

of this document,

(m) Endorsed by: name(s) of the other recognised organisation(s) which also

support(s) the CR,

1 Project must be understood in the large sense, i.e. any planned on-board or trackside installation of

ERTMS/ETCS assemblies or components. 2 Mandatory only in case of enhancement

ERA ERTMS UNIT


ERA_ERTMS_0001


(n) Contact person Name and Email address:* of the expert representing the

mentioned organisation, who will be the contact person in case of further needed exchange between originator and ERA CCM Core Team,

(o) Submitter Reference Number: free text field to allow each organisation to

track the CR for their own internal follow up

5.2.2.1.3. Important note: filling the field preliminary assessment of benefits is strongly recommended in case of enhancement; indeed, it is expected that the submitter is highly motivated to provide such information at this early stage, in order:

(a) to facilitate a further individual economic evaluation for this CR, which is likely to be requested afterwards by the Control Group (refer to step 90),

(b) to provide the justification for the CR and hence to give to the CR the priority it deserves, so that the desired attention will be paid by all the ERTMS CCM involved parties, when managing this CR.

5.2.2.1.4. To provide the information relevant for the submission, the submitter shall log in to the ERA CCM tool and use a predefined CR submission form; the free text fields and the attached documents shall be written in English.

5.2.2.1.5. The CR submission information is then stored in the ERA CCM database with the

attached files and the CR state is put to ‘submitted’ with the current date.

See Figure 3 path 10-20

5.2.2.2. STEP 30 - IS THE CR CORRECTLY FILLED?

5.2.2.2.1. As a general rule, within five working days after its submission, the Core Team performs the pre-analysis of the CR. This pre-analysis consists in checking:

(a) that the mandatory fields are duly filled, and

(b) that the information provided in free text fields and attached documents, if any, is usable for further analysis.

5.2.2.2.2. When a CR can not be accepted due to missing or unusable information, the CR

state is changed to ‘rejected’. The Core Team shall provide the reason(s) of such rejection. During a period of two months, the submitter will have the possibility to provide the required information in order to make the CR valid. If the required information has not been provided after this two months period, the CR shall be considered as definitively rejected. This event will be notified to the submitter.

See Figure 3 path 30-31.

5.2.2.2.3. When all needed information has been positively checked, the CR state changes to

‘valid’.


5.2.2.3. STEPS 50 & 51 - IS THE CR RELATED TO AN ERROR OR AN

ENHANCEMENT?

5.2.2.3.1. The Core Team shall verify the correctness of the assessment made by the submitter with regards to the field Error/Enhancement. This verification of the CR rationale will be done by cross-checking the information given in the submission form and all relevant information that can be found in TSI CCS/OPE annex A list of related documents.

ERA ERTMS UNIT


ERA_ERTMS_0001


5.2.2.3.2. A CR shall be classified as an Error when it relates to any inconsistency, gap found in a document or in the documentation set.

5.2.2.3.3. Conversely a CR which is not classified as an Error shall be considered as an Enhancement, normally leading to new or modified requirement(s) in the FRS.

5.2.2.3.4. Exception: it is also foreseen that the CR is neither to be classified as an Error nor as an Enhancement, because the submitter might have misjudged the reality of the problem or overlooked one piece of information included in TSI CCS/OPE annex A

documents. Should be the case, the CR state is changed to ‘rejected', and this rejection shall be motivated by the ERA Core Team, with all the necessary references justifying this decision.

See Figure 3 path 50-51-31

5.2.2.3.5. If the CR is re-classified (from Error to Enhancement or vice-versa), the reason shall be provided by the ERA Core Team.

5.2.2.4. STEP 60 - ASSESSMENT OF THE PRIORITY LEVEL

5.2.2.4.1. In order to organize the work of the Core Team and the dedicated WG's in the most efficient way, and especially to manage logically a situation when there will be so many logged CR's that it will not be possible to treat all of them in the same time, the Core Team will set priorities for the CR’s.

5.2.2.4.2. Since it may depend on many non technical factors, it is not possible to predefine an exhaustive list of criteria for the prioritization of CR’s. However the CR’s are stamped with a severity qualifier in order to help, together with e.g. the classification error/enhancement and the reference baseline release, the determination of their priority:

(a) safety related

(b) interoperability and non safety related

(c) performances impact, non interoperability and non safety related,

(d) Others.

5.2.2.4.3. The Control Group is responsible to validate the priority list for the CR, paying specific attention to those which affect current implementations. If the CR is considered as relevant for the next expected baseline or is related to the

maintenance of an existing baseline the CR state changes to ‘Assigned’.


5.2.2.4.4. If the Control Group estimates, on the basis of the information provided by the submitter, especially the starting time of the project, that this CR is relevant but not for the next expected baseline, the CR is postponed. The CR state changes to

‘Postponed’.


5.2.2.5. STEPS 75 & 80 – RESOLUTION OF THE CR

5.2.2.5.1. The Core Team, in its role of technical coordinator, shall continuously assess the content of each CR and shall ensure that a complete solution is derived in a timely manner. In that respect, the Core Team can at any time:

ERA ERTMS UNIT


ERA_ERTMS_0001


(a) Allocate the CR to existing Working Group(s), which shall work out a solution for the CR. In case several WG’s are involved in the search for a solution, the necessary coordination task will be performed by the Agency (see annex A.2 for details).

(b) Convene and lead ad-hoc workshops or taskforces.

(c) Validate a proposed solution, avoiding further resource allocation outside the Agency.

5.2.2.5.2. The solution shall consist in a list of unambiguously identified changes to one or more document(s) of the TSI CCS/OPE annex A; together with these proposed amendments, it is possible to add a separate justification for this solution.

5.2.2.5.3. The Agency, acting as the System Authority, shall ensure a fair balance between the cleanliness and the pragmatism of the chosen solution (i.e. avoiding on one hand quick and dirty solutions or on the other hand too complex and nice to have solutions). For that purpose, it is recognised that for the CR’s impacting ERTMS/ETCS, UNIFE/UNISIG brings the main competence to estimate the impacts on their products and provides the soundest economic technical proposal for their products.

5.2.2.5.4. If during the phase of searching for a solution by the WG, it appears that the experts give rises to different solutions, the submitter or representatives of his organization can be invited to participate to the group in question, in order to bring additional information which will help the definition of the most adequate solution.

5.2.2.5.5. A special attention shall also be paid by both the WG and the Core Team, to the type of impact on the ERTMS/ETCS or GSM-R system version. This information will be essential for the Control Group to decide how to assemble packages of CR’s.

5.2.2.6. STEP 90 – IS AN ECONOMIC EVALUATION NEEDED FOR THE CR?

5.2.2.6.1. Once a complete solution has been worked out, the ERA CCM Control Group shall decide whether an economic evaluation is needed for this individual CR.

5.2.2.6.2. If it is decided to perform an individual economic evaluation for the CR, its state

changes to ‘Waiting for economic evaluation'.


5.2.2.6.3. If it is decided that an individual cost/benefit analysis is not worth for the CR, its state

changes to ‘Analysis completed'. Note: this does not mean that the costs induced by the CR, in case of enhancement, will not be evaluated, but only when the CR is integrated in a CR package, at a further stage.


5.2.2.7. STEP 110 – ECONOMIC EVALUATION OF THE CR

5.2.2.7.1. The economic evaluation of an individual CR is detailed in document [4].

5.2.2.7.2. Once this evaluation is completed, the CR state changes to ‘Analysis completed'.


5.2.2.8. STEP 130 – DECISION BY THE CONTROL GROUP FOR THE CR

5.2.2.8.1. In principle, the Control Group shall never take a positive decision on a single CR; but shall rather decide to incorporate a CR in a package (refer to section 4.2.3.2.9.);

if decided so, the CR state changes to ‘packaged’.

ERA ERTMS UNIT


ERA_ERTMS_0001



5.2.2.8.2. When assembling CR package(s), the Control Group shall have the possibility to postpone the incorporation of the CR in a package, for any technical or economic

reason; should be the case, the CR state changes to ‘postponed’.


5.2.2.8.3. The Control Group shall also have the possibility to reject a CR, either because of the Cost/Benefit analysis or because the WG in charge of the technical solution proposes a reason to reject it, which could not be detected at an earlier stage by the

ERA Core Team. The CR state then changes to ‘rejected’.


5.2.2.9. STEP 150 – DECISION BY THE BOARD FOR THE CR

5.2.2.9.1. After a CR has been incorporated in a package, its final acceptance in the context of the creation of a legal release (the first one or a maintenance one), which means its submission to the Commission, shall be endorsed by the Board; if decided so, the

CR state changes to ‘presented to the EC’.


5.2.2.9.2. At this stage, it is still possible that the Board decides not to present the CR to the Commission, either because the CR is to be removed from the agreed package, or because the package itself is postponed as a whole; in both cases, the CR state

changes to ‘postponed’.


5.2.2.10. STEP 62 – UNFREEZING OF THE CR

5.2.2.10.1. Through its monthly meetings, the Control Group will always have the possibility to unfreeze the CR, regardless the reason why the CR was postponed.

5.2.2.10.2. The unfrozen CR shall systematically go through the normal process from the assignment to a WG onwards; this is also relevant if the CR was already solved in the past, as the context might have significantly changed since its postponement (e.g. the reference baseline has changed and the solution is no longer valid, …). The

CR state then changes to ‘assigned’.


ERA ERTMS UNIT


ERA_ERTMS_0001


5.2.3. OVERLAPPING OF CRS

5.2.3.1. At any stage of the CR workflow, it may appear that a CR is linked to one or more other CR, either in terms of problem/need or in terms of the solution found.

5.2.3.2. If it is made sure that a particular CR can be fully covered by another CR dealing with

the same subject, the CR state changes to ‘superseded’; the reference to the superseding CR shall be indicated.

5.2.3.3. Conversely, the CR which supersedes one or more other CRs shall refer to the list of superseded CRs.

5.3. CHANGE REQUEST CONTENT

5.3.1. The table here below gives all the information that shall be stored in the ERA CCM database, for each Change Request.

Table 4 : CR content.

Field Description Who controls it

Identification Number Gives the unique reference number which all the involved parties work with.

ERA CCM tool

State Materialises the CR progress during its lifetime within the ERA CR process, see boxes 20,31,40,61,70,100,120,140,160,170 in Figure 3 : CR workflow and section 4.2.3

See CR workflow

Submission information See Step 10 of CR workflow Submitter

Date of submission Date of capture of the submission form ERA CCM tool

Reason for Error/Enhancement re-classification

See steps 50, 51 of CR workflow Core Team

List of assigned WG(s) See step 60 of CR workflow CG

Severity See step 60 of CR workflow CG

Solution agreed by WG(s) See step 80 of CR workflow WG

Supporting docs for agreed solution

See step 80 of CR workflow WG

Justification/Discussion for solution


Supporting docs for justification/discussion for solution


Economic Evaluation output See step 110 of CR workflow ERA EE Group

Supporting docs for Economic Evaluation

See step 110 of CR workflow ERA EE Group

Target baseline(s) See step 130 of CR workflow CG

Reason for rejection See steps 30, 50, 51, 130 of CR workflow Core Team/CG

Reason for postponement See steps 60, 130, 150 of CR workflow CG/Board

Superseding CR Reference number of the CR that supersedes the CR, when the CR state is "superseded"

Core Team

ERA ERTMS UNIT


ERA_ERTMS_0001


Field Description Who controls it

List of superseded CR(s) Reference number(s) of the CR(s) that are superseded by the CR

Core Team

Modification history For all changes brought to the CR, gives the author, the date and the impacted field

ERA CCM tool

5.4. CHANGE REQUEST STATE TRANSITIONS

5.4.1. Each state transition shall be notified to the submitter, through the email address provided in the CR submission form.

ERA ERTMS UNIT


ERA_ERTMS_0001


6. MANAGEMENT OF DOCUMENTATION CHANGES

6.1. As already stated, the management of the editorial work for updating the TSI CCS/OPE annex A documents is considered as not being part of the CR process itself, but only as a consequence of it; in other terms, any documentation update must be driven by the CR process, not the contrary.

6.2. Of course it is very likely that the update of documents resulting from an agreed CR package might be undertaken in parallel; however, the Agency shall ensure, especially through its quality manager, that these tasks are put under its quality control and verifications.

6.3. In particular, the Agency shall ensure that a full traceability between the document changes and the Change Request is provided, prior the sending to the EC of the full dossier, including the set of updated documents together with the package of Change Requests justifying the changes.

6.4. The detailed process for the management of the documentation production is described in a separate document.

ERA ERTMS UNIT


ERA_ERTMS_0001


ANNEXES

A.1 MAINTENANCE OF BASELINES

A.1.1 FOREWORD

The ERTMS specifications are the basis for a growing number of projects, and allow the daily operations of hundred of trains over thousands km of lines in Europe.

The need to ensure interoperability, combined with the long renewal cycles in railway signalling, establish the obligation to protect the investments in ERTMS systems.

The return of experience and feedback from the millions km accumulated in system use undoubtedly generate the need for additional clarifications and also uncover possible errors, at any time in the lifetime of the ERTMS specifications, e.g. when several baselines have been created and successively enforced.

This annex details how such possible errors are managed in relation to the ERTMS specifications and the CR process described in this document.

A.1.2 WORKFLOW

The workflow hereafter describes all the steps from the time an interoperability issue has been raised to the final decision of the Board regarding the way the solution is going to be adopted.

The baseline B-n is the baseline to which refers the ERTMS implementation where the interoperability issue has been detected. It can be a baseline that was created before one or more new baselines have been created (n>0). Moreover it is assumed

that the ERTMS implementation referring to this baseline B-n complies with the last legal release of this baseline.

The baseline B is the baseline currently in force at the time the interoperability issue has been detected.

The baseline B+1 is the baseline under construction, i.e. its first legal release has not yet been enforced. This workflow assumes that there is always such a baseline at any time.

The flowchart hereafter is designed for the maintenance of the baseline B-n.

However, it must be noted that the baselines (B-n) + 1 to the baseline B inclusive might also need to be maintained as a result of the interoperability issue revealed in

the implementation referred to the baseline B-n. The flowchart can therefore be

applied several times, substituting B-n with (B-n) + 1, …., B respectively.

ERA ERTMS UNIT


ERA_ERTMS_0001


A8

Baseline B-n maintenance release:

Udpate annex A concerned

document(s)

A6

Update application guide of baseline B-

n

Interoperability issue detected in implementation referred to baseline B-n

last release (first legal one or maintenance one if any)

E1

D1

Mitigation

measure

applicable

A4

Raise and solve new CR

for

baseline B-n

No

Yes

D2

Solution included in

baseline B legal

release currently in

force

D7

Solution included in

baseline B reusable

for baseline B-n

No

A3

Raise and solve new CR

for

next baseline B+1

Yes

D8

Solution for baseline

B+1 reusable for

baseline B-n

No

D3

Issue still relevant in

baseline B legal

release currently in

force

No

Yes

Yes

D4

CR for baseline

B+1 already

existing

No

Yes

Yes

A1

Investigate and propose

mitigation measures

No

· baseline B-n: reference baseline of the

interoperability issue

· baseline B: baseline currently in force

· baseline B+1: baseline under creation or

consolidation

ERA ERTMS UNIT


ERA_ERTMS_0001


# Description Who

E1 The triggering event is an interoperability issue detected in the frame of an existing ERTMS implementation referred to the last legal release (first legal or maintenance) of any baseline equal to or older than the one currently in force.

It is assumed that prior to this event, it has been checked that the interoperability issue is due to a gap/inconsistency in the set of

specifications forming the concerned baseline B-n last legal release (i.e. the concerned on-board and trackside assemblies are compliant with the

last legal release of the baseline B-n) and that the existing recommendations included in the application guide of the concerned

baseline B-n have been followed.

Core Team, CER,EIM,UNIFE

A1 The possible mitigation measure(s) (e.g. restriction of use of some function, engineering guideline, …) shall be investigated, in the light of the specific trackside implementation where the reported issue comes from, but also in the perspective of other existing or future implementations.

This investigation can be assigned by the Control Group to an ad-hoc temporary task force, and could require the availability of experts from the sector, with expertise and knowledge that could be of a larger/different scope than pure ERTMS expertise

Core Team, CER,EIM,UNIFE

D1 Can the mitigation measure(s) be relevant to any existing or future

implementation referred to the baseline B-n last release? If yes, the

process shall go to A6, otherwise it shall go to D2

Note: in other terms a mitigation measure, which can only be relevant to a

single project, could not be published in the baseline B-n application guide

Control Group

D2 Was the issue solved in the context of the CCM or in other terms does the

baseline B legal release currently in force include a solution which addresses the issue?

If yes, the process shall go to D7, otherwise it shall go to D3

Control Group

D3 Is the issue still relevant in the context of the baseline B legal release currently in force?

If the issue is no longer relevant (i.e. due to functional changes or other

gap/inconsistency fixes that occurred when building the baseline B legal

release), the process shall be go to A4, otherwise it shall go to D4

Control Group

D4 Is there an existing CR intended for baseline B+1, which covers the issue?

If yes, the process shall go to D8, otherwise it shall go to A3

Control Group

A3 A new CR shall be raised and solved, in the frame of the creation or the

consolidation of the baseline B+1. When the CR is set to “Analysis

completed”, the process shall go to D8

Core team, WGs

D7 Can the solution included in the baseline B be reused as such for the

baseline B-n?

If yes, the process shall go to A8, otherwise it shall go to A4

Note: the solution included in the baseline B could not be reusable e.g. because it is not technically backward compatible or because it refers to

clause(s) not existing in the baseline B-n

Control Group

ERA ERTMS UNIT


ERA_ERTMS_0001


# Description Who

D8 Can the CR solution designed for the baseline B+1 be reused as such for

the baseline B-n?

If yes, the process shall go to A8, otherwise it shall go to A4

Note: the solution designed for the baseline B+1 could not be reusable e.g. because it is not technically backward compatible or because it refers

to clause(s) not existing in the baseline B-n

Control Group

A4 A new CR shall be raised and solved, in the context of the baseline B-n. However, the operation of trains compliant with a newer baseline, on lines where the correction would be applied, shall be taken into account when deriving the solution (i.e. impact on trains compliant with newer baseline should be avoided to maintain interoperability).

When the CR is set to “Analysis completed”, the process shall go to A8

Control Group, Core team, WGs

A6 The application guide of the baseline B-n is updated, in order to include the solution addressing the interoperability issue.

Core team, WGs

A8 The solution addressing the interoperability issue is incorporated in the concerned document(s) of the TSI CCS/OPE annex A, in order to create

a new maintenance release of the baseline B-n.

Since there can only be one release of the TSI CCS/OPE annex A enforced in the Official Journal at a time, the concerned document can be:

if n=0, any of the existing document(s) in the TSI CCS/OPE annex A where the error(s) must be fixed

if n>0, an ad-hoc document in the TSI CCS/OPE annex A, intended for the maintenance of older baselines.

Core team, WGs

ERA ERTMS UNIT


ERA_ERTMS_0001


A.2 SPECIFIC RULES FOR THE MANAGEMENT OF ETCS CR’S

A.2.1 PREAMBLE

This annex includes good practice rules, in order to better regulate the flow of CR’s assigned to the different technical working groups involved in the resolution of the CR’s. By applying these rules, two objectives should be met: keep the overall number of open CR’s at a reasonable level at any time and avoid that certain CR’s remain opened for a too long time.

Some rules regarding the CR’s in relation to the so-called subdocs (i.e. the CCS TSI annex A documents related to ETCS, other than the ETCS System Requirements Specification), are also included in this annex.

A.2.2 MANAGEMENT OF CR’S INVOLVING SEVERAL WG’S

Rule # 1: The assignment of the CR’s, for which the contribution of more than one WG is needed, shall be proposed and decided by the Core Team, in cooperation with the involved WG leaders.

Rule # 2: Starting from the assignment to a given WG, the contribution of this WG should be made within 3 months after the assignment date (in principle this corresponds to minimum two consecutive monthly WG meetings). If the reply is not posted in the ERA CCM tool in due time, the Core Team can temporarily take over the responsibility of the CR.

Rule # 3: The number and the nature of exchanges between WG shall be monitored by the Core Team. In all cases, the resolution of a CR should not exceed one year. Within this limit, the Core Team can also take over the responsibility of a CR and inform the Control Group beforehand, whenever it is detected that the exchange of views between WG cannot lead to a solution agreed.

A.2.3 MANAGEMENT OF CR’S IN RELATION TO SUBDOCS

Rule #4: A cover CR shall be created, in which the intermediate versions (if any) and the final version of the subdoc are attached.

Rule #5: Any CR which deals with a specific problem to be solved in one and only one single subdoc can contain an indicative summary of the solution and a link to the cover CR of this subdoc, through the state “Superseded”

Rule #6: Any CR which deals with a problem to be solved in a subdoc but not only in this subdoc (e.g. in the SRS or in another subdoc) can be put in state “Analysis Completed” even if its solution only contains an indicative summary of the solution for the subdoc. The field “Agreed Solution” shall however include the reference to the subdoc (e.g. SUBSET-0xx Vx.y.z).

Note: While it is always possible to specify in detail the modifications to a subdoc whenever it is necessary to do so, rules #5 & #6 shall also apply in such case, i.e. to supersede the CR itself or to indicate the reference to the subdoc in the field “Agreed Solution”.

Rule #7: A cover CR shall be put in state “Analysis Completed” only after it has been checked that the proposed version of the subdoc takes into account:

the problems and indicative summaries of solution or the detailed solutions described in the superseded CR’s

ERA ERTMS UNIT


ERA_ERTMS_0001


the problems and indicative summaries of solution or the detailed solutions described in the CR’s where the concerned subdoc is referenced in the field “Agreed Solution”.