HomeRail NewsInteroperability - A necessary complication

Interoperability – A necessary complication

Listen to this article

The concept of interoperability amongst European railways may seem to some to be a bit of a moot point so far as the UK is concerned. There is just one rail link with the rest of the continent, through the Channel Tunnel. The Shuttle and Eurostar trains which operate through it go only to the tunnel terminal near Folkestone or to St Pancras, both of which are dedicated railways built to European standards.

There are no plans to operate any other trains into Europe, and even the proposed link with HS2 has been scrapped.

So why do British railways need to be interoperable at all?

The most important point is one of economics and goes back to the Treaty of Rome. Ensuring that systems are interoperable, and standard, results in economy of scale and reduces cost. Once a system is certified as interoperable it opens the door to new markets, and not just in Europe. Railways have always needed to conform to standards and with an assurance regime to certify that products and systems comply. The EU interoperability regulations provide a common system for verification and approval across all of Europe.

Many people believe that the HS2/HS1 link will get reinstated at some point. And, even inside the UK, signalling and other systems need to be interoperable around the country so using a common system for verification and approval makes sense.

EU Requirements

The Railways (Interoperability) Regulations 2011 (RIR) implement European Community (EC) Directive 2008/57/ EC on the interoperability of the UK rail system. They apply to new, major, upgraded or renewed infrastructure and rolling stock. Applicants have to follow a framework and seek an authorisation from the recently renamed Office of Rail and Road (ORR) to place infrastructure or rolling stock into service.

The Directive sets out the conditions to be met to achieve interoperability within the Community rail system. These conditions are met through the processes of: design, construction, placing in service, upgrading, renewing, and operation and maintenance of parts in the system.

The regulations can seem complex and daunting. It is sometimes more straightforward for rolling stock items to receive verification and approval for interoperability, compared to some types of fixed infrastructure. Control- command and signalling subsystems that interface across different infrastructure managers can face difficulties.

Following its recent acquisition of Lloyd’s Register Rail, Ricardo Rail is now a global rail business which provides independent assurance, technical consulting and engineering services to a range of organisations across the industry – operators, manufacturers, maintenance companies, infrastructure managers, investors and regulators.

Rail Engineer recently met up with Martin Westerman, head of telecoms and systems at Ricardo Rail, to find out more about the issues that can arise with the verification and approvals process, and to throw some light onto the subject.

NoBos, DeBos, NTRs, TSIs and the TF!

The verification procedure is split in two parts: an EC verification procedure by a Notified Body (NoBo) and a verification procedure in the case of national rules by a Designated Body (DeBo). The directives aim to ensure that common Technical Specifications for Interoperability (TSIs) are applied across Europe’s railways and to establish a common European verification and authorisation process.

A NoBo is an independent organisation accredited by government to undertake conformity assessment of a project against relevant TSIs. In the UK, the Department for Transport (DfT) appoints NoBos and assesses them as meeting certain criteria, including competence, independence and integrity as required by the regulations. DeBos are independent third parties appointed by the DfT to assess and verify conformity of projects with National Technical Rules (NTRs). DeBos operate in tandem with NoBos.

TSIs define the technical standards required to satisfy the essential requirements to achieve interoperability. The requirements include safety, reliability and availability, health, environmental protection and technical compatibility. NTRs are those standards which the directive requires each member state to notify to the commission where it contains an identified ‘open point’ or where derogation from a TSI has been notified. In the UK, these are normally railway group standards.

The Rail Safety and Standards Board (RSSB) is responsible, on behalf of the rail industry, for proposing to the DfT any NTRs that should be notified against each of the TSIs for use on the British mainline. The purpose of the notified NTRs (NNTRs) is to provide additional controls to make sure that the requirements specified in the directive are met.

A project must seek an authorisation from the ORR before placing an interoperable subsystem into service. The application to the ORR must be in writing and accompanied by both the technical file (TF) and the verification declaration. There is no mandatory time limit for the ORR to determine an application or authorisation, although projects are advised to build a minimum of four months into their timescales.

The structure and content of a technical file is well defined, although there is some flexibility. However, it must include the following: general and detailed electrical and control-circuit diagrams; description of data-processing and automatic systems; list of interoperability constituents or copies of the EC declarations of conformity; conditions – limits and characteristics of the project subsystem; manuals and instructions relating to the servicing, constant or routine monitoring; adjustment, maintenance and configuration controls; and documentation or records demonstrating compliance with the NNTRs.

The verification process

The first step in the process for any project implementing a system which falls into the scope of interoperability and the regulations is to define the scope of authorisation required and the extent of the TSIs and NNTRs to be applied with the agreement of the DfT. Early discussion and engagement with all stakeholders is important.

A NoBo and DeBo must be engaged to assess compliance against the TSIs and NTRs. Evidence must be presented to the Nobo/DeBo which, after assessment, will produce certificates of compliance for the TF. The project submits the TF and any necessary declarations to the ORR which grants the authorisation for placing into service (APIS).

There are different ways a NoBo/DeBo can carry out their assessments using combinations of assessment modules and these can be selected to minimise project cost and risk.

The NoBo can only issue full certification if the system is compliant with all the relevant TSIs in force at the time. This can cause problems with assessing systems which interface with those managed by different infrastructure managers or with projects which may have been installed to earlier versions of the TSIs. In such circumstances, derogations may be required which can only be granted by the DfT.

Similarly, the ORR can only provide the APIS if the project is fully compliant with current TSIs or derogations are in place.

P1070137 [online]

Experience gained with GSM-R

Through Lloyd’s Register, Ricardo Rail has gained many years’ experience as both DeBo and NoBo throughout Europe on a variety of complex projects. One of these is the national GSM-R project on which it was first engaged in 2004. Options on how the assessment could be carried out were considered and agreement was obtained from the DfT to assess against the 2006 TSI.

Verification of conformity with TSIs is carried out using several defined modules. To complete module SB, a NoBo examines the technical design of a subsystem and verifies and provides clear evidence that the design of the subsystem meets the requirements of the relevant TSI(s).

Module SF is based on product verification whereby the applicant fulfils the obligations of manufacture and declaration of verification. The applicant must ensure and declare that the subsystem is in conformity with the type described in the EC- type examination certificate, and satisfies the requirements of the relevant TSI(s).

Verification using module SD is based on a quality management system of the production process. The applicant ensures and declares that the subsystem is in conformity with the type described in the EC-type examination certificate, and satisfies the requirements of the relevant TSI(s).

For the GSM-R project, it was decided to use module SB supplemented with modules SD and SF. The initial completion area, known as the Strathclyde pilot, was assessed using module SB and SF.

GSM-R national deployment commenced after the NoBo assessed the project’s quality management system (QMS) and issued an interim module SD certification. This allowed the project to continue deployment of the GSM-R system under their approved QMS with periodic surveillance audits carried out by the NoBo. Once the national rollout was completed a full SD certificate was issued.

The TF was compiled in two parts. Volume 1 was compiled by the NoBo, representing a snapshot at the time of the assessment. Volume 2 was compiled by Network Rail recording details of the rollout under the approved QMS plus minor changes.

The transition from SB plus SF to SB and SD has been a useful method of assessment, allowing the quality processes to develop and mature as part of the project deployment programme and roll out.

Difficulties and issues have arisen with having to revisit and extend the certification against later TSIs for different project entities and infrastructure managers. The TF has also had to be restructured where more than one party has been involved for contractual reasons.

The DfT derogation letter was issued to the GSM-R project responsible for the national roll out. However it was not transferable to other parties (within Network Rail or otherwise) leading to the risk of other projects not receiving authorisation. The directive is very strict in that authorisation can only be against the current TSIs.

In a scenario of, say, additional GSM-R radio sites being added to a GSM-R core operated by a different infrastructure manager, the project installing the additional GSM-R sites has to be assessed against the latest TSIs. However, the core they are connected to may have been assessed against earlier TSIs. This can lead to problems unless it is managed carefully and all parties co-operate, make sure their TF is up to date, and share information openly.

Lessons for ETCS and other interoperable projects

Unlike GSM-R, there will not be the same concept of a national core network which each subsequent implementation has relied upon. GSM-R infrastructure has used modules SB, plus either SF or SD. ETCS may be more difficult with possible use of further modules (particularly quality-based ones such as SH1 under which EC verification is based on a full quality management system plus design examination). There may be further issues with interoperable constituents, such as balises and radio block centres, which are certified in their own right.

There may be added complication at interface points where the NoBo has to consider technical compatibility and safe integration. This may be more challenging to demonstrate where the other side of the interface has been certified using a different assessment approach.

The choice of appropriate assessment modules, such as SB, SF, SD and SH1, and / or the establishment of a robust quality management system is an early consideration for projects. Different modules have implications on time and resources which may impact on the risk to the project.

Key messages

The first important point with complex systems requiring verification, and in particular for systems which may operate across multiple infrastructure managers, is the importance of planning the initial and long term compliance. TSIs will evolve and change, and projects need to recognise this, and plan to accommodate change as best they can throughout a project lifecycle.

Adopting later versions of TSI and mandatory specifications may be driven by interfacing systems connected to different infrastructure managers, and there may be multiple authorising applicants and technical file owners. Projects must recognise that there are strict criteria governing derogation against TSIs in force at the time of seeking authorisation.

Selecting, choosing and agreeing with all parties the appropriate assessment module(s) is vital to achieve a balance between project risk and efficiency. A robust maintenance and management process for the TF must be established at an early stage, recognising that compliance evidence gathered will be important to any NoBo needing the evidence to support a verification submission.

The maintenance and management process for the TF must be transferred seamlessly into the day-to-day operation and maintenance of the system. A ‘minor change’ reconfiguration to the system may become very important when another verification submission is required. Failure to gather evidence that compliance has been maintained may result in difficulties and delays when any update to the NoBo certificate is required. The process must recognise that there may well be multiple owners of the TF.

Early planning is vital, not just for initial certification and authorisation, but a strategy must be in place to accommodate how maintenance and upgrades will be carried out. Projects must engage early with the DfT and ORR to agree an achievable scope, together with a pragmatic approach to authorisation. When seeking authorisation from the DfT, projects need to be very clear about the scope of any derogation being sought and the party and organisation it applies to.

A robust, but flexible, contracting strategy with suppliers will be required. The procurement contract will need to accommodate changes to the TSIs during the course of the project, together with providing a framework and base for any subsequent upgrades, additions or connections to other subsystems.

So interoperability is a complex area but, like all successful projects, early planning and using the experience and lessons learned from previous projects is the key to success.

Paul Darlington CEng FIET FIRSE
Paul Darlington CEng FIET FIRSEhttp://therailengineer.com

Signalling and telecommunications, cyber security, level crossings

Paul Darlington joined British Rail as a trainee telecoms technician in September 1975. He became an instructor in telecommunications and moved to the telecoms project office in Birmingham, where he was involved in designing customer information systems and radio schemes. By the time of privatisation, he was a project engineer with BR Telecommunications Ltd, responsible for the implementation of telecommunication schemes included Merseyrail IECC resignalling.

With the inception of Railtrack, Paul moved to Manchester as the telecoms engineer for the North West. He was, for a time, the engineering manager responsible for coordinating all the multi-functional engineering disciplines in the North West Zone.

His next role was head of telecommunications for Network Rail in London, where the foundations for Network Rail Telecoms and the IP network now known as FTNx were put in place. He then moved back to Manchester as the signalling route asset manager for LNW North and led the control period 5 signalling renewals planning. He also continued as chair of the safety review panel for the national GSM-R programme.

After a 37-year career in the rail industry, Paul retired in October 2012 and, as well as writing for Rail Engineer, is the managing editor of IRSE News.


Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.