DE102017209328A1 - Device for the synchronization of clocks in control units and control unit - Google Patents

Abstract

The invention relates to a low-cost hardware architecture concept for the implementation of the synchronization of control units (151, 152, 153), which are networked via the CAN bus (104). Synchronization messages SYNC, FUP, OFS and OFNS are provided according to the AUTOSAR standard. The architecture concept provides a timestamp unit (226), reference time computation unit (221), and a cache (227). The time stamp unit (226) detects the time of arrival of a synchronization message to the local clock (222) of the control unit and makes this information available to the reference time calculation unit (221).

Description

The invention relates to the technical field of synchronization of clocks in control units, which are networked via a bus system. Such controllers are widely used in motor vehicles. Networked controllers are also found in other fields of technology, e.g. in automation technology, process technology, etc. The invention relates to a device for the synchronization of clocks in control units and a correspondingly equipped control unit.

In modern vehicles, a large number of control units are installed. For the powertrain alone, a number of controllers are used, e.g. Engine control unit, transmission control unit, ESP control unit, suspension control unit and more. In addition, there are also other control devices that are installed in the area of the vehicle body and provide certain comfort features. Examples include the door or window regulator control units, air conditioner control units, seat adjuster controllers, airbag control devices and the like. Then there are still infotainment control units, such as an environmental monitoring camera control unit, navigation device, RADAR or LIDAR device, communication module and entertainment device with TV, radio, video and music function.

Typically, the controllers of the various categories are each networked with a separate bus designed for the equipment category. It can therefore be used in the vehicle several different bus systems. The various bus systems can be connected to each other via gateways to allow data exchange. In the field of powertrain control units, the CAN bus (Controller Area Network) is typically used, also in the area of comfort control units. In the infotainment area, other bus systems are also used, such as bus systems based on Ethernet technology, e.g. AVB (Audio Video Bridging) based on the standard family according to IEEE 802.1 standard. Bus systems in which the data is transmitted via optical fibers can also be used. Examples are the MOST Bus (Media Oriented System Transport) or the D2B Bus (Domestic Digital Bus).

A problem with the networking of ECUs is the time synchronization of the ECUs with each other. In many cases, the ECUs have to do their control functions synchronously. As an example are called safety-related functions such as a braking process. In this case, the control units ESP control unit (contains the ABS function), engine control unit, transmission control unit and suspension control unit work together, for example, by to realize the best possible braking performance during emergency braking. Deviations of a few milliseconds during initiation and / or the execution of the emergency braking function can then already affect the braking distance.

• • um die Synchronizität von Datenströmen sicher zu stellen
• • um eine gemeinsame Zeitbasis für das Abtasten / Empfangen von Datenströmen an einem Quellgerät und die Präsentation dieser Streams am Zielgerät mit demselben relativen Timing bereit zu stellen.

The AVB bus has a specific protocol designed to precisely synchronize infotainment devices. The protocol was specified in the IEEE 802.1AS standard. Thereafter, the devices periodically exchange time information that allows both subscribers at a connection to very precisely synchronize their local clocks. Synchronization on the AVB bus serves the following purposes:

• • to ensure the synchronicity of data streams
• • to provide a common time base for sampling / receiving data streams on a source device and presenting these streams to the target device with the same relative timing.

Within the time domain there is a single device named "Grandmaster" that provides a "master timing signal". All other devices synchronize their clocks with the "master timing signal".

For the area of the CAN bus, there are also requirements as far as the synchronization of the clocks of the control devices is concerned. The AUTOSAR organization has specified a protocol which allows to synchronize several ECUs connected to a CAN bus. The specification is titled "Specification of Synchronized Time Base Manager", AUTOSAR CP Release 4.3.0. Further information on this topic can be found in the AUTOSAR document "Specification of Time Synchronization over CAN", AUTOSAR CP Release 4.3.0. The proposal, however, refers to a software solution. The achievable accuracy of the time synchronization depends decisively on the accuracy of the time stamp used in the synchronization messages as well as the timestamps detected in the slave controllers on arrival of the synchronization messages.

To improve accuracy, the CiA (CAN in Automation) organization has come up with the proposal to perform frame time stamping in the CAN controller. The specification is titled "Frame time-stamping", CiA 603 Final Working Draft Version 0.0.5, December 2016.

However, neither AUTOSAR nor the CiA document describe the actual as based on the information obtained Time synchronization can be performed at any time.

The DE 10 207 222 A1 focuses on time-consistent data acquisition in ECUs networked via the CAN bus. Due to the bus access method CSMA-CA, a deterministic bus access is not possible among the individual subscribers. There is also the problem that the various controllers operate at different clock rates, resulting in different operating speeds.

From the EP 1 543 389 B1 It is known for the synchronization of networked via CAN bus control units to insert synchronization information in the user data packets to be transmitted, so that no separate synchronization information must be transmitted. In the user data packet, the information is entered, which time slot in the control unit for processing came when the data packet was sent over the bus.

From the EP 3 015 227 A1 is a method for time synchronization of clocks in ECUs, which are distributed in a network known. The network is the fieldbus based on the EtherCAT standard. The synchronization process is started by the master controller via interrupt.

From the field of Ethernet different protocols for the synchronization of clocks are known. The most popular Network Time Protocol (NTP) is a standard for synchronizing clocks in computer systems over packet-based communication networks.

The aim of the invention is to specify a practicable implementation of the solution proposed in the cited CiA document, the time synchronization in the CAN controller.

This object is achieved by a device for the synchronization of clocks in control devices according to claim 1, and a control device according to claim 11.

The dependent claims contain advantageous developments and improvements of the invention according to the following description of these measures.

An advantageous hardware solution for time synchronization in the CAN controller is proposed. The synchronization messages prescribed according to the AUTOSAR standard are used. In this case, a special feature of the solution is that the device has a time stamp unit, a reference time arithmetic unit and a buffer, wherein the time stamp unit detects the time of arrival of a synchronization message after the present in the device local clock, and this detected time of the reference time -Recheneinheit provides. In this case, the synchronization information communicated in the synchronization messages are collected in the buffer and also made available to the reference time computing unit. This solution has the advantage that the network time, despite the fact that the synchronization messages only arrive periodically at certain time intervals, can be calculated at any time using the detected time stamps within the CAN controller. This has the advantage that a high degree of accuracy can be achieved for the time synchronization even between the synchronization times, which is otherwise not the case. Actions that must be carried out synchronously by different control units can thus be carried out with high accuracy at any desired time.

It is advantageous that a configuration register is provided for the device, which serves for setting the calculation of the time correction values in the reference time computing unit. There are several methods for calculating the network time, which are already considered in AUTOSAR. These can be provided in the reference time processing unit. Via the configuration register, the desired calculation type can be selected via the application software of the control unit.

As described, the synchronization messages are supported in the format of the AUTOSAR standard titled "Specification of Time Synchronization over CAN" according to AUOTSAR CP Release 4.3.0. In this case, for the acquisition of the data in the synchronization messages SYNC and FUP a synchronization register and for the acquisition of the data in the synchronization messages OFS and OFNS an offset register upstream of the buffer. As a result, the receive buffer of the CAN controller can be immediately released for receiving further messages.

The architecture of the solution with time stamp unit, reference time processing unit and buffer is very flexible, so that the device can be easily expanded if additional calculation types are to be supported. At AUTOSAR the two approaches "Rate Correction" and "Offset Correction" are considered.

For the "offset correction" the two variants "Jump Correction" and "Rate Adaptation" are considered. Either a rate adjustment is made or it will be hard Jumps in the synchronization accepted. Both calculation types of the time correction are supported in the described solution.

For the implementation according to the proposal, it is advantageous that the time stamp unit only provides the arrival of the information in the synchronization message SYNC with a time stamp. The SYNC message is the first synchronization message arriving at a synchronization time. For the other synchronization messages, no time stamp needs to be detected. All processing of the synchronization messages will be easier. There is also no need to provide an interface between the offset register and the time stamp unit.

It is also advantageous if an interrupt generator unit is provided for triggering time-synchronized actions, which is connected to the reference time computing unit. From the reference time computing unit, the interrupt generator unit gets the exact network time. This is used in the interrupt generator unit to perform synchronous actions. This can be done by triggering interrupts.

It is advantageous if an interrupt configuration register is provided for the interrupt generator unit, via which it is possible to set at which times or with which time period an interrupt / action is to be triggered.

In summary, the proposal specifies a particularly advantageous hardware implementation for calculating the time correction in a local controller of a network. For this purpose, the CAN controller calculates the clock ratio from its own local clock to the clock of its synchronization partner. It calculates this duty cycle from two SYNC and Follow UP messages pairs that it receives over the network and its local input clock signal. This is true under the assumption that the offset transmitted in the OFS and OFNS message pairs does not change in the same time period.

Given a known clock ratio, the CAN controller, taking into account the time offset that it also receives via the network in the synchronization messages OFS and OFNS, at any time based on its local time, and the input clock signal, calculate the network time.

The CAN controller can then make the time information readable via a register. On the other hand, the CAN controller can serve as a clock source after the network time to trigger high-precision time-synchronous operations.

An extension is that the CAN controller automatically sends timestamps of the network time when sending messages.

An embodiment of the invention is illustrated in the drawings and will be explained in more detail with reference to FIGS.

• 1 ein Blockdiagramm für ein Fahrzeug-Bordnetzwerk mit Steuergeräten verschiedener Kategorie;
• 2 das Prinzip des Zeitsynchronisations-Prozesses mit Hilfe periodisch auftretender Synchronisations-Nachrichten, wie er von AUTOSAR spezifiziert wurde;
• 3 die Gegenüberstellung zweier Varianten eines Blockschaltbildes einer CAN-Busschnittstelle bei der die Funktion der Zeitsynchronisation einmal mit Hilfe von Software und zum anderen mit Hardwaremitteln realisiert wurde;
• 4 ein Blockschaltbild des Zeitsynchronisationsblocks im CAN-Controller, der bei der Hardware-Lösung eingesetzt wird; und
• 5 ein Diagramm, dass den Vergleich der verschiedenen Methoden der Zeitkorrektur, die bei der Zeitsynchronisation einsetzbar sind, illustriert.

Show it:

• 1 a block diagram for a vehicle on-board network with control units of various categories;
• 2 the principle of the time synchronization process with the help of periodically occurring synchronization messages as specified by AUTOSAR;
• 3 the comparison of two variants of a block diagram of a CAN bus interface in which the function of the time synchronization was realized once with the help of software and the other with hardware means;
• 4 a block diagram of the time synchronization block in the CAN controller, which is used in the hardware solution; and
• 5 a diagram that illustrates the comparison of the different methods of time correction that can be used in the time synchronization.

The present description illustrates the principles of the disclosure of the invention. It will thus be understood that those skilled in the art will be able to devise various arrangements which, while not explicitly described herein, are intended to embody principles of the invention and to be equally limited in scope.

1 shows the typical structure of an on-board network of a modern motor vehicle. With the reference number 151 is called an engine control unit. The reference number 152 corresponds to an ESP control unit and the reference number 153 denotes a transmission control unit. Other control devices such as a vehicle dynamics control unit, etc. may be present in the motor vehicle. The networking of such control units, which are all attributed to the category of powertrain, typically occurs with the CAN bus system (Controller Area Network) 104 which as ISO standard is standardized, ISO 11898 , Since various sensors are installed in the motor vehicle and these are no longer connected only to individual control units, such sensor data also via the bus system 104 transferred to the individual control units. Examples of sensors in the motor vehicle are wheel speed sensors, steering angle sensors, Acceleration sensors, rotation rate sensors, tire pressure sensors, distance sensors, knock sensors, air quality sensors, etc. The various sensors with which the vehicle is equipped are in the 6 with the reference number 161 . 162 . 163 designated.

However, the modern motor vehicle may have other components such as video cameras, e.g. as a rear view camera or as a driver monitoring camera as well as a radar device for the realization of a Radartempomaten or for the realization of a distance warning or collision warning device.

In the motor vehicle are then also other electronic devices. These are arranged more in the area of the passenger compartment and are often operated by the driver. Examples are a user interface device with which the driver can select driving modes, but can also operate classic components. These include gear selection as well as turn signal control, windscreen wiper control, light control, etc. This user interface arrangement is identified by the reference numeral 130 Mistake. The user interface layout 130 Often also equipped with a rotary / pressure switch, via which the driver can select the various menus that are displayed on a display in the cockpit. On the other hand, a touch-sensitive display falls into this category. Even the voice input for the operation support falls into this area.

Of these, a navigation system is often distinguished 120 , which is also installed in the cockpit area. The route, which is displayed on a map, can of course also be shown on the display in the cockpit. Other components, such as a speakerphone may be present, but are not shown in detail. The reference number 110 refers to an on-board unit. This on-board unit 110 corresponds to a communication module via which the vehicle can receive and send mobile data. Typically, this is a mobile communication module, z. B. according to the LTE standard. All these devices are assigned to the infotainment area. They therefore have a bus system designed for the special needs of this device category 102 networked.

In this regard, reference is made to the already mentioned bus systems AVB (Audio Video Bridging), the MOST Bus (Media Oriented System Transport) or the D2B Bus (Domestic Digital Bus). For the purpose, the vehicle-relevant sensor data via the communication interface 110 to be transferred to another vehicle or to a central computer, is the gateway 140 intended. This is with both different bus systems 102 and 104 connected. The gateway is designed to handle the data it transmits via the CAN bus 104 receives so implement that it is in the transmission format of the infotainment bus 102 be implemented so that they can be distributed in the packages specified there. For the forwarding of these data to external, so to another motor vehicle or to a central computer is the on-board unit 110 equipped with the communication interface to receive these data packets and turn into the transmission format of the corresponding mobile standards used.

2 now shows the principle time synchronization process as specified by AUTOSAR. For further details please refer to the AUTOSAR document "Specification of Time Synchronization over CAN", AUTOSAR CP Release 4.3.0. In principle, it is about the local clocks that are operated in the individual control units, with the time of another clock often referred to as global time to synchronize. In this context, the control units, each equipped with a local clock, are called AUTOSAR "time slaves". A central control unit, called "Time-Master" in AUTOSAR, specifies the time with which the local clocks are to be synchronized. When transmitting the synchronization information from the time master to the time slaves in a broadcast CAN message, there is the problem that the time value due to CAN-specific effects such as the special Arbitrierungsverfahren and software-specific delays, such as the occurrence of interrupts inaccurate becomes. For this reason, AUTOSAR proposes a two-step process for time synchronization.

In this case, in a broadcast SYNC message, the second part ( t0r ) transmitted by the time information used for synchronization. CAN messages are limited in their size of the user data field to 8 bytes. For the actual timestamps even less space remains, so the time information must be cleverly divided into several messages. The second part ( t0r ) is the part in which the change of the synchronization time with respect to the previous synchronization interval is. This corresponds to the LSB part of the synchronization time. The MSB part can be longer valid and will be updated with more time. In the example of the on-board network of 1 takes over the gateway 140 the function of the "time master". In order to determine the exact time when the synchronization message is given to the bus, a CAN low-level function is used, eg the function "CAN transmit confirmation". A timestamp is generated when the "CAN transmit confirmation" information is received. at Receiving the SYNC message in a "Time Slave" controller 151 , this also uses a CAN low-level mechanism, such as "CAN-receive indication", to set the time ( t2r ) to determine when the SYNC message was actually received.

In 2 is t0r the time to be transmitted as synchronization information. The second part of this time S ( t0r ) is transmitted in the SYNC message. At the time T1R the SYNC message goes out. The "Time-Master" then records a timestamp T1R his reference clock. The time master then sends a second message via broadcast to the "time slaves". It is the so-called FUP message according to follow-up message. This is the information T4R transfer. The transmitted information corresponds to this T4R the value of the timestamp T1R less the information s (s) transmitted in the SYNC message t0r ). It therefore applies: $$\text{T4R}=\text{T1R}-\text{s}\left(\text{t0r}\right),$$

The information T4R corresponds to the distance between the time information transmitted in the previous SYNC message and the actually determined transmission time T1R for the SYNC message. There is no timestamp for the FUP message, neither on the send side nor on the receive side.

In the time slave 151 Then both information from SYNC message and FUP message are put together to calculate the new time for the local clock. The previously determined timestamp will also be used t2r used for the arrival time of the SYNC message. The following applies: $$\text{New rel}\text{, Time}=\text{t3r}-\text{t2r}+\text{s}\left(\text{t0r}\right)+\text{T4R},$$

The meaning of the parts t3r - t2r and s (t0r) + t4r is in the 2 illustrated.

AUTOSAR also provides for the use of offset synchronization messages OFS and OFNS. They are used to correct an offset value by which the transmitted time values in the SYNC messages are to be corrected. The correction values are taken from the time master 140 broadcasted in the OFS and OFNS messages as well. Both OFS and OFNS messages contain offset information, which, however, due to space issues, has to be split between these two messages.

The 3 now shows a comparison of the AUTOSAR proposed implementation of time synchronization with the implementation proposed here. It is again from the in 2 assumed example. The engine control unit is a time-slave device which stores the synchronization information from the gateway 140 receives. The same applies to the other control units 152 . 153 and sensors 161 . 162 . 163 synchronized.

The left part shows the software solution proposed by AUTOSAR for time synchronization. With the reference number 1510 is the CAN interface of the engine control unit 150 designated. This consists of the hardware components CAN controller 1513 and CAN transceiver (not shown) and from the two software components application software 1511 and the time synchronization software 1512 , There is an interface between both software components 1514 ,

The right part shows the hardware solution as suggested here for the time synchronization. With the reference number 1520 is the CAN interface of the engine control unit 150 designated. This consists of the hardware components CAN controller 1513 and CAN transceiver (not shown) and from the software component application software 1521 , Instead of the software block 1512 is in the CAN controller 1522 a hardware block is provided for the time synchronization. The synchronization messages 1516 (SYNC, FUP, OFS and OFNS) those of the time master 140 are used in both solutions. Also the other CAN messages 1517 are the same in both cases. The software solution has a data interface 1515 between CAN controllers 1513 and software component 1511 , Next to the data interface 1523 between CAN controllers 1522 and software component 1521 There is also a register interface for the hardware solution 1524 for setting and reading the registers of the hardware block for the time synchronization.

4 shows the structure of the hardware block for the time synchronization according to the proposed hardware solution. The hardware block is with the reference number 1530 Mistake. The local clock is formed by a counter that matches the local clock 2212 of the clock is triggered. To obtain timestamps, the counter is with a local time register 222 Mistake. The local time can be read out by the microcomputer of the control unit. There is a corresponding bus for this 2213 to the local time register 222 connected. The timestamps can be in the timestamp register 226 be recorded. The timestamp register 226 is accordingly over another bus 2218 with the local time register 222 connected. The SYNC and FBD messages are sent via the CAN bus 104 receive and the synchronization information contained therein (time information / timestamp) be in a sync register 228 accepted. This sync register 228 is over the bus 2224 with the timestamp register 226 in connection. When the SYNC message arrives, the time stamp becomes t2r recorded as related to 3 explained. The timestamp is over the bus 2221 to a computing unit 221 forwarded to calculate the global network time. For the OFS and OFNS messages, they are over the CAN bus 104 are received and the synchronization information contained therein (time information / time stamp) in an offset register 229 be taken over. This is associated with a cache block 227 over the interface 2226 in connection. Into the cache block 227 also get the information from the sync register 228 accepted. This is the sync register 228 over the interface 2225 with the memory block 227 connected. The memory block 227 serves to collect and aggregate the values coming over the bus in the SYNC, FUP, OFS and OFNS messages. In one embodiment, the four pieces of synchronization information may be aggregated into one useable timestamp. For this purpose, the buffer block contains a small arithmetic unit. Then the arithmetic unit 221 access it to calculate global network time. It suffices if the information from two consecutive synchronization cycles is made available in the memory. The implementation can therefore be done as a ring buffer, with the new data being fed in one place, and the stored data taken elsewhere. When feeding the data, the existing data will be overwritten. The ring buffer thus corresponds to a unit for the aggregation of time information.

Like the calculation of the global network time in the arithmetic unit 221 works, is below using the 5 explained in more detail. Different calculation types can be used here. This is the arithmetic unit 221 configurable executed. It is therefore a configuration register 224 available. This can be done via the application software 1521 be set. It is a bus interface to it 2214 intended. The configuration register 224 is about the interface 2219 with the arithmetic unit 221 in connection.

To the arithmetic unit 221 is still an interrupt generator 223 over the bus 2220 connected. The interrupt generator 223 generates interrupts / events for time-critical actions that are controlled by global network time. This is done by the network time via the interface 2200 the interrupt generator 223 made available. The interrupt generator can therefore include a timer / counter unit that triggers time-critical actions. The interrupt generator 223 is therefore also designed programmable. The programming is done via the interrupt configuration register 225 , This register 225 is programmed via the application software. This is the corresponding bus interface 2217 shown.

5 shows the different methods for the synchronization of the local clock 222 of the control unit 151 , Along the abscissa the local time t is plotted; the network time t _{n is} plotted along the ordinate. The curve B shows the run of the local clock 222 , Because the local clock 222 With the local clock derived from the local quartz oscillator, there is too much slope for the curve B , Synchronization does not change the local clock. The clock 222 will therefore be readjusted again and again at the synchronization times, but will either resume after a short time if the local clock in the slave runs faster than the clock in the time master or if the local clock in the slave runs slower than the clock in the time slot. Master. The synchronization interval is eg 125 ms. The measuring point M (t1, tn1m) corresponds to the correct value of the network time, which results from the synchronization messages SYNC, FUP, OFS and OFNS and the time stamp t1 acquired therefor. It is practically the target value. The point ACNT corresponds to the value for the network time calculated at the synchronization time in the control unit. However, this is subject to an error, so that a correction is required. A synchronization time is in 5 With t1 designated. The following synchronization time is in 5 with the time t2e specified. Previously, the synchronization time was the time t0 but this one is in 5 not shown.

With curve A the time taken for the correct time of the global network time is illustrated. Strictly speaking, it is not the correct run, but the one the slave presumably considers to be the correct one. This deviates from the actual, real history due to errors that a potential omnipresent observer might see. It is clearly the divergence of time between the local clock 222 and global network time. Both clocks do not have to specify absolute time values with UTC reference. In the field of control units, it is customary to use a relative time, for example the time after the vehicle is started. For some applications, the UTC reference is desirable.

mit dem folgenden „Rate Correction“-Faktor r₁: $$r_1=\frac{t_{n1m}-t_{n0m}}{t_1-t_0}$$

For the time correction of the local clock different mechanisms are proposed in AUTOSAR. These are Rate Correction, Rate Adaptation and Jump Correction. The curve C illustrates the Rate Correction method. Using this method, the local time, whenever it is read out, is corrected according to the following formula: $$t_n\left(t\right)=r_1*\left(t-t_1\right)+t_{n1a}beit\ge t_1$$

with the following Rate Correction factor r ₁ : $$r_1=\frac{t_{n1m}-t_{n0m}}{t_1-t_0}$$

The values t ₁ and t _{n1a are} off 5 seen. The values t _n0m and t ₀ are in 5 not shown, but correspond to the measured values of the previous interval. They are in the memory block 227 still available and can be taken over for the calculation of there. As with a curve C Although the method of "Rate Correction" shows the gradient of the curve B corrected from the time t ₁ , but all values that have been corrected in this way are still too large by the error ε1.

mit dem folgenden „Rate Adaptation“-Faktor a₁: $$a_1=\frac{t_{n2e}-t_{n1a}}{t_{2e}-t_1}.$$

The result of the correction according to the "Rate Adaptation" method is in 5 at curve D seen. In addition to the correction using the method "Rate Correction", another correction takes place, which practically compensates the error ε1 over the current synchronization interval. The calculation formulas for the Rate Adaptation method are as follows: $$t_n\left(t\right)=a_1*\left(t-t_1\right)+t_{n1a}beit\ge t_{1}und{m}_1=a_1$$

with the following "Rate Adaptation" factor a ₁ : $$a_1=\frac{t_{n2e}-t_{n1a}}{t_{2e}-t_1},$$

Where t _{2e is} the time calculated by the time slave. It is the value after the local clock at which the next synchronization time is expected, s. below.

For the in 5 given angle holds the following relationship: $${\gamma }_1={\beta }_1-{\alpha }_1=\text{arctan}\left(m_0\right)-\text{arctan}\left(a_1\right),$$

dabei entspricht m₀: der nach der gleichen Formel wie a₁ berechneten Steigung aus dem vorhergehenden Synchronisationsintervall.With a ₁ : $$a_1=\frac{t_{n2e}-t_{n1a}}{t_{2e}-t_1}$$

where m ₀ corresponds to the slope calculated from the previous synchronization interval using the same formula as a ₁ .

wobei für r₁ wieder gilt, s. oben: $$r_1=\frac{t_{n1m}-t_{n0m}}{t_1-t_0}.$$

In 5 is still a third method of correction shown. In addition to Rate Correction, this method includes a step called Jump Correction. After the "Rate Correction" the error ε1 remains. This is determined in the step of the jump correction from the value of the local clock read at time t1 with the coordinates (t ₁ , t _1na ), s. 5 deducted. Then the corrected values lie on the curve A representing the course of the network time t _n over the local time t. The following formulas are used for this correction method: $$t_n\left(t\right)=r_1*\left(t-t_1\right)+t_{n1m}beit\ge t_{1}und{m}_1=r_1$$

where again for r ₁ , s. above: $$r_1=\frac{t_{n1m}-t_{n0m}}{t_1-t_0},$$

wobei für r₁ wieder gilt, s. oben: $$r_1=\frac{t_{n1m}-t_{n0m}}{t_1-t_0}.$$

The next expected synchronization time t _2e is calculated according to the following formula: $$t_{2e}=r_1*t_{sync}+t_1$$

where again for r ₁ , s. above: $$r_1=\frac{t_{n1m}-t_{n0m}}{t_1-t_0},$$

For the error value ε ₁ : $${\epsilon }_1=t_{n1a}-t_{n1m},$$

$$\alpha \ge {\alpha }_{min}$$

$$\epsilon \le {\epsilon }_{max}$$

$$\left|\gamma \right|\le {\gamma }_{max}.$$

Basically, the method of rate adaptation is to be preferred. However, it is only applicable if the following angle conditions are met: $$\alpha \le {\alpha }_{max}$$

$$\alpha \ge {\alpha }_{min}$$

$$\epsilon \le {\epsilon }_{max}$$

$$\left|\gamma \right|\le {\gamma }_{max},$$

The disclosure is not limited to the embodiments described herein. There is room for various adjustments and modifications that the professional due to his Expertise as well as belonging to the disclosure.

All examples mentioned herein as well as conditional formulations are to be understood without limitation to such specifically mentioned examples. For example, it will be appreciated by those skilled in the art that the block diagram presented here represents a conceptual view of exemplary circuitry. Similarly, it will be appreciated that an illustrated flowchart, state transition diagram, pseudocode, and the like are various variants for representing processes that may be stored substantially in computer-readable media and thus executed by a computer or processor.

It should be understood that the proposed method and apparatus may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. Special purpose processors may include Application Specific Integrated Circuits (ASICs), Reduced Instruction Set Computer (RISC), and / or Field Programmable Gate Arrays (FPGAs). Preferably, the proposed method and apparatus is implemented as a combination of hardware and software. The software is preferably installed as an application program on a program storage device. Typically, it is a machine based computer platform that includes hardware such as one or more central processing units (CPU), random access memory (RAM), and one or more input / output (I / O) interface (s). The computer platform also typically installs an operating system. The various processes and functions described herein may be part of the application program, or part that is executed via the operating system.

LIST OF REFERENCE NUMBERS

100

Automotive electronics

102

Infotainment Bus

104

CAN bus

105

camera

110

On-board unit

120

navigation system

130

operating unit

140

gateway

151

Motor control unit

152

ESP control unit

153

Transmission controller

161

Sensor 1

162

Sensor 2

163

Sensor 3

221

Network time arithmetic unit

222

Local time register

223

Interrupt generator

224

Configuration Registers

225

Interrupt configuration register

226

Time stamp acquisition unit

227

cache

228

Synchronization register

229

Offset register

1510

1. Architecture CAN bus interface

1511

1. Application software

1512

Time synchronization software

1513

1. CAN controller

1514

1st interface

1515

2nd interface

1516

3rd interface

1517

4th interface

1520

2. Architecture CAN bus interface

1521

2. Application software

1522

2. CAN controller

1523

5th interface

1525

6th interface

1526

7. Interface

2210

8. Interface

2211

9. Interface

2212

10. Interface

2213

11th interface

2214

12th interface

2215

13th interface

2216

14th interface

2217

15th interface

2218

16th interface

2219

17th interface

2220

18th interface

2221

19th interface

2222

20th interface

2223

21st interface

2224

22nd interface

2225

23. Interface

2226

24. Interface

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• DE 10207222 A1 [0010]
• EP 1543389 B1 [0011]
• EP 3015227 A1 [0012]

Cited non-patent literature

• ISO standard [0032]
• ISO 11898 [0032]

Claims (11)

Clock synchronization apparatus in control units (151, 152, 153) networked together via a communications bus (104), the controllers (151, 152, 153) having a local clock (222) periodically associated with a global clock synchronization, wherein for synchronization periodically synchronization messages, from a reference timer (140) over the communication bus (104) are received, characterized in that the device comprises a time stamp unit (226) and a reference time computing unit (221) and a buffer (227), wherein the time stamp unit (226) detects the time of arrival of a synchronization message after the local clock (222), and this detected time of the reference time computing unit (221) provides, the synchronization information in the Synchronization messages in the buffer (227) are collected and also the reference time computing unit (221) availgu ng be made. Device after Claim 1 in which a configuration register (224) is provided which is used for setting parameters and the type of calculation of the time correction values in the reference time calculation unit (221). Device after Claim 1 or 2 wherein the communications bus (104) is implemented as a CAN bus or as a CAN FD bus according to Controller Area Network and Controller Area Network Flexible Data Rate, and wherein the synchronization messages are in the format of the AUTOSAR standard entitled "Specification of Time Synchronization over CAN "are received according to AUOTSAR CP Release 4.3.0, wherein for the acquisition of the data in the synchronization messages SYNC and FUP a synchronization register (228) and for the transfer of the data in the synchronization messages OFS and OFNS an offset Register (229) is preceded by the latch (226). Device after Claim 3 , wherein the buffer is used to aggregate the individual components in the synchronization messages SYNC, FUP and OFS, OFNS. Device after Claim 3 or 4 , which can be set via the configuration register (224), the "Rate Correction" and "Offset Correction" calculation types mentioned in the AUTOSAR standard. Device after Claim 5 , wherein via the configuration register (224), the calculation method "Offset Correction" mentioned in the AUTOSAR standard can be set to the two variants "Jump Correction" and "Rate Adaptation". Device according to one of Claims 3 to 6 in which the time stamp unit at least provides the arrival of the information in the synchronization message SYNC with a time stamp. Device according to one of the preceding claims, wherein furthermore an interrupt generator unit (223) is provided for triggering time-synchronized actions, which is in communication with the reference time computing unit (221). Device after Claim 8 , wherein for the interrupt generator unit (223) an interrupt configuration register (225) is provided, via which is adjustable at what times or with which time period an interrupt should be triggered. Device according to one of the preceding claims, wherein the reference time computing unit (221) calculates a network time and wherein a register (225) is provided, in which the calculated network time is taken for easy reading for other components. Control unit, characterized in that the control device is a device according to one of Claims 1 to 10 having.

Images