Abstract:
A computer-implemented method for synchronizing nodes on a controller area network includes identifying, via a processor, a node from a plurality of nodes as a sync master node; designating, via the processor, each of the remaining nodes as a sync slave node; designating, via the processor, the first message from the sync master node as a sync message; assigning, via the processor, the lowest number, among all the message IDs in the network system, to the message ID of the sync message; determining a sync message target receiving time on a sync slave node; and triggering an interrupt to the processor responsive to receiving the sync message on a sync slave node in the controller area network to perform time adjustment on the sync slave node.

Description:
BACKGROUND 
       [0001]    The present disclosure relates to controller area networks, and more specifically, to controller area network nodes synchronization. 
         [0002]    A controller area network (CAN) is a vehicle bus standard designed to allow microcontrollers and devices to communicate with each other. CAN networks include a message-based protocol that was originally designed for multiplex electrical wiring in road vehicles. Due to its real time and data collision avoidance properties, CAN has been widely used in the other industries including aerospace. 
         [0003]    Typically, in nodes on a CAN bus (for example, the CAN discussed below with respect to  FIG. 1 ), the periodic CAN application tasks running on microcontrollers have the same task cycle time by design, and each CAN node may transmit a group of messages (message burst) on the CAN bus and receive messages from the other nodes once every CAN task cycle. The periodic CAN messages are produced and consumed by the periodic CAN application tasks. However, since the CAN protocol does not provide accurate global time service and each node has its own clock, the CAN task cycles on the CAN nodes are not synchronized to each other, which makes the CAN task cycles with the message pack/unpack procedures in the CAN nodes and consequently message bursts on CAN bus drift away from each other over time. 
         [0004]    This can cause overwritten messages and absent messages. The overwritten message occurs when two messages (with the same message identifier but possibly different settings for the same set of parameters inside), transmitted once in each of two consecutive CAN task cycles from a node, are received in one CAN task cycle on a receiving node. This phenomenon can result in a lost message on the receiving node, where either the older or the newer message gets dropped depending on the CAN application interface setup. The absent message occurs when a message, transmitted once every CAN task cycle from a transmission node, is supposed to be but is not received in a CAN task cycle on a receiving node, which can result in stale data from the previously received message being used by the applications. The jitters from different procedures executing on the microcontroller in the CAN node can worsen the effects of overwritten and absent message. CAN bus contention, where multiple CAN nodes attempt to transmit on the CAN bus at the same time and one or more CAN nodes are required to wait until the bus is free, can also worsen this effect. Lost and/or absent messages may not be tolerable in mission critical applications. 
       SUMMARY 
       [0005]    According to an embodiment of the present invention, a computer-implemented method for synchronizing nodes on a controller area network is described. The method may include: identifying, via a processor, a node from a plurality of nodes as a sync master node; designating, via the processor, each of the remaining nodes as a sync slave node; designating, via the processor, the first message from the sync master node as a sync message; assigning, via the processor, the lowest number, among all the message IDs in the network system, to the message ID of the sync message; determining a sync message target receiving time on a sync slave node; and triggering an interrupt to the processor responsive to receiving the sync message on a sync slave node in the controller area network to perform time adjustment on the sync slave node. 
         [0006]    According to another embodiment, an aircraft having a system for synchronizing nodes on a controller area node network system for synchronizing nodes on a controller area node network is described. The system may include a processor configured to: identify a node from a plurality of nodes as a sync master node; designate each of the remaining nodes as a sync slave node; designate the first message from the sync master node as a sync message; assign the lowest number, among all the message IDs in the network system, to the message ID of the sync message; determine a sync message target receiving time on a sync slave node; and trigger an interrupt to the processor responsive to receiving the sync message on a sync slave node in the controller area network to perform time adjustment on the sync slave node. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]    The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The forgoing and other features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which: 
           [0008]      FIG. 1  depicts a block diagram of a conventional (unsynchronized) CAN communication network; 
           [0009]      FIG. 2  depicts a diagram of a conventional CAN where overwritten and absent messages occur according to one embodiment; 
           [0010]      FIG. 3  depicts a block diagram with a CAN node synchronization function according to one embodiment; 
           [0011]      FIG. 4  depicts a diagram of message bursts in a synchronized CAN according to one embodiment; 
           [0012]      FIG. 5  depicts a timing diagram of CAN task periodic cycles, CAN task transmission and receiving procedures on the sync master and sync slave nodes, and message bursts on CAN bus according to one embodiment; 
           [0013]      FIG. 6  depicts a flow diagram of a method for CAN node synchronization according to one embodiment; 
           [0014]      FIG. 7  depicts a diagram of CAN task cycle time adjustment in a synchronized CAN according to one embodiment; and 
           [0015]      FIG. 8  depicts an aircraft having a CAN node synchronization application according to one embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0016]      FIG. 1  is a logical block diagram of a conventional (unsynchronized) CAN  100 , from the microcontroller application perspective, although physically the CAN controller may be part of the microcontroller. For the sake of simplicity, only two nodes  102  and  104  are depicted. It should be appreciated that CAN networks may include more than two nodes. 
         [0017]    CAN is a serial bus standard for connecting Electronic Control Units [ECUs] also known as communication nodes (or simply “nodes”). From a high level, a node may include a communication layer  116  and an application layer  114 , which separate, for each node in conventional (unsynchronized) CAN  100 , a microcontroller  108  and a CAN controller/transceiver  112  (hereafter “CAN controller  112 ”) via an application interface  110 . Communication layer  116  may be configured to provide CAN protocol services. Application layer  114  may be configured to supply/consume data to/from communication layer  116 . Application interface  110  may facilitate data transfer between a microcontroller  108  and a CAN controller  112 . 
         [0018]    A CAN node (e.g., CAN node  102 ) includes a microcontroller  108 , an application interface  110 , and a CAN controller  112 . Microcontroller  108  may include a CAN application task  118 . Application interface  110  may include one or more CAN receiving message boxes (or buffers)  122 , and one or more CAN transmission message boxes (or buffers)  120 . For the sake of brevity, message box is used for the illustration. 
         [0019]    Microcontroller  108  may be a central processing unit, microprocessor, or host processor. Microcontroller  108  may be configured to decide what the received messages mean and what messages it wants to transmit. Other devices on an aircraft, including sensors, actuators and control devices can be connected to microcontroller  108 . Microcontroller  108  may include one or more processors (not shown). Microcontroller  108  may be a hardware device for executing hardware instructions or software. 
         [0020]    For the sake of brevity, in some embodiments, transmission or message transmission, transmitting or message transmitting, and transmit are abbreviated as Tx, and receiving or message receiving, and receive are abbreviated as Rx. A conventional (unsynchronized) CAN  100  may include individual nodes  102  and  104 , connected by a CAN bus  106 . Each node in a conventional CAN  100  can include a microcontroller, a CAN controller, and an application interface (as shown in node  102 ). For Rx, CAN controller  112  stores the received serial bits from CAN bus  106  until an entire message is available. Then CAN controller  112  may check the message integrity, and put the message body in a Rx message box  122  if the message integrity check passes. A CAN application task (e.g., CAN application task  118 ) running on microcontroller  108  may pick up a message body from a Rx message box  122 , unpack the message body and make parameters from the received message available to the consumer applications running on the microcontroller  108 . For Tx, the CAN application task  118  may pack the parameters to be transmitted into a CAN message body and put the message body in a CAN Tx message boxes  120 . CAN controller  112  may pick up a message body from a Tx message box, add the message header and integrity check CRC to form a CAN message, and transmit the message on CAN bus  106  when the bus is free. 
         [0021]    CAN application task  118  running on microcontroller  108  is commonly a periodic task, and performs packing procedure for Tx and unpacking procedure for Rx, among the other possible procedures, once every CAN task cycle. CAN application task  118  packs a set of parameters into a CAN message body and puts the message body in a CAN Tx message box  120 . CAN application task  118  performs this packing procedure continuously until all the messages to be transmitted in a particular cycle are formed and put in the CAN Tx message boxes  120 , while CAN controller  112  is picking up a message from a filled CAN Tx message box and transmitting the message on CAN bus  106 . The CAN application task also picks up a message from a CAN Rx message box  122  and unpacks the message to a set of parameters. The CAN application task performs this unpacking procedure continuously until all the messages in Rx message boxes  122  are unpacked and parameters unpacked from the messages are available to the consumer applications on microcontroller  108 . 
         [0022]    CAN application task  118  running on microcontroller  108  can produce messages much faster than CAN controller  112  can transmit messages on CAN bus  106 . As a result, by the time the CAN task is done packing and putting all the messages in CAN Tx message boxes  120 , the CAN controller has only transmitted a few messages while the majority of the messages may be still waiting in CAN Tx message boxes  120 . Due to the way the messages are produced and transmitted, the CAN messages from a node appear to be a burst of messages (a group of messages back to back with little time gap in between, described hereafter as a “message burst”) on CAN bus  106 . This optimizes the CAN bus bandwidth utilization, and allows CAN application task  118  to perform other procedures after packing procedure, such as the unpacking procedure for Rx messages, while CAN controller/transceiver  112  on the same node is still transmitting. 
         [0023]    The periodic CAN application tasks in the nodes on a CAN bus can have the same task cycle time by design, and each CAN node transmits a group of messages (message burst) on the bus and receives certain messages from the other nodes once every its CAN task cycle. Tx messages are produced and Rx messages are consumed by the periodic CAN application tasks. However, since the CAN protocol does not provide accurate global time service and each node has its own clock, the CAN task cycles on the CAN nodes are not synchronized to each other, which makes the timing of CAN task cycles with the message pack/unpack procedures, and consequently the message bursts from the nodes on CAN bus, drift away from each other over time. This can cause overwritten and absent messages. 
         [0024]      FIG. 2  depicts a timing diagram of a conventional (unsynchronized) CAN to show overwritten and absent messages, according to one embodiment. For the sake of simplicity and brevity, the figure focuses on the CAN Tx on node  102  and the CAN Rx on node  104 . Sequence  128  is an example of how CAN timing jitter and lack of synchronization may cause message  124  in message burst  134  and message  124  in message burst  136  from the transmitting node to be overwritten before Rx node  104  is able to unpack message  124  from message burst  134 . Sequence  130  is an example of how CAN timing jitter and lack of synchronization may cause an absent message where none of message  124  in message burst  136  and message  124  in message burst  138  from the transmitting node is in a Rx message box. When CAN Rx procedure  126  unpacks the received messages, it finds out that Rx node  104  receives no new message for message  124 . 
         [0025]    It may be advantageous to provide a CAN node synchronization function configured to periodically transmit a synchronization message from a node, whereby all the other CAN nodes synchronize their message bursts with the sync message in such a way that message bursts from all the nodes on the CAN bus are evenly time spaced to enable application-level node-to-node deterministic data communication. 
         [0026]      FIG. 3  depicts a CAN configured with a CAN node synchronization function  301  (the CAN and synchronization function collectively referred to hereafter as “system  300 ”), according to one embodiment. System  300  may include a plurality of nodes including, for example, nodes  302  and  304 . It is appreciated that system  300  may include more than two nodes. 
         [0027]    A CAN node includes a communication layer  316  and an application layer  314 , which separate, for each node in system  300 , a microcontroller  308  and a CAN controller/transceiver  312  via an application interface  310 . Communication layer  316  may be configured to provide CAN protocol services. Application layer  314  supplies/consumes data to/from communication layer  316 . Application interface  310  may facilitate data transfer between microcontroller  308  and CAN transceiver  312 . A CAN node (e.g., sync master node  302 ) includes a microcontroller  308 , an application interface  310 , and a CAN controller/transceiver  312 . Microcontroller  308  may include a CAN application task  318 . Application interface  310  may include one or more CAN Rx message boxes  322 , and one or more Tx message boxes  320 . Synchronization function  301  may be configured on each node in system  300 . 
         [0028]    According to some embodiments, system  300  may be configured to select a node in the network via the microcontroller (e.g., microcontroller  308 ) to serve as the synchronization master node. In the present example, network  300  has selected node  302  as the sync master node (synchronization master node). Sync master node  302 , periodically sends a CAN sync message (not shown) e.g., once every CAN task cycle to each of the other CAN nodes. 
         [0029]    Each of the other CAN nodes on CAN bus  306  may be configured as a sync slave node (synchronization slave node). The sync slave nodes (e.g., sync slave node  304 ) may also be configured with a CAN node synchronization function  301 . Accordingly, each sync slave node may adjust its CAN task cycle time based on the point of time the sync message is received to move the start of its CAN task cycle with the Tx/Rx packing/unpacking procedures and consequently to move the message burst from the sync slave node so that the message bursts are evenly time-spaced on CAN bus  306 . System  300  may configure CAN nodes using synchronization function  301  to render all the CAN nodes on CAN bus  306  to be contention free to enable application-level node-to-node deterministic data communication, e.g., from CAN applications running on microcontroller  308  on a node (e.g., sync master node  302 ) to the CAN applications running on microcontroller (not shown) on another node (e.g., sync slave node  304 ). 
         [0030]    In some embodiments, the packing and unpacking procedures running on microcontroller  308  are all in one CAN application task  318 . In CAN application task  318 , the message packing procedure for Tx may run before the message unpacking procedure for Rx. 
         [0031]    Referring now to  FIG. 4 , a diagram of message bursts  402  and  404  in CAN node synchronization system  300  is depicted, according to one embodiment. For the sake of brevity, only two nodes (sync master node  302  and sync slave node  304 ) are shown, although system  300  may include multiple sync slave nodes  304 . To produce even time spacing between message bursts on CAN bus  306 , system  300  may configure one node to be the sync master node (shown in  FIG. 4 , for example, as sync master node  302 ), and configure the remaining node(s) in the network to be the sync slave node(s) (shown in  FIG. 4 , for example, as sync slave node  304 ). 
         [0032]    For optimal operation, the point of time of transmitting a sync message  408  from sync master node  302 , and consequently the point of time of receiving sync message  408  on sync slave node  304 , may be made as accurate as possible. Therefore, sync message  408  may be the first message of its respective message burst  402  sent out from sync master node  302  to avoid the scenario that the message(s) queued before the sync message from the sync master node may need retransmission due to CAN bus contention which makes the sync message transmission start/end time inaccurate on CAN bus  306 . Secondly, microcontroller  308  may assign sync message  408  with the lowest message ID among the messages transmitted from all the nodes on CAN bus  306  so that sync message  408  may have the highest priority on CAN bus  306  to always win the bus in case of bus transmission contention from the other nodes (e.g., sync slave node  304 , etc.). Thirdly, an interrupt may be triggered on microcontroller  308  when the sync message is received and ready in a Rx message box  322  on sync slave node  304 , and the time adjustment may be performed by microcontroller  308  on sync slave node  304  immediately, e.g., in the context of interrupt service routine in  301 . A microcontroller in a CAN node can be configured to trigger interrupts at receiving one or more messages among all the Rx messages. In this invention, microcontroller  308  may be configured to trigger an interrupt at receiving the sync message on the sync slave node. 
         [0033]    In  FIG. 4 , T SMT  represents a message burst transmission time duration from sync master node  302  and T SST  represents a message burst transmission time from sync slave node  304  in a two node CAN. T 1  represents the spacing time between the end of a message burst from sync master node  302  and the start of the following message burst from sync slave node  304 . T 2  represents the spacing time between the end of a message burst from sync slave node  304  and the start of the following message burst from sync master node  302 . According to some embodiments, system  300  may dynamically adjust the start of message bursts  404  from sync slave node  304  once per CAN application task cycle to make the message burst cycle on sync slave node  304  synchronize with that of sync master node  302  in such a way that the values of T 1  and T 2  stay equal within a predetermined threshold of error. A predetermined threshold of error may be, for example, 50 microseconds. 
         [0034]      FIG. 5  depicts a two node CAN timing diagram of CAN task periodic cycles on the sync master and sync slave nodes, CAN task procedures of packing for Tx and unpacking for Rx and message bursts on a CAN bus according to one embodiment. Referring now to  FIG. 5 , Tx procedure  502  and Rx procedure  504  are depicted next to each other. Tx procedure  502  is followed by Rx procedure  504  on both sync master node  302  and sync slave nodes  304 . Tx procedure  502  and Rx procedure  504  may be configured by microcontroller  308  as the early procedures among all the possible procedures in the CAN task in system  300 . In some aspects, making CAN tasks Tx procedure  502  and Rx procedure  504  the early procedures in CAN task on sync master node  302  and sync slave nodes  304  may minimize jitters that may otherwise be caused by the procedures prior to the Tx/Rx procedures. 
         [0035]    As shown in  FIG. 5 , sync message  408  may be the first message in the periodic message burst  402  from sync master node  302 . The start of the message burst on CAN bus  306  from either sync master node  302  or sync slave node  304  is tied to the start of a Tx procedure  502  in CAN task by a small amount of time, from packing of the first message by microcontroller  308  to transmitting the message by CAN controller/transceiver  312 . Thus, microcontroller  308  may adjust the start of a CAN task cycle  506  on the sync slave node to move the start of the message burst from the sync slave node. Since Tx procedures  502  in the CAN task for both sync master node  302  and sync slave node  304  only take a fraction of the node message burst period, there is enough time to finish Rx procedure  504  to unpack all the newly Rx messages before the next message burst from another node starts, when equal time-spaced message bursts are achieved on CAN bus  306 . It is critical for Rx procedures  504  to finish on a node before the message burst from another node starts. Otherwise, a race condition between the Rx procedure on a node and a message transmission from another node may cause an overwritten message if transmission from another node wins the race or an absent message if the Rx procedure on the node wins the race, as illustrated in sequences  128  and  130  in  FIG. 2 . 
         [0036]      FIG. 6  is a flow diagram of a method for CAN node synchronization, according to one embodiment. Referring now to  FIG. 6 , system  300  may identify a node as a sync master node  302 , as shown in block  602 . 
         [0037]    As shown in block  604 , system  300  may designate each of the remaining nodes as a sync slave node  304 . 
         [0038]    As shown in block  606 , microcontroller  308  may designate the first message from sync master node  302  as a sync message  408 , and assign a message ID to the sync message that is the lowest message ID from a plurality of messages in all the message bursts  402  and  404 , as shown in block  608 . 
         [0039]    As shown in block  610 , microcontroller  308  may determine an optimized spacing time duration T spacing  between neighbor message bursts  402  and  404  and the sync message target receiving time T target  relative to the start of the current CAN task cycle time  506  on a sync slave node. As shown in  FIG. 5 , the following equation holds for a two node CAN: 
         [0000]        T   cycle   =T   sst   +T   2   +T   smt   +T   1 ;  (1)
 
         [0000]    where T cycle  is a transmission cycle duration equal and tied to the predetermined CAN task cycle time, T smt  is the sync master message burst duration, and T sst  is the sync slave message burst duration. According to some embodiments, a CAN analyzer and an oscilloscope may provide measurements for the sync master message burst duration (T smt ) and the sync slave message burst duration (T sst ). T 1  represents the spacing time between the end of a message burst from sync master node  302  and the start of the following message burst from sync slave node  304 . T 2  represents the spacing time between the end of a message burst from sync slave node  304  and the start of the following message burst from sync master node  302 . When T 1  is about equal to T 2 , the (message burst from) sync master node  302  and the (message burst from) sync slave node  304  are optimally synchronized. Thus, replace T 1  and T 2  with T spacing  in equation (1), T spacing  for a two node CAN can be derived by: 
         [0000]        T   spacing =( T   cycle −( T   smt   +T   sst ))/2;  (2)
 
         [0000]    In this invention, the sync message receiving time is defined as the sync message receiving time relative to CAN task cycle start time  506  on a sync slave node  304 , which is T sst +T 2 , shown in  FIG. 5 . When T 1 =T 2 =T spacing , the optimized sync message receiving time is achieved. According to some embodiments, the sync message target receiving time is defined as the optimal sync message receiving time relative to the start of CAN task cycle time  506  on a sync slave node  304 , and is denoted as T target  in this invention. Therefore, T target  on the slave node for a two node CAN may be derived by: 
         [0000]        T   target   =T   sst   +T   spacing .  (3)
 
         [0000]    Accordingly, system  300  may be configured with T cycle  as a predefined CAN task cycle time by design, T sst  and T smt , as predetermined known time measurements, and T spacing  and T target  as derived values from the predefined value and the known measurements. 
         [0040]    As shown in block  610 , synchronization function  301  can be configured to trigger an interrupt to microcontroller  308  on sync slave node  304  upon receiving sync message  408  on sync slave node  304 . Accordingly, synchronization function  301  may use the interrupt service routine to get the sync message receiving time (the time elapse from the start of the current CAN task cycle  506  to the interrupt occurrence) and compare the sync message receiving time to the sync message target receiving time on the sync slave node, and determine, based on the comparison, whether the sync message receiving time on the sync slave node occurs before or after the sync message target receiving time, and perform the time adjustment. 
         [0041]    For example, if the sync message receiving time on the sync slave node is less than its sync message target receiving time, then the sync message receiving occurs before its target receiving time on the sync slave node, so synchronization function  301  on the sync slave node may decrease its current CAN task cycle time by a predefined time adjustment to make the CAN task&#39;s next cycle start time  506  occur earlier and consequently move the sync message receiving time on the sync slave node closer to its sync message target receiving time in the CAN task&#39;s next cycle. If the sync message receiving time on the sync slave node is greater than its sync message target receiving time, then the sync message receiving occurs after its target receiving time on the sync slave node, so synchronization function  301  on the sync slave node may increase its current CAN task cycle time by a predefined time adjustment to make the CAN task&#39;s next cycle start time  506  occur later and consequently move the sync message receiving time on the sync slave node closer to the sync message target receiving time in the CAN task&#39;s next cycle. 
         [0042]      FIG. 7  depicts a two node CAN timing diagram of CAN task cycle time adjustment on the sync slave node for CAN node synchronization system  300 , according to one embodiment. Over time, CAN task cycle start time  506  on the sync slave node  304  may be adjusted by decreasing the CAN task cycle time with a predefined time adjustment each cycle. For example, the microcontroller may move the receiving time of sync message  408  relative to the start of the CAN task cycle time  506  on sync slave node  304  closer to sync message target receiving time  702  so that actual sync message receiving time  408  eventually converges with sync message target receiving time  702  on sync slave node  304 . When sync message receiving time  408  on the sync slave node moves close to sync message target receiving time  702 , the message bursts from sync slave node  304  is moving to the middle between its two neighbor sync master message bursts. The message bursts on CAN bus  306  are eventually evenly time spaced when sync message receiving time  408  and sync message target receiving time  702  converge. 
         [0043]    For an N node CAN network, one node may be configured as the sync master node, and the remaining nodes may be configured as sync slave node 1, sync slave node 2, . . . , sync slave node N−2, and sync slave node N−1. The order of message bursts on the CAN bus may be assigned as message bursts from the sync master node, sync slave node 1, sync slave node 2, . . . , sync slave node N−2, and sync slave node N−1. The optimal neighbor message bursts spacing time Tspacing may be derived by: 
         [0000]        T   spacing =( T   cycle −( T   smt   +T   sst1   +T   sst2   + . . . +T   sstN−2   +T   sstN−1 ))/ N;   (4)
 
         [0000]    where T cycle  is a transmission cycle duration equal and tied to the predetermined CAN task cycle time, T smt  is the sync master node message burst duration, T sst1  is the sync slave node 1 message burst duration, T sst2  is the sync slave node 2 message burst duration, T sstN−2  is the sync slave node N−2 message burst duration, and T sstN−1  is the sync slave node N−1 message burst duration. According to some embodiments, a CAN analyzer and an oscilloscope may provide measurements for the sync master message burst duration (T smt ) and all the sync slave message burst durations (T sst1 ), (T sst2 ), (T sstN−2 ), . . . , and (T sstN−1 ), etc. The maximum message burst duration from a node may be taken as its measured burst duration. This may accommodate CAN nodes that transmit messages of different periods and even aperiodic messages. Thus, a measured burst duration for a node may be considered as the maximum CAN bus bandwidth allocation for the node, and T spacing  may be considered as the optimal spacing time between the CAN bus bandwidth allocations for any neighbor message bursts. 
         [0044]    In general, T target  on sync slave node J (J may take an integer value from 1 to N−1) T target-J  may be derived by 
         [0000]        T   target-J =( T   sstJ   +T   sstJ+1   + . . . +T   sstN−2   +T   sstN−1 )+( N−J )* T   spacing .  (5)
 
         [0000]    For instance, for an N node CAN network, T target  on sync slave node 1 may be derived and set to: 
         [0000]      (T sst1 +T sst2 + . . . +T sstN−2 +T sstN−1 )+(N−1)*T spacing ;
 
         [0000]    T target  on sync slave node 2 may be derived and set to 
         [0000]      (T sst2 +T sst3  . . . +T sstN−2 +T sstN−1 )+(N−2)*T spacing ;
 
         [0000]    T target  on sync slave node N−2 may be derived and set to 
         [0000]      (T sstN−2 +T sstN−1 )+2*T spacing ; and 
         [0000]    T target  on sync slave node N−1 may be derived and set to 
         [0000]      T sstN−1 +T spacing . 
         [0000]    For another instance, for a three node CAN network, T spacing  may be set to 
         [0000]      (T cycle −(T smt +T sst1 +T sst2 ))/3;
 
         [0000]    T target  on sync slave node 1 may be set to 
         [0000]      ((T sst1 +T sst2 )+2*T spacing ); and 
         [0000]    T target  on sync slave node 2 may be set to 
         [0000]      (T sst2 +T spacing ). 
         [0045]    The dynamic time adjustment process may occur once every CAN task cycle. According to some embodiments, system  300  may synchronize the sync message receiving time with the sync message target receiving time on a sync slave node (swinging back and forth around the target time by a very small time range). In some aspects, the adjustment time may be a small number, e.g., 1/100 of a CAN task cycle time, to synchronize the sync slave node with the sync master node in less than 100 times CAN cycle time duration (e.g., for a 5 millisecond CAN task cycle, the time adjustment may be set to 50 microseconds, so that it takes less than 500 milliseconds, or half second, to synchronize the sync message receiving time with the sync message target receiving time on a sync slave node). 
         [0046]      FIG. 8  depicts an aircraft  800  having a CAN node synchronization system  300 , according to one embodiment. Aircraft  800  may include a plurality of nodes, including, for example, sync master node  302 , and a plurality of sync slave nodes  304  and  802 , etc. 
         [0047]    The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems and methods according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions. 
         [0048]    The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.