High Speed - Inspection

1. High Speed - Inspection Work on the Contiunoustrack monitoring and advanced monitoring for switches & crossings Dr. Gunnar BaumannDirector Infrastructure System Interfaces – I.NVT 8 Gunnar.Baumann@deutschebahn.com www.automain.eu A Joint Research Project funded under the Seventh Framework Programme (FP7) of the European Commission

2. Aims Aims • Unplannedandplanned non-availabilityofthetrackcausedbyfailuresorrestrictionsarecost-drivers in thenetworks. • A predictionoffailuresallows an optimisationofthe instant of time, wheretheworkiseconomical in a larger partofthetrack. Larger maintenancesectionsreducethecostsandprovideusually a betterquality !!! • Switches aremostcriticaldevices in thenetworkconcerningavailabilityandcosts. A reductionoffailuresaredirectnoticeablebythe passenger orthelogisticcompany.

3. Solutions Solutions • Monitoring oftrackalignmentbyregularsheduledtrainsduringoperationtoget „Online“-Information ofthetrack. On thisbasis a prognosisofthedeteriorationofsinglefaultsispossibleand a maintenanceplanningforthelineismoreeconomical. • Monitoring andinspectionofswitches will give an individual informationaboutthe „Health“ of a switch. Maintenance interventionbeforeanyfaultsarepossible, maintenancestaff will beequippedwiththe spare-parts needed. Traffic interruptioncausedbyswitches will bereduced.

4. WP 3 Organisation WP 3 Organisation • WP 3.1 In-Service Measurement (ISM): Measurement ofthetrackalignmentby an in-service freightlocomotive in thedemonstrator. Line will be Rotterdam (Nl) – Dillingen (D). Data processingforfailurepredictionandthedisplaytothemaintenancestaff (MMI). • WP 3.2 Switch: Monitoring andinspectionofswitchesby intelligent sensorsandfailurepredictionby modern algorithmsandthedisplaytothemaintenancestaff (MMI). Demonstrators areswitches in Eslöv (S). • WP 3 Partners: ProRail, Network Rail, Deutsche Bahn, Trafikverket, StruktonRail, Damill, Birmingham Univ., LuleåTekniska Univ., DLR, Mermec, Vossloh

5. WP 3 Organisation Demonstrators DeliveringoftrackrecordingdataDB / MER DeliveryofswitchdataUoB / DAM AlgorithmsforfailurepredictionDLR / UoB Development ofAlgoritmsUoB Development of Maintenance Prog.Stru / LTU Predictionofopt. time forMainten.DLR / UoB Programmingofthe MMIVCSA Workflow Input forWP2, WP4, WP5

6. Advantages of ISM Advantages • Reduction of service breakdown and delays by early detection of defects • Measured data are automatically stored in a maintenance database • Prediction of defect development (more frequently measurements) • Early maintenance planning due to defect/failure prediction (Single defect tamping vs. line tamping) • Verify the quality of repair efforts (close control loop) • Measurement is a “by-product (spin-off) of train operation” • Improvement of maintenance management  Reduction of costs (LCC) • From “Find and Fix” to “Predict and Prevent” • High Availability of the Freight-Backbones of the ports (Target of FP 7 !)

7. Equipment of ISM Continuous monitoring of track geometry on Freight Loko (BR 189) Location with GPS Data transmission by radio Freight train Acceleration sensors on axle bearing Onboard-computer module (IPC) IMU (Gyroscope)

8. Corridor for demonstrator Oreline Rotterdam - Dillingen Dillingen/ Saar Quelle:Verkehrsrundschau.de Foto: A. Seidel

9. Corridor for demonstrator Ore-line Rotterdam - Dillingen Decision was done due totheautomaticcouplingofthelokomotive fixedschedulefortheore-line Foto: bahn007.startbilder.de

10. Processing of the acc.-data Processing oftheaccelerationdata • To gain the vertical alignment from the acceleration data, a double integration has to be carried out. Algorithms were applied to minimize sensor errors. Still, different measurement runs could not easily be compared, see the Fig. left side. Fig: Vertical alignment of several measurement runs before (left) and after (right, zoomed in) filtering Quelle: DLR

11. Defect/Failureprediction Defectgrowthprediction Predictedexceedingofthe Limit value Limit value (11 mm) In-service measurement (ISM) Vertical Deviation oftrackalignment[mm] Inspectionmeasurement(Railab)Mid-October Date ofthepredictedexceedingofthelimitvalue Jul Aug Sep Oct Nov Dec Date

12. Monitoring of defects • Sustainablemaintenance: Vertical Deviation oftrackalignment[mm] Date Track position[km]

13. Switches & Crossings SP 3.2 Monitoring & intelligent self-inspection of switches • Switch inspection with special staff for the signalling and the track part causes a lot of logistic and economical effort • Inspections are carried out in fixed time periods • The condition of the individual switch is not respected • Sudden defects will be undetected until the next inspection or produced a failure • Prediction of development of defects is difficult • Monitoring is different than Self-Inspecting

14. Modular Self-Inspecting Infrastructure – Switches Condition monitoring Automatic inspection Orientated on the fault and it can do: - fault detection: a system is able to detect a fault which is happening - fault diagnosis: a system is able to diagnose the fault - fault prediction: the system is able the predict a fault a certain amount of time before it will happen Focussed on inspecting the asset according to inspection standards and it can: - identify the assets that do not meet the standards - carry out inspections specified in inspection standards - carry out the inspections in a way that satisfies the inspection requirements (e.g. precision of measurement)

15. Modular Self-Inspecting Infrastructure – Switches Condition monitoring Automatic inspection Measures parameters that reveal faults in the system. Analyse the data and identify the faults or predict potential faults. Develop a cost effective system. The drive is to use the smallest number of sensors to identify the largest number of faults. Measure parameters specified by inspection standards. Parameters must be measured must be in line with the standards. The drive is to eliminate the need for maintenance personnel to inspect switches in person.

16. Summary of self inspecting switch: Review of inspection tasks Shape, size, gauge and position of rails Potential solution Laser measurements Visual inspection Potential solution Video train Cracks in rails and crossing Potential solutions ??? Point machine inspection Potential solution Improved CM Switch rail fittings (bolt loosening, cracks) Potential solution ???

17. Architecture of the MMI (Man-Machine-Interface) www.automain.eu A Joint Research Project funded under the Seventh Framework Programme (FP7) of the European Commission

18. MMI data flow Used in WP6 for demonstration Track data (scenario 1) MERMEC/UoB system Maintenance workers Internet Emails, SMS RailML + HTTPS Track data (scenario 2) DLR/DB system RailML + HTTPS MMI Vossloh MTN Task Internet Import RailML files Infrastructure managers Switch data (scenario 3) UoB system RailML + HTTPS RailML + HTTPS Scheduling Tool (WP5)SNCF RailML + HTTPS RailML + HTTPS Switch data (scenario 4) Damill system Switch data (scenario 5) Struckton system

19. MMI architectureUsed in WP6 for demonstration

20. Maintenance taskdefinition The MMI is a “task management system”. The level of data managed by the MMI is a maintenance task. From ISO13374-1:2003 (Condition monitoring and diagnostics of machines — Data processing, communication and presentation — Part 1: General guidelines) the level of data for a maintenance task is defined as a recommended action.

21. Maintenance taskprocess Maintenance taskprocess

22. RailML data standard • www.railml.org • Since 2001: The railML.org Initiative was founded against the background of the chronic difficulty of connecting different railway IT applications. • Its main objective is to enable heterogeneous railway applications to communicate with each other. • Today, the connection of various railway software packages is beset with problems. The purpose of the railML.org Initiative has been to find, discuss and present systematic, XML-based solutions for simplified data exchange between railway applications. • First step in european standardisation for maintenance IT-tools • MERMEC has already provided lists of standard defects and standard measurements.

23. RailML data standard • State of the art in AUTOMAIN • The RailML schema was agreed by all partners • The level of data is “the maintenance task”. Every demonstrator has to decide the way of communication: • The monitoring inspection systems must send a maintenance task to the MMI • The monitoring inspection systems send a failure to the MMI, and a “translation table” validated by the maintenance will match the tasks in relation to the failure produced. • Every system must send a message to confirm the system is alive • A draft of a XML schema exists to understand • The RailML standard will be a data schema file (XSD file). When it is mature (approved by demonstration), it will be proposed to the official RailML organization.

24. Map for Tasks The assets have colours and description for the flag: • No flag if no task • RED Flag: Needing corrective maintenance. • ORANGE Flag: Needing preventative maintenance • For the scheduled maintenance, the asset will be “orange” when it’s time to do it and red when it’s too late. • For the conditional maintenance, the asset will be “orange” when it appears (alarm from a system, expert report...)

25. Specifications • MMI main features • 1 unique access for all the systems monitoring assets (through Internet) • 1 unique level of data : maintenance task • Map with the status of the maintenance tasks for several assets • Table with the status of the maintenance tasks for several assets • Inspection report on site (questionnaire on site to perform the maintenance task ) • MMI administration • Import/export infrastructure RailML data • RailML “maintenance tasks ” exchange between applications • Send emails, SMS, etc... to the maintenance team when a task needs it • Allow confirmation by maintenance to take the work in charge • Monitors the availibility of the systems (message to know if each system is still alive)

26. … 18 months left Thankyou for your attention!