Controller Area Network Sampling Point Detection

Abstract

Detect the transmission of recessive bits in CAN messages from a transmission electronic control unit (ECU) via a controller area network. After a delay time in the detected recessive bits, a dominant pulse is injected onto the network. Detect the behavior of the transmission ECU and characterize the sampling point for the transmission ECU based on the detected ECU behavior. Generate an action signal based on the characterized sampling point.

Description

Technical Field

[0001] This description relates to computing using a Controller Area Network. More specifically, this description relates to detecting and configuring sample points in an electronic control unit operating on a Controller Area Network. Background Art

[0002] Controller Area Network (CAN) communication is carried out using a well-documented protocol. A computing system is used to run configuration logic to configure an electronic control unit to communicate using CAN communication. This typically includes configuring things that can be directly measured (such as signaling rate) and things that cannot be directly measured (such as CAN sample points).

[0003] More specifically, a single CAN message (or network data packet) is typically composed of a serial bit stream, which can vary from approximately 60 bits in length to well over 100 bits in length. Each individual bit has a specific set of configuration elements that together determine the time length (or bit length) of the bit. The time length of the bit in turn determines the signaling bit rate.

[0004] An electronic control unit (ECU) is also configured with a sample point. The sample point defines the point within the bit length (or bit period) at which the ECU samples the state of the bit. The position of the sample point within the bit length can greatly affect the accuracy with which the ECU interprets the state of the bit.

[0005] The above discussion is provided only for general background information and is not intended to assist in determining the scope of the claimed subject matter. Summary of the Invention

[0006] Via a Controller Area Network, the transmission of recessive bits in a CAN message from a transmitting electronic control unit (ECU) is detected. After a delay time in the detected recessive bits, a dominant pulse is injected onto the network. The behavior of the transmitting ECU is detected, and a sample point for the transmitting ECU is characterized based on the detected ECU behavior. An action signal is generated based on the characterized sample point.

[0007] This summary is provided to introduce in a simplified form some concepts that will be further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to assist in determining the scope of the claimed subject matter. The claimed subject matter is not limited to embodiments that solve any or all of the disadvantages described in the background art. Brief Description of the Drawings

[0008] Figure 1It is a block diagram of an example of a CAN bus architecture.

[0009] Figure 2 It is a block diagram of an example that shows in more detail the sampling point verification and control calculation system.

[0010] Figure 3A and Figure 3B (Collectively referred to as Figure 3 herein) shows an example of the operation of the sampling point verification and control calculation system when identifying the sampling points of the ECU.

[0011] Figure 4 It is an example showing the injection of a dominant pulse into the CAN bus within a CAN message transmitted by an electronic control unit (ECU) under test.

[0012] Figure 5 It is an example showing the Figure 1 block diagram of an example of the architecture shown.

[0013] Figure 6 It is a block diagram of an example showing a computing environment that can be used in the architecture shown in the previous figures. Detailed Description

[0014] As discussed above, the position of the controller area network (CAN) sampling points used by an electronic control unit (ECU) on the CAN bus can greatly affect the accuracy and reliability of the ECU's operation on the CAN bus. However, the CAN sampling points cannot be directly measured.

[0015] Individual bits in a CAN message transmitted by an ECU have a bit length (or bit period) that is defined by a number of time quantities (t q ), where t q is typically derived from a high-speed clock source (such as the clock source of the main microprocessor) that has been divided down by a prescaler. The bit is also subdivided into multiple time segments, each time segment being represented by an integer number of time quantity values t q . The time segments are typically referred to as time segment 1 (tseg1) and time segment 2 (tseg2).

[0016] The total bit period in units of t q is defined as:

[0017] Equation 1

[0018] 1 + tseg1 + tseg2

[0019] The number of time quanta in tseg1 and the number of time quanta in tseg2 are typically set by values tracked in a pair of registers in the CAN controller (or ECU). Some other CAN controllers have additional registers that track propagation delay segments (propseg) related to the propagation delay in the entire network. In such a system, the total bit period (or bit length) is determined as follows:

[0020] Equation 2

[0021] 1 + propseg + tseg1 + tseg2

[0022] The sampling point in the bit period or bit length defined by the above Equation 1 and Equation 2 is at the end of tseg1. This means that within a single bit, the ECU that samples this bit waits within this bit until the end of tseg1 before sampling the state of the bit.

[0023] More specifically, a CAN message starts with a specific "start bit" which is a transition from logic 1 (recessive state) to logic 0 (dominant state). At the start of the defined bit period, the transmitting ECU applies the state of the next bit to the network. The state of the next bit can be the same state as the previous bit, or an alternative state to the previous bit. Each CAN message also has a header. The header includes a CAN identifier field. Some protocols include the source address of the transmitting node in the CAN identifier field. The source address (also referred to herein as the ECU identifier field) can be used to identify which ECU in the network transmitted the message. The CAN identifier field also serves as an arbitration field. The arbitration field is used to obtain control of the CAN bus. The header can also include other bits for other things. A CAN message also includes a data section.

[0024] The physical characteristics of many CAN bus systems include CAN transceivers, wiring harnesses, and other electrical characteristics including terminals, splices, and connectors. Systems with a CAN bus sometimes also have many other circuits that are typically in close proximity to the CAN bus. Thus, it is very common for electrical transients to occur on the CAN bus. Such electrical transients can include things such as signal ringing due to the characteristics of the wiring harness. Transients can also be coupled from other circuits in close proximity to the CAN bus to the CAN bus. Transients can also come from other sources. Transients often occur near the boundaries between bit periods.

[0025] Therefore, the transmitter and receiver of a CAN message must be in very precise time synchronization. This is typically achieved by based on the t in the receiving controller qThe clock is based on the time segments configured in both the transmitter and the receiver controllers, and uses local timing to accurately detect bit transitions to achieve this.

[0026] The CAN ECU typically uses a bit processing engine (BPE) to process the bits in a CAN message. When a transition in the signal is seen at or near an expected time point where a bit transition may occur, the BPE needs to determine the state of this individual bit. If the BPE samples the bit state too early after the transition (e.g., too close to the start of the bit period), it may pick up electrical noise such as ringing and misinterpret this ringing as a bit with an incorrect logic state (1 or 0). This is why the ECU has tseg1 and tseg2 registers. These register values can be used to control when the BPE samples the state of a bit.

[0027] A problem often encountered in CAN communication is the incorrect configuration of the tseg1 and tseg2 values, which results in an incorrect implementation of the sampling point. Many combinations of the tseg1 and tseg2 settings can produce a correct bit rate based on the sum of the tseg1 and tseg2 values. However, an incorrect configuration of the tseg1 and tseg2 values, although producing a correct bit rate, may also lead to a poor choice of the sampling point (placing it too early or too late in the bit period). Since the sampling point is typically inside the BPE, there is no direct means of measuring the sampling point as there is for the bit stream itself. Therefore, it may be difficult to determine whether the sampling point of the ECU is misconfigured.

[0028] To solve this problem, the CAN ECU has a built-in mechanism for detecting transmissions or detecting errors and retrying failed transmissions. Thus, when the ECU has its sampling point slightly misconfigured, the retry mechanism can mask the error or misconfiguration, causing engineers to overlook these errors during product development. This may have the risk of marginal configurations escaping into production.

[0029] Therefore, this description proceeds to determine the actual sampling point implementation in a configured ECU. By a sampling point verification and control computing system, the start of a recessive bit transmission in a CAN message is identified and a dominant value is transmitted onto the network. The behavior of the transmitting ECU is monitored to determine whether the transmitting ECU detects the dominant bit. If so, this means that a dominant bit is injected at the sampling point of the transmitting ECU. If not, the position where the dominant bit is injected within the recessive bit period is shifted, and the dominant bit injection is repeated at different positions within the bit period until the sampling point of the transmitting ECU is fully characterized.

[0030] Figure 1is a block diagram of an example of a CAN bus architecture 100. The CAN bus architecture 100 can be deployed on mobile work machines, such as self-propelled machines, agricultural machines, turf management machines, construction machines, forestry machines, and so on. In Figure 1 In the example shown in, the CAN bus architecture 100 has a plurality of different electronic control units (ECUs) 102 and 104 that are connected for communicating with each other via the CAN bus 106. Figure 1 Also shown is that a sample point verification and control computing system 108 can be connected to the ECUs 102 and 104 via the CAN bus 106. Various other items 110 can also be connected to the CAN bus 106.

[0031] In Figure 1 In the example shown in, the computing system 108 can generate a user interface 112 for interaction by a user 114. For example, the user 114 can be an engineer evaluating the performance of the ECUs 102 and 104. In one example, the user 114 interacts directly with the computing system 108 via the user interface 112. In another example, the user 114 interacts on a network 116 via the user interface 112. One or more remote systems 118 can also be connected to the architecture 100 via the network 116. Thus, the network 116 can be any one of a wide area network, a local area network, a near field communication network, a cellular communication network, or various other networks or combinations of networks.

[0032] The user interface logic 152 illustratively generates the user interface 112 and detects user interactions with those user interfaces. The user interface can be generated on a user interface mechanism, such as a screen or monitor, a touch-sensitive display screen, another visual output mechanism, an audio or tactile output mechanism, etc. The logic 152 can detect user interactions with user-actuable elements on the user interface mechanism. These elements can include icons, links, touch-sensitive buttons actuated by touch gestures, click devices, etc.

[0033] In Figure 1 In the example shown in, the ECU 102 has a bit processing executor (or BPE) 120, and it can have a variety of other ECU functions 122. The ECU 104 also has a bit processing engine (BPE) 124, and it can also have a variety of other ECU functions 126.

[0034] The bit processing executor 120 transmits and receives CAN messages via the CAN bus 106. The CAN messages can be sent for use by other ECUs. Thus, each of the BPEs 120 to 124 includes logic for transmitting, receiving, and sampling bits in the CAN messages.

[0035] In one example, the sample point verification and control computing system 108 injects a dominant pulse into a CAN message. If the system 108 injects a dominant pulse at a position within the bit length (or bit period) that does not correspond to the sample point of the transmitting ECU (e.g., the sample point of ECU 102), then ECU 102 will ignore the injected pulse and continue transmitting. However, if the system 108 injects a pulse at a position within the bit length that corresponds to the sample point of ECU 102, then ECU 102 will see that bit having a value that it did not transmit. When ECU 102 is transmitting a message and it sees a bit value that it did not transmit, then if that bit is in the arbitration field of the CAN message that it is transmitting, ECU 102 will assume that it did not win arbitration to gain control of the CAN bus 106, and it will stop transmitting. In another example, when ECU 102 sees a bit having a value that it did not transmit, and that bit is in the data field of the CAN message, ECU 102 generates a CAN error. By injecting pulses at different positions within the bit length, the system 108 can monitor the behavior of the transmitting ECU in response to the injected pulses and identify the position of the sample point of that ECU within the bit length (or bit period).

[0036] Accordingly, the sample points of ECUs 102 and 104 can be identified and visualized via the user interface 112 of the user 114. They can also be sent to the remote system 118 via the network 116. The system 108 can also determine whether the sample point of a particular ECU is in an undesirable position (such as too close to the start of the bit, or too close to the end of the bit), such that the receiving ECU might misinterpret the bit value due to ringing or other transients occurring at the start and / or end of the bit length.

[0037] Figure 2 is a block diagram that more particularly illustrates one example of the sample point verification and control computing system 108. Some of the items are similar to Figure 1 those shown in Figure 2 and they are numbered similarly. qA clock 138, a communication system 140, a sampling delay time generator 142, a dominant pulse injector 144, an ECU behavior detector 146, a sampling point characterization system 148, an output generation system 150, a user interface logic 152, and it may include various other items 154. The sampling delay time generator 142 itself may include an initial delay generator 156, a delay variation generator 158, and it may include other items 160. The ECU behavior detector 146 may include a continuous transmission detector 162, a stop transmission detector 164, a CAN error generation detector 166, and it may include other items 168. The sampling point characterization system 148 may include an ECU identifier 169, a position identifier 170, a position comparison system 171, a change identifier 172, a resolution identifier 174, and it may include other items 176. The output generation system 150 may include a position output component 178, a resolution output component 180, a configuration control output component 182, and it may include various other items 184. Before describing in more detail the operation of the sampling point verification and control computing system 108, a brief description of some items in the computing system 108 and their operations will first be provided.

[0038] t q The clock illustratively generates high-frequency clock pulses, which can be used as the timing circuit of the processor 130 or others. They are illustratively high-frequency relative to the bit length (or bit period) of the bits transmitted as part of the CAN messages on the CAN bus 106. Thus, the time quantity identified by the t q clock 138 (or it can be identified by scaling the output of the t q clock 138) can be used to identify the bit length of each bit in the CAN message. Further, they can be used to activate the tseg1 and tseg2 registers (not shown), and also for other timing functions. This will be described in detail below.

[0039] The communication system 140 illustratively allows the items in the system 108 to communicate with each other, and allows the computing system 108 to communicate through the network 116 ( Figure 1 shown in). Thus, the communication system 140 can vary based on the type of the network 116 through which it is to communicate.

[0040] The CAN message start bit detector 134 illustratively receives a CAN message and detects the start bit of the CAN message. The recessive bit detector 136 detects recessive bits transmitted as part of the CAN message. The sample delay time generator 142 generates a delay time within the bit length, and the computing system 108 waits for this delay time before it injects a dominant pulse. The initial delay generator 156 can generate an initial delay value, and the delay variation generator 158 varies the delay, as discussed in more detail below, such that the computing system 108 can identify and characterize the sampling point of the transmitting ECU of the CAN message in the transmission analysis.

[0041] After the delay identified by the sample delay time generator 142 to the detected recessive bit, the dominant pulse injector 144 injects a dominant pulse onto the CAN bus 106. Then, the ECU behavior detector 146 detects the behavior of the transmitting ECU in response to the injected dominant pulse. The continuous transmission detector 162 detects when the transmitting ECU continues to transmit (e.g., it detects that the transmitting ECU has ignored the dominant pulse, which means the dominant pulse was not injected at the sampling point of the transmitting ECU). The stop transmission detector 164 detects that the transmitting ECU has stopped transmitting in response to the injected pulse. For example, if the injected pulse is injected during the arbitration portion of a CAN message where the transmitting ECU asserts a recessive bit, the transmitting ECU will determine that it has not won the arbitration and will stop transmitting. This is detected by the detector 164. The CAN error generation detector 166 detects when the transmitting ECU generates a CAN error. For example, when a dominant pulse is injected after the arbitration cycle of a CAN message (and during the data portion), then the transmitting ECU will interpret the injected pulse (if it was injected at the sampling point) as a value different from the value it transmitted, and thus the transmitting ECU will generate a CAN error.

[0042] The sampling point characterization system 148 then characterizes the sampling point based on the behavior of the transmitting ECU in response to the injected pulse. That is, if desired, it identifies multiple characteristics of the sampling point that can be used to reconfigure the transmitting ECU to move the sampling point within the bit length. In an example where the entire ECU identifier field is received before the dominant pulse is injected, the ECU identifier 169 identifies the transmitting ECU. The position identifier 170 identifies the position of the sampling point within the bit length (in terms of a time quantity or otherwise). The position comparison system 171 compares the position of the sampling point with a desired position. The variation identifier 172 can be used to identify variations in the sampling point positions used by different ECUs on the CAN bus. The resolution identifier 174 can be used to identify the resolution of the bit length or bit period (e.g., the number of time quantities in the bit length or bit period).

[0043] Based on the characteristics of the sampling points, the output generation system 150 generates an output. For example, the position output component 178 generates an output indicating the position of the sampling point within the bit length (which can be presented on the user interface 112 for the user 114 by examining the CAN identifier field in conjunction with the identity of the transmitting ECU). The resolution output component 180 can generate an output indicating the resolution being used by the transmitting ECU, and the configuration control output component 182 can generate a control output for modifying the configuration of the transmitting ECU (e.g., increasing its resolution, reconfiguring it to move the position of the sampling point, etc.). The sampling point configuration control output component 182 can generate an output that automatically reconfigures the transmitting ECU. Automatically means that no additional manual intervention is required to perform the operation other than starting or authorizing the operation. In another example, the component 182 can generate an action signal that is output on the user interface 112 by the user interface logic 152 such that the user 114 can use this information to reconfigure the transmitting ECU.

[0044] Figure 3A and Figure 3B (Collectively referred to herein as FIG. 3) shows a flow chart that illustrates an example of the operation of the sampling point verification and control computing system 108 when identifying sampling points for a transmitting ECU and generating an output based on the characterized sampling points. First, assume that the sampling point verification and control computing system 102 is coupled to receive CAN messages from the transmitting ECU. This is indicated by block 190 in the flow chart of FIG. 3. In one example, the system 108 can be coupled to an individual ECU to verify and control its sampling points. This is indicated by block 192. In another example, the computing system 108 can be coupled to a network of connected ECUs. This is indicated by block 194. In this scenario, the computing system 108 can receive CAN messages from any one of multiple different ECUs in the network. The computing system 108 can also be connected to the ECUs in other ways. This is indicated by block 196. In this example, it will be assumed that the ECU 102 is the transmitting ECU.

[0045] Then, the CAN message start bit detector 134 detects the start bit of the CAN message that has been transmitted by the ECU 102 over the CAN bus 106. The detection of the start bit is indicated by block 198 in the flow chart of FIG. 3.

[0046] The recessive bit detector 136 then detects recessive bits in the CAN message. This is indicated by block 200 in the flowchart of FIG. 3. In one example, the recessive bit detector 136 detects the presence of the first recessive bit, regardless of its position in the CAN message. This is indicated by block 202. In another example, the recessive bit detector 136 detects recessive bits at the position in the CAN message after the ECU identifier field, which can be part of the arbitration field or a separate field of the CAN message. Detecting recessive bits after receiving the ECU identifier field is indicated by block 204 in the flowchart of FIG. 3. Recessive bits can also be detected in other ways, which is indicated by block 206.

[0047] The initial delay generator 156 outputs an initial delay period, which indicates the number of time quanta that the dominant pulse injector 144 will wait for injecting a dominant pulse within the bit length of the recessive bit. Waiting for the initial delay in the recessive bit length is indicated by block 208 in the flowchart of FIG. 3. Then, after the delay, the dominant pulse injector 144 injects a dominant pulse at the position of the recessive bit length. This is indicated by block 210 in the flowchart of FIG. 3. The width (or time length) of the dominant pulse can vary.

[0048] The ECU behavior detector 146 then detects the behavior of the transmitting ECU 102 in response to the injected dominant pulse. This is indicated by block 212. The continue transmission detector 162 detects whether the transmitting ECU 102 continues to transmit, thus indicating that it has ignored the injected pulse. This is indicated by block 214. The stop transmission detector 164 detects whether the transmitting ECU has stopped transmitting. This is indicated by block 216. This can be the case where the transmitting ECU 102 has detected the injected pulse in the arbitration field of the CAN message. The CAN error generation detector 166 detects whether the transmitting ECU 102 has generated a CAN error. This is indicated by block 218. This can be the case where the transmitting ECU 102 has detected the injected pulse in the data field part of the CAN message (or at a certain part after the arbitration field). In one example, the ECU behavior detector 146 is also capable of detecting other behaviors of the transmitting ECU 102. This is indicated by block 220.

[0049] If the ECU behavior detector 146 determines that the transmission ECU 102 has not stopped transmitting, this output indication is provided to the sampling delay time generator 142. The delay variation generator 158 then changes the delay time in the bit period in which the dominant pulse is injected, and the process returns to block 198, where the computing system 108 waits for another CAN message to be received from the transmission ECU 102 based on the changed delay output by the delay variation generator 158, and waits for the dominant pulse to be injected at different positions in the bit period. In the flowchart of FIG. 3, determining whether the transmission ECU stops transmitting in response to the injected dominant pulse is indicated by block 222. Changing the delay time using the delay variation generator 158 (when the transmission ECU 102 has ignored the injected dominant pulse) is indicated by block 224 in the flowchart of FIG. 3.

[0050] The sampling point characterization system then determines whether the sampling point has been adequately characterized. This is indicated by block 226. For example, it may be that the system only needs the ECU identifier 169 to identify the particular ECU 102 being tested (where the network of the ECU is being tested), and the position identifier 170 to identify the position of the sampling point of the identified ECU. The position of the sampling point will correspond to the delay within the bit length when the dominant pulse is injected and the transmission ECU stops transmitting. In one example, this is all the characterization that has been done - identifying the position of the sampling point for the transmission ECU 102 within the bit period.

[0051] In another example, the position comparison system 171 can also compare the position of the sampling point with a desired sampling point position (a position far enough from the start and end of the bit length to avoid damage caused by ringing or other transients). The position comparison system 171 then outputs an indication of how the position of the sampling point for the transmission ECU under test compares to the desired sampling point position.

[0052] However, the sampling point characterization system 148 can be configured to perform even further characterization of the sampling point. As an example, it may be that the system 148 will detect changes in the position of the sampling points of different ECUs on the CAN bus, or the resolution (in terms of time magnitude) being used by the transmission ECU 102. In this case, the delay variation generator 158 changes the delay to more closely identify the start and end of the bit length. For example, a dominant pulse can be injected to identify the earliest sampling point of the networked ECU, and then the delay can be changed so that a dominant pulse is injected to identify the latest sampling point of the networked ECU.

[0053] Thus, if the sample point characterization system 148 determines that more dominant pulses need to be injected to further characterize the sample point, the delay variation generator 158 changes the delay again, and the process returns to block 198, where the computing system 108 waits to receive another CAN message from the transmission ECU 102 and inject another dominant pulse. Changing the delay time to further characterize the sample point is represented by block 228 in the flowchart of FIG. 3.

[0054] In this way, the ECU identifier 169 in the sample point characterization system 148 can identify the ECU being tested. The position identifier 170 can identify the position of the sample point within the bit length. The position of the sample point can be compared with the desired sample point position by the position comparison system 171. The resolution identifier 174 can identify the resolution being used by the transmission ECU 102. The variation identifier 172 can detect or verify changes in the position of the sample point for the EUC. Any one or all of these characteristics, and / or other features, can then be provided to the output generation system 150 for generating an output based on the characterized sample point. Generating an output based on the characterized sample point is indicated by block 230 in the flowchart of FIG. 3.

[0055] The output generation system 150 can thus generate an output identifying the ECU 102 being analyzed. This is indicated by block 232.

[0056] The position output component 178 can generate an output identifying the position of the sample point of the transmission ECU 102 within the bit length. It can also generate an output indicating how this position compares with the desired position of the sample point within the bit length. This is indicated by block 234 in the flowchart of FIG. 3. The resolution output component 180 can output the resolution 236 being used by the transmission ECU 102.

[0057] The configuration change output component 182 can also generate an output to change the configuration of the transmission ECU 102. It can use the user interface logic 152 to display the proposed change on the user interface 112, where the user 114 can observe and make the configuration change to the transmission ECU 102. In another example, the component 182 can generate an output signal to automatically change the configuration of the transmission ECU 102. For example, in the case where the position of the sample point for the transmission ECU 102 is going to change within the bit length, the component 182 can generate a configuration output signal that is applied to the transmission ECU 102 via the CAN bus 106 to change its configuration. Displaying the proposed change is indicated by block 238 in the flowchart of FIG. 3.

[0058] It is possible that the sampling point characterization system 148 generates an output indicating that the sampling point is in the correct position (or is positioned within an acceptable range). In this case, the position output component 178 can generate an output verifying that the sampling point is correct or acceptable. This is indicated by block 240 in the flowchart of FIG. 3. The resolution output component 180 can generate an output indicating the resolution being used by the transmission ECU 102, and it can also generate an output signal to suggest reconfiguring the transmission ECU 102 to increase or otherwise change its resolution. The component 180 can also generate a signal to automatically reconfigure the transmission ECU 102 to change its resolution. The output for changing the resolution being used by the transmission ECU 102 is indicated by block 242. The output generation system 150 can also output a change indicator indicating a change in the position of the sampling point of the networked ECUs on the CAN bus. This is indicated by block 243. The output generation system 150 can also generate a variety of other outputs in other ways, which is indicated by block 244.

[0059] Figure 4 is a diagram showing an example of bits transmitted within a CAN message. In Figure 4 the example shown, the signal varies between voltages v0 and v1, which is represented along the y-axis. Two CAN signals, CAN_H and CAN_L, are transmitted. The dominant or recessive state is represented by the voltage difference between the CAN_H and CAN_L signals. The dominant state is represented by a larger voltage difference between CAN_H and CAN_L, while the recessive state is represented by a smaller voltage difference between CAN_H and CAN_L. The time amounts t0 to t16 are shown along the x-axis representing time. t0 marks the start of a recessive bit that is transmitted as part of the CAN message being analyzed. It can be seen that the recessive bit has a bit length (or bit period) from t0 to t16. In one example, the desired sampling point range 251 is shown from t13 to t14. This represents a portion of the bit length t0 to t16 during which the CAN signal has stabilized enough before the next transition. Thus, the bit values at points t13 to t14 are less likely to be corrupted by transients on the network.

[0060] Figure 4 An injected dominant pulse is also shown, as indicated by 250. In Figure 4In the example shown, the dominant pulse 250 is injected slightly at a position before t8 to approximately t9 within the bit length. This means that the sampling delay time generator 142 has set the time delay value from t0 to a time position slightly before t8 within the bit length t0 to t16. Assuming that the sampling point range 251 of the transmission ECU 102 corresponds to the time period t13 to t14, the transmission ECU 102 will not see the dominant pulse 250 because it is outside the sampling point range 251 for the ECU 102. In this case, the ECU 102 will continue to transmit, thus ignoring the dominant pulse 250.

[0061] However, assume that the dominant pulse 250 is injected at a time point corresponding to t13 to t14. In this case, since the transmission ECU 102 is transmitting a recessive bit and detects the dominant pulse at its sampling point, the transmission ECU 102 stops transmitting. If the bit being analyzed is in the arbitration field of the CAN message, the transmission ECU 102 assumes that it has lost arbitration and stops transmitting (or continuously transmits a recessive value). If the bit being analyzed is in the data part of the CAN message, the transmission ECU 102 stops transmitting (starts transmitting a recessive value) and generates a CAN error.

[0062] Figure 4 It is also shown how the sampling point characterization system 148 can control the computing system 108 to characterize the sampling point of the transmission ECU 102, rather than simply identifying its position. For example, if the sampling point characterization system 148 is configured to identify changes in the position of the sampling points of different ECUs, it can control the sampling delay time generator 142 and the dominant pulse injector 144 to start injecting the dominant pulse 250 at a time before t13. Then, it can increase the delay until the dominant pulse 250 is injected over the entire acceptable range t13 to t14. Conversely, it can control the sampling delay time generator 142 to increase the delay to a position after t14, and then start decreasing the delay until the dominant pulse 250 is injected over the acceptable range 251.

[0063] In this way, the change identifier 172 can control the computing system 108 such that it identifies the earliest sampling point (e.g., t13) and the latest sampling point (e.g., t14) of all ECUs on the network. Of course, these are just examples of how the sampling point characterization system 148 can control the computing system 108 to characterize the sampling point of the transmission ECU 102. It can also be done in other ways.

[0064] Thus, it can be seen that the present description is directed to systems and methods for identifying the location of sampling points used by a transmission ECU. The present description can also be used to further characterize the sampling points, such as by identifying their variations, the resolution of the transmission ECU, and other things.

[0065] The current discussion has mentioned processors and servers. In one example, the processor and server include a computer processor with associated memory and timing circuitry, which may not be shown separately. They are functional parts of the systems or devices to which they belong and are activated by other components or items in those systems and facilitate the functions of other components or items in the systems.

[0066] It should be noted that the above discussion has described various different systems, components, and / or logics. It should be understood that such systems, components, and / or logics can be constituted by hardware items (such as processors and associated memory, or other processing components, some of which will be described below) that perform the functions associated with those systems, components, and / or logics. In addition, the systems, components, and / or logics can be constituted by software sets loaded into the memory and subsequently executed by a processor or server or other computing components, as described below. The systems, components, and / or logics can also be constituted by different combinations of hardware, software, firmware, etc., some examples of which are described below. These are just some examples of the different structures that can be used to form the systems, components, and / or logics described above. Other structures can also be used.

[0067] Moreover, many user interface displays have been discussed. They can take various different forms and can have various different user-actuable input mechanisms provided thereon. For example, the user-actuable input mechanism can be a text box, a checkbox, an icon, a link, a drop-down menu, a search box, etc. They can also be actuated in various different ways. For example, a pointing device (such as a trackball or a mouse) can be used to actuate them. They can be actuated using hardware buttons, switches, joysticks, or keyboards, thumb switches, or thumb pads. Virtual keyboards or other virtual actuators can also be used to actuate them. In addition, in the case where the screen on which they are displayed is a touch-sensitive screen, touch gestures can be used to actuate them. Moreover, in the case where the device displaying them has a voice recognition component, voice commands can be used to actuate them.

[0068] Some data storage devices have also been discussed. It should be noted that they can each be divided into multiple data storage devices. All the data storage devices can be local to the systems accessing them, all can be remote, or some can be local while others are remote. All these configurations are considered herein.

[0069] Moreover, the figures show a number of blocks, where functions are attributed to each block. It should be noted that fewer blocks can be used, so that functions are performed by fewer components. Moreover, more blocks can be used with functions distributed among more components.

[0070] Figure 5 is Figure 1 a block diagram of the architecture 100 shown in, except that it communicates with elements in the remote server architecture 500. In an example, the remote server architecture 500 can provide computing, software, data access, and storage services, which do not require an end user to know the physical location or configuration of the system delivering the services. In various examples, the remote server can deliver services over a wide area network (such as the Internet) using appropriate protocols. For example, the remote server can deliver applications over the wide area network and can be accessed through a web browser or any other computing component. Figure 1 The software or components shown in and the corresponding data can be stored on a server at a remote location. The computing resources in the remote server environment can be consolidated at a remote data center location, or they can also be dispersed. The remote server infrastructure can deliver services through a shared data center, even though they appear to the user as a single access point. Thus, the components and functions described herein can be provided from a remote server at a remote location using the remote server architecture. Alternatively, they can be provided from a conventional server, or they can be installed directly on a client device, or installed in some other way.

[0071] In Figure 5 the example shown in, some items are similar to Figure 1 and Figure 2 the items shown in, and they are numbered similarly. Figure 5 Specifically, it is shown that the sampling point characterization system 148 or other items from the architecture 100 can be located at the remote server location 502. Thus, the system 108 accesses those systems through the remote server location 502.

[0072] Figure 5 Another example of the remote server architecture is also depicted. Figure 5 It is shown that it is also conceivable that Figure 1 and Figure 2Some components are arranged at the remote server location 502, while other components are not. As an example, the data storage device 132 or the remote system 118 can be located at a location separate from the location 502 and accessed through the remote server at the location 502. Regardless of where they are located, they can be directly accessed by the architecture 100 through a network (wide area network or local area network), they can be hosted by a server at a remote site, or they can be provided as a server, or accessed by a connection server residing at a remote location. Moreover, the data can be stored at substantially any location and intermittently accessed by interested parties or forwarded to interested parties. All of these architectures are considered herein.

[0073] It should also be noted that Figure 1 and Figure 2 the components of or parts of them can be arranged on various different devices. Some of these devices include servers, desktop computers, laptop computers, tablet computers, or other mobile devices such as palmtop computers, mobile phones, smartphones, multimedia players, personal digital assistants, etc.

[0074] Figure 6 is an example of a computing environment in which Figure 1 and Figure 2 the components of or a part of them (for example) can be deployed. Referring to Figure 6 , an example system for implementing some embodiments includes a computing device in the form of a computer 810, which is programmed to operate as described herein. The components of the computer 810 can include, but are not limited to, a processing unit 820 (which can include (one or more) processors 130), a system memory 830, and a system bus 821 that couples various system components including the system memory to the processing unit 820. The system bus 821 can be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of various bus architectures. Referring to Figure 1 and Figure 2 the memory and programs described can be deployed in Figure 6 the corresponding parts of

[0075] Computer 810 generally includes various computer-readable media. The computer-readable media can be any available media accessible by computer 810 and includes volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, the computer-readable media can include computer storage media and communication media. Computer storage media is different from, and does not include, modulated data signals or carrier waves. It includes hardware storage media, including volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other media that can be used to store the desired information and can be accessed by computer 810. Communication media can contain computer-readable instructions, data structures, program modules, or other data in a transmission mechanism and includes any information delivery media. The term "modulated data signal" means that one or more characteristics of the signal are set or changed to encode information in the signal.

[0076] System memory 830 includes computer storage media in the form of volatile and / or non-volatile memory, such as read only memory (ROM) 831 and random access memory (RAM) 832. The basic input / output system 833 (BIOS) (containing basic routines such as those that help transfer information between components within computer 810 during startup) is typically stored in ROM 831. RAM 832 typically contains data and / or program modules that can be immediately accessed by processing unit 820 and / or are currently being operated on by the processing unit. By way of example and not limitation, Figure 6 an operating system 834, application programs 835, other program modules 836, and program data 837 are shown.

[0077] Computer 810 may also include other removable / non-removable, volatile / non-volatile computer storage media. By way of example only, Figure 6Shown are a hard disk drive 841, an optical disk drive 855, and a non-volatile optical disk 856 that read from and write to a non-removable, non-volatile magnetic medium. The hard disk drive 841 is typically connected to the system bus 821 through a non-removable memory interface such as interface 840, and the optical disk drive 855 is typically connected to the system bus 821 through a removable memory interface such as interface 850.

[0078] Alternatively or in addition, the functions described herein may be performed, at least in part, by one or more hardware logic components. By way of example, and not limitation, illustrative types of hardware logic components that may be used include Field-programmable Gate Array (FPGA), Application Specific Integrated Circuit (e.g., ASIC), Application Specific Standard Product (e.g., ASSP), System-on-a-chip system (SOC), Complex Programmable Logic Device (CPLD), and the like.

[0079] The drives discussed above and shown in Figure 6 provide storage of computer-readable instructions, data structures, program modules, and other data for the computer 810. For example, in Figure 6 , the hard disk drive 841 is shown storing an operating system 844, application programs 845, other program modules 846, and program data 847. Note that these components may be the same as or different from the operating system 834, application programs 835, other program modules 836, and program data 837.

[0080] A user may enter commands and information into the computer 810 through input devices such as a keyboard 862, a microphone 863, and an indicating device 861 (such as a mouse, trackball, or touchpad). Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, etc. These and other input devices are typically connected to the processing unit 820 through a user input interface 860 coupled to the system bus, but may also be connected through other interfaces and bus structures. A visual display 891 or other type of display device is also connected to the system bus 821 through an interface such as a video interface 890. In addition to a monitor, the computer may also include other peripheral output devices that may be connected through an output peripheral interface 895, such as a speaker 897 and a printer 896.

[0081] The computer 810 operates in a networked environment using a logical connection (such as Controller Area Network - CAN, Local Area Network - LAN, or Wide Area Network WAN) to one or more remote computers, such as remote computer 880.

[0082] When used in a LAN networked environment, the computer 810 is connected to the LAN 871 through a network interface or adapter 870. When used in a WAN networked environment, the computer 810 typically includes a modem 872 or other means for establishing communication through the WAN 873 (such as the Internet). In a networked environment, program modules can be stored in a remote memory storage device. Figure 6 For example, it is shown that the remote application 885 can reside on the remote computer 880.

[0083] It should also be noted that the different embodiments described herein can be combined in different ways. That is, parts of one or more embodiments can be combined with parts of one or more other embodiments. All of these are considered herein.

[0084] Example 1 is a computer - implemented method, including:

[0085] Receiving a CAN message from a transmission electronic control unit (ECU) via a Controller Area Network (CAN) bus;

[0086] Detecting recessive bits with a recessive bit length in the CAN message;

[0087] Injecting a dominant pulse onto the CAN bus after a delay time within the bit length;

[0088] Detecting the behavior of the transmission ECU after injecting the dominant pulse;

[0089] Characterizing the sampling point of the transmission ECU based on the delay time and the detected behavior of the transmission ECU to obtain a sampling point feature; and

[0090] Generating a control signal based on the sampling point feature.

[0091] Example 2 is a computer - implemented method of any or all of the foregoing examples, wherein detecting the behavior of the transmission ECU includes:

[0092] Determining whether the transmission ECU stops transmitting CAN messages in response to the injection of the dominant pulse.

[0093] Example 3 is a computer - implemented method of any or all of the foregoing examples, wherein characterizing the sampling point of the transmission ECU includes:

[0094] If the transmitting ECU stops transmitting CAN messages in response to the injection of a dominant pulse, the position of the sampling point of the transmitting ECU within the recessive bit length is identified based on the delay time within the recessive bit length.

[0095] Example 4 is a computer-implemented method of any or all of the foregoing examples, wherein characterizing the sampling point of the transmitting ECU includes:

[0096] If the transmitting ECU does not stop transmitting CAN messages in response to the injection of a dominant pulse, then:

[0097] Changing the delay time to a different delay time;

[0098] Receiving different CAN messages from the transmitting ECU;

[0099] Detecting recessive bits having a recessive bit length in the different CAN messages;

[0100] Injecting a dominant pulse into the CAN bus after different delay times within the recessive bit length;

[0101] Detecting the behavior of the transmitting ECU after injecting the dominant pulse; and

[0102] Characterizing the sampling point of the transmitting ECU based on the different delay times and the detected behavior of the transmitting ECU to obtain a sampling point characteristic.

[0103] Example 5 is a computer-implemented method of any or all of the foregoing examples, wherein characterizing the sampling point of the transmitting ECU includes:

[0104] If the transmitting ECU does not stop transmitting CAN messages in response to the injection of a dominant pulse, then:

[0105] Repeating the following steps: changing the delay time to obtain different delay times; detecting recessive bits in different CAN messages; and injecting a dominant pulse during the recessive bit after different delay times until the transmitting ECU stops transmitting CAN messages in response to the injection of the dominant pulse; and

[0106] Identifying the position of the sampling point for the transmitting ECU within the recessive bit length based on the value of the delay time when the transmitting ECU stops transmitting CAN messages in response to the injection of the dominant pulse.

[0107] Example 6 is a computer-implemented method of any or all of the foregoing examples, wherein the CAN message includes an ECU identifier portion and a data portion identifying the transmitting ECU, and wherein detecting the recessive bit includes:

[0108] Detecting a recessive bit after the ECU identifier portion of the CAN message.

[0109] Example 7 is a computer-implemented method of any or all of the foregoing examples, wherein the transmission ECU is on a network including another ECU, and wherein the sample points characterizing the transmission ECU include:

[0110] Identifying the transmission ECU based on the ECU identifier portion of a CAN message.

[0111] Example 8 is a computer-implemented method of any or all of the foregoing examples, wherein detecting the behavior of the transmission ECU includes:

[0112] Detecting that the transmission ECU generates a CAN error in response to the injection of a dominant pulse.

[0113] Example 9 is a computer-implemented method of any or all of the foregoing examples, wherein generating a control signal includes:

[0114] Generating an interface control signal to display on a user interface the characteristics of the sample points for the transmission ECU.

[0115] Example 10 is a computer-implemented method of any or all of the foregoing examples, wherein generating a control signal includes:

[0116] Generating a control signal to automatically reconfigure the transmission ECU so as to move the sample points of the transmission ECU to different positions within the recessive bit length.

[0117] Example 11 is a computer-implemented method of any or all of the foregoing examples, wherein injecting a dominant pulse includes injecting a dominant pulse into the recessive bits of a plurality of different CAN messages from the transmission ECU, each dominant pulse being injected at a different delay time, and wherein characterizing the sample points includes:

[0118] Identifying the position of the sample points within the recessive bit length, and identifying the change in the position of the sample points of the user transmission ECU relative to the position of the sample points of another ECU on the network.

[0119] Example 12 is a computing system, including:

[0120] A recessive bit detector that detects recessive bits having a recessive bit length in CAN messages transmitted by a transmission electronic control unit (ECU) over a CAN bus;

[0121] A dominant pulse injector that injects a dominant pulse onto the CAN bus within the recessive bit length and after a delay time;

[0122] An ECU behavior detector that detects the behavior of the transmission ECU after injecting the dominant pulse;

[0123] Sampling point characterization system, which characterizes the sampling points of the transmission ECU based on the delay time and the detected behavior of the transmission ECU to obtain sampling point characteristics; and

[0124] Output generation system, which generates a control signal based on the sampling point characteristics.

[0125] Example 13 is a computing system of any or all of the foregoing examples, wherein the ECU behavior detector includes:

[0126] Stop transmission detector, which detects whether the transmission ECU stops transmitting CAN messages in response to the injection of a dominant pulse.

[0127] Example 14 is a computing system of any or all of the foregoing examples, wherein the sampling point characterization system includes:

[0128] Position identifier, which is configured to: if the transmission ECU stops transmitting CAN messages in response to the injection of a dominant pulse, identify the position of the sampling point of the transmission ECU within the recessive bit length based on the delay time within the recessive bit length.

[0129] Example 15 is a computing system of any or all of the foregoing examples, wherein the CAN message includes an ECU identifier part and a data part that identify the transmission ECU, and wherein the recessive bit detector is configured to detect the recessive bit after the ECU identifier part of the CAN message.

[0130] Example 16 is a computing system of any or all of the foregoing examples, wherein the transmission ECU is on a network including another ECU, and wherein the sampling point characterization system includes:

[0131] ECU identifier, which identifies the transmission ECU based on the ECU identifier part of the CAN message.

[0132] Example 17 is a computing system of any or all of the foregoing examples, wherein the ECU behavior detector includes:

[0133] CAN error generation detector, which detects that the transmission ECU generates a CAN error in response to the injection of a dominant pulse.

[0134] Example 18 is a computing system of any or all of the foregoing examples, wherein the output generation system includes:

[0135] Configuration change output component, which generates a control signal to automatically reconfigure the transmission ECU so as to move the sampling point of the transmission ECU to a different position within the recessive bit length.

[0136] Example 19 is a computer-implemented method, including:

[0137] Receiving a CAN message from a transmission electronic control unit (ECU) via a Controller Area Network (CAN) bus;

[0138] Detecting a recessive bit with a recessive bit length in the CAN message;

[0139] Injecting a dominant pulse onto the CAN bus after a delay time within the recessive bit length;

[0140] Determining whether the transmission ECU stops transmitting CAN messages in response to the injection of the dominant pulse;

[0141] If the transmission ECU stops transmitting CAN messages in response to the injection of the dominant pulse, then based on the delay time within the recessive bit length, identifying the position of the sampling point that identifies the transmission ECU within the recessive bit length; and

[0142] Generating a control signal based on the position of the sampling point.

[0143] Example 20 is a computer-implemented method of any or all of the foregoing examples, and further includes if the transmission ECU does not stop transmitting CAN messages in response to the injection of the dominant pulse, then:

[0144] Repeating the following steps: changing the delay time to obtain different delay times; detecting recessive bits in different CAN messages; and injecting dominant pulses during the recessive bits after different delay times until the transmission ECU stops transmitting CAN messages in response to the injection of the dominant pulse; and

[0145] Identifying the position of the sampling point for the transmission ECU in the recessive bit length based on the value of the delay time when the transmission ECU stops transmitting CAN messages in response to the injection of the dominant pulse.

[0146] Although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims need not be limited to the specific features or acts described above. On the contrary, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A computer-implemented method, comprising: Receiving a CAN message from a transmission electronic control unit (ECU) via a Controller Area Network (CAN) bus; Detecting a recessive bit having a recessive bit length in the CAN message; Injecting a dominant pulse onto the CAN bus after a delay time within the recessive bit length; Detecting the behavior of the transmission ECU after injecting the dominant pulse; Characterizing the sampling point of the transmission ECU based on the delay time and the detected behavior of the transmission ECU to obtain a sampling point feature; And Generating a control signal based on the sampling point feature.

2. The computer-implemented method according to claim 1, wherein, Detecting the behavior of the transmission ECU includes: Determining whether the transmission ECU stops transmitting the CAN message in response to the injection of the dominant pulse.

3. The computer-implemented method according to claim 2, wherein, Characterizing the sampling point of the transmission ECU includes: If the transmission ECU stops transmitting the CAN message in response to the injection of the dominant pulse, identifying the position of the sampling point of the transmission ECU within the recessive bit length based on the delay time within the recessive bit length.

4. The computer-implemented method according to claim 3, wherein, Characterizing the sampling point of the transmission ECU includes: If the transmission ECU does not stop transmitting the CAN message in response to the injection of the dominant pulse, then: Changing the delay time to a different delay time; Receiving a different CAN message from the transmission ECU; Detecting a recessive bit having a recessive bit length in the different CAN message; Injecting a dominant pulse onto the CAN bus after the different delay time within the recessive bit length; Detecting the behavior of the transmission ECU after injecting the dominant pulse; and Characterizing the sampling point of the transmission ECU based on the different delay time and the detected behavior of the transmission ECU to obtain the sampling point feature.

5. The computer-implemented method according to claim 3, wherein, Characterizing the sampling point of the transmission ECU includes: If the transmission ECU does not stop transmitting the CAN message in response to the injection of the dominant pulse, then: Repeating the following steps: changing the delay time to obtain different delay times; detecting recessive bits in different CAN messages; and injecting the dominant pulse during the recessive bit after the different delay times until the transmission ECU stops transmitting the CAN message in response to the injection of the dominant pulse; and Identifying the position of the sampling point for the transmission ECU in the recessive bit length based on the value of the delay time when the transmission ECU stops transmitting the CAN message in response to the injection of the dominant pulse.

6. The computer-implemented method according to claim 1, wherein, The CAN message includes an ECU identifier part and a data part, the ECU identifier part identifies the transmission ECU, and wherein detecting the recessive bit includes: Detecting the recessive bit after the ECU identifier part of the CAN message.

7. The computer-implemented method according to claim 6, wherein, The transmission ECU is on a network including another ECU, and wherein, characterizing the sampling point of the transmission ECU includes: Identifying the transmission ECU based on the ECU identifier part of the CAN message.

8. The computer-implemented method according to claim 1, wherein, Detecting the behavior of the transmission ECU includes: Detect that the transmission ECU generates a CAN error in response to the injection of the dominant pulse.

9. A computing system, comprising: A recessive bit detector that detects recessive bits having a recessive bit length in a CAN message transmitted by a transmission electronic control unit (ECU) via a CAN bus; A dominant pulse injector that injects a dominant pulse into the CAN bus after a delay time within the recessive bit length; An ECU behavior detector that detects the behavior of the transmission ECU after injecting the dominant pulse; A sampling point characterization system that characterizes the sampling point of the transmission ECU based on the delay time and the detected behavior of the transmission ECU to obtain a sampling point feature; And An output generation system that generates a control signal based on the sampling point feature.

10. A computer-implemented method, comprising: Receiving a CAN message from a transmission electronic control unit (ECU) via a controller area network (CAN) bus; Detecting a recessive bit having a recessive bit length in the CAN message; Injecting a dominant pulse into the CAN bus after a delay time within the recessive bit length; Determining whether the transmission ECU stops transmitting the CAN message in response to the injection of the dominant pulse; If the transmission ECU stops transmitting the CAN message in response to the injection of the dominant pulse, then identifying the position of the sampling point of the transmission ECU within the recessive bit length based on the delay time within the recessive bit length; and Generating a control signal based on the position of the sampling point.

Images