FR2923925A1

FR2923925A1 - Procede d'evaluation de la surete de fonctionnement d'un systeme

Info

Publication number: FR2923925A1
Application number: FR0708057A
Authority: FR
Inventors: Andre Leblond
Original assignee: Thales SA
Current assignee: Thales SA
Priority date: 2007-11-16
Filing date: 2007-11-16
Publication date: 2009-05-22
Anticipated expiration: 2027-11-16
Also published as: US20090144599A1; US8271845B2; FR2923925B1

Abstract

La présente invention concerne un procédé d'évaluation de la sûreté de fonctionnement d'un système complexe logiciel et/ou matériel comme un système d'affichage d'informations de vol sur une planche de bord d'un aéronef. Le procédé d'évaluation (20) comporte au moins les étapes suivantes :. construction d'une première architecture du système décomposé en plusieurs blocs comportant chacun des entrées/sorties de données, les entrées d'un bloc étant reliées aux sorties d'autres blocs dans la première architecture ;. identification (21) de défaillances des sorties des blocs de l'architecture ;. construction (22) de premières expressions booléennes exprimant les états des sorties des blocs de la première architecture en fonction des états des défaillances identifiées, des états des entrées des blocs ;. définition (23) d'un premier événement redouté à examiner par une deuxième expression booléenne construite à partir des premières expressions booléennes;. réduction (24) de la deuxième expression booléenne en une somme de monômes;

Description

Procédé d'évaluation de la sûreté de fonctionnement d'un système Domaine technique La présente invention concerne un procédé d'évaluation de la sûreté de fonctionnement d'un système complexe logiciel et/ou matériel comme un système d'affichage d'informations de vol sur une planche de bord d'un aéronef. Un système d'affichage d'informations de vol comporte notamment une partie logicielle de traitement de données et une partie matérielle comprenant un calculateur, réalisant le traitement de données, et un écran de visualisation par exemple. Exposé du problème technique La sûreté de fonctionnement d'un système peut être définie comme étant la propriété permettant à des utilisateurs du système de placer une confiance justifiée dans les services qu'il leur délivre. Un utilisateur du système peut être un individu tel qu'un opérateur ou un superviseur ou encore, un autre système matériel ou logiciel ayant des interactions avec le système considéré. Selon les applications auxquelles le système est destiné, la sûreté de fonctionnement peut être caractérisée selon des propriétés différentes mais complémentaires comme : la fiabilité, la disponibilité, la sécurité, la maintenabilité, la confidentialité, l'intégrité du système.

La fiabilité correspond notamment à la continuité des services que le système doit fournir à ses utilisateurs, en l'absence de réparations. La fiabilité peut également être définie comme l'aptitude d'un système à accomplir une fonction requise, dans des conditions données, pendant une durée donnée. Toutes les défaillances du système de nature accidentelle peuvent être prises en compte sans aucune discrimination vis-à-vis de leur sévérité. Un exemple de mesure de fiabilité est le taux de défaillances, inverse du temps moyen de fonctionnement jusqu'à la première défaillance. La maintenabilité d'un système traduit son aptitude à supporter des réparations et des évolutions. La maintenance du système doit alors être accomplie dans des conditions données avec des procédures et des moyens prescrits. Un exemple de mesure de maintenabilité est par exemple le temps moyen de réparation ou de restauration du système dans un état de bon fonctionnement. La disponibilité d'un système est la faculté d'un système à délivrer correctement un service, en termes de délai et de qualité, au moment où l'utilisateur en a besoin. La disponibilité est une mesure sans unité, elle correspond notamment à une proportion du temps de bon fonctionnement sur le temps total de fonctionnement du système. En terme de sécurité, on peut distinguer la sécurité-innocuité, de la sécurité-confidentialité : la sécurité-innocuité vise à se protéger des défaillances catastrophiques, c'est-à-dire des défaillances pour lesquelles des conséquences sont inacceptables vis-à-vis du risque encouru par les utilisateurs du système ; la sécurité-confidentialité correspond à la prévention d'accès ou de manipulations non autorisées d'informations contenues dans le système. La sécurité-confidentialité concerne donc la lutte contre les fautes intentionnelles comme des virus informatiques, des bombes logiques, ou des chevaux de Troie informatiques. La sécurité-confidentialité vise également à garantir l'intégrité des informations fournies aux utilisateurs du système.

Un système doit donc prendre en compte des contraintes en matière de sûreté de fonctionnement afin d'assurer aux utilisateurs un service attendu. Les contraintes de sûreté de fonctionnement peuvent donc se décliner en terme de fiabilité, sécurité, maintenabilité et disponibilité. Pour un système embarqué à bord d'un aéronef comme un calculateur de paramètres de vol par exemple, on s'intéresse particulièrement à la fiabilité, à la disponibilité et à la sécurité. Il est notamment important, voir vital, de maîtriser et de réduire l'ensemble des défaillances d'un tel système, ceci afin, notamment, d'éviter tout accident pouvant mettre en jeu des vies humaines.

Dans la réalisation de systèmes tels des calculateurs de paramètres de vol, les contraintes de sûreté de fonctionnement sont souvent évaluées pendant une phase relativement tardive de la conception et de la réalisation du système. Pendant une telle phase de réalisation et de conception, il est souvent difficile et coûteux de prendre en compte les contraintes de sûreté de fonctionnement, notamment si elles remettent en cause la conception initiale du système. Ceci amène donc souvent à ne prendre en compte qu'imparfaitement les contraintes de sûreté de fonctionnement et donc à une mise en danger du système.

II apparaît donc nécessaire de pouvoir prendre en compte les contraintes de sûreté de fonctionnement dès les phases de spécification du système et de définition de l'architecture fonctionnelle du système. Pendant ces phases, dites phases amont, un moyen de prendre en compte les contraintes de sûreté de fonctionnement est de définir des cas de disfonctionnements critiques du système, mettant potentiellement en danger le système et/ou un utilisateur. Un exemple de disfonctionnement critique pour une fonction d'affichage de paramètres de vol peut être un affichage faux d'une altitude sur un écran du tableau de bord, sans alarme signalant qu'une défaillance s'est produite. Un tel disfonctionnement peut entraîner une collision avec le sol. Les cas de disfonctionnements critiques sont nommés des évènements redoutés. Un évènement redouté, ou ER, peut être décomposé jusqu'à ses causes afin d'obtenir un arbre de défaillances. Un arbre de défaillances peut se représenter sous la forme d'un diagramme logique utilisant une structure arborescente pour représenter des défaillances et leurs combinaisons conduisant à un événement redouté. Une réduction des arbres de défaillances à partir d'un calcul de coupes minimales, permet d'identifier des scénarios critiques. Une coupe minimale est une combinaison d'évènements de base pouvant conduire à l'événement redouté, telle que si l'on retire un évènement de cette combinaison, l'événement redouté n'a plus lieu. La recherche des coupes minimales dans un arbre de défaillances est effectuée à partir des règles de l'algèbre de Boole en considérant que : chaque événement de base de l'arbre de défaillances correspond à une variable booléenne ; - un événement de sortie d'une porte ET de l'arbre de défaillances est associé au produit de variables booléennes correspondant aux évènements d'entrée de la porte ET ; - un événement de sortie d'une porte OU de l'arbre de défaillances est associé à la somme de variables booléennes correspondant à des 35 événements d'entrée.

A partir des coupes minimales, on déduit quels sont les éléments matériels et logiciels du système dont la ou les défaillances contribuent le plus à la réalisation de l'événement redouté. Par exemple, à partir des probabilités d'occurrence des évènements de base, on peut, en remontant dans l'arbre de défaillances, calculer une probabilité d'occurrence de l'événement redouté. Une coupe minimale peut être : • une coupe simple, c'est à dire ne comprenant qu'un unique événement de base aussi nommé panne simple ; • une coupe double, c'est à dire possédant deux évènements de base ; • une coupe triple, c'est à dire possédant trois événements de base. D'autres coupes multiples, c'est à dire possédant plus de trois événements de base, existent mais leur probabilité d'occurrence est en général négligeable en regard des probabilités d'occurrence des coupes simples, doubles et triples.

Une contrainte de sûreté de fonctionnement quantitative est, par exemple, d'obtenir l'événement redouté avec une probabilité inférieure à 10"9 par heure de vol. Une autre contrainte de sûreté de fonctionnement qualitative peut être qu'une panne simple, c'est à dire une panne spécifique affectant une partie délimitée du système, ne puisse pas produire un événement redouté. Une analyse d'un arbre de défaillances peut permettre en phase amont de privilégier une architecture matérielle ou logicielle, parmi plusieurs architectures, au vue des probabilités d'occurrence d'évènements redoutés et de l'existence de coupes simples, pour l'une ou l'autre des architectures proposées.

Exposé de l'art antérieur Une première étape pour évaluer la sûreté de fonctionnement d'un système complexe est notamment la traduction des spécifications du système en un modèle sur lequel s'appuient les analyses de sûreté de fonctionnement.

Une première méthode peut être de transcrire les spécifications du système en un modèle ayant un formalisme particulier comme le proposent 35 les méthodes UML, MDA ou MDE : • UML, acronyme anglo-saxon pour Unified Modeling Language signifiant langage de modélisation unifié, est un langage graphique de modélisation des données et des traitements d'un système ; UML est une formalisation d'une modélisation orientée objet utilisée notamment en génie logiciel ; • MDA, acronyme anglo-saxon pour Model Driven Architecture signifiant architecture dirigée par les modèles, a pour principe de base une élaboration de modèles, indépendants du type de plates-formes de mise en oeuvre du système, puis la transformation de ceux-ci en modèles dépendants du type de plates-formes pour l'implémentation concrète du système. Les techniques employées pour la MDA sont donc principalement des techniques de méta-modélisation et des techniques de transformation de modèles. • MDE, acronyme anglo- saxon pour Model Driven Engeenering signifiant ingénierie des modèles, utilise les principes de méta- modélisation proposés par la MDA pour permettre une capitalisation d'un processus depuis l'analyse jusqu'au code logiciel. Un premier moyen est donc de réduire le nombre de spécifications textuelles du système en les traduisant en modèle selon l'un des formalismes cités ci- dessus. De manière générale, un formalisme est d'autant meilleur qu'il permet de couvrir un maximum de spécifications textuelles. Des outils logiciels utilisant les formalismes cités ci-dessus permettent notamment une génération automatique ou semi-automatique de modèles de conception pour le système. La prise en compte de la sûreté de fonctionnement peut intervenir en intégrant des exigences relatives à la sûreté de fonctionnement dans les exigences du système. L'utilisation des modélisations UML, MDA, MDE pour produire des modèles adaptés à la sûreté de fonctionnement est complexe et nécessite un atelier complet d'outils logiciels spécifiques. De tels ateliers existent mais sont actuellement peu adaptés à la prise en compte de spécifications informelles de systèmes complexes. De plus ces outils ne sont pas adaptés à la prise en compte des contraintes de sûreté de fonctionnement. Les approches UML, MDA, MDE ne permettent donc pas de prendre en compte de manière satisfaisante les spécifications relatives à la sûreté de fonctionnement d'un système.

Une deuxième méthode peut être une génération automatique d'arbres de défaillance à l'aide d'outils logiciels spécifiques. Le système est dans un premier temps décrit sous la forme d'un modèle en utilisant un formalisme dépendant de l'outil logiciel utilisé. Le formalisme de ces outils offre la souplesse requise pour couvrir les contraintes et les spécifications de la sûreté de fonctionnement. L'outil logiciel comprend un générateur automatique d'arbres de défaillances dont les entrées sont le modèle décrit dans un premier temps et les valeurs des taux des défaillances. Le générateur détermine ensuite un ensemble exhaustif de coupes simples ou multiples relatives aux évènements redoutés définis par un concepteur du système, ainsi que leur probabilité d'occurrence. Un tel outil permet donc de cibler des points faibles du système en terme de sûreté de fonctionnement. L'outil permet également de vérifier, après révision éventuelle de l'architecture du système, que le système tient ses objectifs de sûreté de fonctionnement. Ces outils de génération automatique d'arbres de défaillances sont principalement utilisés pour des architectures physiques de systèmes. La fiabilité de ces outils de génération n'a pas été évaluée sur des architectures fonctionnelles complexes. De plus, la génération automatique d'arbres de défaillances est limitée par la taille du modèle d'entrée. Par exemple, une taille trop importante provoque une explosion combinatoire dans l'outil : l'utilisateur doit alors scinder son modèle en plusieurs modèles. La génération des coupes simples et multiples n'est, dans ce cas, pas exhaustive.

Une troisième méthode peut être une extension du formalisme des arbres de défaillances pour réaliser des arbres dynamiques. Les outils associés à la génération de ces arbres dynamiques utilisent un formalisme définissant de nouveaux types de portes logiques. Ces nouvelles portes logiques permettent de prendre en compte certains des aspects dynamiques du système. Les outils associés sont capables de générer des coupes simples ou multiples relatives à des évènements redoutés. Les outils associés à la création d'arbres dynamiques permettent également de définir un ordre d'occurrence des défaillances pour chaque coupe minimale avec les probabilités d'occurrence correspondantes. Cette approche offre donc par rapport aux approches purement statiques une meilleure prise en compte des spécifications amont du système dans leurs aspects dynamiques. Cependant cette troisième méthode reste encore dans un domaine expérimental : elle n'a pas fait ses preuves pour la prise en compte de systèmes complexes et notamment pour la construction d'arbres de défaillances dynamiques réellement représentatifs. De plus, un arbre de défaillances dynamique trop volumineux provoque, lors de la génération des coupes minimales, une explosion combinatoire plus fréquemment qu'un arbre de défaillances statique. L'extension du formalisme ne couvre, par ailleurs, que très partiellement la dynamique réelle d'un système complexe.

Une quatrième méthode peut être une modélisation et une simulation d'une architecture fonctionnelle à l'aide d'outils standards.

L'architecture est modélisée selon un formalisme propre à l'outil standard utilisé. Des simulations réalisées par ces outils standards permettent de détecter des séquences dynamiques de défaillances provoquant des événements redoutés. On peut ainsi mettre en évidence des combinaisons de défaillances qui échappent aux approches statiques classiques. Les probabilités d'occurrence des évènements redoutés sont mesurées par des simulations de longue durée de type Monte-Carlo. Un changement dans l'architecture fonctionnelle se traduit alors par une mesure différente des taux d'occurrence des évènements redoutés, et par une évolution des combinaisons dynamiques de défaillances provoquant ces évènements redoutés. En pratique, les outils disponibles pour mettre en oeuvre la quatrième méthode ne se prêtent pas toujours bien à la modélisation des défaillances et des événements redoutés. La construction du modèle est une tâche assez lourde, demandant beaucoup d'expertise. De plus les simulations quantitatives de type Monte-Carlo ont des durées beaucoup trop longues, si des méthodes d'accélération ne sont pas utilisées. De telles méthodes d'accélération provoquent cependant de multiples effets de bord et leur mise en oeuvre est délicate. Cette quatrième méthode est surtout intéressante pendant les phases de spécification et de conception détaillée du système, à un moment dans le cycle de réalisation du système où la dynamique du système ainsi que les défaillances à envisager sont bien connues. Pendant les phases amont de validation de l'architecture fonctionnelle du système, la quatrième méthode ne peut être mise en oeuvre du fait de l'insuffisance des données d'entrée que l'on doit fournir pour mettre en oeuvre la quatrième méthode. Pendant les phases de conception amont, cette méthode est donc trop lourde et trop coûteuse à mettre en oeuvre.

Une cinquième méthode peut être une méthode de construction manuelle d'arbres de défaillances en utilisant des outils informatiques adaptés. II s'agit d'une approche statique classique, utilisée généralement pour des architectures physiques. Cette cinquième méthode peut être utilisée pour décrire des architectures purement fonctionnelles. Une fois un arbre de défaillances saisi à l'aide des outils informatiques, les coupes simples et multiples sont générées automatiquement ainsi que les taux d'occurrence des évènements redoutés. La cinquième méthode, même si elle est peu coûteuse ne peut pas toujours être mise en oeuvre. De plus, cette cinquième méthode produit des résultats non exhaustifs du fait que l'arbre de défaillances ne contient que les combinaisons de défaillances qu'un expert en sûreté de fonctionnement peut imaginer. La complexité d'un arbre de défaillances correspondant à une architecture fonctionnelle standard requiert de la part d'un expert en sûreté de fonctionnement qu'il ait une vision globale du système. L'arbre de défaillances devient vite non maîtrisable de par la complexité de l'architecture fonctionnelle. De fait, seul un expert en sûreté de fonctionnement, maîtrisant parfaitement bien le système étudié, peut mener à bien la construction manuelle d'un tel arbre de défaillances avec un risque d'erreurs limité.

Une sixième méthode consiste à s'intéresser, pour chaque bloc de l'architecture fonctionnelle du système, aux combinaisons d'états de sorties pouvant provoquer des évènements redoutés. En pratique, on envisage pour chaque sortie de bloc fonctionnel trois états standards qui sont : • valeur présente et significative ; • valeur absente ; • valeur présente et non significative.

Parmi les états standards pour chaque sortie, on identifie ceux qui risquent de provoquer des événements redoutés. Des combinaisons d'états sont ensuite examinées. Il faut alors prévoir une architecture interne au bloc fonctionnel telle que ces combinaisons critiques ne puissent apparaître sur ses sorties. En cas d'impossibilité de modification de l'architecture du bloc fonctionnel, il est souhaitable d'installer de manière externe au bloc fonctionnel des mécanismes de surveillance capables de détecter ces combinaisons critiques et de les inhiber. Cependant, il n'est guère possible de déterminer avec certitude et 10 exhaustivité l'ensemble des combinaisons d'états de sortie de chaque bloc fonctionnel provoquant des évènements redoutés. Résumé de l'invention 15 Un but de l'invention est notamment de pallier les inconvénients précités en fournissant, pour diverses architectures fonctionnelles et, ou physiques d'un système, des critères d'évaluation et de comparaison de l'aptitude du système à éviter des évènements redoutés préalablement définis. 20 A cet effet, l'invention a pour objet un procédé d'évaluation de la sûreté de fonctionnement d'un système réalisant une macro-fonction. Le procédé selon l'invention peut comporter au moins les étapes suivantes : • Construction d'une architecture du système. L'architecture du système peut être décomposée en plusieurs blocs comportant chacun des 25 entrées/sorties de données. Les entrées d'un bloc sont notamment reliées aux sorties d'autres blocs de l'architecture ; • Identification de défaillances associées aux blocs de l'architecture ; • Construction de premières expressions booléennes. Les première expressions booléennes expriment notamment des états des sorties 30 des blocs de l'architecture en fonction d'états des défaillances identifiées, d'états des entrées des blocs ; • Construction d'une ou plusieurs deuxièmes expressions booléennes à partir des premières expressions booléennes. Chaque deuxième expression booléenne définie notamment un premier événement 35 redouté à examiner ; • Réduction de chaque deuxième expression booléenne en une première somme de monômes ; Le procédé selon l'invention peut comporter une étape de calcul d'une première probabilité d'occurrence pour chaque premier événement 5 redouté à partir de la première somme de monômes, correspondant au premier événement redouté, notamment en fonction de probabilités d'occurrence des défaillances identifiées. L'architecture peut être une architecture fonctionnelle. L'architecture peut être une architecture physique . 10 Le procédé selon l'invention peut notamment comporter des étapes de : • Construction d'une architecture physique décomposée en parties physiques réalisant des fonctions de l'architecture fonctionnelle ; • Projection des défaillances identifiées, associées aux blocs de 15 l'architecture fonctionnelle, sur les parties physiques ; • Identification de défaillances physiques à partir des défaillances fonctionnelles identifiées pour des sorties des blocs de l'architecture fonctionnelle ; • Construction de troisièmes expressions booléennes exprimant les 20 états des sorties des blocs de l'architecture fonctionnelle en fonction des défaillances physiques identifiées ; • Construction d'une ou plusieurs quatrièmes expressions booléennes à partir des premières expressions booléennes, chaque deuxième expression booléenne définissant par exemple un deuxième 25 événement redouté à examiner ; • Réduction de chaque quatrième expression booléenne en une deuxième somme de monômes ; • Calcul d'une deuxième probabilité d'occurrence pour chaque deuxième événement redouté à partir de probabilité d'occurrence des 30 défaillances physiques. L'étape d'identification de défaillances physiques peut comporter une première phase d'identification de modes communs, correspondant à des ensembles de parties physiques concourant à l'activation d'un même ensemble de défaillances fonctionnelles, et une deuxième phase d'association de chaque défaillance physique à chaque mode commun identifié. Les défaillances peuvent être des défaillances génériques. Les défaillances peuvent être des défaillances spécifiques aux traitements effectués par chaque bloc associé à une défaillance spécifique. Une défaillance générique peut s'exprimer en fonction des défaillances spécifiques identifiées. Un premier type de défaillance générique peut supprimer une information de sortie ; Un deuxième type de défaillance générique peut rendre non significative une information de sortie d'un bloc, supposée présente ; Un troisième type de défaillance générique peut forcer la présence d'une information de sortie non significative. Les défaillances peuvent prendre deux états : un premier état actif et un deuxième état inactif.

Un état d'une entrée et d'une sortie de type continu peut être traduit par deux booléens : un premier booléen exprimant une présence d'information d'entrée ou de sortie, un deuxième booléen exprimant une valeur non significative pour l'information. Une information de sortie ou d'entrée peut être de type énuméré 20 prendre un nombre n entier de valeurs d'énumération. Un état de sortie ou d'entrée de l'information d'énumération peut être exprimé par : • un troisième booléen par valeur d'énumération, ledit troisième booléen exprimant le caractère significatif associé à la valeur d'énumération du troisième booléen ; 25 • un quatrième booléen exprimant une valeur énumérée non significative ; • un cinquième booléen exprimant une absence d'information. Une information de sortie ou d'entrée pouvant être de type booléen, un état de sortie ou d'entrée est notamment défini par un sixième 30 booléen de présence d'information. Le procédé selon l'invention peut être adapté à un système avionique.

L'invention a notamment pour principaux avantages d'être simple et peu coûteuse à mettre en oeuvre au cours des différentes phases de définition et de développement d'un système complexe. Brève description des figures D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit, donnée à titre illustratif et non limitatif, et faite en regard des dessins annexés qui représentent : • la figure 1 : un exemple d'étapes possibles de réalisation d'un système ; • la figure 2: plusieurs étapes possibles du procédé selon l'invention appliqué à une architecture fonctionnelle ; • la figure 3: plusieurs étapes possibles du procédé selon l'invention appliqué à une architecture physique ; • la figure 4 : un exemple de décomposition en blocs fonctionnels d'une première architecture fonctionnelle ; • la figure 5 : un exemple de décomposition en parties physiques d'une architecture physique ; • la figure 6 : un exemple d'un bloc fonctionnel d'une deuxième architecture fonctionnelle ; • la figure 7: un autre exemple d'un bloc fonctionnel d'une troisième architecture fonctionnelle. Description de l'invention La figure 1 représente plusieurs tâches possibles permettant de réaliser un système 1 mettant en oeuvre une macro-fonction complexe. La réalisation du système 1 peut notamment comporter une première tâche de construction d'une architecture fonctionnelle 2. Une architecture fonctionnelle 2 est notamment construite en découpant la macro-fonction en blocs fonctionnels de taille réduite. Les blocs fonctionnels ainsi obtenus interagissent de manière à réaliser la macro-fonction. Une deuxième tâche de réalisation du système 1 peut être une projection de l'architecture fonctionnelle 2, issue de la première étape, sur une architecture physique 3. L'architecture physique 3 permet une mise en oeuvre de la macro-fonction par une mise en oeuvre des blocs fonctionnels de l'architecture fonctionnelle 2. L'architecture physique 3 peut être également découpée en blocs physiques. Un des objectifs de l'invention est de fournir pour diverses architectures fonctionnelles et, ou physiques, des critères d'évaluation et de comparaison de l'aptitude du système 1 à éviter des évènements redoutés préalablement définis. Les évènements redoutés sont des combinaisons ou des ensembles de combinaisons d'états de sorties primaires, et, ou d'états d'entrées primaires de la macro-fonction. Les entrées primaires et les sorties primaires sont respectivement les entrées et les sorties de la macro-fonction réalisée par l'architecture fonctionnelle. On peut définir trois états standards pour un signal d'entrée, un signal de sortie ou un signal interne : • présence d'une valeur et valeur significative ; • présence d'une valeur et valeur non significative ; • absence de valeur. Une défaillance interne à un bloc fonctionnel ou à un bloc physique peut affecter les états de sortie, et, ou les états de signaux internes à ce bloc. Deux types de critères d'évaluation peuvent être définis : un premier type de critère qualitatif et un deuxième type de critère quantitatif. Un critère qualitatif peut être : est-ce qu'une entrée erronée peut provoquer à elle seule un événement redouté ? Un autre critère qualitatif peut être : existe-t-il une défaillance provoquant à elle seule un événement redouté ? L'existence d'une entrée erronée provoquant à elle seule un événement redouté ou d'une défaillance provoquant à elle seule un événement redouté est un argument fort en défaveur d'une architecture fonctionnelle ou physique considérée. Un critère quantitatif peut être une probabilité d'occurrence maximale pour chaque événement redouté. Des valeurs élevées pour ces probabilités indiquent une architecture fonctionnelle ou physique non optimale. Le procédé selon l'invention peut traiter dans un premier temps une architecture fonctionnelle et éventuellement dans un second temps une architecture physique ou, uniquement une architecture physique.

La figure 2 représente un premier traitement 20 d'une architecture fonctionnelle ou physique, par plusieurs étapes successives possibles 21, 22, 23, 24, 25 du procédé d'analyse selon l'invention. Des données d'entrée du procédé selon l'invention sont notamment une décomposition d'une macro-fonction en blocs fonctionnels ou parties physiques. Un exemple d'architecture fonctionnelle et un exemple d'architecture physique sont détaillés par la suite. Dans le cas d'une architecture fonctionnelle, chaque bloc fonctionnel peut être décomposé en sous-blocs de plus faible granularité que le bloc fonctionnel. Les blocs fonctionnels du niveau à partir duquel on arrête la décomposition en sous-blocs sont par exemple désignés par le terme blocs fonctionnels de base . La granularité peut être définie comme un degré de complexité des blocs fonctionnels de base. La description du premier traitement 20 traite, pour exemple, le cas d'une architecture fonctionnelle. Les mêmes étapes peuvent s'appliquer de la même manière à une architecture physique. Une première étape 21 peut être une étape d'identification 21 des défaillances fonctionnelles pour les blocs fonctionnels de base. Les défaillances fonctionnelles peuvent par exemple se déduire des sous-fonctions de chaque bloc fonctionnel de base. II est à noter que l'on n'associe pas explicitement à une sous-fonction un bloc fonctionnel Une deuxième étape 22 peut être une étape de construction 22 d'expressions booléennes associées à chacun des trois états standards des sorties de chaque bloc fonctionnel de base. Pour chaque sortie de chaque bloc fonctionnel de base, les trois états standards peuvent être exprimés sous la forme d'une combinaison, ou d'un ensemble de combinaisons, d'états des entrées du bloc et d'états de défaillances identifiées pour ce bloc. Les états des défaillances peuvent être par exemple : actif ou inactif. A chacun des trois états d'une sortie d'un bloc fonctionnel de base on peut alors associer une expression booléenne construite à partir des trois états de chaque entrée et des deux états possibles des défaillances. Une troisième étape 23 peut être une étape d'expression 23 d'un ER que l'on souhaite étudier. L'ER est défini dès la phase de spécification de la macrofonction. L'étape 23 permet d'exprimer l'ER sous la forme d'une expression booléenne construite par exemple à partir des trois états standards possibles pour des entrées primaires, ainsi que des deux états possibles pour des défaillances fonctionnelles. Les entrées primaires sont les entrées de la macro-fonction réalisée par l'architecture fonctionnelle. Une quatrième étape 24 est une étape de réduction 24 de l'expression booléenne associée à l'ER en une expression booléenne minimale. Parmi les trois états standards possibles pour une entrée primaire, deux états standards sont considérés comme erronés : la présence d'une valeur et valeur non significative ainsi que l'absence de valeur ; le troisième état standard : la présence d'une valeur et valeur significative, étant un état standard correct. Une expression booléenne minimale est une somme de produits construite à partir des deux états erronés possibles des entrées primaires et de l'état actif, s'il y a lieu, des défaillances associées aux blocs fonctionnels. Les défaillances à l'état inactif ne figurent pas dans l'expression booléenne minimale. Pour un ER, on dispose alors d'un ensemble exhaustif de combinaisons de défaillances et, ou d'états erronés d'entrée primaires provoquant l'ER. Cet ensemble de combinaisons de défaillances permet d'évaluer qualitativement l'architecture fonctionnelle en permettant notamment l'identification : ^ de défaillances simples provoquant l'ER ; ^ des états erronés d'entrées primaires simples provoquant l'ER. Une cinquième étape 25 peut être une étape optionnelle de calcul 25 de la probabilité d'occurrence de l'ER. Le calcul 25 de la probabilité d'occurrence de l'ER n'est possible que si l'on dispose des valeurs de probabilités de défaillances et des probabilités associées aux états erronés des entrées primaires. La probabilité d'occurrence d'un ER permet une évaluation quantitative de la sûreté de fonctionnement de l'architecture fonctionnelle. Le premier traitement 20 peut être poursuivi par l'expression d'un nouvel ER en reprenant le premier traitement 20 à partir de la troisième étape 23. On peut ainsi balayer tous les cas d'ER pour chaque architecture fonctionnelle et, ou physique. De manière itérative, lorsque l'architecture fonctionnelle et, ou physique est définie avec une granularité plus fine du découpage en blocs fonctionnels de base de la macro-fonction, le premier traitement 20 peut être appliqué à cette nouvelle décomposition en blocs fonctionnels de base. Ainsi, au cours du cycle de développement du système, il est possible d'effectuer plusieurs analyses et plusieurs évaluations des architectures fonctionnelles et physiques proposées.

La figure 3 représente un deuxième traitement 30 d'une architecture physique associée à une architecture fonctionnelle, le premier traitement 20 étant supposé effectué. Le deuxième traitement 30 comporte plusieurs étapes possibles successives 31, 21, 22, 23, 24, 25. Lorsque l'on connaît une architecture physique associée à une architecture fonctionnelle pour réaliser la macrofonction, il est possible de valider conjointement l'architecture fonctionnelle et l'architecture physique en utilisant le procédé selon l'invention. Le deuxième traitement 30 prend notamment en compte une décomposition de l'architecture fonctionnelle envisagée en parties physiques de base de plus faible granularité que les blocs fonctionnels de base. Le deuxième traitement 30 utilise également une projection des blocs fonctionnels de base sur les parties physiques de base. On dispose alors pour chaque bloc fonctionnel de base d'une liste de parties physiques de base contribuant à sa réalisation. Le deuxième traitement 30 peut également prendre en compte des valeurs de taux de défaillances pour chaque partie physique. Une première étape 31 du deuxième traitement 30 peut être une étape de projection 31 des défaillances identifiées pour les blocs fonctionnels de base sur les parties physiques de base. II s'agit donc de faire une liste des composants physiques de base contribuant à chaque défaillance fonctionnelle identifiée. Une deuxième étape du deuxième traitement 30 correspond à l'étape 21 du premier traitement 20 qui est une étape d'identification de défaillances physiques. Les défaillances physiques peuvent être identifiées en considérant pour chaque partie physique de base une liste des défaillances fonctionnelles associées. Les défaillances physiques sont indépendantes les unes des autres car elles correspondent à des parties physiques de base et, ou des ensembles de parties physiques de base tous disjoints. Une troisième étape du deuxième traitement 30 correspond à l'étape 22 du premier traitement 20 qui est une étape de construction des expressions booléennes associées aux sorties des blocs fonctionnels de base en utilisant les défaillances physiques à la place des défaillances fonctionnelles. Donc à chaque état standard de sortie d'un bloc fonctionnel de base est associée une expression booléenne construite à partir des trois états standards possibles des entrées du bloc fonctionnel de base et des deux états possibles pour chaque défaillance physique associée au bloc fonctionnel de base. Une quatrième étape du deuxième traitement 30 correspond à l'étape 23 du premier traitement 20 qui est une étape de construction d'une expression booléenne caractérisant un ER, en fonction des trois états possibles des entrées primaires de la macro-fonction ainsi que des deux états possibles des défaillances physiques. Une cinquième étape du deuxième traitement 30 correspond à l'étape 24 du premier traitement 20 qui est une étape de réduction de l'expression booléenne associée à l'ER en une expression booléenne minimale. L'expression booléenne minimale est obtenue à partir de l'expression booléenne construite au cours de la quatrième étape du deuxième traitement 30. L'expression booléenne minimale peut s'exprimer sous la forme d'une somme de produits des deux états erronés possibles des entrées primaires et des défaillances physiques à l'état actif, s'il y a lieu. Une expression booléenne minimale peut être obtenue de façon automatique en utilisant une procédure logicielle dédiée ou en utilisant un moteur de minimisation d'expressions logiques. On dispose alors d'informations d'évaluation qualitatives des architectures fonctionnelles et physiques qui sont : les défaillances physiques simples provoquant l'ER et les entrées primaires simples erronées provoquant l'ER, si elles existent. Ces informations tiennent compte de modes communs introduits entre les défaillances fonctionnelles lors de la projection de l'architecture fonctionelle sur l'architecture physique. Un mode commun est par exemple un ensemble de défaillances fonctionnelles affectant plusieurs sorties des blocs fonctionnels en même temps. Une sixième étape 25 du deuxième traitement 30 permet de calculer la probabilité d'occurrence de l'ER lorsque l'on connaît les valeurs de taux de défaillances pour chaque défaillance physique, ainsi que les taux de défaillances associés aux états erronés des entrées primaires. Cette probabilité d'occurrence dépend d'une part de l'architecture fonctionnelle et d'autre part de l'architecture physique sur laquelle est projetée l'architecture fonctionnelle. La définition d'un nouvel ER peut être prise en compte en reprenant le deuxième traitement 30 à partir de la quatrième étape 23. On peut ainsi balayer tous les cas d'ER. De manière itérative, lorsque les architectures fonctionnelles et physiques sont définies avec une granularité plus fine, le premier traitement 20 et le deuxième traitement 30 peut être appliqué à cette nouvelle décomposition en blocs de base. Les résultats obtenus par exemple à une étape n du développement du système peuvent donc être affinés à une étape n+1.

La figure 4 représente un exemple d'une architecture fonctionnelle 40. L'architecture fonctionnelle 40 réalise une macro-fonction d'affichage de réticules de vol et de navigation. Des réticules de vol et de navigation sont des informations de vol et de navigation affichées sur un écran par exemple. Une information de vol ou de navigation peut être une vitesse, une altitude, un cap. L'architecture fonctionnelle 40 est découpée en plusieurs blocs fonctionnels de base BR, ROUT_BR_DP, DP, ROUT DP_GP, GP, VIS, ROUT DP AP, AP. Le bloc de base ROUT DP AP n'est pas représenté sur la figure, par souci de lisibilité. Chaque bloc fonctionnel de base BR, ROUT_BR_DP, DP, ROUT_DP_GP, GP, VIS, ROUI DP AP, AP réalise une ou plusieurs sous-fonctions. Des entrées primaires, de l'architecture fonctionnelle 40 représentée sur la figure 4, peuvent être : • des données inertielles nommées Dl, consol, conso2: les données inertielles Dl, consol, conso2 sont redondantes, c'est-à-dire qu'un contrôle de cohérence nommé ConsoLoc permet de vérifier la compatibilité des données inertielles de base DI avec les données inertielles de consolidation consol, conso2. • des données de vol DA et DB : les données de vol DA, DB représentent les mêmes informations, par exemple une altitude, mais peuvent provenir d'équipements différents. Des sorties primaires de l'architecture fonctionnelle 40 représentée sur la figure 4 peuvent être : • des réticules nommés Ret_NAV et Ret_VOL qui sont respectivement des réticules de navigation et des réticules de vol. • une alarme notée AL. Le traitement et l'acheminement des informations, comme les entrées primaires, peuvent se faire au sein de l'architecture fonctionnelle 40 comme décrit ci-après. Les données inertielles Dl, Consol, Conso2 ainsi que les données de vol DA, DB peuvent être présentées en entrée BR_Vl_ln, BR_V2_ln de deux voies d'acquisition V1, V2 d'un bloc fonctionnel d'acquisition BR. Une première entrée BR_V1_In correspond par exemple à une première voie V1, et une deuxième entrée BR_V2_ln correspond par exemple à une deuxème voie V2. Les données inertielles Dl, Consol, Conso2 et les données de vol DA, DB sont acquises et transmises sur une voie active du bloc d'acquisition BR. Une voie active peut être la première voie VI, la deuxième voie V2 étant alors inactive : c'est un cas de fonctionnement nominal, c'est à dire un fonctionnement stantdard. Si la première voie V1 devient une voie inactive suite à une défaillance du bloc d'acquisition BR alors la deuxième voie V2 est activée : c'est un cas de fonctionnement dégradé. Les données inertielles acquises Dl, consol, conso2, DA, DB par le bloc d'acquisition BR sortent du bloc d'acquisition BR soit par une première sortie BR_V1_Out, correspondant à la première voie V1 si elle est active, soit par une deuxième sortie BR_V2_Out correspondant à la deuxième voie V2 si elle est active. Les données inertielles Dl, consol, conso2 ainsi que les données de vol DA, DB peuvent ensuite être acheminées vers un bloc de traitement de données DP par l'intermédiaire d'un premier bloc de routage ROUT_BR_DP. Un bloc de routage est un bloc fonctionnel de base capable de sélectionner des informations en entrée et de les acheminer vers les bons destinataires. Le premier bloc de routage ROUT_BR_DP peut notamment sélectionner les informations d'une sortie active BR_V1_Out, BR_V2_Out du bloc d'acquisition BR. En sortie du premier bloc de routage ROUT_BR_DP, on retrouve donc les données inertielles Dl, consol, conso2 et les données de vol DA, DB. Le bloc de traitement DP reçoit sur ses deux entrées DP_V1_In, DP_V2_In, les données inertielles Dl, consol, conso2, les deux voies V1 et V2 de DP étant simultanément actives dans un cas de fonctionnement nominal. L'entrée DP_V1_ln reçoit également les données de vol DA, l'entrée DP V2_In reçoit également les données de vol DB. Le bloc de traitement DP effectue sur les deux voies V1, V2 le contrôle de cohérence ConsoLoc des données inertielles DI, consol, conso2. En cas d'incohérence, un compte-rendu d'erreur DP_V1_ConsoLoc, DP_V2_ConsoLoc est généré par le bloc de traitement DP sur les voies V1, V2. Les compte-rendus d'erreur DP_V1_ConsoLoc, DP_V2_ConsoLoc sont ensuite tous deux transmis à chacune des entrées ConsoLoc Chant, ConsoLoc Chan2 correspondant à deux voies Chant et Chan2 d'un bloc fonctionnel AP. Par ailleurs, sur chaque voie V1, V2, le bloc de traitement DP calcule les réticules de navigation et de vol RET_NAV, RET_VOL. Le calcul des réticules de navigation RET_NAV utilise comme données d'entrée les données inertielles de base Dl consolidées. Le calcul des réticules de vol utilise des premières données de vol DA sur la première voie V1 et des deuxièmes données de vol DB sur la deuxième voie V2. Les réticules de vol RET_VOL et de navigation RET NAV sont ensuite transmis à un bloc de traitement graphique GP par l'intermédiaire d'un deuxième routeur ROUI DP GP. Le bloc de traitement graphique GP comporte également deux voies de traitement V1, V2. Les réticules de navigation RET_NAV et de vol RUVOL sont présentés en entrée des deux voies VI, V2 du bloc de traitement graphique GP simultanément actives, dans un cas de fonctionnement nominal. Chacune des deux voies VI, V2 du bloc de traitement graphique GP calcule les coordonnées cartésiennes Posi_NAV, Posi_VOL utilisées pour l'affichage des réticules reçus et les transmet à un bloc de visualisation VIS. La réception, par le bloc de traitement graphique GP sur ses deux voies, des réticules RET_VOL et RET_NAV permet également de générer un message Pres_Ret simultanément sur chacune des deux voies V1, V2 du bloc de traitement graphique GP. Le message Pres_Ret indique la présence des coordonnées cartésiennes Posi_NAV, Posi_VOL des réticules RET_NAV, RET VOL.. Les messages Pres_Ret sont ensuite transmis à deux voies V1 et V2 du bloc de visualisation VIS. Lorsque les coordonnées cartésiennes Posi_NAV, Posi_VOL des réticules RET_NAV, RET VOL sont reçues sur les deux voies V1, V2 du bloc de visualisation VIS, un test de cohérence ConsoRet est effectué par le bloc de visualisation VIS. En cas d'incohérence, un message d'erreur Conso_Ret_Er est généré par le bloc de visualision et diffusé sur les deux voies V1 et V2 du bloc de visualisation VIS à destination des deux voies V1, V2 du bloc de traitement graphique GP. L'affichage des réticules RET_NAV, RET VOL est effectué quels que soient les résultats du test de cohérence ConsoRet. Dans un cas nominal, les réticules RET_NAV, RET_VOL peuvent être présents sur la première voie V1 de VIS, dans ce cas, les réticules RET_NAV, RET_ VOL affichés par le bloc de visualisation VIS sont issus de la première voie V1 du bloc de visualisation VIS. Les réticules RET_NAV, RET VOL affichés sur l'écran sont issus de la voie V2 de VIS en cas d'absence de réticules sur la première voie V1 du bloc de visualisation VIS, dans un cas de fonctionnement dégradé. Les messages Conso_Ret_Er issus des deux voies V1 et V2 du bloc de visualisation VIS sont ensuite transmis simultanément sur les deux voies V1 et V2 du bloc de traitement DP par l'intermédiaire du premier routeur ROUT_DP_GP. Si la première voie V1 de DP est inactive dans un cas de fonctionnement dégradé, le message Conso_Ret_Er issu de la première voie V1 du bloc de traitement graphique GP est présenté en entrée de la deuxième voie V2 de DP. Si la deuxième voie V2 de DP est inactive dans un autre cas de fonctionnement dégradé, le message Conso_Ret_Er issu de la première voie V1 du bloc de traitement graphique GP est par exemple présenté sur la première voie V1 de DP. Pour ces cas de fonctionnement dégradés, le message Conso_Ret_Er issu de la deuxième voie V2 du bloc de traitement graphique GP est ignoré par DP. Les messages Conso_Ret_Er reçus sur les voies V1, V2 du bloc de traitement DP sont tous deux présentés sur chacune des entrées Conso_Ret_Chan1, Consol_Ret_Chan2 correspondant aux deux voies Chant et Chan2 du bloc fonctionnel AP, par l'intermédiaire du bloc de routage ROUT_DP_AP non représenté sur la figure 4. Lorsque la première voie Chant du bloc fonctionnel AP est active et la deuxième voie Chan2 du bloc fonctionnel AP est inactive, dans un cas de fonctionnement nominal, et qu'au moins un message de type Conso_Ret_Er ou un compte rendu d'erreur ConsoLoc a été reçu sur la première voie Chant du bloc fonctionnel AP, alors une alarme AL est générée par le bloc fonctionnel AP sur la voie Chant du bloc fonctionnel AP. L'alarme AL générée est présentée en entrée des deux voies V1, V2 du bloc de traitement DP via le troisième bloc de routage ROUT_DP_AP. Dans un cas de fonctionnement dégradé où la première voie Chant du bloc fonctionnel AP est inactive et la deuxième voie Chan2 du bloc fonctionnel AP est active, les messages Conso_Ret_Er ou compte-rendu ConsoLoc reçus sur la deuxième voie Chan2 du bloc fonctionnel AP sont sélectionnés. Un message d'alarme AL issu de la deuxième voie Chan2 du bloc fonctionnel AP est ensuite présenté en entrée des deux voies V1,V2 du bloc de traitement DP via le troisième bloc de routage ROUT_DP_AP. Le message d'alarme AL reçu sur les deux voies VI ,V2 du bloc de traitement DP est successivement transmis aux deux voies V1, V2 du bloc de traitement graphique par l'intermédiaire du deuxième routeur ROUI DP_GP puis aux deux voies V1, V2 du bloc de visualisation VIS. La sortie du message d'alarme AL est activée uniquement si un message d'alarme AL est reçu sur au moins l'une des deux voies V1, V2 du bloc de visualisation VIS. Une fois le découpage en blocs fonctionnels de l'architecture fonctionnelle 40 effectué, les différentes étapes du premier traitement 20 peuvent être déroulées en prenant par exemple le bloc de traitement DP. Les sous-fonctions associées à chaque voie V1, V2 du bloc de traitement DP sont notamment les suivantes : ^ recevoir des données venant de l'extérieur du bloc de traitement DP ; • transmettre des données vers l'extérieur du bloc de traitement DP ; ^ effectuer le test de cohérence ConsoLoc entre les données inertielles Dl, consol et conso2 ; • calculer le réticule de navigation Ret_NAV à partir des données inertielles de base Dl ; • pour la voie VI, calculer le réticule de vol Ret_VOL à partir des données de vol DA ; ^ pour la voie V2, calculer le réticule de vol Ret_VOL à partir des données de vol DB ; ^ transférer le message d'erreur éventuel Conso_Ret_Er reçu en entrée vers l'extérieur bloc de traitement DP ; ^ transférer le message d'alarme éventuel AL reçu en entrée vers l'extérieur du bloc de traitement DP.

La première étape 21 du procédé d'analyse selon l'invention est l'identification des défaillances fonctionnelles. Par exemple pour les sous-fonctions associées à la première voie V1 de DP, on peut définir les défaillances suivantes : • Corr Rec : représente une corruption des données d'entrée pendant leur réception ; ^ Corr_Trans : représente une corruption des données pendant leur transmission ; ^ ConsoLoc_Fail : représente des incohérences non détectées ; ^ Ret_NAV Comp_Fail : représente un calcul erroné des réticules de navigation Ret_NAV ; ^ Ret_VOL_Comp_Fail : représente un calcul erroné des réticules de vol Ret_VOL ; ^ ConsoRet_Comp_Fail : représente une corruption du message d'erreur Conso_Ret_Er issu du bloc de traitement graphique GP pendant son transfert vers le bloc fonctionnel AP ; ^ AL_Comp_Fail : représente une corruption du message d'alarme AL issu du bloc fonctionnel AP pendant son transfert vers le bloc de traitement graphique GP ; ^ Lost AII_Fcts : représente une perte de toutes les fonctions rendant la première voie V1 complètement inactive.

La deuxième étape 22 du procédé selon l'invention est l'étape de construction des expressions booléennes associées aux états des sorties du bloc de traitement DP par exemple.

Une notation synthétique est judicieusement utilisée par le procédé d'analyse selon l'invention afin de construire les expressions booléennes. La notation synthétique est définie par un ensemble de notations tel que défini ci-après.

Pour chaque signal comme une entrée primaire, une sortie primaire, un signal interne, et par exemple pour la donnée inertielle de base DI, des variables booléennes DI.VAL, DI.NO et DI.VD peuvent être introduites : ^ DI.VAL = 1 quand la donnée inertielle de base Dl véhicule une valeur, que celle-ci soit significative ou non significative ; ^ DI.NO = -,DI.VAL = 1, c'est-à-dire DI.NO vaut l'opposé de DI.VAL, quand la donnée inertielle de base Dl ne véhicule aucune valeur, par exemple lorsque l'entrée est absente ; ^ DI.FL = 1 quand la valeur véhiculée par la donnée inertielle de base Dl n'est pas significative ; ^ DI.VD = -'DI.FL = 1, c'est-à-dire DI.DV vaut l'opposé de DI.FL, quand la valeur véhiculée par la donnée inertielle de base Dl est significative ; La notation adoptée par la suite signifie l'opposé de la valeur qui suit. Les variables DI.FL et DI.VD n'ont de sens que si la donnée inertielle de base DI véhicule une valeur. Dans le cas contraire, lorsque DI.NO = 1, l'état des variables DI.FL et DI.VD à 0 ou à 1 est sans signification. De plus, DI.FL = 1 et DI.VAL = 1 ne signifie pas que DI.VAL devrait véhiculer une autre valeur, mais que sa valeur courante est non significative. En d'autres termes, en l'absence d'erreur, la donnée inertielle de base DI pourrait être présente ou absente selon les cas, et sa valeur actuelle, s'il y a lieu, peut très bien être par hasard correcte. Ce dernier cas est fréquent avec des signaux ne prenant qu'un nombre réduit d'états discrets. Pour chaque défaillance, notée failure terme anglo-saxon signifiant défaillance, affectant les sorties de un ou plusieurs blocs fonctionnels, les variables booléennes suivantes peuvent êre introduites : failure.A et failure.). ^ faiture.A = 1 quand la défaillance est active ; ^ failure.) = -ifailure.A = 1 quand la défaillance est inactive.

D'autres variables booléennes peuvent être utilisées pour des expressions associées aux sorties des blocs fonctionnels. Ainsi les états actif et inactif de la première voie V1 du bloc de traitement DP peuvent être représentés par deux variables notées DP:V1_Act.T et DP:V1 Act.F : ^ DP:V1 Act.T = 1 quand la voie V1 est active, dans un cas nominal ; ^ DP:V1 Act.F = ~DP:V1 Act.T = 1 quand la voie V1 est inactive, dans un cas dégradé.

Une première expression booléenne peut décrire la valeur DP:V1_Ret NAV.VAL du réticule de navigation Ret_NAV en sortie de la première voie V1 du bloc fonctionnel DP :

DP:V1 Ret NAV.VAL = DP:V1 Act.T * DP:V1 Lost All Fcts.l * DP:V1_DI.VAL * (DP:V1_Corr Rec.I + DP:V1_ConsoLoc_Fail.A) (100)

Dans la première expression booléenne (100) ainsi que par la suite, le terme * représente une fonction ET logique et le terme + une fonction OU logique. La première expression booléenne (100) exprime notamment le fait que le réticule de navigation Ret_NAV véhicule une valeur sur la première voie V1, si la première voie V1 est active et si la donnée inertielle de base Dl porte aussi une valeur. Le terme DP:V1_Corr Rec.I + DP:V1_ConsoLoc_Fail.A provient du fait que si les données inertielles de base Dl sont corrompues en réception, cette corruption est détectée par le contrôle de cohérence ConsoLoc. Le réticule de navigation Ret NAV n'est alors ni calculé ni transmis, sauf si le contrôle ConsoLoc est lui-même défaillant.

Une deuxième expression booléenne peut décrire l'aspect significatif de l'éventuelle valeur véhiculée par le réticule de navigation Ret NAV :

DP:V1 Ret NAV.FL = DP:V1 Corr Rec.A * DP:V1 ConsoLoc Fail.A + DP:V1_Ret_NAV_Comp_Fail.A + DP:V1_Corr Trans.A + DP:V1_DI.FL (101) La deuxième expression booléenne (101) sous-entend que DP:V1_Ret_NAV.VAL=1. La deuxième expression booléenne (101) indique que la valeur calculée n'est pas significative : • si les données inertielles d'entrée Dl sont non significatives ; ^ si le calcul du réticule de navigation Ret_NAV est défaillant ; ^ si le réticule de navigation Ret NAV est corrompu en transmission ; ^ si les données reçues sont corrompues en réception sans que cette corruption soit détectée, auquel cas la valeur calculée est non significative.

Une troisième expression booléenne permet de décrire la valeur DP:V1_ConsoLoc.VAL du compte rendu d'erreur généré par le contrôle de cohérence ConsoLoc effectué par le bloc de traitement DP :

DP:V1_ConsoLoc.VAL = DP:V1 Act.T * (DP:V1_Corr_Rec.A + DP:V1_DI.FL + DP:V1 DI.NO + DP:V1 Consol.FL + DP:V1 Consol.NO + DP:V1_Conso2.FL + DP:V1_Conso2.NO) * DP:V1_ConsoLoc_Fail.l * DP:V1_Lost_AII_Fcts.I (103)

La troisième expression booléenne (103) donnant DP:V1_ConsoLoc.VAL indique que le compte rendu d'erreur DP V1_ConsoLoc effectué par la fonction ConsoLoc est généré si les données inertielles Dl et, ou, les données de consolidation Consol, Consol présentées en entrée du bloc de traitement DP sont corrompues ou absentes ou si elles sont corrompues en réception. Il faut en plus de ces conditions que le contrôle de cohérence ConsoLoc ne soit pas défaillant, sinon aucun compte-rendu d'erreur DP_V1_ConsoLoc n'est transmis, et que la première voie VI du bloc de traitement DP soit active.

Une quatrième expression booléenne permet de décrire l'aspect significatif de l'éventuelle valeur véhiculée par le compte-rendu d'erreur DP V1 ConsoLoc : DP:V1_ConsoLoc.FL = DP:V1_Corr Trans.A (104) La quatrième expression booléenne (104) donnant DP:V1_ConsoLoc.FL suppose que le compte rendu d'erreur DP_V1_ConsoLoc est généré avec une valeur, donc que DP:V1_ConsoLoc.VAL=1. Si l'on définit une défaillance nommée ConsoLoc_Fail comme provoquant une perte du compte-rendu d'erreur DP_V1_ConsoLoc éventuel mais pas sa corruption, il ne reste alors qu'une défaillance notée Corr Trans pour corrompre le compte-rendu d'erreur DP VI ConsoLoc en sortie du bloc de traitement DP.

Des hypothèses différentes de défaillances peuvent donner des expressions booléennes différentes des expressions booléennes (100), (101), (102), (103). A titre d'exemple, de la même manière que pour le bloc de traitement DP, on peut écrire pour les variables de sortie DP_DI, DP_consol , DP_conso2, DP_V1_DA, DP_V2_DB du premier bloc de routage ROU_BR_DP les expressions booléennes suivantes :

^ DP DI.VAL = BR:VI_Act.T * DI BR V1.VAL + BR:V2_Act.T * DI_BR_V2.VAL DP DI.FL = BR:V1 Act.T * DI BR V1.FL + BR:V2_Act.T * DI BR V2.FL

DP Consol .VAL = BR:V1 Act.T * Consol BR V1.VAL + BR:V2_Act.T * Consol_BR_V2.VAL DP_Consol.FL = BR:VI_Act.T * Consol BR VI.FL + BR:V2_Act.T * Consol BR V2.FL

DP Conso2.VAL = BR:V1 Act.T * Conso2 BR V1.VAL + BR:V2 Act.T * Conso2_BR_V2.VAL DP_Conso2.FL = BR:V1 Act.T * Conso2 BR V1.FL + BR:V2_Act.T * Conso2_BR_V2.FL

^ DP VI DA.VAL = BR:VI_Act.T * DA BR VI.VAL + BR:V2_Act.T * DA_B R_V2. VAL DP V1 DA.FL = BR:VI_Act.T * DA BR V1.FL + BR:V2_Act.T * DA_BR_V2.FL ^ DP V2 DB.VAL = BR:V1 Act.T * DB BR V1.VAL + BR:V2_Act.T * DB_BR_V2.VAL DP V2 DB.FL = BR:V1 Act.T * DB BR V1.FL + BR:V2 Act T * DB_BR_V2. FL

Les expressions booléennes de variables de sortie du premier bloc de routage ROUT_BR_DP peuvent être complétées par des expressions représentant les connexions entre les entrées et les sorties des blocs : de traitement DP, d'acquisition BR et de routage ROUT_BR DP. Ces expressions peuvent être par exemple : ^ DP:V1 DI.VAL = DP DAVAL ^ DP:V1 DI.FL = DP_DI.FL ^ DP:V1_Consol.VAL = DP Consol.VAL ^ DP:V1_ Consol .FL = DP_ Consol .FL ^ DP:V1 Conso2.VAL = DP Conso2.VAL ^ DP:V1_ Conso2.FL = DP_ Conso2.FL ^ DP:V1 DA.VAL = DP DA.VAL ^ DP:V1 DA.FL = DP DA.FL ^ DP:V2 Dl VAL = DP DI.VAL ^ DP:V2 DI.FL = DP_DI.FL ^ DP:V2 Consol .VAL = DP Consol .VAL ^ DP:V2 Consol .FL = DP_ Consol .FL ^ DP:V2_Conso2.VAL = DP_Conso2.VAL ^ DP:V2_ Conso2.FL = DP_ Conso2.FL ^ DP:V2 DB.VAL = DP DB.VAL ^ DP:V2_DB.FL = DP_DB.FL et également : ^ DI BR V1.VAL = BR:V1 DIVAL ^ Dl BR V1.FL = BR:V1 DI.FL ^ Consol BR V1.VAL = BR:V1 Consol .VAL • Consol BR V1 .FL = BR:V1 Consol .FL ^ Consol BR V1.VAL = BR:V1_Conso2.VAL ^ Consol BR V1.FL = BR:V1_Conso2.FL ^ DA BR V1.VAL = BR:V1 DA.VAL ^ DA BR V1.FL = BR:V1 DA.FL ^ DB BR V1.VAL = BR:V1 DB.VAL ^ DB BR V1.FL = BR:V1 DB.FL ^ Dl BR V2.VAL = BR:V2 DI.VAL ^ Dl BR V2.FL = BR:V2 DI.FL ^ Consol BR V2 VAL = BR:V2 Consol .VAL • Consol BR V2 FL = BR:V2 Consol.FL ^ Conso2 BR V2 VAL = BR•V2 Conso2.VAL ^ Conso2 BR V2.FL = BR:V2 Conso2.FL ^ DA BR V2.VAL = BR:V2 DA.VAL ^ DA BR V2.FL = BR:V2 DA.FL ^ DB BR V2.VAL = BR:V2 DB.VAL ^ DB BR V2.FL = BR:V2 DB.FL La troisième étape 23 est la traduction sous forme d'une expression logique des événements redoutés. A titre d'exemple, un événement redouté à éviter peut être un affichage d'un réticule erroné sans alarme. Cet événement peut s'exprimer par la condition booléenne suivante : (VIS:Ret_NAV.VAL * VIS:Ret_NAV.FL + VIS:Ret_VOL.VAL * VIS:Ret_VOL.FL) * VIS:AL.NO = 1 (105) Chacun des termes intervenant dans l'expression de la condition booléenne (105) est ensuite développé à l'aide des équations établies au cours de la deuxième étape 22. On remonte ainsi de proche en proche jusqu'aux termes élémentaires, qui sont des variables associées aux entrées primaires et aux défaillances de l'architecture fonctionnelle 40.

La quatrième étape 24 est la réduction de la condition booléenne (105) en expression minimale selon les règles de simplification de logique booléenne. Dans un dernier temps, les termes de la forme failure.l sont remplacés par la valeur 1 , conduisant ainsi à des simplifications supplémentaires de la condition booléenne (105). L'expression finalement obtenue est une somme de monômes minimaux, chaque monôme étant l'équivalent d'une coupe minimale pour l'arbre de défaillances équivalent à l'expression de la condition booléenne (105).

L'algorithme utilisé pour la quatrième étape 24 peut être, selon une méthode classique, basé sur des diagrammes de décision binaire couramment appellé en langage anglo-saxon Binary Decision Diagrams. Une routine logicielle implémentant une méthode basée sur des diagrammes de décision binaire présente par exemple les monômes par ordre croissant du nombre de défaillances dans chaque monôme.

Des premiers monômes comportant chacun deux défaillances et correspondant à des coupes minimales doubles dans l'arbre de défaillances équivalent à l'expression de la condition booléenne (105) sont par exemple les suivants : • GP:V2_AL_Comp_Fail.A*DP:V1_Corr Trans.A • DP:V2 AL_Comp_Fail.A*DP:V1_Corr Trans.A • DP:V2 Corr Trans.A*DP:V1 Corr Trans.A • DP:V2 Lost AIL Fcts.A*DP:V1 Corr Trans.A • DP:V2 Corr Rec.A*DP:V1 Corr Trans.A • GP:V2 Corr Rec.A*DP:V1 Corr Trans.A • GP:V2 Lost ARINC.A*DP:V1 Corr Trans.A

Des deuxièmes monômes comportent chacun trois défaillances et correspondant donc à des coupes minimales triples dans l'arbre de défaillances équivalent à l'expression de la condition booléenne (105) : • VIS: Lost AL.A*DP:V1 Corr Rec.A*DP:V1 ConsoLoc Fail.A • AP:V1_Comp_Fail.A*DP:V1_Corr Rec.A*DP:V1_ConsoLoc Fail.A • AP:V1 Corr Trans.A*DP:V1 Corr Rec.A*DP:V1 ConsoLoc Fail.A • AP:V1 Lost AIL Fcts.A*DP:V1 Corr Rec.A*DP:V1 ConsoLoc Fail • AP:V1 Corr Rec. A*DP:V1 Corr Rec.A*DP:V1 ConsoLoc Fail.A

Les résultats fournis par la routine logicielle indiquent qu'aucune défaillance simple n'est capable à elle seule de produire un ER, en effet la routine logicielle ne fournie que des monômes comportant deux ou trois défaillances dans cet exemple. Ceci permet de répondre au premier critère d'évaluation de l'architecture fonctionnelle 40 : le critère qualitatif.

La cinquième étape 25 est le calcul de la probabilité d'occurrence de l'événement redouté considéré, si l'on dispose des taux de défaillances des défaillances apparaissant dans les monômes calculés au cours de la quatrième étape 24. Cependant, à cette étape, il ne s'agit que d'une première évaluation, susceptible de beaucoup varier selon l'architecture physique éventuellement envisagée et d'éventuels modes communs de défaillance résultants de la mise en correspondance de l'architecture physique et de l'architecture fonctionnelle. On peut cependant introduire des modes communs de défaillances fonctionnelles, c'est à dire des défaillances fonctionnelles affectant plusieurs sorties des blocs fonctionnels en même temps, dès ce stade de l'analyse de l'architecture fonctionnelle. Par exemple, pour exprimer le fait que des défaillances en réception de données Corr_Rec peuvent être communes aux deux voies V1, V2 du bloc de traitement DP, il suffit d'ajouter une condition booléenne comme : DP:V1_Corr_Rec.A = DP:V2_Corr_Rec.A au jeu d'expressions booléennes obtenu au cours de la deuxième étape 22.

La figure 5 représente de manière schématique une architecture physique d'un premier bloc physique 50 qui peut, par exemple, mettre en oeuvre le bloc fonctionnel de traitement DP pour la première voie V1, la voie V2 pouvant être mise en oeuvre par un deuxième bloc physique distinct du premier bloc physique 50. De manière analogue, chaque voie V1, V2, Chan1, Chan2 de chaque bloc fonctionnel de base, hors blocs de routage et bloc de visualisation VIS, c'est-à-dire pour les blocs fonctionnels BR, DP, GP, AP, peut être projetée sur un bloc physique de structure analogue, mais non identique, au premier bloc physique 50 tel que celui représenté sur la figure 5. Le premier bloc physique 50 peut être découpé en plusieurs parties physiques 52, 53, 54, 56, 57, 58, 59, 511, 512 décrits par la suite. Les liens de communication 51, 55, 510 sont aussi des parties physiques et traitées comme telles. Un cheminement de données externes utilisées par le bloc physique 50, à travers les différentes parties du premier bloc physique 50 est par exemple le suivant : • les données externes sont reçues sur un bus SCI 51, acronyme pour le terme anglo-saxon Serial Communication Interface signifiant interface de communication série ; • les données externes peuvent ensuite être stockées dans une ou plusieurs mémoire tampon d'entrée 52 ; • les adresses externes SCI des données sont ensuite converties en adresses PCI, acronyme du terme anglo-saxon Peripheral Component Interface signifiant interface de composant périphérique, par un convertisseur d'adresses SCl/PCI 53; • les données externes sont ensuite transmises sur un bus PCI 55 par l'intermédiaire d'une interface PCI 54 ; • les données associées aux adresses PCI issues du convertisseur d'adresses SCl/PCI 53 traversent ensuite un convertisseur d'adresses PCl/PPC 56, PPC étant un acronyme pour le terme anglo-saxon Program-To-Program Communication signifiant communication programme à programme ; le convertisseur d'adresses PCl/PPC 56 convertit les adresses des données PCI en adresses PPC. • les données associées aux adresses PPC sont ensuite stockées dans une mémoire partagée 57 ; • sur requête d'un processeur 58, les données sont transférées dans une mémoire locale 59 par l'intermédiaire d'un bus PPC 510 ; • ensuite, les données sont reçues par le processeur 58 par l'intermédiaire d'une interface PPC 511 ; • les données reçues par le processeur 58 sont alors traitées par le processeur 58 Des traitements peuvent ensuite être effectués par le processeur 58 pour générer par exemple les réticules de vol et de navigation, les compte-rendus d'erreur ConsoLoc, transférer les messages ConsoRet et les alarmes AL. Les ressources physiques utilisées pour faire les traitements sont les parties physiques processeur 58, interface PPC 511, la mémoire locale 59, ainsi que le bus PPC 510. Un chemin de données utilisé pour une transmission des données générées à l'issue des traitements du processeur 58 peut être le suivant : • les données générées par le processeur 58 peuvent traverser le bus PPC 510 puis le convertisseur d'adresses PCl/PPC 56 ; • les données générées traversent ensuite le bus PCI 55 et l'interface PCI 54 puis le convertisseur d'adresses SCl/PCI 53 ; • les données générées peuvent être par exemple stockées dans une mémoire tampon de sortie 512 avant de sortir du bloc physique 50 sur le bus SCI 51.

L'architecture physique réalisant la macro-fonction à l'aide de parties physiques de base, comme les parties physiques représentées sur la figure 5, peut être analysée en utilisant le deuxième traitement 30. Une des données d'entrée du deuxième traitement 30 est une projection des blocs fonctionnels de base sur des parties physiques de base de plus faible granularité. Un exemple de ce type de projection est décrit ci-après.

La première étape 31 du deuxième traitement 30 est par exemple une projection des défaillances identifiées pour les blocs fonctionnels de base sur les parties physiques de base. Cette projection peut être décrite dans un premier tableau à deux entrées : • une première entrée représentant les défaillances fonctionnelles identifiées au cours du premier traitement 20 et • une deuxième entrée représentant les parties physiques de base réalisant la macro-fonction. Un exemple d'un premier tableau est donné ci-dessous. Dans le premier tableau ci-dessous, une correspondance entre une défaillance fonctionnelle relative à la première voie VI du bloc fonctionnel DP et les parties physiques de base réalisant la première voie VI du bloc fonctionnel DP, est matérialisée par une croix dans la colonne correspondant à la défaillance et dans la ligne correspondant à la partie physique. Une case vide signifie par exemple que la partie physique correspondant à la case vide ne concourre pas à l'activation de la défaillance fonctionnelle correspondant à la case vide. Dans le premier tableau ci-dessous, les parties physiques sont notées In_Buf pour mémoire temporaire d'entrée 52, Out_Buf pour mémoire temporaire de sortie 512, SCl/PCI_Adr_Conv pour convertisseur d'adresses SCl/PCI 53, PCI_Inter pour interface PCI 54, PCl/PPC Adr Conv pour convertisseur d'adresses PCl/PPC 56, Shared_Mem pour mémoire partagée 57, Local_Mem pour mémoire locale 59, PPC_Interf pour Interface PPC 54, PPC_Core pour Processeur 58. DEFAILLANCES FONCTIOMIELLES Corr_Rec ConsoLoc Fail Ret NAV_Comp_Fail Ret_VOL_Comp Fail ConsoRet Fail AL_Comp_Fail Corr_Trans Lost_NI_FCts ln Buf X W Out Buf X Ô SCIIPCI Adr Corn X X > PCI Interf + Bus PCI X = PCIIPPC Adr Corn X a. Shared Mem X rn Ô Local Mem X X X X X PPC Interf +Bus PPC X PPC Core X X X X X La deuxième étape du traitement 30 est l'étape 21 d'identification des défaillances physiques. Le premier tableau ci-dessus met en évidence l'existence de modes communs entre les défaillances fonctionnelles dépendant de parties physiques communes. Les modes communs correspondent dans ce cas à des parties physiques et, ou ensembles de parties physiques concourrant à l'activation de plusieurs défaillances fonctionnelles. Par exemple: la partie physique SCl/PCI_Adr Conv concourre notamment à l'activation des deux défaillances fonctionnelles Corr_Rec et Corr_Trans. Plus précisément, les modes communs peuvent correspondre à des ensembles maximaux de parties physiques concourrant à l'activation du même ensemble de défaillances. Un ensemble de parties physiques ne concourrant qu'à l'activation d'une défaillance fonctionnelle unique peut aussi être désigné par le terme mode commun . Dans l'exemple illustré par le premier tableau, les ensembles de parties physiques correspondant à des modes communs sont par exemple les suivants : {ln_Buf, Shared_Mem}, {Out_Buf}, {SCl/PCI_Adr Conv}, {PCI_Interf, Bus PCI, PCl/PPC Adr_Conv, PPC_Interf, Bus PPC}, {Local_Mem, PPC_Core}

Les défaillances physiques peuvent par exemple être définies à partir de modes communs comme ceux identifiés grâce au premier tableau. Chaque défaillance physique peut être associée à un ensemble de parties physiques correspondant à un mode commun. Les ensembles de parties physiques correspondant à des modes communs étant disjoints, les défaillances physiques sont indépendantes les unes des autres. Un deuxième tableau à deux entrées peut permettre de lister les défaillances physiques et de les mettre en correspondance avec les parties physiques. Un exemple d'un deuxième tableau est donné ci-dessous. DEFAILLANCES PHYSIQUES Phy_Corr_Rec Phy_Corr Trans Phy_Corr_TranclRec Phy_Con-p_Fail Phy_Lost AI_Fcts 0 In Buf X w Out Buf X d SCl/PCI Adr Conv X PCI Interf + Bus PCI X â PCl/PPC Adr Conv X w Shared Mem X 1= Local Mem X Q PPC Interf + Bus PPC X a PPC Core X Dans l'exemple du deuxième tableau ci-dessus, les défaillances physiques sont listées en tête de colonne et les parties physiques en tête de ligne. Les défaillances physiques sont nommées à titre d'exemple. La défaillance physique Phys_Corr_Trans/Rec est par exemple issue d'un mode commun entre les défaillances fonctionnelles Corr_Rec et Corr Trans, le mode commun considéré étant associé à l'ensemble suivant : {SCl/PCI_Adr_Conv }.

On peut également mettre en correspondance les défaillances physiques identifiées avec les défaillances fonctionnelles. Cette mise en correspondance peut se faire sous la forme d'un troisième tableau à deux entrées dont un exemple est donné ci-dessous : DEFAILLANCES PHYSIQUES Phy_Corr_Rec Phy_Corr_Trans Phy_Corr_Tranc/Rec Phy_Comp_Fail Phy_Lost_AII_Fcts w Corr_Rec X X J J ConsoLoc_Fail X z z Ret_NAV -Comp_Fail X g H o Ret_VOL_Comp_Fail X z u. ConsoRet_Fail X o AL_Comp_Fail X Corr_Trans X X LL Lost_AII_Fcts X Une croix dans une case indique une correspondance entre une défaillance physique notée en tête de la colonne de la case contenant la croix et une défaillance fonctionnelle notée en tête de la ligne de la case contenant la croix. Au cours de cette deuxième étape 21, les taux de défaillances associés aux défaillances physiques peuvent être calculés. Un taux de défaillance physique est la somme des taux de défaillance des parties physiques qui lui sont associés. Les taux de défaillances des parties physiques sont déterminés à l'aide de méthodes classiques d'évaluation de la fiabilité de composants physiques.

La troisième étape du deuxième traitement 30 est l'étape de construction 22 des expressions booléennes associées aux sorties des blocs fonctionnels en utilisant les défaillances physiques. Les expressions booléennes peuvent être par exemple du type :

• DP:V1_Ret_NAV.VAL = DP:V1_Act.T * DP:V1_Phy_Lost_AII_Fcts.l * DP:V1_DI.VAL * (DP:V1_Phy_Corr_Rec.l * DP:V1_Phy_Corr_Trans/Rec.l + DP:V1_ Phy_Comp_Fail.A) • DP:V1_Ret_NAV.FL = DP:V1_Phy_Corr_Rec.A + DP:V1_Phy_Corr_Trans/Rec.A + DP:V1_Phy_Comp_Fail.A + DP:V1_Phy_Corr_Trans.A + DP:V1_Phy_Corr_Trans/Rec.A + DP:V1_DI.FL • DP:V1_ConsoLoc.VAL = DP:V1_Act.T * (DP:V1_Phy_Corr_Rec.A + DP:V1_Phy_Corr_Trans/Rec.A + DP:V1_DI.FL + DP:V1_DI.NO + DP:V1 Consol .FL + DP:V1 Consol.NO + DP:V1_Conso2.FL + DP:V1_Conso2.NO) * DP:V1_ Phy_Comp_Fail.l * DP:V1 _P hy_Lost_AI I_Fcts. I • DP:V1 ConsoLoc.FL = DP:V1_Phy_Corr_Trans.A + DP:V1 Phy Corr Trans/Rec.A

La quatrième étape du deuxième traitement 30 est l'étape 23 de construction d'une expression booléenne pour un ER. Cette quatrième étape est effectuée de la même manière que décrit pour l'architecture fonctionnelle. Les défaillances prises en compte sont les défaillances physiques et non plus les défaillances fonctionnelles dans l'expression booléenne construite.

La cinquième étape du deuxième traitement 30 est l'étape 24 de réduction de l'expression booléenne associée à l'ER en une expression booléenne minimale. La cinquième étape s'effectue de la même manière que décrit pour l'architecture fonctionnelle.

La sixième étape du deuxième traitement 30 permet de calculer la probabilité d'occurrence de l'ER défini au cours de la quatrième étape. Les taux de défaillance des défaillances physiques étant connus, le calcul de la probabilité d'occurrence de l'événement redouté prend en compte les modes communs identifiés entre défaillances fonctionnelles.

La figure 6 représente un bloc fonctionnel DPA 60 prenant en entrée un premier signal nommé Input 61, et fournissant en sortie un deuxième signal nommé Output 62. Les signaux d'entrée Input 61 et de sortie Output 62 véhiculent des données qui peuvent être de trois types : un premier type continu, un deuxième type énuméré et un troisième type booléen : • Pour des données de type continu : l'information portée par le signal est soit présente soit absente. Si elle est présente, elle peut être significative ou non. Sa valeur exacte est sans importance pour l'écriture des équations logiques donnant l'état des sorties en fonctions des états des entrées et des défaillances. • Pour des données de type énuméré : l'information portée par le signal est présente ou absente. Si elle est présente, elle peut être significative ou non, les valeurs possibles sont de type énuméré par exemple : VI, V2, V3, et peuvent intervenir dans les équations logiques. • Pour des données de type booléen : l'information ne véhicule pas de valeur. Seul importe le fait qu'elle soit présente ou absente. II s'agit d'un cas particulier du type énuméré où VI, V2, V3 se réduisent à une valeur unique par exemple VAL qui signifie présence d'information.

Pour un signal de type continu on peut définir trois états génériques pour l'information véhiculée par le signal : • OK pour valeur significative ; • NO pour absence d'information ; • KO pour valeur non significative. Les trois états génériques pour l'information véhiculée par le signal peuvent s'exprimer en fonction de deux états de l'information et des deux états de la valeur de l'information quand celle-ci est présente : • VAL représente une présence d'information et NO = -,VAL représente une absence d'information ; • FL représente une valeur non significative pour l'information, VD = -FL représente une valeur significative pour l'information ; On peut ainsi définir les booléens suivants correspondant aux états du signal Input lorsque celui-ci est continu : Input.VAL, lnput.NO, Input.VD, Input.FL. En résumé, on peut noter : • Pour une entrée significative : lnput.OK = Input.VAL * Input.VD ; • Pour une entrée non significative : Input.KO = Input.VAL * Input.FL ; • Pour une entrée absente : Input.NO. Des défaillances génériques nommées par exemple Loss , Misl et Untim associées aux sorties des blocs fonctionnels ou physiques peuvent être définies. Une défaillance générique d'un bloc fonctionnel ou physique peut être définie indépendamment des fonctions mises en oeuvre par le bloc fonctionnel ou physique. Les défaillances génériques peuvent être utilisées systématiquement pour l'écriture des équations booléennes logiques associées aux blocs fonctionnels de base. Si un bloc comprend plusieurs sorties notées Outputl, Output2, les défaillances génériques en sortie du bloc sont par exemple notées : Loss_Outputl, Misl_Outputl , Untim_Outputl , Loss_Output2, Misl_Output2, Untim_Output2. Une première défaillance générique notée par exemple Loss supprime l'information éventuellement véhiculée par le signal Output 62. Une deuxième défaillance générique notée par exemple Misl corrompt, c'est à dire rend non significative, l'information éventuellement véhiculée par le signal Output 62. Une troisième défaillance générique notée par exemple Untim force la présence d'une information sur le signal Output 62, même si le signal Input 61 ne véhicule pas d'information. Cette information intempestive sur le signal Output 62 est, sauf convention contraire, non significative.

Une défaillance nommée par exemple Fail peut avoir deux états : active ou inactive. On peut donc lui associer deux booléens notés : Fail. A signifiant défaillance Fail active et Fail.l signifiant défaillance Fail inactive. On a alors FaiI.A = -,Fail.l, ce qui permet de noter par exemple : • Fail.A = 1 et Fail.l = 0 si Fail est active • Fail.A = 0 et Fail.l = 1 si Fail est inactive

Les défaillances génériques Loss , Misl et Untim sont notamment exclusives les unes des autres, c'est à dire que : • Loss.A * MisI.A = 0; • Loss.A * Untim.A = 0; • Untim.A * MisI.A = O.

Par exemple, en utilisant les notations définies précédemment on peut définir les équations booléennes logiques du signal Output 62 en prenant pour hypothèse que le signal Input 61 et le signal Output 62 sont tous les deux continus. Sachant que : • la première défaillance générique Loss produit NO et donc supprime l'information en sortie quelle que soit l'entrée, • la deuxième défaillance générique Misl produit FL et donc corrompt l'information en sortie quand celle-ci est présente, • la troisième défaillance générique Untim produit VAL et FL quelle que soit l'entrée c'est à dire une sortie de valeur non significative, et que Input.VAL = -,Input.NO, on a alors : • Output.VAL = Input.VAL * Loss.l + Untim.A • Output.FL = Input.FL + MisI.A + Untim.A L'écriture de l'équation Output.FL sous- entend que la valeur du signal Output 62 est présente c'est à dire que Output. VAL = 1. Cette hypothèse permet d'écrire une équation aussi simple que possible pour Output. FL.

On a également Output.NO = ûOutput.VAL; Output.VD = ûOutput.FL On retrouve les trois états génériques de la sortie Output 62 grâce aux expressions suivantes : • sortie significative : Output.OK = Output.VAL * Output.VD • sortie non significative : Output.KO = Output.VAL * Output.FL • sortie absente : Output.NO

D'une manière générale, le formalisme décrit ci-avant permet d'écrire le jeu d'équations pour les blocs fonctionnels ou physiques d'une manière plus compacte que si l'on utilisait les trois états standard signal.OK, signal.KO, signal.NO pour les signaux. Par exemple, un arbre de défaillances construit peut comporter quatre-vingts évènements quand on utilise la notation OK, KO, NO. Il n'en comporte que soixante-deux en utilisant la notation FL, VD, VAL, NO, les coupes minimales étant strictement identiques pour les deux notations.

Pour un signal de type énuméré, on peut définir par exemple plusieurs états pour l'information : • des premiers états correspondant aux valeurs prises par l'énuméré, par exemple : V1, V2, V3 peuvent être trois valeurs énumérées significatives, et donnent donc trois états de valeur significative, • un état KO lorsque les valeurs énumérées V1, V2 ou V3 sont non significatives, • et un état NO lorsqu'il y a absence d'information. Des booléens Signal.V1, Signal.V2, Signal.V3, Signal.KO, Signal.NO peuvent donc par exemple être associés à un signal de type énuméré. On suppose pour simplifier que les informations Input 61 et Output 62 sont toutes deux du type énuméré avec les mêmes valeurs d'énumération V1, V2 et V3. Les équations logiques pour Output 62 sont par exemple les suivantes : • Output.V1 = Input.V1*Loss.l*Misl.l*Untim.l • Output.V2 = Input.V2*Loss.l*Misl.l*Untim.l • Output.V3 = Input.V3*Loss.l*Misl.l*Untim.l • Output.KO = (Input.V1 + Input.V2 + Input.V3)*Misl.A + Input.KO*Loss.l + Untim.A • Output.NO = Input.NO*Untim.l + Loss.A

Pour un signal véhiculant une information de type booléenne deux états peuvent être définis pour l'information : • un premier état VAL pour la présence d'information, • un deuxième état NO = ùVAL pour l'absence d'information. Un exemple de signal booléen peut être une alarme ou une remise à zéro. Les booléens suivant peuvent être par exemple associés à un signal de type énuméré : • Signal.VAL, • Signal.NO avec Signal.VAL ='Signal.NO. Pour un signal de type énuméré, les défaillances génériques à considérer sont Loss et Untim , qui sont en fait associées aux états NO et VAL . Les équations logiques pour Output 62 dans ce cas sont les suivantes : • Output.VAL = Input.VAL * Loss.l + Untim.A • Output.NO = -'Output.NO = Input.NO * Untim.l + Loss.A

Pour représenter des logiques reconfigurables, c'est à dire des fonctions dont le comportement et donc les équations logiques associées dépendent d'états internes à la fonction, on peut utiliser des variables globales ou paramètres. Dans le cas d'un paramètre booléen Param, deux booléens Param.T et Param.F avec Param.F = 'Param.T correspondent aux deux états possibles. Rien n'empêche évidemment l'introduction de paramètres plus généraux, de type énuméré notamment.

La figure 7 représente un autre exemple d'un bloc fonctionnel DPB 70 prenant en entrée : • un vecteur d'état VE qui peut être par exemple un ensemble de données issues de centrales inertielles, • des informations de consolidation des données du vecteur VE, ConsoA et ConsoB qui sont, en fonctionnement normal, cohérentes avec le vecteur VE. Le bloc fonctionnel DPB 70 peut comporter les sorties suivantes : • un réticule Ret calculé par exemple à partir du vecteur VE, • une alarme Alarm activée lorsque les entrées VE, consoA, consoB ne sont pas cohérentes ou si l'une d'elle est absente.

Les défaillances génériques Loss, Misl et Untim sont associées aux sorties du bloc fonctionnel DPB 70. Les équations logiques donnant les états des sorties du bloc fonctionnel DPB 70 sont les suivantes : • Ret.VAL = VE.VAL*Loss_Ret.l + Untim_Ret.A • Ret.FL = VE.FL + Misl_Ret.A + Untim_Ret.A • Alarm.VAL = (VE.FL + VE.NO + Consol.FL + Consol.NO + Conso2.FL + Conso2.NO)*Loss_Alarm.l + Untim_Alarm.A (106)

On suppose maintenant connues les sous-fonctions du bloc fonctionnel DPB. Elles comprennent notamment : • une première sous-fonction de réception Rec, qui reçoit de l'extérieur les entrées VE, Consol et Conso2 ; • une deuxième sous-fonction de transmission Trans, qui transmet vers l'extérieur les informations émises Ret et Alarm ; • une troisième sous-fonction Ret, qui calcule le réticule à partir du vecteur d'état VE ; • une quatrième sous-fonction Check , qui vérifie la cohérence entre VE, Consol et Conso2. En cas d'incohérence détectée par la sous-fonction Check , une alarme Alarm est générée par la sous-fonction Check et le réticule Ret n'est pas calculé.

A partir de la définition des sous-fonctions on peut considérer les défaillances fonctionnelles spécifiques suivantes :

• Rec_Fail provoquant la corruption des informations reçues VE, Consol et Conso2 ; • Trans_Fail provoquant la corruption du réticule Ret et la perte de l'alarme éventuelle Alarm ; • Proc_Fail provoquant simultanément la corruption du réticule Ret calculé et la perte de l'alarme éventuelle Alarm ; • Ret_Fail provoquant la corruption du réticule calculé Ret • Check_Fail provoquant la perte du contrôle de cohérence entre VE, Consol et Conso2 ; • Une défaillance supplémentaire Complete_Loss est identifiée, provoquant la perte complète des sous-fonctions, c'est à dire la perte du réticule Ret et de l'alarme éventuelle Alarm.

II est à noter que les défaillances nommées défaillances fonctionnelles sont considérées comme des défaillances spécifiques et ne sont pas des défaillances fonctionnelles génériques. Les défaillances spécifiques sont particulières aux types de traitement réalisés par les blocs fonctionnels ou physiques. Voici les équations donnant les états des sorties du bloc fonctionnel DPB en fonction des états des entrées du bloc fonctionnel DPB et des défaillances fonctionnelles spécifiques ainsi définies : • Ret.VAL = VE.VAL*Complete_Loss.l*(Rec_Fail.l + Check_Fail.A) Ret.FL = VE.FL + Rec_Fail.A*Check_Fail.A + Proc_Fail.A + Ret_Fail.A + Trans_Fail.A • Alarm.VAL = (VE.FL + VE.NO + Consol .FL + Consol .NO + Conso2.FL + Conso2.NO + Rec_Fail.A) * Proc_Fail.l * Check_Fail.l * Trans_Fail.l * Complete_Loss.l (107)

Il est à noter que : • Pour Ret.VAL : le terme (Rec_Fail.l + Check_Fail.A) exprime que si la sous-fonction réception Rec est non défaillante, ou encore si Rec est défaillante mais que la sous-fonction Check détectant cette défaillance est elle-même défaillante, le réticule est généré. • Pour Ret.FL : le terme Rec_Fail.A*Check_Fail.A exprime que si la sous-fonction réception Ret et le contrôle Check sont tous deux défaillants, le réticule généré sera corrompu. • Pour Alarm.VAL : toutes les causes pouvant provoquer une incohérence apparaissent dans la somme, l'alarme est effectivement générée si toutes les défaillances apparaissant dans le produit sont inactives

L'exemple donné est relativement simple, mais le formalisme présenté est adapté à des logiques de pannes plus complexes.

On peut ensuite décliner les défaillances fonctionnelles génériques en défaillances fonctionnelles spécifiques telles que définies ci-dessus. En mettant en regard les deux jeux d'équations (106), (107), on peut établir les correspondances suivantes : • Loss_Ret.l = Complete_Loss.I*(Rec_Fail.l + Check_Fail.A) • Untim_Ret.A = 0 • Misl_Ret.A = Rec_Fail.A*Check_Fail.A + Proc_Fail.A + Ret_Fail.A + Trans_Fail.A • Loss_Alarm.l = Proc_Fail.I*Check_Fail.l*Trans_Fail.l*Complete_Loss.l • Untim_Alarm.A = Rec_Fail.A * Proc_Fail.l * Check_Fail.l * Trans_Fail.l * Complete_Loss.l (108)

Le formalisme utilisant les défaillances fonctionnelles génériques est suffisamment puissant pour rendre compte des caractéristiques fonctionnelles fines d'un bloc fonctionnel. De plus une traçabilité entre équations logiques de niveau fonctionnel générique et équations logiques de niveau fonctionnel détaillé peut être établie grâce au formalisme défini. Ce point est d'autant plus intéressant que la mise en place d'une telle traçabilité fonctionnelle générique versus fonctionnel spécifique est un problème majeur dans la conception des systèmes complexes, actuellement mal résolu.

En pratique, la plupart du temps, la comparaison entre jeux d'équations permet directement d'exprimer les défaillances fonctionnelles génériques en termes de défaillances fonctionnelles détaillées. Dans certains cas de logiques de pannes complexes, on peut être amené à retoucher les équations génériques afin d'établir la correspondance. De tels cas sont peu fréquents, et les modifications requises sont minimes.

On peut ensuite définir des modes communs entre défaillances fonctionnelles génériques : les équations exprimant les défaillances génériques en termes de défaillances détaillées comportent en effet des termes communs : • Loss_Ret.A et Misl_Ret.A : terme commun Rec_Fail.A • Loss_Ret.A et Loss_Alarm.A : terme commun Complete_Loss.A • Loss_Ret.A et Untim Alarm.A : terme commun Rec_Fail.A • Misl_Ret.A et Loss_Alarm.A : termes communs Check_Fail.A, Proc_FaiI.A, Trans_Fail.A • Misl_Ret.A et Untim_Alarm.A : terme commun Rec_Fail.A. Chacun de ces termes communs représente un mode commun entre les défaillances génériques concernées. La déclinaison des défaillances génériques en défaillances détaillées donnent en fait plus d'information, et notamment les conditions exactes dans lesquelles ces modes communs peuvent devenir actifs et provoquer deux, ou plus, défaillances génériques simultanément. Décliner les défaillances génériques en termes de défaillances physiques par le biais d'équations reliant ces termes permet donc d'identifier d'une part les modes communs entre défaillances génériques, d'autre part leur logique d'activation.

Le passage d'une architecture fonctionnelle à une architecture physique peut donc s'effectuer de trois manières différentes. Une première manière de passer d'une architecture fonctionnelle à une architecture physique peut être la suivante : Des défaillances fonctionnelles génériques sont associées aux sorties des blocs fonctionnels de base de l'architecture fonctionnelle. Puis les défaillances fonctionnelles génériques sont projetées sur des parties physiques de l'architecture physique. Une deuxième manière de passer d'une architecture fonctionnelle à une architecture physique peut être la suivante :Pour chaque bloc fonctionnel de l'architecture fonctionnelle, des défaillances fonctionnelles spécifiques sont définies en s'appuyant sur l'ensemble des sous-fonctions réalisées par le bloc fonctionnel. Les sous-fonctions peuvent être listées, il n'est pas nécessaire que les sous-fonctions représentent un niveau plus fin de découpage du bloc fonctionnel. Les défaillances fonctionnelles spécifiques sont ensuite projetées sur des parties physiques de l'architecture physique. Une troisième manière de passer d'une architecture fonctionnelle à une architecture physique peut être la suivante : Des défaillances génériques portant sur des sorties des blocs fonctionnel de l'architecture fonctionnelle sont définies dans un premier temps. Puis, des défaillances fonctionnelles spécifiques. Ensuite une expression booléenne dont les termes sont des défaillances spécifiques exprime chaque défaillance générique. Les jeux d'équations (108) déduites de la comparaison des jeux d'équations (106) et (107) illustrent l'expression des défaillances génériques en fonction des défaillances fonctionnelles. Puis les défaillances spécifiques sont projetées sur des parties physiques de l'architecture physique.

Une modélisation de la logique de routage d'informations entre blocs fonctionnels peut également être faîte en utilisant le formalisme décrit. On peut par exemple considérer deux blocs fonctionnels DP1 et DP2 identiques au bloc DPB, ainsi que deux autres blocs fonctionnels GP1 et GP2. Les états de bon fonctionnement des blocs DP1, DP2, GP1, GP2 sont représentés par les variables d'état DP1:Act.T, DP2:Act.T, GP1:Act.T et GP2:Act.T respectivement. DP1:Act.T = 1, DP2:Act.T = 1, signifient DP1, DP2 actifs. Dans un fonctionnement nominal, on a DP1:Act.T = DP2:Act.T = GP1:Act.T = GP2:Act.T = 1. Les réticules DP1:Ret et DP2:Ret issus de DP1 et DP2 sont transmis à GP1 et GP2 respectivement. De même, les éventuels comptes-rendus d'erreur GP1:Err et GP2:Err issus de GP1 et GP2 sont transmis à DP1 et DP2 respectivement. Si DP1 est en panne, DP1:Act.T = 0, c'est à dire DP1:Act.F = 1, les réticules DP2:Ret issus de DP2 sont transmis à GP1 et non à GP2, qui ne reçoit plus rien en entrée. De même, les comptes-rendus GP1:Err sont transmis à DP2, les comptes-rendus GP2:Err issus de GP2 étant ignorés. Si DP2 est en panne, DP2:Act.T = 0, les réticules DP1:Ret issus de DP1 continuent d'être transmis à GP1, GP2 ne recevant plus rien en entrée. Les comptes-rendus d'erreur GP1:Err issus de GP1 sont transmis à DP1, ceux émis par GP2 étant ignorés. Si GP1 est en panne GP1:Act.T = 0, les réticules DP1:Ret issus de DP1 sont ignorés, les réticules DP2:Ret continuant d'être transmis à GP2. Les comptes-rendus d'erreur GP2:Err sont transmis à DP2, DP1 ne recevant plus rien en entrée. Si GP2 est en panne GP2:Act.T = 0, les réticules DP2:Ret issus de DP2 sont ignorés, les réticules DP1:Ret continuant d'être transmis à GP1. Les comptes-rendus d'erreur GP1:Err sont transmis à DP1, DP2 ne recevant plus rien en entrée. Cet exemple de logique de routage d'informations peut être représenté par les équations suivantes : • GP1:Ret.VAL = DP1:Act.T * DP1:Ret.VAL + DP1:Act.F * DP2:Act.T * DP2: Ret. VAL • GP1:Ret.FL = DP1:Act.T * DP1:Ret.FL + DP1:Act.F * DP2:Act.T * DP2: Ret. FL • GP2:Ret.VAL = DP1:Act.T*DP2:Act.T*DP2:Ret.VAL • GP2:Ret.FL = DP1:Act.T*DP2:Act.T*DP2:Ret.FL • DP1:Err.VAL = DP1 :Act.T*GP1 :Act.T*GP1 : Err.VAL • DP1:Err.FL = DP1:Act.T*GPI:Act.T*GP1:Err.FL • DP2:Err.VAL = DP1:Act.T * GP2:Act.T * GP2:Err.VAL + DP1:Act.F * GP1 :Act.T * GP1 :Err.VAL • DP2:Err.FL = DP1:Act.T * GP2:Act.T * GP2:Err.FL + DP1:Act.F * GP1:Act.T * GP1:Err.FL L'introduction de paramètres dans les équations est un moyen très puissant pour représenter des logiques reconfigurables. Avantages L'invention permet avantageusement d'éliminer dès la phase de définition fonctionnelle d'un système complexe et dans les phases suivantes une architecture fonctionnelle ou physique insuffisamment robuste du point de vue de la sûreté de fonctionnement. Le procédé d'évaluation de la sûreté de fonctionnement d'un système s'appuie avantageusement sur une construction d'arbres de défaillances. Les analyses de sûreté de fonctionnement par exploitation d'un arbre de défaillances sont reconnues par différentes autorités de certification de systèmes opérationnels. Les données d'entrée, exprimées sous la forme d'expressions booléennes, sont fournies au niveau local, c'est à dire au niveau des blocs fonctionnels ou physiques. L'utilisateur peut alors avantageusement se passer d'avoir une vision globale du système dans la mesure où l'information supplémentaire qui lui reste à fournir concerne essentiellement la connexion entre les blocs. Le degré de complexité d'un système à analyser autorisé par l'approche du procédé selon l'invention ne dépend avantageusement pas de la faculté de l'utilisateur à tout appréhender, mais dans la puissance du moteur de minimisation. Ceci permet donc d'appréhender des architectures fonctionnelles et physiques particulièrement complexes. D'autre part, la génération automatique des combinaisons est avantageusement correcte et exhaustive dans la mesure où les données d'entrée, de définitions des défaillances et d'expressions logiques, fournies par le concepteur sont précises et correctes. Un autre avantage de l'invention est que les données d'entrée pour un jeu spécifique de blocs de base et de défaillances sont fournies une fois pour toutes. Elles sont valables pour n'importe quel type d'événement ER. Les évènements redoutés étudiés traditionnellement sont les évènements redoutés pour la sécurité. Le procédé selon l'invention peut avantageusement être utilisé avec d'autres types d'évènements, dans des buts différents, notamment pour l'établissement de mécanismes de tolérance aux pannes. La puissance descriptive des expressions booléennes associées aux états des sorties de blocs de base est très grande. Enfin, la puissance descriptive dépend en grande partie de la possibilité d'utiliser l'opérateur NOT. La présence de cet opérateur n'affecte en rien la démarche proposée. A l'inverse, son utilisation dans un arbre construit manuellement ou automatiquement gêne fortement les outils, et peut fausser les résultats. La puissance descriptive de la notation PR, NO, VD, FL, qui remplace avantageusement pour les signaux continus la notation traditionnelle OK, KO, NO, permet de simplifier les équations logiques associées aux blocs.

Ceci permet au final d'obtenir un arbre de défaillances nettement moins volumineux et donc plus facilement manipulable. L'invention permet à un expert en sûreté de fonctionnement une transition souple, en maintenant une cohérence, des analyses portant sur l'architecture fonctionnelle vers des analyses portant sur l'architecture physique. Les équations logiques basées sur les défaillances physiques se déduisent, en effet, des équations basées sur les défaillances fonctionnelles. Pour ce faire, l'invention propose une méthode d'identification des défaillances physiques à partir de la donnée des défaillances fonctionnelles et de l'architecture physique.

Claims

REVENDICATIONS

1. Procédé d'évaluation (20, 30) de la sûreté de fonctionnement d'un système réalisant une macro-fonction, caractérisé en ce qu'il comporte au 5 moins les étapes suivantes : • construction d'une architecture (40, 50) du système, décomposée en plusieurs blocs comportant chacun des entrées/sorties de données, les entrées d'un bloc étant reliées aux sorties d'autres blocs de l'architecture (40, 50) ; 10 • identification (21) de défaillances associées aux blocs de l'architecture (40, 50) ; • construction (22) de premières expressions booléennes exprimant des états des sorties des blocs de l'architecture (40, 50) en fonction d'états des défaillances identifiées, d'états des entrées des blocs ; 15 • construction (23) d'une ou plusieurs deuxièmes expressions booléennes à partir des premières expressions booléennes, chaque deuxième expression booléenne définissant un premier événement redouté à examiner ; • réduction (24) de chaque deuxième expression booléenne en une 20 première somme de monômes.

2. Procédé selon la revendication 1 caractérisé en ce qu'il comporte une étape de calcul (25) d'une première probabilité d'occurrence pour chaque premier événement redouté à partir de la première somme de monômes, 25 correspondant au premier événement redouté, en fonction de probabilités d'occurrence des défaillances identifiées.

3. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que l'architecture est une architecture fonctionnelle (40).

4. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que l'architecture est une architecture physique (50). 30

5. Procédé selon la revendication 4, caractérisé en ce qu'il comporte des étapes de : • construction d'une architecture physique (50) décomposée en parties physiques réalisant des fonctions de l'architecture fonctionnelle (40) ; • projection (31) des défaillances identifiées, associées aux blocs de l'architecture fonctionnelle, sur les parties physiques ; • identification (21) de défaillances physiques à partir des défaillances fonctionnelles, identifiées pour des sorties des blocs de l'architecture fonctionnelle (40) ; • construction (22) de troisièmes expressions booléennes exprimant les états des sorties des blocs de l'architecture fonctionnelle (40) en fonction des défaillances physiques identifiées ; • construction (23) d'une ou plusieurs quatrièmes expressions booléennes à partir des premières expressions booléennes, chaque deuxième expression booléenne définissant un deuxième événement redouté à examiner ; • réduction (24) de chaque quatrième expression booléenne en une deuxième somme de monômes ; • calcul (25) d'une deuxième probabilité d'occurrence pour chaque deuxième événement redouté à partir de probabilité d'occurrence des défaillances physiques.

6. Procédé selon la revendication précédente, caractérisé en ce que l'étape d'identification de défaillances physiques (21) comporte une première phase d'identification de modes communs, correspondant à des ensembles de parties physiques concourant à l'activation d'un même ensemble de défaillances fonctionnelles, et une deuxième phase d'association de chaque défaillance physique à chaque mode commun identifié.

7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les défaillances sont des défaillances génériques.

8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les défaillances sont des défaillances spécifiques aux 35 traitements effectués par chaque bloc associé à une défaillance spécifique.

9. Procédé selon la revendication 8, caractérisé en ce qu'une défaillance générique s'exprime en fonction des défaillances spécifiques identifiées.

10. Procédé selon la revendication 7, caractérisé en ce que : • un premier type de défaillance générique supprime une information de sortie , • un deuxième type de défaillance générique rend non significative une information de sortie d'un bloc, supposée présente ; • un troisième type de défaillance générique force la présence d'une information de sortie non significative.

11. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les défaillances prennent deux états : un premier état 15 actif et un deuxième état inactif.

12. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'un état d'une entrée et d'une sortie de type continu est traduit par deux booléens : un premier booléen exprimant une présence 20 d'information d'entrée ou de sortie, un deuxième booléen exprimant une valeur non significative pour l'information.

13. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'une information de sortie ou d'entrée étant de type 25 énuméré et pouvant prendre un nombre n entier de valeurs d'énumération, un état de sortie ou d'entrée de l'information d'énumération est exprimé par : • un troisième booléen par valeur d'énumération, ledit troisième booléen exprimant le caractère significatif associé à la valeur d'énumération du troisième booléen ; 30 • un quatrième booléen exprimant une valeur énumérée non significative ; • un cinquième booléen exprimant une absence d'information.

14. Procédé selon l'une quelconque des revendications précédentes, 35 caractérisé en ce qu'une information de sortie ou d'entrée étant de typebooléen, un état de sortie ou d'entrée est défini par un sixième booléen de présence d'information.

15. Procédé selon l'une quelconque des revendications précédentes 5 caractérisé en ce qu'il est adapté à un système avionique.