Soutenance mémoire
L’introduction de nouvelles prestations d’aide à la conduite automatisée, de sécurité active, par exemple, fait croître le nombre de calculateurs dans les véhicules actuels. Aujourd’hui, l’architecture électronique est composée en moyenne d’une vingtaine de calculateurs partageant de nombreuses informations (ex : vitesse, état du moteur), via des réseaux locaux. Les applications embarquées automobiles sont encore majoritairement des solutions propriétaires indépendantes, mais le regroupement de plusieurs fonctions connexes sur un même calculateur se pratique de plus en plus souvent pour économiser des ressources. Cette tendance sera plus vraisemblablement favorisée dans l’avenir avec des calculateurs plus puissants. La Figure 1 compare de façon très synthétique un réseau de calculateurs représentatif des véhicules actuels et le type de réseaux étudiés, à venir dans un futur proche (calculateurs moins nombreux mais hébergeant plus d’applications). L’organisation du logiciel, à l’intérieur de chaque calculateur, est représentée par une superposition de bandes colorées, correspondant à des couches d’abstraction logicielles. Il apparaît clairement, que la complexité grandissante des systèmes de contrôle électronique se traduit par une structure du logiciel embarqué de plus en plus évoluée. En effet, le multiplexage de plusieurs applications sur un calculateur requiert un support d’exécution capable de gérer un système multitâches temps réel.
Plus précisément, l’organisation du logiciel embarqué automobile évolue vers une architecture plus rigoureuse et standardisée. Outre la gestion de la complexité, les avantages recherchés d’une telle approche sont nombreux, en particulier : réutiliser du logiciel à porter sur une nouvelle plateforme matérielle, faciliter l’interopérabilité de l’intégration de composants logiciels sur étagère (Components-Off-The-Shelf COTS) économiquement avantageux, et tenir des délais de développement courts (quelques mois). Le standard automobile émergent AUTOSAR met en œuvre ces idées, avec une architecture logicielle modulaire, stratifiée en différentes couches d’abstraction. Toutefois, bien qu’il apporte des propriétés intéressantes sur le plan de la flexibilité des systèmes, ce type d’architecture peut aussi être source de nouveaux problèmes, en termes de robustesse par exemple. En effet, l’intégration de composants logiciels sur étagère de niveaux de criticité et de robustesse différents dans le même calculateur peut s’avérer dangereuse. Il s’agit de garantir, pour chaque fonction, les exigences de sécurité (-innocuité) qui lui sont associées indépendamment des autres fonctions, en dépit des phénomènes de propagation d’erreurs.
Le logiciel embarqué dans un calculateur fait partie du système mécatronique du véhicule. Ainsi, les fautes matérielles liées à l’électronique et l’environnement (perturbations électromagnétiques, variations de température, etc.) sont des sources d’erreurs pouvant provoquer la défaillance du logiciel. Elles peuvent se traduire, par exemple, par la corruption de données, de paramètres, voire même de segments de code. Par ailleurs, la complexité du logiciel est un facteur d’augmentation du nombre de fautes logicielles résiduelles. Ces fautes sont susceptibles d’apparaître tout au long du processus de développement du logiciel : au moment des spécifications, des évolutions de conception, de l’implémentation manuelle (erreurs d’interprétation possibles) ou automatique (si l’outil de génération de code n’est pas certifié), de l’intégration de modules de fournisseurs différents, etc.
Dans l’automobile, la notion de sûreté de fonctionnement est principalement caractérisée par la propriété de disponibilité, c’est-à-dire l’aptitude à l’emploi du véhicule. Elle concerne aussi d’autres aspects tels que la fiabilité (aptitude à assurer la continuité de service), la maintenabilité (aptitude au maintien en conditions de fonctionnement ou à la réparation en conditions d’après-vente définies) et la sécuritéinnocuité (aptitude du système à ne pas connaître d’évènement catastrophique). Dans ce contexte, notre travail vise à améliorer la robustesse du logiciel ce qui contribue à améliorer la sûreté de fonctionnement du système. Nous définissons la robustesse comme l’aptitude à fonctionner correctement en présence d’entrées invalides ou de conditions environnementales stressantes.
Du système mécatronique au logiciel embarqué
Un système mécatronique automobile est composé de constituants de natures technologiques différentes en interaction entre eux et avec l’environnement extérieur:
● Le système de contrôle électronique, également appelé architecture Electrique/Electronique (cf. Fig.2) ;
● Les interfaces homme-machine (volant, pédalier, commandes au volant, boutons du tableau de bord, badges, etc.) ;
● Les composants mécaniques, hydrauliques, électriques (câblage) et les matières chimiques présentes dans le système (fluides, gaz, etc.).
Un système électrique/électronique peut être décrit suivant trois angles : fonctionnel, logiciel et matériel (cf. Fig.2). Le système réalise des fonctions. Celles-ci échangent entre elles des flux d’information, qui peuvent représenter des grandeurs physiques à capturer, des signaux à produire pour piloter les actionneurs, ou encore des messages à communiquer entre les calculateurs via un réseau ou une liaison filaire. Les fonctions d’un système peuvent être, par exemple, l’acquisition des requêtes issues des utilisateurs et des autres systèmes ou l’état de l’environnement, le traitement de ces informations afin de calculer les commandes des actionneurs, la mémorisation de ces informations, l’envoi de ces informations vers les utilisateurs ou les IHM via des systèmes de communication. Certaines fonctions (acquisition, action) sont directement supportées par du matériel (capteurs, actionneurs).
Les fonctions de traitement de l’information (calcul, loi de commande, etc.) sont généralement implémentées par du logiciel, de plus en plus organisé en couches d’abstraction (couche applicative, intergiciel, exécutif temps réel).
Au niveau matériel, une fonction peut être répartie sur un ou plusieurs calculateurs (Electronic Control Unit ECU). Dans la suite du travail, nous considérons le logiciel embarqué dans un calculateur unique, qui communique éventuellement avec d’autres calculateurs. Les problématiques de conception classiques de l’embarqué temps réel s’appliquent à l’automobile. Les systèmes doivent être déterministes et sont soumis aux contraintes temporelles de l’environnement physique. En conséquence, les temps de réponse et l’utilisation de la mémoire des calculateurs doivent être bornés statiquement. Pour gérer en même temps plusieurs fonctions véhicules (climatisation, airbag, tableau de bord, etc.), la concurrence d’exécution est un moyen naturel de composer les systèmes.
L’environnement physique peut désigner tantôt un phénomène physique continu (e.g. température, vitesse), tantôt un évènement discret : appui bouton, seuil atteint, etc. Le contrôle de ces informations peut alors être continu, échantillonné, à évènements discrets ou encore hybride, selon la fonction véhicule considérée. Pour concevoir de tels systèmes informatiques de contrôle, le modèle logiciel classique de Turing est trop expressif et complexe. Depuis les années 80, l’introduction de langages de programmation (Lustre, Esterel) spécifiques aux systèmes embarqués temps réel, a particulièrement favorisé le développement d’une culture de programmation graphique, de spécifications exécutables, c’est-à-dire de conception des systèmes à base de modèles ([Simulink] [Stateflow] pour l’automobile, Scade pour l’aéronautique), et enfin de génération automatique de code (TargetLink pour l’automobile, Scade pour l’aéronautique).
Les politiques de développement du logiciel dépendent du constructeur automobile ou du projet véhicule en question. Le constructeur peut choisir de concevoir et développer entièrement ses propres logiciels, pour en avoir la maîtrise complète. Au contraire, dans un modèle de sous-traitance important, le constructeur confie la réalisation du matériel et du logiciel de la plupart des calculateurs à des équipementiers. L’émergence du standard d’architecture logiciel AUTOSAR favorise en particulier la sous-traitance de la production et de l’intégration de systèmes à logiciel prépondérant.
Modèle de fautes
Il est nécessaire de préciser ce que nous appelons « modèle de fautes ». C’est pour nous la liste de fautes (c’est à dire source ou origine des erreurs vis à vis du logiciel embarqué), que nous prenons en compte pour nos travaux. Ce modèle justifie de manière qualitative la nécessité de mettre en œuvre une solution de tolérance aux fautes. Le logiciel embarqué est indissociable de son contexte matériel et environnemental. Ainsi, un système embarqué automobile est susceptible de tomber en panne à l’exécution à cause de fautes physiques ou de fautes logicielles (bogues) résiduelles.
Les fautes physiques sont toujours une menace à cause de l’environnement agressif des applications automobiles (température, CEM, pièces mécaniques, humidité, etc.) et la nature même des composants électroniques (vieillissement des composants, défaut du matériel à la production, etc.). Le logiciel peut être altéré lorsqu’un composant électronique est intrinsèquement défectueux ou qu’il subit les agressions de l’environnement. Par ailleurs, le logiciel, au niveau de ses entrées/sorties, peut aussi mal percevoir ou agir sur l’environnement. En dehors des fautes physiques, le logiciel embarqué peut contenir des bogues résiduels, qui ont pu apparaître pendant les phases de conception, de codage ou d’intégration du cycle de développement logiciel. Pour chercher les origines des fautes purement logicielles, il s’agit de considérer le processus, et examiner pour chacune des phases de développement, les sources d’erreurs logicielles. La persistance des fautes peut être permanente ou temporaire. Une faute est permanente si sa présence n’est pas liée à des conditions ponctuelles internes (processus de traitement) ou externes (environnement). Une faute est temporaire si elle est liée à de telles conditions ponctuelles, et qui sont donc présentes pour une durée limitée. La probabilité d’occurrence des fautes est un facteur important pour décider des mesures de protection à prendre (mécanismes d’élimination ou de tolérance aux fautes). Des métriques existent pour les fautes matérielles [ISO26262-5]. Elles sont cependant spécifiques à des systèmes particuliers, propres à un constructeur, et présente donc souvent un caractère confidentiel. La quantification des fautes logicielles [Chillarege & al. 1992] n’est pas répandue dans l’automobile. Ne disposant pas de toutes les informations statistiques, nous adoptons donc une démarche pessimiste, où nous tenons compte de l’ensemble des sources d’erreurs potentielles, négligeant dans un premier temps la notion de probabilité d’occurrence.
|
Table des matières
Introduction
Chapitre I : Problématique
I.1 Du système mécatronique au logiciel embarqué
I.2 Modèle de fautes
I.2.1 Fautes physiques
I.2.2 Fautes logicielles
I.3 Standards automobiles émergents
I.3.1 Standard d’architecture logicielle
I.3.2 Standards pour la sûreté de fonctionnement logicielle automobile
I.4 Problématique
Chapitre II : Etat de l’art & Méthodologie proposée
II.1 Techniques recommandées par l’ISO26262
II.1.1 Techniques de détection d’erreur
II.1.2 Techniques de recouvrement d’erreur
II.1.3 Conclusion
II.2 Architectures classiques de tolérance aux fautes
II.2.1 Confinement horizontal
II.2.2 Confinement modulaire
II.2.3 Confinement vertical
II.2.4 Conclusion et position du problème
II.3 Principe de la solution de tolérance aux fautes proposée
II.4 Méthodologie proposée
Chapitre III : Développement des assertions de sûreté
III.1 Exigences de sûreté industrielles
III.2 Classification des modes de défaillances logicielles
III.3 Assertions exécutables spécifiques
III.3.1 Décomposition d’une exigence selon la Table 9
III.3.2 Déclinaison au niveau architectural (implémentation)
III.4 Matrice de traçabilité des exigences de sûreté
Chapitre IV : Architecture du logiciel de défense
IV.1 Logiciel de défense : Détection d’erreurs (Etape 2a)
IV.2 Logiciel de défense : Recouvrement d’erreurs (Etape 2b)
IV.3 Logiciel de défense : Traces d’exécution
IV.4 Instrumentation (Etape 2c)
IV.4.1 Hooks
IV.4.2 Services de base pour la capture d’informations
IV.4.3 Services de base pour le recouvrement
Chapitre V : Etude de cas
V.1 Cible logicielle AUTOSAR
V.2 Phase d’analyse
V.2.1 Etape 1a : Analyse des types de défaillances
V.2.2 Etape 1b : Analyse du type d’architecture logicielle
V.3 Phase de conception
V.3.1 Etape 2a : Conception des stratégies de détection
V.3.2 Etape 2b : Conception des stratégies de recouvrement
V.3.3 Etape 2c : Conception des stratégies de l’instrumentation
V.4 Phase d’implémentation
V.4.1 Etape 3a : Implémentation de l’instrumentation
V.4.2 Etape 3b : Implémentation du logiciel de défense
Chapitre VI : Validation expérimentale
VI.1 Généralités sur l’injection de fautes
VI.1.1 Notions de fautes, erreurs, défaillances
VI.1.2 Introduction d’erreurs dans un logiciel modulaire multicouche
VI.2 Technique d’injection de fautes utilisée
VI.3 Protocole d’injection de fautes
VI.4 Outils d’injection de fautes
VI.4.1 1er outil en simulation sur UNIX
VI.4.2 2eme outil de type « bit-flip » sur microcontrôleur
VI.5 Environnement de tests
VI.6 Illustration de l’approche de vérification
VI.6.1 Matrice de traçabilité
VI.6.2 Campagne de tests et exemple de résultats
VI.7 Résultats d’expériences et analyses préliminaires
Conclusion générale
