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
ERTMS CHANGE CONTROL MANAGEMENT
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 3 OF 31
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.3.1. Who 12 4.2.3.2. Roles and responsibilities 12
4.2.4. Core team 14
4.2.4.1. Who 14 4.2.4.2. Roles and responsibilities 14
4.2.5. Technical working groups 14
4.2.5.1. Who 14 4.2.5.2. Roles and responsibilities 14
4.2.6. Quality manager 15
4.2.6.1. Who 15 4.2.6.2. Roles and responsibilities 15
4.2.7. Standardisation Bodies 15
4.2.7.1. Who 15 4.2.7.2. Roles and responsibilities 15
ERA ERTMS UNIT
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 4 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 5 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 6 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 7 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 8 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 9 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 10 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 11 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 12 OF 31
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. ROLES AND RESPONSIBILITIES
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 13 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 14 OF 31
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. ROLES AND RESPONSIBILITIES
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. ROLES AND RESPONSIBILITIES
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 15 OF 31
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. ROLES AND RESPONSIBILITIES
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. ROLES AND RESPONSIBILITIES
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 16 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 17 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 18 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 19 OF 31
(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’.
See Figure 3 path 30-40.
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 20 OF 31
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’.
See Figure 3 path 60-70.
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’.
See Figure 3 path 60-61.
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 21 OF 31
(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'.
See Figure 3 path 90-100.
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.
See Figure 3 path 90-120.
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'.
See Figure 3 path 110-120.
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 22 OF 31
See Figure 3 path 130-140.
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’.
See Figure 3 path 130-61.
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’.
See Figure 3 path 130-31.
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’.
See Figure 3 path 150-160.
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’.
See Figure 3 path 150-61.
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’.
See Figure 3 path 62-70.
ERA ERTMS UNIT
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 23 OF 31
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
See step 80 of CR workflow WG
Supporting docs for justification/discussion for solution
See step 80 of CR workflow WG
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 24 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 25 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 26 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 27 OF 31
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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 28 OF 31
# 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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 29 OF 31
# 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
ERTMS CHANGE CONTROL MANAGEMENT
ERA_ERTMS_0001
Version 2.0 PAGE 30 OF 31
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