FR 3077403 A1 20190802 FR 1850658 A 20180129 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 multicceurs 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 coeur des tâches. Le système d'exploitation Autosar est un système à architecture ouverte pour 25 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 monocceur. Dernièrement, il est apparu des microcontrôleurs comportant au moins deux 30 unités de traitement, avantageusement trois ou plus, dénommés microcontrôleurs à coeurs multiples ou multicceurs qui permettent une puissance de calcul supérieure à celle des microcontrôleurs monocceur, tout en utilisant une fréquence de fonctionnement égale à celle d'un microcontrôleur monocceur. La présente invention se rapporte aussi bien à un microcontrôleur monocceur qu'à un microcontrôleur multicceurs, bien que cette dernière 35 application soit la plus avantageuse. 2 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 5 allocation sur un coeur 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 coeur 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 10 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 15 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 coeurs. 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 20 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 25 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 coeurs mais différant par leur conception. Par exemple, pour des microcontrôleurs multicceurs présentant un même nombre de coeurs, ce ne sont pas forcément les mêmes coeurs qui remplissent les 30 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 multicceurs, le démarrage se fait toujours selon le même coeur, le plus souvent prédéterminé à l'avance, de même que 35 l'accès aux entrées et sorties du microcontrôleur. Ce coeur 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 3 les coeurs présentent diverses fonctionnalités potentielles permettant à l'utilisateur de choisir à quel coeur sera dédiée une fonctionnalité spécifique, cette fonctionnalité spécifique n'étant pas activée ou disponible sur les autres coeurs. Il est aussi sélectionné un coeur en tant que coeur de sûreté de 5 fonctionnement, de même qu'il est procédé à une duplication de coeurs pour assurer une redondance et un contrôle de sûreté. De nombreux types de microcontrôleurs multicceurs peuvent être utilisés, variant entre un microcontrôleur deux coeurs jusqu'à un microcontrôleur six coeurs. Entre des différents microcontrôleurs avec un même nombre de coeurs, ce ne sont pas 10 forcément les mêmes coeurs qui sont utilisés en tant que coeur de démarrage, coeur de communication pour entrées et sorties d'informations et coeur 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 coeurs d'un microcontrôleur à un autre de la même famille. Ceci est encore plus pertinent pour des 15 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 coeurs 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 20 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 coeur 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 30 présentant notamment le même nombre de coeurs. 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 monocceur ou multicceurs à l'unité de contrôle 35 é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 4 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 5 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 10 tâches applicative en utilisant au moins un coeur virtuel différent du ou des coeurs du microcontrôleur, les différentes tâches étant affectées respectivement sur ledit au moins un coeur virtuel et il est effectué une association dudit au moins un coeur virtuel avec le ou les coeurs du microcontrôleur sélectionné pour une attribution de tâches affectées audit au moins un coeur virtuel au coeur ou entre les coeurs du microcontrôleur sélectionné. 15 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 20 architectures des projets, la présente invention propose d'introduire une abstraction des coeurs. Cette abstraction permet un regroupement des coeurs 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 oeuvre du logiciel. 25 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 coeurs. En plus, une telle architecture de tâches applicative avec un ou des coeurs virtuels permet une permutation facilitée avec moins de reconception du logiciel quand il est passé à un nombre différent de coeurs pour un nouveau microcontrôleur ou à un autre microcontrôleur pour lequel les tâches sont allouées à d'autres coeurs. Auparavant, l'architecture de tâches applicative devait attribuer à un coeur 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 coeur 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. 5 Selon l'invention, ces activités primordiales sont confiées tout d'abord à un coeur virtuel. Il est alors possible d'associer ce coeur virtuel au coeur 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 coeur virtuel 5 avec le coeur spécifique pour ces fonctions dans un nouveau microcontrôleur a besoin d'être réactualisée. Ceci vaut aussi pour les coeurs 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 10 tâches applicative qui n'a plus besoin d'être complètement réactualisée. L'utilisation d'un ou de plusieurs coeurs virtuels aide également le programmeur de l'architecture de tâches applicative à être indépendant du ou des coeurs 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 15 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 coeur 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 coeur virtuel pourrait n'avoir aucune tâche associée donc resterait 20 inutilisé par le système d'exploitation. Un coeur virtuel est associé à un et un seul coeur réel. Cette association est souple : elle peut être aisément changée selon les besoins. Un coeur de microcontrôleur peut n'avoir aucun coeur virtuel associé. Par exemple, on peut utiliser un microcontrôleur six coeurs sur lequel trois ou quatre coeurs uniquement sont actifs ou utilisés. 25 Avantageusement, le microcontrôleur sélectionné est multicceurs, l'architecture de tâches applicative comprenant plusieurs coeurs 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 coeurs. Pour adapter un microcontrôleur différent à la place d'un autre 30 microcontrôleur, il suffit de changer l'association du coeur virtuel avec le coeur du microcontrôleur qui présente les moyens nécessaires de traitement des fonctions du coeur virtuel. Ceci aide aussi au passage d'un microcontrôleur avec un nombre de coeurs supérieurs, un nouveau coeur virtuel étant ajouté. On obtient ainsi une standardisation de l'architecture de tâches applicative. 35 Avantageusement, les tâches affectées à un coeur virtuel sont attribuées à un même coeur du microcontrôleur sélectionné. A un coeur virtuel correspond un coeur spécifique du microcontrôleur. Il est possible de paralléliser une exécution de différentes 6 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 coeurs séparés reliés par un pont, il est élaboré un groupe de coeurs 5 virtuels pour chaque groupe de coeurs du microcontrôleur, les groupes de coeurs virtuels étant indépendants les uns des autres. Les groupes de coeurs travaillent séparément. Il est donc possible d'avoir un groupe de coeurs virtuels pour chaque groupe. Avantageusement, quand le microcontrôleur sélectionné comprend au moins un coeur présentant des parties sécurisées et non sécurisées, un coeur virtuel est désigné 10 pour être associé à ce coeur sécurisé du microcontrôleur sélectionné. Comme tous les coeurs d'un microcontrôleur multicceurs peuvent avoir des propriétés et caractéristiques différentes, les coeurs virtuels présentent des propriétés et caractéristiques analogues à leur coeur du microcontrôleur associé. Tous les coeurs d'un microcontrôleur peuvent présenter différents niveaux de sécurité allant par exemple de haute sécurité à basse en 15 passant par moyenne. Les coeurs 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 multicceurs 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 20 procédé de conception, caractérisé en ce qu'il est déterminé pour chaque coeur 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 coeur du microcontrôleur est 25 associé avec le coeur 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 coeurs du microcontrôleur. Il est alors possible au concepteur du logiciel de l'architecture de tâches applicative de savoir quel est le coeur du microcontrôleur qui correspond le mieux à un coeur virtuel donné, par exemple le coeur virtuel qui remplit la fonction de coeur de 30 sûreté et de l'attribuer au coeur spécifique dédié à cette fonction dans le microcontrôleur, ce coeur pouvant être différent selon les microcontrôleurs. Il en va de même pour un coeur du microcontrôleur spécifiquement dédié au démarrage du microcontrôleur qui doit être associé au coeur virtuel dédié au démarrage et possiblement pour le coeur dédié aux communications entrées et sorties du microcontrôleur. 35 Le fournisseur de microcontrôleur peut prévoir plusieurs coeurs dotés de fonctions de sureté, de démarrage ou de communications, et l'utilisateur du 7 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. 5 Avantageusement, il est établie une affinité de coeur aussi bien pour un coeur virtuel qu'un coeur du microcontrôleur, l'affinité concernant une intégration sur un coeur du microcontrôleur, une intégration sur un coeur virtuel, une intégration sur un même coeur qu'une tâche donnée, une intégration sur un coeur dont le coeur de sûreté est actif ou qui est le coeur privilégié pour l'accès aux périphériques, ou un coeur d'un niveau de sûreté 10 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 15 é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 coeurs 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 20 tel procédé d'intégration. Avantageusement, le microcontrôleur comprend trois coeurs. Actuellement, les microcontrôleurs trois coeurs sont les plus répandus en tant que microcontrôleurs multicceurs, mais ce ne sont pas les seuls. L'invention concerne enfin un véhicule automobile caractérisé en ce qu'il 25 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 : 30 - 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 35 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. 8 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 monocceur ou multicceurs avec un nombre de coeurs différent de trois. La mention d'un coeur sans autre précision s'adresse à un coeur réel du 5 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 10 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 15 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 coeurs virtuels A0, A1, A2 que proposent l'invention et qui seront ultérieurement décrits en étant dans l'architecture de 20 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 coeurs CO, C1, C2 en tant qu'organes de traitement travaillant en parallèle pour un traitement de différentes tâches 25 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 coeur à la figure 2, mais ce nombre n'est pas limitatif en pouvant être plus élevé comme moins élevé. Les tâches forment par coeur des jeux de tâches aux propriétés bien définies. 30 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 35 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é. 9 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 5 coeur virtuel A0, A1, A2 différent du ou des coeurs CO, C1, C2 du microcontrôleur. Ceci permet une abstraction du ou des coeurs 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 coeurs CO, C1, C2 du microcontrôleur 5, 5a sont affectées respectivement sur le ou les coeurs virtuels A0, A1, A2. Il s'ensuit que l'architecture de 10 tâches applicative est au départ élaborée en complète indépendance des coeurs 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 coeurs CO, C1, C2 15 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. 20 Il est ensuite effectué une association du ou des coeurs virtuels A0, A1, A2 avec le ou les coeurs 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 coeur virtuel A0, A1, A2 au coeur ou entre les coeurs CO, C1, C2 du microcontrôleur 5, 5a sélectionné. Un coeur virtuel A0, A1, A2 correspond à un coeur du microcontrôleur CO, C1, 25 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 coeurs CO, C1, C2 présentant des propriétés différentes, par exemple ne présentant pas le même niveau de sûreté. 30 Les coeurs virtuels A0, A1, A2 peuvent être utilisés lors de l'intégration de différentes applications à un système à un coeur ou à plusieurs coeurs 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 35 trois coeurs CO, C1, C2, des tâches T10-T14, T20-T24, T30-T34 ont été réparties sur trois coeurs virtuels A0, 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, 10 T20-T24, T30-T34. Les coeurs virtuels A0, 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 coeur réel qui convient le mieux à un coeur virtuel A0, A1, A2 spécifique et qui peut occuper une place différente dans l'arrangement des trois coeurs CO, C1, C2 dans le 5 microcontrôleur 5, 5a donné. Le coeur virtuel AO peut correspondre à un coeur à haute sécurité pouvant remplir la fonction de coeur de sûreté aussi appelé checker core en langue anglo-saxonne. Les deux autres coeurs virtuels restants sont référencés Al et A2. Seulement dans un but illustratif et non limitatif, pour un premier 10 microcontrôleur référencé 5, le coeur de sûreté est le coeur 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 coeur de sûreté est le coeur référencé C1 différent du coeur de démarrage qui est le coeur CO. C'est donc pour ce deuxième microcontrôleur 5a le coeur C1 qui est associé au coeur virtuel A0. Une adaptation au deuxième microcontrôleur 5a de 15 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 coeurs virtuels A0, A1, A2 avec respectivement un coeur 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. 20 Il peut y avoir des microcontrôleurs avec des possibilités de sélection d'un coeur de sûreté parmi plusieurs coeurs aptes à exercer ce rôle, l'utilisateur disposant d'une telle possibilité de sélection. Le coeur de sûreté ainsi sélectionné est associé au coeur virtuel dédié à la sûreté. Comme exemple non limitatif d'un ensemble de coeurs virtuels A0, A1, A2 25 adaptés à un microcontrôleur 5, 5a spécifique, il peut être cité un coeur virtuel AO sécurisé en entrée et en sortie avec des partitions sécurisées ou non, un coeur virtuel de communication non sécurisé et un coeur alternatif non sécurisé qui correspondent respectivement à des coeurs réels d'un microcontrôleur 5, 5a trois coeurs, ce qui est un exemple non limitatif d'un microcontrôleur 5, 5a multicceurs dans le sens de la présente 30 invention. Ainsi, quand le microcontrôleur 5, 5a sélectionné est multicceurs CO, C1, C2, l'architecture de tâches applicative peut comprendre plusieurs coeurs virtuels A0, A1, A2, avec autant de coeurs virtuels A0, A1, A2 que le microcontrôleur 5, 5a possède de coeurs CO, C1, C2. Les tâches T10-T14, T20-T24, T30-T34 affectées à un coeur virtuel A0, A1, 35 A2 peuvent être attribuées à un même coeur CO, C1, C2 du microcontrôleur 5, 5a sélectionné. 11 De plus en plus de microcontrôleurs 5, 5a présentent des groupes de coeurs 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 coeurs CO, C1, C2 séparés reliés par un pont, il est 5 élaboré un groupe de coeurs virtuels A0, A1, A2 pour chaque groupe de coeurs CO, C1, C2 du microcontrôleur 5, 5a, les groupes de coeurs virtuels A0, A1, A2 étant indépendants les uns des autres. Par exemple, pour n groupes ou plus de trois coeurs CO, C1, C2 dans un microcontrôleur 5, 5a, il peut être élaboré des groupes A0, A1, A2 puis BO, B1, B2 et ainsi de suite jusqu'à une énième lettre, ce qui n'est pas représenté à la figure 2. 10 Un coeur virtuel A0, 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 coeur virtuel A0, 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 15 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 20 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 coeurs virtuels A0, 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 coeurs virtuels A0, A1, A2 en fonction de ces critères. 25 Quand le microcontrôleur 5, 5a sélectionné comprend au moins un coeur CO ou C1 présentant des parties sécurisées et non sécurisées, un premier coeur virtuel AO peut être désigné pour être associé à ce coeur sécurisé CO ou C1 du microcontrôleur 5, 5a sélectionné, ce premier coeur virtuel étant le coeur AO précédemment illustré à la figure 2 en présentant virtuellement des parties sécurisées et 30 non sécurisées. Un tel coeur virtuel AO peut donc être associé à un coeur 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 multicceurs 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 35 procédé de conception. Il est déterminé pour chaque coeur CO, C1, C2 du microcontrôleur 5, 5a ses caractéristiques relatives à sa capacité à effectuer un contrôle en exécutant en parallèle 12 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 5 microcontrôleur 5, 5a. Le fournisseur peut proposer plusieurs combinaisons de coeurs spécifiques pour un même microcontrôleur, l'utilisateur du microcontrôleur pouvant choisir un coeur entre plusieurs coeurs aptes à devenir un coeur de sûreté, un coeur de démarrage ou un coeur de communication en entrées et en sorties. A chaque coeur CO, C1, C2 du microcontrôleur 5, 5a est associé un coeur 10 virtuel A0, A1, A2 qui lui est le plus proche au niveau des caractéristiques, chaque coeur virtuel A0, 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 15 figure 2, le coeur CO du premier microcontrôleur 5 est sécurisé et apte à remplir la fonction de coeur de sûreté, mais est aussi apte à effectuer le démarrage du microcontrôleur 5 tandis que le coeur Cl du deuxième microcontrôleur 5a est sécurisé et apte à remplir la fonction de coeur de sûreté mais n'est pas apte à effectuer le démarrage. L'association avec un coeur virtuel A0, A1, A2 se fera pour les deux coeurs CO, C1, C2 20 des deux microcontrôleurs 5, 5a avec un coeur 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 coeur, le coeur pouvant être soit virtuel ou réel. Cette affinité de coeur sera vérifiée, de façon outillée, au moment de l'intégration sur les différents projets. 25 Par exemple, l'affinité de coeur peut s'exprimer de différentes façons comme une intégration sur un coeur réel du microcontrôleur, une intégration sur un coeur virtuel, une intégration sur un même coeur qu'une fonction donnée, une intégration sur un coeur dont le coeur de sûreté est actif ou qui est le coeur privilégié pour l'accès aux périphériques ou un coeur d'un niveau de sûreté donné, etc. 30 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 coeur et non par rapport à un coeur 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 35 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, 13 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 5 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 REVENDICATIONS1. 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) comportant un ou plusieurs coeurs (CO, C1, C2) en tant qu'organes de traitement travaillant en parallèle pour une exécution de différentes tâches (T10-T14, T20-124, T30-T34) du système d'exploitation par l'unité (1) de contrôle électronique, une couche logicielle de base servant à la connexion avec un 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) du système d'exploitation à exécuter 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é, caractérisé en ce que, préalablement à une association avec un microcontrôleur (5, 5a) sélectionné, il est procédé à une élaboration de l'architecture de tâches applicative en utilisant au moins un coeur virtuel (A0, A1, A2) différent du ou des coeurs (CO, C1, C2) du microcontrôleur (5, 5a), les différentes tâches (T10-114, T20-T24, T30-T34) étant affectées respectivement sur ledit au moins un coeur virtuel (A0, A1, A2), et il est effectué une association dudit au moins un coeur virtuel (A0, A1, A2) avec le ou les coeurs (CO, C1, C2) du microcontrôleur (5, 5a) sélectionné pour une attribution de tâches (T10-T14, T20-T24, T30-T34) affectées audit au moins un coeur virtuel (A0, A1, A2) au coeur ou entre les coeurs (CO, C1, C2) du microcontrôleur (5, 5a) sélectionné. 2. Procédé de conception selon la revendication précédente, caractérisé en ce que le microcontrôleur (5, 5a) sélectionné est multicceurs (CO, C1, C2), l'architecture de tâches applicative comprenant plusieurs coeurs virtuels (A0, A1, A2). 3. Procédé de conception selon la revendication précédente, caractérisé en ce que les tâches (T10-T14, T20-T24, T30-T34) affectées à un coeur virtuel (A0, A1, A2) 25 sont attribuées à un même coeur (CO, C1, C2) du microcontrôleur (5, 5a) sélectionné. 4. Procédé selon l'une quelconque des revendications 2 ou 3, caractérisé en ce que, quand le microcontrôleur (5, 5a) sélectionné comprend au moins deux groupes de coeurs (CO, C1, C2) séparés reliés par un pont, il est élaboré un groupe de coeurs virtuels (A0, A1, A2) pour chaque groupe de coeurs (CO, C1, C2) du 30 microcontrôleur (5, 5a), les groupes de coeurs virtuels (A0, A1, A2) étant indépendants les uns des autres. 5. Procédé de conception selon l'une quelconque des revendications 2 à 4, caractérisé en ce que, quand le microcontrôleur (5, 5a) sélectionné comprend au moins un coeur présentant des parties sécurisées et non sécurisées en formant un coeur de 15 sûreté (CO ou C1), un coeur virtuel (A0) est désigné pour être associé à ce coeur de sûreté (CO ou C1) du microcontrôleur (5, 5a) sélectionné. 6. Procédé d'intégration d'un microcontrôleur (5, 5a) multicceurs dans une unité (1) de contrôle électronique basée sur un système d'exploitation Autosar 5 comprenant une couche de base (4) logicielle conçue conformément à un procédé de conception selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il est déterminé pour chaque coeur (CO, C1, C2) du microcontrôleur (5, 5a) ses caractéristiques relatives à sa capacité à effectuer un contrôle par exécution redondante du logiciel, son niveau de sûreté, sa capacité à effectuer un démarrage du 10 microcontrôleur (5, 5a), sa capacité à accéder aux périphériques d'entrée et de sortie du microcontrôleur, et chaque coeur (CO, C1, C2) du microcontrôleur (5, 5a) est associé avec le coeur virtuel (A0, A1, A2) qui lui est le plus proche au niveau des caractéristiques. 7. Procédé d'intégration selon la revendication précédente, caractérisé en ce qu'il est établi un ordre de priorité entre les caractéristiques, la capacité à effectuer un 15 contrôle étant prioritaire. 8. Procédé d'intégration selon l'une quelconque des deux revendications précédentes, caractérisé en ce qu'il est établi une affinité de coeur aussi bien pour un coeur virtuel qu'un coeur du microcontrôleur, l'affinité concernant une intégration sur un coeur réel du microcontrôleur, une intégration sur un coeur virtuel, une intégration sur un 20 même coeur qu'une tâche donnée, une intégration sur un coeur dont le coeur de sûreté est actif ou qui est le coeur privilégié pour l'accès aux périphériques ou un coeur d'un niveau de sûreté donné. 9. Unité (1) de contrôle électronique basée sur un système d'exploitation Autosar comprenant une couche logicielle applicative (2), une couche de base (4) logicielle et un microcontrôleur (5, 5a), une architecture de tâches applicative, intégrée dans la couche logicielle applicative (2), la couche de base (4) logicielle servant à une connexion avec le microcontrôleur (5, 5a) 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 un ou des coeurs (CO, C1, C2) du microcontrôleur (5, 5a), caractérisé en ce que l'architecture de tâches applicative de l'unité (1) de contrôle électronique est conçue conformément à un procédé selon l'une quelconque des revendications 1 à 5, ou en ce que le microcontrôleur (5, 5a) a été intégré à l'unité (1) de contrôle électronique conformément à un procédé d'intégration selon l'une quelconque des revendications 6 à 8. 16 10. Unité (1) de contrôle électronique selon la revendication précédente, caractérisée en ce que le microcontrôleur (5, 5a) comprend trois coeurs (CO, C1, C2). 11. Véhicule automobile caractérisé en ce qu'il comprend au moins une unité (1) de contrôle électronique basée sur un système d'exploitation Autosar selon l'une 5 quelconque des deux revendications précédentes.