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 updating technique for an ECU (Electronic Control Unit) mounted on a vehicle.

Background Art

[0002] Regarding automatic driving technology for automobiles, it is required to provide redundancy for ECUs and sensor systems to ensure safety. That is, it is required to ensure functional safety by preparing, for example, two ECUs having the same function, and when one of them makes an emergency stop, the other ECU performs the function to maintain functional safety.

[0003] When switching between operating programs in this manner, it is required to suppress the influence on the operating system. In relation to this technology, Patent Document 1 describes that "an operation verification and switching unit prepares, as a substitute program, a control program in the same execution environment as the control program to be updated".

Prior Art Literature

Patent Literature

[0004]

Patent Document 1

Summary of the Invention

Problem to be Solved by the Invention

[0005] In recent years, programs installed in vehicle-mounted ECUs are increasingly being updated using OTA (Over the Air) technology. Conventional techniques for updating ECU programs using OTA require a dual-memory structure to write the new program while the vehicle is running (while the ECU program is running), and it is not possible to switch to the new program while the current program is running. In other words, for example, if you want to make a two-ECU configuration redundant, one ECU (ECU_1) must constantly monitor the program running status of the other ECU (ECU_2), and it is not possible to update the program that ECU_2 is currently running. Therefore, when trying to update the program stored in ECU_2, it was necessary to install a separate storage area with the same capacity as the program storage area where the program currently running in ECU_2 is stored, creating a dual-memory structure, updating the program stored in this area, and then switching over.

[0006] The present invention aims to enable program writing and switching during vehicle operation in a redundant ECU configuration without requiring a two-plane 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 comprises a plurality of computing devices and an update management device that controls the plurality of computing devices, wherein the plurality of computing devices comprises 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, it 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 updates and switching can be performed while the vehicle is running with minimal memory resources. Further features related to the present invention will become apparent from the description herein and the accompanying drawings. Problems, configurations, and effects other than those described above will be revealed by the following description of the embodiments. [Brief explanation of the drawing]

[0009] [Figure 1] A block diagram showing the configuration of an update management system according to one embodiment of the present invention. [Figure 2] A flowchart illustrating an example of a program update process. [Figure 3] A flowchart illustrating another example of the program update process. [Figure 4] A sequence diagram showing an example from synchronization to switching. [Figure 5] A block diagram showing the configuration of an update management system according to another embodiment of the present invention. [Modes for carrying out the invention]

[0010] The following describes an example using drawings.

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

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

[0013] The operating unit 104 consists of a CPU (Central Processing Unit) and includes an arithmetic unit 105 for executing programs, a RAM (Random Access Memory) 106 capable of writing and reading data, and a ROM 107 capable of reading data. The ROM 107 is, for example, a non-volatile memory. The ROM 107 further includes a data storage area 108 for storing control data and a program storage area 109 for storing the executable program. The program stored in the program update target unit 111 of the program storage area 109 is rewritten and updated by the rewriting means of the program update processing unit 110.

[0014] The vehicle control device 103 includes a program control unit 124 and a calculation result monitoring unit 125. The program control unit 124 switches the operating state of each calculation unit (redundant processing, control value output, synchronization processing, etc.). The calculation result monitoring unit 125 monitors the calculation results of each calculation unit to determine, for example, whether redundant processing is being performed correctly. The vehicle control device 103 also receives information from an external server or the like regarding whether the programs stored in each calculation unit need updating, as well as update programs, and sends the update programs to each calculation unit. In other words, in this embodiment, the vehicle control device 103 functions as an update management device.

[0015] Here, redundant processing in the present invention refers to processing performed by two or more systems having identical or substitutable different hardware and software. For example, it refers to processing in which different systems mutually monitor each other for calculations such as vehicle control, or processing in which one system takes over when one system fails. As described above, in this embodiment, the first arithmetic unit 101 and the second arithmetic unit 102 are described as having the same functional configuration, but they may be composed of different hardware or different software such as operating systems or compilers, as long as they can substitute for at least some of each other's functional configurations.

[0016] Figure 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 denoted as ECU_A and the second arithmetic unit 102 is denoted as ECU_B. First, the vehicle control device 103 determines whether it is necessary to update the programs stored in ECU_A and ECU_B (step 201). This determination can be made, for example, by checking whether the program control unit 124 within 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 performing redundant processing, the program control unit 124 restricts the functions that use redundant processing for ECU_A. That is, it stops the execution of all functions related to redundant processing. It then notifies the driver that the program update has started and that the functions that use redundant processing have been restricted (step 205). The program control unit 124 then switches ECU_B from the redundant processing state to the program writing state and starts the program update process (step 206). At this time, the driver may be asked for consent to start the program update before switching to the program writing state.

[0019] After the writing of the update program to ECU_B is completed (step 207), the vehicle control device 103 determines whether or not the vehicle is traveling, that is, whether or not the program execution by ECU_A is ongoing, and waits until the traveling stops (step 208). Note that the term "traveling stop" as used herein does not include a temporary stop due to a red light or the like, and refers to a state in which the engine and motor are completely stopped.

[0020] When the vehicle stops traveling, the program control unit 124 switches ECU_B from the program writing state to the operating state. That is, the execution of the updated program is started. Then, the program control unit 124 switches 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 when traveling does not resume after waiting for traveling to stop in step 208.

[0021] After the writing of the update program to ECU_A is completed (step 210), the vehicle control device 103 waits again until the vehicle stops traveling (step 211). After the vehicle stops, the program control unit 124 switches ECU_A to the operating state. That is, the execution of the updated program is started. Then, ECU_B is switched to a redundancy-processable state (step 212). Note that the redundancy-processable state refers to a state in which redundancy processing can be started in response to receiving a redundancy processing start command output from the program control unit 124, and does not only refer to a state where redundancy processing is actually being performed. Finally, the program control unit 124 terminates the program update processing and cancels the functional restriction on the redundancy processing, notifies the driver thereof (step 213), and terminates the update processing.

[0022] As explained above, in this embodiment, when neither of the two arithmetic units is performing redundant processing, the redundant processing function is limited and the program stored in one of the arithmetic units is updated. Therefore, it becomes 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 Embodiment 2 of the present invention will be described. The update management system 100 according to Embodiment 2 has the same configuration as the update management system 100 according to Embodiment 1, and therefore, a description of the configuration and the same processes executed in Embodiment 1 will be omitted.

[0024] The update management system according to Example 2 differs from Example 1 in that, in addition to the configuration and processing of Example 1, it performs the processing shown in steps 301 to 304, as shown in Figure 3. Specifically, after writing the update program to ECU_B in step 207, the vehicle control device 103 determines whether or not the vehicle is running (step 301). If the vehicle is not running, it proceeds to step 209, as in Example 1. If it is determined that the vehicle is running, the control data stored in the RAM 106 and data storage area 108 of the operating ECU_A is synchronized with the control data stored in the RAM 116 and data storage area 118 of ECU_B (step 302). The specific method of synchronization will be described later. Then, while the vehicle is still running, ECU_B is switched to the operating state to start execution of the updated program, and ECU_A is switched to the program writing state (step 209).

[0025] If it is determined in step 303 that the vehicle is in motion, the control data stored in the RAM 116 and data storage area 118 of the operational ECU_B is synchronized with the control data stored in the RAM 106 and data storage area 108 of the written ECU_A (step 304). The subsequent processing is the same as in Example 1.

[0026] The synchronization process for the control data described above will now be explained in detail. As mentioned above, redundant configurations between different ECUs may consist of ECUs with different software configurations that can substitute for some of the functional configurations. In such cases, it is necessary to perform synchronization processing between different software, and it is necessary to match the control data from the program before the update with the control data from the new program. To achieve this, in this embodiment, at least one of the following three methods will be used for synchronization processing. Here, a' is the control data of the updated ECU (control data from the updated program), and a is the control data of the pre-update ECU (control data from the program currently running). Method 1: Convert each control data to be compatible with the updated ECU (e.g., a'=a+5). Method 2: Store the control data of the pre-update ECU directly into the updated ECU (e.g., a'=a). Method 3: After the update, the ECU generates its own initial values ​​(e.g., a'=5).

[0027] Method 1 takes into account cases where RAM values, initial values ​​of variables, data types, and data structures differ before and after a program update. It performs synchronous processing such as assigning initial values, adding or subtracting correction values, and casting data types in the updated ECU to adapt them to the updated ECU.

[0028] Method 2 involves substituting the values ​​from the pre-update program if the contents of RAM values ​​and variables are the same before and after the program update. In this case, the RAM values ​​and variables do not necessarily have to be the same; even if the initial values, data types, and data structures are different, Method 2 may be used if it is not necessary to consider the impact of substituting the pre-update data.

[0029] Method 3 involves starting the updated program with its own RAM values ​​and initial variable values, without referencing the pre-update data.

[0030] When performing any of the above synchronization processes and continuously switching the operating ECU, there is a possibility that the control values ​​may become discrete between the pre- and post-update programs. If the updated program relates to, for example, steering angle control or torque control, discrete control values ​​at the update timing could have a significant impact on vehicle behavior and drastically reduce safety. Therefore, it is necessary to suppress such discrete transitions of control values. To achieve this, for example, one method could be to control the system using values ​​calculated by the pre-update program after the synchronization process is complete, while simultaneously calculating control values ​​in the post-update program, and then switching when the control values ​​of both programs become approximately the same.

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

[0032] When synchronization of ECU_B is complete, the switching control state 403 is in a state where the control values ​​of both ECUs are being monitored. That is, the calculation results of both ECUs are being monitored by the calculation result monitoring unit 125. During this time, ECU_B calculates the steering angle. At this time, ECU_B only calculates the steering angle and does not output it to the steering angle output destination. When the 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 switches to a state where the steering angle is calculated, and the ECU_B state 405 switches to a state where the steering angle is output. After that, the process moves on to updating ECU_A.

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

[0034] Furthermore, an example of the application of this embodiment is partial program updates in SOTA (Software Over the Air), where program updates can be continuously implemented, leading to further improvements in convenience.

[0035] [Example 3] Next, an update management system according to Embodiment 3 of the present invention will be described. As shown in Figure 5, the update management system 500 according to Embodiment 3 differs from the update management system 100 according to Embodiment 1 in that, in addition to the configuration, it further includes a map and route information management device 501.

[0036] In the above-described embodiments 1 and 2, when it was determined in step 201 that an update was necessary, the condition for starting the update was whether or not ECU_B was in redundant processing mode (step 202). In this embodiment, it is possible to determine whether or not redundant processing is in progress based on the vehicle's autonomous driving level. In autonomous driving at level 3 or higher, the driving task is monitored by the system. In other words, the system is the driving entity. Therefore, compared to when the driving entity is a human, it is necessary to ensure the safety of the system, and at least ECUs related to autonomous driving level 3 or higher must have a redundant configuration. Accordingly, a method for determining whether or not an ECU is in redundant processing mode can be adopted by determining the vehicle's autonomous driving level.

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

[0038] One of the conditions for achieving Level 3 or higher autonomous driving is location limitation. That is, highways, 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 on locations where Level 3 or higher autonomous driving can be achieved, it is possible to determine whether or not a location is applicable to Level 3 or higher autonomous driving, that is, whether or not redundant processing is performed. Specifically, the following means 4 to 6 executed by the program control unit 124 can be employed. Note that "autonomous driving" below refers to autonomous driving at a level that requires redundant processing (e.g., Level 3).

[0039] Method 4: Using the map and route information 502 from the map and route information management device 501, the system compares the autonomous driving zone with the vehicle's position. If the vehicle is outside the autonomous driving zone or is more than a predetermined distance away from the zone, the system determines that redundancy processing is not performed and that the system can be updated.

[0040] Method 5: Using map and route information 502 from the map and route information management device 501, the navigation route to the destination is generated by the driver's operation, and it is detected whether the route passes through an automated driving section. If the route does not pass through such a section, it is determined that redundancy processing is not performed and the route can be updated.

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

[0042] By performing the processes described in methods 4 to 6 above, the need to leave the decision of whether or not to perform the update to the driver is reduced, and an improvement in convenience can be expected.

[0043] The embodiments of the present invention described above provide the following effects. (1) An update management system according to one embodiment of the present invention is installed in a vehicle and comprises a plurality of computing devices and an update management device that controls the plurality of computing devices, wherein the plurality of computing devices comprises 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, it restricts the execution of redundant processing by the first computing device and updates the program stored in the second computing device.

[0044] With the above configuration, program updates stored in the second arithmetic unit can be performed while the first arithmetic unit is not performing redundant processing. Therefore, it becomes unnecessary to provide additional program storage areas in the arithmetic unit, which was previously required when updating programs during redundant processing, thereby reducing memory resources and manufacturing costs.

[0045] (2) After updating the program stored in the second computing unit, the update management device, upon determining that the vehicle has stopped, instructs the second computing unit to execute the updated program and updates the program stored in the first computing unit. As a result, the first computing unit also updates its program without the second computing unit performing redundant processing, thus reducing memory resources and manufacturing costs.

[0046] (3) After updating the program stored in the first computing unit, the update management device determines that the vehicle has stopped and instructs the first computing unit to execute the updated program, and also releases the restriction on the execution of redundant processing by the multiple computing units. This makes it possible for both the first and second computing units to resume redundant processing with the updated program.

[0047] (4) The instructions that the update management device gives to the second arithmetic unit include instructions that cause the first arithmetic unit to perform synchronization processing with the program currently being executed before executing the updated program. This eliminates the risk that output values ​​may become discrete at the timing of program switching, causing abnormalities in vehicle control, even if, for example, the first and second arithmetic units have different software configurations.

[0048] (5) The synchronization process includes the process by which the second arithmetic unit outputs a value obtained by recalculating the output value of the first arithmetic unit based on the updated program, the process by which the second arithmetic unit outputs a value identical to the output value of the first arithmetic unit, or the process by which the second arithmetic unit outputs an initial value that the updated program has. This allows the appropriate synchronization process to be selected depending on the nature 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 processing 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 acquiring map and route information, for example, by associating the vehicle's driving status, such as the autonomous driving level, with the map and route information and storing it.

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

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

[0052] 100, 500 Update Management System, 101 First Processing Unit, 102 Second Processing Unit, 103 Vehicle Control Device (Update Management Device), 501 Map / Route Information Management Device

Claims

1. A vehicle-mounted update management system comprising: a plurality of computing devices; an update management device that controls the plurality of computing devices; and a map / route information management device. The plurality of arithmetic units include at least a first arithmetic unit and a second arithmetic unit. The update management device acquires map and route information from the map and route information management device, determines whether the second computing device is performing redundant processing based on the vehicle's driving status and the map and route information, and updates the program stored in the second computing device if it determines that redundant processing is not being performed. An update management system characterized by the following features.

2. The update management system according to claim 1, The update management system is characterized in that, when the update management device determines that the second computing unit is not performing redundant processing while the vehicle is in motion, it restricts the execution of redundant processing by the first computing unit.

3. The update management system according to claim 1, The update management device is characterized by determining whether or not the redundant processing is being performed based on the vehicle's autonomous driving level.

4. The update management system according to claim 3, The update management device is characterized in that it determines that the redundant processing is not being performed if the vehicle's position is more than a predetermined distance away from the automated driving section included in the map and route information.

5. The update management system according to claim 4, The aforementioned map and route information management device is capable of generating a route to a predetermined destination. The update management device is characterized in that, if the route does not pass through the section where automatic driving is possible, the plurality of computing units determine that they are not performing the redundant processing.

6. The update management system according to claim 4, The aforementioned map and route information management device is capable of generating a route to a predetermined destination. The update management device is characterized in that, when the route passes through the section where automatic driving is possible, the update management device determines that the plurality of computing units are not performing the redundant processing when the estimated time required for the program update is shorter than the estimated time to arrive at the section where automatic driving is possible.

7. The update management system according to claim 1, The first arithmetic unit, the second arithmetic unit, and the update management device are An update management system characterized by being installed within one of the ECUs of the aforementioned vehicle.

8. The update management system according to claim 1, The update management device, after updating the program stored in the second computing unit, determines that the vehicle has stopped, and then instructs the second computing unit to execute the updated program, and also updates the program stored in the first computing unit. An update management system characterized by the following features.

9. The update management system according to claim 8, After updating the program stored in the first computing unit, the update management device, upon determining that the vehicle has stopped, instructs the first computing unit to execute the updated program and releases the restriction on the execution of the redundant processing by the multiple computing units. An update management system characterized by the following features.

10. The update management system according to claim 8, The instructions that the update management device gives to the second arithmetic unit include instructions that cause the first arithmetic unit to perform synchronization processing with the program currently being executed before executing the updated program. An update management system characterized by the following features.

11. The update management system according to claim 10, 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. An update management system characterized by the following features.

12. The update management system according to claim 10, The synchronization process includes a process in which the second arithmetic unit outputs a value identical to the output value of the first arithmetic unit. An update management system characterized by the following features.

13. The update management system according to claim 10, The synchronization process includes a process in which the second arithmetic unit outputs the initial values ​​of the updated program. An update management system characterized by the following features.

14. The update management system according to claim 1, The update management device partially updates the programs stored in the first and second arithmetic units. An update management system characterized by the following features.

Images