FR2999367A1 - Procede de transmission de donnees dans des unites de commande ecu et/ou des dispositifs de mesure dans le domaine automobile - Google Patents

Abstract

Procédé de transmission de données dans des unités de commande électronique appelé « unité ECU » et/ou des dispositifs de mesure dans le domaine des véhicules automobiles. L'architecture de la transmission des données est divisée en un plan-commande implémenté par programme travaillant sur la configuration , le calibrage et/ou des diagnostics appelés « CD », des données et un plan-données implémenté dans une mesure de transport de circuit appelé « M », des données et/ou des prototypes appelés « données RP ».

Description

Domaine de l'invention La présente invention se rapporte à un procédé de transmission de données parmi les unités de commande électronique appelées ci-après « unité ECU » et/ou des dispositifs de mesure dans le domaine des véhicules automobiles. L'invention se rapporte en outre à un module d'interface ECU, ainsi qu'à un module ECU et à un dispositif de mesure. Etat de la technique Le nombre d'unité de commande électronique et en parti- culier d'unités de commande de moteur (unité ECU) dans les véhicules automobiles et leur interaction augmente de plus en plus. Par exemple, les nouvelles techniques d'entraînement conduisent à des boucles de commande plus rapides et le système Ethernet commence à compléter, voire remplacer, les techniques d'interconnexion traditionnelles dans les véhicules tels que les systèmes CAN, FlexRay, LIN et MOST. Ces développements se traduisent par une augmentation rapide du débit de données et une demande d'équipement en temps réel pour les unités ECU et les modules d'interface ECU intégrés. La génération future des interfaces ECU passera alors de l'Ethernet rapide à l'Ethernet Gigabit dans les systèmes de diagnostic, de calibrage et de mesure répartis (système MCD). Les systèmes de prototype rapide intégrés (système RPR) utilisent les techniques expresses PCI pour répondre aux exigences de latence et de gigue. La solution traditionnelle utilisant les programmes et qui est fondée sur la qualité de service (QoS) et le traitement par protocole ne permet pas de traiter une très grande diversité de protocoles dans des couches multiples selon les caractéristiques exigées. Les normes traditionnelles de protocole dans le domaine automobile et le diagramme de référence correspondant connu selon l'état de la technique sont fondées sur un modèle de programme client- serveur. Un client fonctionnant avec un ordinateur personnel standard puissant logeant une application MCD de programme ou un programme de prototype, fonctionne comme un protocole maître, intelligent et le module d'interface ECU intégré dans le serveur, fonctionne comme un protocole esclave d'exécution des commandes.

Dans les standards de protocole du domaine automobile, connu, seule la couche de liaison dans le serveur est implémentée en utilisant un programme de contrôleurs standards (contrôleur CAN, contrôleur FlexRay, contrôleur d'accès média Ethernet ou des contrôleurs similaires). Les couches de protocole supérieures telles que la couche réseau, la couche transport et les couches de service de protocole automobile sont toutes implémentées dans des programmes fonctionnant dans le dessus du système en temps réel avec des supports en circuit standard, limités, tels qu'une mémoire accès direct (mémoire DMA).

Implémenter des piles de couches de protocoles multiples sur le dessus des couches de liaison différente dans un jeu très limité d'unités centrales de traitement CPU nécessite la mise en série du traitement associé à des évènements de données d'entrée (trame) asynchrone utilisant les services et les procédés de mise en liaison de programmes assurés par le système d'exploitation sous-jacent. Toutefois, la mise en série et la commutation de contexte associé à la technique de toron (threading) limite le débit maximum d'évènements. Cette restriction du débit d'évènements constitue le goulot d'étranglement principal de tous les systèmes en temps réel basés sur un programme. Il en résulte une augmentation de la latence IO et de la gigue pour les applications de prototype, une augmentation du temps des boucles pour les transactions et un débit limité des mesures à cause des limitations du débit des trames dans le réseau. L'optimisation des caractéristiques de systèmes en temps réel fondés sur programme est difficile voire impossible à réaliser à cause de l'étranglement des débits d'évènements pour réduire les corruptions de commutation de contexte de prototype et d'exigence de latence faible des plan de commande. On détériore la consommation des modules interfaces ECU et on ne peut accélérer efficacement la conversation de données de débit de bits élevées, simples (en général, un protocole de connexion de transmission simple TCP) puisque l'organisation du paquet de conversation interdit le traitement en parallèle des paquets. But de l'invention La présente invention a pour but de développer un pro- cédé de transmission de données du type défini ci-dessus permettant d'accélérer la transmission des données en particulier avec des temps de cycle d'évènements particulièrement rapides (temps réduit) une faible gigue et un fort débit de données. Exposé et avantages de l'invention A cet effet l'invention a pour objet un procédé de trans- mission de données du type défini ci-dessus dont l'architecture de transmission de données est divisée en un plan-commande implémentés dans les programmes travaillant sur la configuration, les données de calibrage et/ou de diagnostic (CD) et le plan-données implémenté dans le circuit de transport de données de mesure M et/ou de données de prototype RP. L'invention propose un composant qui implémente un nouveau paradigme de circuit fondé sur le traitement de protocole multicouche et un circuit fondé sur coefficient QoS dans des modules d'interface ECU intégrés. Cette nouvelle architecture améliore les carac- téristiques par rapport à la technique actuelle. L'invention propose une nouvelle technique utilisant de nouvelles considérations d'architecture. Ainsi, selon les caractéristiques multiservices des protocoles dans le domaine automobile, l'architecture est d iv isée en un plan-commande implémenté par programme d'exploitation sur des données de configuration de calibrage et de diagnostic (données CD) en les transportant de préférence en utilisant des transactions T et un plan-données implémenté dans le circuit transportant les données de mesure M et les données de prototype RP de préfé- rence transportées en utilisant des flux de données sans état S. L'implémentation du plan-données dans un circuit a plusieurs avantages essentiels par rapport à l'état de la technique à savoir : - plan-données optimisé pour un traitement très rapide des évènements dans des temps de cycles d'évènements inférieurs a 360 ns et dans certains cas même inférieurs à 200 ns (les programmes connus ont une approche supérieure à 50 ps). - Plan-données optimisé pour une très faible gigue inférieure à 2 ps (les programmes de l'état de la technique ont des designs de l'ordre de ps). - Plan-données optimisé pour un débit élevé de données allant jusqu'à 2,8 Gbit/s et dans certains cas même jusqu'à 5,0 Gbit/s (la solution par programme de l'état de la technique : inférieure à 100 Mbit/s). On aura une optimisation particulièrement effi- cace, par exemple dans le cas d'un développement ASIC à la place d'un développement FPGA. Selon l'invention, on utilise les termes suivants avec leur définition : Réception = réception de données d'une ligne externe. Transmission = transmission sur une ligne externe. Avancer = avancer les données d'un dispositif vers un coeur de processeur de données et en outre vers un dispositif.

Ainsi la séquence est toujours la suivante : Recevoir -> Avancer. Selon un développement préférentiel, les données à avancer ou le flux de données sont segmentés en des multiples segments de données du côté du dispositif récepteur avant que les données ne soient avancées. Il est de plus possible d'imbriquer les segments de données avant d'envoyer (avancer) les données. Enfin, il est avantageux que les segments de données des différents dispositifs récepteurs soient multiplexés avant que les données ne soient avancées. Le multiplexage peut se faire alternativement ou en plus de l'imbrication avant ou après le procédé d'imbrication. Puis les segments de données sont avancés sé- quentiellement. Si plus d'un dispositif veut avancer les données, en fonction du résultat de l'imbrication et/ou du procédé de multiplexage, l'avancement des données est commuté entre les segments de données d'un premier dispositif des segments de données et ceux d'un autre dispositif. Après avoir avancé les segments de données, le dispositif de transmission collecte les segments de données dans des unités de don- nées pour l'interface du dispositif de sortie ou la ligne. Ainsi, sur le plan microscopique (inférieur à 1 ps) les données ou les segments de données sont avancés séquentiellement. Toutefois, sur le plan macroscopique (supérieur à 10 ps), l'avancement des données se fait en parallèle (ou de manière quasi-parallèle) car la commutation de l'avancement des données entre les segments de données du premier dispositif et les segments de données d'un autre dispositif se fait très rapidement. Cela est possible seulement parce que le plan-données est implémenté sous la forme d'un circuit qui permet une commutation rapide de contexte.

La commutation de contexte consiste à enregistrer et à rétablir l'état (contexte) d'une unité de traitement ce qui permet de reprendre l'exécution à partir du même point à un instant ultérieur. Cela permet à des procédés multiples de partager un unique traitement. La commutation de contexte est une caractéristique essentielle des systèmes multi- tâches. Contrairement à cela, selon l'architecture de programme de l'état de la technique, la commutation, l'avancement des données entre les segments de données du premier dispositif et ceux d'un autre dispositif se fait beaucoup plus lentement. Cela provient du fait que la commutation dans l'architecture de programme utilise plusieurs étapes de registre de sauvegarde, d'enregistrement du contexte courant, de libération de l'unité CPU pour un nouveau contexte et ainsi de suite. La commutation de contexte prend beaucoup plus de temps si elle est réalisée par programme que si elle se fait dans un circuit. L'une des rai- sons est que la commutation de contexte par programme consomme beaucoup de temps pour chaque interruption de programme. Le fonctionnement du circuit fondé sur l'implémentation du plan-données selon l'invention et du module d'interface ECU respectif peut être comparé à un coprocesseur pour accélérer la transmission des données parmi les unités ECU et/ou les dispositifs de mesure. Un coprocesseur conventionnel assiste l'unité CPU pour le traitement des données. A la différence de l'invention, par rapport à un coprocesseur conventionnel il y a le fait que toutes les données qui doivent être traitées par le coprocesseur, passent d'abord par l'unité de traitement avant d'être traitées par le coprocesseur. Cela est différent dans un cir- cuit fondé sur une implémentation par plan-données selon l'invention et le module d'interface ECU. Selon l'invention toutes les données à transmettre traversent le plan-données fondé sur le circuit et le module d'interface ECU respectivement. Les unités ECU et leur CPU respectif sont significativement libérées du traitement et de la manipulation des données pour avancer les données. De façon préférentielle, le plan-données commute les commandes et les réponses des transactions et/ou les flux vers et en provenance des unités ECU et/ou des dispositifs de mesure. Toutefois, il faut remarquer que contrairement par exemple au commutateur -CI Express, la commutation du plan-données ne connaît pas la transaction. Dans les commutations PCI Express, l'unité de commutation se souvient du chemin de la commande et utilise cette information pour les réponses dans le sens inverse. Selon la présente invention les deux chemins doivent être configurés au préalable. La présente invention est utilisée de préférence dans le domaine automobile. Elle peut être réalisée sous la forme d'un module interface ECU situé entre une première unité ECU et une seconde unité ECU et un dispositif de mesure relié à la première unité ECU. De plus, elle peut être réalisée dans un dispositif de mesure qui peut être connecté à une ou plusieurs unités ECU du véhicule pour piloter et/ou contrôler leur fonctionnement et leur travail. De plus, l'invention peut être réalisée dans une unité de commande de passerelle d'une unité ECU. En d'autres termes, l'invention peut également être implémentée directement dans l'unité ECU. Dessins La présente invention sera décrite ci-après de manière plus détaillée à l'aide d'exemples de procédés de transmission de don- nées entre des unités de commande électroniques représentés dans les dessins annexés dans lesquels : - la figure 1 montre une implémentation client-serveur d'un MCD et d'un système de prototype connu selon l'état de la technique, - la figure 2 montre une implémentation de plan-données et de com- mande d'un MCD et d'un système de prototype selon un mode de réalisation préférentiel de l'invention, - la figure 3 montre une implémentation de plan-données et de commande d'un MCD et d'un système de prototype selon un autre mode de réalisation préférentiel de l'invention, - la figure 4 montre une architecture pipeline de plan-données (processeur de données) de l'implémentation selon la présente invention, - la figure 5 montre un modèle d'information de processeur de données de l'implémentation selon la présente invention, - la figure 6 montre un maillon montant XCP sur une architecture TCP selon une implémentation de l'invention, et - la figure 7 montre un maillon montant XCP sur une architecture TCP (débit élevé) et d'un prototype maillon montant RTIO (faible latence) de l'implémentation selon l'invention.

Description de modes de réalisation de l'invention Les standards de protocole d'automobile et les diagrammes de référence correspondant, connus selon l'état de la technique reposent sur un modèle client-serveur piloté par programme dont un exemple est présenté à la figure 1. Un client fonctionnant par exemple avec un ordinateur personnel standard, puissant, logeant une application de mesure de calibrage et de diagnostique (application MCD) ou de programme de prototype, fonctionne comme un maître de protocole intelligent et un serveur dans le module d'interface intégré ECU fonctionne comme un esclave de protocole exécutant des ordres.

Seule la couche de liaison du serveur est implémentée avec un circuit de contrôleur standard (contrôleur CAN, contrôleur Flexray, contrôleur d'accès média Ethernet ou contrôleurs similaires). Les couches supérieures de protocole comme la couche réseau, la couche transport et les couches de service de protocole automobile sont implémentée dans un programme tournant sur un système fonction- nant en temps réel avec un support de circuit standard telle qu'une mémoire à accès direct (DMA). La couche de protocole multiple d'implémentation s'empile au-dessus de différentes couches de liaisons avec un jeu très limité d'unités centrales de traitements CPU qui nécessitent la mise en série du traitement associé à des évènements de données d'entrée asynchrones (trames) utilisant des procédés de mise en file de services et de programmes fournis par le système de fonctionnement sous-jacent. Toutefois, la mise en série et l'entête de commutation de contexte associée avec le programme de mise en série, limite le débit maximum d'évènements. Cette restriction du débit d'évènements se traduit par le goulot d'étranglement principal pour tous les systèmes à programme en temps réel. Cela se traduit par l'augmentation de la latence IO et de la gigue pour l'application de prototype, augmente le temps de circulation des transactions et des mesures limitées à cause des limites résultant de la vitesse des trames réseau. L'optimisation est difficile sinon impossible à réaliser à cause de l'étranglement des vitesses d'évènement réduisant le contexte de commutation en tête détériorant les conditions de prototype et donnant une faible latence aux plans. L'utilisation de la technique CPU multicoeurs pour augmenter la puissance de traitement des programmes détériore les conditions de consommation de puissance des modules d'interface ECU et ne permet pas d'accélérer efficacement une unique conversation de données bidébit élevée (en général une connexion TCP unique) puisque l'ordre des paquets de conversation interdit le traitement en parallèle des paquets. En revanche, l'invention suggère une nouvelle technique utilisant des considérations architecturales différentes. Selon les propriétés multiservices des protocoles automobiles, l'architecture est divisée en un plan-commande implémenté dans un programme de travail sur les données de configuration de calibrage et de diagnostic CD transportées en utilisant des transactions T et un plan-données implémenté dans une mesure de transport en circuit M et de données de prototype RP dans des flux de données sans état S. L'implémentation de commande et de plan-données est présentée à la figure 2.

Les transactions entre le maître (client) et l'esclave (ser- veur) peuvent également être divisées en des flux de données sans état : le flux descendant transporte les ordres et le flux montant transporte les réponses et les évènements. Tenant compte de cette division par transaction, le plan-commande apparaît au plan donné comme un dis- positif d'entrée ordinaire pour le trafic montant et comme un dispositif de sortie ordinaire pour le trafic descendant. Le plan-données commute les flux de transaction échangés avec les dispositifs (puits ECU, source ECU) responsables du port physique souhaité. L'état de transaction lui-même associé au flux descendant et au flux montant se trouve dans le plan de commande.

Selon la figure 2, les couches de protocole d'état, en général le protocole de commande de transmission TCP se termine dans des blocs fonctionnels apparaissant comme des fonctions satellites (dispositif ordinaire) pour le coeur du plan-données de la même manière que les couches de transaction de protocole automobile avec état. L'état du pro- tocole est situé dans la fonction satellite. Le bloc fonctionnel de la figure 2 appelé « protocole transport (chemin rapide) » est décrit en détail dans le document EP 12 188 660. Les couches de protocole sans état (en général le protocole datagramme utilisateur UDP) se terminent dans le plan-données et dans l'interface réseau. La figure 2 montre une autre fonction satellite comme fonction de traitement de signal de chemin rapide qui contient le modèle de prototype et peut être implémentée soit sous forme de circuit, soit sous forme de programme selon le cas d'application particulier. La fi- gure 3 montre une implémentation plan-données et commande d'un système de prototype et MCB comportant des exemples d'autres fonctions satellites. Ces autres fonctions satellites peuvent être par exemple la fonction de protocole transport ISO, la fonction de sécurité (cryptage) et/ou la fonction de portail de niveau de signal.

Un avantage principal d'un plan-données commun est le fait que tout le trafic entrant peut être observé, ce qui est essentiel pour contrôler la qualité de service QoS du point de vue de la latence, de la gigue, du débit etc. La séparation du plan-commande et du plan-données suggérée par la présente invention permet des implémentations optimi- sées. D'autres optimisations peuvent être obtenues par un développement ASIC à la place d'un développement FPGA. * Le plan-données est complètement implémenté sous forme de circuit et est optimisé pour un traitement très rapide d'évènements avec des temps de cycles d'évènements abaissés jusqu'à 200 ns (les solutions courantes en programme sont supérieures à 50 ps). * Le plan-données est complètement implémenté sous forme de circuit et est optimisé pour une gigue très faible inférieure à 2 ps (approche de programme courant : dizaines de ps). * Le plan-données est complètement implémenté sous la forme d'un circuit et est optimisé pour des débits élevés de données allant jusqu'à 5 Gbit/s (les programmes courants sont inférieurs à 100 Mbit/ s. * Toutes les trois optimisations (temps de cycle évènement, gigue et débit de données) sont possibles dans le mêmes programmes sans violer les limitations de consommation de puissance des interfaces ECU intégrées. * Le plan-données est implémenté en programme et est optimisé pour lo un traitement respectant le contenu et la transaction d'état. Comme le programme est déchargé d'un procédé d'évènements rapides en couche protocole, la caractéristique CPU disponible est utilisée plus efficacement. * Les protocoles de transport d'état tels que TCP ou fragmentation IP 15 sont implémentés en circuits (chemins rapides) à caractéristiques optimisées et coexistant (en programme (chemins lents)) optimisés pour des caractéristiques (couches 7 des protocoles, nombre de connexion). * Le traitement du signal peut se faire dans un noeud de simulation 20 externe puissant qui n'a pas de traitement d'évènement à transport granulaire fin et est autorisé à se concentrer sur ces fonctions de traitement de signal. Le plan-données reçoit les évènements transportant des données des dispositifs d'entrée ; il met les évènements en série très ra- 25 pidement sans aucune commutation de contexte au-dessus ; il applique un jeu d'étapes de traitement généralisé et répartit les évènements transportant des données distribuées aux dispositifs de sortie. La qualité de service QoS pour la mise en file et l'échelonnement des évènements de données se fait seulement pour le 30 plan-données qui permet un contrôle bien meilleur de la priorité de tra- fic, des temps de circulation, de transaction, de latence, de gigue et de qualité du débit de données. Les dispositifs traitent et fournissent des évènements pendant que le coeur du plan-données ou le processeur de données 35 traite les évènements séquentiellement suivant une approche stricte de pipeline, avec un circuit coopérant, intégré, multi-chemin comme représenté à la figure 4. Selon le mode de réalisation préférentiel de la figure 4, le plan-données se compose des composants de base suivants : Dispositif plan-données : Dispositifs de travail simultané ; ils encapsulent un com- portement physique et une couche de liaison spécifique ou encore des fonctions de protocole d'état et supportent la mise en série pour le pipeline coeur de plan-données. Pipeline coeur de plan-données = processeur de données : Il traite l'évènement actuel fondé sur un modèle d'informations génériques : classification, réassemblage, mise en file, mise en file hiérarchisée, segmentation et modifications ultérieures de l'entête. Le pipeline se compose d'un jeu d'étages de traitement enchaînés, bien définis (IF, CL, IM, SW, MC, EQ, LL, DQ, SR, EM, IF). Le processeur de données traite les descripteurs (pointeurs) des données plutôt que les données elles-mêmes, ce qui économise des portes logiques et de la puissance. Pôles descripteur : Les pôles descripteurs reposent sur des indices de tam- pon de données situés à un endroit local ou un endroit éloigné. Mémoire de données : Il y a deux types de mémoire de données : une mémoire locale de données située dans le module d'interface ECU, et - une ou plusieurs mémoires de données, éloignées, ex- térieures au module d'interface ECU et que l'on peut atteindre par l'express PCI ou tout autre interface appropriée. Les dispositifs fournissent ces données sous la forme de segments de données avec une taille maximum fixe en général 128 oc- tets. La taille est déterminée par la largeur de la bande (débit) entre les mémoires de données. Les segments multiples forment une unité de données qui correspond à un format de trames spécifique de la couche protocole, en général l'objet de transfert de données pour la couche XCP protocole universel de mesure et de calibrage, trames Ethernet pour la couche de liaison IEEE 802.1, la trame CAN pour le bus CAN ou la trame Flexray. Les dispositifs connaissent la segmentation et peuvent marquer le premier et le dernier segment de données de l'unité de données. La segmentation des données est une condition préalable du non blocage des évènements de données traités dans le processeur de données ; selon ce procédé on met les évènements en série et le traitement est réparti le long d'étages multiples pipelines.

L'implémentation de processeur de données est fondée sur un modèle d'information générique tel que celui présenté à la figure 5 et qui se compose des entités et des attributs suivants. Les étages de traitement décrits ci-après (architecture pipelines de coeur de données) sont contrôlés en utilisant ces attributs. Comme le pipeline peut être configuré pour enregistrer une ou plusieurs entités suivantes dans des registres, ou pour tracer une application spécifique, des entités peuvent être statiques (multiplicité définie par l'implémentation) ou dynamiques (multiplicité définie par l'attribution de pôles partagés pendant la configuration). Les modèles d'information les plus importants sont listés ci- après : Dispositif (statique) : Les dispositifs sont des producteurs et des consomma- teurs de segments de données qui travaillent en concurrence. Chaque segment de données est associé à un indice-dispositif, un indice-canal et drapeau premier/dernier, indiquant ainsi que le segment de données se trouve en première position, dans un segment intermédiaire ou un segment de dernières données de l'unité de données. Canal de réception (canal RX, dynamique) : Un canal de réception est un canal de données d'entrée, logique, indépendant dans le cadre d'un dispositif. Les dispositifs peu- vent être des canaux de réception. Les canaux de réception servent à réassembler les unités de données de segments de données imbriqués dans le temps. Flux (dynamique) : Un flux est la description d'une conversation de données par rapport à une couche de protocole spécifique. Il est utilisé pour les opérations de traitement de données dans la commande dans le processeur de données en général, l'insertion d'une entête spécifique du proto- cole dans le flux de données sortant. Les flux sont attachés aux canaux de réception. Mise en file (mode dynamique) : Les files enregistrent des descripteurs de données. Il s'agit de trois types fondamentaux de files : files descendantes, triple tampons et listes prioritaires. Les files de coupure de queue sont utili- sées pour contrôler la qualité de service QoS en général, la priorité de trafic et la correction. Les triples tampons servent dans les fonctions de prototype en temps réel IO (RTIO) pour un traitement de signal avec un échantillonnage consistant des dernières données d'entrée. Les listes de priorité servent dans les systèmes de bus par rapport à la stricte priori- té fondée sur un arbitrage tel que le bus CAN. Une seconde tâche de file consiste à désassembler les unités de données du flux de segment de données. Canal de priorités de transmission (mode dynamique ou statique) : Le canal de priorités de transmission représente un canal de données indépendant dans le sens sortant. Chaque canal de priorités de transmission établi un niveau d'échelonnement stricte des priorités dans le cadre du dispositif de sortie associé. Le canal de priorités de transmission est lui-même associé à une ou plusieurs files d'attente qui sont organisées avec une pondération. Les canaux de priorités de transmission peuvent organiser des segments de données (changement de la file organisée après chaque segment) ou d'unité de données (changement de file organisé dès que l'unité de données en cours a été com- plètement organisée). Les canaux de priorités de transmission peuvent changer la granulométrie de segmentation en organisant plusieurs fois un segment de données avec un comptage d'octets inférieur et en assurant le décalage supplémentaire d'une mémoire de données. Fonction d'interaction de canal (fonction dynamique) : La fonction d'interaction de canal est une entité en option utilisée pour l'agrégation de l'information entre le chemin d'entrée et le chemin de sortie pour un flux de trafic réparti entre plusieurs segments séquentiels multiples de données.

Echéancier (statique) : Le processeur de données implémente un échéancier hiérarchique à trois niveaux : 1) l'échéancier pondéré des dispositifs 2) l'échéancier strict en priorité des canaux de transmis- sion prioritaire dans un dispositif et 3) l'échéancier pondéré des files dans le cadre d'un canal de priorités de transmission. Le pipeline de coeur de données se compose d'étages de traitement génériques tels que décrits ci-après. L'architecture de pipe- lines de coeur de données est représentée à la figure 4. Les étapes de traitement correspondent au modèle d'information générique décrit ci-dessus (implémentation de processeur de données). Interface d'entrée (IF) : L'interface d'entrée relie les dispositifs au coeur plan- données et met en série simultanément les évènements de données en- trant en utilisant l'échéancier pondéré parmi les dispositifs branchés. Les données associées aux évènements peuvent passer « en valeur » ce qui est le défaut ou « par référence ». Dans ce dernier cas, le processeur de données suppose que le contenu de données associé à l'évènement a déjà été enregistré et qu'il reçoit seulement l'indice de mémoire tampon de la donnée du message. L'exemple décrit ci-dessus illustre le transfert par référence au contexte d'un XCP sur TCP utilisé. Classificateur - CL : Le classificateur utilise le descripteur avec les premières données de message pour classer le segment de données en construi- sant une clé à partir de l'information ci-dessus et en fournissant un vecteur résultant qui contient l'information suivante : - indice de groupement, indice de file, drapeau de chute identité de flux, indice de fonction d'interaction et autres. Cette infor- mation est entrée dans le descripteur.

Modificateur d'entrée - IM : Le modificateur d'entrée constitue un moyen pour modifier (étendre ou réduire) les données entrant en changeant les données elles-mêmes ou en manipulant le descripteur.

Inscripteur de segment - SW : L'inscripteur de segment attribue un descripteur du groupement comme le commande le classificateur de groupement et il inscrit le contenu de données dans sa destination en utilisant l'indice tampon de descripteur.

Multidiffusion - MC : L'étage de multidiffusion constitue un moyen pour distribuer les données vers de multiples destinations. Il contient un tableau de multidiffusion qui est adressé par un identificateur de groupes multidiffusion contenu dans le descripteur reçu et il délivre une liste de files. Le descripteur reçu est cloné dans l'étage multidiffusion pour être groupé dans une file dans les files de sortie multiple. Le descripteur reçoit un comptage de référence pour gérer le groupement de mémoire. Moteur de mise en file - EQ : Le moteur de mise en file exécute toutes les opérations nécessaires pour enregistrer le descripteur dans la file sélectionnée et rendre la file visible à l'organisateur. Liaison avec la liste de commande - LL : La liste maillée contrôle les listes maillées conservées des descripteurs qui représentent les files de données. Il reçoit un ordre de mise en file du moteur de mise en file et des ordres de sortie de file de l'organisateur ou du moteur de sortie de file. Moteur de sortie de file - DQ : Le moteur de sortie de file est l'unité d'exécution organi- sée. Il détermine la file suivante à desservir en utilisant l'état de sortie FIFO du dispositif. Il est configuré en priorité comme information sous la forme de canaux à priorité de transmission du dispositif de sortie. Il permet également de re-segmenter le trafic en divisant un segment de données courant en des segments de données plus courts ou en maintenant l'unité de traitement de données en concordance avec l'échéancier de tous les segments de données de l'unité de données avant de traiter une autre file du canal de priorités de transmission courantes. Lecteur de segment - SR: Le lecteur de segment utilise l'indice de mémoire contenu dans le descripteur pour les données de lecture de la mémoire de don- nées, locale ou éloignée. Modificateur de sortie - EM : Le modificateur de sortie utilise le flux id ainsi que d'autres drapeaux du descripteur pour modifier le contenu du flux de données selon sa configuration, en général en ajoutant ou en suppri- mant des données du flux de données ou en manipulant le contenu de descripteur. Interface de sortie - 0F: L'interface de sortie répartit les segments de données aux dispositifs de sortie qui ont indiqué qu'ils étaient prêts à recevoir plus de données (sortie FIFO non utilisée). Les dispositifs sont desservis en utilisant l'algorithme de pondération avec des poids proportionnels à la vitesse de ligne. Groupement local - LP : Le groupement local contient des indices préparés par le programme pour enregistrer provisoirement dans la mémoire de données locale. Les indices de la mémoire sont les attributs de coeur des descripteurs. Groupement éloigne - RP : Le groupement éloigné contient des indices préparés par le programme pour enregistrer dans l'étage de données à distance et il peut y avoir de multiples groupements éloignés pour de multiples mémoires de données éloignées. Les interfaces entre le pipeline et les dispositifs ETHIP, TCPS, TCPR, CPU L, TEA, sont les mêmes concernant leur syntaxe mais nécessitent un protocole spécifique concernant leur sémantique. Les deux modes de réalisation suivants de l'invention sont décrits à titre d'exemple. Le premier mode de réalisation présenté à la figure 6 se réfère à un accès ECU transparent double chemin avec des mesures ECU en utilisant XCP sur TCP (liaison montante). Ce mode de réalisation utilise un dispositif TEA en face de l'unité ECU. Le dispositif TEA termine la couche de service 5 de flux XCP et fournit les objets de transfert de données DTO standard, XCP distribué contenant les données de mesure à la date. L'unité CPU locale termine la couche de service T de transaction de protocole XCP et fournit les objets de com- mande de transfert CTO standard XCP. Dans le chemin 1 (PATH 1) le processeur de données as- sure le multiplexage de CTO et de DTO et termine les protocoles XCP de transport de couche contenant le compteur de paquets XCP qui est commun pour CTO et DTO. La couche de protocole TCP, complète, se termine dans l'émetteur TCP (dispositif TCPS) qui coopère avec le récepteur TCP et fournit des accusés de réception aux émetteurs TCP. Dans le chemin 2 (PATH 2), le processeur de données multiplexe les segments TCP et les trames Ethernet de la pile de programme CPU, locale vers le réseau IP commun et la couche de liaison Ethernet. Le dispositif ETHIP finalement termine la couche de réseau IP et la couche de liaison Ethernet. Il est à remarquer que la conversation TCP descendante coexiste avec la conversation montante et traverse ainsi deux fois le processeur de données. Comme pour une cession complète XCP, sur TCP il y a quatre chemins coexistant dans le pipeline de traitement de données. Le second mode de réalisation présenté à la figure 7 se rapporte à un unique chemin TEA (ETK) fondé sur le temps réel IO (RTIO) d'un noeud de simulation externe. Le mode de réalisation ajoute un chemin de prototype RTIO à faible latence vers le scénario précédent du premier mode de réalisation. La terminaison RTIO traverse le chemin 1 (PATH 1) dans le processeur de données. Le chemin 2 (PATH 2) n'est pas utilisé pour RTIO. Le dispositif TEA fournit les DTO en utilisant un canal de réception dédié au RTIO. Comme l'unité de traitement de signal (noeud de simulation) est un élément à distance (dispositif CPU-R) le processeur de données attribue les descripteurs du groupe éloigné avec des indices de mémoire dans la mémoire de données éloignée d'un noeud de simulation et il pousse les données très tôt dans la mémoire éloignée. La file du processeur de données fonctionne comme une mémoire triple qui réassemble les groupes de signaux, les objets de transfert de données divisés en segments de données. Dès qu'un échan- tillon de groupe de signaux est complet, une interruption est envoyée au noeud de simulation qui lit l'information d'adresse dans la mémoire triple. La donnée correspondante est déjà arrivée et peut même déjà être disponible dans la mémoire cache du noeud de simulation.

Une sélection à titre d'exemple de certaines caractéris- tiques clés et idées clés de l'invention et certains des avantages associés sera donnée ci-après : - Vues orthogonales sur les données et commandes o Flux de données vus dans le plan-données et le serveur client vu sur le plan-commande. o Le plan-commande est un client ordinaire du plan-données. o Le plan-données assure le coefficient QOS du plan-commande. - Généralisation du dispositif de o Interface de dispositif généralisé pour le processeur de données. o Encapsulage fonctionnel spécifique du dispositif. o Dispositifs physiques - Contrôleurs spécifiques de la couche de liaison encapsulés - Exemples : CAN, FlexRay, Ethernet, TEA (ETK). o Dispositifs de programme - Fonctions de programme encapsulées. - Exemples : CPU local (programme local), CPU à distance (programme à distance). o Dispositifs de protocole - Fonctions de protocole d'état encapsulées. - Exemple : TCP. o Dispositifs de traitement de signal - Instances de traitement de signal encapsulées. - Exemples : Module CPU, PC externe, entité de traitement de signal à base de circuits. - Mise en file multi-usage o Répond à de multiples exigences avec le même circuit. - File tronquée pour des mesures de débits élevés et plan-commande. - Mémoire de tête (triple mémoire) pour faible latence de prototype. - Qualité de service QoS. - Réassemblage d'unités de données. - Fonctionnement multi-chemins o Permet le fonctionnement multicouche sur le même circuit. o Tunnel de la couche client utilisant des exten- sions de descripteur. o Exemples : XPC sur Ethernet ; chemin 1 : XCP ; chemin 2 : IP/Ethernet. - Traitement de données fondé sur des descripteurs. o Minimise le nombre d'accès mémoire. o Réduit le taux de déclenchement logique et la consommation. o Réduit le taux de déclenchement d'interface. - Modes interface « en valeur » et « en référence » (longue description seule). - Segmentation de données o Rend maximum le débit d'évènements (débit série). o Réduit la taille de la mémoire. o Minimise la gigue et la latence. - Architecture pipeline. o Elimine le contexte de commutation entête. o Augmente le déterminisme. o Simplifie l'implémentation multitâches en coopération. - Traitement généralisé de stockage de données o Groupe local et groupe éloigné. o Mémoire locale et mémoire éloignée. - Modèle d'information générique o Réduit l'effort et la quantité de logique par la lo- gique de co mmande et la réutilisation d'algorithme. o Implémentation de protocole par configuration plutôt que par implémentation. - Multidiffusion fondée sur une file. o Support multi-client. - Multidiffusion spatiale pour les interfaces ECU o Séparation logique de la conversation avec des exigences QoS contraires. - Organisation hiérarchique à trois étages o Garantit une faible latence par une organisation stricte des priorités. o Garantit l'organisation correcte par pondération.25

Claims (10)

1. REVENDICATIONS1°) Procédé de transmission de données dans des unités de commande électroniques appelées « unités ECU » et/ou des dispositifs de mesure dans le domaine des véhicules automobiles, caractérisé en ce que l'architecture de la transmission des données est divisée en un plan-commande implémenté par programme travaillant sur la configuration, le calibrage et/ou des diagnostics appelés ci-après « CD », des données et un plan-données implémenté dans un moyen de transport de circuits appelé ci-après « M », des données et/ou des prototypes appelés ci-après « données RP ».
2. 2°) Procédé selon la revendication 1, caractérisé en ce que la donnée CD est transportée en utilisant des transactiosn appelées ci- après «T ».
3. 3°) Procédé selon la revendication 1 ou 2, caractérisé en ce que la donnée M et/ou la donnée RP sont transportées dans un flux de données sans état, appelé ci-après « S ».
4. 4°) Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que le plan-données commute les commandes et répond aux transactions et/ou les flux échangés avec les unités ECU et/ou les dispositifs de mesure.
5. 5°) Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu' il est appliqué avec des mesures de calibrage et diagnostic distribuées appelées ci-après « système MCD ».
6. 6°) Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il est adapté pour piloter et/ou commander le fonctionnement des unités ECU dans un véhicule automobile.
7. 7°) Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu' il est adapté pour piloter et/ou commander la transmission de données parmi les unités ECU dans un véhicule automobile.
8. 8°) Unité de commande électronique appelée ci-après « unité ECU », module d'interface pour piloter la transmission de données parmi les unités ECU et/ou des dispositifs de mesure dans le domaine des véhicules automobiles, caractérisé en ce que l'interface ECU comporte des moyens pour apliquer un procédé selon l'une quelconque des revendications précédentes.
9. 9°) Dispositif de mesure pour piloter et/ou commander le fonctionnement d'une unité de commande électronique ECU d'un véhicule automobile, caractérisé en ce que le dispositif comporte un module d'interface ECU selon la revendication 8.
10. 10°) Unité de commande électronique ECU adaptée pour la connexion à un dispositif de mesure pour une opération de pilotage et/ou de com- mande d'une unité de commande électronique ECU d'un véhicule au- tomobile ou autres unités ECU, caractérisée en ce que l'unité ECU comporte un module d'interface ECU selon la revendication 8.30