Method for determining one-way communication latencies for a CAN network

Abstract

Method for determining one-way communication latencies for a CAN network (1), comprising a plurality of control units (4, 5) which each communicate predefined message types via the CAN network (1), wherein each message type has a predefined CAN ID S i from a set S = (S0, S1,..., S i-1} of available CAN IDs, wherein a computer (3) is further connected to the CAN network, which is connected to a first control unit (4) via data transmission, wherein the first control unit is configured to send test messages (19) with different CAN IDs S i from the set S = (S0, S1, ..., S i-1} of available CAN IDs to send, where the CAN ID S i the test messages about the set S = {S0, S1, ..., S i-1} of available Can-IDs are distributed, the procedure comprising the following steps: a) Providing a time t0 (13) for sending a test message (19) between the computer (3) and the first control unit (4), b) Sending at least one test message (19) with a designated CAN ID d=S i at time t0 via the CAN network to the computer (3), c) Determining the time t rx (15), to which the computer (3) receives at least one test message, d) Determining the one-way communication latency t d_ow for the test message (19) that was sent in step b) from time t0 (13) and time t rx (15), and e) Estimating a one-way communication latency for messages with neighboring CAN IDs in the vicinity of CAN ID d=S i , which message types are assigned to which are sent by second control units (5) via the CAN network.

Description

State of the art

[0001] The present invention relates to a method for determining one-way communication latencies for a CAN network. Furthermore, a computer program, a machine-readable storage medium, and a CAN network are specified. The invention can be applied in particular to vehicles.

[0002] CAN networks (CAN = Controller Area Network) are well known and are used as the predominant communication channel between control units in vehicles.

[0003] A CAN bus typically comprises a multitude of control units connected to a CAN bus, forming a CAN network. Computers may also be connected to the CAN bus. The control units may have sensors for acquiring sensor data, with the control units sending the sensor data or parts of the sensor data via the CAN bus. Additional control units or computers connected to the CAN bus can combine the sensor data sent by different control units via the CAN bus for further estimation or evaluation.

[0004] The CAN bus generally refers to the pure data line to which various control units and computers are connected. The CAN network describes the CAN bus including the connected control units and computers.

[0005] However, most ECUs do not have synchronized clocks, so the sensor data sent by the ECUs is not time-stamped. This is often due to cost reasons, but can also have other technical causes. Furthermore, it should be considered that the one-way communication latency between the time sensor data is acquired on an ECU and the time the computer begins to fuse this sensor data can be on the order of 100 ms. All of this has the consequence of degrading the quality of the real-time estimation acquired by fusing the non-time-stamped sensor data transmitted over the CAN bus.

[0006] Currently, two approaches are typically used to fuse non-time-stamped sensor data. In the first approach, the time offset between the sensor data is dynamically estimated using correlations. However, this approach is based on assumptions that may not always be valid in real-world operation and can therefore significantly impact the quality of the estimate. In the second approach, the time offset between the sensor data is initially calibrated and stored in software as a fixed value, which is then taken into account during the fusion process. Obviously, this static time offset leads to problems as soon as the one-way communication latency fluctuates dynamically in real-world operation.

[0007] Although the use of a PPS signal to synchronize ECU clocks is known, it has so far only been used to synchronize the ECUs' local clocks. These clocks can then be used to time-stamp recorded sensor data and transmit this time stamp along with the sensor data over the CAN bus. This gives the receiver direct access to the corresponding time for each measurement point. However, this method has the major disadvantage of significantly increasing data traffic on the CAN bus, as each measured value now contains additional data.

[0008] Based on this, the object of the present invention is to alleviate or at least partially solve the problems described with reference to the prior art. In particular, a method for cost-effectively determining one-way communication latencies for a CAN network is to be provided. Disclosure of the invention

[0009] A method for determining one-way communication latencies for a CAN network contributes to this, comprising a plurality of control units, each of which communicates predetermined message types via the CAN network, each message type being assigned a predetermined CAN-ID S i from a set S = {S0, S1,...,S i-1} of available CAN IDs, wherein a computer is further connected to the CAN network, which computer is connected to a first control unit (4) in a data-conducting manner, wherein the first control unit is set up to send test messages with different CAN IDs S i from the set S = (S0, S1,..., S i-1} of available CAN IDs, where the CAN ID S i of the test messages over the set S = (S0, S1,..., S i-1} of available Can IDs, the method comprising the following steps: a) Providing a time t0 for sending a test message between the computer and the first control unit, b) Sending at least one test message with a designated CAN ID d=S i and at time t0 via the CAN network to the computer, c) Determine the time t rx , to which the computer receives at least one test message, d) Determine the one-way communication latency t d_ow for the test message sent in step b) from time t0 and time t rx , and e) Estimate a one-way communication latency for messages with neighboring CAN IDs in the vicinity of the CAN ID d=S i which message types are assigned that are sent by second control units (5) via the CAN network.

[0010] The essential idea of ​​the invention is to determine one-way communication latencies for a CAN network using a specific control unit configured to provide test messages with time information and designated CAN IDs and to send the provided test messages to a computer connected to the CAN network. This specific (first control unit) serves only the purpose of sending test messages to estimate latencies. The first control units also connected to the CAN network are connected to sensors, for example, and serve the purpose of transmitting sensor data from the computer. The set S = (S0, S1, ..., S i-1} of available CAN IDs contains, for example, 1,000 different, available CAN IDs. Of 1,000 available CAN IDs, for example, 80 are intended for one-way communication between second control units and the computer. For the test messages sent with the specific (first) control unit, 40 additional CAN IDs are reserved, for example. The data connection between the computer and the specific (first) control unit makes it possible to transmit the time information regarding the sending of the message t0 – a possibility that does not exist for the aforementioned second control units. Based on the time information available for the test messages, it is possible to determine the one-way communication latencies for the test messages.According to the CAN IDs contained in the test messages, it is possible to estimate the one-way communication latencies between the computer and other ECUs with neighboring CAN IDs in the vicinity of the CAN IDs of the test messages.

[0011] The communication latencies occur because the CAN network is regularly blocked by messages sent over the CAN network, which delays the sending of messages.

[0012] This specific control unit is also referred to here as the first control unit.

[0013] Time information regarding the time t0 at which the first control unit sends the test messages is available to the computer. For this purpose, the first control unit can, for example, comprise a standalone clock and preferably receive trigger signals for clock synchronization. It is also possible for the first control unit and the computer to exchange time information regarding the time t0 with each other via a data line, or for this time information to be made available to the first control unit and the computer from another source (a trigger). To carry out the described method, only a single first control unit is fundamentally required.

[0014] To distinguish them from the first control unit, the additional control units connected to the CAN network are referred to as second control units. These are, for example, control units that provide sensor data. These second control units typically do not have synchronized clocks, so the messages sent by the second control units to the computer do not contain any time information, and consequently, the one-way communication latencies between the computer and the respective second control units are unclear.

[0015] The computer can be a central computer connected to the CAN network, configured to receive and further process data from various control units. However, the computer can also be configured as an additional control unit or be connected to the CAN network via a control unit.

[0016] A one-way communication latency to be determined on the CAN network therefore means the time delay between the time at which data was acquired on a (second) control unit and the time at which the computer can further process this data.

[0017] A second control unit can send several different message types over a CAN network. Each message type has a unique CAN ID. Typically, messages with a lower CAN ID have higher priority on the CAN network. If two messages are to be sent to the computer at the same time, the message with the lower ID takes precedence. This has the effect that the expected one-way communication latency for a message also increases with the increasing CAN ID.

[0018] Here it can be provided that each message type is assigned a predefined CAN-ID S i from a set S = (S0, S1 ,..., S i-1} of available CAN IDs. In principle, the available CAN IDs can be n=11 bits or n=29 bits wide, depending on the CAN standard used. The CAN IDs are therefore natural numbers in the interval [0, 2^n-1]. Depending on the control units connected to the CAN network, the set S = (S0, S1, ..., S i-1} can be any (arbitrary) subset of this interval. The CAN IDs of the message types available to the second control units can be specified when designing the CAN network. This means that these CAN IDs do not change when executing the described procedure.

[0019] In contrast, the CAN IDs S contained in the test messages can i not be determined during the design of the CAN network, but during the execution of the described procedure from the set S = {S0, S1, ..., S i-1} randomly selected. In other versions, the CAN IDs S i of the test messages must also be specified. The selected CAN IDs S i of the test messages are over the set S = (S0, S1, ..., S i-1} of available CAN IDs. The CAN IDs S i However, the test messages do not overlap with the CAN IDs of the correct messages sent by second control units, but are located in between or next to them.

[0020] Step a) and step b) can be executed on the first control unit to send test messages with time information and CAN IDs d=S iand send them to the computer. Steps c), d), and e) can be executed on the computer to calculate one-way communication latencies for test messages and to estimate one-way communication latencies for other messages relative to the calculated one-way communication latencies for the test messages.

[0021] According to step a), a time t0 is set for sending a test message between the computer and the first control unit. Time t0 can be set by a clock built into the first control unit. This clock can be synchronized with the GNSS time via PPS signals from a GNSS receiver to provide time t0 more accurately.

[0022] According to step b), at least one test message with a designated CAN ID d=S iand the content t0 is sent to the computer via the CAN network. The CAN ID d=S i from the set S = (S0, S1, ..., S i-1} are randomly selected. In principle, it is possible to send several test messages to the computer one after the other with a delay in step b). In this case, the test messages can each have the content with a different delay t0+r and with the number of messages from the set S = {S0, S1, ..., S i-1} selected different CAN-ID d=S i sent to the computer, where r is a random number.

[0023] According to step c), the time t rx determines the time at which the computer receives at least one test message. The time t rx can be provided by a clock built into the computer. It is possible to synchronize this clock with the GNSS time via PPS signals from a GNSS receiver in order to determine the time t rxto provide more precise information.

[0024] According to step d), the one-way communication latency for the at least one test message from time t0 and time t rx The time t0 is contained in at least one test message. The time t rx can be determined using the computer's clock. The one-way communication latency t d_ow thus corresponds to the time difference between time t0 and time t rx , namely t d_ow = t rx - t0. If at least one test message is sent to the computer with a delay t0+r, the one-way communication latency corresponds to the time difference between time t0+r and time t rx , namely t d_ow = t rx - t0 - r.

[0025] According to step e), one-way communication latencies for messages with neighboring CAN IDs in the vicinity of the CAN ID d=S contained in the at least one test message are determined. i certainly.

[0026] The method described here has the advantage that one-way communication latencies can be determined without a significant increase in data traffic on the CAN bus. In this case, only a single first control unit is used for time synchronization, resulting in only a very small data volume to be transmitted. The total volume of test messages required for a good estimate of communication latencies is relatively small compared to the volume of regular messages sent from second control units to the computer.

[0027] The invention offers the particular advantage that one-way communication latencies on a CAN bus can be determined cost-effectively and more accurately. The determined one-way communication latencies can, in turn, be used to merge different sensor data, recorded by different control units, at a central location in the vehicle, for example. This solves the problem of temporal shifts between the sensor data and thus allows for sensor fusion with higher quality. To implement the described method, only a single specific control unit and the software update for performing method steps a) and e) are required.This also means that the existing CAN bus can be easily retrofitted with a specific control unit and the software update, allowing one-way communication latencies to be determined on the existing CAN bus using the described method. In particular, if an control unit already exists in the vehicle that has a dedicated clock and receives PPS signals for clock synchronization, the method described here can even be implemented entirely in software and requires no additional hardware.

[0028] Compared to known approaches for temporal synchronization of measured values, the described method has the particular advantage that the measured values ​​are available in real time and that it does not require calibration. In particular, if the time offset between the sensor data is initially determined as a fixed value with the aim of subsequently compensating for it via software, these time differences depend on the CAN matrix used and are therefore different for each vehicle with different equipment. This is not the case with the method described here. This means that the described method can be flexibly implemented on different CAN buses in different vehicles. All that is required is a control unit for receiving PPS signals and the software update, as mentioned above.

[0029] It is preferred if steps a) to c) are performed for a plurality of test messages with different CAN IDs.

[0030] It is also preferred if the method is carried out regularly and repeatedly in order to determine current values ​​for the one-way communication latency.

[0031] By periodically changing the CAN IDs S contained in the test messages i and by regularly repeating the described procedure, a complete picture of the one-way communication latencies for the CAN network can be generated.

[0032] Even though the procedural steps are listed here in a specific order using letters a) and e), this order need not always be followed. For example, the individual procedural steps can be repeated independently of one another many times and / or, if repeated, partially omitted. It is possible that the procedural steps are carried out at least partially at different times.

[0033] It is preferred if in step a) the time t0 is provided via a trigger which is capable of sending a trigger signal to the first control device.

[0034] The trigger signal can, for example, be provided and sent every full second. Other times are also possible, such as every half second or even 10 times per second.

[0035] The first control unit can be connected to the CAN network on the one hand, and to a trigger via an out-of-band data line on the other, in order to receive a trigger signal generated by the trigger every full second via the out-of-band data line with the shortest possible time delay. The trigger is preferably a GNSS receiver. It is possible to implement the trigger signal in the form of a PPS (plus per second) signal, which is generated precisely once per second.

[0036] It is preferred if, in step a), a time delay r is additionally inserted in the form of a random number. The time delay r can be between 0 and 999 milliseconds, so that the described method can be executed, taking into account the clock synchronization with the GNSS time, via a PPS signal, which is always generated every full second (i.e., every 1000 milliseconds).

[0037] It is particularly preferred if the time delay r lies in an interval range between 0 and 255 milliseconds. This allows a message to always arrive at the computer in the same second in which the trigger signal was received, simplifying the execution of the entire method. In particular, one execution of the described method (beginning with step a) and ending with step e)) is completed before a next execution of the method begins with a renewed execution of the steps. The load on the CAN network caused by the test message is thereby preferably reduced.

[0038] It is preferred if in step b) the CAN ID d=S i which is provided with at least one test message according to the formula i = (i+1) mod n, where n is a natural number. Thus, the CAN ID d=S i when the entire procedure is executed regularly from the set S = {S0, S1, ..., S i-1} can be selected one after the other.

[0039] It is preferred if step e) comprises interpolating one-way communication latencies from the test messages to the messages sent with second control units. Different interpolation techniques can be used, such as linear interpolation, polynomial interpolation, or spline interpolation.

[0040] It is preferable to smooth the measured values ​​using a filter with the aid of older measured values. This smooths the measured values ​​over a certain period of time, which can reduce measurement noise and, in particular, the influence of measurement outliers.

[0041] It is preferred if the trigger is a GNSS receiver and the trigger signal is a PPS signal, so that both the computer's clock and the clock of the first control unit can be synchronized with the atomic clock-based GNSS time via PPS signals. It is particularly advantageous if the GNSS receiver is connected to the computer and the first control unit via an additional data line outside the CAN bus (i.e., out-of-band). This allows the computer and the first control unit to receive PPS signals from the GNSS receiver independently of the CAN network.

[0042] It is preferred if the computer is a vehicle computer.

[0043] It is also preferred if a computer program is used to carry out a method described here. In other words, this particularly relates to a computer program (product) comprising instructions that, when executed by a computer, cause the computer to carry out a method described here.

[0044] It is particularly preferred if a machine-readable storage medium is used on which the computer program proposed here is stored. The machine-readable storage medium is usually a computer-readable data carrier.

[0045] Furthermore, a CAN network is proposed, comprising a computer, a first control unit and a plurality of second control units, wherein the computer and the first control unit are capable of synchronizing their clocks with each other and determining one-way communication latencies for the CAN network according to the described method.

[0046] It is preferred if the computer and the first control device are connected to a trigger via a trigger signal channel and are capable of receiving trigger signals from the trigger for clock synchronization.

[0047] The solution presented here and its technical environment are explained in more detail below with reference to the figures. It should be noted that the invention is not intended to be limited by the exemplary embodiments shown. In particular, unless explicitly stated otherwise, it is also possible to extract partial aspects of the facts explained in the figures and combine them with other components and / or findings from other figures and / or the present description. It shows schematically: Fig. 1 a CAN network according to the invention, Fig. 2 an exemplary time sequence for determining a one-way communication latency for a test message, Fig. 3 an exemplary representation for the estimation of one-way communication latencies, and Fig. 4 shows an exemplary result for the estimation of one-way communication latencies across all available CAN IDs.

[0048] Fig. 1 shows a CAN network 1 according to the invention, which can be used in modern vehicles (not shown). Fig. 1 it can be seen that a computer 3, a first control unit 4 and, for example, three second control units 5 are connected to a CAN bus 2.

[0049] The computer 3 can be a vehicle computer, which is typically connected via a USB channel 9 to a GNSS receiver 6 for positioning, which typically generates PPS signals and can be used as a trigger for the described method. The computer 3 can also be connected to a camera 7 via an Ethernet channel 10, so that both the computer 3 and the camera 7 can receive PPS signals from the GNSS receiver 6 via a trigger signal channel 8 to synchronize their internal clocks. The trigger signal channel 8 forms the data connection here.

[0050] In Fig. 1 further shows that a second control unit 5 includes an angular speed sensor 11 and is capable of detecting the real-time speed of the vehicle. Another second control unit 5 includes a gyro sensor 12 and is capable of detecting the real-time angular change rate. The angular change rate is relevant for the direction in which the vehicle is moving. The detected speed and the detected angular change rate are sent sequentially via the CAN bus 2 to the computer 3 so that the computer 3 can fuse the speed and the angular change rate to calculate dead reckoning (i.e., determine a vehicle position relative to a starting point). If the speed and the angular change rate are not synchronized in time, the quality of the dead reckoning is significantly impaired. This problem is solved here by the first control unit 4.For this purpose, the first control unit 4 is connected both to the CAN bus 2 and, outside of the CAN bus 2, to the GNSS receiver 6 via a trigger signal channel 8. This makes it possible for the first control unit 4 and the computer 3 to synchronize their internal clocks with the GNSS time via the PPS signals generated by the GNSS receiver 6, and the one-way communication latencies of all CAN IDs can be more accurately estimated according to the described methods based on the clock synchronizations of the first control unit 4 and the computer 3. Furthermore, the speed and the angular rate of change can be synchronized in time according to the estimated one-way communication latencies, thus improving the quality of dead reckoning. The example chosen here with a gyro sensor 12 and an angular speed sensor 11 is only an example. Any other sensors can be connected to the CAN bus 2 via the second control unit 5.

[0051] Fig. Figure 2 schematically shows an exemplary timing of the communication between the trigger in the form of a GNSS receiver 6 (the left vertical axis), the computer 3 (the middle vertical axis) and the first control unit 4 (the right vertical axis) for the determination of a one-way communication latency t d_ow 17 for a test message 19.

[0052] In Fig. 2 shows that at time t0 13, both the computer 3 and the first control unit 4 receive a trigger signal 18 in the form of a PPS signal, which is generated by the GNSS receiver 6 every full second. Using the trigger signal 18, both the computer 3 and the first control unit 4 can synchronize their internal clocks with the GNSS time.

[0053] After receiving the trigger signal 18, the first control unit 4 determines the time t0 13 at which the trigger signal 18 was received and sends a test message 19 with a real-time CAN ID to the computer 3 after a delay r 16, ie at the time t0 +r 14, wherein the test message 19 contains the time information t0 +r.

[0054] After receiving the test message 19, the computer determines the time t rx 15, at which the test message 19 was received. The one-way communication latency t d_ow 17 for the test message 19, thus corresponds to the time difference between the time t0 +r 14 and the time t rx 15, namely t d_ow = t rx -t0 -r.

[0055] Fig. Figure 3 schematically shows an exemplary representation for estimating further one-way communication latencies with respect to the determined one-way communication latencies, as performed in step e) of the described method. The CAN IDs are plotted on the horizontal axis, increasing from right to left. The communication latency is plotted on the vertical axis. Fig. In Figure 3, the one-way communication latencies to be estimated are represented by the dots. These are the latencies of messages sent via second control units, which cannot be directly measured due to the lack of time information.

[0056] It can be seen that latencies generally increase with higher CAN IDs. In contrast, the specific one-way communication latencies of test messages sent with the first control unit are represented by the crosses. These one-way communication latencies for the respective test messages can be calculated according to the Fig. 2 can be determined.

[0057] Since the CAN IDs S i of the test messages when sending from the set S = (S0, S1, ..., S i-1} were selected and the selected CAN IDs S i as in Fig. 3 over the set S = (S0, S1, ..., S i-1} are distributed, it is thus possible to reduce the one-way communication latency (referred to as points) for messages with neighboring CAN IDs in the vicinity of the CAN IDs S iof the test messages. The term "environment" in this context means that CAN IDs are located at a similar height. For example, CAN ID 993 is close to CAN ID 992. It can be seen that, based on the precisely determined communication latencies of the test messages, represented by crosses, conclusions can be drawn about the communication latencies of the communication latencies to be estimated, represented by dots. Any interpolation approach can be used to improve these estimates.

[0058] Fig. Figure 4 schematically shows an exemplary result for estimating one-way communication latencies across all available CAN IDs by periodically changing CAN IDs of the test messages and by interpolation, which provides a complete picture of the one-way communication latencies compared to Fig. 3 is generated.

Claims

[1] Method for determining one-way communication latencies for a CAN network (1), comprising a plurality of control units (4, 5) which each communicate predetermined message types via the CAN network (1), wherein each message type is assigned a predetermined CAN-ID S i from a set S = (S0, S1,..., S i-1} of available CAN IDs, wherein a computer (3) is further connected to the CAN network, which computer is connected to a first control unit (4) in a data-conducting manner, wherein the first control unit is set up to send test messages (19) with different CAN IDs S i from the set S = (S0, S1, ..., S i-1} of available CAN IDs, where the CAN ID S i of the test messages over the set S = {S0, S1, ..., S i-1} of available Can IDs, the method comprising the following steps: a) providing a time t0 (13) for sending a test message (19) between the computer (3) and the first control unit (4), b) Sending at least one test message (19) with a designated CAN ID d=S i at time t0 via the CAN network to the computer (3), c) Determine the time t rx (15) to which the computer (3) receives the at least one test message, d) Determine the one-way communication latency t d_ow for the test message (19) sent in step b) from time t0 (13) and time t rx (15), and e) Estimate a one-way communication latency for messages with neighboring CAN IDs in the vicinity of the CAN ID d=S i which are assigned to message types sent by second control units (5) via the CAN network (1). [2] Method according to claim 1, wherein steps a) to c) are performed for a plurality of test messages (19) with different CAN IDs. [3] Method according to claim 1 or 2, wherein in step a) the time t0 (13) is provided via a trigger (6) which is capable of sending a trigger signal (18) to the first control unit (4). [4] Method according to one of the preceding claims, wherein in step a) a time delay r (16) in the form of a random number is additionally inserted, wherein the time t0 is delayed by the time delay r (16). [5] Method according to one of the preceding claims, wherein the time delay r (16) lies in an interval range between 0 and 255 milliseconds. [6] Method according to one of the preceding claims, wherein steps a) to d) are regularly repeated with test messages with different CAN-IDs d=S i be performed.. [7] Method according to one of the preceding claims, wherein step e) comprises interpolating one-way communication latencies from the test messages to the messages sent with second control devices (5). [8] Method according to one of the preceding claims, wherein the method is carried out regularly and repeatedly for each individual test message (19) in order to determine current values ​​for the one-way communication latency. [9] Method according to one of the preceding claims, wherein the one-way communication latencies determined in step e) are smoothed with a filter with the aid of older determined one-way communication latencies. [10] Method according to one of the preceding claims 3 to 9, wherein the trigger is a GNSS receiver (6) and the trigger signal (18) is a PPS signal. [11] Method according to one of the preceding claims, wherein the computer (3) is a vehicle computer. [12] Computer program for carrying out a method according to one of the preceding claims 1 to 11. [13] A machine-readable storage medium on which the computer program according to claim 12 is stored. [14] CAN network (1) comprising a computer (3), a first control unit (4) and a plurality of second control units (5), wherein the computer (3) and the first control unit (4) are capable of synchronizing their clocks with each other and determining one-way communication latencies for the CAN network (1) according to one of claims 1 to 10. [15] CAN network (1) according to claim 14, wherein the computer (3) and the first control unit (4) are connected to a trigger (6) via a trigger signal channel (8) and are capable of receiving trigger signals (18) from the trigger (6) for clock synchronization.

Images