Définition et optimisation de Fonctions Instrumentées

de Sécurité par une approche Model-Based Safety

Assessment (MBSA)
Frédéric Milcent

To cite this version:

Frédéric Milcent. Définition et optimisation de Fonctions Instrumentées de Sécurité par une approche
Model-Based Safety Assessment (MBSA). Congrès Lambda Mu 23 “ Innovations et maîtrise des risques
pour un avenir durable ” - 23e Congrès de Maîtrise des Risques et de Sûreté de Fonctionnement, Institut
pour la Maîtrise des Risques, Oct 2022, Paris Saclay, France. �hal-03878478�

HAL Id: hal-03878478

https://hal.science/hal-03878478
Submitted on 29 Nov 2022

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
 Définition et optimisation de Fonctions
Instrumentées de Sécurité par une approche Model-
Based Safety Assessment (MBSA)
Using Model-Based Safety Assessment (MBSA) to
define and optimize Safety Integrated Functions
MILCENT Frédéric
Naval Group / Equipements Navals
CS 81 030
16600 RUELLE SUR TOUVRE
frederic.milcent@naval-group.com

Résumé — Au même titre que l’évaluation des performances de I. OBJECTIF / CONTEXTE

Sûreté de Fonctionnement des systèmes complexes, l’emploi d’une
approche MBSA (Model-Based Safety Assessment) peut permettre
de vérifier de façon exhaustive que les Fonctions Instrumentées de
Sécurité répondent, de façon nécessaire et suffisante, au besoin.
Une expérimentation a été menée sur le cas d’application d’une
installation d’embarquement / débarquement d’armes tactiques. Un
modèle a donc été réalisé dans le but de vérifier qualitativement la
couverture des Fonctions Instrumentées de Sécurité et grâce au
logiciel Simfianeo basé sur le langage AltaRica DataFlow.
L'analyse MBSA a permis de mettre en évidence les éventuelles
failles au niveau des Fonctions Instrumentées de Sécurité et de
vérifier l'absence de situations de blocage mais également
d'optimiser celles-ci en ne conservant que les informations
nécessaires et suffisantes.
Mots-clefs — Model-Based Safety Assessment, AltaRica,
Sécurité Fonctionnelle, Fonctions Instrumentées de sécurité,
Simulation pas-à-pas, Séquences
Abstract— MBSA approach make possible to assess Safety and
Reliability performances of complex systems. It can also help to
make an exhaustive analysis of the system to define necessary and
sufficient Safety Integrated Functions.
An application to a Weapon Embarking / disembarking System
(WES) was made to illustrate this methodology. A model has been
realized for a qualitative verification of the Safety Integrated
Functions covering with Simfianeo software based on the Altarica
Data Flow language.
The results of the application case show that MBSA approach
can be used to identify eventual leaks in the Safety Integrated
Functions and to optimize them to satisfy needs with the less
necessary information.
Keywords — Model-Based Safety Assessment, AltaRica,
Functional Safety, Safety Instrumented Functions, Step-by-step
simulation, Sequences
Définir des Fonctions Instrumentées de Sécurité peut
parfois s’avérer complexe. En effet, il convient de s’assurer
d’avoir traité toutes les configurations fonctionnelles
possibles et d’évaluer l’efficacité de ces fonctions en toutes
circonstances. Il faut également vérifier que la mise en place
de ces fonctions ne remet pas en cause le fonctionnement en
aboutissant à des situations de blocage. Suivant le
séquencement des opérations, certaines conditions peuvent
avoir déjà été validées par une autre fonction rendant
également possibles des optimisations au niveau des capteurs
et de la logique.
Au même titre que l’évaluation des performances de
sécurité des systèmes complexes, l’emploi d’un modèle, très
tôt dans le développement, peut permettre de vérifier, de façon
déterministe, que les Fonctions Instrumentées de Sécurité
répondent, de manière à la fois nécessaire et suffisante, au
besoin.
Ce type d’approche (ainsi que les logiciels les supportant)
dispose de nombreux avantages et permet de bénéficier
notamment :
• Du langage Altarica (Data flow) [2] avec son système
de transitions gardées permettant de gérer
l’interdépendance entre les états fonctionnels /
dysfonctionnels, les contraintes physiques /
sécuritaires…
• Des moteurs de calcul du logiciel permettant de
garantir l’exhaustivité de l’analyse en prenant en
compte tous les scénarios possibles et pas seulement
ceux que l’Ingénieur en Sûreté de Fonctionnement peut

Congrès Lambda Mu 23 10 au 13 octobre 2022, EDF Lab Paris Saclay

 imaginer (en réalisant des arbres de défaillances par
exemple).
• D’une interface graphique permettant de faciliter le
dialogue avec les concepteurs (dialogue qui peut
s’avérer difficile autour d’arbres de défaillances et
encore plus autour de réseaux de Petri).
II. MÉTHODOLOGIE
A. Cas d’application
L’approche MBSA pour la définition des Fonctions
Instrumentées de Sécurité a été appliquée sur plusieurs
équipements développés par Naval Group dont un, assez
simple, qui va servir d’illustration pour cet article.
Il s’agit d’une installation permettant d’embarquer et de
débarquer des armes tactiques à bord d’un sous-marin (voir
Figure 1).
La prolonge est mise en place à l’aide du chariot, celle-ci
permet d’assurer la continuité de guidage de l’arme entre la
Butée
Rampe
Prolonge
Figure 1 : Installation d’embarquement / débarquement des armes tactiques
Plusieurs événements redoutés sont identifiés sur cette
installation.
Le principal événement redouté correspond à la perte de
maintien de l’arme lors d’une phase où elle se trouve sur un
plan incliné ce qui occasionne sa chute par glissement (angle
d’inclinaison suffisamment important pour que le poids
propre de l’arme entraîne son glissement).
Le retour en position horizontale de la plateforme avec une
arme engagée dans le sas ainsi que la poussée de l’arme sur
plateforme au-delà de son centre de gravité sont également
redoutés.
Il est primordial que les événements redoutés soient tous
identifiés pour ensuite être intégrés au modèle car le moteur
de calcul ne permettra de détecter que les séquences générant
les situations redoutées indiquées par le modélisateur.Modèle
Congrès Lambda Mu 23
plateforme inclinable, située à l’extérieur, et la rampe de la
manutention intérieure.
Lors d’un embarquement, l’arme est déposée sur la
plateforme, le chariot est alors déplacé pour être verrouillé sur
l’arme, la plateforme est ensuite inclinée dans l’alignement de
la prolonge et l’arme est déplacée (après effacement de la
butée) à l’aide du chariot jusqu’à la rampe de la manutention
intérieure (préalablement inclinée et verrouillée).
L’arme est ensuite stockée à l’intérieur du sous-marin et le
chariot retourne à sa position initiale. Pour un débarquement,
les opérations sont réalisées dans l’ordre inverse.
Trois actionneurs sont présents pour réaliser les
mouvements suivants :
• Avancée / recul du chariot,
• Verrouillage / déverrouillage du chariot,
• Inclinaison de la plateforme.
Arme Chariot
Plateforme inclinable
©Naval Group, 2022, All rights reserved.
Un modèle a été réalisé pour vérifier que les premières
bases définies pour les Fonctions Instrumentées de Sécurité
permettait d’assurer une couverture complète vis-à-vis des
commandes intempestives (manuelles ou fonctionnelles).
Celui-ci a été construit grâce au logiciel SimfiaNeo[1]
développé par la société AIRBUS Protect. Ce logiciel utilise
le langage AltaRica DataFlow qui est particulièrement adapté
au traitement des systèmes complexes.
Les différents éléments graphiques ont été superposés afin
de proposer une vision synthétique permettant de suivre
facilement l’évolution du système lors d’une simulation pas-
à-pas et d’améliorer le dialogue avec les concepteurs de
l’installation. La représentation graphique obtenue (Figure 2)
est équivalente à celle issue des documents d’entrée (Figure
1).
10 au 13 octobre 2022, EDF Lab Paris Saclay
 Figure 2 : Représentation graphique du modèle (niveau de tête)
Un bloc Logic (voir contenu en Figure 3) est créé afin de
gérer les opérations et le contrôle commande.
Figure 3 : Contenu du bloc « Logic »
Pour chaque actionneur, un bloc virtuel correspondant aux
conditions d'autorisation d'utilisation de l'actionneur (bloc
sans comportement avec seulement des entrées / sorties –
blocs en bleu sur la Figure 3) a été créé pour représenter la
partie logique des Fonctions Instrumentées de Sécurité. La
logique initiale est basée sur une première ébauche définie en
groupe de travail (voir exemple en Figure 4 présentant la
logique initiale de la Fonction Instrumentées de Sécurité
relative au mouvement d’inclinaison de la plateforme).
No module
Trolley at
on WES
Home
platform
Trolley
locked
Figure 4 : Logique de la fonction de Sécurité sur l’inclinaison de la
plateforme – version initiale
La Figure 5 présente le bloc virtuel tilting_author
correspondant à cette fonction de sécurité. Ce bloc dispose de
3 entrées donnant les informations suivantes : chariot en
position rentré (i_trolley_at_home), arme sur plateforme
extérieure (i_weapon_presence_WES) et chariot verrouillé
(i_trolley_locked). Ces informations sont synthétisées dans
une assertion de type case {… else …} pour statuer sur
l’autorisation du mouvement en affectant une valeur vraie ou
fausse la sortie booléenne du bloc (o_tilt_authorised).
Congrès Lambda Mu 23
i_weapon_presence_WES
i_trolley_at_home
i_trolley_locked
case {
i_trolley_at_home and ~i_weapon_presence_WES : true,
i_trolley_at_home and i_trolley_locked : true,
else
false
}
o_tilt_authorised
Figure 5 : Bloc virtuel “tilting_author”– version initiale
Le bloc positions (en blanc sur la Figure 3) permet de gérer
les états correspondant aux positions du chariot
(trolley_position), de l’arme (weapon_position), de la
prolonge de sas (ext_position) et du verrouillage du chariot
(trolley_locked).
La plupart des opérations de l’installation (commandes
manuelles et fonctionnelles) ont été modélisées sous forme de
transitions (30 au total).
La Figure 6 présente le menu dans lequel est renseigné le
comportement du bloc avec, à gauche, les variables d’états et
les transitions et, à droite, la garde et les effets de la transition
sélectionnée (weapon_WES_to_WES_home).
Les contraintes physiques ont été intégrées dans les
conditions requises au niveau de la garde. Par exemple, pour
remonter l’arme, il est nécessaire que le chariot et l’arme
soient à la même position et que les verrous du chariot soit
sortis pour que le mouvement de recul du chariot soit transmis
à l’arme.
Lorsqu'une opération requiert l'emploi d'un actionneur, sa
transition intègre cette autorisation booléenne dans sa garde
(sur la Figure 6 par ex., l’autorisation de mouvement du
chariot i_trolley_mvt_authorised est présente dans la garde de
la transition weapon_WES_to_WES_home représentant le
déplacement de l’arme de la position milieu de plateforme à
la position intermédiaire avec la position home).
10 au 13 octobre 2022, EDF Lab Paris Saclay

Figure 6 : Comportement du bloc « position »
Le renseignement d’une loi pour les transitions dans
Simfianeo est obligatoire. Le but étant de réaliser une analyse
qualitative, la loi utilisée pour toutes les transitions est une loi
exponentielle avec un taux de défaillance  égal à 1 h-1. Cette
valeur très élevée permet de garantir une forte probabilité de
weapon_WES_home_to_home
tirage des transitions lors des simulations. Cela évite d’avoir à
fixer un nombre important d’histoires et permet de limiter le
temps de calcul.
Une des principales difficultés de ce modèle résidait dans
la gestion du déplacement du chariot car selon la position de
l’arme ou de la prolonge et du verrouillage du chariot, celui-
ci se déplace à vide ou déplace l’arme ou la prolonge.
Il a donc été décidé de créer 3 variables d’états partageant
le même domaine de valeurs pour la position du chariot, de
l’arme et de la prolonge.
Les changements d’états de la position du chariot sont
coordonnés avec les transitions liées au changement de
position de l’arme ou de la prolonge. Par exemple, sur la
Figure 6, il y a deux effets sur la transition
weapon_WES_to_WES_home mettant en évidence la
coordination entre changement de position du chariot et de
l’arme (weapon_position et trolley_position doivent toutes
les deux être égales à WES pour que la transition soit possible
et ces positions prennent toutes les deux la valeur WES_home
à l’issue de la transition).
Chaque position principale (permettant souvent
l’acquisition d’une information de position par un capteur)
est représentée par un état ainsi que chaque position
intermédiaire (entre deux positions principales).
Le but de ces positions intermédiaires est de pouvoir
intégrer à l’analyse les séquences correspondant à la perte
d’une information de position sans encore avoir acquis la
position suivante.
La Figure 7 présente les différents états et transitions liés
à la position de l’arme.

home WES_home

weapon_home_to_WES_home

weapon_WES_home_to_WES

weapon_WES_to_WES_home

Initial state
(Default)
weapon_none_to_WHS weapon_WES_to_none

Initial state
WHS none WES
(Start_emb)

weapon_WHS_to_none weapon_none_to_WES

weapon_WHS_to_sas weapon_sas_WES_to_WES

weapon_sas_to_WHS weapon_WES_to_sas_WES

weapon_WES_sas_to_sas

sas sas_WES

weapon_sas_to_sas_WES © Naval Group, 2022, all rights reserved

Figure 7 : Transitions liées à la position de l’arme

Congrès Lambda Mu 23 10 au 13 octobre 2022, EDF Lab Paris Saclay

 La dernière étape de la modélisation consiste à mettre en
place un ou plusieurs observer(s) représentatif(s) des
événements redoutés du système. Compte-tenu du nombre
limité d’événements redoutés, il a été décidé de ne définir
qu’un seul observer qui correspond à la synthèse des
événements redoutés. Cela permet de n’effectuer qu’une
simulation pour vérifier si des séquences mènent aux
événements redoutés mais complexifie le traitement des
éventuelles séquences identifiées par le moteur de calcul.
n’empêche pas le bon déroulement des séquences de
fonctionnement du système à savoir mise en place et retrait de
la prolonge et embarquement / débarquement d’une arme.
Elle a également permis de contribuer à la validation du
modèle en vérifiant son comportement lors de sa construction
(en échangeant avec les concepteurs pour vérifier que les
contraintes physiques avaient correctement été implantées) et
de comprendre les résultats de la génération de séquences.

Cette étape reste délicate car il s’agit de traduire les
événements redoutés en combinaisons d’états de variables et
d’entrées / sorties.
Par exemple, l’événement redouté “perte de maintien de
l’arme lors d’une phase où elle se trouve sur un plan incliné”
a été traduit de la façon suivante :
• L’arme doit être en cours d’embarquement ou de
débarquement. En termes d’états, cela
correspond aux positions de l’arme différentes
d’absente (weapon_position != none) ou en
appui sur la rampe (weapon_position != WHS)
• La plateforme doit être inclinée ce qui signifie
que son angle doit être supérieur à 0 (angle > 0)
• Le chariot doit être déverrouillé
(~Logic.positions.o_trolley_locked)
L’observer correspondant s’écrit donc de la façon
suivante :
((Logic.positions.weapon_position != WHS) and
(Logic.positions.weapon_position != none))
and (Tilt_mech.angle > 0)
and ~Logic.positions.o_trolley_locked
III. RÉSULTATS
A. Simulation pas-à-pas
La simulation pas-à-pas du modèle a été utilisée surtout
pour vérifier que la logique sécuritaire mise en place
B. Génération de Séquences
Pour générer les séquences, le moteur de calcul
stochastique de Simfianeo a été utilisé avec les paramètres
suivants :
• Ordre : 100 (cet ordre est volontairement élevé afin de
permettre un nombre important de combinaisons de
séquences fonctionnelles)
• Nombre d’histoires : 100 000 (le nombre d’histoire est
modéré car les probabilités d’occurrences des
événements sont élevées du fait du taux de défaillance
 égal à 1 h-1).
La première tentative de génération de séquence a identifié
de très nombreuses séquences. L’analyse de ces séquences
(réalisée grâce à la simulation pas-à-pas) a rapidement permis
d’identifier que bon nombre d’entre elles étaient en réalité
dues à une mauvaise définition de l’observer venant ainsi
confirmer la difficulté de l’étape de traduction des événements
redoutés en observer.
Une fois les corrections réalisées, la génération de séquence a
permis d’identifier environ 7500 séquences (voir
Tableau 1). Il existe donc des combinaisons d’opérations
non couvertes par les Fonctions Instrumentées de Sécurité.

Tableau 1 : Résultats bruts de la génération de séquence

# Elements Order
1 Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Logic.positions.trolley_unlock 3
2 Logic.positions.trolley_lock & WHS.return_horiz & Tilt_mech.tilt_to_50 & Logic.positions.trolley_unlock 4
3 Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Rear_stop.unlock_rear_stop & Logic.positions.trolley_unlock 4
4 Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & WHS.return_horiz & Logic.positions.trolley_unlock 4
5 Rear_stop.unlock_rear_stop & Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Logic.positions.trolley_unlock 4
6 WHS.return_horiz & Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Logic.positions.trolley_unlock 4
7 Logic.positions.trolley_lock & Rear_stop.unlock_rear_stop & Tilt_mech.tilt_to_50 & Logic.positions.trolley_unlock 4
8 Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Tilt_mech.tilt_to_100 & Logic.positions.trolley_unlock 4
9 WHS.return_horiz & Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Rear_stop.unlock_rear_stop & 5
Logic.positions.trolley_unlock
10 Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Rear_stop.unlock_rear_stop & Tilt_mech.tilt_to_100 & 5
Logic.positions.trolley_unlock
11 Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Tilt_mech.tilt_to_100 & WHS.return_horiz & Logic.positions.trolley_unlock 5
12 Logic.positions.trolley_lock & WHS.return_horiz & Tilt_mech.tilt_to_50 & WHS.tilting_locking & Logic.positions.trolley_unlock 5
13 Rear_stop.unlock_rear_stop & WHS.return_horiz & Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & 5
Logic.positions.trolley_unlock
14 Logic.positions.trolley_home_to_WES & Logic.positions.trolley_WES_to_home & Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 5
& Logic.positions.trolley_unlock
15 Logic.positions.trolley_lock & Rear_stop.unlock_rear_stop & Tilt_mech.tilt_to_50 & Rear_stop.lock_rear_stop & 5
Logic.positions.trolley_unlock
16 WHS.return_horiz & Logic.positions.trolley_lock & WHS.tilting_locking & Tilt_mech.tilt_to_50 & Logic.positions.trolley_unlock 5
17 WHS.return_horiz & Rear_stop.unlock_rear_stop & Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & 5
Logic.positions.trolley_unlock
18 WHS.return_horiz & Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Tilt_mech.tilt_to_100 & Logic.positions.trolley_unlock 5

Congrès Lambda Mu 23 10 au 13 octobre 2022, EDF Lab Paris Saclay

 # Elements Order
19 WHS.return_horiz & Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & WHS.tilting_locking & Logic.positions.trolley_unlock 5
20 Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Tilt_mech.tilt_to_100 & Rear_stop.unlock_rear_stop & 5
Logic.positions.trolley_unlock
21 Logic.positions.trolley_lock & Rear_stop.unlock_rear_stop & Rear_stop.lock_rear_stop & Tilt_mech.tilt_to_50 & 5
Logic.positions.trolley_unlock
22 Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Rear_stop.unlock_rear_stop & WHS.return_horiz & 5
Logic.positions.trolley_unlock
23 Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & WHS.return_horiz & Rear_stop.unlock_rear_stop & 5
Logic.positions.trolley_unlock
24 Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Rear_stop.unlock_rear_stop & Rear_stop.lock_rear_stop & 5
Logic.positions.trolley_unlock
25 Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Tilt_mech.tilt_to_0 & Tilt_mech.tilt_to_50 & Logic.positions.trolley_unlock 5
26 WHS.return_horiz & Logic.positions.trolley_lock & Rear_stop.unlock_rear_stop & Tilt_mech.tilt_to_50 & 5
Logic.positions.trolley_unlock
… … …
7488 Logic.positions.trolley_home_to_WES & Logic.positions.weapon_WES_none & Logic.positions.trolley_lock & … 100
7489 Rear_stop.unlock_rear_stop & Logic.positions.trolley_lock & Logic.positions.trolley_home_to_WES & … 100
7490 Logic.positions.weapon_WES_none & Logic.positions.trolley_lock & WHS.return_horiz & Rear_stop.unlock_rear_stop & … 100
7491 WHS.return_horiz & Logic.positions.trolley_home_to_WES & Logic.positions.trolley_lock & Logic.positions.trolley_unlock & … 100
7492 Logic.positions.weapon_WES_none & WHS.return_horiz & Rear_stop.unlock_rear_stop & Logic.positions.trolley_lock & … 100
7493 Logic.positions.trolley_lock & Logic.positions.trolley_unlock & Rear_stop.unlock_rear_stop & ... 100
7494 Rear_stop.unlock_rear_stop & Rear_stop.lock_rear_stop & Logic.positions.trolley_home_to_WES & … 100
7495 Logic.positions.trolley_home_to_WES & Logic.positions.weapon_WES_none & Logic.positions.trolley_WES_to_sas & … 100
7496 Rear_stop.unlock_rear_stop & Logic.positions.trolley_home_to_WES & Logic.positions.trolley_WES_to_home & … 100
7497 Logic.positions.weapon_WES_none & Logic.positions.trolley_lock & Logic.positions.trolley_home_to_WES & … 100
7498 Logic.positions.trolley_lock & Rear_stop.unlock_rear_stop & WHS.return_horiz & Tilt_mech.tilt_to_50 & … 100
7499 Rear_stop.unlock_rear_stop & Logic.positions.trolley_home_to_WES & Logic.positions.weapon_WES_none & … 100
7500 WHS.return_horiz & WHS.tilting_locking & Logic.positions.weapon_WES_none & Logic.positions.trolley_home_to_WES & … 100
7501 Logic.positions.weapon_WES_none & Logic.positions.weapon_none_to_WES & WHS.return_horiz & WHS.tilting_locking & … 100

Pour analyser ces séquences, Simfianeo offre deux mieux appréhender les causes de déclenchement de
fonctionnalités intéressantes : l’événement redouté.
• Un post-traitement de minimisation des séquences qui La minimisation montre que toutes les séquences
permet de ne retenir que les séquences minimales (voir identifiées partagent une seule et unique séquence
Tableau 2) correspondant à une faille dans les Fonctions Instrumentées de
Sécurité. Cette faille correspondait à la possibilité d’incliner
• La possibilité de choisir une séquence et de la la plateforme après avoir verrouillé le chariot sans qu’il soit
reproduire en simulation pas-à-pas ce qui permet de en contact avec l’arme (« dans le vide »).
Tableau 2 : Résultat synthétique de la génération de séquences

# Elements Order
1 Logic.positions.trolley_lock & Tilt_mech.tilt_to_50 & Logic.positions.trolley_unlock 3

Ce scénario a été traité en ajoutant l’information chariot en

i_contact_trolley_weapon
i_weapon_presence_WES

contact avec l’arme aux conditions à remplir pour autoriser le

mouvement d’inclinaison de la plateforme. Suite à cette
i_trolley_at_home

i_trolley_locked

modification, plus aucune séquence n’est identifiée ce qui

permet de confirmer que les Fonctions Instrumentées de
Sécurité couvrent bien l’ensembles des configurations.
La Figure 8 et la Figure 9 présentent la version finale de la
cette fonction et du bloc concerné dans le modèle.
No module
Trolley at
on WES case {
Home
platform i_trolley_at_home and ~i_weapon_presence_WES : true,
i_trolley_at_home and i_trolley_locked and i_contact_trolley_weapon : true,
else
false
}
Module in
Trolley
contact with
locked
trolley
o_tilt_authorised

Figure 8 : Logique de la fonction de Sécurité sur l’inclinaison de la Figure 9 : Bloc virtuel “tilting author”– version finale
plateforme – version finale

Congrès Lambda Mu 23 10 au 13 octobre 2022, EDF Lab Paris Saclay

C. Optimisation
Pour vérifier si toutes les informations contenues dans les
assertions (conditionnant l’autorisation d’utiliser les
actionneurs) étaient bien nécessaires, d’autres simulations ont
été réalisées en isolant, un à un, les capteurs sur lesquels il y
avait un doute. Si aucune séquence n’est identifiée sans ces
capteurs, cela confirme leur inutilité dans la Fonction
Instrumentée de Sécurité. Cette vérification a permis de mettre
en évidence que quelques informations étaient superflues
permettant ainsi d’ajuster les fonctions au juste besoin.
IV. CONCLUSION
Cette application sur un système relativement simple
montre que l'analyse qualitative des fonctions de sécurité à
l’aide d’une approche MBSA présente de réels avantages.
L’exhaustivité des scénarios (y compris les phases
transitoires) explorés par les moteurs de calculs permet de
mettre en évidence les éventuelles failles au niveau des
fonctions de sécurité.
La simulation pas-à-pas de vérifier l'absence de situations
de blocage.
Congrès Lambda Mu 23
L’approche MBSA permet également d'optimiser les
fonctions de sécurité en testant rapidement des modifications
et ainsi de ne conserver que les informations nécessaires et
suffisantes dans les conditions d'autorisation d'utilisation des
actionneurs.
De plus, la représentation graphique proposée par le
logiciel Simfianeo (beaucoup plus abordable qu’une
représentation sous forme d’arbres de défaillances ou de
réseaux de Petri) facilite grandement le dialogue avec les
concepteurs et leur compréhension du métier de la Sûreté de
Fonctionnement.
REFERENCES
[1] X. de Bossoreille, M. Machin, L. Sagaspe, “Un nouvel outil de Safety
pour maîtriser la complexité des systèmes,” Congrès Lambda-Mu 21,
Octobre 2018.
[2] M. Boiteau, Y. Dutuit, A. Rauzy and J.-P. Signoret, The AltaRica Data-
Flow Language in Use: Modeling of Production Availability of a
MultiStates System, Reliability Engineering / System Safety
91(7):747-755, July 2006
10 au 13 octobre 2022, EDF Lab Paris Saclay