Systèmes

ferroviaires communiquant et
hétérogènes : impact sur la sécurité et la
cer9fica9on

14:40-15:30 : Jean-Louis Boulanger
CERTIFER
 Thème de la journée
•  Les systèmes embarqués occupent une place importante dans les moyens
de transport. Ceci s’explique par le fait qu’aujourd’hui, plus de 90% des
innova9ons dans le secteur des transports, rou9ers comme l’automobile,
aéronau9ques ou ferroviaires, sont dues directement ou indirectement
aux avancées technologiques dans les domaines de l’informa9que et de
l’électronique embarquées. Les systèmes embarqués, dans les moyens de
transport modernes, deviennent de plus en plus complexes et ils
con9ennent, dans certaines plates-formes, plusieurs dizaines de
processeurs.
•  CePe complexité répond aux besoins des constructeurs, pour offrir des
fonc9onnalités de plus en plus avancées comme l’aide à la conduite, la
communica9on véhicule-à-véhicule ou la conduite automa9que.
Grâce aux progrès technologiques, les performances (vitesse d’exécu9on)
ne sont plus de nos jours la seule figure de mérite.
Les ou9ls de concep9on des systèmes embarqués doivent maintenant
prendre en compte aussi la fiabilité, la dissipa9on thermique, la
cer9fica9on et la vérifica9on du logiciel exécuté.
 CERTIFER
q  Evalua&on de la sécurité et de la conformité dans le domaine du
ferroviaire

q  Accrédita/on COFRAC INSPECTION « 17020 » et CERTIFICATION

« 45011 »
q  Nombreuses reconnaissances na&onales et interna&onales

q  Plus de 17 années d’expérience
q  Plus de 350 experts sur l’ensemble des secteurs ferroviaires provenant
de : SNCF, RFF, RATP, Apave et Industriels, etc.…

 www.CERTIFER.eu
q  Couvre tous les secteurs :
v  Grande vitesse,
v  Conven9onnel,
v  Fret et
v  Urbain
q  Couvre tous les domaines :
v  Infrastructure,
v  Energie,
v  Contrôle-commande et signalisa9on,
v  Matériel roulant,
v  Système, maintenance, exploita9on

Ø  La référence pour vos missions ISA/NOBO/DEBO/
CSM

 Sommaire
•  Système ferroviaire
•  Organisa9on des normes
•  Cycle de Vie de la sécurité
•  Logiciel
•  CENELEC EN50128
•  Conclusion
•  Ques9on
Système ferroviaire
Système ferroviaire
 Changements
1er changement Train a conduite manuelle

Train a conduite automa9que

Retrait des équipements à la voie

2ème changement Monitoring

Récupéra9on d’informa9on
Maintenance distante
…
 Communica9on entre système
Point sur les communica9ons inter-système
•  Communica9on au sein du train
•  Échange d’informa9on au sein d’une voiture;
•  Échange d’informa9on au sein d’une unité ;
•  Échange d’informa9on au sein d’unité mul9ple:
•  Accouplement/désaccouplement
•  Phase d’inaugura9on
•  …
•  Mise en place de réseau passager (Wifi, GSM, ...).
•  Communica9on sol – train
•  Mise en place de balise ;
•  Système de détec9on des trains ;
•  Système ERTMS
•  U9lisa9on de communica9on de type GSM-R
•  Communica9on au sein du système ferroviaire
•  Informa9on passager
•  Échange entre opérateur
•  …
Évolu9on du réseau global

!
 !"#$%&'(#)*+(#&,-./0,.*/$&121.#0&!"#$
%&'("(#)'#*+',*#-+'(.+-)'#&$#.3/45&.#67$/(/82
D.7#4$#.&.4,*$&+,65+/$#&NPPP&B@*.A1

D.7#4$#.&6/$1*1.&$#.3/45&NPP&B@*.A1 <L!OHFD?

+3,$124'() +0($12/'() ";8$1&/'( !"#$1&/'()

IN IN IN IN IN IN IN IN IN IN 2& +,'
IN IN 2& 2& +,' IN IN 2& 2& 2& 2& IN +, J;

,G ,G ,G ,G ,G ,G ,G ,G ,G ,G A2 +," A6L>=*>6 A6L>=*>6

AJS&

$%2C
,G ,G

$%&'
$%&"
A2 +,"

$G+
G&'

$G+
2,'
G&"
G&M
!3 !9 ! .
!: !'. !' !" !# !7 !1 !8 !3 !9 A,/ "#$%&%'() "#$%&%'() G0>C?..0!+HE00!
!' !" A%/ A2J ,G ,G A2 A2 A2 A2 ,G ,C+A 2;

/' 2
MG I-!0

<"=*#>,!?@3A#B
'-& MG
F)
/0 '&& 0&&

!"#$%&"
* /
$JJK $JJK

'(
"#$%&%'() "#$%&%'()
2FEE>
2,"#" A6L>=*>6 A6L>=*>6 /. -& !" .&&
2,"#" A6L>=*>6
!'# !1 !8
A6L>=*>6(OBK$P
%JK %JK
;<.< !1 !"
!'. & 1&&

./0"#1"/
/1

9!:,';
2E0/

'2
0 JK JK
+,- "#$%&%'()

/-
0

!"#$%&'()*
+,0(A%/ A6L>=*>6 A6L>=*>6 /5 !

3456,*7/,'8
()*+,-.+/-,,0/.0! A6L>=*>6

KGB&A&K<LG&A
$%&''
!'" !# !7 +,0(A%/
!'

!"#$%&'%()
$%&'1 23456758+(9:4926+295; !7

C!D,'E
$%&'1 ()*+</=+.><?,+!<.<
$%&'1 @<A.+B->+</=+.><?,+!<.<+B>-C+()*DDD $%&''
3?!0 '%

3+456#*7

>JEF
' 0 . 1 - 5 4 % 3 & ($ (2
A6L>=*>6(OBK$P
!: G4H>= A6L>=*>6 A6L>=*>6
G4H>=

345D,*7/,'D
H)@/)/3":

345D,%1,'6
!'' !' !"

;+$0"+<-
!#

)*+"#,'-
9!
GH
!*6$4.'()*

-5$*%# :$-E&/1
+# 89 89 @: A:,

"'1<''B
*7C#%2
*7C#%$
A/)/3":'-5$*%#

*A,

*A,
R(,*"+ QR>?24SO D/3()
*+ :3 :3 A3:

LGTUV
%()*+(&',)$*

*1;<='<1%$
$)*"+K/%"

A:,
(>

(K
9QH'U'SC8 9QH'(+'+"@(*"'2C>

*1;<='<1%2
;EFNN

A3:
(D
()
!6;$1&/'( !"#$1&/'() --($%&/'(5*/6 -7($%&&'(0 -8($%&4'(5 !"#$%&/'() --($%&/'(5*/6 -7($%&&'(0 -8($%&4'(5
A2 +, 2&

:6,E!B=F
2& 2& 2& 2& M .. .' ." .# .7 .1 .8 .3 +, 2& A2 +, 2& 2& +, 2& M .. .' ." .# .7 .1 .8 .3 +, 2& M .. .' ." .# .7 .1 .8 .3 +, 2&

@:.%H*",I
2& 2& 2& IN +, J; M .. .' ." .# .7 .1 .8 .3 +, 2&
K .. .' ." .# .7 .1 .8 .3 , A2 K N. N' N" N# M .9 .: '. '' '" '# '7 '1 +, A2 K .. .' ." .# .7 .1 .8 .3 , A2 K N. N' N" N# M .9 .: '. '' '" '# '7 '1 +, A2

(J
AJS&

$%2C
$%&'
$%&"
$%&'
$%&"
$%&#

$%&'
$G+

$G+
2,'

$G+
M .9 .: '. '' '" '# '7 '1 +,
K N7 N1 N8 N3 M '8 '3 '9 ': ". "' "" "# +, M .9 .: '. '' '" '# '7 '1 +,
K N7 N1 N8 N3 M '8 '3 '9 ': ". "' "" "# +,
A2 A2 A2 A2 A2 A2 A2 ,G ,C+A 2;
A2 I0 A2
K .9 .: '. '' '" '# '7 '1 , M "7 "1 "8 "3 "9 ": #. #' +, K .9 .: '. '' '" '# '7 '1 , M "7 "1 "8 "3 "9 ": #. #' +,

7 1 7 1
"# 83 "# 83
<"=*#>,!?@3A#B

2,"#" ,>=D)E>
F) N. N' M.. M'8 ' ' N. N' M.. M'8

,#
;(('.

,"
. 9 . 9
: B :

%<<=>??
!"#$%&"

'7 '7 M.' M'3 '. A

C$0% '7 '7 M.' M'3
'" ''
'(

7 1
'' '' "# 83 "# '' ''
M." M'9 ' ' M." M'9

,7

,'
. 9 ;((' .
'" '" : '" '" M.# M':
M.# M':

9QH'(+'+"@(*"'2C>

3/?<=%($
$%&#(456(!1

;EFNN
$%&#()*(!8

7 1
@:
MQK MQK M.7 M". "# 83 MQK MQK M.7 M".

0)6(=@6>

@:.%(2
N" N# ' N" N# G-

,1
. 9
./0"#1"/

.. .9 '7 '7 M.1 M"' '1 :

.. .9 '7 '7 M.1 M"'
9!:,';
'2

.' .: '' '' M.8 M"" .' .: '' '' M.8 M""

." '. '" '" M.3 M"# ." '. '" '" M.3 M"#

.# '' +,' +,# .# '' +,' +,#

N7 N1 N7 N1
.7 '" .-' .-# .7 '" .-' .-#
3456,*7/,'8

'7 '7 '7 '7

$%&"(456(!#

$%&"()*(!7

!"#$%&'%()

C!D,'E

.1 '# .1 '#

$%&'(456
'' ''

$%&'()*
'' '' M.9 M"7 M.9 M"7

!"

!#
.8 '7 '" '" .8 '7 '" '" M.: M"1
M.: M"1
.3 '1 .3 '1 3)9,262@I
M'. M"8 M'. M"8
N8 N3 N8 N3
+,' +," +,' +," M'' M"3
M'' M"3
'7 '7 '7 '7
.-' .-" .-' .-" M'" M"9
'' '' M'" M"9 '' ''

;EFM
'" '" M'# M": +,- '" '" M'# M":
345D,*7/,'D

345D,%1,'6
$%&'(456(!'

$%&'()*(!"

M'7 M#. M'7 M#.

+,

2,"#"
)*+"#,'-

G4H>=
" ! # $ % & ' ( " ! # $ % & ' (
M'1 M#' M'1 M#'

!'

!3
+, +, +, !
9! +, +,
+," +,7 +," +,7
.- .- .- .- .-
GH
.-" .-7 .-" .-7
.-

!"#$%&"'9()+(&'H)$*'G!9HI !"#$%&"'9()+(&'H)$*'G!9HI ;"%")*+/&$-":'%()*+(&',)$*

;EFN C#7*6(#&&+-1&;EF/"#$

;EFQ&&RNSMS

!"#$%&/'() !".$%&/'() !"#$%&&'()*+,- ,<:$1&/'( !"#$1&/'() --,$%&/'() 68($%&/'()*/4: -8($%&&'(9 --($%&/'(5*/6 -8($%&4'(5
2& +, 2& 2& A2 +, 2& +, 2& 2& % 0 %0 % 0 2& 2& +, 2& A2 2&
A!J 2& 2& 2& IN +, J;
! .. .' ." .# .7 .1 .8 .3 +, 2& M .. .' ." .# .7 .1 .8 .3 +, 2& M .. .' ." .# .7 .1 .8 .3 +, 2&

$%&'
K .. .' ." .# .7 .1 .8 .3 , A2 M .9 .: '. '' '" '# '7 '1 +, A2

J2/
2& A2 K& ,

/-0
$G+

2$-
A2
$%&'

AJS&

$%2C
$%&'
$%&"
J2/

/-0
$G+

2$-

$%&'
$G+

CC$
$G+
2,'
$%&(GI'
2& A2 K& , *+ ! .9 .: '. '' '" '# '7 '1 +, M .9 .: '. '' '" '# '7 '1 +, M '8 '3 '9 ': ". "' "" "# +,
"50
A2 I0 A2 A2 I0 A2 A2 A2 A2 A2 ,G ,C+A 2; A2 A2
$%&(GI"
K .9 .: '. '' '" '# '7 '1 , M "7 "1 "8 "3 "9 ": #. #' +, *+,$-.'()/
7 1 7 1 7 1 $C 7 1
"# 83 "# 83 "# 83 %0 AB "# 83 "#
7 1
2,"#" ,>=D)E>

83

2,"#" ,>=D)E>

0; 0;

+0 +0
!6;$/

<"=*#>,!?@3A#B
' ' ' : ' '

/4<>
F) M.. M'8
,#

,"

,#

9 ;(('.

,9

,"
. 9 ;(('. . 9 . 9 . . 9

,#
. 9 ;(('. !6;$4

!"0 0#; <!!

,6 ,( ,9 #3 ;3
5, 5( 59 )9 :(
: B : : 3 ' B :
%<<=>??
%<<=>??

%<<=>??

#4 #/ #2
8 A
A
C$0% 1 7 # " C$0%

!"#$%&"
'. '. '.
'" '' '" '' '" '' M.' M'3
7 1 $C M.$ M'$
"#
7 1 "# %0 "# "#
7 1

'(
83 "# 83 AB 83
' ' ' : ' ' M." M'9

,3
. ;F
,7

,'
. 9 ;((' 9 .

,7
9
,7

,'

. 9 ;((' . . ;((' M.R M'R

: 3 ' ! " #

%<<=>??
: :

!6;$/$?@A
8
1 7 # "

!6;$/$=>
$%&(/K&"

M.# M':

5(:$64

5(:$6/
M.- M'-
$%&(GI"

"#
7 1
%0
$C 7 1 !
"#
7 1
83 83 AB "# 83
0)6(=@6>

0)6(=@6>
0)6(=@6>

M.7 M".
!7

!1

' ' : ' MQK MQK

,8
,1

. 9 9 . F;

,1
. 9 "
,1

. 9
: '1 : 3 ' '1 :

./0"#1"/
'1 ,7-+
8
1 7 # " .. .9 M.1 M"'
# 3(:*6#(*6!(

9!:,';
'2
M"$ M#$
.' .: M.8 M""
M"R M#R $
." '. M.3 M"# )50
3B 3B
M"- M#- %&
!"0
.# '' +,' +,#
%!
.7 '" .-' .-#

3456,*7/,'8

8*7
%"
$%&(/K&'

!"#$%&'%()
$%&(GI'

$%&'(456

$%&'(456
M7$ M1$
$%&'()*

$%&'()*
C!D,'E
$%&'(456

.1 '#
$%&'()*

M.9 M"7

!6;$4$?@A
%#
!"

!#

!6;$4$=>
!"

!#

!"

!#

5(:$:4

5(:$:/
M7R M1R
!"

!#

30<
.8 '7

<#
%$ M.: M"1
M7- M1-
.3 '1 M'. M"8
!&
,-.%&' ,-.%/01 +,' +," M'' M"3
($ (2 !!
M8$ M3$

0;
.-' .-"

+0
!::
!" M'" M"9
!:,
+,- &$ M8R M3R
+,- !# M'# M":

345D,*7/,'D
/-0(456((!7

345D,%1,'6
M8- M3-
/-0()*((!1

+, +,
2,"#"((!3

+, M'7 M#.
!$
G4H>=

G4H>=
!'

!'
2,"#"
G4H>=

+, +,

)*+"#,'-
M'1 M#'
!'

!3

+, +, '&
G4H>=

9!
!'

.- .-
.- .- +," +,7
'!
.- GH .-

T/*"5/1
.- .-" .-7

T/*"5/1 9QH'C'T/*"5/1 !"#$%&"'9()+(& A!F'$)*"+K/%" 984'C'DOF

984BQ(5"+&$)" .84'C'A!F H)$*'G!9HI

?4,*$&+-1&;EF:</3#4(*$# BC@ ?4,*$&+-1&>?@

!"#$%#&#'()*+,$-.%$/0&(120+'(1*+3&$30(*/3(1*+
454(#/$1+$'*+()*&$366&1'3(1*+4$2*)7
! !"#$%&"'%()*+(&',)$*- ! ./0/*(+1
! 2)/,3,+/*$() ! .$3#*$)3
! 4"*5(+6'*"%#)(&(3$"- ! 7!89
! >,*"+'/):'$))"+':((+- ! ?/,&*'@"--/3"-
! D#""&'-&$:"'E+(*"%*$() ! F/**"+1'@/)/3"@")*
! !"#$%&"':$/3)(-*$% ! ;+$0"+<-'%/=
! A(*(+B'C'3"/+',)$* ! D$+"&"--'%(@@,)$%/*$()
 Que de logiciel
•  Ini9alement : la sécurité reposait sur la
signalisa9on

•  Maintenant : le train dispose

–  de plusieurs réseaux et
–  de nombreux équipements qui comportent du
logiciel
Contexte norma9f
 Organisa9on des normes
Système Complet
50126

Sous-système Signalisa9on Train

50129
50159
Equipement Equipement

Hardware Logiciel Hardware Logiciel

50128 50155
 Cadre
•  Les normes fournissent un cadre
•  Ce cadre est un point de vue de l’état de l’art
•  Une technique ou une approche non présente
dans la norme ne signifie pas son rejet

•  Mais la norme reste la référence, un objec9f à

aPeindre, etc.
 Innova9on et normes
•  Au sein des normes, il n’y a aucun élément
explicite lié à l’innova9on.
Pourquoi l’innova9on ?
 Principe de sécurité
•  Un système/sous-système/équipement/
hardware/logiciel doit être capable de réaliser
les fonc9ons en sécurité.
•  Pour ce faire, des principes de sécurité
doivent être
–  Iden9fiés;
–  Mis en œuvre;
–  Et démontrer leurs efficacités.
 Innova9on
•  L’innova9on doit répondre à un besoin et pour
les aspects sécuritaires, doit être associée à un ou
plusieurs principes de sécurité.

•  Concernant le besoin :
–  Aspect financier (solu9on moins onéreuse, etc.)
–  Aspect délais (gain sur les délais de dev/..)
–  Aspect charge (gain sur les ac9vités, …)
–  Aspect efficacité
–  …
–  Aspect démonstra9on sécurité
 Exemple
•  Soit un système ferroviaire X, la taille du
logiciel est en général de 400 000 lignes
–  Il a été choisi de le développer en C++
–  Impact
•  Environ 1 000 000 de lignes de code C++
–  60% du code concernent des classes abstraites ou d’interfaces
–  40% représentent le code exécutable
•  Difficulté à tester le C++
•  Difficulté à relire l’ensemble du code
Cycle de vie de la sécurité
 Cycle de vie
Concept -1 Modification/mise à niveau -12

Définition du système et conditions Acceptation du Exploitation et Retrait du service

d’application -2 système - 10 Maintenance et dépose -14
-11

Analyse du risque -3 Surveillance des perfos -13

Exigence du système-4
Validation du système -9

Allocation des exigences

du système -5

Conception et Réalisation -6 Installation -8

(nécessité de reprendre le cycle)

Fabrication -7
 Safety Assurance Plan

1
Concept

2 11 14
System Definition & 10
Operation and De-commissioning
System Acceptance
Application Conditions Maintenance and Disposal

PHA
3

Safety-Case
Risk Analysis

SHA System Requirements

4
9
IHA System Validation
(Including Safety Acceptance
and Commissioning)

5
Apportionment of
System Requirements

6 8
Sta9c analysis Design and
Implementation Installation
(hardware,
souware, …)

7
Safety review Manufacture

Hazard-Log

Hazard-Log
 Besoins
•  Démonstra9on de la sécurité du produit
–  Cer9ficat des composants
•  Fiabilité et Disponibilité
•  Maitrise de la sécurité jusqu’au retrait
–  Capacité à maitriser les évolu9ons après la mise
en service et jusqu’au retrait
–  Capacité à déployer de nouvelles versions
•  Maitrise de l’obsolescence
–  Au moins 40 années d’exploita9on
 Démonstra9on de la sécurité du
produit (1/3)
•  Pour un produit nouveau :
•  Cer9ficat de produit
•  Retour d’expérience documenté
•  Valida9on du produit

•  Le guide CENELEC 50129 – par9e 1 fixe le cadre de la

« cross-acceptance »

•  Difficulté :
•  DAL est différent de SIL et SSIL
•  ASIL est différent de SIL et SSIL
•  SIL (61508) est différent de SIL(CENELEC)
 Démonstra9on de la sécurité du
produit (2/3)
•  Pour la démonstra9on de sécurité, il est
nécessaire de démontrer la compétence des
personnes :
•  Besoin de définir une méthodologie;
–  Guide
–  Instruc9on
–  Etc.
•  Besoin de forma9on;
•  Etc.
 Démonstra9on de la sécurité du
produit (3/3)
•  Pour la démonstra9on de sécurité, il est nécessaire de
démontrer que les exigences sont prises en comptes:
•  Besoin de testabilité ;
•  Besoin de rejeu des ac9vités;
•  Besoin de définir une méthodologie;
•  Etc.

•  Il est nécessaire d’avoir une évalua9on indépendante

Besoin de disposer d’éléments auditables;
•  Nécessité de former les évaluateurs et de donner accès à la
technologie.
 Fiabilité et Disponibilité
•  Pour un produit nouveau :
•  Des éléments liés à la fiabilité
–  MTBF, MTTR, …
•  Des éléments liés à la disponibilité

–  Probléma9que du retour d’expérience

•  Disposer d’informa9ons (nom projet, taille, niveau de
sécurité, etc.);
•  Disposer de chiffres (temps d’u9lisa9on, …);
•  Disposer d’une liste des défauts connus;
•  Etc.
 Maitrise de la sécurité jusqu’au
retrait
•  Capacité à maitriser les évolu9ons après la mise
en service et ceci jusqu’au retrait
•  Remise en œuvre du processus de réalisa9on;
•  Maitrise des évolu9ons;
•  Maitrise des moyens d’exécu9on (mémoire, cycle, etc.);
•  Etc.
•  Capacité à déployer de nouvelles versions
•  Nouvelle version de l’équipement
•  Nouvelle version des OS/firmware
•  Nouvelle version des logiciels
•  Etc.
 Maitrise de l’obsolescence
•  Ges9on de l’obsolescence
•  Hardware;
•  Logiciels;
•  Ou9ls et OS;
•  Etc.
 Accepta9on du risque
•  Le référen9el CENELEC introduit 3 approches
d’accepta9on du risque : ALARP, GAME et
MEM
•  En France, il est recommandé d’u9liser le
GAME
=> Le GAME peut sembler un frein à l’innova9on
… logiciel
 Que du logiciel
•  Une des difficultés : les innova9ons impliquent,
en général, la mise en œuvre de logiciel:
–  Environnement de développement
–  Système d’exploita9on
–  Bibliothèques
–  Compilateur
–  Générateur de code
–  Logiciels spécifiques
–  Etc.
CENELEC 50128
 50128:2001
•  Dans le cadre de la CENELEC 50128:2001, les
tableaux A.x contenaient des éléments
nommés comme par exemple
 50128:2011
2296
- 75 -

Table A.15 + Textual Programming Languages

FprEN 50128:2011

TECHNIQUE/MEASURE Ref SIL 0 SIL 1 SIL 2 SIL 3 SIL 4

1. ADA D.54 R HR HR HR HR

•  Retrait du nom des 2. MODULA-2

3. PASCAL
D.54
D.54
R
R
HR
HR
HR
HR
HR
HR
HR
HR

méthodes 4. C or C++ D.54

D.35
R R R R R

5. PL/M D.54 R R R NR NR
•  Ajout de la capacité 6. BASIC D.54 R NR NR NR NR

d’u9liser d’autres
7. Assembler D.54 R R R R R
8. C# D.54 R R R R R
D.35

langages 9. JAVA D.54

D.35
R R R R R

10. Statement List D.54 R R R R R

Requirements:
1) The selection of the languages shall be based on the requirements given in 6.7 and 7.3.
2) There is no requirement to justify decisions taken to exclude specific programming languages.
NOTE 1 For information on assessing the suitability of a programming language see entry in Clause D.54 ^Suitable Programming
Languages_,

NOTE 2 If a specific language is not in the table, it is not automatically excluded. It should, however, conform to Clause D.54.

NOTE 3 Run-time systems associated with selected languages which are necessary to run application programs still have to be
justified for usage according to the Software Safety Integrity Level.

2297

2298 Table A.16 + Diagrammatic Languages for Application Algorithms

 50128:2011
EN#50128#

SSIL Clauses#4#

Organisation Clauses#5# Annex#B# Role

Application Data

Clauses#8#

Clauses#6# Clauses#9#

Clauses#7#
Software Assurance Maintenance
Deployment
Generic software

Annex#A# Annex#D#
Technics Bibliography of technics
37
 Innova9ons possibles
•  Évolu9on méthodologique
–  Modélisa9on
–  Vérifica9on sta9que
–  Etc.
•  U9lisa9on d’ou9ls
•  Environnement d’exécu9on
–  Machine virtuelle
–  Couche logicielle
•  Par99onnement
•  Virtualisa9on
•  Etc.
 Évolu9ons méthodologiques
•  Démontrer la prise en compte de la CENELEC
50128
•  Ou une efficacité similaire
–  Jus9fica9on
–  Demande d’accepta9on de la jus9fica9on par
l’évaluateur
 U9lisa9ons d’ou9ls
•  Jus9fica9on de l’u9lisa9on par rapport au processus de la 50128
•  Qualifica9on des ou9ls
–  3 classes T1,T2,T3
1) tools and Tx selec5on
[ 6.7.4.1 AND 6.7.4.2 AND 6.7.4.3 ]
AND
2) Tools specifica5on and valida5on
[(6.7.4.4 AND 6.7.4.5) OR 6.7.4.6]
AND
3) Design methodology jus5fica5on
[6.7.4.7 OR 6.7.4.8]
AND
4) Code genera5on
(6.7.4.9)
AND

5) configura5on management and new version
[ 6.7.4.10 AND 6.7.4.11]
AND
6) effort for Tx
(6.7.4.12)
 Environnement d’exécu9on
•  Concernant les machines virtuelles, les systèmes
d’exploita9on, la virtualisa9on, etc.
–  Il convient de faire très aPen9on car il est difficile de
démontrer que la norme a été appliquée pour les
développer

•  Concernant les couches logicielles ou

bibliothèques,
–  La nouvelle 50128 introduit la no9on de composants
réu9lisés en place des COTS
Communica9on
Gray channel
Réseau ouvert
•  Au final, les erreurs de base concernant les messages se limitent à :
–  la répétition : un message existant est resoumis à un moment inapproprié.
–  la suppression : un message est détruit (par exemple une demande de freinage d’urgence)
–  l’insertion : un message est inséré dans le flux existant
–  le séquencement : la séquence des messages est modifiée (retard sur un message par exemple)
–  la corruption : un message est modifié en un autre message correct
–  le retard : le système de transmission est surchargé
–  la mascarade : un intrus se fait passer pour un des interlocuteurs.

•   
•  Sur cette base, la norme CENELEC 50159 propose une approche pour traiter et
démontrer la sécurité des communications. Une des caractéristiques au final des
applications ferroviaires est que la sécurité est réalisée par les applications (et non
par le réseau) et qu’en cas de défaillances le système va atteindre un état de sécurité
prédéfini (en général de manière passive).
•   
•  Les réseaux (fermés ou ouverts) sont construits sur des médias de communication
qui sont maitrisés et dont les accès sont limités.
 Politique
•  La mise en place d’un réseau distant doit se faire en
définissant une politique qui doit prendre en compte
différents sujets :
–  La définition des missions du réseau distant (type d’accès, etc.) ;
–  La définition des objectifs (accès à tout moment à chaque équipement,
etc.) ;
–  La définition du réseau (choix des éléments, etc.) ;
–  Le processus d’installation (procédure, etc.) ;
–  Le processus de gestion ;
–  La gestion des modes dégradés (perte d’une partie du réseau, etc.) ;
–  La gestion des rôles ;
–  La politique de sécurité au sens « security » ;
–  etc.
Réseau ouvert 

+

accès distant
 Point faible 50159
•  Il apparaît au travers de ces nouveaux usages
(utilisation de réseau WiFi par exemple) que la
norme CENELEC 50159 n’est pas suffisante car
elle ne traite
–  ni de la gestion des COTS ;
–  ni des protections contre les attaques externes ;
–  ni des protections physiques contre l’intrusion dans
les locaux ;
–  etc.
Accès distant
•  Du point de vue de la « security », il va falloir être capable
–  d’identifier et de contrôler l’ensemble des accès ;
–  d’identifier et de contrôler les flots de données sécuritaires et/ou prioritaires ;
–  de garantir les objectifs de qualité de service (QoS), de disponibilité et de
fiabilité ;
–  …

•  Du point de vue de la FDMS classique, il va falloir (liste partielle)

–  analyser les impacts sur la « safety » des nouvelles menaces comme
•  les virus : que se passe-t-il si un virus se charge sur un calculateur de sécurité ? même s’il ne peut avoir
d’impact, il peut entrainer une consommation de temps, de place, …
•  les surcharges du réseau : le retard et/ou la perte de message pourrait entrainer des indisponibilités ;
•  …

–  analyser les impacts des problèmes réseaux sur la disponibilité du(des)

système(s) ;
–  …
•  Les équipements liés au réseau distant
doivent être hébergés dans des locaux
spécifiques qui sont à la limite du système
ferroviaire (voire à l’extérieur) et qui
peuvent être sujets à des intrusions
physiques (la personne mal intentionnée
cherchant un moyen de se connecter
physiquement).
•  Concernant la politique de sécurité, il faut
maintenant prendre en compte tous les types
d’intrusions (physiques ou pas). Mais il est aussi
nécessaire de bien analyser les usages qui sont
prévus et d’identifier les nouvelles menaces qui
pourraient apparaître. Si un PC de supervision
est installé sur le réseau et qu’il dispose d’un
accès au net permettant de surfer sur le web, il y
a de fortes chances qu’un malware soit chargé
et qu’il passe d’un réseau à l’autre.
Conclusion
 Innova9on
•  Elle est nécessaire pour offrir un meilleur
service, des nouvelles fonc9onnalités ou pour
gagner en compé99vité
•  Elle doit rendre un service (ne peut pas être
qu’un moyen de se démarquer)
•  Elle doit être maitrisée (connaissance des
impacts et des gains)
•  Elle doit s’inscrire dans un produit et dans une
approche de sécurité
 Pour conclure
•  Une politique « security » nécessite de définir un
cycle de vie et un objectif à atteindre (du type du
SIL).
•  On parle de SL
•  La norme 27005 présente une politique de
« security » très générale qui reste a préciser.
•  La norme IEC 62443 concernant la « security »
dans le monde des automates est un bon point
de commencement
 Pour finir
•  L’innova9on ne doit pas chercher à simplifier
l’applica9on des normes mais elle doit
simplifier la conformité aux normes.
Ques9on ?
 !

! ! ! !

!
!