Update management system

Abstract

To make it possible to rewrite and change, without using a two-side memory structure, a program during vehicle travelling in an arrangement of an ECU with redundancy.SOLUTION: An update management system according to the present invention mounted on a vehicle has a plurality of computing devices and an update management apparatus for controlling the plurality of computing devices. The plurality of computing devices has at least a first computing device and a second computing device. The update management apparatus determines, during travelling of the vehicle, whether or not the second computing device executes redundancy processing, and, if determining that the second computing device does not execute any redundancy processing, restricts execution of the redundancy processing by the first computing device and updates a program stored in the second computing device.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a program update technology for an ECU (Electronic Control Unit) mounted on a vehicle. [Background technology]

[0002] Autonomous driving technology for automobiles requires redundancy in ECUs and sensor systems to ensure safety. In other words, functional safety is ensured by preparing, for example, two ECUs with the same functions, so that if one ECU makes an emergency stop, the other ECU can continue to perform its function.

[0003] When switching a running program in this way, it is necessary to minimize the impact on the running system. In relation to this technology, Patent Document 1 states that "the operation verification and switching unit prepares, as an alternative program, a control program with the same execution environment as the control program to be updated." [Prior art documents] [Patent documents]

[0004] [Patent Document 1] International Publication No. 2015 / 037116 Summary of the Invention [Problem to be solved by the invention]

[0005] In recent years, programs installed in vehicle ECUs are increasingly being updated using OTA (Over the Air) technology. Conventional ECU program updates using OTA require a dual-layer memory structure to write a new program while the vehicle is running (while the ECU program is running), making it impossible to switch to a new program while the current program is running. In other words, for example, when attempting to configure two ECUs for redundancy, one ECU (ECU_1) must constantly monitor the program running status of the other ECU (ECU_2), making it impossible to update the program currently being executed by ECU_2. Therefore, when attempting to update a program stored in ECU_2, it was necessary to create a dual-layer memory structure by installing a separate storage area with the same capacity as the program storage area where the program currently being executed by ECU_2 is stored, update the program stored in this area, and then switch the program.

[0006] The present invention aims to enable program writing and switching while the vehicle is running in a redundant ECU configuration without using a two-sided memory structure. [Means for solving the problem]

[0007] An update management system according to one embodiment of the present invention is mounted on a vehicle and includes a plurality of computing devices and an update management device that controls the plurality of computing devices, the plurality of computing devices including at least a first computing device and a second computing device, and the update management device determines whether the second computing device is performing redundant processing while the vehicle is running, and if it determines that the redundant processing is not being performed, restricts the execution of redundant processing by the first computing device and updates the program stored in the second computing device. [Effects of the Invention]

[0008] According to the present invention, in an ECU with a redundant configuration, program update and switching can be performed while the vehicle is running using minimal memory resources. Further features related to the present invention will become apparent from the description of the present specification and the accompanying drawings. Furthermore, problems, configurations, and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a block diagram showing the configuration of an update management system according to an embodiment of the present invention. [Figure 2] FIG. 10 is a flowchart illustrating an example of a program update process. [Figure 3] FIG. 10 is a flowchart showing another example of a program update process. [Figure 4] FIG. 10 is a sequence diagram showing an example of a process from synchronization processing to switching processing. [Figure 5] FIG. 10 is a block diagram showing the configuration of an update management system according to another embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, an embodiment will be described with reference to the drawings.

[0011] [Example 1] 1 is a block diagram showing the overall configuration of an update management system according to a first embodiment of the present invention. The update management system 100 includes a first arithmetic unit 101, a second arithmetic unit 102, and a vehicle control device 103 that controls these arithmetic units. The first arithmetic unit 101, the second arithmetic unit 102, and the vehicle control device 103 are, for example, ECUs mounted on a vehicle to perform various functions, and are connected to each other via a communication network such as a CAN (Controller Area Network). These devices may be mounted separately within the vehicle, or may be configured as a zone architecture in which they are mounted together in a single ECU.

[0012] The configuration of the first arithmetic unit 101 will be described. In this embodiment, the first arithmetic unit 101 and the second arithmetic unit 102 have the same configuration and functions. Therefore, a description of the second arithmetic unit 102 will be omitted. The first arithmetic unit 101 has an operation unit 104, a communication IF (Interface) 112, and a power supply 113. The operation unit 104 executes stored programs to realize various functions. The communication IF 112 transmits and receives various data to and from the second arithmetic unit 102 and the vehicle control device 103 via a network. The power supply 113 stores power supplied from an external power source and functions as a power supply.

[0013] The operating unit 104 is composed of a CPU (Central Processing Unit), and has an arithmetic unit 105 that executes programs, a RAM (Random Access Memory) 106 that can write and read data, and a ROM 107 that can read data. The ROM 107 is, for example, a non-volatile memory. The ROM 107 further has a data storage area 108 that stores control data and a program storage area 109 that stores executable programs. The programs stored in a program update target area 111 of the program storage area 109 are rewritten and updated by a rewriting means possessed by a program update processing unit 110.

[0014] The vehicle control device 103 has a program control unit 124 and a calculation result monitoring unit 125. The program control unit 124 switches the operating state (redundancy processing, control value output, synchronization processing, etc.) of each calculation device. The calculation result monitoring unit 125 for each calculation device monitors the calculation results of each calculation device and determines, for example, whether redundancy processing is being performed accurately. The vehicle control device 103 also receives information on whether the programs stored in each calculation device require updating and update programs from an external server or the like, and transmits the update programs to each calculation device. That is, the vehicle control device 103 functions as an update management device in this embodiment.

[0015] Here, the redundant processing in the present invention refers to processing executed by a system having two or more systems of the same or different substitutable hardware or software, such as processing in which different systems mutually monitor calculations such as vehicle control, or processing in which one system takes over when the other system fails. As described above, in this embodiment, the first calculation device 101 and the second calculation device 102 are described as having the same functional configuration, but they may be configured with different hardware or software with different operating systems or compilers used, as long as they are capable of substituting at least part of their functional configurations.

[0016] 2 is a flowchart showing the processing performed by the update management system 100 according to this embodiment. In this embodiment, the first arithmetic unit 101 is referred to as ECU_A, and the second arithmetic unit 102 is referred to as ECU_B. First, the vehicle control device 103 determines whether the programs stored in ECU_A and ECU_B need to be updated (step 201). This determination can be made, for example, by determining whether the program control unit 124 in the vehicle control device 103 has received update information from an external source.

[0017] When the vehicle control device 103 determines that an update is necessary or receives an update command, it determines whether ECU_B is performing redundant processing (step 202). If it determines that redundant processing is being performed, it notifies the driver of the existence of a program update and waits until the redundant processing is completed (steps 203 / 204).

[0018] If it is determined in step 202 that ECU_B is not executing redundancy processing, the program control unit 124 restricts the functions that use redundancy processing for ECU_A. That is, it stops the execution of all functions related to redundancy processing. Then, it notifies the driver that a program update will be started and that the functions that use redundancy processing will be restricted (step 205). Then, the program control unit 124 switches ECU_B from the redundancy processing state to the program writing state, and starts the program update process (step 206). At this time, it is possible to ask the driver for consent to start the program update before switching to the program writing state.

[0019] After writing the update program to ECU_B is completed (step 207), the vehicle control device 103 determines whether the vehicle is running, i.e., whether program execution by ECU_A is continuing, and waits until the vehicle stops running (step 208). Note that "stopped running" here does not include a temporary stop due to a red light or the like, but refers to a state in which the engine or motor is completely stopped.

[0020] When the vehicle stops running, the program control unit 124 switches the ECU_B from the program writing state to the operating state. That is, execution of the updated program is started. Then, the program control unit 124 switches the ECU_A from the operating state to the program writing state (step 209). Note that step 209 also includes a process of setting the program control unit 124 to operate ECU_B at the next startup if the vehicle does not resume running after waiting until the vehicle has stopped running in step 208.

[0021] After the writing of the update program to ECU_A is completed (step 210), the vehicle control device 103 again waits until the vehicle stops running (step 211). After the vehicle stops, the program control unit 124 switches ECU_A to an operating state. That is, it starts executing the updated program. Then, ECU_B is switched to a redundant processing enabled state (step 212). Note that the redundant processing enabled state refers to a state in which redundant processing can be started in response to receipt of a redundant processing start command output from the program control unit 124, and does not refer only to a state in which redundant processing is actually being performed. Finally, the program control unit 124 ends the program update process and releases the functional restrictions on the redundant processing, notifying the driver of this (step 213), and the update process ends.

[0022] As described above, in this embodiment, when neither of the two arithmetic units is performing redundancy processing, the redundancy processing function is restricted and the program stored in one of the arithmetic units is updated. This makes it possible to update the program without providing multiple program storage areas within a single arithmetic unit, thereby reducing memory resources and manufacturing costs.

[0023] [Example 2] Next, an update management system according to a second embodiment of the present invention will be described. The update management system 100 according to the second embodiment has the same configuration as the update management system 100 according to the first embodiment, and therefore, a description of the configuration and the same processes as those executed in the first embodiment will be omitted.

[0024] As shown in FIG. 3, the update management system according to the second embodiment differs from the first embodiment in that it performs the processes shown in steps 301 to 304 in addition to the configuration and processes of the first embodiment. That is, after writing the update program to ECU_B in step 207, the vehicle control device 103 determines whether the vehicle is running (step 301). If the vehicle is not running, the process proceeds to step 209, as in the first embodiment. If it is determined that the vehicle is running, the control data stored in the RAM 106 and data storage area 108 of the ECU_A in the operating state is synchronized with the control data stored in the RAM 116 and data storage area 118 of the ECU_B (step 302). A specific synchronization method will be described later. Then, while the vehicle is running, the ECU_B is switched to the operating state to start executing the updated program, and the ECU_A is switched to the program writing state (step 209).

[0025] If it is determined in step 303 that the vehicle is running, the control data stored in the RAM 116 and data storage area 118 of the ECU_B in the operating state is synchronized with the control data stored in the RAM 106 and data storage area 108 of the ECU_A in the writing state (step 304). The subsequent processing is the same as in the first embodiment.

[0026] The above-mentioned synchronization processing of control data will be described in detail. As described above, a redundant configuration between different ECUs may be configured between ECUs having different software configurations that can replace some of the functional configuration. In this way, synchronization processing between different software is required, and control data based on the pre-update program must be matched with control data based on the new program. To achieve this, in this embodiment, synchronization processing is performed using at least one of the following three means. Here, a' is the control data of the post-update ECU (control data based on the post-update program), and a is the control data of the pre-update ECU (control data based on the running program). Method 1: Convert each control data to fit the updated ECU (e.g., a'=a+5). Method 2: Store the control data of the pre-update ECU in the post-update ECU as is (e.g., a'=a). Method 3: After updating, the ECU generates its own initial value (e.g., a'=5).

[0027] Means 1 takes into account cases where RAM values, initial values ​​of variables, data types, data structures, etc. are different before and after a program update, and performs synchronization processing such as substituting initial values, adding or subtracting correction values, and casting data types in the updated ECU to make it compatible with the updated ECU.

[0028] If the contents of RAM values, variables, etc. are the same before and after the program update, the second method substitutes the values ​​of the pre-update program. At this time, the RAM values ​​and variables do not necessarily have to be the same, and even if the initial values, data types, data structures, etc. are different, the second method may be adopted if the impact of substituting the pre-update data does not need to be considered.

[0029] Method 3 is a method in which the updated program is started with its own RAM values ​​and initial variable values, and the pre-update data is not referenced.

[0030] When one of the above synchronization processes is performed and the operating ECU is continuously switched, there is a possibility that the control values ​​will become discrete between the programs before and after the update. For example, if the program being updated is related to steering angle control or torque control, if the control values ​​become discrete at the time of the update, this could have a significant impact on vehicle behavior and significantly reduce safety. Therefore, it is necessary to suppress such discrete transitions in the control values. To achieve this, for example, a method can be used in which, after the synchronization process is completed, the pre-update program performs control using values ​​calculated by the program, while the post-update program calculates control values, and the program switches when the control values ​​of both programs become similar.

[0031] 4 is a sequence diagram showing an example of the process from synchronization processing of ECU_A / B to switching of the operating ECU in this method. Here, ECU_A / B output steering angle control values ​​401 / 402, respectively. The solid line indicates a state in which a control value related to the steering angle is being output to the output destination, and the dashed line indicates a state in which the steering angle is being calculated but not output. When the switching control state 403 is synchronization processing, ECU_A state 404 is a state in which the steering angle is being output, and ECU_B state 405 is a synchronization processing state.

[0032] When synchronization of ECU_B is completed, the switching control state 403 is in a state in which the control values ​​of both ECUs are monitored. That is, the calculation result monitoring unit 125 is monitoring the calculation results of both ECUs. During this time, ECU_B calculates the steering angle. At this time, ECU_B only calculates the steering angle and does not output the steering angle to the output destination. When the degree of approximation of the steering angles of both ECUs exceeds a certain value, the program control unit 124 sends a switching command to both ECUs, and the ECU_A state 404 is switched to a state in which the steering angle is calculated, and the ECU_B state 405 is switched to a state in which the steering angle is output. Then, the process proceeds to update ECU_A.

[0033] As described above, in this embodiment, the control data according to the updated program is synchronized with the control data according to the pre-update program while the redundant processing function is restricted. Therefore, even while the vehicle is running, it is possible to switch the running program to the updated program, which is expected to improve convenience.

[0034] Furthermore, an example of application of this embodiment is partial program updates in SOTA (Software Over the Air), which allows program updates to be performed at any time, and is expected to further improve convenience.

[0035] [Example 3] Next, an update management system according to a third embodiment of the present invention will be described. The update management system 500 according to the third embodiment differs from the update management system 100 according to the first embodiment in that it further includes a map and route information management device 501, as shown in FIG.

[0036] In the above-described first and second embodiments, when it is determined in step 201 that an update is required, the condition for starting the update is whether ECU_B is performing redundant processing (step 202). In this embodiment, whether redundant processing is being performed can be determined based on the autonomous driving level of the vehicle. In autonomous driving of level 3 or higher, the driving task is monitored by the system. In other words, the system is the driving subject. Therefore, compared to when the driving subject is a human, it is necessary to ensure the safety of the system, and at least ECUs related to functions of autonomous driving level 3 or higher must have a redundant configuration. Therefore, a method for determining the autonomous driving level of the vehicle can be used to determine whether an ECU is performing redundant processing.

[0037] When determining the autonomous driving level of a vehicle, the program control unit 124 can determine whether a program for demonstrating functions of autonomous driving level 3 or higher is actually being executed, but it is also possible to use map and route information 502 stored in the map and route information management device 501, as described below. Note that the map and route information management device 501 preferably has a GPS function and may be installed in the vehicle as a car navigation system. Alternatively, it may be configured to be installed in the vehicle control device 103.

[0038] One of the conditions for achieving level 3 or higher autonomous driving is that the location must be limited. This includes expressways, parking lots, and other specific locations. Therefore, by associating the information contained in the map and route information 502 stored in the map and route information management device 501 with information about locations where level 3 or higher autonomous driving is possible, it is possible to determine whether a location is applicable to level 3 or higher autonomous driving, i.e., whether redundant processing is to be performed. Specifically, the following steps 4 to 6, which are executed by the program control unit 124, can be employed. Note that "autonomous driving" below refers to autonomous driving at a level (e.g., level 3) that requires redundant processing.

[0039] Means 4: Using map and route information 502 from the map and route information management device 501, compare the section where automatic driving is possible with the vehicle's position, and if the vehicle is outside the section where automatic driving is possible or is more than a predetermined distance away from the section, redundant processing is not performed and it is determined that updating is possible.

[0040] Means 5: After a navigation route to the destination is generated through driver operation using map and route information 502 from the map and route information management device 501, it is detected whether the route passes through an area where automatic driving is possible, and if the route does not pass through such an area, redundant processing is not performed and it is determined that the route can be updated.

[0041] Means 6: In addition to the determination of means 4 or 5, if the estimated time required for the program update is shorter than the estimated time to reach the section where automatic driving is possible, even if the vehicle is scheduled to enter the section where automatic driving is possible, redundant processing will not be performed until the vehicle reaches the section, and it will be determined that the update is possible.

[0042] The processing of the above means 4 to 6 reduces the need to leave the decision on whether to perform the update to the driver, and is expected to improve convenience.

[0043] According to the embodiment of the present invention described above, the following advantageous effects are achieved. (1) An update management system according to one embodiment of the present invention is mounted on a vehicle and includes a plurality of computing devices and an update management device that controls the plurality of computing devices, the plurality of computing devices including at least a first computing device and a second computing device, and the update management device determines whether the second computing device is performing redundant processing while the vehicle is running, and if it determines that the second computing device is not performing the redundant processing, it restricts the first computing device from performing the redundant processing and updates the program stored in the second computing device.

[0044] With the above configuration, the program stored in the second arithmetic unit can be updated while the first arithmetic unit is not performing redundancy processing. This eliminates the need to provide an additional program storage area in the arithmetic unit, which was previously required when updating a program during redundancy processing, thereby reducing memory resources and manufacturing costs.

[0045] (2) After updating the program stored in the second arithmetic unit, when the update management device determines that the vehicle has stopped, it instructs the second arithmetic unit to execute the updated program and updates the program stored in the first arithmetic unit. This allows the program in the first arithmetic unit to be updated while the second arithmetic unit is not performing redundant processing, thereby reducing memory resources and manufacturing costs.

[0046] (3) After updating the program stored in the first arithmetic unit, when the update management device determines that the vehicle has stopped, it instructs the first arithmetic unit to execute the updated program and removes the restriction on the execution of redundant processing by the multiple arithmetic units, thereby enabling both the first and second arithmetic units to resume redundant processing using the updated program.

[0047] (4) The instructions issued by the update management device to the second arithmetic unit include an instruction to synchronize the updated program with the program currently being executed by the first arithmetic unit before executing the updated program. This eliminates the risk of output values ​​becoming discrete at the time of switching between the execution programs, which could cause abnormalities in vehicle control, even if the first and second arithmetic units have different software configurations.

[0048] (5) The synchronization process includes a process in which the second arithmetic unit outputs a value obtained by recalculating the output value of the first arithmetic unit based on the updated program, a process in which the second arithmetic unit outputs a value identical to the output value of the first arithmetic unit, or a process in which the second arithmetic unit outputs an initial value of the updated program. This allows an appropriate synchronization process to be selected depending on the characteristics of the program to be updated.

[0049] (6) The update management device further includes a map and route information management device, and the update management device acquires map and route information from the map and route information management device and determines whether multiple arithmetic units are performing redundant processing based on the vehicle's driving status and the map and route information. This makes it possible to automatically determine whether redundant processing is in progress by automatically acquiring map and route information, for example, by storing the vehicle's driving status, such as the autonomous driving level, in association with the map and route information.

[0050] (7) The update management device partially updates the programs stored in the first and second computing devices. This makes it possible to update only the common parts, even if the first and second computing devices have partially different hardware or software configurations, thereby improving the usefulness of the present invention.

[0051] The technical scope of the present invention is not limited to the scope of the above-described embodiments, and various modifications are included without departing from the main features of the present invention. Therefore, the above-described embodiments are merely illustrative and should not be interpreted as limiting. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations, and all of these are within the scope of the present invention. [Explanation of symbols]

[0052] 100, 500 Update management system, 101 First calculation device, 102 Second calculation device, 103 Vehicle control device (update management device), 501 Map and route information management device

Claims

1. An update management system mounted on a vehicle, the update management system including a plurality of arithmetic units and an update management device that controls the plurality of arithmetic units, the plurality of arithmetic units include at least a first arithmetic unit and a second arithmetic unit; the update management device determines whether the second arithmetic unit is executing redundant processing while the vehicle is running, and when it determines that the second arithmetic unit is not executing the redundant processing, restricts the execution of the redundant processing by the first arithmetic unit and updates the program stored in the second arithmetic unit. An update management system characterized by:

2. The update management system according to claim 1, and when the update management device determines that the vehicle has stopped after updating the program stored in the second arithmetic device, the update management device instructs the second arithmetic device to execute the updated program and updates the program stored in the first arithmetic device. An update management system characterized by:

3. 3. The update management system according to claim 2, and when the update management device determines that the vehicle has stopped after updating the program stored in the first arithmetic device, the update management device instructs the first arithmetic device to execute the updated program and releases the restriction on the execution of the redundant processing by the plurality of arithmetic devices. An update management system characterized by:

4. 3. The update management system according to claim 2, The instruction issued by the update management device to the second computing device includes an instruction to execute a synchronization process with the program being executed by the first computing device before executing the updated program. An update management system characterized by:

5. The update management system according to claim 4, the synchronization process includes a process in which the second arithmetic unit outputs a value obtained by recalculating an output value of the first arithmetic unit based on the updated program. An update management system characterized by:

6. The update management system according to claim 4, the synchronization process includes a process in which the second arithmetic unit outputs a value identical to an output value of the first arithmetic unit, An update management system characterized by:

7. The update management system according to claim 4, the synchronization process includes a process in which the second arithmetic unit outputs an initial value of the updated program. An update management system characterized by:

8. The update management system according to claim 1, Further comprising a map and route information management device, the update management device acquires map and route information from the map and route information management device, and determines whether the plurality of arithmetic devices are executing the redundant processing based on the traveling state of the vehicle and the map and route information; An update management system characterized by:

9. The update management system according to claim 1, the update management device partially updates the programs stored in the first computing device and the second computing device; An update management system characterized by:

Images