Nouvelle méthodologie de développement de logiciels ...

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

NOUVELLE METHODOLOGIE DE DEVELOPPEMENT DE LOGICIELS EMBARQUES DANS LA PHASE DE PROTOTYPAGE

NEW DEVELOPMENT METHODOLOGY OF EMBEDDED SOFTWARE IN THE PROTOTYPING PHASE

Adil ALIF et Jean GODOT Bertrand BARBEDETTE, Sébastien SAUDRAIS FAAR Industry ESTACA’Lab 43 rue du saule trapu Rue Georges CHARPAK 91300 MASSY 53061 LAVAL

Résumé De nos jours, l’augmentation de la complexité des systèmes embarqués impose la prise en charge, dès les premiers prototypeset au niveau logiciel, d’exigences habituellement traitées plus tardivement voire même seulement lors du passage en série, comme notamment les contraintes de sûreté de fonctionnement. Cet article propose une méthodologie de développement de logiciels embarqués pouvant répondre aux besoins et contraintes de développement de ces logiciels dans la phase de prototypage. La flexibilité de la méthodologie garantit une meilleure gestion des évolutions récurrentes caractérisant les logicielsdans cette phase de prototypage. Aussi, grâce à sa structure bien adaptée, l’aspect automatisé de son intégration et de sa mise en place, notre méthodologie garantit une réduction significative des coûts du passage en série et de la mise en place des normes ISO 26262 et DO-178. Pour illustrer les résultats que nous obtenons grâce à notre méthodologie et les outils associés, un cas d’étude est présenté. L’exemple d’étude s’inscrit dans le cadre d’un projet de robotisation d’un véhicule et est centré sur la fonction « accélérateur ».

Summary Nowadays, the increasing complexity of embedded systems requires the management, from the first prototypes and software level, of requirements usually handled later even only when passing in production, such as including dependability constraints. This article deals with a development methodology for embedded software that can meet the needs and constraints of developing this software in the prototyping phase. The flexibility of the methodology ensures better management of recurring changes characterizing the software in the prototyping phase. Also, due to its well-adapted structure, and automated aspect of its integration and implementation, our methodology ensures a significant cost reduction of serialization and implementation of ISO 26262 and DO-178B. To illustrate the results, we apply our methodology and the associated tools to a case study. The study deals with the acceleration function of a vehicle. ______________________________________________________________________________________________________

Introduction 1 Contexte

D’une manière générale, le prototypage est principalement focalisé sur l’aspect fonctionnel, dans le but de prouver la faisabilité du système désiré. De nos jours, dans le domaine des transports, l’augmentation de la complexité des systèmes embarqués, leur implication dans des fonctions à caractère critique et les contraintes budgétaires, imposent la prise en charge, dès les premiers prototypes, d’exigences habituellement traitées plus tard, voire même seulement lors du passage en série. En parallèle, l’instauration de normes de sûreté de fonctionnement (SdF) comme l’ISO 26262 dans l’automobile (Kafka, 2012) ou la DO-178dans l’aéronautique (Hilderman et al., 2007), oblige les industriels à certifier leurs systèmes avant leurs homologations. Ce processus peut se révéler très couteux s’il est appliqué tardivement. L’ingénierie dirigée par les modèles (IDM) a permis de surmonter en partie cette complexité grandissante des systèmes et aussi de réduire le temps de développement. De plus, l’utilisation d’une méthodologie de développement bien adaptée permet de mieux maîtriser ces contraintes.

Nous avons constaté que les analyses de SdF ne sont souvent pas conduites sur le logiciel au niveau de la réalisation. Or, le développement logiciel est dépendant du niveau d’expertise et du style du développeur. Des erreurs peuvent être introduites malencontreusement dans le logiciel. Une des raisons de cette omission des analyses de SdF au niveau de la réalisation, est qu’à ce stade du développement le modèle ne contient pas seulement l’information structurelle des composants, mais il décrit aussi un comportement qui est induit par les blocs élémentaires composant ce modèle. Ce comportement a une influence sur l’apparition des événements redoutés. La gestion de cette dimension comportementale nécessite une bonne connaissance de chacun des blocs élémentaires utilisés et une expertise sur ce type de modèle qu’il faut réussir à prendre en compte dans les analyses de SdF.

Au cours du développement en prototypage, le logiciel en développement subit des modifications et des ajustements réguliers. Pour maîtriser ces changements, le modèle doit avoir une architecture bien définie afin de le rendre à la fois flexible et robuste. En effet, avec une structure bien cadrée, il sera plus facile d’appliquer les modifications et de s’assurer qu’elles ont été réalisées correctement. D’autre part, les analyses de SdF sont encore trop souvent réalisées manuellement, ainsi lorsque des modifications surviennent au niveau du logiciel, la mise à jour des analyses est longue et source d’erreur. L’automatisation du processus est une solution à ces difficultés, mais le mécanisme doit conserver une certaine flexibilité pour rester encore une fois adapté au prototypage.

Les problèmes décrits auparavant sont encore plus importants pour les petites et moyennes entreprises (PME) qui sont toujours à la recherche de produits innovants, et ainsi souvent directement impliquées dans les phases de prototypage. En effet, leurs ressources limitées et l’évolution constante des développements des prototypes imposent davantage à ces entreprises de travailler dans le cadre d’une méthodologie qui convienne à cette phase de développement.

Communication 7F-2 /4 page 1/8


Dans ce contexte, nous proposons une méthodologie de développement de logiciels embarqués basée sur les modèles, pouvant être appliquée en phase de prototypage. Notre méthodologie accorde la même priorité aux exigences fonctionnelles, de SdF et de performances tout au long du cycle en V. Elle accompagne le développeur à chacune des étapes du développement fonctionnel, avec en parallèle des analyses de SdF pour identifier les causes potentielles d’apparition d’un événement redouté, et ceci même au niveau de la réalisation du logiciel. Pour garantir la flexibilité de la méthodologie concernant la gestion des évolutions récurrentes, caractérisant les logiciels dans la phase de prototypage, le processus est en partie automatisé à l’aide d’outils. De plus, avec l’ajout de configurations, il est possible de cibler des zones du modèle à étudier pour éviter de refaire l’étude sur les parties qui n’ont pas été modifiées. Aussi, des outils viennent encadrer la méthodologie pour faciliter sa mise en place en accompagnant le développeur mais aussi en automatisant certaines tâches en particulier les analyses de SdF.

Pour illustrer les résultats que nous obtenons grâce à notre méthodologie, un cas d’étude industriel est présenté. Ce cas d’étude s’inscrit dans le cadre d’un projet de robotisation d’un véhicule. Pour l’article, nous n’aborderons que la sous-fonction « accélérateur » qui fait l’acquisition des signaux de la pédale, leur interprétation et leur transmission via un bus de communication.

Dans la suite de cet article, nous passons brièvement en revue les travaux connexes présentant des méthodologies intégrant des analyses de SdF. Nous présentons les méthodes et outils qui sont impliqués dans notre méthodologie. Ensuite, nous décrivons la méthodologie de développement et d’analyse et plus particulièrement ces spécificités. Finalement, nous illustrons certaines de ces spécificités avec le cas d’étude.

2 Travaux connexes

2.1 Analyse des arbres de défaillances et AMDE

L’analyse des arbres de défaillances ou « Fault Tree Analysis » (FTA) (Vesely et al., 1981) est une méthode déductive visant à découvrir les causes potentielles d’occurrence des événements redoutés dans des systèmes complexes. Un arbre de défaillances est représenté par un diagramme logique qui décrit les liens entre l’événement redouté étudié et ses différentes causes potentielles. L’analyse des arbres de défaillances est efficace pour montrer la résistance du système contre des défaillances uniques ou multiples.

L’Analyse des Modes de Défaillance et leurs Effets (AMDE) est une des méthodes les plus populaires pour réaliser une analyse de SdF, elle est largement utilisée dans l’industrie (IEC60812, 1991). L’AMDE est une méthode inductive utilisée pour identifier et éliminer ou anticiper les défaillances potentielles du système. Toutes les informations de l’analyse sont rassemblées dans un tableau spécifique. Ce tableau est divisé en deux parties, la première inclue les modes de défaillances, les causes et les effets, la seconde partie contient les recommandations d’amélioration et les actions qui ont finalement été menées. Le principal avantage de l’AMDE est son habilité à collecter de façon exhaustive les défaillances potentielles et à identifier leurs effets locaux. L’analyse des arbres de défaillances et l’AMDE sont généralement conduites conjointement car elles sont complémentaires.

2.2 IDM et outil de développement logiciel

La complexité des systèmes étant en constante augmentation, leur représentation à partir de données textuelles est devenue un travail fastidieux et les informations utiles ne sont plus clairement perceptibles. Ainsi, l’Ingénierie Dirigée par les Modèles (IDM) ou « Model-Driven Development » ou encore « Model-Based Design » (Schmidt, 2006) (Nicolescu et al., 2009) propose d’utiliser des modèles ou concepts pour représenter de manière efficace les problèmes posés aux ingénieurs mais aussi leurs solutions. Cette méthode a été largement mise en pratique dans le génie logiciel pour favoriser la représentation des architectures logicielles. Mais l’IDM ne s’étend pas toujours jusqu’au niveau de l’implémentation du logiciel. En effet cette étape est encore généralement réalisée à l’aide d’un langage de programmation tel que le langage C. Néanmoins, à l’aide de méthodes et d’outils de génération de code, il est maintenant possible de générer du code embarqué à partir d’un modèle représentant la stratégie de contrôle-commande du système. Ainsi, l’ingénieur s’affranchit de l’étape de programmation et peut se concentrer sur la réalisation de sa stratégie de contrôle-commande.

L’outil MotoHawk et les calculateurs embarqués associés (Woodward, n.d.) sont destinés pour les prototypes, les projets d’innovation et les productions en petite série pour des applications dans les transports : automobile, marine ou véhicules off-road. MotoHawk est un outil de développement de systèmes de contrôle et est intégré comme une bibliothèque dans Matlab-Simulink. Les composants Motohawk sont utilisés pour interfacer les entrées/sorties des calculateurs avec le logiciel embarqué. MotoHawk est principalement axé sur l’aspect fonctionnel et l’interfaçage entre le logiciel et le matériel, mais l’aspect SdF n’est pas suffisamment mis en avant lors de son utilisation.

2.3 Méthodologies existantes

HiP-HOPS ou « Hiercharchically Performed Hazard Origin and Propagation Studies » (Papadopoulos et al., 2001) est une méthode d’analyse de SdF qui automatise la construction d’arbres de défaillances et d’AMDE. Ces analyses sont générées à partir de la topologie de modèles système dont les composants ont été préalablement annotés avec des informations sur leurs défaillances potentielles et leurs équations de dysfonctionnement. Une équation de dysfonctionnement décrit le comportement des sorties d’un composant lorsqu’une faute arrive à une ou ses entrées ou qu’une défaillance interne se déclare. HiP-HOPS fonctionne avec des outils de modélisation système couramment utilisés tels que Matlab-Simulink1 ou SimulationX2. Un éditeur de défaillance est intégré dans ces outils de modélisation pour permettre à l’ingénieur système d’annoter les composants avec leurs informations de défaillances. L’utilisation de HiP-HOPS requiert des compétences avancées en SdF et implique une grande charge de travail,

1 http://fr.mathworks.com/ 2 https://www.simulationx.com/



impactant le coût du développement. De plus, en pratique avec Matlab-Simulink, l’outil ne permet pas de prendre en compte l’analyse des composants élémentaires du modèle comme les blocs : constante, gain...

AutOmotive Analysis and Safety EngIneering InStrument (OASIS) (Mader et al., 2013) est une méthodologie associée à un outil et elle est basée sur le langage EAST-ADL3 pour la description d’architecture système. Cette méthodologie réalise des analyses de SdF sur les modèles EAST-ADL. Elle conduit à la génération d’une architecture logicielle dans Matlab-Simulink. La suite de l’implémentation du logiciel n’est pas détaillée et aucune analyse de SdF n’est présentée sur le logiciel.

Le projet et la chaine d’outils Build-It-Safe (Vallée et al., 2013) visent à proposer une méthodologie soutenant le processus d’analyse de SdF et reposant sur des approches basées sur les modèles dans le contexte du domaine de l’automobile. Leur méthodologie permet de réaliser les analyses de SdF sur différents types de modèles comme UML4/SysML5 ou Matlab-Simulink. Le mécanisme consiste à transformer le modèle étudié en un fichier XML6 ayant un formalisme bien défini pour pouvoir être utilisé dans l’outil d’analyse. Ensuite, la liste des composants est importée à l’aide du fichier XML dans l’outil d’analyse. Chacun des composants peut alors être annoté avec des informations sur ses défaillances et ses équations de dysfonctionnement, de manière similaire à HiP-HOPS. Les résultats sont plutôt concluant avec des modèles UML/SysML car ils ne contiennent que des informations structurelles, c’est-à-dire sur l’organisation des composants entre eux. En revanche, avec les modèles Matlab-Simulink, le même procédé basé sur la topologie du modèle manque de précision. En effet, ce type de modèle ne contient pas seulement l’information structurelle des composants entre eux mais il décrit aussi un comportement qui est induit par les blocs élémentaires qui composent ce modèle. Ce comportement a une influence sur l’apparition des événements redoutés qui n’est pas gérée dans Build-It-Safe.

Méthodologie proposée 1 Présentation de la méthodologie

Nous proposons une méthodologie de développement de logiciels embarqués basée sur les modèles et qui par certaines spécificités permet d’être appliquée en phase de prototypage. La figure 1 représente la structure générale de notre méthodologie. Cette méthodologie reprend le concept de développement selon le cycle en V, et est consacrée plus particulièrement à la branche descendante de ce cycle. La méthodologie accorde la même priorité aux exigences fonctionnelles, de SdF et de performances tout au long du processus de développement. Concernant les exigences de performances, il s’agira

des contraintes d’exécution en temps réel. La suite de l’article décrit les différentes étapes de la méthodologie, nous nous attarderons plus spécialement sur ces caractéristiques qui la distingue des méthodologies plus traditionnelles.

1.1 Niveau architecture système

Même si la méthodologie présentée est destinée au développement de logiciels embarqués, la première étape concerne l’architecture système car il est primordial d’inscrire le logiciel dans son environnement. Le but, dans cette première étape, est de connaitre le nombre et le type de chacune des entrées et sorties qui sont utilisées sur le calculateur qui va contenir le logiciel embarqué. L’analyse préliminaire des risques menée à ce stade a pour objectif de déterminer les événements redoutés système (ERs). Ces ERs sont répartis en trois classes : l’absence ou la perte d’une fonction, le déclenchement intempestif d’une fonction et l’envoi de données erronées par la fonction. Comme le recommande les normes, les ERs sont évalués pour qu’un niveau de criticité leur soit attribué, appelé Automotive Safety Integrity Level (ASIL) pour l’ISO26262 ou Design Assurance Level (DAL) pour la DO-178. Cette évaluation permet d’identifier les événements redoutés les plus dangereux et donc pour lesquels il faudra être vigilent et mettre en place des stratégies afin d’éviter leur apparition. En connaissance des autres composants présents dans le système et leur relation, c’est-à-dire la topologie du système, il est possible en partant des événements redoutés, de remonter à leurs causes et notamment dans notre cas, à celles induites par le calculateur et son logiciel. Le logiciel n’étant pas encore développé, les causes potentielles de défaillances au niveau du calculateur se rapportent au dysfonctionnement de ces sorties.

3 Electronic Architecture and Software Tools – Architecture Description Language (EAST-ADL) 4 Unified Modeling Language (UML) - http://www.omg.org/ 5 Systems Modeling Language (SysML) - http://www.omg.org/ 6 Extensible Markup Language (XML)

Réalisation FTA et AMDE détaillées Tests Unitaires

Conception du logiciel FTA et AMDE préliminaires Vérification

Code embarqué

Spécification du logiciel Spécification SdF Intégration

Validation Architecture système Analyse préliminaire des risques

Cahier des charges

Plage d’analyse de SdF classique Plage d’analyse de SdF approfondie

FTA : Fault Tree Analysis = analyse des arbres de défaillances Figure 1. Synoptique de la méthodologie de développement de logiciels embarqués proposée



1.2 Niveau spécification

La spécification du logiciel décrit, de façon textuelle mais formalisée, les exigences qui doivent être implémentées dans le logiciel. Pour cette spécification, les exigences sont de deux types : fonctionnel, c’est-à-dire qu’elles décrivent ce que doit réaliser le logiciel, et performance, celle-ci décrivent les contraintes de temps réel. Ensuite, les exigences sont traduites en fonctions et en algorithmes qui devront être programmés dans les étapes suivantes. La spécification de SdF contient les exigences de qualité du logiciel. Ces exigences de SdF sont induites par le cahier des charges et l’analyse préliminaire des risques qui a été faites précédemment. Les stratégies de diagnostic et de repli répondant aux exigences de SdF sont spécifiées ici.

1.3 Niveau conception du logiciel

L’objectif à ce niveau est de construire l’architecture type d’un modèle logiciel de contrôle-commande tel qu’un superviseur. La méthodologie suit des règles de conception afin de structurer correctement le modèle : répartition des tâches et des fonctions, gestion des priorités, allocation et gestion des ressources. Cette architecture intègre les deux aspects : structurel et performance. A ce stade, la communication entre les grandes fonctions constituant le modèle et l’environnement extérieur est assurée. Aussi, les contraintes de temps réel sont respectées avec la création des tâches et la configuration de leur périodicité d’exécution. En effet, chacune des fonctions principales, vue à ce stade comme une boite noire, est reliée à une tâche.

En parallèle, une nouvelle étude de SdF est conduite. Pour cette nouvelle analyse de SdF, le champ d’étude s’est réduit par rapport à l’analyse des risques au niveau système. Les causes potentielles d’occurrence d’un ERs déterminées précédemment deviennent par projection des événements redoutés logiciel (ERl). Ainsi des analyses des arbres de défaillances et AMDE sont conduites sur les fonctions et sous fonctions qui viennent d’être créées en phase de conception pour déterminer comment elles peuvent causer l’apparition d’un ERl. A ce stade, les analyses de SdF reposent majoritairement sur l’étude de la structure du modèle logiciel. Après avoir défini les équations de dysfonctionnement des fonctions et sous-fonctions, le mécanisme de propagation est très efficace pour établir toutes les causes potentielles de chaque ERl.

1.4 Niveau réalisation du logiciel

La dernière phase de notre méthodologie est la réalisation. Il s’agit de programmer à l’aide de blocs élémentaires les lois de contrôle-commande de chacune des fonctions. Des règles de développement sont spécifiées pour cadrer le travail du développeur. Ces règles de développement reprennent ce qui se fait avec d’autres langage de programmation comme le code-C (MISRA-C, 2013), auxquelles s’ajoutent des conseils sur les blocs à privilégier. De nouveau, cette étape est associée à une étude de SdF. Ceci est une des principales particularités de notre méthodologie car les analyses de SdF sont rarement effectuées jusqu’à ce niveau de détail, à cause de l’apparition de la dimension comportementale des blocs à ce stade.

Comme indiqué dans la figure 1, les analyses SdF ne sont généralement pas conduites jusqu’à ce niveau d’avancement. Mais avec l’établissement de normes comme l’ISO 26262, les analyses SdF doivent être conduites à chaque niveau de développement. Donc pour suivre cette consigne, les analyses sont conduites à la main ce qui impact le coût et qui est source d’erreur d’autant plus lorsque des modifications sont nécessaires. Dans notre cas, une analyse SdF approfondie est menée sur le modèle réalisé en vue de l’enrichir avec les recommandations résultantes. Il est à noter que le modèle à cette étape est souvent très riche et peut contenir des milliers de blocs décrivant des comportements divers et variés : physique, électronique ou encore diagnostic. L’analyse SdF conduite doit gérer cette diversité, et être suffisamment flexible et automatisée pour suivre l’évolution constante du modèle. Pour cela, notre analyse SdF s’appuie sur des règles spécifiques prenant en compte les différents blocs utilisés avec les différents types de défaillances, scénarios de dysfonctionnement et événements redoutés qui leurs sont associés (Godot et al , 2016). Ces règles sont dépendantes de chaque type de bloc élémentaire et de l’événement redouté étudié. Les événements redoutés pris en charge par notre méthodologie sont : absence de la fonction, fonction déclenchée de manière intempestive et valeur de sortie de la fonction erronée. Ces règles sont appliquées sous forme de filtrage, c’est-à-dire que dans un premier temps l’analyse est conduite sur tous les blocs puis il est possible pour l’utilisateur d’activer ces règles ou filtres pour obtenir un résultat plus précis.

Enfin, la dernière étape de la méthodologie consiste à raffiner le modèle suite à des tests unitaires, fonctionnels et dysfonctionnels.

Dans la figure 2, voici un exemple illustrant l’influence du comportement des blocs dans le modèle. Dans ce modèle apparait deux blocs élémentaires de type gain (Sortie = Gain x Entrée) mais leurs influences quant aux événements redoutés ne sont pas identiques. En effet, le bloc « gain » de valeur 2 est lié à des blocs qui mènent au trigger d’un sous-système ; s’il est mal paramétré ce bloc peut conduire à l’événement redouté : déclenchement intempestif de la sortie. Alors que le bloc « gain 1 » de valeur 5 est lié à la sortie de notre modèle, donc dans son cas s’il est mal configuré, il peut conduire à l’événement redouté : valeur de la sortie erronée.

Figure 2. Exemple de l’influence du comportement



1.5 Suivi des événements redoutés

En conduisant les analyses de SdF tout au long du processus, on assure un suivi permanent des événements redoutés à travers les différents niveaux d’avancement du modèle et ce jusqu’aux blocs élémentaires. La combinaison des arbres de défaillances et des AMDE sont très efficaces pour gérer cette traçabilité. La figure 3 illustre cette projection et propagation des événements redoutés dans les différents niveaux du système et du logiciel. Au stade d’analyse de SdF au niveau système, les événements redoutés sont définis à ce même niveau. Les modes de défaillances associées proviennent des sorties du calculateur et donc du logiciel. Lorsque l’on descend dans le cycle de développement, les modes de défaillances logiciels deviennent les événements redoutés pour l’étude du logiciel et les causes potentielles d’occurrence de ces événements redouté est au niveau des fonctions du logiciel. Enfin, les modes de défaillances des fonctions logicielles deviennent les événements redoutés des lois de contrôle-commande qui ont été implémentées au niveau de la réalisation.

1.6 Flexibilité de la méthodologie

La flexibilité de la méthodologie qui est une caractéristique importante pour être adaptée au prototypage, est apportée par plusieurs caractéristiques. Tout d’abord, par l’architecture du logiciel qui est bien organisée comme présentée précédemment en phase de conception, puis par deux méthodes spécifiques appliquées sur les analyses de SdF.

La première méthode vise à configurer les analyses de SdF pour limiter l’étendu du modèle à étudier. Il est possible de définir jusqu’à quelle profondeur du modèle, c’est-à-dire le niveau hiérarchique, on souhaite que l’analyse s’arrête. Ceci peut être utilisé lorsque l’on considère qu’à partir d’un certain niveau, les fonctions ont déjà été éprouvées et analysées, il n’est donc pas nécessaire de les inclure dans l’analyse.

La deuxième méthode consiste à marquer les composants au cours du parcours des analyses SdF dans le modèle afin de savoir lorsque les composants ont déjà été étudiés. De fait, si des modifications sont apportées au modèle, il est possible de déterminer quels blocs ont déjà été étudiés et par conséquent de ne pas répéter l’analyse. Pour avoir une meilleure garantie qu’aucune modification n’a été effectuée sur ces blocs, les paramètres, les blocs précédents et suivants et la position dans le niveau hiérarchique du modèle sont vérifiés en plus du marquage. Dans les arbres de défaillances générés et le tableau AMDE, l’impact des modifications est signalé en appliquant un code couleur sur les éléments des arbres de défaillances et sur les lignes du tableau. Ces pratiques sont en partie automatisées pour encore une fois faciliter le travail du développeur en prototypage.

1.7 Outils accompagnant la méthodologie

La mise en place de cette méthodologie est assurée par une chaine d’outils. Le développement du logiciel se fait dans l’environnement Matlab-Simulink complété de la bibliothèque MotoHawk pour assurer l’interfaçage matériel/logiciel. Un espace de travail est installé en surcouche de Matlab afin d’accompagner le développeur lors de la phase de conception et imposer les différentes règles de développement lors de la réalisation. Un kit d’outils dédié à l’analyse SdF se compose de trois logiciels : une interface homme machine (IHM) pour la configuration des analyses, un logiciel d’interfaçage avec les modèles développés puis le logiciel de génération des arbres de défaillances et des rapports AMDE.

2 Cas d’étude Pour illustrer les résultats obtenus grâce à notre méthodologie et les outils associés, un cas d’étude est présenté. L’exemple d’étude s’inscrit dans le cadre d’un projet de robotisation d’un véhicule. Nous nous intéressons à la fonction « accélérateur ». L’objectif est de remplacer le calculateur d’origine par notre matériel afin de pouvoir ajouter des fonctions d’automatisation. Dans le cadre de ce cas d’étude, la partie automatisation n’est pas abordée. Nous ne traitons que le développement de la partie traditionnelle de l’accélérateur c’est-à-dire la commande à partir de la pédale. Cette fonction est illustrée dans la figure 4, elle consiste à faire l’acquisition des deux signaux analogiques provenant de la pédale d’accélérateur, les convertir en pourcentage d’appui pédale et enfin les envoyer via le bus CAN 7.

7 Control Area Network (CAN)

Figure 3. Illustration du résultat de la propagation et projection des événements redoutés



Le logiciel embarqué est développé dans l’environnement Matlab-Simulink avec la bibliothèque spécifique MotoHawk pour l’interfaçage du logiciel avec les entrées et sorties du calculateur. Le modèle du logiciel réalisé est présenté en figure 5. Le niveau 0 correspond au paramétrage du calculateur, la configuration du bus de communication CAN et la création des taches avec leurs triggers définissant leurs périodes d’exécution. Dans le niveau 1, on définit les fonctions principales qui sont réalisées par le calculateur, dans notre cas la fonction « accélérateur ». Le niveau 2 décrit les sous-fonctions de l’accélérateur. Enfin à partir du niveau 3 et plus, il s’agit des niveaux d’implémentation du logiciel avec les algorithmes de contrôle-commande.

Nous abordons pour cette présentation la partie sur l’analyse de SdF au niveau de la réalisation. La sortie du logiciel est l’envoi d’un message CAN. Nous avons étudié à l’aide d’un arbre de défaillance toutes les sources potentielles d’erreur pouvant conduire à une défaillance de cette trame CAN c’est-à-dire l’absence de son envoi, un envoi intempestif ou encore l’envoi de données erronées dans la trame. L’arbre de défaillance obtenu contient 102 éléments dont 42 événements basiques. Nous choisissons un événement redouté plus précis du type mise à jour intempestive de la trame CAN et nous appliquons nos filtres qui permettent de mieux sélectionner les causes potentielles de cet événement redouté en fonction du comportement des blocs élémentaires du modèle. Dans ce cas, le résultat est réduit à 75 éléments dont 26 événements basiques. La figure 6 n’est pas ici pour montrer en détail les arbres mais pour illustrer leur réduction grâce au filtrage.

Concernant la répétabilité des analyses de SdF, nous avons réalisé une première étude sur un modèle ne contenant pas le bloc « saturation dynamic » qui se trouve au niveau 3 du modèle logiciel dans la sous-fonction « ControlStrategy ». Le bloc est entouré en pointillé dans le niveau 3 de la figure 5 pour le repérer. Cette saturation était réalisée directement sur le signal en amont dans la sous-fonction « safety ». Pour des raisons fonctionnelles, il a été choisi de réaliser cette saturation autrement d’où l’ajout du bloc « saturation dynamic ».

Lorsque nous réalisons la nouvelle étude de SdF, l’analyse n’est pas reconduite complètement, seul les modifications sont étudiées. Cette modification est identifiée clairement dans le tableau de l’AMDE comme le montre la figure 7. Les lignes grises proviennent de la précédente analyse alors que les blanches indiquent ce qui a été inséré suite à l’ajout du bloc « saturation dynamic ».

Figure 4. Modèle du logiciel de la fonction accélérateur

Figure 5. Architecture de la fonction « accélérateur »



Pour valider la méthodologie et les analyses de sûreté de fonctionnement, nous avons développé un modèle logiciel basique de la fonction « accélérateur ». Ce logiciel était uniquement centré sur l’aspect fonctionnel du système c’est-à-dire qu’il n’effectuait que la conversion des signaux pour les envoyer via le bus CAN, il ne remplissait aucune exigence de SdF. Ce logiciel est fonctionnel dans les conditions idéales mais il peut conduire à des dysfonctionnements comme la perte de la commande d’accélérateur, en cas d’apparition d’une erreur. Nous avons mené les analyses de sûreté de fonctionnement comme indiqué précédemment pour rendre le système de plus en plus robuste quant à l’apparition d’une défaillance. Ce travail reflète l’avancement d’un projet en prototypage avec de nombreuses modifications. Grâce à cette pratique, il a été plus facile d’identifier les sources d’erreur et d’appliquer des stratégies pour les éviter. Les événements redoutés ont été éliminés ou atténués selon les recommandations.

Figure 7. Arbres de défaillances complet (à gauche) / Arbre de défaillance filtré (à droite)

Figure 6. Tableau AMDE avec la gestion des mises à jour du modèle



Conclusion Nous avons décrit dans cet article une méthodologie de développement de logiciels embarqués pouvant répondre aux besoins et contraintes du prototypage, tout en délivrant des analyses SdF précises et de plus en plus indispensables même pour des systèmes qui ne sont pas encore destinés à la série. La méthodologie définit des règles de développement aussi bien dans la phase de conception, pour garantir la création d’une structure logicielle ajustée, que dans la phase de réalisation pour cadrer le développeur dans l’implémentation des lois de contrôle-commande. La méthodologie vise à assurer la conduite d’analyse de SdF tout au long du développement et même sur le modèle logiciel au stade de la réalisation. Ainsi, il est possible de suivre les événements redoutés et leurs causes potentielles à travers tous les niveaux d’abstraction du processus.

Une des caractéristiques de notre méthodologie est sa flexibilité dans le but de pouvoir s’adapter aux évolutions récurrentes des modèles logiciels dans la phase de prototypage. Cette flexibilité provient de l’utilisation d’une architecture logicielle type de contrôle-commande qui par sa structure facilite l’introduction de modifications, puis de l’emploi d’analyses de SdF qui peuvent d’une part limiter la profondeur des analyses à l’aide de configurations et d’autre part s’effectuer que sur les parties du modèle qui ont subies des changements.

Le cas d’étude a permis d’illustrer des spécificités de la méthodologie qui sont : l’étude de l’analyse de SdF au niveau de la réalisation du logiciel et l’identification des modifications lors d’analyses de SdF successives sur un modèle ayant subi quelques modifications. A ce jour, la méthodologie n’a été pratiquée que sur le cas d’étude présenté mais elle sera prochainement étendue aux autres fonctions du véhicule robotisé.

Concernant les analyses de SdF et leur fonction de filtrage, des recherches sont actuellement conduites pour étudier des événements redoutés plus précis qu’erroné comme par exemple valeur en dehors d’un intervalle et ainsi déterminer des causes potentielles encore plus précises et réduites. L’une des pistes notamment porte sur l’utilisation de réseaux bayésiens.

Ré fé re nc es Godot, J., Saudrais, S., Alif, A., Barbedette, B., & Larouci, C. (2016). Safety Analysis Generation from Prototyping Models for

Transportation Systems. In ACM - Symposium on Applied Computing (SAC 16).

Hilderman, V., & Baghi, T. (2007). Avionics certification: a complete guide to DO-178 (software), DO-254 (hardware).

IEC60812. (1991). Functional safety of electrocal/electronic/programmable electronic safety/related systems, analysis for system reliability-procedure for failure mode and effect analysis (FMEA).

Kafka, P. (2012). The automotive standard ISO 26262, the innovative driver for enhanced safety assessment & technology for motor cars. In Procedia Engineering (Vol. 45).

Mader, R., Armengaud, E., Grießnig, G., Kreiner, C., Steger, C., & Weiß, R. (2013). OASIS: An automotive analysis and safety engineering instrument. Reliability Engineering & System Safety, 120, 150–162.

MISRA-C. (2013). Guidelines for the Use of the C Language in Critical Systems.

Nicolescu, G., & Mosterman, P. J. (2009). Model-Based Design for Embedded Systems (CRC Press).

Papadopoulos, Y., McDermid, J., Sasse, R., & Heiner, G. (2001). Analysis and synthesis of the behaviour of complex programmable electronic systems in conditions of failure. Reliability Engineering and System Safety, 71, 229–247.

Schmidt, D. C. (2006). Guest Editor’s Introduction: Model-Driven Engineering. IEEE Computer, 39, 25–31.

Vallée, F., Lanusse, A., Alif, A., & Laarouchi, Y. (2013). Model-Based Safety Assessment : Experiments conducted in the Build-It Safe project . In ICSSEA’13.

Vesely, W. E., Goldberg, F. F., Roberts, N. H., & Haasl, D. F. (1981). Fault Tree Handbook.

Woodward. (n.d.). MotoHawk Control Solutions: Product Guide.


Nouvelle méthodologie de développement de logiciels ...

Documents

Transcript of Nouvelle méthodologie de développement de logiciels ...