Brevet FR3143146A1 — publié le 20240614

L’invention concerne une unité de commande électronique (2) pour véhicule, l’unité de commande électronique (2) comprenant un processeur principal (4), des moyens mémoire (6), une boîte noire transactionnelle (8) et une pluralité de cœurs applicatifs (10), les moyens mémoire (6) stockant un chargeur d’amorçage (18) et du code applicatif (13), la boîte noire transactionnelle (8) comportant un coprocesseur de sécurité (20) et une mémoire (22), la mémoire (22) de la boîte noire transactionnelle (8) stockant un code informatique de sauvetage (24) configuré pour mettre en œuvre au moins une fonction de diagnostic de l’unité de commande électronique (2) lorsqu’il est exécuté par le processeur principal (4), et le coprocesseur de sécurité (20) étant configuré pour vérifier l’intégrité et authentifier le chargeur d’amorçage (18) au sein de la pluralité de cœurs applicatifs (10). Figure de l’abrégé : Fig. 1 UNITE DE COMMANDE ELECTRONIQUE POUR VEHICULE COMPRENANT UNE BOITE NOIRE TRANSACTIONNELLE, ET PROCEDE DE FONCTIONNEMENT D’UNE TELLE UNITE DE COMMANDE ELECTRONIQUE L’invention se rapporte à une unité de commande électronique pour véhicule, notamment automobile, comprenant un processeur principal, des moyens mémoire, une boîte noire transactionnelle et une pluralité de cœurs applicatifs. L’invention se situe dans le domaine de la sécurité électronique et informatique, et plus précisément du démarrage sécurisé d’une unité de commande électronique embarquée dans un véhicule et de l’exécution de code applicatif authentique sur une telle unité de commande électronique. L’invention se rapporte également à un procédé de fonctionnement d’une telle unité de commande électronique, ainsi qu’à un produit programme d’ordinateur pour la mise en œuvre de certaines étapes de ce procédé. L’unité de commande électronique est par exemple un microcontrôleur, sans que cela ne soit limitatif dans le cadre de la présente invention. Il est connu de l’état de la technique des unités de commande électronique pour véhicule, notamment automobile, comprenant typiquement un processeur principal, des moyens mémoire, une boîte noire transactionnelle et plusieurs cœurs applicatifs. Une telle unité de commande électronique (appelée ECU en anglais pour « Electronic Command Unit ») est par exemple un microcontrôleur. Les moyens mémoire sont reliés au processeur principal via un bus de communication de données et stockent un chargeur d’amorçage et du code applicatif destiné à être exécuté par le processeur principal (un tel code applicatif étant par exemple destiné à permettre le pilotage de briques logicielles du véhicule telles que celles appartenant notamment au contrôle moteur ou encore à la batterie de stockage électrique). Le chargeur d’amorçage (aussi appelé « Boot Loader » en anglais) correspond à une couche logicielle autre que le code applicatif et comprend plusieurs séquences de lancement. Le chargeur d’amorçage est configuré, lorsqu’exécuté par le processeur principal, pour requérir une vérification de l’intégrité et une authentification du code applicatif stocké dans les moyens mémoire et pour exécuter ce code applicatif sur les cœurs applicatifs lorsque le code applicatif a été authentifié. La boîte noire transactionnelle (aussi appelée module HSM, de l’anglais « Hardware Security Module ») comporte un coprocesseur de sécurité et une mémoire. Le coprocesseur de sécurité (aussi appelé « Trust Anchor » en anglais) est le seul élément de l’unité de commande électronique à qui cette dernière fait confiance de manière immuable. Le coprocesseur de sécurité est relié au processeur principal via le bus de communication de données et est configuré pour vérifier l’intégrité et authentifier le code applicatif stocké dans les moyens mémoire, ainsi que pour autoriser l’exécution du code applicatif sur les cœurs applicatifs. Le coprocesseur de sécurité est ainsi chargé d’assurer des fonctions de sécurisation au sein de l’unité de commande électronique, et fait plus généralement partie d’un mécanisme dit de « sécurité d’amorçage » (« Secure Boot » en anglais) qui comporte une série de niveaux, chaque niveau impliquant l’exécution d’une nouvelle partie de code informatique après vérifications nécessaires de l'intégrité du code et décryptage optionnel du contenu protégé, le coprocesseur de sécurité correspondant au premier niveau. En effet, les utilisateurs et les fabricants de véhicules demandent désormais de s'assurer que le code applicatif exécuté par une unité de commande électronique dédiée dans le véhicule soit suffisamment sûr pour être exécuté. Par « suffisamment sûr » on entend que l’unité est dans un mode sûr pour être exécutée mais également dans un état où il est garanti que personne n'a pu modifier le contenu de la mémoire interne non volatile de l’unité, dédiée au stockage du logiciel permettant d’avoir un système opérationnel en cours d'exécution. La boîte noire transactionnelle, et donc le coprocesseur de sécurité, est le premier module exécuté par le l’unité de commande électronique et est en charge d’autoriser l’exécution, par le chargeur d’amorçage, du code applicatif sur les cœurs applicatifs. Cependant, lorsqu’une des séquences de lancement du chargeur d’amorçage n’est plus digne de confiance (et donc plus authentifiable), cette dernière ne peut être exécutée par processeur principal de l’unité de commande électronique. Le code applicatif devient alors à son tour inexécutable au sein de l’unité, cette dernière devenant inopérante dans le véhicule sans que l’utilisateur final du véhicule n’en comprenne la raison. En effet, dans les systèmes actuellement utilisés l’unité de commande électronique n’offre aucun moyen à l’utilisateur pour communiquer avec elle afin de comprendre la raison pour laquelle le chargeur d’amorçage et le code applicatif ne s’exécutent plus au sein du système et/ou essayer d'effectuer une mise à jour du code applicatif au sein de l’unité. En particulier, l’utilisateur ne dispose d’aucun moyen de diagnostic pour distinguer entre un problème de mémoire matérielle (en particulier sur les moyens mémoire) ou une attaque malveillante (de type compromission intentionnelle) sur l’unité. Le but de l’invention est de pallier les inconvénients de l’art antérieur en proposant une unité de commande électronique pour véhicule, notamment automobile, qui offre la possibilité à un utilisateur ou à un fabricant du véhicule de comprendre la raison pour laquelle le chargeur d’amorçage et le code applicatif ne s’exécutent plus au sein du système, tout en permettant à l’unité de commande électronique de continuer à s’exécuter dans un mode dédié afin d’offrir un moyen de communication et de diagnostic avec l’extérieur. Pour ce faire, l’invention se rapporte ainsi, dans son acceptation la plus large, à une unité de commande électronique pour véhicule, l’unité de commande électronique comprenant un processeur principal, des moyens mémoire, une boîte noire transactionnelle et une pluralité de cœurs applicatifs, les moyens mémoire étant reliés au processeur principal via un bus de communication de données et stockant un chargeur d’amorçage et du code applicatif destiné à être exécuté par le processeur principal, sur la pluralité de cœurs applicatifs, ledit chargeur d’amorçage comprenant plusieurs séquences de lancement et étant configuré, lorsqu’exécuté par le processeur principal, pour requérir une vérification de l’intégrité et une authentification du code applicatif stocké dans les moyens mémoire et pour exécuter ledit code applicatif sur la pluralité de cœurs applicatifs lorsque ledit code applicatif a été authentifié, la boîte noire transactionnelle comportant un coprocesseur de sécurité et une mémoire, le coprocesseur de sécurité étant relié au processeur principal et aux moyens mémoire via le bus de communication de données et étant configuré pour vérifier l’intégrité et authentifier le code applicatif stocké dans les moyens mémoire et pour autoriser l’exécution dudit code applicatif sur la pluralité de cœurs applicatifs, les cœurs applicatifs étant reliés au processeur principal via le bus de communication de données, la mémoire de la boîte noire transactionnelle stockant un code informatique de sauvetage, ledit code informatique de sauvetage étant destiné à être exécuté par le processeur principal, sur la pluralité de cœurs applicatifs, et étant configuré pour mettre en œuvre au moins une fonction de diagnostic de l’unité de commande électronique lorsqu’il est exécuté par le processeur principal, et en ce que le coprocesseur de sécurité est configuré en outre pour vérifier l’intégrité et authentifier le chargeur d’amorçage au sein de la pluralité de cœurs applicatifs et, si le chargeur d’amorçage n’est pas authentifié, pour télécharger le code informatique de sauvetage depuis la mémoire de la boîte noire transactionnelle vers les moyens mémoire, pour installer ledit code informatique de sauvetage à la place d’une première séquence de lancement du chargeur d’amorçage et pour faire exécuter, par le processeur principal, ledit code informatique de sauvetage sur la pluralité de cœurs applicatifs. Grâce à la présence dans la mémoire de la boîte noire transactionnelle du code informatique de sauvetage ainsi configuré, l’unité de commande électronique pour véhicule selon l’invention offre la possibilité à un utilisateur ou à un fabricant du véhicule de comprendre la raison pour laquelle le chargeur d’amorçage et le code applicatif ne s’exécutent plus au sein du système, tout en permettant à l’unité de commande électronique de continuer à s’exécuter dans un mode dédié afin d’offrir un moyen de communication et de diagnostic avec l’extérieur. Un tel moyen de diagnostic embarqué directement dans l’unité de commande électronique permet avantageusement de réduire les coûts ainsi que le temps de diagnostic et de prise en charge d’une éventuelle panne matérielle ou d’une intrusion malveillante sur le système, ainsi que d’éviter de devoir se débarrasser de l’unité lorsque l’origine de la non-authentification du chargeur d’amorçage est inconnue. Selon une caractéristique technique particulière de l’invention, la mémoire de la boîte noire transactionnelle est une mémoire non volatile, de préférence une mémoire flash. Une telle mémoire non volatile est accessible en lecture et en écriture uniquement par le coprocesseur de sécurité, ce qui permet d’améliorer la sécurité de l’unité de commande électronique, en particulier concernant l’utilisation et l’authentification du code informatique de sauvetage. Selon une autre caractéristique technique particulière de l’invention, les moyens mémoire comportent une mémoire non volatile, de préférence une mémoire flash. Selon une autre caractéristique technique particulière de l’invention, le bus de communication de données est un bus CAN (de l’anglais « Controller Area Network ») ou un bus conforme au protocole Ethernet. Avantageusement, une image compressée du code informatique de sauvetage est stockée dans la mémoire de la boîte noire transactionnelle. Ceci permet d’optimiser la consommation de ressources mémoire au sein de la boîte noire transactionnelle. Avantageusement, le code informatique de sauvetage est stocké dans une portion applicative de la mémoire de la boîte noire transactionnelle. Ceci permet de faciliter la mise à jour du code informatique de sauvetage par un utilisateur final de l’unité de commande électronique ou par un fabricant du véhicule. Avantageusement, le coprocesseur de sécurité est configuré en outre pour vérifier l’intégrité et authentifier le code informatique de sauvetage. Ceci permet d’améliorer encore la sécurité liée à l’utilisation du code informatique de sauvetage au sein de l’unité de commande électronique. Selon une caractéristique technique particulière de l’invention, le coprocesseur de sécurité est configuré en outre pour exécuter une instruction de réinitialisation de l’unité de commande électronique. Avantageusement, le code informatique de sauvetage est configuré en outre, lorsqu’exécuté par le processeur principal, pour mettre en œuvre une fonction de téléversement du code applicatif depuis les moyens mémoire vers une mémoire d’un dispositif tiers relié à l’unité de commande électronique. Ceci permet à un utilisateur du dispositif tiers de pouvoir récupérer le code applicatif éventuellement compromis. La mémoire d’un tel dispositif tiers est par exemple un bloc de mémoire vive ou encore un dispositif de stockage non volatil de type mémoire flash. Avantageusement, le code informatique de sauvetage est configuré de manière à pouvoir vérifier l’intégrité et l’authenticité du code applicatif téléversé dans la mémoire du dispositif tiers. L’invention se rapporte également à un procédé de fonctionnement d’une unité de commande électronique pour véhicule tel que décrite ci-dessus, le procédé comportant les étapes suivantes : vérification, par le coprocesseur de sécurité, de l’intégrité du chargeur d’amorçage au sein de la pluralité de cœurs applicatifs ; si la vérification de l’intégrité du chargeur d’amorçage au sein de la pluralité de cœurs applicatifs est positive, authentification, par le coprocesseur de sécurité, du chargeur d’amorçage et : envoi, par le chargeur d’amorçage à destination du coprocesseur de sécurité, d’une requête de vérification de l’intégrité et d’authentification du code applicatif stocké dans les moyens mémoire ; vérification de l’intégrité et authentification, par le coprocesseur de sécurité, du code applicatif stocké dans les moyens mémoire ; autorisation, par le coprocesseur de sécurité, de l’exécution dudit code applicatif sur la pluralité de cœurs applicatifs ; et exécution par le processeur principal, via le chargeur d’amorçage, dudit code applicatif sur la pluralité de cœurs applicatifs ; si la vérification de l’intégrité du chargeur d’amorçage au sein de la pluralité de cœurs applicatifs est négative : téléchargement, par le coprocesseur de sécurité, du code informatique de sauvetage depuis la mémoire de la boîte noire transactionnelle vers les moyens mémoire ; installation, par le coprocesseur de sécurité, dudit code informatique de sauvetage à la place d’une première séquence de lancement du chargeur d’amorçage ; et exécution, par le processeur principal, dudit code informatique de sauvetage sur la pluralité de cœurs applicatifs. Avantageusement, si la vérification de l’intégrité du chargeur d’amorçage au sein de la pluralité de cœurs applicatifs est négative, le procédé comporte en outre une étape de vérification de l’intégrité et d’authentification, par le coprocesseur de sécurité, du code informatique de sauvetage. Ceci permet d’améliorer encore la sécurité liée à l’utilisation du code informatique de sauvetage au sein de l’unité de commande électronique. Selon une caractéristique technique particulière de l’invention, si la vérification de l’intégrité du chargeur d’amorçage au sein de la pluralité de cœurs applicatifs est négative, le procédé comporte en outre une étape d’exécution, par le coprocesseur de sécurité, d’une instruction de réinitialisation de l’unité de commande électronique. Après cette réinitialisation, l’unité de commande électronique n’est plus à même que de communiquer avec l’extérieur, afin d’offrir à un utilisateur ou à un fabricant du véhicule un moyen de communication et de diagnostic grâce à l’exécution du code informatique de sauvetage. Selon une variante de réalisation particulière de l’invention, l’étape de vérification, par le coprocesseur de sécurité, de l’intégrité du chargeur d’amorçage au sein de la pluralité de cœurs applicatifs comporte une vérification de l’intégrité de la première séquence de lancement du chargeur d’amorçage au sein de la pluralité de cœurs applicatifs, et une vérification de l’intégrité d’un module de chargeur d’amorçage flash au sein de la pluralité de cœurs applicatifs, la vérification de l’intégrité du chargeur d’amorçage au sein de la pluralité de cœurs applicatifs étant positive si et seulement si les résultats desdites deux vérifications sont positifs. L’invention se rapporte également à un produit programme d’ordinateur comprenant un ensemble d’instructions de code de programme qui, lorsqu’elles sont exécutées par un processeur, configurent le processeur pour mettre en œuvre une ou plusieurs étape(s) du procédé tel que décrit ci-dessus, ledit produit programme d’ordinateur constituant le code informatique de sauvetage, ledit processeur étant le processeur principal. On décrira ci-après, à titre d’exemples non limitatifs, des formes d’exécution de la présente invention, en référence aux figures annexées sur lesquelles : - est une représentation schématique d’une unité de commande électronique pour véhicule selon la présente invention ; et - est un logigramme illustrant le procédé de fonctionnement de l’unité de commande électronique de la . En référence à la est illustrée une unité de commande électronique 2 selon un mode de réalisation de l’invention. L’unité de commande électronique 2 est installée au sein d’un véhicule, notamment un véhicule automobile (un tel véhicule n’étant pas représenté sur les figures pour des raisons de clarté), et est par exemple destiné à piloter certains éléments physiques du véhicule tels que notamment le contrôle moteur ou encore une batterie de stockage électrique. L’unité de commande électronique 2 est par exemple un microcontrôleur implanté sur une puce unique, sans que cela ne soit limitatif dans le cadre de la présente invention. L’unité de commande électronique 2 comporte un processeur principal 4, des moyens mémoire 6, une boîte noire transactionnelle 8 et plusieurs cœurs applicatifs 10. Le système informatique 2 comporte également un bus de communication de données 12 reliant ces différents éléments. Les moyens mémoire 6 sont reliés au processeur principal 4 via le bus de communication de données 12, et stockent du code applicatif 13 destiné à être exécuté par le processeur principal 4, sur les cœurs applicatifs 10, afin de permettre notamment le pilotage de certaines briques logicielles appartenant aux différents éléments physiques du véhicule susmentionnés. Les moyens mémoire 6 stockent également un chargeur d’amorçage 18, par exemple sur une zone ou partition différente de celle utilisée pour le stockage du code applicatif 13. Les moyens mémoire 6 comportent typiquement une mémoire non volatile, de préférence une mémoire flash, dans laquelle sont stockés (sous des partitions et/ou dans des couches différentes) le code applicatif 13 et le chargeur d’amorçage 18. Le chargeur d’amorçage 18 se présente sous la forme d’un code de programme, autrement dit d’une suite d’instructions informatiques destinées à être exécutées par le processeur principal 4. Plus précisément, le chargeur d’amorçage 18 correspond à une couche logicielle autre que le code applicatif 13, comprend plusieurs séquences de lancement et est configuré, lorsqu’il est exécuté par le processeur principal 4, pour requérir une vérification de l’intégrité et une authentification du code applicatif 13, et pour exécuter le code applicatif 13 sur les cœurs applicatifs 10 lorsque le code applicatif 13 a été authentifié. La boîte noire transactionnelle 8 comporte un coprocesseur de sécurité 20 et une mémoire 22 qui stocke un code informatique de sauvetage 24. Le coprocesseur de sécurité 20 est relié au processeur principal 4 et aux moyens mémoire 6 via le bus de communication de données 12. Le coprocesseur de sécurité 20 est configuré pour vérifier l’intégrité et authentifier le code applicatif 13 stocké dans les moyens mémoire 6, et pour autoriser l’exécution du code applicatif 13 sur les cœurs applicatifs 10. Comme cela sera détaillé par la suite, le coprocesseur de sécurité 20 est configuré en outre pour vérifier l’intégrité et authentifier le chargeur d’amorçage 18 au sein des cœurs applicatifs 10 et, si le chargeur d’amorçage 18 n’est pas authentifié, pour télécharger le code informatique de sauvetage 24 depuis la mémoire 22 de la boîte noire transactionnelle 8 vers les moyens mémoire 6, pour installer le code informatique de sauvetage 24 à la place d’une première séquence de lancement du chargeur d’amorçage 18 et pour faire exécuter, par le processeur principal 4, le code informatique de sauvetage 24 sur les cœurs applicatifs 10. De préférence, le coprocesseur de sécurité 20 est configuré également pour vérifier l’intégrité et authentifier le code informatique de sauvetage 24. De préférence encore, le coprocesseur de sécurité 20 est configuré également pour exécuter une instruction de réinitialisation de l’unité de commande électronique 2. La mémoire 22 de la boîte noire transactionnelle 8 est typiquement une mémoire non volatile, de préférence une mémoire flash. Le code informatique de sauvetage 24 est destiné à être exécuté par le processeur principal 4, sur les cœurs applicatifs 10, et est configuré pour mettre en œuvre au moins une fonction de diagnostic de l’unité de commande électronique 2 lorsqu’il est exécuté par le processeur principal 4. De préférence, outre la fonction de diagnostic de l’unité de commande électronique 2, le code informatique de sauvetage 24 est configuré en outre, lorsqu’exécuté par le processeur principal 4, pour mettre en œuvre une fonction de téléversement du code applicatif 13 depuis les moyens mémoire 6 vers une mémoire d’un dispositif tiers relié au système informatique 2 (un tel dispositif tiers n’étant pas représenté sur la pour des raisons de clarté). De préférence encore, une image compressée du code informatique de sauvetage 24 est stockée dans la mémoire 22 de la boîte noire transactionnelle 8. De préférence encore, le code informatique de sauvetage 24 est stocké dans une portion applicative de la mémoire 22 de la boîte noire transactionnelle 8. Le bus de communication de données 12 est typiquement un bus CAN (de l’anglais « Controller Area Network ») ou un bus conforme au protocole Ethernet, sans que cela ne soit limitatif dans le cadre de la présente invention. Le procédé de fonctionnement de l’unité de commande électronique 2 selon un mode de réalisation de l’invention va maintenant être décrit en référence à la . Le procédé comporte une étape initiale 30 au cours de laquelle la boîte noire transactionnelle 8 est initialisée par le processeur principal 4. Le procédé comporte une étape suivante 32 au cours de laquelle le coprocesseur de sécurité 20 vérifie l’intégrité du chargeur d’amorçage 18 au sein des cœurs applicatifs 10. De préférence, la vérification 32 de l’intégrité du chargeur d’amorçage 18 au sein des cœurs applicatifs 10 comporte une vérification de l’intégrité d’une première séquence de lancement du chargeur d’amorçage 18 au sein des cœurs applicatifs 10, et une vérification de l’intégrité d’un module de chargeur d’amorçage flash au sein des cœurs applicatifs 10. Si la vérification 32 de l’intégrité du chargeur d’amorçage 18 au sein des cœurs applicatifs 10 est positive (autrement dit si et seulement si les résultats des deux vérifications susmentionnées sont positifs), le coprocesseur de sécurité 20 authentifie le chargeur d’amorçage 18 et le procédé passe à une étape suivante 34. Sinon (autrement dit si au moins une des deux vérifications susmentionnées est négative), le coprocesseur de sécurité 20 n’authentifie pas le chargeur d’amorçage 18 et le procédé passe à une étape suivante 36. Au cours de l’étape 34, le processeur principal 4 initialise le chargeur d’amorçage 18. Le procédé comporte alors une étape suivante 38 au cours de laquelle le chargeur d’amorçage 18 envoie au coprocesseur de sécurité 20 une requête de vérification de l’intégrité et d’authentification du code applicatif 13 stocké dans les moyens mémoire 6. Au cours d’une étape 40 suivant l’étape 38, le coprocesseur de sécurité 20 vérifie l’intégrité du code applicatif 13 stocké dans les moyens mémoire 6. Dans l’exemple de réalisation particulier de la , le code applicatif 13 se divise en un code applicatif haut niveau et un code applicatif de reprogrammation du code applicatif haut niveau. Selon cet exemple de réalisation particulier, l’étape 40 débute donc par une phase 41 de vérification de l’intégrité du code applicatif haut niveau stocké dans les moyens mémoire 6. Si la phase 41 de vérification de l’intégrité du code applicatif haut niveau est positive, le coprocesseur de sécurité 20 authentifie le code applicatif haut niveau et autorise l’exécution du code applicatif haut niveau sur les cœurs applicatifs 10, et le procédé passe à une étape suivante 42. Sinon, le coprocesseur de sécurité 20 n’authentifie pas le code applicatif haut niveau et le procédé passe à une phase suivante 44. Au cours de l’étape 42 le processeur principal 4 exécute, via le chargeur d’amorçage 18, le code applicatif haut niveau sur les cœurs applicatifs 10. Au cours de la phase 44, le chargeur d’amorçage 18 envoie au coprocesseur de sécurité 20 une requête de vérification de l’intégrité et d’authentification du code applicatif de reprogrammation stocké dans les moyens mémoire 6. Au cours d’une phase 46 suivant la phase 44, le coprocesseur de sécurité 20 vérifie l’intégrité du code applicatif de reprogrammation stocké dans les moyens mémoire 6. Si la vérification 46 de l’intégrité du code applicatif de reprogrammation est positive, le coprocesseur de sécurité 20 authentifie le code applicatif de reprogrammation et autorise l’exécution du code applicatif de reprogrammation sur les cœurs applicatifs 10, et le procédé passe à une étape suivante 48. Sinon, le coprocesseur de sécurité 20 n’authentifie pas le code applicatif de reprogrammation et n’autorise pas l’exécution du code applicatif de reprogrammation sur les cœurs applicatifs 10. Au cours de l’étape 48, le processeur principal 4 exécute, via le chargeur d’amorçage 18, le code applicatif de reprogrammation sur les cœurs applicatifs 10. Au cours de l’étape 36, le coprocesseur de sécurité 20 télécharge le code informatique de sauvetage 24 depuis la mémoire 22 de la boîte noire transactionnelle 8 vers les moyens mémoire 6. De préférence, au cours d’une étape 50 suivant l’étape 36, le coprocesseur de sécurité 20 vérifie l’intégrité du code informatique de sauvetage 24, et authentifie le cas échéant le code informatique de sauvetage 24. Au cours d’une étape 52 suivant l’étape 50, le coprocesseur de sécurité 20 installe le code informatique de sauvetage 24 à la place d’une première séquence de lancement du chargeur d’amorçage 18. De préférence, au cours d’une étape 54 suivant l’étape 52, le coprocesseur de sécurité 20 exécute une instruction de réinitialisation de l’unité de commande électronique 2. Au cours d’une étape 56 suivant l’étape 54, le processeur principal 4 redémarre sous une session d’authenticité et exécute le code informatique de sauvetage 24 sur les cœurs applicatifs 10. L’exécution du code informatique de sauvetage 24 sur les cœurs applicatifs 10 permet alors de mettre en œuvre au moins une fonction de diagnostic, afin de pouvoir communiquer avec l’extérieur de l’unité de commande électronique 2 et de permettre à un utilisateur de l’unité 2 ou à un fabricant du véhicule de comprendre la raison pour laquelle le chargeur d’amorçage 18 et le code applicatif 13 ne s’exécutent plus au sein du système et/ou essayer d'effectuer une mise à jour du code applicatif 13 au sein de l’unité 2. Selon un mode de réalisation particulier de l’invention, l’exécution du code informatique de sauvetage 24 sur les cœurs applicatifs 10 peut également permettre de téléverser le code applicatif 13 depuis les moyens mémoire 6 vers une mémoire d’un dispositif tiers relié à l’unité de commande électronique 2 (un tel dispositif tiers n’étant pas représenté sur les figures pour des raisons de clarté). Selon ce mode de réalisation particulier, le dispositif tiers est par exemple un bloc de mémoire vive ou encore un dispositif de stockage non volatil de type mémoire flash. Le code informatique de sauvetage 24 peut par exemple être configuré pour pouvoir vérifier l’intégrité et authentifier le code applicatif 13 téléversé dans la mémoire du dispositif tiers. L’unité de commande électronique 2 pour véhicule selon l’invention offre la possibilité à un utilisateur ou à un fabricant du véhicule de comprendre la raison pour laquelle le chargeur d’amorçage et le code applicatif ne s’exécutent plus au sein du système, tout en permettant à l’unité de commande électronique de continuer à s’exécuter dans un mode dédié afin d’offrir un moyen de communication et de diagnostic avec l’extérieur. Unité de commande électronique (2) pour véhicule, l’unité de commande électronique (2) comprenant un processeur principal (4), des moyens mémoire (6), une boîte noire transactionnelle (8) et une pluralité de cœurs applicatifs (10), les moyens mémoire (6) étant reliés au processeur principal (4) via un bus de communication de données (12) et stockant un chargeur d’amorçage (18) et du code applicatif (13) destiné à être exécuté par le processeur principal (4), sur la pluralité de cœurs applicatifs (10), ledit chargeur d’amorçage (18) comprenant plusieurs séquences de lancement et étant configuré, lorsqu’exécuté par le processeur principal (4), pour requérir une vérification de l’intégrité et une authentification du code applicatif (13) stocké dans les moyens mémoire (6) et pour exécuter ledit code applicatif (13) sur la pluralité de cœurs applicatifs (10) lorsque ledit code applicatif (13) a été authentifié, la boîte noire transactionnelle (8) comportant un coprocesseur de sécurité (20) et une mémoire (22), le coprocesseur de sécurité (20) étant relié au processeur principal (4) et aux moyens mémoire (6) via le bus de communication de données (12) et étant configuré pour vérifier l’intégrité et authentifier le code applicatif (13) stocké dans les moyens mémoire (6) et pour autoriser l’exécution dudit code applicatif (13) sur la pluralité de cœurs applicatifs (10), les cœurs applicatifs (10) étant reliés au processeur principal (4) via le bus de communication de données (12), caractérisé en ce que la mémoire (22) de la boîte noire transactionnelle (8) stocke un code informatique de sauvetage (24), ledit code informatique de sauvetage (24) étant destiné à être exécuté par le processeur principal (4), sur la pluralité de cœurs applicatifs (10), et étant configuré pour mettre en œuvre au moins une fonction de diagnostic de l’unité de commande électronique (2) lorsqu’il est exécuté par le processeur principal (4), et en ce que le coprocesseur de sécurité (20) est configuré en outre pour vérifier l’intégrité et authentifier le chargeur d’amorçage (18) au sein de la pluralité de cœurs applicatifs (10) et, si le chargeur d’amorçage (18) n’est pas authentifié, pour télécharger le code informatique de sauvetage (24) depuis la mémoire (22) de la boîte noire transactionnelle (8) vers les moyens mémoire (6), pour installer ledit code informatique de sauvetage (24) à la place d’une première séquence de lancement du chargeur d’amorçage (18) et pour faire exécuter, par le processeur principal (4), ledit code informatique de sauvetage (24) sur la pluralité de cœurs applicatifs (10). Unité de commande électronique (2) selon la revendication 1, caractérisé en ce que la mémoire (22) de la boîte noire transactionnelle (8) est une mémoire non volatile, de préférence une mémoire flash. Unité de commande électronique (2) selon la revendication 1 ou 2, caractérisé en ce qu’une image compressée du code informatique de sauvetage (24) est stockée dans la mémoire (22) de la boîte noire transactionnelle (8). Unité de commande électronique (2) selon l’une quelconque des revendications 1 à 3, caractérisé en ce que le code informatique de sauvetage (24) est stocké dans une portion applicative de la mémoire (22) de la boîte noire transactionnelle (8). Unité de commande électronique (2) selon l’une quelconque des revendications 1 à 4, caractérisé en ce que le coprocesseur de sécurité (20) est configuré en outre pour vérifier l’intégrité et authentifier le code informatique de sauvetage (24). Unité de commande électronique (2) selon l’une quelconque des revendications 1 à 5, caractérisé en ce que le coprocesseur de sécurité (20) est configuré en outre pour exécuter une instruction de réinitialisation de l’unité de commande électronique (2). Unité de commande électronique (2) selon l’une quelconque des revendications 1 à 6, caractérisé en ce que le code informatique de sauvetage (24) est configuré en outre, lorsqu’exécuté par le processeur principal (4), pour mettre en œuvre une fonction de téléversement du code applicatif (13) depuis les moyens mémoire (6) vers une mémoire d’un dispositif tiers relié à l’unité de commande électronique (2). Procédé de fonctionnement d’une unité de commande électronique (2) pour véhicule selon l’une quelconque des revendications 1 à 7, caractérisé en ce que le procédé comporte les étapes suivantes : vérification (32), par le coprocesseur de sécurité (20), de l’intégrité du chargeur d’amorçage (18) au sein de la pluralité de cœurs applicatifs (10) ; si la vérification (32) de l’intégrité du chargeur d’amorçage (18) au sein de la pluralité de cœurs applicatifs (10) est positive, authentification, par le coprocesseur de sécurité, du chargeur d’amorçage et : envoi (38), par le chargeur d’amorçage (18) à destination du coprocesseur de sécurité (20), d’une requête de vérification de l’intégrité et d’authentification du code applicatif (13) stocké dans les moyens mémoire (6) ; vérification de l’intégrité (40, 41, 44, 46) et authentification, par le coprocesseur de sécurité (20), du code applicatif (13) stocké dans les moyens mémoire (6) ; autorisation, par le coprocesseur de sécurité (20), de l’exécution dudit code applicatif (13) sur la pluralité de cœurs applicatifs (10) ; et exécution (42, 48) par le processeur principal (4), via le chargeur d’amorçage (18), dudit code applicatif (13) sur la pluralité de cœurs applicatifs (10) ; si la vérification (32) de l’intégrité du chargeur d’amorçage (18) au sein de la pluralité de cœurs applicatifs (10) est négative : téléchargement (36), par le coprocesseur de sécurité (20), du code informatique de sauvetage (24) depuis la mémoire (22) de la boîte noire transactionnelle (8) vers les moyens mémoire (6) ; installation (52), par le coprocesseur de sécurité (20), dudit code informatique de sauvetage (24) à la place d’une première séquence de lancement du chargeur d’amorçage (18) ; et exécution (56), par le processeur principal (4), dudit code informatique de sauvetage (24) sur la pluralité de cœurs applicatifs (10). Procédé selon la revendication 8, caractérisé en ce que, si la vérification (32) de l’intégrité du chargeur d’amorçage (18) au sein de la pluralité de cœurs applicatifs (10) est négative, le procédé comporte en outre une étape (50) de vérification de l’intégrité et d’authentification, par le coprocesseur de sécurité (20), du code informatique de sauvetage (24). Procédé selon la revendication 8 ou 9, caractérisé en ce que, si la vérification (32) de l’intégrité du chargeur d’amorçage (18) au sein de la pluralité de cœurs applicatifs (10) est négative, le procédé comporte en outre une étape (54) d’exécution, par le coprocesseur de sécurité (20), d’une instruction de réinitialisation de l’unité de commande électronique (2). Procédé selon l’une quelconque des revendications 8 à 10, caractérisé en ce que l’étape de vérification (32), par le coprocesseur de sécurité (20), de l’intégrité du chargeur d’amorçage (18) au sein de la pluralité de cœurs applicatifs (10) comporte une vérification de l’intégrité de la première séquence de lancement du chargeur d’amorçage (18) au sein de la pluralité de cœurs applicatifs (10), et une vérification de l’intégrité d’un module de chargeur d’amorçage flash au sein de la pluralité de cœurs applicatifs (10), la vérification (32) de l’intégrité du chargeur d’amorçage (18) au sein de la pluralité de cœurs applicatifs (10) étant positive si et seulement si les résultats desdites deux vérifications sont positifs. Produit programme d’ordinateur (24) caractérisé en ce qu’il comporte un ensemble d’instructions de code de programme qui, lorsqu’elles sont exécutées par un processeur (4), configurent le processeur pour mettre en œuvre une ou plusieurs étape(s) du procédé selon l’une quelconque des revendications 8 à 11, ledit produit programme d’ordinateur constituant le code informatique de sauvetage (24), ledit processeur étant le processeur principal (4).