High speed embedded protocol for distributed control systems

Abstract

A control network communication arrangement includes a second protocol embedded in a first protocol in such a way that modules supporting the second protocol are aware of and utilize the first protocol, while modules supporting only the first protocol are unaware of the second protocol. Operation of modules using the second protocol does not interfere with operation of modules not configured to use or understand the second protocol. In one approach, messages sent using the second protocol are treated as messages sent using the first protocol, but without messages that must be understood or require a specific response. In another approach, modules using the second protocol can be configured to send messages within CAN message frames without being CAN compliant.

Description

[0001] This application is a divisional application of the following application: Application date: May 26, 2015; Application number: 201580028277.8; Invention title: "High-speed embedded protocol for distributed control system".

[0002] Related applications

[0003] This application is a continuation of U.S. Application No. 14 / 287,154, filed May 26, 2014, which in turn is a partial continuation of U.S. Application No. 13 / 965,342, filed August 13, 2013, which in turn is a partial continuation of U.S. Patent Application No. 13 / 833,238, filed March 15, 2013. The contents of these applications are restated herein in their entirety by reference. Technical Field

[0004] This invention relates generally to electronic communications, and more specifically to high-speed protocols for controlling networks. Background Technology

[0005] Electronic devices typically communicate with each other in various ways based on the requirements of a given environment. One such environment is that of a control system. Unlike simple communication systems that only allow communication between devices on the system, control system communication aims to explicitly control modules connected to the system for communication. Such systems then allow other applications to run on these modules. In distributed embedded control systems, these applications can work collaboratively.

[0006] To provide this kind of group control, most distributed embedded control systems are built around communication protocol standards, such as CAN (ISO 11898), SERCOS, FlexRay, EtherCAT, and sometimes even Ethernet. Higher-level protocols are embedded on top of the communication standard to provide rules, timing rules, sequence rules, etc., for data exchange between participating applications on the electronic control units involved in the control network, facilitating communication between the distributed applications exchanging information. CANopen, DeviceNet, SDS, J1939, and NMEA 2000 are just a few examples of protocols overlaid on the CAN standard. Even meta-protocols such as CanKingdom are used, through which higher-level protocols can be built and optimized for specific distributed embedded control systems.

[0007] Each protocol standard has its own strengths and weaknesses. Ideal communication offers unlimited bandwidth, zero latency, and complete data integrity. Available communication schemes fall far short of this ideal, necessitating compromises. For example, Ethernet offers high bandwidth, but its poor handling of message collisions results in poor timeliness. CAN boasts efficient collision resolution but suffers from low bandwidth and lacks synchronization support. SERCOS is fast, but all nodes must support the communication requirements of the most demanding nodes in the system. Consequently, a major challenge in designing distributed embedded control systems is selecting a basic communication system suitable for the needs of a given system. Another complexity arises because different parts of the system often have different requirements. Some parts may involve advanced feedback loops requiring accurate time synchronization and low latency, while others may not be particularly time-critical, instead relying on correct event sequences. In another example, a system might work well with a low-bandwidth communication protocol in runtime but would require high bandwidth for a refresh module in maintenance mode. Furthermore, the industry demands numerous development and analysis tools and a number of engineers proficient in choosing communication protocols to discover the right compromises. To apply a given technology in a way that leverages the good properties of a protocol while minimizing its shortcomings, it typically requires extensive practical experience in designing and maintaining distributed embedded control systems, based on the chosen protocol and its associated tools.

[0008] In the example of the CAN system, the CANFD protocol was developed to address the data bandwidth limitations of the CAN protocol. However, this system is not backward compatible with previous CAN-based modules. Consequently, modules using the CANFD protocol cannot be installed in control networks with CAN-based modules and cannot communicate with those modules. Another drawback is that the CANFD protocol relies on modules to find a given set point in time, requiring modules with highly accurate clocks and processors. Specifically, CAN-FD requires switching from the first bit rate to the second bit rate relative to an edge, in combination with the sampling point location. This solution requires a stable clock over the time from the edge to the common location of the sampling point as defined in the first bit rate definition. Obtaining the precise definition of the sampling point limits the possible clock frequencies that can be used to run the CAN-FD controller. Furthermore, although the speed is improved compared to previous CAN-based systems, the maximum message length is still limited to 64 bytes. Such a system lacks flexibility for system designers.

[0009] Furthermore, CANFD may present certain implementation challenges for current users of CAN-based control systems. In one example, the automotive industry uses CAN-based modules to communicate between various components in a vehicle. Given the nature of the automotive business, simply replacing a module in a vehicle's system can be extremely expensive. Considering the challenges of integrating CANFD modules with CAN modules, introducing a CANFD module would force an automaker to either replace every module in a given vehicle with CANFD (incurring many times the cost of designing, building, and testing each new module) or split the vehicle's communication bus into two: one running CAN and the other running CANFD. Therefore, a technology is needed that allows for the gradual introduction of CANFD modules into previously established CAN-based systems over time, as is the case in the automotive industry, to reduce what might otherwise be the entry barriers to CANFD modules. Summary of the Invention

[0010] Generally, according to these embodiments, the second protocol is embedded in the first protocol in such a way that modules supporting the second protocol can be aware of and use the first protocol, while modules supporting only the first protocol can remain unaware of the second protocol. The operation of modules using the second protocol does not interfere with the operation of modules not configured to use or understand the second protocol. According to one method, a message sent using the second protocol will be treated as a message sent using the first protocol, but without the required message for understanding, or as requiring a specific response. In another method, a module using the second protocol can be configured to send a message during the transmission of a first protocol message by another module, the second protocol message being triggered by a desired aspect of a message sent according to the first protocol.

[0011] In a specific example, the first protocol could be the CAN protocol, and the second protocol could be a protocol that embeds bits into certain parts of the CAN protocol. For example, a bit in a CAN protocol typically comprises multiple bit quanta, and the CAN protocol operates by finding a specific signal level at a specific part, or the bit quanta of a single bit. Therefore, according to one approach, the second protocol could include sending additional information within the CAN message data packet using the bit quanta of the Prop-Seg bits in addition to the defined bit quanta.

[0012] The second protocol information is embedded in such a way that the falling edge of a bit in the second protocol will not interfere with the normal operation of a module that only understands the first protocol or the CAN protocol. This can be accomplished, for example, by using both the first and second protocols together as part of a message data packet to perform module synchronization. Using this method allows modules using the second protocol to control the second protocol message using the message transmission control of the first protocol message that is transmitting the second protocol message, thereby increasing the amount of data that can be transmitted using a single second protocol message.

[0013] These principles are scalable so that multiple modules on a single general-purpose control network can use a variety of different types of embedded protocols within the first protocol. Furthermore, modules using the second protocol can be installed in control networks that use older modules configured to use only the first protocol, thus providing considerable flexibility in upgrading parts of existing control networks.

[0014] Such advantages can be envisioned in implementation examples within the automotive industry environment. Here, the new module can be configured to operate using the CAN standard, such as the second protocol described herein, as well as the CANFD protocol. Such a module can be introduced into an otherwise stable CAN-based communication bus and, by using the second protocol, improve communication speed. Over time, after all older CAN modules have been replaced, the module can communicate using the CANFD protocol to provide a consistent, high-speed communication environment. Thus, the adoption of modules using the CANFD protocol can be implemented immediately without the associated concerns of merging CANFD modules into a communication bus with older CAN modules.

[0015] These and other advantages become clearer after a thorough reading and study of the following detailed description. Attached Figure Description

[0016] Figure 1 A block diagram including example control networks configured according to various embodiments of the present invention;

[0017] Figure 2 A diagram including CAN messages;

[0018] Figure 3 Includes a schematic diagram of an example CAN time quantum;

[0019] Figure 4 Includes a schematic diagram of example CAN bits;

[0020] Figure 5 A schematic diagram illustrating an example of embedding a second protocol message in a portion of a first protocol message (here, the Prop_Seg portion of a CAN message) according to various embodiments of the present invention;

[0021] Figure 6 A schematic diagram of another example of embedding a second protocol message in a portion of a first protocol message based on CAN, including configurations according to various embodiments of the present invention;

[0022] Figure 7 A schematic diagram of an example of embedding a second protocol message in a portion of a first protocol message based on CAN, including configurations according to various embodiments of the present invention, wherein the Sync_Seg portion is set to be dominant;

[0023] Figure 8 A schematic diagram illustrating how a module configured according to various embodiments of the present invention, which operates using a second protocol message within a portion of a first protocol message based on CAN, can interpret a received message with signal distortion.

[0024] Figure 9 Including the second module configured according to various embodiments of the present invention, which operates using a second protocol message within a first CAN-based protocol message, how can it interpret signals with different distortions? Figure 8 The received message;

[0025] Figure 10 A block diagram including example control networks configured according to various embodiments of the present invention;

[0026] Figure 11 This includes a graphical comparison of example messages sent from one module and how those messages are perceived by a second module, configured according to various embodiments of the present invention.

[0027] Figure 12 This includes a graphical comparison of an example message sent from one module and a second module's response to receiving the example message using a second protocol, configured according to various embodiments of the present invention.

[0028] Figure 13 This includes a graphical comparison of an example message sent from one module and a second module's response to receiving the example message using a second protocol, configured according to various embodiments of the present invention.

[0029] Figure 14 A block diagram of an example control network with a star topology configured according to various embodiments of the present invention;

[0030] Figure 15 A block diagram including example communication devices configured according to various embodiments of the present invention;

[0031] Figure 16 Illustrations of multiple example messages sent according to various embodiments of the present invention;

[0032] Figure 17 The diagram includes CAN bits configured and extended CAN bits according to various embodiments of the present invention, with some portions highlighted to show where CAN-EF can be implemented;

[0033] Figure 18 The timeline includes the communication between two modules, A and B, showing the propagation delay;

[0034] Figure 19 Includes the timeline of synchronization pulses transmitted between the two CAN-EF modules A and B during CAN transmission;

[0035] Figure 20 This illustrates a CAN transmission with a dominant synchronization segment following a recessive bit;

[0036] Figure 21 It shows in Figure 20 Where can the CAN-EF embedding bit be sent within the CAN transmission?

[0037] Figure 22 The range of sampling points (SP) and synchronization jump width (SJW) for CAN transmission is shown.

[0038] Figure 23 The modified sampling point (SP) and synchronization jump width (SJW) ranges for CAN transmission according to various embodiments of the present invention are shown.

[0039] Figure 24 The transmission of a sequence of recessive bits configured according to various embodiments of the present invention is illustrated, wherein five of the six bits have synchronization edges;

[0040] Figure 25 The relationship between various CAN-EF parameters in the bit time (BT) configured according to various embodiments of the present invention is shown;

[0041] Figure 26 The possible states of communication between the two modules A and B after the arbitration sequence are shown;

[0042] Figure 27 The last CAN bit is inverted to force a synchronization edge after the recessive bit and the dominant bit, along with the worst-case bit stuffing.

[0043] Figure 28 An example CAN-EF frame format, embedded within CAN bits and extended CAN bits, is shown according to various embodiments of the present invention;

[0044] Figure 29 This shows where the CAN-EF embedding bit can be sent within a CAN transmission;

[0045] Figure 30 An example transmission using 80 CAN-EF bits (two CAN bytes) is shown, configured according to various embodiments of the present invention;

[0046] Figure 31 Transmission sequences according to various embodiments of the present invention are shown, wherein the transmitted CRC DELIM portion is forcibly filled with violations;

[0047] Figure 32 A two-bit cycle with an initial synchronization pulse is shown;

[0048] Figure 33 This illustrates the propagation delay between the transmitting and receiving devices;

[0049] Figure 34 It shows Figure 33 The synchronization uncertainty within the propagation delay shown;

[0050] Figure 35 The broadcast data overlay layer configured according to various embodiments of the present invention is shown;

[0051] Figure 36 The operation of the broadcast data overlay layer in a bidirectional protocol configured according to various embodiments of the present invention is illustrated.

[0052] Those skilled in the art will understand that the elements in the figures are shown concisely and clearly, and are not necessarily drawn to scale. For example, the size and / or relative positioning of certain elements in the figures may be enlarged relative to other elements to aid in understanding the various embodiments of the invention. Furthermore, common but well-understood elements that are useful or necessary in commercially viable embodiments are often not depicted to facilitate a less intrusive understanding of these embodiments. It will be further understood that certain actions and / or steps may be described or depicted in a particular sequence of occurrence, and those skilled in the art will understand that such specificity relative to the sequence is not practically necessary. It will also be understood that the terms and expressions used herein have the ordinary technical meaning given to such terms and expressions as set forth above by those skilled in the art, except where different specific meanings are otherwise set forth herein. Detailed Implementation

[0053] Now, referring to the diagram, specifically, referring to... Figure 1 Now, we will present many illustrative systems compatible with these principles. Figure 1The diagram illustrates a control network 1000 with various devices communicating via bus 1005; however, these principles can be applied to control networks with any of various topologies. A communication device 1010 can be considered as a module or node on the control network 1000 and includes a communication port 1012 configured to connect to the control network 1000 according to its topology. The communication device 1010 also includes a processing device 1014 operatively connected to the control network 1000 to control the reception and transmission of communications via the communication port 1012 through the control network 1000. Those skilled in the art will recognize and understand that such a processor may comprise a fixed-purpose hardwired platform, or may also comprise a partially or fully programmable platform. All these architectural options are known and understood in the industry and do not require further description.

[0054] According to one method, processing device 1014 is configured to, during the transmission of message data packets via control network 1000 according to a first protocol, use a second protocol to transmit a second message embedded within the message data packets. For example, processing device 1014 is further configured to perform synchronization with second communication devices 1020, 1030, 1040, 1050, and / or 1060 via control network 1000 based on at least a portion of the message data packets, for both the first and second protocols. In another method, processing device 1014 supports both the first and second protocols and uses both protocols when communicating with communication devices 1020 and 1050, which also support both protocols, while communication devices 1030, 1040, and 1060 only support the first protocol. In this example, any information in the message according to the second protocol will be interpreted as noise by communication devices 1030, 1040, and 1060, which only operate under the first protocol and as defined by the first protocol, and will be ignored.

[0055] In the context of CAN-based systems, refer to Figure 2-10 This describes an example implementation that embeds a second protocol within a first protocol message. The Controller Area Network (CAN) standard (International Organization for Standardization (ISO) 11898) is a commonly used protocol for distributed embedded control systems, although these general principles can be applied to other protocols.

[0056] In this implementation, a module supporting the CAN protocol ISO 11898 can coexist on the same bus with a module supporting the second protocol by forgoing the use of one or more features of CAN. Figure 2Some key features of CAN are illustrated. CAN is designed for bus topology and is compatible with two voltage levels: no voltage 101, representing the value "1", and voltage 102, representing the value "0". This arrangement implies that zero is dominant over 1; in other words, if the first transmitter transmits a 1 while the second transmitter simultaneously transmits a zero, only the zero can be detected. An idle bus can be viewed as a continuous stream of 1s. Message 103 begins with a zero bit, Start of Frame (SOF) 104, followed by an identifier 105 of 11 (standard) or 29 (extended) plus 2 protocol bits (31 bits in total), and a Remote Transfer Request (RTR) bit 106. The SOF and identifier message portions constitute the arbitration field 107, where bus collisions are resolved through bit-by-bit arbitration. During the remainder of message 108 up to the acknowledgment bit (ACK) 109, only one transmitter is on the bus because other transmitters are controlled and inactive in response to these initial message portions; specifically, after the arbitration portion of the message, ending with RTR, only one transmitter will transmit, while all other communication units will only receive bits according to the protocol. This remainder of message 108 begins with a control field 110 with two dominant bits and a four-bit data length code (DLC) 111, which indicates the length of the subsequent data field 112, which may contain no data (DLC = 0) or be up to eight bytes (DLC = 8). In other words, the data field 112 of a standard CAN message can be 0 bits to 64 bits long. Up to this point, the message is checked by a 15-bit CRC code placed in a sixteen-bit CRC field 113, where the last bit is a CRC delimiter 114. The ACK field 115 contains the ACK bit 109, followed by the recessive bit, the ACK delimiter 116. The remainder of message 103 is the End of Frame (EOF) field 117, which contains seven consecutive recessive bits. Three recessive bits, intermittent 118, must be passed before the bus is idle and no new messages arrive.

[0057] According to the CAN specification (ISO 11898-1), bits are composed of time quanta. (Reference) Figure 3 A single bit quantum in a standard CAN message is described as a time quantum 130, which is a fixed unit of time derived from the oscillator period 131 of the transmitter / receiver's clock. The time ticks 131 can optionally be derived from a separate oscillator or clock. A programmable prescaler with integer values ​​varying from at least 1 to 32 is used to define a time quantum as a given number of minimum time quantumes. Accordingly, starting with the minimum time quantum, the time quantum should have the following lengths:

[0058] Time quantum = mx Minimum time quantum

[0059] Where m is the value of the prescaler.

[0060] Therefore, in operation, such as Figure 4 Another example of CAN bit 132 shown consists of a single time quantum. The first time quantum is Sync_Seg 133, followed by Prop_Seg (propagation segment) 134, comprising one to at least eight time quantumes. The propagation segment is defined according to a time interval to ensure that the signal wave can propagate from the transmitter to the far end of the bus and back, which will also correspond to the amount of time required for the furthest module on the control network to receive the message and respond. Accordingly, the Prop_Seg length is set to allow the bit arbitration aspect of the CAN protocol to function. The final part of CAN bit 132 includes phase segments, Phase_Seg1 135 and Phase_Seg2 136. The phase segments are symmetrical, each having a length of one or at most eight time quantumes. The phase segments occupy the propagation slack between different nodes in the system. The CAN bit should then be programmable from 4 to at least 25 time quantumes.

[0061] Assume all clocks in the CAN system are asynchronous. When transmitting SOF 104, the clock of each module is synchronized with the falling edge 140, and each module counts the number of time quantum units specified by Prop_Seg and Phase_Seg1. For example, the internal clock of the module receiving the falling edge can determine the desired sampling point timing within the resolution of that internal clock; that is, by knowing the definition of the bits in the internal clock, the module can calculate the position of the sampling point relative to the internal clock. In CAN, this is typically implemented using time quantum units, where each time quantum is the number of local clock elements. The voltage of the signal is measured at sampling point 141. If the voltage is still present, the module determines that SOF has been detected and decodes the following voltage shift according to the CAN specification. If there is no voltage at sampling point 141, the falling edge is considered a technical fault and is ignored. This feature can be considered as a low-pass filter, filtering out interference on the bus, for example, due to radio wave reflections. Such features make CAN reliable and fault-tolerant in poor wiring installations.

[0062] Voltage edges can radiate high frequencies in some communication systems, leading to electromagnetic compatibility (EMC) problems. To mitigate these issues, CAN specifies non-return-to-zero (NRZ) decoding of bits; in other words, consecutive bits of the same value do not generate any edges. Instead, bits are decoded using a dead reckoning algorithm. The clock of a single module is resynchronized only on the falling edge of what is defined as the transition from the recessive (1) bit to the dominant (0) bit. CAN has a bit-stuffing rule that after a sequence of five consecutive bits of the same value, a stuffing bit of the opposite value should be inserted to ensure resynchronization. Thus, under normal circumstances, resynchronization will occur at least ten bits later. The CAN specification requires that the sampling point be held within a phase segment for at least 13 bits.

[0063] More detailed information about CAN can be found in ISO standard 1898 and in the paper "The Configuration of the CAN Bit Timing" presented by Florian Hartwig and Armin Bassemir (Robert Bosch GmbH, Abt. K8 / EIS) at the 6th International CAN Conference held in Turin, Italy from November 2nd to 4th. This paper was written by CAN in Automation (CiA) (Germany). These materials are included in full in this article as references.

[0064] Turning Figure 5 An example solution to the bandwidth problem is to modify the first protocol, here the CAN protocol, to embed a second high-speed protocol into certain parts of a standard CAN message. In such an approach, the processing device controlling the network module can be configured to control the second protocol to use a bit rate higher than that of the first protocol, for example, to control the second protocol to use a bit rate that is an integer multiple of that of the first protocol. Alternatively, the second protocol bit rate can also have a rate that is a non-integer multiple of that of the first protocol. For example, the first protocol can have a bit rate of 100 bits / second, while the second protocol can have a bit rate of any number between 400 bits / second and 6 Mbit / second. The bit rate will be (number of second protocol bits per first protocol bit) / ((propsegment time length) x utilization) bits / second. The rate of bits in the second protocol is limited only by the clock resolution in the second protocol control logic. The number of bits per time quantum can, for example, be 20 per 3 time quantum. In any case, the effect is that the processing device is configured to implement the second protocol by adding bits within a single bit quantum of the first protocol. In other words, a CAN message data packet can be defined by bits with multiple bit quanta, and the data of the CAN message data packet is defined by the signal level of a defined bit quanta at the bit, where the defined bit quanta is smaller than each bit quanta of the bit. For example, a standard CAN bit uses defined bit quanta, including the first bit quanta of the corresponding bit (which is the Sync_Seg bit), and the sample point bit quanta of the corresponding bit. This sample point is typically between the Phase_Seg1 and Phase_Seg2 portions of the bit, such as... Figure 4As shown. There are remaining, undefined bit quantum numbers that can be used in the second protocol. Thus, in one example, to embed the second protocol, the processing device is configured to send additional information within the CAN message packet using the bit quantum numbers of the Prop-Seg bits of the CAN message packet, in addition to the defined bit quantum numbers checked by the node using the standard CAN message protocol.

[0065] exist Figure 5 In the example, the second protocol message is embedded in the Prop_Seg of the CAN bit transmitted in the CAN message, after the arbitration field of the CAN message. The propagation segment is only useful in the arbitration portion of the CAN message exchange between nodes. If more than one module transmits simultaneously during the arbitration period, this can lead to fluctuating bit timing or bit timing identification problems caused by different modules communicating at approximately the same time, resulting in conflicts that must be resolved by arbitration and / or by bad clocks in one or more modules. After the arbitration period, only one module transmits, and the bit timing on the bus reflects the transmitter's oscillator. With this configuration, the second message can be embedded in the time quantum of the Prop_Seg of such a CAN bit without concern about being lost to collision noise on the control network. Furthermore, modules not configured to receive messages with the second protocol will not look for signal changes during the Prop_Seg of such a bit, so that signal changes in this portion of the message will not adversely affect such modules. Accordingly, the processing device is configured to implement the second protocol by adding bits within a single bit quantum of the first protocol, which is not measured according to the first protocol at a specific level.

[0066] More specifically, Figure 5An example CAN bit is shown with a propagation segment 205 and two phase segments 203 and 204, each of which is a time quantum. The bit begins with Sync_Seg 202, where any voltage shift 201 is performed at this time. The voltage levels during the bit time are depicted by the thick line 206. Modules supporting the second protocol will use Prop_Seg for the embedded high-speed bit stream by sampling the voltage value of each time quantum and decoding the value according to CAN rules, where a sensed voltage is decoded as zero and no voltage is decoded as 1. Modules supporting only the original CAN protocol will decode the falling edge 201 as an asynchronous or resynchronization edge and ignore subsequent voltage shifts. The voltage level at sampling point 207 is dominant, and the CAN module will correctly decode this bit as zero. The module supporting the second protocol will decode sampling points 210 to 217 as follows: 210 = 0; 211 = 1; 212 = 1; 213 = 1; 214 = 0; 215 = 0; 216 = 1; 217 = 0. Here, the module's processing device is configured to represent signals using the same voltage level for both the first and second protocols, although this is not mandatory. Indeed, instead, the processing device can be configured to implement the second protocol by adding bits within a single bit quantum of the first protocol that is not measured to a specific level according to the first protocol. Furthermore, although the width of the second protocol bit or sampling point shown is indicated to have the same width as the first protocol sampling point, other time lengths different from the width of the first protocol sampling point are also possible. The number of second protocol bits placed in the propagation segment is limited only by the physical layer performance and the clock resolution in the controller logic processing the second protocol.

[0067] Figure 6An example of embedding a second protocol message through the entire CAN message based on the first protocol is shown. Dashed line 300 shows the voltage level on the bus as interpreted by CAN as starting with an idle bus. Solid line 320 shows the voltage level of the second protocol embedded in a standard CAN message as described above. Falling edge 301 indicates Start of Frame (SOF) bit 303. The falling edge is detected in Sync_Seg 304 and acknowledged by the module supporting the original CAN protocol at sampling point 305. It ignores any additional falling edges, such as edge 322 after the initial edge 302. The module supporting the second protocol will read the bit sequence 0 111 0 0 1 0 embedded in the CAN bit 321. The first two CAN bits 306 and 307 after SOF have the value 1 1. Edge 308 at the beginning of bit 306 is a rising edge, thus not affecting CAN resynchronization. The embedded second protocol transmits 10001101 in this CAN bit 306, including the generation of falling edge 323. The CAN module will ignore this edge, as well as the subsequent edge 324, because it does not look for edges at these points and will no longer synchronize, as it sampled the dominant level at sampling point 305. The CAN module will correctly sample the recessive level at point 309, assuming the next bit 307 starts at point 310, and calculate the position of sampling point 311.

[0068] However, in this example, the second protocol will generate a falling edge 326 two-bit quantum from the hypothetical start 310 of bit 307. This will cause the CAN module to resynchronize and shift the sampling point by one bit quantum to 312 (because the Phase_Seg in this example is only one bit quantum long). The CAN module will still correctly sample a bit value of 1, but at a false position in the CAN message used by the transmission module supporting the second protocol. The next falling edge 327 in subsequent CAN bit 313 will shift the CAN sampling point by another time quantum and into the wrong bit. It may then incorrectly sample the dominant level generated by the second protocol, as indicated by 314.

[0069] To avoid this error, the processing device of the module operating according to the second protocol is configured to set the Sync_Seg bit quantum to dominant, for example, after the recessive sample in the first protocol. The disadvantage of this rule is that it introduces more falling edges in the CAN message compared to the original CAN protocol; however, any high-speed protocol will similarly generate additional falling edges. In one example of this approach, in the first protocol, padding bits are used to obtain a resynchronization edge at least every 10 bits. Using this new edge generator, resynchronization will occur on every recessive bit and will never occur after more than 6 bits. With such an arrangement, the example system is able to operate with clocks with a tolerance of less than 66%. A potential disadvantage of this approach is that the advantage can only be realized where all messages are sent using this additional edge in the synchronization segment, and this approach may not work if messages are sent according to the first protocol. This feature can also be used to move the sampling point outside the propagation segment in the first protocol. By having a first byte with only the recessive bit in the first protocol, eight edges can be used to move the sampling point outside the propagation segment by at least eight time quantum. This will not cover all cases, as the propagation segment may have more than eight time quantum units. In most cases, this should be sufficient, and other implementations can be programmed to cover any settings used in the first protocol.

[0070] Figure 7 It shows the relationship with Figure 6 The same message, but with the new rules of the second protocol applied. The expected rising edge 308 is now replaced by the rising edge 401 of the second protocol because Sync_Seg 402 is dominant. The second protocol may have already moved the rising edge to Phase_Seg1 all the way up to 403, and at 309, the CAN module will still sample correctly. Sync_Seg 404 will generate a falling edge 405 that will resynchronize the CAN module, which will sample correctly at sampling point 410. By using such a method, it is shown that a processing device operating a module of the second protocol can be configured to perform synchronization with a second communication device via a control network, for both the first and second protocols, based on the same portion of the message data packets including message data packets sent according to the CAN protocol.

[0071] Refer back Figure 2Section 108, from arbitration field 107 to acknowledgment bit 115, contains 86 CAN bits where a second protocol can be embedded. Using the embedded protocol implemented according to the example above, an additional 86 bytes can be added to an 8-byte CAN message. In one approach, the embedded protocol may include a 24-bit Cyclic Redundancy Check (CRC) sum. Furthermore, the last bit of these bits must be reserved for transmitting an error frame in the event of a faulty CRC sum. If the 24-bit CRC sum is deemed sufficient for 89 bytes of data from the embedded protocol, then the eight-byte CAN message can transmit 97 bytes of data, increasing the bandwidth of CAN communication by 12 times. According to another example method, the processing device is configured to use the CRC bits of the CAN message data packet as a quality control check for the CAN message data packet, and use a bit quantum other than the defined bit quantum for standard CAN messages for a quality control check for sending additional information within the CAN message data packet using the second protocol. Thus, in the case of implementing the second protocol, as described above... Figure 5In an example using the bit quantum of the Prop_Seg portion of bits not used by the original CAN protocol, the same unused or undefined bit quantum of the CRC bits of the standard CAN message can be used as error checking information for messages sent using the second protocol. In one such approach, a longer CRC field is chosen for the longer data of the embedded protocol, for example, a 21-bit CRC. This is more efficient for messages that should only be received by nodes using the second protocol. In one such example, the data field of the basic CAN message should contain only recessive bits, where the presence of CAN padding bits and CAN CRC bits is known a priori, and the total number of bits in the message is independent of the data in the message. The CRC of the second protocol is then placed as far away from the SOF in the CAN message as possible, such as the last two bits next to the end of the frame. In the event of a CRC mismatch, a CAN error flag can be sent in the bits before the EOF bit to trigger message rejection by every CAN node in the system. Implementing a rule where the Sync_Seg of each CAN bit has the opposite value of the corresponding bit value—that is, the Sync_Seg of recessive bits is dominant and vice versa—will create more synchronization flanking for the embedded protocol. Additional synchronization flanking will allow for a higher bit rate of the embedded protocol, which can also be used to improve CRC protection for the first protocol. The definition of the first protocol has certain drawbacks due to the calculation of the CRC in a combination of padding bits. The second protocol can address this concern by using a different definition of CRC calculation. By adding only one extra bit to the second protocol and setting this bit in the propagation segment to be the same as the value of the sampling point of the first protocol, two CRC calculations are performed in parallel, one according to the first protocol and the other using a second improved CRC, according to the second protocol. By including the second protocol CRC in the propagation segment of the first protocol CRC bit, both will be sent in parallel. Units supporting only the first protocol will not use the second protocol CRC information and will not detect any problems; however, all second protocol units will check both CRCs in parallel and generate an error frame if necessary, otherwise both are correct. In yet another approach, the first protocol message can be retransmitted entirely within the second protocol portion of the CRC bit as a further check for the accuracy of the received first protocol message.

[0072] In this example, 11 qubits are chosen to constitute a CAN bit. Eighteen qubits could be chosen to embed two bytes in each CAN bit. The bandwidth could then be increased by 24 times. The CAN specification states that bits should be programmable up to at least 25 qubits, thus allowing for further bandwidth increases, such as by using 35 or 67 qubits for a single bit. Limitations are imposed solely by the clock, transceiver, and the quality of the cables used in the system. One advantage of this configuration is that protocols such as CAN can be progressively enhanced as new module designs utilize more modern and advanced components, while remaining fully backward compatible with systems using older modules.

[0073] Starting from the framework described above, many modified methods can be used to meet the needs of various control network designs.

[0074] In one example, U.S. Patent No. 7,711,880, entitled "Schematizing of messages in distributed control and supervision system" and incorporated herein by reference, describes various ways to design a CAN system to avoid collisions, such as by combining message scheduling and CAN collision resolution mechanisms. The CanKingdom protocol describes how the protocol is established from protocol primitives. Any CAN system has a finite number of messages. Assuming the number of such messages is in the range of 128 to 256, the arbitration field can be limited to one byte. The RTR bit of the CAN protocol primitive is optional and can be omitted in this example. Furthermore, the two reserved bits in the control field do not contribute if a system-specific protocol has been created and legacy CAN modules are not involved. The DLC field can be modified, allowing 16 different lengths of the data field to be defined as needed.

[0075] If such a method is used in a given control network, then the arbitration field 107 of the CAN message on that network can be used by the embedded protocol. In this method, the processing device of the module operating the second protocol is configured to use full or partial collision avoidance for the first CAN-based protocol and embed at least a portion of the second message into the arbitration portion of the message packet. This will add an additional 12 or 32 embedded bytes to the CAN message as implemented in the example above, so that 109 or 129 data bytes can be included in a single CAN transmission.

[0076] In another example, the maximum bit rate of CAN communication is limited by the bus length. U.S. Patent No. 5,696,911, entitled "Arrangement foreliminating malfunction and / or permitting high-speed transmission in a serialbus connection, and transmitter and receiver units linked to the latter," and incorporated herein by reference, describes how a higher bit rate can be used when certain modules can be switched to silent mode and thus not fully participate in CAN error protection measures. By applying the embedded protocol described above to such a system, the bandwidth of the communication can be increased by another order of magnitude.

[0077] In another example, CAN can be used as a transport frame for other new protocols. Some higher-level CAN protocols are not backward compatible with CAN-FD and may not be able to integrate high-speed protocols into the standard. One such protocol is the known SAE J1939. Solutions to this problem involve specifying several specific CAN identifiers with a fixed CAN field for a single purpose: transport frames for new protocols. The first three bits of a J1939 frame are ignored by the receiver and used to form seven transmission priority levels (J1939 / 21, 5.2.1). Value 011 b (3) Reserved for control messages, with a value of 110 b Reserved for all other informational, proprietary, request, and ACK messages. Therefore, the value 001 can be used to specify the transmission of a new protocol. The subsequent CAN bits should all be 1 (recessive) to provide a well-defined frame, with all CAN bits including the CAN id, padding bits, RTR bits, control bits, HLP bits, CRC bits, etc., which are known a priori. Then, each CAN bit after 001 can be used to embed the new protocol. Alternatively, if a lower priority level is preferred, the first five CAN identifier bits should be 11101, followed by 1s for transmitting the new protocol. The proposed solution also provides maximum resynchronization opportunities for the embedded protocol through the previously suggested Sync_Seg modification. Regarding synchronization, a module that has lost arbitration will sample received bits at the wrong location because it will not perform hard synchronization on the falling wing of the winning module, such as in cases where it may have started its transmission before receiving the falling wing of the winning node's SOF. Then, some of the initial recessive bits in the CAN identifier can be used alone (i.e., without carrying any bits of the new protocol) to force the receiving nodes to resynchronize fully to obtain the correct position of their sampling points.

[0078] Furthermore, the second protocol can be implemented in any of a variety of ways. In the example above, the embedded protocol has NRZ bit encoding; however, it can be encoded in another way, such as Manchester or Miller encoding. Additional advantages can be achieved when the processing device is configured to implement the second protocol using a CAN-based encoding method, especially when the first protocol is CAN-based. In such cases, the system can be upgraded incrementally. Some higher-level CAN protocols use only a few CAN identifiers and extend the identifiers to one or two data bytes. CanKingdom is an example of such a protocol. It uses CANJStd. ID 0 for setup messages, and each node has a CAN ID for responding to messages. In such an approach, the setup time of the control network can be significantly reduced for modules supporting the embedded protocol, because all setup instructions to the module can be carried in one message, and all responses to the instructions are sent by the module in another message. More specifically, the module's processing device is configured to receive setup messages and derive from the setup messages information sufficient to configure the first protocol for communication via the bus, as well as information sufficient to configure the second protocol for communication via the bus. This same setup message is configured to allow a device configured to operate only according to the first protocol to configure itself in response to receiving the setup message. In one approach, a processing device operating a module of the second protocol can be configured to use the same software module to configure itself at setup times for both the first and second protocols. Almost no software changes are required, and mixing the new module with the legacy module will not cause any problems. The legacy module will receive one instruction per message (as it has so far), however, the new module will receive everything in a single message. Since the content is defined by CAN id 0 and the first two bytes, decoding will be identical in both cases.

[0079] Thus, additional efficiency can be achieved when the processing device is configured to implement the second protocol by sharing at least one of the following groups: error status message portion, initialization message portion, acknowledgment message portion, sampling portion, and any combination thereof with message data packets transmitted according to the first protocol. When both the first and second protocols use a CAN-based method, the processing device implementing the second module can be configured to implement the second protocol by sharing at least one of the following groups: frame start bit, arbitration field, error status bit, acknowledgment bit, frame end bit, and any combination thereof with message data packets transmitted according to the CAN protocol. Although the acknowledgment bit is transmitted by all modules, the second protocol may or may not use this message to configure a module for further communication with the acknowledgment module.

[0080] Omitting the bit padding arrangement of the CAN protocol allows for additional modifications to the bit encoding of the embedded protocol. The second protocol described above does not require bit padding because the longest time between resynchronization edges is five consecutive dominant CAN bits. A CRC sum is calculated after each CAN byte and placed in the next two CAN bits. If a CRC mismatch is detected, a CAN error frame is transmitted. In other methods, if the first protocol requires resynchronization every 10 bits, then the second protocol will need to be resynchronized after a time period equal to 10 second protocol bits. If resynchronization occurs in every synchronization segment, there can be up to 10 bits in the propagation segment without resynchronization, which would require each first protocol bit to be sampled as recessive to ensure that there is a recessive to dominant edge in each synchronization segment. If the number of second protocol bits exceeds this, resynchronization will be required, one example being to include a padding bit every five bits, or by fixing a pattern where every sixth bit is a padding bit with its polarity reversed to the value of the previous bit. Here, it can be assumed that the clock has a tolerance better than the 500 ppm described in the J1939 standard. This will make it possible to sample the secondary protocol bits using two first protocol bits. If the clock is poor, a mechanism can be implemented that will ensure resynchronization in the synchronization segment to define the start of the secondary protocol sequence. One such rule is that if there is a dominant first protocol bit, there will be a recessive-dominant pair as the start case; if there is a recessive first protocol bit, there will be a dominant-recessive pair as the start case before the secondary protocol bits in the propagation segment. This method will synchronize all receiver modules to sample the secondary protocol bits. To maintain synchronization, additional padding bits may be required, and the distance between the padding bits will set the maximum tolerance of the oscillators in the modules used in the system.

[0081] The above principle is scalable. A module can be configured to communicate via a control network. During the transmission of message data packets via the control network according to the first protocol, a third message using the third protocol is embedded within the message data packet. In another approach, different modules can embed different protocols. These embedded protocols do not necessarily adhere to any of the design rules of CAN. The voltage level in the example above is the same as that of CAN, but it can also be different. Thus, a large number of protocols optimized for different purposes can be embedded. Different groups of nodes in a CAN network can use different embedded protocols. For example, the processing device of a module can be configured to change the encoding method of the second protocol in response to changes in the operating mode of the communication device. Such modes include, for example, maintenance mode, refresh mode, running mode, sleep mode, etc. The bit rate of the second protocol can also be modified.

[0082] Furthermore, the processing device can be configured to apply the second protocol to fewer than each first protocol message sent from the communication device. For example, in many systems, CAN bandwidth is perfectly adequate for most of the runtime. In such applications, the embedded protocol will only be used for certain specific messages that might require multiple transmissions via the first protocol; an example is GPS coordinates. The embedded protocol can also be used for diagnostics. Currently, On-Board Diagnostics (OBD) is part of the legislative mandate for CAN communication in vehicles, requiring certain message exchanges during runtime. This creates bandwidth and timing issues because OBD messages only appear when performing diagnostic checks. When the communication module is configured to operate on the vehicle bus, its processing device can thus be configured to use the second protocol to perform the transmission of vehicle on-board diagnostic information during runtime message transmission using the first protocol. Such an application of the embedded protocol as described herein would eliminate the problem because OBD information can be transmitted by the embedded protocol without affecting timing or bandwidth during runtime. Another example is in the case of a vehicle system being re-flashed. In this example, the module's processing device is configured to control the participation of devices on the control bus using the second protocol's flashing operation, reducing system latency during the flashing operation.

[0083] Another advantage of the described method is the use of a secondary protocol to aid in the identification of network problems. For example, interference on the bus includes common CAN problems that are often difficult to detect and correct. Such interference includes wave reflections due to impedance displacement along the bus, clock frequency variations due to temperature changes across different nodes, and temporary distortions due to external sources. An interference on only one node in a system can often corrupt CAN messages on its own. The margin of failure is often unknown. Thus, a secondary protocol can be used to address such problems. For example, the high-speed sampling capability of the secondary protocol can be used to detect noise in the primary protocol messages. Noise in the propagation segment of the primary protocol message can indicate difficulties when using a secondary protocol, as noise can cause bit errors or CRC errors in the secondary protocol.

[0084] As mentioned above, embedded high-speed protocols are typically only needed occasionally. When not used for communication with embedded protocols, the device can be used for near-continuous quality checks of the physical layer. In this method, a module's processing device is configured to use a second protocol to test the signal quality of the control network. According to one method, the processing device is configured to control the second protocol to use a bit rate higher than that of the first protocol, and to determine whether the second protocol bits embedded in the received first protocol message differ from the expected signal level for the corresponding portion of the received first protocol message when the received first protocol message does not use the second protocol embedded message. In other words, each module is set to listen to the bus, and zeros should not be detected during bus idle periods. When transmitting CAN messages, all bits in the bytes of the embedded protocol should have the same value as the CAN bits.

[0085] To illustrate this point, Figure 8 The diagram shows the beginning of a received CAN message 600 sent from another module, starting with a recessive level 601 and a falling edge 602, indicating SOF. Three reflections follow the falling edge: 603, 604, and 605. The first two 1s are decoded as 11, indicating that the first two time quantum times following the falling edge are insecure for the embedded protocol. Figure 9 The same message is shown on another module farther from the reflection point. Here, the reflection is damped to a level safe for the embedded protocol. Another interference 605 is detected, which can be easily considered a false resynchronization edge, or, if it occurs at the sampling point, will cause a bit error. Modules that support, but do not use, the embedded protocol can detect and record such interference that may cause the CAN module to resynchronize at false edges and / or sample incorrect bit values. The interference will be time-stamped very accurately according to the local clock on the respective module. The processing device can then send information about whether the second protocol bit embedded in the received first protocol message differs from the expected signal level to a comparator device configured to compare this information with corresponding information from other devices on the control network to locate the source of the control network error. This can be achieved by using a time recorded according to the respective local clock and replaced with common time, an example of which is described in U.S. Patent No. 8,065,052, the contents of which are incorporated herein by reference in their entirety. Interference caused by impedance changes on the bus can be distinguished from other types of interference. Furthermore, since the wave propagation speed in the bus is known, the location of impedance anomalies in the bus can be determined by correlating the timestamps of the interference on the corresponding nodes with the bus length between the corresponding nodes.

[0086] If it is determined that for a given control network, interference primarily occurs in specific portions of the first protocol message, such as near the edge in the example above, the embedded protocol can be modified to prevent the use of those specific portions of the first protocol for embedding. In the example above, the second protocol can be configured to avoid using one or more of the time quanta at the beginning of Prop_Seg for embedding data. The higher-level protocol CanKingdom demonstrates how CAN bit timing can be optimized using Kings Page8; the same method can be used to specify the time quanta that should be used by the embedded protocol. In another such approach, the entire embedded protocol can be configured in a system-specific manner by applying the CanKingdom method, still using general modules.

[0087] In further quality checks, the clock used for relying on the second protocol can be used to detect differences between the local clock and the clock of another device on the control network. In such an approach, modules typically use separate counters to decode the first protocol, such as the CAN protocol, and the embedded second protocol. Here, the processing device is configured to operate in a mode where embedded second messages are not expected; when operating in this mode, the second protocol counter is not resynchronized in response to receiving the synchronization portion of a received first protocol message. The processing device then counts the ticks of the second protocol counter for each received portion of the first protocol message to determine the clock rate of the module that transmitted the received first protocol message. Thus, in parallel with participation in CAN communication, a node can easily determine the difference between the local clock frequency and the clock frequency of the corresponding transmitter by avoiding resynchronization of the embedded protocol's clock (by comparing the time from the end of the arbitration field to the falling edge of the ACK bit, as recorded by the resynchronized CAN clock and the unresynchronized clock of the embedded protocol). Additional advantages can be achieved by combining the present principles with the techniques described in U.S. Patent Nos. 7,934,039 and 7,478,234, the entire contents of each of which are incorporated herein by reference.

[0088] Reference Figure 10-13 This describes another example implementation of the second protocol within the first protocol. In this example, the CAN bus 701 has an electronic control unit (ECU) 702 connected at the leftmost end of the bus 701 and a second ECU 703 connected at the rightmost end of the bus 701. Between these ECUs 702 and 703, there are more ECUs 704, 705, and 70n connected to the bus 701. The second ECU 703 transmits message 1100 according to the CAN protocol, a portion of which... Figure 11The following is shown. The bit sequence 1 1 0 1 1 of message 1100 according to the CAN specification is shown. More specifically, bits 0 of CAN message 1100, Sync_Seg 705 and Phase_Seg 1 and 2, 706, are shown. Next, bits 1 of CAN message 1100, Sync_Seg 707 and Phase_Seg 1 and 2, 708, are shown.

[0089] In the case where the second ECU 703, as described here, is configured to operate according to the second protocol, ECU 703 will signal the same bit sequence, as shown in message 1120. Here, Sync_Seg 710 is understood as a dominant bit quantum. The next part is recessive, up to the dominant Phase_Seg 1 and 2 711, followed by the dominant Sync_Seg 712 and the recessive Phase_Seg 1 and 2 713, the first 1 bit following the zero bit in the original CAN message 1100. The second 1 bit after the zero bit is initiated by the dominant Sync_Seg 714. Prop_Seg is calculated according to the original CAN protocol to determine the signal delay between ECUs 702 and 703, which is designated as an eight-bit quantum, shown as 715. An additional nine-bit quantum is added to the left of the bit 716. In this example, the second protocol is defined as a byte, represented as a "start of byte" bit quantum, followed by eight-bit quantum.

[0090] This instructs ECU 702 to use specific bits from a specific CAN message to transmit bytes according to a second protocol. In this example, segment 716 shows these bits transmitted from ECU 703 in the original CAN protocol message 1100. To illustrate the time delay on the bus and how the module transmits information despite the time delay, Figure 12 and 13 The diagram shows what was sent by the first ECU 702 at 1200 and 1300, and what was received and transmitted by the second ECU 703 at 1220 and 1320. Figure 12 It is configured based on the time sensed by the second ECU 703, and Figure 13 It is configured based on the time sensed by the first ECU 702. Transmission 717 from the first ECU 702 begins with Sync_Seg 710. It propagates along the CAN bus 701 and reaches the second ECU 703. When it is detected by ECU 702, ECU 702 transmits the beginning of the byte 718, followed by bits 01101011 according to the second protocol. This is in... Figure 12As shown, bit 01101011 is transmitted immediately in response to receiving Sync_Seg710 from the first ECU 702. Then, the second ECU 703, in response to receiving Sync_Seg712 from the first ECU 702, transmits the second byte 01010101 according to the second protocol. This second protocol signal from the second ECU 703 propagates back to the first ECU 702; however, due to the propagation delay, it is now located at the second portion 715 of the original CAN signal transmitted by the first ECU 702. The time difference between 710 and 718, i.e., the propagation delay between ECUs 702 and 703, can then be easily measured by the first ECU 702.

[0091] This configuration not only allows signals from different ECUs according to the second protocol to be embedded in the same message according to the first protocol, but also makes it easy to measure the propagation delay between ECUs. A wide variety of protocols with different qualities can be created by combining these principles with those described in U.S. Patent No. 7,711,880 entitled "Schematizing Of Messages In Distributed Control and Supervision", U.S. Patent No. 7,472,216 entitled "Variable Oscillator For Generating Different Frequencies In A Controller Area Network (CAN)", U.S. Patent No. 7,899,936 entitled "Device In A Modularized System For Effecting Time-Stamping Of Events / Reference Events", and U.S. Patent No. 7,478,234 entitled "Distributed Control and Monitoring System", the entire contents of each of which are incorporated herein by reference.

[0092] The various protocols described here can also be applied to different control network topologies. Figure 14In one example shown, the CAN-based control network 1400 has a star topology with an active hub device 1410 at the center. The active hub device 1410 is configured to connect to multiple CAN channels 1422, 1424, and 1426 of the control network 1400 and acts as a gateway between two or more of the multiple CAN channels 1422, 1424, and 1426. For example, the active hub device 1410 may be an ECU connected to communicate on each of the multiple CAN channels 1422, 1424, and 1426. In another example, the active hub device 1410 may be three separate controllers simply linked by software that exchange messages or information between three different buses. In yet another example, the active hub device 1410 may also be a combination of logic designed to transmit messages between different buses in approximately real-time.

[0093] In an example implementation of such a star topology network with multiple modules, a first group of modules 1412, 1414, 1415, 1416, and 1417 are configured to communicate using both the first and second protocols as described herein, and are connected to communicate on a first CAN channel 1422 of the multiple CAN channels. A second group of modules 1430, 1431, 1432, and 1433 are connected to communicate via a second CAN channel 1424 using the first protocol instead of the second protocol through a control network 1400. A third group of modules 1460 and 1462 are connected to communicate via a third CAN channel 1426 of the multiple CAN channels, using both the first and third protocols, by using the first protocol in conjunction with the third protocol, and sending message packets based on messages embedded in message packets using the third protocol. The third protocol may or may not be compatible with the second protocol. Here, the active hub device 1410 is configured to receive messages via the first CAN channel 1422 using the second protocol, and to send messages via the third CAN channel 1426 using the third protocol.

[0094] In another example with multiple modules communicating in a given environment, the multiple modules configured to use an embedded protocol can be configured to receive a signal that an upcoming first protocol message will be sent, and to allow multiple second protocol messages to be embedded during the transmission time of the upcoming message. In response, the multiple modules can configure themselves such that a single module within the module sends a second protocol message during certain portions of the upcoming first protocol message. From the perspective of a single module, the first module is configured to receive a signal that an upcoming first protocol message will be sent, and is configured to send a message based on the second protocol during a first defined portion of the upcoming first protocol message (which is less than the entire upcoming first protocol message), and to receive second protocol messages from another module during a second defined portion of the upcoming first protocol message that differs from the first defined portion. Accordingly, multiple modules based on the second protocol can send information during the duration of a single first protocol message, which significantly reduces communication latency when multiple modules need to exchange information.

[0095] In a specific example of such a method, a "master node" transmits a message based on a given CAN ID and DLC, such as, for example, a 1000-bit CAN message. The data field then carries a pattern of 1s. On the bus, there will be ten blocks of patterns containing five recessive bits and one dominant bit. Each of the ten recessive bits can be used in a different way for the embedded protocol. An example could be a protocol with an embedded protocol, as suggested above, where each CAN bit can transmit bytes according to the embedded protocol. The decoding rules for the information in the embedded protocol are given by the CAN ID in a manner largely the same as for higher-level CAN protocols. The data bits are then scheduled so that the first two five-bit sequences are reserved for transmission from the first node using the second protocol, the second two five-bit sequences are reserved for transmission from the second node using the second protocol, the third two five-bit sequences are reserved for transmission from the third node using the second protocol, and so on. Each module can then send eight bytes of data and a 15-bit CRC sum, as in a normal CAN message. In this way, the latency of transmissions from these second protocol nodes can be significantly reduced. For example, transmission from five nodes can be reduced by a factor of five, where the delay between data packets among these five nodes is known a priori with high precision in this example. Different schemes can be applied depending on different needs. Not only the data field can be used, but also the hidden bits in the CRC field, the CRC delimiter, and the hidden bits after the ACK bit can be used.

[0096] In additional alternative embodiments, the functionality or logic described herein may be embodied in the form of code that can be executed in separate processor circuitry. If embodied in software, each block of functionality or logic may represent a module, segment, or portion of code comprising program instructions to implement the specified logical function. Program instructions may be embodied in the form of source code (which comprises human-readable statements written in a programming language) or machine code (which comprises numerical instructions recognizable by a suitable execution system such as a processor in a computer system or other system). Machine code can be derived from source code. If embodied in hardware, each block may represent a circuit or a plurality of interconnected circuits to implement the specified logical function. Accordingly, a computer-readable medium (which is neither transient nor tangible) may store such instructions configured to cause a processing device to perform the operations described herein. Those skilled in the art will understand hardware approaches including field-programmable gate arrays (FPGAs), microcontrollers, and the like.

[0097] Generally speaking, today's electronic devices are highly complex and dynamic, with no clear-cut line between software and hardware. For example, software will require some supporting hardware for information storage, and essentially every software instruction will depend on some hardware in the MCU core that will return the expected result from the instruction. Conversely, hardware design depends on some software and documentation describing the hardware to be produced. Hardware can also be fixed to a hardware gate array (HGA) device based on hard-to-modify schematics, where the basic hardware is fixed but the final hardware functionality can be modified by using different connections between the internal basic structures. The most flexible solution available today is the FPGA mentioned above, which does not need to be fully finalized before delivery. Instead, internal connections between the basic structures can be made while the device is installed in the product. Connections in an FPGA are made by setting a programmable value to a certain value, which in binary will be set to 0 or 1. The most common solution is to use RAM technology to store the connection patterns. The disadvantage of such a solution is that the device loses connectivity when power is lost, and the device needs to be reconfigured every time power is restored. The advantage of configuring in SRAM is that the device can be reprogrammed at any time. Some newer devices even offer the possibility of reprogramming only a portion of the device. Some devices use flash memory to configure connections within the FPGA. The advantage of this approach is that the device is likely to be working correctly once the power supply is stable. The disadvantage is that, in most cases, programming flash memory takes significantly longer than programming RAM. Some older devices use fusion technology to program the FPGA. The drawback of this solution is that once you have programmed the device in the cell, it is impossible to change the connections in the future. This isn't 100% accurate, because in most cases, connections start with binary values ​​of 1 or 0; you can change their default values, but you cannot switch them back.

[0098] Various methods are possible to implement a second protocol within the CAN protocol using hardware and software components. In one approach, data transmission and reception comprise two independent processes with two different local clocks, except for arbitration; this is a mixture of simultaneous transmission and reception. The transmitter places one bit at a time into the communication line. The length of each bit is defined as a number of local clock cycles. In most cases, each bit transmitted has the same length in the local clock cycle; however, the protocol can accommodate a mixture of different bit lengths in the local clock cycle. In one example, the second protocol can use two different bit lengths, but additional bit lengths are also possible. Each transmitted bit will generally have at least two different levels; however, more levels are also possible. The level of each bit is defined by the protocol. Certain fixed and other bits will depend on the data content; for example, the digit 1 can be transmitted as a bit 0 and a second bit 1, while the digit 0 can be transmitted as a bit 1 and a second bit 0; such a pattern is called Manchester encoding. The transmitter will send a bit stream to form a message, starting with the first bit included in the protocol and ending with the last bit. The time between messages is called the idle bus and can be a fixed level or a pattern representing different levels of the idle communication bus.

[0099] In this example, the receiver typically remains idle when decoding the idle mode on the communication line. The message will begin with a different mode than the idle mode, which includes an edge (switching from one level to another). The protocol defines how this edge relates to the position of the sample point in each bit that follows in units of the local clock. If the receiver clock has the same speed as the transmitter clock, the receiver will correctly sample each bit through the message. In practice, having two clocks that will have the same speed for an infinite amount of time is difficult, if not impossible. Accordingly, the system must either use a clock good enough to keep the sample point within the message, or the message must be designed short enough to guarantee that the clock will not deviate too much during the message's duration. Neither solution is ideal because often the available clock is not accurate enough or the message becomes too short. To address this, the protocol can define certain edges used to adjust the sample point. Typically, an edge is defined as a level shift between two bits. If those well-defined edges occur too early or too late, the receiver may be able to adjust the position of the sample point relative to those edges to obtain better sampling in the later bits, until a new edge is available for the next correction. During arbitration, the module should adjust the transmission of bits based on the reception of edges as defined in the protocol. The accuracy of the clock is given by a combination of the degree to which the sampling point can vary in time and still sample within the correct bit range, and the frequency and extent to which the sampling point will be corrected by the protocol rules.

[0100] Turning Figure 15This section will describe a specific implementation using a second protocol within the CAN protocol. Unlike the specific implementation described above where a single processing device prepares and sends (and receives) both the first and second protocol messages in a combined CAN / second protocol message, two or more processing devices can work in parallel to process different parts of the combined message. This aspect can be scalable, where different processing devices are responsible for processing specific bit quanta or portions of a given sent or received message.

[0101] More specifically, in Figure 15 In the example, the communication device 1500 includes a communication port 1510 configured to connect to a control network 1511. The processing device of the communication device includes a first processing device 1500 configured to control the communication device to perform CAN communication arbitration and control the communication of CAN message packets. The processing device also includes at least one second processing device 1505 and 1507 configured to control the communication of at least a portion of additional information within at least one bit quantum other than the defined bit quantum. In the illustrated example, the at least one second processing device includes separate processing devices 1505 and 1507, each configured to control the communication of at least a portion of additional information within a different bit quantum other than the defined bit quantum. More or fewer processing devices can be added, and the different processing devices can have different amounts of bit quantum or specific bit quantum assigned for analysis or generation.

[0102] In this method, communication port 1510 is operatively connected to a first processing device 1500 to transmit CAN message packets via control network 1511, and at least one second processing device 1505 transmits additional information via control network 1511. Furthermore, communication port 1510 is also configured to connect to control network 1511 to receive CAN message packets transmitted via control network 1511, and is operatively connected to provide received CAN message packets to first processing device 1503 to read CAN message data, and to provide received CAN message packets to at least one second processing device 1505, 1507 to read additional information in the CAN message packets. In the illustrated example, communication port 1510 includes a separate receive (bus-level indicator) 1513 section and a transmit 1515 section, although other configurations that essentially combine these aspects together are also possible.

[0103] Figure 15A further example method is illustrated to apply a more precise clock to the device to enable read capability and second data embedded within a single bit of a standard CAN message. In this example, a time event generator 1520 is operatively connected to at least two registers 1532 and 1632. The time event generator 1520 generates time ticks at a specific rate. Registers 1532 and 1632 are part of separate time counters 1530 and 1630. The first register 1532 of the at least two registers counts the ticks received from the time event generator 1520 and, in response to counting a first number of ticks, outputs a first trigger signal at output 1533 and resets. The second register 1632 of the at least two registers counts the ticks received from the time event generator 1520 and, in response to counting a second number of ticks, outputs a second trigger signal at output 1633 and resets.

[0104] First register 1532 provides a first trigger signal to first processing device 1503, wherein the first trigger signal corresponds to the sampling time of the CAN message data packet. Second register 1632 provides a second trigger signal to at least one of second processing devices 1505, wherein the second trigger signal corresponds to the sampling time of additional information transmitted within the CAN message data packet. Thus, registers 1532 and 1632 help the processing devices track when a voltage signal is sensed in a received data packet or when a signal is provided in a transmitted data packet. Sometimes, these registers need to be reset to resynchronize the communication device with other communication modules on control network 1511. In one method, reset device 1536 senses the frame start point and, in response to sensing the frame start point, connects to reset at least two registers 1532 and 1534. In the illustrated method, the reset devices 1536 and 1636 of each of the corresponding time counters 1530 and 1630 receive an output signal provided from CAN bit identifier module 1550 in response to sensing a frame start point signal on control network 1511. Although different registers for providing time events at different sampling rates are shown in different modules 1530 and 1630, the registers do not necessarily have to be so separate in a given implementation.

[0105] The above examples can be understood within the context of the concept of time. The most common communication protocols are based on physical seconds, used to represent bits. For example, the standard CAN protocol defines its bit time as "bus management functions performed within a bit time frame, such as CAN node synchronization behavior, network transmission delay compensation, and sampling point positioning, which should be given by the programmable bit timing logic of the CAN protocol IC. a) Rated positioning rate (BR) gives the number of bits per second transmitted by an ideal transmitter without resynchronization, b) Rated positioning time, t B= 1 / BR.

[0106] On the other hand, time can be described as a count of bit quanta generated by an oscillator. For example, the standard CAN protocol defines "programming bit time" as "programming bit time shall be performed using the following time period... a) time quantum, which shall be a fixed unit of time derived from the oscillator period."

[0107] Thus, time is not defined in communication protocols, although some communication protocols are defined as event-triggered or time-triggered. Three different concepts of time can be considered to understand this invention. The first is NTime (natural time), which is the concept of time that everyone experiences daily, but no one knows exactly what it is. According to NTime, events can be recorded and organized with dimensions of past and future, and predictable and unpredictable events can be distinguished. Normally, NTime has no starting point and is continuous, irreversible, unstoppable, and endless.

[0108] The second is PTime (Physical Time), which is the scientific concept of time in the physical laws used to describe NTime when modeling its essence. PTime is continuous and reversible, meaning that any model based on physical laws can operate reversibly in time. The model will then show the situation from any point in time, and vice versa, depending on the model. PTime has a base unit, the second, which is one of the seven base units in the International System of Units (SI).

[0109] Third is LTime (Local Time or Logical Time), which is generated by a time tick generator and measured by a time counter. The combination of these two constitutes the LTime Clock (LTC). The LTC is the time source for the LTime Domain (LTD). Two or more LTDs can be associated with each other and / or synchronized to one of them, or alternatively synchronized to a virtual LTD. The primary purpose of this time concept is to coordinate the flow of events, the flow of states, the transitions between states themselves, and coordination with both the PTime and NTime domains.

[0110] Some LTime characteristics include being finite, with a defined start and end. LTime is stopable and can be restarted. LTime can also be associated with PTime and NTime in a non-linear / linear manner. Accordingly, the time tick generator can be independent of PTime and NTime.

[0111] An LTD is typically defined by an LTC, where the corresponding LTCs of multiple LTDs can have the same time tick generator. Multiple LTDs can be synchronized via reference events (REs).

[0112] Refer again Figure 15 For example, the time event generator 1520 includes an oscillator 1522 that outputs time event 1524 to TC 1526. The CAN standard defines a “time quantum” as follows: “A time quantum should be a fixed unit of time derived from the oscillator period. A programmable prescaler should exist with integer values ​​from at least 1 to 32. Starting with the minimum time quantum, the time quantum should have the following length: time quantum = m * minimum time quantum, where m is the value of the prescaler.”

[0113] To define the time quantum, TC 1526 includes a register 1528 that sets a limit for LTime. Whenever register 1528 reaches its defined limit, it transmits a time quantum event at its output 1529 and resets itself. The result is a stream of time tick events, i.e., a stream of time quantum 1525. Time event generator 1520 defines an LTD programmable to span from 1 to 32 time events, which can generate time quantum according to the CAN protocol. LTC or time event generator 1520 acts as a time tick generator and feeds time events to time counter 1530. Time event generator 1520 and time counter 1530 form another local time counter 1539.

[0114] The time counter 1530 includes an event input 1537 that resets the counter 1530 in response to receiving an event. In this example, the first register 1532 is programmable from 2 to 17, and when the first register 1532 reaches its programmed value, an event is transmitted at output 1533. The second register 1534 is programmable from 1 to 8, and when the counter 1530 reaches the programmed value of the first register 1532 plus the programmed value of the second register 1534, the counter 1530 is reset. According to the CAN specification, a CAN bit consists of at least one Sync_Seg time quantum, one Prop_Seg time quantum, one Phase_Seg 1 time quantum, and one Phase_Seg 2 time quantum, i.e., four time quantumes, with a maximum length of Sync_Seg plus 24 time quantumes. The first register 1532 can be programmed to override Sync_Seg plus Prop_Seg plus Phase_Seg 1, while the second register 1534 can be programmed to override Phase_Seg 2. Local time counter 1539 will count the number of time events representing CAN bits, generating one event after Phase_Seg 1 and another after Phase_Seg 2.

[0115] Such a local time counter 1539 can support the CAN bit identifier 1550 and the bus-level indicator 1513. In the illustrated example, the bus-level indicator 1513 has an event input 1514 that receives a time event 1525 from the time event generator 1520. In response to receiving a time event from the time event generator 1520, the bus-level indicator 1513 samples the bus voltage on the CAN bus control network 1511. If a voltage is detected, the bus-level indicator 1513 transmits a voltage event signal 1516 to the event input port 1551 of the bit identifier 1550. If no voltage is detected, the bus-level indicator 1513 sends a no-voltage event signal 1517 to the event input port 1552 on the CAN bit identifier 1550. Therefore, in this arrangement, the CAN bit identifier 1550 receives a voltage signal or a no-voltage event signal at each tick event generated by the time event generator 1520.

[0116] The CAN bit identifier 1550 includes an event logic device 1553 and an event counter 1554 for counting time events 1525. The event logic device 1553 is operatively coupled to an input port 1555 connected to receive a first register event from a first register 1532 of the time counter 1530. When operating according to the CAN specification, the bit value is determined at the end of Phase_Seg 1. In such a case, the first register 1532 stores the value of the first register event that generates the expected sampling point event corresponding to a given CAN bit. The first register event triggers the CAN bit identifier 1550 to detect the voltage on the control network 1511 at the expected sampling point event. In response to the expected sampling point event, and in response to determining that there is no voltage event from the bus level detector 1513, the event logic device 1553 outputs a recessive bit event (corresponding to logic "1") at output 1556. If a voltage event is detected at the sampling point, the event logic device 1553 outputs the dominant bit event (corresponding to logic "zero") at output 1557, unless the dominant bit event is a frame start event. A frame start event occurs when a logic "0" is detected after ten or more consecutive recessive bits (logic "1").

[0117] Event logic device 1553 is also triggered in response to receiving a frame start register event signal from frame start register 1534 to detect voltage. In this example, frame start register 1534 is operatively connected to first register 1532 and programmed to start counting time events in response to receiving an event from first register 1532. After reaching the time event count programmed into frame start register 1534, it outputs a frame start check event to event logic device 1553 via output 1535 to trigger event logic device 1553 to check the voltage corresponding to the frame start bit after a sampling point read triggered by first register 1532.

[0118] Generally, the event logic detector 1553 is configured to identify recessive, dominant, and SOF bits not only by comparing voltage events, sampling point events, and the number of time-tick events counted by counter 1554. In response to detecting a frame start event, the event logic detector 1553 generates an SOF bit event signal at output 1558. These signals from outputs 1556, 1557, and 1558 are received by a protocol logic unit (PLU) 1560, which is configured to decode the bit stream received via control network 1511 according to the CAN protocol.

[0119] The following describes programming. Figure 15 Examples include sensing standard CAN bits (such as...) Figure 16 This is an example of the configuration shown. The data to be received is defined by voltage level 1601 on control network 1511. Here, the standard CAN bit has the following components: Sync_Seg 1602 is one time quantum, Prop_Seg 1604 is eight time quantum, Phase_Seg 1 1606 is three time quantum, and Phase Seg_2 1608 is three time quantum. The prescaler is set to sixteen so that the oscillator generates sixteen minimum time quantum to construct a single bit. Accordingly, register 1528 is set to sixteen. First register 1532 is set to twelve, and frame start register 1534 is set to three. Using these settings, CAN bit recognizer 1550 can trigger resynchronization in response to the detection of a hard Sync_Seg, thus notifying reset devices 1536 and 1636. Local time counter 1539 defines the time quantum of a bit, while the first register counts to the twelfth bit quantum to trigger sampling at the sampling point, and the frame start register counts to the third bit quantum after the sampling point to trigger sampling of the desired next frame start bit. Once triggered, event logic detector 1553 will transmit the CAN bit detected on the control network 1511 to the CAN protocol unit 1560.

[0120] More specifically, upon receiving the initial falling edge, the receiving device 1500 assumes it is the Start of Frame (SOF) bit 1652 of the message and performs hard synchronization, i.e., resets the time quantum counter. In an example where hard synchronization occurs in a bit after the start of a new message, SOF 1652 can be referred to as the start of the bit. After twelve time quantumes, sampling point 1607 is reached, which lies between the last time quantum 1653 of Phase_Seg 1 1606 and the first time quantum 1654 of Phase_Seg 2 1608. At sampling point 1607, or SP, a voltage level is sampled. If the voltage level is dominant, as shown by voltage line 1601, then the bit is decoded as SOF, where the falling edge in time quantum 1652 is considered the start of a new CAN bit. Conversely, if a recessive level is detected at the sampling point, as shown by voltage lines 1660, 1670, and 1680, the bit is ignored. For example, voltage line 1670 shows a voltage level that drops to a dominant level, but rises to a recessive level after 11 time quanta, drops back to a dominant level after 12 time quanta, and rises back to a recessive level after 15 time quanta. Since the receiver samples a recessive level at the sampling point (SP), the bit is ignored as an SOF bit.

[0121] In other words, Figure 16Another scenario is illustrated: since the CAN receiver samples only twice within a standard CAN bit, ignoring any voltage level offset, these ignored portions of the bit can be used for transmission at a higher bit rate by another protocol. In one example, the second protocol can transmit bytes on an idle CAN bus, as shown in voltage line 1680. Here, the transmitting device uses the same time quantum as the CAN system; however, each time quantum represents one bit. The quantum sampled at the recessive level is decoded as 1, while the time quantum sampled at the dominant level is decoded as 0. The protocol has the same definition of the idle bus as CAN, however, the Sync_Seg of the CAN SOF is defined as the start of the frame (sof). Following the sof is the first data frame of eleven bits, followed by two recessive bits from the standard CAN sampling point. The two recessive bits are decoded as recessive by the standard CAN module, thus triggering the standard CAN module to ignore the initial falling edge at the sof. Accordingly, the standard CAN module treats the control network bus as idle. The second data frame of two bits follows the two recessive bits, followed by the end of the frame (eof) bit at the recessive level. The first four bits of the first data frame are a byte counter, meaning that fifteen consecutive bytes can be transmitted as a message. Then, voltage trace 1680 shows the voltage level shift for transmission according to Example Second Protocol or the embedded protocol. After the sof, the byte counter binary number 0100 (decimal four) is followed by the binary number 11001000 (decimal 200). Immediately following, the next sof 1685 indicates the start of the next sequence, beginning with the byte counter value of 0101 (decimal five).

[0122] Thus, the frame start bit of standard CAN communication can be used to force module resynchronization between sequences of a second protocol or an embedded higher-frequency protocol, reducing transmission errors caused by poorly synchronized time event generators of various modules on the control network. Generally, when a second message is embedded within a message packet of the first protocol and the receiving device adjusts the position of the sampling point within the received first protocol bit in response to a transition edge sensed within the defined portion of the received first protocol bit, the device can transmit a series of bits according to the first protocol with transition edges to implement the movement of the sampling point of the receiving communication device, providing additional space within the first protocol bit for embedding the second message using the second protocol. In such a method where the CAN protocol is the first protocol, if Sync_Seg after the recessive bit is set to the dominant level, the oscillator accuracy problem across modules will be reduced because the clocks of all modules will be resynchronized at each bit. CAN resynchronization and synchronization jump width (SJW) rules will not be needed. Modules on the control network configured to only understand standard CAN messages will sample thirteen bit quanta within Phase_Seg 1 and Phase_Seg 2 after the last resynchronization. Because the example new protocol generates a dominant Sync_Seg, such a primitive CAN controller will resynchronize at least every other recessive bit, but only at the sixth bit after five consecutive dominant bits. In any case, this synchronization is twice as fast as the thirteen-bit requirement, thus ensuring that the various modules are fully synchronized.

[0123] Furthermore, the original CAN modules can be tricked into moving their sampling points to allow more space within the CAN bit for transmitting second protocol information. For example, the processing device of the second protocol module can transmit a series of bits according to a first protocol with transition edges, where the Sync_Seg bit quantum of subsequent bits is dominant, to provide a transition edge for moving the sampling points. The processing device of the second protocol module can also use a second protocol, at least partially within the bit transmitted using the CAN protocol, to transmit a second message in the portion of the bit other than the Sync_Seg bit quantum and the sampling point, such as using the Prop_Seg portion of a CAN message data packet. The transition edge does not need to have the full width of Sync_Seg as defined within the CAN protocol; instead, the edge can have a length sufficient to be detected by modules on the communication network.

[0124] To detect voltage levels at each time quantum, the second register 1632 can be programmed with a specific count to trigger the event logic detector 1553 or the second processing device 1505 to sample the voltage at bit quantum levels other than those defined for the typical CAN standard. Thus, in addition to other embedded protocols using the LTime domain, voltage levels can be decoded on the bus and sampled at different bit rates according to the CAN specification. The system does not require the use of physical time or natural time where the connection to NTime is made via oscillator 1522. Oscillator 1522 can be replaced with anything that generates an event stream, such as an electromagnetic pickup that senses the rotation of the gear tip. Accordingly, a CAN network can be established where all ECUs are connected to the electromagnetic pickup and will correctly encode and decode CAN messages; however, the bit rate per second will vary with the rpm of the gear.

[0125] If a local oscillator is used as a time tick generator in the system, the frequencies of the time quantum defined by the various time tick generators 1520 at the corresponding ECUs within the system should be synchronized. This can be accomplished in two ways: either by adjusting the frequency of a given oscillator or by adding or removing time tick events to and from the time tick generation stream 1525. Either method can be implemented via feedback between nodes on the control network 1511 and / or via control signals from the master node on the control network 1511.

[0126] Controlling the voltage level of each quantum time can provide further advantages beyond embedding a second protocol. For example, the CAN standard is often criticized for its high power consumption. One way to reduce power would be to transmit only the dominant voltage level during Sync_Seg and Phase Seg 1 and 2, thus reducing transmission power compared to keeping the voltage level high.

[0127] If a second protocol is used within a standard CAN message, certain advantages can be achieved by specifying the new protocol (by setting all RTR, r1, and r0 bits to a recessive level). After the RTR bit, all CAN controllers are resynchronized to the transmission node by sensing the falling edge from the recessive RTR bit, allowing the embedded second protocol to begin embedding data into the CAN message. According to one approach, r1, r0, and the DLC bit can be used to indicate how many second protocol bits will be embedded within each CAN bit. Since the second protocol can have its own time quantum definition, higher resolution is possible, allowing for more than one embedded bit within a single CAN time quantum. In some approaches, only one additional bit is embedded within the standard CAN bit, sampled between the Sync_Seg and Phase_Seg 1 time quantum levels to minimize the impact of wave reflections on the physical bus, which in some applications can increase the data error rate.

[0128] Specific considerations for implementation in older CAN communication systems

[0129] In legacy CAN systems, module resynchronization occurs after the dominant signal in the synchronization segment follows the recessive bit. This is the rule by which all legacy CAN systems better adjust sampling points relative to this edge. Generally, legacy CAN systems leave a space around the sampling point open to acknowledge signal reception, as timing errors can cause signal reception to occur sometime before or after the sampling point. By performing this resynchronization multiple times, the module described above communicating using the second protocol will confirm the location of the legacy CAN sampling point much more accurately than the usual times before and after the legacy CAN sampling point allocated using the SJW rule, thus ensuring additional space within the legacy CAN bit for second protocol communication. For example, if more edges are generated to perform resynchronization of the legacy CAN system module, the sampling point can be moved to the theoretically correct position between Phase-Segment 1 and Phase-Segment 2, allowing almost all of Phase-Segment 1 and Phase-Segment 2 to be available for second protocol data. In short, all the implicit bits following this dominant Sync-Seg will adjust the sampling points of the legacy CAN system, and this feature can be used by the second communication protocol module to create additional space within the legacy CAN bits for second protocol communication.

[0130] In legacy CAN, a sequence of ten bits without edges is possible. However, if all those bits are recessive and the second protocol does not send a dominant signal for resynchronization, the second protocol will be limited in the amount of phase segments available for transmitting second protocol data due to the uncertainty of the actual location of the legacy CAN sampling point. Conversely, frequent adjustments to the sampling point confirm the second protocol module's functionality, meaning the legacy CAN sampling point will only use a small portion of the phase segment. This allows more available space in the phase segment before the sampling point to be used for transmitting second protocol data. Placing second protocol bits after the legacy CAN module has sampled recessive bits will cause edges to be used for resynchronization, which limits the ability to transmit second protocol data in the phase segment after the legacy CAN sampling point.

[0131] However, when the legacy CAN system samples the dominant signal, it ignores any edges after the sampling point so that the second protocol module can insert additional data into the second phase segment after the legacy CAN sampling point. Accordingly, the module can increase the amount of space that second protocol data can be inserted into the legacy CAN bits by balancing the use of resynchronization to confirm the location of the legacy CAN sampling point with the use of the dominant legacy CAN sample to allow the second protocol bits to be inserted after the legacy CAN sampling point. For example, after a series of resynchronizations, 90% of the entire phase segment in the first dominant legacy CAN bit can also be used for second protocol communication. In the second dominant legacy CAN bit, 80% of the entire phase segment can also be used for second protocol communication, and so on, up to the fifth consecutive dominant legacy CAN bit, where 50% of the entire phase segment can be used in addition to all propagation segments. We again have limitations with respect to legacy CAN, as this does not conform to the rule of having more than five consecutive bits with the same sample value. The sixth bit must be recessive; however, high-speed bits can be placed in all sync and propagation segments, as well as 40% of the phase segment 1. After the sampling point, the signal remains recessive without any edges until the start of the dominant sync segment following the recessive bit, which adjusts the sampling point back to the theoretically correct position. The cycle then restarts, at which point the high-speed bit can be placed once an edge is detected and up to 90% of the entire phase segment. In practice, the sync segment should be just the length required for all modules on the bus to recognize the dominant edge after the recessive sample. If the dominant sync segment is too short, some older CAN nodes may not recognize the resynchronized signal. In this example implementation, the CRC portion of the message will vary with different bits in the CAN frame until the start of the CRC.

[0132] In this implementation, the system should verify the correct sampling for the second protocol. In one example, if you needed to adjust the sampling point every ten bits in legacy CAN to preserve the sample position within the bit, the system could do this more or less frequently for high-speed bits in the second protocol. If the phase segment is 20% of a legacy CAN bit, then most of the bit is used for the propagation segment, and only the phase segment is needed to compensate for clock skew. Therefore, since high-speed bits do not use the propagation segment, in an example where communication is unidirectional and the only compensation needed is the clock skew between the sending and receiving nodes, if the first protocol can utilize 20% of the bits to handle clock skew within ten bits, then the second protocol will handle 100 bits in the stream until resynchronization is required. Typically, it is the receiver with a less accurate clock that will set the physical layer performance. If the clock performance is better, more bits can be in the row before needing to be resynchronized to ensure the sampling point is better positioned within the bit edges. The other extreme would be with a very small propagation segment (in the case of a communication bus, e.g., with short cables and a very unstable clock), where most of the legacy CAN bit is used for the phase segment. In this case, the secondary protocol will require resynchronization almost every 10 bits.

[0133] There are no theoretical limitations on the relationship between the legacy CAN (first protocol) bit rate and the second protocol bit rate, because the only limitation is that the second protocol bit will not cause legacy CAN modules to sample the second protocol bit or use it in such a way that they would incorrectly resynchronize the first protocol units. As an example, we tested communication with a second protocol bit rate 80,000 times that of the first protocol bit rate. In this case, there would be approximately 40,000 second protocol bits per first protocol bit (assuming the propagation segment is approximately 50% of the first protocol bits). In this case, if the clock requires resynchronization every 100 bits, we would resynchronize the second protocol at least 400 times.

[0134] In those extreme numerical cases, the very precise position of the first bit is used in the second protocol. Even if you have a precisely dominant edge in the first protocol bit, which is divided into ten time quanta, the second protocol bit will still enter the synchronization segment quantum at the end of the synchronization segment with up to 2.5% desynchronization, and the second protocol receiver may have a 40-bit phase difference with the transmitter. In these cases, the second protocol starts with an edge to ensure that the subsequent samples in the second protocol are sampled in the correct position, and resynchronization in the second protocol should occur every 100 second protocol bits, and together with the first protocol bit.

[0135] Implementation of additional synchronization with CAN-FD

[0136] While the above description primarily focuses on the implementation of the second protocol within the first protocol by adding bits within the legacy CAN bits, certain aspects of the second protocol described above can be implemented in or combined with other protocols such as CAN-FD, as described in the article "CAN with Flexible Data-Rate Specification Version 1.0 (Released April 17, 2012)," which is incorporated herein by reference in its entirety. The CAN-FD protocol definition essentially follows the rules of the legacy CAN protocol for the first part of the transmission. After this initial transmission, messages sent according to CAN-FD can switch to a higher bit rate. CAN-FD uses the edge between the Identifier Extended Flag (IDE) bit and the r0 bit to define the start of the higher-speed portion of CAN-FD (Extended Data Length (EDL) bit, which also serves as a final synchronization before entering the high-speed portion of the transmission. However, the start of the high-speed transmission portion is delayed until the bit rate switch at the Bit Rate Switch (BRS) bit, which causes a difference in the receiver's clock relative to the sampling point of the high-speed portion. The lack of embedding resynchronization into the high-speed portion of the CAN-FD protocol results in the need for a higher-quality clock and limitations on the ability to improve the sampling rate at the high-speed portion of the protocol, thereby limiting the overall possible bandwidth.

[0137] If the resynchronization method described above for the second protocol implementation in the legacy CAN system is applied to the high-speed portion of CAN-FD, the CAN-FD method may have a much higher bandwidth due to the increased confidence at the higher-speed sampling points. For example, by defining an edge in the first bit (or immediately after the BRS bit) of the high-speed portion of the CAN-FD protocol, the receiver will sample exactly correctly at the first bit, and after a certain number of bits, there will be an edge in the bit that can be used to resynchronize the sampling point to the appropriate position in the received bit. Thus, the processing device of the transmitting module can send the dominant bit after the recessive signal to define an edge at the beginning of the second part of the message, so that the modified CAN-FD protocol is partially defined by the receiving device adjusting the position of the sampling point of the second high-speed portion bit in response to sensing this edge. For example, in CAN-FD, this new resynchronization edge can be located in the high-speed portion of CAN-FD, immediately after the BRS bit is sampled, or as the end of the BRS bit / start of the high-speed portion, where in the slower portion of the protocol, the next slower portion bit has already started. The latency in the high-speed implementation relative to synchronization is essentially eliminated because the edge of the first detected high-speed bit defines the start of the high-speed portion of the CAN-FD message. The only drawback of this solution is that the first high-speed portion bit is defined as dominant so that this bit defines the start of the high-speed portion. Testing confirms that if this synchronization technique is applied to the CAN-FD protocol, a bit rate ratio of at least 1 legacy CAN bit to 80,000 CAN-FD bits can be achieved.

[0138] Specific implementations and optional uses of the CAN embedding format

[0139] A specific implementation of the second protocol described above, applied in either the traditional or extended CAN format, will be described. Here, the second protocol is referred to as CAN-Embedded High-Speed ​​Format or CAN-EF. In this implementation, the stringent requirements imposed on the CAN bus system provide the basis for embedding auxiliary data transmission mechanisms into the CAN frames.

[0140] Generally speaking, and as Figure 17As shown, a CAN frame (whether it's the basic CAN frame 1710 or the extended CAN frame 1720) is divided into two bidirectional cycles 1712, 1714 and 1722, 1724, respectively, meaning that more than one module is actively communicating and exchanging information. The unidirectional phase 1716 or 1726 is located between or between the two bidirectional cycles 1712, 1714 and 1722, 1724. In other words, at this point in the frame, only the transmitting module is active on the bus, while the remaining communication modules are in listen-only mode. The first bidirectional phase 1712, 1722 is the arbitration field ending with the RTR bit, as described above. The frame period from IDE in the basic CAN format frame 1710 or R1 in the extended CAN format frame 1720 up to and including the CRC delimiter is the time for unidirectional communication.

[0141] In one-way communication, the propagation segment is useless when the receiver is fully connected to the transmitter. Embedded protocols use this fact to send alternative protocols within the propagation segment, as described above. The complete propagation segment can be used from the IDE / R1 bit without arbitration.

[0142] Arbitration offset and system synchronization

[0143] During arbitration, when both units are at the cable length limit, the time difference between any two nodes can be as large as a propagation delay. To illustrate the arbitration situation, Figure 19 The diagram shows that unit A transmits earlier than unit B by one propagation delay. The worst-case scenario occurs when unit B wins arbitration. In this case, both units enter a unidirectional phase with the maximum offset, and the entire propagation segment is used for compensation. In the worst case, the CAN frame data sequence may result in a minimum amount of synchronization information, giving a dominant edge every ten bits, just enough to compensate for the allowed frequency offset. In this case, if arbitration occurs, the size of the portion of the frame that can be used for a second protocol embedding is limited by the propagation delay.

[0144] If multiple units start at the same absolute time, the synchronization offset generated by arbitration can be reduced by factor 2. The synchronization pulse is a sufficiently short, dominant pulse transmitted during bus idle periods that is not detected as the start of a frame. Figure 19 This diagram illustrates two communication units configured to transmit synchronization pulses according to the CAN-EF method. Both units begin at the same absolute time. A falling edge from unit A or B will reach all units on the bus within one propagation delay. At the end of arbitration, the maximum difference will be the sum of the propagation delay and the difference added by the uncertainty in the clock of a given unit.

[0145] The synchronization pulse sent before the transmission begins ensures that all CAN units will be synchronized to units A and B, and arbitration begins with the synchronized unit.

[0146] To achieve synchronization, a timing reference can be used. For example, one of the cells (A or B) can be set to act as a timing reference and transmit timing reference pulses. To achieve absolute time, the propagation delay from the reference cell to all other cells must be estimated.

[0147] CAN Synchronization

[0148] Resynchronization in the receiver is performed for each recessive-to-dominant edge, provided that the relevant synchronization rules for CAN are followed: 1) Only a single synchronization between two sample points is allowed; 2) Only the synchronization edge following the recessive sample bit is used; and 3) Only the recessive-to-dominant edge is used for synchronization. A node transmitting the dominant bit should not synchronize to a recessive-to-dominant edge with a positive phase error. Other synchronization rules do not apply to CAN unidirectional phase. These rules give the following conclusions: 1) No edge following the dominant sample will be considered a synchronization edge; and 2) Only the first edge following the recessive sample will be used.

[0149] Satisfy CAN synchronization

[0150] To enable the propagation segment for embedded data transmission, the CAN receiver must be prevented from performing false synchronization in this region. If a dominant CAN bit is received, this automatically follows the CAN synchronization rules. However, when a recessive bit is received, the receiver must be forced to synchronize in the synchronization segment to avoid losing synchronization with the transmitter. This behavior is handled by transmitting the dominant synchronization segment. This method ensures that a falling edge with correct CAN timing follows each recessive bit. According to the CAN specification, all edges up to the next sampling point should be ignored.

[0151] One side effect of this method is that CAN timing is improved during the embedded frame because the longest time between synchronization edges is reduced from 10 bits to 6 bits, which in turn leads to the 60% synchronization jump width (SJW) requirement for CAN.

[0152] Example: Embedded frames in a propagation segment, without arbitration.

[0153] When CAN synchronization as described above is satisfied, propagation segment 2102 can be used for embedded data, such as... Figure 21 As shown. Edges not created in this embedded frame should be able to alter CAN frame synchronization.

[0154] Figure 22The definition of phase segment 1 shown is during a unidirectional phase change. Sampling at the receiver occurs within the SJW+SP region before the transition from phase segment 1 to phase segment 2, before the sampling point, and after the transition from phase segment 1 to phase 2 within the SJW region. The sampling point SP field is an uncertainty added by the SYNC quantum. Depending on a shorter maximum synchronization delay, the SJW can be as low as 60% of the full CAN SJW. Thus, during the unidirectional phase (see...), Figure 23 The resulting phase segment 1 will require that

[0155] t ps1 = 1 + 0.6SJW

[0156] Use the following inequality to calculate the usable value of SJW so that the clock tolerance requirement is not determined by SJW, where PS is the phase segment length and BT is the bit time, usually expressed as the number of quanta.

[0157]

[0158] Assume phase segment 2 is equal to phase segment 1, and assume the processing delay is less than or equal to PS1.

[0159] Therefore, during the format portion of the frame embedding, the required phase segment 1 is:

[0160]

[0161] The required phase segment length can also be expressed relative to a known clock tolerance, where df is the clock frequency offset:

[0162]

[0163]

[0164] As clock tolerance improves, the margin required from the rated sampling point approaches a time quantum.

[0165] Synchronization after arbitration

[0166] In the case of arbitration, the portion of a frame that can be used for embedding is significantly limited by the propagation delay. Dominant edges that force more synchronization can be introduced to further improve the timing before synchronization. One way to achieve this would be to send alternating recessive / dominant bits to create a dominant edge every other bit.

[0167] By using the method described in the previous section, a dominant edge can be created in the recessive bit sequence. If the sequence of recessive bits is sent in reverse, five of the six bits will have the following characteristics: Figure 24The synchronization edges are shown. Each synchronization edge will reduce the offset by up to SJW time quantum, but for each bit, a certain time offset is added due to the frequency shift between cells. For a bit, the average improvement in the number of time quantum is at least:

[0168]

[0169] Then, the length of the embedded frame can be increased at the rate of the dominant edge, and the largest of the embedded data channels can be used.

[0170] Furthermore, by applying a larger SJW setting, the synchronization performance before the embedded frames is improved. If the maximum propagation delay in the system is known, the desired number of dominant edges can be used as a configuration parameter to shorten the time before the frame region begins to be embedded.

[0171] If the clock tolerance is unknown, the worst-case scenario can be calculated based on SJW and expressed as:

[0172]

[0173] This method relies on a timing margin large enough to send the embedded synchronization segment.

[0174] Once synchronization to the CAN-EF unit is established after arbitration, the entire frame up to the earliest sample point in the system can be used for embedded data. To maximize efficiency, the earliest sample point (ESP) is determined by the shortest t on the bus. seg1 - 0.6t sjw The unit is determined.

[0175]

[0176] t sync Suitable for CAN units with the longest time quantum to ensure correct sampling and synchronization. The time left for the embedded data bits is...

[0177]

[0178] In bandwidth-constrained situations, preferably, all portions of the bandwidth-limited embedded CAN frame are of equal length. In this case, all embedded samples will have timing requirements equal to those of the CAN portion of the frame.

[0179] With limited clock tolerance, the synchronization segment at the beginning of each CAN-EF bit improves the embedded frame synchronization interval from 10 CAN bits to less than 2 CAN bits. CAN timing is also improved from SJW to 0.6SJW. Therefore, the embedded part is guaranteed to have better synchronization than the CAN part, and thus can be set to a higher bit rate. Furthermore, improved bandwidth performance can also be achieved by shortening the embedded bits. The shorter the embedded field, the faster resynchronization is completed, and full-rate embedding is possible.

[0180] In the case of maximum arbitration offset, the synchronization pulse cannot be transmitted without extending it to the phase segment. Sufficient resynchronization must be achieved before using the synchronization pulse method. The first part of the data phase of switching CAN bits can be used to achieve the necessary synchronization.

[0181] The embedded frame is characterized by the following parameters:

[0182]

[0183] CAN and embedded frame timing ( Figure 25 The following relationships between (as shown in the diagram) also apply.

[0184]

[0185] Only early or late t esjw The synchronization edge will be used for synchronization. Adjust t sync The length is such that the received value is at least a time quantum, even in the worst-case dominant-recessive-dominant transition. Short recessive pulses are shortened by CAN bus features with active dominant drive and pull-up for recessive values. Receiver filtering may also introduce shortening of the pulse detected by the receiver.

[0186] Timing margin is the remaining portion of the propagation segment when propagation delay is taken into account. Figure 26 The situation described above represents the possible state after arbitration. Every change in the data after the portion within the timing margin can be interpreted as a CAN error.

[0187] Bit fill

[0188] The timing in the embedded field requires more accurate timing than the sampling in the CAN bits. This timing improvement can be achieved without any protocol cost if the synchronization segment bit is always transmitted as the inverted value of the last CAN sample, such as... Figure 27 As shown. This method will provide the necessary edges after the recessive sample. A synchronization edge will be generated no later than one CAN bit cycle after the dominant CAN bit. Fill bits with incorrect polarity will generate a fill error.

[0189] The worst-case oscillator tolerance requirement for the embedded frame is given by the following formula:

[0190]

[0191] To implement the above method, several other parameters are determined. First, the number of CAN bits from the last synchronization edge is counted. For a synchronization edge detected before an RTR bit, the counter is reset to zero because synchronization edges in RTR bits can only be generated by the transmitter, and the synchronization edge is counted as a timing offset correction. The value of the counter is the number of clock drift bits (n). cdb ). n cdb It is proportional to the accumulated clock skew in the worst-case scenario.

[0192] Next, count the number of dominant synchronization edges (n) from and including the RTR bits. se Each synchronization edge increases the timing margin to at least t. sjw .

[0193] Use the following formula to calculate the total time margin that can be used to send the embedded data, tm tot :

[0194]

[0195] Among them, sjw can be used min / 10 represents the maximum known clock drift in reality.

[0196] When tm tot Less than t sync At that time, CAN bits with alternating recessive and dominant values ​​are transmitted to obtain the necessary clearance. If tm tot Greater than or equal to t sync Then from tm tot Subtract t from the middle sync And send a synchronization segment.

[0197] When tm tot Greater than or equal to t bit At that time, from tm tot Subtract t from the middle bit And send the embedded bits. Calculate a new tm for each new bit. tot Then restart the judgment process until all embedded bits are contained within a bit cycle.

[0198] When synchronization is achieved, the CAN bit field of the CAN EF bit can be used to transmit data packet information. Padding bits are sent along with diagnostic message bits until the number of CAN bits specified by the DLC has been sent. The data portion always begins with an embedded DLC (EDLC) and ends with an embedded CRC (ECRC).

[0199] This method will be precise and will be dynamically applied to the data on the bus. Furthermore, depending on the time since the last synchronization, this method also considers practical requirements for phase segments that may be smaller than the SJW.

[0200] Embedded frame format

[0201] The previous section described how to embed CAN EF data bits into ordinary CAN bits. This section will refer to... Figure 28 and 29 This describes the frame format of the embedded data portion. An embedded CAN frame is transmitted as a sequence using the available embedded timeslots and CAN bit timeslots. In practice, the actual start of the embedded frame depends on the EF bus parameters.

[0202] The Start of Embedded Frame (ESOF) is signaled, similar to a CAN FD frame, by sending a recessive R0 or R1 bit. The Start of Frame field is used to distinguish embedded CAN frames from regular CAN frames, and also to differentiate them from the resynchronization phase of the embedded frame. The CAN EF unit receiving the recessive R0 / R1 bit will perform hard synchronization on the next recessive to dominant edge. If the synchronization margin is large enough, synchronization will be completed immediately after the ESOF bit. The recessive ESOF signal indicates that the frame is a CAN EF frame; however, the actual start of the embedded frame is delayed until sufficient synchronization is achieved. Synchronization requirements are related to both the CAN unit and the CAN EF unit.

[0203] The Embedded Data Length Code (EDLC) is the first 6 bits after the ESOF. The EDLC allows embedded data packets of 0-64 bytes. The EDLC counts the embedded bits and data bits transmitted during CAN bit timing. Embedded data frames (EDATA) are transmitted using every available bit during and after synchronization, up to and including the CRC delimiter. Diagnostic bits are transmitted as padding when no more data packets remain to be transmitted.

[0204] Figure 30 The diagram shows 80 CAN EF bits transmitted using two CAN bytes. The upward slop at the beginning is part of a design that utilizes as many bits as possible during arbitration offset compensation.

[0205] At the end of the frame, the embedded CRC (ECRC) is transmitted in the same manner as the data bits. The ECRC is initiated at a time agreed upon by both the transmitter and receiver in the frame, and the ECRC should be transmitted completely within the CRC delimiter at the latest.

[0206] In the embedded phase, the CAN transmitter logic will remain synchronized with the frame; however, it will not transmit on the bus, and it will not detect bus errors. The embedded transmitter and receiver operate asynchronously to compensate for receiver / transmitter cycle delay. Transmitted data is stored in a FIFO for comparison with received data to detect bus errors.

[0207] In this example, instead of maximizing the use of all available embedded frame bits, the protocol is closer to the CAN protocol for simplicity of implementation. CAN padding bits, as well as additional embedded fields in the DLC, DATA, CRC, and CRC delimiter CAN fields, can also be used for data transmission. In some configurations, a considerable number of additional bits can be used for data. The occurrence of padding bits is not easily predictable, and the maximum number of bits in this channel will vary with the amount of data transmitted. Additionally, the best effort channel can also be used to send diagnostic messages, including, for example, error counter values, error passivity flags, bus parameters used, transmitter ID, transmitter capabilities, and technical fault counts. If each message is preceded by a message identifier, the EF unit can add diagnostic messages to the best effort channel as needed or as required.

[0208] The current scheme uses CAN bits for data transmission. If CAN bit values ​​are used to control the padding of data fields, other alternative frame formats can be sent. Examples include sending a minimum number of padding bits in the CAN channel and sending a maximum number of padding bits in the CAN channel, where the number of padding bits in the CRC may still be difficult to control.

[0209] Another optional configuration is to send acknowledgments only for the IDs that match the filter. This method ensures that valid units receive the data packets.

[0210] For higher speeds in pure EF mode

[0211] To achieve better performance, the CAN-EF protocol can be implemented in an environment where CAN compatibility limitations can be abandoned. Various attributes can be modified in this environment to achieve a more efficient protocol, including, for example, one or more of the following: having a variable ID length, making high-priority messages shorter, removing the IDE bit, removing remote transmission requests, having a high-speed data field, and shortening the frame end field. Some important CAN attributes are retained, including arbitration, error frames, and methods for modifying frame synchronization.

[0212] To achieve a more efficient bit format, padding bits are still inserted, with arbitration bit spacing; however, the insertion interval (t) is not present in the data. can = 0) to achieve CAN compatibility. tcan is expected to be greater than tbit because the worst-case CAN resynchronization interval is 6 CAN bits, compared to less than 2 CAN bits for the embedded protocol. This additional margin may allow for more than one embedded bit to replace a portion of the CAN bit allocation in the bit cycle. Hard synchronization is used to handle the synchronization offset after arbitration; as a result, all embedded time slots can be used immediately.

[0213] Systems with relatively good clock tolerance can increase the spacing between padding bits by increasing the number of embedded bits. This method reduces the overhead associated with padding bits. However, the data stream may be misinterpreted as error frames or bus idle, and error frames will not be detected because no padding bits are overwritten. In this case, alternative mechanisms for error frames and frame synchronization must be used.

[0214] One of the significant performance penalties associated with CAN compatibility is the length of the ID field. This can be improved by introducing a variable-length ID field. Shorter ID fields can be assigned to higher-priority messages and the most frequently used messages.

[0215] In some cases, a much shorter new frame format can be used. The following illustrates a new frame.

[0216]

[0217] The ID field has a variable length of n bits = 2k, where k is between 0 and 15. The TERMINAL field always consists of two dominant bits. An octet DLC allows for 0 to 255 bytes of data in the packet. When the ID field size is set to 0 and there is no data transmission in the data field, a minimum packet size of 6 arbitration bits and 35 high-speed bits is sent.

[0218] The ID field is encoded using 2 bits. 00 is used as the terminator and can only be used as the last bit in the ID. 01, 10, and 11 are used in arbitration. The shortest code wins. The highest possible priority ID is 00. Below are four example unit IDs:

[0219] Unit a: 01 10 10 0*1 11 11 00

[0220] Unit b: 01 10 1*1 00

[0221] Unit c: *11 11 11 11 11 11 11 11 00

[0222] Unit d: 01 10 10 00

[0223] The asterisk-marked unit loses arbitration and becomes the receiver's point. After 8 bits, unit d wins and ends the sequence. Using this method, 25% of all possible ID values ​​will be lost; however, the lost ID numbers can be compensated for by adding an extra ID bit.

[0224] If the packet limit from CAN FD is retained, the new protocol uses fewer than 23 arbitration bits compared to CAN FD, in which case there is one additional HS bit. For longer ID fields, the differences are reduced.

[0225] The ratio of padding bits between protocols is data-dependent. The embedding format uses one padding bit per CAN bit. When using 8 embedding bits per CAN bit, the embedding format has one padding bit every eight bits. If the data is all 1s or all zeros, the CAN FD protocol uses one padding bit every five bits.

[0226] Overload frames cannot be used with just one ACK delimiter bit; if this functionality is required, an intermittent bit should be added.

[0227] At least one bit is reserved for protocol extensions. The reserved bit should be designed to be backward compatible. If a newer protocol than the supported one is detected, the unit should enter listen mode and wait for a backward compatible resynchronization sequence.

[0228] The End-of-Frame (EOF) field has several functions. First, the EOF field can detect units that have misunderstood the DLC field and are still receiving data, or units that are receiving data when the EOF is transmitted. The EOF field is long enough to create a padding error. The EOF field can also allow new units to resynchronize to the bus.

[0229] Units attempting to synchronize to bus communication will have two cases to handle. First, an idle bus is identified by a time period of 11 recessive bits, as in CAN. Second, if the bus is active, the CRC DELIM bit must be checked. The CRC DELIM is designed to make resynchronization possible. Units seeking synchronization will set the bit synchronization to the falling edge. The CRC DELIM is reserved to be recessive long enough to generate a padding bit violation, such as... Figure 31 As shown. The combination of high-speed dominant bits and padding violations is the only combination for the CRC DELIM field. In the event of an actual padding error, the bit positions at both ACK and ACK DELIM will be overwritten, and the cell will be resynchronized to the end of the error frame.

[0230] Fixed-form padding violations in the CRC DELIM field are used as markers for the end-of-data field. Units that misunderstand the DLC and are still transmitting data will generate padding errors at this point. Units arriving at the CRC DELIM field while the transmitter is still in the data field will generate fixed-form errors.

[0231] Error frames are transmitted at the CAN bit rate as six symbols, as in CAN, except for the error frame delimiter. The error frame delimiter has been removed. An error frame should end with a sequence of matching CRC delimiters, an ACK slot, and an ACK delimiter, but without a first-dominant edge. This sequence provides a resynchronization edge in the ACK slot, resulting in good synchronization of the frame start immediately following the ACK delimiter. The RTR field of the regular CAN protocol is replaced with an ID mask matching the response buffer.

[0232] Idle bit communication protocol

[0233] During bus idle periods, each falling edge is used by the CAN receiver to perform hard synchronization. If the dominant bus event causing the edge is shorter than the bit's propagation segment, it will not be considered a frame start bit. A dedicated coordinator module can be used to transmit information during the period between the dominant edge and the end of the propagation segment. With sufficient bandwidth and propagation segment length, multiple bits of information can be transmitted during this period. The dedicated coordinator can be any module on the communication network (such as those described herein, with processing devices configured to control its activity and communication ports configured to allow communication on the network), but preferably, it will be located at the physical midpoint of the bus to minimize the maximum distance to communication modules on the network. Brief Reference Figure 10 The dedicated coordinator can be module 705 located in the middle of the bus 701 shown.

[0234] A dedicated coordinator can be used in one or more of the following ways: supporting automatic baud rate, distributing bus parameter settings so that any unit connected to the bus can immediately obtain the correct bus parameter settings, distributing time, sending scheduling information (setting the current minimum priority, mask, etc.), sending beacons, capturing and sending diagnostic information, performing bus signal quality measurements, and delay measurements. If a unique identity is assigned to all nodes, the coordinator can target one node at a time. Idle bit communication will be a non-intrusive best-effort channel. The coordinator can send a request to a specific node, which can then be allowed to send its response. Frame start-up conditions will delay frames until the data packet is sent and the bus returns to an idle state. Even if the coordinator is not an acceptable solution as a conventional communication concept, this concept can still be useful as part of a test setup.

[0235] In another application, it is possible for the first sampling point to be moved into the propagation segment during arbitration; to move the sampling point, a recessive transmission to the dominant edge can be made in the synchronization segment to ensure that those receivers with sampling points in the propagation segment move their sampling points outside the propagation segment, as specified by the CAN protocol rules. If a dedicated coordinator is placed in the middle of the physical medium, transmitting the dominant synchronization segment during the idle phase will force the units using the CAN protocol to be synchronized to this mode. With this synchronization, all units begin transmitting within 25% of the propagation segment. This behavior can be used in two different ways. It can be used to ensure that the first protocol sampling point never moves more than 50% into the propagation segment, thereby allowing the transmission of embedded bits to begin within at least 50% of the propagation segment without waiting for many edges to move the first sampling point out of the segment. Another use would be to extend the cable length in communication systems using the first protocol. By having idle phase synchronization transmitted from units located in the middle of the physical medium, double the delay can be achieved between the farthest units in a CAN system compared to the rules typically applied to systems according to the first protocol (CAN). In this system, the embedded bits as described above can still be used; however, by utilizing the extended cable length, the first protocol sampling point can be located in any part of the propagation segment after arbitration, which requires many implicit to dominant edges in the synchronization segment to ensure that the embedded second protocol bit will not hit the first protocol sampling point.

[0236] The worst-case bus parameters used on the bus can be determined using an idle bit communication method. A scan is initiated by a dominant sync pulse, which is extended until an error frame is detected. An error frame is generated when the dominant sync pulse is sampled at a receiver's sampling point. The length of the sync pulse is a measurement of the maximum usable propagation segment on the bus.

[0237] Figure 32 The diagram shows a two-bit cycle with an initial synchronization pulse. Actual sampling will occur within an uncertain period around the nominal sampling point. When the synchronization pulse is long enough to enter the sampling interval, the actual setup will be determined. At this point, a false frame start point will be detected, generating an error frame.

[0238] The idle bit communication principle works not only during idle bus periods but also, in some cases, for each recessive bit. The simplest application of this is a synchronization pulse overlay. A synchronization pulse overlay can be used to synchronize all units on the bus to a coordinating synchronization pulse transmitter. A synchronization pulse is sent as the dominant pulse at the beginning of each bit within each bit time interval. The synchronization pulse must be short enough that it cannot be detected as the dominant bit by any receiver on the bus segment. The synchronization pulse interval must be shorter than or equal to the shortest bit time of any receiver on the bus to force all units to remain synchronized with the coordinator. Synchronization pulses are also sent during bus idle periods to ensure that all units are hard-synchronized to the synchronization unit. If all of these requirements are met, all units on the bus will remain synchronized with the coordinator.

[0239] The advantage of this method is that the maximum number of bit cycles between synchronization edges is only 6, compared to 10 bit cycles for a standard CAN bus. Synchronization pulses can also be used to gather information about the location of nodes on the bus. The distance between the coordinator and nodes can be estimated when a unit transmits the dominant bit after the recessive bit, while all units remain synchronized with the coordinator.

[0240] Figure 33 The upper timeline shows the bus at the coordinator's receiver. The coordinator receives its own synchronization pulse as it is transmitted on the bus. The lower timeline shows the data sent from the transmitter. In this case, the transmitter is shown as perfectly synchronized with the synchronization pulse; therefore, it will send the dominant bit at the exact time the synchronization pulse arrives. The dominant bit will be detected at the coordinator with a propagation delay exactly two steps after the start of the synchronization pulse.

[0241] Figure 34 Synchronization uncertainty is illustrated, where synchronization at a transmitter will drift within its synchronization segment, and propagation delay includes the transmitter's transceiver delay. If sufficient samples that can be associated with the transmitter's identity are available, synchronization errors can be removed using statistical methods. Transceiver delay will add uncertainty that has not been removed.

[0242] During bus idle periods, the coordinator can broadcast a best-effort message. Each bit in the message begins with a sync pulse, and the remaining portion of the available propagation segment can be used to send the information. The broadcast message will not interfere with CAN bus communication; however, the broadcast message itself will be destroyed at each CAN protocol-dominant bit. The broadcast data overlay will have the same basic properties as the sync pulse overlay, with an additional data segment appended. The sync pulse must be long enough to be safely detected by each CAN controller on the bus segment.

[0243] If a unique addressing scheme is available, a broadcast data overlay can be used to support bidirectional protocols. The address is sent in one or more broadcast bits, and the response from a single-addressed unit follows a configurable delay. The unique address may be a CAN identifier used in the system, and only devices configured for that specific identifier will respond. An example use case would be obtaining diagnostic information from a unit with a specific identifier that is detected behaving incorrectly. Figure 35 The diagram illustrates the coordinator sending an idle message with an 11-bit unique identifier and responding after a sufficient delay by sending the identifier back to the unit. Broadcast and response protocols can be constructed from the sequence of idle bits.

[0244] With this configuration, a complete best-effort protocol can be implemented on top of the CAN protocol by using idle bit communication. The protocol will not interfere with ongoing CAN protocol transactions, and it may improve bus timing by providing synchronization edges.

[0245] Besides being used as an idle bus and a high-speed communication option, the embedded format can also be used for diagnostics. For example, the patterns described above can also be used to check the maximum performance of the communication medium in the physical medium, such as... Figure 15 As shown. Numerous CAN buses are installed in cars, trucks, and machines, and they work very well with their rated bit rates. The most common bit rates are between 125 and 500 kbit / s. Some are higher, up to 1 Mbit / s, while others are as low as 20 kbit / s. In many of those systems, higher bit rates can be used; however, the extent to which the bit rate can be increased without problems is uncertain. In CAN-FD, bit rate switching is performed at the sampling point, which makes the switching somewhat complex because there are no edges within close proximity to the bit rate switching location. To position the bit rate switching at the same location as in the CAN-FD method, bit rate switching is performed on almost two bits. First, a dominant bit follows a recessive bit according to the first protocol. According to the sequence of recessive bits followed by the dominant bit, an edge causes a synchronization segment. This edge has two functions. First, the edge measurement is sent from the edge to the... Figure 15 The part indicated by 1515 in the code starts from the point until it is received back into the logic (as...). Figure 15The internal delay of the output from 1513. When this delay is known, it can be checked that each bit is received with the same value transmitted on the communication medium. This is necessary for detecting and handling errors according to the protocol. A second use of this edge is to locate the device switching from the upper bit rate to a sampling point at a higher bit rate. This switching cannot be done in this bit because this bit is reserved to indicate the upper bit rate of a future-defined protocol. The bit following this reserved bit is called the BRS bit (Bit Rate Switching Bit), and when you reach a sampling point in the upper bit rate, there is a switch to the higher bit rate. This solution presents a small problem in making precise measurements in a flexible way. First, it will travel almost from the edge to the upper bit rate until it reaches the sampling point. During this time, time diverges because different units have clocks with different speeds. The units on the bus should also have similar time quanta because when you add the time quanta from the edge to the sampling point, the time you get must be the same to guarantee that you are switching at the same time instance in all modules. Without a very good clock, it will be difficult to have a ratio of more than 20 times between the upper bit rate and the higher bit rate. In diagnostic situations, we aim for the highest possible accuracy.

[0246] By switching to the high bit on the edge of the synchronous segment, it is possible to switch with precision limited only by the jitter in the edge and the level of how quickly the logic can sample what is received from the bus. The solution will also depend on the location of the sampling point. Utilizing this freedom, a higher bit rate independent of the base positioning rate can be set. For testing, the EF protocol bits can be shorter, and each step can be one clock cycle shorter. In today's available low-cost FPGA logic, a 100MHz clock can be used, with each step as small as 10 nanoseconds. Using more expensive equipment, clocks approaching 1 GHz can be achieved, with resolutions up to 1 nanosecond. Simultaneously, the phase-shift logic samples eight times faster than the basic clocks used today. The basic mode is as follows... Figure 2 The same applies as shown, except for the bits marked 108, where the base rate is used for all bits.

[0247] Those skilled in the art will recognize that various modifications, alterations, and combinations can be made to the embodiments described above without departing from the scope of the invention, and such modifications, alterations, and combinations will be considered to be within the scope of the inventive concept.

Claims

1. A method for communication between two or more modules (1010, 1020, 1030, 1040, 1050, 1060) via a universal control network (1000), the method comprising: A message data packet is received by communication devices (1012, 1014) through the control network (1000), the message data packet being defined by a bit having a plurality of bit quanta, wherein the data of the message data packet is defined by a signal level at a defined bit quantum of the bit, the defined bit quantum being part of a bit quantum in a bit, and wherein the communication devices (1012, 1014) are configured to sample bit quantum outside the defined bit quantum of the bit; Receive signal interference at a specific bit quantum of a specific bit in the message data packet; decode the signal interference into a value that is different from the expected value; The method is characterized in that it further includes: The signal interference is time-stamped and recorded; The location of impedance anomalies in the general control network is determined by associating the timestamps of a given signal interference at each node of the general control network.

2. The method of claim 1, further comprising determining, in response to decoding the signal interference into a value having a different value from the expected value of the bit, that the use of the particular bit quantum for data transmission is not error-free.

3. An apparatus for communicating between two or more modules (1010, 1020, 1030, 1040, 1050, 1060) via a universal control network (1000), the apparatus comprising a processor and a computer-readable medium storing program instructions for causing the apparatus to perform the method as described in any one of claims 1 or 2 when the program instructions are executed on the processor.

Images