European rail vehicle and infrastructure databases study - - PowerPoint PPT Presentation

European rail vehicle and infrastructure databases study

Mick Haynes, Project Director, and the Atos consultancy team

Presentation of final report

NMBS/SNCB HQ Brussels 5th October 2011

2

Agenda

▶ 1. Welcome ▶ 2. Introduction and background ▶ 3. Overview of the study ▶ 4. Results of the questionnaires and interviews ▶ 5. Presentation of the main ‘gaps’ ▶ LUNCH ▶ 6. Introduction to the solution – principles ▶ 7. Impact on the existing architecture – 7.1 Databases – 7.2 Interfaces – 7.3 Pointers ▶ 8. Technical feasibility ▶ 9. The way forward – Phasing – Costs and benefits – Governance ▶ 10. Summary and discussion

3

The consultancy team

▶ Mick Haynes Project Director ▶ Chris Dugdale Lead consultant ▶ Fraser Mitchell Consultant and project manager ▶ Steve Shaw Consultant (vehicle data) ▶ Peter Beevers Technical consultant

4

▶ Consultancy study under contract to the European Commission ▶ Linked to the work of a Task Force established by the European Commission following the 51st meeting of RISC (the Rail Interoperability and Safety Committee) ▶ The task of the consultants is summarised as: -

“Before taking any decision on the technical aspect of a real-time data exchange system, there is a need for a detailed overview on data requirements which arise from the European Railway Regulatory Framework, including Safety and Interoperability Directives (and the related secondary legislation e.g. technical specifications for interoperability), on market needs for real time data exchange, and on existing IT applications in operation or being developed in Europe. The study will determine if these applications make it possible to fulfil the

• requirements. The study will then recommend a real-time data exchange system

from the technical, governance and financial aspects. Finally, the study will examine the technical and economic feasibility of it.”

Introduction

5

▶ The TAF-TSI (Regulation (EC) 62/2006) sets out a structure of mandatory messages and databases for freight. The TAP-TSI is very similar. ▶ Only these two TSIs require the use of IT and telematics, ▶ Other TSIs, other EU law, and international conventions create other

• bligations to exchange data but do not specify the means

Introduction and background

6

Overview of the study

▶ Phase 1 fact finding ▶ Questionnaires ▶ Interviews ▶ Extract the requirements in the legislation ▶ Phase 2 assessment ▶ Assessment of fulfilment

• f legislation

▶ Gaps ▶ Data issues ▶ Technical requirements ▶ Phase 3 recommended options ▶ Work up the available

• ptions and

recommendations ▶ Phase 4 feasibility ▶ Technical and economic feasibility ▶ Governance

7

Questionnaires

▶ Sent to/replied: ▶ National safety/regulatory bodies (27/6)

• 22%

▶ Nineteen vehicle keepers (19/5) – 26% ▶ Railway undertakings (37/5)

• 14%

▶ Twenty-three infrastructure managers (23/6) - 26% ▶ Twenty-one industry associations (21/3)

• 14%

▶ Questionnaire in three parts: ▶ Policy and strategic issues consultation (sent to all stakeholders) ▶ IT systems and databases in use and whether compliant or not

• Infrastructure register
• Vehicle registers
• Consignment data
• Train pathing
• Train operations
• Vehicle operations
• Vehicle maintenance and repair

Each organisation only received the IT questionnaires relevant to its role

8

Results of the questionnaires – policy/strategy

▶ As expected, individual views submitted tended to be related to the role of the

• rganisation in the industry.

▶ However some themes emerged: ▶ Centralised databases of vehicle technical information were favoured (NVR as minimum)) ▶ Keepers and ECMs are entitled to be supplied with information from other parties such as RUs at least daily for maintenance/fleet purposes ▶ Keepers/ECMs should coordinate maintenance information ▶ Benefits seen in electronically accessible databases for infrastructure capability ▶ Network statements should be linked to infrastructure DBs ▶ IRNDBs should be integrated with infrastructure DBs ▶ Safety-related data should be excluded from the TAF-TSI messages ▶ Common-use databases & registers should be under industry control ▶ TAF-TSI should apply to all freight services, international and domestic The results should be treated with some caution because the number of responses was small

9

Results of the questionnaires – IT systems (1)

▶ Infrastructure register ▶ Most respondents have an electronic system for infrastructure data ▶ Infrastructure restrictions ▶ All respondents have a system but indicated changes needed for TAF-TSI ▶ Vehicle registers ▶ All respondents had electronic records however none are fully compliant with TAF-TSI. Respondents said that systems would be compliant at the end of SEDP roll-out ▶ Consignment notes ▶ All the RU respondents operated such systems, which in some cases generated records for a billing system

10

Results of the questionnaires – IT systems (2)

▶ Train pathing ▶ All respondents operated or used such systems ▶ Train operations ▶ All respondents had such systems in use, one respondent for over 40 years. The information was usually made available electronically to RUs ▶ Vehicle operations ▶ All respondents had systems. Respondents said that systems would be compliant with TAF-TSI at the end of SEDP roll-out. ▶ Vehicle maintenance and repair ▶ All respondents reported favourably on their systems, some

• f which are commercial-off-the-shelf (COTS)

11

Results of the questionnaires – REX

▶ Difficulty with integrating a new system with other existing systems.

▶ Many existing systems have been in operation for many years, some are decades old, with obsolete platforms and various other incompatibilities.

▶ Difficulties with data quality, especially from external parties.

▶ This can force the need for costly data checking and manual correction processes negating the system benefits. On the other hand, other organisations reported improvements in data quality

▶ Benefits for processes that had previously relied on paper documents, and low tech office tools like fax and e-mail.

▶ Benefits were reported by most organisations from the various systems they had implemented

▶ Benefits due to system making data available to organisations not directly involved.

▶ Example given was engineering being able to use vehicle movement information to improve maintenance and reduce costs

The results should be treated with some caution because the number

• f responses was small

12

Results of the questionnaires – state of the art

▶ Systems covered a wide spread of technology, from 40 year old mainframe- based systems in one IM, and use of MS Excel in another, to leading edge systems that had only recently been introduced. ▶ The newer, smaller, railway undertakings have only limited funds available for IT development, so carry on using existing systems, or purchase modern COTS products. ▶ For some functions such as asset maintenance there is sharing of development costs by purchase of ‘modern’ commercial products.

13

Results of the interviews – main points

▶ None of the interviewees IT systems was 100% compliant with legislation

▶ however stakeholders pointed to a substantial measure of compliance and to developments that would increase the level of compliance.

▶ Relationships within the industry are complex, therefore data exchange is also likely to be complex. ▶ There is a need to ensure that any solutions take into account the needs of small and medium enterprises (SMEs). ▶ Only one of the stakeholders was able to identify a development which would deliver substantial and defined savings ▶ It is acceptable to legislate on the principles of any system, but stakeholders should be free to find their own means of satisfying them.

▶ In particular proprietary databases should not be mandated, for example

▶ Solutions need to also take into account countries outside the EU.

14

Analysis of ‘gaps’

▶ This section of the presentation ▶ Introduces the ‘gap analysis’ and lists the unfulfilled data needs found by the team when considering the overall picture of the TSI requirements for interfaces and databases in meeting the objectives of the TSIs ▶ Presents the ‘gaps’ ▶ Presents the ‘big picture’ visualising the total TSI requirements ▶ A question and answer session on the ‘gaps’ we have presented

15

Analysis of ‘gaps’

▶ General “Health warning” ▶ The consultant’s proposals, and to a lesser extent the gaps, do not fit into a simple single activities. We identified fourteen but only the major ones are presented ▶ Summary of the major gaps: ▶ Providing railway undertakings with vehicle technical data ▶ Supplying the keeper with vehicle performance data ▶ Supplying incident data to customers ▶ Enhanced data in the wagon order message ▶ Vehicle search enquiry ▶ Keeper access to vehicle information ▶ Handover and interchange process ▶ Accessing the infrastructure file ▶ Train running information

16

Analysis of ‘gaps’

Providing railway undertakings with vehicle technical data ▶ The obligation to run a safe railway means that railway undertakings need a complete file of vehicle data before they run a train (and preferably before they load a vehicle) ▶ They need permanent data – its weight, length, carrying characteristics … ▶ They need temporary, transient, data, the vehicle’s condition ▶ The source of the data needs to be authoritative ▶ TAF-TSI does not define messages to exchange this data properly nor the prime source ▶ This is an operational need

17

Analysis of ‘gaps’

Supplying the keeper with vehicle performance data ▶ In accordance with the ECM Regulation, entities in charge of maintenance need information on the performance of vehicles in order to develop proper maintenance programmes. The keeper, with the rights to control the vehicle, needs to be involved in this process. The information most sensibly comes from user railway undertakings. This is the provision of historic journey data ▶ The ECM legislation post dates TAF and therefore TAF-TSI does not address this issue ▶ This is an operational need

18

Analysis of ‘gaps’

Supplying incident data to customers ▶ Whilst incidents are rare, their consequences are serious, customers need to be kept informed ▶ The most sensible way is via the lead railway undertaking ▶ TAF-TSI, whilst recognising the problem, does not deal with it

• adequately. The exception message does not cover all types of

incident. ▶ This is a market need

19

Analysis of ‘gaps’

Enhanced data in the wagon order message ▶ The wagon order message does not contain all the data needed to move traffic effectively. Most importantly, it doesn’t distinguish subcontracting carriers ▶ The wagon order message partially duplicates the function of the electronic consignment note message in e-RailFreight ▶ This is a shortcoming in TAF-TSI ▶ Operational need

20

Analysis of ‘gaps’

Vehicle and container search enquiry ▶ Customers want hard information about their traffic ▶ TAF-TSI doesn’t define a message with hard information about their wagon(s) and/or containers ▶ TAF only has container as part of the TransportUnit within a wagon and it is not indexed ▶ This is a market need

21

Analysis of ‘gaps’

Keeper access to vehicle information ▶ Keepers are defined (in the Safety Directive) as the party with the right to make use of the vehicle ▶ Keepers must therefore maintain their RSRD and get information about their vehicles to organise their business ▶ The system must also accommodate long term hire to either other keepers or RUs ▶ TAF-TSI does not provide a message or messages for the keeper to

• btain information about the vehicle’s deployment/ location to plan

maintenance/repair ▶ This is an operational need

22

Analysis of ‘gaps’

Handover and interchange process The goal is to achieve common electronic handover. ▶ TAF-TSI defines a number of handover and interchange messages ▶ TAF falls short on achieving the goal as it has interchange notice interchange sub notice to IM and RU respectively A standard approach for achieving small variations in formats could be the solution ▶ They require to be rationalised to reflect the realities of current practice, ▶ to take account of the roles of railway undertakings, ▶ to reflect infrastructure managers’ limited interest ▶ to make them more coherent ▶ to make use of current messages ▶ This is an operational need

23

Analysis of ‘gaps’

Accessing the infrastructure file The need is to be able to validate the train composition before running over the infrastructure ▶ TAF-TSI requires railway undertakings to interrogate the infrastructure file to ensure vehicles are compatible ▶ Unfortunately, the process as defined uses the ERATV and RINF (as specified in annex G of RINF final report) but it is not clear that all the data is present ▶ More clarity is required to indicate how this will work in practice. The RSRD, train composition, train path and line of route and the ERATV all need to be taken into account and compared with RINF and the temporary infrastructure restrictions database and possible temporary vehicle restrictions ▶ This is an operational planning need

24

Analysis of ‘gaps’

Train running information Need is to have efficient access to current train running information which is clear ▶ TAF prescribes in some circumstances that the IM supplies the RU which then supplies the next RU. This is likely to be inefficient. In addition, there is no IM to IM message except for 407 and TIS ▶ The principle that data should always be supplied by the entity closest to it requires that train running information should always come direct from the infrastructure manager, it should not be passed via railway undertakings ▶ This both an operational and a market need

25

Analysis of ‘gaps’

▶ TAF TSI has 2 train IDs defined – path and train. ▶ The TAP commercial messages need a train ID to link to the timetabled train and for reservation purposes ▶ Signalling requires a common ID between RU and IM based on the operational ID of a train ▶ The Working Group (WG10) has defined a TTID with 4 identities ▶ Many IMs and RUs commented that the solution was complex and didn’t explain what would happen when an ID was not present ▶ Missing train ID needs to be resolved ▶ The train number is not always available in the required timeframe ▶ This is primarily an operational need but commercial timeframes for TAP will need solutions in advance of real operational allocation.

26

Analysis of ‘gaps’

▶ There is a gap in the handover process to provide efficient electronic response from IM to RU to avoid the need for the RU to complete a specific set of documentation and receive a specific set of documentation before the RU can safely pass onto the new IMs infrastructure ▶ Driver advisory information from IM to RU ▶ The IM has information that should be passed to the driver ▶ Train composition to be sent from RU ▶ The handover process to include any communication that is needed between the IM and RU to use his path ▶ This is an operational need

27

Analysis of ‘gaps’

▶ TAF includes a single specific train composition message . TAP is unclear on what is appropriate for passenger services. The working group (WG3 ) left it for agreement between each RU and IM. This ensures that the developments will not deliver the expected benefits! ▶ Train composition clarity is needed for RU to IM development ▶ We propose two variations – The full composition as in TAF can also be sent as HERMES 30 – A shortened version suitable for passenger trains containing essential elements (not for TAP the formation details are essential for passenger commercial reasons) ▶ This is an operational need

28

Analysis of ‘gaps’

The “Big Picture” of the as-is situation

29

The current overall ‘picture’

30

Conclusion from the ‘gap’ analysis

▶ Lack of clarity – prime data sources are not well defined and replication leads to uncertainty of source for authoritative information ▶ WIMO – a way forward is required as it exists as a centralised solution in TAF but an alternative technical solution is required ▶ RSRD – no clear defined responsibility for managing vehicle data and data duplicated with WIMO ▶ The wagon order message is an inadequate subset of the consignment data

31

Analysis of gaps/issues

So now its your turn questions and answers on the gaps!

32

The ‘to be picture’ including all TSIs

33

Legislative source for each interface

for each of the 35 interfaces we have identified the legislative source – Example for interface no 1

No Description TAF (or other) Message/interface Solution changes 1 Maintenance Data/Wagon restrictions/Performance As described in the Conventional Freight TSI, the RU will require maintenance/restriction data to assure themselves of the vehicles fitness to run. Additionally the RU should provide performance data back to ECM/keeper to allow for future maintenance planning 2006/861/EC – Section 4.2.8.1.2 None suitable RU will request maintenance/restriction data (see also flows 3, 5) from the relevant keeper database (RSRD). The relevant RSRD will be identified by initial querying of the pointer file and the data may be retained in the RU traffic database as a date series to ensure it is up to date and as accurate as possible Additional messages required : 1. From RU to pointer file to update RU using the vehicle number obtained from HERMES interchange message 2. From RU to pointer file to identify keeper database and reply

• 3. From RU to keeper’s database to request defined data items

for a vehicle and reply

• 4. From keeper to pointer file to check RU’s entitlement to data

and reply

• 5. From RU to pointer file to claim a vehicle coming from outside

system

• 6. From RU to keeper database (RSRD)/ECM to provide

maintenance/performance data/stop-release. W e propose the HERMES “Goethe” message to be considered as a possible model for provision of wagon use/performance information by RUs to keepers

Data exchange required Existing defined message Proposed solution

34

Introduction to our solution

35

The issue

Before deciding on databases, we ought first to consider the data This presentation looks at the types of data we need to handle, where it is used and where it might be most sensibly sourced. The analysis is necessarily high level and does not make direct reference to TAF-TSI structures. The perspective is that of a freight wagon. Passenger vehicles and infrastructure are only treated in passing. We have identified some points which you may find contentious.

36

Our solution in detail

– Gap solutions – Data groups – Principles – Technical data – Performance data – Journey data – Traffic data – Pointer files – Messages

37

Gap solutions

▶ GAP ▶ RUs access to vehicle technical data ▶ Vehicle performance data to keepers ▶ Incident data to customers ▶ Improvements to wagon order ▶ Vehicle & intermodal search ▶ Keeper access to certain vehicle info ▶ Handover / interchange standardise ▶ Access to infrastructure data ▶ Train composition ▶ Missing train ID ▶ SOLUTION ▶ Distributed RSRD with pointer, H30 in the interim ▶ Revised messages between RUs & keepers to distributed RSRD ▶ Uses H30 which already includes incident messages from RU to keepers ▶ Wagon order enhanced to include the data each RU needs according to its role ▶ New enquiry messages. Intermodal identity to be referenced ▶ LRU to provide data via new message ▶ Agree solution and valid variances on standard interchange message. Include driver advisory notice ▶ Resolve process and message structures ▶ Provide two versions and mandate use ▶ New message flows to resolve

38

Data groups and classes of data

Authorisation data – is the vehicle authorised at all, is it authorised to run to its destination? Technical data – permanent data – what is the vehicle’s weight, braking characteristics, load/speed characteristics, Technical data – vehicle condition – maintenance due data, restrictions due to condition, Vehicle performance and repair data – how far has this vehicle run, what repair work has been done on it, Journey data – where is this vehicle going, what does it contain, are there special instructions, Consignment history and tracing information Messages and pointer files

39

Principles

Data should be maintained by those closest to it and with an interest in its accuracy. Data can only be maintained by organisations ready, willing and capable. Organisations must be prepared to accept liability, they must have the systems knowledge. As far as possible data should be held in one-stop-shops. Systems should build on what exists. Systems should take account of the fact that not all railway organisations are large and rich.

40

Technical data

Authorisation data, permanent technical data and vehicle condition data are

• allied. They should be in the same database.

The keeper is the obvious person to hold this data. The consultants believe that the keeper’s data (rather than the NVR) should be the master file. (In many cases that is inevitable since the NVR is not rich in data).

41

Vehicle performance

Distance run data, repair work and so on should be recorded on the keeper’s technical file. It follows that railway undertakings (etc.) should supply the keeper with distance run, stopping of the wagon, repair work, etc. The consultants believe that the keeper and not the ECM should hold the master file to avoid split responsibility. The ECM will of course require to read it and write to it.

42

Journey data

Each user railway undertaking requires journey data to say where the vehicle is going, what it contains, what customs process are required en route, etc. The “wagon order” message provides the source. It needs to be more sophisticated to provide (for example) for subcontracting railway undertakings. There is no need for this data to be held in the (former) user RU’s system after the vehicle has departed. The lead railway undertaking however will hold details of the journey and the keeper will hold details of the wagon’s performance.

43

Traffic database

A traffic database is required for current customer enquiries, quality analyses, etc. This can only be held by the lead railway undertaking. The traffic data needs to be held after the journey is completed to allow for retrospective analysis.

44

Pointer files

Pointer files are needed to point to the database holding the technical data for each vehicle so that (for example) railway undertakings can interrogate it. Pointer files are needed to provide the current user railway undertaking for each vehicle so that updates on condition can be sent. These pointer files are crucial and require to be impartially managed.

45

Messages

Additional messages are required to support this structure. Not many are required and they are simple. The consultants noted however that the existing suite of HERMES messages provides substantial cover for some applications, advice of distance run, advice of incident and repair, for example. Furthermore, the HERMES interchange messages provide a remarkably effective way of providing technical data for vehicles. Some changes will be required to reflect new requirements and the effects

• f liberalisation

46

Impact on existing architecture

▶ Databases ▶ Pointers ▶ Technical feasibility of our solution

47

Vehicle registers, databases and interfaces

▶ With all the TSIs we have: – VVR (not a register but a pointer) – NVR (a register) – ERATV (a register) – RSRD (to be a distributed reference database) – WIMO (to be a distributed set of current operational data) – Pointer(s) needed to support distributed RSRD and WIMO – Maintenance records to be held in RSRD ▶ Need to define how are they linked and how often? ▶ Which is the master? ▶ Who is taking responsibility for which data?

48

Wagon operational database (WIMO)

▶ To implement TAF, a solution is needed ensure all RUs have quick access to technical data and movement data for their movements. In the future keepers and ECMs also need operational data to carry out their roles efficiently – LRU to be responsible for holding traffic data for the whole journey. This includes trainload movements. RU to copy all movement messages to LRU. – To copy movements to ISR for all traffic where multiple RUs are involved (could also be X-Rail if trip plans are needed) – EU wide pointer file required to identify nominated wagon movement databases – index to be identified ▶ Priority 1.

49

Implementation of RSRD

▶ Duplication of data with WIMO to be avoided – clear statement of which is the master file (admin and design datasets) ▶ The RU needs to have up to date data relating to the maintenance status and condition of the vehicle. ▶ RSRD2 proposals exclude maintenance and defects – these must be added ▶ If the database is distributed, there needs to be a method for knowing which database has data on which wagons ▶ New messages will be required for exchange of maintenance and status data ▶ Priority 1 for technical characteristics and 3 for maintenance data

50

Infrastructure temporary restrictions

▶ Specified in TAF but under discussion ▶ CER, EIM and UIC have study group (suggestion to OPE group to set out the process) ▶ Should enable the RU to validate the composition and to issue the driver with safety and line of route documentation (in the longer term) ▶ Online enquiries by route of the train to be done by the RU BEFORE transmitting the train composition. ▶ Note that the IM is not responsible for validating trains, a process is laid down for very short notice infrastructure restrictions ▶ Priority 2 for initial version

51

RINF architecture and interfaces

▶ Needs a database(s) to be created and a new message to access. ▶ Need links to Network Statement and IRNDB ▶ This is complex due to the many special restrictions in Annex C of RINF Final Report ▶ The coding of line sections needs to be clearly specified and related to Locations Reference file ▶ The respective roles of the NSAs and IMs in establishing RINF, taking account of multiple infrastructure managers in some states. ▶ Code lists and messages to be defined ▶ Implementation will be phased (ERA already defining) ▶ Priority 3 due to need to collect some key elements

52

Implementation of ERATV and interfaces

▶ ERATV is central and not required for operational day-to-day messaging. Links to NVRs and RSRDs are needed with defined messages – unless existing types are included its usefulness will be limited. ▶ Link to the infrastructure database required for validation of capability – need to be able to identify individual lines ▶ Cross acceptance needs some agreement as to acceptable build tolerances in vehicles of the same type ▶ Priority 2 or 3

53

Pointers

This is a new needed to make the solution proposed work - concept to allow for distributed databases ▶ To support the distributed RSRD and Wagon Movement Databases a central pointers file will need to be implemented ▶ Each RU links its wagon movement database to a central index ▶ Each keeper updates a pointer with a link to its RSRD ▶ Priority 2

54

Technical aspects - sizing

Message volumes are relatively low

– Data based on UIC 2008 statistics from EU-27 – Added other variables using experience – Produced

• a sizing for the total volumes expected in the system
• Estimates of effort to develop various parts of the system

and enhancements required by it

55

Technical aspects - methodology

▶Industry-standard metrics ▶Spreadsheets and tables used internally by Atos for project sizing etc. (self validating) ▶Volumes etc. were used to drive feasibility calculations

56

Technical aspects – pointer files

▶A central index of where to find information ▶Updated as/when required ▶Main use is for queries, assume that the issuer will cache the result

57

Technical aspects - summary

▶Message volume is small ▶Pointer files (central) system hardware and volumes are modest by current standards ▶Message passing layer isolates the varying technologies from each other – also provides a wall round the system

58

The way forward

▶ How to proceed – Phasing – a suggestion – Costs and benefits as compared to the base case of implementing TAF as is – Governance

59

Phasing include list of priorities

▶ Three phases are proposed, each taking two years ▶ Phase 1 2013 – Incorporation into TAF-TSI existing interchange messages based on their xml versions – Simple bid offer – Train running information ▶ Phase 2 2015 – Implementation of pointers to distributed databases and interfaces ▶ Phase 3 2017 – Implementation of remaining databases – Implementation of wagon maintenance – Implementation of performance related messages

60

Gap phasing

▶ GAP ▶ RUs access to vehicle technical data ▶ Vehicle performance data to keepers ▶ Incident data to customers ▶ Improvements to wagon order ▶ Vehicle intermodal search ▶ Keeper access to certain vehicle info ▶ Handover / interchange standardise ▶ Access to infrastructure data ▶ PRIORITY / PHASE ▶ Priority 1 via H30 ▶ Priority 2 ▶ Priority 1 via H30 ▶ Priority 2 ▶ Priority 1 for wagons, 2 for intermodal ▶ Priority 2 ▶ Priority 1 for interchange, 2 electronic ▶ Priority 3

61

Simplification of implementation

▶ Although outside the remit, we considered how to implement and some simplification ▶ We recommend adoption of existing interchange message (HERMES 30) as suitable for filling the gap on handover and interchange and should be included in the change management to allow it to be used as a combination of train composition and separate wagon technical messages ▶ We recommend wagon technical data continues to be included in the interchange as now until RSRDs are up and running

62

Need for simplified path request & path offer

▶ The system laid down in TAF-TSI for path requests requires formal messages to be sent, processed and received ▶ It is clear that a formal request and allocation process must take place, but the form of this process needs to reflect the need to encourage

• competition. A complex message-based solution may require too much

programming for a small railway undertaking ▶ A simple solution is required to enable single request/offer to be exchanged (this could be web based). ▶ This is partially provided for in TAF but has since been made more complex to allow for harmonised and partially harmonised requests/offers. ▶ This is both an operational and a market need ▶ Priority 1

63

Quantification of costs and benefits

▶ Introduction – On the costs and benefits we have studied ONLY the impact of our recommendations on costs and benefits taking the implementation of TAF as a base – Costs are incurred 2012 through to 2017. Benefits accrue only when the systems are in widespread use ▶ Classification of types of users – We chose to categorise all users into type in order to show different users are impacted differently ▶ Costs methodology – The types of IT change were estimated based on typical IT scenarios and using ATOS metrics for man days – The man days were converted into € based on a conservative cost of €300 per day ▶ Benefits methodology – IT cost avoidance – Staff savings at handover, small increase in volumes due to increased customer satisfaction

64

Types of user - RUs

▶ Category R1 - Large RUs operating internationally with sophisticated commercial and traffic management systems.

– RI type RUs will need to modify their systems to support new interfaces and modified fields. They will probably already be using RAILDATA so they can fast track development and implementation using their TSI support. They will already support international freight messaging.

▶ Category R2 - Medium RUs operating internationally with reasonably sophisticated commercial and traffic management systems.

– R2 type RUs will need to enhance their systems to support new functions and interfaces and new and modified fields. Some will already be using RAILDATA so can fast track using their TSI support. Already support international freight messaging.

▶ Category R3 - Medium RUs operating nationally and geared to national rules

– R3 type RUs will need to modify their national procedures to support the TSI processes messages and interfaces applicable to them. This will need to be done in conjunction with their IM as it impacts traffic messages.

▶ Category R4 - Small RUs operating internationally with very simple IT

– R4 type RUs will need a small system to support the three basic functions of train composition, path request and train running. This should form the minimum package.

▶ Category R5 - Small RUs operating nationally in a limited geographic area with simple IT and only one IM.

– R5 type RUs should only need to support the HERMES interchange message as they would use online access to the IMs traffic system for traffic purposes.

65

Types of user - IMs and keepers

▶ IMs

▶ Category I1 - Large IMs with sophisticated IT and multiple RUs as customers ▶ Category I2 - Small to medium sized IMs with less sophisticated IT and only a few RUs as customers.

▶ Keepers

▶ Category K1 - Large RUs with their own fleet for which they act as wagon keepers. ▶ They will already hold a wagon database which will require small enhancements to meet the RSRD requirements. ▶ Category K2 - Independent wagon owners and operator belonging to the UIP. ▶ They will use the new RSRD2 ▶ Category K3 - Small RUs without a wagon database suitable for RSRD and small wagon keepers not members of the UIP

▶ ECMs

▶ Category E1 - RUs responsible for their own maintenance and maintenance staff. ▶ They will need to ensure maintenance and defect data is recorded and interfaced in accordance with the TSI ▶ Category E2 - Independent maintainers. ▶ These are maintainers who do not have an RU safety certificate and do not operate trains. They maintain rolling stock under contract with the keeper.

66

Costs methodology (1)

▶ Types of IT change: Type Abbreviation New simple interface NSI New complex interface NCI Modified simple interface MSI Modified complex interface MCI New RSRD database NRD New traffic database NTD New RINF (infra) database NID Modified RS database MRD Modified traffic database MTD Modified inf database MID New IM NI New RU NR

67

Costs methodology (2)

Type of development On modern web based technology On mainframe technology On bespoke small computers (SMEs) New simple interface 4335 5202 3685 New complex interface 8160 9792 6936 Modified simple interface 3655 4386 3107 Modified complex interface 5610 6732 4768 New RS database 29155 34986 24782 New Ops Database 37740 45288 32079 New INF database 24225 29070 20591 Modified RS database 15342 73644 13041 Modified Ops Database 20995 100776 17846 Modified INF database

68

Costs impact assessment

69

Benefits methodology

Divided into ▶ IT benefits through simplification and cost avoidance – Fewer databases, reuse of existing IT systems ▶ Staffing savings through trusted interchanges – Elimination of manual handover when quality is proven ▶ Increased revenues due to interoperability improving service quality – Return on experience has shown investment in quality monitoring increases rail’s share ▶ Some long term savings in maintenance efficiencies through improved data – Requires efficient interfaces RU-keeper-ECM

70

Benefits summary

Overall benefit calculation Category Estimated No of each Benefits from lower staffing costs each Benefits from lower IT costs each Total benefits

• ver 5 years

R1 20 1150000 904428 41088560 R2 40 500000 753690 50147600 R3 75 250000 599021 63676537 R4 10 25000 60710 857104 R5 100 60710 6071040 I1 25 675000 55598 18264960 I2 35 175000 46332 7746620 K1 60 250000 67932 19075920 K2 70 175000 56610 16212700 K3 45 175000 48119 10040333 E1 50 262500 13125000 E2 100 87500 8750000 Overall total 142,000,000 113,056,374 255,056,374

71

Cost Benefit Conclusions

▶ Overall Benefits of €250M over 5 years ▶ Benefits are higher for the larger organisations with complex interoperable movements ▶ Benefits through use of common electronic processes will be significant ▶ Significant benefits also through simplification of the IT systems

72

Governance criteria

▶ The legislation requires the industry to co-operate and exchange data ▶ Highly desirable that the industry recognises the benefits and improvements in service and quality ▶ Impartial ▶ Efficient ▶ Participation by interested players ▶ Desirable to monitor quality and resolve poor quality ▶ Manages shared data/ databases ▶ Manages change in an impartial way ▶ Fair cost recovery

73

Governance framework

▶ User driven – Driven by the industry to further rail interests ▶ Impartiality – Interests balanced between roles, railway undertakings, infrastructure managers, keepers etc. large and small ▶ Common tasks – Sets standards – Manages users – Manages changes ▶ Efficiency – Inspired by the conviction that the objective is to run an effective service

74

Governance (1)

Structure (cost recovery on fair ‘open book’ basis)

• association or small not for profit company limited by guarantee
• a general assembly with all RUs, IMs, keepers, ECM and other bodies
• an elected governance group of 12 with key representation from key

players

• a management team to deal with day to day issues

Assembly – present the quality report on the previous year; – present the proposals for the next year covering budgets, changes and improvements; – consider longer term strategic issues; – decide on proposals for improving the fairness of the cost allocation

75

Governance (2)

Governance Group – ensures smooth running of the central parts and makes recommendations for changes and improvements; – publishes a bi-annual report on effectiveness; – ensures fairness with open costing and charging and having regular review of the cost attribution methodology; – tenders and outsources contracts for the central components; – works with ERA on changes and improvements to the specifications – Monitors and actions data quality Management team – handles any day to day issues with the operation of the central services that arise; – maintains systems documentation and prepares user manuals; – handles issues with new users including technical facilitation; – prepares and makes test data available; – administers the financial side, collecting revenues and paying bills; – deals with audit issues.

76

Summary

▶ Key proposals

– Databases

• Replace central WIMO by pointer file to RUs own systems
• Each keeper nominates its RSRD and updates the central index
• Technical data ONLY in RSRDs
• RSRD to be master
• RUs can nominate ISR as their WIMO implementation

– Interfaces

• Use of central pointer files
• Clarification of ‘big picture’

– Phasing

• Basic interchange message and path bid/offer and train running only
• Three phases with benefits for each preserving investments in interchange (H30),

TIS and Raildata ISR – Benefits of the recommendations

• €250M over 5 years of full implementation
• These mainly accrue when implementations are co-ordinated
• Substantial cost avoidance based on reduced IT complexity and reuse of existing

implementations

• Saving in border and handover when fully implemented and REX tells us growth

can be expected

Thank you