0% found this document useful (0 votes)

100 views

TSC Ievc Doc System Syad V2.0

Uploaded by

Marocain Dbx

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

100 views

TSC Ievc Doc System Syad V2.0

Uploaded by

Marocain Dbx

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 750

iEVC System Architecture Description

ID: tsc_ievc_doc_system_syad
Version: V2.0
Status: Published
Author: Francois Delory
Date: 03/02/2023
Review: !767
Authorized by: Alexandre Betis

Configuration Management
Commit: 7686d0c8

Document signature
b2c00c725888f54563d63f5293b6fdc2681109bb
CONTENTS

1 Revision history [artifact history] 5

2 Introduction 8
2.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Applicable documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Terms and definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Artifacts definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Management of the SyAD 16

3.1 Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Filing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Management of system requirements 17

5 Limitations and open points 19

6 System definition and purpose 21

6.1 iEVC system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2 iEVC certification kits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.3 iEVC Basic kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4 iEVC Sensor kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.5 iEVC Telecom kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.6 iEVC ETCS kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.7 Other Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.8 Component list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7 General description 66
7.1 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.2 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.3 Power supply distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.4 Cycle time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.5 Platform software update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.6 Failure management strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.7 Recovery strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.8 Performance requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.9 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

8 System functional architecture 120

8.1 [IEVC.F1] Develop IEVC applications [function] . . . . . . . . . . . . . . . . . . . . . . . . . . 120
8.2 [IEVC.F3] Run trains under ETCS control [function] . . . . . . . . . . . . . . . . . . . . . . . . 126

2 of 750 CONTENTS
b2c00c725888f54563d63f5293b6fdc2681109bb
8.3 [IEVC.F4] Maintain IEVC in service [function] . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
8.4 [IEVC.F5] Operate trains fitted with iEVC [function] . . . . . . . . . . . . . . . . . . . . . . . . 173
8.5 [IEVC.F7] Manage TSC NET network [function] . . . . . . . . . . . . . . . . . . . . . . . . . . 178
8.6 [IEVC.F8] Supply power to the iEVC boxes components [function] . . . . . . . . . . . . . . . . 179
8.7 [IEVC.F100.LINEAS] Run the train under Lineas specific operating modes [function] . . . . . . 179

9 Safety & Cybersecurity requirements 180

9.1 Requirements derived from PHA mitigations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
9.2 Requirements derived from SHA mitigations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
9.3 Requirements derived from IHA mitigations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
9.4 Requirements derived from HLRA mitigations . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

10 RAM design targets 198

11 Developed components 199

11.1 Sensor box hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
11.2 iBTM-TX module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
11.3 iBTM-RX module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
11.4 Euroantenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
11.5 iODO module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
11.6 iODO Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
11.7 iODO BITE module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
11.8 iODO BITE driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
11.9 Computer Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
11.10 Telecom box hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
11.11 TSC Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
11.12 Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
11.13 Euroradio Safe Functional Module driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
11.14 Euroradio CFM software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
11.15 Euroradio Modem controller Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
11.16 On-Board Operation and Maintenance software . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
11.17 IO driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
11.18 DMI software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
11.19 iBTM application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
11.20 iBTM driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
11.21 DMI Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
11.22 DMI driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
11.23 LRU application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
11.24 TIU application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
11.25 Odometry Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
11.26 ETCS messages application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
11.27 Subset 026 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
11.28 SIDE Authorizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
11.29 SIDE Configurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
11.30 JRU decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602

12 Outsourced Generic Components 605

12.1 Safe computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605
12.2 Wheel pulse generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
12.3 Secondary odometry sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
12.4 Crash Protected Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
12.5 GSM-R Modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
12.6 4G Modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
12.7 DMI hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
12.8 DMI checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
12.9 Ethernet Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689

13 iEVC Configuration 704

13.1 iEVC Configuration data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704

CONTENTS 3 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
13.2 iEVC Configuration Data files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
13.3 iEVC Configuration Data Preparation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

14 Specific requirement 712

14.1 EN50155 requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
14.2 ERA Opinions and BCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
14.3 Design provisions for ERTMS game changers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
14.4 Design provisions for national rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
14.5 Assignment of values to ETCS variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
14.6 Subset 114 Off-line distribution of level 2 keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
14.7 Exported ergonomics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
14.8 Miscellaneous requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737

15 Traceability matrix 742

15.1 URS traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
15.2 Subset 036 traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
15.3 Subset 037 traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
15.4 Subset 040 traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
15.5 Subset 041 traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
15.6 ERA_ERTMS_015560 traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745

16 Appendix 747
16.1 Compatibility with OCORA concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
16.2 Exported requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
16.3 URS functions traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
16.4 Assumptions recapitulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750

4 of 750 CONTENTS
b2c00c725888f54563d63f5293b6fdc2681109bb
CHAPTER

ONE

REVISION HISTORY [ARTIFACT HISTORY]

This artifact version is: V2.0

This artifact signature: b2c00c725888f54563d63f5293b6fdc2681109bb

Name Description Date Author Signature MR

DRAFTV0 First draft released for information 29/04/2020 Alexandre Betis 4199f !202
626f6e6070e96efe626ad
DRAFTV1 second draft released for information 04/11/2020 Alexandre Betis
831511d57f7af673b2a
-
712f0412b9ad3cab2d8d1
V1.0 First release for system baseline IEVC 1.0. 16/12/2020 Francois Delory !373
d9a48bcf2401b7effa9
Update requirement traceability due to ad-
dition of wrongly deleted requirement urs- 1f9de5214568b4f6c6577
V1.1 14/01/2021 Alexandre Betis !356
maintainer-lru-status. Add a requirement to 97aa87adc80152c54b3
OBOM that traces to this requirement.
Update of the references following changes 1ea79d75a27e4f820506e
V1.2 08/02/2021 Alexandre Betis !414
on document names ea7e64a739936e4e74a
!374,
Modifications based on the V1.0 verification !390,
4377655f6a3961b0b62d3
V1.3 comments and based on RAMS team com- 19/02/2021 Francois Delory !399,
78b02571c6c589acb7a
ments !423,
!424
Housekeeping changes. Renaming of 3b118f1bded34c7999c13
V1.4 29/03/2021 Alexandre Betis !438
RAMS plan to safety plan. ba6104a2cb05f415532
Addition of the Euroloop and component re- !440,
set functions. Rework of the Sensor box f5b5ac33e34be0b7a94fd
V1.5 08/04/2021 François Delory !442,
component requirements. Add a second b8535ae07cdc5396c44
KER demodulator in the iBTM-RX. !447
Addition of provision based on measures
from safety analysis for the Sensor box. Up- 0e2bc5bcc8ad04046f1a2
V1.6 15/04/2021 François Delory !462
date of the TSC Net specification based on d29354fadcf1129fb98
software team feedback.
Addition of a traceability matrix between the 36519605c28347e6a08cb
V1.7 05/05/2021 François Delory !463
URS and SyAD functions. b0033a29c92d0fd9d55
Minor Correction: Change the name
of the EN50126 traceability matrix from
8d6bbf329dd499db056b2
V1.8 IEVC EN50126:2018 requirements trace- 14/05/2021 François Delory !478
06cf9d740dc68c047ee
ability matrix to IEVC EN50126:2017 re-
quirements traceability matrix
Minor correction to display correctly the b524f102c968a70b5739c
V1.9 27/05/2021 François Delory !483
safety tag in the requirements ID. 3c233b2d23f52cd0e0b
continues on next page

1. Revision history [artifact history] 5 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Table 1.1 – continued from previous page

Name Description Date Author Signature MR
Update the limitations listed in chapter 5.
Update and-or add the compliance level of
the generic component requirements. Al- François Delory,
11761efa73dd47629aef5
V1.10 locate the URS requirements related to the 04/06/2021 Stéphane Brigant, !482
c3f8ed320ce48d9d3cc
PHA measures and update the safety related Sajad Azizi
flag accordingly. Addition of new PHA-
related requirements in chapter 9.
Minor update after comments from software
4b0271147eb24a2560c84
V1.11 team following the creation of iEVC Soft- 22/09/2021 François Delory !422
e3f2f2387da267bd94e
ware Architecture and Design Specification.
Housekeeping change - Remove reference to 7ca7932016559c79d0eef
V1.12 13/10/2021 Francois Delory !468
obsolete product management plan 1fb879c5c58617221d8
Replace reference to quality manual by ref- d76766137d56d10a4086a
V1.14 15/11/2021 Francois Delory !606
erence to quality plan. 21737712ad75700e55a
Updates related to the System Specification
Baseline 1.4. Refer to the Merge Request
for a detailed description of the changes.
The main modifications are: - Update of the
SFM and CFM interfaces - Detailed allo-
cation of ERA-ERTMS-015560 and update
of the DMI software interface with VM and bf1b58c905a50590bfefd
V1.13 25/11/2021 Francois Delory !566
OBOM - DMI and Safe computer reset is ee0a1767746daa9f99f
now ordered through relays - Ethernet switch
is taken out of the Telecom box - iEVC com-
ponents are now structured by certification
kit - First allocation of FHA measure - Up-
dates related to the verification of the trace-
ability matrix of chapter 15
Housekeeping change - Change of Cenelec 723e4f4a3563e3146e1a0
V1.15 07/01/2022 Francois Delory !524
Requirement List. 0069fcb707122d862ca
"Fix software specification CIs to belong to 86ec1b6f046ea1597edb3
V1.16 01/02/2022 Francois Delory !644
the basic kit." 65d7b7cf4a1b5a27106
Add the ci ’iODO BITE driver’ and adapt the
functional architecture in order for this driver
to manage all the communication with the
iODO BITE board. Add the Tele-powering
mode in the ’Active Euroantenna’ message.
Update the architecture for the LRU appli-
cation in order for it to request the odom-
etry BITE test to the odometry application
instead of commanding directly the iODO
cd9c406a8b8c9a09722b1
V1.17 BITE board. Update the functional scope 15/03/2022 Francois Delory !678
52deb5830321809cf60
of the odometry application in order for it to
control the BITE test sequence and to feed-
back the test result to the LRU application.
Update the content of the following mes-
sages to be in line with the application archi-
tecture: ’Odometry information message’,
’Confidence interval reset order’, ’Odometry
parameters validation’ and ’iODO reset or-
ders’.
Additional traceability required by EN5012x 73db7455cffcfb904a766
V1.18 25/05/2022 Alexandre Betis !868
matrices 7eac89375c1c6845539
Housekeeping change: Align roles and skills 99460a2728df7c54afa6c
V1.19 26/07/2022 Francois Delory !643
in the iEVC program documentation 7bb45cd9274949ed60b
Updates related to the URS V5.5. The iEVC 6eb613af557aea0153da2
V1.20 26/08/2022 Francois Delory !983
ETCS kit is taken out of the iEVC system 60cb1465a7719ecfdbf
Housekeeping change: use generic messages ec8050047e593685a8d78
V1.21 12/09/2022 Eric Schellenberg !973
VM debug command/reply 8df0c7142adc9e0b2b9
House keeping change cleanup vm require- 06901f3e600ddfaca9e0a
V1.22 19/09/2022 Francois Delory !852
ments dd611fc97bc69e08afa
Housekeeping change: remove duplicate abfa6952a23ae2edcc432
V1.23 05/10/2022 Alexandre Betis !1023
lines in traceability matrices. e64f42b22ecbce12f4e
Housekeeping change: cleanup TSC Net 3b776781b8564ebfd4f40
V1.24 17/11/2022 Francois Delory !764
software requirements c01e7e30b454fe40848
continues on next page

6 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Table 1.1 – continued from previous page

Name Description Date Author Signature MR
New release for iEVC system specification b2c00c725888f54563d63
V2.0 03/02/2023 Francois Delory !767
baseline V1.0.5 f5293b6fdc2681109bb

7 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
CHAPTER

TWO

INTRODUCTION

2.1 Context

The IEVC project consists into developing an ETCS on-board inter-operable constituent (IC), as introduced in
[SyAD-R30-CCS:2016]. This project also covers tools developed around this IC.

2.2 Purpose

The purpose of iEVC System Architecture Description (SyAD) is to perform a structured decomposition of the
iEVC system into components and interfaces. For each component and interface, requirements are allocated or
derived from the user requirements allocated to the iEVC.
During the definition of each component and interface, the assumptions made, especially those related to safety,
shall be documented in terms of exported requirements. Constraints on the choice of technology (i.e. independence
of functions, or processes) shall also be documented.
In addition, the impact of common cause and multiple failures shall be studied, both in terms of safety and
availability. If new hazards are identified arising from this analysis, requirements to control these hazards shall be
derived from the new hazards and allocated to the related subsystems and/or components.

2.3 Contents

The document is structured as follows:

• Introduction. This chapter;
• Management of the SyAD recapitulates the rules governing the management of this document;
• Management of system requirements recapitulates the requirements that are going to be used as inputs, and
defines how these requirements are going to be managed in this architecture description;
• Limitations and open points lists the known limitations of the system, as well as the known issues;
• System definition and purpose defines the system, its components, environment and purpose;
• General description describes how the components work together in order to achieve the system purpose. It
covers topics like interfaces, performances, security, timing constraints and communication;
• System functional architecture details the functions of the system, and apportions them to components and
interfaces;
• Safety & Cybersecurity requirements details the safety requirements
• RAM design targets details the Reliability, availability and Maintainability targets of the iEVC system
• Developed components details all the components previously introduced in the architecture that are devel-
oped in the scope of the iEVC system.

8 of 750 2. Introduction
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Outsourced Generic Components describes all components previously introduced in the architecture that
are ‘Generic Components’ in the sense that they are not designed specifically for the iEVC system. These
components are outsourced to TSC suppliers and are considered as provided with the required certification
documentation.
• iEVC Configuration details the iEVC On-board subsystem configuration data, the configuration data files
and the associated configuration process
• Specific requirement defines specific requirements on the system not previously covered;
• Traceability matrix provides the requirement traceability matrix of the SyAD.

2.4 Applicable documents

[SyAD-R55-SIF-iBTM-Euroantenna] iBTM - Euroantenna Interface Specification [id:

tsc_ievc_doc_system_interfaces_sif_ibtm_euroantenna]
[SyAD-R56-SIF-iBTM-VM] iBTM - Virtual Machine Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_ibtm_vm]
[SyAD-R57-SIF-iODO-PG] iODO - Wheel Pulse Generator Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_iodo_pg]
[SyAD-R58-SIF-iODO-SECONDARY] iODO - Secondary Speed Sensor Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_iodo_secondary]
[SyAD-R59-SIF-iODO-VM] iODO - Virtual Machine Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_iodo_vm]
[SyAD-R60-SIF-OBOM-CPM] OBOM - Crash Protected Memory Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_obom_cpm]
[SyAD-R61-SIF-OBOM-DMI] OBOM - DMI Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_obom_dmi]
[SyAD-R62-SIF-OBOM-VM] OBOM - Virtual Machine Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_obom_vm]
[SyAD-R63-SIF-OBOM-4G] 4G Modem - OBOM Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_obom_4g]
[SyAD-R64-SIF-OBOM-MC] OBOM - Modem Controller Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_obom_mc]
[SyAD-R78-SIF-OBOM-PS] OBOM - Power Supply Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_obom_ps]
[SyAD-R65-SIF-CFM-MC] CFM - Modem Controller Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_cfm_mc]
[SyAD-R66-SIF-TSC-NET] TSC Net Protocol Specification [id: tsc_ievc_doc_system_interfaces_sif_tsc_net]
[SyAD-R67-SIF-VM-CFM] Virtual Machine CFM Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_vm_cfm]
[SyAD-R68-SIF-VM-DBG] Virtual Machine Debug Interface Specification [id:
tsc_ievc_doc_software_sif_vm_debug]
[SyAD-R69-SIF-VM-DMI] Virtual Machine DMI Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_vm_dmi]
[SyAD-R70-SIF-Test-Switch] Test Switch Interface Specification [id: tsc_ievc_doc_system_interfaces_sif_test_switch]
[SyAD-R71-SIF-BITE] BITE Interface Specification [id: tsc_ievc_doc_system_interfaces_sif_bite]
[SyAD-R72-SIF-Maintenance-Fault-UI] DMI Maintenance and Fault User Interface Specification [id:
tsc_ievc_doc_system_interfaces_sif_dmi_mf_ui]

2.4. Applicable documents 9 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

[SyAD-R73-SIF-Train-Generic] iEVC - Train generic interface specification [id:

tsc_ievc_doc_system_interfaces_sif_train_generic]
[SyAD-R74-SIF-Sensor-interface] Sensor Interface Common Protocol Specification [id:
tsc_ievc_doc_system_interfaces_sif_sensor_protocol]
[SyAD-R75-SIF-JRU-Text-file] JRU text file format description [id: tsc_ievc_doc_system_interfaces_sif_jru_text]
[SyAD-R29-DPP] IEVC Data Preparation Plan (To be released) (to be released)
[SyAD-R1-SD] System Definition [id: tsc_ievc_doc_system_sd]
[SyAD-R2-URS] IEVC User Requirement Specification [id: tsc_ievc_doc_system_urs]
[SyAD-R3-PQP] IEVC Project Quality Plan [id: tsc_ievc_doc_system_pqp]
[SyAD-R4-PENG] IEVC Project Engineering Plan [id: tsc_ievc_doc_system_eng]
[SyAD-R14-SWVERP] IEVC Software Verification Plan [id: tsc_ievc_doc_software_swverp]
[SyAD-R52-EN50126_RTM] IEVC EN50126:2017 requirements traceability matrix [id:
tsc_ievc_doc_rams_50126_matrix]
[SyAD-R54-EN50129_RTM] IEVC EN50129:2018 requirements traceability matrix [id:
tsc_ievc_doc_rams_50129_matrix]
[SyAD-R76-ODO-STAT] Odometry Application Statistical Test Analysis [id:
tsc_ievc_doc_system_sad_test_odometry]
[SyAD-R79-BK-APP-ARCHI] iEVC Basic Kit Application Architecture Description [id:
tsc_ievc_doc_system_applications_apparch_basic]
[SyAD-R80-SK-APP-ARCHI] iEVC Sensor Kit Application Architecture Description [id:
tsc_ievc_doc_system_applications_apparch_sensor]
[SyAD-R81-ETCSK-APP-ARCHI] iEVC ETCS Kit Application Architecture Description [id:
tsc_ievc_doc_system_applications_apparch_etcs]
[SyAD-R82-SIL-ALLOCATION] iEVC SIL Allocation Report [id: tsc_ievc_doc_rams_sil_allocation_report]

2.5 Reference documents

[SyAD-R0-GLOSSARY] TSC glossary [id: glossary]

[SyAD-R30-CCS:2016] COMMISSION REGULATION (EU) 2016/919 of 27 May 2016 on the technical speci-
fication for interoperability relating to the ‘control-command and signalling’ subsystems of the rail
system in the European Union
[SyAD-R31-TSI-LOCPAS:2014] COMMISSION REGULATION (EU) No 1302/2014 of 18 November 2014
concerning a technical specification for interoperability relating to the ‘rolling stock — locomotives
and passenger rolling stock’ subsystem of the rail system in the European Union
[SyAD-R33-EN50126-1:2017] CENELEC. EN51026-1. Railway Application - The Specification and Demon-
stration of Reliability, Availability, Maintainability and Safety (RAMS) - Part 1: Generic RAMS
Process, 2017.
[SyAD-R34-EN50126-2:2017] CENELEC. EN51026-2. Railway Application - The Specification and Demon-
stration of Reliability, Availability, Maintainability and Safety (RAMS) - Part 2: Systems approach
to safety, 2017.
[SyAD-R36-EN50129:2018] CENELEC. EN50129. Railway applications - Communication, signalling and pro-
cessing systems - Safety related electronic systems for signalling, 2018
[SyAD-R38-EN50155:2017] CENELEC. EN50155. Railway applications - Rolling stock - Electronic equipment,
2017

10 of 750 2.5. Reference documents

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

[SyAD-R37-EN50159:2010] CENELEC. EN50159. Railway applications - Communication, signalling and pro-

cessing systems - Safety-related communication in transmission systems, 2010
[SyAD-R46-EN-62262:2002] EN 62262 - Degrees of protection provided by enclosures for electrical equipment
against external mechanical impacts (IK code)
[SyAD-R7-Capella] TSC Arcadia and Capella guide (To be released)
[SyAD-R8-SS026] Subset-026 v3.6.0 (System Requirements Specification)
[SyAD-R17-DMI] ERA_ERTMS_015560 v3.6.0 (DMI subset)
[SyAD-R16-SS027] Subset-027 v3.3.0 (FIS Juridical Recording)
[SyAD-R23-SS34] Subset-034 v3.2.0 (Train Interface FIS)
[SyAD-R18-STM] Subset-035 v3.2.0 (FFFIS STM)
[SyAD-R9-SS36] Subset-036 v3.1.0 (Eurobalise interface)
[SyAD-R10-SS37] Subset-037 v3.2.0 (Euroradio interface)
[SyAD-R21-EIRENE-FRS] EIRENE FRS v8.0.0 (GSM-R Functional Requirements Specification)
[SyAD-R22-EIRENE-SRS] EIRENE SRS v16.0.0 (GSM-R System Requirements Specification)
[SyAD-R15-AT11T6001] A 11 T 6001 (MORANE) Radio Transmission FFFIS for EuroRadio v13.0.0
[SyAD-R25-SS40] Subset-040 Dimensioning and Engineering rules v3.4.0
[SyAD-R26-SS41] Subset-041 Performance Requirements for Interoperability v3.2.0
[SyAD-R50-SS44] Subset-044 v2.4.0 (FFFIS for Euroloop)
[SyAD-R27-SS58] Subset-058 v3.2.0 (FFFIS STM Application Layer)
[SyAD-R77-SS85] Subset-085 v3.0.0 (Test Specification for Eurobalise FFFIS)
[SyAD-R24-SS94] Subset-094 v3.1.0 FUNCTIONAL REQUIREMENTS FOR AN ON-BOARD REFERENCE
TEST FACILITY
[SyAD-R28-SS100] Subset-100 v2.0.0 (Interface “G” Specification)
[SyAD-R51-SS103] Subset-103 v1.1.0 (Test specification for Euroloop)
[SyAD-R24-ERTMS-040001] ASSIGNMENT OF VALUES TO ETCS VARIABLES v1.29
[SyAD-R39-ERA-OPI-2020-2] ERA/OPI/2020-2 Opinion of the European Union Agency for Railways to the
European Commission regarding error corrections of current ERTMS baselines
[SyAD-R40-IEC-8802-3:2014] IEC 8802-3 Standard for Ethernet
[SyAD-R41-RFC-791] RFC 791 INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL
SPECIFICATION
[SyAD-R42-RFC-793] RFC 793 TRANSMISSION CONTROL PROTOCOL DARPA INTERNET PROGRAM
PROTOCOL SPECIFICATION
[SyAD-R43-RFC-768] RFC 768 User Datagram Protocol - INTERNET STANDARD
[SyAD-R44-RFC-1918] RFC 1918 Address Allocation for Private Internets - INTERNET STANDARD
[SyAD-R45-NMEA-0183] NMEA 0183 Interface Standard v4.11
[SyAD-R47-3GPP-TS] 3GPP TS 21.111.rev.8 - USIM card requirements
[SyAD-R48-ETSI-TS] ETSI TS 51.011 v4.15 - Specification of the Subscriber Identity Module
[SyAD-R49-IEC-7498] ISO/IEC 7498 - Information technology — Open Systems Interconnection
[SyAD-R11-OCORA] OCORA basic information - CCRCC 2019 - Commit e292a3b on OCORA GitHub docu-
ment publication platform (https://github.com/OCORA-Public/Publication)
[SyAD-R53-GSMR-MANUAL] Triorail 8/2 Watt GSM-R Module Data Only TRC-6RM datasheet

Bibliography 11 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

2.6 Terms and definition

Refer to [SyAD-R0-GLOSSARY] .

2.7 Artifacts definition

This document is the iEVC system architecture description.

Artifact
iEVC System Architecture Description [artifact]

2.8 Prerequisites

2.8.1 Requirements

This document defines requirements. These requirements appear in the document in a frame bearing the title
“Requirement”. Each requirement is uniquely identified between brackets so that it can be traced (e.g. [req][id:
tsc-req-this-is-a-requirement]).
This document also allocates requirements. In this case, the allocation is justified in a frame bearing the title
“Allocate”. Allocations can be made to components or artifacts (e.g. documents).
The process of identification and tracing of requirements is defined in the [SyAD-R4-PENG].
For the outsourced components a notion of “Compliance level” is defined to characterize each requirement. The
compliance level appears between brackets in the identifier of the requirement. Three levels are defined:
• P1: Mandatory; compliance of the supplier with this requirement is mandatory
• P2: Flexible; functional compliance of the supplier is required. The exact implementation method shall
be detailed by the supplier. Strict compliance may not be achieved but the proposed implementation shall
satisfy the original functional purpose the requirement.
• P3: Optional; the requirement is purely optional for the supplier.

Note: A requirement categorized as P3 for the supplier does not mean that the requirement is optional for the
iEVC system. It may be implemented by TSC if not implemented by the supplier.

2.8.2 Functions

This document defines functions of the system. Each function is generally presented as a section of the document.
The title is then suffixed with the [function] tag. For each function, the following data is presented in a dedicated
frame just below the function title:
• SIL - The assigned safety integrity level of this function;
• Definition - The concise definition of the function;
• Input - The inputs of the function with the associated interface
• Output - The outputs of the function with the associated interface
• Allocated to - the list of component the function is allocated to
• Sub functions - the list of contributing sub functions
• Associated interface - the list of logical interfaces used by this function

12 of 750 2.6. Terms and definition

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Inputs and outputs of functions are represented as functional variables. A functional variable is presented in a
frame bearing the title “Functional variable”. Functional variables are mostly documented in interface specifica-
tion documents. Each functional variable documents its objective and its content. Typically, messages exchanged
over interfaces are represented as functional variables.

2.8.3 Configuration items

This document defines multiple configuration items of two major types: components and interfaces. The configu-
ration items of type ‘interface’ are defined in section Interfaces. The configuration items of type ‘component’ are
defined in section System definition and purpose.
These configuration items appear in the document in a frame bearing the title “Configuration item”.

2.8.4 Capella

This document illustrates the architecture of the iEVC using diagrams realized using the Capella tool, according
[SyAD-R7-Capella]. We provide here the necessary guidance for reading these diagrams.
Capella represents functions as green boxes. Function outputs are represented as little triangles pointing out of the
function boxes, while function inputs are represented as triangles pointing inside the function boxes. Functional
variables are represented as green labeled lines connecting function inputs to outputs. This is illustrated in figure
Fig. 2.1.

Figure 2.1: Representation of functions in Capella

Capella represents the components of the system as blue boxes. Some of the components are also represented
as white boxes or using specific pictures to improve readability. Components can contain other components
or functions. Interfaces between components are represented as blue labeled lines connecting the components.
Components are named according to the components defined in this document, and interfaces are prefixed with

2.8. Prerequisites 13 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

the interface code, between brackets. Dashed color lines represent allocations of functional variables to interface.
These conventions are illustrated in figure Fig. 2.2.

Figure 2.2: Representation of components and interfaces in Capella

Actors external to the system, such as users or external systems, are represented as light blue boxes. This is
illustrated in Fig. 2.3.

Figure 2.3: Representation of actors in Capella

Component modes and transitions between these modes can be represented as in Fig. 2.4. Transitions can be
expressed in term of active function or functional exchange message.

14 of 750 2.8. Prerequisites

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 2.4: Representation of modes transition in Capella

The following issues are known:

• #1573 - For [SyAD-R28-SS100]: design provisions have been taken for the KER interface, but the coverage
is not demonstrated clause by clause.
• #1576 - System parameters are documented, but they are not classified and recapitulated in a dedicated
section of the documentation.
• #1577 - The DMI application does not document its modes.
• #1579 - The wheel diameter is a parameter of the odometry, and is not re-estimated by the odometry algo-
rithm. This creates a strong constraint on operations.
• #1580 - The SIDE Configurator should explain how it generates configuration templates
• #1582 - Clarify how the DMI can display external feeds.

5. Limitations and open points 19 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• #2682 - Add a detailed allocation for EN62625-1:2013 and Subset-092

• #4490 - Update function and component SIL to account for the SSHA
• #4501 - The component OBOM driver should be introduced in the system architecture to be in line with
the software architecture. This component manages the interface between the OBOM and the various iEVC
applications. The associated functions and requirements are currently allocated to the VM.
• #4503 - The ETCS messages and Subset 026 applications must be merged in the architecture description to
reflect the actual application architecture
• #4585 - Review the functional architecture of the DMI SIL2 functions
• #4587 - LRU Fault ID map needs to be consolidated based on the possible faults reported by the generic
components LRUs.
• #4622 - Update the Telecom box architecture to recover the power supply maintenance data through the 4G
modem (and therefore reducing the quantity of ethernet connectors on the front panel).
• #4655 - A more recent version of EN 50155 has been released (2021). The system specification should be
updated to trace that new version.

20 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
CHAPTER

SIX

SYSTEM DEFINITION AND PURPOSE

6.1 iEVC system

Configuration Item

iEVC [ci]
Data
• Sil: 4
• Composed of:
– iEVC Basic kit[ci]
– iEVC Sensor kit[ci]
– iEVC Telecom kit[ci]

The iEVC system (also called iEVC Platform) is a model-oriented generic on-board platform. Its main purpose
is to execute on-board signalling applications that are modeled in a domain specific language. The application
models have the particularity that they can be compiled to a format directly executable by the iEVC. An example
of such iEVC application is the Subset 026 application[ci].
Applications are executed on-board by a Virtual Machine. The applications loaded on this VM are grouped in a
coherent package, that regroups the applications to run, but also their configuration, as well as the sequence in
which these applications must be run.
In order to support the execution of ETCS signalling applications, the iEVC generic platform interfaces this VM
with speed sensors, balises/loops and radio communications.
This document is intended to define the required architecture of the iEVC system in order to be able to run under
ERTMS/ETCS supervision. However some generic applications other than the ETCS application are introduced
(such as class B applications) in order to define the standard interfaces of the iEVC system. The specification of
these applications is out of the scope of this document.
The installation team is the team responsible for the installation of the iEVC product with its applications into a
specific type of train. They design the specific application part of the system in order to meet the functional needs
of the installation project. This includes as a minimum:
• the design of the train interface.
• the configuration of the iEVC applications.
• the development of any specific application required by the project.
• the design of the installation (including cabling) for the different iEVC On-board components.
• the integration, test and validation of their specific application solution
The iEVC system boundaries and interfaces are introduced in the [SyAD-R1-SD] and illustrated in Fig. 6.1.

6. System definition and purpose 21 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 6.1: Overview of the IEVC system and its interfaces

The iEVC on-board subsystem is the on-board part of the iEVC system. It is organized around three hardware
boxes plus an Ethernet switch. The hardware architecture is illustrated in Fig. 6.2.

Figure 6.2: Simplified on-board subsystem hardware overview

Note: The power supply lines are not illustrated in Fig. 6.2. The topic of power supply is treated in section Power

22 of 750 6.1. iEVC system

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

supply distribution.

The iEVC on-board subsystem allows operating 2 desks or cabins. Each cabin or desk has its own driver interface.
The selection of the active desk is included in the iEVC train generic interface ([SyAD-R73-SIF-Train-Generic]).
For short engines with 2 desks, one Euroantenna may be used in compliance with the installation constraint
from Subset 040 (see tsc-req-ievc-euroantenna-ss40-installation[req]). For long engines with 2 desks, this
constraint may not be possible to fulfill with only one antenna. In this case 2 Sensor boxes must be used.
They are connected to a same Computer box. Each Sensor box corresponds to one cabin or desk and is con-
nected to its own Euroantenna. More information is provided in section System functional architecture and in
[SyAD-R55-SIF-iBTM-Euroantenna].
The iEVC on-board subsystem allows using 1 up to 4 DMI to interface the user (driver or maintainer). There is at
least 1 DMI per cabin and an installation project may require that the iEVC On-board controls 1 or 2 cabins. In
each cabin the whole DMI device may be duplicated, meaning that there is a main display and a backup display.
The backup display DMI is used in case of failure of the main one. Another possibility is to use dual-screen
technology, meaning that part of the information is displayed on 1 device and the rest on the second.

Figure 6.3: iEVC On-board with 2 Sensor boxes

Allocate
Allocation of URS requirements to support at least 2 driver desks and long trains [allocate]

6.1. iEVC system 23 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-install-at-least-2-desks[req]
– tsc-req-urs-install-ievc-must-support-long-train-or-trailing-unit[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: iEVC system
• Justification: The section in the SyAD explains how 2 desks are managed by the iEVC On-
board subsystem. urs-install-ievc-must-support-long-train-or-trailing-unit: for the aspects
related to long trains that may use 2 sensor box.

Allocate
Allocation of URS requirements to have not more than 5 days installation time for the iEVC On-
board [allocate]
Data
• Requirement:
– tsc-req-urs-install-ievc-max-time-5-days[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: iEVC system
• Justification: This is achieved through the architecture design by using boxes, safe relays
and through the type of connectors. The installation of each box is assumed to take approxi-
mately 2 hours. The installation of the sensors and antenna is assumed to take approximately
one day. The installation of the DMI, CPM and switch is assumed to take approximately 1h
per component, so at most 6 hours if there are 4 DMI. The cabling including the installation
of relays is assumed to take approximately 1 day thanks to the use of latched connectors for
most of the cables. Total installation time is a little less than 4 days, assuming 8h work per
day.

Allocate
Allocation of the URS requirement to not use welding for connections or threaded rods pointing
outside of the boxes. [allocate]

24 of 750 6.1. iEVC system

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-install-ievc-no-wield[req]
– tsc-req-urs-install-ievc-no-threaded-rods[req]
• Ci:
– 4G modem[ci]
– 4G antenna[ci]
– GPS antenna[ci]
– Computer box hardware[ci]
– Computer box extension[ci]
– Test key switch[ci]
– Crash protected memory[ci]
– DMI hardware[ci]
– Telecom box hardware[ci]
– Ethernet switch[ci]
– GSM-R antenna[ci]
– Euroantenna[ci]
– Wheel pulse generators[ci]
– Secondary odometry sensor[ci]
– Sensor box hardware[ci]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: iEVC system
• Justification: There is no welding connection nor threaded rods in the iEVC system archi-
tecture design.

Allocate
Allocation of the URS requirement that requires that iEVC shall be made of components that are
ready to install in a train and shall not contain sharp or cutting edges. [allocate]

6.1. iEVC system 25 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-install-modular[req]
– tsc-req-urs-install-ievc-no-sharp-cutting-edges[req]
• Ci:
– 4G modem[ci]
– 4G antenna[ci]
– GPS antenna[ci]
– Computer box hardware[ci]
– Computer box extension[ci]
– Test key switch[ci]
– Crash protected memory[ci]
– DMI hardware[ci]
– Telecom box hardware[ci]
– Ethernet switch[ci]
– GSM-R antenna[ci]
– Euroantenna[ci]
– Wheel pulse generators[ci]
– Secondary odometry sensor[ci]
– DMI hardware[ci]
– Sensor box hardware[ci]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: iEVC system
• Justification: The requirement is met by the modular architecture of the iEVC system

6.2 iEVC certification kits

The components of the iEVC program are grouped in certification kits. Each kit contains components that have
similar life cycles and that manage similar peripherals. Each kit is structured by hardware (including electronic
and mechanical components), software, applications and tools. The 4 certification kits are:
• iEVC Basic kit[ci] - Generic Product certification,
• iEVC Sensor kit[ci] - Generic Product certification,
• iEVC Telecom kit[ci] - Generic Product certification,
• iEVC ETCS kit[ci] - Generic Application certification.
The architecture of the kits is such that the iEVC Sensor kit[ci] and iEVC Telecom kit[ci] cannot be used alone.
They both rely on the iEVC Basic kit[ci]. In the same way the iEVC ETCS kit[ci] can only be used with the iEVC
Sensor kit[ci] and iEVC Telecom kit[ci].

26 of 750 6.2. iEVC certification kits

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The iEVC system is composed of the 3 generic product kits: iEVC Basic kit[ci], iEVC Sensor kit[ci] and iEVC
Telecom kit[ci].

Figure 6.4: iEVC kits architecture

6.3 iEVC Basic kit

Configuration Item

iEVC Basic kit [ci]

Data
• Sil: 4
• Composed of:
– iEVC Basic kit hardware[ci]
– iEVC Basic kit software[ci]
– iEVC Basic kit applications[ci]
– iEVC Basic kit tools[ci]
– iEVC Basic kit interfaces[ci]

The iEVC Basic kit includes a Safe computer and the necessary peripherals to interface with the driver
and with the train.

6.3. iEVC Basic kit 27 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 6.5: iEVC Basic kit - physical architecture

Figure 6.6: iEVC Basic kit - logical architecture

Note: the Computer box extension is not represented in the logical architecture because the associated functions
are entirely managed by the safe computer.

28 of 750 6.3. iEVC Basic kit

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

6.3.1 iEVC Basic kit hardware

Configuration Item

iEVC Basic kit hardware [ci]

Data
• Sil: 4
• Composed of:
– Computer box[ci]
– Computer box extension[ci]
– Ethernet switch[ci]
– Crash protected memory[ci]
– Safety relay[ci]
– DMI[ci]

The hardware components of the basic kit are:

• Computer box[ci]
• Computer box extension[ci]
• Ethernet switch[ci]
• Crash protected memory[ci]
• Safety relay[ci]
• DMI[ci]

Configuration Item

Computer box [ci]

Data
• Sil: 4
• Composed of:
– Computer box hardware[ci]
– Safe computer[ci]
– Computer box power supply[ci]
– Test key switch[ci]
– Computer box - IO board internal interface[ci]
– Computer box - Safe Computer internal interface[ci]

The Computer box contains the Safe computer, that is the main processing unit of the iEVC. It also
manages the digital I/O in the train interface. When the installation project requires more safe I/O than
available on a Computer box, one Computer box extension can be added (only one Computer box extension
can be used).

Data
• Sil: 4

The Safety relays are used to relay safe output and/or input to/from train electrical lines such as the brake
command lines, the traction cut-off line or the brake status readback lines. They provide dry contacts and
allow adapting to higher line tensions and/or currents than those of the IO boards of the Safe computer.

30 of 750 6.3. iEVC Basic kit

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Configuration Item

DMI [ci]
Data
• Sil: 2
• Composed of:
– DMI computer[ci]
– DMI software[ci]

6.3. iEVC Basic kit 31 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Sil: basic

The Computer box power supply provides power to the various components inside the Computer box.

Configuration Item

IO board [ci]
Data
• Sil: 4

The IO board is the hardware component of the Safe computer in charge of interfacing electrical signals
from the train in order to provide the safe digital inputs and outputs of the system (e.g. brake release
command, cabin activation signal, etc).

Configuration Item

Test key switch [ci]

Data
• Sil: basic

The Test key switch is a physical switch placed on the front of the Computer box. When turned on, it
informs the Safe computer that the platform should run in a special Test mode. This test mode unlocks
certain possibility in the Virtual machine[ci] related to testing.

Configuration Item

Safe computer IO Extension [ci]

Data
• Sil: 4

The Safe computer IO Extension provides access to extra digital inputs and outputs.

Note: This component is included in the Computer box extension[ci] and is therefore optional.

32 of 750 6.3. iEVC Basic kit

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

6.3.1.2 DMI hardware components

Configuration Item

DMI computer [ci]

Data
• Sil: 2
• Composed of:
– DMI hardware[ci]

The DMI computer is an outsourced component. The DMI is a multi-function terminal which performs
the interface with the user (driver or maintainer). It is composed of the DMI hardware[ci] that includes
the hardware mechanism used to execute the SIL2 functions. It runs the DMI software[ci] and the DMI
checker[ci] in order to provide a safe display of information and to get safe inputs from the driver.

Configuration Item

DMI hardware [ci]

Data
• Sil: 2

The DMI hardware is a hardware dedicated to driver display and input. It typically features an LCD
screen. Different types of hardware are possible depending on the technology used between Soft-key and
Touchscreen.

6.3.2 iEVC Basic kit software

Configuration Item

iEVC Basic kit software [ci]

6.3. iEVC Basic kit 33 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Sil: 4
• Composed of:
– DMI software[ci]
– DMI checker[ci]
– Virtual machine[ci]
– IO driver[ci]
– DMI driver[ci]
– TSC Net[ci]
– OBOM[ci]
– iODO driver[ci]
– iBTM driver[ci]
– SFM[ci]
– iODO BITE driver[ci]
– CFM[ci]
– Modem controller[ci]

The software components of the basic kit are:

• DMI software[ci]
• DMI checker[ci]
• TSC Net[ci]
• OBOM[ci]
• CFM[ci]
• Modem controller[ci]
• Virtual machine[ci]
• DMI driver[ci]
• IO driver[ci]
• iODO driver[ci]
• iBTM driver[ci]
• iODO BITE driver[ci]
• SFM[ci]

Note: The DMI driver[ci], IO driver[ci], iODO driver[ci], iBTM driver[ci], iODO BITE driver[ci] and SFM[ci]
are hosted by the Virtual Machine.

Note: The iODO driver[ci], iBTM driver[ci], iODO BITE driver[ci], SFM[ci], CFM[ci] and Modem con-
troller[ci] are functionally related to other kits but they are developed and managed in configuration together with
the Virtual Machine. Therefore these configuration items are included in the iEVC Basic kit.

34 of 750 6.3. iEVC Basic kit

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Configuration Item

DMI software [ci]

Data
• Sil: basic

The DMI software is in charge of drawing driver user interfaces on the DMI hardware computer screen,
and acquiring inputs from the driver through the same screen.

Configuration Item

DMI checker [ci]

Data
• Sil: 2

The DMI checker is an additional software running on the DMI computer that verifies independently what
is displayed on the DMI screen and what is input by the driver. This feedback can be used by the Safe
computer to determine that safety-related information is indeed displayed to the driver or that safety-
related input has indeed been provided by the driver.

Configuration Item

Virtual machine [ci]

Data
• Sil: 4

The Virtual Machine is in charge of executing the iEVC applications. It is also able to host drivers that
can manage specific interfaces and associated protocols used by the applications. An example of such
interface is the Euroradio Safe protocol that is managed by the Safety Functional Module (SFM) according
to [SyAD-R10-SS37], or the one driving access to the digital inputs and outputs.
The term ‘VM’ is often used in this document as an acronym of the Virtual machine component.

Data
• Sil: 4

The iODO Driver manages the interface between the Virtual Machine on one side and the iODO module
on the other side. As such, the exchange of synchronization, measurement sample and other messages is
performed by this module to cyclically feed the Odometry Application in the Safe computer.

Configuration Item

iODO BITE driver [ci]

Data
• Sil: basic

The iODO BITE driver manages the interface between the Virtual Machine on one side and the iODO
BITE module on the other side. It relays the messages that control the test of iODO module as well as the
V1/V2 messages that are used to interface a Subset-085 or Subset-103 certification laboratory.

36 of 750 6.3. iEVC Basic kit

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Configuration Item

iBTM driver [ci]

Data
• Sil: 4

The iBTM driver manages the interface between the Virtual Machine and the various iBTM components
in the Sensor box (e.g. iBTM-RX module, iBTM-TX module). The iBTM driver allows to synchronize the
messages exchanged between the iBTM application in the Computer box and the iBTM-TX module and
iBTM-RX module components in the Sensor box.

Configuration Item

SFM [ci]
Data
• Sil: 4

The Euroradio Safe Functional Module driver implements the SFM portion of [SyAD-R10-SS37]. As
a driver, it is part of the Virtual Machine. It manages the Euroradio protocol stack in interface with the
Euroradio CFM software.

Configuration Item

CFM [ci]
Data
• Sil: basic

The Euroradio CFM software implements the low level Euroradio protocol stack of [SyAD-R10-SS37].
It manages the interface between the Euroradio Safe Functional Module driver and the Euroradio Modem
controller Software.

Configuration Item

Modem controller [ci]

Data
• Sil: basic

The modem controller software is in charge of managing the GSM-R modem protocol. It allows the
Euroradio CFM software to communicate with the GSM-R modems.

6.3. iEVC Basic kit 37 of 750

The tools of the basic kit are:

• SIDE Configurator[ci]
• SIDE Authorizer[ci]

6.3.4.1 Configuration

To simplify the job of configuration for a fleet of vehicle, the SIDE Configurator offers a simple command line
tool that automates the production of the configuration files.
In the iEVC, configuration data files are special applications that are executed once during the initialization phase
of the Virtual Machine. During this phase, the configuration application is allowed to overwrite the relevant
parameter in each configurable application. After this is done, the VM locks the parameters in read-only for the
remainder of the execution.
The topic of configuration is described in more details in iEVC Configuration.

Configuration Item

SIDE Configurator [ci]

Data
• Sil: basic

The SIDE Configurator is an off-line command line tool that allows to generate and decode the configura-
tion data for a given vehicle fleet.

6.3.4.2 Authorization

Another aspect of configuration is the management of applications authorization. The purpose is to guarantee that
only authorized applications are executed in the trains. The iEVC uses asymmetric cryptography to support this
activity.
The application packages are numerically signed (see Application package descriptor file for a description of
an application package). Using the SIDE Authorizer, a designated privileged user (e.g. Safety Assurance En-
gineer[role]) uses a public / private key pair to produce a cryptographic certificate for each of the application
packages used in the fleet.
• The public key is a configuration parameter of the Virtual Machine;
• The private key, never to be shared outside of the Authorizer tool, is used to encrypt the authorized applica-
tion package signature. The resulting cypher is a valid certificate for this application package.

6.3. iEVC Basic kit 39 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Certificates are then uploaded to the iEVC on-board subsystem.

During its initialization phase, the Virtual Machine uses the public key to decrypt the available certificate (see
Virtual Machine for more information). If it matches the signature of the proposed application package to run,
then it will authorize the execution. In case of failure, execution of the application package is denied.
The configuration & authorization tools workflow is illustrated by Fig. 6.7 below.

Figure 6.7: iEVC Specific Application Support Tools

Configuration Item

SIDE Authorizer [ci]

Data
• Sil: basic

The SIDE Authorizer is an off-line software tool dedicated to the creation of cryptographic certificates
authorizing the execution of a given application package version.

6.3.5 IEVC basic kit interfaces

Configuration Item

iEVC Basic kit interfaces [ci]

40 of 750 6.3. iEVC Basic kit

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Sil: 4
• Composed of:
– Safe computer - Test switch interface[ci]
– VM - DMI interface[ci]
– VM - Applications interface[ci]
– VM - OBOM interface[ci]
– DMI - OBOM interface[ci]
– CPM - OBOM interface[ci]
– Safety Relays - Safe Computer interface[ci]
– Ethernet Switch - OBOM interface[ci]
– Sensor Box Ethernet Switch - OBOM interface[ci]
– Power supply - OBOM interface[ci]
– SIDE Configurator User Interface[ci]
– SIDE Authorizer User Interface[ci]
– Computer box - Computer box Extension[ci]
– TSC Net - OBOM interface[ci]
– DMI ETCS User Interface[ci]
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]
– Computer box - Ethernet interface[ci]
– Computer box - Power supply interface[ci]
– VM - Safe computer OS interface[ci]
– VM - debug interface[ci]
– DMI - Ethernet interface[ci]
– CPM - Ethernet interface[ci]
– Computer box - Safety Relays[ci]
– Ethernet switch - Reset relay interface[ci]
– DMI Software Configuration Data Files[ci]
– DMI Checker Configuration Data Files[ci]
– Modem Controller - OBOM interface[ci]
– CFM - Modem Controller interface[ci]
– VM - CFM interface[ci]

Interfaces are presented in section Section 7.2.

6.3. iEVC Basic kit 41 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

6.4 iEVC Sensor kit

Configuration Item

iEVC Sensor kit [ci]

Data
• Sil: 4
• Composed of:
– iEVC Sensor kit hardware[ci]
– iEVC Sensor kit applications[ci]
– iEVC Sensor kit interfaces[ci]

The iEVC Sensor kit consists of a Sensor box and the necessary peripherals to:
• measure and compute an estimate of the train odometry,
• read Eurobalise, Euroloop and KER balise telegrams.

Figure 6.8: iEVC Sensor kit - physical architecture

42 of 750 6.4. iEVC Sensor kit

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 6.9: iEVC Sensor kit - logical architecture

Note: grey components are not part of the kit

When 2 Euroantenna are required by the installation project, then the Secondary Sensor Box must be used
to interface the second Euroantenna. The Secondary Sensor box does not include any iODO or iODO
BITE board since it does not interface with any odometry sensor.

Configuration Item

Euroantenna [ci]
Data
• Sil: basic

The Euroantenna is located under the train. It is composed of inductive loops that are used to Tele-power
electro-magnetically balises and loops placed on the track and capture the reply signal.

Configuration Item

Wheel pulse generators [ci]

Data
• Sil: basic

The Wheel pulse generators (also called PG in this document) provide a measure of the rotation of the
wheels. This can be used to estimate the speed and distance traveled.
The PG is mounted on a vehicle axle. The mechanical coupling transfers the rotation of the vehicle axle to
the shaft of the electronic pulse generator. The pulse generator contains a pulse wheel with varying number
of slots on the outer and/or inner track. The optoelectronics pulse wheel generates a speed-depended pulse
signal.

Configuration Item

Secondary odometry sensor [ci]

Data
• Sil: basic

6.4. iEVC Sensor kit 45 of 750

The applications of the sensor kit are:

6.4. iEVC Sensor kit 47 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Odometry application[ci]
• iBTM application[ci]

Configuration Item

Odometry application [ci]

Data
• Sil: 4

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• retrieve GPS information

Figure 6.10: iEVC Telecom kit - physical architecture

50 of 750 6.5. iEVC Telecom kit

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 6.11: iEVC Telecom kit - logical architecture

Note: grey components are not part of the kit

6.5.1 iEVC Telecom kit hardware

Configuration Item

iEVC Telecom kit hardware [ci]

6.5. iEVC Telecom kit 51 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Sil: basic
• Composed of:
– Telecom box[ci]
– 4G antenna[ci]
– GPS antenna[ci]
– GSM-R antenna[ci]

The hardware components of the telecom kit are:

• Telecom box[ci]
• 4G antenna[ci]
• GPS antenna[ci]
• GSM-R antenna[ci]

Configuration Item

Telecom box [ci]

Data
• Sil: basic
• Composed of:
– Telecom box hardware[ci]
– 4G modem[ci]
– GSM-R modem[ci]
– Telecom box power supply[ci]
– Telecom box - 4G modem internal interface[ci]
– Telecom box - GSM-R modem internal interface[ci]
– Telecom box - power adapter internal interface[ci]

The Telecom box components contains the modems that are necessary to radio-access Internet or the GSM-
R network.

Configuration Item

4G antenna [ci]
Data
• Sil: basic

The 4G antenna is connected to the 4G Modem. It is considered that the 4G antenna is supplied together
with the 4G Modem. Therefore in the functional architecture only the 4G Modem is considered for alloca-
tion.

52 of 750 6.5. iEVC Telecom kit

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Note: depending on the 4G modem solution/vendor, a same antenna may be used for 4G and GPS.

Configuration Item

GPS antenna [ci]

iEVC Telecom kit interfaces [ci]

Data
• Sil: 4
• Composed of:
– NMEA 0183 GPS interface[ci]
– 4G Modem - OBOM interface[ci]
– Telecom box - 4G antenna interface[ci]
– Telecom box - GPS antenna interface[ci]
– Telecom box - GSM-R antenna interface[ci]
– Telecom box - power supply interface[ci]
– Telecom box - Ethernet interface[ci]
– Euroradio air-gap[ci]
– Modem Controller - GSM-R Modem Interface[ci]

Interfaces are described in section Section 7.2.

54 of 750 6.5. iEVC Telecom kit

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

6.6 iEVC ETCS kit

Configuration Item

iEVC ETCS kit [ci]

Data
• Sil: 4
• Composed of:
– iEVC ETCS kit applications[ci]
– iEVC ETCS kit tools[ci]
– iEVC ETCS kit interfaces[ci]
– IEVC Requirement Sources[ci]

The iEVC ETCS kit adds generic applications and associated tools to the iEVC system in order to allow
the train running under ETCS supervision.

Figure 6.12: iEVC ETCS kit - logical architecture

Note: grey components are part of the iEVC system

Note: The ETCS Kit introduces applications and tools. The hardware and software components executing the

6.6. iEVC ETCS kit 55 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

applications are those of the iEVC system.

6.6.1 iEVC ETCS kit applications

Configuration Item

iEVC ETCS kit applications [ci]

Data
• Sil: 4
• Composed of:
– Subset 026 application[ci]
– ETCS messages application[ci]
– TIU application[ci]

The applications of the ETCS kit are:

• Subset 026 application[ci]
• ETCS messages application[ci]
• TIU application[ci]

Configuration Item

Subset 026 application [ci]

Data
• Sil: 4

The Subset 026 Application is in charge of the functional requirements defined in ETCS Subset 026
([SyAD-R8-SS026]). It includes also functional requirements from Subset 027 ([SyAD-R16-SS027]),
Subset 035 ([SyAD-R18-STM]), Subset 037 ([SyAD-R10-SS37]), Subset 040 ([SyAD-R25-SS40]) and
ERA_ERTMS_015560 ([SyAD-R17-DMI]).
This application requires configuration data for which values are defined by the installation project de-
pending its specific functional needs. Refer to iEVC Configuration for more information on the iEVC
configuration data.

Configuration Item

ETCS messages application [ci]

Data
• Sil: 4

The ETCS messages application is in charge of packing and unpacking ETCS messages exchanged with
wayside devices, as well as verifying their checksum.

56 of 750 6.6. iEVC ETCS kit

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Configuration Item

TIU application [ci]

Data
• Sil: 4

The TIU application is in charge of interfacing the train physical inputs and outputs, and adapt them to
exchange functional variables with the iEVC applications in charge of the signalling (Subset 026 applica-
tion[ci] or any other Class B application[ci]).
The TIU application that will be installed on a train will need to be adapted based on the need of each
specific installation project because each project has its own specific train interface. Therefore what we call
‘TIU application’ in the frame of the iEVC system development and in this document must be understood
as a ‘TIU application for test’. This application will provide the means to test and verify the iEVC ETCS
kit.

6.6.2 iEVC ETCS kit tools

Configuration Item

iEVC ETCS kit tools [ci]

Data
• Sil: basic
• Composed of:
– JRU decoder[ci]

The ETCS kit contains the JRU decoder.

The JRU decoder is an off-line tool dedicated to the decoding of the data logged for juridical purposes in a Crash
Protected Memory. The JRU decoder is required by the JRU requirements of [SyAD-R31-TSI-LOCPAS:2014].
This tool is described in details in JRU decoder, and illustrated in Fig. 6.13 below. The JRU functions are allocated
in System functional architecture.

6.6. iEVC ETCS kit 57 of 750

Installation project application [ci]

Data
• Sil: Undefined

This component covers any iEVC application developed in the frame of a specific installation project and
that uses interface provided by the TIU application for non-safe applications (see TIU application).
This type of application is outside of the scope of this document.
This component is created to export constraints that are specific to this type of application.

6.7. Other Applications 59 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

6.8 Component list

Fig. 6.14 provides a summary overview of the logical components making the iEVC with their corresponding
certification kit. This figure is a ‘component view’ without their interfaces. The logical interfaces internal to the
iEVC on-board subsystem are illustrated in Fig. 7.1. For a complete definition of all the interfaces, refer to section
Interfaces.

Figure 6.14: iEVC Components Overview

Note: the Virtual Machine is not only composed of other sub-components, it has its own functions, which is why
it is identified explicitly as a Basic kit software component in the previous figures.

Note: The iEVC On-board cabling design is not covered by a specific component but is included the scope of
the Specific Application as it is linked to the specific project installation requirements. This includes the odom-
etry sensors cables, the Euroantenna cable, other antenna cables, and the cabling of the train interface. Generic
constraints on these cables are exposed in a generic train interface document ([SyAD-R73-SIF-Train-Generic]).

The figure Fig. 6.15 provides the physical architecture of the iEVC system together with a view of the quantity for

60 of 750 6.8. Component list

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

each component.

Figure 6.15: iEVC Physical architecture with quantities

The following tables provide a detailed list of the components making the iEVC system. Components are struc-
tured in a hierarchy, and this hierarchy is made visible by component condensation.
For each component, the following information is provided:
• Code - the code of the component. This is used to position the component in the product breakdown structure
and to identify its certification kit;
• Description - short description of the component;
• Type - the type of the component:
– “Project”: components designed specifically for the iEVC projections;
– “Generic Component”: outsourced generic components. The design of these components is not spe-
cific to the iEVC system. They are outsourced to TSC suppliers and are considered as provided with
the required certification documents;
– “Reused”: components reused from other projects;
– “COTS”: components bought off the shelf (COTS).
• Physical type - the physical type of the component. Hardware, Software, or Data.
– Hardware refers to a component that has a physical reality. Hardware components may be composed
of sub-components of any physical type;
– Software refers to components that contain instructions to be executed by some computer hardware.
Software components should only be composed of software sub-components.

6.8. Component list 61 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– Data refers to components that contain information that are necessary for the software to function.
Information can be parameters or the description of algorithms to execute. Data components should
only be composed of data sub-components.

Important: iEVC applications are considered in the Data category, since they are models of algorithms,
and these algorithms are not coded in a general-purpose programming language.

• SIL - the highest SIL carried by a function allocated to the component. It can be Basic Integrity (BI), 1, 2,
3 or 4;

6.8.1 iEVC hardware - product breakdown structure [recap table]

Table 6.1: iEVC hardware - product breakdown structure

Code Description Type Physical Quantity Sil
type
IEVC.BASIC iEVC Basic kit Project Hardware 1 4
IEVC.BASIC.HW iEVC Basic kit Project Hardware 1 4
hardware
IEVC.BASIC.HW.CB Computer box Project Hardware 1 4
IEVC.BASIC.HW.CB.HW Computer box Project Hardware 1 basic
hardware
IEVC.BASIC.HW.CB.PSU Computer box Generic Hardware 1 basic
power supply Compo-
nent
IEVC.BASIC.HW.CB.SC Safe computer Generic Hardware 1 4
Compo-
nent
IEVC.BASIC.HW.CB.SC.IOB IO board Generic Hardware 2 4
Compo-
nent
IEVC.BASIC.HW.CB.TKS Test key switch Generic Hardware 1 basic
Compo-
nent
IEVC.BASIC.HW.CBEXT Computer box ex- Generic Hardware 0/1 4
tension Compo-
nent
IEVC.BASIC.HW.CBEXT.IO Safe computer IO Generic Hardware 0/1 4
Extension Compo-
nent
IEVC.BASIC.HW.CPM Crash protected Generic Hardware 1 basic
memory Compo-
nent
IEVC.BASIC.HW.DMI DMI Project Hardware 2/4 2
IEVC.BASIC.HW.DMI.CP DMI computer Generic Hardware 2/4 2
Compo-
nent
IEVC.BASIC.HW.DMI.CP.HW DMI hardware Generic Hardware 2/4 2
Compo-
nent
IEVC.BASIC.HW.ETH Ethernet switch Generic Hardware 1 basic
Compo-
nent
continues on next page

62 of 750 6.8. Component list

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Table 6.1 – continued from previous page

Code Description Type Physical Quantity Sil
type
IEVC.BASIC.HW.SR Safety relay Generic Hardware >0 4
Compo-
nent
IEVC.SENSOR iEVC Sensor kit Project Hardware 1 4
IEVC.SENSOR.HW iEVC Sensor kit Project Hardware 1 basic
hardware
IEVC.SENSOR.HW.EANT Euroantenna Project Hardware 1/2 basic
IEVC.SENSOR.HW.PG Wheel pulse gener- Generic Hardware 1 basic
ators Compo-
nent
IEVC.SENSOR.HW.SB Sensor box Project Hardware 1 basic
IEVC.SENSOR.HW.SB.BITE iODO BITE Project Hardware 1 basic
IEVC.SENSOR.HW.SB.ETH Sensor box ether- Generic Hardware 1 basic
net switch Compo-
nent
IEVC.SENSOR.HW.SB.HW Sensor box hard- Project Hardware 1 basic
ware
IEVC.SENSOR.HW.SB.IODO iODO Project Hardware 2 basic
IEVC.SENSOR.HW.SB.PSU Sensor Box Power Generic Hardware 2 basic
Supply Compo-
nent
IEVC.SENSOR.HW.SB.RX iBTM-RX Project Hardware 2 basic
IEVC.SENSOR.HW.SB.TX iBTM-TX Project Hardware 1 basic
IEVC.SENSOR.HW.SB2 Secondary Sensor Project Hardware 0/1 basic
box
IEVC.SENSOR.HW.SEC Secondary odome- Generic Hardware 1 basic
try sensor Compo-
nent
IEVC.TELECOM iEVC Telecom kit Project Hardware 1 basic
IEVC.TELECOM.HW iEVC Telecom kit Project Hardware 1 basic
hardware
IEVC.TELECOM.HW.4GA 4G antenna Generic Hardware 1 basic
Compo-
nent
IEVC.TELECOM.HW.GPSA GPS antenna Generic Hardware 1 basic
Compo-
nent
IEVC.TELECOM.HW.GSMRA GSM-R antenna Generic Hardware 2 basic
Compo-
nent
IEVC.TELECOM.HW.TB Telecom box Project Hardware 1 basic
IEVC.TELECOM.HW.TB.4G 4G modem Generic Hardware 1 basic
Compo-
nent
IEVC.TELECOM.HW.TB.GM GSM-R modem Generic Hardware 2 basic
Compo-
nent
IEVC.TELECOM.HW.TB.HW Telecom box hard- Project Hardware 1 basic
ware
IEVC.TELECOM.HW.TB.PSU Telecom box power Generic Hardware 2 basic
supply Compo-
nent

6.8. Component list 63 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

6.8.2 iEVC software, applications & tools [recap table]

Table 6.2: iEVC software, applications & tools

Code Description Type Physical type Sil
ETCS.APP.EMSG ETCS messages application Project Data 4
ETCS.APP.S26 Subset 026 application Project Data 4
ETCS.APP.TIU TIU application Project Data 4
ETCS.TOOLS.JDEC JRU decoder Project Software basic
IEVC.BASIC.APP.DMI DMI application Project Data 2
IEVC.BASIC.APP.LRU LRU application Project Data basic
IEVC.BASIC.SW.SPEC.BDRV iBTM driver Project Software 4
IEVC.BASIC.SW.SPEC.BITE iODO BITE driver Project Software basic
IEVC.BASIC.SW.SPEC.CFM CFM Project Software basic
IEVC.BASIC.SW.SPEC.DMI DMI software Project Software basic
IEVC.BASIC.SW.SPEC.DMICHK DMI checker Generic Component Software 2
IEVC.BASIC.SW.SPEC.MC Modem controller Project Software basic
IEVC.BASIC.SW.SPEC.OBOM OBOM Project Software basic
IEVC.BASIC.SW.SPEC.ODRV iODO driver Project Software 4
IEVC.BASIC.SW.SPEC.SFM SFM Project Software 4
IEVC.BASIC.SW.SPEC.TSCNET TSC Net Project Software basic
IEVC.BASIC.SW.SPEC.VM Virtual machine Project Software 4
IEVC.BASIC.SW.SPEC.VM.DD DMI driver Project Software 2
IEVC.BASIC.SW.SPEC.VM.IOD IO driver Project Software 4
IEVC.BASIC.TOOLS.AUTH SIDE Authorizer Project Software basic
IEVC.BASIC.TOOLS.CONF SIDE Configurator Project Software basic
IEVC.SENSOR.APP.IBTM iBTM application Project Data 4
IEVC.SENSOR.APP.ODO Odometry application Project Data 4

Allocate
Allocation of the URS requirement that requires to support ERTMS levels to the architecture and
its components that are required to read balises or loops and to connect to RBC through Euroradio
[allocate]

Data
• Requirement:
– tsc-req-urs-nobo-ievc-supports-etcs-l1-etcs-l2[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: System definition and purpose, Interfaces
• Justification: Level 0/1/2 management is made possible through the Sensor kit and Telecom
kit components, Level STM is made possible with the National system interface of the iEVC
system.

Allocate
Allocation of the URS requirement that requires that the iEVC system shall use its own odometry
system with 1 pulse generator and 1 or several other diversified sensors. [allocate]

64 of 750 6.8. Component list

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-ievc-execute-odometry-functions[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: System definition and purpose
• Justification: The system architecture introduces the components required for the odometry
functions of the iEVC system.

Allocate
Allocation of the URS requirement that requires a secondary speed sensor [allocate]
Data
• Requirement:
– tsc-req-urs-pha-secondary-speed-sensor[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: System definition and purpose
• Justification: The system architecture introduces a secondary odometry sensor that provides
a measure of the train displacement that does not depend on the wheels.

Allocate
Allocation of the URS requirement that requires a CPM [allocate]
Data
• Requirement:
– tsc-req-urs-operator-cpm[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: System definition and purpose
• Justification: The system architecture introduces a Crash Protected Memory to log opera-
tion, maintenance and juridical data.

6.8. Component list 65 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
CHAPTER

SEVEN

GENERAL DESCRIPTION

7.1 Platform

The iEVC on-board subsystem is built around the Safe computer. This generic product computer uses redundancy
to protect against hardware failures, according to the “Two Out of Two” principle (2oo2).
The Safe computer is structured in two domains, each running a different operating system.
• The safe domain is where the safety-related softwares must be run.
• The non-safety domain is where non-safety-related softwares can run.
Within the safe domain, the Safe computer provides a hardware fault protection mechanism.
The Virtual Machine runs within the safe domain. This software, in turn, offers the mechanisms necessary to load
and execute iEVC applications. In the iEVC architecture, the VM and its drivers are the only software to run in
the safe domain;
Within the non-safety domain, the TSC Net software offers a publish / subscribe message oriented middleware
to federate all the software running both in and out of the safe computer. Clients connect to the TSC Net to
publish and consume messages asynchronously. The Virtual Machine, for instance, recovers through TSC Net
its application packages at start-up. It also receives through TSC Net fresh samples from the Sensor box (see
[SyAD-R66-SIF-TSC-NET]).
The on-board operation and maintenance software (OBOM[ci]) runs within the non-safety domain. This super-
vision software is responsible for managing the boot sequence, uploading application and certificates to the VM.
Then it logs the execution of the VM. It is also responsible for managing fault and maintenance data collection,
logging and reporting.
In addition to these, the non-safety domain hosts communication protocol software, one for the Euroradio CFM,
and another one for the modem.
The Safe computer provides access to safe digital I/O, through its IO board[ci]. One of the board inputs is
reserved for a specific use: it is connected to the test key switch. This key switch, when turned on, informs the
Safe computer that the platform should run in a special Test mode. This test mode unlocks certain possibility in
the Virtual Machine related to testing. No specific equipment is required to test an LRU of the iEVC system. The
iODO Built-In Test Equipment (BITE) allows simulating wheel pulse generators and secondary sensor signal.
The Safe computer is interfaced via Ethernet with two other components: the Sensor box and the Telecom box.
The Sensor box contains the necessary electronics to acquire data from the speed sensors and the wayside devices,
while the Telecom box provides the necessary electronics to connect to the Internet (via a 4G interface) and to the
GSM-R network.
The Safe computer is also connected to the DMI[ci].

Important: In this release of the iEVC system, 4G interface is not activated.

Fig. 7.1 illustrates this iEVC on-board subsystem with its interfaces. Not all the iEVC components listed previ-
ously are represented, only those that have functional interfaces. Inside the Safe computer, a color code is used to
differentiate the components belonging to the safe and non-safe domains.

66 of 750 7. General description

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 7.1: iEVC On-board subsystem logical architecture

Allocate
Allocation of the URS requirement to include all tools required for maintenance and to avoid small
mechanical assembly [allocate]
Data
• Requirement:
– tsc-req-urs-periodic-maintenance-tools-included[req]
– tsc-req-urs-integrator-small-mechanical-assembly[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: Platform
• Justification: The requirement is covered by the BITE mechanism that requires no specific
tool to allow testing all LRU of the iEVC On-board subsystem. Only a cable is required to
loop back the iODO BITE signal to the sensor input connectors.

7.1. Platform 67 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.2 Interfaces

This section enumerates the interfaces of the system. When appropriate, reference is given to the corresponding
specification document. The interfaces are presented in three groups:
• “Application” interfaces: interface between iEVC applications
• “Internal” interfaces: interfaces that are part of the iEVC system at large;
• “Train” interfaces: interfaces with the train, of various types;
• “External” interfaces: interfaces with other systems
• “Graphical User Interfaces” (GUI or UI): graphical interfaces with users
Interfaces receive an arbitrary sequential identifier of type “[IF.XXXX.YY]”, “XXXX” being the certification kit
to which the interface belong (see iEVC certification kits) and “YY” being a sequence number.
Interfaces are documented in interface specifications. The definition of each interface in this section contains a
reference to the correct specification document.

Note: Some related interfaces are specified jointly in a single interface specification.

7.2.1 Application interfaces

Each application defines the variable it produces and consumes. Therefore, each application specification contains
its own interface specification.
When defining an application package for the Virtual machine[ci], the system engineer defines what output vari-
able from an application A should be fed as an input variable to application B, and when. This variable map is the
definition of the application interfaces for the application package.
In this system specification, application variables are defined as “TSC functional variables”. A convention is
followed for their description. This convention is specified here. It applies also to the variables exchanged between
the VM and the applications.
The attributes follow the conventions below:
• Attribute: the functional name of the variable in the Capella architecture diagram
• Objective: a description of the message purpose
• Description: a description of the message content
• Family: Software. It’s the default value, so it is not required to document it.
• Type: Name of the variable. Typically a Camel Case word
– Good: Counter, SomethingElse
– Bad: counter_1, Message 1
• Format: The type used. It can be complex types like structure, but then it needs to be described using the
BNF notation conventions of the Virtual Machine;
• Protocol: some application may require access to data provided by the Virtual Machine in the form of
built-in variables. In which case, pick one of the following:
– VM built-in IN variable
– VM built-in OUT variable
Other attributes are not used.
This is a template for such a variable:

68 of 750 7.2. Interfaces

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

.. tsc_functional_variable:: Rose counter

:objective: To inform about the amount of roses in the bunch of flowers
:description: A counter of the number of roses
:type: RosesCounter
:format: Integer
:protocol: VM built-in IN variable

7.2.2 Internal interfaces

Data
• Sil: 4

This interface is materialized by the specification of the application files that the Virtual machine[ci] can
execute.
It is therefore introduced as part of the Virtual Machine component description. It is further detailed in the
VM software design documents.

Configuration Item

VM - CFM interface [ci]

Data
• Sil: 4

This is the interface between the SFM component (inside the VM) and the CFM component. It is used for
Euroradio communication.

7.2. Interfaces 71 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

This interface is specified in [SyAD-R67-SIF-VM-CFM].

Configuration Item

VM - OBOM interface [ci]

Data
• Sil: basic

This TSC Net[ci] interface is used by OBOM[ci] to supervise the Virtual machine[ci].
This interface is specified in [SyAD-R62-SIF-OBOM-VM].

Configuration Item

VM - Safe computer OS interface [ci]

Data
• Sil: 4

Data
• Sil: basic

7.2. Interfaces 73 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

This network interface is used by OBOM to obtain the 4G Modem maintenance data. Typically, this
information is provided using a TSC Net message.
This interface is specified in [SyAD-R63-SIF-OBOM-4G]

Configuration Item

Modem Controller - OBOM interface [ci]

Data
• Sil: basic

This network interface is used by OBOM to obtain the GSM-R modem maintenance data. The modem
controller is responsible to acquire this information from the modem and push it through TSC Net to the
OBOM.
This interface is specified in [SyAD-R64-SIF-OBOM-MC]

Configuration Item

Ethernet Switch - OBOM interface [ci]

Data
• Sil: basic

This network interface is used by OBOM to obtain the Ethernet Switch maintenance data. Typically, this
information is provided using a SNMP protocol or a similar network management protocol.

Configuration Item

Modem Controller - GSM-R Modem Interface [ci]

Data
• Sil: 4

Note: This interface depends on the vendor/generic component selected for the GSM-R modem. It is
covered by the interface description in the supplier manual [SyAD-R53-GSMR-MANUAL].

7.2.2.5 Safe Relay interface

Configuration Item

Safety Relays - Safe Computer interface [ci]

Data
• Sil: 4

Safety relays provide dry contacts and allow adapting to higher line tensions and/or currents than those
of the IO boards of the Safe computer. This interface is the logical interface that is used to exchange the
digital I/O information from/to the IO boards of the safe computer.

7.2. Interfaces 75 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Note: This interface depends on the vendor/generic component selected for the Safe computer. It is not
detailed in this specification.

7.2.2.6 Telecom box physical interfaces

Configuration Item

Telecom box - 4G antenna interface [ci]

Data
• Sil: basic

This interface is the physical cable between the Telecom box and the 4G antenna. It includes the connector
on the Telecom box, the cable and the connector of the 4G antenna. If same antenna can be used for 4G
and GPS, this interface is common with Telecom box - GPS antenna interface[ci].

Note: This interface depends on the vendor/generic product selected for the 4G modem, as well as the
design of the telecom box. It is not detailed in this revision of the specification.

Configuration Item

Telecom box - GPS antenna interface [ci]

Data
• Sil: basic

This interface is the physical cable between the Telecom box and the GPS antenna. It includes the con-
nector on the Telecom box, the cable and the connector of the GPS antenna. If a same antenna can be used
for 4G and GPS, this interface is common with Telecom box - 4G antenna interface[ci].

Note: This interface depends on the vendor/generic product selected for the 4G modem, as well as the
design of the Telecom box. It is not detailed in this specification.

Configuration Item

Telecom box - GSM-R antenna interface [ci]

Data
• Sil: basic

This interface is the physical cable between the Telecom box and the GSM-R antenna. It includes the
connector on the Telecom box, the cable and the connector of the GSM-R antenna.

Note: This interface depends on the vendor selected for the GSM-R modem and antenna. It is not detailed
in this specification.

76 of 750 7.2. Interfaces

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Configuration Item

Telecom box - power supply interface [ci]

Data
• Sil: basic

This interface is the link between the Telecom box and the power supply. It contains also the ground
connection. It includes connectors and cables.
It is described in the Telecom box hardware component description.

Configuration Item

Telecom box - Ethernet interface [ci]

Data
• Sil: basic

This interface represents the physical Ethernet connections between the Telecom box and the Ethernet
switch and between the Telecom box and the tester laptop. This interface includes the ethernet connectors
on the Telecom box front panel.
It is described in the Telecom box hardware component description.

7.2.2.7 Computer box physical interfaces

Configuration Item

Computer box - Computer box Extension [ci]

Data
• Sil: 4

This interface is the link between the Safe computer and the extension rack.
It is described in the Safe computer component description.

Configuration Item

Computer box - Power supply interface [ci]

Data
• Sil: 4

This interface is the link between the Computer box and the power supply. It contains also the ground
connection.
It is described in the Computer Box component description.

7.2. Interfaces 77 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Configuration Item

Computer box - Safety Relays [ci]

Data
• Sil: 4

This interface is the link between the physical link between the Computer box and the Safety Relays.
It is described in the Safe computer component description.

Configuration Item

Computer box - Ethernet interface [ci]

Data
• Sil: 4

78 of 750 7.2. Interfaces

80 of 750 7.2. Interfaces

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Configuration Item

CPM - Ethernet interface [ci]

Data
• Sil: 4

This interface represents the physical Ethernet connections between the CPM and the Ethernet switch.

Note: This interface depends on the vendor selected for the CPM and Ethernet switch. It is not detailed
in this specification.

Configuration Item

Ethernet switch - Reset relay interface [ci]

Data
• Sil: basic

This interface represents the physical interface between the ethernet switch and the relays used to perform
a ‘hard’ reset of the DMI and/or the safe computer. This logical interface is described in Section 7.5.1.
It is the responsibility of the Installation designer to design this interface with dedicated relays that allow
cutting the power supply of the DMI and/or Computer box.

Note: The physical interface depends on the vendor selected for the relays and Ethernet switch. It is not
detailed in this specification.

7.2.2.10 National system interface

The iEVC system is designed to allow using Class B national systems as “iEVC applications” included in the
Safe computer with the other iEVC system applications. These Class B applications are modeled applications.
They may interface the Subset 026 application[ci] through an emulated STM interface inside the Safe computer.
This internal software interface is functionally compliant with [SyAD-R18-STM]. This Subset 035 STM interface
allows the Class B application to access the standard STM functions:
• Odometer
• Train interface
• Brake interface
• Juridical data
• DMI
The iEVC system design does not include a profibus interface for external STM devices. The physical part of
[SyAD-R18-STM] is not applicable to the iEVC system architecture design.

7.2. Interfaces 81 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 7.2: Integration of class B systems in the iEVC system using the STM interface

The Class B application[ci] may need to access the train interface for specific information not included in the
Subset 035 STM interface. In this case the Class B application[ci] can use the interface provided by the TIU
application (see TIU application). For example the TBL1+ application will need to access the brush information
through digital inputs in the train interface.
The Class B application[ci] may need to process KER balise information and can therefore interface
with the information coming from the iBTM driver. This information includes the Balise or loop de-
tection message[functional variable][VM - iBTM-RX interface][VM - Applications interface] and the Up-
link telegram message[functional variable][VM - iBTM-RX interface][VM - Applications interface] (see
[SyAD-R56-SIF-iBTM-VM]).

82 of 750 7.2. Interfaces

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 7.3: Generic interfaces of a Class B application

The Class B applications may also be used in a stand-alone implementation; meaning without the Subset 026
application[ci]. In that case the Class B application may access any of the interface variables that are accessible
to the Subset 026 application[ci].
The development of Class B applications is outside the scope of the iEVC system development. It has no impact
on the iEVC system development as long as no modification is required in the generic interfaces described above
or in the Subset 026 application interface. If a Class B application requires a modification of these interfaces, for
example to add a new driver that manages a specific protocol, then a new evolution of the iEVC system will need
to be triggered.
When the Class B application is executed together with the Subset 026 application[ci] inside the Safe com-
puter[ci], the compliance with the Subset 056 and Subset 057 that specify the Safe time layer and Safe link layer
of the STM communication bus is not required. The application layer according to [SyAD-R27-SS58] remains
applicable.

Requirement

The class B applications shall be compliant with Subset 035 and Subset 058 when they interface the
Subset 026 application. [id:tsc-req-ievc-classb-compliance-subsets][p1][ns]

Allocate
Allocation of URS requirements for a design compatible with the implementation of Belgian national
system. [allocate]

7.2. Interfaces 83 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-operator-belgian-compatibility[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: National system interface
• Justification: The iEVC system design allows developing national system as applications
that run in the Safe computer.

7.2.3 Train interface

The train interfaces of the iEVC systems are generic interfaces. They constitute an input for the engineering team
in charge of the installation design of the iEVC on a specific locomotive.

Configuration Item

iEVC - Train generic interface [ci]

Data
• Sil: 4

This interface describes the iEVC requirements on the train, in terms wiring and functional constraints.
This interface is specified in [SyAD-R73-SIF-Train-Generic].

7.2.4 External interfaces

Configuration Item

Eurobalise air-gap [ci]

Data
• Sil: 4

The Eurobalise air-gap is the interface used to transfer Tele-powering magnetic field to the Eurobalise,
KER balise or Euroloop device and to pick-up the Up-link magnetic field in response. The require-
ments and performance to be achieved for this interface are defined in [SyAD-R9-SS36] for Eurobalise,
in [SyAD-R50-SS44] for Euroloop and in [SyAD-R28-SS100] for KER balise.

Configuration Item

Euroradio air-gap [ci]

Data
• Sil: 4

84 of 750 7.2. Interfaces

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

[SyAD-R10-SS37] specifies for ERTMS/ETCS the Radio System Interoperability for message exchange
between on-board and trackside equipment in respect to safety-related application processes.
The “1A” interface defined in this Subset defines the boundary between the modem and the air-gap.

This is the user interface with the SIDE Configurator tool. Refer to Section 11.29 for a description of the
SIDE Configurator tool.

Configuration Item

SIDE Authorizer User Interface [ci]

7.2. Interfaces 85 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Sil: 4

This is the user interface with the SIDE Authorizer tool. Refer to Section 11.28 for a description of the
SIDE Authorizer tool.

Configuration Item

JRU decoder User Interface [ci]

Data
• Sil: basic

This is the user interface with the JRU decoder tool.

7.2.6 Interface list

The following tables provide a summary list of the interfaces of the iEVC system for each of the certification kit.
For each interface, the following information is provided:
• Code - a unique short code for the interface. Interfaces are numbered sequentially.
• Description - short description of the interface;
• Type - the type of the interface. Interface are either designed specifically for the iEVC (“Project”), or are
standardized outsourced components (“Generic component”);
• Status - what is the modification status of this interface component for this project. It can be ‘new’, if
the interface is created for the iEVC program, ‘modified’ if the interface exists and will be modified, or
‘unmodified’ if it exists and will be used as is;

7.2.6.1 iEVC Basic kit interfaces [recap table]

Table 7.1: iEVC Basic kit interfaces

Code Description Type Status
IEVC.BASIC.IF iEVC Basic kit interfaces Project New
IEVC.BASIC.IF.08 Safe computer - Test switch interface Project New
IEVC.BASIC.IF.09 VM - DMI interface Project New
IEVC.BASIC.IF.10 VM - Applications interface Project New
IEVC.BASIC.IF.12 VM - OBOM interface Project New
IEVC.BASIC.IF.13 DMI - OBOM interface Project New
IEVC.BASIC.IF.14 CPM - OBOM interface Project New
IEVC.BASIC.IF.18 Safety Relays - Safe Computer interface Project New
IEVC.BASIC.IF.21 Ethernet Switch - OBOM interface Project New
IEVC.BASIC.IF.22 Power supply - OBOM interface Generic Component Unmodified
IEVC.BASIC.IF.23 SIDE Configurator User Interface Project New
IEVC.BASIC.IF.24 SIDE Authorizer User Interface Project New
IEVC.BASIC.IF.31 Computer box - Computer box Extension Generic Component Unmodified
IEVC.BASIC.IF.42 TSC Net - OBOM interface Project Unmodified
IEVC.BASIC.IF.46 DMI ETCS User Interface Generic Component Unmodified
IEVC.BASIC.IF.47 DMI Fault User Interface Project New
continues on next page

86 of 750 7.2. Interfaces

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Table 7.1 – continued from previous page

Code Description Type Status
IEVC.BASIC.IF.48 DMI Maintenance User Interface Project New
IEVC.BASIC.IF.49 Computer box - Ethernet interface Generic Component Unmodified
IEVC.BASIC.IF.50 Computer box - Power supply interface Generic Component Unmodified
IEVC.BASIC.IF.51 VM - Safe computer OS interface Project New
IEVC.BASIC.IF.52 VM - debug interface Project New
IEVC.BASIC.IF.66 DMI - Ethernet interface Generic Component Unmodified
IEVC.BASIC.IF.67 CPM - Ethernet interface Generic Component Unmodified
IEVC.BASIC.IF.68 Computer box - Safety Relays Generic Component Unmodified
IEVC.BASIC.IF.69 Ethernet switch - Reset relay interface Generic Component New

7.2.6.2 iEVC Sensor kit interfaces [recap table]

Table 7.2: iEVC Sensor kit interfaces

Code Description Type Status
IEVC.SENSOR.IF.01 Tele-powering loop interface Project New
IEVC.SENSOR.IF.02 RX loop interface Project New
IEVC.SENSOR.IF.03 Test loop interface Project New
IEVC.SENSOR.IF.04 VM - iBTM-TX interface Project New
IEVC.SENSOR.IF.05 VM - iBTM-RX interface Project New
IEVC.SENSOR.IF.06 VM - iODO interface Project New
IEVC.SENSOR.IF.07 VM - iODO BITE interface Project New
IEVC.SENSOR.IF.32 Sensor box - Ethernet interface Generic Component Unmodified
IEVC.SENSOR.IF.33 Sensor box - Power supply interface Generic Component Unmodified
IEVC.SENSOR.IF.34 Sensor box - Euroantenna interface Project New
IEVC.SENSOR.IF.35 Sensor box - Secondary sensor interface Generic Component Unmodified
IEVC.SENSOR.IF.36 Sensor box - Loopback interface Generic Component Unmodified
IEVC.SENSOR.IF.37 Sensor box - Pulse generator interface Generic Component Unmodified
IEVC.SENSOR.IF.38 Sensor box - Secondary sensor BITE interface Project New
IEVC.SENSOR.IF.39 Sensor box - Pulse generator BITE interface Project New
IEVC.SENSOR.IF.40 Sensor box - V1V2 interface Project New
IEVC.SENSOR.IF.44 Eurobalise air-gap Generic Component Unmodified
IEVC.SENSOR.IF.59 iODO - iODO BITE interface Project New
IEVC.SENSOR.IF.70 Sensor Box Ethernet Switch - OBOM interface Project New

7.2.6.3 iEVC Telecom kit interfaces [recap table]

Table 7.3: iEVC Telecom kit interfaces

Code Description Type Status
IEVC.TELECOM.IF.11 VM - CFM interface Project New
IEVC.TELECOM.IF.15 NMEA 0183 GPS interface Project New
IEVC.TELECOM.IF.16 CFM - Modem Controller interface Project New
IEVC.TELECOM.IF.17 Modem Controller - GSM-R Modem Interface Project New
IEVC.TELECOM.IF.19 4G Modem - OBOM interface Generic Component Unmodified
IEVC.TELECOM.IF.20 Modem Controller - OBOM interface Project New
IEVC.TELECOM.IF.26 Telecom box - 4G antenna interface Generic Component Unmodified
IEVC.TELECOM.IF.27 Telecom box - GPS antenna interface Generic Component Unmodified
IEVC.TELECOM.IF.28 Telecom box - GSM-R antenna interface Generic Component Unmodified
IEVC.TELECOM.IF.29 Telecom box - Ethernet interface Generic Component Unmodified
IEVC.TELECOM.IF.30 Telecom box - power supply interface Generic Component Unmodified
IEVC.TELECOM.IF.45 Euroradio air-gap Generic Component Unmodified

7.2. Interfaces 87 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.2.6.4 iEVC ETCS kit interfaces [recap table]

Table 7.4: iEVC ETCS kit interfaces

Code Description Type Status
ETCS.IF.25 JRU decoder User Interface Project New
ETCS.IF.41 iEVC - Train generic interface Generic Component Unmodified

7.3 Power supply distribution

Requirement

The iEVC Sensor box and telecom box shall have two power plugs, each one connected to 1 power
supply component inside the box. [id:tsc-req-ievc-hw-box-sources][p1][ns]

When the vehicle provides two independent power sources, each of them shall be connected to one of the
plugs. When only one power source is available on-board, it shall be connected to both plugs.

Note: The previous requirement is not applicable to the Computer box as the selected product has been designed
to use only one power source.

Requirement

When only one power line is available on-board, the power cable from this source shall be designed
to connect to the 2 power plugs of the Sensor box and Telecom box. [id:tsc-req-ievc-hw-box-sources-
cable][p1][ns]

The Computer box only has one power plug.

7.3.1 Distribution scheme

Two options exist depending on whether the train has 2 redundant power lines or not.

88 of 750 7.3. Power supply distribution

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 7.4: iEVC power distribution scheme - 1 power line

Figure 7.5: iEVC power distribution scheme - 2 power lines

Note: the optional Computer box extension[ci] is not represented in the previous figures. It has a maximum con-
sumption of 40W (see tsc-req-ievc-hw-safe-computer-io-extension-power[req]). Also the second Sensor box[ci]
(in case 2 Euroantenna are required) is not represented. Its maximum power consumption is 90W and can be
deduced from its components consumption requirements, refer to Power supply requirements.

7.3. Power supply distribution 89 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Note: Antenna and sensors are not represented in the previous figure. The power for antenna and sensors is
supplied by the box to which they are connected.

7.3.2 Budget

Based on benchmark study carried out during the feasibility phase, the power budget to be allocated to a box
should be 120W (this is the figure required by some generic product vendors).

Note: The Ethernet switch was initially part of the Telecom box but has been taken out. Therefore the Telecom
box has a reduced power budget of 90W (see tsc-req-ievc-hw-telecom-box-max-power[req]). The Ethernet switch
power budget is 30W (see tsc-req-ievc-hw-switch-power[req]).

Requirement

The maximum power consumption of the box shall be 120W or less. [id:tsc-req-ievc-hw-box-max-
power][p1][ns]

This figure makes it at par with a large laptop PC, hence can be compatible with fanless requirements.
However, lower figures are possible and should be proposed.
This general requirement is refined box by box per component inside the box.

Requirement

The maximum power consumption of the telecom box box shall be 90W or less. [id:tsc-req-ievc-hw-
telecom-box-max-power][p1][ns]

Requirement

A LED on the front panel of each box shall indicate if the power supply is nominal. LED power
consumption should be less than 1% of total power consumed. [id:tsc-req-ievc-hw-box-led][p2][ns]

The LED shall indicate perturbations as short-circuit. iEVC components should not drain power when
switched off.

Requirement

The maximum power consumption of the Crash Protected Memory component shall be 20W or less
[id:tsc-req-ievc-cpm-max-power][p2][ns]

Requirement

The maximum power consumption of one DMI component shall be 40W or less [id:tsc-req-ievc-dmi-
max-power][p1][ns]

Requirement

Component power consumption shall not exceed 0 Watt when switched off. [id:tsc-req-ievc-hw-zero-
watt-when-off][p2][ns]

90 of 750 7.3. Power supply distribution

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The maximum power consumption of the ethernet switch shall be 30W or less. [id:tsc-req-ievc-hw-
switch-power][p2][ns]

7.4 Cycle time

7.4.1 VM cycle

The iEVC performs its computations in a cyclic fashion. Each cycle is driven by the Virtual Machine. During a
round of computation, the VM performs the following:
• Consume incoming messages from its incoming TSC Net message queue;
• Recover incoming data from its drivers (e.g. acquiring the status of IO boards);
• Recompute the state of applications, based on the received incoming data;
• Publish the result as outgoing messages on its outgoing TSC Net message queue;
• Update the outgoing data of its drivers (e.g. commanding the I/O boards)

Functional Variable
VM_cycle_time [functional variable]
Data
• Objective: To allow controlling the VM execution cycle
• Description: The VM cycle time is a fixed value. This cycle is used to trigger time-based
events, as well as guarantee that certain performance figures are met. Therefore, it must
be controlled. First, a watchdog mechanism is provided by the Safe computer platform to
ensure that the execution cycle is never exceeded. Second, this watchdog mechanism is used
by the VM to put its execution time under control.
• Family: Software

The maximum value of the VM_cycle_time is fixed to 200 ms (see tsc-req-ievc-sw-vm-cycle-time[req]).

Requirement

Safe computer shall include a safe watchdog mechanism to allow safety critical software to ensure
they never exceed their allocated execution time. This watchdog shall have a precision of 1ms
[id:tsc-req-ievc-hw-sc-watchdog][p1][s]

Should the watchdog expire, the Safe computer shall trigger its Fail Safe mode and put its safe outputs in
their restrictive state. The restrictive states depend on the technology of the IO boards used in the Safe
computer. They are the guaranteed default states assumed by the digital outputs whenever a critical failure
occurs such as a complete loss of power.

Requirement

Using a watchdog mechanism provided by the underlying Safe computer, VM shall control its exe-
cution cycle with a tolerance of 1ms. The watchdog cycle time shall be set to a value lower or equal
to 200ms. [id:tsc-req-ievc-sw-vm-cycle-time][p1][s]

7.4. Cycle time 91 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.4.2 Asynchronous inputs and outputs

Incoming and outgoing messages are exchanged by the VM through TSC Net[ci]. Due to the asynchronous nature
of these exchanges, certain message exchanges over this protocol require a synchronization protocol. This protocol
allows to estimate safely the age of the message received in the VM time reference, and accept only those messages
that are sufficiently recent. This threshold is defined by each receiving driver and possibly each application, based
on system tolerances. The generic interfaces providing such mechanisms are:
• The interface between the iBTM and the VM: [SyAD-R56-SIF-iBTM-VM];
• The interface between the iODO and the VM: [SyAD-R59-SIF-iODO-VM];

7.4.3 Safe digital inputs and outputs

The interface providing safe digital inputs and outputs is provided by the Safe computer. The status of safe inputs
and outputs is sampled by the VM every cycle.
The key timing parameter of this interface is the worst case time for a vital output to reach its safe position once
the VM has decided it should be in this position.

Requirement

The worst case delay between the moment when a safety-critical software has set a vital output to
a restrictive state, and the moment when the output board is in restrictive state, shall be less than
100ms [id:tsc-req-ievc-hw-sc-safe-output-restrictive-state-delay][p1][s]

Furthermore, safe outputs may be mediated by intermediary safety relays. These relays can have high worst
case contact opening delays. Therefore, it is assumed that the installation design shall install two such relays for
controlling safe outputs.

Requirement

When a safe output of the Safe computer needs to command the opening of a safe relay to achieve a
safe state (for example brake applied), the Installation design shall use two safety relays in series to
limit the worst case relay opening delay. [id:tsc-req-ievc-hw-safe-output-double-cut][p1][s]

Requirement

Nominal delay to open a normally open contact shall be less than 100ms [id:tsc-req-ievc-hw-safe-relay-
n-o-nominal-delay][p1][ns]

7.4.4 Chronogram

The Fig. 7.6 illustrate a VM cycle in the form of a chronogram. Incoming messages from TSC Net are entered in
a queue, that is unpiled by the VM at the beginning of each evaluation cycle. Applications are then run, and the
results pushed out in outgoing queues.
In order to know what was the last message consumed prior to execution, the VM write the corresponding message
counter from TSC Net in the message that indicates the completion of each evaluation cycle.

92 of 750 7.4. Cycle time

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 7.6: iEVC chronogram

7.5 Platform software update

7.5.1 Update interface

The platform software is defined as the software running on the following components:
• The iBTM-RX[ci];
• The iBTM-TX[ci];
• The iODO[ci];
• The iODO BITE[ci];
• The Safe computer[ci];
• The DMI[ci];
• The 4G modem[ci];
• The Crash protected memory[ci].
This definition encompasses programmable hardware (e.g. FPGA). It shall be possible to update these through a
network interface.
Requirement

The update of a platform software shall be possible through its network interface. [id:tsc-req-ievc-
component-sw-remote-programming][p2][ns]

After an update, the component reset shall be possible through this same network interface.
Only the Safe computer and the DMI are managed in a specific way. The Safe computer and the DMI components
on the market cannot be reset directly through the network interface. They require a ‘hard’ reset through a new
power on cycle. Therefore their reset shall be performed by commanding 2 dedicated digital output of the Ethernet
switch. These digital outputs shall be connected to ‘normally closed’ relays that provide the power supply for these
components.

7.5. Platform software update 93 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

Component shall be resettable through its network interface. [id:tsc-req-ievc-component-sw-remote-

reset][p2][ns]

Requirement

The Ethernet switch shall have at least 2 digital outputs that can be controlled through its network
interface. [id:tsc-req-ievc-ethernet-switch-digital-outputs][p1][ns]

The first digital output is used for the reset of the Safe computer and the second digital output for the reset
of all the installed DMIs.

Requirement

One of the digital outputs of the Ethernet switch shall be connected to a ‘normally closed’ relay
that allows to trigger a new power on cycle of the Safe computer [id:tsc-req-ievc-cabling-to-reset-safe-
computer][p1][ns]

Requirement

One of the digital outputs of the Ethernet switch shall be connected to a ‘normally closed’ relay that
allows to trigger a new power on cycle of DMI computers installed on-board. [id:tsc-req-ievc-cabling-
to-reset-dmi][p1][ns]

The wired digital outputs used to reset the Safe computer and the DMI are included in the Ethernet switch - Reset
relay interface[ci].

Functional Variable
Safe computer reset [functional variable]
Data
• Objective: To provide electrical level of the inputs of the safety relays performing the reset
of the Safe computer
• Description: set of wires that connect the digital output of the ethernet switch to the safety
relay controlling the power supply of the safe computer.
• Family: Hardware
• Type: Wired
• Format: schematics
• Associated interface:
– Ethernet switch - Reset relay interface[ci]

Functional Variable
DMI reset [functional variable]

94 of 750 7.5. Platform software update

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide electrical level of the inputs of the safety relays performing the reset
of the DMI
• Description: set of wires that connect the digital output of the ethernet switch to the safety
relay controlling the power supply of the DMI.
• Family: Hardware
• Type: Wired
• Format: schematics
• Associated interface:
– Ethernet switch - Reset relay interface[ci]

7.5.2 Application compatibility

After the platform software has been updated, it is necessary to determine if the application software remains
compatible with this update.
iEVC applications run on the virtual machine. Application files are compatible with a specific version of the
format of the files that this virtual machine can interpret. The following mechanism applies:
• Every version of the VM uniquely identifies the formats it is compatible with. This format should be
documented in a specific deliverable;
• iEVC applications declare the version of format they comply to;
• VM verifies that the format of application is compatible. This is done during the authorization process (refer
to [IEVC.F1.05.10] Verify Authorization[function]).

Requirement

Virtual machine documentation shall identify in a specific document what file formats it can ac-
cept. Each acceptable format shall be given a unique identification string [id:tsc-req-ievc-vm-file-
format][p1][ns]

Requirement

The files loaded by the Virtual machine (application file, configuration file and application package
descriptor) shall include an identification number of the Virtual machine file format it follows.
[id:tsc-req-ievc-vm-file-format-id-in-file][p1][ns]

A variable of type ‘string’ called ‘EXS_file_format’ shall be be used in the root namespace of the ap-
plication. Its format shall be ‘X.Y.Z’ with ‘X’, ‘Y’ and ‘Z’ being the major, middle and minor EXS file
version.

Requirement

When loading application package files, the Virtual machine shall verify the *format version* of
the loaded files are compatible with a the specific format that this virtual machine can interpret.
[id:tsc-req-ievc-vm-file-format-verify][p1][ns]

If a file format is not supported the VM shall go to VM_FAULT.

7.5. Platform software update 95 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.5.3 Sensors compatibility

Compatibility checks on the iODO and iODO BITE shall be done by the Virtual Machine. This implies that
the interface between these components and the VM contains the necessary information (see tsc-req-ievc-iodo-
version[req] and tsc-req-ievc-iodobite-version[req]).

Requirement

The iODO driver shall verify that it is compatible with iODO hardware and software versions.
[id:tsc-req-ievc-iodo-drv-version-check][p1][s]

Requirement

The iODO BITE driver shall verify that it is compatible with iODO BITE hardware and software
versions. [id:tsc-req-ievc-iodo-bite-drv-version-check][p1][ns]

Compatibility checks on the iBTM-RX and iBTM-TX shall be done by the Virtual Machine. This implies that the
interface between these components and the Virtual machine contains the necessary information.

Requirement

The status messages of the iBTM components in their interface with the iBTM driver shall include
information about their hardware and software version. [id:tsc-req-ievc-ibtm-msg-sw-version][p1][ns]

Requirement

The iBTM driver shall verify that it is compatible with the iBTM components hardware and soft-
ware versions received by the iBTM driver. [id:tsc-req-ievc-ibtm-drv-version-check][p1][s]

7.6 Failure management strategy

The failure management strategy of the iEVC system relies mainly on 3 components: the Safe computer, the
Virtual Machine and the On-Board Operation and Maintenance software (OBOM). The failure mechanisms for
these 3 components are detailed in the sections below.

7.6.1 Safe Computer failures

7.6.1.1 Failure mechanism 1

• Failure Cause
– VM cycle watchdog expiration, or
– VM going to mode VM_FAULT, or
– Other hardware or software critical failures (vendor dependent)
• Failure effect
The Safe computer goes to ‘Fail Safe’ mode. This means that the Safe computer digital outputs are set to a
restrictive state. This causes the application of the emergency brake.
• Reference
– Safe computer failure modes,
– Safe computer modes

96 of 750 7.6. Failure management strategy

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.6.1.2 Failure mechanism 2

• Failure Cause
Non-critical failures or failures impacting only the non-safe domain.
• Failure effect
No change of mode. The Safe computer reports its fault information to the VM that may forward it to the
signalling applications. The reaction is specific to the signalling application based on the type of failure.
• Reference
Safe computer failure modes

7.6.2 Virtual Machine

7.6.2.1 Failure mechanism

• Failure Cause
– failure to flush the loaded application in VM_START mode, or
– failure to load the VM configuration file in VM_START mode, or
– failure to load the application package files in VM_LOADING mode, or
– failure to verify the package certificate in VM_LOADING mode, or
– failure to execute the configuration application in VM_LOADING mode, or
– attempt of a forbidden action by an application in VM_READY, or
– hardware or software incompatibility detected with the sensor components (iODO, iODO BITE,
iBTM-TX, iBTM-RX)
• Failure effect
The VM goes to VM_FAULT, and it reports its state to the Safe computer that goes, in turn, to Fail Safe
mode.
• Reference
VM Initialization States

7.6.3 OBOM

7.6.3.1 Failure mechanism 1

• Failure Cause
VM going to mode VM_FAULT
• Failure effect
OBOM goes to OBOM_VM_FALLBACK mode. The functions related to maintenance and fault that do
not require interaction with the VM or one of its iEVC applications remain active.
• Reference
OBOM Virtual Machine supervision modes

7.6. Failure management strategy 97 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.6.3.2 Failure mechanism 1

• Failure Cause
Failure in OBOM execution
• Failure effect
There is no specific OBOM software mode. All OBOM functions are unavailable. If the VM was running,
it continues its execution in the safe domain of the Safe computer. If the VM was not running, it does
not start its execution since the OBOM does not provide the message VM Load application package and
certificate[functional variable][VM - OBOM interface] that allows the VM to load its application package
and certificate. The brakes remain applied since no iEVC application is able to change the restrictive states
of the corresponding digital outputs.
• Reference
OBOM Failure modes

7.6.4 Other LRU failure

When other LRU fail (other than the Safe computer, VM or OBOM), and supposing that the failure is detected,
the detecting component reports the failure to the OBOM or to the VM as described in [IEVC.F4.28] Provide
maintenance and fault information[function]. Ultimately the fault is reported to an iEVC applications such as
LRU application or Subset 026 Application. The iEVC applications are responsible to react in an appropriate way
considering the operational impact of the failure and/or the signalling requirements. These reactions are outside
of the scope of the iEVC system.

7.7 Recovery strategy

7.7.1 Safe computer recovery strategy

In case the Safe computer goes to Fail Safe mode or stops operating, a reset of the Safe computer is ultimately the
only way to recover. This will trigger a restart of the entire application code. This reset can be triggered through
a specific digital output of the Ethernet switch (see Update interface).

Note: In a future baseline, the reset will also be possible remotely.

7.7.2 Sensors recovery strategy

In case a peripheral component fails, the asynchronous design of the iEVC means that it is possible to recover the
situation by simply resetting the failed device, without having the entire application going through a reset. Drivers
and OBOM can trigger this through the network interface thanks to tsc-req-ievc-component-sw-remote-reset[req]
(refer to Update interface).

Requirement

In case of a detected iODO failure, the Odometry application shall automatically attempt N times to
reset it, where N shall be a parameter of the application [id:tsc-req-ievc-odo-app-auto-reset][p1][ns]

The iODO failure that triggers the reset is the ‘iODO board status alarm’ (see ‘Odometry fault map’).
iODO maximum failures[functional variable] represent the failures N parameter.

98 of 750 7.7. Recovery strategy

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
Maximum iODO failures reset [functional variable]
Data
• Objective: Specifies the number of iODO resets that should be attempted after a failure
• Description: An integer value
• Family: Software
• Type: MaximumIODOResetCount
• Format: Integer
• Protocol: System parameter
• Minimum: 0
• Maximum: 10

Requirement

In case of a detected iBTM-RX or iBTM-TX board failure, iBTM application shall automatically
attempt N times to reset it, where N shall be a parameter of the application [id:tsc-req-ievc-ibtm-app-
auto-reset][p1][ns]

The failure is detected based on the board status contained in iBTM-RX status message[functional vari-
able][VM - iBTM-RX interface] and iBTM-TX status message[functional variable][VM - iBTM-TX inter-
face][VM - Applications interface]. The board failures that trigger a reset are the ‘iBTM-RX status alarm’
and ‘iBTM-TX status alarm’ (see ‘iBTM fault map’).
A new reset attempt will be made after the expiration of a configurable delay without a status message
indicating that the board is healthy. This configurable delay is Timeout for next reset[functional variable].
Maximum iBTM-RX failures reset[functional variable] represents the number of reset attempts N for the
iBTM-RX components. Maximum iBTM-TX failures reset[functional variable] represents the number of
reset attempts N for the iBTM-TX components.
The requirement applies to all iBTM components including those of the second sensor box, when two
2 Euroantenna need to be installed on-board (one for each cab or desk). It also applies whatever the
activation status of the Euroantenna.

Functional Variable
Maximum iBTM-RX failures reset [functional variable]
Data
• Objective: Specifies the number of iBTM-RX resets that should be attempted after a failure
• Description: An integer value
• Family: Software
• Type: MAX_IBTMRX_RESET
• Format: Integer
• Protocol: System parameter
• Minimum: 0
• Maximum: 10

7.7. Recovery strategy 99 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
Maximum iBTM-TX failures reset [functional variable]
Data
• Objective: Specifies the number of iBTM-TX resets that should be attempted after a failure
• Description: An integer value
• Family: Software
• Type: MAX_IBTMTX_RESET
• Format: Integer
• Protocol: System parameter
• Minimum: 0
• Maximum: 10

Functional Variable
Timeout for next reset [functional variable]
Data
• Objective: Specifies the maximum delay for the reception of a status message from a board
after a reset order has been sent.
• Description: An integer value
• Family: Software
• Type: MAX_IBTM_RESET_DELAY
• Format: Integer
• Unit: ms
• Protocol: System parameter
• Minimum: 0
• Maximum: 1000000

For sensor devices (e.g. iBTM-RX, iBTM-TX and iODO), depending on the result of RAMS analysis, the appli-
cations may decide to prevent further reset of failed components (in other words, “lock” the device).

Requirement

iODO application shall lock out an iODO when a certain number of failures (or reset attempts) N is
accumulated against a time window T. N and T shall be parameters of the application. [id:tsc-req-
ievc-odo-app-lock-thresholds][p1][ns]

iODO maximum failures[functional variable] represent the failures N parameter. iODO maximum failures
time window[functional variable] represent the time window T parameter. The time window is a sliding
window.

Functional Variable
iODO maximum failures [functional variable]

100 of 750 7.7. Recovery strategy

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: Specifies the number of maximum boards failures or reset attempts during the
:tsc:`functional_variable:iODO maximum failures time window` that Odometry application
can tolerate before being locked out of service.
• Family: Software
• Type: MAX_IODO_FAILURES
• Format: Integer
• Protocol: System parameter
• Minimum: 0
• Maximum: 10

Functional Variable
iODO maximum failures time window [functional variable]
Data
• Objective: Specifies a time window during which the odometry application shall count the
number of failures or reset attempts of IODO 1 and IODO 2 boards in order to evaluate the
criteria to lock out the boards.
• Family: Software
• Type: MAX_IODO_FAILURE_TIME_WINDOW
• Format: Integer
• Unit: ms
• Protocol: System parameter
• Minimum: 0
• Maximum: 1000000

Requirement

iBTM application shall lock out iBTM-RX and/or iBTM-TX when a certain number of failure (or
reset attempts) N is accumulated against a time window T. N and T shall be parameters of the driver.
[id:tsc-req-ievc-ibtm-app-lock-thresholds][p1][ns]

iBTM maximum failures[functional variable] represent the failures N parameter. iBTM maximum failures
time window[functional variable] represent the time window T parameter. The time window is a sliding
window.

Functional Variable
iBTM maximum failures [functional variable]

7.7. Recovery strategy 101 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: Specifies the number of maximum boards failures or reset attempts during the
:tsc:`functional_variable:iBTM maximum failures time window` that iBTM application can
tolerate before being locked out of service.
• Family: Software
• Type: MAX_IBTM_FAILURES
• Format: Integer
• Protocol: System parameter
• Minimum: 0
• Maximum: 10

Functional Variable
iBTM maximum failures time window [functional variable]
Data
• Objective: Specifies a time window during which the iBTM application shall count the
number of failures or reset attempts of the iBTM boards in order to evaluate the criteria to
lock out the boards.
• Family: Software
• Type: MAX_IBTM_FAILURE_TIME_WINDOW
• Format: Integer
• Unit: ms
• Protocol: System parameter
• Minimum: 0
• Maximum: 1000000

7.7.3 DMI recovery strategy

The DMI hardware incorporates a watchdog mechanism (tsc-req-ievc-ob-dmi-hw-req14[req]). In case of failure,

this watchdog mechanism will trigger the reboot of the DMI. Seen from the safe computer, this will be managed
as a DMI connection re-initialization.

7.8 Performance requirements

7.8.1 Subset 036 requirements

7.8.1.1 Balise relocation error

Excluding odometry errors, the balise relocation error according to Subset 036 shall be within +/-1m (tsc-req-
subset-036-4-2-10-2-1[req], tsc-req-subset-036-4-4-6-2-4-1[req])

102 of 750 7.8. Performance requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Allocate
Allocation of Subset 036 balise relocation error [allocate]
Data
• Requirement:
– tsc-req-subset-036-4-2-10-2-1[req]
– tsc-req-subset-036-4-4-6-2-4-1[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: Balise relocation error
• Justification: The balise relocation error is demonstrated by suitable computations in the
System Architecture Description.

The following errors need to be considered:

• 𝜀𝑡𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 : the error induced by the timestamping of the rising and falling edge of the balise contact
detection by the iBTM-RX modules.
– Requirement on the iBTM-RX: 0.1ms timestamping accuracy (tsc-req-ievc-ibtm-rx-timestamp-
precision[req])
– Requirement on the Safe computer underlying the VM: 0.1ms timestamping accuracy (tsc-req-ievc-
safe-computer-sil-4-operating-system[req])
– So, 0.4ms error on the timestamping: (0.1ms at iBTM-RX side + 0.1 ms at safe computer side) x2
since this error may affect both the balise contact entry and exit messages. At 500kph, this induces a
worst case error of 5.5cm.
• 𝜀𝑎𝑠𝑦𝑚 : the error induced by the asymmetry of the balise response. This error characterizes the fact that a
balise is qualified to respond with a power level that is comprised within a normalized 1.5dB band around a
reference signal. Taking this tolerance into account results into an uncertainty on the exact position of the
center of the balise;
– The hypothesis based on testing shows a maximum +/-10cm error (even if reasonably an error of +/-
5cm is more likely.
• 𝜀𝑓 𝑎𝑖𝑙 : the error induced by the potential failure of a balise during the passage. This error may result into a
shortened lobe and an offset on the balise position;
– Two parameters need to be defined in our system:

* balise contact minimum length[functional variable] (30cm according to Subset 036 section
5.2.2.5 Fig. 13)

* balise contact maximum length[functional variable] (70cm according to Subset 036 section
5.2.2.5 Fig. 13)
And,

𝜀𝑓 𝑎𝑖𝑙 = 1/2.(𝑖𝑏𝑡𝑚_𝑐𝑜𝑛𝑡𝑎𝑐𝑡_𝑚𝑖𝑛_𝑙𝑒𝑛𝑔𝑡ℎ + 𝑖𝑏𝑡𝑚_𝑐𝑜𝑛𝑡𝑎𝑐𝑡_𝑚𝑎𝑥_𝑙𝑒𝑛𝑔𝑡ℎ)

𝜀𝑓 𝑎𝑖𝑙 = 50𝑐𝑚

Total error is thus in worst case conditions:

5.5 + 10 + 50 = 65.5𝑐𝑚 < 1𝑚

7.8. Performance requirements 103 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.8.2 Subset 041 requirements

The computations detailed in this section are performed in the following embedded Excel spreadsheet:

Input Data Table

SUBSET 041 Analysis [xlsx data]

Assumption

The model is in state-space form [assumption]

7.8. Performance requirements 105 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Id: IEVC-ASS-SYAD-ODO-002
• Ci:
– iEVC[ci]
• Source:
– iEVC System Architecture Description[artifact]

This assumption is correct. The position of a train and its speed is adequately represented by a state vector.

Assumption

The state and measurement noise models are zero mean gaussian and independent of one another
[assumption]

Data
• Id: IEVC-ASS-SYAD-ODO-003
• Ci:
– iEVC[ci]
• Source:
– iEVC System Architecture Description[artifact]

For state, the noise is due to:

• Error due to the constant acceleration hypothesis (as explained below). It is reasonable to model
changes in accelerations as a gaussian noise since it corresponds to the driver commands while
driving the train;
• Error on the wheel diameter, either from measurement error and oscillation due to the wheel conicity
generating. Such errors are gaussian in nature;
• Error due to slipping and sliding of the wheels. Such events occur randomly, and so may be ade-
quately modeled as a gaussian.
For measurements, the noise depends on the model of sensors:
• There is quasi zero noise on the pulse generators due to their nature: pulse counts can be off by +1
or -1 pulse due the resolution of the sensor;
• There may be some noise on the secondary sensor due to the image processing. For instance, when
going over crossings, the secondary sensors like cameras or Doppler have issues. Such events can
be modeled as random events, so the hypothesis is reasonable
There is reasonably no dependency between the state and measurement noises. The measurement process
error is not affected by the error on the state of the system and vice versa.
For example, the uncertainty on the wheel diameter does not affect the reliability of the pulse count pro-
cess.
Therefore, overall, the assumption is reasonable.

Let 𝑘 be the count of computation rounds by the VM. The kinematic model assumes constant acceleration 𝑎 of the
train, e.g.:

𝑎𝑘 = 𝑎𝑘−1

106 of 750 7.8. Performance requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The speed 𝑣 of the train is estimated as:

𝑣𝑘 = 𝑣𝑘−1 + 𝑎𝑘1 .𝑇𝑉 𝑀 _𝑐𝑦𝑐𝑙𝑒

This equation is not accurate, since a train may accelerate or decelerate while an evaluation of the speed and
distance is pending. This error is modeled using a process noise covariance matrix 𝑄𝑘 . Let:
• 𝜎𝑎 be the error made by the kinematic model on the estimate of acceleration;
• 𝜎𝑣 be the error made by the kinematic model on the estimate of speed
• 𝜎𝑑 be the error made by the kinematic model on the estimate of distance
Then :
⎡ 2 ⎤
𝜎𝑎 0 0
𝑄𝑘 = ⎣ 0 𝜎𝑣2 0⎦
0 0 𝜎𝑑2

While the Kalman filter also takes into account measurement noises, these noises are negligible when compared
to the process noise, that must take into account all non-measurable variations between the moment the speed
measurement was done and the actual moment it is taken into account to produce a new estimate:
• The maximum variation of acceleration (a.k.a. jerk)
• The effect of uncertainties on the wheel diameter, leading to systematic errors in the speed measurements;
• The effect of slipping and sliding
Let:
• 𝑗𝑚𝑎𝑥 be the maximum absolute jerk value of the train
• 𝑡 be the age of the speed sample used, that is, the time elapsed between now and the moment it was elabo-
rated by the iODO module
• 𝜖𝑤𝑑 be the tolerated error on the wheel diameter parameter
• 𝑣𝑚𝑎𝑥 be the maximum speed of the train
Then, in the worst case scenario, the error made on the acceleration estimate shall be:

𝜎𝑎 = 𝑗𝑚𝑎𝑥 .𝑡

And the error made on the estimate of the speed is the sum of the errors due to jerk, wheel diameter and slipping
and sliding:

𝜎𝑣 = 𝜎𝑣_𝑗𝑒𝑟𝑘 + 𝜎𝑣_𝑤𝑑 + 𝜎𝑣_𝑠𝑙𝑖𝑝𝑠𝑙𝑖𝑑𝑒

𝜎𝑣_𝑗𝑒𝑟𝑘 = 1/2.𝑗𝑚𝑎𝑥 .𝑡2
𝜎𝑣_𝑤𝑑 = 𝜖𝑤𝑑 .𝑣𝑚𝑎𝑥

We assume the requirement from [SyAD-R26-SS41] to correspond to a 6.5𝜎 confidence interval.

Assumption

Subset 041 requirements for confidence interval correspond to a 6.5 sigma interval [assumption]

7.8. Performance requirements 107 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Id: IEVC-ASS-SYAD-ODO-004
• Ci:
– iEVC[ci]
• Source:
– iEVC System Architecture Description[artifact]

This translate to an expected fraction of estimates out of range of 8.032E-11. We need to multiply this
value by the expected occurrence per hour of the event “the working odometry system provides an in-
consistent result”. For a SIL 4 hazard rate of 1E-9 h-1, we can back-calculate the maximum tolerate
occurrence of this event, it is 8.032E-11 / 1E-9 = 8.032E-2 h-1, or 12.5h.
The hazard rate demonstrated by the odometry sub-system is going to be much higher than this figure,
therefore, the assumption is reasonable.

To fulfill the requirement of [SyAD-R26-SS41], we impose values to 𝑗𝑚𝑎𝑥 , 𝑡 and 𝜖𝑤𝑑 . We then derive a budget
for 𝜎𝑣_𝑠𝑙𝑖𝑝𝑠𝑙𝑖𝑑𝑒 .
𝜎𝑣_𝑠𝑙𝑖𝑝𝑠𝑙𝑖𝑑𝑒 is the amount of slip and slide that can be ignored without jeopardizing the requirement. Therefore,
any higher discrepancy on the speed must be detected by the odometry system. In other words, this is the minimum
resolution that should be fulfilled by the secondary speed sensor, and becomes a requirement for it.
The following requirements are allocated to the generic train interface of the iEVC:

Requirement

The maximum jerk value of the train is assumed to be less than 1m.s-3. [id:tsc-req-ievc-jerk-
max][p1][ns]

This requirement is created in order for the installation designer to confirm the assumption on the maxi-
mum jerk value for the specific type of train on which the iEVC is being installed.
A specific performance calculation has to be performed by the installation project team in case this as-
sumption is not verified.

Requirement

The uncertainty on the wheel diameter parameter shall be less than 1%, with a confidence interval
of at least 3 sigma (e.g. trained human error rate) [id:tsc-req-ievc-wheel-diameter-uncertainty][p1][s]

The following requirement is allocated to the odometry application:

Requirement

The odometry application shall accept speed samples with an estimated age of less than 50ms [id:tsc-
req-ievc-odometry-iodo-threshold][p1][s]

Based on this value, we can compute the 𝑠𝑖𝑔𝑚𝑎 values at 30kph and 500kph (values of 𝑣𝑚𝑎𝑥 specified by
[SyAD-R26-SS41]).

108 of 750 7.8. Performance requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Table 7.6: Calculation of slip-slide tolerance (all figures in KPH)

𝑣𝑚𝑎𝑥 𝜎𝑣 (target) 𝜎𝑣_𝑗𝑒𝑟𝑘 𝜎𝑣_𝑤𝑑 𝜎𝑣_𝑠𝑙𝑖𝑝𝑠𝑙𝑖𝑑𝑒
1 0.308 0.001 0.003 0.3
30 0.308 0.001 0.1 0.203
500 1.846 0.001 1.667 0.175

The resulting requirement for the speed sensors is therefore that their accuracy shall be less than 0.15KPH. This
requirement is covered by tsc-req-ievc-pg-accuracy[req] and tsc-req-ievc-secondarysensor-accuracy[req], that
requires it to be less than 0.15KPH.

7.8.2.3 Accuracy of distance known on-board

The relocation error has been computed before. Therefore, this section justifies compliance
Using the conventions used in the previous section, we get

𝜎𝑣 = 𝜎𝑣_𝑗𝑒𝑟𝑘 + 𝜎𝑣_𝑤𝑑 = 1/2.𝑗𝑚𝑎𝑥 .𝑡2 + 𝜖𝑤𝑑 .𝑣𝑘−1 ,

therefore, the distance 𝑑 of the train is estimated by taking the integral from the speed Kinematics model:

𝑣𝑘 = 𝑎𝑘−1 .𝑇𝑉 𝑀 _𝑐𝑦𝑐𝑙𝑒 + 𝑣𝑘−1 + 1/2.𝑗𝑚𝑎𝑥 .𝑇𝑉2 𝑀 _𝑐𝑦𝑐𝑙𝑒 + 𝜖𝑤𝑑 .𝑣𝑘−1

which will give the distance Kinematics model of

𝑑𝑘 = 1/2.𝑎𝑘−1 .𝑇𝑉2 𝑀 _𝑐𝑦𝑐𝑙𝑒 + 𝑣𝑘−1 .𝑇𝑉 𝑀 _𝑐𝑦𝑐𝑙𝑒 + 𝑑𝑘−1 + 1/4.𝑗𝑚𝑎𝑥 .𝑇𝑉3 𝑀 _𝑐𝑦𝑐𝑙𝑒 + 1/2.𝜖𝑤𝑑 .𝑣𝑘−1 .𝑇𝑉 𝑀 _𝑐𝑦𝑐𝑙𝑒

We can use this equation to estimate 𝜎𝑑 , simply by replacing 𝑇𝑉 𝑀 _𝑐𝑦𝑐𝑙𝑒 with 𝑡 and the fact that the covariance

𝜎𝑑 = 1/4.𝑗𝑚𝑎𝑥 .𝑡3 + 1/2.𝜖𝑤𝑑 .𝑣𝑘−1 .𝑡.

In the process of the Kalman filter, this value accumulates at each update of the estimates. Contrary to speed
estimates, there is no sensor input that can correct the value of the distance. Therefore, it grows linearly with
every re-estimation.
We can calculate the proportional distance error 𝜖𝑑 when the train travels a certain distance 𝐷𝑡𝑟𝑎𝑣𝑒𝑙 at constant
speed 𝑉𝑡𝑟𝑎𝑣𝑒𝑙 . This will allow us to estimate if our system, with the requirements already apportioned, stays within
the required bounds.
Let 𝑇𝑡𝑟𝑎𝑣𝑒𝑙 be the time of the travel. Then:

𝜖𝑑 = 𝜎𝑑 .𝑇𝑡𝑟𝑎𝑣𝑒𝑙 /𝑡/𝐷𝑡𝑟𝑎𝑣𝑒𝑙
𝜖𝑑 = 𝜎𝑑 /𝑉𝑡𝑟𝑎𝑣𝑒𝑙 .𝑡

This equation is an inverse function of the speed, therefore, it takes its higher value at low speed. Applying the
values to this equation, we can determine that 6.5𝜖𝑑 is equal to 4.7% (less than 5%) when 𝑉𝑡𝑟𝑎𝑣𝑒𝑙 is less than 1
KPH.
Therefore, the distance accuracy requirement from [SyAD-R26-SS41] is fulfilled when the speed of the train is
higher than 1KPH.
This implies that the odometry application should not update its estimates through when falling below that thresh-
old.
Requirement

The odometry application shall stop updating estimates using the EKF when the train speed falls
below 1KPH [id:tsc-req-ievc-odometry-app-train-at-stop][p1][ns]

7.8. Performance requirements 109 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.8.2.4 Safe clock drift

This requirement is apportioned between the Safe computer, as well as the iODO and iBTM-RX components.
The requirement for the Safe computer is created here:

Requirement

The Safe computer shall control that the drift on the clock used for timestamping and scheduling
purposes is lower or equal to 0.1% (or, said differently, that the clock drifts by less than 1ms per
second) [id:tsc-req-ievc-sc-clock-drift][p1][s]

This is a safety critical requirement according to SUBSET 041, but is also required for performance
purposes.

The requirements for iBTM-RX and iODO is tsc-req-ievc-snsr-prtcl-drift[req], and is an interface requirement of
[SyAD-R74-SIF-Sensor-interface].

7.8.3 Juridical recording performance

Requirement tsc-req-ievc-pqp-jru-62625-1-class-r1[req] implies that events should be recorded within 500ms.

This requirement is apportioned as follows:

Table 7.7: Apportionment of JRU recording performance

VM cycle time <=200ms It is the time required for the VM to tsc-req-ievc-
sample its safe inputs and build the sw-vm-cycle-
JRU events. time[req]
OBOM JRU pro- 200ms Time allocated to OBOM for its JRU treat- tsc-req-ievc-
cessing delay ments sw-obom-jru-
delay[req]
Delay on write to 100ms Time allocated to CPM to write the data tsc-req-ievc-
CPM physically on the CPM non-volatile mem- hw-cpm-write-
ory. delay[req]

The following requirements are created here:

Requirement

OBOM processing time for JRU logging shall be less than 200ms [id:tsc-req-ievc-sw-obom-jru-
delay][p1][ns]

Requirement

CPM write time for JRU shall be less than 100ms [id:tsc-req-ievc-hw-cpm-write-delay][p1][ns]

110 of 750 7.8. Performance requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.8.4 iEVC boot time

It is requested that the iEVC on-board system boot time shall be less than 90 seconds (see tsc-req-urs-evc-boot-
time[req]).
This total 90 seconds delay is allocated to the different iEVC components as described in Fig. 7.7.

Figure 7.7: iEVC boot time allocation

The following requirements are created accordingly:

Requirement

The CPM boot time from power-on until the moment the CPM data can be retrieved by the VM
shall not exceed 30s. [id:tsc-req-ievc-hw-cpm-boot-time][p1][ns]

Requirement

The safe computer nominal boot time shall not exceed 60s. [id:tsc-req-ievc-hw-sc-boot-time][p1][ns]

Boot time in specific cases in which additional auto tests are performed by the safe computer may exceed
this limit.

7.8. Performance requirements 111 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The time required by the Virtual Machine to start executing the applications shall not exceed 30s.
[id:tsc-req-ievc-hw-vm-start-app-execution-time][p1][ns]

Requirement

The Ethernet switch boot time shall not exceed 30s. [id:tsc-req-ievc-hw-ethernet-switch-boot-time][p1][ns]

Requirement

The Secondary sensor boot time shall not exceed 30s. [id:tsc-req-ievc-hw-sec-boot-time][p1][ns]

Requirement

The Sensor box components boot time shall not exceed 90s. [id:tsc-req-ievc-hw-sensor-box-boot-
time][p1][ns]

Within this 90 seconds delay, all the components of the Sensor box shall be ready to synchronize with the
Virtual Machine of the Computer box.

Requirement

The GSM-R modem boot time shall not exceed 30s. [id:tsc-req-ievc-hw-gsmr-boot-time][p1][ns]

Requirement

The DMI hardware boot time shall not exceed 30s. [id:tsc-req-ievc-hw-dmi-hw-boot-time][p1][ns]

Within this 30 seconds delay, the DMI hardware shall be ready to execute the DMI software and DMI
checker.

Requirement

The 4G modem boot time shall not exceed 90s. [id:tsc-req-ievc-hw-4g-boot-time][p1][ns]

7.8.5 Wiring simplification and robustness

Requirement tsc-req-urs-install-wiring-minimal-section[req] provides a minimal section for the wire, and requires
our design to limit the complexity and increase the robustness of the wiring inside the train.
The requirement on minimal section is transferred here to the installation design.

Requirement

Cable connections shall be performed with the use of cables of a section of minima 1 square mm to
ensure they are robust enough and easy to find on the market [id:tsc-req-ievc-perf-cable-section][p1][ns]

To achieve this, the iEVC design leverages as much as possible the usage of Ethernet. To support this design
choice, the protocols used take into account the asynchronous nature of this interface, for instance, using synchro-
nization messages.
In addition, the interface to sensors is simplified. For instance, the Euroantenna interface is reduced to 4 loops
(e.g. no coaxial cable).

112 of 750 7.8. Performance requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

All the iEVC cables shall use controlled impedance lines like coax or twisted pair. [id:tsc-req-ievc-
cables-controlled-impedance][p2][ns]

Requirement

All the iEVC cables shall comply with EN45545-2:2013+A1:2015, with a fire hazard level of 2 or
higher. [id:tsc-req-ievc-cables-fire][p1][s]

Requirement

All the iEVC cables shall be reclampable and/or easy to replace. [id:tsc-req-ievc-cables-
clampable][p2][ns]

Requirement

All the iEVC cables connectors shall have a mechanical life of at least 500 plugging / unplugging
cycles [id:tsc-req-ievc-cables-connectors-lifecycle][p2][ns]

Requirement

All iEVC cables and connectors shall resist pulling and being torn. [id:tsc-req-ievc-cables-connectors-
pulling][p2][ns]

Allocate
Allocation of the URS requirement to have routine maintenance tests that do not require any cable
plug/unplug cycle [allocate]
Data
• Requirement:
– tsc-req-urs-integrator-ievc-connectors-no-unplug-for-routine-maintenance[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: Interactive tests, iODO BITE module
• Justification: Interactive tests of the LRU components can be launched from the DMI Main-
tenance user interface. It does not require modification on the cabling except when testing
the odometry sensor inputs with the built-in pulse generator.

7.8. Performance requirements 113 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.9 Communication

This section describes the network communication of the iEVC system.

7.9.1 Network architecture

The network is composed of the following sub-networks:

• Sensor Box sub-network is dedicated to the communication between the Safe computer[ci] and the compo-
nents of the Sensor box[ci]. This sub-network includes the Sensor box ethernet switch[ci] that reduces the
number of network cables to connect to Ethernet switch[ci].
• Communication sub-network is dedicated to the communication between the Safe computer[ci] and modem
components (4G modem[ci], GSM-R modem[ci]).
• Peripherals sub-network is reserved to the communication between the Safe computer[ci] and other periph-
erals components (Crash protected memory[ci], DMI[ci]).
• IO board sub-network allows connecting an optional Computer box extension[ci] that contains additional
IO boards to extend the capacity of the Computer box[ci]. This sub-network is connected directly to the
Safe computer through dedicated ports. The technology used (physical link, protocol) depends on the Safe
computer[ci] design which is vendor-dependent.
• Tester laptop sub-network is dedicated to the communication between the tester laptop and the 4G mo-
dem[ci].
Fig. 7.8 illustrates the architecture.

Figure 7.8: iEVC network architecture

Sub-networks are isolated by the sub-mask mechanism and the Safe computer[ci] is connected to the Ethernet
switch[ci] by one cable and declares an IP address on each sub-network.

114 of 750 7.9. Communication

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.9.2 Network Principles

The network principles are :

• The network protocol is IP V4 ([SyAD-R41-RFC-791]) over Ethernet (IEC 802-3 -
[SyAD-R40-IEC-8802-3:2014]). Depending on the component, the transport protocol could be Transmis-
sion Control Protocol (TCP - RFC 793 - [SyAD-R42-RFC-793]) or User Data-gram Protocol (UDP - RFC
768 - [SyAD-R43-RFC-768]).
• All the addresses within sub-networks are statically allocated (tsc-req-network-static-ip-address[req]).
• Each sub-network use a 8-bit address bloc in the private address space according to [SyAD-R44-RFC-1918]
(Address Allocation for Private Internets).
• Modem components (4G modem[ci], GSM-R modem[ci]) ensure
– the protection against non authorized access
– the address translation and the routing of the traffic with outside world. To do so, in addition to static
address into communication sub-network, the modem holds the address dynamically allocated by the
telecommunication infrastructure.
• Connection through 4G modem[ci] with the outside world (including with the tester laptop) use Reverse
SSH Port Forwarding technique as follows:
– the Safe computer[ci] establishes an SSH connection with a trusted and secure computer with a public
IP address (named remote connection server), then a socket (named remote port) is assigned on the
remote side.
– Whenever a connection is made to the remote port, the connection is forwarded over the secure channel
to the specified port of a component of the local network. This particular connection is called a tunnel.
– It is possible to establish one tunnel per component that requires remote access.
– the Safe computer[ci] and the remote connection server are identified by a unique SSH key
• the Ethernet switch[ci] allows port mirroring to monitor activities on the network. The target of the mirror-
ing could be a computer connected to the Ethernet switch[ci]. The same SSH Port Forwarding technique is
used for 4G connection.
• The components are allocated between the Ethernet switch[ci] and the Sensor box ethernet switch[ci] ac-
cording to the table Ethernet network allocation in section Ethernet Switch.

Note: It will only be possible to use such telematics interface in a future version of the iEVC System.

7.9.3 Requirements

Requirement

Each component connected to the communication network shall have a static IP address [id:tsc-req-
network-static-ip-address][p2][ns]

Requirement

Each Developed component shall have a MAC address with an Organizationally Unique Identifier
allocated to TSC by IEEE [id:tsc-req-mac-address-developed-component][p2][ns]

7.9. Communication 115 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.9.4 Network addressing plan

7.9.4.1 MAC Address plan

Each component have a media access control address (MAC address) allocated by their supplier. For developed
components the MAC addresses are allocated according the Table 7.8.

Table 7.8: Mac address plan for developed component.

Box Component, MAC Address
Sensor Box 1 iBTM-TX <TSC Prefix>:01
Sensor Box 1 iBTM-RX 1 <TSC Prefix>:02
Sensor Box 1 iBTM-RX 2 <TSC Prefix>:03
Sensor Box 1 iODO 1 <TSC Prefix>:11
Sensor Box 1 iODO 2 <TSC Prefix>:12
Sensor Box 1 iODO-BITE <TSC Prefix>:20
Sensor Box 2 iBTM-TX <TSC Prefix>:05
Sensor Box 2 iBTM-RX 1 <TSC Prefix>:06
Sensor Box 2 iBTM-RX 2 <TSC Prefix>:07

Note: Organizationally Unique Identifier allocated to TSC (<TSC Prefix> in the table) is not yet defined.

7.9.4.2 IP address plan

The table IP address plan presents the IP address used for each iEVC.

Table 7.9: IP address plan

Sub-network Network prefix Component IP address
Communication 192.168.100/24 4G modem 192.168.100.1
Communication 192.168.100/24 GSM-R Modem 1 192.168.100.11
Communication 192.168.100/24 GSM-R Modem 2 192.168.100.12
Communication 192.168.100/24 power supply 1 192.168.100.31
Communication 192.168.100/24 power supply 2 192.168.100.32
Communication 192.168.100/24 Safe computer 192.168.100.10
Tester laptop 192.168.103/24 Tester laptop 192.168.103.1
Peripheral 192.168.3/24 DMI 1 (Cab A main) 192.168.3.1
Peripheral 192.168.3/24 DMI 3 (Cab A backup) 192.168.3.2
Peripheral 192.168.3/24 DMI 2 (Cab B main) 192.168.3.11
Peripheral 192.168.3/24 DMI 4 (Cab B backup) 192.168.3.12
Peripheral 192.168.3/24 Crash Protected Memory 192.168.3.21
Peripheral 192.168.3/24 Telemetry 192.168.3.40
Peripheral 192.168.3/24 Spare 1 (for Train interface) 192.168.3.41
Peripheral 192.168.3/24 spare 2 (provision for TSI- 192.168.3.42
CCS 2022)
Peripheral 192.168.3/24 Safe computer 192.168.3.10
Safe Computer 192.168.1/24 Safe Computer 192.168.1/24
Computer Box Extension 192.168.2/24 IO Boards sub-network 192.168.2/24
Sensor box 1 192.168.10/24 iBTM-TX 192.168.10.1
Sensor box 1 192.168.10/24 iBTM-RX 1 192.168.10.11
Sensor box 1 192.168.10/24 iBTM-RX 2 192.168.10.12
Sensor box 1 192.168.10/24 iODO 1 192.168.10.21
Sensor box 1 192.168.10/24 iODO 2 192.168.10.22
Sensor box 1 192.168.10/24 iODO-BITE 192.168.10.30
continues on next page

116 of 750 7.9. Communication

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Table 7.9 – continued from previous page

Sub-network Network prefix Component IP address
Sensor box 1 192.168.10/24 power supply 1 192.168.10.31
Sensor box 1 192.168.10/24 power supply 2 192.168.10.32
Sensor box 1 192.168.10/24 Sensor Box switch 192.168.10.100
Sensor box 1 192.168.10/24 Safe computer 192.168.10.200
Sensor box 2 192.168.20/24 iBTM-TX 192.168.20.1
Sensor box 2 192.168.20/24 iBTM-RX 1 192.168.20.11
Sensor box 2 192.168.20/24 iBTM-RX 2 192.168.20.12
Sensor box 2 192.168.20/24 power supply 1 192.168.20.31
Sensor box 2 192.168.20/24 power supply 2 192.168.20.32
Sensor box 2 192.168.20/24 Sensor Box switch 192.168.20.100
Sensor box 2 192.168.20/24 Safe computer 192.168.20.200

7.9.5 Capacity calculations

The capacity of the network is estimated as follows:

• the size of a cyclic messages is estimated in worst case,
• a provision of 10% of the previous calculation is taken for message send on event,

Table 7.10: Apportionment of network Capacity

Component network usage max number of total (Mbits/s)
(Mbits/s) component
Sensor box[ci] 2.3 2 4.6
DMI[ci] 0.25 4 1
Crash protected memory[ci] 1 1 1
Euroradio 1 1 1
telemetry, tester laptop and software up- 1 1 1
date
Safe computer[ci] 8.6

7.9. Communication 117 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.9.5.1 Network usage for the Sensor box

Table 7.11: Network usage Sensor box

message name Size cycle Bandwidth justification
(bytes) (ms) (bits/seconds)
iODO Synchronization mes- 266 50 170240 bidirectional between 2 IODO
sage[functional variable][VM boards and Virtual machine[ci]
- iODO interface]
iODO sample mes- 362 10 579200 from 2 IODO boards to Virtual ma-
sage[functional variable][VM chine[ci]
- iODO interface]
iODO status mes- 286 50 91520 from 2 IODO boards to Virtual ma-
sage[functional variable][VM chine[ci]
- iODO interface]
iBTM synchronization mes- 286 50 274560 bidirectional between 2 RX board +
sage[functional variable][VM 1 TX board and Virtual machine[ci]
- iBTM-RX interface][VM -
iBTM-TX interface]
Balise or loop detection mes- 926 100 148160 from 2 RX board and 10 balise per
sage[functional variable][VM seconds
- iBTM-RX interface][VM -
Applications interface]
Up-link telegram mes- 406 10 649600 from 2 RX board and ibtm over a
sage[functional variable][VM balise
- iBTM-RX interface][VM -
Applications interface]
iBTM-TX status mes- 474 50 75840 from 1 TX board
sage[functional variable][VM
- iBTM-TX interface][VM -
Applications interface]
iBTM-RX status mes- 228 50 72960 from 2 RX board
sage[functional variable][VM
- iBTM-RX interface]
Provision for message send on N/A N/A 206208 10% of cyclic message exchanged
event
Total Sensor box 2268288

The network capacity needed for one Sensor box is : 2.3 Mbits/s.

7.9.5.2 Network usage reserved for Euroradio GSM-R modem

The maximum capacity of one GSM-R modem[ci] is 296 Kbits/s (177.6 Kbits/s in download and 118.4 Kbits/s
upload).
In provision for future upgrade, 1 Mbits/s is reserved for Euroradio

118 of 750 7.9. Communication

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

7.9.5.3 Network usage reserved for DMI

1 Mbits/s is reserved for DMI (250 Kbits/s per screen)

7.9.5.4 Network usage for Crash protected memory

1 Mbits/s is reserved for Crash protected memory[ci]

7.9.5.5 Network usage for telemetry, tester laptop and software update

1 Mbits/s is reserved for telemetry, tester laptop data and software update. A software package of 20 Mega bytes
will take about 3 minutes to be uploaded. It is noteworthy that according to tsc-req-urs-evc-sw-update-time[req]
we have 1 hour time to upload.

7.9.5.6 Network usage for the Safe computer

The Safe computer shall support Communication with all the devices on the network.

7.9. Communication 119 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
CHAPTER

EIGHT

SYSTEM FUNCTIONAL ARCHITECTURE

This section presents the logical functions of the iEVC system. These functions are decomposed progressively up
to the point where they can be allocated to individual components of the architecture. The logical functions of the
IEVC system are obtained by the analysis and decomposition of the functions defined in [SyAD-R1-SD].
Once the function can be assigned to a given component, further functional decomposition is deferred to the
corresponding chapter in Developed components and Outsourced Generic Components.

8.1 [IEVC.F1] Develop IEVC applications [function]

Data
• Definition: The iEVC system is built upon the concept of model-based *applications* that are exe-
cuted directly by the system. The system is able to run multiple applications side by side, ensuring
that safety-related applications are not compromised.
• Allocated to:
– iEVC[ci]
• Sub functions:
– [IEVC.F1.05] Execute applications[function]
– [IEVC.F1.07] Support application tests[function]
– [IEVC.F1.15] Record execution[function]
– [IEVC.F1.26] Support Configuration Data Preparation and Verification[function]
– [IEVC.F1.20] Manage deployment authorizations[function]

Fig. 8.1 provides an overview of the structure of function F1 with the associated certification kit based on the
component to which the function is allocated.

120 of 750 8. System functional architecture

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.1: Functional structure of F1 with associated certification kit

8.1.1 [IEVC.F1.05] Execute applications [function]

Data
• Definition: The iEVC on-board subsystem executes model-based applications.
• Allocated to:
– iEVC[ci]
• Sil: 4
• Sub functions:
– [IEVC.F1.05.17] Provide VM Config files[function]
– [IEVC.F1.05.03] Upload application package and certificate to VM[function]
– [IEVC.F1.05.07] Determine initialization status[function]
– [IEVC.F1.05.15] Read VM config files[function]
– [IEVC.F1.05.08] Load application package files and certificate[function]
– [IEVC.F1.05.06] Configure applications[function]
– [IEVC.F1.05.10] Verify Authorization[function]
– [IEVC.F1.05.14] Execute an evaluation cycle[function]

The execution of applications is supported by the following components:

• On-Board Operation and Maintenance software: uploads the application package data to the virtual ma-
chine at start-up. This data is composed of the application themselves, but also the configuration applica-
tions and a descriptor file of the package. It also uploads the authorization certificate.
• Virtual Machine: executes the application logic. The VM works in controlled sequential evaluation rounds,
during which incoming messages are consumed, application state re-computed, and outgoing messages
produced; The VM is configured at start-up using its VM configuration file provided by the Safe Computer
(namely by its Operating System);
• TSC Net: provides input and output messages to the VM from the outside world;
• Crash Protected Memory: hosts the application package files and the authorization certificate;
Applications also interact with the outside world using driver softwares inside the VM. These drivers interface
applications with components or physical devices that require a specific protocol. The following drivers are

8.1. [IEVC.F1] Develop IEVC applications [function] 121 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

defined:
• iODO Driver: provides application access to odometry samples from the speed sensors sampled by iODO
module;
• iODO BITE driver: provides application access to the iODO BITE to execute built-in test of the odom-
etry function or to exchange messages on a V1/V2 serial interface used by a Subset-085 or Subset-103
certification laboratory;
• iBTM driver: provides application access to the components in charge of interfacing the wayside balises
and loops (e.g. iBTM-RX module, iBTM-TX module);
• IO driver: provides application access to digital inputs and outputs and to numeric data bus in the train
interface of the iEVC on-board subsystem;
• DMI driver: provides application access to the DMI;
• Euroradio Safe Functional Module driver: provides application access to the components in charge of
interfacing the Euroradio.
The VM also provides the iEVC application with specific information such as the execution time, the date, the test
mode, etc. . . The exhaustive list is described in [SyAD-R79-BK-APP-ARCHI], [SyAD-R80-SK-APP-ARCHI]
and [SyAD-R81-ETCSK-APP-ARCHI]
An overview of the functional architecture is provided in Fig. 8.2. More details are available in each component
description.

Figure 8.2: iEVC architecture for function ‘Execute applications’ (F1.05)

Note: TSC Net does not appear in Fig. 8.2. It is a medium for communication between logical components.

122 of 750 8.1. [IEVC.F1] Develop IEVC applications [function]

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

8.1.2 [IEVC.F1.07] Support application tests [function]

Data
• Definition: The iEVC on-board subsystem is able to control test sequences in its Virtual Machine
using a debug interface.
• Allocated to:
– Virtual machine[ci]
• Sil: 4
• Sub functions:
– [IEVC.F1.07.06] Determine Test mode[function]
– [IEVC.F1.07.05] Implement debug protocol[function]

When in a certain test mode, the Virtual Machine provides the necessary mechanism for a debugging tool to:
read and write all variable values and memory areas, stop and resume execution of the VM, perform step-by-step
execution and compute code coverage during a test.
This function is completely allocated to the Virtual machine[ci].

8.1.3 [IEVC.F1.15] Record execution [function]

Data
• Definition: The iEVC on-board subsystem records its execution while operating. This operational
data can be used to replay a specific recorded sequence of events.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Sub functions:
– [IEVC.F1.15.01] Record VM execution[function]

• Virtual Machine: during execution, produces records and sends them to OBOM. These records contain
sufficient information for an exact replay of the VM behavior.
• On-Board Operation and Maintenance software: records the information received from the VM.
• Crash Protected Memory: hosts the record files.
An overview of the functional architecture is provided in Fig. 8.3. More details are available in the On-Board
Operation and Maintenance software component description.

8.1. [IEVC.F1] Develop IEVC applications [function] 123 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.3: iEVC architecture for function ‘Record execution’ (F1.15)

8.1.4 [IEVC.F1.26] Support Configuration Data Preparation and Verification

[function]

Data
• Definition: The SIDE Configurator produces the iEVC configuration data files for a given installa-
tion project and includes a module to de-compile these configuration files.
• Allocated to:
– SIDE Configurator[ci]
• Sil: basic
• Associated interface:
– SIDE Configurator User Interface[ci]
• Sub functions:
– [IEVC.F1.26.01] Extract configuration parameters from the generic applications[function]
– [IEVC.F1.26.02] Provide tabular input interface[function]
– [IEVC.F1.26.03] Generate the configuration data files[function]
– [IEVC.F1.26.04] Extract configuration data values from files[function]

This function is completely allocated to the SIDE Configurator[ci]. An overview of the functional architecture is
provided in Fig. 8.4. More details are available in the SIDE Configurator component description and in section
iEVC Configuration.

124 of 750 8.1. [IEVC.F1] Develop IEVC applications [function]

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.4: iEVC architecture for function ‘Support Configuration Data Preparation and Verification’ (F1.26)

8.1.5 [IEVC.F1.20] Manage deployment authorizations [function]

Data
• Definition: This SIDE authorizer delivers certificates to the iEVC on-board to allow the execution
of a specific version of the iEVC application package. This package contains the iEVC applications
and iEVC configuration data files.
• Allocated to:
– SIDE Authorizer[ci]
• Sil: basic
• Associated interface:
– SIDE Authorizer User Interface[ci]
• Sub functions:
– [IEVC.F1.20.01] Verify the application package content[function]
– [IEVC.F1.20.02] Compute application package certificate[function]

This function is completely allocated to the SIDE Authorizer[ci]. An overview of the functional architecture is
provided in Fig. 8.5. More details are available in the SIDE Authorizer component description.

8.1. [IEVC.F1] Develop IEVC applications [function] 125 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.5: iEVC architecture for function ‘Manage deployment authorizations’ (F1.20)

8.2 [IEVC.F3] Run trains under ETCS control [function]

Data
• Definition: Regroups the functions used in order to run trains under ETCS control.
• Allocated to:
– iEVC[ci]
• Associated interface:
– DMI ETCS User Interface[ci]
– DMI Maintenance User Interface[ci]
– DMI Fault User Interface[ci]
– Eurobalise air-gap[ci]
– Euroradio air-gap[ci]
• Sub functions:
– [IEVC.F3.02] Execute ETCS functions[function]
– [IEVC.F3.03] Support ETCS CI certification process[function]

Fig. 8.6 provides an overview of the structure of function F3 with the associated certification kit based on the
component to which the function is allocated.

126 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.6: Functional structure of F3 with associated certification kit

8.2.1 [IEVC.F3.02] Execute ETCS functions [function]

Data
• Definition: The iEVC On-board subsystem uses model-based applications to execute the ETCS
functions and to manage the associated interfaces. These functions and interfaces are de-
scribed in Subset 026, Subset 027, Subset 034, Subset 035, Subset 036, Subset 037 and
ERA_ERTMS_015560.
• Allocated to:
– iEVC[ci]
• Sub functions:
– [IEVC.F3.02.01] Manage Data entry[function]
– [IEVC.F3.02.02] Select Supervision mode on the basis of information from track-
side[function]
– [IEVC.F3.02.04] Compute the dynamic speed profile[function]
– [IEVC.F3.02.05] Supervise the dynamic speed profile[function]
– [IEVC.F3.02.06] Provide the intervention function[function]
– [IEVC.F3.02.12] Manage equipment health and degraded modes[function]
– [IEVC.F3.02.10] Communicate with the STM[function]
– [IEVC.F3.02.03] Execute odometry functions[function]

8.2. [IEVC.F3] Run trains under ETCS control [function] 127 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– [IEVC.F3.02.07] Read Eurobalise information[function]

– [IEVC.F3.02.08] Communicate through radio communication[function]
– [IEVC.F3.02.09] Communicate with the driver[function]
– [IEVC.F3.02.13] Support data recording for regulatory purposes[function]
– [IEVC.F3.02.14] Manage train interface[function]
– [IEVC.F3.02.15] Read Euroloop information[function]

The following sub-functions are allocated solely to the Subset 026 application[ci]:
• [IEVC.F3.02.01] Manage Data entry[function]
• [IEVC.F3.02.02] Select Supervision mode on the basis of information from trackside[function]
• [IEVC.F3.02.04] Compute the dynamic speed profile[function]
• [IEVC.F3.02.05] Supervise the dynamic speed profile[function]
• [IEVC.F3.02.06] Provide the intervention function[function]
• [IEVC.F3.02.12] Manage equipment health and degraded modes[function]
• [IEVC.F3.02.10] Communicate with the STM[function]
Other sub-functions have a more complex functional architecture as illustrated in their description below.

Figure 8.7: Sub-functions allocated only to Subset 026 application

128 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

8.2.1.1 [IEVC.F3.02.01] Manage Data entry [function]

Data
• Definition: The Subset 026 application allows configuring the train data that needs be entered by
the driver on the DMI. The entry method and default value selection are also configurable.
• Allocated to:
– Subset 026 application[ci]
• Sil: 4
• Associated interface:
– DMI ETCS User Interface[ci]

This function exchanges variables with the TIU application. These variables are listed in
[SyAD-R73-SIF-Train-Generic].
This function is fully allocated to the Subset 026 application.

8.2.1.2 [IEVC.F3.02.02] Select Supervision mode on the basis of information from trackside
[function]

Data
• Definition: This functions consists in selecting the ETCS mode based on the trackside information
and driver inputs. This function is realized by the Subset 026 application.
• Allocated to:
– Subset 026 application[ci]
• Input:
– Emergency Brake test report[functional variable]
• Output:
– Emergency brake test allowed[functional variable]
• Sil: 4
• Associated interface:
– DMI ETCS User Interface[ci]
– Eurobalise air-gap[ci]
– Euroradio air-gap[ci]

This function exchanges variables with the TIU application. These variables are listed in
[SyAD-R73-SIF-Train-Generic].
This function is fully allocated to the Subset 026 application.

8.2. [IEVC.F3] Run trains under ETCS control [function] 129 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

8.2.1.3 [IEVC.F3.02.04] Compute the dynamic speed profile [function]

Data
• Definition: The Subset 026 Application is in charge of the computation of the Most Restrictive
Speed Profile that is constructed based on all trackside related speed restrictions and on the maxi-
mum train speed.
• Allocated to:
– Subset 026 application[ci]
• Sil: 4

This function exchanges variables with the TIU application. These variables are listed in
[SyAD-R73-SIF-Train-Generic].
This function is fully allocated to the Subset 026 application.

8.2.1.4 [IEVC.F3.02.05] Supervise the dynamic speed profile [function]

Data
• Definition: The speed and distance monitoring is the supervision of the speed of the train versus its
position, in order to ensure that the train remains within the computed dynamic speed profile.
• Allocated to:
– Subset 026 application[ci]
• Sil: 4

This function exchanges variables with the TIU application. These variables are listed in
[SyAD-R73-SIF-Train-Generic].
This function is fully allocated to the Subset 026 application.

8.2.1.5 [IEVC.F3.02.06] Provide the intervention function [function]

Data
• Definition: This function allows providing the emergency and service brake commands. This func-
tion is realized by the Subset 026 application. The commands are provided to the TIU application
that controls the physical train lines associated to these commands.
• Allocated to:
– Subset 026 application[ci]
• Sil: 4
• Associated interface:
– iEVC - Train generic interface[ci]

This function exchanges variables with the TIU application. These variables are listed in
[SyAD-R73-SIF-Train-Generic].
This function is fully allocated to the Subset 026 application.

130 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

8.2.1.6 [IEVC.F3.02.12] Manage equipment health and degraded modes [function]

Data
• Definition: This function includes: initializing the on-board ETCS functionality, providing degraded
ETCS mode support and isolating the on-board ETCS functionality. These features are those de-
scribed in Subset 026.
• Allocated to:
– Subset 026 application[ci]
• Sil: 4

This function is fully allocated to the Subset 026 application.

8.2.1.7 [IEVC.F3.02.10] Communicate with the STM [function]

Data
• Definition: This function allows the exchange of information with a STM system using a standard-
ized interface. This interface is specified in Subset 035.
• Allocated to:
– Subset 026 application[ci]
• Sil: basic

This function exchanges variables with the TIU application. These variables are listed in
[SyAD-R73-SIF-Train-Generic].

Note: In the iEVC system architecture, the STM interface is managed as a functional interface between iEVC
applications inside the Safe computer, not as a physical interface.

This function is fully allocated to the Subset 026 application.

Class B applications that interface with the Subset 026 application using this STM functional interface are not in
the scope of this specification. Fig. 8.8 provides an overview of the STM interface that a class B application may
use. Additional information is provided in the section National system interface.

8.2. [IEVC.F3] Run trains under ETCS control [function] 131 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.8: STM interface in the iEVC architecture

8.2.1.8 [IEVC.F3.02.03] Execute odometry functions [function]

Data
• Definition: The odometry functions end-goal is to provide to iEVC applications a safe estimate
of the train displacement and speed. The distance estimate is given as an abstract measure of a
"distance" since the initialization of the iEVC.
• Allocated to:
– iEVC[ci]
• Sil: 4
• Sub functions:
– [IEVC.F3.02.03.09] Reset confidence interval[function]
– [IEVC.F3.02.03.08] Manage sensor fusion, selection and conditioning[function]
– [IEVC.F3.02.03.10] Estimate train odometry (EKF)[function]
– [IEVC.F3.02.03.15] Validate odometry parameters[function]
– [IEVC.F3.02.03.11] Extract confidence interval reset information from the linking informa-
tion[function]
– [IEVC.F3.02.03.12] Manage information from odometry application[function]
– [IEVC.F3.02.03.03] Sample PG[function]
– [IEVC.F3.02.03.04] Sample secondary sensor[function]
– [IEVC.F3.02.03.05] Manage serial link from secondary sensor[function]
– [IEVC.F3.02.03.06] Provide a sample measure and sensor status of the Odometry sen-
sors[function]
– [IEVC.F3.02.03.16] Configure iODO network connection[function]
– [IEVC.F3.02.03.07] Manage iODO synchronization[function]
– [IEVC.F3.02.03.13] Simulate sensor signal[function]
– [IEVC.F3.02.03.14] Manage iODO BITE[function]

132 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– [IEVC.F3.02.03.01] Produce pulse signal from wheel rotation[function]

– [IEVC.F3.02.03.02] Produce secondary pulse proportional to speed and serial link[function]

The iEVC odometry relies on multi-sensor data fusion to achieve the required level of safety on this function. The
conceptual framework is that of an Extended Kalman Filter (EKF), that processes measurements of the following
sensors:
• Wheel pulse generators
The Wheel pulse generators[ci] are the primary mean of determining the train speed. It is biased by the
diameter of the wheel, that must therefore be known by the EKF.
• Secondary odometry sensor
The Secondary odometry sensor[ci] is meant to compensate for the failure modes of a PG.

Note: This sensor is a Corrail optical sensor. It has been selected based on [SyAD-R76-ODO-STAT].

Each measure from the previous two sensors comes with an uncertainty. One of the strength of EKF is that it can
model Gaussian uncertainties and manage the accumulation of this uncertainty on the successive measures. In
other words, the estimations returned by the filter will be accompanied with an ever growing uncertainty.
The only way to collapse this uncertainty is to fuse in the computations a third source that provides a direct
measure of the position and can be used to “reset” the uncertainty accumulated over time through indirect speed
sensors.
Thanks to the concept of ‘Linking’ in ETCS, it is possible to know with known precision the distance between
two successive groups of Eurobalise. The iEVC can use this information to provide the filter with an intermittent,
safe and accurate measure of the location.
The fusion of the measures provided by these sensors is supported by the following components:
• The Odometry Application is in charge of performing the EKF computations and raising alarms from any
detected faults during the odometry information computation.
• The iODO module is in charge of acquiring the measures from the sensors. In order to achieve the required
level of safety, the iODO shall ensure that no undetected single failure on its acquisition chain can result in
wrong inputs to the Odometry Application.
• The management of the linking information is part of the Subset 026 Application. It processes the infor-
mation in order to provide a confidence interval reset order to the Odometry Application. The Subset 026
Application provides a safe reaction in case of critical failure of the odometry function based on the alarm
information provided by the Odometry Application. The Subset 026 Application also provides information
about the active Euroantenna. This information is used by the Odometry application in case two Euroan-
tenna are installed on-board (one for each cab). In that case, the Odometry application will shift the relative
positioning information by the distance between the two Euroantenna each time there is a change of active
Euroantenna.
This functional architecture is illustrated in Fig. 8.9.

8.2. [IEVC.F3] Run trains under ETCS control [function] 133 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.9: Functional architecture of the iEVC odometry

Note: The sub-functions IEVC.F3.02.03.13, IEVC.F3.02.03.14 and IEVC.F3.02.03.15 are illustrated in Fig.
11.9, Fig. 11.15 and Fig. 11.74.

Note: The sub-function IEVC.F3.02.03.16 are described in section Function in iODO module.

134 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

8.2.1.9 [IEVC.F3.02.07] Read Eurobalise information [function]

Data
• Definition: This function allows the ETCS On-board subsystem to read information from the Eu-
robalise air-gap. This function is specified in Subset 036.
• Allocated to:
– iEVC[ci]
• Sil: 4
• Associated interface:
– Eurobalise air-gap[ci]
• Sub functions:
– [IEVC.F3.02.07.09] Verify, filter and decode Eurobalise and Euroloop telegram[function]
– [IEVC.F3.02.07.10] Manage Tele-powering mode[function]
– [IEVC.F3.02.07.11] Manage iBTM alarms[function]
– [IEVC.F3.02.07.13] Manage iBTM synchronization[function]
– [IEVC.F3.02.07.12] Manage ETCS telegram[function]
– [IEVC.F3.02.07.01] Generate Tele-power magnetic field[function]
– [IEVC.F3.02.07.02] Pick-up Up-link magnetic field[function]
– [IEVC.F3.02.07.03] Generate test Up-link magnetic field[function]
– [IEVC.F3.02.07.15] Provide the installed cabin associated to the Euroantenna[function]
– [IEVC.F3.02.07.07] Detect Up-link signal[function]
– [IEVC.F3.02.07.08] Demodulate the balise signal[function]
– [IEVC.F3.02.07.16] Configure iBTM-RX network connection[function]
– [IEVC.F3.02.07.04] Generate Tele-powering signal[function]
– [IEVC.F3.02.07.05] Read back Tele-powering signal[function]
– [IEVC.F3.02.07.06] Generate test signal[function]
– [IEVC.F3.02.07.17] Configure iBTM-TX network connection[function]

This function is realized by the iBTM. iBTM is the name of the iEVC On-board balise transmission system.
The main components involved in this function are:
• the Euroantenna that contains the loops that produce the Tele-powering magnetic field and that picks up
the balise Up-link magnetic field. It also contains a specific ‘iBTM test’ loop that allows a readback of the
Tele-powering and a test of the 2 RX reception channels. It is installed under the train.
• the iBTM-TX module that generates the Tele-powering signal that feeds the Euroantenna. It reads back the
induced Tele-powering signal from the test loop. It also produces the ‘iBTM test’ signal. The iBTM-TX is
located inside the Sensor box[ci].
• the iBTM-RX module that detects the balise Up-link signal and demodulates it to extract the Up-link telegram
information. There are 2 redundant iBTM-RX components, both located inside the Sensor box[ci].
• the iBTM driver synchronizes the communication with the iBTM-RX and iBTM-TX. The iBTM driver is
in the Virtual machine[ci] of the Safe computer[ci].
• the iBTM application manages the Tele-powering mode and processes the Eurobalise Up-link information
received from the 2 iBTM-RX components.

8.2. [IEVC.F3] Run trains under ETCS control [function] 135 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• the Odometry Application provides the information needed by the iBTM application to associate a location
to each balise contact.
• the ETCS messages application performs the transformation of packet message received from the iBTM
application[ci] into data structure that contains application variables as expected by the Subset 026 appli-
cation[ci]
• the Subset 026 Application consumes the unpacked data for signalling purpose.
The Euroantenna includes 2 independent reception loops. Each reception loop is connected to one iBTM-RX
module. The Euroantenna includes 1 loop for the Tele-powering signal and 1 test loop. These 2 loops are fed by
the iBTM-TX module component. The test loop is used to transmit an emulated Eurobalise signal that is picked up
by the 2 RX chains. The demodulated test telegram is verified by the iBTM application. The test loop is also used
to read back the Tele-powering signal.
Each iBTM-RX module includes 5 different and independent demodulation circuits:
• Eurobalise demodulator A
• Eurobalise demodulator B (with diversified circuits from demodulator A)
• KER demodulator A
• KER demodulator B
• Euroloop demodulator (refer to [IEVC.F3.02.15] Read Euroloop information[function])
All the demodulators are fed with the balise Up-link signal and all can report the demodulated telegram, if any, to
the iBTM application.
Each of the two iBTM-RX component detects the presence of a balise Up-link signal using a signal level threshold.
Once a balise contact has been detected the Up-link signal is demodulated and decoded by the demodulators.
When processing the Eurobalise information coming from the iBTM-RX module components, the iBTM applica-
tion will use demodulator A information from one component and demodulator B information from the other.

Note: the same principle applies to KER class B application when processing the demodulated information from
KER demodulators A and B.

The iBTM application verifies, decodes the Eurobalise telegram and associates a reference location to the balise
based on the odometry information provided by the Odometry Application. The resulting information is provided
to the Subset 026 Application through the ETCS messages application that decodes the telegram into packets in
ETCS language.
This architecture aims at avoiding that any single failure remains unnoticed and/or results in a hazardous situation
(tsc-req-subset-036-4-4-6-2-1-1[req]). It also aims at ensuring that the iBTM is able to correctly detect balises
(tsc-req-subset-036-6-2-2-1-1[req]).

Allocate
Allocation of Subset 036 requirement covered by the iBTM architecture [allocate]

136 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-subset-036-4-4-6-2-1-1[req]
– tsc-req-subset-036-6-2-2-1-1[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: System functional architecture
• Justification: This architecture aims at avoiding that any single failure remains unnoticed
and/or results in a hazardous situation. It also aims at ensuring that the iBTM is able to
correctly detect balises.

The iBTM logical architecture for Eurobalise transmission is represented in figure Fig. 8.10.

8.2. [IEVC.F3] Run trains under ETCS control [function] 137 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.10: Representation of iBTM logical architecture for Eurobalise transmission

Note: In the physical architecture 2 iBTM-RX components are detecting balise contact in parallel.

Note: The sub-functions IEVC.F3.02.07.16 and IEVC.F3.02.07.17 are illustrated in Fig. 11.4 and Fig. 11.3.

The Subset 036 introduces the On-board balise transmission system as composed of:
• the antenna unit
• the BTM function
• the Interface adapter

138 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• the ERTMS/ETCS kernel

Figure 8.11: Subset 036 definition of the On-board balise transmission system

The equivalence with the iBTM architecture is represented in figure Fig. 8.12.

Figure 8.12: iBTM architecture against Subset 036 definition of the On-board balise transmission system

The iBTM architecture includes the V1 and V2 interfaces that are specifically used to interface a Subset 085 labora-
tory; the associated iEVC function is [IEVC.F3.03.03] Support test according to Subset 085 (BTM tests)[function].
These interfaces are described in annex E of Subset 085. They are intended to be used only when the iEVC On-

8.2. [IEVC.F3] Run trains under ETCS control [function] 139 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

board subsystem is in test mode. These V1 and V2 interfaces use serial links located in the iODO BITE module
component. The logical architecture of the iBTM including the V1 and V2 interfaces is represented in Fig. 8.13.

Figure 8.13: iBTM architecture including V1 and V2 interfaces

The iBTM does not implement any maintenance data exchange in the interface ‘A’ with the Eurobalises. There
will be no handshaking neither as required by Subset 036 §4.2.2.5.
The iBTM allows the iEVC On-board subsystem to read Eurobalise as well as KER balises of type Ebicab 700/900,
KVB and RSDD (tsc-req-subset-036-4-2-6-2[req]). Each iBTM-RX module includes 2 KER demodulators on each
iBTM-RX component. Each of them demodulates in Amplitude Shift Key (ASK) the KER balise Up-link signal.
The KER Class B application[ci] may use the demodulated telegram coming from KER demodulator A on the
first iBTM-RX board and from KER demodulator B on the second iBTM-RX board.
The logical architecture for KER balise transmission is represented in Fig. 8.14

140 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.14: iBTM architecture for KER balise transmission

Note: The balise detection function is identical for Eurobalise and KER balise.

Allocate
Allocation of Subset 036 requirement for compatibility with existing railway systems. [allocate]
Data
• Requirement:
– tsc-req-subset-036-4-2-6-2[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: System functional architecture
• Justification: The iBTM allows the iEVC On-board subsystem to read Eurobalise as well as
KER balises of type Ebicab 700/900, KVB and RSDD in addition to Eurobalise.

The iEVC can be operated using 2 Euroantenna (1 per cab or desk). This is useful for long locomotives using a

8.2. [IEVC.F3] Run trains under ETCS control [function] 141 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

centralized iEVC On-board for both cabins or desks. In this case it may be impossible to respect the installation
constraint from Subset 040 (see tsc-req-ievc-euroantenna-ss40-installation[req]). When this happens, 2 Sensor
box hardware must be used. They are connected to a same Safe computer. Each Sensor box hardware correspond
to one cabin or desk and is connected to its own Euroantenna. The iBTM components (iBTM-RX and iBTM-TX)
are able to detect their associated installed cabin through the type of Euroantenna cable used for the installation
(see [SyAD-R55-SIF-iBTM-Euroantenna]).

Figure 8.15: iEVC On-board with 2 Sensor boxes

Allocate
Allocation of the URS requirement that requires that the iEVC shall communicate with trackside
Control-Command and Signalling subsystems by reading Eurobalise data in compliance with Subset
036 [allocate]
Data
• Requirement:
– tsc-req-urs-ievc-read-eurobalise-information[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: System functional architecture
• Justification: The system functional architecture for functions "Read Eurobalise informa-
tion" and "Read Euroloop information" covers the requirement to be able to communicate
with ETCS trackside devices.

142 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

8.2.1.10 [IEVC.F3.02.08] Communicate through radio communication [function]

Data
• Definition: This function allows the iEVC On-board subsystem to exchange information with track-
side equipment over the Euroradio air-gap. This function is specified in Subset 037.
• Allocated to:
– iEVC[ci]
• Sil: 4
• Associated interface:
– Euroradio air-gap[ci]
• Sub functions:
– [IEVC.F3.02.08.08] Decode and encode ETCS telegrams or messages[function]
– [IEVC.F3.02.08.01] Manage RBC connection[function]
– [IEVC.F3.02.08.02] Connect to the network[function]
– [IEVC.F3.02.08.07] Exchange data through radio communication[function]
– [IEVC.F3.02.08.03] Manage network registration[function]
– [IEVC.F3.02.08.04] Manage Euroradio protocol[function]
– [IEVC.F3.02.08.06] Manage Low-level protocol & modem interface[function]
– [IEVC.F3.02.08.05] Manage safe Euroradio layer[function]

The Euroradio communication function is split into the following components of the iEVC:
• the GSM-R modem[ci] that connects to the GSM-R network and exchanges data over the air-gap. It is
located inside the Telecom box[ci]. This component is outsourced.
• the Modem controller[ci] that is located inside the Safe computer[ci] and that allows adapting the controls
to the type of GSM-R modem[ci] outsourced.
• the CFM[ci] component that is in charge of the low level Euroradio protocol stack as described by
[SyAD-R10-SS37].
• the SFM[ci] component that provides access to the Euroradio safe protocol stack.
• the ETCS messages application[ci] that performs the transformation of packet message received from
SFM[ci] or iBTM application[ci] into data structure that contains unpacked data as expected by the Subset
026 application[ci].
• the Subset 026 application[ci] that manages the RBC connections and the application data exchanged over
the Euroradio air-gap.
The functional architecture is illustrated in Fig. 8.16. Additional details are provided in each component descrip-
tion.

8.2. [IEVC.F3] Run trains under ETCS control [function] 143 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.16: iEVC architecture for Euroradio communication

Allocate
Allocation of the chapter 4 of Subset-037 ‘REFERENCE ARCHITECTURE’ to the functional ar-
chitecture defined in this document [allocate]
Data
• Requirement:
– tsc-req-id-subset-037-euroradio-4[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: System functional architecture
• Justification: the architecture of function IEVC.F3.02.08 "Communicate through radio com-
munication" is made in compliance to the reference architecture described in chapter 4 of
the Subset-037

144 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

8.2.1.11 [IEVC.F3.02.09] Communicate with the driver [function]

Data
• Definition: This function covers the exchange of information with the ETCS driver and the main-
tainer. The associated interfaces are specified in ERA_ERTMS_015560 and `DMI Maintenance and
Fault User Interface Specification`.
• Allocated to:
– iEVC[ci]
• Sil: 3
• Associated interface:
– DMI ETCS User Interface[ci]
– DMI Maintenance User Interface[ci]
– DMI Fault User Interface[ci]
• Sub functions:
– [IEVC.F3.02.09.06] Manage active screens[function]
– [IEVC.F3.02.09.04] Manage DMI protocol for ETCS screens[function]
– [IEVC.F3.02.09.05] Manage DMI SIL2 protocol[function]
– [IEVC.F3.02.09.07] Manage ETCS DMI[function]
– [IEVC.F3.02.09.01] Display information and collect user inputs[function]
– [IEVC.F3.02.09.03] Manage ETCS display information[function]
– [IEVC.F3.02.09.02] Verify safety-related display and driver input[function]

The DMI function is supported by the following components:

• The DMI software is in charge of drawing the various screens to be shown to the driver or maintainer, and
acquire inputs entered through the DMI hardware interface.
• The Subset 026 Application contains the logic necessary to manage DMI inputs and outputs. Some DMI
functions are safety related. Therefore, the DMI functions must include mechanisms to ensure that certain
information are indeed displayed and that some driver inputs are consistent with the current display. This is
achieved by the DMI checker.
• The DMI Application is in charge of the activation of the suitable DMI screens, taking into account the
active cabin and potential DMI device failure.
• The DMI driver manages the communication with all DMI devices.
• The DMI checker checks the consistency of the safe information to display and detects safe user inputs.
The DMI function also controls the access to fault and maintenance screens. These screens are managed by the
On-Board Operation and Maintenance software.
Access to fault menu is only possible when the train is at standstill and allows the user to view the current fault
status and to report the failure of a component.
Access to maintenance menu is restricted to maintainers, based on configured special driver IDs. It allows to view
the current LRU lifetimes, the service and configuration report. The user can perform interactive tests and report
a maintenance operation.
This functional architecture is illustrated in in figure Fig. 8.17.

8.2. [IEVC.F3] Run trains under ETCS control [function] 145 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.17: DMI functional architecture

8.2.1.12 [IEVC.F3.02.13] Support data recording for regulatory purposes [function]

Data
• Definition: This function includes the recording of juridical data into a non-volatile memory as
described in Subset 027.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Associated interface:
– CPM - OBOM interface[ci]
• Sub functions:
– [IEVC.F3.02.13.01] Compute JRU data[function]
– [IEVC.F3.02.13.03] Decode JRU data[function]
– [IEVC.F3.02.13.02] Publish JRU data[function]

The JRU function is supported by the following components:

• The Subset 026 Application constructs, at each evaluation cycle, the list of JRU messages that need to be
produced, in accordance with the requirements of [SyAD-R16-SS027].
• The Virtual Machine publishes these messages to the On-Board Operation and Maintenance software as
log entries. In turn, the On-Board Operation and Maintenance software writes the received log entries to a
rotating log files on the Crash Protected Memory.
• The JRU decoder is an off-line tool dedicated to the decoding of the data logged for juridical purposes.
The log files on the Crash Protected Memory are decoded using the JRU decoder.

146 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

This functional architecture is illustrated in Fig. 8.18.

Figure 8.18: JRU functional architecture

8.2.1.13 [IEVC.F3.02.14] Manage train interface [function]

Data
• Definition: This function covers the exchange of functional data between the iEVC On-board sub-
system and the train. Such functional data are described in Subset 034.
• Allocated to:
– iEVC[ci]
• Sil: 4
• Associated interface:
– iEVC - Train generic interface[ci]

8.2. [IEVC.F3] Run trains under ETCS control [function] 147 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Sub functions:
– [IEVC.F3.02.14.03] Map Application variables onto I/O[function]
– [IEVC.F3.02.14.11] Manage Emergency Brake test[function]
– [IEVC.F3.02.14.05] Manage IO board[function]
– [IEVC.F3.02.14.06] Collect inputs[function]
– [IEVC.F3.02.14.07] Drive outputs[function]
– [IEVC.F3.02.14.08] Provide safe contacts[function]
– [IEVC.F3.02.14.01] Manage logical I/O signal[function]
– [IEVC.F3.02.14.04] Manage Ethernet I/O[function]
– [IEVC.F3.02.14.02] Provide Test mode input[function]

The TIU function is supported by the following components:

• The Safe computer (with its Operating System and with its IO boards) is in charge of providing the physical
access to the physical inputs and outputs in the train interface. Since this information will be used to carry
out safety functions, it must ensure that the inputs can be trusted, and that outputs will never have a wrong-
side failure.
• The Virtual Machine is in charge of providing the physical train input status to the applications, and trans-
ferring the outputs as computed by the applications.
• The TIU application maps the physical inputs and outputs to the functional variables expected by the iEVC
applications (most importantly the Subset 026 Application).
• The Safety Relays provide dry contacts and allow to adapt to higher line tensions and/or currents than those
of the IO board of the Safe computer.
• The Test key switch[ci] uses a specific digital input to inform the Safe computer that the platform should run
in a special Test mode.
This functional architecture is illustrated in Fig. 8.19.

148 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.19: TIU functional architecture

8.2.1.14 [IEVC.F3.02.15] Read Euroloop information [function]

Data
• Definition: This function allows the ETCS On-board subsystem to read information from Euroloop
devices. This function is specified in Subset 044.
• Allocated to:
– iEVC[ci]
• Associated interface:
– Eurobalise air-gap[ci]
• Sub functions:
– [IEVC.F3.02.15.02] Relay Euroloop Spread Spectrum Code[function]
– [IEVC.F3.02.15.01] Demodulate the Euroloop signal[function]

The activation of an Euroloop device is done though the Eurobalise Tele-powering signal (see [IEVC.F3.02.07]
Read Eurobalise information[function]). No additional feature is required. Therefore this function focuses on the
processing of the Euroloop Up-link signal.
The main components involved in this function are:
• the Euroantenna that contains the loops that pick up the Euroloop Up-link magnetic field.
• the iBTM-RX module that detects the Euroloop Up-link signal and demodulates it to extract the Up-link
telegram information. The demodulation process uses a Spread Spectrum Code that is provided by the
Subset 026 application (see [SyAD-R50-SS44]).

8.2. [IEVC.F3] Run trains under ETCS control [function] 149 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• the iBTM driver synchronizes the communication between the iBTM application and the 2 iBTM-RX com-
ponents.
• the iBTM application relays the Spread Spectrum Code from the Subset 026 application[ci] to the 2 iBTM-
RX components. It decodes the Euroloop telegram received from the 2 iBTM-RX components.
• the ETCS messages application performs the transformation of packet message received from the iBTM
application[ci] into a data structure that contains application variables as expected by the Subset 026 Appli-
cation
• the Subset 026 Application consumes the unpacked data for signalling purpose. It also provides the Spread
Spectrum Code to use during Euroloop signal demodulation.

150 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.20: Logical architecture for Euroloop transmission

The Eurobalise V1 interface (see [IEVC.F3.02.07] Read Eurobalise information[function]) can be used to inter-
face a Subset 103 laboratory in charge of testing the Euroloop.

8.2. [IEVC.F3] Run trains under ETCS control [function] 151 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

8.2.2 [IEVC.F3.03] Support ETCS CI certification process [function]

Data
• Definition: The iEVC On-board subsystem supports the ETCS certification process by providing
specific features and interfaces to perform tests according to subsets 076, 085, 092 and 094.
• Allocated to:
– iEVC[ci]
• Associated interface:
– Sensor box - V1V2 interface[ci]
• Sub functions:
– [IEVC.F3.03.02] Support test according to Subset 076[function]
– [IEVC.F3.03.03] Support test according to Subset 085 (BTM tests)[function]
– [IEVC.F3.03.04] Support test according to Subset 092 (Euroradio tests)[function]
– [IEVC.F3.03.05] Support test according to Subset 094 (Interoperability tests architec-
ture)[function]

8.2.2.1 [IEVC.F3.03.02] Support test according to Subset 076 [function]

Data
• Definition: The iEVC on-board subsystem provides the necessary interfaces for carrying out subset
076 testing.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Associated interface:
– iEVC - Train generic interface[ci]
– Eurobalise air-gap[ci]
– Euroradio air-gap[ci]
– DMI ETCS User Interface[ci]

No specific interface is developed in addition to the interfaces already used for normal operation.

8.2.2.2 [IEVC.F3.03.03] Support test according to Subset 085 (BTM tests) [function]

Data
• Definition: The iEVC on-board subsystem provides the necessary interfaces (V1, V2) for carrying
out the BTM compatibility testing.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Associated interface:

152 of 750 8.2. [IEVC.F3] Run trains under ETCS control [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– Sensor box - V1V2 interface[ci]

• Sub functions:
– [IEVC.F3.03.03.02] Manage V1 and V2 interfaces[function]
– [IEVC.F3.03.03.01] Provide V1 and V2 interfaces[function]
– [IEVC.F3.03.03.03] Manage V1-V2 serial link[function]

An overview of the functional architecture is provided in Fig. 8.21. More details are available in the description
of [IEVC.F3.02.07] Read Eurobalise information[function] and in each iBTM component description.

Figure 8.21: iEVC functional architecture - V1 and V2 test interface for Subset 085 laboratory

8.2. [IEVC.F3] Run trains under ETCS control [function] 153 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

8.2.2.3 [IEVC.F3.03.04] Support test according to Subset 092 (Euroradio tests) [function]

Data
• Definition: The iEVC on-board subsystem provides the necessary interface for performing the Eu-
roradio compatibility tests specified in Subset 092.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Associated interface:
– Euroradio air-gap[ci]

No specific interface is developed in addition to the interfaces already used for normal operation.
This function is covered by the certificate provided with the iEVC Telecom kit[ci].

8.2.2.4 [IEVC.F3.03.05] Support test according to Subset 094 (Interoperability tests architecture)
[function]

Data
• Definition: The iEVC on-board subsystem provides the necessary interface required to be compati-
ble with a laboratory that complies with Subset 094.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Associated interface:
– iEVC - Train generic interface[ci]

No specific interface is developed in addition to the interfaces already used for normal operation. The Modem
Controller - GSM-R Modem Interface[ci] can also be used to produce AT commands for testing purpose.
This function is covered by specific features provided by the Virtual Machine such as the debug interface and the
record-replay mechanism. The VM debug interface is described in [SyAD-R68-SIF-VM-DBG]. Concerning the
record-replay mechanism please refer to [IEVC.F1.15] Record execution[function].

8.3 [IEVC.F4] Maintain IEVC in service [function]

Data
• Definition: In order to maintain the iEVC in service, the iEVC system provides support to preventive
and corrective maintenance.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Sub functions:
– [IEVC.F4.31] Check VM compatibility with sensor components[function]

154 of 750 8.3. [IEVC.F4] Maintain IEVC in service [function]

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– [IEVC.F4.05] Collect a failure report from the driver[function]

– [IEVC.F4.07] Determine estimated lifetime and trigger lifetime warning.[function]
– [IEVC.F4.08] Display fault synoptic[function]
– [IEVC.F4.11] Perform LRU interactive tests[function]
– [IEVC.F4.12] Produce configuration report[function]
– [IEVC.F4.13] Produce event report[function]
– [IEVC.F4.14] Produce service report[function]
– [IEVC.F4.17] Record a maintenance activity[function]
– [IEVC.F4.28] Provide maintenance and fault information[function]
– [IEVC.F4.29] Manage maintenance and fault information to display[function]
– [IEVC.F4.30] Provide 4G connection[function]
– [IEVC.F4.32] Reset iEVC components[function]

The maintenance features of the iEVC system are organized around the concept of Line Replaceable Unit (LRU).
A LRU is essentially a component of the system that can be replaced and/or programmed on-board the train. For
each LRU, the iEVC system will therefore determine whether or not faults have or are occurring, and provide the
necessary information to manage their preventive maintenance (e.g. up-time, down-time, mileage, . . . )
In addition to this fault management, the iEVC system provides additional maintenance features. Using the iEVC,
it is possible to record a maintenance operation through a service entry on the DMI, to consult the configuration
data of all LRU (e.g. part number and version), as well as query the iEVC for events having occurred in the past.
Finally, the iEVC includes Built In Test Equipment (BITE) functions. Such functions provide a support for per-
forming interactive tests on specific LRU in order to verify their correct installation, for example after a replace-
ment.
This function is mainly supported by the following components:
1. LRU application
This application, delivered with the generic platform, determines the presence of faults in each LRU.
It also calculates the estimated lifetime of each LRU, and triggers lifetime warning messages in case the
estimated lifetime reaches certain thresholds.
2. On-Board Operation and Maintenance software
Within the context of this function, this software is responsible for collecting the maintenance and fault
information from all LRU. It is then responsible for dispatching this information to the LRU application or
for logging it in the Crash Protected Memory.
3. 4G Modem
The position and date information are given by the 4G Modem. This component contains an interface with
a geo localization system such as GPS.
This information is then used by OBOM for logging the speed and position of the train, as well as for
timestamping purpose in its logs.
4. DMI software
The interface with the maintainer on-board the train is achieved by the DMI software. In order not to
pollute the ETCS information interface with the DMI, On-Board Operation and Maintenance software has
a dedicated networked interface with the DMI.
5. Crash Protected Memory
OBOM writes its logs on the Crash Protected Memory.

8.3. [IEVC.F4] Maintain IEVC in service [function] 155 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

6. Virtual Machine
The VM interfaces OBOM and applications to exchange maintenance and fault information. It provides
its configuration report to the On-Board Operation and Maintenance software. It also checks its hardware
and software compatibility with the main components of the Sensor box (iODO, iODO BITE, iBTM-RX &
iBTM-TX). The compatibility check is required to ensure that any software update is performed correctly.
7. Odometry Application
It provides information used to compute the mileage of components.
8. iBTM application
It provides the means to drive the iBTM test features.
Fig. 8.22 provides an overview of the structure of function F4 with the associated certification kit based on the
component to which the function is allocated.

156 of 750 8.3. [IEVC.F4] Maintain IEVC in service [function]

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.22: Functional structure of F4 with associated certification kit

8.3. [IEVC.F4] Maintain IEVC in service [function] 157 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

8.3.1 [IEVC.F4.05] Collect a failure report from the driver [function]

Data
• Definition: The driver can report failures using the iEVC DMI. The purpose is to avoid having the
need of a third party application to report failure to the operations and maintenance systems.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Associated interface:
– DMI Fault User Interface[ci]
• Sub functions:
– [IEVC.F4.05.01] Collect failure report from driver[function]

This function is supported by the following components:

• DMI software: in order to enter a failure report, the driver uses the DMI Fault User Interface[ci]. The DMI
software then sends the report to On-Board Operation and Maintenance software.
• On-Board Operation and Maintenance software: logs the failure report as an appropriate failure event in its
event logs
• Crash Protected Memory: hosts the OBOM logs, in particular the events corresponding to failure reports as
entered by the driver.
This functional architecture is illustrated in Fig. 8.27

8.3.2 [IEVC.F4.07] Determine estimated lifetime and trigger lifetime warning.

[function]

Data
• Definition: For each LRU of the iEVC on-board subsystem, a predictive maintenance function
continuously calculates the estimated lifetime remaining.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Sub functions:
– [IEVC.F4.07.01] Determine LRU lifetime and warnings[function]
– [IEVC.F4.07.04] Recover lifetime data[function]
– [IEVC.F4.07.03] Publish lifetime data and warnings (OBOM)[function]
– [IEVC.F4.07.02] Publish lifetime data and warnings (VM)[function]

This function is supported by the following components:

• DMI software: lifetime warnings are displayed on a dedicated screen of the DMI Fault User Interface[ci].
• Odometry Application: provide a fresh measure of the traveled distance by the train. This information is
necessary to compute the mileage of components and trigger lifetime warnings based on mileage;

158 of 750 8.3. [IEVC.F4] Maintain IEVC in service [function]

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• On-Board Operation and Maintenance software: performs the dual role of logging updated lifetime es-
timates, and providing past logs so that the lifetime computations do not reset when the iEVC is power
cycled;
• Virtual Machine: interfaces OBOM and applications for exchanging lifetime data;
• LRU application: determines lifetime warnings based on the information provided both by OBOM and
odometry.
• Crash Protected Memory: hosts the OBOM logs, in particular the record of previous lifetime estimations;
This functional architecture is illustrated in Fig. 8.23.

Figure 8.23: Lifetime computation and warning functional architecture

8.3. [IEVC.F4] Maintain IEVC in service [function] 159 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

8.3.3 [IEVC.F4.08] Display fault synoptic [function]

Data
• Definition: The iEVC on-board subsystem determines the presence of faults on its LRUs. For each
LRU fault, a dedicated synoptic is available on the DMI, as well as a list of suggested action.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Associated interface:
– DMI Fault User Interface[ci]
• Sub functions:
– [IEVC.F4.08.01] Determine LRU faults[function]
– [IEVC.F4.08.02] Publish LRU fault data[function]

This function is supported by the following components:

• LRU application: determine overall fault status of the iEVC, based on the information collected through
[IEVC.F4.28] Provide maintenance and fault information[function]. Produce the fault status message,
containing, among other things, the suggested actions;
• Virtual Machine: interfaces OBOM and applications for exchanging fault data;
• On-Board Operation and Maintenance software: logs the fault data in a specific log, and provides the fault
data to the DMI for display;
• DMI software: faults are displayed on dedicated screens of the DMI Fault User Interface[ci].
• Crash Protected Memory: hosts the OBOM logs, in particular the fault data.
This functional architecture is illustrated in Fig. 8.24.

160 of 750 8.3. [IEVC.F4] Maintain IEVC in service [function]

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.24: Faults display functional architecture

8.3.4 [IEVC.F4.11] Perform LRU interactive tests [function]

Data
• Definition: The iEVC on-board subsystem offers an interactive test mode. This mode allows the
maintainer to trigger tests inside the iEVC LRUs and software. It is accessed through the mainte-
nance user interface of the DMI.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Associated interface:
– DMI Maintenance User Interface[ci]
• Sub functions:
– [IEVC.F4.11.01] Manage interactive test sessions[function]

8.3. [IEVC.F4] Maintain IEVC in service [function] 161 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– [IEVC.F4.11.04] Manage iODO BITE test[function]

– [IEVC.F4.11.03] Interface LRU interactive tests (OBOM)[function]
– [IEVC.F4.11.02] Interface LRU interactive tests (VM)[function]

This function is supported by the following components:

• LRU application: during an interactive test session, the LRU application is responsible for orchestrating this
session. It does so by collecting inputs from the maintainer on the DMI, and building an interactive test
report that is sent back to the DMI for display during the test session;
• DMI software: interactive test reports are displayed on dedicated screens of the DMI Fault User Inter-
face[ci].
• iBTM application: provides the means for the LRU application to drive the test features of the iBTM, such
as the ability to simulate balise detection;
• Odometry Application: provides the means for the LRU application to drive the test features of the odometry
components, such as the ability to simulate odometry sensor signals in input of the sensor box;
• Virtual Machine: interfaces OBOM and applications for exchanging interactive test data. Furthermore, the
iODO BITE driver[ci] provides access to the iODO BITE test features, such as the simulation of odometry
sensors inputs;
• On-Board Operation and Maintenance software: interfaces DMI and VM for exchanging interactive test
data;
This functional architecture is illustrated in Fig. 8.25.

162 of 750 8.3. [IEVC.F4] Maintain IEVC in service [function]

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.25: Interactive test functional architecture

8.3.5 [IEVC.F4.12] Produce configuration report [function]

Data
• Definition: The iEVC on-board subsystem can produce a configuration report, showing the exact
version information for all LRUs and software. This report can be accessed on the maintenance UI
of the DMI.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Associated interface:
– DMI Maintenance User Interface[ci]
• Sub functions:
– [IEVC.F4.12.01] Publish configuration report[function]

8.3. [IEVC.F4] Maintain IEVC in service [function] 163 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– [IEVC.F4.12.02] Publish VM configuration report[function]

This function is supported by the following components:

• On-Board Operation and Maintenance software: computes an overall configuration report of the iEVC,
based on the information collected through [IEVC.F4.28] Provide maintenance and fault informa-
tion[function];
• Virtual Machine: provides the configuration report of the VM, including the version of the loaded applica-
tion and configuration files;
• DMI software: displays the configuration report on dedicated screens of the DMI Fault User Interface[ci].
This functional architecture is illustrated in Fig. 8.26.

Figure 8.26: Configuration report functional architecture

164 of 750 8.3. [IEVC.F4] Maintain IEVC in service [function]

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

8.3.6 [IEVC.F4.13] Produce event report [function]

Data
• Definition: The iEVC on-board subsystem can produce an event report, showing the history of
events detected on a specified period of time. This report can be accessed on the maintenance user
interface of the DMI.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Associated interface:
– DMI Maintenance User Interface[ci]
• Sub functions:
– [IEVC.F4.13.01] Log event[function]
– [IEVC.F4.13.02] Query events from event log[function]

Within the context of this function, an event is a timestamped plain-text message attached to an LRU. Events are
logged in rotating log files that can be queried to produce reports.
Event logs are different from pure data logs, in the sense that event logs are designed to be read by human beings,
and / or transmitted as short text messages.
This function is supported by the following components:
• On-Board Operation and Maintenance software: logs all the events collected from the following sources:
– JRU data: among the various data that must be logged according to [SyAD-R16-SS027], some of them
correspond to events. These events are extracted and logged;
– Service log: maintainer can enter service log entries through the DMI (through [IEVC.F4.14] Produce
service report[function]). When this happens, a suitable event should be inserted in the event log of
the iEVC;
– Selected variables: the VM can be configured to trigger specific events when some application vari-
ables take certain values. These events are collected by OBOM and logged;
– Failure report from drivers: as described in [IEVC.F4.05] Collect a failure report from the
driver[function], drivers can enter an observed failure. This is recorded as a suitable event in the
iEVC event log.
– Lifetime warnings, as produced by [IEVC.F4.07] Determine estimated lifetime and trigger lifetime
warning.[function]: such warnings are translated to suitable events in the event log;
– Detected faults, as produced by [IEVC.F4.08] Display fault synoptic[function]: when faults are de-
tected, a corresponding event is logged.
In addition, OBOM provides a query service that can be used to recover logged events based on query
parameters.
• Crash Protected Memory: hosts the event logs.
• DMI software: through the DMI Fault User Interface[ci], provides the maintainer with the ability to query
the event log.
This functional architecture is illustrated in Fig. 8.27

8.3. [IEVC.F4] Maintain IEVC in service [function] 165 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.27: Event reporting functional architecture

8.3.7 [IEVC.F4.14] Produce service report [function]

Data
• Definition: The iEVC on-board subsystem can produce a service report, showing the history of
maintenance operations recorded over a specified period of time. This report can be accessed on the
maintenance user interface of the DMI.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Associated interface:
– DMI Maintenance User Interface[ci]

166 of 750 8.3. [IEVC.F4] Maintain IEVC in service [function]

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Sub functions:
– [IEVC.F4.14.01] Query service log[function]

Within the context of this function, a service report is a timestamped report of a maintenance activities carried out
on an LRU. Example of such operations are: replacement of LRU, routine inspection of LRU, etc.
Such maintenance activity records are produced by [IEVC.F4.17] Record a maintenance activity[function].
This function is supported by the following components:
• DMI software: the maintainer uses the DMI Fault User Interface[ci] to query the recorded maintenance
activities and produce a matching service report.
• On-Board Operation and Maintenance software: provides the necessary function to query the logs and
extract past maintenance activities;
• Crash Protected Memory: hosts the OBOM logs, in particular the one dedicated to maintenance activities.
This functional architecture is illustrated in Fig. 8.28.

Figure 8.28: Service report functional architecture

8.3. [IEVC.F4] Maintain IEVC in service [function] 167 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

8.3.8 [IEVC.F4.17] Record a maintenance activity [function]

Data
• Definition: The maintainer can record an iEVC maintenance activity using the DMI maintenance
user interface.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Associated interface:
– DMI Maintenance User Interface[ci]
• Sub functions:
– [IEVC.F4.17.01] Log maintenance operation[function]

This function is supported by the following components:

• DMI software: in order to enter a service report, the maintainer uses the DMI Fault User Interface[ci]. The
DMI software then sends the report to On-Board Operation and Maintenance software;
• On-Board Operation and Maintenance software: logs the service report in a dedicated log. It also provides
the LRU maintenance event information to the Virtual Machine that, in turn, will transfer this information
to the LRU application (see also Fig. 8.23);
• Crash Protected Memory: hosts the OBOM logs, in particular the one dedicated to maintenance activities.
This functional architecture is illustrated in Fig. 8.28.

8.3.9 [IEVC.F4.28] Provide maintenance and fault information [function]

Data
• Definition: On-board subsystems of all nature provide the necessary information for determining
the presence of faults and to support maintenance functions (e.g. configuration, lifetime, etc).
• Allocated to:
– iEVC[ci]
• Sil: basic
• Associated interface:
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]
• Sub functions:
– [IEVC.F4.28.05] 4G modem - Provide maintenance and fault information[function]
– [IEVC.F4.28.12] CPM - Provide maintenance and fault information[function]
– [IEVC.F4.28.02] Ethernet switch - Provide maintenance and fault information[function]
– [IEVC.F4.28.15] Sensor box ethernet switch - Provide maintenance and fault informa-
tion[function]
– [IEVC.F4.28.08] GSM-R modem - Provide maintenance and fault information[function]
– [IEVC.F4.28.16] Provide status information[function]

168 of 750 8.3. [IEVC.F4] Maintain IEVC in service [function]

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– [IEVC.F4.28.01] Safe computer - Provide maintenance and fault information[function]

– [IEVC.F4.28.11] Sensor box power supply - Provide maintenance and fault informa-
tion[function]
– [IEVC.F4.28.04] Telecom box power supply - Provide maintenance and fault informa-
tion[function]
– [IEVC.F4.28.10] Collect DMI maintenance and fault information[function]
– [IEVC.F4.28.09] Modem controller - Provide maintenance and fault information[function]
– [IEVC.F4.28.06] Collect maintenance and faults information[function]
– [IEVC.F4.28.13] Collect fault information from OBOM[function]
– [IEVC.F4.28.14] Collect safe computer faults[function]

In order to determine the status of LRUs, and produce a complete configuration report of the iEVC, it is necessary
to collect from each LRU the information about faults and configuration.
This function is supported by many components.
The following components provide their maintenance and fault information:
• Ethernet switch[ci];
• 4G modem[ci];
• DMI[ci];
• Sensor Box Power Supply[ci];
• Telecom box power supply[ci];
• Crash protected memory[ci];
• GSM-R modem[ci];
• Safe computer[ci];
• TSC Net[ci];
• Sensor box ethernet switch[ci]

Note: The maintenance and fault information for the Safe computer power supply is included in the information
provided by the Safe computer OS.

Then:
• OBOM[ci] collects all this information and performs a synthesis that is sent to the Virtual machine[ci]. An
exception is the Safe computer, for which the information is collected by the VM directly.
• Virtual machine[ci] provides all the information to the applications.
This functional architecture is illustrated in Fig. 8.29.

8.3. [IEVC.F4] Maintain IEVC in service [function] 169 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.29: Fault computation functional architecture

Note: Faults are also collected directly by the LRU application from the various iEVC applications through
dedicated alarm variables.

8.3.10 [IEVC.F4.29] Manage maintenance and fault information to display [func-

tion]

Data
• Definition: Manage the display of maintenance and fault information on the DMI, ensuring that the
correct screen is displayed with the correct information available.
• Allocated to:
– iEVC[ci]
• Sil: basic

170 of 750 8.3. [IEVC.F4] Maintain IEVC in service [function]

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Associated interface:
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]
• Sub functions:
– [IEVC.F4.29.01] Manage maintenance and fault screens[function]
– [IEVC.F4.29.02] Manage maintenance and faults information to display[function]
– [IEVC.F4.29.03] Publish fault status[function]

This function is supported by the following components:

• DMI software: displays the adequate screen on the DMI Fault User Interface[ci], based on the requests
received from On-Board Operation and Maintenance software;
• On-Board Operation and Maintenance software: orders the screen to be displayed based on the inputs made
by the user on DMI Fault User Interface[ci].

8.3.11 [IEVC.F4.30] Provide 4G connection [function]

Data
• Definition: Manage the 4G connection that can be used for the connection from the wayside to the
iEVC.
• Allocated to:
– 4G modem[ci]
• Sil: basic
• Sub functions:
– [IEVC.F4.30.01] Perform 4G connection startup[function]
– [IEVC.F4.30.02] Manage sim card handover[function]
– [IEVC.F4.30.03] Manage the connection with the 4G operator[function]
– [IEVC.F4.30.04] Exchange data over 4G Network[function]
– [IEVC.F4.30.05] Protect iEVC network from unauthorized access.[function]

This function is fully supported by the 4G Modem.

8.3.12 [IEVC.F4.32] Reset iEVC components [function]

Data
• Definition: Manage the software reset of the iEVC on-board components.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Sub functions:
– [IEVC.F4.32.02] Command iBTM component reset[function]

8.3. [IEVC.F4] Maintain IEVC in service [function] 171 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– [IEVC.F4.32.06] Reset 4G modem[function]

– [IEVC.F4.32.07] Reset Ethernet switch[function]
– [IEVC.F4.32.12] Reset Sensor box ethernet switch[function]
– [IEVC.F4.32.18] Command digital outputs[function]
– [IEVC.F4.32.08] Reset GSM-R modem[function]
– [IEVC.F4.32.14] Reset iBTM-RX[function]
– [IEVC.F4.32.13] Reset iBTM-TX[function]
– [IEVC.F4.32.15] Reset iODO[function]
– [IEVC.F4.32.03] Command iODO component reset[function]
– [IEVC.F4.32.16] Reset iODO BITE[function]
– [IEVC.F4.32.19] Command iODO BITE component reset[function]
– [IEVC.F4.32.09] Command GSM-R modem reset[function]
– [IEVC.F4.32.01] Command iEVC component reset[function]
– [IEVC.F4.32.04] Relay reset orders[function]
– [IEVC.F4.32.17] Reset VM[function]

This function is supported by the following components:

• On-Board Operation and Maintenance software: commands the reset of the various components by pro-
ducing reset order messages that are dispatched to the interfaced components through Ethernet.
• Virtual Machine: relays the reset orders received from the OBOM through TSC Net to:
– the iBTM driver that controls the reset of the iBTM components inside the Sensor box (iBTM-TX
module and iBTM-RX module)
– the IO driver that controls the reset of the iODO module
– the iODO BITE driver that controls the reset of the iODO BITE module
– the Safe computer
• Euroradio Modem controller Software: translates the reset order from the OBOM into a GSM-R modem
low level command
• Ethernet Switch: translates the reset order from the OBOM into the activation of digital outputs that trigger
a power on cycle of the Safe computer or the DMI computers
• all the components able to reset them-self implement a specific reset function that is triggered when receiv-
ing a reset order. These components are:
– Ethernet switch[ci]
– Sensor box ethernet switch[ci]
– 4G modem[ci]
– GSM-R modem[ci]
– iBTM-TX[ci]
– iBTM-RX[ci]
– iODO[ci]
– iODO BITE[ci]
– Virtual machine[ci]

172 of 750 8.3. [IEVC.F4] Maintain IEVC in service [function]

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• iBTM application and Odometry Application are able to order respectively iBTM and iODO component
reset following a detected failure of the component (see Recovery strategy).
This functional architecture is illustrated in Fig. 8.30.

Figure 8.30: iEVC component reset

Note: There are two sources for iBTM and iODO boards reset: the OBOM, the iBTM and Odometry applications.
Reset may be triggered automatically by the applications when a failure is detected (refer to Section 7.7.2). The
reset triggered from OBOM will be used for remote software update in a future version of the iEVC

8.4 [IEVC.F5] Operate trains fitted with iEVC [function]

Data
• Definition: The iEVC supports operations by keeping a record of the following on-board informa-
tion: the juridical data required by ETCS Subset 027, the train location data from the odometry
function, selected events, LRU lifetime information, maintenance activities, and selected variables.
The record takes the form of a time series, containing for each entry the GPS position of the vehicle.
To that purpose, the iEVC on-board subsystems are interfaced to a GPS
• Allocated to:
– iEVC[ci]
• Sub functions:
– [IEVC.F5.03] Record GPS position and time[function]
– [IEVC.F5.05] Record selected variables[function]

8.4. [IEVC.F5] Operate trains fitted with iEVC [function] 173 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– [IEVC.F5.08] Manage iEVC Ethernet network[function]

– [IEVC.F5.09] Manage non-volatile operational data[function]

Fig. 8.31 provides an overview of the structure of function F5 with the associated certification kit based on the
component to which the function is allocated.

Figure 8.31: Functional structure of F5 with associated certification kit

8.4.1 [IEVC.F5.03] Record GPS position and time [function]

Data
• Definition: The iEVC on-board subsystem records GPS data. The position and time information is
used to characterize the operational data stored in the crash protected memory.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Sub functions:
– [IEVC.F5.03.01] Determine GPS position and time[function]
– [IEVC.F5.03.02] Record GPS position and time[function]

This function is supported by the following components:

• 4G Modem: interfaces with a GPS network and provides GPS data;
• On-Board Operation and Maintenance software: records the GPS data in an adequate log file;
• Crash Protected Memory: hosts the OBOM logs, in particular the one dedicated to GPS data.

174 of 750 8.4. [IEVC.F5] Operate trains fitted with iEVC [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.32: Functional structure of F5.03

8.4.2 [IEVC.F5.05] Record selected variables [function]

Data
• Definition: The iEVC on-board subsystem provides a function to select the data to be included in the
operational and maintenance data. The term 'selected variables' refers to data not already included
in regulatory data. It also provides a data logging function to store machine execution information
ina rotating log file.
• Allocated to:
– iEVC[ci]
• Sil: basic
• Sub functions:
– [IEVC.F5.05.02] Record data in crash protected memory[function]

8.4. [IEVC.F5] Operate trains fitted with iEVC [function] 175 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– [IEVC.F5.05.01] Log Data[function]

– [IEVC.F5.05.03] Record selected variables[function]
– [IEVC.F5.05.04] Extract JRU events to log[function]

The Application package descriptor file is loaded by the Virtual Machine at initialization (see Application package
descriptor file for a description of this file). It contains the application variables that must be logged during
execution, and the events that must be triggered when these variables take certain values.
This allows iEVC users to dynamically configure the system to log any interesting data without having to modify
the applications themselves.
This function is supported by the following components:
• Virtual Machine: it provides the execution data from which the selected data values can be extracted. It also
provides the execution entries to log in the rotating memory;
• On-Board Operation and Maintenance software: based on the specification embedded in the application
package descriptor file uploaded to the VM at initialization, OBOM records the specified application vari-
ables and generates adequate events. It also provides the function to record different machine execution data
(OBOM log entry and VM log entry) in a rotating log file in the CPM;
• Crash Protected Memory: hosts the OBOM log files.
This functional architecture is illustrated in section Record selected variables functional architecture.

176 of 750 8.4. [IEVC.F5] Operate trains fitted with iEVC [function]
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 8.33: Record selected variables functional architecture

8.4.3 [IEVC.F5.08] Manage iEVC Ethernet network [function]

Data
• Definition: The iEVC on-board subsystem provides a function to manage the Ethernet network
services in the iEVC On-board subsystem and in interface with the train network.
• Allocated to:
– Ethernet switch[ci]
– Sensor box ethernet switch[ci]
• Sil: basic
• Associated interface:
– iEVC - Train generic interface[ci]
• Sub functions:
– [IEVC.F5.08.01] Perform Ethernet network startup[function]
– [IEVC.F5.08.02] Perform Ethernet packet switching[function]
– [IEVC.F5.08.03] Mirror Ethernet network traffic[function]

8.4. [IEVC.F5] Operate trains fitted with iEVC [function] 177 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

This function is fully supported by the Ethernet Switch components.

8.4.4 [IEVC.F5.09] Manage non-volatile operational data [function]

Data
• Definition: The iEVC on-board subsystem provides a service to the iEVC applications to allow them
to store and retrieve operational data on a non-volatile memory.
• Allocated to:
– iEVC[ci]
• Sil: 4
• Sub functions:
– [IEVC.F5.09.03] Log non-volatile operational data checksums[function]
– [IEVC.F5.09.02] Read and write non-volatile operational data[function]
– [IEVC.F5.09.01] Provide application access to non-volatile operational data[function]

This function is supported by the following components:

• Virtual Machine: VM offers to the iEVC applications the built-in mechanisms to read and write data on
non-volatile memory;
• On-Board Operation and Maintenance software: provides the VM access to the Crash Protected Memory,
that is used as a non volatile memory;
• Safe computer: stores a control sum of the stored data on a local non-volatile memory. This sum is used to
verify the integrity of the stored data when reading it;
• Crash Protected Memory: hosts the OBOM logs, in particular the one dedicated to non volatile memory.
When iEVC applications request to write a value in non-volatile memory, the VM:
• Concatenates its ETCS_ID to the value to store
• Compute a control sum on the result
The value is then forwarded to OBOM for logging, while the control sum is stored locally on the Safe computer.
When applications request to read the stored value, the VM compares the control sum to that of value read. This
allows VM to verify that the value stored was indeed stored by itself, and not some other device.

8.5 [IEVC.F7] Manage TSC NET network [function]

Data
• Definition: This function is involved for each interface using the TSC net protocol.
• Allocated to:
– TSC Net[ci]
• Output:
– TSC Net Maintenance Data[functional variable][TSC Net - OBOM interface]
• Sil: basic
• Associated interface:
– TSC Net - OBOM interface[ci]

178 of 750 8.5. [IEVC.F7] Manage TSC NET network [function]

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

This function is fully allocated to the component TSC Net.

This function is included in the scope of the iEVC Basic kit[ci].

8.6 [IEVC.F8] Supply power to the iEVC boxes components [func-

tion]

Data
• Definition: This function allows supplying the required power to the components of the Sensor box,
Computer box and Telecom box.
• Allocated to:
– Computer box power supply[ci]
– Sensor Box Power Supply[ci]
– Telecom box power supply[ci]
• Sil: basic
• Sub functions:
– [IEVC.F8.02] Supply power to the Computer box[function]
– [IEVC.F8.01] Supply power to the Sensor box[function]
– [IEVC.F8.03] Supply power to the Telecom box[function]

This function is allocated to the different boxes power supply components.

8.7 [IEVC.F100.LINEAS] Run the train under Lineas specific oper-

ating modes [function]

Data
• Definition: In order to sustain the ‘Refoulement’ (refer to LINEAS use cases), the iEVC on-board
provides a specific operating mode for Lineas.
• Allocated to:
– iEVC[ci]
• Sil: 4

This function shall be managed by a specific Installation project application[ci]. This application may use the
STM interface as described National system interface to enable this operating mode.
This function has a specific application scope.

8.6. [IEVC.F8] Supply power to the iEVC boxes components [function] 179 of 750
b2c00c725888f54563d63f5293b6fdc2681109bb
CHAPTER

NINE

SAFETY & CYBERSECURITY REQUIREMENTS

9.1 Requirements derived from PHA mitigations

Allocate
Allocation of the URS requirement that requires compliance to Subset 091 [allocate]
Data
• Requirement:
– tsc-req-urs-nobo-subset-091[req]
• Artifact:
– IEVC ETCS Safety Plan[artifact]
• Justification: The compliance to the subset 091 is done through the safety analysis described
in the IEVC ETCS Safety plan.

Allocate
Allocation of the requirement that iEVC shall be compliant with CLC/prTS 50701:2019 [allocate]
Data
• Requirement:
– tsc-req-urs-cyber-en-50701[req]
• Artifact:
– iEVC Cybersecurity Plan[artifact]
• Justification: The compliance to this standard must be covered by the IEVC CyberSecurity
Plan and the management of the related mitigations as described in the iEVC Engineering
plan

Allocate
Allocation of the PHA measure which requires that the outsourced components shall be approved
railway industry systems, subsystems and components. [allocate]

180 of 750 9. Safety & Cybersecurity requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-pha-industry-recognized-equipments[req]
• Ci:
– 4G modem[ci]
– 4G antenna[ci]
– GPS antenna[ci]
– Computer box hardware[ci]
– Computer box power supply[ci]
– Test key switch[ci]
– Crash protected memory[ci]
– DMI hardware[ci]
– DMI checker[ci]
– Telecom box hardware[ci]
– Telecom box power supply[ci]
– Ethernet switch[ci]
– GSM-R modem[ci]
– GSM-R antenna[ci]
– Safe computer[ci]
– Safe computer IO Extension[ci]
– Sensor box ethernet switch[ci]
– Sensor Box Power Supply[ci]
– Euroantenna[ci]
– Wheel pulse generators[ci]
– Secondary odometry sensor[ci]
– Safety relay[ci]
• Justification: All the outsourced components installed within the iEVC shall respect this
PHA measure

Allocate
Allocation of the PHA measure which requires the logging of specific application conditions, restric-
tions or exported constraints imposed by the air-borne antennas to the other radio frequency (RF)
equipment [allocate]

9.1. Requirements derived from PHA mitigations 181 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-pha-airborne-antenna-include-app-conditions[req]
• Ci:
– 4G antenna[ci]
– GPS antenna[ci]
– GSM-R antenna[ci]
• Artifact:
– iEVC Telecom Kit Operation Manual[artifact]
– iEVC Telecom Kit Maintenance Manual[artifact]
• Justification: Air-borne antennas installed within the iEVC shall respect this PHA measure
and the manuals shall reflect the supplier prescriptions

Allocate
Allocation of the PHA measure concerning the compliance of the air-borne antennas to EN 301489-
1:2019 (V2.2.3) and EN 301489-3:2013 (V1.6.1) [allocate]
Data
• Requirement:
– tsc-req-urs-pha-airborne-antenna-compliant-en301489[req]
• Ci:
– 4G antenna[ci]
– GPS antenna[ci]
– GSM-R antenna[ci]
• Justification: Air-borne antennas shall respect this PHA measure

Allocate
Allocation of the PHA concerning the specification of periodic inspections and eventual obsolescence
information (i.e. components availability, preventive maintenance operations) from suppliers in the
iEVC Operation Manual & in the iEVC Maintenance Manual. (basic kit) [allocate]

182 of 750 9.1. Requirements derived from PHA mitigations

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-pha-specify-periodic-inspections[req]
– tsc-req-urs-pha-component-obsolescence[req]
– tsc-req-urs-maintainer-obso-process[req]
• Ci:
– Computer box hardware[ci]
– Computer box power supply[ci]
– Test key switch[ci]
– Crash protected memory[ci]
– DMI hardware[ci]
– Ethernet switch[ci]
– Safe computer[ci]
– Safe computer IO Extension[ci]
– Safety relay[ci]
• Artifact:
– iEVC Basic Kit Operation Manual[artifact]
– iEVC Basic Kit Maintenance Manual[artifact]
• Justification: The measures issued from the PHA are allocated to all the hardware compo-
nents of the iEVC and to the Operation and Maintenance manual artifacts. The obsolescence
process has to be specified in maintenance and operation manuals.

9.1. Requirements derived from PHA mitigations 183 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-pha-specify-periodic-inspections[req]
– tsc-req-urs-pha-component-obsolescence[req]
– tsc-req-urs-maintainer-obso-process[req]
• Ci:
– Sensor box ethernet switch[ci]
– Sensor Box Power Supply[ci]
– Euroantenna[ci]
– Wheel pulse generators[ci]
– Secondary odometry sensor[ci]
– Sensor box hardware[ci]
– iODO[ci]
– iBTM-RX[ci]
– iBTM-TX[ci]
– iODO BITE[ci]
• Artifact:
– iEVC Sensor Kit Operation Manual[artifact]
– iEVC Sensor Kit Maintenance Manual[artifact]
• Justification: The measures issued from the PHA are allocated to all the hardware compo-
nents of the iEVC and to the Operation and Maintenance manual artifacts. The obsolescence
process has to be specified in maintenance and operation manuals.

184 of 750 9.1. Requirements derived from PHA mitigations

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-pha-specify-periodic-inspections[req]
– tsc-req-urs-pha-component-obsolescence[req]
– tsc-req-urs-maintainer-obso-process[req]
• Ci:
– 4G modem[ci]
– 4G antenna[ci]
– GPS antenna[ci]
– Telecom box hardware[ci]
– Telecom box power supply[ci]
– GSM-R modem[ci]
– GSM-R antenna[ci]
• Artifact:
– iEVC Telecom Kit Operation Manual[artifact]
– iEVC Telecom Kit Maintenance Manual[artifact]
• Justification: The measures issued from the PHA are allocated to all the hardware compo-
nents of the iEVC and to the Operation and Maintenance manual artifacts. The obsolescence
process has to be specified in maintenance and operation manuals.

Allocate
Allocation of the PHA measure requiring that precautions against toxic materials are provided in
iEVC Operation manual and in iEVC Maintenance manual. [allocate]

9.1. Requirements derived from PHA mitigations 185 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-pha-maintenance-on-toxic-materials[req]
• Ci:
– 4G modem[ci]
– 4G antenna[ci]
– GPS antenna[ci]
– Computer box hardware[ci]
– Computer box power supply[ci]
– Test key switch[ci]
– Crash protected memory[ci]
– DMI hardware[ci]
– Telecom box hardware[ci]
– Telecom box power supply[ci]
– Ethernet switch[ci]
– GSM-R modem[ci]
– GSM-R antenna[ci]
– Safe computer[ci]
– Safe computer IO Extension[ci]
– iODO[ci]
– iBTM-TX[ci]
– iBTM-RX[ci]
– Sensor box ethernet switch[ci]
– Sensor Box Power Supply[ci]
– Euroantenna[ci]
– Wheel pulse generators[ci]
– Secondary odometry sensor[ci]
– Sensor box hardware[ci]
– iODO BITE[ci]
– Safety relay[ci]
• Artifact:
– iEVC Basic Kit Operation Manual[artifact]
– iEVC Basic Kit Maintenance Manual[artifact]
– iEVC Sensor Kit Operation Manual[artifact]
– iEVC Sensor Kit Maintenance Manual[artifact]
– iEVC Telecom Kit Operation Manual[artifact]
– iEVC Telecom Kit Maintenance Manual[artifact]
• Justification: The measure issued from the PHA is allocated to all the hardware components
of the iEVC and to the Operation and Maintenance manual artifacts.

186 of 750 9.1. Requirements derived from PHA mitigations

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Allocate
Allocation of the PHA measure requiring that no explosive material is used. [allocate]
Data
• Requirement:
– tsc-req-urs-pha-no-explosive-materials[req]
• Ci:
– 4G modem[ci]
– 4G antenna[ci]
– GPS antenna[ci]
– Computer box hardware[ci]
– Computer box power supply[ci]
– Test key switch[ci]
– Crash protected memory[ci]
– DMI hardware[ci]
– Telecom box hardware[ci]
– Telecom box power supply[ci]
– Ethernet switch[ci]
– GSM-R modem[ci]
– GSM-R antenna[ci]
– Safe computer[ci]
– Safe computer IO Extension[ci]
– iODO[ci]
– iBTM-TX[ci]
– iBTM-RX[ci]
– Sensor box ethernet switch[ci]
– Sensor Box Power Supply[ci]
– Euroantenna[ci]
– Wheel pulse generators[ci]
– Secondary odometry sensor[ci]
– Sensor box hardware[ci]
– iODO BITE[ci]
– Safety relay[ci]
• Justification: The measure issued from the PHA is allocated to all the hardware components
of the iEVC

Allocate
Allocation of the PHA measure that requires including precautions against ESD in iEVC Operation
manual and in the iEVC Maintenance manual. [allocate]

9.1. Requirements derived from PHA mitigations 187 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-pha-precautions-against-esd[req]
• Ci:
– 4G modem[ci]
– 4G antenna[ci]
– GPS antenna[ci]
– Computer box hardware[ci]
– Computer box power supply[ci]
– Test key switch[ci]
– Crash protected memory[ci]
– DMI hardware[ci]
– Telecom box hardware[ci]
– Telecom box power supply[ci]
– Ethernet switch[ci]
– GSM-R modem[ci]
– GSM-R antenna[ci]
– Safe computer[ci]
– Safe computer IO Extension[ci]
– iODO[ci]
– iBTM-TX[ci]
– iBTM-RX[ci]
– Sensor box ethernet switch[ci]
– Sensor Box Power Supply[ci]
– Euroantenna[ci]
– Wheel pulse generators[ci]
– Secondary odometry sensor[ci]
– Sensor box hardware[ci]
– iODO BITE[ci]
– Safety relay[ci]
• Justification: The measure issued from the PHA is allocated to all the hardware components
of the iEVC

Allocate
Allocation of the PHA measure concerning the size of the power supply units [allocate]

188 of 750 9.1. Requirements derived from PHA mitigations

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-pha-ievc-size-power-supply[req]
• Ci:
– Telecom box power supply[ci]
– Computer box power supply[ci]
– Sensor Box Power Supply[ci]
• Justification: Power supply units shall respect this PHA measure

Allocate
Allocation of the PHA measure that concerns access and display of maintenance and faults informa-
tion on DMI shall be inhibited in normal operation conditions, but at standstill. [allocate]
Data
• Requirement:
– tsc-req-urs-pha-fault-info-only-at-standstill[req]
– tsc-req-urs-driver-no-distraction[req]
• Ci:
– Subset 026 application[ci]
• Justification: The Subset 026 Application is the component responsible to enable the access
to the Maintenance and Fault information from the settings window as it controls when to
send the request to display this specific window ID to the DMI software.

Allocate
Allocation of the PHA measure that concerns the design of the airborne antennas in degraded rail-
way conditions, though limiting unnecessary excessive power emission for people and systems (i.e.
maximum allowed power). [allocate]
Data
• Requirement:
– tsc-req-urs-pha-airborne-antenna-adapted-to-all-conditions[req]
• Ci:
– 4G antenna[ci]
– GPS antenna[ci]
– GSM-R antenna[ci]
• Justification: Airborne antennas shall respect this PHA measure

Allocate
Allocation of the PHA measure that concerns the possibility to test a possible malfunction or fault
of the loudspeaker of the iEVC manual [allocate]

9.1. Requirements derived from PHA mitigations 189 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-pha-test-fault-loudspeaker[req]
• Artifact:
– iEVC Basic Kit Operation Manual[artifact]
– iEVC Basic Kit Maintenance Manual[artifact]
• Justification: Instructions to test of the loudspeaker, and instructions in case of loudspeaker
failure shall be included inside the iEVC Operation and Maintenance manual

Allocate
Allocation of the PHA measure that describes the Specific precautions to be followed during mainte-
nance operations on active antennas (i.e. keeping safe distance from any active antenna, requesting
to have the antennas powered down or moved, using RF monitor, etc.). [allocate]
Data
• Requirement:
– tsc-req-urs-pha-describe-antenna-maintenance-precautions[req]
• Ci:
– Euroantenna[ci]
– GPS antenna[ci]
– GSM-R antenna[ci]
– 4G antenna[ci]
• Artifact:
– iEVC Sensor Kit Operation Manual[artifact]
– iEVC Sensor Kit Maintenance Manual[artifact]
– iEVC Telecom Kit Operation Manual[artifact]
– iEVC Telecom Kit Maintenance Manual[artifact]
• Justification: The operations on the active antennas shall respect this PHA measure

Allocate
Allocation of the PHA measure that specifies that the iEVC external subsystems and components
installation shall be consistent with clearance envelope and actual available and practical space for
installation outside and under the car body (including any fastener or adaptor). [allocate]

190 of 750 9.1. Requirements derived from PHA mitigations

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-pha-clearance-envelope[req]
• Ci:
– Euroantenna[ci]
– 4G antenna[ci]
– GPS antenna[ci]
– GSM-R antenna[ci]
– Wheel pulse generators[ci]
– Secondary odometry sensor[ci]
• Justification: The externally-mounted components shall be compliant with a typical train
external enveloppe when mounted.

Requirement

iEVC external subsystems and components shall be installed considering the clearance envelope and
the available and practical space especially outside and under the car body (including any fastener
or adaptor). [id:tsc-req-ievc-clearance-envelope][p1][s]

Requirement exported to the Installation designer.

When an application executes a forbidden action during its execution, then the VM shall go to
VM_FAULT mode. [id:tsc-req-ievc-sha-vm-fault-forbidden-action][p1][s]

The forbidden actions include:

• read or write a variable for which it has no read or write access;
• write constant or configuration variables;
• dividing by 0
• access collection or array outside of its range

Note: The detailed list will be established during detailed design of the VM.

Requirement

When using the “refoulement” mode, this mode shall be displayed on the DMI and recorded in the
system [id:tsc-req-ievc-sha-refoulement-display-and-recorded][p1][s]

Requirement

The Subset 026 application shall manage balise information with no telegram or with erroneous
telegram (with coding errors) as described in section §3.16.2.4 of Subset-026 [id:tsc-req-ievc-sha-wrong-
telegram][p1][s]

Requirement

The class B applications shall react in a safe way to an erroneous message received from the track-
side. [id:tsc-req-ievc-sha-classb-reaction][p1][s]

The reaction is specific to the class B signalling principles.

Requirement

The IO driver shall relay any failure related to logical I/O information detected by the I/O boards
to the TIU application. [id:tsc-req-ievc-sha-io-board-failure-tiu][p1][s]

Requirement

The model of CPM rotating log file shall be defined in order to prevent loss of data (overwriting of
recent data, integrity of the data sent to the CPM, partial overwriting of data) [id:tsc-req-ievc-sha-
format-totating-log-file][p1][s]

9.2. Requirements derived from SHA mitigations 193 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

9.3 Requirements derived from IHA mitigations

Requirement

The iEVC Operation & Maintenance Manuals shall define Periodic inspections of the iEVC (includ-
ing cables, grounding system, power supplies, sensors, Euroantenna, fastening system and inter-
faces) and preventive maintenance procedures and operations (including recovery tests). [id:tsc-req-
ievc-iha-ievc-periodic-inspection][p1][s]

Requirement

The voltage thresholds of the iEVC digital inputs for which the signal is considered indeterminate
shall be defined [id:tsc-req-ievc-iha-io-voltage-threshold][p1][s]

Requirement

The Safe computer shall inform the IO driver of the Virtual Machine when a digital input state
cannot be determined. [id:tsc-req-ievc-iha-digital-in-not-available][p1][s]

Requirement

The iEVC installation manual shall define the installation constraints of the iEVC system for the
Euroantenna. [id:tsc-req-ievc-iha-ievc-euroantenna-installation-constraint][p1][s]

Requirement

The cables and connectors shall be designed in accordance with the requirements of EN 50155
[id:tsc-req-ievc-iha-cables-50155][p1][s]

Requirement exported to the Installation designer and iEVC Designer.

Requirement

The DMI shall have an anti-reflection screen glass [id:tsc-req-ievc-iha-dmi-anti-reflection][p1][s]

Requirement

All the cables used to connect the iEVC inputs/ouputs with the train shall be immunized against
electromagnetic perturbation in accordance with EN 50155. [id:tsc-req-ievc-io-cable-shielding][p2][s]

Requirement exported to the Installation designer and iEVC Designer.

The iEVC shall manage a rotation of the SSH public/private keys that are used for the connection
external to the iEVC system. [id:tsc-req-ievc-hlra-keys-rotation][p1][s]

The rotation mechanism applies to:

• SSH keys for 4G modem connection
• SSH keys for tester laptop connection (including single-use emergency keys)
• authorization keys
• CPM connection account
‘Super user’ privileges are used to make any update.

Note: the key rotation management mechanism and procedure is not described in this version of the
specification.

Requirement

The tester laptop shall be able to connect to the iEVC by using single-use emergency keys. [id:tsc-
req-ievc-hlra-tester-emergency-keys][p1][s]

Requirement

‘Super user’ privileges shall be defined. They shall be used to update the security keys and accounts
at iEVC on-board side. [id:tsc-req-ievc-hlra-super-user][p1][s]

This concerns:
• SSH keys for 4G modem connection
• SSH keys for tester laptop connection (including single-use emergency keys)
• authorization keys
• CPM connection account

9.4. Requirements derived from HLRA mitigations 195 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The iEVC shall implement an account management mechanism for the access to the CPM. [id:tsc-
req-ievc-hlra-keys-cpm-account][p1][s]

Note: the account management mechanism and procedure is not described in this version of the specifi-
cation.

Requirement

The tester laptop shall be protected by end point security (Firewall) that shall be regularly up-
dated to block interactive applications from running automatically [id:tsc-req-ievc-hlra-tester-laptop-
firewall][p1][s]

Requirement

It shall be possible to connect only one tester laptop at a time to the iEVC on-board. [id:tsc-req-ievc-
hlra-only-one-test-laptop][p1][s]

Requirement

The iEVC shall log events related to 4G and tester laptop connection activity for off-line analysis
[id:tsc-req-ievc-hlra-user-activity][p1][s]

The events are logged in the CPM. The detailed list of events that can be logged is detailed in the software
specification.

Note: The logs will be provided to SIDE operate in a later version of the system. SIDE operate will
implement security violation detection mechanisms.

Allocate
Allocation of HLRA requirements to the software development plan. [allocate]
Data
• Requirement:
– tsc-req-urs-hlra-automated-security-function-verification[req]
• Artifact:
– iEVC Software Development Plan[artifact]
• Justification: the iEVC software development plan descibes the cybersecurity activities that
are planned in addition to the SIL4 development techniques.

Requirement

The 4G modem shall manage communication load. As much as possible, the communication load
shall be monitored and limited. [id:tsc-req-ievc-hlra-communication-load][p1][s]

196 of 750 9.4. Requirements derived from HLRA mitigations

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

There shall be a back up policy for all the application packages used to program a fleet of train.
[id:tsc-req-ievc-hlra-back-up][p1][s]

9.4. Requirements derived from HLRA mitigations 197 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
CHAPTER

TEN

RAM DESIGN TARGETS

The URS requirement that drives the iEVC MTBSF target is tsc-req-urs-corrective-maintenance-time[req]. This
requirement, when translated in figures, results in a very low MTBSF for the iEVC.
TSC MTBSF target is therefore higher than the contractual requirement. The logic behind it is to apply the same
target to a fleet of 100 trains, and not a unique train. The resulting requirement is the following:

Requirement

IEVC On-board MTBSF shall be higher than 15000h [id:tsc-req-ievc-mtbsf][p1][ns]

This high level target computations, and the corresponding apportionment to components of the iEVC is detailed
in the following attached spreadsheet.

Input Data Table

RAM targets [xlsx data]

These are design targets. They do not substitute to the RAM analysis, as defined in a RAM plan, and as required
by the TSI.

Allocate
Allocation of RAM plan requirement [allocate]
Data
• Requirement:
– tsc-req-ievc-pqp-tsi-4-2-1-2-1[req]
• Artifact:
– IEVC RAM Plan[artifact]
• Justification: RAM plan must take into account the TSI need for a MTBSF computation.

The URS requirement that drives the iEVC MTTR target is tsc-req-urs-maintenance-lru-repair-time[req]. TSC
MTTR requirement for the iEVC is 30 minutes. In order to leave sufficient time for the repair team to test a
replaced LRU, the component requirement is even reduced:

Requirement

Component replacement time shall be less than 15 minutes. [id:tsc-req-ievc-mttr][p2][ns]

This figures assumes that the component is accessible, and includes any programming that cannot be
achieved through a networked interface at boot time.

198 of 750 10. RAM design targets

b2c00c725888f54563d63f5293b6fdc2681109bb
CHAPTER

ELEVEN

DEVELOPED COMPONENTS

This section details all the components previously introduced in the architecture that are developed specifically in
the frame of the iEVC program.
For each component, the following information is provided, if applicable:
• A general description
• Operating modes of the component
• Functions allocated to the component
• Functional interfaces of the component, especially the definition of inputs, parameters, internal data and
outputs, as well as their allocation to systems interfaces
• Requirements allocated and apportioned to the component
• Failure mode analysis
In order to define system parameters, functional variables are used. The attributes follow the conventions below:
• Attribute: the functional name of the parameter
• Objective: a description of the parameter purpose
• Description: a description of the parameter content
• Type: Name of the parameter. Typically a Camel Case word
– Good: Counter, SomethingElse
– Bad: counter_1, Message 1
The variables Types are defined but not described. They will be described during the software design phase.
• Format: The type used. It can be complex types like structure, but then it needs to be described
• Protocol: System parameter
• Equivalence class: the equivalence classes of the variable in the form [0 first limit[, [first limit, first limit],
]first limit, last limit[, [last limit, last limit],]last limit, inf[
Other attributes are not used.
This is a template for such a variable:

.. tsc_functional_variable:: Maximum call retries

:objective: To inform about the number of times a call should be
retried
:description: An integer value
:type: MaximumCallRetries
:format: Integer
:protocol: System parameter
:equivalence_class:[0 10], ]10 inf[

11. Developed components 199 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.1 Sensor box hardware

Important: This component is included in the iEVC Sensor kit[ci]

11.1.1 Description

The Sensor box hardware hosts the components necessary to physically interface the iEVC on-board iEVC sub-
system with its sensors, as well as test them:
• 2 (two) iODO[ci] (referred to as iODO-1 and iODO-2 in this section);
• 1 iODO BITE[ci];
• 1 iBTM-TX[ci];
• 2 (two) iBTM-RX[ci] (referred to as RX-1 and RX-2 in this section);
• 2 (two) Sensor Box Power Supply[ci];
• 1 Sensor box ethernet switch[ci];
The box protects the hosted components from external conditions (dust, water), therefore allowing installation in
the train. Through its external interfaces it also provides the required connections to the sensors.

Figure 11.1: Sensor box physical architecture overview

The iEVC On-board subsystem can be operated using 1 Euroantenna per cabin/desk. In this case 2 Sensor box[ci]
are used. Each box uses its own Euroantenna. The Sensor boxes can be associated either to cab A or cab B. When
the iBTM component exchanges messages with the Safe computer, each message must indicate the associated
cabin. Specific Euroantenna cables are used for cab A and cab B. They use coded connectors to allow the iBTM
components to detect their associated installation cabin.

200 of 750 11.1. Sensor box hardware

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.1.2 Modes

The Sensor box hardware[ci] has no mode.

11.1.3 Functions

The Sensor box hardware[ci] in itself does not implement any system function.
The Sensor Box Power Supply[ci], inside the box, implements the following functions:

11.1.3.1 [IEVC.F4.28.11] Sensor box power supply - Provide maintenance and fault information
[function]

Data
• Definition: Provide maintenance and fault information about the Sensor box power supply
• Allocated to:
– Sensor Box Power Supply[ci]
• Input:
– Power supply Maintenance Data request[functional variable]
• Output:
– Power supply Maintenance Data[functional variable]
• Sil: basic

11.1.3.2 [IEVC.F8.01] Supply power to the Sensor box [function]

Data
• Definition: This function allows supplying the required power to the components of the Sensor box.
• Allocated to:
– Sensor Box Power Supply[ci]
• Sil: basic
• Associated interface:
– Sensor box - Power supply interface[ci]

11.1.4 Interface

The Sensor box is a pure hardware components, therefore providing only physical interfaces.
There are two types of physical interfaces:
• External: for the cables between hosted components and peripherals/components outside of the Sensor box.
The related connectors are grouped on the front panel of the Sensor box.
• Internal: for the physical interfaces between the components inside the Sensor box.

11.1. Sensor box hardware 201 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.1.4.1 External interfaces

Figure 11.2: Sensor box front panel

The following external physical interfaces are applicable to the Sensor box hardware:
• Sensor Box Power Supply[ci] (power plugs)
• Sensor box - Euroantenna interface[ci] (Euroantenna connector). This interface informs the Sensor box
about the cab it is allocated to thanks to specific pins on the connector;
• Sensor box - Pulse generator interface[ci] (pulse generator connector)
• Sensor box - Secondary sensor interface[ci] (secondary sensor connector)
• Sensor box - Loopback interface[ci] (PG sensor 3 loopback connector)
• Sensor box - Pulse generator BITE interface[ci] (PG BITE connector)
• Sensor box - Secondary sensor BITE interface[ci] (secondary BITE connector)
• Sensor box - V1V2 interface[ci] (V1/V2 serial links connector)
• Sensor box - Ethernet interface[ci] (Ethernet ports)
• Grounding point

11.1.4.2 Internal interfaces

Configuration Item

• power supply from the internal power adapter;
• connection to ground;
• Ethernet link with the internal network switch;
• link with 2 pulse generator channel pairs (6 wires) on the PG cable connector (note that one of the
link may be unused);
• link with a secondary sensor pulse generator (6 wires) for iODO1 and serial link (3 wires) for iODO2
on the secondary sensor cable connector (note that this link may be unused)
• a connection with an identification dongle that allows each iODO module to know if it is iODO-1
or iODO-2;

11.1. Sensor box hardware 203 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Configuration Item

Sensor box - iODO BITE interface [ci]

Data
• Sil: basic

The following connections are necessary to have an operational iODO BITE component:
• power supply from the internal power adapter;
• connection to ground;
• Ethernet link with the internal network switch;
• link with V1 serial link connector;
• link with V2 serial link connector;
• link with pulse generator BITE connector;
• link with secondary sensor BITE connector.

Configuration Item

Sensor box - Power adapter internal interface [ci]

Data
• Sil: basic

The following connections are necessary to have an operational power adapter:

• connection to ground;
• link with the front panel connector for external power supply, controlled by the power switch on the
front panel;
• Ethernet link with the internal network switch (for monitoring purposes).
• link with the other component to power

Configuration Item

Sensor box - Network switch internal interface [ci]

Data
• Sil: basic

The following connections are necessary to have an operational network switch:

• 2 power supply from the internal power adapter
• connection to ground
• 2 link with the Ethernet connectors on the front panel
• 8 Ethernet link with internal components of the Sensor box

204 of 750 11.1. Sensor box hardware

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.1.5 Requirements

11.1.5.1 Connectors

Requirement

The Sensor box front panel shall have a 12 pin connector to the Euroantenna [id:tsc-req-ievc-sensorbox-
connector-euroantenna][p2][ns]

The suggested connector name is EUROANTENNA

There are 4 loops in the Euroantenna, each requiring 2 pins. There are 4 pins dedicated to the installed
cabin information.
Suggested pin names:
• TX-LOOP+ : Transmission loop +
• TX-LOOP- : Transmission loop -
• RX1-LOOP+ : First reception loop +
• RX1-LOOP- : First reception loop -
• RX2-LOOP+ : Second reception loop +
• RX2-LOOP- : Second reception loop -
• TEST-LOOP+ : Test loop +
• TEST-LOOP- : Test loop -
• CAB-A+ : Cabin A +
• CAB-A- : Cabin A -
• CAB-B+ : Cabin B +
• CAB-B- : Cabin B -
When 2 Euroantenna are used, the Euroantenna cable used for Cab A shunts the Cabin A pins and the the
Euroantenna cable used for Cab B shunts the Cabin B pins.

Requirement

The Sensor box front panel shall have 2 Ethernet port connectors [id:tsc-req-ievc-sensorbox-connector-
eth][p2][ns]

The suggested connectors names are ETH1 and ETH2

Requirement

The Sensor box front panel shall have a 24 pin connector to the wheel pulse generator [id:tsc-req-ievc-
sensorbox-connector-pg][p2][ns]

The suggested connector name is PG

4 pins are required for each channel of the pulse generators. There are 6 channels working in pairs, hence
24 pins. The suggested pinout names are:
• PG-CH1-PW : Pulse signal 1 power
• PG-CH1-GND : Pulse signal 1 ground
• PG-CH1-SIG : Pulse signal 1 signal

11.1. Sensor box hardware 205 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• PG-CH1-SCR : Pulse signal 1 screen

• PG-CH2-PW : Pulse signal 2 power
• PG-CH2-GND : Pulse signal 2 ground
• PG-CH2-SIG : Pulse signal 2 signal
• PG-CH2-SCR : Pulse signal 2 screen
• PG-CH3-PW : Pulse signal 3 power
• PG-CH3-GND : Pulse signal 3 ground
• PG-CH3-SIG : Pulse signal 3 signal
• PG-CH3-SCR : Pulse signal 3 screen
• PG-CH4-PW : Pulse signal 4 power
• PG-CH4-GND : Pulse signal 4 ground
• PG-CH4-SIG : Pulse signal 4 signal
• PG-CH4-SCR : Pulse signal 4 screen
• PG-CH5-PW : Pulse signal 5 power
• PG-CH5-GND : Pulse signal 5 ground
• PG-CH5-SIG : Pulse signal 5 signal
• PG-CH5-SCR : Pulse signal 5 screen
• PG-CH6-PW : Pulse signal 6 power
• PG-CH6-GND : Pulse signal 6 ground
• PG-CH6-SIG : Pulse signal 6 signal
• PG-CH6-SCR : Pulse signal 6 screen

Requirement

The Sensor box front panel shall have a 15 pin connector to the secondary sensor [id:tsc-req-ievc-
sensorbox-connector-secondary][p2][ns]

The suggested connector name is SEC

6 pins for two speed-proportional pulse signals, 3 pins for a RS 485 unidirectional serial link, and 6 pins
to code the type of secondary sensor (provision for future use). The suggested pinout names are:
• SEC-SER-RX+ : Serial link RX+
• SEC-SER-RX- : Serial link RX-
• SEC-SER-GND : Serial link GND
• SEC-CH1-PW : Pulse signal 1 power
• SEC-CH1-GND : Pulse signal 1 ground
• SEC-CH1-SIG : Pulse signal 1 signal
• SEC-CH2-PW : Pulse signal 2 power
• SEC-CH2-GND : Pulse signal 2 ground
• SEC-CH2-SIG : Pulse signal 2 signal
• SEC-TYP-ID0+ : Coding input ID0+

206 of 750 11.1. Sensor box hardware

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• SEC-TYP-ID0- : Coding input ID0-

• SEC-TYP-ID1+ : Coding input ID1+
• SEC-TYP-ID1- : Coding input ID1-
• SEC-TYP-ID2- : Coding input ID2+
• SEC-TYP-ID2- : Coding input ID2-
The coding inputs ID0, ID1 and ID2 are provisions for future use in order to identify other types of
secondary sensor connected to the Sensor box. In the current version of the system, and while a Corrail
sensor is being used as secondary source of speed measurement, the secondary sensor cable connector
shall leave these 3 inputs free (not connected).

Note: In the future, when another type of sensor than the Corrail sensor will be used, the secondary
sensor cable connector will need to shunt one or several of the coding inputs in order for the iODO boards
to identify the specific type of sensor.

Requirement

The Sensor box front panel shall have a 18 pin pulse generator BITE connector [id:tsc-req-ievc-
sensorbox-connector-bite-pg][p2][ns]

The suggested connector name is BITE-PG.

The connector should match the PG connector.
The suggested pinout names are:
• BITE-PG-CH1-PW : Pulse signal 1 power
• BITE-PG-CH1-GND : Pulse signal 1 ground
• BITE-PG-CH1-SIG : Pulse signal 1 signal
• BITE-PG-CH2-PW : Pulse signal 2 power
• BITE-PG-CH2-GND : Pulse signal 2 ground
• BITE-PG-CH2-SIG : Pulse signal 2 signal
• BITE-PG-CH3-PW : Pulse signal 3 power
• BITE-PG-CH3-GND : Pulse signal 3 ground
• BITE-PG-CH3-SIG : Pulse signal 3 signal
• BITE-PG-CH4-PW : Pulse signal 4 power
• BITE-PG-CH4-GND : Pulse signal 4 ground
• BITE-PG-CH4-SIG : Pulse signal 4 signal
• BITE-PG-CH5-PW : Pulse signal 5 power
• BITE-PG-CH5-GND : Pulse signal 5 ground
• BITE-PG-CH5-SIG : Pulse signal 5 signal
• BITE-PG-CH6-PW : Pulse signal 6 power
• BITE-PG-CH6-GND : Pulse signal 6 ground
• BITE-PG-CH6-SIG : Pulse signal 6 signal

11.1. Sensor box hardware 207 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Note: Screen pins are not needed at BITE connector side because the screening is in the cable. There
will be 4 pins at box side and 3 pins at sensor side for each channel.

Requirement

The Sensor box front panel shall have a 9 pin secondary sensor BITE connector [id:tsc-req-ievc-
sensorbox-connector-bite-secondary][p2][ns]

The suggested connector name is BITE-SEC

The connector should match the SEC connector.
The suggested pinout names are:
• BITE-SEC-SER-RX+ : Serial link RX+
• BITE-SEC-SER-RX- : Serial link RX-
• BITE-SEC-SER-GND : Serial link GND
• BITE-SEC-CH1-PW : Pulse signal 1 power
• BITE-SEC-CH1-GND : Pulse signal 1 ground
• BITE-SEC-CH1-SIG : Pulse signal 1 signal
• BITE-SEC-CH2-PW : Pulse signal 2 power
• BITE-SEC-CH2-GND : Pulse signal 2 ground
• BITE-SEC-CH2-SIG : Pulse signal 2 signal

Requirement

When installed on the train, the Sensor box front panel shall be accessible to the maintainer in order
to allow modifying the cabling to test the odometry through the iODO BITE function. [id:tsc-req-
ievc-sensorbox-connector-bite-access][p2][ns]

Requirement exported to the Installation designer.

Requirement

The Sensor box front panel shall have a 6 pin pulse generator loopback connector [id:tsc-req-ievc-
sensorbox-connector-loopback][p2][ns]

The suggested connector name is PG-LOOPBACK.

• PG-LOOPBACK-CH1-PW : Pulse signal 1 power loopback
• PG-LOOPBACK-CH1-GND : Pulse signal 1 ground loopback
• PG-LOOPBACK-CH1-SIG : Pulse signal 1 signal loopback
• PG-LOOPBACK-CH2-PW : Pulse signal 2 power loopback
• PG-LOOPBACK-CH2-GND : Pulse signal 2 ground loopback
• PG-LOOPBACK-CH2-SIG : Pulse signal 2 signal loopback

Note: Screen pins are not needed at PG Loopback connector side because the screening is in the cable.

Requirement

The maximum power consumption of the Sensor box Ethernet switch shall be 30W or less. [id:tsc-
req-ievc-hw-sensor-switch-power][p2][ns]

Requirement

The maximum power consumption of a iODO component shall be 5W or less [id:tsc-req-ievc-hw-iodo-

power][p2][ns]

11.1. Sensor box hardware 209 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The maximum power consumption of a iODO-BITE component shall be 5W or less [id:tsc-req-ievc-

hw-iodo-bite-power][p2][ns]

Requirement

The Sensor box shall contain two power supply components [id:tsc-req-ievc-sensorbox-ibtm-ps-
redundant][p1][ns]

Requirement

The two iBTM-RX components in the Sensor box shall be fed by two independent power supplies.
[id:tsc-req-ievc-sensorbox-ibtm-rx-powersupply-independence][p1][ns]

Requirement

Each iBTM-RX shall use its own RX loop independent from other loops of the Euroantenna. [id:tsc-
req-ievc-sensorbox-rxloop][p1][ns]

Requirement

The two iODO components in the Sensor box shall be fed by two independent power supplies.
[id:tsc-req-ievc-sensorbox-iodo-powersupply-independence][p1][s]

Requirement

The output of Sensor box power adapter shall be galvanically isolated and shall not float and shall
be referenced to an earth point. [id:tsc-req-ievc-sensorbox-iodo-powersupply-galvanically-isolated][p2][s]

The power adapter output shall be referenced to an earth point.

11.1.5.3 Redundancy requirements

Requirement

The Sensor box shall contain two iBTM-RX components [id:tsc-req-ievc-sensorbox-ibtm-rx-

redundant][p1][s]

These 2 iBTM-RX components allow having 2 independent balise up-link signal acquisition chains. The
ETCS system places strong requirements on the availability of the balise reading function. The reason is
that missing a balise can result into a hazardous situation. Therefore, it is required that both RX and TX
functions do not fail without going unnoticed.

Requirement

The Sensor box shall contain two iODO components [id:tsc-req-ievc-sensorbox-iodo-redundant][p1][s]

Because the wheel sensors only provide physical signals, failure of the iODO board may be mistaken for
a train at standstill. Therefore, the iODO board need to be duplicated to discriminate failure of a board
from standstill.

210 of 750 11.1. Sensor box hardware

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

If their clock source is external (e.g. crystal oscillator), the two iBTM-RX components in the Sensor
box shall not share the same clock source. [id:tsc-req-ievc-sensorbox-ibtm-rx-clock-independence][p1][s]

This implies no common mode on their internal clock.

Requirement

The Sensor box power supply shall provide maintenance and faults information to the OBOM
[id:tsc-req-ievc-ob-sb-hw-psu-maintenance-and-faults][p2][ns]

The reported faults shall include at least too low and too high voltage.

11.1.6 Failure modes

The Sensor box hardware[ci] is only a recipient of other components. It has no failure mode.

11.2 iBTM-TX module

Important: This component is included in the iEVC Sensor kit[ci]

11.2.1 Description

The iBTM-TX component produces the Tele-powering signal that feeds the Tele-powering loop of the Euroan-
tenna.
The iBTM-TX component reads back the Tele-powering signal from filtering the 27 MHz band induced current
in the test loop of the Euroantenna.
The iBTM-TX component produces a test signal that emulates an Up-link signal and feeds this signal to the test
loop of the Euroantenna. This test is called ‘iBTM test’. During the iBTM test sequence the Tele-powering is
turned off. There are 3 types of iBTM test corresponding to 3 types of test signal:
• Eurobalise test signal: it is a signal modulated using Frequency Shift Keying (FSK) between a nominal low
frequency of 3.951 MHz and a nominal high frequency of 4.516 MHz (refer to [SyAD-R9-SS36] for more
information).
• KER test signal: this signal uses a 4.5 MHz carrier modulated in amplitude (ASK) by 50 kHz pulses. The
amplitude is decreasing exponentially during the pulse (refer to [SyAD-R28-SS100] for more information).
• Euroloop test signal: this signal uses a 13.5 MHz carrier modulated using a Direct Sequence Spread Spec-
trum (DSSS) scheme. Each binary data symbol shall be Differential Binary Phase Shift Keying (DBPSK)
modulated with a complete period of the Spread Spectrum Code (refer to [SyAD-R50-SS44] for more in-
formation).
The iBTM-TX component mode is controlled by the iBTM application. The iBTM-TX communicates with the
iBTM application through its interface with the iBTM driver. The iBTM driver is in charge of the synchronization
mechanism. It verifies the integrity and freshness of the messages transmitted by the iBTM-TX by implementing
the Sensor Interface Common Protocol (refer to [SyAD-R74-SIF-Sensor-interface]). The iBTM-TX component
returns its status including the Tele-powering detection information to the iBTM application through the same
interface.
The logical architecture of the iBTM-TX and its interactions with the other components are described in Fig. 11.3

11.2. iBTM-TX module 211 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.3: iBTM-TX logical architecture

Note: the ‘test Up-link magnetic field’ is transmitted over the air inside the Euroantenna unit between the test
loop and one of the RX loops.

11.2.2 Modes

The iBTM-TX modes are:

• Continuous Wave Tele-powering mode (CW): uses a fixed amplitude signal with frequency of 27.095 MHz
with a tolerance of ±5 kHz
• Toggling Tele-powering mode (TM): the 27.095 MHz Tele-powering signal is pulse width modulated by a
50 kHz synchronization signal where every other modulation pulse is longer
• Non Toggling Tele-powering mode (NT): the 27.095 MHz Tele-powering signal is amplitude modulated
with a 50 kHz synchronization signal where each modulation pulse has the same length
• Tele-Powering OFF (Off): No Tele-powering signal is produced.

212 of 750 11.2. iBTM-TX module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Test mode: In this mode the Tele-powering signal is turned OFF. The iBTM-TX emulates an Up-link signal
that feeds the test loop of the Euroantenna.
Upon reception of iBTM test message[functional variable][VM - iBTM-TX interface][VM - Applications inter-
face] the iBTM-TX switches to test mode. While in this mode it transmits the test signal to the test loop of the
Euroantenna. The test signal is an Up-link signal containing the test telegram received from the iBTM applica-
tion in the iBTM test message[functional variable][VM - iBTM-TX interface][VM - Applications interface]. The
iBTM-TX exits the test mode when receiving a Tele-powering setup message[functional variable][VM - iBTM-TX
interface][VM - Applications interface]. The new Tele-powering mode is selected based on the content of this new
setup message.
Any other transition is triggered only by the Tele-powering mode commanded in Tele-powering setup mes-
sage[functional variable][VM - iBTM-TX interface][VM - Applications interface]. The initial mode at start-up
is Tele-Powering OFF.
• The function [IEVC.F3.02.07.04] Generate Tele-powering signal[function] is inactive in Tele-Powering
OFF and test mode.
• The function [IEVC.F3.02.07.06] Generate test signal[function] is only active in test mode.
• The other functions are active in all modes.

From To Condition
Any CW reception of Tele-powering setup message[functional variable][VM - iBTM-TX interface][VM
mode - Applications interface] with mode = ‘Continuous wave’
Any TM reception of Tele-powering setup message[functional variable][VM - iBTM-TX interface][VM
mode - Applications interface] with mode = ‘Toggling Mode’
Any NT reception of Tele-powering setup message[functional variable][VM - iBTM-TX interface][VM
mode - Applications interface] with mode = ‘Non-Toggling Mode’
Any Off reception of Tele-powering setup message[functional variable][VM - iBTM-TX interface][VM
mode - Applications interface] with mode = ‘Off’
Any Test reception of iBTM test message[functional variable][VM - iBTM-TX interface][VM - Applica-
mode tions interface]

Note: the different messages are described in [SyAD-R56-SIF-iBTM-VM]

11.2.3 Functions

11.2.3.1 [IEVC.F3.02.07.04] Generate Tele-powering signal [function]

Data
• Definition: The iBTM-TX component is in charge of the generation of the Tele-powering signal to
feed the TX loop of the Euroantenna. The iBTM application sends the iBTM-TX a Tele-powering
setup message to select the Tele-powering mode.
• Allocated to:
– iBTM-TX[ci]
• Input:
– Tele-powering setup message[functional variable][VM - iBTM-TX interface][VM - Applica-
tions interface]
– Stop Tele-powering[functional variable]
• Output:
– Tele-powering signal[functional variable][Tele-powering loop interface]

11.2. iBTM-TX module 213 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– Stop iBTM test[functional variable]

• Sil: basic
• Associated interface:
– VM - iBTM-TX interface[ci]
– Tele-powering loop interface[ci]

11.2.3.2 [IEVC.F3.02.07.05] Read back Tele-powering signal [function]

Data
• Definition: The iBTM-TX component filters the signal from the test loop of the Euroantenna in the
Tele-powering frequency band and measures its characteristics. The frequency, level and detected
mode is provided to the iBTM application as a readback to control the effectiveness of the Tele-
powering. The message provided to the iBTM application contains the associated installed cabin
information. This information is useful when there is one installed Euroantenna per cabin or desk.
This function also provides the iBTM-TX software and hardware versions in the status message.
• Allocated to:
– iBTM-TX[ci]
• Input:
– Tele-powering readback[functional variable][Test loop interface]
– Associated installed cabin[functional variable][Sensor box - Euroantenna interface]
– iBTM synchronization message[functional variable][VM - iBTM-RX interface][VM - iBTM-
TX interface]
• Output:
– iBTM-TX status message[functional variable][VM - iBTM-TX interface][VM - Applications
interface]
– iBTM synchronization message[functional variable][VM - iBTM-RX interface][VM - iBTM-
TX interface]
• Sil: basic
• Associated interface:
– VM - iBTM-TX interface[ci]
– Test loop interface[ci]
– Sensor box - Euroantenna interface[ci]

This function allows detecting the presence of Big Metal Masses (BMM) along the track that could disturb the
Tele-powering emission and therefore the correct transmission of balise or loop information.

214 of 750 11.2. iBTM-TX module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.2.3.3 [IEVC.F3.02.07.06] Generate test signal [function]

Data
• Definition: The iBTM-TX component is in charge of the generation of the test signal that feeds
a specific test loop of the Euroantenna. The test is enabled by the iBTM application. The iBTM
application provides the test bitstream to be used in the signal. 3 types of signal can be produced:
Eurobalise, KER and Euroloop signals.
• Allocated to:
– iBTM-TX[ci]
• Input:
– iBTM test message[functional variable][VM - iBTM-TX interface][VM - Applications inter-
face]
– Stop iBTM test[functional variable]
• Output:
– Test signal[functional variable][Test loop interface]
– Stop Tele-powering[functional variable]
• Sil: basic
• Associated interface:
– VM - iBTM-TX interface[ci]
– Test loop interface[ci]

11.2.3.4 [IEVC.F3.02.07.17] Configure iBTM-TX network connection [function]

Data
• Definition: Based on the cabin, determine the network address of the iBTM-TX component.
• Allocated to:
– iBTM-TX[ci]
• Input:
– Associated installed cabin[functional variable][Sensor box - Euroantenna interface]
• Sil: basic
• Associated interface:
– Sensor box - Euroantenna interface[ci]

The address to use, depending on the installed cabin is provided in section Network architecture.

11.2. iBTM-TX module 215 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.2.3.5 [IEVC.F4.32.13] Reset iBTM-TX [function]

Data
• Definition: The iBTM-TX component resets itself upon reception of a reset order from the iBTM
driver
• Allocated to:
– iBTM-TX[ci]
• Input:
– iBTM-TX reset order[functional variable][VM - iBTM-TX interface]
• Sil: basic
• Associated interface:
– VM - iBTM-TX interface[ci]

Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional architecture.

11.2.4 Interface

• Tele-powering loop interface[ci]

This is the physical interface between the iBTM-TX and the Tele-powering loop of the Euroan-
tenna. The Tele-powering loop is used to produce signal in 3 different modes:
– Continuous wave (CW)
– Toggling Mode (TM)
– Non Toggling (NT)
• Test loop interface[ci]
This is the physical interface between the iBTM-TX and the test loop of the Euroantenna.
• VM - iBTM-TX interface[ci]
This interface is used to exchange messages between the iBTM driver and the iBTM-TX module
over ethernet and after synchronization of the 2 components. The exchanged messages are:
– Tele-powering setup message[functional variable][VM - iBTM-TX interface][VM - Appli-
cations interface]
– iBTM-TX status message[functional variable][VM - iBTM-TX interface][VM - Applications
interface]
– iBTM test message[functional variable][VM - iBTM-TX interface][VM - Applications inter-
face]
– iBTM synchronization message[functional variable][VM - iBTM-RX interface][VM - iBTM-
TX interface]
– iBTM-TX reset order[functional variable][VM - iBTM-TX interface]
The following messages are used internally to the iBTM-TX module component:

Functional Variable
Stop Tele-powering [functional variable]

216 of 750 11.2. iBTM-TX module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To stop the Tele-powering during the iBTM test
• Description: message internal to the iBTM-TX component that commands if the Tele-
powering must be stopped or not
• Family: Software
• Format: boolean
• Timing constraints: Event
• Produced by:
– [IEVC.F3.02.07.06] Generate test signal[function]
• Consumed by:
– [IEVC.F3.02.07.04] Generate Tele-powering signal[function]

Functional Variable
Stop iBTM test [functional variable]
Data
• Objective: To stop the iBTM test when a new Tele-powering setup message is received
• Description: message internal to the iBTM-TX component that commands if the iBTM test
must be stopped or not
• Family: Software
• Format: boolean
• Timing constraints: Event
• Produced by:
– [IEVC.F3.02.07.04] Generate Tele-powering signal[function]
• Consumed by:
– [IEVC.F3.02.07.06] Generate test signal[function]

11.2.5 Parameters

Functional Variable
Tele-powering level [functional variable]

11.2. iBTM-TX module 217 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To set the nominal power level of the Tele-powering signal
• Description: Power amplification level of the Tele-powering signal
• Family: Hardware
• Type: IBTMTXTele-poweringLevel
• Format: Real
• Protocol: System Parameter

Note: Unit and range must be specified during the component detailed design.

• The off-edge of the signal shall be constant in phase, with less than ±0.1𝑠 jitter.

218 of 750 11.2. iBTM-TX module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• The modulation depth, (a-b)/a, shall be 100 %, +0/-50 %.

• The pulse width, t, shall be defined at 50 % of the actual modulation depth, c=(a+b)/2.
• The pulse width, t, shall be between 2.0 µs and 3.5 µs.
• Within the defined limits of t, the pulse width shall alternate between two different values, counted
from the off-edge to the on-edge. The difference between the two values of pulse width shall be 1.2
µs, +0.3/-0.4 µs.
• The overshoot, (d-a)/a, shall not exceed 10 %.
• After the time 𝑡𝑚𝑎𝑥 ≤ 7𝑠 the amplitude a shall not vary more than ±0.5 %.

Requirement

The iBTM-TX shall provide Non Toggling (NT) Tele-powering signal when in Non Toggling mode.
[id:tsc-req-ievc-ibtm-tx-tp-nt][p1][ns]

This signal feeds the Tele-powering loop of the Euroantenna.

Requirement

The non-toggling mode signal from the iBTM-TX shall have the characteristics described in Subset
100 §3.1.3. [id:tsc-req-ievc-ibtm-tx-tp-nt-characteristics][p1][ns]

Requirement

The iBTM-TX shall select the Tele-powering mode between CW, TM, NT or Off according to the
command included in the iBTM Tele-powering setup message received from the iBTM driver (the
message is originally produced by the iBTM application) unless an iBTM test is on-going. When
an iBTM test is on-going, the Tele-powering mode shall be set to Off. [id:tsc-req-ievc-ibtm-tx-tp-
setup][p3][s]

The Tele-powering signal is generated according to the selected iBTM-TX mode.

The Tele-powering mode is switched Off also when an iBTM test in on-going (refer to tsc-req-ievc-ibtm-
tx-tp-off-for-autotest[req]).

Requirement

In order to achieve compatibility with old types of KER balises, the maximum flux from the Eu-
roantenna shall be 200 nVs in a Standard Size Reference Area positioned at a vertical distance of 93
mm below the top of rail. [id:tsc-req-ievc-ibtm-tx-ker-tp-flux-compatibility][p1][ns]

The respective flux levels refer to a CW Tele-powering flux level where the KER balises shall not be
destroyed or degraded. The heights refer to the vertical position of the Standard Size Reference Area, and
during testing the Test Antenna shall be positioned at respectively 220 mm and 277 mm above the KER
balise.

Requirement

The iBTM-TX and Euroantenna shall guarantee that, in all possible operational conditions, the
magnetic flux concatenated with the balise reference areas (standard size, reduced size, and reduced
size with transversal installation) never exceeds the applicable maximum Tele-powering magnetic
flux value (“phid4”, see sub-clause 5.2.2.6 in Subset 036), in both CW and TM mode, when the balise
impedance fulfils the requirements of sub-clause 5.2.2.6 of Subset 036. [id:tsc-req-ievc-ibtm-tx-tp-max-
flux][p1][s]

11.2. iBTM-TX module 219 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The iBTM-TX shall use a constant power level for Tele-powering. [id:tsc-req-ievc-ibtm-tx-tp-power-
level][p1][s]

The iBTM-TX shall not allow to adjust or modify the power level during operation. The supplier shall
specify the tolerable fluctuation on the target Tele-powering level. This tolerance shall be agreed with
TSC.

Requirement

It shall not be possible to modify the Tele-powering level after its adjustment in factory. [id:tsc-req-
ievc-ibtm-tx-tp-power-level-modification][p1][s]

Requirement

The iBTM shall be designed to be robust against air-gap disturbance that could lead to the non-
detection of a balise, an erroneous balise detection or the corruption of the telegram. [id:tsc-req-ievc-
ibtm-tx-robust-design-ag-disturbance][p1][s]

For failures related to air-gap noise, the actual worst case situation shall be considered if known, otherwise
any ratio of random bit error rate applies.

Requirement

The total attenuation from the Euroantenna Tele-powering to the received signal level of the Up-
link signal shall under the worst case condition (i.e., highest possible efficiency according to Figure
16 of sub-clause 5.2.2.6 in Subset 036, and in presence of nearby cables, guard rails, and debris)
be more than the ratio between the maximum Tele-powering signal level in the Euroantenna and
the minimum value of the Up-link receiver threshold field strength Vth. [id:tsc-req-ievc-ibtm-tx-
attenuation][p1][s]

Requirement

The Tele-powering field generated by the iBTM-TX and the Euroantenna in the worst case Tele-
powering field condition shall be low enough not to activate a balise in a cross-talk protected zone
(as defined in Table 1 of Subset 036) to a level that the Up-link signal is correctly received by the
Euroantenna. [id:tsc-req-ievc-ibtm-tx-cross-talk][p1][s]

The worst case situation for the On-board Equipment and for air-gap propagation shall be considered. The
cross-talk protection zone is defined by Table 1 of Subset 036. The worst case for the balise input-to-output
characteristic and field conformity shall be considered, see Figure 16, Figure 14, and Figure 15 in Subset
036. The conformity tolerance B in Figure 14 and Figure 15 of Subset 036 shall be considered for the
balise for Up-link in the balise cross-talk zone. Cross-talk shall be evaluated considering all constraints
regarding the installation requirements.

Requirement

A mean figure of 10^6 balise passages with error free telegrams delivered to the iBTM application
shall be ensured. [id:tsc-req-ievc-ibtm-tx-availability-1][p1][s]

This applies within the entire range of environmental conditions and train speeds specified in Subset 036.

220 of 750 11.2. iBTM-TX module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The iBTM-TX and Euroantenna shall limit the induction into suitable test cables, which assume
that the return current is passing at 0.5 m below the cable under consideration, so forming a vertical
loop underneath the Euroantenna, and presenting a characteristic impedance of 400 ohm. The two
extremities of the loop shall be closed by the characteristic impedance. This loop shall be checked
with longitudinal and transversal orientation with respect to the Euroantenna. The maximum value
of the current at the position of best coupling, and at the minimum height (specified by the supplier)
for the Euroantenna, shall be according to one of the classes defined below. [id:tsc-req-ievc-ibtm-tx-
cables-induced-currents-tests][p1][ns]

Class Current
1 < 10 mA
2 < 25 mA

The maximum induced current is considered excluding conductive loop cable. Class 1 is applicable to a
mounting condition where cables between the rails are positioned at a height equal to or lower than 493
mm below the top of the rail. Class 2 is applicable when cables between the rails are positioned at a height
equal to or lower than 93 mm below the top of the rail.

Requirement

The iBTM-TX and Euroantenna shall be able to handle induced Up-link currents in a LZB loop ca-
ble, from a Balise, not exceeding 0.3 mA. [id:tsc-req-ievc-ibtm-tx-cables-induced-currents-lzb-loop][p1][ns]

The conductive LZB loop cable is defined in sub-clause 5.7.10.7.1 of Subset 036. The center of the LZB
cable is always positioned more than 75 mm below the top of rail during co-existence with Eurobalise.
The above stated current level is applicable using the reference set-up defined in Subset 085 (defining an
impedance level of 75 ohm and a vertically oriented loop emulating the real LZB cable).

Requirement

The iBTM-TX and Euroantenna shall limit the Tele-powering induction into the reference set-up
defined in Subset 085. The maximum value of the current at the position of best coupling, and at
the minimum supplier specific height for the Euroantenna, shall not exceed 250 mA in installations
where the center of the LZB cable is always positioned more than 105 mm below the top of the
rail; and 400 mA in installations where the center of the LZB cable is anywhere along the track
positioned within the interval 75 mm to 105 mm below the top of rail. [id:tsc-req-ievc-ibtm-tx-cables-
induced-currents-ss85][p1][ns]

The LZB cable shall not be installed higher than 75 mm below the top of the rail when coexistence with
Eurobalise is required.

Requirement

Once a iBTM-TX component has synchronized with the iBTM driver in the Virtual Machine, it
will not resynchronize with any other component until the next shut-down. [id:tsc-req-ievc-ibtm-tx-
synchronization][p3][ns]

Requirement

The iBTM-TX shall implement a Tele-powering detection to assert that the Tele-powering magnetic
field is generated correctly by the Euroantenna. [id:tsc-req-ievc-ibtm-tx-tp-readback][p1][s]

11.2. iBTM-TX module 221 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The readback is realized through the filtering of the Tele-powering frequency on the signal picked up by
the test loop. If the transmitted level of the Tele-powering signal is so low that balises may not be detected
by the iBTM-RX, this error shall be detected by analyzing the readback signal. If the level of the Tele-
powering signal is so high that it may generate cross-talk, this error shall be detected by analyzing the
readback signal.

Requirement

The iBTM-TX shall include the associated installed cabin information in all the messages sent to the
Virtual Machine. [id:tsc-req-ievc-ibtm-tx-installed-cabin][p3][ns]

This information is included in the iBTM message body (see iBTM - Virtual Machine Interface Specifica-
tion) and is computed based on the electric signal detected on specific pins of the Euroantenna connector
at Sensor box side (see iBTM - Euroantenna Interface Specification). There are specific pairs of pins for
cab A and cab B installation. These pins may be shunted by the Euroantenna cable connector. There are
therefore 2 types of Euroantenna cables depending on the associated cabin. When no installed cabin can
be detected from the Sensor box connector, the iBTM-TX shall use the value Unknown (when none or
both pairs of pin are shunted).

Requirement

The iBTM-TX Tele-powering detection shall measure the frequency of the Tele-powering compo-
nent. [id:tsc-req-ievc-ibtm-tx-tp-readback-frequency][p1][s]

Requirement

The iBTM-TX Tele-powering detection shall measure the level of the Tele-powering component.
[id:tsc-req-ievc-ibtm-tx-tp-readback-level][p1][s]

Requirement

The iBTM-TX Tele-powering detection shall characterize the modulation in use (CW, TM, NT, Un-
known). [id:tsc-req-ievc-ibtm-tx-tp-readback-tp-modulation][p2][s]

Requirement

The iBTM-TX shall provide the Tele-powering detection information on its interface with the iBTM
driver. [id:tsc-req-ievc-ibtm-tx-tp-detection-report][p3][s]

The Tele-powering detection information is included in “iBTM-TX status message”

The effect is that no consistent Tele-powering detection information is contained in the iBTM-TX status mes-
sage[functional variable][VM - iBTM-TX interface][VM - Applications interface]. The iBTM application will
raise an iBTM alarm to the signalling application (subset 26 application or class B application).

11.2.7.3 Failure to Generate test signal

The effect is that no test signal can be read and decoded by the RX channels. The iBTM test will fail and the iBTM
application will raise an iBTM alarm to the signalling application (subset 26 application or class B application).

11.3 iBTM-RX module

Important: This component is included in the iEVC Sensor kit[ci]

11.3.1 Description

The iBTM-RX component is in charge of the Eurobalise, Euroloop and KER balise Up-link signal detection and
demodulation. The iEVC Sensor box is equipped with 2 independent iBTM-RX components. Each of them
acquire the Up-link signal through 2 independent loops in the Euroantenna.
Each iBTM-RX component is equipped with
• 2 different Eurobalise demodulation circuits called ‘Eurobalise demodulator A’ and ‘Eurobalise demodula-
tor B’.
• 2 different KER balise demodulation circuits called ‘KER demodulator A’ and ‘KER demodulator B’.
• 1 Euroloop demodulation circuit.
The iBTM-RX component returns the balise or loop detection and Up-link telegram information to the iBTM
application through its interface with the iBTM driver. The iBTM-RX component does not filter the telegram
information. The filtering is performed:
• in the iBTM application for Eurobalise side lobe and telegram coding consistency.
• in the Subset 026 Application for all the other application related filtering actions of the Eurobalise and
Euroloop data.
• in the KER Class B application[ci] for KER balise side lobe and telegram coding consistency.
The logical architecture of the iBTM-RX and its interactions with the other components are described in Fig. 11.4

11.3. iBTM-RX module 225 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.4: iBTM-RX logical architecture

Note: the messages are described in [SyAD-R56-SIF-iBTM-VM]

226 of 750 11.3. iBTM-RX module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.3.2 Modes

The iBTM-RX component does not manage any mode.

11.3.3 Functions

11.3.3.1 [IEVC.F3.02.07.07] Detect Up-link signal [function]

Data
• Definition: Each iBTM-RX component is in charge of detecting an Up-link signal transmission start
and end. There is a threshold within the iBTM-RX component that is based on a voltage representing
the received field strength (Vth). The voltage is measured on a RX loop of the Euroantenna. A
balise or loop detection message is provided by the iBTM-RX component to the iBTM application
to report transitions of type 'Off to On' (balise or loop entry) and 'On to Off' (balise or loop exit).
This function also provides a periodic status message to the iBTM application that contains the
iBTM-RX software and hardware versions.
• Allocated to:
– iBTM-RX[ci]
• Input:
– Up-link signal[functional variable][RX loop interface]
– Associated installed cabin[functional variable][Sensor box - Euroantenna interface]
• Output:
– Balise or loop detection message[functional variable][VM - iBTM-RX interface][VM - Appli-
cations interface]
– iBTM-RX status message[functional variable][VM - iBTM-RX interface]
• Sil: basic
• Associated interface:
– VM - iBTM-RX interface[ci]
– RX loop interface[ci]
– Sensor box - Euroantenna interface[ci]

11.3.3.2 [IEVC.F3.02.07.08] Demodulate the balise signal [function]

Data
• Definition: Whenever a balise or loop contact is detected, this function is in charge of the FSK and
ASK demodulation of the balise Up-link signal. The resulting iBTM Up-link telegram, if any, is
provided to the iBTM application.
• Allocated to:
– iBTM-RX[ci]
• Input:
– Detected balise or loop signal[functional variable]
– Up-link signal[functional variable][RX loop interface]
– iBTM synchronization message[functional variable][VM - iBTM-RX interface][VM - iBTM-

11.3. iBTM-RX module 227 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

TX interface]
– Associated installed cabin[functional variable][Sensor box - Euroantenna interface]
• Output:
– Up-link telegram message[functional variable][VM - iBTM-RX interface][VM - Applications
interface]
– iBTM synchronization message[functional variable][VM - iBTM-RX interface][VM - iBTM-
TX interface]
• Sil: basic
• Associated interface:
– VM - iBTM-RX interface[ci]
– RX loop interface[ci]
– Sensor box - Euroantenna interface[ci]

This telegram is repeated in the Eurobalise air-gap[ci] interface. The first message is sent after receiving 2 valid
identical telegrams, the second after 4, then 8, 16, and so on up to 256. This mechanism is used to reduce the
message traffic in case of low speed passage or stopping over the balise.
The Up-link telegram message[functional variable][VM - iBTM-RX interface][VM - Applications interface] is
described in [SyAD-R56-SIF-iBTM-VM].
Each demodulator sends its own instance of the message when a telegram is detected.
No telegram is demodulated by this function when processing an Euroloop Up-link signal.

11.3.3.3 [IEVC.F3.02.15.01] Demodulate the Euroloop signal [function]

Data
• Definition: Whenever a balise or loop contact is detected, this function is in charge of the Direct Se-
quence Spread Spectrum (DSSS) demodulation of the Euroloop Up-link signal. The demodulation
process uses a Spread Spectrum Code that is provided by the iBTM application. A default value
is used if no code value has been provided since the last component start-up. The resulting iBTM
Up-link telegram, if any, is provided to the iBTM application.
• Allocated to:
– iBTM-RX[ci]
• Input:
– Detected balise or loop signal[functional variable]
– Up-link signal[functional variable][RX loop interface]
– Associated installed cabin[functional variable][Sensor box - Euroantenna interface]
– Change of Spread Spectrum Code[functional variable][VM - iBTM-RX interface][VM - Ap-
plications interface]
• Output:
– Up-link telegram message[functional variable][VM - iBTM-RX interface][VM - Applications
interface]
• Associated interface:
– VM - iBTM-RX interface[ci]

228 of 750 11.3. iBTM-RX module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– RX loop interface[ci]
– Sensor box - Euroantenna interface[ci]

This function outputs an iBTM Up-link telegram message as in [IEVC.F3.02.07.08] Demodulate the balise sig-
nal[function] (refer to [SyAD-R56-SIF-iBTM-VM] for a description of the message).
The Euroloop telegrams are received continuously in the air-gap over the section of the track where the loop is
installed. The balise Up-link telegram reporting frequency remains applicable for Euroloop: after 2, 4, 8, 16, and
so on up to 256 valid identical telegrams.
The use of the Spread Spectrum Code to demodulate the signal is described in [SyAD-R50-SS44]. The default
Spread Spectrum Code value to use at start-up is 15 (reserved value not used in operation).
No telegram is demodulated by this function when processing an Eurobalise or KER balise Up-link signal.

11.3.3.4 [IEVC.F3.02.07.16] Configure iBTM-RX network connection [function]

Data
• Definition: Based on the cabin and its identification dongle, determine the network address of the
iBTM-RX component.
• Allocated to:
– iBTM-RX[ci]
• Input:
– Associated installed cabin[functional variable][Sensor box - Euroantenna interface]
• Sil: basic
• Associated interface:
– Sensor box - Euroantenna interface[ci]

The address to use, depending on the cab and the identification dongle, is provided in section Network architecture.

11.3.3.5 [IEVC.F4.32.14] Reset iBTM-RX [function]

Data
• Definition: The iBTM-RX component resets itself upon reception of a reset order from the iBTM
driver
• Allocated to:
– iBTM-RX[ci]
• Input:
– iBTM-RX reset order[functional variable][VM - iBTM-RX interface]
• Sil: basic
• Associated interface:
– VM - iBTM-RX interface[ci]

Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional architecture.

11.3. iBTM-RX module 229 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.3.4 Interface

• RX loop interface[ci]
• VM - iBTM-RX interface[ci]
This interface is used to exchange messages between the iBTM driver and the iBTM-RX module over
ethernet and after synchronization of the 2 components. The exchanged messages are:
• Balise or loop detection message[functional variable][VM - iBTM-RX interface][VM - Appli-
cations interface]
• Up-link telegram message[functional variable][VM - iBTM-RX interface][VM - Applications
interface]
• iBTM synchronization message[functional variable][VM - iBTM-RX interface][VM - iBTM-TX
interface]
• iBTM-RX status message[functional variable][VM - iBTM-RX interface]
• iBTM-RX reset order[functional variable][VM - iBTM-RX interface]
The following message is used internally to the iBTM-RX module component:

Functional Variable
Detected balise or loop signal [functional variable]
Data
• Objective: To inform that a balise or loop contact is detected and that the demodulation
function must be active.
• Description: message containing the information that a balise or loop contact is detected
• Family: Software
• Format: boolean
• Timing constraints: Event
• Consumed by:
– [IEVC.F3.02.07.08] Demodulate the balise signal[function]
– [IEVC.F3.02.15.01] Demodulate the Euroloop signal[function]

11.3.5 Parameters

Functional Variable
Vth [functional variable]

230 of 750 11.3. iBTM-RX module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To set the Up-link signal detection threshold
• Description: threshold based on a voltage representing the minimum received field strength
to consider a the balise or loop is present
• Family: Software
• Type: Vth
• Format: Real
• Protocol: System Parameter

Note: the unit and range of the ‘Vth’ variable needs to be defined during the component detailed design.

11.3.6 Requirements

11.3.6.1 General requirements

Requirement

The iBTM-RX shall be able to process the signal from at least 8 balises within a time frame of 0.8s.
[id:tsc-req-ievc-ibtm-rx-ss40-4-1-1-6-antenna-installation][p1][ns]

This includes any side lobe processing.

Requirement

The iBTM-RX shall have an absolute error on the event timestamping lower or equal to 0.1ms.
[id:tsc-req-ievc-ibtm-rx-timestamp-precision][p1][s]

The concerned timestamps are those of the messages iBTM Up-link telegram message and iBTM balise or
loop detection message. This error includes the effect of signal noise error and threshold detection error.

Requirement

The iBTM-RX shall be able to sense the lowest current of 37mA with a dynamic range sufficient for
the full power range required. [id:tsc-req-ievc-ibtm-rx-lowest-current][p1][ns]

Requirement

The iBTM-RX shall continuously analyze the Up-link signals characteristics. [id:tsc-req-ievc-ibtm-rx-
detection-continuous][p1][ns]

Requirement

The iBTM-RX shall measure the Up-link signal amplitude. [id:tsc-req-ievc-ibtm-rx-detection-

amplitude][p1][ns]

11.3. iBTM-RX module 231 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The iBTM-RX shall measure the Up-link signal frequencies presence. [id:tsc-req-ievc-ibtm-rx-detection-
frequency][p2][ns]

The Eurobalise Up-link signal has a center frequency of 4.234 MHz +/-175 kHz and a frequency deviation
of 282.24 kHz +/-7 %. The KER balise Up-link signal uses a carrier frequency of 4.5 MHz, +200/-500
kHz. The Euroloop Up-link signal uses a carrier center frequency of 13.54750 MHz +/-30 ppm.

Requirement

The iBTM-RX shall evaluate the detection of a modulating balise based on the up-link signal ampli-
tude and spectral contents. [id:tsc-req-ievc-ibtm-rx-detection-spectral-content][p2][s]

Requirement

The iBTM-RX shall include the associated installed cabin information in all the messages sent to the
Virtual Machine. [id:tsc-req-ievc-ibtm-tx-tp-readback-cabin][p3][ns]

This information is included in the iBTM message body and is computed based on the electric signal
detected on specific pins of the Euroantenna connector at Sensor box side. There are specific pairs of pins
for cab A an cab B installation. These pins are shunted by the Euroantenna cable connector. There are
therefore 2 types of Euroantenna cables depending on the associated cabin. When no installed cabin can
be detected from the Sensor box connector, the iBTM-RX shall use the value Unknown (when none or
both pairs of pin are shunted).

Requirement

The iBTM-RX shall use a threshold based on a voltage representing the received field strength to
detect the balise/loop presence. [id:tsc-req-ievc-ibtm-rx-detection-threshold][p1][s]

Requirement

The iBTM-RX threshold for balise/loop detection shall be constant. It shall not be possible to adjust
or modify this detection threshold during operation. [id:tsc-req-ievc-ibtm-rx-constant-vth][p1][s]

Requirement

It shall be possible to verify the iBTM-RX balise detection threshold (hereafter referred to as Vth)
using a certain current encircling the borders of the specified reference area positioned in a defined
geometrical position. [id:tsc-req-ievc-ibtm-rx-detection-threshold-verification][p1][ns]

Requirement

Vth shall be set to correspond to a field that is generated by the current Iuth encircling the borders
of the specified reference area in the geometrical worst case position. [id:tsc-req-ievc-ibtm-rx-threshold-
value][p1][s]

The value of the field strength that corresponds to the current Iuth depends on the size and orientation of
the specified reference areas according to Subset 036 (two different sizes with two different orientations
for the smaller size reference area are possible), and on the design of the Euroantenna. The level is
fundamental for the cross-talk protection and the detection of the Balise.

232 of 750 11.3. iBTM-RX module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The iBTM-RX shall detect an ‘Off to On’ transition when the field strength from the balise/loop
is higher than Vth during a minimum time of a 2ms delay. [id:tsc-req-ievc-ibtm-rx-detection-filtering-
delay][p1][s]

This filtering delay is used to avoid false detection of transient signal due for example to excessive noise.

Requirement

The iBTM-RX shall not detect any balise/loop when the received field strength remains lower than
a threshold value of Vth. [id:tsc-req-ievc-ibtm-rx-detection-threshold-criteria][p1][s]

Requirement

The iBTM-RX shall detect an ‘On to Off’ transition when the field strength from the balise/loop is
lower than Vth. [id:tsc-req-ievc-ibtm-rx-detection-balise-exit][p1][s]

No filtering delay is used for ‘On to Off’ transitions. ‘On to Off’ transitions can only be detected when an
‘Off to On’ transition had been detected prior to that.

Requirement

The iBTM-RX component shall report the detected ‘Off to On’ and ‘Off to On’ transitions in a de-
tection message on its interface with the iBTM driver. [id:tsc-req-ievc-ibtm-rx-detection-reporting][p3][s]

Requirement

The iBTM-RX component shall include a timestamp in the balise/loop detection message. [id:tsc-
req-ievc-ibtm-rx-detection-reporting-timestamp][p3][s]

The iBTM application uses the odometry information to localize the balise contact entry and exit.

Requirement

The iBTM-RX component shall include an identifier of the ‘Off to On’ transition in the balise/loop
detection message. [id:tsc-req-ievc-ibtm-rx-detection-reporting-transition-id][p3][s]

The transition identifier is incremented for each new ‘Off to On’ transition

Requirement

The iBTM-RX component shall include a list of the last 10 transitions in the detection message
including their identifier, their type and their timestamp. [id:tsc-req-ievc-ibtm-rx-detection-reporting-
transition-id-list][p3][ns]

Less than 10 transitions can be reported in case there were fewer since power on. These last 10 transitions
may be used by the iBTM application to recover the exact transition timestamp in case a specific previous
‘Off to On’ message was not received.

Requirement

The iBTM-RX component shall report any balise or loop detection event on its interface at most
5ms after the signal presence or absence. [id:tsc-req-ievc-ibtm-rx-detection-reporting-delay][p1][ns]

11.3. iBTM-RX module 233 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The minimum value of the field strength threshold Vth of the iBTM-RX shall be sufficiently high to
correctly handle possible up-link signal received from an activated balise in the cross-talk protected
zone as defined in Table 1 of Subset 036. [id:tsc-req-ievc-ibtm-rx-cross-talk][p1][s]

Requirement

The iBTM-RX and Euroantenna shall be able to handle induced currents in cables, in the track
underneath the Antenna, from a cross-talk Balise, of less than 2 mA in the Up-link frequency band
when the cable passes the track at a height equal to or lower than 93 mm below the top of the rail;
and less than 10 mA in the Up-link frequency band when the cable passes the track at a height equal
to or lower than 493 mm below the top of the rail. [id:tsc-req-ievc-ibtm-tx-cables-induced-currents][p1][s]

The above stated current levels are applicable with the return current passing less than 0.5 m underneath
the above mentioned cable, simulated by the reference set-up defined in subset 85.

Requirement

The iBTM-RX shall include 2 independent Eurobalise FSK demodulators (‘Eurobalise demodulator
A’ and ‘Eurobalise demodulator B’) using different and independent implementations. [id:tsc-req-
ievc-ibtm-rx-eb-demodulators][p1][s]

Each iBTM-RX component includes both demodulator circuits.

Requirement

The iBTM-RX shall include 2 independent KER demodulators (‘KER demodulator A’ and ‘KER
demodulator B’) using different and independent implementations. [id:tsc-req-ievc-ibtm-rx-ker-
demodulators][p1][ns]

Each iBTM-RX component includes both demodulator circuits.

The KER balise telegram bits are transmitted as decaying pulses of a single 4.5 MHz carrier and need
specific demodulating circuits.
The Subset 101 implies high safety integrity requirements which conducts to implementing the same
demodulation strategy as for Eurobalise: 2 demodulators with diversified design.

Requirement

The iBTM-RX shall include one Euroloop demodulator. [id:tsc-req-ievc-ibtm-rx-euroloop-

demodulator][p1][ns]

The Euroloop signal demodulation is performed according to Subset 044.

234 of 750 11.3. iBTM-RX module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

In each iBTM-RX component, all the demodulators shall work in parallel and provide their own
outputs in the interface with the Virtual Machine. [id:tsc-req-ievc-ibtm-rx-demodulators-outputs][p1][ns]

Requirement

The Eurobalise demodulators shall demodulate the Up-link signal and detect any Eurobalise tele-
gram in the demodulated bitstream by implementing steps 1 to 3 of the ‘Basic Receiver Operation’
described in section 4.3.4.1 of Subset 036. [id:tsc-req-ievc-ibtm-rx-eb-demodulators-tgm-detection][p1][s]

Requirement

The Euroloop demodulator shall demodulate the Up-link signal and detect any telegram in the de-
modulated bitstream by implementing steps 1 to 3 of the Basic Receiver Operation described in
section 4.3.4.1 of Subset 036. [id:tsc-req-ievc-ibtm-rx-euroloop-demodulators-tgm-detection][p1][ns]

Only long telegrams (1023 bits) are used for Euroloop.

Requirement

Each Eurobalise demodulator shall detect the Eurobalise telegram Type (long/short/unknown)
[id:tsc-req-ievc-ibtm-rx-eb-demodulators-tgm-type][p3][ns]

‘Short’ corresponds to 341 bits telegram. ‘Long’ corresponds to 1023 bits telegram.

Requirement

The KER demodulators shall detect KVB analog and EBICAB balise telegrams by identifying the
alternating synchronization bytes S0 and S1 at the beginning of 2 consecutive bit streams of 32 bits.
It shall then verify that the telegram part (24 bits) is identical in the consecutive bit streams. It
shall start reporting the telegram part (24 bits) when 2 identical telegrams have been received.
[id:tsc-req-ievc-ibtm-rx-ker-demodulators-kvba][p3][ns]

Figure 11.5: KVB analog and EBICAB balise bitstream

The synchronization bytes are:

- S0 = '00001101' = '0x0D'
- S1 = '01110010' = '0x72'

Requirement

The KER demodulators shall detect KVB digital balise telegrams by identifying the synchronization
byte S2 at the beginning of a repeating bit stream of 256 bits. It shall start reporting the telegram
part (248 bits) when 2 identical telegrams have been received. [id:tsc-req-ievc-ibtm-rx-ker-demodulators-
kvbn][p3][ns]

11.3. iBTM-RX module 235 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.6: KVB digital balise bitstream

The synchronization byte is:

- S2 = '11111110' = '0xFE'

Requirement

The KER demodulators shall detect RSDD balise telegrams by detecting repetition of bit streams
of size 255 bits in the demodulated bit flow. It shall start reporting the repeating bit stream (255
bits) as valid telegram when 2 identical bit streams have been received. [id:tsc-req-ievc-ibtm-rx-ker-
demodulators-rsdd][p3][ns]

No specific synchronization method is used for RSDD balise information.

Requirement

For each demodulator, the iBTM-RX component shall start producing an Up-link telegram message
after detecting 2 identical valid telegrams. [id:tsc-req-ievc-ibtm-rx-tgm-reporting-frequency][p1][s]

This message is provided whatever the consistency of its content. This requirement is applicable for all
the iBTM-RX demodulators

Requirement

The Eurobalise and KER demodulators shall report the detected telegram information in an Up-link
telegram message on the interface with the iBTM driver. [id:tsc-req-ievc-ibtm-rx-tgm-reporting][p3][s]

Requirement

The Euroloop demodulator shall report the detected telegram information in an Up-link telegram
message on the interface with the iBTM driver. [id:tsc-req-ievc-ibtm-rx-euroloop-tgm-reporting][p3][ns]

Requirement

For each demodulator, if identical telegrams continue to be detected after the 2 first ones, then new
messages shall be produced by incrementally doubling the number of identical telegram required at
each message up to a steady quantity of 256 identical telegrams. [id:tsc-req-ievc-ibtm-rx-tgm-reporting-
next-messages][p1][ns]

New messages are produced after detecting 4, 8, 16, 32, 64, 128, 256 identical telegrams. The maximum
number of repetitions of 256 telegrams implies one message every 460 ms. This requirement is applicable
for all the iBTM-RX demodulators

Requirement

Whenever the telegram is detected as modified (‘telegram has switched’) during a balise passage the
iBTM-RX component shall restart sending new up-link telegram messages starting with a detection

236 of 750 11.3. iBTM-RX module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

of 2 identical telegrams. [id:tsc-req-ievc-ibtm-rx-tgm-switch][p1][ns]

This requirement is applicable for all the iBTM-RX demodulators

Requirement

Whenever the demodulated bit stream contains undefined content (meaning that no telegram is
detected in the demodulated bitstream), the iBTM-RX component shall not report any up-link tele-
gram message. [id:tsc-req-ievc-ibtm-rx-tgm-unknown][p2][ns]

This requirement is applicable for all the iBTM-RX demodulators

Requirement

The iBTM-RX component shall include the timestamp of the message transmission in each Up-link
telegram message. [id:tsc-req-ievc-ibtm-rx-tgm-timestamp][p2][ns]

This requirement is applicable for all the iBTM-RX demodulators

Requirement

The iBTM-RX component shall include an identifier of the ‘Off to On’ transition in each Up-link
telegram message. [id:tsc-req-ievc-ibtm-rx-tgm-transition-id][p3][s]

This requirement is applicable for all the iBTM-RX demodulators

Requirement

The iBTM-RX component shall include Eurobalise/Euroloop telegram error counter in the Up-link
telegram messages issued from the Eurobalise and Euroloop demodulators. [id:tsc-req-ievc-ibtm-rx-
detection-reporting-tgm-error-rate][p3][ns]

The errors are counts of telegram detected as erroneous for the first 3 steps of the decoding requirements
of Subset 036 §4.3.4.1. The computation method shall be further developed in the component detailed
design. This counter is not used for KER telegrams.

Requirement

The iBTM-RX shall be able to read 2 short telegrams in a maximum time of 3,6 ms. The iBTM-RX
shall be able to read 2 long telegrams in a maximum time of 7 ms. [id:tsc-req-ievc-ibtm-rx-read-2-
telegrams][p1][ns]

This allows reading at least 2 telegrams during a balise passage at a maximum speed of 500 kph. At this
maximum speed a short balise has a contact duration of 3,6 ms considering a contact length of 0,5m. At
this speed the short balise can only transmit short telegram (as specified in table 5 of Subset 036). The
average transmission time of a short telegram is 0,6 ms. Considering the filtering delay of 2 ms on the
contact entry, there is sufficient time in the remaining 1,6 ms to receive at least 2 short telegrams. In the
same way a long balise has a contact duration of 7,2 ms at 500 kph considering a contact length of 1 m.
The average transmission time of a long telegram is 1,8 ms. Considering the filtering delay of 2 ms on the
contact entry, there is sufficient time in the remaining 5 ms to receive at least 2 long telegrams.

11.3. iBTM-RX module 237 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The iBTM-RX shall be designed in order to not contribute negatively to the bit error rate in the
central area of a balise contact. A specific study shall demonstrate that there is no negative effect.
[id:tsc-req-ievc-ibtm-rx-ber][p1][ns]

Requirement

When passing over a KER balise in CW mode, the balise might transmit one or two bits (at an ASK
modulated data rate of 50 kbit/s) before it turns silent again. This shall not affect the iBTM function.
[id:tsc-req-ievc-ibtm-tx-ker-in-cw][p1][ns]

In this situation, no balise contact shall be detected.

Requirement

The iBTM-RX shall be compliant with Subset 100. [id:tsc-req-ievc-ibtm-rx-ss100][p1][ns]

These components are responsible to detect and demodulate the KER balise signal up to the transmission
of the KER telegram to the Class B application which is in charge of decoding its application data.

Requirement

The iBTM-RX shall be compliant with Subset 044. [id:tsc-req-ievc-ibtm-rx-ss044][p1][ns]

Requirement

The iBTM-RX status message shall be sent to the iBTM driver (and by extension to the iBTM
application) periodically every 50 ms. [id:tsc-req-ievc-ibtm-rx-rx-status-message-frequency][p3][s]

This message shall contain the iBTM-RX hardware and software versions and its health information.

Requirement

Once an iBTM-RX component has synchronized with the iBTM driver in the Virtual Machine, it
will not resynchronize with any other component until the next shut down. [id:tsc-req-ievc-ibtm-rx-
synchronization][p3][ns]

Requirement

The iBTM-RX shall not erroneously report to the iBTM application that it has detected a balise
more often than 10-3 times per hour. [id:tsc-req-ievc-ibtm-tx-availability-2][p1][ns]

This requirement is allocated to iBTM-TX as well because a too high tele-powering can cause cross-talk.
This can occur without faults in the equipment (e.g., due to disturbance).

Requirement

The iBTM-RX shall configure its network connection based on the installed cabin (detected at the
Euroantenna connector) and based on a dongle (internal to the sensor box) that identifies the iBTM-
RX board #1 and #2 inside the sensor box [id:tsc-req-ievc-ibtm-rx-network-config][p2][ns]

238 of 750 11.3. iBTM-RX module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The iBTM-RX component shall reset itself upon reception of a reset order from the iBTM driver.
[id:tsc-req-ievc-ibtm-rx-reset][p2][ns]

11.3.7 Failure modes

11.3.7.1 Failure to detect balise Up-link signal

The effect is that the iBTM-RX is not able to detect balise contacts anymore. There are 2 iBTM-RX component
working in parallel meaning that only the other component may detect balise contact. The availability and safety
of the iBTM function are impacted.
This failure is detected by the iBTM application when comparing the information provided by the 2 RX channels.
This can also be detected by the iBTM test (see iBTM-TX module). When this happens, the iBTM application
raises an iBTM alarm to the signalling application (subset 26 application or class B application).

11.3.7.2 Failure to demodulate the balise signal

The effect is that the iBTM-RX is not able to decode Up-link balise information anymore. There are 2 iBTM-RX
component working in parallel meaning that only the other component may decode correctly the Up-link balise
information. The availability and safety of the iBTM function are impacted.
This failure is detected by the iBTM application when comparing the information provided by the 2 RX channels.
This can also be detected by the iBTM test. When this happens, the iBTM application raises an iBTM alarm to
the signalling application (subset 26 application or class B application).

11.4 Euroantenna

Important: This component is included in the iEVC Sensor kit[ci]

11.4.1 Description

The iEVC Euroantenna contains very little electronics. It contains 4 inductive loops that are basically wires
arranged in concentric circles:
• A tele-powering loop (a.k.a TX loop). This loop receives a tele-powering signal from the iBTM;
• Two independent reception loops (a.k.a. RX loops). These loops receive the reply from the wayside devices,
and feed the iBTM with two independent detection signals.
• A “test” loop. This loop can be used by the iBTM to simulate a balise or loop up-link signal and to read back
the Tele-powering signal, and therefore verify the good behavior of the complete iBTM detection chain.
Refer to [SyAD-R55-SIF-iBTM-Euroantenna] for more information about the interface between the Euroantenna
and the Sensor box.

11.4. Euroantenna 239 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.4.2 Modes

The iBTM modes are not managed by the Euroantenna component.

11.4.3 Functions

11.4.3.1 [IEVC.F3.02.07.01] Generate Tele-power magnetic field [function]

Data
• Definition: The Euroantenna provides 1 Tele-powering loop. This loop is fed with the Tele-powering
signal generated by the iBTM-TX component. The signal is either in Constant Wave, Toggling or
Non-Toggling modulation mode. With this signal the Tele-powering loop generates a magnetic
field. This magnetic field induces a voltage in a reception loop of the Up-link wayside device. The
induced voltage in the wayside device is based mainly on the vertical component of the magnetic
field that flows through the device loop.
• Allocated to:
– Euroantenna[ci]
• Input:
– Tele-powering signal[functional variable][Tele-powering loop interface]
• Output:
– Tele-powering magnetic field[functional variable][Eurobalise air-gap]
• Sil: basic
• Associated interface:
– Eurobalise air-gap[ci]
– Tele-powering loop interface[ci]

11.4.3.2 [IEVC.F3.02.07.02] Pick-up Up-link magnetic field [function]

Data
• Definition: The Euroantenna provides 2 independent reception loops. Each loop picks up the mag-
netic field produced in a transmit loop of the wayside device (balise or loop). This field induces a
voltage in the 2 horizontal reception loops of the Euroantenna. The Euroantenna also provides 1 test
loop that picks-up a readback signal of the Tele-powering and feeds it back to the iBTM-TX.
• Allocated to:
– Euroantenna[ci]
• Input:
– Test Up-link magnetic field[functional variable]
– Up-link balise magnetic field[functional variable][Eurobalise air-gap]
– Up-link Euroloop magnetic field[functional variable][Eurobalise air-gap]
– Tele-powering magnetic field[functional variable][Eurobalise air-gap]
• Output:
– Tele-powering readback[functional variable][Test loop interface]

240 of 750 11.4. Euroantenna

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– Up-link signal[functional variable][RX loop interface]

• Sil: basic
• Associated interface:
– RX loop interface[ci]
– Test loop interface[ci]
– Eurobalise air-gap[ci]

11.4.3.3 [IEVC.F3.02.07.03] Generate test Up-link magnetic field [function]

Data
• Definition: The Euroantenna provides 1 test loop. This loop is used to emulate an Up-link magnetic
field that allows testing the 2 iBTM reception chains.
• Allocated to:
– Euroantenna[ci]
• Input:
– Test signal[functional variable][Test loop interface]
• Output:
– Test Up-link magnetic field[functional variable]
• Sil: basic
• Associated interface:
– Test loop interface[ci]

11.4.3.4 [IEVC.F3.02.07.15] Provide the installed cabin associated to the Euroantenna [function]

Data
• Definition: The Euroantenna cable is able to provide the information of the installed cabin associated
to the Euroantenna. There are dedicated pins in the Euroantenna connector of the Sensor box that
can be shunted by the cable to inform the iBTM-TX and iBTM-RX components.
• Allocated to:
– Euroantenna[ci]
• Output:
– Associated installed cabin[functional variable][Sensor box - Euroantenna interface]
• Sil: basic
• Associated interface:
– Sensor box - Euroantenna interface[ci]

There are 2 different hardware for the Euroantenna cable. One to be used when the Euroantenna is installed in
cabin A and one when it is installed in cabin B.

11.4. Euroantenna 241 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.4.4 Interface

• Tele-powering loop interface[ci]

The Euroantenna component receives the Tele-powering signal from the iBTM-TX module using
this interface.
• 2 RX loop interface[ci]
The Euroantenna component provides the Up-link signal to the iBTM-RX module using this
interface.
• Test loop interface[ci]
The Euroantenna component receives the test signal from the iBTM-TX module using this inter-
face. The Euroantenna component provides the Tele-powering signal readback information to
the iBTM-TX module using this interface.
• Eurobalise air-gap[ci]
The Euroantenna component receives the magnetic field from the wayside device (Eurobalise,
KER balise or Euroloop) through this interface.
• Sensor box - Euroantenna interface[ci]
This is the physical interface between the Sensor box and the Euroantenna. It allows for the logical interfaces
Tele-powering loop interface[ci], RX loop interface[ci] and Test loop interface[ci].

11.4.5 Parameters

Not applicable for this component.

11.4.6 Requirements

Requirement

The iEVC Euroantenna shall provide 2 independent reception loops capable of receiving informa-
tion from the wayside signalling equipments according to subset 036. [id:tsc-req-ievc-euroantenna-rx-
loops][p1][s]

Requirement

The iEVC Euroantenna shall provide 1 Tele-powering loop capable of providing power to the way-
side device by generating a Tele-powering magnetic field. [id:tsc-req-ievc-euroantenna-tx-loop][p1][s]

The vertical component of this field shall induce a voltage in a reception loop of the balise.

Requirement

The iEVC Euroantenna Tele-powering shall be compliant to interface ‘A’ according to subset-036.
[id:tsc-req-ievc-euroantenna-tp-loop][p1][s]

Requirement

The Tele-powering field distribution from the iEVC Euroantenna loop shall be such that a balise gets
enough power to be able to provide an output signal forming the contact volume for the Euroantenna
reception loops. [id:tsc-req-ievc-euroantenna-tx-power][p1][s]

242 of 750 11.4. Euroantenna

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

This is valid whatever the type of Eurobalise (Reduced or Standard Size). The field strength from the
Euroantenna Unit shall be defined as the total flux into a Balise reference area placed in any position
relative to the Euroantenna in accordance with sub-clause 5.2.2.4 of subset 36.

Requirement

The iEVC Euroantenna shall provide 1 test loop capable of emulating a wayside device response by
generating an Up-link magnetic field. [id:tsc-req-ievc-euroantenna-test-loop][p1][s]

The generated signal allows testing the 2 iBTM reception chains used for Eurobalise, KER balise and
Euroloop, respectively in compliance with Subset 036, Subset 100 and Subset 044.

Requirement

The deviation of the field form from the Euroantenna, due to debris and proximity of conductive
material, relative to the field form in free air, shall be considered in the Euroantenna design (see
also sub-clause 5.2.2.5 of subset 36). Debris and the proximity to conductive material may influence
the efficiency of the Euroantenna itself. Such influence shall be within the specified limits for the
performance of the Euroantenna. The levels of debris, nominated as Class A and Class B layers, are
defined in sub-clause 5.7.9 of subset 36. The Antenna Unit design shall be such that both Class A
and Class B Balises are properly handled. [id:tsc-req-ievc-euroantenna-tx-flux-deviation][p1][s]

Requirement

The iEVC Euroantenna shall operate for both driving directions [id:tsc-req-ievc-euroantenna-
bidirectionnal-installation][p1][ns]

Requirement

The iEVC Euroantenna shall be resistant to impacts in compliance with ‘IK10’ level according to
EN62262. [id:tsc-req-ievc-euroantenna-impact-resistance][p2][s]

Refer to EN-62262:2002.

Requirement

The iEVC Euroantenna cable shall be protected to be resistant to impacts for its section installed out-
side of the vehicle in compliance with ‘IK10’ level according to EN62262. [id:tsc-req-ievc-euroantenna-
cable-impact-resistance][p2][s]

Refer to EN-62262:2002.

Requirement

The iEVC Euroantenna, PG, secondary sensor, and all other equipment added under the vehicle
shall resist normal wear and tear for a device installed under a locomotive. The justification, in
the form of a technical note or similar study, shall cover the topic of shocks, debris, temperature,
vibrations, mounting and dismounting during operations as well as maintenance (e.g. when cleaning
the locomotive). [id:tsc-req-ievc-euroantenna-pg-secondary-sensor-wear-resistance][p2][ns]

11.4. Euroantenna 243 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The Euroantenna shall be placed such that the Reference Mark of the antenna lies between 2m from
the front of the engine and the axle, or up to 12.5 m in the rear of the axle. [id:tsc-req-ievc-euroantenna-
ss40-installation][p1][s]

The minimum value of 2m shall be ensured taking into account dynamic effects of the coupling.

Requirement

Metallic reflectors/objects shall be outside the metal free area of the Euroantenna Unit, as specified
by the manufacturer. [id:tsc-req-ievc-euroantenna-ss36-installation][p1][s]

Requirement

The iEVC Euroantenna shall carry X, Y, and Z reference marks on each of the six sides. The man-
ufacturer of the Antenna Unit shall specify the installation measurements related to these reference
marks. [id:tsc-req-ievc-euroantenna-reference-marks][p1][ns]

The X, Y, and Z reference marks indicate the positions of the X, Y, and Z axes respectively. The X axis is
the reference axis in parallel with the rails. The Y axis is the reference axis at right angles across the rails,
and which is level with the top of rails. The Z axis is the reference axis directed upwards, at right angles
to the rail plane.

Requirement

The allowed static and dynamic displacements of the Euroantenna relative to the track shall be
specified in a table having the format of the table in §6.5.4 of subset 36 [id:tsc-req-ievc-euroantenna-
allowed-displacements][p1][ns]

Requirement

The Euroantenna shall fulfil applicable parts of 4.5 (Air movement), 4.6 (Rain), 4.7 (Snow and Hail),
4.8 (Ice), and 4.9 (Solar Radiation) of EN 50125-1. [id:tsc-req-ievc-euroantenna-en50125][p1][s]

Requirement

The Euroantenna shall fulfil applicable parts of sub-clause 4.11 (Pollution) of EN 50125-1 concern-
ing chemical and biological conditions. [id:tsc-req-ievc-euroantenna-pollution][p1][s]

Requirement

The Euroantenna manufacturer shall specify the performance of the Euroantenna and its maximum
allowed debris under the unit. [id:tsc-req-ievc-euroantenna-debris][p2][s]

Table 20 of subset 036 shall be used to specify the maximum debris quantity.

Requirement

The Euroantenna manufacturer shall specify a defined area around the Euroantenna where metal
shall be avoided. [id:tsc-req-ievc-euroantenna-metal][p1][s]

Metallic reflectors on the vehicle shall not cause any risk of cross-talk with balises in the cross-talk pro-
tected area.

244 of 750 11.4. Euroantenna

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The Euroantenna manufacturer shall specify a defined area around the Euroantenna where Cables
should not be placed to guarantee that no influence is possible to/from other transmission equip-
ment. [id:tsc-req-ievc-euroantenna-cables][p1][s]

Requirement

The installation designer shall mount the Euroantenna in such a way that metal is avoided in a
well-defined area as specified by the manufacturer. [id:tsc-req-ievc-euroantenna-cables-installation][p1][s]

Requirement

The in-band emission from the Eurobalise On-board Transmission Equipment, when transmitting
CW Tele-powering, shall comply with EN 302 608. [id:tsc-req-ievc-euroantenna-emission-in-band][p1][s]

Requirement

The in-band emission from the Eurobalise On-board Transmission Equipment, when transmitting
Toggling Tele-powering (TM), shall comply the frequency mask of sub-clause D1.3 in Subset-036.
[id:tsc-req-ievc-euroantenna-emission-in-band-toggling-mode][p1][ns]

Requirement

The out-band emission from the Eurobalise On-board Transmission Equipment, when transmitting
CW Tele-powering, shall comply with EN 302 608. [id:tsc-req-ievc-euroantenna-emission-out-band][p1][ns]

Requirement

The Euroantenna manufacturer shall provide information related to the Eurobalise band sus-
ceptibility of the equipment, to support its integration in the vehicle. [id:tsc-req-ievc-euroantenna-
susceptibility-in-band][p1][ns]

This information should make reference to recognized technical standards.

Requirement

The Radiated immunity requirements shall comply with the applicable items of table 9 in clause
8 of EN 50121-3-2. This requirement does neither apply for the frequency band 2.5 MHz to 6.0
MHz, nor for the frequency range +/-500 kHz centred on the Tele-powering carrier frequency.
[id:tsc-req-ievc-euroantenna-susceptibility-out-band][p1][ns]

Requirement

The Euroantenna shall be compliant with Subset 100. [id:tsc-req-ievc-euroantenna-ss100][p1][ns]

Requirement

The Euroantenna shall be compliant with Subset 044. [id:tsc-req-ievc-euroantenna-ss044][p1][ns]

Note: [SyAD-R46-EN-62262:2002] is referenced in requirement tsc-req-ievc-euroantenna-impact-

resistance[req]

11.4. Euroantenna 245 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.4.7 Failure modes

11.4.7.1 Failure to generate Tele-power magnetic field

The effect is that the On-board subsystem will fail to generate Tele-powering and therefore it will fail to detect
any balise.
This failure is detected through the readback of the Tele-powering signal. The iBTM application will raise an
iBTM alarm to the signalling application (subset 26 application or class B application).
A failure of the read-back function will have the same effect.

11.4.7.2 Failure to pick-up Up-link magnetic field in one of the RX loop interface

The effect is that only one RX chain is functional. The availability and safety of the function are impacted.
This failure is detected by the iBTM application when comparing the information provided by the 2 RX channels.
This can also be detected by the iBTM test. The iBTM application will raise an iBTM alarm to the signalling
application (subset 26 application or class B application).

11.4.7.3 Failure to pick-up Up-link magnetic field in both of the RX loop interface

The effect is that the On-board subsystem will fail to pick-up any Up-link balise signal.
This failure is detected by the iBTM application through the iBTM test.

11.4.7.4 Failure to Generate test Up-link magnetic field

11.5 iODO module

Important: This component is included in the iEVC Sensor kit[ci]

11.5.1 Description

iODO module is a sensor hardware electronic module inside the Sensor box[ci] that is responsible to acquire
measurement samples from Wheel pulse generators[ci] and Secondary odometry sensor[ci] and then to send the
samples to the Odometry application[ci] by means of iODO driver[ci]. Fig. 11.7 depicts the system logical
architecture design of iODO:

246 of 750 11.5. iODO module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.7: Capella diagram of iODO and the interfaces inside sensor box

Note: [IEVC.F3.02.03.16] Configure iODO network connection[function] is not represented on this Fig. 11.7.
This function doesn’t interact with any other function.

Note: [IEVC.F4.32.15] Reset iODO[function] is not represented on this Fig. 11.7. This function is present on
Fig. 11.9.

11.5. iODO module 247 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.5.1.1 Odometry sampling

The odometry sampling relies on reading up to 6 channels independently (3 pairs of cables with each cable
including 2-channel square output signal) from the Wheel pulse generators[ci], and 1 channel (a cable of single
channel square output signal) from the Secondary odometry sensor[ci] (Corrail optical sensor) and one RS485
serial output from the Secondary odometry sensor[ci]. In this regard, there must exist 2 redundant iODO modules
inside the Sensor box[ci] for efficient sampling of the sensors. The architectural design of the iODO boards has to
finally provide 2 acquisition chains for the Odometry application[ci] through iODO driver[ci] (Odometry driver).
Fig. 11.8 depicts this architectural design:

Figure 11.8: Architectural design of iODO modules

Since the demodulated measurement data packet needs to be sent to the Virtual machine[ci] via Ethernet, the
iODO boards must also provide serial to Ethernet converter to convert serial protocol from secondary sensor to
UDP message.

11.5.2 Functions

11.5.2.1 [IEVC.F3.02.03.03] Sample PG [function]

Data
• Definition: iODO samples analog signals from the Wheel pulse generators. These signals are square
signals in the 2V-30V range. The sampling consists into counting the number of rising and falling
edges of these signals during a sampling period (e.g. "pulse edges count"). Also the sample includes
the frequency of the last signal period, it allows to have a better estimation of the speed.
• Allocated to:
– iODO[ci]
• Input:
– Pulse Generator signals[functional variable][Sensor box - Pulse generator interface]
• Output:

248 of 750 11.5. iODO module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– PG sample[functional variable]
• Sil: basic
• Associated interface:
– Sensor box - Pulse generator interface[ci]

11.5.2.2 [IEVC.F3.02.03.04] Sample secondary sensor [function]

Data
• Definition: iODO samples analog signals from the Secondary Odometry sensor. These signals are
serial and square signals in the 2V-30V range. The sampling consists into counting the number of
rising and falling edges of these signals during a sampling period (e.g. "pulse edges count"). Also
the sample includes the frequency of the last signal period, it allows to have a better estimation of
the speed.
• Allocated to:
– iODO[ci]
• Input:
– Secondary odometry sensor pulse signals[functional variable][Sensor box - Secondary sensor
interface]
• Output:
– Secondary sensor sample (from pulse signal)[functional variable]
• Sil: basic
• Associated interface:
– Sensor box - Secondary sensor interface[ci]

11.5.2.3 [IEVC.F3.02.03.05] Manage serial link from secondary sensor [function]

Data
• Definition: There's also serial link protocol RS485 for the Secondary Odometry sensor by which the
speed measurement telegram data are being sent continuously in telegram content. Accordingly, the
iODO also samples the serial data from the Secondary Odometry sensor.
• Allocated to:
– iODO[ci]
• Input:
– Secondary odometry serial link[functional variable][Sensor box - Secondary sensor interface]
• Output:
– Secondary sensor sample (from serial link)[functional variable]
• Sil: basic
• Associated interface:
– Sensor box - Secondary sensor interface[ci]

11.5. iODO module 249 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.5.2.4 [IEVC.F3.02.03.06] Provide a sample measure and sensor status of the Odometry sen-
sors [function]

Data
• Definition: In each acquisition time-step iODO demodulates the samples by providing the packet
of measurement data to feed the Odometry application in Virtual Machine. The measurement data
packet includes also the signal of health of sensor (sensor status) which is acquired by self testing
sensors.
• Allocated to:
– iODO[ci]
• Input:
– iODO Synchronization message[functional variable][VM - iODO interface]
– PG sample[functional variable]
– Secondary sensor sample (from pulse signal)[functional variable]
– Secondary sensor sample (from serial link)[functional variable]
• Output:
– iODO Synchronization message[functional variable][VM - iODO interface]
– iODO sample message[functional variable][VM - iODO interface]
– iODO status message[functional variable][VM - iODO interface]
• Sil: basic
• Associated interface:
– VM - iODO interface[ci]

11.5.2.5 [IEVC.F3.02.03.16] Configure iODO network connection [function]

Data
• Definition: Based on its identification dongle, determine the network address of the iODO compo-
nent.
• Allocated to:
– iODO[ci]
• Sil: basic
• Associated interface:
– Sensor box - iODO interface[ci]

This function takes as input the ‘hardware’ information of the dongle and outputs the IP address to use in the com-
munication of the other functions with the iODO driver of the VM. The address to use, depending on identification
dongle, is provided in Network architecture.

250 of 750 11.5. iODO module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.5.2.6 [IEVC.F4.32.15] Reset iODO [function]

Data
• Definition: The iODO component resets itself upon reception of a reset order from the iODO driver
• Allocated to:
– iODO[ci]
• Input:
– iODO reset order[functional variable][VM - iODO interface]
• Sil: basic
• Associated interface:
– VM - iODO interface[ci]

Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional architecture.

11.5.3 Modes

The iODO has no mode.

11.5.4 Interface

iODO 1 is connected to 2 square signal outputs and the serial connection is unplugged. iODO 2 is connected to
one square signal output and one serial output and the other square signal connection is unplugged. According
to what is explained the interfaces of 2 iODO boards are listed as following (see [SyAD-R59-SIF-iODO-VM],
[SyAD-R57-SIF-iODO-PG] and [SyAD-R58-SIF-iODO-SECONDARY] for more information):
• Interfaces for iODO 1:
– Sensor box - Pulse generator interface[ci]
iODO 1 has 2 connectors (2 for analog square signals). Via first connector it receives a pair of
2-channel square signal form Wheel pulse generators[ci].
– Sensor box - Secondary sensor interface[ci]
iODO 1 has 2 connectors (2 for analog square signals). Via second connector it receives single
channel square signal form Secondary odometry sensor[ci].
– VM - iODO interface[ci]
iODO 1 board provides UDP message to feed the Odometry application[ci] in Virtual ma-
chine[ci] by mean of iODO driver[ci]. It is done by synchronization process, in each sampling
time, between iODO boards and iODO driver[ci].
• Interfaces for iODO 2:
– Sensor box - Pulse generator interface[ci]
iODO 2 has 2 connectors (one for analog square signals and one for serial link). Via first con-
nector it receives a pair of 2-channel square signal form Wheel pulse generators[ci].
– Sensor box - Secondary sensor interface[ci]
iODO 2 has 2 connectors (one for analog square signals and one for serial link). Via second
connector it receives serial telegram message in RS485 protocol from secondary sensor.
– VM - iODO interface[ci]

11.5. iODO module 251 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

iODO 2 board provides UDP message to feed the Odometry application[ci] in Virtual ma-
chine[ci] by mean of iODO driver[ci]. It is done by synchronization process, in each sampling
time, between iODO boards and iODO driver[ci].
During a test, the iODO components are connected to the iODO BITE through iODO - iODO BITE interface[ci].

11.5.5 Internal variables

Functional Variable
PG sample [functional variable]
Data
• Objective: To provide a cyclic sample measurement of PG
• Description: The message includes the number of PG pulses' edges and the associated times-
tamps in each sample cycle
• Family: Hardware
• Format: Integer
• Timing constraints: Cyclic (iODO_sampling_period)
• Produced by:
– [IEVC.F3.02.03.03] Sample PG[function]
• Consumed by:
– [IEVC.F3.02.03.06] Provide a sample measure and sensor status of the Odometry sen-
sors[function]

Functional Variable
Secondary sensor sample (from pulse signal) [functional variable]
Data
• Objective: To provide a cyclic pulse edges sample measurement of secondary sensor
• Description: The message includes the number of secondary sensor pulses' edges and the
associated timestamps in each sample cycle
• Family: Hardware
• Format: Integer
• Timing constraints: Cyclic (iODO_sampling_period)
• Produced by:
– [IEVC.F3.02.03.04] Sample secondary sensor[function]
• Consumed by:
– [IEVC.F3.02.03.06] Provide a sample measure and sensor status of the Odometry sen-
sors[function]

Functional Variable
Secondary sensor sample (from serial link) [functional variable]

252 of 750 11.5. iODO module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide a cyclic sample measurement of secondary sensor from serial link
• Description: The message includes speed and direction of travel information as well as
sensor status
• Family: Hardware
• Format: BSON
• Timing constraints: Cyclic (iODO_sampling_period)
• Produced by:
– [IEVC.F3.02.03.05] Manage serial link from secondary sensor[function]
• Consumed by:
– [IEVC.F3.02.03.06] Provide a sample measure and sensor status of the Odometry sen-
sors[function]

11.5.6 Parameters

Functional Variable
iODO_sampling_period [functional variable]
Data
• Objective: To fix the iODO measurement sampling period
• Description: delay between the processing of odometry sensor signal to produce sample
information
• Family: Software
• Protocol: system parameter

iODO_sampling_period is fixed to 10 ms (see tsc-req-ievc-iodo-req3[req]).

11.5.7 Requirements

Requirement

The iODO shall be able to sample the pulse signal from the Wheel Pulse Generators. [id:tsc-req-ievc-
iodo-sample-pg][p1][s]

Requirement

The iODO shall be able to sample the pulse signal from the Secondary odometry sensor. [id:tsc-req-
ievc-iodo-sample-sec-pulse][p1][s]

The secondary sensor provide a signal that is not directly linked to the wheel rotation and therefore not
sensitive to slip and slide.

11.5. iODO module 253 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The iODO shall be able to sample the Secondary odometry sensor signal through a serial link.
[id:tsc-req-ievc-iodo-sample-sec-serial][p1][s]

Requirement

The iODO shall provide the sample information on its interface with the iODO driver cyclically
every 10 ms. [id:tsc-req-ievc-iodo-sample-report][p3][s]

Requirement

The iODO shall provide health information about each Odometry sensors. [id:tsc-req-ievc-iodo-
req1][p2][s]

Health information is used in the sample selection process. For the PG sensor, each iODO shall detect
when the sensor head appears disconnected. For the secondary sensor, one of the iODO shall report the
sensor status as provided on the serial link.

Requirement

The 2 iODO boards inside the Sensor box shall be diversified in terms of used software (same SW
only for PGs), processor, electronics, memory, clocks and PG information. [id:tsc-req-ievc-iodo-
req2][p1][s]

Requirement

The iODO board shall sample sensors data with a minimum frequency of 100 Hz (10 ms). [id:tsc-
req-ievc-iodo-req3][p1][s]

Requirement

iODO boards shall provide the measurement packet to the iODO driver without degradation of
measurements precision coming from sensors outputs. [id:tsc-req-ievc-iodo-req4][p1][s]

Requirement

The iODO shall configure its network connection based on a dongle (internal to the sensor box) that
identifies the iODO board #1 and #2 inside the sensor box [id:tsc-req-ievc-iodo-network-config][p2][ns]

Refer to [IEVC.F3.02.03.16] Configure iODO network connection[function] for a description of the re-
lated functional architecture.

Requirement

The iODO component shall reset itself upon reception of a reset order from the iODO driver.
[id:tsc-req-ievc-iodo-reset][p2][ns]

Requirement

Each iODO module shall provide its hardware and software version information and its health
status in a cyclic message to the iODO driver over TSC Net [id:tsc-req-ievc-iodo-version][p3][s]

254 of 750 11.5. iODO module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.5.8 Failure modes

The 2 iODO boards are redundant. So, in case of failure of one iODO the other still can provide a sample
of sensors measurement to the Odometry application[ci]. The failure of iODO boards can be detected during
the pairing (synchronization) with iODO driver[ci]. The iODO driver will inform this failure to the Odometry
application through the iODO status message.

11.6 iODO Driver

Important: This component is included in the iEVC Basic kit[ci]

11.6.1 Description

iODO driver is a software module inside the Virtual machine[ci] that manages cyclic exchange of measurement
data and messages as well as synchronization between iODO[ci] boards and Virtual machine[ci]. This application
is illustrated in Fig. 11.9:

11.6. iODO Driver 255 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.9: Capella diagram of iODO driver in system logical architecture design level

According to Fig. 11.9 the iODO driver is an interface application between iODO[ci] boards and Odometry ap-
plication[ci] such that it receives acquired measurement samples from the two iODO[ci] boards via Ethernet
UDP messages and then makes the samples data available as built-in variables to the Odometry application[ci]
(see also Fig. 11.8). The messages structures are elaborated in [SyAD-R59-SIF-iODO-VM]. To that end, iODO
driver plays the role of pairing between iODO[ci] boards and Virtual machine[ci] where it can accept or reject the
sampled measurement data by performing a synchronization process. This synchronization process is performed
through “iODO synchronization message”. This message is exchanged between iODO[ci] and iODO driver. The
content of the message allows the receiving party to:
• Identify surely that the message is coming from different iODO[ci] boards

256 of 750 11.6. iODO Driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Ensure that the messages are not corrupted

• Determine the “age” of the message
In general, in accordance with EN 50159, it provides protection against (see [SyAD-R74-SIF-Sensor-interface]):
• Repetition / Deletion / Insertion / Re-sequence
• Corruption
• Delay
The iODO driver is also able to reset the iODO components. This reset is triggered in case of failure to recover the
component (refer to [IEVC.F3.02.03.08] Manage sensor fusion, selection and conditioning[function]) or when
an order has been received by the VM through TSC Net (refer to [IEVC.F4.32.01] Command iEVC component
reset[function]).

11.6.2 Functions

11.6.2.1 [IEVC.F3.02.03.07] Manage iODO synchronization [function]

Data
• Definition: This function safely pairs iODO driver and iODO. Once pairing occurs the iODO driver
feeds the exchange messages to Odometry application
• Allocated to:
– iODO driver[ci]
• Input:
– iODO Synchronization message[functional variable][VM - iODO interface]
– iODO sample message[functional variable][VM - iODO interface]
– iODO status message[functional variable][VM - iODO interface]
• Output:
– iODO Synchronization message[functional variable][VM - iODO interface]
– iODO cycle sample messages[functional variable][VM - Applications interface]
– iODO status messages[functional variable][VM - Applications interface]
• Sil: 4
• Associated interface:
– VM - iODO interface[ci]
– VM - Applications interface[ci]

The iODO driver sends “iODO synchronization message” to iODO[ci]. Later, iODO replies back with the same
message. This way, iODO driver evaluates the message and pairs with the iODO[ci] accordingly. Then iODO
driver receives acceptable “iODO sample message” and corresponding “iODO status message” that are forwarded
to the Odometry application[ci]. This functionality is illustrated in Fig. 11.10.

11.6. iODO Driver 257 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.10: Synchronization between iODO and Virtual Machine

Once pairing occurs the iODO driver feeds the Odometry application[ci] with the cyclic measurement sample
message.

11.6.2.2 [IEVC.F4.32.03] Command iODO component reset [function]

Data
• Definition: The iODO driver is able to order a reset of the iODO components it is synchronized
with.
• Allocated to:
– iODO driver[ci]
• Input:
– iODO reset orders (VM internal)[functional variable]
• Output:

258 of 750 11.6. iODO Driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– iODO reset order[functional variable][VM - iODO interface]

• Sil: basic
• Associated interface:
– VM - iODO interface[ci]

Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional architecture.

11.6.3 Modes

The iODO driver has no mode.

11.6.4 Interface

• VM - iODO interface[ci]:
Through this interface iODO driver communicates with iODO[ci] by sending and receiving synchroniza-
tion, status message and measurement sample signals. The iODO driver is also able to order a reset of the
component.
• VM - Applications interface[ci]:
Through this interface iODO driver feeds Odometry application[ci] with cyclic measurement samples and
status messages.

Functional Variable
iODO cycle sample messages [functional variable]
Data
– Objective: To provide a cyclic sample measurement from the odometry
sensors for odometry application
– Description: A copy of the newly received iODO sample messages
– Family: Software
– Format: bitarray
– Protocol: VM Built-in IN Variable
– Timing constraints: Cyclic (VM_cycle_time)
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.03.07] Manage iODO synchronization[function]

– Consumed by:

* [IEVC.F3.02.03.08] Manage sensor fusion, selection and condition-

ing[function]

* [IEVC.F4.11.04] Manage iODO BITE test[function]

This message contains a set of iODO sample message[functional variable][VM - iODO

interface] (Refer to [SyAD-R59-SIF-iODO-VM]). It also contains the VM timestamp
and the freshness of the messages in addition to the iODO component timestamp.

11.6. iODO Driver 259 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
iODO status messages [functional variable]
Data
– Objective: To provide a cyclic status of the odometry sensors for odometry
application
– Description: A copy of the newly received iODO status messages
– Family: Software
– Format: bitarray
– Protocol: VM Built-in IN Variable
– Timing constraints: Cyclic (VM_cycle_time)
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.03.07] Manage iODO synchronization[function]

– Consumed by:

* [IEVC.F3.02.03.08] Manage sensor fusion, selection and condition-

ing[function]

* [IEVC.F4.12.02] Publish VM configuration report[function]

* [IEVC.F4.31] Check VM compatibility with sensor compo-
nents[function]

This message contains a set of iODO status message[functional variable][VM - iODO

interface] (Refer to [SyAD-R59-SIF-iODO-VM]).

11.6.5 Parameters

Not applicable.

11.6.6 Requirements

Requirement

The iODO driver shall manage the synchronization between the iODO components of the
Sensor Box and the Odometry application in the Safe Computer. [id:tsc-req-ievc-iodo-drv-
synchronization][p1][s]

The synchronization mechanism shall be compliant with the Sensor Interface Common Protocol.

Requirement

The iODO driver shall synchronize with exactly 2 iODO boards. Once 2 boards are synchronized,
the iODO driver shall not synchronize with any other module unless powered off. [id:tsc-req-ievc-
iodo-drv-synchronization-max][p1][ns]

260 of 750 11.6. iODO Driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The iODO driver shall transmit in a cyclic sample message to the Odometry application, all the
samples acquired from the 2 iODO boards during that cycle [id:tsc-req-ievc-iodo-drv-data-trsmn][p1][s]

Requirement

When providing a message to the Odometry application, the iODO driver shall include the VM
timestamp and freshness information in addition to the iODO component timestamp already present
in the message. [id:tsc-req-ievc-iodo-drv-data-trsm-freshness][p1][s]

Requirement

When requested by the VM or by the odometry application, the iODO driver shall command a reset
of the iODO components of the Sensor Box. [id:tsc-req-ievc-iodo-drv-reset][p1][ns]

Requirement

The iODO driver shall transmit in a cyclic status message to the Odometry application, all the
hardware and software version information and health of the 2 iODO boards during that cycle.
[id:tsc-req-ievc-iodo-drv-status-trsmn][p1][s]

11.6.7 Failure modes

The iODO driver has no specific failure mode.

11.7 iODO BITE module

Important: This component is included in the iEVC Sensor kit[ci]

11.7.1 Description

iODO BITE is a built-in test equipment inside the Sensor box[ci] of iEVC[ci]. Fig. 11.11 depicts this module
inside the iEVC sensor box.

11.7. iODO BITE module 261 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.11: Representation of iODO BITE in sensor box

The iODO BITE equipment is an on-board hardware-in-the-loop test bench for iODO[ci] and for any application,
such as Odometry application[ci], which requires odometry inputs. This module can simulate the iODO input
signals on demand when receiving the adequate test commands through TSC Net[ci] coming from iODO BITE
driver[ci].
The iODO BITE component provides 2 external serial links on which the test messages are exchanged with test lab
devices. These 2 links are called ‘V1’ and ‘V2’. The iODO BITE driver exchanges the various V1/V2 messages
with the iODO BITE.

11.7.2 Functions

11.7.2.1 [IEVC.F3.02.03.13] Simulate sensor signal [function]

Data
• Definition: Upon receiving an enabling test message through TSC Net by means of its interface
with the Virtual machine, this module generates square signals with different frequencies in order
to simulate Wheel pulse generators sensor and secondary sensor. The generated signals are then
passed through iODO boards instead of real sensors data (In this occasion sensors are bypassed by
iODO BITE). When test is disabled (in standby mode), the generated signals correspond to a 500kph
speed.
• Allocated to:
– iODO BITE[ci]
• Input:
– iODO test command message[functional variable][VM - iODO BITE interface]
• Output:
– Simulated PG signal[functional variable][Sensor box - Pulse generator BITE interface]
– Simulated Secondary sensor pulse signal[functional variable][Sensor box - Secondary sensor

262 of 750 11.7. iODO BITE module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

BITE interface]
– Simulated Secondary sensor speed (from serial link)[functional variable][Sensor box - Sec-
ondary sensor BITE interface]
• Sil: basic
• Associated interface:
– Sensor box - Pulse generator BITE interface[ci]
– Sensor box - Secondary sensor BITE interface[ci]
– VM - iODO BITE interface[ci]

The iODO BITE functionally act as sensor simulator by generating dummy signals. Fig. 11.12 depicts the Capella
diagram of iODO BITE.

Figure 11.12: Functional architecture of the iODO BITE sensor signal simulation function

11.7.2.2 [IEVC.F3.03.03.01] Provide V1 and V2 interfaces [function]

Data
• Definition: The iODO BITE Provides the V1 and V2 serial links. These links are used to exchange
the V1 and V2 messages between the iODO BITE driver and the test equipment of a Subset-085
or Subset-103 laboratory. The serial link connectors are in iODO BITE. The iODO BITE driver
communicates with the iODO BITE through Ethernet using TSC Net protocol and exchanges the
V1-V2 messages with the iBTM application.
• Allocated to:
– iODO BITE[ci]
• Input:
– V1 Mode Status message[functional variable][VM - Applications interface][VM - iODO BITE
interface]

11.7. iODO BITE module 263 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– V1 Self-test Report message[functional variable][VM - Applications interface][VM - iODO

BITE interface]
– V1 Link Status message[functional variable][VM - iODO BITE interface]
– V1 Balise Passage Report message[functional variable][VM - Applications interface][VM -
iODO BITE interface]
– V2 data (serial link)[functional variable][Sensor box - V1V2 interface]
– V1 input data (serial link)[functional variable][Sensor box - V1V2 interface]
• Output:
– V2 - ODO data[functional variable][VM - Applications interface][VM - iODO BITE interface]
– V1 Mode Selection message[functional variable][VM - Applications interface][VM - iODO
BITE interface]
– V1 output data (serial link)[functional variable][Sensor box - V1V2 interface]
• Sil: basic
• Associated interface:
– Sensor box - V1V2 interface[ci]
– VM - iODO BITE interface[ci]

The V1 and V2 messages are described in [SyAD-R59-SIF-iODO-VM].

The iODO BITE V1 and V2 interfaces are shown in Fig. 11.13.

264 of 750 11.7. iODO BITE module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.13: Functional architecture iODO BITE V1 and V2 interfaces

11.7.2.3 [IEVC.F4.28.16] Provide status information [function]

Data
• Definition: Provide the version information of the iODO BITE and the status of the BITE signal
(enabled/disabled).
• Allocated to:
– iODO BITE[ci]
• Output:
– iODO BITE status[functional variable][VM - iODO BITE interface]
• Sil: basic
• Associated interface:
– VM - iODO BITE interface[ci]

11.7. iODO BITE module 265 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.7.2.4 [IEVC.F4.32.16] Reset iODO BITE [function]

Data
• Definition: The iODO BITE component resets itself upon reception of a reset order from the iODO
BITE driver
• Allocated to:
– iODO BITE[ci]
• Input:
– iODO BITE reset order[functional variable][VM - iODO BITE interface]
• Sil: basic
• Associated interface:
– VM - iODO BITE interface[ci]

Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional architecture.

11.7.3 Modes

iODO BITE has the following modes:

Table 11.1: Modes of iODO BITE component

Mode Active functions
Standby [IEVC.F3.02.03.13] Simulate sensor signal[function]1
Test [IEVC.F3.02.03.13] Simulate sensor signal[function]
[IEVC.F3.03.03.01] Provide V1 and V2 interfaces[function]
[IEVC.F4.28.16] Provide status information[function]

As long as there is no enabling test command from TSC Net[ci], the iODO BITE stays standby. Before starting the
test, the sensors connectors are unplugged and the iODO BITE will be plugged into the iODO board connectors.
Then, upon the receipt of an enabling test message by iODO BITE driver[ci] the iODO BITE test mode starts to
operate and the simulated sensor signals are generated.

11.7.4 Interface

• VM - iODO BITE interface[ci]

iODO BITE has interface with iODO BITE driver[ci] through Ethernet connection using TSC Net protocol.
This interface is within an internal network which provides routing platform to exchange messages between
Virtual machine[ci] and iODO BITE.
• iODO - iODO BITE interface[ci]
The second iODO BITE interface is with iODO[ci] boards during the test execution. As illustrated in Fig.
11.11 the iODO BITE has 2 connectors which will be plugged into the 2 iODO boards. The first connector
is the re-placer of PG sensor connector and it transmits the simulated PG sensor square signals to the iODO
boards. The second connector is the re-placer of secondary sensor connector and it transmits the simulated
square signals and serial data of the secondary sensor. So, the protocol, type, frequency range and voltage
of data transmission from iODO BITE to the iODO boards are identical to that of sensors as explained in
[SyAD-R57-SIF-iODO-PG] and [SyAD-R58-SIF-iODO-SECONDARY].
1 When in standby mode, the iODO BITE generates sensor signals corresponding to a speed of 500 kph. This is to avoid confusing test

signals with actual sensor signals when the BITE function is not in use.

266 of 750 11.7. iODO BITE module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Sensor box - V1V2 interface[ci]

This is the physical interface between the Sensor box and the Subset-085 laboratory as illustrated in Fig.
11.11. The iODO BITE Provides the V1 and V2 serial links. These links are used to exchange the V1 and
V2 messages between the iODO BITE driver and the test equipment of a Subset-085 laboratory.

11.7.5 Requirements

Requirement

The iODO BITE module shall generate square signals with different frequencies in order to simu-
late Wheel pulse generators sensor and secondary odometry sensors [id:tsc-req-ievc-iodobite-simulated-
signal][p1][ns]

The frequency range and voltage of the signal transmission from iODO BITE to the iODO boards depend
on the type of PG and secondary sensor.

Requirement

The iODO BITE module shall generate the serial data in order to simulate secondary odometry
sensors [id:tsc-req-ievc-iodobite-simulated-serial][p1][ns]

The protocol, type, frequency range of the serial data transmission from iODO BITE to the iODO boards
depend on the type of secondary sensor.

Requirement

The iODO BITE module shall generate the simulated signals based on the command message re-
ceived form the iODO BITE driver. [id:tsc-req-ievc-iodobite-simulated-signal-command][p3][ns]

Requirement

The iODO BITE module shall change the Secondary sensor speed value on the serial link by using a
simulated acceleration that is also provided in the command message received form the iODO BITE
driver. [id:tsc-req-ievc-iodobite-smooth-signal-serial][p1][ns]

The test command message instruct a new Secondary sensor serial speed value and the acceleration to use
to reach this new value starting from the current serial link speed generated by the iODO BITE board.

Requirement

The iODO BITE module shall change the simulated signal frequency using a rate provided in
the command message received form the iODO BITE driver. [id:tsc-req-ievc-iodobite-smooth-signal-
freq][p1][ns]

The iODO BITE shall modify the output frequency continuously to reach the new value received in the
command message using the frequency change rate provided in this message.

The simulating signals are pulses with fixed duty cycle (typically 0.5) and varying frequency from 0 HZ to max-
imum frequency that PG sensor and secondary odometry sensor can generate. The iODO BITE shall be able to
cover this range of frequency and, during the test, generate continuous frequency change smoothly (NOT abruptly)
as illustrated in Fig. 11.14.

11.7. iODO BITE module 267 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.14: iODO BITE simulating pulses

Requirement

The iODO BITE module shall provide the interface for the V1 and V2 serial links as described in
Subset 085. [id:tsc-req-ievc-iodobite-v1-v2][p1][ns]

Requirement

The iODO BITE module shall manage the V1/V2 serial link protocol as described in the appendix
of Subset-085. [id:tsc-req-ievc-iodobite-v1-v2-protocol][p1][ns]

The iODO BITE module shall produce the V1 messages on the V1 serial link based on the V1 messages
received from the iBTM driver over TSC Net. The iODO BITE module shall relay the V1 & V2 messages
received from the V1 & V2 serial link to the iBTM driver over TSC Net.

Requirement

The iODO BITE module shall provide its version information and health status in a cyclic message
to the iODO BITE driver over TSC Net [id:tsc-req-ievc-iodobite-version][p2][ns]

Requirement

The iODO BITE component shall reset itself upon reception of a reset order from the iODO BITE
driver. [id:tsc-req-ievc-iodo-bite-reset][p2][ns]

Requirement

When in standby mode, the iODO BITE component shall generate sensor signals equivalent to a
speed of 500 kph. [id:tsc-req-ievc-iodo-bite-standby][p2][ns]

This is a protection measure in case the iODO BITE remains plugged onto the sensor inputs of the Sensor
box during normal operation.

268 of 750 11.7. iODO BITE module

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.7.6 Failure modes

The iODO BITE has no specific failure mode.

11.8 iODO BITE driver

Important: This component is included in the iEVC Basic kit[ci]

11.8.1 Description

The iODO BITE driver provides the interface between the Virtual Machine inside the Computer Box and the
iODO BITE component inside the Sensor Box.
It relays the command of test signals that need to be generated by the iODO BITE board during the odometry
BITE test. This signal emulates the pulse generator and secondary sensor signals. They are intended to be looped
back through cabling to the inputs of the iODO boards in order to test its correct acquisition and processing.
The iODO BITE driver also behaves as a gateway to exchange the V1/V2 messages between the iBTM application
and the iODO BITE board which provides the standard serial interface that is intended to be used by a Subset-085
or Subset-103 certification laboratory.

11.8. iODO BITE driver 269 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.15: Functional architecture of the iODO BITE driver

11.8.2 Functions

11.8.2.1 [IEVC.F3.02.03.14] Manage iODO BITE [function]

Data
• Definition: This function is responsible for relaying the command that triggers the test of the Odom-
etry acquisition chain. This command message is originated from the Odometry application and is
sent to the iODO BITE board. This function also collects the iODO BITE board status message and
transmits it to the Odometry application.
• Allocated to:
– iODO BITE driver[ci]
• Input:
– iODO BITE status[functional variable][VM - iODO BITE interface]
– iODO test command message[functional variable][VM - iODO BITE interface]
• Output:

270 of 750 11.8. iODO BITE driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– iODO test command message[functional variable][VM - iODO BITE interface]

– iODO BITE status[functional variable][VM - iODO BITE interface]
• Sil: basic
• Associated interface:
– VM - iODO BITE interface[ci]
– VM - Applications interface[ci]

The iODO BITE driver sends iODO_test_command_message to iODO BITE[ci] in order to execute built-in test
of Odometry application[ci]. This testing function is used when the iODO BITE connector is looped back to the
sensor connectors on the Sensor box hardware[ci] panel.

11.8.2.2 [IEVC.F3.03.03.03] Manage V1-V2 serial link [function]

Data
• Definition: The iODO BITE driver component manages the V1/V2 messages exchanged between
the iBTM application and the iODO BITE board. These messages are used to interface the test
equipment of a Subset-085 or Subset-103 certification laboratory.
• Allocated to:
– iODO BITE driver[ci]
• Input:
– V2 - ODO data[functional variable][VM - Applications interface][VM - iODO BITE interface]
– V1 Mode Selection message[functional variable][VM - Applications interface][VM - iODO
BITE interface]
– V1 Mode Status message[functional variable][VM - Applications interface][VM - iODO BITE
interface]
– V1 Self-test Report message[functional variable][VM - Applications interface][VM - iODO
BITE interface]
– V1 Balise Passage Report message[functional variable][VM - Applications interface][VM -
iODO BITE interface]
• Output:
– V2 - ODO data[functional variable][VM - Applications interface][VM - iODO BITE interface]
– V1 Mode Selection message[functional variable][VM - Applications interface][VM - iODO
BITE interface]
– V1 Mode Status message[functional variable][VM - Applications interface][VM - iODO BITE
interface]
– V1 Self-test Report message[functional variable][VM - Applications interface][VM - iODO
BITE interface]
– V1 Balise Passage Report message[functional variable][VM - Applications interface][VM -
iODO BITE interface]
– V1 Link Status message[functional variable][VM - iODO BITE interface]
• Sil: basic
• Associated interface:
– VM - iODO BITE interface[ci]

11.8. iODO BITE driver 271 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– VM - Applications interface[ci]

The V1/V2 interface is a serial link that is managed by the iODO BITE module. The iODO BITE driver commu-
nicates with the iODO BITE module through Ethernet using TSC Net protocol.
The messages are defined in [SyAD-R59-SIF-iODO-VM]

11.8.2.3 [IEVC.F4.32.19] Command iODO BITE component reset [function]

Data
• Definition: The iODO BITE driver is able to order a reset of the iODO BITE components.
• Allocated to:
– iODO BITE driver[ci]
• Input:
– iODO reset orders (VM internal)[functional variable]
• Output:
– iODO BITE reset order[functional variable][VM - iODO BITE interface]
• Sil: basic
• Associated interface:
– VM - iODO BITE interface[ci]

Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional architecture.

11.8.3 Interface

• VM - iODO BITE interface[ci]

Through this interface iODO BITE driver triggers built-in test by sending test command signal to iODO
BITE[ci] and collects the iODO BITE status. The iODO driver is also able to order a reset of the component.
It also exchanges the V1/V2 messages used to interface a Subset-085 or Subset-103 laboratory that certifies
the Eurobalise or Euroloop transmission function.
Refer to [SyAD-R59-SIF-iODO-VM] for a detailed list of the messages.
• VM - Applications interface[ci]/ iBTM application
The iODO BITE driver is interfaced with the iBTM application to exchange the V1 and V2 test
data. The content of some V1 messages can be extended for Subset 103 lab tests.
From the iBTM application to the iODO BITE driver:
– V1 Mode Status message[functional variable][VM - Applications interface][VM - iODO
BITE interface]
– V1 Self-test Report message[functional variable][VM - Applications interface][VM - iODO
BITE interface]
– V1 Balise Passage Report message[functional variable][VM - Applications interface][VM -
iODO BITE interface]
From the iODO BITE driver to the iBTM application:
– V2 - ODO data[functional variable][VM - Applications interface][VM - iODO BITE inter-
face]

272 of 750 11.8. iODO BITE driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– V1 Mode Selection message[functional variable][VM - Applications interface][VM - iODO

BITE interface]
All these messages are also exchanged between the iODO BITE driver and the
iODO BITE component which provides the physical interface. They are described in
[SyAD-R59-SIF-iODO-VM].
• VM - Applications interface[ci]/ Odometry application
The iODO BITE driver is interfaced with the iBTM application to exchange the following vari-
ables:
From the odometry application to the iODO BITE driver:
– iODO test command message[functional variable][VM - iODO BITE interface]
– iODO reset orders (VM internal)[functional variable]
From the iODO BITE driver to the odometry application:
– iODO BITE status[functional variable][VM - iODO BITE interface]

11.8.4 Parameters

Not applicable.

11.8.5 Requirements

Requirement

The iODO BITE driver shall relay the iODO test command message from the Odometry application
to the iODO BITE component, and the iODO BITE status message from the iODO BITE to the
Odometry application. [id:tsc-req-ievc-iodo-bite-drv-iodo-bite][p1][ns]

Requirement

The iODO BITE driver shall relay the V1/V2 interface messages between the iBTM application and
the iODO BITE component. [id:tsc-req-ievc-iodo-bite-drv-v1v2-messages][p1][ns]

The iODO BITE driver shall transfer the V1 messages received from the iBTM application to the iODO
BITE (through TSC Net) and the V1/V2 messages received from the iODO BITE (through TSC Net) to
the iBTM application.

Requirement

The iODO BITE driver shall translate the information to exchanged on the V1/V2 link as specified
in Subset-085 and Subset-103. [id:tsc-req-ievc-iodo-bite-drv-v1v2-messages-translation][p1][ns]

The V1/V2 messages on the serial link are formatted as string, while some of the variables exchanged with
the iBTM application for this V1/V2 link have a different type than string.
The following rules shall apply:
• When constructing an outgoing message, the iODO BITE driver shall add the header string for
company acronym using ‘TSC’. The iBTM application will not provide the header information.
• the iODO BITE driver shall automatically add the separator strings ‘-’ between variables. The iBTM
application will provide only the useful data, not the separator.
• For the ‘V1 Balise Passage Report message’, the iODO BITE driver shall translate the variables val-

11.8. iODO BITE driver 273 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

ues into string based on their types and according to Subset-085 §E.1.3.2 (this translation concerns
basically 4 types bitarray, timestamp, distance and integer)
• When translating a distance, the value ‘Unknown’ shall be translated using only space characters,
and a value ‘Infinity’ using only ‘0’ characters (this last value is used when testing Euroloop)
• When translating the type timestamp, a variable value ‘NA’ shall be translated using only space
characters
• For the ‘V1 Mode Status message’, the last variable ‘Euroloop Key-code’ is optional and only used
to test Euroloop. Therefore, when the corresponding iBTM application integer variable has a value
outside of the range 0-15, it shall not be included in the string message (the string message stops
with the previous variable).
• For the ‘V1 Mode Status message’, when last variable ‘Euroloop Key-code’ has value within 0-15
range, the iODO BITE driver shall translate it in 2 ASCII characters as per Subset-103 G3.3
• For the ‘V1 Mode Selection message’, when the string message does not include the optional ‘Eu-
roloop Key-code’, the corresponding iBTM application integer variable shall be set to 16.
• For the V2 message, the iODO BITE driver shall not transmit the sequence number and CRC to the
iBTM application (there are no corresponding variable defined for these 2 data).

Requirement

When requested by the VM or by the odometry application, the iODO BITE driver shall command
a reset of the iODO BITE component of the Sensor Box. [id:tsc-req-ievc-iodo-bite-drv-reset][p1][ns]

Requirement

The iODO BITE driver shall generate the V1 Link Status message and transmit it to the iODO BITE
board. [id:tsc-req-ievc-iodo-bite-drv-v1-link-status][p1][ns]

11.8.6 Failure modes

The iODO BITE driver has no specific failure mode.

11.9 Computer Box

Important: This component is included in the iEVC Basic kit[ci]

11.9.1 Description

The computer box hardware hosts components necessary to Safe computer[ci] operation. This box protects these
components from external conditions (dust, water) and provides the required external connections to the hosted
components.
There are two variants for the computer box:
• the Computer box[ci] that hosts the Safe computer[ci], the main processing unit of the iEVC. This compo-
nent includes a set of IO board[ci].
• the Computer box extension[ci] that hosts the Safe computer IO Extension[ci], that provides another set of
IO board[ci] to extend the input/output capacity of the Computer box[ci]. There is a dedicated sub network
for the communication between computer box and the extension.

274 of 750 11.9. Computer Box

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.9.2 Modes

The Computer box hardware[ci] is only a recipient of other components. It has no mode.

11.9.3 Functions

Functions are not applicable to this hardware component.

The Computer box power supply[ci], inside the box, implements the following function:

11.9.3.1 [IEVC.F8.02] Supply power to the Computer box [function]

Data
• Definition: This function allows supplying the required power to the components of the Computer
box.
• Allocated to:
– Computer box power supply[ci]
• Sil: basic
• Associated interface:
– Computer box - Power supply interface[ci]

11.9.4 Interface

11.9.4.1 External interfaces

Figure 11.16: Computer box front panel

11.9. Computer Box 275 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.17: Computer box extension front panel

The following external interfaces are applicable to the Computer box hardware:
• iEVC - Train generic interface[ci]
• Computer box - Computer box Extension[ci]
• Computer box power supply[ci]
• Computer box - Ethernet interface[ci]

11.9.4.2 Internal interfaces

Configuration Item

Computer box - IO board internal interface [ci]

Data
• Sil: basic

This interface describes the link between the front panel and I/O board. This interface shall describe
principle of cabling required by IO board to meet safety and availability requirements. The interface
will depend on the choice of I/O board. It may include a direct connection to the external power supply
depending on the model of I/O Board selected (refer to Safe Input acquisition and Safe outputs commands)
.

Configuration Item

Computer box - Safe Computer internal interface [ci]

276 of 750 11.9. Computer Box

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Sil: basic

The following connections are necessary to have an operational power adapter:

• connection to ground;
• link with the front panel connector for external power supply, controlled by the power switch on the
front panel;
• depending on the input range of the Safe computer[ci], a Computer box power supply[ci] may not
be required;
• Ethernet link with the front panel.

11.9.5 Parameters

Parameters are not applicable to this hardware component.

11.9.6 Requirements

Requirement

The Computer box hardware shall be able to host a safe computer rack or extension rack [id:tsc-req-
ievc-ob-cb-hw-req1][p2][ns]

The box shall contains all required elements to fix the hosted components and for the necessary wiring.

11.10 Telecom box hardware

Important: This component is included in the iEVC Telecom kit[ci]

11.10.1 Description

The telecom box hardware hosts the following communication components:

• 1 4G modem[ci],
• 2 GSM-R modem[ci],
• 2 power adapters.
It protects the hosted components from external conditions (dust, water). It allows installation in the train, and
provides the required connections to the hosted components.
The telecom box provides the access point for a tester laptop.

Figure 11.18: Overview of telecom box

278 of 750 11.10. Telecom box hardware

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.10.2 Modes

The Telecom box hardware[ci] is only a recipient of other components. It has no mode.

11.10.3 Functions

The Telecom box hardware[ci] in itself does not implement any system function.
The Telecom box power supply[ci], inside the box, shall implement the following functions:

11.10.3.1 [IEVC.F4.28.04] Telecom box power supply - Provide maintenance and fault informa-
tion [function]

Data
• Definition: Provide maintenance and fault information about the telecom box power supply
• Allocated to:
– Telecom box power supply[ci]
• Input:
– Power supply Maintenance Data request[functional variable]
• Output:
– Power supply Maintenance Data[functional variable]
• Sil: basic

11.10.3.2 [IEVC.F8.03] Supply power to the Telecom box [function]

Data
• Definition: This function allows supplying the required power to the components of the Telecom
box.
• Allocated to:
– Telecom box power supply[ci]
• Sil: basic
• Associated interface:
– Telecom box - power supply interface[ci]

11.10.4 Interface

The Telecom box is a hardware component, only physical interfaces are provided. There are two types of inter-
faces:
• external: for the connection links between hosted components and peripherals/components outside of the
Telecom box. All of these are grouped on the front panel of Telecom box.
• internal: for the connection of the components inside the Telecom box.

11.10. Telecom box hardware 279 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.10.4.1 External interfaces

Figure 11.19: Telecom box front panel

The following external interfaces are applicable to the Telecom box hardware:
• Telecom box - power supply interface[ci]
• Telecom box - 4G antenna interface[ci]
• Telecom box - GPS antenna interface[ci]
• Telecom box - GSM-R antenna interface[ci]
• Telecom box - Ethernet interface[ci] (and including the interface to the tester laptop)
• Grounding point

11.10.4.2 Internal interfaces

Configuration Item

Telecom box - 4G modem internal interface [ci]

Data
• Sil: basic

The following connections are necessary to have an operational 4G modem:

• power supply from the internal power adapter.
• connection to ground.
• link with the front panel connector for Ethernet link with the external Ethernet switch.
• link with the front panel connector for external 4G antenna.

280 of 750 11.10. Telecom box hardware

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• link with the front panel connection for external GPS antenna.

Configuration Item

Telecom box - GSM-R modem internal interface [ci]

Data
• Sil: basic

The following connections are necessary to have an operational GSM-R modem:

• power supply from the internal power adapter.
• connection to ground.
• link with the front panel connector for external GSM-R antenna.
• link with the front panel connector for Ethernet link with the external Ethernet switch. If an
Ethernet / serial converter is required, it will be a part of GSM-R modem[ci].

Configuration Item

Telecom box - power adapter internal interface [ci]

Requirement

The Telecom box hardware shall provide the connectors for 4G and GPS antenna. [id:tsc-req-ievc-ob-
tb-hw-req4][p1][ns]

282 of 750 11.10. Telecom box hardware

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

A single connector is required if the same antenna can be used for 4G signal and GPS signal reception.
The connector format shall be MIL-C like, bayonet and is part of Telecom box - 4G antenna interface and
Telecom box - GPS antenna interface.

Requirement

The maximum power consumption of a GSM-R modem shall be 5W or less. [id:tsc-req-ievc-hw-gsmr-

power][p2][ns]

Requirement

The maximum power consumption of a 4G modem shall be 20W or less. [id:tsc-req-ievc-hw-4g-

power][p2][ns]

Requirement

The Telecom box power supply shall provide maintenance and faults information to the OBOM
[id:tsc-req-ievc-ob-tb-hw-psu-maintenance-and-faults][p2][ns]

The reported faults shall include at least too low and too high voltage.

Requirement

The SIM card slots on the front panel of the Telecom box, if any, shall be designed in such way that
they guarantee that the SIM cards remain in place at all time during operation. [id:tsc-req-ievc-ob-tb-
hw-sim-slot][p2][ns]

11.10.7 Failure modes

The Telecom box hardware[ci] is only a recipient of other components. It has no failure mode.

11.11 TSC Net

Important: This component is included in the iEVC Basic kit[ci]

11.11.1 Description

The TSC Net[ci] provides a messaging system that allows managing communication channels between component.
It provides high performance and unique passage point for all messages within the iEVC.
TSC Net services is based on the TSC Net protocol ([SyAD-R66-SIF-TSC-NET]) to exchange structured data.
The services provided by TSC Net[ci] are :
• create a publish-subscribe communication channel,
• publish data on a communication channel,
• listen a communication channel,
• provide timer service: that consist to request to received a predefined message with a given period,
• provide an unified trace mechanism.

11.11. TSC Net 283 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

TSC Net[ci] is used to transport Safety-related messages but does not implement a Safety layer. Corresponding
protection shall be implemented by the source of the message in the application data. It shall be verified by the
destination components.
In practice, Safe data are transported as binary bloc of data.
TSC Net also reports Maintenance Data to the OBOM that includes:
• the version of TSC Net;
• any fault detected by the protocol. This includes as a minimum the client disconnections detected through a
heartbeat mechanism.
Refer to [SyAD-R66-SIF-TSC-NET] for more details on the implementation of the TSC Net protocol.

11.11.2 Interface

This component is involved in the transport of the messages exchanged on the following interfaces:
• VM - iBTM-TX interface[ci]
• VM - iBTM-RX interface[ci]
• VM - iODO interface[ci]
• VM - iODO BITE interface[ci]
• VM - DMI interface[ci] for non safety related data
• VM - CFM interface[ci]
• VM - OBOM interface[ci]
• DMI - OBOM interface[ci]
• Modem Controller - OBOM interface[ci]
• CFM - Modem Controller interface[ci]
• Sensor Box Ethernet Switch - OBOM interface[ci]
• CPM - OBOM interface[ci]
• NMEA 0183 GPS interface[ci] where TSC Net convert NMEA protocol to TSC Net message
The TSC Net component provides the message TSC Net Maintenance Data[functional variable][TSC Net - OBOM
interface] to OBOM through TSC Net - OBOM interface[ci].

11.11.3 Mode

Refer to [SyAD-R66-SIF-TSC-NET] for a description of the modes applicable to each instance of the TSC Net
sub-component.

11.11.4 Functions

The TSC Net component implements [IEVC.F7] Manage TSC NET network[function]

284 of 750 11.11. TSC Net

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.11.5 Requirements

Requirement

TSC Net shall implement a publish subscribe messaging system [id:tsc-req-ievc-tsc-net-messaging-

system][p1][ns]

The messaging system shall be compliant with the content of ‘TSC Net protocol specification’.

Requirement

TSC Net shall provide a unique order to all messages exchanged [id:tsc-req-ievc-tsc-net-messaging-
order][p1][ns]

TSC Net shall use a timestamp and a sequence number in each exchanged message.

Requirement

A message shall be transmitted across TSC Net channel in less than 10 milliseconds. [id:tsc-req-ievc-
tsc-net-transmission-time][p1][ns]

This requirement is applicable for UDP, TCP and internal protocol with the safe computer.

Requirement

TSC Net shall put a sequence number for each message sent by TSC Net [id:tsc-req-ievc-tsc-net-
sequence][p1][ns]

11.11.6 Failure modes

In case of failure of TSC Net the iEVC is no more operational. Critical alarms will be raised by the iEVC
applications (iBTM, Odometry and DMI application) due to loss of communication with the Sensor Box or the
DMI.

11.12 Virtual Machine

Important: This component is included in the iEVC Basic kit[ci]

11.12.1 Description

The virtual machine (VM) executes applications encoded in the EXS format. EXS stands for ERTMS Executable
Specification. It is the format of modeled iEVC applications once they are compiled in machine code. This ma-
chine code is tailor-made to run inside the virtual machine of the Safe computer of the iEVC On-board subsystem.
The VM executes within the safe domain of a Safe computer[ci] (Safe computer). This safe computer exports the
necessary constraints on the VM to protect its functions against hardware failures, and participates therefore to the
attainment of the required safety integrity level.
In addition, the Safe computer[ci] provides the IO driver[ci] inside the VM with the necessary mechanisms to
access digital inputs and outputs. This is illustrated in the Fig. 11.21 below.

11.12. Virtual Machine 285 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.21: Overview of the VM environment

The virtual machine is a variable-based virtual computer. The iEVC applications read and write variables that are
statically defined for each application at initialization. The VM does not support dynamic memory allocation nor
recursive functional calls.
The term ‘application’ will be used in the rest of this component description to refer to the iEVC applications. The
term ‘configuration files’ or ‘configuration applications’ are used to refer to iEVC Configuration Data files[ci].
The VM provides the applications with access to external resources using drivers. The applications interface with
these drivers by reading and writing special built-in variables that are specific to each driver.
A typical example of driver is the IO driver[ci]. This driver provides access to safe digital inputs and outputs (e.g.
emergency brake releases, switches, . . . )
The VM provides safe communication between the different applications using a configurable sequencer. The
sequencer knows when and where to transfers data between applications.
Therefore, the VM does not manipulate applications individually. It loads a coherent application package, along
with an application package descriptor file that describes the content of the package and that includes the sequencer
information.
During its startup process, the VM loads its VM configuration file which is stored on a non-volatile memory of
the Safe computer[ci]. This file contains the minimal information the VM needs to identify the train it is running
on (ETCS_ID).
The VM is responsible for verifying that the loaded application package is authorized to run. This authorization
is granted by verifying a cryptographic certificate of the application package.
The principle for creating this certificate is the following:
1. For each application file, compute a SHA-256 checksum;
2. For each configuration file, compute a SHA-256 checksum;
3. Verify the list of files and computed checksums are consistent with the list provided in the application
package descriptor file;
4. Calculate a SHA-256 checksum of the application package descriptor file;
5. Compute a signature of this SHA-256 checksum using the RSA algorithm;

286 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

6. Concatenate the ETCS-ID of the iEVC on-board unit with the byte string resulting from the signature
process.
The resulting byte string is the certificate of the application package. The SIDE Authorizer is used to produce this
certificate.
The signature step must be performed by the relevant safety authority of the installation project using the iEVC as
a generic platform. It is done using the RSA private key. This key must never be shared with anyone.
The VM is configured with the corresponding RSA public key. The certificate verification process will therefore
be as follows:
1. Verify that the certificate ETCS_ID matches the VM configuration file ETCS_ID
2. For each loaded application file, recompute the SHA-256 checksum
3. For each loaded configuration file, recompute the SHA-256 checksum
4. Compare the loaded applications and configuration to the content of the loaded application package descrip-
tor file.
5. If match, verify that the format version of the loaded application and configuration files are compatible with
the specific format that this virtual machine can interpret;
6. If match, recompute the SHA-256 checksum of the application package descriptor file, and compare it with
the signature extracted from the certificate using the RSA public key.
7. Verify that the decrypted signature and the application package descriptor file SHA-256 checksum are iden-
tical.

Figure 11.22: Overview of the VM package authorization process

The application package files (application files and configuration files), the application package descriptor file and
the certificates are provided to the VM at startup by the On-Board Operation and Maintenance software (see also
[SyAD-R66-SIF-TSC-NET]).
The general VM-OBOM exchange scenario is illustrated in Fig. 11.23.

11.12. Virtual Machine 287 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.23: Overview of the VM-OBOM components interactions

Finally, the VM can also support the execution of tests using its debug interface. This is only possible when the
VM is in test mode. Request to this mode is made by placing a physical key switch on the (Computer Box) front
panel in the ‘Test’ position (see also [SyAD-R70-SIF-Test-Switch]) and by inputting a randomly generated PIN
code on a specific entry screen of the DMI at start-up.
In the startup process, the test mode is evaluated by the VM as soon as a state VM_LOAD has been reported to
the OBOM.
Tests are controlled from a test tool using the VM debug protocol. This protocol can be used to set and query the
status of any variable of the VM (see also [SyAD-R68-SIF-VM-DBG]).

11.12.2 VM Modes

The virtual machine is described by the combination of two state machines.

• An initialization state machine : describes the status of initialization of the VM and its applications.
• A test mode state machine : informs about whether or not the VM is in test mode (e.g. active or inactive).

288 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.12.2.1 VM Initialization States

The VM goes through the following states during its initialization.

• VM_START: VM is starting.
This is the initial state. In this mode, the VM reads its VM configuration file. Once the VM configuration
file is read successfully, it proceeds to VM_LOADING mode.
From this mode, the VM goes to VM_FAULT mode if it fails to read the VM configuration file.
• VM_LOADING: VM is started and is ready to be uploaded with applications and configuration applications.
In this mode the VM is allowed to enter its test mode (see Test Mode States).
In this mode, the VM loads application and configuration files in memory. It applies the certificate verifica-
tion procedure also called ‘authorization verification’ ([IEVC.F1.05.10] Verify Authorization[function]).
In this mode, the VM verifies the application package certificate that allows it to run the loaded applica-
tions and configuration applications. Once the certificate has been validated, it executes the configuration
code, so that applications now have the correct constant parameters. After the configuration code has been
successfully executed, it reports its state to the OBOM.
From this mode, the VM goes to VM_FAULT mode if one of these conditions occurs:
– the VM fails to load the application package files;
– the certificate verification fails;
– the execution of the configuration code fails.
• VM_READY: VM is ready to run.
In this mode the VM starts the cyclic evaluation of the loaded applications. Once the VM has reach this
mode, it will execute until the next power off of the safe computer or until a transition to VM_FAULT.
In this mode the application variables marked as ‘CONFIGURATION’ cannot be modified anymore by the
executed applications (see iEVC configuration data file).
From this mode, the VM goes to VM_FAULT mode if an application tries to execute a forbidden action
such as (but not limited to):
– read or write a variable for which it has no read or write access;
– write constant or configuration variables;
– dividing by 0
The exhaustive list of forbidden actions shall be documented in the software design documentation.
VM_FAULT can also be triggered when the hardware and software compatibility check with the sensor
components fails (see [IEVC.F4.31] Check VM compatibility with sensor components[function]).
Finally, VM_FAULT could also be explicitly requested by an application when it goes into specific degraded
operating modes. The conditions are then specific to the operating principles of the application and are not
in the scope of the VM component design.
• VM_FAULT: VM has detected a fault and cannot continue to run.
In this mode, the VM refuses to execute evaluation cycles, and positions its safe outputs to a restrictive state.
The restrictive states of the safe outputs implies an application of the emergency brake (see tsc-req-ievc-sw-
vm-fault-eb[req]).

11.12. Virtual Machine 289 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.24: Overview of VM initialization States and functions

11.12.2.2 Test Mode States

The VM can be in the following test states:

• Inactive: The VM is not in test mode.
• Active: the VM is in test mode.
– It shall accept to enable debug protocols. The following function is enabled only while in this test
mode:

* [IEVC.F1.07.05] Implement debug protocol[function]

– When the test mode of the VM is enabled, the authorization process is skipped.
– In test mode, the V1/V2 interface with the Subset-085 certification lab may be used
The transition of the state ‘Active’ to ‘Inactive’ implies a self-reset of the VM to force the execution of the
certificate verification.

290 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.12.3 Functions

Figure 11.25: Overview of the VM functions and their interactions with the OBOM during initialization

11.12.3.1 Initialization

11.12.3.1.1 [IEVC.F1.05.07] Determine initialization status [function]

Data
• Definition: Determine the VM initialization mode and publish this information to interested parties
(e.g. OBOM)
• Allocated to:
– Virtual machine[ci]
• Output:
– VM status message[functional variable][VM - OBOM interface][VM - Safe computer OS in-
terface]
• Sil: 4
• Associated interface:

11.12. Virtual Machine 291 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– VM - OBOM interface[ci]

The VM determines and publishes its initialization status, as described in VM Initialization States. The status is
published cyclically.

11.12.3.1.2 [IEVC.F1.05.15] Read VM config files [function]

Data
• Definition: Load VM configuration file data in memory (e.g. ETCS_ID, cryptographic key)
• Allocated to:
– Virtual machine[ci]
• Input:
– VM config file[functional variable][VM - Safe computer OS interface]
• Sil: 4
• Associated interface:
– VM - Safe computer OS interface[ci]

The VM loads its configuration file, as described in VM configuration file.

11.12.3.1.3 [IEVC.F1.05.08] Load application package files and certificate [function]

Data
• Definition: Load the content of the application package and associated certificate. Verify the content
of the package based on the descriptor file. The VM goes in VM_FAULT in case the verification
fails. If the verification is successful then the VM proceeds to the authorization verification.
• Allocated to:
– Virtual machine[ci]
• Input:
– VM Load application package and certificate[functional variable][VM - OBOM interface]
• Output:
– Application package files correctly loaded[functional variable]
• Sil: 4
• Associated interface:
– VM - OBOM interface[ci]

292 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.12.3.1.4 [IEVC.F1.05.06] Configure applications [function]

Data
• Definition: Executes the configuration code of each configuration application within the address
space of the application to configure
• Allocated to:
– Virtual machine[ci]
• Input:
– Authorization is confirmed[functional variable]
• Sil: 4

This function is the only one where configuration variables can be written. It is executed only once during
VM_LOADING. After that, the configuration variables cannot be modified anymore.

11.12.3.1.5 [IEVC.F1.05.10] Verify Authorization [function]

Data
• Definition: Executes the different verification steps required to authorize the execution of a spe-
cific application package by the VM. (1) It verifies that the certificate ETCS_ID matches the VM
configuration file ETCS_ID. (2) It verifies the SHA-256 checksum of each loaded application and
configuration file is consistent with the content of the application package descriptor file. (3) It
verifies that the format version of the loaded application and configuration files are compatible with
the specific format that this virtual machine can interpret. (4) It verifies that the application package
descriptor SHA-256 checksum matches the signature extracted from the certificate using the VM
public RSA key. If any of the previous verifications fails, then the VM goes to VM_FAULT. When
the VM test mode is enabled, the authorization verification steps are skipped.
• Allocated to:
– Virtual machine[ci]
• Input:
– Application package files correctly loaded[functional variable]
– Test mode enabled[functional variable]
• Output:
– Authorization is confirmed[functional variable]
• Sil: 4

11.12.3.1.6 [IEVC.F1.05.14] Execute an evaluation cycle [function]

Data
• Definition: Evaluates all the rules of the various applications, according to the sequence defined in
the application package descriptor file. Produces, after the execution, a report on the variables hav-
ing been updated, as well as snapshot data necessary to log an execution trace that can be replayed
at a later time.
• Allocated to:

11.12. Virtual Machine 293 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– Virtual machine[ci]
• Input:
– VM status message[functional variable][VM - OBOM interface][VM - Safe computer OS in-
terface]
• Output:
– VM End Cycle Message[functional variable][VM - OBOM interface]
– VM Snapshot Message[functional variable][VM - OBOM interface]
– VM Variable Update Message[functional variable][VM - OBOM interface]
• Sil: 4
• Associated interface:
– VM - OBOM interface[ci]
– VM - Safe computer OS interface[ci]

The cyclic VM execution starts when entering VM_READY mode. It will then keep executing until a power off
of the safe computer or until a transition to VM_FAULT mode.

11.12.3.1.7 [IEVC.F5.09.01] Provide application access to non-volatile operational data [function]

Data
• Definition: Offers built-in functions that can be used by applications to store data on a non-volatile
memory, and read these values when needed (e.g. first cycle of VM_READY).
• Allocated to:
– Virtual machine[ci]
• Input:
– OBOM Log Entry[functional variable][VM - OBOM interface]
– Non volatile data control[functional variable][VM - Safe computer OS interface]
• Output:
– OBOM Log Entry[functional variable][VM - OBOM interface]
– Non volatile data control[functional variable][VM - Safe computer OS interface]
• Sil: 4
• Associated interface:
– VM - OBOM interface[ci]
– VM - Safe computer OS interface[ci]

During a write operation, this function:

• concatenates the ETCS_ID to the data to store
• computes a checksum on the data to store
• stores this checksum on a non-volatile memory of the safe computer
• sends the data for storage to OBOM
During a read operation, this function:
• requests the data stored from OBOM;

294 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• compares the checksum of the received data with the one previously stored on the safe computer, if any;
• provides the data to applications if the checksum control is correct, without the ETCS_ID

11.12.3.2 Test and Debugging

11.12.3.2.1 [IEVC.F1.07.06] Determine Test mode [function]

Data
• Definition: Determines if the VM is in test mode. This function is in charge of verifying the state
of the Test key switch digital input. If this input is enabled at start-up, it requests the display of the
PIN code entry window on the DMI. If the PIN code is entered correctly by the user, then the test
mode is entered by the VM. This function is active when the VM is in state VM_LOAD.
• Allocated to:
– Virtual machine[ci]
• Input:
– Test switch enabled[functional variable]
– Test Mode PIN response[functional variable]
• Output:
– Test mode enabled[functional variable]
– Test Mode PIN Request[functional variable]
• Sil: 4

Figure 11.26: Functional architecture for the determination of the test mode

11.12. Virtual Machine 295 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.12.3.2.2 [IEVC.F1.07.05] Implement debug protocol [function]

Data
• Definition: When in test mode only, provides the necessary mechanism for a debugging tool to:
read and write all variable values and memory areas, stop and resume execution of the VM, perform
step-by-step execution and provide code coverage information at the end of each cycle.
• Allocated to:
– Virtual machine[ci]
• Input:
– Test mode enabled[functional variable]
– VM debug command[functional variable][VM - debug interface]
• Output:
– VM debug reply[functional variable][VM - debug interface]
• Sil: 4
• Associated interface:
– VM - debug interface[ci]

Refer to [SyAD-R68-SIF-VM-DBG] for a detailed description of the different types of VM debug com-
mand[functional variable][VM - debug interface] and VM debug reply[functional variable][VM - debug inter-
face].

11.12.3.3 Faults

The VM is involved in fault computations by providing the LRU application with the basic fault information
collected from OBOM and from the safe computer. Then, after the application is done evaluating the complete
LRU fault status of the iEVC, it provides this information back to OBOM for display and logging purposes.

Note: Refer to [IEVC.F4.08] Display fault synoptic[function] and [IEVC.F4.28] Provide maintenance and fault
information[function] for a description of the related functional architecture.

11.12.3.3.1 [IEVC.F4.28.13] Collect fault information from OBOM [function]

Data
• Definition: Recover the fault information from OBOM, and write this information in a variable that
the LRU application can read.
• Allocated to:
– Virtual machine[ci]
• Input:
– Faults collected by OBOM[functional variable][VM - OBOM interface]
• Output:
– OBOM faults information[functional variable][VM - Applications interface]
• Sil: basic

296 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Associated interface:
– VM - OBOM interface[ci]
– VM - Applications interface[ci]

11.12.3.3.2 [IEVC.F4.28.14] Collect safe computer faults [function]

Data
• Definition: Act as an intermediary to collect the fault status of the safe computer the VM is running
on. Write this information in a variable that the LRU application can read.
• Allocated to:
– Virtual machine[ci]
• Input:
– Safe computer faults[functional variable][VM - Safe computer OS interface]
• Output:
– Safe computer fault information[functional variable]
• Sil: basic
• Associated interface:
– VM - Safe computer OS interface[ci]

11.12.3.3.3 [IEVC.F4.08.02] Publish LRU fault data [function]

Data
• Definition: Act as an intermediary, to recover the result of the computation of LRU fault status by
the LRU application, and provides this information back to OBOM.
• Allocated to:
– Virtual machine[ci]
• Input:
– LRU fault status[functional variable][VM - Applications interface]
• Output:
– LRU fault status Message[functional variable][VM - OBOM interface][DMI - OBOM inter-
face]
• Sil: basic
• Associated interface:
– VM - Applications interface[ci]
– VM - OBOM interface[ci]

11.12. Virtual Machine 297 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.12.3.4 Lifetime data

The VM is involved in the computation of lifetime estimations by providing the LRU application with recorded
lifetime data and LRU maintenance event information (provided by OBOM). When the LRU application is done
evaluating an updated lifetime for all LRUs, the VM transfers the result of this computation to OBOM for logging
and display purposes.

Note: Refer to [IEVC.F4.07] Determine estimated lifetime and trigger lifetime warning.[function] for a descrip-
tion of the related functional architecture.

11.12.3.4.1 [IEVC.F4.07.02] Publish lifetime data and warnings (VM) [function]

Data
• Definition: Publish the lifetime data and warning information to interested parties, as computed by
the LRU application. This function also retrieves the LRU maintenance activity information from
the OBOM and provides it to the LRU application.
• Allocated to:
– Virtual machine[ci]
• Input:
– LRU lifetime data[functional variable][VM - Applications interface]
– LRU lifetime data message[functional variable][VM - OBOM interface][DMI - OBOM inter-
face]
– LRU lifetime warning[functional variable][VM - Applications interface]
– LRU maintenance event message[functional variable][VM - OBOM interface]
• Output:
– LRU lifetime data[functional variable][VM - Applications interface]
– LRU lifetime data message[functional variable][VM - OBOM interface][DMI - OBOM inter-
face]
– LRU lifetime warning message[functional variable][VM - OBOM interface][DMI - OBOM
interface]
– LRU maintenance event[functional variable][VM - Applications interface]
• Sil: basic
• Associated interface:
– VM - Applications interface[ci]
– VM - OBOM interface[ci]

298 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.12.3.5 Configuration

11.12.3.5.1 [IEVC.F4.12.02] Publish VM configuration report [function]

Data
• Definition: Publish a configuration report of the VM and its underlying safe computer platform.
This configuration report also contains the version information of the loaded application package.
• Allocated to:
– Virtual machine[ci]
• Input:
– Safe Computer Configuration Information[functional variable][VM - Safe computer OS inter-
face]
– iBTM-RX status message[functional variable][VM - iBTM-RX interface]
– iBTM-TX status message[functional variable][VM - iBTM-TX interface][VM - Applications
interface]
– iODO status messages[functional variable][VM - Applications interface]
– iODO BITE status[functional variable][VM - iODO BITE interface]
• Output:
– VM Configuration report[functional variable][VM - OBOM interface]
• Sil: basic
• Associated interface:
– VM - Safe computer OS interface[ci]
– VM - Applications interface[ci]
– VM - OBOM interface[ci]

11.12.3.5.2 [IEVC.F4.31] Check VM compatibility with sensor components [function]

Data
• Definition: Verify the compatibility of the Virtual Machine with the hardware and software versions
of the iODO, iODO BITE, iBTM-RX and iBTM-TX components. When an incompatibility is
detected, the VM goes in VM_FAULT mode.
• Allocated to:
– Virtual machine[ci]
• Input:
– iBTM-RX status message[functional variable][VM - iBTM-RX interface]
– iBTM-TX status message[functional variable][VM - iBTM-TX interface][VM - Applications
interface]
– iODO status messages[functional variable][VM - Applications interface]
– iODO BITE status[functional variable][VM - iODO BITE interface]
• Sil: basic
• Associated interface:

11.12. Virtual Machine 299 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– VM - Applications interface[ci]

This compatibility check is executed for each sensor component when the message containing the version infor-
mation is received for the first time and when the version information is modified.

Figure 11.27: VM configuration functions

11.12.3.6 Interactive tests

The VM plays a pure interfacing role between the LRU application and OBOM for interactive testing.

Note: Refer to [IEVC.F4.11] Perform LRU interactive tests[function] for a description of the related functional
architecture.

11.12.3.6.1 [IEVC.F4.11.02] Interface LRU interactive tests (VM) [function]

Data
• Definition: Act as a gateway between the LRU application and OBOM for relaying messages related
to the management of interactive test sessions.
• Allocated to:
– Virtual machine[ci]

300 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Input:
– LRU Interactive Test Input[functional variable][VM - OBOM interface]
– LRU Interactive Test Report[functional variable][VM - OBOM interface]
• Output:
– LRU Interactive Test Input[functional variable][VM - OBOM interface]
– LRU Interactive Test Report[functional variable][VM - OBOM interface]
• Sil: basic
• Associated interface:
– VM - OBOM interface[ci]

11.12.3.7 JRU

The VM recovers the JRU data packets computed by the ETCS messages application, and provides it to OBOM
for logging and event recording purposes.

Note: Refer to [IEVC.F3.02.13] Support data recording for regulatory purposes[function] for a description of
the related functional architecture.

11.12.3.7.1 [IEVC.F3.02.13.02] Publish JRU data [function]

Data
• Definition: Publish the JRU data, as produced by the ETCS messages application, to the OBOM for
logging purpose.
• Allocated to:
– Virtual machine[ci]
• Input:
– JRU Log Entry[functional variable][VM - Applications interface]
• Output:
– OBOM Log Entry[functional variable][VM - OBOM interface]
• Sil: basic
• Associated interface:
– VM - Applications interface[ci]
– VM - OBOM interface[ci]

The VM collects the JRU Log Entry from a built-in variables and publishes it on TSC Net.

11.12. Virtual Machine 301 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.12.3.8 I/O access

The VM contains a built-in IO driver[ci] to interface safe digital inputs and outputs. One of the safe digital input
recovered by the IO driver[ci] corresponds to the test mode key switch. This input is provided to the VM by this
driver.
The associated functions are described in IO driver.

11.12.3.9 Component reset

The VM relays the component software reset orders received through TSC Net to the components of the Sensor
box (iBTM-TX module, iBTM-RX module, iODO module and iODO BITE module).
The VM is also able to reset itself upon reception of a reset order through TSC Net.

Note: Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional archi-
tecture.

11.12.3.9.1 [IEVC.F4.32.04] Relay reset orders [function]

Data
• Definition: Relay the reset orders received from TSC Net to the Safe computer and to the drivers
that control the reset of the Sensor box components reset.
• Allocated to:
– Virtual machine[ci]
• Input:
– Reset orders to VM[functional variable][VM - OBOM interface]
• Output:
– iBTM reset orders (VM internal)[functional variable]
– iODO reset orders (VM internal)[functional variable]
• Sil: basic
• Associated interface:
– VM - OBOM interface[ci]

11.12.3.9.2 [IEVC.F4.32.17] Reset VM [function]

Data
• Definition: Reset the Virtual Machine upon reception of a reset order through TSC Net.
• Allocated to:
– Virtual machine[ci]
• Input:
– VM reset order[functional variable][VM - OBOM interface]
• Sil: basic

302 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Associated interface:
– VM - OBOM interface[ci]

11.12.4 Interfaces

• TSC Net[ci]: Enables the VM to access the network through this protocol.
• VM - OBOM interface[ci]: OBOM communicates with the VM through a dedicated networked interface
using the TSC Net network protocol. Through this interface, OBOM provides the application and config-
uration files, the application package descriptor file and the certificate to the VM during its initialization.
The OBOM logs the VM execution data. The OBOM collects maintenance and faults information from the
VM. The OBOM is also able to provide the VM with reset orders for the Sensor box components and the
VM itself.
• VM - debug interface[ci]: when the VM is in test mode, the interface provides the necessary access for a
debugging tool to:
– read and write all variable values and memory areas,
– stop and resume execution of the VM,
– perform step-by-step execution,
– compute the code coverage at each cycle
Through this interface, maintainers controls the VM test and debug execution using dedicated messages
(refer to [SyAD-R68-SIF-VM-DBG]). The test mode is enabled using a test key switch on the front panel.
• VM - Safe computer OS interface[ci]: The VM is implemented according to the application programming
interface of the Safe computer[ci]. The exact nature of this API is vendor dependent. The VM configuration
file is stored in a dedicated read only memory section of the Safe computer[ci]. The VM also has access to
a non-volatile memory of the safe computer through this interface. This access is used to store a checksum
computed on the applications operational data that needs to be recorded in the CPM.

Functional Variable
Non volatile data control [functional variable]

11.12. Virtual Machine 303 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide a means to verify that the value stored on the non volatile
memory is not corrupted and was stored by the VM. This value is stored on the safe
computer.
– Description: A binary control sum of the concatenation of ETCS_ID and the value
stored.
– Family: Software
– Format: Defined by the safe computer vendor
– Protocol: Defined by the safe computer vendor
– Timing constraints: Event
– Associated interface:

* VM - Safe computer OS interface[ci]

– Produced by:

* [IEVC.F5.09.03] Log non-volatile operational data checksums[function]

* [IEVC.F5.09.01] Provide application access to non-volatile operational
data[function]
– Consumed by:

* [IEVC.F5.09.03] Log non-volatile operational data checksums[function]

* [IEVC.F5.09.01] Provide application access to non-volatile operational
data[function]

This checksum is used when reading back the value, in order to determine if the value read back is
correct.

The VM accesses the digital I/O of the IO boards of the Safe computer through this interface.
The VM reports its VM_FAULT state to the safe computer by providing the information VM status mes-
sage[functional variable][VM - OBOM interface][VM - Safe computer OS interface] through this interface.
When the VM is in VM_FAULT, the safe computer triggers its Fail Safe mode (see Safe computer modes).
• One of the safe digital input recovered by the IO driver[ci] corresponds to the test mode key switch. This
input is provided to the VM by this driver. Refer to IO driver.

Functional Variable
Test mode enabled [functional variable]

304 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: Notify the safe computer that the test mode key switch is in enable position.
– Description: a boolean value. True if test mode is enabled.
– Family: Software
– Type: test_mode_enabled
– Format: bool
– Protocol: VM built-in IN variable
– Timing constraints: Cyclic (VM_cycle_time)
– Produced by:

* [IEVC.F1.07.06] Determine Test mode[function]

– Consumed by:

* [IEVC.F3.02.07.10] Manage Tele-powering mode[function]

* [IEVC.F3.03.03.02] Manage V1 and V2 interfaces[function]
* [IEVC.F1.05.10] Verify Authorization[function]
* [IEVC.F1.07.05] Implement debug protocol[function]

• The VM exchanges built-in variables with the LRU application and the ETCS messages application that are
used in its interface with OBOM. These variables are:
– Variables exchanged with the LRU application

Functional Variable
OBOM faults information [functional variable]
Data

* Objective: To provide fault data collected from OBOM to applications

* Description: copy of the message received from OBOM containing the fault
information collected

* Family: Software
* Type: obom_collected_faults_info
* Format: bitarray
* Protocol: VM built-in IN variable
* Timing constraints: Event
* Associated interface:
· VM - Applications interface[ci]

* Produced by:
· [IEVC.F4.28.13] Collect fault information from OBOM[function]

* Consumed by:
· [IEVC.F4.08.01] Determine LRU faults[function]

11.12. Virtual Machine 305 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The content of the variable is a bitarray with the content of a Faults col-
lected by OBOM[functional variable][VM - OBOM interface] message (see
[SyAD-R62-SIF-OBOM-VM]).

Functional Variable
LRU fault status [functional variable]
Data

* Objective: To provide synthesis of LRU fault status, for OBOM or other pur-
poses.

* Family: Software
* Type: lru_fault_status
* Format: bitarray
* Protocol: VM built-in OUT variable
* Timing constraints: Event
* Associated interface:
· VM - Applications interface[ci]

* Produced by:
· [IEVC.F4.08.01] Determine LRU faults[function]

* Consumed by:
· [IEVC.F3.02.14.03] Map Application variables onto I/O[function]
· [IEVC.F4.08.02] Publish LRU fault data[function]

The content of the variable is a bitarray with the content of a LRU fault status Mes-
sage[functional variable][VM - OBOM interface][DMI - OBOM interface] message (see
[SyAD-R62-SIF-OBOM-VM]).

Functional Variable
LRU lifetime data [functional variable]

306 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data

* Objective: To provide synthesis of LRU lifetime data, for OBOM or other pur-
poses.

* Family: Software
* Type: lru_lifetime_data
* Format: bitarray
* Protocol: VM built-in IN variable, VM built-in OUT variable
* Timing constraints: Event
* Associated interface:
· VM - Applications interface[ci]

* Produced by:
· [IEVC.F4.07.01] Determine LRU lifetime and warnings[function]
· [IEVC.F4.07.02] Publish lifetime data and warnings (VM)[function]

* Consumed by:
· [IEVC.F4.07.01] Determine LRU lifetime and warnings[function]
· [IEVC.F4.07.02] Publish lifetime data and warnings (VM)[function]

The content of the variable is a bitarray with the content of a LRU lifetime data mes-
sage[functional variable][VM - OBOM interface][DMI - OBOM interface] message (see
[SyAD-R62-SIF-OBOM-VM]).

Functional Variable
LRU maintenance event [functional variable]
Data

* Objective: To provide LRU maintenance event information

* Family: Software
* Type: lru_maintenance_event
* Format: bitarray
* Protocol: VM built-in IN variable
* Timing constraints: Event
* Associated interface:
· VM - Applications interface[ci]

* Produced by:
· [IEVC.F4.07.02] Publish lifetime data and warnings (VM)[function]

* Consumed by:
· [IEVC.F4.07.01] Determine LRU lifetime and warnings[function]

The content of the variable is a bitarray with the content of a LRU main-
tenance event message[functional variable][VM - OBOM interface] message (see

11.12. Virtual Machine 307 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

[SyAD-R62-SIF-OBOM-VM]).

Functional Variable
LRU lifetime warning [functional variable]
Data

* Objective: To provide synthesis of LRU lifetime warnings, for OBOM or other

purposes.

* Family: Software
* Type: lru_lifetime_warning
* Format: bitarray
* Protocol: VM built-in OUT variable
* Timing constraints: Event
* Associated interface:
· VM - Applications interface[ci]

* Produced by:
· [IEVC.F4.07.01] Determine LRU lifetime and warnings[function]

* Consumed by:
· [IEVC.F4.07.02] Publish lifetime data and warnings (VM)[function]

The content of the variable is a bitarray with the content of a LRU lifetime warning mes-
sage[functional variable][VM - OBOM interface][DMI - OBOM interface] message (see
[SyAD-R62-SIF-OBOM-VM]).

Functional Variable
Safe computer fault information [functional variable]
Data

* Objective: To provide fault status of the safe computer, including the faults
related to the safe I/O.

* Description: message containing the list of LRU faults reported

* Family: Software
* Type: safe_computer_fault_information
* Protocol: VM built-in IN variable
* Timing constraints: Event
* Produced by:
· [IEVC.F4.28.14] Collect safe computer faults[function]

* Consumed by:
· [IEVC.F4.08.01] Determine LRU faults[function]

The structure of the information is identical to the structure of LRU fault status Mes-
sage[functional variable][VM - OBOM interface][DMI - OBOM interface].

308 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– Variable exchanged with the ETCS messages application

Functional Variable
JRU Log Entry [functional variable]
Data

* Objective: To provide the JRU information to log after a Subset 026 application
execution cycle.

* Description: Message containing the subset 027 compliant messages ready to

be logged by OBOM

* Family: Software
* Type: io_fault_status
* Format: BSON
* Protocol: VM built-in OUT variable
* Timing constraints: Event
* Associated interface:
· VM - Applications interface[ci]

* Produced by:
· [IEVC.F3.02.08.08.04] Encode JRU telegrams[function]
· [IEVC.F3.02.08.08] Decode and encode ETCS telegrams or mes-
sages[function]

* Consumed by:
· [IEVC.F3.02.13.02] Publish JRU data[function]

<JRUBitArray> ::= byte* ; As defined in Subset 027

[<JRUBitArray>] ; collection of maximum 255 elements

• The VM relays reset orders as built-in variables internally to its drivers.

– The following message is provided to the iBTM driver

Functional Variable
iBTM reset orders (VM internal) [functional variable]

11.12. Virtual Machine 309 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data

* Objective: To trigger the reset of one or several of the Sensor box iBTM com-
ponents

* Description: message that details which component(s) must be reset and if the
component has to be reset in 'update mode' in order to update the software of the
component at the next start-up.

* Family: Software
* Type: iBTM_reset_order
* Format: iBTMResetStruct
* Timing constraints: Event
* Produced by:
· [IEVC.F3.02.07.11] Manage iBTM alarms[function]
· [IEVC.F4.32.04] Relay reset orders[function]

* Consumed by:
· [IEVC.F4.32.02] Command iBTM component reset[function]

<Box1TxBoardReset> ::= TRUE | FALSE

<Box1TxBoardReset> <Box1Rx1BoardReset> <Box1Rx2BoardReset>

– The following message is provided to the iODO Driver and the iODO BITE driver

Functional Variable
iODO reset orders (VM internal) [functional variable]

310 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data

* Objective: To trigger the reset of one or both iODO boards, or of the iODO
BITE board.

* Description: message that details which component(s) must be reset and if the
component has to be reset in 'update mode' in order to update the software of the
component at the next start-up.

* Family: Software
* Type: iODO_reset_order, iodo_bite_reset_order
* Format: iODOResetStruc, iODOBiteResetStruct
* Timing constraints: Event
* Produced by:
· [IEVC.F3.02.03.08] Manage sensor fusion, selection and condition-
ing[function]
· [IEVC.F4.32.04] Relay reset orders[function]

* Consumed by:
· [IEVC.F4.32.03] Command iODO component reset[function]
· [IEVC.F4.32.19] Command iODO BITE component reset[function]

<iODO1BoardReset> ::= TRUE | FALSE

<iODO1SoftwareUpdateMode> ::= TRUE | FALSE
<iODO2BoardReset> ::= TRUE | FALSE
<iODO2SoftwareUpdateMode> ::= TRUE | FALSE

<iodo_reset_order> ::= <iODO1BoardReset>

<BoardReset> ::= TRUE | FALSE

<SoftwareUpdateMode> ::= TRUE | FALSE

<iodo_bite_reset_order> ::= <BoardReset>

<iodo_reset_order> | <iodo_bite_reset_order>

– The following message is provided to the DMI driver

Functional Variable
Test Mode PIN Request [functional variable]

11.12. Virtual Machine 311 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data

* Objective: Request to display the Test mode PIN code entry window
on the DMI.

* Description: Structure that contains the PIN code to be entered format-

ted as a string and a boolean that indicates if the entry window needs
to be displayed.

* Family: Software
* Format: test_mode_pin_request
* Protocol: VM internal
* Timing constraints: Event
* Produced by:
· [IEVC.F1.07.06] Determine Test mode[function]

* Consumed by:
· [IEVC.F3.02.09.04] Manage DMI protocol for ETCS
screens[function]

<PIN_code_to_enter_s4> ::= string ; 4 digits string

<Display_PIN_code_entry_window> ::= TRUE | FALSE ; true when
˓→the entry window needs to be displayed

<PIN_code_to_enter_s4> <Display_PIN_code_entry_window>

Functional Variable
Test Mode PIN response [functional variable]
Data

* Objective: Inform the VM about the user entry in the PIN code window
* Description: Structure that contains the entered value as a string and a
boolean that indicates if the entry is complete or not.

* Family: Software
* Type: entered_PIN_code_information
* Format: entered_PIN_code_information_Struct
* Protocol: VM built-in IN variable
* Timing constraints: Event
* Produced by:
· [IEVC.F3.02.09.04] Manage DMI protocol for ETCS
screens[function]

* Consumed by:
· [IEVC.F1.07.06] Determine Test mode[function]

312 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

<entered_PIN_code_s4> ::= string ; 4 digits string

<PIN_code_AcceptedByDriver> ::= TRUE | FALSE ; Indicates if
˓→the entered value has been accepted by the driver.

<entered_PIN_code_s4> <AcceptedByDriver>

When the entry is canceled by the driver (by pressing ‘close’), the boolean is set to
‘True’ while the string remains empty.

• The following variable is internal to the VM:

Functional Variable
Authorization is confirmed [functional variable]
Data
• Objective: inform VM software modules that authorization to run applications has been
confirmed;
• Description: message internal to the VM.
• Family: Software
• Format: boolean
• Timing constraints: Event
• Produced by:
– [IEVC.F1.05.10] Verify Authorization[function]
• Consumed by:
– [IEVC.F1.05.06] Configure applications[function]

Functional Variable
Application package files correctly loaded [functional variable]
Data
• Objective: trigger the application package authorization verification
• Family: Software
• Type: boolean
• Format: BSON
• Timing constraints: Event
• Produced by:
– [IEVC.F1.05.08] Load application package files and certificate[function]
• Consumed by:
– [IEVC.F1.05.10] Verify Authorization[function]

11.12. Virtual Machine 313 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.12.5 VM files

The detailed description of the VM file format is provided in the iEVC software design documentation. An
overview of each type of file is provided hereafter.

11.12.5.1 VM configuration file

The VM configuration file contains the minimal information that the VM needs to identify the train it is running
on (ETCS_ID) and authenticate the application package it is supposed to run (RSA public key). It is stored in
a dedicated read only memory section of the Safe computer[ci] and is loaded at start-up through the VM - Safe
computer OS interface[ci].

Functional Variable
VM config file [functional variable]
Data
• Objective: To provide the VM with its configuration data
• Description: JSON file containing the VM configuration data
• Family: Software
• Type: File
• Format: JSON
• Protocol: Safe computer vendor dependent
• Timing constraints: Event
• Associated interface:
– VM - Safe computer OS interface[ci]
• Produced by:
– [IEVC.F1.05.17] Provide VM Config files[function]
• Consumed by:
– [IEVC.F1.05.15] Read VM config files[function]

The VM config file contains the following information:

• ETCS_ID
• The public RSA key used to verify application package authorization
• Specific VM software parameters (the exact list of these parameters is specified by the VM software
documentation)
The file contains a SHA-256 sum of its content, allowing the VM to verify it is not corrupted.

314 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.12.5.2 iEVC Application file

VM shall verify that the content of the application package is consistent with the application package
file descriptor content during initialization. [id:tsc-req-ievc-sw-vm-app-data-valid-package][p1][s]

The VM shall verify that:

• each file is listed in the descriptor file
• the checksum provided in the descriptor file is correct for each application package file
The VM initialization shall go to VM_FAULT when one of these verifications fails.

Requirement

VM shall execute the iEVC configuration application during initialization. [id:tsc-req-ievc-sw-vm-

conf-execution][p1][ns]

The iEVC configuration applications shall overwrite the configuration variables.

The configuration applications cannot be executed anymore when the VM is in VM_READY mode.

316 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

VM shall verify the application package certificate, and proceed to VM_FAULT status in case a
mismatch is found. When the test mode of the VM is enabled, the authorization process is skipped.
[id:tsc-req-ievc-sw-vm-app-package-checksum][p1][s]

The VM is configured with a RSA public key. The certificate verification process shall be as follows:
1. For each loaded application file, recompute the SHA-256 checksum
2. For each loaded configuration file, recompute the SHA-256 checksum
3. Compare the loaded applications and configuration to the content of the loaded application package
descriptor file.
4. If match, verify that the format version of the loaded application and configuration files are compat-
ible with the specific format that this virtual machine can interpret;
5. If match, recompute the SHA-256 checksum of the application package descriptor file, and compare
it with the signature extracted from the certificate using the RSA public key.
6. Verify that the decrypted signature and the application package descriptor file SHA-256 checksum
are identical.

Requirement

VM shall verify the ETCS_ID contained in the application package certificate is identical to the
ETCS_ID from its VM configuration file. It shall proceed to VM_FAULT status in case a mismatch
is found. [id:tsc-req-ievc-sw-vm-app-package-certificate-etcs-id][p1][s]

Requirement

During its cyclic execution, VM shall evaluate all the rules of the various applications according to
the sequence defined in the application package descriptor file. It shall produce, after each cycle, a
report on the variables having been updated, as well as snapshot data necessary to log an execution
trace. [id:tsc-req-ievc-sw-vm-cyclic-execution][p1][s]

Requirement

VM shall provide applications with an access to non-volatile memory in order for them to store their
operational data. [id:tsc-req-ievc-sw-vm-nv-data][p1][ns]

This access is used to store the iEVC applications operational data inside the CPM. A checksum computed
on this data is also stored in a non-volatile memory of the safe computer. The checksum is used to verify
the integrity of the data when loading it from the CPM.

Requirement

When the integrity of the operational data is not verified, the VM shall report this to the iEVC
applications. [id:tsc-req-ievc-sw-vm-nv-data-corrupted][p1][s]

Requirement

VM shall determine its test mode based on the status of the digital input connected to the test key
switch of the computer box, and based on the correct input of a randomly generated PIN code on
the DMI. [id:tsc-req-ievc-sw-vm-test-mode][p1][ns]

11.12. Virtual Machine 317 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

When Test mode key switch is activated, and before switching to test mode, the VM shall ask an
acknowledgement in the form of a randomly generated pin code that has to be entered on the DMI
[id:tsc-req-ievc-vm-test-mode-random-pin][p1][ns]

Requirement

The Virtual Machine shall only enter test mode during its initialization (when in VM_LOAD state).
[id:tsc-req-ievc-vm-test-mode-during-initialization][p1][ns]

Requirement

VM shall implement a debug protocol that is active only when the VM test mode is enabled. [id:tsc-
req-ievc-sw-vm-debug][p1][ns]

The debug commands are specified in ‘Virtual Machine Debug Interface Specification’.

Requirement

VM shall collect the fault information provided by the OBOM and store the information in built-in
variables that can be accessed by the LRU application. [id:tsc-req-ievc-sw-vm-obom-faults][p1][ns]

Requirement

VM shall collect the fault information provided by the Safe computer and store the information in
built-in variables that can be accessed by the LRU application. [id:tsc-req-ievc-sw-vm-safe-computer-
faults][p1][ns]

Requirement

VM shall collect the LRU fault information computed by the LRU application and provide it to the
OBOM. [id:tsc-req-ievc-sw-vm-faults-report][p1][ns]

Requirement

VM shall collect the LRU lifetime data and warning information provided by the LRU application
and send it to the OBOM. At start-up it shall also provide the past lifetime data and warnings recov-
ered from the CPM by the OBOM to the LRU application. [id:tsc-req-ievc-sw-vm-lifetime-data][p1][ns]

Requirement

VM shall collect from the OBOM the maintenance operations logged by the user on DMI and pro-
vide it to the LRU application [id:tsc-req-ievc-sw-vm-logged-maintenance-operation][p1][ns]

Requirement

VM shall publish in a cyclic message to the OBOM a report of its configuration including the loaded
application package information and including the configuration of the safe computer [id:tsc-req-
ievc-sw-vm-configuration-report][p1][ns]

318 of 750 11.12. Virtual Machine

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

At start-up, or upon modification of the related information, VM shall verify its compatibility with
the hardware and software versions of the iODO, iODO BITE, iBTM-RX and iBTM-TX compo-
nents. When an incompatibility is detected, the VM shall go in VM_FAULT mode. [id:tsc-req-ievc-
sw-vm-compatibility-check][p1][ns]

Requirement

VM shall relay the messages related to interactive LRU tests between the LRU application and the
OBOM. [id:tsc-req-ievc-sw-vm-interactive-test][p1][ns]

Requirement

VM shall relay the juridical data produced by the ETCS messages application to the OBOM. [id:tsc-
req-ievc-sw-vm-jru-data][p1][ns]

Requirement

VM shall relay the reset orders received through TSC Net to the drivers that control the reset of the
Sensor box components. [id:tsc-req-ievc-sw-vm-relay-reset][p1][ns]

Requirement

VM shall reset itself upon reception of a VM reset order through TSC Net. [id:tsc-req-ievc-sw-vm-
reset][p1][ns]

Requirement

When in VM_FAULT mode, the VM shall command the emergency brake by setting its safe output
to a restrictive state. [id:tsc-req-ievc-sw-vm-fault-eb][p1][s]

This means that the train interface must be designed to associate the emergency brake application to the
restrictive default position of the safe output.

Requirement

VM shall allow write access to a built-in variable to only one application, provided this variable has
been reserved. [id:tsc-req-ievc-sw-vm-app-package-biv][p1][ns]

Requirement

When VM goes from test mode to non-test mode, it shall reset itself. It shall restart completely its
initialization process. [id:tsc-req-ievc-sw-vm-test-exit][p1][ns]

In test mode the authorization verification process may have been skipped. Variables may have been
modified. Therefore it needs to reset its memory, load once again the application package files and undergo
the authorization verification process to make sure it is allowed to execute the applications in non-test
mode.

Requirement

The VM shall allow the modification of variables marked as ‘configuration’ variables only when in
VM_LOADING mode and only to an application marked as a ‘configuration’ application. [id:tsc-

11.12. Virtual Machine 319 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

req-ievc-sw-vm-protect-constant-variables][p1][ns]

Requirement

The VM shall support the safety demonstration of the applications by allowing them to use bespoke
modelling logic. [id:tsc-req-ievc-sw-vm-bespoke-logic][p1][ns]

The VM shall implement instruction sets at software level to allow writing bespoke logic. This supports
safety demonstration by allowing to decompile the logic.

Requirement

The VM shall go to VM_FAULT when a system failure is reported by the signalling application.
[id:tsc-req-ievc-sw-vm-system-failure-from-app][p1][s]

The boolean variable ‘request_VM_fault’ shall be used. A reason (a string) for the VM_FAULT request
shall also be provided by the signalling application.

11.12.7 Failure modes

In case of failure detected during its execution, the VM shall transition to the VM_FAULT status (Failure man-
agement strategy). The VM can only exit this state by being re-initialized completely.

11.13 Euroradio Safe Functional Module driver

Important: This component is included in the iEVC Basic kit[ci]

11.13.1 Description

The SFM[ci] is a driver of the Virtual machine[ci] that provides access to the Euroradio protocol stack. In par-
ticular this component provides the safe services primitives as described by [SyAD-R10-SS37]. These services
perform:
• Safe connection set-up and release;
• Safe data transfer;
• Error reporting;
• Transfer priority data (this service is only available when connected to an infrastructure in CS mode);
Other services of the [SyAD-R10-SS37] are performed by CFM[ci] component as shown by figure Fig. 11.28.

320 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.28: Euroradio stack architecture

The interface with OBOM[ci] is presented by figure Fig. 11.29:

11.13. Euroradio Safe Functional Module driver 321 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.29: Euroradio maintenance architecture

11.13.2 Functions

Figure 11.30: Euroradio Safe Functional Module driver architecture

322 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.13.2.1 [IEVC.F3.02.08.05] Manage safe Euroradio layer [function]

Data
• Definition: Set of functions that manage safe layer of the Euroradio layer.
• Allocated to:
– SFM[ci]
• Sil: 4
• Associated interface:
– VM - Applications interface[ci]
– VM - CFM interface[ci]
• Sub functions:
– [IEVC.F3.02.08.05.01] Manage network Registration[function]
– [IEVC.F3.02.08.05.02] Setup a Safe connection[function]
– [IEVC.F3.02.08.05.03] Transfer Safe data[function]

This function is described the section 7 of [SyAD-R10-SS37]. Main Sub functions are:

11.13.2.1.1 [IEVC.F3.02.08.05.01] Manage network Registration [function]

Data
• Definition: This function exchanges with the CFM module in order to register to one or several
networks.
• Allocated to:
– SFM[ci]
• Input:
– Configure EURORADIO transport protocol indication[functional variable][VM - CFM inter-
face]
– T-REGISTRATION.indication[functional variable][VM - CFM interface]
– T-PERMISSION.indication[functional variable][VM - CFM interface]
– Sa-REGISTRATION.request[functional variable][VM - Applications interface]
– Sa-PERMISSION.request[functional variable][VM - Applications interface]
– Mobile Available (From CFM)[functional variable][VM - CFM interface]
• Output:
– Configure EURORADIO transport protocol[functional variable][VM - CFM interface]
– T-REGISTRATION.request[functional variable][VM - CFM interface]
– T-PERMISSION.request[functional variable][VM - CFM interface]
– Sa-PERMISSION.indication[functional variable][VM - Applications interface]
– Sa-REGISTRATION.indication[functional variable][VM - Applications interface]
– Mobile Available (From SFM)[functional variable][VM - Applications interface]
• Sil: basic

11.13. Euroradio Safe Functional Module driver 323 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Associated interface:
– VM - CFM interface[ci]
– VM - Applications interface[ci]

The request for a list of permitted network and the registration to a network are illustrated in Fig. 11.31 and Fig.
11.32.

Figure 11.31: Example of network operation (simplified view)

324 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.32: GSM-R network registration (simplified view)

11.13.2.1.2 [IEVC.F3.02.08.05.02] Setup a Safe connection [function]

Data
• Definition: This function setup connection with an RBC by the execution of the safety procedure
'peer entity authentication' of the SUBSET 037.
• Allocated to:
– SFM[ci]
• Input:
– T-CONNECT.confirmation[functional variable][VM - CFM interface]
– T-DISCONNECT.indication[functional variable][VM - CFM interface]
– Sa-CONNECT.request[functional variable][VM - Applications interface]
– Sa-DISCONNECT.request[functional variable][VM - Applications interface]
– CS mode protocol parameter[functional variable][VM - Applications interface]

11.13. Euroradio Safe Functional Module driver 325 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– PS mode protocol parameter[functional variable][VM - Applications interface]

• Output:
– T-CONNECT.request[functional variable][VM - CFM interface]
– Sa-DISCONNECT.indication[functional variable][VM - Applications interface]
– T-DISCONNECT.request[functional variable][VM - CFM interface]
– Sa-CONNECT.confirm[functional variable][VM - Applications interface]
• Sil: 4
• Associated interface:
– VM - CFM interface[ci]
– VM - Applications interface[ci]

The summarized by the figure Fig. 11.33:

Figure 11.33: Setup a connection with an RBC (simplified view)

326 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.13.2.1.3 [IEVC.F3.02.08.05.03] Transfer Safe data [function]

Data
• Definition: This function provide an exchange of user data in both directions simultaneously. This
function is described in detail by procedures of section 'Message origin authentication / Message
integrity' of the SUBSET 037
• Allocated to:
– SFM[ci]
• Input:
– T-HP-DATA.indication[functional variable][VM - CFM interface]
– T-DATA.indication[functional variable][VM - CFM interface]
– Sa-DATA.request[functional variable][VM - Applications interface]
• Output:
– T-DATA.request[functional variable][VM - CFM interface]
– Sa-HP-DATA.indication[functional variable][VM - Applications interface]
– Sa-DATA.indication[functional variable][VM - Applications interface]
• Sil: 4
• Associated interface:
– VM - CFM interface[ci]
– VM - Applications interface[ci]

The data transfer is summarized by the figures Fig. 11.34 and Fig. 11.35:

11.13. Euroradio Safe Functional Module driver 327 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.34: Data operation exchange outgoing messages (simplified view)

328 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.35: Data operation exchange incoming messages (simplified view)

11.13.3 Interface

The SFM[ci] use the following interface :

• VM - CFM interface[ci]: this is the interface between SFM[ci] and CFM[ci] and it is based on TSC Net[ci];
• VM - Applications interface[ci].
In this interface, the VM built-in OUT variable is kept empty when the message is not relevant. When not
empty, the corresponding message is considered as present in the interface.
The Virtual machine[ci] exchanges following variable with applications:
From Subset 026 Application and for each RBC communication channel:

Functional Variable
CS mode protocol parameter [functional variable]

11.13. Euroradio Safe Functional Module driver 329 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: Determine the parameter required by the CS mode operation
– Description: Structure that contains parameter value to use by the CS mode.
– Family: Software
– Type: CSModeParameterStruct
– Format: Structure defined using the VM BNF syntax
– Protocol: VM built-in OUT variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.08.01] Manage RBC connection[function]

– Consumed by:

* [IEVC.SW.SFM.REQ.CONNECTION] Request RBC connection[function]

* [IEVC.F3.02.08.05.02] Setup a Safe connection[function]

<cs_windows_size> ::= e_int32 ; Window size value, valid value: 1 - 127

<cs_t1> ::= e_int32 ; Acknowledge time in ms
<cs_t2> ::= e_int32 ; Local processing delay time in ms
<cs_t3> ::= e_int32 ; Out of service time in ms
<cs_t4> ::= e_int32 ; Inactivity time in ms
<cs_n1> ::= e_int32 ; Maximum number of bits an a frame
<cs_n2> ::= e_int32 ; Maximum number of re-transmission
˓→attempts

<cs_windows_size> <cs_t1> <cs_t2> <cs_t3> <cs_t4> <cs_n1> <cs_n2>

Notes:
– See cs_windows_size[functional variable] (CFM)
– See cs_t1[functional variable] (CFM)
– See cs_t2[functional variable] (CFM)
– See cs_t3[functional variable] (CFM)
– See cs_t4[functional variable] (CFM)
– See cs_N1[functional variable] (CFM)
– See cs_N2[functional variable] (CFM)

Functional Variable
PS mode protocol parameter [functional variable]

330 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: Determine the parameter required by the PS mode operation
– Description: Structure that contains parameter value to use by the PS mode.
– Family: Software
– Type: PSModeParameterStruct
– Format: Structure defined using the VM BNF syntax
– Protocol: VM built-in OUT variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.08.01] Manage RBC connection[function]

– Consumed by:

* [IEVC.SW.SFM.REQ.CONNECTION] Request RBC connection[function]

* [IEVC.F3.02.08.05.02] Setup a Safe connection[function]

<ps_p1> ::= e_int32 ; TcpKeepAliveTime

<ps_p2> ::= e_int32 ; TcpKeepAliveInterval
<ps_p3> ::= e_int32 ; TcpKeepAliveProbes
<ps_p4> ::= e_int32 ; TcpUserTimeout
<ps_p5> ::= e_int32 ; Max TCP segment size

<ps_p1> <ps_p2> <ps_p3> <ps_p4> <ps_p5>

Notes:
– See ps_p1[functional variable] (CFM)
– See ps_p2[functional variable] (CFM)
– See ps_p3[functional variable] (CFM)
– See ps_p4[functional variable] (CFM)
– See ps_p5[functional variable] (CFM)

Functional Variable
Sa-REGISTRATION.request [functional variable]

11.13. Euroradio Safe Functional Module driver 331 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To register to mobile network.
– Description: Structure that contains the identifiers of the network(s) to connect
– Family: Software
– Type: SFM.OUT.SaREGISTRATION.RequestStruct
– Format: RegisteringRequestStruct
– Protocol: VM built-in OUT variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.08.01] Manage RBC connection[function]

– Consumed by:

* [IEVC.SW.SFM.REQ.REGISTRATION] Request network registra-

tion[function]

* [IEVC.F3.02.08.05.01] Manage network Registration[function]

[<MNID>]

Notes:
– ‘Sa-REGISTRATION.request’ in Subset 037
– See MNID[functional variable]

Functional Variable
Sa-CONNECT.request [functional variable]

332 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To establish a connection to a RBC
– Description: Structure that contains identify of the RBC (ETCS ID) to contact, net-
work address or calling code (For CS mode) and the identifier of mobile network to
use.
– Family: Software
– Type: SFM.OUT.SaCONNECT.RequestStruct
– Format: ContactOrderStruct
– Protocol: VM built-in OUT variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.08.01] Manage RBC connection[function]

– Consumed by:

* [IEVC.SW.SFM.REQ.CONNECTION] Request RBC connection[function]

* [IEVC.F3.02.08.05.02] Setup a Safe connection[function]

<CallingETCSId> ::= <NID_ENGINE>

<CallingETCSIdType> ::= <ETCSIdType>
<CalledETCSIdType> ::= <ETCSIdType>
<CalledETCSId> ::= <RBCETCSId>
<preferred_connection_mode> ::= <connection_mode> ; Connection mode
˓→requested by application, but may be changed by CFM

<CallingETCSId> <CallingETCSIdType> <ApplicationType> <CalledETCSIdType>

˓→<CalledETCSId> <AddressType> <NetworkAddress> <MNID> <preferred_

˓→connection_mode> <KMAC_Authentication_Key>

Notes:
– ‘Sa-CONNECT.request’ in Subset 037
– See NID_ENGINE[functional variable]
– See ETCSIdType[functional variable]
– See ApplicationType[functional variable]
– See AddressType[functional variable]
– See NetworkAddress[functional variable]
– See MNID[functional variable]
– See RBCETCSId[functional variable]
– See connection_mode[functional variable]
– See KMAC_Authentication_Key[functional variable]
– <preferred_connection_mode> should be used as follows (refer to Subset 037 8.4.1.9 & An-
nex I):

11.13. Euroradio Safe Functional Module driver 333 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

* CS mode: RBC is present in Transmission Mode Table and is associated to CS mode;

* PS mode: RBC is present in Transmission Mode Table and is associated to PS mode;
* unknown mode: RBC is not present yet in Transmission Mode Table.

Functional Variable
Sa-DISCONNECT.request [functional variable]
Data
– Objective: To stop a connection to a RBC.
– Description: Structure that contains the connection identifier (SaCEPID) and the
reason/sub-reason
– Family: Software
– Type: SFM.OUT.SaDISCONNECT.RequestStruct
– Format: DisconnectStruct
– Protocol: VM built-in OUT variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Consumed by:

* [IEVC.SW.SFM.REQ.DISCONNECTION] Request RBC disconnec-

tion[function]

* [IEVC.F3.02.08.05.02] Setup a Safe connection[function]

<SaCEPID> <DisconnectReason> <DisconnectSubReason>

Notes:
– ‘Sa-DISCONNECT.request’ in Subset 037
– See SaCEPID[functional variable]
– See DisconnectReason[functional variable]
– See DisconnectSubReason[functional variable]

Functional Variable
Sa-PERMISSION.request [functional variable]

334 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To request the list of permitted mobile network.
– Description: Request to establish the list of permitted network. This message contains
an empty list of Mobile Network Id.
– Family: Software
– Type: SFM.OUT.SaPERMISSION.RequestStruct
– Format: RequestEnum
– Protocol: VM built-in OUT variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.08.01] Manage RBC connection[function]

– Consumed by:

* [IEVC.SW.SFM.REQ.PERMITTED] Request list of permitted net-

works[function]

* [IEVC.F3.02.08.05.01] Manage network Registration[function]

[<MNID>]

Notes:
– ‘Sa-PERMISSION.request’ in Subset 037
– See MNID[functional variable]

To Subset 026 Application and for each RBC communication channel:

Functional Variable
Sa-REGISTRATION.indication [functional variable]

11.13. Euroradio Safe Functional Module driver 335 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide the status of network registration
– Description: List of the registered networks
– Family: Software
– Type: SFM.IN.SaREGISTRATION.IndicationStruct
– Format: NetworkRegistrationStatus
– Protocol: VM built-in IN variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.SW.SFM.RESP.STATUS] Provide modem status[function]

* [IEVC.F3.02.08.05.01] Manage network Registration[function]
– Consumed by:

* [IEVC.F3.02.08.01] Manage RBC connection[function]

The message contains the list of MNID of the registered networks.

<MobileNetworkName> ::= e_string ; max 32 characters

[<MNID> <MobileNetworkName>]

Notes:
– Replaces ‘Sa-REGISTRATION.indication’ in Subset 037
– See MNID[functional variable]

Functional Variable
Sa-CONNECT.confirm [functional variable]

336 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide the status of the RBC connection.
– Description: List of the status of RBC connection.
– Family: Software
– Type: SFM.IN.SaCONNECT.ConfirmStruct
– Format: SafeConnectionStatus
– Protocol: VM built-in IN variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.SW.SFM.RESP.STATUS] Provide modem status[function]

* [IEVC.F3.02.08.05.02] Setup a Safe connection[function]
– Consumed by:

* [IEVC.F3.02.08.01] Manage RBC connection[function]

The message contains the identifier of the RBC (its ETCS_ID), the ETCS ID type and the status of
the connection in the form of an enumeration that has the possible values:

<RespondingETCSId> ::= <RBCETCSId>

<SaCEPID> <RespondingETCSId> <RespondingETCSIdType>

Notes:
– ‘Sa-CONNECT.confirm’ in Subset 037
– See SaCEPID[functional variable]
– See RBCETCSId[functional variable]
– See ETCSIdType[functional variable]
– See connection_mode[functional variable]

Functional Variable
Sa-PERMISSION.indication [functional variable]

11.13. Euroradio Safe Functional Module driver 337 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide the list of permitted mobile networks.
– Description: List of permitted network identifiers (MNID)
– Family: Software
– Type: SFM.IN.SaPERMISSION.IndicationStruct
– Format: Collection of string
– Protocol: VM built-in IN variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.SW.SFM.RESP.PERMITTED] Provide list of permitted net-

works[function]

* [IEVC.F3.02.08.05.01] Manage network Registration[function]

– Consumed by:

* [IEVC.F3.02.08.01] Manage RBC connection[function]

<MobileNetworkName> ::= e_string ; max 32 characters

[<MNID> <MobileNetworkName>]

Notes:
– ‘Sa-PERMISSION.indication’ in Subset 037
– See MNID[functional variable]

Functional Variable
Sa-DISCONNECT.indication [functional variable]

338 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide error on each communication channel.
– Description: Error code when an error is reported
– Family: Software
– Type: SFM.IN.SaDISCONNECT.IndicationStruct
– Format: Structure defined using the VM BNF syntax
– Protocol: VM built-in IN variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.SW.SFM.RESP.STATUS] Provide modem status[function]

* [IEVC.F3.02.08.05.02] Setup a Safe connection[function]
– Consumed by:

* [IEVC.F3.02.08.01] Manage RBC connection[function]

<SaCEPID> <DisconnectReason> <DisconnectSubReason>

Notes:
– ‘Sa-DISCONNECT.indication’ in Subset 037
– See SaCEPID[functional variable]
– See DisconnectReason[functional variable]
– See DisconnectSubReason[functional variable]

To Subset 026 Application:

Functional Variable
Mobile Available (From SFM) [functional variable]

11.13. Euroradio Safe Functional Module driver 339 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: Informs Subset 026 if there is at least one mobile terminal available for
use.
– Description: Boolean variable provided by CFM component and originated by the
Modem controller. The variable is true when at least one GSM-R mobile is available
for use.
– Family: Software
– Type: Boolean
– Protocol: VM built-in IN variable
– Timing constraints: Cyclic (5s)
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.08.05.01] Manage network Registration[function]

– Consumed by:

* [IEVC.F3.02.08.01] Manage RBC connection[function]

From ETCS messages application

Functional Variable
Sa-DATA.request [functional variable]
Data
– Objective: To provide ETCS message to sent on the network
– Description: ETCS message without safe protection.
– Family: Software
– Type: SFM.OUT.SaDATA.RequestStruct
– Format: bitarray defined in Subset 026 Chapters 7 and 8, with the identification of the
destination RBC
– Protocol: VM built-in OUT variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.08.08.03] Encode Euroradio messages[function]

* [IEVC.F3.02.08.08] Decode and encode ETCS telegrams or messages[function]
– Consumed by:

* [IEVC.SW.SFM.DATA.SEND] Send data[function]

* [IEVC.F3.02.08.05.03] Transfer Safe data[function]

340 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

<SaCEPID> <SaUserData> <SaUserDataLMessage>

Notes:
– ‘Sa-DATA.request’ in Subset 037
– See SaCEPID[functional variable]
– See SaUserData[functional variable]
– See SaUserDataLMessage[functional variable]

To ETCS messages application

Functional Variable
Sa-DATA.indication [functional variable]
Data
– Objective: To provide ETCS message received from the network
– Description: ETCS message without safe protection.
– Family: Software
– Type: SFM.IN.SaDATA.IndicationStruct
– Format: bitarray defined in Subset 026 Chapters 7 and 8, with the identification of the
RBC connection
– Protocol: VM built-in IN variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.SW.SFM.DATA.RECEIVE] Receive data[function]

* [IEVC.F3.02.08.05.03] Transfer Safe data[function]
– Consumed by:

* [IEVC.F3.02.08.08.01] Decode Euroradio messages[function]

* [IEVC.F3.02.08.08] Decode and encode ETCS telegrams or messages[function]

<SaCEPID> <SaUserData> <SaUserDataLMessage>

Notes:
– ‘Sa-DATA.indication’ in Subset 037
– See SaCEPID[functional variable]
– See SaUserData[functional variable]
– See SaUserDataLMessage[functional variable]

11.13. Euroradio Safe Functional Module driver 341 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
Sa-HP-DATA.indication [functional variable]
Data
• Objective: To provide high priority ETCS message received from the network
• Description: High priority ETCS message without safe protection.
• Family: Software
• Type: SFM.IN.SaHPDATA.IndicationStruct
• Format: bitarray defined in Subset 026 Chapters 7 and 8, with the identification of the RBC
connection
• Protocol: VM built-in IN variable
• Timing constraints: Event
• Associated interface:
– VM - Applications interface[ci]
• Produced by:
– [IEVC.SW.SFM.DATA.RECEIVE] Receive data[function]
– [IEVC.SW.SFM.DATA.RECEIVE.HP] Receive high-priority data[function]
– [IEVC.F3.02.08.05.03] Transfer Safe data[function]
• Consumed by:
– [IEVC.F3.02.08.08.01] Decode Euroradio messages[function]
– [IEVC.F3.02.08.08] Decode and encode ETCS telegrams or messages[function]

<SaCEPID> <SaUserData> <SaUserDataLMessage>

Notes:
• ‘Sa-HP-DATA.indication’ in Subset 037
• See SaCEPID[functional variable]
• See SaUserData[functional variable]
• See SaUserDataLMessage[functional variable]

11.13.4 Parameters

11.13.4.1 Structures

Functional Variable
MNID [functional variable]

342 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: Identify a network
• Description: Structure that contains the values which uniquely identifies a network: MCC
and MNC. It corresponds to NID_MN in Subset 026 chapter 7.
• Family: Software
• Type: MNIDStruct

Notes:
• See MCC[functional variable]
• See MNC[functional variable]

Functional Variable
RBCETCSId [functional variable]
Data
• Objective: Identify a RBC
• Description: Structure that contains the values which uniquely identify a RBC: NID_C and
NID_RBC
• Family: Software
• Type: EtcsIdStruct

<NID_C> <NID_RBC>

Notes:
• NID_C in Subset-026 §7
• See NID_RBC[functional variable]

Functional Variable
NID_ENGINE [functional variable]

11.13. Euroradio Safe Functional Module driver 343 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: transmit the ETCS ID of the equipment initiating the connection
• Description: iEVC ETCS ID
• Family: Software
• Type: integer
• Format: NA
• Unit: NA
• Precision: 1
• Protocol: NA
• Equivalence class: [1 2^24-1]
• Minimum: 1
• Maximum: 2^24-1
• Behavior outside range: report error
• Memory management: int32
• Sil: TBD

11.13.4.2 Terminal elements

Functional Variable
SaCEPID [functional variable]
Data
• Objective: Identify a connection endpoint (SaCEPID in SS 037)
• Description: Unique identifier of a connection end point
• Family: Software
• Type: integer
• Format: NA
• Unit: NA
• Precision: 1
• Protocol: NA
• Equivalence class: [0 2^31-1]
• Minimum: 0
• Maximum: 2^31-1
• Behavior outside range: report error
• Memory management: int32
• Sil: TBD

344 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
MCC [functional variable]
Data
• Objective: Identify a network
• Description: Mobile Country Code in a 3-character string
• Family: Software
• Type: string
• Format: [0-9][0-9][0-9]
• Behavior outside range: report error
• Memory management: string
• Sil: TBD

Functional Variable
MNC [functional variable]
Data
• Objective: Identify a network
• Description: Mobile Network Code in a 2 or 3-character string
• Family: Software
• Type: string
• Format: [0-9][0-9][0-9]?
• Behavior outside range: report error
• Memory management: string
• Sil: TBD

Functional Variable
NID_RBC [functional variable]
Data
• Objective: Identify a RBC
• Description: RBC Number (within a given country)
• Family: Software
• Type: integer (14 bits)
• Equivalence class: [0 16382], [16383]
• Minimum: 0
• Maximum: 16383
• Behavior outside range: report error
• Memory management: int32
• Sil: TBD

11.13. Euroradio Safe Functional Module driver 345 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Note: 16383 is a special value which means “Contact last known RBC” (Subset 026 7.5.1.96).

Functional Variable
ETCSIdType [functional variable]
Data
• Objective: Identify an ETCS equipment
• Description: ETCS ID type
• Family: Software
• Type: integer
• Equivalence class: [0], [1], [2], [3], [4], [5], [6], [0xff]
• Minimum: 0
• Maximum: 255
• Behavior outside range: report error
• Memory management: int32
• Sil: TBD

<ETCSIdType> ::= "\x00" ; Radio in-fill unit

"\x01" ; RBC
"\x02" ; Engine
"\x03" ; Reserved for Balise
"\x04" ; Reserved for Field element (Level crossing,...)
"\x05" ; Key management entity
"\x06" ; Interlocking related entity
"\xFF" ; Unknown

Functional Variable
DES Authentication Key [functional variable]
Data
• Objective: Represent Authentication key part of a <KMAC_Authentication_Key>
• Description: cryptographic of standard Data Encryption Standard of length 64 bits, where
each eighth bit is an odd parity bit as described in SUBSET 037.
• Family: Software
• Type: int_64
• Memory management: 64 bits
• Sil: TBD

346 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
KMAC_Authentication_Key [functional variable]
Data
• Objective: Represent Authentication used for the signature of Euroradio messages
• Description: This key formed by three DES key
• Family: Software
• Type: Structure of three 64 bits
• Memory management: 192 bits
• Sil: TBD

<key1: DES Key> <key2: DES Key> <key3: DES Key>

Functional Variable
AddressType [functional variable]
Data
• Objective: Qualify the usage of sub-parameters of called address
• Description: transport service user entity used to identify the requested CFM user entity
type
• Family: Software
• Type: integer
• Memory management: int8
• Sil: TBD

Functional Variable
NetworkAddress [functional variable]
Data
• Objective: Represent network address of the called SaS user (called RBC)
• Description: Phone number (CS mode) or IP address (PS mode)
• Family: Software
• Type: string
• Memory management: string
• Sil: TBD

Functional Variable
SaUserData [functional variable]

11.13. Euroradio Safe Functional Module driver 347 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: Represent safe data to transfer
• Description: a byte array of 1023 bytes
• Family: Software
• Type: byte array
• Memory management: 1023 bytes
• Sil: TBD

Functional Variable
SaUserDataLMessage [functional variable]
Data
• Objective: Represent safe length in byte of the useful information inside 'SaUserData'
• Description: length of the useful data in byte inside 'SaUserData'
• Family: Software
• Type: integer
• Minimum: 1
• Maximum: 1023
• Behavior outside range: report error
• Memory management: int32

Functional Variable
ApplicationType [functional variable]
Data
• Objective: Convey the application type
• Description: An integer representing the application type as defined in Subset 037
• Family: Software
• Type: integer
• Equivalence class: [16], [17], [23]
• Minimum: 16
• Maximum: 23
• Behavior outside range: report error
• Memory management: int8
• Sil: TBD

<reason_code>

Functional Variable
DisconnectSubReason [functional variable]

11.13. Euroradio Safe Functional Module driver 349 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: Sub-reason code in case of error or disconnection
• Description: An integer representing the sub-reason
• Family: Software
• Type: integer
• Equivalence class: [0], [1], [2], [3], [4], [5], [6], [8], [29]
• Minimum: 0
• Maximum: 29
• Behavior outside range: report error
• Memory management: int32
• Sil: TBD

350 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

<mc_sub_code> ::= "\x01" ; Network Error

<key_error> ::= "\x02" ; Missing authentication key

| "\x03" ; Other problem related to the key management
˓→(e.g. loss of session key)

| "\x04" ; Authentication key not currently valid

| "\x1D" ; Requested safety feature is not supported

<mac_error> ::= "\x01" ; MAC error

| "\x02" ; MAC error in AU2 SaPdu
| "\x03" ; MAC error in AU3 SaPdu
| "\x04" ; MAC error in AR SaPdu

<seq_error> ::= "\x01" ; Replay of authentication message after

˓→connection establishment

<dir_error> ::= "\x01" ; Value of direction flag '0' instead of '1'

| "\x02" ; Value of direction flag '1' instead of '0'

<timeout_error> ::= "\x03" ; Time out of Testab without receiving the AR

˓→SaPDU

<invalid_PDU> ::= "\x01" ; Invalid information field Rejection of SaPDU

| "\x04" ; Invalid responding ETCS Id in AU2, i.e.
| "\x05" ; Invalid AU1 SaPDU : the header indicates aAU1
˓→SaPDU, but the rest of the Sa PDU does not match with the structure of an
˓→AU1 SaPDU.

<setup_error> ::= "\x01" ; Transmission of AU1 SaPDU but a message

˓→different from AU2 SaPDU is obtained.
| "\x02" ; Transmission of AU2 SaPDU but a message
˓→different from AU3 SaPDU is obtained.

| "\x03" ; Transmission of AU3 SaPDU but a message

˓→different from AR SAPDU is obtained.

<SaPDU_len_error> ::= "\x01" ; AU1 SaPDU length error Rejection of AU1 SaPDU
| "\x02" ; AU2 SaPDU length error Sa-DISCONNECT.
˓→indication

| "\x03" ; AU3 SaPDU length error T-DISCONNECT.request

| "\x05" ; DT SaPDU length error Sa-DISCONNECT.indication
| "\x08" ; AR SaPDU length error

<sub_reason_code> ::= "\x00" ; "No error"

<sub_reason_code>

11.13. Euroradio Safe Functional Module driver 351 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.13.5 Requirements

Requirement

the SFM driver shall establish a transport connection with the CFM module in compliance with
Subset 037. [id:tsc-req-euroradio-sfm-network-connection][p1][s]

The SFM driver shall be compliant to SUBSET 037 sections 5.7 and 5.8.

Requirement

the SFM driver shall establish safe connections with wayside devices in compliance with Subset 037
and Subset 092-2. [id:tsc-req-euroradio-sfm-safe-connection][p1][s]

The SFM driver shall be compliant to SUBSET 037 sections 5.2, 5.4, 5.5, 7.1 and 7.3. The associated
function shall be verified against the test cases of Subset 092-2.

Requirement

the SFM driver shall exchange safe data with wayside devices in compliance with Subset 037.
[id:tsc-req-euroradio-sfm-safe-data-exchange][p1][s]

The SFM driver shall be compliant to SUBSET 037 sections 5.3, 5.6 and 7.2.

Requirement

The SFM driver shall report any error detected to applications in case of loss of connection. [id:tsc-
req-euroradio-sfm-error-report][p1][ns]

The loss of connection are reported to the application with the service primitive Sa-
DISCONNECT.indication.

Requirement

The SFM shall manage at least two simultaneous safe connection. [id:tsc-req-euroradio-dual-safe-
connection][p1][ns]

Requirement

The SFM shall be compliant with Subset-092-1 chapter 5 and with with Subset-092-2. [id:tsc-req-
euroradio-sfm-ss092][p1][ns]

Requirement

The SFM shall relay the mobile availability status provided by the CFM to the Subset 026 applica-
tion. [id:tsc-req-euroradio-sfm-mobile-available][p1][ns]

352 of 750 11.13. Euroradio Safe Functional Module driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.13.6 Failure modes

11.13.6.1 Message integrity failure detected

When a Message integrity failure is detected, the SFM[ci] reports this failure to the application.

11.13.6.2 Message Origin Authentication failure detected

When a Message origin authentication failure is detected, the SFM[ci] reports this failure to the application.

11.13.6.3 Error detected on transport protocol

When a communication error is detected on the transport protocol associated to a communication channel, the
corresponding channel is closed and the error is reported to the SFM[ci].

11.14 Euroradio CFM software

Important: This component is included in the iEVC Basic kit[ci]

11.14.1 Description

The Communication Functional Module (CFM[ci]) is the component in charge of the management of the low
level Euroradio protocol stack as described by [SyAD-R10-SS37]. CFM[ci] services perform:
• Query of the list of permitted mobile networks;
• Mobile network registration;
• Transport connection establishment and release according to the connection mode (PS mode or CS mode);

Figure 11.36: Communication Functional Module Architecture

11.14. Euroradio CFM software 353 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.14.2 Functions

Figure 11.37: Euroradio CFM software architecture

11.14.2.1 [IEVC.F3.02.08.03] Manage network registration [function]

Data
• Definition: Set of functions that manage registration to GSM-R network.
• Allocated to:
– CFM[ci]
• Sil: basic
• Associated interface:
– VM - CFM interface[ci]
– CFM - Modem Controller interface[ci]
• Sub functions:
– [IEVC.F3.02.08.03.01] Determine Network connection Mode.[function]
– [IEVC.F3.02.08.03.02] Handle permitted mobile networks.[function]

Sub functions are:

354 of 750 11.14. Euroradio CFM software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.14.2.1.1 [IEVC.F3.02.08.03.01] Determine Network connection Mode. [function]

Data
• Definition: Determine connection mode with mobile network. The PS mode is the privileged con-
nection mode. If it is not available the CS mode is used as fallback.
• Allocated to:
– CFM[ci]
• Input:
– Configure EURORADIO transport protocol[functional variable][VM - CFM interface]
– T-CONNECT.request[functional variable][VM - CFM interface]
– T-DISCONNECT.request[functional variable][VM - CFM interface]
– MC RBC Connection status[functional variable][CFM - Modem Controller interface]
• Output:
– T-CONNECT.confirmation[functional variable][VM - CFM interface]
– T-DISCONNECT.indication[functional variable][VM - CFM interface]
– MC RBC Connection Request[functional variable][CFM - Modem Controller interface]
– Configure EURORADIO transport protocol indication[functional variable][VM - CFM inter-
face]
• Sil: basic
• Associated interface:
– VM - CFM interface[ci]
– CFM - Modem Controller interface[ci]

This function is described in section 8.4 and annex I of [SyAD-R10-SS37].

11.14.2.1.2 [IEVC.F3.02.08.03.02] Handle permitted mobile networks. [function]

Data
• Definition: Function that allows to query one of the modems to (1) establish the list of permitted
mobile networks, or (2) request registration to one specific mobile network. It also relays the mobile
availability status provided by the Modem Controller to the SFM.
• Allocated to:
– CFM[ci]
• Input:
– T-PERMISSION.request[functional variable][VM - CFM interface]
– T-REGISTRATION.request[functional variable][VM - CFM interface]
– MC Network Available list[functional variable][CFM - Modem Controller interface]
– MC Network Registration status[functional variable][CFM - Modem Controller interface]
– Mobile Available (From MC)[functional variable][CFM - Modem Controller interface]
• Output:

11.14. Euroradio CFM software 355 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– T-PERMISSION.indication[functional variable][VM - CFM interface]

– T-REGISTRATION.indication[functional variable][VM - CFM interface]
– MC Network Available request[functional variable][CFM - Modem Controller interface]
– MC Network Registration request[functional variable][CFM - Modem Controller interface]
– Mobile Available (From CFM)[functional variable][VM - CFM interface]
• Sil: basic
• Associated interface:
– VM - CFM interface[ci]
– CFM - Modem Controller interface[ci]

11.14.2.2 [IEVC.F3.02.08.04] Manage Euroradio protocol [function]

Data
• Definition: Set of functions that manage Euroradio protocol according to network connection mode
• Allocated to:
– CFM[ci]
• Sil: basic
• Associated interface:
– VM - CFM interface[ci]
– CFM - Modem Controller interface[ci]
• Sub functions:
– [IEVC.F3.02.08.04.01] Manage Euroradio protocol in CS mode[function]
– [IEVC.F3.02.08.04.02] Manage Euroradio protocol in PS mode[function]

Sub functions are:

11.14.2.2.1 [IEVC.F3.02.08.04.01] Manage Euroradio protocol in CS mode [function]

Data
• Definition: Manage Euroradio protocol in CS mode as specified in subset 037
• Allocated to:
– CFM[ci]
• Input:
– T-DATA.request[functional variable][VM - CFM interface]
– MC TPDU in[functional variable][CFM - Modem Controller interface]
• Output:
– T-DATA.indication[functional variable][VM - CFM interface]
– T-HP-DATA.indication[functional variable][VM - CFM interface]
– MC TPDU out[functional variable][CFM - Modem Controller interface]

356 of 750 11.14. Euroradio CFM software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Sil: basic
• Associated interface:
– VM - CFM interface[ci]
– CFM - Modem Controller interface[ci]

Refer to section 8.2 of the [SyAD-R10-SS37].

11.14.2.2.2 [IEVC.F3.02.08.04.02] Manage Euroradio protocol in PS mode [function]

Data
• Definition: Manage Euroradio protocol in PS mode as specified in subset 037
• Allocated to:
– CFM[ci]
• Input:
– T-DATA.request[functional variable][VM - CFM interface]
– MC TPDU in[functional variable][CFM - Modem Controller interface]
• Output:
– T-DATA.indication[functional variable][VM - CFM interface]
– MC TPDU out[functional variable][CFM - Modem Controller interface]
• Sil: basic
• Associated interface:
– VM - CFM interface[ci]
– CFM - Modem Controller interface[ci]

Refer to sections 8.3 and 8.5 of the [SyAD-R10-SS37].

11.14.3 Interface

The CFM[ci] uses the following interfaces:

• VM - CFM interface[ci]
This is the interface between the SFM[ci] and CFM[ci] is based on TSC Net[ci], exchanged messages are
defined in [SyAD-R67-SIF-VM-CFM].
• CFM - Modem Controller interface[ci] shall handle commands specified by [SyAD-R15-AT11T6001], data
exchange. (see [SyAD-R65-SIF-CFM-MC])

11.14. Euroradio CFM software 357 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.14.4 Parameters

No local parameters, they are provided by Configure EURORADIO transport protocol[functional variable][VM -
CFM interface] via the interface VM - CFM interface[ci]

11.14.5 Requirements

Requirement

The CFM shall manage the GSM-R network connection according to Subset 037 for what concerns
the Communication Functional Module. [id:tsc-req-euroradio-cfm-manage-network][p1][ns]

Requirement

The CFM shall manage the Euroradio protocol according to Subset 037 for what concerns the Com-
munication Functional Module. [id:tsc-req-euroradio-cfm-manage-euroradio][p1][ns]

Requirement

The CFM shall report any protocol error to the SFM driver in case of loss of connection. [id:tsc-req-
euroradio-cfm-error-report][p1][ns]

The loss of connection are reported to the SFM driver with the service primitive T-
DISCONNECT.indication.

Requirement

The CFM shall manage at least two simultaneous transport connections. [id:tsc-req-euroradio-dual-
transport-connection][p1][ns]

In CS mode, each transport connection use separated modem.

Requirement

The CFM shall manage the connection modes between Packet Switch (PS) and Circuit Switch (CS).
[id:tsc-req-euroradio-cfm-manage-mode][p1][ns]

Requirement

The CFM shall shall provide communication services according to annex B of Subset-037 [id:tsc-req-
euroradio-cfm-ss037-ab][p1][ns]

Requirement

The CFM shall be compliant with Subset-092-1 chapter 6. [id:tsc-req-euroradio-cfm-ss092][p1][ns]

Requirement

The CFM shall relay the mobile availability status provided by the Modem Controller to the SFM
[id:tsc-req-euroradio-cfm-mobile-available][p1][ns]

358 of 750 11.14. Euroradio CFM software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.14.6 Failure modes

11.14.6.1 Failure detected on protocol

On communication error, the associated connection is closed and the error is reported to the application using
variable T-DISCONNECT.indication[functional variable][VM - CFM interface].

11.15 Euroradio Modem controller Software

Important: This component is included in the iEVC Basic kit[ci]

11.15.1 Description

The Modem controller Software manages the communication with the GSM-R modem[ci]. The protocol used for
this interface is GSM-R modem vendor dependent.

11.15.2 Functions

11.15.2.1 [IEVC.F4.28.09] Modem controller - Provide maintenance and fault information [func-
tion]

Data
• Definition: Builds GSM-R modem configuration report and provides fault information about GSM-
R modems.
• Allocated to:
– Modem controller[ci]
• Input:
– GSM-R low level Maintenance Data[functional variable][Modem Controller - GSM-R Modem
Interface]
• Output:
– GSM-R Maintenance Data[functional variable][Modem Controller - OBOM interface]
– GSM-R modem commands[functional variable][Modem Controller - GSM-R Modem Inter-
face]
– TSC Net Modem Data[functional variable][Modem Controller - OBOM interface]
• Sil: basic
• Associated interface:
– Modem Controller - OBOM interface[ci]
– Modem Controller - GSM-R Modem Interface[ci]

The modem controller requests the maintenance data to the GSM-R modem every 5 seconds though specific
GSM-R modem commands[functional variable][Modem Controller - GSM-R Modem Interface] and reports it to
the OBOM through GSM-R Maintenance Data[functional variable][Modem Controller - OBOM interface].
TSC Net Modem Data[functional variable][Modem Controller - OBOM interface] is used for logging purpose; it
contains each command sent to or received from the GSM-R modem (refer to [SyAD-R64-SIF-OBOM-MC]).

11.15. Euroradio Modem controller Software 359 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.15.2.2 [IEVC.F3.02.08.06] Manage Low-level protocol & modem interface [function]

Data
• Definition: Manages the interface of the GSM-R modem, this function shall handle 2 GSM-R
modems. It manages the connection with the modem including initialization, failure detection and
reconnection.
• Allocated to:
– Modem controller[ci]
• Input:
– GSM-R Data from modem[functional variable][Modem Controller - GSM-R Modem Inter-
face]
– GSM-R connection state[functional variable][Modem Controller - GSM-R Modem Interface]
– GSM-R List of available services[functional variable][Modem Controller - GSM-R Modem
Interface]
– MC Network Available request[functional variable][CFM - Modem Controller interface]
– MC Network Registration request[functional variable][CFM - Modem Controller interface]
– MC RBC Connection Request[functional variable][CFM - Modem Controller interface]
– MC TPDU out[functional variable][CFM - Modem Controller interface]
• Output:
– GSM-R Data to modem[functional variable][Modem Controller - GSM-R Modem Interface]
– GSM-R modem commands[functional variable][Modem Controller - GSM-R Modem Inter-
face]
– MC Network Available list[functional variable][CFM - Modem Controller interface]
– MC Network Registration status[functional variable][CFM - Modem Controller interface]
– MC TPDU in[functional variable][CFM - Modem Controller interface]
– MC RBC Connection status[functional variable][CFM - Modem Controller interface]
– Mobile Available (From MC)[functional variable][CFM - Modem Controller interface]
• Sil: basic
• Associated interface:
– Modem Controller - GSM-R Modem Interface[ci]
– CFM - Modem Controller interface[ci]

11.15.2.3 [IEVC.F4.32.09] Command GSM-R modem reset [function]

Data
• Definition: Converts the reset orders received through TSC Net into specific GSM-R reset/reboot
command
• Allocated to:
– Modem controller[ci]
• Input:
– GSM-R modem reset order[functional variable][Modem Controller - OBOM interface]

360 of 750 11.15. Euroradio Modem controller Software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Output:
– GSM-R low level reset order[functional variable][Modem Controller - GSM-R Modem Inter-
face]
• Sil: basic
• Associated interface:
– Modem Controller - OBOM interface[ci]
– Modem Controller - GSM-R Modem Interface[ci]

11.15.3 Interface

The Modem controller[ci] uses the following interfaces :

• Modem Controller - GSM-R Modem Interface[ci] is vendor dependent, it shall handle commands specified
by AT11T6001, data exchange information about the modem configuration.
• CFM - Modem Controller interface[ci] is based on TSC Net[ci] for the communication CFM[ci].
• Modem Controller - OBOM interface[ci] supports the exchange of the following variables:
– GSM-R Maintenance Data[functional variable][Modem Controller - OBOM interface]
– GSM-R modem reset order[functional variable][Modem Controller - OBOM interface]

11.15.4 Parameters

Parameters not described in this release of the specification.

11.15.5 Requirements

Requirement

The GSM-R modem controller shall handle two GSM-R modems. [id:tsc-req-ievc-sw-gsm-r-modem-
controller-dual][p1][ns]

Requirement

The GSM-R modem controller shall translate standard message from CFM to specific modem com-
mands. [id:tsc-req-ievc-sw-gsm-r-modem-controller-translate-cmd][p1][ns]

Requirement

The GSM-R modem controller shall translate specific status or data coming from modem to stan-
dard message to CFM [id:tsc-req-ievc-sw-gsm-r-modem-controller-translate-data][p1][ns]

Requirement

The GSM-R modem controller shall provide maintenance and fault information to the OBOM.
These information shall be exhaustive enough (e.g., does the fault impact only Packet Switched,
Circuit Switched, all of the functionalities of the GSM-R modem. . . ) [id:tsc-req-ievc-sw-gsm-r-modem-
controller-maintenance-and-faults][p2][ns]

11.15. Euroradio Modem controller Software 361 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The GSM-R modem controller shall command the GSM-R modem reset upon reception of a reset
order received through TSC Net [id:tsc-req-ievc-sw-gsm-r-modem-controller-reset][p1][ns]

Requirement

The GSM-R modem controller shall be compliant with Subset-092-1 Annex A in its interface with
the GSM-R modems. [id:tsc-req-ievc-sw-gsm-r-modem-controller-ss092][p1][ns]

Requirement

The Modem Controller shall inform the CFM if there is at least one mobile terminal available for
use. [id:tsc-req-ievc-sw-gsm-r-modem-controller-mobile-available][p1][ns]

11.15.6 Failure modes

11.15.6.1 Failure of one modem

When the failure of one modem is detected, the service can continue with the other device. When connected in
CS mode the handover between RBC is performed in degraded mode. This failure is transmitted to the OBOM[ci]
with the variable GSM-R Maintenance Data[functional variable][Modem Controller - OBOM interface].

11.15.6.2 Failure of all modem

When all modems are failed, the ERTMS operation in level 2 and 3 is no more possible.

11.16 On-Board Operation and Maintenance software

Important: This component is included in the iEVC Basic kit[ci]

11.16.1 Description

The On-Board Operation & Maintenance software (OBOM[ci]) is the iEVC on-board supervision software.
OBOM[ci] provides the necessary files for the initialization of the Virtual machine[ci] (VM).
OBOM[ci] acts as a central access point to the Crash protected memory[ci] for loading iEVC configuration data
files and storing data in rotating log files. This role is important for:
• Recording important events, in particular those required for juridical purposes;
• Recording configuration, failures and lifetime of LRU;
Finally, OBOM[ci] controls the DMI Maintenance User Interfaces.

362 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.16.2 Modes

11.16.2.1 OBOM Virtual Machine supervision modes

OBOM[ci] has the following modes related to the management of the Virtual machine[ci] initialization and exe-
cution. OBOM is continuously informed of the current state of the VM through the VM status message[functional
variable][VM - OBOM interface][VM - Safe computer OS interface].
• OBOM_VM_UPLOAD: Uploading the VM
In this state, OBOM[ci] uploads the necessary file for the VM to run:
– The application package files:

* application files
* configuration files
* application package descriptor file
– The authorization certificate (also called ‘certificate’)
Once OBOM has completed this upload and as soon as a VM_LOADING status message is received from
the VM, it sends a VM Load application package and certificate[functional variable][VM - OBOM inter-
face] message to the VM, and proceeds to the next state.
• OBOM_VM_RUN: Running the VM
This state is activated when OBOM[ci] has been informed that the VM has authorized execution of the
loaded application package.
The only way to exit this state (apart from a power off) is to have an error reported from the VM
(VM_FAULT). In this case, OBOM proceeds to OBOM_VM_FALLBACK mode.

Note: OBOM is not in charge of ensuring that the VM respects its cycle time. Such mechanism is enforced
by the Safe computer, through an adequate watchdog mechanism. Refer to Cycle time for a description of
the timing constraints enforced in the iEVC. Should the VM not honor its timing constraints, OBOM shall
be informed by the status of the VM, or its inability to respond to a cycle message.

• OBOM_VM_FALLBACK: Fallback mode

This state is activated when OBOM[ci] has been informed that the VM is in failure state (VM_FAULT).
OBOM may proceed to this state from any other state.
In this mode, OBOM[ci] continues offering operational functions such as logging the GPS position, dis-
playing the available maintenance and fault information, etc.
Fig. 11.39 illustrates the active functions from OBOM when in VM_FALLBACK mode.
The following table recapitulates the active functions depending on the mode:

11.16. On-Board Operation and Maintenance software 363 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Table 11.2: OBOM functions activation

Mode Active functions
OBOM_VM_UPLOAD
• [IEVC.F1.05.03] Upload application package and certifi-
cate to VM[function]

OBOM_VM_RUN
• [IEVC.F1.15.01] Record VM execution[function],
• [IEVC.F5.05.03] Record selected variables[function],
• [IEVC.F5.05.04] Extract JRU events to log[function],
• [IEVC.F4.11.03] Interface LRU interactive tests
(OBOM)[function],
• [IEVC.F5.09.02] Read and write non-volatile operational
data[function]

Always active
• [IEVC.F5.03.02] Record GPS position and time[function]
• [IEVC.F4.28.06] Collect maintenance and faults informa-
tion[function],
• [IEVC.F4.29.02] Manage maintenance and faults informa-
tion to display[function],
• [IEVC.F4.29.03] Publish fault status[function],
• [IEVC.F4.07.04] Recover lifetime data[function],
• [IEVC.F4.07.03] Publish lifetime data and warnings
(OBOM)[function],
• [IEVC.F4.17.01] Log maintenance operation[function],
• [IEVC.F4.12.01] Publish configuration report[function],
• [IEVC.F4.13.01] Log event[function],
• [IEVC.F4.13.02] Query events from event log[function],
• [IEVC.F4.14.01] Query service log[function],
• [IEVC.F4.32.01] Command iEVC component re-
set[function]

The VM initialization sequence is illustrated in the Fig. 11.38.

364 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.38: VM initialization sequence

11.16. On-Board Operation and Maintenance software 365 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.39: OBOM active functions in VM_FALLBACK mode

11.16.3 Functions

11.16.3.1 Virtual Machine initialization

OBOM is responsible, upon startup, to upload all the files necessary to start the VM execution. This includes the
application package files and the authorization certificate. Once this is achieved, the VM asserts that the provided
application files are complete, and whether or not the certificate provided is acceptable.
Along the initialization and execution process, OBOM is informed of the status of the VM by a VM status mes-
sage[functional variable][VM - OBOM interface][VM - Safe computer OS interface].

366 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.16.3.1.1 [IEVC.F1.05.03] Upload application package and certificate to VM [function]

Data
• Definition: OBOM Reads the application package files, the certificate and the configuration data
files from the CPM, it uploads the content of these files to a location that can be accessed by the
VM. Once the files have been uploaded in the safe computer memory OBOM notifies the VM by
providing the memory address of the files to use.
• Allocated to:
– OBOM[ci]
• Input:
– Application package[functional variable][CPM - OBOM interface]
– Certificate file[functional variable][CPM - OBOM interface]
– VM status message[functional variable][VM - OBOM interface][VM - Safe computer OS in-
terface]
• Output:
– VM Load application package and certificate[functional variable][VM - OBOM interface]
– Logged variable list[functional variable]
• Sil: basic
• Associated interface:
– CPM - OBOM interface[ci]
– VM - OBOM interface[ci]
– VM - Safe computer OS interface[ci]

11.16.3.1.2 [IEVC.F1.15.01] Record VM execution [function]

Data
• Definition: Record the VM execution in order to enable a future replay of this execution.
• Allocated to:
– OBOM[ci]
• Input:
– VM End Cycle Message[functional variable][VM - OBOM interface]
– VM Snapshot Message[functional variable][VM - OBOM interface]
– VM Variable Update Message[functional variable][VM - OBOM interface]
– VM status message[functional variable][VM - OBOM interface][VM - Safe computer OS in-
terface]
• Output:
– OBOM Log Entry[functional variable][VM - OBOM interface]
– VM Variable Update Message[functional variable][VM - OBOM interface]
• Sil: basic
• Associated interface:

11.16. On-Board Operation and Maintenance software 367 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– VM - OBOM interface[ci]
– VM - Safe computer OS interface[ci]

11.16.3.2 GPS

11.16.3.2.1 [IEVC.F5.03.02] Record GPS position and time [function]

Data
• Definition: Construct a log entry of the currently reported time and GPS position of the train, then
forwards it to the logging function.
• Allocated to:
– OBOM[ci]
• Input:
– NMEA 0183 GPS[functional variable][NMEA 0183 GPS interface]
• Output:
– OBOM Log Entry[functional variable][VM - OBOM interface]
• Sil: basic
• Associated interface:
– NMEA 0183 GPS interface[ci]
– VM - OBOM interface[ci]

OBOM is responsible to log the GPS position and time of the train. Furthermore, the GPS is used as an external
clock source in order to obtain a reference date and time information to be used for logging.
Refer to [IEVC.F5.03] Record GPS position and time[function] for a description of the related functional architec-
ture. When no GPS data is available the positioning and time are set to a specific value equivalent to ‘unknown’.

11.16.3.3 Data logging

OBOM is responsible for data logging. Based on log entry messages, it writes the data to an appropriate rotating
log file. The log file to use is specified in the log entry message.
Data log content is intended for machines, not for humans. This is in contrast with event logs (refer to
[IEVC.F4.13.01] Log event[function] below).
Refer to [IEVC.F5.05] Record selected variables[function] for a description of the related functional architecture.

11.16.3.3.1 [IEVC.F5.05.01] Log Data [function]

Data
• Definition: Log data in a rotating log file
• Allocated to:
– OBOM[ci]
• Input:
– OBOM Log Entry[functional variable][VM - OBOM interface]

368 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Output:
– OBOM log file[functional variable][CPM - OBOM interface]
• Sil: basic
• Associated interface:
– VM - OBOM interface[ci]
– CPM - OBOM interface[ci]

11.16.3.4 Collect a failure report from the driver

OBOM collects the failure report entered by the driver on the DMI.
Refer to [IEVC.F4.05] Collect a failure report from the driver[function] for a description of the related functional
architecture.

11.16.3.4.1 [IEVC.F4.05.01] Collect failure report from driver [function]

Data
• Definition: Receive from the DMI a failure report as entered by the driver, logs it and provide this
information to the fault status computation function.
• Allocated to:
– OBOM[ci]
• Input:
– Failure report entry[functional variable]
• Output:
– LRU fault status Message (OBOM internal)[functional variable]
• Sil: basic

11.16.3.5 Maintenance and faults information collection and reporting

OBOM plays an important role in collecting the maintenance data available from the various LRUs, and building
up a synthesis of this data that applications can use.
Refer to [IEVC.F4.28] Provide maintenance and fault information[function] for a description of the related func-
tional architecture.

11.16.3.5.1 [IEVC.F4.28.06] Collect maintenance and faults information [function]

Data
• Definition: Collect the maintenance and fault information from various LRUs, and synthesize the
information in a single fault information message
• Allocated to:
– OBOM[ci]
• Input:

11.16. On-Board Operation and Maintenance software 369 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– Power supply Maintenance Data[functional variable]

– CPM Maintenance Data[functional variable][CPM - OBOM interface]
– 4G modem Maintenance Data[functional variable][4G Modem - OBOM interface]
– DMI Maintenance Data[functional variable][DMI - OBOM interface]
– GSM-R Maintenance Data[functional variable][Modem Controller - OBOM interface]
– Ethernet Switch Maintenance Data[functional variable][Ethernet Switch - OBOM interface]
– Sensor Box Ethernet Switch Maintenance Data[functional variable][Sensor Box Ethernet
Switch - OBOM interface]
– TSC Net Maintenance Data[functional variable][TSC Net - OBOM interface]
– LRU fault status Message (OBOM internal)[functional variable]
– TSC Net Modem Data[functional variable][Modem Controller - OBOM interface]
• Output:
– Faults collected by OBOM[functional variable][VM - OBOM interface]
– Configuration report[functional variable]
– Ethernet Switch Maintenance Data request[functional variable][Ethernet Switch - OBOM in-
terface]
– 4G modem configuration request[functional variable][4G Modem - OBOM interface]
– Power supply Maintenance Data request[functional variable]
• Sil: basic
• Associated interface:
– CPM - OBOM interface[ci]
– 4G Modem - OBOM interface[ci]
– DMI - OBOM interface[ci]
– Modem Controller - OBOM interface[ci]
– Ethernet Switch - OBOM interface[ci]
– Sensor Box Ethernet Switch - OBOM interface[ci]
– TSC Net - OBOM interface[ci]
– VM - OBOM interface[ci]

In addition, OBOM drives the maintenance and fault screen to display on the DMI, based on buttons pushed by the
driver. Refer to [IEVC.F4.29] Manage maintenance and fault information to display[function] for a description
of the related functional architecture.

11.16.3.5.2 [IEVC.F4.29.02] Manage maintenance and faults information to display [function]

Data
• Definition: Based on the requests received from the DMI and OBOM internal state, orders the screen
to be displayed on the DMI maintenance UI.
• Allocated to:
– OBOM[ci]

370 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Input:
– OBOM user inputs[functional variable][DMI - OBOM interface]
– Configuration report[functional variable]
– LRU fault status Message (OBOM internal)[functional variable]
– LRU Interactive Test Report (OBOM internal)[functional variable]
– LRU lifetime data message (OBOM internal)[functional variable]
– LRU lifetime warning message (OBOM internal)[functional variable]
– OBOM Event Entry[functional variable]
– Service report entry[functional variable]
• Output:
– OBOM screen update[functional variable][DMI - OBOM interface]
– Failure report entry[functional variable]
– LRU Interactive Test Input (OBOM internal)[functional variable]
– Maintenance operation entry[functional variable]
– Service report query[functional variable]
– OBOM Event Query[functional variable]
• Sil: basic
• Associated interface:
– DMI - OBOM interface[ci]

OBOM is also responsible to forward to the DMI a synthesis of LRU faults, as well as log this synthesis in a file
for future analysis. Also refer to [IEVC.F4.29] Manage maintenance and fault information to display[function]
for a description of the related functional architecture.

11.16.3.5.3 [IEVC.F4.29.03] Publish fault status [function]

Data
• Definition: Publish LRU faults reported to interested parties (e.g. DMI), log it, and create fault
events.
• Allocated to:
– OBOM[ci]
• Input:
– LRU fault status Message[functional variable][VM - OBOM interface][DMI - OBOM inter-
face]
– LRU fault status Message (OBOM internal)[functional variable]
• Output:
– LRU fault status Message (OBOM internal)[functional variable]
– OBOM Event Entry[functional variable]
– OBOM Log Entry[functional variable][VM - OBOM interface]
• Sil: basic

11.16. On-Board Operation and Maintenance software 371 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Associated interface:
– VM - OBOM interface[ci]
– DMI - OBOM interface[ci]

Allocate
Allocation of the URS requirement to compute and report LRU faults [allocate]
Data
• Requirement:
– tsc-req-urs-operator-troubleshooting-report[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: Maintenance and faults information collection and reporting
• Justification: This requirement is in part covered by the functions IEVC.F4.28.06,
IEVC.F4.29.02 and IEVC.F4.29.03. The faults computation is allocated to the LRU ap-
plication.

11.16.3.6 Lifetime warnings

OBOM collects recorded LRU lifetime data, and provides this information to the VM so that application use it to
compute an updated lifetime for each LRU. OBOM then collects this updated information to store it and dispatch
it to interested parties.

11.16.3.6.1 [IEVC.F4.07.04] Recover lifetime data [function]

Data
• Definition: Recover the latest recorded lifetime data from the appropriate log file on the CPM.
• Allocated to:
– OBOM[ci]
• Input:
– OBOM log file[functional variable][CPM - OBOM interface]
• Output:
– LRU lifetime data message[functional variable][VM - OBOM interface][DMI - OBOM inter-
face]
– LRU lifetime data message (OBOM internal)[functional variable]
• Sil: basic
• Associated interface:
– CPM - OBOM interface[ci]
– VM - OBOM interface[ci]

When the OBOM is in OBOM_VM_FALLBACK mode, this function is still able to recover lifetime data logs
from the CPM to provide it to [IEVC.F4.07.03] Publish lifetime data and warnings (OBOM)[function] in order

372 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

to be displayed on the maintenance user interface of the DMI.

11.16.3.6.2 [IEVC.F4.07.03] Publish lifetime data and warnings (OBOM) [function]

Data
• Definition: Provide updated information about the lifetime of each LRU, as produced by the appli-
cations running on the VM.
• Allocated to:
– OBOM[ci]
• Input:
– LRU lifetime data message[functional variable][VM - OBOM interface][DMI - OBOM inter-
face]
– LRU lifetime data message (OBOM internal)[functional variable]
– LRU lifetime warning message[functional variable][VM - OBOM interface][DMI - OBOM
interface]
– LRU lifetime warning message (OBOM internal)[functional variable]
• Output:
– OBOM Log Entry[functional variable][VM - OBOM interface]
– LRU lifetime warning message (OBOM internal)[functional variable]
– LRU lifetime data message (OBOM internal)[functional variable]
– OBOM Event Entry[functional variable]
• Sil: basic
• Associated interface:
– VM - OBOM interface[ci]
– DMI - OBOM interface[ci]

Refer to [IEVC.F4.07] Determine estimated lifetime and trigger lifetime warning.[function] for a description of
the related functional architecture.
Allocate
Allocation of the URS requirement to have predicted lifetime to the maintenance center. [allocate]
Data
• Requirement:
– tsc-req-urs-maintainer-lifetime-telemetry[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: Lifetime warnings
• Justification: The predicted lifetime and warnings are stored in the CPM. It can be exported
and used off-line in the maintenance center. It and can be displayed on-line to the maintainer
on the maintenance user interface of the DMI.

11.16. On-Board Operation and Maintenance software 373 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.16.3.7 Service report

OBOM is responsible for collecting service reports from the DMI, as entered by the maintainer, and to log these
reports in a dedicated service log. It also provides the maintenance event information to the VM in case it impacts
the LRU Lifetime computation.

11.16.3.7.1 [IEVC.F4.17.01] Log maintenance operation [function]

Data
• Definition: Record a maintenance operation. The description of the operation is typically received
as a message from the DMI maintenance functions. The event is logged in the CPM and is also
forwarded to the LRU application in order to update the LRU lifetime information, if needed.
• Allocated to:
– OBOM[ci]
• Input:
– Maintenance operation entry[functional variable]
• Output:
– OBOM log file[functional variable][CPM - OBOM interface]
– OBOM Event Entry[functional variable]
– LRU maintenance event message[functional variable][VM - OBOM interface]
• Sil: basic
• Associated interface:
– CPM - OBOM interface[ci]
– VM - OBOM interface[ci]

It also supports querying those reports. Refer to [IEVC.F4.14] Produce service report[function] for a description
of the related functional architecture.

11.16.3.7.2 [IEVC.F4.14.01] Query service log [function]

Data
• Definition: Query the service log and return entries that match the query parameters.
• Allocated to:
– OBOM[ci]
• Input:
– OBOM log file[functional variable][CPM - OBOM interface]
– Service report query[functional variable]
• Output:
– Service report entry[functional variable]
• Sil: basic
• Associated interface:
– CPM - OBOM interface[ci]

374 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.16.3.8 Configuration report

OBOM is responsible for building and providing a configuration report. This report provides the complete list of
part numbers and versions of the various LRUs.
Refer to [IEVC.F4.12] Produce configuration report[function] for a description of the related functional architec-
ture.

11.16.3.8.1 [IEVC.F4.12.01] Publish configuration report [function]

Data
• Definition: Publish a configuration report of the IEVC, based on information collected by OBOM
and by the VM. Also logs in the event log a complete configuration report at startup.
• Allocated to:
– OBOM[ci]
• Input:
– VM Configuration report[functional variable][VM - OBOM interface]
– Configuration report[functional variable]
• Output:
– Configuration report[functional variable]
– OBOM Event Entry[functional variable]
• Sil: basic
• Associated interface:
– VM - OBOM interface[ci]

11.16.3.9 Event logging and reporting

OBOM is responsible for logging events, and supports querying this event log.
Within the context of these functions, an event is a timestamped plain-text message attached to a LRU. Events are
logged in rotating log files that can be queried to produced report.
Event logs are different from pure data logs, in the sense that event logs are designed to be read by human beings,
and / or transmitted as short text messages.
Refer to [IEVC.F5.05] Record selected variables[function] and [IEVC.F4.13] Produce event report[function] for
a description of the related functional architecture.

11.16.3.9.1 [IEVC.F5.05.03] Record selected variables [function]

Data
• Definition: Create specific events when some specific variables in applications change value.
• Allocated to:
– OBOM[ci]
• Input:
– Logged variable list[functional variable]

11.16. On-Board Operation and Maintenance software 375 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– VM Variable Update Message[functional variable][VM - OBOM interface]

• Output:
– OBOM Event Entry[functional variable]
• Sil: basic

The specification of what variable should create an event, and what are the values that should create an event, are
part of the application package descriptor.

11.16.3.9.2 [IEVC.F5.05.04] Extract JRU events to log [function]

Data
• Definition: Peek inside the logged JRU data for interesting events to log.
• Allocated to:
– OBOM[ci]
• Input:
– OBOM Log Entry[functional variable][VM - OBOM interface]
• Output:
– OBOM Event Entry[functional variable]
• Sil: basic

11.16.3.9.3 [IEVC.F4.13.01] Log event [function]

Data
• Definition: Log events of interest in a timestamped, textual format
• Allocated to:
– OBOM[ci]
• Input:
– OBOM Event Entry[functional variable]
– OBOM Log Entry[functional variable][VM - OBOM interface]
• Output:
– OBOM log file[functional variable][CPM - OBOM interface]
• Sil: basic
• Associated interface:
– VM - OBOM interface[ci]
– CPM - OBOM interface[ci]

Events are defined as:

• LRU faults reported by the driver on the Report failure window or reported by the LRU application or
computed internally by the OBOM - refer to [IEVC.F4.29.03] Publish fault status[function].

376 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• maintenance operations reported through the Report maintenance window - refer to [IEVC.F4.17.01] Log
maintenance operation[function].`
• LRU lifetime warnings reported by the LRU application - refer to [IEVC.F4.07.03] Publish lifetime data
and warnings (OBOM)[function].
• specific changes in specific VM variables (as defined in the application package descriptor file) - refer to
[IEVC.F5.05.03] Record selected variables[function].
• specific changes in the juridical data (as defined in the application package descriptor file) - refer to
[IEVC.F5.05.04] Extract JRU events to log[function].
• Configuration report at start-up - refer to [IEVC.F4.12.01] Publish configuration report[function].

11.16.3.9.4 [IEVC.F4.13.02] Query events from event log [function]

Data
• Definition: Returns an extract of logged events, based on query parameters provided.
• Allocated to:
– OBOM[ci]
• Input:
– OBOM Event Query[functional variable]
– OBOM log file[functional variable][CPM - OBOM interface]
• Output:
– OBOM Event Entry[functional variable]
• Sil: basic
• Associated interface:
– CPM - OBOM interface[ci]

11.16.3.10 Interactive tests

OBOM acts as a gateway between the DMI and relevant applications to perform interactive testing of the iEVC.
Refer to [IEVC.F4.11] Perform LRU interactive tests[function] for a description of the related functional archi-
tecture.

11.16.3.10.1 [IEVC.F4.11.03] Interface LRU interactive tests (OBOM) [function]

Data
• Definition: Act as a gateway between the VM and the DMI for relaying messages related to the
management of interactive test sessions.
• Allocated to:
– OBOM[ci]
• Input:
– LRU Interactive Test Input (OBOM internal)[functional variable]
– LRU Interactive Test Report[functional variable][VM - OBOM interface]

11.16. On-Board Operation and Maintenance software 377 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Output:
– LRU Interactive Test Input[functional variable][VM - OBOM interface]
– LRU Interactive Test Report (OBOM internal)[functional variable]
• Sil: basic
• Associated interface:
– DMI - OBOM interface[ci]
– VM - OBOM interface[ci]

11.16.3.11 Non volatile data storage

OBOM acts as a gateway between the VM and the crash protected memory for storing data in non volatile memory.
Refer to [IEVC.F5.09] Manage non-volatile operational data[function] for a description of the related functional
architecture.

11.16.3.11.1 [IEVC.F5.09.02] Read and write non-volatile operational data [function]

Data
• Definition: Act as a gateway between the VM and the CPM for reading and writing values stored
by applications in non volatile memory
• Allocated to:
– OBOM[ci]
• Input:
– OBOM Log Entry[functional variable][VM - OBOM interface]
– OBOM log file[functional variable][CPM - OBOM interface]
• Output:
– OBOM Log Entry[functional variable][VM - OBOM interface]
– OBOM log file[functional variable][CPM - OBOM interface]
• Sil: basic
• Associated interface:
– VM - OBOM interface[ci]
– CPM - OBOM interface[ci]

11.16.3.12 Component software reset

OBOM is able to command a software reset of the following iEVC components:

• Ethernet switch[ci]
• Sensor box ethernet switch[ci]
• 4G modem[ci]
• GSM-R modem[ci]
• iBTM-TX[ci]

378 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• iBTM-RX[ci]
• iODO[ci]
• iODO BITE[ci]
• Virtual machine[ci]
For the DMI and Safe computer, the reset order is provided to the Ethernet switch. These orders are SNMP
requests that activate specific digital outputs of the switch. These outputs translate trigger a power on cycle of the
DMI or of the Safe computer by using specific ‘normally closed’ relays.
Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional architecture.

11.16.3.12.1 [IEVC.F4.32.01] Command iEVC component reset [function]

Data
• Definition: Produce reset order messages to the iEVC on-board components through Ethernet
• Allocated to:
– OBOM[ci]
• Output:
– DMI reset order[functional variable][Ethernet Switch - OBOM interface]
– 4G modem reset order[functional variable][4G Modem - OBOM interface]
– Ethernet switch reset order[functional variable][Ethernet Switch - OBOM interface]
– GSM-R modem reset order[functional variable][Modem Controller - OBOM interface]
– Sensor box ethernet switch reset order[functional variable][Sensor Box Ethernet Switch -
OBOM interface]
– Reset orders to VM[functional variable][VM - OBOM interface]
– VM reset order[functional variable][VM - OBOM interface]
– Safe Computer reset order[functional variable][Ethernet Switch - OBOM interface]
• Sil: basic
• Associated interface:
– Ethernet Switch - OBOM interface[ci]
– 4G Modem - OBOM interface[ci]
– Modem Controller - OBOM interface[ci]
– Sensor Box Ethernet Switch - OBOM interface[ci]
– VM - OBOM interface[ci]

Note: This function is meant to be used in future baselines in order to trigger the reset mechanism remotely,
using the OBOM as a gateway.

11.16. On-Board Operation and Maintenance software 379 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.16.4 Interfaces

OBOM[ci] communicates with the VM through a dedicated interface.

• VM - OBOM interface[ci].
Furthermore, it has access to a GPS. This provides it with date and time information, as well as a geographical
position. Both are used to provide time and position context to information logged by OBOM for operational and
maintenance purposes.
• NMEA 0183 GPS interface[ci]
OBOM[ci] controls the DMI maintenance user interface through a dedicated interface.
• DMI - OBOM interface[ci]
Finally, OBOM centralizes the maintenance and fault information coming from all the on-board iEVC compo-
nents. Therefore, it requires the following dedicated interfaces:
• CPM - OBOM interface[ci]
• 4G Modem - OBOM interface[ci]
• Modem Controller - OBOM interface[ci]
• Sensor Box Ethernet Switch - OBOM interface[ci]
• Ethernet Switch - OBOM interface[ci]
• Power supply - OBOM interface[ci]

11.16.5 Internal data flows

Internally, OBOM functions exchange the following information.

Note: The format, protocol or details of these functional exchanges are defined by OBOM software implementa-
tion. It is not specified at system level.

Functional Variable
Logged variable list [functional variable]
Data
• Objective: To provide the OBOM the information in order to record selected application
events
• Description: The information, extracted from the loaded application package, about what
variable changes and what event should be logged and when.
• Family: Software
• Produced by:
– [IEVC.F1.05.03] Upload application package and certificate to VM[function]
• Consumed by:
– [IEVC.F5.05.03] Record selected variables[function]

Functional Variable
Configuration report [functional variable]

380 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide configuration information to be displayed in the 'Configuration report
window' on the DMI.
• Description: LRU configuration information such as serial number, hardware and software
version information
• Family: Software
• Produced by:
– [IEVC.F4.28.06] Collect maintenance and faults information[function]
– [IEVC.F4.12.01] Publish configuration report[function]
• Consumed by:
– [IEVC.F4.29.02] Manage maintenance and faults information to display[function]
– [IEVC.F4.12.01] Publish configuration report[function]

Functional Variable
Service report entry [functional variable]
Data
• Objective: To provide a list of service report information that may be displayed on the DMI.
• Description: List of service operations with their date, LRU ID, action performed and main-
tainer identity.
• Family: Software
• Produced by:
– [IEVC.F4.14.01] Query service log[function]
• Consumed by:
– [IEVC.F4.29.02] Manage maintenance and faults information to display[function]

Functional Variable
Service report query [functional variable]
Data
• Objective: To provide the criteria to extract a list of service report information in order to
be displayed on the DMI.
• Description: Structure that contains an LRU ID, a Maintainer ID, a start date, an end date,
and a maximum number of results.
• Family: Software
• Produced by:
– [IEVC.F4.29.02] Manage maintenance and faults information to display[function]
• Consumed by:
– [IEVC.F4.14.01] Query service log[function]

11.16. On-Board Operation and Maintenance software 381 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
OBOM Event Entry [functional variable]
Data
• Objective: To provide the information related to specific events in order for them to be
recorded in a textual log.
• Description: List of events with the LRU ID, event description, event type and event date
and time.
• Family: Software
• Produced by:
– [IEVC.F4.29.03] Publish fault status[function]
– [IEVC.F4.07.03] Publish lifetime data and warnings (OBOM)[function]
– [IEVC.F4.17.01] Log maintenance operation[function]
– [IEVC.F4.12.01] Publish configuration report[function]
– [IEVC.F5.05.03] Record selected variables[function]
– [IEVC.F5.05.04] Extract JRU events to log[function]
– [IEVC.F4.13.02] Query events from event log[function]
• Consumed by:
– [IEVC.F4.29.02] Manage maintenance and faults information to display[function]
– [IEVC.F4.13.01] Log event[function]

Functional Variable
OBOM Event Query [functional variable]
Data
• Objective: To provide the criteria to extract a list of event information from the log in order
to display them on the DMI.
• Description: Structure that contains an LRU ID, an event type, a start date and an end date.
• Family: Software
• Produced by:
– [IEVC.F4.29.02] Manage maintenance and faults information to display[function]
• Consumed by:
– [IEVC.F4.13.02] Query events from event log[function]

Functional Variable
Failure report entry [functional variable]

382 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide the LRU failure data as entered and validated by the user in the DMI
'Report failure window'.
• Description: Contains the entered LRU ID and the type of fault.
• Family: Software
• Produced by:
– [IEVC.F4.29.02] Manage maintenance and faults information to display[function]
• Consumed by:
– [IEVC.F4.05.01] Collect failure report from driver[function]

Functional Variable
LRU fault status Message (OBOM internal) [functional variable]
Data
• Objective: To provide the information related to one or several LRU faults in order either to
log or display on the DMI 'Fault status window'.
• Description: list of LRU faults containing as a minimum the LRU ID, the fault ID, fault
date, any contextual information and proposed action.
• Family: Software
• Produced by:
– [IEVC.F4.05.01] Collect failure report from driver[function]
– [IEVC.F4.29.03] Publish fault status[function]
• Consumed by:
– [IEVC.F4.28.06] Collect maintenance and faults information[function]
– [IEVC.F4.29.02] Manage maintenance and faults information to display[function]
– [IEVC.F4.29.03] Publish fault status[function]

Functional Variable
LRU lifetime data message (OBOM internal) [functional variable]

11.16. On-Board Operation and Maintenance software 383 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide LRU lifetime data information in order to be displayed in the DMI
'Maintenance LRU lifetime window'.
• Description: list of LRU lifetime data
• Family: Software
• Produced by:
– [IEVC.F4.07.04] Recover lifetime data[function]
– [IEVC.F4.07.03] Publish lifetime data and warnings (OBOM)[function]
• Consumed by:
– [IEVC.F4.29.02] Manage maintenance and faults information to display[function]
– [IEVC.F4.07.03] Publish lifetime data and warnings (OBOM)[function]

Refer to LRU lifetime data message[functional variable][VM - OBOM interface][DMI - OBOM interface]
in [SyAD-R62-SIF-OBOM-VM] for more information about the content of the lifetime data.

Functional Variable
LRU lifetime warning message (OBOM internal) [functional variable]
Data
• Objective: To provide LRU warning information in order to be displayed in the DMI 'Main-
tenance LRU lifetime window'.
• Description: list of LRU warning data
• Family: Software
• Produced by:
– [IEVC.F4.07.03] Publish lifetime data and warnings (OBOM)[function]
• Consumed by:
– [IEVC.F4.29.02] Manage maintenance and faults information to display[function]
– [IEVC.F4.07.03] Publish lifetime data and warnings (OBOM)[function]

Refer to LRU lifetime warning message[functional variable][VM - OBOM interface][DMI - OBOM in-
terface] in [SyAD-R62-SIF-OBOM-VM] for more information about the content of the lifetime warning
data.

Functional Variable
LRU Interactive Test Input (OBOM internal) [functional variable]

384 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: Inform that an interactive test command has been entered by the maintainer on
the DMI on the 'Interactive test window'.
• Description: message containing the LRU ID and the interactive test data.
• Family: Software
• Produced by:
– [IEVC.F4.29.02] Manage maintenance and faults information to display[function]
• Consumed by:
– [IEVC.F4.11.03] Interface LRU interactive tests (OBOM)[function]

Refer to LRU Interactive Test Input[functional variable][VM - OBOM interface] in

[SyAD-R62-SIF-OBOM-VM] for more information about the content of the interactive test data.

Functional Variable
LRU Interactive Test Report (OBOM internal) [functional variable]
Data
• Objective: To provide information to display in the 'Interactive test window' about the cur-
rent step of the test and possibly a list of actions to be executed on an LRU (for preparation
and de-preparation)
• Description: message containing the current test step with context (a description and the
result if available) and possibly a list of textual actions on specific LRUs. Each action
contains a description of the action, as well as the name of a picture file to display.
• Family: Software
• Produced by:
– [IEVC.F4.11.03] Interface LRU interactive tests (OBOM)[function]
• Consumed by:
– [IEVC.F4.29.02] Manage maintenance and faults information to display[function]

Refer to LRU Interactive Test Report[functional variable][VM - OBOM interface] in

[SyAD-R62-SIF-OBOM-VM] for more information about the content of the interactive test report
information.

Functional Variable
Maintenance operation entry [functional variable]

11.16. On-Board Operation and Maintenance software 385 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide the maintenance operation data as entered and validated by the user
in the DMI 'Report maintenance window'.
• Description: message containing the data relative to the maintenance operation entered on
the DMI. This includes the LRU ID, the action performed (such as replace, repair, control)
and the new lifetime (h, km).
• Family: Software
• Produced by:
– [IEVC.F4.29.02] Manage maintenance and faults information to display[function]
• Consumed by:
– [IEVC.F4.17.01] Log maintenance operation[function]

11.16.6 Requirements

Requirement

OBOM shall read the application package files and the authorization certificate in the CPM, load
them in the safe computer memory and provide the memory location to the Virtual Machine during
its initialization. [id:tsc-req-ievc-ob-cb-obom-app-package-and-certificate-upload][p1][ns]

Requirement

OBOM shall trigger the application package certificate verification by notifying the Virtual Machine
that all the application package files and associated certificate have been loaded in the safe computer
memory. [id:tsc-req-ievc-ob-cb-obom-trigger-vm-auth-check][p1][ns]

Requirement

OBOM shall record the VM execution and log the associated data in the CPM [id:tsc-req-ievc-ob-cb-
obom-log-vm-execution][p1][ns]

Requirement

OBOM shall log the GPS position and time in the CPM [id:tsc-req-ievc-ob-cb-obom-log-gps][p1][s]

Requirement

OBOM shall be able to log data in a rotating log file of the CPM. [id:tsc-req-ievc-ob-cb-obom-log-
data][p1][s]

Requirement

The OBOM shall generate an alarm when the capacity of CPM reaches a defined threshold. [id:tsc-
req-ievc-ob-cb-obom-capacity-alarm][p1][s]

The capacity threshold is set to 90% of the total CPM capacity.

386 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

OBOM shall collect the failure reports entered by the driver on the *Report failure window*, log
this information as an event in the CPM and provide it to the LRU application inside the VM.
[id:tsc-req-ievc-ob-cb-obom-failure-report][p1][ns]

Requirement

OBOM shall collect the maintenance and fault information from the various LRUs, and synthesize
the information in a single fault report entry message. [id:tsc-req-ievc-ob-cb-obom-lru-faults][p1][ns]

The list of LRUs is referenced in the Maps section of [SyAD-R61-SIF-OBOM-DMI].

Requirement

OBOM shall control the information to display on all the maintenance and faults screens based on
the user inputs on the DMI. [id:tsc-req-ievc-ob-cb-obom-mf-screens][p1][ns]

The screens shall be compliant with the DMI Maintenance and Fault User Interface Specification.

Requirement

OBOM shall display the LRU fault information in the *fault status window* on the DMI [id:tsc-req-
ievc-ob-cb-obom-fault-status-window][p1][ns]

Requirement

OBOM shall log any fault report entry as an event in the CPM at start-up and whenever the status
of an LRU changes [id:tsc-req-ievc-ob-cb-obom-fault-status-log][p1][ns]

Requirement

OBOM shall retrieve the latest recorded lifetime data from the appropriate log file on the CPM and
provide it to the LRU application in the VM. [id:tsc-req-ievc-ob-cb-obom-lifetimedata-to-vm][p1][ns]

Requirement

OBOM shall log in the CPM the lifetime data and warning messages produced by the LRU applica-
tion. [id:tsc-req-ievc-ob-cb-obom-lifetimedata-log][p1][ns]

The lifetime data and warning messages shall also be provided to the DMI software when displaying the
Maintenance LRU lifetime window.

Requirement

OBOM shall log the maintenance operations reported through the *Report maintenance window*
in the event log of the CPM. It shall also report the event to the VM. [id:tsc-req-ievc-ob-cb-obom-
maintenance-report-log][p1][ns]

Requirement

When receiving a Service Report Query from the DMI software, OBOM shall retrieve maintenance
operation logs from the CPM and provide them in return to the DMI software. [id:tsc-req-ievc-ob-cb-
obom-maintenance-report-query][p1][ns]

11.16. On-Board Operation and Maintenance software 387 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

OBOM shall build a configuration report of the iEVC based on the information collected through
the maintenance and fault data. It shall log the report in the CPM and display it on the DMI.
[id:tsc-req-ievc-ob-cb-obom-configuration-report][p1][ns]

OBOM shall provide the configuration report to the DMI software when displaying the Configuration
report window.
OBOM shall log the configuration report in the CPM at start-up when all the configuration information is
available.

Requirement

OBOM shall log in the CPM specific events related to specific VM variables. [id:tsc-req-ievc-ob-cb-
obom-record-selected-variables][p1][ns]

These specific variables and their event criteria are described in the application package descriptor file.

Requirement

OBOM shall be able to identify and log specific events in the juridical data. [id:tsc-req-ievc-ob-cb-
obom-record-jru-events][p1][ns]

These specific variables and their event criteria are described in the application package descriptor file.

Requirement

OBOM shall log events as timestamped plain-text messages attached to a LRU. [id:tsc-req-ievc-ob-cb-
obom-log-event][p1][ns]

The event shall be logged in rotating log files inside the CPM.
Events are defined as:
• LRU faults reported by the driver on the Report failure window or reported by the LRU application
or computed internally by the OBOM - refer to [IEVC.F4.29.03] Publish fault status[function].
• maintenance operations reported through the Report maintenance window - refer to
[IEVC.F4.17.01] Log maintenance operation[function].`
• LRU lifetime warnings reported by the LRU application - refer to [IEVC.F4.07.03] Publish lifetime
data and warnings (OBOM)[function].
• specific changes in specific VM variables (as defined in the application package descriptor file) -
refer to [IEVC.F5.05.03] Record selected variables[function].
• specific changes in the juridical data (as defined in the application package descriptor file) - refer to
[IEVC.F5.05.04] Extract JRU events to log[function].
• Configuration report at start-up - refer to [IEVC.F4.12.01] Publish configuration report[function].

Requirement

OBOM shall be able to query logged events from the CPM [id:tsc-req-ievc-ob-cb-obom-query-
event][p1][ns]

388 of 750 11.16. On-Board Operation and Maintenance software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

OBOM shall relay the interactive test inputs and reports between the LRU application and the DMI
software [id:tsc-req-ievc-ob-cb-obom-gateway-interactive-test][p1][ns]

Requirement

OBOM shall provide the VM with a read and write access in the CPM for non-volatile operational
data [id:tsc-req-ievc-ob-cb-obom-nv-data][p1][ns]

Requirement

OBOM shall be able to command the reset of all the iEVC on-board components [id:tsc-req-ievc-ob-
cb-obom-reset][p1][ns]

Allocate
Allocation of data recording requirement [allocate]
Data
• Requirement:
– tsc-req-ievc-pqp-62625-1-4-2-1[req]
• Ci:
– OBOM[ci]
• Justification: The record of data shall fulfill the recording requirements of EN 62625 stan-
dard

Requirement

The recorded data shall be completed with measures to safeguard data integrity in compliance with
EN/IEC 62625-1:2013 clause 4.3.1.5. [id:tsc-req-ievc-ob-cb-obom-data-integrity][p1][ns]

11.16.7 OBOM Failure modes

Should the OBOM software fails in its execution inside the non-safety domain of the safe computer. The con-
sequence is that its allocated functions will be unavailable. Maintenance and faults logs will not be recorded
anymore. This failure does not impact the execution of the VM in the safety domain of the safe computer if the
VM was already running.
If the OBOM failure occurs before the VM Load application package and certificate[functional variable][VM -
OBOM interface] has been sent to the VM, the VM will not execute and the safe outputs will remain in their
restrictive state.

11.16. On-Board Operation and Maintenance software 389 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.17 IO driver

Important: This component is included in the iEVC Basic kit[ci]

11.17.1 Description

The IO driver provides an I/O interface between the Virtual Machine and the Safe computer. This driver im-
plements the necessary application interface exposed by the Safe computer, and is integrated inside the Virtual
Machine.

11.17.2 Modes

The IO driver has no mode.

11.17.3 Functions

11.17.3.1 [IEVC.F3.02.14.01] Manage logical I/O signal [function]

Data
• Definition: The IO driver component is in charge of the acquisition process of inputs from the IO
board and their transmission to the TIU application as built-in variables. It is also in charge of the
production of outputs to the IO board based on the values provided by applications (e.g. TIU). The
IO driver also associate the state of a specific digital input to the enabling of the VM test mode.
• Allocated to:
– IO driver[ci]
• Input:
– Built-in logical commands[functional variable][VM - Applications interface]
– IO Board Logical states[functional variable][VM - Safe computer OS interface]
– IO Board health information[functional variable][VM - Safe computer OS interface]
• Output:
– Built-in logical states[functional variable][VM - Applications interface]
– IO Board Logical commands[functional variable][VM - Safe computer OS interface]
– Test switch enabled[functional variable]
– Built-in IO board health[functional variable][VM - Applications interface]
• Sil: 4
• Associated interface:
– VM - Safe computer OS interface[ci]
– VM - Applications interface[ci]

390 of 750 11.17. IO driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.17.3.2 [IEVC.F3.02.14.04] Manage Ethernet I/O [function]

Data
• Definition: The IO driver component is in charge of the acquisition process of inputs from the
Ethernet network and their transmission to the TIU application as numeric input data. It is also
in charge of the production of outputs to the ethernet network based on the numeric output data
provided by the TIU application.
• Allocated to:
– IO driver[ci]
• Input:
– Built-in numeric output[functional variable][VM - Applications interface]
– Numeric input data[functional variable][iEVC - Train generic interface]
• Output:
– Built-in numeric input[functional variable][VM - Applications interface]
– Numeric output data[functional variable][iEVC - Train generic interface]
• Sil: 4
• Associated interface:
– iEVC - Train generic interface[ci]
– VM - Applications interface[ci]

Note: This function will not be used in version 1.0 of the iEVC system.

The following function is not allocated directly to the IO driver but is associated to the IO driver functions.

11.17.3.3 [IEVC.F3.02.14.02] Provide Test mode input [function]

Data
• Definition: The Test key switch is in charge to provide the information that the *test mode* has
been enabled by the system user. It is a physical switch installed on the Computer box. One of the
digital inputs of the IO board is reserved for this use and this input is associated to the test mode by
the IO driver.
• Allocated to:
– Test key switch[ci]
• Output:
– Test mode input signal[functional variable][Safe computer - Test switch interface]
• Sil: basic
• Associated interface:
– Safe computer - Test switch interface[ci]

See [SyAD-R70-SIF-Test-Switch] for more information on the related interface.

11.17. IO driver 391 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.17.4 Interface

• The IO driver is interfaced with the TIU application using the VM - Applications interface[ci] to exchange
the following built-in variables:

Functional Variable
Built-in logical commands [functional variable]
Data
– Objective: To provide built-in variables applications can use to control the physical
digital outputs of the safe computer.
– Description: structure containing the command to apply for each safe digital output.
Each output is represented using a boolean: True means 'active' level, False means
'inactive' level.
– Family: Software
– Type: Built_In_Logical_Commands
– Protocol: VM built-in OUT variable
– Timing constraints: Cyclic (VM_cycle_time)
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.14.03] Map Application variables onto I/O[function]

* [IEVC.F3.02.14.11] Manage Emergency Brake test[function]
– Consumed by:

* [IEVC.F3.02.14.01] Manage logical I/O signal[function]

For high side switching outputs (K1 boards): ‘active’ means a High level on Output and ‘inactive’
means a High Impedance.
For low side switching outputs (K7 boards): ‘active’ means Low level and ‘inactive’ means a High
Impedance.

Functional Variable
Built-in logical states [functional variable]

392 of 750 11.17. IO driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide built-in variables that applications can use to get the state of
the digital inputs of the safe computer IO boards.
– Description: structure or collection containing the state of each safe digital input.
Value 'True' means high level, 'False' means low level. Value 'NA' is used when the
physical train input becomes unavailable or cannot be determined.
– Family: Software
– Type: built_in_logical_states
– Protocol: VM built-in IN variable
– Timing constraints: Cyclic (VM_cycle_time)
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.14.01] Manage logical I/O signal[function]

– Consumed by:

* [IEVC.F3.02.14.03] Map Application variables onto I/O[function]

Functional Variable
Built-in IO board health [functional variable]
Data
– Objective: To provide built-in variables that applications can use to get health infor-
mation related to the IO boards and to each single digital I/O.
– Description: Structure containing diagnosis information concerning the IO boards
digital I/O
– Family: Software
– Type: built_in_IO_board_health
– Protocol: VM built-in IN variable
– Timing constraints: Cyclic (VM_cycle_time)
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.14.01] Manage logical I/O signal[function]

– Consumed by:

* [IEVC.F3.02.14.03] Map Application variables onto I/O[function]

The health data contains the following information:

For digital inputs:
– ‘IsOperational’: the operational state of the input. Possible values are ‘True’/’False’.
– ‘IsCommunicationEstablished’: the communication state with the IO board. Possible values

11.17. IO driver 393 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

are ‘True’/’False’.
– ‘IsBoardFailed’: a flag to indicate an error of the input or of the whole IO board. Possible
values are ‘True’/’False’/’NA’. The value ‘NA’ is used when the associated diagnosis feature
is not supported.
– ‘IsIOVoltageOutOfRange’: a flag to indicate that the IO board voltage is out of range. Possible
values are ‘True’/’False’/’NA’. The value ‘NA’ is used when the associated diagnosis feature
is not supported.
– ‘IsTemperatureWarning’: a flag to indicate that the temperature is abnormally high or low.
Possible values are ‘True’/’False’/’NA’. The value ‘NA’ is used when the associated diagnosis
feature is not supported.
For digital outputs:
– ‘FeedbackLevel’: the feedback level of the digital output. Possible values are
‘True’/’False/NA’. Value ‘True’ means ‘active’, ‘False’ means ‘inactive’. Value ‘NA’ corre-
sponds to a ‘non-operational’ state and is used when no communication is available or when
the feedback value is not reliable or when the associated feature is disabled.
– ‘IsCommunicationEstablished’: the communication state with the IO board Possible values
are ‘True’/’False’.
– ‘IsBoardFailed’: a flag to indicate an error of the input or of the whole IO board. Possible
values are ‘True’/’False’/’NA’. The value ‘NA’ is used when the associated diagnosis feature
is not supported.
– ‘IsIOVoltageOutOfRange’: a flag to indicate that the IO board voltage is out of range. Possible
values are ‘True’/’False’/’NA’. The value ‘NA’ is used when the associated diagnosis feature
is not supported.
– ‘IsTestPulseFailure’: Value ‘False’ means “Test pulse not failed” and False “Test pulse
failed”. ‘True’ is used if the communication is established with the IO board AND a test
pulse failure is detected. The test pulses can detect the following types of errors: output
switch stuck closed, output pin shorted to DIG_OUT_VS+, output pin shorted to neighboring
pins. Possible values are ‘True’/’False’/’NA’. The value ‘NA’ is used when the associated
diagnosis feature is not supported.
– ‘IsTemperatureWarning’: a flag to indicate that the temperature is abnormally high or low.
Possible values are ‘True’/’False’/’NA’. The value ‘NA’ is used when the associated diagnosis
feature is not supported.

Functional Variable
Built-in numeric output [functional variable]

394 of 750 11.17. IO driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide registers to be used to manage the physical numeric outputs of
the safety computer.
– Description: message or list of data to be published on the numeric data bus.
– Family: Software
– Type: built_in_logical_numeric_output
– Format: bitarray
– Protocol: VM built-in OUT variable
– Timing constraints: Cyclic (VM_cycle_time)
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.14.03] Map Application variables onto I/O[function]

– Consumed by:

* [IEVC.F3.02.14.04] Manage Ethernet I/O[function]

Functional Variable
Built-in numeric input [functional variable]
Data
– Objective: To provide registers to be used to manage the physical numeric inputs of
the safety computer.
– Description: message or list of data received from numeric data bus.
– Family: Software
– Type: built_in_logical_numeric_input
– Format: bitarray
– Protocol: VM built-in IN variable
– Timing constraints: Cyclic (VM_cycle_time)
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.14.04] Manage Ethernet I/O[function]

– Consumed by:

* [IEVC.F3.02.14.03] Map Application variables onto I/O[function]

Note: The variables Built-in numeric output[functional variable][VM - Applications interface] and Built-in
numeric input[functional variable][VM - Applications interface] are not used in this version of the system.
Their content will be described in a later version.

11.17. IO driver 395 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• The IO driver is interfaced with the safe computing OS of the Safe computer[ci]. The following variables
are exchanged:
– IO Board Logical states[functional variable][VM - Safe computer OS interface]
– IO Board Logical commands[functional variable][VM - Safe computer OS interface]
These variables are defined in section Interface of the Safe computer.
• The IO driver is interfaced with the Ethernet network of the train interface. The following variables are
exchanged:

Functional Variable
Numeric output data [functional variable]
Data
– Objective: To provide information that is published on an ethernet data bus
– Description: message or list of data to be published on the numeric data bus.
– Family: Software
– Protocol: TSC Net
– Timing constraints: Cyclic (VM_cycle_time)
– Associated interface:

* iEVC - Train generic interface[ci]

– Produced by:

* [IEVC.F3.02.14.04] Manage Ethernet I/O[function]

Functional Variable
Numeric input data [functional variable]
Data
– Objective: To provide information that is read from an ethernet data bus
– Description: message or list of data received from the numeric data bus.
– Family: Software
– Protocol: TSC Net
– Timing constraints: Cyclic (VM_cycle_time)
– Associated interface:

* iEVC - Train generic interface[ci]

– Consumed by:

* [IEVC.F3.02.14.04] Manage Ethernet I/O[function]

Note: The variables Numeric output data and Numeric input data[functional variable][iEVC - Train
generic interface] are not used in the version 1.0 of the iEVC system. Their content will be described
in a later version.

• The IO driver provides also the information Test switch enabled to the Virtual machine[ci].

396 of 750 11.17. IO driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
Test switch enabled [functional variable]
Data
– Objective: Notify the Virtual machine that the test mode key switch is in enable posi-
tion.
– Description: a boolean value. True if test mode is enabled.
– Family: Software
– Protocol: VM built-in IN variable
– Timing constraints: Cyclic (VM_cycle_time)
– Produced by:

* [IEVC.F3.02.14.01] Manage logical I/O signal[function]

– Consumed by:

* [IEVC.F1.07.06] Determine Test mode[function]

11.17.5 Parameters

The IO driver component has no specific parameter.

11.17.6 Requirements

Requirement

The IO driver shall relay the logical I/O information between the TIU application and the I/O boards
of the Safe Computer. [id:tsc-req-ievc-io-drv-relay-logical-io][p1][s]

Requirement

The IO driver shall relay the numeric data between the TIU application and the ethernet network
in the train interface. [id:tsc-req-ievc-io-drv-relay-numeric-io][p1][ns]

The digital input used by the Test key switch on the IO board is reserved and shall not be made available
to the TIU application.

The following requirements are related to the Test key switch[ci].

Requirement

The Test key switch shall provide the test mode enabled status to the safe computer. [id:tsc-req-ievc-
test-key-provide-mode][p2][ns]

Requirement

The first safe input from the safety computer shall be reserved to the test key switch status [id:tsc-
req-ievc-test-key-reserved-input][p1][ns]

11.17. IO driver 397 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.17.7 Failure modes

The IO driver component has no specific failure mode.

11.18 DMI software

Important: This component is included in the iEVC Basic kit[ci]

11.18.1 Description

The DMI software is in charge of drawing user interfaces from the data received from the Virtual machine[ci]
(ETCS information) and the OBOM[ci] (faults and maintenance information).
The arrangements of the displayed information is organized according to the [SyAD-R17-DMI]
for the ETCS parts, the graphical arrangement of other parts is customized according to
[SyAD-R72-SIF-Maintenance-Fault-UI].
All display changes are performed only on reception of new data and are checked by the DMI checker[ci] for the
safe information parts before updating the DMI computer[ci] screen.
The DMI software also gets the user inputs from the touchscreen or the soft key depending on the used technology,
or from an external push button, translates them in user action and transmits them to the Virtual machine[ci] and/or
OBOM[ci].
The following parts describes the principles of the display management performed by the DMI software.

11.18.1.1 Common principles to all windows

Note: It is possible that DMI shall have two separate screens (see tsc-req-urs-driver-dmi-two-screens[req]): a
complete DMI can be duplicated or dual-screens can be used. The choice of the solution will be done by the
installation project.
If the dual-screens solution is used, all defined windows can be split near to the middle. In the nominal case,
the single impact is that the DMI software and the DMI checker will manage only a half part (left or right) of
the foreseen windows. In the degraded situation (one of the two screens is out of order), the remaining device
(half screen) will have to manage the mandatory display and user actions. As it is project dependent and a safety
analysis has to be performed, it is not defined in this version of the specification.

11.18.1.1.1 Control of the DMI display

The DMI is composed of several windows which allow to organize the displayed information. Each window is
defined by a layout with a set of identified areas. Hereafter, there are some samples of DMI window layout.

398 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.40: Base DMI window layout

Figure 11.41: DMI data entry layout

Then, the content of each window is described by a set a of keys (item identifier) with their values (content
identifier). The meaning of the key / value is adapted to the displayed information, there are hereafter some
samples (the areas and symbol identifiers are defined in [SyAD-R17-DMI]):

11.18. DMI software 399 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Table 11.3: DMI data

Type of Key Value Sample
displayed
informa-
tion
Simple icon Area Symbol identifier (i.e. DR03) Indication of ETCS mode, level, . . .
identifier
(i.e.
G12)
Icon to ac- Area Combination of symbol identifier acknowledgment of mode, level
knowledge identifier (i.e. LE07) and attribute “ac-
(i.e. C1) knowledgment requested”
Complex Area Combination of several parame- Speed needle (train speed + color attribute),
graphical identifier ters circular gauge (target speed + permitted
item (i.e. B0) speed + intervention speed + . . . )
Simple text Area Text string Target distance, clock
identifier
Button sta- Button Status (enabled/disabled) All buttons
tus identifier
Default Field or Numerical value or text code Default ETCS level, default train data, value
value button of button
identifier

400 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.42: Sample of graphical item

Figure 11.43: Sample of graphical item

The messages received by the DMI software shall provide the applicable window and a list of graphical items
configuration (key/value).

11.18. DMI software 401 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.18.1.1.2 Management of user inputs

There are three types of user input to transmit to the Virtual Machine and/or the OBOM:

Table 11.4: user inputs

Type of Value Sample
user input
user action Code of the action “Request main menu”, “Acknowledgment of text message”
Single data Type and value entered Driver Id entry (“123456”), Train length entry (“257m”)
entry
Entry of Type of data set and list of Maintenance report data entered: LRU=PG#1, Ac-
data set values entered tion=REPLACE, LifeTime_H=100, LifeTime_KM=50

Figure 11.44: Sample of type user inputs “user action” and “single data entry”

402 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.45: Sample of type user inputs “entry of data set”

11.18.1.2 ETCS Windows

All ETCS windows are described in the standard [SyAD-R17-DMI].

Some toggle functions (to show/hide information on user request) are foreseen in the standard. As the Virtual
Machine has to always controlled the displayed information to the user, these requests to show or hide infor-
mation shall be transmitted to the Virtual Machine which will sent the suitable message in order to update the
corresponding information.
The information related to these windows will be exchanged only with the Virtual Machine. The messages ex-
changed between the DMI software and the Virtual Machine are defined in the [SyAD-R69-SIF-VM-DMI].
Special case of planning area:
The planning area as defined §8.3 of [SyAD-R17-DMI] is a complex graphical element of the DMI display. It will
be defined by the following parameters received from the Virtual Machine:
• List of orders and announcements: distance, identifier of order or announcement.
• Gradient profile: distance, gradient value.
• Speed profile: distance, speed value.
• Indication marker: distance.
The DMI software manages the display of the planning area from these parameters. The zoom in/out is also
managed by the DMI software. The hide/show request from the user will be transmitted to the Virtual machine
as user input, which will be taken into account to provide an updated planning display request. The planning area

11.18. DMI software 403 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

information shall be transmitted cyclically in order to have a smooth update of the planning area when the train is
moving.

Figure 11.46: ETCS planning area

Special case of text message

The management of text messages is described in §8.2.3.4 of [SyAD-R17-DMI].
In order to facilitate the user navigation among the text messages, a list with the following parameters will be sent
by the Virtual Machine:
• timestamp of the message: time formatted (hh:mm)
• priority of the message: important or auxiliary
• message content: text code or plain text
The DMI software manages the display of the list of text messages and the user navigation among the list (without
necessary interaction with the Virtual machine).

Figure 11.47: DMI text message

404 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Special case of data entry and data view windows

In case a data entry window is split in several windows containing input fields related to the same topic, the DMI
software will manage the navigation between the different windows. The navigation actions and display updates
are done without interaction with the Virtual machine. The same applies for the navigation between the different
data view windows (the ETCS data windows and the NTC data windows, if any).
Management of Isolation
URS requires to display the train speed on DMI in isolation. We propose to use the DMI default window with a
new symbol to indicate the isolation mode.

Figure 11.48: Proposal of Isolation window

Note: The DMI won’t offer a means to isolate the ERTMS/ETCS on-board equipment. (even if required by §5.6
of [SyAD-R17-DMI])

Special case of Odometry parameters

The entry of Odometry parameters described in [SyAD-R72-SIF-Maintenance-Fault-UI]
This entry process is managed as ETCS windows, as these data are used by the Odometry Application inside the
Virtual Machine.
Special case of Test mode pin code entry window
This window is described in the [SyAD-R72-SIF-Maintenance-Fault-UI]
At start-up and when Test mode key switch is activated, the VM shall ask an acknowledgement in the form of a
randomly generated pin code that has to be entered on the DMI.
The VM provides a request to the DMI driver that requires the display of the PIN code entry window to the DMI
software through VM screen update[functional variable][VM - DMI interface]. Refer to the description in Virtual
Machine.

11.18. DMI software 405 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.18.1.3 Maintenance and faults windows

All maintenance and faults windows are described in the [SyAD-R72-SIF-Maintenance-Fault-UI].

The settings window containing the buttons used to access to the maintenance and faults menus is controlled by
the virtual machine as for the others buttons.
The maintenance and faults windows are controlled by the OBOM but the Virtual machine stays the master for
the window selection. Then, the coordination between the Virtual Machine and the OBOM is performed in the
following way (sample with fault menu):
1. The user selects “faults”.
2. The DMI software transmits the user input “fault request” to the Virtual Machine and the OBOM.
3. The Virtual Machine requests the display of the Faults main window.
4. The OBOM requests sub-level faults windows with the related list of graphical items to update.
5. The DMI software will complete the empty part of the Faults main window requested by the VM with the
sub-level faults window requested by the OBOM.
6. As long as the Fault main window is requested by the Virtual Machine, the DMI software takes into account
the information from the OBOM and transmits the user inputs on these sub-windows only to the OBOM.
7. The Virtual Machine continues to provide the information to update the left part of the screen and can
request the exit from fault menu by requesting another window at any time.

Figure 11.49: DMI display shared between VM and OBOM

Same principles are applied for the management of maintenance windows.

The messages exchanged between the DMI software and the OBOM are defined in the
[SyAD-R61-SIF-OBOM-DMI].

406 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

For some windows, some user actions are directly managed by the DMI software:
• Maintenance Service report window: if several pages are required to display the information, it is man-
aged by the DMI software, as the user request to show / hide details about a service operation.
• Maintenance Configuration report window: if several pages are required to display the information, it is
managed by the DMI software.
• Maintenance Interactive test window: the scrolling (up/down) of the text part is managed by the DMI
software.

11.18.1.4 National Windows

The Customizable DMI service is used for the display of the NTC objects as described in §9 of [SyAD-R17-DMI].
All principles described for the ETCS windows are still applicable. It is up to the virtual Machine to format the
data exchanged between the DMI software and the National system application.
The message exchanged between the Virtual Machine and the DMI software (see [SyAD-R69-SIF-VM-DMI])
will support the NTC DMI functionalities foreseen in the SUBSET-058:
• Button request
• Indicator request
• Request to display / remove text message
• Speed and distance supervision information
• Sound command
• NTC data entry
• NTC data view
• Button event report
• acknowledgment reply (text)
If the NTC default window can not be used, a specific national window has be defined and implemented in the
DMI software. It is out of scope of this specification.

11.18.2 Modes

This DMI software has no specific mode.

11.18.3 Functions

11.18.3.1 [IEVC.F3.02.09.03] Manage ETCS display information [function]

Data
• Definition: This function manages DMI screen status: it switches on/off the screen according to the
received activation request and the local screen identifier. For dual-screens solutions, it also identi-
fies the parts of the window to manage (left, right or degraded half part). This function builds the
display from the data received from the Virtual Machine and integrate maintenance and fault screen
if required. The display is transmitted to the DMI Checker which will control the safe information
before updating the DMI screen. It plays the sounds as requested by the Virtual Machine. It gets
the user inputs, translates them in user action and transmits them to the Virtual Machine or to the
OBOM if they are related to the maintenance and fault screens.
• Allocated to:
– DMI software[ci]

11.18. DMI software 407 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Input:
– VM screen activation request[functional variable][VM - DMI interface]
– VM screen update[functional variable][VM - DMI interface]
– VM sound control[functional variable][VM - DMI interface]
– DMI user input[functional variable][DMI ETCS User Interface][DMI Fault User Inter-
face][DMI Maintenance User Interface]
– Maintenance and faults screen display information[functional variable]
• Output:
– Screen status[functional variable][VM - DMI interface]
– Non-Safe users inputs[functional variable][VM - DMI interface]
– DMI software graphical output[functional variable]
– DMI sound[functional variable][DMI ETCS User Interface][DMI Fault User Interface][DMI
Maintenance User Interface]
– Data for maintenance or faults screen[functional variable]
• Sil: basic
• Associated interface:
– DMI ETCS User Interface[ci]
– VM - DMI interface[ci]
• Sub functions:
– [IEVC.F3.02.09.03.01] Manage intense light condition[function]

Figure 11.50: DMI functions

408 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.18.3.2 [IEVC.F4.29.01] Manage maintenance and fault screens [function]

Data
• Definition: Based on OBOM instructions, it builds the required maintenance and fault screen to be
integrated in the DMI display. It also forward the related user inputs to the OBOM.
• Allocated to:
– DMI software[ci]
• Input:
– OBOM screen update[functional variable][DMI - OBOM interface]
– Data for maintenance or faults screen[functional variable]
• Output:
– OBOM user inputs[functional variable][DMI - OBOM interface]
– Maintenance and faults screen display information[functional variable]
• Sil: basic
• Associated interface:
– DMI - OBOM interface[ci]
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]

11.18. DMI software 409 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.51: Functional architecture of the DMI interface with OBOM

The previous figure summarizes the functional exchanges between the OBOM and the DMI software. The associ-
ated functions are described in System functional architecture.

11.18.3.3 [IEVC.F3.02.09.03.01] Manage intense light condition [function]

Data
• Definition: It plays a warning sound when the measurement from the light sensor exceed a config-
ured limit indicating that there is too much light for the user to reliably read the screen.
• Allocated to:
– DMI software[ci]
• Input:
– Intense light limit[functional variable]
• Output:
– DMI sound[functional variable][DMI ETCS User Interface][DMI Fault User Interface][DMI

410 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Maintenance User Interface]

• Sil: 2
• Associated interface:
– DMI ETCS User Interface[ci]
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]

Note: this function does not appear on any logical architecture diagram. It is an internal function of the DMI
component.

11.18.3.4 [IEVC.F4.28.10] Collect DMI maintenance and fault information [function]

Data
• Definition: The DMI software receives maintenance and faults information from the DMI Checker,
it provides information about the configuration of all DMI parts (version of hardware / software
/ configuration data) and reports the faults of DMI (selftest error, hardware failure) through the
network to the OBOM.
• Allocated to:
– DMI software[ci]
• Input:
– DMI computer maintenance data[functional variable]
• Output:
– DMI Maintenance Data[functional variable][DMI - OBOM interface]
• Sil: basic
• Associated interface:
– DMI - OBOM interface[ci]

11.18.4 Interfaces

The following external interfaces are applicable to the DMI software:

• VM - DMI interface[ci] [SyAD-R69-SIF-VM-DMI]: this specification maps the information exchanged in
dedicated sections. These mappings concern:
– DMI window ID
– DMI items to display in each window
– DMI user inputs in each window
– ETCS user requests
– ETCS button ID
• DMI - OBOM interface[ci] [SyAD-R61-SIF-OBOM-DMI]
• DMI ETCS User Interface[ci] [SyAD-R17-DMI]
• DMI Fault User Interface[ci] [SyAD-R72-SIF-Maintenance-Fault-UI]

11.18. DMI software 411 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• DMI Maintenance User Interface[ci] [SyAD-R72-SIF-Maintenance-Fault-UI]

The following messages are exchanged with the DMI Checker:
• DMI software graphical output[functional variable]
• DMI computer maintenance data[functional variable]

11.18.5 Configuration

Configuration Item

DMI Software Configuration Data Files [ci]

Data
• Sil: Undefined

It is the set of files to configure the DMI Software functionalities and communications:
• Soft-key mapping[functional variable]
• ETCS icons[functional variable]
• ETCS sounds[functional variable]
• National systems icons[functional variable]
• National systems dictionary[functional variable]
• National sounds[functional variable]
• Maintenance and Faults icons[functional variable]
• Text dictionary[functional variable]
• Intense light limit[functional variable]
• DMI network parameters[functional variable]
• Maximum number of reboot[functional variable]
• Speedometer scale[functional variable]

We now define the parameters applicable to the DMI configuration.

Functional Variable
Soft-key mapping [functional variable]
Data
• Objective: To provide the link between a key identifier and its associated virtual button.
• Description: This variable contains the correspondence between the identifier of a soft key
and its virtual button (F1 to F10 and H1 to H7 in DMI ETCS User Interface). Applicable to
soft key technology only.
• Family: Software
• Format: vendor dependent

Note: The format of this data depends on the DMI computer vendor. It is not specified in this version of

412 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

the specification.

Figure 11.52: Link between soft key and virtual buttons

Functional Variable
ETCS icons [functional variable]
Data
• Objective: To provide the used icons in the ETCS screens.
• Description: This variable contains the picture of ETCS symbols (defined in chapter 13
of DMI ETCS User Interface) and its identifier used in message received from the Safe
Computer. The picture size shall be suitable to the DMI resolution of 640x480.
• Family: Software
• Format: PNG or BMP, 24b RGB

Functional Variable
ETCS sounds [functional variable]

11.18. DMI software 413 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide the ETCS sounds to play.
• Description: This variable contains the sound file (defined in chapter 14 of DMI ETCS
User Interface) and its identifier used in message received from the Safe Computer. This
also includes the sounds used as high brightness warning and the sound used in the volume
window.
• Family: Software
• Format: wave file

Functional Variable
National systems icons [functional variable]
Data
• Objective: To provide the used icons in the national configuration screens.
• Description: This variable contains the picture, its identifier (NID_ICON) and the applicable
NID_NTC used in message received from the Safe Computer. The picture size shall be
suitable to the DMI resolution of 640x480.
• Family: Software
• Format: PNG or BMP, 24b RGB

Functional Variable
National sounds [functional variable]
Data
• Objective: To provide the additional sounds to play under national supervision.
• Description: This variable contains the sound file, its identifier (NID_SOUND) and the
applicable NID_NTC used in message received from the Safe Computer.
• Family: Software
• Format: wave file

Functional Variable
National systems dictionary [functional variable]

414 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide the list and mapping of National System ID concerning indicators,
positions, buttons, data, icons and sounds.
• Description: This variable contains the list of buttons (NID_BUTTON) with their character-
istics, the list of button positions (NID_BUTPOS), the list of data (NID_DATA) with the link
to the associated label, the list of icons (NID_ICON) with the name of the associated file,
the list of indicators (NID_INDICATOR), the list of indicator positions (NID_INDPOS),
the list of sounds (NID_SOUND) with their associated sound file.
• Family: Software
• Type: dmi_ntc_dictionary
• Format: BSON
• Protocol: file

<NTC_ID> ::= integer

<NTC_name_text_code> ::= string ; code used in the text dictionary
<NTC_BUTTON> ::= integer
<NTC_BUTTON_LIST> ::= [<NTC_BUTTON>]
<NTC_BUTPOS_ID> ::= integer
<Screen_position> ::= string ; position code on the ETCS default window
<NTC_BUTPOS_LIST> ::= [<NTC_BUTPOS_ID> <Screen_position>]
<NID_DATA> ::= integer
<NID_DATA_LABEL_CODE> ::= string ; code used in the text translation
˓→dictionary

<NID_DATA_LIST> ::= [<NID_DATA> <NID_DATA_LABEL_CODE>]

<NID_ICON> ::= Integer
<NID_ICON_FILE_NAME> ::= string ; file name for this icon ID
<NID_ICON_LIST> ::= [<NID_ICON> <NID_ICON_FILE_NAME>]
<NID_INDICATOR> ::= integer
<NID_INDICATOR_LIST> ::= [<NID_INDICATOR>]
<NID_INDPOS> ::= integer
<Screen_position> ::= string ; position code on the ETCS default window
<NID_INDPOS_LIST> ::= [<NID_INDPOS> <Screen_position>]
<NID_SOUND> ::= Integer
<NID_SOUND_FILE_NAME> ::= string ; file name for this sound ID
<NID_SOUND_LIST> ::= [<NID_SOUND> <NID_SOUND_FILE_NAME>]

[<NTC_ID> <NTC_name_text_code> <NTC_BUTTON_LIST> <NTC_BUTPOS_LIST> <NID_DATA_

˓→LIST> <NID_ICON_LIST> <NID_INDICATOR_LIST> <NID_INDPOS_LIST> <NID_SOUND_

˓→LIST>]

Functional Variable
Maintenance and Faults icons [functional variable]

11.18. DMI software 415 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide the used icons in the Maintenance and Faults screens.
• Description: This variable contains the picture (interactive tests, faults synoptics) and its
identifier used in message received from OBOM. The picture size shall be suitable to the
DMI resolution of 640x480.
• Family: Software
• Format: PNG or BMP, 24b RGB

Functional Variable
Text dictionary [functional variable]
Data
• Objective: To Provide the suitable text according to the DMI language selection.
• Description: This variable contains the list of all coded texts in the DMI for the supported
language (i.e. English, French, Netherland) It shall cover the translation of the text labels
displayed on buttons, text messages (except plain text messages given from trackside), the
window titles and text labels for the input fields, the echo texts and the data view items.
• Family: Software
• Type: dmi_text_dictionary
• Format: BSON
• Protocol: file

<Language_ID> ::= string ; Language (i.e. English, French, ...)

<Text_code> ::= string ; English text will be used as code

<Translation> ::= string

<Translation_table> ::= [<Text_code> <Translation>]

[<Language_ID> <Translation_table>]

Functional Variable
Intense light limit [functional variable]

416 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide the light value for intense light detection
• Description: This variable contains the light value from which there is intense light condi-
tions.
• Family: Software
• Type: DMIIntenseLightLimit
• Format: vendor dependent
• Protocol: System Parameters
• Consumed by:
– [IEVC.F3.02.09.03.01] Manage intense light condition[function]

Note: The format of this parameter is linked to the measure of the light sensor which depends on the
DMI computer vendor. It is not specified in this version of the specification.

Functional Variable
DMI network parameters [functional variable]
Data
• Objective: To provide the network parameter to the DMI.
• Description: This variable contains network parameter for the DMI operation (IP address).
• Family: Software
• Type: Internet Protocol Address
• Format: SSS.SSS.SSS.XXX (SSS.SSS.SSS: subnet address, address in the subnet)
• Protocol: System Parameters

The IP address used for each component of iEVC are referenced in the table IP address plan

Functional Variable
Maximum number of reboot [functional variable]
Data
• Objective: To provide the maximum number of reboot due to the watchdog.
• Description: This variable is a single constant.
• Family: Software
• Type: Constants
• Format: Integer

11.18. DMI software 417 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
Speedometer scale [functional variable]
Data
• Objective: To provide the type of speedometer scale among the 4 scales allowed by
ERA_ERTMS_015560.
• Description: This variable is a single constant with possible values '0-400kph', '0-250kph',
'0-180kph' and '0-140kph'.
• Family: Software
• Type: Constants
• Format: Integer

11.18.6 Internal variables

Functional Variable
Data for maintenance or faults screen [functional variable]
Data
• Objective: To provide the user inputs related to the maintenance or faults screen
• Description: It is an internal variable of the DMI software, no further details are provided.
• Family: Software
• Produced by:
– [IEVC.F3.02.09.03] Manage ETCS display information[function]
• Consumed by:
– [IEVC.F4.29.01] Manage maintenance and fault screens[function]

Functional Variable
Maintenance and faults screen display information [functional variable]
Data
• Objective: To provide the maintenance and faults screen to be integrated in the DMI display.
• Description: It is an internal variable of the DMI software, no further details are provided.
• Family: Software
• Produced by:
– [IEVC.F4.29.01] Manage maintenance and fault screens[function]
• Consumed by:
– [IEVC.F3.02.09.03] Manage ETCS display information[function]

418 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.18.7 Requirements

11.18.7.1 General requirements

Allocate
Allocation of URS requirement to remember setting parameters across power cycles. [allocate]
Data
• Requirement:
– tsc-req-urs-driver-dmi-remember-settings[req]
• Ci:
– DMI software[ci]
• Function:
– [IEVC.F4.29.01] Manage maintenance and fault screens[function]
• Justification: The DMI software stores the setting parameters in a non-volatile memory of
the DMI hardware.

Allocate
In Isolation mode, the DMI shall display the speed of the train. [allocate]
Data
• Requirement:
– tsc-req-urs-driver-backup-speed-display[req]
• Ci:
– Subset 026 application[ci]
• Justification: The DMI software displays the ETCS status to the driver provided by SUbset
026 application

Requirement

The DMI shall detect when there is too much light for the user to reliably read the screen, and issue
a warning sound. [id:tsc-req-ievc-ob-dmi-sw-light-warning-sound][p1][s]

The sound wav file shall be configurable. The suggested file name is ‘light_warning.wav’.

Requirement

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The DMI software shall set its volume to the value provided by the Subset 026 application unless the
Volume window is being displayed. [id:tsc-req-ievc-ob-dmi-sw-volume][p1][ns]

When the Volume window is being displayed, the volume of the DMI is the one selected based on the user
inputs.
When the DMI volume value is modified based on the information from the Subset 026 application, the
DMI software shall update its stored volume accordingly.

Requirement

If no volume value is provided by the Subset 026 application, the DMI software shall select the
last stored volume in the non-volatile memory of the DMI hardware, or the median value of the
volume range as default value when there is no stored value. [id:tsc-req-ievc-ob-dmi-sw-volume-default-
value][p1][ns]

Requirement

Each time a new volume value is accepted by the DMI user, the DMI software shall provide the
newly selected value to the Subset 026 application and update its stored volume in the non-volatile
memory of the DMI hardware. [id:tsc-req-ievc-ob-dmi-sw-volume-change][p1][ns]

Requirement

The DMI software shall set its language to the value provided by the Subset 026 application unless
the Language window is being displayed. [id:tsc-req-ievc-ob-dmi-sw-language][p1][ns]

When the Language window is being displayed, the Language of the DMI is the one selected based on the
user inputs.
When the DMI Language value is modified based on the information from the Subset 026 application, the
DMI software shall update its stored language accordingly.

Requirement

If no language value is provided by the Subset 026 application, the DMI software shall select the last
stored language in the non-volatile memory of the DMI hardware. [id:tsc-req-ievc-ob-dmi-sw-language-
default-value][p1][ns]

By default the selected language should be ‘English’ when there is no stored language or the 1st language
configured when there is no ‘English’.

Requirement

Each time a new language value is accepted by the DMI user, the DMI software shall provide the
newly selected value to the Subset 026 application and update its stored language in the non-volatile
memory of the DMI hardware. [id:tsc-req-ievc-ob-dmi-sw-language-change][p1][ns]

Requirement

The text translations for buttons, window titles, text messages, data label shall be contained in the
DMI software configuration data [id:tsc-req-ievc-ob-dmi-sw-text-translations-in-configuration][p1][ns]

11.18. DMI software 421 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The text translations for buttons, window titles, text messages, data label shall be selected based on
the current language. [id:tsc-req-ievc-ob-dmi-sw-text-translations-selection][p1][ns]

The functional variable ‘selected_language’ is provided by the Subset 026 application and can be modified
in the ‘Language window’.

Requirement

The code used to identify a text to translate for a national system (NTC) shall contain the identifier
of this NTC. [id:tsc-req-ievc-ob-dmi-sw-text-code-ntc][p1][ns]

example: NTC_9_Button_1 identifies the label related to the button with ID 1 for the NTC with ID 9.

Requirement

The DMI software shall display and enable the [Close] button in the current window when required
by the Subset 026 application. Symbols NA11 shall be used. [id:tsc-req-ievc-ob-dmi-sw-close-button-
display][p1][ns]

Requirement

When the [Close] button is pressed, the DMI software shall report it to the Subset 026 application as
a user request in order for the Subset 026 to manage the window display sequence. [id:tsc-req-ievc-
ob-dmi-sw-close-button-pressed][p1][ns]

Requirement

The DMI software shall use and display the following navigation buttons where appropriate: [En-
ter], [Next], [Previous], [Delete], [Up], [Down], [Scale Up], [Scale Down] and [More]. [id:tsc-req-ievc-
ob-dmi-sw-navigation-buttons][p1][ns]

These navigation buttons are not controlled by the Subset 026 application.
• (a) [Enter] button: to be used to accept the input field data value; the [Enter] button finishes the
handling of the current selection; symbol NA20 of shall be used (soft key technology).
• (b) [Next] button: to be used to select the next window related to the same topic using the symbol
NA17.
• (c) [Previous] button: to be used to select the previous window related to the same topic using the
symbols NA18.
• (d) [Delete] button: to be used to delete the just entered character, symbol NA21 of chapter 13 shall
be used.
• (e) [Up] or [Down] button: to be used to scroll respectively up and down in lists; symbols NA13 and
NA14 of chapter 13 shall be used.
• (f) [Scale Up] or [Scale Down] button: to be used respectively to shorten/enlarge a distance scale;
symbols NA03, NA04 (touch screen technology) and NA07, NA08 (soft key technology) shall be
used.
• (g) [More] button: to be used to present the next predefined choices of a dedicated keyboard, symbol
NA23 shall be used.

422 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The [Close], [Next], [Previous], [Scale Up], [Scale Down] and [More] navigation buttons shall always
be up-type buttons. [id:tsc-req-ievc-ob-dmi-sw-navigation-buttons-up-type][p1][ns]

Requirement

The DMI software shall display a driver acknowledgement when requested by the Subset 026 appli-
cation. [id:tsc-req-ievc-ob-dmi-sw-display-ack][p1][ns]

The display of the acknowledgement shall continue as long as the display is requested by the Subset 026
application.

Requirement

When the driver performs an acknowledgement on the DMI, the DMI software shall feedback this
as a user request to the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-ack-request][p1][ns]

Requirement

When a driver’s acknowledgement is displayed, a yellow flashing frame shall be used to surround
the related object or text message. [id:tsc-req-ievc-ob-dmi-sw-display-ack-flashing-frame][p1][ns]

Requirement

The DMI software shall play the sounds ‘Sinfo’,’S1’,’S2’ and National system sounds based on the
requests from the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-play-sound][p1][ns]

The requests are included in ‘VM sound control’ for Sinfo, S1 and S2 and in ‘ntc_sound’ for national
systems (refer to Virtual Machine DMI Interface Specification).

Requirement

The DMI software shall play sounds only when the screen activation status is ‘screen active - total
DMI image’, or ‘screen active - left part of the DMI image’, or ‘screen active - half part of the DMI
image in degraded mode’. [id:tsc-req-ievc-ob-dmi-sw-play-sound-condition][p1][ns]

Refer to Screen activation status message[functional variable][VM - Applications interface] for a detailed
list of the possibles screen activation statuses.

Requirement

The DMI software shall display the train speed pointer in white, grey, yellow, orange or red ac-
cording to the request from the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-speed-pointer-color-
display][p1][ns]

Requirement

The DMI software shall display ‘Vperm’, ‘Vtarget’, ‘VSBI’ and ‘Vrelease’ information on the Cir-
cular Speed Gauge (CSG) according to the request from the Subset 026 application. [id:tsc-req-ievc-
ob-dmi-sw-csg-display][p1][ns]

The Subset 026 display request includes the CSG elements to display, their speed and their color.

11.18. DMI software 423 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The DMI software shall display the Basic Speed Hook(s) according to the request from the Subset
026 application. [id:tsc-req-ievc-ob-dmi-sw-hook-display][p1][ns]

The information related to hook display is provided together with the CSG information related to ‘Vperm’
and ‘Vtarget’.

Requirement

The DMI software shall display the graphical presentation of the Release speed according to the
request from the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-release-speed-display][p1][ns]

The Subset 026 display request includes the Release speed value and the color to use.

Requirement

The DMI software shall display the digital presentation of the Release speed according to the request
from the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-release-speed-digital-display][p1][ns]

The Subset 026 display request includes the speed value to represent.

Requirement

When the Lowest Supervised Speed within the Movement Authority (LSSMA) display is requested
by the Subset 026 application, the DMI software shall display it with a number in grey vertically
and horizontally centred in A1. [id:tsc-req-ievc-ob-dmi-sw-lssma-display][p1][ns]

The Subset 026 display request includes the LSSMA speed value to represent.

Requirement

The DMI software shall display the distance to target bar and scale in A3 according to the request
from the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-target-distance-display][p1][ns]

The Subset 026 display request includes the distance value to represent.

Requirement

The DMI software shall display the distance to target digital in A2 according to the request from the
Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-target-distance-digital-display][p1][ns]

The Subset 026 display request includes the distance value to represent.

Requirement

If the display of a driver acknowledgement for releasing a brake intervention is requested by the
Subset 026 application, the ST01 symbol shall be used as object of the acknowledgement. [id:tsc-req-
ievc-ob-dmi-sw-brake-release-ack-display][p1][ns]

Requirement

When using touch screen technology, and when the speed/distance information toggling function
is active, the areas A and B shall become sensitive to allow the driver to toggle on and off the dis-

424 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

play of the speed/distance information. [id:tsc-req-ievc-ob-dmi-sw-speed-distance-toggling-touchscreen-a-b-

sensitive][p1][ns]

The activation of the speed/distance information toggling function is an information provided by the Subset
026 application.

Requirement

When the speed/distance information toggling function is active and when the toggle is pressed by
the driver, the DMI software shall provide a toggling request to the Subset 026 application. [id:tsc-
req-ievc-ob-dmi-sw-speed-distance-toggling-request][p1][ns]

The Subset 026 application is responsible for the update of the speed/distance information display update
based on the toggle request.

Requirement

When using soft key technology, and when the speed/distance information toggling function is active,
F7 shall be an enabled up-type button showing the symbol DR01 to allow the driver to toggle on
and off the display of the speed/distance information. [id:tsc-req-ievc-ob-dmi-sw-speed-distance-toggling-
softkey-f7][p1][ns]

The activation of the speed/distance information toggling function is an information provided by the Subset
026 application.

Requirement

When the speed/distance information toggling function is inactive: For the touch screen technology,
the A/B areas shall not be sensitive; and for the soft key technology, no button shall exist in F7 for
the toggling function. [id:tsc-req-ievc-ob-dmi-sw-speed-distance-no-toggling-disabled-buttons][p1][ns]

The activation of the speed/distance information toggling function is an information provided by the Subset
026 application.

Requirement

The DMI software shall display the Time To Indication (TTI) in A1 according to the request from
the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-tti-display][p1][ns]

The Subset 026 display request includes the TTI value to represent.

Requirement

The DMI software shall display the current ERTMS/ETCS mode in area B7 according to the request
from the Subset 026 application. The following symbols shall be used: MO01, MO04, MO06, MO07,
MO09, MO11, MO12, MO13, MO14, MO16, MO18 or MO21. [id:tsc-req-ievc-ob-dmi-sw-ertms-etcs-
mode-display][p1][ns]

Requirement

The DMI software shall display a specific configurable icon in isolation mode according to the re-
quest from the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-isolation-mode][p1][ns]

11.18. DMI software 425 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The DMI software shall display a specific text message to inform the driver when the communica-
tion with the safe computer is lost (for example in case of system failure) [id:tsc-req-ievc-ob-dmi-sw-
communication-loss][p1][ns]

All the display item that were requested by the safe computer prior to the communication loss shall be
removed. The speed indication shall be removed as well.
A dedicated icon may also be used to inform the driver in addition to the text message.

Requirement

The DMI software shall display a specific text message to inform the driver when the communication
with the Virtual Machine is lost. [id:tsc-req-ievc-ob-dmi-sw-vm-communication-loss][p1][ns]

This applies also in case the VM enters its VM_FAULT mode.

All the display item that were requested by the VM prior to the communication loss shall be removed. The
speed indication shall be removed as well.
A dedicated icon may also be used to inform the driver in addition to the text message.

Requirement

The DMI software shall display the Symbol MO03 (active override) as long as it is requested by the
Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-active-override-display][p1][ns]

Requirement

The DMI software shall display the current ERTMS/ETCS level in area C8 according to the request
from the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-level-display][p1][ns]

Requirement

If an acknowledgement is requested by the Subset 026 application for the ERTMS/ETCS level an-
nouncement, the symbol LE07, LE09, LE11, LE13, LE15 shall be used, depending on the next
ERTMS/ETCS level announcement. [id:tsc-req-ievc-ob-dmi-sw-level-announcement-ack-display][p1][ns]

For the relationship between symbol and level announced, please refer to Chapter 13 / Table 59 of
ERA_ERTMS_015560 V3.6.0.

Requirement

If an ERTMS/ETCS level announcement without acknowledgement is requested by the Subset 026

application, the symbol LE06, LE08, LE10, LE12 or LE14 shall be used, depending on the next
ERTMS/ETCS level announcement. [id:tsc-req-ievc-ob-dmi-sw-level-announcement-display][p1][ns]

For the relationship between symbol and level announced, please refer to Chapter 13 / Table 59 of
ERA_ERTMS_015560 V3.6.0.

Requirement

The DMI software shall display the text messages according to the request from the Subset 026
application. [id:tsc-req-ievc-ob-dmi-sw-text-msg][p1][ns]

426 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The DMI software shall display the orders and announcements of track condition in area B3/4/5
according to the request and order provided by the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-
track-conditions-display][p1][ns]

Requirement

The DMI software shall display the tunnel stopping area according to the display request and as-
sociated distance provided by the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-tunnel-stopping-
display][p1][ns]

Requirement

When the tunnel stopping area toggling function is active, it shall be possible to toggle on and off
the display of the tunnel stopping area by touching the sensitive area of C2/C3/C4 for touch screen
technology or by using F6 for soft key technology. [id:tsc-req-ievc-ob-dmi-sw-tunnel-stopping-toggling-
button][p1][ns]

The activation of the tunnel stopping area toggling function is an information provided by the Subset 026
application.

Requirement

When the tunnel stopping area toggling function is active and when the toggle is pressed by the
driver, the DMI software shall provide a toggling request to the Subset 026 application. [id:tsc-req-
ievc-ob-dmi-sw-tunnel-stopping-toggling-request][p1][ns]

The activation of the tunnel stopping area toggling function is an information provided by the Subset 026
application.

Requirement

The DMI software shall display the adhesion factor “slippery rail” using symbol ST02 in area A4
according to the display request from the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-adhesion-
display][p1][ns]

Requirement

The DMI software shall display the level crossing “not protected” using symbol LX01 in area
B3/4/5 according to the display request from the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-lx-
display][p1][ns]

Requirement

The DMI software shall display the orders and announcements of track conditions in area B3/4/5
according to the display request from the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-tc-display-
order][p1][ns]

Requirement

The DMI software shall display the Set Speed indication in area B0 according to the display request
from the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-set-speed-display][p1][ns]

11.18. DMI software 427 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The Subset 026 display request includes the Set Speed value to use for the representation in area B0.

Requirement

The DMI software shall display the planning information in area D according to the request
and information provided by the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-planning-area-
display][p1][ns]

The Subset 026 display request includes:

a) orders and announcements of track conditions (excluding tunnel stopping areas)
b) gradient profile
c) speed profile discontinuity information
d) Planning Area Speed Profile (PASP)
e) indication marker location.

Requirement

When the planning information is displayed, the DMI software shall manage the zoom function.
[id:tsc-req-ievc-ob-dmi-sw-planning-area-zoom][p1][ns]

The DMI software manages the update of the display due to a change of scale on its own, without any
additional interaction with the Subset 026 application.

Requirement

The DMI software shall display the Safe radio connection indication in area E1 according to
the request provided by the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-safe-radio-connection-
display][p1][ns]

The Subset 026 display request includes the state of the Safe radio connection.

Requirement

The DMI software shall display the indication that reversing is permitted in area C6 using the sym-
bol ST06 according to the request provided by the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-
reversing-permitted-display][p1][ns]

Requirement

The DMI software shall display the local time indication in area G13 according to the request pro-
vided by the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-local-time-display][p1][ns]

Requirement

The DMI software shall display the geographical position in area G12 according to the request
provided by the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-geo-pos-display][p1][ns]

428 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

When the the geographical position toggling function is active, the DMI software shall enable the ge-
ographical toggling button to allow the user to toggle on and off the display by touching the sensitive
area of G12 for touch screen technology or by using F8 for soft key technology. [id:tsc-req-ievc-ob-
dmi-sw-geo-pos-toggling-button][p1][ns]

The activation of the geographical position area toggling function is an information provided by the Subset
026 application.

Requirement

When the geographical position toggling function is active and when the toggle is pressed by the
driver, the DMI software shall provide a toggling request to the Subset 026 application. [id:tsc-req-
ievc-ob-dmi-sw-geo-pos-toggling-request][p1][ns]

The activation of the geographical position toggling function is an information provided by the Subset 026
application.

Requirement

When the display status of a button is managed by the Subset 026 application, the DMI software
shall display and enable the button based on the display status information provided by the Subset
026 application. [id:tsc-req-ievc-ob-dmi-sw-button-display][p1][ns]

The display status can be one of the following:

Requirement

When a button is pressed by the user, and when the display status of this button is managed by the
Subset 026 application, the DMI software shall provide a user request related the activation of this
button to the Subset 026 application [id:tsc-req-ievc-ob-dmi-sw-button-request][p1][ns]

The list of window buttons for which the display status is controlled by the Subset 026 application is
provided in Virtual Machine DMI Interface Specification.

Requirement

The DMI software shall display the sub-level windows according to the request provided by the
Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-window-display][p1][ns]

The list of windows for which the display is controlled by the Subset 026 application is provided in Virtual
Machine DMI Interface Specification.

11.18. DMI software 429 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

When displaying a data entry or a data validation window, the DMI software shall display the label
and data part of the echo text. The data part is provided by the Subset 026 application including
any data check errors. [id:tsc-req-ievc-ob-dmi-sw-echo-text-data-part-display][p1][s]

Any data check error or warning is raised by the Subset 026 for each input field. The DMI software
replaces the data part of the echo text with ‘????’ or ‘++++’ according to the rules of section 10.3.4 in
ERA_ERTMS_015560 v360.
This requirement applies to:
• train data
• SR speed / distance
• Set VBC
• Remove VBC
• NTC X data
• Odometry parameters

Requirement

When displaying a data entry window, the DMI software shall replace the data part of the echo text
of a specific input field with ‘++++’ in red in case a failed technical range check or a failed technical
resolution check is reported by the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-echo-text-technical-
check][p1][s]

Requirement

When displaying a data entry window, the DMI software shall replace the data part of the echo text
of a specific input field with ‘????’ in red in case a failed technical cross-check is reported by the
Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-echo-text-technical-cross-check][p1][s]

Requirement

When displaying a data entry window, the DMI software shall replace the data part of the echo text
of a specific input field with ‘++++’ in yellow in case a failed operational range check is reported by
the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-echo-text-operational-check][p1][s]

Requirement

When displaying a data entry window, the DMI software shall replace the data part of the echo text
of a specific input field with ‘????’ in yellow in case a failed operational cross-check is reported by
the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-echo-text-operational-cross-check][p1][s]

Requirement

When displaying a data entry window, and when a data value is accepted by the driver, the DMI
software shall provide this data value to the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-data-
entry-data-accepted][p1][ns]

The accepted value is used by the Subset 026 application to trigger the range and resolution checks, if any.

430 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

When displaying a data entry window, and when a valid button activation is performed on the ‘Yes’
button attached to the question ‘[Window Title] entry complete?’, the DMI software shall inform
the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-data-entry-complete-yes][p1][ns]

After the ‘Yes’ button has been pressed, the Subset 026 application triggers the data cross-checks, if any.

Requirement

When displaying a data entry window, and when a valid button activation is performed on the delay-
type ‘Yes’ button attached to the question ‘[Window Title] entry complete?’, the DMI software shall
inform the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-entry-complete-yes-delay-type][p1][ns]

This information is used by the Subset 026 application to accepts the entered data with operational check
failed and display the validation window.

Requirement

When displaying a data entry window, the DMI software shall use the default values provided by
the Subset 026 application as default value for the input fields. [id:tsc-req-ievc-ob-dmi-sw-data-entry-
default-value-display][p1][ns]

Requirement

The DMI software shall use specific NTC labels in its configuration data for the NTC level buttons
and for the NTC windows titles. [id:tsc-req-ievc-ob-dmi-sw-ertms-etcs-level-ntc-labels][p1][ns]

The selection of label is based on the NTC id provided by the Subset 026 application.
These configured labels are used as button labels used when displaying the ERTMS/ETCS level window
or the NTC data entry selection window, or to replace ‘NTC X’ in the title of NTC X data view window

Requirement

When the ERTMS/ETCS level window must be displayed, the DMI software shall only enable the
buttons corresponding to the supported ERTMS/ETCS levels based on the list provided by the Sub-
set 026 application. [id:tsc-req-ievc-ob-dmi-sw-ertms-etcs-level-buttons-activation][p1][ns]

Requirement

When the Driver ID window must be displayed, the DMI software shall also display a ‘settings’
button with the symbol SE04 and a ‘train running number’ button with the label ’TRN’ unless the
display status of these buttons are set to ‘hidden’ by the Subset 026 application. [id:tsc-req-ievc-ob-
dmi-sw-driver-id-window-settings-trn-buttons-display][p1][ns]

Requirement

The DMI software shall be able to display the Train data window using either the Fixed train data
entry layout or in the Flexible data entry layout based on the window ID requested by the Subset
026 application. [id:tsc-req-ievc-ob-dmi-sw-train-data-entry-layout-display][p1][ns]

The selection between the two layouts is controlled by the Subset 026 application through the request of
specific window IDs for ‘Fixed train data entry’ and ‘Flexible data entry’.

11.18. DMI software 431 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

When displaying the Data view window, the DMI software shall display the data view items as
specified in Table 44 for fixed train data entry and as specified in Table 45 for flexible train data
entry, and using data values provided by the Subset 026 application. (Tables 44 and 45 are in
ERA_ERTMS_015560 v360). [id:tsc-req-ievc-ob-dmi-sw-train-data-view-display][p1][ns]

Requirement

When displaying the Data view window, for the topic ‘Train data’, the DMI software shall only
display the data provided as ‘to be displayed’ by the Subset 026 application. [id:tsc-req-ievc-ob-dmi-
sw-train-data-view-train-data-to-display][p1][ns]

Requirement

When displaying the NTC data entry selection window, the DMI software shall display the NTC
buttons only for the NTC included in the list provided by the Subset 026 application. [id:tsc-req-ievc-
ob-dmi-sw-ntc-data-entry-selection-ntc-buttons][p1][ns]

Requirement

When displaying the NTC data entry selection window, the DMI software shall display the NTC
buttons based on the display status provided by the Subset 026 application. [id:tsc-req-ievc-ob-dmi-
sw-ntc-data-entry-selection-ntc-buttons-status][p1][ns]

The display status can be one of the following:

Requirement

When displaying NTC X data window, the DMI software shall manage the screen display based
on the information provided by the Subset 026 application which includes the NTC id, the number
of input fields, their labels, their their default values, their associated keyboards and the list of
permitted values, if any. [id:tsc-req-ievc-ob-dmi-sw-ntc-data-entry-display][p1][ns]

Requirement

When displaying data view window, the DMI software shall manage the navigation between the
windows and display the ETCS as well as the NTC information based on the information provided
by the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-ntc-data-view-navigation][p1][ns]

Requirement

The DMI software shall allow the configuration of several NTC default windows. The selection of
the NTC default windows to display shall be made based on the ERTMS/ETCS level provided by
the Subset 026 application. [id:tsc-req-ievc-ob-dmi-sw-ntc-default-window][p1][ns]

The NTC default windows may differ by the different positioning of the ETCS buttons.

432 of 750 11.18. DMI software

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The dedicated keyboard used to change the volume level shall be as specified hereafter [id:tsc-req-
ievc-ob-dmi-sw-volume-window-keyboard][p1][ns]

Table 11.5: dedicated keyboard in volume window

Button /selection # Label volume value
1 25 % set volume to 25
2 50 % set volume to 50
3 100 % set volume to 100
5 << decrease current volume by 10
6 >> increase current volume by 10
8 < decrease current volume by 1
9 > increase current volume by 1

The labels shall be configurable by the installation project through the DMI software configuration data.
The requirements related to dedicated keyboards shall still apply (ERA-ERTMS-015560-10-3-5-18, ERA-
ERTMS-015560-10-3-5-19, ERA-ERTMS-015560-10-3-6-22, ERA-ERTMS-015560-10-3-6-22-1, ERA-
ERTMS-015560-10-3-6-22-2).

Requirement

In the volume window, when the driver presses a button that modifies the volume, the DMI software
shall give a preview of the volume selected by the driver by playing a sound. This sound shall
however not be disturbing for the driver. This sound shall sufficiently different from other sound
used onboard (ie. sounds used in STM). [id:tsc-req-ievc-ob-dmi-sw-volume-preview][p1][s]

The sound wav file shall be configurable. The suggested file name is ‘volume_preview.wav’.

Requirement

The dedicated keyboard used to change the brightness level shall be as specified hereafter [id:tsc-req-
ievc-ob-dmi-sw-brightness-window-keyboard][p1][ns]

Table 11.6: dedicated keyboard in brightness window

Button /selection # Label brightness value
1 25 % set brightness to 25
2 50 % set brightness to 50
3 100 % set brightness to 100
4 Auto set brightness management to automatic
5 << decrease current brightness by 10
6 >> increase current brightness by 10
8 < decrease current brightness by 1
9 > increase current brightness by 1

11.18. DMI software 433 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.18.8 Failure modes

The DMI software has no specific failure mode.

11.19 iBTM application

Important: This component is included in the iEVC Sensor kit[ci]

Note: In this section, the term ‘signalling application’ refers to the application that supervises the train movement.
It is either the Subset 026 application or a Class B application.

11.19.1 Description

The iBTM application is in charge of verifying, filtering and decoding the balise and loop information received
from the iBTM-RX components. For balise telegrams, it also locates the balise reference position using the
odometry information provided by the odometry application that is also located inside the Safe computer (tsc-req-
subset-036-4-2-4-2-3[req]).

Allocate
Allocation of Subset 036 requirement on the origin of the time or position used to compute the
location reference. [allocate]
Data
• Requirement:
– tsc-req-subset-036-4-2-4-2-3[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: iBTM application
• Justification: The iBTM application is in charge of computing the reference location of the
balise using the odometry information provided by the odometry application that is also
located inside the Safe computer.

The iBTM application commands the iBTM-TX Tele-powering mode and manages the iBTM test sequence.
The iBTM application manage the exchange of messages with the V1/V2 interfaces as described in Subset-085.
The iBTM application centralizes any iBTM failure detected and raises them to the signalling application and to
the LRU application.
The logical architecture of the iBTM application and its interactions with the other components are described in
Fig. 11.53

434 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.53: iBTM Application logical architecture

Note: the reporting of the alarms to the LRU application is illustrated in Fig. 8.29.

The iEVC can be operated using 2 Euroantenna (one per cab or desk). This is useful for long locomotives using
a centralized iEVC On-board for both cabins or desks. In this case it may be impossible to respect the installation
constraint from Subset 040 (see tsc-req-ievc-euroantenna-ss40-installation[req]). When this happens, 2 Sensor
box hardware must be used. They are connected to a same Safe computer. Each Sensor box hardware corresponds
to one cabin or desk and is connected to its own Euroantenna. The iBTM components (iBTM-RX and iBTM-TX)
are able to detect their associated installed cabin through the type of Euroantenna cable used for the installation
(see [SyAD-R55-SIF-iBTM-Euroantenna]).

11.19. iBTM application 435 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.54: iEVC On-board subsystem using 2 Euroantenna, 1 per cabin or desk

The iBTM application receives the active cabin information from the signalling application and uses this infor-
mation to address the correct iBTM components. The Tele-powering of the inactive iBTM-TX component is set
to ‘off’. The iBTM application only processes the detection and telegram messages of the iBTM components
associated to the active cabin.
The iBTM application relays the Spread Spectrum Code that needs to be used for the Euroloop demodulation.
This code is provided by the signalling application based on the content of a previously passed ‘End Of Loop
Marker’ (EOLM) balise group; refer to [SyAD-R8-SS026] for more details about the EOLM and its associated
packets.

11.19.2 Modes

The iBTM application has no specific mode.

11.19.3 Functions

11.19.3.1 [IEVC.F3.02.07.09] Verify, filter and decode Eurobalise and Euroloop telegram [func-
tion]

Data
• Definition: The iBTM application is in charge of building the balise contact information based on
the detection and telegram information provided by the 2 iBTM-RX. The iBTM application filters
the side lobes. It also verifies the consistency of the information provided by the 2 iBTM-RX
components and reports the balise information to the signalling application. The iBTM application
is in charge of the unscrambling Eurobalise and Euroloop telegram data and checking the validity
of the coding against the coding requirements of Subset-036 §4.3.

436 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Allocated to:
– iBTM application[ci]
• Input:
– Balise or loop detection message[functional variable][VM - iBTM-RX interface][VM - Appli-
cations interface]
– Up-link telegram message[functional variable][VM - iBTM-RX interface][VM - Applications
interface]
– Odometry information message[functional variable]
– Test V2 data[functional variable]
• Output:
– Telegram information[functional variable]
– Balise contact alarm[functional variable]
• Sil: 4
• Associated interface:
– VM - Applications interface[ci]

The extracted information is the Telegram information[functional variable] that is provided to the signalling ap-
plication through the ETCS messages application. This message also contains information about any detected
telegram error:
• Telegram coding errors (errors related to coding requirements of §4.3 in Subset-036):
– Start bit detection error (step 3)
– 11-bit words to 10-bit words translation error (step 5)
– Control bit error (step 7 & 8)
– Telegram size error (size is not 341 or 1023)
• No telegram reported
This function needs the odometry information to filter the side lobes and to locate the balise center. This informa-
tion is provided by the Odometry Application.
This function can also use odometry information from the V2 test interface. These V2 data are provided by
function [IEVC.F3.03.03.02] Manage V1 and V2 interfaces[function]. This feature is only used when the VM test
mode is enabled.

11.19.3.2 [IEVC.F3.02.07.10] Manage Tele-powering mode [function]

Data
• Definition: The iBTM application is in charge of commanding the Tele-powering mode to the
iBTM-TX component using the Tele-powering setup message. When 2 Euroantenna are used, this
function disables the Tele-powering of the inactive Euroantenna. Through this function, the iBTM
application also manages the iBTM test. It triggers the start of a test transmission using the iBTM
test message and controls the balise contact information provided by the 2 iBTM-RX channels to
establish the iBTM test result.
• Allocated to:
– iBTM application[ci]
• Input:

11.19. iBTM application 437 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– iBTM-TX status message[functional variable][VM - iBTM-TX interface][VM - Applications

interface]
– Balise or loop detection message[functional variable][VM - iBTM-RX interface][VM - Appli-
cations interface]
– Up-link telegram message[functional variable][VM - iBTM-RX interface][VM - Applications
interface]
– Active Euroantenna[functional variable]
– iBTM test request[functional variable]
– Test V1 mode[functional variable]
– Test mode enabled[functional variable]
• Output:
– iBTM test message[functional variable][VM - iBTM-TX interface][VM - Applications inter-
face]
– Tele-powering setup message[functional variable][VM - iBTM-TX interface][VM - Applica-
tions interface]
– iBTM-TX status alarm[functional variable]
– Tele-powering detection error[functional variable]
– iBTM test alarm[functional variable]
– iBTM test report[functional variable]
• Sil: 4
• Associated interface:
– VM - Applications interface[ci]

The Tele-powering modes are:

• Continuous Wave Tele-powering mode (CW): used for the Tele-powering of Eurobalise devices and for the
activation of Euroloop devices.
• Toggling Tele-powering mode (TM): used for the Tele-powering of Eurobalise and KER balise devices, and
for the activation of Euroloop devices.
• Non Toggling Tele-powering mode (NT): used for the Tele-powering of KER balise devices (only)
• Tele-Powering OFF (Off): No Tele-powering signal is produced.
There are 3 types of iBTM tests:
• Eurobalise iBTM test: it tests the Eurobalise reception chains including demodulators A and B of each
iBTM-RX board
• KER iBTM test: it tests the KER reception chains including the KER demodulators A and B of each iBTM-
RX board
• Euroloop iBTM test: it tests the Euroloop reception chains including the Euroloop demodulator of each
iBTM-RX board
The Eurobalise and KER iBTM tests are launched automatically at start-up. These iBTM tests is also launched
automatically when no balise has been read for a defined period. In this case, the test sequence is launched as
soon as the train stops (provided that the other conditions to start the test are met, see tsc-req-ievc-ibtm-app-test-
in-operation[req]).
Any of the 3 iBTM tests may also be launched upon request from the driver or the maintainer through the “in-
teractive test window” (see [SyAD-R72-SIF-Maintenance-Fault-UI]). In this case it is the LRU application that
provides the request to start the test.

438 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The iBTM test transmission is stopped by setting the Tele-powering mode to CW, TM, NT or Off. The iBTM
application interrupts any on-going test if the train starts moving unless the VM test mode is enabled.
This function also raises alarms related to the iBTM-TX health status or to the Tele-powering detection in ad-
dition to the alarms related to the iBTM tests. It provides them to function [IEVC.F3.02.07.11] Manage iBTM
alarms[function].

11.19.3.3 [IEVC.F3.02.07.11] Manage iBTM alarms [function]

Data
• Definition: This function collects the alarms raised in the iBTM application and forwards them to
the signalling application and to the LRU application. This function also implements the automatic
reset of an iBTM component in case of detected critical alarm as described in the 'Sensor recovery
strategy' section of this document.
• Allocated to:
– iBTM application[ci]
• Input:
– iBTM test alarm[functional variable]
– iBTM-TX status alarm[functional variable]
– Tele-powering detection error[functional variable]
– iBTM alarm - V1/V2 interface[functional variable]
– iBTM-RX status message[functional variable][VM - iBTM-RX interface]
– Balise contact alarm[functional variable]
• Output:
– iBTM Alarms[functional variable]
– iBTM reset orders (VM internal)[functional variable]
• Sil: 4

The iBTM application collects the following types of alarm:

• iBTM-TX status alarm: alarm raised when the status message indicates a board health issue or when no
status message has been received for more than iBTM status message timeout[functional variable];
• iBTM-TX high temperature alarm: alarm raised when the iBTM-TX temperature reported in
iBTM_TX_status_message is above Maximum iBTM-TX operating temperature[functional variable];
• iBTM-RX status alarm: alarm raised when the status message indicates a board health issue or when
no status message has been received from an iBTM-RX component for more than iBTM status message
timeout[functional variable];
• Tele-powering detection alarm: alarm raised when the content of iBTM_TX_status_message for the read-
back of the Tele-powering signal is not consistent with the commanded Tele-powering mode;
• iBTM test alarm: alarm raised due to a failed iBTM test;
• V1/V2 interface alarm: alarm raised when V1/V2 interface is used while not in test mode (this alarm is
computed by function [IEVC.F3.02.07.02] Pick-up Up-link magnetic field[function]);
• Balise contact alarm: alarm raised when building the balise contact
– iBTM-RX inconsistency alarm: alarm raised when a balise contact is reported by one of the
iBTM-RX boards but not by the other one or when the telegram content is different in each RX
(either one of the telegram is invalid only in one RX or both telegrams are valid but different).

11.19. iBTM application 439 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– Balise contact length warning: warning raised when the contact is detected as too long or too
short (according to the prescription from Subset-036 §5.2.2.5) in one or both of the completed
balise information from the 2 iBTM-RX.
– Balise contact too long: alarm raised when the length of an on-going balise contact exceeds a
defined threshold for any of the iBTM-RX
– Balise telegram warning: warning raised when both iBTM-RX detect no telegram or invalid
telegrams (according to the decoding requirements of Subset-036 §4.3) for a same balise infor-
mation.
– Balise overflow alarm: alarm raised when more than 8 balise information has to be reported to
the signalling application in a unique VM cycle.
iBTM alarms are formatted and transmitted to the signalling application and to the LRU application.
The iBTM automatic reset is triggered in case of iBTM-RX status alarm or iBTM-TX status alarm. The reset com-
mand uses the VM built-in variable iBTM reset orders (VM internal)[functional variable] (see Sensors recovery
strategy).

11.19.3.4 [IEVC.F3.03.03.02] Manage V1 and V2 interfaces [function]

Data
• Definition: This functions allows interfacing with the V1/V2 test messages provided by the associ-
ated V1/V2 test interface as specified in appendix E of Subset 085. This function is only enabled
when the VM test mode is enabled.
• Allocated to:
– iBTM application[ci]
• Input:
– Telegram information[functional variable]
– V2 - ODO data[functional variable][VM - Applications interface][VM - iODO BITE interface]
– V1 Mode Selection message[functional variable][VM - Applications interface][VM - iODO
BITE interface]
– Test mode enabled[functional variable]
• Output:
– iBTM alarm - V1/V2 interface[functional variable]
– Test V2 data[functional variable]
– V1 Mode Status message[functional variable][VM - Applications interface][VM - iODO BITE
interface]
– V1 Self-test Report message[functional variable][VM - Applications interface][VM - iODO
BITE interface]
– V1 Balise Passage Report message[functional variable][VM - Applications interface][VM -
iODO BITE interface]
– Test V1 mode[functional variable]
• Sil: basic
• Associated interface:
– VM - Applications interface[ci]

The iBTM application allows consuming the V1 mode selection commands and producing the V1 data reports
according to the format in appendix E of [SyAD-R77-SS85]. The iBTM application allows using the odometry

440 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

information from the V2 interface instead of the information from the Odometry Application in order to locate and
timestamp the balise information.
The use of the V1 interface is also extended to the Euroloop testing by a Subset 103 laboratory. When used for
that purpose, additional characters are added in some of the V1 messages as described in [SyAD-R51-SS103].
The V1 and V2 messages are described in [SyAD-R59-SIF-iODO-VM].

11.19.3.5 [IEVC.F3.02.15.02] Relay Euroloop Spread Spectrum Code [function]

Data
• Definition: This functions relays the Spread Spectrum Code received from the signalling application
to the iBTM-RX components. This code is required for the Euroloop demodulation. This code is
received from an End Of Loop Marker (EOLM) balise group that announces the Euroloop device.
• Allocated to:
– iBTM application[ci]
• Input:
– Spread Spectrum Code[functional variable]
• Output:
– Change of Spread Spectrum Code[functional variable][VM - iBTM-RX interface][VM - Ap-
plications interface]
• Associated interface:
– VM - Applications interface[ci]

11.19.4 Interface

• VM - Applications interface[ci]
This is the interface between the iBTM application and the iBTM driver included in the Vir-
tual Machine. The iBTM driver pushes all the messages exchanged with the iBTM-RX and
iBTM-TX, except the synchronization messages, on its interface with the iBTM application.
The following messages are exchanged:
From the iBTM driver to the iBTM application:
– Balise or loop detection message[functional variable][VM - iBTM-RX interface][VM - Ap-
plications interface]
– Up-link telegram message[functional variable][VM - iBTM-RX interface][VM - Applica-
tions interface]
– iBTM-TX status message[functional variable][VM - iBTM-TX interface][VM - Applications
interface]
– iBTM-RX status message[functional variable][VM - iBTM-RX interface]
From the iBTM application to the iBTM driver:
– Tele-powering setup message[functional variable][VM - iBTM-TX interface][VM - Appli-
cations interface]
– iBTM test message[functional variable][VM - iBTM-TX interface][VM - Applications inter-
face]
– Change of Spread Spectrum Code[functional variable][VM - iBTM-RX interface][VM - Ap-
plications interface]

11.19. iBTM application 441 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

All these messages are described in [SyAD-R56-SIF-iBTM-VM]. When exchanged be-

tween the iBTM driver an the iBTM application, these messages do not need to contain
header or signature information. These header and signature are required to secure the in-
formation exchanged between the VM and the components from the Sensor Box (refer to
[SyAD-R74-SIF-Sensor-interface]). However when transmitting the message to the iBTM appli-
cation, the iBTM driver shall make sure that the origin of the message is well identified; namely
the installed cabin of the Euroantenna or the identity of the iBTM-RX board: 1 or 2. The iBTM
driver shall also make available to the application the VM timestamp and the freshness informa-
tion in addition to the iBTM timestamp.
The iBTM application is interfaced with the iODO BITE driver to exchange the V1 and V2 test
data with a Subset 085 test lab. The content of some V1 messages can be extended for Subset
103 lab tests.
From the iBTM application to the iODO BITE driver:
– V1 Mode Status message[functional variable][VM - Applications interface][VM - iODO
BITE interface]
– V1 Self-test Report message[functional variable][VM - Applications interface][VM - iODO
BITE interface]
– V1 Balise Passage Report message[functional variable][VM - Applications interface][VM -
iODO BITE interface]
From the iODO BITE driver to the iBTM application:
– V2 - ODO data[functional variable][VM - Applications interface][VM - iODO BITE inter-
face]
– V1 Mode Selection message[functional variable][VM - Applications interface][VM - iODO
BITE interface]
All these messages are also exchanged between the iODO BITE driver and the
iODO BITE component which provides the physical interface. They are described in
[SyAD-R59-SIF-iODO-VM].
The iBTM application is interfaced with the Virtual Machine to collect the state of the VM test mode through the
variable Test mode enabled[functional variable].
The iBTM application is interfaced with several other applications inside the safe computer:
• interface with the ETCS messages application. This interface includes the exchange of the following mes-
sages:

Functional Variable
Telegram information [functional variable]

442 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide balise or loop telegram that can be decoded into packets and
associated application data
– Description: Collection of Eurobalise, Euroloop or KER telegram information. The
telegram user data is provided with its type (Eurobalise, Euroloop or KER), the balise
center location with its associated reference id. For an Euroloop telegram the location
is not provided (the corresponding location structure is left empty). For Eurobalise
and Euroloop telegrams, any detected decoding error is reported as well. 'NoError' is
always reported for KER telegrams as no decoding check is performed in the iBTM
application.
– Family: Software
– Type: telegram_info
– Timing constraints: Event
– Produced by:

* [IEVC.F3.02.07.09] Verify, filter and decode Eurobalise and Euroloop tele-

gram[function]
– Consumed by:

* [IEVC.F3.03.03.02] Manage V1 and V2 interfaces[function]

* [IEVC.F3.02.08.08.02] Decode balise and loop telegrams[function]
* [IEVC.F3.02.08.08] Decode and encode ETCS telegrams or messages[function]

<TelegramUserData> ::= byte* ; bitarray of maximum size 830 bits

<TelegramUserDataLMessage> ::= int32 ; length in byte of the useful
˓→information inside the user data

; Value 0 indicates an empty

˓→telegram.

<TelegramType> ::= Eurobalise

| Euroloop
| KER
<LocationBaliseCenter> ::= real; center of balise location
<ContactLength> ::= real; distance between OFF_TO_ON and ON_TO_OFF
˓→balise detection message

<UnderReadingAmount> ::= real ; under reading amount of the estimated

˓→position

<OverReadingAmount> ::= real; over reading amount of the estimated

˓→position

<OdoInfoSigmaPosition> ::= real; Error on the positioning retrieved by

˓→the odometry at the time the telegram is received

<BaliseLocationInfo> ::= <LocationBaliseCenter> <ContactLength>

˓→<UnderReadingAmount> <OverReadingAmount> <OdoInfoSigmaPosition>

<BalisePassageTimestamp> ; timestamp corresponding to the passage of

˓→the balise center.

<TelegramDecodingError> ::= "NoError" ; no decoding error

| "StartBitError" ; STEP 3 decoding error
˓→according to Subset-036 coding rules

| "WordTranslationError" ; STEP 5 decoding

˓→error according to Subset-036 coding rules

| "ControlBitError" ; STEP 7 or 8 decoding

˓→error according to Subset-036 coding rules

| "TelegramSizeError"; size of the input

˓→message is different from 341 or 1023

11.19. iBTM application 443 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

<TelegramUserData> <TelegramUserDataLMessage> <BaliseLocationInfo>

˓→<BalisePassageTimestamp> <TelegramDecodingError>

[<TelegramInfoStruct>] ; collection of 8 balise information

• interface with the Subset 026 Application. This interface includes the exchange of the following messages:

Functional Variable
iBTM Alarms [functional variable]
Data
– Objective: To provide iBTM components failure information to the signalling appli-
cation and to the LRU application.
– Description: Collection of structure that contains iBTM alarm information.
– Family: Software
– Type: ibtm_alarms
– Produced by:

* [IEVC.F3.02.07.11] Manage iBTM alarms[function]

– Consumed by:

* [IEVC.F4.08.01] Determine LRU faults[function]

* [IEVC.F3.02.07.12] Manage ETCS telegram[function]

Collection of maximum 64 detected faults. Each fault has the structure of LRUFaultSta-
tus[functional variable]
The faults are those listed in the iBTM fault map.
Contextual data provides more detailed information on the alarm when available.

Functional Variable
Active Euroantenna [functional variable]
Data
– Objective: To provide the information about the number of Euroantenna installed on-
board, which Euroantenna must be active and what Tele-powering mode to use.
– Description: message that contains the number of Euroantenna installed on-board, the
current active Euroantenna, the Tele-powering mode to use and the distance between
the Euroantenna.
– Family: Software
– Type: active_euroantenna
– Produced by:

* [IEVC.F3.02.07.12] Manage ETCS telegram[function]

– Consumed by:

* [IEVC.F3.02.07.10] Manage Tele-powering mode[function]

* [IEVC.F3.02.03.10] Estimate train odometry (EKF)[function]

444 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

<NumAntennaOnboard> ::= 1 | 2 ; Number of antenna on board

<CurrentActiveAntenna> ::= NoActiveEuroantenna ; Tele-powering must be

˓→disabled on all Euroantenna installed on-board

| UseAntennaCabA ; Use Euroantenna installed

˓→in Cab A

| UseAntennaCabB ; Use Euroantenna installed

˓→in Cab B

<TelePoweringModeCommand> ::= ContinuousWave

| TogglingMode
| NonTogglingMode
| Off

<AntennaDistance> ::= real ; distance between Cab A and Cab B

˓→Euroantenna in m (0 when only 1 antenna)

<NumAntennaOnboard> <CurrentActiveAntenna> <TelePoweringModeCommand>

˓→<AntennaDistance>

When there is only 1 Euroantenna, the value ‘UseAntennaCabB’ is not used. The distance between
the 2 Euroantenna is not used by the iBTM application.

Functional Variable
Spread Spectrum Code [functional variable]
Data
– Objective: To specify the code required to demodulate the signal from a specific
Euroloop installation
– Description: this message contains the Spread Spectrum Code to use (value 0 to 15)
– Family: Software
– Type: spread_spectrum_code
– Produced by:

* [IEVC.F3.02.07.12] Manage ETCS telegram[function]

– Consumed by:

* [IEVC.F3.02.15.02] Relay Euroloop Spread Spectrum Code[function]

The message contains the variable ‘Q_SSCODE’ described in §7 of Subset 026

([SyAD-R8-SS026]); this variables has integer values from 0 to 15 (See also [SyAD-R50-SS44] for
more information about this code and the associated demodulation method).

• interface with the Odometry Application This interface includes the exchange of the following messages:
Odometry information message[functional variable]
• interface with the LRU application This interface includes the exchange of iBTM Alarms[functional vari-
able] and of the following messages:

11.19. iBTM application 445 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
iBTM test request [functional variable]
Data
– Objective: To inform the iBTM application that an interactive test command entered
by the maintainer on the DMI when executing an interactive test session.
– Description: message containing the iBTM test request and the type of iBTM test
between Eurobalise, KER and Euroloop.
– Family: Software
– Type: ibtm_test_request
– Timing constraints: Event
– Produced by:

* [IEVC.F4.11.01] Manage interactive test sessions[function]

– Consumed by:

* [IEVC.F3.02.07.10] Manage Tele-powering mode[function]

The structure of the message shall be consistent with the definition of message LRU Interactive Test
Input[functional variable][VM - OBOM interface] defined in [SyAD-R62-SIF-OBOM-VM].

Functional Variable
iBTM test report [functional variable]
Data
– Objective: To provide updated interactive testing data to display
– Description: message containing iBTM test result and a list of textual action to exe-
cute.
– Family: Software
– Type: iBTM_test_report
– Timing constraints: Event
– Produced by:

* [IEVC.F3.02.07.10] Manage Tele-powering mode[function]

– Consumed by:

* [IEVC.F4.11.01] Manage interactive test sessions[function]

The structure of the message shall be consistent with the definition of message LRU Interactive Test
Report[functional variable][VM - OBOM interface] defined in [SyAD-R62-SIF-OBOM-VM].

• The following logical messages are used internally to the iBTM application component:

Functional Variable
Test V2 data [functional variable]

446 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide odometry information coming from the V1/V2 in-
terface used for subset 085 tests
– Description: This message contains time and odometer information to be
used by the iBTM application during testing. The content of the message
is described in E2.2 of Subset 085.
– Family: Software
– Produced by:

* [IEVC.F3.03.03.02] Manage V1 and V2 interfaces[function]

– Consumed by:

* [IEVC.F3.02.07.09] Verify, filter and decode Eurobalise and Eu-

roloop telegram[function]

Functional Variable
Test V1 mode [functional variable]
Data
– Objective: To provide a command to switch the Tele-powering to a specific
mode
– Description: This message contains the Tele-powering mode to be selected
by the iBTM application among 'Test mode' (iBTM test), CW, TM or Off.
The content of the message is described in E1.2.2 of Subset-085. When
used to test Euroloop it also includes the Spread Spectrum Code to be used
for the signal demodulation. The extra characters to include in the message
are described in G.3.2 of Subset 103.
– Family: Software
– Produced by:

* [IEVC.F3.03.03.02] Manage V1 and V2 interfaces[function]

– Consumed by:

* [IEVC.F3.02.07.10] Manage Tele-powering mode[function]

Functional Variable
Tele-powering detection error [functional variable]

11.19. iBTM application 447 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To inform about a detected inconsistency in the Tele-powering
detection information coming from iBTM-TX.
– Description: This message contains an alarm flag
– Family: Software
– Produced by:

* [IEVC.F3.02.07.10] Manage Tele-powering mode[function]

– Consumed by:

* [IEVC.F3.02.07.11] Manage iBTM alarms[function]

Functional Variable
iBTM test alarm [functional variable]
Data
– Objective: To inform about a failed iBTM test.
– Description: This message contains an alarm flag
– Family: Software
– Produced by:

* [IEVC.F3.02.07.10] Manage Tele-powering mode[function]

– Consumed by:

* [IEVC.F3.02.07.11] Manage iBTM alarms[function]

Functional Variable
iBTM-TX status alarm [functional variable]
Data
– Objective: To inform when the a detected failure of the iBTM-TX board.
The failure may be reported in the status message. It may also be due to a
lack of status message or to a reported temperature higher than a maximum
operating temperature.
– Description: This message contains alarm flags
– Family: Software
– Produced by:

* [IEVC.F3.02.07.10] Manage Tele-powering mode[function]

– Consumed by:

* [IEVC.F3.02.07.11] Manage iBTM alarms[function]

Functional Variable
iBTM alarm - V1/V2 interface [functional variable]

448 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To inform when an inconsistency is detected in the use of the
V1/V2 interface.
– Description: This message contains an alarm flag
– Family: Software
– Produced by:

* [IEVC.F3.03.03.02] Manage V1 and V2 interfaces[function]

– Consumed by:

* [IEVC.F3.02.07.11] Manage iBTM alarms[function]

This alarm is raised when receiving V1 or V2 test data while the test mode of the iEVC
On-board subsystem has not been enabled

Functional Variable
Balise contact alarm [functional variable]
Data
– Objective: To inform about warnings or alarms detected when constructing
balise or loop information based on the detection and telegram messages.
– Description: This message contains alarm flags
– Family: Software
– Produced by:

* [IEVC.F3.02.07.09] Verify, filter and decode Eurobalise and Eu-

roloop telegram[function]
– Consumed by:

* [IEVC.F3.02.07.11] Manage iBTM alarms[function]

refer to the description of [IEVC.F3.02.07.11] Manage iBTM alarms[function]

11.19.5 Parameters

Functional Variable
Eurobalise iBTM test restart delay [functional variable]

11.19. iBTM application 449 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To fix a limit to launch a new Eurobalise iBTM test during operation
• Description: this variable fixes a minimum time without reading any balise to decide to
start a new Eurobalise iBTM test. The iBTM application maintains an internal timer that
is reset when a balise is correctly read or when an iBTM test is performed successfully.
When this timer becomes greater than the 'Eurobalise iBTM test restart delay' then the iBTM
application will start a new iBTM test as soon the conditions to start the test are met.
• Family: Software
• Type: iBTMTestReplayDelay
• Unit: s
• Protocol: System Parameter
• Minimum: 0
• Maximum: 100000

Functional Variable
iBTM test monitoring delay [functional variable]
Data
• Objective: To fix a maximum delay in the test sequence
• Description: this delay fixes the maximum delay after the start of the transmission to collect
correct telegram from the 2 RX channels.
• Family: Software
• Type: iBTMTestMonitoringDelay
• Unit: ms
• Protocol: System Parameter
• Minimum: 0
• Maximum: 10000

Functional Variable
Maximum iBTM-TX operating temperature [functional variable]

450 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To limit the maximum temperature of the component and to avoid permanent
damage
• Description: this variable fixes the temperature limit in °C above which the iBTM-TX
should not operate.
• Family: Software
• Type: iBTMTXMaxTemperature
• Unit: °C
• Protocol: System Parameter
• Minimum: 0
• Maximum: 1000

Functional Variable
balise contact minimum length [functional variable]
Data
• Objective: To fix an inferior limit for a balise contact
• Description: Minimum balise contact length under which the contact is considered as not
being a normal balise contact.
• Family: Software
• Type: BaliseContactMinLength
• Unit: cm
• Protocol: System Parameter
• Minimum: 0
• Maximum: 260

Its value shall consider the minimum balise contact length of 30cm according to Subset 036 section 5.2.2.5
Fig. 13.

Functional Variable
balise contact maximum length [functional variable]

11.19. iBTM application 451 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To fix a superior limit for a balise contact
• Description: Maximum balise contact length over which the contact is considered as not
being a normal balise contact
• Family: Software
• Type: BaliseContactMaxLength
• Unit: cm
• Protocol: System Parameter
• Minimum: 0
• Maximum: 260

Its value shall consider the maximum balise contact length of 70cm according to Subset 036 section 5.2.2.5
Fig. 13.

Functional Variable
Side lobe filtering distance [functional variable]
Data
• Objective: To fix a filtering distance to detect side lobe contacts
• Description: maximum distance between an 'On to Off' transition and an 'Off to On' transi-
tion to decide that the 2 contacts are from a same balise.
• Family: Software
• Type: SideLobeFilteringDistance
• Unit: cm
• Protocol: System Parameter
• Minimum: 0
• Maximum: 95

Functional Variable
RX comparison filtering distance [functional variable]

452 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To fix a specific distance window during which a completed balise contact is-
sued from the processing of the data coming from one iBTM-RX has to be matched by an
equivalent completed balise contact based on the information of the second iBTM-RX.
• Description: distance value
• Family: Software
• Type: RXComparisonWindow
• Unit: cm
• Protocol: System Parameter
• Minimum: 0
• Maximum: 260

This distance has to be strictly higher than the Side lobe filtering distance[functional variable].

Functional Variable
Maximum center distance for matching balise information [functional variable]
Data
• Objective: To fix a criteria to decide that 2 completed balise information coming different
iBTM-RX have their balise center close enough to consider that they match.
• Description: distance value
• Family: Software
• Type: RXCenterMatchingWindow
• Unit: cm
• Protocol: System Parameter
• Minimum: 0
• Maximum: 260

When the 2 balise information have center positions that are closer than this value, it is considered that
they match.

Functional Variable
Maximum ageing of iBTM-RX messages [functional variable]

11.19. iBTM application 453 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To limit the age of the iBTM-RX messages to process based on the odometry
information buffer
• Description: maximum age of the message to be able to position it based on the odometry
information
• Family: Software
• Type: iBTMRXMaximumAge
• Unit: ms
• Protocol: System Parameter
• Minimum: 0
• Maximum: 10000

Functional Variable
iBTM status message timeout [functional variable]
Data
• Objective: To monitor that the iBTM component is alive
• Description: maximum delay without iBTM status message received by the iBTM applica-
tion
• Family: Software
• Type: iBTMStatusTimeout
• Unit: ms
• Protocol: System Parameter
• Minimum: 0
• Maximum: 10000

Functional Variable
iBTM status message start-up timeout [functional variable]
Data
• Objective: To monitor that the iBTM component is alive at start-up
• Description: maximum delay after the first VM cycle without having received an iBTM
status message
• Family: Software
• Type: iBTMStatusStartupTimeout
• Unit: ms
• Protocol: System Parameter
• Minimum: 0
• Maximum: 10000

454 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
Maximum Tel-powering level [functional variable]
Data
• Objective: To fix a superior limit for the readback of the Tele-powering level
• Description: dB loss with reference to the nominal emission level
• Family: Software
• Type: iBTMMaxTPLevel
• Unit: dB
• Protocol: System Parameter
• Minimum: 0
• Maximum: 1000

Its value depends on the design of the Tele-powering transmission chain. It shall correspond to a maximum
flux from the antenna 𝜑𝑑4 +10 dB according to Subset 036 §6.4.5.2.

Functional Variable
Minimum Tel-powering level [functional variable]
Data
• Objective: To fix an inferior limit for the readback of the Tele-powering level
• Description: dB loss with reference to the nominal emission level
• Family: Software
• Type: iBTMMinTPLevel
• Unit: dB
• Protocol: System Parameter
• Minimum: 0
• Maximum: 1000

Its value depends on the design of the Tele-powering transmission chain. It shall correspond to a maximum
flux from the antenna 𝜑𝑑1 according to Subset 036 §5.2.2.6.

Functional Variable
Reverse movement detection distance [functional variable]

11.19. iBTM application 455 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To fix a criteria to detect a reverse movement based on the odometry information.
When the odometry position show that the train has traveled that distance in the direction
opposite to the current one, then the iBTM application detects a reverse movement and clears
the stored balise information.
• Description: distance value
• Family: Software
• Type: ReverseMovementDetectionDistance
• Unit: cm
• Protocol: System Parameter
• Minimum: 0
• Maximum: 260

Functional Variable
Balise contact alarm distance [functional variable]
Data
• Objective: To fix a limit for an on-going balise contact after which an alarm has to be raised
by the iBTM application.
• Description: a maximum contact distance
• Family: Software
• Type: BaliseContactAlarmDistance
• Unit: cm
• Protocol: System Parameter
• Minimum: 0
• Maximum: 1000

11.19.6 Requirements

11.19.6.1 Euroantenna activation

Requirement

The iBTM application shall disable (set to ‘off’) the Tele-powering of an inactive Euroantenna.
[id:tsc-req-ievc-ibtm-app-2-euroantenna][p1][s]

The activation information is provided by the signalling application through the functional variable Active
Euroantenna[functional variable].
The messages from the iBTM components (iBTM-TX and iBTM-RX) contain the ‘associated installed
cabin’ information (see iBTM - Virtual Machine Interface Specification).
When there are 2 Euroantenna (one per cabin or desk), the iBTM application shall only process the detec-
tion and telegram messages from the iBTM components associated to the active Euroantenna.

456 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

When there is only one Euroantenna installed on-board the iBTM application shall process all the mes-
sages from the iBTM components.

Note: By default both Euroantenna are inactive at start-up while the variable Active Euroan-
tenna[functional variable] is not provided.

Requirement

The iBTM application shall command the Tele-powering mode of the iBTM-TX component to one
of the following modes ‘Continuous Wave’ (CW), ‘Toggling Mode’ (TM), ‘Non Toggling’ (NT) or
‘Off’. [id:tsc-req-ievc-ibtm-app-tp-mode-command][p1][ns]

Requirement

The Tele-powering mode used by the iBTM application to command the iBTM-TX component shall
be provided by the signalling application. [id:tsc-req-ievc-ibtm-app-tp-mode-active-euroantenna][p1][ns]

The information is provided through the variable Active Euroantenna[functional variable].

11.19.6.2 Processing of balise and loop information

Requirement

For each of the iBTM-RX, the iBTM application shall reconstruct a balise contact by associating
pairs of ‘Off to On’ and ‘On to Off’ transitions. [id:tsc-req-ievc-ibtm-app-balise-contact][p1][s]

This requirement is applicable for Eurobalise and KER.

Requirement

For each of the iBTM-RX and for each balise contact, the iBTM application shall try associating a
telegram information based on the telegram messages received. [id:tsc-req-ievc-ibtm-app-balise-contact-
telegram][p1][s]

The telegram information may be missing. It may also be invalid according to the coding requirements of
Subset-036 §4.3. In that case the information (invalid telegram and coding error) shall be recorded in the
balise contact.
This requirement is applicable for Eurobalise and KER.

Requirement

When reconstructing balise contact information, the iBTM application shall be robust to the loss of
one message from the the iBTM-RX. [id:tsc-req-ievc-ibtm-app-ss36-ibtm-lost-message][p1][ns]

The loss of one message is allowed for one iBTM-RX board and as long as the iBTM application is able
to reconstruct correctly a balise contact information for each of the iBTM-RX.
When an ‘Off to On’ message has been lost, the iBTM application shall retrieve the associated lost infor-
mation from the list of past transitions included in the next ‘On to Off’ message. The transition id shall be
used to identify that lost information.
The loss of a telegram message is compensated by the repetition of the message in the interface (refer to

11.19. iBTM application 457 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

tsc-req-ievc-ibtm-rx-tgm-reporting-next-messages[req]).
This requirement is applicable for Eurobalise and KER.

Note: For Eurobalise telegram information consistency, different raw telegram are possible while the
decoded (unscrambled) telegram is identical.

Requirement

When associating telegrams to balise contacts the iBTM application shall use the telegram infor-
mation coming from different demodulators for each iBTM-RX. [id:tsc-req-ievc-ibtm-app-balise-contact-
telegram-demodulator][p1][s]

For example, demodulator A for iBTM-RX 1 and demodulator B for iBTM-RX 2.

This requirement is applicable for Eurobalise and KER.

Requirement

When several telegrams are provided by the iBTM-RX components in association with a same balise
contact, the iBTM application record the latest valid telegram information received and use that
information when making the balise information available to the signalling application. [id:tsc-req-
ievc-ibtm-app-ss36-switched-telegram][p1][ns]

This requirement is applicable for Eurobalise and KER.

For Eurobalise, an invalid telegram (according to the coding requirements of Subset-036 §4.3) shall not
replace a previously received valid telegram.
For KER balises, no assumption can be made on the validity of the telegram coding as it is application
dependent (Class B dependent). Therefore the last telegram received is recorded.

Note: If the telegram switches in a side lobe following the main lobe it will not be reported as only the
main lobe information is reported. It is considered that the switch of content happened too late.

Requirement

For each of the iBTM-RX and for each balise contact, the iBTM application shall compute the balise
center position and contact length using the ‘Off to On’ and ‘On to Off’ transition timestamps.
The iBTM application shall associate position to timestamps values using the odometry information
provided by the Odometry application. [id:tsc-req-ievc-ibtm-app-ss36-telegram-location][p1][s]

Note: During subset 085 lab test the source of odometry information is the V2 message provided through
the V1/V2 interface.

Requirement

The iBTM application shall take into account the detection message estimated freshness for each
transition to define the error related to the balise contact center position. [id:tsc-req-ievc-ibtm-app-
ss36-error][p1][s]

458 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The estimated freshness is provided by the iBTM driver by applying the principles described in Sensor In-
terface Common Protocol Specification. The resulting error shall be included in the information provided
to the signalling application.
The balise contact length shall be an average value between the min and max values taking into account
the estimated age of the detection messages containing the ‘Off to On’ and ‘On to Off’ transitions.
The details of the implementation are provided in the application design specification document.
This requirement is applicable for Eurobalise and KER.

Requirement

For each of the iBTM-RX, the iBTM application shall consider a balise contact as ‘completed’ (1)
when a filtering distance has been passed since the end of the contact with no new balise contact
detected, or (2) when a new balise contact is detected but this contact is associated to a different
valid telegram (assuming the first contact is also associated to a valid telegram). [id:tsc-req-ievc-ibtm-
app-ss36-eurobalise-side-lobes-detection][p1][s]

This criteria is used to decide if several balise contacts have to be considered as lobes coming from a same
balise.
A completed balise information may therefore contain from 1 to 3 balise contacts.
When valid telegrams are received on 2 consecutive balise contacts and when these telegrams show that
the information is coming from different balises, these contacts shall be managed as 2 different completed
balises. When the discrimination cannot be based on the telegram content (either no valid telegram has
been received in one contact or the same information has been received) then side lobes shall be detected
whenever the balise contacts are too close from each other to be coming from separate balises.
The filtering delay is set through the value of Side lobe filtering distance[functional variable].

Note: The value for ‘Side lobe filtering distance’ has to be selected between 0 and 95 cm. These values
are derived from:
• the main lobe contact volume as described in Figure 13 of subset 036 which refers a the maximum
contact length of 70 cm;
• the minimum distance between 2 consecutive balises of 2.3m center to center according to §5.6.3 of
subset 036 (worst case is 2.3m for reduced size balises).

11.19. iBTM application 459 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.55: Representation of worst case balise positioning for side lobe detection

When comparing the telegram information between 2 successive balise contacts the last valid telegram of
the first contact is compared to the first valid telegram of the second contact.

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

This condition includes the case in which the telegram is valid on one side and empty or invalid on the
other side.
The balise information is not reported to the signalling application.
This requirement is applicable for Eurobalise and KER.
For Eurobalise, an invalid telegram is a telegram with errors related to the coding requirements of Subset-
036 §4.3.
For KER balises, no assumption can be made on the validity of the telegram coding as it is application
dependent (Class B dependent). Therefore the alarm is raised if the telegram are non-empty and different
or if one of the telegram information is empty and the other not.

Requirement

The iBTM application shall raise a warning if the two matching completed balise information from
the 2 iBTM-RX have empty or invalid telegrams. [id:tsc-req-ievc-ibtm-app-ss36-no-telegram][p1][ns]

The balise information is reported to the signalling application even when this warning is raised.
This requirement is applicable for Eurobalise and KER.
For Eurobalise, an invalid telegram is a telegram with errors related to the coding requirements of Subset-
036 §4.3.
For KER balises, no assumption can be made on the validity of the telegram coding as it is application
dependent (Class B dependent). Therefore the warning is raised if the both telegrams are empty.

Requirement

When two matching completed balise information from the 2 iBTM-RX have empty or invalid tele-
grams, the iBTM application shall report the balise information to the signalling information with-
out Telegram data and indicating that either no (valid) telegram has been received. [id:tsc-req-ievc-
ibtm-app-ss36-no-telegram-report][p1][s]

An empty or invalid telegram is reported in Telegram information[functional variable] using a bitarray

filled with ‘0’ (‘TelegramUserData’) and a telegram length of 0 (‘TelegramUserDataLMessage’).
For Eurobalise, an invalid telegram is a telegram with errors related to the coding requirements of Subset-
036 §4.3.
This requirement is applicable for Eurobalise and KER.
For KER balises, no assumption can be made on the validity of the telegram coding as it is application
dependent (Class B dependent). Therefore the warning is raised if the both telegrams are empty.

Requirement

The iBTM application shall raise a warning when one or both of the two matching completed balise
information from the 2 iBTM-RX have a contact length below a minimum threshold or above a
maximum threshold. [id:tsc-req-ievc-ibtm-app-contact-length][p1][ns]

These thresholds are:

• balise contact minimum length[functional variable] (30cm according to Subset 036 section 5.2.2.5
Fig. 13)
• balise contact maximum length[functional variable] (70cm according to Subset 036 section 5.2.2.5
Fig. 13, but a larger value may be considered, at least 1m should be accepted)

462 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

This detection shall take place after verifying the telegram content consistency between the 2 iBTM-RX.
The balise information is reported to the signalling application even when a warning is raised.
This requirement is applicable for Eurobalise and KER.

Requirement

After two matching completed balise information have been identified from the 2 iBTM-RX, and if
no alarm has been raised due to their telegram content, the iBTM application shall report to the sig-
nalling application (1) the balise information that has a contact length within the defined minimum
and maximum thresholds, or (2) the balise information with the lowest error on its center posi-
tion (if both contact length are within the defined thresholds). [id:tsc-req-ievc-ibtm-app-ss36-telegram-
report][p1][s]

If the selection is based on the lowest center position error and if both RX information have the same error
value, then the information from iBTM-RX 1 shall be selected.
This requirement is applicable for Eurobalise and KER.

Requirement

The iBTM application shall report the balise and loop information regardless of the direction of
travel of the vehicle. [id:tsc-req-ievc-ibtm-app-ss36-telegram-reporting-direction][p1][ns]

Requirement

The iBTM application shall clear any balise information under processing once a reverse movement
is detected [id:tsc-req-ievc-ibtm-app-reverse-movement][p1][ns]

Any on-going balise contact shall be cleared; that includes any subsequent telegram information or detec-
tion message related to that same transition id.
Any completed balise information that is not yet reported to the signalling application shall be cleared.
The odometry information buffer is reset as well.

Note: Asynchronism between the 2 iBTM-RX may cause in very specific cases that a reset happens while
a contact is initiated in one iBTM-RX but not yet in the other. As a consequence alarms for iBTM-RX
inconsistency will be raised and cause a safe reaction. The associated degradation in system availability is
assumed acceptable considering that this event is very unlikely.

Requirement

The iBTM application shall consider that a reverse movement has been initiated when the odome-
try information show that the train has traveled a defined distance in the direction opposite to the
current direction of travel. [id:tsc-req-ievc-ibtm-app-reverse-movement-detection][p1][ns]

The distance value is set by Reverse movement detection distance[functional variable].

Requirement

When 2 Euroantenna are used (one per cabin or desk), the iBTM application shall clear any balise
information under processing each time the active Euroantenna is changed. [id:tsc-req-ievc-ibtm-app-
change-euroantenna][p1][ns]

11.19. iBTM application 463 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Any on-going balise contact shall be cleared.

Any completed balise information that is not yet reported to the signalling application shall be cleared.
The odometry information buffer is reset as well.

Requirement

The iBTM application shall make available to the signalling application the balise information in
such a way that the order, in which data was received, can be reconstructed. [id:tsc-req-ievc-ibtm-app-
ss36-telegram-reporting-order][p1][s]

In other words, the balise information shall be provided in a ordered way.

Requirement

When decoding an Eurobalise or Euroloop telegram, the 1024 words in the list provided in annex
B2 of Subset 036 shall be considered as ‘valid’. All other 11-bit words shall be ‘invalid’. [id:tsc-req-
ievc-ibtm-app-ss36-eurobalise-decoding-11bit-words][p1][s]

Requirement

The iBTM application shall decode an Eurobalise or Euroloop telegram according to the coding
requirements of Subset 036 §4.3 [id:tsc-req-ievc-ibtm-app-ss36-eurobalise-decoding][p1][s]

Requirement

The iBTM application shall maintain a buffer of the timestamped odometry information in order to
be able to reconstruct the balise position as a minimum up to the last 15 m traveled. [id:tsc-req-ievc-
ibtm-app-ss36-odo-buffer][p1][ns]

The buffer shall allow providing a positioning accuracy of at least 20cm for a given timestamped event.
A maximum ageing of the iBTM-RX messages shall result from the dimensioning of this buffer. When
receiving a message older than the maximum ageing delay, the message shall be rejected.

Requirement

The iBTM application shall reject the messages with an estimated freshness above a defined thresh-
old. [id:tsc-req-ievc-ibtm-app-ss36-odo-freshness][p1][s]

The value of the freshness threshold is set through Maximum ageing of iBTM-RX messages[functional
variable]. The value of this parameter is set in the application detailed design.

Requirement

The time delay between the end of transmission of the current balise (that is 1.3 m after the centre
point of the current Balise) in a cluster of balises, and the availability of data for signalling appli-
cation (location reference information and the data from this current Balise) shall be less than Tn
where Tn is defined in Subset 036 §4.2.9. [id:tsc-req-ievc-ibtm-app-msg-reporting-perf][p1][ns]

464 of 750 11.19. iBTM application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The iBTM application shall be able to process at least 8 balises within a time frame of 0.8s. [id:tsc-
req-ievc-ibtm-app-ss40-4-1-1-6-balise-processing-perf][p1][ns]

The iBTM application shall report the first 8 balises to the signalling application.

Requirement

The iBTM application shall raise an alarm when the quantity of balise information to report to the
signalling application exceeds 8 during a same VM cycle. [id:tsc-req-ievc-ibtm-app-ss40-4-1-1-6-balise-
processing-perf-alarm][p1][ns]

The iBTM Fault ID alarm is balise overflow alarm.

Requirement

The iBTM application shall report the decoded Euroloop information to the signalling application
(through the ETCS messages application) as soon as the last valid decoded telegram is identical be-
tween the two iBTM-RX. During a same loop contact, it shall report again the decoded information
from the Euroloop only when the content of the telegram changes consistently for both iBTM-RX.
[id:tsc-req-ievc-ibtm-app-euroloop-telegram-report][p1][ns]

No reporting is done if the 2 telegrams are different or if one of them is empty or invalid against the coding
requirements of Subset-036 §4.3.
No reporting is done during an on-going iBTM test.

11.19.6.3 iBTM test

Requirement

When the VM test mode is disabled, the iBTM application shall automatically start an Eurobalise
and a KER IBTM test at start-up. [id:tsc-req-ievc-ibtm-app-test-at-start-up][p1][s]

When there is one Euroantenna per cabin or desk, 2 Sensor box with their own Euroantenna are connected
to the Safe computer. An Eurobalise and a KER iBTM test shall be performed on both units even if only
one Euroantenna is active (based on ‘Active Euroantenna’).
There is no automatic iBTM test at startup for Euroloop.
The iBTM application shall report the result to the LRU application upon test completion.

Note: The execution of automatic iBTM test is conditioned to the VM test mode to allow using the test
loop during lab test without interference from the actual iBTM test.

Requirement

The iBTM application shall start an Eurobalise, Euroloop or KER iBTM test upon request from the
LRU application. It shall report the result to the LRU application upon test completion. [id:tsc-req-
ievc-ibtm-app-test-lru-app][p1][s]

The LRU application may request an iBTM test during an interactive test session.

11.19. iBTM application 465 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The required conditions to start an iBTM test still apply.

The iBTM test is requested through the variable iBTM test request[functional variable]. One request
corresponds to one type of test only (Eurobalise, KER or Euroloop). The result is reported through iBTM
test report[functional variable].
This test is not conditioned on the VM test mode.

Requirement

When the VM test mode is disabled, the iBTM application shall automatically start an Eurobalise
and KER iBTM test (i) when the train is stopped and (ii) when no balise/loop signal is currently being
read and (iii) when no balise has been correctly read by the active Euroantenna for a configured time
and (iv) when no iBTM test has been successfully performed for the same configured time. [id:tsc-
req-ievc-ibtm-app-test-in-operation][p1][s]

The configured time is Eurobalise iBTM test restart delay[functional variable]. If the train is stopped over
a balise or loop (a balise/loop contact is currently on-going in one of the iBTM-RX and Up-link telegrams
are being received) the test cannot be started.
When there is one Euroantenna per cabin or desk, the iBTM test shall be performed on both units even if
only one Euroantenna is currently active (based on ‘Active Euroantenna’).
The iBTM application shall report the result to the LRU application upon test completion.

Note: the Euroloop iBTM test is not triggered automatically. It has to be launched on driver/maintainer
request.

Note: The execution of automatic iBTM test is conditioned to the VM test mode to allow using the test
loop during lab test without interference from the actual iBTM test.

Requirement

The iBTM application shall stop any on-going iBTM test as soon as a train movement is detected
unless the Virtual Machine test mode is enabled. [id:tsc-req-ievc-ibtm-app-test-stop-when-moving][p1][s]

The iBTM application shall raise an iBTM alarm to the signalling application and turn off the Tele-
powering when the temperature reported by the iBTM-TX is higher than a maximum operating
temperature provided by the manufacturer. [id:tsc-req-ievc-ibtm-app-ss36-ibtm-tx-temp-error][p1][s]

The request to turn off the Tele-powering takes precedence on the mode ordered by the signalling appli-
cation in Tele-powering setup message[functional variable][VM - iBTM-TX interface][VM - Applications
interface].

Requirement

The iBTM application shall raise an iBTM alarm to the signalling application when an iBTM test
has failed. [id:tsc-req-ievc-ibtm-app-ss36-ibtm-test-failed][p1][s]

The iBTM test transmission is triggered by the ‘iBTM test message’. The test is ended by the transmission
of a ‘iBTM Tele-powering setup message’. The test is considered as failed when correct detection and
demodulation of the telegram message has not been received by the 2 RX channels and a configurable
delay (‘iBTM test monitoring delay’) has expired after the start of the test transmission.
The test is successful when both iBTM-RX boards have reported an ‘Off to On’ transition and when all
the demodulators of each board have reported the expected demodulated telegram.
This is applicable for all the types of iBTM test (Eurobalise, KER and Euroloop).

11.19. iBTM application 467 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The iBTM application shall raise an iBTM alarm to the signalling application when no status mes-
sage has been received from one of the iBTM components (iBTM-RX or iBTM-TX) for more than a
configurable delay or when the status message indicates a failure of the board. [id:tsc-req-ievc-ibtm-
app-ss36-ibtm-status-timeout][p1][s]

The configurable delay is iBTM status message timeout[functional variable].

For this monitoring, the iBTM application shall consider the difference between the Virtual Machine
timestamp of the current cycle and the reception timestamp of the last status message.
At start-up, a specific delay shall be used: iBTM status message start-up timeout[functional variable]. The
iBTM application shall raise the alarm if no status message has been received and if this delay has expired
counting from the Virtual Machine timestamp of the first cycle.
The requirement applies to all iBTM components including those of the second sensor box, when two
2 Euroantenna need to be installed on-board (one for each cab or desk). It also applies whatever the
activation status of the Euroantenna. However the alarm shall be critical only for the iBTM components
of the active Euroantenna.

Requirement

The iBTM application shall raise an iBTM alarm when receiving V1 or V2 test data while the VM
test mode is not enabled. [id:tsc-req-ievc-ibtm-app-v1v2-alarm-test-mode][p1][s]

This iBTM alarm is raised to mitigate the risk of using V1 or V2 test information while the train is actually
running.

Requirement

11.20 iBTM driver

Important: This component is included in the iEVC Basic kit[ci]

11.20.1 Description

The iBTM driver allows to synchronize the communication between the iBTM components in the Sensor box
hardware and the iBTM application in the Safe computer.
The iBTM driver of the VM sends a synchronization message at every evaluation cycle to each iBTM-TX and
iBTM-RX component. This message contains a sequence number and the identification of the VM. The iBTM
component replies with a synchronization message, giving its own sequence number, its identifier, and the last
sequence number received from the iBTM driver. The iBTM driver synchronization process allows estimating
the age of any event message with reference to its own clock. The iBTM driver, the iBTM application and the
Odometry application share the same clock inside the Safe computer.
The content of each message allows the receiving party to:
• Identify surely that the message is coming from different iBTM modules
• Ensure that the messages are not corrupted
• Determine the “age” of the message
In general, in accordance with EN 50159, it provides protection against:
• Repetition / Deletion / Insertion / Re-sequence
• Corruption
• Delay
Refer to [SyAD-R74-SIF-Sensor-interface] for a detailed description of this mechanism.
Once an iBTM-RX module has synchronized with a VM, it will not re-synchronize with any other component,
unless powered off. Similarly, the VM will synchronize with exactly 1 TX module and 2 RX modules for each
installed Euroantenna (there may be 1 installed Euroantenna per cabin).
The synchronization sequence with the iBTM-TX components is illustrated in Fig. 11.57. The same principle
applies for the iBTM-RX components.

470 of 750 11.20. iBTM driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.57: iBTM synchronization sequence with one iBTM-TX component

11.20.2 Modes

The iBTM driver has no mode.

11.20.3 Functions

11.20.3.1 [IEVC.F3.02.07.13] Manage iBTM synchronization [function]

Data
• Definition: The iBTM driver component is in charge of managing the synchronization between the
iBTM components in the Sensor Box and the iBTM application in the Safe Computer.
• Allocated to:
– iBTM driver[ci]
• Input:
– iBTM test message[functional variable][VM - iBTM-TX interface][VM - Applications inter-

11.20. iBTM driver 471 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

face]
– Balise or loop detection message[functional variable][VM - iBTM-RX interface][VM - Appli-
cations interface]
– iBTM synchronization message[functional variable][VM - iBTM-RX interface][VM - iBTM-
TX interface]
– iBTM-TX status message[functional variable][VM - iBTM-TX interface][VM - Applications
interface]
– Tele-powering setup message[functional variable][VM - iBTM-TX interface][VM - Applica-
tions interface]
– Up-link telegram message[functional variable][VM - iBTM-RX interface][VM - Applications
interface]
– iBTM-RX status message[functional variable][VM - iBTM-RX interface]
– Change of Spread Spectrum Code[functional variable][VM - iBTM-RX interface][VM - Ap-
plications interface]
• Output:
– Balise or loop detection message[functional variable][VM - iBTM-RX interface][VM - Appli-
cations interface]
– Up-link telegram message[functional variable][VM - iBTM-RX interface][VM - Applications
interface]
– iBTM synchronization message[functional variable][VM - iBTM-RX interface][VM - iBTM-
TX interface]
– iBTM test message[functional variable][VM - iBTM-TX interface][VM - Applications inter-
face]
– iBTM-TX status message[functional variable][VM - iBTM-TX interface][VM - Applications
interface]
– Tele-powering setup message[functional variable][VM - iBTM-TX interface][VM - Applica-
tions interface]
– iBTM-RX status message[functional variable][VM - iBTM-RX interface]
– Change of Spread Spectrum Code[functional variable][VM - iBTM-RX interface][VM - Ap-
plications interface]
• Sil: 4
• Associated interface:
– VM - Applications interface[ci]
– VM - iBTM-TX interface[ci]
– VM - iBTM-RX interface[ci]

472 of 750 11.20. iBTM driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.20.3.2 [IEVC.F4.32.02] Command iBTM component reset [function]

Data
• Definition: The iBTM driver is able to order a reset of the iBTM-TX and iBTM-RX components it
is synchronized with.
• Allocated to:
– iBTM driver[ci]
• Input:
– iBTM reset orders (VM internal)[functional variable]
• Output:
– iBTM-TX reset order[functional variable][VM - iBTM-TX interface]
– iBTM-RX reset order[functional variable][VM - iBTM-RX interface]
• Sil: basic
• Associated interface:
– VM - iBTM-TX interface[ci]
– VM - iBTM-RX interface[ci]

Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional architecture.
The reset is commanded either by the VM (due to an order received through TSC Net) or by the iBTM application
following an iBTM component failure (see Recovery strategy).

11.20.4 Interface

• VM - iBTM-TX interface[ci]
• VM - iBTM-RX interface[ci]
• VM - Applications interface[ci]

11.20.5 Parameters

The iBTM driver component has no specific parameter.

11.20.6 Requirements

Requirement

The iBTM driver shall manage the synchronization between the iBTM components of the Sensor
Box and the iBTM application in the Safe Computer. [id:tsc-req-ievc-ibtm-drv-synchronization][p1][s]

The synchronization mechanism shall be compliant with the Sensor Interface Common Protocol.

Requirement

The iBTM driver shall manage the exchange of messages between the iBTM application and the
iBTM components in the Sensor box(es). [id:tsc-req-ievc-ibtm-drv-data-trsm][p1][ns]

11.20. iBTM driver 473 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The messages are listed in iBTM - Virtual Machine Interface Specification.

Requirement

When providing a message to the iBTM application, the iBTM driver shall include the VM times-
tamp corresponding to the reception of the message and the estimated freshness information in
addition to the iBTM component timestamp already present in the message. [id:tsc-req-ievc-ibtm-drv-
data-trsm-freshness][p1][s]

Requirement

When 2 sensor box are used, the iBTM driver shall route the messages coming from the iBTM
application to the correct sensor box component based on the value of the parameter ‘Installed
cabin’ in the header. [id:tsc-req-ievc-ibtm-drv-dual-sensor-box][p1][s]

The iBTM driver is able to identify the Installed cabin of the iBTM-RX and iBTM-TX component based
on their message content after synchronization (see iBTM - Virtual Machine Interface Specification). The
iBTM driver routes the messages when 2 Sensor box with 2 Euroantenna are required by the installation
project (one per cabin/desk).

Requirement

The iBTM driver shall be able to synchronize with a maximum of 2 iBTM-TX components and 4
iBTM-RX components at a time. [id:tsc-req-ievc-ibtm-drv-synchronization-max][p1][ns]

The iBTM driver shall be able to synchronize with 2 Sensor box when 2 Euroantenna are required by the
installation project (one per cabin/desk).

Requirement

When requested by the VM or by the iBTM application, the iBTM driver shall command a reset of
the iBTM components of the Sensor Box. [id:tsc-req-ievc-ibtm-drv-reset][p1][ns]

11.20.7 Failure modes

The iBTM driver component has no specific failure mode.

474 of 750 11.20. iBTM driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.21 DMI Application

Important: This component is included in the iEVC Basic kit[ci]

11.21.1 Description

As several DMI devices are used, the DMI application is in charge of selecting the active screen(s). It sets the
activation and display state of each screen taking into account the TIU inputs (active cabin), the configuration of
DMI devices (full screen or dual-screens) and any DMI devices failure.
It also collects the safe and non-safe user inputs performed on the DMI and forwarded by the DMI driver, merges
the two pieces of information and provides the result to the signalling application (Subset 026 application[ci] or
Class B application[ci]).

Figure 11.58: DMI functions

11.21.2 Management of active screens

It is a possibility that the DMI shall have two separate screens in each cabin (see tsc-req-urs-driver-dmi-two-
screens[req]): a complete DMI can be duplicated or one may be used as secondary display in case the primary
one fails or in dual-screens mode. The choice of the solution will be done by the project installation through the
configuration of the signalling application. The information is provided to the DMI application through specific
variables.
All DMI devices are identical (same software and hardware). A coded connector provides to a device its unique
identifier, used in the communication with the DMI application.
The DMI application associates to each DMI device an identifier a cabin and a specific display state (full screen
main / backup or dual-screens left / right). This information is used by the DMI application to provide the screen
activation request to the DMI devices.
The following DMI configurations are foreseen:

11.21. DMI Application 475 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Full screens configuration: there is one or two devices full screen per cabin. When two are used, one
device is the main one and the other is used as backup. As long as the main device is working, the backup
device is not used. In case of failure, the backup device is used in replacement of the failed main device.

Figure 11.59: DMI full screen, cabin A active

Figure 11.60: DMI full screen, cabin B active

476 of 750 11.21. DMI Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.61: DMI full screen, cabin B active, failure of main device

• Dual-screens configuration: there are two devices half-screen per cabin, one for the left part of the display
and one for the right part of the display. Both are used in the nominal situation. In case of failure of one
device, the remaining device is used in a degraded mode: the display is adapted to show to the mandatory
information and to get the safe user inputs.

Figure 11.62: DMI dual-screens, cabin A active

11.21. DMI Application 477 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.63: DMI dual-screens, cabin B active

Figure 11.64: DMI dual-screens, cabin B active, failure of left device

• Use of duplicated screens

As the information for DMI display is transmitted to all DMI devices, it is possible to have duplicated
screens. The activation of duplicated screens is achieved through a DMI configuration variable provided by
the signalling application.

478 of 750 11.21. DMI Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.65: DMI full screen, cabin A active, with a second duplicated DMI screen

11.21.3 Modes

The DMI application has no specific mode.

11.21.4 Functions

11.21.4.1 [IEVC.F3.02.09.06] Manage active screens [function]

Data
• Definition: manages the activation and display state of the different DMI devices screens according
to the system configuration (active cabin, device configuration and device failures). Through this
function the DMI application also collects the safe and non-safe user inputs to provide them in a
consistent input for the signalling application. It also collects the SIL2 errors reported by the DMI
devices and reports them with other detected faults to the signalling application and to the LRu
application.
• Allocated to:
– DMI application[ci]
• Input:
– Safe user input information[functional variable][VM - Applications interface]
– SIL2 display status[functional variable][VM - Applications interface]
– SIL2 display error[functional variable][VM - Applications interface]
– Non-safe user input information[functional variable][VM - Applications interface]
– Screen activation status message[functional variable][VM - Applications interface]
– Active cabin[functional variable]
– DMI devices configuration[functional variable]
• Output:
– Screen activation request message[functional variable][VM - Applications interface]
– User inputs for Subset 026 application[functional variable]

11.21. DMI Application 479 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– DMI alarms[functional variable]

• Sil: 2
• Associated interface:
– VM - Applications interface[ci]

The display data is provided directly by the signalling application to the DMI driver.

11.21.5 Interface

The DMI application[ci] uses the VM - Applications interface[ci] to exchange data with the other VM applications
(such as Subset 026 application[ci], Odometry application[ci], LRU application[ci]) and with the DMI driver[ci].
• The following data are provided by the DMI driver to the DMI application, refer to
[SyAD-R69-SIF-VM-DMI] for a more detailed description of some of the mentioned elements:

Functional Variable
Non-safe user input information [functional variable]
Data
– Objective: To provide the information related to an user input received from the DMI
software
– Description: Data structure containing information about the non-safe user input and
the safe user input but treated without safety control.
– Family: Software
– Type: DmiUserInput
– Format: DmiUserInputStruct
– Protocol: VM built-in IN variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.09.04] Manage DMI protocol for ETCS screens[function]

– Consumed by:

* [IEVC.F3.02.09.06] Manage active screens[function]

<DMI_Device_ID> ::= int32 ; Refer to DMI screen ID map in [SyAD-R69-SIF-

˓→VM-DMI].

<DMI_Window_ID> ::= int32 ; Refer to the DMI windows map in [SyAD-R69-

˓→SIF-VM-DMI].

<User_Input> ; type depends on the possible input for the window,

; refer to the DMI user input map in [SyAD-R69-SIF-VM-DMI].

<DMI_device_ID> <DMI_Window_ID> <User_Input>

480 of 750 11.21. DMI Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
Safe user input information [functional variable]
Data
– Objective: To provide the information related to a safe user input received from the
DMI checker
– Description: Data structure containing information about the safe user input (acquired
with safety check).
– Family: Software
– Type: DMI_SIL2_display_status
– Format: DmiSafeUserInputStruct
– Protocol: VM built-in IN variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.09.05] Manage DMI SIL2 protocol[function]

– Consumed by:

* [IEVC.F3.02.09.06] Manage active screens[function]

<DMI_device_ID> ::= int32 ; Refer to DMI screen ID map in [SyAD-R69-SIF-

˓→VM-DMI].

<DMI_Window_ID> ::= int32 ; Refer to the DMI windows map in [SyAD-R69-

˓→SIF-VM-DMI].

<text_msg_acknowledged_s255> ::= string ; Refer to safe input from the

˓→Fixed text code map in [SyAD-R69-SIF-VM-DMI]

<etcs_user_request> ::= enum ; Refer to safe inputs from the ETCS user
˓→request map in [SyAD-R69-SIF-VM-DMI]

<DmiSafeUserInputStruct> ::= <DMI_device_ID> <DMI_Window_ID> <text_msg_

˓→acknowledged_s255> <etcs_user_request>

Functional Variable
SIL2 display status [functional variable]

11.21. DMI Application 481 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide the status of the DMI device received from the DMI checker
– Description: Collection of data structures containing the status information about a
DMI display
– Family: Software
– Type: DMI_SIL2_display_status
– Format: DmiSIL2DisplayStatusList
– Protocol: VM built-in IN variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.09.05] Manage DMI SIL2 protocol[function]

– Consumed by:

* [IEVC.F3.02.09.06] Manage active screens[function]

<DMI_device_ID> ::= int32 ; Refer to DMI screen ID map in [SyAD-R69-SIF-

˓→VM-DMI].

<Screen_State> ::= "\x00" ; screen not available (due to failure)

| "\x01" ; screen inactive (no information displayed)
| "\x02" ; screen active

.. code::

<DmiSil2DisplayStatusStruct> ::= <DMI_device_ID> <Screen_State>

<DmiSIL2DisplayStatusList> ::= [<DmiSil2DisplayStatusStruct>] ;

˓→collection of 4 elements

Functional Variable
Screen activation status message [functional variable]

482 of 750 11.21. DMI Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide the current activation status of a DMI device received from the
DMI software
– Description: Collection of data structure containing the information about activation
and usage of each DMI screen.
– Family: Software
– Type: DmiScreenActivationStatus
– Format: DMIScreenStatusCol
– Protocol: VM built-in IN variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.09.04] Manage DMI protocol for ETCS screens[function]

– Consumed by:

* [IEVC.F3.02.09.06] Manage active screens[function]

<DMI_device_ID> ::= int32; Refer to DMI screen ID map in [SyAD-R69-SIF-

˓→VM-DMI].

<Screen_State_Extended> ::= "\x00" ; screen not available (due to

˓→failure)

| "\x01" ; screen inactive (no information displayed)

| "\x02" ; screen active, total DMI image (no dual-
˓→screen solution)

| "\x03" ; screen active, left part of the DMI image

˓→(dual-screen solution)

| "\x04" ; screen active, right part of the DMI image

˓→(dual-screen solution)

| "\x05" ; screen active, half part of the DMI image

˓→in degraded mode

(failure of the second screen in dual-screen

˓→solution)

<DMI_Screen_Status> ::= <DMI_device_ID> <Screen_State_Extended>

<DMIScreenStatusCol> ::= [<DMI_Screen_Status>] ; collection of 4 elements

• The following data is provided by the DMI application to the DMI driver:

Functional Variable
Screen activation request message [functional variable]

11.21. DMI Application 483 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide the requested screen activation information to all DMI devices
– Description: Data structure containing for each DMI devices its requested screen
activation
– Family: Software
– Type: DmiScreenActivationRequest
– Format: DmiScreenActivationRequestList
– Protocol: VM built-in OUT variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.09.06] Manage active screens[function]

– Consumed by:

* [IEVC.F3.02.09.04] Manage DMI protocol for ETCS screens[function]

* [IEVC.F3.02.09.05] Manage DMI SIL2 protocol[function]

Refer to VM screen activation request[functional variable][VM - DMI interface] in [SyAD-R69-

SIF-VM-DMI].

• The following data is provided by the DMI driver to the DMI application:

Functional Variable
SIL2 display error [functional variable]
Data
– Objective: To provide error of a DMI device
– Description: message containing the reported DMI faults
– Family: Software
– Type: SIL2DisplayErrorList
– Format: BSON
– Protocol: VM built-in IN variable
– Timing constraints: Event
– Associated interface:

* VM - Applications interface[ci]
– Produced by:

* [IEVC.F3.02.09.05] Manage DMI SIL2 protocol[function]

– Consumed by:

* [IEVC.F3.02.09.06] Manage active screens[function]

484 of 750 11.21. DMI Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Collection of maximum 64 detected faults. Each fault has the structure of LRUFaultSta-
tus[functional variable].

Note: The list of SIL2 faults is not defined in this version of the specification.

• The following data is provided by the DMI application to the signalling application (Subset 026 applica-
tion[ci] or Class B application[ci]):

Functional Variable
User inputs for Subset 026 application [functional variable]
Data
– Objective: To provide aggregated DMI user inputs based on the safe and non-safe
user inputs
– Description: Data structure containing information about inputs from the DMI user
– Family: Software
– Type: DMIUserInputs
– Timing constraints: Event
– Produced by:

* [IEVC.F3.02.09.06] Manage active screens[function]

– Consumed by:

* [IEVC.F3.02.09.07] Manage ETCS DMI[function]

This variable is a series of structured data. These data are those of Non-Safe users inputs[functional
variable][VM - DMI interface] in [SyAD-R69-SIF-VM-DMI].

Functional Variable
DMI alarms [functional variable]
Data
– Objective: To provide all the errors related to the DMI devices. This includes the
SIL2 errors reported by the DMI checker but also the errors detected by the DMI
application.
– Description: message containing all the detected DMI faults
– Family: Software
– Type: dmi_alarms
– Timing constraints: Event
– Produced by:

* [IEVC.F3.02.09.06] Manage active screens[function]

– Consumed by:

* [IEVC.F4.08.01] Determine LRU faults[function]

* [IEVC.F3.02.09.07] Manage ETCS DMI[function]

11.21. DMI Application 485 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Collection of maximum 64 detected faults. Each fault has the structure of LRUFaultSta-
tus[functional variable].

Note: The list of DMI faults is not defined in this version of the specification.

The DMI alarms are also provided by the DMI application to the LRU application.
• The following data is provided by signalling application (Subset 026 application[ci] or Class B applica-
tion[ci]) to the DMI application:

Functional Variable
DMI devices configuration [functional variable]
Data
– Objective: To provide the information about how the DMI devices are configured in
a same cabin for a specific installation project
– Description: enum with all the possible screen configurations in a same cabin
– Family: Software
– Type: DMI_device_configuration
– Produced by:

* [IEVC.F3.02.09.07] Manage ETCS DMI[function]

– Consumed by:

* [IEVC.F3.02.09.06] Manage active screens[function]

<DMI_configuration_per_cab> ::= dual half screen

| single full screen
| dual full screen
| dual full screen duplicated

The configuration is considered as identical in both cabins in case 2 cabins are used.

Functional Variable
Active cabin [functional variable]
Data
– Objective: To provide the information about the current active cabin
– Description: enum with all the possible cabin activation
– Family: Software
– Type: ActiveCabin
– Produced by:

* [IEVC.F3.02.09.07] Manage ETCS DMI[function]

– Consumed by:

* [IEVC.F3.02.09.06] Manage active screens[function]

486 of 750 11.21. DMI Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

<Active_Cabin> ::= CabA

| CabB
| No cab active

11.21.6 Parameters

Functional Variable
List of safe user inputs [functional variable]
Data
• Objective: To provide the list of user input to be acquired with safety control.
• Description: This list is used to merge the safe and non-safe user inputs that are reported
respectively by the DMI checker and by the DMI software. Any safe user inputs reported
by the DMI checker will overwrite the corresponding non-safe input provided by the DMI
software.
• Family: Software
• Protocol: System Parameter

Refer to the DMI user input map in [SyAD-R69-SIF-VM-DMI].

11.21.7 Requirements

Requirement

The DMI application shall control the active DMI screens. [id:tsc-req-ievc-ob-dmi-app-req1][p1][ns]

The DMI application shall select the active DMI screens taking into account the current situation (active
cabin, full screen or dual-screens configuration, DMI device failure). It disables the unused screens.

Requirement

The DMI application shall collect the safe and non-safe user inputs from the DMI driver and report
them to the signalling application. [id:tsc-req-ievc-ob-dmi-app-user-inputs][p1][ns]

Any safe user input shall overwrite a non-safe user input when merging the two pieces of information.

Allocate
The iEVC shall support having at least 2 complete DMI display simultaneously showing the same
information. [allocate]

11.21. DMI Application 487 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-install-dmi-duplication[req]
• Ci:
– DMI application[ci]
• Function:
– [IEVC.F3.02.09.06] Manage active screens[function]
• Justification: the DMI application manages the active screens.

The DMI application shall be able to activate simultaneously several DMI devices. In case of dual-screens
solution, a complete DMI display is composed by 2 DMI devices.

Allocate
Allocation of the URS requirement that requires to allow having two separate screens with manda-
tory DMI information on one screen and non-ETCS information on the second. [allocate]
Data
• Requirement:
– tsc-req-urs-driver-dmi-two-screens[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: Management of active screens, Common principles to all windows
• Justification: the management of the active screens

Requirement

The DMI application shall use a fixed mapping for the DMI identifiers. [id:tsc-req-ievc-ob-dmi-app-
dmi-id][p1][ns]

The following mapping shall be used:

• with full screen configuration:
– Cabin A - main device: ID 1
– Cabin A - backup device: ID 3
– Cabin B - main device: ID 2
– Cabin B - backup device: ID 4
• with dual-screen configuration:
– Cabin A - left device: ID 1
– Cabin A - right device: ID 3
– Cabin B - left device: ID 2
– Cabin B - right device: ID 4

488 of 750 11.21. DMI Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Note: The DMI device ID is set through a specific coded connector of the DMI hardware.

Requirement

The DMI application shall provide the DMI alarms to the signalling application and to the LRU
application . [id:tsc-req-ievc-ob-dmi-app-alarms][p1][ns]

The DMI alarms include the SIL2 errors reported by the DMI devices and the errors detected by the DMI
application.

11.21.8 Failure modes

The DMI application has no failure mode.

11.22 DMI driver

11.22.1 Description

The DMI driver is a software module inside the Virtual machine[ci] that acts as a gateway between the DMI
Application and the softwares running on the DMI devices (DMI checker and DMI software). Concerning the data
to display it collects the information directly from the signalling application (Subset 026 application[ci] or Class
B application[ci]).
Furthermore, it reports DMI failures to the OBOM[ci].

11.22.2 Modes

The DMI driver has no mode.

11.22.3 Functions

11.22.3.1 [IEVC.F3.02.09.04] Manage DMI protocol for ETCS screens [function]

Data
• Definition: Command the display and acquire user inputs on the DMI.
• Allocated to:
– DMI driver[ci]
• Input:
– Screen activation request message[functional variable][VM - Applications interface]
– Data to display[functional variable]
– Non-Safe users inputs[functional variable][VM - DMI interface]
– Screen status[functional variable][VM - DMI interface]
– Test Mode PIN Request[functional variable]
• Output:

11.22. DMI driver 489 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– VM screen activation request[functional variable][VM - DMI interface]

– VM screen update[functional variable][VM - DMI interface]
– VM sound control[functional variable][VM - DMI interface]
– Non-safe user input information[functional variable][VM - Applications interface]
– Screen activation status message[functional variable][VM - Applications interface]
– Test Mode PIN response[functional variable]
• Sil: 2
• Associated interface:
– VM - DMI interface[ci]
– VM - Applications interface[ci]

This function manages the TSC Net communication with the DMI software as described in
[SyAD-R69-SIF-VM-DMI]. From the information received from the DMI application and from the sig-
nalling application, it builds and sends the suitable message to all DMI software.
When receiving a Data to display[functional variable] from the signalling application, it transmits to all DMI
software one of the messages contained in VM screen update[functional variable][VM - DMI interface] if there
is some displayed information to be updated on the DMI; or VM sound control[functional variable][VM - DMI
interface] if there is request to start or stop playing a sound.
When receiving a Screen activation request message[functional variable][VM - Applications interface] from the
DMI application, it transmits the VM screen activation request[functional variable][VM - DMI interface] to all
DMI software.
When the message Non-Safe users inputs[functional variable][VM - DMI interface] is received from a DMI
software, it transmits the Non-safe user input information[functional variable][VM - Applications interface] to
the DMI application.
When the message Screen status[functional variable][VM - DMI interface] is received from a DMI software,
it transmits the Screen activation status message[functional variable][VM - Applications interface] to the DMI
application.
When the message Test Mode PIN Request[functional variable] is received from the VM, it transmits the VM
screen update[functional variable][VM - DMI interface] message that requests the display of the PIN code entry
window to the DMI software. When a the user input with the entered PIN code is received from the DMI software
through Non-Safe users inputs[functional variable][VM - DMI interface], it provides the information to the VM
with Test Mode PIN response[functional variable].

11.22.3.2 [IEVC.F3.02.09.05] Manage DMI SIL2 protocol [function]

Data
• Definition: Controls the display and input of safety-related information on the DMI.
• Allocated to:
– DMI driver[ci]
• Input:
– Screen activation request message[functional variable][VM - Applications interface]
– Data to display[functional variable]
– Safe user inputs[functional variable][VM - DMI interface]
– SIL2 error message[functional variable][VM - DMI interface]

490 of 750 11.22. DMI driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– SIL2 Screen activation status[functional variable][VM - DMI interface]

• Output:
– SIL2 Screen activation request[functional variable][VM - DMI interface]
– ETCS message for safe display[functional variable][VM - DMI interface]
– Safe user input information[functional variable][VM - Applications interface]
– SIL2 display status[functional variable][VM - Applications interface]
– SIL2 display error[functional variable][VM - Applications interface]
• Sil: 2
• Associated interface:
– VM - DMI interface[ci]
– VM - Applications interface[ci]

Note: The implementation of this function and the exchanged messages with the DMI checker depends on the
DMI computer vendor.

This function manages the SIL2 communication with the DMI checker as described in
[SyAD-R69-SIF-VM-DMI].
From the information received from the signalling application application (Data to display[functional variable])
and from the DMI application (Screen activation request message[functional variable][VM - Applications inter-
face]), it builds and sends the suitable message to the DMI checker (ETCS message for safe display[functional
variable][VM - DMI interface], SIL2 Screen activation request[functional variable][VM - DMI interface]).
When the message Safe user inputs[functional variable][VM - DMI interface] is received from a DMI checker, it
transmits the Safe user input information[functional variable][VM - Applications interface] to the DMI applica-
tion.
The status of the communication with the DMI checker and the received messages (SIL2 Screen activation sta-
tus[functional variable][VM - DMI interface] and SIL2 error message[functional variable][VM - DMI interface])
are used to transmit the SIL2 display status[functional variable][VM - Applications interface] and the SIL2 display
error[functional variable][VM - Applications interface] to the DMI application.

11.22.4 Interface

The following interfaces are applicable to the DMI driver:

• VM - DMI interface[ci]
• VM - Applications interface[ci]
Through this interface the DMI driver exchange information with the DMI application. See Section 11.21.5
for more information.

11.22. DMI driver 491 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.22.5 Parameters

Functional Variable
DMI SIL2 communication parameters [functional variable]
Data
• Objective: To provide the parameters to establish the communication with the DMI checker.
• Description: A SIL2 protocol through Ethernet is used. To be able to communicate with
the DMI checker on each DMI devices, some parameters are required like: IP address, port
number, ...
• Family: Software
• Type: DMISIL2CommParameters
• Format: vendor dependent
• Protocol: System Parameter

Note: The format of this data depends on the DMI computer vendor and its associated SIL2 protocol. It
is not specified in this version of the specification.

11.22.6 Requirements

Requirement

The DMI driver shall manage the protocol used to provide display information to the DMI and to
receive user inputs. [id:tsc-req-ievc-ob-dmi-driver-etcs-screen][p1][ns]

The DMI driver shall relay the screen activation and display/sound requests coming from the DMI appli-
cation and signalling application to the DMI software.
The DMI driver shall relay the screen activation status and non-safe user inputs coming from the DMI
software to the DMI application.

Requirement

The DMI driver shall manage the SIL2 communication with the DMI [id:tsc-req-ievc-ob-dmi-driver-
req1][p1][s]

Requirement

The DMI driver shall be able to manage the communication with four DMI devices at the same time
[id:tsc-req-ievc-ob-dmi-driver-req2][p1][ns]

Requirement

The DMI driver shall synchronize the information transmitted to the DMI software and to the DMI
checker. [id:tsc-req-ievc-ob-dmi-driver-req3][p1][ns]

The DMI driver shall send at the same time the information about display control to the DMI checker and
the information about display update to the DMI software.

492 of 750 11.22. DMI driver

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.22.7 Failure modes

The DMI driver component has no specific failure mode.

11.23 LRU application

Important: This component is included in the iEVC Basic kit[ci]

11.23.1 Description

The LRU application is in charge of determining the status of each individual LRU of the on-board iEVC subsys-
tem. This application performs a synthesis of information received from the Odometry application[ci], the iBTM
application[ci] and the Virtual machine[ci] to detect and report faults on each LRU and trigger lifetime warnings
when needed.

11.23.2 Interfaces

The LRU application has functional application interfaces with:

• The Odometry application[ci]
• The iBTM application[ci]
• The Virtual machine[ci]
• The TIU application[ci]
• The DMI application[ci]
The details of the interface with the TIU application are provided in [SyAD-R73-SIF-Train-Generic].

11.23.3 Functions

11.23.3.1 [IEVC.F4.08.01] Determine LRU faults [function]

Data
• Definition: Determine LRU faults and synthesize this information in a LRU fault status variable.
• Allocated to:
– LRU application[ci]
• Input:
– Odometry Alarms[functional variable]
– iBTM Alarms[functional variable]
– OBOM faults information[functional variable][VM - Applications interface]
– Safe computer fault information[functional variable]
– DMI alarms[functional variable]
• Output:
– LRU fault status[functional variable][VM - Applications interface]
• Sil: basic

11.23. LRU application 493 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Associated interface:
– VM - Applications interface[ci]

The fault information is reported using the following format:

Functional Variable
LRUFaultStatus [functional variable]
Data
• Family: Software

<FAULT_ID> ::= string ; Refer to Fault ID map

<LRU_ID> ::= enum ; Refer to LRU ID map

<CriticalAlarm> ::= boolean ; flag that identifies if the alarm

; has to be considered as critical
; by the signalling application

<Contextual_Data> ::= string ; Additional contextual data information

; attached to the fault. String of maximum
; size 255.
<SuggestedAction> ::= string ; Suggested action in regards to the LRU
; and the Fault. String of maximum size 255.

<Date> ::= fault detection date including time to the

˓→millisecond

<LRUFaultStatus> ::= <Date> <LRU_ID> <Contextual_Data> <SuggestedAction>

˓→<CriticalAlarm> <FAULT_ID>

Fault ID map and LRU ID map are described in [SyAD-R62-SIF-OBOM-VM]

11.23.3.2 [IEVC.F4.07.01] Determine LRU lifetime and warnings [function]

Data
• Definition: Determine latest LRU lifetime and synthesize this information in an updated LRU life-
time data message.
• Allocated to:
– LRU application[ci]
• Input:
– LRU lifetime data[functional variable][VM - Applications interface]
– Odometry information message[functional variable]
– LRU maintenance event[functional variable][VM - Applications interface]
• Output:
– LRU lifetime data[functional variable][VM - Applications interface]
– LRU lifetime warning[functional variable][VM - Applications interface]

494 of 750 11.23. LRU application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Sil: basic
• Associated interface:
– VM - Applications interface[ci]

11.23.3.3 [IEVC.F4.11.01] Manage interactive test sessions [function]

Data
• Definition: Drives interactive test report sessions, providing detailed test preparation instructions
and triggering tests, and evaluating results.
• Allocated to:
– LRU application[ci]
• Input:
– LRU Interactive Test Input[functional variable][VM - OBOM interface]
– iODO BITE test report[functional variable]
– iBTM test report[functional variable]
– Emergency Brake test report[functional variable]
• Output:
– LRU Interactive Test Report[functional variable][VM - OBOM interface]
– iODO BITE test request[functional variable]
– iBTM test request[functional variable]
• Sil: basic

11.23.4 Parameters

Functional Variable
LRU lifetime thresholds [functional variable]
Data
• Objective: To provide the list of LRU and associated lifetime threshold above which a warn-
ing shall be reported in the maintenance interface of the DMI.
• Description: list of LRU with their associated lifetime threshold
• Family: Software
• Type: LRU_Lifetime_Threshold
• Format: LRU_Lifetime_Threshold
• Protocol: System Parameter

11.23. LRU application 495 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.23.5 Requirements

Requirement

LRU application shall determine pulse generator faults from odometry alarms [id:tsc-req-ievc-app-lru-
faults-pg][p1][ns]

Requirement

LRU application shall determine secondary speed sensor faults from odometry alarms [id:tsc-req-
ievc-app-lru-faults-secondary][p1][ns]

Requirement

LRU application shall determine iBTM-TX faults from iBTM alarms. [id:tsc-req-ievc-app-lru-faults-
ibtm-tx][p1][ns]

Requirement

LRU application shall determine iBTM-RX faults from iBTM alarms. [id:tsc-req-ievc-app-lru-faults-
ibtm-rx][p1][ns]

Requirement

LRU application shall determine I/O faults from I/O faults status. [id:tsc-req-ievc-app-lru-faults-
io][p1][ns]

Requirement

LRU application shall determine DMI faults from OBOM faults information and from SIL2 display
error. [id:tsc-req-ievc-app-lru-faults-dmi][p1][ns]

Requirement

LRU application shall determine Sensor Box Ethernet Switch and Ethernet Switch faults from
OBOM faults information. [id:tsc-req-ievc-app-lru-faults-eth][p1][ns]

Requirement

LRU application shall determine 4G modem faults from OBOM faults information. [id:tsc-req-ievc-
app-lru-faults-4g][p1][ns]

Requirement

LRU application shall determine Sensor Box Power Supply and Telecom Box Power Supply faults
from OBOM faults information. [id:tsc-req-ievc-app-lru-faults-power][p1][ns]

Requirement

LRU application shall determine GSM-R faults from OBOM faults information. [id:tsc-req-ievc-app-
lru-faults-gsmr][p1][ns]

496 of 750 11.23. LRU application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

LRU application shall determine CPM faults from OBOM faults information. [id:tsc-req-ievc-app-lru-
faults-cpm][p1][ns]

Requirement

LRU application shall determine LRU faults based on the faults reported by the driver or maintainer
on the *Report failure window* of the DMI. [id:tsc-req-ievc-app-lru-faults-fault-report][p1][ns]

Requirement

LRU application shall provide the LRU faults status information to the OBOM software in order
for this data to be logged in the CPM or displayed on the DMI Fault status window. [id:tsc-req-ievc-
app-lru-faults-fault-status][p1][ns]

The LRU fault status information provided by the LRU application shall include suggested actions related
to that fault (refer to LRUFaultStatus[functional variable] for the format of the message).

Allocate
Allocation of LRU unique identification requirement [allocate]
Data
• Requirement:
– tsc-req-urs-maintainer-unique-failure-code[req]
• Function:
– [IEVC.F4.08.01] Determine LRU faults[function]
• Artifact:
– OBOM - Virtual Machine Interface Specification[artifact]
• Justification: The full LRU fault map is described in OBOM - Virtual Machine Interface
Specification

Requirement

LRU application shall manage interactive test sessions [id:tsc-req-ievc-app-lru-interactive-tests][p1][ns]

The DMI is used as user interface. The LRU application is responsible for orchestrating the test session by
collecting inputs from the Maintainer, commanding the LRU tests and collecting or computing the result.

Requirement

LRU application shall compute the LRU lifetime and warnings [id:tsc-req-ievc-app-lru-lifetime][p1][ns]

Requirement

LRU application shall report a warning in the maintenance interface of the DMI when the predicted
lifetime of a LRU falls below a configurable threshold. [id:tsc-req-ievc-app-lru-lifetime-warning][p1][ns]

11.23. LRU application 497 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

iEVC error codes shall be designed in such way to identify the LRUs needing replacement, in an
unambiguous way [id:tsc-req-ievc-lru-app-error-codes][p1][ns]

11.23.6 Failure modes

Requirement

If the fault status of a LRU cannot be determined, LRU application shall report the fault status as
“Unknown”. [id:tsc-req-ievc-app-lru-faults-unknown][p1][ns]

11.24 TIU application

Important: This component is included in the iEVC ETCS kit[ci]

11.24.1 Description

TIU means ‘Train Interface Unit’.

In the iEVC system, the TIU is specified as an application. This application maps the physical inputs and outputs to
functional variables expected by other iEVC applications inside Safe computer such as the Subset 026 Application.
The TIU Application translates VM built-in variables exchanged with the IO driver to or from functional variables
exchanged with iEVC Applications. These VM built-in variables represent digital I/O of the iEVC On-board
subsystem. The TIU Application also manages the translation of functional variables onto digital network bus
data.
Depending of the technology a safe input may be a combination of VM built-in variables. For example a func-
tional variable providing the direction may require several physical inputs from the direction controller device.
Depending of the technology a safe output may be mapped to a combination of physical outputs. For example the
emergency brake command will likely be mapped onto at least 2 physical train lines.
While the TIU application may exchange functional variables with safe and non-safe applications, the TIU is
ultimately responsible for commanding the safe train outputs to the train, such as commanding and releasing the
brakes.
Any Installation project application[ci] is not in the scope of this specification. However their ‘standard’ interface
with the TIU application needs to be described.
The mapping of physical I/O is specific to the installation project. So it is the choice of the installation project to
use or not each optional generic I/O functional variables. For example the Service Brake Command will not be
used when trains are not fitted with a Service Brake interface.
A large part of the functional variables that can be exchanged with the applications are derived from
[SyAD-R23-SS34]. This is also in line with the mandatory interface with on-board test facilities as described
in [SyAD-R24-SS94] (tsc-req-urs-nobo-subset-094[req]). Additional functional variables are defined to cover
potential needs in interfacing other train equipment such as TCMS (Train Control & Management System), GSM-
R cab radio, etc.
The principle for the routing of the VM built-in variables outside of the Virtual Machine to physical I/O is de-
scribed in Fig. 12.4 of the Safe computer component description.

498 of 750 11.24. TIU application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The TIU application is also in charge of executing the Emergency Brake test. This test is required in order to
ensure that the iEVC system has an effective access to the brakes. During this test, the TIU application commands
the Emergency Brake and reads back the brake application status on the train interface.

Note: The TIU application that will be installed on a train will need to be adapted based on the need of each
specific installation project because each project has its own specific train interface. Therefore what we call ‘TIU
application’ in the frame of the iEVC system development and in this document must be understood as a ‘TIU
application for test’. This application will provide the means to test and verify the iEVC ETCS kits.

11.24.2 Modes

The TIU application has no specific mode.

11.24.3 Functions

11.24.3.1 [IEVC.F3.02.14.03] Map Application variables onto I/O [function]

Data
• Definition: The TIU application is in charge of translating the application functional variables ex-
changed with the Safe computer applications into VM built-in variables. It translates the application
functional variables into VM built-in output variables and VM built-in input variables into appli-
cation functional variables. The VM built-in variables are used by the IO driver to write and read
information to/from Safe digital I/O and Numeric information on a network data bus. Through this
function the TIU collects the faults related to the IO boards and forwards specific alarms to the LRU
application.
• Allocated to:
– TIU application[ci]
• Input:
– TIU_functional_outputs[functional variable]
– Built-in numeric input[functional variable][VM - Applications interface]
– Built-in logical states[functional variable][VM - Applications interface]
– Odometry information message[functional variable]
– LRU fault status[functional variable][VM - Applications interface]
– Built-in IO board health[functional variable][VM - Applications interface]
• Output:
– TIU_functional_inputs[functional variable]
– Built-in logical commands[functional variable][VM - Applications interface]
– Built-in numeric output[functional variable][VM - Applications interface]
– TIU Alarms[functional variable]
• Sil: 4
• Associated interface:
– VM - Applications interface[ci]

See Fig. 8.19 for a description of the associated functional architecture.

11.24. TIU application 499 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The TIU application aggregates the VM built-in output variables coming from the mapping of safe and non-safe
applications functional variables. The TIU application ensures that there is no overlap in the physical output used
by both types of application. The TIU application reads and dispatches the VM built-in variables linked to physical
input between the safe and non-safe applications. The TIU application will execute a logical ‘OR’ between the
safe and non-safe brake commands. It will ensure that the non-safe application cannot release any brake applied
by a safe application.
The list of TIU_functional_outputs[functional variable] and TIU_functional_inputs[functional variable] is pro-
vided in [SyAD-R73-SIF-Train-Generic].
IO board health information (as provided by the IO driver) is also used to compute safe states and possi-
bly to trigger a system failure (using the variable Safety Critical Fault Occurred[functional variable], refer to
[SyAD-R73-SIF-Train-Generic]). This health information is also used to trigger alarms for the LRU application.
The TIU application may use the Odometry information message[functional variable] coming from the Odometry
application[ci] for internal use or to provide odometry information to a distant device.
The TIU application may use the LRU fault status[functional variable][VM - Applications interface] coming from
the LRU application[ci] for internal use or to communicate fault information to a distant device.

11.24.3.2 [IEVC.F3.02.14.11] Manage Emergency Brake test [function]

Data
• Definition: The TIU application manages the execution of the Emergency Brake test sequence and
assesses the test result. During the test, the TIU application orders the brake through the digital
outputs associated to the functional variable 'EB commanded' and verifies the application status
through the 'EB applied' readback.
• Allocated to:
– TIU application[ci]
• Input:
– Emergency Brake test button activated[functional variable]
– Emergency brake test allowed[functional variable]
– EB Applied[functional variable]
– EB command for test requested[functional variable]
– Odometry information message[functional variable]
• Output:
– TIU Text Messages[functional variable]
– Safety Critical Fault Occurred[functional variable]
– Emergency Brake test report[functional variable]
– Built-in logical commands[functional variable][VM - Applications interface]
• Sil: undefined
• Associated interface:
– VM - Applications interface[ci]

500 of 750 11.24. TIU application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.66: Manage Emergency Brake test

The required conditions for the TIU application to be allowed to start an Emergency Brake test are:
• the variable Emergency brake test allowed[functional variable] has a value ‘TRUE’. This variable is con-
trolled by the signalling application (Subset 026 application[ci] or a Class B application[ci]), AND
• the Emergency Brake readback (EB Applied[functional variable]) indicates that the brake is not applied,
AND
• the Emergency Brake is not being commanded (EB Commanded[functional variable]), AND
• the train is at standstill.
The test is triggered by the TIU application when one of the following events occurs:
• automatically after a new power on cycle, OR
• when the Emergency Brake test button is activated in the Settings window of the DMI, OR

11.24. TIU application 501 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• when the physical input associated with the variable EB command for test requested[functional variable] is
activated in the train interface (usually using a dedicated button on the desk).
It is the decision of the installation designer to implement one or all of these triggering conditions.
Once started, the execution of the test will be aborted if :
• the train moves, OR
• the input Emergency brake test allowed[functional variable] becomes ‘FALSE’, OR
• the Emergency Brake is commanded by the signalling applications (EB Commanded[functional variable]).
If the test is already on-going, an activation of the DMI button or an activation of the digital input ‘EB command
for test requested’ shall have no effect.
When the brake is commanded by using several physical outputs of the safe computer, the TIU application shall
test the effective application and release of the brake for each of these physical outputs individually. Usually 2
digital outputs of the IO boards are used.
The test shall consider a maximum delay to read back a correct application status: Maximum EB application
delay[functional variable], and a maximum delay to read back a correct release status: Maximum EB release
delay[functional variable]. These delays are specific to the type of train and shall be configured by the installation
designer.
The overall test stops as soon as a failure is detected.

Figure 11.67: Successful EB test sequence for 1 physical output (called ‘n’)

502 of 750 11.24. TIU application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.68: Failed EB application or release for 1 physical output (called ‘n’)

The TIU application shall display text messages on the DMI in relation with the status of the test. The following
messages are identified:
• ‘EB test required’: this message is displayed at startup and until a successful EB test has been performed.
• ‘EB test on-going’: this message is displayed during the test sequence execution.
• ‘EB test successful’: this message is displayed when the test is complete and if it was successful. This
message is displayed for 30 seconds.
• ‘EB test failed’: this message is displayed when the test has failed. This message is displayed until a
successful test has been performed.
• ‘EB test aborted’: this message is displayed when the test is aborted. This message is displayed for 30
seconds.

11.24.4 Interfaces

11.24.4.1 TIU interface with iEVC system applications

The TIU application exchange functional variables with the following iEVC system applications:
• Subset 026 Application or other signalling application
• Odometry Application
• LRU application
A detailed description of these functional variables is provided in [SyAD-R73-SIF-Train-Generic].

11.24. TIU application 503 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.69: TIU interface with iEVC system applications

In addition to the variables described in [SyAD-R73-SIF-Train-Generic] the TIU application also provides an
Alarm information to the LRU application for Fault computation and logging purpose.

Functional Variable
TIU Alarms [functional variable]
Data
• Objective: To provide failure information related to the train interface to the LRU applica-
tion.
• Description: Collection of structure that contains TIU alarm information.
• Family: Software
• Type: tiu_alarms
• Produced by:
– [IEVC.F3.02.14.03] Map Application variables onto I/O[function]

Collection of maximum 64 detected faults. Each fault has the structure of LRUFaultStatus[functional
variable]
The faults are those listed in TIU fault map.
Contextual data provides more detailed information on the alarm when available.

504 of 750 11.24. TIU application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.24.4.2 TIU Interface with other applications

The TIU application allows other applications an access to the variables exchanged with iEVC system applica-
tions. The installation designer in charge of the modeling of this application is ultimately responsible for ensuring
a correct mapping of these I/O. In particular, she/he must ensure that non-safe applications cannot interfere with
physical I/O used by safe applications. The only exception concerns brake commands: emergency brake and/or
service brake, if available. The non-safe brake commands may be combined with safe applications brake com-
mands using a logical ‘OR’. This means that a non-safe application cannot release a brake command from a safe
application.

11.24.4.3 Interface between the TIU application and the Virtual Machine

The VM - Applications interface[ci] is used between the TIU application and the Virtual Machine: This interface
includes the following variables:
• Built-in logical commands[functional variable][VM - Applications interface]
• Built-in logical states[functional variable][VM - Applications interface]
• Built-in numeric output[functional variable][VM - Applications interface]
• Built-in numeric input[functional variable][VM - Applications interface]
• Built-in IO board health[functional variable][VM - Applications interface]
A detailed description of these functional variables is provided in the IO driver section.

11.24. TIU application 505 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.70: TIU interface with the virtual machine

The mapping of the build-in Virtual Machine variables on the functional variables depends on the locomotive and
the corresponding installation design. It will not be detailed here.

11.24.4.4 Variables related to Emergency Brake test

The TIU application receives the following variables from the Subset 026 application or other signalling applica-
tion:
Functional Variable
Emergency Brake test button activated [functional variable]

506 of 750 11.24. TIU application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To inform the TIU application that the EB test button has been activated on the
DMI
• Description: boolean with value 'TRUE' when the button has been activated; 'FALSE' oth-
erwise.
• Family: Software
• Type: eb_test_button_activated
• Format: boolean
• Produced by:
– [IEVC.F3.02.09.07] Manage ETCS DMI[function]
• Consumed by:
– [IEVC.F3.02.14.11] Manage Emergency Brake test[function]

When implementing an I/O described in Subset 034, the related installation and rolling stock
constraints shall be observed and traced by the installation designer. [id:tsc-req-ievc-tiu-app-ss34-
constraints][p1][s]

Requirement

When several applications are able to command a service brake, the TIU application shall execute
a logical ‘OR’ between these commands. The TIU application shall release the physical output for
service brake command only when all the individual functional variables have the value “Service
brake not commanded”. [id:tsc-req-ievc-tiu-app-several-sb-command][p1][s]

This includes the case in which the TIU itself is one of the applications ordering the service brake. The
TIU may command a brake as a result of an internal monitoring function specific to the installation design.

Requirement

When several applications are able to command an emergency brake, the TIU application shall
execute a logical ‘OR’ between these commands. The TIU application shall release the physical
output for emergency brake command only when all the individual functional variables have the
value “Emergency brake not commanded”. [id:tsc-req-ievc-tiu-app-several-eb-command][p1][s]

This includes the case in which the TIU itself is one of the applications ordering the emergency brake.
The TIU may command a brake as a result of an internal monitoring function specific to the installation
design.

Requirement

When the Service Brake command interface is used in the subset 026 application (meaning that
the ‘sb_commanded’ functional variable is used to command the full service brake in the train
interface), then the TIU shall read back the state of the service brake through one or several phys-
ical inputs in the train interface and provide its value to the subset 026 application through the
‘SB_applied’ functional variable. [id:tsc-req-ievc-tiu-app-sb-applied][p1][s]

Requirement

The TIU application shall request a system failure to the signalling application when safe inputs
become impossible to read or provide inconsistent values. [id:tsc-req-ievc-tiu-app-failure-mode][p1][s]

510 of 750 11.24. TIU application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The implementation details are project dependent. Filtering delays may be used to avoid that transient
states induce system availability issues.
The variable Safety Critical Fault Occurred[functional variable] is used to request the system failure.

Requirement

During operation, the TIU application shall monitor the emergency brake application (when re-
quested) and shall request a system failure to the signalling application when the monitoring fails.
[id:tsc-req-ievc-tiu-app-eb-apply-monitoring][p1][s]

The implementation details are project dependent. Filtering delays may be used to account for brake
application and readback delays.
The variable Safety Critical Fault Occurred[functional variable] is used to request the system failure.

Requirement

The TIU application shall be able to display text messages on the DMI [id:tsc-req-ievc-tiu-app-txt-
msg][p1][ns]

The TIU application may order the Subset 026 application to display a specific text message.

Requirement

The TIU application shall report alarms to the LRU application. [id:tsc-req-ievc-tiu-app-report-
alarms][p1][ns]

It is up to the installation designer to select the appropriate events to be logged from the TIU Fault map.

11.24.6.2 Emergency Brake test requirements

Requirement

The TIU application shall manage the execution of the Emergency Brake test sequence and assess
the test result. [id:tsc-req-ievc-tiu-app-eb-test][p1][s]

Requirement

The TIU application shall start an Emergency Brake test only when the variable ‘Emergency brake
test allowed’ has a value ‘TRUE’. [id:tsc-req-ievc-tiu-app-eb-test-allowed][p1][ns]

The variable ‘Emergency brake test allowed’ can be controlled by other signalling applications such as the
Subset 026 application or a Class B application.

Requirement

The TIU application shall start an Emergency Brake test only when the Emergency Brake read back
indicates that the Emergency Brake is not already being applied [id:tsc-req-ievc-tiu-app-eb-test-allowed-
eb-not-applied][p1][ns]

The readback is done through the variable ‘EB Applied’.

11.24. TIU application 511 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The TIU application shall start an Emergency Brake test only when the Emergency Brake is
not being commanded by the signalling application. [id:tsc-req-ievc-tiu-app-eb-test-allowed-eb-not-
commanded][p1][ns]

The EB is commanded by the signalling application through the variable ‘EB commanded’.

Requirement

The TIU application shall abort the Emergency Brake test sequence if at least one of the follow-
ing conditions is verified: (1) the value of the variable ‘Emergency brake test allowed’ becomes
‘FALSE’, (2) the train is not at standstill anymore, (3) the brake is commanded by the signalling
application. [id:tsc-req-ievc-tiu-app-eb-test-aborted][p1][ns]

The test result shall be considered as ‘undefined’.

Requirement

The TIU application shall trigger an Emergency Brake test automatically at start-up. [id:tsc-req-
ievc-tiu-app-eb-test-at-startup][p1][ns]

This requirement assumes that the required conditions to start the test are met.

Requirement

The TIU application shall trigger an Emergency Brake test when the Emergency Brake test button
is activated on the DMI. [id:tsc-req-ievc-tiu-app-eb-test-dmi-button][p1][ns]

This requirement assumes that the required conditions to start the test are met.
The Emergency Brake test button is located in the Settings window of the DMI. The activation of the
button is a trigger. it is not required that the button remains activated during the test.

Requirement

The TIU application shall trigger an Emergency Brake test when the variable ‘EB command for test
requested’ is activated in the train interface. [id:tsc-req-ievc-tiu-app-eb-test-desk-button][p1][ns]

This variable is associated to digital inputs connected to one or several buttons on the driver desk. The
activation of the variable is a trigger. it is not required that the variable and its associated button remains
activated during the test.
This requirement assumes that the required conditions to start the test are met.

Requirement

The TIU application shall ignore any request to start an Emergency Brake test while a test is already
on-going. [id:tsc-req-ievc-tiu-app-eb-test-request-ignored][p1][ns]

Requirement

During an Emergency Brake test, the TIU application shall test the correct application and release
of the brake for each physical output commanding the Emergency Brake. [id:tsc-req-ievc-tiu-app-eb-
test-apply-release-each-output][p1][s]

512 of 750 11.24. TIU application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

For each physical output, starting from an ‘EB not applied’ state, the TIU application shall command the
brake and verify the ‘EB applied’ state is correctly read back within a maximum delay (specific to the type
of train considered). If successful, the TIU application shall then release the brake command and verify
the ‘EB not applied’ state is correctly read back within a maximum delay (also specific to the type of train
considered).
While one physical output is being tested the other outputs are left in a state corresponding to ‘EB not
commanded’ in order not to interfere.
The test shall stop as soon as an error is detected and shall be considered as failed.
The test is successful when the application and release of the brake is verified correctly for all the physical
outputs.

Requirement

The TIU application shall display text messages on the DMI in relation to the status of the Emer-
gency Brake test and its result. [id:tsc-req-ievc-tiu-app-eb-test-text-message][p1][ns]

• ‘EB test required’: this message is displayed at startup and until a successful EB test has been
performed.
• ‘EB test on-going’: this message is displayed during the test sequence execution.
• ‘EB test successful’: this message is displayed when the test is complete and if it was successful.
This message is displayed for 30 seconds.
• ‘EB test failed’: this message is displayed when the test has failed. This message is displayed for
30 seconds.
• ‘EB test aborted’: this message is displayed when the test is aborted. This message is displayed for
30 seconds.
These Text messages shall be of type ‘auxiliary’ according to ERA_ERTMS_015560 §8.2.3.4.

11.24. TIU application 513 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.24.7 TIU fault map

Table 11.8: TIU fault map

Fault ID critical Comment
alarm
EB application failure Yes See tsc-req-ievc-tiu-app-eb-apply-monitoring[req]
EB release failure No Based on the same mechanism as for the EB application
IO board communica- to con- Based on the digital I/O health information provided by the IO driver
tion failure firm (1)
IO board failure to con- Based on the digital I/O health information provided by the IO driver
firm (1)
IO board Voltage out to con- Based on the digital I/O health information provided by the IO driver
of range firm (1)
IO temperature warn- No Based on the digital IO health information provided by the IO driver
ing
Digital input not No Based on the digital I/O health information provided by the IO driver.
available Safety reaction, if needed, is managed through the input state ‘NA’
Digital output feed- to con- Based on the digital I/O health information provided by the IO driver.
back non-operational firm (1)
Digital output test to con- Based on the digital I/O health information provided by the IO driver.
pulse failed firm (1)
Specific TIU alarm to con- Other alarms specific to the installation project. The contextual data pro-
firm (1) vide more details about the detected failure

(1) the alarm may be critical for safety-related digital IO only. Detailed analysis has to be performed at installation
project level to confirm the criticality.

11.24.8 Failure modes

When a critical alarm is detected by the TIU application triggers the variable Safety Critical Fault Oc-
curred[functional variable] in its interface with Subset 026 Application.

11.25 Odometry Application

Important: This component is included in the iEVC Sensor kit[ci]

11.25.1 Description

The odometry application provides the iEVC on-board with a safe and highly reliable train’s front-end position
and velocity with respect to a reference Balise Group.
The application receives inputs of on-board sensors measurements by means of iODO driver[ci], as illustrated in
Fig. 11.71.

514 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.71: Odometry logical architecture

Note: Using control theory terminology, this application is a system identification algorithm (an expression in
control theory for system estimators)

Then in each running time-step of iEVC this application computes and outputs estimated traveled distance of the
train’s front-end together with associated confidence interval and Min/Max traveled distance, estimated velocity
and estimated acceleration. Fig. 11.72 illustrates outputs of the odometry application,

11.25. Odometry Application 515 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.72: Representation of Odometry application outputs

in which:
• D_EST: is the estimated traveled distance,
• D_MIN and D_MAX are the minimum and maximum safe frond-end position of train respectively,
• Q_LOCACC: is the location accuracy of balise.
The system identification algorithm to compute the aforementioned estimation of train positioning is an Extended
Kalman Filter (EKF).
The EKF estimates train’s positioning information based on the probability theory in statistics. It computes the
estimation of positioning information which tends to be equal (it is never equal) to the real positioning information
with highest probability. Accordingly, there is no 100% certainty that the estimated positioning information is the
real one.
Therefore, EKF also returns the estimation of error from the real positioning of the train, in the form of a standard
deviation on each of the estimates (e.g. acceleration, speed and distance). For distance, this error gradually grows
with time as train moves.
This accumulation of error is due to uncertainty originating from the lack of precise knowledge on the train’s
dynamical model and sensor inaccuracy. The error accumulation is represented in Fig. 11.72 in the context of
confidence interval which grows with error.
In the context of a safe application like the iEVC, the confidence interval to retain is 6.5𝜎 where 𝜎 is one standard
deviation from estimated traveled distance by odometry. This confidence interval characterizes the min and max
front-end position of the train which are vital to be known for the on-board safety.
The odometry application is also in charge of triggering the iODO BITE test sequence. It requests the iODO BITE
board to generate a specific test signal. This signal is looped back through cables to the iODO boards. the iODO
boards process this signal and report samples to the odometry application that is able to decide whether the test
was successful or not.

516 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.25.2 Modes

No mode is considered for odometry application because this application is always active regardless of other
system components failure or their different operational modes.

Note: Occurrence of wheels slip/slide is not a mode in odometry application, but, it is a condition where the
odometry application decides to accept or reject wheels PG sensor measurement.

11.25.3 Functions

11.25.3.1 [IEVC.F3.02.03.09] Reset confidence interval [function]

Data
• Definition: Resets the EKF function with train's reference point for localization. This initialization
re-calibrates the odometry application to avoid large amount of uncertainty, due to error accumula-
tion, in the positioning estimation of the train.
• Allocated to:
– Odometry application[ci]
• Input:
– Confidence interval reset order[functional variable]
• Output:
– Initialization information[functional variable]
• Sil: 4

11.25.3.2 [IEVC.F3.02.03.08] Manage sensor fusion, selection and conditioning [function]

Data
• Definition: this function selects the sensor inputs to be used for computing an updated estimate
of the train position and speed. This function also implements the automatic reset of an iODO
component in case of detected failure as described in the Sensor recovery strategy. It raises the
odometry alarms to the LRU application and to the signalling application.
• Allocated to:
– Odometry application[ci]
• Input:
– iODO cycle sample messages[functional variable][VM - Applications interface]
– iODO status messages[functional variable][VM - Applications interface]
– Validated odometry parameters[functional variable]
• Output:
– Odometry Alarms[functional variable]
– Selected samples[functional variable][VM - Applications interface]
– iODO reset orders (VM internal)[functional variable]
• Sil: 4

11.25. Odometry Application 517 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Associated interface:
– VM - Applications interface[ci]

This function should be fed by two sensor types, PG sensor and the secondary sensor (Camera sensor or Doppler
radar).
Sensor fusion and conditioning:
• Evaluates the received sensors measurement packet by checking the age of the message it receives from
iODO driver[ci] to make sure that it is receiving the most recent measurement from correct acquisition
source
• Selects sensor combination to be used by evaluating PG and secondary sensor velocity
• Generates Odometry alarms if sensors failure occurs or if sensors return out of range measurement
This function also detects any alarms related to the odometry function and provides them to the LRU application
and to the signalling application. The message is Odometry Alarms[functional variable]. The following alarms
are concerned:
• ‘iODO board status alarm’: failure of an iODO board or lack of iODO status message (tsc-req-ievc-
odometryapplication-iodoboardfailure[req]);
• ‘Maximum distance reached’: overflow of a positioning information (tsc-req-ievc-odometryapplication-
iodo-wrap-around[req]);
• ‘PG sensor failure warning’, ‘PG sensor critical failure’, ‘Secondary sensor failure warning’ and ‘Secondary
sensor critical failure’: failure of one sensor (tsc-req-ievc-odometryapplication-sensor-failure-warning[req]
and tsc-req-ievc-odometryapplication-sensor-failure-alarm[req]);
• ‘Both sensors failed’: failure of both sensors (tsc-req-ievc-odometryapplication-two-sensor-failure-
alarm[req]);
• ‘Inconsistent PG samples from iODO boards’ and ‘Inconsistent Secondary sensor samples from
iODO boards’: inconsistent samples between the 2 iODO boards for a same sensor (tsc-req-ievc-
odometryapplication-iodo-inconsistency[req]).
An iODO automatic reset is triggered in case of detected iODO failure. The reset command uses the VM built-in
variable iODO reset orders (VM internal)[functional variable] (see Sensors recovery strategy).

11.25.3.3 [IEVC.F3.02.03.10] Estimate train odometry (EKF) [function]

Data
• Definition: Estimate the train traveled distance, velocity, acceleration using an Extended Kalman
Filter.
• Allocated to:
– Odometry application[ci]
• Input:
– Selected samples[functional variable][VM - Applications interface]
– Initialization information[functional variable]
– Active Euroantenna[functional variable]
• Output:
– Odometry information message[functional variable]
• Sil: 4

518 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Associated interface:
– VM - Applications interface[ci]

EKF function is a recursive optimal algorithm which estimates the train traveled distance, velocity, acceleration
and other associated variables in Fig. 11.72 in two main computational steps:
1. Prediction step: Predicts the train state vector by propagating the train’s nonlinear kinematics model
2. Correction step: Correct the prediction incorporating the measurement
The two recursive steps of prediction and correction are illustrated in Fig. 11.73, where the following definitions
apply:
• The indices 𝑘 and 𝑘 − 1 indicate the current time step and previous time step respectively. To that end, for
example, 𝑥
ˆ𝑘|𝑘−1 is the estimated train’s state vector at time 𝑘 with respect to the information provided at
time 𝑘 − 1
• 𝑥
ˆ𝑘|𝑘 is the estimated train’s state vector (traveled distance, velocity, acceleration) at instance 𝑘
𝑥𝑥
• 𝑃𝑘|𝑘 is the estimated covariance (estimated errors of the train’s state vector that gives the minimum and
maximum velocity and confidence interval)
• 𝑦𝑘 is the sensors measurement vector. In other words this vector is formed by the samples receive from
[IEVC.F3.02.03.08] Manage sensor fusion, selection and conditioning[function] and by considering the
following sensor models for pulse generator and secondary sensor:
𝜋.𝑊𝐷 .∆𝑐𝑛𝑡
𝑉𝑃 𝐺 =
4.𝑁.∆𝑡
0.01.∆𝑐𝑛𝑡
𝑉𝐶𝑅 =
∆𝑡
where 𝑉𝑃 𝐺 and 𝑉𝐶𝑅 are the measured speeds by pulse generator and secondary sensor (Corrail) respec-
tively, 𝑊𝐷 is the train’s wheel diameter, 𝑁 is the PG sensor resolution, ∆𝑐𝑛𝑡 is the measured pulse dif-
ferentiation between two consecutive sampling time and the ∆𝑡 is the cycles differentiation between two
consecutive sampling cycles.
• 𝑅𝑘 is the measurement noise matrix. It includes sensors noises
• 𝑄𝑘−1 is the process noise matrix. It includes noises due to train’s Kinematics model deviation from the real
model of the train. Accordingly the matrix contains:
– 𝜎𝑎 : standard deviation of acceleration
– 𝜎𝑣 : standard deviation of velocity
– 𝜎𝑑 : standard deviation of traveled distance
𝑦𝑦
• 𝑃𝑘|𝑘−1 is the covariance matrix of measurement
𝑥𝑦
• 𝑃𝑘|𝑘−1 is the cross covariance matrix of state and measurement

11.25. Odometry Application 519 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.73: Representation of EKF function

11.25.3.4 [IEVC.F3.02.03.15] Validate odometry parameters [function]

Data
• Definition: Validate the odometry parameters entered through the DMI (e.g. wheel diameter).
• Allocated to:
– Odometry application[ci]
• Input:
– Odometry parameters[functional variable]
• Output:
– Odometry parameters validation[functional variable]
– Validated odometry parameters[functional variable]
• Sil: 4

This function is responsible to validate and update odometry parameters based on the updated information it
receives from Subset 026 application[ci]. For example the wheel diameter is measured periodically by the main-
tainer and this parameter is entered on the DMI screen. The Subset 026 application controls the display of the
Odometry parameters entry and validation windows (see also [SyAD-R69-SIF-VM-DMI] for details about the
interface between the DMI software and the Virtual Machine). The Subset 026 application will send the updated
parameter to the Odometry application. The wheel diameter parameter is very important to calculate PG sensor
measured speed accurately and if this parameter changes it should also be updated in the Odometry application.
Fig. 11.74 depicts this function and its interface with DMI application.

520 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.74: Representation of Validate odometry parameters function in Odometry application

Different validation outputs from this function to DMI application[ci] is foreseen. The outputs are data check
statuses as:
• Default data: Odometry returns this status when the parameter is entered for the first time
• Data checked: Odometry returns this status when the parameter is compliant with range and resolution
• Data to validate: The change of odometry parameters is in 2 steps, data entry and data validation. Based on
that, Odometry returns this request after being informed from DMI application[ci] of “data entry complete”.
So, the request is sent to DMI to validate (or not) the previously entered data.
• Technical range check error: Odometry returns this status when the parameter is not within specified range
• Technical resolution check error: Odometry returns this status when the parameter resolution is not accept-
able

11.25. Odometry Application 521 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.25.3.5 [IEVC.F4.11.04] Manage iODO BITE test [function]

Data
• Definition: The Odometry application is in charge of triggering the iODO BITE test sequence when
requested by the LRU application. It instructs the characteristics of the signal that the iODO BITE
component has to produce. The odometry application then collects the odometry samples from the
iODO boards. Based on these samples it decides wether the test is successful or not and feeds back
the result to the LRU application.
• Allocated to:
– Odometry application[ci]
• Input:
– iODO BITE status[functional variable][VM - iODO BITE interface]
– iODO BITE test request[functional variable]
– iODO cycle sample messages[functional variable][VM - Applications interface]
• Output:
– iODO test command message[functional variable][VM - iODO BITE interface]
– iODO BITE test report[functional variable]
• Sil: basic
• Associated interface:
– VM - Applications interface[ci]
– VM - iODO BITE interface[ci]

522 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.75: Functional architecture for the iODO BITE test

11.25.4 Interface

Odometry application sends and receives messages in Virtual Machine by means of the following interface:
• VM - Applications interface[ci]:
The packet of sensors measurement as well as sensors status is provided through iODO driver[ci] by the
following functional variable:
– iODO cycle sample messages[functional variable][VM - Applications interface]
• LRU application[ci] and signalling applications such as Subset 026 Application
The odometry application returns a list of alarms that are used by the LRU application to determine the faults
affecting the iODO boards or the odometry sensors. The alarms are also used by the signalling applications
(such as the Subset 026 application) to produce a safe reaction in case of critical failure. The alarms are
defined as follow:
– Odometry alarms

11.25. Odometry Application 523 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
Odometry Alarms [functional variable]
Data

* Objective: To alarm on-board with possible failure in odometry sensors

* Description: This functional variable reports sensors failures or sensors out of
range behavior to LRU application

* Family: Software
* Type: odometry_alarms
* Produced by:
· [IEVC.F3.02.03.08] Manage sensor fusion, selection and condition-
ing[function]

* Consumed by:
· [IEVC.F4.08.01] Determine LRU faults[function]
· [IEVC.F3.02.03.12] Manage information from odometry applica-
tion[function]

Collection of maximum 64 detected faults. Each fault has the structure of LRUFaultSta-
tus[functional variable]
The faults are those listed in the Odometry fault map.
Contextual data provides more detailed information on the alarm when available.

• LRU application[ci]. The interface with the LRU application also includes the exchange of the following
messages:

Functional Variable
iODO BITE test request [functional variable]
Data
– Objective: To inform the odometry application that an interactive test command en-
tered by the maintainer on the DMI when executing an interactive test session.
– Description: message containing the iODO BITE test request
– Family: Software
– Type: iodo_test_request
– Timing constraints: Event
– Produced by:

* [IEVC.F4.11.01] Manage interactive test sessions[function]

– Consumed by:

* [IEVC.F4.11.04] Manage iODO BITE test[function]

The structure of the message shall be consistent with the definition of message LRU Interactive Test
Input[functional variable][VM - OBOM interface] defined in [SyAD-R62-SIF-OBOM-VM].

524 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
iODO BITE test report [functional variable]
Data
– Objective: To provides updated interactive testing data to display
– Description: message containing the test status and result. The message also contains
additional information on the test result and possibly suggested actions.
– Family: Software
– Type: iodo_test_report
– Timing constraints: Event
– Produced by:

* [IEVC.F4.11.04] Manage iODO BITE test[function]

– Consumed by:

* [IEVC.F4.11.01] Manage interactive test sessions[function]

The structure of the message shall be consistent with the definition of message LRU Interactive Test
Report[functional variable][VM - OBOM interface] defined in [SyAD-R62-SIF-OBOM-VM].

• Subset 026 application[ci]

– Odometry information message and reset order
The linking information message (originated from iBTM-RX[ci]) is processed by the Subset 026 ap-
plication[ci]. It extracts from this information a new reference position and an associated location
accuracy that is used to reset the confidence interval in the odometry application (see Confidence
interval reset order[functional variable].
The odometry application returns its outputs to several iEVC applications such as the Subset 026
application[ci] or the iBTM application[ci]. The outputs contain:
1. Train’s estimated state vector including acceleration, velocity and traveled distance from the Cur-
rent Reference Balise Group (CRBG) and the start of the system
2. Confidence interval of the traveled distance (Fig. 11.72)
3. Max and Min traveled distance which determine Max and Min safe front-end position (Fig.
11.72).
Functional Variable
Odometry information message [functional variable]

11.25. Odometry Application 525 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data

* Objective: To provide on-board with train positioning information

* Description: Train's acceleration, velocity, position from a reference location
and the associated sigma values. The message also includes the absolute posi-
tion counted from the power on of the iEVC, and the total travelled distance,
whatever the direction of travel.

* Family: Software
* Type: odo_info_message
* Format: OdoInfoMessageStruct
* Produced by:
· [IEVC.F3.02.03.10] Estimate train odometry (EKF)[function]

* Consumed by:
· [IEVC.F3.02.07.09] Verify, filter and decode Eurobalise and Euroloop
telegram[function]
· [IEVC.F4.07.01] Determine LRU lifetime and warnings[function]
· [IEVC.F3.02.03.12] Manage information from odometry applica-
tion[function]
· [IEVC.F3.02.14.03] Map Application variables onto I/O[function]
· [IEVC.F3.02.14.11] Manage Emergency Brake test[function]

<Odo_info_acceleration> ::= real ; In m.s-2. Estimated acceleration.

<Odo_info_speed> ::= real ; In m.s-1. Estimated speed.
<Odo_info_position> ::= real ; In m. Distance travelled with respect
˓→to the last CRBG (Current Reference Balise Group).

<Odo_info_reference_id> ::= uint32 ; The CRBG reference id with

˓→respect to which the position is provided.

<Odo_info_sigma_acceleration> ::= real ; In m.s-2. Standard

˓→deviation of estimated acceleration.

<Odo_info_sigma_speed> ::= real ; In m.s-1. Standard deviation of

˓→estimated speed.

<Odo_info_sigma_position> ::= real ; In m. Standard deviation of

˓→estimated position 'Odo_info_position'.

<Odo_info_sensor_combination> ::= enum ; Refer to odometry sensor map

<Odo_info_absolute_position_from_start> ::= real ; In m. Absolute
˓→position of the train counted from the power on of the iEVC.

<Odo_info_total_travelled_distance> ::= real ; In m. Total

˓→accumulated travelled distance of the train (whatever the

˓→direction of movement). This information is used to compute the

˓→mileage of LRU.

<Odo_info_acceleration> <Odo_info_speed> <Odo_info_position> <Odo_

˓→info_sigma_acceleration> <Odo_info_sigma_speed> <Odo_info_sigma_

˓→position> <Odo_info_sensor_combination> <Odo_info_absolute_

˓→position_from_start> <Odo_info_total_travelled_distance> <Odo_info_

˓→reference_id>

The Odo_info_position value increases when moving in the nominal direction of the sensors.
The sensors are installed in such way that the nominal direction corresponds to the Cab A for-
ward traveling direction. When moving in the opposite direction, the distance value decreases.

526 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– Odometry parameters update

The following data are exchanged between the Subset 026 application and the Odometry application
in order to update the Odometry parameters:

Functional Variable
Odometry parameters [functional variable]
Data

* Objective: To provide the odometry parameters entry /validation from the user
on DMI

* Description: Data structure containing the Odometry parameters and the entry
status

* Family: Software
* Type: OdometryParameters
* Format: OdometryParametersStruct
* Timing constraints: Event
* Produced by:
· [IEVC.F3.02.09.07] Manage ETCS DMI[function]

* Consumed by:
· [IEVC.F3.02.03.15] Validate odometry parameters[function]

<wheel_diameter_mm> ::= int32

<data_entry_state> ::= "\x00" ; data entry screen requested

| "\x01" ; data accepted by the user (to be
˓→checked)

| "\x02" ; data entry complete

| "\x03" ; data validated
| "\x04" ; data entry canceled

<OdometryParametersStruct> ::= <wheel_diameter_mm> <data_entry_state>

Functional Variable
Odometry parameters validation [functional variable]

11.25. Odometry Application 527 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data

* Objective: To provide the odometry parameters default values and controls to

the user on DMI

* Description: Data structure containing

* Family: Software
* Type: OdometryParametersValidation
* Format: OdometryParametersValidationStruct
* Timing constraints: Event
* Produced by:
· [IEVC.F3.02.03.15] Validate odometry parameters[function]

* Consumed by:
· [IEVC.F3.02.09.07] Manage ETCS DMI[function]

<wheel_diameter_default_value> ::= int32 ; default value in mm

<wheel_diameter_echo_value> ::= int32 ; echo value in mm

<OdometryParametersValidationStruct> ::= <wheel_diameter_default_

˓→value> <wheel_diameter_echo_value> <wheel_diameter_data_check_

˓→status>

Fig. 11.76 illustrates the functional exchange scenario between the Subset 026 application and the
Odometry application when updating the wheel diameter through data entry. The figure represents a
successful update. When the technical check of the Odometry application fails it returns ‘Technical
range check error’ or ‘Technical resolution check error’ instead of ‘Data checked OK’. In this case
the DMI application shall command that the echo text indicates ‘++++’ in red and that the input field
remains active until a valid value is entered or until the data entry is canceled by the user (refer to
[SyAD-R17-DMI] for more information on data entry display).
The entry process can be canceled by the user at any step of the process. The odometry parameter is
only updated once the data has been validated by the user.
Provision is made for future cross-checks in case several parameters must be entered. The cross-check
is realized after receiving the ‘data entry complete’ message.

528 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 11.76: Odometry parameters data entry sequence

– Active Euroantenna[functional variable]: this information is used to shift the position information
that is relative to a reference balise group once the active Euroantenna changes (see tsc-req-ievc-
odometryapplication-two-euroantenna-pos-shift[req]).

11.25.5 Internal variables

Functional Variable
Initialization information [functional variable]

11.25. Odometry Application 529 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To reset (re-calibrate) the odometry algorithm and update the Current Reference
Balise Group (CRBG)
• Description: Initial conditions to reset the train's state vector and associated errors due to
accumulated uncertainties. These initial conditions are set based on a reference position
and a new (reduced) confidence interval. When operating in ETCS this information is ex-
tracted from the linking information and is provided when a change of CRBG occurs. This
information includes a new reference position and the associated location accuracy.
• Family: Software
• Type: Array of structure containing a new reference position and the associated location
accuracy
• Unit: meter for the usage distance
• Timing constraints: Event
• Produced by:
– [IEVC.F3.02.03.09] Reset confidence interval[function]
• Consumed by:
– [IEVC.F3.02.03.10] Estimate train odometry (EKF)[function]

Functional Variable
Selected samples [functional variable]
Data
• Objective: To provide a cyclic reliable measurement samples for EKF function
• Description: Upon the reception of iODO cycle sample messages the function Manage
sensor fusion, selection and conditioning produces this functional variable for EKF function
for the reliable train positioning estimation. Based on that, different sensor combinations
with different measurement vectors can be generated to be sent to EKF function by this
functional variable
• Family: Software
• Format: Array
• Protocol: VM Built-in IN Variable
• Timing constraints: Cyclic(VM_cycle_time)
• Associated interface:
– VM - Applications interface[ci]
• Produced by:
– [IEVC.F3.02.03.08] Manage sensor fusion, selection and conditioning[function]
• Consumed by:
– [IEVC.F3.02.03.10] Estimate train odometry (EKF)[function]

530 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
Validated odometry parameters [functional variable]
Data
• Objective: To update odometry sensors parameters
• Description: When the DMI application sends updated parameters to the function Validate
odometry parameters and the Odometry application validates the entered parameter it should
also update the validated parameters inside the application for more precise estimation cal-
culations of the train positioning
• Family: Software
• Format: Double
• Protocol: VM Built-in IN Variable
• Timing constraints: Event
• Produced by:
– [IEVC.F3.02.03.15] Validate odometry parameters[function]
• Consumed by:
– [IEVC.F3.02.03.08] Manage sensor fusion, selection and conditioning[function]

11.25.6 Parameters

Functional Variable
Sensors parameters [functional variable]
Data
• Objective: To provide sensors model for odometry algorithm
• Description: Sensors parameters are required to calculate measurement vector based on
sensors model from raw sensors data. The sensor parameters can be derived from technical
specification of sensor catalog provided by supplier.
• Family: Software
• Type: OdometrySensorParameters
• Format: OdometrySensorParameter
• Protocol: System Parameters

<Odo_Sensor_Parameter_PG_Pulse_Revolution> ::= uint32 ; number of pulses per

˓→revolution for PG sensor

<Odo_Sensor_Parameter_PG_Wheel_Diameter> ::= real ; In m

<Odo_Sensor_Parameter_PG_Resolution> ::= uint32 ; Resolution factor of PG
˓→sensor

<Odo_Sensor_Parameter_Secondary_Resolution> ::= real ; Resolution factor of

˓→Secondary sensor

11.25. Odometry Application 531 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
EKF calibration parameter: Standard deviation of acceleration [functional variable]
Data
• Objective: To calibrate EKF estimator
• Description: Standard deviation of acceleration is a feature in process noise matrix of the
EKF. This parameter determines how much the EKF prediction model can be far from the
real train model.
• Family: Software
• Type: EKFSigmaA
• Format: Double
• Unit: m/s^2
• Precision: 0.05
• Protocol: System Parameters
• Equivalence class: ]0 0.2], ]0.2 1] ]1 inf[
• Forbidden data: > 0.2
• Minimum: 0
• Maximum: 0.2
• Behavior outside range: NA
• Memory management: NA
• Timing constraints: NA
• Sil: NA

Functional Variable
EKF calibration parameter: Standard deviation of velocity [functional variable]

532 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To calibrate EKF estimator
• Description: Standard deviation of velocity is a feature in process noise matrix of the EKF.
This parameter determines how much error in velocity can happen due to some unexpected
phenomenon like wheels slip/slide or due to model inaccuracy.
• Family: Software
• Type: EKFSigmaV
• Format: Double
• Unit: m/s
• Precision: 0.5
• Protocol: System Parameters
• Equivalence class: ]0 2], ]2 inf[
• Forbidden data: Dependent on the performance of EKF
• Minimum: 0
• Maximum: 2
• Behavior outside range: NA
• Memory management: NA
• Timing constraints: NA
• Sil: NA

Functional Variable
EKF calibration parameter: Standard deviation of traveled distance [functional variable]

11.25. Odometry Application 533 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To calibrate EKF estimator
• Description: Standard deviation of traveled distance is a feature in process noise matrix of
the EKF. This parameter determine how much error in travelled distance can happen due to
some unexpected phenomenon like wheels slip/slide or due to model inaccuracy.
• Family: Software
• Type: EKFSigmaD
• Format: Double
• Unit: m
• Precision: 0.01
• Protocol: System Parameters
• Equivalence class: ]0 1.5], ]1.5 inf[
• Forbidden data: > 1.5
• Minimum: 0
• Maximum: 1.5
• Behavior outside range: NA
• Memory management: NA
• Timing constraints: NA
• Sil: NA

Functional Variable
iODO sample maximum delta speed [functional variable]
Data
• Objective: To provide a criteria to detect inconsistency between the samples provided by
the 2 iODO boards
• Description: Maximum allowed absolute speed difference between the selected valid sam-
ples provided by the 2 iODO boards for a sensor. Above that threshold, the sensor is con-
sidered as failed in the odometry computation.
• Family: Software
• Type: iODOSampleMaxDeltaV
• Format: Double
• Unit: m/s
• Precision: 0.1
• Protocol: System Parameters
• Minimum: 0
• Maximum: 10

534 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
maximum absolute position value [functional variable]
Data
• Objective: To provide a criteria to raise an alarm in order to avoid a wrap around of the
position information
• Description: Maximum distance that can be used in the odometry information
• Family: Software
• Format: double
• Unit: m
• Precision: 0.1
• Protocol: System Parameters
• Minimum: 0.0
• Maximum: 2147483648.0

Functional Variable
iODO status message timeout [functional variable]
Data
• Objective: To monitor that the iODO component is alive
• Description: maximum delay without iODO status message received by the odometry ap-
plication
• Family: Software
• Type: iODOStatusTimeout
• Unit: ms
• Precision: 1
• Protocol: System Parameter
• Minimum: 0
• Maximum: 10000

Functional Variable
maximum wheel diameter [functional variable]

11.25. Odometry Application 535 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To validate the value of the wheel diameter entered on DMI entry window :de-
scription: Maximun wheel diameter that can be entered from the user on DMI
• Family: Software
• Type: iODOWheelDiameterMax
• Unit: mm
• Precision: 1
• Protocol: System Parameter
• Minimum: 600
• Maximum: 1400

Functional Variable
minimum wheel diameter [functional variable]
Data
• Objective: To validate the value of the wheel diameter entered on DMI entry window :de-
scription: minimum wheel diameter that can be entered from the user on DMI
• Family: Software
• Type: iODOWheelDiameterMin
• Unit: mm
• Precision: 1
• Protocol: System Parameter
• Minimum: 600
• Maximum: 1400

11.25.7 Requirements

Requirement

Odometry application shall estimate accurately enough train positioning information (Accelera-
tion, Speed, Travelled distance, Confidence interval) such that the whole iEVC architecture ful-
fills accuracy requirement specified in subsets 041 and 036 [id:tsc-req-ievc-odometry-provide-odometry-
information][p1][ns]

An EKF algorithm shall be used.

Requirement

When the accuracy requirement specified in subsets 041 for speed and distance measurement are
not met, the Odometry application shall report a warning to the Subset 026 application. [id:tsc-req-
ievc-odometry-alarm-accuracy][p1][ns]

536 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

Odometry application shall reset the odometry confidence interval upon reception of a reset order.
[id:tsc-req-ievc-odometryapplication-iodo-reset][p1][ns]

Requirement

Odometry application shall raise a critical alarm when no status message has been received from
one of the iODO boards for more than a configurable delay or when the status message indicates a
failure of the board. [id:tsc-req-ievc-odometryapplication-iodoboardfailure][p1][s]

The configurable delay is iODO status message timeout[functional variable].

Requirement

Odometry application shall raise an alarm in case the absolute value of any positioning information
reported by the odometry application reaches a maximum value. [id:tsc-req-ievc-odometryapplication-
iodo-wrap-around][p1][ns]

Requirement

Odometry application shall select the best possible sensors combination (accept or reject each sensor
measurement) at each sampling cycle based on the measurement samples received during the cycle.
[id:tsc-req-ievc-odometryapplication-req1][p1][s]

Requirement

Odometry application shall raise a critical alarm in case it detects one sensor failure that lasts more
than 30 seconds. [id:tsc-req-ievc-odometryapplication-sensor-failure-alarm][p1][s]

A sensor failure is considered when:

• all the samples available for this sensor are too old for one of the iODO boards
• no samples are available for this sensor for one of the iODO boards
• inconsistent sample data for this sensor between the two iODO boards
• the sensor is detected as ‘not connected’ or failed in all the valid samples from one of the
iODO boards (based on “pg_x_connected” or “secondary_serial_status” in iODO sample mes-
sage[functional variable][VM - iODO interface])
• sensor samples are valid for this sensor for both iODO boards but EKF selects the only other
sensor during its selection process.
This specific alarm is used by the signalling application to trigger a safe reaction.

Requirement

Odometry application shall raise a critical alarm in case it detects that both sensors are failed for
more than 2 seconds. [id:tsc-req-ievc-odometryapplication-two-sensor-failure-alarm][p1][s]

The conditions to consider a sensor as failed are the same as for tsc-req-ievc-odometryapplication-sensor-
failure-alarm[req].
This specific alarm is used by the signalling application to trigger a safe reaction.

11.25. Odometry Application 537 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

For a speed sensor, the Odometry application shall consider the samples coming form the two iODO
boards as inconsistent when the absolute speed difference is higher than a configurable threshold.
[id:tsc-req-ievc-odometryapplication-sensor-inconsistency-criteria][p1][s]

Refer to iODO sample maximum delta speed[functional variable] for the configurable threshold.

Requirement

Odometry application shall raise a warning in case of inconsistent samples are provided by the two
iODO boards for a same sensor. [id:tsc-req-ievc-odometryapplication-iodo-inconsistency][p1][ns]

Requirement

Odometry application shall raise a specific warning in case it detects a sensor failure that lasts more
than 15 seconds. [id:tsc-req-ievc-odometryapplication-sensor-failure-warning][p1][s]

A sensor failure is considered when:

Requirement

Odometry application shall evaluate and select the measurement samples received from the
iODO boards based on their age, their content, and the status of the sensor. [id:tsc-req-ievc-
odometryapplication-measurement-selection][p1][s]

Requirement

Odometry application shall filter sensors measurement noise (High frequency noises due to measure-
ment imperfection or environmental perturbations) [id:tsc-req-ievc-odometryapplication-req3][p1][ns]

Requirement

When two Euroantenna are used and when the active euroantenna is changed, the odometry ap-
plication shall shift the reported position information that is relative to a reference balise group
by the distance between the two Euroantenna. [id:tsc-req-ievc-odometryapplication-two-euroantenna-pos-
shift][p1][ns]

The shift is triggered based on the information provided in Active Euroantenna[functional variable].

538 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

Odometry application shall validate and update odometry parameters which it receives from Subset
026 application [id:tsc-req-ievc-odometryapplication-req4][p1][s]

The Odometry application validates the value that were input manually on the DMI if it is included be-
tween minimum wheel diameter[functional variable] and maximum wheel diameter[functional variable]
and if the resolution is 1mm.

Requirement

When requested by the LRU application, the odometry application shall trigger the iODO BITE test
sequence by commanding the signal to be generated by the iODO BITE component. It shall compute
the test result based on the collected samples from the iODO boards and feedback the result to the
LRU application. [id:tsc-req-ievc-odometryapplication-bite-test][p1][ns]

11.25.8 Odometry sensor map

Table 11.9: Odometry sensor map

Index, Sensor combi-
nation
1 PG
2 Secondary sensor
3 PG-Secondary sensor
4 Tag read from Balise

11.25. Odometry Application 539 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.25.9 Odometry fault map

Table 11.10: Odometry fault map

Fault ID Critical Requirement
alarm
Poor accuracy for speed No tsc-req-ievc-odometry-alarm-accuracy[req]
Poor accuracy for position No tsc-req-ievc-odometry-alarm-accuracy[req]
Maximum distance reached Yes tsc-req-ievc-odometryapplication-iodo-wrap-
around[req]
PG sensor failure warning No tsc-req-ievc-odometryapplication-sensor-failure-
warning[req]
Secondary sensor failure warning No tsc-req-ievc-odometryapplication-sensor-failure-
warning[req]
PG sensor critical failure Yes tsc-req-ievc-odometryapplication-sensor-failure-
alarm[req]
Secondary sensor critical failure Yes tsc-req-ievc-odometryapplication-sensor-failure-
alarm[req]
Both sensors failed Yes tsc-req-ievc-odometryapplication-two-sensor-
failure-alarm[req]
Inconsistent PG samples from iODO No tsc-req-ievc-odometryapplication-iodo-
boards inconsistency[req]
Inconsistent Secondary sensor samples No tsc-req-ievc-odometryapplication-iodo-
from iODO boards inconsistency[req]
iODO board status alarm Yes tsc-req-ievc-odometryapplication-
iodoboardfailure[req]
No valid wheel diameter Yes tsc-req-ievc-odometryapplication-wheel-diameter-
no-valid-value[req]
iODO BITE status error No tsc-req-ievc-iodobite-version[req]

The faults marked as critical alarms trigger a safe reaction of the signalling application (refer to tsc-req-ievc-ss26-
app-odo-critical-failure[req]).

11.25.10 Failure modes

Different failure modes can happen for Odometry application where they are discussed in the following.

11.25.10.1 Broken PG

At every cycle of the Virtual machine[ci] the Odometry application receives a packet of data form iODO driver[ci].
This measurement data packet should provide healthy signal of sensor status as per on-board sensor. So, the fail-
ure of Wheel pulse generators[ci] can be detected by odometry application from the sensor status signal. In this
condition, the odometry takes into account the measurement data only from Secondary odometry sensor[ci]. This
way, if we stay too long with secondary sensor, the requirement on keeping odometry application performance
(according to accuracy threshold) depends on the secondary sensor reliability and the results of RAMS calcula-
tions.

540 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.25.10.2 Wheel Slip and Slide

Slip and Slide phenomena are the kind of failures imposed by exogenous uncontrolled events that are very likely
to happen sporadically.
The odometry application can tolerate some amount of slip and slide, and that it fuses this amount in its uncertain-
ties.
Beyond that threshold, slip and slide is detected by comparison of previous measurement samples, as well as
comparing measures from the two different odometry sensor types. In case it is detected, the odometry appli-
cation ignores PG sensor measurement in the case of possible wheel slip/slide. This evaluation task is part of
[IEVC.F3.02.03.08] Manage sensor fusion, selection and conditioning[function].
Continuous slip and slide above the detection threshold can only be tolerated for the same time as the broken PG
scenario.

11.25.10.3 Broken secondary sensor

In case of Secondary odometry sensor[ci] failure the odometry application has only the measurement data received
from Wheel pulse generators[ci]. In this condition odometry application can keep the accuracy requirements in
range, though its performance may degrade and depends on the precision of the Wheel pulse generators[ci].
Besides, odometry application cannot detect Slip/Slide anymore and during this condition there would be a false
estimation of velocity and traveled distance on-board. Conclusively, losing Secondary odometry sensor[ci] poses
greater concern than losing Wheel pulse generators[ci], and may not be tolerated very long. The exact tolerance
depends on RAMS computations.

11.25.10.4 Broken PG and Secondary Sensor

The odometry application can no longer estimate the train position and speed in this scenario. It is theoretically
possible, but estimates will diverge very quickly, and so ultimately amounts to the same.

11.25.10.5 No sample received from a single sensor

In the lack of measurement sample from one sensor (PG or secondary sensor) odometry application can decide to
fuse only one single sensor measurement until the measurement sample from that sensor is available again. How
long this may continue depends on RAMS calculations.

11.25.10.6 Lag on the transmission from iODO to Virtual Machine

Odometry application can tolerate a certain amount of lag on the iODO network interface thanks to the synchro-
nization protocol used between iODO driver and the iODO components. However, the higher this tolerance, the
less accurate the odometry estimates.

11.25.10.7 No sample received from iODO

If two iODO[ci] boards desynchronize with Virtual machine[ci] it is a hazard situation for train positioning. If no
sample is received for more than couple of seconds from the last received sample the calculated confidence interval
will rise exponentially and odometry needs re-calibration (by using the Confidence interval reset order[functional
variable] received from the signalling applications).

11.25. Odometry Application 541 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.25.10.8 No relocation Balise detected for long time

The consequence of this condition is the gradual growth of confidence interval in train’s positioning. The main
problem with this is that the train may exhibit non-linear behavior that will become significant compared to the
linear approximation that an EKF is.
Examples of such behaviors are:
• Wheel grinding
• Lateral oscillations of the train leading to variations on the longitudinal speed;
• Etc. . .
Therefore, there is a limit beyond which the EKF model estimated distance simply becomes irrelevant (this is not
true for speed, since it is directly measured every cycle).
The exact threshold depends on RAMS calculations and is a system parameter of the odometry application. Be-
yond this threshold, the odometry application shall create an alarm to inform the signalling application.

Requirement

Odometry shall create an alarm when the confidence interval goes beyond the calculated threshold.
[id:tsc-req-ievc-odometry-confidence-interval][p1][ns]

11.25.10.9 Wheel diameter changes

The wheel diameter must be known with a precision better than 1% for the odometry application to return values
compliant with ETCS performance requirements. In this version, this constraint is exported as regular checks to
maintenance. The exact period depends on RAMS computations.

Requirement

Wheel diameter shall be verified regularly [id:tsc-req-ievc-wheel-diameter-regular-check][p1][s]

11.25.10.10 No valid Wheel diameter value

The wheel diameter is an operational data that is stored in a non-volatile memory of the iEVC (refer to
[IEVC.F5.09.01] Provide application access to non-volatile operational data[function]). It is retrieved at start-up
and provided to the Odometry application. A new valid value may be input using the DMI interface.
It may be possible that no valid wheel diameter value is currently stored on-board. This happens when the opera-
tional data is corrupted, or because no valid wheel diameter has ever been recorded and no value has been input on
the DMI. In that case, the Odometry application has to raise a critical alarm to inform the signalling application
that the provided odometry information cannot be trusted.

Requirement

The Odometry application shall raise a critical alarm when no valid Wheel diameter value is stored
on-board. [id:tsc-req-ievc-odometryapplication-wheel-diameter-no-valid-value][p1][s]

No valid wheel diameter data exists when the operational data is corrupted, or when no value has ever
been recorded and no valid input has been validated on the DMI interface.

542 of 750 11.25. Odometry Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.26 ETCS messages application

Important: This component is included in the iEVC ETCS kit[ci]

11.26.1 Description

The ETCS messages application[ci] performs the transformation of packet message received from SFM[ci] or
iBTM application[ci] into data structure that contains unpacked data as expected by the Subset 026 application[ci].
This application also transforms data structure filled by Subset 026 application[ci] to packet messages to be sent
on Euroradio (via SFM[ci]) or to the JRU interface.

11.26.2 Modes

No mode for this component

11.26.3 Functions

Figure 11.77: Functional architecture of the ETCS messages application

11.26.3.1 [IEVC.F3.02.08.08] Decode and encode ETCS telegrams or messages [function]

Data
• Definition: Transforms Euroradio messages or Eurobalise/Euroloop telegrams to data structure ex-
pected by the Subset 026 application. Transforms Euroradio data structure produced by the Subset
026 application to Euroradio messages. Transforms JRU data structure produced by the Subset 026
application to JRU packets to be stored in the CPM.
• Allocated to:
– ETCS messages application[ci]
• Input:

11.26. ETCS messages application 543 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– Sa-DATA.indication[functional variable][VM - Applications interface]

– Sa-HP-DATA.indication[functional variable][VM - Applications interface]
– Telegram information[functional variable]
– Train to Track Messages[functional variable]
– JRU Messages[functional variable]
• Output:
– Euroradio Track to Train Messages[functional variable]
– Balise or Loop Track to Train Messages[functional variable]
– Sa-DATA.request[functional variable][VM - Applications interface]
– JRU Log Entry[functional variable][VM - Applications interface]
– Telegram decoding error[functional variable]
– Euroradio message decoding error[functional variable]
• Sil: 4
• Associated interface:
– VM - Applications interface[ci]
• Sub functions:
– [IEVC.F3.02.08.08.01] Decode Euroradio messages[function]
– [IEVC.F3.02.08.08.02] Decode balise and loop telegrams[function]
– [IEVC.F3.02.08.08.03] Encode Euroradio messages[function]
– [IEVC.F3.02.08.08.04] Encode JRU telegrams[function]

11.26.3.1.1 [IEVC.F3.02.08.08.01] Decode Euroradio messages [function]

Data
• Definition: Transforms Euroradio messages to data structure expected by the Subset 026 application.
• Allocated to:
– ETCS messages application[ci]
• Input:
– Sa-DATA.indication[functional variable][VM - Applications interface]
– Sa-HP-DATA.indication[functional variable][VM - Applications interface]
• Output:
– Euroradio Track to Train Messages[functional variable]
– Euroradio message decoding error[functional variable]
• Sil: 4
• Associated interface:
– VM - Applications interface[ci]

544 of 750 11.26. ETCS messages application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.26.3.1.2 [IEVC.F3.02.08.08.02] Decode balise and loop telegrams [function]

Data
• Definition: Transforms Eurobalise and Euroloop telegrams to data structure expected by the Subset
026 application.
• Allocated to:
– ETCS messages application[ci]
• Input:
– Telegram information[functional variable]
• Output:
– Balise or Loop Track to Train Messages[functional variable]
– Telegram decoding error[functional variable]
• Sil: 4

11.26.3.1.3 [IEVC.F3.02.08.08.03] Encode Euroradio messages [function]

Data
• Definition: Transforms Euroradio data structure produced by the Subset 026 application to Eurora-
dio messages.
• Allocated to:
– ETCS messages application[ci]
• Input:
– Train to Track Messages[functional variable]
• Output:
– Sa-DATA.request[functional variable][VM - Applications interface]
• Sil: 4
• Associated interface:
– VM - Applications interface[ci]

11.26.3.1.4 [IEVC.F3.02.08.08.04] Encode JRU telegrams [function]

Data
• Definition: Transforms JRU data structure produced by the Subset 026 application to JRU packets
to be stored in the CPM
• Allocated to:
– ETCS messages application[ci]
• Input:
– JRU Messages[functional variable]
• Output:

11.26. ETCS messages application 545 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– JRU Log Entry[functional variable][VM - Applications interface]

• Sil: basic
• Associated interface:
– VM - Applications interface[ci]

11.26.4 Interface

The ETCS messages application[ci] uses the following interfaces:

• VM - Applications interface[ci]
The following variables are exchanged with SFM[ci]:
– Sa-DATA.request[functional variable][VM - Applications interface]
– Sa-DATA.indication[functional variable][VM - Applications interface]
– Sa-HP-DATA.indication[functional variable][VM - Applications interface]
• The following variables are received from other applications.
From iBTM application[ci]:
– Telegram information[functional variable] to be decoded to be usable by other application.
From Subset 026 application[ci]:

Functional Variable
Train to Track Messages [functional variable]
Data
– Objective: To provide messages to send on Euroradio.
– Description: Collection of data structure that contain messages to send to RBC. Each
data structure is transformed to protocol data unit.
– Family: Software
– Type: EURORADIO.RBCConnection.Data.MessageOutCol
– Format: Collection of Messages.EURORADIO.MessageOut.Message
– Timing constraints: Event
– Produced by:

* [IEVC.F3.02.08.01] Manage RBC connection[function]

– Consumed by:

* [IEVC.F3.02.08.08.03] Encode Euroradio messages[function]

* [IEVC.F3.02.08.08] Decode and encode ETCS telegrams or messages[function]

This variable is defined as a Collection Of ( <Messages.EURORADIO.MessageOut.Message> )

The structure <Messages.EURORADIO.MessageOut.Message> is an unpacked version of each Eu-
roradio train to track message type with a specific destination RBC and system version.

546 of 750 11.26. ETCS messages application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
JRU Messages [functional variable]
Data
– Objective: To provide information to store as juridical data.
– Description: Data structure that contains JRU data to record.
– Family: Software
– Type: Messages.JRU.MESSAGE.Message
– Format: Messages.JRU.MESSAGE.Message
– Timing constraints: Event
– Produced by:

* [IEVC.F3.02.13.01] Compute JRU data[function]

– Consumed by:

* [IEVC.F3.02.08.08.04] Encode JRU telegrams[function]

* [IEVC.F3.02.08.08] Decode and encode ETCS telegrams or messages[function]

This variable is defined as a Collection Of ( <Messages.JRU.MESSAGE.Message> ).

The structure <Messages.JRU.MESSAGE.Message> contains an unpacked version of each JRU
message type and for each system version.

• The following variables are transmitted to other applications.

To Subset 026 application[ci]:

Functional Variable
Euroradio Track to Train Messages [functional variable]
Data
– Objective: To provide decoded messages received from Euroradio.
– Description: Collection of data structure containing the received Euroradio informa-
tion.
– Family: Software
– Type: Messages.EURORADIO.MessageIn.Message
– Format: Collection of Messages.EURORADIO.MessageIn.Message
– Timing constraints: Event
– Produced by:

* [IEVC.F3.02.08.08.01] Decode Euroradio messages[function]

* [IEVC.F3.02.08.08] Decode and encode ETCS telegrams or messages[function]
– Consumed by:

* [IEVC.F3.02.08.01] Manage RBC connection[function]

This variable is defined as a Collection Of ( <Messages.EURORADIO.MessageIn.Message> ).

11.26. ETCS messages application 547 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The structure <Messages.EURORADIO.MessageIn.Message> contains an unpacked version of

each Euroradio track to train message type and for each system version.

Functional Variable
Balise or Loop Track to Train Messages [functional variable]
Data
– Objective: To provide decoded telegram received from iBTM application.
– Description: Collection of data structure containing the received telegram informa-
tion.
– Family: Software
– Type: BTMMessagesToHandle
– Format: collection of Messages.BTM.Message
– Timing constraints: Event
– Produced by:

* [IEVC.F3.02.08.08.02] Decode balise and loop telegrams[function]

* [IEVC.F3.02.08.08] Decode and encode ETCS telegrams or messages[function]
– Consumed by:

* [IEVC.F3.02.07.12] Manage ETCS telegram[function]

This variable is defined as a Collection Of ( <Messages.BTM.Message> ).

The structure <Messages.BTM.Message> contains an unpacked version of each Eu-
robalise/Euroloop message type and for each system version.

Functional Variable
Telegram decoding error [functional variable]
Data
– Objective: To provide error report from the decoding of the Eurobalise or Euroloop
telegram.
– Description: data structure that provides information about the error.
– Family: Software
– Type: TelegramDecodingError
– Format: TelegramDecodingError
– Timing constraints: Event
– Produced by:

* [IEVC.F3.02.08.08.02] Decode balise and loop telegrams[function]

* [IEVC.F3.02.08.08] Decode and encode ETCS telegrams or messages[function]
– Consumed by:

* [IEVC.F3.02.07.12] Manage ETCS telegram[function]

548 of 750 11.26. ETCS messages application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

This error report contains the telegram identification information and the context of the error de-
tected in the telegram.

Functional Variable
Euroradio message decoding error [functional variable]
Data
– Objective: To provide error report from the decoding of the Euroradio message.
– Description: data structure that provides information about the error.
– Family: Software
– Type: EuroradioMessageDecodingError
– Format: EuroradioMessageDecodingError
– Timing constraints: Event
– Produced by:

* [IEVC.F3.02.08.08.01] Decode Euroradio messages[function]

Requirement

ETCS messages application shall transform juridical data received from the Subset 026 applica-
tion to structured messages as described in Subset 027. [id:tsc-req-ievc-messages-application-encode-
jru][p1][ns]

Refer to Subset 027 for the description of the structured messages.

11.26.7 Failure modes

11.26.7.1 Fail to decode a message

When this application fails to decode a message, (due to bad checksum, or bad format), the error is re-
ported through the variables Telegram decoding error[functional variable] or Euroradio message decoding er-
ror[functional variable].

11.27 Subset 026 Application

Important: This component is included in the iEVC ETCS kit[ci]

11.27.1 Description

The Subset 026 application is the application in charge of fulfilling the ETCS functional requirements defined in
the Subset 026 and Subset 027.

11.27.2 Functions

11.27.2.1 ETCS functions

The Subset 026 application is in charge of the following system-level functions directly:
• [IEVC.F3.02.01] Manage Data entry[function]
• [IEVC.F3.02.02] Select Supervision mode on the basis of information from trackside[function]
• [IEVC.F3.02.04] Compute the dynamic speed profile[function]
• [IEVC.F3.02.05] Supervise the dynamic speed profile[function]
• [IEVC.F3.02.06] Provide the intervention function[function]
• [IEVC.F3.02.12] Manage equipment health and degraded modes[function]
• [IEVC.F3.02.10] Communicate with the STM[function]

550 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.27.2.2 Odometry interface functions

11.27.2.2.1 [IEVC.F3.02.03.11] Extract confidence interval reset information from the linking in-
formation [function]

Data
• Definition: If a new reference balise group is accepted by Subset 026, it extracts the confidence
interval reset information from the linking information and provides it to the odometry application.
• Allocated to:
– Subset 026 application[ci]
• Output:
– Confidence interval reset order[functional variable]
• Sil: 4

11.27.2.2.2 [IEVC.F3.02.03.12] Manage information from odometry application [function]

Data
• Definition: The Subset 026 application receives the updates from the odometry application of the
speed, distance and acceleration estimates of the train. These updates are used by its supervision
functions. It also receives the alarms raised by the odometry application. These alarms allow the
function to trigger a safe reaction in case of critical failure.
• Allocated to:
– Subset 026 application[ci]
• Input:
– Odometry information message[functional variable]
– Odometry Alarms[functional variable]
• Sil: 4

11.27.2.3 DMI interface function

11.27.2.3.1 [IEVC.F3.02.09.07] Manage ETCS DMI [function]

Data
• Definition: The Subset 026 application provides the data required for DMI display and collects the
DMI user inputs. This function is also used to exchange information related to the DMI with the
TIU application and the Odometry application (for the entry of odometry parameters).
• Allocated to:
– Subset 026 application[ci]
• Input:
– User inputs for Subset 026 application[functional variable]
– Odometry parameters validation[functional variable]
– TIU Text Messages[functional variable]

11.27. Subset 026 Application 551 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– DMI alarms[functional variable]

• Output:
– Data to display[functional variable]
– Odometry parameters[functional variable]
– Emergency Brake test button activated[functional variable]
– Active cabin[functional variable]
– DMI devices configuration[functional variable]
• Sil: 4

This function also exchanges variables with the TIU application. These variables are listed in
[SyAD-R73-SIF-Train-Generic].
When a request to enter the odometry parameters is received from the DMI user, it informs the Odometry applica-
tion of the data entry status. The Odometry application provides the DMI application with the default values and
the data check results.

11.27.2.4 Telegrams interface function

11.27.2.4.1 [IEVC.F3.02.07.12] Manage ETCS telegram [function]

Data
• Definition: The Subset 026 application processes the decoded telegram packets received from the
Eurobalise/Euroloop and Euroradio air-gaps. This function provides the iBTM application with the
Spread Spectrum Code to use to demodulate the Euroloop signal. It also provides the iBTM and
Odometry applications with the active Euroantenna information.
• Allocated to:
– Subset 026 application[ci]
• Input:
– Balise or Loop Track to Train Messages[functional variable]
– iBTM Alarms[functional variable]
– Telegram decoding error[functional variable]
• Output:
– Active Euroantenna[functional variable]
– Spread Spectrum Code[functional variable]
• Sil: 4

552 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.27.2.5 RBC interface function

11.27.2.5.1 [IEVC.F3.02.08.01] Manage RBC connection [function]

Data
• Definition: The Subset 026 application manages the level 2 GSM-R connection requests and the
associated connection parameters.
• Allocated to:
– Subset 026 application[ci]
• Input:
– Sa-PERMISSION.indication[functional variable][VM - Applications interface]
– Euroradio message decoding error[functional variable]
– Sa-CONNECT.confirm[functional variable][VM - Applications interface]
– Sa-DISCONNECT.indication[functional variable][VM - Applications interface]
– Euroradio Track to Train Messages[functional variable]
– Sa-REGISTRATION.indication[functional variable][VM - Applications interface]
– Mobile Available (From SFM)[functional variable][VM - Applications interface]
• Output:
– CS mode protocol parameter[functional variable][VM - Applications interface]
– PS mode protocol parameter[functional variable][VM - Applications interface]
– Sa-CONNECT.request[functional variable][VM - Applications interface]
– Sa-REGISTRATION.request[functional variable][VM - Applications interface]
– Sa-PERMISSION.request[functional variable][VM - Applications interface]
– Train to Track Messages[functional variable]
• Sil: 4
• Associated interface:
– VM - Applications interface[ci]

This function exchanges variables with the TIU application. These variables are listed in
[SyAD-R73-SIF-Train-Generic].

11.27.2.6 JRU function

11.27.2.6.1 [IEVC.F3.02.13.01] Compute JRU data [function]

Data
• Definition: The Subset 026 application provides the juridical data that needs to be stored inside the
Crash Protected Memory. It provides a collection of messages containing juridical data to store.
The types of messages are described in Subset 027.
• Allocated to:
– Subset 026 application[ci]
• Output:

11.27. Subset 026 Application 553 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– JRU Messages[functional variable]

• Sil: basic

11.27.3 Interfaces

• Odometry application[ci]
The Subset 026 application provides the following messages to the odometry application:
– Active Euroantenna[functional variable]
– Confidence interval reset order[functional variable]
– Odometry parameters[functional variable]

Functional Variable
Confidence interval reset order [functional variable]
Data
– Objective: To trigger odometry re-calibration by resetting the positioning confidence
interval.
– Description: The message includes the odometry information recorded when passing
the new reference balise (the estimated position and the associated sigma value) where
the confidence interval needs to be reset. It also contains the location accuracy of
the balise center (sum of the balise installation error and the balise center estimation
error).
– Family: Software
– Type: confidence_interval_reset_order
– Format: CIResetOrderStruct
– Timing constraints: Event
– Produced by:

* [IEVC.F3.02.03.11] Extract confidence interval reset information from the link-

ing information[function]
– Consumed by:

* [IEVC.F3.02.03.09] Reset confidence interval[function]

554 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

<Balise_Odo_info_position> ::= real ; estimated balise center position

˓→expressed in m

<Balise_Odo_info_sigma_position> ::= real ; odometry standard deviation

; of the estimated balise position as
; provided in the odometry information
; when the balise center location was
; passed; expressed in m
<Balise_Odo_info_reference_id> ::= int32 ; id of the reference used in
; the previous odometry information.
; In ETCS it is the NID_BG of the
; current reference balise group
˓→(CRBG).

<Balise_location_accuracy> ::= real ; Balise center location accuracy

˓→expressed in m

; it is the sum of the balise

; installation error ('Q_LOC_ACC' for
˓→ETCS)

; and the error made when estimating

; the nominal balise center location

<Balise_location_accuracy> <Balise_Odo_info_reference_id> <Balise_Odo_

˓→info_position> <Balise_Odo_info_sigma_position>

The Subset 026 application receives the following messages from the odometry application:
– Odometry information message[functional variable]
– Odometry Alarms[functional variable]
– Odometry parameters validation[functional variable]
• TIU application[ci]
The Subset 026 application exchanges the functional variables with the TIU application. These variables
are listed and defined in [SyAD-R73-SIF-Train-Generic].
• DMI application[ci]
The Subset 026 application provides the following information to the DMI application in order for it to
know the device configuration to be considered for screen activation:
– Active cabin[functional variable]
– DMI devices configuration[functional variable]
The Subset 026 application receives the following information from the DMI application:
– User inputs for Subset 026 application[functional variable]
– DMI alarms[functional variable]
• iBTM application[ci]
The Subset 026 application provides the Active Euroantenna[functional variable] information to the iBTM
application and receives the iBTM Alarms[functional variable].
• ETCS messages application[ci]
The Subset 026 application receives the following information from the ETCS Messages application:
– Balise or Loop Track to Train Messages[functional variable]
– Telegram decoding error[functional variable]
• DMI driver[ci]
The Subset 026 application provides the information to be displayed on the DMI screen directly to the DMI
driver. The following variable is used:

11.27. Subset 026 Application 555 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
Data to display [functional variable]
Data
– Objective: To provide data to update the displayed screen (window) on DMI
– Description: Set of structures that contain the parameters of the applicable DMI lay-
out (window) and a list of graphical items to display on the DMI: key (area identifier)
and value (symbol identifier).
– Family: Software
– Type: VM_screen_update
– Timing constraints: Event
– Produced by:

* [IEVC.F3.02.09.07] Manage ETCS DMI[function]

– Consumed by:

* [IEVC.F3.02.09.04] Manage DMI protocol for ETCS screens[function]

* [IEVC.F3.02.09.05] Manage DMI SIL2 protocol[function]

Refer to VM screen update[functional variable][VM - DMI interface] for the content of the variable.

11.27.4 Parameters

Functional Variable
Maintainer identifier list [functional variable]
Data
• Objective: To provide the list of Maintainer identifier
• Description: This list is used by the Subset 026 application in order to enable the mainte-
nance menu only for the user recognized as maintainer.
• Family: Software
• Type: MaintainerIDList
• Format: MaintainerIDList
• Protocol: System Parameter

<Maintainer_ID> ::= 16*byte ; As defined in Subset 027

<MaintainerIDList> ::= [<Maintainer_ID>]

556 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.27.5 Requirements

11.27.5.1 General requirements

Requirement

The Subset 026 Application shall order a confidence interval reset to the odometry application based
on the linking information available on-board. [id:tsc-req-ievc-ss26-app-odo-reset][p1][s]

Requirement

The Subset 026 Application shall manage the odometry information provided by the odometry ap-
plication according to subset 026. [id:tsc-req-ievc-ss26-app-odo-data][p1][s]

Requirement

The signalling Application shall apply a service brake until standstill when a critical alarm is raised
by the odometry application. [id:tsc-req-ievc-ss26-app-odo-critical-failure][p1][s]

Refer to the ‘Odometry fault map’ for the identification of the critical alarms.
The service brake shall be released once no more critical failure is present while the train is at standstill.

Requirement

The signalling Application shall apply a service brake until standstill when a critical alarm is raised
by the iBTM application. [id:tsc-req-ievc-ss26-app-ibtm-alarm][p1][s]

Refer to the ‘iBTM fault map’ for the identification of the critical alarms
The service brake shall be released once no more critical failure is present while the train is at standstill.

Requirement

The signalling Application shall apply a service brake until standstill when a critical alarm is raised
by the TIU application. [id:tsc-req-ievc-ss26-app-tiu-critical-failure][p1][s]

Refer to the ‘TIU fault map’ for the identification of the critical alarms.
The service brake shall be released once no more critical failure is present while the train is at standstill.

Requirement

The Subset 026 application shall consider the Tele-powering detection error as a ‘balise transmission
alarm’ (as defined in the Subset-026 specification) and shall manage it according to the requirements
of Subset-026 §3.15.7. [id:tsc-req-ievc-ss26-app-ibtm-alarm-and-bmm-tc][p1][s]

Tele-powering detection alarms may be ignored when inside a track condition of type Big Metal Masses
(BMM) or in levels 0 or NTC for a defined distance.

Requirement

The Subset 026 Application shall apply a service brake until standstill when all the DMI devices
related to the current active cabin are failed. [id:tsc-req-ievc-ss26-app-dmi-alarm][p1][s]

11.27. Subset 026 Application 557 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The service brake shall be released once the display function is restored while the train is at
standstill.

Requirement

The signalling Application shall display a warning message to the driver when a warning alarm is
raised by the odometry application due to a too long failure or too long measurement delay for one
of the speed sensors. [id:tsc-req-ievc-ss26-app-odo-warning-failure][p1][s]

Requirement

The Subset 026 Application shall manage the application data of the ETCS messages received from
the trackside devices according to subset 026. [id:tsc-req-ievc-ss26-app-etcs-messages][p1][s]

The related requirements are those of §3.4, §3.10, §3.16, §6, §7 and §8 in the Subset 026 specification.

Requirement

The Subset 026 Application shall manage the RBC connection according to Subset 026. [id:tsc-req-
ievc-ss26-app-rbc-connection][p1][s]

The requirements related to RBC connection management are those of §3.5 in the Subset 026 specification.

Requirement

During the start of mission the Subset 026 Application shall update the list of levels available
on-board based on the mobile terminal availability. [id:tsc-req-ievc-ss26-app-rbc-connection-mobile-
availability][p1][ns]

Levels 2 and 3 shall not be proposed during start of mission if none of the mobile terminals are available.
This level inhibition is allowed only during start of mission. The problematic scenario during a mission
is the following: Transition to level 2 is announced to the driver. Then the mobile terminals become not
available for use before the execution of transition. In that case a NTC level may be used as fallback in
the execution. This may be misleading for the driver who may think that transition to level 2 was executed
based on the announcement while the train is actually under NTC supervision (that is until he realizes that
the actual current level icon displayed is NTC) .

Requirement

The Subset 026 Application shall comply with the conditions and constraints of annex A of Subset-
037 when using the SFM services. [id:tsc-req-ievc-ss26-app-sfm-constraints][p1][s]

Requirement

The Subset 026 Application shall compute the juridical data to log in compliance with Subset 027.
[id:tsc-req-ievc-ss26-app-jru-data][p1][ns]

Requirement

The Subset 026 Application shall manage the train data and including the train data to be entered
on the DMI according to Subset 026. [id:tsc-req-ievc-ss26-app-train-data][p1][ns]

The related requirements are those of §3.7 and §3.18 in the Subset 026 specification.

558 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The Subset 026 Application shall select the supervision mode on the basis of information from track-
side and from the driver according to Subset 026. [id:tsc-req-ievc-ss26-app-etcs-mode][p1][s]

The related requirements are those of §4 and §5 in the Subset 026 specification.

Requirement

The Subset 026 Application shall compute the train dynamic speed profile according to Subset 026.
[id:tsc-req-ievc-ss26-app-speed-profile][p1][s]

The related requirements are those of §3.8, §3.9, §3.11, §3.12 and §3.15 in the Subset 026 specification.

Requirement

The Subset 026 Application shall supervise the train dynamic speed profile according to Subset 026.
[id:tsc-req-ievc-ss26-app-supervision][p1][s]

The related requirements are those of §3.6 and §3.13 in the Subset 026 specification.

Requirement

The Subset 026 Application shall command a brake intervention when required according to Subset
026. [id:tsc-req-ievc-ss26-app-braking][p1][s]

The related requirements are those of §3.14 in the Subset 026 specification.

Requirement

The Subset 026 Application shall manage equipment health and degraded modes according to Sub-
set 026. [id:tsc-req-ievc-ss26-app-degraded-modes][p1][ns]

This requirement concerns the degraded situations described in §5 of the Subset 026 (§5.4.5, §5.5.4, §5.6.4,
§5.11.4, §5.15.3, §5.15.4).

Requirement

The Subset 026 Application shall be able to manage the communication with a class B application us-
ing the STM interface to exchange application-level data in compliance with Subset 035 and Subset
058. [id:tsc-req-ievc-ss26-app-stm-interface][p1][ns]

Requirement

The Subset 026 Application shall be compliant to the Subset 026, the Subset 034, the Subset 076 and
the Subset 104. [id:tsc-req-ievc-ss26-app-subsets-compliance][p1][s]

Allocate
Allocation of driver cab change requirement to Subset 026. [allocate]

11.27. Subset 026 Application 559 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-driver-change-cab-while-moving[req]
• Ci:
– Subset 026 application[ci]
• Function:
– [IEVC.F3.02.02] Select Supervision mode on the basis of information from track-
side[function]
• Justification: Subset 026 contains specific requirements for supporting this feature.

Allocate
Allocation of driver behavior requirement to the Subset 026 [allocate]
Data
• Requirement:
– tsc-req-urs-driver-behavior-recording[req]
– tsc-req-urs-ievc-record-data[req]
• Ci:
– Subset 026 application[ci]
• Function:
– [IEVC.F3.02.13.01] Compute JRU data[function]
• Justification: This is part of the JRU data, and this data is produced by the Subset 026.
Therefore, we can allocate it this requirement.

Allocate
Allocation of required levels to the Subset 026 application [allocate]
Data
• Requirement:
– tsc-req-urs-nobo-ievc-supports-etcs-l1-etcs-l2[req]
• Ci:
– Subset 026 application[ci]
• Function:
– [IEVC.F3.02.02] Select Supervision mode on the basis of information from track-
side[function]
• Justification: Level management is fully within the scope of the Subset 026.

560 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Allocate
Allocation of the URS requirement to be able to install the iEVC system on a trailing car or in a long
train configuration [allocate]
Data
• Requirement:
– tsc-req-urs-install-ievc-must-support-long-train-or-trailing-unit[req]
• Ci:
– Subset 026 application[ci]
• Function:
– [IEVC.F3.02.02] Select Supervision mode on the basis of information from track-
side[function]
• Justification: The Subset 026 application provides the Non Leading and Sleeping modes.
The train length is part of the ETCS data entry and can be modified by the driver. There will
also be a need to manage two sensor boxes on long trains.

Allocate
Allocation of the URS requirement to not impact negatively the following use cases on locomotives:
remote control, multiple unit operations, “rames encadrées” [allocate]
Data
• Requirement:
– tsc-req-urs-install-ievc-no-impact[req]
• Ci:
– Subset 026 application[ci]
• Function:
– [IEVC.F3.02.02] Select Supervision mode on the basis of information from track-
side[function]
• Justification: The Subset 026 application provides the Non Leading and Sleeping modes.

Allocate
Allocation of the Subset 040 requirement about the use of Packet 145 (Inhibition of balise group,
message consistency reaction) [allocate]

11.27. Subset 026 Application 561 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-subset-040-4-2-4-1[req]
• Ci:
– Subset 026 application[ci]
• Function:
– [IEVC.F3.02.02] Select Supervision mode on the basis of information from track-
side[function]
• Justification: The Subset 026 application can verify this constraint in the telegram informa-
tion

Allocate
Allocation of the Subset 040 requirement about the use of packet 49 (List of balises for SH Area)
[allocate]

Data
• Requirement:
– tsc-req-subset-040-4-2-4-3[req]
• Ci:
– Subset 026 application[ci]
• Function:
– [IEVC.F3.02.02] Select Supervision mode on the basis of information from track-
side[function]
• Justification: The Subset 026 application can verify this constraint in the telegram informa-
tion

Allocate
Allocation of the Subset 040 requirement about the information provided by an infill device [allocate]
Data
• Requirement:
– tsc-req-subset-040-4-2-4-5-1[req]
– tsc-req-subset-040-4-2-4-5-2[req]
– tsc-req-subset-040-6-2-1-1-1[req]
• Ci:
– Subset 026 application[ci]
• Function:
– [IEVC.F3.02.02] Select Supervision mode on the basis of information from track-
side[function]
• Justification: The Subset 026 application can verify this constraint in the telegram informa-
tion

562 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Allocate
Allocation of the Subset 040 requirement about the Mode Profile information provided in the air-gap
[allocate]

Data
• Requirement:
– tsc-req-subset-040-4-2-4-6-1[req]
– tsc-req-subset-040-4-2-4-6-2[req]
– tsc-req-subset-040-6-2-1-2-1[req]
• Ci:
– Subset 026 application[ci]
• Function:
– [IEVC.F3.02.02] Select Supervision mode on the basis of information from track-
side[function]
• Justification: The Subset 026 application can verify this constraint in the telegram informa-
tion

Allocate
Allocation of the Subset 040 requirement about consistency in several air-gap packets [allocate]
Data
• Requirement:
– tsc-req-subset-040-4-2-4-10[req]
– tsc-req-subset-040-4-2-4-11[req]
– tsc-req-subset-040-4-2-4-13[req]
– tsc-req-subset-040-4-2-4-14[req]
• Ci:
– Subset 026 application[ci]
• Function:
– [IEVC.F3.02.02] Select Supervision mode on the basis of information from track-
side[function]
• Justification: The Subset 026 application can verify this constraint in the telegram informa-
tion

Allocate
Allocation of the Subset 040 requirement about maximum values of ‘N_ITER’ in telegram informa-
tion [allocate]

11.27. Subset 026 Application 563 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-subset-040-4-3-2-1-1-a[req]
– tsc-req-subset-040-4-3-2-1-1-b[req]
– tsc-req-subset-040-4-3-2-1-1-c[req]
– tsc-req-subset-040-4-3-2-1-1-d[req]
– tsc-req-subset-040-4-3-2-1-1-e[req]
– tsc-req-subset-040-4-3-2-1-1-f[req]
– tsc-req-subset-040-4-3-2-1-1-g[req]
– tsc-req-subset-040-4-3-2-1-1-h[req]
– tsc-req-subset-040-4-3-2-1-1-i[req]
– tsc-req-subset-040-4-3-2-1-1-j[req]
– tsc-req-subset-040-4-3-2-1-1-k[req]
– tsc-req-subset-040-4-3-2-1-1-l[req]
– tsc-req-subset-040-4-3-2-1-1-m[req]
– tsc-req-subset-040-4-3-2-1-1-o[req]
– tsc-req-subset-040-4-3-2-1-1-p[req]
– tsc-req-subset-040-4-3-2-1-1-q[req]
– tsc-req-subset-040-4-3-2-1-1-r[req]
– tsc-req-subset-040-4-3-2-1-1-s[req]
– tsc-req-subset-040-4-3-2-1-1-t[req]
– tsc-req-subset-040-4-3-2-1-1-u[req]
– tsc-req-subset-040-4-3-2-1-1-k[req]
– tsc-req-subset-040-4-3-2-1-1-k[req]
– tsc-req-subset-040-4-3-2-1-1-x[req]
– tsc-req-subset-040-4-3-2-1-1-v[req]
– tsc-req-subset-040-4-3-2-1-1-w[req]
– tsc-req-subset-040-6-3-1-1[req]
• Ci:
– Subset 026 application[ci]
• Function:
– [IEVC.F3.02.02] Select Supervision mode on the basis of information from track-
side[function]
• Justification: The Subset 026 application shall implement a verification of the maximum
number of iterations in 1 packet and shall memorize at least the minimum quantity provided
by the rule.

564 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Allocate
Allocation of the Subset 040 requirement about the check of data from driver input [allocate]
Data
• Requirement:
– tsc-req-subset-040-4-4-3[req]
• Ci:
– Subset 026 application[ci]
• Function:
– [IEVC.F3.02.01] Manage Data entry[function]
• Justification: The Subset 026 application is in charge of the verification of the driver input
data range

This shall apply to the ETCS, STM train data as well as to DMI settings.

Requirement

The Subset 026 application shall allow configuring default values that are used as default input field
value during data entry. [id:tsc-req-ievc-subset026app-default-data-entry-values][p1][ns]

This shall apply to the ETCS, STM train data as well as to DMI settings.

Requirement

The Subset 026 application shall provide the last stored luminance value to all the DMI units so that
their DMI software can use this value as default value during start-up or when the DMI screen is
activated. [id:tsc-req-ievc-subset026app-stored-luminance-1][p1][ns]

568 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

Each time the luminance value is modified on a DMI, the Subset 026 application shall store the new
value in a non volatile memory in order to re-use it at next iEVC start-up or when the DMI screen
is activated. [id:tsc-req-ievc-subset026app-stored-luminance-2][p1][ns]

Requirement

The Subset 026 application shall provide the last stored volume value to all the DMI units so that
their DMI software can use this value as default value during start-up or when the DMI screen is
activated. [id:tsc-req-ievc-subset026app-stored-volume-1][p1][ns]

Requirement

Each time the volume value is modified on a DMI, the Subset 026 application shall store the new
value in a non volatile memory in order to re-use it at next iEVC start-up. [id:tsc-req-ievc-subset026app-
stored-volume-2][p1][ns]

Requirement

The Subset 026 application shall provide the last stored Language value to all the DMI units so that
their DMI software can use this value as default value during start-up or when the DMI screen is
activated. [id:tsc-req-ievc-subset026app-stored-language-1][p1][ns]

Requirement

Each time the language is modified on a DMI, the Subset 026 application shall store the new value in
a non volatile memory in order to re-use it at next iEVC start-up. [id:tsc-req-ievc-subset026app-stored-
language-2][p1][ns]

Requirement

The Subset 026 application shall request the display of the [Close] button to the DMI software
whenever required in the current window. [id:tsc-req-ievc-subset026app-close-button][p1][ns]

Requirement

Each time a driver’s acknowledgement needs to be displayed, the Subset 026 application shall pro-
vide the DMI software with a display request. [id:tsc-req-ievc-subset026app-ack-display-request][p1][ns]

Specific requests are used for the following types of acknowledgement:

• brake release acknowledgement
• Level announcement acknowledgement
• Mode announcement acknowledgement
• Text message acknowledgement

Requirement

When the subset 026 application receives an acknowledgement confirmation from the DMI software
it shall revoke the corresponding display request [id:tsc-req-ievc-subset026app-ack-remove][p1][ns]

11.27. Subset 026 Application 569 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

Each time a driver’s acknowledgement needs to be displayed, the Subset 026 application shall re-
quest the DMI software to play the ‘Sinfo’ sound. [id:tsc-req-ievc-subset026app-ack-sinfo][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the train speed pointer color
based on Table 8 in ERA_ERTMS_015560 v360. [id:tsc-req-ievc-subset026app-speed-pointer-color-
request][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the Circular Speed Gauge
(CSG) elements to display with their speed value and their associated color based on Table 8 in
ERA_ERTMS_015560 v360. [id:tsc-req-ievc-subset026app-csg-info][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the information whether the Speed
Hook(s) must be displayed for ‘Vperm’ and ‘Vtarget’ with their associated color based on Table 10
in ERA_ERTMS_015560 v360. [id:tsc-req-ievc-subset026app-basic-speed-hook][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the display information for the
graphical presentation of the Release speed based on Table 9 in ERA_ERTMS_015560 v360. [id:tsc-
req-ievc-subset026app-release-speed-csg][p1][ns]

The display request includes the color and speed value to use.

Requirement

The Subset 026 application shall provide the DMI software with the display information for the
digital presentation of the Release speed with a number in medium grey based on Table 11 in
ERA_ERTMS_015560 v360. [id:tsc-req-ievc-subset026app-release-speed-digital][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the display request for the LSSMA.
[id:tsc-req-ievc-subset026app-lssma][p1][ns]

The display request includes the LSSMA speed value to use.

Requirement

The Subset 026 application shall provide the DMI software with a display request for the distance to
target bar and scale according to table 13 in ERA_ERTMS_015560 v360. [id:tsc-req-ievc-subset026app-
distance-to-target-request][p1][ns]

The display request includes the distance value to use.

570 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The Subset 026 application shall provide the DMI software with a display request for the distance
to target digital according to table 14 in ERA_ERTMS_015560 v360. [id:tsc-req-ievc-subset026app-
distance-to-target-digital-request][p1][ns]

Requirement

The Subset 026 application shall manage the activation of the speed/distance information toggling
function and provide the DMI software with the activation status of this function. [id:tsc-req-ievc-
subset026app-speed-distance-toggling-function-activation][p1][ns]

This allows the DMI software to know when to display the associated toggling button (for soft key tech-
nology DMI) or to when to make area A and area B sensitive (for touchscreen technology DMI).

Requirement

When the speed/distance toggling function is active, the Subset 026 application shall request dis-
play of the related objects according to Table 15 in ERA_ERTMS_015560 v360. [id:tsc-req-ievc-
subset026app-speed-distance-toggling-objects-vs-mode][p1][ns]

Requirement

When the speed/distance information toggling function is active and when a toggle request is re-
ceived from the DMI software, the Subset 026 application shall update the display request of the
speed/distance information based on the updated toggling status (either On or Off). [id:tsc-req-ievc-
subset026app-speed-distance-toggling-display-request-update][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with a display request for the Time To
Indication (TTI) according to Table 15a in ERA_ERTMS_015560 v360. [id:tsc-req-ievc-subset026app-
tti-request][p1][ns]

The display request includes the Time To Indication value to be used for the display.

Requirement

The Subset 026 application shall provide the DMI software with a display request for the current
ERTMS/ETCS mode. [id:tsc-req-ievc-subset026app-ertms-etcs-mode-request][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with a display request for the ‘active
override’ symbol as long as the override function is active. [id:tsc-req-ievc-subset026app-active-override-
request][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with a display request for the current
ERTMS/ETCS level when this level is valid and equal to 0, NTC (except in the modes SN and NL),
1, 2 or 3. [id:tsc-req-ievc-subset026app-level-request][p1][ns]

11.27. Subset 026 Application 571 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

In NTC level, the NTC identifier is also used by the DMI software to select the NTC default window to
display.

Requirement

When an acknowledgement is required for the ERTMS/ETCS level announcement symbol, as long
as the train has not yet reached the trackside location from where the acknowledgement is required
or as soon as the ERTMS/ETCS level announcement is acknowledged, the Subset 026 application
shall request the display of the ERTMS/ETCS level announcement symbol without acknowledge-
ment. [id:tsc-req-ievc-subset026app-level-announcement-ack-request][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with a display request for the track
ahead free information [id:tsc-req-ievc-subset026app-taf-request][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with a display request for the text mes-
sage information [id:tsc-req-ievc-subset026app-text-msg][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the the display request for the
orders and announcements of track conditions (in area B3/4/5). [id:tsc-req-ievc-subset026app-track-
conditions-b3-b4-b5-request][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the order in which the orders and
announcements of track conditions must be displayed in area B3/4/5. [id:tsc-req-ievc-subset026app-
track-conditions-b3-b4-b5-order][p1][ns]

The first, second and third object correspond respectively to the area B3, B4 and B5. When an area is
already displaying a symbol, the next area shall be used. When all areas are already displaying symbols,
any further objects to be displayed shall wait that B3, B4 or B5 is free.

Requirement

The Subset 026 application shall provide the DMI software with the display request of the tun-
nel stopping area and its associated remaining distance. [id:tsc-req-ievc-subset026app-tunnel-stopping-
request][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the activation status of the
tunnel stopping area toggling function. [id:tsc-req-ievc-subset026app-tunnel-stopping-toggling-function-
activation][p1][ns]

This allows the DMI software to know when to display the associated toggling button (for soft key tech-
nology DMI) or to when to make C2/C3/C4 area sensitive (for touchscreen technology DMI).

572 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

When the tunnel stopping area toggling function is active and when a toggle request is received from
the DMI software, the Subset 026 application shall update the display request of the tunnel stopping
area based on the updated toggling status (On or Off). [id:tsc-req-ievc-subset026app-tunnel-stopping-
toggling-update][p1][ns]

Requirement

When the entering the condition in which the tunnel stopping area toggling function becomes ac-
tive, the Subset 026 shall consider a ‘toggle off’ status by default. [id:tsc-req-ievc-subset026app-tunnel-
stopping-toggling-default][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the request to display the adhesion
factor “slippery rail” symbol. [id:tsc-req-ievc-subset026app-adhesion-request][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the request to display the level
crossing “not protected” symbol. [id:tsc-req-ievc-subset026app-lx-request][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the order for the display of the
track conditions announcements and orders in areas B3/4/5. [id:tsc-req-ievc-subset026app-tc-display-
order][p1][ns]

The placement of the objects is from left to right filling B3/4/5. When an area is already displaying a
symbol, the next area shall be used. When all areas are already displaying symbols, any further objects to
be displayed shall wait that B3, B4 or B5 is free.

Requirement

The Subset 026 application shall provide the DMI software with the request to display the Set Speed
indication together with the speed value to use. [id:tsc-req-ievc-subset026app-set-speed-request][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the display request for the planning
information if one of the following conditions is met: (a) the current mode is FS, (b) the current mode
is OS and the speed and distance monitoring information is toggled on. [id:tsc-req-ievc-subset026app-
planning-area-display-request][p1][ns]

Requirement

When the planning information must be displayed, the Subset 026 application shall provide the
DMI software with the following information: (a) the orders and announcements of track condi-
tions (excluding tunnel stopping areas), (b) the gradient profile, (c) the speed profile discontinuity
information, (d) the Planning Area Speed Profile (PASP), (e) the indication marker location [id:tsc-
req-ievc-subset026app-planning-area-information][p1][ns]

The distance scale is controlled via the zoom function that is managed by the DMI software.

11.27. Subset 026 Application 573 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The Subset 026 application shall provide the DMI software with the request to display the Safe radio
connection indication. [id:tsc-req-ievc-subset026app-safe-radio-connection-request][p1][ns]

The display request includes the state of the Safe radio connection:
• Connection Up
• Connection Lost/Set-Up failed

Requirement

When the train is at standstill inside a reversing area, the Subset 026 application shall request the
display of the indication that reversing is permitted. [id:tsc-req-ievc-subset026app-reversing-permitted-
request][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the local time indication. [id:tsc-
req-ievc-subset026app-local-time-request][p1][ns]

Requirement

The Subset 026 application shall provide the DMI software with the activation status of
the geographical position toggling function. [id:tsc-req-ievc-subset026app-geo-pos-toggling-function-
activation][p1][ns]

This allows the DMI software to know when to display the associated toggling button (for soft key tech-
nology DMI) or to when to make G12 area sensitive (for touchscreen technology DMI).

Requirement

The Subset 026 application shall activate the geographical position toggling function and provide
the DMI software with the display request of the geographical position only when the geographical
position of the train is known by the onboard. [id:tsc-req-ievc-subset026app-geo-pos-request][p1][ns]

The display request contains the geographical position data.

Requirement

When the geographical position toggling function is active, and when a toggle request is received
from the DMI software, the Subset 026 application shall update the display request of the geograph-
ical position based on the updated toggling status (On or Off). [id:tsc-req-ievc-subset026app-geo-pos-
toggling-update][p1][ns]

Requirement

When the entering the condition in which the geographical position toggling function becomes ac-
tive, and when no last status of the toggle on/off is available, the Subset 026 shall consider a toggle
of status by default. [id:tsc-req-ievc-subset026app-geo-pos-toggling-default][p1][ns]

574 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The Subset 026 application shall inform the DMI software of the display status of the sub-level
windows buttons. [id:tsc-req-ievc-subset026app-button-activation-request][p1][ns]

The display status can be one of the following:

a) ‘Enabled’ when the button is displayed and may be pressed by the user;
b) ‘Disabled’ when the button is displayed but cannot be pressed by the user;
c) ‘Hidden’ when the button cannot be displayed.
The list of window buttons for which the display status is controlled by the Subset 026 application is
provided in Virtual Machine DMI Interface Specification.
The DMI software manages which button is supposed to be present in a specific window. When a button
is not supposed to be displayed in a specific window, then it is not displayed by the DMI software even if
the display status provided by the Subset 026 application is ‘Enabled’ or ‘Disabled’.
When a button is supposed to be displayed in a specific window and the Subset 026 application reports its
display status as ‘Hidden’ then the button is not displayed by the DMI software.

Requirement

The 5 buttons for sub-level window selection in the default window shall always be ‘enabled’.
[id:tsc-req-ievc-subset026app-button-activation-default-window][p1][ns]

Requirement

The navigation from the default window to sub-level windows shall be managed by the Subset 026
according to Table 18 in ERA_ERTMS_015560 v360 and based on the user requests (button pressed)
provided by the DMI software. [id:tsc-req-ievc-subset026app-window-request][p1][ns]

The list of windows for which the display is controlled by the Subset 026 application is provided in Virtual
Machine DMI Interface Specification.
The navigation from the ‘Fault window’ or from the ‘Maintenance window’ to eventual sub-level windows
is not managed by the Subset 026 application. This specific navigation is managed by the OBOM.

Requirement

The Subset 026 application shall manage the display of the odometry parameters entry and valida-
tion windows on the DMI. [id:tsc-req-ievc-ob-odo-param-entry-management][p1][ns]

Requirement

When displaying a data entry or a data validation window, the Subset 026 application shall provide
to the DMI software with the data part for each data echo text to display on the DMI. [id:tsc-req-ievc-
subset026app-echo-text-data-part-request][p1][ns]

The label part of the echo text is selected by the DMI software in its configuration data based on the
information provided by the Subset 026 application.
Special values are used to indicate when there is no echo text to display. In case of data check failure,
the DMI software replaces the data part of the echo text with ‘????’ or ‘++++’ according to the rules of
section 10.3.4 in ERA_ERTMS_015560 v360.

11.27. Subset 026 Application 575 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The Subset 026 application shall allow to configure the permitted range of each train data that can
be entered on the DMI. [id:tsc-req-ievc-subset026app-technical-range-check-in-configuration][p1][ns]

Requirement

The Subset 026 application shall allow to call specific check functions contained in one or several
specific installation project applications in order to realize: (a) technical cross-check on train data,
(b) operational checks on train data, (c) any type of check on the SR speed / distance or set VBC
data. [id:tsc-req-ievc-subset026app-data-check-external-call][p1][ns]

The checks on the NTC data are made by the class B application.

Note: the interface that allows these external check calls will be defined in a later version of this docu-
ment.

Requirement

The Subset 026 application shall trigger technical range check on a data value once it has been
accepted by the driver. [id:tsc-req-ievc-subset026app-technical-range-check-timing][p1][ns]

The technical range check concerns: - train data - SR speed / distance - Set VBC - Remove VBC - NTC
X data - Odometry parameters
A data is considered as accepted by the driver when the corresponding variable ‘[data_name] _Accepted-
ByDriver’ is set to true by the DMI software (see ‘Virtual Machine - DMI interface specification’).

Requirement

The Subset 026 application shall trigger technical resolution check on a data value once it has been
accepted by the driver. [id:tsc-req-ievc-subset026app-technical-resolution-check-timing][p1][ns]

The technical resolution check concerns: - train data - SR speed / distance - NTC X data - Odometry
parameters
A data is considered as accepted by the driver when the corresponding variable ‘[data_name] _Accepted-
ByDriver’ is set to true by the DMI software (see ‘Virtual Machine - DMI interface specification’).

Requirement

The Subset 026 application shall trigger technical cross-check on the data values accepted by
the driver once a valid button activation is performed on the ‘Yes’ button attached to the ques-
tion‘[Window Title] entry complete?’ [id:tsc-req-ievc-subset026app-technical-cross-check-timing][p1][ns]

The technical cross-check concerns: - train data - SR speed / distance - NTC X data - Odometry parameters
(in case several values must be entered)
When a valid button activation is performed on the ‘Yes’ button attached to the question‘[Window Title]
entry complete?’, the DMI software provides the variable ‘data_entry_complete’ with value ‘true’ to the
Subset 026 application (see ‘Virtual Machine - DMI interface specification’).

576 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

If an operational range check is required on a data, the Subset 026 application shall trigger this
range check on the data value accepted by the driver only if the technical range check is satisfied
[id:tsc-req-ievc-subset026app-operational-range-check-timing][p1][ns]

The operational range check concerns: - train data - SR speed / distance - Set VBC - Remove VB -
Odometry parameters (in case several values must be entered)
A data is considered as accepted by the driver when the corresponding variable ‘[data_name] _Accepted-
ByDriver’ is set to true by the DMI software (see ‘Virtual Machine - DMI interface specification’).

Requirement

If an operational cross-check is required on the accepted data values, the Subset 026 application
shall trigger this operational cross-check when a valid button activation is performed on the ‘Yes’
button attached to the question ‘[Window Title] entry complete?’, and only if the technical cross-
check is satisfied. [id:tsc-req-ievc-subset026app-operational-cross-check-timing][p1][ns]

The operational cross-check concerns: - train data - SR speed / distance - Odometry parameters (in case
several values must be entered)
When a valid button activation is performed on the ‘Yes’ button attached to the question‘[Window Title]
entry complete?’, the DMI software provides the variable ‘data_entry_complete’ with value ‘true’ to the
Subset 026 application (see ‘Virtual Machine - DMI interface specification’).

Requirement

Concerning the check of the Odometry parameters, the Subset 026 application shall provides the
values to be checked to the odometry application. [id:tsc-req-ievc-subset026app-odometry-parameters-
check-by-odo-app][p1][ns]

Requirement

Once a data check is performed on an accepted data value or on a set of data values, the Subset
026 application shall provide the DMI software with the check result for each data. [id:tsc-req-ievc-
subset026app-data-check-result][p1][ns]

Requirement

In the Settings window, the ‘EB test’ and ‘Fault’ buttons shall be enabled when the train is at stand-
still. [id:tsc-req-ievc-subset026app-eb-test-and-fault-button-activation][p1][ns]

Requirement

In the Settings window, the Maintenance button shall be enabled when the Driver ID is valid, AND
the valid Driver ID corresponds to a special Driver ID value configured in the Subset 026 application.
[id:tsc-req-ievc-subset026app-maintenance-button-activation][p1][ns]

The special value of Driver ID allows restricting the access to the Maintenance sub-level windows only to
the maintainers.

Requirement

In the Settings window, the Odometry parameters button shall be enabled when the train is at
standstill, AND when the Driver ID is valid, AND the valid Driver ID corresponds to a special

11.27. Subset 026 Application 577 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Driver ID value configured in the Subset 026 application. [id:tsc-req-ievc-subset026app-odo-parameters-

button-activation][p1][ns]

The special value of Driver ID allows restricting the access to the Odometry parameters entry windows
only to the maintainers.

Requirement

When data entry window must be displayed, the Subset 026 application shall provide the DMI
software with default values to use in the input fields. [id:tsc-req-ievc-subset026app-data-entry-default-
value-info][p1][ns]

Specific values are used to indicate that there is no default value to display; the input field of the data entry
window remains empty in this case when the window is displayed.
This requirement is applicable for the following entry windows:
• Train running number window
• ERTMS/ETCS level window
• Driver ID window
• Radio Network ID window,
• RBC data window
• Train data window(s)
• SR speed / distance window
• Adhesion window
• NTC X data window
• Odometry parameters window

Requirement

When the ERTMS/ETCS level window must be displayed, the Subset 026 application shall provide
the DMI software with a list of ERTMS/ETCS levels and with the status of their associated buttons.
[id:tsc-req-ievc-subset026app-ertms-etcs-level-list][p1][ns]

The DMI software uses the list of levels to build a dedicated keyboard list for the ERTMS/ETCS level
input field. A button activation status is provided for each of the buttons associated to an entry of this
keyboard list. The list of levels contains the levels 0/1/2/3 and the NTC levels that are configured in the
Subset026 application.

Requirement

When a table of priority of trackside supported levels is available onboard, the Subset 026 applica-
tion shall only enable the buttons associated to the ERTMS/ETCS levels in that list. The other level
buttons shall be disabled. [id:tsc-req-ievc-subset026app-ertms-etcs-level-trackside-priority][p1][ns]

Requirement

When a table of priority of trackside supported levels is not available onboard, the Subset 026
application shall only enable the buttons associated to the levels configured on-board. The other
level buttons shall be disabled. [id:tsc-req-ievc-subset026app-ertms-etcs-level-list-configured][p1][ns]

578 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

When the onboard is in the step S1 of the start up dialogue sequence (see 11.7.2 in
ERA_ERTMS_015560 v360), the Driver ID window shall also present a ‘Settings’ and a
‘Train running number’ button. [id:tsc-req-ievc-subset026app-driver-id-window-settings-trn-buttons-display-
request][p1][ns]

This means that, when not in step S1, the Subset 026 application sets the activation status of these 2 buttons
to ‘Hidden’.

Requirement

When the Radio Network ID window must be displayed, the Subset 026 application shall provide
the DMI software with the list of available Radio Networks. [id:tsc-req-ievc-subset026app-network-id-
list][p1][ns]

The DMI software uses the available Networks to build a dedicated keyboard list for the Network ID input
field.

Requirement

The Subset 026 application shall provide the DMI software with the type of train data window that
needs to be used in the Train data window(s). The possible types are: Fixed train data entry or
Flexible data entry. [id:tsc-req-ievc-subset026app-train-data-entry-types][p1][ns]

When in Switchable train data entry, the layout is switched by the Subset 026 application based on the
user action on the ‘switch’ and ‘select type’ buttons. When entering the data entry screen, the selection
between the 2 layouts is based on the lastly used layout. By default the initial type at start-up is ‘flexible
data entry’.
The allowed type of train data entry is fixed through the train interface variable ‘TrainDataEntry’ (refer to
‘iEVC - Train generic interface specification’).

Requirement

When displaying Train data window(s), the Subset 026 application shall provide the DMI software
with the list of permitted values for all the data that require a dedicated keyboard. [id:tsc-req-ievc-
subset026app-train-data-entry-permitted][p1][ns]

Requirement

For Flexible train data entry method, the Subset 026 application shall allow configuring which
data require an entry by the driver and which have a fixed value. The fixed value shall also be
configurable in the Subset 026 application. [id:tsc-req-ievc-subset026app-flexible-train-data-entry-data-
included][p1][ns]

The data that requires entry using the flexible train data entry method may therefore be a subset of the data
listed in Table 40 in ERA_ERTMS_015560 v360.

Requirement

When displaying the Data view window, the Subset 026 application shall provide the DMI software
with the data values to display as specified in Table 44 for fixed train data entry, and as speci-
fied in Table 45 (these Tables are in ERA_ERTMS_015560 v360). [id:tsc-req-ievc-subset026app-data-
view][p1][ns]

11.27. Subset 026 Application 579 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

In a data view window, the data to display under the topic ‘Train data’ are only Train Data either
modifiable by the driver or modifiable by other ERTMS/ETCS external sources shall be displayed.
[id:tsc-req-ievc-subset026app-data-view-train-data-modifiable][p1][ns]

Requirement

When displaying the Data view window, the Subset 026 application shall provide the DMI software
with the information of which train data to display under the topic “Train data”. [id:tsc-req-ievc-
subset026app-data-view-train-data-display-request][p1][ns]

Requirement

When displaying the NTC data entry selection window, the Subset 026 application shall provide the
DMI software with the list of NTC for which a data entry is required. [id:tsc-req-ievc-subset026app-ntc-
data-entry-selection-list-ntc][p1][ns]

The list of NTC for which a data entry is required is composed of the NTC that are available on-board
(according to the Subset 026 application configuration data) AND that have sent ‘Specific NTC Data
Need’ information indicating that it needs Specific NTC Data (in the standard STM interface; refer to
Subset 035).

Requirement

When displaying the NTC data entry selection window, the Subset 026 application shall provide
the DMI software with the display status of the NTC buttons and including the ‘End of data entry’
button. [id:tsc-req-ievc-subset026app-ntc-data-entry-selection-buttons-activation-status][p1][ns]

A button display status is provided for each of the NTC contained in the list of NTC for which a data entry
is allowed.
The display status can be one of the following:
a) ‘Enabled’ when the button is displayed and may be pressed by the user;
b) ‘Disabled’ when the button is displayed but cannot be pressed by the user;
c) ‘Hidden’ when the button cannot be displayed.

Requirement

In the NTC data entry selection window, the NTC X button shall be ‘Enabled’ when: (a) the train
is at standstill, AND (b) Driver ID is valid AND (c) ERTMS/ETCS level is valid AND (d) mode
is SB/FS/LS/SR/OS/UN/SN AND (e) ‘Specific NTC data entry request’ has been received for this
NTC X AND (f) no ‘STOP’ flag has been sent to the STM supporting this NTC X. [id:tsc-req-ievc-
subset026app-ntc-data-entry-selection-ntc-x-button][p1][ns]

Requirement

In the NTC data entry selection window, the ‘End of data entry’ button shall be ‘Enabled’
when: (a) train is at standstill AND (b) Driver ID is valid AND (c) ERTMS/ETCS level is valid
AND (d) mode is SB/FS/LS/SR/OS/UN/SN [id:tsc-req-ievc-subset026app-ntc-data-entry-selection-end-of-
data-entry-button][p1][ns]

580 of 750 11.27. Subset 026 Application

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

When displaying NTC X data entry window, the Subset 026 application shall provide the DMI
software with the NTC ID for which the data is entered, the number of input fields, their labels,
their default values, their associated keyboards and the list of permitted values, if any. [id:tsc-req-
ievc-subset026app-ntc-data-entry-info][p1][ns]

Requirement

When entering the data view window, the Subset 026 application shall provide the DMI software
with all the data view items to display for each NTC that requires a data view window. [id:tsc-req-
ievc-subset026app-ntc-data-window-info][p1][ns]

For each of these NTC, the information includes the number of items, the data labels, values and the NTC
ID for which the data is displayed.
All the NTC information is provided at once (with the ETCS data view information). The navigation
between the data view screens is managed by the DMI software.
ETCS and NTC data view windows are considered as a same window (ETCS Data View Window) for the
Subset 026 application.

11.27.5.3 Configuration data

Requirement

When gamma trains are used in the configuration data (meaning that there are preconfigured de-
celeration models and brake build up times), the installation designer shall observe the rules of
subset 040 §4.4.1.2, §4.4.1.3, §4.4.1.4 and §4.4.1.5 to determine the emergency brake deceleration
profiles, brake build up time and rolling stock correction factors. [id:tsc-req-ievc-ss26-app-gamma-
models-rules][p1][ns]

These rules specify how the values of the deceleration models, build up time and correction factors must
be fixed. The values are set into the On-board subsystem configuration data.

Requirement

The default list of levels configured on-board shall include all the levels fitting the trackside in-
frastructures where the train has been granted access (i.e. the levels listed in the Interoperability
Registers on the concerned infrastructures). [id:tsc-req-ievc-ss26-app-configured-levels][p1][ns]

The ETCS on-board equipment must always be able to switch to a level ordered by trackside (i.e. fitting the
line where the train is), independently from the availability of the parts of the on-board equipment allowing
to support this level. In case of degraded operation, it is always the responsibility of the Infrastructure
Manager to order the level the on-board will switch to and, even though the train is not fitted with the
National System corresponding to the ordered level, to instruct the driver to follow the ad-hoc operating
rules applicable for a train with a failed National System. Therefore the so-called on-board default list of
levels is not an unilateral choice made by the Railway Undertaking based on the devices the on-board is
fitted with, but is rather a substitute of the list of trackside supported levels (packet 41) ordered by trackside
when this list is not stored on-board.

Requirement

The Subset 026 application shall verify that the ETCS_ID configured by the OBU Configuration
Data file is identical to the ETCS_ID stored in the VM. An emergency brake shall be requested

11.27. Subset 026 Application 581 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

while an inconsistency exists. [id:tsc-req-ievc-ss26-app-etcs-id][p1][ns]

11.28 SIDE Authorizer

Important: This component is included in the iEVC Basic kit[ci]

11.28.1 Description

An application package is composed of

• iEVC application files: these files include the iEVC generic application files and the installation project
specific application files. Refer to the description in iEVC Application file.
• iEVC configuration data files: refer to the description in iEVC configuration data file
• An application package descriptor file: It lists the files contained in the application package. It also include
the SHA-256 of each of these files as illustrated in Fig. 11.78. Refer to Application package descriptor file
for the other content of this file.
The application package does not include any software component other than EXS applications (e.g. no virtual
machine components like drivers, no OBOM, etc).

Figure 11.78: Application package files listing in the descriptor file

The application packages are numerically signed. Using the SIDE Authorizer. A designated privileged user of
the installation project (e.g. Safety Assurance Engineer[role] or IEVC model safety[stakeholder]) uses the private

582 of 750 11.28. SIDE Authorizer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

key of an RSA public/private key pair to produce a cryptographic certificate for each of the iEVC application
packages.
• The public key is a configuration parameter of the Virtual Machine;
• The private key, never to be shared outside of the Authorizer tool, is used to encrypt the authorized applica-
tion package signature. The resulting cypher is a valid certificate for this application package.
Certificates are then uploaded to the iEVC on-board subsystem and verified by the Virtual Machine.
An application package with its certificate are programmed into each iEVC On-board subsystem of the fleet. The
programming operation is a ‘manual’ operation using a laptop and an ethernet connection.

Note: in a later version of the system the application packages and certificates will be deployed over the air using
respectively SIDE Deploy and SIDE Authorizer.

During its initialization phase, the Virtual Machine of the Safe computer uses the public key to decrypt the available
certificate (see Virtual Machine for more information). If it matches the signature of the proposed application
package to run, then it will authorize the execution. In case of failure, execution of the application package is
denied.
The SIDE Authorizer uses the following principle to create the application package certificate:
• For each application and iEVC configuration data files in the package, compute a SHA-256 checksum;
• Verify the list of files and computed checksums are consistent with the list provided in the application
package descriptor file;
• Calculate a SHA-256 checksum of the application package descriptor file;
• Compute a signature of this SHA-256 checksum using the RSA algorithm;
• Concatenate the ETCS-ID of the iEVC on-board unit with the byte string resulting from the signature
process.
The byte string resulting from the signature process is the Application package certificate.

11.28.2 Modes

The SIDE Authorizer has no specific mode.

11.28. SIDE Authorizer 583 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.28.3 Functions

The logical architecture of the SIDE Authorizer logical architecture component is described in Fig. 11.79.

Figure 11.79: SIDE Authorizer logical architecture

11.28.3.1 [IEVC.F1.20.01] Verify the application package content [function]

Data
• Definition: The SIDE authorizer computes a SHA-256 checksum for each of the applications files
and iEVC configuration data files that need to be included in an application package. Then it com-
pares the list of files with their computed SHA-256 to the list and SHA-256 values in the Application
package descriptor file.
• Allocated to:
– SIDE Authorizer[ci]
• Input:
– Application files to include in an application package[functional variable][SIDE Authorizer
User Interface]
– iEVC configuration data files to include in an application package[functional variable][SIDE
Authorizer User Interface]
– Application package descriptor file[functional variable][SIDE Authorizer User Interface]
• Output:
– Application package verification result[functional variable][SIDE Authorizer User Interface]
– Package verified[functional variable]
• Sil: basic
• Associated interface:
– SIDE Authorizer User Interface[ci]

584 of 750 11.28. SIDE Authorizer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.28.3.2 [IEVC.F1.20.02] Compute application package certificate [function]

Data
• Definition: When the verification of the application package is successful, the SIDE authorizer
computes a SHA-256 checksum of the application package descriptor file. Then it computes a
signature of this SHA-256 using the RSA private key. The SIDE authorizer includes the byte string
resulting from the signature process in the Application package certificate file.
• Allocated to:
– SIDE Authorizer[ci]
• Input:
– Application files to include in an application package[functional variable][SIDE Authorizer
User Interface]
– iEVC configuration data files to include in an application package[functional variable][SIDE
Authorizer User Interface]
– Application package descriptor file[functional variable][SIDE Authorizer User Interface]
– Package verified[functional variable]
• Output:
– Application package certificate[functional variable][SIDE Authorizer User Interface]
• Sil: basic
• Associated interface:
– SIDE Authorizer User Interface[ci]

11.28.4 Interface

• SIDE Authorizer User Interface[ci]

This interface is the user interface of the tool. It is used by the IEVC model safety[stakeholder] or Safety
Assurance Engineer[role] to produce the application package certificate.
The user has to input the following files:

Functional Variable
Application files to include in an application package [functional variable]

11.28. SIDE Authorizer 585 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To be included in the application package that will be used for a specific
installation project and for a specific iEVC on-board subsystem in the fleet
– Description: Application in EXS format. These files contain variables and algorithms
to execute on these variables
– Family: Software
– Associated interface:

* SIDE Authorizer User Interface[ci]

– Consumed by:

* [IEVC.F1.20.01] Verify the application package content[function]

* [IEVC.F1.20.02] Compute application package certificate[function]

The detailed description of the application file format will be done during the iEVC software design
activity.

Functional Variable
iEVC configuration data files to include in an application package [functional variable]
Data
– Objective: To be included in the application package that will be used for a specific
installation project and for the specific iEVC on-board subsystem in the fleet
– Description: Application in EXS format. These files contain the generic application
configuration data.
– Family: Software
– Associated interface:

* SIDE Authorizer User Interface[ci]

– Consumed by:

* [IEVC.F1.20.01] Verify the application package content[function]

* [IEVC.F1.20.02] Compute application package certificate[function]

These files are those produced using the SIDE Configurator. See iEVC Configuration Data
Files[functional variable][SIDE Configurator User Interface] and iEVC Configuration Data files
for the format of these files.

Functional Variable
Application package descriptor file [functional variable]

586 of 750 11.28. SIDE Authorizer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To detail the applications that are to be executed by the VM
– Description: contains the list of the application and configuration data files with their
SHA-256, the VM execution sequence and the reservation of built in variables to each
application.
– Family: Software
– Associated interface:

* SIDE Authorizer User Interface[ci]

– Consumed by:

* [IEVC.F1.20.01] Verify the application package content[function]

* [IEVC.F1.20.02] Compute application package certificate[function]

The file is described in Application package descriptor file

The tool provides in output:

Functional Variable
Application package verification result [functional variable]
Data
– Objective: To inform the user about the application package verification result.
– Description: message in the user interface providing the verification result (OK/NOK)
and the reason for the failure if the verification has failed.
– Family: Software
– Associated interface:

* SIDE Authorizer User Interface[ci]

– Produced by:

* [IEVC.F1.20.01] Verify the application package content[function]

Functional Variable
Application package certificate [functional variable]

11.28. SIDE Authorizer 587 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To authorize the execution of the files contained in an application package
– Description: binary file containing the ETCS_ID of the on-board unit and a 4096
RSA signature of the application package SHA-256 signature
– Family: Software
– Associated interface:

* SIDE Authorizer User Interface[ci]

– Produced by:

* [IEVC.F5.05.02] Record data in crash protected memory[function]

* [IEVC.F1.20.02] Compute application package certificate[function]

The file is described in Applications Package Certificate file.

• Internal message
This message is used internally to the SIDE Authorizer component:

Functional Variable
Package verified [functional variable]
Data
– Objective: To allow the SIDE Authorizer to proceed with the computation of the
certificate.
– Description: boolean variable internal to the SIDE Authorizer that enables the pro-
duction of the application package certificate. This variable is reset whenever there is
a change in the inputs files (file added, removed)
– Family: Software
– Produced by:

* [IEVC.F1.20.01] Verify the application package content[function]

– Consumed by:

* [IEVC.F1.20.02] Compute application package certificate[function]

11.28.5 Parameters

The SIDE Authorizer has the RSA private key as parameter:

Functional Variable
SIDE Authorizer private key [functional variable]

588 of 750 11.28. SIDE Authorizer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To authorize the execution of the files contained in an application package
• Description: 2048 bit long byte string used to compute the certificate from the application
package SHA-256 signature.
• Family: Software
• Protocol: System parameters

A pair of private / public keys must be generated using a RSA algorithm.

11.28.6 Requirements

Requirement

The SIDE Authorizer shall compute the SHA-256 of all the files included in the application package
and verify them against the values listed content of the application package descriptor file. [id:tsc-
req-ievc-side-authorizer-descriptor][p1][s]

The application package descriptor shall verify that

• all the files in input of the tool are listed in the application package descriptor.
• all the file listed in the application package descriptor file have been provided in input of the tool
• the SHA-256 computed by the SIDE Authorizer matches the values provided by the application
package descriptor for each file included in the list

Requirement

The SIDE Authorizer shall compute the application package certificate [id:tsc-req-ievc-side-authorizer-
certificate][p1][s]

The SIDE Authorizer shall allow the computation of the certificate only when the application package
verification is successful.
The SIDE Authorizer shall:
• compute a SHA-256 checksum of the application package descriptor file.
• compute a signature of this SHA-256 using the RSA private key.
• concatenate the ETCS-ID of the iEVC on-board unit with the byte string resulting from the signature
process.
The ETCS-ID is extracted from the OBU Configuration Application file.
There is one application package and therefore one certificate for each On-board unit of the fleet.

11.28. SIDE Authorizer 589 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.28.7 Failure modes

11.28.7.1 Failure to verify the application package content

If the SIDE authorizer is not able to verify the application package, it will not compute the certificate and the
package will not be authorized to be executed by the Virtual machine.

11.28.7.2 Verification is successful while the application package content is not correct

The application package descriptor consistency with the application content and the SHA-256 will be checked
again by the Virtual Machine that will not execute the package in case of error.

11.28.7.3 Verification is failed while the application package content is correct

The application package certificate cannot be produced and the package cannot be executed on-board because the
Virtual Machine will not be able to verify the certificate. The SIDE Authorizer needs to be fixed; this is a tool
issue.

11.28.7.4 Failure to provide the application package certificate

The package cannot be executed on-board because the Virtual Machine will not be able to verify the certificate.
The SIDE Authorizer needs to be fixed; this is a tool issue.

11.28.7.5 Provide a wrong certificate (wrong value of the byte string)

The package cannot be executed on-board because the Virtual Machine will not be able to verify the certificate.
The SIDE Authorizer needs to be fixed; this is a tool issue.

11.29 SIDE Configurator

Important: This component is included in the iEVC Basic kit[ci]

11.29.1 Description

The SIDE Configurator subsystem supports the IEVC modeler[stakeholder] in the configuration of the iEVC
generic application into an installation project specific application. The IEVC modeler[stakeholder] inputs con-
figuration data values into the tool. The tool converts the data values into iEVC configuration data files. Once
validated, these files are integrated into the software package to deploy for the specific installation project.
Refer to the iEVC Configuration data section for detailed information about the iEVC configuration data, files and
associated process.
Among the iEVC Configuration Data files, the SIDE Configurator is used to prepare:
• The OBU Configuration Application files
• The Train Type Configuration Application file
An OBU Configuration Application file is specific to 1 On-board unit. One set of data and therefore one file is
required for each train in the installation project fleet. Examples of these data are the ETCS identity or the level 2
authentication keys.

590 of 750 11.29. SIDE Configurator

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The Train Type Configuration Application file contains data that are specific to one type of train. Within a type of
train the iEVC system has a unique functional scope, the On-board units have an identical interface with the train
and an identical installation design.

Note: The configuration related to the train interface is included into a project specific TIU application It is
developed as an iEVC applications.

The SIDE Configurator user interface is that of a command line tool that produces configuration files for a fleet
of trains equipped with the iEVC. The tool allows inputting the configuration data values in a tabular format by
generating an excel file containing the list of parameters and their range. Once filled in with the values, the excel
file is consumed by the tool to generate the iEVC configuration data files.
The SIDE Configurator subsystem supports the IEVC model verifier[stakeholder] in verifying that the iEVC Con-
figuration Data files contain values that are compliant with the installation project design. The SIDE Configurator
decodes the iEVC configuration Data files prepared by the IEVC model verifier[stakeholder] in a readable format.
The Train Type and OBU Configuration Application files are both in EXS format. The EXS files are decompiled
and the configuration data with their value are extracted.

Figure 11.80: Use of SIDE Configurator for Configuration Data preparation

The configuration variables are marked with a specific ‘CONFIGURATION’ type in the application model. Such
variables are configurable by application configuration files only during the initialization phase of the VM (see
function [IEVC.F1.05.06] Configure applications[function]). The VM will go to fault (VM_FAULT mode) in
case an attempt is made at writing a configuration variable otherwise.

Note: The routing mechanism of the configuration variables to the type of configuration file (OBU or Train Type)
needs to be established during software design.

11.29. SIDE Configurator 591 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.29.2 Modes

The SIDE Configurator has no specific mode.

11.29.3 Functions

The logical architecture of the SIDE Configurator component is described in Fig. 11.81.

Figure 11.81: SIDE Configurator logical architecture

11.29.3.1 [IEVC.F1.26.01] Extract configuration parameters from the generic applications [func-
tion]

Data
• Definition: The SIDE configurator takes in input the generic applications that must be configured by
the installation project and extracts the list of parameters with their allowed range for each generic
application.
• Allocated to:
– SIDE Configurator[ci]
• Input:
– Generic applications to configure[functional variable][SIDE Configurator User Interface]
• Output:
– Generic applications parameters information[functional variable]
• Sil: basic
• Associated interface:
– SIDE Configurator User Interface[ci]

All the generic applications are input at once in SIDE Configurator in order to extract all the configuration param-
eters. This is because the configuration data of several applications are included in the Train Type Configuration
Application file.

592 of 750 11.29. SIDE Configurator

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.29.3.2 [IEVC.F1.26.02] Provide tabular input interface [function]

Data
• Definition: The SIDE configurator takes in input the generic applications parameters and displays
them in a tabular format for the iEVC modeler (or the installation designer) to input the project
specific values.
• Allocated to:
– SIDE Configurator[ci]
• Input:
– Generic applications parameters information[functional variable]
– Installation project configuration data values[functional variable][SIDE Configurator User In-
terface]
• Output:
– Installation project configuration data information[functional variable][SIDE Configurator
User Interface]
– Configuration data values[functional variable]
– Invalid project configuration data values[functional variable][SIDE Configurator User Inter-
face]
• Sil: basic
• Associated interface:
– SIDE Configurator User Interface[ci]

11.29.3.3 [IEVC.F1.26.03] Generate the configuration data files [function]

Data
• Definition: The SIDE configurator creates the generic applications configuration data files based on
the configuration data values input by the iEVC modeler (or the installation project designer).
• Allocated to:
– SIDE Configurator[ci]
• Input:
– Configuration data values[functional variable]
• Output:
– iEVC Configuration Data Files[functional variable][SIDE Configurator User Interface]
• Sil: basic
• Associated interface:
– SIDE Configurator User Interface[ci]

11.29. SIDE Configurator 593 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.29.3.4 [IEVC.F1.26.04] Extract configuration data values from files [function]

Data
• Definition: The SIDE configurator transforms the configuration data information from the configu-
ration Data files prepared by the iEVC Model Verifier in a readable format.
• Allocated to:
– SIDE Configurator[ci]
• Input:
– iEVC Configuration Data Files[functional variable][SIDE Configurator User Interface]
• Output:
– Readable configuration data values[functional variable][SIDE Configurator User Interface]
• Sil: basic
• Associated interface:
– SIDE Configurator User Interface[ci]

11.29.4 Interface

• SIDE Configurator User Interface[ci]

This interface is the user interface of the tool. It is used by the IEVC model verifier[stakeholder]
and IEVC modeler[stakeholder].
Functional Variable
Generic applications to configure [functional variable]
Data
– Objective: To allow extracting information about the configuration param-
eters which values must be set by the installation project.
– Description: Application in EXS format
– Family: Software
– Associated interface:

* SIDE Configurator User Interface[ci]

– Consumed by:

* [IEVC.F1.26.01] Extract configuration parameters from the generic

applications[function]

The detailed description of the application file format will be done during the iEVC
software design activity.

Functional Variable
Installation project configuration data information [functional variable]

594 of 750 11.29. SIDE Configurator

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide the iEVC Modeler with the list of configuration data
parameters and their range and to allow him to input installation project
specific values
– Description: list of parameters and ranges displayed in tabular format
– Family: Software
– Associated interface:

* SIDE Configurator User Interface[ci]

– Produced by:

* [IEVC.F1.26.02] Provide tabular input interface[function]

Functional Variable
Invalid project configuration data values [functional variable]
Data
– Objective: To provide the iEVC Modeler with an list of errors due to in-
valid values entered
– Description: list of errors
– Family: Software
– Associated interface:

* SIDE Configurator User Interface[ci]

– Produced by:

* [IEVC.F1.26.02] Provide tabular input interface[function]

The exact format depends on the design of the user interface. This will be decided during
the detailed design of the tool.

Functional Variable
Installation project configuration data values [functional variable]
Data
– Objective: To provide configuration data values that are used to create the
iEVC Configuration Data Files
– Description: set of values that are input by the installation project into the
tabular interface of SIDE Configurator
– Family: Software
– Associated interface:

* SIDE Configurator User Interface[ci]

– Consumed by:

* [IEVC.F1.26.02] Provide tabular input interface[function]

11.29. SIDE Configurator 595 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The information includes the iEVC Modeler identifier and the installation project identi-
fier.
The exact format depends on the design of the user interface. This will be decided during
the detailed design of the tool.

Functional Variable
iEVC Configuration Data Files [functional variable]
Data
– Objective: To store the generic applications configuration data and to be
deployed on the iEVC On-board subsystems.
– Description: Files containing the generic application configuration data
– Family: Software
– Associated interface:

* SIDE Configurator User Interface[ci]

– Produced by:

* [IEVC.F5.05.02] Record data in crash protected memory[function]

* [IEVC.F1.26.03] Generate the configuration data files[function]
– Consumed by:

* [IEVC.F1.26.04] Extract configuration data values from

files[function]

These iEVC Configuration Data Files produced by SIDE Configurator are:

– The OBU Configuration Application files
– The Train Type Configuration Application file
Refer also to iEVC Configuration. In addition to the configuration data values, these files
contain also:
– the identifier of the iEVC Modeler
– the identifier of the installation project
– the date and time of the file generation
– a SHA-256 checksum
See also iEVC configuration data file.

Functional Variable
Readable configuration data values [functional variable]

596 of 750 11.29. SIDE Configurator

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide a readable format of the parameter values contained
in the iEVC configuration data files
– Description: set of values in readable format
– Family: Software
– Format: JSON or equivalent readable format
– Associated interface:

* SIDE Configurator User Interface[ci]

– Produced by:

* [IEVC.F1.26.04] Extract configuration data values from

files[function]

<configuration_data_file_name> ::= string

<configuration_data_file_date_and_time> ::= string

<ievc_modeler_identification> ::= string

<installation_project_identification> ::= string

<generic_application_name> ::= string

<generic_application_version> ::= string

<parameter_name> ::= string ; this is the parameter

˓→unique identifier

<parameter_value> ::= string

<parameter_value_info> ::= <parameter_name> <parameter_value>

<generic_application_configuration_data_values> ::= <generic_

˓→application_name> <generic_application_version> <parameter_

˓→value_info>*

<configuration_data_file_content> ::= <configuration_data_file_

˓→name> <configuration_data_file_date_and_time> <installation_

˓→project_identification> <ievc_modeler_identification> <generic_

˓→application_configuration_data_values>*

<configuration_data_file_content>*

• Internal messages
The following 2 messages are used internally to the SIDE Configurator component:

Functional Variable
Configuration data values [functional variable]

11.29. SIDE Configurator 597 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide the values to be used in the iEVC Configuration
Data Files.
– Description: List of parameters with their source generic application and
values.
– Family: Software
– Produced by:

* [IEVC.F1.26.02] Provide tabular input interface[function]

– Consumed by:

* [IEVC.F1.26.03] Generate the configuration data files[function]

<ievc_modeler_identification> ::= string

<installation_project_identification> ::= string

<generic_application_name> ::= string

<generic_application_version> ::= string

<parameter_name> ::= string ; this is the parameter

˓→unique identifier

<parameter_value> ::= e_binary*

<parameter_value_info> ::= <parameter_name> <parameter_value>

<generic_application_configuration_data_Values> ::= <generic_

˓→application_name> <generic_application_version> <parameter_

˓→value_info>*

<ievc_modeler_identification> <installation_project_
˓→identification> <generic_application_configuration_data_Values>

˓→*

Functional Variable
Generic applications parameters information [functional variable]

598 of 750 11.29. SIDE Configurator

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide information about the configuration parameters
which values must be set by the installation project. This information is
used to display the data on the SIDE configurator user interface.
– Description: List of generic application with their parameters name and
allowed range.
– Family: Software
– Produced by:

* [IEVC.F1.26.01] Extract configuration parameters from the generic

applications[function]
– Consumed by:

* [IEVC.F1.26.02] Provide tabular input interface[function]

<generic_application_name> ::= string

<generic_application_version> ::= string

<parameter_name> ::= string ; this is the parameter

˓→unique identifier

<parameter_type> ; Structure that describes the type of the

˓→parameter.

; Its exact content is to be defined when

˓→ designing SIDE
; configurator software. It allows describing
˓→ any
; EXS type that could be used inside an iEVC
˓→ application

<parameter_info> ::= <parameter_name> <parameter_type>

<generic_application_configuration_data_range> ::= <generic_

˓→application_name>

<generic_
˓→application_version>

<parameter_
˓→info>*

<generic_application_configuration_data_range>*

11.29. SIDE Configurator 599 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.29.5 Parameters

The SIDE Configurator has no specific parameter.

11.29.6 Requirements

Requirement

The SIDE Configurator shall extract the configuration variables that must be set by the installation
project from the iEVC generic applications. The information extracted contains as a minimum the
generic application identifier, the parameter identifier and its allowed range. [id:tsc-req-ievc-side-
configurator-param-extraction][p1][ns]

The configuration variables are marked with a specific ‘CONFIGURATION’ type in the application model.

Requirement

The SIDE Configurator shall provide a tabular input interface for the configuration parameters that
must be input by the installation project. [id:tsc-req-ievc-side-configurator-interface][p1][ns]

This can be done by exporting the parameters and their range to an excel file. The iEVC Modeler can input
the values in the excel file. Once completed, the file can be parsed by the SIDE Configurator to produce
the iEVC configuration data files.

Requirement

The SIDE Configurator shall generate the generic application configuration data files based on the
configuration parameters values input by the installation project. [id:tsc-req-ievc-side-configurator-file-
generation][p1][ns]

The produced files are:

• The OBU Configuration Application files
• The Train Type Configuration Application file

See also iEVC Configuration Data files for a description of all the configuration data files and their format.

Requirement

The SIDE Configurator shall verify that each value input by the user is within the range that
has been retrieved from the generic application. [id:tsc-req-ievc-side-configurator-file-generation-check-
range][p1][ns]

An explicit error message shall be displayed to the user and the Installation Project Configuration Data
Files shall not be produced in case an error is detected. All parameter values shall checked at once and all
errors shall be displayed at once to the user.

Requirement

The configuration data files that are generated with the SIDE Configurator shall contain information
allowing to identify the user that has prepared them, the date and time of the file generation and the
installation project identifier. [id:tsc-req-ievc-side-configurator-file-content][p1][ns]

600 of 750 11.29. SIDE Configurator

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The configuration data files that are generated with the SIDE Configurator shall contain a SHA-256
checksum [id:tsc-req-ievc-side-configurator-file-content-sha256][p1][s]

Requirement

The SIDE Configurator shall extract configuration data values from the iEVC Configuration
Data Files generated previously with the SIDE Configurator. [id:tsc-req-ievc-side-configurator-data-
extraction][p1][ns]

This feature is used by the iEVC Model Verifier. The SIDE Configurator tool decodes the Train Type and
OBU Configuration Application files and converts the Configuration Data into a readable format.

Requirement

The SIDE Configurator shall ensure that no common mode exists between the production and de-
coding of the iEVC Configuration Data Files. [id:tsc-req-ievc-side-configurator-common-mode][p1][s]

A common mode between these 2 functions imply that there is a risk that a wrong configuration data value
is not detected during the verification activity.

Refer to iEVC Configuration Data Preparation Process for the a description of the configuration process.

11.29.7 Failure modes

11.29.7.1 Failure to extract the configuration parameters from the generic applications

The effect is that some parameters are not extracted and no value is contained inside the configuration file. The
configuration data verification and test activities must detect that no value has been assigned in the configuration
data file.

11.29.7.2 Failure to provide the user interface

The effect is that no configuration data file can be generated by the IEVC modeler[stakeholder].

11.29.7.3 Failure to generate the iEVC configuration data files

The effect is that no configuration data file is generated by the IEVC modeler[stakeholder].

11.29.7.4 A data value is corrupted when generating the configuration data files

The effect is that the configuration data files are not correct and not compliant to the installation project design.
This issue must be detected during the configuration data verification and test activities

11.29. SIDE Configurator 601 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.29.7.5 Failure to generate the configuration data values from files

The effect is that the iEVC Configuration Data Files cannot be verified by the IEVC model verifier[stakeholder]
using the SIDE configurator tool.

11.30 JRU decoder

Important: This component is included in the iEVC ETCS kit[ci]

11.30.1 Description

The Juridical Recording Unit (JRU) Decoder converts the JRU log file produced by the OBOM[ci] in a collection
of textual, human-readable files. The JRU log files entries are specified in [SyAD-R16-SS027].

11.30.2 Functions

The JRU decoder takes a OBOM log file[functional variable][CPM - OBOM interface] as an input.

11.30.2.1 [IEVC.F3.02.13.03] Decode JRU data [function]

Data
• Definition: Transform JRU log files produced by OBOM in a human-readable textual format. Verify
the integrity of the JRU log files and produce a report.
• Allocated to:
– JRU decoder[ci]
• Input:
– OBOM log file[functional variable][CPM - OBOM interface]
• Output:
– JRU Text Files[functional variable]
• Sil: basic
• Associated interface:
– CPM - OBOM interface[ci]

11.30.3 Interfaces

The JRU decoder produces outputs files according to the following definition.

Functional Variable
JRU Text Files [functional variable]

602 of 750 11.30. JRU decoder

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide a human-readable format of recorded JRU logs
• Description: a list of files, with names prefixed by dates. Message content is encoded using
a clear text format.
• Family: Software
• Format: textual file format
• Produced by:
– [IEVC.F3.02.13.03] Decode JRU data[function]

Note: The detailed format is defined in [SyAD-R75-SIF-JRU-Text-file].

11.30.4 Requirements

Requirement

The JRU decoder shall transform JRU log files produced by OBOM in a human-readable textual
format [id:tsc-req-ievc-jru-decoder-decode][p1][ns]

The human-readable format shall be compliant to ‘JRU text file format description’.

Allocate
Allocation of JRU data conversion requirement [allocate]
Data
• Requirement:
– tsc-req-ievc-pqp-jru-62625-1-4-2-4[req]
• Ci:
– JRU decoder[ci]
• Justification: The JRU decoder converts the recorded data into a standard format for data
exchanged

Requirement

The JRU decoder shall check the integrity of recorded data [id:tsc-req-ievc-jru-decoder-integrity-
check][p1][ns]

11.30. JRU decoder 603 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

11.30.5 Failure modes

If the JRU decoder fails, either no decoded data is available or wrong values are decoded. In the first case the
information from the log file cannot be read at all. In the second case the decoded values are not correct, and the
run cannot be analyzed correctly.
In both cases a ‘manual’ decoding of the binary log file is required and the JRU decoder needs to be fixed for the
identified issue.

604 of 750 11.30. JRU decoder

b2c00c725888f54563d63f5293b6fdc2681109bb
CHAPTER

TWELVE

OUTSOURCED GENERIC COMPONENTS

This section describes all ‘Outsourced Generic Components’ previously introduced in the architecture. The infor-
mation is organized in the same way as for the ‘Developed Components’ of the previous chapter.

12.1 Safe computer

Important: This component is included in the iEVC Basic kit[ci]

12.1.1 Description

The Safe Computer is designed to execute safety critical software according to [SyAD-R36-EN50129:2018] stan-
dard.
In term of architecture the Safe computer[ci] is composed of:
• A Safe domain executor in charge of executing safety-critical software components.
• A set of Safe IO boards (IO board[ci]) capable of performing safety-critical operations with wired input
and output.
• A Non Safe domain executor in charge of Basic Integrity (BI) software components. It manages for example
network protocol, software upload, maintenance and debug.

12.1.1.1 Safe domain executor

This component uses a composite fail-safe architecture as defined by [SyAD-R36-EN50129:2018] annex B1. It
is able to execute SIL 4 code, with several independent CPU that perform the same calculation with the following
principles:
• Both CPU are identical and use an independent memory Space for program (Flash, Read Only, Random
access);
• When a failure happens, the Safe domain executor shall detect it and put the CPU of the Safe domain into a
Fail Safe mode;
• The Safe domain remains safe in the event of any single random hardware fault. To do so, failures are
detected by dedicated supervision electronic. It is the responsibility of the board designer to implement
automatic reaction according the requirement of the [SyAD-R36-EN50129:2018] annex B;
• The Safe Computer Operating system shall ensure the safety by providing:
– a deterministic and real time scheduling of the execution of the SIL 4 software;
– a service that provides safe communication over non-trusted parts. This is used for communications:

* between the 2 CPU of the Safe domain,

12. Outsourced Generic Components 605 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

* between a CPU of the Safe domain and the IO boards.

– A service that ensures that the inputs of both processors are identical;
– a set of synchronization services between CPU that ensures a deterministic timing for:

* the beginning of the execution,

* the establishment of a shared system time,
* the start of the acquisition process from IO boards,
* the production of the outputs to the network and IO boards,
* the start of execution of some key processing (VM driver, Application, . . . );
– A voting service that allows to cross-check the consistency of both processors. In particular this service
is used to cross-check at least:

* the output messages produced by each processors,

* the execution context of each processor.

12.1.1.2 Safe Input acquisition

Status of wired inputs are collected according to a composite fail-safe architecture presented by the figure Fig.
12.1.
The main principles are:
• The acquisition of a wired input is performed by two independent input boards. Each board transmit its
information through a safety protocol to the 2 CPU of the Safe domain executor.
• The detection performed by two redundant and independent contacts linked to the item to supervise. When
only one contact is available it is the responsibility of the installation designer to add additional relay if
needed.
• An isolated power supply (I/O Power Supply) produces the current crossing the contact.
• Each board shall implement a set of techniques to detect failure. When a failure is detect the board shall be
put in a Fail Safe mode.

Note: These principles are vendor dependent.

606 of 750 12.1. Safe computer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 12.1: Principle of wired safe inputs

12.1.1.3 Safe outputs commands

Wired output are commanded according to a composite fail-safe architecture presented by the figure Fig. 12.2.
The main principles are:
• Each CPU of Safe domain executor sends an order to both IO boards. Each board activates its wired outputs
only when the 2 orders are consistent;
• Both outputs command a safety relay that allows having 2 floating free contacts.
• The power supply (I/O Power Supply) produces the power needed for the operation of the safety relay.
When the Safe computer goes into Fail Safe mode it shall position its outputs in a restrictive position. The restric-
tive states depend on the technology of the IO boards used in the Safe computer. They are the guaranteed default
states assumed by the digital outputs whenever a critical failure occurs such as a complete loss of power. The digi-
tal output(s) that command(s) the emergency brake must have a restrictive state corresponding to ‘EBCommanded’
(meaning that the brake is applied). This is achieved by means of the installation design (see tsc-req-ievc-tiu-app-
default-values-outputs[req]). This means that the emergency brake of the train shall be applied whenever the Safe
computer is in Fail Safe mode.

12.1. Safe computer 607 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 12.2: Principle of wired safe outputs

12.1.1.4 I/O Expansion rack

IO board can be arranged into the Computer box extension[ci] rack to increase the number of safe inputs and
outputs available to the iEVC system. The communication between the Safe computer IO Extension[ci] and Safe
computer[ci] is vendor dependent.

12.1.1.5 Non Safe domain executor

This component is a general purpose CPU running a Linux operating systems. This processor is used for non safe
operation, that includes :
• the management of the interface of the Safe computer[ci] (Ethernet, communication),
• the execution of the TSC Net[ci] services,
• the execution of the maintenance functions of the iEVC (e.g OBOM[ci]).

608 of 750 12.1. Safe computer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.1.2 Safe computer modes

This component has the following modes:

Table 12.1: Safe Computer functions activation

Mode Active functions
Off
Hardware Starting
• [IEVC.F4.28.01.01] Check Safe Computer Hardware Integrity[function]

Computing OS Starting
• [IEVC.F4.28.01.01] Check Safe Computer Hardware Integrity[function],
• [IEVC.F4.28.01.02] Check Safe Domain Software Integrity[function],
• [IEVC.F1.05.17] Provide VM Config files[function]

Nominal mode
• [IEVC.F4.28.01.01] Check Safe Computer Hardware Integrity[function],
• [IEVC.F4.28.01.02] Check Safe Domain Software Integrity[function],
• [IEVC.F3.02.14.05] Manage IO board[function],
• [IEVC.F3.02.14.06] Collect inputs[function],
• [IEVC.F3.02.14.07] Drive outputs[function],
• [IEVC.F5.09.03] Log non-volatile operational data checksums[function]

Fail Safe mode

• [IEVC.F4.28.01.01] Check Safe Computer Hardware Integrity[function],
• [IEVC.F4.28.01.02] Check Safe Domain Software Integrity[function],
• [IEVC.F3.02.14.07] Drive outputs[function]

The transitions are as follows:

Figure 12.3: Mode transition diagram of Safe Computer

The transition to ‘Fail Safe mode’ occurs when there is a hardware or software critical failure. A failure is
considered as critical when it impacts the integrity of the Safe domain. The detailed list of hardware and software
critical failures depends on the technology of the Safe computer. However it shall include as a minimum the
conditions:
• VM cycle watchdog expiration
• VM going to VM_FAULT (see VM Modes).

12.1. Safe computer 609 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.1.3 Functions

12.1.3.1 Wired IO Management

Flows involved by the wired I/O management are illustrated by figure Fig. 12.4.

Figure 12.4: Flows involved by the wired I/O management by the Safe computer

12.1.3.1.1 [IEVC.F3.02.14.05] Manage IO board [function]

Data
• Definition: This function manages protocol with IO board. It collects the state of the digital inputs
and commands the digital outputs. It also collects the the IO boards health information to inform
the TIU application.
• Allocated to:
– Safe computer[ci]
– Safe computer IO Extension[ci]
• Input:
– IO Board Logical commands[functional variable][VM - Safe computer OS interface]
– IO board fault[functional variable]
– Redundant inputs[functional variable]
• Output:
– IO Board Logical states[functional variable][VM - Safe computer OS interface]
– Redundant outputs[functional variable]

610 of 750 12.1. Safe computer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– IO Board health information[functional variable][VM - Safe computer OS interface]

• Sil: 4
• Associated interface:
– VM - Safe computer OS interface[ci]

12.1.3.1.2 [IEVC.F3.02.14.06] Collect inputs [function]

Data
• Definition: Transforms electrical level to input states.
• Allocated to:
– IO board[ci]
• Input:
– Safe computer digital inputs[functional variable][Safety Relays - Safe Computer interface]
• Output:
– Redundant inputs[functional variable]
– IO board fault[functional variable]
• Sil: 4
• Associated interface:
– Safety Relays - Safe Computer interface[ci]

12.1.3.1.3 [IEVC.F3.02.14.07] Drive outputs [function]

Data
• Definition: Drives electrical output level according to commands. When the Safe computer goes
into Fail Safe mode, this function allows positioning the IO boards outputs in a restrictive state.
• Allocated to:
– IO board[ci]
• Input:
– Redundant outputs[functional variable]
• Output:
– Safe computer digital outputs[functional variable][Safety Relays - Safe Computer interface]
– IO board fault[functional variable]
• Sil: 4
• Associated interface:
– Safety Relays - Safe Computer interface[ci]

12.1. Safe computer 611 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.1.3.1.4 [IEVC.F3.02.14.08] Provide safe contacts [function]

Data
• Definition: For outputs, provides contacts able to support tension and/or current needed to power
the load. For inputs, provides the status of the item to observe.
• Allocated to:
– Safety relay[ci]
• Input:
– Safe computer digital outputs[functional variable][Safety Relays - Safe Computer interface]
– Train digital inputs[functional variable][iEVC - Train generic interface]
• Output:
– Safe computer digital inputs[functional variable][Safety Relays - Safe Computer interface]
– Train digital outputs[functional variable][iEVC - Train generic interface]
• Sil: 4
• Associated interface:
– Safety Relays - Safe Computer interface[ci]
– iEVC - Train generic interface[ci]

12.1.3.2 Others

12.1.3.2.1 [IEVC.F4.28.01] Safe computer - Provide maintenance and fault information [function]

Data
• Definition: Provides maintenance information and fault information about the Safe Computer. This
information includes any information about the Safe computer power supply. Fault information
about the IO boards is not included as it is already reported though the IO driver of the VM.
• Allocated to:
– Safe computer[ci]
• Output:
– Safe computer faults[functional variable][VM - Safe computer OS interface]
– Safe Computer Configuration Information[functional variable][VM - Safe computer OS inter-
face]
• Sil: basic
• Associated interface:
– VM - Safe computer OS interface[ci]
• Sub functions:
– [IEVC.F4.28.01.01] Check Safe Computer Hardware Integrity[function]
– [IEVC.F4.28.01.02] Check Safe Domain Software Integrity[function]

612 of 750 12.1. Safe computer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.1.3.2.2 [IEVC.F4.28.01.01] Check Safe Computer Hardware Integrity [function]

Data
• Definition: Checks hardware integrity. When a critical fault is detected, the Safe computer shall go
in Fail Safe mode.
• Allocated to:
– Safe computer[ci]
• Sil: basic

12.1.3.2.3 [IEVC.F4.28.01.02] Check Safe Domain Software Integrity [function]

Data
• Definition: Checks Safe domain software integrity. When a critical fault is detected, including the
VM going to VM_FAULT mode, the Safe computer shall go in Fail Safe mode.
• Allocated to:
– Safe computer[ci]
• Input:
– VM status message[functional variable][VM - OBOM interface][VM - Safe computer OS in-
terface]
• Sil: basic
• Associated interface:
– VM - Safe computer OS interface[ci]

12.1.3.2.4 [IEVC.F5.09.03] Log non-volatile operational data checksums [function]

Data
• Definition: The Safe computer offers a non-volatile memory area for safe application to write values
that can be read at startup.
• Allocated to:
– Safe computer[ci]
• Input:
– Non volatile data control[functional variable][VM - Safe computer OS interface]
• Output:
– Non volatile data control[functional variable][VM - Safe computer OS interface]
• Sil: 4
• Associated interface:
– VM - Safe computer OS interface[ci]

12.1. Safe computer 613 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.1.3.2.5 [IEVC.F1.05.17] Provide VM Config files [function]

Data
• Definition: The Safe computer stores in its non-volatile memory the VM configuration file. This file
contains the minimal information that the VM needs to identify the train it is running and authenti-
cate the application packages it is supposed to run. The Safe Computer operating system provides
this file to the VM during its initialization.
• Allocated to:
– Safe computer[ci]
• Output:
– VM config file[functional variable][VM - Safe computer OS interface]
• Sil: 4
• Associated interface:
– VM - Safe computer OS interface[ci]

12.1.4 Interface

The following external interfaces are applicable to the Safe computer:

• Safety Relays - Safe Computer interface[ci] This interface describes the technical aspect of the wired input
and output interface.
This interface includes the following variables:

Functional Variable
Safe computer digital inputs [functional variable]
Data
– Objective: To provide electrical level of the inputs managed by the IO boards of the
Safe computer
– Description: set of wires that connect the safety relay to the IO boards of the Safe
computer.
– Family: Hardware
– Type: Wired
– Format: schematics
– Associated interface:

* Safety Relays - Safe Computer interface[ci]

– Produced by:

* [IEVC.F3.02.14.08] Provide safe contacts[function]

– Consumed by:

* [IEVC.F3.02.14.06] Collect inputs[function]

The detail of the wiring is defined according of the constraints exported by the Safe computer vendor
and the principle described by section Safe Input acquisition.

614 of 750 12.1. Safe computer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
Safe computer digital outputs [functional variable]
Data
– Objective: To provide electrical power to set the state of the safety relays
– Description: set of wires that connect the IO boards to the safety relays.
– Family: Hardware
– Type: Wired
– Format: schematics
– Associated interface:

* Safety Relays - Safe Computer interface[ci]

– Produced by:

* [IEVC.F3.02.14.07] Drive outputs[function]

– Consumed by:

* [IEVC.F3.02.14.08] Provide safe contacts[function]

The detail of the wiring is defined according of the constraints exported by the Safe computer vendor
and the principle described by section Safe outputs commands.

Functional Variable
Train digital inputs [functional variable]
Data
– Objective: To provide electrical level of the inputs to be acquired by the safety relays.
– Description: set of wires that connect the train lines to be acquired to the safety relays.
– Family: Hardware
– Type: Wired
– Format: schematics
– Associated interface:

* iEVC - Train generic interface[ci]

– Consumed by:

* [IEVC.F3.02.14.08] Provide safe contacts[function]

The detail of the wiring is defined according of the constraints exported by the safety relay vendor
and the train lines. Generic constraints are also provided in [SyAD-R73-SIF-Train-Generic].

Functional Variable
Train digital outputs [functional variable]

12.1. Safe computer 615 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide electrical power to set the status of the train lines to command.
– Description: set of wires that connect the safety relays to the train lines to be com-
manded.
– Family: Software
– Type: Wired
– Format: schematics
– Associated interface:

* iEVC - Train generic interface[ci]

– Produced by:

* [IEVC.F3.02.14.08] Provide safe contacts[function]

The detail of the wiring is defined according of the constraints exported by the safety relay vendor
and the train lines. Generic constraints are also provided in [SyAD-R73-SIF-Train-Generic].

• VM - Safe computer OS interface[ci]

The Virtual Machine reports its VM_FAULT mode to the Safe computer by providing the mes-
sage VM status message[functional variable][VM - OBOM interface][VM - Safe computer OS
interface] (or an equivalent information depending on the interface that is Safe computer vendor
dependent). The failure of the VM triggers the Fail Safe mode of the Safe computer.
The Safe computer reports its detected failures to the VM. The VM provides the information to
iEVC applications such as LRU application. The information can then be published and logged.
The Safe computer reports its configuration to the VM.
The Safe computer exchanges information about the digital input states and the digital output
commands with the VM.
The following variables are exchanged with the VM:

Functional Variable
Safe computer faults [functional variable]

616 of 750 12.1. Safe computer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide Safe computer faults, excluding the faults related to
the IO boards.
– Description: data structure or message providing the list of detected faults
in the Safe computer.
– Family: Software
– Type: vendor dependent
– Format: vendor dependent
– Protocol: vendor dependent
– Associated interface:

* VM - Safe computer OS interface[ci]

– Produced by:

* [IEVC.F4.28.01] Safe computer - Provide maintenance and fault in-

formation[function]
– Consumed by:

* [IEVC.F4.28.14] Collect safe computer faults[function]

This fault is collected by the Virtual machine[ci] and forwarded to the LRU applica-
tion[ci] (refer to LRU application). The content depends on the Safe computer vendor.
It is not defined in this release of the specification.

Note: The faults related to the IO boards are provided separately by the IO driver
through the variable IO Board health information[functional variable][VM - Safe com-
puter OS interface].

Functional Variable
Safe Computer Configuration Information [functional variable]

12.1. Safe computer 617 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide the configuration information of the Safe computer
(e.g. P/N and version), including the IO boards.
– Description: data structure or message providing the part number and ver-
sion of the various components making the safe computer.
– Family: Software
– Type: vendor dependent
– Format: vendor dependent
– Protocol: vendor dependent
– Associated interface:

* VM - Safe computer OS interface[ci]

– Produced by:

* [IEVC.F4.28.01] Safe computer - Provide maintenance and fault in-

formation[function]
– Consumed by:

* [IEVC.F4.12.02] Publish VM configuration report[function]

The following variables are internal to the Safe computer or exchanged with the Computer box
extension[ci], when used:
Functional Variable
IO board fault [functional variable]
Data
– Objective: To provide IO board failure information to the Safe computer
OS
– Description: message providing IO board failure information.
– Family: Hardware
– Type: vendor dependent
– Format: vendor dependent
– Protocol: vendor dependent
– Produced by:

* [IEVC.F3.02.14.06] Collect inputs[function]

* [IEVC.F3.02.14.07] Drive outputs[function]
– Consumed by:

* [IEVC.F3.02.14.05] Manage IO board[function]

This message contains fault information as provided by the IO board to the Safe computer
OS. The content depends on the Safe computer vendor. It is not defined in this release of
the specification.

Functional Variable
Redundant inputs [functional variable]
Data
– Objective: To provide the state of the digital inputs managed by the IO
boards of the Safe computer
– Description: data structure or message providing the list of safe input with
their state.
– Family: Software
– Type: vendor dependent
– Format: vendor dependent
– Protocol: vendor dependent
– Produced by:

* [IEVC.F3.02.14.06] Collect inputs[function]

– Consumed by:

* [IEVC.F3.02.14.05] Manage IO board[function]

620 of 750 12.1. Safe computer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The content depends on the Safe computer vendor. It is not defined in this release of the
specification.

Functional Variable
Redundant outputs [functional variable]
Data
– Objective: To provide command for digital outputs managed by the IO
boards of the Safe computer.
– Description: data structure or message providing the list of safe output
commands.
– Family: Software
– Type: vendor dependent
– Format: vendor dependent
– Protocol: vendor dependent
– Produced by:

* [IEVC.F3.02.14.05] Manage IO board[function]

– Consumed by:

* [IEVC.F3.02.14.07] Drive outputs[function]

The content depends on the Safe computer vendor. It is not defined in this release of the
specification.

12.1.5 Parameters

Functional Variable
Safe computer network parameters [functional variable]
Data
• Objective: To provide the network parameters of the Safe computer.
• Description: This variable contains the network parameters of the Safe computer. There is
one IP address per sub-network where the Safe computer shall communicate.
• Family: Software
• Type: Internet Protocol Address
• Format: SSS.SSS.SSS.XXX (SSS.SSS.SSS: subnet address, address in the subnet)
• Protocol: System Parameters

12.1. Safe computer 621 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.1.6 Requirements

12.1.6.1 Functional

Requirement

The Safe computer shall check the Safe computer hardware integrity and go in Fail safe mode when
a critical fault is detected. [id:tsc-req-ievc-safe-computer-check-hw][p1][s]

Note: Hardware integrity faults that have to be considered as critical in order to reach SIL 4 need to be
defined by the supplier.

Requirement

The Safe computer shall check the Safe domain software integrity and go in Fail safe mode when a
critical fault is detected. [id:tsc-req-ievc-safe-computer-check-sw][p1][s]

Note: Software integrity faults that have to be considered as critical in order to reach SIL 4 need to be
defined by the supplier.

Requirement

The Safe computer shall provide a non-volatile memory area that can be accessed by the Virtual
Machine in order for safe applications to be able to read/write values during their execution. [id:tsc-
req-ievc-safe-computer-nv-memory][p1][ns]

This access is used to store a checksum computed on the iEVC applications operational data that are
recorded in the CPM.

Requirement

The Safe computer shall store the VM configuration file in its non-volatile memory area. The Safe
computer shall provide this file to the Virtual Machine during the VM initialization. [id:tsc-req-ievc-
safe-computer-vm-config-file][p2][ns]

Requirement

The Safe computer shall provide maintenance and faults information to the Virtual Machine. [id:tsc-
req-ievc-safe-computer-maintenance-faults][p2][ns]

The Safe computer is responsible to detect faults of all components within its architecture, including its
IO boards and its power supply units.
The Safe computer shall provide a Safe computer faults message and a Safe Computer Configuration
Information message to the VM. The Safe Computer Configuration Information message contains the part
numbers and versions of the different components of the Safe computer.

622 of 750 12.1. Safe computer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.1.6.2 Architecture

Requirement

The Safe computer shall provide an executor suitable for SIL 4 software. [id:tsc-req-ievc-safe-computer-
sil-4-executor][p1][s]

Each CPU shall use an independent Memory Space for program (Flash, Read Only of Random access);
The architecture shall be able to support SIL 2 functions if needed.

Requirement

The Safe computer shall provide a general purpose executor with a Linux based operating system
suitable for Basic integrity software. [id:tsc-req-ievc-safe-computer-basic-integrity-executor][p2][ns]

Requirement

The operating system of the safe executor shall provide a deterministic and real time scheduling
with SIL 4 certification. [id:tsc-req-ievc-safe-computer-sil-4-operating-system][p1][s]

The precision of the scheduling is less than 0.1 millisecond.

Requirement

The operating system of the safe executor shall provide a set of synchronization services between
CPU [id:tsc-req-ievc-safe-computer-sil-4-synchronization-services][p2][s]

Such services shall synchronize :

• the beginning of the execution,
• the establishment of a shared system time,
• the start of the acquisition process form IO boards,
• the production of the outputs to the network and IO boards,
• the start of execution of some key processing (VM driver, Application, . . . );

Requirement

The operating system of the 2oo2 executor shall provide a service that ensures that the inputs of
both processors are identical [id:tsc-req-ievc-safe-computer-sil-4-synchro-services][p2][s]

Requirement

The operating system of the safe executor shall provide a voting service that cross-checks the safe
behavior of the CPU [id:tsc-req-ievc-safe-computer-sil-4-voting-services][p2][s]

This service is used to cross-check at least:

• the output messages produced by each processors,
• the execution context of each processor.

12.1. Safe computer 623 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The operating system of the safe executor shall establish a safe communication channel between
CPU even over non-trusted parts (Black channel) [id:tsc-req-ievc-safe-computer-black-channel][p2][s]

Requirement

The safe executor shall go into Fail Safe mode when the VM reports a VM_FAULT mode [id:tsc-req-
ievc-safe-computer-vm-fault][p1][s]

12.1.6.3 Interfaces

Requirement

The Safe computer shall manage the protocol with its IO boards. [id:tsc-req-ievc-safe-computer-io-
boards][p2][s]

Requirement

The IO Boards of the Safe computer shall collect the digital inputs and transform them into input
states that can be provided to the VM. [id:tsc-req-ievc-safe-computer-io-inputs][p2][s]

Requirement

The IO Boards of the Safe computer shall drive digital outputs according to commands provided by
the Virtual Machine [id:tsc-req-ievc-safe-computer-io-outputs][p1][s]

Requirement

The Safe computer shall provide at least 16 SIL4 outputs to the train interface. [id:tsc-req-ievc-safe-
computer-16-safety-outputs][p2][s]

These outputs shall ensure the SIL4 integrity level according to EN50129. Taking into account the redun-
dancy requirement of the composite fail-safe architecture, the Safe computer rack shall actually manage
32 outputs.

Requirement

The Safe Computer shall provide at least 16 inputs for the train interface. [id:tsc-req-ievc-safe-
computer-16-safety-inputs][p2][s]

These inputs shall ensure the SIL4 integrity level according to EN50129. Taking into account the redun-
dancy requirement of the composite fail-safe architecture, the Safe computer rack shall actually manage
32 inputs.

Requirement

The Safe Computer IO Extension shall add at least 16 outputs to the train interface. [id:tsc-req-ievc-
safe-computer-16-safety-outputs-extension][p2][s]

624 of 750 12.1. Safe computer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The Safe Computer IO Extension shall to add at least 16 inputs for the train interface. [id:tsc-req-
ievc-safe-computer-16-safety-inputs-extension][p2][s]

Requirement

The Safe Computer shall provide 2 individual Ethernet connectors. [id:tsc-req-ievc-safe-computer-dual-

ethernet][p2][ns]

Requirement

The Safe Computer shall provide 2 individual connectors for the connection with Safe Computer IO
Extension. [id:tsc-req-ievc-safe-computer-io-link][p2][ns]

Physical cable used for this connection shall be twisted par category 5e (Like Ethernet).

Requirement

When in Fail Safe mode, the Safe computer shall command the emergency brake by setting its safe
outputs in a restrictive state. [id:tsc-req-ievc-safe-computer-fail-safe-eb][p1][s]

This means that the train interface must be design to associate the emergency brake application command
to the restrictive default position of the safe output.

Requirement

The Safety Relay shall provide safe dry contacts able to control line with tensions up to 220V DC
and currents up to 3A, and using input line with nominal tension of 24V DC. [id:tsc-req-ievc-safetty-
relay][p1][ns]

Requirement

The function of the Safety Relay shall be certified SIL4 against EN50129:2018 [id:tsc-req-ievc-safety-
relay-sil4][p1][s]

12.1.6.4 Conformity to EN 50129

Allocate
Safe computer - Sufficient failure detection and negation mechanisms shall be demonstrated in the
safety case of the Safe computer. [allocate]

12.1. Safe computer 625 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-en50129-2018-b-3-1-1[req]
• Ci:
– Safe computer[ci]
– IO board[ci]
• Justification: This requirement shall be satisfied by the safe computer with composite fail-
safe 2oo2 architecture order to ensure the integrity of the execution

Allocate
Safe computer with composite fail-safe 2oo2 architecture - Appropriate rules or guidelines to be
fulfilled to ensure this independence [allocate]
Data
• Requirement:
– tsc-req-en50129-2018-b-3-2-1-1[req]
– tsc-req-en50129-2018-b-3-2-2-2[req]
– tsc-req-en50129-2018-b-3-2-3-2[req]
– tsc-req-en50129-2018-b-3-3-1-1[req]
– tsc-req-en50129-2018-b-3-3-2-1[req]
– tsc-req-en50129-2018-b-3-4-1[req]
• Ci:
– Safe computer[ci]
– IO board[ci]
• Justification: Safe Computer is a composite fail-safe 2oo2. It shall be conform this require-
ment

Requirement

The Safe computer shall be conform to requirements of the EN50129:2018 Annex C [id:tsc-req-ievc-
safe-computer-computer-en50129-annex-c][p1][s]

Requirement

The design of the Safe computer shall be conform to requirements of the EN50129:2018 Table E.5
[id:tsc-req-ievc-safe-computer-computer-en50129-table-e5][p1][s]

626 of 750 12.1. Safe computer

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.1.7 Safe computer failure modes

When a hardware or software critical failure is detected by the Safe computer, it switches to ‘Fail Safe mode’. In
this mode the outputs of the IO boards assume a restrictive state. This means that the emergency brake is ordered
unless the iEVC On-board had been isolated from its train interface. In this state the iEVC needs to be fixed
and restarted. The detailed list of hardware and software critical failures depends on the technology of the Safe
computer. However it shall include as a minimum the conditions:
• VM cycle watchdog expiration
• VM going to VM_FAULT (see VM Modes).
When a non critical failure occurs the Safe computer remains in its current mode and it reports the failure to the
Virtual Machine. The VM makes the information available to the generic applications that react in an appropriate
way considering the operational impact of the failure and/or the signalling requirements.

12.2 Wheel pulse generators

Important: This component is included in the iEVC Sensor kit[ci]

12.2.1 Description

The electronic wheel Pulse Generator (PG) is an Odometry sensor that measures the train’s wheel rotation that
leads to the calculation of speed and distance traveled by train. The PG to be used on-board is a multi-channel
sensor which, due to the defined phase offset, is also able to returns the direction of travel. Fig. 12.5 shows an
example of a PG sensor:

Figure 12.5: PG sensor

12.2. Wheel pulse generators 627 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.2.2 Installation of Wheel pulse generator

The Wheel pulse generator is exposed to hard external conditions (water, wind, dust, . . . ). On the advice of PG
suppliers, it is recommended to use PG with a fixed cable instead of screwed connector.
A PG with a fixed cable with a minimum length of 3m (resizable) and a junction box will provide more flexibility
for the installation on the train.

Figure 12.6: Installation of PG with fixed cable and junction box (source HaslerRail)

For the installation of the Wheel pulse generator on the train, some adapters are required for the mounting of the
PG and for the connection of the PG with the wheel axle (driving systems).

Figure 12.7: PG driving systems: Bottom left: driving fork, Top: driving tongue and Bottom right: differential
disc (source HaslerRail)

628 of 750 12.2. Wheel pulse generators

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.2.3 Modes

No mode is defined for PG sensor.

12.2.4 Functions

12.2.4.1 [IEVC.F3.02.03.01] Produce pulse signal from wheel rotation [function]

Data
• Definition: The PG is mechanically coupled with the train's wheel. The mechanical coupling trans-
fers the rotation of the vehicle axle to the shaft of the electronic pulse generator. The pulse generator
contains a pulse wheel with varying number of slots on the outer and/or inner track. The optoelec-
tronics pulse wheel generates a speed-depended pulse signal such that the number of pulses within
each time step determine the rotational speed. These signals are square signals in the 10V-30V
range. The PG has 3 independent square signals, each signal includes 2 channels. Due to the de-
fined phase offset (2 channels with 90° phase shift), the PG can also detect direction of train’s wheel
rotation.
• Allocated to:
– Wheel pulse generators[ci]
• Output:
– Pulse Generator signals[functional variable][Sensor box - Pulse generator interface]
• Sil: basic
• Associated interface:
– Sensor box - Pulse generator interface[ci]

12.2.5 Interface

• Sensor box - Pulse generator interface[ci]

The PG sensor has interface with 2 iODO module boards (inside sensor box) which sample the
generated square signals. The sensor output is formed with 3 pairs of cables, each cable having
2 channels, such that the speed and direction information is passed to the iODO boards through
6 channels in each sampling time-step. The 3 pairs of cables are assembled in one larger cable
for easy installation. More on the content of PG interface (including messages) can be found in
[SyAD-R57-SIF-iODO-PG]. Also the interface architecture and connector type with Sensor box
can be found in Sensor box hardware.

12.2.6 Requirements

Requirement

The PG sensor accuracy shall be better than 0.15 Km/h [id:tsc-req-ievc-pg-accuracy][p1][ns]

Requirement

PG sensor power supply shall be DC +24 V [id:tsc-req-ievc-pg-req3][p1][ns]

The PG sensor power supply shall be limited to +24 V. The supply voltage range shall be DC +10 V to
+30 V

12.2. Wheel pulse generators 629 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The PG sensor shall provide 3 independent speed measurement square signals, each signal including
2 channels with 90° phase shift. [id:tsc-req-ievc-pg-output][p1][s]

Requirement

The PG sensor shall be consist of at least 6 internal optical detectors [id:tsc-req-ievc-pg-req4][p1][s]

There should be at least 6 optical detectors (each detector returns one output channel) inside the PG sensor.

Requirement

The PG sensor shall be provided with a fixed cable with a minimum length of 3m [id:tsc-req-ievc-pg-
req5][p1][ns]

It is the best solution to have a waterproof PG and avoid issue due to connector. The cable shall be
resizable.

Requirement

Adapters for the mounting of the PG on the train shall be provided [id:tsc-req-ievc-pg-req6][p1][ns]

It contains the required adapter to fix the PG on the train and the suitable driving system between the wheel
axle and the PG sensor.

Note: The adapter are specific to the project and are not detailed in this specification.

12.2.7 Failure modes

Any failure on wheel PG directly affects the performance of Odometry Application. For PG sensor specifically 3
failure mode can be defined as elaborated in the following.

12.2.7.1 Optoelectronics pulse wheel broken

If the optoelectronics pulse wheel brakes the PG sensor can not return speed-dependent pulse signals and the
Odometry Application will receive only secondary sensor measurement. This situation is more explained in failure
mode section of Odometry Application.

12.2.7.2 Channel broken

As already explained PG sensor output is formed by 3 pairs of redundant cables where each cable has two channels
(for backward and forward movement detection). However, the odometry is fed only by 2 redundant cables (4
channels in total) as depicted in Fig. 11.8. So, there is a spare cable which can be used if one of the paired
channels is broken.

630 of 750 12.2. Wheel pulse generators

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.2.7.3 Power supply broken

If PG sensor doesn’t receive power supply the odometry application temporary will operate with secondary sensor,
with possible degradation in precision, until the power supply is restored.

12.3 Secondary odometry sensor

Important: This component is included in the iEVC Sensor kit[ci]

12.3.1 Description

The Secondary Odometry sensor is another type of speed sensor, other than Wheel pulse generators, that measures
the train speed and movement direction independent of wheels rotation. Accordingly, one of the main goal of
having the secondary sensor is to detect possible Slip/Slide phenomenon when Wheel pulse generators returns
an unreal train’s speed during Slip/Slide. Therefore, this sensor should be highly reliable. This sensor has been
selected based on [SyAD-R76-ODO-STAT]. It is a Corrail sensor.
Corrail sensor is an optical sensor that offers contact-less, track-bed independent, direct measurement of a rail ve-
hicle’s speed and movement direction, using the rail head as a reference. This sensor is mounted on the locomotive
bogie such that the sensor field of view is centered and pointed to the rail surface. Fig. 12.8 shows an example of
a Corrail camera sensor and rail surface.

Figure 12.8: Corrail camera sensor and rail head

The Corrail sensor needs to be connected to a filter box via a specific cable.

12.3. Secondary odometry sensor 631 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.3.1.1 Functions

12.3.1.1.1 [IEVC.F3.02.03.02] Produce secondary pulse proportional to speed and serial link
[function]

Data
• Definition: The secondary sensor produces speed dependent pulse output in the form of square-wave
signal as well as speed information, including speed and direction of travel, in the form of serial link
output
• Allocated to:
– Secondary odometry sensor[ci]
• Output:
– Secondary odometry sensor pulse signals[functional variable][Sensor box - Secondary sensor
interface]
– Secondary odometry serial link[functional variable][Sensor box - Secondary sensor interface]
• Sil: basic
• Associated interface:
– Sensor box - Secondary sensor interface[ci]

To detect the train speed, Corrail camera uses optical spatial filter technology. This technology comprises the op-
tics, which use a grid (spatial filter) to map the structure of the moving surface of the rail head onto a photographic
receiver. Then, a photo-detector converts the optical information into electrical signals whose frequency is propor-
tional to the speed. The speed information is gathered in terms of pulse output and serial output (RS485) in two
voltage of 12 or 24 V amplitude. The pulse output is a square-wave signal coming from the photo-detector with
speed-proportional frequency. The serial output is in form of RS485 protocol with the data interface including
speed, distance and direction of travel.

12.3.2 Interface

• Sensor box - Secondary sensor interface[ci]

The secondary sensor has interface with 2 iODO[ci] boards (inside sensor box) which sam-
ple the generated square signals as well as serial link information carried by RS485 pro-
tocol. The two outputs are split between the 2 iODO[ci] boards such that the first iODO
samples the square signals and the second iODO samples the serial information. More on
the content of secondary odometry sensor interface (including messages) can be found in
[SyAD-R58-SIF-iODO-SECONDARY]. Also the interface architecture and connector type with
Sensor box[ci] can be found in Sensor box hardware.

12.3.3 Requirements

Requirement

Secondary odometry sensor accuracy shall be better than 0.15 Km/h [id:tsc-req-ievc-secondarysensor-
accuracy][p1][ns]

According to the requirement imposed by the Odometry Application, the secondary sensor precision shall
not be worse than the Wheel pulse generators. Because this sensor is intended to be used also for the
detection of Slip/Slide condition which is not sensed by the Wheel pulse generators.

632 of 750 12.3. Secondary odometry sensor

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The secondary odometry sensor power supply shall be +24 V to +110 V DC (<35 Watt) [id:tsc-req-
ievc-secondarysensor-powersupply][p1][ns]

Requirement

Secondary odometry sensor shall return a signal of pulse output as well as one serial output (Nor-
mally RS485) [id:tsc-req-ievc-secondarysensor-output][p1][s]

Requirement

The frequency of the Secondary odometry sensor serial output shall be higher than or equal to iODO
boards sampling frequency (> 100 Hz) [id:tsc-req-ievc-secondarysensor-serial-output][p1][s]

Requirement

The Secondary odometry sensor shall be provided with its specific cable. [id:tsc-req-ievc-
secondarysensor-req5][p1][ns]

Note: the features of the cable depends on the selected Secondary odometry sensor.

Requirement

The secondary odometry sensor shall report faults [id:tsc-req-ievc-secondarysensor-faults][p2][ns]

12.3.4 Failure modes

Any failure on secondary sensor directly affects the performance of Odometry application[ci]. It is more explained
in Odometry Application.

12.4 Crash Protected Memory

Important: This component is included in the iEVC Basic kit[ci]

12.4.1 Description

The CPM is a networked drive used to store, among other things, the juridical data as described in
[SyAD-R31-TSI-LOCPAS:2014] and Subset 027. Therefore, this drive is engineered to withstand the crash of
a train.

12.4. Crash Protected Memory 633 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.4.2 Interfaces

The CPM is mainly interfaced, through the network, to the on-board operation and maintenance software (a.k.a.
OBOM). The related physical interface is CPM - Ethernet interface[ci] while the functional interface is CPM -
OBOM interface[ci]
This interface is used for two purposes:
• Accessing the CPM for reading and writing log files over the network
• Obtaining the maintenance and faults information related to the CPM
The CPM may also be connected to a laptop in order to recover the log files or to update the application package
files and certificate. JRU log files may be decoded using the JRU decoder.

Figure 12.9: CPM logical interfaces

634 of 750 12.4. Crash Protected Memory

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.4.3 Functions

12.4.3.1 [IEVC.F5.05.02] Record data in crash protected memory [function]

Data
• Definition: The iEVC on-board subsystem records operation data and regulatory data in a crash
protected memory. This data includes timed events, GPS data, maintenance activity and predictive
maintenance information.
• Allocated to:
– Crash protected memory[ci]
• Input:
– OBOM log file[functional variable][CPM - OBOM interface]
• Output:
– OBOM log file[functional variable][CPM - OBOM interface]
– iEVC Configuration Data Files[functional variable][SIDE Configurator User Interface]
– Application package certificate[functional variable][SIDE Authorizer User Interface]
– Application package[functional variable][CPM - OBOM interface]
• Sil: basic
• Associated interface:
– CPM - OBOM interface[ci]
– CPM - OBOM interface[ci]
– SIDE Configurator User Interface[ci]
– SIDE Authorizer User Interface[ci]

12.4.3.2 [IEVC.F4.28.12] CPM - Provide maintenance and fault information [function]

Data
• Definition: Provide maintenance and fault information to the on-board operation and maintenance
system. This includes internal faults and configuration information.
• Allocated to:
– Crash protected memory[ci]
• Output:
– CPM Maintenance Data[functional variable][CPM - OBOM interface]
• Sil: basic
• Associated interface:
– CPM - OBOM interface[ci]

12.4. Crash Protected Memory 635 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.4.4 Requirements

Requirement

The CPM shall report maintenance and faults information. [id:tsc-req-ievc-cpm-report-faults][p2][ns]

At a minimum, the CPM should report faults that can result in the impossibility to read or write data on it,
and the configuration information (hardware and software versions)

Requirement

The CPM shall report available capacity storage [id:tsc-req-ievc-cpm-report-available-capacity][p2][s]

An alarm is generated when the capacity of CPM reaches a defined threshold (refer to tsc-req-ievc-ob-cb-
obom-capacity-alarm[req]).

Requirement

The CPM shall provide read and write access to files through a network interface [id:tsc-req-ievc-cpm-
rw-access][p2][ns]

Allocate
Allocation of JRU protection requirement [allocate]
Data
• Requirement:
– tsc-req-ievc-pqp-jru-62625-1-4-3-1-7[req]
– tsc-req-ievc-pqp-jru-62625-1-4-2-2[req]
• Ci:
– Crash protected memory[ci]
• Justification: The CPM main purpose is to fulfill the protection requirements of EN 62625
standard

Requirement

Network access to the files on the CPM shall be protected [id:tsc-req-ievc-cpm-access-control][p2][s]

A provably NIST-recommended secure protocol shall be used (e.g. SSH).

Allocate
Allocation of recorded data retrieval requirement [allocate]

636 of 750 12.4. Crash Protected Memory

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-ievc-pqp-jru-62625-1-4-2-3[req]
• Ci:
– Crash protected memory[ci]
• Justification: The CPM shall ensure retrieval of recorded data

Requirement

The CPM shall not overwrite data until at least 8 days have elapsed after it was recorded [id:tsc-req-
ievc-cpm-data-storage-capacity][p2][ns]

Requirement

The CPM shall contain the necessary galvanically isolated power adapter. The adapter output shall
not float and shall be referenced to an earth point. [id:tsc-req-ievc-cpm-galvanically-isolated][p2][s]

12.4.5 Failure modes

12.4.5.1 Failure to log and retrieve maintenance data

A failure of the CPM may result in the impossibility to log data or to recover the logged data or in the corruption of
the logged information. This may impact the capacity of the iEVC On-board to execute the following maintenance
functions:
• [IEVC.F4.28] Provide maintenance and fault information[function]
• [IEVC.F4.17] Record a maintenance activity[function]
• [IEVC.F5.05] Record selected variables[function]
• [IEVC.F4.07] Determine estimated lifetime and trigger lifetime warning.[function]
• [IEVC.F4.14] Produce service report[function]
• [IEVC.F4.13] Produce event report[function]
The CPM unit needs to be repaired or replaced.

12.4.5.2 Failure to retrieve application package files

A failure of the CPM may result in the impossibility to recover the application package files or in the corruption of
these files. If the files are not loaded correctly at start-up, the VM will go to ‘VM_FAULT’ mode that will trigger
the ‘Fail Safe mode’ of the safe computer (refer to VM Initialization States and Safe computer). Any corruption
of an application package file is detected through [IEVC.F1.05.10] Verify Authorization[function] that is executed
by the VM. This will result in the same ‘Fail Safe mode’ of the safe computer.
The CPM unit needs to be repaired or replaced.

12.4. Crash Protected Memory 637 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.4.5.3 Failure to read or write operational data

A failure of the CPM may result in the impossibility to achieve [IEVC.F5.09] Manage non-volatile operational
data[function]. The consequence is that the iEVC applications that use this function cannot recover operational
variables from the previous run. The reaction to this type of failure must be application specific.
The CPM unit needs to be repaired or replaced.

12.5 GSM-R Modem

Important: This component is included in the iEVC Telecom kit[ci]

12.5.1 Description

The GSM-R modem component allows the iEVC On-board subsystem to interface with the GSM-R infrastructure
([SyAD-R21-EIRENE-FRS], [SyAD-R22-EIRENE-SRS]).
The GSM-R modem supports the following communication modes :
• Circuit Switched Data for the communication with GSM-R baseline 1 infrastructure (or when the other
mode is not available). In this mode the transmission rate is 9,6 kbits/s.
• Packet Switched Data for communication with GSM-R baseline 1 infrastructures. In this mode there are
two variants:
– General Packet Radio Service (GPRS) . This mode allows a maximum transmission rate of 64.2 kbits/s
in download and 42.8 kbits/s in upload.
– Enhanced GPRS (or EDGE) This mode allows a maximum transmission rate of 177.6 kbits/s in down-
load and 118.4 kbits/s in upload.
As shown in the next figure, the interface between the GSM-R modem and the rest of iEVC system depends on
the technology of the modem. Nevertheless, the Safe computer[ci] communicates with UDP/IP messages. That
means that a protocol converter shall be added when needed.

638 of 750 12.5. GSM-R Modem

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.5.2 Modes

This component has the following modes:

Table 12.2: GSM-R modem operational mode

Mode Active functions
Off
Starting
• [IEVC.F3.02.08.02.01] Perform GSM-R modem startup[function],
• [IEVC.F4.28.08] GSM-R modem - Provide maintenance and fault informa-
tion[function],
• [IEVC.F4.32.08] Reset GSM-R modem[function]

Not Connected
• [IEVC.F4.28.08] GSM-R modem - Provide maintenance and fault informa-
tion[function],
• [IEVC.F4.32.08] Reset GSM-R modem[function],
• [IEVC.F3.02.08.02.03] Manage the connection with a Circuit Switch infras-
tructure[function],
• [IEVC.F3.02.08.02.04] Manage the connection with a Packet Switched in-
frastructure[function]

Connecting to a CS
• [IEVC.F4.28.08] GSM-R modem - Provide maintenance and fault informa-
GSM-R
tion[function],
• [IEVC.F4.32.08] Reset GSM-R modem[function],
• [IEVC.F3.02.08.02.03] Manage the connection with a Circuit Switch infras-
tructure[function]

Connecting to a PS
• [IEVC.F4.28.08] GSM-R modem - Provide maintenance and fault informa-
GPRS
tion[function],
• [IEVC.F4.32.08] Reset GSM-R modem[function],
• [IEVC.F3.02.08.02.02] Collect the list of available services[function]
• [IEVC.F3.02.08.02.04] Manage the connection with a Packet Switched in-
frastructure[function]

Connected to a CS GSM-
• [IEVC.F4.28.08] GSM-R modem - Provide maintenance and fault informa-
R
tion[function],
• [IEVC.F4.32.08] Reset GSM-R modem[function],
• [IEVC.F3.02.08.07.01] Exchange data over GSM-R[function]

Connected to a PS GPRS
• [IEVC.F4.28.08] GSM-R modem - Provide maintenance and fault informa-
tion[function],
• [IEVC.F4.32.08] Reset GSM-R modem[function],
• [IEVC.F3.02.08.07.02] Exchange data over GPRS[function]

The transitions are as follows:

12.5. GSM-R Modem 639 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 12.10: Mode transition diagram of GSM-R modem

Note: The GSM-R modem may be in several modes at the same time in specific operational conditions such as
when attempting to register to a new network or when connecting to a second RBC during hand-over in Packet
Switch Data mode.

640 of 750 12.5. GSM-R Modem

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.5.3 Functions

Figure 12.11: GSMR modem logical architecture

12.5.3.1 [IEVC.F3.02.08.02] Connect to the network [function]

Data
• Definition: This function allows the GSM-R modem to connect to the GSM-R infrastructure.
• Allocated to:
– GSM-R modem[ci]
• Sil: basic
• Sub functions:
– [IEVC.F3.02.08.02.01] Perform GSM-R modem startup[function]
– [IEVC.F3.02.08.02.02] Collect the list of available services[function]
– [IEVC.F3.02.08.02.03] Manage the connection with a Circuit Switch infrastructure[function]
– [IEVC.F3.02.08.02.04] Manage the connection with a Packet Switched infrastruc-
ture[function]

12.5. GSM-R Modem 641 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.5.3.1.1 [IEVC.F3.02.08.02.01] Perform GSM-R modem startup [function]

Data
• Definition: Loads the GSM-R configuration and sim card information services. The configuration
includes: allowed network, configuration of the access to the iEVC network and maintenance report
configuration
• Allocated to:
– GSM-R modem[ci]
• Sil: basic

12.5.3.1.2 [IEVC.F3.02.08.02.02] Collect the list of available services [function]

Data
• Definition: Collects the list of available operators and available services.
• Allocated to:
– GSM-R modem[ci]
• Input:
– GSM-R modem commands[functional variable][Modem Controller - GSM-R Modem Inter-
face]
– GSM-R operator parameters[functional variable]
– Available service answer[functional variable][Euroradio air-gap]
• Output:
– Available service request[functional variable][Euroradio air-gap]
– GSM-R List of available services[functional variable][Modem Controller - GSM-R Modem
Interface]
• Sil: basic
• Associated interface:
– Modem Controller - GSM-R Modem Interface[ci]
– Euroradio air-gap[ci]

12.5.3.1.3 [IEVC.F3.02.08.02.03] Manage the connection with a Circuit Switch infrastructure

[function]

Data
• Definition: Manages the connection to a Circuit Switch infrastructure (GSM-R) according to
AT11T6001 and Subset 037 specifications
• Allocated to:
– GSM-R modem[ci]
• Input:
– GSM-R modem commands[functional variable][Modem Controller - GSM-R Modem Inter-

642 of 750 12.5. GSM-R Modem

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

face]
– GSM-R operator parameters[functional variable]
– Infrastructure network connection response[functional variable][Euroradio air-gap]
• Output:
– Infrastructure network connection[functional variable][Euroradio air-gap]
– GSM-R connection state[functional variable][Modem Controller - GSM-R Modem Interface]
• Sil: basic
• Associated interface:
– Modem Controller - GSM-R Modem Interface[ci]
– Euroradio air-gap[ci]

12.5.3.1.4 [IEVC.F3.02.08.02.04] Manage the connection with a Packet Switched infrastructure

[function]

Data
• Definition: Manages the connection to a Packet Switched infrastructure (GPRS or EDGE) according
to AT11T6001 and Subset 037 specifications. Once connected, the modem starts the Point to Point
Protocol stack. (PPP is defined by RFC 1661).
• Allocated to:
– GSM-R modem[ci]
• Input:
– GSM-R modem commands[functional variable][Modem Controller - GSM-R Modem Inter-
face]
– GSM-R operator parameters[functional variable]
– Infrastructure network connection response[functional variable][Euroradio air-gap]
• Output:
– Infrastructure network connection[functional variable][Euroradio air-gap]
– GSM-R connection state[functional variable][Modem Controller - GSM-R Modem Interface]
• Sil: basic
• Associated interface:
– Modem Controller - GSM-R Modem Interface[ci]
– Euroradio air-gap[ci]

12.5. GSM-R Modem 643 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.5.3.2 [IEVC.F3.02.08.07] Exchange data through radio communication [function]

Data
• Definition: This function allows the GSM-R modem to exchange application data with the ETCS
wayside devices (RBC).
• Allocated to:
– GSM-R modem[ci]
• Sil: basic
• Sub functions:
– [IEVC.F3.02.08.07.01] Exchange data over GSM-R[function]
– [IEVC.F3.02.08.07.02] Exchange data over GPRS[function]

12.5.3.2.1 [IEVC.F3.02.08.07.01] Exchange data over GSM-R [function]

Data
• Definition: Routes messages between iEVC internal network and the Circuit Switch GSM-R net-
work according to AT11T6001 and Subset 037 specifications.
• Allocated to:
– GSM-R modem[ci]
• Input:
– Euroradio Data Link layer data in[functional variable][Euroradio air-gap]
– GSM-R Data to modem[functional variable][Modem Controller - GSM-R Modem Interface]
• Output:
– Euroradio Data Link layer data out[functional variable][Euroradio air-gap]
– GSM-R Data from modem[functional variable][Modem Controller - GSM-R Modem Inter-
face]
• Sil: basic
• Associated interface:
– Euroradio air-gap[ci]
– Modem Controller - GSM-R Modem Interface[ci]

12.5.3.2.2 [IEVC.F3.02.08.07.02] Exchange data over GPRS [function]

Data
• Definition: Routes messages between iEVC internal network and the Packet Switched GSM-R net-
work according to AT11T6001 and Subset 037 specifications. This function handles the PPP proto-
col and the dynamic IP address provided by the operator.
• Allocated to:
– GSM-R modem[ci]
• Input:

644 of 750 12.5. GSM-R Modem

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– Euroradio Data Link layer data in[functional variable][Euroradio air-gap]

– GSM-R Data to modem[functional variable][Modem Controller - GSM-R Modem Interface]
• Output:
– Euroradio Data Link layer data out[functional variable][Euroradio air-gap]
– GSM-R Data from modem[functional variable][Modem Controller - GSM-R Modem Inter-
face]
• Sil: basic
• Associated interface:
– Euroradio air-gap[ci]
– Modem Controller - GSM-R Modem Interface[ci]

12.5.3.3 [IEVC.F4.28.08] GSM-R modem - Provide maintenance and fault information [function]

Data
• Definition: Provides maintenance and fault information about the GSM-R modem.
• Allocated to:
– GSM-R modem[ci]
• Input:
– GSM-R modem commands[functional variable][Modem Controller - GSM-R Modem Inter-
face]
• Output:
– GSM-R low level Maintenance Data[functional variable][Modem Controller - GSM-R Modem
Interface]
• Sil: basic
• Associated interface:
– Modem Controller - GSM-R Modem Interface[ci]

12.5.3.4 [IEVC.F4.32.08] Reset GSM-R modem [function]

Data
• Definition: Reset the GSM-R modem upon reception of a reset order from the modem controller.
• Allocated to:
– GSM-R modem[ci]
• Input:
– GSM-R low level reset order[functional variable][Modem Controller - GSM-R Modem Inter-
face]
• Sil: basic
• Associated interface:
– Modem Controller - GSM-R Modem Interface[ci]

12.5. GSM-R Modem 645 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional architecture.

12.5.4 Interface

The following external interface is applicable to the GSM-R modem:

• Telecom box - GSM-R antenna interface[ci]
The GSM-R modem has the following internal interface:
• Modem Controller - GSM-R Modem Interface[ci].

Note: the implementation of this interface depends on the model of GSM-R modem outsourced.

This interface has the following variables:

Functional Variable
GSM-R modem commands [functional variable]
Data
• Objective: To control the GSM-R modem according to standard A11T6001
• Description: The GSM-R modem shall handle commands specified in the A11T6001 stan-
dard. Such commands include 'Connect in CS mode', 'Connect in PS mode'.
• Family: Software
• Type: AT command specified as A11T6001 and modem specific commands
• Protocol: Vendor dependent protocol
• Associated interface:
– Modem Controller - GSM-R Modem Interface[ci]
• Produced by:
– [IEVC.SW.MC.REQ.REGISTRATION] Request network registration[function]
– [IEVC.SW.MC.REQ.CONNECTION] Request RBC connection[function]
– [IEVC.SW.MC.REQ.DISCONNECTION] Request RBC disconnection[function]
– [IEVC.SW.MC.REQ.AVAILABLE] Request list of available networks[function]
– [IEVC.F4.28.09] Modem controller - Provide maintenance and fault informa-
tion[function]
– [IEVC.F3.02.08.06] Manage Low-level protocol & modem interface[function]
• Consumed by:
– [IEVC.SW.MC.LOGGING] Send all communication with modem over TSC
Net[function]
– [IEVC.F3.02.08.02.02] Collect the list of available services[function]
– [IEVC.F3.02.08.02.03] Manage the connection with a Circuit Switch infrastruc-
ture[function]
– [IEVC.F3.02.08.02.04] Manage the connection with a Packet Switched infrastruc-
ture[function]
– [IEVC.F4.28.08] GSM-R modem - Provide maintenance and fault informa-
tion[function]

646 of 750 12.5. GSM-R Modem

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The standard applicable is described by the document [SyAD-R15-AT11T6001] Radio Transmission

FFFIS for Euroradio.
Specifics AT commands may be used to collect maintenance information.

Functional Variable
GSM-R connection state [functional variable]
Data
• Objective: To provide the state of the connection to the network
• Description: this variable is specified in the standard A11T6001.
• Family: Software
• Type: Specified in A11T6001
• Protocol: Vendor dependent protocol
• Associated interface:
– Modem Controller - GSM-R Modem Interface[ci]
• Produced by:
– [IEVC.F3.02.08.02.03] Manage the connection with a Circuit Switch infrastruc-
ture[function]
– [IEVC.F3.02.08.02.04] Manage the connection with a Packet Switched infrastruc-
ture[function]
• Consumed by:
– [IEVC.SW.MC.RESP.STATUS] Provide modem status[function]
– [IEVC.SW.MC.LOGGING] Send all communication with modem over TSC
Net[function]
– [IEVC.F3.02.08.06] Manage Low-level protocol & modem interface[function]

Refer to [SyAD-R15-AT11T6001] Radio Transmission FFFIS for Euroradio.

Functional Variable
GSM-R List of available services [functional variable]

12.5. GSM-R Modem 647 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To collect the list of available operator services.
• Description: message standardized into the GSM-R specification (refer to AT11T6001 and
Subset 037). This message contains the list of available networks the modem can register
to.
• Family: Software
• Type: Specified in A11T6001
• Protocol: Vendor dependent protocol
• Associated interface:
– Modem Controller - GSM-R Modem Interface[ci]
• Produced by:
– [IEVC.F3.02.08.02.02] Collect the list of available services[function]
• Consumed by:
– [IEVC.SW.MC.RESP.AVAILABLE] Provide list of available networks[function]
– [IEVC.SW.MC.LOGGING] Send all communication with modem over TSC
Net[function]
– [IEVC.F3.02.08.06] Manage Low-level protocol & modem interface[function]

Functional Variable
GSM-R low level Maintenance Data [functional variable]
Data
• Objective: To provide fault and maintenance data about the GSM-R modem
• Description: Set of information vendor dependent that provides configuration information
and fault status of the modem.
• Family: Software
• Type: AT command specified in A11T6001
• Protocol: Vendor dependent protocol
• Associated interface:
– Modem Controller - GSM-R Modem Interface[ci]
• Produced by:
– [IEVC.F4.28.08] GSM-R modem - Provide maintenance and fault informa-
tion[function]
• Consumed by:
– [IEVC.SW.MC.REQ.MAINTENANCE] Provide maintenance and fault informa-
tion[function]
– [IEVC.SW.MC.LOGGING] Send all communication with modem over TSC
Net[function]
– [IEVC.F4.28.09] Modem controller - Provide maintenance and fault informa-
tion[function]

648 of 750 12.5. GSM-R Modem

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
GSM-R Data to modem [functional variable]
Data
• Objective: To send data to an RBC over Euroradio
• Description: application data containing packed ERTMS radio messages.
• Family: Software
• Type: outgoing data to radio
• Protocol: Vendor dependent protocol
• Associated interface:
– Modem Controller - GSM-R Modem Interface[ci]
• Produced by:
– [IEVC.SW.MC.DATA.SEND] Send data[function]
– [IEVC.F3.02.08.06] Manage Low-level protocol & modem interface[function]
• Consumed by:
– [IEVC.SW.MC.LOGGING] Send all communication with modem over TSC
Net[function]
– [IEVC.F3.02.08.07.01] Exchange data over GSM-R[function]
– [IEVC.F3.02.08.07.02] Exchange data over GPRS[function]

The types of message are listed in §8.5.2 of [SyAD-R8-SS026]. Their content is defined in §8.6 and in §7
of [SyAD-R8-SS026].

Functional Variable
GSM-R Data from modem [functional variable]

12.5. GSM-R Modem 649 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To receive data message from an RBC over Euroradio
• Description: application data containing packed ERTMS radio messages.
• Family: Software
• Type: incoming data from radio
• Protocol: Vendor dependent protocol
• Associated interface:
– Modem Controller - GSM-R Modem Interface[ci]
• Produced by:
– [IEVC.F3.02.08.07.01] Exchange data over GSM-R[function]
– [IEVC.F3.02.08.07.02] Exchange data over GPRS[function]
• Consumed by:
– [IEVC.SW.MC.DATA.RECEIVE] Receive data[function]
– [IEVC.SW.MC.LOGGING] Send all communication with modem over TSC
Net[function]
– [IEVC.F3.02.08.06] Manage Low-level protocol & modem interface[function]

The types of message are listed in §8.5.3 of [SyAD-R8-SS026]. Their content is defined in §8.7 and in §7
of [SyAD-R8-SS026].

Functional Variable
GSM-R low level reset order [functional variable]
Data
• Objective: To reset the GSM-R device
• Description: the content, format and protocol are vendor dependent
• Family: Software
• Type: Vendor dependent
• Protocol: Vendor dependent protocol
• Associated interface:
– Modem Controller - GSM-R Modem Interface[ci]
• Produced by:
– [IEVC.F4.32.09] Command GSM-R modem reset[function]
• Consumed by:
– [IEVC.F4.32.08] Reset GSM-R modem[function]

• The following variable are exchanged on the GSM-R air gap (Euroradio air-gap[ci])

650 of 750 12.5. GSM-R Modem

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
Infrastructure network connection [functional variable]
Data
• Objective: To perform operation with GSM-R infrastructure.
• Description: Set of request to perform network operation such as: register, call a peer,
connect in GPRS, request DNS resolution. These actions are standardized by the GSM-R
standard.
• Family: Software
• Type: outgoing data to radio
• Protocol: GSM-R
• Associated interface:
– Euroradio air-gap[ci]
• Produced by:
– [IEVC.F3.02.08.02.03] Manage the connection with a Circuit Switch infrastruc-
ture[function]
– [IEVC.F3.02.08.02.04] Manage the connection with a Packet Switched infrastruc-
ture[function]

Functional Variable
Infrastructure network connection response [functional variable]
Data
• Objective: To provide answer to network operation
• Description: These answers are standardized by the GSM-R specification.
• Family: Software
• Type: incoming data from radio
• Protocol: GSM-R
• Associated interface:
– Euroradio air-gap[ci]
• Consumed by:
– [IEVC.F3.02.08.02.03] Manage the connection with a Circuit Switch infrastruc-
ture[function]
– [IEVC.F3.02.08.02.04] Manage the connection with a Packet Switched infrastruc-
ture[function]

Functional Variable
Available service request [functional variable]

12.5. GSM-R Modem 651 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To request the list of available operator services.
• Description: These requests are standardized by the GSM-R specification (refer to
AT11T6001 and GSM-R standard).
• Family: Software
• Type: outgoing data to radio
• Protocol: GSM-R
• Associated interface:
– Euroradio air-gap[ci]
• Produced by:
– [IEVC.F3.02.08.02.02] Collect the list of available services[function]

Functional Variable
Available service answer [functional variable]
Data
• Objective: To collect the list of available operator services
• Description: These answers are standardized by the GSM-R specification (refer to
AT11T6001 and GSM-R standard).
• Family: Software
• Type: incoming data from radio
• Protocol: GSM-R
• Associated interface:
– Euroradio air-gap[ci]
• Consumed by:
– [IEVC.F3.02.08.02.02] Collect the list of available services[function]

Functional Variable
Euroradio Data Link layer data out [functional variable]

652 of 750 12.5. GSM-R Modem

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To send data message over Euroradio
• Description: Euroradio message containing the ERTMS radio data to transfer to an RBC
• Family: Software
• Type: outgoing data to radio
• Protocol: GSM-R
• Associated interface:
– Euroradio air-gap[ci]
• Produced by:
– [IEVC.F3.02.08.07.01] Exchange data over GSM-R[function]
– [IEVC.F3.02.08.07.02] Exchange data over GPRS[function]

Functional Variable
Euroradio Data Link layer data in [functional variable]
Data
• Objective: To receive data message over Euroradio
• Description: Euroradio message containing the ERTMS radio data received from an RBC
• Family: Software
• Type: incoming data from radio
• Protocol: GSM-R
• Associated interface:
– Euroradio air-gap[ci]
• Consumed by:
– [IEVC.F3.02.08.07.01] Exchange data over GSM-R[function]
– [IEVC.F3.02.08.07.02] Exchange data over GPRS[function]

12.5.5 Parameters

Functional Variable
GSM-R modem network parameters [functional variable]

12.5. GSM-R Modem 653 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide the network parameter to the GSM-R modem.
• Description: This variable contains network parameter for the GSM-R modem operation
(IP address).
• Family: Software
• Type: Internet Protocol Address
• Format: SSS.SSS.SSS.XXX (SSS.SSS.SSS: subnet address, address in the subnet)
• Protocol: System Parameters

Functional Variable
GSM-R operator parameters [functional variable]
Data
• Objective: To provide the GSM-R operator parameters to the GSM-R modem.
• Description: This variable contains the set of parameters needed to connect the GSM-R
network. These parameter are stored in the SIM Card.
• Family: Software
• Protocol: System Parameters
• Consumed by:
– [IEVC.F3.02.08.02.02] Collect the list of available services[function]
– [IEVC.F3.02.08.02.03] Manage the connection with a Circuit Switch infrastruc-
ture[function]
– [IEVC.F3.02.08.02.04] Manage the connection with a Packet Switched infrastruc-
ture[function]

12.5.6 Requirements

Requirement

The GSM-R modem shall interface the Safe computer with an Ethernet link [id:tsc-req-ievc-gsmr-
ethernet-interface][p2][ns]

If the selected modem do not provide a native Ethernet interface, a converter shall be added. This converter
shall translate:
• incoming message from the modem to UDP message to the modem controller inside the Safe com-
puter.
• UDP messages received from the modem controller of the Safe computer to outgoing message to
the GSM-R modem.

Requirement

The GSM-R modem shall support GSM-R mobile protocol [id:tsc-req-ievc-gsmr-gsm-r][p1][ns]

654 of 750 12.5. GSM-R Modem

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The GSM-R modem shall support GPRS class 10 mobile protocol [id:tsc-req-ievc-gsmr-gprs][p1][ns]

The modem shall support all the Coding Schemes (CS1 - CS4)

Requirement

The GSM-R modem shall support EGPRS(EDGE) class 10 mobile protocol [id:tsc-req-ievc-gsmr-
egprs][p1][ns]

The modem shall support most efficient Modulation coding schemes ( minimum MCS 5 to MCS 9)

Requirement

The GSM-R modem shall product an output radio frequency power compatible with Class 2 (8W)
[id:tsc-req-ievc-gsmr-rfpower][p1][ns]

Requirement

The GSM-R modem shall support PPP stack when operating in PS mode (GPRS or EGPRS). [id:tsc-
req-ievc-gsmr-ppp][p1][ns]

Requirement

The GSM-R shall support GSM-R frequency used in Europe. [id:tsc-req-ievc-gsmr-frequency][p1][ns]

For Europe operation, the minimum is to support the 900 MHz band ( 876 MHz - 880 MHz up-link, 921
MHz - 925 MHz down-link)

Requirement

The GSM-R modem shall report maintenance and fault information to the modem controller upon
request. [id:tsc-req-ievc-gsmr-faults][p2][ns]

Requirement

The GSM-R modem shall reset itself upon reception of a reset order from the modem controller
[id:tsc-req-ievc-gsmr-reset][p2][ns]

Allocate
The GSM-R modem shall be compliant with A11T6001 [allocate]
Data
• Requirement:
– tsc-req-urs-nobo-a11t6001[req]
– tsc-req-id-subset-037-euroradio-6-1-1-2[req]
• Ci:
– GSM-R modem[ci]
• Justification: To be able to perform tests required by the Subset-092-1

12.5. GSM-R Modem 655 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Allocate
The GSM-R modem shall be compliant with GSM-R Baseline 1 [allocate]
Data
• Requirement:
– tsc-req-urs-nobo-eirene-frs[req]
– tsc-req-urs-nobo-eirene-srs[req]
– tsc-req-urs-nobo-morane-f12-t6003[req]
– tsc-req-urs-nobo-etsi-ts-102610[req]
– tsc-req-urs-nobo-morane-f10-t6002[req]
– tsc-req-urs-nobo-morane-f12-t6002[req]
– tsc-req-urs-nobo-morane-e10-t6001[req]
– tsc-req-urs-nobo-morane-e12-t6001[req]
– tsc-req-urs-nobo-morane-f10-t6001[req]
– tsc-req-urs-nobo-morane-f12-t6001[req]
– tsc-req-urs-nobo-morane-f10-t6003[req]
– tsc-req-urs-nobo-morane-f12-t6003[req]
– tsc-req-urs-nobo-etsi-en-301515[req]
– tsc-req-urs-nobo-etsi-ts-102281[req]
– tsc-req-urs-nobo-etsi-ts-103169[req]
– tsc-req-urs-nobo-morane-p38-t9001[req]
• Ci:
– GSM-R modem[ci]
• Justification: EIRENE and MORANE standards are required by the CCS TSI. They can be
allocated directly to the GSM-R modem.

Allocate
GSM-R modem installation instructions shall provide exported constraints [allocate]
Data
• Requirement:
– tsc-req-urs-install-ievc-gsmr-gps-antennas-immune-against-motorola-alike-radio[req]
• Ci:
– GSM-R antenna[ci]
– GPS antenna[ci]
– 4G antenna[ci]
• Justification: Such constraints shall be taken into account by the installation design.

656 of 750 12.5. GSM-R Modem

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Allocate
GSM-R, GPS and 4G antenna documentation shall specify the maximum amount of snow that can
cover GSM-R modem antenna. [allocate]
Data
• Requirement:
– tsc-req-urs-install-ievc-gsmr-gps-4g-document-max-snow[req]
• Ci:
– GSM-R antenna[ci]
– 4G antenna[ci]
– GPS antenna[ci]
• Justification: Such constraints shall be taken into account by the installation design.

12.5.7 Failure modes

12.5.7.1 Complete failure of a GSM-R modem

When a GSM-R modem[ci] fails, the iEVC On-board subsystem will continue operating with the second one. This
fault is reported to the OBOM[ci] by the function [IEVC.F4.28.08] GSM-R modem - Provide maintenance and
fault information[function].

12.5.7.2 Complete failure of both GSM-R modems

When the both GSM-R modem[ci] are failed, ERTMS operational modes that requires Euroradio (e.g. full su-
pervision level 2 and 3) are no more available. The service can continue in ERTMS operation in level 1, staff
responsible or in an available National System mode.

12.6 4G Modem

Important: This component is included in the iEVC Telecom kit[ci]

12.6.1 Description

The 4G modem provide an internet access for the iEVC network (described by section Network architecture) as
well as a GPS positioning and time information.

Note: In this version of the document, the 4G modem is installed on-board but the 4G connection is disabled
(for example by removing the SIM card). The functions and interfaces related to the internet access described
below are therefore disabled. The descriptions are kept in this document to allow starting the sourcing process
of this component. Only the functions [IEVC.F4.28.05] 4G modem - Provide maintenance and fault informa-
tion[function] and [IEVC.F5.03] Record GPS position and time[function] and he interface NMEA 0183 GPS
interface[ci] remain applicable.

12.6. 4G Modem 657 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

As a regular cell phone the 4G modem uses sim cards to access to operator network. The 4G modem is able to
manage several SIM Cards, allowing for example to change operator when crossing a border in order to avoid loss
of communication.

12.6.2 Modes

This component has the following modes:

Table 12.3: 4G modem operational mode

Mode Active functions
Off
Starting
• [IEVC.F4.30.01] Perform 4G connection startup[function]

Select a 4G operator net-

• [IEVC.F4.30.02] Manage sim card handover[function],
work
• [IEVC.F4.30.05] Protect iEVC network from unauthorized ac-
cess.[function],
• [IEVC.F4.28.05] 4G modem - Provide maintenance and fault informa-
tion[function],
• [IEVC.F5.03.01] Determine GPS position and time[function],
• [IEVC.F4.32.06] Reset 4G modem[function]

Connect to the 4G opera-

• [IEVC.F4.30.03] Manage the connection with the 4G operator[function],
tor network
• [IEVC.F4.30.05] Protect iEVC network from unauthorized ac-
cess.[function],
• [IEVC.F4.28.05] 4G modem - Provide maintenance and fault informa-
tion[function],
• [IEVC.F5.03.01] Determine GPS position and time[function],
• [IEVC.F4.32.06] Reset 4G modem[function]

Exchange data over the

• [IEVC.F4.30.04] Exchange data over 4G Network[function],
4G Network
• [IEVC.F4.30.05] Protect iEVC network from unauthorized ac-
cess.[function],
• [IEVC.F4.28.05] 4G modem - Provide maintenance and fault informa-
tion[function],
• [IEVC.F5.03.01] Determine GPS position and time[function],
• [IEVC.F4.32.06] Reset 4G modem[function]

The transitions are as follows:

658 of 750 12.6. 4G Modem

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 12.12: Mode transition diagram of 4G modem

12.6.3 Functions

12.6.3.1 [IEVC.F4.30.01] Perform 4G connection startup [function]

Data
• Definition: Load modem configuration and operator information from a set of SIM Card, then con-
nect to iEVC network. The configuration include: connection credentials to the operator network,
roaming authorization (for iEVC services multi country locomotive) and allowed networks, firewall
configuration that is a set of security rules.
• Allocated to:
– 4G modem[ci]
• Input:
– 4G modem network parameters[functional variable]
– 4G modem operator parameters[functional variable]
• Sil: basic

12.6. 4G Modem 659 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Note: this function is out of the scope for this version of the document.

12.6.3.2 [IEVC.F4.30.02] Manage sim card handover [function]

Data
• Definition: Manage the handover between SIM card when a change of network is required.
• Allocated to:
– 4G modem[ci]
• Sil: basic

Note: this function is out of the scope for this version of the document.

12.6.3.3 [IEVC.F4.30.03] Manage the connection with the 4G operator [function]

Data
• Definition: Manage connection to operator infrastructure (Connection, Roaming)
• Allocated to:
– 4G modem[ci]
• Sil: basic

Note: this function is out of the scope for this version of the document.

12.6.3.4 [IEVC.F4.30.04] Exchange data over 4G Network [function]

Data
• Definition: Route message between iEVC internal network and the outside network. This function
handle the dynamic IP address provided by the operator.
• Allocated to:
– 4G modem[ci]
• Sil: basic

Note: this function is out of the scope for this version of the document.

660 of 750 12.6. 4G Modem

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.6.3.5 [IEVC.F4.30.05] Protect iEVC network from unauthorized access. [function]

Data
• Definition: Ensure the network security by controlling incoming and outgoing network traffic based
on security rules that configure the filtering of protocols, port, or IP addresses.
• Allocated to:
– 4G modem[ci]
• Sil: basic

Note: this function is out of the scope for this version of the document.

12.6.3.6 [IEVC.F4.28.05] 4G modem - Provide maintenance and fault information [function]

Data
• Definition: Provide maintenance and fault information about the 4G modem to OBOM software of
the iEVC.
• Allocated to:
– 4G modem[ci]
• Input:
– 4G modem configuration request[functional variable][4G Modem - OBOM interface]
• Output:
– 4G modem Maintenance Data[functional variable][4G Modem - OBOM interface]
• Sil: basic
• Associated interface:
– 4G Modem - OBOM interface[ci]

12.6.3.7 [IEVC.F5.03.01] Determine GPS position and time [function]

Data
• Definition: Provide an estimated geographical position and the current coordinated universal time
(UTC) form an internal Global Navigation Satellite System (GNSS) receiver.
• Allocated to:
– 4G modem[ci]
• Output:
– NMEA 0183 GPS[functional variable][NMEA 0183 GPS interface]
• Sil: basic
• Associated interface:
– NMEA 0183 GPS interface[ci]

12.6. 4G Modem 661 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.6.3.8 [IEVC.F4.32.06] Reset 4G modem [function]

Data
• Definition: Reset the 4G modem upon reception of a reset order through Ethernet.
• Allocated to:
– 4G modem[ci]
• Input:
– 4G modem reset order[functional variable][4G Modem - OBOM interface]
• Sil: basic
• Associated interface:
– 4G Modem - OBOM interface[ci]

Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional architecture.

12.6.4 Interface

The following external interfaces are applicable to the 4G modem:

• 4G Modem - OBOM interface[ci]
This interface includes these variables:
– 4G modem Maintenance Data[functional variable][4G Modem - OBOM interface]
– 4G modem configuration request[functional variable][4G Modem - OBOM interface]
– 4G modem reset order[functional variable][4G Modem - OBOM interface]
Refer to [SyAD-R63-SIF-OBOM-4G].
• NMEA 0183 GPS interface[ci]
This interface includes this variable:
Functional Variable
NMEA 0183 GPS [functional variable]

662 of 750 12.6. 4G Modem

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide the current estimated geographical position
– Description: 4G modem reports the current geographical position as a
NMEA 0183 Frame. This frame can transmitted through a TSC Net mes-
sage.
– Family: Software
– Type: NMEA 0183 Frame
– Format: BSON
– Protocol: TSC Net
– Timing constraints: Cyclic (frequency depending on the GPS module).
– Associated interface:

* NMEA 0183 GPS interface[ci]

– Produced by:

* [IEVC.F5.03.01] Determine GPS position and time[function]

– Consumed by:

* [IEVC.SW.Adapter.GPS.CONVERT] Convert NMEA 0183 frame

(GGA and RMC)[function]

* [IEVC.SW.Adapter.GPS.PUBLISH_MAINTENANCE_DATA] Pro-
vide maintenance data[function]

Requirement

The 4g modem shall report maintenance and faults information to the OBOM software. [id:tsc-req-
ievc-4g-modem-faults][p2][ns]

Requirement

The 4g modem shall reset itself upon reception of a reset order through Ethernet [id:tsc-req-ievc-4g-
modem-reset][p2][ns]

Requirement

The SIM card slots of the 4G modem shall be designed in such way that they guarantee that the SIM
cards remain in place at all time during operation. [id:tsc-req-ievc-4g-modem-sim-slot][p2][ns]

The SIM card shall remain in position even when subject to vibration due to the train movement.

12.6.7 Failure modes

12.6.7.1 Complete failure of the 4G modem

A complete failure of the 4G modem[ci] is not critical. When this occur:

• the remote maintenance functions are not available. In that case the maintenance data are available on the
DMI[ci]. Remote investigation shall be done by phone.
• maintenance events cannot be localized with the GPS data.

12.7 DMI hardware

Important: This component is included in the iEVC Basic kit[ci]

12.7.1 Description

The DMI hardware is the main device for the interface between the ETCS and the driver. It provides the screen
to display the relevant information, the loudspeaker to play sounds and the interface to get inputs from the driver
(touchscreen or soft-key). It is also used in the scope of maintenance operation. It is composed of the hardware
parts and an operating system. An Ethernet connection allows the communication between the DMI computer and
the other parts of iEVC.
It is a user requirement to be able to have duplicated screens for the display. Two configurations are possible
to fulfill this requirement: the DMI device can be duplicated in each cabin or a dual-screen device can be used.
For a dual-screen solution, each screen and related driver inputs shall be managed separately, the failure of one
screen shall have no impact on the other one, the two screens can be embedded in the same device or two identical
devices can be used. The choice of the solution will be done by the installation project.

12.7. DMI hardware 665 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Allocate
The DMI shall have two separate screens. [allocate]
Data
• Requirement:
– tsc-req-urs-driver-dmi-two-screens[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: DMI hardware
• Justification: The installation project can decide which solution to use between a simple
screen, dual-screen or duplicated DMI device. The iEVC On-board architecture allows the
system to be compatible with any of those solutions.

12.7.2 Modes

This component has no specific mode.

12.7.3 Functions

12.7.3.1 [IEVC.F3.02.09.01] Display information and collect user inputs [function]

Data
• Definition: This function manages the system startup, supervises the hosted application and provides
them access to hardware resources (screen, user inputs, ...).
• Allocated to:
– DMI hardware[ci]
• Input:
– DMI sound[functional variable][DMI ETCS User Interface][DMI Fault User Interface][DMI
Maintenance User Interface]
– DMI screen[functional variable][DMI ETCS User Interface][DMI Fault User Interface][DMI
Maintenance User Interface]
– DMI hardware screen activation request[functional variable][DMI ETCS User Interface][DMI
Fault User Interface][DMI Maintenance User Interface]
• Output:
– DMI user input[functional variable][DMI ETCS User Interface][DMI Fault User Inter-
face][DMI Maintenance User Interface]
– DMI hardware screen activation status[functional variable][DMI ETCS User Interface][DMI
Fault User Interface][DMI Maintenance User Interface]
• Sil: basic
• Associated interface:
– DMI ETCS User Interface[ci]
– DMI Fault User Interface[ci]

666 of 750 12.7. DMI hardware

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– DMI Maintenance User Interface[ci]

At boot, the DMI performs self-tests, loads services, performs the connection to the iEVC network and starts the
applications (DMI checker, DMI software). It manages the watchdog in order to perform a reboot of the DMI
computer in case of critical system failure.

12.7.4 Interface

The following external interfaces are applicable to the DMI hardware:

• Physical interface:
– DMI - Ethernet interface[ci]
• Functional interfaces:
– DMI ETCS User Interface[ci] (refer to [SyAD-R17-DMI])
– DMI Fault User Interface[ci] (refer to [SyAD-R72-SIF-Maintenance-Fault-UI])
– DMI Maintenance User Interface[ci] (refer to [SyAD-R72-SIF-Maintenance-Fault-UI])
The DMI User interfaces contain the following variables:

Functional Variable
DMI screen [functional variable]
Data
• Objective: To provide the display on the DMI screen.
• Description: the actual picture defined by the screen resolution and color range.
• Family: Software
• Type: vendor dependent
• Format: vendor dependent
• Protocol: vendor dependent
• Timing constraints: Event
• Associated interface:
– DMI ETCS User Interface[ci]
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]
• Produced by:
– [IEVC.F3.02.09.02.01] Check consistency of display output from the DMI soft-
ware[function]
– [IEVC.F3.02.09.02] Verify safety-related display and driver input[function]
• Consumed by:
– [IEVC.F3.02.09.01] Display information and collect user inputs[function]
– [IEVC.F3.02.09.02.02] Manage safe driver input[function]

Note: The format of this variable depends on the DMI computer vendor. It is not specified in this version

12.7. DMI hardware 667 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

of the specification.

Functional Variable
DMI hardware screen activation request [functional variable]
Data
• Objective: To command the activation of the display on the DMI hardware screen.
• Description: the content of the message is vendor dependent.
• Family: Software
• Type: vendor dependent
• Format: vendor dependent
• Protocol: vendor dependent
• Timing constraints: Event
• Associated interface:
– DMI ETCS User Interface[ci]
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]
• Produced by:
– [IEVC.F3.02.09.02.04] Manage DMI screen activation[function]
• Consumed by:
– [IEVC.F3.02.09.01] Display information and collect user inputs[function]

Note: The format of this variable depends on the DMI computer vendor. It is not specified in this version
of the specification.

Functional Variable
DMI hardware screen activation status [functional variable]

668 of 750 12.7. DMI hardware

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide the activation status of the DMI hardware screen.
• Description: the content of the message is vendor dependent.
• Family: Software
• Type: vendor dependent
• Format: vendor dependent
• Protocol: vendor dependent
• Timing constraints: Event
• Associated interface:
– DMI ETCS User Interface[ci]
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]
• Produced by:
– [IEVC.F3.02.09.01] Display information and collect user inputs[function]
• Consumed by:
– [IEVC.F3.02.09.02.04] Manage DMI screen activation[function]

Note: The format of this variable depends on the DMI computer vendor. It is not specified in this version
of the specification.

Functional Variable
DMI user input [functional variable]

12.7. DMI hardware 669 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide the user input performed on the DMI
• Description: It can be a key event: for soft-key technology or acknowledgment with
the external button, the parameters contain the identifier of the key and its new status
(pressed/released). It can be a touch event: for touchscreen technology, the parameters
contain the coordinate of the touch input and its new status (pressed / released).
• Family: Software
• Type: vendor dependent
• Format: vendor dependent
• Protocol: vendor dependent
• Timing constraints: Event
• Associated interface:
– DMI ETCS User Interface[ci]
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]
• Produced by:
– [IEVC.F3.02.09.01] Display information and collect user inputs[function]
• Consumed by:
– [IEVC.F3.02.09.03] Manage ETCS display information[function]
– [IEVC.F3.02.09.02.02] Manage safe driver input[function]
– [IEVC.F3.02.09.02] Verify safety-related display and driver input[function]

Note: The format of this variable depends on the DMI computer vendor. It is not specified in this version
of the specification.

Functional Variable
DMI sound [functional variable]

670 of 750 12.7. DMI hardware

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide the sounds to the user
• Description: it is the sounds played by the DMI loudspeaker
• Family: Software
• Type: vendor dependent
• Format: vendor dependent
• Protocol: vendor dependent
• Timing constraints: Event
• Associated interface:
– DMI ETCS User Interface[ci]
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]
• Produced by:
– [IEVC.F3.02.09.03] Manage ETCS display information[function]
– [IEVC.F3.02.09.03.01] Manage intense light condition[function]
• Consumed by:
– [IEVC.F3.02.09.01] Display information and collect user inputs[function]

Note: The format of this variable depends on the DMI computer vendor. It is not specified in this version
of the specification.

12.7.5 Parameters

The DMI hardware has no parameter.

12.7.6 Requirements

Requirement

The DMI shall allow displaying information and collecting user inputs. [id:tsc-req-ievc-ob-dmi-hw-req-
display][p2][ns]

Requirement

It shall be possible to code an identifier via a connector (ie in the power supply plug). [id:tsc-req-ievc-
ob-dmi-hw-req-id][p2][ns]

Four different identifiers are required and shall be accessible to the hosted software application.

12.7. DMI hardware 671 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The DMI device identifiers shall be coded through their connectors using the following mapping:
for full screen configuration: Cabin A - main device: ID 1; Cabin A - backup device: ID 3; Cabin
B - main device: ID 2; Cabin B - backup device: ID 4; for dual-screen configuration: Cabin A - left
device: ID 1; Cabin A - right device: ID 3; Cabin B - left device: ID 2; Cabin B - right device : ID 4.
[id:tsc-req-ievc-ob-dmi-hw-req-id-mapping][p1][ns]

Requirement

On the rear side, connectors shall be uniquely identified. [id:tsc-req-ievc-ob-dmi-hw-req-00][p2][ns]

The front side of the DMI is its screen, all connectors are on the rear side and shall be uniquely identified.

Requirement

The DMI hardware shall provide 2 individual Ethernet connectors. [id:tsc-req-ievc-ob-dmi-hw-

req03][p2][ns]

The connectors shall be RJ45 with a lock system (M12 to avoid) and are parts of the Telecom box -
Ethernet interface.

Requirement

It shall be possible to update the whole system via Ethernet. [id:tsc-req-ievc-ob-dmi-os-req1][p2][ns]

The DMI computer shall provide a mechanism to perform an update of the complete system or only a
part of it (DMI software, DMI checker, configuration data, . . . ) via Ethernet. SSH connection shall be
provided. Details will be provided later.

This is to avoid a too high volume that may disturb or even hurt the driver.

Requirement

For dual-screen DMI devices, the failure of one screen shall have no impact on the function of the
second one. [id:tsc-req-ievc-ob-dmi-hw-dualscreen-failure][p2][ns]

Requirement

The DMI screen shall be able to have a luminance of 1000cd/m2 or higher. [id:tsc-req-ievc-ob-dmi-hw-
req3][p1][ns]

The maximum luminance of the DMI screen shall be sufficient to have a comfortable visibility of the
displayed information under intense light conditions like sun or direct daylight. Furthermore, the screen
shall have an anti-reflection layer.

Requirement

The DMI screen shall have a 170° angle of vision or higher. [id:tsc-req-ievc-ob-dmi-hw-req4][p1][ns]

The angle of view for the DMI screen shall have a wide range for a comfortable use by the driver.

Requirement

The minimum size of the total image display area shall be 180 mm x 135 mm (w x h). [id:tsc-req-ievc-
ob-dmi-hw-req6][p1][ns]

For dual-screen solution, it means that the minimum size of each screen shall be 90 mm x 135 mm (w x
h), assuming that the display area covers the whole screen (no unused border).

Requirement

The minimum resolution of the total image display area shall be based on a total grid array of 640 x
480 square cells. [id:tsc-req-ievc-ob-dmi-hw-req8][p1][ns]

For dual-screen solution, it means that the minimum resolution of each display area shall be 320 x 480
square cells. All superior ratios are authorized.

Requirement

The display shall support 24-bit RGB color. [id:tsc-req-ievc-ob-dmi-hw-req9][p1][ns]

At least, the following 24-bit RGB color values shall be supported.

12.7. DMI hardware 673 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Nr Color Red Green Blue

1 white 255 255 255
2 black 0 0 0
3 Grey 195 195 195
4 medium Grey 150 150 150
5 dark Grey 85 85 85
6 dark blue 3 17 34
7 shadow 8 24 57
8 yellow 223 223 0
9 orange 234 145 0
10 red 191 0 2
11 PASP dark 33 49 74
12 PASP light 41 74 107

Requirement

It shall be possible to adjust the luminance of the screen. [id:tsc-req-ievc-ob-dmi-hw-req10][p1][s]

The DMI computer shall provide the function and its driver in order to allow control of the screen lumi-
nance by the DMI software.

Requirement

It shall be possible to adjust the sound volume. [id:tsc-req-ievc-ob-dmi-hw-req11][p1][s]

The DMI computer shall provide the function and its driver in order to allow control the volume of the
loudspeaker by the DMI software.

Allocate
The DMI hardware shall be capable of displaying additional applications. [allocate]
Data
• Requirement:
– tsc-req-urs-driver-dmi-extensibility[req]
• Ci:
– DMI hardware[ci]
• Justification: This is a direct allocation of the URS requirement to the DMI hardware to be
able to display information from another source than ETCS or class B applications.

The DMI hardware should have some spare connector or mechanism like a screen cast over Ethernet that
allows to stream a third party video feet.

Requirement

The DMI hardware shall implement touchscreen or soft-key technology to capture driver inputs.
[id:tsc-req-ievc-ob-dmi-hw-req13][p1][ns]

The choice of the technology will be done by the installation project. For soft-key technology, the size and
location of key shall be compliant with ERTMS-015560.

674 of 750 12.7. DMI hardware

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The DMI hardware shall provide a watchdog function. [id:tsc-req-ievc-ob-dmi-hw-req14][p1][s]

The watchdog supervises the execution of the DMI software on the DMI computer. The watchdog will
reboot the system in case of too long DMI software execution time. If the DMI doesn’t recover a working
state after a limited number of reboot, it stays in its failed state until the next hardware reboot.

Requirement

The DMI hardware shall provide an input to connect an external button. [id:tsc-req-ievc-ob-dmi-hw-
external-ack][p2][ns]

Requirement

The DMI computer shall implement a mechanism to detect a freeze of the display and provide the
detection result in its maintenance data. [id:tsc-req-ievc-ob-dmi-hw-image-freeze][p2][s]

Allocate
Requirements from ERA_ERTMS_015560 that can be allocated directly to the DMI hardware [allo-
cate]

Data
• Requirement:
– tsc-req-era-ertms-015560-6-3-1-8[req]
– tsc-req-era-ertms-015560-6-3-1-9[req]
• Ci:
– DMI hardware[ci]
• Justification: these requirements concern the hardware keys when using soft key technology

Requirement

The DMI computer shall contain the necessary galvanically isolated power adapter. The adapter
output shall not float and shall be referenced to an earth point. [id:tsc-req-ievc-ob-dmi-hw-galvanically-
isolated][p2][s]

12.7.7 Failure modes

There are two levels of failure:

• software failure: a running application failed. It triggers the watchdog which perform a reboot of the DMI
computer.
• critical system failure: after several reboot due to the watchdog (configurable limit), the DMI doesn’t
manage to recover a working state, it stays in the failure mode.

Note: when possible the DMI hardware failures will be reported by the DMI checker.

12.7. DMI hardware 675 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.8 DMI checker

Important: This component is included in the iEVC Basic kit[ci]

12.8.1 Description

The DMI checker is an additional software running on the DMI computer[ci] which checks the consistency of
the displayed information from the DMI software[ci] according to the data received from the Virtual machine[ci]
before any screen update.
It also identifies the driver input to be considered as safe input and checks that the reported driver action to the
Virtual Machine corresponds to its intention according to display on screen.

12.8.1.1 Management of DMI display

Each DMI window is described by a layout composed of separate areas in which a graphical information is
displayed.

Figure 12.13: Sample of DMI layout

Then, the DMI display is specified by the applicable window (layout) and a list of graphical elements defined by a
key (area identifier) with its value (symbol identifier). These data will be sent by the Virtual Machine to the DMI
checker and the DMI software.

676 of 750 12.8. DMI checker

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 12.14: Sample of DMI graphical elements

There are two kinds of graphical elements:

• safe information: a wrong information has an impact on the safety. Its display shall be controlled by
the DMI checker which send the information to the screen. These safe information are described in the
configuration of the DMI checker. For the concerned areas, it verifies that the display output from the DMI
software corresponds to the expectation according to the configuration and the data received from the Virtual
Machine. In case of inconsistent display, a specific mask is displayed on the screen in order to inform the
driver of the mistake and a feedback is sent to the Virtual Machine.
• non safe information: there is no need to check that the information is correctly displayed. The DMI
checker gets the information from the DMI software and displays it on the screen without verification.

Note: Due to this principle, the changes of the display of the safe information shall always be linked to the
reception of new data from the Virtual Machine.

12.8. DMI checker 677 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.8.1.2 Management of driver action

As for the display, there are two kinds of driver action:

• safe driver input: this action has an impact on the safety and it has to be checked that the driver action
matches its intention. For example the acknowledgment of a mode transition to On-sight is a safe input. The
DMI checker needs to make sure that the mode transition acknowledgment message or icon was actually
being displayed (and not some other information) when the driver pushed on the acknowledgment button.
The safe driver inputs are described in the configuration of the DMI checker. For any driver input (touch
event for touch screen technology or key event for soft-key technology) and according to the current dis-
played information, the DMI checker looks for a corresponding safe driver input in its configuration data. If
the driver action is identified as safe input, the related pre-configured message is transmitted to the Virtual
Machine. This ensures that the sending of the message is inline with the displayed information.
• non safe driver input: this action has not a direct impact on the safety. The DMI checker doesn’t find them
in its configuration and ignore them.
All driver inputs will be reported by the DMI software as non-safe input even if they are also taken into account
by the DMI checker and reported to the Virtual Machine as safe input.
In the following figure, there are several samples of driver input (the areas and symbol identifiers are defined in
ERA_ERTMS_015560):
1) The driver touch area C1 containing the symbol LE07 : the DMI checker identifies it as a safe input and
sends the predefined message “ACK LEVEL 0” to the Virtual Machine. The DMI software also reports this
action to Virtual Machine as a non-safe input with an equivalent message “ACK LEVEL 0”.
2) The driver touch area G12 containing symbol DR03: the DMI checker doesn’t identify it as a safe input and
ignores it. The DMI software report this non-safe input as a request to display the geographical position.
3) The driver touch area C8 containing symbol LE03: the DMI checker doesn’t identify it as a safe input and
ignores it. The DMI software also ignores this input as it is not linked to known driver action.

Figure 12.15: Samples of driver input

678 of 750 12.8. DMI checker

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The list of displayed information and driver inputs to be considered as safe data will be provided by a RAMS
analysis. The other data (non-safe) could be managed also as safe data. For the safe data, a validation report have
to be created and verified in order to certified the SIL2 functions of the DMI. It can be a substantial work (i.e. for
a safe display of the train speed, the pictures of the speed needles have to be generated for all combination of all
speed values and colors). Then, the classification between safe and no-safe data has to be performed taken into
account all of these criteria.

12.8.2 Modes

This DMI checker has no specific mode.

12.8.3 Functions

Figure 12.16: DMI checker logical architecture

12.8.3.1 [IEVC.F3.02.09.02] Verify safety-related display and driver input [function]

Data
• Definition: This function checks the graphical display from the DMI software and controls the safe
user inputs. It manages the DMI screen activation. It also provides maintenance and fault data
concerning the DMI hardware and DMI checker components to the DMI software.
• Allocated to:
– DMI checker[ci]
• Input:
– DMI user input[functional variable][DMI ETCS User Interface][DMI Fault User Inter-

12.8. DMI checker 679 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

face][DMI Maintenance User Interface]

– SIL2 Screen activation request[functional variable][VM - DMI interface]
– ETCS message for safe display[functional variable][VM - DMI interface]
– DMI software graphical output[functional variable]
• Output:
– DMI screen[functional variable][DMI ETCS User Interface][DMI Fault User Interface][DMI
Maintenance User Interface]
– DMI computer maintenance data[functional variable]
– SIL2 error message[functional variable][VM - DMI interface]
– SIL2 Screen activation status[functional variable][VM - DMI interface]
– Safe user inputs[functional variable][VM - DMI interface]
• Sil: 2
• Associated interface:
– DMI ETCS User Interface[ci]
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]
– VM - DMI interface[ci]
• Sub functions:
– [IEVC.F3.02.09.02.01] Check consistency of display output from the DMI software[function]
– [IEVC.F3.02.09.02.02] Manage safe driver input[function]
– [IEVC.F3.02.09.02.03] Provide maintenance and fault information[function]
– [IEVC.F3.02.09.02.04] Manage DMI screen activation[function]

12.8.3.1.1 [IEVC.F3.02.09.02.01] Check consistency of display output from the DMI software
[function]

Data
• Definition: For each graphical element identified as a safe data, the DMI checker shall check that the
corresponding output from the DMI software matches the expectation according to the configuration
and the data received from the Virtual Machine. If it is consistent, the information is updated on the
screen displayed to the driver. If it is inconsistent, the concerned area on the screen shall indicated to
the driver that the information is not valid (by the use of a special mask or equivalent) and the error
is reported to the Virtual Machine. The DMI checker shall not verify all graphical element/area not
identified as a safe information.
• Allocated to:
– DMI checker[ci]
• Input:
– DMI software graphical output[functional variable]
– ETCS message for safe display[functional variable][VM - DMI interface]
• Output:

680 of 750 12.8. DMI checker

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– DMI screen[functional variable][DMI ETCS User Interface][DMI Fault User Interface][DMI

Maintenance User Interface]
– SIL2 error message[functional variable][VM - DMI interface]
• Sil: 2
• Associated interface:
– DMI ETCS User Interface[ci]
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]
– VM - DMI interface[ci]

12.8.3.1.2 [IEVC.F3.02.09.02.02] Manage safe driver input [function]

Data
• Definition: All inputs from the driver are received by the DMI checker. According to the DMI
technology, it can be touch event (touchscreen technology) or key event (soft-key technology or
acknowledgment performed with an external pushbutton). Taking into account the current DMI
status, the configuration and the event, the DMI checker determines if it has to be managed as a safe
driver input. If it corresponds to a safe input, it gets the corresponding predefined message in its
configuration and sends it directly to the Virtual Machine via the SIL2 communication. Otherwise,
it ignores this driver input.
• Allocated to:
– DMI checker[ci]
• Input:
– DMI screen[functional variable][DMI ETCS User Interface][DMI Fault User Interface][DMI
Maintenance User Interface]
– DMI user input[functional variable][DMI ETCS User Interface][DMI Fault User Inter-
face][DMI Maintenance User Interface]
• Output:
– Safe user inputs[functional variable][VM - DMI interface]
• Sil: 2
• Associated interface:
– DMI ETCS User Interface[ci]
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]
– VM - DMI interface[ci]

12.8. DMI checker 681 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.8.3.1.3 [IEVC.F3.02.09.02.03] Provide maintenance and fault information [function]

Data
• Definition: Provide maintenance and fault information about the DMI computer (DMI hardware,
DMI checker) to the DMI software.
• Allocated to:
– DMI checker[ci]
• Output:
– DMI computer maintenance data[functional variable]
• Sil: 2

12.8.3.1.4 [IEVC.F3.02.09.02.04] Manage DMI screen activation [function]

Data
• Definition: This function switches on/off the screen according to the received activation request and
reports the screen activation status.
• Allocated to:
– DMI checker[ci]
• Input:
– SIL2 Screen activation request[functional variable][VM - DMI interface]
– DMI hardware screen activation status[functional variable][DMI ETCS User Interface][DMI
Fault User Interface][DMI Maintenance User Interface]
• Output:
– SIL2 Screen activation status[functional variable][VM - DMI interface]
– DMI hardware screen activation request[functional variable][DMI ETCS User Interface][DMI
Fault User Interface][DMI Maintenance User Interface]
• Sil: 2
• Associated interface:
– VM - DMI interface[ci]
– DMI ETCS User Interface[ci]
– DMI Fault User Interface[ci]
– DMI Maintenance User Interface[ci]

682 of 750 12.8. DMI checker

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.8.4 Interface

The following external interfaces are applicable to the DMI checker:

• VM - DMI interface[ci]
• DMI ETCS User Interface[ci]
• DMI Fault User Interface[ci]
• DMI Maintenance User Interface[ci]
The following variables are exchanged between the DMI software and the DMI checker:

Functional Variable
DMI software graphical output [functional variable]
Data
• Objective: To provide the DMI display built by the DMI software.
• Description: picture defined by the screen resolution and color range.
• Family: Software
• Type: vendor dependent
• Format: vendor dependent
• Protocol: vendor dependent
• Timing constraints: Event
• Produced by:
– [IEVC.F3.02.09.03] Manage ETCS display information[function]
• Consumed by:
– [IEVC.F3.02.09.02.01] Check consistency of display output from the
DMI software[function]
– [IEVC.F3.02.09.02] Verify safety-related display and driver in-
put[function]

Note: The format of this message depends on the DMI computer vendor. It is not specified
in this version of the specification.

Functional Variable
DMI computer maintenance data [functional variable]

12.8. DMI checker 683 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide the DMI computer maintenance data.
• Description: it contains the identification/version of the DMI hardware and
DMI checker software, failure and status.
• Family: Software
• Type: vendor dependent
• Format: vendor dependent
• Protocol: vendor dependent
• Timing constraints: Event
• Produced by:
– [IEVC.SW.DMI.CHECKER_DRV.GET_DATA] Receive maintenance
data from the DMI Checker[function]
– [IEVC.F3.02.09.02.03] Provide maintenance and fault informa-
tion[function]
– [IEVC.F3.02.09.02] Verify safety-related display and driver in-
put[function]
• Consumed by:
– [IEVC.SW.DMI.CHECKER_DRV.GET_DATA] Receive maintenance
data from the DMI Checker[function]
– [IEVC.SW.DMI.COMP_STATE] Compute DMI states[function]
– [IEVC.F4.28.10] Collect DMI maintenance and fault informa-
tion[function]

Note: The format of this message depends on the DMI computer vendor. It is not specified
in this version of the specification.

12.8.5 Configuration

Configuration Item

DMI Checker Configuration Data Files [ci]

Data
• Sil: Undefined

It is the set of files to configure the DMI Checker functionalities and communications. The format of the
files will be defined in the software design.
• DMI device parameters[functional variable]
• Safe display control configuration[functional variable]
• Safe driver inputs configuration[functional variable]

684 of 750 12.8. DMI checker

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Functional Variable
DMI device parameters [functional variable]
Data
• Objective: To provide the parameters for the communication of the DMI checker with others
software
• Description: This variable contains parameters for the network communication (local port
number, remote IP address and port number for the SIL2 communication), identification of
the device.
• Family: Software
• Type: vendor dependent
• Format: vendor dependent
• Protocol: vendor dependent
• Timing constraints: Event

Note: The format of this message depends on the DMI computer vendor. It is not specified in this version
of the specification.

Functional Variable
Safe display control configuration [functional variable]
Data
• Objective: To provide the parameters for the check of the safe information display.
• Description: This variable contains the description of all graphical elements to be consid-
ered as a safe displayed information. It is like a list of data: Windows identifier / area
identifier (key) / symbol identifier (value) / expected picture
• Family: Software
• Type: vendor dependent
• Format: vendor dependent
• Protocol: vendor dependent
• Timing constraints: Event

Note: The format of this message depends on the DMI computer vendor. It is not specified in this version
of the specification.

Functional Variable
Safe driver inputs configuration [functional variable]

12.8. DMI checker 685 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide the parameters for the management of the safe driver inputs.
• Description: This variable contains the rules for the identification and management of the
safe driver input. It is like a list of data: Windows identifier / area identifier (key) / displayed
picture / predefined message to transmit to the VM.
• Family: Software
• Type: vendor dependent
• Format: vendor dependent
• Protocol: vendor dependent
• Timing constraints: Event

Note: The format of this message depends on the DMI computer vendor. It is not specified in this version
of the specification.

12.8.6 Requirements

Requirement

The DMI checker shall check the consistency of the displayed safe information with the received
data from Virtual Machine and report any inconsistency to the DMI driver. [id:tsc-req-ievc-ob-dmi-
check-req2][p2][s]

For each graphical element identified as a safe data, the DMI checker shall check that the corresponding
output from the DMI software matches the expectation according the configuration. If it is consistent,
the information is updated on the screen displayed to the driver. If it is inconsistent, the concerned area
on the screen shall indicated to the driver that the information is not valid (by the use of a special mask
or equivalent). The DMI checker shall not control the graphical element/area not identified as a safe
information and update them on the screen as received from the DMI software.

Requirement

The DMI checker shall process the driver input to identify the safe input and shall report safe driver
inputs to the DMI driver. [id:tsc-req-ievc-ob-dmi-check-req3][p2][s]

Requirement

The configuration of the DMI checker shall be protected by a checksum. [id:tsc-req-ievc-ob-dmi-check-

req8][p2][s]

The DMI checker shall detect if its configuration is corrupted and shall report the error to the Virtual
Machine.

12.8. DMI checker 687 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

The DMI checker shall transmit its maintenance and fault data to the DMI software. [id:tsc-req-ievc-
ob-dmi-check-req9][p2][ns]

The maintenance data contains identification, version information, failure and status.

Requirement

The DMI checker shall manage the activation of the DMI screen. [id:tsc-req-ievc-ob-dmi-check-
activation][p2][s]

It shall switch on/off the screen according to the activation requests received from the DMI driver and it
shall report the screen activation status.

Allocate
The development of the DMI checker shall comply with the requirements of EN 50128:2011. [allo-
cate]

Data
• Requirement:
– tsc-req-ievc-component-sw-en50155-7-3-sig-en50128-2011[req]
• Ci:
– DMI checker[ci]
• Justification: Safety analysis of DMI requires SIL2 for some DMI functions. See informa-
tive SUBSET-118 (Study to be performed by RAMS)

Requirement

A SIL2 communication protocol shall be used to exchange data with the Virtual Machine. [id:tsc-
req-ievc-ob-dmi-check-req11][p1][s]

Any lost of message or message corruption or a too old message has to be detected in order to manage
message recovery. Furthermore, the version of the used protocol has to be included in the exchanged data.

Requirement

In the communication with external components, an unique identifier shall be included in the ex-
changed data. [id:tsc-req-ievc-ob-dmi-check-req12][p1][ns]

The iEVC contains several DMI and an unambiguous identification of each DMI device is required.

688 of 750 12.8. DMI checker

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.8.7 Failure modes

The following failures of the DMI checker are identified:

• invalid or corrupted configuration: a configuration is requested by the DMI checker. It has to be protected
by a checksum. This configuration can be missing, unreadable or corrupted. Depending on the vendor the
DMI checker may not start and/or not communicate with the DMI driver or it may report an error through
SIL2 error message[functional variable][VM - DMI interface].
• inconsistency detected in the display of a safe information: the graphical output of the DMI software
has to be compliant with the expectation recorded in the configuration. In case of inconsistency, the DMI
checker reports it to the DMI driver through the SIL2 error message[functional variable][VM - DMI inter-
face].
• hardware failure: all problem related to the hardware which prevent the DMI to work correctly. In case
of hardware failure, the DMI checker will attempt to report it through the DMI computer maintenance
data[functional variable].

12.9 Ethernet Switch

Important: The Ethernet switch is included in the iEVC Basic kit[ci]. The Sensor box ethernet switch is included
in the iEVC Sensor kit[ci]

12.9.1 Description

The Ethernet switch is the networking hardware that connects devices on the iEVC network by using packet
switching to receive and forward data to the destination device.
In the iEVC system, there are two components:
• the ‘main’ Ethernet switch[ci],
• the Sensor box ethernet switch[ci].
The Sensor box ethernet switch[ci] connects all the components inside the sensor box to the ‘main’ Ethernet
switch[ci]. The ‘main’ Ethernet switch[ci] connects the Computer box to the DMI computers, the CPM, the
Telecom box components and the Sensor box ethernet switch. The following sections are applicable to the Ethernet
switch[ci] and to the Sensor box ethernet switch[ci].

12.9. Ethernet Switch 689 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.9.1.1 Network allocation

Figure 12.17: iEVC network allocation

The table Ethernet network allocation describes the allocation of the Ethernet ports between the network switches
connected as presented by iEVC network allocation. Within this table :
• Component is the component connected to the network;
• Allocated Switch device is the physical connection of the component to the network;
• Nb unit is the number of component connected;
• External port Sensor box is the number of the external port of the sensor box used to perform this link;
• Ethernet switch port is the number of the ethernet switch port used to perform this link;
• Interfaces is the list of interface that use this physical link.

690 of 750 12.9. Ethernet Switch

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Sensor box ethernet Sensor box - Network switch

spare 1 2
switch[ci] internal interface[ci]
NMEA 0183 GPS inter-
4G modem[ci] Ethernet switch[ci] 1 2
face[ci]
Modem Controller - GSM-R
GSM-R modem[ci] Ethernet switch[ci] 2 3-4
Modem Interface[ci]
Telecom box power sup- Power supply - OBOM inter-
Ethernet switch[ci] 2 5-6
ply[ci] face[ci]
VM - iBTM-TX inter-
face[ci], VM - iBTM-RX
interface[ci], VM - iODO
interface[ci], VM - iODO
Safe computer[ci] Ethernet switch[ci] 1 7
BITE interface[ci], CPM -
OBOM interface[ci], DMI -
OBOM interface[ci], VM -
DMI interface[ci]
Crash protected mem-
Ethernet switch[ci] 1 8 CPM - OBOM interface[ci]
ory[ci]
DMI - OBOM interface[ci],
DMI computer[ci] Ethernet switch[ci] 4 9-12
VM - DMI interface[ci]
Second Sensor box Ethernet switch[ci] 1 13
reserved for telemetry Ethernet switch[ci] 1 14
spare 1 (for Train inter-
Ethernet switch[ci] 1 15
face)
spare 2 (provision for TSI-
Ethernet switch[ci] 1 16
CCS 2022)

12.9. Ethernet Switch 691 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.9.2 Modes

This component has the following modes:

Table 12.5: Modes the Ethernet switch

Mode Active functions
Off
Starting
• [IEVC.F5.08.01] Perform Ethernet network startup[function]

Ready
• [IEVC.F5.08.02] Perform Ethernet packet switching[function],
• [IEVC.F5.08.03] Mirror Ethernet network traffic[function],
• [IEVC.F4.28.02] Ethernet switch - Provide maintenance and fault infor-
mation[function] or [IEVC.F4.28.15] Sensor box ethernet switch - Provide
maintenance and fault information[function],
• [IEVC.F4.32.07] Reset Ethernet switch[function] or [IEVC.F4.32.12] Reset
Sensor box ethernet switch[function],
• [IEVC.F4.32.18] Command digital outputs[function]

The transitions are as follows:

Figure 12.18: Mode transition diagram of the Ethernet switch

Note: In Fig. 12.18, the functions [IEVC.F4.28.02] Ethernet switch - Provide maintenance and fault informa-
tion[function] and [IEVC.F4.32.07] Reset Ethernet switch[function] in Fig. 12.18 need to be replaced respec-
tively by [IEVC.F4.28.15] Sensor box ethernet switch - Provide maintenance and fault information[function] and
[IEVC.F4.32.12] Reset Sensor box ethernet switch[function] for the Sensor box ethernet switch[ci]. In addition,
[IEVC.F4.32.18] Command digital outputs[function] is not applicable for the Sensor box ethernet switch[ci].

692 of 750 12.9. Ethernet Switch

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.9.3 Functions

12.9.3.1 [IEVC.F5.08.01] Perform Ethernet network startup [function]

Data
• Definition: Load the switch configuration and startup network services, the configuration includes:
Static IP address (for the OBOM interface and the switch management), sub network configuration
if needed, maintenance report configuration.
• Allocated to:
– Ethernet switch[ci]
– Sensor box ethernet switch[ci]
• Sil: basic

12.9.3.2 [IEVC.F5.08.02] Perform Ethernet packet switching [function]

Data
• Definition: Forward received packets to the destination device. Packets are routed with destination
MAC address of the ethernet header (OSI level 2 packets switching).
• Allocated to:
– Ethernet switch[ci]
– Sensor box ethernet switch[ci]
• Sil: basic

12.9.3.3 [IEVC.F5.08.03] Mirror Ethernet network traffic [function]

Data
• Definition: Copy any packets sent or received on port to a destination port
• Allocated to:
– Ethernet switch[ci]
– Sensor box ethernet switch[ci]
• Sil: basic

This function is available for debug purpose. It is usually disabled in operation. It is enabled through the switch
configuration.

12.9. Ethernet Switch 693 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.9.3.4 [IEVC.F4.28.02] Ethernet switch - Provide maintenance and fault information [function]

Data
• Definition: Provide maintenance and fault information about the Ethernet switch.
• Allocated to:
– Ethernet switch[ci]
• Input:
– Ethernet Switch Maintenance Data request[functional variable][Ethernet Switch - OBOM in-
terface]
• Output:
– Ethernet Switch Maintenance Data[functional variable][Ethernet Switch - OBOM interface]
• Sil: basic
• Associated interface:
– Ethernet Switch - OBOM interface[ci]

The switch provides maintenance data with SNMP protocol.

12.9.3.5 [IEVC.F4.28.15] Sensor box ethernet switch - Provide maintenance and fault information
[function]

Data
• Definition: Provide maintenance and fault information about the Sensor Box Ethernet switch.
• Allocated to:
– Sensor box ethernet switch[ci]
• Output:
– Sensor Box Ethernet Switch Maintenance Data[functional variable][Sensor Box Ethernet
Switch - OBOM interface]
• Sil: basic
• Associated interface:
– Sensor Box Ethernet Switch - OBOM interface[ci]

The Sensor box ethernet switch provides maintenance data using TSC Net protocol.

12.9.3.6 [IEVC.F4.32.07] Reset Ethernet switch [function]

Data
• Definition: Reset the Ethernet switch upon reception of a reset order through Ethernet.
• Allocated to:
– Ethernet switch[ci]
• Input:
– Ethernet switch reset order[functional variable][Ethernet Switch - OBOM interface]
• Sil: basic

694 of 750 12.9. Ethernet Switch

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Associated interface:
– Ethernet Switch - OBOM interface[ci]

Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional architecture.

12.9.3.7 [IEVC.F4.32.12] Reset Sensor box ethernet switch [function]

Data
• Definition: Reset the Sensor box ethernet switch upon reception of a reset order through Ethernet.
• Allocated to:
– Sensor box ethernet switch[ci]
• Input:
– Sensor box ethernet switch reset order[functional variable][Sensor Box Ethernet Switch -
OBOM interface]
• Sil: basic
• Associated interface:
– Sensor Box Ethernet Switch - OBOM interface[ci]

Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional architecture.

12.9.3.8 [IEVC.F4.32.18] Command digital outputs [function]

Data
• Definition: This function allows commanding digital outputs of the switch in order to trigger a 'hard'
reset of the Safe computer and DMI through dedicated relays.
• Allocated to:
– Ethernet switch[ci]
• Input:
– DMI reset order[functional variable][Ethernet Switch - OBOM interface]
– Safe Computer reset order[functional variable][Ethernet Switch - OBOM interface]
• Output:
– DMI reset digital output[functional variable][Ethernet switch - Reset relay interface]
– Safe computer reset digital output[functional variable][Ethernet switch - Reset relay interface]
• Sil: basic
• Associated interface:
– Ethernet Switch - OBOM interface[ci]
– Ethernet switch - Reset relay interface[ci]

Refer to [IEVC.F4.32] Reset iEVC components[function] for a description of the related functional architecture.
This function is specific to the ‘main’ Ethernet switch (not applicable to the Sensor box ethernet switch).

12.9. Ethernet Switch 695 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.9.4 Interface

12.9.4.1 Physical interface

The following interfaces are applicable to Ethernet switch[ci]:

• Telecom box - Ethernet interface[ci]
• Computer box - Ethernet interface[ci]
• Sensor box - Ethernet interface[ci]
• DMI - Ethernet interface[ci]
• CPM - Ethernet interface[ci]
• Ethernet switch - Reset relay interface[ci]

Functional Variable
DMI reset digital output [functional variable]
Data
• Objective: To provide electrical power to command relays that are used for a 'hard' reset of
the DMI devices.
• Description: wired digital output.
• Family: Software
• Type: Wired
• Format: schematics
• Associated interface:
– Ethernet switch - Reset relay interface[ci]
• Produced by:
– [IEVC.F4.32.18] Command digital outputs[function]

The detail of the wiring is train -specific and has to be defined during the installation design activities.

Functional Variable
Safe computer reset digital output [functional variable]

696 of 750 12.9. Ethernet Switch

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Objective: To provide electrical power to command a relay that is used for a 'hard' reset of
the computer box.
• Description: wired digital output.
• Family: Software
• Type: Wired
• Format: schematics
• Associated interface:
– Ethernet switch - Reset relay interface[ci]
• Produced by:
– [IEVC.F4.32.18] Command digital outputs[function]

The detail of the wiring is train -specific and has to be defined during the installation design activities.

The following interface is applicable to Sensor box ethernet switch[ci]:

• Sensor box - Network switch internal interface[ci]

12.9.4.2 Functional interface

There are 2 external interfaces:

• Sensor Box Ethernet Switch - OBOM interface[ci]
This interface has the following variables:

Functional Variable
Sensor Box Ethernet Switch Maintenance Data [functional variable]
Data
– Objective: To provide the maintenance information on the network device
– Description: TSC Net message that contains maintenance data. The data includes
identification, version information, failure and status of each port.
– Family: Software
– Protocol: TSC Net
– Timing constraints: Cyclic (5s)
– Associated interface:

* Sensor Box Ethernet Switch - OBOM interface[ci]

– Produced by:

* [IEVC.F4.28.15] Sensor box ethernet switch - Provide maintenance and fault

information[function]
– Consumed by:

* [IEVC.F4.28.06] Collect maintenance and faults information[function]

12.9. Ethernet Switch 697 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

<sw_version> ::= e_string

<hw_version> ::= e_string
<status> := “\x01” ; active
| “\x00” ; not active
<temperature> := int32_t ; current temperature ( °C * 100)
<port_status> := [<status>]* 10 ; array of the status of the ethernet
˓→port

<sw_version> <hw_version> <temperature> <port_status>

Functional Variable
Sensor box ethernet switch reset order [functional variable]
Data
– Objective: To trigger the reset of the Sensor box ethernet switch
– Description: TSC Net message with the reboot request. the message contains a
boolean that indicates if the board has to reboot in a mode that allows software update.
– Family: Software
– Protocol: TSC Net
– Timing constraints: event
– Associated interface:

* Sensor Box Ethernet Switch - OBOM interface[ci]

– Produced by:

* [IEVC.F4.32.01] Command iEVC component reset[function]

– Consumed by:

* [IEVC.F4.32.12] Reset Sensor box ethernet switch[function]

<software_update_mode> ::= "\x00" ; False

| "\x01" ; True

• Ethernet Switch - OBOM interface[ci]

This interface has the following variables:

Functional Variable
Ethernet Switch Maintenance Data [functional variable]

698 of 750 12.9. Ethernet Switch

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To provide the maintenance information on the network device
– Description: SNMP message that contains maintenance data. The data includes iden-
tification, version information, failure and status of each port.
– Family: Software
– Protocol: SNMP
– Timing constraints: event (response to the request)
– Associated interface:

* Ethernet Switch - OBOM interface[ci]

– Produced by:

* [IEVC.F4.28.02] Ethernet switch - Provide maintenance and fault informa-

tion[function]
– Consumed by:

* [IEVC.F4.28.06] Collect maintenance and faults information[function]

A SNMP message equivalent to TSC Net message of Sensor Box Ethernet Switch Maintenance
Data[functional variable][Sensor Box Ethernet Switch - OBOM interface] is used

Functional Variable
Ethernet Switch Maintenance Data request [functional variable]
Data
– Objective: To request the production of the maintenance information on the network
– Description: SNMP message that requests maintenance data of the Ethernet switch
– Family: Software
– Type: SNMP request
– Protocol: SNMP
– Timing constraints: Cyclic (5s)
– Associated interface:

* Ethernet Switch - OBOM interface[ci]

– Produced by:

* [IEVC.F4.28.06] Collect maintenance and faults information[function]

– Consumed by:

* [IEVC.F4.28.02] Ethernet switch - Provide maintenance and fault informa-

tion[function]

Functional Variable
Ethernet switch reset order [functional variable]

12.9. Ethernet Switch 699 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To trigger the reset of the Ethernet switch
– Description: SNMP reset/reboot request
– Family: Software
– Type: SNMP message (SNMP request)
– Protocol: SNMP
– Timing constraints: event
– Associated interface:

* Ethernet Switch - OBOM interface[ci]

– Produced by:

* [IEVC.F4.32.01] Command iEVC component reset[function]

– Consumed by:

* [IEVC.F4.32.07] Reset Ethernet switch[function]

Functional Variable
Safe Computer reset order [functional variable]
Data
– Objective: To trigger the 'hard' reset of the Safe computer through the activation of a
digital output of the ethernet switch
– Description: Specific SNMP request
– Family: Software
– Type: SNMP message (SNMP request)
– Protocol: SNMP
– Timing constraints: event
– Associated interface:

* Ethernet Switch - OBOM interface[ci]

– Produced by:

* [IEVC.F4.32.01] Command iEVC component reset[function]

– Consumed by:

* [IEVC.F4.32.18] Command digital outputs[function]

Functional Variable
DMI reset order [functional variable]

700 of 750 12.9. Ethernet Switch

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
– Objective: To trigger the 'hard' reset of the DMI computers through the activation of
a digital output of the ethernet switch
– Description: Specific SNMP request
– Family: Software
– Type: SNMP message (SNMP request)
– Protocol: SNMP
– Timing constraints: event
– Associated interface:

* Ethernet Switch - OBOM interface[ci]

– Produced by:

* [IEVC.SW.OBOM_MAINTENANCE.MANAGE_RESET] Manage Compo-

Requirement

The Ethernet switch shall contain the necessary galvanically isolated power adapter. The adapter
output shall not float and shall be referenced to an earth point. [id:tsc-req-ievc-switch-galvanically-
isolated][p2][s]

Requirement

The Ethernet switch shall packet route at the layer 2 in OSI model according to IEC-7498. [id:tsc-
req-ievc-switch-level2][p1][ns]

Refer to [SyAD-R49-IEC-7498] for a description of the OSI model.

Requirement

The Ethernet switch shall allow to mirror packets in read-only. [id:tsc-req-ievc-switch-mirror][p1][ns]

Requirement

The Ethernet switch shall provide a maintenance and fault interface as SNMP message [id:tsc-req-
ievc-switch-maintenance][p2][ns]

Requirement

The Sensor box ethernet switch shall provide a maintenance and fault information in a TSC Net
message [id:tsc-req-ievc-switch-sb-maintenance][p2][ns]

Requirement

The Ethernet switch shall reset itself upon reception of a reset order through Ethernet [id:tsc-req-
ievc-switch-reset][p2][ns]

Requirement

The Sensor box ethernet switch shall reset itself upon reception of a reset order through Ethernet
[id:tsc-req-ievc-switch-sb-reset][p2][ns]

Requirement

All unused ports on the Ethernet switch shall be programmatically de-activated in factory [id:tsc-
req-ievc-switch-deactivate-unused-ports][p1][s]

702 of 750 12.9. Ethernet Switch

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

12.9.7 Failure modes

12.9.7.1 Complete failure of the Ethernet switch

A complete failure of the Ethernet switch[ci] result in an unavailability of the on-board iEVC system as a whole.
As there is no more communication, the only way to report this failure is through the DMI to the driver. When
this failure the train is stopped and the device shall be replaced.
Mitigations : The main cause of this failure is a default on the power supply. This is mitigated by using dual power
supply to increase the MTBF (see tsc-req-ievc-switch-dual-power[req])

12.9.7.2 Complete failure of the sensor Ethernet switch

A complete failure of the Sensor box ethernet switch[ci] will cause the lost of functions [IEVC.F3.02.03] Exe-
cute odometry functions[function] and [IEVC.F3.02.07] Read Eurobalise information[function]. This failure is
reported by OBOM[ci]
Mitigations : The main cause of this failure is a default on the power supply. This is mitigated by using dual power
supply to increase the MTBF (see tsc-req-ievc-switch-dual-power[req])

12.9. Ethernet Switch 703 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
CHAPTER

THIRTEEN

IEVC CONFIGURATION

13.1 iEVC Configuration data

The iEVC Configuration Data is the set of data that allows tuning the iEVC Generic Product and iEVC Generic
Application into a specific solution to comply with the specific requirements of an installation project.

Figure 13.1: Structure of the iEVC Configuration Data

The iEVC configuration Data is composed of:

• OBU Configuration Data: These data are specific to 1 On-board unit. One set of data is required for each
train in the installation project fleet. Examples of these data are:
– ETCS identity (ETCS_ID)

704 of 750 13. iEVC Configuration

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

– Level 2 authentication keys: for example the list of RBC with their authentication keys, validity dates,
etc.

Note: the verification that the ETCS_ID provided by the OBU Configuration Data is consistent
with the ETCS_ID of the VM (see VM configuration file) is the responsibility of the Subset 026
application)

• Train Type Configuration Data: These data are specific to one type of train. Within a type of train the iEVC
system has a unique functional scope, the On-board units have an identical interface with the train and an
identical installation design. These data are structured in different categories such as:
– Subset 026 Configuration Data: These data are used by the Subset 026 Application. Examples of these
data are:

* Train braking models parameters

* Train traction model parameters
* ETCS train data parameters
* ETCS levels used on-board
* STM configuration parameters
* ...
– Odometry Configuration Data: These data are those used by the Odometry Application. Examples of
these data are:

* Type of sensors used

* Sensor installation parameters
* Sensor calibration parameters
* ...
– Installation Configuration Data: These data are related to the hardware installed on-board. Examples
of these data are:

* Type of Safe computer platform

* Type of DMI
* Number of DMI screens
* ...
– Train Interface Configuration Data: These data are associated to the information exchanged between
the iEVC On-board subsystem and the train. See TIU application for a description of this interface.
– Euroradio Configuration Data: Network parameters, use of Circuit Switch and/or Packet Switch com-
munication, CS/PS parameters, . . .

Note: the detailed exhaustive list of parameters included in the configuration data is not in the scope of this doc-
ument. It is defined in [SyAD-R29-DPP]. Ultimately, each generic application defines its own list of parameters,
with the rules for filling them in.

13.1. iEVC Configuration data 705 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

13.2 iEVC Configuration Data files

The key point is that configuration files of the iEVC are regular application files, except that these configuration
applications are only executed once at startup.
The effect of these configuration applications is to over-write configuration variables in each regular applications,
each such variable corresponding to a parameter of the application. Once these variables are set, their modification
is no longer tolerated by the VM during its cyclic execution (when the VM is in VM_READY mode; see VM
Initialization States).

Figure 13.2: iEVC Configuration Files

Configuration Item

iEVC Configuration Data files [ci]

Data
• Sil: Undefined

The iEVC Configuration Data files are files containing iEVC Configuration data information. These files
are:
• The OBU Configuration Application files
• The Train Type Configuration Application file

Note: The TIU application contains also configuration data, but is a dedicated application that is executed
at each Safe Computer cycle. It has a specific preparation process different from the other configuration
data files.

The structure and format of the configuration data and their associated files are provided in Fig. 13.2.
The iEVC Configuration Data files are (EXS) files. The Train Type Configuration Application file contains
the train type data with exception of the information related to the train interface (which is contained in
the TIU application file). The OBU Configuration Data is included in the OBU Configuration Application
file. There is one OBU Configuration Application file for each On-Board Unit in the fleet.
The iEVC Configuration Data Files contain a SHA-256 checksum.

The Train Type Configuration Application file and TIU application file are defined once for a set of locomotives
having the same train type.

706 of 750 13.2. iEVC Configuration Data files

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Note: For example all the locomotives of type HLD 77 will use the same Train Type Configuration Application
file and TIU application file. But each of them will have a specific OBU Configuration Application file.

The SIDE Configurator is used to produce the iEVC configuration data files, namely:
• The OBU Configuration Application files
• The Train Type Configuration Application file
Apart from the iEVC configuration data, the files contain also:
• The identifier of the iEVC Modeler that prepared those files
• The identifier of the installation project
• The date and time of the file generation
• A SHA-256 checksum
The SIDE Configurator takes in input the Subset 026 and the other generic applications provided by the IEVC
designer[stakeholder]. The parameters are extracted from the application files to be presented in tabular format to
the IEVC modeler[stakeholder] of the installation project. She/he fills in the project specific values.

Note: Any modeled applications developed by the installation project (Installation project application[ci]) that
require configuration data may use the same process. This type of application will need to be included as well in
input of the SIDE Configurator. The need for configuration data may be evidenced during the installation project
design phase.

Figure 13.3: iEVC Configuration Files production

A specific TIU application is developed by each installation project. It must meet the specifications presented in
TIU application.
Once the files are prepared, the IEVC modeler[stakeholder] collects the configuration files and adds them to the
generic applications to produce a ‘project specific’ application package.
An application package is a set of applications including the iEVC system applications, the installation project
specific applications and the configuration applications.
The application package does not include any software component other than applications (e.g. no virtual machine
components like drivers, no OBOM, etc).
The application package includes the ETCS_ID of the iEVC system to program.
The SIDE Authorizer allows to produce cryptographic certificate that can then be uploaded to the iEVC on-board
to authorize the execution of an application package.

13.2. iEVC Configuration Data files 707 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

The application package and the certificate are programmed into each iEVC On-board subsystem of the fleet. The
programming operation is a ‘manual’ operation using a laptop and an ethernet connection.

Note: In a later version of the system, it is foreseen that application packages and certificates will be deployed
over the air.

The application package files are stored inside the Crash Protected Memory. They are transmitted to the Virtual
Machine by the On-Board Operation and Maintenance software at start-up.

Figure 13.4: iEVC Configuration Files Programming

13.3 iEVC Configuration Data Preparation Process

The iEVC Configuration Data Preparation Process is the process followed by the Installation project team to
produce the iEVC Configuration Data files. It is described in Fig. 13.5 in the form of a functional exchange
scenario. The corresponding architecture diagram is provided in Fig. 13.6.

708 of 750 13.3. iEVC Configuration Data Preparation Process

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 13.5: iEVC Configuration Data Preparation Process

13.3. iEVC Configuration Data Preparation Process 709 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Figure 13.6: iEVC Logical architecture - Configuration Data Preparation

The Installation designer[stakeholder] is in charge of the production of the installation project design documents.
These documents are specific to one type of train. They are used as input by the IEVC modeler[stakeholder] and
the IEVC model verifier[stakeholder] for their activities during the configuration data preparation process. It is
considered that these documents have complied with the installation designer quality process for verification and
validation before being used to produce the configuration data.

Artifact
Installation project design documents [artifact]

The Installation project design documents contains the installation design of the iEVC On-board sub-
system on a specific locomotive. This includes drawings, installation constraints, safety and contractual
requirements. They also specify as a minimum the project specific functional needs and the specificities
of the train interface. They provide guidance for the configuration of the iEVC Applications.

In the set of iEVC Configuration data, there is a subset of data that must be provided by the customer (Most
likely the Railway undertaking[stakeholder] but it may also be the Contract owner[stakeholder]). The RU data
collecting file is a document used to exchange these data. The data values must come from train specialists or
operation specialists but with TSC support as they are not always ERTMS experts.
The process must ENSURE that the values provided in the RU data collecting file will be correctly set in the iEVC
Configuration data. There can be no corruption of the exchanged file or error in the copy of values inside the
configuration tool. Two methods are provided as examples:
• Use 2 different format of the RU data collecting file when returning it to the installation design team: for
example an excel form to be used by the IEVC modeler[stakeholder] and a printed signed format to be used
by the IEVC model verifier[stakeholder].

710 of 750 13.3. iEVC Configuration Data Preparation Process

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

• Compute a checksum on the data provided together with the file and check the value during verification

Artifact
RU data collecting file [artifact]

The RU data collecting file is a template that is used to collect a specific subset of the iEVC configuration
data from the Railway undertaking[stakeholder] or the Contract owner[stakeholder]. It concerns the data
that is related to intrinsic train performance or operational choices and that don’t require any specific
additional installation engineering activity. Examples of these data are:
• Braking model parameters (deceleration models, brake build up times, ..)
• Traction model parameters (traction cut-off delay, ..)
• Train data parameters (data entry configuration, train data values and ranges, ..)
• GSM-R options (use of level 2, network parameters, ..)

The IEVC modeler[stakeholder] uses the SIDE Configurator to set the configuration data values and to produce
the iEVC Configuration Data files. The values are set according to the installation project design documents and
according to the RU data collecting file. Once all iEVC Configuration Data files are generated, they are provided
to the IEVC model verifier[stakeholder] to start the verification and test the data.
The IEVC model verifier[stakeholder] uses the SIDE Configurator to extract the data values from the iEVC Config-
uration Data files. She/he verifies the values against the prescription of the installation project design documents
and RU data collecting file. The result of the verification is documented in a iEVC configuration data verification
report. If no error is detected during the verification, IEVC model verifier[stakeholder] proceeds with the test of
the configuration data. If one or several errors are detected during the verification then the result of the verification
is discussed in a ‘Change Control Board’ meeting including as a minimum the IEVC modeler[stakeholder], the
IEVC model verifier[stakeholder], Installation designer[stakeholder], the Installation safety[stakeholder] and the
Installation project manager[stakeholder]. During this meeting it must be decided what activity/process must be
re-started to implement the appropriate correction.

Artifact
iEVC configuration data verification report [artifact]

The iEVC configuration data verification report is used to collect the result of the data verification ac-
tivity. It is produced by the IEVC model verifier[stakeholder]. It provides a comparison of the decoded
values with the expected results. The decoded values are the values extracted from the iEVC Configu-
ration Data files using the SIDE Configurator. The expected results are computed by the IEVC model
verifier[stakeholder] from the analysis of the installation project design documents and according to the
RU data collecting file.

The IEVC model verifier[stakeholder] tests the iEVC Configuration data using functional test scenarios that are
run on the iEVC On-board subsystem. She/he can also use formal proof as described in [SyAD-R14-SWVERP]
to test the EXS applications of the iEVC Configuration Data files. The result of the test is documented in a
iEVC configuration data test report. If no error is detected during the test, the iEVC Configuration Data files are
considered as valid for the installation project. Test errors are handled in the same way as verification errors (see
above).
Artifact
iEVC configuration data test report [artifact]

The iEVC configuration data test report is used to collect the result of the configuration data test activity. It
is produced by the IEVC model verifier[stakeholder]. The test specifications with scenarios and expected
results are computed by the IEVC model verifier[stakeholder] from the analysis of the installation project
design documents and according to the RU data collecting file.

13.3. iEVC Configuration Data Preparation Process 711 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
CHAPTER

FOURTEEN

SPECIFIC REQUIREMENT

14.1 EN50155 requirements

This section of the SyAD decomposes the EN50155 standard ([SyAD-R38-EN50155:2017]) in requirements that
are then allocated to the relevant components. The chapters are post-fixed with the corresponding section in the
standard, between parenthesis.

Allocate
Allocation of requirements for compliance to EN50155 [allocate]
Data
• Requirement:
– tsc-req-subset-036-4-6-1-2[req]
– tsc-req-subset-036-6-8-1[req]
– tsc-req-ievc-iha-mm-416[req]
– tsc-req-ievc-iha-mm-069[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: EN50155 requirements
• Justification: The allocation of all iEVC system components to EN50155 is performed at
once in a specific section of the System Architecture Description. iEVC-IHA-MM-069: this
covers the 'connector' part of the requirement.

14.1.1 Environmental service conditions (4.3)

14.1.1.1 Altitude (4.3.1)

Requirement

Component shall meet or exceed altitude class A1 in Table 1, EN 50125-1:2014. [id:tsc-req-ievc-hw-

en50155-4-3-1-a1][p1][s]

This requirement applies to all On-board IEVC components.

712 of 750 14. Specific requirement

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

14.1.1.2 Operating temperature (4.3.2)

Requirement

Component shall meet or exceed the operating temperature requirements of class OT3 or OT4 in
Table 1 of EN 50155:2017. [id:tsc-req-ievc-hw-en50155-4-3-2-ot3-ot4][p1][s]

OT4 is preferred, OT3 accepted. This requirement applies to On-board IEVC components that are not
externally mounted.

Requirement

Component shall operate in ambient temperature of class T3 or TX in Table 2 of EN 50125-1:2014.

[id:tsc-req-ievc-hw-en50125-4-3-tx][p1][s]

TX is preferred, T3 accepted. This requirement applies to externally mounted On-board IEVC compo-
nents.

14.1.1.3 Switch-on extended operating temperature (4.3.3)

Requirement

Component shall meet or exceed switch-on extended operating temperature requirements of class
ST1 and ST2 in Table 2 of EN 50155:2017 [id:tsc-req-ievc-hw-en50155-4-3-3-st1-st2][p1][s]

This requirement characterizes the ability of the components to work within an enclosure when external
temperature rises. Therefore, it is allocated to boxes and any device with built-in electronics.

14.1.1.4 Rapid temperature variations (4.3.4)

Requirement

Externally mounted component shall meet or exceed rapid temperature variations requirements of
class H2 in Table 3, EN 50155:2017 [id:tsc-req-ievc-hw-en50155-4-3-4-h2][p1][s]

This requirement applies to components that are located outside the vehicle body. In the case of the IEVC,
this applies mostly to speed sensors and antennas.

14.1.1.5 Shock and vibration (4.3.5)

Requirement

Component shall comply with the shock and vibration requirements of EN 61373 category 2 [id:tsc-
req-ievc-hw-en50155-4-3-5-en61373-category-2][p1][s]

This requirement applies to Cubicles, subassemblies, equipment and components mounted directly on or
under the car body. In the case of the IEVC, this applies mostly to the speed sensors and the antennas.

14.1. EN50155 requirements 713 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

Component shall comply with the shock and vibration requirements of EN 61373 category 1 class
B. [id:tsc-req-ievc-hw-en50155-4-3-5-en61373-category-1-class-b][p1][s]

This requirement applies to Anything mounted inside an equipment case which is in turn mounted directly
on or under the car body. In the case of the IEVC, this applies to the boxes and anything inside it.

14.1.1.6 Electromagnetic compatibility (4.3.6)

Requirement

Component shall comply with the EMC compatibility requirements of EN 50121-3-2. [id:tsc-req-ievc-
hw-en50155-4-3-6-en50121-3-2][p1][s]

This requirement applies to all components vulnerable to, or capable of generating EMC perturbations.

Requirement

Requirement

DC power supply range shall meet or exceed 0.7 Un to 1.25 Un per section 5.1.1.2 of EN50155:2017
[id:tsc-req-ievc-hw-en50155-5-1-1-2][p1][s]

This requirement applies to on-board IEVC power supply components

Requirement

Temporary DC power supply fluctuations shall meet or exceed 0.6 Un to 1.4 Un per section 5.1.1.3
of EN50155:2017 [id:tsc-req-ievc-hw-en50155-5-1-1-3][p1][s]

This requirement applies to on-board IEVC power supply components

Requirement

Power supply shall meet interruption of voltage supply requirements of class S3 per section 5.1.1.4
of EN50155:2017 [id:tsc-req-ievc-hw-en50155-5-1-1-4][p1][ns]

This requirement applies to on-board IEVC power supply components

Requirement

At start-up of combustion engines the voltage supply system shall be designed to guarantee the
supply to the iEVC on-board subsystem during the whole starting sequence. [id:tsc-req-ievc-hw-
en50155-5-1-1-5][p2][ns]

14.1. EN50155 requirements 715 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

Power supply shall meet ripple factor requirements of section 5.1.1.6 of EN50155:2017 [id:tsc-req-
ievc-hw-en50155-5-1-1-6][p1][ns]

14.1.2.2 Supply change-over (5.1.3)

Requirement

When the equipment supply is switched between different sources (e.g. redundancy switching), the
voltage supply system shall meet the requirements of section 5.1.3 of EN50155:2017 [id:tsc-req-ievc-
hw-en50155-5-1-3][p1][ns]

14.1.2.3 Supply with overhead line or third rail (5.1.4)

Not applicable to the iEVC system.

14.1.3 Power supply installation requirements (5.2)

Requirement

Power supply installation design shall meet the installation requirements of section 5.2 of
EN50155:2017 [id:tsc-req-ievc-hw-en50155-5-2][p1][ns]

14.1.4 Reliability, Maintainability and Expected useful life (6)

14.1.4.1 Equipment reliability (6.1)

Refer to RAM design targets.

14.1.4.2 Useful life (6.2)

Requirement

Useful life of the component shall reach or exceed class L4 according to EN 50155 section 6.2.
[id:tsc-req-ievc-hw-en50155-6-2][p1][ns]

This requirement applies to all hardware components, and corresponds to a useful life of 20 years.

Requirement

Component lifetime shall be documented. [id:tsc-req-ievc-hw-en50155-6-2-document-lifetime][p1][ns]

This requirement applies to all hardware components. TSC shall use this information to build its obsoles-
cence strategy.

716 of 750 14.1. EN50155 requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

14.1.4.3 Maintainability (6.3)

The topic of maintainability at iEVC level is covered by [IEVC.F4] Maintain IEVC in service[function]. This
function cascades maintainability requirements for each component, covering the topics of preventive maintenance
and corrective maintenance.
At the component level, it necessary however that the supplier performs a similar analysis and documents its
maintainability requirements.

Requirement

Component documentation shall meet the requirements for maintainability defined in

EN50155:2017 section 6.3 [id:tsc-req-ievc-hw-en50155-6-3-document-maintainability][p1][ns]

Applies to all iEVC hardware components

14.1.5 General design (7.1)

14.1.5.1 Equipment (7.1.1)

The following form-factor requirements are defined to simplify the installation of the iEVC on-board boxes inside
a freight locomotive. As required by EN50155, such requirements shall be verified during integration stages.

Requirement

A box dimensions shall be 4U (height), half 19 inches (width), 21cm (depth) [id:tsc-req-ievc-hw-box-
dimensions][p2][ns]

This requirement applies to the IEVC On-board boxes.

Requirement

A box maximum weight shall be 9kg with all its enclosed components mounted [id:tsc-req-ievc-hw-
box-weight][p3][ns]

This requirement applies to the IEVC On-board boxes.

Requirement

It shall be possible to mount a box on a standard DIN-rail [id:tsc-req-ievc-hw-box-din-mountable][p2][ns]

Requirement

It shall be possible to screw a box on a support on any of its face. [id:tsc-req-ievc-hw-box-screwable-on-

all-faces][p2][ns]

This requirement applies to the IEVC On-board boxes.

The following design requirement is added on top as a reserve.

Requirement

Inside a box, electronic components shall be racked in a 3U rack. [id:tsc-req-ievc-hw-box-internal-3u-

rack][p2][ns]

718 of 750 14.1. EN50155 requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

14.1.5.2 Quality (7.1.2)

Requirement

Component suppliers shall have an ISO 9001-compliant quality management system. [id:tsc-req-ievc-
component-design-iso-9001][p1][s]

This requirement applies to all IEVC components.

14.1.5.3 System life cycle (7.1.3)

The iEVC is developed according to a tailored EN 50126 life cycle as required. This is described fully in
[SyAD-R3-PQP].

Allocate
Allocation of Subset 036 safety requirements to the safety plan and associated analysis. [allocate]
Data
• Requirement:
– tsc-req-subset-036-4-4-1-1[req]
– tsc-req-subset-036-4-4-6-1-1[req]
– tsc-req-subset-036-6-10-1[req]
– tsc-req-subset-036-6-4-5-1-1[req]
– tsc-req-subset-036-6-4-5-2-2[req]
– tsc-req-subset-036-6-4-5-3-1[req]
– tsc-req-subset-036-6-4-5-4-1[req]
– tsc-req-subset-036-6-4-5-4-2[req]
• Artifact:
– IEVC ETCS Safety Plan[artifact]
• Justification: The safety activities are described in the Safety plan and are compliant
with EN 50126 and EN 50129. SUBSET_036_6.4.5.1_1, SUBSET_036_6.4.5.2_2, SUB-
SET_036_6.4.5.3_1, SUBSET_036_6.4.5.4_1, SUBSET_036_6.4.5.4_2: the hazards iden-
tified, their targets and the assumptions are included or referenced in the Subset-091 and the
Safety plan details how the inputs of the Subset 091 are managed. SUBSET_036_4.4.6.1_1
: requirements allocated to safety activities

Allocate
Allocation of Subset 036 RAM requirements to the RAM plan. [allocate]

14.1. EN50155 requirements 719 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-subset-036-4-4-1-1[req]
• Artifact:
– IEVC RAM Plan[artifact]
• Justification: The RAM activities are described in the RAM plan and are compliant with
EN 50126

Allocate
Allocation of Subset 036 safety requirements to the safety analysis performed in the scope of the
Sensor Kit analysis. [allocate]
Data
• Requirement:
– tsc-req-subset-036-4-4-6-1-1[req]
– tsc-req-subset-036-4-4-6-2-1-1[req]
– tsc-req-subset-036-4-4-6-2-2-1[req]
– tsc-req-subset-036-6-4-5-1-1[req]
– tsc-req-subset-036-6-4-5-2-2[req]
– tsc-req-subset-036-6-4-5-4-1[req]
– tsc-req-subset-036-6-4-5-3-1[req]
– tsc-req-subset-036-6-4-5-4-2[req]
• Artifact:
– iEVC Sensor Kit Generic Product Safety Plan[artifact]
• Artifact ref: iEVC Sensor Kit Generic Product Safety Activities
• Justification: The different analysis described in this requirement are specified in the Sensor
Kit Safety Plan.

Allocate
Allocation of Subset 036 requirement for compliance to EN 50128. [allocate]
Data
• Requirement:
– tsc-req-subset-036-6-10-1[req]
– tsc-req-subset-036-4-4-6-1-1[req]
• Artifact:
– iEVC Software Development Plan[artifact]
• Justification: the compliance to EN 50128 for the software development activities is ex-
plained in the iEVC Software Development Plan and in the iEVC Platform Safety Plan.

720 of 750 14.1. EN50155 requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

Component shall specify its protection requirements as per EN50155 clause 7.2.3 [id:tsc-req-ievc-hw-
en50155-7-2-3-component-specify-protections][p1][s]

This requirement applies to the boxes and their power supply, to the safe relays, and to any component
requiring to be powered from the train (e.g. the crash protected memory, the DMI, etc)

Requirement

Installation design shall comply with fault protection requirements of EN50155 section 7.2.3, and
implement the protections required by iEVC components. [id:tsc-req-ievc-hw-en50155-7-2-3-install-
design-compliance][p1][s]

Each iEVC component is required to provide its individual requirements.

14.1. EN50155 requirements 721 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

14.1.6.4 Referencing power supplies (7.2.4)

Requirement

Installation design shall comply with power supplies referencing requirements of EN50155 section
7.2.4. [id:tsc-req-ievc-hw-en50155-7-2-4][p1][ns]

14.1.6.5 Interchangeability (7.2.5)

The iEVC design is interchangeable at the exception of the safe Computer box. When the Computer box is
replaced, it needs to be programmed with its unique on-board ETCS identifier. This identifier allows the Safe
computer to then query its individual parameters.
The usage of a mechanically separate “dongle” to contain this information that is unique to the train was not
retained for the following reasons:
• It degrades MTBF of the system by adding another device
• The programming step does not complexify the procedure required anyway to upload configuration param-
eters to the on-board.

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

14.1.7 Detailed practices - Software (7.3)

Requirement

The development of the software component shall comply with the requirements of EN 50128:2011
[id:tsc-req-ievc-component-sw-en50155-7-3-sig-en50128-2011][p1][s]

Applies to hardware components that contains software.

14.1.8 Features of software controlled equipment (7.4)

14.1.8.1 Self-test (7.4.2)

In order to support function [IEVC.F4] Maintain IEVC in service[function], each component needs to provide a
fault detection function that can be exploited to calculate the fault status of LRUs. Therefore, a generic requirement
is created here for the iEVC that all components need to trace to.

Requirement

Component shall include a fault detection and reporting function, as suggested by EN 50155 section
7.4.2 and 7.4.4 [id:tsc-req-ievc-component-sw-en50155-7-4-2-7-4-4][p1][ns]

This requirement is allocated to the iEVC, and must be traced by each component by a suitable functional
requirement

Allocate
Allocation of fault detection and reporting requirements to power supplies [allocate]
Data
• Requirement:
– tsc-req-ievc-component-sw-en50155-7-4-2-7-4-4[req]
• Ci:
– Sensor Box Power Supply[ci]
– Telecom box power supply[ci]
– Computer box power supply[ci]
• Justification: Power supplies need to report their failures in order to anticipate maintenance.

Allocate
Allocation of fault detection and reporting requirements to safe relay [allocate]

724 of 750 14.1. EN50155 requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-ievc-component-sw-en50155-7-4-2-7-4-4[req]
• Ci:
– Safety relay[ci]
• Justification: Typically safety relays include a readback contact that can be used to meet this
requirement.

14.1.8.2 Watchdog (7.4.3)

Refer to VM cycle section.

14.1.8.3 Failure indication (7.4.4)

This is covered by tsc-req-ievc-component-sw-en50155-7-4-2-7-4-4[req], as introduced in the Self test section

above.

14.1.8.4 Recovery (7.4.5)

Refer to the Recovery strategy section.

14.1.8.5 Remote software update

Refer to the Platform software update section

14.1.9 Non-railway designed electronic equipment (8)

This section is not applicable to the iEVC program.

14.1.10 Components (9)

Requirement

Choice of electronics component shall be justified against recommendations of EN50155 section 9 in

a dedicated technical note. [id:tsc-req-ievc-component-hw-en50155-9][p1][ns]

This note should detail, in particular, the multiple sourcing strategy retained

Requirement

Component supplier shall have an obsolescence policy into place, and specify their commit-
ment in terms of availability to order. [id:tsc-req-ievc-component-hw-en50155-9-obsolescence-policy-and-
commitment][p1][ns]

This requirement applies to all hardware components, and shall be used by TSC to determine its obsoles-
cence strategy for the component.

14.1. EN50155 requirements 725 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

14.1.11 Equipment construction (10)

Requirement

Component construction shall meet the requirements of section 10 of EN 50155:2017 [id:tsc-req-ievc-

hw-en50155-10][p1][ns]

This requirement applies to all hardware components.

Furthermore, section 10 of the standard requires component size to be specified. This is done by tsc-req-ievc-hw-
box-dimensions[req] and tsc-req-ievc-hw-box-internal-3u-rack[req].

14.1.12 Safety (11)

14.1.12.1 Requirements (11.2)

Requirement

Component design shall meet the general safety requirements of section 11.2 of EN 50155:2017
[id:tsc-req-ievc-hw-en50155-11-2][p1][s]

This requirement applies to all hardware components.

14.1.12.2 Fire behavior (11.3)

Compliance with EN 45545 series of protection against spread of fire is used. This requirement also appears
in [SyAD-R31-TSI-LOCPAS:2014]. The corresponding requirement in the URS is tsc-req-urs-nobo-locpas-fire-
en45545[req]. It is exported to the installation design and allocated to each on-board hardware component

Requirement

Installation design components (including cables) shall comply with EN45545-2:2013+A1:2015, with
a fire hazard level of 2 or higher. [id:tsc-req-ievc-hw-en50155-11-3][p1][s]

Allocate
Allocation of EN45545 to iEVC on-board components [allocate]

726 of 750 14.1. EN50155 requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-nobo-locpas-fire-en45545[req]
• Ci:
– Computer box hardware[ci]
– Sensor box hardware[ci]
– Telecom box hardware[ci]
– Ethernet switch[ci]
– Crash protected memory[ci]
– DMI hardware[ci]
– Wheel pulse generators[ci]
– Secondary odometry sensor[ci]
– Safety relay[ci]
– GPS antenna[ci]
– GSM-R antenna[ci]
– 4G antenna[ci]
• Justification: EN45545 compliance requirement is transferred to all on-board iEVC compo-
nents.

14.1.12.3 Functional safety (11.4)

This is not part of the EN 50155 standard. Refer to Safety & Cybersecurity requirements.

14.1.12.4 Personnel safety (11.5)

While the iEVC exports no specific requirements for personnel safety, it does require component manufactures to
document any eventual hazard to personnel safety deriving from the component design.

Requirement

Component documentation shall mention any potential health or personnel safety hazard related to
the usage of the component. [id:tsc-req-ievc-hw-en50155-11-5-hazards][p2][s]

This requirement applies to all iEVC hardware components. The documentation provided will be incor-
porated in the iEVC operation and maintenance manuals.

It is also required to document the skills necessary to maintain the component, as it may participate to personnel
safety.

Requirement

This document shall contain:

• hardware principles,
• principles of electrical connections,
• non functional requirements,
• main mechanical constrains.
This requirement applies to all hardware components to be developed.

Requirement

Start of hardware component prototyping or production shall be conditionned to the approval of the
hardware requirement specificiation and design documents by TSC iEVC program. This approval
shall be materialized by a gate review, organized by the component designer. [id:tsc-req-ievc-hw-
en50155-12-gate-review][p1][ns]

This requirement applies to all hardware components to be developed.

Allocate
Allocation of the URS requirement that require that the component power consumption shall be
specified with 5% precision. [allocate]

14.1. EN50155 requirements 729 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-install-ievc-specify-power-consumption-5-pct[req]
• Ci:
– Sensor box hardware[ci]
– iBTM-TX[ci]
– iBTM-RX[ci]
– iODO[ci]
– iODO BITE[ci]
– Sensor Box Power Supply[ci]
– Sensor box ethernet switch[ci]
– Telecom box hardware[ci]
– Ethernet switch[ci]
– Telecom box power supply[ci]
– GSM-R modem[ci]
– 4G modem[ci]
– Computer box power supply[ci]
– Computer box hardware[ci]
– Safe computer[ci]
– Safe computer IO Extension[ci]
– IO board[ci]
– DMI hardware[ci]
– Crash protected memory[ci]
– Euroantenna[ci]
– Wheel pulse generators[ci]
– Safety relay[ci]
– 4G antenna[ci]
– GSM-R antenna[ci]
– GPS antenna[ci]
• Justification: This requirement applies to all hardware components of the iEVC

Note: the power consumption of the 4G and GSM-R modems shall include the consumption of their
respective antenna.

730 of 750 14.1. EN50155 requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

14.1.14 Testing

Requirement

Component test specification shall meet the requirements of section 13 of EN 50155:2017 [id:tsc-req-
ievc-hw-en50155-13][p1][ns]

This requirement applies to all hardware components.

Requirement

Should the installation design include the manufacturing of an enclosure or a customized compo-
nent, this enclosure or component test specification shall meet the requirements of section 13 of EN
50155:2017 [id:tsc-req-ievc-hw-en50155-13-install-design][p1][ns]

14.1.15 Product hardware requirements

Requirement

On the front panel, only latched connectors shall be used (e.g. MIL-C bayonet and/or rugged
RJ45 connectors). No screwed connector shall be used (e.g. M12) [id:tsc-req-ievc-hw-box-connectors-
bayonet][p2][ns]

Requirement

On the front panel, all connectors shall have secured blanking caps when they are not in use.
[id:tsc-req-ievc-hw-box-connectors-blanking-caps][p2][ns]

Requirement

On the front panel, connectors shall be uniquely identified. [id:tsc-req-ievc-hw-box-connectors-

id][p1][ns]

This requirement applies to boxes and peripherals.

Requirement

Component shall have a earthing connector [id:tsc-req-ievc-hw-earthing-connector][p1][s]

This requirement applies to boxes and peripherals.

Requirement

Component protection level shall be IP65 or better [id:tsc-req-ievc-hw-ip65][p1][s]

This requirement applies to externally mounted components (including their cables) and the crash pro-
tected memory.

Requirement

Box protection level shall be IP55 or better [id:tsc-req-ievc-hw-ip55][p2][s]

14.1. EN50155 requirements 731 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

This requirement applies to boxes and the DMI (at least its front side and external loudspeaker).

Requirement

iEVC connectors protection level shall be IP55 or better [id:tsc-req-ievc-hw-connectors-ip55][p2][s]

Requirement

iEVC cables protection level shall be IP55 or better [id:tsc-req-ievc-hw-cables-ip55][p2][s]

Requirement

iEVC cables that are meant to be mounted externally shall be IP65 or better [id:tsc-req-ievc-hw-
external-cables-ip65][p2][s]

Requirement

On the front panel, there shall be a power on/off switch [id:tsc-req-ievc-hw-box-on-off-switch][p2][s]

This requirement applies to boxes.

Requirement

Switches on the boxes front panels shall have a protection cover. [id:tsc-req-ievc-hw-box-switch-
protection-cover][p2][ns]

This requirement applies to boxes.

Requirement

Box size and mounting points shall be harmonized [id:tsc-req-ievc-hw-box-harmony-size-

mounting][p1][ns]

This requirement applies to boxes.

Requirement

Box connector choice shall be harmonized [id:tsc-req-ievc-hw-box-harmony-connectors][p1][ns]

Sensor box color shall be green [id:tsc-req-ievc-hw-box-sensor-green][p2][ns]

Requirement

The iEVC boxes and connectors shall resist being stepped onto. [id:tsc-req-ievc-hw-box-crush][p2][ns]

14.2 ERA Opinions and BCA

The iEVC system, in accordance with [SyAD-R3-PQP] and [SyAD-R39-ERA-OPI-2020-2] clause 4.3, must im-
plement the ERA change requests classified as error that potentially prevents the normal service, depending on the
actual use of the related functionality and on the combination of the onboard and trackside implementation.

Requirement

The iEVC On-board subsystem shall be compliant with the ERA corrective change requests from
the 2020-2 ERA opinion. [id:tsc-req-ievc-ss26-app-era-opi-2020-2][p1][ns]

The following change requests are considered potentially applicable to the Subset 026 application:

Table 14.1: ERA opinion 2020-2 - List of change requests for iEVC
system
CR n° Headline
0887 Position Report Consistency (Follow-up of CR556)
0994 Text message start conditions
1021 Brake command revocation/acknowledgment issues
1023 Conditions for start/end text message
1120 Uncertain handling of some infill information
1128 Passing Level 0 / Level NTC border in PT mode
1130 Contradiction between SRS 3.12.2.8 (Trip at route unsuitability) and SRS
3.13.10.2.6/7
1146 Euroradio HDLC parameters
1162 Functions that could use linking information in modes without linking consistency
check
1166 Ambiguities in driver acknowledgment requirements
1170 Ambiguity about the list of traction systems accepted by a diesel engine
1251 Use of inconsistent or incomplete terms for the cooperative MA shortening func-
tion
1252 Ambiguities about release speed and application of A.3.4 in case a train accepts a
CES
1259 Accuracy of distances measured on-board not considered when determining Re-
lease Speed from MRSP
1263 MA request condition when LoA speed is above MRSP
1264 Exhaustiveness of the list of actions not to be reverted or executed twice
1267 Acquiring the list of available networks whilst communication session is estab-
lished
1274 Problem to compare locations in the absence of linking information
1288 Shortcomings due to specific locations temporarily considered as the EOA/SvL

14.2. ERA Opinions and BCA 733 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

1293 Ambiguity about clauses to be applied to messages containing high priority data
1295 TSR inhibition in SB and SR modes
1296 Wrong assumption in on-board calculation of release speed
1300 Follow-up to CR977
1306 Undefined sequence of actions following the filtering of trackside information as
per SRS 4.8
1309 Enhancement of HDLC to handle retransmission of SABME message
1310 DNS/ETCS on-board communication handling
1311 Inconsistency in Subset-026 regarding the relevance of Q_SLEEPSESSION for
session termination orders
1312 Undefined sequence of actions following the filtering of trackside information as
per SRS 4.8 (part 2)
1313 Unclear management of train position status on passing unlinked BG(s)
1318 Ambiguity in determination of location accuracy
1319 Support of different transmission speeds (ETCS data)
1320 MA request issues
1321 Transition PS-SF inconsistent with other slave modes
1324 Problems with applying SRS clauses related to the supervision of an unprotected
LX
1325 Rejection of safety relevant information due to pending acknowledgment of vali-
dated train data
1326 Display conflict in area D of ETCS DMI
1327 Reset of confidence interval
1332 Release speed calculated on-board while a LTO in rear of the EOA is stored on-
board
1333 Subset-026 clause 3.12.4.4 does not cover the case of reception of a new MA
without mode profile
1334 Ambiguity regarding the mode and level end events for the display of a text mes-
sage
1335 Train categories B3 on B2
1338 Issues regarding the forwarding of data to a National System
1340 Maximum D_LRBG exceeded
1347 Unclear specification of “balise detection degradation” function
1348 No change of speed and distance monitoring supervision status

Requirement

The iEVC On-board subsystem shall be compliant with the ERA corrective radio change requests
from the 2020-2 ERA opinion. [id:tsc-req-ievc-ss26-app-era-opi-2020-2-radio][p1][ns]

The following change requests are considered

Table 14.2: ERA opinion 2020-2 - List of radio change requests for iEVC
system
CR n° Headline Allocation
5041 Radio characteristics for EDOR GSM-R modem
5049 PPP Activation timeout is not defined and ETCS GSM-R modem, CFM
DNS query repetition is missing
5050 Errors & inconsistencies found in FFFIS for SIM GSM-R modem
card

734 of 750 14.2. ERA Opinions and BCA

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

14.3 Design provisions for ERTMS game changers

The following design provisions have been identified as provision for the future version of the TSI CCS planned
in 2022.
• the iEVC system must have spare ethernet ports to anticipate the standardization of a “signalling” network
allowing the add-on of the “game changers modules”.
• The installation design shall include empty space to allow installation of future equipment such as the
FRMCS radio module.
Allocate
Allocation of the URS requirement to have spare ethernet port [allocate]
Data
• Requirement:
– tsc-req-urs-nobo-ccs-tsi2022-dual-ethernet[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: network_allocation_table
• Justification: The ethernet port allocation of the ethernet switch includes 2 spares

Requirement

The installation design shall include empty space to allow installation of future equipment such as
the FRMCS radio module. [id:tsc-req-ievc-provisions-spare-space][p1][ns]

14.4 Design provisions for national rules

National rules refer to all binding rules adopted in a Member State, irrespective of the body issuing them, which
contain railway safety or technical requirements, other than those laid down by Union or international rules, and
which are applicable within that Member State to railway undertakings, infrastructure managers or third parties.
National rules are often based on national technical standards, are being gradually replaced by rules based on com-
mon standards, established by Common Safety Methods (CSMs) and Technical Specifications for Interoperability
(TSIs). In order to eliminate the obstacles to interoperability, the volume of national rules, including operating
rules, is expected be reduced as a consequence of extending the scope of the TSIs to the whole of the Union rail
system and of closing open points in the TSIs.
The national rules in Belgium, the Netherlands, France and Germany have been reviewed and no additional tech-
nical requirement on the iEVC system has been identified.

14.3. Design provisions for ERTMS game changers 735 of 750

Requirement

DMI ergonomics shall be verified by a panel of drivers. This verification shall cover mode changes,
start of mission and data entry but also the DMI location on the desk. [id:tsc-req-ievc-ergonomics-
verification][p1][ns]

736 of 750 14.5. Assignment of values to ETCS variables

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

14.8 Miscellaneous requirements

This section allocates remaining miscellaneous requirements appropriately.

Allocate
Allocation of TSI requirement not to modify interfaces or components of the TSI framework [allo-
cate]

Data
• Requirement:
– tsc-req-ievc-pqp-tsi-4-2-1-1[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: Traceability matrix
• Justification: SyAD traceability matrix demonstrates that iEVC does not export additional
requirements to components or interfaces falling within the TSI framework

Allocate
Allocation of requirement related to the area of use [allocate]
Data
• Requirement:
– tsc-req-urs-install-obtains-authorization-for-areas-of-use[req]
• Artifact:
– iEVC Platform Safety Plan[artifact]
• Justification: The iEVC Platform Safety Plan shall define the structure of safety cases to
cover the generic product and so to cover the area of use

Allocate
Allocation of EN 50126 compliance to the dedicated traceability document [allocate]
Data
• Requirement:
– tsc-req-stake-rams-en-50126-1-2017[req]
– tsc-req-stake-rams-en-50126-2-2017[req]
• Artifact:
– IEVC EN50126:2017 requirements traceability matrix[artifact]
• Justification: Detailed traceability to EN50126 requirements is provided by this document

Allocate
Allocation of EN 50129 compliance to the dedicated traceability document [allocate]

14.8. Miscellaneous requirements 737 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-rams-en-50129-2018[req]
• Artifact:
– IEVC EN50129:2018 requirements traceability matrix[artifact]
• Justification: Detailed traceability to EN50129 requirements is provided by this document

Allocate
Allocation of EN 50128 compliance to the dedicated traceability document [allocate]
Data
• Requirement:
– tsc-req-stake-rams-en-50128-2011[req]
• Artifact:
– IEVC EN50128:2011 requirements traceability matrix[artifact]
• Justification: Detailed traceability to EN50128 requirements is provided by this document

Allocate
Allocation of ISO 9001 compliance to quality plan [allocate]
Data
• Requirement:
– tsc-req-stake-rams-iso-9001-2015[req]
• Artifact:
– IEVC Project Quality Plan[artifact]
• Justification: Compliance with ISO 9001 is demonstrated by the quality plan, where ISO
certificate is mentioned.

Requirement

When required, the installation project team shall develop a specific application to be able to manage
the operating mode ‘refoulement’ [id:tsc-req-ievc-refoulement][p1][ns]

This mode allows reverse movement over large distances (typically 600m) under the respon-
sibility of the operators. In this mode the iEVC system will not trip when reading balises of
type “danger for shunting”.

Allocate
Allocation of the URS intellectual property requirement to the iEVC hardware components [allocate]

738 of 750 14.8. Miscellaneous requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-install-ievc-ip-rights[req]
• Ci:
– Computer box hardware[ci]
– Sensor box hardware[ci]
– Telecom box hardware[ci]
– Crash protected memory[ci]
– DMI hardware[ci]
– Safety relay[ci]
– Euroantenna[ci]
– Wheel pulse generators[ci]
– Secondary odometry sensor[ci]
– Safe computer[ci]
– Computer box power supply[ci]
– 4G modem[ci]
– GSM-R modem[ci]
– Ethernet switch[ci]
– Telecom box power supply[ci]
– iBTM-RX[ci]
– iBTM-TX[ci]
– iODO[ci]
– iODO BITE[ci]
– Sensor Box Power Supply[ci]
– Sensor box ethernet switch[ci]
• Justification: this requirement applies to all hardware components.

Allocate
Allocation of the URS intellectual property requirement to the iEVC software components [allocate]
Data
• Requirement:
– tsc-req-urs-install-ievc-ip-rights[req]
• Artifact:
– iEVC Software Architecture and Design Specification[artifact]
• Justification: All the software components are developped by TSC

14.8. Miscellaneous requirements 739 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Requirement

A target cost analysis shall be carried on based on the target set by TSC supply chain. [id:tsc-req-
ievc-target-component-cost][p1][ns]

The analysis shall be carried out by the iEVC Supply chain team in a specific document outside of this
SyAD. The analysis document is confidential by nature.

Artifact
iEVC Target cost analysis [artifact]

Allocate
Allocation of the requirement for driver manual [allocate]
Data
• Requirement:
– tsc-req-urs-driver-dmi-manual[req]
• Artifact:
– iEVC ETCS Kit Driver Manual[artifact]
• Justification: The driver manual covers the requirement.

Allocate
Allocation of the URS requirement for operation, maintenance and driver manual [allocate]
Data
• Requirement:
– tsc-req-urs-operator-ievc-manuals[req]
• Artifact:
– iEVC Basic Kit Operation Manual[artifact]
– iEVC Basic Kit Maintenance Manual[artifact]
– iEVC Sensor Kit Operation Manual[artifact]
– iEVC Sensor Kit Maintenance Manual[artifact]
– iEVC Telecom Kit Operation Manual[artifact]
– iEVC Telecom Kit Maintenance Manual[artifact]
– iEVC ETCS Kit Operation Manual[artifact]
– iEVC ETCS Kit Driver Manual[artifact]
• Justification: The different iEVC kits manuals cover this requirement.

Allocate
Allocation of the URS requirement that no periodic reboot shall be required [allocate]

740 of 750 14.8. Miscellaneous requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-operator-perf-no-reboot-needed[req]
• Ci:
– Safe computer[ci]
– DMI computer[ci]
– GSM-R modem[ci]
– Ethernet switch[ci]
– Sensor box ethernet switch[ci]
– 4G modem[ci]
– iBTM-RX[ci]
– iBTM-TX[ci]
– iODO[ci]
– iODO BITE[ci]
– Crash protected memory[ci]
• Justification: This requirement is allocated to all the hardware components. The software
components do not require structural reboot; in line of principle a reboot is needed only
when a bug occurs.

14.8. Miscellaneous requirements 741 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
CHAPTER

FIFTEEN

TRACEABILITY MATRIX

15.1 URS traceability

Req Traceability Matrix

URS RTM [req traceability matrix]

15.2 Subset 036 traceability

Configuration Item

Subset 036 [ci]

Data
• Sil: Undefined

Input Data Table

SUBSET 036 [xlsx data]

Req Traceability Matrix

Subset 036 RTM [req traceability matrix]

Allocate
Allocation of URS requirement for compliance to Subset-036 [allocate]

742 of 750 15. Traceability matrix

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-nobo-subset-036[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: Subset 036 traceability
• Justification: The detailed allocation is provided by a specific traceability matrix inside the
SyAD

15.3 Subset 037 traceability

Configuration Item

Subset 037 [ci]

Data
• Sil: Undefined

Input Data Table

SUBSET 037 [xlsx data]

Req Traceability Matrix

Subset 037 RTM [req traceability matrix]

Allocate
Allocation of URS requirement for compliance to Subset-037 [allocate]
Data
• Requirement:
– tsc-req-urs-nobo-subset-037[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: Subset 037 traceability
• Justification: The detailed allocation is provided by a specific traceability matrix inside the
SyAD

15.3. Subset 037 traceability 743 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

15.4 Subset 040 traceability

Configuration Item

Subset 040 [ci]

Data
• Sil: Undefined

Input Data Table

SUBSET 040 [xlsx data]

Req Traceability Matrix

Subset 040 RTM [req traceability matrix]

Allocate
Allocation of URS requirement for compliance to Subset-040 [allocate]
Data
• Requirement:
– tsc-req-urs-nobo-subset-040[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: Subset 040 traceability
• Justification: The detailed allocation is provided by a specific traceability matrix inside the
SyAD

15.5 Subset 041 traceability

Configuration Item

Subset 041 [ci]

Data
• Sil: Undefined

Input Data Table

SUBSET 041 [xlsx data]

744 of 750 15.4. Subset 040 traceability

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Req Traceability Matrix

Subset 041 RTM [req traceability matrix]

Allocate
Allocation of URS requirement for compliance to Subset-041 [allocate]
Data
• Requirement:
– tsc-req-urs-nobo-subset-041[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: Subset 041 traceability
• Justification: The detailed allocation is provided by a specific traceability matrix inside the
SyAD

15.6 ERA_ERTMS_015560 traceability

Configuration Item

ERA_ERTMS_015560 [ci]
Data
• Sil: Undefined

Input Data Table

ERA_ERTMS_015560 requirements [xlsx data]

Req Traceability Matrix

ERA_ERTMS_015560 RTM [req traceability matrix]

Allocate
Allocation of URS requirement for compliance to ERA_ERTMS_015560 [allocate]

15.6. ERA_ERTMS_015560 traceability 745 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

Data
• Requirement:
– tsc-req-urs-nobo-ertms-015560[req]
– tsc-req-urs-ievc-communicate-with-driver[req]
• Artifact:
– iEVC System Architecture Description[artifact]
• Artifact ref: ERA_ERTMS_015560 traceability
• Justification: The detailed allocation is provided by a specific traceability matrix inside the
SyAD

746 of 750 15.6. ERA_ERTMS_015560 traceability

b2c00c725888f54563d63f5293b6fdc2681109bb
CHAPTER

SIXTEEN

APPENDIX

16.1 Compatibility with OCORA concepts

OCORA stands for Open CCS On-board Reference Architecture. OCORA is a collaboration of railway companies
with 5 founding members that decided to combine engineering resources in the CCS domain to work on ERTMS
and beyond. Refer to [SyAD-R11-OCORA] for an in-depth definition.
The OCORA layered architecture is compatible with iEVC:
• Safe / secure operating system == Safe computer
• Output distribution / Input fusion == TSC Net
• Standardized safe runtime environment == Virtual machine
• Safety application == Applications
• COTS OS == Non-safe OS running on the Safe computer like Linux
However, our concept differs in some areas:
• We are planning to run unsafe apps and safe apps alongside inside the virtual machine
• We are not interested in a hardware “abstraction layer” as long as we can run our virtual machine and a Linux
on the safe platform. This could be of interest to the suppliers of safety computers (in order to standardize
the hardware interface) but it is unclear if railway has enough scale to justify such a standardization effort.
Nevertheless, the principles of OCORA are a nice summary of the goals of the iEVC:
• Reducing SIL4 systems to the minimal functionality
• Interfaces with “modular safety” qualities (allows isolated safety case per components) (. . . /. . . )
• Incremental safety case (automated impact analysis)
• Platform independence (. . . )
• Remote and automated update of safe applications
Principles of OCORA are therefore compatible with our design. One function we do not have in the architecture
is “intelligent load balancing”. But it will be possible to add on top of the mechanisms we are providing, if we
give the possibility for iEVCs to “subscribe” to variable updates from one another.

16. Appendix 747 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

16.2 Exported requirements

This section provides the list of requirements exported by the system specification documents to:
• Installation project application,
• Class B application,
• KER Class B application

Installation project application requirement list [req list]

Class B application requirement list [req list]

KER Class B application requirement list [req list]

16.3 URS functions traceability

This section provides the traceability between the URS functions described in [SyAD-R1-SD] and the functions
defined in this document.
Function Traceability Matrix

URS functions traceability matrix [function traceability matrix]

Realizing CI
CI Name Source Function Realizing Function
Name
[URS.F1.05] Execute appli- [IEVC.F1.05] Execute ap-
URS iEVC
cations plications
[URS.F1.15] Record execu- [IEVC.F1.15] Record exe-
URS iEVC
tion cution
[URS.F1.20] Manage de- [IEVC.F1.20] Manage de-
URS SIDE Authorizer
ployment authorizations ployment authorizations
[URS.F1.26] Support Con- [IEVC.F1.26] Support Con-
SIDE Configura-
URS figuration Data Preparation figuration Data Preparation
tor
and Verification and Verification
[URS.F100] Run the train [IEVC.F100.LINEAS] Run
URS under Lineas specific oper- iEVC the train under Lineas spe-
ating modes cific operating modes
[URS.F1] Develop iEVC [IEVC.F1] Develop IEVC
URS iEVC
application applications
[URS.F3.02.01] Manage Subset 026 appli- [IEVC.F3.02.01] Manage
URS
Data entry cation Data entry
[URS.F3.02.02] Select Su- [IEVC.F3.02.02] Select Su-
pervision mode on the basis Subset 026 appli- pervision mode on the basis
URS
of information from track- cation of information from track-
side side
[URS.F3.02.03] Execute [IEVC.F3.02.03] Execute
URS iEVC
odometry functions odometry functions
[URS.F3.02.04] Compute Subset 026 appli- [IEVC.F3.02.04] Compute
URS
the dynamic speed profile cation the dynamic speed profile
[URS.F3.02.05] Supervise Subset 026 appli- [IEVC.F3.02.05] Supervise
URS
the dynamic speed profile cation the dynamic speed profile

748 of 750 16.2. Exported requirements

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

[URS.F3.02.06] Provide the Subset 026 appli- [IEVC.F3.02.06] Provide

URS
intervention function cation the intervention function
[URS.F3.02.07] Read Eu- [IEVC.F3.02.07] Read Eu-
URS iEVC
robalise information robalise information
[URS.F3.02.08] Communi- [IEVC.F3.02.08] Communi-
URS cate through radio commu- iEVC cate through radio commu-
nication nication
[URS.F3.02.09] Communi- [IEVC.F3.02.09] Communi-
URS iEVC
cate with the driver cate with the driver
[URS.F3.02.10] Communi- Subset 026 appli- [IEVC.F3.02.10] Communi-
URS
cate with the STM cation cate with the STM
[URS.F3.02.12] Manage [IEVC.F3.02.12] Man-
Subset 026 appli-
URS equipment health and age equipment health and
cation
degraded modes degraded modes
[URS.F3.02.13] Support [IEVC.F3.02.13] Support
URS data recording for regulatory iEVC data recording for regulatory
purposes purposes
[URS.F3.02.14] Manage [IEVC.F3.02.14] Manage
URS iEVC
train interface train interface
[URS.F3.02] Execute ETCS [IEVC.F3.02] Execute
URS iEVC
functions ETCS functions
[URS.F3.03.02] Support test [IEVC.F3.03.02] Support
URS iEVC
according to Subset 076 test according to Subset 076
[URS.F3.03.03] Support test [IEVC.F3.03.03] Support
URS according to Subset 085 iEVC test according to Subset 085
(BTM tests) (BTM tests)
[URS.F3.03.04] Support test [IEVC.F3.03.04] Support
URS according to Subset 092 iEVC test according to Subset 092
(Euroradio tests) (Euroradio tests)
[URS.F3.03.05] Support test [IEVC.F3.03.05] Support
according to Subset 094 (In- test according to Subset
URS iEVC
teroperability tests architec- 094 (Interoperability tests
ture) architecture)
[IEVC.F3.03] Support
[URS.F3.03] Support ETCS
URS iEVC ETCS CI certification
CI certification process
process
[URS.F3] Run trains under [IEVC.F3] Run trains under
URS iEVC
ETCS control (subset 26) ETCS control
[URS.F4.05] Collect failure [IEVC.F4.05] Collect a fail-
URS iEVC
report from driver ure report from the driver
[IEVC.F4.07] Determine es-
[URS.F4.07] Determine es-
URS iEVC timated lifetime and trigger
timated lifetime
lifetime warning.
[URS.F4.08] Display fault [IEVC.F4.08] Display fault
URS iEVC
synoptic synoptic
[URS.F4.11] Perform LRU [IEVC.F4.11] Perform LRU
URS iEVC
interactive tests interactive tests
[URS.F4.12] Produce con- [IEVC.F4.12] Produce con-
URS iEVC
figuration report figuration report
[URS.F4.13] Produce event [IEVC.F4.13] Produce event
URS iEVC
report report
[URS.F4.14] Produce ser- [IEVC.F4.14] Produce ser-
URS iEVC
vice report vice report
URS [URS.F4.15] Record events OBOM [IEVC.F4.13.01] Log event

16.3. URS functions traceability 749 of 750

b2c00c725888f54563d63f5293b6fdc2681109bb
iEVC System Architecture Description

[IEVC.F4.07.03] Publish
[URS.F4.16] Record life-
URS OBOM lifetime data and warnings
time
(OBOM)
[URS.F4.16] Record life-
URS OBOM [IEVC.F5.05.01] Log Data
time
[IEVC.F4.07.02] Publish
[URS.F4.16] Record life-
URS Virtual machine lifetime data and warnings
time
(VM)
[URS.F4.17] Record main- [IEVC.F4.17] Record a
URS iEVC
tenance activity maintenance activity
[IEVC.F4.29.03] Publish
URS [URS.F4.19] Report events OBOM
fault status
[URS.F4.24] Trigger life- [IEVC.F4.07.01] Determine
URS LRU application
time warnings LRU lifetime and warnings
[URS.F4.25] Troubleshoot [IEVC.F4.08] Display fault
URS iEVC
the iEVC synoptic
[URS.F4] Maintain iEVC in [IEVC.F4] Maintain IEVC
URS iEVC
service in service
[IEVC.F5.05.02] Record
[URS.F5.02] Record data in Crash protected
URS data in crash protected
crash protected memory memory
memory
[URS.F5.03] Record GPS [IEVC.F5.03] Record GPS
URS iEVC
position and time position and time
[URS.F5.05] Record se- [IEVC.F5.05] Record se-
URS iEVC
lected variables lected variables
[URS.F5] Operate trains fit- [IEVC.F5] Operate trains
URS iEVC
ted with iEVC fitted with iEVC

16.4 Assumptions recapitulation

16.4.1 List of assumptions [recap table]

Table 16.2: List of assumptions

Id Description Ci Is safety related
IEVC-ASS-SYAD- The system model used iEVC[ci] Yes
ODO-001 by the odometry EKF is
linear and time invariant
IEVC-ASS-SYAD- The model is in state- iEVC[ci] Yes
ODO-002 space form
IEVC-ASS-SYAD- The state and measure- iEVC[ci] Yes
ODO-003 ment noise models are
zero mean gaussian and
independent of one an-
other
IEVC-ASS-SYAD- Subset 041 requirements iEVC[ci] Yes
ODO-004 for confidence interval
correspond to a 6.5 sigma
interval

750 of 750 16.4. Assumptions recapitulation

b2c00c725888f54563d63f5293b6fdc2681109bb

Intrusion Detection Honeypots
From Everand
Intrusion Detection Honeypots
Chris Sanders
3/5 (2)
DWC_pcie_ctl_sw_databook
No ratings yet
DWC_pcie_ctl_sw_databook
1,093 pages
Essenza Mars
100% (3)
Essenza Mars
38 pages
03 9708 22 2023 2RP Afp M23 20022023
100% (1)
03 9708 22 2023 2RP Afp M23 20022023
4 pages
IxiaReferenceGuide PDF
No ratings yet
IxiaReferenceGuide PDF
914 pages
Manual Siemens BS 240 & 241 PDF
100% (1)
Manual Siemens BS 240 & 241 PDF
77 pages
Radio Ip Alcatel
100% (3)
Radio Ip Alcatel
548 pages
Planning and Installation Guide For Tricon v9-V11 Systems (Dec 2018)
80% (5)
Planning and Installation Guide For Tricon v9-V11 Systems (Dec 2018)
421 pages
ATV900 Ethernet Manual Embedded NHA80940 03
No ratings yet
ATV900 Ethernet Manual Embedded NHA80940 03
148 pages
ATV340 Ethernet Embedded Manual NVE61653 03
No ratings yet
ATV340 Ethernet Embedded Manual NVE61653 03
156 pages
Altivar 61/71: Variable Speed Drives For Synchronous and Asynchronous Motors Profinet Communication Manual VW3A3327
No ratings yet
Altivar 61/71: Variable Speed Drives For Synchronous and Asynchronous Motors Profinet Communication Manual VW3A3327
84 pages
Profinet VW3A3327 2013 en
No ratings yet
Profinet VW3A3327 2013 en
84 pages
ATV600 DeviceNet Manual en EAV64330 01
No ratings yet
ATV600 DeviceNet Manual en EAV64330 01
121 pages
Alcatel 1000 S12 Functional Description PDF
100% (2)
Alcatel 1000 S12 Functional Description PDF
582 pages
Twave T8 User Manual: Release 0.4.0
No ratings yet
Twave T8 User Manual: Release 0.4.0
167 pages
AWY 20 Technical ED03
No ratings yet
AWY 20 Technical ED03
338 pages
t8 Manual v2.0
No ratings yet
t8 Manual v2.0
195 pages
E84aycib Interbus Mci Module v4-0 en
No ratings yet
E84aycib Interbus Mci Module v4-0 en
75 pages
Data Manual: February 2003 1394 Host Controller Solutions
No ratings yet
Data Manual: February 2003 1394 Host Controller Solutions
110 pages
Data Manual: February 2003 1394 Host Controller Solutions
No ratings yet
Data Manual: February 2003 1394 Host Controller Solutions
110 pages
door controller
No ratings yet
door controller
199 pages
Ha030047 - 11 User Guide
0% (1)
Ha030047 - 11 User Guide
202 pages
Altivar Process 900: Modbus SL Manual
No ratings yet
Altivar Process 900: Modbus SL Manual
118 pages
Enerlin'X IFE: Ethernet Interface For One IEC Circuit Breaker User Guide
No ratings yet
Enerlin'X IFE: Ethernet Interface For One IEC Circuit Breaker User Guide
96 pages
ATV6000 Modbus SL Manual MFR24213 01
No ratings yet
ATV6000 Modbus SL Manual MFR24213 01
98 pages
Altivar Process 900 Ethernet Manual en NHA80940 01
No ratings yet
Altivar Process 900 Ethernet Manual en NHA80940 01
156 pages
Mn00114e PDF
No ratings yet
Mn00114e PDF
178 pages
AWY_20_Technical
No ratings yet
AWY_20_Technical
306 pages
Altivar Process 900: PROFINET Manual - VW3A3627
No ratings yet
Altivar Process 900: PROFINET Manual - VW3A3627
126 pages
Eio0000002836 00
No ratings yet
Eio0000002836 00
122 pages
I Xia Reference Guide
0% (1)
I Xia Reference Guide
40 pages
Ted Sma1k-Cp
No ratings yet
Ted Sma1k-Cp
74 pages
Teles - Igate 14.0
No ratings yet
Teles - Igate 14.0
234 pages
A 13 2 4 Technical Description BS241 II
100% (1)
A 13 2 4 Technical Description BS241 II
70 pages
M Us 106113 Iqube2 Technical Revc
No ratings yet
M Us 106113 Iqube2 Technical Revc
86 pages
eBUS SDK Programmer's Guide
No ratings yet
eBUS SDK Programmer's Guide
98 pages
Slla 067 A
No ratings yet
Slla 067 A
79 pages
Ha030554 13 PDF
100% (1)
Ha030554 13 PDF
410 pages
TELES iGATE 17.0 ReferenceManual 001
No ratings yet
TELES iGATE 17.0 ReferenceManual 001
271 pages
TSX Quantum 140 ERT 854 10 Manual Eng
No ratings yet
TSX Quantum 140 ERT 854 10 Manual Eng
116 pages
Ug962 v7 Vc709 XT Connectivity TRD Ug
No ratings yet
Ug962 v7 Vc709 XT Connectivity TRD Ug
98 pages
02 CIP Equipment
No ratings yet
02 CIP Equipment
31 pages
AUTOSAR CP SWS CANNetworkManagement-pages-2
No ratings yet
AUTOSAR CP SWS CANNetworkManagement-pages-2
3 pages
Ethernet Manual (Embedded)
No ratings yet
Ethernet Manual (Embedded)
100 pages
Altivar Machine 320: Variable Speed Drives For Synchronous and Asynchronous Motors Modbus Serial Link Manual
No ratings yet
Altivar Machine 320: Variable Speed Drives For Synchronous and Asynchronous Motors Modbus Serial Link Manual
84 pages
EIO0000001681.01
No ratings yet
EIO0000001681.01
170 pages
Ni Daqmx - 11 14 2023
No ratings yet
Ni Daqmx - 11 14 2023
1,047 pages
B7700 CAN Manual en
No ratings yet
B7700 CAN Manual en
246 pages
MTB-00001-06 TP9400 API protocal manual
No ratings yet
MTB-00001-06 TP9400 API protocal manual
88 pages
Read The Docs - Espressif PDF
No ratings yet
Read The Docs - Espressif PDF
2,201 pages
Read The Docs - Espressif PDF
No ratings yet
Read The Docs - Espressif PDF
2,201 pages
Igate Systems Manual: Software Version 14.5
No ratings yet
Igate Systems Manual: Software Version 14.5
234 pages
VTX_Two-Way Communications 88700 v.1.00
No ratings yet
VTX_Two-Way Communications 88700 v.1.00
116 pages
S140_SDS_v2.1
No ratings yet
S140_SDS_v2.1
110 pages
Cu Vrtu Ig
No ratings yet
Cu Vrtu Ig
90 pages
LHR Technical
No ratings yet
LHR Technical
548 pages
SIMATIC 545 System Manual 505-8201-3
No ratings yet
SIMATIC 545 System Manual 505-8201-3
322 pages
Transcede 2xxx Hardware Data Sheet (PN 842xx-DSH-001-A) PDF
No ratings yet
Transcede 2xxx Hardware Data Sheet (PN 842xx-DSH-001-A) PDF
257 pages
Content Creation Revolution with chatGPT
From Everand
Content Creation Revolution with chatGPT
Maria Cowen
No ratings yet
Kellory the Warlock
From Everand
Kellory the Warlock
Lin Carter
No ratings yet
Gray Hat Hacking the Ethical Hacker's
From Everand
Gray Hat Hacking the Ethical Hacker's
Çağatay Şanlı
5/5 (1)
Rizal Biñan
No ratings yet
Rizal Biñan
2 pages
EMB120 Airport Planning Manual
No ratings yet
EMB120 Airport Planning Manual
115 pages
CATHECISM
No ratings yet
CATHECISM
2 pages
Weather Forecasting App
No ratings yet
Weather Forecasting App
1 page
Body Part Leadership
No ratings yet
Body Part Leadership
5 pages
Fortnite Template - Animated
No ratings yet
Fortnite Template - Animated
17 pages
Ecycle 01
No ratings yet
Ecycle 01
58 pages
Application of Business Analytics in Corporate Enterprises, An Exploratory Study
No ratings yet
Application of Business Analytics in Corporate Enterprises, An Exploratory Study
15 pages
Grade_2-WAP-Nov__25-29__2024
No ratings yet
Grade_2-WAP-Nov__25-29__2024
4 pages
4theory of Consumer Behavior
No ratings yet
4theory of Consumer Behavior
6 pages
Del Rosario Vs Conanan
No ratings yet
Del Rosario Vs Conanan
5 pages
Comparison
No ratings yet
Comparison
25 pages
Shaze
No ratings yet
Shaze
1 page
Size Ingredient
No ratings yet
Size Ingredient
16 pages
Sikagrout - 4 Uw
No ratings yet
Sikagrout - 4 Uw
3 pages
Muslim Marriage (Nikah) : Mutual Rights and Obligations
100% (1)
Muslim Marriage (Nikah) : Mutual Rights and Obligations
10 pages
Inter Miami
No ratings yet
Inter Miami
1 page
Simple Form: The Participle Ending Is - en
No ratings yet
Simple Form: The Participle Ending Is - en
4 pages
Warframe Issue #1 - Read Warframe Issue #1 comic online in high quality
No ratings yet
Warframe Issue #1 - Read Warframe Issue #1 comic online in high quality
4 pages
Section 56-D of The Conduct of Election Rules Allows Scrutiny of VVPAT Slips in Case of Disputes
No ratings yet
Section 56-D of The Conduct of Election Rules Allows Scrutiny of VVPAT Slips in Case of Disputes
1 page
2023 AI For SME Schonberger
No ratings yet
2023 AI For SME Schonberger
25 pages
NetScaler 10.5 AAA Application Traffic
No ratings yet
NetScaler 10.5 AAA Application Traffic
182 pages
Kootenay Lake Pennywise May 6, 2014
No ratings yet
Kootenay Lake Pennywise May 6, 2014
56 pages
Unilab History
100% (7)
Unilab History
2 pages
Zenex AR 23-24 - Non Stat Revised 231024 - 10 Comments
No ratings yet
Zenex AR 23-24 - Non Stat Revised 231024 - 10 Comments
48 pages
Lady of All Nations - Amsterdam Apparition Album
No ratings yet
Lady of All Nations - Amsterdam Apparition Album
40 pages
Region 02: The Learner Produces A Detailed Abstract of Information Gathered From The Various Academic Texts Read
No ratings yet
Region 02: The Learner Produces A Detailed Abstract of Information Gathered From The Various Academic Texts Read
5 pages
Religious Responses To Globalisation: Hatib A. Kadir & Maufur
No ratings yet
Religious Responses To Globalisation: Hatib A. Kadir & Maufur
18 pages
Gear Lubrication FZG Wind Turbines
No ratings yet
Gear Lubrication FZG Wind Turbines
9 pages