EP3518480A1 - Procédé de communication de données dans un dispositif de réseau à base d'ethernet, en particulier industriel, destiné à la mise en uvre dudit procédé ainsi que programme informatique et support lisible par ordinateur - Google Patents

Procédé de communication de données dans un dispositif de réseau à base d'ethernet, en particulier industriel, destiné à la mise en uvre dudit procédé ainsi que programme informatique et support lisible par ordinateur Download PDF

Info

Publication number
EP3518480A1
EP3518480A1 EP18153182.3A EP18153182A EP3518480A1 EP 3518480 A1 EP3518480 A1 EP 3518480A1 EP 18153182 A EP18153182 A EP 18153182A EP 3518480 A1 EP3518480 A1 EP 3518480A1
Authority
EP
European Patent Office
Prior art keywords
stream
initiator
data
controller
port
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.)
Withdrawn
Application number
EP18153182.3A
Other languages
German (de)
English (en)
Inventor
Thomas Fischer
Stephan Höme
Konstantin Jung
Sven Kerschbaum
Marcel Kiessling
Frank Volkmann
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.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Priority to EP18153182.3A priority Critical patent/EP3518480A1/fr
Priority to PCT/EP2019/051503 priority patent/WO2019145297A1/fr
Publication of EP3518480A1 publication Critical patent/EP3518480A1/fr
Withdrawn legal-status Critical Current

Links

Images

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
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/72Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]

Definitions

  • the invention relates to a method for data communication in an Ethernet-based, in particular industrial network. Moreover, the invention relates to a device for carrying out the method. Finally, the invention relates to a computer program and a computer-readable medium.
  • a new type of traffic was defined, the so-called streams.
  • a prior art stream according to these standards provides a protected unidirectional communications link from a device called a talker, forming a data source, to one or more devices also called listeners that represent data sinks, ie, receivers a reservation is made by a so-called Stream Reservation Protocol (SRP).
  • SRP Stream Reservation Protocol
  • Each stream needs its own address to control the forwarding.
  • the address is also called Stream-DA, where DA stands for Destination Address.
  • TSN Time-Sensitive Networking
  • PROFINET RT uses bidirectional connections for communication and is based on standard Ethernet (PROFINET RT) or uses proprietary extensions (PROFINET IRT).
  • the addresses and the resources needed to manage streams are usually limited in a network.
  • the maximum number of streams is heavily hardware-dependent, especially in the range of 100 to 10,000 in the entire network. Streams are therefore a very valuable network resource, and as the number of streams increases, the overhead and resources required for each network component involved increase, in particular the nodes, such as bridges of the network.
  • the object of the present invention is to provide opportunities to create data exchange between participants of a particular industrial Ethernet-based network with comparatively little effort with efficient use of existing resources.
  • This object is achieved by a method for data communication in an Ethernet-based, in particular industrial network with one or more nodes, wherein at a node based on a reservation for a stream in the direction of a stream participant, a reservation for a stream towards a stream initiator is made.
  • the basic idea of the present invention is to introduce a new stream, with which in Deviation from the previous standards, according to which streams allow only a unidirectional data transfer, a data exchange between two communication partners takes place in both directions.
  • an extended stream reservation is performed. Specifically, in addition to the reservation at the node (s) located on the network path between the two communication partners, in addition to the reservation, only a reservation is made to the port in the direction of the stream subscriber at the port in the direction of the stream participant. Initiator, that is performed for the according to the previously known standards not provided "return direction" or the "return channel".
  • the stream participants are spoken by a data-transmitting talker and a (or more) data-receiving listener (s), since these standards only provide unidirectional streams, and thus the talker and the listener (s) are established.
  • the present invention unlike the prior art, provides bidirectional streams which allow data exchange between two subscribers in both directions, ie each of the two communication partners is both a talker and a listener, the use of the usual terms talker and listener is deliberately avoided and instead talked about a stream initiator and a stream participant.
  • the stream initiator has in common with the classical talker according to the prior art that he / she offers / initiated the stream.
  • the stream participant has in common with the classic listener because he logs on to an offered / initiated stream. It is true that the stream participant according to the invention not only receives data, so not only “listen” (listen) but also sends data, so “speaks” (talk), whereby data sent by him again received by the stream initiator ( listen).
  • the input / output, in particular sensor / actuator, data in an industrial network generally have the same traffic characteristics (for example, the size of the data frame, the transmission cycle), as in the case of cyclical transmission with Profinet IO. If this is the case, the traffic characteristic specified by the stream initiator can also be used for the inventively provided "return direction" from the stream subscriber to the stream initiator. Of course, it is also possible that a different traffic characteristic is used / reserved for the return direction.
  • the receive port and the transmit port of the bridge or bridges are internally maintained as status. Due to the expansion according to the invention, the resources can be tested with little effort on both ports, ie the respective receive and transmit ports, and the forwarding can be for the common address at both ports of the node (s) between the two communication partners, ie between the stream initiator and the stream participant, if there are enough resources.
  • the same forwarding address is used as for the direction from the stream initiator to the stream subscriber.
  • the receive port When forwarding Ethernet frames, the receive port is hidden during forwarding according to IEEE 802.1Q. This allows the forwarding of the data in one direction in a bidirectional connection according to the invention, if both ports are entered for forwarding in the Filtering Database (FDB) of the node according to IEEE 802.1 Q. Both subscribers are then senders and receivers of the bidirectional stream at the same time. If the data exchange according to the invention takes place via a new bidirectional stream between exactly two communication partners, it is particularly ensured that the "backfeed protection" takes effect.
  • FDB Filtering Database
  • the inventive method for the industrial environment is particularly suitable.
  • Another advantage of the procedure according to the invention is that since the reservation is made for both directions, as is necessary, for example, in the exchange of data between the controller and an I / O device, a complex query of two reservations and their reservation status is not required. Rather, the bidirectional reservation according to the invention can save addresses and reservation entries, and can double the number of connections in an existing network with a given hardware configuration.
  • the stream description is within the scope of
  • the method according to the invention is also particularly simple, since in this case only one entry is required for the description of the data, in particular only one Tspec (English: Traffic Specification), which additionally reduces the management information.
  • a bidirectional stream may be established between a programmable controller and a plurality of devices, each of which is to receive both these transmissions and data therefrom.
  • an extended Stream Reservation Protocol is used, which preferably an additional reservation of the initiator port of the node or the nodes on the network path between the stream initiator and the stream subscriber on the same forwarding Address as the reservation of the subscriber port of the node or nodes allows.
  • the extended stream reservation protocol is, in particular, one that corresponds essentially to the stream reservation protocols of the known standards, in particular AVB or TSN, but to the reservation of the port in the direction of the stream initiator, that is to say Initiator ports of the node or nodes on the network path is extended.
  • an extended stream reservation protocol which can be used in the context of the method according to the invention, is characterized by the following properties.
  • the Traffic Specification can be extended by an optional parameter that indicates whether the return direction from the stream user to the stream initiator should also be reserved under the same stream ID.
  • the stream initiator which may be given by a controller or a PLC, for example, can then set up the corresponding bidirectional streams in the system power-up using the new optional parameter in the TSpec.
  • the stream participant (s) present in the form of sensors / actuators then use the stream. This is possible in particular because the controller has all relevant information about the connected sensors / actuators from the engineering (offline).
  • the node or the nodes on the network path between the stream initiator and the stream participant both at the respective initiator and the respective subscriber port whether sufficient resources for the bidirectional stream are available .
  • a further advantageous embodiment is characterized in that the stream initiator also specifies a bandwidth for the return channel, ie the data transfer from the stream subscriber to it in the context of the stream description, in addition to the bandwidth for an outgoing data transfer.
  • a bandwidth for the return channel ie the data transfer from the stream subscriber to it in the context of the stream description, in addition to the bandwidth for an outgoing data transfer.
  • the description of the stream by the stream initiator comprises at least one Traffic Specification (Tspec) parameter.
  • Tspec Traffic Specification
  • the method according to the invention is furthermore carried out in particular in an Ethernet-based network with P2P links without hubs and without a shared medium.
  • the method according to the invention has proven particularly suitable for data exchange in the industrial environment, for example for components of industrial automation systems or the like.
  • a further advantageous embodiment may accordingly be distinguished by the fact that the stream initiator is a controller, in particular a programmable logic controller, preferably a control system for a technical process or a vehicle, and the stream user is a O device, preferably of the control system, which comprises a sensor and an actuator or is connected to a sensor and an actuator, or to another controller, in particular a further programmable logic controller, preferably the control system acts.
  • the stream initiator is a controller, in particular a programmable logic controller, preferably a control system for a technical process or a vehicle
  • the stream user is a O device, preferably of the control system, which comprises a sensor and an actuator or is connected to a sensor and an actuator, or to another controller, in particular a further programmable logic controller, preferably the control system acts.
  • the I / O device the stream initiator and the controller is the stream participant is
  • the stream initiator and the stream participant are given by corresponding components, it is further preferred to control an industrial technical process or a vehicle on the basis of data exchanged between them via the bidirectional stream in both directions.
  • a computer program or a collection of computer programs is used, the or the program code means for performing all steps of the method according to the invention comprises.
  • a corresponding program or a corresponding program collection can be stored, for example, on one or more storage media of a device according to the invention.
  • FIG. 1 shows a purely schematic partial representation of a device according to the invention for carrying out an embodiment of the control method according to the invention for an industrial process, not shown in the FIG, for example, a production machine or a chemical process.
  • the device comprises a central unit, which in the present case is provided by a controller, specifically a programmable logic controller (PLC) 1 and a plurality of peripheral devices, specifically sensors 2, actuators 3 and peripheral devices 4, which include or include both a sensor and an actuator these are connected.
  • a controller specifically a programmable logic controller (PLC) 1
  • PLC programmable logic controller
  • peripheral devices specifically sensors 2, actuators 3 and peripheral devices 4, which include or include both a sensor and an actuator these are connected.
  • PLC programmable logic controller
  • Ethernet-based network with a multiplicity of nodes, which in the illustrated embodiment are in each case given by a bridge 5.
  • the Ethernet-based network is one with P2P links (no hubs, no shared medium).
  • the Ethernet-based network with the plurality of bridges 5 in the illustrated embodiment is characterized by a line topology.
  • a line topology such as a tree, star or ring topology.
  • detect sensors 2, 4 in well-known from the prior art cyclically actual states of the technical process, which may be about position or temperature signals, it being emphasized that this is purely exemplary to understand and monitoring other parameters is equally possible.
  • the actual states are transmitted from the sensors 2, 4 via the Ethernet-based network to the PLC 1.
  • the SPS 1 determined in well-known from the prior art, based on the transmitted actual conditions and possibly other parameters control signals, which in turn are transmitted to actuators 3, 4 of the system, so that are acted upon taking into account the detected actual conditions on the technical process can, as also well known.
  • control signals which may be, for example, an actuation of a servomotor, such as a valve above an on or off or throttling or increasing a heater, are also via the Ethernet-based network of the PLC. 1 transmitted to the actuators 3, 4.
  • control signals are to be understood as purely exemplary and - in particular depending on the type of actuators 3, 4 - any other control signals can alternatively or additionally be determined and transmitted to the actuators 3, 4 via the network.
  • the totality of all actual states forms the so-called process image of the inputs and all the control signals the so-called process image of the outputs.
  • the actuators 3, 4 act when they have received a control signal from the PLC 1 according to the respective signal on the industrial technical process, whereby this - as well as the data transmission - cyclically.
  • the transmission of the actual states with the sensors 2, 4 to the PLC 1 takes place according to the invention via stream.
  • the transmission of the control signals from the PLC 1 to the actuators 3, 4 takes place in this way.
  • this type of data communication known from the AVB and TSN standards, ensures that a given latency, which can vary from stream to stream, and particularly depends on the particular application, is maintained.
  • This ensures that the actual states arrive within a predetermined maximum latency time at the SPS 1, ie a maximum latency passes between the feeding of the data into the network and the receipt of the data at the SPS 1.
  • the control signals arrive at the actuators 3, 4 within a predetermined maximum latency period. For example, it is possible to ensure, in particular, real-time-critical communication between the PLC 1 and the peripheral devices 2, 3, 4.
  • a stream as defined, for example, by the Audio / Video Bridging (AVB) task group and in particular by the Time Sensitive Networking (TSN) task group in the international standard IEE802.1, is used the associated Stream Reservation Protocol (SRP) is established, but only unidirectional streams can be obtained.
  • AVB Audio / Video Bridging
  • TSN Time Sensitive Networking
  • SRP Stream Reservation Protocol
  • each stream requires its own forwarding address. Addresses and the resources needed to manage streams are severely limited in a network, especially as they are heavily hardware dependent. Streams thus represent a very valuable network resource. As the number of streams increases, the administrative overhead and the resources required for this increase in each participating network component, in particular in each bridge 5 of the network. It also increases the processing overhead, because for each stream direction messages are exchanged according to SRP (Stream Reservation Protocol) from the talker to the listener and processed in the bridges 5
  • SRP Stream Reservation Protocol
  • each of the bridges 5 the in FIG. 1 partially illustrated Ethernet-based network has four ports each. It should be noted that it is of course possible for bridges 5 to be used with a different number of ports, with the procedures described below then applying equally.
  • the stream is in a first step by the device 4, which in the case of the transmission of detected by the sensor of this device 4 actual states to the PLC 1, the according to AVB or TSN standard also referred to as Talker data source, announced and it will be the properties of the stream of the talker described.
  • the device 4 specifies a stream ID, a forwarding address, and a bandwidth information for the data transfer that it intends to make.
  • each bridge 5 carries the information of the receiving port, ie the port in the direction of the talker, via which the announcement is received and later the data will be received , Since, according to the prior art, the data source is also referred to as a talker, this port also bears the name Talkerport.
  • the Talkerport 7 is shown on the left hand side and on the right side there are two ports 8, 9, via which the information about the announced stream is passed on and listeners to can log in the stream.
  • the talker port 7, which received the stream announcement is known.
  • the direction in which the announcement is made and which later also the data are transmitted indicated by a large arrow 10 through the Talkerport 7.
  • the passing of the information through the two opposite ports 8, 9 is indicated by smaller arrows 11 through these ports 8, 9.
  • a listener in this case the SPS 1 logs on and the information about the application is about those bridges 5, which are between the talker 4 and the listener 1 to the talker, So the device 4 transmitted.
  • each node 5 checks whether its internal resources are sufficient for performance required in the context of the stream to be established (in particular with regard to data volume and data throughput). If this is the case, the node 5 reserves these resources for the stream to be established. Otherwise, a corresponding message is sent to a device establishing the stream. Through reservation, each node 5 can ensure that it ensures the required performance during the subsequent data transfer. This is different protected connections representing streams of unprotected connections.
  • a Listenerjoin and the forwarding of the offered by the device 4 actual states to the PLC 1 is activated.
  • the data forwarding is realized in a manner known per se from the AVB and TSN standard by means of a so-called stream filtering database (FDB).
  • FDB stream filtering database
  • the data transmission takes place in a likewise well-known manner in the form of individual data packets, which are also referred to as "frames".
  • the bridges 5 forward the data - while maintaining a latency - each on.
  • FIG. 3 which receives a purely schematic representation of the data plane for the situation of active forwarding, is the data passing through a large arrow 10 through the upper of the two ports 8, which is the port 8 in the direction of the device 4 of the struck bridge 5, So the listener port 8 for the device 4 is marked.
  • the resulting stream according to the previously known AVB or TSN standard allows data exchange in one direction only, however, data can always only from the device forming the talker for this stream 4 in the direction of one or more other devices, ie in the direction of the data subscribing PLC 1 and possibly in the direction of one or more other devices. If a data exchange in the direction of the device 4 is required so that, as in the present case, control signals from the PLC 1 can be transmitted to the actuator of the device 4, a second unidirectional stream must be set in the opposite direction.
  • the stream description 14 here belongs to the stream for which the peripheral device 4 represents the talker, with which thus determined actual states are to be transmitted from the peripheral device 4 to the SPS 1 and the stream description 15 is issued by the PLC 1 for the transfer of the control signals to the actuator of the peripheral device 4 together with the corresponding stream announcement.
  • the resulting statuses for the ports of the bridges 5, namely the SRP status (center) and the status after the FDB (bottom) are outlined.
  • FIG. 4 is indicated that according to the SRP the status on all four ports in the bridge 5 is known. It should be noted that each fourth port 16 of the bridge 5, which in the FIGS. 2 and 3 not shown, also shown here. With regard to the statuses, the following applies. At the in the FIG. 5 dotted Listenerports 8, the reservation was successful, at the obliquely hatched ports 9, 16, the information is passed and the hatched each with a horizontal line Talkerport 7 is known.
  • FIG. 5 a bridge 5 is shown in a highly simplified external view, above which are two opposite arrows representing the two unidirectional streams A, B in the opposite direction.
  • the present invention now provides that not two unidirectional streams with two forwarding addresses for the data transfer from the device 4 to the PLC 1 and the data transfer in the reverse direction are set up and the data forwarding via the two separate streams is activated, but a novel, bidirectional one Stream is set up by means of an extended Stream Reservation Protocol and data is forwarded in both directions via the one bidirectional stream. This happens as follows.
  • the device 4 representing the stream initiator in the context of the method according to the invention announces a stream and describes it, exactly as in the context of the known standards, wherein the device 4 receives in particular a stream ID, a forwarding address and at least one bandwidth information for the data transfer which he intends to specify.
  • the announcement and description does not differ from that which also takes place within the framework of the AVB or TSN standard (as described above).
  • a bandwidth for the "return channel" ie the data transfer from the PLC 1 to the device 4 is indicated.
  • the only one required stream description, which may include bandwidth indications for the forward and reverse directions, is in FIG. 8 in analogy to the FIG. 4 indicated by a schematically illustrated data sheet 17.
  • each bridge 5 carries the information of the receiving port, ie the port 18 in the direction of the stream initiator via which the announcement has been received.
  • the port, via which the announcement is received, is referred to herein also as initiator port 18.
  • the bridges 5 between device 4 and PLC 1 an additional check of the resources and a reservation is carried out in each case at the port 18 in the direction of the stream initiator, ie in the direction of the device 4 a data transfer in the return direction to the device 4 is possible.
  • extended Stream Reservation Protocol is used, which includes the additional reservation for the return direction.
  • the Traffic Specification (TSpec) is extended by an optional parameter indicating whether the return from the Stream Subscriber to the Stream Initiator should also be reserved under the same Stream ID.
  • the stream initiator can then set up the appropriate bidirectional streams during system bootup using the new optional parameter in the TSpec.
  • the stream participants then use the stream. This is possible in particular because the controller has all relevant information about the connected sensors / actuators from the engineering (offline).
  • the reservation is carried out at the initiator ports 18 in accordance with the differing bandwidth. If this is not the case, the reservation corresponds to that at the subscriber ports 19.
  • the Listenerjoin and the forwarding offered by the device 4 actual states to the PLC 1 and the forwarding of control signals from the PLC 1 to the actuator of the device 4 are activated. It should be noted that the data forwarding in a conventional manner by means of a so-called Stream Filtering Database (FDB) is realized.
  • FDB Stream Filtering Database
  • FIG. 7 which analogous to the FIG. 3 the data plane shows, the bidirectional data forwarding is recognizable by the fact that in addition to the arrow 10 through the subscriber port 19, an oppositely oriented arrow 21 passes through the Inititatorport 18 and both the subscriber and the Initiatorport 18 is shown hatched.
  • FIG. 7 The backfeed protection associated with Ethernet as a result of the masking of the receive port during forwarding is contained in the FIG. 7 also indicated. This accesses both the initiator 18 and the subscriber port, which in the FIG. 7 in analogy to the FIG. 3 indicated by dashed lines 12.
  • FIG. 7 When forwarding Ethernet frames according to IEEE802.1Q the receiving port, so for one direction the initiator 18 and for the other direction of the subscriber port 19, hidden.
  • the data flow taking place only in the desired direction is in the FIG. 7 also indicated by further dashed lines 23rd
  • the FIG. 8 contains - in analogy to the FIG. 4 for the previously known standards - again the statuses resulting for all ports, specifically the SRP status (middle) and the FDB (bottom). Specifically, in the middle here also indicated by points in the Initiator- 18 and the subscriber port 19 that a reservation was successful and at the obliquely hatched further ports 22, 24, the information is passed. At the data level ( FIG. 8 below), a forwarding occurs both at the initiator 18 and the subscriber port 19, which is indicated in the FIG by a letter "C" at these two ports - for the bidirectional stream C -. The other two ports 22, 24, on which no data forwarding via the bidirectional stream takes place, are in the FIG. 8 shown in white below.
  • FIG. 9 shows analogous to the FIG. 5 schematically a bridge 5, wherein a bidirectional stream C is indicated by this by a double arrow shown above.
  • bidirectional streams can be set up according to the present invention, as described above for the device 4 and the SPS 1.
  • another bidirectional stream for data exchange between the PLC 1 and the Sensor 2 and another bidirectional stream for a data exchange between the PLC 1 and the actuator 3 are set up.
  • the bidirectional streams between the PLC 1 and each of the peripheral devices 2, 3, 4 are indicated by double arrows.
  • Other bidirectional streams according to the present invention for other device pairs that need to exchange data in both directions are equally possible.
  • the procedure according to the invention makes it possible to control a technical process with significantly reduced network complexity and significantly reduced network resources for the data exchange required for the control, in particular the transmission of detected actual states and on the basis of these determined control signals.
  • the invention has been further illustrated and described in detail by the preferred embodiment, the invention is not limited by the disclosed examples, and other variations can be derived therefrom by those skilled in the art without departing from the scope of the invention.
  • either of the two partners may be the stream initiator.
  • the SPS 1 instead of the stream announcing device 4 forming the stream initiator, the SPS 1 may also represent the stream initiator and the device 4 may be the stream user who logs on to the advertised stream. Due to the bidirectionality, it makes no difference who later announces and who logs on for later data exchange.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Small-Scale Networks (AREA)
EP18153182.3A 2018-01-24 2018-01-24 Procédé de communication de données dans un dispositif de réseau à base d'ethernet, en particulier industriel, destiné à la mise en uvre dudit procédé ainsi que programme informatique et support lisible par ordinateur Withdrawn EP3518480A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP18153182.3A EP3518480A1 (fr) 2018-01-24 2018-01-24 Procédé de communication de données dans un dispositif de réseau à base d'ethernet, en particulier industriel, destiné à la mise en uvre dudit procédé ainsi que programme informatique et support lisible par ordinateur
PCT/EP2019/051503 WO2019145297A1 (fr) 2018-01-24 2019-01-22 Procédé de communication de données dans un réseau, en particulier industriel, basé ethernet dispositif pour la mise en oeuvre dudit procédé ainsi que programme informatique et support lisible par ordinateur

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP18153182.3A EP3518480A1 (fr) 2018-01-24 2018-01-24 Procédé de communication de données dans un dispositif de réseau à base d'ethernet, en particulier industriel, destiné à la mise en uvre dudit procédé ainsi que programme informatique et support lisible par ordinateur

Publications (1)

Publication Number Publication Date
EP3518480A1 true EP3518480A1 (fr) 2019-07-31

Family

ID=61156985

Family Applications (1)

Application Number Title Priority Date Filing Date
EP18153182.3A Withdrawn EP3518480A1 (fr) 2018-01-24 2018-01-24 Procédé de communication de données dans un dispositif de réseau à base d'ethernet, en particulier industriel, destiné à la mise en uvre dudit procédé ainsi que programme informatique et support lisible par ordinateur

Country Status (2)

Country Link
EP (1) EP3518480A1 (fr)
WO (1) WO2019145297A1 (fr)

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
BERGER L ET AL: "Generalized Multi-Protocol Label Switching (GMPLS) Signaling; rfc3473.txt", GENERALIZED MULTI-PROTOCOL LABEL SWITCHING (GMPLS) SIGNALING; RFC3473.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARD, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, 1 January 2003 (2003-01-01), XP015009256 *
DESIRE OULAI ET AL: "An Improved Resource Reservation Protocol", JOURNAL OF COMPUTER SCIENCE, vol. 3, no. 8, 1 August 2007 (2007-08-01), United States, pages 658 - 665, XP055488538, ISSN: 1549-3636, DOI: 10.3844/jcssp.2007.658.665 *
HYUNG-TAEK LIM ET AL: "Performance comparison of IEEE 802.1Q and IEEE 802.1 AVB in an Ethernet-based in-vehicle network", 2012 8TH INTERNATIONAL CONFERENCE ON COMPUTING TECHNOLOGY AND INFORMATION MANAGEMENT (NCM AND ICNIT), vol. 1, 1 April 2012 (2012-04-01), pages 1 - 6, XP055488522, ISBN: 978-1-4673-0893-9 *
M BHATIA ET AL: "Network Working Group Extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) for Bi-directional Label Switched Paths (LSPs) draft-bhatia-mpls-rsvp-te-bidirectional-lsp-01", 19 March 2011 (2011-03-19), XP055488530, Retrieved from the Internet <URL:https://tools.ietf.org/pdf/draft-bhatia-mpls-rsvp-te-bidirectional-lsp-01.pdf> [retrieved on 20110319] *
TIME-SENSITIVE NETWORKING TASK GROUP OF IEEE 802 1 OF THE: "Draft Standard for Local and metropolitan area networks-", vol. 802.1cc drafts; 802.1qcc drafts, no. d1.6, 18 July 2017 (2017-07-18), pages 1 - 218, XP068113856, Retrieved from the Internet <URL:grouper.ieee.org/groups/802/1/files/private/cc-drafts/d1/802-1Qcc-d1-6.pdf> [retrieved on 20170718] *

Also Published As

Publication number Publication date
WO2019145297A1 (fr) 2019-08-01

Similar Documents

Publication Publication Date Title
EP3695577B1 (fr) Procédé de communication de données dans un réseau tsn, procédé de commande et dispositif
EP2413538B1 (fr) Prévention de boucles de transmission dans un réseau en anneau redondant
EP1748338A1 (fr) Méthode d&#39;optimisation l&#39;utilisation de la largeur de bande dans des systèmes de bus
DE102014108455A1 (de) Verfahren zum Betreiben eines Netzwerks
DE102013207826B3 (de) Verfahren zum Betreiben eines Slave-Knotens eines digitalen Bussystems
EP3625627B1 (fr) Flux de sommes pour états réels et signaux de commande d&#39;un système de commande réparti
EP3618384B1 (fr) Procédé de simulation d&#39;un traitement des requêtes de réservation pour flux de données multidiffusion dans des réseaux de communication et un système de simulation
EP2847966B1 (fr) Procédé de transmission de données dans un réseau de communication orienté paquets, système correspondant et produit programme d&#39;ordinateur correspondant
EP3598719A1 (fr) Procédé de communication de données, en particulier dans un réseau industriel, procédé de commande, dispositif, programme informatique et support lisible par ordinateur
EP3226484A1 (fr) Procede destine a la transmission de donnees dans un reseau de communication d&#39;un systeme d&#39;automatisation industriel et appareil de communication
EP3518480A1 (fr) Procédé de communication de données dans un dispositif de réseau à base d&#39;ethernet, en particulier industriel, destiné à la mise en uvre dudit procédé ainsi que programme informatique et support lisible par ordinateur
DE102017130167A1 (de) Verfahren zur Optimierung der Ausfallerkennung von Redundanz-Protokollen mit Testdatenpaketen
EP3758310A1 (fr) Procédé de communication de données, dispositif de commande de réseau, réseau, programme informatique et support lisible par ordinateur
EP1453252B1 (fr) Transmission de données dans un réseau de données commutable
DE102019207579A1 (de) Verfahren und Vorrichtung zum Überwachen von Datenaustausch in einem Kommunikationssystem
EP3518470A1 (fr) Procédé de communication de données dans un dispositif de réseau à base d&#39;ethernet, en particulier industriel, destiné à la mise en uvre dudit procédé, programme informatique ainsi que support lisible par ordinateur
EP3629550A1 (fr) Procédé de transmission de données dans un réseau de communication industrielle et dispositif de communication couplée
EP3644555A1 (fr) Procédé de communication de données, en particulier dans un réseau industriel, procédé de commande, dispositif, programme informatique et support lisible par ordinateur
EP3700130A1 (fr) Procédé de transmission de données, appareil, programme informatique et support lisible par ordinateur
DE102007041621A1 (de) Verfahren und Vorrichtung zur Stabilisierung einer Datenfunkverbindung
EP3703340A1 (fr) Procédé de fonctionnement d&#39;appareils réseau dans un réseau, dispositif de calcul ainsi que réseau
EP3716550A1 (fr) Procédé de communication de données dans un réseau industriel, commande, réseau, programme informatique et support lisible par ordinateur
EP3975488A1 (fr) Procédé et appareil de communication destinés à la transmission de données temporellement critiques
EP3672163A1 (fr) Procédé de communication de données, appareil de communication, programme informatique et support lisible par ordinateur
EP1371193A2 (fr) Circuit electronique et procede pour interface de communication a memoire tampon pseudo-transit

Legal Events

Date Code Title Description
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

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

17P Request for examination filed

Effective date: 20200130

RBV Designated contracting states (corrected)

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

17Q First examination report despatched

Effective date: 20200608

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20200721