Software management system, program and software update method

Abstract

To properly cancel a campaign and properly notify a user of the reason for the cancellation.SOLUTION: A software management system 100 includes: a vehicle 2 including an ECU storing software and MID 27; and an OTA center 1 that updates the software by wireless communication. When a first error due to the OTA center 1 occurs, the OTC center 1 cancels updating the software and request the vehicle 2 to display explanation of the first error on the MID 27. When a second error different from the first error occurs, the vehicle 2 cancels updating the software, and displays the explanation of the second error on the MID 27 regardless of the request from the OTA center 1.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present disclosure relates to a software management system, 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] If an error occurs during a software update (hereinafter also referred to as a "campaign"), it is desirable to cancel the software update and notify the user of the reason for the cancellation. A campaign may be canceled due to a variety of errors (reason). More specifically, a campaign may be canceled due to an error caused by the server (the OTA center described below) that transmits the software, or due to an error caused by the vehicle that receives the software. It is desirable to appropriately cancel the campaign and appropriately notify the user of the reason for the cancellation.

[0005] The present disclosure has been made to solve the above-mentioned problems, and one of the objectives of the present disclosure is to appropriately cancel a campaign and to appropriately notify users of the reason for the cancellation. [Means for solving the problem]

[0006] (1) A software management system according to an embodiment of the present disclosure includes a vehicle including a control device and a display device in which software is stored, and a server that updates the software via wireless communication. When a first error caused by the server occurs, the server requests the vehicle to stop updating the software and display a description of the first error on the display device. When a second error different from the first error occurs, the vehicle stops updating the software and displays a description of the second error on the display device without a request from the server.

[0007] (2) The first error includes at least one of the expiration of a warranty period regarding the operation of the software in the vehicle and a failure to download the software from the server to the vehicle.

[0008] (3) When the software update is stopped due to the first error and communication between the server and the vehicle is not possible, the server notifies a terminal that can be operated by the user of the first error.

[0009] (4) The second error includes at least one of a failure to install or activate the software in the vehicle, a deterioration in wireless communication conditions between the server and the vehicle, and the expiration date for which the software can be updated.

[0010] (5) If the software update is canceled due to a second error, the vehicle displays on the display device a method for retrying the software update or the timing for updating the software.

[0011] In the above configurations (1) to (5), when a first error caused by the server occurs, the server stops the software update and displays an explanation of the first error on the vehicle in response to a request from the server. This makes it possible to take measures in line with the intentions of the server side of the software development company, etc. (for example, to prevent the vehicle side from proceeding with the software update even if the vehicle side attempts to proceed with the software update). On the other hand, when a second error other than the above occurs, the vehicle itself stops the software update and displays an explanation of the second error, thereby reducing the server's management costs for the vehicle (cost for the server to determine the reason for the cancellation and to send a request to the vehicle). In addition, it becomes possible to notify the user even if the vehicle is in an environment where wireless communication is not possible.

[0012] (6) A program according to an embodiment of the present disclosure is executed by a server or a vehicle. The program includes a step of, when a first error caused by the server occurs, the server cancels an update of software in a control device of the vehicle and requests the vehicle to display an explanation of the first error on a display device of the vehicle, and a step of, when a second error different from the first error occurs, the vehicle cancels the update of the software and displays an explanation of the second error on a display device of the vehicle itself without a request from the server.

[0013] (7) 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 the steps of, when a first error caused by the server occurs, the server cancels the software update and requests the vehicle to display an explanation of the first error on a display device of the vehicle, and, when a second error different from the first error occurs, the vehicle cancels the software update and displays an explanation of the second error on a display device of the vehicle itself without a request from the server.

[0014] According to the program of (6) or the method of (7) above, similarly to the configuration of (1) above, the campaign can be appropriately stopped and the user can be appropriately notified of the reason for the stop. Effect of the Invention

[0015] According to the present disclosure, it is possible to appropriately cancel a software update (campaign) and to appropriately notify a user of the reason for the cancellation in an appropriate manner. [Brief description of the drawings]

[0016] [Figure 1] 1 is a diagram illustrating a schematic configuration of a software management 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] 13 is a flowchart showing a processing procedure for canceling a campaign at the OTA center. [Figure 6] 10 is a flowchart showing a processing procedure for canceling a campaign in a vehicle. 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 a software management system according to an embodiment of the present disclosure. The software management 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 software management 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, and the like 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 notification of the reason for canceling a software update (campaign) is also output from the network interface 114 to the user (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, a multi-information display (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 the MID 27. The input device 26 may be a physical switch or button. The MID 27 is, for example, a 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 two-way 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] <Campaign Cancellation> When a software update (campaign) is canceled, the user is notified of the cancellation. More specifically, the campaign may be canceled due to a reason attributable to the OTA center 1 that transmits the software, or due to a reason attributable to the vehicle 2 that receives the software. It is desirable to appropriately notify the user of the reason for the cancellation of the campaign.

[0036] Therefore, in this embodiment, the mode of notification to the user is switched depending on the reason for canceling the campaign. More specifically, if the reason for canceling the campaign is a first error caused by the OTA center 1, the reason for the cancellation (an explanation of the first error) is notified to the user from the OTA center 1 via the vehicle 2. If the reason for canceling the campaign is a second error different from the first error, the reason for the cancellation (an explanation of the second error) is notified to the user from the vehicle 2 itself.

[0037] Note that "notifying the user of the reason for the cancellation" means displaying the reason for the cancellation on the MID 27 (or instrument panel) of the vehicle 2, or transmitting the display content from the OTA center 1 to the vehicle 2 and displaying it on the MID 27. However, as described later, there are also cases where the reason for the cancellation is notified to the user terminal 3. Specific examples of the first and second errors will be described below.

[0038] <First Error> The first error may include at least one of the following errors A and B.

[0039] (A) Expiration of the warranty period The software developer determines the period (for example, several months to several years) for which the software developer guarantees the operation of the new software to be updated. Generally, the possibility of the vehicle hardware breaking down or being replaced (modified) increases as time passes. As a result, when the warranty period has elapsed, a situation may occur in which the software does not operate normally due to a hardware abnormality or a mismatch between the hardware and the software. Therefore, the campaign is canceled. This is based on the software developer's judgment that the proper operation of the software cannot be guaranteed when the warranty period has elapsed, and that it is preferable not to use excessively old functions. In this case, the OTA center 1 cancels the campaign, and the OTA center 1 notifies the vehicle 2 of the reason for the cancellation, that the warranty period has elapsed.

[0040] (B) Download issues An error (e.g., a timeout) may occur while the vehicle 2 is downloading software from the OTA center 1. Since the OTA center 1 can detect the error, the OTA center 1 notifies the vehicle 2 of the reason for canceling the download, that is, the error occurred during the download.

[0041] <Second error> The second error may include at least one of the following errors C, D, E.

[0042] (C) Installation / Activation Problems There is a possibility that an error may occur during the process of installing the downloaded software in the storage 223 of the individual ECU 22, or during the process of activating the installed software. Since the installation and activation are performed within the vehicle 2 (the central ECU 21 and / or the individual ECU 22), it is preferable for the vehicle 2 to detect these errors by itself. Therefore, if an error occurs during the installation / activation by the vehicle 2, the vehicle 2 will cancel the campaign and notify the user of the reason for the cancellation (displayed on the MID 27, etc.).

[0043] (D) Deterioration of wireless communication conditions When vehicle 2 is parked in an underground parking lot or in the shadow of a large building, the wireless communication conditions between the OTA center 1 and vehicle 2 may be poor. In such cases, since it is difficult for the OTA 1 to transmit information (commands / notifications) to vehicle 2, the campaign is cancelled by vehicle 2 and a notice is sent stating the reason for the cancellation, that the wireless communication conditions have deteriorated.

[0044] (E) Expiration date has expired An expiration date is set for the campaign. The expiration date is the period given from the start of downloading (or from the time downloading becomes possible) to the completion of activation, and is, for example, 10 days. Whether or not this expiration date has passed can be measured by either the OTA center 1 or the vehicle 2. However, since there are many vehicles 2 under the management of the OTA center 1, the computational load (management cost) of managing the expiration dates of all the vehicles 2 can be large. Therefore, the management cost of the OTA center 1 can be reduced by having each vehicle 2 determine whether or not the validity period has passed. Therefore, the vehicle 2 notifies the user of the reason for cancellation, that the expiration date has passed.

[0045] <Processing flow> <Processing on the OTA center side> 5 is a flowchart showing the processing procedure for canceling a campaign at the OTA center 1. The steps included in this flowchart are executed when a predetermined condition is met (for example, at a predetermined interval). Each step is typically realized by software processing by the server 11 (processor 111) of the OTA center 1, but may also be realized by hardware (electrical circuitry) within the server 11. Hereinafter, steps are abbreviated as S.

[0046] In S11, the OTA center 1 determines whether an error (error A) has occurred due to the expiration of the warranty period. If the warranty period has expired (YES in S11), the OTA center 1 advances the process to S13. If the warranty period has not expired (NO in S11), the OTA center 1 advances the process to S12.

[0047] In S12, the OTA center 1 determines whether an error (error B) due to a download problem has occurred. If a download problem has occurred (YES in S12), the OTA center 1 advances the process to S13. If a download problem has not occurred (NO in S12), the OTA center 1 ends the series of processes. Note that the order of the processes in S11 and S12 can be reversed.

[0048] In S13, the OTA center 1 cancels the campaign. The OTA center 1 then determines whether wireless communication is possible between the OTA center 1 and the vehicle 2 (S14). If wireless communication is possible (YES in S14), the OTA center 1 notifies the vehicle 2 of the reason for canceling the campaign (the appropriate one of error A and error B) (S15). That is, the OTA center 1 requests the vehicle 2 to display an explanation of the reason for canceling the campaign on the MID 27. In response to this request, the vehicle 2 displays an explanation of error A or B on the MID 27 (S21).

[0049] On the other hand, if wireless communication between the OTA center 1 and the vehicle 2 is not possible due to a communication failure or the like (NO in S14), the OTA center 1 notifies the user terminal 3 of the reason for the cancellation of the campaign (error A or B) (S16). In response to the notification (request) from the OTA center 1, the user terminal 3 displays an explanation of error A or B on the display 33 (S31).

[0050] <Vehicle side processing> 6 is a flowchart showing a processing procedure for canceling a campaign in the vehicle 2. The steps included in this flowchart are also executed when a predetermined condition is satisfied (for example, at a predetermined interval). Each step is typically realized by software processing by the individual ECU 22 (processor 221) of the vehicle 2, but may also be realized by hardware (electrical circuitry) in the individual ECU 22.

[0051] In S401, the vehicle 2 determines whether an error (error C) has occurred due to an installation / activation problem. If an installation / activation problem has occurred (YES in S401), the vehicle 2 advances the process to S402 and cancels the campaign. Furthermore, the vehicle 2 displays on the MID 27 that the reason for canceling the campaign is an installation / activation problem (S403).

[0052] If no error due to a malfunction in installation / activation has occurred (NO in S401), the vehicle 2 proceeds to the process in S404.

[0053] In S404, the vehicle 2 determines whether an error (error D) due to a deterioration in the wireless communication situation has occurred. If an error due to a deterioration in the wireless communication situation has occurred (YES in S404), the vehicle 2 advances the process to S405 and cancels the campaign. The vehicle 2 also displays on the MID 27 that the reason for canceling the campaign is the deterioration in the wireless communication situation (S406). Furthermore, the vehicle 2 may display on the MID 27 a method for retrying the campaign (S407). More specifically, the vehicle 2 may display on the MID 27 a message encouraging the user to move to a place where the wireless communication situation can be improved (such as on the ground or in an open area). This allows the user to take measures to improve the wireless communication situation.

[0054] If an error due to deterioration of the wireless communication conditions has not occurred (NO in S404), the vehicle 2 proceeds to the process in S408.

[0055] In S408, the vehicle 2 determines whether an error (error E) due to the expiration date has occurred. If an error due to the expiration date has occurred (YES in S408), the vehicle 2 advances the process to S409 and cancels the campaign. The vehicle 2 also displays on the MID 27 that the reason for canceling the campaign is the expiration date (S410). Furthermore, the vehicle 2 may display on the MID 27 the method and / or time when the campaign can be retried (S411). For example, the vehicle 2 may display on the MID 27 that the campaign must be completed within the expiration date, or that the user is prompted to retry the campaign (such as the operation to permit software update), or that the expiration date of the next campaign. This allows the user to perform the necessary operations while being aware of the expiration date.

[0056] If no error has occurred due to the expiration date (NO in S408), the vehicle 2 ends the series of processes. The order of the processes of S401, S404, and S408 can be changed as appropriate. The reason for the cancellation may be displayed on the display 33 of the user terminal 3 instead of or in addition to the MID 27 of the vehicle 2.

[0057] As described above, in this embodiment, when a first error (errors A and B) caused by the OTA center 1 occurs, the campaign is stopped at the OTA center 1 side, and an explanation of the first error is displayed on the vehicle 2 in response to a request from the OTA center 1. This makes it possible to take measures in line with the intentions of the OTA center 1 side (software development company, etc.) (for example, to prevent the vehicle 2 side from proceeding with the campaign even if the vehicle 2 side attempts to proceed with it). On the other hand, when another second error (errors C to E) occurs, the vehicle 2 itself stops the campaign and displays an explanation of the second error, thereby reducing the cost of managing a large number of vehicles by the OTA center 1. In addition, it becomes possible to notify the user even if the vehicle 2 is in an environment where wireless communication is not possible.

[0058] 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]

[0059] 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, 51,61,71 system program, 52,62,72 control program, 53 update program, 54 license information, 81 header, 82 body, 100 software management system.

Claims

1. a vehicle including a control device and a display device in which software is stored; a server that updates the software via wireless communication; When a first error caused by the server occurs, the server requests the vehicle to stop updating the software and to display a description of the first error on the display device; A software management system in which, if a second error occurs due to the expiration of a given expiration date from the start of downloading the software or from the time downloading becomes possible to the completion of activation of the software, the vehicle cancels the software update and, without a request from the server, displays on the display device that the reason for canceling the software update is the expiration of the expiration date and that the software update must be completed within the expiration date.

2. A software management system as described in claim 1, wherein if the software update is canceled due to the second error, the vehicle further displays the expiration date for the next software update on the display device.

3. A software management system as described in claim 2, wherein if the software update is canceled due to the second error, the vehicle further displays on the display device a method for retrying the software update or the timing for updating the software.

4. 4. The software management system according to claim 1, wherein the first error includes at least one of the following: expiration of a warranty period for the operation of the software in the vehicle; and a failure to download the software from the server to the vehicle.

5. A software management system as described in any one of claims 1 to 3, wherein when the software update is canceled due to the first error and the server and the vehicle are unable to communicate, the server notifies a terminal that can be operated by a user of the vehicle of the first error.

6. A program executed by a server and a vehicle, When a first error caused by the server occurs, the server stops updating software of the control device of the vehicle, and the server requests the vehicle to display a description of the first error on a display device of the vehicle; and when a second error occurs due to the expiration of a given expiration date from when downloading of the software begins or from when downloading becomes possible to when activation of the software is completed, the vehicle cancels the software update and, without a request from the server, displays on the display device a message to the effect that the reason for canceling the software update is the expiration date and that the software update must be completed within the expiration date.

7. A software update method for updating software of a control device of a vehicle via wireless communication, comprising: when a first error caused by a server occurs, the server stops the software update and requests the vehicle to display a description of the first error on a display device of the vehicle; a step of, when a second error occurs due to the expiration of a given expiration date from when downloading of the software begins or from when downloading becomes possible to when activation of the software is completed, the vehicle cancels the software update and, without a request from the server, the vehicle itself displays on the display device a message that the reason for canceling the software update is the expiration date and that the software update must be completed within the expiration date.

Images