Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
Architecture logicielle embarquée automobile
Les voitures se modernisent de plus en plus, si bien qu’il est maintenant possible de trouver plus de 60 calculateurs embarqués dans certains modèles de voitures. Il y a donc eu une augmentation importante de la quantité de logiciel embarqué dans les voitures au cours de ces 15 dernières années. Une quantité croissante de fonctionnalités est à présent réalisée en utilisant du logiciel et de nombreuses innovations actuelles (jusqu’à 90% [30]) sont possibles grâce à celui-ci.
De plus, les véhicules sont maintenant de plus en plus connectés (les communica-tions car-to-car [33] ou car-to-infrastructure [90] sont des sujets auxquels les industriels s’intéressent de près). Cette ouverture des véhicules vers leur environnement peut à la fois permettre des évolutions plus faciles pour ces systèmes mais également poser des problèmes liés à la sécurité-immunité [74, 75, 53].
La complexité des systèmes embarqués évoluant de manière croissante, de nombreuses architectures logicielles sont apparues dans les différents domaines (par exemple AUTO-SAR [16] pour l’automobile ou ARINC 653 [87] dans le domaine aéronautique) afin de rendre cette complexité plus simple à gérer et de permettre une meilleure compatibilité entre des parties de logiciel développées par différentes entreprises. De plus, cela permet d’assurer une cohérence globale. Ainsi, lors de la conception d’un système embarqué, il faut se plier à un certain nombre de standards pour respecter l’architecture logicielle correspondante.
Le logiciel embarqué automobile se divise en deux domaines. Le premier est lié à l’infotainment, c’est-à-dire les systèmes multimédias et l’autre corresponds aux calcu-lateurs enfouis qui permettent de réaliser des fonctions qui ne sont pas nécessairement visibles pour l’utilisateur, comme les contrôles moteurs. Dans chacun de ces domaines, les procédés, architectures et méthodes de développement sont distinctes. Dans le cadre de cette thèse, nous nous intéressons principalement aux calculateurs enfouis. Ces derniers utilisent majoritairement une architecture de type AUTOSAR.
Cette augmentation massive du logiciel crée néanmoins des problèmes qui n’existaient pas avant. Par exemple, des fonctionnalités totalement décorrélées peuvent désormais se retrouver sur le même calculateur et interférer les unes avec les autres [31]. Dans ce contexte, la vérification et la validation du logiciel, sa maintenance ainsi que sa réutili-sabilité posent donc des problèmes majeurs.
Historiquement, les calculateurs embarqués étaient développés de manière ad hoc, c’est-à-dire que le logiciel associé à chaque calculateur était développé spécifiquement à chaque fois. Ceci était possible car peu de logiciel était embarqué dans les véhicules. Cependant ce procédé rendait très difficile la réutilisation du logiciel, ainsi que sa modi-fication, sa maintenance ou encore l’intégration de parties de logiciel issues de différents fournisseurs. D’autre part, dans le cas d’un logiciel ad hoc, il est difficile de changer d’architecture matérielle. Ainsi, pour des raisons de simplification et afin de résoudre ces problèmes, les différents acteurs de l’industrie automobile ont créé le standard AUTO-SAR (AUtomotive Open System ARchitecture).
AUTOSAR présente une architecture en couche qui permet d’abstraire le hardware. Il s’agit d’une architecture modulaire facilitant la construction du logiciel à partir de briques élémentaires. L’objectif du standard est de réduire les coûts de développement lo-giciel. En effet, les composants applicatifs peuvent être réutilisés facilement et être portés d’une plateforme à une autre. Il est également possible d’utiliser des COTS (Commercial Off-The-Shelf) [69] et de simplifier l’architecture matérielle en mixant des fonctions sur des calculateurs génériques.
Dans le standard AUTOSAR, un ECU (Electronic Control Unit) présente une archi-tecture logicielle divisée en quatre couches, comme montré par la figure 2.1. La couche la plus basse correspond au matériel. Au dessus du matériel se trouve le logiciel de base, également appelé couches basses (BSW ou Basic Software [9]). La couche la plus haute, quant à elle, est la couche applicative qui contient les différents composants logiciels (SWC ) réalisant les fonctions (AUTOSAR Software [10]). Enfin, entre la couche ap-plicative et le logiciel de base se trouve le middleware spécifique à AUTOSAR appelé Run-Time Environment (RTE) [12].
Ports
Les ports d’un SWC sont ce qui lui permet de communiquer avec le reste de l’ap-plication ou avec le BSW via le RTE. Un port n’appartient qu’à un seul SWC à la fois et ne peut pas recevoir et envoyer en même temps. Chaque port doit être associé à une interface qui définit la nature des informations véhiculées entre deux ports. Une interface peut être considérée comme un “type” pour le port. Un port ne peut être associé qu’à une seule interface. Cette dernière décrit également les opérations ou données associées.
Inter-Runnable Variable (IRV)
Les runnables d’un même SWC n’utilisent pas nécessairement le RTE (dans la version 4 d’AUTOSAR), et aucunement les ports pour communiquer. En effet, des données peuvent être réservées pour permettre la communication, indépendamment des tâches sur lesquelles ces runnables sont alloués. Ces données (IRV) ne peuvent êtres lues ou écrites que par les runnables appartenant à un SWC donné. Les données sont écrites par un runnable et lues par un autre. L’utilisation d’IRV permet une encapsulation des données dans la mesure où les autres SWC ne peuvent pas y accéder.
Run-Time Environment (RTE) et Virtual Functional Bus (VFB)
Dans AUTOSAR, une application est modélisée par une composition de SWCs inter-connectés [7]. Le RTE est l’interface concrète qui permet aux différents SWCs de com-muniquer non seulement entre eux mais également avec le Basic Software.
Le VFB(Virtual Functional Bus) permet la conception des fonctions indépendam-ment du matériel ou de l’allocation fonctionnelle entre les calculateurs : il réalise l’abs-traction des interconnexions entre les différents composants logiciels. L’existence du VFB est purement conceptuelle. Le RTE est l’implémentation concrète du VFB au niveau de l’ECU. La figure 2.2 illustre, sur un exemple extrait des spécifications AUTOSAR 4.0, la différence entre le niveau VFB et le niveau RTE. Ainsi, la partie haute de cette figure montre différents composants qui communiquent via le VFB il s’agit d’une vue archi-tecturale qui montre les différents SWCs présents au final dans le système. Ensuite ces SWCs sont alloués sur les différents ECUs disponibles au cours du processus de dévelop-pement. Le RTE de chaque ECU doit ensuite être généré. Quel que soit l’emplacement physique des SWCs, la communication doit se faire de manière transparente pour ces derniers : le SWC ne sait pas où se situe physiquement la source (ou la destination) des messages qu’il reçoit (ou envoie.
Basic Software
La figure 2.1 montre que le Basic Software contient de nombreuses briques logicielles. Cependant, dans cette section nous ne détaillons que celles qui sont les plus importantes du point de vue de la mise à jour dynamique dans les systèmes embarqués automobiles. Dans le cas particulier de ce travail, nous nous intéressons plus en détail au système d’exploitation, communément abrégé “OS” (pour Operating System) ainsi qu’à la pile de communication. Le premier des deux éléments, l’OS, gère l’exécution des runnables. En effet, c’est lui qui exécute, entre autre, des tâches qui contiennent elles-mêmes les runnables. La pile de communication, quant à elle, gère les flux entrants et sortants sur les différents bus logiciels disponibles, et par conséquent la communication entre l’ECU et son environnement.
Système d’exploitation (OS)
Afin de garantir les propriétés temps-réel du système embarqué automobile dans le cadre d’une architecture AUTOSAR, le standard définit un système d’exploitation asso-cié appelé AUTOSAR OS [11]. Il est fondé sur un standard précédent appelé OSEK [78].
Un OS de type AUTOSAR doit posséder un ordonnancement à priorité fixe (chaque tâche possède une priorité qui ne varie pas au cours de l’exécution), offrir une protection contre un mauvais usage des services de l’OS et être capable de gérer les interruptions. Ces dernières doivent avoir des priorités supérieures à celles des tâches. Ces caractéris-tiques principales de l’OS associé au standard sont largement héritées de OSEK.
Dans le modèle architectural proposé par AUTOSAR, l’implémentation d’un com-posant logiciel se fait par l’intermédiaire de l’allocation de chacun des runnables qui le composent sur une ou plusieurs tâches de l’OS.
Le système d’exploitation temps-réel qui nous intéresse ici dispose de deux types de tâches, à savoir les tâches basiques et les tâches étendues que nous détaillons ici.
Modèles de tâches La différence principale entre les deux types de tâches peut se résumer par le fait que les tâches étendues peuvent être dans un état d’attente d’un évènement extérieur alors que les tâche basiques ne le peuvent pas. Ainsi, la synchro-nisation entre une tâche basique et son environnement ne se fait qu’au début et à la fin de son exécution. Alors que les tâches basiques consomment peu de mémoire, les tâches étendues apportent une meilleure cohérence (en ayant plus de points de synchronisation).
Ainsi, il n’existe que trois états possibles pour les tâches basiques : running, lorsque la tâche est en train de s’exécuter, ready, lorsque la tâche est prête à être exécutée et suspended, lorsque la tâche est passive. Les tâches étendues quant à elles peuvent atteindre un quatrième état : waiting, lorsque la tâche attend un évènement pour pouvoir poursuivre son exécution. Notons que lorsqu’une tâche étendue est dans l’état d’attente d’un évènement elle n’empêche pas l’exécution des autres tâches. La figure 2.3 montre les différents états possibles pour chacun des types de tâches, ainsi que les transitions possibles entre ces états.
— Lorsqu’une tâche est dans l’état suspended et qu’elle est activée (activate) parce qu’elle doit être exécutée, elle passe alors dans l’état ready.
— Lorsque la tâche est dans l’état ready et que les ressources nécessaires sont libres pour l’exécuter, elle peut alors être exécutée (start) et passer dans l’état running.
— Lorsque la tâche est en cours d’exécution, elle peut soit terminer son exécution (terminate), soit être préemptée (preempt) si une interruption est activée ou bien si un tâche de priorité supérieure est prête à être exécutée, soit, s’il s’agit d’une tâche étendue attendre un évènement (wait).
— Lorsque la tâche reçoit l’évènement qu’elle attendait, elle passe alors à nouveau dans l’état ready pour poursuivre son exécution (release).
Espace d’adaptation et container
L’une des hypothèses prise pour définir ces notions est que la granularité des mises à jour est le runnable. En effet, comme expliqué dans la section 2.5.1.1, un SWC est une décomposition hiérarchique qui contient un certain nombre de runnables. Ce sont ces runnables qui réalisent effectivement une partie de nos chaînes de calcul. Les SWCs n’ont aucune existence propre en tant que tel dans l’implémentation finale.
Étant donné que nous nous plaçons au niveau implémentation final pour ajouter la mise à jour, nous partons du principe que s’il est possible d’ajouter dans un système tous les runnables d’un SWC, cela revient à ajouter un SWC. Il est à noter toutefois, que bien que l’intégration se fasse au niveau du code, le travail architectural préparatoire est nécessaire pour déterminer le contexte dans lequel la mise à jour s’intègre. Nous nous concentrons donc dans ce travail sur les mécanismes permettant d’ajouter un runnable. Notons que ces mécanismes peuvent être actionnés plusieurs fois de suite afin d’ajouter un SWC complet.
Différentes vues d’une application
Les mises à jour doivent être intégrées dans une application existante de manière la plus transparente possible. Pour cette raison, nous présentons ici les différentes vues d’une application, dans le contexte d’une modélisation AUTOSAR.
Les différentes caractéristiques qui sont présentées dans cette section sont la base de la définition de nos concepts d’espace d’adaptation et de container.
Vue haut niveau
Cette vue correspond au niveau applicatif d’une application sur un ECU. Le ta-bleau 3.1 montre les différentes caractéristiques que nous considérons pour le logiciel applicatif dans le cadre d’un ECU. Les éléments qui nous intéressent sont :
— les runnables (puisque ce sont eux qui réalisent la fonctionnalité), qui possèdent eux-mêmes un certain nombre de caractéristiques que nous détaillons ultérieure-ment,
— les tâches qui exécutent les runnables,
— les connexions internes (i.e. celles qui passent uniquement par le RTE) et
— les données d’entrées sorties (qui transitent par un bus matériel). Ces deux types de données sont différenciés car ils mettent en œuvre des mécanismes différents,
et ne sont pas traités de la même manière lors des mises à jour.
Il est important de noter que les tâches qui sont considérées dans ce cas précis sont uniquement les tâches qui hébergent le logiciel applicatif (les runnables). Il existe également dans le système d’autres tâches qui permettent aux éléments du Basic Software d’être exécutés, mais elles ne sont pas prises en compte ici. Elles doivent toutefois être prises en compte pour l’analyse d’ordonnancement.
Développement d’une application logicielle embarquée : processus standard
Lors du développement d’une application embarquée de type AUTOSAR, un proces-sus précis doit être suivi. Ce processus repose sur un certain nombre d’outils nécessaires pour créer une application embarquée de type AUTOSAR [106].
La figure 3.3 montre les différentes étapes nécessaires à la création d’une application embarquée de type AUTOSAR telle qu’elle a été définie chez Renault. Il s’agit d’une approche dite top down, c’est à dire que le point de départ sont les spécifications fonction-nelles pour arriver au final au code des calculateurs. Ce processus respecte la méthodolo-gie AUTOSAR [15], mais apporte un certain nombre de contributions supplémentaires. Tout d’abord une étape supplémentaire est rajoutée : elle consiste a faire une modéli-sation complète du point de vue de l’architecture logicielle fonctionnelle. Cette étape n’est pas forcément spécifique à une conception AUTOSAR. Il s’agit d’une architecture globale et haut niveau du logiciel. Ensuite des critères spécifiques de regroupement des runnables dans les composants logiciels sont explicités. Enfin les critères d’allocation pour les SWCs sur les ECUs et pour les runnables sur les tâches sont détaillés. Ces éléments n’apparaissent pas explicitement dans le standard AUTOSAR.
La première étape du processus de développement est d’identifier les besoins fonc-tionnels, c’est-à-dire quelles sont les spécifications qui doivent être remplies par notre système et les caractéristiques qu’il doit avoir. Lorsque les besoins ont été identifiés, le processus de développement peut débuter. Cette section décrit les différentes étapes de ce processus. Tout d’abord comment le modèle logiciel global est créé (étape 2 de la figure 3.3). Cette étape définit les éléments logiciels applicatifs dont nous disposons et qui doivent ensuite être agencés de manière à respecter l’architecture AUTOSAR (étape 3 de la figure 3.3). Enfin, pour chacun des calculateurs, des outils permettent de générer et/ou de configurer d’une part les couches basses et d’autre part le logiciel applicatif lui-même. Chacune de ces étapes est détaillée dans les sections suivantes.
En se plaçant dans un contexte avec une architecture de type AUTOSAR, nous de-vons non seulement respecter l’architecture elle-même avec sa division en couche comme détaillée dans la section 2.5, mais également la démarche de développement requise par le standard.
Architecture logicielle fonctionnelle globale
Pour répondre à un besoin fonctionnel dans le domaine de l’automobile, il est généra-lement nécessaire d’avoir des organes mécaniques, électroniques et logiciels. Le processus qui est développé ici se concentre uniquement sur la partie logicielle.
L’étape présentée dans cette section, à savoir l’architecture logicielle fonctionnelle globale ne fait pas partie des étapes décrites par la méthodologie AUTOSAR. C’est une étape qui a été rajoutée dans le développement d’application chez Renault. Nous avons, en effet, considéré qu’il est nécessaire d’avoir une vision globale des différents éléments présents dans un système et qui réalisent un ensemble de fonctionnalité. Cela permet d’avoir une meilleure cohérence dans un système. De plus, c’est une manière de regrouper de manière formelle les informations concernant une application et d’éviter ainsi les redondances. Les éléments disponibles et nécessaires de l’application sont donc clairement identifiés. Ainsi, cette première étape du processus de développement a été pensée pour améliorer le dossier de conception d’une application et pour permettre une meilleure analyse haut niveau sur le plan structurel et comportemental. Cette étape est indispensable lorsque par la suite nous souhaitons faire des mises à jour.
Lors de la conception du logiciel, la première étape consiste en une description des dif-férents cas d’utilisation correspondant à chacune des fonctions. Si nous prenons l’exemple d’une fonction A, il faut en déterminer tous les cas d’utilisation. La figure 3.4 montre un exemple de diagramme sur lequel les différents cas d’utilisation pour une fonction don-née sont décrits. Ce diagramme donne uniquement des informations basiques.En effet, il ne montre que les cas d’utilisation et les acteurs affectés par ou agissants sur ces cas d’utilisation.
Architecture logicielle AUTOSAR
Lorsque tous les runnables et leur caractéristiques propres (caractéristiques tempo-relles, flots de données, flots de contrôle), ainsi que les caractéristiques temporelles de l’application (contraintes de temps de bout-en-bout), ASIL (Automotive Safety Inte-grity Level [57]), contraintes de sécurité particulières ont été définies dans le modèle fonctionnel global, les différents éléments applicatifs peuvent être organisés de manière à correspondre au modèle architectural du standard AUTOSAR.
Une des premières étapes pour l’architecture au format AUTOSAR est de regrouper les runnables qui ont été précédemment définis au sein de composants logiciels. Les critères qui permettent de procéder à ce groupement ne sont pas clairement définis dans le standard. Ceux que nous présentons ici ont été définis par Renault dans le processus de développement. Le regroupement doit obéir à une logique permettant la meilleure réutilisation possible des composants ainsi créés. Par exemple, tous les runnables d’un même SWC doivent être placés dans la même OS-Application (groupement d’objets OS qui permet de mettre en place des mécanismes de protection) : pour cette raison il est préférable que tous les runnables d’un même SWC aient le même niveau ASIL.
L’objectif de ce modèle AUTOSAR est :
— de définir les différentes communications entre les composants applicatifs,
— de répartir les composants sur les ECU disponibles,
— de configurer les couches du Basic Software de chaque ECU pour répondre aux besoins des composants qui lui sont alloués.
Conception niveau Virtual Functionnal Bus (VFB)
La première étape du modèle AUTOSAR consiste à définir les SWCs ainsi que leur communications. Il s’agit ici d’une vue haut niveau qui ne dépend pas de l’allocation future sur les différents ECUs disponibles. Cette conception est la vue VFB (Virtual Functional Bus), c’est-à-dire les communications entre les différents SWCs d’un point de vue global. Cependant, afin de garder la meilleure indépendance possible entre les com-posants logiciels (c’est un des buts de AUTOSAR), chaque composant ignore l’identité de celui avec qui il communique. D’autre part, l’allocation des composants sur les ECUs ne doit pas avoir d’impact, du point de vue des SWCs, sur les communications : même si les mécanismes bas niveau sont différents dans le cas de communication entre ECUs, cela doit être totalement transparent pour les SWCs.
Les critères qui permettent de regrouper des runnables au sein d’un même composant sont principalement des critères de cohérence et de sécurité-innocuité. En effet, puisque 1) l’objectif est d’assurer la meilleure réutilisabilité possible des SWCs et 2) les runnables d’un même SWC doivent être placés dans une même OS-Application, alors il faut faire en sorte que les runnables d’un même SWC aient une cohérence fonctionnelle et que le niveau d’ASIL soit cohérent. Pour une meilleure réutilisabilité, il faut également éviter de réunir au sein d’un même composant des runnables directement dépendants du matériel et des runnables calculatoires. En effet, les unités qui peuvent être réutilisées d’une application à une autre sont les SWCs et non les runnables. La figure 3.8 montre ici la vue VFB pour l’exemple de la section 3.3.1. Les 6 run-nables, qui ont été répartis dans différents composants logiciels, sont bien présents ici. Les runnables 1, 5 et 6 qui sont aux extrémités de la chaine de calcul, peuvent correspondre
à des capteurs ou des actionneurs. Ils ont été placés dans des composants spécifiques. Les runnables 2, 3 et 4, quant à eux sont au milieu de la chaine et peuvent correspondre à des runnables de traitement, ils sont ici groupés ensemble au sein d’un même composant. Il s’agit ici d’une répartition possible, mais d’autres auraient également été valables. Une fois de plus il s’agit d’un choix architectural. Les liens qui apparaissent sur la figure 3.8 représentent les flots de données entre les runnables de SWCs différents.
|
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
3.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
6.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
Télécharger le rapport complet
