La présente invention concerne un procédé de conception d’une architecture de tâches applicative d’une unité de contrôle électronique basée sur un système d’exploitation Autosar adaptable à une pluralité de microcontrôleurs comportant un ou plusieurs coeurs en tant qu’unités de traitement travaillant en parallèle pour un traitement de différentes tâches par l’unité de contrôle électronique, la couche logicielle de base servant à la connexion avec un microcontrôleur sélectionné faisant partie de l’unité de contrôle électronique, des différentes tâches du système d’exploitation à exécuter par l’unité de contrôle électronique étant attribuées par l’architecture de tâches applicative sur le ou les coeurs du microcontrôleur sélectionné.

La présente invention concerne aussi un procédé d’intégration d’un microcontrôleur multicoeurs dans une unité de contrôle électronique basée sur un système d’exploitation Autosar comprenant une architecture de tâches applicative conçue conformément à un tel procédé de conception. La présente invention concerne aussi une unité de contrôle électronique basée sur un système d’exploitation Autosar.

La présente invention trouve une application particulière mais non limitative dans le domaine des véhicules automobiles pour calculateurs d’un contrôle commande moteur ou autre avec une architecture de système ouvert, c’est-à-dire un système dans lequel il est possible de réutiliser des fonctionnalités selon une interface standard ou dans une version dite adaptable à un système dans lequel il est possible d’ajouter ou d’enlever de nouvelles fonctionnalités.

Une couche logicielle de base fait la connexion logicielle entre un microcontrôleur sélectionné et le reste de l’unité de contrôle électronique basée sur un système d’exploitation Autosar en attribuant à chaque cœur des tâches.

Le système d’exploitation Autosar est un système à architecture ouverte pour le domaine automobile aussi connu sous la dénomination anglo-saxonne de « AUTomotive Open System ARchitecture ».

Les calculateurs de contrôle moteur utilisaient jusqu’à ces dernières années des microcontrôleurs avec une seule unité de traitement, c’est-à-dire des microcontrôleurs monocœur. Dernièrement, il est apparu des microcontrôleurs comportant au moins deux unités de traitement, avantageusement trois ou plus, dénommés microcontrôleurs à cœurs multiples ou multicœurs qui permettent une puissance de calcul supérieure à celle des microcontrôleurs monocœur, tout en utilisant une fréquence de fonctionnement égale à celle d’un microcontrôleur monocœur. La présente invention se rapporte aussi bien à un microcontrôleur monocoeur qu’à un microcontrôleur multicoeurs, bien que cette dernière application soit la plus avantageuse.

Classiquement, l’architecture du logiciel associé au microcontrôleur découpe les fonctions en sous-fonctions selon des besoins de répartition du travail ou de gestion de la diversité des options. Actuellement, une allocation de fonctions sur deux unités de traitement d’un microcontrôleur à coeurs multiples est par exemple réalisée par une allocation sur un cœur du logiciel d’application au-dessus d’une interface de l’architecture du système ouvert et une allocation du logiciel de base du système sur un autre cœur du microcontrôleur, plus adapté pour la gestion des entrées et sorties de communication.

La figure 1 montre une unité 1 de contrôle électronique basée sur un système d’exploitation Autosar typique comprenant une couche logicielle applicative 2, une couche logicielle de base 4 et un microcontrôleur 5. La couche logicielle applicative 2 intègre l’architecture de tâches applicative attribuant des traitements au microcontrôleur 5.

Une tâche au sens du système d’exploitation est un ensemble de fonctions/traitements à exécuter dans un certain ordre et à une certaine récurrence. Ces traitements ne sont pas forcément liés fonctionnellement, par exemple la gestion du contrôle de vitesse, suivie de la gestion de la vanne d’un turbocompresseur, suivie par la gestion du niveau de carburant dans le réservoir, mais ont en commun de devoir être exécutées à la même fréquence. Elles sont donc intégrées dans la même tâche ou dans deux tâches chaînées sur plusieurs cœurs. Entre la couche logicielle applicative 2 et la couche logicielle de base 4 se trouve une couche RTE 3 typique de la norme Autosar dite d’environnement d’exécution, faisant abstraction de la topologie du réseau à des fins d’échange d’informations internes et externes à l’unité 1 de contrôle électronique entre les composants logiciels applicatifs et entre la couche logicielle applicative 2 et la couche de base 4 logicielle.

La partie logicielle d’une même unité 1 de contrôle électronique basée sur un système d’exploitation Autosar avec ses couches logicielle applicative 2 et logicielle de base 4 peut être associée à différents types de microcontrôleur 5 ayant un même nombre de cœurs mais différant par leur conception.

Par exemple, pour des microcontrôleurs multicœurs présentant un même nombre de cœurs, ce ne sont pas forcément les mêmes cœurs qui remplissent les mêmes tâches. Lors d’une adaptation de la partie logicielle à un nouveau microcontrôleur, toute l’architecture de tâches applicative doit être reconçue pour s’adapter à ce nouveau microcontrôleur, ce qui prend du temps et occasionne un coût élevé.

Par exemple, dans un microcontrôleur multicœurs, le démarrage se fait toujours selon le même cœur, le plus souvent prédéterminé à l’avance, de même que l’accès aux entrées et sorties du microcontrôleur. Ce cœur n’est pas forcément le même pour les entrées et sorties ainsi que pour le démarrage, et peut différer d’un type de microcontrôleur à un autre. Des fournisseurs peuvent proposer des microcontrôleurs dont les coeurs présentent diverses fonctionnalités potentielles permettant à l’utilisateur de choisir à quel cœur sera dédiée une fonctionnalité spécifique, cette fonctionnalité spécifique n’étant pas activée ou disponible sur les autres cœurs.

Il est aussi sélectionné un cœur en tant que cœur de sûreté de fonctionnement, de même qu’il est procédé à une duplication de cœurs pour assurer une redondance et un contrôle de sûreté.

De nombreux types de microcontrôleurs multicœurs peuvent être utilisés, variant entre un microcontrôleur deux cœurs jusqu’à un microcontrôleur six cœurs. Entre des différents microcontrôleurs avec un même nombre de cœurs, ce ne sont pas forcément les mêmes cœurs qui sont utilisés en tant que cœur de démarrage, cœur de communication pour entrées et sorties d’informations et cœur de sûreté. Pour une même famille de microcontrôleurs proposée par un même fournisseur, les fonctionnalités citées ci-dessus ne sont donc pas toujours disponibles sur les mêmes cœurs d’un microcontrôleur à un autre de la même famille. Ceci est encore plus pertinent pour des microcontrôleurs de différents fournisseurs.

De ce fait, les attributions des tâches faites par le logiciel de la couche de base ne se feront pas sur les mêmes cœurs d’un microcontrôleur à un autre et l’architecture de tâches applicative ne sera pas la même pour ces microcontrôleurs.

En conséquence, les projets basés sur un microcontrôleur donné présenteront une autre architecture que les projets basés sur un autre microcontrôleur car les tâches du système d’exploitation ont besoin d’être allouées à un cœur donné.

Dans le domaine automobile, et en particulier pour une unité de contrôle électronique basée sur un système d’exploitation Autosar, les considérations de coût sont tellement drastiques qu’une stratégie de réutilisation de l’architecture de tâches applicative est requise. Ceci pourrait être réalisé par des fonctions réutilisables qui seraient intégrées dans différents projets en étant basées sur la même plateforme.

Selon l’approche de l’état de la technique, la réutilisation et la synergie entre projets pour différents microcontrôleurs sont rendues difficiles, étant donné qu’il n’est pas possible de partager une architecture de tâches commune parmi des microcontrôleurs présentant notamment le même nombre de cœurs.

Le problème à la base de la présente invention est pour une unité de contrôle électronique basée sur un système d’exploitation Autosar de concevoir l’architecture de tâche applicative de cette unité de contrôle électronique qui puisse faciliter l’adaptation de différents types de microcontrôleurs monocœur ou multicœurs à l’unité de contrôle électronique. A cet effet, la présente invention concerne un procédé de conception d’une architecture de tâches applicative d’une unité de contrôle électronique basée sur un système d’exploitation Autosar adaptable à une pluralité de microcontrôleurs comportant un ou plusieurs coeurs en tant qu’organes de traitement travaillant en parallèle pour une exécution de différentes tâches d’un système d’exploitation par l’unité de contrôle électronique, l’architecture logicielle de base servant à la connexion avec un microcontrôleur sélectionné faisant partie de l’unité de contrôle électronique, des différentes tâches à remplir du système d’exploitation par l’unité de contrôle électronique étant attribuées par l’architecture de tâches applicative sur le ou les coeurs du microcontrôleur sélectionné, caractérisé en ce que, préalablement à une association avec un microcontrôleur sélectionné, il est procédé à une élaboration de l’architecture de tâches applicative en utilisant au moins un cœur virtuel différent du ou des cœurs du microcontrôleur, les différentes tâches étant affectées respectivement sur ledit au moins un cœur virtuel et il est effectué une association dudit au moins un cœur virtuel avec le ou les cœurs du microcontrôleur sélectionné pour une attribution de tâches affectées audit au moins un cœur virtuel au cœur ou entre les cœurs du microcontrôleur sélectionné.

L’unité de contrôle électronique basée sur un système d’exploitation Autosar peut être une unité de contrôle moteur, une unité de contrôle de la transmission d’un véhicule automobile ou toute autre unité en charge du fonctionnement d’organes embarqués dans le véhicule automobile.

Afin d’éviter que la diversité des microcontrôleurs n’impacte sur les architectures des projets, la présente invention propose d’introduire une abstraction des cœurs.

Cette abstraction permet un regroupement des cœurs pour des domaines de calcul séparés, par exemple dans le but d’intégrer des tâches différentes ou pour séparer des regroupements de calcul dépendant de la mise en œuvre du logiciel.

La présente invention permet d’élaborer une architecture de tâches applicative qui peut être commune à plusieurs types de microcontrôleurs présentant le même nombre de cœurs. En plus, une telle architecture de tâches applicative avec un ou des cœurs virtuels permet une permutation facilitée avec moins de reconception du logiciel quand il est passé à un nombre différent de cœurs pour un nouveau microcontrôleur ou à un autre microcontrôleur pour lequel les tâches sont allouées à d’autres cœurs.

Auparavant, l’architecture de tâches applicative devait attribuer à un cœur spécifique du microcontrôleur les activités primordiales que sont la redondance et le contrôle d’exécution des tâches. Or, ce cœur spécifique pouvait ne pas être le même pour deux microcontrôleurs provenant du même fournisseur ou surtout provenant d’un fournisseur différent. Il en résultait que la conception de l’architecture en tâches applicative devait être complètement refaite.

Selon l’invention, ces activités primordiales sont confiées tout d’abord à un cœur virtuel. Il est alors possible d’associer ce cœur virtuel au cœur réel dans un microcontrôleur qui est apte à remplir ces fonctions. La conception de l’architecture de tâches applicative n’a plus besoin d’être reconstruite, seule l’association du cœur virtuel avec le cœur spécifique pour ces fonctions dans un nouveau microcontrôleur a besoin d’être réactualisée. Ceci vaut aussi pour les cœurs en charge du démarrage du logiciel, ou de la gestion des ports d’entrée et de sortie du microcontrôleur qui peuvent différer d’un modèle de microcontrôleur à un autre.

Il s’ensuit que la diversité des microcontrôleurs n’impacte plus l’architecture de tâches applicative qui n’a plus besoin d’être complètement réactualisée.

L’utilisation d’un ou de plusieurs cœurs virtuels aide également le programmeur de l’architecture de tâches applicative à être indépendant du ou des cœurs du microcontrôleur qui sont liés à la conception du microcontrôleur et qui peuvent avoir différentes fonctions pour différents types de microcontrôleurs. La présente invention permet de partager une architecture des tâches standardisée en dépit des différences entre les microcontrôleurs. Une tâche est associée à un et un seul cœur virtuel. Cette association est rigide. Changer l’association demande de renommer la tâche. Il est fréquent qu’une telle réassociation ne soit pas possible. Il faut supprimer, puis créer une nouvelle tâche. Un cœur virtuel pourrait n’avoir aucune tâche associée donc resterait inutilisé par le système d’exploitation. Un cœur virtuel est associé à un et un seul cœur réel. Cette association est souple : elle peut être aisément changée selon les besoins. Un cœur de microcontrôleur peut n’avoir aucun cœur virtuel associé. Par exemple, on peut utiliser un microcontrôleur six cœurs sur lequel trois ou quatre cœurs uniquement sont actifs ou utilisés.

Avantageusement, le microcontrôleur sélectionné est multicœurs, l’architecture de tâches applicative comprenant plusieurs cœurs virtuels. Ceci est l’application préférentielle de la présente invention, étant donné qu’il y avait de multiples possibilités de microcontrôleurs avec des attributions différentes des activités primordiales à divers cœurs. Pour adapter un microcontrôleur différent à la place d’un autre microcontrôleur, il suffit de changer l’association du cœur virtuel avec le cœur du microcontrôleur qui présente les moyens nécessaires de traitement des fonctions du cœur virtuel. Ceci aide aussi au passage d’un microcontrôleur avec un nombre de cœurs supérieurs, un nouveau cœur virtuel étant ajouté. On obtient ainsi une standardisation de l’architecture de tâches applicative. Avantageusement, les tâches affectées à un cœur virtuel sont attribuées à un même cœur du microcontrôleur sélectionné. A un cœur virtuel correspond un cœur spécifique du microcontrôleur. Il est possible de paralléliser une exécution de différentes tâches ou de « chaîner » différentes tâches en les faisant s’exécuter les unes après les autres.

Avantageusement, quand le microcontrôleur sélectionné comprend au moins deux groupes de cœurs séparés reliés par un pont, il est élaboré un groupe de cœurs virtuels pour chaque groupe de cœurs du microcontrôleur, les groupes de cœurs virtuels étant indépendants les uns des autres. Les groupes de cœurs travaillent séparément. Il est donc possible d’avoir un groupe de cœurs virtuels pour chaque groupe.

Avantageusement, quand le microcontrôleur sélectionné comprend au moins un cœur présentant des parties sécurisées et non sécurisées, un cœur virtuel est désigné pour être associé à ce cœur sécurisé du microcontrôleur sélectionné. Comme tous les cœurs d’un microcontrôleur multicœurs peuvent avoir des propriétés et caractéristiques différentes, les cœurs virtuels présentent des propriétés et caractéristiques analogues à leur cœur du microcontrôleur associé. Tous les cœurs d’un microcontrôleur peuvent présenter différents niveaux de sécurité allant par exemple de haute sécurité à basse en passant par moyenne. Les cœurs peuvent présenter des vitesses d’horloge différentes pour exécuter les instructions.

L’invention concerne aussi un procédé d’intégration d’un microcontrôleur multicœurs dans une unité de contrôle électronique basée sur un système d’exploitation Autosar comprenant une architecture de tâches applicative conçue conformément à un tel procédé de conception, caractérisé en ce qu’il est déterminé pour chaque cœur du microcontrôleur ses caractéristiques relatives à sa capacité à effectuer un contrôle par exécution redondante parallèle et simultanée du logiciel, son niveau de sûreté, sa capacité d’effectuer un démarrage du microcontrôleur, sa capacité à accéder aux périphériques d’entrée et sortie du microcontrôleur et chaque cœur du microcontrôleur est associé avec le cœur virtuel qui lui est le plus proche au niveau des caractéristiques. Le fabricant d’un microcontrôleur fournit toutes les données relatives notamment aux cœurs du microcontrôleur. Il est alors possible au concepteur du logiciel de l’architecture de tâches applicative de savoir quel est le cœur du microcontrôleur qui correspond le mieux à un cœur virtuel donné, par exemple le cœur virtuel qui remplit la fonction de cœur de sûreté et de l’attribuer au cœur spécifique dédié à cette fonction dans le microcontrôleur, ce cœur pouvant être différent selon les microcontrôleurs. Il en va de même pour un cœur du microcontrôleur spécifiquement dédié au démarrage du microcontrôleur qui doit être associé au cœur virtuel dédié au démarrage et possiblement pour le cœur dédié aux communications entrées et sorties du microcontrôleur. Le fournisseur de microcontrôleur peut prévoir plusieurs coeurs dotés de fonctions de sûreté, de démarrage ou de communications, et l’utilisateur du microcontrôleur peut choisir un des coeurs pour assurer une fonction spécifique parmi les coeurs aptes à assurer cette fonction spécifique.

Avantageusement, il est établi un ordre de priorité entre les caractéristiques, la capacité à effectuer un contrôle étant prioritaire.

Avantageusement, il est établie une affinité de cœur aussi bien pour un cœur virtuel qu’un cœur du microcontrôleur, l’affinité concernant une intégration sur un cœur du microcontrôleur, une intégration sur un cœur virtuel, une intégration sur un même cœur qu’une tâche donnée, une intégration sur un cœur dont le cœur de sûreté est actif ou qui est le cœur privilégié pour l'accès aux périphériques, ou un cœur d’un niveau de sûreté donné.

L’invention concerne enfin une unité de contrôle électronique basée sur un système d’exploitation Autosar comprenant une couche logicielle applicative, une architecture de tâches applicative et un microcontrôleur, la couche de base logicielle servant à une connexion avec le microcontrôleur faisant partie de l’unité de contrôle électronique, des différentes tâches à remplir par l’unité de contrôle électronique étant attribuées par l’architecture de tâches applicative sur un ou des cœurs du microcontrôleur, caractérisé en ce que l’architecture de tâches applicative de l’unité de contrôle électronique est conçue conformément à un tel procédé de conception ou en ce que le microcontrôleur a été intégré à l’unité de contrôle électronique conformément à un tel procédé d’intégration.

Avantageusement, le microcontrôleur comprend trois cœurs. Actuellement, les microcontrôleurs trois cœurs sont les plus répandus en tant que microcontrôleurs multicœurs, mais ce ne sont pas les seuls.

L’invention concerne enfin un véhicule automobile caractérisé en ce qu’il comprend au moins une telle unité de contrôle électronique basée sur un système d’exploitation Autosar.

D’autres caractéristiques, buts et avantages de la présente invention apparaîtront à la lecture de la description détaillée qui va suivre et au regard des dessins annexés donnés à titre d’exemples non limitatifs et sur lesquels :

- la figure 1 est une représentation schématique d’une vue en coupe d’une unité de contrôle électronique basée sur un système d’exploitation Autosar pouvant être utilisée dans le cadre de la présente invention,

- la figure 2 est une représentation schématique d’une vue en coupe d’une architecture de tâches applicative faisant partie d’une unité de contrôle électronique basée sur un système d’exploitation Autosar selon l’invention, deux microcontrôleurs étant montrés avec cette architecture de tâches applicative comportant des coeurs virtuels.

Dans ce qui va suivre, le microcontrôleur illustré aux figures et décrit ci-après comprend trois coeurs. Ceci n’est pas limitatif et la présente invention peut concerner un microcontrôleur monocoeur ou multicœurs avec un nombre de coeurs différent de trois.

La mention d’un cœur sans autre précision s’adresse à un cœur réel du microcontrôleur.

En se référant aux figures 1 et 2, la présente invention concerne un procédé de conception d’une architecture de tâches applicative d’une unité 1 de contrôle électronique basée sur un système d’exploitation Autosar adaptable à une pluralité de microcontrôleurs 5, 5a, un microcontrôleur 5, 5a étant sélectionné pour être associé à la partie logicielle de l’unité 1 de contrôle électronique basée sur un système d’exploitation Autosar formé par la couche logicielle applicative 2 intégrant l’architecture de tâches applicative, la couche de base 4 logicielle et la couche d’environnement d’exécution 3.

La couche de base 4 logicielle peut comporter des services du système qu’est l’unité 1 de contrôle électronique, des mémoires, des services de communication. La couche de base 4 logicielle comporte un module d’abstraction du système embarqué, un module d’abstraction de communication avec le microcontrôleur 5, 5a et un module d’abstraction du microcontrôleur 5, 5a en communication en entrées et sorties.

Ces modules d’abstraction sont différents des cœurs virtuels AO, A1 , A2 que proposent l’invention et qui seront ultérieurement décrits en étant dans l’architecture de tâches applicative intégrée dans la couche logicielle applicative 2. La couche de base 4 logicielle comporte aussi des pilotes du microcontrôleur 5, 5a, des pilotes de mémoires, des pilotes de communication et des pilotes de communication en entrée et en sortie.

Le microcontrôleur 5, 5a comporte un ou plusieurs cœurs CO, C1 , C2 en tant qu’organes de traitement travaillant en parallèle pour un traitement de différentes tâches T10-T14, T20-T24, T30-T34 par l’unité 1 de contrôle électronique. Les références T10- T14, T20-T24, T30-T34 regroupent chacune des tâches différentes. Il est montré cinq tâches par cœur à la figure 2, mais ce nombre n’est pas limitatif en pouvant être plus élevé comme moins élevé.

Les tâches forment par cœur des jeux de tâches aux propriétés bien définies. Des relations entre les tâches peuvent être établies pour certaines tâches, telles que des exécutions parallèles ou au contraire chaînées.

Comme précédemment mentionné, l’architecture de tâches applicative sert à la connexion avec le microcontrôleur 5, 5a sélectionné faisant partie de l’unité 1 de contrôle électronique, des différentes tâches T10-T14, T20-T24, T30-T34 à remplir par l’unité 1 de contrôle électronique étant attribuées par l’architecture de tâches applicative sur le ou les coeurs CO, C1 , C2 du microcontrôleur 5, 5a sélectionné.

Selon l’invention, préalablement à une association avec un microcontrôleur 5, 5a sélectionné, lors de la conception de l’architecture logicielle de l’unité 1 de contrôle électronique basée sur un système d’exploitation Autosar, il est procédé à une élaboration de l’architecture de tâches applicative en utilisant au moins un cœur virtuel AO, A1 , A2 différent du ou des cœurs CO, C1 , C2 du microcontrôleur. Ceci permet une abstraction du ou des cœurs CO, C1 , C2 du microcontrôleur 5, 5a.

En se référant à la figure 2, les différentes tâches T10-T14, T20-T24, T30- T34 à répartir sur le ou les cœurs CO, C1 , C2 du microcontrôleur 5, 5a sont affectées respectivement sur le ou les cœurs virtuels AO, A1 , A2. Il s’ensuit que l’architecture de tâches applicative est au départ élaborée en complète indépendance des cœurs CO, C1 , C2 du microcontrôleur. Ceci permet de construire une architecture de tâches applicative qui restera commune pour tous les microcontrôleurs 5, 5a différents et qui n’aura pas besoin d’être réactualisée lorsqu’il est nécessaire d’adapter l’architecture de tâches applicative à un autre microcontrôleur 5, 5a avec un même nombre de cœurs CO, C1 , C2 que le microcontrôleur 5, 5a pour lequel l’architecture de tâches applicative a été élaborée.

Il est ainsi créé une architecture générique qui donne un aperçu sur la validité de la partie relative à la couche logicielle applicative 2 et à l’architecture de tâches applicative.

Il est ensuite effectué une association du ou des cœurs virtuels AO, A1 , A2 avec le ou les cœurs CO, C1 , C2 du microcontrôleur 5, 5a sélectionné pour une attribution de tâches T10-T14, T20-T24, T30-T34 précédemment affectées audit au moins un cœur virtuel AO, A1 , A2 au cœur ou entre les cœurs CO, C1 , C2 du microcontrôleur 5, 5a sélectionné. Un cœur virtuel AO, A1 , A2 correspond à un cœur du microcontrôleur CO, C1 , C2.

La présente invention permet de partager la même architecture de tâches applicative entre des unités 1 de contrôle électronique avec différents microcontrôleurs 5, 5a comportant des cœurs CO, C1 , C2 présentant des propriétés différentes, par exemple ne présentant pas le même niveau de sûreté.

Les cœurs virtuels AO, A1 , A2 peuvent être utilisés lors de l’intégration de différentes applications à un système à un cœur ou à plusieurs cœurs CO, C1 , C2 multiples, ce qui peut se faire selon l’invention en indépendance du microcontrôleur 5, 5a utilisé.

A la figure 2, qui illustre le cas non limitatif de deux microcontrôleurs 5, 5a trois cœurs CO, C1 , C2, des tâches T10-T14, T20-T24, T30-T34 ont été réparties sur trois coeurs virtuels AO, A1 , A2. Deux microcontrôleurs 5, 5a sont montrés avec des répartitions différentes de coeurs CO, C1 , C2 réels pour accomplir ces tâches T10-T14, T20-T24, T30-T34. Les coeurs virtuels AO, A1 , A2 ne seront donc pas associés avec la même disposition de coeurs CO, C1 , C2 réels dans les deux cas mais avec le cœur réel qui convient le mieux à un cœur virtuel AO, A1 , A2 spécifique et qui peut occuper une place différente dans l’arrangement des trois cœurs CO, C1 , C2 dans le microcontrôleur 5, 5a donné.

Le cœur virtuel AO peut correspondre à un cœur à haute sécurité pouvant remplir la fonction de cœur de sûreté aussi appelé checker core en langue anglo- saxonne. Les deux autres cœurs virtuels restants sont référencés A1 et A2.

Seulement dans un but illustratif et non limitatif, pour un premier microcontrôleur référencé 5, le cœur de sûreté est le cœur référencé CO servant aussi au démarrage du microcontrôleur 5 tandis que pour un deuxième microcontrôleur référencé 5a, le cœur de sûreté est le cœur référencé C1 différent du cœur de démarrage qui est le cœur CO. C’est donc pour ce deuxième microcontrôleur 5a le cœur C1 qui est associé au cœur virtuel AO. Une adaptation au deuxième microcontrôleur 5a de l’architecture de tâches applicative implémentée pour le premier microcontrôleur 5 n’a besoin que de prévoir une modification dans l’étape d’association des cœurs virtuels AO, A1 , A2 avec respectivement un cœur CO, C1 , C2 du microcontrôleur 5, 5a, le reste de l’architecture étant conservé, ce qui est un grand avantage procuré par la présente invention.

Il peut y avoir des microcontrôleurs avec des possibilités de sélection d’un cœur de sûreté parmi plusieurs cœurs aptes à exercer ce rôle, l’utilisateur disposant d’une telle possibilité de sélection. Le cœur de sûreté ainsi sélectionné est associé au cœur virtuel dédié à la sûreté.

Comme exemple non limitatif d’un ensemble de cœurs virtuels AO, A1 , A2 adaptés à un microcontrôleur 5, 5a spécifique, il peut être cité un cœur virtuel AO sécurisé en entrée et en sortie avec des partitions sécurisées ou non, un cœur virtuel de communication non sécurisé et un cœur alternatif non sécurisé qui correspondent respectivement à des cœurs réels d’un microcontrôleur 5, 5a trois cœurs, ce qui est un exemple non limitatif d’un microcontrôleur 5, 5a multicœurs dans le sens de la présente invention.

Ainsi, quand le microcontrôleur 5, 5a sélectionné est multicœurs CO, C1 , C2, l’architecture de tâches applicative peut comprendre plusieurs cœurs virtuels AO, A1 , A2, avec autant de cœurs virtuels AO, A1 , A2 que le microcontrôleur 5, 5a possède de cœurs CO, C1 , C2. Les tâches T10-T14, T20-T24, T30-T34 affectées à un cœur virtuel AO, A1 , A2 peuvent être attribuées à un même cœur CO, C1 , C2 du microcontrôleur 5, 5a sélectionné.

De plus en plus de microcontrôleurs 5, 5a présentent des groupes de cœurs CO, C1 , C2 travaillant en parallèle. Quand le microcontrôleur 5, 5a sélectionné pour faire partie de l’unité 1 de contrôle électronique basée sur un système d’exploitation Autosar comprend au moins deux groupes de cœurs CO, C1 , C2 séparés reliés par un pont, il est élaboré un groupe de cœurs virtuels AO, A1 , A2 pour chaque groupe de cœurs CO, C1 , C2 du microcontrôleur 5, 5a, les groupes de cœurs virtuels AO, A1 , A2 étant indépendants les uns des autres. Par exemple, pour n groupes ou plus de trois cœurs CO, C1 , C2 dans un microcontrôleur 5, 5a, il peut être élaboré des groupes AO, A1 , A2 puis B0, B1 , B2 et ainsi de suite jusqu’à une énième lettre, ce qui n’est pas représenté à la figure 2.

Un cœur virtuel AO, A1 , A2 peut donc être défini par deux caractères. Le premier caractère, par exemple A, indique, de façon non limitative, le domaine d’application, tandis que le second caractère est le nombre associé au cœur virtuel AO, A1 , A2 dans son domaine d’application, par exemple de 1 à 3, ce qui n’est pas limitatif.

Les tâches T10-T14, T20-T24, T30-T34 peuvent être classifiées en des tâches d’acquisition avec une communication entre l’architecture de tâches applicative et la couche logicielle applicative 2 comme des acquisitions et des diagnostics associés ou des commandes transitant de la couche applicative vers la couche de base 4, par exemple des informations sur de nouvelles données de la couche applicative 2 transmises à la couche de base 4. En pratique, une même tâche peut contenir de l’acquisition aussi bien que du contrôle de commande.

Des tâches T10-T14, T20-T24, T30-T34 peuvent être réparties sur plusieurs cœurs virtuels AO, A1 , A2. Les tâches T10-T14, T20-T24, T30-T34 peuvent être classées selon leur caractère périodique ou aléatoire ou selon leurs durées d’exécution et réparties sur les cœurs virtuels AO, A1 , A2 en fonction de ces critères.

Quand le microcontrôleur 5, 5a sélectionné comprend au moins un cœur CO ou C1 présentant des parties sécurisées et non sécurisées, un premier cœur virtuel AO peut être désigné pour être associé à ce cœur sécurisé CO ou C1 du microcontrôleur 5, 5a sélectionné, ce premier cœur virtuel étant le cœur AO précédemment illustré à la figure 2 en présentant virtuellement des parties sécurisées et non sécurisées. Un tel cœur virtuel AO peut donc être associé à un cœur de sûreté ou checker core en langue anglo-saxonne dans le microcontrôleur.

L’invention concerne aussi un procédé d’intégration d’un microcontrôleur 5, 5a multicœurs dans une unité 1 de contrôle électronique basée sur un système d’exploitation Autosar comprenant une architecture de tâches applicative conçue conformément à un tel procédé de conception. Il est déterminé pour chaque cœur CO, C1 , C2 du microcontrôleur 5, 5a ses caractéristiques relatives à sa capacité à effectuer un contrôle en exécutant en parallèle des tâches T10-T14, T20-T24, T30-T34 identiques simultanées, son niveau de sûreté, sa capacité d’effectuer un démarrage du microcontrôleur 5, 5a, sa capacité à communiquer en entrée ou en sortie avec l’architecture de tâches applicative.

Ceci correspond aux spécifications données par le fournisseur du microcontrôleur 5, 5a. Le fournisseur peut proposer plusieurs combinaisons de cœurs spécifiques pour un même microcontrôleur, l’utilisateur du microcontrôleur pouvant choisir un cœur entre plusieurs cœurs aptes à devenir un cœur de sûreté, un cœur de démarrage ou un cœur de communication en entrées et en sorties.

A chaque cœur CO, C1 , C2 du microcontrôleur 5, 5a est associé un cœur virtuel AO, A1 , A2 qui lui est le plus proche au niveau des caractéristiques, chaque cœur virtuel AO, A1 , A2 ayant été virtuellement conçu pour comporter virtuellement de telles caractéristiques qui sont nécessaires au fonctionnement du microcontrôleur.

Parmi toutes ces caractéristiques, il peut être établi un ordre de priorité entre les caractéristiques, la capacité à effectuer un contrôle étant prioritaire. Par exemple, à la figure 2, le cœur CO du premier microcontrôleur 5 est sécurisé et apte à remplir la fonction de cœur de sûreté, mais est aussi apte à effectuer le démarrage du microcontrôleur 5 tandis que le cœur C1 du deuxième microcontrôleur 5a est sécurisé et apte à remplir la fonction de cœur de sûreté mais n’est pas apte à effectuer le démarrage. L’association avec un cœur virtuel AO, A1 , A2 se fera pour les deux cœurs CO, C1 , C2 des deux microcontrôleurs 5, 5a avec un cœur virtuel AO sécurisé en priorité.

Pour toute fonctionnalité à intégrer, il existe la possibilité de spécifier, en phase de design, une affinité de cœur, le cœur pouvant être soit virtuel ou réel. Cette affinité de cœur sera vérifiée, de façon outillée, au moment de l'intégration sur les différents projets.

Par exemple, l’affinité de cœur peut s'exprimer de différentes façons comme une intégration sur un cœur réel du microcontrôleur, une intégration sur un cœur virtuel, une intégration sur un même cœur qu’une fonction donnée, une intégration sur un cœur dont le cœur de sûreté est actif ou qui est le cœur privilégié pour l'accès aux périphériques ou un cœur d’un niveau de sûreté donné, etc.

Cette dernière formulation est la plus intéressante car basée sur un principe d'abstraction en se positionnant par rapport à une caractéristique du cœur et non par rapport à un cœur donné. L’invention concerne enfin une unité 1 de contrôle électronique basée sur un système d’exploitation Autosar comprenant une couche logicielle applicative 2 intégrant une architecture de tâches applicative et un microcontrôleur 5 ou 5a, l’architecture de tâches applicative servant à l’intégration du microcontrôleur 5 ou 5a dans l’unité 1 de contrôle électronique, des différentes tâches T10-T14, T20-T24, T30-T34 à remplir par l’unité 1 de contrôle électronique étant attribuées par l’architecture de tâches applicative sur un ou des coeurs CO, C1 , C2 du microcontrôleur 5 ou 5a.

L’architecture de tâches applicative de l’unité 1 de contrôle électronique est conçue conformément à un procédé de conception tel que précédemment décrit où le microcontrôleur 5, 5a a été intégré à l’unité 1 de contrôle électronique basée sur un système d’exploitation Autosar conformément à un procédé d’intégration tel que précédemment décrit.