OC ConceptUmbrella DocumentVersion 13_published 3042018

1 Disclaimer

This document is a DRAFT version which is still under construction Its content may change in the ongoing concept phase of

SmartRail 40 The document is not completely verified and is not finalized by now The document is published to enable an

open discussion of the ongoing work of the SmartRail 40 program

Links and references inside of this document may refer to other documents inside of the program SmartRail 40 that may not be

published at this stage

ES Object Controller

OC Concept Umbrella Document (rev 86972)

126 SBB CFF FFS 2018-05-27 2224

Content1 Disclaimer 1

2 List of Figures 2

3 Glossary 3

4 Introduction 5

5 Objectives (EN 50126 sect611) 5

51 Objectives of this concept document 5

52 OC and Y-switch product goals 6

53 OC and Y-switch safety goals 7

6 Requirements 8

7 General function description 9

71 Functional OC model based on a modularization which supports optimal procurement reference points 9

72 Innovative safety-relevant parts of the OC and their treatment in subconcepts 10

721 Control of the TAs by the legacy interlocking (LI) 10

722 Interlocking switchover 13

723 Control of the TAs by the ETCS Interlocking (EI) 13

7231 Communication between EI and OC via Transfer System TS 14

724 Translation Configuration Profile harr Todays TA Control Signals and Messages 16

725 Connection of existing TAs 16

7251 Main- pre- block- combination signals 16

7252 Dwarf signals (dt Zwergsignale ZS) 17

726 Trackside assets in general 17

73 Power supply and S-interface Air-conditioning 17

74 Y-switch spatial arrangement 18

741 Version 1 18

742 Version 2 19

75 OC-life-cycle in the OC rollout phases 21

751 OC rollout phase 0 Preponed Y-switch rollout (about 2021 - 2024) 21

752 OC rollout phase 1 Start of the OC rollout until the end of the EI-Migration (from approx 2024) 21

753 OC rollout phase 2a For OCs which can be dismantled with their TAs thanks to SR40 (end of EI migration to TA-decommissioning) 21

754 OC Rollout Phase 2b For OCs which become redundant with the evolution of their TAs (end of EI migration until the replacementwith new TAs with integrated OC functionality ie without requirement of external OCs) 21

755 OC rollout phase 3 Life cycles of the TAs with integrated OC functionality ie without requirement of external OCs 22

76 Operation and maintenance concept 22

761 Operational concept 23

762 Maintenance Concept 23

77 Alternative approach OCs as soft OCs in current eStws 24

8 Pending items and working hypotheses 24

81 Y-Switch 24

82 Y-Switch shadow-mode 24

83 OC TOPO 25

84 OC rollout and migration 25

85 OC operation 25

9 Sources References 26

2 List of FiguresFigure 1 Overall view of the OC peripheral- and subsystems as the basis for the approval concept

Figure 2 OC reference model

Figure 3 The modularisation of the OC in innovative safety-relevant components and its treatment in subconcepts (SC)

Figure 4 Control via LI with threaded Y-switches

Figure 5 Todays manual Y-switches

Figure 6 Control by EI with threaded Y-switches

ES Object Controller

OC Concept Umbrella Document (rev 86972)

226 SBB CFF FFS 2018-05-27 2224

Figure 7 Basic safety architecture

Figure 8 Selected levels of the OC TOPO model

Figure 9 version 1 Arrangement of the modules at the time of commissioning

Figure 10 version 1 Arrangement of assemblies after final Clean-up

Figure 11 version2 Arrangement of the modules at the time of commissioning

Figure 12 version 2 Arrangement of the assemblies after final Clean-up

Figure 13 Categories operation and maintenance

Figure 14 Impact and terms of maintenance

3 Glossary

Term Abbrev Description

Configuration Profile CP It is an OC data model which includes the configuration data in its entirety

ETCS Interlocking EI ETCS FSS based interlocking comprising the RBC Its dynamic rule based and geometric safety logic

controls all movements of the objects and all changes of the state of the trackside assets within the EIs

effective range All operational logic is moved to the higher-level systems

European Initiative

Linking Interlocking

Subsystems

EULYNX Is an european project with the aim of reducing costs for trackside maintenance an servicing

Fahrdienstvorschriften FDV Der Fahrdienstvorschriften (FDV) sind die Vorschriften welche fuumlr alle schweizerischenEisenbahnen sowie fuumlr alle Bahnen die schweizerische Eisenbahninfrastrukturen guumlltigsind Sie umfassen die sicherheitsrelevanten Regeln fuumlr alle Fahrten auf SchienenDas Bundesamt fuumlr Verkehr erlaumlsst gestuumltzt auf Art 11a der Eisenbahnverordnung vom23 November 1983 EBV (7421411) die Schweizerischen Fahrdienstvorschriften FDVZu den Vorschriftenhttpwwwbavadminchgrundlagen035140353303649indexhtmllang=de Begriffe( httpwwwbavadminchdokumentationvernehmlassung02503indexhtmld )Die Eisenbahnverkehrsunternehmung und Infrastrukturbetreiberin koumlnnen zusaumltzlich zuden FDV verschaumlrfte bzw praumlzisierendere Ausfuumlhrungsbestimmungen erlassen

FRMCS FRMCS Future Railway Mobile Communication System Kuumlnftiges GSM-R Nachfolgesystem Die UIC hat die

Anforderungsspezifikation abgeschlossen und an die Mobilfunk-Standardisierungsorganisation (3rd

Generation Partnership Project 3GPP) uumlbergeben

GLAT GLAT German Acronym Genau Lokalisierbare sichere und Allgemeinverwendbare EndgeraumlteTechnik

translates to exactly locatable safe all purpose end device technology

Legacy Interlocking LI Legacy interlocking system (eg relay and electronic interlocking) that shall be replaced by the ETCS

Interlocking (EI)

Level crossing LX A level crossing is an intersection where a railway line crosses a road or path at the same level

Open safety An interface fulfils the open safety requirements when it is built in a way that allows to homologate

(safety case) the communication partners separately without knowing each other Normally this means a

small protocol and a minimized number of status-combinations and the requirement of a full

testability (test vector reference systems isolated certification) of the component against the interface

specification

See also

ES Object Controller

OC Concept Umbrella Document (rev 86972)

326 SBB CFF FFS 2018-05-27 2224

Figure 7 Basic safety architecture

Figure 8 Selected levels of the OC TOPO model

Figure 9 version 1 Arrangement of the modules at the time of commissioning

Figure 10 version 1 Arrangement of assemblies after final Clean-up

Figure 11 version2 Arrangement of the modules at the time of commissioning

Figure 12 version 2 Arrangement of the assemblies after final Clean-up

Figure 13 Categories operation and maintenance

Figure 14 Impact and terms of maintenance

3 Glossary

Term Abbrev Description

Configuration Profile CP It is an OC data model which includes the configuration data in its entirety

ETCS Interlocking EI ETCS FSS based interlocking comprising the RBC Its dynamic rule based and geometric safety logic

controls all movements of the objects and all changes of the state of the trackside assets within the EIs

effective range All operational logic is moved to the higher-level systems

European Initiative

Linking Interlocking

Subsystems

EULYNX Is an european project with the aim of reducing costs for trackside maintenance an servicing

Fahrdienstvorschriften FDV Der Fahrdienstvorschriften (FDV) sind die Vorschriften welche fuumlr alle schweizerischenEisenbahnen sowie fuumlr alle Bahnen die schweizerische Eisenbahninfrastrukturen guumlltigsind Sie umfassen die sicherheitsrelevanten Regeln fuumlr alle Fahrten auf SchienenDas Bundesamt fuumlr Verkehr erlaumlsst gestuumltzt auf Art 11a der Eisenbahnverordnung vom23 November 1983 EBV (7421411) die Schweizerischen Fahrdienstvorschriften FDVZu den Vorschriftenhttpwwwbavadminchgrundlagen035140353303649indexhtmllang=de Begriffe( httpwwwbavadminchdokumentationvernehmlassung02503indexhtmld )Die Eisenbahnverkehrsunternehmung und Infrastrukturbetreiberin koumlnnen zusaumltzlich zuden FDV verschaumlrfte bzw praumlzisierendere Ausfuumlhrungsbestimmungen erlassen

FRMCS FRMCS Future Railway Mobile Communication System Kuumlnftiges GSM-R Nachfolgesystem Die UIC hat die

Anforderungsspezifikation abgeschlossen und an die Mobilfunk-Standardisierungsorganisation (3rd

Generation Partnership Project 3GPP) uumlbergeben

GLAT GLAT German Acronym Genau Lokalisierbare sichere und Allgemeinverwendbare EndgeraumlteTechnik

translates to exactly locatable safe all purpose end device technology

Legacy Interlocking LI Legacy interlocking system (eg relay and electronic interlocking) that shall be replaced by the ETCS

Interlocking (EI)

Level crossing LX A level crossing is an intersection where a railway line crosses a road or path at the same level

Open safety An interface fulfils the open safety requirements when it is built in a way that allows to homologate

(safety case) the communication partners separately without knowing each other Normally this means a

small protocol and a minimized number of status-combinations and the requirement of a full

testability (test vector reference systems isolated certification) of the component against the interface

specification

See also

ES Object Controller

OC Concept Umbrella Document (rev 86972)

326 SBB CFF FFS 2018-05-27 2224

Reactionless Nonreactive free from feedback or side-effects transparent

Safe Topology EI

TOPO

The safe topological data for use in the EI core

safe as error-free as possible and if errors occur they fall to the safe side and are safely disclosed

SmartRail 40 SR40 A program with disruptive innovations for the processes and Systems of the railway production

Trackside Asset TA Trackside installations such as rail points level crossing barriers signals etc

Traffic Management

System

TMS The production systems for planning scheduling disposition which control CCS- and ATO Systems

Trafficability Level Logical layer of the topology which Expresses the trafficability of something

Trafficability Vector Vector representing the direction dependent Trafficability between two Route Path Nodes Shows the

GOBs driving possibilities (ability to navigate) Has capabilites to secure the Route Path (switch a Point

close a Level Crossing) and to show the safety status Stores capabilities which are direction- and

trafficability related

Transfer System TS Ensures fault-free and secure (safety security) data transmission

Transfer System

Configuration

Management Service

TSCMS Transfer System Configuration Management Service

Y-Switch Technical solution that provides during the migration phase a switching mechanism to alternate the

control of trackside elements between the legacy interlocking systems (LI) and the ETCS Interlocking

(EI)

ES Object Controller

OC Concept Umbrella Document (rev 86972)

426 SBB CFF FFS 2018-05-27 2224

4 IntroductionThe existing SBB-Interlockings are to be operated until 2024 They are either relay (eg Do67) or electronic interlockings (eg

ELEKTRA-2 or SIMIS-W) Hereafter they are referred to as Legacy Interlockings (LI)

The LIs are to be replaced by a new generation of interlocking namely the ETCS Interlocking (EI)

Depending on the architectural scenario in the Smart Rail 40 (SR40) project it is estimated that 30000-70000 trackside assets

(TA) of the current 115000 will remain in operation Each of the remaining ones must be controlled by an EI in the future

The EI will interact with TA-elements by means of a generic protocol (make topology-vector xy trafficable) Additionally to the

physical connection each TA will need a translation function which translates this generic protocol into the control signals of the

existing TA and conversely reports th TArsquos messages and sensory information to the EI as a generic status information

For a rapid migration from the legacy interlockings (LI) to the EI and to minimise the expensive and for the train driver

demanding ETCS level transitions during the migration period the LIs are no longer to be replaced one by one at the end of their

life cycle by a complex commissioning but in bulk segments of about 50 interlockings at once

To enable this construction and commissioning process the TA control needs to be switchable between LI and EI Thus the

preparation processes for commissioning can be accomplished with minimal effort regular operation with the LI during the day

and switchover to the EI for tests at night (eg integration and driving tests to be defined) Whether the ldquoshadow moderdquo required

in the basic concept design (which would require a reactionless monitoring of the TA on the disconnected TA-side of the Y-

switch) can be implemented with an OC external Y-switch needs to be further studied

The basis for the safety-critical applications in SR40 is an actual and correct topology

The OC only needs to know the topology required to describe its own Configuration Profile The approach in which the OC

TOPO selectively supplements or validates the TOPO4 is no longer pursued by the TOPO team The OC-topology data is

validated when registering an OC on the EI (= comparison with the safe EI-topology data) The OC-topology data are thus used

to validate the OCs themselves but not to validate the TOPO4 data

The OC must ensure that its own OC topology is error-free

The OC must always provide the true status of its TAs

The overall process of what needs to be detectedconfigured by whom when and whether automatically or manually will be

defined in the EI-program by mid 2018

A new generation of Object Controllers (OC) is required to meet the above mentioned requirements

Since both the EI and the OCs can be redesigned in the SR40 program there is an unique opportunity to set up a new overall

interlocking harr OC architecture (functional system)

5 Objectives (EN 50126 sect611)

51 Objectives of this concept document

The objective of this Object Controller concept according to the CENELEC EN50126 Phase 1 is to develop an adequate

understanding of the OC system its modularisation and the resulting combinable OC-variants in order to fulfil all subsequent

RAMS life-cycle tasks

The aim of this first version of the Object Controller concept is to enable an initial assessment of its certificability (acceptance)

For this purpose it focuses on the new innovative safety-relevant components of the OC Components which merely

correspond to the current state of the control devices interlockings and trackside assets are partly mentioned but not explained

in detail

The focus lies on the functional concept with the aim of focussing on safety considerations at an early project stage The

reasoning why the innovative components are sufficiently reliable and safe (= result in a safe railway operation) as well as a

basic plan on how to prove the reliability and safety are therefore outlined in the approval concept (Zulassungskonzept)

ES Object Controller

OC Concept Umbrella Document (rev 86972)

526 SBB CFF FFS 2018-05-27 2224

52 OC and Y-switch product goals

The existing interlocking systems contain functions that do not necessarily have to be implemented in their safety-critical section

Such No-SIL-functions are not implemented in the EI but will be realized by the future Traffic Management System (TMS)

Currently there is an enormous variety of interfaces between OC and trackside assets (TA) which has emerged over time

sometimes by historical reasons regional autonomy or in the search for isolated cost-effective solutions To avoid the EI having

to implement a wide range of interfaces and their associated functionalities the OC translates this variety of interfaces and

protocols into a generic protocol and provides a uniform interface between the EI and the trackside assets

In the case of the replacement of old interlocking systems by electronic interlocking for example new TAs suitable for the new

system are typically built in parallel to the existing ones and maintained inactive until the migration night (eg signals are

covered point machines are put on the ground beside the existing point) During the night when commissioning takes place

they are then activated (eg the signals are uncovered the new point machines are installed) The old trackside assets are

deactivated and dismantled during a decommissioning phase The disadvantages of this procedure are

The design and replacing of the trackside assets is expensive and time-consuming

The work on the commissioning night is complex (time resources)

Only a few interlockings can be commissioned per night resulting in many expensive and complex level transitions

between ETCS L2 and L0

There is no longer a fast fall-back possibility to the old interlocking with its trackside assets since eg the point machines

were converted

A bulk migration of about 50 interlockings is thus not feasible Additionally the current method of interlocking replacement

contradicts the central goal of a rapid migration

With the OCs as key elements of the SR40 migration concept the following overall goals are achieved

The OCs allow the existing trackside assets to be used within their life cycle as long as that they are still required

The long-term goal and basis of the SR40 business case is a drastic reduction in the number of trackside assets elements to

the essential points level crossings and the elements necessary for ETCS level transitions (eg to the neighbouring countries

as long as they use a different ETCS level as well as to areas which are not yet controlled by an EI such as private tracks

and persistent old interlockings) Non safety relevant trackside assets such as eg point heaters will not be controlled neither

by the EI nor the OC

New architectures such as ATO (automatic train operation) lead to new types of trackside assets which should be easy to

integrate via an OC

During an initial phase following the migration to EI many of todays types of TAs will still need to be controlled and monitored

by the EI (eg track occupancy circuits as long as not all trains support an autonomous safe and accurate localisation via

GLAT) This requires the provision of OCs which can be disabled or uninstalled at the end of this phase

The OC connects the TAs to the EI The OC performs the conversion of the different TA interfaces with their manifold protocol

characteristics into a standardised protocol to the EI It only discloses the current TA properties capabilities and stati without

disclosing the form of implementation of these capabilities The EI is not aware of the type of TAs (point level-crossing etc) it

only deals with the trafficability of topology vectors the detection and monitoring of objects on the track and their influence in a

generalised manner

The Y-switch enables an extended migration phase which can be prepared in stages per interlocking It connects the TA either

to the legacy interlocking (LI) or to the new ETCS Interlocking (EI) in a switchable manner Additionally to the physical Y-

switch the safe switchover process orchestrated via many participating systems is also an aspect of the OC concept The

bulk migration of the individual interlockings of one entire migration segment can be thus decoupled prepared and tested with

a feasible and plannable contingent of technical experts on site

The OC provides the following advantages

ES Object Controller

OC Concept Umbrella Document (rev 86972)

626 SBB CFF FFS 2018-05-27 2224

Functional decoupling between the interlocking and the OC levels1

Centralisation of the overlying interlocking logic (EI) in a highly availability data centre2

Separation of the life-cycles (independent development innovation replacement times)3

New products and technologies can use existing interfaces4

Independent system procurement (less dependencies from incumbent suppliers wider market)5

Creation of smaller subsystems (interlocking and OC separated) so that more suppliers can participate6

Specification and development of standardised hardware-independent protocols between interlocking and OC (flexible7

architecture improved mixing of different models)

Due to a standardised (previously proprietary) modularisation in the interlocking and the OC the OC enables

Simplification of approvals based on isolated type approvals8

independent and functionally-reduced releases of EI and OC9

53 OC and Y-switch safety goals

OC Safety Target Framework

The OC Safety Target applies to the total amount of all OCs The TAs are not covered by the OC Safety Target Modified cabling

is a separate project covered by a separate SR40 safety budget unless a new type of cabling is introduced with SR40

OC Safety Target

50 of the total SR40 hazard budget is assigned to the OCs Quantitatively this means that1

The collective risk for the railway passengers related to the sum of all OCs shall be less than or equal to 005a

fatalities per year AND

The individual risk rate (risk of death for a single person) related to the sum of all OCs shall be less than or equal tob

015E-05 fatalities per person per year

An OC controls several TAs A physical trackside module (TA Module) generally enables the connection of several2

identical TAs (eg two point machines)

The digital OC central module (Base Module) can manage and control several TA-modules3

The safety target has to be broken down to the corresponding OC modules4

The functional OC refers to the calculated portion of the OC that is necessary for the connection of a trackside element

The safety target of a single functional OC is thus divided between these two modules

The OC guarantees the implementation of actuator commands and the reporting of sensor and system states with the

respectively required functional safety level

The OC does not guarantee cross-TA safety

This safety level is implemented by the EI the OC Base Module TA Module and Y-Switch subsystems

ES Object Controller

OC Concept Umbrella Document (rev 86972)

726 SBB CFF FFS 2018-05-27 2224

Figure 1 Overall view of the OC peripheral- and subsystems as the basis for the approval concept

The Y-switch is installed during the preparatory phase between LI and TA by means of a defined procedure thus guaranteeing

that the previous LI and TA functionality remains unchanged (= safe) and the valid safety processes are ensured

The Y-switch is reactionless (ruumlckwirkungsfrei) concerning reliable and safe functionality of the LI and its TA

The Y-switch enables a safe (in the sense of safety) switching of the connected TA elements No hazards may result from this

In order to ensure synchronisation (EI and LI) the state of the TA elements (eg point locked to the left) must either be known

before operating the Y-switch or be safely identified immediately after switching from the OC

The switching process must prevent the LI from entering an invalid state

Incorrect switching of the Y-switch must be detected and reported by the OC

6 RequirementsThe requirements on the subsystem OC from the basic concept and the SR40 concept are listed on the catalogue of

requirements Anforderungskatalog (V02) where initially the referencing to the subconcepts that address them was made This

served to verify whether all requirements are addressed Following the import and while linking to Polarion consistency with the

higher-level top-down requirements must be ensured Requirements from the SR40 concept will be linked to the overall system

PRQs and then via the architecture to the OC subsystem

The OC shall be realized in such a universal way that it implements not only the SBB requirements but also those of other Swiss

operators such as SOB BLS Thus requirements are used to validate the OC

ES Object Controller

OC Concept Umbrella Document (rev 86972)

826 SBB CFF FFS 2018-05-27 2224

52 OC and Y-switch product goals

The existing interlocking systems contain functions that do not necessarily have to be implemented in their safety-critical section

Such No-SIL-functions are not implemented in the EI but will be realized by the future Traffic Management System (TMS)

Currently there is an enormous variety of interfaces between OC and trackside assets (TA) which has emerged over time

sometimes by historical reasons regional autonomy or in the search for isolated cost-effective solutions To avoid the EI having

to implement a wide range of interfaces and their associated functionalities the OC translates this variety of interfaces and

protocols into a generic protocol and provides a uniform interface between the EI and the trackside assets

In the case of the replacement of old interlocking systems by electronic interlocking for example new TAs suitable for the new

system are typically built in parallel to the existing ones and maintained inactive until the migration night (eg signals are

covered point machines are put on the ground beside the existing point) During the night when commissioning takes place

they are then activated (eg the signals are uncovered the new point machines are installed) The old trackside assets are

deactivated and dismantled during a decommissioning phase The disadvantages of this procedure are

The design and replacing of the trackside assets is expensive and time-consuming

The work on the commissioning night is complex (time resources)

Only a few interlockings can be commissioned per night resulting in many expensive and complex level transitions

between ETCS L2 and L0

There is no longer a fast fall-back possibility to the old interlocking with its trackside assets since eg the point machines

were converted

A bulk migration of about 50 interlockings is thus not feasible Additionally the current method of interlocking replacement

contradicts the central goal of a rapid migration

With the OCs as key elements of the SR40 migration concept the following overall goals are achieved

The OCs allow the existing trackside assets to be used within their life cycle as long as that they are still required

The long-term goal and basis of the SR40 business case is a drastic reduction in the number of trackside assets elements to

the essential points level crossings and the elements necessary for ETCS level transitions (eg to the neighbouring countries

as long as they use a different ETCS level as well as to areas which are not yet controlled by an EI such as private tracks

and persistent old interlockings) Non safety relevant trackside assets such as eg point heaters will not be controlled neither

by the EI nor the OC

New architectures such as ATO (automatic train operation) lead to new types of trackside assets which should be easy to

integrate via an OC

During an initial phase following the migration to EI many of todays types of TAs will still need to be controlled and monitored

by the EI (eg track occupancy circuits as long as not all trains support an autonomous safe and accurate localisation via

GLAT) This requires the provision of OCs which can be disabled or uninstalled at the end of this phase

The OC connects the TAs to the EI The OC performs the conversion of the different TA interfaces with their manifold protocol

characteristics into a standardised protocol to the EI It only discloses the current TA properties capabilities and stati without

disclosing the form of implementation of these capabilities The EI is not aware of the type of TAs (point level-crossing etc) it

only deals with the trafficability of topology vectors the detection and monitoring of objects on the track and their influence in a

generalised manner

The Y-switch enables an extended migration phase which can be prepared in stages per interlocking It connects the TA either

to the legacy interlocking (LI) or to the new ETCS Interlocking (EI) in a switchable manner Additionally to the physical Y-

switch the safe switchover process orchestrated via many participating systems is also an aspect of the OC concept The

bulk migration of the individual interlockings of one entire migration segment can be thus decoupled prepared and tested with

a feasible and plannable contingent of technical experts on site

The OC provides the following advantages

ES Object Controller

OC Concept Umbrella Document (rev 86972)

626 SBB CFF FFS 2018-05-27 2224

Functional decoupling between the interlocking and the OC levels1

Centralisation of the overlying interlocking logic (EI) in a highly availability data centre2

Separation of the life-cycles (independent development innovation replacement times)3

New products and technologies can use existing interfaces4

Independent system procurement (less dependencies from incumbent suppliers wider market)5

Creation of smaller subsystems (interlocking and OC separated) so that more suppliers can participate6

Specification and development of standardised hardware-independent protocols between interlocking and OC (flexible7

architecture improved mixing of different models)

Due to a standardised (previously proprietary) modularisation in the interlocking and the OC the OC enables

Simplification of approvals based on isolated type approvals8

independent and functionally-reduced releases of EI and OC9

53 OC and Y-switch safety goals

OC Safety Target Framework

The OC Safety Target applies to the total amount of all OCs The TAs are not covered by the OC Safety Target Modified cabling

is a separate project covered by a separate SR40 safety budget unless a new type of cabling is introduced with SR40

OC Safety Target

50 of the total SR40 hazard budget is assigned to the OCs Quantitatively this means that1

The collective risk for the railway passengers related to the sum of all OCs shall be less than or equal to 005a

fatalities per year AND

The individual risk rate (risk of death for a single person) related to the sum of all OCs shall be less than or equal tob

015E-05 fatalities per person per year

An OC controls several TAs A physical trackside module (TA Module) generally enables the connection of several2

identical TAs (eg two point machines)

The digital OC central module (Base Module) can manage and control several TA-modules3

The safety target has to be broken down to the corresponding OC modules4

The functional OC refers to the calculated portion of the OC that is necessary for the connection of a trackside element

The safety target of a single functional OC is thus divided between these two modules

The OC guarantees the implementation of actuator commands and the reporting of sensor and system states with the

respectively required functional safety level

The OC does not guarantee cross-TA safety

This safety level is implemented by the EI the OC Base Module TA Module and Y-Switch subsystems

ES Object Controller

OC Concept Umbrella Document (rev 86972)

726 SBB CFF FFS 2018-05-27 2224

Figure 1 Overall view of the OC peripheral- and subsystems as the basis for the approval concept

The Y-switch is installed during the preparatory phase between LI and TA by means of a defined procedure thus guaranteeing

that the previous LI and TA functionality remains unchanged (= safe) and the valid safety processes are ensured

The Y-switch is reactionless (ruumlckwirkungsfrei) concerning reliable and safe functionality of the LI and its TA

The Y-switch enables a safe (in the sense of safety) switching of the connected TA elements No hazards may result from this

In order to ensure synchronisation (EI and LI) the state of the TA elements (eg point locked to the left) must either be known

before operating the Y-switch or be safely identified immediately after switching from the OC

The switching process must prevent the LI from entering an invalid state

Incorrect switching of the Y-switch must be detected and reported by the OC

6 RequirementsThe requirements on the subsystem OC from the basic concept and the SR40 concept are listed on the catalogue of

requirements Anforderungskatalog (V02) where initially the referencing to the subconcepts that address them was made This

served to verify whether all requirements are addressed Following the import and while linking to Polarion consistency with the

higher-level top-down requirements must be ensured Requirements from the SR40 concept will be linked to the overall system

PRQs and then via the architecture to the OC subsystem

The OC shall be realized in such a universal way that it implements not only the SBB requirements but also those of other Swiss

operators such as SOB BLS Thus requirements are used to validate the OC

ES Object Controller

OC Concept Umbrella Document (rev 86972)

826 SBB CFF FFS 2018-05-27 2224

Functional decoupling between the interlocking and the OC levels1

Centralisation of the overlying interlocking logic (EI) in a highly availability data centre2

Separation of the life-cycles (independent development innovation replacement times)3

New products and technologies can use existing interfaces4

Independent system procurement (less dependencies from incumbent suppliers wider market)5

Creation of smaller subsystems (interlocking and OC separated) so that more suppliers can participate6

Specification and development of standardised hardware-independent protocols between interlocking and OC (flexible7

architecture improved mixing of different models)

Due to a standardised (previously proprietary) modularisation in the interlocking and the OC the OC enables

Simplification of approvals based on isolated type approvals8

independent and functionally-reduced releases of EI and OC9

53 OC and Y-switch safety goals

OC Safety Target Framework

The OC Safety Target applies to the total amount of all OCs The TAs are not covered by the OC Safety Target Modified cabling

is a separate project covered by a separate SR40 safety budget unless a new type of cabling is introduced with SR40

OC Safety Target

50 of the total SR40 hazard budget is assigned to the OCs Quantitatively this means that1

The collective risk for the railway passengers related to the sum of all OCs shall be less than or equal to 005a

fatalities per year AND

The individual risk rate (risk of death for a single person) related to the sum of all OCs shall be less than or equal tob

015E-05 fatalities per person per year

An OC controls several TAs A physical trackside module (TA Module) generally enables the connection of several2

identical TAs (eg two point machines)

The digital OC central module (Base Module) can manage and control several TA-modules3

The safety target has to be broken down to the corresponding OC modules4

The functional OC refers to the calculated portion of the OC that is necessary for the connection of a trackside element

The safety target of a single functional OC is thus divided between these two modules

The OC guarantees the implementation of actuator commands and the reporting of sensor and system states with the

respectively required functional safety level

The OC does not guarantee cross-TA safety

This safety level is implemented by the EI the OC Base Module TA Module and Y-Switch subsystems

ES Object Controller

OC Concept Umbrella Document (rev 86972)

726 SBB CFF FFS 2018-05-27 2224

Figure 1 Overall view of the OC peripheral- and subsystems as the basis for the approval concept

The Y-switch is installed during the preparatory phase between LI and TA by means of a defined procedure thus guaranteeing

that the previous LI and TA functionality remains unchanged (= safe) and the valid safety processes are ensured

The Y-switch is reactionless (ruumlckwirkungsfrei) concerning reliable and safe functionality of the LI and its TA

The Y-switch enables a safe (in the sense of safety) switching of the connected TA elements No hazards may result from this

In order to ensure synchronisation (EI and LI) the state of the TA elements (eg point locked to the left) must either be known

before operating the Y-switch or be safely identified immediately after switching from the OC

The switching process must prevent the LI from entering an invalid state

Incorrect switching of the Y-switch must be detected and reported by the OC

6 RequirementsThe requirements on the subsystem OC from the basic concept and the SR40 concept are listed on the catalogue of

requirements Anforderungskatalog (V02) where initially the referencing to the subconcepts that address them was made This

served to verify whether all requirements are addressed Following the import and while linking to Polarion consistency with the

higher-level top-down requirements must be ensured Requirements from the SR40 concept will be linked to the overall system

PRQs and then via the architecture to the OC subsystem

The OC shall be realized in such a universal way that it implements not only the SBB requirements but also those of other Swiss

operators such as SOB BLS Thus requirements are used to validate the OC

ES Object Controller

OC Concept Umbrella Document (rev 86972)

826 SBB CFF FFS 2018-05-27 2224

Figure 1 Overall view of the OC peripheral- and subsystems as the basis for the approval concept

The Y-switch is installed during the preparatory phase between LI and TA by means of a defined procedure thus guaranteeing

that the previous LI and TA functionality remains unchanged (= safe) and the valid safety processes are ensured

The Y-switch is reactionless (ruumlckwirkungsfrei) concerning reliable and safe functionality of the LI and its TA

The Y-switch enables a safe (in the sense of safety) switching of the connected TA elements No hazards may result from this

In order to ensure synchronisation (EI and LI) the state of the TA elements (eg point locked to the left) must either be known

before operating the Y-switch or be safely identified immediately after switching from the OC

The switching process must prevent the LI from entering an invalid state

Incorrect switching of the Y-switch must be detected and reported by the OC

6 RequirementsThe requirements on the subsystem OC from the basic concept and the SR40 concept are listed on the catalogue of

requirements Anforderungskatalog (V02) where initially the referencing to the subconcepts that address them was made This

served to verify whether all requirements are addressed Following the import and while linking to Polarion consistency with the

higher-level top-down requirements must be ensured Requirements from the SR40 concept will be linked to the overall system

PRQs and then via the architecture to the OC subsystem

The OC shall be realized in such a universal way that it implements not only the SBB requirements but also those of other Swiss

operators such as SOB BLS Thus requirements are used to validate the OC

ES Object Controller

OC Concept Umbrella Document (rev 86972)

826 SBB CFF FFS 2018-05-27 2224

7 General function descriptionThe OC functions are described by this umbrella concept and more detailed in subconcepts which explain the innovations in

terms of functionality and safety relevance

Generally it has to be distinguished between the OC as a function and the OC as a physical subsystem (HWSW) installed in

an interlocking room and controlling the trackside asset of an interlocking perimeter As OC procurement options (procurement

of entire Subsystem vs procurement of modules and Integration by SBB) are already an issue in this early CENELEC phase the

physical subsystem view had to be introduced into this concept

71 Functional OC model based on a modularization which supports optimal procurement reference points

Figure 2 OC reference model

Meaning of the reference points

A Interface between the OC and the Transfer System Module (TS Module)

Bm Interface to the existing Interlocking (LI) type m (Example m=Do 67) harr OC

D Remote diagnostic interface

E Interface between the Transfer System and the ETCS interlocking (EI) Functionally identical to the A interface

I Identification and Local Device Management interface Connects safe GLAT tablet harr OC Only a fallback when

device management via M interface is not possible

L OC Internal interface between the Base Module and the TA Modules

M Remote Device Management Interface

S Power supply interface

Wnx Interface Y switch harr Trackside Asset type n subtype x (eg n=barrier motor x= ASSA engine with coal 110V)

Wnx Interface OC harr Y switch for the Trackside Asset type n subtype x Corresponds to the Wnx Interface

ES Object Controller

OC Concept Umbrella Document (rev 86972)

926 SBB CFF FFS 2018-05-27 2224

72 Innovative safety-relevant parts of the OC and their treatment in subconcepts

The following chart shows the innovative safety-relevant parts of the OC their thematic relationships (not to be confused with

precise building blocks and data flows) and their treatment in subconcepts In this context the term innovative should be

understood as meaning that the so designated systems does not correspond to any conventional (state of the praxis) or similar

solution found on the railway environment and therefore has of an innovative nature

Figure 3 The modularisation of the OC in innovative safety-relevant components and its treatment in subconcepts (SC)

721 Control of the TAs by the legacy interlocking (LI)

The legacy interlocking is connected by means of existing cabling to its existing TAs thereby implementing a safe rail operation

As a preparation for the EI migration the so-called Y-switches are introduced When unpowered or controlled to their initial state

ldquoLI controlrdquo they connect the LI with its existing TAs When switching on the power supply of the Y-switch it shall be ensured

that this state is not changed

ES Object Controller

OC Concept Umbrella Document (rev 86972)

1026 SBB CFF FFS 2018-05-27 2224

Figure 4 Control via LI with threaded Y-switches

The electrical connection between the LI and the TAs after installation of the Y-switch is identical to the situation before the

installation

Definition of the initial position of the Y-switch

When no switching control voltage is applied the Y-switch shall assume a non-activated state and take the position ldquoLI

controlrdquo

When connecting the control cable it shall be made sure that the switching control voltage corresponds to the initial

position

The standalone Y-switches can already be installed before the OC rollout since they transparently connect the TA to the LI in

the initial position

In previous interlocking migration projects manual Y-switches have already been successfully implemented Terminal blocks

with contact strips were used to galvanically connect the TAs either to the old or the new interlocking

ES Object Controller

OC Concept Umbrella Document (rev 86972)

1126 SBB CFF FFS 2018-05-27 2224

Figure 5 Todays manual Y-switches

This previous manual switch requires three complete extensive functional tests by SA-technicians and test experts (SIOP-B) in

the interlocking room as well as several SA-technicians each with a security guard at the TA (the security guards are not

necessary in the case of a secured perimeter)

when equipping the original terminal blocks with the manual Y-switches1

during the definitive switchover to the new interlocking2

when dismantling the manual Y-switches3

The first and third tests are necessary to rule out incorrect wiring the second to detect and eliminate any wiring changes during

the period between installation and final switchover

In the new OC migration After ensuring that all switchover conditions have been met the change must be remotely controlled by

a centralised function so that switchovers can take place simultaneously in several interlockings The switchover conditions are

described in Subconcept Interlocking Switchover

Variant 1a The (remotely controllable) Y-switch can be physically mounted on existing terminal blocks

Version 1b (preferred if feasible) The switchover function (relay mechanical switch) is implemented as an integral part of a new

terminal type which replaces the existing terminal blocks

Other variants are to be considered including an OC with an integrated Y-switch which does not switchover galvanically

between interlockings but digitizes and processes the trackside signals for both the LI and the EI

Functionally the switchover command to the Y-switch is generated by an instance which is superordinate to the interlocking

In the interlocking room the switching signals to the Y-switches can be implemented via ILTIS (variant a) or via OC (variant b) in

the interlocking facilities

Variant a is based on the hypothesis that proven ILTIS interfaces can be used

Variant b is based on the hypothesis that the switchover command is initiated OC externally and transmitted via EI and

OC to the Y-switch For this purpose the OC provides a separate switching interface generated on a general IO TA

Module

The effort for the first and third functional tests are acceptable when installing the Y-switch since the installation can be

performed sequentially LI by LI The second functional test is not required if wiring changes during the period between

installation and the final switching can be excluded eg procedurally or by automated testing

ES Object Controller

OC Concept Umbrella Document (rev 86972)

1226 SBB CFF FFS 2018-05-27 2224

Due to the technical characteristics of the Y-switch the non-reactiveness is ensured and can be demonstrated

The detailed Y-switch concept is described in Subconcept Interlocking Switchover

722 Interlocking switchover

Beyond the physical Y-switch the interlocking switchover includes many system-specific and process-related aspects that are

safety-relevant and include new approaches that go beyond the state of the art

Switchover aspect 1 is the switching of the TA control from LI to EI at the beginning of a test night and the corresponding

switching back before the start of the productive operation

Switchover aspect 2 is the control of the operational readiness after the switchover and reverse switching

The switchover aspect 2 must be able to reoccur almost without manual function control since it should occur simultaneously for

several interlockings

This requires a secure switching process orchestrated over many involved systems (LI with its auxiliary systems ILTIS TMS-L

EI OC and TAs) and roles (test managers dispatchers)

This switching process is described in Subconcept Interlocking Switchover

Unpowered old object controllers of the LI can cause problems when re-powered on reverse switching and must be reset

manually This corresponds to the already known problems eg with Simis-C With the requirement of a possible automatic

switchover and reverse switching this must be avoided whenever possible Should this not be possible an employee must be

on-site to handle the Simis-C interlocking

723 Control of the TAs by the ETCS Interlocking (EI)

By setting the switch position to ldquoEI controlrdquo the Y-switch galvanically connects the ETCS Interlocking with the existing TAs

Figure 6 Control by EI with threaded Y-switches

The innovative safety-related components of the EI control are described from the left (EI) to the right (TA)

ES Object Controller

OC Concept Umbrella Document (rev 86972)

1326 SBB CFF FFS 2018-05-27 2224

7231 Communication between EI and OC via Transfer System TS

The data connection between EI and OC is defined as an independent subsystem Transfer System (TS) with its own type

approval

This differentiation is of great importance for cost-effectiveness security innovation use in heterogeneous communication

environments and for international applicability

This encapsulation makes the Transfer System technically independent and manageable simplifies operation and thus

separates the approval process for the EI the Transfer System and the OC from one another (open safety) Not all EI-

TS-OC system permutations must be approved This reduces the approval effort with corresponding economic and

temporal advantages not only for the operator but also for the approving authority

EI TS and OC can be procured independently Less system dependencies lead to a larger number of suppliers

participating on the bidding process

Separation of the TS short life-cycle from the longer EI and OC life-cycles The technology life-cycles of communication

technologies and IT security mechanisms (encryption algorithm key length etc) are shorter than the estimated EI and

OC life-cycles It is assumed that due to new IT-threats the IT security processes must be adapted in an agile manner

This agility is not readily possible in an OC which is developed according to CENELEC SIL4

The country-specific proportion is reduced

The EI controls the OC which is responsible for the TAs by means of the so-called Configuration Profile (CP)

For control and monitoring tasks the Traffic Management System (TMS) communicates with the OCs via the EI

Eg the TMS receives the TA properties which it must consider from a timing aspect via EI

The Transfer System is a loosely coupled system with its own remote diagnostic interface and a remote device management

interface

The so-called Transfer System Connector (TSC) is a service that enables the use of a specific transfer channel provided by the

TS Module for the safe amp secure transmission of data

The TSC service is performed on the same hardware and the same OS as the user application (eg OC) It offers a type-safe

API-service

To connect the Transfer System and the application respectively the TSC a bus is set up (sensibly a category 1 solution)

The A and E interfaces are kept very simple stable and deterministic in physical and logical terms

This enables the implementation of the open safety-strategy the extent of the mutual state permutation and thus the test scope

for the interface is limited

The A-Interface is decentralised There is one A-Interface per OC

The A-Interface is implemented as a proven standardised state-of-the-art interface eg Ethernet

The functionally identical E-interface is centralised and comprises the communication to many OCs the number of which

depends on the area segmentation

The E and A interfaces are unencrypted To ensure physical safety and security the Transfer System Module must be physically

and safely connected to the OC The Transfer System is therefore not implemented as an isolated box but as a hardware

module which is physically hosted in the OC but is not part of the OC

The security architecture features the following basic structure

ES Object Controller

OC Concept Umbrella Document (rev 86972)

1426 SBB CFF FFS 2018-05-27 2224

Figure 7 Basic safety architecture

The open safety principle is achieved by keeping the standard OC interfaces simple Thus the isolated type approval of an OC

with its TA-specific use conditions (eg use exclusively for point of type XY) is feasible The approval effort is thus significantly

reduced as the interlockingOC combination does not require to be cross-checked and approved for all conceivable permutations

as to overall correct behaviour

The communication using the Configuration Profile (CP) forms the basis for the simple interface to the EI The CP covers the

following areas

The CP is the data model (tree-structure) of the OC storage of all static and dynamic values of the runtime configuration

It contains the properties (identification and information data) and capabilities (declared functions that can be used externally) as

well as the status (=actual states) of the OC and the TAs controlled by it

The CP representation in the OC is synchronised bi-directionally with the CP-representation in the communication partner (eg

EI) by means of functions provided by the Transfer System Connector TSC

Via this synchronised CP the EI can

request trafficability for the track topology under the OCrsquos responsibility in the form of the so-called ldquotrafficability vectorsrdquo

which are to be secured (eg points)

recognise and monitor objects on the track via OC (eg track circuits and axle counters)

control movements and objects on the track via OC (eg signals)

The OC maps the TA status (eg NotSecured Transient Secured SecuredAndLocked) as well as the route-related TA

capabilities and properties as trafficability vectors The trafficability vectors are identified based on the safe topology

The concept for the communication of the EI with the OC (E A and A Interface) explained in detail in the subconcepts ldquoTransfer

Systemrdquo Transfer System Connector and Configuration Profile Synchronizationldquo

The detailed concept of Run Modes and Runtime Configuration via Configuration Profile is described in Subconcept Modes of

Operation and Configuration

The TA configuration aspect of the CP is based on an error-free and up-to-date topology of the TA under the OCacutes responsibility

An error-free and up-to-date topology is one of the main pillars of SR40 and the basis for the safe interworking of EI OC GLAT

etc

The Subconcept OC TOPO describes the OC topology model The OC-controlled infrastructure objects must be registered

correctly and be up-to-date in this model so that the OC and the EI can process them adequately

The so-called trafficability level is of central significance for the OC as a link between the existing TA and the EI

ES Object Controller

OC Concept Umbrella Document (rev 86972)

1526 SBB CFF FFS 2018-05-27 2224

Figure 7 Basic safety architecture

The open safety principle is achieved by keeping the standard OC interfaces simple Thus the isolated type approval of an OC

with its TA-specific use conditions (eg use exclusively for point of type XY) is feasible The approval effort is thus significantly

reduced as the interlockingOC combination does not require to be cross-checked and approved for all conceivable permutations

as to overall correct behaviour

The communication using the Configuration Profile (CP) forms the basis for the simple interface to the EI The CP covers the

following areas

The CP is the data model (tree-structure) of the OC storage of all static and dynamic values of the runtime configuration

It contains the properties (identification and information data) and capabilities (declared functions that can be used externally) as

well as the status (=actual states) of the OC and the TAs controlled by it

The CP representation in the OC is synchronised bi-directionally with the CP-representation in the communication partner (eg

EI) by means of functions provided by the Transfer System Connector TSC

Via this synchronised CP the EI can

request trafficability for the track topology under the OCrsquos responsibility in the form of the so-called ldquotrafficability vectorsrdquo

which are to be secured (eg points)

recognise and monitor objects on the track via OC (eg track circuits and axle counters)

control movements and objects on the track via OC (eg signals)

The OC maps the TA status (eg NotSecured Transient Secured SecuredAndLocked) as well as the route-related TA

capabilities and properties as trafficability vectors The trafficability vectors are identified based on the safe topology

The concept for the communication of the EI with the OC (E A and A Interface) explained in detail in the subconcepts ldquoTransfer

Systemrdquo Transfer System Connector and Configuration Profile Synchronizationldquo

The detailed concept of Run Modes and Runtime Configuration via Configuration Profile is described in Subconcept Modes of

Operation and Configuration

The TA configuration aspect of the CP is based on an error-free and up-to-date topology of the TA under the OCacutes responsibility

An error-free and up-to-date topology is one of the main pillars of SR40 and the basis for the safe interworking of EI OC GLAT

etc

The Subconcept OC TOPO describes the OC topology model The OC-controlled infrastructure objects must be registered

correctly and be up-to-date in this model so that the OC and the EI can process them adequately

The so-called trafficability level is of central significance for the OC as a link between the existing TA and the EI

ES Object Controller

OC Concept Umbrella Document (rev 86972)

1526 SBB CFF FFS 2018-05-27 2224

Figure 8 Selected levels of the OC TOPO model

The TAs which are positioned in an up-to-date and error-free way at the Material Level as Positioning Nodes are abstracted

on the Trafficability Level by trafficability vectors These are the common language of EI and OC Based on these trafficability

vectors the EI requests trafficabilities from the OC via the Configuration Profile The TA status and the route-related TA

capabilities and characteristics are also tied to these trafficability vectors

The Subconcept OC TOPO explains how OC and EI provide the basis for the safe traffic route on the infrastructure side via

trafficability vectors

The concept for the error-free and up-to-date positioning of new or modified TAs for representation on the material level does not

yet exist It will be developed in coordination with the TOPO4 project

724 Translation Configuration Profile harr Todays TA Control Signals and Messages

The trafficability vectors secured by the EI must be translated safely from their abstract representation in the Configuration

Profile into the TA control signals Conversely the TA messages must be translated safely as status into the abstract

representation in the Configuration Profile

To keep the number of hardware TA Modules low the TA connection is realized by a combination of TA modules Eg the direct

connection of a level crossing may use one (of several) motor control interfaces of a generic Motor TA Module plus one (of

several) IO signals of a generic IO TA Module etc

The Subconcept CP-to-L Translation describes this translation and binding Configuration Profile Translation (mapping)

Binding of units (combination and scaling) It also explains the generic (ie non-TA-specific) L-Interface and the binding of the

trafficability vectors to the physical TA-interface

725 Connection of existing TAs

The subconcepts Trackside Asset connection ( Subconcept Clear Track Signalling Installation Subconcept Block

Subconcept Level Crossing and Subconcept Point Controller) explain the TA connection

7251 Main- pre- block- combination signals

If the FDV (Fahrdienstvorschriften) can be adjusted so that signal coverage during test nights and segment migration is not

necessary and the signals can indicate any driving command these signals need not be controllable by the EI This adjustment

should be arguable as the test train drivers can be trained specifically and can handle L2 contradictory driving commands in the

ETCS L2 perimeter

If the FDV can only be adapted to the extent that a signal coverage during test nights and the segment migration is not

necessary but the signals must be equipped with a white triangular extension and dimmed analogous to the dwarf signals the

Y-switch must turn off the signal current

ES Object Controller

OC Concept Umbrella Document (rev 86972)

1626 SBB CFF FFS 2018-05-27 2224

7252 Dwarf signals (dt Zwergsignale ZS)

Until the OC rollout start planned for 2024 the ETCS standard may not yet contain functionalities that enable cab-signalling for

shunting Even MTC the SR40 shunting solution will not be available on a nationwide scale until then Thus a dwarf signal OC

will probably have to be developed Whether or not the rollout of this OC also occurs can be decided later Since the ZS-

interface is standardised and the ZS always initialises correctly after LIEI switchover the implementation is classified as non-

critical and is therefore not further elaborated in this concept version

The challenge of the dwarf signal migration will be that the ZS will have to comply with the ETCS shunting signal after the

migration of the segment In contrast to the classic ZS it has blue LED light points and is not set to ldquoFahrtrdquo in an ETCS Train

movement (Zugfahrt)

During the migration preparation phase during which the ZS control is switched from LI to EI and back for testing the white light

points can be left as they are as the test-train-drivers test-shunting teams etc are prepared for their modified meaning

In particular the test drivers on open track (Streckenlokfuumlhrer in contrast to Rangierlokfuumlhrer) are to be made aware of the fact

that ZS switched from EI to ldquoStoprdquo may be run over the train drivers however must not become used to this

Shunting tests under the control of the EI are possible as the ZS displays the standardised driving command simply with white

instead of blue light points

With the start of productive operation after the final segment-wide switchover to EI all ZS lamps must be replaced by blue

LEDs If this is not possible in one night transitional solutions must be defined with the Control Group on Operational Safety

(ldquoSteuergruppe Betriebssicherheitrdquo) and agreed with the BAV via PampA

726 Trackside assets in general

The reaction times of TAs (eg rotation times of points) are permanently measured by the OC and managed as corresponding

capability in the Configuration Profile

The OC monitors its W-interfaces for connection interruption it is used to procedurally detect manipulations of TAs and their

cabling Detected manipulations are alarmed to the Network Management System where adequate action is taken eg sending

FieldForce out to confirm a point position (requirement from HLSA-206 Generally wrong point position following maintenance

work at the point)

This requirement does not apply if until the migration the CH-wide point position detection has been introduced by I-AT-SAZ

In the subconcepts ldquoTrackside Asset connectionrdquo ( Subconcept Clear Track Signalling Installation Subconcept Block

Subconcept Level Crossing and Subconcept Point Controller) a separate subconcept per TA type describes the connection

(physical part = electrical signals and process-related part = protocol) of the TA type

73 Power supply and S-interface Air-conditioning

While TA control is switched to EI the object controllers of the LI could theoretically be switched off so that the existing power

supply and air-conditioning would be sufficient However the expense of properly retrofitting a remote controlled LI object

controller shutdown would be unduly high and switching back to the LI would be more complex

Thus the power supply must be powerful enough to feed both LI and OCs simultaneously

The power supply extension to be implemented must be sufficiently available (uninterrupted power supply - UPS) according to

the current state of the art (commercial cabinet power supplies) It will be determined in the rollout planning whether the

reinforcement of the power supply can be performed with temporary units (mobile UPS)

The necessary TA voltages are created by the OC The OC itself thus only needs to be supplied by one UPS voltage

ES Object Controller

OC Concept Umbrella Document (rev 86972)

1726 SBB CFF FFS 2018-05-27 2224

74 Y-switch spatial arrangement

The following spatial arrangement versions are available to install EI OC and Y-Switch

741 Version 1

The version 1 is favoured It can be implemented if the Y-switches can be made compact enough to the extent that they can be

mounted directly on existing terminal blocks or even replace the current terminal blocks altogether

OCs

If possible the OCs are to be assembled in the interlocking site If there is not enough space they will be assembled in an

external construction container The relevant details will be developed in 2018 in the OC migration concept

Y-switch

Y-switches are attached to the terminal blocks each connecting one TA to the existing control section of the LI and to the1

OCs

In the case of track occupancy sensors (track circuits axle counters) some electronic sets enable the connection of two2

interlockings per GFM unit These electronic sets do not require Y-switches (The figure below shows Y-switches on all

electronic sets)

In the case of axles counters with resetting these Y-switches are attached to the terminal blocks of the registers3

No Y-switches are attached to TAs which do not need to be migrated4

Figure 9 version 1 Arrangement of the modules at the time of commissioning

Clean-up

After the EI has been commissioned the assemblies of the old interlockings which are no longer required are to be removed

If the modules of the EI had to be assembled in a construction container they are to be transferred to the interlocking room and

the construction container is disassembled The relevant details as well as the question of whether the Y-switches will be

replaced by normal terminal blocks for safety reasons and for reuse will be developed in the OC-migration concept in 2018

ES Object Controller

OC Concept Umbrella Document (rev 86972)

1826 SBB CFF FFS 2018-05-27 2224

Figure 10 version 1 Arrangement of assemblies after final Clean-up

742 Version 2

The more complex version 2 needs to be implemented if the Y-switches are too large to be assembled directly on the existing

terminal blocks

OCs

If possible the OCs are to be assembled in the interlocking site If there is not enough space they will be set up in a construction

container Location and cabling are to be defined in the rollout planning for each LI

Y-switch

Branches are attached to the terminal blocks each one diverting the connection of a TA to a Y-switch1

In the case of axle counters and track circuits similar branches are attached to the terminal blocks of the electronics sets2

Some electronic sets already allow the connection of two actuators per track release message With these electronic kits

the OC can be connected directly to the electronics set (In the figure below branches are shown on all electronic sets)

In the case of TAs which do not need to be migrated (signals etc) no branches are attached3

The Y-switches could be integrated into the OC in this arrangement This enables the implementation of additional4

functions in the Y-switches

ES Object Controller

OC Concept Umbrella Document (rev 86972)

1926 SBB CFF FFS 2018-05-27 2224

Figure 11 version2 Arrangement of the modules at the time of commissioning

Clean-up

After the EI has been commissioned the assemblies of the old interlockings which are no longer required are removed

If the modules of the EI needed to be assembled in a construction container they are to be transferred to the interlocking room

and the construction container is to be disassembled

The branches are removed

The relevant details as well as the question of whether the Y-switches will be replaced by normal terminal blocks for safety

reasons and for reuse will be developed in the OC migration concept in 2018

Figure 12 version 2 Arrangement of the assemblies after final Clean-up

ES Object Controller

OC Concept Umbrella Document (rev 86972)

2026 SBB CFF FFS 2018-05-27 2224

75 OC-life-cycle in the OC rollout phases

Illustration 1 OC-life-cycle in the OC rollout phases

751 OC rollout phase 0 Preponed Y-switch rollout (about 2021 - 2024)

The standalone Y-switches can already be installed before the OC rollout as they connect the TA reactionlessly to the LI in its

uncontrolled state

Analysis with SBB PJ and the industry have shown that rapid punctual installation of the Y-switches is not efficient every time an

TA connection is changed from now on Also this approach would result in high administrative overheads (what was already

modified and what was not) Overall it is more efficient cheaper and qualitatively better when a specialised Y-switch team

implements the rollout on a CH-wide scale interlocking room by interlocking room

752 OC rollout phase 1 Start of the OC rollout until the end of the EI-Migration (from approx 2024)

Additionally to the sustainably (up to and including the OC rollout phase 2a) existent TA types many of todays TA types must be

temporarily controlled by the EI Their respective states must be identifiable (eg track-release message since not all trains

support autonomous accurate and safe localisation via GLAT) For this purpose some OCs need to be provided which can be

dismantled during the OC rollout phase 2a

753 OC rollout phase 2a For OCs which can be dismantled with their TAs thanks to SR40 (end of EI migration to TA-

decommissioning)

With the decoupled development of SR40 parts such as GLAT the temporary OCs of OC Rollout Phase 1 can be dismantled

before the end of their life cycle (advance depreciation) When and for which TA types this thinning out is deployed depends

on the scheduling of the SR40 partner programs

754 OC Rollout Phase 2b For OCs which become redundant with the evolution of their TAs (end of EI migration until

the replacement with new TAs with integrated OC functionality ie without requirement of external OCs)

The goal (to be confirmed) prior to this phase is on the basis of economic criteria to integrate the OC functionality into the future

TAs ie for the OC interfaces A D M and I specified by SR40 together with the dialogue partners to become internationally

standardised TA interfaces analogous to EULYNX

ES Object Controller

OC Concept Umbrella Document (rev 86972)

2126 SBB CFF FFS 2018-05-27 2224

755 OC rollout phase 3 Life cycles of the TAs with integrated OC functionality ie without requirement of external

OCs

Based on the already rapid development of the Internet of Things it can be assumed that until the OC rollout phase 3 the

availability of mobile network access for systems with low data transmission will be high enough to the extent that the TAs

already optionally contain the OC functionality and can connect directly via mobile IP to the EI Depending on the life-cycle of the

existing TAs and the availability of these new TA types the OC rollout Phase 3 may overlap with Phase 2 The mobile

transmittersreceivers will be so robust miniaturised energy efficient and cheap that with high probability they will be able to

replace the current field bus

The mobile network may be the FRMCS (Future Railway Mobile Communication System) Alternatively mobile networks of

public operators that require to be combined due to their lower availability In general terms before this phase the availability of

all mobile networks will need to be analysed due to the fault situation the workload repair times etc

With the spread of TA which directly supports the A D M and I interfaces the separate OCs become redundant except for

individual types connecting special TAs The start and duration of this streamlining process depend on the TA industry and the

TA life cycle strategies of the railways

76 Operation and maintenance concept

The overall view of operation and maintenance of the OC (figure below) can be broken down into the following categories which

relate to the roles of operator and supplier and their processes

Operation respectively (manual) handling1

Technical operation2

Maintenance3

Value preservation4

System adaptation5

Figure 13 Categories operation and maintenance

The operation or maintenance comprises all functions of the OC which relate directly to the manual part of the future railway

operation These are monitoring activities such as accepting fault messages (eg barrier jams) by the railway company (train

traffic management) manually performable activities such as the triggering of a self healing activity (eg troubleshooting of a

point) and others

ES Object Controller

OC Concept Umbrella Document (rev 86972)

2226 SBB CFF FFS 2018-05-27 2224

The technical operation covers all activities around the OC system operation

Monitoring via the Central Diagnosis Layer in the Network Management System currently IBM Netcool (urgent non-1

intrusive alarms notes etc) For this purpose SR40 must implement an overall concept together with the technical

operation

Control (status and error messages etc)2

Analysis (assessment of OC conditions etc)3

Corrective and preventive maintenance covers all activities in the areas of inspection maintenance and repair The detailing

takes place within the framework of the maintenance concept

Value preservation includes ongoing activities to maintain the OC platform up-to-date (eg replacement of OCs with newer

generations)

The system adaptation includes the implementation of new functions (new capabilities new interface to TA etc) within the OC

system

The role of the operator is to provide the required IT service management processes (ITSM) as part of an operational concept to

ensure the operation or technical operation of the OC system

The role of the supplier is to provide the required processes for service and support to ensure maintenance value retention and

system customisation

761 Operational concept

In cooperation with I-B an operational concept for the functional operation of the OC is to be implemented In particular this

relates to the functions of the OC which are connected with manual interactions of the driving service

An operational concept for the technical operation is to be implemented in cooperation with the future technical operation In

particular this relates to the purpose and the use of the M D and I interfaces of the OC

762 Maintenance Concept

The OCrsquoS maintenance overview (figure 14) can be broken down as follows

Preventive maintenance1

Predetermined maintenancea

Condition-based maintenanceb

Corrective maintenance2

Figure 14 Impact and terms of maintenance

The maintenance of OC systems basically includes repairs and replacement of OC systems or OC parts (Base Module TA

Module) as a repair activity

ES Object Controller

OC Concept Umbrella Document (rev 86972)

2326 SBB CFF FFS 2018-05-27 2224

The preventive maintenance of OC systems is performed as part of inspection and maintenance This also includes the analysis

and assessment of diagnostic data

An SR40 concept for predetermined preventive maintenance is yet to be implemented In the case of OC it could be based on

analysis (Big Data) such as

Ageing (eg dependence temperature life-cycle)1

Stress (eg mechanical stress nearby the rails)2

Corrective maintenance is triggered by faults or failures of OC systems (= error-case)

77 Alternative approach OCs as soft OCs in current eStws

In 2024 approximately 30 of the TAs will be connected to electronic points of the Simis W and ELEKTRA 2 types

The option of implementing OCs as new software in subsystems adjacent to internal systems (Simis W the Area Control

Components layer ACC) therefore becomes attractive It would provide benefits such as a simple and easy migration with a

favourable costbenefit ratio However this would not fully implement the targeted modularisation

The subconcepts of Siemens and Thales (under OCs in ELEKTRA_SimisW) describe this option

8 Pending items and working hypothesesIn the next versions of the OC concept the following pending items must be addressed and the working hypotheses must be

confirmed

81 Y-Switch

82 Y-Switch shadow-mode

Additional Y-switch versions must be tested and assessed eg OC with an integrated Y-switch which does not galvanically

switch but picks up all signals and digitises them if required as well as adequately replicate the two interlocking interfaces

depending on the interface type In the analogous case similar to the current analogue signal repeaters (ASR) In this way a

high level of flexibility is implemented to simulate something towards the LI (thus simplifying the morning reverse switching) or to

implement the shadow mode Additionally the entire process is thus digitally controllable and safety-relevant switching errors

can be better monitored detected or suppressed Although the relay terminal block Y is much easier to develop approve and

install there is not much else it can perform Furthermore only the additional replication function and the complicated SiNa are a

disadvantage for the conversion variant as well as possibly the spatial problem which raises additional costs However it also

offers the additional benefit in the event of an early installation of suddenly providing us with system states for other

applications we want to access via the network (WDS point storage risk level crossing optimisation MTC information

requirement and redundant security level etc) even before SR40 is introduced This secondary benefit may possibly be quite

substantial however it must be examined Conclusion As long as there is no hard KO argument against the

conversionrepetition model it must be assessed here If we examine more trivial solutions such as 1a1b we must do so

consciously and justify it here

The Shadow Mode Stakeholders (users of the function enabling EI to listen in via LI in the event of TA control including EI

TMS-L) must be subsequently defined

These stakeholders must define the specific requirements of the shadow mode and quantify the generated benefits so that they

can be offset against the effort

ES Object Controller

OC Concept Umbrella Document (rev 86972)

2426 SBB CFF FFS 2018-05-27 2224

83 OC TOPO

An overall process must initially be defined following an agreement between the Lead Architect and the EI projects AMP and

TOPO4 What has to be automaticallymanually detectedconfigured by whom and when This process must then be accepted

by PJ and subsequently the TOPO functions must be distributed across the technical components within the overall

architecture

84 OC rollout and migration

An OC rollout and migration concept is to be created

85 OC operation

An overall operational cross-SR40 concept is to be created together with the technical operations

ES Object Controller

OC Concept Umbrella Document (rev 86972)

2526 SBB CFF FFS 2018-05-27 2224

9 Sources References

Document

OC Concept Umbrella Document

Subconcept OC TOPO

Subconcept Interlocking Switchover

Subconcept Transfer System

Subconcept Transfer System Connector

Subconcept Transfer System Module

Subconcept Configuration Profile Synchronization

Subconcept Modes of Operation and Configuration

Subconcept CP-to-L Translation

Subconcept Clear Track Signalling Installation

Subconcept Block

Subconcept Level Crossing

Subconcept Point Controller

Subconcept Signal Controller

Transitions under EI

Subconcept M-D-I-Interface

OCs in ELEKTRA_SimisW

Monitoring Concept

Subconcept - SBB W Interface OC-TA

Anforderungskatalog (V02)

OC_Hazardsxlsx

M5 Migrationsprinzip und Uumlbergaumlnge

M6 Bauverfahren Gebaumlude Uumlberlagerung

ES Object Controller

OC Concept Umbrella Document (rev 86972)

2626 SBB CFF FFS 2018-05-27 2224

9 Sources References

Document

OC Concept Umbrella Document

Subconcept OC TOPO

Subconcept Interlocking Switchover

Subconcept Transfer System

Subconcept Transfer System Connector

Subconcept Transfer System Module

Subconcept Configuration Profile Synchronization

Subconcept Modes of Operation and Configuration

Subconcept CP-to-L Translation

Subconcept Clear Track Signalling Installation

Subconcept Block

Subconcept Level Crossing

Subconcept Point Controller

Subconcept Signal Controller

Transitions under EI

Subconcept M-D-I-Interface

OCs in ELEKTRA_SimisW

Monitoring Concept

Subconcept - SBB W Interface OC-TA

Anforderungskatalog (V02)

OC_Hazardsxlsx

M5 Migrationsprinzip und Uumlbergaumlnge

M6 Bauverfahren Gebaumlude Uumlberlagerung

ES Object Controller

OC Concept Umbrella Document (rev 86972)

2626 SBB CFF FFS 2018-05-27 2224