FR 3057840 A1 20180427 FR 1660236 A 20161021 1 L'invention concerne un procédé de traitement de données de position d'un moteur de véhicule automobile mis en oeuvre par un calculateur électronique multi-coeurs. L'invention s'applique notamment à la gestion d'une perte de synchronisation du calculateur électronique par rapport à la position du moteur, ou à la gestion de modes 5 de fonctionnement du moteur pour lesquels des commandes de pilotage du moteur doivent être interrompues, telles qu'un fonctionnement du moteur en rotation inverse ou une reprise du moteur après une interruption temporaire destinée à économiser du carburant (interruption « Stop and Start »). Un calculateur électronique de véhicule automobile est classiquement un 10 microcontrôleur comprenant au moins un module logiciel de pilotage du moteur du véhicule automobile, adapté par exemple pour piloter l'injection de carburant, l'allumage du carburant, etc. Les commandes réalisées par les modules de pilotage du moteur doivent être synchronisées à la position angulaire du moteur pour permettre un bon fonctionnement de 15 ce dernier. Pour réaliser la synchronisation du pilotage du moteur à la position angulaire de celui-ci, le calculateur électronique comprend également un module logiciel de production de données de position angulaire du moteur, et un compteur angulaire commandé par le module de production de données. Le compteur angulaire est un 20 compteur fixe de résolution angulaire fixée, de sorte que chaque coup compté par le compteur correspond à une valeur d'angle fixe du vilebrequin du moteur. Le module logiciel de production de données de position angulaire du moteur est en outre adapté pour recevoir, en provenance de capteurs dédiés, des informations concernant la position du vilebrequin et de l'arbre à came du moteur. 25 A partir de ces informations, ce module détermine une position de référence du moteur correspondant à une valeur nulle d'angle du vilebrequin du moteur. En référence à la figure 1, cette valeur de référence associée au comptage par le compteur angulaire permet d'associer à chaque position angulaire du compteur angulaire une position angulaire correspondante du moteur, et donc de déterminer une position 30 angulaire du moteur à chaque instant en fonction de celle du compteur angulaire. Ceci permet de synchroniser des commandes de pilotage du moteur à la position angulaire de celui-ci. Dans certaines circonstances il peut arriver que la synchronisation entre la position du moteur et la position du compteur angulaire soit perdue. C'est le cas par 3057840 2 exemple si des données relevées par les capteurs de position du vilebrequin ou de l'arbre à came du moteur sont erronées, ou en cas de calage du moteur, etc. Dans ces cas, la position angulaire du moteur ne peut plus être déterminée à partir de celle du compteur angulaire. Il s'ensuit un risque que des commandes générées par les modules logiciels de pilotage du moteur (par exemple allumage du carburant) soient exécutées à des moments inappropriés par rapport à la position réelle du moteur. Ceci peut fortement dégrader le moteur. Il est donc connu, en cas de perte de synchronisation du moteur, de figer le compteur angulaire afin de protéger le moteur, et d'arrêter l'exécution des commandes 10 par les modules logiciels de pilotage du moteur avant de réinitialiser le compteur angulaire. Pour ce faire, une commande de désactivation est typiquement envoyée par le module de production de données à ces modules dès qu'une perte de synchronisation est détectée. Puis, une fois les commandes désactivées, une nouvelle synchronisation du 15 moteur est lancée en réinitialisant le compteur angulaire, c'est-à-dire en le faisant redémarrer à une position angulaire initiale nulle. Classiquement, les microcontrôleurs utilisés en tant que calculateurs électroniques de véhicules automobiles sont des microcontrôleurs mono-coeur, c'est-à-dire que le microcontrôleur ne comprend qu'un seul coeur physique, ou encore un seule 20 ensemble de circuits électroniques, permettant d'exécuter les différentes applications logicielles du microcontrôleur. Dans le cas de microcontrôleurs mono-coeur, une série de commandes est exécutée de manière séquentielle et synchrone. De ce fait, l'implémentation par le microcontrôleur d'une fonction d'arrêt de commande des modules de pilotage avant de 25 mettre en oeuvre une nouvelle synchronisation du moteur implique que les commandes sont nécessairement arrêtées au moment où une nouvelle synchronisation a lieu et où le compteur angulaire est réinitialisé. Or, certains microcontrôleurs de véhicules automobiles ont désormais des structures multi-coeurs, c'est-à-dire qu'ils comprennent plusieurs modules physiques ou 30 coeurs indépendants, qui sont adaptés pour exécuter des programmes en parallèle de façon totalement autonome. Ce caractère multi-coeurs supprime le caractère séquentiel de l'implémentation des fonctions par le microcontrôleur. En particulier, le fait de faire suivre une commande de désactivation des modules de pilotage du moteur d'une commande de 35 réinitialisation du compteur angulaire ne permet pas de garantir, lors du redémarrage du compteur angulaire, que les modules de pilotage ont été effectivement désactivés. 3057840 3 Il en résulte un risque que des commandes soient lancées par les modules de pilotage du moteur après une réinitialisation du compteur angulaire, et que ces commandes soient complètement désynchronisées de la position angulaire du moteur, et causent des dégradations de ce dernier. 5 Par ailleurs, la resynchronisation du moteur doit avoir lieu le plus vite possible après la perte de synchronisation et il n'est pas envisageable d'attendre un laps de temps long pour s'assurer que l'ensemble des modules de pilotage du moteur sont désactivés. L'invention a pour but de proposer une solution à la perte de synchronisation du moteur dans le cas d'un calculateur électronique multi-coeurs. En particulier, un but de l'invention est de permettre de garantir la désactivation des commandes des modules de pilotage du moteur avant de réinitialiser un compteur angulaire en cas de perte de synchronisation du moteur. Un autre but de l'invention est de permettre une désactivation rapide des modules de pilotage du moteur dans d'autres circonstances où il n'y a pas de pertes de synchronisation du moteur mais où le fonctionnement de celui-ci peut générer des déclenchements inadaptés de commandes (par exemple en cas de rotation inverse ou après une interruption temporaire du moteur). Un autre but de l'invention est de permettre une désactivation rapide des modules de pilotage du moteur lorsque la position du moteur déterminée par le module de 20 production n'est pas valide. A cet égard, l'invention a pour objet un procédé de traitement de données de position d'un moteur de véhicule automobile, mis en oeuvre par un calculateur électronique multi-coeurs comprenant : - un module logiciel de production de données de position angulaire du moteur, et 25 - au moins un module logiciel de pilotage du moteur en fonction des données de position angulaire, le procédé comprenant une étape de désactivation de chaque module de pilotage par le module de production de données de position angulaire, suivie d'une étape d'activation de chaque module de pilotage par le module de production, caractérisé en ce que : 30 - au cours l'étape de désactivation, le module de production envoie à chaque module de pilotage une commande de désactivation, puis une requête de confirmation que chaque module de pilotage est désactivé, et - l'étape d'activation des modules de pilotage n'est mise en oeuvre que lorsque la désactivation de tous les modules de pilotage a été confirmée au module de 35 production. Avantageusement, mais facultativement, le procédé selon l'invention peut en outre comprendre au moins l'une des caractéristiques suivantes : 3057840 4 - L'étape de désactivation peut comprendre en outre au moins une répétition de l'envoi d'une requête de confirmation de la désactivation des modules de pilotage si au moins un module de pilotage n'a pas confirmé sa désactivation. - La répétition de l'envoi de la requête de confirmation de la désactivation des 5 modules de pilotage peut être mise en oeuvre dans un délai compris entre 5 et 20 ms, de préférence égal à 10 ms, après l'envoi de la première requête de confirmation. - Le procédé peut comprendre en outre une étape de réinitialisation du calculateur électronique si le module de production ne reçoit pas d'information de 10 confirmation d'un état désactivé de chaque module de pilotage après la ou les répétitions de l'envoi de la commande de désactivation, et l'étape d'activation des modules de pilotage est mise en oeuvre après l'étape de réinitialisation du calculateur électronique. - Le calculateur électronique peut comprendre un compteur angulaire, et le module 15 logiciel de production de données de position du moteur est adapté pour, à partir d'informations de position angulaire d'un vilebrequin et d'un arbre à cames du moteur, générer une position angulaire de référence du moteur, et dans lequel : l'étape de désactivation est précédée d'un arrêt du compteur angulaire, et l'étape de réactivation est précédée d'une étape de réinitialisation du compteur angulaire et de calcul d'une nouvelle position angulaire de référence du moteur, mise en oeuvre lorsque le module de production a reçu l'information de confirmation de l'état désactivé de chaque module de pilotage. - Chacun du module logiciel de production de données et de chaque module logiciel de pilotage du moteur peut comprendre une couche logicielle bas niveau et une couche logicielle applicative, et l'envoi d'une commande de désactivation par le module de production à chaque module de pilotage comprend : l'envoi d'une commande de désactivation par la couche logicielle applicative du module de production à la couche logicielle applicative de chaque module de pilotage, suivie de l'envoi d'une commande de désactivation par la couche logicielle applicative de chaque module de pilotage à la couche logicielle bas-niveau respective. - Chacun du module logiciel de production de données et de chaque module logiciel de pilotage du moteur du calculateur comprenant une couche logicielle bas niveau et une couche logicielle applicative, et la couche logicielle bas niveau de chaque module logiciel de pilotage étant adaptée pour adopter un état 3057840 5 « actif », un état « passif » et un état « suspendu », la réception d'une commande de désactivation par un module de pilotage peut entraîner la transition dudit module de l'état « actif » ou de l'état « suspendu » à l'état « passif ». 5 - Le procédé peut en outre comprendre en outre une étape supplémentaire de désactivation rapide mise en oeuvre avant l'étape de désactivation, comprenant l'envoi d'une commande de désactivation rapide de la couche logicielle bas niveau du module de production de données directement à la couche logicielle bas niveau de chaque module de pilotage du moteur. 10 - La réception d'une commande de désactivation rapide par un module de pilotage entraîne la transition dudit module de l'état « actif » à l'état « suspendu ». - Le procédé peut comprendre en outre une étape supplémentaire mise en oeuvre avant l'étape de désactivation, au cours de laquelle la couche logicielle bas niveau de chaque module de pilotage du moteur passe d'un état « actif » à un 15 état « suspendu » lorsqu'une valeur de référence de position du moteur fournie par le module de production est erronée. Selon un autre objet, l'invention concerne un calculateur électronique multicoeurs de véhicule automobile comprenant : - un module logiciel de production de données de position du moteur, et 20 - au moins un module logiciel de pilotage du moteur en fonction des données de position, caractérisé en ce qu'il est adapté pour mettre en oeuvre le procédé selon la description qui précède. Le procédé proposé permet, par la confirmation auprès du module de 25 production des données de position angulaire du moteur du fait que les modules de pilotage ont bien été désactivés, d'éviter un déclenchement inapproprié de commandes du moteur par un calculateur électronique multi-coeurs, lors d'une réactivation ultérieure de ces modules de pilotage. Ceci est applicable notamment en cas de perte de synchronisation du moteur, 30 et permet de garantir l'arrêt des commandes exécutées par les modules de pilotage du moteur avant la réinitialisation du compteur angulaire. Ceci est également applicable lors d'une rotation inverse du moteur ou lors d'une phase de fonctionnement en veille comprenant une interruption temporaire du moteur destinée à économiser du carburant (mode « Stop and Start »), même si la 35 synchronisation du moteur n'a pas été perdue. La possibilité pour les couches logicielles bas niveau des modules de pilotage du moteur d'adopter un étant transitoire « suspendu » en plus d'états « actif » et 3057840 6 « passif » permet également une plus grande réactivité du calculateur à des circonstances impliquant l'arrêt des commandes, tout en sécurisant le fonctionnement du calculateur. D'autres caractéristiques et avantages de la présente invention apparaîtront à 5 la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : - La figure 1, déjà décrite, représente la position du moteur synchronisée avec le compteur angulaire, - La figure 2, représente schématiquement un calculateur électronique de 10 véhicule automobile, - Les figures 3a à 3c représentent différentes mises en oeuvre d'une étape de désactivation des modules de pilotage en cas d'une perte de synchronisation du moteur, - Les figures 4a et 4b représentent deux modes de réalisation d'une étape 15 d'envoi de commande de désactivation des modules de pilotage du moteur, - La figure 5 représente une machine à état de la couche bas niveau des modules de pilotage du moteur, - La figure 6 représente schématiquement les principales étapes d'un procédé de traitement de données, 20 - La figure 7 est un logigramme représentant schématiquement un exemple détaillé d'un procédé de traitement de données selon un mode de réalisation de l'invention, - Les figures 8a à 8g représentent les états adoptés par les modules logiciels du calculateur électronique lors de l'implémentation des différentes étapes du 25 procédé de traitement. Calculateur électronique multi-coeurs En référence à la figure 2, on a représenté schématiquement un calculateur 1 électronique de véhicule automobile. Le calculateur électronique 1 est typiquement un microcontrôleur, mais en variante pourrait être un circuit intégré de type ASIC, un 30 microprocesseur ou un processeur couplé à une horloge, une mémoire et des interfaces de communication. Dans tous les cas, le calculateur électronique 1 est de type multi-coeurs, c'est- à-dire qu'il comprend un processeur comprenant plusieurs coeurs physiques, c'est-à-dire plusieurs circuits capables d'exécuter des programmes de façon autonomes. 35 Le processeur du calculateur électronique est adapté pour exécuter des instructions de programme correspondant à différentes fonctionnalités à exécuter. En particulier, le processeur est adapté pour exécuter des instructions de programme 3057840 7 correspondant à un module logiciel 10 de production de données de position angulaire du moteur du véhicule, et une pluralité de modules logiciels 20 de pilotage du moteur en fonction de données de position produites par le module 10. Les modules 20 de pilotages comprennent par exemple un module de pilotage des injecteurs du moteur du véhicule, 5 un module de pilotage de l'allumage du carburant, etc. Les instructions de programme pour l'exécution des modules logiciels 10, 20 sont installées sur une mémoire dédiée du calculateur électronique. Dans la suite, on parlera plus simplement des modules logiciels 10, 20 du calculateur électronique. Le module logiciel 10 est adapté pour recevoir en entrée, d'un capteur 2 de 10 mesure de la position angulaire du vilebrequin du moteur, une valeur de position angulaire du vilebrequin comprise entre 0 et 720° ou 0 et 720degré CRK. Avantageusement, le module logiciel 10 est également adapté pour recevoir en entrée, d'un capteur 3 de mesure de la position angulaire de l'arbre à came du moteur, une valeur de position angulaire de l'arbre à came comprise entre 0 et 360°. 15 Un cycle moteur correspondant à deux tours de vilebrequin, le croisement des informations de position angulaire du vilebrequin et de la came par le module logiciel 10 de production de données permet de déterminer la position angulaire exacte du moteur. A cet effet, le module logiciel 10 de production de données de position est également adapté pour générer une position angulaire de référence du moteur à partir 20 des informations fournies par les capteurs 2 et le cas échéant 3. Typiquement, cette position angulaire de référence est une position angulaire nulle du moteur, correspondant au démarrage d'un cycle. Cette position angulaire est appelée TDCO. Dans la suite, on appelle synchronisation le fait pour le module 10 de production de données de générer la valeur de la position angulaire de référence TDCO à 25 partir des capteurs 2 et 3. De plus, pour que les modules logiciel 20 de pilotage du moteur puissent exploiter la position angulaire du moteur, le calculateur électronique 1 comprend en outre un compteur angulaire 30, qui est avantageusement un compteur libre (ou free running timer) adapté pour compter un nombre de coups entre 0 et une valeur maximale, tel que 30 chaque coup correspond à une résolution angulaire fixe. Le compteur angulaire 30 est piloté par le module logiciel 10 de production de données. En particulier, le module logiciel 10 de production de données est adapté pour démarrer, arrêter, et remettre à zéro le compteur angulaire 30. Chaque module 20 de pilotage du moteur reçoit du module logiciel 10 de 35 production de données la valeur de la position angulaire de référence TDCO, et est en outre adapté pour exécuter, en fonction de cette valeur et de la position du compteur 3057840 8 angulaire, des commandes d'actionneurs du moteur de manière synchronisée avec celui-ci. En effet, comme sur la figure 2 présentée ci-avant, la mise en correspondance de la position de référence du moteur et du compteur angulaire permet de déduire, en 5 soustrayant du nombre de coups comptés par le compteur angulaire le nombre de coups correspondant à la position de référence, la position angulaire absolue du moteur. La position du compteur angulaire peut être exploitée d'autres manières, par exemple pour calculer le moment à laquelle une commande doit être envoyée par un module 20 de pilotage, en fonction d'une position angulaire cible correspondante du moteur. 10 A cet égard, les modules de pilotage 20 sont avantageusement adaptés pour communiquer avec des modules additionnels (non représentés) du calculateur électronique 1, ayant pour fonction de lire la position angulaire du compteur angulaire 30 et d'exploiter ladite position à partir de la position angulaire de référence du moteur TDCO. Les modules additionnels peuvent ensuite retourner aux modules de pilotage 20 des 15 informations permettant la mise en oeuvre des commandes d'actionneurs de manière synchronisée avec le moteur. On connaît par exemple comme module additionnel un module matériel de comparaison de valeur angulaire, ou des modules logiciels de type PMT (pour l'acronyme anglais « Position Minus Timer ») ou ATD (pour l'acronyme anglais « Angle Time Driver »). 20 Chaque module logiciel 10, 20 comprend une couche logicielle dite bas niveau (également appelé Basic Software, en anglais) BSW10,20, et une couche logicielle applicative ASW10,20- La couche logicielle bas niveau BSW10 du module 10 de production de données est la couche logicielle par laquelle le module 10 communique avec les capteurs 25 2 et 3 pour recevoir les données de position du vilebrequin et de l'arbre à came, et par laquelle le module 10 envoie des instructions de commande au compteur angulaire. La couche logicielle applicative ASW10 du module 10 est la couche permettant au module de produire la position de référence TDCO, à partir des informations reçues par les capteurs 2 et 3 et transmises par la couche bas niveau BSW10. 30 La couche logicielle applicative ASW20 d'un module 20 est la couche fournissant des consignes en angles pour la commande d'actionneurs du moteur à la couche bas niveau BSW du module 20. La couche logicielle bas niveau BSW20 d'un module 20 de pilotage du moteur est la couche logicielle recevant la valeur de la position de référence TDCO et 35 convertissant, à partir de celle-ci, les consignes en angle vers des consignes en valeurs de compteur angulaire. C'est également la couche logicielle par laquelle le module 20 3057840 9 communique avec un actionneur du moteur (par exemple un injecteur, une bougie) pour le commander. La structure de ces couches logicielles est visible par exemple sur les figures 4a, 4b et 8a à 8g. 5 Chaque couche logicielle d'un module 10, 20 est en outre adaptée pour présenter un nombre fini d'états qui seront décrits plus en détails ci-après. En particulier, la couche applicative et la couche bas niveau de chaque module 20 de pilotage du moteur est adaptée pour présenter un état EP1 dit « actif », et un état EP2 dit « passif ». Lorsque la couche applicative ASW20 et la couche bas niveau 10 BSW20 d'un module présentent l'état actif, alors le module 20 exécute des instructions de commande du moteur 20. Lorsque la couche bas niveau BSW20 présente l'état passif, les commandes du module 20, incluant les commandes des actionneurs du moteur, ainsi que les commandes de modules additionnels visant à exploiter la position du compteur angulaire 30, sont annulées. 15 La couche applicative ASW10 et la couche bas niveau BSW10 du module 10 de production de données est adaptée pour présenter : - un état ED1 dit « désactivé » ou passif, typiquement lors d'un démarrage du moteur ou d'une réinitialisation du module, avant une synchronisation du moteur, - un état ED2 dit « synchonisation en cours », lors de laquelle le module 10 est 20 actif et recherche la position angulaire du moteur pour calculer la valeur de référence TDCO à partir des valeurs des capteurs 2 et 3, et - un état ED3 dit « position moteur disponible », qui correspond à un état actif du module une fois que la position angulaire de référence du moteur TDCO a été calculée. 25 Avantageusement, mais facultativement, un état supplémentaire ED4 dit de « synchronisation suspendue » est prévu pour les couches logicielles du module 10 de production de données, et un état supplémentaire EP3 dit « suspendu » est prévu pour les couches logicielles bas niveau BSW20 des modules 20 de pilotages. Ces états et leur fonctionnement est décrit plus en détails ci-après. 30 Désactivation des modules de pilotage - cas de la perte de synchronisation En référence à la figure 6, on va maintenant décrire un procédé de traitement de données de position du moteur mis en oeuvre par le calculateur électronique 1 décrit ci-avant. Ce procédé comprend une première étape 100 de désactivation des modules 35 logiciels 20 de pilotage du moteur par le module logiciel 10 de production de données. La désactivation 100 comprend l'envoi 110 d'une commande de désactivation « ExitSyn » du module 10 de production de données à chaque module 20 de pilotage du 3057840 10 moteur. La commande de désactivation permet de faire passer l'état de la couche bas niveau BSW20 de chaque module 20 de pilotage du moteur d'actif à passif, et donc d'annuler toutes les commandes générées par le module 20. En particulier, l'étape 110 d'envoi d'une commande comprend la série de 5 commandes suivantes : - la couche applicative du module 10 communique une instruction de désactivation à la couche logicielle applicative ASW20 de chaque module 20 de pilotage du moteur, et - la couche logicielle applicative ASW20 de chaque module 20 passe à l'état passif 10 et communique une instruction de désactivation à la couche bas niveau correspondante BSW20 du module 20. L'étape 100 de désactivation des modules 20 est avantageusement, mais non limitativement, mise en oeuvre en cas de perte de synchronisation entre le compteur angulaire 30 et la position angulaire du moteur. Une telle perte de synchronisation peut 15 survenir par exemple en cas de calage du moteur, de panne ou d'erreur de mesure de l'un des capteurs 2 et 3. La perte de synchronisation peut être détectée par la couche logicielle bas niveau BSW10 ou par la couche logicielle applicative ASW10 du module 10 de production de données qui communique alors l'information à la couche logicielle bas niveau. 20 Dans ce cas d'une perte de synchronisation, le procédé comprend la mise en oeuvre, avant l'étape 100, d'une étape 90 au cours de laquelle la couche bas niveau du module 10 fige le compteur angulaire 30, et passe la valeur de la position angulaire de référence TDCO du moteur à invalide. Ceci permet de protéger le moteur en empêchant l'implémentation de commandes exploitant la position du compteur angulaire. 25 Il est nécessaire, pour reprendre un fonctionnement normal à la suite de la perte de synchronisation, de redémarrer le compteur angulaire 30 et pour ce faire de le réinitialiser à une valeur initiale nulle. Avant de réinitialiser le compteur angulaire 30, il est impératif de désactiver les modules logiciels 20 de pilotage pour arrêter l'envoi de commande aux actionneurs du 30 moteur. En effet, le déclenchement des commandes lors du redémarrage du compteur angulaire 30 serait désynchronisé avec le moteur et pourrait provoquer des défauts de fonctionnement ou des dégradations du moteur. Or, dans le cas d'un calculateur électronique multi-coeurs 1, l'envoi d'une instruction de désactivation de la couche logicielle bas niveau BSW20 de chaque module 35 20, avant la mise en oeuvre d'une étape de réactivation 200 de chaque module 20, ne garantit pas que les modules soient effectivement inactivés et en particulier que les commandes respectives générées par les modules soient annulées. 3057840 11 Par conséquent, l'étape de désactivation 100 comprend en outre une étape 120 d'envoi à chaque module de pilotage 20, par le module 10 de production de données, d'une requête de confirmation que le module correspondant 20 est bien désactivé, c'est-à-dire que toutes ses commandes ont été annulées. 5 Cette requête est une requête synchrone de sorte que le module 10 reçoit immédiatement une réponse de chaque module de pilotage. Avantageusement, l'étape 120 est mise en oeuvre à l'issue d'un délai déterminé, compris entre 5 et 20 ms, par exemple égal à 10 ms, après l'envoi 110 de la commande de désactivation. 10 Lorsque tous les modules de pilotage 20 ont confirmé leur désactivation, le procédé comprend ensuite une étape 200 de réactivation de chaque module de pilotage 20, qui comprend l'envoi, par le module 10 de production de données, d'une commande de réactivation de chaque module de pilotage 20 pour que la couche applicative ASW20, puis la couche bas niveau BSW20 de chaque module de pilotage 20 adopte l'état actif. 15 Dans le cas où l'étape 100 a été mise en oeuvre à cause d'une perte de synchronisation, le procédé comprend en outre une étape 190 préalable à l'étape 200 au cours de laquelle la couche bas niveau BSW10 du module 10 réinitialise le compteur angulaire 30, c'est-à-dire le redémarre à partir de la valeur initiale 0, recalcule la valeur de la position angulaire de référence du moteur TDCO et la renvoie aux modules de pilotage 20 20. En revanche, si en réponse à la requête de confirmation 120, au moins un module de pilotage 20 a indiqué au module de production de données 10 que toutes ses commandes n'étaient pas annulées, le procédé comprend avantageusement la répétition, un nombre déterminé de fois supérieur ou égal à un, de l'étape 120. Cette répétition est 25 mise en oeuvre à l'issue d'un délai déterminé écoulé à partir de la précédente mise en oeuvre de l'étape 120, le délai étant par exemple compris entre 5 et 20 ms, avantageusement égale à 10 ms. Dans le cas où, à l'issue de la mise en oeuvre répétée de l'étape 120, tous les modules 20 de pilotage n'ont pas confirmé leur désactivation, le procédé comprend une 30 étape 300 de réinitialisation du calculateur électronique 1. Lors de cette réinitialisation, toutes les couches logicielles de tous les modules sont forcées à passer à l'état « passif » ou « désactivé » et le compteur angulaire est également réinitialisé. Sur les figures 3a à 3c, on a représenté en abscisse le temps et en ordonnée la valeur du compteur angulaire 30. 35 En référence à la figure 3a, on a ainsi représenté un exemple de mise en oeuvre du procédé dans lequel, au moment d'une perte de synchronisation, le compteur angulaire 30 étant figé, la commande de désactivation est envoyée à l'étape 110. 3057840 12 A l'issue d'une temporisation de 10 ms, une requête 120 de confirmation de désactivation est envoyée par le module de production de données 10 à chaque module 20 de pilotage, et chaque module 20 confirme sa désactivation. Le procédé comprend alors une réinitialisation 190 du compteur angulaire 30 5 et une réactivation de chaque module de pilotage 20. Dans le cas de la figure 3b, on a représenté le cas où l'un des modules 20 de pilotage n'est pas désactivé lors de l'envoi de la requête 120 de confirmation de désactivation par le module 10. Dans ce cas, l'étape 200 de réactivation n'a donc pas lieu. Sur la figure 3c, on a représenté la répétition de l'étape 120. Lorsqu'après la 10 répétition de l'étape 120, au moins l'un des modules n'est toujours pas désactivé, et cette étape est suivie de la réinitialisation 300 du calculateur électronique 1. Désactivation rapide des modules de pilotage Dans certaines circonstances, il peut être nécessaire d'interrompre les commandes envoyées par les modules 20 de pilotage du moteur, même lorsque la 15 synchronisation du moteur n'a pas été perdue. C'est par exemple le cas lors d'une rotation inverse du moteur. Une telle rotation inverse peut survenir lors d'une diminution brusque du régime moteur à bas régime, ou par exemple lors d'un arrêt momentané du moteur pour économiser la consommation de carburant du véhicule (cas dit « Stop and Start »), lors duquel le moteur 20 peut osciller en rotation avant de s'arrêter. Dans ces cas, la position angulaire du moteur continue d'être suivie, le compteur angulaire 30 n'est pas interrompu et la position angulaire de référence TDCO est valide. Néanmoins, dans ce type de circonstance on ne souhaite pas commander le moteur (par exemple on ne souhaite pas déclencher d'injection ou d'allumage du 25 carburant), et il faut annuler les commandes des modules 20 de pilotage du moteur. De plus, les commandes doivent alors être annulées le plus rapidement possible pour éviter une commande intempestive du moteur lors de la reprise d'une rotation normale du moteur et lors de la rotation inverse. Dans ce cas, le procédé comprend alors une étape 400 de désactivation 30 rapide des modules de pilotage 20. En référence à la figure 4b, cette étape 400 comprend l'envoi, directement de la couche bas niveau BSW10 du module 10 de production de données à la couche bas niveau BSW20 de chaque module 20 de pilotage, d'une commande de désactivation. En effet, cette commande est plus rapide que celle de l'étape 110 représentée 35 à la figure 4a et qui nécessite de transiter par les couches applicatives des différents modules. 3057840 13 Selon un mode de réalisation, la réception de la commande de désactivation par une couche bas niveau BSW20 d'un module de pilotage, lorsque ladite commande est envoyée par la couche bas niveau du module 10, entraine le passage à l'état désactivé de ladite couche. 5 En variante, la couche bas niveau BSW20 d'un module de pilotage peut passer à l'état suspendu, comme décrit plus en détails ci-après. Dans tous les cas, l'étape 400 de désactivation rapide des modules 20 entraine une différence d'état entre la couche applicative, qui est restée à l'état actif, et la couche bas niveau d'un module 20. Cette décorrélation des états des couches logicielles 10 ne doit pas durer pour éviter des dysfonctionnements du calculateur. Par conséquent, l'étape 400 est alors suivie de la mise en oeuvre des étapes 100 de désactivation et 200 de réactivation ou 300 de réinitialisation décrites précédemment, de manière à désactiver la couche applicative, puis la couche bas niveau de chaque module 20 de pilotage du moteur, avant de les réactiver. Ceci permet de ré- 15 établir une corrélation entre les couches applicatives des modules 20 et les couches bas niveau correspondantes. Etat suspendu Comme évoqué ci-avant, selon un mode de réalisation particulier, la couche logicielle bas niveau des modules 20 de pilotage du moteur peut adopter, outre l'état actif 20 EP1 et l'état passif EP2, un état dit « suspendu » EP3. Cet état est un état transitoire comprenant, comme l'état passif, une désactivation de toutes les commandes d'actionneurs et de toutes les commandes de modules pour l'exploitation du compteur angulaire. Cependant contrairement à l'état passif, cet état est prévu pour relever l'incohérence avec l'état de la couche applicative du 25 même module, et son adoption ne génère pas de risque de dysfonctionnement du calculateur. En référence à la figure 5, l'état suspendu peut être adopté soit à partir de l'état passif, soit à partir de l'état actif. En revanche, à partir de l'état suspendu, seul l'état passif peut être adopté. 30 Plus précisément, le fonctionnement de la machine à état correspondant à la couche logicielle bas niveau d'un module 20 de pilotage du moteur est le suivant : - passage d'un état actif ou suspendu à un état inactif à réception d'une commande de désactivation 110 provenant de la couche applicative du module 10 de production de données, 35 - passage d'un état inactif à l'état actif à réception d'une commande d'activation 200 provenant de la couche applicative du module 10 de production de données, 3057840 14 - dans un mode de réalisation, passage d'un état actif à suspendu à réception d'une commande de désactivation rapide 400 provenant de la couche bas niveau du module 10 de production de données, - passage d'un état inactif à suspendu à réception d'une commande d'activation 5 provenant de la couche applicative du module 10 de production de données avec une valeur de position angulaire de référence du moteur invalide. De manière plus détaillée, l'état suspendu peut être adopté dans les différents cas suivants. Tout d'abord, dans le cas d'une désactivation rapide 400 des modules de 10 pilotage 20, lors de laquelle la couche bas niveau d'un module 20 reçoit une requête de désactivation émise par la couche bas niveau BSW10 du module de production de données 10. Cette requête peut faire passer la couche bas niveau BSW20 d'un module 20 de pilotage à l'état suspendu plutôt qu'à l'état passif. On note 500 une étape de passage à l'état suspendu de la couche BSW20 d'un module 20. 15 En variante, l'état suspendu peut être adopté 500 dans le cas où, au cours d'une étape 200 d'activation des modules 20 de pilotage du moteur, la synchronisation du moteur est immédiatement perdue. Dans ce cas, les couches applicatives des modules 20 ont déjà été activées mais pas les couches bas niveau. La valeur de référence TDCO qui est envoyée par le module 10 à chaque module 20 est alors invalide. Lorsque les 20 couches bas niveau BSW20 des modules 20 reçoivent la valeur de référence TDCO et constatent que cette donnée invalide, ces couches passent à l'état suspendu. Ce passage à l'état suspendu 500 en cas de désactivation rapide ou de perte de synchronisation rapide permet de désactiver toutes les commandes du module 20 sans pour autant mettre la couche bas niveau du module 20 en état passif alors que la couche applicative est 25 toujours en état actif. Le fonctionnement du module est donc plus robuste avec cet état. Dans ce cas, à la suite du passage à l'état suspendu l'étape 100 de désactivation est mise en oeuvre, et la couche bas niveau du module 20 passe de l'état suspendu à l'état passif à réception de la commande de désactivation provenant de la couche applicative du module 10 de production de données, via la couche applicative du 30 module 20. L'étape 100 est suivie comme décrit précédemment d'une étape 200 de réactivation ou d'une étape 300 de réinitialisation. Selon un autre mode de réalisation, l'état suspendu peut être utilisé dans le cas d'une suspension de la synchronisation. Dans ce mode de réalisation, les machines à état correspondant aux couches logicielles ASW10 et BSW10 du module 10 de production 35 de données présentent l'état supplémentaire « synchronisation moteur suspendue ». Ce type de cas peut notamment intervenir lorsque le véhicule ne comprend pas de capteur de position de l'arbre à came ou que la position de l'arbre à came n'est 3057840 15 pas disponible. Dans ce cas il n'est pas possible de déterminer uniquement d'après la position du vilebrequin la position angulaire du moteur et l'état du cycle moteur, puisqu'un cycle moteur couvre deux tours de vilebrequin. Alors, une première position angulaire de référence TDCO du moteur peut être 5 déterminée par le module 10 de production de données en faisant une hypothèse sur le fait que le cycle du moteur correspond au premier ou au deuxième tour du vilebrequin, cette position angulaire étant communiquée normalement aux modules 20 de pilotage du moteur. Les couches logicielles du module 10 de production de données sont alors à l'état « position moteur disponible ». 10 Le module 10 de production de données surveille ensuite le fonctionnement du moteur en fonction de cette valeur de position angulaire de référence TDCO. La détection d'un dysfonctionnement du moteur permet le cas échéant de constater que l'hypothèse adoptée pour le calcul de la valeur de référence TDCO était invalide. Dans ce cas, les couches logicielles du module 10 passent à l'état 15 « synchronisation moteur suspendue », ce qui entraine directement l'envoi d'une commande de désactivation rapide 400 de la couche bas niveau du module 10 à la couche bas niveau de chaque module 20 de pilotage pour que celui-ci passe de l'état actif à l'état suspendu. La commande de désactivation rapide 400 est dans ce cas également suivie 20 d'une étape 100 de désactivation et d'une étape 200 de réactivation ou 300 de réinitialisation conformes à la description qui précède, afin d'harmoniser les états des différentes couches logicielles des modules et de garantir l'arrêt des commandes avant la reprise du fonctionnement normal. En référence à la figure 7, on va maintenant décrire un exemple de mise en 25 oeuvre du procédé de traitement intégrant les différentes situations exposées ci-avant. Lors d'une situation initiale SO, la synchronisation du moteur n'est pas réalisée, et les modules 10, 20 de production de données et de pilotage du moteur sont inactifs. Cette situation correspond aux états de la figure 8a. De retour à la figure 7, avant la recherche d'une synchronisation moteur SO, le 30 procédé comprend une étape 120 de vérification que tous les modules de pilotage 20 sont inactifs. Si non (N), on revient à la situation initiale SO, si oui (0), le procédé poursuit avec l'établissement de la synchronisation moteur 51. Lors d'une étape S2 on interroge si la synchronisation moteur a été atteinte. Si non (N), l'étape 51 synchronisation est implémentée tant que la synchronisation n'est pas 35 atteinte. Si oui (0), le procédé poursuit à l'étape S3 dans lequel la synchronisation est effectuée. 3057840 16 Le procédé comprend alors une étape 200 d'activation des modules de pilotage 20 du moteur, comprenant d'abord l'activation de la couche logicielle applicative 20 desdits modules, puis l'activation de la couche logicielle bas niveau des modules. L'état obtenu à l'issue de l'étape 200 est l'état représenté à la figure 8c. 5 Le procédé comprend ensuite une étape S4 au cours de laquelle on détermine si la position de référence du moteur TDCO est valide. Si non (N), alors le procédé comprend une étape 500 de passage à l'état suspendu des couches bas niveau des modules de pilotage du moteur. Cette étape est suivie d'une étape 100 de désactivation des modules 20 de pilotage du moteur. 10 Si la position de référence TDCO est valide (0), le procédé poursuit avec une étape S5 où la position du moteur est calculée à partir de la position de référence TDCO. Le procédé comprend ensuite une étape S6 au cours de laquelle on détermine si le véhicule est dans une situation de rotation inverse. Si oui (0), le procédé comprend une étape 400 de désactivation rapide des couches bas niveau des modules 15 20 de pilotage du moteur. Cette étape peut entrainer le passage 500 à l'état suspendu des couches bas niveau des modules de pilotage du moteur, et est suivie d'une étape 100 de désactivation des modules de commande 20. Si non (N), le procédé comprend une étape S7 au cours de laquelle on vérifie à nouveau si la position du moteur déterminée par le module 10 est toujours valide. Si oui 20 (0) , les commandes des modules 20 de pilotage du moteur peuvent être exécutées lors d'une étape S8, qui reboucle à l'étape S5. Si non (N), il s'agit d'un cas de perte de synchronisation du moteur. Le procédé comprend alors une étape 90 d'arrêt du compteur angulaire, suivi d'une étape 100 de désactivation des modules de commande, comprenant l'inactivation des couches 25 applicatives ASW20 des modules 20, puis des couches bas niveau BSW20 desdits modules. A l'issue de l'étape 100, le procédé reboucle sur l'étape SO. En référence aux figures 8a à 8g, on va présenter le fonctionnement des différentes machines à état des modules 10, 20 lors de la mise en oeuvre du procédé de 30 traitement de données. Sur la figure 8a, les couches logicielles du module 10 sont à l'état ED1 désactivé, et les couches logicielles de chaque module 20 sont à l'état EP1 inactif. Il s'agit d'un cas où tous les modules sont désactivés, par exemple au démarrage du moteur où suite à la mise en oeuvre d'une étape 100 de désactivation par exemple en cas de perte 35 de synchronisation avec une étape 90 d'arrêt du compteur angulaire. Sur la figure 8b, la synchronisation du moteur est en cours de mise en oeuvre. La transition 1 amène les couches logicielles du module 10 à l'état ED2 « synchronisation 3057840 17 moteur en cours », tandis que les couches logicielles des modules 20 sont toujours à l'état EP1 inactif. Sur la figure 8c, la synchronisation moteur est obtenue par le module 10. La transition 2 amène les couches logicielles du module 10 à l'état ED3 de position du 5 moteur disponible. De ce fait la couche applicative de chaque module 20 est activée, de sorte qu'à l'issue de la transition 3 elle adopte l'état EP2 actif. L'activation de cette couche applicative entraîne l'activation de la couche bas niveau correspondante, correspondant à la transition 4 qui amène ladite couche à l'état actif EP2. Sur la figure 8d, on a représenté le cas d'une perte de synchronisation 10 immédiate lors de l'activation des modules 20 de pilotage. Dans ce cas la transition 5 amène les couches logicielles du module 10 de l'état ED3 synchronisé à l'état ED1 désactivé. L'état de la couche applicative ASW20 des modules 20 est alors toujours actif. En revanche la réception par la couche bas niveau BSW20 d'une valeur de référence TDCO invalide entraine la transition 9 de passage à l'état suspendu EP3 de la couche 15 correspondante. Sur la figure 8e, on a représenté le cas d'une suspension de la synchronisation, où les couches logicielles passent (transition 14) à l'état ED4 de suspension de la synchronisation, ce qui entraine l'envoi d'une commande de désactivation rapide 400 à la couche bas niveau BSW20 du module 20, qui passe à l'état 20 EP3 suspendu par la transition 12. Sur la figure 8f, lorsque la synchronisation a été suspendue, la désactivation rapide est suivie d'une étape 100 de désactivation des modules 20, ce qui amène la couche applicative de chaque module à l'état EP1 inactif par la transition 6, et la couche bas niveau à l'état EP1 inactif par la transition 10. 25 Enfin, la figure 8g décrit l'exemple d'une reprise de la synchronisation dans lequel les couches logicielles du module 10 repassent à l'état synchronisé ED3 par la transition 13. Les couches logicielles applicative et bas niveau des modules 20 repassent à l'état actif EP2 par les transitions 3 et 4 respectivement. 30 REVENDICATIONS1. Procédé de traitement de données de position d'un moteur de véhicule automobile, mis en oeuvre par un calculateur électronique (1) multi-coeurs comprenant : - un module logiciel (10) de production de données de position angulaire du moteur, et - au moins un module logiciel (20) de pilotage du moteur en fonction des données de position angulaire, le procédé comprenant une étape de désactivation (100) de chaque module de pilotage par le module de production de données de position angulaire, suivie d'une étape d'activation (200) de chaque module de pilotage par le module de production, caractérisé 10 en ce que : - au cours l'étape de désactivation, le module de production envoie à chaque module de pilotage une commande de désactivation (110), puis une requête de confirmation (120) que chaque module de pilotage est désactivé, et - l'étape d'activation (200) des modules de pilotage n'est mise en oeuvre que 15 lorsque la désactivation de tous les modules de pilotage a été confirmée au module de production. 2. Procédé de traitement de données selon la revendication 1, dans lequel l'étape de désactivation (100) comprend en outre au moins une répétition de l'envoi (120) d'une requête de confirmation de la désactivation des modules de pilotage si au moins un 20 module de pilotage n'a pas confirmé sa désactivation. 3. Procédé de traitement de données selon la revendication 2, dans lequel la répétition de l'envoi (120) de la requête de confirmation de la désactivation des modules de pilotage est mise en oeuvre dans un délai compris entre 5 et 20 ms, de préférence égal à 10 ms, après l'envoi de la première requête de confirmation. 25 4. Procédé de traitement de données selon l'une des revendications 2 ou 3, comprenant en outre une étape de réinitialisation (300) du calculateur électronique (1) si le module de production ne reçoit pas d'information de confirmation d'un état désactivé de chaque module de pilotage après la ou les répétitions de l'envoi de la commande de désactivation, et l'étape d'activation des modules de pilotage est mise en oeuvre après 30 l'étape de réinitialisation du calculateur électronique. 5. Procédé de traitement de données selon l'une des revendications précédentes, dans lequel le calculateur électronique (1) comprend un compteur angulaire (30), et le module logiciel (10) de production de données de position du moteur est adapté 3057840 19 pour, à partir d'informations de position angulaire d'un vilebrequin et d'un arbre à cames du moteur, générer une position angulaire de référence du moteur, et dans lequel : - l'étape de désactivation (100) est précédée d'un arrêt du compteur angulaire (90), et 5 - l'étape de réactivation (200) est précédée d'une étape de réinitialisation du compteur angulaire (190) et de calcul d'une nouvelle position angulaire de référence du moteur, mise en oeuvre lorsque le module de production a reçu l'information de confirmation de l'état désactivé de chaque module de pilotage. 6. Procédé de traitement de données selon l'une des revendications précédentes, dans lequel chacun du module logiciel (10) de production de données et de chaque module logiciel de pilotage du moteur (20) comprend une couche logicielle bas niveau (BSW10, BSW20) et une couche logicielle applicative (ASW10, ASW20), et l'envoi d'une commande de désactivation (110) par le module de production à chaque module de pilotage comprend : - l'envoi d'une commande de désactivation par la couche logicielle applicative du module de production à la couche logicielle applicative de chaque module de pilotage, suivie de - l'envoi d'une commande de désactivation par la couche logicielle applicative de chaque module de pilotage à la couche logicielle bas-niveau respective. 7. Procédé de traitement selon l'une des revendications précédentes, chacun du module logiciel de production de données (10) et de chaque module logiciel de pilotage du moteur (20) du calculateur (1) comprenant une couche logicielle bas niveau (BSW10, BSW20) et une couche logicielle applicative (ASW10, ASW20), et la couche logicielle bas niveau de chaque module logiciel de pilotage étant adaptée pour adopter un état « actif », un état « passif » et un état « suspendu », dans lequel la réception d'une commande de désactivation (110) par un module de pilotage (20) entraîne la transition dudit module de l'état « actif » ou de l'état « suspendu » à l'état « passif ». 8. Procédé de traitement de données selon l'une des revendications précédentes, comprenant en outre une étape supplémentaire de désactivation rapide (400) mise en oeuvre avant l'étape de désactivation (100), comprenant l'envoi d'une commande de désactivation rapide de la couche logicielle bas niveau (BSW10) du module (10) de production de données directement à la couche logicielle bas niveau (BSW20) de chaque module (20) de pilotage du moteur. 9. Procédé de traitement de données selon les revendications 7 et 8 en combinaison, dans lequel la réception d'une commande de désactivation rapide (400) par 3057840 20 un module de pilotage entraîne la transition dudit module de l'état « actif » à l'état « suspendu ». 10. Procédé de traitement de données selon l'une des revendications 7 à 9, comprenant en outre une étape supplémentaire mise en oeuvre avant l'étape de 5 désactivation, au cours de laquelle la couche logicielle bas niveau de chaque module de pilotage du moteur passe d'un état « actif » à un état « suspendu » lorsqu'une valeur de référence de position du moteur fournie par le module de production est erronée. 11. Calculateur électronique multi-coeurs (1) de véhicule automobile comprenant : - un module logiciel (10) de production de données de position du moteur, et 10 - au moins un module logiciel (20) de pilotage du moteur en fonction des données de position, caractérisé en ce qu'il est adapté pour mettre en oeuvre le procédé selon l'une des revendications qui précèdent.