FR 3038749 A1 20170113 FR 1556384 A 20150706 - 1 - PROCEDE DE COMMANDE D'UNE UNITE DE CALCUL ELECTRONIQUE D'UN VEHICULE AUTOMOBILE, UNITE DE CALCUL ELECTRONIQUE ET VEHICULE AUTOMOBILE CORRESPONDANTS DOMAINE TECHNIQUE DE L'INVENTION. La présente invention concerne un procédé de commande d'une unité de calcul électronique d'un véhicule automobile. L'invention concerne également une unité de calcul électronique apte à la mise en oeuvre de ce procédé, ainsi que le véhicule automobile comprenant cette 10 unité de calcul électronique. ARRIERE PLAN TECHNOLOGIQUE DE L'INVENTION. De nos jours, des systèmes d'exploitations (ou OS, acronyme en terminologie anglaise de "Operating System") embarqués sont couramment utilisés dans les 15 unités de calcul électroniques (ECU ou "Electronique Computing Unit" en terminologie anglaise) de véhicules automobiles. En général, il revient à un système d'exploitation l'enchaînement des tâches, le traitement des interruptions, et la gestion des ressources. Les enjeux classiques des systèmes d'exploitations embarqués sont la 20 capacité de réponse temporelle (c'est-à-dire un déterminisme temps réel) et l'extensibilité (c'est-à-dire la portabilité de microprocesseurs de bas de gamme à des microprocesseurs de haut de gamme). En ce qui concerne le logiciel dans l'automobile, le standard ISO 26262 établit un cadre formel pour la sécurité fonctionnelle des modules. La norme ISO 25 26262 stipule que la sûreté et la sécurité du logiciel doivent être prises en compte de manière systématique pendant tout le cycle de développement du logiciel. Un niveau d'exigence en termes de sécurité, ou ASIL défini par la norme (acronyme de "Automotive Safety Integrity Level" en terminologie anglaise), est attribué sur la base du risque de l'occurrence d'un évènement dangereux en 30 prenant en compte la périodicité de la situation, l'impact d'un dommage éventuel, et dans quelle mesure cette situation peut être contrôlée et gérée. Avec l'arrivée de la norme ISO 26262, les systèmes d'exploitation embarqués sont soumis à un nouvel ensemble d'exigences pour satisfaire aux contraintes de sécurité. Par conséquent, les implémentations classiques pour l'automobile ont été 3038749 - 2 - remaniées et de nouvelles solutions de systèmes d'exploitation de sécurité ont été mises sur le marché avec des coûts importants. La norme ISO 26262 définit quatre ASIL indiqués par des lettres de A à D, cette dernière correspondant au risque le plus faible et au niveau d'exigence en 5 termes de sécurité le plus élevé. Un niveau d'exigence en termes de sécurité indiqué par QM ("Qualité Management" c'est-à-dire "Gestion de la Qualité") est assigné aux fonctions non- critiques. Un système d'exploitation qui satisfait aux exigences de la norme ISO 26262 est appelé "Safety OS". Comparé à un "QM OS" (c'est-à-dire un OS avec une 10 gestion de qualité classique), un "Safety OS" fournit des fonctions de protection pour des protections spatiales et temporelles. D'une part, les protections temporelles ont pour but de contrôler le taux de lancement, le temps d'exécution et le verrouillage/ déverrouillage des ressources partagées par un programme. 15 D'autre part, les protections spatiales ont pour but de contrôler les droits d'accès à la mémoire RAM (acronyme de "Random Acces Memory" en terminologie anglaise, c'est-à-dire "mémoire à accès aléatoire"), la mémoire de type "Flash", et les périphériques. Une protection mémoire est une caractéristique d'un OS qui supporte 20 l'implémentation de protections spatiales, le plus souvent sur une unité de protection mémoire, ou MPU (acronyme en terminologie anglaise de "Memory Protection Unit"), du microprocesseur. Quand elle est activée, la MPU supervise les bus d'instructions et de données de l'unité centrale de traitement, ou CPU (acronyme en terminologie 25 anglaise de "Central Processing Unit"), du microprocesseur, et les accès à la mémoire RAM, Flash et aux périphériques sont contrôlés. L'accès est accordé quand les droits d'accès (en lecture, en écriture, ou d'exécution) sont valides. Cependant, quand les droits d'accès sont restreints, toute violation d'accès déclenche une erreur de la MPU, arrête la CPU et l'exécution du programme. 30 Il revient à l'implémentation du Safety OS d'offrir les services appropriés pour initialiser et remettre à zéro les registres de la MPU. Dans l'état de la technique, il est connu qu'une protection mémoire mettant en oeuvre une MPU permet une détection et une prise en compte d'une erreur plus rapides; l'impact sur la charge de la CPU est réduit puisque la plus grande partie du 35 traitement est faite par le matériel. 3038749 - 3 - En réponse aux défis de tout ordre posés par le développement de systèmes d'exploitation embarqués, les constructeurs et les équipementiers de l'automobile ont pour la plupart adopté une architecture logicielle standard: AUTOSAR. Les développements d'AUTOSAR (acronyme en terminologie anglaise de 5 "AUTomotive Open System ARchitecture", c'est-à-dire "Architecture de Système Ouvert d'Automobile") visent à remplir toutes les exigences de la norme ISO 26262 à partir des modules de base de l'OS ("AUTOSAR basic software" ou "AUTOSAR BSW") accessible librement, mais développés seulement au niveau d'exigence QM. Il s'en suit que la mise en oeuvre d'une MPU a été le plus souvent associée à 10 la nécessité d'acheter un système d'exploitation de type "Safety OS", tel que "AUTOSAR Safety", avec un impact des coûts important sur le budget des projets. De plus, la vérification de la conformité à la norme ISO 26262 des différentes couches de l'OS est souvent rendue difficile par la disparité des contributeurs et l'absence des codes sources. 15 Pour pallier cet inconvénient, il a été proposé des techniques de tests des OS du commerce, et de leur conformité à la norme ISO 26262, même si les exécutables seulement sont disponibles. Une telle technique est décrite notamment dans l'article "Binary-Level Fault Injection for AUTOSAR Systems", Mafijul Md. Islam et al., 2014 Tenth European 20 Dependable Computing Conference, p.138- 141, 2014, IEEE. La technique est évaluée sur une unité électronique de calcul comprenant un microprocesseur de la société Freescale de la série MPC5567 fonctionnant sous AUTOSAR. Le microprocesseur MPC5567 comporte une unité de gestion de la mémoire 25 ("Memory Management Unit", ou MMU, en terminologie anglaise, qui est une MPU avec une fonction supplémentaire de translation des adresses. La technique décrite n'a pas besoin de connaître ni les connecteurs de l'OS, ni les appels du gestionnaire d'évènements de son environnement temps réel, et considère l'OS comme une boîte noire. 30 Cependant, cette technique, en regardant l'OS globalement comme une boîte noire, ne fait pas la distinction entre les contraintes normatives portant sur l'OS de base et celles afférentes à la mise en oeuvre d'une MPU. De la sorte, l'utilisation d'un OS de base ayant un niveau d'exigence en terme de sécurité QM associé à un mécanisme de protection mémoire spécifique en 35 dehors de l'OS de niveau de criticité supérieur n'est pas envisagée dans cet article 3038749 - 4 - pour répondre au besoin d'un "Safety OS". Or ce découplage de l'OS et du mécanisme de protection mémoire permettrait aux constructeurs et équipementiers d'automobiles d'intégrer une protection mémoire tout en conservant leurs OS QM habituels dans leurs projets, et 5 correspondrait à un besoin de réduction des coûts. DESCRIPTION GENERALE DE L'INVENTION. La présente invention vise par conséquent à satisfaire ce besoin. Elle a précisément pour objet un procédé de commande d'une unité de calcul électronique de véhicule automobile du type de ceux basés sur un premier système d'exploitation conforme à un premier niveau d'exigence en termes de sécurité de la norme ISO 26262, une première interface de programmes d'application, un premier gestionnaire d'évènements d'un environnement temps réel et des premiers pilotes de périphériques exécutés par une unité centrale de calcul d'un microprocesseur comprenant en outre une unité de protection mémoire. Le procédé selon l'invention met en oeuvre en outre une seconde interface de programmes d'application, un second gestionnaire d'évènements et un second pilote de périphérique, spécifiques à cette unité de protection mémoire, et distincts du premier système d'exploitation. Selon l'invention, le premier système d'exploitation, le second gestionnaire d'évènements et le second pilote sont équivalents à un second système d'exploitation conforme à un second niveau d'exigence en termes de sécurité de la norme ISO 26262 supérieur au premier niveau d'exigence en termes de sécurité. Dans le procédé de l'invention, le premier niveau d'exigence en termes de 25 sécurité est de préférence coté QM. Dans le procédé de l'invention encore, le second pilote utilise des premiers connecteurs de tâches et des seconds connecteurs d'interruptions du premier système d'exploitation. Le procédé de commande d'une unité de calcul électronique de véhicule 30 automobile selon l'invention comprend une première étape appelant une première fonction de la seconde interface de programmes d'application initialisant au moins un registre de l'unité de protection mémoire. Le procédé selon l'invention comprend en outre une deuxième étape appelant une deuxième fonction de la seconde interface de programmes 35 d'application initialisant une protection des tâches. 3038749 - 5 - Le procédé selon l'invention encore comprend en outre une troisième étape appelant une troisième fonction de la seconde interface de programmes d'application initialisant une protection des interruptions. Selon l'invention, le second gestionnaire d'évènements transmet à la 5 seconde interface de programmes d'application des violations de la protection des tâches et de la protection des interruptions. L'invention concerne également une unité de calcul électronique de véhicule automobile apte à ma mise en oeuvre du procédé de commande décrit ci-dessus. Cette unité de calcul électronique est du type de celles comprenant un 10 microprocesseur comportant au moins une unité centrale de calcul et une unité de protection mémoire associées à au moins une mémoire de programme, au moins une mémoire de données, et à au moins une interface d'entrées/ sorties. Au moins une mémoire de programme stocke des premiers codes informatiques représentatifs d'un système d'exploitation conforme à un niveau 15 d'exigence en termes de sécurité coté QM de la norme ISO 26262, d'une première interface de programmes d'application, d'un premier gestionnaire d'évènements d'un environnement temps réel et de premiers pilotes de périphériques aptes à être connectés à l'au moins une interface d'entrées/ sorties, exécutés par l'au moins une unité centrale de calcul. 20 Selon l'invention, l'au moins une mémoire de programme stocke en outre des seconds codes informatiques représentatifs d'une seconde interface de programmes d'application, d'un second gestionnaire d'évènements et d'un second pilote spécifiques à l'unité de protection mémoire distincts des premiers codes informatiques. Un véhicule automobile comprenant au moins une unité de calcul électronique tirera bénéfice de l'invention décrite ci-dessus. Ces quelques spécifications essentielles auront rendu évidents pour l'homme de métier les avantages apportés par le procédé de commande d'une unité de calcul électronique de véhicule automobile selon l'invention, ainsi que par l'unité de calcul électronique correspondante, et par le véhicule automobile comprenant une telle unité de calcul électronique, par rapport à l'état de la technique antérieur. Les spécifications détaillées de l'invention sont données dans la description qui suit en liaison avec les dessins ci-annexés. Il est à noter que ces dessins n'ont d'autre but que d'illustrer le texte de la description et ne constituent en aucune sorte 35 une limitation de la portée de l'invention. 3038749 - 6 - BREVE DESCRIPTION DES DESSINS. La Figure 1 est un schéma synoptique d'une architecture logicielle d'une unité de calcul électronique selon l'invention. La Figure 2 illustre en détail le procédé de commande de l'unité de calcul 5 électronique montrée sur la Figure 1. Les Figure 3, 4 et 5 illustrent respectivement des première, deuxième et troisième étages du procédé de commande selon l'invention. DESCRIPTION DU MODE DE REALISATION PREFERE DE L'INVENTION. 10 Dans le mode de réalisation préféré de l'invention, montré sur la Figure 1, l'unité de calcul électronique 1 de véhicule automobile dont il s'agit comporte un microprocesseur 2 comprenant une unité centrale de calcul 3, une unité de protection mémoire 4 et une interface d'entrées/ sorties 5. L'unité de calcul électronique 1 acquiert des données en provenance de 15 capteurs du véhicule et transmet des commandes à des équipements, ou en général échange des informations avec des périphériques, au moyen d'une interface de communication réseau 6 entre l'interface d'entrées/ sorties 5 et un réseau embarqué 7. Pour ce faire, de manière connue en soi, l'unité de calcul électronique est 20 commandée par des modules logiciels 8 exécutés sur le microprocesseur 2 sur lequel est implémenté un système d'exploitation 9 standardisé de type AUTOSAR, spécifiquement conçu pour les applications de l'automobile. Les modules logiciels 8 développés en fonction des besoins des utilisateurs communiquent avec le système d'exploitation 9 via une première interface de 25 programmes d'application 10 également standardisée, et communiquent avec les périphériques au moyens de premiers pilotes 11 appropriés fournis par les fabricants. Le choix d'une version de base du système d'exploitation 9, telle que AUTOSAR BSW, permettrait de limiter les coûts mais ne permettrait pas à l'unité de 30 calcul électronique 1 de satisfaire aux exigences de la norme ISO 26262 pour des degrés d'exigence supérieurs à QM, car cette version de base ne gère pas de mécanisme de protection mémoire. Tout en étant basé sur un système d'exploitation 9 coté QM, le procédé de commande de l'unité de calcul électronique 1 selon l'invention, gère l'unité de 3038749 - 7 - protection mémoire 4 du microprocesseur 2 comme le montre bien l'architecture logicielle de la Figure 1. Un second pilote 12 spécifique à l'unité de protection mémoire 4 permet de contrôler le système d'exploitation 9 au moyen de ses connecteurs 13 si un second 5 gestionnaire d'évènements 14, spécifique également à l'unité de protection mémoire 4, rapporte un évènement de violation mémoire. Une seconde interface de programmes d'application 15 permet à l'utilisateur de programmer l'unité de protection mémoire 4 et de rapporter la cause de la violation mémoire aux modules logiciels 8. 10 La Figure 2 montre l'intégration de la seconde interface de programmes d'application 15, du second pilote 12 et du second gestionnaire d'évènements 14 dans le procédé de commande selon l'invention de l'unité de calcul électronique 1. Au moment du démarrage 16 de l'unité de calcul électronique 1, un code de lancement 17 effectue le lancement du système d'exploitation 9 et une configuration 15 de l'unité de protection mémoire 4. Pour ce faire une première fonction MPU_Init() de la seconde interface de programmes d'application 15 est appelée 18 afin d'effectuer une initialisation des registres de l'unité de protection mémoire 4. La Figure 3 montre une première séquence d'appel correspondante gérée 20 par le second gestionnaire d'évènements 14. En cours d'exécution 19 de l'un des modules logiciels 8 de l'unité de calcul électronique 1 par le système d'exploitation 9, une seconde fonction MPU_SetTaskProtection() de la seconde interface de programmes d'application 15 est invoquée 20 au moment du lancement d'une tâche 21 en fournissant un premier 25 connecteur de début de tâche OS_PreTaskHook() 22 du système d'exploitation 9. Comme le montre bien une seconde séquence d'appel représentée sur la Figure 4, celle-ci est également gérée par le second gestionnaire d'évènements 14. Après déclenchement 23 de l'exécution de la tâche 21 et sa complétion 24, une première réinitialisation MPU_ResetTaskProtection() 25 de l'unité de protection 30 mémoire 4 est appelée en fournissant un premier connecteur de fin de tâche OS_PostTaskHook() 26 du système d'exploitation 9. Les modules logiciels 9 dans les applications de l'automobile travaillant essentiellement dans un environnement temps réel, les vecteurs d'interruption sont également protégés dans le procédé de commande d'une unité de calcul 35 électronique 1 selon l'invention. 3038749 - 8 - Dans ce but, une troisième fonction MPU_SetlsrProtection() de la seconde interface de programmes d'application 15 est invoquée 27 au moment du lancement d'un sous-programme d'interruption 28 en fournissant un second connecteur de début d'interruption OS_PrelsrHook() 29 du système d'exploitation 9. 5 Comme le montre bien une troisième séquence d'appel représentée sur la Figure 5, celle-ci est également gérée par le second gestionnaire d'évènements 14. Après déclenchement 30 de l'exécution du sous-programme d'interruption 28 et sa complétion 31, une seconde réinitialisation MPU_ResetlsrProtection() 32 de l'unité de protection mémoire 4 est appelée en fournissant un second connecteur de 10 fin d'interruption OS_PostlsrHook() 33 du système d'exploitation 9. L'unité de protection mémoire 4 est configurée dynamiquement à chaque changement de contexte au cours du fonctionnement 19 de l'unité de calcul électronique 1. L'unité de protection mémoire 4 est initialisée en premier par la première fonction MPU_Init() 18 de la seconde interface de programmes 15 d'application 15, ensuite les deuxième et troisième fonctions MPU_SetTaskProtection() 20, MPU_SetlsrProtection() 27 sont appelées pour initialiser les registres de l'unité de protection mémoire 4 avec des nouveaux droits d'accès pour chaque tâche 21 et sous-programme d'interruption 28, respectivement. En ajoutant un tel mécanisme de protection mémoire 4, 12, 14, 15 en dehors 20 du système d'exploitation 9 coté QM, le procédé selon l'invention permet d'obtenir un autre système d'exploitation équivalent 34 ayant un niveau d'exigence en termes de sécurité supérieur, tout en limitant les coûts. Comme il va de soi, l'invention ne se limite pas au seul mode de réalisation préférentiel décrit ci-dessus. 25 Notamment, le système d'exploitation AUTOSAR BSW cité n'est qu'un exemple parmi d'autres de systèmes d'exploitations cotés QM pouvant être mis en oeuvre dans un système embarqué. La seule restriction est que le système d'exploitation choisi soit suffisamment ouvert pour que les connecteurs de tâches et d'interruptions puissent être utilisés. 30 La description ci-dessus porte implicitement sur une unité de calcul électronique 1 comprenant un seul microprocesseur 2 avec une seule unité centrale de calcul 3. Une description similaire pourrait porter sur une unité de calcul électronique 1 comprenant des co-processeurs et/ ou, un ou des microprocesseurs multi-coeurs, notamment dans des architectures matérielles ou logicielles 3038749 - 9 - redondantes où les questions de protection des données/ instructions dans des mémoires partagées sont particulièrement importantes. Il est considéré que le microprocesseur 2 comprend une unité de protection mémoire ou MPU 4. L'homme de métier connaît des microprocesseurs, tels que le 5 microprocesseur de référence MPC5567, déjà cité, qui comporte une unité de gestion de la mémoire ou MMU. Comme déjà indiqué, une MMU est une MPU 4 avec une fonction supplémentaire de translation des adresses, mais reste, pour les fonctions de protection mémoire, une MPU 4. La présente description pourrait donc s'appliquer sans modification à une unité de calcul électronique 1 comprenant un 10 microprocesseur 2 muni d'une MMU. Ces autres modes de réalisation ne sortiraient pas du cadre de la présente invention dans la mesure où ils résultent des revendications ci-après. REVENDICATIONS1) Procédé de commande d'une unité de calcul électronique (1) de véhicule automobile du type de ceux basés sur un premier système d'exploitation (9) 5 conforme à un premier niveau d'exigence en termes de sécurité de la norme ISO 26262, une première interface de programmes d'application (10), un premier gestionnaire d'évènements d'un environnement temps réel et des premiers pilotes (11) de périphériques exécutés par une unité centrale de calcul (3) d'un microprocesseur (2) comprenant en outre une unité de protection mémoire (4), 10 caractérisé en ce qu'il met en oeuvre en outre une seconde interface de programmes d'application (15), un second gestionnaire d'évènements (14) et un second pilote (12) de périphérique spécifiques à ladite unité de protection mémoire (4) et distincts dudit premier système d'exploitation (9). 15 2) Procédé de commande d'une unité de calcul électronique de véhicule automobile selon la revendication 1, caractérisé en ce que ledit premier système d'exploitation (9), ledit second gestionnaire d'évènements (14) et ledit second pilote (11) sont équivalents à un second système d'exploitation (34) conforme à un second niveau d'exigence en termes de sécurité de la norme ISO 26262 supérieur audit premier 20 niveau d'exigence en termes de sécurité. 3) Procédé de commande d'une unité de calcul électronique (1) de véhicule automobile selon la revendication 2, caractérisé en ce que ledit premier niveau d'exigence en termes de sécurité est coté QM. 25 4) Procédé de commande d'une unité de calcul électronique (1) de véhicule automobile selon l'une quelconque des revendications 1 à 3 précédentes, caractérisé en ce que ledit second pilote (12) utilise des premiers connecteurs de tâches (13; 22, 26) et des seconds connecteurs d'interruptions (13; 29, 33) dudit 30 premier système d'exploitation (9). 5) Procédé de commande d'une unité de calcul électronique (1) de véhicule automobile selon la revendication 4, caractérisé en ce qu'il comprend une première étape appelant une première fonction (18) de ladite seconde interface de 3038749 - 11 - programmes d'application (15) initialisant au moins un registre de ladite unité de protection mémoire (4). 6) Procédé de commande d'une unité de calcul électronique (1) de véhicule 5 automobile selon la revendication 5, caractérisé en ce qu'il comprend en outre une deuxième étape appelant une deuxième fonction (20) de ladite seconde interface de programmes d'application (15) initialisant une protection des tâches (21). 7) Procédé de commande d'une unité de calcul électronique (1) de véhicule 10 automobile selon la revendication 6, caractérisé en ce qu'il comprend en outre une troisième étape appelant une troisième fonction (27) de ladite seconde interface de programmes d'application (15) initialisant une protection des interruptions (28). 8) Procédé de commande d'une unité de calcul électronique (1) de véhicule 15 automobile selon la revendication 7, caractérisé en ce que ledit second gestionnaire d'évènements (14) transmet à ladite seconde interface de programmes d'application (15) des violations de ladite protection des tâches (21) et de ladite protection des interruptions (28). 20 9) Unité de calcul électronique (1) de véhicule automobile apte à ma mise en oeuvre du procédé de commande selon l'une quelconque des revendications 1 à 8 précédentes, ladite unité de calcul électronique (1) étant du type de celles comprenant un microprocesseur (2) comportant au moins une unité centrale de calcul (3) et une unité de protection mémoire (4) associées à au moins une mémoire 25 de programme, au moins une mémoire de données, et à au moins une interface d'entrées/ sorties (5), ladite au moins une mémoire de programme stockant des premiers codes informatiques représentatifs d'un système d'exploitation (9) conforme à un niveau d'exigence en termes de sécurité coté QM de la norme ISO 26262, d'une première interface de programmes d'application (10), d'un premier 30 gestionnaire d'évènements d'un environnement temps réel et de premiers pilotes (11) de périphériques aptes à être connectés à ladite au moins une interface d'entrées/ sorties (5), exécutés par ladite au moins une unité centrale de calcul (3), caractérisée en ce que ladite au moins une mémoire de programme stocke en outre des seconds codes informatiques représentatifs d'une seconde interface de 35 programmes d'application (15), d'un second gestionnaire d'évènements (14) et d'un 3038749 - 12 - second pilote (12) spécifiques à ladite unité de protection mémoire (4) distincts desdits premiers codes informatiques (9, 10, 11). 10) Véhicule automobile, caractérisé en qu'il comprend au moins une unité de calcul 5 électronique (1) selon la revendication 9 précédente.