Création d'un atelier d'ingénierie en Sûreté de … · 2. e. Congrs de matrise des risques et...

20e Congrès de maîtrise des risques et de sûreté de fonctionnement - Saint-Malo 11-13 octobre 2016

Création d'un atelier d'ingénierie en Sûreté de Fonctionnement

Creation of a Dependability Engineering workbench

Gérald Hardy Thales Global Services19-21 Avenue Morane Saulnier 78140 Vélizy-Villacoublay Tél : +33 (0) 1 40 83 26 [email protected]

Michel Giraudeau Thales Systèmes Aéroportés 2 Avenue Gay Lussac 78851 Elancourt Cedex Tél : +33 (0) 1 34 81 49 33 [email protected]

Résumé

Cette communication présente la démarche entreprise par le groupe Thales concernant la construction d’un atelier d’ingénierie du service client, c’est-à-dire un ensemble de logiciels, intégrés entre eux ainsi qu’avec les autres logiciels de l’entreprise, et proposant des fonctionnalités complémentaires comme la gestion de la donnée. Cet atelier couvrira, à terme, la réalisation des analyses prévisionnelles de Fiabilité, Maintenabilité, Disponibilité/ Cout Global de Possession, Testabilité (FMDT) ainsi que les études de Retour d’Expérience.

Summary

This communication presents the initiative undertaken by Thales Global Services concerning the creation of a Customer Services Engineering workbench, i.e. a set of software, integrated between them as well as with the other Enterprise tools, and proposing additional features such as the data management. This workbench will be able to perform Reliability, Availability / Life Cycle Cost, Maintainability, Testability ( RAMT) studies as well as of Feedback analysis.

1 Problématique

Thales, comme tous les grands industriels, est amené à concevoir et fournir des systèmes de plus en plus complexes et à en assurer un haut niveau de services sur plusieurs dizaines d’années. Thales doit spécifier, concevoir, développer, vérifier,valider, produire et intégrer des systèmes en un minimum de temps et en assurer le support, voire parfois l’exploitation, jusqu’à son démantèlement.

Figure 1: Exemple avec le projet BALARD : le « Pentagone à la française »

Ceci à des conséquences sur la manière de travailler des ingénieurs en Sûreté de Fonctionnement (SdF) du Groupe, car ayant un rôle transversal, ils doivent intervenir plus tôt dans la phase de conception, être plus réactifs en cas d’évolutions /changements et maintenir leurs études à jour durant toute la vie des systèmes/produits. En effet, du fait que Thales soit en charge du soutien, il est important de suivre les performances de celui-ci afin de proposer des corrections, des évolutions, adapter les offres de service etc... Ainsi, il faut commencer les études très en amont (phase de faisabilité ou de conception préliminaire) c’est-à-dire lorsque les données sont incomplètes et changeantes, analyser les demandes d'évolution et de correction, mettre à jour les rapports d’étude en conséquence jusqu’à la fin de l’exploitation du système. Le problème est que la mise à jour des études a un coût…

Communication 7E-1 /3 page 1/9


En plus de ces nouveaux « challenges », il était constaté des difficultés dans l’archivage des données et l’échange des données d’un métier à l’autre, ce qui générait de la non-qualité. Ceci est lié à l’absence de référence des données d’entrée ainsi qu’une gestion de configuration des études SdF « perfectibles ». Ainsi, il n’était pas rare de constater des écarts entre différents documents livrés au client de Thales, ce qui engendrait une insatisfaction de celui-ci et une reprise des études pour mise en cohérence (par exemple, incohérence entre les données de fiabilité de l’étude de fiabilité et de l’étude de disponibilité, incohérence entre les temps d’échange de l’analyse de disponibilité et de l’Analyse des Tâches de Maintenance etc.).

Un autre problème est la multitude d’outils différents utilisés dans le groupe Thales pour réaliser les études SdF. Cela a pour effet des coûts d’achat de licence, de support et de développement d’interface spécifique très lourds pour les entités du fait que ces coûts ne soient pas mutualisés au niveau du groupe.

Suite à ce constat, il a donc été identifié différents axes d’amélioration, au niveau groupe, comme la réduction du coût des études d’ingénierie, dont la SdF fait partie. Cet axe d’amélioration fait partie du programme d’amélioration de la profitabilité et de l’efficacité des services rendus aux clients de Thales (Ambition 10).

Ces divers problèmes ont obligé Thales à trouver des solutions pour aider les ingénieurs SdF à travailler de manière plus collaborative avec les autres domaines d’ingénierie, partager les mêmes configurations de référence afin d’échanger plus facilement les données. Cela passe aussi par la sélection de logiciels SdF uniques au niveau du groupe Thales afin de limiter les couts d’intégration.

Cependant, il ne s’agit pas de tendre vers une cohérence totale et en temps réel de tous les documents techniques mais de maitriser ces écarts. Le but étant de répondre aux questions suivantes :

• Est-il pertinent que je mette à jour mon étude maintenant ? plus tard ? • Quel est la quantité de modifications que je dois prendre en compte ? • Les modifications sont-elles majeures ? mineures ?

2 Description du projet CSE workbench

Face à cette problématique, Thales a décidé de lancer un projet de création d’un atelier d’ingénierie du Service Client (Customer Service Engineering workbench). Celui-ci couvrira les domaines de la sûreté de fonctionnement (c’est-à-dire la Fiabilité, Maintenabilité, Disponibilité et Coût Global de Possession, Testabilité ainsi que le RETour d’EXpérience), l’Analyse du Soutien Logistique (ASL), la documentation électronique, le réapprovisionnement ainsi que la Formation.

Pour chacun de ces domaines, il sera choisi un, et un seul, logiciel du commerce. Il n’est plus envisagé de développement d’outils spécifiques comme cela a été fait par le passé.

Les logiciels seront intégrés en se basant sur le processus d’ingénierie des services et en prenant en compte la manière de travailler des ingénieurs du groupe. L’atelier sera aussi interfacé avec les autres ateliers ou logiciels du groupe. Il sera complété par un ensemble de fonctions transverses comme :

• La gestion des données, • La création de base de référence, • L’analyse d’écarts entre deux références, • La gestion des demandes d’évolutions, • La gestion des accès et des droits.

3 Méthode mise en place

Cette partie présente de manière synthétique la méthode mise en place dans le but de spécifier l’atelier CSE WB.

3.1 Modélisation des processus et des fonctions La méthode mise en place est la suivante :

1. Modélisation de l’environnement du processus d’ingénierie des services 2. Modélisation du processus d’ingénierie des services lui-même 3. Modélisation de ce processus complet dans le temps 4. Modélisation du processus de chacun des domaines, par phase 5. Modélisation des fonctions par domaine



Chaque modèle a été créé avec l’outil Archimate. Ce logiciel est un langage de modélisation pour les architectures d’entreprise. Il fournit les instruments permettant aux architectes de décrire, analyser et visualiser les relations entre différents domaines d’activité, d’une manière non-ambiguë.

3.1.1 Modélisation de l’environnement du processus d’ingénierie des services Le but de cette modélisation « très haut niveau » est d’identifier avec quelles autres activités (« processus » dans Archimate) du référentiel qualité, l’atelier CSE WB devra travailler et donc, à terme, s’interfacer. Ce modèle montre aussi les différentes parties prenantes, internes (par exemple l’ingénieur ASL) et externes (ingénieur matériel).

Figure 2: Environnement du processus d’ingénierie des services

3.1.2 Modélisation du processus global d’ingénierie des services A ce niveau de modélisation, le but est de définir les flux entre les différents domaines de l’atelier mais aussi avec ceux en dehors de celui-ci. On retrouve ainsi une logique de déroulement « générique » des processus (faire les études de Fiabilité, puis Maintenabilité etc…) ainsi que tous les liens avec les autres logiciels d’ingénierie (Ingénierie système, conception mécanique, gestion de configuration etc.).



Figure 3: Processus d’ingénierie des services

3.1.3 Modélisation du processus complet dans le temps La modélisation précédente correspond à une vue générale des activités et de leur séquencement. Cependant, il est à noter que ce processus n’est pas intégralement appliqué à chaque phase de vie du projet. Par exemple, dans une phase de réponse à appel d’offre, il n’y a pas d’activités de documentation électronique ou de formation. Des études préliminaires de SdF sont, au mieux, réalisées.

Ainsi une description des différentes phases d’un projet a été réalisée et une corrélation a été faite avec la modélisation précédente. Cette modélisation est très importante car elle permet de vérifier que la modélisation globale est cohérente avec toutes les sous-activités mis en œuvre pour chacune des phases du projet.

La représentation ci-dessous décrit le processus associé à la phase « Allouer les performances et réaliser les activités avec les données allouées ».



Figure 4: Extrait du processus de la phase 2 “Allouer les performances et réaliser les activités avec les données allouées”

3.1.4 Modélisation du processus de chacun des domaines, par phase Cette modélisation a pour but de détailler les processus identifiés dans le modèle précédent, c’est-à-dire les fonctions de chacun des processus par phase. Ce travail a été réalisé à partir des guides métiers présents dans le référentiel qualité Thales. Il en résulte, par exemple, les fonctions supportant le processus de fiabilité réalisées durant la phase N°2. On obtient donc le modèle ci-dessous.

Figure 5: Fonctions du processus fiabilité de la phase 2 “Allouer les performances et réaliser les activités avec les données allouées”

3.1.5 Modélisation des fonctions par domaine Dans ce dernier niveau de modélisation, on rassemble toutes les fonctions du domaine afin d’identifier les fonctions propres au domaine, de celles qui seront couvertes par la fonction « intégration » de l’atelier. Cela permet donc de commencer à spécifier les « exigences » du logiciel de fiabilité ainsi que celles spécifiques au logiciel d’intégration.

Ci-dessous les fonctions relatives au domaine fiabilité :



Figure 6: Fonctions du processus fiabilité (toutes phases confondues)

Sur la gauche (en jaune), on retrouve les fonctions attendues par le logiciel de fiabilité prévisionnelle et sur la droite, les fonctions de la partie intégration de l’atelier.

Dans la partie bleue, la fonction « calculer les données de fiabilité » est détaillée en sous-fonctions (en vert). A chaque sous-fonction est associée une ou plusieurs exigences fonctionnelles, indiquant son numéro, le domaine, la version de l’atelier et l’intitulé de l’exigence.

3.1.6 Définition des concepts opérationnels Il est ressorti de ces modélisations un rapport de concept opérationnel (Operational Concept Document) décrivant les différents cas d’utilisation, les parties prenantes, le processus de haut niveau ainsi que les interfaces et flux de données associées.

3.2 Identification des fonctions transverses Les fonctions communes ou transverses identifiées durant la phase de modélisation ont été collectées et redéfinies comme suit :

• Gérer les données de CSE WB de manière collaborative,

o Echange de donnée d’ingénierie avec le logiciel de gestion de configuration de l’entreprise. Il est prévu de pouvoir importer les arborescences techniques et exporter/stocker les livrables du CSE WB.

o Gestion des demandes d’évolution avec le logiciel de gestion de configuration de l’entreprise. Il est prévu d’émettre des demande d’évolution et de recevoir des demandes d’évolutions/modifications faites sur le produit/système.

• Travail collaboratif entre les utilisateurs de l’atelier CSE WB.

o Transformation de l’arborescence technique en arborescence logistique.

Les éléments échangeables de l’arborescence technique sont dupliqués pour former l’arborescence logistique. Toute modification de l’une sera reportée sur l’autre. Exemple : décomposition d’un équipement en différents éléments échangeables reportée dans l’arborescence technique, nouvel élément de l’arborescence technique reporté dans l’arborescence logistique, etc.

o Utilisation des principes de « référence » et de « version » des données permettant la parallélisation des activités.



A partir d’une référence, chaque activité (ex : étude de fiabilité, ASL) sera initialisée et livrera une version « intermédiaire ». Ceci permet un travail en parallèle, sans avoir à attendre que l’activité précédente soit terminée pour commencer la suivante. Pour une livraison au client, toutes ces versions seront rassemblées. Exemple : rapport de fiabilité V4, rapport de maintenabilité V2, rapport de disponibilité V1)

o Identification des écarts entre deux versions.

Chacune des versions collectées sera analysé afin d’identifier des écarts. L’analyse indiquera les écarts entre les deux références, ainsi que les changements effectués par chacune des activités sur une même référence. Exemple : sur quelle donnée l’analyse de disponibilité s’est basée ? Sur le rapport de fiabilité V4 ? V3 ? V2 ? V1. Sur le rapport de maintenabilité V1 ? V2 ?

o Analyse d’impact (quelles sont les activités touchées par cette modification).

En cas de modification de la base de référence, cette analyse indiquera les changements effectués sur l’arborescence ainsi que sur les données attachées aux éléments. Exemple : l’arborescence technique est passée de V3 à V4, quelle est l’impact sur l’arborescence logistique ? Les études de fiabilité ? De disponibilité ? etc

o Gestion des demandes d’évolution entre les acteurs de l’atelier (par exemple entre l’ingénieur SdF et ASL).

Dans le cas où le responsable d’une activité demande à modifier une donnée, une demande ou un avertissement est envoyé aux personnes concernés. Ces personnes pourront, ou non, accepter la modification. Exemple : le responsable ASL demande à modifier un temps d’échange. Cette demande doit être acceptée par le responsable maintenabilité car elle a un impact sur le calcul du MTTR et par conséquence sur la disponibilité.

o Vérification de la qualité des données générées (réalisation de test de cohérence).

Ces tests de cohérence permettent de détecter les éventuelles incohérences entre les éléments d’une même référence. Exemple : le plan de maintenance utilise des données de fiabilité différentes de celle de l’étude de fiabilité ; la version des données est différente.

o Génération de rapport sous un format défini par l’utilisateur. o Gestion des droits d’accès et des profils.

Ces fonctions seront portées par un outil de gestion de configuration des données du style Product Life Management (PLM), et celui-ci sera propre à l’atelier.

Cette liste d’exigences transverses a été validée lors de différentes rencontres avec des opérationnels en charge de départements d’ingénierie du service client.

3.3 Définition des exigences fonctionnelles A partir des exigences fonctionnelles identifiées lors de la modélisation, une liste a été initialisée et a été revue par le groupe de travail « Outils et Données de Fiabilité » du groupe Thales. Le but étant de confronter cette liste aux besoins « réels » des ingénieurs SdF du groupe.

La liste des exigences a été complétée afin de prendre en compte l’expérience acquise sur les logiciels actuellement utilisés ou évalués par d’autres entités du groupe. Cette tâche est importante car elle permet de confronter la prévision aux besoins réels des futurs utilisateurs. Elle assurera donc une meilleure adéquation du logiciel par rapport aux spécificités du groupe Thales ainsi qu’une meilleure appropriation par les utilisateurs.

Devant la diversité des domaines d’activités du groupe (avionique, ferroviaire, radar, optronique etc.) , il a été demandé au groupe de travail de pondérer chacune des exigences afin de distinguer les exigences majeures des mineures.

3.4 Choix des logiciels du commerce Suite à la définition des exigences, un appel d’offres a été lancé et plusieurs fournisseurs de logiciels spécialisés en Sûreté de Fonctionnement ont été contactés.



Il leur a été transmis la liste avec toutes les exigences fonctionnelles, techniques et d’intégration/ déploiement. Après l’analyse des réponses des fournisseurs, des démonstrations leur ont été demandées sur certaines exigences majeures. Suite à ces présentations et aux réponses des fournisseurs, le choix du logiciel a été réalisé par plusieurs experts du groupe Thales, en prenant en compte les aspects fonctionnels, techniques et financiers.

4 Premiers résultats

Pour des raisons budgétaires, il a été décidé de développer l’atelier CSE WB en deux phases successives, en fonction des priorités fixées par les Directeurs Ingénierie du Soutien du Groupe.

Une première phase, allant de janvier 2015 à fin 2017, comprenant l’intégration des domaines suivants :

• La fiabilité prévisionnelle, • La disponibilité avec le Coût Global de Possession, • L’analyse de Retour d’Expérience, • L’ASL, • La documentation électronique (incluant l’approvisionnement).

Une deuxième phase, post 2017, comprenant l’ajout des domaines suivants :

• La fiabilité opérationnelle, • La maintenabilité, • La testabilité, • La formation.

De plus, il a été préféré de déployer tout d’abord les outils en mode autonome (sans intégration). Cela permet de fournir plus rapidement une solution commune pour les entités du groupe ayant un besoin urgent en termes de logiciels. Cela permet aussi aux utilisateurs de commencer à appréhender les logiciels seuls, sans la surcouche intégration qui nécessitera une conduite du changement plus importante.

Ceci est résumé dans le planning ci-dessous :

Figure 7: Planning de déploiement

Au stade actuel, les logiciels de fiabilité prévisionnelle, disponibilité, Coût Global de Possession (CGP), ASL et intégration ont été sélectionnés.

• Le logiciel de fiabilité prévisionnelle sera intégré, à terme, avec les outils de gestion de configuration, d’analyse thermique et la base de données des composants électroniques du groupe Thales. Il sera bien entendu intégré avec les autres outils de l’atelier.



• Concernant les logiciels de calcul/simulation de disponibilité et CGP, ils seront principalement intégrés avec ceux relatifs à la Fiabilité, Maintenabilité ainsi que l’Analyse du Soutien Logistique (pour le partage de l’organisation de soutien) et avec les outils d’ingénierie système pour la description du système d’intérêt.

• Pour le logiciel d’analyse du Retour d’Expérience, il sera interfacé avec notre portail client « Customer On line » (qui offre aux clients de Thales la possibilité d’ouvrir des incidents, commander des pièces de rechange, suivre les équipements en réparation, etc.) et l’outil de gestion de la maintenance (MMS).

Concernant les logiciels de disponibilité et Coût Global de Possession, il a été dérogé à la règle car nous avons finalement retenu deux outils. La raison en est que le logiciel correspondant le mieux à nos besoins était celui avec des coûts de licence les plus élevés. Un deuxième outil, moins performant mais moins cher, a dont été retenu pour les entités moins exigeantes ou ne souhaitant pas y associer plus de ressources.

Les logiciels de fiabilité prévisionnelle, disponibilité, Coût Global de Possession ont été validés (conformité du logiciel aux exigences fonctionnelles, hormis les non-conformités déclarés par les fournisseurs) et un kit d’installation a été créé (afin de vérifier que le logiciel peut être installé sur les postes informatiques standardisés du groupe, qu’il ne présente pas de failles de sécurité etc.).

5 Retour d’expérience

Même si le projet n’est pas terminé, on peut déjà tirer certaines leçons par rapport à la création d’un atelier d’ingénierie :

• Il est préférable d’avoir au préalable un document décrivant, de manière détaillée, le processus que l’on désire « automatiser ». Dans notre cas, le processus d’ingénierie du service client n’était pas vraiment partagé au niveau du groupe Thales. Il a donc fallu décrire celui-ci, avec les ingénieurs et responsables des entités, et cela demande du temps.

• Il est important de bien définir le processus de sélection des logiciels, ainsi que les critères qui seront utilisés. En effet, on ne peut éviter des préférences de certains pour tel ou tel logiciel. Il faut essayer de comprendre pourquoi cet ingénieur apprécie cet outil, et prendre en compte ce besoin sans pour autant se focaliser dessus (d’où l’intérêt de pondéré les exigences).

• Il est fortement recommandé de travailler avec les futurs utilisateurs de l’atelier afin de coller au mieux à leurs besoins. Leur aide est aussi précieuse pour choisir le meilleur logiciel du commerce, parmi ceux disponibles sur le marché.

• Il est important de préparer la conduite du changement. Pour cela, il a été décidé de communiquer de manière transparente avec les ingénieurs SdF du groupe, de les faire participer à chacune des étapes de construction de l’atelier, de répondre à leur questions/craintes et, plus généralement, d’avancer progressivement avec eux.

6 Remerciements

Les auteurs tiennent à remercier Hervé Chapotin, chef de ce projet, ainsi que Pierre-Olivier Robic, Responsable des nouveaux services, pour leur support.


Création d'un atelier d'ingénierie en Sûreté de … · 2. e. Congrs de matrise des risques et...

Documents

Transcript of Création d'un atelier d'ingénierie en Sûreté de … · 2. e. Congrs de matrise des risques et...