MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

ET DE LA RECHERCHE

MASTER de RECHERCHE
DOMAINE SCIENCES ET TECHNOLOGIES
Mention « Conception Industrialisation Risque Décision »
Spécialité « Knowledge Integration in Mechanical Production »
Parcours « Conception, Industrialisation, Innovation »

2016-2017

Intégration de la sécurité au plus tôt dans la conception de système

de production basé sur les modèles de l’Ingénierie Système

Rapport de master de recherche

Réalisé et soutenu le 07/09/2017 par Mariem ARBI

Responsables de recherche : Alain ETIENNE

Bruno DAILLE-LEFEVRE
 Remerciements

Le travail présenté dans ce mémoire a été réalisé au Laboratoire de Conception Fabrication

Commande (LCFC) à l’Ecole Nationale Supérieure d’Arts et Métiers de Metz.
Je remercie Monsieur Alain ETIENNE, maitre de conférences au campus de Metz des Arts et
Métiers, de m’avoir accueilli au sein de son groupe de recherche de LCFC et d’avoir encadré mon travail
en m’apportant nombres de recommandations.

Ce travail a également été dirigé par Monsieur Bruno DAILLE-LEFEVRE, Chargé d'études
Ingénierie des équipements de travail à l’INRS à qui j’exprime ma gratitude pour ses conseils, son
soutien et sa confiance.

J’associe à ces remerciements tous les membres de l’ENSAM centre Metz, enseignants chercheurs,
doctorants et stagiaires, avec qui j’ai pu travailler et échanger durant ce master.

Je remercie tous ceux qui de près ou de loin ont contribué à la réussite de ce travail.

Metz, le 30-08-2017

ii
 Dédicaces

Je dédie ce travail de master à ma famille, sans qui rien n’aurait été possible.

iii
 Table des matières

Remerciements ........................................................................................................................................ ii
Dédicaces ............................................................................................................................................... iii
Annexes ................................................................................................................................................... v
Tableaux .................................................................................................................................................. v
Figures ..................................................................................................................................................... v
Résumé .................................................................................................................................................. vii
Abréviations ......................................................................................................................................... viii
Introduction ............................................................................................................................................. 1
Chapitre 1 : Présentation du processus de conception de système de production dans le cadre de l’IS.. 3
I. Définition des modèles de l’Ingénierie Système ......................................................................... 3
1. Les diagrammes comportementaux ......................................................................................... 5
2. Les diagrammes structurels ..................................................................................................... 8
3. Le diagramme transversal...................................................................................................... 10
II. Définition de processus de conception de système complexe dans le cadre de l’IS ................. 11
III. Processus d’appréciation et réduction des risques suivant la norme ISO 12100 ................... 13
IV. Choix d’outil de modélisation des diagrammes de SysML issus de phases de conception de
système de production ....................................................................................................................... 14
Chapitre2 : L’interopérabilité entre le processus de conception de système de production et le
processus d’appréciation des risques suivant la norme ISO 12100 ....................................................... 16
I. Les modèles d’information pour la structuration de l’étape d’identification des risques .......... 20
II. Les modèles d’information pour la structuration de l’étape d’évaluation des risques .............. 22
III. Le modèles d’information pour le traitement des risques ..................................................... 23
IV. Etude de cas : la scie à viande, la machine à tronçonner ....................................................... 25
V. Synthèse des cas d’étude ........................................................................................................... 31
Conclusions ........................................................................................................................................... 32
Annexes ................................................................................................................................................. 34
Références bibliographiques ................................................................................................................. 42

iv
 Annexes

Annexe 1 : Tableau de notation des critères de choix d’outil de modélisation ..................................... 34

Annexe 2 : Diagramme de contexte de la scie à viande ........................................................................ 35
Annexe 3 : Diagramme de cas d’utilisation de la scie à viande ............................................................ 35
Annexe 4 : Diagramme de contexte de dispositif de protection ............................................................ 36
Annexe 5 : Diagramme des exigences de dispositif de protection ........................................................ 36
Annexe 6 : Diagramme d’état de dispositif de protection ..................................................................... 37
Annexe 7 : Diagramme de définition de bloc de sous-système poussoir tiroir ..................................... 37
Annexe 8 : Diagramme de séquence de sous-système poussoir tiroir ................................................... 38
Annexe 9 : Modèle d’information pour l’identification des risques liés aux flux d’énergie de la machine
tronçonneuse.......................................................................................................................................... 39
Annexe 10 : Modèle d’information pour la réduction des risques liés aux flux d’énergie de la machine
tronçonneuse.......................................................................................................................................... 40
Annexe 11 : Modèle d’information pour l’identification des risques liés aux flux d’énergie de la machine
tronçonneuse.......................................................................................................................................... 41
Annexe 12 : Modèle d’information pour la réduction des risques liés aux flux d’énergie de la machine
tronçonneuse.......................................................................................................................................... 41

Tableaux

Tableau 1 : Les critères dispensables de choix d’outil de modélisation de SysML .............................. 14

Figures

Figure 1 : Cycle de développement en V [Guillerm, 2011] .................................................................... 3

Figure 2 : Exemple de diagramme de cas d’utilisation, [Pascal,2015] .................................................... 5
Figure 3 : Exemple de diagramme de séquence, [Pascal,2015] .............................................................. 6
Figure 4 : Exemple de diagramme d’état, [Pascal,2015] ......................................................................... 7
Figure 5 : Exemple de diagramme d’activité, [Pascal,2015] ................................................................... 7
Figure 6 : Exemple de diagramme de définition de bloc, [Pascal,2015] ................................................. 8
Figure 7 : Exemple de diagramme de bloc interne [Pascal,2015] ........................................................... 9
Figure 8 : Exemple de diagramme paramétrique [Pascal,2015] .............................................................. 9
Figure 9 : Exemple de diagramme des exigences [Pascal,2015] ........................................................... 10
Figure 10 : Processus de conception d’un système complexe dans le cadre de l’IS ............................. 11
Figure 11 : Processus d’identification et réduction des risques............................................................. 13
Figure 12 : Diagramme Radar ............................................................................................................... 15
Figure 13 : L’interopérabilité entre le processus de conception système de production et le processus
d’appréciation des risques suivant la norme ISO 12100 ....................................................................... 17

v
Figure 14 : Diagramme de cas d’utilisation montre le comportement de l’opérateur en cas de
dysfonctionnement ................................................................................................................................ 18
Figure 15 : Diagramme de séquence de système hydraulique............................................................... 19
Figure 16 : Modèle d’information pour l’identification des risques ..................................................... 20
Figure 17 : Modèle d’information pour l’identification des risques liés aux flux d’énergie ................. 21
Figure 18 : Modèle d’information pour l’identification des risques ..................................................... 22
Figure 19 : Modèle d’information pour l’évaluation des risques .......................................................... 23
Figure 20 : La distance de sécurité e et l’angle E pour éviter le risque d’entraînement [Sécurité machine]
............................................................................................................................................................... 24
Figure 21 : Modèle d’information pour le traitement des risques ......................................................... 25
Figure 22 : Diagramme de séquence « Transformer la viande brute en morceaux de viande » ............ 26
Figure 23 : Modèle d’information pour l’identification du risque de la scie à viande .......................... 27
Figure 24 : Modèle d’information pour la réduction des risques de la scie à viande ............................ 28
Figure 25 : Diagramme de bloc interne de la machine à tronçonner ..................................................... 29
Figure 26 : Modèle d’information pour l’identification des risques liés aux flux d’énergie de la machine
à tronçonner ........................................................................................................................................... 30
Figure 27 : Modèle d’information de réduction des risques liés aux flux d’énergie de la machine
tronçonneuse.......................................................................................................................................... 31

vi
 Résumé

Les secteurs manufacturiers sont les plus impactés par les accidents liés à l’utilisation de la machine. Et l’une des
principales raisons de ces accidents est la conception de systèmes de production qui ne prend pas en compte la
sécurité de l’opérateur. Dans ce projet de master une méthode est proposée pour pallier ce problème. Tout
d’abord, un processus de conception de machine dans le cadre d’Ingénierie Système et des modèles de SysML
sont définis comme un moyen pour structurer les données manipulées lors de cette phase. Ainsi une interopérabilité
entre le processus de conception de système de production et processus d’appréciation des risques suivant la
norme ISO 12100 est présentée clairement. Cette interaction identifie les étapes de conception propices à une
intégration pertinente de la sécurité et génère dans le langage SysML des modèles d’information pour
l’identification, l’estimation, l’évaluation et la réduction des risques.

Mots clés :

Ingénierie Système, Conception de la machine, Sécurité de l’opérateur, modèles de

SysML

Abstract

Manufacturing sectors are the most affected by accidents related to the use of the machine. And one of the main
reasons for these accidents is the design of production systems that does not take into account the safety of the
operator. In this master project, a method is proposed to overcome this problem. First, a machine design process
within the framework of System Engineering and SysML models are defined as a way to structure the data
manipulated during this phase. Thus, an interoperability between the production system design process and the
risk assessment process according to the ISO 12100 standard is clearly presented. This interaction identifies
design steps that are conducive to meaningful security integration and generates information models for the
identification, estimation, evaluation, and reduction of risks in the SysML language.
Keys words

System Engineering, Machine design, safety of the operator, SysML models

vii
 Abréviations

APTE :Analyse de la valeur - Analyse Fonctionnelle

AMDEC : Analyse des modes de défaillance, de leurs effets et de leur criticité
LC2S : Laboratoire de Conception de Systèmes Sûrs
LCFC : Laboratoire de Conception Fabrication Commande
CPI : Laboratoire Conception, équipements de Protection et Interface homme-machine
EZID: Energy analysis for systematic hazard Identification during Design
MFS : Modèle Fonctionno-Structurel
UML : Unified Modeling Language
SysML : Systems Modelling Language
MéDISIS : Méthode D’Intégration des analyses Sdf à l’Ingénierie Système
IS: Ingénierie Système
HAZOP: Hazard and operability studies

viii
Introduction

La conception d’une machine est une activité complexe. Elle consiste à mener conjointement des
activités telles que l’analyse du cahier de charges fonctionnel, la spécification technique des besoins et
la définition de l’architecture du système, afin de parvenir à une solution satisfaisant un besoin formulé
par les parties prenantes et un ensemble des exigences. Et l’une des exigences actuelles, dans le domaine
de conception et de l’industrialisation de système, est la sécurité de l’opérateur. En effet, le concept de
sécurité est devenu un des enjeux les plus importants pour la conception des nombreux systèmes
complexes et multi-technologiques. Il est utilisé pour exprimer l’absence d’accident ou de perte
humaine. D’où le besoin d’effectuer des analyses et des estimations des risques de manière précise et
méthodique dans un processus de conception d’un système de production. C’est dans ce cadre qui
s’inscrivent les travaux de ce projet de master de recherche intitulé « Intégration de la sécurité au plus
tôt dans un processus de conception de système de production basé sur les modèles d’Ingénierie
Système ». Ce projet est proposé dans le cadre d’un partenariat entre l’INRS et le laboratoire LCFC
Arts et Métiers. L’INRS est un organisme scientifique et technique qui travaille dans le domaine de la
prévention des risques professionnels. Et les travaux réalisés au LCFC ont pour objectif de formaliser
des connaissances technologiques, de valider la pertinence de modèles et les démarches proposées dans
un souci de cohérence, de robustesse, de gestion des incertitudes et d’optimisation globale liées aux
procédés, processus de fabrication et moyens de production afin de disposer des modèles, démarches et
outils d’aide à la décision pour la conception et la fabrication des systèmes de haute qualité[Eureka].
Ainsi plusieurs travaux récents concernant l’intégration des aspects de sécurité professionnelle dans le
processus de conception de machines industrielles sont menés dans le laboratoire commun LC2C
composés du LCFC des Arts et Métiers et CPI de l’INRS. Citons la thèse de [Galvez, 2016] qui
s’intéresse à l’intégration de la sécurité tout au long de processus de conception d’une machine en se
basant sur la méthode Energy analysis for systematic hazard Identification during Design (EZID). EZID
permet de modéliser les échanges d’énergies durant les différentes phases de vie de système, il permet
d’identifier les phénomènes dangereux auxquels est exposé l’opérateur à un moment précis à l’aide du
modèle fonctionnel structurel MFS afin de permettre au concepteur de suivre le processus d’appréciation
des risques et de définir les moyens de protection adaptés. Ce travail de recherche s’inscrit alors dans la
continuité de ce travail, en effet, mon défi est définir des techniques rigoureuses de l’Ingénierie Système
permettant de maîtriser tout au long des phases de conception la complexité des systèmes et les étapes
d’identification et réduction des risques. Ainsi, la problématique de ce mémoire est :
Quel est le cycle de développement de système d’IS qui nous permet d’ordonnancer les tâches
à réaliser pour concevoir le système désiré ?
Quels langages de modélisation d’IS permettent de connecter les différentes activités d’analyse
et de conception de machine ?
Dans quelles phases du processus de conception d’un système dans le cadre de l’IS, devons-
nous intégrer le processus d’analyse des phénomènes dangereux et de validation de la sécurité de
l’opérateur ?
Comment les modèles d’IS peuvent être employés pour réaliser une détection systématique
des phénomènes dangereux ou des situations dangereuses très tôt dans la conception de système ?
Comment pouvons-nous modéliser le résultat d’identification, estimation, évaluation et
réduction des risques en s’appuyant sur les modèles d’IS ?
Avant de résoudre cette problématique, nous avons réalisé une étude bibliographique qui a donné
lieu à un premier rapport. Cette étude permet dans un premier temps d’étudier le cadre de l’Ingénierie
Système et les techniques de modélisation sur lesquelles s’appuient l’IS afin de maîtriser la phase de
conception d’un système de production. Les travaux de l’intégration de sûreté de fonctionnement au
plus tôt dans la phase de conception en se basant sur les modèles d’IS ont été explorés. On cite par

1
exemple la méthode MéDISIS de la thèse [David,2009]. C’est une méthode qui organise l’analyse de
sûreté de fonctionnement en exploitant les modèles SysML purement fonctionnels. Le but de ce projet
est de s’inspirer de cette méthodologie et faire un parallèle entre la sûreté de fonctionnement et la sécurité
de l’utilisateur vu que ces deux concepts présentent d’importantes ressemblances. En effet, la gestion de
la sécurité et la sûreté s’appuient sur la notion de risque. En plus, la résolution des problématiques de
sûreté et sécurité peuvent avoir des impacts conséquents sur la conception des architectures du système.
Suite à cette introduction, le premier chapitre présente le cadre de l’Ingénierie Système, la définition
des diagrammes SysML. Il présente entre autres, le processus de conception d’un système complexe
dans le cadre de l’IS, ainsi que le processus d’appréciation et réduction des risques suivant la norme
ISO_12100 [ISO 12100]
Le deuxième chapitre expose la contribution de ce projet qui est l’interopérabilité entre ces deux
approches ainsi que les modèles de SysML utiles à cette fin. Ce chapitre finit par introduire deus cas
d’étude qui sont la machine à tronçonner et la scie à viande.
Pour finir ce rapport, une conclusion générale dresse le bilan des contributions apportées par rapport
à la problématique initiale. Il s’agit également de présenter les perspectives des futurs travaux afin
d’améliorer et poursuivre ce master.

2
 Chapitre 1 : Présentation du processus de conception de système de production dans le
cadre de l’IS

Ce travail de recherche consiste à étudier les possibilités d’intégration de la sécurité au plus tôt dans
le processus de conception d’un système complexe. Ainsi, son objectif est de permettre au concepteur
d’une machine l’intégration des mesures de sécurité qui consistent à éviter ou réduire des phénomènes
dangereux autant que possible en choisissant convenablement certaines caractéristiques de conception
ou limiter l’exposition des personnes aux phénomènes dangereux inévitables. Afin de réaliser cet
objectif, dans un premier temps, une structuration des activités de conception est définie dans un
processus basé sur les modèles d’Ingénierie Système faisant apparaître les types de données manipulés,
la manière dont ils sont créés et le séquencement de leur apparition. Dans un second temps, le processus
d’identification et réduction des risques est présenté brièvement afin de mettre en lumière les pratiques
que le concepteur doit intégrer dans le processus de développement d’un système de production pour
garantir la sécurité de l’opérateur.

I. Définition des modèles de l’Ingénierie Système

La complexité de conception d’un système provient de l’augmentation des données, des variables,
du nombre de domaines simultanément impliqués dans son fonctionnement. Cette complexité conduit
les ingénieurs à adopter des nouvelles méthodes de conception. Dans le cadre de ce sujet de master, la
démarche d’IS est adaptée pour définir un processus de conception de système. Elle permet de gérer
toutes les tâches nécessaires au développement du système et la détermination de l’architecture
fonctionnelle à réaliser à la validation des choix opérés et performances. La contribution de ce travail
consiste à identifier les étapes de conception propices à une intégration pertinente de la sécurité dans le
contexte des modèles d’IS. Avant d’introduire ce processus, les modèles de SysML sont présentés. En
effet, « l’Ingénierie Système est une démarche méthodologique interdisciplinaire qui englobe
l’ensemble des activités adéquates pour concevoir, faire évoluer et vérifier un système apportant une
solution économique et performante aux besoins d’un client tout en satisfaisant l’ensemble des parties
prenantes » [David,2009]. Ainsi, l’Ingénierie Système développe des méthodes et outils permettant de
comprendre et de gérer la complexité des systèmes. Tout au long des étapes de conception, le système
passe par différents stades : expression des exigences, définition de solution fonctionnelle puis physique.

Cahier de charges fonctionnels

Spécification
Validation Système
Référentiel des exigences

Conception Intégration Système

Dossier de conception

Développement des constituants

Figure 1 : Cycle de développement en V [Guillerm, 2011]

3
 Et l’un des enjeux de l’IS est de s’assurer de la cohérence et de l’interopérabilité de ces
représentations au cours de l’avancement du projet. Pour cette raison, le cycle de développement d’IS
choisi est le cycle en V. La figure 1 donne un exemple de ce cycle de développement. Ce cycle
commence par une étape de spécification. Elle démarre avec un cahier de charges fonctionnel et elle
produit le référentiel des exigences. Ensuite, une étape de conception démarre pour aboutir au dossier
de conception composé d’une spécification de l’architecture du système et des spécifications techniques
des besoins des constituants. Ainsi, l’étape de développement des différents constituants, qui vont
composer le système final, commence. Pour finir, se succèdent les étapes d’intégration du système
pendant lesquelles les constituants sont assemblés entre eux et la validation du système pour vérifier que
le système répond bien aux besoins initiaux (le cahier des charges fonctionnel). Donc, ce cycle en V est
séparé en deux branches : une branche descente correspondante à une phase de spécification et
conception et une branche ascendante détaillant les phases d’intégration et validation du système. La
définition du processus de conception du système s’inspire de la construction de la branche descente de
cycle en V. En effet, le concepteur est informé des besoins des utilisateurs et des parties prenantes. Tous
ces besoins sont alors étudiés et analysés, puis progressivement transformés en une spécification faite
d’exigences fonctionnelles et non fonctionnelles qui sont des énoncés plus ou moins formels des besoins
de l’ensemble des parties prenantes. Le concepteur démarre alors la phase d’étude fonctionnelle du
système en commençant par une analyse externe, pour ensuite procéder à une analyse interne qui
consiste à décomposer les fonctions en sous fonctions. Puis, la conception du système proprement dit
commence par l’approche organique qui consiste à découper le système en autant de sous-systèmes que
nécessaire et à faire des choix d’organes matériels ou de modules logiciels. On obtient alors
l’architecture organique du système, qui peut être vue comme une solution logique. Pour finir, il reste
l’approche physique qui consiste à faire des choix d’organes physique pour répondre à l’architecture
organique préalablement établie. Il s’agit de produire l’architecture physique. Donc, le concepteur a
besoin d’écrire les besoins et les exigences clairement dans un modèle et d’en s’assurer la traçabilité
vers l’architecture. Il a besoin de représenter les éléments non logiciels et d’en spécifier le type
(mécanique, circuit hydraulique, câblage, capteur). Le développeur a besoin aussi de représenter les
équations physiques, les contraintes et les flux continus. En plus, il a besoin de représenter des
allocations (logique vers physique). Or, lors d’étude bibliographique, certains modèles d’IS sont définis
tel que le langage UML. En effet, UML a été développé par l’OMG pour aider à spécifier, visualiser et
documenter des modèles de systèmes logiciels mais il est faiblement accepté par l’Ingénierie Système
en raison de sa sémantique trop orientée logiciel. UML est un langage orienté objet. Il ne soutient pas la
modélisation des flux continus : il n’offre pas une expression claire des flux physiques d’énergie et de
matériel et de passage d’information entre les composants du système. Et il n’offre pas non plus la
gestion réelle des exigences système pendant la conception. Ces manques ont conduit à choisir le SysML
comme un langage de modélisation, support de processus de conception de système complexe. Il est une
extension d’UML destinée à la modélisation d’un large spectre de systèmes complexes. Le vocabulaire
d’UML axé sur l’objet et les classes a été caché dans SysML et remplacé par un vocabulaire général.
SysML est particulièrement efficace dans la précision des exigences, la structure, le comportement, les
allocations et les contraintes sur les propriétés du système. Ce langage repose sur une décomposition du
modèle en vues. Chaque vue est dédiée à la représentation d’un aspect particulier du système : exigences,
structures, comportements. Et chaque vue est représentée dans un diagramme spécial de SysML. Donc,
une étude est faite sur les différents diagrammes de SysML afin d’être capable d’indiquer à chaque type
du modèle durant quelle phase de processus de développement de système doit être produit ou exploité.
Ces diagrammes sont regroupés suivant trois classes définies dans la section suivante.

4
 1. Les diagrammes comportementaux
L’axe comportemental comporte 4 types de diagrammes. Le diagramme de cas d’utilisation est une
vue très haut niveau des fonctionnalités du système. L’environnement et les éléments en interaction avec
le système, ainsi que les liens existants entre les diverses fonctionnalités y sont représentés. Les trois
autres diagrammes, diagramme de séquence, diagramme d’état et diagramme d’activité sont dédiés à la
modélisation du comportement du bloc. Ces blocs présentent les acteurs en interaction directe ou
indirecte avec le système. Ces acteurs peuvent être tous les profils humains qui sont en interaction directe
avec le système ou les autres sous-systèmes tels qu’un ordinateur, un programme, une base de données
ou une norme. Donc, l’opérateur est considéré comme un élément crucial du système. Les diagrammes
comportementaux, plus particulièrement le diagramme de cas d’utilisation et le diagramme de séquence,
permettent alors d’identifier rigoureusement tous les acteurs humains en contact direct ou indirect avec
le système principal ou bien ses composants et permet de décrire le comportement du bloc acteur humain
qui est le point clé de cette étude sur lequel on cherche ultérieurement de le prévenir de tout phénomène
dangereux.
Le diagramme de cas d’utilisation spécifie les fonctionnalités attendues du système et liens entre
ces fonctionnalités et acteurs du système. Le schéma 2 de cas d’étude radio-réveil [Pascal, 2015] montre
les cas d’utilisation (ovales) reliés par des associations à leurs acteurs (icône du stick man pour acteur
humain ou bloc pour les autres sous-systèmes).

Figure 2 : Exemple de diagramme de cas d’utilisation, [Pascal,2015]

Le diagramme de séquence décrit les acteurs externes comme des lignes de vie qui interagissent
directement avec le système. Il modélise chronologiquement les interactions entre ces lignes de vie en
montrant les messages passés entre eux. Cette modélisation est illustrée dans le cas d’étude radio-réveil

5
[Pascal, 2015] dans la figure 3. Les diagrammes de séquence peuvent être utilisés à différents niveaux
de la hiérarchie de système. A un niveau supérieur, ils représentent les interactions entre le système et
son environnement. A niveau de détail inférieur, ils représentent les interactions entre les composants
internes du système.

Figure 3 : Exemple de diagramme de séquence, [Pascal,2015]

Le diagramme d’état permet de modéliser des comportements de type état-transition. En effet, il

introduit une vue locale d’un bloc SysML qui décrit comment il réagit à évènements en fonction de son
état courant et comment il passe dans un nouvel état. Et la figure 4 illustre un exemple du diagramme
d’état.

6
 Figure 4 : Exemple de diagramme d’état, [Pascal,2015]

Le diagramme d’activité sert à préciser la séquence d’actions à réaliser et à structurer ce qui est
produit, consommé ou transformé au cours de l’exécution des activités de système à travers les éléments
de base suivants : des actions, des flots de contrôle entre actions, des branchements conditionnels, un
début et une ou plusieurs fins. La figure 5 introduit un diagramme d’activité de cas d’étude réveil-radio
[Pascal, 2015].

Figure 5 : Exemple de diagramme d’activité, [Pascal,2015]

7
 2. Les diagrammes structurels
L’élément principal de structuration en SysML est l’élément bloc. Ce bloc permet de modéliser la
structure externe et interne du système. A la frontière entre les blocs et leur environnement, les ports
permettent de spécifier les interfaces de ces blocs en distinguant les interfaces issues du logiciel (port
standard) et les ports de flux qui permettent de spécifier une interface physique support de l’entrée/sortie
de flux continus d’information, de matière et d’énergie. Dans cet axe structurel s’inscrivent trois
diagrammes :
Le diagramme de définition de bloc représente graphiquement des relations de composition et
d’agrégation de blocs, des attributs et des opérations associés aux blocs. La figure 6 montre un exemple
du diagramme de définition de bloc.

Figure 6 : Exemple de diagramme de définition de bloc, [Pascal,2015]

Le diagramme de bloc interne décrit la structure interne du système. Il décrit la logique de

connexion de flux immatériels et physiques entre blocs de même niveau grâce au concept port standard
et port de flux. Il permet de modéliser l’interface externe avec l’opérateur qui doit respecter des
contraintes spécifiques pour la sécurité de l’utilisateur. Cette modélisation est illustrée dans la figure 7.

8
 Figure 7 : Exemple de diagramme de bloc interne [Pascal,2015]

Le diagramme paramétrique est une technique de modélisation spécifique à SysML permettant

d’intégrer dans un modèle des représentations des contraintes ou d’équations à des fins d’analyse. Il
s’agit d’une spécialisation du diagramme de bloc interne où les seuls blocs utilisables sont des relations
entre paramètres permettant de représenter graphiquement des équations et des relations mathématiques.
La figure 8 montre un exemple de diagramme paramétrique de cas d’étude radio réveil [Pascal, 2015].

Figure 8 : Exemple de diagramme paramétrique [Pascal,2015]

9
 3. Le diagramme transversal
Le diagramme des exigences
Les blocs d’exigences permettent d’intégrer dans ce modèle les exigences fonctionnelles et non
fonctionnelles structurées entre elles par des relations hiérarchiques et de liens de traçabilité :
Exigence- élément comportement sont reliés par la relation « refine »
Exigence-bloc d’architecture sont reliés par la relation « satisfy »
Exigence-cas de test sont reliés par la relation « verify »
La figure 9 montre un exemple de diagramme de exigences.

Figure 9 : Exemple de diagramme des exigences [Pascal,2015]

Cette analyse permet de conclure que ces diagrammes modélisent efficacement la structure, les
composants physiques ou logiciels, les acteurs humains, les flux de données, les interconnexions, les
comportements basés sur les fonctions, des états et des messages, les contraintes sur les propriétés
physiques et les performances, les exigences, leurs relations entre elles, leur affectation à la structure et
la déclaration de leur méthode de test, les allocations entre comportement, structure et exigences. En
plus, le langage SysML est de plus en plus adopté par des industriels tels que Valeo, fournisseur de
système automobiles, et Airbus, concepteur et intégrateur des systèmes aéronautiques[Faîda,2014].
Concrètement, ce processus de conception basé sur les modèles de SysML va produire des référentiels
et des points de vue qui seront notre base des connaissances pour faire une détection systématique des
dangers, qui menace la sécurité de l’opérateur, très tôt dans le développement de système.

10
 II. Définition de processus de conception de système complexe dans le cadre de l’IS
Ainsi, après l’introduction des définitions fondamentales à cette étude, le processus de conception
d’un système complexe dans le périmètre de l’IS est expliqué rigoureusement et le processus
d’identification et réduction des risques de la norme ISO 12100 est présenté.

Processus de conception d’un système complexe dans le cadre d’IS

<<Data store>>
Analyse des besoins
Diagrammes des exigences

Diagramme de contexte

Diagramme de cas d’utilisation

Définir les exigences <<Data store>>

système
Diagrammes des exigences

<<Data store>>
Concevoir l’architecture
fonctionnelle ou logique du Diagrammes de séquence
système
Diagrammes d’état

Diagrammes de définition de
Concevoir l’architecture bloc <<Data store>>
organique du système
Diagrammes de définition de bloc

Diagrammes de séquence

Diagrammes d’activité

Diagramme de bloc interne

Diagramme paramétrique

Figure 10 : Processus de conception d’un système complexe dans le cadre de l’IS

11
 Comme le montre la figure 10, le processus de conception de système dans le périmètre de l’IS est
composé de cinq étapes principales. Les modèles de SysML sont schématisés comme des éléments de
communication entre les phases de ce processus. La première étape consiste à définir les besoins des
parties prenantes. Elle s’établit de la façon suivante : on définit la mission principale du système en
réalisant un diagramme des exigences qui comporte les stéréotypes Besoin-Mission, Besoin-Finalité,
par suite on présente par le diagramme de contexte toutes les entités externes, les parties physiques ou
morales concernés directement ou indirectement par le système dans toutes ses situations de vie. Sont
définies alors les utilisations du système. Ainsi, en se basant sur les données du diagramme de contexte
et diagramme des exigences réalisés précédemment, on s’attache à définir les fonctionnalités à réaliser
par le système pour chaque phase de vie en formalisant un diagramme de cas d’utilisation. Puis, pour
raffiner les différentes utilisations du système, on réalise pour chaque cas d’utilisation une description
textuelle sous forme d’un scénario dans un nouveau diagramme des cas d’utilisation. Ainsi, sur la base
d’analyse de diagrammes de cas d’utilisation et du diagramme de contexte, on formalise les besoins des
parties prenantes eu utilisant le concept SysML « Bloc d’exigence » où on décrit Besoin -Service,
Besoin opérationnel, Besoin performance, Besoin-Interface, Besoin -Contrainte. Par suite, l’étape de la
définition des exigences est établie : on exprime les exigences fonctionnelles et non fonctionnelles du
système dans les diagrammes des exigences. On formalise les différents exigences système : exigence
fonctionnelle, exigence opérationnelle, exigence performance, exigence contrainte et exigence interface
en utilisant le concept SysML d’exigence. Cette étape comporte une étape d’analyse des exigences
consistant à faire un retour aux parties prenantes sur les besoins exprimés pour s’assurer que les
exigences système reflètent bien les besoins des parties prenantes. Puis on passe à la définition de
l’architecture fonctionnelle en réponse aux exigences système exprimées pour satisfaire les besoins des
parties prenantes. A partir des scénarios associés à chaque cas d’utilisation, sont identifiées les
opérations du système dans le diagramme de séquence, et on associe chaque période d’activation de
ligne de vie d’un bloc à état de fonctionnement du système. Et de cette manière, le diagramme d’état est
réalisé. Ainsi, la vue logique du système est définie sur les diagrammes de définition de bloc. Les
opérations identifiées dans le diagramme de séquence apparaissent dans le compartiment opérations du
bloc et les évènements identifiés dans le diagramme de séquence apparaissent dans le compartiment
réception des signaux du bloc. Et pour la vérification de l’architecture logique, on reprend les
diagrammes des exigences pour les compléter par des liens de satisfaction : les opérations issues de
blocs de diagramme de définition de bloc sont allouées aux exigences fonctionnelles, et les exigences
non fonctionnelles sont satisfaites par d’autres caractéristiques du système. Par conséquent, on passe à
la phase cruciale de conception de l’architecture physique du système. On alloue les opérations aussi
leurs décompositions et les nouvelles opérations éventuelles aux sous-systèmes dans le diagramme de
définition de bloc. Pour concevoir les échanges avec les sous-systèmes, on reprend les diagrammes de
séquence, on fait apparaître les sous-systèmes, on définit les interactions entre eux en utilisant des
messages réflexifs, synchrones ou asynchrone. En se basant sur les éléments du diagramme de définition
de bloc, on ajoute sur les blocs sous-systèmes les ports et leur affecter les éléments externes en
interaction avec le système dans le diagramme de bloc interne. On utilise les ports standards pour les
interfaces commande et les ports flux pour les échanges de données, d’énergie ou de matière. On vérifie
l’architecture physique en reprenant les diagrammes d’exigences pour les compléter par de liens de
satisfaction des composants vers les exigences. En plus, les solutions logiques et physiques induisent à
leur tour des exigences techniques dérivées. De cette façon, l’architecture est validée lorsque toutes les
exigences système sont satisfaites par le système et les sous-systèmes.

12
 III. Processus d’appréciation et réduction des risques suivant la norme ISO 12100
La section précédente se focalise sur les étapes de conception d’un système dans lequel les
informations sont continuellement échangées grâce aux modèles de SysML. Dans cette section, la norme
ISO 12100 est étudiée en présentant le processus d’identification et réduction des risques qui définit les
tâches à exécuter pour respecter les exigences de santé et sécurité de l’opérateur.

Processus d’identification et réduction des risques

Définition des limites des fonctions de la machine D’autres

phénomènes
dangereux sont créés

Identification des dangers

Pas de nouveaux phénomènes dangereux

Estimation des risques

Evaluation des risques

Risque réduit de manière adéquate
Risque non réduit de manière adéquate

La prévention intrinsèque permettant la réduction du risque

Conception sûre
La prévention intrinsèque
ne permettant pas la
réduction du risque

Mesures techniques de protection

Réduction du risque par informations pour l’utilisateur

La réduction du risque n’est pas réalisée La réduction du risque souhaitée est réalisée

Figure 11 : Processus d’identification et réduction des risques

La figure 11 indique que l’analyse des risques concerne deux points essentiels. Une appréciation des
risques est une suite d’étapes logiques permettant l’identification, l’estimation et l’évaluation

13
 systématique des risques. Cette étape est suivie d’une réduction des risques étape au cours de laquelle
des mesures de protection adéquates sont mises en œuvre. Et l’application des mesures de protection ne
doivent pas générer de nouveaux risques. Il peut être nécessaire de répéter tout le processus
d’appréciation et de réduction des risques pour éliminer autant que possible les dangers et réduire
suffisamment les risques identifiés. Donc, c’est un processus itératif qui doit prendre en compte tous les
dangers et risques jusqu’à ce qu’il n’en reste aucun ou seulement des risques résiduels acceptables. Nous
exposons jusqu’ici les étapes de conception d’un système en mettant en parallèle les étapes de processus
de gestion des risques suivant la norme ISO 12100. Je rappelle que l’objectif de ce recherche consiste à
développer et valider une nouvelle méthodologie outillée pour garantir l’interaction entre ces deux
processus.

IV. Choix d’outil de modélisation des diagrammes de SysML issus de phases de

conception de système de production
L’objectif d’outiller cette méthodologie est la modélisation et la simulation les différents aspects des
systèmes dans les diagrammes SysML issus de la phase de conception dans un premier temps. Le
logiciel choisi doit permettre de réaliser une connexion systématique entre les deux approches et il
permet aussi d’introduire des extensions de SysML pour structurer le résultat du processus de gestion
du risque.

Les critères de choix du logiciel de modélisation du langage SysML Classe

1 : Respecter les standards SysML 1

2 : Une capacité graphique puissante : Apporter une très grande souplesse pour créer, associer, connecter, 2
organiser et manipuler les éléments d’un diagramme du SysML, personnaliser l’apparence des Stereotypes
des diagrammes SysML (couleur, largeur, longueur, police du texte)

3 : L’outil doit permettre de sélectionner des Stereotypes SysML (block, use case) d’un diagramme bien 4
précis sans avoir besoin d’importer le modèle entier et il permet aussi de faire des liens d’allocation et de
traçabilité entre eux. Il permet d’intégrer aussi des nouvelles Stereotypes tel que « risque », « défaut
système », « erreur » pour construire des modèles de structuration du processus de gestion du risque.

4 : Cout limité. 3

5 : L’outil est capable de faire la vérification de la sémantique SysML automatiquement afin de faciliter la 5
création de modèle valide
6 : Le logiciel permet de traduire les exigences sécurité et les risques identifiées dans la Stereotype 8
« Requirement » du SysML sous forme tabulaire.

7 : Partager les modèles de conception SysML pour la structuration du processus du gestion du risque 6
entre les concepteurs et les experts de sécurité dans un format texte ou en ligne.

8 : Simulation des modèles. 7

9 : Cohérence des modèles : toute modification d’un élément d’un diagramme SysML est 9
automatiquement propagée dans tous les modèles, pour résultat des modèles cohérents.

Tableau 1 : Les critères dispensables de choix d’outil de modélisation de SysML

14
 Afin de répondre à ces besoins, un nombre des critères spécifiques sont identifiées et classées dans
le tableau 1 ci-dessus. On définit leurs caractéristiques qui répondent convenablement aux objectifs
définis initialement, en se basant sur une échelle de notation commune à l’ensemble des critères
définis, les différents outils analysés sont notés dans l’annexe1. Et pour comparer les résultats obtenus,
ils sont présentés sous une forme cohérente et explicite. Et c’est là qu’intervient le diagramme Radar
de la figure 12 permettant d’avoir une synthèse visuelle qui aide à comparer directement sur le même
graphe les outils de modélisation en SysML.

1:Rational Rhapsody
Designer 9
2:Magic Draw 8
7

3:Sprax Entreprise 6
Architect 5
4
4:Pradigm visual
3
2
5:SysML designer 1
0
6:Modilo

7:CORE 9

8:Cameo System
Modeler
9:Innoslate

10:Lucichart

Figure 12 : Diagramme Radar

En analysant le diagramme Radar, les axes des CORE9, Cameo System Modeler, Magic Draw,
Rational Rhapsody Designer ont des axes qui tendent vers la forme pentagone et occupent une surface
importante. Ceci signifie que ces outils ont des caractéristiques similaires donc il est utile de choisir un
parmi eux dans l’application de la démarché proposée.

15
Chapitre2 : L’interopérabilité entre le processus de conception de système de
production et le processus d’appréciation des risques suivant la norme ISO 12100

Après la modélisation du processus de conception dans le périmètre de l’IS, le travail de ce master

consiste à chercher les moment clés de la conception et les données à utiliser pour aider le concepteur
lors de son identification et réduction des risques afin de respecter les exigences de santé et de sécurité
de l’opérateur. En effet, cette étude s’intéresse aux opportunités données par SysML pour identifier les
problématiques d’interactions Homme-machine qui peuvent être à l’origine des risques.

La figure 13 détaille l’interopérabilité entre le processus de développement d’un système de

production dans le contexte d’IS et le processus d’identification et de réduction des risques ainsi que le
langage de modélisation SysML. En se basant sur la figure 13, on décrit comment les modèles SysML
peuvent être analysés pour supporter le processus de gestion de risques. En effet, l’analyse,
l’identification, l’estimation et l’évaluation des risques s’appuient sur la compréhension du système du
point de vue de ses fonctions, ses frontières ainsi que l’utilisation attendue. En outre, certains éléments
du système comme les flux d’énergie, et les interfaces homme-machine doivent être correctement définis
pour pouvoir réaliser l’analyse des risques. La phase d’appréciation des risques commence en
définissant les limites des fonctions de la machine. En effet, l’environnement et le milieu de la machine
peuvent être identifiés à partir du diagramme de contexte découlant de l’étape « définir le contexte » du
système comme le montre la relation (1) dans la figure 13. Les fonctions de la machine peuvent être
définies à partir des diagrammes de cas d’utilisation comme il est montré dans le lien (2) et (3), les
spécifications techniques de la machine peuvent être analysés au niveau des diagrammes des exigences
dans les liens (4). Les modes de fonctionnement sont définis par les diagrammes d’état dans le lien (5),
les flux d’énergie et les interfaces Homme-machine sont décrits au niveau des diagrammes de bloc
interne et des diagrammes paramétriques dans la relation (6). Une fois les limites des fonctions de la
machine définies, vient l’étape la plus importante de l’appréciation des risques. Il s’agit de procéder aux
modèles de SysML des phases de conception pour l’identification systématique des dangers, situations
dangereuses ou événements dangereux. Les diagrammes de cas d’utilisation dans les liens (7) et (8) dans
la figure 13 sont un ensemble des données clé car l’acteur humain est au centre de cette modélisation.
En effet, grâce aux diagrammes de cas d’utilisation, on détaille les tâches dévolues à chaque acteur du
système et plus particulièrement aux acteurs humains. On peut ainsi analyser les tâches qui peuvent
présenter un risque pour la sécurité de l’opérateur. Il permet de modéliser les actions qu’exercent l’un
sur l’autre, l’homme sur le système physique ou inversement, on cite par exemple « consigne d’effort »
et « les actions lors de montage et démontage » qui peuvent engendre des risques. En effet, ces
diagrammes permettent de décrire le comportement de l’utilisateur dans les différentes situations de vie
du système. En analysant les diagrammes de cas d’utilisation, le concepteur ou l’expert sécurité peut
préciser les risques dans lesquelles l’opérateur perd le contrôle sur la machine en particulier pour les
machines tenues à la main ou il se comporte d’une façon erronée par manque de concentration.

16
 (2)
« Data store »
(3)
« Data store »
Diagramme des
exigences (1)
Diagramme de
Définir la mission principale Définition des limites des structuration pour
fonctions de la machine l’identification des risques
« Data store »
Définir le contexte
Diagramme de contexte (14)

« Data store » (7)

Identification des dangers
« Data store »
Définir les utilisations (15)
Diagramme de cas
d’utilisation Diagramme de
(8) Estimation des risques structuration pour
« Data store »
Décrire les utilisations l’estimation des
Diagramme de cas risques
d’utilisation Evaluation des risques
Définir les besoins des parties
« Data store » « Data store »
prenantes (16)

Diagramme des Diagramme de

exigences structuration pour
Vérifier les besoins des (18)
l’évaluation des
(17)
Conception sûre risques
parties prenantes

« Data store »
(19)
Valider les besoins des parties Diagramme de
prenantes traitement des
« Data store »
(4) Mesures techniques de protection risques
Diagramme des
Définir les exigences exigences

A (20)

Analyser les exigences « Data store »

(9)
Réduction du risque par « Data store »
Diagramme de
informations pour l’utilisateur
Identifier les opérations séquence (22) Diagramme des
exigences
« Data store » (10)

(21)
Associer les opérations aux états Diagramme d’état (5)

A : exigence non associée à un

Définir l’architecture logique du système « Data store » besoin des parties prenantes ou à
Diagramme de définition de bloc un cas d’utilisation
B Vérifier l’architecture logique du système (11) B : liens de satisfaction de
« Data store » l’architecture logique vers les
exigences
Allouer les opérations aux sous-systèmes Diagramme de définition de
(12) C : liens de traçabilité de
bloc
composants vers les exigences
Définir les échanges avec les sous-systèmes « Data store »

Diagramme de séquence (6)

(13)
Définir la vue interne de l’architecture physique de système
« Data store »

Vérifier l’architecture physique de système Diagramme de bloc interne

C
Diagramme paramétrique

Valider l’architecture physique de système

Figure 13 : L’interopérabilité entre le processus de conception système de production et le processus d’appréciation des risques
suivant la norme ISO 12100

17
 Sur le diagramme de cas d’utilisation, le concepteur peut concevoir aussi le comportement réflexe
de l’utilisateur en cas de dysfonctionnement, de défaillance ou de panne pendant l’utilisation de la
machine comme il est montré sur la figure 14. Le concepteur peut alors identifier les risques qui sont
liés aux dysfonctionnements ou des pannes de la machine.

Figure 14 : Diagramme de cas d’utilisation montre le comportement de l’opérateur en cas de

dysfonctionnement

Donc les diagrammes de cas d’utilisation servent à spécifier les acteurs humains exposés aux dangers
et définir dans quels cas d’utilisation ils se trouvent. Les diagrammes de séquence dans le lien (9) du
schéma 13 permettent de représenter les interactions entre les utilisateurs et les composants d’un système
selon un point de vue temporel. En effet l’accent est mis sur la chronologie des envois des messages.
On peut montrer comment le concept de message dans le diagramme de séquence permet de définir les
risques liés à la sécurité humaine. En effet, un composant du système à l’origine d’un risque mais qui
n’échange aucun message avec les autres composants qui sont eux même en relation avec les acteurs du
système ne sera pas dangereux et ne nécessitera donc pas une analyse relative à la sécurité alors le danger
provient de l’échange de ces messages entre les composants. Donc, c’est l’analyse de ces messages que
nous proposons pour identifier les risques. En plus, le diagramme de séquence raffine les tâches qui sont
associées aux acteurs humains sous forme des séquences ordonnées. Et le concepteur peut identifier une
erreur de type une mauvaise exécution d’une action de diagramme de séquence, de sorte que les données
envoyées au système soient fausses. Cette erreur peut être l’origine d’un risque. Un exemple de ce type
d’erreur est la mise sous pression d’un système hydraulique, cette action est modélisée dans le
diagramme de séquence comme il est illustré dans la figure 15, où l’opérateur peut tourner par erreur un

18
bouton proche d’un manomètre. Il peut monter la pression du système jusqu’à un niveau trop important
ou insuffisant qui peut engendre un danger.

Figure 15 : Diagramme de séquence de système hydraulique

Le diagramme d’état- transition dans le lien (10) de la figure 13 est également utile lors des premières
étapes d’un processus de conception d’un système pour spécifier le comportement. Ce comportement se
traduit par le passage d’un état à un autre. Ce sont donc les transitions et l’état de transition qui retiennent
notre attention pour détecter les risques. Les états identifiés dans ce diagramme concernent le passage
de fonctionnement nominal de la machine à un état de maintenance, montage démontage ou
dysfonctionnements. En effet, ces états présentent les situations les plus fréquentes qui produisent des
accidents par exemple branchement et débranchement des circuits d’eau et circuits électriques. A partir
du diagramme de définition de bloc dans le lien (11) dans la figure 13, on est capable d’identifier les
sous-systèmes dans la brique bloc et analyser ses attributs et ses propriétés afin de déterminer le
comportement dangereux pour chaque composant. En effet, les dysfonctionnements et perturbations des
composants génèrent un fort potentiel de danger. Dans cette analyse des risques, on souhaite identifier
les phénomènes dangereux liés à l’énergie donc les diagrammes paramétriques et IBD dans le lien (13)
de la figure 13 sont une base de données importante. En effet, le diagramme de bloc interne sert à
modéliser les différents types d’énergie existants dans la construction de système de production et
permet ainsi à modéliser les interférences potentielles entre ces flux et l’acteur humain les
transformations d’énergie et les dissipations d’énergie, de cette manière le concepteur pourra définir
facilement les risques liés à la circulation de l’énergie dans le système. Cette proposition s’inspire de
travail de [Galvez,2016]. Il définit le Modèle Fonctionno-Structurel comme une modélisation d’un
système Homme-machine au travers de leurs échanges d’énergie. Cette modélisation est basée sur quatre

19
éléments : des frontières, des surfaces fonctionnelles, des liaisons et des associations internes. Elle est
étudiée dans sa thèse afin d’obtenir les potentiels des dangers liés aux flux d’énergie. En plus, le
diagramme de bloc interne permet de décrire la logique de connexion de flux entre blocs grâce au
concept de port. Ces ports permettent d’aller plus loin dans l’analyse des risques grâce à leurs attributs
spécifiques « direction » et « is conjugated » concernant le sens de passage des flux. La « direction »
(in, out ou inout) indique le sens de propagation des flux échangés, l’attribut « is conjugated » indique
si le sens du port est piloté par le composant ou celui auquel il est connecté. Si cette connexion entre les
composants du système peut introduire un risque, on est alors en mesure de connaître le sens de
propagation potentiel de ce risque. En obtenant ces informations à partir des modèles de SysML dans
les différentes étapes de processus de développement, le concepteur est capable de détecter au plus tôt
les phénomènes dangereux. La contribution de ce travail consiste à modéliser le résultat de cette phase.
Des diagrammes de structuration pour l’identification des risques sont proposés. Ils sont des exemples
de modèles d’information qui regroupent toutes les données qui sont illustrées à partir des modèles de
SysML relatifs à la conception de machine et qui résultent de la recherche des risques qui se fait en
réunissant les avis d’experts des différents spécialités rencontrés dans la création du système. Ainsi, ces
modèles d’information pour l’identification des risques sont expliqués dans la section suivante.

I. Les modèles d’information pour la structuration de l’étape d’identification des

risques
Les figures 16, 17 et 18 présentent des extensions de SysML pour structurer les phénomènes
dangereux identifiés dans l’étape identification des risques. Sur la figure 16 apparaît des nouveaux
stéréotypes qui soulignent l’origine de la construction d’un danger. Les stéréotypes « Condition
opérationnelle », qui est une traduction d’analyse des diagrammes de cas d’utilisation et des diagrammes
de séquence, et « Condition d’environnement », qui est le résultat d’analyse de diagramme de contexte
et de diagrammes de bloc interne, sont définis comme des éléments négatifs qui perturbent le
fonctionnement du bloc « Composant système » propre au langage SysML et en réagissant, produit
« L’effet système » néfaste qui est la cause directe du risque.

Figure 16 : Modèle d’information pour l’identification des risques

20
 On introduit sur la figure 17 une modélisation des risques liés aux flux d’énergie. Ce diagramme
modélise la source de flux d’énergie dans le système à travers le bloc « Composant système » et le type
d’énergie dans les stéréotypes « Energie principale » qui correspond aux flux utiles dont se sert le
système pour remplir ses différentes fonctions et « Energie secondaire » qui correspond aux dissipations
d’énergie sous forme (thermique, vibratoire, sonore…). L’analyse de propagation de ces types d’énergie
dans le système, dans le diagramme de bloc interne permet au concepteur d’identifier systématiquement
des phénomènes dangereux dans le stéréotype « Risque ».

Figure 17 : Modèle d’information pour l’identification des risques liés aux flux d’énergie

De la même manière, la figure 18 fait apparaître d’autres dimensions constitutives du risque qui sont
les stéréotypes « Erreur » et « Défaut système ». Dans le stéréotype « Erreur », on peut insérer les erreurs
possibles pour un message en analysant le diagramme de séquence issu de la phase de conception. On
cite par exemple un message appartient à une interaction et l’envoi non prévu de ce message au sein
d’une autre interaction est un type d’erreur que l’on trouve notamment lors de manipulation interface
Homme-système de commande de la machine. Ce type d’erreur peut créer un défaut système à l’origine
d’un risque comme il est illustré dans la figure 18.

21
 Figure 18 : Modèle d’information pour l’identification des risques

II. Les modèles d’information pour la structuration de l’étape d’évaluation des

risques
Une fois que le concepteur a identifié les risques, chaque risque doit être l’objet d’une évaluation et
estimation. Dans cette optique, un diagramme de structuration pour l’évaluation des risques est défini
comme le montre le lien (16) de la figure 13. Ce diagramme, représenté dans la figure 19, inclut encore
le stéréotype « Risque » sur lequel on définit les attributs « Gravité » et « Fréquence d’évènement » qui
sont les variables de la fonction de l’estimation des risques. Et une extension de SysML « Evénement
déclencheur » d’un accident qui peut être une mauvaise conduite de l’acteur dans le champ de danger.
Ce mauvais comportement de l’acteur est obtenu en analysant les diagrammes de cas d’utilisation et les
diagrammes de séquence. De même, le stéréotype « Conséquence » décrit les impacts négatifs de
l’accident sur la santé de l’utilisateur de système.

22
 Figure 19 : Modèle d’information pour l’évaluation des risques

III. Le modèles d’information pour le traitement des risques

Après l’appréciation des risques, le concepteur passe à l’étape la plus importante la réduction des
risques en mettant en œuvre des mesures pour protéger les opérateurs des risques existants. Pour traiter
ces risques, le concepteur modifie la construction de son système en créant des nouveaux retours dans
le processus principal de conception de système comme il est représenté par les lien (17) et (18) dans la
figure 13. En effet, le lien (18) montre l’ajout des nouvelles exigences de sécurité de l’opérateur, voire
des modifications des exigences déjà existantes et le lien (17) présente l’intégration des nouveaux
composants dans le système qui assurent des fonctions de sécurité de l’opérateur. Et l’exemple le plus
classique que l’on puisse mentionner est l’implantation d’un arrêt d’urgence qui provoque la sortie de
l’état de fonctionnement. Il convient alors de mettre à jour le diagramme de séquence en ajoutant le
message (arrêt d’urgence) envoyé par l’opérateur vers un composant du système et par suite la mise à
jour du diagramme d’état en ajoutant l’événement (arrêter en urgence) suivi d’un état (arrêt d’urgence).
En outre, le concepteur peut créer des nouveaux diagrammes paramétriques pour réduire les risques. Par
exemple, il peut produit une équation mathématique pour limiter l’énergie cinétique (masse m, et vitesse
V) des certains éléments de la machine qui sont à l’origine de risques mécaniques. Le concepteur peut
utiliser aussi le diagramme paramétrique pour préciser par exemple une distance de sécurité « e » et
l’angle « E » pour éviter la zone d’entraînement, qui est un risque mécanique, comme le montre la
figure20.

23
 Figure 20 : La distance de sécurité e et l’angle E pour éviter le risque d’entraînement [Sécurité
machine]

Pour structurer cette étape, la réduction du risque, un modèle d’information pour la gestion des
risques a été défini, représenté par le lien (22) dans la figure 13. Dans ce modèle de la figure 21, on
souhaite mettre en évidence comment le langage SysML sert à modéliser une solution de conception
soit pour réduire la gravité du risque ou réduire la fréquence d’occurrence du risque. Ce diagramme est
composé de stéréotype « Exigence sécurité » qui est lié au « Risque » à travers le lien « treat ». Cette
exigence de sécurité est affectée à « Exigence fonctionnelle » par le lien « satisfy ». A la fin, cette
exigence de sécurité sera associée à un bloc « Composant système » représentant un nouveau sous-
système comme une solution de conception permettant d’éliminer le risque. Outre le choix de conception
sûre, le concepteur peut réduire les risques en référant aux mesures techniques de protection ou réduction
du risque par information pour l’utilisateur qui sera documenté dans des diagrammes des exigences
comme il est montré dans le lien (22) dans la figure 13.

24
 Figure 21 : Modèle d’information pour le traitement des risques

IV. Etude de cas : la scie à viande, la machine à tronçonner

Cette section illustre les propositions de ce travail avec l’exemple de la scie en viande et de la
machine à tronçonner. La scie à ruban est largement utilisée pour couper viandes et os et elle est à
l’origine d’accidents souvent très graves comme des amputations. Elle est l’objet d’étude de [PJM, 2011]
pour ajouter des dispositifs de sécurité pour garder les doigts de l’opérateur intactes. En se basant sur le
démarche de rétroingénierie, je me place dans la position du concepteur pour étudier cette machine et
montrer la faisabilité de l’interopérabilité de processus de conception de système dans le cadre d’IS et
le processus d’appréciation et de réduction des risques. En se basant sur l’analyse fonctionnelle le [PJM,
2011] et la norme NF-EN-12268 qui répertorient l’ensemble des risques liés à l’utilisation d’une scie à
ruban alimentaire, je réalise dans un premier temps les différents diagrammes de SysML sur Lucidchart
pour structurer les étapes de conception comme il est défini dans la section II du chapitre 1. Le
diagramme de contexte de l’annexe 2 présente l’environnement et le milieu de la machine et définit
aussi les acteurs principaux de la scie à ruban « Opérateur » et « Opérateur de maintenance ». Et le
diagramme de cas d’utilisation de l’annexe 3 permet de définir les différentes tâches allouées à
l’opérateur, ce qui est fondamentale pour l’analyse de sa sécurité par la suite. Puis, l’étape
d’identification des risques est abordée. Le diagramme de séquence de la figure 22 fait apparaître une
situation dangereuse qui est la présence des mains de l’opérateur à proximité de la lame tranchante. Le
diagramme de séquence permet de détecter systématiquement la localisation temporelle et spatiale de
cette situation dangereuse.

25
 Figure 22 : Diagramme de séquence « Transformer la viande brute en morceaux de viande »

Ainsi, le concepteur présente le risque mécanique résultant de l’analyse du diagramme de séquence

en respectant le modèle d’information pour la réduction du risque défini dans la section I. Ce modèle est
proposé dans la figure 23.

26
 Figure 23 : Modèle d’information pour l’identification du risque de la scie à viande

Pour protéger l’opérateur des risques de coupure pendant le sciage, le concepteur définit dans le
modèle d’information pour la réduction des risques, présenté dans la figure 24, des exigences de sécurité.
Ces exigences sont à l’origine de conception des nouveaux composants système. Donc des sous cycle
en V de sous-système « Ensemble protecteur guide lame » et sous-système « Poussoir » se déroulent en
parallèle du cycle de développement principal de la machine Scie à viande. Les annexes 4,5,6, 7 et 8
illustrent la réalisation des certains diagrammes SysML qui supportent ces deux sous cycles en V.

27
Figure 24 : Modèle d’information pour la réduction des risques de la scie à viande

28
Figure 25 : Diagramme de bloc interne de la machine à tronçonner

29
 Figure 26 : Modèle d’information pour l’identification des risques liés aux flux d’énergie de la machine à tronçonner

Ensuite, un travail est mené sur la machine à tronçonner. Elle est située au fond du secteur forge du laboratoire LCFC. Ce travail se focalise sur la traduction
d’une modélisation fonctionnelle énergétique réalisée précédemment dans un projet de LC2S [PJM, 2014] en un diagramme de bloc interne. Ce diagramme,
présenté dans la figure 25, modélise les données des flux énergétiques de conception. L’analyse de ce diagramme fait apparaître une interface énergétique entre
l’opérateur et le disque. En effet, le disque ne transmet pas que de l’énergie mécanique vers l’opérateur, mais aussi de l’énergie thermique, l’énergie sonore et
l’énergie vibratoire. Cela signifie que l’opérateur est exposé aux phénomènes dangereux tel que « La rotation du disque pendant la découpe risque de sectionner
les doigts de l’opérateur ». Ces risques sont présentés dans la figure 26 en respectant le modèle d’information d’identification des risques liés aux flux d’énergie.
Puis, le concepteur doit effectuer des modifications pour éviter ces types des risques. Il peut mettre en place un dispositif chargé d’éloigner l’utilisateur de
la source du risque ou supprimer la source de danger. Par exemple, pour traiter les risques liés au composant « Disque » et « L’arbre de transmission », il
introduit un nouveau composant « Capot mobile » pour éviter tout contact entre l’opérateur et ces composants. Ces modifications sont illustrées dans le modèle
de réduction des risques dans la figure27. Et les annexes 9,10, 11 et 12 proposent d’autres modèles d’information pour l’identification et la réduction des risques
liés aux flux d’énergie de la machine à tronçonner qui résultent d’analyse de diagramme de bloc interne de la figure 25.

30
 Figure 27 : Modèle d’information de réduction des risques liés aux flux d’énergie de la machine à tronçonner

V. Synthèse des cas d’étude

Cette section a présenté une application de la démarche d’interopérabilité entre le processus de conception et le processus d’appréciation des risques. La
modélisation a permis d’effectuer une analyse de risque des différents messages lors de réalisation de diagramme de séquence de la machine scie à viande. Les
modèles d’information pour l’identification des risques et pour l’évaluation sont validés. Cette étude de cas « la machine scie à viande » se base sur le démarche
de rétroingénierie et par conséquent, elle dépend de disponibilité des documents, qui détaillent la conception de la machine. On a souhaité réaliser une analyse
des risques liés aux flux d’énergie mais l’absence du schéma cinématique de la machine scie à ruban l’en empêche. Donc, cette analyse est réalisée sur la
machine à tronçonner en se basant sur le schéma cinématique et la modélisation fonctionnelle énergétique de projet [PJM, 2014]. Cet exemple a permis de
valider le modèle d’information pour l’identification des risques liés aux flux d’énergie et le modèle d’information de réduction des risques liés aux flux
d’énergie. La principale difficulté pour la réalisation de ces deux études de cas est l’absence des documents détaillant leurs conceptions. L’approche n’a pas
été appliqué à la conception logicielle. Ces deux cas d’étude ne présentent pas une interface Homme-ordinateur qui peut être modélisée par des diagrammes de
séquence. Et par suite ils sont analysés pour détecter les risques qui résultent des erreurs tels que « exécution d’un ou plusieurs messages dans un ordre
incorrect » ou « Envoi ou réception d’un message en dehors des limites de temps spécifiés ». Ce qui limite ces cas d’étude.

31
 Conclusions
La dernière partie de ce rapport propose une synthèse du travail effectué, une évaluation des objectifs
atteints par rapport à la problématique initiale et ouvre les perspectives raisonnables atteignables à court
terme et à plus long terme.
Le premier chapitre a permis d’établir les définitions fondamentales sur lesquelles les propositions
de ce travail sont construites. Le concept d’IS et le cycle de développement en V sont définis comme la
meilleure alternative pour exprimer les exigences système, définir les éléments logiciels et non logiciels
(mécanique, électrique, hydraulique…), écrire les équations physiques, préciser les flux continus
(matière, énergie…) lors des phases de conception de système de production. Les diagrammes du
langage SysML pour la représentation des constructions des systèmes complexes sont présentés. Par
conséquent, un processus de conception de système dans le contexte d’IS supporté par le langage SysML
est défini. Grâce aux diagrammes SysML, ce processus permet l’identification des besoins et exigences
système, l’identification de l’architecture fonctionnelle et l’identification de l’architecture des
composants système et les relations entre eux. Parallèlement, les étapes de processus d’identification et
réduction des risques suivant la norme ISO 12100 ont été décrites.
Ainsi, la définition de processus de conception de système dans le périmètre d’IS et de processus de
gestion des risques a conduit naturellement à créer un diagramme d’activité qui permet au concepteur
d’obtenir les connaissances suffisantes pour faciliter la réalisation du processus d’identification et
réduction des risques. Dans ce travail, la gestion des risques est intégrée dans le processus de définition
et développement de système non pas comme une étape de vérification obligatoire mais comme un
processus interactif qui produira des exigences de sécurité qui doivent faire l’objet des sous processus
de conception des moyens de protection de l’utilisateur ou des solutions techniques ou des structures
fonctionnelles. Et la source d’information initiale du processus d’appréciation et réduction des risques
est les modèles SysML issus des étapes de conception du système. Le processus de gestion n’intervienne
pas uniquement en début de conception de système mais à des étapes différentes. La gestion des risques
progresse donc avec l’évolution de développement de la machine. La contribution de ce travail concerne
ensuite la proposition des modèles d’informations permettant de structurer les données techniques
échangées entre les étapes d’identification des risques et le processus de conception du système. Ils
incluent des concepts propres à SysML et des nouveaux concepts importants pour la problématique de
ces travaux à savoir « Risque », « Evénement déclencheur », « Erreur », « Défaut système »,
« Accident » et « Conséquence ». Ici, on doit mentionner que les stéréotypes en rouge, qui sont
représentés graphiquement dans les modèles d’information, résultent de la recherche des risques qui se
fait en réunissant les avis d’experts des différents spécialités rencontrés dans la création du système lors
de l’analyse des diagrammes SysML du processus de conception et ceux en bleus sont des stéréotypes
propres au langage SysML. Le « Modèle d’information pour l’identification des risques » repose sur
une analyse des composants système des diagrammes SysML. Et le « Modèle d’information pour
l’identification des risques liés aux flux d’énergie » qui se base sur une analyse énergétique de système
proposée par Galvez [De Galvez,2016] à l’aide de diagramme de bloc interne lors de la phase de
conception. Ces modèles d’information pourront être utilisés par les ingénieurs système et ceux de
sécurité. Par la suite, nous avons montré la faisabilité de cette méthodologie sur deux exemples : la
machine scie à viande et la machine à tronçonner. Ces cas d’étude montrent que la rigueur
d’identification des risques dépend de la précision des modèles de SysML issus de processus de
conception de système. En effet, le langage SysML est un langage « centré humain » par la possibilité
de représenter les acteurs humains dans la plupart des diagrammes. A travers la modélisation du système
au moyen des diagrammes de cas d’utilisation et diagramme de séquence, on conçoit le comportement

32
de la machine en contact avec l’utilisateur et on définit aussi les différentes tâches allouées à l’acteur
humain. Le diagramme de séquence, comme il est montré dans le chapitre 2, permet de détecter une
localisation temporelle des risques. En plus le diagramme de bloc interne permet de modéliser la
propagation des flux énergétiques dans le système. Donc, en se basant à ces informations, le concepteur
est capable d’identifier les phénomènes dangereux associés aux conditions dans lesquelles l’opérateur
utilise la machine et les phénomènes dangereux mécaniques ou électriques ou thermiques. Il faut donc
maximiser les diagrammes de SysML analysés pour l’identification des éléments en amont qui sont à
l’origine des risques.
Ainsi, les travaux présentés dans ce mémoire ont permis de couvrir une partie importante des
objectifs définis par la problématique initiale. Cependant, il faut noter que le diagramme d’activité qui
guide notre contribution est complexe et nécessite d’être automatisé pour faciliter les tâches des
concepteurs.
L’objectif d’identifier tous les risques du système en se basant uniquement sur les modèles de
SysML est atteint partiellement. Par exemple, lors d’étude de la machine scie à viande, je n’ai pas suivi
uniquement la démarche proposée dans le chapitre 2 mais également la Bête à cornes de la méthode
APTE et la norme NF-EN-12268 afin de définir les risques mécaniques de la machine.
De surcroit, dans la section d’application de la démarche proposée, le logiciel Lucidchart en ligne
est utilisé pour concevoir les différents modèles de SysML. Cet outil est insuffisant pour créer une bonne
qualité graphique permettant la communication facile entre les concepteurs et l’expert sécurité. Cet outil
ne permet pas de créer un nouveau package que nous appelons « Extension SysML pour l’appréciation
et réduction des risques ». Ce package contient les nouveaux stéréotypes à ajouter à SysML tels que
ceux proposés dans le chapitre 2. Donc, pour perspectives des futurs travaux, il est utile d’utiliser un
outil de modélisation qui offre un environnement graphique dynamique pour construire des diagrammes
complexes et hautement connectés d’une part et introduire le nouveau package d’autre part.
La structuration des modèles d’information pour l’identification des risques repose sur une
compréhension par exemple de la méthode analyse des effets et défauts « FMEA » de la thèse
[Faîda,2014]. Cette méthode comporte ces termes : « Identifiant », « Function », « Failure Mode »,
« Cause », « Local effects », « System Effect », « Severity », « Occurrence », « Detectability »,
« Criticity », « Detection Method », « Corrective Action ». Alors, pour les perspectives, il est utile
d’intégrer des outils méthodologiques tels que AMDEC ou HAZOP dans la démarche de ce master afin
de fournir un vocabulaire du risque stable et non ambigu.
Afin de fournir le modèle d’information d’identification de risques, on a étudié, dans le
fonctionnement normal, les diagrammes de l’architecture des composants afin de déduire les propriétés
néfastes ou les conditions opérationnelles ou environnementales qui conduisent à des risques. Et de cette
manière, le bloc « Composant Système » se trouve au centre du modèle d’information. Dans les
prochains travaux, on propose de réaliser une analyse purement fonctionnelle des diagrammes de SysML
issus des étapes de conception de système. Cette analyse permet de construire un modèle reflétant le
comportement dysfonctionnel du système, et dans ce modèle dysfonctionnel on cherche à identifier les
risques qui peuvent menacer la santé de l’opérateur. Par conséquent, on est apte à créer le stéréotype
« Fonction » qui est au cœur d’un autre modèle d’information d’identification des risques.

33
 Annexes

Annexe 1 : Tableau de notation des critères de choix d’outil de modélisation

Note Appréciation Explication

1 Tout à fait insatisfaisant Le critère n'est pas abordé dans la description de l'outil

2..4 Insatisfaisant Le critère d'évaluation est traité de manière inadéquate ou partiellement

5..7 Globalement satisfaisant La description de l'outil répond d'une manière adéquate au critère du choix de l'outil de modélisation

8..10 Très satisfaisant Le critère du choix de l'outil est bien clarifié et l'outil offre d'autres intérêts pour améliorer le critère

1 : Rational 2 : Magic 3 : Sprax 4 : Pradigm 5 : SysML 6 : Modilo 7 : CORE 9 8 : Cameo 9 : Innoslate 10 : Lucidchart
Rhapsody Draw Entreprise visuel designer System
Designer Architect Modeler

Les critères de choix d’outil de modélisation 1: 2: 3 : 4 : 5 : 6 : 7 : 8 : 9 : 10 :

1 : Respecter les standards du SysML 9 9 8 8 8 9 9 8 8 8
2 : Une capacité graphique puissante : Apporter une très grande souplesse pour créer, 1 9 2 2 1 1 8 1 1 3
Associer, connecter, organiser et manipuler les éléments d’un diagramme du SysML,
Personnaliser l’apparence des Stereotypes des diagrammes SysML (couleur, largeur, longueur, police du texte)
3 : L’outil doit permettre de sélectionner des Stereotypes (testcase, block, use case) d’un diagramme bien précis sans 2 1 1 2 1 1 1 1 1 1
avoir besoin d’importer le modèle entier et il permet aussi de faire des liens d’allocation et de traçabilité entre eux. Il
permet d’intégrer aussi des nouvelles Stereotypes tel que « risque », « défaut système », « erreur » pour construire des
modèles de structuration du processus de gestion du risque.
4 : Coût limité 3 3 4 6 9 8 8 2 8 8
5 : Le logiciel permet de traduire les exigences sécurité et les risques identifiées dans la Stereotype « Requirement » du 1 1 1 8 1 8 1 6 1 1
SysML sous forme tabulaire

6 : L'outil est capable de faire la vérification de la sémantique SysML automatiquement afin de faciliter la création de 1 8 1 1 1 1 1 1 1 1
modèle valide
7 : Cohérence des modèles : toute modification d’un élément d’un diagramme est automatiquement propagée dans tout le 8 1 1 1 1 1 8 8 1 1
modèle, avec pour résultat un modèle cohérent.
8 : Simulation des modèles 9 1 6 1 1 1 8 8 8 1
9 : Partager les modèles de conception SysML et les diagrammes SysML pour la structuration du processus du gestion du 7 9 8 7 1 1 8 7 1 8
risque entre les concepteurs et les experts de sécurité dans un format texte ou en ligne

34
 Annexe 2 : Diagramme de contexte de la scie à viande

Annexe 3 : Diagramme de cas d’utilisation de la scie à viande

35
 Annexe 4 : Diagramme de contexte de dispositif de protection

Annexe 5 : Diagramme des exigences de dispositif de protection

36
 Annexe 6 : Diagramme d’état de dispositif de protection

Annexe 7 : Diagramme de définition de bloc de sous-système poussoir tiroir

37
Annexe 8 : Diagramme de séquence de sous-système poussoir tiroir

38
Annexe 9 : Modèle d’information pour l’identification des risques liés aux flux d’énergie de la machine tronçonneuse

39
Annexe 10 : Modèle d’information pour la réduction des risques liés aux flux d’énergie de la machine tronçonneuse

40
Annexe 11 : Modèle d’information pour l’identification des risques liés aux flux d’énergie de la machine tronçonneuse

Annexe 12 : Modèle d’information pour la réduction des risques liés aux flux d’énergie de la machine tronçonneuse

41
 Références bibliographiques

[De Galvez,2016] : Nicholas de GALVEZ, 2016. Sécurité des machines méthodologie

d’identification systématique des phénomènes dangereux en conception. ENSAM.
[David,2009] : Pierre DAVID, 2009. Contribution à l’analyse de sûreté de fonctionnement
des systèmes complexes en phase de conception : application à l’évaluation des missions
d’un réseau de capteurs de présence humaine. Université d’Orléans.
[Eureka] : Le portail de l’enseignement supérieur de la recherche et de l’innovation en
Lorraine. LCFC : Laboratoire de Conception, Fabrication et Commande. Eureka. Available
from http://eureka.lorraine.eu/jahia/Jahia/pid/1701?view_id=19109

[Pascal, 2015] : Pascal Roques, 2015. Modélisation de systèmes complexes avec SysML.
France : Editions Eyrolles
[Guillerm, 2011] : Romaric Guillerm ,2011. Intégration de la Sûreté de Fonctionnement
dans les Processus d'Ingénierie Système

[ISO, 12100] : Norme européenne, 2010, NF EN ISO 12100, Sécurité des machines :
principaux de conception, appréciation du risque et réduction du risque
[Sécurité machine] : Guide : Sécurité des machines : Six étapes pour une machine sûre.
Available from
[Faîda,2014]: Faîda Mhenni, 2014. Safety Analysis Integration in a Systems Engineering
Approach for Mechatronic Systems Design. École Centrale Paris

[Guiochet, 2003] : Jérémie Guiochet, 2003. Maîtrise de la sécurité des systèmes de la

robotique de service - Approche UML basée sur une analyse du risque système. L’Institut
national des sciences appliquées de Toulouse
[PJM, 2011] : Projet métier, 2011, Charles Fabien, Chen Yifan, Fargeix Romain, Poggiolini
Quentin, Saulnier Raphael, Virlouvet Florian, Conception d’un système de protection pour
scies à ruban alimentaires, ENSAM-INRS
[NF EN 12268] : Norme européenne, 2014, NF EN 12268. Machines pour les produits
alimentaires - Scies à ruban - Prescriptions relatives à la sécurité et à l'hygiène
[PJM, 2014] : Projet métier, 2014, DELPANQUE Ulysse HENRY-LHEUREUX Thomas
PHETSINORATH Damien SOUDY Bryan. Modélisation énergétique de machine,
ENSAM-INRS

42