Server, program and software update method

Abstract

To improve the convenience for a user, while properly reflecting the intention of the user, in updating software.SOLUTION: An OTA center 1 updates software on an ECU of a vehicle 2 through wireless communication. A processor 111 is configured to issue a command to start updating first and second software when obtaining an approval for updating the first and second software. When an error occurs during updating the first software, the processor 111 makes a request again for the approval to update the first software and selectively makes a request again for the approval to update the second software based on predetermined association between the first software and the second software, before re-executing the update of the first software and the second software.SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] The present disclosure relates to a server, a program, and a software update method. [Background technology]

[0002] Research and development is underway on OTA (Over The Air) technology, which updates software (vehicle control programs) stored in a vehicle control device (ECU: Electronic Control Unit) via wireless communication. For example, JP 2017-149323 A (Patent Document 1) discloses a vehicle control system that can safely update software without impairing user convenience. When it is determined that the location of the vehicle's electronic key is inside the vehicle, the portable device transmits a signal to a server requesting download of update software. The ECU downloads the update software transmitted from the server via the portable device to update the software. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2017-149323 A Summary of the Invention [Problem to be solved by the invention]

[0004] When updating software on electrical devices such as personal computers and smartphones, it is common to require the user's permission beforehand. Similarly, when updating ECU software, it is possible to obtain the user's permission in advance. When updating multiple pieces of software, the user's permission may be obtained for each piece of software.

[0005] The present inventors have focused on the fact that an error may occur during software update processing executed after obtaining user permission. When an error occurs, it may be an issue as to whether to request user permission again. If user permission is requested again each time, the permission process may become cumbersome for the user. On the other hand, if user permission is uniformly not required, there is a possibility that the user's intention may not be appropriately reflected in the software update processing.

[0006] The present disclosure has been made to solve the above problems, and an object of the present disclosure is to improve user convenience in software updates while appropriately reflecting the user's intentions. [Means for solving the problem]

[0007] (1) A server according to an embodiment of the present disclosure updates software of a vehicle control device via wireless communication. The server includes a processor that executes a process for obtaining user permission for the software update, and an interface that outputs a request for obtaining permission to the vehicle or a user terminal. When permission for the first and second software updates is obtained, the processor commands the start of update processes for the first and second software. When an error occurs in the update process for the first software, the processor requests permission again for the first software, and selectively requests permission for the second software based on a predetermined association between the first software and the second software, prior to re-executing the update processes for the first and second software.

[0008] (2) If the first software and the second software are associated with each other, the processor re-executes the update process for the second software without requesting permission again.

[0009] (3) If the error is a simple error that has been classified in advance, the processor re-executes the update process for both the first and second software without requesting permission again.

[0010] (4) If the first software and the second software are not associated with each other, the processor requests permission again for the second software.

[0011] In the above configurations (1) to (4), if an error occurs in the update process of the first software, it is determined whether to request the user's permission again based on the association between the first software and the second software. Since permission is requested only once for software that is associated with each other, the user can save the trouble of the permission operation, and the user's convenience can be improved. On the other hand, since permission is requested again for each piece of software that is not associated with each other, the user's intention can be appropriately reflected. Therefore, according to the above configurations (1) to (4), the user's convenience can be improved while the user's intention is appropriately reflected. Furthermore, by not requiring the user's permission for simple errors regardless of the association of the software, the trouble of the permission operation can be further reduced, and the user's convenience can be further improved.

[0012] (5) A program according to another aspect of the present disclosure causes a computer to execute the program to update software of a control device of a vehicle via wireless communication. The program, when executed by the computer, includes the steps of: outputting a request to obtain user permission for the software update to the vehicle or a user terminal; and, when permission for the first and second software updates is obtained, instructing the computer to start update processing of the first and second software. The output step includes, when an error occurs in the update processing of the first software, requesting permission again for the first software, and selectively requesting permission for the second software based on a predetermined association between the first software and the second software, prior to re-executing the update processing of the first and second software.

[0013] (6) A software update method according to yet another aspect of the present disclosure updates software of a control device of a vehicle via wireless communication. The software update method includes a step of outputting a request for obtaining user permission for the software update to the vehicle or a user terminal, and a step of issuing a command to start update processing of the first and second software when permission for the updates of the first and second software is obtained. The output step includes a step of, when an error occurs in the update processing of the first software, requesting permission again for the first software, and selectively requesting permission for the second software based on a predetermined association between the first software and the second software, prior to re-executing the update processing of the first and second software.

[0014] According to the program of (5) and the method of (6) above, similarly to the configuration of (1) above, it is possible to improve user convenience while appropriately reflecting the user's intention. Effect of the Invention

[0015] According to the present disclosure, in software updates, it is possible to improve user convenience while appropriately reflecting the user's intentions. [Brief description of the drawings]

[0016] [Figure 1] 1 is a diagram illustrating a schematic configuration of an information processing system according to an embodiment of the present disclosure. [Diagram 2] FIG. 1 is a block diagram showing a typical configuration example of an OTA center. [Diagram 3] FIG. 1 is a block diagram showing a typical configuration example of a vehicle. [Figure 4] FIG. 1 is a block diagram showing a typical configuration example of a user terminal. [Diagram 5] FIG. 13 is a diagram for explaining software association. [Figure 6] 11 is a flowchart showing the entire process of updating software. [Figure 7]13 is a flowchart showing a first example of a processing procedure of a re-update process. [Figure 8] 13 is a flowchart showing a second example of the processing procedure of the re-update process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference characters, and the description thereof will not be repeated.

[0018] [Embodiment Mode] <System configuration> 1 is a diagram illustrating a schematic configuration of an information processing system according to an embodiment of the present disclosure. The information processing system 100 includes an OTA center 1, a vehicle 2, and a user terminal 3 (UE: User Equipment). The OTA center 1 is connected to the vehicle 2 and the user terminal 3 via a network NW so as to be able to communicate with each other.

[0019] The OTA center 1 is a server that provides software for an ECU (see FIG. 3) mounted on a vehicle 2. The OTA center 1 is managed, for example, by a vehicle manufacturer that manufactures the vehicle body (VP: Vehicle Platform). The configuration of the OTA center 1 will be described with reference to FIG. 2.

[0020] The vehicle 2 is managed by a user. The user is typically an individual, but may be, for example, a corporation (such as a transportation business operator) that conducts a business using the vehicle 2. The vehicle 2 may be an autonomous vehicle. In this case, the OTA center 1 may be managed by a manufacturer of an autonomous driving system (ADS) (see FIG. 3) installed in the VP, instead of or in addition to the vehicle manufacturer. However, the vehicle 2 may be a vehicle that is not autonomous and can only be manually driven. The configuration of the vehicle 2 will be described with reference to FIG. 3.

[0021] The user terminal 3 is a terminal operated by a user of the vehicle 2. The user terminal 3 may be a mobile terminal or a fixed terminal. Mobile terminals include, for example, a smartphone, a tablet, a notebook PC (Personal Computer), and a wearable device (such as a smart watch). Fixed terminals include, for example, a desktop PC. The configuration of the user terminal 3 will be described with reference to FIG. 4.

[0022] 1, due to space limitations, only one vehicle 2 is illustrated, but the number of vehicles 2 is arbitrary. Typically, the information processing system 100 includes multiple vehicles 2. The same applies to the user terminals 3.

[0023] 2 is a block diagram showing a typical configuration example of the OTA center 1. The OTA center 1 includes a server 11, an input device 12, a display 13, and a communication device 14. The server 11 includes a processor 111, a memory 112, a storage 113, and a network interface 114. The components of the OTA center 1 are connected to each other via a communication bus.

[0024] The storage 113 is a rewritable non-volatile memory such as a hard disk drive (HDD), a solid state drive (SSD), or a flash memory. The storage 113 stores a system program 51 including an operating system (OS), a control program 52 including computer-readable code required for control calculation, an update program 53 for updating the control program of the vehicle 2, and license information 54 (described later) for obtaining a user's permission for downloading, installing, etc., of the update program 53. The processor 111 is, for example, a central processing unit (CPU) or a micro-processing unit (MPU). The processor 111 realizes various processes by reading the system program 51 and the control program 52, expanding them in the memory 112, and executing them. The network interface 114 controls data communication between the server 11 and other devices (such as the vehicle 2 and the user terminal 3) via the communication device 14. Although details will be described later, a request for obtaining permission for updating the software is also output from the network interface 114 to the vehicle 2 and / or the user terminal 3.

[0025] The input device 12 is a keyboard, a mouse, etc., and receives input from an operator of the server 11. The display 13 displays various information to the operator of the server 11.

[0026] 2 shows an example in which the server 11 includes one processor 111, the server 11 may include multiple processors. That is, the server 11 includes one or more processors. The same applies to the memory 112 and the storage 113.

[0027] In this specification, the term "processor" is not limited to a processor in the narrow sense that executes processing by a stored program method, but may include hardwired circuits such as ASICs (Application Specific Integrated Circuits) and FPGAs (Field-Programmable Gate Arrays). Therefore, the term "processor" may be interpreted as a processing circuitry in which processing is defined in advance by computer-readable code and / or hardwired circuits.

[0028] 3 is a block diagram showing a typical configuration example of the vehicle 2. The vehicle 2 includes a central ECU 21, a plurality of discrete ECUs 22, an advanced driver-assistance system (ADAS) 23, an ADS 24, a sensor group 25, an input device 26, an MID 27, and a data communication module (DCM) 28. The discrete ECUs 22 are ECUs divided by function, such as a brake ECU, a steering ECU, a motor generator ECU, and a body ECU. The discrete ECUs 22 may be controllers in which software for realizing the functions of the ADAS 23 and / or the ADS 24 is stored. The components of the vehicle 2 are connected to each other by a wired in-vehicle network such as a controller area network (CAN) or in-vehicle Ethernet (registered trademark).

[0029] The basic configurations of the central ECU 21 and the individual ECU 22 are similar to that of the server 11. The storage 223 of the individual ECU 22 stores software (a system program 71 and a control program 72) executed by the processor 221 of the individual ECU 22. The individual ECU 22 controls a system corresponding to the individual ECU 22 so that the vehicle 2 is in a desired state in response to signals from the sensor group 25 and the like. The systems here may include a brake system, a steering system, a power train system, a body system, and the like, none of which are shown in the figures.

[0030] The processor 211 of the central ECU 21 controls the update process of the software stored in the storage 223 of the individual ECU 22. The central ECU 21 receives (downloads) the software from the OTA center 1 via the DCM 28, and stores (installs) the downloaded software in the storage 223 of the individual ECU 22 at an appropriate timing. Then, the central ECU 21 enables (activates) the installed software at an appropriate timing.

[0031] The ADAS 23 includes, for example, an adaptive cruise control (ACC), an auto speed limiter (ASL), a lane keeping assist (LKA), a pre-crash safety (PCS), and a lane departure alert (LDA). The ADS 24 is configured to be capable of executing automatic driving of the vehicle 2.

[0032] The sensor group 25 includes a sensor configured to detect an external situation of the vehicle 2. The sensor group 25 further includes sensors (none of which are shown) configured to detect information corresponding to a traveling state of the vehicle 2, as well as a steering operation, an accelerator operation, and a brake operation. Specifically, the sensor group 25 may include, for example, a camera 251 (see FIG. 5), a radar, a LIDAR (Laser Imaging Detection and Ranging), a vehicle speed sensor, an acceleration sensor, a yaw rate sensor, and a steering sensor (none of which are shown).

[0033] The input device 26 is, for example, a touch panel provided on a multi-information display (MID). The input device 26 may be a physical switch or button. The MID 27 is, for example, a touch panel display on which map information, vehicle management information, etc. are displayed. An instrument panel (not shown) is also used as an HMI (Human Machine Interface). The DCM 28 is an in-vehicle communication module. The DCM 28 is configured to enable bidirectional data communication between the central ECU 21 and the server 11.

[0034] 4 is a block diagram showing a typical configuration example of the user terminal 3. The user terminal 3 includes an arithmetic processing device 31, an input device 32, a display 33, and a communication device 34. The input device 32 and the display 33 are integrally configured as, for example, a touch panel display. However, the input device 32 may be a dedicated input device (keyboard, mouse, etc.), and the display 33 may be a stationary monitor. Other configurations of the user terminal 3 are similar to those of the server 11 (see FIG. 2).

[0035] <User Agreement> When updating any of the software in the multiple individual ECUs 22, the OTA center 1 requests permission for the update from the user before executing the software update process. When updating two or more pieces of software, permission may be requested from the user for each piece of software. When the user who receives the request operates the MID 27 or the user terminal 3 to permit the update, the OTA center 1 executes the software update process for the software for which permission has been obtained from the user.

[0036] An error may occur during the software update process. When an error occurs, it may be an issue whether to request the user's permission again. In particular, when multiple permissions are requested to update multiple software programs, the multiple permission operations may be troublesome for the user. On the other hand, if user permission is not required across the board, there is a possibility that the user's intentions may not be properly reflected.

[0037] Therefore, when an error occurs during the update process when updating multiple pieces of software, the OTA center 1 determines whether to request the user for permission again based on the association between the multiple pieces of software. In this embodiment, pieces of software that are related to each other are associated with each other in advance. The association of software will be described below.

[0038] <Software Association> Fig. 5 is a conceptual diagram for explaining software association. Here, an example will be described in which the software of the three individual ECUs 22 is updated. As shown in Fig. 5, the three pieces of software are ADS software 41 for controlling the ADS 24, camera software 42 for controlling a camera (not shown) included in the sensor group 25, and MID software 43 for controlling the MID 27.

[0039] The external situation of the vehicle 2 photographed by the camera 251 is used for automatic driving by the ADS 24. In this example, the update contents of the camera software 42 are assumed to be related to the automatic driving by the ADS 24. Therefore, the ADS software 41 and the camera software 42 are associated with each other. On the other hand, the update contents of the ADS software 41 are assumed to be not directly related to the update contents of the MID software 43. Therefore, the ADS software 41 and the MID software 43 are not associated with each other. Similarly, the camera software 42 and the MID software 43 are not associated with each other.

[0040] Each of the software programs is assigned an identification number (such as a product ID). Two or more software programs may be associated with each other using the identification number. For example, the following two methods may be adopted.

[0041] First, the administrator of the OTA center 1 (which may be a software development company or the like) may register information in advance for each piece of software to be updated so that each piece of software has an identification number for the other software associated with it. In the example of FIG. 5, an identification number is assigned to each of the ADS software 41 and the camera software 42. Furthermore, the ADS software 41 has the identification number of the camera software 42. The camera software 42 has the identification number of the ADS software 41. The OTA center 1 can determine that the ADS software 41 and the camera software 42 are associated with each other by reading that they have each other's identification numbers.

[0042] Secondly, the administrator of the OTA center 1 may generate assembly information in advance indicating that multiple pieces of software to be updated belong to the same set (group). In this example, the assembly information includes an identification number of the ADS software 41 and an identification number of the camera software 42. By referring to the assembly information, the OTA center 1 can determine that the ADS software 41 and the camera software 42 are associated with each other.

[0043] <Processing flow> 6 is a flowchart showing the entire processing procedure for software updates. The steps included in this flowchart are executed when a predetermined condition is met (for example, at a predetermined interval). Each step is realized by software processing by the OTA center 1 (processor 111 of server 11), but may also be realized by hardware (electrical circuits) arranged in the OTA center 11. Hereinafter, steps are abbreviated as S. Hereinafter, a situation is assumed in which multiple permissions are requested from the user for multiple software updates.

[0044] In S1, the OTA center 1 determines whether or not permission to update all software has been obtained from the user. If permission to update all software has been obtained (YES in S1), the OTA center 1 starts the update process for all software (S2). If the update process for all software has ended normally (YES in S3), the OTA center 1 ends the series of processes. On the other hand, if an error occurs in the update process for at least some of the software (NO in S3), the OTA center 1 executes the update process again (S4).

[0045] <Example 1> 7 is a flowchart showing a first example of a processing procedure of the re-update processing (the processing of S4 in FIG. 6). In S411, the OTA center 1 identifies software in which an error occurred in the update processing (hereinafter, referred to as "update-failed software").

[0046] In S412, the OTA center 1 determines, for each of the multiple software to be updated (excluding the update-failed software), whether or not the software (hereinafter referred to as "other software") is associated with the update-failed software. The method of associating software with each other has been described with reference to FIG. 5, and therefore will not be described again. Note that the update-failed software corresponds to the "first software" according to the present disclosure. The other software corresponds to the "second software" according to the present disclosure.

[0047] If other software is associated with the update-failed software (YES in S412), the OTA center 1 advances the process to S413 and again requests the user for permission to update the update-failed software (for example, the ADS software 41 in the example of FIG. 5). On the other hand, the OTA center 1 does not request the user for permission to update other software (for example, the camera software 42) (S414). Note that the order of the processes of S413 and S414 can be reversed.

[0048] On the other hand, if other software is not associated with the update-failed software (NO in S412), the OTA center 1 advances the process to S415 and requests the user again for permission to update the update-failed software (e.g., the ADS software 41). Furthermore, the OTA center 1 requests the user again for permission to update other software (e.g., the MID software 43) (S416). The order of the processes of S415 and S416 can also be reversed.

[0049] In S417, the OTA center 1 determines whether the necessary permission has been obtained again from the user. If permission has been obtained again (YES in S417), the OTA center 1 executes the update process for the software for which permission has been obtained again (S418). Thereafter, the process returns to S3 in Fig. 6. On the other hand, if permission could not be obtained this time (NO in S417), the OTA center 1 ends the process without executing the update process again.

[0050] As described above, in this embodiment, when an error occurs during software update processing, re-authorization from the user is selectively requested based on the relevance between the software. Since re-authorization is requested only once for software that are associated with each other, the user can save the trouble of performing the authorization operation, and user convenience can be improved. On the other hand, since re-authorization is requested for each piece of software that is not associated with each other, the user's intention can be appropriately reflected. Therefore, according to this embodiment, the user's convenience can be improved while appropriately reflecting the user's intention.

[0051] <Second Example> 8 is a flowchart showing a second example of the processing procedure of the re-update processing. This flowchart differs from the flowchart of the first example (see FIG. 7) in that it further includes processes of S430 to S433. The other processes of S421 to S428 are similar to the processes of S411 to S418 in the first example, and therefore detailed description thereof will not be repeated.

[0052] The OTA center 1 that has identified the update-failed software determines whether the error that has occurred is a simple error. Simple errors may include, for example, an error that has occurred due to an unstable communication connection, an error that occurs when software transfer inside the vehicle 2 (for example, between ECUs) is interrupted due to a power failure or the like, and the like. Simple errors are distinguished from fatal errors (such as an error that requires a system restart of the vehicle 2). If the error that has occurred is not a simple error (NO in S430), the OTA center 1 advances the process to S422. The process from S422 onwards is the same as the process described with reference to FIG. 7.

[0053] On the other hand, if the error that occurred is a simple error (YES in S430), the OTA center 1 proceeds to the process at S431 and does not request the user to re-authorize the update of the software for which the update has failed. The OTA center 1 also does not request the user to re-authorize the update of other software, regardless of whether the software is associated with the update process software (S432). Then, the OTA center 1 executes the update process of all software again (S433). After that, the process returns to S3 in FIG. 6.

[0054] As described above, if the error is merely a simple error, re-authorization by the user is not required regardless of the relationship between the software. This further reduces the time and effort required for authorization, further improving user convenience.

[0055] The embodiments disclosed herein should be considered to be illustrative and not restrictive in all respects. The scope of the present disclosure is defined by the claims, not by the description of the embodiments described above, and is intended to include all modifications within the meaning and scope of the claims. [Explanation of symbols]

[0056] 1 OTA center, 11 server, 111 processor, 112 memory, 113 storage, 114 network interface, 12 input device, 13 display, 14 communication device, 2 vehicle, 21 central ECU, 22 individual ECU, 211, 221 processor, 212, 222 memory, 213, 223 storage, 214, 224 network interface, 23 ADAS, 24 ADS, 25 sensor group, 26 input device, 27 MID, 3 user terminal, 31 arithmetic processing unit, 311 processor, 312 memory, 313 storage, 314 network interface, 32 input device, 33 display, 34 communication device, 41 ADS software, 42 camera software, 43 MID software, 51, 61, 71 system program, 52, 62, 72 control program, 53 update program, 54 license information, 81 header, 82 Body, 100 Information Processing System.

Claims

1. A server that wirelessly updates software of a vehicle control device, a processor that executes a process for obtaining user consent for the software update; an interface that outputs a request to obtain the permission to the vehicle or a user terminal; The processor, if the permission for updating the first and second software is obtained, commanding the start of an update process of the first and second software; When an error occurs in the first software update process, before re-executing the first and second software update processes, for the first software, requesting the permission again; With respect to the second software, the server selectively requests the permission based on a predetermined association between the first software and the second software.

2. The server of claim 1 , wherein when the first software and the second software are associated with each other, the processor re-executes the update process for the second software without requesting the permission again.

3. 3. The server according to claim 2, wherein the processor, if the error is a pre-classified simple error, re-executes the update process for both the first and second software without requesting the permission again.

4. The server according to any one of claims 1 to 3, wherein if the first software and the second software are not associated with each other, the processor requests the permission again for the second software.

5. A program executed by a computer to update software of a vehicle control device via wireless communication, a step of outputting, when executed by the computer, a request for obtaining user consent regarding the software update to the vehicle or a user terminal; and if the permission for updating the first and second software is obtained, instructing the start of an update process of the first and second software; When an error occurs in the first software update process, the output step includes, prior to re-execution of the first and second software update processes, for the first software, requesting the permission again; and for the second software, selectively requesting the permission based on a predetermined association between the first software and the second software.

6. A software update method for updating software of a control device of a vehicle via wireless communication, comprising: outputting a request for obtaining user consent regarding the software update to the vehicle or a user terminal; and if the permission for updating the first and second software is obtained, instructing the start of an update process of the first and second software; When an error occurs in the first software update process, the output step includes, prior to re-execution of the first and second software update processes, for the first software, requesting the permission again; The software update method includes the step of selectively requesting the permission for the second software based on a predetermined association between the first software and the second software.

Images