Risques associés aux technologies logicielles

05/09/2017
Publication REE REE 2005-11
OAI : oai:www.see.asso.fr:1301:2005-11:19815
DOI :

Résumé

Risques associés aux technologies logicielles

Métriques

21
8
2.84 Mo
 application/pdf
bitcache://0c5b7666cf7464730a3b3304a1a9d3e32db18b77

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/1301:2005-11/19815</identifier><creators><creator><creatorName>Gilles Motet</creatorName></creator><creator><creatorName>Stéphanie Gaudan</creatorName></creator></creators><titles>
            <title>Risques associés aux technologies logicielles</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2017</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Tue 5 Sep 2017</date>
	    <date dateType="Updated">Tue 5 Sep 2017</date>
            <date dateType="Submitted">Fri 17 Aug 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">0c5b7666cf7464730a3b3304a1a9d3e32db18b77</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>33613</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

. DOSSier) 1 1 1 SÛRETÉ DE FONCTIONNEMENT DES SYSTÈMES A FORTE COMPOSANTE LOGICIELLE Mots clés Managementdurisque, Logicielcritique,1 Langagedeprogrammation et demodélisation m m F Risques associés aux R Managementdurisque, ec no ogles oglcle es Logiciel critique, Langagedeprogrammation et demodélisation t Par Gilles MOTET l (2,Stéphanie GAUDAN LESIA de/'INSA de Toulouse {I ! Fondation pour une culture de sécurité industrielle Si les substances chimiques utilisées pour réaliser des produits sont considérées comme potentiellement dangereuses depuis de nombreuses années, il n'en est pas de même des technologies logicielles employées pour réaliser des produits logiciels ; pourtant, elles méritent également 'étude de leurs risques. 1. Maîtrise des risques logiciels 1.1. Part croissante de la technologie logicielle La technologie logicielle prend une part croissante dans la réalisation des systèmes, non seulement pour se substituer à d'autres technologies, mais également pour apporter de nouvelles caractéristiques fonctionnelles ou non fonctionnelles aux produits. L'automobile en est un des exemples les plus probants. Tout d'abord, la technologie logicielle a été introduite pour faire profiter des caractéristiques de cette technologie à l'amélioration des qualités du produit. . Par exemple, le logiciel permet d'améliorer la ,fïabilité globale du produit en remplaçant des technologies matérielles affectées par le phénomène de vieillissement. Ainsi, l'allumage électronique évite, entre autres, le réglage des « vis platinées » qu'il a remplacé pour rythmer l'allumage des bougies. . L'usage de variables, de paramètres ou d'attributs offerts par les langages de programmation permet la définition de fonctionnements conditionnels ou paramétrés, qui ont autorisé la réalisation de conipoi-- tements adaptatifs des produits. Ils interviennent par exemple dans l'allumage électronique des bougies, ou dans le contrôle de l'ouverture des soupapes, afin de réduire les émissions polluantes. Les facilités de conception, de réalisation et de production offertes par les technologies logicielles autorisent la création de fonctionscoiiil) lexes, telles que celles mises en oeuvredans les lois de commande pour l'amortissement du véhicule, afin d'augmenter le confort des passagers. Ensuite, la technologie logicielle a été employée pour réduire les dommages potentiellement causés par les produits. . Tout d'abord, elle intervient fréquemment pour pallier les iiiativaises utilisations des produits. Ainsi, les programmes d'ABS ou d'ESP (Electronic Skid Prevention) préviennent l'occurrence d'accidents, alors que les logiciels de contrôle de l'ouverture des airbags améliorent la protection des passagers si unZD accident survient. . En second lieu, les applications logicielles réduisent l'impact des dommages causés par les caracté- ristiyues d'autres technologies du système. Par exemple, la technologie matérielle d'implantation d'un moteur est inéluctablement affectée par le vieillissement. Celui-ci peut causer des émissions 5 5 NT/EL L'usagede latechnologie logicielleest de plus en plusfréquent et important dans la réalisation des systèmes, y compris des sys- tèmes critiques. Des études sont menées pour réduire le risque de défaillance des applications logicielles embarquées. Cependant,les caractéristiquesdes technologies logiciellesque sont les langagesde programmationou de modélisationsont rare- ment étudiées en termes de risques intrinsèquesprésentés par ces technologies. Cet article propose la démarcheà suivre pour une approche systématique de gestion de ces risques, et son illustrationpar un exemple d'application. SYNOPSIS The software technologiesare more and more frequently usedto implement systems including high-critical systems.Studies dealt with the mitigation of the risk of failures of embedded software applications. However, the characteristicsof the software tech- nologies such as the programmingand modeling languagesare rarely studied considering the intrinsec risks associated with these technologies. This paper proposesa systematic approach to handle these risks presenting a process and an application example. REE N " l ! Décembre2005 Risques associés aux technologies logicielles polluantes excessives. Des programmes sont fré- quemment ajoutés pour analyser les gaz émis et agir si besoin est, afin de réduire leur nocivité (par exemple par du recyclage). Enfin, des logiciels peuvent être utilisés pour assis- ter des éléments défaillants d'un système. Par exemple, le freinage mécaniquement instable d'une voiture a été corrigé par un programme ajouté à celui de l'ABS. On constate qu'une part de plus en plus importante des responsabilités de décision, jusqu'alors prises par l'utilisateur du produit, est maintenant déléguée à des systèmes informatiques embarqués. Ces décisions sont souvent attachées à la sécurité : ouverture d'airbag, diminution de la pression des freins par l'ABS, ou au contraire décision de freinage d'une roue par l'ESP. Elles peuvent également concerner le respect d'exigences non fonctionnelles du produit, comme le respect des normes de pollution. 1.2. Besoin de garantir l'absence de défaillances Cette prépondérance des fonctions et des responsabi- lités prises par les systèmes informatiques embarqués nécessite : . une maîtrise, par les concepteurs de ces pro- grammes, des risques que ces applications logi- cielles font courir aux utilisateurs, . et également la fourniture des éléments d'information permettant de donner aux usagers des produits les garanties assurant que cette maîtrise est effective. Ces exigences sont tout d'abord induites par deux constatations : 1) la part prépondérante des fonctions de sécurité gérées par des applications logicielles, telles que l'ABS ou l'ESP, et 2) l'autonomie croissante des fonctions remplies, sur lesquelles l'utilisateur a de moins en moins d'in- fluence (mêmes exemples). Cette maîtrise des risques est également imposée par l'intégration croissante des systèmes dont le dysfonction- nement de l'un peut impacter un ou plusieurs autres en chaîne (effet dominos). En considérant toujours le secteur automobile, les valeurs des paramètres calculées par un système (comme la vitesse de rotation des roues) sont uti- lisées comme données par un autre système. Ainsi la défaillance du premier système conduit-elle à la fournitu- re d'une valeur incomecte, pouvant provoquer la défaillance du second, etc., ou des comportements globaux désastreux. L'impact des défaillances des systèmes informatiques embarqués concerne non seulement le bon fonctionnement du produit qui les inclut, mais affecte également lesCD finances (coûts des rappels) et l'image de marque de la société productrice. Elles conduisent de plus en plus souvent à des actions en justice déclenchées soit par des utilisateurs ou des groupes d'utilisateurs, soit par des autorités. Les poursuites judiciaires entreprises par la Cour fédérale américaine à l'encontre d'un constructeur automobile, à la suite d'un risque de pollution par un modèle de voiture du fait d'un programme erroné de contrôle des émissions, en est un exemple [1] [2]. Afin de prévenir les défaillances des programmes embarqués, il est indispensable de conduire des études de management des risques qui leur sont associés. Ces études serviront également d'argument de défense à d'éventuelles poursuites judiciaires en cas de dommages causés par le produit, malgré les efforts de prévention entrepris. 1.3. Risques applicatifs et risques technologiques Les travaux de recherche actuels, tout comme les activités de développement relatives aux risques inhérents aux applications logicielles, traitent essentiellement des événements redoutés que sont les défaillances potentielles de ces applications. Nous les qualifierons de risques applicatifs. Ces défaillances sont considérées comme issues de la présence de fautes de conception dans les programmes. Ces risques sont traités en agissant sur le processus de développement ou sur les résultats de chaque étape de ce processus (documents, modèles ou programmes). Selon le niveau de criticité de l'application développée, c'est-à-dire selon la gravité des conséquences induites par l'occurrence d'une défaillance de cette appli- cation, des exigences plus ou moins importantes sont imposées aux concepteurs. Celles-ci contraignent les étapes du processus de développement (guides, etc.) ainsi que les actions qui doivent être menées sur les résultats des étapes : évaluation des risques de défaillance, techniques de vérification pour prévenir la présence de fautes, mise en oeuvre de redondances pour inhiber ou réduire les effets des défaillances de composants, etc. Si les fautes présentes dans les logiciels peuvent certainement être induites par des erreurs survenues lors du processus de conception, elles sont également attachées à la technologie logicielle employée. Or cet aspect est très peu étudié. La technologie logicielle n'est pas considérée de la même manière que les autres technologies. En effet, si les études des risques induits par les technologies matérielles (produits chimiques, matériaux, etc.) sont très fréquentes, rares sont celles concernant la technologieZD logicielle. Cet article a pour but d'y remédier. Pour cela, nous décrivons au chapitre 2 l'approche générique, que nous déclinerons par la suite, pour mener7 l'étude des risques liés aux technologies logicielles. En effet, une telle approche augmentera la garantie d'unec CI étude exhaustive de ces risques. Cette approche est mise en oeuvre au chapitre 3. Dans celui-ci, nous décrivons les REE N°tt Décembre2005 . DOSSier) 1 1 1 SÛRETÉ DE FONCTIONNEMENT DES SYSTÈMES À FORTE COMPOSANTE LOGICIELLE différents aspects du management du risque propres aux technologies logicielles, que nous illustrons par l'étude d'un exemple de risque lié à une construction importante des langages-objets : l'héritage. Cette section n'a pas pour but de fournir une étude complète des risques relevant d'une technologie logicielle donnée (UML, Java, Ada, etc.) mais de préciser comment de telles études doivent être conduites, et quels sont leurs apports. Le LESIA de l'INSA de Toulouse développe de telles études sur les technologies UML [3] [4] et Java [5]. 2. Management du risque Ce chapitre introduit les éléments du management du risque. Les notions de risque et de processus de management du risque sont présentées au premier sous-chapitre. Les sous-chapitres suivants abordent les diverses tâches communément mises en oeuvre dans un processus de management du risque en décrivant leurs objectifs, les résultats qu'elles produisent, et en fournissant quelques informations sur les méthodes ou techniques utiles à leur mise en oeuvre. Ce chapitre n'a pas pour prétention de fournir une connaissance approfondie sur ce sujet, mais une vue d'ensemble, permettant de comprendre comment des études des risques inhérents aux technologies logicielles peuvent être conduites. Notre présentation est basée sur les normes ISO Guide 51 [6] et Guide 73 [7], ainsi que sur de nombreux standards sectoriels (médical, ferroviaire, avionique, nucléaire, etc.). Signalons que le cadre proposé ici n'est pas finalisé et qu'il est l'objet de discussions, en particulier pour établir une nouvelle norme ISO. Certains éléments sont donc des propositions des auteurs. 2.1. Concept de risque et de processus de management De multiples causes survenant à un instant peuvent avoir des effets dans le futur. Ces effets sont caractérisés par deux notions : . un événement qui identifie l'occurrence potentielle de l'effet, et . une conséquence qui qualifie son impact sur une cible Cette cible peut être une personne, un bien, l'environ- nement, etc. Le risque est une entité qui couple ces deux notions, événement et conséquence. Par exemple, les dommages (conséquence) causés par l'impact d'un choc d'une coulée de neige (événement) sur un chalet (cible) qualifient un risque. Nous utiliserons cet exemple simple pour illustrer les notions introduites dans ce chapitre 2. Il est important de noter que l'occurrence de l'événement n'est que potentielle, et non induite assurément par des causes même présentes. Par exemple, tous les chalets de montagne ne sont pas atteints par des coulées de neige. Il s'agit d'une potentialité qu'il convient d'étudier pour la maîtriser. De même, les conséquences ne sont pas toujours graves : tous les chalets construits ne seront pas un jour détruits par une avalanche. Les causes du risque sont multiples : origine naturelle, décision humaine, événement opérationnel d'un système, etc. Ils sont regroupés sous le terme de source du risque. Le management du risque a pour but de fournir les moyens de maîtrise des risques. Pour ce faire, il met en oeuvre un processus de management du risque, qui décrit un séquencement de tâches incluant généralement : . l'identification qui a pour but d'énumérer et de décrire les risques possibles, ainsi que leurs sources . l'estimation des risques qui quantifie les risques identifiés 0 1,évaluation des risques conduisant à la hiérarchi- sation des risques à partir de leurs estimations, et également d'autres critères . l'acceptation des risques qui porte un jugement sur les risques hiérarchisés, en fixant un seuil d'accep- tabilité . le traitement des risques fournissant des moyens permettant, par exemple, de réduire les valeurs des estimations des risques à un niveau acceptable a la coiiiiitiiiication sur les risques qui concerne les échanges avec l'ensemble des parties prenantes des risques Pour chacune des tâches doivent être définis : . les modèles des résultats que doivent produire ces tâches, ainsi que . les méthodes à employer pour produire ces résultats Ces éléments sont parfois imposés par les normes sec- torielles ou doivent être définis lors d'une étape prélimi- naire appelée « établissement du contexte » [8]. 2.2. Identification des risques Le risque est donc exprimé par deux attributs : l'événement et la conséquence. Les termes d'événement dommageable et de dommage (respectivement d'événement bénéfique et de bénéfice) sont souvent utilisés pour connoter le risque par une appréciation négative (respec- tivement positive). Si un accord existe sur les attributs du risque, ceux permettant de décrire les sources des risques font encore l'objet de débats. La terminologie proposée dans cette section ne fait pas référence à un standard spécifique, REE Wll Décembre2005 Risques associés aux technologies logicielles mais est issue de l'étude de nombreuses normes et d'une contribution personnelle. Pour ne pas alourdir ce texte et pour faciliter sa compréhension, nous choisirons délibé- rément une terminologie associée à l'appréciation négative du risque, souvent attachée au domaine de la sécurité. Les attributs de la source du risque sont subdivisés en deux parties : le danger et la situation dangereuse. Le danger définit la source du risque vis-à-vis de l'acteur à l'origine du risque. Cet acteur est par exemple l'ingénieur prenant une décision de conception, le langage de programmation offrant des instructions particulières, ou encore la substance chimique intervenant dans une fabrication de produit. Trois éléments caractérisent le danger : Le phénoiiiène dangereux pouvant affecter des types d'acteurs (humains, objets, substances ou systèmes) qui a la capacité de provoquer un dom- mage. Il s'agit par exemple des énergies (potentielle, cinétique, etc.), de la toxicité des substances chimiques, de la défaillance d'un composant d'un système, de l'erreur humaine. Le terme « a la capacité de » met en avant la potentialité des effets. Le phénomène dangereux ne concerne pas un acteur particulier, mais une classe ou un type d'acteurs. Par exemple, toute masse située en hauteur a de l'énergie potentielle, qu'il s'agisse d'une masse de neige, d'un avion, etc. . La propriété dangereuse est une propriété d'un acteur spécifique (humain, objet, substance, ou système) lui attribuant un ou plusieurs phénomènes dangereux. Par exemple, une masse de neige « au sommet d'une montagne » possède de l'énergie potentielle, tout comme un avion « en vol » . Un événement dangereux (ou initiateur) est un évé- nement qui active l'effet (nuisible) de la propriété dangereuse d'un acteur (humain, objet, substance ou système). C'est le cas, par exemple, d'une avalanche qui est à l'origine des effets nuisibles de la masse de neige au sommet mise en déplacement. La situation dangereuse définit la position de la cible vis-à-vis de la source du risque. Une situation dangereu- se est une situation dans laquelle une cible (personne, bien, environnement, etc.) est exposée à un ou plusieurs phénomènes dangereux. C'est cette cible qui est affectée par les dommages potentiellement causés. C'est le cas par exemple des chalets construits au pied de la montagne enneigée, qui sont susceptibles d'être détériorés en cas d'avalanche. Les sources (dangers et situations dangereuses) peuvent être à l'origine de dommages mais l'occurrence de cette conséquence n'est pas certaine. Par exemple, tous les chalets de montagne ne sont pas détruits par des avalanches. Cet exemple met également en valeur le fait que les sources du risque, si elles peuvent être à l'origine de dom- mages, sont initialement sources de bénéfices (proximité des pistes de ski, agrément de l'environnement, etc.). La propagation des effets de l'événement dangereux sur la cible en situation dangereuse dépend de l'environnement. Par exemple, la probabilité du choc (événement domma- geable) d'un chalet à la suite d'une avalanche (événement dangereux), ainsi que les dommages causés, dépendent de la topographie du lieu (par exemple la présence d'un monticule entravant le déplacement de la neige). Les valeurs de ces attributs sont obtenues par diverses techniques incluant l'utilisation de check-lists énumérant les événements dangereux et les situations dangereuses associés aux phénomènes dangereux, comme ceux des produits chimiques par exemple. 2.3. Estimation des risques L'estimation des risques a pour but de mesurer les risques, c'est-à-dire ses attributs. Pour cela des critères d'estimation (éléments d'appréciation de l'estimation des attributs) et des métriques (classes de valeurs utilisées) doivent être associés aux différents attributs du risque et de ses sources. Ainsi l'événement dommageable est-il estimé par la vraisemblance de son occurrence, et le dommage par sa gravité. Pour l'exemple, il s'agit de la probabilité qu'un chalet soit impacté par une coulée de neige, et des dégâts causés sur la construction. Ces valeurs sont généralement déduites de celles des attributs des dangers et de la situation dangereuse. Pour cela on exprime : . farnplitude du phénomène dangereux (liée à la masse de neige et à la hauteur du sommet), la vraiseijiblance de l'événement dangereux ou ini- tiateur (dépendant par exemple des conditions atmosphériques), la topologie d'intensité ayant pour but de définir à chaque endroit donné de l'environnement du danger, l'intensité du phénomène dangereux (par exemple définissant l'énergie cinétique de la masse de neige en tout point environnant la montagne), . l'exposition de la situation dangereuse (liée au lieu de construction du chalet), et · la vulnérabilité de la cible (architecture du bâtiment, matériaux de construction, etc.). Pour chacun des attributs, des métriques sont définies. Il s'agit de nouveau d'un choix à établir lors de l'étape intitulée « établissement du contexte ». Ces métriques peuvent être quantitatives ou qualitatives. Par exemple, la REE ? ! ! Décembre2005 s s i e r 1 1 1 SÛRETÉ DE FONCTIONNEMENT DES SYSTÈMES A FORTE COMPOSANTE LOGICIELLE vraisemblance de l'occurrence d'une avalanche peut être exprimée par : . une probabilité (valeur entre 0 et 1) ou des classes de valeurs [10-'..10'], [10'..10-1], [10-.11) il s'agit d'une approche quantitative ; . un ensemble d'identificateurs qualitatifs tels que : jamais, souvent, très souvent, pratiquement toujours. Ils forment un exemple de métrique qualitative. Un cadre standard du processus d'estimation des risques a été établi très récemment par l'AFNOR [9]. 2.4. Evaluation et acceptation des risques L'évaluation des risques a pour but de hiérarchiser les risques. Elle fait intervenir la matrice de risque qui associe à chaque couple de valeurs (vraisemblance, gravité) un niveau de risque. Pour un risque considéré, d'autres critères interviennent pour évaluer le niveau de risque. Il s'agit par exemple des bénéfices que l'on compte tirer des sources du risque ainsi que des coûts des traitements envisagés pour réduire le risque (analyse coût/bénéfice). Par exemple, le proprié- taire d'un chalet aura tendance à minimiser l'évaluation du risque de destruction de son chalet du fait de l'agrément qu'il en tire et du coût élevé des paravalanches qu'il lui faudrait construire pour réduire le risque. L'étape d'acceptation des risques nécessite de fixer un niveau d'acceptabilité. Il permet de situer les risques évalués par rapport à ce seuil. Cependant d'autres données intervien- nent dans ce choix, que nous ne développerons pas ici. 2.5. Traitement des risques Les traitements des risques sont répartis en quatre approches : le refus du risque, le transfert de risque, la prise de risque et l'optimisation du risque. Elles sont suc- cessivement définies comme suit : . Le refus est une décision visant à ne pas impliquer une cible dans la source d'un risque. Il est obtenu en agissant sur l'amplitude du phénomène dangereux (par exemple en purgeant la montagne), ou sur l'exposition au risque (par exemple en interdisant les constructions). Elle conduit cependant à une perte des bénéfices associés. . Le transfert de risque consiste à partager avec une autre partie la charge de la perte ou le bénéfice du gain d'un risque. Il s'agit donc de partager les effets des conséquences (par exemple en assurant le chalet). . La prise de risque consiste à accepter la charge de la perte ou le bénéfice du gain d'un risque. Ce traitement n'est pas acceptable dans le contexte des applications critiques qui nous intéressent. . L'optimisation a pour but d'améliorer la valeur de l'estimation. Dans le domaine de la sécurité (traduction de safety), il s'agit essentiellement de réduction du risque. Celle-ci est obtenue par des techniques de prévention visant à réduire la vraisemblance de l'occurrence de l'événement dommageable ou par des techniques de protection minimisant la gravité du dommage.ZD Nous n'aborderons ici les éléments de la communica- tion sur les risques qu'à travers la diffusion des risques associés aux technologies logicielles ou des moyens d'es-Zn timation et de réduction associés, dont cet article est d'ailleurs l'objet. 3. Management des risques des technologies logicielles 3.1. Objectifs Nous avons souligné en introduction que les études de risque actuellement menées concernent les risques propres aux applications logicielles. Cependant, elles utilisent rarement le cadre du management du risque décrit précédemment. On peut néanmoins les replacer dans ce cadre. Tout d'abord, leur but est de maîtriser les événements dommageables que sont les défaillances pouvant survenir en phase opérationnelle. Les dommages induits dépendent des fonctions remplies par les pro- grammes défaillants. La cible est donc l'environnement du programme exécutable. Le phénomène dangereux est la faute qui affecte la structure du programme : le programme contenant une faute présente une propriété dangereuse. L'événement dangereux est l'occurrence d'une erreur qui peut conduire ou non à l'occurrence de l'événement dommageable, c'est-à-dire à la défaillance, selon les barrières qui vont lui être opposées (mécanismes de tolérance aux fautes par exemple). Les risques identifiés et leurs sources dépendent donc de chaque application. tout comme les estimations de ces risques. Ces études laissent supposer que les technologies utilisées pour développer le programme-source (le langagec ZD de programmation) ou son modèle (le langage de modélisation) ont un impact négligeable sur la présence de fautes, et donc sur la conection des programmes. Au contraire, pour les autres technologies (substances chimiques, matériaux, etc.) des études sur les risques intrinsèques sont conduites. Or, comme nous allons le montrer, certaines classes de fautes sont inhérentes aux technologies utilisées. Ce fait, sans être formalisé, est sous-jacent à des études comme celles de l'OOTiA [10] qui souligne entre autres des fautes de programmation induites par les langages orientés-objet. De même, l'effi- cacité des moyens de détection de fautes dépend des constructions offertes par ces langages. Cela est également REE NO il Dvcembre2005 Risques associés aux technologies logicielles sous-jacent à des travaux tels que ceux de la norme ISO 15942 [11], qui estiment l'efficacité de l'emploi des tech- niques de vérification des programmes écrits en langage Ada en fonction des constructions utilisées de ce langage. Connaître les événements dommageables pouvant survenir à une pièce métallique (rupture par exemple) en fonction des dangers potentiels (charge, torsion, corrosion, etc.) permet de choisir la technologie adaptée lors de la construction d'un élément métallique. De même, évaluer les risques propres à une technologie logicielle devrait précéder le choix de cette technologie en fonction des caractéristiques de l'application, afin de maîtriser les risques des fautes associées lors du développement. De plus, la définition de moyens de réduction (prévention ou protection) de ces fautes fournit une nouvelle classe de bonnes pratiques, afin de réduire de façon maîtrisée un nombre important de types de défaillances. Enfin, signa- lons que les études des risques inhérents aux technologies logicielles ne doivent être conduites qu'une seule fois puisqu'elles sont indépendantes des applications qui les utilisent. La maîtrise des risques des technologies logicielles est de plus un argument qui devrait faciliter la qualification des produits, améliorer l'image de marque de l'entreprise qui la met en application, et montrer le sérieux de cette entreprise, par exemple auprès d'experts judiciaires, si des défaillances de ces produits conduisant à des dommages survenaient. Afin de mener à bien la maîtrise de ces risques, nous allons montrer comment les diverses tâches introduites au chapitre 2 peuvent être mises en oeuvre pour le mana- gement des risques des technologies logicielles. Chaque tâche seradéveloppée dans une sous-section. Nous y suivrons le traitement d'une classe de fautes associées aux langages orientés-objet, que ces langages concernent la modélisation ou la programmation. Comme précisé en introduction, nous fournissons la démarche de management des risques liés aux technologies logicielles, et non pas le résultat complet de cette démarche, par exemple pour les techno- logies-objet. Ces résultats sont en cours d'obtention concernant les langages UML et Java. 3.2. Identification des risques Comme nous cherchons à juger et à maîtriser le lan- gage, et non l'application l'utilisant, la cible affectée est le programme-source ou le modèle. L'événement domma- geable est la faute qui l'affecte. Il ne s'agit pas d'une faute propre à une application particulière, mais d'un type de faute relevant des caractéristiques du langage. Considérons par exemple, le type de faute suivant : « redéfinition involontaire d'une méthode (ou fonction) héritée ». La figure 1 en fournit une illustration par un exemple de ce type de faute : dans la classe D, le concepteur a voulu ajouter une nouvelle méthode f (). Cependant, son nom et ses paramètres d'appel (ici vides) étant identiques A fo n gO "oT fo 10 AJOUT Î h i h CI.! ho () l Figure 1. Redéfinition itivolontaire d'une inéthode héntée. à ceux d'une méthode héritée de la classe A, cet ajout conduit donc à une redéfinition indésirée. Le dommage créé par cette faute exprime son effet sur le programme ou le modèle. Dans notre exemple, il s'agit des appels aux méthodes fo des objets qui sont ins- tances de la classe D ou des sous-classes de D. Dans la figure 1, on suppose qu'un objet 01 appelait la méthode fo de l'objet el, instance de la classe E, avant que la méthode fo ne soit ajoutée à la classe D. La méthode dont l'exécution était désirée était donc celle héritée de la classe A ; la méthode effectivement exécutée est la méthode homonyme ajoutée. Analysons maintenant les sources de ce risque. De façon générale, la propriété dangereuse est associée à la disponibilité d'un paradigme dans le langage : le langage a la propriété d'offrir telle ou telle construction dangereuse. Pour l'exemple traité, il s'agit de l'héritage. En effet, l'héritage induit un phénomène dangereux, qui est la pro- pagation inzplicite d'informations (méthodes, attributs, etc.). L'événement dangereux est la méconnaissance ou la non-prise en compte du phénomène dangereux par le concepteur. Ainsi la faute exprimée à la figure 1 provient du fait que le concepteur n'a pas perçu que la méthode fo ACTEUR: langage t PROPRIETEDANGEREUSE: miseàdispositiond'uneconstruction t PHENOI,IENE DAIQGEPEUX : indliitpar laconstruction t EVENEMENTDANGEREUX: effetnéfastesur le concepteur Figure 2. Dangersd'un langage de programmation. REE Nn il Décembre2005 M Dossier 1 1 1 SÛRETÉ DE FONCTIONNEMENT DES SYSTÈMES À FORTE COMPOSANTE LOGICIELLE ACTEUR:langage Java 1 UML PROPRIETEDANGEREUSE: offre l'héritage PHENOMENEDANGEREUX: propagationd infoniiat2ons EVENEMENTDANGEREUX: propagationimplicited'informations Figure3. Exeiiiple diiii (itiiigei- lié à 1liérit (ige. était déjà disponible dans l'ensemble des classes de la chaîne d'héritage.c La figure 2 synthétise les notions associées au dangerc d'un langage de programmation ou de modélisation. Lac figure 3 fournit une identification de l'exemple de dangerzz c considéré pour illustrer cette section. L'environnement est défini par la structure du programme. En effet, plus on s'éloigne de points de définition de méthodes, plus la méconnaissance des informations héritées est grande. On peut donc définir une topologie du programme.c Le fait de modifier le programme (ce qui est l'action de base de la conception) constitue la situation dangereuse. Elle est qualifiée par le lieu où cette modification est effectuée. Dans l'exemple, l'ajout d'une nouvelle méthode fo dans les classes A ou B aurait sans doute été moins dangereux, car la méconnaissance de l'existence de la méthode fo aurait été réduite, et de même la vraisemblance de l'occurrence de la faute. La figure 4 synthétise l'ensemble de ces notions. A BJ t Db 14'b\ f0 I 1 1 -- 1-i - -1 _-. -_- i i PROPRti-7C;1>.4!v'nrimulontariyJ - DOML\CE effet sur ! e programme (Ici, appels in OICntïlles de fo délit2ie d,7ns DI) 4. Effets des daiioers d'iiii Itiiigage cle pi-ogi-aiiiiiitioii.Il 3.3. Estimation des risques A partir du modèle d'identification précédent et pour chaque danger, il est nécessaire de définir des critèresZD d'évaluation et des métriques associés à chacun des cri- tères génériques établis au chapitre 2.3. Nous les intro-Zn duisons et les illustrerons en poursuivant le traitement de l'exemple présenté. L'amplitude doit qualifier le degré de dangerosité du phénomène, c'est-à-dire, dans notre exemple, l'importance de la propagation d'information. Nous la mesurons par une fonction intégrant le nombre de niveaux d'héritage, et le nombre de méthodes présentes dans le programme. L'exposition au risque est évaluée sur chaque classe de l'application afin d'obtenir une carte des expositions au risque. Pour chaque classe Ci, elle représente la somme pour chaque méthode M accessible dans Ci (héritée ou définie localement) des distances qui séparent la classe Ci étudiée de la classe Cj dans laquelle la méthode M est définie. La vulnérabilité de la modification du programme par ajout d'une méthode mo dans une classe C est fonction du nombre maximum de classes dans lesquelles la métho- de mo définie dans la classe C est effective. Dans la figu- re , avant ajout de fo dans la classe D, la vulnérabilité de fo en A est de 5, car fo de A est effective en A, B, C, D, E. la vulnérabilité de g () en B est de 2 car gO de B est effective dans B et dans F. L'approche de l'estimation des risques présentée ici est basée sur la définition de moyens de mesure sur des programmes ou des modèles. Deux autres approches sont fréquemment employées et ont été expérimentées : . l'interview d'experts consistant à demander une estimation basée sur l'expérience au moyen de métriques qualitatives ; cette approche a été mise en oeuvre sur UML [4], . le retour d'expérience par l'analyse de programmes ou de modèles dans lesquels on détecte la présence de fautes identifiées (événements dommageables) et leurs effets, afin d'en déduire des estimations du risque. Par exemple, pour une construction donnée d'un langage, la vraisemblance est déduite du nombre d'utilisations de la construction affectées par le type de faute identifié, divisé par le nombre total d'utilisations de cette construction dans le programme ou dans le modèle. 3.4. Evaluation et acceptation des risques L'estimation des risques associés à chaque construction du langage de programmation ou de modélisation fournit les valeurs de vraisemblance et de gravité. Or, si ces constructions sont sources de dangers, elles contribuent également à la sécurité en prévenant la présence de fautes ou en minimisant leurs effets. Par exemple, l'emploi de l'hé- ritage permet de considérer un élément comme une instan- ce d'un autre élément par la relation « est une sorte de ». REE N°n Décembre2005 Risques associés aux technologies logicielles w x*'* _____,, f "___J'-''.L... . <_______________ w '... ...., c <______/____'.''._________ ".________,. T ** j . ! !y Vraisemblance Figtii-e5. E.tii7iitioiz cles tisqties d'tiiie coiistrtictioii dtiii Iciligage. L'héritage facilite donc la conception, et permet la réuti- lisation de classes déjà créées et validées. Il est donc nécessaire d'estimer ces bénéfices en termes de sécurité avant d'affecter un niveau de risque à une construction donnée. De plus, pour une construction donnée d'un langage de programmation ou de modélisation, plusieurs phéno- mènes dangereux sont mis en valeur, puis estimés. On obtient ainsi pour chaque construction des représentations comme celle fournie à la figure 5, à partir desquelles on doit juger globalement de l'usage ou non de la construction. Enfin, l'évaluation et l'acceptation vont intégrer les coûts nécessaires à la réduction des risques, principale- ment pour les risques intermédiaires. 3.5. Traitement des risques Les traitements des risques sont répartis en quatre approches : le refus du risque, le transfert de risque, la prise de risque et l'optimisation du risque. Le refus du risque consiste tout d'abord à agir sur l'amplitude du phénomène dangereux. En premier lieu, l'usage de la construction concernée peut être interdite ; cependant les bénéfices associés sont alors perdus. On peut agir sur l'exposition au risque en l'interdisant. Cette solution est également inacceptable, car elle interdit de trop nombreuses modifications du programme ou du modèle. L'action principale est la réduction du risque. Celle-ci est obtenue par des techniques de prévention visant à réduire la vraisemblance de l'occurrence de l'événement dommageable. Par exemple, on peut limiter le nombre de niveaux d'héritage (réduction du phénomène par des règles de codage). Les techniques de protection ont pour but la minimisation de la gravité du dommage, c'est-à-dire dans notre cas de l'impact de la faute sur le programme. Cela peut être obtenu par des guides de modélisation facilitant la détection. Par exemple, en associant un mot- clef « override », respectivement « new », à chaque ajout d'une redéfinition de méthode, respectivement d'une nou- velle méthode, on peut détecter la faute de redéfinition involontaire d'une méthode, si une méthode possède deux fois le mot-clef « new » dans une chaîne d'héritage. 4. Conclusion Le choix d'une technologie logicielle de modélisation ou de programmation doit être effectué en ayant au préalable identifié et estimé les risques propres à cette technologie. Ensuite, en fonction de l'évaluation obtenue et de l'acceptabilité des risques, des mesures de réduction de ces risques doivent être proposées. Cette activité de management des risques est indépendante des applications. Elle doit donc être effectuée une seule fois. Seul le niveau d'acceptabilité des risques est ensuite variable. En consé- quence, en fonction de la criticité de chaque application ou par type d'application d'un secteur, des mesures de prévention ou de protection plus ou moins importantes doivent être choisies parmi la panoplie des moyens de réduction établis. Les bénéfices attendus et les enjeux financiers associés font partie des critères de ce choix. Les opportunités qu'offrent les constructions des langages en termes de bénéfices pour la sécurité doivent également être identifiées et estimées. Cet aspect n'a pas été développé dans cette présentation, qui s'est focalisée sur les risques négatifs, c'est-à-dire associés aux dommages comme conséquences, et aux dangers comme source du risque. L'évaluation globale des risques et les choix conduisant à l'acceptation de ces derniers doivent en revanche intégrer toutes les contributions positives à la sécurité. Enfin, la présence de risques identifiables associés à une technologie logicielle ne doit pas être considérée comme un défaut intrinsèque à cette technologie. Bien au contraire. En effet, ces risques permettent de mettre en valeur des classes de fautes qui seraient, pour beaucoup, présentes mais non détectables dans d'autres langages. Prenons l'exemple des types de fautes que sont les inco- hérences dans les modèles UML. Elles sont dues à la redondance ou à la complémentarité d'informations dis- ponibles dans ces modèles, en particulier du fait des divers diagrammes offerts qui permettent l'expression de multiples vues sur un même aspect d'un système. Il est erroné de penser que, du fait des nombreux types d'incohérences observables entre différents diagrammes UML, le langage UML est un langage moins sûr qu'un autre langage de modélisation moins riche qu'UML. En effet, si les points de vue variés sur les systèmes proposés par UML ne sont pas exprimables dans d'autres langages de modélisation, les types d'incohérences ne sont bien sûr pas observables. Cependant, les informations fournies REE No Il Décembre2005 m Dossier 1 1 1 SÛRETÉ DE FONCTIONNEMENT DES SYSTÈMES À FORTE COMPOSANTE LOGICIELLE par les modèles UML étaient bien présentes dans la tête du concepteur. Soit elles sont traduites dans des documents en langage naturel dont la cohérence globale est difficilement vérifiable, soit des informations sont perdues, et la faute présente que reflèterait une incohérence n'est pas détectable. Du fait de sa richesse, UML est finalement un langage plus sûr, grâce à la vérification de cohérence sur les différents modèles. De même, en l'absence du mécanis- me d'héritage, le concepteur effectuerait mentalement des analyses par l'analogie « est une sorte de » sans la forma- liser, et donc sans être capable de détecter les fautes qu'il introduit. Les activités sur le management des risques des technologies logicielles présentées dans cet article sont soutenues par la société Thales Avionics, par la Délégation Générale pour l'Armement, par le Ministère délégué à l'Enseignement Supérieur et à la Recherche et par l'ANRT (Association nationale de la recherche technique). 151 Références [1] US Department of Justice, " US. Sues Toyota For Clean Air Act Violation Claims 2.2 Million Cars Have Illegal Emission Control Monitoring Systems ", Washington, DC, 12 July 1999. [2] California Environmental Protection Agency, " Toyota Agrees ta Pay $7.9 Million Settiement ", News Release, Air ressources Board, 2 March 2003. [3] JP SEUMA VIDAL, H. MALGOUYRES. G. MOTET, " UML 2.0 Consistency Rules Identification ", International Conference on Software Engineering Research and Practice (SERP'05), Las Vegas, USA, CSREA Press, June 2005. [4] R. LOPEZ TORO, J.-P. SEUMA VIDAL, H. MALGOUYRES, G. MOTET, " UML Inconsistencies Assessment ", 3rd European Congress on Embedded Real-Time Software (ERTS06), Toulouse, France, January 2006. 161 [71 S GAUDAN, G. MOTET, E. JENN, S. LERICHE, " Identification Model of the Object-Oriented Technology's Rtsks for an Avionics Certification ", 3rd European Congress on Embedded Real-Time Software (ERTS06, Toulouse, France, January 2006. ISO/IEC Guide 51, " Safety Aspects - Guidelines for their Inclusion in Standards ", International Organization for Standardization, 1999. ISO/IEC Guide 73, " Risk Management - Vocabulary - Guidelines for Use in Standards ", nternatonal Organization 191 [101 [11 for Standardization, 2002, AS/NZS 4360 " Risk management ", Standards Australia, 2004. FD-X 50-252, " Management du risque - Lignes directrices pour l'estimation des risques ", AFNOR, 2005. " Handbook for Object-Oriented Technology in Aviation (OOTïA) ", http ://shemesh.iarc.nasa.gov/foot/, 2004, ISO/IEC 15942, " Guide for the Use of the Ada Programming Language in High Integrity Systems ", International Organization for Standardization, 2000. EI Et e u r s Gilles Motet est professeur à l'INSA de Toulouse et membre du LESIA (Laboratoire d'étude des systèmes informatiques et automatiques). Ses activités concernent la sûreté de fonction- nement et le management des risques des systèmes informa- tiques embarqués Il a participé à la rédaction de plusieurs ouvrages sur le sujet : " Design of Dependable Ada Software " (Prentice Hall, 1996),'Embedded Systems Applications " (éditeur, Kluwer Academic Pubishers, 1997), "Sûreté de fonctionnement des systèmes informatiques (Dunod-Masson, 1998), " Dependable Computing (éditeur, Theoretical Computer Sciences, Elsevier, 2002, "Design of Dependable Systems " (Kluwer Academlc Publlshers, 2002). Il contribue également à des activités de normalisation auprès de l'AFNOR et de l'ISO : ISO 15942 " Guide for the use of the Ada programming language in high integrity systems " (2000), " Marque NF Logiciel " (2003), AFNOR 50-252 " Management du risque Lignes directrices pour l'estimation des risques " (2005). Il est directeur scientifique de la Fondation pour une culture de sécurité industrielle. Stéphanie Gaudan a obtenu un Master en « ingénierie des systèmes critiques » de l'Un versité Bordeaux 1, Elle effectue actuellement une thèse au LESIA et à Thales Avionics sur l'utilisation du langage Java pour les applications avioniques embarquées critiques. REE N°H Décembre 2005