Time-Synchronization Method for CAN–Ethernet Networks with Gateways

Featured Application: Authors are encouraged to provide a concise description of the speciﬁc application or a potential application of the work. This section is not mandatory. Abstract: Time-synchronization technology can provide a common notion of time among the participating nodes on a network. This is essential not only for protocol operation for time-critical services but also for the time stamp for information included in the message. Precise time information can be very crucial for such things as autonomous driving because there are various sensor measurements from multiple cameras, and radio detection and ranging (radar) and light detection and ranging (LiDAR) are used for perceiving the current situation via sensor fusion. A well-known synchronization method, IEEE 1588, denoted as the precision time protocol (PTP), can be used for various applications. For in-vehicle networks of autonomous cars, we have to consider that the network may be comprised of subnetworks based on di ﬀ erent protocols such as controller area network (CAN) and Ethernet. However, implementing PTPs on such heterogeneous vehicle networks causes several problems. First, the PTP procedure must be modiﬁed to be implement on a CAN network. Second, to calculate the delay and o ﬀ set for PTP, the processing delay that occurs during message conversion must be considered. In this paper, we propose a synchronization method for CAN–Ethernet networks to solve these problems. The performance of the proposed synchronization method is evaluated by experiments on a real CAN–Ethernet network.


Overview of IEEE 1588
IEEE 1588, also referred to as the PTP, is an international standard for the precise time clock synchronization of measurement and control systems used in various environments, such as communications, local computing, and distributed systems. IEEE 1588v1 (first published in 2002) operated only on local area networks (LANs), while IEEE 1588v2 (published in 2008) supports unicast and multicast modes. Through these standards, packets containing time-synchronization information are transmitted through routers and switches, providing precise time synchronization for various Ethernet-based protocols. IEEE 1588 specifies several functions for time synchronization; these include the best master clock (BMC) algorithm, which selects a clock master in a master-slave structure, and a method that calculates the delay and offset to synchronize the time clock of the slave nodes with that of the master. The standard also specifies several measures in the case of failure of the device selected as the master.

Time-Synchronization Mechanism of PTP
PTP, which is defined in IEEE 1588, calculates the delay and offset through PTP messages exchanged between the master and slave and synchronizes their clocks. In this process, the PTP message type is determined according to the synchronization mechanism. Mechanisms for correcting the offset and delay through PTP include end-to-end (E2E) and peer-to-peer (P2P), which are also referred to as a delay-request response and peer delay, respectively. Figure 1a presents the synchronization mechanism of the E2E method. In the E2E method, four types of synchronization messages are exchanged between the master and slave, through which the delay and offset are calculated and time is synchronized. First, the master transmits a synchronization message to the slave at time t 1 , and the slave receives it at time t 2 . Next, the master node stores t 1 in a follow-up message and transmits it to the slave node. The slave then transmits a delay-request message at time t 3 , and the master receives it at time t 4 . Finally, the master stores t 4 in the delay-response message and transmits it to the slave. Through this process, the slave can acquire four timestamps (t 1 , t 2 , t 3 , and t 4 ) to calculate the offset and propagation delay. Equations (1) and (2) are used to calculate the delay and offset between the master and slave nodes. In this process, the network must provide a link with a symmetrical structure, in which the transmission rates of the master and slave in both directions are identical.

End-To-End Mechanism
The four timestamps used in Equation (1) are the timestamp values generated by the master and slave nodes; the timestamp can be classified as a software-or hardware-based timestamp depending on the measurement method. The accuracy of the timestamp is highest when generated close to the physical layer, and, depending on whether the device supports PTP, the hardware-based timestamp is measured in the media access control (MAC) or physical (PHY) layer.

Peer-To-Peer Mechanism
In the E2E mechanism, the synchronization accuracy may decline if the paths connecting the master and slaves are composed of numerous devices. However, the P2P mechanism addresses this by performing synchronization between all neighboring devices, such as switches or routers. Although this technique requires that all neighboring devices support the P2P mechanism, it can ensure more accurate time synchronization. Moreover, unlike the E2E mechanism, the delay and offset can be calculated through three messages in the P2P mechanism. Figure 1b demonstrates the synchronization mechanism of the P2P method. First, the requester node transmits a pdelay-request message at time t 1 , and the responder node receives it at time t 2 . Next, the responder node stores time t 2 in the pdelay-response message and transmits it to the requester node, and the requester receives it at time t 4 . Finally, the responder stores time t 3 in a pdelay-request follow-up message and transmits it to the requester. Through this process, the requester acquires four timestamps and calculates the propagation delay and offset using Equations (1) and (2). The P2P mechanism is also based on a link with a symmetrical structure in which the transmission rates in both directions are identical, and the time-synchronization accuracy is determined according to the measurement position of the timestamp.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 4 of 11 The four timestamps used in Equation (1) are the timestamp values generated by the master and slave nodes; the timestamp can be classified as a software-or hardware-based timestamp depending on the measurement method. The accuracy of the timestamp is highest when generated close to the physical layer, and, depending on whether the device supports PTP, the hardware-based timestamp is measured in the media access control (MAC) or physical (PHY) layer.

Peer-To-Peer Mechanism
In the E2E mechanism, the synchronization accuracy may decline if the paths connecting the master and slaves are composed of numerous devices. However, the P2P mechanism addresses this by performing synchronization between all neighboring devices, such as switches or routers. Although this technique requires that all neighboring devices support the P2P mechanism, it can ensure more accurate time synchronization. Moreover, unlike the E2E mechanism, the delay and offset can be calculated through three messages in the P2P mechanism. Figure 1b demonstrates the synchronization mechanism of the P2P method. First, the requester node transmits a pdelay-request message at time t1, and the responder node receives it at time t2. Next, the responder node stores time t2 in the pdelay-response message and transmits it to the requester node, and the requester receives it at time t4. Finally, the responder stores time t3 in a pdelay-request follow-up message and transmits it to the requester. Through this process, the requester acquires four timestamps and calculates the propagation delay and offset using Equations (1) and (2). The P2P mechanism is also based on a link with a symmetrical structure in which the transmission rates in both directions are identical, and the time-synchronization accuracy is determined according to the measurement position of the timestamp.

Network-Synchronization Procedure via a Gateway
A gateway is needed to convey messages from one type of network to another. It is unavoidable to have a processing delay to convert the messages, which impacts the time-synchronization performance. Figure 2 illustrates the time-synchronization process of the E2E method in a CAN-

Network-Synchronization Procedure via a Gateway
A gateway is needed to convey messages from one type of network to another. It is unavoidable to have a processing delay to convert the messages, which impacts the time-synchronization performance. Figure 2 illustrates the time-synchronization process of the E2E method in a CAN-Ethernet network including a gateway with an Ethernet node as a master. t Eth2CAN indicates the processing delay_required Appl. Sci. 2020, 10, 8873 5 of 11 to convert an Ethernet message into a CAN message, and t CAN2Eth denotes the processing delay_required to convert a CAN message into an Ethernet message. t Eth2CAN is calculated by measuring the time interval from the time instant the gateway receives the Ethernet message to the moment it starts to transmit the converted CAN message. Conversely, t CAN2Eth is obtained by measuring the time interval from the time instant the gateway receives the CAN message to the time it begins to send the converted Ethernet message. Both t CAN2Eth and t Eth2CAN may have different values because the time required for each network to receive and convert the message differs. Consequently, the network has an asymmetrical structure when a gateway is included, which can prevent precise synchronization. Equations (3) and (4) represent propagation delay and offset calculations, considering the processing delay that occurs when a gateway converts a message in a CAN-Ethernet network.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 5 of 11 Ethernet network including a gateway with an Ethernet node as a master. tEth2CAN indicates the processing delay_required to convert an Ethernet message into a CAN message, and tCAN2Eth denotes the processing delay_required to convert a CAN message into an Ethernet message. tEth2CAN is calculated by measuring the time interval from the time instant the gateway receives the Ethernet message to the moment it starts to transmit the converted CAN message. Conversely, tCAN2Eth is obtained by measuring the time interval from the time instant the gateway receives the CAN message to the time it begins to send the converted Ethernet message. Both tCAN2Eth and tEth2CAN may have different values because the time required for each network to receive and convert the message differs. Consequently, the network has an asymmetrical structure when a gateway is included, which can prevent precise synchronization. Equations (3) and (4) represent propagation delay and offset calculations, considering the processing delay that occurs when a gateway converts a message in a CAN-Ethernet network. To calculate the propagation delay and offset in a CAN-Ethernet network with a gateway, the slave must confirm the values of tEth2CAN and tCAN2Eth. For this purpose, the gateway can store the calculated value of tEth2CAN in the synchronization message and transmit it to the slave, while tCAN2Eth can be stored in the delay-request message and transmitted to the master. The master learns tCAN2Eth at time t4 after receiving the delay-request message, stores the value obtained by subtracting tCAN2Eth from t4 in the delay-response message, and transmits it to the slave. To calculate the propagation delay and offset in a CAN-Ethernet network with a gateway, the slave must confirm the values of t Eth2CAN and t CAN2Eth . For this purpose, the gateway can store the calculated value of t Eth2CAN in the synchronization message and transmit it to the slave, while t CAN2Eth can be stored in the delay-request message and transmitted to the master. The master learns t CAN2Eth at time t 4 after receiving the delay-request message, stores the value obtained by subtracting t CAN2Eth from t 4 in the delay-response message, and transmits it to the slave.

Setting of the PTP Message Format
To synchronize the time between the Ethernet and CAN networks, the PTP messages must be converted into a format suitable for the message format of each network through the gateway. Figure 3 shows a comparison of the formats of the existing PTP and CAN messages and a converted PTP message format for time synchronization between heterogeneous networks. The PTP message consists of a header and timestamp, and the timestamp consists of a 6-byte-seconds field and 4-byte-nanoseconds field. In contrast, because the total size of the data field of a CAN message is 8 bytes, it is insufficient to store the timestamp of the PTP message. In this study, the upper two bytes of the seconds field in the existing PTP message are removed to store the 8-byte timestamp in the CAN message. These two deleted bytes are information used to mark the accurate year; hence, their exclusion from the timestamp should not significantly impact the system. If the accurate time is required, the master can transmit the 2-byte value deleted during system initialization to the slave and set the complete time.

Setting of the PTP Message Format
To synchronize the time between the Ethernet and CAN networks, the PTP messages must be converted into a format suitable for the message format of each network through the gateway. Figure  3 shows a comparison of the formats of the existing PTP and CAN messages and a converted PTP message format for time synchronization between heterogeneous networks. The PTP message consists of a header and timestamp, and the timestamp consists of a 6-byte-seconds field and 4-bytenanoseconds field. In contrast, because the total size of the data field of a CAN message is 8 bytes, it is insufficient to store the timestamp of the PTP message. In this study, the upper two bytes of the seconds field in the existing PTP message are removed to store the 8-byte timestamp in the CAN message. These two deleted bytes are information used to mark the accurate year; hence, their exclusion from the timestamp should not significantly impact the system. If the accurate time is required, the master can transmit the 2-byte value deleted during system initialization to the slave and set the complete time.  Figure 4 presents the time-synchronization algorithm of the master (Ethernet) and slave (CAN) nodes in the CAN-Ethernet network. In Figure 4a, the master transmits the synchronization message to the slave and stores the timestamp (t1) in the memory buffer. Then, after storing t1 in the follow-up message, it is transmitted to the slave. Next, it checks whether the delay-request message transmitted from the slave node has been received. If the delay-request message has been received, then the timestamp (t4) and timestamp included in the message (tCAN2Eth) are stored in the memory buffer. Finally, the calculated value of t4-tCAN2Eth is stored in the delay-response message and transmitted to the slave.

Time-Synchronization Algorithm of the CAN-Ethernet Network
In Figure 4b, the slave checks whether the synchronization message transmitted from the master has been received. If the message has been received, then the timestamp (t2) and timestamp included in the synchronization message (tEth2CAN) are stored in the memory buffer. Next, it waits until the follow-up message transmitted from the master is received. If the follow_up message is received, then the timestamp (t1) included in the message is stored in the memory buffer. A delay-required message is then transmitted to the master, and after storing the timestamp (t3), it waits until the delayresponse message transmitted from the master is received. If the delay-response message is received, then the timestamp (t4-tCAN2Eth) included in the message is stored. Finally, the saved timestamps (t1, t2, t3, t4-tCAN2Eth, and tEth2CAN) are used to calculate the delay and offset. Figure 4c shows the time-synchronization algorithm of the gateway in the CAN-Ethernet network. The gateway first checks whether a synchronization message transmitted from the master is received. If a synchronization message is received, then it is converted into a CAN message, and tEth2CAN, which is the time from the receipt of the synchronization message until the completion of conversion, is calculated. tEth2CAN is then stored in the synchronization message converted for the CAN network and transmitted to the slave. If a follow-up message or delay-response message transmitted from the master is received, it is converted into a CAN message and transmitted to the slave. Finally, once the delay-request message transmitted from the slave is received, it is converted into an Ethernet  Figure 4 presents the time-synchronization algorithm of the master (Ethernet) and slave (CAN) nodes in the CAN-Ethernet network. In Figure 4a, the master transmits the synchronization message to the slave and stores the timestamp (t 1 ) in the memory buffer. Then, after storing t 1 in the follow-up message, it is transmitted to the slave. Next, it checks whether the delay-request message transmitted from the slave node has been received. If the delay-request message has been received, then the timestamp (t 4 ) and timestamp included in the message (t CAN2Eth ) are stored in the memory buffer. Finally, the calculated value of t4-t CAN2Eth is stored in the delay-response message and transmitted to the slave.

Time-Synchronization Algorithm of the CAN-Ethernet Network
In Figure 4b, the slave checks whether the synchronization message transmitted from the master has been received. If the message has been received, then the timestamp (t 2 ) and timestamp included in the synchronization message (t Eth2CAN ) are stored in the memory buffer. Next, it waits until the follow-up message transmitted from the master is received. If the follow_up message is received, then the timestamp (t 1 ) included in the message is stored in the memory buffer. A delay-required message is then transmitted to the master, and after storing the timestamp (t 3 ), it waits until the delay-response message transmitted from the master is received. If the delay-response message is received, then the timestamp (t 4 -t CAN2Eth ) included in the message is stored. Finally, the saved timestamps (t 1 , t 2 , t 3 , t 4 -t CAN2Eth , and t Eth2CAN ) are used to calculate the delay and offset. Figure 4c shows the time-synchronization algorithm of the gateway in the CAN-Ethernet network. The gateway first checks whether a synchronization message transmitted from the master is received. If a synchronization message is received, then it is converted into a CAN message, and t Eth2CAN , which is the time from the receipt of the synchronization message until the completion of conversion, is calculated. t Eth2CAN is then stored in the synchronization message converted for the CAN network and transmitted to the slave. If a follow-up message or delay-response message transmitted from the master is received, it is converted into a CAN message and transmitted to the slave. Finally, once the delay-request message transmitted from the slave is received, it is converted into an Ethernet message, and t CAN2Eth , which is the time from the receipt of the delay-request message until the completion of conversion, is calculated. t CAN2Eth is then stored in the converted delay-request message and transmitted to the master. message, and tCAN2Eth, which is the time from the receipt of the delay-request message until the completion of conversion, is calculated. tCAN2Eth is then stored in the converted delay-request message and transmitted to the master.

Time-Synchronization Method of the CAN Network
The PTP procedure can be directly applicable to an homogeneous CAN network. Unlike Ethernet, which uses a 1:1 connection, a CAN network employs bus topology where broadcast transmission is readily available [20]. This feature can be used to synchronize all the CAN nodes without repeating PTP procedure for each node. We can design the procedure so that a master node can transmit synchronization and follow-up messages only once. However, slave nodes will try to

Time-Synchronization Method of the CAN Network
The PTP procedure can be directly applicable to an homogeneous CAN network. Unlike Ethernet, which uses a 1:1 connection, a CAN network employs bus topology where broadcast transmission is readily available [20]. This feature can be used to synchronize all the CAN nodes without repeating PTP procedure for each node. We can design the procedure so that a master node can transmit synchronization and follow-up messages only once. However, slave nodes will try to transmit a delay-request message almost simultaneously, which will cause message collisions. To prevent these collisions, we may assign different IDs for each delay-request message, which will increase the duration of the synchronization process and the network traffic. Instead, we selected a single slave node to perform the delay calculation using Equation (1) and let the node broadcast the results to other nodes. Figure 5 shows the method for sharing the delay between slave nodes. First, the master transmits synchronization and follow-up messages to all slaves, and slave 1 stores t 1 and t 2 . Slaves 2 and 3 share t 1 , but because the reception time differs, they store t 2 * and t 2 **, respectively. Next, the time synchronization procedure is performed for only slave 1 to calculate the delay. The calculated delay is transmitted to the remaining slaves, and the previously-stored timestamps (t 1 and t 2 *, or t 1 and t 2 **) are used to calculate the offset using Equation (2). This modified procedure can simplify the synchronization over the broadcast medium although synchronization error may increase as the length of network increases.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 8 of 11 transmit a delay-request message almost simultaneously, which will cause message collisions. To prevent these collisions, we may assign different IDs for each delay-request message, which will increase the duration of the synchronization process and the network traffic. Instead, we selected a single slave node to perform the delay calculation using Equation (1) and let the node broadcast the results to other nodes. Figure 5 shows the method for sharing the delay between slave nodes. First, the master transmits synchronization and follow-up messages to all slaves, and slave 1 stores t1 and t2. Slaves 2 and 3 share t1, but because the reception time differs, they store t2* and t2**, respectively. Next, the time synchronization procedure is performed for only slave 1 to calculate the delay. The calculated delay is transmitted to the remaining slaves, and the previously-stored timestamps (t1 and t2*, or t1 and t2**) are used to calculate the offset using Equation (2). This modified procedure can simplify the synchronization over the broadcast medium although synchronization error may increase as the length of network increases.  Figure 6 shows the experimental setup for the performance evaluation of the CAN-Ethernet network synchronization. Five NXP MPC5748-LCEVB modules were used for the nodes and gateway. MPC5748 is a chipset for vehicle use and supports CAN (CAN FD) and 100-Mbps Ethernet networks. The network topology for the performance evaluation comprised a master node (Ethernet), gateway, and three slave nodes (CAN), and an oscilloscope was used to measure the synchronization error. To emulate a CAN network with many nodes, CAN slave 3 was connected with a 15 m cable. To generate timestamps, each node used a software-based timestamp.    Figure 6 shows the experimental setup for the performance evaluation of the CAN-Ethernet network synchronization. Five NXP MPC5748-LCEVB modules were used for the nodes and gateway. MPC5748 is a chipset for vehicle use and supports CAN (CAN FD) and 100-Mbps Ethernet networks. The network topology for the performance evaluation comprised a master node (Ethernet), gateway, and three slave nodes (CAN), and an oscilloscope was used to measure the synchronization error. To emulate a CAN network with many nodes, CAN slave 3 was connected with a 15 m cable. To generate timestamps, each node used a software-based timestamp.

Evaluation of the CAN-Ethernet Network Time-Synchronization Performance
Appl. Sci. 2020, 10, x FOR PEER REVIEW 8 of 11 transmit a delay-request message almost simultaneously, which will cause message collisions. To prevent these collisions, we may assign different IDs for each delay-request message, which will increase the duration of the synchronization process and the network traffic. Instead, we selected a single slave node to perform the delay calculation using Equation (1) and let the node broadcast the results to other nodes. Figure 5 shows the method for sharing the delay between slave nodes. First, the master transmits synchronization and follow-up messages to all slaves, and slave 1 stores t1 and t2. Slaves 2 and 3 share t1, but because the reception time differs, they store t2* and t2**, respectively. Next, the time synchronization procedure is performed for only slave 1 to calculate the delay. The calculated delay is transmitted to the remaining slaves, and the previously-stored timestamps (t1 and t2*, or t1 and t2**) are used to calculate the offset using Equation (2). This modified procedure can simplify the synchronization over the broadcast medium although synchronization error may increase as the length of network increases.  Figure 6 shows the experimental setup for the performance evaluation of the CAN-Ethernet network synchronization. Five NXP MPC5748-LCEVB modules were used for the nodes and gateway. MPC5748 is a chipset for vehicle use and supports CAN (CAN FD) and 100-Mbps Ethernet networks. The network topology for the performance evaluation comprised a master node (Ethernet), gateway, and three slave nodes (CAN), and an oscilloscope was used to measure the synchronization error. To emulate a CAN network with many nodes, CAN slave 3 was connected with a 15 m cable. To generate timestamps, each node used a software-based timestamp. The synchronization error is defined as the difference in the perceived global times. To measure the error, slave nodes were programmed to output trigger signals to a certain pin so that the oscilloscope captured the time instants. In addition, the synchronization procedure was periodically repeated every 1 s to limit the effect of difference in clock rates. The trigger signal for measuring synchronization performance was set to output approximately 800 ms after the time synchronization ended. Figure 7 demonstrates the time difference of the trigger signals from the nodes before and after time synchronization was performed. The rising edges of the output signals from the nodes were not aligned before synchronization while the edges were rising almost simultaneously after synchronization. These results confirmed that the proposed algorithm enables time synchronization in the CAN-Ethernet network.

Evaluation of the CAN-Ethernet Network Time-Synchronization Performance
Appl. Sci. 2020, 10, x FOR PEER REVIEW 9 of 11 The synchronization error is defined as the difference in the perceived global times. To measure the error, slave nodes were programmed to output trigger signals to a certain pin so that the oscilloscope captured the time instants. In addition, the synchronization procedure was periodically repeated every 1 s to limit the effect of difference in clock rates. The trigger signal for measuring synchronization performance was set to output approximately 800 ms after the time synchronization ended. Figure 7 demonstrates the time difference of the trigger signals from the nodes before and after time synchronization was performed. The rising edges of the output signals from the nodes were not aligned before synchronization while the edges were rising almost simultaneously after synchronization. These results confirmed that the proposed algorithm enables time synchronization in the CAN-Ethernet network.  Figure 8 shows the oscilloscope measurement results of the synchronization error occurring in the four nodes after performing time synchronization in the CAN-Ethernet network. According to the measurements, when the proposed synchronization algorithm was applied, the maximum synchronization error between the master and slave was approximately 9.68 µs. Table 1 presents the synchronization error when the above experiment was repeated ten times. The average of the synchronization errors was approximately 8.18 µs, with a worst-case error of 9.68 µs. Although various factors can cause this error, the timestamp function, which measures and records time, is most likely to significantly influence this error, because it is operated by software.   Figure 8 shows the oscilloscope measurement results of the synchronization error occurring in the four nodes after performing time synchronization in the CAN-Ethernet network. According to the measurements, when the proposed synchronization algorithm was applied, the maximum synchronization error between the master and slave was approximately 9.68 µs. Table 1 presents the synchronization error when the above experiment was repeated ten times. The average of the synchronization errors was approximately 8.18 µs, with a worst-case error of 9.68 µs. Although various factors can cause this error, the timestamp function, which measures and records time, is most likely to significantly influence this error, because it is operated by software.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 9 of 11 The synchronization error is defined as the difference in the perceived global times. To measure the error, slave nodes were programmed to output trigger signals to a certain pin so that the oscilloscope captured the time instants. In addition, the synchronization procedure was periodically repeated every 1 s to limit the effect of difference in clock rates. The trigger signal for measuring synchronization performance was set to output approximately 800 ms after the time synchronization ended. Figure 7 demonstrates the time difference of the trigger signals from the nodes before and after time synchronization was performed. The rising edges of the output signals from the nodes were not aligned before synchronization while the edges were rising almost simultaneously after synchronization. These results confirmed that the proposed algorithm enables time synchronization in the CAN-Ethernet network.  Figure 8 shows the oscilloscope measurement results of the synchronization error occurring in the four nodes after performing time synchronization in the CAN-Ethernet network. According to the measurements, when the proposed synchronization algorithm was applied, the maximum synchronization error between the master and slave was approximately 9.68 µs. Table 1 presents the synchronization error when the above experiment was repeated ten times. The average of the synchronization errors was approximately 8.18 µs, with a worst-case error of 9.68 µs. Although various factors can cause this error, the timestamp function, which measures and records time, is most likely to significantly influence this error, because it is operated by software.

Conclusions
This study proposed a method for performing time synchronization on a CAN-Ethernet heterogeneous network connected by a gateway. In particular, the study proposed a time-synchronization method that considered the processing delay in the gateway required to convert the messages. Moreover, a synchronization method for CAN networks was proposed in which the slaves shared the calculated delay to simplify the procedure by exploiting CAN's bus topology. In addition, the CAN message format was proposed to convey PTP messages over the CAN network. Finally, a test bed was constructed using automotive microcontroller modules, and used to evaluate the time-synchronization performance of the proposed method for heterogeneous CAN-Ethernet networks. The following conclusions may be drawn from the obtained results.
First, the synchronization method of IEEE 1588 was extended to develop a synchronization method for heterogeneous networks connected by a gateway. For this purpose, equations were derived to calculate the propagation delay and offset by considering the asymmetric processing time of the gateway. Furthermore, to implement the required synchronization technique, this study proposed a method that accommodates the maximum data size constraint of the CAN and the difference in bus transmission methods.
Second, the evaluation of synchronization performance demonstrated that the proposed method has an error of approximately 7 µs. While this does not satisfy the 1 µs error suggested in IEEE 1588, it indicates that the method can provide satisfactory synchronization precision for applications, such as autonomous driving, despite the use of software timestamps. Therefore, because the output of the sensors connected to the synchronized CAN nodes is measured within approximately 7 µs, it is expected to enhance context recognition performance via sensor fusion.
In terms of future research directions, follow-up studies may replace the software timestamps with hardware timestamps and experimentally verify the extent to which the system performance can be improved. Research is also required concerning methods to introduce the P2P method of IEEE 1588 and the selection of the appropriate CAN nodes to perform synchronization with the Ethernet master node. In addition, more research effort on synchronization should be directed to more complicated network structures such as Ethernet connected with tandem CAN networks and other types of heterogeneous networks, namely, CAN-MOST and CAN-FlexRay.