FR2982443A1 - Procede de gestion d'un dispositif de bus - Google Patents

Procede de gestion d'un dispositif de bus Download PDF

Info

Publication number
FR2982443A1
FR2982443A1 FR1260421A FR1260421A FR2982443A1 FR 2982443 A1 FR2982443 A1 FR 2982443A1 FR 1260421 A FR1260421 A FR 1260421A FR 1260421 A FR1260421 A FR 1260421A FR 2982443 A1 FR2982443 A1 FR 2982443A1
Authority
FR
France
Prior art keywords
data
slave
master
slaves
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR1260421A
Other languages
English (en)
Inventor
Heiko Boeck
Michael Helmle
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Robert Bosch GmbH filed Critical Robert Bosch GmbH
Publication of FR2982443A1 publication Critical patent/FR2982443A1/fr
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/403Bus networks with centralised control, e.g. polling
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/36Handling requests for interconnection or transfer for access to common bus or bus system
    • G06F13/362Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
    • G06F13/364Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control using independent requests or grants, e.g. using separated request and grant lines
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/403Bus networks with centralised control, e.g. polling
    • H04L12/4035Bus networks with centralised control, e.g. polling in which slots of a TDMA packet structure are assigned based on a contention resolution carried out at a master unit
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40208Bus networks characterized by the use of a particular bus standard
    • H04L2012/40234Local Interconnect Network LIN

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Small-Scale Networks (AREA)

Abstract

Procédé de gestion d'un dispositif de bus (112) comportant comme participants un maître (114) et k esclaves (116, 118, 120, 122). Le maître (114) envoyant aux esclaves (116, 118, 120, 122) une en-tête (1, 85) comportant une trame de requête (2, 84), les k champs d'information (24, 26, 28, 30, 32, 34, 36, 38, 96, 98, 100, 102). Un m champ d'information (24, 26, 28, 30, 32, 34, 36, 38, 96, 98, 100, 102) est associé à chaque m esclave (116, 118, 120, 122), qui inscrit dans le m champ d'information associé, une information concernant la quantité de données à envoyer. La trame de requête (2, 84) étant transmise au maître (114), qui tient compte d'une chronologie pour transmettre les données, et selon laquelle il transmet la quantité de données.

Description

Domaine de l'invention La présente invention se rapport à un procédé de gestion d'un dispositif de bus ainsi qu'un tel dispositif mis en oeuvre selon ce procédé.
Etat de la technique Un réseau d'interconnexion locale LIN est une spécification d'un système de communication série et ainsi celle d'un dispositif de bus série encore appelé bus LIN. Ce dispositif de bus s'utilise pour communiquer entre les capteurs et/ou les actionneurs ainsi qu'avec un appareil de commande comme participant du dispositif de bus, par exemple dans un véhicule automobile. Le standard LIN 2.0 transmet les données entre les participants avec des trames à résolution évènementielle (trame ETF) et des trames sporadiques (trame SF). Cela permet de définir une évolution chronologique (chronologie ou échéancier) pour la transmission de don- nées, c'est-à-dire que les trames permettent une transmission sporadique ou évènementielle des données et les trames elles-mêmes définissant de manière fixe une chronologie (échéancier). Dans le cas de trames sporadiques, on peut définir plu- sieurs messages à priorité statique pour une fenêtre de temps. Dans une telle fenêtre de temps, on envoie seulement une information il y a ses données pour le maître comme participant du dispositif de bus, ou si elles sont requises comme réponse de l'esclave vers le maître. Si l'on n'est pas dans l'un de ces deux cas, le dispositif de bus reste vide à ce moment. Le dispositif de bus peut également ne pas être occupé com- plètement par des trames sporadiques. Les trames évènementielles permettent de tenir compte de ce que tous les esclaves comme participants du dispositif de bus n'ont pas à émettre des données dans chaque cycle de transmission de données. A une trame évènementielle peuvent être associés plusieurs esclaves, c'est-à-dire qu'une en-tête d'une trame évènementielle peut recevoir la réponse de plusieurs esclaves. En cas de collision entre les trames transmises, les esclaves peuvent la détecter en relisant les données et en arrêtant la phase d'émission. Le maître reconnaît alors un défaut de réception ou de fin de temps. Dans la fenêtre de temps sui- vante de cette trame évènementielle, le maître interroge les esclaves avec des messages normaux ou par des identifiants distincts. Cela signifie que chaque esclave doit réagir à une trame résolue de manière évènementielle mais il doit néanmoins exister un identifiant normal univoque. Selon le standard LIN 2.1, après une collision, le maître peut changer une fois pour passer à une autre chronologie sans collision et après son traitement, il doit revenir au tableau initial de la chronologie. Il est toutefois nécessaire d'implémenter une détection de collision. De plus, en cas de collision, des retards considérables sont générés par le renouvellement de la requête et les différentes requêtes des esclaves. En général, les trames à résolution évènementielle ne sont en général intéressantes que si la prévision de collision est très faible. Un procédé de commande pour l'accès aux médias avec un bus série est décrit dans le document DE 197 21 740 Al. Ce bus série comporte plusieurs participants communiquant entre eux par des télégrammes de données. Pour permettre à un participant d'accéder au bus à des instants déterminés, un premier participant réalisé comme maître émet des télégrammes de déclenchement dans un ordre cyclique.
Pour cela, chaque télégramme de déclenchement contient le début et la durée de l'autorisation d'émission pour au moins l'un des participants sélectionnés par le maître. Le télégramme de déclenchement fixe pour les participants sélectionnés, un ordre chronologique de transmission des télégrammes de données. Avant l'émission d'un télégramme de dé- clenchement suivant, les esclaves peuvent demander des autorisations d'émission pour d'autres télégrammes de données auprès du maître. Exposé et avantages de l'invention La présente invention a pour but de remédier aux inconvénients des techniques connues et concerne à cet effet un procédé de gestion d'un dispositif de bus comportant comme participants un maître et k esclaves, le maître envoyant aux esclaves une en-tête comportant une trame de requête, les k champs d'information, un Mième champ d'information étant associé à chaque mièrne esclave, le mième esclave inscrivant dans le mième champ d'information qui lui est associé, une information concernant la quantité de données à envoyer du mième esclave vers le maître, * la trame de requête étant transmise au maître, et le maître tient compte d'une chronologie pour transmettre les don- nées et selon laquelle il transmet la quantité de données. L'invention permet d'éliminer les temps morts et/ou les octets vides dans une trame pour la transmission des données sur le dispositif de bus, de réduire le temps de cycle et de diminuer le temps le latence si par exemple aucun esclave n'envoie des données comme par- ticipant du dispositif de bus. Selon le procédé, il n'y a pas de collision et ainsi le dispositif de bus peut être utilisé à 100 %. Pour cela, le maître interroge k esclaves avec une trame de requête commune à tous les k esclaves pour connaître si chaque es- clave veut émettre des données dans le cycle suivant de transmission de données et la quantité de données à transmettre. Pour cela, on utilise un procédé selon lequel plusieurs esclaves participent à la trame de requête. La trame de requête contient k champs d'information. Le maître envoie une en-tête de cette trame de requête et chacun des k es- claves inscrit des informations dans l'un des k champs d'information. L'en-tête et les champs d'information donnent en combinaison la somme de contrôle que le dernier esclave envoie sur le dispositif de bus avec la trame de requête complète et conforme LIN. Le maître lit après la réception de la trame de requête les champs d'information envoyés par les esclaves. Puis, le maître génère un plan chronologique (chronologie ou échéancier) qui est attribué par au moins une fenêtre de temps en général une succession de fenêtres de temps à au moins un esclave et ainsi communiquer au moins de manière implicite. En outre, le maître peut demander à au moins un esclave d'envoyer les données dans une fenêtre de temps qui lui est attribuée pour la transmission des données avec une trame de transmission de données. Le maître peut transmettre par l'en-tête en plus une information de synchronisation pour les esclaves et/ou pour le cycle de transmission de données. En inscrivant les informations dans les champs d'information, on fixe un ordre, un volume et/ou une quantité maximale de données que les esclaves peuvent transmettre. Selon un développement de l'invention, chaque esclave peut inscrire des informations dans un champ d'information de la trame de requête qui comprend par exemple un octet et l'ordre des champs d'information est défini par l'identité (ID) des esclaves et/ou de leur position dans le dispositif de bus. L'en-tête de la trame de requête est envoyé pour appliquer une requête. Selon le standard LIN, la trame de requête peut comporter huit champs d'information d'une longueur maximale de 8 octets de sorte que l'on a au maximum k = 8 esclaves ou participants du dispositif de bus et qui pourrons être interrogés. Par une certaine valeur, par exemple "0" qui peut également s'appeler "valeur vide", l'esclave enregistre cette valeur vide dans le champ d'information qui lui est attribué dans la trame de requête ; ainsi il l'inscrit et l'esclave signale au maître, que pour le cycle de transmission de données suivant lancé par la trame de requête et/ou préparé par celle-ci, il n'y a pas de nouvelles données. Si dans un Mième esclave il y a des données à émettre, une première partie du champ d'information associé dans la trame de requête et qui comporte par exemple 5 bits d'un octet, on utilisera une valeur pour une première indication des données à transmettre dans le cycle de transmission de données. Dans la seconde partie du champ d'information qui lui est associée et qui se compose par exemple de 3 bits, l'esclave indique la quantité, par exemple le nombre d'octets des données qui doivent être transmises dans le cycle suivant de transmis- sion de données. Après réception et traitement de la trame de requête, le maître est en mesure de fournir pour le cycle de transmission de données suivant, une chronologie optimisée selon la demande réelle, par exemple sélectionner parmi plusieurs schémas de déroulement déjà préparés. Il est toutefois également possible de générer un tel plan d'organisation par le maître et le cas échéant de l'indexer par un enregistrement en mémoire pour les cycles de transmission de données suivants.
Le maître reçoit par la trame de requête reçue, les informations suivantes des esclaves : le nombre d'esclaves qui doivent envoyer des données : le maître peut en déduire le nombre de fenêtres de temps à prévoir, une première indication des données à transmettre ou de leur ori- gine, leur caractère déterminant, leur importance et/ou leur urgence le maître peut en déduire l'ordre chronologique des fenêtres de temps du schéma qui peuvent être attribuées aux esclaves. L'ordre chronologique selon lequel les fenêtres de temps sont attribuées aux esclaves dans le cycle de transmission de données, peut être fixé en fonction du niveau d'une valeur pour le classement quantitatif de l'indication des données à envoyer. Une première fenêtre de temps est attribuée à un premier esclave sélectionné qui a une première valeur comme indication de données. A un nième esclave on attribuera une nième valeur d'indication de données et à un nième instant, on as- socie la nième fenêtre de temps, etc... la quantité de données à envoyer par un esclave : pour cela, le maître déduit l'intervalle de temps que doit avoir une fenêtre de temps ; la longueur de l'intervalle de temps dépend de la quantité et/ou de la place de mémoire nécessaire dans la trame de transmis- sion de données de l'esclave pour transmettre les données. Le maître prévoit sa configuration, par exemple en fonction du nombre k d'esclaves existant avec des plans de déroulement différents dans le temps (échéancier). Chaque plan de déroulement est caractérisé par un nombre et par un ordre caractérisant les fenêtres de temps. Le nombre de fenêtres de temps correspond au nombre d'esclaves qui doivent émettre des données dans le cycle de transmission. La longueur de l'intervalle de temps d'une fenêtre de temps, est adaptée par le maître selon la quantité respective de données qui doivent être envoyées par l'esclave. De plus, pour chaque fenêtre au-delà du plan de déroulement chronologique ou de la chronologie, on fixe un instant d'émission, ce qui fixe l'ordre des fenêtres de temps attribué par le maître. Il en résulte également l'ordre chronologique auquel les esclaves émettent les trames de transmission de données. De plus, cela fixe l'ordre chronologique selon lequel le maître reçoit les trames de trans- mission de données. Cela correspond à l'instant auquel le maître reçoit du Mièrne esclave, la //lierne trame de transmission de données. On peut exécuter de manière cyclique une requête consistant à envoyer l'en-tête d'une trame de requête par le maître aux es- claves. Ainsi, dans une requête, une en-tête est envoyée de manière cyclique jusqu'à qu'au moins un esclave signale qu'il veut transmettre de nouvelles données par l'écriture d'une information dans le champ d'information qui lui est attribué. Les esclaves sont ainsi interrogés pratiquement pendant la durée du cycle de la requête et ainsi aussi long- temps qu'aucune données n'est transmise. Si à la transmission de l'en- tête on a un défaut, l'en-tête sera renvoyé par le maître et/ou est initialisé. Le procédé selon l'invention peut par exemple s'appliquer si après une durée dans laquelle aucune donnée n'a pas été envoyée, on peut recommencer aussi rapidement que possible un nouveau cycle de transmission de données, pour que le procédé puisse tenir compte de ce que les esclaves ne fournissent pas toujours ou en permanence des données. En établissant une fenêtre de temps pour une trame de transmission de données, on tient compte de ce qu'une quantité de données des esclaves peut varier dans chaque cycle de transmission de données. Les esclaves permettent ainsi de respecter un échéancier qui est réglé de manière souple et comporte des fenêtres pour le cycle de transmission de données. Pour avoir un échéancier (chronologie) optimisé selon la demande, par exemple pour un dispositif de bus développé, par exemple un dispositif de bus LIN, le maître demande aux esclaves s'ils ont des données à transmettre et la quantité de données. Pour cela, tous les esclaves du dispositif de bus LIN seront interrogés avec l'en-tête commune d'une trame de requête que les esclaves se partagent. A chacun des es- claves est associé un champ d'information de la trame de requête avec par exemple un octet qui indique à l'esclave si une nouvelle donnée a été envoyée ou non. De plus, l'esclave peut également indiquer combien d'octets de données sont à transmettre. Après le remplissage des champs d'information, la trame de requête est envoyée au maître. Sur ce fondement, il est possible de fournir un échéancier optimisé pour la demande effective de données à transmettre. En général, un esclave peut indiquer au maître de manière explicite le volume et l'importance des données à lui transmettre. Dans le cas d'un dispositif de bus LIN commandé dans le s temps, le maître détermine par une fenêtre de temps de décision s'il faut transmettre aux esclaves selon le plan d'organisation, quel esclave communique et quand il peut envoyer ses données. L'échéancier d'un cycle de transmission de données peut se régler de manière dynamique de façon glissante selon le fonctionnement. On peut également définir 10 plusieurs cycles de fonctionnement entre lesquels le maître peut com- muter de manière dynamique en fonction du temps. L'invention permet de tenir compte entre autres de ce que tous les esclaves n'ont pas à envoyer des données actuelles que le volume de données qu'un esclave transmet peut varier d'un cycle de 15 transmission de données à l'autre. On évite de cette manière de nom- breux temps morts et des octets vides sur le bus, ce qui optimise le taux de données utiles. En outre, on évite des temps de latence importants. La fixation dynamique selon l'invention de l'instant auquel un esclave envoie ses données dans un cycle de transmission de 20 données, peut par exemple être prise en compte de sorte que l'esclave envoie d'abord les données qui arrivent en premier et qui sont ainsi les plus anciennes. On évite que l'esclave qui a transmis des données en premier, transmette les données en dernier dans un cycle de transmission de données. 25 Le dispositif de bus selon l'invention exécute toutes les étapes du procédé présentées ci-dessus. Les différentes étapes du procédé peuvent être exécutées par les différents composants du dispositif de bus. En outre, les fonctions du dispositif de bus ou les fonctions de différents composants du dispositif de bus peuvent être réalisées sous 30 la forme d'étapes du procédé. Il est en outre possible que les étapes du procédé soient réalisées comme fonctions d'au moins un composant du dispositif de bus ou de l'ensemble du dispositif de bus. 35 Dessins La présente invention sera décrite ci-après de manière plus détaillée à l'aide d'un exemple de procédé de gestion d'un dispositif de bus représenté dans les dessins dans lesquels la figure 1 est une représentation schématique d'un exemple d'ordi- nogramme comprenant la succession chronologique des fenêtres de temps appliquées par un premier mode de réalisation du procédé de l'invention, la figure 2 montre schématiquement un exemple d'une trame de re- quête, - la figure 3 est un schéma d'autres exemples de fenêtres de temps associées à différents esclaves pour un second mode de réalisation du procédé de l'invention, la figure 4 est un diagramme d'un troisième mode de réalisation du procédé de l'invention, - la figure 5 est un schéma d'un mode de réalisation d'un dispositif de bus selon l'invention. Description de modes de réalisation de l'invention La figure 1 montre dans une première ligne, l'en-tête 1 d'une trame de requête 2 présentée ci-après à la figure 2 pour réaliser une requête envoyée par un maître d'un dispositif de bus ayant en tout k esclaves (k = 8). Pendant la requête, seule l'en-tête 1 représentée à la figure 1 est transmise. Si pendant un cycle de transmission de données tel que prévu, uniquement un premier esclave transmet des données, alors se- lon un premier ordinogramme du maître, comme celui représenté dans la seconde ligne de la figure 1, une première fenêtre de temps 4 sera mise à dispositif pour l'unique esclave, par exemple le premier esclave. Dans la troisième ligne à côté de la première fenêtre de temps 4, on a une seconde fenêtre de temps 6 qui correspond à un or- dinogramme de cycle de transmission de données dans lequel deux esclaves envoient des données. La seconde fenêtre de temps 6 est associée à un second esclave du dispositif de bus. Dans la quatrième ligne de l'ordinogramme de la figure 1, trois esclaves transmettent des données dans un cycle de transmission de données. Pour cela, l'ordinogramme fournit la première fenêtre de temps 4 pour le premier esclave, une troisième fenêtre de temps 8 pour un troisième esclave et une quatrième fenêtre de temps 10 pour un quatrième esclave.
Si dans les modes de réalisation du procédé de l'inven- tion, tous les k esclaves envoient des données dans un cycle de transmission de données, dans l'ordinogramme, selon la cinquième ligne de la figure 1, pour chacun des esclaves on dispose d'une fenêtre de temps 4, 6, 8, 10, 12, 14, 16, 18. La première fenêtre de temps 4 est associée au premier esclave, la seconde fenêtre de temps 6 est associée au se- cond esclave, la troisième fenêtre de temps 8 est associée au troisième esclave, la quatrième fenêtre de temps 10 est associée au quatrième esclave, la cinquième fenêtre de temps 12 est associée au cinquième esclave, la sixième fenêtre de temps 14 est associée au sixième esclave, la septième fenêtre de temps 16 est associée au septième esclave et la hui- tième fenêtre de temps 18 est associée au huitième esclave. Les fenêtres de temps 4, 6, 8, 10, 12, 14, 16, 18 de la fi- gure 1, ont des intervalles et la longueur d'un intervalle de temps d'une fenêtre de temps 4, 6, 8, 10, 12, 14, 16, 18 est adaptée de manière indi- viduelle et souple au volume de données à transmettre par un esclave pour chacun des cycles de transmission de données. On peut ainsi par exemple adapter l'intervalle de temps de la première fenêtre de temps 4 au volume de données qui sont transmises par le premier esclave pour chaque ordinogramme présenté.
Les ordinogrammes de la figure 1 fixent également l'ordre selon lequel le maître attribue les fenêtres de temps 4, 6, 8, 10, 12, 14, 16, 18 aux esclaves. Il en résulte un ordre selon lequel les esclaves fournissent des trames de transmission de données, complètent avec les données et l'ordre avec lequel les esclaves envoient des trames de transmission de données au maître et l'ordre selon lequel le maître re- çoit les trames de transmission de données des esclaves. Les détails possibles d'une longueur des intervalles de temps des fenêtres de temps 4, 6, 8, 10, 12, 14, 16, 18 qui dépend du volume des données et qui définit la longueur des trames de transmis- sion de données servant à recevoir les données transmises à chaque cycle de transmission de données, seront décrits à l'aide de la figure 3. La figure 2 est une représentation schématique de détail de la structure d'une trame de requête 2 de l'en-tête 1 présentée à la figure 1. La trame de requête 2 comporte en plus de l'en-tête 1, k champs d'information vides 24, 26, 28, 30, 32, 34, 36, 38 ainsi qu'un champ de contrôle 40 (k = 8). Après avoir renseigné les champs d'information 24, 26, 28, 30, 32, 34, 36, 38 avec des informations concernant les données à envoyer par les esclaves, on transmet la trame de requête 2 au maître. Un premier champ d'information 24 est associé à un premier esclave ; un second champ d'information 26 est associé à un second esclave ; un troisième champ d'information 28 est associé à un troisième esclave ; un quatrième champ d'information 30 est associé à un quatrième esclave ; un cinquième champ d'information 32 est as- socié à un cinquième esclave ; un sixième champ d'information 34 est associé à un sixième esclave ; un septième champ d'information 36 est associé à un septième esclave ; un huitième champ d'information 38 est associé à un huitième esclave ; ces esclaves font partie du dispositif de bus comportant ici en tout huit esclaves. Le champ de contrôle 40 en extrémité est associé à l'ensemble de la trame de requête 2 pour le con- trôle redondant cyclique par une somme de contrôle. Pour la mise en oeuvre du mode de réalisation du procédé de l'invention, les champs d'information 24, 26, 28, 30, 32, 34, 36, 38 associés aux esclaves ne contiennent pas encore des données lorsque l'en-tête 2 de la trame de requête est transmise par le maître aux es- claves dans un cycle de requête. Les esclaves reçoivent l'en-tête 1 dans l'ordre du dispositif de bus. Si au moins l'un des esclaves, par exemple le mième esclave doit envoyer des données vers le maître au cours du cycle de transmission de données suivant, ce mieme esclave inscrit au moins une information relative aux données à envoyer dans le mième champ d'information 24, 26, 28, 30, 32, 34, 36, 38, libre qui lui est associé. Chacun de ces champs d'information 24, 26, 28, 30, 32, 34, 36, 38 est divisé en deux parties. Le mième esclave inscrit dans la première partie qui correspond ici à 5 bits, des informations concernant une in- dication relative aux données à envoyer. Dans la seconde partie du mième champ d'information 24, 26, 28, 30, 32, 34, 36, 38 qui lui est associé, le mième esclave inscrit des informations concernant le volume des données à envoyer ; la seconde partie du champ d'information 24, 26, 28, 30, 32, 34, 36, 38 correspond ici à 3 bits. Si le mième esclave n'a au- donnée à envoyer au maître dans le cycle de transmission de don- nées suivant, cet mième esclave inscrit une valeur vide dans le mième champ d'information 24, 26, 28, 30, 32, 34, 36, 38 qui lui est associé ; cette valeur vide est conventionnelle et correspond par exemple à la valeur 0. Ainsi, il est prévu que les informations de l'en-tête 1 qui peuvent contenir par exemple les identités (ID) des esclaves, sont adressées à l'en-tête 1 en étant inscrites par le maître et lues par les esclaves. Les informations des champs d'information 24, 26, 28, 30, 32, 34, 36, 38 sont inscrites par les esclaves. La somme de contrôle est écrite par le dernier esclave du dispositif de bus dans le champ de contrôle 40. Les champs d'information 24, 26, 28, 30, 32, 34, 36, 38 ainsi que le champ de contrôle 40, constituent la réponse des esclaves. Cette réponse est lue par le maître. La figure 3 montre des exemples de fenêtres de temps 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72 dans les inter- valles de temps dépendent du volume de données que les esclaves 74, 76, 78, 80 doivent envoyés par les trames de transmission de données. Ainsi, une première fenêtre de temps 42 est associée à un premier esclave 74 pour un volume de 1 octet de données ; une seconde fenêtre de temps 44 est associée pour un volume de 2 octets ; une Xièrne fenêtre de temps 46 est associée pour un volume de x octets de données ou une huitième fenètre de temps 48 est associée pour un volume de 8 octets de données. De façon correspondante, à un second esclave 76 on associe une première fenêtre de temps 50 pour un volume de 1 octet de données, une seconde fenêtre de temps 52 pour un volume de 2 octets de données, une Xièrne fenêtre de temps 54 pour un volume de x octets de données ou une huitième fenêtre de temps 56 pour un volume de 8 octets de données. A un mième esclave 78 sur un ensemble de k esclaves 74, 76, 78, 80, on associe dans l'ordinogramme d'un maître, une pre- mière fenêtre de temps 58 pour un volume de 1 octet de données, une seconde fenêtre de temps 60 pour un volume de 2 octets de données, une xième fenêtre de temps 62 pour un volume de x octets de données ou une huitième fenêtre de temps 64 pour un volume de 8 octets de données de sorte qu'à ce Mième esclave 78, est associée l'une des fenêtres de temps 58, 60, 62, 64 pour des intervalles de temps de dimensions diffé- rentes pour constituer des trames de transmission de données de tailles différentes recevant des quantités de données différentes. Il est prévu que le dispositif de bus comporte en tout k esclaves 74, 76, 78, 80 (k = 8). Avec un ordinogramme, on attribue au dernier ou kième esclave 80 par le maître, soit une première fenêtre de temps 66 pour un volume de 1 octet de données, une seconde fenêtre de temps 68 pour un volume de 2 octets de données, une xième fenêtre de temps 70 pour un volume de x octets de données ou une huitième fenêtre de temps 72 pour un volume de 8 octets de données.
On fixe une durée d'un intervalle de temps d'une fenêtre de temps 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72 par le volume de données qu'un esclave 74, 76, 78, 80 après attribution de la fenêtre de temps 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72 peut insérer dans une trame de données fournie. La lon- gueur d'un intervalle de temps est réglée en fonction de l'information relative au volume de données à envoyer que l'esclave 74, 76, 78, 80 a inscrit dans le champ d'information associé de la trame de requête et qui est ainsi communiquée au maître pour être réglée par celui-ci. Le diagramme de la figure 4 correspond à un troisième mode de réalisation du procédé de l'invention, représente en abscisses 82 le temps en ms. Le digramme de la figure 4 correspond à un autre exemple de trame de requête 84 avec une en-tête 85 transmise par une requête 86 par les esclaves à un maître du dispositif de bus et des exemples de trame de transmission de données 88, 90, 92 utilisée dans un cycle de transmission de données 94. Le cycle de transmission de données 94 directement à la suite de la requête 86 est préparé et/ou introduit par la requête 86. Dans le mode de réalisation décrit ici, le dispositif de bus a k = 4 esclaves. En conséquence, la trame de requête 84 comporte un premier champ d'information 96 pour un premier esclave, un second champ d'information 98 pour un second esclave, un troisième champ d'information 100 pour un troisième esclave ainsi qu'un quatrième champ d'information 102 pour un quatrième esclave. Les champs d'information 96, 98, 100, 102 sont vides lorsque l'en-tête 85 de la trame de requête 84 est transmis par le maître aux esclaves. Dès que pendant la requête 86 un esclave reçoit l'en-tête 85, cet esclave inscrit les informations de données dans le champ d'information 96, 98, 100, 102 associé ; ces informations sont envoyées par l'esclave respectif, au cours de chacun des cycles de transmission de données suivants 94 vers le maître. De façon détaillée, le premier esclave de l'exemple de réalisation présenté, inscrit l'information "20:2" dans le premier champ d'information 96 qui lui est attribué. Le second esclave inscrit l'information "0:0" dans le second champ d'information 98 qui lui est associé ; le troisième esclave inscrit l'information "13:2" dans le troisième champ d'information 100 qui lui est associé. Le quatrième esclave inscrit l'information "19:4" dans le quatrième champ d'information 102 qui lui est associé. Ainsi, un rnième esclave inscrit dans le mième champ d'information 96, 98, 100 qui lui est associé, l'information "Y:Z" relation dans laquelle Y représente le premier nombre et/ou une première valeur et Z représente un second nombre et/ou une seconde valeur. La première valeur Y contient des informations relatives à une indication des données à envoyer ; il en est de même dans l'exemple présenté 20, 0, 13 ou 19. Dans le présent mode de réalisation, l'indication expose le carac- tère pertinent, par exemple l'importance et/ou l'urgence ou encore l'âge des données que le mième esclave doit envoyer. Le caractère pertinent est d'autant plus grand que la valeur Y est petite pour l'indication. En variante ou en complément, la valeur Y expose à quel instant les données à transmettre ont été saisies par le mième esclave. Les données à envoyer sont d'autant plus vieilles que la valeur Y est plus petite. La seconde valeur Z indique une grandeur et/ou un volume de données à envoyer. Ainsi, par l'information "20:2", le premier esclave indique dans le premier champ d'information 96, que ce premier esclave doit envoyer un volume de 2 octets de données ayant le caractère certain 20 et/ou qui ont été saisis à l'instant Y = 20. Le troisième esclave signale au maître par le champ d'information associé 100 qu'il a cherché à envoyer un volume de 2 octets de données qui ont un caractère pertinent 13 et/ou à l'instant Y = 13 qui ont été saisis. Les informations "19:4" du quatrième champ d'information 102 associé, informent le quatrième esclave du maître qu'il doit envoyer un volume de 4 octets ayant le caractère pertinent 19 et/ou qui ont été saisis à l'instant Y = 19. Dans le présent mode de réalisation, les informations "0:0" du second champ d'information 98 associé au second esclave, prennent une position particulière. La première information indique la valeur Y = 0 indiquant qu'aucune donnée ne pourra être transmise du second esclave dans le cycle de transmission suivant 94, qui ont nécessairement un volume de 0 octet.
Pendant la requête 86, la trame de requête 84 est trans- mise au maître qui l'exploite ; cette transmission se fait après que chaque esclave ait inscrit des informations "Y:Z" concernant les données dans le champ d'information associé 96, 98, 100, 102. En tant compte des informations fournies par les esclaves, le maître attribue un ordino- gramme dans le temps avec des fenêtres de temps pour la transmission des données dans le cycle suivant de transmission de données 94 ; cet ordinogramme dans le temps est caractérisé par l'organisation en série et la dimension des trames de transmission de données 88, 90, 92 transmises pendant le cycle de transmission de données 94.
Les informations contenues dans les champs d'information 96, 98, 100, 102 indiquent quel esclave doit envoyer quel volume de données et quel caractère déterminant et/ou quel âge ont les données à envoyer. Le maître est informé que le second esclave n'a pas à envoyer de données et que le caractère déterminant des données du troisième esclave (Y = 13), est supérieur au caractère déterminant des données du quatrième esclave (Y = 19) qui est lui-même supérieur au caractère déterminant des données du premier esclave (Y = 20). Le maître est également informé que le premier et le troisième esclave doivent envoyer chacun un volume de 2 octets de données et le quatrième esclave doit envoyer un volume de 4 octets de données.
En tenant compte de ces informations, le maître prépare l'ordinogramme chronologique (chronologie) pour le cycle suivant de transmission de données 94 qui caractérise le caractère déterminant et/ou l'âge des données à envoyer ainsi que le volume des données à envoyer chaque fois par un esclave. Pendant le cycle de transmission de données 94, le maître attribue un premier instant 104 (tl) au troisième esclave une première fenêtre de temps pour une première trame de transmission de données 88 ayant deux champs de données 106 pour enregistrer 2 octets de données. A un second instant 108 (t2), le maître attribue au quatrième esclave une fenêtre de temps pour une seconde trame de transmission de données 90 avec quatre champs de données 106 pour enregistrer 4 octets de données. A un troisième instant 110 (t3), le maître attribue au premier esclave une troisième fenêtre de temps pour la troisième trame de transmission de données 92 avec deux champs de données 106 pour enregistrer 2 octets de données. Dans le présent mode de réalisation, il est prévu pour chaque bit à transmettre, un temps de transmission TBit = 52 gs. De plus, l'en-tête 85 et ainsi la tête de données de chacune des trames présentées a pour les trames de requête 84 ainsi que pour les trames de transmission de données 88, 90, 92, une longueur de données BitEn- tête = 34. Pour la queue de chaque trame présentée à la figure 4, on a une longueur de données BitQueue = 10. Ainsi, pour un temps de transmission TFO de la trame de requête 84, on a la formule (1) suivante : TFO = 1,4 * (TBit * (BitEn-tête (NEsclaves * 10) BitQueue)) (1) La durée de transmission des données pour les trames de requête 84 est représentée dans le diagramme de la figure 4 par la première double flèche 108. La formule (2) donnée ci-après représente le temps de transfert des trames de transmission de données 88, 90, 92 ; m représente le numéro de l'esclave et Z le nombre d'octets à transmettre : TFmZ = 1,4 * (TBit * (BitEn-tête + (Z * 10) + BitQueue)) (2)35 Il est évident que pour toutes les durées de transmission de données TFrnZ représentées par la seconde double flèche 110 dans le diagramme de la figure 4, le temps de transmission de données TF32 de la première trame de transmission de données 88 est représenté pour le troisième esclave. Dans le mode de réalisation présenté, il est par exemple prévu que par cycle de transmission de données 94 et par esclave, on transmet jusqu'à 6 octets de données. C'est pourquoi, dans le dispositif de bus, on a prévu pour chaque trame de transmission de données 88, 90, 92, un maximum de six champs de données 106 pour recevoir les données utiles (charge de paiement). Ainsi, une trame de transmission de données 88, 90, 92 réalisée pour le transport d'un volume de données de 6 octets, a un temps de transmission TFm6 = 7;58 ms. Un cycle de transmission de données 94 a ainsi une durée 4 * 7,58 ms = 30,32 ms. Pour les trames de requête 84, on a un temps de transmission de données TFO = 6,13 ms. Pour la première trame de transmission de données 88 qui transmet 2 octets de données, on a ainsi un temps de transmission de données TF32 = 4,67 ms ; pour la seconde trame de transmission de données 90 par lequel on a transmis 4 octets de données, on a un temps de transmission de données TF44 = 6,13 ms et pour la troisième trame de transmission de données 92 avec laquelle on a également transmis 2 octets de données, on a un temps de transfert de données TF12 = 4,67 ms, de sorte que l'on a un temps de cycle pour le cycle de requête 86 et pour le cycle de transmission de données 94 qui résulte de la somme des temps de transfert de données 21,60 ms. Le mode de réalisation du dispositif de bus 112 représenté schématiquement à la figure 5 est un réseau LIN et comporte un maître 114 réalisé ici par l'appareil de commande d'un véhicule automobile. Le dispositif de bus 112 comporte un premier esclave 116, un second esclave 118, un mième esclave 120 ainsi qu'un klème et dernier esclave 122. Les esclaves 116, 118, 120, 122 peuvent être des capteurs ou des actionneurs du véhicule automobile. Tous les participants du dispositif de bus 112, c'est-à-dire le maître 114 et les esclaves 116, 118, 120, 122, sont reliés par une liaison de communication 124 en série.
Le maître 114 transmet aux esclaves 116, 118, 120, 122, une en-tête de trame de requête avec k champs d'information vides. Chaque fois au mième esclave 116, 118, 120, 122, est associé un mième champ d'information parmi les k champs d'information. Après réception de l'en-tête de la trame de requête par le mième esclave 116, 118, 120, 122, celui-ci inscrit dans le mième champ d'information qui lui est associé, une information indiquant le volume de données que ce mième esclave 116, 118, 120, 122 veut envoyer au maître 114 dans le cycle suivant de transmission de données. Après avoir rempli les champs d'information tout d'abord vides, les esclaves 116, 118, 120, 122 transmettent de nouveau la trame de requête renseignée avec les informations au maître 114. Après réception de la trame de requête, remplie, le maître 114 fournit un schéma chronologique pour la transmission de données ; ce schéma tient compte du volume de données à envoyer.
Il est en outre prévu que le mième esclave 116, 118, 120, 122 inscrive dans le mième champ d'information, en plus une information concernant une indication relative aux données à envoyer. Ces informations concernant l'indication des données sont également prises en compte par le maître 114 pour fournir l'ordinogramme en fonction du temps. Comme le mième esclave 116, 118, 120, 122 inscrit les informations relatives au volume et/ou à l'indication de données à émettre dans le mième champ d'informations, il indique au maître 114 si des données doivent être pourvues ou non.
Les données envoyées au cours d'un cycle de transmis- sion de données sont transmises en tenant compte de l'ordinogramme dans le temps (chronologie). Le même ordinogramme dans le temps est réalisé par la succession de fenêtres de temps qui sont attribuées par le maître 114 aux esclaves 116, 118, 120, 122.
En fournissant l'ordinogramme en fonction du temps à chaque esclave 116, 118, 120, 122 par les données transmises, on transmet une fenêtre de temps prévue à cet effet ; la (m) 116, 118, 120, 122 reçoit une mième fenêtre de temps. Un esclave 116, 118, 120, 122 qui a indiqué par l'écriture d'au moins une information dans le champ d'information associé, c'est-à-dire a donné une information relative au volume et/ou à l'indication des données, de sorte qu'il n'a pas à envoyer de données, pendant le cycle de transmission de données, le maître 114 a attribué une fenêtre de temps. Avec l'ordinogramme en fonction du temps, on fixe un ordre indiquant les esclaves qui doivent recevoir les données à trans- mettre. Cet ordre dépend entre autres de l'indication des données à prévoir. En inscrivant l'information relative à l'indication dans le champ d'information qui lui est associé dans la trame de requête, l'esclave 116, 118, 120, 122 indique au maître 114 la pertinence, l'importance, io l'urgence et/ou quelle trame de temps des données envoyées. Après ré- ception de la trame de requête, le maître 114 compare les informations qu'il a reçues de tous les esclaves 116, 118, 120, 122. Les informations relatives à l'indication sont fixées ici de manière quantitative par les valeurs et les données d'un esclave 116, 118, 120, 122 sont une indica- 15 tion par la valeur fournie. Pour réaliser l'ordinogramme, on attribue une première fenêtre de temps à chaque esclave 116, 118, 120, 122 dont les données à envoyer ont la plus grande valeur indicatrice avec une première fenêtre de temps. Un esclave d'ordre (n) 116, 118, 120, 122 et dont les données à transmettre ont prises vis-à-vis de l'indication dans 20 un ordre, toutes valeurs pour l'indication prennent le rang (n) en leur associant le (n) à la nième fenêtre de temps. A chaque esclave 116, 118, 120, 122 dont les données à transmettre ont une valeur inférieure à l'indication, on attribue en fin de compte une dernière fenêtre de temps. L'ordre en série en fonction des esclaves 116, 118, 120, 25 122 est transmis à la trame de transmission de données qui est remplie avec les données à envoyer ; ces données sont transmises par une trame de transmission de données vers le maître 114 qui reçoit la trame de transmission de données selon l'ordre et traite les données enregistrées selon l'ordre.
30 La mième trame de transmission de données comporte au moins un champ de données ayant un emplacement de mémoire adapté au volume des (m) données 116, 118, 120, 122 pour les données à envoyer et après réception de la mième trame de transmission de données par le mième esclave 116, 118, 120, 122, les données à envoyer sont in-

Claims (4)

  1. REVENDICATIONS1°) Procédé de gestion d'un dispositif de bus (112) comportant comme participants un maître (114) et k esclaves (116, 118, 120, 122), le maître (114) envoyant aux esclaves (116, 118, 120, 122) un en-tête (1, 85) comportant une trame de requête (2, 84), les k champs d'information (24, 26, 28, 30, 32, 34, 36, 38, 96, 98, 100, 102), - un mime champ d'information (24, 26, 28, 30, 32, 34, 36, 38, 96, 98, 100, 102) étant associé à chaque mièrne esclave (116, 118, 120, 122), * le mrenle esclave (116, 118, 120, 122) inscrivant dans le Mièrne champ d'information (24, 26, 28, 30, 32, 34, 36, 38, 96, 98, 100, 102) qui lui est associé, une information concernant la quantité de données à envoyer du mrerne esclave (116, 118, 120, 122) vers le maître (114), - la trame de requête (2, 84) étant transmise au maître (114), et - le maître (114) tient compte d'une chronologie pour transmettre les données, et selon laquelle il transmet la quantité de données.
  2. 2°) Procédé selon la revendication 1, caractérisé en ce que le mième esclave (116, 118, 120, 122) inscrit dans le mièrne champ d'information (24, 26, 28, 30, 32, 34, 36, 38, 96, 98, 100, 102) qui lui est associé, une information concernant une indication des données à envoyer.
  3. 3°) Procédé selon la revendication caractérisé en ce que le mrerne esclave (116, 118, 120, 122), par l'inscription d'au moins une information dans le mième champ d'information (24, 26, 28, 30, 32, 34, 36, 38, 96, 98, 100, 102), reçoit l'indication que des données sont ou non à envoyer.
  4. 4°) Procédé selon la revendication 1, caractérisé en ce que l'en-tête (1) est transmis par le maître (114) pour lancer un cycle de transmission de données (94) aux esclaves (116, 118, 120, 122) et les 25données à transmettre sont transmises pendant le cycle de transmission de données (94) en tenant compte de la chronologie. 10, 12, 14, 16, 18, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72) de la chronologie est attribuée, une mième fenêtre de temps (4, 6, 8, 10, 12, 14, 16, 18, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72) étant attribuée au mième esclave (116, 118, 120, 122). 6°) Procédé selon la revendication 5, 15 caractérisé en ce que la mième fenêtre de temps (4, 6, 8, 10, 12, 14, 16, 18, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72) est adaptée à la quantité de 20 le mième esclave (116, 118, 120, 122) insère dans au moins une fenêtre de données (106) d'une trame de transmission de données (88, 90, 92), les données à envoyer, la mième trame de transmission de données (4, 6, 8, 10, 12, 14, 16, 18, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72) qui lui est associée est transmise par le mième esclave (116, 118, 120, 122) vers le maître (114). 7°) Procédé selon la revendication 1, 30 caractérisé en ce que la chronologie fixe l'ordre indiquant l'instant auquel un esclave (116, 118, 120, 122) doit transmettre les données. 8°) Procédé selon l'une des revendications 5 à 7, 35 caractérisé en ce que 5°) Procédé selon la revendication 1, caractérisé en ce qu' en fournissant la chronologie à chaque esclave (116, 118, 120, 122) pour les données à transmettre, au moins une fenêtre de temps (4, 6, 8, données à envoyer par le mième esclave (116, 118, 120, 122), après attribution de sa mième fenêtre de temps (4, 6, 8, 10, 12, 14, 16, 18, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72),plusieurs fenêtres de temps (4, 6, 8, 10, 12, 14, 16, 18, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72) sont attribuées par le maître (114) aux esclaves (116, 118, 120, 122) en tenant compte de la chronologie. 9°) Dispositif de bus comportant comme participants un maître (114) et k esclaves (116, 118, 120, 122), le maître (114) transmettant aux esclaves (116, 118, 120, 122), un l'en-tête (1, 85) d'une trame de requête (2, 84) comportant k champs d'information (24, 26, 28, 30, 32, 34, 36, 38, 96, 98, 100, 102), un mième champ d'information (24, 26, 28, 30, 32, 34, 36, 38, 96, 98, 100, 102) étant associé à un Mièrne esclave (116, 118, 120, 122), chaque Mièrne esclave (116, 118, 120, 122) inscrivant une information dans le mIème champ d'information (24, 26, 28, 30, 32, 34, 36, 38, 96, 98, 100, 102) qui lui est attribué, cette information indiquant la quantité de données que le m'ènle esclave (116, 118, 120, 122) doit envoyer au maître (114), les esclaves (116, 118, 120, 122) transmettant les trames de requête (2, 84) au maître (114), et le maître (114) fournit une chronologie de transmission de données qui tient compte de la quantité de données à transmettre. 10°) Dispositif de bus selon la revendication 9, caractérisé en ce qu' il est réalisé comme réseau d'interconnexion locale LIN.30
FR1260421A 2011-11-04 2012-10-31 Procede de gestion d'un dispositif de bus Pending FR2982443A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102011085764A DE102011085764A1 (de) 2011-11-04 2011-11-04 Verfahren zum Betreiben einer Busanordnung

Publications (1)

Publication Number Publication Date
FR2982443A1 true FR2982443A1 (fr) 2013-05-10

Family

ID=48128806

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1260421A Pending FR2982443A1 (fr) 2011-11-04 2012-10-31 Procede de gestion d'un dispositif de bus

Country Status (5)

Country Link
US (1) US9143348B2 (fr)
JP (1) JP6258579B2 (fr)
CN (1) CN103281227B (fr)
DE (1) DE102011085764A1 (fr)
FR (1) FR2982443A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3033110A1 (fr) * 2015-02-19 2016-08-26 Peugeot Citroen Automobiles Sa Dispositif de transmission de donnees et vehicule associe
WO2019011836A1 (fr) * 2017-07-12 2019-01-17 Safran Electronics & Defense Système et procédé de communication pour la commande et le contrôle d'au moins un périphérique

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013002648B3 (de) * 2013-02-15 2014-05-22 Audi Ag Master-Busgerät für einen Fahrzeugkommunikationsbus eines Kraftwagens
US9582452B2 (en) * 2013-06-05 2017-02-28 The Boeing Company Sensor network using pulse width modulated signals
AT517782B1 (de) * 2015-10-01 2021-10-15 B & R Ind Automation Gmbh Verfahren zur asynchronen Datenkommunikation in einem echtzeitfähigen Ethernet-Datennetzwerk
CN109076004B (zh) * 2016-05-02 2021-01-01 索尤若驱动有限及两合公司 将另外的总线用户集成到总线系统中的方法以及总线系统
JP6729488B2 (ja) * 2017-05-17 2020-07-22 株式会社デンソー 通信システム、マスタノード、及び制御プログラム
DE102017118565A1 (de) 2017-08-15 2019-02-21 Valeo Schalter Und Sensoren Gmbh Verfahren zum Betreiben einer Sensoranordnung in einem Kraftfahrzeug auf Basis eines DSI-Protokolls
DE102018001574B4 (de) * 2018-02-28 2019-09-05 WAGO Verwaltungsgesellschaft mit beschränkter Haftung Master-Slave Bussystem und Verfahren zum Betrieb eines Bussystems
CN113169986A (zh) * 2018-12-07 2021-07-23 深圳市柔宇科技股份有限公司 网络会议数据传输方法及电子设备
DE102019205488A1 (de) * 2019-04-16 2020-10-22 Robert Bosch Gmbh Teilnehmerstation für ein serielles Bussystem und Verfahren zur Kommunikation in einem seriellen Bussystem
KR102256670B1 (ko) * 2019-11-06 2021-05-27 (주)로보티즈 효율적인 통신 버스 중재 시스템 및 방법
DE102020113977A1 (de) * 2020-05-25 2021-11-25 Bayerische Motoren Werke Aktiengesellschaft System zur datenübertragung in einem kraftfahrzeug, ver-fahren und kraftfahrzeug
DE102020215329A1 (de) * 2020-12-03 2022-06-09 Continental Automotive Gmbh Verfahren zum schnellen Flashen von Sensorknoten über ein Ethernetnetzwerk
DE102020215763A1 (de) * 2020-12-11 2022-06-15 Continental Automotive Gmbh Verfahren zur Optimierung der Übertragungsdatenrate in einem Sensornetzwerk im Teilnetzbetrieb in einem Ethernetnetzwerk

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04354221A (ja) * 1991-05-31 1992-12-08 Toshiba Corp 衛星パケット通信方式
JP3235041B2 (ja) * 1993-11-10 2001-12-04 日本電信電話株式会社 Tdd無線通信方式
DE19721740B4 (de) 1997-05-24 2005-06-30 Bosch Rexroth Ag Steuerungsverfahren für den Medienzugriff bei einem seriellen Bus
JP2001211192A (ja) * 2000-01-28 2001-08-03 Nec Corp データ同報配信の送信方法、通信方法、送信装置、及び通信方式
DE10065115A1 (de) * 2000-12-28 2002-07-04 Bosch Gmbh Robert Verfahren und Kommunikationssystem zum Datenaustausch zwischen mehreren über ein Bussystem miteinander in Verbindung stehenden Teilnehmern
AU2002257527A1 (en) * 2001-03-15 2002-10-03 Robert Bosch Gmbh Method and device for preparing a time schedule for the transmission of messages to a bus system
DE10145218A1 (de) * 2001-09-13 2003-04-03 Bosch Gmbh Robert Verfahren und Vorrichtung zur Zeitbestimmung in einem Bussystem und Bussystem
FR2889010B1 (fr) * 2005-07-19 2007-09-28 Valeo Vision Sa Procede et dispositif de communication pour vehicule automobile
JP4756340B2 (ja) * 2005-10-13 2011-08-24 株式会社デンソー 通信システム及び方法、並びに分散制御システム及び方法
DE102006055514A1 (de) * 2006-05-24 2007-11-29 Robert Bosch Gmbh Gateway zum Datentransfer zwischen seriellen Bussen
JP2008062802A (ja) * 2006-09-07 2008-03-21 Denso Corp 通信システム及びアドレス割り当て方法
JP5022740B2 (ja) * 2007-03-09 2012-09-12 矢崎総業株式会社 中継コネクタユニット、ワイヤハーネス組付体、及び、電子機器制御システム
CN101453757B (zh) * 2007-12-07 2011-03-16 中兴通讯股份有限公司 一种hsdpa流量控制的方法及系统
US8972514B2 (en) * 2008-12-12 2015-03-03 Mitsubishi Electric Corporation Data transmitting and receiving method, data transmitting and receiving system, master device, and slave device
CN102111688A (zh) * 2009-12-29 2011-06-29 华为技术有限公司 无源光网络的上行带宽分配方法及光线路终端
JP5140692B2 (ja) * 2010-03-12 2013-02-06 株式会社日立情報制御ソリューションズ ポーリング伝送システム、ポーリング伝送方法、および、ポーリング伝送プログラム
KR101703106B1 (ko) * 2011-01-04 2017-02-06 삼성전자주식회사 부분-이레이즈 동작을 수행할 수 있는 비휘발성 메모리 장치와 상기 비휘발성 메모리 장치를 포함하는 장치들
WO2013035953A1 (fr) * 2011-09-07 2013-03-14 Samsung Sdi Co., Ltd. Procédé de communication, système de communication et système de stockage d'énergie le comprenant

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3033110A1 (fr) * 2015-02-19 2016-08-26 Peugeot Citroen Automobiles Sa Dispositif de transmission de donnees et vehicule associe
WO2019011836A1 (fr) * 2017-07-12 2019-01-17 Safran Electronics & Defense Système et procédé de communication pour la commande et le contrôle d'au moins un périphérique
FR3069077A1 (fr) * 2017-07-12 2019-01-18 Safran Electronics & Defense Systeme et procede de communication pour la commande et le controle d'au moins un peripherique
US10805108B2 (en) 2017-07-12 2020-10-13 Safran Electronics & Defense Communication system and method for controlling and monitoring at least one peripheral

Also Published As

Publication number Publication date
JP2013098992A (ja) 2013-05-20
US20130117483A1 (en) 2013-05-09
US9143348B2 (en) 2015-09-22
CN103281227B (zh) 2018-11-09
DE102011085764A1 (de) 2013-05-08
JP6258579B2 (ja) 2018-01-10
CN103281227A (zh) 2013-09-04

Similar Documents

Publication Publication Date Title
FR2982443A1 (fr) Procede de gestion d'un dispositif de bus
EP0021917B1 (fr) Concentrateur téléinformatique pour réseau de transmission et de commutation de données par paquets
EP0403911B1 (fr) Procédé et dispositif de gestion d'acces au support de transmission d'un réseau de commutation reparti multiservices
EP0475161B1 (fr) Système de mémorisation temporaire d'information comprenant une mémoire tampon enregistrant des données structurées en blocs de données de longueur fixe ou variable
EP0003493B2 (fr) Système de transmission de données entre des stations connectées en boucle
EP0084389B1 (fr) Dispositif de transmission de données et réseau de communications avec récupération préventive des erreurs
FR2517442A1 (fr) Dispositif d'interruption pour un systeme de multitraitement, procede pour sa commande et systeme pour sa mise en oeuvre
FR2637997A1 (fr) Procede et dispositif pour mettre en file d'attente des requetes et des reponses sur un bus
FR2983670A1 (fr) Procede de transmission de donnees utiles de plusieurs capteurs vers un dispositif de commande de bus et dispositif de transmission de capteur pour un vehicule
FR2758681A1 (fr) Allocation a une pluralite d'elements d'autorisations d'acces a une ressource partagee
FR2504330A1 (fr) Reseau local de communication decentralise
FR2737030A1 (fr) Procede de transfert de messages dans un systeme informatique multinodal
EP0462294B1 (fr) Interface pour accès en émission et en réception au support de transmission synchrone d'un réseau de commutation réparti
EP0609114B1 (fr) Procédé de gestion du débit de messages codés numériquement transportés par un réseau asynchrone, notamment un réseau ATM, et dispositif pour sa mise en oeuvre
FR2779301A1 (fr) Procede d'identification d'appareils dans un reseau de communication et appareil de mise en oeuvre
EP0166838B1 (fr) Procédé et dispositif pour détecter une configuration de bits particulière dans un train de bits en série
EP0403912B1 (fr) Procédé et dispositif d'arbitrage pour accès en émission au support de transmission d'un réseau de commutation réparti
EP0667694B1 (fr) Procédé de mesure de paramètres de performance d'un réseau ATM et dispositif de mise en oeuvre
FR2536884A1 (fr) Reseau de transfert de donnees entre plusieurs processeurs et une memoire
FR2764759A1 (fr) Dispositif de controle de periodicite des messages transitant sur un reseau multiplexe de transmission d'une formation de type can
EP0632622B1 (fr) Procédé pour espacer temporellement les émissions de cellules appartenant à des messages ainsi que des dispositifs pour la mise en oeuvre d'un tel procédé
FR3023047A1 (fr) Procede de gestion de messages de panne d'un vehicule automobile
FR2991475B1 (fr) Dispositif de circuit pour systeme ainsi que systeme equipe et procede d'acces en memoire
FR2858076A1 (fr) Procede et dispositif de synchronisation d'unites de trainement de donnees reliees par un reseau
EP0011540B1 (fr) Dispositif d'interface entrée-sortie entre un commutateur de données et une pluralité de voies de transmission

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLSC Search report ready

Effective date: 20171103