ARP-4754

La norme de sûreté [ARP-4754, 1996], dont l’intitulé est « Certification Considerations

for Highly-Integrated or Complex Aircraft Systems » et dont une nouvelle version est sortie

en décembre 2010, est un standard de la Society of Automotive Engineers (SAE). Elle traite de processus de développement de systèmes aéronautiques en se focalisant sur les aspects de sûreté. Elle s’intéresse également à des aspects concernant la certification.

La norme fait référence à d’autres standards bien connus, comme le [DO-178B, 1992] « Software Considerations in Airborne Systems and Equipment Certification » pour le développement de logiciel dans le domaine aéronautique, ou encore le [DO-254, 2000] « Design Assurance Guidance for Airborne Electronic Hardware Considerations in Airborne

Systems and Equipment Certification » pour le développement de matériel.

La Figure II.2 montre les activités et leurs organisations préconisées par la norme ARP- 4754, qui fait intervenir des :

 FHA : Functional Hazard Assessment,

 PSSA : Preliminary System Safety Assessment,

 CCA : Common Cause Analysis,

Chapitre 2 Démarche processus proposée

39

Cet ensemble d’activités débute par une analyse préliminaire des risques au niveau du système, qui a pour objectif d’identifier les risques potentiels qui pourraient porter atteinte au système. Eventuellement, ces risques peuvent être pondérés par une criticité (fonction de la probabilité d’apparition et de la gravité), puis classés suivant cette criticité.

Sur cette base de risques, les objectifs, les exigences ou encore la politique de SdF sont identifiés et définis. Ils doivent être intégrés directement pour la conception du système.

Puis des analyses de risques approfondies sont effectuées à partir de la conception déjà établie. Elles sont éventuellement complétées par des analyses de causes communes.

Figure II.2 : Les processus de l’ARP-4754

Enfin, un ensemble d’activités concerne l’évaluation de la sûreté de fonctionnement du système, où il s’agit de trouver des indications qui montrent que le système satisfait bien les exigences de sûreté de fonctionnement.

Une fois la réalisation terminée ou en partie achevée, des activités de tests et d’essais relatifs à la sûreté de fonctionnement sont également réalisés, ceci pour valider le respect effectif des contraintes et exigences de sûreté de fonctionnement.

Pour beaucoup de techniques d’ingénierie pour la sûreté, l’ARP-4754 fait aussi référence à un autre standard de la SAE : l’ARP-4761 présenté dans la section suivante.

40

2.1.3. ARP-4761

L’ARP-6761 [ARP-4761, 1996] « Guidelines and Methods for Conducting the Safety

Assessment Process on Civil Airborne Systems and Equipment » est un standard de la SAE.

Il est destiné à être utilisé conjointement avec l’ARP-4754 pour démontrer la conformité du système en court de conception avec des articles de certification, tel que le 14 CFR 25.1309 concernant la FAA (Federal Aviation Administration) ou encore le CS–25.1309 concernant l’EASA (European Aviation Safety Agency).

Dans ses 30 premières pages, le standard définit un ensemble organisé de processus couvrant l’évaluation de la sûreté, avec principalement la description de méthodes d’analyse courantes pour cette évaluation de la sûreté, dont :

 FHA : Functional Hazard Assessment,

 FTA : Fault Tree Analysis,

 FMEA : Failure Mode and Effects Analysis,

 FMES : Failure Modes and Effects Summary,

 CCA : Common Cause Analysis,

 ZSA : Zonal Safety Analysis,

 PRA : Particular Risks Analysis,

 CMA : Common Mode Analysis.

Les 140 pages suivantes de ce standard détaillent plus en profondeur les différentes techniques, avec leur modélisation et explique comment elles doivent être appliquées. Les 160 dernières pages présentent un exemple fictif et l’application de ces techniques sur ce cas d’étude. Cet exemple sera d’ailleurs repris en partie dans le chapitre 5 pour illustrer notre travail.

2.2. Quelques projets

2.2.1. SQUALE

Le projet SQUALE (Security, Safety and Quality Evaluation for Dependable Systems) [Deswarte & al., 1999], [Deswarte, 1998] est un projet européen dont les principaux participants étaient le CR2A-DI, Admiral, IABG, le LAAS-CNRS et Matra Transport International. C’est un projet ACTS (Advanced Communications Technologies and Services) qui débuta en mars 1996 et s’acheva vers la fin 1998. Le rapport final du projet est consultable dans [SQUALE, 1999b].

Le but de ce projet était d’élaborer et de fournir un cadre pour l’évaluation de la sûreté de fonctionnement des systèmes à technologie d’information (IT System). Des critères d’évaluation de la sûreté de fonctionnement ont été définis. Ils ont un caractère générique, dans le sens où ils peuvent s’appliquer à tous les secteurs d’activités. L’intérêt de ses critères par rapport à d’autres critères comme ceux fourni par TCSEC (Trusted Computer

System Evaluation Criteria), ITSEC (Information Technology Security Evaluation Criteria)

[TCSEC, 1985], [Deswarte & al., 1998] ou encore d’autres normes propres à l’avionique, le ferroviaire, le nucléaire, etc. provient du fait qu’ils couvrent à la fois les aspects de sécurité- innocuité et de sécurité-confidentialité, ainsi que tous les autres attributs de la sûreté de

Chapitre 2 Démarche processus proposée

41

fonctionnement (fiabilité, disponibilité, maintenabilité,…). Pour élaborer les critères proposés par SQUALE, les participants au projet se sont d’ailleurs en partie appuyés sur les Critères Communs [Common Criteria, 1998]. (Note : il existe maintenant des versions plus récentes des Critères Communs.)

Ainsi, les différents collaborateurs du projet ont défini et proposé un panel d’activités à réaliser dans des conditions données, selon les différents attributs de sûreté de fonctionnement et leurs niveaux de confiance souhaités (déclinés en niveaux de détail, de rigueur et d’indépendance). Fondamentalement, SQUALE définit des activités à mettre en œuvre pour valider la sûreté de fonctionnement d’un système, paramétrables en fonction des niveaux de confiance voulus. Le document alors établi par le projet SQUALE [SQUALE, 1999a] se veut être applicable pour la validation ou la certification de systèmes qui sont critiques au niveau de la sûreté ou de la sécurité, ou qui ont un niveau requis élevé de disponibilité, de fiabilité ou de maintenabilité. De plus, il couvre toutes les phases du cycle de vie des systèmes.

2.2.2. ESACS

ESACS (Enhanced Safety Assessment For Complex Systems) [ESACS], [Bozzano & al., 2003] est un projet européen RTD en réponse à l’appel de Growth 2000 traitant de « nouvelles perspectives en aéronautique ». Le projet démarra en février 2001 et s’acheva en décembre 2003.

Les objectifs du projet étaient :

 de définir une méthodologie pour améliorer la réalisation des analyses de sûreté au cours du développement de systèmes complexes,

 d’établir un environnement partagé basé sur les outils supportant la méthodologie,

 de valider la méthodologie à travers son application sur un cas d’étude.

L’environnement entre la conception et la sûreté est composé d’outils pour générer des parties d’analyses de sûreté en utilisant les informations extraites directement du modèle du système et d’une base incluant toutes les informations de sûreté liées au système.

Le constat de base fait lors des débuts du projet ESACS rejoint des points identiques aux nôtres concernant les faiblesses des processus de sûreté de fonctionnement. Plus de détails sont disponibles dans [ESACS, 2001].

Les défaillances et leurs effets proviennent souvent du simple jugement des ingénieurs et sont vérifiés par des tests. Or ces jugements deviennent de plus en plus difficiles à cause de la complexification des systèmes. Principalement, le nombre d’états possibles des systèmes augmentent considérablement du fait de l’intégration de calculateurs toujours plus sophistiqués et de l’augmentation des interactions entre les différents systèmes avion (note : on parle de « système avion » en aéronautique pour désigner les premiers « sous- systèmes » de l’avion) qui implique un risque d’interaction entre des défaillances.

L’autre point concerne la manière dont les informations sont gérées et échangées par les ingénieurs. En fait, actuellement les informations entre les ingénieurs système et les ingénieurs de sûreté sont échangées sous forme papier. Ainsi, l’information concernant le

42

comportement du système est transmise par texte ou par modèle et elle doit être en premier lieu interprétée par l’analyste de sûreté. Dans un second temps seulement, des AMDEC ou des arbres de défaillances (par exemple) sont réalisés, étant supportés par d’autres outils. Ce type de traitement de l’information est source d’erreurs et implique la duplication des efforts de modélisation (pour la conception, puis pour la sûreté) et aussi retarde l’identification des problèmes.

Figure II.3 : Proposition du projet ESACS

Le projet ESACS a répondu à ces faiblesses actuelles en expliquant que les analyses d’évaluation de la sûreté doivent être conduites à partir de quelques moyens automatiques directement appliqués sur le modèle fonctionnel du système (voir Figure II.3). Cela signifie que les modèles utilisés pour la conception du système doivent être enrichis avec les informations ou exigences de sûreté de fonctionnement. Egalement, il s’agit d’utiliser des méthodes de simulation ou des méthodes formelles (model-checking) pour aider aux analyses de sûreté.

Finalement, les principales recommandations issues du projet sont :

 identifier et développer un modèle commun du système à la fois pour la conception et pour la sûreté,

 développer une façon d’exprimer les exigences de sûreté plus précise et plus rigoureuse, et dans le même cadre que celui pour la conception du système,

 Enrichir les modèles du système pour inclure les comportements défaillants,

 Fournir le moyen d’utiliser le modèle du système enrichi pour la génération d’analyse des modes de défaillance et de leurs effets, ainsi que pour la génération d’arbres de défaillance,

 Fournir une classification des modes de défaillance.

2.2.3. ISAAC

Le projet européen ISAAC (Improvement of Safety Activities on Aeronautical Complex

systems) [ISAAC], [Akerlund & al., 2006] est une continuité au projet ESACS qui avait

réussi à montrer le bénéfice engendré par l’utilisation de méthodes formelles pour l’évaluation de la sûreté des avions. Ce projet se déroula de 2003 à 2006. L’objectif était d’aller encore plus loin dans l’amélioration et l’intégration des activités de sûreté des

Chapitre 2 Démarche processus proposée

43

systèmes complexes aéronautiques. Les bénéfices potentiels vont d’une meilleure confiance en la sûreté des systèmes à un accroissement de la compétitivité des industries européennes.

Entre autre, il s’agissait d’étendre les techniques formelles pour prendre en compte les erreurs humaines, les analyses de causes communes, les analyses de mission et la testabilité. Il était aussi question d’améliorer les notations d’ESACS pour représenter les exigences de sûreté. Un troisième volet s’occupait de l’aspect d’intégration, à travers des recommandations générales et de librairies et interfaces partagé. C’est en fait un des concepts clés qui permet d’améliorer l’efficacité des processus industriels, qui le plus souvent reposent sur des outils différents.

2.2.4. ASSERT

Le projet ASSERT (Automated proof-based System and Software Engineering for Real-

Time systems) [Conquet, 2008] [Conquet & al., 2005] est un projet coordonné par l’Agence

Spatiale Européen (European Space Agency – ESA), plus précisément par la division des systèmes logiciels. Il a réuni près de 28 partenaires, dont des industries spatiales et des laboratoires de recherche, ainsi que des entreprises de développement de logiciels et d’outils. Il commença le 1er _{septembre 2004 et se termina le 31 décembre 2007.}

Ce projet avait comme objectif de changer la manière de procéder à l’ingénierie des systèmes et des logiciels. Notamment, une nouvelle approche est proposée, plus fiable car basée sur la modélisation, la préservation de propriétés système et la transformation de modèle vers le code final. Un processus est défini, accompagné d’un ensemble d’outils, et des projets concrets ont permis de valider l’approche. Parmi les nombreux langages utilisés dans les processus d’ASSERT, on trouve notamment AADL, UML ou encore Altarica.

Sur un cas d’étude d’un budget total de 50 M€, avec une partie avionique représentant 30 M€ dont la part logicielle est de 4 M€, il a été estimé un gain de 1,8 M€ sur ces 4 M€ en suivant l’approche proposée par le projet ASSERT.