WO2011051157A1 - Verfahren und vorrichtung zur datenübertragung - Google Patents

Verfahren und vorrichtung zur datenübertragung Download PDF

Info

Publication number
WO2011051157A1
WO2011051157A1 PCT/EP2010/065861 EP2010065861W WO2011051157A1 WO 2011051157 A1 WO2011051157 A1 WO 2011051157A1 EP 2010065861 W EP2010065861 W EP 2010065861W WO 2011051157 A1 WO2011051157 A1 WO 2011051157A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
interface
transmission
segment
telegrams
Prior art date
Application number
PCT/EP2010/065861
Other languages
English (en)
French (fr)
Inventor
Harald Karl
Friedrich Lindner
Original Assignee
Siemens Aktiengesellschaft
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 Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Publication of WO2011051157A1 publication Critical patent/WO2011051157A1/de

Links

Classifications

    • 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/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/4616—LAN interconnection over a LAN backbone
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/188—Time-out mechanisms
    • 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/40006—Architecture of a communication node
    • H04L12/40032—Details regarding a bus interface enhancer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092—Error control systems characterised by the topology of the transmission link
    • H04L2001/0094—Bus
    • 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/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN

Definitions

  • CAN buses are fieldbuses that are used to network different devices with each other for data exchange. They are used particularly in safety-relevant areas, where high data security is required, for example in automotive engineering for networking different control units and sensor units in automation technology for monitoring purposes or in the Medi ⁇ zintechnik in magnetic resonance and computed tomography or heart Lung machines.
  • a CAN bus In various areas in which a CAN bus is used, for example in known computed tomography with a CAN bus, at least one other network is used in addition to the CAN bus.
  • a CAN bus is divided into at least two segments and the CAN-CAN segments of the CAN bus are connected by a determinorien ⁇ -oriented network logically together, said CAN Telegrams are transmitted by means of the network between CAN segments.
  • the transmission of CAN frames over the network is checked for freedom from errors and a erkann ⁇ ter transmission error is corrected by a signal sent from a sending CAN segment and erroneously transmitted CAN message of this CAN segment is retransmitted over the network.
  • a packet-oriented network is understood to mean a network in which data is transmitted in packets, i. in the form of individual data packets.
  • a CAN bus is thus combined with a packet-oriented network, so that the network between individual CAN segments of the CAN bus acts as a data tunnel, via which CAN telegrams are transmitted between the CAN segments.
  • the network logically connects the CAN segments to a CAN bus.
  • terminals with interfaces for a CAN bus in the individual CAN segments can advantageously be networked via the network without having to lay a physically connected CAN bus in addition to the network.
  • the effort for networking the terminals connected to the CAN bus can be considerably reduced as a result.
  • the data-locking mechanisms of a CAN bus can be largely beibehal ⁇ th characterized in the transmission of CAN messages over the network, in particular a deterministic simplifyssteue ⁇ delay for the bandwidth management, an acknowledgment of receiving a CAN message or a Log from reception erroneous and a repetition of the transmission of erroneously transmitted ⁇ CAN telegrams.
  • the method according to the invention is also suitable for safety-relevant applications in which CAN buses are usually used with preference.
  • each CAN segment is coupled to the network via an associated CAN interface in each case and the transmission of CAN telegrams from a CAN segment via the network and the receipt of CAN telegrams from the network by means of the associated CAN interface performed.
  • each CAN interface by means of which a CAN telegram is received via the network, it is checked whether the received CAN telegram has been transmitted without errors.
  • a CRC checksum is understood to be a suitable test value which is transmitted together with a data packet in order to detect transmission errors.
  • the received verification value with the transmitted check value set and closed at a Kochtra ⁇ transmission errors if the two test values from one another vary the.
  • Transmission errors during the transmission of CAN telegrams via the network are preferably recognized and corrected as follows:
  • the CAN telegram is sent to all other CAN interfaces by means of a sending CAN interface;
  • a positive acknowledgment message is sent to the transmitting CAN interface by this CAN interface via the network;
  • the CAN telegram is sent again via the network to all other CAN interfaces, if the transmitting CAN interface of at least one of the other CAN interfaces within a predetermined timeout time does not receive a positive acknowledgment message.
  • a transmitting CAN interface from a receiving CAN interface error-free transmission of a ⁇ CAN telegram is acknowledged and the transmitting CAN interface can check the accuracy of the transmission of the CAN telegram based on the acknowledgments received from it. For this purpose, it checks whether it receives a positive acknowledgment message from all other CAN interfaces. If this is the case, an error-free transmission of the CAN telegram is concluded.
  • the specification of a timeout period for waiting for Affirmation ⁇ supply objects prevents advantageous that a CAN interface waits as long as desired for a confirmation message is thus blocked, and a transmission error is not corrected.
  • a signal received from a CAN interface from the network CAN message will only be transferred by means DIE ser CAN interface to the associated CAN segment when the transmission of the CAN message is ⁇ classifies as error-free turned.
  • a CAN telegram received by a CAN interface over the network is buffered in a buffer of the CAN interface before it is forwarded from the CAN interface to the associated CAN segment.
  • a corresponding memory status message is sent by a CAN interface to all ren On the other CAN interfaces, as soon as the memory capacity of its exceeds a predeterminable first Greschwellwert intermediate ⁇ memory or below.
  • a memory status message is sent from each CAN interface cyclically in predetermined time intervals to all other CAN interfaces, a memory status message about whether a current memory usage of the insectspei ⁇ Chers the respective CAN interface threshold value exceeds a first filling.
  • the inventive device for data transmission accordingly has a CAN bus divided into at least two CAN segments and a packet-oriented network.
  • the network connects the CAN segments logically such miteinan ⁇ that that of each CAN segment, a CAN telegram can be sent by means of the network both to all other CAN segments as well as targeted to a selectable other CAN segment.
  • the device according to the invention enables the
  • the device according to the invention in each case has a CAN interface for each CAN segment for its coupling to the network and for controlling the transmission of CAN telegrams from the CAN segment over the network and the receipt of CAN telegrams from the network.
  • each CAN interface preferably has an intermediate memory for storing CAN telegrams received from the network.
  • FIG. 1 schematically shows a device for data transmission with several CAN segments of a CAN bus, which are logically connected to each other via a network,
  • FIG. 4 schematically shows a sequence of a transmission of CAN telegrams between CAN segments via a network in the event of packet loss in a block diagram
  • FIG. 5 schematically shows a sequence of a transmission of CAN messages.
  • Telegrams between CAN segments over a network in case of memory overflow in a CAN interface in a block diagram.
  • FIG. 1 schematically shows a device for data transmission with a CAN bus 1 with a plurality of CAN subscribers C1 to Cm, which is subdivided into n CAN segments 1.1 to ln.
  • the CAN segments 1.1 to ln are logically interconnected via a packet-oriented network 2 in that CAN telegrams between the CAN segments 1.1 to ln can be exchanged via the network 2.
  • the network 2 thus forms a tunnel between the CAN segments 1.1 to ln and connects them logically to the CAN bus 1.
  • the CAN participants Cl to Cm are terminals that are dependent on the respective use of the
  • CAN bus 1 Depend on CAN bus 1.
  • the entirety of the CAN users C1 to Cm and the logical CAN bus 1 connecting them is also referred to below as the CAN network.
  • Each CAN segment 1.1 to ln is coupled via a further below ⁇ be required associated therewith CAN interface 3.1 to 3.n to the network.
  • 2 CAN messages that are sent in one of the CAN segments 1.1 to ln, are ever ⁇ stays awhile CAN interface 3.1 to 3.n to the network 2 and the network 2 to each other CAN interface 3.1 to third n transfer.
  • SAR segmentation and reassembly
  • each CAN segment 1.1 to 1 in itself ensures the integrity of the transmitted data, and in the case of transmission via the packet-oriented network 2, security mechanisms described in more detail below are used. Only correctly received CAN telegrams are forwarded from a CAN segment 1.1 to ln to the network 2 or from the network 2 to a CAN segment 1.1 to ln.
  • Network 2 does not have sufficient security mechanisms. If a CAN interface 3.1 to 3.n receives a CAN telegram, it checks, if necessary, its CRC checksum and, in the case of a transmission classified as error-free, acknowledges receipt of the CAN data packet by sending a positive acknowledgment message (acknowledge packet ACK) to the transmitter of the CAN data packet, that is to the relevant ⁇ CAN interface 3.1 to 3.n, sends. In case of a In the event of a faulty transmission, the receiving CAN interface 3.1 to 3.n does not send an acknowledge packet ACK or sends a negative acknowledgment message to the sender.
  • acknowledge packet ACK positive acknowledgment message
  • the CAN interface 3.1 to 3.n of the transmitter checks currency ⁇ rend a predetermined timeout period after transmitting a CAN message, whether from all other CAN interfaces 3.1 to 3.n of CAN segments 1.1 to ln an Acknowledge Package ACK received. If after expiration of the timeout period at least one acknowledge packet ACK is missing or a negative acknowledgment ⁇ message was received, the CAN interface 3.1 to 3.n sends the transmitter the CAN message again to the other CAN segments of 1.1 to ln CAN bus 1. The number of repetitions in case of error is configurable.
  • the timeout time is adapted to the respective network 2. It is chosen to ⁇ special is that it is longer than twice the time required to transmit a data packet on the network 2 since the transmission times of a CAN data packet and the acknowledge packets ACK and an additional time reference serve to are taken into account.
  • Network stations are connected to the network 2, as a rule, are not part of the CAN network of the CAN bus ⁇ ses 1, belonging to the CAN network
  • Network subscribers have the characteristic address field eg an Ethernet multicast address or a special Ver ⁇ connection. This ensures that CAN data packets are exchanged only between the CAN segments 1.1 to ln and are not also sent to other network subscribers of the network 2.
  • CAN buses 1 can be operated on the network ⁇ unit 2 by appropriate allocation of Trim Krite ⁇ rien within the network 2, for example of addresses.
  • the network 2 is designed both multicast and unicastDedicated, ie over the network 2 data packets can be so ⁇ well sent in the form of multicast data packets to a group of network participants as well as unicast data packets targeted to each specific network participant.
  • the multicast capability makes it possible to send CAN data packets to all CAN users C1 to Cm of the logical CAN bus 1.
  • the unicast capability enables the above ⁇ be signed acknowledgment mechanism by specifically over ⁇ transmission of acknowledge packets ACK to the sender of a CAN telegram.
  • the network 2 is designed such that a time can be specified, after which a CAN data packet is usually transmitted via the network 2. This makes it possible to set the timeout for waiting for acknowledge packets ACK.
  • this time can redu ⁇ ed and thus the deterministic CAN tunneling be increased through the network. 2
  • IP Internet Protocol
  • SiDaNet so-called SiDaNet network
  • the multicast addresses of Ethernet can be used for the multicast connections.
  • Each logical CAN network has its own multicast address.
  • DHCP Dynamic Host Configuration Protocol
  • the network 2 has a multicast capability and preferably has the option that network subscribers can register at the network node for specific multicast addresses. If the network 2 does not have this option, multi ⁇ cast addresses are treated as broadcast addresses and delivered to each network subscriber.
  • a logical multicast data packet can also be converted into individual unicast data packets.
  • a server is necessary, which supplies the sender with the network participants of the multicast domain necessary for the implementation.
  • At least one CAN telegram can always be packed in one Ethernet packet. It is also possible to pack and send several time-buffered CAN telegrams in an Ethernet packet, which advantageously reduces the traffic on the network. Alternatively or additionally accompanying information can be encoded in the CAN message, which are necessary for the assignment of the acknowledgments.
  • a recipient of a message is always aware of Ethernet because each Ethernet packet contains the source and destination addresses.
  • the return ⁇ response (acknowledge packet ACK) is sent via unicast data packet.
  • additional packet elements are defined.
  • Ethernet packets for the CAN telegrams are preferably given a high priority (IEEE 802.3q), assuming Network 2 supports it.
  • the network 2 can be realized as an IP network (Layer 3, 4) using the network protocol UDP (User Datagram Protocol).
  • IP IP protocol
  • UDP User Datagram Protocol
  • the same mechanisms as in Ethernet can be used, whereby preferably the same requirements are made with regard to the multicast capability.
  • the implementation of the logical multicast domain in unicast connections with server support is also possible here.
  • the assignment of received IP telegrams to the CAN service and the corresponding CAN network is simpler when using the IP than with Ethernet, since UDP ports can be used for this purpose.
  • Si-DaNet described in DE 10 2005 008 503 B3 can likewise be used as network 2. It is a real-time, connection-oriented network for communication within a machine.
  • the multicast connections are implemented in SiDaNet via point-to-multipoint connections.
  • the unicast connections are realized in SiDaNet via point-to-point connections.
  • Each connection between two network participants has a unique connection identifier. Therefore, no further telegram features are necessary for the assignment of a received CAN telegram to the CAN service or a CAN network.
  • SND SiDaNet Network Description
  • FIG. 2 shows a first CAN interface 3.1 associated with a first CAN segment 1.1 with its individual components in a block diagram.
  • the individual components are a CAN controller 4, a CAN_RX packet memory 5, a CRC supplement unit 6, a CAN_RX controller 7, a network control ⁇ ler 8, a CAN_Tx packet memory 9, a CRC checking unit 10, a CAN_Tx Control 11 and a latch 12.
  • the CAN controller 4 has a CAN network interface, via the CAN-compliant messages Txl conform to the standard to the CAN interface 3.1 associated CAN segment 1.1 and CAN receive telegrams Rxl from the CAN segment 1.1 are emp ⁇ catchable. All CAN security mechanisms are adhered to. In particular, a CAN-CRC checksum is transmitted with the CAN transmission telegrams Txl, and a CAN-CRC checksum of the CAN reception telegrams Rxl is checked.
  • the CAN CRC checksum comprises, for example, 16 bits.
  • the CAN controller 4 preferably removes the CAN CRC checksum of the correctly received CAN receive telegrams Rxl and provides the CAN_Rx packet memory 5 with the CAN receive telegrams Rxl freed from the CAN CRC checksum at an output.
  • the CAN CRC checksum may be transmitted to the CAN_Rx packet memory 5. But this is not usually necessary and only increases unnecessary Da ⁇ tenauf tone.
  • the CAN controller 4 outputs the CAN transmission telegrams Txl in accordance with the standard to the CAN segment 1.1.
  • the CAN_Rx packet memory 5 provides the CRC supplementary unit 6 with the CAN receive messages Rxl. Because of the generally limited deterministic of the network 2, CAN receive telegrams Rx1 can also be temporarily buffered in the CAN_Rx packet memory 5.
  • the CRC supplementary unit 6 adds a new CRC checksum to the CAN receive messages Rxl for transmission in the network 2 which also includes 16 bits, for example. If the security mechanisms of the network 2 are sufficient, the CRC supplementary unit 6 can also be omitted.
  • the CAN_Rx controller 7 coordinates the CAN telegrams sent on the network 2 in the following way:
  • the network controller 8 has an interface to the network 2, via which the CAN telegrams can be sent to the network 2 in conformity with the standard and can be received from the network 2. If the network can not be completely transmitted in a data packet 2 CAN messages, the network controller correctly received CAN receive telegrams decomposed 8 further Rxl in ent ⁇ speaking adapted CAN transmit data packets Tx2 and sets in cooperation with the CAN_Tx packet memory 9 in greater detail below the manner described from the network 2 received CAN receive data packets Rx2 to CAN send telegrams Txl together (SAR mechanism).
  • the CAN transmit data packets Tx2 and CAN receive data packets Rx2 thus contain CAN sub-telegrams, if the network can not fully transferred to ei ⁇ nem data packet 2 CAN telegrams, ie in this case are segmented via the network 2 ⁇ gen übertra the CAN telegrams; otherwise the CAN transmit data packets Tx2 and the CAN receive data packets Rx2 contain complete CAN telegrams.
  • the CAN_Tx packet memory 9 receives the CAN receive data packets Rx2 received via the network 2 and buffers the CAN receive data packets Rx2 of a CAN telegram until the CAN telegram has been completely received. If there is no segmented transmission on network 2, then the
  • the CAN_Tx packet memory 9 has at least n-1 Speicherplät ⁇ ze, wherein each of the CAN segments 1.2 to ln is assigned at least one storage space and each storage location can accurately store a CAN message. Furthermore, each memory location is subdivided into memory space segments whose number corresponds to a maximum number of CAN receive data packets Rx2 into which a CAN telegram is segmented during transmission via the network 2 and which can each store a CAN receive data packet Rx2.
  • a CAN receive data packet Rx2 arrives via the network 2, the network controller 8 assigns a corresponding memory location and a corresponding memory space segment to the CAN receive data packet Rx2 on the basis of order characteristics contained in it, into which the CAN receive data packet Rx2 is to be stored.
  • the CAN receiving data packets are stored Rx2 a CAN message frame in the correct sequence in a memory location associated with the respective transmitting CAN segment 1.2 to ln in the ⁇ se, and thereby composed successively to the complete CAN message.
  • the CRC check unit 10 After a CAN telegram has been completely received, it is forwarded to the CRC check unit 10. As a result, the corresponding storage space in the CAN_Tx packet memory 9 is freed and ready for another CAN telegram.
  • the CRC check unit 10 is checked the CRC checksum of the received CAN frames, if for si ⁇ assurance to the network 2, a CRC checksum is used. If this is not the case, no CRC checking
  • the CAN_Tx controller 11 controls the transmission of CAN transmit telegrams Txl on the CAN segment 1.1 in the following way: It forwards correctly received CAN receive data packets Rx2 to the buffer 12.
  • CAN_Rx controller 7 has received a memory status message Xoff of another CAN segment 1.2 to ln. This prevents that Tx2 are fed into the network 2 in the Sprintlastsituati ⁇ on new CAN-transmission data packets. Before sending a backpressure
  • Telegram BP is attempting to empty its own intermediate memory 12.
  • the buffer 12 forms a buffer for correctly received CAN telegrams before their transmission to the CAN controller 4.
  • FIG. 3 schematically shows a sequence of error-free transmission of a CAN telegram from the first CAN segment 1.1 to the other CAN segments 1.2 to ln via the network 2 in a block diagram.
  • At least one CAN receive message Rxl is present in the CAN_Rx packet memory 5 of the first CAN interface 3.1, this is provided with the CRC checksum by means of its CRC supplementary unit 6, segmented by the network controller 8 into CAN transmit data packets Tx2, which are transmitted via the Network 2 are transmitted as multicast data packets to all other CAN interfaces 3.2 to 3.n, which logically belong to the same CAN network.
  • the received CAN receive telegrams Rx2 of this CAN telegram are first, as described above, stored in a memory area assigned to the transmitting first CAN segment 1.1.
  • the CAN_Tx packet memory 9 is written until the CAN telegram is completely received. Since in the CAN_Tx packet memory 9, there is a space for eachdian ⁇ len stations at least, and each memory location is exactly one CAN telegram can absorb, CAN messages can via the network 2 and a plurality of CAN segments 1.1 to ln simultaneously transmit without requiring a Packet loss occurs.
  • the CRC check unit 10 checks the CRC checksum of the received CAN telegram. If the CRC check is successful, as is assumed here, the received CAN frame is written into the insectspei ⁇ cher 12 of the respective CAN interface 3.2 to 3.n and from there via the CAN controller 4 in the respective CAN Segment 1.2 to ln fed. Simultaneously, a positive acknowledgment in the form of an acknowledge parity kets ACK as a unicast data packet to the first CAN interface of the ⁇ le 3.1 is returned.
  • the first CAN interface 3.1 collects and counts the acknowledge packets ACK received from the other CAN interfaces 3.2 to 3.n. If all n-1 acknowledge packets ACK have arrived within the timeout time, the first CAN interface 3.1 evaluates the transmission of the CAN telegram via the network 2 as successful. For this purpose, the number n of the CAN segments 1.1 to In that are logically to the CAN bus 1 together ⁇ quantitative switches, registered in each CAN interface 3.1 to 3.n in their configuration, so that the CAN_RX-tax augmentation 7 the first CAN interface 3.1 knows the number of expected acknowledge packets ACK.
  • FIG. 4 schematically shows a sequence of a transmission of a CAN telegram from the first CAN segment 1.1 to the other CAN segments 1.2 to ln via the network 2 in one Block diagram, wherein in contrast to the ge ⁇ showed in FIG. 3 error-free transmission, a transmission error in the network 2 occurs.
  • a segmented transmission of the CAN telegram and the backup of the CAN telegram with a CRC checksum are assumed during transmission via the network 2.
  • the first CAN interface 3.1 first sends a CAN telegram as described above with reference to FIG. 3 segmented via the network 2 to all other CAN interfaces 3.2 to 3.n of the same logical CAN bus 1.
  • a negative Bes ⁇ concernedungsnachricht to the first CAN interface to be 3.1 Gesen ⁇ det from the second CAN interface 3.2 that indicates a faulty transmission.
  • the CAN_Rx controller 7 of the first CAN interface 3.1 in turn collects the ACK acknowledge packet during the timeout time and counts it. Since the second CAN interface 3.2 no acknowledge packet ACK or a negative acknowledgment ⁇ object sends, represents the first CAN interface 3.1 after the timeout a missing acknowledge packet ACK firmly and thereby detect the faulty transmission of the CAN message ⁇ grams.
  • the complete CAN message is then transmitted from the first CAN interface 3.1 again via the network 2 at all to the CAN interfaces ⁇ 3.2 to 3.n of the same logical CAN bus 1, wherein the number of repetitions in the event of a fault is configurable.
  • FIG. 5 schematically shows a sequence of a transmission of CAN telegrams from the first CAN segment 1.1 to the other CAN segments 1.2 to ln via the network 2 in a block diagram, wherein an overflow of the buffer 12 of the second CAN interface 3.2 occurs. Again, a segmented transmission of the CAN telegrams and their hedging ⁇ tion with a CRC checksum in the transmission over the network 2 are assumed.
  • the first CAN interface 3.1 sends CAN telegrams as described above with reference to FIG. 3 segmented via the network 2 to all other CAN interfaces 3.2 to 3.n of the same logical CAN bus 1.
  • the second CAN interface 3.2 receives the CAN telegrams sent by the first CAN interface 3.1 and writes them into their intermediate memory 12 after a successful CRC check. If more CAN telegrams accumulate in the buffer memory 12 than via the downstream CAN controller 4 can be placed on the second CAN segment 1.2, the buffer 12 of the second CAN interface 3.2 runs fully.
  • Each CAN interface 3.1 to 3.n which receives this Xoff message, stops sending further CAN telegrams via the network 2 and holds the CAN receive telegrams Rxl read out of the CAN controller 4 in their CAN_Rx packet memory 5th
  • Each CAN interface 3.1 to 3.n is now trying to empty their Zvi ⁇ rule memory 12 and then sends it to their respective CAN segment 1.1 to ln a backpressure message BP, with which the respective CAN segment is blocked 1.1 to ln.
  • the backpressure command operates in a manner only complete if the own buffer memory 12 is empty, otherwise continue CAN transmission messages Txl be sent to the respective CAN-Seg ⁇ ment 1.1 to furniture. Therefore, any CAN interface 3.1 to 3.n first attempts to write its interim ⁇ memory 12 in the CAN controller 4 before it sends a backpressure telegram BP the content.
  • the second CAN interface 3.2 After the first Artschwellwert is again fallen below in the buffer 12 of the second CAN interface 3.2, the second CAN interface 3.2 sends a memory status message ⁇ Xon as a multicast Danna over the network 2 to all other CAN interfaces 3.1 to 3.n same logical CAN bus 1 and thus releases the transmission of CAN telegrams in the network 2 again.
  • the overflow of a buffer 12 therefore leads to the temporary blockage of the entire logical CAN bus. 1
  • the CAN_Rx controllers 7 of all CAN interfaces 3.1 to 3.n each have a list with the Xon / Xoff status of all other CAN interfaces 3.1 to 3.n. Furthermore, the CAN_Rx controllers 7 of the CAN interfaces 3.1 to 3.n preferably cyclically transmit their own Xon / Xoff status in addition to the current changes. In this way, possible packet losses of these commands can be compensated advantageous.
  • a backpressure telegram BP is also output of a CAN interfaces le 3.1 to 3.n to their respective CAN segment 1.1 to ln, when the memory capacity of the own CAN_RX packet memory 5 the second predetermined threshold value exceeds a filling ⁇ .
  • Characterized ⁇ advantageous way prevents further to ln CAN messages are generated in the accompanying CAN segment 1.1 and CAN_RX-packet memory 5 is running normally.
  • a CAN telegram doubling occurs.
  • the network 2 is only used when the CAN interface 3.1 to 3.n of the respective CAN segment 1.1 to ln receives a valid CAN telegram from it. Faulty CAN telegrams are already detected in the CAN controller 4 and not forwarded. The mechanisms for the arbitration of the CAN bus 1 for CAN telegrams of high priority remain fully within each CAN segment 1.1 to ln.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Datenübertragung mit einem CAN-Bus (1). Der CAN-Bus (1) wird in wenigstens zwei CAN-Segmente (1.1 bis 1.n) aufgeteilt und die CAN-Segmente (1.1 bis 1.n) des CAN-Busses (1) werden durch ein paketorientiertes Netzwerk (2) logisch miteinander verbunden, wobei CAN-Telegramme mittels des Netzwerkes (2) zwischen CAN-Segmenten (1.1 bis 1.n) übertragen werden. Die Übertragung der CAN-Telegramme über das Netzwerk (2) wird auf Fehlerfreiheit geprüft und ein erkannter Übertragungsfehler wird korrigiert, indem ein von einem sendenden CAN-Segment (1.1 bis 1.n) gesendetes und fehlerhaft übertragenes CAN-Telegramm von diesem CAN-Segment (1.1 bis 1.n) erneut über das Netzwerk (2) gesendet wird. Ferner betrifft die Erfindung eine Vorrichtung zur Datenübertragung mit einem in wenigstens zwei CAN-Segmente (1.1 bis 1.n) aufgeteilten CAN-Bus (1) und einem paketorientierten Netzwerk (2), das die CAN-Segmente (1.1 bis 1.n) logisch miteinander verbindet.

Description

Beschreibung
Verfahren und Vorrichtung zur Datenübertragung Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Datenübertragung mit einem CAN-Bus (CAN = Controller Area Network) .
CAN-Busse sind Feldbusse, mittels derer verschiedene Geräte zwecks Datenaustausch miteinander vernetzt werden. Sie werden vor allem in sicherheitsrelevanten Bereichen verwendet, bei denen eine hohe Datensicherheit benötigt wird, beispielsweise in der Automobiltechnik zur Vernetzung unterschiedlicher Steuergeräte und Sensoreinheiten, in der Automatisierungs- technik für überwachungstechnische Zwecke oder in der Medi¬ zintechnik in Magnetresonanz- und Computertomographen oder Herz-Lungen-Maschinen .
In verschiedenen Bereichen, in denen ein CAN-Bus eingesetzt wird, beispielsweise in bekannten Computertomographen mit einem CAN-Bus, wird neben dem CAN-Bus mindestens ein weiteres Netzwerk verwendet.
Es ist eine Aufgabe der Erfindung, ein verbessertes Verfahren und eine verbesserte Vorrichtung zur Datenübertragung mit einem CAN-Bus und einem weiteren Netzwerk anzugeben.
Die Aufgabe wird erfindungsgemäß hinsichtlich des Verfahrens durch die Merkmale des Anspruchs 1 und hinsichtlich der Vor- richtung durch die Merkmale des Anspruchs 11 gelöst.
Vorteilhafte Ausgestaltungen der Erfindung sind Gegenstand der Unteransprüche. Bei dem erfindungsgemäßen Verfahren zur Datenübertragung wird ein CAN-Bus in wenigstens zwei CAN-Segmente aufgeteilt und die CAN-Segmente des CAN-Busses werden durch ein paketorien¬ tiertes Netzwerk logisch miteinander verbunden, wobei CAN- Telegramme mittels des Netzwerkes zwischen CAN-Segmenten übertragen werden. Die Übertragung der CAN-Telegramme über das Netzwerk wird auf Fehlerfreiheit geprüft und ein erkann¬ ter Übertragungsfehler wird korrigiert, indem ein von einem sendenden CAN-Segment gesendetes und fehlerhaft übertragenes CAN-Telegramm von diesem CAN-Segment erneut über das Netzwerk gesendet wird.
Unter einem paketorientierten Netzwerk wird dabei ein Netz- werk verstanden, in dem Daten paketweise, d.h. in Form einzelner Datenpakete, übertragen werden.
Bei dem erfindungsgemäßen Verfahren wird somit ein CAN-Bus mit einem paketorientierten Netzwerk kombiniert, so dass das Netzwerk zwischen einzelnen CAN-Segmenten des CAN-Busses als ein Datentunnel wirkt, über den CAN-Telegramme zwischen den CAN-Segmenten übertragen werden. Mit anderen Worten: Das Netzwerk verbindet die CAN-Segmente logisch zu einem CAN-Bus. Auf diese Weise können vorteilhaft Endgeräte mit Schnittstel- len für einen CAN-Bus in den einzelnen CAN-Segmenten über das Netzwerk vernetzt werden, ohne dass ein physikalisch zusammenhängender CAN-Bus zusätzlich zu dem Netzwerk verlegt werden muss. Gegenüber Anlagen oder Geräten, in denen ein herkömmlicher CAN-Bus und ein zusätzliches Netzwerk nebeneinan- der eingesetzt werden, kann dadurch der Aufwand zur Vernetzung der an den CAN-Bus angeschlossenen Endgeräte erheblich reduziert werden.
Durch die Prüfung der Übertragung von CAN-Telegrammen auf Fehlerfreiheit und die Korrektur von Übertragungsfehlern durch wiederholtes Senden eines fehlerhaft übertragenen CAN- Telegramms werden dabei Datenverluste und Datenverfälschungen vorteilhaft reduziert. Insbesondere können dadurch bei der Übertragung von CAN-Telegrammen über das Netzwerk die daten- sichernden Mechanismen eines CAN-Busses weitgehend beibehal¬ ten werden, insbesondere eine deterministische Zugriffssteue¬ rung für das Bandbreitenmanagement, eine Quittierung eines Empfangs eines CAN-Telegramms bzw. ein Melden von Empfangs- fehlem und eine Wiederholung des Senden von fehlerhaft über¬ tragenen CAN-Telegrammen . Dadurch eignet sich das erfindungsgemäße Verfahren auch für sicherheitsrelevante Anwendungen, in denen CAN-Busse üblicherweise bevorzugt eingesetzt werden.
Moderne paketorientierte Netzwerke ermöglichen außerdem eine erheblich größere Ausdehnung als CAN-Busse. Die Verbindung der CAN-Segmente durch das Netzwerk ermöglicht daher die Rea¬ lisierung eines logischen CAN-Busses, der eine deutlich grö- ßere Ausdehnung als herkömmliche CAN-Busse hat. Dadurch wird die Verwendung insbesondere der sicherheitsrelevanten Vorteile eines CAN-Busses auf deutlich größere Systeme als bisher erweitert . In einer bevorzugten Ausgestaltung des Verfahrens wird jedes CAN-Segment über jeweils eine zugehörige CAN-Schnittstelle an das Netzwerk gekoppelt und das Senden von CAN-Telegrammen aus einem CAN-Segment über das Netzwerk und das Empfangen von CAN-Telegrammen aus dem Netzwerk mittels der zugehörigen CAN- Schnittstelle durchgeführt.
Dadurch werden alle Komponenten und Mechanismen zur Anbindung eines CAN-Segmentes an das Netzwerk, insbesondere diejenigen zur Datensicherung, in einer zugehörigen CAN-Schnittstelle vereint. Insbesondere ermöglicht dies vorteilhaft, die spe¬ ziellen Eigenschaften des verwendeten Netzwerkes durch die Ausbildung der CAN-Schnittstellen zu berücksichtigen, während die einzelnen CAN-Segmente wie bei einem üblichen CAN-Bus und insbesondere unabhängig von den speziellen Eigenschaften des verwendeten Netzwerkes gestaltet werden können.
Vorzugsweise wird dabei für jede CAN-Schnittstelle, mittels derer über das Netzwerk ein CAN-Telegramm empfangen wird, überprüft, ob das empfangene CAN-Telegramm fehlerfrei über- tragen wurde.
Dadurch können fehlerhaft übertragene CAN-Telegramme erkannt werden. Dies erhöht vorteilhaft die Datensicherheit. Dabei wird zur Überprüfung der fehlerfreien Übertragung eines CAN-Telegramms über das Netzwerk vorzugsweise eine CRC-Prüf¬ summe (CRC = Cyclic Redundancy Check) verwendet, die dem CAN- Telegramm vor dessen Sendung über das Netzwerk mittels der CAN-Schnittstelle des sendenden CAN-Segmentes hinzugefügt wird und die von jeder ein CAN-Telegramm über das Netzwerk empfangenden CAN-Schnittstelle überprüft wird.
Unter einer CRC-Prüfsumme wird dabei ein geeigneter Prüfwert verstanden, der zusammen mit einem Datenpaket übertragen wird, um Übertragungsfehler zu erkennen. Dabei wird von einem Empfänger eines Datenpaketes der empfangene Prüfwert mit dem gesendeten Soll-Prüfwert verglichen und auf einen Übertra¬ gungsfehler geschlossen, wenn die beiden Prüfwerte voneinan- der abweichen.
Die Verwendung einer CRC-Prüfsumme ist ein einfaches und er¬ probtes Verfahren, das sich deshalb vorteilhaft zur Erkennung von Übertragungsfehlern eignet.
Übertragungsfehler bei der Übertragung von CAN-Telegrammen über das Netzwerk werden vorzugsweise folgendermaßen erkannt und korrigiert:
- das CAN-Telegramm wird mittels einer sendenden CAN-Schnitt- stelle an alle anderen CAN-Schnittstellen gesendet;
- wenn mittels einer CAN-Schnittstelle ein CAN-Telegramm aus dem Netzwerk empfangen und dessen Übertragung als fehlerfrei eingestuft wird, wird von dieser CAN-Schnittstelle über das Netzwerk eine positive Bestätigungsnachricht an die sendende CAN-Schnittstelle gesendet;
- mittels der sendenden CAN-Schnittstelle wird das CAN- Telegramm erneut über das Netzwerk an alle anderen CAN- Schnittstellen gesendet, wenn die sendende CAN- Schnittstelle von wenigstens einer der anderen CAN- Schnittstellen innerhalb einer vorgebbaren Timeout-Zeit keine positive Bestätigungsnachricht empfängt. Auf diese Weise wird einer sendenden CAN-Schnittstelle von einer empfangenden CAN-Schnittstelle eine fehlerfreie Über¬ tragung eines CAN-Telegramms quittiert und die sendende CAN- Schnittstelle kann anhand der von ihr empfangenen Quittierun- gen die Fehlerfreiheit der Übertragung des CAN-Telegramms überprüfen. Dazu prüft sie, ob sie von allen anderen CAN- Schnittstellen eine positive Bestätigungsnachricht erhält. Ist dies der Fall, wird auf eine fehlerfreie Übertragung des CAN-Telegramms geschlossen. Andernfalls wird auf einen Über- tragungsfehler geschlossen und versucht, diesen durch erneutes Senden eines fehlerhaft übertragenen CAN-Telegramms zu korrigieren. Dies reduziert vorteilhaft die Wahrscheinlich¬ keit eines Datenverlustes und einer Datenverfälschung und er¬ höht somit die Datensicherheit bei der Übertragung von CAN- Telegrammen über das Netzwerk.
Die Vorgabe einer Timeout-Zeit für das Warten auf Bestäti¬ gungsnachrichten verhindert dabei vorteilhaft, dass eine CAN- Schnittstelle beliebig lange auf eine Bestätigungsnachricht wartet, dadurch blockiert wird und ein Übertragungsfehler nicht korrigiert wird.
Ferner wird vorzugsweise ein von einer CAN-Schnittstelle aus dem Netzwerk empfangenes CAN-Telegramm nur dann mittels die- ser CAN-Schnittstelle dem zugehörigen CAN-Segment übergeben, wenn die Übertragung des CAN-Telegramms als fehlerfrei einge¬ stuft wird.
Dadurch wird verhindert, dass fehlerhaft übertragene CAN- Telegramme in ein CAN-Segment übertragen werden. Dies verringert einerseits vorteilhaft unnötigen Datenverkehr in den CAN-Segmenten und verhindert andererseits vorteilhaft, dass den an den logischen CAN-Bus angeschlossenen Endgeräten verfälschte Nachrichten zugestellt werden, die möglicherweise zu unerwünschten Reaktionen eines oder mehrerer dieser Endgeräte führen . In einer bevorzugten Ausgestaltung des Verfahrens wird ein von einer CAN-Schnittstelle über das Netzwerk empfangenes CAN-Telegramm in einem Zwischenspeicher der CAN-Schnittstelle zwischengespeichert, bevor es von der CAN-Schnittstelle an das zugehörige CAN-Segment weitergeleitet wird.
Durch die Zwischenspeicherung kann ein von einer CAN-Schnittstelle aus dem Netzwerk empfangenes CAN-Telegramm zeitverzö¬ gert an das zugehörige CAN-Segment weitergeleitet werden. Da- durch können vorteilhaft Totzeiten überbrückt werden, in denen ein CAN-Segment nicht empfangsbereit ist oder eine Wei¬ terleitung eines CAN-Telegramms an das CAN-Segment aus ande¬ ren Gründen nicht möglich ist, insbesondere wenn das CAN-Seg¬ ment durch den dortigen lokalen Datenverkehr bereits überlas- tet ist. Insbesondere wird dadurch ein Datenverlust während derartiger Totzeiten vermieden.
In einer bevorzugten Weitergestaltung dieser Ausgestaltung des Verfahrens wird von einer CAN-Schnittstelle an alle ande- ren CAN-Schnittstellen eine entsprechende Speicherstatusnachricht gesendet, sobald die Speicherauslastung ihres Zwischen¬ speichers einen vorgebbaren ersten Füllschwellwert überschreitet oder unterschreitet. Alternativ oder zusätzlich wird von jeder CAN-Schnittstelle zyklisch in vorgebbaren Zeitabständen an alle anderen CAN- Schnittstellen eine Speicherstatusnachricht darüber gesendet wird, ob eine aktuelle Speicherauslastung des Zwischenspei¬ chers der jeweiligen CAN-Schnittstelle einen ersten Füll- schwellwert überschreitet.
Dadurch können alle anderen CAN-Schnittstellen über die Gefahr eines Speicherüberlaufes in dem Zwischenspeicher einer CAN-Schnittstelle oder über die Beseitigung einer derartigen Gefahr informiert werden.
Vorzugsweise werden bei dieser Weitergestaltung des Verfahrens ferner von jeder CAN-Schnittstelle anhand der von ihr empfangenen Speicherstatusnachrichten die aktuellen Speicherauslastungen der Zwischenspeicher aller anderen CAN- Schnittstellen überwacht und CAN-Telegramme nur dann versendet, wenn die Speicherauslastungen der Zwischenspeicher aller anderen CAN-Schnittstellen den ersten Füllschwellwert unterschreiten .
Dies verhindert, dass CAN-Telegramme über das Netzwerk ver¬ sendet werden, solange in einer CAN-Schnittstelle ein Spei- cherüberlauf in deren Zwischenspeicher droht, da das zugehö¬ rige CAN-Segment überlastet ist. Dadurch wird das für einen üblichen CAN-Bus charakteristische Bandbreitenmanagement über eine Busarbitrierung mittels CAN-Identifizierung nachgebildet und vorteilhaft ein Speicherüberlauf in den Zwischenspeichern der CAN-Schnittstellen und somit ein Datenverlust durch einen derartigen Speicherüberlauf verhindert.
Die erfindungsgemäße Vorrichtung zur Datenübertragung weist dementsprechend einen in wenigstens zwei CAN-Segmente aufge- teilten CAN-Bus und ein paketorientiertes Netzwerk auf. Das Netzwerk verbindet die CAN-Segmente logisch derart miteinan¬ der, dass von jedem CAN-Segment ein CAN-Telegramm mittels des Netzwerkes sowohl zu allen anderen CAN-Segmenten als auch gezielt zu einem auswählbaren anderen CAN-Segment sendbar ist.
Dadurch ermöglicht die erfindungsgemäße Vorrichtung die
Durchführung des erfindungsgemäßen Verfahrens mit den oben genannten Vorteilen. Insbesondere ermöglicht sie die Versen¬ dung eines CAN-Telegramms über das Netzwerk an alle anderen CAN-Segmente und an ein auswählbares anderes CAN-Segment und damit die oben beschriebene Erkennung und Korrektur von Übertragungsfehlern bei der Übertragung eines CAN-Telegramms über das Netzwerk durch eine Quittierung fehlerfrei empfangener CAN-Datenpakete .
Vorzugsweise weist die erfindungsgemäße Vorrichtung jeweils eine CAN-Schnittstelle für jedes CAN-Segment zu dessen An- kopplung an das Netzwerk und zur Steuerung des Sendens von CAN-Telegrammen aus dem CAN-Segment über das Netzwerk und des Empfangens von CAN-Telegrammen aus dem Netzwerk auf.
Dadurch wird das Senden und Empfangen von CAN-Telegrammen mittels der CAN-Schnittstellen gemäß dem erfindungsgemäßen Verfahren mit den oben beschriebenen Vorteilen ermöglicht.
Ferner weist jede CAN-Schnittstelle vorzugsweise einen Zwi- schenspeicher zum Speichern aus dem Netzwerk empfangener CAN- Telegramme auf.
Dies ermöglicht die Zwischenspeicherung aus dem Netzwerk emp fangener CAN-Telegramme und deren zeitverzögerte Weiterlei¬ tung an die CAN-Segmente mit den oben beschriebenen Vorteilen .
Weitere Vorteile, Merkmale und Einzelheiten der Erfindung werden im Folgenden anhand von Ausführungsbeispielen unter Bezugnahme auf Zeichnungen beschrieben. Dabei zeigen:
FIG 1 schematisch eine Vorrichtung zur Datenübertragung mit mehreren CAN-Segmenten eines CAN-Busses, die über ein Netzwerk logisch miteinander verbunden sind,
FIG 2 ein Blockschaltbild einer CAN-Schnittstelle,
FIG 3 schematisch einen Ablauf einer fehlerfreien Übertragung von CAN-Telegrammen zwischen CAN-Segmenten über ein Netzwerk in einem Blockschaltbild,
FIG 4 schematisch einen Ablauf einer Übertragung von CAN- Telegrammen zwischen CAN-Segmenten über ein Netzwerk bei Paketverlust in einem Blockschaltbild, und FIG 5 schematisch einen Ablauf einer Übertragung von CAN-
Telegrammen zwischen CAN-Segmenten über ein Netzwerk bei Speicherüberlauf in einer CAN-Schnittstel- le in einem Blockschaltbild.
Einander entsprechende Teile sind in allen Figuren mit den gleichen Bezugszeichen versehen. Figur 1 zeigt schematisch eine Vorrichtung zur Datenübertragung mit einem CAN-Bus 1 mit mehreren CAN-Teilnehmern C.l bis Cm, der in n CAN-Segmente 1.1 bis l.n aufgeteilt ist. Die CAN-Segmente 1.1 bis l.n sind über ein paketorientiertes Netzwerk 2 logisch miteinander verbunden, indem CAN-Tele- gramme zwischen den CAN-Segmenten 1.1 bis l.n über das Netzwerk 2 austauschbar sind. Das Netzwerk 2 bildet also einen Tunnel zwischen den CAN-Segmenten 1.1 bis l.n und verbindet diese logisch zu dem CAN-Bus 1. Die CAN-Teilnehmer C.l bis Cm sind Endgeräte, die von der jeweiligen Verwendung des
CAN-Busses 1 abhängen. Die Gesamtheit der CAN-Teilnehmer C.l bis Cm und der sie verbindende logische CAN-Bus 1 wird im Folgenden auch als CAN-Netzwerk bezeichnet. Jedes CAN-Segment 1.1 bis l.n ist über eine unten näher be¬ schriebene ihm zugeordnete CAN-Schnittstelle 3.1 bis 3.n an das Netzwerk 2 gekoppelt. CAN-Telegramme, die in einem der CAN-Segmente 1.1 bis l.n gesendet werden, werden über die je¬ weilige CAN-Schnittstelle 3.1 bis 3.n an das Netzwerk 2 und durch das Netzwerk 2 zu jeder anderen CAN-Schnittstelle 3.1 bis 3.n übertragen.
Die Paketgröße des CAN-Busses 1 (3 bis 13 Byte zuzüglich ei¬ ner Prüfsumme zur zyklischen Redundanzprüfung) wird auf die Paketgröße des Netzwerks 2 umgesetzt. Falls das Netzwerk 2 ein CAN-Telegramm eines CAN-Segmentes 1.1 bis l.n nicht in einem Datenpaket transportieren kann, wird das CAN-Telegramm vor seiner Übertragung in das Netzwerk 2 in CAN-Datenpakete zerlegt, die jeweils von dem Netzwerk 2 übertragen werden können, und diese CAN-Datenpakete werden nach der Übertragung über das Netzwerk 2 wieder zu CAN-Telegrammen zusammengesetzt. Dazu wird in den CAN-Schnittstellen 3.1 bis 3.n ein entsprechender SAR-Mechanismus (SAR = Segmentation and Reas- sembly) zum Zerlegen und Zusammensetzen von CAN-Telegrammen implementiert.
Auf den einzelnen sendenden und empfangenden CAN-Segmenten 1.1 bis l.n erfolgt der Buszugriff mittels einer Arbitrierung wie bei einem üblichen CAN-Bus durch ein CD-Verfahren (CD = Carrier Detect) und einen zerstörungsfreien, prioritätsgesteuerten Zugang zum Übertragungsmedium. Die Übertragungskapazität des Netzwerkes 2 ist so ausgelegt, dass sie im Mittel ausreicht, um die anfallenden CAN-Telegramme und die Datenpa¬ kete zu deren Management (insbesondere zur unten beschriebe¬ nen Datensicherung) zu übertragen. Kurzzeitige Überlastsituationen werden in unten näher beschriebener Weise durch interne Bufferspeicher überbrückt. Im Netzwerk 2 wird daher keine Arbitrierung von Netzwerkressourcen benötigt.
Die End-to-End-Datensicherung eines üblichen CAN-Busses (von Sender zu Empfänger) wird durch eine segmentierte Datensiche¬ rung ersetzt. Dabei stellt jedes CAN-Segment 1.1 bis l.n für sich die Integrität der übertragenen Daten sicher und bei der Übertragung über das paketorientierte Netzwerk 2 werden im Folgenden näher beschriebene Sicherheitsmechanismen verwendet. Nur korrekt empfangene CAN-Telegramme werden von einem CAN-Segment 1.1 bis l.n an das Netzwerk 2 oder von dem Netz- werk 2 an ein CAN-Segment 1.1 bis l.n weitergeleitet.
Bei der Übertragung im Netzwerk 2 werden übliche CAN-Sicher- heitsmechanismen zur Datensicherung weitestgehend beibehalten. Übertragungsfehler innerhalb des Netzwerks 2 werden über einen Quittierungsmechanismus erkannt und durch erneutes Sen¬ den eines fehlerhaft übertragenen CAN-Datenpaktes korrigiert.
Dabei werden CAN-Datenpakete durch eine zyklische Redundanz¬ prüfung mittels einer CRC-Prüfsumme (CRC = Cyclic Redundancy Check) und charakteristische Bitwerte gesichert, falls das
Netzwerk 2 keine ausreichenden eigenen Sicherheitsmechanismen aufweist. Empfängt eine CAN-Schnittstelle 3.1 bis 3.n ein CAN-Telegramm, so überprüft sie gegebenenfalls dessen CRC- Prüfsumme und quittiert im Fall einer als fehlerfrei einge- stuften Übertragung den Empfang des CAN-Datenpaketes, indem sie eine positive Bestätigungsnachricht (Acknowledge-Paket ACK) an den Sender des CAN-Datenpaketes, d.h. an die betref¬ fende CAN-Schnittstelle 3.1 bis 3.n, sendet. Im Falle einer fehlerhaften Übertragung sendet die empfangende CAN-Schnitt- stelle 3.1 bis 3.n kein Acknowledge-Paket ACK oder sie sendet eine negative Bestätigungsnachricht an den Sender. Die CAN-Schnittstelle 3.1 bis 3.n des Senders überprüft wäh¬ rend einer vorgebbaren Timeout-Zeit nach dem Senden eines CAN-Telegramms , ob von allen anderen CAN-Schnittstellen 3.1 bis 3.n von CAN-Segmenten 1.1 bis l.n ein Acknowledge-Paket ACK eingeht. Wenn nach Ablauf der Timeout-Zeit mindestens ein Acknowledge-Paket ACK fehlt oder eine negative Bestätigungs¬ nachricht empfangen wurde, sendet die CAN-Schnittstelle 3.1 bis 3.n des Senders das CAN-Telegramm erneut an die anderen CAN-Segmente 1.1 bis l.n des CAN-Busses 1. Die Anzahl der Wiederholungen im Fehlerfall ist konfigurierbar. Die Timeout- Zeit wird dem jeweiligen Netzwerk 2 angepasst. Sie wird ins¬ besondere so gewählt, dass sie länger ist als die zweifache Zeit, die benötigt wird, um ein Datenpaket im Netzwerk 2 zu übertragen, da die Übertragungszeiten eines CAN-Datenpaketes und der Acknowledge-Pakete ACK sowie eine zusätzliche Zeitre- serve zu berücksichtigen sind.
Da an das Netzwerk 2 in der Regel auch Netzwerkteilnehmer angeschlossen sind, die nicht zu dem CAN-Netzwerk des CAN-Bus¬ ses 1 gehören, verfügen die zu dem CAN-Netzwerk gehörenden Netzwerkteilnehmer über ein charakteristisches Adressmerkmal, z.B. eine Ethernet-Multicastadresse oder eine spezielle Ver¬ bindung. Dadurch wird sichergestellt, dass CAN-Datenpakete nur zwischen den CAN-Segmenten 1.1 bis l.n ausgetauscht und nicht auch anderen Netzwerkteilnehmern des Netzwerkes 2 zuge- stellt werden.
In einer Weitergestaltung des hier beschriebenen Ausführungsbeispiels können durch geeignete Vergabe von Ordnungs-Krite¬ rien innerhalb des Netzwerks 2, beispielsweise von Adressen, auch mehrere logisch verschiedene CAN-Busse 1 an dem Netz¬ werk 2 betrieben werden. Das Netzwerk 2 ist sowohl multicast- als auch unicastfähig ausgebildet, d.h. über das Netzwerk 2 können Datenpakete so¬ wohl in Form von Multicast-Datenpaketen an eine Gruppe von Netzwerkteilnehmern als auch als Unicast-Datenpakete gezielt an jeweils einen bestimmten Netzwerkteilnehmer versendet werden .
Dabei ermöglicht die Multicast-Fähigkeit , CAN-Datenpakete an alle CAN-Teilnehmer C.l bis Cm des logischen CAN-Busses 1 zu versenden. Die Unicast-Fähigkeit ermöglicht den oben be¬ schriebenen Quittierungsmechanismus durch die gezielte Über¬ tragung der Acknowledge-Pakete ACK an den Sender eines CAN- Telegramms . Ferner ist das Netzwerk 2 derart ausgebildet, dass eine Zeit angebbar ist, nach der in der Regel ein CAN-Datenpaket über das Netzwerk 2 übertragen ist. Dies ermöglicht, die Timeout- Zeit für das Warten auf Acknowledge-Pakete ACK festzulegen. Durch geeignete Priorisierung der CAN-Telegramme oder andere EchtZeiteigenschaften des Netzwerks 2 kann diese Zeit redu¬ ziert und damit die Deterministik der CAN-Tunnelung durch das Netzwerk 2 erhöht werden.
Das Netzwerk 2 kann auf verschiedene Weisen realisiert wer- den, beispielsweise als Ethernetnetzwerk, als IP-Netzwerk (IP = Internetprotokoll) oder als so genanntes SiDaNet-Netzwerk, das aus der DE 10 2005 008 503 B3 bekannt ist.
Bei einer Realisierung als Ethernetnetzwerk nach IEEE 802.3 auf Layer 2 können für die Multicastverbindungen die Multi- castadressen von Ethernet verwendet werden. Jedes logische CAN-Netzwerk verfügt über eine eigene Multicastadresse . Die Zuordnung der Multicast-Adresse zu einem logischen CAN-Netzwerk kann per Konfiguration der betroffenen Netzwerkteilneh- mer oder die Definition und Installation eines entsprechenden Servers vergleichbar zu DHCP (DHCP = Dynamic Host Configura- tion Protocol) realisiert werden. Zur effektiven Nutzung von Multicastmechanismen in Ethernet ist das Netzwerk 2, wie oben bereits erwähnt, multicastfähig ausgebildet und verfügt vorzugsweise über die Möglichkeit, dass sich Netzwerkteilnehmer an den Netzwerkknoten für be- stimmte Multicastadressen registrieren können. Verfügt das Netzwerk 2 nicht über diese Möglichkeit, so werden Multi¬ castadressen wie Broadcastadressen behandelt und jedem Netzwerkteilnehmer zugestellt. Dies führt jedoch zu einer hohen Netzwerklast und einer hohen Empfangsdatenrate bei allen Netzwerkteilnehmern. Alternativ kann ein logisches Multicast- Datenpaket auch in einzelne Unicast-Datenpakete umgesetzt werden. Hierfür ist ein Server notwendig, welcher dem Sender die für die Umsetzung notwendigen Netzwerkteilnehmer der Mul- ticastdomäne liefert.
Aufgrund seiner Paketlänge von mindestens 60 Byte lässt sich in einem Ethernetpaket immer mindestens ein CAN-Telegramm verpacken. Es können auch mehrere zeitlich gepufferte CAN- Telegramme in einem Ethernetpaket verpackt und versendet wer- den, wodurch der Datenverkehr auf dem Netzwerk vorteilhaft verringert wird. Alternativ oder zusätzlich können noch Begleitinformationen im CAN-Telegramm codiert werden, welche für die Zuordnung der Quittungen notwendig sind. Ein Empfänger einer Nachricht ist bei Ethernet immer bekannt, da jedes Ethernetpaket die Quell- und Zieladresse enthält. Die Rück¬ antwort (Acknowledge-Paket ACK) wird per Unicast-Datenpaket gesendet. Damit der Empfänger jedoch die Empfangsantwort (empfangenes Acknowledge-Paket ACK) einem logischen CAN-Netz- werk zuordnen kann, werden noch zusätzliche Paketelemente de- finiert. Möglich ist dies beispielsweise über die Definition von SSAP/DSAP (SSAP = Source Service Access Point, DSAP = Destination Service Access Point) oder Ethertypes. Hierüber wird mindestens codiert, dass sich die Rückantwort auf den CAN-Dienst bezieht. Die logische Zuordnung zu einem konkreten CAN-Netzwerk kann dann auch in den Nutzdaten des CAN-Tele- gramms erfolgen. Um die Latenzzeit von CAN-Telegrammen im Netzwerk 2 zu minimieren, werden Ethernetpakete für die CAN- Telegramme vorzugsweise mit einer hohen Priorität (IEEE 802.3q) versendet, vorausgesetzt das Netzwerk 2 unterstützt dies .
Alternativ kann das Netzwerk 2 als IP-Netzwerk (Layer 3, 4) unter Verwendung des Netzwerkprotokolls UDP (UDP = User Datagram Protocol) realisiert werden. Ein Vorteil dieser Reali¬ sierung gegenüber einem Ethernetnetzwerk ist, dass der Netzwerkzugang hierfür einfacher ist und keine Abhängigkeit vom konkreten Netzwerk 2 besteht. Bei Verwendung des IP können prinzipiell die gleichen Mechanismen wie bei Ethernet benutzt werden, wobei vorzugsweise die gleichen Anforderungen hinsichtlich der Multicast-Fähigkeit gestellt werden. Alternativ ist auch hier die Umsetzung der logischen Multicastdomäne in Unicast-Verbindungen mit Serverunterstützung möglich. Die Zu- Ordnung von empfangenen IP-Telegrammen zum CAN-Dienst und dem entsprechenden CAN-Netzwerk ist bei Verwendung des IP einfacher als bei Ethernet, da hierfür UDP-Ports verwendet werden können . Das in der DE 10 2005 008 503 B3 beschriebene so genannte Si- DaNet kann ebenfalls als Netzwerk 2 verwendet werden. Es ist ein echtzeitfähiges , verbindungsorientiertes Netzwerk zur Kommunikation innerhalb einer Maschine. Die Multicast-Verbin- dungen werden in SiDaNet über Punkt-zu-Multipunkt-Verbindun- gen realisiert. Die Unicast-Verbindungen werden in SiDaNet über Punkt-zu-Punkt-Verbindungen realisiert. Jede Verbindung zwischen zwei Netzwerkteilnehmern hat dabei eine eindeutige Verbindungskennung . Daher sind keine weiteren Telegrammmerkmale zur Zuordnung eines empfangenen CAN-Telegramms zum CAN- Dienst oder einem CAN-Netzwerk notwendig. Die Konfiguration, welcher SiDaNet-Teilnehmer Bestandteil welchen CAN-Netzes ist, erfolgt einfach und symbolisch in einer Netzwerkbschrei- bung (SND = SiDaNet Network Description) . Ein SiDaNet-Network Manager erzeugt daraus automatisch die notwendigen Verbindun- gen innerhalb des SiDaNet und beschreibt diese in der Konfi¬ guration für die Netzwerkteilnehmer (SDC = SiDaNet Device Configuration SDC) und Switches (SSC = SiDaNet Switch Confi- guration) . Figur 2 zeigt eine einem ersten CAN-Segment 1.1 zugeordnete erste CAN-Schnittstelle 3.1 mit deren einzelnen Komponenten in einem Blockschaltbild. Die einzelnen Komponenten sind ein CAN-Controller 4, ein CAN_Rx-Paketspeicher 5, eine CRC-Ergän- zungseinheit 6, eine CAN_Rx-Steuerung 7, ein Netzwerkcontrol¬ ler 8, ein CAN_Tx-Paketspeicher 9, eine CRC-Überprüfungseinheit 10, eine CAN_Tx-Steuerung 11 und ein Zwischenspeicher 12. Der CAN-Controller 4 weist eine CAN-Netzwerkschnittstelle auf, über die normkonform CAN-Sendetelegramme Txl an das zu der CAN-Schnittstelle 3.1 gehörige CAN-Segment 1.1 sendbar und CAN-Empfangstelegramme Rxl aus dem CAN-Segment 1.1 emp¬ fangbar sind. Dabei werden alle CAN-Sicherungsmechanismen eingehalten. Insbesondere wird mit den CAN-Sendetelegrammen Txl eine CAN-CRC-Prüfsumme übertragen, und es wird eine CAN- CRC-Prüfsumme der CAN-Empfangstelegramme Rxl überprüft. Die CAN-CRC-Prüfsumme umfasst beispielsweise 16 Bit. Der CAN-Controller 4 entfernt vorzugsweise die CAN-CRC-Prüf- summe der korrekt empfangenen CAN-Empfangstelegramme Rxl und stellt dem CAN_Rx-Paketspeicher 5 an einem Ausgang die von der CAN-CRC-Prüfsumme befreiten CAN-Empfangstelegramme Rxl zur Verfügung. Alternativ kann die CAN-CRC-Prüfsumme mit zu dem CAN_Rx-Paketspeicher 5 übertragen werden. Dies ist aber in der Regel nicht notwendig und erhöht nur unnötig das Da¬ tenaufkommen. In Senderichtung zu dem CAN-Segment 1.1 gibt der CAN-Controller 4 die CAN-Sendetelegramme Txl normkonform zu dem CAN-Segment 1.1 aus.
Der CAN_Rx-Paketspeicher 5 stellt der CRC-Ergänzungseinheit 6 die CAN-Empfangstelegramme Rxl zur Verfügung. Aufgrund der in der Regel eingeschränkten Deterministik des Netzwerks 2 können dabei auch CAN-Empfangstelegramme Rxl temporär in dem CAN_Rx-Paketspeicher 5 zwischengepuffert werden.
Die CRC-Ergänzungseinheit 6 fügt den CAN-Empfangstelegrammen Rxl für die Übertragung im Netzwerk 2 eine neue CRC-Prüfsumme hinzu, die beispielsweise ebenfalls 16 Bit umfasst. Wenn die Sicherungsmechanismen des Netzwerks 2 ausreichend sind, kann die CRC-Ergänzungseinheit 6 auch entfallen. Die CAN_Rx-Steuerung 7 koordiniert die am Netzwerk 2 gesendeten CAN-Telegramme in folgender Weise:
- Sie veranlasst die Sendung eines neuen CAN-Telegramms über das Netzwerk 2, wenn das Netzwerk 2 Übertragungs- kapazität frei hat.
- Sie verhindert das Senden von CAN-Telegrammen über das Netzwerk 2, wenn eine andere CAN-Schnittstelle 3.2 bis 3.n Überlast festgestellt hat und dies in unten näher beschriebener Weise durch eine Speicherstatus- nachricht Xoff mitteilt, und sie gibt das Senden wie¬ der frei, wenn keine andere CAN-Schnittstelle 3.2 bis 3.n mehr überlastet ist.
- Sie überprüft durch Empfang der Acknowledge- Pakete ACK, ob alle Empfänger im Netzwerk 2 das CAN- Telegramm fehlerfrei empfangen haben.
- Sie wiederholt die Übertragung eines CAN-Telegramms im Netzwerk 2, wenn ein Empfänger das CAN-Telegramm falsch oder gar nicht (fehlendes Acknowledge-
Paket ACK) empfangen hat.
Der Netzwerkcontroller 8 weist eine Schnittstelle zum Netzwerk 2 auf, über die die CAN-Telegramme normkonform an das Netzwerk 2 sendbar und aus dem Netzwerk 2 empfangbar sind. Wenn das Netzwerk 2 CAN-Telegramme nicht vollständig in einem Datenpaket übertragen kann, zerlegt der Netzwerkcontroller 8 ferner korrekt empfangene CAN-Empfangstelegramme Rxl in ent¬ sprechend angepasste CAN-Sendedatenpakete Tx2 und setzt in Zusammenwirken mit dem CAN_Tx-Paketspeicher 9 in unten näher beschriebener Weise aus dem Netzwerk 2 empfangene CAN-Emp- fangsdatenpakete Rx2 zu CAN-Sendetelegrammen Txl zusammen (SAR-Mechanismus) . Die CAN-Sendedatenpakete Tx2 und CAN-Emp- fangsdatenpakete Rx2 enthalten somit CAN-Teiltelegramme, falls das Netzwerk 2 CAN-Telegramme nicht vollständig in ei¬ nem Datenpaket übertragen kann, d.h. in diesem Fall werden die CAN-Telegramme segmentiert über das Netzwerk 2 übertra¬ gen; andernfalls enthalten die CAN-Sendedatenpakete Tx2 und die CAN-Empfangsdatenpakete Rx2 vollständige CAN-Telegramme.
Bei segmentierter Übertragung der CAN-Telegramme über das Netzwerk 2 nimmt der CAN_Tx-Paketspeicher 9 die über das Netzwerk 2 empfangenen CAN-Empfangsdatenpakete Rx2 auf und puffert die CAN-Empfangsdatenpakete Rx2 eines CAN-Telegramms bis das CAN-Telegramm vollständig empfangen wurde. Erfolgt am Netzwerk 2 keine segmentierte Übertragung, so wird der
CAN_Tx-Paketspeicher 9 nicht benötigt. Der CAN_Tx-Paketspeicher 9 weist mindestens n-1 Speicherplät¬ ze auf, wobei jedem der CAN-Segmente 1.2 bis l.n mindestens ein Speicherplatz zugeordnet ist und jeder Speicherplatz genau ein CAN-Telegramm speichern kann. Ferner ist jeder Speicherplatz in Speicherplatzsegmente unterteilt, deren Anzahl einer maximalen Anzahl von CAN-Empfangsdatenpaketen Rx2 entspricht, in die ein CAN-Telegramm bei der Übertragung über das Netzwerk 2 segmentiert wird, und die jeweils ein CAN-Emp- fangsdatenpaket Rx2 speichern können. Wenn ein CAN-Empfangs- datenpaket Rx2 über das Netzwerk 2 eintrifft, ordnet der Netzwerkcontroller 8 dem CAN-Empfangsdatenpaket Rx2 aufgrund in ihm enthaltener Ordnungsmerkmale einen entsprechenden Speicherplatz und ein entsprechendes Speicherplatzsegment zu, in das das CAN-Empfangsdatenpaket Rx2 abzulegen ist. Auf die¬ se Weise werden die CAN-Empfangsdatenpakete Rx2 eines CAN- Telegramms in richtiger Reihenfolge in einem Speicherplatz abgelegt, der dem jeweils sendenden CAN-Segment 1.2 bis l.n zugeordnet ist, und dabei sukzessive zu dem vollständigen CAN-Telegramm zusammengesetzt. Nachdem ein CAN-Telegramm vollständig empfangen wurde, wird es an die CRC-Überprüfungseinheit 10 weitergereicht. Dadurch wird der entsprechende Speicherplatz im CAN_Tx-Paketspeich- er 9 frei und für ein weiteres CAN-Telegramm aufnahmebereit. Mittels der CRC-Überprüfungseinheit 10 wird die CRC-Prüfsumme der empfangenen CAN-Telegramme überprüft, falls zur Datensi¬ cherung am Netzwerk 2 eine CRC-Prüfsumme eingesetzt wird. Ist dies nicht der Fall, wird keine CRC-Überprüfungseinheit 10 benötigt.
Die CAN_Tx-Steuerung 11 regelt das Senden von CAN-Sendetele- grammen Txl am CAN-Segment 1.1 auf folgende Weise: - Sie leitet korrekt empfangene CAN-Empfangsdatenpake- te Rx2 in den Zwischenspeicher 12 weiter.
- Sie leitet die korrekt empfangenen CAN-Empfangsdaten- pakete Rx2 aus dem Zwischenspeicher 12 an den CAN-Con- troller 4 weiter, wenn dieser zu deren Aufnahme bereit ist.
- Sie quittiert einen korrekten Empfang eines CAN-Emp- fangsdatenpaketes Rx2, indem sie ein Acknowledge-Pa- ket ACK an den Sender zurückschickt.
- Sie überwacht den Füllstand des Zwischenspeichers 12 und veranlasst bei drohendem Überlauf das Senden einer
Xoff-Nachricht und nach Abbau der Überlast das Senden einer Xon-Nachricht an alle Sender im Netzwerk 2.
- Dabei sendet sie die Xon- bzw Xoff-Nachrichten zyklisch, um eine Blockade der Datenübertragung aufgrund von Übertragungsfehlern zu verhindern.
- Sie sendet ein so genanntes Backpressure-Telegramm BP, d.h. ein CAN-Telegramm höchster Priorität zum Blockieren der Aktivitäten der CAN-Teilnehmer C.l bis Cm im CAN-Segment 1.1 an das CAN-Segment 1.1, wenn der eige- ne CAN_Rx-Paketspeicher 5 zu voll wird oder die
CAN_Rx-Steuerung 7 eine Speicherstatusnachricht Xoff eines anderen CAN-Segmentes 1.2 bis l.n empfangen hat. Dadurch wird verhindert, dass bei der Überlastsituati¬ on neue CAN-Sendedatenpakete Tx2 in das Netzwerk 2 eingespeist werden. Vor dem Senden eines Backpressure-
Telegramms BP wird versucht, den eigenen Zwischenspei¬ cher 12 zu leeren. Der Zwischenspeicher 12 bildet einen Puffer für korrekt empfangene CAN-Telegramme vor deren Übertragung an den CAN-Con- troller 4. Der Zwischenspeicher 12 ist vorzugsweise derart ausgebildet, dass er mehrere CAN-Telegramme gleichzeitig zwi- schenspeichern kann. Dabei ist er vorzugsweise als ein Fifo- Speicher (Fifo = First in - first out) ausgebildet, bei dem diejenigen CAN-Telegramme, die zuerst gespeichert wurden, auch zuerst wieder aus dem Speicher entnommen werden. Figur 3 zeigt schematisch einen Ablauf einer fehlerfreien Übertragung eines CAN-Telegrammes von dem ersten CAN-Seg- ment 1.1 zu den anderen CAN-Segmenten 1.2 bis l.n über das Netzwerk 2 in einem Blockschaltbild. Dabei werden eine seg¬ mentierte Übertragung des CAN-Telegramms und die Sicherung des CAN-Telegramms mit einer CRC-Prüfsumme bei der Übertra¬ gung über das Netzwerk 2 angenommen. Bei einer nicht segmentierten oder einer nicht CRC-gesicherten Übertragung vereinfacht sich der Ablauf entsprechend. Sobald der CAN-Controller 4 der ersten CAN-Schnittstelle 3.1 ein empfangenes CAN-Empfangstelegramme Rxl meldet, wird die¬ ses ausgelesen und in den CAN_Rx-Paketspeicher 5 der ersten CAN-Schnittstelle 3.1 geschrieben, der mehrere CAN-Empfangs¬ telegramme Rxl speichern kann.
Liegt mindestens ein CAN-Empfangstelegramm Rxl im CAN_Rx- Paketspeicher 5 der ersten CAN-Schnittstelle 3.1, wird dieses mittels deren CRC-Ergänzungseinheit 6 mit der CRC-Prüfsumme versehen, von dem Netzwerkcontroller 8 in CAN-Sendedatenpa- kete Tx2 segmentiert, die über das Netzwerk 2 als Multicast- Datenpakete an alle anderen CAN-Schnittstellen 3.2 bis 3.n übertragen werden, die logisch demselben CAN-Netzwerk angehören . In jeder das CAN-Telegramm empfangenden CAN-Schnittstelle 3.2 bis 3.n werden die empfangenen CAN-Empfangstelegramme Rx2 dieses CAN-Telegramms zunächst wie oben beschrieben in einen dem sendenden ersten CAN-Segment 1.1 zugeordneten Speicher- platz des CAN_Tx-Paketspeichers 9 geschrieben bis das CAN- Telegramm vollständig empfangen ist. Da für jeden potentiel¬ len Sender in dem CAN_Tx-Paketspeicher 9 wenigstens ein Speicherplatz existiert und jeder Speicherplatz genau ein CAN- Telegram aufnehmen kann, können über das Netzwerk 2 auch mehrere CAN-Segmente 1.1 bis l.n gleichzeitig CAN-Telegramme senden, ohne dass ein Paketverlust auftritt.
Liegt das von der ersten CAN-Schnittstelle 3.1 gesendete CAN- Telegramm vollständig im CAN_Tx-Paketspeicher 9 einer anderen CAN-Schnittstelle 3.2 bis 3.n vor, wird von deren CRC-Überprüfungseinheit 10 die CRC-Prüfsumme des empfangenen CAN- Telegramms überprüft. Wenn die CRC-Überprüfung erfolgreich ist, wie hier angenommen wird, wird das empfangene CAN-Telegramm in den Zwischenspei¬ cher 12 der jeweiligen CAN-Schnittstelle 3.2 bis 3.n geschrieben und von dort über den CAN-Controller 4 in das jeweilige CAN-Segment 1.2 bis l.n eingespeist. Gleichzeitig wird eine positive Quittierung in Form eines Acknowledge-Pa- kets ACK als Unicast-Datenpaket an die erste CAN-Schnittstel¬ le 3.1 zurückgesendet.
Die erste CAN-Schnittstelle 3.1 sammelt und zählt die erhal- tenen Acknowledge-Pakete ACK der anderen CAN-Schnittstel- len 3.2 bis 3.n. Wenn alle n-1 Acknowledge-Pakete ACK innerhalb der Timeout-Zeit eingetroffen sind, wertet die erste CAN-Schnittstelle 3.1 die Übertragung des CAN-Telegramms über das Netzwerk 2 als erfolgreich. Dazu wird die Anzahl n der CAN-Segmente 1.1 bis l.n, die logisch zu dem CAN-Bus 1 zusam¬ mengeschaltet sind, in jeder CAN-Schnittstelle 3.1 bis 3.n bei deren Konfiguration eingetragen, so dass die CAN_Rx-Steu- erung 7 der ersten CAN-Schnittstelle 3.1 die Anzahl der erwarteten Acknowledge-Pakete ACK kennt.
Figur 4 zeigt schematisch einen Ablauf einer Übertragung eines CAN-Telegramms von dem ersten CAN-Segment 1.1 zu den an¬ deren CAN-Segmenten 1.2 bis l.n über das Netzwerk 2 in einem Blockschaltbild, wobei im Unterschied zu der in Figur 3 ge¬ zeigten fehlerfreien Übertragung ein Übertragungsfehler im Netzwerk 2 auftritt. Wiederum werden eine segmentierte Übertragung des CAN-Telegramms und die Sicherung des CAN-Tele- gramms mit einer CRC-Prüfsumme bei der Übertragung über das Netzwerk 2 angenommen.
Die erste CAN-Schnittstelle 3.1 sendet zunächst ein CAN-Tele- gramm wie oben anhand von Figur 3 beschrieben segmentiert über das Netzwerk 2 an alle anderen CAN-Schnittstellen 3.2 bis 3.n desselben logischen CAN-Busses 1.
Es wird nun angenommen, dass ein CAN-Datenpaket des CAN-Tele¬ gramms bei der Übertragung über das Netzwerk 2 zu einer zwei- ten CAN-Schnittstelle 3.2 aufgrund eines Übertragungsfehlers im Netzwerk 2 verloren geht, so dass der zweiten CAN-Schnittstelle 3.2 eines der CAN-Empfangsdatenpakete Rx2 des CAN- Telegramms fehlt. Aufgrund des fehlenden CAN-Empfangsdatenpaketes Rx2 erkennt die CRC-Überprüfung in der zweiten CAN-Schnittstelle 3.2 einen CRC-Fehler und damit eine fehlerhafte Übertragung des CAN-Telegramms. Die CAN_Tx-Steuerung 11 der zweiten CAN- Schnittstelle 3.2 sendet daraufhin kein Acknowledge-Paket ACK an die erste CAN-Schnittstelle 3.1 zurück. Alternativ kann von der zweiten CAN-Schnittstelle 3.2 auch eine negative Bes¬ tätigungsnachricht an die erste CAN-Schnittstelle 3.1 gesen¬ det werden, dass eine fehlerhafte Übertragung anzeigt. Die CAN_Rx-Steuerung 7 der ersten CAN-Schnittstelle 3.1 sammelt wiederum während der Timeout-Zeit die Acknowledge-Pake- te ACK und zählt diese. Da die zweite CAN-Schnittstelle 3.2 kein Acknowledge-Paket ACK oder eine negative Bestätigungs¬ nachricht sendet, stellt die erste CAN-Schnittstelle 3.1 nach der Timeout-Zeit ein fehlendes Acknowledge-Paket ACK fest und erkennt dadurch die fehlerhafte Übertragung des CAN-Tele¬ gramms . Das komplette CAN-Telegramm wird daraufhin von der ersten CAN-Schnittstelle 3.1 erneut über das Netzwerk 2 an alle an¬ deren CAN-Schnittstellen 3.2 bis 3.n desselben logischen CAN- Busses 1 gesendet, wobei die Anzahl von Wiederholungen im Fehlerfall konfigurierbar ist.
Derjenige CAN-Teilnehmer C.l bis Cm im ersten CAN-Segment 1.1, der das CAN-Telegramm ursprünglich gesendet hat, erfährt dabei nichts von einer wiederholten Sendung des CAN-Tele- gramms im Netzwerk 2. Er erfährt auch nicht, wenn alle Wie¬ derholungen fehlschlagen. Dies führt zu einem Telegrammverlust, wie er auch in einem üblichen CAN-Bus vorkommen kann und durch die jeweilige Anwendung abgefangen werden muss. Figur 5 zeigt schematisch einen Ablauf einer Übertragung von CAN-Telegrammen von dem ersten CAN-Segment 1.1 zu den anderen CAN-Segmenten 1.2 bis l.n über das Netzwerk 2 in einem Blockschaltbild, wobei ein Überlauf des Zwischenspeichers 12 der zweiten CAN-Schnittstelle 3.2 auftritt. Wiederum werden eine segmentierte Übertragung der CAN-Telegramme und deren Siche¬ rung mit einer CRC-Prüfsumme bei der Übertragung über das Netzwerk 2 angenommen.
Die erste CAN-Schnittstelle 3.1 sendet CAN-Telegramme wie oben anhand von Figur 3 beschrieben segmentiert über das Netzwerk 2 an alle anderen CAN-Schnittstellen 3.2 bis 3.n desselben logischen CAN-Busses 1.
Die zweite CAN-Schnittstelle 3.2 empfängt die von der ersten CAN-Schnittstelle 3.1 gesendeten CAN-Telegramme und schreibt sie nach erfolgreicher CRC-Überprüfung in ihren Zwischenspeicher 12. Falls in dem Zwischenspeicher 12 mehr CAN-Telegramme auflaufen, als über den nachgeschalteten CAN-Controller 4 an das zweite CAN-Segment 1.2 abgesetzt werden können, läuft der Zwischenspeicher 12 der zweiten CAN-Schnittstelle 3.2 voll.
Bei Überschreiten eines vorgebbaren ersten Füllschwellwertes, der eine Speicherauslastung des Zwischenspeichers 12 angibt, wird von der zweiten CAN-Schnittstelle 3.2 an alle anderen CAN-Schnittstellen 3.1 bis 3.n, die zu demselben logischen CAN-Bus 1 gehören, eine Speicherstatusnachricht Xoff als Mul- ticast-Nachricht gesendet.
Jede CAN-Schnittstelle 3.1 bis 3.n, die diese Xoff-Nachricht empfängt, stellt das Senden weiterer CAN-Telegramme über das Netzwerk 2 ein und hält die aus dem CAN-Controller 4 ausgelesenen CAN-Empfangstelegramme Rxl in ihrem CAN_Rx-Paketspei- eher 5.
Jede CAN-Schnittstelle 3.1 bis 3.n versucht nun ihren Zwi¬ schenspeicher 12 zu leeren, und sendet danach an ihr jeweiliges CAN-Segment 1.1 bis l.n ein Backpressure-Telegramm BP, mit dem das jeweilige CAN-Segment 1.1 bis l.n blockiert wird. Das Backpressure-Kommando funktioniert dabei nur vollständig, wenn der eigene Zwischenspeicher 12 leer ist, da andernfalls weiterhin CAN-Sendetelegramme Txl an das jeweilige CAN-Seg¬ ment 1.1 bis l.n gesendet werden. Deshalb versucht jede CAN- Schnittstelle 3.1 bis 3.n zunächst den Inhalt ihres Zwischen¬ speichers 12 in den CAN-Controller 4 zu schreiben, bevor sie ein Backpressure-Telegramm BP sendet.
Nachdem der erste Füllschwellwert im Zwischenspeicher 12 der zweiten CAN-Schnittstelle 3.2 wieder unterschritten wird, sendet die zweite CAN-Schnittstelle 3.2 eine Speicherstatus¬ nachricht Xon als Multicast-Nachtricht über das Netzwerk 2 an alle anderen CAN-Schnittstellen 3.1 bis 3.n desselben logischen CAN-Busses 1 und gibt damit die Übertragung von CAN- Telegrammen im Netzwerk 2 wieder frei. Der Überlauf eines Zwischenspeichers 12 führt daher zur zeitweiligen Blockade des gesamten logischen CAN-Busses 1.
In einer bevorzugten Ausgestaltung des Ausführungsbeispiels führen die CAN_Rx-Steuerungen 7 aller CAN-Schnittstellen 3.1 bis 3.n jeweils eine Liste mit dem Xon / Xoff-Status aller anderen CAN-Schnittstellen 3.1 bis 3.n. Die CAN_Rx-Steuerungen 7 der CAN-Schnittstellen 3.1 bis 3.n übertragen ferner vorzugsweise jeweils zyklisch ihren eigenen Xon / Xoff-Status zusätzlich zu den aktuellen Änderungen. Auf diese Weise können eventuelle Paketverluste dieser Kommandos vorteilhaft kompensiert werden.
Ein Backpressure-Telegramm BP wird von einer CAN-Schnittstel- le 3.1 bis 3.n auch dann an ihr jeweiliges CAN-Segment 1.1 bis l.n ausgegeben, wenn die Speicherauslastung des eigenen CAN_Rx-Paketspeichers 5 einen zweiten vorgebbaren Füll¬ schwellwert überschreitet. Dadurch wird im Regelfall vorteil¬ haft verhindert, dass im zugehörigen CAN-Segment 1.1 bis l.n weiterhin CAN-Telegramme erzeugt werden und der CAN_Rx-Paket- speicher 5 überläuft.
Anhand von Figur 4 wurde oben beschrieben, wie Übertragungs¬ fehler durch Paketverlust bei der Übertragung über das Netzwerk 2 erkannt und korrigiert werden. Es wird nun beschrie¬ ben, wie Übertragungsfehler bei Paketverlust in einem CAN- Segment 1.1 bis l.n behandelt werden.
Tritt beim Senden eines CAN-Teilnehmers C.l bis Cm in einem CAN-Segment 1.1 bis l.n ein derartiger Übertragungsfehler auf, so wird dieser von den anderen normkonformen CAN-Teil- nehmern C.l bis Cm in dem CAN-Segment 1.1 bis l.n erkannt und dem Sender signalisiert. Dieser führt dann ein erneutes Senden durch.
Auch hierbei tritt also eine CAN-Telegrammverdoppelung auf. Diese tritt jedoch auch bei üblichen CAN-Netzwerken auf. Das Netzwerk 2 wird erst eingesetzt, wenn die CAN-Schnittstel- le 3.1 bis 3.n des jeweiligen CAN-Segmentes 1.1 bis l.n aus diesem ein gültiges CAN-Telegramm empfängt. Fehlerhafte CAN- Telegramme werden bereits im CAN-Controller 4 erkannt und nicht weitergeleitet. Die Mechanismen für die Arbitrierung des CAN-Busses 1 für CAN-Telegramme hoher Priorität bleiben innerhalb jedes CAN- Segmentes 1.1 bis l.n voll erhalten. Tritt beim Senden des CAN-Controllers 4 einer CAN-Schnitt- stelle 3.1 bis 3.n in das zugehörige CAN-Segment 1.1 bis l.n ein Fehler auf, so wird dieser von den normkonformen CAN- Teilnehmern C.l bis Cm des betreffenden CAN-Segmentes 1.1 bis l.n erkannt und dem CAN-Controller 4 signalisiert. Der CAN-Controller 4 sendet das CAN-Telegramm dann erneut bis es korrekt erkannt wird.

Claims

Patentansprüche
1. Verfahren zur Datenübertragung mit einem CAN-Bus (1), bei dem der CAN-Bus (1) in wenigstens zwei CAN-Segmente (1.1 bis l.n) aufgeteilt wird und die CAN-Segmente (1.1 bis l.n) des CAN-Busses (1) durch ein paketorientiertes Netzwerk (2) logisch miteinander verbunden werden, wobei CAN-Telegramme mittels des Netzwerkes (2) zwischen CAN-Segmenten (1.1 bis l.n) übertragen werden und die Übertragung der CAN-Telegramme über das Netzwerk (2) auf Fehlerfreiheit geprüft sowie ein erkannter Übertragungsfehler korrigiert wird, indem ein von einem sendenden CAN-Segment (1.1 bis l.n) gesendetes und feh¬ lerhaft übertragenes CAN-Telegramm von diesem CAN-Segment (1.1 bis l.n) erneut über das Netzwerk (2) gesendet wird, dadurch gekennzeichnet, dass jedes CAN-Segment (1.1 bis l.n) über jeweils eine zugehörige CAN-Schnittstelle (3.1 bis 3.n) an das Netzwerk (2) gekoppelt wird und das Senden von CAN- Telegrammen aus einem CAN-Segment (1.1 bis l.n) über das Netzwerk (2) und das Empfangen von CAN-Telegrammen aus dem Netzwerk (2) mittels der zugehörigen CAN-Schnittstelle (3.1 bis 3.n) durchgeführt wird, und dass Übertragungsfehler bei der Übertragung von CAN-Telegrammen über das Netzwerk (2) folgendermaßen erkannt und korrigiert werden:
das CAN-Telegramm wird mittels einer sendenden CAN- Schnittstelle (3.1 bis 3.n) an alle anderen CAN-Schnitt- stellen (3.1 bis 3.n) gesendet;
wenn mittels einer CAN-Schnittstelle (3.1 bis 3.n) ein CAN-Telegramm aus dem Netzwerk (2) empfangen und dessen Übertragung als fehlerfrei eingestuft wird, wird von die- ser CAN-Schnittstelle (3.1 bis 3.n) über das Netzwerk (2) eine positive Bestätigungsnachricht (ACK) an die sendende CAN-Schnittstelle (3.1 bis 3.n) gesendet;
mittels der sendenden CAN-Schnittstelle (3.1 bis 3.n) wird das CAN-Telegramm erneut über das Netzwerk (2) an alle an- deren CAN-Schnittstellen (3.1 bis 3.n) gesendet, wenn die sendende CAN-Schnittstelle (3.1 bis 3.n) von wenigstens einer der anderen CAN-Schnittstellen (3.1 bis 3.n) inner- halb einer vorgebbaren Timeout-Zeit keine positive Bestä¬ tigungsnachricht (ACK) empfängt.
2. Verfahren nach Anspruch 1,
dadurch gekennzeichnet, dass für jede CAN-Schnittstelle (3.1 bis 3.n), mittels derer über das Netzwerk (2) ein CAN-Tele- gramm empfangen wird, überprüft wird, ob das empfangene CAN- Telegramm fehlerfrei übertragen wurde. 3. Verfahren nach Anspruch 2,
dadurch gekennzeichnet, dass zur Überprüfung der fehlerfreien Übertragung eines CAN-Telegramms über das Netzwerk (2) eine CRC-Prüfsumme verwendet wird, die dem CAN-Telegramm vor des¬ sen Sendung über das Netzwerk (2) mittels der CAN-Schnitt- stelle (3.1 bis 3.n) des sendenden CAN-Segmentes (1.1 bis l.n) hinzugefügt wird und die von jeder ein CAN-Telegramm über das Netzwerk (2) empfangenden CAN-Schnittstelle (3.1 bis
3. n) überprüft wird.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein von einer CAN-Schnittstel¬ le (3.1 bis 3.n) aus dem Netzwerk (2) empfangenes CAN-Tele¬ gramm nur dann mittels dieser CAN-Schnittstelle (3.1 bis 3.n) dem zugehörigen CAN-Segment (1.1 bis l.n) übergeben wird, wenn die Übertragung des CAN-Telegramms als fehlerfrei einge¬ stuft wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ein von einer CAN-Schnittstel- le (3.1 bis 3.n) über das Netzwerk (2) empfangenes CAN-Tele¬ gramm in einem Zwischenspeicher (12) der CAN-Schnittstelle (3.1 bis 3.n) zwischengespeichert wird, bevor es von der CAN-Schnittstelle (3.1 bis 3.n) an das zugehörige CAN-Seg¬ ment (1.1 bis l.n) weitergeleitet wird.
6. Verfahren nach Anspruch 5,
dadurch gekennzeichnet, dass von einer CAN-Schnittstelle (3.1 bis 3.n) an alle anderen CAN-Schnittstellen (3.1 bis 3.n) ei- ne entsprechende Speicherstatusnachricht gesendet wird, so¬ bald die Speicherauslastung ihres Zwischenspeichers (12) ei¬ nen vorgebbaren ersten Füllschwellwert überschreitet oder un¬ terschreitet .
7. Verfahren nach Anspruch 5 oder 6,
dadurch gekennzeichnet, dass von jeder CAN-Schnittstelle (3.1 bis 3.n) zyklisch in vorgebbaren Zeitabständen an alle anderen CAN-Schnittstellen (3.1 bis 3.n) eine Speicherstatusnach- rieht darüber gesendet wird, ob eine aktuelle Speicherauslas¬ tung des Zwischenspeichers (12) der jeweiligen CAN-Schnitt¬ stelle (3.1 bis 3.n) einen ersten Füllschwellwert überschrei¬ tet .
8. Verfahren nach Anspruch 6 oder 7,
dadurch gekennzeichnet, dass von jeder CAN-Schnittstelle (3.1 bis 3.n) anhand der von ihr empfangenen Speicherstatusnachrichten die aktuellen Speicherauslastungen der Zwischenspeicher (12) aller anderen CAN-Schnittstellen (3.1 bis 3.n) überwacht und CAN-Telegramme nur dann versendet werden, wenn die Speicherauslastungen der Zwischenspeicher (12) aller anderen CAN-Schnittstellen (3.1 bis 3.n) den ersten Füllschwellwert unterschreiten.
9. Vorrichtung zur Datenübertragung mit einem in wenigstens zwei CAN-Segmente (1.1 bis l.n) aufgeteilten CAN-Bus (1) und einem paketorientierten Netzwerk (2), das die CAN-Segmente (1.1 bis l.n) logisch derart miteinander verbindet, dass von jedem CAN-Segment (1.1 bis l.n) ein CAN-Telegramm mittels des Netzwerkes (2) sowohl zu allen anderen CAN-Segmenten (1.1 bis l.n) als auch gezielt zu einem auswählbaren anderen CAN- Segment (1.1 bis l.n) sendbar ist
gekennzeichnet durch jeweils eine CAN-Schnittstelle (3.1 bis 3.n) für jedes CAN-Segment (1.1 bis l.n) zu dessen Ankopplung an das Netzwerk (2) und zur Steuerung des Sendens von CAN-
Telegrammen aus dem CAN-Segment (1.1 bis l.n) über das Netzwerk (2) und des Empfangens von CAN-Telegrammen aus dem Netzwerk (2), wobei jede CAN-Schnittstelle (3.1 bis 3.n) einen Zwischenspeicher (12) zum Speichern aus dem Netzwerk (2) empfangener CAN-Telegramme aufweist.
PCT/EP2010/065861 2009-10-27 2010-10-21 Verfahren und vorrichtung zur datenübertragung WO2011051157A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102009050767.1 2009-10-27
DE102009050767.1A DE102009050767B4 (de) 2009-10-27 2009-10-27 Verfahren und Vorrichtung zur Datenübertragung

Publications (1)

Publication Number Publication Date
WO2011051157A1 true WO2011051157A1 (de) 2011-05-05

Family

ID=43302405

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2010/065861 WO2011051157A1 (de) 2009-10-27 2010-10-21 Verfahren und vorrichtung zur datenübertragung

Country Status (2)

Country Link
DE (1) DE102009050767B4 (de)
WO (1) WO2011051157A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019123458A1 (en) * 2017-12-24 2019-06-27 Technion Research & Development Foundation Limited Message authentication based on a physical location on a bus
DE102020212452B3 (de) 2020-10-01 2022-01-13 Volkswagen Aktiengesellschaft Verfahren zur Reduzierung der Auswirkungen von einer auf einem Kommunikationsbus eingeschleusten Botschaft
CN114051702A (zh) * 2019-09-24 2022-02-15 倍福自动化有限公司 运行通信网络的方法、通信网络和用于通信网络的用户

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016219475A1 (de) 2016-10-07 2018-04-12 Robert Bosch Gmbh Verfahren und Vorrichtung zum Betreiben eines Bussystems

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001045348A2 (en) * 1999-12-14 2001-06-21 Schneider Automation Inc. Bridge for can to tcp/ip connection
US20060083250A1 (en) * 2004-10-15 2006-04-20 Jordan Patrick D System and method for tunneling standard bus protocol messages through an automotive switch fabric network
US20060112204A1 (en) * 2004-11-24 2006-05-25 Yann Casteignau Method for making a network formed by can type buses, a network and an apparatus having the network
DE102005008503B3 (de) 2005-02-24 2006-06-29 Siemens Ag Verfahren und Netzwerk zur Daten- und Signalübertragung

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19514696B4 (de) * 1994-04-18 2006-03-09 Kvaser Consultant Ab System zur Beseitigung von Störungen bzw. zur Ermöglichung einer Hochgeschwindigkeitsübertragung in einer seriellen Bus-Schaltung sowie mit letzterer verbundene Sende- und Empfangsgeräte
GB2385752B (en) * 2002-02-20 2004-06-16 Motorola Inc Information communication controller interface apparatus and method
JP4292795B2 (ja) * 2002-12-13 2009-07-08 富士フイルム株式会社 カメラ付き携帯端末
US20050220131A1 (en) * 2004-03-31 2005-10-06 Boris Ginzburg Method and apparatus to multicast transmission

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001045348A2 (en) * 1999-12-14 2001-06-21 Schneider Automation Inc. Bridge for can to tcp/ip connection
US20060083250A1 (en) * 2004-10-15 2006-04-20 Jordan Patrick D System and method for tunneling standard bus protocol messages through an automotive switch fabric network
US20060112204A1 (en) * 2004-11-24 2006-05-25 Yann Casteignau Method for making a network formed by can type buses, a network and an apparatus having the network
DE102005008503B3 (de) 2005-02-24 2006-06-29 Siemens Ag Verfahren und Netzwerk zur Daten- und Signalübertragung

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ERTURK I: "A new method for transferring CAN messages using wireless ATM", JOURNAL OF NETWORK AND COMPUTER APPLICATIONS, ACADEMIC PRESS, NEW YORK, NY, US, vol. 28, no. 1, 1 January 2005 (2005-01-01), pages 45 - 56, XP004606435, ISSN: 1084-8045, DOI: DOI:10.1016/J.JNCA.2004.04.001 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019123458A1 (en) * 2017-12-24 2019-06-27 Technion Research & Development Foundation Limited Message authentication based on a physical location on a bus
US11245550B2 (en) 2017-12-24 2022-02-08 Technion Research & Development Foundation Limited Message authentication based on a physical location on a bus
CN114051702A (zh) * 2019-09-24 2022-02-15 倍福自动化有限公司 运行通信网络的方法、通信网络和用于通信网络的用户
DE102020212452B3 (de) 2020-10-01 2022-01-13 Volkswagen Aktiengesellschaft Verfahren zur Reduzierung der Auswirkungen von einer auf einem Kommunikationsbus eingeschleusten Botschaft

Also Published As

Publication number Publication date
DE102009050767A1 (de) 2011-05-05
DE102009050767B4 (de) 2017-06-14

Similar Documents

Publication Publication Date Title
DE69636382T2 (de) Vollduplexflusssteuerung für Ethernet-Netze
EP3210325B1 (de) Verfahren zur rekonstruktion eines in einem drahtlosen sensornetzwerk fehlerhaft empfangenen datenpakets
DE69533951T2 (de) Protokoll für asynchrone Zeitvielfachvermittlung
DE19954377A1 (de) Datenübertragungssystem für Luftfahrzeuge
EP2586162A1 (de) Priorisierte übertragung von datentelegrammen
EP2297902A1 (de) Protokollbeschleunigermodul mit paketweiterleitungsfunktion und betriebsverfahren für einen senderempfänger zur schnellen weiterleitung von datenpaketen
EP2137893A1 (de) Paketvermittlungsvorrichtung und lokales kommunikationsnetz mit einer solchen paketvermittlungsvorrichtung
WO2021037837A1 (de) Übertragung von datenpaketen
WO2011051157A1 (de) Verfahren und vorrichtung zur datenübertragung
EP3977683B1 (de) Einrichtung für eine teilnehmerstation eines seriellen bussystems und verfahren zur kommunikation in einem seriellen bussystem
EP2915289A1 (de) Repeater, can-kommunikationssystem und verfahren zur übertragung eines datentelegramms innerhalb eines can-kommunikationssystems
DE102010064582B3 (de) Proxy-Knoten einsetzende Übertragungswiederholungsprotokolle für ein Netz
EP3895384A1 (de) Überlagerungserfassungseinheit für eine teilnehmerstation eines seriellen bussystems und verfahren zur kommunikation in einem seriellen bussystem
WO2017036508A1 (de) Kommunikationsgerät für ein redundant betreibbares industrielles kommunikationsnetz und verfahren zum betrieb eines kommunikationsgeräts
EP4029202A1 (de) Teilnehmerstation für ein serielles bussystem und verfahren zur kommunikation in einem seriellen bussystem
WO2021004835A1 (de) Verfahren und datennetzwerk zum kommunizieren von dateninhalten, insbesondere in einer aufzuganlage
EP2865120B1 (de) Datenpaket für eine bidirektionale übertragung von datenpaketen bei einer datenübertragung zwischen einem ersten und einem zweiten kommunikationsgerät sowie verfahren zum übertragen eines solchen datenpaketes
EP1886433A1 (de) Redundante übertragung von datentelegrammen für die leittechnik von hgü-systemen
DE19911951C2 (de) Datenkommunikationssystem und Datenkommunikationsverfahren, welches eine Nachrichtenkollision umgehen kann
DE112009000087B4 (de) Fahrzeug-Weiterleitungs-Verbindungseinheit
US20130191501A1 (en) Procedures for the Transfer of User Data
DE102005003016B4 (de) Verfahren und Vorrichtungen zur Datenübertragung
WO2020088999A1 (de) Teilnehmerstation für ein serielles bussystem und verfahren zum senden einer nachricht in einem seriellen bussystem
EP1400063A2 (de) Fehlertoleranter verbindungstest
EP1527547B1 (de) Verfahren und vorrichtung zur überwachung einer daten übertragung

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10778890

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10778890

Country of ref document: EP

Kind code of ref document: A1