maintenance framework - digital railwaydigitalrailway.co.uk/wp-content/uploads/2019/04/...issue/ver:...

Reference 153821-NWR-REP-EMN-000001

Issue/Ver: 1.0

Date: 10/09/2018

Digital Railway – Maintenance Framework

Prepared by:

Camilla Rock Senior Engineer, DECCS

CJR-200918-0001 Date: 20/09/2018

Reviewed by: David Nicholson System Integration and Interface Manager

DJN-200918-0021 Date: 20/09/2018

Accepted by:

Rubina Greenwood Head of System Requirements and Integration

RNG-291018-0020 Date: 05/11/2018

of 19


Issue/Ver: 1.0

Date: 10/09/2018

Electronic file reference: https://digitalrailway.ipss-hdms.co.uk/DigitalRail/Search/QuickLink.aspx?n=153821-NWR-REP-EMN-000001&t=3&d=Main%5cDIGITAL-RAIL-Production&sc=Global&state=LatestRevision&i=view

Disclaimer

Group Digital Railway has used its best endeavours to ensure that the content, layout and text of this document are accurate, complete and suitable for its stated purpose. It makes no warranties, expressed or implied, that compliance with the contents of this document will be sufficient to ensure safe systems of work or operation. Group Digital Railway will not be liable to pay compensation in respect of the content or subsequent use of this document for any purpose other than its stated purpose or for any purpose other than that for which it was prepared, except where it can be shown to have acted in bad faith or there has been wilful default.

© Copyright 2018 Group Digital Railway.

This document is the property of Group Digital Railway. It shall not be reproduced in whole or in part, nor disclosed to a third party, without the written permission of Group Digital Railway.

Document owner: Louie Lawana, Senior Maintenance Interface Manager

Version History

Issue Date Comments

0.1 - Minor version for any change in content

0.2 31/05/18 Peer feedback included. Document structure changed.

0.3 06/06/18 CR update-comments from steering group

0.4 07/06/18 TF update-comments from steering group

0.5 15/06/18 CR updated and submitted to DR/ DR’s elected onboard team for comments

0.6 19/06/18 CR updated to comments from DR/DR’s elected onboard team including confirmation of meeting Con ops requirements (NWR-PLN-MPM-000005) and customer requirements (NWR-SPE-ESE-0000003).

0.7 22/06/18 LL updated section 1. CR updated to comments from stakeholders.

0.8 03/07/18 CR & LL Updates to first draft review

0.9 13/07/2018 RD Updates

0.10 16/08/2018 Updated to comments after review.

1.0 10/09/2018 Final version, issued for signature

Exclusions

These are items currently missing from this version of the document that should be included in a later publication.

https://digitalrailway.ipss-hdms.co.uk/DigitalRail/Search/QuickLink.aspx?n=153821-NWR-REP-EMN-000001&t=3&d=Main%5cDIGITAL-RAIL-Production&sc=Global&state=LatestRevision&i=view



of 19


Issue/Ver: 1.0

Date: 10/09/2018

None

Assumptions

These are items upon which the validity of this document relies, and which will be delivered by others. Non-delivery of these items will necessitate a change to this document.

1. A key assumption within the scope of this document is the baseline SoS architecture is being deployed.

Dependencies

These are items upon which the validity of this document depends. Any changes to the referenced document may require further changes to this document.

None

of 19


Issue/Ver: 1.0

Date: 10/09/2018

Content

ABBREVIATIONS ................................................................................................................................... 5

GLOSSARY OF TERMS ......................................................................................................................... 6

REFERENCES ........................................................................................................................................ 7

1. INTRODUCTION ........................................................................................................................... 8

Purpose of this document ......................................................................................................... 8

Scope of this document ............................................................................................................ 8

Maintenance of this Handbook ................................................................................................. 9

2. INTRODUCTION TO THE DIGITAL RAILWAY PROGRAMME ................................................. 10

Background ............................................................................................................................. 10

Digital Railway Programme .................................................................................................... 10

Systems Maintenance ............................................................................................................ 11

3. SYSTEMS MAINTENANCE FRAMEWORK ............................................................................... 12

Introduction ............................................................................................................................. 12

Product ................................................................................................................................... 12

People ..................................................................................................................................... 14

Procurement ........................................................................................................................... 16

Process ................................................................................................................................... 17

of 19


Issue/Ver: 1.0

Date: 10/09/2018

Abbreviations are explained in full on first use within this document. A comprehensive list of abbreviations and definitions is contained in the Glossary [RD6].

Abbreviation Description

AM Asset Management

AMEM Asset Management Excellence Model

CMMS Computerised Maintenance Management System

GUI Graphic User Interface

RAG Red Amber Green

of 19


Issue/Ver: 1.0

Date: 10/09/2018

Terms Definitions

COM Ports Communication Ports located on IT-based hardware

RACI The RACI is a tool that is used to link the key activities to produce the

maintenance strategy and the stakeholders and the role they play in its

production. RACI defines who is Responsible, Accountable, Consulted

and Informed.

Route Route with ‘R’ encompasses RU, IM and Supply Chain

Skills Fade Loss of confidence and competence of staff responsible for maintaining

DR systems.

soak testing soak testing is the method used to reduce commissioning time by

validating the system behaviour.

System Data Information that can be used to ascertain the entire status of the system.

of 19


Issue/Ver: 1.0

Date: 10/09/2018

Dependent References

An update to one of these references requires an update to this document

Note: References should be used in sequential format throughout this document.

RD1 Digital Railway – System of Systems Realignment Strategy, 153819-NWR-STR-SSD-000001, v1.2, December 2017

RD2 Digital Railway – System of Systems (SoS) System Definition, 153821-NWR-REP-ESE-000002, Ver4.0, April 2018

RD3 Digital Railway – System Management Plan, 153819-NWR-PLN-MPM-000002, Ver 6, June 2018

RD4 Network Rail, Asset Management Policy, 2018

RD5 Network Rail, Asset Management System Handbook, December 2017 v2.0

RD6 Digital Railway – Glossary of Terms and Abbreviations, 153819-NWR-SPE-ESE-000001, v1.1, 31st Aug 2018

RD7 Digital Railway - Operational Readiness Plan, 158875-NWR-PLN-OPP-000001

Informative References

These references have no material bearing on the content of this document.

Note: References should be used in sequential format throughout this document.

RI1 Competence Management, NR/L1/CTM/001, v1, 31/12/2007

RI2 Signalling Asset Policy, NR/L1/SIG/50021, v3, 01/04/2019

RI3 Asset Data Policy, NR/L1/ADG/001, v1, 03/12/2016

RI4 Information Security Policy, NR/L1/INF/02232, v2, 07/06/2016

RI5 Arrangements for maintenance of new and changed assets, NR/L2/MTC/088, 05/09/2009

RI6 ISO/TR 18529 2000 Ergonomics — Ergonomics of human system interaction — Human-centred lifecycle process descriptions (to be superseded by ISO 9241-220: Processes for enabling, executing and assessing human-centred design within organisations)

RI7 ISO 9241-210 - Ergonomics of human-system interaction Part 210: Human-centred design for interactive systems.

of 19


Issue/Ver: 1.0

Date: 10/09/2018

1. Introduction

This document is a child of the Operational Readiness Plan [RD7] and will provide guidance to Routes in understanding the effect of a Digital Railway SoS implementation (see Figure 1 below). This will in turn influence the Route Asset Management Plans (RAMPs) for the deployment of the DR SoS on GB’s Railway network.

Figure 1 Maintenance Strategy adapted from [RD5]

This framework further supports deployment projects in understanding maintenance considerations during the early development stages of an integrated system.

The guidance in this document will also incorporate lessons learned from previous projects deploying similar digital technologies.

This Maintenance Framework contributes to the achievement of outcomes A & D (see 2.2 - Digital Railway Programme). The scope covers Infrastructure Manager (IM) and Railway Undertaking (RU) maintenance. Figure 1, above, illustrates the strategic positioning of this document and its relationship within Industry and the Generic SoS Operations and Maintenance (O&M) Requirements. Routes, in collaboration with the supply chain and customers, can develop their own maintenance strategies to enable the transition from Deployment Project to Business as Usual.

The scope addresses four main areas:

• People

of 19


Issue/Ver: 1.0

Date: 10/09/2018

• Product

• Procurement

• Process

These are covered in more detail in Section 3 - Systems Maintenance Framework.

The baseline SoS architecture being deployed [RD2] is the most complex of the DR technology configurations and provides the greatest Maintenance challenge and, therefore, this document can also be adapted for any less complex integration programmes.

This document does not cover the maintenance specifics of any specific application (i.e. how to maintain any specific sub-system) and the intention is not to describe here all possible maintenance scenarios that may occur on the GB rail network.

This Maintenance Framework is owned by the DRP Senior Maintenance Interface Manager. Updates may be instigated, as necessary, when directed by the DRP Head of System Requirements and Integration, or when changes are made to the wider Digital Railway Programme’s scope.

of 19


Issue/Ver: 1.0

Date: 10/09/2018

2. Introduction to the Digital Railway Programme

The benefits of the Digital Railway are expressed as:

• More trains

• Better connections

• Improved reliability

These benefits are to be realised by the Digital Railway Programme for GB Rail through the application of modern train control technology supported by appropriate business change activities. The vision, purpose and objectives have been summarised as:

• Increased capacity

• Safer, more secure, and environmentally sustainable railway

• Improved train performance (reliability and availability)

• Improved whole-life cost and sustainable commercial model

• Wider socio-economic benefits (e.g. skills, productivity, housing, exports)

This is an Industry-wide programme involving Network Rail (as Infrastructure Manager); Rolling Stock Companies (RoSCos), Train and Freight Operating Companies (as Railway Undertakings), the Rail Safety and Standards Board (RSSB), operators of On-Track Machines, and the supply chain. It will also engage with the Office of Rail and Road (ORR) and the Department for Transport (DfT), as necessary, to secure the required improvements to safety, customer provision, funding, and approvals.

The revised definition of the system has been captured in an updated System Definition Document

[RD2] and the Systems Engineering delivery approach is described in the DRP System Management

Plan [RD3].

The Digital Railway Programme has several principal objectives; these are:

A. Creation of generic Customer Requirements for the deployment of Digital Railway (DR) Systems (using the European Train Control System (ETCS), Connected Driver Advisory System (C-DAS), and a Traffic Management System (TMS)) and for interfaces with other systems and enablers.

B. Preparation of Business Cases that provided input to Route strategic business plans for deployment projects using specific applications of DR Systems.

C. Assisting deployment projects in deploying specific DR Systems as a result of the Business Plan work undertaken in [RD1], above.

D. Production of guidance notes, rules, processes, and templates to help deployment projects. Where remitted to do so, DR will provide support to deployment projects in determining the deltas between Digital Railway System of Systems (DR SoS) items and a particular Route deployment.

Both ‘System’ and ‘System of Systems’ (see Glossary) comprise of more than just the systems themselves: they also include the people, processes and data required to enable their operation.

of 19


Issue/Ver: 1.0

Date: 10/09/2018

Maintenance, for the purpose of this document, is a broad term used to encapsulate the way in which the industry manages its assets. With the assets playing a central role in the delivery of its goods and services, ‘Systems Maintenance’ in the Rail Industry is a vital part of operations. As such, maintenance accounts for a significant proportion of the Industry’s management time, focus, and resources.

Because this Maintenance Framework will impact a wide range of railway entities during Digital

Railway deployment on the Routes, the term ‘Route’ (with a capital ‘R’) is used in the context of

this document to encompass the IM, RUs and supply chain partners involved in that particular

deployment of Digital Rail.

Lessons learnt from previous technology introduction programmes suggest that delaying the review of maintenance considerations until later in the programme life cycle increases risk and costs exponentially. Therefore, to maximise the benefits of the DRP SoS, Routes should take a holistic approach to maintenance and plan for it early in the programme (project) life cycle.

There are a number of benefits directly linked to Route Scorecards, as well as the Asset Management Policy [RD4], that a robustly designed maintenance strategy will offer, some of which are listed below:

• Enhanced safety

• Enhanced security

• Increased reliability

• Higher quality of service provision

• Lower operating costs

• Improved asset information, leading to better informed asset decision-making

• Extended useful life span of assets

• Assets hold value at disposal

• Provision of direction, communication and prioritisation for the industry

The DRP RAM plan will provide support for the outlining of the overall approach to Reliability, Availability

and Maintainability in the context of Safety and it can be used by Routes to inform their design activities

and development of their local RAMS targets. RAMS targets should aim at achieving an optimal low life

cycle cost by allocating RAM requirements between designed-in Reliability & Maintainability

Requirements and requirements for operational and maintenance capability and response times. The

Routes will also need to recognise and act upon issues raised in System Security, DRACAS, Intelligent

Infrastructure, and Asset Management to ensure that their deployment of the Digital Railway SoS aligns

with these other wider initiatives.

At the time of writing, this Maintenance Framework had started the exploration of wider Network Rail

initiatives and some of these are included in this document. While this document is intended as an early

aid to the thinking of Routes deploying the DR SoS, it should be noted that there is ongoing engagement

with the wider DR community, including Railway Undertakings and the supply chain, through a series

of workshops to ensure that the final requirement suite delivered at the end of November recognises

similar initiatives across all DR deployment stakeholders.

of 19


Issue/Ver: 1.0

Date: 10/09/2018

3. Systems Maintenance Framework

The following sections aim to highlight good practice, where available, and share lessons learned from other delivery projects to assist Routes in the development of their own maintenance strategies. There are four key areas for consideration; Product, People, Procurement and Process as per Figure 2 below.

Figure 2 Maintenance Framework

During the early stages of deployment, there are opportunities to work collaboratively with suppliers to design in desirable features that offer maintenance efficiencies and benefits, provided suppliers are engaged early on in the project life cycle.

The following points have been identified as considerations that may enhance the benefits for SoS Reliability, Availability and Maintainability (RAM) targets. These considerations will not remove any obligations under Construction Design Management (CDM) or the Common Safety Method (CSM).

Considerations:

3.2.1. Monitoring Station – There is benefit in specifying that it should be possible to monitor all equipment within a central area from one central system monitoring centre. The scope of equipment that could be so monitored should be considered by the Route, but could include existing systems, new technology, and items that are currently considered to be of a different discipline or owner responsibility. Amalgamation of monitoring stations will enable rapid monitoring and investigation of the whole system, resulting in a shorter Mean Time to Repair (MTTR) equipment. However, it will be necessary to consider the implications were this system to fail, and this should be considered as part of RAM analysis to provide assurance that overall availability targets are met as well as part of business continuity management and system security requirements.

3.2.2. Replay Facilities – The facility should be available to enable immediate replay of events to facilitate the understanding of failures of the systems. In addition to this, it should be possible to align time codes from different items of equipment to establish an accurate timeline of events between systems.

of 19


Issue/Ver: 1.0

Date: 10/09/2018

3.2.3. In-built Intelligence – Sub-systems should be able to carry out health self-checks, flag up failures, and identify which part of its system has failed, including any issues that may have occurred with the Onboard. In conjunction with this, error messaging should be in plain text and in the vernacular (rather than in the form of error codes) and could be auto-reported. This intelligence should extend to the ability to self-report on software/hardware configuration and should also include the automation of values to reduce manual data entry needs.

3.2.4. Learning Environment – To address potential ‘skills fade’, it would be beneficial to have additional facilities, such as simulators, or the ability to partition the system to enable training whilst maintaining normal operation. This would enable scenario-based exercises to be undertaken to increase user confidence. Other tools may be investigated for use in conjunction with day-to-day activities, e.g. software applications for failure investigation, prompts and training. Other industries using complex digital systems have reported similar problems of retaining technical competence and familiarity, resulting in the replacement of traditional handbooks/manuals with a hybrid digital manual incorporating short video training materials to facilitate live training on rare faults.

3.2.5. Lineside Monitoring – Tools should be utilised to manage lineside assets in order to reduce the number of lineside inspections required and reduce the time that members of staff remain in higher risk environments. There is the potential to develop Onboard technology to assist with this in addition to Auto-reporting and health checking which should also be applied to enable remote diagnosis, thereby reducing the likelihood of failure and improving the MTTR.

3.2.6. Zero Maintenance – Any new products/technology should, where possible, be maintenance free or, where maintenance is necessary, have a minimal maintenance impact. This will reduce cost over the lifetime of the system and reduce the amount of equipment downtime.

3.2.7. Ability to update – For software updates, there must be no, or very limited, downtime. Some DR systems will provide control of large geographical areas and taking them offline will have a high impact on operations. When dealing with national updates it could be beneficial to allow air gap updates to reduce update roll-out time. However, with any updates, it is advisable that it be possible to roll back to the previous version quickly in case of any unexpected errors. There should be a robust process in place to evaluate the implications of an update for related and unrelated systems. Where possible, soak testing could be used to uncover system errors without causing Service Affecting Failures.

3.2.8. Obsolescence – As systems become more computer-based they may use more common software platforms and operating systems. If this is the case, then there is an element of certainty that these software platforms will, at some point, no longer be supported by the Licenser. In addition, it will not be known how the supplier’s software will function if the platform is updated for cyber security purposes. Hardware interface obsolescence has occurred previously with changes in Communication (COM) ports and, whilst this form of technology obsolescence can be re-engineered, it is at a cost and should be budgeted for as part of the maintenance strategy.

3.2.9. Product Support – Support contracts will need to be reviewed to establish if they meet the needs of the asset owner. An initial, more intense support contract can be beneficial in building knowledge and the confidence of the maintainers which training alone will be unlikely to provide. In addition to this, warranty periods should cover an in-service life from design, through commissioning and operation, not just during installation. How this is managed should be agreed early on in the project to enable the service provider to confirm that they can meet the needs of the customer and to ensure that pricing is obtained as part of the initial procurement process, thus ensuring value for money.

of 19


Issue/Ver: 1.0

Date: 10/09/2018

3.2.10. Line Replaceable Unit (LRU) – Any replacements should be as efficient as possible, e.g. replacing components without isolation but not effecting safety, or easily accessible components, connectors and non-intrusive test points which do not require the removal of other components in order to gain access to them. In setting the Route-specific requirements, Routes should consider requirements relating to design for maintainability, all components should be designed to be easily replaced. In addition to this having the replaceable unit able to determine when it is defective will also improve efficiency.

3.2.11. Human Factors – When considering the equipment within the SoS, Human Factors should be analysed. HF considerations which have been overlooked previously include aligning the RAG (Red Amber Green) statuses of new systems to existing systems to prevent confusion when managing assets, and using unified error codes or meanings across all systems and between IM and RUs. When there is substantial SoS-type work, there may be multiple HF considerations, all of which need to be aligned. Reducing the need for human data input by having pre-set options available for selection, or systems capable of self-calibrating, can ensure continuity of data input across systems. System and component version details should always be accessible, as well as any modification states. This aids in identification of system requirements and large-scale campaign changes.

Some areas of change that can occur with a DR deployment will be discussed below. A systems performance is largely dependent on the people who look after it and, in some instances, there may a be a crossover between responsibilities of the system and the areas in which the equipment is located; this will need to be managed and a process for communication across commercial boundaries introduced. The Maintenance Strategy should cover the transitional arrangements that need to be both considered and in place when Routes transition from current state to the SoS.

Considerations:

3.3.1. Cross-boundary relationships – Changes to interfaces between systems and people will need to be managed. Within the IM There may be fewer locally-based delivery units, which may mean longer travel times for maintenance teams; this will in turn, mean that additional support is required for failure diagnosis, and this may have to come from the more centralised teams. The Route deployment projects should also consider opportunities for employing multi-disciplinary staff capable of working across both trackside and Onboard systems to facilitate a more efficient whole-life cost solution. Management of events should be captured across boundaries by use of a DRACAS process.

Other organisations, such as HS2, will also need to be considered. It is beneficial to agree a contract to maintain their interface with the network. In addition to this, cross-boundary/discipline updates will have an effect on the entire system; a process will need to be established to manage these.

It is worth highlighting the IM-RU relationship again here. The RUs may require data from the IM, and vice versa. Data stored in the on-board system and within the IM systems can be accessed in a number of ways, but unless access is pre-agreed and data requirements clearly specified by the IM and RUs, it is unlikely that it will be possible to recover the service in a timely fashion. Data examples may include, but are not limited to;

• Balise error data

• Movement Authority (MA) data

• Packet/ Messages received/ transmitted

• Train movement and braking data

• Radio error

of 19


Issue/Ver: 1.0

Date: 10/09/2018

An Agreement will need be established and a process put in place to enable access to IM and RU data. This agreement will also need to include turnaround time and be subject to regular review as, over time, other data may be identified as beneficial.

3.3.2. System boundaries and interfaces – System boundaries and interfaces should be clearly defined and developed. A clear and concise Responsible, Accountable, Communicated and Informed (RACI) plan will help ensure anyone involved within the system understands both, their role in the system life. Mapping and agreement of system boundaries will further assist with this clarification for both the IM and RUs.

3.3.3. Track access and safety – It is expected that there will be an increase in rail traffic with the desired increase in capacity. Consequently, when developing a maintenance strategy, consideration should be given to track access needs after deployment to enable safe access to IM or RU assets during degraded mode working or emergency conditions. Other methods of accessing equipment should also be considered. In addition to this, where possible, structures should be built with fixed access equipment to avoid the need for temporary structures, e.g. where signals are located on platforms, it can be safer to supply fixed ladders and use anti-vandal guards to prevent public access.

3.3.4. Resourcing – Location of staff is likely to change. As more equipment becomes centralised, there may be a need to review staffing in the central control area. In addition to this, the skill set of teams maintaining equipment will probably need to evolve. Having increased resources centrally could enable faster trackside equipment recovery times as the central team will be able to provide technical support through use of diagnostic tools and assist in identifying the failed system component. During training periods, it may be necessary to find additional personnel to cover critical roles. The technology step-change could also result in an initial loss of skills due to the challenges being faced.

3.3.5. Training Requirements – When setting out training requirements, it will be beneficial for the maintainer to have an understanding of all aspects of the system, including those elements of which they might not be traditionally aware. A learning needs analysis should be undertaken on all roles impacted by the DR change; for instance, an IM maintainer needs to understand the in-cab signalling features, especially the Driver Machine Interface (DMI). In addition to this, they may also need a good understanding of the operating rules.

3.3.6. Training Facility – Having an on-site training facility can be costly as training equipment needs to be maintained to the same standard as live equipment. An additional challenge involves preventing the training facility being used for spares. An on-site training facility may, reduce the turnaround time for training new starters and help to maintain the confidence and competence of other personnel.

3.3.7. Training – Training could be provided on equipment prior to it being brought into use. In this case the risk of equipment being damaged should be considered. Practice component replacement is also an option. Once the equipment has been commissioned, the opportunity to train no longer exists for any new starters during operational periods.

3.3.8. Equipment Specific Training - Generally, this is provided by the supplier initially; however, this initial period will be relatively short compared to the lifespan of the equipment. Routes should consider how training will be managed to enable the trainers to retain equipment knowledge and competence for the whole life of the system. This may be in conjunction with the supplier of equipment where limited numbers of people work on it.

of 19


Issue/Ver: 1.0

Date: 10/09/2018

3.3.9. Gaining System Knowledge – System knowledge can be difficult to achieve through training courses alone; embedding a member of the maintenance organisation within the project to provide in-house technical expertise has been highlighted as good practice. Tacit knowledge can also be built upon by ensuring involvement in a project’s Defect Reporting, Analysis and Corrective Action System (DRACAS) process, which should be implemented during the soak/trial testing period and run beyond the initial deployment into Business as Usual. This would ensure that staff responsible for maintaining the system gained an understanding of potential technical failures early on; this would help them to identify potentially larger issues, such as design or software issues. System knowledge can also be gained from the supplier by enabling the maintainers involvement in the FAT - Factory Acceptance Test and SAT - Site Acceptance Test process.

3.3.10. Mentorship – For IM’s specific training course might not be available, it could be beneficial to set up a mentorship programme to manage new starters and run through scenario-based exercises. However, attaining competence can take longer as mentorship may be dependent upon staff completing activities that might not be required very often. The Cambrian deployment found benefit in employing those with telecoms backgrounds and training them in signalling principles; another approach could be to have multi-disciplined teams.

3.3.11. Competency Management – Skills fade needs to be considered, as this is likely to occur due to the reliability of the new equipment. Traditionally, equipment-specific training courses have been available after project delivery. Such training courses may be difficult to provide in future, meaning competence will need to be managed differently, possibly by building periods of scenario-based training into normal working. The competency management system will likely need to be updated to reflect the aforementioned.

How equipment and services are procured for the delivery of a complex systems integration programme can directly influence the resulting maintenance outcome. The approach to procurement will underpin the programme-wide aims and objectives and must be planned with Systems Maintenance in mind before awarding contracts.

Specifically, it is worth considering how RAM allocations break down into ‘design for maintainability’ requirements, in parallel with setting a ‘Maintenance Strategy for DR Assets’ on the Route. These two aspects of maintenance are inextricably linked and are essential for overall DR SoS performance, but they are often dealt with by separate teams, notably, ‘design’, ‘transition into service’ then ‘operations and maintenance’.

When developing a procurement strategy, the following should be considered however each Route will have their own procurement guidelines.

Considerations;

3.4.1. Warranty – It is essential, where necessary for Routes to understand and procure appropriate warranty arrangements either directly or with 3rd party suppliers and also that those warranty arrangements are clear in respect of their start and end criteria (delivery date versus first installation date versus commissioning date).

of 19


Issue/Ver: 1.0

Date: 10/09/2018

3.4.2. Current equipment – It might reduce whole life costs to use a similar supplier to that used for existing equipment. e.g. suppliers should have the corporate knowledge to be able to make changes to the SoS, and maintainers are likely to have confidence in their skill set when working with familiar equipment.

3.4.3. Specialist diagnostic equipment or tools – Often with new systems and, specifically, complex digital systems, there is a need for special diagnostic or test equipment; in addition, there can sometimes be a need for special tools which do not form a part of a standard railway technician’s toolkit. Examples may include plug in testers/laptops, etc. for diagnosing faults on an Onboard, for example. Similarly, there are examples where special tools may be needed to open boxes or cabinets, e.g. tamper proof tools. Ideally, specialist equipment would not be required. However, it is important to ensure that sufficient numbers of unique items of equipment or tools are procured to equip the maintenance workforce who will require them, and that there is a strategy for procuring additional items in the future.

3.4.4. Ongoing support – Routes may require a longer period of support to enable Route/ systems knowledge development (two years, or potentially product lifespan). e.g. European colleagues have requested 25-year support contracts and generally specified that 1st and 2nd line will be managed internally with further support from the supplier. Some have identified high-level requirements, which are shared below:

• Fault restoration support service

• Spare part service and pricing thereof over longer timescales

• Configuration Management service

• System component performance data analysis service

• Documentation service

• Modification retrofit and change support service

• System administration services

• Software Maintenance service

The supplier is responsible for the whole life of the system, including any obsolescence over the 25 years.

3.4.5. Initial Spares – If a spare parts service, is not procured then consideration should be given to carrying out an analysis of spare parts requirements in terms of both the range and volume of spare parts needed. This analysis needs to be carried out as part of the design process to provide assurance that the overall operational availability of the DR SoS meets the RAM allocation made during the RAM analysis.

Once a system becomes operational, the role of process becomes significantly more important to the successful management and sustainment of the DR SoS. Routes should consider a variety of process-related elements during the specification of DR requirements.

Considerations:

of 19


Issue/Ver: 1.0

Date: 10/09/2018

3.5.1. Installation and commissioning handover and handback – Routes should bear in mind that the implementation of assets will occur over lengthy periods of time. Requirements will need to be set which address not only the basic handover/handback arrangements, but also who is responsible for maintaining assets during the lengthy testing and commissioning of the DR SoS. These arrangements have the potential to impact warranty and the final configuration in terms of design and hardware/software configuration.

3.5.2. Managing software upgrades and configuration change – Any software configuration change will likely affect onboard and trackside equipment. ensuring there is a process to engage with all parties to assess the impact of the change will be necessary. The DRP has established a System Authority function which will provide national level support for design configuration across all the Routes.

3.5.3. Processes to manage potentially large numbers of alarms or alerts from self-reporting digital systems – Connected digital systems offer many benefits and the Product section of this Maintenance Framework has discussed the potential for the Routes to include requirements for self-monitoring and self-reporting. Previous experience both from within the railway sector and from other industries indicates that such innovations bring new problems of their own. The Routes should consider the technical specifications for the product tools to help manage and filter alarms and notifications. Additionally, a process will be required to address potentially large numbers of alarms and notifications. Any such process will need to address how to respond to the alarms, but it should also include a degree organisational instruction on differentiating between spurious alarms and real ones.

3.5.4. Processes to manage No Fault Found and understand root causes through Root Cause Analysis (RCA) – It is likely that the Routes will specify in their procurement activity some kind of ‘Repair and Return’ process for failed items. Previous experience from both the rail industry and other sectors indicates that electronic and digital items can often be returned to the railway asset owner after such a Repair and Return activity marked as ‘No Fault Found’. It would be viewed as good practice to include some kind of identification process which can isolate a part that is repeatedly going into the supply chain for repair. A DRACAS system can help support this.

It is often the case that Repair and Return contracts include the ability (at additional cost) to carry our Root Cause Analysis. Routes should consider the cost benefit of those activities, balancing the benefit of a detailed RCA report with a Route’s ability to analyse/act on such reports and the overall cost of the part concerned. This should be considered in a wider Whole-Life Cost (WLC) analysis process which builds upon the WLC models constructed during the business case development and design phases. Actual WLC should continue to be monitored as the DR SoS matures through its life cycle.

3.5.5. In Service Spare Parts Management – In designing their overall maintenance processes, the Routes should consider that digital assets are much more prone to obsolescence than traditional rail assets. A process will be required to maintain assets in a controlled environment. The Routes should also design a process which, before issuing a spare part for a repair activity, provides assurance that it is of a software load and hardware configuration that matches the system into which it is being installed.

maintenance framework - digital railwaydigitalrailway.co.uk/wp-content/uploads/2019/04/...issue/ver:...

Documents