FR3047821A1

FR3047821A1 - Procede et dispositif de gestion d'un appareil de commande

Info

Publication number: FR3047821A1
Application number: FR1751176A
Authority: FR
Inventors: Peter Haefele; Uwe Hartmann; Dirk Ziegenbein; Simon Kramer
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2016-02-16
Filing date: 2017-02-14
Publication date: 2017-08-18
Anticipated expiration: 2037-02-14
Also published as: EP3417373A1; CN108701054B; US11115232B2; FR3047821B1; EP3417373B1; JP6679758B2; DE102016202305A1; WO2017140504A1; KR20180108831A; JP2019510327A; US20210194720A1; CN108701054A

Abstract

Procédé de gestion d'un appareil de commande (33), ayant une unité d'exécution (30) de programmes de tâches (31). On exécute de temps en temps un premier programme de tâches (31) et un second programme de tâches (31), le premier programme (31) fournissant à la fin d'un premier intervalle de temps prédéfini, des données (32) pour le second programme (31). La transmission des données du premier programme (31) vers le second programme (31) ne se fait qu'après chaque dernière exécution du premier programme (31) dans un second intervalle de temps prédéfini pour l'exécution du second programme (31). Le second intervalle est plus long que le premier.

Description

Domaine de ^invention

La présente invention se rapporte à un procédé et à un dispositif de gestion d’un appareil de commande, notamment pour un véhicule, l’appareil de commande ayant au moins une unité d’exécution pour exécuter des programmes de tâches, selon lequel on exécute au moins de temps en temps un premier programme de tâches et un second programme de tâches, le premier programme fournissant à la fin d’un premier intervalle de temps prédéfini, des données pour le second programme.

Etat de la technique

On connaît un document DE 102 29 520 Al concernant ce domaine.

Dans un véhicule, les opérations de commande se font avec des systèmes de gestion comme bases pour l’exécution des opérations de commande. Les systèmes de gestion, notamment les systèmes de gestion en temps réel, tels que par exemple les systèmes intégrés dans le domaine automobile, répartissent souvent les fonctions entre plusieurs programmes de tâches avec des temps de détection différents de sorte que les parties critiques dans le temps sont plus fréquentes que les algorithmes ou programmes ou parties de programme moins critiques dans le temps. Un programme de tâches est une unité de programme qui est appelée « tâche » dans la suite de la description. Dans le cas normal, le système de gestion sécurise la consistance des données. C’est ainsi que des données sont utilisées dans plusieurs tâches et sont fournies comme copies à des instants appropriés, pour que par exemple dans une tâche longue, la valeur des données ne change pas entre deux accès si les données ont été inscrites à une taille correspondant à une tâche plus rapide.

Dans les applications en technique de régulation comme par exemple les systèmes de dynamique de roulage ESP ou dans le cadre d’une commande de moteur ou de boîte de vitesses, il faut garantir le comportement déterministique. Cela signifie que pour les mêmes conditions de sortie, les résultats des calculs (par exemple l’émission cyclique de commande d’actionneur) ne doivent dépendre que des grandeurs d’entrée (par exemple les valeurs des capteurs fournies par une détection cyclique) et être indépendants de la répartition des unités de programme entre les noyaux de calcul disponibles et la charge du système. De plus, la communication déterministique garantit que le temps de parcours (latence) d’une chaîne de signaux d’activité qui traverse plusieurs unités de programme ne bouge que dans un petit cadre prédéfini, c'est-à-dire que l’effet jitter reste petit dans les temps de parcours. Il faut également garantir naturellement que toutes les tâches soient exécutées dans les durées prédéfinies pour ne pas surcharger les noyaux de calcul.

Le comportement déterministique peut en général améliorer la qualité des systèmes de régulation et permet de simplifier le calibrage et les tests dans le procédé de développement ; il facilite la migration vers d’autres unités de calcul, par exemple avec plus de noyaux de calcul avec une distribution optimisée des unités de programme entre les noyaux de calcul, et facilite la sécurité de fonctionnement dans les unités de calcul avec un ou plusieurs noyaux de calcul. De plus, cela garantit dans le cadre, par exemple d’un procédé de développement fondé sur des modèles, le système se comporte toujours de la même manière, fonctionnellement sur les différentes plateformes d’exécution, par exemple l’environnement de simulation, le calculateur de développement, et l’appareil de commande en série.

But de l’invention

La présente invention a pour but de développer un procédé de communication entre les tâches qui demande beaucoup moins de ressources de calcul que les solutions connues, par exemple des mémoires, des temps de parcours et des temps de calcul, et réduit les pointes de charge des canaux de communication.

Exposé et avantages de l’invention A cet effet, l’invention a pour objet un procédé de gestion d’un appareil de commande, notamment pour un véhicule, ayant au moins une unité d’exécution pour exécuter des programmes de tâches et consistant à exécuter au moins de temps en temps un premier programme de tâches et un second programme de tâches, le premier programme fournissant à la fin d’un premier intervalle de temps prédéfini, des données pour le second programme de tâches, la transmission des données du premier programme de tâches vers le second programme de tâches ne se faisant qu'après chaque dernière exécution du premier programme à l’intérieur d’un second intervalle de temps prédéfini pour l’exécution du second programme, le second intervalle de temps étant plus long que le premier. L’invention a également pour objet un dispositif pour la mise en œuvre d’un tel procédé.

Selon l’invention, les données sont transmises à des instants déterminés entre les unités de programme contrôlées par le système de gestion, la transmission physique entre les différents partenaires en communication étant répartie dans le temps. Ainsi, il suffit de beaucoup moins de ressources de calcul et on réduit les pointes de charge appliquées aux canaux de communication. L’avantage par rapport à un procédé de communication déterministique du type évoqué dans le préambule est la suppression d’une mémoire intermédiaire et le fait d’éviter plus d’une mémoire de réception pour les données à transmettre, ce qui permet une économie de place de mémoire considérable pour les données échangées entre les tâches et ainsi une réduction de coûts.

Un autre avantage est que l’émission/réception des données ne se fait pas selon la réalisation de l’émetteur ou du récepteur mais de façon ciblée en fonction des rapports des périodes d’activité entre deux tâches seulement à des instants déterminés pour la communication des données. Cela se traduit par une réduction de la charge appliquée au bus et de la demande de temps de calcul.

De façon avantageuse, on supprime une tâche supplémentaire par relation de communication pour économiser des ressources de calcul. De plus, dans certaines conditions, on économise encore plus de ressources par l’utilisation multiple de la même mémoire d’entrée.

De façon avantageuse, le premier programme de tâches se fait dans une première unité d’exécution et le second programme de tâches dans une seconde unité d’exécution de l’appareil de commande. Cela permet l’échange de données entre des tâches qui s’exécutent en parallèle dans des noyaux de calcul différents.

De manière avantageuse, la durée du second intervalle est un multiple entier de celle du premier intervalle. Ainsi, les limites des intervalles entre les tâches démarrées simultanément seront synchrones.

De manière avantageuse, on transmet les données d’une première plage de mémoire associée au premier programme de tâches, directement dans une plage de mémoire associée au second programme de tâches. Ainsi, les données seront transmises directement d’un émetteur au récepteur par une seule opération de copie, sans avoir à copier d’abord les données dans une mémoire intermédiaire. Bien que l’on évite les pointes de charge de communication et qu’on économise de la place de mémoire et du temps de calcul, le comportement global déter-ministique est conservé.

De manière avantageuse, on exécute en plus un troisième programme de tâches pour transmettre les données d’une plage de mémoire associée au premier programme de tâches à une mémoire intermédiaire et à partir de cette mémoire intermédiaire, dans une seconde plage de programme associée au second programme de tâches. Cela permet la communication entre les tâches qui n’ont pas démarré simultanément ou qui ont entre elles une longueur qui ne correspond pas à un multiple entier.

De manière avantageuse, le premier programme de tâches et le second programme de tâches ont des temps de cycle différents, le temps de cycle du premier programme de tâches étant plus petit que le temps de cycle du second programme de tâches et les données sont transmises de la première plage de mémoire associée au premier programme de tâches à une plage de mémoire associée au second programme de tâches à l’intérieur du cycle du premier programme de tâches qui se situe dans le temps, dans la plage de la fin de cycle du second programme de tâches. Ainsi, le résultat de la première exécution du premier programme de tâches qui se répète plus rapidement sera utilisé pour la communication avec le second programme de tâches qui se répète plus lentement. Ainsi, les résultats les plus rapides seront disponibles pour la communication.

De façon préférentielle, dans le premier état de fonctionnement, à l’intérieur d’un intervalle de temps (durée) associé au programme de tâches respectif, un autre programme de tâches n’accède pas à la plage de mémoire associée au premier programme de tâches et dans un second état de fonctionnement, à l’intérieur de cet intervalle de temps, le programme de tâches respectif n’accède plus à cette plage de mémoire. Ainsi, les grandeurs de sortie ne seront pas copiées avant que des valeurs actuelles soient disponibles, c'est-à-dire que les grandeurs de sortie ne seront pas modifiées pendant l’opération de copie.

De façon préférentielle, dans un programme de tâches, on attribue une première plage de mémoire aux données d’entrée et le programme de tâches a une seconde plage de mémoire pour les données de sortie, des informations d’état indiquant qu’à l’intérieur de l’exécution du programme de tâches, avant la fin de l’intervalle actuel, on n’accède plus aux données d’entrée et il n’y aura pas de modification des données de sortie. L’information supplémentaire commande l’accès aux données de sorte que l’opération de copie est elle-même « sans attente » c’est-à-dire « wait-free ».

Dessins

La présente invention sera décrite ci-après de manière plus détaillée à l’aide d’exemples de réalisation d’un procédé de gestion d’un appareil de commande d’un véhicule, représentés dans les dessins annexés dans lesquels les éléments identiques ou analogues des différentes figures portent les mêmes références.

Ainsi : la figure 1 montre schématiquement une succession de tâches, la figure 2 montre schématiquement une commande, la figure 3 montre schématiquement des routines de copie et de transfert, la figure 4 montre schématiquement un procédé de commande avec un bit d’état, la figure 5 montre schématiquement un procédé de commande avec plus de deux tâches en communication, la figure 6 montre schématiquement d’autres variantes du procédé de commande, la figure 7 montre schématiquement une communication non harmonique entre deux tâches.

Description de modes de réalisation

La figure 1 montre un exemple de système à deux unités de programme. Les unités de programme sont des programmes de tâches qui se déroulent sous la forme d’une tâche 5 ms et d’une tâche 10 ms. La figure 1 montre la tâche 5 ms sous la forme d’un rectangle 1. La figure 1 montre un exemple d’une tâche 10 ms sous la forme d’un rectangle 2. Les programmes de tâches selon la figure 1 n’occupent pas la totalité de la durée de 5 ms ou de 10 ms. La longueur des rectangles 1, 2 et leur position sur l’axe du temps t montrent à titre d’exemple, le début et la fin et la durée des différents calculs. Cela signifie que les programmes de tâches seront activés toutes les 5 ms ou 10 ms. L’activation se fait non nécessairement au début d’une tâche. Les tâches sont exécutées à l’intérieur d’un intervalle prédéfini d’une durée de 5 ms, représenté par la double flèche 3 ou d’une durée de 10 ms, représenté par la double flèche 4. Toutes les 10 ms, on échange aux limites communes les intervalles 5 donnés entre les tâches, par un échange logique. L’échange des données est représenté schématiquement sous la forme d’une double flèche 6. L’échange des données se fait de manière directionnelle ou seulement dans l’une des deux directions.

Le maximum du besoin de communication correspond aux limites 5 entre les intervalles, lorsque comme représenté, on implémente la communication 6.

Le système de gestion du type défini ci-dessus assure les déroulements correspondants.

Le procédé correspondant suppose au préalable un rapport fixe de nombres entiers entre les taux d’activation des différentes tâches, et s’utilise sans autres extensions seulement pour les unités de calcul avec un unique noyau de calcul (Single Core Processeur). L’exemple de la figure 1 montre une telle implémentation de la tâche sur les mêmes noyaux de calcul avec une exécution commandée en priorité.

Une autre communication entre les tâches utilise une mémoire intermédiaire dans laquelle l’émetteur inscrit ses données de sortie à la fin de la tâche et dans laquelle le récepteur lit ces données d’entrée au début de la tâche. Pour garantir la cohérence des données, il faut protéger l’accès à la mémoire intermédiaire, ce qui signifie par exemple que pendant que l’émetteur inscrit des données dans la mémoire intermédiaire, le récepteur ne peut pas copier de données d’entrée et doit attendre.

Pour la communication entre une première et une seconde tâche, on peut prévoir que la première tâche active une notification de tâche supplémentaire pour coordonner la communication, dans le contexte de la seconde tâche. La notification de tâche informe la première tâche ou la seconde tâche de la communication imminente.

Dans la suite de la description, on utilisera l’expression « temps d’exécution logique » (LET) qui décrit le comportement chronologique des unités de programme, notamment le comportement de communication entre les unités, indépendamment de la répartition entre les unités de calcul et la capacité des unités de calcul d’exécution. Cette expression est définie dans l’ouvrage « T.A. Henzinger, B. Horowitz, et C.M. Kirsch. Embedded control Systems development with Giot-to. In Proc. ACM SIGPLANWorkshop on Languages, Compilers, and Tools for Embedded Systems (LCTES). ACM, 2001”. Cette expression sera utilisée ci-après.

Pour l’exécution des unités de programme, on dispose d’un intervalle de temps prédéfini. Au début de l’intervalle de temps, on dispose des grandeurs d’entrée de l’unité de programme et précisément à la fin de l’intervalle, on fournit les grandeurs de sortie calculées par l’unité de programme, aux autres unités de programme. L’exécution de l’unité de programme peut se faire à des instants quelconques à l’intérieur de l’intervalle de temps.

La communication entre les unités de programme se fait de manière logique chaque fois au début et à la fin des intervalles de temps, soit par une communication précise à ces instants (par exemple en établissant des copies des données de sortie dans la plage de travail du récepteur) ou en établissant des mémoires multiples pour les données entre lesquelles on commutera en fonction du temps de parcours, c'est-à-dire pendant que l’émetteur inscrit dans la mémoire, le récepteur peut lire des données consistantes d’un cycle d’émission précédent à partir d’une autre mémoire.

Le procédé décrit ci-dessus assure la coordination de communication entre les différentes unités de programme d’exécution, c'est-à-dire les programmes de tâches dans un cycle de régulation en temps réel.

Pour cela, on s’assure que la communication entre les tâches ne se fait qu’à des instants déterminés dans le but de garantir un comportement déterministique et reproductible de l’ensemble du système indépendamment de la charge de l’unité de calcul qui assure l’exécution.

La figure 2 montre schématiquement un appareil de commande électronique 33 à deux unités d’exécution 30. Il s’agit par exemple de noyaux de calcul ou d’unités de calcul qui exécutent de manière cyclique une unité de programme 31 respective, les données étant échangées de l’une à l’autre unité de programme. Cette transmission de données est indiquée par la flèche portant la référence 32 à la figure 2. Une grandeur d’entrée 34 ou plusieurs grandeurs d’entrée 34 ou données d’entrée telles que des valeurs mesurables physiquement, seront mesurées et traitées dans l’appareil de commande 33. Une grandeur de sortie 35 ou plusieurs grandeurs de sortie 35 ou données de sortie de l’appareil de commande 33 sont par exemple émises sous la forme de grandeurs de réglage vers l’environnement physique. Pour cela, l’appareil de commande 33 a des mémoires non volatiles ou des interfaces de données.

Dans la suite de la description, à l’aide de plusieurs grandeurs d’entrée 34 ou de plusieurs grandeurs de sortie 35, on décrira comment se fait la communication 32 entre les différentes unités de programme 31 en économisant les ressources en ce que les grandeurs de sortie 35 ne dépendent des grandeurs d’entrée 34 que de manière déterministique, indépendamment de la répartition des unités de programme 31 entre les unités d’exécution 30 et indépendamment de la charge des unités d’exécution 30. Cette remarque s’applique à une grandeur d’entrée 34 ou une grandeur de sortie 35.

La figure 3 montre une communication entre une tâche de 5 ms et une tâche de 10 ms. Le déroulement du programme garantit que la transmission des données de l’émetteur vers le récepteur se fait précisément une fois au cours de l’intervalle de temps le plus court. Un mécanisme de comptage garantit que la tâche la plus lente transmet des données seulement après la dernière exécution respective de la tâche la plus rapide dans l’intervalle de temps. Le compteur 5 ms, 5 ms_ready et 10 ms_ready du mécanisme de comptage est représenté à la figure 3 sous les références 22, 20 et 21.

On garantit ainsi le comportement déterministique dans le sens de LET (temps logique d’exécution).

Dans l’exemple de la figure 3, la tâche 5 ms a le taux d’activité le plus élevé par comparaison avec la tâche 10 ms. C’est pourquoi, ce n’est que pour chaque seconde exécution 12a/b que l’on transfère les données mais non pour les exécutions 19. Pour cela, chaque fois à la fin de la tâche la plus rapide, on décrémente un compteur 22.

La transmission des données est autorisée lorsque l’état de comptage du compteur 22 arrive à zéro, et le compteur est remis à une valeur qui correspond au rapport du temps de détection le plus lent par le rapport du temps de détection le plus rapide. Dans l’exemple de la figure 3, le compteur 22 est mis à la valeur 2. L’information 5 ms_ready 20 et l’information 10 ms_ready 21 représentent les états de fonctionnement. Par exemple, l’état 1 indique que la tâche respective est prête pour l’échange des données et, l’état 0 indique que la tâche respective n’est pas prête pour un échange des données.

Les tâches peuvent être exécutées par le même noyau de calcul ou un noyau de calcul différent.

Une condition de l’implémentation de l’invention est chacune des deux tâches accède à la plage de mémoire caractéristique pour la communication, de l’autres tâche respective. Les plages de mémoire sont caractérisées à la figure 3 sous la forme de tampons de chaque tâche.

La plage de mémoire 11 de la tâche 5 ms, 12a/b ou 19, contient les grandeurs de sortie calculées pour la tâche 5 ms et qui doivent être transférées de la plage de mémoire 15 de la tâche 10 ms 13.

La transmission 14 des données de l’émetteur vers le récepteur doit se faire lorsque chaque seconde tâche 5 ms 12a/b termine le calcul des données à émettre et qu’en même temps la tâche 10 ms a terminé le traitement des données reçues 15 dans le cycle précédent. Cela est le cas au plus tard lorsque les deux tâches seront terminées.

La même remarque s’applique à la communication dans l’autre direction, pour passer de la tâche 10 ms à la tâche 5 ms. Les données à émettre 16 calculées par la tâche 10 ms 13 peuvent être copiées 18, simultanément dans la zone de mémoire 17 de la tâche 5 ms 12a/b ou 19.

Pour arriver au comportement souhaité, la tâche 5 ms 12a/b insère un bit d’information 20 dans la plage de mémoire que peuvent atteindre les deux tâches dès que les calculs dans l’intervalle commun 10 ms sont terminés et ne nécessitent plus d’accès aux données reçues, c'est-à-dire au plus tard à la fin de chaque seconde tâche 5 ms, 12a/b.

De façon analogue, la tâche 10 ms 13 place un bit d’information 21 dès que l’exécution des calculs est terminée et ne nécessite plus d’accès aux données reçues, c'est-à-dire au plus tard à la fin de chaque tâche 10 ms.

La transmission des données entre les tâches se fait à la fin de la tâche 5 ms 12a/b ou à la fin de la tâche 10 ms 13 selon l’évènement qui se produit en dernier. Dans le cas 12a, la tâche 10 ms fait passer les données 22a dans les deux directions car la tâche 5 ms 12a s’est déjà terminée préalablement. Dans le cas 12b, la tâche 5 ms 12b transmet les données 22b car celle-ci s’est terminée après la tâche 10 ms 13.

La reconnaissance de la tâche responsable de la transmission des données se fait à l’aide des bits d’état 20 et 21. Chacune des deux tâches place le bit d’état correspondant lorsqu’elle est prête pour l’échange des données et demande l’autre bit d’état. Lorsque les deux bits sont mis, la communication est faite par l’appel de l’une des fonctions de communication 22a, 22b et les bits d’état sont remis à l’état initial. Par exemple, un bit d’état qui aura été mis définit une zone à la fin de la tâche respective.

De façon générale, un cycle d’une première tâche se place dans la plage de la fin d’un cycle d’une seconde plage si le cycle de la première plage se termine pendant le cycle de la seconde tâche dans une plage dans laquelle la seconde tâche est prête pour l’échange de données. De façon préférentielle, la durée du cycle de la première tâche est plus courte que la durée du cycle de la seconde tâche. Ainsi, par exemple un cycle de la première tâche se place par exemple chronologiquement, dans la plage de la fin du cycle de la seconde tâche si la première tâche commence après le début de ce cycle de la seconde tâche et il se termine dans la plage dans laquelle la seconde tâche de ce cycle est prête pour l’échange des données.

Les bits d’état 20 et 21 sont protégés contre un accès simultané par les deux tâches. L’opération de copie ou de communication proprement dite est toutefois non verrouillée et sans attente.

Dans le cas idéal, les fonctions 22a et 22b responsables de la transmission des données sont identiques et sont appelées à la fin de l’une ou de l’autre tâche. De façon préférentielle, ces fonctions sont générées selon les relations de communication, en étant soutenues par le matériel.

Les exemples de programmes suivants montrent schématiquement comment arriver au comportement souhaité dans l’exemple d’une communication entre une tâche 5 ms et une tâche 10 ms : A la fin de la tâche dont la durée de détection est la plus courte 12/b ou 19, on insère un code programme analogue à ce qui suit selon les expressions anglo-saxonnes usuelles dans cette technique : END_5 ms:

Counter _5 ms = counter_5 ms - 1 If (counter_5 ms == 0 {

Protection_on 5 ms_ready = true

If (10 ms_ready == true) copy = true

Protection_off

Counter_5 ms = 2 ! Rapport des durées de détection }

If (copy == true) {

Call copydata ! Fonction générée pour copier les 5 ms_ready = false données dans les deux directions 10 ms_ready = false Copy = false } A l’aide d’un compteur (counter 5_ms), on vérifie tout d’abord si des données doivent être échangées dans cette étape. Cela ne concerne que les tâches de durée de détection la plus courte ; pour les autres cas, on supprime le compteur.

Dans l’exemple de la figure 3, la tâche 10 ms 13 ne nécessite pas de compteur car dans chaque étape, on échange les données avec la tâche 5 ms 12a/b plus rapide.

Dans la mesure où l’on constate à l’aide du compteur qu’il faut échanger les données, on vérifie quelle tâche est responsable de l’échange des données. Avant d’interroger le bit d’état correspondant et de manipuler, il faut s’assurer que les deux tâches participant à la communication n’accéderont pas simultanément. Pour cela, dans la majorité des cas, il faut des mécanismes de protection supplémentaires (protection_on/ protection_off) insérés dans le code programme pour garantir les valeurs consistantes des états « 5 ms_ready » et « 10 ms_ready ». Avec les mécanismes connus du système de gestion, on garantit qu’à chaque fois, seulement l’une des deux unités de programme concernées puisse accéder à la plage protégée par une « protection ». Selon la répartition de la tâche entre les unités d’exécution, le mécanisme de protection agit localement seulement sur une unité d’exécution, c'est-à-dire sur le noyau de calcul local, par exemple en ce que l’on interdit pendant une courte durée, le changement de tâche, ou encore au-delà des limites du noyau de calcul par exemple par l’utilisation de spin-Locks (verrous tournants).

Après le placement du bit de commande « 5 ms_ready », pour signaler que la tâche 5 ms est prête à émettre et recevoir des don- nées, on vérifie l’état de l’autre tâche à l’aide du bit de commande « 10 ms_ready ». Si ce bit est également mis, la tâche 10 ms est prête à échanger et la communication peut se faire immédiatement ; dans le cas contraire, la communication se fera ultérieurement, à la fin de la tâche 10 ms. A titre d’exemple, on transmet les données d’un cycle 5 ms d’une première unité de programme 31. Le cycle 5 ms dont on transmet les données se situe par exemple dans le temps, dans la plage d’une fin d’un cycle 10 ms de la seconde unité de programme 31. La plage de la fin de cycle de la seconde unité de programme 31 est la plage dans laquelle la seconde unité de programme 31 est déjà prête pour l’échange de données. La plage commence par exemple dès que les calculs dans l’exécution de la seconde unité de programme 31 sont terminés et qu’il n’est plus nécessaire d’accéder aux données reçues. La plage se termine par exemple à la fin du cycle respectif de la seconde unité de programme 31.

Pour que le temps reste court, pendant lequel la protection d’accès (protection) est active, on commande l’exécution de l’action de copie par une grandeur logique « copy » de façon que l’action de copie proprement dite puisse se faire en dehors de la plage protégée. A la fin de la tâche correspondant au temps de détection 13 le plus long, on insère le code programme comme suit : END_10 ms:

Protection_on 10 ms_ready = true

If (5 ms_ready == true) copy = true

Protection_off

If (copy == true) {

Call copydata ! Fonction générée pour copier les 5 ms_ready = false données dans les deux directions 10 ms_ready = false Copy = false }

Le code programme est très analogue au code à la fin de la tâche 5 ms, à la différence que l’on n’a pas de compteur car le contrôle peut se faire à la fin de chaque exécution de la tâche la plus lente.

La figure 4 montre une optimisation en option du procédé de réduction de la demande de temps de mémoire et de calcul qui doit être appliquée dans un système à plus de deux tâches en communication. L’optimisation repose sur le fait qu’en principe toutes les tâches de réception de données, dans la mesure où elles ont une durée de période ou durée de cycle plus petite (ou identique) que celle de la tâche émettant les données, peuvent utiliser les mêmes données reçues.

La figure 4 montre un exemple avec une tâche 20 ms 40 émettant des données et deux tâches 41 et 42 recevant des données, ayant une durée de période plus courte, de 5 ms et 10 ms. La tâche 20 ms 40 inscrit ces données à émettre dans sa plage de mémoire 43. Les tâches plus rapides 41 et 42 ont besoin des données d’entrée de la tâche 20 ms et au moins certaines données d’entrée sont nécessaires aux deux tâches, pour économiser des ressources par cette optimisation. A la fin 44 de l’intervalle commun de toutes les tâches 40, 41, 42 qui participent, on détermine selon un procédé analogue à celui décrit ci-dessus, laquelle des tâches s’est terminée en dernier. Cette tâche appelle alors comme décrit ci-dessus, la fonction de communication 45 ou 46 qui copie les données d’entrée nécessaires aux tâches de réception 41 et 42 à partir de la plage de mémoire 43 vers la plage de mémoire 47. A titre d’exemple, la fonction de communication 45 est appelée à la fin du premier intervalle commun de la tâche 20 ms 40 car cette tâche se terminera après les tâches 41 et 42. A la fin du second intervalle commun, la tâche 5 ms 42 se termine la dernière et appelle la fonction de communication 46.

La plage de mémoire 47 contient toutes les données de sortie de la tâche 20 ms 40 qui sont nécessaires à l’une des deux tâches réceptrices 41 et 42 ou par les deux, comme données d’entrée. Les deux tâches réceptrices lisent leurs données d’entrée dans la même plage de mémoire 47.

Il en résulte qu’il suffit de copier et d’enregistrer une seule fois dans la plage de mémoire 47, les données d’entrée nécessaires aux deux tâches réceptrices, ce qui permet d’économiser de la place de mémoire et du temps de calcul.

En revanche, la logique pour déterminer la tâche qui exécute l’action de communication est plus complexe car plus de deux tâches possibles sont maintenant concernées. En tenant compte de la répartition des tâches réceptrices entre les unités de calcul, on détermine une combinaison optimale entre le temps de fonctionnement et la place de mémoire.

La figure 4 montre la communication seulement dans une direction. Les fonctions de communication 45 et 46 peuvent toutefois se faire également dans l’autre direction, c'est-à-dire à partir des zones de mémoire de sortie des tâches les plus rapides 41 et 42 vers la zone de mémoire d’entrée de la tâche 20 ms 40.

La figure 5 montre une optimisation en option du procédé qui peut s’appliquer dans un système à plus de deux tâches en communication. L’optimisation permet en tenant compte de la répartition de programme, de l’échéancement et/ou des données copiées, de décaler les opérations de copie de la fin d’un intervalle au début de l’intervalle suivant.

Ainsi, on évite de manière ciblée les pointes de charge par le chevauchement des différentes longueurs d’intervalle et la charge est encore plus rectifiée pour le système de bus en dessous. A la figure 5, une tâche 5 ms 50 communique avec une tâche 10 ms 51 chaque fois à la fin de l’intervalle comme décrit ci-dessus.

La fonction de communication 52 est appelée comme décrit, chaque fois à la fin de la tâche qui se termine la dernière dans l’intervalle commun.

La communication 53 entre la tâche 10 ms 51 et la tâche 20 ms 52 est décalée, au début du nouvel intervalle pour les raisons indiquées. Au début de chaque seconde tâche 10 ms 51, on appelle la fonction de communication 54 qui a copié les valeurs calculées dans l’intervalle précédent entre les tâches, dans les deux sens chaque fois dans les plages de mémoire correspondantes (cela n’est pas représenté).

Cela fonctionne sans autre moyen s’il est certain que le partenaire de communication, c'est-à-dire dans ce cas, la tâche 20 ms 52, est appelé la seulement lorsque la communication est terminée. Cela est automatiquement le cas si par un échelonnement fondé sur la priorité, les deux tâches sont activées dans la même unité d’exécution et si la communication est faite par la tâche de priorité la plus élevée, c'est-à-dire dans ce cas, la tâche 10 ms qui est la plus rapide.

La figure 6 montre une variante en option du procédé dont le comportement s’écarte du schéma décrit ci-dessus de « Logical Execution Time » LTG. L’objectif est de réduire le temps de passage du signal (latence) dans une chaîne de signaux tout en conservant un comportement déterministique.

Une tâche 5 ms 60 communique avec une tâche 10 ms 61. La communication 64 entre la tâche 61 la plus lente vers la tâche 60 la plus rapide se fait toujours à la fin de l’intervalle commun et elle est exécutée chaque fois par la tâche 61a ou 60c qui se termine en dernier, par l’appel des fonctions de communication 62 ou 63.

La communication 65 de la tâche 5 ms 60 la plus rapide vers la tâche 10 ms 61 ne se fait toutefois pas à la fin de l’intervalle commun mais directement après la première exécution de la tâche 5 ms 60a ou 60b la plus rapide dans l’intervalle commun.

La condition pour ce type de communication est d’exécuter d’abord la tâche réceptrice 61a ou 61 la plus lente si la communication a été établie, c'est-à-dire à la fin de la tâche 60a ou 60b. Cela est automatiquement le cas pour un ordonnancement à taux monotone, commandé en priorité, si les deux tâches sont exécutées par la même unité d’exécution c'est-à-dire le même noyau de calcul car dans ce cas, les tâches les plus rapides ont une priorité d’exécution supérieure à celle des tâches les plus lentes.

Si les tâches sont traitées par des unités d’exécution différentes, la tâche la plus lente 61a ou 61 sera activée à la fin de la tâche émettrice 60a ou 60b.

Grâce à cette variante de l’invention, pour les chaînes de signaux d’activité qui, sur le trajet, par exemple allant d’un capteur, par exemple le capteur 34 de la figure 1 vers un actionneur, par exemple l’actionneur 35 de la figure 1, se font par une tâche rapide puis une tâche plus lente, on réduit le temps de passage (latence) ce qui est avantageux pour les applications en technique de régulation.

Dans cette variante, on répartit les tâches entre les unités d’exécution en tenant compte des dépendances entre les espaces de temps d’exécution à l’intérieur des intervalles.

La figure 7 montre la communication entre une tâche 2 ms 70 et une tâche 5 ms 71. La longueur de la tâche 5 ms 71 n’est pas un multiple entier de la longueur de la tâche 2 ms. La communication entre de telles tâches sera appelée ci-après communication non harmonique.

Les procédés décrits ci-dessus partent de limites d’intervalle, communes, se produisant régulièrement, et auxquelles on communique logiquement. Dans le cas d’une communication non harmonique, par exemple entre une tâche 2 ms et une tâche 5 ms, cela n’est le cas que toutes les 10 ms. A de telles limites d’intervalle 72, communes, avec le procédé décrit ci-dessus, on effectue la communication 73 à la fin de l’intervalle commun par la tâche qui s’est terminée la dernière.

Les résultats du calcul de la seconde tâche 2 ms dans l’intervalle commun doivent également être communiqués de manière déterministique à la tâche 5 ms mais dans ce cas, il n’y a pas de limites d’intervalle, communes. Les valeurs ne peuvent être copiées directement dans la mémoire d’entrée 74 de la tâche 5 ms car celle-ci est encore bloquée pour un accès en lecture par la première tâche 5 ms 71a. C’est pourquoi la seconde tâche 2 ms 70a inscrit les valeurs à communiquer à la fin de la tâche par l’appel d’une fonction de communication 75, en inscrivant tout d’abord dans la mémoire intermédiaire 76. La seconde tâche 5 ms 71b copie alors les valeurs de la mémoire intermédiaire 76 dans la mémoire d’entrée 74 au début de la tâche en appelant une fonction de communication 77.

La communication dans l’autre direction allant de la tâche 5 m vers la tâche 2 ms fonctionne de manière équivalente. La première tâche 5 ms copie les valeurs dans une autre mémoire intermédiaire. La quatrième tâche 2 ms, c'est-à-dire la première tâche 2 ms qui est activée après la fin garantie de la première tâche 5 ms dans l’intervalle de 6 ms-8 ms, copie les données de la mémoire intermédiaire dans sa mémoire d’entrée.

La communication à la fin commune de l’intervalle se déroule comme la communication dans l’autre direction, selon l’un des procédés décrits ci-dessus. Les programmes de mission sont de préférence répétés cycliquement. Les intervalles correspondent alors au temps de cycle. La communication se fait de préférence également de manière cyclique.

Les partenaires en communication peuvent être réalisés comme dans le procédé décrit ci-dessus, par les mêmes noyaux de calcul ou des noyaux différents.

Le placement des bits d’état 20 ou 21 se fait de préférence lorsqu’au cours de l’exécution d’une tâche, on n’accède plus aux données d’entrée 17 ou 15 et on ne modifie plus les données de sortie 11 ou 16, c'est-à-dire à un instant qui précède la fin de la tâche. Cela permet de fixer la plage à la fin du cycle de l’unité de programme 31 correspondante.

Les avantages du principe sont regroupés ci-après : 1 . Le procédé selon DE 102 29 520 Al est étendu pour qu’il puisse également s’appliquer à des unités de calcul ayant plusieurs noyaux de calcul, par exemple des processeurs multi-core, en conservant le comportement déterministique et reproductible. Le concept du « Logical Execution Time » LTG s’applique à cela. 2 . Le procédé garantit la cohérence entre les données échangées entre deux tâches, ce qui signifie que toutes les données disponibles au début d’une tâche réceptrice doivent provenir de la même exécution de la tâche émettrice et les données d’entrée ne doivent pas être modifiées pendant que la tâche réceptrice y accède. 3 . Le comportement est soutenu par une unité de programme (tâche) contrôlée par un système de gestion et dont les taux d’activation sont dans un rapport entier fixe, les uns par rapport aux autres (voir figure 1). On peut également avoir plusieurs tâches avec le même taux d’activation. 4 . Le procédé sollicite moins les canaux de communication (par exemple les bus) que la communication qui se fait précisément aux limites d’intervalle comme représenté à la figure 1. 5 . Pour mieux pouvoir utiliser la puissance de calcul disponible, le procédé est très largement sans attente « wait free », ce qui signifie que l’exécution par aucun des partenaires en communication n’est bloquée pour une durée significative, par exemple pour garantir la cohérence des plages de mémoire utilisées en commun. 6 . Le procédé peut être implémenté sans extension dans les systèmes de gestion utilisés habituellement dans le domaine automobile (par exemple AUTOSAR-OS). 7 . Le procédé est optimisé pour économiser des tâches « notification » supplémentaires et réduire les ressources de calcul nécessaires (mémoire, temps de parcours). 8 . Le procédé est optimisé pour que dans certaines conditions, l’utilisation commune des données reçues par plusieurs récepteurs permet d’économiser des ressources (mémoire, temps de parcours). 9 . La communication peut se faire de manière bidirectionnelle, ce qui signifie que dans les espaces de temps lorsqu’il y a une communication entre deux tâches, celle-ci peut se faire dans les deux directions dans la mesure où il y a une demande. Ainsi, l’infrastructure d’exécution (les fonctions, les compteurs et les mémoires d’état) n’est nécessaire qu’une fois par paire de tâches et non pour chaque sens de communication. 10 . Le procédé est optimisé en option de façon qu’en tenant compte de l’architecture de programme et de répartition des programmes, on évite les pointes de charge et on utilise de façon optimale les ressources (mémoire, temps de parcours). 11 . Le procédé offre en option la possibilité de réduire les latences d’une chaîne de signaux d’activité entre plusieurs tâches. 12 . Le procédé peut être étendu en option pour la communication dé- terministique entre les tâches avec des intervalles non harmo- niques, par exemple pour la communication entre une tâche 2 ms et une tâche 5 ms.

Claims

REVENDICATIONS 1°) Procédé de gestion d’un appareil de commande (33), notamment pour un véhicule, l’appareil de commande (33) ayant au moins une unité d’exécution (30) pour exécuter des programmes de tâches (31), on exécute au moins de temps en temps un premier programme (31) et un second programme de tâches (31), le premier programme de tâches (31) fournissant à la fin d’un premier intervalle de temps prédéfini, des données (32) pour le second programme de tâches (31), procédé caractérisé en ce que la transmission des données du premier programme (31) vers le second programme (31) ne se fait qu'après chaque fois la dernière exécution du premier programme (31) à l’intérieur d’un second intervalle de temps prédéfini pour l’exécution du second programme (31), le second intervalle de temps étant plus long que le premier intervalle de temps.
2°) Procédé selon la revendication 1, caractérisé en ce que le premier programme de tâches (31) est appliqué par une première unité d’exécution (30) et le second programme de tâches est appliqué par une seconde unité d’exécution (30) dans l’appareil de commande (33).
3°) Procédé selon l’une des revendications 1 ou 2, caractérisé en ce que la longueur du second intervalle de temps est un multiple entier de la longueur du premier intervalle de temps.
4°) Procédé selon l’une des revendications 1 à 3, caractérisé en ce que les données de la plage de mémoire associée au premier programme de tâches (31) sont transmises directement dans une plage de mémoire associée au second programme de tâches (31).
5°) Procédé selon l’une des revendications 1 à 4, caractérisé en ce qu’ en plus, on exécute un troisième programme de tâches (75, 77) pour transmettre les données de la plage de mémoire associée au premier programme de tâches (31) dans une mémoire intermédiaire (76) et de cette mémoire intermédiaire (76), dans une plage de mémoire associée au second programme de tâches (31).
6°) Procédé selon l’une des revendications 1 à 5, caractérisé en ce que le premier programme de tâches (31) et le second programme (31) ont des durées de cycle différentes, la durée de cycle du premier programme (31) étant inférieure à la durée de cycle du second programme (31), et les données de la plage de mémoire associée au premier programme (31) étant transmises dans une plage de mémoire (114) associée au second programme (31) à l’intérieur du cycle du premier programme (31) qui se situe dans le temps, dans la plage d’une fin de cycle du second programme de tâches (31).
7°) Procédé selon l’une des revendications 1 à 6, caractérisé en ce que dans un premier état de fonctionnement, à l’intérieur d’un intervalle de temps associé au programme de tâches (31) respectif, l’autre programme de tâches (31) n’accède pas à la plage de mémoire associée au programme de tâches (31) respectif, dans un second état de fonctionnement, à l’intérieur de cet intervalle de temps, le programme de tâches (31) respectif n’accède pas à cette plage de mémoire.
8°) Procédé selon l’une des revendications 1 à 7, caractérisé en ce qu’ on associe une première plage de mémoire pour les données d’entrée (17, 15) à un programme de tâches (31), on associe au programme de tâches (31) une seconde plage de mémoire pour les données de sortie (11, 16), une information d’état (20, 21) indique qu’à l’intérieur de l’exécution du programme de tâches (31), avant la fin de l’intervalle de temps actuel, on n’accède plus aux données d’entrée (17, 15) et on ne fait aucune modification des données de sortie (11, 16).
9°) Appareil de commande (33), notamment pour un véhicule automobile, réalisé pour exécuter le procédé selon l’une des revendications 1 à 8, ayant une unité d’exécution (30) pour exécuter des programmes de tâches (31), consistant à exécuter au moins de temps en temps un premier (31) et un second programme de tâches (31), le premier programme (31) fournissant à la fin d’un premier intervalle de temps prédéfini, des données (32) pour le second programme (31), la transmission des données du premier programme de tâches (31) vers le second programme (31) ne se faisant qu'après chaque dernière exécution du premier programme (31) dans un second intervalle de temps prédéfini pour l’exécution du second programme (31), ce second intervalle de temps étant plus long que le premier intervalle de temps.