EP4635151A1 - Verfahren zum testen eines kommunikationsbusses - Google Patents

Verfahren zum testen eines kommunikationsbusses

Info

Publication number
EP4635151A1
EP4635151A1 EP23828343.6A EP23828343A EP4635151A1 EP 4635151 A1 EP4635151 A1 EP 4635151A1 EP 23828343 A EP23828343 A EP 23828343A EP 4635151 A1 EP4635151 A1 EP 4635151A1
Authority
EP
European Patent Office
Prior art keywords
data
transmission cycle
network device
transmission
communication medium
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23828343.6A
Other languages
English (en)
French (fr)
Inventor
Helge ZINNER
Daniel HOPF
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.)
Aumovio Germany GmbH
Original Assignee
Continental Automotive Technologies GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Continental Automotive Technologies GmbH filed Critical Continental Automotive Technologies GmbH
Publication of EP4635151A1 publication Critical patent/EP4635151A1/de
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0888—Throughput
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/407—Bus networks with decentralised control
    • H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0894—Packet rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements

Definitions

  • the present invention relates to communication over a communication medium shared by multiple network devices, in particular to monitoring the integrity of the communication.
  • communication medium is used to refer to wireless, wired or other media-based transmission media, i.e. synonymously to acoustic signals, light waves, radio waves or electrical signals transmitted via electrical conductors, unless the context necessarily requires a specification of one of these communication media.
  • IP Internet Protocol
  • Each of these subsystems uses its own hardware interface with different EMC behavior and uses different software stacks.
  • a consistently Ethernet-based network architecture offers many advantages because it always works with the same protocol regardless of the physical layer.
  • a data frame always looks the same regardless of whether it is transmitted at 10 Mbit/s or 10 Gbit/s. Scaling the bandwidth for specific applications does not require complex gateways.
  • a single switch can often be equipped with the appropriate interfaces that enable communication at different speeds. The data frames can then switch from one domain to another without modifying the data by buffering it accordingly.
  • an electrical Ethernet connection that is implemented as a point-to-point connection between two network devices or a network device and a switch with one line requires a dedicated physical interface at each end of the line, generally referred to as a PHY, which is responsible for encoding and decoding data between the digital side of the system and a propagation or transmission medium.
  • a switch requires a separate PHY for each network device connected to it, so that a large number of connections are required in a network.
  • An example system 10 with four network devices 12, 14, 18, and 20 connected via a switch 16 is shown in Figure 1. A total of 8 physical interfaces are required for the four point-to-point connections so that all five network devices can communicate with each other.
  • Ethernet systems are known in which a bus topology is used (10BASE2, 10BASE5).
  • a coaxial cable 22 connects the five network devices 12, 14, 16, 18 and 20.
  • Each of the network devices 12, 14, 16, 18 and 20 is connected to the coaxial cable 22 via a spur line and a connection box 12a, 14a, 16a, 18a and 20a.
  • the outer conductor of the coaxial cable 22 is interrupted at certain points in the connection boxes 12a, 14a, 16a, 18a and 20a, and a contact pin is inserted into the connection box 12a, 14a, 16a, 18a and 20a.
  • 10BASE-T1 S One of the variants specified under this IEEE standard is called 10BASE-T1 S, where the S stands for Short Reach, and can use a multidrop or bus topology in which all nodes are connected via a single two-wire twisted pair cable. This eliminates the need for switches, i.e. the number of physical interfaces is smaller than in a system with one switch, and no coaxial cable is required. Connecting spur lines to a twisted pair cable can also be implemented passively, easily and inexpensively.
  • a long-range variant - called 10BASE-T1 L (L for Long Reach) - has been defined for distances of up to 1 km. The long-reach variant uses point-to-point connections.
  • At least eight network devices can be connected to one another via a 10BASE-T1 S bus system, with the maximum bus length being 25 m.
  • the individual network devices can be connected to the bus line using spur lines that are no more than 10 cm long. All nodes share the bandwidth of 10 Mbit/s.
  • Figure 3 shows a corresponding example of a 10BASE-T 1 S network with five network devices 12, 14, 16, 18, 20 connected via a shared communication medium 24, e.g. a bus line formed by a twisted pair of wires.
  • the dashed line indicates the logical connections between the network devices, the solid line indicates the physical connections.
  • the standard specifies an arbitration scheme that enables full utilization of the available bandwidth with reduced latency and high Quality of Service (QoS).
  • QoS Quality of Service
  • One of the possible arbitration schemes is known as Physical Layer Collision Avoidance - PLCA
  • another arbitration scheme known as Carrier Sense Multiple Access/Collision Detection - CSMA/CD
  • the CSMA/CD access method allows every network device to access the network and send data as soon as no other network device is sending data.
  • a regulation that ensures that each of the network devices in a network has the opportunity to send data within a specified period of time is not included in the CSMA/CD access method and must be implemented at a higher protocol level.
  • the PLCA access method is conceptually similar to a token ring method or TDMA (Time Division Multiple Access).
  • each network device is configured with a node ID, and the network device with node ID 0 is designated as the PLCA coordinator.
  • the coordinator initiates a communication cycle by sending an agreed sequence of data bits or octets, also called a beacon message or a beacon frame.
  • the other nodes use this beacon message to coordinate their clocks.
  • beacon message and beacon frame are used synonymously in this description.
  • each network device In order to determine when it is allowed to send data in the PLCA access procedure, each network device "listens" on the bus line and waits until the network device with a node ID one lower than its own completes the transmission. After each transmission process by a network device, which can be marked as completed by an agreed sequence of data bits or octets at the end of a transmission, there follows a period known as the transmit opportunity or TO time window.
  • the TO time window can be 20 bits long, for example, i.e. it can correspond to a period of time within which 20 bits can be sent at the nominal data rate of the data bus.
  • the network device whose node ID is one higher than that of the network device that has just completed its transmission can begin transmission.
  • Each node can send all of its data, although each network device typically only sends one frame. However, a network device can send several consecutive data frames in what is known as burst mode, with commit messages sent between the respective data frames marking the communication medium as still occupied by the network device currently sending. If a network device does not send and allows the TO time window reserved for it to expire, another TO time window follows for the next network device. In this way, even in a cycle in which not all network devices are sending, the coordinator can determine or assume the end of the cycle and start a new cycle.
  • the PLCA coordinator After the last network device has received and, if necessary, used the opportunity to transmit data, the PLCA coordinator initiates the next cycle with another beacon message.
  • Access using PLCA achieves a higher throughput than TDMA or Token Ring because the network devices do not have to split their messages into multiple time slots.
  • the transmit opportunity phase with its 20 bits is shorter than a token packet. Since the participants on the bus may or may not take advantage of their opportunity to transmit, the duration of a complete transmission cycle cannot be determined exactly in advance.
  • FIG 4. An example of the messages sent by network devices in the order of their node IDs over the shared communication medium is shown in Figure 4.
  • the start of a transmission cycle is initiated with a corresponding bit sequence B, also known as a beacon.
  • a TO time window within which the network device with the lowest node ID can start sending its message, in this case the node ID with the value 0, which also sent the beacon bit sequence.
  • the TO time window is hatched in the figure.
  • the end of transmission by a network device is followed by the T0 time window for the next network device.
  • the network device that is allowed to transmit can start transmitting immediately at the beginning of the TO time window or at any time within the TO time window.
  • the TO time window can be started, for example, by a signal representing the end of a transmission by a network device.
  • This signal can be, for example, an end-of-frame signal (EOF).
  • EEF end-of-frame signal
  • the end of a TO time window can be determined by a counter or timer.
  • the end of the TO time window is reached when the network device that is allowed to transmit has not started a transmission during an agreed time, corresponding to an agreed number of data bits sent at the nominal data rate of the shared communication medium.
  • SOF start-of-frame signal
  • the counter for the TO time window can be stopped. This process repeats until the last network device has sent its message or allowed its TO time window to expire.
  • a new beacon bit sequence is then sent, which begins a new transmission cycle.
  • the length or duration of each transmission cycle is determined by the length of the beacon bit sequence, the length of the messages sent by the network devices, or the TO time windows that are completely or partially unused, and can vary from transmission cycle to transmission cycle.
  • FIG. 6 An example representation of the error in the sequence of messages sent by the network devices in the order of their node IDs over the shared communication medium is shown in Figure 6.
  • the representation essentially corresponds to the representation in Figure 4, except that the message from Node 2 is disturbed.
  • This disturbance can consist, for example, in Node 2 not sending at all, sending incompletely, or sending random bit sequences due to a disturbance in the connection between the processor and the network interface.
  • Such an error is not recognizable at the access control level in normal operation and would have to be recognized at higher protocol levels.
  • the individual network devices provide little computing power and memory and also have to be particularly cost-effective, such capabilities cannot always be available.
  • Figure 7 shows the network from Figure 3 with an error affecting the bus line 24, for example a temporary disturbance triggered by an electromagnetic interference pulse.
  • the physical connection between the network interface and the bus line 24 is not disturbed.
  • the disturbance is shown as local in the figure, it occurs at all interfaces almost simultaneously due to the short length and low attenuation of the bus line and thus disturbs the correct reception of data bits or octets of a message, for example by changing a signal level in such a way that the value of one or more data bits is changed, or by a voltage level being applied to the receivers of the interfaces which overrides them.
  • An example representation of the error in the sequence of messages sent by the network devices in the order of their node IDs over the shared communication medium is shown in Figure 8.
  • the representation essentially corresponds to the representation in Figure 4, except that in the exemplary representation in Figure 8 the beacon bit sequence is disturbed, for example by an electrical or electromagnetic interference pulse at the time when the Coordinator has sent the beacon bit sequence.
  • the network devices with node IDs greater than 0 cannot therefore recognize the start of a new transmission cycle and will not send their messages.
  • the coordinator will therefore only recognize TO time slots that are not being used by the other network devices and will begin a new transmission cycle when the number of elapsed, unused TO time slots corresponds to the number of network devices connected via the shared communication medium.
  • the transmission cycle x+1 shown in Figure 8 is very short, but for the other network devices, the transmission cycle x is longer than for the coordinator.
  • Such a change cannot be reliably recognized on OSI layers 1 and 2 of the communication connection during normal operation and would have to be recognized and, if necessary, corrected at higher protocol levels, as in the error example described with reference to Figure 5.
  • a network of the type described above in which a large number of network devices are connected to one another via a shared communication medium, is used in a system that places high demands on the reliability and security of communication, e.g. in a system with several network devices that communicate with one another in connection with partially or highly automated driving, frequent, ideally continuous, integrity checks of the communication are essential.
  • the term network device includes all possible types of network devices, including networked sensors and network devices that process signals from networked sensors.
  • a method for monitoring the integrity of communication between a plurality of network devices connected via a shared communication medium which can each send a message via the shared communication medium within a transmission cycle initiated and terminated by a first network device, also referred to as a coordinator, comprises listening to at least certain parts of the communication on the communication medium within the transmission cycle.
  • the message sent by the respective network device can have any length, ie comprise one or more Ethernet frames, whereby the length of the or the Ethernet frames can be between 64 and 1518 bytes. Sending so-called jumbo frames with a longer length is also possible in principle, although in this case all of the network devices connected via the communication medium must support these jumbo frames. If a network device sends several consecutive frames, which is also known as burst mode, the network device can send a commit signal after a sent frame to signal to the other network devices that another frame is following.
  • the start of a transmission cycle is marked by a sequence of data bits.
  • the end of a transmission cycle can be represented, for example, by a sequence of data bits that mark the start of a subsequent transmission cycle.
  • the end of a transmission cycle can also be represented by a sequence of data bits that mark the end of the transmission of the last network device. The latter may require that all network devices that carry out the process know at least the number of network devices in the network, for example through appropriate parameterization or through independent learning during operation.
  • Listening accordingly includes at least the detection and/or evaluation of data bits or sequences of data bits that mark the beginning and end of a transmission cycle, and of data bits or sequences of data bits or octets that mark the beginning and end of a transmission by a network device.
  • the start of a transmission by a network device can already be recognized by the fact that a first data bit is sent within a TO time window.
  • the protocol used can ensure that only a network device that is actually currently sending is sending.
  • Listening also includes the detection and/or evaluation of a transmission option not used by a network device within a transmission cycle. If at least one of the network devices in the network transmits messages in burst mode, listening also includes the detection and/or evaluation of sequences of data bits that represent commit signals.
  • Network devices that also send messages in burst mode can do this, for example, when initializing the network. or, if the number and type of network devices of the system using the network is known from the outset and remains unchanged, a corresponding configuration can be made in advance in the network devices.
  • Each network device in the network is assigned a unique node ID, usually a number within an interval starting with 0 and ending with the number n of network devices in the network.
  • the network device with the lowest node ID i.e. node ID 0
  • the network device with the lowest node ID is the first network device, i.e. the coordinator, which initiates the transmission cycle and is also the first to transmit its data.
  • Each network device implements a node ID counter, which is reset to 0 at the beginning of each transmission cycle.
  • the node ID counter can be a simple counter implemented in software.
  • a network device does not necessarily have to send within a transmission cycle.
  • the detection and evaluation of a transmission option not used by a network device can therefore include, for example, the detection and evaluation of a TO time window.
  • a TO time window has a predetermined period of time, e.g. the period that would have been required to transmit a predetermined number of data bits at the nominal data rate of the shared communication medium.
  • a TO time window follows the end of a transmission, e.g. a sequence of data bits representing the end of a data frame. As soon as no data bits are detected during the entire duration of a TO time window, i.e.
  • each network device increases the node ID counter and waits during a new TO time window to see whether data bits are received, or sends its own data bits. Transmission over the communication medium if the value of the node ID counter corresponds to its node ID.
  • a network device can also send a commit message during the TO time window if, for example, the network device is not yet ready to send the message but will be shortly. In this case, the other network devices wait beyond the end of the TO time window until the network device that sent the commit signal has sent its message. In the following TO time window, the next network device whose node ID matches the counter value can then send.
  • the method also comprises determining the duration of a transmission cycle.
  • the duration of a transmission cycle can be determined, for example, by measuring the time elapsed between two consecutive sequences of data bits identifying the start of a transmission cycle. If the end of a transmission cycle is signaled by a sequence of data bits that marks the end of the transmission of the last network device, the time elapsed between the start of the transmission cycle and this sequence can be measured. Since the length of the transmission cycles can vary depending on the number of network devices that actually transmit data and the number of data bits or octets sent by each network device, the duration of each individual transmission cycle is determined individually.
  • the amount of data transmitted within the transmission cycle is determined, and the amount of data expected within the transmission cycle is calculated.
  • the determined amount of data is then compared with the calculated amount of data.
  • a data rate can be determined from the measured duration of the transmission cycle and the amount of data transmitted via the communication medium during the transmission cycle, which is compared with a nominal data rate of the network. If the determined and calculated amount of data or the determined and nominal data rate match within a tolerance window, the method is repeated for a subsequent transmission cycle. Otherwise, at least one of the network devices that carried out the method goes into error mode. In error mode, a network device can take different measures depending on the type and severity of the error.
  • information relating to the error can be stored locally in the network device, in an audit-proof storage device that is communicatively connected to the network device, and/or in a cloud.
  • the log level i.e. the amount of data and level of detail of the information stored, can also be tightened on a case-by-case basis so that additional data is available for troubleshooting.
  • the network device can stop its own communication via the shared communication medium, or the network device with the lowest node ID, which has the role of coordinator, can be notified so that it can prevent further communication on the data bus if necessary.
  • CSMA/CD Carrier-Sense Multiple Access/Collision Detection
  • communication no longer takes place in cycles initiated by a coordinator, and no beacon frames are sent. Instead, all network devices listen for possible communication on the communication medium and try to send if no other network device is currently sending. If collisions occur, the network devices wait a certain amount of time with randomly generated waiting times before they try to send again.
  • the method is carried out for each transmission cycle, continuous or quasi-continuous monitoring of the integrity of the communication is possible.
  • the new transmission cycle is already monitored and the amount of data transmitted in the new transmission cycle is started to be determined, while the expected amount of data for the previous cycle is calculated and the determined and expected amount of data for the completed transmission cycle are compared.
  • random monitoring may also be sufficient, which is carried out cyclically on a regular basis or at irregular intervals.
  • the method can also be carried out over several transmission cycles, i.e. the determination of the amount of data transmitted and the calculation of the expected amount of data can take place over several transmission cycles.
  • the method can also be carried out for a shorter period of time than one transmission cycle, even over parts of two consecutive transmission cycles. It would be possible, for example, to monitor the integrity of the communication for only a selection of network devices. In this case, the "shortened transmission cycle" could be determined using the node ID counter. In principle, it is therefore possible to start and end the determination of the amount of data transmitted within a transmission cycle, or to start within a first transmission cycle and end it within a subsequent transmission cycle, i.e. not necessarily at the beginning and at the end.
  • determining a data volume or data rate transmitted within a transmission cycle includes counting all data bits or octets transmitted via the communication medium within a transmission cycle, possibly including those transmitted by a network device carrying out the method itself, provided that it sends a message within the transmission cycle. This embodiment could be used, for example, on layer 1 of the OSI layer model if the network device carrying out the method is not set up to evaluate the communication on a higher layer of the OSI layer model.
  • determining an amount of data transmitted within a transmission cycle or the data rate comprises detecting the start and end of a transmission of a network device.
  • the amount of data sent by a respective network device can be calculated by multiplying the time period between the start and end of the transmission by the nominal data rate of the shared communication medium.
  • the calculated data amounts of all network devices that have transmitted during a transmission cycle are summed up.
  • determining a data volume or data rate transmitted within a transmission cycle comprises evaluating information contained in transmissions of a transmission cycle about the number of data bits or octets transmitted in the respective transmission, possibly including those transmitted by a network device carrying out the method itself, provided that it sends a message within the transmission cycle.
  • the number of data bits or octets can be corrected by the data bits or octets required for the communication protocol, including the number of data bits or octets that are sent to initiate and possibly to end a transmission cycle.
  • the network interface of a device using the method executing network device is put into a special operating mode in which the contents of transmissions not sent to the network device are also evaluated.
  • This operating mode is also known as "promiscuous mode”. Determining the number of data bits or octets transmitted can then include evaluating information transmitted in higher protocol layers about the amount of data sent in a transmission.
  • the method used to determine the amount of data transmitted within a transmission cycle or the data rate or the type of data recorded for this purpose can be selected, for example, depending on the number of network devices connected to one another via the shared communication medium, the maximum duration of the TO time window and/or the duration of the sequence of data bits or octets characterizing the start and end of the transmission cycle.
  • one method may dispense with explicitly recording one or more signal components, for example the sequence of data bits or octets characterizing the start and end of a transmission cycle, the duration of unused TO time windows or commit signals, while another method explicitly records one or more of these signal components.
  • determining a data volume or data rate transmitted within a transmission cycle comprises replacing a period of a TO time window or a the transmission opportunity not used by a network device by the number of data bits or octets that could be transmitted during the elapsed time period or the duration of a TO time window.
  • the number of bits that could theoretically have been sent before the network device actually started transmitting or the number of data bits or octets that could be transmitted during a TO time window can be calculated, for example, from the nominal transmission speed of the shared communication medium and the elapsed time.
  • This number can also correspond to a predetermined number of data bits that is taken into account as a representative of the unused transmission opportunity for determining the amount of data transmitted within a transmission cycle, because no data bits or octets are sent during an unused TO time window.
  • the node IDs are permanently assigned to the network devices before or when the system is put into operation.
  • the node IDs it is also possible for the node IDs to be reassigned during operation, for example cyclically at fixed time intervals, in order to allow access to new network devices that have been added to the network, or in order to maintain a continuous series of node IDs, for example if a network device has been removed from the network.
  • the latter can be announced by the network device in a corresponding message, but it can also be assumed, for example, if a network device has not used a predetermined number of TO time slots of consecutive transmission cycles.
  • At least the network device executing the method can also switch to an error mode.
  • the predetermined value may be different for each network device and may be announced via broadcast messages when the system is started up or may be stored in a memory accessible to the network device executing the procedure.
  • calculating an amount of data expected within a transmission cycle comprises multiplying the cycle duration by the nominal data rate of the communication medium. This embodiment may This can be used especially when transmission cycles follow one another immediately without any major delay.
  • a network device comprises one or more processors, volatile and non-volatile memory associated with it or these, and a physical network interface communicatively connected to the one or more processors and configured to send and/or receive via a communication medium shared by multiple network devices.
  • the elements of the network device are communicatively connected to one another by means of one or more data lines or buses.
  • Computer program instructions are stored in the non-volatile memory which, when executed by the at least one processor, configure the network device to carry out one or more embodiments of the method according to the invention.
  • a system in particular a vehicle system, comprises two or more network devices networked via a communication medium shared by several network devices.
  • at least one of the network devices is set up to carry out at least one embodiment of the method according to the invention described above.
  • a computer program product contains instructions which, when executed by a computer, cause the computer to carry out one or more embodiments and further developments of the method described above.
  • the computer program product can be stored on a computer-readable medium or data carrier.
  • the medium or data carrier can be physically embodied, for example as a hard disk, CD, DVD, flash memory or the like, but the medium or data carrier can also comprise a modulated electrical, electromagnetic or optical signal that can be transmitted by a computer by means of a corresponding receiver and stored in the computer's memory.
  • the method described above and the network devices executing the method can advantageously be implemented without changes to existing hardware and can be integrated into existing networks accordingly, since the protocols already used do not have to be changed and the function of the network is not impaired by higher usage or latencies.
  • the operational reliability of systems e.g. sensor networks and control units that control and execute actions based on sensor data
  • systems e.g. sensor networks and control units that control and execute actions based on sensor data
  • Errors can be detected quickly and appropriate measures can be taken more quickly to restore safe operation or to switch to a safe operating mode.
  • the method described above and the network devices executing the method can be used platform-independently and therefore flexibly due to the simple and lean implementation.
  • Fig. 1 shows an exemplary network known from the prior art with four network devices connected via a switch
  • Fig. 2 shows an exemplary network known from the prior art with five network devices connected via a 10BASE2 or 10BASE5,
  • Fig. 3 shows an exemplary network known from the prior art with five network devices connected via a twisted pair of wires
  • Fig. 4 is an example of messages sent by network devices in the order of their node IDs over the shared communication medium
  • Fig. 5 the network from Figure 3 with a fault in the network interface of a network device
  • Fig. 6 is an exemplary representation of an error in a network device in the sequence of messages sent by the network devices in the order of their node IDs over the shared communication medium
  • Fig. 7 the network from Figure 3 with a fault affecting the bus line
  • Fig. 8 is an exemplary representation of a transient disturbance affecting the bus line in the sequence of messages sent by the network devices in the order of their node IDs over the shared communication medium
  • Fig. 9 is a schematic flow chart of the basic procedure of the method.
  • Fig. 10 is an exemplary schematic flow diagram of monitoring the communication on the shared communication medium
  • Fig. 11 is an exemplary schematic flow chart for selecting one of two options for determining the amount of data transmitted over the shared communication medium during a transmission cycle depending on parameters of the shared communication medium and the network,
  • Fig. 12 is an exemplary schematic flow diagram of an alternative method for selecting one of two measurement methods for determining the amount of data transmitted over the shared communication medium during a transmission cycle depending on parameters of the shared communication medium and the network when at least one network device sends messages in burst mode,
  • Fig. 13 is an exemplary schematic flow diagram for determining the integrity of communication during a transmission cycle
  • Fig. 14 shows a first part of an exemplary schematic flow diagram of a method for determining the data bits or octets sent within a transmission cycle on the physical layer
  • Fig. 15 shows a second part of an exemplary schematic flow diagram of a method for determining a data volume transmitted within a transmission cycle on the physical layer
  • Fig. 16 is an exemplary block diagram of a network device configured to carry out one or more aspects of the method according to the invention.
  • Figure 9 shows a schematic flow diagram of the basic sequence of the method 100.
  • step 110 the communication on the shared communication medium is listened to or monitored, whereby at least sequences of data bits or octets are detected and evaluated, which mark the start and end of a transmission by a network device, and transmission options not used by network devices within a transmission cycle are detected and evaluated.
  • step 120 the determination of its duration begins in step 120. For this purpose, for example, the time elapsed between two consecutive sequences of data bits representing the start of a transmission cycle can be measured.
  • step 130 the amount of data transmitted during the transmission cycle via the shared communication medium is determined, for example by counting the data bits or octets transmitted via the shared communication medium or in another way.
  • Data from the monitoring in step 110 can also be used here, as indicated by the separate arrow, for example special sequences of data bits or octets detected during the monitoring, which serve to control the transmission.
  • step 140 an expected amount of data within the transmission cycle is calculated. This can be based on the duration of the transmission cycle and the nominal data rate of the shared communication medium as well as the number of network devices connected via it. For this purpose, the duration of the transmission cycle determined in step 120 is supplied, as indicated by the arrow.
  • step 150 the integrity of the communication via the shared communication medium is checked.
  • the integrity is determined, for example, by comparing the calculated expected data volume with the data volume determined by monitoring the communication. It is also possible to calculate a data rate from the data volume determined by monitoring the communication and the duration of the transmission cycle, which is then compared with the nominal data rate of the shared communication medium.
  • a tolerance range can be used to suppress measurement inaccuracies that are unavoidable due to the lack of synchronization between the network devices and possibly slightly differing transmission data rates of different network devices when determining the integrity.
  • Figure 10 shows an example of a schematic flow diagram of listening in or monitoring, in step 110, the communication on the shared communication medium.
  • step 110 the communication on the shared communication medium.
  • Network devices that can be operated in so-called promiscuous mode can listen in not only to the address data of data packets not addressed to them, but also to the other content of the transmissions, or at least count the number of data bits or octets of transmissions not addressed to them.
  • step 111 data from a transmission is received accordingly, and in step 112 the length of the transmission is determined or extracted, i.e. the number of data bits or octets.
  • a network device executing the method can also evaluate the content of transmissions not addressed to the network device, for example information about the length of a transmission contained in a header, counting all data bits or octets of the transmission is not necessary. In this case, it is sufficient if the network device can determine the end of a transmission, for example by receiving a signal representing the end of a data frame (EOF) or another signal agreed in a protocol used. If the transmission is directed to the network device executing the method, which is determined by a check in step 113, the received data bits or octets are also forwarded for further processing in higher protocol layers in step 114.
  • EEF end of a data frame
  • the data not required to determine the amount of data transmitted can be discarded in step 115, provided they are not used for other purposes by the network device executing the method.
  • the listening or monitoring of the communication on the shared communication medium is repeated at least until a signal representing the end of a transmission cycle is received, i.e. a corresponding sequence of data bits.
  • Figure 11 shows an example schematic flow chart for selecting one of two options for determining, in step 130, the amount of data transmitted during a transmission cycle via the shared communication medium depending on parameters of the shared communication medium and the network.
  • the number of network devices connected via the shared communication medium is determined, in step 1302 the number of data bits or octets in the sequence of data bits representing the start of a transmission cycle and possibly the end of a transmission cycle, and in step 1303 the number of data bits or octets that correspond to the TO time window.
  • This information about the parameters of the protocol used for communication also referred to as signal components, can be read out, for example, from a configuration file that is accessible locally or via the network to all network devices carrying out the method.
  • step 1305 it is checked whether the total number of data bits or octets of the signal components, which results from the sum of the number of data bits or octets in the sequence of data bits representing the start of a transmission cycle and, if applicable, the end of a transmission cycle and the product of the number of network devices connected via the shared communication medium and the number of data bits or octets representing the TO time window, plus a measurement inaccuracy, is equal to or greater than the number of data bits or octets of the shortest possible transmission of a network device, e.g. the shortest length of a data frame.
  • the number of data bits or octets of the signal components is recorded in step 1306, in addition to determining the number of data bits or octets transmitted in the messages of the network devices in step 1307.
  • Figure 12 shows an exemplary schematic flow diagram of an alternative method for selecting one of two measurement methods for determining, in step 130, the amount of data transmitted over the shared communication medium during a transmission cycle as a function of parameters of the shared communication medium and the network when at least one network device sends messages in burst mode.
  • Steps 1301, 1302 and 1303 correspond to those described with reference to Figure 11.
  • step 1304 the number of network devices that send several consecutive data frames in burst mode in a message is determined.
  • At least one network device transmits in burst mode, a larger number of data bits or octets for signal components can occur within a transmission cycle, among other things because in burst mode a network device can send up to 255 data frames in succession, and a commit signal is sent for each sent data frame, which tells the other network devices in the network that the network device currently actively accessing the communication medium will send further data frames.
  • the more network devices send additional data bits or octets for signal components the more likely it is that the number of data bits or octets in the shortest possible message from a network device will be reached or exceeded simply by the sum of the data bits or octets of the signal components, so that it becomes necessary to also record the data bits or octets of the signal components and to include them in the calculation of the number of data bits or octets transmitted or the data rate for a transmission cycle.
  • step 1305 when determining the number of data bits or octets for signal components, the sum described with reference to step 1305 in Figure 11 is the product of the number of network devices transmitting in burst mode, the number of data bits or octets of the additional TO time slots and the maximum number of data packets in burst mode, i.e. 255, is added.
  • step 1306 in addition to determining the number of data bits or octets transmitted in the messages of the network devices in step 1307, the number of data bits or octets of the signal components is recorded.
  • FIG. 13 shows an example schematic flow diagram of the steps of a method 150 for determining the integrity of communication during a transmission cycle.
  • a "real bus load" is first determined by subtracting the number of data bits or octets actually transmitted via the shared communication medium from the number of data bits or octets that can be transmitted at the nominal data rate during the duration of the transmission cycle.
  • step 152 it is checked whether the real bus load is a positive number. If this is not the case, i.e.
  • step 156 in which this error is signaled and/or treated differently.
  • Such an error can arise, for example, because the end of a transmission cycle was not recognized.
  • the method follows the "yes" branch and next checks, in step 153, whether the number representing the real bus load is greater than the number of data bits or octets of the shortest possible transmission of a network device, e.g. the shortest length of a data frame.
  • step 154 the method follows the "no" branch to step 154, which may, for example, include waiting for the determination of the integrity of the communication for the next transmission cycle. If the number representing the real bus load is greater than the number of data bits or octets of the shortest possible transmission of a network device, at least one data frame has been lost and the method follows the "yes" branch to step 155. In step 155, this second type of error is signaled and/or treated differently.
  • Figure 14 shows a first part of an exemplary schematic flow diagram of a method 1100 for listening and a method 1300 for determining the data bits or octets sent within a transmission cycle on the physical layer, i.e. layer 1 of the OSI layer model.
  • This method can be used, for example, if a network device executing the method according to the invention does not support listening to communication on layer 2 that is not intended for the network device itself, i.e. the layer 2 frames cannot be analyzed.
  • those data bits or octets that are used for signaling are also directly recorded, i.e., the sequences of data bits or octets that signal the start of a transmission cycle (beacon), the start (SOF) or the end of a transmission (EOF), and the sequences of data bits or octets that signal a further assignment (commit).
  • an initialization of the network device executing the method can take place before the start of the method, in which, for example, the number of data bits or octets of a message identifying the start or end of a transmission cycle, the number of network devices and their properties and the like are read from a database (not shown in the figure).
  • step 1101 it is checked whether a sequence of data bits or octets characterizing the start of a new transmission cycle has been received. If this is not the case, the "no" branch of step 1101 is branched off and the test is repeated.
  • step 140 branches off into the "yes" branch to the methods represented by steps 140 and 150, in which the amount of data expected within the previous transmission cycle is calculated and the integrity of the communication for the previous cycle is checked.
  • a flow chart of an exemplary method 150 which is used in the analysis on the Layer 1 of the OSI layer model is described below with reference to Figure 15. The number of data bits or octets that could have been sent while waiting for a sequence of data bits or octets indicating the start of a new transmission cycle is determined in step 1301a and taken into account accordingly when checking the integrity of the communication, indicated by the dashed arrow from step 1301a to step 140.
  • step 1102 In parallel to checking the integrity of the communication, in step 1102, respective counters for the network device that is allowed to send next, for the TO time slots not used by network devices and for the number of data bits or octets transmitted during the current transmission period, and in step 1103 a timeout counter for the current TO time slot are reset and started. In step 1104, it is checked whether all network devices had the opportunity to send in the current transmission cycle, i.e. whether the counter for the network device that is allowed to send next has reached a value that corresponds to the last network device in the group of network devices connected via the shared communication medium. If this is the case, i.e.
  • step 1104 if all network devices had the opportunity to transmit a message during the current transmission cycle, the method follows the "yes" branch from step 1104 back to step 1101, in which it waits for the start of the next transmission cycle. Otherwise, the method follows the "no" branch from step 1104 to step 1301, in which all data bits or octets sent on the shared communication medium are received and counted.
  • Received sequences of data bits or octets are checked in step 1302 to see whether they mark the beginning of a transmission by a network device, for example, form a start-of-frame signal or the like. If this is the case, the method follows the "yes" branch of step 1302 and waits, in step 1303, for a sequence of data bits or octets that mark the end of a transmission by a network device.
  • the received data bits or octets are checked in step 1304 to see whether, instead of a sequence of data bits or octets that marks the end of the transmission, there is a sequence of data bits or octets that marks the beginning of a new transmission cycle.
  • step 1305 for example, the network device executing the method can be put into an error mode and/or the network device can announce the detected error via the network.
  • step 1303 If a sequence of data bits or octets is received in step 1303 that indicates the end of a transmission by a network device, "yes" branch of step 1303, the counter for the network device that is allowed to send next is incremented in step 1306 and the method continues with step 1104.
  • step 1104 checks whether all network devices have had the opportunity to send in the current transmission cycle. If this is not the case, the part of the method beginning with step 1301 is continued for the next network device.
  • step 1302 If the check in step 1302 does not find a sequence of data bits or octets that indicates the start of a transmission by a network device, the method follows the "no" branch of step 1302 and checks in step 1307 whether a received sequence of data bits or octets indicates the start of a transmission cycle. If this is the case, "yes" branch of step 1304, an error must be present because not all network devices connected via the shared communication medium have had the opportunity to send a message or at least to allow their respective TO time windows to elapse, and the method continues with step 1305. As already described above, in step 1305, for example, the network device executing the method can be put into an error mode and/or the network device can announce the detected error via the network.
  • step 1308 If no sequence of data bits or octets marking the start of a transmission cycle was detected in step 1307 (“no” branch of step 1304), a check is made in step 1308 as to whether the timeout counter for the current TO time window has expired. If this is not the case (“no” branch of step 1308), while the shared communication medium is unused, i.e. idle, reception or waiting continues until a data bit marking the start of a transmission or a sequence of data bits or octets marking the start of a transmission is detected. was, that is, whether the network device started sending until the timeout counter expired.
  • step 1308 the counter for the TO time slots not used by network devices is incremented in step 1309 and the method continues with step 1308.
  • step 1301 All data bits or octets received in the meantime, including the sequences of data bits or octets indicating the beginning or end of a transmission, are counted by step 1301, which runs in parallel with the checks of the received data bits or octets.
  • the number of data bits or octets that could have been sent by a network device between the beginning of the TO time window and the beginning of the transmission is either added to the number of data bits or octets sent over the shared communication medium at this point, or later when checking the integrity of the communication.
  • Data bits or octets intended for the network device executing the procedure are forwarded to higher protocol layers (not shown in the figure).
  • the amount of data sent by a network device that is currently permitted to access the shared communication medium or determined for this network device using the method described above is added to the amount of data that has already been sent by or determined for other network devices during the current transmission cycle.
  • Figure 15 shows an exemplary flow chart of the steps for determining the duration of a transmission cycle and for checking the integrity of the communication for a transmission cycle.
  • the time is calculated which has elapsed between the reception of a sequence of data bits or octets characterizing the beginning of a transmission cycle and the reception of a sequence of data bits or octets characterizing the end of a transmission cycle.
  • the end of a transmission cycle can be can also be signaled by the start of a subsequent transmission cycle.
  • a timer can be used for the calculation, which is started at the start of a transmission cycle and stopped at the end of a transmission cycle.
  • step 140 an expected data volume within the transmission cycle is calculated. This can be done, for example, on the basis of the duration of the transmission cycle and the nominal data rate of the shared communication medium.
  • step 150 the amount of data transmitted during the transmission cycle via the shared communication medium, determined in step 130, which runs parallel to determining the duration of the transmission cycle, is compared with the expected amount of data calculated in step 140. If the data bits or octets that could theoretically be transmitted during an unused TO time window were not already taken into account when determining the transmitted data bits or octets, these are determined in step 1399 by multiplying the number of network devices that did not transmit by the number of data bits or octets that could theoretically be transmitted during a TO time window and added to the data bits or octets actually received.
  • the network device may enter various error modes of operation.
  • the possible error modes may include using a different method for accessing the shared communication medium, e.g. CSMA/CD, enhanced logging of communications over the shared communication medium, placing the system in safe mode, sending one or more messages to a remote system, or the like.
  • Figure 16 shows an exemplary block diagram of a network device 400 configured to carry out one or more aspects of the method according to the invention.
  • the network device 400 comprises volatile and non-volatile memory 404, 406 and a communication interface 408.
  • the elements of the network device are communicatively connected to one another via one or more data connections or buses 410.
  • the non-volatile memory 406 contains computer program instructions which, when executed by the microprocessor 402, configure the network device to carry out at least one embodiment of the method according to the invention.
  • Network device 406 non-volatile memory
  • Connection box 1300 determine the amount of data sent

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Small-Scale Networks (AREA)

Abstract

Ein Verfahren zur Überwachung der Integrität der Kommunikation zwischen mehreren über ein gemeinsam genutztes Kommunikationsmedium verbundenen Netzwerkgeräten, welche innerhalb eines durch ein erstes Netzwerkgerät initiierten Sendezyklus jeweils eine Nachricht über das gemeinsam genutzte Kommunikationsmedium senden können, umfasst das Mithören zumindest bestimmter Teile der Kommunikation auf dem Kommunikationsmedium innerhalb eines Sendezyklus. Das Mithören umfasst zumindest das Erkennen und Auswerten von Datenbits bzw. Oktetten, welche den Beginn und das Ende des Sendezyklus sowie den Beginn und das Ende einer Übertragung durch ein Netzwerkgerät kennzeichnen. Das Mithören umfasst außerdem das Erkennen und Auswerten einer von einem Netzwerkgerät innerhalb eines Sendezyklus nicht genutzten Sendemöglichkeit. Erfindungsgemäß wird die Dauer eines Sendezyklus bestimmt und eine innerhalb des Sendezyklus übertragene Datenmenge oder eine für den Sendezyklus erreichte Datenrate ermittelt. Durch Vergleichen einer innerhalb des Sendezyklus erwarteten Datenmenge oder der nominellen Datenrate mit der übertragenen Datenmenge bzw. der erreichten Datenrate kann die Integrität der Kommunikation auf dem Kommunikationsmedium überwacht werden.

Description

BESCHREIBUNG
VERFAHREN ZUM TESTEN EINES KOMMUNIKATIONSBUSSES
FELD
Die vorliegende Erfindung bezieht sich auf die Kommunikation über ein von mehreren Netzwerkgeräten gemeinsam genutztes Kommunikationsmedium, insbesondere auf die Überwachung der Integrität der Kommunikation.
BEGRIFFSDEFINITIONEN
Im vorliegenden Dokument wird der Begriff Kommunikationsmedium stellvertretend für drahtlose oder draht- bzw. andere mediengebundene Übertragungsmedien genutzt, also synonym für akustische Signale, Lichtwellen, Funkwellen, oder über elektrische Leiter geführte elektrische Signale, sofern sich aus dem Kontext nicht zwingend eine Festlegung auf eines dieser Kommunikationsmedien ergibt.
HINTERGRUND
In einer Vielzahl von Technologiebereichen ist eine sichere Kommunikation zwischen mehreren Netzwerkgeräten erforderlich. Die Kommunikation kann mittels Punkt-zu-Punkt- Verbindungen über Router und Switches erfolgen, wie beispielsweise bei den meisten Ethernet- und Internetprotokoll (IP)-basierten Netzwerken, oder über von mehreren Netzwerkgeräten gemeinsam genutzte Kommunikationskanäle, einschließlich drahtloser Verbindungen oder drahtgebundener Busverbindungen.
Im Bereich Industrieautomatisierung werden diverse Feldbusse genutzt, wie bspw. EtherCAT, RS-485, UARTs, usw. In der Automobilwelt kommen MOST-, CAN-, LIN- und andere Netzwerke zum Einsatz, die zur Kommunikation mit anderen Domänen komplexe Gateway-Geräte benötigen. Auf dem Markt der Computer-Server nutzt man zur Verwaltung verschiedener Subsysteme I2C, GPIO, SPI und sogar CAN aus der Automobilwelt.
Jedes dieser Subsysteme verwendet eine eigene Hardwareschnittstelle mit jeweils unterschiedlichem EMV-Verhalten, und nutzt dazu verschiedene Software-Stacks. Eine durchgängig Ethernet-basierte Netzwerkarchitektur bietet demgegenüber viele Vorteile, da sie unabhängig vom physikalischen Layer immer mit dem gleichen Protokoll arbeitet. Ein Datenframe sieht unabhängig von seiner Übertragung mit 10 Mbit/s oder 10 Gbit/s immer gleich aus. Die Skalierung der Bandbreite für bestimmte Anwendungen erfordert keine komplexen Gateways. Oft lässt sich ein einzelner Switch mit entsprechenden Schnittstellen ausstatten, welche die Kommunikation mit unterschiedlichen Geschwindigkeiten ermöglichen. Die Datenframes können dann ohne eine Modifikation der Daten durch entsprechende Zwischenspeicherung von einer Domäne in eine andere wechseln.
In vielen Anwendungsfällen ist die Verwendung klassischer Ethernet-Verbindungen aus Komplexitäts-, Platz-, Gewichts-, Kosten- oder anderen Gründen nicht realisierbar. So ist bei einer elektrischen Ethernet-Verbindung, die als Punkt-zu-Punkt-Verbindung zwischen zwei Netzwerkgeräten oder einem Netzwerkgerät und einem Switch mit einer Leitung ausgeführt ist jeweils an beiden Enden der Leitung eine dedizierte physische Schnittstelle erforderlich, im allgemeinen als PHY bezeichnet, welche für die Kodierung und Dekodierung von Daten zwischen der digitalen Systemseite und einem Ausbreitungsoder Übertragungsmedium zuständig ist. Ein Switch benötigt für jedes daran angeschlossene Netzwerkgerät einen separaten PHY, so dass eine große Zahl an Anschlüssen in einem Netzwerk erforderlich ist. Ein beispielhaftes System 10 mit vier über einen Switch 16 verbundenen Netzwerkgeräten 12, 14, 18, und 20 ist in Figur 1 dargestellt. Insgesamt werden 8 physische Schnittstellen für die vier Punkt-zu-Punkt- Verbindungen benötigt, so dass alle fünf Netzwerkgeräte miteinander kommunizieren können.
Aus der Frühzeit des Ethernets sind Ethernet-Systeme bekannt, bei der eine Bustopologie genutzt wird (10BASE2, 10BASE5). Eine solche ist in Figur 2 beispielhaft dargestellt. Ein Koaxialkabel 22 verbindet die fünf Netzwerkgeräte 12, 14, 16, 18 und 20. Jedes der Netzwerkgeräte 12, 14, 16, 18 und 20 ist über eine Stichleitung und eine Anschlussbox 12a, 14a, 16a, 18a und 20a an das Koaxialkabel 22 angeschlossen. In den Anschlussboxen 12a, 14a, 16a, 18a und 20a wird im Falle von 10BASE5-Ethernet der äußere Leiter des Koaxialkabels 22 punktuell durchbrochen, und ein Kontaktstift wird in Kontakt mit dem inneren Leiter des Koaxialkabels 22 gebracht, ohne mit dem äußeren Leiter in Kontakt zu kommen. Im Falle von 10BASE2 erfolgt der Anschluss der Stichleitungen über T-Verbinder mit BNC-Anschlüssen. Zwar ist die Anzahl der physischen Schnittstellen zu der Busleitung auf fünf reduziert, jedoch wird für die bekannte Ethernet-Bustopologie in jedem Fall ein Koaxialkabel benötigt, welches gegenüber eines ggf. verdrillten Leiterpaars u.a. erhebliche Kosten-, Handhabungs- und Gewichtsnachteile mit sich bringt. Außerdem ist für den Anschluss jedes Netzwerkgeräts an die Busleitung eine besondere Anschlussbox oder zumindest ein T-Stück für Koaxialleitungen erforderlich, was wiederum einen hohen Aufwand bedeutet.
Um die Nutzung von Ethernet-Verbindungen in weiteren Anwendungsbereichen attraktiver zu machen wurde eine neue Variante des Ethernet-Standards entwickelt, die eine Bandbreite von 10 Mbit/s über einen physikalischen Layer mit einem einzigen Leitungspaar bietet: IEEE Std 802.3cg-2019. Eine der unter diesem IEEE-Standard spezifizierten Varianten heißt 10BASE-T1 S, wobei das S für Short Reach - kurze Reichweite steht, und die eine Multidrop- oder Bus-Topologie nutzen kann, bei der alle Knoten über eine einzige zweiadrige verdrillte Leitung verbunden sind. Damit erübrigt sich die Nutzung von Switches, d.h., die Anzahl der physischen Schnittstellen ist kleiner als bei einem System mit einem Switch, und es wird keine Koaxialleitung benötigt. Der Anschluss von Stichleitungen an ein verdrilltes zweiadriges Kabel ist ebenfalls einfach und kostengünstig passiv realisierbar. Eine Variante mit großer Reichweite - 10BASE-T1 L genannt (L für Long Reach) - wurde für Entfernungen bis 1 km definiert. Die Long-Reach- Variante nutzt wiederum Punkt-zu-Punkt-Verbindungen.
Über ein 10BASE-T1 S Bussystem können mindestens acht Netzwerkgeräte miteinander verbunden werden, wobei die maximale Buslänge 25 m beträgt. Die einzelnen Netzwerkgeräte können mit jeweils höchstens 10 cm langen Stichleitungen an die Busleitung angeschlossen werden. Alle Knoten teilen sich die Bandbreite von 10 Mbit/s. Figur 3 zeigt ein entsprechendes beispielhaftes 10BASE-T 1 S Netzwerk mit fünf über ein gemeinsam genutztes Kommunikationsmedium 24, bspw. eine von einem verdrillten Aderpaar gebildete Busleitung, verbundenen Netzwerkgeräten 12, 14, 16, 18, 20. Die gestrichelte Linie deutet die logischen Verbindungen zwischen den Netzwerkgeräten an, die durchgezogene Linie die physischen Verbindungen an.
Um einen geregelten Zugriff einzelner Netzwerkgeräte auf den KBUS zu gewährleisten spezifiziert der Standard ein Arbitrierungsschema das eine volle Ausnutzung der verfügbaren Bandbreite bei reduzierter Latenz und hoher Quality of Service (QoS) ermöglicht. Eines der möglichen Arbitrierungsschemata ist als Physical Layer Collision Avoidance - PLCA bekannt, ein anderes, als Carrier Sense Multiple Access/Collision Detection - CSMA/CD bekanntes Arbitrierungsschema kann eine geringere Ausnutzung der Buskapazität aufweisen und kann bspw. als Rückfalloption genutzt werden.
Das CSMA/CD-Zugriffsverfahren erlaubt es jedem Netzwerkgerät auf das Netzwerk sendend zuzugreifen, sobald kein anderes Netzwerkgerät sendet. Eine Regelung die sicherstellt, dass jedes der Netzwerkgeräte eines Netzwerks innerhalb eines festgelegten Zeitraums die Möglichkeit erhält, Daten zu senden, ist im CSMA/CD Zugriffsverfahren nicht enthalten und muss auf einer höheren Protokollebene erfolgen.
Das PLCA-Zugriffsverfahren ähnelt konzeptionell einem Token Ring Verfahren oder TDMA (Time Division Multiple Access). Beim PLCA-Zugriffsverfahren wird jedes Netzwerkgerät mit einer Node-ID konfiguriert, und das Netzwerkgerät mit der Node-ID 0 wird als PLCA-Koordinator festgelegt. Der Koordinator initiiert einen Kommunikationszyklus, indem er eine vereinbarte Folge von Datenbits bzw. Oktetten sendet, auch Beacon-Nachricht oder einen Beacon-Frame genannt. Die anderen Knoten nutzen diese Beacon-Nachricht, um ihre Taktgeber zu koordinieren. Die Begriffe Beacon- Nachricht und Beacon-Frame werden in dieser Beschreibung synonym verwendet.
Um beim PLCA-Zugriffsverfahren zu ermitteln wann es Daten senden darf „lauscht“ jedes Netzwerkgerät auf der Busleitung und wartet, bis das Netzwerkgerät mit einer um eins niedrigeren Node-ID als seine eigene die Übertragung beendet. Nach jedem Sendevorgang eines Netzwerkgeräts, der durch eine vereinbarte Folge von Datenbits bzw. Oktetten am Ende einer Übertragung als beendet markiert werden kann, folgt eine Periode, die als Transmit Opportunity (Übertragungsmöglichkeit) oder TO-Zeitfenster bezeichnet wird. Das TO-Zeitfenster kann bspw. 20 Bit lang sein, d.h., einer Zeitdauer entsprechen, innerhalb derer 20 Bit mit der nominalen Datenrate des Datenbusses gesendet werden können. Innerhalb dieses TO-Zeitfensters kann dasjenige Netzwerkgerät mit der Übertragung beginnen, dessen Node-ID um eins höher ist als die des Netzwerkgerätes, das unmittelbar zuvor seine Übertragung beendet hat. Jeder Knoten darf seine gesamten Daten senden, wobei typischerweise jedes Netzwerkgerät nur einen Frame sendet. Gleichwohl kann ein Netzwerkgerät im sogenannten Burst Modus mehrere aufeinander folgende Datenframes senden, wobei durch zwischen den jeweiligen Datenframes gesendete Commit-Nachrichten das Kommunikationsmedium als weiterhin von dem derzeit sendenden Netzwerkgerät als besetzt markiert wird. Wenn ein Netzwerkgerät nicht sendet und das für es reservierte TO-Zeitfenster verstreichen lässt, schließt sich ein weiteres TO-Zeitfenster für das nächste Netzwerkgerät an. So kann auch in einem Zyklus, in dem nicht alle Netzwerkgerät senden, vom Koordinator das Ende des Zyklus festgestellt bzw. angenommen werden, und ein neuer Zyklus gestartet werden.
Nachdem das letzte Netzwerkgerät die Möglichkeit zur Datenübertragung erhalten und ggf. genutzt hat, initiiert der PLCA-Koordinator den nächsten Zyklus mit einer weiteren Beacon-Nachricht.
Der Zugriff mittels PLCA erzielt einen höheren Durchsatz als TDMA oder Token Ring, weil die Netzwerkgeräte ihre Nachrichten nicht auf mehrere Zeitschlitze aufteilen müssen. Außerdem ist die Transmit-Opportunity-Phase mit ihren 20 Bit kürzer als ein Token-Paket. Da die Teilnehmer am Bus ihre Sendemöglichkeit wahrnehmen können oder auch nicht, ist die Dauer eines kompletten Sendezyklus vorab nicht exakt bestimmbar.
Eine beispielhafte Darstellung der von Netzwerkgeräten in der Reihenfolge ihrer Node-IDs über das gemeinsam genutzte Kommunikationsmedium gesendeten Nachrichten ist in Figur 4 gezeigt. Der Beginn eines Sendezyklus wird mit einer entsprechenden Bitsequenz B, auch als Beacon bezeichnet, eingeleitet. Unmittelbar daran schließt sich ein TO- Zeitfenster an, innerhalb welchen das Netzwerkgerät mit der niedrigsten Node-ID beginnen darf, seine Nachricht zu senden, hier also der Node-ID mit dem Wert 0, der auch die Beacon-Bitsequenz gesendet hat. Das TO-Zeitfenster ist in der Figur schraffiert dargestellt. Auf das Ende der Übertragung durch ein Netzwerkgerät folgt das T0- Zeitfenster für das nächste Netzwerkgerät. Das Netzwerkgerät, welches senden darf, kann unmittelbar am Anfang des TO-Zeitfensters zu senden beginnen oder irgendwann innerhalb des TO-Zeitfensters. Das TO-Zeitfenster kann bspw. durch ein das Ende einer Übertragung eines Netzwerkgerätes repräsentierendes Signal gestartet werden. Dieses Signal kann bspw. ein End-of-Frame-Signal (EOF) sein. Das Ende eines TO-Zeitfensters kann durch einen Zähler oder Timer bestimmt werden. Das Ende des TO-Zeitfensters wird erreicht, wenn während einer vereinbarten Zeit, entsprechend einer vereinbarten Anzahl von mit der nominellen Datenrate des gemeinsam genutzten Kommunikationsmediums gesendeten Datenbits, das Netzwerkgerät, welches senden darf, keine Übertragung begonnen hat. Wenn vor dem Ablauf des TO-Zeitfensters der Beginn einer Übertragung erkannt wird, bspw. durch ein Start-of-Frame-Signal (SOF) signalisiert, kann der Zähler für das TO-Zeitfenster gestoppt werden. Dieser Vorgang wiederholt sich, bis das letzte Netzwerkgerät seine Nachricht gesendet oder sein TO- Zeitfenster verstreichen lassen hat. Anschließend wird eine neue Beacon-Bitsequenz gesendet, mit der ein neuer Sendezyklus begonnen wird. Die Länge oder Dauer jedes Sendezyklus ergibt sich aus der Länge der Beacon-Bitsequenz, der Länge der von den Netzwerkgeräten jeweils gesendeten Nachrichten bzw. ganz oder teilweise nicht genutzten TO-Zeitfenstern und kann von Sendezyklus zu Sendezyklus unterschiedlich sein.
Obwohl die Netzwerkgeräte stets auf die Kommunikation auf dem KBUS lauschen, um festzustellen wann sie senden dürfen, findet eine weitergehende Prüfung, ob die Kommunikation auf dem KBUS fehlerfrei abläuft nicht statt. Fehler durch Unterbrechung des Kommunikationsmediums oder durch transiente Störungen, welche die Übertragung einzelner Datenpakete stören können, können nicht erkannt werden. Solche Fehler können beim Betrieb des Netzwerks bspw. in einer harschen Umgebung mit vielen Störquellen auftreten, infolge eines Angriffs oder durch einen Fehler in der Verbindung zwischen der physikalischen Schnittstelle (PHY) und dem Mikrocontroller verursacht werden, welcher über die Schnittstelle zu kommunizieren versucht. Figur 5 zeigt das Netzwerk aus Figur 3 mit einem Fehler in der Verbindung zwischen dem Prozessor und der Netzwerkschnittstelle des Netzwerkgeräts 16. Die physische Verbindung zwischen der Netzwerkschnittstelle und der Busleitung 24 ist nicht gestört. Dennoch kann die Übertragung der Daten durch das Netzwerkgerät 16 unvollständig sein oder ganz ausfallen. Eine beispielhafte Darstellung des Fehlers in der Abfolge der von den Netzwerkgeräten in der Reihenfolge ihrer Node-IDs über das gemeinsam genutzte Kommunikationsmedium gesendeten Nachrichten ist in Figur 6 gezeigt. Die Darstellung entspricht im Wesentlichen der Darstellung in Figur 4, außer dass die Nachricht von Node 2 gestört ist. Diese Störung kann bspw. darin bestehen, dass Node 2 wegen einer Störung der Verbindung zwischen dem Prozessor und der Netzwerkschnittstelle überhaupt nicht sendet, unvollständig sendet oder zufällige Bitfolgen sendet. Ein solcher Fehler ist auf der Ebene der Zugriffssteuerung im normalen Betrieb nicht erkennbar und würde auf höheren Protokollebenen erkannt werden müssen. Insbesondere bei Sensornetzwerken, bei denen die einzelnen Netzwerkgeräte wenig Rechenleistung und Speicher bereitstellen und zudem besonders kostengünstig sein müssen, können solche Fähigkeiten nicht immer vorhanden sein.
Figur 7 zeigt das Netzwerk aus Figur 3 mit einem auf die Busleitung 24 einwirkenden Fehler, bspw. eine durch einen elektromagnetischen Störimpuls ausgelöste, vorübergehende Störung. Auch hier ist die physische Verbindung zwischen der Netzwerkschnittstelle und der Busleitung 24 nicht gestört. Wenngleich die Störung als lokal in der Figur dargestellt ist, tritt sie wegen der kurzen Länge und der geringen Dämpfung der Busleitung an allen Schnittstellen quasi zeitgleich auf und stört so den korrekten Empfang von Datenbits bzw. Oktetten einer Nachricht, bspw. indem ein Signalpegel so verändert wird, dass der Wert eines oder mehrerer Datenbits geändert wird, oder indem ein Spannungspegel an den Empfängern der Schnittstellen anliegt, welcher diese übersteuert. Eine beispielhafte Darstellung des Fehlers in der Abfolge der von den Netzwerkgeräten in der Reihenfolge ihrer Node-IDs über das gemeinsam genutzte Kommunikationsmedium gesendeten Nachrichten ist in Figur 8 gezeigt. Die Darstellung entspricht im Wesentlichen der Darstellung in Figur 4, außer dass in der beispielhaften Darstellung der Figur 8 die Beacon-Bitsequenz gestört ist, bspw. durch einen elektrischen oder elektromagnetischen Störimpuls zu dem Zeitpunkt, als der Koordinator die Beacon-Bitsequenz gesendet hat. Die Netzwerkgeräte mit den Node-IDs größer als 0 können dadurch den Beginn eines neuen Sendezyklus nicht erkennen, und werden ihre Nachrichten nicht senden. Der Koordinator wird also in der Folge vermeintlich nur TO-Zeitfenster erkennen, die von den anderen Netzwerkgeräten nicht genutzt werden, und einen neuen Sendezyklus beginnen, wenn die Anzahl der verstrichenen, nichtgenutzten TO-Zeitfenster der Anzahl der über das gemeinsam genutzte Kommunikationsmedium verbundenen Netzwerkgeräte entspricht. Für den Koordinator ist der in der Figur 8 dargestellte Sendezyklus x+1 sehr kurz, für die anderen Netzwerkgeräte ist dagegen der Sendezyklus x länger als für den Koordinator. Eine solche Veränderung ist auf den OSI-Layern 1 und 2 der Kommunikationsverbindung im normalen Betrieb nicht sicher erkennbar und müsste, wie in dem mit Bezug auf Figur 5 beschriebenen Fehlerbeispiel, auf höheren Protokollebenen erkannt und ggf. korrigiert werden.
BESCHREIBUNG DER ERFINDUNG
Wenn ein Netzwerk des zuvor beschriebenen Typs, in welchem eine Vielzahl von Netzwerkgeräten über ein gemeinsam genutztes Kommunikationsmedium miteinander verbunden sind, in einem System genutzt wird, welches hohe Anforderungen an die Zuverlässigkeit und Sicherheit der Kommunikation stellt, bspw. in einem System mit mehreren Netzwerkgeräten, die im Zusammenhang mit teil- oder hochautomatisiertem Fahren miteinander kommunizieren, ist eine häufige, idealerweise kontinuierliche Integritätskontrolle der Kommunikation unerlässlich. Im Kontext dieser Beschreibung umfasst der Begriff Netzwerkgerät alle möglichen Arten von Netzwerkgeräten, einschließlich vernetzter Sensoren und Netzwerkgeräte, welche Signale von vernetzten Sensoren verarbeiten.
Um auch bei gravierenden Fehlem an beliebigen Stellen des Netzwerks diese Integritätskontrolle durchführen zu können kann es außerdem wünschenswert sein, diese Integritätskontrolle in möglichst vielen Netzwerkgeräten unabhängig voneinander durchführen zu können, um bspw. in Reaktion auf einen Fehler in einen sicheren Betriebsmodus schalten zu können. Da die Hardware und Rechenleistung in vielen Netzwerkgeräten nicht ausreichen, um aufwendige Kontrollroutinen kontinuierlich oder quasi-kontinuierlich auszuführen, und die Verwendung von Kommunikationsprotokollen mit Bestätigungsnachrichten für empfangene Daten die für die Datenübertragung verfügbare Bandbreite verringert und zusätzliche Verzögerungen hervorruft besteht ein großer Bedarf eine einfache aber zuverlässige Integritätskontrolle der Kommunikation in Netzwerken durchführen zu können, bei denen mehrere Netzwerkgeräte über ein gemeinsam genutztes Medium kommunizieren.
Es ist daher eine Aufgabe der vorliegenden Erfindung ein Verfahren zur Integritätskontrolle einer Kommunikation in einem Netzwerk bereitzustellen, welches eine geringe Rechenkapazität erfordert, und welches außerdem dezentral ausführbar sein kann.
Diese Aufgabe wird durch das in dem unabhängigen Anspruch 1 angegebene Verfahren gelöst. Ausgestaltungen und Weiterentwicklungen des Verfahrens sind in den abhängigen Ansprüchen angegeben.
Es ist eine außerdem eine Aufgabe der vorliegenden Erfindung, ein Netzwerkgerät anzugeben, welches zur Durchführung des erfindungsgemäßen Verfahrens oder seiner Ausgestaltungen bzw. Weiterentwicklungen eingerichtet ist. Weitere Aufgaben der Erfindung betreffen die Schaffung eines Systems mit mindestens einem erfindungsgemäßen Netzwerkgerät sowie eines Computerprogrammprodukts und eines dieses abrufbar bereitstellenden computerlesbaren Mediums.
Gemäß einem ersten Aspekt der Erfindung umfasst ein Verfahren zur Überwachung der Integrität der Kommunikation zwischen mehreren über ein gemeinsam genutztes Kommunikationsmedium verbundenen Netzwerkgeräten, welche innerhalb eines durch ein erstes, auch als Koordinator bezeichnetes Netzwerkgerät initiierten und beendeten Sendezyklus jeweils eine Nachricht über das gemeinsam genutzte Kommunikationsmedium senden können, das Mithören zumindest bestimmter Teile der Kommunikation auf dem Kommunikationsmedium innerhalb des Sendezyklus.
Die von dem jeweiligen Netzwerkgerät gesendete Nachricht kann eine beliebige Länge haben, d.h. einen oder mehrere Ethernet-Frames umfassen, wobei die Länge des oder der Ethernet-Frames zwischen 64 und 1518 Byte liegen kann. Das Senden sogenannter Jumbo-Frames mit einer größeren Länge ist prinzipiell ebenfalls möglich, wobei in diesem Fall alle der über das Kommunikationsmedium vernetzten Netzwerkgeräte diese Jumbo- Frames unterstützen müssen. Wenn von einem Netzwerkgerät mehrere aufeinanderfolgende Frames gesendet werden, was auch als Burst-Mode bezeichnet wird, kann das Netzwerkgerät im Anschluss an einen gesendeten Frame ein Commit- Signal senden, um den anderen Netzwerkgeräten zu signalisieren, dass ein weiterer Frame folgt.
Der Beginn eines Sendezyklus wird durch eine Folge von Datenbits markiert. Das Ende eines Sendezyklus kann bspw. durch eine Folge von Datenbits dargestellt werden, welche den Beginn eines darauffolgenden Sendezyklus markieren. Alternativ kann das Ende eines Sendezyklus auch durch eine Folge von Datenbits dargestellt werden, welche das Ende der Übertragung des letzten Netzwerkgerätes markiert. Letzteres kann erfordern, dass alle Netzwerkgeräte, welche das Verfahren durchführen, zumindest die Anzahl der Netzwerkgeräte in dem Netzwerk kennen, bspw. durch entsprechende Parametrisierung oder durch eigenständiges Erlernen während des Betriebs.
Das Mithören umfasst entsprechend zumindest das Erkennen und/oder Auswerten von Datenbits bzw. Folgen von Datenbits, welche den Beginn und das Ende eines Sendezyklus kennzeichnen, und von Datenbits bzw. von Folgen von Datenbits bzw. Oktetten welche den Beginn und das Ende einer Übertragung durch ein Netzwerkgerät kennzeichnen. Der Beginn einer Übertragung durch ein Netzwerkgerät kann bereits daran erkannt werden, dass ein erstes Datenbit innerhalb eines TO-Zeitfensters gesendet wird. Durch das verwendete Protokoll kann sichergestellt werden, dass nur ein Netzwerkgerät sendet, das tatsächlich gerade an der Reihe ist. Das Mithören umfasst außerdem das Erkennen und/oder Auswerten einer von einem Netzwerkgerät innerhalb eines Sendezyklus nicht genutzten Sendemöglichkeit. Wenn zumindest eines der Netzwerkgeräte des Netzwerks Nachrichten im Burst-Mode überträgt umfasst das Mithören auch das Erkennen und/oder Auswerten von Commit-Signalen repräsentierenden Folgen von Datenbits. Netzwerkgeräte, welche Nachrichten auch im Burst-Mode senden können dies bspw. bei der Initialisierung des Netzwerks bekanntgeben oder, wenn die Anzahl und Art der das Netzwerk nutzenden Netzwerkgeräte des Systems von Anfang an bekannt ist und unveränderlich bleibt, kann vorab eine entsprechende Konfiguration in den Netzwerkgeräten erfolgen.
Jedem Netzwerkgerät des Netzwerks ist eine eindeutige Node-ID zugewiesen, in der Regel eine Zahl innerhalb eines mit 0 beginnenden und mit der Anzahl n der Netzwerkgeräte des Netzwerks endenden Intervalls. Das Netzwerkgerät mit der niedrigsten Node-ID, also der Node-ID 0, ist das erste Netzwerkgerät, d.h. der Koordinator, welcher den Sendezyklus initiiert und außerdem als erster seine Daten übertragen darf. Jedes Netzwerkgerät implementiert einen Node-ID-Zähler, der am Anfang eines jeden Sendezyklus auf 0 zurückgesetzt wird. Der Node-ID-Zähler kann ein einfacher, in Software implementierter Zähler sein. Bei jeder Übertragung durch ein Netzwerkgerät auf dem gemeinsamen Kommunikationsmedium, bspw. am Ende einer Übertragung, erhöht jedes Netzwerkgerät seinen Node-ID-Zähler um 1 und vergleicht den Zählerwert des Node-ID-Zählers mit seiner eigenen Node-ID. Wenn der Zählerwert des Node-ID-Zählers und die eigene Node-ID eines Netzwerkgeräts übereinstimmen, darf dieses Netzwerkgerät nach dem Ende der vorherigen Übertragung selbst über das gemeinsam genutzte Kommunikationsmedium senden.
Wie zuvor erwähnt muss ein Netzwerkgerät innerhalb eines Sendezyklus nicht unbedingt senden. Das Erkennen und Auswerten einer von einem Netzwerkgerät nicht genutzten Sendemöglichkeit kann daher bspw. das Erkennen und Auswerten eines TO-Zeitfensters umfassen. Ein TO-Zeitfenster hat eine vorherbestimmte Zeitdauer, bspw. die Dauer, die die Übertragung einer vorherbestimmten Anzahl von Datenbits mit der nominellen Datenrate des gemeinsam genutzten Kommunikationsmediums benötigt hätte. Ein TO- Zeitfenster folgt auf das Ende einer Übertragung, z.B. auf eine das Ende eines Datenframes repräsentierende Folge von Datenbits. Sobald während der Gesamtdauer eines TO-Zeitfensters, d.h. bis zu dessen Ablauf, keine Datenbits erkannt werden, welche den Beginn einer Übertragung durch dasjenige Netzwerkgerät kennzeichnen, welches derzeit senden darf, erhöht jedes Netzwerkgerät den Node-ID-Zähler und wartet während eines neuen TO-Zeitfensters, ob Datenbits empfangen werden, bzw. sendet selbst seine Übertragung über das Kommunikationsmedium, wenn der Wert des Node-ID-Zählers seiner Node-ID entspricht.
Ein Netzwerkgerät kann während des TO-Zeitfensters auch eine Commit-Nachricht senden, wenn das Netzwerkgerät bspw. noch nicht bereit zum Senden der Nachricht ist, dies aber in Kürze der Fall sein wird. In diesem Fall warten die anderen Netzwerkgerät über das Ende des TO-Zeitfensters hinaus, bis das Netzwerkgerät, welches das Commit- Signal gesendet hat, seine Nachricht gesendet hat. Im darauffolgenden TO-Zeitfenster kann dann das nächste Netzwerkgerät senden, dessen Node-ID mit dem Zählerwert übereinstimmt.
Erfindungsgemäß umfasst das Verfahren außerdem das Bestimmen der Dauer eines Sendezyklus. Die Dauer eines Sendezyklus kann bspw. durch Messen der zwischen zwei aufeinanderfolgenden Folgen den Beginn eines Sendezyklus kennzeichnender Datenbits verstrichenen Zeit bestimmt werden. Falls das Ende eines Sendezyklus durch eine Folge von Datenbits signalisiert wird, die das Ende der Übertragung des letzten Netzwerkgerätes markiert, kann die zwischen dem Beginn des Sendezyklus und dieser Folge verstrichene Zeit gemessen werden. Da die Länge der Sendezyklen in Abhängigkeit von der Anzahl der Netzwerkgeräte, die tatsächlich Daten übertragen, und der Anzahl der von jedem Netzwerkgerät gesendeten Datenbits bzw. Oktette schwanken kann wird die Dauer jedes einzelnen Sendezyklus individuell bestimmt.
Weiter erfindungsgemäß wird die innerhalb des Sendezyklus übertragene Datenmenge ermittelt, und es wird die innerhalb des Sendezyklus erwartete Datenmenge berechnet. Anschließend wird die ermittelte mit der die berechneten Datenmenge verglichen. Alternativ kann aus der gemessenen Dauer des Sendezyklus und der während des Sendezyklus über das Kommunikationsmedium übertragenen Datenmenge eine Datenrate bestimmt werden, die mit einer nominellen Datenrate des Netzwerks verglichen wird. Wenn die ermittelte und die berechnete Datenmenge bzw. die ermittelte und die nominelle Datenrate innerhalb eines Toleranzfensters übereinstimmen wird das Verfahren für einen nachfolgenden Sendezyklus wiederholt. Anderenfalls geht zumindest eines der Netzwerkgeräte die das Verfahren durchgeführt haben in einen Fehlermodus über. Im Fehlermodus kann ein Netzwerkgerät je nach Art und Schwere des Fehlers unterschiedliche Maßnahmen ergreifen. Zum Beispiel können den Fehler betreffende Informationen lokal in dem Netzwerkgerät, in einem mit dem Netzwerkgerät kommunikativ verbundenen revisionssicheren Speicher und/oder in einer Cloud gespeichert werden. Das Log-Level, also bspw. Datenmenge und Detailgrad der Informationen die gespeichert werden, kann auch Fallweise verschärft werden, so dass zusätzliche Daten zur Fehlersuche zur Verfügung stehen. Alternativ oder zusätzlich dann das Netzwerkgerät die eigene Kommunikation über das gemeinsam genutzte Kommunikationsmedium einstellen, oder das Netzwerkgerät mit der niedrigsten Node-ID, das die Rolle des Koordinators innehat, wird benachrichtigt, so dass dieses ggf. weitere Kommunikation auf dem Datenbus unterbindet. Genauso ist es möglich, andere über das gemeinsam genutzte Kommunikationsmedium kommunizierende Netzwerkgeräte über den Fehler zu benachrichtigen, falls diese nicht selbst die Integrität der Kommunikation über das gemeinsam genutzte Kommunikationsmedium überwachen, so dass diese Netzwerkgeräte ggf. ihre Funktion an den Fehler anpassen können. Auch ein Rückfall in einen anderen Zugriffsmodus kann als Reaktion auf einen Fehler erfolgen, bspw. in den CSMA/CD-Zugriffsmodus für das gemeinsam genutzte Kommunikationsmedium. Bei CSMA/CD (Carrier-Sense Multiple Access/Collision Detection) wird nicht mehr in durch einen Koordinator initiierte Zyklen kommuniziert, und es werden keine Beacon-Frames ausgesandt. Stattdessen lauschen sämtliche Netzwerkgeräte auf mögliche Kommunikation auf dem Kommunikationsmedium und versuchen zu senden, wenn gerade kein anderes Netzwerkgerät sendet. Sollte es zu Kollisionen kommen, warten die Netzwerkgeräte mit zufällig generierten Wartezeiten eine gewisse Zeit, bevor sie erneut versuchen zu senden. Dadurch wird die Netto-Datenrate reduziert, rein statistisch wird aber allen Teilnehmern weiterhin die Möglichkeit zum Senden von Daten gegeben. Ein solcher Wechsel der Zugriffssteuerung muss in geeigneter Weise an alle Busteilnehmer kommuniziert werden. Hierfür könnte bspw. das Netzwerkgerät mit der niedrigsten Node- ID benachrichtigt werden, welches dann eine entsprechende Nachricht an die anderen Netzwerkgerät sendet. Es ist leicht erkennbar, dass nach einem Wechsel in einen Fehlermodus u.U. keine Überwachung nach dem erfindungsgemäßen Verfahren mehr durchgeführt werden kann, bspw. wenn auf das CSMA/CD-Zugriffsverfahren umgeschaltet wurde.
Wenn das Verfahren für jeden Sendezyklus ausgeführt wird, ist eine kontinuierliche bzw. quasi-kontinuierliche Überwachung der Integrität der Kommunikation durchführbar. Wenn das Ende eines Sendezyklus durch den Beginn eines anschließenden Sendezyklus signalisiert wird, wird für den neuen Sendezyklus bereits mitgehört und begonnen, die in dem neuen Sendezyklus übertragene Datenmenge zu ermitteln, während das Berechnen der erwarteten Datenmenge für den vorherigen Zyklus und das Vergleichen der ermittelten und der erwarteten Datenmenge für den abgeschlossenen Sendezyklus durchgeführt wird. Je nach Anwendungsfall kann auch eine stichprobenartige Überwachung ausreichen, die zyklisch regelmäßig oder in unregelmäßigen Abständen ausgeführt wird.
Das Verfahren kann auch über mehrere Sendezyklen hinweg ausgeführt werden, d.h. das Ermitteln der übertragenen Datenmenge und das Berechnen der erwarteten Datenmenge können über mehrere Sendezyklen hinweg erfolgen. Genauso kann das Verfahren für einen kürzeren Zeitraum als ein Sendezyklus ausgeführt werden, auch über Teile zweier aufeinanderfolgender Sendezyklen hinweg. Es wäre bspw. möglich, die Integrität der Kommunikation nur für eine Auswahl von Netzwerkgeräten zu überwachen. Die Bestimmung des „verkürzten Sendezyklus“ könnte in diesem Fall über den Node-ID- Zähler erfolgen. Grundsätzlich ist es also möglich, das Ermitteln der übertragenen Datenmenge innerhalb eines Sendezyklus zu beginnen und auch zu beenden, oder innerhalb eines ersten Sendezyklus zu beginnen und innerhalb eines später darauffolgenden Sendezyklus zu beenden, also nicht zwingend jeweils am Anfang und am Ende.
Selbstverständlich werden über das Kommunikationsmedium gesendete Daten, die an das das Verfahren ausführende Netzwerkgerät adressiert sind, nicht ausschließlich für die Ermittlung der übertragenen Datenmenge genutzt, sondern auch zur weiteren Verarbeitung an höhere Softwareschichten weitergeleitet. Gemäß einer oder mehrerer Ausführungsformen umfasst das Ermitteln einer innerhalb eines Sendezyklus übertragenen Datenmenge bzw. der Datenrate das Zählen aller über das Kommunikationsmedium innerhalb eines Sendezyklus übertragenen Datenbits bzw. Oktette, ggf. einschließlich der von einem das Verfahren durchführenden Netzwerkgerät selbst übertragenen, sofern es innerhalb des Sendezyklus eine Nachricht sendet. Diese Ausführungsform könnte bspw. auf dem Layer 1 des OSI-Schichtenmodells genutzt werden, wenn das das Verfahren ausführende Netzwerkgerät nicht zur Auswertung der Kommunikation auf einem höheren Layer des OSI-Schichtenmodells eingerichtet ist.
Gemäß einer oder mehrerer Ausführungsformen umfasst das Ermitteln einer innerhalb eines Sendezyklus übertragenen Datenmenge bzw. der Datenrate das Erkennen des Beginns und des Endes einer Übertragung eines Netzwerkgeräts. Die von einem jeweiligen Netzwerkgerät gesendete Datenmenge kann durch Multiplikation der zwischen Beginn und Ende der Übertragung liegenden Zeitdauer mit der nominellen Datenrate des gemeinsam genutzten Kommunikationsmediums berechnet werden. Die berechneten Datenmengen aller Netzwerkgeräte, die während eines Sendezyklus gesendet haben, werden aufsummiert.
Gemäß einer oder mehrerer Ausführungsformen umfasst das Ermitteln einer innerhalb eines Sendezyklus übertragenen Datenmenge bzw. der Datenrate das Auswerten von in Übertragungen eines Sendezyklus enthaltenen Informationen über die Anzahl der in der jeweiligen Übertragung übertragenen Datenbits bzw. Oktette, ggf. einschließlich der von einem das Verfahren durchführenden Netzwerkgerät selbst übertragenen, sofern es innerhalb des Sendezyklus eine Nachricht sendet. Abhängig davon, ob die Information die Gesamtanzahl der übertragenen Datenbits bzw. Oktette oder nur die Anzahl der als Nutzlast übertragenen Datenbits bzw. Oktette angibt kann die Anzahl der Datenbits bzw. Oktette um die für das Kommunikationsprotokoll benötigten Datenbits bzw. Oktette korrigiert werden, einschließlich der Anzahl der Datenbits bzw. Oktette, welche zur Initiierung und ggf. zum Beenden eines Sendezyklus gesendet werden.
Für das Ermitteln der innerhalb eines Sendezyklus übertragenen Datenmenge bzw. der Datenrate kann es erforderlich sein, dass die Netzwerkschnittstelle eines das Verfahren ausführenden Netzwerkgerätes in eine spezielle Betriebsart gebracht wird, in der auch Inhalte von nicht an das Netzwerkgerät gesendeten Übertragungen ausgewertet werden. Diese Betriebsart ist auch unter dem Begriff „promiscuous mode“ bekannt. Das Ermitteln der Anzahl der übertragenen Datenbits bzw. Oktette kann dann die Auswertung von in höheren Protokollschichten übertragenen Angaben über die in einer Übertragung gesendete Datenmenge umfassen.
Das für die Ermittlung der innerhalb eines Sendezyklus übertragenen Datenmenge bzw. der Datenrate genutzte Verfahren bzw. die dazu erfasste Art der Daten kann bspw. in Abhängigkeit von der Anzahl der über das gemeinsam genutzte Kommunikationsmedium miteinander verbundenen Netzwerkgeräte, der maximalen Dauer des TO-Zeitfensters und/oder der Dauer des den Beginn und das Ende des Sendezyklus kennzeichnenden Folge von Datenbits bzw. Oktetten ausgewählt werden. Bspw. kann bei einem Verfahren darauf verzichtet werden, eine oder mehrere Signalkomponenten, also bspw. die den Beginn und das Ende eines Sendezyklus kennzeichnende Folge von Datenbits bzw. Oktetten, die Dauer von nichtgenutzten TO-Zeitfenstern oder Commit-Signale, explizit mit zu erfassen, während in einem anderen Verfahren eine oder mehrere dieser Signalkomponenten explizit miterfasst werden. Insbesondere bei einer kleinen Anzahl von über das gemeinsam genutzte Kommunikationsmedium miteinander verbundener Netzwerkgeräte kann die Erfassung ausschließlich der von Netzwerkgeräten gesendeten Daten für das Ermitteln der innerhalb eines Sendezyklus übertragenen Datenmenge bzw. der Datenrate gewählt werden, weil die maximale Anzahl der nicht genutzten TO- Zeitfenster bzw. die Anzahl der Datenbits bzw. Oktette, die während deren Zeitdauern hätten gesendet werden können, nicht die kürzest mögliche Länge einer Übertragung eines Netzwerkgeräts erreichen. Wenn eine größere Anzahl an Netzwerkgeräten über das gemeinsam genutzte Kommunikationsmedium verbunden ist, oder wenn eines oder mehrere Netzwerkgeräte mehrere durch ein Commit-Signal verbundene Datenframes senden kann dagegen die Erfassung auch von Signalkomponenten nötig werden.
Gemäß einer oder mehrerer Ausführungsformen umfasst das Ermitteln einer innerhalb eines Sendezyklus übertragenen Datenmenge bzw. der Datenrate das Ersetzen eines vor dem Beginn einer Übertragung verstrichenen Zeitraums eines TO-Zeitfensters oder einer von einem Netzwerkgerät nicht genutzten Möglichkeit zur Übertragung durch die Anzahl der während des verstrichenen Zeitraums oder der Zeitdauer eines TO-Zeitfensters übertragbaren Datenbits bzw. Oktette. Die Anzahl von Bits, die theoretisch hätten gesendet werden können bevor das Netzwerkgerät tatsächlich angefangen hat zu senden oder die Anzahl der während eines TO-Zeitfensters übertragbaren Datenbits bzw. Oktette kann bspw. aus der nominellen Übertragungsgeschwindigkeit des gemeinsam genutzten Kommunikationsmediums und der verstrichenen Zeit errechnet werden. Diese Anzahl kann auch einer vorgegebenen Anzahl Datenbits entsprechen, die stellvertretend für die nicht genutzte Möglichkeit zur Übertragung für die Ermittlung der innerhalb eines Sendezyklus übertragenen Datenmenge berücksichtigt wird, weil ja während eines nicht genutzten TO-Zeitfensters keine Datenbits bzw. Oktette gesendet werden.
Bei einer oder mehreren Ausgestaltungen des Verfahrens werden die Node-IDs den Netzwerkgeräten vor oder bei der Inbetriebnahme des Systems fest zugewiesen. Es ist jedoch auch möglich, dass die Node-IDs während des Betriebs neu zugewiesen werden, bspw. zyklisch in festen Zeitabständen, um neu zu dem Netzwerk hinzukommenden Netzwerkgeräten den Zugang zu ermöglichen, oder um eine lückenlose Reihe von Node- IDs zu erhalten, etwa wenn ein Netzwerkgerät aus dem Netzwerk entfernt wurde. Letzteres kann von dem Netzwerkgerät in einer entsprechenden Nachricht bekannt gegeben werden, es kann aber bspw. auch dann angenommen werden, wenn ein Netzwerkgerät eine vorbestimmte Anzahl von TO-Zeitfenstern aufeinanderfolgender Sendezyklen nicht genutzt hat. Anstelle einer Neuzuweisung von Node-IDs in dem Fall, dass ein Netzwerkgerät eine vorbestimmte Anzahl von TO-Zeitfenstern aufeinanderfolgender Sendezyklen nicht genutzt hat, kann zumindest das das Verfahren ausführende Netzwerkgerät auch in eine Fehlerbetriebsart übergehen. Der vorbestimmte Wert kann für jedes Netzwerkgerät unterschiedlich sein und bei der Inbetriebnahme des Systems über Broadcast-Nachrichten bekanntgegeben werden oder in einem Speicher gespeichert sein, auf den das das Verfahren ausführende Netzwerkgerät Zugriff hat.
Gemäß einer oder mehrerer Ausführungsformen umfasst das Berechnen einer innerhalb eines Sendezyklus erwarteten Datenmenge das Multiplizieren der Zyklusdauer mit der nominellen Datenrate des Kommunikationsmediums. Diese Ausführungsform kann insbesondere dann genutzt werden, wenn Sendezyklen ohne größere Verzögerung unmittelbar aufeinander folgen.
Gemäß einem zweiten Aspekt der Erfindung umfasst ein Netzwerkgerät einen oder mehrere Prozessoren, diesem bzw. diesen zugeordneten flüchtigen und nichtflüchtigen Speicher sowie eine mit dem einen oder den mehreren Prozessoren kommunikativ verbundene, zum Senden und/oder Empfangen von über ein von mehreren Netzwerkgeräten gemeinsam genutztes Kommunikationsmedium eingerichtete physikalische Netzwerkschnittstelle. Die Elemente des Netzwerkgeräts sind mittels einer oder mehreren Datenleitungen oder -bussen kommunikativ miteinander verbunden. In dem nichtflüchtigen Speicher sind Computerprogramminstruktionen gespeichert welche, wenn sie von dem mindestens einen Prozessor ausgeführt werden, das Netzwerkgerät zur Ausführung einer oder mehrerer Ausführungsformen des erfindungsgemäßen Verfahrens einrichten.
Gemäß einem dritten Aspekt der Erfindung umfasst ein System, insbesondere ein Fahrzeugsystem, zwei oder mehr über ein von mehreren Netzwerkgeräten gemeinsam genutztes Kommunikationsmedium vernetzte Netzwerkgeräte. Erfindungsgemäß ist mindestens eines der Netzwerkgeräte dazu eingerichtet, zumindest eine Ausführungsform des weiter oben beschriebenen erfindungsgemäßen Verfahrens auszuführen.
Ein Computerprogrammprodukt gemäß einem vierten Aspekt der Erfindung enthält Befehle, die bei der Ausführung durch einen Computer diesen dazu veranlassen, eine oder mehrere Ausgestaltungen und Weiterentwicklungen des vorstehend beschriebenen Verfahrens ausführen.
Das Computerprogrammprodukt kann auf einem computerlesbaren Medium bzw. Datenträger gespeichert sein. Das Medium bzw. der Datenträger kann physisch verkörpert sein, bspw. als Festplatte, CD, DVD, Flash-Speicher oder dergleichen, das Medium bzw. der Datenträger kann aber auch ein moduliertes elektrisches, elektromagnetisches oder optisches Signal umfassen, das von einem Computer mittels eines entsprechenden Empfängers empfangen und in dem Speicher des Computers gespeichert werden kann.
Das vorstehend beschriebene Verfahren und die das Verfahren ausführenden Netzwerkgeräte können in vorteilhafter Weise ohne Änderungen an bereits existierender Hardware implementiert werden, und entsprechend in bereits bestehende Netzwerke integriert werden, da die bereits genutzten Protokolle nicht geändert werden müssen und die Funktion des Netzwerks nicht durch eine höhere Nutzung oder Latenzen beeinträchtigt wird.
Da die Integrität der Kommunikationskanäle im laufenden Betrieb überwacht wird, kann die Betriebssicherheit von Systemen, bspw. von Sensornetzwerken und von Steuergeräten, welche basierend auf Sensordaten Aktionen steuern und ausführen gesteigert werden, bspw. in Fahrzeugen mit einem hohen Grad an Fahrerunterstützung oder autonom fahrenden Fahrzeugen. Fehler können schnell erkannt werden und geeignete Maßnahmen können schneller getroffen werden, um den sicheren Betrieb wiederherzustellen oder in einen sicheren Betriebsmodus überzugehen.
Das vorstehend beschriebene Verfahren und die das Verfahren ausführenden Netzwerkgeräte können wegen der einfachen und schlanken Implementierung plattformunabhängig und daher flexibel eingesetzt werden.
KURZE BESCHREIBUNG DER ZEICHNUNG
Im Folgenden wird die Erfindung mit Bezug auf die Zeichnung exemplarisch erläutert. In der Zeichnung zeigt:
Fig. 1 ein beispielhaftes aus dem Stand der Technik bekanntes Netzwerk mit vier über einen Switch verbundenen Netzwerkgeräten,
Fig. 2 ein beispielhaftes aus dem Stand der Technik bekanntes Netzwerk mit fünf über eine 10BASE2 oder 10BASE5 verbundenen Netzwerkgeräten,
Fig. 3 ein beispielhaftes aus dem Stand der Technik bekanntes Netzwerk mit fünf über ein verdrilltes Aderpaar verbundenen Netzwerkgeräten, Fig. 4 eine beispielhafte Darstellung der von Netzwerkgeräten in der Reihenfolge ihrer Node-IDs über das gemeinsam genutzte Kommunikationsmedium gesendeten Nachrichten
Fig. 5 das Netzwerk aus Figur 3 mit einem Fehler in der Netzwerkschnittstelle eines Netzwerkgeräts,
Fig. 6 eine beispielhafte Darstellung eines Fehlers in einem Netzwerkgerät in der Abfolge der von den Netzwerkgeräten in der Reihenfolge ihrer Node-IDs über das gemeinsam genutzte Kommunikationsmedium gesendeten Nachrichten,
Fig. 7 das Netzwerk aus Figur 3 mit einem auf die Busleitung einwirkenden Fehler,
Fig. 8 eine beispielhafte Darstellung einer transienten, auf die Busleitung einwirkenden Störung in der Abfolge der von den Netzwerkgeräten in der Reihenfolge ihrer Node-IDs über das gemeinsam genutzte Kommunikationsmedium gesendeten Nachrichten,
Fig. 9 ein schematisches Flussdiagramm des prinzipiellen Ablaufs des Verfahrens,
Fig. 10 ein beispielhaftes schematisches Flussdiagramm des Mithörens der Kommunikation auf dem gemeinsam genutzten Kommunikationsmedium,
Fig. 11 ein beispielhaftes schematisches Flussdiagramm für die Auswahl eines von zwei Möglichkeiten für das Ermitteln der während eines Sendezyklus über das gemeinsam genutzte Kommunikationsmedium übertragenen Datenmenge in Abhängigkeit von Parametern des gemeinsam genutzten Kommunikationsmediums und des Netzwerks,
Fig. 12 ein beispielhaftes schematisches Flussdiagramm eines alternativen Verfahrens für die Auswahl eines von zwei Messverfahren für das Ermitteln der während eines Sendezyklus über das gemeinsam genutzte Kommunikationsmedium übertragenen Datenmenge in Abhängigkeit von Parametern des gemeinsam genutzten Kommunikationsmediums und des Netzwerks, wenn mindestens ein Netzwerkgerät Nachrichten im Burst-Mode sendet,
Fig. 13 ein beispielhaftes schematisches Flussdiagramm für die Bestimmung der Integrität der Kommunikation während eines Sendezyklus,
Fig. 14 einen ersten Teil eines beispielhaften schematischen Flussdiagramms eines Verfahrens für das Ermitteln der innerhalb eines Sendezyklus gesendeten Datenbits bzw. Oktette auf dem physikalischen Layer, Fig. 15 einen zweiten Teil eines beispielhaften schematischen Flussdiagramms eines Verfahrens zum Ermitteln einer innerhalb eines Sendezyklus übertragenen Datenmenge auf dem physikalischen Layer, und
Fig. 16 ein exemplarisches Blockdiagramm eines zur Ausführung eines oder mehrerer Aspekte des erfindungsgemäßen Verfahrens eingerichteten Netzwerkgeräts.
Gleiche oder ähnliche Elemente können in den Figuren mit denselben Bezugszeichen referenziert sein.
Die Figuren 1 bis 8 wurden bereits weiter oben beschrieben und werden daher im Folgenden nicht erneut diskutiert.
BESCHREIBUNG VON AUSFÜHRUNGSBEISPIELEN
Figur 9 zeigt ein schematisches Flussdiagramm des prinzipiellen Ablaufs des Verfahrens 100. In Schritt 110 wird die Kommunikation auf dem gemeinsam genutzten Kommunikationsmedium mitgehört bzw. überwacht, wobei zumindest Folgen von Datenbits bzw. Oktetten erkannt und ausgewertet werden, welche den Beginn und das Ende einer Übertragung durch ein Netzwerkgerät kennzeichnen, sowie von Netzwerkgeräten innerhalb eines Sendezyklus nicht genutzten Sendemöglichkeiten erkannt und ausgewertet werden. Sobald der Beginn eines Sendzyklus erkannt wurde beginnt, in Schritt 120, die Bestimmung dessen Dauer. Dazu kann bspw. die zwischen zwei aufeinanderfolgenden Folgen den Beginn eines Sendezyklus repräsentierender Datenbits verstrichene Zeit gemessen werden.
Parallel dazu wird, in Schritt 130, die während des Sendezyklus über das gemeinsam genutzte Kommunikationsmedium übertragenen Datenmenge ermittelt, bspw. durch Zählen der über das gemeinsam genutzte Kommunikationsmedium übertragenen Datenbits oder Oktette oder auf andere Weise. Hierbei können auch Daten aus der Überwachung in Schritt 110 genutzt werden, wie durch den separaten Pfeil angedeutet, bspw. während der Überwachung erkannte spezielle Folgen von Datenbits bzw. Oktetten, die der Steuerung der Übertragung dienen. In Schritt 140 wird eine innerhalb des Sendezyklus erwartete Datenmenge berechnet. Dies kann u.a. auf Basis der Dauer des Sendezyklus und der nominellen Datenrate des gemeinsam genutzten Kommunikationsmediums sowie der Anzahl der darüber verbundenen Netzwerkgeräte erfolgen. Dazu wird die Dauer in Schritt 120 bestimmte Dauer des Sendezyklus zugeführt, wie durch den Pfeil angedeutet ist.
In Schritt 150 wird die Integrität der Kommunikation über das gemeinsam genutzte Kommunikationsmedium überprüft. Die Bestimmung der Integrität erfolgt bspw. durch einen Vergleich der berechneten erwarteten Datenmenge mit der durch Überwachung der Kommunikation ermittelten Datenmenge. Es ist auch möglich, aus der durch Überwachung der Kommunikation ermittelten Datenmenge und der Dauer des Sendezyklus eine Datenrate zu berechnen, welche mit der nominellen Datenrate des gemeinsam genutzten Kommunikationsmediums verglichen wird. Dabei kann ein Toleranzbereich dazu genutzt werden, eine wegen der fehlenden Synchronisation der Netzwerkgeräte untereinander unvermeidbare Messungenauigkeit und ggf. geringfügig voneinander abweichende Sendedatenraten unterschiedlicher Netzwerkgeräte bei der Bestimmung der Integrität zu unterdrücken.
Figur 10 zeigt ein beispielhaftes schematisches Flussdiagramm des Mithörens bzw. Überwachens, in Schritt 110, der Kommunikation auf dem gemeinsam genutzten Kommunikationsmedium. Zwischen zwei den Beginn und das Ende eines Sendezyklus repräsentierenden Folgen von Datenbits sind nur Nutzdaten sowie Signale zu erwarten, welche den ordnungsgemäßen Ablauf der Kommunikation der Netzwerkgeräte steuern. Netzwerkgeräte, welche im sogenannten Promiscuous-Mode betrieben werden können, können neben den Adressdaten von nicht an sie adressierten Datenpaketen auch den weiteren Inhalt der Übertragungen mithören, zumindest aber die Anzahl der Datenbits bzw. Oktette auch von nicht an sie gerichteter Übertragungen zählen. In Schritt 111 werden entsprechend Daten einer Übertragung empfangen, und in Schritt 112 wird die Länge der Übertragung bestimmt oder extrahiert, also die Anzahl der Datenbits oder Oktette. Wenn ein das Verfahren ausführendes Netzwerkgerät auch den Inhalt von nicht an das Netzwerkgerät gerichteten Übertragungen auswerten kann, bspw. eine in einem Header enthaltene Information über die Länge einer Übertragung, ist das Zählen aller Datenbits oder Oktette der Übertragung nicht erforderlich. In diesem Fall genügt es, wenn das Netzwerkgerät das Ende einer Übertragung feststellen kann, bspw. durch Empfang eines das Ende eines Datenframes repräsentierendes Signal (EOF) oder eines anderen in einem verwendeten Protokoll vereinbarten Signals. Sollte die Übertragung an das das Verfahren ausführende Netzwerkgerät gerichtet sein, was durch eine Überprüfung in Schritt 113 ermittelt wird, werden die empfangenen Datenbits oder Oktette auch zur weiteren Verarbeitung in höheren Protokollschichten in Schritt 114 weitergeleitet. Anderenfalls können die nicht für die Bestimmung der übertragenen Datenmenge erforderlichen Daten in Schritt 115 verworfen werden, sofern sie nicht für andere Zwecke von dem das Verfahren ausführenden Netzwerkgerät genutzt werden. Das Mithören bzw. Überwachen der Kommunikation auf dem gemeinsam genutzten Kommunikationsmedium wird zumindest solange wiederholt, bis ein das Ende eines Sendezyklus repräsentierendes Signal empfangen wird, also eine entsprechende Folge von Datenbits.
Figur 11 zeigt ein beispielhaftes schematisches Flussdiagramm für die Auswahl einer von zwei Möglichkeiten für das Ermitteln, in Schritt 130, der während eines Sendezyklus über das gemeinsam genutzte Kommunikationsmedium übertragenen Datenmenge in Abhängigkeit von Parametern des gemeinsam genutzten Kommunikationsmediums und des Netzwerks. Zunächst wird in Schritt 1301 die Anzahl der über das gemeinsam genutzte Kommunikationsmedium verbundenen Netzwerkgeräte, in Schritt 1302 die Anzahl Datenbits bzw. Oktette in der den Beginn eines Sendezyklus und ggf. der das Ende eines Sendezyklus repräsentierenden Folge von Datenbits, und in Schritt 1303 die Anzahl der Datenbits bzw. Oktette bestimmt, welche dem TO-Zeitfenster entsprechen. Diese Informationen über die auch als Signalkomponenten bezeichneten Parameter des für die Kommunikation genutzten Protokolls können bspw. aus einer Konfigurationsdatei ausgelesen werden, welche allen das Verfahren durchführenden Netzwerkgeräten lokal oder über das Netzwerk zugänglich ist. In Schritt 1305 wird geprüft, ob die Gesamtzahl der Datenbits bzw. Oktette der Signalkomponenten, die sich aus der Summe der Anzahl Datenbits bzw. Oktette in der den Beginn eines Sendezyklus und ggf. der das Ende eines Sendezyklus repräsentierenden Folge von Datenbits und dem Produkt der Anzahl der über das gemeinsam genutzte Kommunikationsmedium verbundenen Netzwerkgeräte und der Anzahl von das TO-Zeitfenster repräsentierenden Datenbits bzw. Oktetten ergibt, zuzüglich einer Messungenauigkeit, gleich oder größer ist als die Anzahl von Datenbits bzw. Oktetten der kürzest möglichen Übertragung eines Netzwerkgeräts, bspw. die kürzeste Länge eines Datenframes. Falls die größtmögliche Gesamtzahl der Datenbits bzw. Oktette der Signalkomponenten gleich oder größer ist als die Anzahl der Datenbits bzw. Oktette der kürzest möglichen Übertragung eines Netzwerkgeräts wird in Schritt 1306, zusätzlich zu der Ermittlung der Anzahl der in den Nachrichten der Netzwerkgeräte übertragenen Datenbits bzw. Oktette in Schritt 1307, die Anzahl der Datenbits bzw. Oktette der Signalkomponenten erfasst.
Figur 12 zeigt ein beispielhaftes schematisches Flussdiagramm eines alternativen Verfahrens für die Auswahl eines von zwei Messverfahren für das Ermitteln, in Schritt 130, der während eines Sendezyklus über das gemeinsam genutzte Kommunikationsmedium übertragenen Datenmenge in Abhängigkeit von Parametern des gemeinsam genutzten Kommunikationsmediums und des Netzwerks, wenn mindestens ein Netzwerkgerät Nachrichten im Burst-Mode sendet. Die Schritte 1301 , 1302 und 1303 entsprechen den mit Bezug auf Figur 11 beschriebenen. Zusätzlich wird in Schritt 1304 die Anzahl der Netzwerkgeräte bestimmt, die in einer Nachricht mehrere aufeinanderfolgende Datenframes im Burst-Mode senden. Wenn mindestens ein Netzwerkgerät im Burst-Mode sendet, kann eine größere Anzahl von Datenbits bzw. Oktetten für Signalkomponenten innerhalb eines Sendezyklus vorkommen, u.a. weil im Burst-Mode ein Netzwerkgerät bis zu 255 Datenframes hintereinander senden kann, und auf einen gesendeten Datenframe jeweils ein Commit-Signal gesendet wird, welches den anderen Netzwerkgeräten im Netzwerk zu erkennen gibt, dass das derzeit aktiv auf das Kommunikationsmedium zugreifende Netzwerkgerät weitere Datenframes senden wird. Je mehr Netzwerkgeräte zusätzliche Datenbits bzw. Oktette für Signalkomponenten senden, desto eher kann daher allein durch die Summe der Datenbits bzw. Oktette der Signalkomponenten die Anzahl der Datenbits bzw. Oktette in der kürzest möglichen Nachricht eines Netzwerkgeräts erreicht bzw. überschritten werden, so dass es notwendig wird, auch die Datenbits bzw. Oktette der Signalkomponenten zu erfassen und in die Berechnung der Anzahl der übertragenen Datenbits bzw. Oktette oder der Datenrate für einen Sendezyklus einfließen zu lassen. Bei der Prüfung in Schritt 1305 wird entsprechend bei der Bestimmung der Anzahl von Datenbits bzw. Oktetten für Signalkomponenten zu der mit Bezug auf Schritt 1305 in Figur 11 beschriebenen Summe das Produkt aus der Anzahl der im Burst-Mode sendenden Netzwerkgeräte, der Anzahl von Datenbits bzw. Oktetten der zusätzlichen TO-Zeitfenster und der maximalen Anzahl von Datenpaketen im Burst-Mode, also 255, hinzugefügt. Wenn diese erweiterte Summe, abzüglich einer Messungenauigkeit, gleich oder größer ist als die Anzahl von Datenbits bzw. Oktetten der kürzest möglichen Übertragung eines Netzwerkgeräts wird, wie in dem mit Bezug auf Figur 11 beschriebenen Beispiel, in Schritt 1306, zusätzlich zu der Ermittlung der Anzahl der in den Nachrichten der Netzwerkgeräte übertragenen Datenbits bzw. Oktette in Schritt 1307, die Anzahl der Datenbits bzw. Oktette der Signalkomponenten erfasst.
Figur 13 zeigt ein beispielhaftes schematisches Flussdiagramm der Schritte eines Verfahrens 150 für die Bestimmung der Integrität der Kommunikation während eines Sendezyklus. Dazu wird in Schritt 151 zunächst eine „reale Buslast“ bestimmt, indem von der Anzahl der während der der Dauer des Sendezyklus maximal mit der nominellen Datenrate übertragbaren Datenbits bzw. Oktetten die Anzahl der tatsächlich über das gemeinsam genutzte Kommunikationsmedium übertragenen Datenbits bzw. Oktette subtrahiert wird. In Schritt 152 wird geprüft, ob die reale Buslast eine positive Zahl ist. Falls dies nicht der Fall ist, falls also mehr Datenbits bzw. Oktette innerhalb des betrachteten Zyklus übertragen wurden, als theoretisch möglich gewesen wäre, muss eine erste Art Fehler vorliegen, und das Verfahren folgt dem „nein“-Zweig zum Schritt 156, in welchem dieser Fehler signalisiert und/oder anders behandelt wird. Ein solcher Fehler kann bspw. dadurch entstehen, dass das Ende eines Sendezyklus nicht erkannt wurde. Falls die reale Buslast eine positive Zahl ist folgt das Verfahren dem „ja“-Zweig und es wird als nächstes geprüft, in Schritt 153, ob die die reale Buslast repräsentierende Zahl größer ist als die Anzahl der Datenbits bzw. Oktette der kürzest möglichen Übertragung eines Netzwerkgeräts, bspw. die kürzeste Länge eines Datenframes. Wenn dies nicht der Fall ist folgt das Verfahren dem „nein“-Zweig zum Schritt 154, der bspw. das Warten auf die Bestimmung der Integrität der Kommunikation für den nächsten Sendezyklus umfassen kann. Falls die die reale Buslast repräsentierende Zahl größer ist als die Anzahl der Datenbits bzw. Oktette der kürzest möglichen Übertragung eines Netzwerkgeräts ist mindestens ein Datenframe verloren gegangen, und das Verfahren folgt dem „ja“-Zweig zum Schritt 155. In Schritt 155 wird diese zweite Art Fehler signalisiert und/oder anders behandelt.
Figur 14 zeigt einen ersten Teil eines beispielhaften schematischen Flussdiagramms eines Verfahrens 1100 für das Mithören und eines Verfahrens 1300 für das Ermitteln der innerhalb eines Sendezyklus gesendeten Datenbits bzw. Oktette auf dem physikalischen Layer, also dem Layer 1 des OSI-Schichtenmodells. Dieses Verfahren kann bspw. genutzt werden, wenn ein das erfindungsgemäße Verfahren ausführendes Netzwerkgerät das Mithören der nicht für das Netzwerkgerät selbst bestimmten Kommunikation auf dem Layer 2 nicht unterstützt, die Layer 2 Frames also nicht analysiert werden können. Bei diesem Verfahren werden auch diejenigen Datenbits bzw. Oktette direkt erfasst, welche für die Signalisierung verwendet werden, also bspw. die den Start eines Sendezyklus (Beacon), den Beginn (SOF) oder das Ende einer Übertragung (EOF), und die eine Weiterbelegung (Commit) signalisierenden Folgen von Datenbits bzw. Oktetten.
Ggf. kann vor dem Beginn des Verfahrens eine Initialisierung des das Verfahren ausführenden Netzwerkgeräts erfolgen, bei dem bspw. die Anzahl der Datenbits bzw., Oktette einer den Beginn bzw. das Ende eines Sendezyklus kennzeichnenden Nachricht, die Anzahl der Netzwerkgeräte sowie deren Eigenschaften und dergleichen aus einer Datenbank gelesen werden (nicht in der Figur gezeigt).
Zunächst wird in Schritt 1101 geprüft, ob eine den Beginn eines neuen Sendezyklus kennzeichnende Folge von Datenbits bzw. Oktetten empfangen wurde. Falls dies nicht der Fall ist, wird in den „nein“-Zweig von Schritt 1101 abgezweigt und die Prüfung wird wiederholt.
Wenn eine den Beginn eines neuen Sendezyklus kennzeichnende Folge von Datenbits bzw. Oktetten empfangen wurde verzweigt das Verfahren zum einen in den „ja“-Zweig zu den durch die Schritte 140 und 150 repräsentierten Verfahren ab, in welchen die innerhalb des vorangegangenen Sendezyklus erwartete Datenmenge berechnet und die Integrität der Kommunikation für den vorangegangenen Zyklus überprüft wird. Ein Flussdiagramm eines exemplarischen Verfahrens 150, welches bei der Analyse auf dem Layer 1 des OSI-Schichtenmodells genutzt werden kann, ist weiter unten mit Bezug auf Figur 15 beschrieben. Die Anzahl von Datenbits bzw. Oktetten, die während des Wartens auf eine den Beginn eines neuen Sendezyklus kennzeichnende Folge von Datenbits bzw. Oktetten hätten gesendet werden können, wird in Schritt 1301 a ermittelt bzw. bestimmt und bei der Überprüfung der Integrität der Kommunikation entsprechend berücksichtigt, angedeutet durch den gestrichelten Pfeil von Schritt 1301a zum Schritt 140.
Parallel zur Überprüfung der Integrität der Kommunikation werden in Schritt 1102 jeweilige Zähler für das Netzwerkgerät, welches als nächstes Senden darf, für die von Netzwerkgeräten nichtgenutzten TO-Zeitfenster und für die während des aktuellen Sendezeitraums übertragene Anzahl Datenbits bzw. Oktette, sowie in Schritt 1103 ein Timeout-Zähler für das aktuelle TO-Zeitfenster zurückgesetzt und gestartet. In Schritt 1104 wird geprüft, ob alle Netzwerkgeräte im aktuellen Sendezyklus die Gelegenheit hatten zu senden, d.h., ob der Zähler für das Netzwerkgerät, welches als nächstes senden darf, einen Wert erreicht hat, der dem letzten Netzwerkgerät in der Gruppe der über das gemeinsam genutzte Kommunikationsmedium verbundenen Netzwerkgeräte entspricht. Falls dies der Fall ist, falls also alle Netzwerkgeräte die Gelegenheit hatten, während des aktuellen Sendezyklus eine Nachricht zu übertragen, folgt das Verfahren dem „ja“-Zweig von Schritt 1104 zurück zu Schritt 1101 , in welchem auf den Beginn des nächsten Sendezyklus gewartet wird. Anderenfalls folgt das Verfahren dem „nein“-Zweig von Schritt 1104 zu Schritt 1301 , in welchem alle auf dem gemeinsam genutzten Kommunikationsmedium gesendeten Datenbits bzw. Oktette empfangen und gezählt werden.
Empfangene Folgen von Datenbits bzw. Oktetten werden in Schritt 1302 darauf hin überprüft, ob sie den Beginn einer Übertragung durch ein Netzwerkgerät kennzeichnen, bspw. ein Start-of-Frame-Signal oder dergleichen bilden. Falls dies der Fall ist folgt das Verfahren dem „ja“-Zweig von Schritt 1302 und wartet, in Schritt 1303, auf eine Folge von Datenbits oder Oktetten, die das Ende einer Übertragung durch ein Netzwerkgerät kennzeichnen. Parallel dazu werden die empfangenen Datenbits bzw. Oktette in Schritt 1304 darauf überprüft, ob statt einer das Ende der Übertragung kennzeichnenden Folge von Datenbits bzw. Oktetten eine den Beginn eines neuen Sendezyklus kennzeichnende Folge von Datenbits bzw. Oktetten empfangen wurde. Ist dies der Fall, „ja“-Zweig von Schritt 1304, muss ein Fehler vorliegen, und das Verfahren wird mit Schritt 1305 fortgeführt. In Schritt 1305 kann bspw. das das Verfahren ausführende Netzwerkgerät in eine Fehlerbetriebsart versetzt werden und/oder das Netzwerkgerät kann den erkannten Fehler über das Netzwerk bekanntgeben.
Wenn in Schritt 1303 eine Folge von Datenbits oder Oktetten empfangen wird, die das Ende einer Übertragung durch ein Netzwerkgerät kennzeichnen, „ja“-Zweig von Schritt 1303, wird in Schritt 1306 der Zähler für das Netzwerkgerät, welches als nächstes Senden darf, inkrementiert und das Verfahren mit Schritt 1104 fortgesetzt. Wie bereits weiter oben beschrieben wird in Schritt 1104 geprüft, ob alle Netzwerkgeräte im aktuellen Sendezyklus die Gelegenheit hatten zu senden. Fall dies nicht der Fall ist wird der mit Schritt 1301 beginnende Teil des Verfahrens für das nächste Netzwerkgerät fortgesetzt.
Wenn die Prüfung in Schritt 1302 keine Folge von Datenbits bzw. Oktetten findet, welche den Beginn einer Übertragung durch ein Netzwerkgerät kennzeichnet, folgt das Verfahren dem „nein“-Zweig von Schritt 1302 und prüft in Schritt 1307, ob eine empfangene Folge von Datenbits bzw. Oktetten den Beginn eines Sendezyklus kennzeichnet. Ist dies der Fall, „ja“-Zweig von Schritt 1304, muss ein Fehler vorliegen, weil noch nicht alle über das gemeinsam genutzte Kommunikationsmedium verbundenen Netzwerkgeräte die Möglichkeit hatten, eine Nachricht zu senden oder zumindest deren jeweilige TO- Zeitfenster verstreichen zu lassen, und das Verfahren wird mit Schritt 1305 fortgesetzt. Wie weiter oben bereits beschrieben kann in Schritt 1305 bspw. das das Verfahren ausführende Netzwerkgerät in eine Fehlerbetriebsart versetzt werden und/oder das Netzwerkgerät kann den erkannten Fehler über das Netzwerk bekanntgeben. Wenn in Schritt 1307 keine den Beginn eines Sendezyklus kennzeichnende Folge von Datenbits bzw. Oktetten erkannt wurde, „nein“-Zweig von Schritt 1304, wird in Schritt 1308 überprüft, ob der Timeout-Zähler für das aktuelle TO-Zeitfenster abgelaufen ist. Ist dies nicht der Fall, „nein“-Zweig von Schritt 1308, wird, während das gemeinsam genutzte Kommunikationsmedium unbenutzt, d.h. idle ist, so lange weiter empfangen bzw. gewartet, ob ein den Beginn einer Übertragung markierendes Datenbit oder eine den Beginn einer Übertragung kennzeichnende Folge von Datenbits bzw. Oktetten erkannt wurde, d.h. also ob das Netzwerkgerät zu senden begonnen hat, bis der Timeout-Zähler abgelaufen ist.
Wenn der Timeout-Zähler für das aktuelle TO-Zeitfenster abgelaufen ist, „ja“-Zweig von Schritt 1308, wird in Schritt 1309 der Zähler für die von Netzwerkgeräten nichtgenutzten TO-Zeitfenster inkrementiert und das Verfahren mit Schritt 1308 fortgesetzt.
Alle in der Zwischenzeit empfangenen Datenbits bzw. Oktette, einschließlich der den Beginn bzw. das Ende einer Übertragung kennzeichnenden Folgen von Datenbits bzw. Oktetten, werden durch den parallel zu den Überprüfungen der empfangenen Datenbits bzw. Oktette laufenden Schritt 1301 gezählt. Die Anzahl der Datenbits bzw. Oktette, die zwischen dem Beginn des TO-Zeitfensters und dem Beginn der Übertragung durch ein Netzwerkgerät hätten gesendet werden können, wird entweder an dieser Stelle zu der Anzahl der über das gemeinsam genutzte Kommunikationsmedium gesendeten Datenbits bzw. Oktette hinzugerechnet, oder später bei der Prüfung der Integrität der Kommunikation.
Datenbits bzw. Oktette, die für das das Verfahren ausführende Netzwerkgerät bestimmt sind, werden an höhere Protokollschichten weitergeleitet (nicht in der Figur gezeigt).
Die mit dem vorstehend beschriebenen Verfahren jeweils von einem Netzwerkgerät, das gerade auf das gemeinsam genutzte Kommunikationsmedium zugreifen darf, gesendete bzw. für dieses Netzwerkgerät ermittelte Datenmenge wird zu der Datenmenge addiert, welche während des aktuellen Sendezyklus bereits von anderen Netzwerkgeräten gesendet bzw. für diese ermittelt wurde.
Figur 15 zeigt ein exemplarisches Flussdiagramm der Schritte zur Bestimmung der Dauer eines Sendezyklus und zur Überprüfung der Integrität der Kommunikation für einen Sendezyklus. In Schritt 120 wird die Zeit berechnet, welche zwischen dem Empfang einer den Beginn eines Sendezyklus kennzeichnenden Folge von Datenbits bzw. Oktetten und dem Empfang einer das Ende eines Sendezyklus kennzeichnenden Folge von Datenbits bzw. Oktetten verstrichen ist. Wie zuvor bereits erwähnt kann das Ende ein Sendezyklus auch durch den Beginn eines nachfolgenden Sendezyklus signalisiert werden. Zur Berechnung kann bspw. ein Timer genutzt werden, welcher mit dem Beginn eines Sendezyklus gestartet wird und am Ende eines Sendezyklus angehalten wird. Es ist auch möglich eine Systemzeit am Beginn und am Ende eines Sendezyklus in einen Speicher zu schreiben und daraus die Dauer des Sendezyklus zu berechnen. Andere dem Fachmann geläufige Wege zur Bestimmung der Dauer des Sendezyklus sind denkbar und werden an dieser Stelle nicht im Detail erläutert.
Anschließend wird in Schritt 140 eine innerhalb des Sendezyklus erwartete Datenmenge berechnet. Dies kann bspw. auf Basis der Dauer des Sendezyklus und der nominellen Datenrate des gemeinsam genutzten Kommunikationsmediums erfolgen.
In Schritt 150 wird die in dem parallel zur Bestimmung der Dauer des Sendezyklus laufenden Schritt 130 ermittelte, während des Sendezyklus über das gemeinsam genutzte Kommunikationsmedium übertragene Datenmenge mit der in Schritt 140 berechneten erwarteten Datenmenge verglichen. Falls nicht schon bei der Bestimmung der übertragenen Datenbits bzw. Oktette die während eines nicht genutzten TO-Zeitfensters theoretisch übertragbaren Datenbits bzw. Oktette berücksichtigt wurden werden diese in Schritt 1399 durch Multiplikation der Anzahl der Netzwerkgeräte, welche nicht gesendet haben mit der Anzahl der während eines TO-Zeitfensters theoretisch übertragbaren Datenbits bzw. Oktette bestimmt und zu den tatsächlich empfangenen Datenbits bzw. Oktette addiert. Wenn der Vergleich ergibt, dass die innerhalb des Sendezyklus erwartete Datenmenge mit der tatsächlich gesendeten Datenmenge, ggf. innerhalb eines festgelegten Toleranzfensters, übereinstimmt, „ja“-Zweig von Schritt 150, ist die Integrität der Kommunikation während des überprüften Sendezyklus gegeben, und das Verfahren kann für den nachfolgenden Sendezyklus wiederholt werden. Falls der Vergleich ergibt, dass mehr oder weniger Datenbits bzw. Oktette innerhalb des Sendezyklus übertragen wurden als theoretisch hätten übertragen werden können, „nein“-Zweig von Schritt 150, ist die Integrität der Kommunikation über das gemeinsam genutzte Kommunikationsmedium nicht gegeben und das das das Verfahren ausführende Netzwerkgerät kann in einen Fehlerbetrieb übergehen und/oder das Ergebnis der Überprüfung an andere Netzwerkgeräte weiterleiten. Dabei können, abhängig davon, ob mehr oder weniger Datenbits bzw. Oktette übertragen wurden als erwartet, das Netzwerkgerät in unterschiedliche Fehlerbetriebsmodi übergehen. Die möglichen Fehlerbetriebsarten können die Nutzung eines anderen Verfahrens für den Zugriff auf das gemeinsam genutzte Kommunikationsmedium, bspw. CSMA/CD, ein erweitertes Protokollieren der Kommunikation über das gemeinsam genutzte Kommunikationsmedium, das Versetzen des Systems in einen sicheren Betrieb, das Absetzen einer oder mehrerer Nachrichten an ein entfernt angeordnetes System oder dergleichen umfassen.
Figur 16 zeigt ein exemplarisches Blockdiagramm eines zur Ausführung eines oder mehrerer Aspekte des erfindungsgemäßen Verfahrens eingerichteten Netzwerkgeräts 400. Das Netzwerkgerät 400 umfasst neben einem Mikroprozessor 402 flüchtigen und nichtflüchtigen Speicher 404, 406 sowie eine Kommunikationsschnittstelle 408. Die Elemente des Netzwerkgeräts sind über eine oder mehrere Datenverbindungen oder - busse 410 kommunikativ miteinander verbunden. Der nichtflüchtige Speicher 406 enthält Computerprogramminstruktionen die, wenn sie von dem Mikroprozessor 402 ausgeführt werden, das Netzwerkgerät zur Ausführung zumindest einer Ausgestaltung des erfindungsgemäßen Verfahrens einrichten.
BEZUGSZEICHENLISTE
10 System 400 Netzwerkgerät
12 Netzwerkgerät 402 Mikroprozessor
12a Anschlussbox 404 flüchtiger Speicher
14 Netzwerkgerät 406 nichtflüchtiger Speicher
14a Anschlussbox 408 Kommunikationsschnittstelle
16 Netzwerkgerät/Switch 410 Datenverbindungen /-busse
16a Anschlussbox
18 Netzwerkgerät 1100 Mithören
18a Anschlussbox 1101 - 1104 Verfahrensschritte „Mithören“
20 Netzwerkgerät
20a Anschlussbox 1300 gesendete Datenmenge ermitteln
22 Koaxialkabel 1301 - 1307 Verfahrensschritte
24 Kommunikationsmedium/Aderpaar „gesendete Datenmenge ermitteln“
100 Verfahren 1399 Korrektur nicht gesendeter Datenbits
110 Mithören bzw. Oktette
120 Sendezyklusdauer bestimmen
130 gesendete Datenmenge ermitteln
140 erwartete Datenmenge berechnen
150 Integrität überprüfen
111-115 Verfahrensschritte „Mithören

Claims

ANSPRÜCHE
1 . Verfahren (100) zur Überwachung der Integrität der Kommunikation zwischen mehreren über ein gemeinsam genutztes Kommunikationsmedium (24) verbundenen Netzwerkgeräten (12, 14, 16, 18, 20), welche innerhalb eines durch ein erstes Netzwerkgerät initiierten Sendezyklus jeweils eine Nachricht über das gemeinsam genutzte Kommunikationsmedium (24) senden können, umfassend:
- Mithören (110) zumindest bestimmter Teile der Kommunikation auf dem Kommunikationsmedium innerhalb eines Sendezyklus, wobei das Mithören (110) zumindest das Erkennen und/oder Auswerten von Datenbits bzw. Folgen von Datenbits bzw. Oktetten umfasst, welche den Beginn und das Ende des Sendezyklus kennzeichnen, wobei das Mithören außerdem das Erkennen und/oder Auswerten einer von einem Netzwerkgerät innerhalb eines Sendezyklus nicht genutzten Sendemöglichkeit umfasst, wobei das Verfahren gekennzeichnet ist durch die Schritte:
- Bestimmen (120) der Dauer eines Sendezyklus,
- Ermitteln (130) einer innerhalb des Sendezyklus übertragenen Datenmenge oder einer für den Sendezyklus erreichten Datenrate,
- Berechnen (140) einer innerhalb des Sendezyklus erwarteten Datenmenge,
- Vergleichen (150) der ermittelten und der erwarteten Datenmenge oder der ermittelten Datenrate mit einer nominellen Datenrate des Kommunikationsmedium wobei, wenn die ermittelte und die erwartete Datenmenge bzw. die ermittelte und die nominelle Datenrate innerhalb eines vorbestimmten Toleranzbereichs übereinstimmen, das Verfahren für einen nachfolgenden Sendezyklus erneut ausgeführt wird und anderenfalls zumindest ein das Verfahren ausführendes Netzwerkgerät in einen Fehlermodus übergeht.
2. Verfahren (100) nach Anspruch 1 , wobei das Ermitteln (130) der innerhalb eines Sendezyklus übertragenen Datenmenge bzw. der Datenrate das Zählen aller über das Kommunikationsmedium (24) innerhalb eines Sendezyklus übertragenen Datenbits bzw. Oktette, ggf. einschließlich der von einem das Verfahren durchführenden Netzwerkgerät selbst übertragenen umfasst.
3. Verfahren (100) nach Anspruch 1 , wobei das Ermitteln (130) der innerhalb eines Sendezyklus übertragenen Datenmenge bzw. der Datenrate das Erkennen des Beginns und des Endes einer Übertragung eines Netzwerkgeräts umfasst, wobei die von einem jeweiligen Netzwerkgerät gesendete Datenmenge durch Multiplikation der zwischen Beginn und Ende der Übertragung liegenden Zeitdauer mit der nominellen Datenrate des gemeinsam genutzten Kommunikationsmediums berechnet wird, und wobei die berechneten Datenmengen aller Netzwerkgeräte, die während eines Sendezyklus gesendet haben, aufsummiert werden.
4. Verfahren (100) nach Anspruch 1 , wobei das Ermitteln (130) der innerhalb eines Sendezyklus übertragenen Datenmenge bzw. der Datenrate das Auswerten von in Übertragungen eines Sendezyklus enthaltenen Informationen über die Anzahl der in der jeweiligen Übertragung übertragenen Datenbits bzw. Oktette, ggf. einschließlich der von einem das Verfahren durchführenden Netzwerkgerät selbst übertragenen umfasst.
5. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei das das Ermitteln einer innerhalb eines Sendezyklus übertragenen Datenmenge bzw. der Datenrate das Ersetzen eines vor dem Beginn einer Übertragung verstrichenen Zeitraums eines TO-Zeitfensters oder einer von einem Netzwerkgerät nicht genutzten Möglichkeit zur Übertragung durch die Anzahl der während des verstrichenen Zeitraums oder der Zeitdauer eines TO-Zeitfensters übertragbaren Datenbits bzw. Oktette umfasst.
6. Verfahren (100) nach einem der vorhergehenden Ansprüche, wobei das Berechnen einer innerhalb eines Sendezyklus erwarteten Datenmenge das Multiplizieren der Zyklusdauer mit der nominellen Datenrate des Kommunikationsmediums umfasst.
7. Netzwerkgerät (400), eingerichtet zur Kommunikation über ein von mehreren Netzwerkgeräten gemeinsam genutztes Kommunikationsmedium (24), mit mindestens einem Prozessor (402), flüchtigem (404) und nicht-flüchtigem (406) Speicher sowie einer Netzwerkschnittstelle (408), wobei in dem nichtflüchtigen Speicher (406) Computerprogramminstruktionen abrufbar gespeichert sind welche, wenn sie von dem mindestens einen Prozessor ausgeführt werden, das Netzwerkgerät (400) zur Ausführung eines Verfahrens zur Überwachung der Integrität der Kommunikation nach einem der vorhergehenden Ansprüche 1 bis 6 einrichten.
8. System, insbesondere Fahrzeugsystem, mit zwei oder mehr über ein von mehreren Netzwerkgeräten gemeinsam genutztes Kommunikationsmedium vernetzten Netzwerkgeräten, wobei zumindest eines der Netzwerkgeräte ein Netzwerkgerät nach Anspruch 7 ist.
9. Computerprogrammprodukt umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, das Verfahren nach einem oder mehreren der Ansprüche 1 bis 6 auszuführen.
10. Computerlesbares Medium, auf dem das Computerprogrammprodukt nach Anspruch 9 gespeichert ist.
EP23828343.6A 2022-12-13 2023-12-01 Verfahren zum testen eines kommunikationsbusses Pending EP4635151A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022213583.0A DE102022213583A1 (de) 2022-12-13 2022-12-13 Verfahren zum testen eines kommunikationsbusses
PCT/DE2023/200240 WO2024125731A1 (de) 2022-12-13 2023-12-01 Verfahren zum testen eines kommunikationsbusses

Publications (1)

Publication Number Publication Date
EP4635151A1 true EP4635151A1 (de) 2025-10-22

Family

ID=89321720

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23828343.6A Pending EP4635151A1 (de) 2022-12-13 2023-12-01 Verfahren zum testen eines kommunikationsbusses

Country Status (4)

Country Link
EP (1) EP4635151A1 (de)
CN (1) CN120266456A (de)
DE (1) DE102022213583A1 (de)
WO (1) WO2024125731A1 (de)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018213898B4 (de) * 2018-08-17 2020-03-19 Continental Automotive Gmbh Überwachung einer Netzwerkverbindung auf Abhören
DE102021202075A1 (de) * 2020-07-23 2022-01-27 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zur Validierung von Nachrichten
DE102020215329A1 (de) * 2020-12-03 2022-06-09 Continental Automotive Gmbh Verfahren zum schnellen Flashen von Sensorknoten über ein Ethernetnetzwerk
DE102020215763A1 (de) * 2020-12-11 2022-06-15 Continental Automotive Gmbh Verfahren zur Optimierung der Übertragungsdatenrate in einem Sensornetzwerk im Teilnetzbetrieb in einem Ethernetnetzwerk
DE102020216278A1 (de) * 2020-12-18 2022-06-23 Continental Automotive Gmbh Verfahren zur dynamischen Konfiguration von Sensoren und Steuergeräten in einem Ethernetnetzwerk

Also Published As

Publication number Publication date
CN120266456A (zh) 2025-07-04
WO2024125731A1 (de) 2024-06-20
DE102022213583A1 (de) 2024-06-13

Similar Documents

Publication Publication Date Title
EP2936747B1 (de) Datenübertragung unter nutzung eines protokollausnahmezustands
EP1100230B1 (de) Datenübertragungssystem für Luftfahrzeuge
DE102017211860B3 (de) Verfahren zur Übertragung von Daten über einen seriellen Kommunikationsbus, entsprechend ausgelegte Busschnittstelle sowie entsprechend ausgelegtes Computerprogramm
EP1573974B1 (de) Automatische adressierung auf bussystemen
DE102012216689B4 (de) Verfahren zur Überwachung eines Ethernet-basierten Kommunikationsnetzwerks in einem Kraftfahrzeug
EP2637362B1 (de) Busteilnehmer-einrichtung zum anschluss an einen linienredundanten, seriellen datenbus und verfahren zur steuerung der kommunikation eines busteilnehmers mit einem linienredundanten, seriellen datenbus
EP3618384B1 (de) Verfahren zur simulation einer verarbeitung von reservierungsanfragen für multicast-datenströme in kommunikationsnetzen und simulationssystem
WO2009083078A1 (de) Kommunikationssystem
EP3151476B1 (de) Verfahren zum querverkehr zwischen zwei slaves eines ringförmigen datennetzwerks
DE102012224031A1 (de) Datenübertragungsprotokoll mit Protokollausnahmezustand
DE102012206529B4 (de) Drahtloses Echtzeitübertragungssystem
DE102004062683A1 (de) Verfahren zur Regelung einer Übertragung mit kurzen Datentelegrammen
EP4635151A1 (de) Verfahren zum testen eines kommunikationsbusses
EP3032779B1 (de) Verfahren zur bestimmung der signalqualität in einem can-protokoll basierten netzwerk
DE102012204536A1 (de) Netzwerk und Verfahren zur Übertragung von Daten über ein gemeinsames Übertragungsmedium
DE19961644A1 (de) Verfahren und System zur Steuerung und zum Austausch von Daten für multimediale Geräte sowie dafür geeignetes Gerät
EP1436950A1 (de) Teilnehmergerät für ein hochperformantes kommunikationssystem
WO2024125732A1 (de) Authentifizierungsgerät für ein fahrzeug
EP3629550A1 (de) Verfahren zur datenübermittlung innerhalb eines industriellen kommunikationsnetzes und koppel-kommunikationsgerät
EP3975488A1 (de) Verfahren und kommunikationsgerät zur übermittlung zeitkritischer daten
DE102020202226A1 (de) Verfahren sowie Übertragungssystem zur Übermittlung von Messdaten
EP2220829A1 (de) Kommunikationssystem
EP2421209A2 (de) Verfahren zum Senden digitaler Daten
EP1885100B1 (de) Verfahren zur automatischen Adressvergabe an einen Kommunikationsteilnehmer und Kommunikationsteilnehmer
EP1329057B1 (de) Verfahren für den Zugriff aauf einen Datenbus zwischen kommunizierenden elektronischen einheiten

Legal Events

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

Free format text: STATUS: UNKNOWN

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

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

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250714

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 ME MK MT NL NO PL PT RO RS SE SI SK SM TR

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

Owner name: AUMOVIO GERMANY GMBH

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)