Brevet FR2922038A1 — publié le 20090410

PROCEDE DE GESTION DES TRAMES DE DONNEES DANS UN BUS DE COMMUNICATION DE TYPE BUS CAN. La présente invention concerne un procédé de gestion des trames de données dans un bus de communication de type bus CAN. Elle concerne également un bus de communication de type bus CAN, qui met en oeuvre un tel procédé de gestion des trames de données, en particulier mais de façon non exclusive, un bus CAN - ou bus de terrain CAN - pour la communication entre des calculateurs embarqués d'un véhicule automobile. Le CAN (acronyme de � Controller Area Network �) est un protocole de communication série qui supporte efficacement le contrôle en temps réel de systèmes distribués tels qu'on peut en trouver dans les véhicules automobiles, avec un très haut niveau d'intégration au niveau des données. Pour satisfaire les exigences de plus en plus importantes du client en matière de sécurité et de confort, et pour se conformer aux règlements de réduction de la pollution et de la consommation de plus en plus drastiques, l'industrie automobile a développé de très nombreux systèmes électroniques : systèmes anti-patinage, contrôle électronique du moteur, de l'air climatisé, fermeture centralisée des portes, etc. De la complexité de ces systèmes et de la nécessité d'échanger des données entre eux, du souci d'éviter des câblages et des connections trop nombreux, de l'exigence de compacité, de fiabilité et de réparation aisée sont nés le protocole et le bus CAN, aptes à intégrer de plus en plus de commandes électroniques et à faire communiquer entre eux à grande vitesse de nombreux contrôleurs, capteurs et actionneurs. La communication entre les calculateurs se fait en série par le biais de messages sous forme de trames. Les trames de données transmises par un noeud sur le bus ne contiennent ni adresse du noeud expéditeur ni adresse du noeud destinataire. C'est le contenu du message, sa signification, qui est précisé par un identifiant. Chaque noeud recevant un message regarde si celui-ci est intéressant pour lui grâce à l'identifiant. Si c'est le cas, il le traite, sinon il l'ignore. Cet identifiant indique aussi la priorité des messages. Si deux noeuds ou plus cherchent à avoir accès au bus en même temps, c'est celui de plus haute priorité qui gagne. Les messages de priorité inférieure seront automatiquement retransmis lorsque le bus sera libre. En d'autres termes, il est interdit que deux stations connectées sur des bus de communication envoient des trames avec le même identifiant, car il est utilisé lors de collisions pour déterminer l'unique trame dont la transmission est poursuivie (la trame avec l'identifiant le plus petit parmi les trames dont la transmission a débuté en même temps) et les autres trames dont la transmission est arrêtée. La communication sur le bus CAN est une communication de type � broadcast � dans laquelle la trame envoyée est reçue par toutes les autres stations. Les calculateurs sont connectés aux bus CAN par l'intermédiaire d'une interface matérielle, qui est le gestionnaire du protocole CAN - désigné aussi � GP � dans la suite du texte. Le gestionnaire du protocole CAN contient des zones de mémoire tampon, désignées aussi � buffers �, pour la transmission et la réception des trames. Ces buffers servent d'intermédiaires de stockage pour les informations transférées et permettent de pallier les inconvénients résultant des différences de débit de traitement et de transmission des unités interconnectées. Le gestionnaire du protocole est géré par un composant logiciel dédié : l'interface CAN. L'interface transmet les trames à transférer au gestionnaire du protocole. Le gestionnaire du protocole CAN possède un nombre limité de buffers, souvent inférieur au nombre de trames différentes à émettre, ce qui a pour conséquence de nécessiter la gestion d'une file d'attente par l'interface CAN pour entreposer temporairement les trames à envoyer lorsqu'il n'y a pas de buffer d'émission libre. Le protocole CAN est basé sur une phase d'arbitrage où tous les gestionnaires de protocole, qui contiennent au moins une trame dans un de leurs buffers, essaient de une trame. Les identifiants des trames à transmis pendant la phase d'arbitrage. Les protocole CAN n'ayant pas la trame avec la élevée, cessent leur transmission et c'est la plus élevée qui est la phase d'arbitrage. Ensuite, le cycle recommence par une phase d'arbitrage, suivie par une phase de transmission jusqu'à ce qu'aucun gestionnaire de protocole CAN ne contienne de trame 15 dans ses buffers. Dans les interfaces de bus CAN connus et largement utilisés de l'art antérieur, la file d'attente des trames est gérée comme une file d'attente de type FIFO (� First In, First Out � pour � Premier arrivé, premier servi �), et de 20 manière la plus fréquente, un seul buffer est utilisé. Dès que le buffer d'émission se libère, la trame en tête de la file d'attente est transférée dans le buffer. Lorsqu'une nouvelle trame est soumise à l'interface CAN pour transmission, elle est stockée dans le buffer si le buffer 25 est libre ou, si le buffer n'est pas libre, elle est ajoutée à la fin de la file d'attente. Cette gestion de la file d'attente et des buffers à pour conséquence des inversions de priorités. Il y a donc nécessité de gérer différemment la file 30 d'attente et les trames, de façon à hiérarchiser les priorités. On connaît déjà des systèmes de gestion de file d'attente dans des réseaux de données, qui connaissent une certaine hiérarchisation. 35 Ainsi, selon le document US 7 058 064 B2, on connaît un système configurable de mise en file d'attente pour comptabilisation de paquets en cours de traitement transmettre transmettre sont gestionnaires de priorité la plus la trame avec la priorité effectivement transmise pendant la phase qui suit informatique. Ce système comporte une pluralité de files d'attente dans un ou plusieurs clusters, un mécanisme d'identification pour créer un identifiant de paquet pour les paquets arrivants, une logique de mise en place pour l'insertion des identifiants de paquet dans des files d'attente et pour déterminer dans quelle file d'attente il faut insérer chaque identifiant de paquet, et une logique de sélection pour sélectionner des identifiants de paquet à partir de files d'attente pour démarrer le traitement informatique de paquet identifiés, le téléchargement de paquets complets, ou pour remettre en files d'attente les identifiants de paquet sélectionnés. Le document US 6 771 653 B1 décrit un système de gestion de file d'attente hiérarchisée dans un noeud de réseau de transmission de données qui supporte différents types de circulation de trames. Le système comporte une mémoire tampon pour mémoriser une trame entrante de type trame identifiable. Une file d'attente est préalablement associée au type de trame de la trame entrante de telle sorte que, lors de l'arrivée de la trame au noeud de réseau, la file d'attente mémorise une adresse d'emplacement auquel la trame est stockée dans la mémoire tampon pour que la trame soit maintenue dans la file d'attente. La file d'attente qui contient la trame est mémorisée dans une table de trames. Des moyens de traitement informatique sont prévus pour déterminer un temps auquel la file d'attente transfère la trame de la mémoire tampon selon une liste de priorité des sous files d'attente prédéterminée. Le système comporte, de plus, des moyens de mesure du temps associés à la trame pour attribuer temporairement la trame à une sous file virtuelle parmi de nombreuses sous files virtuelles qui sont associées à la file d'attente. Les sous files sont numérotées séquentiellement selon ladite liste de priorité, de telle façon que les moyens de traitement sélectionnent une trame à priorité élevée pour transfert à partir de la mémoire tampon. On connaît aussi, selon le document US 2005/0228873, un système qui classe des données selon un critère de priorité. Un serveur envoie les données et utilise la priorité pour le classement. Selon l'objet de ce document, le tri des trames se limite aux trames envoyées par le serveur vers le client, en réponse à des demandes de ce client. Le classement est basé sur une indication de � priorité relative � dans la demande envoyée par le client. A titre d'exemple également, selon le document US 2003/0056000 Al, sont connus un procédé et un système d'enregistrement de trames reçues qui permettent de garantir que les trames prêtes au transfert - ou trames TR (TR pour � Tranfer Ready �) - parmi les trames reçues sont prises en charge avec la priorité la plus élevée, et de cette façon avec un temps d'attente plus faible que pour les autres trames. A une sortie connectée à un ou plusieurs dispositifs peut être attribuée une file d'attente supplémentaire pour ces trames TR. La priorité donnée aux trames sur cette file d'attente supplémentaire est plus élevée que celle donnée aux trames des autres files d'attente. Les trames TR sont ajoutées à la file d'attente à plus haute priorité, et les autres trames à la file d'attente à plus faible priorité. Les trames sur la file d'attente à plus haute priorité sont transférées avant les trames sur la file d'attente à plus faible priorité. Les trames sont, ainsi, classées dans un ordre à deux niveaux, à savoir la catégorie de la trame (trame TR ou non) et l'ordre d'arrivée lorsque les trames sont de même catégorie. Toutefois, le domaine d'application de tous ces systèmes et procédés, connus et cités à titre d'exemples de l'art antérieur, est le domaine des réseaux de données de type Internet, dans lequel les trames n'ont pas un identifiant de type CAN ou sont alors triées selon des critères qui ne sont pas ceux de la présente invention. Le but de la présente invention est de fournir un nouveau procédé de gestion des trames de données dans un bus de communication de type bus CAN, qui permette d'éviter les inversions de priorité. Un autre but de la présente invention est de fournir un tel procédé de gestion qui permette de réduire les délais 5 de transmission de toutes les trames. Un autre but de la présente invention est de fournir un bus de communication de type CAN pour la mise en oeuvre d'un tel procédé, qui permette une meilleure exploitation de la bande passante du bus, de manière à ne pas devoir 10 recourir à l'introduction de bus CAN additionnels et à économiser le coût de gestionnaires de programme. Pour parvenir à ces buts, la présente invention conçoit un nouveau procédé de gestion des trames de données dans un bus de communication de type bus CAN. Le bus CAN 15 comprend, de manière conventionnelle, un gestionnaire du protocole CAN avec des zones de mémoire pour la réception et l'émission des trames et un composant logiciel dédié - ou interface CAN - qui � stocke � les trames dans une file d'attente et transmet les trames à transférer au 20 gestionnaire du protocole. Selon le nouveau procédé de gestion de l'invention, les trames dans la file d'attente sont rangées selon l'ordre croissant des identifiants des trames qui correspond à l'ordre de priorité des trames, la trame de plus petit identifiant et, par conséquent, la plus 25 prioritaire, étant toujours en tête de la file d'attente. De préférence, la zone de mémoire du gestionnaire du protocole CAN comporte au moins trois buffers utilisés en émission, de manière à assurer que le gestionnaire du protocole puisse toujours participer aux arbitrages 30 lorsqu'il a au moins une trame à envoyer. De préférence également, des trames peuvent être déplacées à la fois de la file d'attente de l'interface vers les buffers du gestionnaire du protocole CAN et des buffers du gestionnaire du protocole vers la file d'attente de 35 l'interface, de sorte que les trames les plus prioritaires se trouvent toujours dans les buffers d'émission du gestionnaire du protocole CAN. L'invention propose également un nouveau bus de communication de type bus CAN, dans lequel les trames de données reçues sont traitées selon le procédé de gestion décrit ci-dessus dans ses grandes lignes. Enfin, la présente invention propose un véhicule, en particulier un véhicule automobile, qui comprend une pluralité de calculateurs électroniques embarqués qui communiquent entre eux au moyen d'un bus de communication de type CAN conforme à celui de la présente invention. Selon un mode de réalisation particulier, le procédé de gestion de la présente invention s'applique au logiciel de pilotage des communications du concept d'architecture électrique et électronique standardisé connu sous le nom AUTOSAR (acronyme de AUTomotive Open System Architecture). D'autres buts, avantages et caractéristiques de l'invention apparaîtront dans la description qui suit d'un mode de réalisation préféré, non limitatif de l'objet et de la portée de la présente demande de brevet, accompagnée de dessins dans lesquels : - la figure 1 illustre, de manière schématique, un bus CAN avec une gestion de la file d'attente conforme à celle connue des bus CAN de l'art antérieur, - la figure 2 illustre, de manière schématique, un bus CAN avec une gestion de la file d'attente conforme au procédé de gestion des trames de données de la présente invention, - la figure 3 est un diagramme UML d'état illustrant le comportement de l'interface CAN, - la figure 4 est un diagramme UML d'activité 30 illustrant le placement d'une nouvelle trame dans les buffers d'émission ou la file d'attente, et - la figure 5 est un diagramme UML d'activité illustrant le remplissage d'un buffer libéré. En référence à la figure 1, on va décrire le procédé 35 de gestion des trames de données dans un bus de communication de type bus CAN, tel qu'il est connu de l'art antérieur. Le bus CAN est référencé 1000. I illustre, de manière schématique, l'interface ou composant logiciel dédié, qui gère le gestionnaire du protocole CAN, référencé � GP �, du bus CAN. La file d'attente de trames, désignée F, est gérée, comme déjà mentionné précédemment, comme une file dite � FIFO � et un seul buffer d'émission est utilisé. Dès que le buffer d'émission B se libère, la trame tr 55, en tête de la file d'attente F, est transférée dans le buffer d'émission B. Lorsqu'une nouvelle trame est soumise à l'interface I pour transmission, elle est stockée dans le buffer si le buffer est libre ou, si le buffer n'est pas libre, elle est ajoutée à la fin de la file d'attente F. Cette gestion de la file d'attente et des buffers à pour conséquence des inversions de priorités. Ainsi, la trame tr 6, de priorité élevée, est bloquée dans la file d'attente F, bien que la trame tr 105, de priorité plus faible, se trouve dans un buffer d'émission B. Le principe de gestion de la présente invention est illustré par le dessin de la figure 2, dans lequel les éléments et composants identiques ou similaires aux éléments et composants de la figure 1 sont désignés par les mêmes références numériques. La file d'attente F est triée selon la priorité des trames ; la trame tr 55, qui a l'identifiant le plus petit, est la trame la plus prioritaire et se trouve en tête de file, devant la trame tr 105, qui a un identifiant plus grand et est donc moins prioritaire, la trame tr 105 étant elle-même devant la trame tr 218, qui a un identifiant encore plus grand et est donc encore moins prioritaire. Au moins trois buffers du gestionnaire de protocole CAN, désigné également GP, sont utilisés en émission, de manière à assurer que le gestionnaire du protocole GP puisse toujours participer aux arbitrages lorsqu'il a au moins une trame à envoyer. De plus, des trames sont déplacées à la fois de la file d'attente F vers les buffers et des buffers vers la file d'attente F, de sorte que les trames les plus prioritaires se trouvent dans des buffers d'émission. La flèche � d � illustre le déplacement de la trame 105 d'un buffer (la figure 1) à la file d'attente (figure 2), tandis que la trame 6, la plus prioritaire, est déplacée de la file d'attente F à un buffer d'émission B (flèche d' de la figure 2). Ainsi, selon l'invention, la trame tr 6 se trouve dans un buffer d'émission et n'attend que la fin de la 10 transmission de la trame tr 5. Le procédé de gestion des trames de la présente invention permet d'éviter toute inversion de priorité, d'où il résulte la propriété souhaitée suivante : plus une priorité de trame est élevée, plus court sont ses délais de 15 transmission. Le diagramme UML d'état de la figure 3 illustre le comportement de l'interface CAN. L'interface I a deux traitements informatiques à réaliser : un premier traitement T1 de placement d'une nouvelle trame, et un second 20 traitement T2 de remplissage d'un buffer libéré. De manière plus précise : Selon T1, une nouvelle trame est placée dans les buffers ou en file d'attente F, suite à une soumission de nouvelle trame, et 25 selon T2, un buffer est rempli avec la trame en tête de la file d'attente F, suite à une notification de fin de transmission. La figure 4 est un diagramme UML d'activité illustrant le placement d'une nouvelle trame dans les buffers 30 d'émission ou la file d'attente (traitement T1). La nouvelle trame est désignée tr. Si la file d'attente F est vide et si un buffer B est libre, la nouvelle trame tr est insérée (étape 50) dans le buffer libre. Si la file d'attente est vide et si aucun 35 buffer n'est libre, la priorité de la nouvelle trame Ptr est comparée en 20 à la priorité des trames dans les buffers désignée Ptrb. Si la file d'attente n'est pas vide, la priorité de la nouvelle trame Ptr est comparée en 10 à la priorité de la trame en tête de file d'attente Ptrti et si Ptr > Ptrti, alors la priorité de la nouvelle trame Ptr est également comparée en 20 à celles des trames dans les buffers. Si la priorité de la nouvelle trame Ptrest plus élevée que les priorités des trames dans les buffers, c'est-à-dire si Ptr > Ptrb , alors la trame la moins prioritaire des buffers est retirée (étape 30) et cette trame retirée des buffers est insérée dans la file d'attente selon sa priorité (étape 40), ce qui permet alors d'insérer la nouvelle trame dans le buffer libre (étape 50). Dans le cas encore où la file d'attente n'est pas vide, mais où la priorité de la nouvelle trame Ptr est inférieure à celle de la trame en tête de file d'attente Ptrti (Ptr Si la file d'attente n'est pas vide, la trame en tête de la file est retirée (étape 70) et celle-ci est insérée dans le buffer libre (étape 80). On notera qu'une zone mémoire du gestionnaire de protocole CAN comportant trois buffers constitue un mode de réalisation optimal sur le plan technico-économique, parce que les autres buffers du gestionnaire de protocole GP servent à la réception filtrée des trames. La présente invention, telle que décrite ci-dessus, s'applique particulièrement bien dans le logiciel de pilotage des communications du concept d'architecture électrique et électronique standardisé connu sous le nom AUTOSAR, comme déjà mentionné précédemment. La gestion de la file d'attente et des buffers en émission selon la présente invention permet d'éviter une inversion des priorités, parce que les trames avec une priorité plus importante, c'est-à-dire les trames avec un identifiant plus petit, ne sont pas bloquées dans la file d'attente par des trames de priorité faible. En évitant de cette manière les inversions des priorités, on aboutit au résultat souhaité que plus la priorité d'une trame est élevée, plus court sont ses délais de transmission. Ce résultat souhaité a pour conséquence favorable que la bande passante du bus CAN peut être exploitée plus efficacement, parce qu'il est alors possible de choisir les priorités des trames en fonction des contraintes sur les délais de transmission. Enfin, dans un contexte de besoins de communication croissants, cette meilleure exploitation de la bande passante du bus CAN offre l'avantage d'éviter de recourir à des bus CAN additionnels et, par conséquent, offre l'avantage d'économiser le coût d'un gestionnaire de protocole CAN. Bien entendu, la présente invention n'est pas limitée au mode de réalisation décrit et représenté ci-dessus à titre d'exemple ; d'autres modes de réalisation peuvent être conçus par l'homme de métier sans sortir du cadre et de la portée de la présente invention. REVENDICATIONS 1. Procédé de gestion des trames de données dans un bus de communication de type bus CAN, comprenant un gestionnaire du protocole (GP) avec des zones de mémoire pour la réception et l'émission des trames et un composant logiciel dédié (I) - ou interface CAN - qui stocke les trames dans une file d'attente (F) et transmet les trames à transférer au gestionnaire du protocole, caractérisé en ce que les trames dans la file d'attente (F) sont rangées selon l'ordre croissant des identifiants des trames qui correspond à l'ordre de priorité des trames, la trame de plus petit identifiant et, par conséquent, la plus prioritaire, étant toujours en tête de la file d'attente (F). 2. Procédé selon la revendication 1, caractérisé en ce que la zone de mémoire du gestionnaire de protocole (GP) comporte au moins trois buffers utilisés en émission, de manière à assurer que le gestionnaire de protocole (GP) puisse toujours participer aux arbitrages lorsqu'il a au moins une trame à envoyer. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que des trames peuvent être déplacées à la fois de la file d'attente (F) vers les buffers du gestionnaire de protocole (GP) et des buffers du gestionnaire de protocole (GP) vers la file d'attente (F), de sorte que les trames les plus prioritaires se trouvent toujours dans les buffers d'émission du gestionnaire de protocole (GP). 4. Bus de communication de type bus CAN, comprenant un gestionnaire du protocole (GP) avec des zones de mémoire pour la réception et l'émission des trames et un composant logiciel dédié (I) - ou interface CAN - qui stocke les trames dans une file d'attente (F) et transmet les trames à transférer au gestionnaire du protocole, caractérisé en ce que les trames de données reçues sont traitées selon le procédé de gestion conforme à l'une quelconque des revendications 1 à 3. 5. Véhicule, en particulier véhicule automobile, comprenant une pluralité de calculateurs électroniques embarqués qui communiquent entre eux au moyen d'un bus de communication de type CAN, caractérisé en ce que ledit bus de communication est conforme à la revendication 4. 6. Véhicule selon la revendication 5, caractérisé en ce que lesdites communications entre les calculateurs embarqués sont intégrées dans un système de pilotage standardisé de type AUTOSAR, connu en soi.