5.5 Sûreté de fonctionnement
5.5.3 Mécanismes de sécurité-innocuité
5.5.3.2 Sûreté de fonctionnement et création de mise à jour
Lorsque la mise à jour est créée, il est nécessaire d’ajouter un certain nombre de mécanismes de sûreté de fonctionnement en lien avec l’analyse de safety qui doit être faite. Après la création de la mise à jour, cette dernière doit être transférée dans le calculateur embarqué, et à ce moment là, un certain nombre de mécanismes de sécurité
doivent également être mis en place pour s’assurer, non seulement que la mise à jour est intègre, mais également que l’entité qui a émis cette mise à jour est fiable et que son exécution ne va pas avoir de conséquences néfastes.
Pendant la création de la mise à jour (offline) Lorsque la mise à jour est créée,
il est nécessaire de suivre le processus de développement standard, et de passer par toutes les étapes de modélisation. De cette manière, à chaque étape, le développement doit suivre les règles liées à la sécurité-innocuité, et en particulier s’assurer d’être en conformité avec le standard ISO 26262.
Ainsi, au cours du développement, les analyses de safety doivent avoir lieu, ainsi que les tests unitaires qui doivent permettre de vérifier que la mise à jour est fiable et que le comportement global du système qui intègre la mise à jour correspond bien à ce qui est attendu.
Pour le transfert de la mise à jour dans le calculateur Il est nécessaire de mettre
en place un système de signatures électroniques afin de s’assurer que la mise à jour qui a été envoyée au calculateur est non seulement intègre, mais également qu’il est possible d’avoir confiance dans l’émetteur de cette mise à jour (authentification).
Ce type de système doit permettre d’identifier de manière certaine l’identité de celui qui a signé et envoyé la mise à jour et qu’il ne soit pas possible de falsifier, de réutiliser la signature. Ainsi, lorsque la mise à jour est envoyée (par exemple depuis un serveur sécurisé du constructeur automobile), il est possible pour le calculateur de vérifier si cette mise à jour est conforme et si elle a bien été envoyée par le constructeur et non par une source frauduleuse. L’identification peut reposer sur un système de mécanisme à clefs publiques. Dans ce cas, la mise à jour est signée grâce a un système de chiffrement asymétrique : le constructeur possède une clef privée avec laquelle il signe les mises à jour, et dans chaque véhicule est embarqué la clef publique avec laquelle il est possible de vérifier l’authenticité de la mise à jour.
Ce système permet également de vérifier qu’il n’y a pas eu de problème pendant le transfert et que la mise à jour n’a pas été corrompue (par exemple par un bit qui aurait été mal transmis).
La sûreté de fonctionnement passe donc ici par une vérification de l’intégrité de ce qui est intégré dans le système initial.
Pendant l’installation de la mise à jour Une modification importante qui doit être
faite, pour l’installation et surtout pour la bonne exécution ultérieure de la mise à jour, porte sur la table d’indirection qui contient tous les pointeurs de fonctions ainsi que la description de chacun d’entre eux. Nous avons décrit précédemment cette table, ainsi que les descripteurs associés.
Il est important que cette table soit protégée de toute modification frauduleuse ou accidentelle. Pour cette raison, en utilisant des mécanismes disponibles dans les calcula- teurs embarqués (tels que la MMU, “Memory Management Unit”, qui permet de gérer les permissions de lecture et d’écriture dans la mémoire), il est nécessaire de protéger cette
table en ne la modifiant que dans un mode privilégié. Cela signifie que le segment de la mémoire qui contient la table d’indirection peut uniquement être lu en temps normal, et n’est modifié que lorsqu’une mise à jour est faite, qui se déroule en mode privilégiée. Il est également nécessaire lorsque cela se produit de dupliquer ces modifications en mémoire FLASH pour en assurer la persistance.
5.5.3.3 Conclusion
La figure 5.12 montre les différentes étapes de création et de chargement dans le cal- culateur d’une mise à jour. Ces étapes ont, pour la majorité, été décrites précédemment dans notre chapitre. Notre objectif ici est de pointer les différents mécanismes de sûreté de fonctionnement qui peuvent permettre d’assurer un niveau de confiance acceptable lors des mises à jour. Ces mécanismes peuvent permettre de répondre à des besoins de l’ISO 26262 allant jusqu’à l’ASIL D.
OFF-LINE
Développement mise à jour uj Application Vn Application Vn+1 Analyse Safety Base de données des mises à jour uk u1 u0 . . . Init {run1(V1), run2(V1), run3(V1), run4(V1), run5(V1), com 1->2, com 2->3, com 3->4, com 3->5} MaJ_A run2(VA), runA(V1), com A->2} MaJ_Brun2(VB), runB(V1), com B->2} MaJ_B_A run2(VAB), runA(V1), com A->2} MaJ_A_B run2(VAB), runB(V1), com B->2}
MaJ_C run3(VC), runC(V1), com 3->C}
MaJ_D run4(VD), runD(V1), com D->4}
MaJ_D_G run1(VG), runG(V1), com 1->G} MaJ_C_D run4(VD), runD(V1), com D->4}
ON-LINE
Protocole de communication LoaderECU
RAM indirection table buffer ui FLASH Programme vn | ui Méta-données Pile de versions mémoire1
2
3
4
5
Figure 5.12 – Etapes de création et de chargement d’une mise à jour
Dans cette section, le modèle de faute que nous adressons correspond aux fautes transitoires accidentelles. En effet, bien qu’il puisse exister également des fautes malicieuses ou des attaques sur ce type de système, ces questions ne sont pas traitées dans le cadre de ce travail.
La première étape (étape 1 de la figure 5.12 consiste donc à créer la mise à jour selon le processus qui a été décrit section 5.2.2. Cette étape a lieu hors-ligne, c’est-à- dire en dehors du calculateur et indépendamment de son exécution. Le processus de développement des mises à jour doit se faire dans le contexte de l’application embarquée dans le calculateur et en respectant les règles, telles que celles recommandées par l’ISO 26262. Des tests unitaires, ainsi que des tests d’intégration des mises à jour doivent également être mis en place afin de s’assurer du bon fonctionnement de chaque mise à jour.
Une fois que la mise à jour est créée, elle doit être placée dans la base de donnée des mises à jour (étape 2 de la figure 5.12). Dans cette base de données, nous avons donc les éléments correspondant à chaque mise à jour élémentaire, ainsi que l’arbre de mise à jour qui permet de déterminer si chacune d’elle peut être (ou non) ajoutée à un système donné.
Lorsqu’une mise à jour est demandée par un utilisateur, il faut donc faire une requête sur la base de données, en fonction de la version déjà embarquée dans le calculateur, puis utiliser un protocole de communication pour envoyer la mise à jour au véhicule. Ce protocole doit bien sûr être sécurisé afin de permettre une identification, d’une part du véhicule demandant la mise à jour, et d’autre part du serveur qui va lui envoyer. Du côté utilisateur, l’identification peut être faite par une carte à puce, alors que du côté du serveur il est possible d’utiliser un mécanisme de signature cryptographique (KPi) (étape 3 de la figure 5.12).
Lors de l’étape 4, c’est-à-dire du chargement dans la mémoire du calculateur, il est nécessaire de faire des vérifications d’intégrité, par exemple en utilisant des codes de type CRC.
Il est ensuite nécessaire de modifier la table d’indirection, non seulement en mémoire RAM, mais également en mémoire FLASH. Cette modification est très importante et aucune erreur ne peut arriver lors de cette étape car cela aurait pour conséquence po- tentielle une défaillance catastrophique du système. Il est donc nécessaire de mettre en place une redondance des données, sous forme par exemple de signature électroniques ou de codes “détecteur-correcteur” d’erreurs.
La pile de version doit également être mise à jour de manière fiable, ainsi que les méta-données associées à cette mise à jour. Enfin, lors de l’exécution, la prévention de fautes transitoires peut être faite en utilisant de la redondance temporelle. Il s’agit alors d’exécuter plusieurs fois un même programme afin de vérifier que le résultat est le même. Si le résultat est identique, alors ce dernier est considéré comme acceptable. Dans le cas contraire, il ne peut pas être considéré comme fiable.
6
Application au cas des clignotants
Sommaire 6.1 Introduction . . . 106 6.2 Outils et matériel . . . 106 6.2.1 Cible matérielle . . . 106 6.2.2 Trampoline . . . 107 6.2.3 Otawa . . . 107
6.3 Application initiale et processus de développement . . . 108
6.3.1 Règlementation liée aux clignotants . . . 108
6.3.2 Besoins fonctionnels et évènements indésirables . . . 109
6.3.3 Modèle fonctionnel logiciel global . . . 109
6.3.4 Modèle AUTOSAR . . . 114
6.3.5 Allocation des runnables sur les tâches et modèle de tâche associé115
6.3.6 Modélisation temps-réel . . . 115
6.4 Étapes de préparation de l’application . . . 118
6.4.1 Ajout de méta-données . . . 118
6.4.2 Ajout de mécanismes pour la gestion des mises à jour . . . 119
6.4.3 Ajout d’un niveau d’indirection et de containers . . . 119
6.5 Mise à jour de l’application . . . 121
6.5.1 Description des mises à jour . . . 121
6.5.2 Modèle AUTOSAR pour les mises à jour . . . 126
6.5.3 Temps-réel . . . 127
6.5.4 Gestion de version . . . 130
6.1
Introduction
Ce chapitre présente la mise en pratique des différents concepts que nous avons développés jusqu’à présent sur une application réelle. Cette dernière gère les clignotants et les warnings, sur un seul ECU (pas de reconfiguration réseau). Elle est composée de 8 runnables (deux capteurs, runnables de traitement et deux actionneurs). Deux mises à jour sont considérées pour cette application : l’allumage des warnings en cas de freinage d’urgence et les clignotants impulsionnels (en cas d’appui bref sur le capteur le clignotant correspondant s’actionne 3 fois).
Une des raisons du choix de cette application est que nous avons accès à tous les éléments de l’application, ce qui facilite les manipulations. Nous avons accès directement au code source de l’application, ce qui est utile pour certains tests. En effet, pour des raisons de propriété intellectuelle, dans le cas où la création de l’ECU est déléguée à un équipementier, il est habituel que seul le code objet des composants soit disponible.
Cependant, il est important de noter que l’accès complet au code source des SWCs n’est pas nécessaire pour être en mesure de faire des mises à jour selon la méthode que nous avons présentée dans cette thèse, mais a permis d’en faciliter l’évaluation.
Nous présentons ici dans un premier temps l’application initiale que nous utilisons comme preuve de concept avec les différentes étapes de configuration. Puis nous pré- sentons la préparation de l’application d’un point de vue temps-réel et structurel, et en particulier la préparation de l’application avec les containers afin de permettre une plus grande flexibilité.
Enfin, nous présentons les différentes mises à jour possibles pour cette application ainsi que les mécanismes qui permettent de gérer ces mises à jour.