G A 7 7 7 5 1 3 P a g e 1 | 51

Indicator Monitoring for a new railway Paradigm in seamlessly

integrated Cross modal Transport chains – Phase 2

Deliverable D 6.3

Normative input for standardisation of CBM data

structures

Reviewed: (yes/no)

This projecthas received funding from the EuropeanUnion'sHorizon2020 Programme

ResearchandInnovationactionundergrantagreementNo 777513.

Thisdocumentreflectstheviewsoftheauthor(s)anddoesnotnecessarilyreflecttheviewsor

policyoftheEuropeanCommission.Whilsteffortshavebeenmade toensuretheaccuracyand

completenessofthisdocument, the IMPACT-2 consortiumshallnotbeliableforanyerrorsor

omissions,howevercaused.

Project acronym: IMPACT-2

Starting date: Month 16

Duration (in months): 12

Call (part) identifier: H2020-S2RJU-CFM-2017

Grant agreement no: 777513

Due date of deliverable: Month 28

Actual submission date: 15-11-2019 Responsible/Author: Harald Ackermann, Georg Ermer, Tadeusz Szczepaniak;

DB Systemtechnik Dissemination level: PU Status: Draft

Ref. Ares(2020)580129 - 30/01/2020

G A 7 7 7 5 1 3 P a g e 2 | 51

Document history

Revision Date Description

1 16/09/2019 First version of deliverable

2 25/10/2019 Second version of deliverable

3 15/11/2019 Third version of deliverable

Report contributors Name Beneficiary Short Name Details of contribution

Claudio Cavalletti Hitachi Rail STS Deliverable 6.2

Neto Helder CP/ EMEF Additional information and comments

Benoit Guyot SNCF Additional information and comments

G A 7 7 7 5 1 3 P a g e 3 | 51

Table of contents

Abbreviations and acronyms ................................................................................................................... 7

1 Executive summary ......................................................................................................................... 9

2 Background .................................................................................................................................... 10

3 Einleitung ....................................................................................................................................... 11

4 Input for Standardising CBM Data ................................................................................................. 13

4.1 Definition of CBM data ..............................................................................................13

4.2 Overview of CBM data ...............................................................................................14

4.3 Overview regarding input from WP6 ...........................................................................15

4.4 Existing standards ongoing standardization activities ...................................................16

4.5 Digital data model (cyber-physical model)/ Deliverable 6.5............................................17

4.6 Collaboration with other Shift2Rail partners ................................................................18

5 Selection of Standardisation Areas ............................................................................................... 21

5.1 Basic approach to selection ........................................................................................21

5.2 Data flow and format ................................................................................................22

5.2.1 Data flow ....................................................................................................................... 22

5.2.2 Data format ................................................................................................................... 23

5.3 Frequency of data extraction and transfer ...................................................................24

5.4 Physical data transmission from vehicles to ground ......................................................25

5.5 On-board rolling stock software and databases ............................................................26

5.6 Landside data collection and storage ..........................................................................27

5.7 Access and transfer to CBM visualization and application systems ..................................28

5.8 Common data semantics for alignment and interoperability of vehicle condition .............30

6 Standardisation Proposals Regarding Data Structure and Data Designation ............................... 31

6.1 Data structure model ................................................................................................31

6.1.1 Background and objectives ........................................................................................... 31

6.1.2 Basic structure of the "generic data model" ................................................................. 32

6.1.3 Product group structure ................................................................................................ 32

6.1.4 Function group .............................................................................................................. 34

6.1.5 Component part condition and error description ......................................................... 35

6.1.6 Location structure ......................................................................................................... 36

6.1.7 Class-specific codes / examples ..................................................................................... 38

6.1.8 Summary relating to the generic data model ............................................................... 39

G A 7 7 7 5 1 3 P a g e 4 | 51

6.2 Data designation model .............................................................................................40

6.2.1 Background, problem and objectives ............................................................................ 40

6.2.2 Basic structure and function.......................................................................................... 40

6.2.3 Examples of uniform data designation .......................................................................... 42

6.2.4 Summary of the data annotation .................................................................................. 44

6.3 Benefit of standardisation for CBM usage in the rail sector ............................................45

7 Conclusions and data requirements for CBM ............................................................................... 46

8 Future Development ..................................................................................................................... 47

9 Further steps towards standardization ......................................................................................... 48

10 References ................................................................................................................................. 49

11 Annexes ..................................................................................................................................... 50

12 Antitrust statement ................................................................................................................... 51

G A 7 7 7 5 1 3 P a g e 5 | 51

List of tables

Table 1: Summary of the relevant data for the CBM from Deliverable 6.2 .......................................... 15

Table 2: Overview of the existing standards and ongoing standardization activities ........................... 16

Table 3: Contact to other Shift2Rail projects ........................................................................................ 19

Table 4: Product group structure in the generic data model ................................................................ 33

Table 5: Extract from the main product groups in EN 15380-2:2006-06 .............................................. 33

Table 6: Excerpt from subproduct groups in EN 15380-2:2006-06 ....................................................... 33

Table 7: Excerpt from EN 15380-2:2006-06 with examples to which a number is assigned to use them

as sub-subproduct group....................................................................................................................... 33

Table 8: Extract from the ISI component part catalogue ...................................................................... 34

Table 9: Extract from the ISI component part catalogue ...................................................................... 34

Table 10: Precise component part type description according to the generic data model, consisting of

product group and function group ........................................................................................................ 35

Table 11: Component part condition and error description in the generic data model....................... 35

Table 12: Component part conditions as per DB condition catalogue ................................................. 36

Table 13: Location group in the generic data model ............................................................................ 37

Table 14: Mounting position group, mounting positions and installation position based on the generic

data model ............................................................................................................................................ 37

Table 15: Detailed explanation of the example for data designation ................................................... 42

Table 16: The data set "Environment" of the product "Dust sensor" contains among other things the

attribute "DustLevelConcentration" with the data type Float with the unit "g / m³". ......................... 44

Table 17: A sensor of the product "Soft" contains the attribute "IsSensorFailure" with the data type

Boolean - Without unit in the set "Error message" because only "True" or "False" is returned. ......... 44

Table 18: The product "temperature sensor" has among other things the attributes of the "maximum

and minimum room temperature" in the unit "Kelvin" in the data type Float in the data set

"Parameter"........................................................................................................................................... 44

G A 7 7 7 5 1 3 P a g e 6 | 51

List of illustration

Figure 1: Four quadrant model in maintenance ................................................................................... 11

Figure 2: Cyber-physical model taking the "Vehicle monitors vehicle" quadrant by way of example . 12

Figure 3: Cyber-physical model for Vehicle monitors itself .................................................................. 18

Figure 4: cyber physical modell with input from the partners .............................................................. 20

Figure 5: Cyber-physical model added with Support tool and Arrow to it ........................................... 28

Figure 6: Basic structure of the generic data model ............................................................................. 32

Figure 7: Assignment of locations within the generic data model ........................................................ 37

Figure 8: Class code based on the generic data model ......................................................................... 38

Figure 9: Fault codes Class 430 translated into error codes based on the generic data model ........... 39

Figure 10: Operating data Class 430 translated into the generic data model ...................................... 39

G A 7 7 7 5 1 3 P a g e 7 | 51

Abbreviations and acronyms

Abbreviation / acronym

Description

BT Bombardier Transportation

BUS System for data transmission

CCA Condition Based Maintenance

CBM Condition Based Maintenance

CCA Cross Cutting Activities

CCS Control Command and Signaling

CDM Conceptual Data Model

CEN/ CENELEC Comité Européen de Normalisation - European Committee for Standardization

CLC CENELEC

DB Deutsche Bahn

DIN Deutsches Institut für Normung -

EDP electronic data processing

ECM Entity in Charge of Maintenance

EMU Electrical Multiple Unit

EN Europäische Norm – European Standard

ETB Ethernet Train Backbone

EDP Electronic data processing

EuroSpec European Specifications (for railway vehicles) - initiative of several European railway

companies

ISI Integriertes System Instandhaltung - Integrated system of maintenance of the DB

JSON Javascript Object Notation – a programming language

JU Joint Undertaking -

HTTPS Hypertext Transfer Protocol Secure – a Standard for data exchange

IMPACT-2 Indicator Monitoring for a new railway PAradigm in seamlessly integrated Cross modal

Transport chains – Phase 2

IT Information technology

LCC Life Circle Costs

G A 7 7 7 5 1 3 P a g e 8 | 51

Abbreviation / acronym

Description

LRU Last Replaceable Unit

MQTT Message Queuing Telemetry Transport - a Standard for data exchange

MPG Main Product Group – Assignment within the norm EN 15380-2

MVB Main vehicle bus

OPC UA Open Platform Communications Unified Architecture – a Standard for data exchange

S2R Shift2Rail

SPG Sub Product Group – Assignment within the norm EN 15380-2

TBD To Be Done

TCN train communication network

TCMS Train Control & Management System

TD Technical Demonstrator

TRL Technology Rediness Level

UIC International Union of Railways (UIC, French: Union internationale des chemins de fer)

UL Underwriters Laboratories – a global safety certification company

USB Universal Serial Bus

WA Work Area

WP Work Package

WTB Wire Train Bus

XML eXstensible Markup Language – a programming language

G A 7 7 7 5 1 3 P a g e 9 | 51

1 Executive summary

Deliverable 6.4 provides a summary of the work in Task 6.7 Standardisation within the Shift2Rail

project from Work Package 6 – Smart Maintenance.

On the basis of the range of work within WP6, and in collaboration with the specified partner working

groups it was found that standardisation for data-based maintenance, such as CBM or predictive

maintenance, is crucial. Necessary standardisation areas and standardisation solutions for CBM data

are illustrated in the following deliverable.

It must, however, also be stated that it is not worthwhile for individual areas to implement

standardisation, since this kind of standardisation could entail restrictions in the future work, or

standardisation would not bring any benefits. These "negative examples" are also described and

justified.

The data used for maintenance essentially follows the same processing sequence; as such, it is no

longer necessary to differentiate between the four quadrants of CBM. The main problems with

processing were identified in this respect in the area of the structure, the designation and the

classification of the data, as well as with just a single interface to all data.

To this end, two standardisation approaches were presented. These entailed standardising the way in

which the volume of data is structured – data structure model – and standardising the data designation

– data designation model.

Finally, the advantages of standardisation are highlighted, the connections with other deliverables

from WP6, and suggestions provided for the further treatment of this topic.

G A 7 7 7 5 1 3 P a g e 10 | 51

2 Background

This document "Normative input for standardisation of CBM data structures" illustrates the problems

associated with maintenance when processing data and provides initial solutions in this respect.

It examines problems associated with maintaining infrastructure and vehicles in the overall rail system.

From the insights regarding the existing data from Deliverable 6.6 CBM Data Structures, problems,

which occur when processing data for maintenance, were discussed in consultation with projects

outside and within WP6.

In connection with Deliverable 6.5 Smart maintenance concept for infrastructure, rolling stock and

CCS, the basic approaches to data processing were found.

In connection with Deliverable 6.4 Results for rail vehicles, problems with data processing and data

recognition were found.

In connection with the partner working groups [TD3.6 (Dynamic Railway Information Management

System Demonstrator), WA 4.2 (Integrated Mobility), TD 2.9 (Traffic Management System), TD 1.1

(Traction), TD 1.2 (Train Control and Monitoring System), TD 5.1 (Freight Electrification, Brake and

Telematics) and TD 5.3 (Wagon Design)], contradictions with these were excluded and the respective

solution strategies discussed.

In connection with WA 3.2 (Standardisation), ongoing standardisation topics were analysed.

G A 7 7 7 5 1 3 P a g e 11 | 51

3 Einleitung

Ongoing digitalisation and the associated Industry 4.0 are being used in an increasing number of

industrial segments. As such, this also influences the rail sector with associated maintenance of

vehicles and infrastructure. Increasingly, the rail system has access to new public opportunities for

using data and new data analysis systems. These opportunities can be used to gradually transition from

scheduled preventive maintenance to data-based maintenance. As a result, condition-based

maintenance (CBM) can be introduced in an initial step. In a further step, predictive maintenance is

also conceivable, which analyses and processes historic or data available in real time that is relevant

to maintenance, to predict in advance when faults or problems will arise in a system. Data-based

maintenance should save time and resources, and guarantee or even improve safety. The keys to doing

so are, however, the control and reliability of the data.

Irrespective of which area generates data in the rail system and its technical characteristics, the data

follows a similar, shared logic, whereby the same basic requirements are placed on the data.

The data generation process involves four quadrants: vehicle monitors itself, vehicle monitors

infrastructure, infrastructure monitors vehicle, and infrastructure monitors itself - See Figure 1 below.

Figure 1: Four quadrant model in maintenance

To use data for data-based maintenance, the data must, irrespective of in which quadrant the data is

generated, then be transferred to a uniform structure so it can be analysed subsequently. Interim

storage is possible following generation, structuring and/or after the analysis. Subsequently the data

is provided to the maintenance operator by means of a maintenance tool in the form of a work order.

G A 7 7 7 5 1 3 P a g e 12 | 51

This data flow has already been considered in Deliverable 6.5 for the flow of information as a cyber-

physical model and is again copied for data in this deliverable. Figure 2 below shows the information

flow from Deliverable 6.5; more detailed information follows in section 4.5:

Figure 2: Cyber-physical model taking the "Vehicle monitors vehicle" quadrant by way of example

Although the process is very similar in all rail areas, but also within a quadrant, there are only very few

end-to-end harmonised solutions. As such, urgent harmonisation is required here to achieve

compatibility between various solutions and to prevent additional work as a result. The main problem

in this respect is finding the right data, understanding that data and assigning it accordingly.

As a partial solution to these problems, this deliverable helps find a solution for standardising data in

all rail areas and to manage, understand and process data better in future.

G A 7 7 7 5 1 3 P a g e 13 | 51

4 Input for Standardising CBM Data

4.1 Definition of CBM data At the time of publication of this document, there is still no official definition of the term CBM data

(CBM = condition-based maintenance). Since this term, however, is constantly being used in relation

to maintenance and, in turn, to maintenance data, a definition initially follows within this deliverable:

CBM data is taken to mean hereinafter all available data (e.g. raw data, error messages, process data,

condition logs, sensor data) of a vehicle or other asset, which can be used to assess the condition of

those assets. In addition, data is also included that has already been processed, e.g. from the

associated analysis program, i.e. all data that reflects the condition of an asset across the entire process

chain.

The following are examples of CBM data from Deliverable 6.4:

• raw sensor signals (analogue and digital) from individual measuring devices and actuators

• process & state variables incl. message and events data from TCN - train communication

network (incl. MVB, WTB, ETB and periphery BUS)

• operational parameters displayed or/and recorded on the vehicle (central and local displays)

• diagnostic messages displayed or/and recorded on the vehicle (central and local displays)

• records of diagnostic messages and parameters transmitted on the landside (i.e. on-board

diagnostic and data transmission)

G A 7 7 7 5 1 3 P a g e 14 | 51

4.2 Overview of CBM data In addition to the hitherto classic methods of assessing the condition of component parts, components

and whole assets using conventional monitoring (regular measurements, testing and visual inspection,

etc.), the targeted monitoring of CBM data provides another option for permanent monitoring of

assets and derivation of individual maintenance requirements.

Since to date there are no adequate recording and processing standards, most projects (e.g.

information on a vehicle class, a classification yard or a barrier system) were programmed and created

independently of each other. As a result, existing data provided and available on the assets have

different data formats, structure etc. in the entire rail sector. The same data is also read out, stored,

transmitted, analysed and processed further individually in each case.

The interfaces of the various assets for data processing are in some cases incompatible or prove very

time-consuming to design so that the same processing and analysis software can process them.

Moreover, the processing systems, in their current configuration, are structured differently in each

company with their interface to the database for the maintenance tasks and accordingly fitted with

different interfaces.

The structure of the data or the encoding with each asset is also different.

Collaboration between various companies or various projects proves difficult with the aforementioned

different basic requirements and in any case entails a huge amount of additional work.

The goal must be to find common solutions, based on the current partial solutions from all the project

partners and on the existing overarching standards in IT. For this reason it is important to first examine

these standards.

G A 7 7 7 5 1 3 P a g e 15 | 51

4.3 Overview regarding input from WP6 The analyses regarding Deliverable 6.3 should be based on the results of Deliverable 6.2.

Table 1 from the summary of Deliverable 6.2 is shown below, which provides a brief overview of the

results. Deliverable 6.2 analysed over 100 different use cases within Shift2Rail. As a result, it was

recognised that the data and how that data is processed differ greatly.

Table 1: Summary of the relevant data for the CBM from Deliverable 6.2

Quadrant Units Frequency Format Protocol

Infrastructure/

infrastructure

35 TBD/ Configurable XML or

JSON

OPC UA, TCP/IP

Infrastructure

monitors vehicle

15 After every train run XML,

JSON, jpg/ TBD

TBD/

OPC UA, TCP/IP

Vehicle monitors

infrastructure

8 Each day/ After every

train run

Binary, TBD G4, LTE, rsync,

TBD

Vehicle monitors

vehicle

50 Permanent, 60,000 km,

every 15 min.

JSON, MVB TBD,

dat, JSON,

TBD/ Mobile

Network

Further, input from WP6 was provided with the aid of a survey and discussed during the work package

meetings; even more differences were found in this respect, such as in the data structure and data

processing. This helped find the suitable approaches to standardisation, as described in section 6.

G A 7 7 7 5 1 3 P a g e 16 | 51

4.4 Existing standards ongoing standardization activities There are already numerous standards and ongoing standardisation activities relating to CBM data.

Table 2 below illustrates selected important standards and standardisation activities. Standardisation

approaches from the results of the work within Shift2Rail are illustrated in WA 3.2.

Table 2: Overview of the existing standards and ongoing standardization activities

Standard Beschreibung Aktivität

IEC61375 series - Electronic railway equipment - Train communication network (TCN)

The standard shows the architecture of data communication systems (architecture of a communication system for the data communication between vehicles of the open trains, the data communication within the vehicles and the data communication from train to the ground) in trains.

active

UIC 438-3, Identification marking for tractive stockyes

Illustrates the system used to identify rail vehicles. In this way, the vehicle can be assigned uniquely to a class, a country and a company, and it can be identified which type of vehicle is involved.

active

UIC 556 - Information transmission in the train (train bus)

The leaflet shows the general conditions that the data transmission equipment of RIC-compatible passenger trains must fulfil.

active

UIC 557 – Diagnostic on passenger rolling stock

The leaflet describes the functionality of the various diagnosis systems in rail vehicles.

active

UIC 559 - Specification "Diagnostic Data Transmission" from railway vehicles

The present document specifies a common content and format for "diagnostic data transmission" from railway vehicles, as well as basic processing structures of data in XML.

active

UL 4600 - Standard for Safety for the Evaluation of Autonomous Products

"UL 4600 evaluates whether autonomous systems can safely perform their intended functions without human intervention, based on their current state and sensing of their operating environment. The standard also covers the reliability of hardware and software necessary for machine learning, sensing the operating environment, and other safety aspects of autonomy."

In progress

EN 15380 - Railway applications - Designation system for railway vehicles

The standard series shows various identification systems according to which rail vehicle components are structured. This deliverable refers to Part 2 from 2006 (Product groups).

active

LinX4Rail - Conceputal data model

The conceptual data model will be developed in a future Shift2Rail group and cover a data model for all areas of the rail system. It takes place in the S2R project LinX4Rail.

In progress

railML - Railway Markup Language

A data structure for rail transport based on XML. The current version 3.1 was released in February 2019. The standard is licensed under CC-BY-NC-ND.

active

EN 15016-4 - Technical drawings - Railway applications - Part 4: Data exchange; German version

The standard illustrates how data relating to bills of materials and technical drawings must be transferred so that this data is generally understandable. Security during transmission is also examined.

Revision planned

G A 7 7 7 5 1 3 P a g e 17 | 51

EN 17023 - Railway applications – Railway vehicle maintenance – Creation and modification of maintenance plan

The standard shows the processes for creating and modifying maintenance plans for rail vehicles.

active

EULYNX As part of the ERA-funded program EULYNX a uniform standard for modular interlocking technology should be created.

In progress

ITS (Intelligent Transport Systems)

The ITS project run by ISO/TC 204 – WG8 is a standardisation of the information, communication and control systems in the transportation sector (excluding vehicle control systems).

In progress

4.5 Digital data model (cyber-physical model)/ Deliverable 6.5 The steps within the entire CBM process from data acquisition on the asset to deriving rules for

maintenance should apply in the entire rail system. As a result, this paves the way for cross-system

solutions for CBM applications for all assets. The steps were developed in Deliverable 6.5 "Smart

Maintenance System" and based on the necessary steps to provide practical maintenance in future for

all assets.

It should be shown in this deliverable how cross-system solutions can be supported through

standardisation relating to CBM data.

Figure 3 below shows the cyber-physical model for the quadrant "Vehicle monitors itself". This model

is, however, equally applicable to all four quadrants. This process essentially includes the following

steps:

1. Data acquisition on the asset

2. Handover interface

3. Transfer

4. Storage

5. Data analysis with pattern recognition

6. Rules for maintenance

G A 7 7 7 5 1 3 P a g e 18 | 51

Figure 3: Cyber-physical model for Vehicle monitors itself

This cyber-physical model initially shows the data flow for the vehicle asset. It is, however, basically

applicable to all assets in the rail sector in all four quadrants with the aforementioned process steps 1

to 6. This results in the need to develop uniform, harmonised solutions for the technical

implementation of these process steps.

The current situation is, however, characterised by the existence at present of various, custom

solutions for maintenance to cover the subareas of the cyber-physical model. Often these solutions

have been developed directly for a certain use case, making them incompatible with other solutions.

This makes it more difficult to develop an overall system for maintenance, since there are already

major differences even with similar subsystems, such as two different vehicle classes. This issue arose

with the work relating to Deliverable 6.4 and is explained in greater detail there.

4.6 Collaboration with other Shift2Rail partners The deliverable requires close cross-Shift2Rail collaboration with various partner IPs/ TDs.

The collaboration and the key results/statements are summarised in Table 3.

G A 7 7 7 5 1 3 P a g e 19 | 51

Table 3: Contact to other Shift2Rail projects

Ref

ere

nce

to

D

eliv

erab

le/

Dra

ft

- The

mo

st D

eliv

erab

les

of

this

w

ork

pac

kage

- Stan

dar

dis

atio

n

Ro

llin

g D

evel

op

men

t P

lan

D7

.1 O

pen

dat

a: a

rev

iew

of

the

stat

e-o

f-th

e-

art

D7

.2 R

equ

irem

ents

an

alys

is a

nd

Def

init

ion

of

stan

dar

d g

uid

elin

e D

7.3

Op

en s

tan

dar

d in

terf

ace

pro

toty

pe

D7

.4 P

roto

typ

e V

alid

atio

n

- - Del

iver

able

6.2

– C

BM

Dat

a st

ruct

ure

s

- -

Co

nta

ct P

erso

n

Ecka

rt M

eesm

ann

(D

B)

Stef

an T

esar

DB

,

Ro

lan

d K

uh

n B

T

Lau

ren

t Sc

hm

itt

SNC

F, Y

ing

Lösc

hel

DB

Gu

lia V

ign

ola

H

itac

hi,

Mar

io

Mik

usc

hek

D

B

Mar

io

Mik

usc

hek

D

B

Cla

ud

io

Cav

alet

ti

Hit

ach

i

Ro

lan

d K

uh

n B

T

Ren

ato

R

od

rige

s D

B

Stat

emen

ts, r

esu

lts,

inp

ut

for

the

del

iver

able

Del

iver

able

ap

pro

ach

es a

re

sup

po

rted

Su

pp

ort

s d

eliv

erab

le a

pp

roac

hes

. P

rovi

des

pla

tfo

rm, f

or

dat

a

tran

sfer

No

te c

olla

bo

rati

on

wit

h C

DM

! U

niq

ue

list

of

req

uir

emen

ts

Act

ivit

y fr

om

oth

er

stan

dar

dis

atio

n t

op

ics.

No

sim

ilar

app

roac

hes

els

ewh

ere

Sup

po

rts

app

roac

hes

, th

ey u

se

the

sam

e tr

ansf

er p

roto

col a

s in

sect

ion

6.2

Sup

po

rts

del

iver

able

ap

pro

ach

es

Sup

po

rts

del

iver

able

ap

pro

ach

es

Hig

h d

ive

rsit

y o

f th

e e

xist

ing

CB

M d

ata

No

te c

olla

bo

rati

on

wit

h C

DM

! U

niq

ue

list

of

req

uir

emen

ts

Inp

ut

of

the

del

iver

able

to

CD

M

Inh

alt

TD/W

A

Trac

tio

n (

PIN

TA)

Trai

n c

on

tro

l an

d

mo

nit

ori

ng

syst

em

(CO

NN

ECTA

)

Traf

fic

Man

agem

ent

Syst

em

Stan

dar

dis

atio

n

dyn

amic

rai

lway

in

form

atio

n

man

agem

ent

syst

em

dem

on

stra

tor

Frei

ght

Elec

trif

icat

ion

, B

rake

an

d T

ele

mat

ics

Wag

gon

des

ign

Info

rmat

ion

id

enti

fica

tio

n

Inte

grat

ed m

ob

ility

Co

nce

ptu

al d

ata

mo

del

Co

op

erat

ion

TD 1

.1

TD: 1

.2

TD 2

.9

WA

3.2

TD: 3

.6

TD 5

.1

TD 5

.3

TD 6

.6

WA

4.2

CD

M

Essentially all project partners have agreed to the deliverable ideas. Some supplements were also

highlighted. No partner has rejected the content, most of them believe the approaches (see section 6)

are important and agree to the standardisation proposals.

G A 7 7 7 5 1 3 P a g e 20 | 51

The following Figure 4 shows on the basis of the cyber-physical model where interfaces between this

deliverable and the various partner IPs/ TDs were identified as part of the collaboration.

Figu

re 4

: cyb

er p

hys

ical

mo

del

l wit

h in

pu

t fr

om

th

e p

artn

ers

G A 7 7 7 5 1 3 P a g e 21 | 51

5 Selection of Standardisation Areas

5.1 Basic approach to selection As the aforementioned actual state highlights, there is a major need for action to harmonise and

standardise CBM data along the cyber-physical model.

Based on the project requirements in WP6, standardisation regarding CBM data is required in

particular for industry-wide, uniform data semantics and interoperability and the following areas must

at least be investigated as part of this further analysis:

· data flow and format

· frequency of data extraction and transfer

· physical data transmission from vehicles to ground

· on-board rolling stock software and databases

· landside data collection and storage

· access and transfer to CBM visualisation and application systems

Initial information on further processing, data analysis and other data processing is highlighted in this

deliverable. Since, however, there is no working overall system at present, which uses the entire data

flow process, this can only be illustrated here on the basis of examples.

When determining the areas to be standardised, it must also be borne in mind that there are areas in

which standardisation is not worthwhile or possible. This is also illustrated below.

An initial selection of the standardisation areas has already been made as part of the "Scope Definition

WP6 (Deliverable 6.1)" with various experts. To this end, agreement was reached with:

• experts within the working group WP6

• partner working groups within S2R (as per project requirements specification)

• experts outside S2R

As a result of this consultation between experts, it was worked out which of the aforementioned areas

should be standardised for CBM data. At the same time, however, it was also shown in which areas

standardisation is not necessary or even undesirable.

The expert opinions for the individual areas of the CBM data are illustrated below.

G A 7 7 7 5 1 3 P a g e 22 | 51

5.2 Data flow and format

5.2.1 Data flow

The data flow governs the transfer of data from one EDP device to another. The transfer is completed

via various interfaces (see section 5.3) such as USB interface, Wi-Fi or the mobile internet.

The standards regarding these transfers are stipulated outside the rail sector, such as by the

telecommunications companies. Within these transfers, the communication is made between the EDP

devices using transfer protocols; the transfers via the respective interface, however, with the

respective interface protocol.

The customary transfer protocols are HTTPS, MQTT and OPC UA, apart from other protocols. HTTPS is

better suited to transferring small volumes of data for real-time monitoring, the MQTT or OPC UA, by

contrast, can be used more effectively to transfer large volumes of data, to transfer for example, the

data storage unit containing the "historic data" from the day during the vehicle idle times.

The data flow is therefore defined outside the rail sector. The type of transfer is, in turn, dependent

on the use case (mobile data or USB; lots of data at once or only what is absolutely necessary); as a

result there should be no restriction and, in turn, no standardisation to one type of data flow in this

area.

Conclusion: standardisation not desirable

G A 7 7 7 5 1 3 P a g e 23 | 51

5.2.2 Data format

The analysis of the actual situation has shown that there are generally valid formats that are

independent of the rail system (e.g. XML or JSON). These formats are designed outside the rail sector

and, among other things, within the rail sector in wide-ranging ways.

The analyses as part of Deliverable 6.2 did not result in any uniform application of these standards.

Furthermore, it was found in the expert discussions that standardisation in this area is not worthwhile,

since there have hitherto been no problems with the file format.

On the contrary, any standardisation of the available standards would restrict the usability for various

use cases. Moreover, it must be assumed that these standards will continue to be developed very

quickly so that current file formats could be deemed outmoded in a few years.

The analysis has shown that the following formats were predominantly used:

XML: eXtensible Markup Language: a static format which can be adapted simply to the particular use

case. It allows for platform-independent data exchange. XML separates content from its structure and

presentation; as a result, information such as text, graphics and audio recordings can be easily

transferred. [1]

JSON: (Javascript Object Notation): is a text-based, language-independent, human-readable data

interchange format used for representing simple data structures and objects in web browser-based

code. It is easy to parse (analysing of data structures) and generate for machines. JSON is simply a way

to represent data structures, as opposed to a full markup language. JSON documents are relatively

lightweight and are rapidly executed on a web server. [2]

A format is, however, often not defined (see Table 1). If other activities are analysed, for instance in

the CDM group, it can be found that Rail-ML (an XML format modified for rail) is also often represented,

but which is barely used, if at all, as part of maintenance or at those points where data is generated

for maintenance.

The various file formats have so far not caused any problems in data processing, since they were always

programmed openly to date and any other format for further processing the data can be created

quickly using a conversion tool. It is, however, important that the formats do not entail any encrypted

formats, but open formats, as otherwise conversion or simple readability is not ensured. As such, a

standardisation approach is not required within this deliverable. The use of open formats is all that is

important.

Conclusion: standardisation not desirable

G A 7 7 7 5 1 3 P a g e 24 | 51

5.3 Frequency of data extraction and transfer A distinction must be drawn between the frequency of the data extraction and the frequency of the

data transfer. While the data transfer depends on the type of monitoring and the further processing

of the CBM data, the data extraction is dependent on the component part being monitored in each

case. In any case it therefore depends on the relevant use case.

Two examples in this respect:

Monitoring the rotational speed requires a high sampling rate, irrespective of how this information is

further processed, since the wheel may rotate several times a second. Short-term changes in the

rotational speed should also be expected (say through braking or acceleration).

By contrast, the monitoring of room temperature requires a low sampling rate. Even with a high heat

output (e.g. by stabling in the sun or an electric heater) it is unlikely that the room temperature will

fluctuate wildly within a second. Here a sampling rate of a few seconds to a few minutes would be

sufficient.

The frequency of the data transfer depends on the particular user's boundary conditions. These include

the storage capacity on the vehicle, the transfer possibilities during operation, the type of data to be

transferred, the type of analysis and the type of monitoring. With regard to the monitoring type, these

include real-time monitoring, monitoring only in critical moments, i.e. seamless monitoring overall or

partial monitoring.

Since every user must decide for themselves which extraction data they require in the particular use

case, it is neither worthwhile to impose a restriction by standardising the frequency of data extraction,

nor to impose standardisation for the frequency of the data transfer.

Conclusion: standardisation not desirable

G A 7 7 7 5 1 3 P a g e 25 | 51

5.4 Physical data transmission from vehicles to ground In connection with CBM data you need to analyse in a single analysis unit the transfer from vehicles to

the landside in the case of physical data transmission, as well as the transmission of the data of an

infrastructure asset, such as decentralised fitted switch.

Basically there is the option of transferring data wirelessly (e.g. Wi-Fi, mobile network), wired (e.g. via

Ethernet) or using a storage medium (e.g. USB stick or laptop). This, however, depends in turn on the

company and intended purpose. The standards for transferring and the associated transfer protocols

are stipulated by the respective interface operator, e.g. the mobile communications network

companies, and as a result do not need to be standardised at this point.

In the context of the data transfer, however, it is also important to note the provisioning of the data.

At present the situation is such that the central MVB (Main Vehicle Bus) can pick off lots of data. This,

however, does not apply to all data; for instance you can only read out on the MVB whether the doors

have been released in a local transport DB double-decker carriage so the passenger can open them or

not. The information relevant to maintenance, such as door opening and closure times, and number

of the load cycles are only output by the door control unit to the door and are not normally readable

as such. (Bombardier wrote a script for Deliverable 6.4 specifically to read out this data; this script can

then be used to read out this data via the MVB).

It must therefore be determined that there are different sources for CBM data with a different

structure and architecture in the 'vehicle' asset alone.

The necessary centralisation of the data as well as the creation of a uniform data architecture for

vehicles and the provisioning of data on just one standardised interface, is implemented by the project

TD 1.2 CONNECTA and does not need to be pursued further in WP6. This standardisation implemented

through TD 1.2 CONNECTA is a key requirement for the further standardisation of CBM data.

There is currently no known project that defines a central data interface for all four quadrants.

Conclusion: standardisation not desirable

G A 7 7 7 5 1 3 P a g e 26 | 51

5.5 On-board rolling stock software and databases The on-board rolling stock software and databases of a vehicle do not constitute a substantial issue for

maintenance, since these are mainly only created and processed by the vehicle manufacturer. The

vehicle software is usually the property of the manufacturer. It is subject to constant change, especially

if this involves procuring new vehicles (as opposed to older vehicles), these often have state-of-the-art

software.

More important than the on-board software for the user is the interface on which the user is provided

with their data in a suitable form. The underlying structure must be able to supply this data suitably,

depending on how the user would like to access this data. The structure (database) that underlies the

storage and management, and management and storage of data itself is of secondary interest. The

provisioning of the data should in future run over a centralised interface only. This provides simple

access to the data. This is developed, as shown in section 5.3 by TD 1.2 "CONNECTA" and deemed

necessary for future CBM measures.

Conclusion: standardisation not desirable.

G A 7 7 7 5 1 3 P a g e 27 | 51

5.6 Landside data collection and storage Data acquisition, storage and access

To clarify the issue of data storage, you first need to clarify who the data belongs to. The vehicle

manufacturer produces the software that generates the data. The data helps the manufacturer

develop future vehicles and improve current vehicles.

The vehicle keeper generally owns the vehicle or the rights to use this vehicle. The data, which the

vehicle creates, originated based on its use cases associated with its ownership. The keeper requires

this data for maintenance to rectify or prevent problems.

There is currently no general arrangement regarding ownership of the data. It must be regulated

separately each time in the contract or governed centrally in future by law.

If user-based data collection (regardless of whether manufacturer or vehicle keeper) is assumed, a

different format is required for the collection and storage of data depending on the use case. The data

tends to be acquired via sensors that generate an analogue or digital signal. A device then processes

this signal. This data is then either processed or sent for further processing to a suitable device

(automatically or also manually). Depending on the sensor, different data is created during the

acquisition and various processing steps exist depending on the analysis method. As such,

standardisation is not possible here from a current standpoint.

The data tends to be stored on data servers or cloud solutions, but can also be stored on a USB stick

or computer in the individual instance.

Another possible future storage method could be Europe-wide centralised storage. This would mean

that the data would be available to everybody and created by everybody. So it be could be possible for

each manufacturer and user to consult straightaway problems affecting a class to prevent such

problems in future.

Centralised data management for storing and sorting data within a work area then constitutes a

necessary measure. It must also be possible to set up a link for third parties to a storage location, where

necessary with partial anonymisation of data.

These different technical solutions, whether centrally or company-specific or also storage quantity and

transfer mode, obviously depend on the respective use case. Hence standardisation is not worthwhile

at present, since this would result in unnecessary restrictions.

Conclusion: standardisation not desirable

G A 7 7 7 5 1 3 P a g e 28 | 51

5.7 Access and transfer to CBM visualization and application systems

Figure 5: Cyber-physical model added with Support tool and Arrow to it

CBM visualisation and application systems are systems for monitoring individual components of the

asset, maintenance databases and maintenance management tools (e.g. SAP) or also systems for

monitoring the entire cyber-physical model process. This therefore involves maintenance

management systems or support tools.

The information for these systems comes from a storage system (database) where the data is buffered

or also stored long term, or from direct inputs from the Maintenance Operator itself or from analysis

systems.

There are disparate end users that use the maintenance management systems and support tools. Apart

from maintenance, these end users may also be involved in engineering for the assets, in parts

procurement or also in operating the assets. In the maintenance alone, a distinction is essentially

drawn between the end users based on their task definition in the maintenance process. For instance,

the end user "ECM 2" (responsible for maintenance specifications and fleet monitoring) requires

different information from the CBM process than the end user ECM 4 (responsible for maintenance

implementation). These different requirements of end users call for custom visualisation solutions.

According to the particular requirements relating to the particular task in maintenance, the

requirements from the particular company in relation to maintenance and the different maintenance

management tools in the companies, the data is then accessed differently or sent straight to the

systems.

G A 7 7 7 5 1 3 P a g e 29 | 51

To illustrate these tasks accordingly in the cyber-physical model, the model needs to be extended to

include the support tool that indicates the particular information to the particular maintenance

functions and the arrow that shows that information flows from the memory to the maintenance

management system and support tool, see Figure 5.

The different systems in the maintenance functions and the different requirements placed on these

mean that at present it does not make sense to define a uniform standard for access and transfer.

Conclusion: standardisation not desirable

G A 7 7 7 5 1 3 P a g e 30 | 51

5.8 Common data semantics for alignment and interoperability of vehicle condition Basically the processing of data and information, as described at the start, always follows a similar

pattern (see section 4.5). Data is collected, transferred, processed, stored and provided for the user.

This is done at the moment in respective custom solutions so that each solution, regardless of whether

infrastructure or vehicle and regardless of whether from the same manufacturer or multiple

manufacturers, constitutes a standalone solution. As a result, everyone faces the same problem here.

So a solution needs to be found where all work and task areas associated with maintenance-related

areas are also involved, or can get involved:

• TD 1.1 (Traction),

• TD 1.2 (Train control and monitoring system),

• TD 2.9 (Traffic Management System),

• TD 3.6 (Dynamic railway information management system demonstrator),

• WA 4.2 (Integrated mobility),

• TD 5.1 (Freight Electrification, Brake and Telematics),

• TD 5.3 (Wagon design),

• WP6 partners (see appendix "Survey").

The key problems relating to the data are currently associated with access to the data on an interface,

the readability of the data, the assignment of the data to a corresponding component and the

interpretation of the data relating to a condition or problem.

As already described in section 5.4 the necessary centralisation of the data as well as the creation of a

uniform data architecture for vehicles and the provisioning of data on just one standardised interface

is done by the TD 1.2 (Connecta) project. This resolves the problem of uniform access to the data.

The standardisation of the data itself is not dealt with by the TD 1.2 CONNECTA project. This is,

however, essential for the efficient, effective use of the CBM data in maintenance and effects in

particular readability, traceability and assignment to components and errors as well as the

interpretation of data.

This statement is also confirmed by the experience in the subprojects of Deliverable 6.4 CBM results

for rail vehicles.

Conclusion: standardisation of the data structure and the data designation including semantics.

G A 7 7 7 5 1 3 P a g e 31 | 51

6 Standardisation Proposals Regarding Data Structure and

Data Designation

As a result of the analysis of the standardisation areas required in the individual tasks in WP 6 Task 6.7, an actual standardisation requirement exists primarily in the following areas:

- Data structure (structuring of large volumes of data)

- Data designation, content and semantics of the individual data set

The following takes a closer look at this issue and two possible solutions to these problems are illustrated.

6.1 Data structure model

6.1.1 Background and objectives

In the current state, there are numerous different types of data with virtually all assets. This will be

explained below taking the vehicle by way of example. Here, data can be picked off directly by

components or subsystems via the MVB (Main Vehicle Bus). In the case of existing vehicles, this data

is normally not designed or only designed to a small degree for use in maintenance. Apart from the

actual access to the data (technical and legal), above all the understanding of the data and its clear

assignment to individual components, component parts and conditions of the affected assets is

therefore particularly important.

An initial step to solving this problem is a predefined, standardised structure of data with clear

reference to the structure of the considered assets.

Given the particular importance of this issue for vehicles, the structure model to be standardised

(hereinafter referred to as "generic data model") is basically presented taking vehicles by way of

example and explained in detail. Transferring this approach and structure logic to other assets in the

rail system is worthwhile.

Railway undertakings normally operate vehicles from various manufacturers, in different expansion

stages and with different hardware and software versions.

Each vehicle has its own manufacturer-specific codes and signals for conditions and error messages as

well as commands and data structures. In addition, changes are also often made within a class with

different as-delivered versions (e.g. series/ software versions). This makes it difficult to deal with

existing data or to compare it.

To implement data-based maintenance, such as CBM or predictive maintenance, the access to,

allocation of and the understanding of the available data already poses a major problem for the

aforementioned reasons.

The objective must therefore be to create a uniform structure model of the available data. This uniform

data structure should meet the following requirements:

• uniform mapping of the particular vehicle irrespective of the manufacturer

• simple structure for supporting end users (maintenance, engineering and operation)

• consideration of existing structure standards for assets (vehicles)

G A 7 7 7 5 1 3 P a g e 32 | 51

The information in chapter 6.1 are based on the DB Systemtechnik Project for the maintenance of the

DB Class 430. It is currently at the DB work in progress. Contact person is Jan Eichhorn from DB

Systemtechnik.

6.1.2 Basic structure of the "generic data model"

The task of the generic data model is to assign the existing signals to the components, conditions and

mounting positions. This structuring is designed from a user perspective as simply and understandably

as possible for maintenance purposes on the basis of a well-known structure model as per EN 15380-

2.

The vehicle structuring illustrated in EN 15380-2 is used as the basis for the further necessary detailing

of the structure model for use in maintenance. To clearly assign the data and signals, further

subdivision levels with the following information are necessary:

• Further subdivision of the vehicle down to the smallest maintenance unit to be analysed

• Condition description of component part/ function

• Position of the individual component part

The basic structure is shown below in Figure 6

Figure 6: Basic structure of the generic data model

For rail vehicles the product group structure in EN 15380-2 (2006-06) is illustrated. For the remaining

subdivision, a new standard must be drafted.

To be able to precisely assign a product in accordance with the generic data model, subareas must first

be analysed.

6.1.3 Product group structure

The product group structure as per EN 15380-2 forms the existing standard in the generic data model

and so constitutes the central support. The following areas of the data model should form the new

standard. The existing central support and the new standards are again illustrated by There are already

numerous standards and ongoing standardisation activities relating to CBM data. Table 2 below

illustrates selected important standards and standardisation activities. Standardisation approaches

from the results of the work within Shift2Rail are illustrated in WA 3.2.

Table 2.

G A 7 7 7 5 1 3 P a g e 33 | 51

Table 4: Product group structure in the generic data model

EN 15380-2 divides component parts into two different groups to specify them. There are different

main product groups (MPG) to which subproduct groups (SPG) are assigned respectively. In the

aforementioned standard, examples are also assigned to the subproduct group. They are also copied

for the generic data model as sub-subproduct group (SSPG). This is again illustrated below with extracts

from EN 15380-2 in Table 5, Table 6 and Table 7.

Table 5: Extract from the main product groups in EN 15380-2:2006-06

MPG Name of MPG

F Power system, drive unit

L Air conditioning

M Ancillary operating equipment

N Doors, entrances

Table 6: Excerpt from subproduct groups in EN 15380-2:2006-06

MPG MPG Name SPG Unterproduktgruppe Name

M Ancillary operating equipment A Ancillary operating equipment

M Ancillary operating equipment B Sanding equipment

M Ancillary operating equipment C Lubricating equipment

N Doors, entrances A Doors, entrances

N Doors, entrances B External doors

N Doors, entrances D Entrances, steps (not inside)

Table 7: Excerpt from EN 15380-2:2006-06 with examples to which a number is assigned to use them as sub-subproduct group.

MPG SBG Number Example

N A 001 Emergency switch

N A 002 Lock layout plan

N B 001 Connecting door

G A 7 7 7 5 1 3 P a g e 34 | 51

N B 005 Door panelling

N B 011 Entrance door

N B 015 Pivot bearing

N B 018 Sliding door

6.1.4 Function group

Since the product group structure in EN 15380-2 is not specific enough to determine a component part

type unmistakably, the generic data model needs to be supplemented with a functional group. In the

example shown this is done on the basis of the DB ISI catalogue. As part of future standardisation this

component part catalogue must be harmonised and updated centrally.

Table 8: Extract from the ISI component part catalogue

DB has been using the ISI component part catalogue since 2002 as the function catalogue. It contains

a list of general component part designations and categorisation of the component parts, thus

providing the basis for standardising maintenance work and is always kept up to date. An extract is

shown below.

Table 9: Extract from the ISI component part catalogue

Category code

Category name Component part type code

Component part type name

Component part code

Component part name

M M parts general BE Control element ZMD Door actuation inside

E E parts general EC Electrical device ZWS Door blocking control unit

M M parts general VM Fastener M ZWT Door handle plug connection

N M parts special TE Door element ZHD Driver's cab entry door

S Special categories SE System/device FMJ Locking system/unit

F E parts special SL Switch BRV Locking control switch

N M parts special SS Lock DHR External emergency unlocking device

M M parts general BE Control element YQN Emergency release outside

N M parts special SS Lock JJE Pneumatic locking

F E parts special TA Button GPT Stop call button

G A 7 7 7 5 1 3 P a g e 35 | 51

M part = Mechanical component part; N part = Special mechanical component part; E part = Electrical

component part; F part = Special electrical component part; S part = Special category

Apart from DB's ISI catalogue there are also other catalogues that map the component part functions,

such as EN 15380-4:2013-05 "Railway applications – Classification system for railway vehicles – Part 4:

Function groups". Compared with the ISI catalogue this is, however, very general and is not

permanently updated, meaning that newer component parts are not listed.

The product group as per EN 15380-2 and the function group as per the ISI component part group are

required together to develop a code for just one component part type within the generic data model.

This is described below in Table 10.

Table 10: Precise component part type description according to the generic data model, consisting of product group and function group

6.1.5 Component part condition and error description

Apart from the component part, the condition or an existing problem must also be assigned to the

generic data model code. This happens in the next step.

Table 11: Component part condition and error description in the generic data model

The analysis of the error signals, bus signals and standardised damage conditions gave rise at DB to a

condition catalogue, which includes the most common errors. With the aid of the condition catalogue,

damage and damage conditions can be assigned clearly. In this way, damage warnings can already be

G A 7 7 7 5 1 3 P a g e 36 | 51

sent to the maintenance depot. The conditions were already categorised and extended to include an

error description.

They are required in the generic data model to display the condition to Maintenance, in addition to

the specific component part. A few errors and conditions with assigned condition descriptions are

shown below by way of example (see Table 12).

Since each condition code illustrates just one defined condition, it is particularly important here that

the same notation and same assignment of a condition to a code are used on a cross-manufacturer

basis. Otherwise, you would again have huge problems in maintenance if two manufacturers use the

same code for different conditions.

Table 12: Component part conditions as per DB condition catalogue

Signal type Condition code Condition description/ unit

Damage condition 10-004 Deformed

Damage condition 10-005 Flat spots

Damage condition 10-006 NA

Subjective symptoms 11-001 Noise

Subjective symptoms 11-002 Temperature too hot/too cold (damage

warning, subjective feel)

Error message 13-002 Reduced function/no function

Error message 13-004 Does not open/does not close (mechanical)

Error message 13-005 Phase-to-phase short circuit

Error message 13-006 Capacity limit reached (full)

Control command 14-001 Switch on/switch off

Control command 14-002 Couple/separate vehicles

Configuration parameter 15-001 Threshold, maximum

Configuration parameter 15-003 Condition fulfilled yes / no

Functional condition 22-001 Switched on/switched off

Functional condition 22-006 Direction driver's cab 1/driver's cab 2 (FS1/FS2)

Parameter 23-001 Number

Parameter 23-005 Temperature

Parameter 23-006 Speed

External environment parameter 24-001 Air pressure

6.1.6 Location structure

Typically multiple instances of the same assemblies can be installed in a vehicle. As a result, a

component part cannot be clearly assigned across the product group and the function group within a

vehicle. For instance, the DB Class 423 (an electric power car) has 24 external passenger doors, 2 drive

systems, 8 traction motors and 4 roof-mounted air conditioning systems. To resolve this problem, a

location group is also assigned to the "generic data model". This location group enables the

components/ component parts in need of maintenance to be located clearly (Table 13).

G A 7 7 7 5 1 3 P a g e 37 | 51

Table 13: Location group in the generic data model

If you divide the mounting positions into different groups, specific errors can also be found during

maintenance (e.g. failure of the doors on the right side of the vehicle). Therefore it makes sense to

classify the mounting positions by mounting position group (e.g. left side of the vehicle), mounting

position (e.g. side wall) and the specific installation position (e.g. door 22). A few mounting positions

are shown below by way of example.

Table 14: Mounting position group, mounting positions and installation position based on the generic data model

OGR (location group) Location

EPL (installation position) OGR text Mounting position Designation of installation position

2 8 0 Side wall R Right side of veh., door All doors

2 8 10 Side wall R Right side of veh., door Door 1R

2 8 120 Side wall R Right side of veh., door Door 12

2 8 220 Side wall R Right side of veh., door Door 22

2 8 430 Side wall R Right side of veh., door Door 43 (right side of veh.)

3 8 0 Side wall L Left side of veh., door All doors

3 8 10 Side wall L Left side of veh., door Door 1L

3 8 130 Side wall L Left side of veh., door Door 13 (left side of veh.)

Figure 7: Assignment of locations within the generic data model

G A 7 7 7 5 1 3 P a g e 38 | 51

6.1.7 Class-specific codes / examples

With the aid of the aforementioned elements, each component part can now be determined clearly.

Available codes can also be copied to this model so that in Maintenance the condition or the problem

of each component part can be identified quickly. As a result, the company saves time with

troubleshooting and can in some cases already rectify errors early on, which could occur in the

foreseeable future. A component part code is now made up of the product group as per EN 15380-2,

the function group as per the ISI component part catalogue, the component part condition and the

mounting position.

A component part code might look like this:

NB006_NSSCRV_14-022_2-8-0

Figure 8 shows the translation of this error sorted by the respective groups of the generic data model.

Further, other possibilities for the same component part are also shown, in some cases at other

mounting positions.

Figure 8: Class code based on the generic data model

Existing error codes can also be shown in the generic data model. One advantage in this respect is that

available error codes and conditions can be reformatted by an interface. Figure 9 and Figure 10 below

show this.

G A 7 7 7 5 1 3 P a g e 39 | 51

Figure 9: Fault codes Class 430 translated into error codes based on the generic data model

Figure 10: Operating data Class 430 translated into the generic data model

6.1.8 Summary relating to the generic data model

The generic data model provides the option of reflecting exactly all component parts in the form of

data.

The "generic data model" structures the various signals available on the vehicle to a degree of detail

required for the user in maintenance. The model also includes, apart from the familiar structure

elements of the product group structure as per EN 15380-2, information on further component part

subdivisions, information on the condition and on the individual mounting position of the elements to

be analysed.

The structure levels beyond EN 15380-2 must be standardised and subsequently continuously updated

centrally and extended.

G A 7 7 7 5 1 3 P a g e 40 | 51

The "generic data model" was presented here as an example just for vehicles. Transfer of the

structuring logic to all parts of the rail system is recommended.

6.2 Data designation model

6.2.1 Background, problem and objectives

While the data structure model in section 0 initially involves the structural classification of the total

volume of the data, in other words the assignment of the data to the component parts, errors and

events, the necessary standardisation of the designation and notation of the individual data is

analysed below. This is then explained in detail taking an example from the area of infrastructure.

At present there are major differences with the designation of components, component parts and

functions as well as with the designation of the different conditions including error description. To

further standardise the data to promote the use of data-based maintenance and for cross-

manufacturer analysis it is therefore necessary to also conduct harmonisation in this area. Such

standardisation of the designation and notation supports a cross-system analysis and evaluation of the

CBM data irrespective of manufacturer, operator or maintenance operator. Furthermore, this kind of

harmonisation is advantageous for a subsequent automation process.

As the example below shows, different error messages are generated with the same component part

and with the same error at different manufacturers. The maintenance operator receives an error

message, which may look like one of the following examples, depending on the manufacturer:

Manufacturer 1: "Track module fault detected"

Manufacturer 2: "Lamp status 1/2 (Lz1 / Lz2) red (in series) channel de-energised"

As shown in the example, different notations or conditions are defined for similar errors. This

constitutes a substantial obstacle for the necessary data analysis for the purpose of CBM.

Standardisation therefore aims to harmonise data designation and data notation. This harmonisation

must be manufacturer-, operator- and maintenance operator-independent. In addition, it must also

be ensured of course that this harmonisation also remains unaffected in the case of software

modifications.

When standardising the designation and notation of the data, the details necessary for the particular

asset down to the Last Replaceable Unit (LRU) as well as the description of all relevant conditions must

be taken into account.

For the purpose of future predictive maintenance, the extension of the conditions to include suitable

graduations (e.g. "half full" or wear reserve) is also possible.

The information in chapter 6.2 are based on the DB Netze Project DIANA. It is already used by DB.

6.2.2 Basic structure and function

The model for designating the data is explained below using an infrastructure model as an example.

A data set basically consists of four elements:

1. Product type – designation of the asset to be analysed (e.g. switch, signal, barrier system)

2. Product sets – collector for information categories (e.g. manufacturer information, condition

information)

G A 7 7 7 5 1 3 P a g e 41 | 51

3. Attributes - specific designation of the information in the product sets (e.g. lamp faulty,

manufacturer: Siemens, use up to maximum 50°C)

4. Assignments relating to the attribute – collection of other necessary information (e.g. data

type "Double", measurement unit "mm")

To guarantee comparability of similar component parts, the same component parts must be

designated uniformly irrespective of the manufacturer. Irrespective of where the component part was

installed (e.g. a level crossing in Germany or in France). The same applies to the conditions on the

component part. They are always similar irrespective of location and thus comparable (e.g. "level

crossing closed").

Both are information that must be processed in a defined way.

This information is stored in the form of attributes. The annotation of the attributes must always be

the same to aid understanding. For instance you could specify uniformly the attribute "IsName" for the

name of a component part:

IsName = "[Name of the component part]"

After it was stipulated one-time centrally that the component part name is stored under the attribute

"IsName", anyone wanting to give a name to a component part knows that they have to do this under

the attribute "IsName" or also that the name of the component part can be found under this attribute.

In addition to the component part name, there are, however, also other attributes that can be assigned

to a component part. For instance, this could also be the manufacturer name or the serial number.

Example:

Manufacturer = "[component part manufacturer]"

SerialNumber = "[serial number of the component part]"

So that any involved party knows which information must be stated under which attribute, attribute

tables must be maintained centrally.

To be able to better classify these attributes overall, they are summarised in groups, known as data

sets. In this way, all information that is associated with the manufacturer is written in the DeviceSet;

all information that is associated with the component function itself is written to the FunctionSet or

information on subcomponents to ProductGroupSets.

In addition to the clear data notation, in other words the attributes, it is also necessary in IT to assign

a data type to the data. Depending on what kind of data an attribute should include, another data type

is required. Otherwise, the data may under certain circumstances not be readable, analysable or

combinable with each other. As such, an assignment to a corresponding file type is required

immediately when defining the attribute. Depending on the use case, various data types are used. Data

types exist, for instance, for:

• Strings

• True/false logic (Boolean)

• Integers

• Floating-point number with higher accuracy (double)

G A 7 7 7 5 1 3 P a g e 42 | 51

An attribute that only has two states (mostly "true" or "false") includes a different data type than an

attribute that has multiple states, for instance a millilitre-based fill level.

It must also be stipulated which unit is used for which attribute so the unit can be interpreted clearly

during data processing. The unit is not stored within the attribute, but is required as known. The unit

should therefore be noted in an attribute table.

A reservoir for lubricating oil could contain 2,000 ml of oil. This could include, for instance, the

following information as file type "double"

IsOil = "2,000"

If another party involved has programmed their software to litres because they would like to work with

decimal places, they would understand here that the reservoir contains 2,000 l of oil.

During the further processing, a limit value of say 500 ml could be stated, which is constantly checked

and issues a warning as soon as this value is not reached:

If IsOil < "500" then WarningOil = "true"

If the attribute "IsOil" were to be stored in an unsuitable data type for this information (e.g. string),

the system could not process the data in the way shown above, since the data type string is understood

as a string of characters.

Conversely, for the aforementioned example "IsName" would not work as "double", but only as string,

since a string cannot be stored in the format "double".

In addition to the aforementioned comments, there are other IT reasons for assigning data types,

which are, however, not decisive for the data model used here and which will not be described further

at this point.

6.2.3 Examples of uniform data designation

The introductory example from section 6.2.1 is, as described, very difficult to process using electronic

data processing since the faults from the two sample manufacturers look different.

Manufacturer 1: "Track module fault detected"

Manufacturer 2: "Lamp status 1/2 (Lz1 / Lz2) red (in series) channel de-energised"

Adapted to the described data model with the clear data designation, you get a classification which is

understandable on a cross-manufacturer basis. A brief description of the example is provided in Table

15 below:

• ProductGroup<Signal>: Lamp status 2 (Lz2)

o ProductGroup<LightPoint>: red

▪ LampStatus: Failed

Table 15: Detailed explanation of the example for data designation

Type of assignment Name of assignment Assignment content Description

G A 7 7 7 5 1 3 P a g e 43 | 51

Product ProductGroup <signal>: Lamp status 2 (Lz2)

Assignment to the component part

Set ProductGroup <LightPoint>: red Assignment to the component of the component part

Attribute LampStatus Failed Status of the component part component

So that each involved party knows which signals and information are assigned to which attributes and

sets, an attribute table needs to be maintained centrally for each of the individual products. This must

be accessible to everyone involved. The attribute table must state at least the set with the respective

attributes, their importance, the data type of the attributes and the particular unit which is assigned

to the attribute. Three relevant examples follow.

G A 7 7 7 5 1 3 P a g e 44 | 51

Table 16: The data set "Environment" of the product "Dust sensor" contains among other things the attribute "DustLevelConcentration" with the data type Float with the unit "g / m³".

Name Meaning Data typ Unit

2.2.1.1 DustlevelConcentration Dust Concentration for dust sensor models that measure concentration. The data type is only available if the dust sensor has been created with the parameter "DustSensorMeasurementType.Concentration".

Float g/m³

2.2.1.2 DustLevelPPM Dust concentration for dust sensor models that measure the amount of dust (particles). The data type is only available if the dust sensor has been created with the parameter "DustSensorMeasurementType.PPM".

Float ppm

Table 17: A sensor of the product "Soft" contains the attribute "IsSensorFailure" with the data type Boolean - Without unit in the set "Error message" because only "True" or "False" is returned.

Name Meaning Data typ Unit

3.5.2.1 IsSensorFailure True: The sensor for measuring the direction of rotation is disturbed. For example, 0 mA for a 4mA-20mA current interface

Boolean -

Table 18: The product "temperature sensor" has among other things the attributes of the "maximum and minimum room temperature" in the unit "Kelvin" in the data type Float in the data set "Parameter".

Name Meaning Data typ Unit

2.2.2.1 pTemperatureRoomMaxFailure

Maximum room temperature Float K

2.2.2.2 pTemperatureRoomMinFailure

Minimum room temperature Float K

2.2.2.3 pPortId PortId of the input to which the sensor is connected. A list of all input PortIDs must be provided to the operator in advance. The identifier of the Input PorIds from the list must be physically attached by means of stickers or signs above the connector.

String -

6.2.4 Summary of the data annotation

To process CBM data uniformly in future in the rail sector, the content of the data must be annotated

uniformly and follow a common structure.

The structure and designation the data must be controlled centrally to be able to respond regularly to

changes. Everyone involved must follow and comply with this structure. Changes should only be

organised from the central entity so that here too all involved companies can implement the same

changes.

G A 7 7 7 5 1 3 P a g e 45 | 51

In addition to the centrally specified data structure and designation, it must be shown for which data

this structure is valid and how these features must be handled.

6.3 Benefit of standardisation for CBM usage in the rail sector Maintenance of vehicles and infrastructure still tends to be preventive today. This means component

parts are swapped out regardless of their condition. In some cases, perfectly intact component parts

are removed. The replacement intervals tended to be derived from experience of operating these

vehicles or similar classes.

Unexpected component failures are only identified once these failures occur and cannot be predicted

or are very difficult to predict. This requires an immediate operational response and disrupts

operations.

This should be changed in future. Through a uniform structure of data and its classification, the user

should be able at any time to find out the current condition of a vehicle.

By standardising the data structure and data designation it will be possible immediately in future to

include a new class or a new component of the infrastructure into the maintenance system and

analysis system.

In this way, most vehicle or infrastructure problems will be able to be detected in future by means of

continuous monitoring (tailored to the particular user) before such problems occur. Further

information in this respect is also included in Deliverable 6.5.

Automatic identification will allow conventional maintenance tasks to be shortened and, in some

cases, even omitted entirely. This reduces LCC costs of a vehicle or an infrastructure system

substantially in some cases, reducing in turn the expenditure of the companies.

G A 7 7 7 5 1 3 P a g e 46 | 51

7 Conclusions and data requirements for CBM As part of the work on this deliverable, it was found that standardisation of the following elements is

not worthwhile based on the insights from Deliverable 6.2:

• Data format

• Transfer protocols

• Data and sampling frequency

• On-board software for rail vehicles

• The type of physical data transfer from the vehicle to the landside

• The type of data storage

• CBM visualisation systems and data transfer to these

Within the working group WP6 it was found and confirmed by all participants that there are major

problems with data processing, which can be rectified by standardising the following elements:

• Single data structure, by classifying the data into a model that clearly reflects the vehicle

structure and the function of the component parts and can be assigned clearly to just one

component part on the basis of the data name.

• Unique data designation, which is structured so that a component part, which is used by

multiple manufacturers or operators, always gets the same designation, as well as the

designation of the conditions so that a condition that a component part can adopt, always has

the same conditions irrespective of the manufacturer and operator.

• Data classification that specifies precisely in what format data must be classified with which

subgroupings.

• Table of data meaning that shows in which unit the data has (e.g. liter or milliliters) and

explains its exact meaning.

• Data interface where all CBM data can be picked off so that it is no longer necessary to build

interfaces at multiple locations. Irrespective of the interface, the data can then be further

processed.

• Clarification of the legal situation regarding who the data belongs to.

• Centralised management of the data that updates the specifications for structure, designation

and classification of the data.

These insights serve as input for the smart maintenance concept in Deliverable 6.5 in relation to the

Guideline for Manufacturers/ Operators/ Maintenance Operators. They are equally interesting for the

partner TDs since similar problems were found here.

G A 7 7 7 5 1 3 P a g e 47 | 51

8 Future Development In addition to the illustrated need for standardisation, the following areas in particular will need to be analysed in greater detail and regulated on an overarching basis in future

• Quality/ reliability of data (including necessary continuity of the data provisioning and transfer, as well as the data truth – Deliverable 6.4)

• Data security (protection against tampering, hacking or similar)

• Data safety (reliability – Deliverable 6.2)

• Security plan for special events (data loss, wireless dead zone, transfer interruption, ethical issue – Who decides whether a component part is bad, and an accident happens?)

• Data management (centrally/remotely) and accessibility to the data with various access options

G A 7 7 7 5 1 3 P a g e 48 | 51

9 Further steps towards standardization

The standardisation approaches of deliverable 6.3 are incorporated into the summary of the standardisation approaches S2R (tabular overview WP5 – Deliverable). They are also submitted as input for the CDM group (Shift2Rail project LinX4Rail) to provide guidance here for the joint data model.

The overall list of standardisation WP5 must be agreed between Joint Undertaking and European/international standardisation committees (CEN/ CENELEC) to place the standardisation projects accordingly. There a decision will be taken in a further step regarding which committee is commissioned with the further development regarding standardisation of the CBM data.

For the standardisation approaches devised as part of this deliverable, various additional steps for further development are conceivable. These steps may also be performed in parallel. These are:

1. ISO TC 204 – WG8 to further process the topic to devise ISO standardisation

2. CEN/ TC 256 / WG48 or the IEC/TC 9/WG 43 to further process the topic to devise standardisation for rail vehicle maintenance

3. CEN/ TC 256-SC1 to further process the topic as part of devising standardisation for rail infrastructure-infrastructure - track

4. CLC/ SC 9XA to further process the topic to devise signal and data exchange in the infrastructure

5. New standard by CEN/ TC 256 / WG48 to standardise the data

6. CEN/ TC 256 / WG19 to undertake revision to provide a greater level of detail of 15380-2

7. Creation and development of an EuroSpec for data standardisation

G A 7 7 7 5 1 3 P a g e 49 | 51

10 References

No References

G A 7 7 7 5 1 3 P a g e 50 | 51

11 Annexes

No Annexes

G A 7 7 7 5 1 3 P a g e 51 | 51

12 Antitrust statement

While some activities among competitors are both legal and beneficial to the industry, group activities of competitors are inherently suspect under the antitrust/ competition laws of the countries in which our companies do business. Agreements between or among competitors need not be formal to raise questions under antitrust laws. They may include any kind of understanding, formal or informal, secretive or public, under which each of the participants can reasonably expect that another will follow a particular course of action or conduct. Each of the participants in this initiative is responsible for seeing that topics which may give an appearance of an agreement that would violate the antitrust laws are not discussed. It is the responsibility of each participant in the first instance to avoid raising improper subjects for discussion, notably such as those identified below. It is the sole purpose of any meeting of this initiative to provide a forum for expression of various points of view on topics

▪ (i) that are strictly related to the purpose or the execution of the initiative,

▪ (ii) that need to be discussed among the participants of the initiative,

▪ (iii) that are duly mentioned in the agenda of this meeting and

▪ (iv) that are extensively described in the minutes of the meeting.

Participants are strongly encouraged to adhere to the agenda. Under no circumstances shall this meeting be used as a means for competing companies to reach any understanding, expressed or implied, which restricts or tends to restrict competition, or in any way impairs or tends to impair the ability of members to exercise independent business judgment regarding matters affecting competition. As a general rule, participants may not exchange any information about any business secret of their respective companies. In particular, participants must avoid any agreement or exchange of information on topics on the following non-exhaustive list:

1. Prices, including calculation methodologies, surcharges, fees, rebates, conditions, freight rates, marketing terms, and pricing policies in general;

2. any kind of market allocation, such as the allocation of territories, routes, product markets, customers, suppliers, and tenders;

3. production planning; marketing or investment plans; capacities; levels of production or sales; customer base; customer relationships; margins; costs in general; product development; specific R&D projects;

4. standards setting (when its purpose is to limit the availability and selection of products, limit competition, restrict entry into an industry, inhibit innovation or inhibit the ability of competitors to compete);

5. codes of ethics administered in a way that could inhibit or restrict competition; 6. group boycotts; 7. validity of patents; 8. ongoing litigations.