Modélisation temps-réel et adaptation dans AUTOSAR

Télécharger le fichier pdf d’un mémoire de fin d’études

Systèmes embarqués

A l’heure actuelle, les systèmes embarqués jouent un rôle important dans notre vie de tous les jours. Même s’ils sont généralement invisibles pour l’utilisateur final, leur bon fonctionnement de manière continue et sans erreur revêt une importance majeure. D’autre part les architectures logicielles des systèmes embarqués sont conçues spécifi-quement pour répondre à des besoins particuliers.
Un système embarqué est un système autonome qui possède des ressources tem-porelles et matérielles limitées. Généralement le comportement attendu est temps-réel, c’est-à-dire que le système doit respecter des contraintes temporelles précises. Il doit alors être capable de traiter des informations et de répondre dans un temps adapté à l’évolution de son environnement. Un système embarqué fait partie d’un système plus grand.

Temps-réel

Une distinction qualitative peut être faite entre deux types de systèmes temps-réel : les systèmes temps-réel stricts (hard real-time) et les systèmes temps-réel mous (soft real-time). Dans le premier cas, la non-satisfaction de contraintes temporelles peut conduire à des situations catastrophiques, par exemple dans le cas des fonctions critiques de l’aéronautique. Dans le second cas, des dépassements peuvent être tolérés dans une certaine mesure, par exemple dans le cas du streaming vidéo. Il existe un continuum entre les systèmes temps-réel mous et stricts. En eﬀet, certains systèmes peuvent adresser simultanément des contraintes des deux types, par exemple un système qui perdrait certains messages mais informerait l’utilisateur [93].
Pour garantir le respect des propriétés temps-réel, des vérifications préalables peuvent être faite sur un système. Par exemple, dans le cas de systèmes utilisant un système d’exploitation temps-réel, il est possible de faire une analyse d’ordonnancement qui vérifie que les contraintes temps-réel sont respectées [64].

Sûreté

Les contraintes de sécurité-innocuité peuvent être critiques pour certains systèmes (par exemple, pour les systèmes de surveillance du coeur des centrales nucléaires), et dans ce cas des tests spécifiques doivent être mis en place. Pour d’autres systèmes, comme les smartphones, ces contraintes peuvent être relâchées dans la mesure où une défaillance peut facilement être corrigée et n’entraîne pas de conséquences potentiellement drama-tiques.
On parle de sûreté de fonctionnement pour un système lorsque celui-ci est capable de “délivrer un service de confiance justifiée” [2]. L’une des facettes de la sûreté de fonc-tionnement est la disponibilité, c’est-à-dire que le système doit être prêt à être utilisé à tout instant. Un système embarqué doit avoir la meilleure disponibilité possible. En eﬀet, l’indisponibilité peut mener à des conséquences catastrophiques si le système n’est pas en mesure de répondre à une sollicitation extérieure et de réagir de manière appropriée.

Ressources limitées

Par nature, les systèmes embarqués ont des ressources limitées. Généralement il s’agit de ressources temporelles et de mémoire disponible. En eﬀet, avoir plus de temps dispo-nible signifie généralement avoir un calculateur plus puissant, donc plus onéreux. Une quantité de mémoire plus importante est aussi plus chère. Les applications destinées aux systèmes embarquées doivent donc être conçues de manière à optimiser les ressources disponible et par conséquent limiter les coûts.

Modèle de développement

De plus en plus, le logiciel pour les système embarqué est conçu à partir de mo-dèles [24, 88, 71, 56, 29, 4]. Il s’agit alors de ‘Model-Based Design”. L’idée est de proposer une approche structurée pour le développement de systèmes complexes.
L’avantage proposé par ces approches est un développement plus aisé et rapide grâce à des outils spécialisés. Par exemple, dans [88], les auteurs expliquent comment l’utilisation de cette approche permet d’accélérer le développement de systèmes de contrôle pour les locomotives.
L’objectif est également de faciliter les communications entre les diﬀérents interve-nants sur le logiciel, de mieux gérer la complexité et d’améliorer la qualité du logiciel [29]. Cette approche permet de répondre aux besoins de développement pour les systèmes em-barqués, en terme de tests, de prédictibilité et de système distribués [4]. Les problèmes liés à la conception de système embarqué et certaines réponses sont détaillées dans [4].
Un exemple de conception de système embarqué dans le domaine de l’aéronautique grâce à une approche “Model-Based” est donnée dans [56]. Les auteurs de ce travail expliquent comment les coûts et les risques au cours du développement peuvent être réduits grâce à cette approche. L’industrie de l’automobile se tourne également vers cette approche [71].
Ces approches peuvent également permettre de s’insérer au mieux dans une chaine outillée existante afin de permettre des reconfigurations en ligne du système [24].

Mise à jour

Étant donné le contexte particulier qui est lié aux systèmes embarqués, de nom-breux problèmes émergent pour leur mise à jour [58]. En eﬀet, les systèmes embarqués doivent répondre à des contraintes de disponibilité importantes. Il peut être inacceptable que certains systèmes embarqués deviennent inutilisables et/ou doivent être redémarrés lors d’une mise à jour [46], alors que cette contrainte est parfaitement acceptable dans d’autres cas.
A l’heure actuelle, il est relativement fastidieux de faire des mises à jour ou des évolutions dans les systèmes embarqués car, historiquement, leur conception est faite de manière ad hoc afin d’optimiser au mieux les ressources utilisées. Toutefois, la flexibilité est une caractéristique souhaitable pour ces systèmes. En eﬀet, ils doivent de plus en plus se plier à l’évolution constante de l’environnement et/ou aux désirs de changement des utilisateurs. Ces derniers ont eu l’habitude de pouvoir faire des modifications facilement sur leurs smartphones ou leurs ordinateurs.
Enfin, l’un des problèmes est lié aux ressources limitées dont disposent les systèmes embarqués : comment dans ce cas optimiser l’utilisation des ressources alors que nous souhaitons pouvoir faire des modifications sur le système ? En eﬀet, ces modifications sont potentiellement plus consommatrices de ressources. En outre, il est nécessaire d’ajouter des mécanismes supplémentaires afin de permettre la flexibilité du système, ce qui est en contradiction avec l’optimisation des ressources disponibles.
Afin de réaliser la mise à jour, d’autres aspects doivent être étudiés, par exemple l’acheminement de la mise à jour au système, la gestion du côté distribué de cette mise à jour, ou encore la granularité des mises à jour. Ces aspects plus spécifiques sont abordés dans les chapitres suivants, et l’état de l’art correspondant est détaillé à ce moment là.
La mise à jour dans les systèmes embarqués automobiles peut être vue sous trois angles :
— la mise à jour de systèmes embarqués,
— la mise à jour de systèmes distribués
— les architectures pour mise à jour.
La reconfiguration dynamique, i.e. la mise à jour du système soit sous forme d’ajout de fonctionnalité, soit sous forme de modification interne, pendant son exécution, est un problème qui intéresse les chercheurs depuis de nombreuses années [28, 48, 92, 86]. Cependant mettre à jour des systèmes tels que ceux utilisés dans l’industrie automobile n’est pas aisé [58, 4] et de nombreux problèmes se posent :
— Comment optimiser les ressources tout en faisant évoluer le système ?
— Comment assurer la cohérence globale du changement si l’évolution n’est pas monolithique ? En eﬀet, dans le cas où une mise à jour est composée de plusieurs éléments, il faut que toutes les parties soient intégrées, ou qu’aucune ne le soit.
— Comment minimiser l’indisponibilité du système lors des mises à jour ? Comme expliqué précédemment (section 2.2.2), la disponibilité du système est un enjeu pour la sûreté de fonctionnement. Il faut donc s’assurer que les changements ne rendent pas le système indisponible pendant une durée inacceptable par rapport à la fonction à réaliser.
— Comment garantir la sécurité-innocuité du système ? En eﬀet, les systèmes em-barqués peuvent réaliser des fonctions critiques et il faut s’assurer que toute modification apportée ne perturbe pas le bon fonctionnement de celui-ci.

Mise à jour pour les systèmes embarqués

Faire évoluer un système embarqué ayant des ressources limitées peut être beaucoup plus problématique que dans le cas de systèmes plus traditionnels.
Pour ces raisons, il faut prévoir à l’avance et insérer des mécanismes spécifiques lors de la conception du système pour permettre des évolutions a posteriori. Les questions majeures sont les suivantes :
— Comment minimiser l’utilisation de ressources tout en permettant les évolutions ? Par exemple, dans [42], les mises à jour sont gérées par un élément ayant des res-sources plus importante et distribuées aux éléments ayant des ressources limitées.
— Comment limiter au maximum le temps d’indisponibilité du système pour faire ces évolutions ? Certaines approches permettent de faire des mises à jour “à chaud”, c’est-à-dire sans éteindre le système et en continuant à l’utiliser [5, 55].
— Comment conserver les propriétés de sécurité-innocuité du système ?
Les caractéristiques les plus intéressantes et recherchées lorsque l’on souhaite rendre possible les mises à jour dynamiques dans un système embarqué sont les suivantes : simplicité, transparence pour les applications et utilisation du moins de ressources pos-sible [46, 58]. Dans [104], les auteurs proposent un classement des diﬀérentes méthodes permettant de faire des mises à jour dans les systèmes embarqués. Ces systèmes sont classés en fonction des critères principalement liés à la facilité pour un utilisateur à eﬀectivement faire des mises à jour dynamiques dans le système.
Lorsque l’on parle d’évolution pour les systèmes embarqués, il existe plusieurs types selon l’approche qui est choisie. Il existe quatre types possibles d’évolution ou de mise à jour pour ces systèmes :
— les évolutions reposant sur les modèles,
— les évolutions reposant sur le binaire,
— la reconfigurations du système lui-même,
— les mises à jour pour les systèmes d’exploitation.
Les trois premiers types nous intéressent tout particulièrement et sont détaillées dans la suite de cette section. La mise à jour pour les systèmes d’exploitation nous intéresse dans une moindre mesure car notre objectif est surtout focalisé sur les évolutions des parties applicatives du système.

Modèles et évolutions

Les mises à jour utilisant des modèles présentent un intérêt particulier dans le cadre du Model-Based Design (MBD) qui se développe de nos jours de plus en plus dans l’indus-trie. Les avantages de ce type de procédé sont nombreux, tout particulièrement lorsque les systèmes en question sont complexes. En eﬀet, bien que cette approche soit diﬀérente des méthodes traditionnelles de développement, elle permet de faciliter grandement la conception, la simulation, le test et la vérification. De plus, le MBD facilite les com-munications grâce à un environnement de développement homogène et une réutilisation beaucoup plus facile des éléments.
Becker et al. [24] proposent une approche intéressante pour ajouter plus de flexibi-lité dans une architecture embarquée de type AUTOSAR en travaillant directement au niveau du modèle AUTOSAR. Ce travail présente un outil appelé dTool développé afin de définir les reconfigurations possibles du système en fonction de l’évolution de l’envi-ronnement. Ainsi, pour chacune des situations possibles, un nouveau modèle doit être créé. Un automate de reconfiguration est également créé dans dTool pour permettre de prendre une décision de reconfiguration en fonction de la situation. L’objectif des au-teurs ici est de proposer une approche qui puisse s’interfacer facilement avec une chaine d’outil AUTOSAR existante. L’inconvénient majeur de l’approche proposée est qu’elle est fortement attachée à un outil spécifique qui permet de faire des développement d’ap-plication AUTOSAR, à savoir SystemDesk distribué par dSpace. Elle manque donc de transversalité par rapport au standard lui même.
Une autre approche plus générale est proposée dans [32]. Dans ce travail les auteurs présentent une suite outillée qui repose sur UML. Elle n’a pas pour vocation d’être spécifique au domaine automobile, mais s’adresse aux systèmes temps-réel critiques en général. L’approche utilise une partie restreinte des possibilités de modélisation d’UML afin d’utiliser des outils de model-checking et de générer du code. De plus, cette approche permet de vérifier un certain nombre de propriétés temporelles du système. Toutefois, le modèle UML ne fait pas partie intégrante du processus de développement tel qu’il est défini dans le standard AUTOSAR.
Enfin, dans [94], les auteurs proposent un modèle formel pour supporter les mé-canismes de mise à jour dynamique des composants. Dans les systèmes embarqués, les mécanismes permettant les mises à jour sont majoritairement réalisés de manière ad hoc. Ces mécanismes peuvent donc être non seulement très complexes, mais également source d’erreur. Ainsi, il est très diﬃcile d’ajouter de manière automatique dans tous les nouveaux systèmes des mécanismes permettant les mises à jour. En analysant les diﬀérentes techniques proposées pour faire des mises à jour dans diﬀérents domaines, les auteurs ont défini le concept de Dynamic Update Connector (DUC) qui correspond à un élément du système qui gère toutes les connections entre les composants. De cette manière lorsqu’un nouveau composant vient remplacer un ancien, le DUC gère toutes les connections de manière transparente pour le reste du système. Ce composant gère également le transfert d’état. Les diﬀérentes interactions entre les composants, ainsi que les mécanismes de mises à jour, peuvent ensuite être décrites en utilisant CSP [52] (Com-municating Sequential Processes) afin de vérifier de manière formelle trois propriétés : la transparence pour les clients, l’obtention de réponse aux requêtes des clients de la part du serveur (propriété d’équité), et l’absence de deadlock (propriété de vivacité).

Évolutions au niveau binaire

Les mises à jour des systèmes embarqués au niveau du binaire se concentrent plus sur l’intégration de la mise à jour dans le système d’un point de vue technique sans vraiment se concentrer sur la partie fonctionnelle qui y correspond. Dans ce contexte, il s’agit de faire une mise à jour diﬀérentielle du binaire, c’est-à-dire, déterminer quelles parties ont été changées, sans pour autant reprogrammer toute la mémoire de l’ECU (Electronic Control Unit). La mise à jour repose alors sur un système qui permet de construire un arbre de diﬀérence entre le binaire actuel et le binaire de mise à jour. Des exemples d’approche qui permettent d’identifier les diﬀérences entre deux fichiers binaires sont bdiff [91] ou encore Vdiff/Vdelta [91]. Ces deux approches cherchent les plus longues chaines identiques et représentent les diﬀérences entre les deux fichiers par une séquence d’instructions de changements. Ceci peut se révéler techniquement diﬃcile dans un contexte embarqué car les applications sont stockées en mémoire flash et un secteur de flash ne peut pas être partiellement ré-écrit : il faut tout d’abord l’eﬀacer intégralement avant de pouvoir écrire à nouveau [45].
L’approche proposée par Nakanishi et al. [73] permet de faire des mises à jour de bas niveau de manière diﬀérentielle. Dans cette approche, des patchs logiciels sont construits à partir du binaire présent dans le système et du nouveau binaire qui doit être chargé. Ainsi un fichier binaire est reconstruit à partir des diﬀérences trouvées entre l’ancien et le nouveau binaire. Cela permet de limiter la taille des patchs qui doivent être envoyés. Des mécanismes spécifiques doivent cependant être ajoutés dans le système embarqué lui-même pour pouvoir reconstruire le binaire complet après que le patch a été réceptionné. Cette approche est très intéressante, tout particulièrement dans le cadre d’une mise à jour OTA (Over-The-Air) car elle permet d’avoir une taille de binaire à envoyer très réduite (comparée à l’envoi complet du nouveau binaire).

Reconfigurations du système

Habituellement, lorsque l’on parle de reconfiguration du système, il s’agit de modi-fications faites au sein du système lui-même, sans nécessairement ajouter des éléments extérieurs. Il s’agit donc de modifier le comportement du système sans nécessairement introduire de nouvelles fonctionnalités. Par exemple, il est possible de n’exécuter qu’une partie de l’ensemble des fonctionnalités ou encore de n’exécuter certaines fonctionnalités que dans un contexte donné. Cette reconfiguration peut se faire de manière adaptative en fonction du contexte ou bien à la demande de l’utilisateur. Ce concept peut être ap-pliqué dans le cas où le système rencontre un problème et qu’il se met dans un “mode dégradé” où seuls les éléments essentiels sont exécutés : dans ce cas une reconfiguration peut être nécessaire pour atteindre ce mode dégradé.
Ces évolutions permettent de préserver les propriétés de sécurité-innocuité du sys-tème et de fournir une continuité de service même si certaines fonctionnalités non prio-ritaires peuvent être désactivées en cas d’absolue nécessité. Cela permet de répondre à deux contraintes majeures concernant le temps d’indisponibilité qui se voit réduit ainsi que les propriétés de sécurité qui sont conservées. Cependant, les évolutions qui sont per-mises dans le cas de reconfiguration du système lui-même sont assez limitées car elles ne prennent pas en compte l’ajout de nouvelles fonctionnalités : seuls des états pré-définis et connus du système peuvent être atteints.
Les mises à jour reposant sur la reconfiguration peuvent également permettre de ré-pondre à des problématiques de sécurité-innocuité du système. Dans [51] par exemple, les auteurs proposent de mettre en place un système de monitoring qui détecte les problèmes qui peuvent se produire dans le système surveillé et de placer ce dernier dans un état dégradé : seules les fonctionnalités essentielles sont alors conservées. Dans le domaine de l’adaptation pour la sécurité-innocuité, Schneider et Trapp, dans [100] développent le concept de “survivabilite” pour un système embarqué automobile, c’est-à-dire décider dynamiquement de ne garder que les fonctions critiques, en cas de problème. Les auteurs proposent une méthode pour modéliser, analyser et vérifier au moment de la conception les mécanismes permettant de faire une adaptation dynamique du système. Pour cela, un nouveau concept appelé MARS est défini afin d’étendre les possibilités de modélisation du système pour spécifier de manière formelle les mécanismes d’adaptation. Dans [43], les auteurs proposent une approche diﬀérente, fondée sur une reconfigu-ration au niveau des tâches. En fonction du contexte, un algorithme détermine si une tâche doit s’exécuter ou non. Cette approche est principalement destinée à être mise en place sur des systèmes d’infotainement. Dans ce contexte, un middleware spécifique au projet DySCAS 1 (Dynamically Self-Configuring Automotive System) est mis en place. Cette approche tranche avec la manière plus classique de voir les systèmes automobiles embarqués, car généralement dans ce domaine les tâches sont fixées statiquement au moment de la conception et aucune modification ne peut être faite a posteriori. Leur approche a un certain nombre de limites, en particulier elle se confine à un seul ECU (Electronic Control Unit). Chaque tâche est représentée par un nouveau modèle dans lequel elle peut être chargée, activée (dans ce cas la tâche peut s’exécuter) ou désactivée (la tâche ne peut plus s’exécuter). Le choix de l’exécution ou non des tâches repose sur la disponibilité des entrées de la tâche ainsi que sur la charge CPU.
Becker et al. [24] insistent sur le besoin pour les systèmes automobiles actuels d’avoir une plus grande flexibilité, par exemple dans le cas où un capteur est défaillant. Étant donné l’importance de la chaîne outillée utilisée dans le contexte d’AUTOSAR, leur objectif est d’intégrer au mieux aux modèles de l’application AUTOSAR, réalisés dans un outil donné, des modules spécifiques qui permettent la reconfiguration du système.
Ainsi, ces approches pour les mises à jour peuvent être vues comme complémen-taires. Elles répondent à diverses questions. Les mises à jour reposant sur les modèles définissent des évolutions qui peuvent être intégrées au système en utilisant des mises à jour diﬀérentielles de bas niveau (binaire). Enfin, il est également possible d’ajouter à cela des mécanismes qui permettent au système de se reconfigurer en cas de problème afin d’assurer au mieux les propriétés de sécurité-innocuité [51].

Mise à jour pour les systèmes distribués : cohérence globale

Certaines contraintes particulières sont à prendre en compte lors de la mise à jour de systèmes distribués. La première d’entre elles est liée à la cohérence globale. En eﬀet, dans les systèmes distribués, il est possible qu’une mise à jour impacte plusieurs nœuds du système. Il est important dans ce cas de s’assurer que tous les éléments de la mise à jour sur les diﬀérents nœuds sont bien ajoutés au système ou bien qu’aucun d’entre eux ne l’est.
Une autre contrainte concerne l’état du système : comment gérer l’état courant du système ? L’état représente non seulement la valeur des variables (doit-on garder leur valeur actuelle ou bien les réinitialiser après la mise à jour ?), mais également les flots de contrôle (doit-on reprendre à zéro ou bien continuer avec les nouveaux éléments ?).
Enfin, un concept important qui peut être développé pour les mises à jour est celui de la separation of concerns, c’est-à-dire de séparer le logiciel permettant de faire des mises à jour de celui qui réalise eﬀectivement les fonctionnalités.

Cohérence de la mise à jour

Les systèmes distribués peuvent comporter un grand nombre d’éléments, qui exé-cutent des programmes de manière concurrentielle. Dans un tel système, d’une part les modes de défaillance de chacun des éléments sont indépendants. D’autre part, la trans-mission de communications entre eux prend un temps non nul et il n’existe pas nécessai-rement d’horloge globale. Toutefois, l’exécution de certains programmes peut dépendre d’exécutions situées sur des nœuds distants (c’est-à-dire sur un élément diﬀérent et relié par un bus de communication). Un exemple de système distribué et temps-réel est le réseau de capteurs sur lequel de nombreuses études portent : par exemple, Han et al. proposent une étude des diﬀérentes techniques qui existent pour mettre à jour les réseaux de capteur [49]. Leur approche utilise un modèle d’architecture distribuée qui permet de créer et d’évaluer des outils de gestion logicielle pour les mises à jours de réseau de capteurs. En particulier l’évaluation des mécanismes pour la mise à jour repose sur trois critères principaux : l’environnement d’exécution des nœuds, le protocole de distribution des mises à jour et la compression des données transportées.
Un autre problème important qui peut se poser lorsque la mise à jour porte sur plusieurs éléments du système concerne la cohérence globale du système, qui doit être assurée. Il est donc important de garantir que la mise à jour est faite soit en totalité (tous les éléments concernés sont modifiés), soit pas du tout (aucun élément n’est mo-difié) afin de ne pas se trouver dans un état intermédiaire qui serait dommageable pour le bon fonctionnement du système. Ce concept a été développé par Gray qui définit qu’une transaction doit posséder les propriétés suivantes : être cohérente, atomique et durable [47].
Du point de vue du flot de contrôle, il faut également garantir une continuité dans l’exécution. En eﬀet, il faut s’assurer par exemple que lorsqu’un service est demandé par un autre composant, ce service est bien fourni et une seule fois. Pour cela, Kramer et Magee [60] ont défini le concept d’état de quiescence, c’est-à-dire un état dans lequel le composant ne traite et n’émet pas de requêtes, et n’est sollicité par aucun autre élément du système. Lorsqu’un composant est dans cet état, il est alors possible de le mettre à jour sans porter préjudice au système puisque ce composant n’est pas sollicité et ne devrait pas l’être pendant la mise à jour. Toutefois, d’autres recherches ont montré que cet état de quiescence est trop restrictif et que les mises à jour peuvent avoir lieu à condition de s’assurer de la cohérence de l’exécution [20, 66, 103].
Par exemple, dans [66], les auteurs considèrent que la cohérence de version pour les transactions est un critère de sécurité-innocuité dans le cas de reconfiguration dyna-mique. Ce travail utilise les dépendances dynamiques à l’échelle globale, i.e. les contraintes actuelles sur les composants, qui peuvent évoluer au cours du temps, afin de permettre plus de reconfigurations pour le système. Pour cela le concept de “cohérence de ver-sion” est définit pour les transactions qui implique qu’il n’existe pas un couple de sous-transactions (T1, T2) d’une même transaction, où T1 est exécuté sur un composant non mis à jour et où T2 sur un composant mis à jour. De cette manière ils définissent un état intermédiaire moins contraignant que l’état de quiescence mais plus contraignant que l’état de tranquilité [103].
André et al. proposent un framework pour prévoir le plan d’action qui permet de garder la cohérence du système [3]. Cette étape est extrêmement importante dans le cas des systèmes distribués, et ce tout particulièrement dans le cas de systèmes distribués de grande taille car un grand nombre d’éléments peuvent être impactés par la mise à jour. Il n’est toutefois pas forcément aisé de trouver un plan de reconfiguration ou de mise à jour qui soit optimal pour le système étant donné que de nombreux facteurs doivent être pris en compte pour y parvenir. Ainsi, Arshad et al. proposent un outil qui permet, à partir d’un modèle du système, de déterminer un plan de reconfiguration qui soit le meilleur possible (moindre nombre d’étapes ou temps de reconfiguration) [6].Pour cela ils ont développé un outil appelé Planit qui utilise la planification temporelle pour déterminer les déploiements possibles du système à partir d’un modèle.
Pour réaliser une mise à jour qui ne perturbe pas la cohérence du système, il faut non seulement déterminer le moment auquel la mise à jour peut être faite, mais également assurer la cohérence des flots de données et de contrôle, et enfin prévoir les actions qui permettent d’obtenir ce résultat. Par exemple, Banno et al. [20] proposent une méthode pour gérer la cohérence des mise à jour dans un système distribué en utilisant un outil appelé FREJA (Framework for Runtime Evolution of Java Applications). Le niveau de granularité pour les mises à jour est la classe et repose sur un Update Controller centralisé qui gère les mises à jour. Ce contrôleur délègue ensuite la gestion bas niveau des mises à jour à des Update Clients situés sur chacun des hôtes du système distribué. Enfin, un protocole spécifique est mis en place au sein de ce système afin d’assurer la cohérence globale. Ce dernier repose sur 4 étapes : 1/ vérifier qu’aucun élément pouvant invoquer le composant à mettre à jour n’est couramment exécuté, 2/ vérifier que le composant à mettre à jour lui-même n’est pas couramment exécuté et si c’est le cas bloquer l’accès au composant, 3/ vérifier si le composant à mettre à jour est inutilisé (étapes 1 et 2), procéder à la mise à jour, 4/ débloquer l’accès au composant.

État de la mise à jour

Ces systèmes présentent des caractéristiques spécifiques, qui rendent la mise à jour complexe : leur complexité architecturale, et pour certains, l’impossibilité de s’arrêter complètement pour la mise à jour [59]. En eﬀet, éteindre le système conduit à un temps d’indisponibilité qui peut être considéré dans certains cas comme inacceptable. D’autre part, redémarrer complètement un système a pour conséquence la perte de son état actuel (par exemple si le système avait un processus non terminé, il faut reprendre là où il s’était arrêté lorsque cela est possible). Reconstruire cet état peut alors être long et complexe [42].
Pour gérer ce problème, il est donc nécessaire de s’assurer de la cohérence des flots de données et de contrôle. Concernant la cohérence des données : lorsqu’un composant est remplacé par un autre, il faut s’assurer que le nouveau composant a des données correctes [60]. Généralement, la solution la plus simple pour assurer cette cohérence est de copier les données vers le nouveau composant afin que ses données soient correctement initialisées [77].
Afin de réduire les contraintes importantes apportées par la notion de quiescence, Vandewoude et al. proposent un nouveau concept, à savoir celui de tranquilité, comme alternative [103]. Si une séquence d’actions initiée par un nœud du réseau est appelée “Transaction”, il n’est pas nécessaire d’attendre la fin de cette dernière si le nœud qui doit être mis à jour ne lui fourni plus aucun service (même si ce nœud a été utilisé lors de la transaction). De plus, il est également possible de mettre à jour un nœud utilisé par une transaction si cette dernière a commencé mais n’a utilisé aucun service fourni par le nœud en question. Le nœud est alors dans un état de Tranquilité si : 1) il n’est engagé dans aucune transaction commencée, 2) il n’initie aucune nouvelle transaction, 3) il ne traite aucune demande ou 4) aucun nœud connexe n’est engagé dans une transaction dans laquelle le nœud qui doit être mis à jour a déjà été utilisé et doit à nouveau l’être. Cela nécessite d’avoir une hypothèse forte concernant la cascade de nœuds utilisés dans une transaction. Considérons trois nœuds N1, N2 et N3 tels que N1 débute une transaction. Lors de cette transaction une action est initiée par N1 sur N2 (A1) puis par N1 sur N3 (A2). N3 initie ensuite une action sur N2 (A3) puis la transaction se termine. Lorsque A1 est terminé, N2 peut alors être considéré comme étant tranquille ; cependant ce dernier est ensuite utilisé par N3 lors de la même transaction. Il faut donc être certain de l’indépendance entre A1 et A2 pour que la mise à jour sur N2 soit faite entre A1 et A2.

Séparation des éléments pour la mise à jour du reste du système : “separation of concern”

L’une des clefs de l’évolution des systèmes distribués réside dans la “separation of concerns”, i.e. la séparation de la gestion des mises à jour et de la partie applicative qui réalise une fonction spécifique.
Un exemple de technique pour permettre les mises à jour graduelles d’un système distribué tout en limitant son indisponibilité est proposé dans [1]. Leur approche repose sur une infrastructure spécifique qui permet de mettre à jour les nœuds du système. Cette mise à jour est faite grâce à la “couche de mise à jour” intégrée dans chaque nœud et doit répondre aux exigences suivantes : modularité, généralité, conservation de l’état persistant, déploiement automatique et contrôlé, et continuité de service. L’inconvénient majeur de cette technique de mise à jour est qu’elle repose sur une architecture dédiée, incompatible avec l’architecture AUTOSAR actuelle et non prévue pour des systèmes embarqués.
Un autre travail sur les systèmes distribués est plus orienté sur la reconfiguration dynamique de systèmes distribués en utilisant Argus, un langage qui permet de construire des systèmes distribués plus fiables [28]. Le problème qui se pose également dans ce cas est de pouvoir remplacer des parties de l’application tout en gardant un état cohérent et en minimisant les perturbations.
Dans [42], les auteurs proposent également une approche pour permettre la mise à jour dynamique de systèmes distribués présentant des ressources contraintes. L’objectif de ce travail est de présenter un outil qui permet une mise à jour des nœuds du réseau fondé sur le code binaire de l’application. Leur approche se soucie également de préserver l’état de l’application. Elle repose sur un nœud qu’ils nomment “manager” et qui dispose de ressources plus importantes que les autres nœuds du réseau. Il peut traiter les mises à jour avant de les envoyer au(x) nœud(s) concerné(s). Ce “manager” peut donc construire à partir du nouveau binaire et de l’ancien un ensemble de changements. Chaque élément de l’ensemble peut ensuite être intégré, au niveau du code binaire, dans chacun des nœuds du système distribué concerné par cette mise à jour.

Mise à jour pour les systèmes à composants

Il existe plusieurs types d’architectures qui ont pour vocation de permettre une adap-tation plus facile des systèmes, telles que les architectures orientées services (SOA : Service-Oriented Architecture) [81]. Le principe de ce type d’architecture est de mettre en relation des éléments fournissant un ou plusieurs services et d’autres consommant des services. Ils reposent ensuite sur un middleware qui met en relation les diﬀérents élé-ments. Il conserve également l’indépendance de ces éléments en masquant l’identité des fournisseurs et des consommateurs. L’intérêt de ce type d’architecture est tout d’abord une meilleure réutilisabilité, mais également une meilleure interopérabilité des éléments car il est possible d’avoir des technologies diﬀérentes fournissant et utilisant les services.
Les systèmes à composants sont également une option architecturale qui repose sur l’indépendance entre les diﬀérents éléments et une meilleure réutilisabilité. Il existe de nombreuses définitions de composants, la plus communément reprise est celle de Szy-perski [99] : “A software component is a binary unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties”.
Ainsi un composant doit pouvoir être développé par une personne diﬀérente de celle qui l’intègre. L’intégration correspond ensuite à un assemblage de composants afin de former une application. Un exemple de structure à composants logiciels est CORBA [76]. Ce dernier permet d’assembler des composants logiciels en utilisant des services d’un middleware (logiciel tiers qui gère les échanges entre les composants).

Architecture à composants et systèmes embarqués

Les systèmes à composants peuvent être utilisés pour des applications embarquées devant avoir un comportement temps-réel. Ces approches permettent un développement plus facile des applications en réutilisant des composants existants et en simplifiant l’architecture globale. C’est pour cette raison que l’architecture proposée par le standard AUTOSAR est elle aussi fondée sur une approche à composants. D’autres exemple de systèmes à composants existent également pour les systèmes embarqués temps-réel : par exemple ROBOCOP [67] existe pour les produits électroniques grand public connectés, et oﬀre une grande robustesse, Koala [102] pour les produits électroniques grand public (par exemple les télévisions) propose une meilleure flexibilité sans perdre en eﬃcacité ou encore SaveCCM [50] pour les systèmes critiques de contrôle dans les véhicules.
Une étude récente par Hosek et al. [54] propose une comparaison des diﬀérentes structures à composants orientées systèmes embarqués temps-réel. Cette étude utilise les critères suivants :
— support de fonctionnalités avancées,
— existence d’outils,
— méthode,
— support de la reconfiguration dynamique et d’applications distribuées,
— documentations,
— statut de développement.
L’avantage apporté par les composants pour les systèmes embarqués réside princi-palement dans leur réutilisabilité qui permet de réduire les coûts de développement, les délais de mise sur le marché et permettent d’avoir des systèmes distribués à grande échelle ainsi que des productions de masse. De plus, cela permet d’améliorer la qualité du logiciel en utilisant des composants déjà testés et utilisés dans des systèmes, et qui ont donc fait leurs preuves. Enfin la taille des composants étant réduite (comparée à une application dans son intégralité), cela facilite les tests unitaires [104].
De nombreux problèmes se posent lorsque les approches à composants sont utili-sées [4]. L’un de ces problèmes est le développement d’une architecture logicielle qui prend en compte la nature des composants et leur composition. Cette architecture doit permettre de
— spécifier la structure du système,
— spécifier son comportement,
— vérifier l’ordonnancement,
— vérifier l’exécution des composants,
— spécifier les composants logiciels selon des critères de décomposition systéma-tique et qui ne dépendent pas d’une application particulière, pour améliorer la réutilisabilité.

Architectures et mises à jour

OSGi (Open Service Gateway initiative) est une plateforme utilisant le langage JAVA, qui permet de gérer de manière modulaire les éléments qui constituent une application afin de permettre une reconfiguration sans arrêt de service [95]. Chen et al. ont proposé une approche pour permettre des mises à jour dynamiques de services [35]. Elle est fondée sur OSGi et utilise une méthode de spécification des mises à jour des services reposant sur l’utilisation des automates finis ainsi qu’un outil pour faire des vérifications formelles de certaines propriétés.
Li et al., dans [63] ont proposé une adaptation de cette plateforme dans un contexte automobile. Son objectif est de permettre une meilleure flexibilité des services téléma-tiques embarqués dans les voitures, mais ne concerne donc pas les calculateurs enfouis dans le véhicule.
Enfin, Concierge [89] propose une version de OSGi conçue pour les systèmes embar-qués. Son objectif est de prendre en compte au mieux les contraintes sur les ressources de ce type de système en réduisant l’empreinte mémoire et en améliorant les performances de la plateforme. L’inconvénient majeur de ces approche fondées sur OSGi dans notre contexte est leur incompatibilité avec AUTOSAR car elle repose sur une architecture à composants et des interfaces spécifiques qui sont diﬀérentes.
D’autres approches pour la mise à jour dans les systèmes à composants existent. Par exemple Gravity [34], proposé par Cervantes et al., présente une architecture à composants qui interagissent via des services. Cela permet alors d’introduire le concept des architectures orientées service dans un modèle à composants, qui doivent alors être capable de s’adapter dynamiquement, pendant leur exécution, à l’apparition de nouveaux services lors de l’ajout de composants. L’objectif ici est de pouvoir s’adapter facilement à l’ajout ou la suppression de composants pendant l’exécution de l’application. L’approche proposée ici repose sur une architecture spécifique qui n’est pas nécessairement adaptée pour les systèmes embarqués. Plasil et al. ont mis au point une architecture à composants appelée SOFA (SOFtware Appliance) et une extension à cette architecture, à savoir DCUP (Dynamic Component UPdating), qui permet de faire des mises à jour ou des échanges de composants de manière transparente pour le système [86]. Leur approche oﬀre des réponses intéressantes aux questions plus générales de gestion de version dans l’application (comment savoir dans quel contexte la mise à jour est intégrée, comment lier clairement une mise à jour à une version). Ils oﬀrent également des réponses concernant la gestion de l’état d’un composant au moment de la mise à jour et de la transparence de cette dernière pour l’utilisateur final.
Il est également important de prendre en compte le fait que ces systèmes qui sont soumis à évolution peuvent être critiques. Dans ce cas, il peut être intéressant de faire évoluer les mécanismes de sécurité en même temps que le système lui même. Dans le cas des systèmes à composants, Stoicescu et al. proposent une approche pour rendre les mécanismes de tolérance aux fautes évolutifs afin de permettre des évolutions à grains fins dans l’architecture [97].
Des travaux précédents ont traité la question de la mise à jour applicative dans AUTOSAR. Par exemple, Axelsson et Kobetski [18] proposent d’encapsuler une machine virtuelle JAVA dans un composant logiciel. Cette machine virtuelle pourrait ensuite recevoir les diﬀérents modules et les exécuter. Ainsi, les mises à jour seraient séparées du système de base. Cependant cette approche demande d’avoir une puissance de calcul bien supérieure à celle disponible sur les calculateurs embarqués traditionnellement utilisés dans les voitures. Elle semble donc compliquée à adapter à un vrai système embarqué automobile. D’autre part, en utilisant cette approche, l’architecture AUTOSAR elle-même n’est plus respectée puisque les mises à jour sont séparées du système principal et mise dans une architecture à part.

Classification des résultats

Nous avons présenté ici un certain nombre de résultats concernant les approches pour la mise à jour dans diﬀérents systèmes. Le positionnement de ces approches est résumé dans la table 2.1. Bien que certains résultats portent également sur la mise à jour oﬀ-line ([24] [32] [6]), ce tableau présente uniquement les diﬀérents résultats concernant la mise à jour en ligne. Nous pouvons voir ici que la majorité des résultats existants ne se positionnent pas nécessairement sur le domaine de l’automobile. D’autre part, beaucoup d’entre eux sont pour des systèmes distribués qui ne sont pas forcément adaptés dans le contexte embarqué qui est celui de l’automobile.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela chatpfe.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Chapitre 1 Introduction
Chapitre 2 Contexte, problématique et état de l’art
2.1 Introduction
2.2 Systèmes embarqués
2.2.1 Temps-réel
2.2.2 Sûreté
2.2.3 Ressources limitées
2.2.4 Modèle de développement
2.3 Mise à jour
2.3.1 Mise à jour pour les systèmes embarqués
2.3.1.1 Modèles et évolutions
2.3.1.2 Évolutions au niveau binaire
2.3.1.3 Reconfigurations du système
2.3.2 Mise à jour pour les systèmes distribués : cohérence globale
2.3.2.1 Cohérence de la mise à jour
2.3.2.2 État de la mise à jour
2.3.2.3 Séparation des éléments pour la mise à jour du reste du système : “separation of concern”
2.3.3 Mise à jour pour les systèmes à composants
2.3.3.1 Architecture à composants et systèmes embarqués
2.3.3.2 Architectures et mises à jour
2.4 Classification des résultats
2.5 Architecture logicielle embarquée automobile
2.5.1 Software component et runnable
2.5.1.1 Runnable
2.5.1.2 Ports
2.5.1.3 Inter-Runnable Variable (IRV)
2.5.2 Run-Time Environment (RTE) et Virtual Functional Bus (VFB)
2.5.3 Basic Software
2.5.3.1 Système d’exploitation (OS)
2.5.3.2 Pile de communication CAN
2.6 Synthèse
Chapitre 3 Architecture du système pour l’adaptation
3.1 Introduction
3.2 Espace d’adaptation et container
3.2.1 Différentes vues d’une application
3.2.1.1 Vue haut niveau
3.2.1.2 Vue niveau runnable
3.2.1.3 Vue niveau implémentation
3.2.2 Espace d’adaptation
3.2.3 Container
3.3 Développement d’une application logicielle embarquée : processus standard
3.3.1 Architecture logicielle fonctionnelle globale
3.3.2 Architecture logicielle AUTOSAR
3.3.2.1 Conception niveau Virtual Functionnal Bus (VFB)
3.3.2.2 Allocation sur les calculateurs
3.3.3 Création du code des ECUs
3.3.3.1 Création du logiciel applicatif
3.3.3.2 Allocation des runnables dans les tâches
3.3.3.3 Génération du RTE et configuration des couches bas niveaux
3.4 Modifications du processus de développement
3.4.1 Détermination de la version de l’application . .
.4.2 Ajout des containers
3.4.3 Ajout des mécanismes bas niveau
3.4.3.1 Réception des mises à jour – Update Services
3.4.3.2 Stockage des mises à jour – Container Manager et Flash Services
3.4.3.3 Exécution des mises à jour – Pointer Manager
3.4.4 Préparation off-line et intégration on-line
3.5 Types de mise à jour
3.5.1 Upgrade
3.5.2 Updates
Chapitre 4 Modélisation temps-réel et adaptation dans AUTOSAR
4.1 Introduction
4.2 Définitions et modèle de tâche classique
4.2.1 Worst Case Execution Time (WCET)
4.2.2 Offset
4.2.3 Contraintes de précédence
4.2.3.1 Définitions et modélisation
4.2.3.2 État de l’art
4.2.4 Modèle de tâches classique
4.3 Analyse d’ordonnancement et de sensibilité
4.3.1 Analyse d’ordonnancement
4.3.2 Analyse de sensibilité
4.4 Modèle de tâches et AUTOSAR
4.4.1 Contraintes de précédence, tâches et runnables
4.4.1.1 Priorités et précédences
4.4.1.2 Des contraintes de précédence sur les runnables aux contraintes sur les tâches
4.4.1.3 Allocation des runnables sur les tâches
4.4.2 Modèle de tâche dans le cadre d’AUTOSAR
4.5 Mise à jour, AUTOSAR et temps-réel
4.5.1 Caractéristiques de la mise à jour
4.5.2 Contraintes de précédence
4.5.3 Analyse de sensibilité
4.6 Application à un exemple simple
4.6.1 Présentation du système et de la mise à jour
4.6.2 Caractéristiques temps-réel de l’application initiale
4.6.3 Caractéristiques temps-réel de l’application mise à jour
4.6.3.1 Contraintes de précédence
4.6.3.2 Analyse de sensibilité
4.7 Conclusion
Chapitre 5 Mise en pratique des mises à jour
5.1 Introduction
5.2 Gestion des communications et création des mises à jour
5.2.1 Gestion des nouvelles communications
5.2.1.1 Canaux du RTE
5.2.1.2 Modifications du Basic Software
5.2.2 Création des mises à jour
5.2.2.1 Mise à jour et méta-données
5.2.2.2 Insertion des mises à jour
5.3 Gestion de version
5.4 Indirections et gestion de la mémoire
5.4.1 Indirections
5.4.2 Gestion de la mémoire
5.4.2.1 Types de mémoire
5.4.2.2 Gestion et stockage des mises à jour dans la mémoire
5.5 Sûreté de fonctionnement
5.5.1 Généralités
5.5.2 Sécurité-innocuité : AUTOSAR et ISO 26262
5.5.2.1 ISO 26262
5.5.2.2 AUTOSAR
5.5.3 Mécanismes de sécurité-innocuité
5.5.3.1 Sûreté de fonctionnement et mécanismes pour la mise à jour
5.5.3.2 Sûreté de fonctionnement et création de mise à jour
5.5.3.3 Conclusion
Chapitre 6 Application au cas des clignotants
6.1 Introduction
6.2 Outils et matériel
6.2.1 Cible matérielle
6.2.2 Trampoline
6.2.3 Otawa
6.3 Application initiale et processus de développement
6.3.1 Règlementation liée aux clignotants
6.3.2 Besoins fonctionnels et évènements indésirables
6.3.3 Modèle fonctionnel logiciel global
6.3.3.1 Indicateur de changement de direction
6.3.3.2 Warnings
6.3.3.3 Conception avancée
6.3.4 Modèle AUTOSAR
6.3.5 Allocation des runnables sur les tâches et modèle de tâche associé
6.3.6 Modélisation temps-réel
6.3.6.1 Contraintes de précédence
6.3.6.2 Analyse d’ordonnancement et de sensibilité
6.4 Étapes de préparation de l’application
6.4.1 Ajout de méta-données
6.4.2 Ajout de mécanismes pour la gestion des mises à jour
6.4.3 Ajout d’un niveau d’indirection et de containers
6.5 Mise à jour de l’application
6.5.1 Description des mises à jour
6.5.1.1 Freinage d’urgence
6.5.1.2 Clignotants impulsionnels
6.5.1.3 Conception Avancée
6.5.2 Modèle AUTOSAR pour les mises à jour
6.5.3 Temps-réel
6.5.3.1 WCET
5.3.2 Contraintes de précédence
6.5.3.3 Analyse de sensibilité
6.5.4 Gestion de version
6.6 Synthèse
Chapitre 7 Conclusion
Bibliographie