Welcome to the Final Event - projects.shift2rail.org

Welcome to the

Final Event

This project has received funding from the European Union’s Horizon 2020

research and innovation programme under grant agreement No: 730640



WP 3 Adaptable Communication

SystemWP Leader - Ulrich Geier

3 12.07.2019

WP3 - WORK PACKAGE OVERVIEW

Objectives:

➢ Collection of User Requirements

➢ Specification of ACS System

Architecture

➢ Analysing Candidate Business

Models

➢ Specification and development of

prototypes and demonstrators

WP Duration + Deliverables

Task 3.7 Definition of Test Strategy

Task 3.6 Definition and Development of selected Prototypes

Task 3.5 Guideline for Choice of Technology

Task 3.4 Specification of the Communication System

Task 3.3 Business Model

Task 3.2 User Requirements

Task 3.1 Technical Coordination and System Integration

6 30241812 36

WP Members

D3.3

D3.3

D3.4

D3.2

Months

D3.4

D3.1

4 12.07.2019

User and System Requirements specified

=> USR published

System Architecture of the ACS specified and Guidelines for Technologies given

=> System Specification published

Different Business Models evaluated

Specification and Development of Technical Prototypes and Demonstrators for

Highspeed/Mainline

Regional/Freight

Urban/Suburban

Test Strategy defined

WP3 - WORK PACKAGE ACHIEVEMENTS

5 12.07.2019

ADAPTABLE COMMUNICATION SYSTEM ARCHITECTURE

6 12.07.2019

BENEFITS / ADVANTAGES COMPARED TO LEGACY NETWORKS

Higher data throughput

and simultaneous connections

Support of multiple

applications in parallel

Improved

connection

reliability

through higher

redundancy

Dynamically selectable and configurable

Quality of Service support

Radio Access Technology

agnostic

Facilitating migration

ACS

Range of business models

supported

7 12.07.2019

ALIGNMENT WITH EXTERNAL UIC PROJECT FRMCS

8 12.07.2019

The Adaptable Communication System development is well on track

All Objectives within X2Rail-1 were fulfilled

Deliverables approved even one month earlier as planned

Activities on X2Rail-3 Project already started since 03/2019

Good collaboration with other work packages as well as other IPs and the

external UIC Project FRMCS

Please have a look to our poster and the animation film produced for Innotrans

2018 on the screen next to our stand.

SUMMARY / CONCLUSION

Thank You For Your Attention!

Questions?

Contact: [email protected]



WP 4 ATO up to GoA4WP Leader - Benoit Bienfait

11 12.07.2019

GRADES OF AUTOMATION

GoA1+

C-DAS over

ETCS

GRADES OF AUTOMATION

12 12.07.2019

AOE IN SHIFT2RAIL

Shift2Rail

NGTC

Ten-T

EEIG – ATO over ETCSOperation Concepts

(Up to GoA4)

ETCS Baseline 3

Test Bench Demonstrator

(limited to GoA2)

Pilot Line Demonstrator

(limited to GoA2)

ATO over ETCS(up to GoA4)

Feasibility Study

Test Bench Demonstrator(up to GoA4)

Pilot Line Demonstrator(up to GoA4)

Product development phase (up to GoA4)

ATO over ETCSSpecification work

(up to GoA4)

AoE System Requirements

(GoA2)

Product development phase (limited to

GoA2)

Quick Win

2 separate workstreams

13 12.07.2019

WORK PACKAGE OVERVIEW

Grade of automation 2 (GoA2)

➢ Standard specification

➢ Trackside and on-board prototypes

➢ Reference Tests on 2 standard Test

Benches

➢ Pilot tests on actual train and line

(delayed due to train unavailibility)

Grade of automation 3/4 (GoA3/4)

➢ Preliminary specification:

➢ Operation Requirement

➢ System Requirement Specification


Task 4.7 ATO over ETCS – GoA3 Specification

Task 4.6 ATO over ETCS – GoA3/4 Feasibility Study

Task 4.5 ATO over ETCS – GoA2 Pilot Line Demonstration

Task 4.4 ATO over ETCS – GoA2 Reference Test Bench Demonstration

Task 4.3 GoA2 Prototype Development

Task 4.2 GoA2 Specification


6 30241812 36

WP Members

D4.1

D4.2

D4.3

D4.4

14 12.07.2019

ERTMS

Driver

- Operate the train- Define speed profile- Accelerate and brake

FFFIS

Voice communication

Interlocking

- Lock the routes

Traffic Management System

- Manage Passing & Stopping Points

- Manage arrival & departure times

- Manage the routes

ETCS-TS (RBC)

- Define Movement of Authorities

ETCS-OB (EVC)

- Define safe speed curves

- Protect the train againstMoA override

GOA1 ARCHITECTURE

15 12.07.2019

Traffic Management

ATO

ERTMS

Interlocking

- Routes Handling

ATO-TS

- Provide operation data- Provide infrastructure

data

ETCS-OB (EVC)

- Define safe speed curves

- Supervise MA restrictions

ATO-OB- Optimised speed

computation- Control Train

(Traction/Brake)- Passing & Stopping

Point Management

FFFIS

ETCS-TS (RBC)

- Define MovementAuthorities

FFFIS

Traffic Management System

- Define Passing & Stopping Points

- Define arrival & departure times

- Define the routes

FIS

GOA2 ARCHITECTURE

FFFIS TRAIN

16 12.07.2019

ATO/DASon-board

ETCSon-board

Train

DMI

Onboard Recording Device

ETCSTrackside

SUBSET-125

Key Mgt System

ATO/DASTrackside

SUBSET-125

SUBSET-139 SUBSET-140

AdjacentATO/DASTrackside

TMS

SUBSET-126

X2

Rai

l-13

1SU

BS

ET-

13

2

SUBSET-130

SUBSET-143

On-board ATO

Trackside-board ATO

➢ The ATO trainborne is defined as a

SIL0 sub-system adjacent to the

ETCS trainborne system.

➢ The ATO trackside is defined as a

SIL0 sub-system.

➢ The ATO trackside and ATO

trainborne interface via using the

GSM-R PS communication bearer.

DOCUMENTS ASSOCIATED WITH GOA2 SOLUTION

17 12.07.2019

DOCUMENTS ASSOCIATED WITH GOA2 SOLUTION

DocumentERA

Review

Frozen for

IOP testsCompletion

SUBSET-125 (AoE - System Requirement Specification) x x 20-02-20

SUBSET-130 (ETCS-OB/ATO-OB FIS) x x 24-03-20

SUBSET-126 (AoE - Track/Train FIS) x 26-05-20

SUBSET-139 (Train/ATO-OB FIS) x 21-01-21

SUBSET-140 (ORD/ATO-OB FIS) 26-03-21

SUBSET-143 (FFFIS for ETCS/OB/ATO-OB) 08-04-20

SUBSET-132 (ATO-TS/ATO-TS) 14-08-20

SUBSET-126 App A (FFFIS for ATO-OB/ATO-TS) 18-11-20

X2Rail-131 (TMS/ATO-TS FIS) 25-09-20

➢ Two Reference Test Benches

➢ Four different configurations

➢ Interoperability Tests performed

in 12/18 and 1/19

INTEROPERABILITY TESTS ON REFERENCE TEST BENCHES

Reference Test Bench





ATO-OB ATO-TS

ETCS-OB


ATO-OB ATO-TS

ETCS-OB


ATO-OB ATO-TS

ETCS-OB


ATO-OB ATO-TS

ETCS-OB

19 12.07.2019

GOA3/4 PRELIMINARY SPECIFICATION

Operational Contexts

Actors

Actors

Use Cases

Actors

Logical Architecture

Top

-Do

wn

ap

pro

ach

bas

ed O

pe

rati

on

al C

on

text

s an

d

Use

Cas

es

20 12.07.2019


FunctionsFunction


Actors

Actors

Use Cases

Actors


FIS Interface specification

FIS

FFFIS Inte

rface

spe

cification

FIS

Physical Architecture (in line with RCA)

Bo

tto

m-U

p a

pp

roac

h b

ased

on

cu

rren

t d

rive

rs in

stru

ctio

ns

Top

-Do

wn

ap

pro

ach

bas

ed O

pe

rati

on

al C

on

text

s an

d

Use

Cas

es

21 12.07.2019


FunctionsFunction


Actors

Actors

Use Cases

Actors


FIS Interface specification

FIS

FFFIS Inte

rface

spe

cification

FIS

Physical Architecture (in line with RCA)

Bo

tto

m-U

p a

pp

roac

h b

ased

on

cu

rren

t d

rive

rs in

stru

ctio

ns

Top

-Do

wn

ap

pro

ach

bas

ed O

pe

rati

on

al C

on

text

s an

d

Use

Cas

es

Operation Requirement

System Requirement Specification


Questions?




WP 5 Moving BlockWP Leader – Simon Chadwick

24 12.07.2019

WP Members


Task 5.9 High Speed Lines Prototypes Definition


Moving Block Objectives:

➢ Enable increase capacity without

extra infrastructure costs

➢ Decouple the infrastructure from

train performance parameters

➢ Reduction in trackside equipment

Work Package Objectives:

➢ Definition of Moving Block signalling,

based on ETCS Baseline 3 Release 2

➢ Cover different styles of Moving

Block: „Full Moving Block“ and „Fixed

Virtual Blocks“

➢ Applicable to different types of

railway


Task 5.8 Overlay Prototype Definition

Task 5.7 Urban/Suburban Prototype Definition

Task 5.6 Moving Block Application Analysis

Task 5.5 Moving Block Safety Analysis

Task 5.3 Moving Block System Specification

Task 5.2 Moving Block Operational and Engineering Rules

6 30241812 36

D5.1

D5.2

D5.3

D5.4

Task 5.10 Low Traffic and Freight Prototypes Definition

Months

25 12.07.2019

We agreed early in the WP5 work on the definition of Moving Block System Types:

MOVING BLOCK SYSTEM TYPES

1) Full Moving Block, without Trackside Train Detection

2) Full Moving Block, with Trackside Train Detection

3) Fixed Virtual Blocks, without Trackside Train Detection

4) Fixed Virtual Blocks, with Trackside Train Detection

FS

Trackside Train Detection: Occupied (TTD occ)

FS MA FS MA

FS

FSFS

FS MA FS MA

FSFS

TTD occ

FS MA FS MA

FSFS

Full Supervision Movement Authority (FS MA) FS MA

26 12.07.2019

The work was done by

creating Scenario

Descriptions in a series

of Workshops

Thereafter System

Requirements,

Operational and

Engineering Rules were

derived.

The Scenarios were also

used for Hazard

Identification.

HOW THE WORK WAS DONE

Scenario Descrip-

tion

Scenario List

Consoli-dation

D5.3Moving Block

Preliminary Safety Analysis

D5.2Moving Block

Operational and Engineering Rules

D5.1Moving Block

System Specifications

Scoping Documents

etc.

Scenario Descriptions

Applica-tion

Analysis

D5.4Moving Block Application

Analysis

16 Scenarios

27 12.07.2019

D5.1 System Requirements

System Requirements for Moving Block, based on ETCS Baseline 3

Release 2, together with CR940 (Train Integrity)

Requirements cover all four Moving Block system types

Requirements are for ETCS Level 3, relative to ETCS Level 2

Each Requirement has Requirement; Rationale; Guidance

List of 7 proposed Change Requests for the CCS TSI

Highlight: The requirements are built up around the concept of

Track Status:

DELIVERABLE D5.1 SYSTEM SPECIFICATION

Train 1

MSFE-1CSRE-1 CRE-1

Train 1

MSFE-2CSRE-2 CRE-2

New Train Position Report

mSFE-1

mSFE-2

Example:

Train “Sweeping” an

Unknown area of track,

shown in blue

28 12.07.2019

DELIVERABLE 5.2 OPERATIONAL AND ENGINEERING RULES

D5.2 Operational and Engineering Rules

Operational Rules – where new rules are required for

Operation of a Moving Block system

Example: To handle a non-communicating train

Engineering Rules – where decisions and data are required to

implement a Moving Block system

Example: Configure the system reaction to a train has not

confirmed train integrity

Each Rule has Rule, Rationale, Guidance

29 12.07.2019

DELIVERABLE D5.3 PRELIMINARY SAFETY ANALYSIS

D5.3 Preliminary Safety Analysis

Preliminary Safety Analysis has been carried out by a separate

safety team (Task 5.5) to identify hazards arising from use of

Moving Block

Each Hazard has Description, Potential Mitigations

Document has links back to D5.1, D5.2 for mitigations

Example Hazard categories:

Track Status erroneously cleared

Error in Train Location

Error in Train Length

Undetected Train Movement

30 12.07.2019

D5.4 APPLICATION ANALYSIS

D5.4 Moving Block Application Analysis

Examination of:

Urban / Suburban Lines

Overlay Systems

High Speed Lines

Low Traffic and Freight Lines

Characterise each type of railway

Understand how you might apply the system defined in D5.1,

D5.2 to such lines

Identify any extra Requirements or Rules (D5.1, D5.2)

31 12.07.2019

X2Rail-1 WP5 Moving Block provided demonstrations and presentations on the

Shift2Rail stand at Innotrans 2018

ON THE WAY….INNOTRANS 2018

Presentations

Demonstrations

WP5 Participants:

32 12.07.2019

The Moving Block journey continues

As we finish the work in X2Rail-1 WP5 Moving Block, we are starting the work in

X2Rail-3 WP4 Moving Block

Headline areas for next work in X2Rail-3:

Further work on the Specifications – especially on Track Status

Further work on Safety Analysis

How to Test Moving Block systems

Future Moving Block Architectures

Technical Demonstrators

Innotrans 2020

WHAT´S NEXT?


Questions?


has addressed the first six out of

eleven research and development work streams within the

Shift2Rail IP2. These workstreams, also called Technical

Demonstrators, are Adaptable Communication, ATO over

ETCS, Moving Block, Zero on-site Testing, Smart radio-

connected all-in-all Wayside Objects and Cyber Security.

To make sure that all developments are in line and well

coordinated, X2Rail-1 and each subsequent X2Rail project

includes a specific "WP2", which looks at system coherence

challenges and is the main body to discuss all technical

interdependencies.

19

partners

Budget of

45 M €

3

Years Duration

IP2

AdaptableCommunication

Automatic Train Operation

Moving Block

Train Positioning

On Board Train Integrity

Zero on-site TestingFormal Methods

Virtual Coupling

Traffic Management

Wayside Objects

Cyber Security

TD2.1

TD2.9

TD2.2

TD2.3

TD2.4

TD2.5

TD2.6TD2.7

TD2.8

TD2.10

TD2.11

WP1 Project Management

WP2 Technical Coordination and System Coherence

Adaptable

Communic

ation

System

ATO over

ETCS

Moving

Block

Zero on-

site

Testing

Smart

Wayside

Objects

Cyber

Security

WP9 Dissemination and Communication

What´s next?

The remaining five Technical Demonstrators (Fail Safe Train

Positioning, Onboard Train Integrity, Formal Methods, Traffic

management Evolution and Virtual Coupling) were first dealt

within X2Rail-2 project. From the beginning, it was planned and

foreseen that the eleven Technical Demonstrators are

developed and researched within the five X2Rail-xprojects.

With X2Rail-1finished, X2Rail-2 and X2Rail-3 infullswing,

theX2Rail-4 proposal just submitted and the X2Rail-5 project in

the early planning stage, we are on a very good path to reach

the overall goals. With each project, the prototypes reach a

higher technical readiness level (TRL) and bring the innovations

closer to the market.

WP3 WP7WP6WP5WP4 WP8



WP 6 Zero On-Site TestingWP Leader – Lisa-Marleen Scheile

36 12.07.2019

Task 6.4 Define General Architecture for Test Environment


Objectives:

➢ Assessing today’s practice of field

testing including other industries

benchmarking

➢ Defining a common framework for

the test process

➢ Defining a dedicated system test

architecture for lab testing

➢ Standardizing interfaces and test

processes

➢ Fostering interoperability


Task 6.3 Definition of Test Process

Task 6.2

Assessment of

Status Quo in

Field Test and

Benchmarking

Task 6.1 Technical Coordination and System Interaction

6 30241812 36

WP Members

D6.1

D6.2

D6.3

Months

37 12.07.2019

Task 6.1 - Technical Coordination and System Integration

Task 6.2 - Assessment of status quo in field testing and benchmarking

Deliverable D6.1 - Current test condition and Benchmarking report

Task 6.3 - Definition of test process

Deliverable D6.2 - Description of test process

Task 6.4 - Define general architecture for test environment

Deliverable D6.3 - Description of general test architecture

TASKS AND DELIVERABLES

38 12.07.2019

Objectives

To assess the current field test activities and to identify work packages which can be

shifted to lab testing.

Identify areas where lead time and cost of field testing can be reduced and to

improve further on the quality of delivered solutions.

A benchmarking of Rail Signalling and Telecom activities with other safety critical

industries like avionics, medical, automotive has been a strong element of this task.

Main activities of this task are:

Collecting data about today’s requirements for tests and verification / validation

procedures.

Provide knowledge of specifications in the Europe railway networks.

Benchmarking with automotive, aviation and other sectors.

TASK 6.2 - ASSESSMENT OF STATUS QUO IN FIELD TESTING

AND BENCHMARKING

39 12.07.2019

Reasons for lab testing:

(ranked by replies)

Cost savings

Time savings

Required by notified Bodies

Intersystem-Interoperability

Contractually defined

TASK 6.2 - RESULTS

Tests performed in lab Tests performed on-site

40 12.07.2019

Objectives

Define and agree on a common test process framework and to identify a standard method to derive and describe test specifications.

Justification : Easily exchange test specs between the different parties involved in field testing.


Collaborating and comparing existing test processes within the rail signalling and telecom industry, the way the test specifications are derived and designed and compare it with best practices from other industries.

Develop methodology and tools on how to derive the needed test specifications. Preferred is a model based approach. Involvement of railway operators and model based approach in line with EN50126 is mandatory.

To develop a formalized way of creating test cases (one example could be corridor 1 for ETCS Systems).

Definition of measureable KPIs to support improvements in testing.

TASK 6.3 - DEFINITION OF TEST PROCESS

41 12.07.2019

TASK 6.3 - RESULTS

Subtask1: Definition of common test process framework

standardize and unify the terms related to Tests Category classification

42 12.07.2019

Subtask2: Definition of common criteria for test case selection which can be shifted

from site to lab

Identification and classification of limitations to shift tests from site to lab

Evaluation of possible improvements in testing environment and in certification process to

overcome limitations

TASK 6.3 - RESULTS

43 12.07.2019

Subtask 3: Specification of a standardized method to derive and describe test

cases

Input and output of the test cases related to the defined test activities from subtask

1 analyzed and compared

TASK 6.3 - RESULTS

44 12.07.2019

Objectives

Create a new architecture of a test environment where the majority of activities which are currently done during field testing can be executed.

Support different technologies but also products of different suppliers.

Define architecture of this future test environment as well as defining elements which need to be real (HW and SW).


Contribute specifically with the knowledge of simulator development (RBC, OBU, IXL) and verification and interfacing it to the tested subsystem.

Deliver feedback from field tests and contribute to ETCS System requirements of test architecture.

Define a full end-to-end network to increase the test coverage and maximize off site testing, incl. network function virtualization and use of simulators within the telecoms domain.

Define the requirements on the test architecture to integrate the contributed components and perform the envisioned tests.

Decide about the location of the test environment(s).

TASK 6.4 - DEFINE GENERAL ARCHITECTURE FOR TEST

ENVIRONMENT

45 12.07.2019

TASK 6.4 - RESULTS

46 12.07.2019

Generic architecture for test environment:

TASK 6.4 - RESULTS

47 12.07.2019

Examples:

TASK 6.4 - RESULTS

«system under test»Railway Signalling System

«subsystem»RBC

bdd [system] Test Environment (example IOP test with real GSM-R)

«block»Test Control and Logging

«module»Test Control Unit

«module»Test Logging Unit

«module»Track Controller

«module»RBC Controller

«block»RBC Adaptor

«block»User Interface

Tester

«module»IXL Simulator

Test Script/Specification

«subsystem»OBU

«block»OBU Adaptor

«subsystem»Radio – GSM-R

«block»RBS Adaptor

«module»Traffic

Simulator

«module»RBS Controller

«module»OBU Controller

«module»Saboteur

«module»Balise Simulator

48 12.07.2019

Examples:

TASK 6.4 - RESULTS

bdd [system] two Test Environments (example corridor test)

«subsystem»RBC


«subsystem»RBC


«subsystem»OBU

«block»OBU Adaptor

«subsystem»IXL

«block»IXL Adaptor

«subsystem»IXL


«subsystem»IXL


«subsystem»OperatorPlace(CTC)

«block»OP Adaptor

«subsystem»OperatorPlace(CTC)

«block»OP Adaptor


«module»OP Controller

«module»IXL Controller








«module»OP Controller







«module»Field Elements



Tester TesterLab BLab A


Questions?




WP 7 Smart Wayside ObjectsWP Leader – Belen Losada

51 12.07.2019

6 12 18 363024

Task 7.4 Definition of System Architecture


Objectives:

▪ To develop an autonomous, intelligent,

maintenance free smart equipment (“box”)

able to connect with any signalling wayside

object and communicating device in the

area (wireless), guaranteeing safety and

security, by the definition of a common

architecture and of requirements and

interface specifications

▪ To develop concepts for locally derived

power and develop concepts for the overall

reduction of power consumptions and

required cabling

▪ To specify interfaces with control, power,

diagnostics and maintenance systems using

both low and high capacity wireless links

▪ Co-operate with other Work Packages and

Open Call (Etalon)


Task 7.3 Analysis of Railway Requirements and Standards

Task 7.2 Analysis of Existing

Lines and Economic Models

Task 7.1 Technical Coordination and System Interaction

WP Members

D7.1

D7.2

D7.3 D7.4

52 12.07.2019

Relationships between WP7 Tasks

Deliverables generated in each

task

Links between deliverables

METHODOLOGY

Task 7.1 leader

Thales

Task 7.2 leader

Thales

Task 7.4 leader

Indra

Task 7.3 leader

CAF

WP7 leader

Thales

53 12.072019

Analyses item Specific Item Works/TasksCosts

OC SWOCComments

Installation

CAPEXCivil Works High Low

OC and SWOC installation itself can be considered the same cost, but

not the civil works for cabling paths as well as the cable itselfCabling High Low

Tests

FAT Medium Medium

Performing tests (FAT, SAT and Commissioning) costs is considered the

same for both (OC and SWOC)

SAT Medium Medium

Commissioning Medium Medium

Diagnosis and

Maintenance OPEX

Material (spare

parts, cable,…)

Preventive Maintenance High Medium Preventive maintenance in SWOC is expected to be reduced because

implementation of enhanced Diagnosis and Maintenance capabilities

into SWOC.Corrective Maintenance Medium Medium

Update costsSoftware and Firmware

updatesHigh Low

Remote Software and Firmware updates reduces traveling costs, as

well It is not an usual work to be performed with high frequency.

Human Staff costs

Task forces for preventive

maintenanceMedium Low Preventive maintenance in SWOC is expected to be reduced because

implementation of enhanced Diagnosis and Maintenance capabilities

into SWOC

Staff rostering for corrective

maintenanceMedium Medium

Communication

System

WiredCivil engineering works High Low

Cable High Low

WirelessSite engineering works N/A Medium

Civil works N/A Low

Power Supply and

Power sources….

R&D ….

TASK 7.2: ANALYSIS OF EXISTING LINES AND ECONOMIC MODELS

ANALYSIS OF COSTS OC VS SWOC

54 12.072019


TRANSITION FROM OC TO SWOC

Centralized and Wired solution

Versus

SWOC Distributed and Wireless

solution

55 12.072019

The table shows the comparison of wired and wireless connection

The scheme shows the wireless techniques applicable to SWOC

Wired connection Wireless connection

Design precise reconnaissance and surveying necessary

constructional and earthwork design necessary

classical drawing of the whole line between the end points

reconnaissance and surveying easy

mathematical modelling of propagation of the electromagnetic waves between

the end points

if line of sight is free no modelling

only drawing of both radio transceivers/antennas at both end points

Installation highly laborious earthwork easy

Change difficult fairly easy if propagation of the electromagnetic waves is not obstructed

Maintenance easy fairly laborious

Reliability high medium

Immunity against lightning immune, depends on level of isolation sensitive for radio transceivers

Galvanic isolation systems usually 4KV isolators used no galvanic isolation necessary

Immunity against interference internal cable crosstalk on the long cable confluence

external cable crosstalk from catenary and high-voltage lines

depends on area

depends on spectrum management

depends on quality (and allowed dimensions) of antennas

Life-cycle cost (LCC) very high cost of ground works, medium cost of cables low cost of installation, minor to medium cost of terminals

Power consumption low low to medium

Bandwidth medium for metallic twisted pairs

high for coaxial cables

very high for optical cables

low to high – depends on selected technology

Transmitted data security good – cryptographic protection usually unnecessary low – cryptographic protection necessary

Line dependability low to good – depends on installation technology, type of cable high for the line itself – nothing to steal

good for the transceivers – not very attractive for thieves


ANALYSIS OF WIRED TO WIRELESS CONNECTION

56 12.072019

Option 1: Object Controller and power source integrated in the field element

Option 2: Object Controller managing a group of field elements, one power source for the site

Option 3: Common power source for high energy users


ANALYSIS OF POWER SUPPLY

57 12.07.2019

Smart Wayside Object Controller Requirements

OC requirements, related to the SWOC as a whole and its behavior as Object

Controller (OC)

Functional

Non-Functional

Communication requirements, related to the communication functions to be carried

out by the SWOC

Power supply requirements, related to power supply management.

TASK 7.3: ANALYSIS OF RAILWAY REQUIREMENTS AND

STANDARDS

58 12.07.2019

Design process for the

generation of “D7.3 - System

Architecture and Interfaces”

uses as inputs:

“D7.1 – Analysis of Existing

Lines and economic models”:

Operational Scenarios/Use

Cases/Business Needs linked

to Capabilities

“D7.2 – Railway Requirements

and Standard application

conditions”:

Requirements linked to

Activities

TASK 7.4: DEFINITION OF SYSTEM ARCHITECTURE.

DESIGN PROCESS FOR D7.3 GENERATION

59 12.07.2019


APPLICATION SCENARIOS - EXAMPLES

Scenario 1: SWOC used to control a Point Machine

Scenario 2: Axle Counter Connected via simple SWOC to the IXL

Scenario 3: SWOC Diagnosis and Maintenance

60 12.07.2019


SYSTEM ARCHITECTURE AND INTERFACES

System Architecture of the

SWOC composed of:

Control Unit

Power Management Unit

Communication Unit

Maintenance, Diagnosis

and Asset Data Unit

Interfaces:

External systems

External power source

system

Wayside Objects

61 12.07.2019

Structured planning of an overall system demonstrator:

Based on:

Identified solutions in D7.1

Requirements included in D7.2

System architecture and interfaces defined in D7.3

Demonstrators for each company :

Development of prototypes following the specification

Verification of the prototypes will take into account an environment for testing to reach a TRL 4

Prototypes validation tests executed in operationally representative environment (simulation or

field tests site) to reach a TRL 6


PLANNING OF SYSTEM DEMONSTRATOR


Questions?




WP 8 Cyber SecurityWP Leader – Francois Hausman

64 12.07.2019


Objectives:

▪ Define cybersecurity framework for

railway

▪ Define railway cybersecurity context

▪ Propose risk assessment process

▪ Propose protection profile for railway

components

▪ Analyse Threat detection, protection

and response for railway

▪ Identify standard for security-by-

design

▪ Propose security-by-design

approach

▪ Disseminate S2R cybersecurity work


WP Members


Task 8.9 Definition of the Scope and

Functional Specification of the

´´security-by-design´´

Demonstrator

Task 8.8 Draft of the ´´security-by-design´´ Standard Applied to Railway

Task 8.7 Definition of Protection Profile

Task 8.6 Selection of the ´´security-by-

design´´ Standard

Task 8.5 Definition of the Scope and

Functional Specification on the

Cyber Security

Task 8.4 Draft Standard for Railway Cyber Security System

Task 8.3 Threat Detection, Prevention and Response

Task 8.2 Security Assessment of ETCS and Urban System

6

D8.1

D8.2

D8.4

12 18 24 30 36

D8.3

D8.5

D8.6

Months

65 12.07.2019

Analysis cybersecurirty framework for security-by-design

IEC 62443-4-1 and other IEC 62443 parts are taken as framework

IDENTIFICATION OF IEC 62443-4-1 FOR SECURITY-BY-DESIGN

Criteria ISA/IEC 62443-4 ISO 15408 (CC) ISO/IEC 27034 NIST ANSSI Microsoft SDL Coding Rules

Design and Development OK OK OK OK High-level Partial NOK

Verification and validation OK OK OK OK Partial Partial Partial

Security level OK High-level NOK OK OK Partial NOK

Maturity level OK OK NOK High-level NOK Partial NOK

Defence in depth OK OK OK OK OK Partial NOK

Security defect management OK OK OK OK OK Partial NOK

Patch management OK OK OK OK OK Partial NOK

Security assessment OK OK OK OK OK Partial NOK

Guideline/documentation OK OK OK OK OK OK OK

System integration and use OK OK OK OK NOK Partial NOK

Technological watch OK Partial OK OK OK OK OK

Protection profile OK OK NOK High Level OK NOK Partial

Product lifecycle OK OK Partial OK NOK Partial NOK

66 12.07.2019

IEC 62443 has been chosen ascybersecurity framework forrailway due to:

Set of standards dedicated to IACSs

Stakeholders expectations, responsibilities and duties

Product and system life cycles

Define security levels based on functional security requirements

Used by other critical infrastructures

Approach compliant with definition of protection profiles

Standard analysed and validated for railway sector in D8.2

IEC 62443 AS CYBERSECURITY FRAMEWORK FOR RAILWAY

67 12.07.2019

Process for risk assessment and protection profile definition

RISK ASSESSMENT AND PROTECTION PROFILE DEFINITION

68 12.07.2019

Threat landscape based on ISO 27005 – 2011, ENISA – Threat Taxonomy and BSI

Threat Catalogue

Attacker landscape proposed

Impact criteria

CYBERSECURITY CONTEXT FOR RAILWAY

Impact criticality

level Impact criticality description per level

4

Safety: Major loss of life.

Financial: > 10% of the turnover.

Performance: All users experience prolonged and unplanned disruption to key routes. Access to major station facilities likely to be severely restricted.

Reputation: Extensive prolonged adverse national reporting and public disputes with key stakeholders. Compliance: Extensive non-compliance to contracts, regulations and legislation with high penalties & liabilities. Loss of license to operate.

3

Safety: Loss of life, major/severe injuries.

Financial: Up to 10% of annual turnover.

Performance: Unplanned disruption (for up to a week) on multiple routes.

Reputation: Significant local and / or regional reports. National media interest creating public concern. Negative national stakeholder statements. Compliance: Restriction to operate. Major non-compliance to contracts, regulations and legislation with penalties & liabilities.

2

Safety: No loss of life, multiple injuries.

Financial: Up to 3% of annual turnover.

Performance: Unplanned disruption (for up to a week) on any one route or Up to a day on multiple routes.

Reputation: Adverse local media reports over a period. Localised stakeholder concern. Compliance: Medium non-compliance to contracts, regulations and legislation with low penalties & liabilities.

1

Safety: No loss of life, minor injuries.

Financial: Minimal financial impact < 0.2% annual turnover.

Performance: Unplanned disruption (for up to a day) on one route.

Reputation: Adverse local stakeholder reaction. Compliance: Minor non-compliance to contracts, regulations and legislation with Low penalties & liabilities.

69 12.07.2019

Overview of risk assessment process

RISK ASSESSMENT PROCESS

70 12.07.2019

Zone and Conduit architecture proposal

RISK ASSESSMENT PROCESS

71 12.07.2019

DETAILED RISK ASSESSMENT PROCESS

Detailled risk assessment

72 12.07.2019

Security level vector for each generic zones

DETAILED RISK ASSESSMENT PROCESS

Zone S2R WP8 SL-T vectors

FR1-IAC FR2-UC FR3-SI FR4-DC FR5-RDF FR6-TRE FR7-RA FCM

A1 3 3 3 3 3 3 3 3

A2 3 3 3 3 3 3 3 3

B 3 3 3 3 3 3 3 3

C1 3 3 3 3 3 3 3 3

C2 3 3 3 3 3 3 3 3

C3 3 3 3 3 3 3 3 3

C6 3 3 3 3 3 3 3 3

F1 3 3 3 3 3 3 3 3

F2 1 1 1 1 1 1 1 1

G1 3 3 3 3 3 3 3 3

G2 3 3 3 3 3 3 3 3

G3 1/3 1/3 1/3 1/3 1/3 1/3 1/3 1/3

H 3 3 3 3 3 3 1 3

K 3 3 3 3 3 3 3 3

73 12.07.2019

Zone secure architecture proposal (including cybersecurity peripheral protection)

PROTECTION PROFILE DEFINITION

74 02.08.2019

SO1-A1: Provide secure HMI to enter credential

SO2-A1: Secure connection with centralised IAM

server

SO3-A1: Segregate duty and/or apply least

privilege approach

SO4-A1: Application and device authentication

SO5-A1: authorisation enforcement for all users

SO6-A1: Session termination

SO7-A1: Maximum number of simultaneous sessions

SO8-A1: Audit record

SO9-A1: Resilience to audit processing failure

SO10-A1: Timestamp management

SO11-A1: Communication authenticity and

integrity

SO12-A1: Verification of security functions

SO13-A1: SW and information integrity and

authenticity check

SO14-A1: Input validation

SO15-A1: Fail secure function

SO16-A1: Error handling

SO17-A1: Confidentiality at rest

SO18-A1: Memory purge at decommissioning

SO19-A1: Volatile memory management

SO20-A1: Use of cryptography for information at rest

SO21-A1: Physical network segregation

SO22-A1: Monitoring of security function

SO23-A1: DDOS attack resilience

SO24-A1: Limit resources allocated to security

function

SO25-A1: Support backup system.

SO26-A1: secure reconstitution

SO27-A1: Secure configuration

SO28-A1: Least functionality

SO29-A1: Component inventory

SO30-A1: Malicious code protection

SO31-A1: Support for update and patch

management

SECURITY OBJECTIVE DEFINITION

75 12.07.2019

Top-down approach: patch

management analysis

ISA/IEC 62443-2-3 provides a solid frame for

railways, but still research has to be undertaken to

give guidance to the industry stakeholders to

establish an industry adjusted and aligned

vulnerability and patch management program.

X2RAIL-3 Task 9.5 Demonstrator 1: Verification of

patch management process

Bottom-up approach: DMI analysis

ISA/IEC 62443 series and tenders provide high-

level requirements.

X2RAIL-3 D8.1 Guidelines for railway cybersecurity

design and implementation on the railway

signalling system

Security by design investigated through 2 approaches:

APPLICATION OF SECURITY BY DESIGN: USE CASES


Questions?


19

partners

Budget of

45 M €

3

Years Duration

2016

WP3 WP3 WP3

WP4 WP3

WP5 WP4 WP4

WP3 WP5

WP4 WP4

WP6 WP5 WP6

WP5 WP7

WP6

WP7

WP6 WP5

WP7 WP6

WP8WP8

WP9WP8

TD2.11 - Cyber Security

TD2.2 - ATO Up to GoA4

TD2.3 - Fluid moving block

TD2.4 - Fail safe train pos. (GNSS)

TD2.5 - On Board Train Integrity

TD2.6 - Zero on site testing

TD2.7 - Formal Methods

TD2.8 - Virtual Coupling

TD2.9 - Traffic Management evolution

TD2.10 - Smart radio connected object contr.

IP2TD2.1 - Adaptable comms.

2017 2018 2019 2020 2021 2022

Thank You and enjoy the Railway hall!

Welcome to the Final Event - projects.shift2rail.org

Documents

Transcript of Welcome to the Final Event - projects.shift2rail.org