FR3033110A1 - Dispositif de transmission de donnees et vehicule associe - Google Patents

Dispositif de transmission de donnees et vehicule associe Download PDF

Info

Publication number
FR3033110A1
FR3033110A1 FR1551436A FR1551436A FR3033110A1 FR 3033110 A1 FR3033110 A1 FR 3033110A1 FR 1551436 A FR1551436 A FR 1551436A FR 1551436 A FR1551436 A FR 1551436A FR 3033110 A1 FR3033110 A1 FR 3033110A1
Authority
FR
France
Prior art keywords
data
frame
node
master node
video data
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.)
Granted
Application number
FR1551436A
Other languages
English (en)
Other versions
FR3033110B1 (fr
Inventor
Mehdi Adjadj
Antony Boisserie
Julien Poussard
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.)
PSA Automobiles SA
Original Assignee
Peugeot Citroen Automobiles SA
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 Peugeot Citroen Automobiles SA filed Critical Peugeot Citroen Automobiles SA
Priority to FR1551436A priority Critical patent/FR3033110B1/fr
Publication of FR3033110A1 publication Critical patent/FR3033110A1/fr
Application granted granted Critical
Publication of FR3033110B1 publication Critical patent/FR3033110B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • 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/40052High-speed IEEE 1394 serial bus
    • H04L12/40117Interconnection of audio or video/imaging devices
    • 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/40267Bus for use in transportation systems
    • H04L2012/40273Bus for use in transportation systems the transportation system being a vehicle
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/64Hybrid switching systems
    • H04L12/6418Hybrid transport
    • H04L2012/6432Topology
    • H04L2012/6435Bus
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/64Hybrid switching systems
    • H04L12/6418Hybrid transport
    • H04L2012/6445Admission control
    • H04L2012/6448Medium Access Control [MAC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/64Hybrid switching systems
    • H04L12/6418Hybrid transport
    • H04L2012/6445Admission control
    • H04L2012/6448Medium Access Control [MAC]
    • H04L2012/6451Deterministic, e.g. Token, DQDB

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un dispositif (10) de transmission de données, comportant un nœud maître (11) et un nœud esclave (12) échangeant des données par l'intermédiaire d'une liaison de données (13), les données échangées comportant des données vidéo (14) circulant de façon unidirectionnelle et des données non vidéo (15) circulant de façon de façon bidirectionnelle, caractérisé en ce qu'il (10) comporte une table définissant des créneaux temporels, chaque créneau temporel définissant quel nœud (11, 12) est autorisé à transmettre des données non vidéo (15) sur la liaison de données (13), la table comportant au moins un créneau temporel autorisant le nœud maître (11) à émettre des données non vidéo (15) et au moins un créneau temporel autorisant le nœud esclave (12) à émettre des données non vidéo (15).

Description

1 Dispositif de transmission de données et véhicule associé L'invention concerne les liaisons numériques de type "LVDS", acronyme signifiant "Low Voltage Differential Signaling". L'invention concerne plus particulièrement le système d'émission et de réception des signaux émis ainsi que leur codage. Il est connu de l'état de la technique des liaisons LVDS dite bidirectionnelles. Une liaison LVDS bidirectionnelle permet de connecter deux noeuds et de transporter, d'une part, des données vidéo et, d'autre part, des données non vidéo. Les données vidéo sont transportées de façon unidirectionnelle alors que les données non vidéo sont transportées de façon bidirectionnelle. Les protocoles d'accès à ces liaisons LVDS bidirectionnelles ne définissent pas de règles d'accès au medium. Ainsi, les trames de données non vidéo peuvent entrer en collision. En effet, chacun des noeuds peut initier une trame de données non vidéo simultanément. Il en résulte que les deux trames de données non vidéo sont perturbées par cette collision et sont donc perdues. Lorsque la liaison LVDS bidirectionnelle est utilisée entre un calculateur multimédia et un écran tactile d'un véhicule, les données non vidéo sont, par exemple, des données de paramétrage de l'écran. Une collision entraine donc un effet indésirable pour un utilisateur comme l'absence de prise compte d'un paramétrage qu'il a commandé. L'invention a donc pour but de remédier au problème précité en proposant un dispositif de transmission de données vidéo et non vidéo permettant d'éviter des collisions entre des trames non vidéo émises par différents noeuds sur une même liaison. Elle propose plus précisément à cet effet un dispositif de transmission de données, comportant un noeud maître et un noeud esclave échangeant des données par l'intermédiaire d'une liaison de données, les données échangées comportant des données vidéo circulant de façon unidirectionnelle et des données non vidéo circulant de façon de façon bidirectionnelle, caractérisé en 3033110 2 ce qu'il comporte une table définissant des créneaux temporels, chaque créneau temporel définissant quel noeud est autorisé à transmettre des données non vidéo sur la liaison de données, la table comportant au moins un créneau temporel autorisant le noeud maître à émettre des données non 5 vidéo et au moins un créneau temporel autorisant le noeud esclave à émettre des données non vidéo. La table définissant les créneaux temporels permet d'indiquer à chaque instant quel noeud est autorisé à émettre sur la liaison de données. De la sorte, les noeuds n'émettent pas de trame de données non vidéo en la même temps et les collisions de trames sont évitées. De plus, les émissions des trames de données non-vidéo sont ainsi déterministes et donc prédictibles. L'invention permet aussi de s'assurer que les trames arrivent bien en temps et en heure, ce qui permet de garantir un temps de réactivité du 15 système. Par exemple, en définissant des créneaux temporels suffisamment courts, on peut obtenir une réactivité similaire à celle d'une dalle tactile, afin que l'utilisateur n'ait pas une sensation de lenteur lors des appuis sur une dalle tactile. Avantageusement, le noeud maître transmet des données non vidéo 20 au noeud esclave en émettant des trames d'écriture. Avantageusement, la durée d'un créneau temporel est strictement supérieure à la durée de transmission d'une trame d'écriture sur la liaison de données. Avantageusement, le noeud esclave transmet des données non vidéo 25 au noeud maître en émettant des trames de lecture en réponse à des trames d'en-tête émises par le noeud maître. Avantageusement, la durée d'un créneau temporel est strictement supérieure à la durée de transmission d'une trame d'en-tête et d'une trame de lecture sur la liaison de données.
30 Avantageusement, la table comporte en outre au moins un créneau temporel, dit sporadique, réservé à la transmission de données non vidéo ponctuelles du noeud esclave vers le noeud maître.
3033110 3 Avantageusement, les données non vidéo ponctuelles sont chacune associées à une priorité, la priorité étant utilisée pour déterminer dans quel ordre, les données non vidéo ponctuelles sont transmises. Avantageusement, la table est utilisée par le noeud maître de façon 5 cyclique, les créneaux étant traités l'un après l'autre, après avoir traité le dernier créneau de la table, le noeud maître revenant au premier créneau pour le traiter. Avantageusement, le noeud maître est un calculateur de véhicule, le noeud esclave étant un afficheur du véhicule.
10 L'invention concerne aussi un véhicule comportant un calculateur et un afficheur caractérisé en ce qu'il comporte en outre un dispositif de transmission de données selon l'invention, dans lequel le noeud maître est le calculateur et le noeud esclave l'afficheur. D'autres caractéristiques et avantages de l'invention apparaîtront à 15 l'examen de la description détaillée ci-après, et des dessins annexés, sur lesquels: la figure 1 illustre un exemple de réalisation d'un dispositif de transmission de données selon l'invention ; la figure 2 illustre une transmission de données depuis un noeud maître 20 vers un noeud esclave selon l'invention ; la figure 3 illustre une transmission de données depuis un noeud esclave vers le noeud maître selon l'invention ; la figure 4 illustre une trame d'écriture selon l'invention ; la figure 5 illustre une trame d'en-tête selon l'invention ; 25 la figure 6 illustre une trame de lecture selon l'invention ; la figure 7 illustre une table selon l'invention. Les dessins annexés pourront non seulement servir à compléter l'invention, mais aussi contribuer à sa définition, le cas échéant. La figure 1 montre un exemple de réalisation d'un dispositif de 30 transmission de données selon l'invention. Le dispositif 10 de transmission de données comporte un noeud maître 11 et un noeud esclave 12 connectés entre eux par une liaison de données 13.
3033110 4 La liaison de données 13 permet de transporter d'une part des données vidéo et d'autre part des données non vidéo, en particulier des données dites fonctionnelles correspondant à des informations de paramétrages du noeud maître 11 ou du noeud esclave 12. Les données 5 vidéo sont transportées de façon unidirectionnelle alors que les données non vidéo sont transportées de façon bidirectionnelle. La transmission des données entre le noeud maître 11 et le noeud esclave 12 est par exemple de type signalisation différentielle à basse tension aussi connue sous la dénomination LVDS (pour Low Voltage Differential Signaling).
10 Dans ce qui suit, on considère à titre d'exemple non limitatif que le noeud maître 11 est un calculateur d'un véhicule automobile et que le noeud esclave 12 est un afficheur dudit véhicule automobile. Les données vidéo circulent du noeud maître 11 vers le noeud esclave 12. Mais l'invention n'est pas limitée à ce mode de réalisation. Dans un 15 autre mode de réalisation, le noeud maître 11 est un calculateur automobile et le noeud esclave 12 une caméra. Dans ce cas, les données vidéo circulent du noeud esclave 12 vers le noeud maître 11. Plus généralement, l'invention concerne tout type de calculateurs aptes à émettre (ou recevoir) des données vidéo à destination (ou en 20 provenance) d'un autre équipement. Le noeud maître 11 comporte un sérialiseur apte à encoder des données sous forme de trame avant leur transfert sur la liaison 13. Le noeud esclave comporte un désérialiseur apte à décoder des trames de données provenant de la liaison 13.
25 La communication sur la liaison de données est gérée par le noeud maître 11 qui initie tous les échanges. Il existe deux types de transmission de données non vidéo : les transmissions depuis le noeud maître 11 vers le noeud esclave 12 et les transmissions depuis le noeud esclave 12 et le noeud maître 11.
30 La figure 2 illustre une transmission de données depuis le noeud maître 11 vers le noeud esclave 12. Cette transmission de données se fait par l'intermédiaire de trames d'écriture 20 (ou « write frames » en anglais). Une trame d'écriture 20 est 3033110 5 émise par le noeud maître 11 et consommée le noeud esclave 12 . La figure 4 montre un exemple de trame d'écriture. Une trame d'écriture 20 contient les champs suivants, toujours transmis dans le même ordre : - Un champ de synchronisation (SYNC), indiquant le début de la trame, 5 - Un champ (DEV ADDR) indiquant à quel composant (sérialiseur, désérialiseur ou microcontrôleur esclave), la trame est adressée, - Un identifiant (ID), permettant à l'application du noeud récepteur de savoir comment décoder le champ de données fonctionnelles, - Une longueur de trame (DLC), indiquant la taille de la trame ou la taille 10 champ de données fonctionnelles (en octet), - le champ de données fonctionnelles (Di) contenant des données de commandes (par exemple, le réglage de l'écran), - une somme de contrôle (CRC), pour vérifier que la trame reçue n'a pas été altérée au cours de la transmission.
15 La figure 3 illustre une transmission de données depuis le noeud esclave 12 vers le noeud maître 11. Cette transmission de données se fait par l'intermédiaire de trames d'en-tête 31 (ou « header frames ») et de trames de lecture 32 (ou « read frames » en anglais). Une trame d'en-tête 31 est émise par le noeud maître 11 20 à destination du noeud esclave 12 pour demander une réponse du noeud esclave 12. Une trame de lecture 32 est émise par le noeud esclave 12 en réponse à une trame d'entête 31. La figure 5 montre un exemple de trame d'en-tête. Une trame 31 d'entête contient les champs suivants, toujours 25 transmis dans le même ordre : - Un champ de synchronisation (SYNC), indiquant le début de la trame, - Un champ (DEV ADDR), indiquant à quel composant (sérialiseur, désérialiseur ou microcontrôleur esclave), la trame est adressée, - Un identifiant (ID), permettant à l'application du noeud récepteur de 30 savoir comment décoder le champ de données fonctionnelles, 3033110 6 - Une longueur de trame (DLC), indiquant la taille de la trame demandée (en octet). La figure 6 montre un exemple de trame lecture. Une trame de lecture 32 contient les champs suivants, toujours transmis dans le même ordre : 5 - un premier champ (ACK), indiquant le début de la trame, - un champ de données fonctionnelles (Di) contenant des données de commandes (par exemple, des données générées par un écran tactile indiquant quelle partie de l'écran est touchée par un utilisateur), - une somme de contrôle (CRC), pour vérifier que la trame reçue 10 n'a pas été altérée au cours de la transmission. Afin de garantir que le maître 11 et l'esclave 12 ne communiquent jamais en même temps, les échanges sont organisés selon une table cyclique (ou "schedule table" en anglais). La figure 7 illustre un exemple d'une table selon l'invention 15 Cette table définie une succession de créneaux temporels (ou fenêtres temporelles), appelées "slots", d'une longueur fixe Tslot (par exemple 5ms). Chaque slot contient un type d'échange (écriture ou lecture), autrement dit chaque slot indique quel noeud est autorisé à émettre sur la liaison de données.
20 Le noeud maître 11 gère cette table de façon cyclique : après avoir traité le dernier slot de la table, le maître revient au premier slot Il existe deux types de slots : - Le slot d'écriture : contient une trame écriture 20 uniquement. Ce slot permet au noeud maître 11 d'envoyer des données au noeud l'esclave 25 12. - Le slot de lecture : contient une trame entête 31 suivi d'une trame lecture 32. Ce slot permet au noeud maître 11 de recevoir des données de la part du noeud esclave 12. De façon avantageuse, la table cyclique définit en outre au moins un 30 créneau dit sporadique ou slot sporadique.
3033110 7 Un slot sporadique peut être lié à une ou plusieurs trames écriture et/ou plusieurs trames en-tête, contrairement au slot écriture, qui n'est lié qu'à une seule trame écriture et au slot lecture, qui n'est lié qu'à une seule trame en-tête et une seule trame lecture.
5 Les conditions d'émission des trames liées à un slot sporadique, sont définies dans la messagerie de réseau. La messagerie définit l'ensemble des flux échangés dans les trames de commande et la position précise de ces flux dans les trames. Un slot sporadique peut être implémenté une ou plusieurs fois dans 1 o une table cyclique. L'utilisation de slot sporadique permet de prévoir dans la table un espace pour l'émission de messages qui ont une évolution très lente. Autrement dit, des messages dont le contenu évolue très lentement (par exemple une évolution toute les minutes ou plus). C'est le cas, par exemple, 15 de messages liés au diagnostic. Avantageusement, une trame d'écriture n'est émise que lorsque le message associé à cette trame a évolué par rapport à la dernière émission de cette trame. L'évaluation de cette évolution est réalisée par le noeud maître 11 lorsqu'il traite le slot associé à cette trame.
20 Dans l'exemple, les conditions d'émission des messages WRITE_2 et WRITE3 sont liées à une évolution de leur contenu. Une trame WRITE_2 (ou WRITE_3) n'est effectivement émise, lors du traitement de son slot, que lorsque le contenu de son message a évolué. On peut donner comme exemple d'évolution de contenu de 25 messages : l'envoi d'une trame de diagnostic WRITE avec un identifiant Ox3C pour l'ouverture d'une cession de diagnostic ; puis l'envoi d'une ou plusieurs autres trames de WRITE Ox3C pour écrire un paramètre diagnostic dans l'esclave. De façon générale, l'émission de trames d'en-tête par le noeud maître 30 11 dépend d'un flux fonctionnel interne au noeud maître 11. Dans l'exemple, les conditions d'émission du message HEADER_6 3033110 8 dépend d'un flux fonctionnel interne du maître FLUX_1. Les conditions d'émission du message HEADER_7 dépend d'un autre flux fonctionnel interne du maître FLUX_2. On peut donner comme exemple d'évolution de contenu de 5 messages : l'envoi d'une ou plusieurs trame(s) de diagnostic HEADER avec un identifiant Ox3D pour lire une donnée diagnostic. FLUX_1 correspondrait alors à l'émission dans un slot précédent d'une trame WRITE demandant l'ouverture d'une session diagnostique. Dans l'exemple, sans évolution du contenu des messages WRITE_2 1 o et WRITE_3, et en l'absence d'activation des flux FLUX_1 et FLUX_2, le slot sporadique SPO reste vide, autrement dit, aucune trame n'est émise dans le slot. Sur évolution du message WRITE_2, la trame WRITE_2 est émise dans le slot sporadique SPO.
15 Sur évolution du message WRITE_3, la trame WRITE_3 est émise dans le slot sporadique SPO. Sur activation du flux FLUX_1, la trame HEADER_6 est émise dans le slot sporadique SPO. L'esclave répondra à la suite de ce HEADER, dans le même slot sporadique SPO.
20 Sur activation du flux FLUX_2, la trame HEADER_7 est émise dans le slot sporadique SPO. L'esclave répondra à la suite de ce HEADER, dans le même slot sporadique SPO. Pour gérer les cas où plusieurs conditions sont actives en même temps, une notion de priorité est introduite sur les messages liés au slot 25 sporadique. Ainsi, chacun des messages (WRITE_2, WRITE_3, HEADER_6, HEADER_7) est associé à une priorité différente. Lorsque plusieurs messages doivent être émis dans un slot sporadique, c'est le message de plus forte priorité qui sera émis en premier.
30 Les autres messages seront émis dans les autres occurrences du slot sporadique, dans l'ordre correspondant à leur priorité. En reprenant l'exemple précédent, on peut assigner les priorités 303 3 1 10 9 suivantes à chacun des messages : WRITE_2, priorité 2 ; WRITE_3, priorité 4 ; HEADER_6, priorité 1 ; HEADER_7, priorité 3. Afin de garantir l'absence de collisions entre une trame émise le noeud maître 11 et une trame émise par le noeud esclave 12 et d'assurer 5 l'aspect déterministe du réseau, chaque trame est contenue dans son slot. Autrement dit : - Une trame écriture 20 a une longueur (autrement dit une durée de transmission) inférieure à la durée d'un slot Tslot, et - L'échange lecture (longueur de la trame en-tête 31 plus temps de réponse o du noeud esclave 12 plus longueur de la trame lecture 32) doit avoir une longueur inférieure à la durée d'un slot Tslot. La longueur d'une trame écriture 20 dépend de deux paramètres : (i) le nombre d'octets total de la trame et (ii) le temps entre chaque octet. Pour s'assurer qu'une trame est contenue dans le slot, la taille du slot 15 est strictement supérieure à la taille d'une trame. On applique par exemple la règle suivante : Tframe_max = 0,6*Tslot avec Tframe_max la taille maximale d'une trame. Cette règle permet de prévoir une marge de 20% pour le délai de transmission (ou jitter) du noeud 20 maître 11 et 20% de marge supplémentaire par rapport à la fin du slot. De façon avantageuse, on définit une contrainte de performance : le temps inter octet total maximum est de 20% du Tframemin. Où Tframe min correspond à la durée de la trame lorsque tous les octets sont nuls.
25 Cette contrainte induit un nombre maximum de données utiles (Di) dans la trame. Par exemple, pour une taille de slot (Tslot) de 5ms et un débit (D) de 500kbit/s, la taille maximale d'une trame est de 3ms (Tframe_max = 5*0,6=3ms) et la la durée de la trame lorsque tous les octets sont nuls est de 2,5ms 3 0 (Tframe_min = 3/1 ,2=2,5ms).
303 3 1 10 10 Sachant que le débit est de 500kbit/s, un bit représente donc 2us et donc un octet (11 bits) représente 22us. On peut noter que la transmission d'un octet utile nécessite la transmission de 11bits : soit 8 bits utiles encapsulés avec un bit de départ (ou 5 start) au début et ainsi qu'un bit de parité suivi d'un bit de stop à la fin. Le nombre d'octets total de la trame = 2,5/0,022=113. On pourra en conclure le nombre d'octets de données utiles, en fonction du nombre d'octets d'encapsulation. La durée de l'échange de trames d'en-tête et de lecture dépend des 10 paramètres suivants : - Le temps inter octets dans de la trame d'en tête 31, - Le temps de réponse du noeud esclave 12, entre la trame d'en tête 31 et la trame de lecture 32, - le nombre d'octets total de la trame lecture 32, 15 - le temps entre chaque octet de la trame lecture. On définit une durée maximale de la trame HEADER (Theader_ frame_max) et une contrainte de performance imposant que le temps inter octet total est à 20% du Theader framemin- Theaderframe_max = 1,2 Theader framemin- 20 On définit une durée maximale de la trame READ Tread frame max - On définit la contrainte de performance suivante : le temps inter octet total à 20% du Treadframemin- Tread_frame_max = 1,2 Treadframemin- Pour s'assurer que l'échange de lecture est contenu dans le slot, on 25 définit la relation suivante : Theaderframe_max + Tresp_max + Tread_frame_max = 0,6*Tslot : de façon à avoir 20% de marge pour le jitter (délai de transmission) du noeud maître 11 et 20% de marge supplémentaire par rapport à la fin du slot. Par exemple, pour une taille de slot (Tslot) de 5ms et un débit (D) de 303 3 1 10 11 500kbit/s, la taille maximale d'un échange de lecture est de 3ms (Theaderframe_max + Tresp_max + Tread_frame_max = 0,6*Talaf = 5*0,6 = 3ms) Sachant que le débit est de 500kbit/s, un bit représente donc 2us et donc un octet transmis (11 bits) représente 22us.
5 En considérant que le nombre d'octets total de la trame HEADER est de 4, on obtient : Theaderframe_min = 4*22us = 88us Theader frame max = 88*1,2 = 105us. En définissant, la contrainte suivante : Tresp_max = 600us (valeur 10 choisie pour avoir au moins 50 octets dans la trame READ), on en déduit : Tread_frame_max = 0,6*Talor(Theader_frame_max + Tresp_max) Tread frame max = 2,295ms Tread frame min = 2,295/1,2 Tread frame min = 1,912ms 15 Sachant qu'un octet LVDS (11 bits) représente 22us, le nombre d'octets total de la trame READ= 1,912/0,022=86. On pourra en conclure le nombre d'octets de données utiles, en fonction du nombre d'octets d'encapsulation.

Claims (10)

  1. REVENDICATIONS1. Dispositif (10) de transmission de données, comportant un noeud maître (11) et un noeud esclave (12) échangeant des données par l'intermédiaire d'une liaison de données (13), les données échangées comportant des données vidéo (14) circulant de façon unidirectionnelle et des données non vidéo (15) circulant de façon de façon bidirectionnelle, caractérisé en ce qu'il (10) comporte une table définissant des créneaux temporels, chaque créneau temporel définissant quel noeud (11,12) est autorisé à transmettre des données non vidéo (15) sur la liaison de données (13), la table comportant au moins un créneau temporel autorisant le noeud maître (11) à émettre des données non vidéo (15) et au moins un créneau temporel autorisant le noeud esclave (12) à émettre des données non vidéo (15).
  2. 2. Dispositif (10) de transmission de données selon la revendication 1, caractérisé en ce que, le noeud maître (11) transmet des données non vidéo (15) au noeud esclave (12) en émettant des trames d'écriture (20).
  3. 3. Dispositif (10) de transmission de données selon la revendication 2, caractérisé en ce que la durée d'un créneau temporel est strictement supérieure à la durée de transmission d'une trame d'écriture (20) sur la liaison de données (13).
  4. 4. Dispositif (10) de transmission de données selon l'une des revendications précédentes, caractérisé en ce que le noeud esclave (12) transmet des données non vidéo (15) au noeud maître (11) en émettant des trames de lecture (32) en réponse à des trames d'en-tête (31) émises par le noeud maître (11).
  5. 5. Dispositif (10) de transmission de données selon la revendication 4, 3033110 13 caractérisé en ce que la durée d'un créneau temporel est strictement supérieure à la durée de transmission d'une trame d'en-tête (31) et d'une trame de lecture (32) sur la liaison de données (13). 5
  6. 6. Dispositif (10) de transmission de données selon l'une des revendications précédentes, caractérisé en ce que la table comporte en outre au moins un créneau temporel, dit sporadique, réservé à la transmission de données non vidéo (15) ponctuelles du noeud esclave (12) vers le noeud maître (11). 10
  7. 7. Dispositif (10) de transmission de données selon la revendication 6, caractérisé en ce que les données non vidéo (15) ponctuelles sont chacune associées à une priorité, la priorité étant utilisée pour déterminer dans quel ordre, les données non vidéo (15) ponctuelles sont transmises. 15
  8. 8. Dispositif (10) de transmission de données selon l'une des revendications précédentes, caractérisé en ce que la table est utilisée par le noeud maître (11) de façon cyclique, les créneaux étant traités l'un après l'autre, après avoir traité le dernier créneau de la table, le noeud maître (11) revenant au premier créneau pour le traiter. 20
  9. 9. Dispositif (10) de transmission de données selon l'une des revendications précédentes, caractérisé en ce que le noeud maître (11) est un calculateur de véhicule, le noeud esclave (12) étant un afficheur du véhicule. 25
  10. 10. Véhicule comportant un calculateur et un afficheur caractérisé en ce qu'il comporte en outre un dispositif (10) de transmission de données selon l'une des revendications précédentes, dans lequel le noeud maître (11) est le calculateur et le noeud esclave (12) l'afficheur.
FR1551436A 2015-02-19 2015-02-19 Dispositif de transmission de donnees et vehicule associe Expired - Fee Related FR3033110B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1551436A FR3033110B1 (fr) 2015-02-19 2015-02-19 Dispositif de transmission de donnees et vehicule associe

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1551436A FR3033110B1 (fr) 2015-02-19 2015-02-19 Dispositif de transmission de donnees et vehicule associe

Publications (2)

Publication Number Publication Date
FR3033110A1 true FR3033110A1 (fr) 2016-08-26
FR3033110B1 FR3033110B1 (fr) 2017-02-17

Family

ID=54007768

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1551436A Expired - Fee Related FR3033110B1 (fr) 2015-02-19 2015-02-19 Dispositif de transmission de donnees et vehicule associe

Country Status (1)

Country Link
FR (1) FR3033110B1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3851104A (en) * 1973-04-11 1974-11-26 Mitre Corp Digital communications system
DE102008061712A1 (de) * 2008-12-12 2010-06-17 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zur Übertragung von Daten in einem Fahrzeug
FR2945171A1 (fr) * 2009-04-29 2010-11-05 Peugeot Citroen Automobiles Sa Procede de transmission de messages
EP2410697A1 (fr) * 2010-07-20 2012-01-25 ABB Research Ltd. Transmission de trame et réseau de communication
FR2982443A1 (fr) * 2011-11-04 2013-05-10 Bosch Gmbh Robert Procede de gestion d'un dispositif de bus
EP2614996A1 (fr) * 2012-01-13 2013-07-17 Technische Universität Kaiserslautern Noeud d'émission/de réception commandé de manière temporelle et prioritaire pour FlexRay et LIN

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3851104A (en) * 1973-04-11 1974-11-26 Mitre Corp Digital communications system
DE102008061712A1 (de) * 2008-12-12 2010-06-17 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zur Übertragung von Daten in einem Fahrzeug
FR2945171A1 (fr) * 2009-04-29 2010-11-05 Peugeot Citroen Automobiles Sa Procede de transmission de messages
EP2410697A1 (fr) * 2010-07-20 2012-01-25 ABB Research Ltd. Transmission de trame et réseau de communication
FR2982443A1 (fr) * 2011-11-04 2013-05-10 Bosch Gmbh Robert Procede de gestion d'un dispositif de bus
EP2614996A1 (fr) * 2012-01-13 2013-07-17 Technische Universität Kaiserslautern Noeud d'émission/de réception commandé de manière temporelle et prioritaire pour FlexRay et LIN

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
PEDREIRAS P ET AL: "The flexible time-triggered (FTT) paradigm: an approach to QoS management in distributed real-time systems", PARALLEL AND DISTRIBUTED PROCESSING SYMPOSIUM, 2003. PROCEEDINGS. INTE RNATIONAL APRIL 22-26, 2003, PISCATAWAY, NJ, USA,IEEE, 22 April 2003 (2003-04-22), pages 123 - 131, XP010645672, ISBN: 978-0-7695-1926-5 *
RICHARDSON P ET AL: "Intravehicle computer networks: emerging trends, protocols, and obstacles", ANNUAL REVIEW OF COMMUNICATIONS, NATIONAL ENGINEERING CONSORTIUM, CHICAGO, IL, US, vol. 57, 1 January 2004 (2004-01-01), pages 763 - 781, XP001520646, ISSN: 0886-229X *
TILL STEINBACH ET AL: "Tomorrow's In-Car Interconnect? A Competitive Evaluation of IEEE 802.1 AVB and Time-Triggered Ethernet (AS6802)", VEHICULAR TECHNOLOGY CONFERENCE (VTC FALL), 2012 IEEE, IEEE, 3 September 2012 (2012-09-03), pages 1 - 5, XP032294507, ISBN: 978-1-4673-1880-8, DOI: 10.1109/VTCFALL.2012.6398932 *
TUOHY SHANE ET AL: "Next generation wired intra-vehicle networks, a review", 2013 IEEE INTELLIGENT VEHICLES SYMPOSIUM (IV), IEEE, 23 June 2013 (2013-06-23), pages 777 - 782, XP032501947, ISSN: 1931-0587, [retrieved on 20131010], DOI: 10.1109/IVS.2013.6629561 *

Also Published As

Publication number Publication date
FR3033110B1 (fr) 2017-02-17

Similar Documents

Publication Publication Date Title
FR2965374A1 (fr) Communication maitre-esclave sur bus unifilaire entre un circuit maitre et au moins deux circuits esclaves
Reusch et al. Dependability‐aware routing and scheduling for Time‐Sensitive Networking
EP2923461B1 (fr) Dispositif et procédé de retransmission de données dans un commutateur réseau
FR2998125A1 (fr) Procede de transmission de paquets de donnees entre deux modules de communication ainsi que module emetteur et module recepteur
FR3033110A1 (fr) Dispositif de transmission de donnees et vehicule associe
FR2988934A1 (fr) Dispositif de communication et procede de programmation ou de correction d'erreur d'un ou plusieurs participants du dispositif de communication
FR2790892A1 (fr) Procede et dispositif de controle de la synchronisation entre deux bus de communication serie d'un reseau
EP3122005B1 (fr) Système de routage permettant le filtrage de données pour l'intégration et le test d'équipements opérationnels
FR3039952A1 (fr) Procede de transmission d'information entre deux domaines de niveaux de securite distincts
FR3001310A1 (fr) Interface de reseau sur puce dotee d'un systeme adaptatif de declenchement d'envoi de donnees
WO2020109733A2 (fr) Gestion des données pour le stockage de trames de données dans la mémoire d'un système de transmission de données
KR102342000B1 (ko) 차량 네트워크에서 프레젠테이션 타임에 기초한 콘텐츠의 재생 방법 및 장치
US8331788B2 (en) Encapsulation scheme for optical over Ethernet
EP3146683A1 (fr) Commutateur de trames numeriques
EP2740039B1 (fr) Dispositif pour echanger des donnees entre au moins deux applications
JP2015032985A (ja) 通信制御装置、通信制御方法、および通信制御システム
FR3001311A1 (fr) Interface reseau d'un soc comportant un controleur de communication ameliore
FR3087979A1 (fr) Systeme de transmission de donnees
FR2925806A1 (fr) Procede de transmission de donnees et dispositif correspondant
EP3295613A1 (fr) Procédé et dispositif de contrôle de la transmission de trames dans un réseau vidéo bidirectionnel.
FR3103583A1 (fr) Système de gestion des données partagées
EP2929657A1 (fr) Dispositif d'entrées sorties transférant et/ou recevant des données à un dispositif de contrôle
EP2840762B1 (fr) Équipement de type lame productive multiserveur pour châssis modulaire, avec accès multiples par le réseau de gestion du châssis
FR2574236A1 (fr) Procede d'adressage entre une station emettrice d'un message et au moins une station receptrice dans un reseau de communication et dispositif permettant la mise en oeuvre du procede
FR2823041A1 (fr) Procede, application, dispositifs et modules de gestion de paquets de donnees dans un noeud de communication

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20160826

PLFP Fee payment

Year of fee payment: 3

CA Change of address

Effective date: 20180312

CD Change of name or company name

Owner name: PEUGEOT CITROEN AUTOMOBILES SA, FR

Effective date: 20180312

ST Notification of lapse

Effective date: 20181031