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
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
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 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
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
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
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 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
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
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 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
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
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 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
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
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 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
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
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 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
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
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 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
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 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
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 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
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 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
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 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
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 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
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 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
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 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
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
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
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
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
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
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
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
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
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
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
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