Aid to system validation the specification of a machine · La méthode exploite des AMDEC / AEEL (Analyse des Modes de Défaillances de leurs Effets et de leur Criticité / Analyse

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

Aide à la validation système de la spécification d’une machine numérique

Aid to system validation the specification of a machine

Auteur : Philippe Leclercq Société : R.I.S. Adresse : 12 Avenue de Bures Cottage, F91440 Bures sur YvetteCourriel : [email protected]

Résumé Les machines numériques deviennent de plus en plus complexes. Elles sont susceptibles de défaillances dont les sources sont liées à des défaillances matérielles et logicielles, aux opérateurs, à l’environnement. Cependant force est de constater qu’uneautre source en est la spécification, incomplète, inadaptée à l’usage, ou au comportement à mettre en œuvre sur défaillancesobservées. Cet article présente une méthode résultant de travaux destinés aux maîtres d’ouvrage pour diminuer les risques dus aux insuffisances de spécification.La méthode est basée sur une modélisation cohérente tant de la spécification que de la réalisation de la machine. Elle s’appuie sur des analyses classiques mais améliorées de sûreté de fonctionnement (AMEC, AEEL, FTA,…) pour identifier de façon très rapide les scénarios résultants les plus critiques, correspondant aux coupes minimales d’ordre les plus faibles pour proposerdes solutions pour y remédier. Après avoir positionné le problème traité, le principe de la méthode est détaillé et illustré à l’aide d’un exemple didactique pouren comprendre des étapes de la mise en œuvre et les résultats obtenus avant que d’exposer le traitement d’un exemple industriel. Les avantages, limites et perspectives de la méthode sont ensuite décrits.

Summary Digital machines are becoming more and more complex. They are likely to failures whose sources are related to hardware and software, failures to operators, to the environment. However it is clear that another source is the specification, incomplete, inadequate for the purpose, or to implement in observed failure behaviour.This paper presents a method resulting from works intended for owners to reduce risks due to the shortcomings of specification. The method is based on consistent modelling both the specification and the construction of the machine. It relies on classic but improved dependability analyses (FMECA, SEEA, FTA,...) to identify very quickly the most critical resulting scenarios, corresponding to the lowest minimum order cuts to propose solutions to address them. After positioning the problem addressed, the principle of the method is detailed and illustrated using an example to understand content, the stages of the implementation and the results obtained before as to expose the treatment of an industrial example. The benefits, limits and perspectives of the method are then described.

1 Objet

Les machines, dont les machines numériques, sont de plus en plus complexes. Mises en œuvre, elles présentent des défaillances. Une analyse de ces défaillances montre que leurs sources sont liées aux défaillances de la partie matérielle, à des erreurs des opérateurs, à l’activation de défauts dans le logiciel ou à des conditions anormales d’exploitation (fonctionnelles et / ou environnementales).La source de beaucoup de ces défaillances est le processus de développement. Cependant, fort est de constater, qu’une autresource en est la spécification, incomplète, inadaptée à l’usage, ou au comportement à mettre en œuvre sur défaillancesinternes observées [réf. 6]. L’objectif de cet article est de présenter des travaux destinés à fournir aux maîtres d’ouvrage une méthode pour diminuer lesrisques dus aux insuffisances de spécification [réf. 7].

2 Plan de l’article

Nous développerons successivement : 1. Le contexte,2. Une introduction à la méthode sur une machine simple,3. Le détail de la méthode,4. L’application au cas réel d’une machine numérique complexe,5. Les résultats.

3 Contexte

Le processus d’élaboration d’une spécification est complexe et comporte souvent de nombreuses itérations. Pour ce faire des méthodes et outils sont mis en œuvre [réf : 1]. Ils formalisent ce processus en intégrant autant que possible l’expérience « métier » sur des machines antérieures. Cependant dans un environnement, ouvert par définition, il est difficile d’être assuré que la machine aura le niveau de sûreté attendu. Dans ce but des méthodes orientées sûreté de fonctionnement doivent être mises en œuvre très tôt pour minimiser les « re-conceptions ». Malgré tout ces méthodes de SdF, ne garantissent pas que l’ensemble des cas soient traités notamment lorsque des combinaisons de causes sont sources de dysfonctionnements et ce dans des conditions économiques acceptables. La méthode est à mettre en œuvre lorsque le développement démarre. Celui-ci répond au « référentiel de spécification » qu’il s’agit de consolider et de maintenir compte tenu des contraintes de développement.

Communication 7F-2 /1 page 1/10


4 Introduction à la méthode

Figure 4.1. Spécification et développement

De fait, il existe des exigences de la spécification qui sont, incomplètes, imparfaitement prises en compte, d’où une zone « A » comme illustré Figure 4.1. De même la machine en développement comporte, suite à défaillance(s), des dysfonctionnements mal maîtrisés qui ne correspondent en rien à la spécification, d’où une zone « B ». Dans le processus qui permet de passer d’une spécification à une réalisation / développement il y des itérations qui s’effectuent. Au final, l’objectif de la méthode est d’identifier les zones « A » et « B » afin de les réduire jusqu’au niveau de risque souhaité.

La méthode itérative conduit à dérouler de façon cyclique les étapes 1 à 5 :

1. Modélisation de la spécification et du développement au travers de la description des objets « Environnement », « Matériel », Logiciel », « Opérateur », « Fonction »,

2. Analyse de la sûreté de fonctionnement du projet en cours de développement, 3. Evaluation des conditions de dysfonctionnement conduisant à des conséquences non souhaitées, 4. Choix de solutions pour en réduire l’occurrence, 5. Edition d’une liste des modifications / enrichissements de la spécification et du développement.

Figure 4.2: Etapes de la méthode

Figure 4.3.1: Alimentation initiale en eau

Développement

Spécification

1 Modélisation

2 Analyse

3 Evaluation

4 Choix

5 Liste

4.1 Objectif

4.2 Etapes de la méthode

4.3 Exemple pour illustrer

A

B



Il s’agit d’un système essentiellement mécanique et électrique très simple de distribution d’eau illustrant le processus mis en œuvre par la méthode. Lors du premier cycle de mise en œuvre de la méthode, la modélisation étant faite (étape 1), les données sont utilisées dans l’analyse de Sûreté de Fonctionnement (SdF) (étape 2). La méthode exploite des AMDEC / AEEL (Analyse des Modes de Défaillances de leurs Effets et de leur Criticité / Analyse de l’Effet des Erreurs du Logiciel), des arbres de défaillances. L’évaluation (étape 3), par rapport à la fonction de fourniture d’eau, établit les dysfonctionnements correspondant à plusieurs coupes d’ordre 1 :

1. Perte du bloc alimentation électrique, 2. Vanne 1 bloquée fermée, 3. Vanne 2 bloquée fermée.

Dans le cas présent il n’est « pas encore » utile de s’intéresser aux coupes d’ordre supérieur. L’étape suivante (4) conduit à choisir des corrections permettant de supprimer l’un de ces dysfonctionnements. On note dans la liste des mises à jour de la spécification, en conception, « redonder l’alimentation (étape 5) ». La redondance peut être d’ajouter une deuxième alimentation identique ou un groupe électrogène ou toute autre solution permettant de maintenir la fonction alimentation. La spécification doit définir la solution choisie. Lors du deuxième cycle, l’étape 3 montre que si la redondance est physiquement souhaitable, elle est cependant fonctionnellement non valable. En effet, si la cause de la défaillance d’une alimentation est l’environnement, si celui-ci est commun, il s’agit d’une « vrai, fausse » redondance. A l’étape suivante (4), on choisit de spécifier un environnement diversifié pour les deux alimentations. Ainsi, par exemple, des précautions doivent être prises pour éviter l’inondation du groupe électrogène. La liste des mises à jour de la spécification (étape 5) a donc ce choix pour élément de rang deux.

Figure 4.3.2: Alimentation en eau corrigée

En conséquence, pour une simple défaillance nous avons déjà deux modifications, une de spécification, une de conception. En poursuivant les cycles il est possible d’arriver à une liste des mises à jour de la spécification plus ou moins importante compte tenu du soin, de l’expérience des spécificateurs, de la compétence des développeurs et du nombre de coupes minimales souhaitées. La méthode permet d’enrichir non seulement la spécification mais d’imposer des choix raisonnés au développeur.

5 Détails de la méthode

Dans le but de supporter la méthode proposée nous utilisons une modélisation cohérente et complémentaire qui intègre:

1. Le système décrit dans la spécification, 2. La machine en cours de développement qui y répond, 3. Les possibilités de dysfonctionnement lorsqu’elle sera mise en œuvre.

L’important est d’avoir une seule modélisation et non deux qui le plus souvent s’ignorent. Nous verrons plus loin comment la méthode atteint ce but. Cette modélisation permet de manipuler des objets dont les attributs et relations vont permettre de décrire une machine. Certains attributs ne décrivant que la spécification, d’autres ne décrivent que la SdF et enfin d’autres sont communs aux deux. L’objet « Premier », la machine, intègre une partie matérielle que nous nommerons objet « Matériel ». Elle est mise en œuvre par des objets « Opérateurs » et fonctionne dans un objet « Environnement » qui pour la machine est composé soit d’agressions (choc, température,…) soit de ressources (alimentation électrique, fluide,…). Elle est également susceptible de comprendre une partie logicielle dite objet « Log / Projet ». Ces objets peuvent se décomposer en des objets de même nature et de rang inférieur. Dans le cas du projet logiciel nous nommons les éléments de cette décomposition « Module ».

5.1 Modélisation



L’ensemble de ces objets peuvent être situés physiquement en des lieux différents et avoir un environnement diversifié. La mise en œuvre de ces objets s’effectue par l’objet « Analyse fonctionnelle externe » qui décrit le besoin auquel devra répondre la machine, les fonctions de service qu’elle devra remplir, les contraintes auxquelles elle sera soumise et à caractériser ces fonctions et ces contraintes. Ceci est consigné dans le « Cahier des charges Fonctionnel » élément de la « Spécification ». Le concepteur crée la machine qui peut être considérée comme le support d’un certain nombre de fonctions techniques. L’objet « Analyse fonctionnelle interne » décrit les fonctions techniques permettant d’assurer les fonctions de service et la matérialisation des concepts de solutions techniques. Ces deux analyses évoluent dans le temps en fonction des phases de développement de la machine. Ainsi la spécification est modélisée de même que le développement. Les étapes de l’évaluation dans la vie du projet conduisent à l’itération du processus de modélisation, notamment les analyses jusqu’au niveau souhaité. On remarquera cependant que les attributs des objets de la modélisation (Matériel, Logiciel, Opérateur, Fonction) peuvent être liés soit à la spécification soit au développement ou encore être communs et donc liés aux deux.

Figure 5.1. : Schéma des relations entre la spécification, le développement et la modélisation

Ayant adopté le principe d’une modélisation comme support à la méthode proposée nous n’entrerons pas dans le détail de la modélisation proprement dite, celle ci n’étant pas le cœur de notre propos dans le présent article. Dans le futur, pour un complément à ce qui est présentement exposé, il sera toujours temps se pencher sur les techniques de « Model Checking », les diagrammes de décision binaire (BDD)... Pour l’approche exposée, il n’est pas nécessaire de traiter l’exhaustivité du graphe traduisant le comportement de la machine que ce soit en absence ou en présence de défaillance(s). Seuls comptent pour nous les états de défaillances de la machine. De plus, nous nous intéressons en priorité à l’ensemble des états identiques quand à l’effet sur la machine résultant d’un nombre minimum de défaillances. Ces états, s’ils sont non souhaités, sont le résultat d’une spécification incomplète ou inadaptée soit de défaillances pour lesquelles rien n’est prévu pour en contrôler l’effet. Aussi la méthode proposée va s’appuyer sur des AMDEC / AEEL extraites des modèles qui compilées et transformées en arbres de défaillance vont permettre d’identifier les seuls états non souhaités recherchés. A ceux-ci, il est facile alors d’en présenter les causes et proposer, soit une solution pour les éliminer moyennant une spécification « enrichie », soit une solution technique pour le développement.

La méthode proposée va vérifier que les liens décrits dans la modélisation entre les différents objets sont exhaustifs et que les défaillances de la machine en développement trouvent réponse tant dans la spécification que dans le fonctionnement de la machine. Ainsi la méthode s’appuie sur la comparaison :

Des demandes contenues dans la spécification identifiant : - Les fonctions à exécuter, - Les ressources nécessaires pour ce faire (matériel, logiciel, opérateur), - L’environnement dans lequel il réalise les fonctions incluant agressions, ressources nécessaires, règles

métier.

5.2 Approche

5.3 Mise en œuvre



Enfin il n’est pas « inutile » de définir ce que le système ne doit pas faire. Avec les modes de défaillances et leurs propagations identifiés dans les analyses de SdF.

Les modes de défaillances pris en compte sont ceux des parties matérielles et logicielles auxquelles s’ajoutent les erreurs susceptibles d’être commises par le / les opérateurs. Les défauts logiciels se propagent via des valeurs de variables erronées auxquelles s’ajoutent des valeurs en pannes « avance ou retard ». La propagation dépend bien évidemment du type de programme (séquentiel, événementiel, multitâches, temps réel).

Cette comparaison doit être effectuée aux différents stades des processus d’élaboration et de raffinement de la spécification et de l’avancement des études de SdF, fonction des éléments disponibles au cours du processus de développement. Pour ce faire, nous nous appuierons sur le traitement de mécanismes d’apparition et de propagation de défaillances. Nous décrirons dans la suite du texte la prise en compte de deux mécanismes, le premier dit « fonctionnel », ce que doit faire la machine numérique, le second mécanisme dit « environnemental » qui considère l’environnement dans lequel la machine fonctionne, la façon dont elle est construite et mise en œuvre. Ces mécanismes sont complémentaires et ont des éléments en commun. On remarquera que ces deux seuls mécanismes ne rendent pas compte de l’ensemble des conditions pouvant conduire à une défaillance. Nous ne traitons pas, notamment, des facteurs organisationnels ou réglementaires tels que traités, par Nancy G. Leveson, dans la méthode SMART [réf. 4], ou par Erik Hollnagel, dans la méthode FRAM [réf. 3]. Nous nous sommes limités à ceux décrits pour ne pas alourdir l’exposé. Cependant la présente méthode est applicable de la même façon à d’autres mécanismes. Compte tenu de la modélisation de la spécification notamment par des méthodes et outils utilisés dans l’industrie, modélisation U.M.L., SysML, … la méthode génère des scénarios de fonctionnement / dysfonctionnement à partir des hypothèses d’évènements internes ou externes aux objets. Pour ce faire elle utilise des AMDEC/AEEL, des arbres de défaillances, des arbres d’évènements, des diagrammes de séquences [réf : 5 et 2] générés automatiquement à partir de données tirées de la spécification et de celles décrivant la machine développée. Après avoir constaté l’état « initial » de la spécification tel que déjà décrit au chapitre 4.2 précédent, la méthode suggère des modifications de la spécification pour les défaillances traitées dans les études de SdF et dont on souhaite réduire le nombre et la criticité d’occurrences. Pour chaque modification acceptée, une nouvelle génération des scénarios de fonctionnement / dysfonctionnement est établie. Le processus peut s’arrêter lorsque le niveau de risques de dysfonctionnement atteint le niveau souhaité.

Le mécanisme dit « fonctionnel » s’appuie sur les fonctions spécifiées à la machine. Chaque fonction nécessite pour sa réalisation l’enchainement d’une succession de tâches réalisées par du matériel, du logiciel, un / des opérateur(s). C’est une réalisation correcte des tâches qui permet la bonne fin d’une fonction après qu’elle ait été lancée dans des conditions qui sont définies pour chacune d’elles. Si la mise en œuvre d’une tâche s’effectue alors qu’une défaillance s’est produite, par défaillance interne au matérielle, par erreur d’un opérateur, par activation d’un défaut dans une partie du logiciel alors la fonction est défaillante soit en cours soit en fin de mise en œuvre. La conséquence dépend de la défaillance et du moment où elle se révèle. Elle peut être plus ou moins grave / critique.

Le mécanisme dit « environnemental » considère l’environnement dans lequel la machine est appelée à fonctionner. L’environnement peut comprendre des agressions (choc, eau, électromagnétique, pression, rayonnement, température, vibration,..) et comporter des ressources (carburant, climatisation, électricité, fluide, hydraulique, …). Ces agressions et ressources peuvent être la cause de défaillances des matériels, d’erreurs des opérateurs, de la modification de la zone de mémoire adressable attribuée en exécution celle-ci étant découpée en sous zones, celle de code où sont stockés les instructions du programme, une zone de variables où sont stockées certaines données que le programme manipule, une zone de pile d’exécution et la zone de tas. Les deux premières zones sont fixes, les deux suivantes dynamiques. Or ces zones peuvent être « compromises » par les contraintes de l’environnement, l’altération des ressources, par des défaillances physiques qui modifient soit l’exécutable ou la valeur des variables, par un défaut d’adressage, par la valeur de variables qui ne sont pas stockées à l’endroit souhaité, par exemple, par débordement de pile,…

A l’aide d’AMDEC/AEEL dites « gigognes » faites pour les objets matériels, opérateurs et logiciels, d’arbres d’événements, de diagrammes de séquence, la méthode établie les fonctionnements dégradés, les reconfigurations si elles existent et les conséquences plus ou moins critiques. Les AMDEC/AEEL associent à une cause de mode défaillance un évènement qui le provoque. Cet évènement peut être interne à l’objet, être lié à son support, à son environnement. La figure 5.5 illustre un cas parmi d’autres:

5.4 Les mécanismes

5.4.1 Le mécanisme fonctionnel

5.4.2 Le mécanisme environnemental

5.5 Support à la méthode



Figure 5.5 Matériel non protégé contre les chocs

Les caractéristiques des AMDEC/AEEL dites « gigognes », sont:

1. Pour chaque mode de défaillance : 1. Il est associé une cause potentielle (défaillance matérielle, défaillance logicielle,…), par exemple, une

défaillance matérielle interne et / ou le dépassement d’une agression environnementale par rapport au niveau autorisé,

2. Il existe un / des évènements initiateurs, par exemple un défaut interne et / ou des pertes de ressources lié(s) à la cause potentielle.

2. Il existe autant de lignes pour un même mode de défaillance qu’il y a de combinaisons possibles d’évènements initiateurs simple(s) et multiples.

3. Ces lignes ont un effet local ou au niveau machine identique. 4. Ces AMDEC/AEEL réalisées sur différents objets (matériel, logiciel,...) peuvent être liées, d’où le terme « gigogne ».

Ainsi, pour un logiciel, le mode défaillance peut être l’activation d’un défaut interne mais aussi une modification de donnée, de code due à la défaillance du support matériel, lui-même du à un environnement présentant une agression supérieure à ce qui peut être supporté ou la perte d’une ressource nécessaire.

Ceci permet de réaliser des AMDEC/AEEL distinctes pour chacun des objets tout en assurant le lien et la cohérence entre elles. Cette façon de faire rend le processus automatisable et apte à gérer un grand nombre de lignes conséquences des combinaisons d’évènements initiateurs. Ces évènements peuvent être catalogués et servir de base à l’analyse d’un objet en l’absence de caractéristique particulière de celui-ci. A titre d’exemple pour le matériel nous avons :

1. Défaillance interne au niveau de décomposition analysé de l’objet 2. Environnement de fonctionnement non défini ou supérieur à la définition :

a. Choc, b. Eau (inondation). c. E.M.C. (Electromagnetic Compatibility), d. Pression. e. Rayonnement. f. Température ambiante, g. Vibration. h. Autre(s)…

3. Ressource non définies ou inférieure au besoin : a. Carburant, b. Climatisation, c. Alimentation électrique, d. Alimentation hydraulique, e. Autre(s)…

En reprenant l’exemple précédent de fourniture d’eau nous avons :

Evènement(s) Désignation des modes de défaillances

Cause(s) Désignation de l’effet au niveau matériel

Effet sur le matériel

Désignation de l’effet au niveau machine

Effet machine

Interne Défaillance du bloc de commande électrique

Défaillance interne Sorties du bloc: Hors service

Marginal Défaillance fonction fourniture d’eau : Perte totale de la fonction

Critique

Choc Défaillance du bloc de commande électrique

Non protégé contre l’agression: Choc

Sorties du bloc: Hors service


Critique

Choc + Electricité Défaillance du bloc de commande électrique

Non protégé contre l’agression : choc + la perte de ressource: Electricité

Sorties du bloc: Hors service


Critique

Suivant…

Tableau 5.5 : Premières lignes du tableau d’AMDEC du matériel



Ainsi à une ligne d’AMDEC/AEEL correspond un même mode de défaillance, une ou plusieurs causes et un seul effet. Des AMDEC/AEEL sont générées pour les éléments matériels, les opérateurs et les logiciels. En liant ligne à ligne de ces différentes AMDEC/AEEL, d’où le nom de « gigognes » et la description des fonctions, la méthode établit les éléments constitutifs des arbres d’évènements du fonctionnement de la machine en présence de défaillances. Ces arbres n’ont pas besoin d’être créés de façon explicite. Seuls les évènements dont on souhaite réduire la criticité et/ou l’occurrence (en nombre de causes possibles) ont besoin d’être explicités. Ceci évite d’entrer dans un processus combinatoire bien connu d’autres méthodes telles les graphes de Markov ou réseaux de Petri, et en conséquence un gain de temps évident.

6 Explicitation, exemple industriel en vrai grandeur La méthode a été mise en œuvre sur une machine numérique, un réseau de télésurveillance et d’alarme comprenant un serveur, 10 concentrateurs et 3000 terminaux clients. Des opérateurs le mettent en œuvre tant au niveau serveur que terminaux. Pour illustrer et expliciter la méthode nous présentons des extraits de la mise en œuvre de la méthode. Les tables présentées ci-après sont tirées de la mise en œuvre de la méthode à l’aide du progiciel « Sofmat eXPert » qui la met en œuvre.

La figure suivante reproduit le début de l’AMDEC d’un sous ensemble de la partie matérielle, le serveur.

Tableau 6.1.1.1 : AMDEC d’une partie de l’objet matériel

La figure suivante est semblable à la précédente et concerne un module logiciel.

Tableau 6.1.1.2 : AEEL d’une partie de l’objet logiciel applicatif

Ici les causes sont des valeurs de variables erronées suite à l’activation d’un défaut soit du fait que la variable soit stockée sur une partie défaillante du support matériel. Pour le reste les lignes sont semblables aux lignes du tableau précédent. Cependant, si on lie les deux AMDEC on remarque qu’à la ligne 2 on peut relier la défaillance des causes qui peuvent être soit l’activation d’un défaut logiciel, soit une défaillance matérielle sans cause extérieure, soit encore une agression extérieure. Nous avons ici l’illustration de scénarios « implicites » de défaillances multiples ayant la même conséquence sans entrer dans le mode combinatoire mise en œuvre dans les modèles d’états, les processus de Markov ou réseaux de Pétri.

Les AMDEC/AEEL « gigognes » sont concaténées et transformées pour obtenir une partie des entrées de l’arbre de défaillance de la machine. Celui-ci nécessite, en outre, la prise en compte des redondances mises en œuvre, des interfaces entre éléments et diverses autres données. Pour ne pas alourdir l’arbre et faciliter son usage dans la méthode toutes les feuilles sont regroupées :

1. Par criticité de l’effet au niveau machine, 2. Par combinaisons d’éléments impliqués dans un même effet, 3. Par coupe.

Bien que comportant un nombre très important de feuilles l’arbre est ainsi d’une présentation très concise. La figure suivante en présente un extrait en milieu de développement, les principales questions ont déjà trouvé une réponse dans les étapes précédente.

6.1.1 AMDEC/AEEL « gigogne »

6.1.2 Arbre de défaillance



Figure 6.1.2

Nous en sommes au cycle 47 de l’application de la méthode. La colonne « Désignation » définit, pour une coupe d’ordre 1 à n, l’objet concerné, la criticité de l’effet de la / les défaillances. Dans la colonne « Résultats » figure le nombre de causes de défaillance attachées à l’objet concerné et la catégorie de criticité indiquée. Ainsi, l’environnement a été validé :

Certaines agressions ont été écartées car le projet ne peut y être soumis, Pour d’autres les limites de fonctionnement ont été définies, Si jamais elles devaient être dépassée une détection permet d’enclencher un mode de fonctionnement, soit dégradé

soit stable, Il en est de même des ressources pour lesquelles des secours ont été implantés.

Quant aux risques simples restants :

Il y a encore une défaillance simple dont l’effet peut être « Catastrophique », Elle doit être traitée en priorité. La plupart des défaillances ont un effet « Critique » c'est-à-dire en relation avec la disponibilité. Il semble raisonnable

de les faire également disparaître car correspondant à des coupes d’ordre 1. Dans le présent cas de figure nous avons pour l’opérateur du « Serveur », deux types de solutions :

o Il pourrait être doublé (redondé) et cette redondance ne sera effective que si chacun d’eux n’est pas soumis en même temps à une même agression ou manque de ressource,

o Faire en sorte qu’un seul opérateur ne soit plus critique en ajoutant, par exemple, des fonctions de contrôle des données qu’il manipule, ceci faisant l’objet d’un complément de modélisation, après acceptation des mesures prises avec à la clé une nouvelle mise à jour de la spécification.

La figure suivante présente un exemple de suggestions, proposées par « Sofmat eXPert » pour réduire les risques liés à l’opérateur du serveur.

Figure 6.1.3.1

6.1.3 Suggestions



Le choix d’une suggestion conduit dans la modélisation mise en œuvre par le progiciel à : 1. Modifier les entrées, 2. Evaluer l’impact, 3. Editer la mise à jour à introduire dans la spécification.

Il n’y a pas d’ordre à l’application des suggestions. Cependant la logique et l’efficacité dans la réduction du nombre d’occurrence de défaillances conduit à procéder comme suit :

1. Avant toute chose il s’agit que l’environnement de la machine soit correctement et complètement défini. Ceci permet que les redondances soient effectives.

2. Ensuite il s’agit de mettre en redondance les éléments là ou nécessaire, 3. De placer des barrières et définir des modes de reconfiguration, 4. Diversifier les éléments utilisés (matériels, logiciels,…) pour la réalisation des fonctions.

La figure suivante présente un résumé des suggestions prises en compte et la façon dont elles l’ont été conduisant à une mise à jour de la spécification. Ainsi, la suggestion numéro 3 concerne les E.M.C. Il convient de s’assurer en qualification que le matériel fonctionne correctement dans l’environnement défini dans la spécification. Il s’agit donc d’un élément qui doit être contenu dans la spécification des essais et pas unique de la spécification de définition fonctionnelle.

Figure 6.1.3.2

Au final cela permet d’éditer la liste des modifications à introduire tant dans la spécification fonctionnelle que dans la spécification des essais de qualification.

7 Conclusion

La mise en œuvre de la méthode permet d’enrichir la / les spécification(s) conduisant à de meilleurs développements et une vie en opération de la machine plus conforme au niveau de sûreté de fonctionnement souhaité. Parmi les types de suggestions pouvant être proposés, citons, par exemple:

1. « Spécifier la criticité de la fonction ! ». En début de projet il est possible que l’on ne connaisse pas de façon suffisamment précise les conditions de cette criticité, aussi prise par défaut de façon conservatoire par la méthode il convient peut-être de l’ajuster ?,

2. « Diversifier la fonction ! ». Dans la description de la fonction, le diagramme de séquence d’activation définit l’enchaînement de n « modules » logiciels. Cette fonction pourrait être réalisée d’une autre façon avec d’autres modules,… ?,

3. « Redonder le code ! ». C’est une solution mais, pour être une redondance valable, la conception doit au minimum l’implanter sur des supports différents et être de programmation diversifiée,

7.1 Résumé



4. « Redonder le matériel ! ». C’est une solution souvent simple. Cependant la solution est acceptable si la cause de la défaillance est interne, mais ne l’est pas si la cause est une agression car il faut situer les éléments du produit matériel redondé en des lieux où les agressions s’exercent de façon indépendante aboutissant à une diversification de l’environnement,

5. « Ajouter une ressource de secours ! ». Ce peut être une seconde source d’alimentation, si possible, en tous points indépendante de la première y compris en environnement,

6. « Ajouter une barrière de sécurité dans le support matériel, le logiciel ! ». Elle assure que la défaillance ne peut se propager,

7. … La méthode définit où les appliquer et comment. Sur une application à un cas réel de réseau informatique architecturé de façon pyramidale et comprenant trois types de boîtiers. La méthode a, notamment, conduit à redonder physiquement et fonctionnellement « le boitier serveur », chaque branche de la redondance étant isolée vis-à-vis de l’environnement et introduire pour chacun une alimentation électrique de secours. En outre, pour « les boîtiers clients » des barrières logicielles ont été introduites pour éviter la propagation d’erreurs des opérateurs. Au total, une cinquantaine de modifications à la spécification ont pu être retenues, au stade où nous décrivons la méthode.

La méthode repose sur une description « convenable » du comportement à mettre en œuvre sur défaillances internes observées. Elle est limitée par la définition des mécanismes de défaillances pris en compte décrits ci-dessus. Cependant elle peut être étendue sans problème à d’autres mécanismes tels ceux d’organisation considérés dans les méthodes STAM et Fram. Dans le cas du logiciel elle suppose que l’on utilise un langage de haut niveau qui masque, l’accès à la zone de pile d’exécution et la zone de tas dont le pourcentage d’utilisation et le contenu sont dynamique, les zones de stockage fixes du code et des données.

La méthode gère une modélisation commune entre le maître d’œuvre qui édite une spécification et le maître d’ouvrage qui réalise le développement. On évite ainsi des incohérences entre deux modèles, des écarts liés aux mises à jour tant de la spécification que du développement. Elle peut s’interfacer facilement avec les outils des uns et des autres par import / export. La méthode permet de s’affranchir de la problématique combinatoire et explosive de vérification de l’ensemble des séquences de fonctionnement. Elle permet de systématiser les vérifications, évaluations, de s’assurer de leur mise en œuvre dans des délais réduits rendant la mise œuvre opérationnelle et ce jusqu’à un nombre élevé de coupes minimales. Des tests de mise en œuvre de la méthode ont montré que 10**18 séquences potentielles de fonctionnement sont identifiables en moins de 30 secondes auxquelles ne correspondent que quelques milliers de cas intéressants pour notre propos et quelques dizaines de modification à la spécification. Seules celles en rapport avec les dysfonctionnements dont il est nécessaire de réduire les conséquences et l’occurrence ont besoin d’être effectivement établies pour produire des suggestions d’amélioration de la spécification. Il conviendra ultérieurement d’étendre la méthode à d’autres mécanismes pour répondre plus complètement aux défis des accidents de ces dernières années.

8 Remerciements Je tiens à remercier ceux qui au long du développement de la méthode m’ont aidés de leurs remarques et commentaires. Je voudrais plus particulièrement remercier, par ordre alphabétique, pour leur aide, Allain Delage ancien référent Sûreté de Fonctionnement à la Société Renault, France, Patrice Kahn Consultant à KSdF-Conseil, France ainsi qu’Antoine Rauzy professeur à la Norwegian University of Science and Technology, Norvège.

9 Références

[1] Stéphane Badreau et Jean-Louis Boulanger, 4/6/2014, Ingénierie des exigences, Dunod. [2] Clifton A. Ericson, 2005, Hazard Analysis Techniques for System Safety, John Wiley & Sons. [3] Erik Hollnagel, 2012, FRAM : The Functional Resonance Analysis Method, Modelling complex socio-technical systems, Ashgate Publishing. [4] Nancy G. Leveson, 2011, Engineering a Safer World, Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press. [5] I. A. Papazoglou, 1998, Functional Block Diagrams and Automated Construction of Event Trees, Reliability Eng. System Safety, pages185–214. [6] The National Diet of Japan, 7/5/2012, The official report of the Fukushima Nuclear Accident, Independent Investigation Commission. [7] John Wang and Marvin L. Roush. 2000, What Every Engineer Should Know About Risk Engineering and Management. London: CRC Press.

10 Mots clés Système micro-programmés, Modélisation de la sûreté de fonctionnement, Gestion des risques projet.

7.2 Limites

7.3 Avantages et perspectives


Documents

Aid to system validation the specification of a machine · La méthode exploite des AMDEC / AEEL (Analyse des Modes de Défaillances de leurs Effets et de leur Criticité / Analyse