EP3607730A1 - Dispositif de gestion pour gérer un réseau ethernet/ip via un organe ethernet - Google Patents

Dispositif de gestion pour gérer un réseau ethernet/ip via un organe ethernet

Info

Publication number
EP3607730A1
EP3607730A1 EP18715231.9A EP18715231A EP3607730A1 EP 3607730 A1 EP3607730 A1 EP 3607730A1 EP 18715231 A EP18715231 A EP 18715231A EP 3607730 A1 EP3607730 A1 EP 3607730A1
Authority
EP
European Patent Office
Prior art keywords
ethernet
protocol
management
type
service
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
EP18715231.9A
Other languages
German (de)
English (en)
Inventor
Antony Boisserie
Jean Thibault VIARD
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.)
Stellantis Auto SAS
Original Assignee
PSA 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 PSA Automobiles SA filed Critical PSA Automobiles SA
Publication of EP3607730A1 publication Critical patent/EP3607730A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/407—Bus networks with decentralised control
    • H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]

Definitions

  • the invention relates to Ethernet / 1P ("Internet Protocol") and layered communication networks of the TCP / IP (Transport Control Protocol / Internet Protocol) model, and more specifically the management of such networks via Ethernet devices (or nodes) that they understand.
  • Ethernet / 1P Internet Protocol
  • IP Transmission Control Protocol / Internet Protocol
  • the layer structure of the TCP / IP model includes a first network access layer using the MAC 802.3 protocol, a second network layer using the IP, ARP, ICMP and IGMP protocols. a third transport layer using the TCP and UDP ("User Datagram Protocol") protocols, and a fourth application layer allowing services provided by the Ethernet members (or nodes) to access their communication network.
  • an audio and / or video service may require a protocol of the RTP family or a protocol such as AVB or TSN
  • a human-machine interface (HMI) service and a control-command service may require a protocol such as HTTP (HTML5) or MQTT or SOME / IP
  • a synchronization service may require a protocol such as NTP or PTP or 802.1 AS
  • a connection service may require a protocol such as Telnet or SSH
  • a service file transfer may require a protocol such as FTP or TFTP
  • a mail service may require a protocol such as IMAP or POP3 or SMTP
  • a system service may require a protocol such as DNS or DHCP or SNMP or DolP.
  • Ethernet / IP communication
  • services need to perform certain management functions, for example to control different phases of network life, supervise Ethernet devices (or nodes) to determine their network connection status, test the different protocols used in the TCP / IP model protocol stack, and perform generic functional services (for example ensure a message gateway between different network technologies).
  • the invention is therefore particularly intended to improve the situation.
  • a management device intended to equip an Ethernet device to be coupled to an Ethernet / 1 P type communication network, suitable for the bidirectional transmission of data frames between ethernet devices and structured in layers.
  • a TCP / IP model among which a transport layer and an application layer placed above the transport layer and allowing services provided by the Ethernet devices to access the communication network.
  • a so-called management data frame comprising a message that has been generated by a service provided by this Ethernet element and intended for at least one other Ethernet device, having a type and preceded by a header comprising first, second and third fields respectively identifying this service, this type and a length of the management data frame, and transmitting to a service of the application layer of its Ethernet element a message that has been generated by another Ethernet element, having a type and preceded by a second field identifying this type.
  • each network management function can now be managed by each of the organs (or nodes) Ethernet, and can even be divided between several Ethernet devices.
  • the management device according to the invention may include other features that can be taken separately or in combination, and in particular:
  • the management protocol for transmitting to the transport layer of its Ethernet element a concatenated frame comprising at least two frames of management data each comprising a message that has been generated by a service provided by its Ethernet element, intended for at least one other Ethernet element, placed one after the other, and encapsulated between a UDP header of a UDP protocol of the transport layer and a checksum field of a layer of network access of the TCP / IP model;
  • the first field of the management protocol may, for example, comprise two bytes
  • the third field of the management protocol may, for example, comprise two bytes
  • the third field of the management protocol may, for example, comprise a number of bytes of between three and five;
  • each service can, for example, be chosen from a phase control (s) of life of the communication network, a supervision of at least one Ethernet element to determine a connection state to the communication network, a test of least one protocol used in a protocol stack of the TCP / IP model, and a realization of at least one generic functional service.
  • phase control s
  • each service can, for example, be chosen from a phase control (s) of life of the communication network, a supervision of at least one Ethernet element to determine a connection state to the communication network, a test of least one protocol used in a protocol stack of the TCP / IP model, and a realization of at least one generic functional service.
  • the invention also proposes an Ethernet element, on the one hand, intended to be coupled to an Ethernet / 1P type communication network, suitable for the bidirectional transmission of data frames between Ethernet organs and structured in layers of a TCP / IP model, and, secondly, comprising a management device of the type of that presented above.
  • the invention also proposes a Ethernet / 1P type communication network, structured in layers of a TCP / IP model, and comprising at least two Ethernet devices of the type of the one presented above and suitable for exchanging frames. bidirectionally.
  • the invention also proposes a vehicle, possibly of automobile type, and comprising at least one communication network of the type of that presented above.
  • FIG. 1 diagrammatically and functionally illustrates a vehicle comprising an exemplary Ethernet / IP communication network comprising four Ethernet members (or nodes) each equipped with a management device according to the invention
  • FIG. 2 schematically illustrates a management data frame conforming to the management protocol of the invention
  • FIG. 3 schematically illustrates an example of a concatenated frame comprising three frames of management data compliant with the management protocol of the invention and encapsulated.
  • the object of the invention is in particular to propose a management device DG intended to equip an Ethernet device Oj to be coupled to an Ethernet / IP type TCP / IP-based network communication network.
  • the layer structure of the TCP / IP model includes a first network access layer using the MAC 802.3 protocol, a second network layer using the IP, ARP, ICMP and IGMP protocols, a third transport layer using the TCP and UDP protocols (User Datagram Protocol), and a fourth application layer allowing services provided by the organs (or nodes) Ethernet Oj to access the communication network RC.
  • the protocols used in this application layer basically depend on the services that are offered by Oj Ethernet organs (or nodes).
  • the RC communication network is intended to be installed in a vehicle V automobile, such as a car.
  • the invention is not limited to this application. It concerns any system, installation or apparatus that may include at least one Ethernet / 1P communication network suitable for the bidirectional transmission of data frames between Ethernet devices (or nodes). It therefore relates in particular to vehicles, whether terrestrial, maritime (or fluvial), or air, facilities, possibly of industrial type, and buildings.
  • FIG. 1 shows schematically a nonlimiting example of a network (of communication) RC of the Ethernet / IP type.
  • the organs (or nodes) Ethernet Oj can be of any type.
  • a car it may be a computer (possibly multimedia), a smart antenna of an infotainment module, a device for merging acquired images, or a screen.
  • the invention proposes to equip each Ethernet member (or node) Oj of the RC network with a management device DG using in the application layer a new management protocol for the transmission and reception of Ethernet / IP frames used. (or generated) by any of the services provided by the different organs (or nodes) Ethernet Oj.
  • These transmissions and receptions are intended to allow the realization of certain functions of management of the RC network, such as for example the control of the various phases of life of the RC network, the supervision of the organs (or nodes) Ethernet Oj to determine their connection status to the network, the testing of the different protocols used in the protocol stack of the TCP / IP model, and the realization of generic functional services (such as ensuring a message gateway between different technologies network).
  • the management device DG of an Ethernet device Oj uses the new management protocol to transmit to the transport layer of this Ethernet element Oj, on a dedicated management port, a so-called management data frame tg.
  • the latter (tg) comprises, as illustrated in FIG. 2, a message (or "payload" - useful data) that has been generated by a service provided by this Ethernet element Oj and which is intended for at least one other Ethernet device Oj '(j' ⁇ j), having a type and preceded by a header etg comprising first C1, second C2 and third C3 fields respectively identifying this service, this type and the length of the management data frame tg.
  • the management device DG receives from the service of its Ethernet element Oj the message and the type of this message, and generates the management data frame tg by adding to this message a header including the first field C1 identifying this service, the second field C2 identifying the type of the message, and the third field C3 defining the length of the management data frame tg.
  • the management device DG of an Ethernet element Oj also uses the new management protocol to transmit to a service of the application layer of this Ethernet element Oj a message (or payload) which has been generated by another Ethernet member Oj '(j' ⁇ j), having a type and preceded by a second field C2 identifying this type.
  • this transmission is done after extraction by the management device DG in a management data frame tg, received from another Ethernet element Oj 'and communicated by the transport layer via the dedicated management port, of its message. and the second field C2 of its header etg, and determination of the destination service of this message and identified by the first field C1 of its header etg.
  • each of the above-mentioned RC network management functions can be managed by each of the Ethernet members (or nodes) Oj, or can be distributed among several Ethernet members Oj.
  • the management device DG can also use in the application layer the management protocol for transmitting to the transport layer of its Ethernet element Oj, via the dedicated management port, a concatenated frame te.
  • the latter (te) which is generated by the management device DG, comprises, as illustrated in FIG. 3, at least two tgk management data frames, each comprising a message generated by a service provided by the Ethernet element Oj, intended for at least one other Ethernet element Oj '(j' ⁇ j), placed one after the other, and encapsulated between a UDP header of the UDP protocol of the transport layer and a CRCMAC checksum field of the first network access layer of the TCP / IP model.
  • checksum field (CRC or "CHECKSUM) is intended to allow an Ethernet device to verify that the frame it has received has not been altered during transmission.
  • the first field C1 of the management protocol may comprise two bytes (or "bytes"). But it could include a single byte or three bytes. This number of bytes is a function of the number of services provided by the different organs (or nodes) Ethernet Oj RC network.
  • the second field C2 of the management protocol may comprise two bytes (or bytes). But it could include a single byte or three bytes. This number of bytes is a function of the number of message types used by the services provided by the different organs (or nodes) Ethernet Oj of the RC network, to perform the various management functions of the network RC.
  • a service designates a management function of the network RC. Therefore, a service may, for example, be selected from the phase control (s) life of the RC communication network, the supervision of at least one Ethernet member Oj, Oj 'to determine a connection state to the network of communication, the test of at least one protocol used in a protocol stack of the TCP / IP model, and the realization of at least one generic functional service (such as for example providing a message gateway between different network technologies).
  • the type of a message characterizes a message in a service. For example, it is possible to have a wake-up frame for the control service of the life phases of the communication network RC, or a configuration frame for performing a test for the protocol testability service (s).
  • the third field C3 of the management protocol may comprise a number of bytes of between three and five.
  • this number of bytes can be equal to four (4).
  • This number of bytes is a function of the maximum length that can present a management data frame tg (etg + message header) generated by a management device DG.
  • dedicated management port may, for example, be at the address 1120 (in decimal).
  • management device DG can be implemented at the level of the application software of an Ethernet device Oj. Therefore, it (DG) can, for example, be realized in the form of a combination of software modules (or "software").
  • the invention requires the use of a small amount of computing resources (or CPU) and reduced memory. Therefore, the management devices can be easily implanted in all Ethernet devices (or nodes) of an Ethernet / IP communication network, without penalizing them.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Abstract

Un dispositif de gestion (DG) équipe un organe Ethernet (O1) d'un réseau de communication (RC) de type Ethernet/IP et structuré en couches du modèle TCP/IP. Ce dispositif (DG) utilise dans la couche d'application un protocole de gestion pour transmettre à la couche de transport de l'organe Ethernet (O1) une trame de données de gestion comprenant un message généré par un service assuré par l'organe Ethernet (O1) et destiné à un autre organe Ethernet (O2), ayant un type et précédé par un entête comprenant des premier, deuxième et troisième champs identifiant respectivement ce service, ce type et la longueur de la trame de données de gestion, et pour transmettre à un service de la couche d'application de l'organe Ethernet (O1) un message généré par un autre organe Ethernet (O3), ayant un type et précédé par un deuxième champ identifiant ce type.

Description

DISPOSITIF DE GESTION POUR GÉRER UN RÉSEAU ETHERNET/IP VIA UN ORGANE ETHERNET
L'invention concerne les réseaux de communication de type Ethernet/1 P (« Internet Protocol ») et structurés en couches du modèle TCP/IP (« Transport Control Protocol / Internet Protocol »), et plus précisément la gestion de tels réseaux via des organes (ou nœuds) Ethernet qu'ils comprennent.
Comme le sait l'homme de l'art, la structure en couches du modèle TCP/IP comprend une première couche d'accès au réseau utilisant le protocole MAC 802.3, une deuxième couche de réseau utilisant les protocoles IP, ARP, ICMP et IGMP, une troisième couche de transport utilisant les protocoles TCP et UDP (« User Datagram Protocol »), et une quatrième couche d'application permettant à des services assurés par les organes (ou nœuds) Ethernet d'accéder à leur réseau de communication.
Les protocoles utilisés dans la couche d'application dépendent essentiellement des services qui sont offerts par les organes (ou nœuds) Ethernet. A titre d'exemples un service audio et/ou vidéo peut nécessiter un protocole de la famille RTP ou un protocole tel que AVB ou TSN, un service d'interface homme/machine (ou IHM) et un service de commande de contrôle peuvent nécessiter un protocole tel que HTTP (HTML5) ou MQTT ou encore SOME/IP, un service de synchronisation peut nécessiter un protocole tel que NTP ou PTP ou encore 802.1 AS, un service de connexion peut nécessiter un protocole tel que Telnet ou SSH, un service de transfert de fichier peut nécessiter un protocole tel que FTP ou TFTP, un service de messagerie peut nécessiter un protocole tel que IMAP ou POP3 ou encore SMTP, et un service système peut nécessiter un protocole tel que DNS ou DHCP ou SNMP ou encore DolP.
Dans certains systèmes comprenant un réseau (de communication) Ethernet/IP, comme par exemple certains véhicules, des services ont besoin de réaliser certaines fonctions de gestion, comme par exemple piloter les différentes phases de vie du réseau, superviser les organes (ou nœuds) Ethernet pour déterminer leur état de connexion au réseau, tester les différents protocoles utilisés dans la pile de protocoles du modèle TCP/IP, et réaliser des services fonctionnels génériques (comme par exemple assurer une passerelle de message entre différentes technologies réseau).
Pour réaliser toutes ces fonctions de gestion, il faudrait implémenter un même protocole de gestion dans tous les organes (ou nœuds) Ethernet du réseau. A cet effet, on pourrait utiliser le protocole SOME/IP ou le protocole MQTT de la couche d'application. Mais ces protocoles ne sont pas implémentés de façon systématique dans tous les organes (ou nœuds) Ethernet car ces derniers n'ont pas les mêmes besoins fonctionnels du fait de leur importante diversité, notamment en matière de services assurés. De plus, ces protocoles sont difficilement implémentables dans tous les organes (ou nœuds) Ethernet car leurs poids (en termes d'octets de leurs trames de données) et complexité sont élevés du fait du nombre élevé de fonctions qu'ils gèrent.
L'invention a donc notamment pour but d'améliorer la situation.
Elle propose notamment à cet effet un dispositif de gestion destiné à équiper un organe Ethernet devant être couplé à un réseau de communication de type Ethernet/1 P, adapté à la transmission bidirectionnelle de trames de données entre des organes Ethernet et structuré en couches d'un modèle TCP/IP, parmi lesquelles une couche de transport et une couche d'application placée au-dessus de la couche de transport et permettant à des services assurés par les organes Ethernet d'accéder au réseau de communication.
Ce dispositif de gestion se caractérise par le fait qu'il utilise dans la couche d'application un protocole de gestion pour :
- transmettre à la couche de transport de son organe Ethernet une trame de données dite de gestion et comprenant un message ayant été généré par un service assuré par cet organe Ethernet et destiné à au moins un autre organe Ethernet, ayant un type et précédé par un entête comprenant des premier, deuxième et troisième champs identifiant respectivement ce service, ce type et une longueur de la trame de données de gestion, et - transmettre à un service de la couche d'application de son organe Ethernet un message ayant été généré par un autre organe Ethernet, ayant un type et précédé par un deuxième champ identifiant ce type.
Grâce à l'invention, chaque fonction de gestion du réseau peut désormais être gérée par chacun des organes (ou nœuds) Ethernet, et peut même être répartie entre plusieurs organes Ethernet.
Le dispositif de gestion selon l'invention peut comporter d'autres caractéristiques qui peuvent être prises séparément ou en combinaison, et notamment :
- il peut utiliser dans la couche d'application le protocole de gestion pour transmettre à la couche de transport de son organe Ethernet une trame concatanée comportant au moins deux trames de données de gestion comprenant chacune un message ayant été généré par un service assuré par son organe Ethernet, destinées à au moins un même autre organe Ethernet, placées l'une après l'autre, et encapsulées entre un entête UDP d'un protocole UDP de la couche de transport et un champ de somme de contrôle d'une couche d'accès au réseau du modèle TCP/IP ;
- le premier champ du protocole de gestion peut, par exemple, comprendre deux octets ;
- le troisième champ du protocole de gestion peut, par exemple, comprendre deux octets ;
- le troisième champ du protocole de gestion peut, par exemple, comprendre un nombre d'octets compris entre trois et cinq ;
- chaque service peut, par exemple, être choisi parmi un pilotage de phase(s) de vie du réseau de communication, une supervision d'au moins un organe Ethernet pour déterminer un état de connexion au réseau de communication, un test d'au moins un protocole utilisé dans une pile de protocoles du modèle TCP/IP, et une réalisation d'au moins un service fonctionnel générique.
L'invention propose également un organe Ethernet, d'une part, destiné à être couplé à un réseau de communication de type Ethernet/1 P, adapté à la transmission bidirectionnelle de trames de données entre des organes Ethernet et structuré en couches d'un modèle TCP/IP, et, d'autre part, comprenant un dispositif de gestion du type de celui présenté ci-avant.
L'invention propose également un réseau de communication de type Ethernet/1 P, structuré en couches d'un modèle TCP/IP, et comprenant au moins deux organes Ethernet du type de celui présenté ci-avant et propres à s'échanger des trames de données de façon bidirectionnelle.
L'invention propose également un véhicule, éventuellement de type automobile, et comprenant au moins un réseau de communication du type de celui présenté ci-avant.
D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés, sur lesquels :
- la figure 1 illustre schématiquement et fonctionnellement un véhicule comprenant un exemple de réseau de communication Ethernet/IP comprenant quatre organes (ou nœuds) Ethernet équipés chacun d'un dispositif de gestion selon l'invention,
- la figure 2 illustre de façon schématique une trame de données de gestion conforme au protocole de gestion de l'invention, et
- la figure 3 illustre de façon schématique un exemple de trame concaténée comprenant trois trames de données de gestion conformes au protocole de gestion de l'invention et encapsulées.
L'invention a notamment pour but de proposer un dispositif de gestion DG destiné à équiper un organe Ethernet Oj devant être couplé à un réseau de communication RC de type Ethernet/IP et structuré en couches du modèle TCP/IP.
Il est rappelé que la structure en couches du modèle TCP/IP comprend une première couche d'accès au réseau utilisant le protocole MAC 802.3, une deuxième couche de réseau utilisant les protocoles IP, ARP, ICMP et IGMP, une troisième couche de transport utilisant les protocoles TCP et UDP (User Datagram Protocol), et une quatrième couche d'application permettant à des services assurés par les organes (ou nœuds) Ethernet Oj d'accéder au réseau de communication RC. Les protocoles utilisés dans cette couche d'application dépendent essentiellement des services qui sont offerts par les organes (ou nœuds) Ethernet Oj.
Dans ce qui suit, on considère, à titre d'exemple non limitatif, que le réseau de communication RC est destiné à être installé dans un véhicule V automobile, comme par exemple une voiture. Mais l'invention n'est pas limitée à cette application. Elle concerne en effet tout système, installation ou appareil pouvant comprendre au moins un réseau de communication Ethernet/1 P adapté à la transmission bidirectionnelle de trames de données entre des organes (ou nœuds) Ethernet. Elle concerne donc notamment les véhicules, qu'ils soient de type terrestre, maritime (ou fluvial), ou aérien, les installations, éventuellement de type industriel, et les bâtiments.
On a schématiquement représenté sur la figure 1 un exemple non limitatif de réseau (de communication) RC de type Ethernet/IP. Dans cet exemple, le réseau RC comprend un bus auquel sont connectés quatre organes (ou nœuds) Ethernet 01 à 04 (j = 1 à 4). Mais le nombre d'organes Ethernet Oj peut prendre n'importe quelle valeur supérieure ou égale à deux (2).
Les organes (ou nœuds) Ethernet Oj peuvent être de tout type. Par exemple, dans le cas d'une voiture il peut s'agir d'un calculateur (éventuellement multimédia), d'une antenne intelligente d'un module d'info- divertissement, d'un dispositif de fusion d'images acquises, ou d'un écran.
L'invention propose d'équiper chaque organe (ou nœud) Ethernet Oj du réseau RC d'un dispositif de gestion DG utilisant dans la couche d'application un nouveau protocole de gestion permettant l'émission et la réception de trames Ethernet/IP utilisées (ou générées) par n'importe lequel des services assurés par les différents organes (ou nœuds) Ethernet Oj. Ces émissions et réceptions sont destinées à permettre la réalisation de certaines fonctions de gestion du réseau RC, comme par exemple le pilotage des différentes phases de vie du réseau RC, la supervision des organes (ou nœuds) Ethernet Oj pour déterminer leur état de connexion au réseau RC, le test des différents protocoles utilisés dans la pile de protocoles du modèle TCP/IP, et la réalisation de services fonctionnels génériques (comme par exemple assurer une passerelle de message entre différentes technologies réseau).
Plus précisément, le dispositif de gestion DG d'un organe Ethernet Oj utilise le nouveau protocole de gestion pour transmettre à la couche de transport de cet organe Ethernet Oj, sur un port de gestion dédié, une trame de données dite de gestion tg. Cette dernière (tg) comprend, comme illustré sur la figure 2, un message (ou « payload » - données utiles) qui a été généré par un service assuré par cet organe Ethernet Oj et qui est destiné à au moins un autre organe Ethernet Oj' (j'≠ j), ayant un type et précédé par un entête etg comprenant des premier C1 , deuxième C2 et troisième C3 champs identifiant respectivement ce service, ce type et la longueur de la trame de données de gestion tg.
On comprendra que le dispositif de gestion DG reçoit du service de son organe Ethernet Oj le message et le type de ce message, et génère la trame de données de gestion tg en adjoignant à ce message un entête comprenant le premier champ C1 identifiant ce service, le deuxième champ C2 identifiant le type du message, et le troisième champ C3 définissant la longueur de la trame de données de gestion tg.
De plus, le dispositif de gestion DG d'un organe Ethernet Oj utilise également le nouveau protocole de gestion pour transmettre à un service de la couche d'application de cet organe Ethernet Oj un message (ou payload) qui a été généré par un autre organe Ethernet Oj' (j'≠ j), ayant un type et précédé par un deuxième champ C2 identifiant ce type.
On comprendra que cette transmission se fait après extraction par le dispositif de gestion DG dans une trame de données de gestion tg, reçue d'un autre organe Ethernet Oj' et communiqué par la couche de transport via le port de gestion dédié, de son message et du deuxième champ C2 de son entête etg, et détermination du service destinataire de ce message et identifié par le premier champ C1 de son entête etg.
Ainsi, chacune des fonctions de gestion du réseau RC précitées peut être gérée par chacun des organes (ou nœuds) Ethernet Oj, ou peut être répartie entre plusieurs organes Ethernet Oj.
On notera que le dispositif de gestion DG peut également utiliser dans la couche d'application le protocole de gestion pour transmettre à la couche de transport de son organe Ethernet Oj, via le port de gestion dédié, une trame concatanée te. Cette dernière (te), qui est générée par le dispositif de gestion DG, comprend, comme illustré sur la figure 3, au moins deux trames de données de gestion tgk comprenant chacune un message généré par un service assuré par l'organe Ethernet Oj, destinées à au moins un même autre organe Ethernet Oj' (j' ≠ j), placées l'une après l'autre, et encapsulées entre un entête UDP du protocole UDP de la couche de transport et un champ de somme de contrôle CRCMAC de la première couche d'accès au réseau du modèle TCP/IP.
Il est rappelé que le champ de somme de contrôle (CRC ou « CHECKSUM ») est destiné à permettre à un organe Ethernet de vérifier que la trame qu'il a reçue n'a pas été altérée au cours de la transmission.
Dans l'exemple illustré non limitativement sur la figure 3, la trame concatanée te comprend trois trames de données de gestion tg1 à tg3 (k = 1 à 3). Mais elle pourrait comprendre n'importe quel nombre de trames de données de gestion tgk, dès lors que ce nombre est supérieur ou égal à deux (2).
Par exemple, le premier champ C1 du protocole de gestion peut comprendre deux octets (ou « bytes »). Mais il pourrait comprendre un seul octet ou bien trois octets. Ce nombre d'octets est fonction du nombre de services assurés par les différents organes (ou nœuds) Ethernet Oj du réseau RC.
Egalement par exemple, le deuxième champ C2 du protocole de gestion peut comprendre deux octets (ou bytes). Mais il pourrait comprendre un seul octet ou bien trois octets. Ce nombre d'octets est fonction du nombre de types de message utilisés par les services assurés par les différents organes (ou nœuds) Ethernet Oj du réseau RC, pour réaliser les différentes fonctions de gestion du réseau RC.
On comprendra que le service désigne ici une fonction de gestion du réseau RC. Par conséquent, un service peut, par exemple, être choisi parmi le pilotage de phase(s) de vie du réseau de communication RC, la supervision d'au moins un organe Ethernet Oj, Oj' pour déterminer un état de connexion au réseau de communication RC, le test d'au moins un protocole utilisé dans une pile de protocoles du modèle TCP/IP, et la réalisation d'au moins un service fonctionnel générique (comme par exemple assurer une passerelle de message entre différentes technologies réseau).
Le type d'un message caractérise un message dans un service. Par exemple, on peut avoir une trame de réveil pour le service de pilotage des phases de vie du réseau de communication RC, ou une trame de configuration pour effectuer un test pour le service de testabilité de protocole(s).
Egalement par exemple, le troisième champ C3 du protocole de gestion peut comprendre un nombre d'octets compris entre trois et cinq. Par exemple ce nombre d'octets peut être égal à quatre (4). Ce nombre d'octets est fonction de la longueur maximale que peut présenter une trame de données de gestion tg (entête etg + message) générée par un dispositif de gestion DG.
On notera que le port de gestion dédié peut, par exemple, être à l'adresse 1 120 (en décimal).
On notera également que le dispositif de gestion DG peut être implanté au niveau du logiciel applicatif d'un organe Ethernet Oj. Par conséquent, il (DG) peut, par exemple, être réalisé sous la forme d'une combinaison de modules logiciels (ou « software »).
L'invention requiert l'utilisation d'une faible quantité de ressources de calcul (ou CPU) et d'une mémoire réduite. Par conséquent, les dispositifs de gestion peuvent être facilement implantés dans tous les organes (ou nœuds) Ethernet d'un réseau de communication Ethernet/IP, sans que cela les pénalise.

Claims

REVENDICATIONS
1 . Dispositif de gestion (DG) pour un organe Ethernet (Oj) destiné à être couplé à un réseau de communication (RC) de type Ethernet/IP, adapté à la transmission bidirectionnelle de trames de données entre des organes Ethernet (Oj, Oj') et structuré en couches d'un modèle TCP/IP (Transport Control Protocol / Internet Protocol), parmi lesquelles une couche de transport et une couche d'application placée au-dessus de ladite couche de transport et permettant à des services assurés par lesdits organes Ethernet (Oj, Oj') d'accéder audit réseau de communication (RC), caractérisé en ce qu'il utilise dans ladite couche d'application un protocole de gestion pour transmettre à ladite couche de transport dudit organe Ethernet (Oj) une trame de données dite de gestion et comprenant un message ayant été généré par un service assuré par ledit organe Ethernet (Oj) et destiné à au moins un autre organe Ethernet (Oj'), ayant un type et précédé par un entête comprenant des premier, deuxième et troisième champs identifiant respectivement ledit service, ledit type et une longueur de ladite trame de données de gestion, et pour transmettre à un service de la couche d'application dudit organe Ethernet (Oj) un message ayant été généré par un autre organe Ethernet (Oj'), ayant un type et précédé par un deuxième champ identifiant ce type.
2. Dispositif selon la revendication 1 , caractérisé en ce qu'il utilise dans ladite couche d'application ledit protocole de gestion pour transmettre à ladite couche de transport dudit organe Ethernet (Oj) une trame concatanée comportant au moins deux trames de données de gestion comprenant chacune un message ayant été généré par un service assuré par ledit organe Ethernet (Oj), destinées à au moins un même autre organe Ethernet (Oj'), placées l'une après l'autre, et encapsulées entre un entête UDP (User Datagram Protocol) d'un protocole UDP de ladite couche de transport et un champ de somme de contrôle d'une couche d'accès au réseau dudit modèle TCP/IP.
3. Dispositif selon la revendication 1 ou 2, caractérisé en ce que ledit premier champ du protocole de gestion comprend deux octets.
4. Dispositif selon l'une des revendications 1 à 3, caractérisé en ce que ledit troisième champ du protocole de gestion comprend deux octets.
5. Dispositif selon l'une des revendications 1 à 4, caractérisé en ce que ledit troisième champ du protocole de gestion comprend un nombre d'octets compris entre trois et cinq.
6. Dispositif selon l'une des revendications 1 à 5, caractérisé en ce que chaque service est choisi parmi un pilotage de phase(s) de vie dudit réseau de communication (RC), une supervision d'au moins un organe Ethernet (Oj, Oj') pour déterminer un état de connexion audit réseau de communication (RC), un test d'au moins un protocole utilisé dans une pile de protocoles dudit modèle TCP/IP, et une réalisation d'au moins un service fonctionnel générique.
7. Organe Ethernet (Oj, Oj') destiné à être couplé à un réseau de communication (RC) de type Ethernet/IP, adapté à la transmission bidirectionnelle de trames de données entre des organes Ethernet (Oj, Oj') et structuré en couches d'un modèle TCP/IP (Transport Control Protocol / Internet Protocol), caractérisé en ce qu'il comprend un dispositif de gestion (DG) selon l'une des revendications précédentes.
8. Réseau de communication (RC) de type Ethernet/IP et structuré en couches d'un modèle TCP/IP (Transport Control Protocol / Internet Protocol), caractérisé en ce qu'il comprend au moins deux organes Ethernet (Oj, Oj') selon la revendication 7 et propres à s'échanger des trames de données de façon bidirectionnelle.
9. Véhicule (V), caractérisé en ce qu'il comprend au moins un réseau de communication (RC) selon la revendication 8.
10. Véhicule selon la revendication 9, caractérisé en ce qu'il est de type automobile.
EP18715231.9A 2017-04-04 2018-03-23 Dispositif de gestion pour gérer un réseau ethernet/ip via un organe ethernet Pending EP3607730A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1752909A FR3064866B1 (fr) 2017-04-04 2017-04-04 Dispositif de gestion pour gerer un reseau ethernet/ip via un organe ethernet
PCT/FR2018/050717 WO2018185396A1 (fr) 2017-04-04 2018-03-23 Dispositif de gestion pour gérer un réseau ethernet/ip via un organe ethernet

Publications (1)

Publication Number Publication Date
EP3607730A1 true EP3607730A1 (fr) 2020-02-12

Family

ID=59297010

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18715231.9A Pending EP3607730A1 (fr) 2017-04-04 2018-03-23 Dispositif de gestion pour gérer un réseau ethernet/ip via un organe ethernet

Country Status (4)

Country Link
EP (1) EP3607730A1 (fr)
CN (1) CN110495156B (fr)
FR (1) FR3064866B1 (fr)
WO (1) WO2018185396A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113760799B (zh) * 2020-06-03 2024-04-09 中车株洲电力机车研究所有限公司 Upp接口的可扩展通信方法、装置、计算机设备和存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1816038A (zh) * 2005-01-31 2006-08-09 西门子（中国）有限公司 一种在媒体接入控制层标识业务类型的方法
DE102006057133B4 (de) * 2006-12-01 2008-08-07 Phoenix Contact Gmbh & Co. Kg Verfahren zum Betreiben eines ethernetfähigen Feldbusgerätes
DE102007006614A1 (de) * 2007-02-06 2008-08-07 Daimler Ag Anwendung einer verteilten Diagnosearchitektur in AUTOSAR
CN100466554C (zh) * 2007-02-08 2009-03-04 华为技术有限公司 通信适配层系统及获取网元信息的方法
JP2012165033A (ja) * 2009-06-12 2012-08-30 Renesas Electronics Corp 自動車用制御システム及び電子制御ユニット

Also Published As

Publication number Publication date
FR3064866B1 (fr) 2020-08-14
WO2018185396A1 (fr) 2018-10-11
CN110495156B (zh) 2022-04-29
FR3064866A1 (fr) 2018-10-05
CN110495156A (zh) 2019-11-22

Similar Documents

Publication Publication Date Title
CA2698324C (fr) Dispositif de commutation de trames
EP3476096B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
US20070133520A1 (en) Dynamically adapting peer groups
FR2930100A1 (fr) Procede d'etablissement d'un chemin de communication dans un reseau etendu de communication, tetes de tunnel,produit programme d'ordinateur et moyen de stockage correspondants
WO2016001543A1 (fr) Procede de communication tcp via des chemins multiples entre deux terminaux
CA3087762A1 (fr) Procede de configuration d'un systeme d'extension de couverture de communication sans-fil et un systeme d'extension de couverture de communication sans-fil mettant en oeuvre ledit procede
EP3991391A1 (fr) Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé
FR2925808A1 (fr) Procede de communication dans un reseau comprenant un reseau primaire et un reseau secondaire
CA3181810A1 (fr) Procede pour fournir des services dns de multidiffusion a travers des frontieres de sous-reseaux ip
FR3071118A1 (fr) Dispositif electronique et procede de reception de donnees via un reseau de communication rebonde, systeme de communication et programme d'ordinateur associes
EP3682600B1 (fr) Gestion de la connexion avec d'autres passerelles residentielles d'une passerelle residentielle mettant en oeuvre l'agregation de liens
FR3042081A1 (fr) "procede de controle d'un systeme de communications de donnees par paquets et systeme de communications mettant en œuvre le procede"
EP3619908B1 (fr) Technique d'exécution d'un service dans un réseau local à travers un réseau de communication étendu
EP3607730A1 (fr) Dispositif de gestion pour gérer un réseau ethernet/ip via un organe ethernet
EP3682601B1 (fr) Routage de données dans une passerelle résidentielle mettant en oeuvre l'agrégation de liens
EP3329702B1 (fr) Procede de decouverte d'un noeud d'un reseau ad hoc
EP3373558B1 (fr) Procédé de communication pour assurer le maintien d'une session applicative entre un terminal et un serveur d'application
EP3122005B1 (fr) Système de routage permettant le filtrage de données pour l'intégration et le test d'équipements opérationnels
EP3637645B1 (fr) Dispositif électronique et procédé de réception de données via un réseau de communication redondé, système de communication et programme d'ordinateur associés
EP2579545B1 (fr) Méthode d'attribution d'une adresse réseau publique à un équipement disposant d'une adresse réseau privée
EP2153593A2 (fr) Procédé de transmission de paquets de données
EP1432210A1 (fr) Dispositif de contrôle de traitements associés a des flux au sein d'un reseau de communications
EP1432213B1 (fr) Plate-forme de médiation et réseau de transport de messages
FR3034272A1 (fr) Reseau de communication et nœud de communication d'un reseau de communication
EP4024820A1 (fr) Procédé de configuration d'une interface sécurisée entre un réseau de transport et un réseau élémentaire d'une pluralité de réseaux élémentaires fédérés à travers le réseau de transport; interface associée

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20191016

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: PSA AUTOMOBILES SA

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20220517

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: STELLANTIS AUTO SAS