FR2997206A1

FR2997206A1 - Unite de calcul d'un appareil de commande et son procede de gestion

Info

Publication number: FR2997206A1
Application number: FR1360276A
Authority: FR
Inventors: Almir Kaiser; Alexander Lang
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2012-10-22
Filing date: 2013-10-22
Publication date: 2014-04-25
Also published as: KR20140051080A; CN103778021B; DE102012219180A1; CN103778021A; KR102046510B1

Abstract

Procédé de gestion d'une unité de calcul (110) d'un appareil de commande (100) échangeant des données avec un système de bus (200). L'unité de calcul (110) synchronise un système d'exploitation (OS) avec le système de bus (200). Le procédé primaire (T1) exécuté par l'unité de calcul (110) : a) reçoit périodiquement (310) des données du système de bus (200) et les fournit (320) à un autre procédé (T2a, T2b, T2c) exécuté également par l'unité de calcul (110), et/ou b) cherche (350) dans l'unité de calcul (110) les données à émettre vers le système de bus (200) par au moins un procédé (T3) et les transmet (360) au système de bus (200).

Description

Domaine de l'invention La présente invention se rapporte à un procédé de gestion d'une unité de calcul d'un appareil de commande échangeant des données par un système de bus.

L'invention se rapporte également à une unité de calcul pour un tel appareil de commande. Etat de la technique Les appareils de commande connus ou leurs unités de calcul reçoivent des données de manière caractéristique par un système de bus ou un réseau (bus CAN, bus LIN, FlexRay, Ethernet ou de cap- teurs tels que des capteurs de pression dans la chambre de combustion d'un moteur thermique, les capteurs de vitesse de rotation) pour les traiter de manière interne et émettre de nouveau par exemple directement à des actionneurs couplés de l'appareil de commande tel qu'un injecteur de moteur ou par un système de bus vers d'autres appareils de commande. Les temps de parcours et les temps de réaction de système liés à de telles données constituent un inconvénient pour les différents scénarios car non déterministiques (c'est-à-dire sans durée connue prévisible) car les systèmes de bus tels que par exemple le Fle- xRay ont une base de temps indépendante du temps de l'appareil de commande et qui s'écarte de la base de temps de l'unité de calcul. Cela signifie que par exemple une durée de 1 ms dans le système de bus FlexRay n'a pas nécessairement exactement la même longueur pour les participants aux bus, c'est-à-dire par exemple les appareils de com- mande. Habituellement le temps des participants aux bus s'écoule moins lentement ou plus rapidement que le temps FlexRay. Il en résulte que les procédés d'un système de gestion d'unités de calcul et ainsi le traitement du signal dans l'unité de calcul de l'appareil de commande sont décalés par rapport au bus FlexRay et ainsi qu'aux fenêtres d'émission et de réception de sorte que l'instant du traitement et la du- rée du traitement varie. En outre, le point de départ de la tache du système de gestion et de sa durée d'exécution varient de manière liée au principe. Il s'agit de la gigue ou du démarrage de tâches ou de la durée d'exécution de la tâche. La dérive du bus, la gigue des instants de démarrage de la tâche ou du procédé ainsi que les calculs de la tâche et du procédé s'amplifient à cause de cette influence négative de l'instant de traitement et de la durée. Une conséquence négative est que des signaux peuvent se perdre côté réception car a) ils n'ont pas été récupérés à temps par le bus ou b) le procédé de traitement n'était pas disponible à temps. Pour les mêmes raisons, les valeurs des signaux peuvent se perdre côté émission car par exemple la fenêtre d'émission a été dépassée sur le bus FlexRay.

But de l'invention La présente invention a pour but de développer un pro- cédé et un appareil de commande du type défini ci-dessus permettant de remédier aux inconvénients cités de l'état de la technique. Exposé et avantages de l'invention A cet effet, l'invention a pour objet un procédé du type défini ci-dessus caractérisé en ce que l'unité de calcul est synchronisée notamment par le système de bus sur le système d'exploitation exécuté par l'unité de calcul et le procédé primaire exécuté par l'unité de calcul qui reçoit périodiquement des données du système de bus et les fournit à un autre procédé exécuté également par l'unité de calcul et/ou cherche dans l'unité de calcul, les données à émettre vers le système de bus par au moins un procédé et les transmet au système de bus. Le procédé selon l'invention a l'avantage que le système de gestion de l'unité de calcul travaille avec la même base de temps que le système de bus auquel est reliée l'unité de calcul. On évite ainsi les effets de la dérive évoquée ci-dessus. On évite en outre la perte de valeur de signaux côté émission et côté réception. En outre l'invention permet avantageusement de réduire la gigue concernant le démarrage de la tâche et la durée d'exécution de la tâche ou son influence perturbatrice sur le traitement des données. Par exemple, le procédé primaire peut avoir une priorité et/ou une fréquence d'exécution supérieure à celle des autres procédés de traitement des données (données de capteurs) de sorte que le procédé primaire pourra recueillir à temps dans le système de bus les données de capteur que l'unité de calcul doit recevoir, par exemple par la lecture dans une mémoire de pile d'entrée dans laquelle ont été enregistrées de façon connue, les données reçues du système de bus. Si par rapport aux autres procédés de traitement de don- nées (données de capteur) de procédé primaire à une priorité plus élevée et/ou une fréquence d'exécution plus élevée, en général il est assuré que le procédé primaire fournit à temps les données aux autres procédés qui pourront toujours travailler avec les données actuelles ou ne pas attendre les données actuelles. Selon un développement préférentiel, le procédé primaire lo reçoit les données du bus du système d'une manière synchronisée no- tamment avec au moins une fréquence par laquelle les données arrivent du système de bus dans l'unité de calcul ce qui évite des situations dans lesquelles on perd des données reçues car elles n'ont pu être lues à temps par le procédé primaire, par exemple dans la mémoire de pile 15 d'entrée, si bien que les données qui s'y trouvent seront le cas échéant remplacées par des données suivantes. Le procédé primaire selon l'invention permet, grâce à sa synchronisation ou à la synchronisation du système de gestion et à sa priorité, toutes les données d'entrée du système de bus de recevoir de 20 manière précise dans le temps et suffisamment rapidement. Selon un développement préférentiel, le procédé primaire fournit les données reçues à au moins un autre procédé de façon qu'elles soient disponibles à un instant prédéfini par rapport au déroulement de l'autre procédé, notamment avant le démarrage suivant de 25 cet autre procédé ; le procédé primaire peut disposer des informations de planification du procédé (échéancier) de l'unité de calcul ou du système de gestion. Ce mode de réalisation garantit avantageusement que le procédé primaire pourra transmettre les données reçues d'une manière déterministique vers les autres procédés qui seront alors alimen- 30 tés régulièrement et à temps avec les données toujours actuelles. On évite ainsi entre autre avantageusement qu'un procédé traitant par exemple des données de capteur reçoive deux fois successivement les mêmes données de capteur qui ne seront plus à jour pour la seconde opération.

Selon un autre développement, le procédé primaire tient compte de la priorité et/ou de la durée de la période d'exécution d'au moins un autre procédé pour fournir les données à cet autre procédé. De même le procédé primaire pourra tenir compte de ses propres para- mètres de calendrier (priorité/ou durée de période) ainsi que le cas échant des autres procédés exécutés par l'unité de calcul. Selon un autre développement avantageux, le procédé primaire cherche les données à émettre par un autre procédé vers le bus du système à un instant prédéfini rapporté au déroulement de cet autre procédé, ce qui garantit que les données à émettre vers le système de bus sont toujours des données actuelles. Selon un autre développement avantageux, le procédé primaire transmet les données à émettre par le procédé par le système de bus d'une manière synchronisée dans le système de bus vers celui-ci. Selon un autre développement avantageux, le procédé primaire utilise une plage de mémoire de l'unité de calcul utilisée en commun par le procédé primaire et par les autres procédés pour échanger des données avec les autres procédés. La plage de mémoire utili- sable en commun se présente par exemple sous la forme d'une variable dite « globale » d'une langue de programmation selon laquelle l'unité de calcul est programmée. La présente invention a également pour objet une unité de calcul d'un appareil de commande échangeant des données avec un système de bus caractérisé en ce qu'elle a un système d'exploitation ap- pliqué par l'unité de calcul pour se synchroniser avec le système de bus et recevoir un procédé primaire qui se déroule dans l'unité de calcul, pour recevoir les données périodiques du système de bus et les données d'au moins un autre procédé se déroulant également dans l'unité de calcul et/ou les données à envoyer par l'unité de calcul vers le système de bus d'au moins un procédé pour les chercher et les transférer au système de bus. Selon un autre développement, l'unité de calcul est un microcontrôleur ou un processeur numérique de signal DSP ou encore un circuit intégré dédié à une application ASIC ou un composant lo- gigue programmable (par exemple un composant FPGA) et le système de gestion de l'unité de calcul est conçu pour un fonctionnement multiprocédés, multitâches. De façon particulièrement avantageuse, l'unité de calcul est réalisée pour appliquer le procédé de l'invention. Dessins La présente invention sera décrite ci-après de manière plus détaillée à l'aide d'un mode de réalisation d'un procédé de gestion d'une unité de calcul et d'une unité de calcul pour sa mise en oeuvre représentée dans les dessins annexés dans lesquels : - la figure 1 est un schéma par bloc d'un mode de réalisation d'une unité de calcul selon l'invention, - la figure 2 est un schéma par bloc d'un mode de réalisation d'un système de gestion d'une unité de calcul selon l'invention, - les figures 3 et 4 sont des ordinogrammes très sché- matiques d'un mode de réalisation du procédé de l'invention. Description d'un mode de réalisation de l'invention La figure 1 montre un schéma par blocs d'un mode de réalisation d'un appareil de commande 100 selon l'invention par exemple d'un véhicule automobile. L'appareil de commande 100 est re- lié à un capteur S (par exemple un capteur de vitesse de rotation pour détecter la vitesse de rotation du vilebrequin du moteur thermique du véhicule) pour recevoir les données du capteur. Les données du capteur sont traitées dans l'appareil de commande 100. L'appareil de commande 100 est également branché pour actionner un actionneur tel que l'actionneur A, par exemple, un injecteur. L'appareil de commande 100 est en outre relié à un sys- tème de bus 200 qui, en général permet par une communication bidirectionnelle avec d'autres appareils reliés au système de bus 200 (appareils non représentés) de communiquer par exemple avec d'autres appareils de commande. Le système de bus est un bus de données tel que les bus FlexRay, CAN, LIN ou autres bus de données. Pour traiter des données de capteur et commander l'actionneur A par exemple en fonction des données de capteur, l'appareil de commande 100 comporte une unité de calcul 110 qui est par exemple un microcontrôleur ou un circuit DSP. D'autres réalisations (circuit ASIC, FPGA ou autres) peuvent également s'envisager. L'unité de calcul 110 peut exécuter des programmes d'ordinateur ayant pour objet par exemple une fonction de traitement de données de cap- teur et/ou de commande de l'actionneur A. L'unité de calcul 110 dispose d'un système de gestion OS qui commande le déroulement des opérations de l'unité de calcul. Le système de gestion OS permet par exemple dans le cas d'un système de gestion multitâches, d'établir et d'exécuter plusieurs procédés ayant dif- férentes fonctions tels que par exemple le traitement de données de cap- teur, l'exécution d'algorithme de régulation ou autres. Pour avoir un traitement particulièrement précis dans le temps des données du capteur S et commander l'actionneur A, l'unité de calcul 110 ou son système de gestion ou système d'exploitation sont synchronisés avec le système de bus 200. Cela se fait par exemple en ce que le système de gestion ou d'exploitation OS enregistre, par exemple dans un procédé correspondant, une étiquette de temps ou autres informations permettant une synchronisation du système de bus 200 et le réglage correspondant de son horloge interne ou du compteur de l'unité de calcul 110. La synchronisation selon l'invention se fait de préférence également de manière périodique pour éviter les effets de la dérive entre le temps du bus et l'horloge interne. L'ordinogramme simplifié de la figure 3 montre l'étape de synchronisation évoquée ci-dessus de l'unité de calcul 110 avec le sys- tème de bus 200 sous la référence 300. En outre, selon l'invention, l'unité de calcul 110 exécute un procédé primaire Ti (voir figure 2) qui reçoit périodiquement des données du système de bus 200 et applique aux données ainsi reçues au moins un autre procédé T2a, T2b, T2c également fournis par l'unité de calcul 110. Les autres procédés T2a, T2b, T2c sont par exemple des procédés qui traitent les données du capteur S reçues par le procédé primaire Tl. La transmission de données entre les procédés Ti, T2a, T2b, T2c peut se faire par exemple en utilisant des variables globales d'une langue de programmation selon laquelle l'unité de calcul 110 est programmée. La réception des données par le système de bus 200 se- lon le procédé primaire Ti est présenté par l'étape 310 à la figure 3 et l'étape 320 suivante représente la transmission des données par le pro- cédé primaire T1 aux autres procédés T2a, T2b, T2c. Selon un mode de réalisation préférentiel, le procédé pri- maire Ti n'effectue pas lui-même le traitement des données de capteur ou autres données reçues du système de bus 200 mais assure simple- ment leur transmission à temps notamment de façon déterministique vers les autres procédés T2a, T2b, T2c. Le procédé primaire Ti peut ainsi être considéré comme constituant un procédé de répartition qui reçoit à l'heure exacte les données arrivant dans l'unité de calcul 110 notamment avant que les données d'entrée ne soient souscrites par les nouvelles données suivantes et il envoie les données ainsi reçues vers les autres procédés T2a, T2b, T2c pour leur traitement proprement dit. En outre, l'invention permet avantageusement de diminuer la gigue concernant le départ de la tâche ou la durée d'exécution de la tâche ou son influence perturbatrice sur le traitement des don- nées. Par exemple, le procédé primaire Ti peut avoir une priorité et/ou une fréquence d'exécution plus élevée que celle des autres procédés de traitement de données (données de capteur) T2a, T2b, T2c ce qui garantit que le procédé primaire Tlpourra recueillir dans l'unité de calcul 110 les données de capteur à recevoir du système de bus 200 par exemple en lisant dans une mémoire de pile d'entrée (mémoire non représentée) dans laquelle ont été inscrites de façon connue en soi, les données reçues par le système de bus 200. Si par comparaison aux autres procédé de traitement de données (données de capteur) le procédé primaire Ti a une priorité su- périeure et/ou une fréquence d'exécution supérieure, cela garantit en général que le procédé primaire T1 pourra également fournir à temps les données aux autres procédés T2a, T2b, T2c qui pourront toujours travailler avec les données actuelles et n'auront pas à attendre les données actuelles.

Vis-à-vis de cela dans les systèmes usuels on arrive à des gigues importantes concernant le démarrage de la tâche ou la durée d'exécution de la tâche car les procédés qui traitent les différentes données de capteurs doivent chercher elles-mêmes les données d'entrée dans le système de bus 200. Selon un mode de réalisation préférentiel de l'invention, le procédé primaire Ti reçoit les données du système de bus 200 d'une manière synchronisée sur le système de bus 200 en particulier avec au moins une fréquence selon laquelle les données du système de bus 200 arrive dans l'unité de calcul 110 ce qui évite des situation de perte de données reçues car elles n'auront pas été lues suffisamment à temps par le procédé primaire Ti par exemple dans la mémoire de la pile d'entrée, si bien que les données qui s'y trouvent auront déjà été remplacées par les données suivantes.

Le procédé primaire Ti selon l'invention, grâce à sa syn- chronisation ou à la synchronisation du système de gestion OS et de sa priorité permet d'une manière suffisamment précise et rapide dans le temps de recevoir toutes les données d'entrée du système de bus 200 et de les réserver aux autres procédés.

Selon un développement préférentiel, le procédé primaire Ti fournit les données reçues à au moins un autre procédé T2a de façon que ces données soient disponibles à un instant prédéfini rapporté au déroulement ou déroulement de cet autre procédé T2a notamment avant le démarrage suivant de cet autre procédé. Cela permet au procé- dé primaire T1 de disposer d'informations de planification de procédé (échéancier) de l'unité de calcul 110 ou du système de gestion OS. Ce mode de réalisation garantit avantageusement que les données reçues par le procédé primaire Ti sont transmises d'une manière déterministique vers les autres procédés T2a, T2b, T2c. ces autres procédés T2a, T2b, T2c sont alimentés ainsi régulièrement et à temps avec des don- nées toujours actuelles. Ainsi, on évite avantageusement entre-autre qu'un procédé qui traite par exemple les données de capteur ait à traiter deux fois successivement les mêmes données de capteur qui pourtant ne sont plus les données actuelles pour la seconde opération.

Selon un autre développement avantageux, le procédé primaire T1 cherche les données envoyées par un autre procédé T3 du système de gestion OS (figure 2) au bus du système 200 pour émettre des données à un instant prédéfini par rapport au déroulement de l'autre procédé T3, par exemple au moment précis auquel les données à émettre ont été fournies par le procédé T3 ou juste après. Cela garantit que les données à émettre vers le système de bus 200 sont toujours des données actuelles. Selon un autre développement avantageux, le procédé primaire T1 transmet les données à envoyer par l'autre procédé T3 vers le système de bus 200 d'une manière synchronisée avec le système de bus 200 vers ce système de bus 200. La figure 4 montre un autre mode de réalisation de l'invention. Dans l'étape 350, le procédé primaire Ti cherche les don- nées à émettre à un instant prédéfini par le procédé T3 vers le système de bus 200 rapporté au déroulement de cet autre procédé T3. Dans l'étape 360, le procédé primaire Ti transfère les données à émettre par l'autre procédé T3 vers le système de bus 200 de préférence d'une manière synchronisée avec le bus de système 200 vers celui-ci.

L'invention permet avantageusement que les temps de parcours de signal et les temps de réaction de système dans l'appareil de commande 100 vis-à-vis des données traitées par le procédé primaire Ti (données reçues par le bus de système 200 et transmise aux autres procédés T2a, T2b et T2c et ainsi que celles reçues d'un autre procédé T3 et transmises au système de bus 200) soient toujours représentés de la même manière et se comportent de manière déterministique. Une planification appropriée de l'instant de synchronisation de l'unité de calcul 110 avec le système de gestion 200 et des différents procédés entre autres, interdit la perte de valeur de signaux ou évite le double traitement de la même valeur de signal avec la même étiquette de temps ou autre. Selon un mode de réalisation préférentiel, le procédé pri- maire T 1, est exécuté environ toutes les 5 ms (millisecondes), alors que les procédés T2a, T2b, T2c, T3 sont exécutés sensiblement toutes les 20 ms.

Les procédés T2a, T2b, T2c peuvent également avoir des fréquences d'exécution différentes tel que par exemple 10 ms, 20 ms et 40 ms.5 NOMENCLATURE DES ELEMENTS PRINCIPAUX 100 Appareil de commande 110 Unité de calcul 200 Système de bus 300, 310, 320, 350, 360 Etapes d'un ordinogramme T2a, T2b, T2c Procédés10

Claims

REVENDICATIONS1°) Procédé de gestion d'une unité de calcul (110) d'un appareil de commande (100) échangeant des données avec un système de bus (200), procédé caractérisé en ce que l'unité de calcul (110) est synchronisée (300) notamment par le système de bus (200) sur le système d'exploitation (OS) exécuté par l'unité de calcul (110), et le procédé primaire (Ti) exécuté par l'unité de calcul (110) qui a) reçoit périodiquement (310) des données du système de bus (200) et les fournit (320) à un autre procédé (T2a, T2b, T2c) exécuté également par l'unité de calcul (110), et/ou b) cherche (350) dans l'unité de calcul (110) les données à émettre vers le système de bus (200) par au moins un procédé (T3) et les transmet (360) au système de bus (200).
2°) Procédé selon la revendication 1, caractérisé en ce que le procédé primaire (Ti) reçoit les données du système de bus (200) d'une manière synchronisée avec le système de bus notamment à l'aide d'une fréquence par laquelle les données arrivent dans l'unité de calcul (110) à partir du système de bus (200).
3°) Procédé selon la revendication 1, caractérisé en ce que le procédé primaire (Ti) fournit les données reçues à au moins un autre procédé (T2a) de façon que ces données soient disponibles à un instant prédéfini rapporté au déroulement de l'autre procédé (T2a) notamment avant le prochain démarrage du procédé suivant.
4°) Procédé selon la revendication 3, caractérisé en ce que le procédé primaire (Ti) tient compte d'une priorité et/ou d'une durée de période d'exécution d'au moins un autre procédé (T2a) pour fournir les données à au moins cet autre procédé.5°) Procédé selon la revendication 1, caractérisé en ce que le procédé primaire (Ti) cherche les données à envoyer par le procédé (T3) au système de bus (200) à des intervalles prédéfinis à apporter au déroulement de l'autre procédé (T3) (350). 6°) Procédé selon la revendication 1, caractérisé en ce que le procédé primaire (Ti) transmet les données envoyées par le procédé (T3) au système de bus (200) d'une manière synchronisée sur le sys- tème de bus et vers ce système de bus (200). 7°) Procédé selon la revendication 1, caractérisé en ce que le procédé primaire (Ti) utilise une plage de mémoire de l'unité de cal- cul (110) commune aux autres procédés (T2a, T3) par le procédé primaire (T1), pour échanger des données avec les autres procédés (T2a, T3). 8°) Unité de calcul (110) d'un appareil de commande (100) échangeant des données avec un système de bus (200), unité de calcul caractérisé en ce qu' elle a un système d'exploitation (OS) appliqué par l'unité de calcul (110) pour se synchroniser (300) avec le système de bus (200) et recevoir (310) un procédé primaire (Ti) qui se déroule dans l'unité de calcul (110), pour a) recevoir périodiquement (310) des données du système de bus (200) et les fournit (320) à un autre procédé (T2a, T2b, T2c) exécuté également par l'unité de calcul (110), et/ou b) chercher (350) dans l'unité de calcul (110) les données à émettre vers le système de bus (200) par au moins un procédé (T3) et les transmet (360) au système de bus (200). 9°) Unité de calcul (110) selon la revendication 8, caractérisée en ce qu'elle est réalisée comme microcontrôleur ou comme processeur numérique de signal ou comme circuit intégré dédié à une application ou encore comme composant logique programmable et le système d'exploitation (OS) de l'unité de calcul (110) est conçut pour une gestion multi-procédés, multitâches. 10°) Unité de calcul (110) selon l'une des revendications 8 ou 9, caractérisée en ce qu' elle exécute le procédé selon l'une des revendications 2 à 7.10