CAN data update method and electronic control unit

Abstract

This invention provides a CAN data update method and an electronic control device that suppress delays in CAN (Controller Area Network) data update time in a software sharing system. [Solution] A method for updating CAN data by a second electronic control unit 20, in which the second electronic control unit 20 receives CAN data from the first electronic control unit 10 via the CAN bus 40 and controls the drive of the controlled object 30 based on control data used to drive the controlled object 30 contained in the CAN data, wherein the number of software processes executed at predetermined execution cycles from the reception of CAN data to the execution of drive control for the controlled object 30 is N, and the execution cycle of the CAN data transmission process by the CAN bus 40 is T CA In this case, the execution period of each of the N software processes is defined as execution period T. CA By setting the value obtained by dividing by N, delays in CAN data update time are suppressed.

Description

[Technical Field]

[0001] This invention relates to a CAN (Controller Area Network) communication method, one of the data communication methods used in automated vehicles, and to an electronic control device for updating CAN data, particularly one that aims to improve reliability by suppressing and reducing delays in CAN data update time. [Background technology]

[0002] It is well known that so-called CAN communication is used as a means of transmitting and receiving various types of data between multiple electronic control devices installed in a vehicle (see, for example, Patent Document 1). Figures 8 and 9 show schematic diagrams illustrating the basic procedures for transmitting and receiving CAN data in such CAN communication. The following will provide an overview of the CAN data transmission and reception procedures with reference to these figures. Figures 8 and 9 both show the first electronic control unit (ECU) that outputs CAN data via the CAN bus. TX The second electronic control unit (ECU) receives the CAN data. RX This is a schematic diagram illustrating the approximate timing of CAN data transmission and reception between the two devices.

[0003] First, in Figures 8 and 9, “SW AX "This conveniently refers to software processing that generates control data to drive and control a controlled object, such as an electric mirror on a vehicle. BX " is software processing SW AX This diagram conveniently shows the software processing necessary to transmit the control data generated as CAN data. Furthermore, "SW CX " receives CAN data via the CAN bus and the first electronic control unit (ECU) TX This shows, for convenience, the software processing that performs demodulation of control data. Furthermore, "SW DX " is software processing SWCX This shows a software process that generates and outputs signals and the like necessary to actually drive a control target based on the demodulated control data for the sake of convenience.

[0004] The forms of constructing these software processes can be roughly divided into two types. That is, a so-called non-software sharing system that is all constructed based on a unified design concept, design criteria, etc. by the same designer or the same company, etc., and a so-called software sharing system that is separately constructed by different designers or different companies, etc.

[0005] FIG. 8 schematically shows a basic example of the transmission and reception process of CAN data in the above-mentioned non-software sharing system, and FIG. 9 schematically shows a basic example of the transmission and reception process of CAN data in the above-mentioned software sharing system. First, while referring to FIG. 8, the transmission and reception process of CAN data in the non-software sharing system will be described. In the first electronic control unit ECU of FIG. 8 TX The part where the diamond-shaped figure is marked indicates the point when the generation of required data is completed in the software process SW AX Also, in the same figure, the part where the triangular figure is marked indicates the point when the output of CAN data to the CAN bus is completed in the software process SW BX The time Δ1 from the completion of the execution of this software process SW

[0006] This software process SW AX to the completion of the execution of the software process SW BX is usually maximally optimized in a non-software sharing system. This is because the two software processes SW AX , SW BX are constructed by the same designer or the like as described above, so it is possible to construct software processes considering the characteristics of each process.

[0007] Furthermore, in Figure 8, the second electronic control unit (ECU) RX The area where the trapezoidal shape is indicated is the software processing SW CX This indicates the point at which the required CAN data reception processing is completed. Furthermore, the second electronic control unit (ECU) RX The area where the square shape is indicated is the software processing SW DX This indicates the point in time when the required control processing for the controlled object has been completed. And then, software processing SW CX From the completion of execution, the software processing SW DX The time Δ2 until the completion of the execution can be optimized to the maximum extent for the same reasons as in the case of Δ1.

[0008] In such non-software sharing systems, the execution cycle of each process is the same, i.e., T AX =T BX =T CX =T DX =T CT It is common practice to set it this way. Here, T AX Software processing SW AX The period during which this is performed is T BX Software processing SW BX The period during which this is performed is T CX Software processing SW CX The period during which this is performed is T DX Software processing SW DX The period during which this is performed is T CT (Hereafter referred to as "CAN data transmission cycle" for convenience of explanation) refers to the cycle in which CAN data transmission via the CAN bus is performed.

[0009] Furthermore, in non-software sharing systems, software processing SW AX From the point when the processing is complete, the software processing SW DX The data update time Tdu, which is the time until the processing is completed, satisfies Equation 1 below, and each software process is constructed such that Δ1 and Δ2 satisfy Equation 2 below, thereby reducing the CAN data update delay time TUD The maximum CAN data transmission period T CT It becomes possible to keep it within twice that amount.

[0010] 0 <Tdu≦2×T CT ...Formula 1

[0011] 0 < Δ1, Δ2 < 0.5 × T CT ...Formula 2

[0012] Here, Equation 1 gives the data update time Tdu as the CAN data transmission period T. CT This indicates that it should be within twice that amount. Furthermore, Equation 2 expresses Δ1 and Δ2 as the CAN data transmission period T. CT This indicates that it should be within half the time. Thus, the data update time Tdu is defined as the CAN data transmission period T. CT Keeping it within twice the limit is an important factor in ensuring the real-time nature of the series of control operations. [Prior art documents] [Patent Documents]

[0013] [Patent Document 1] Japanese Patent Publication No. 2023-8113 [Overview of the project] [Problems that the invention aims to solve]

[0014] However, software processing SW AX ~SW DX When this is built as a software sharing system, there is a problem in that the reliability of ensuring real-time control operations tends to decrease, unlike in the non-software sharing system described above. In other words, first, the software processing SW AX ~SW DX If it is built as a software sharing system, then, as with non-software sharing systems, the execution cycle of each process will be the same, i.e., TAX =T BX =T CX =T DX =T CT It is possible to set it that way. However, in the case of a software sharing system, it is not possible to optimize the processing times Δ1 and Δ2 as in the non-software sharing system mentioned above.

[0015] Therefore, due to timing differences in the execution of each software process, the data update time Tdu is affected by the CAN data transmission period T, as shown in Figure 9. CT It can exceed twice that. Furthermore, in the worst case, the data update time Tdu may exceed the CAN data transmission period T CT The cost could be up to three times higher, and it has problems in terms of reliability and other aspects compared to non-software sharing systems.

[0016] The present invention has been made in view of the above circumstances, and provides a CAN data update method and an electronic control device that can suppress and reduce delays in CAN data update time in a software sharing system. [Means for solving the problem]

[0017] To achieve the above-mentioned objectives of the present invention, the CAN data update method according to the present invention is: A method for updating CAN data by an electronic control device (20) that receives CAN data from a CAN bus (40) and controls the driving of a controlled object (30) based on control data used to drive the controlled object (30) contained in the CAN data, wherein the electronic control device (20) is capable of controlling the driving of the controlled object (30), The number of software processes executed at predetermined execution cycles from the reception of the CAN data to the execution of drive control for the controlled object (30) is N, and the execution cycle of the CAN data transmission process by the CAN bus (40) is T. CA In this case, the execution period of each of the N software processes is defined as the execution period T. CA The system is configured to set the value obtained by dividing by N. Furthermore, in order to achieve the above-mentioned objectives of the present invention, the electronic control device according to the present invention is An electronic control unit (20) including a CPU that receives CAN data from a CAN bus (40) and controls the driving of a controlled object (30) based on control data used to drive the controlled object (30) contained in said CAN data, The CPU is capable of executing N software processes, each having a predetermined execution period, between receiving the CAN data and performing drive control on the controlled object (30). The execution cycle of each of the N software processes is the execution cycle T of the CAN data transmission process by the CAN bus (40). CA This is set to the value obtained by dividing it by the aforementioned N. [Effects of the Invention]

[0018] According to the present invention, the sum of the execution cycles of each software process from CAN data reception to drive control is kept within a range that does not exceed the CAN data transmission and reception cycle, and the system is configured to check for the presence or absence of CAN data reception at predetermined time intervals and to execute software processing based on the results of that check. This makes it possible to suppress and reduce the CAN data update delay to a range of at most about two cycles of the CAN data transmission and reception cycle, thereby improving the stability and reliability of the overall operation of the device. [Brief explanation of the drawing]

[0019] [Figure 1] This is a configuration diagram showing an example of the configuration of an electronic control device to which the CAN data update method according to an embodiment of the present invention is applied. [Figure 2] This flowchart shows the procedure for the CAN data update pre-processing that constitutes the CAN data update process in the first configuration example of the CAN data update process in an embodiment of the present invention. [Figure 3] This flowchart shows the procedure for the post-CAN data update processing that constitutes the CAN data update processing in the first configuration example of the CAN data update processing in an embodiment of the present invention. [Figure 4] This is a schematic diagram illustrating the timing of CAN data updates during the execution of the CAN data update process in an embodiment of the present invention. [Figure 5] This is a schematic diagram illustrating a general configuration example of a dual-core CPU used in an electronic control device that performs CAN data update processing according to an embodiment of the present invention, where the CPU is a dual-core CPU. [Figure 6] This flowchart shows the procedure for the CAN data update pre-processing that constitutes the CAN data update process in a second configuration example of the CAN data update process according to an embodiment of the present invention. [Figure 7] This flowchart shows the procedure for the post-CAN data update processing that constitutes the CAN data update processing in a second configuration example of the CAN data update processing according to an embodiment of the present invention. [Figure 8] This is a schematic diagram illustrating the timing of conventional CAN data updates in non-software sharing systems. [Figure 9] This is a schematic diagram illustrating the timing of conventional CAN data updates in a software sharing system. [Modes for carrying out the invention]

[0020] Hereinafter, embodiments of the present invention will be described with reference to Figures 1 to 7. The components, arrangements, etc., described below are not intended to limit the present invention and can be modified in various ways within the scope of the spirit of the present invention. First, an example of the configuration of an electronic control unit to which the CAN (Controller Area Network) data update method according to an embodiment of the present invention is applied will be described with reference to Figure 1. Figure 1 shows a basic example of the configuration of an electronic control unit in an automated vehicle that uses CAN communication. This example will be explained below with reference to the same figure. Typically, an automated vehicle contains multiple electronic control units, each primarily composed of an electronic control unit, configured to perform desired electronic control processing. Some of these electronic control units require the exchange of data with each other, and in such cases, the necessary data is sent and received via, for example, CAN communication.

[0021] Figure 1 shows a minimal configuration example of an electronic control unit that performs CAN communication as described above. In other words, Figure 1 shows the first electronic control unit (referred to as "ECU" in Figure 1) that generates and outputs CAN data. T The first electronic control unit 10 is referred to as "ECU" (in Figure 1, "ECU") 10, and the second electronic control unit (in Figure 1, "ECU") receives the CAN data output by the first electronic control unit 10 via the CAN bus 40. R An example configuration is shown in which (notation) 20 and are provided. The first electronic control unit 10 is configured to generate control data necessary for driving an actuator (indicated as "AC" in Figure 1) 30 that drives, for example, an electric mirror, and to output it as CAN data.

[0022] Furthermore, the second electronic control unit 20 is configured to be able to perform drive control of the actuator 30 based on CAN data received via the CAN bus 40. These first electronic control unit 10 and second electronic control unit 20 are, as is well known, configured primarily around a microcomputer (hereinafter referred to as "CPU" for convenience of explanation) having a publicly known configuration, and are equipped with memory elements such as RAM and ROM (not shown), as well as input / output interface circuits (not shown).

[0023] In the first electronic control unit 10, at least, there is a first software process (indicated as "SW" in Figure 1) which generates control data necessary for driving the actuator 30 based on required sensor signals, etc. (indicated as "SIG1" in Figure 1). A11 is a software process that transmits the control data generated by the first software process 11 as CAN data (in Figure 1, this is referred to as "SW") 11, and the second software process is a software that performs the process of transmitting the control data generated by the first software process 11 as CAN data. B (This is written as ")12 and are executed respectively.

[0024] Furthermore, the second electronic control unit 20 includes at least a third software processing (in Figure 1, "SW") C (indicated as "SW") 13 and the fourth software process (in Figure 1, "SW") D (This is written as ") 14 and are executed respectively. Here, the third software processing (CAN data reception software processing) 13 is software that receives CAN data from the CAN bus 40 and performs processing such as demodulation and extraction of control data necessary for driving the actuator 30. Furthermore, the fourth software processing (drive software processing) 14 is software that performs drive control of the actuator 30 based on the control data obtained by the third software processing 13 and the necessary sensor signals etc. (indicated as "SIG2" in Figure 1) input from the outside. Regarding the transmission and reception of CAN data via the CAN bus 40, the process remains the same as before, so a detailed explanation will be omitted here.

[0025] Next, with reference to Figures 2 to 4, a first configuration example of the CAN data update method in an embodiment of the present invention will be described. First, the CAN data update method in the embodiment of the present invention is applied to the CAN data receiving device, that is, in the configuration example shown in Figure 1, to the second electronic control unit 20 and executed as a CAN data update process. The CAN data update process in the first configuration example is particularly suitable for a software sharing system. Specifically, the CAN data update process in the first configuration example assumes that the third software process 13 and the fourth software process 14 in the second electronic control unit 20 are designed and created by separate manufacturers, and that the execution timing of each process is asynchronous.

[0026] Furthermore, it is assumed that the first software process 11 to the fourth software process 14 are all executed periodically and repeatedly. In addition, it is assumed that the transmission and reception of CAN data on the CAN bus 40 are also performed periodically and repeatedly. Here, the execution period of the first software process 11 is defined as T, which is the period during which each software process is executed repeatedly (hereinafter referred to as the "execution period" for the sake of explanation). A The execution cycle of the second software process 12 is set to T B The execution cycle of the third software process 13 is set to T C The execution cycle of the fourth software process 14 is set to T D Furthermore, the execution cycle of the CAN data transmission process on the CAN bus 40 is set to T. CA This is how it is defined.

[0027] Next, the execution cycle described above will be explained with reference to the schematic diagram shown in Figure 4. Figure 4 is a schematic diagram illustrating the timing of CAN data transmission and reception during the CAN data update process, and its general outline is explained here. In Figure 4, the diamond shapes indicate the completion time of the first software process 11, and the time interval between adjacent diamond shapes corresponds to the execution period T mentioned earlier. A It is equivalent to this. Furthermore, in Figure 4, the locations marked with triangles indicate the point in time when the execution of the second software process 12 is completed, and the time interval between adjacent triangles corresponds to the execution period T mentioned earlier. B It is equivalent to this.

[0028] Furthermore, in Figure 4, the locations marked with circles indicate the point in time when the transmission of CAN data by the CAN bus 40 is completed, and the time interval between adjacent circles corresponds to the execution period T mentioned earlier. CA It is equivalent to this. Furthermore, in Figure 4, the areas marked with trapezoidal shapes indicate the completion time of the third software process 13, and the time interval between adjacent trapezoidal shapes corresponds to the execution period T mentioned earlier. C It is equivalent to this. The square shapes indicate the completion time of the fourth software process 14, and the time interval between adjacent square shapes corresponds to the execution period T mentioned earlier. D It is equivalent to this.

[0029] In this embodiment, the first configuration example provides two prerequisites necessary for applying the CAN data update process. One of these two prerequisites is the execution cycle T of the first software process 11 in the first electronic control unit 10. A Then, the execution period T of the second software process 12 B The execution cycle T of the CAN data transmission process in the CAN bus 40. CA The condition is that both are identical. That is, T A =T B =T CA It is set to this.

[0030] Furthermore, the other of the two preconditions is that in the second electronic control unit 20, the execution period T of the third software process 13 is... C The execution period T of the fourth software process 14. D However, both have an execution cycle T for the CAN data transmission process on the CAN bus 40. CA The condition is that it is half of T. C =T D = 0.5 × T CA It is set to this.

[0031] Under the two preconditions described above, the CAN data update process in this first configuration example consists of a CAN data update pre-processing step performed before and after the execution of the third software process 13, and a CAN data update post-processing step performed before the execution of the fourth software process 14, as described below. Figure 2 shows a flowchart illustrating the pre-CAN data update processing procedure for the CAN data update process that takes place before and after the execution of the third software process 13. The details will be explained below with reference to this figure. When processing is started by a CPU (not shown), the first step, S110, is to perform an adjustment time elapsed determination. That is, it is determined whether a predetermined adjustment time has elapsed since the start of processing. This predetermined adjustment time is the execution cycle T of the CAN data transmission process on the CAN bus 40. CA Half the time of (hereinafter referred to as the "CAN data transmission cycle" for the sake of explanation), i.e., 0.5 × T CA It is preferable to set it as such.

[0032] In step S110, if the CPU (not shown) determines YES, i.e., that the predetermined adjustment time has elapsed, the process proceeds to step 120, which will be described next. On the other hand, if the CPU determines NO, i.e., that the predetermined adjustment time has not elapsed, step S110 will continue until it is determined that the predetermined adjustment time has elapsed. In step S110, once it is determined that the predetermined time has elapsed, the predetermined time elapsed determination is immediately repeated again by so-called background processing.

[0033] Next, in step S120, a CAN frame reception determination is made by a CPU (not shown). That is, the CPU (not shown) determines whether a CAN frame including CAN data or the like has been received based on the CAN communication standard. If YES, that is, if it is determined that a CAN frame has been received, the process proceeds to the process of step S130 described below. On the other hand, if in step S120, NO, that is, if it is determined that a CAN frame has not been received, the process returns to the previous step S110 and a series of processes are repeated.

[0034] Next, in step S130, software C processing execution is performed by a CPU (not shown) as before. That is, CAN data reception processing by the third software process 13 is executed. This CAN data reception processing demodulates and extracts required data such as control data for driving control of the actuator 30 from the received CAN frame, and the demodulated and extracted control data and other required data are passed to the fourth software process 14. Next, in step S140, a reception confirmation flag setting is executed by a CPU (not shown). That is, corresponding to the determination in the previous step S120 that a CAN frame has been received, a reception confirmation flag Fr for identifying the presence or absence of reception of the received frame is set to "1" indicating that a CAN frame has been received. Thus, after the reception confirmation flag is set as described above, the process returns to the previous step S110, and a series of processes are repeated by a CPU (not shown).

[0035] By executing the third software process 13 through the adjustment time elapse determination set to half the cycle of the execution cycle of the CAN data transmission process in this way, unlike the prior art, the waiting time from when CAN data is transmitted from the CAN bus 40 until the start of processing by the third software process 13 is surely shortened compared to the prior art, so that the update delay of CAN data is suppressed and reduced.

[0036] Next, the post-CAN data update processing procedure of the CAN data update process, which is performed before the execution of the fourth software process 14, will be explained with reference to the flowchart shown in Figure 3. When processing is initiated by a CPU (not shown), the first step, S210, is used to determine the elapsed adjustment time. This determination is identical to the process in step S110, so a further explanation is omitted here.

[0037] Next, in step S220, a CPU (not shown) performs a reception acknowledgment flag check. That is, it is determined whether the reception acknowledgment flag Fr, as explained earlier, is set to "1", which indicates that a CAN frame has been received. If it is determined to be YES, i.e., Fr=1, the process proceeds to step S230, which will be described next. On the other hand, if it is determined in step S220 to be NO, i.e., Fr=1, the process returns to step S210 and the series of processes is repeated again.

[0038] Next, in step S230, the reception acknowledgment flag initialization is performed by a CPU (not shown). That is, the reception acknowledgment flag Fr is set and initialized to "0". Next, in step S240, a CPU (not shown) performs the same SW as before. D Processing is executed. Specifically, the drive control of the actuator 30 is performed by the fourth software processing 14, and after the required control is executed, the process returns to step S210, and the series of processes is repeated.

[0039] . In this way, by executing the fourth software process 14 via an adjustment time elapsed determination set to half the execution cycle of the CAN data transmission process, the waiting time from the completion of the third software process 13 to the start of the fourth software process 14 is reliably shortened compared to the conventional method, thereby suppressing and reducing delays in updating CAN data.

[0040] Next, the data update time Tdu and the allowable limit update time Tdl in the CAN data update process described above will be explained with reference to Figure 4. In Figure 4, the time from the completion of the first software process 11 to the start of the second software process 12 is exactly one execution cycle T, due to delays in processing timing caused by some reason. A =T B The flow of each software process when delayed by a few minutes is shown by the thick dashed line.

[0041] In other words, in Figure 4, the flow from the first software process 11, denoted by the symbol a, to the final fourth software process 14, denoted by the symbol d, is shown by a thick dashed line. In this case, even if the processing result of the second software process 12 is transmitted to the second electronic control unit 20 via the CAN bus 40 upon completion of execution, the third software process 13 will not be executed simultaneously with the reception, as is the case with conventional devices. This is because the communication on the CAN bus 40 and the execution timing of the third software process 13 of the second electronic control unit are not synchronized. Therefore, in the case of conventional devices, the start of execution of the third software process 13 based on CAN data received from the CAN bus 40 may be delayed by about one execution cycle of the third software process 13.

[0042] In contrast, in the CAN data update process according to the embodiment of the present invention, the execution interval of the third software process 13 is, as explained above, different from the conventional method, the CAN data transmission period T CA This is half the time. Therefore, after the CAN data is received by the second electronic control unit 20, the received CAN data is transmitted during the CAN data transmission period T. CA Without going through a waiting period equivalent to the CAN data transmission cycle T CA After a waiting period of about half the time, the third software process 13 (see symbol c in Figure 4) is executed, followed by the execution of the fourth software process 14 (see symbol d in Figure 4).

[0043] As a result, in FIG. 4, the data update time Tdu defined as the time from the execution (or completion of execution) of the first first software process 11 marked with symbol a to the execution (or completion of execution) of the last fourth software process 14 marked with symbol d can be within a range that does not exceed the allowable limit update time Tdl which is the limit value of the data update time that can ensure the normal operation of the entire device. That is, the data update time Tdu can be within a time corresponding to twice the CAN data transmission cycle T CA (see FIG. 4). Note that the allowable limit update time Tdl is Tdl = 2 × T CA is.

[0044] Next, the procedure of the CAN data update process in the second configuration example will be described with reference to FIGS. 5 to 7. First, it is assumed that the second configuration example uses a so-called multi-core CPU in the second electronic control device 20. FIG. 5 shows a schematic diagram schematically showing a schematic configuration example of a dual-core CPU. Hereinafter, the content will be described with reference to the same figure. In FIG. 5, the CPU 50 is composed of a first CPU core (denoted as "CPU (C1)" in FIG. 5) 51 and a second CPU core (denoted as "CPU (C2)" in FIG. 5) 52.

[0045] And, a first primary cache memory (denoted as "L11" in FIG. 5) 61 is connected to the first CPU core 51, and a second primary cache memory (denoted as "L12" in FIG. 5) 62 is connected to the second CPU core 52, respectively. Furthermore, a secondary cache memory (denoted as "L2" in FIG. 5) 63 that enables sharing by the first and second CPU cores 51 and 52 is provided. Note that a bus interface (not shown) is provided in the portion of this secondary cache memory 63, enabling communication between the first CPU core 51 and the second CPU core 52, and communication between the first CPU core 51 and the second CPU core 52 and the secondary cache memory 63.

[0046] Next, assuming that at least the second electronic control unit 20 is configured using the CPU 50 described above, the CAN data update process performed by the second electronic control unit 20 will be explained with reference to Figures 6 and 7. The CAN data update process in this second configuration example, like the first configuration example, consists of a CAN data update pre-processing step performed before and after the execution of the third software process 13 in the second electronic control unit 20, and a CAN data update post-processing step performed before the execution of the fourth software process 14. The CAN data update pre-processing step is executed in one CPU core (see the first CPU core 51 in Figure 5), and the CAN data update post-processing step is executed in the other CPU core (see the second CPU core 52 in Figure 5).

[0047] Figure 6 shows a flowchart illustrating the pre-processing steps for updating CAN data. The following explanation will refer to this figure. For the purposes of this explanation, the CAN data update pre-processing will be assumed to be performed on the first CPU core 51 as illustrated in Figure 5. When processing is started by the first CPU core 51, the first step, S310, is used to determine the elapsed adjustment time. This determination is the same as the determination described in step S110 (see Figure 2), so a further explanation is omitted here. Next, in step S320, the first CPU core 51 performs a CAN frame reception determination. This CAN frame reception determination is the same as the one described in step S120 (see Figure 2), so a further explanation will be omitted here.

[0048] Next, in accordance with the determination result in step S320 that a CAN frame has been received, in step S330, the first CPU core 51 performs SW CThe process is executed. This step 330 is basically the same as the one described in the previous step S130 (see Figure 2), so a detailed explanation will be omitted here.

[0049] Next, in step S340, the first CPU core 51 performs a read of the reception acknowledgment flag. That is, the reception acknowledgment flag Fr is the same as the one described in step S140 (see Figure 2). In this second configuration example, since the reception acknowledgment flag Fr is stored in the secondary cache memory 63, in step S340, the data of the reception acknowledgment flag Fr is read from the secondary cache memory 63 into the storage area of ​​the first CPU core 51.

[0050] Next, in step S350, the first CPU core 51 performs the reception acknowledgment flag setting and transmission. That is, the reception acknowledgment flag Fr, which was read in step S340, is set to "1" to indicate that a CAN frame has been received (see step S320 in Figure 6), and is then transmitted to the secondary cache memory 63 for storage. However, as described above, after step S350 is executed, the process returns to step S310, and the first CPU core 51 repeats the series of processes again.

[0051] Thus, in the case of a multi-core CPU, processing such as sending and receiving the reception confirmation flag Fr via the secondary cache memory 63 is required. However, by ensuring that the third software processing 13 in step S330 is executed after the adjustment time elapsed in step S310, the waiting time from when CAN data is transmitted from the CAN bus 40 until the start of processing by the third software processing 13 is significantly reduced compared to the conventional method, as is the case with the first configuration example above. This suppresses and reduces delays in updating CAN data (see Figure 4).

[0052] Next, the post-processing steps for the CAN data update process will be explained with reference to the flowchart shown in Figure 7. For the purposes of this explanation, the CAN data update post-processing will be assumed to be performed on the second CPU core 52 as illustrated in Figure 5. When processing is started by the second CPU core 52, the first step, S410, is used to determine the elapsed adjustment time. This determination is the same as the one described in step S110 (see Figure 2), so a further explanation is omitted here.

[0053] Next, in step S420, the second CPU core 52 performs a read of the reception acknowledgment flag. That is, similar to the previous step S340 (see Figure 6), the reception acknowledgment flag Fr stored in the secondary cache memory 63 is read into the second CPU core 52.

[0054] Next, in step S430, the second CPU core 52 performs a check to determine whether the reception confirmation flag is set. That is, it is determined whether the reception confirmation flag Fr, which was read in step S420, is set to "1". If it is determined in step S430 that YES, i.e., that the reception confirmation flag Fr is set to "1", then the process proceeds to step S440, which will be described next. On the other hand, if it is determined in step S430 that NO, i.e., that the reception confirmation flag Fr is not set to "1", then the process returns to step S410 and the series of processes is repeated again.

[0055] Next, in step S440, the second CPU core 52 performs initialization and transmission of the reception acknowledgment flag. That is, the reception acknowledgment flag Fr is initialized to "0", and then transmitted to the secondary cache memory 63, where it is stored. Next, in step S450, the second CPU core 52 performs the same SW as before. DThe process is executed. Note that the process in step S450 is basically the same as that described in step S240 (see Figure 3), so a detailed explanation will be omitted here. After the necessary processing in step S450 is completed, the process returns to step S410, and the series of processes is repeated.

[0056] Thus, in the case of a multi-core CPU, processing such as sending and receiving the reception confirmation flag Fr via the secondary cache memory 63 is required. However, by ensuring that the fourth software process 14 in step S450 is executed after the adjustment time elapsed determination in step S410, the waiting time from the completion of the third software process 13 to the start of the fourth software process 14 is significantly reduced compared to conventional methods, as is the case with the first configuration example above. This suppresses and reduces delays in updating CAN data (see Figure 4).

[0057] In the embodiments of the present invention described above, the second electronic control unit 20 executes two software processes, namely the third and fourth software processes 13 and 14, and the execution cycles of both are set to half the CAN data transmission cycle. However, the execution cycle settings are not limited to this. For example, the sum of the execution cycles of the third and fourth software processes 13 and 14 may be T CA You may set each execution period to any value, as long as it does not exceed the specified limit.

[0058] Furthermore, the software processing performed in the second electronic control unit 20 is not limited to two software processes as in the embodiment of the present invention. In other words, the configuration may be such that, between the transition from the third software process 13 to the fourth software process 14, the fourth software process 14 is executed via the execution of other software processes. In this case, if the total number of software processes, which is the number of software processes executed between the third software process 13 and the fourth software process 14 plus the number of the third and fourth software processes 13 and 14, is N, then the execution period of each software process is the CAN data transmission period T. CA It is best to set the same period as / N. Furthermore, the sum of the execution cycles of each software process equals the CAN data transmission cycle T. CA Within a range that does not exceed the specified limit, it is also preferable to set the execution cycle to the appropriate period depending on the execution content of each software process. [Industrial applicability]

[0059] This technology can be applied to automated vehicles where suppressing or reducing delays in CAN data update time is desired. [Explanation of symbols]

[0060] 10…First Electronic Control Unit 11…First software processing 12…Second software processing 13…Third software processing 14…Fourth software processing 20…Second Electronic Control Unit 30… Actuator 40...CAN bus

Claims

1. A method for updating CAN data by an electronic control device (20) that receives CAN data from a CAN bus (40) and controls the driving of a controlled object (30) based on control data used to drive the controlled object (30) contained in the CAN data, wherein The number of software processes executed at predetermined execution cycles from the reception of the CAN data to the execution of drive control for the controlled object (30) is N, and the execution cycle of the CAN data transmission process by the CAN bus (40) is T. ＣＡ In this case, the execution period of each of the N software processes is defined as the execution period T. ＣＡ A CAN data update method characterized by setting the value obtained by dividing by the aforementioned N.

2. The execution period of each of the N software processes is defined as the execution period T. ＣＡ Instead of setting it to the value obtained by dividing by N, the sum of the execution periods of each of the N software processes is the execution period T. ＣＡ The CAN data update method according to claim 1, characterized in that the execution period of each of the N software processes is set as follows.

3. The aforementioned N is 2, One of the N software processes is CAN data receiving software processing (13) that receives the CAN data from the CAN bus and extracts and outputs the control data, Of the N software processes mentioned above, the other is: The CAN data update method according to claim 1, characterized in that it is a drive software process (14) that performs drive control of the controlled object based on the control data obtained by the CAN data receiving software process (13).

4. Each time a time corresponding to the execution cycle of the first software process to be executed among the N software processes has elapsed, it is determined whether or not a CAN frame containing the CAN data has been received. If the CAN frame has been received, the execution of the first software process is started, and a reception confirmation flag for identifying whether or not the CAN frame has been received is set to a predetermined value corresponding to the reception of the CAN frame. A CAN data update method according to any one of claims 1 to 3, characterized in that, each time a time corresponding to the execution cycle of the last software process to be executed among the N software processes has elapsed, it is determined whether the reception confirmation flag is set to the predetermined value, and if the reception confirmation flag is set to the predetermined value, the reception confirmation flag is initialized and the execution of the last software process is started.

5. An electronic control device (20) including a CPU that receives CAN data from a CAN bus (40) and controls the driving of a controlled object (30) based on control data used to drive the controlled object (30) contained in said CAN data, The CPU is capable of executing N software processes, each having a predetermined execution period, between receiving the CAN data and performing drive control on the controlled object (30). The execution cycle of each of the N software processes is the execution cycle T of the CAN data transmission process by the CAN bus (40). ＣＡ An electronic control device characterized by being set to a value obtained by dividing by the aforementioned N.

6. In the CPU, the execution period of each of the N software processes is the execution period T. ＣＡ Instead of being set to the value obtained by dividing by N, the sum of the execution periods of each of the N software processes is the execution period T. ＣＡ The electronic control device according to claim 5, characterized in that the execution period of each of the N software processes is set as follows.

7. The above N is 2, One of the N software processes is a CAN data receiving software process (13) that receives the CAN data from the CAN bus and extracts and outputs the control data, The other of the N software processes is A drive software process (14) that performs drive control of the controlled object (30) based on the control data obtained by the CAN data receiving software process (13), The electronic control device according to claim 5, characterized in that the CPU is capable of executing the CAN data reception software processing (13) and the drive software processing (14).

8. The aforementioned CPU is Each time a time corresponding to the execution cycle of the first software process to be executed among the N software processes has elapsed, it is determined whether or not a CAN frame containing the CAN data has been received. If the CAN frame has been received, the execution of the first software process is started, and a reception confirmation flag for identifying whether or not the CAN frame has been received is set to a predetermined value corresponding to the reception of the CAN frame. The electronic control device according to any one of claims 5 to 7, characterized in that, each time a time corresponding to the execution cycle of the last software process to be executed among the N software processes has elapsed, it is determined whether the reception confirmation flag is set to the predetermined value, and if the reception confirmation flag is set to the predetermined value, the reception confirmation flag is initialized and the execution of the last software process is started.

Images