Soutenance mémoire
Au cours des dernières années, l’utilisation des véhicules automobiles a évolué. Précédemment symbole de liberté permettant de se rendre à n’importe quel endroit, la voiture est devenue, au fil de sa popularisation, un calvaire au quotidien, synonyme de temps perdu dans le trafic. Un français passant en moyenne 4 ans de sa vie dans sa voiture, ces dernières proposent à leurs utilisateurs de plus en plus de logiciels embarqués, que cela soit des aides à la conduite (aide au parking, régulateur de vitesse) ou de l’infotainment (Application mobile, réseau 4G) avec pour objectif le véhicule autonome. Ainsi, à l’instar du téléphone mobile se transformant en smartphone, la voiture n’est plus un simple outil de déplacement mais une véritable smartcar.
Ce changement d’utilisation de la voiture a entraîné une explosion des calculateurs embarqués appelé ECU (Electronic Control Unit) poussant les constructeurs automobile à former un consortium appelé AUTOSAR [AUTOSAR ]. Ce consortium à pour but de standardiser le support d’exécution logiciel des ECU. L’avantage de cette standardisation est de permettre une meilleure réutilisation du code, une standardisation des interfaces pour une meilleure communication entre les différents calculateurs, et une abstraction des couches basses (protocol de communication, drivers, système d’exploitation) avec la couche applicative. De plus, l’Organisation Internationale de Normalisation (ISO) a définit la norme ISO 26262 [Sinha 2011] permettant de garantir la sécurité fonctionnelle des systèmes électriques électroniques dans les véhicules automobiles.
Avec l’arrivée de Tesla sur le marché automobile, la voiture est de plus en plus personnalisable au niveau du logiciel qui peut être modifié à n’importe quel moment de la vie du véhicule. De ce fait, la capacité de mettre à jour à distance les systèmes embarqués automobiles est devenue un enjeu technologique majeur pour les constructeurs. Cette volonté de mettre à jour les systèmes à distance est avant tout économique. D’une part, cela permet de diminuer les coûts de maintenance du logiciel car le rappel au garage n’est, dans ce cas, plus nécessaire. D’autre part, cela donne une image de marque pour attirer de nouveaux clients en proposant d’ajouter des options après l’achat du véhicule.
Tolérance aux Fautes Adaptative
Les premiers travaux de la Tolérance aux Fautes Adaptative ou Adaptive Fault Tolérance remontent à [Kim 1990], qui la définissent comme : « une approche permettant de répondre à l’exigence de tolérance aux fautes de façon dynamique et très variée en utilisant de manière efficace et adaptative un nombre limité et en constante évolution de ressources disponibles ». Considérée dans un premier temps comme une branche de la tolérance aux fautes encore sous sa forme naissante, l’AFT a suscité dans un second temps un intérêt croissant, devenant une méthode à part entière. L’AFT est à la tolérance aux fautes ce que la résilience est à la sûreté de fonctionnement. C’est un moyen d’améliorer la résilience d’un système, prenant en compte l’état courant de ce système au niveau des ressources, de leur état et de l’environnement source de perturbations.
Mécanismes de tolérance aux fautes adaptatifs
L’AFT se veut une solution pour répondre à une question simple : Les mécanismes de tolérance aux fautes ne sont valides que sous certaines hypothèses. Que faire si une ou plusieurs hypothèses changent au cours de la vie opérationnelle du système? Le principe de l’AFT va donc nécessiter trois exigences primordiales. Il faut que les FTM mis en place (1) puissent évoluer indépendamment de l’application fonctionnelle, (2) aient une architecture permettant d’être modifiée avec un impact minimum sur la disponibilité de l’application et (3) puissent être mis à jour à distance [Stoicescu 2011]. Pour répondre à ces trois exigences, nous utilisons les concepts de Separation of Concern (SoC) et de Design For Adaptation (D4A). Nous fonderons nos travaux sur ces même concepts.
La Separation of Concern, présentée dans [Dijkstra 1982], signifie concentrer son attention sur un certain aspect en oubliant temporairement ceux qui ne sont pas pertinents au sujet. Pour l’AFT, cela signifie séparer les parties fonctionnelles d’un système, qui délivrent le service, avec les parties non-fonctionnelles . Cela permet donc de développer les FTM en parallèle du système, de les rattacher au système et de les modifier indépendemment de ce dernier. Seules les interfaces sont communes pour l’interaction entre le FTM et le service.
Le Design For Adaptation va être la capacité de créer les mécanismes pour permettre une modification rapide ayant un impact minime sur la délivrance du système. Dans le cas d’un intercepteur, un mécanisme qui intercepte les requêtes vers une application, on distingue les fonctions exécutées avant le service (p. ex. sauvegarde de l’état initial…), celle pendant (p. ex. vérification d’ordre d’exécution de tâche) et enfin celle après le service (p. ex. sauvegarde d’un point de reprise). Ce modèle de conception (Design Pattern) appelé Before – Proceed – After , est mis en avant dans [Stoicescu 2013]. Ce découpage en ordre d’exécution permet de compartimenter les différences entre les mécanismes et donc de définir les changements nécessaires au passage d’un mécanisme à un autre. Finalement, cela permet de ne changer que ce qui diffère entre deux FTM. Si nous prenons, par exemple , nous avons deux intercepteurs entre le Client et le primaire et le secondaire. Nous pouvons concevoir le mécanisme avec le Before qui contiendrait la synchronisation avant l’exécution avec le partage de la requête du primaire vers le secondaire, le Proceed qui effectuerait l’opération requise sur le service et l’After qui contiendrait la synchronisation post-exécution.
La mise à jour à distance (Over-The-Air updates), quant à elle, permet de suivre l’évolution logicielle qui interviendra au cours de la vie opérationnelle du système sans avoir un besoin d’accès à la plate-forme matérielle. Que cela soit pour des raisons financières (rappel de véhicule coûteux) ou techniques (intervention manuelle sur satellite impossible), la mise à jour à distance est nécessaire pour réagir aux perturbations.
L’AFT présente donc de nombreux besoins (SoC, D4A, OTA updates) et de nombreuses contraintes (Manipulation en ligne des FTM, Manipulation des communications, Intégrité de l’envoi des mises à jour à distance) pour son implémentation. D’une part, la Separation of Concern va imposer des règles de conception, des choix de langages et de techniques de programmation pour permettre le développement des parties fonctionnelles et non-fonctionnelles de manière détachée. D’autre part, le Design For Adaptation va demander une architecture logicielle et des solutions techniques permettant la manipulation dynamique des fonctions de tolérance aux fautes.
L’idée repose sur une analyse fine des mécanismes de tolérance aux fautes qui conduit à concevoir chacun d’eux sous la forme de briques élémentaires (des composants logiciels dans notre cas). Plusieurs mécanismes partagent plusieurs de ces composants, d’autres sont plus spécifiques au mécanisme considéré. L’AFT exigeant une évolution de l’architecture interne des mécanismes, elle astreint à une adaptation des communications internes (inter-composant) et externes (entre le client, le mécanisme et le serveur). On en déduit qu’un des moyens pour réaliser l’AFT est de créer des mécanismes de tolérance aux fautes comme un jeu de construction où chaque pièce mise dans un certains ordre permet de faire une structure particulière pouvant être réutilisée ailleurs. L’association « SoC + D4A + OTA updates » semble être une façon efficace de réaliser l’AFT et donc d’améliorer la résilience du système.
Mécanismes de tolérance aux fautes à composants
l’AFT a pour but d’assurer la sûreté de fonctionnement en cas de perturbation survenant durant la vie opérationnelle. Les FTM sont choisis pour répondre à certaines contraintes et sous certaines hypothèses. Une fois qu’une perturbation s’active, elle peut rendre une hypothèse obsolète et invalider l’utilisation du mécanisme. Les travaux [Excoffon 2016], [Stoicescu 2012b] et [Stoicescu 2013] mettent en avant la définition d’hypothèses selon trois classes qui sont le modèle de faute (FT), définissant le type et l’impact d’une faute en cas de défaillance (P.ex. Fautes matérielles permanentes ⇒ Réplication matérielle), les caractéristiques de l’application (AC) qui vont imposer des choix de stratégies de tolérance aux fautes (Pas d’accès à l’état ⇒ Pas de réplication passive) et enfin, les ressources nécessaires (RS) au bon fonctionnement de l’application (Bande passante limité ⇒ Pas d’envoi de message de checkpoint) et des FTM qui lui sont rattachée en terme de mémoire, de bande passante, de nombre de CPU alloué etc… L’AFT servant à adapter les FTM en cas de perturbation, il est nécessaire d’assurer la transition d’un mécanisme à un autre.
Programmation Orientée Composant
De l’Aspect au Composant
La programmation orientée aspect (AOP) a été proposée comme technique permettant d’améliorer la Separation of Concern. L’AOP s’appuie sur des technologies antérieures, notamment la programmation orientée objet, qui a déjà considérablement amélioré la modularité des logiciels. Un vaste corpus de recherche existe sur le sujet de la programmation orientée aspect dans de nombreux travaux tels que [Kiczales 1997] et [Irwin 1997] ou encore [Elrad 2001]. L’idée de l’AOP repose sur des concepts différents de la programmation orientée objet. Un aspect correspond à l’implémentation d’une spécification nonfonctionnelle qui est synchronisée avec le code applicatif. Cette synchronisation s’effectue grâce à divers moyens tels des pointcuts ou des intercepteurs sophistiqués s’appuyant sur des éléments structurels du langages (p. ex. les appels de fonction). Avec l’AOP, un système peut être décomposé en module. Chacun de ces modules peut gérer une spécification non-fonctionnelle. Ces modules comportent des greffons et des points d’activation. Les greffons sont le code qui sera exécuté lorsque l’application passera par le point d’activation. L’AOP est la capacité d’activer des modules (des morceaux de code) à des moments spécifiques comme avant ou après l’exécution d’une application. Concernant notre schéma de conception BPA, nous pourrions avoir deux modules Before et After qui sont activés avant et après l’exécution de l’application.
Le problème avec l’AOP est que les aspects sont enchevêtrés au code et ne permettent pas de réaliser correctement le niveau de SoC que nous attendons pour l’AFT. L’AOP reste une technique de programmation statique avec une définition a priori des modules. Il existe des possibilités de rendre la modification des modules dynamiques mais qui reste fastidieuse et liée à des outils spécifiques. Nous allons donc nous tourner vers la Programmation Orientée Composant. Cette technique de programmation consiste à utiliser une approche modulaire de l’architecture d’un projet informatique. Les concepteurs, au lieu de créer un exécutable unique, se servent de briques réutilisables pour constituer leur application.
|
Table des matières
Introduction & Objectifs
1 Contexte & Démarche scientifique
Introduction
1 Sûreté de fonctionnement et Résilience
1.1 Sûreté de Fonctionnement Informatique
1.2 Tolérance aux fautes
1.3 Résilience
2 Tolérance aux Fautes Adaptative
2.1 Mécanismes de tolérance aux fautes adaptatifs
2.2 Mécanismes de tolérance aux fautes à composants
3 Programmation Orientée Composant
3.1 De l’Aspect au Composant
3.2 Architectures logicielles à composant
4 Robot Operating System
4.1 Pourquoi ROS ?
4.2 ROS : Une architecture logicielle en LEGO
4.3 Conception d’une application sous ROS
4.4 Exemples d’utilisation de ROS
5 Contexte Automobile
5.1 Un standard pour développer les applications critiques
5.2 AUTOSAR
5.3 Mise à jour à distance et Adaptation
6 Démarche Scientifique
6.1 Problématiques
6.2 Déroulement des travaux de thèse
6.3 Ce que n’aborde pas cette thèse
7 Synthèse
2 Adaptation par composant substituable
Introduction
1 Conception théorique d’un FTM
1.1 Projection des mécanismes
1.2 Transition entre les mécanismes
1.3 Ensemble de mécanismes pour la validation de l’architecture
2 Implémentation de mécanismes sous ROS
2.1 Fonctionnement Nominal
2.2 Implémentation d’un composant
2.3 Implémentation du graphe de composant
3 Transition entre mécanismes
3.1 Reconfiguration d’un FTM
3.2 Adaptation entre deux FTM
3.3 Composition de deux FTM
4 Analyse critique de notre approche pour l’AFT
4.1 Une approche à gros grain suffisante ?
4.2 ROS, un support d’exécution idéal ?
4.3 ROS, AFT, approche à gros grain, ce qu’il faut en retenir
5 Synthèse
3 Du composant à l’action
Introduction
1 Décomposition fine des mécanismes
1.1 Modélisation en réseau de Petri
1.2 Affinage de la granularité
1.3 Méthode de classification : Un cas concret
2 Classification en action
2.1 Décomposition d’un ensemble de FTM
2.2 Définition de classes d’action
3 Analyse critique de l’approche sur la généricité
3.1 Implémentation des catégories d’actions
3.2 Avantages et Inconvénients de l’approche
4 Synthèse
4 Approche par actions ordonnançables
Introduction
1 Nouvelle méthode de conception
1.1 Du composant à l’objet
1.2 Conceptions des objets dynamiques
1.3 Un Gestionnaire pour les gouverner tous
1.4 Un Ordonnanceur pour les appeler et dans une table les lier
1.5 Mise en œuvre de l’AFT
2 Les plugins dans ROS
2.1 Définition d’un plugin
2.2 Une bibliothèque pour créer des plugins
2.3 Étapes de création d’un plugin
2.4 Utilisation d’un plugin
3 Implémentation des FTM sous ROS
3.1 Implémentation des objets statiques
3.2 Implémentation des objets dynamiques
3.3 Adaptation et Composition
4 Analyse critique de la nouvelle approche
4.1 Avantages d’implémentation
4.2 Avantages conceptuels
4.3 Inconvénients de l’approche
5 Synthèse
5 Application au Contexte Automobile
Introduction
1 Évolutivité des systèmes automobiles
1.1 Mise en œuvre de l’AFT avec AUTOSAR Classic Platform
1.2 Adaptation pour l’automobile : AUTOSAR Adaptive Platform
2 Analyse de l’AFT sur AUTOSAR Adaptive Platform
2.1 Projection de l’approche par composants substituables
2.2 Projection de l’approche par actions ordonnançables
3 Synthèse et perspective pour l’automobile
Conclusion
