Information processing device for vehicles, software update system for vehicles, and program for vehicles

Abstract

To prevent update of software from being started when an occupant wants to use a vehicle.SOLUTION: An OTA master is configured to: make an advance notification before starting an update with update software (step S120) when determining that an occupant is present in a vehicle cabin (step S110: YES); and start the update with the update software (step S150) on condition that a signal indicating an approval of the update with the update software is acquired after the advance notification (step S140: YES); or start the update with the update software without the advance notification (step S150) when determining that no occupant is present in the vehicle cabin (step S110: NO).SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] This invention relates to an information processing device for vehicles, a software update system for vehicles, and a program for vehicles.

Background Art

[0002] The software update system disclosed in Patent Document 1 includes a server and a terminal. The server and the terminal are communicably connected via a communication network. When a predetermined date and time arrives, the server transmits data for updating the software of the terminal to the terminal. When the terminal receives the transmitted data, it updates its own software.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] The software of the electronic control device mounted on a vehicle may be updated. The software update in a vehicle is performed when the vehicle system is off. Therefore, during the software update, the vehicle cannot be driven. Thus, if the time when the user tries to use the vehicle overlaps with the software update time, the user cannot use the vehicle until the software update is completed.

Means for Solving the Problems

[0005] The vehicle information processing device for solving the above problems is capable of receiving update software for an electronic control unit installed in the vehicle, updating the software of the electronic control unit with the update software, determining whether or not there is an occupant in the vehicle's cabin, and notifying the occupant to choose whether or not to start the update to the update software. If it is determined that there is an occupant in the cabin, the notification is given before starting the update to the update software. If it is determined that there is no occupant in the cabin, the update to the update software is started without giving the notification.

[0006] A vehicle software update system for solving the above problems comprises: a first device for detecting the presence of an occupant in the vehicle's cabin; a second device for notifying the occupant in the cabin of information by light or sound; a third device for receiving instructions from the occupant in the cabin; an electronic control unit mounted in the vehicle; and an information processing device mounted in the vehicle that controls the updating of the software of the electronic control unit, wherein the information processing device receives update software for the electronic control unit, updates the software of the electronic control unit with the update software, and detects the presence of an occupant in the vehicle's cabin. Based on the output, the system can determine whether or not there is an occupant in the vehicle compartment, and use the second device to notify the occupant whether or not to start updating to the update software. If it is determined that there is an occupant in the vehicle compartment, the system will give the notification before starting the update to the update software, and after giving the notification, it will start the update to the update software, provided that it has received a signal from the third device indicating that the update to the update software has been authorized. If it is determined that there is no occupant in the vehicle compartment, the system will start the update to the update software without giving the notification.

[0007] A vehicle program for solving the above problems is applied to a vehicle equipped with an electronic control unit and an information processing unit that controls the updating of the software of the electronic control unit, and causes the information processing unit to perform the following actions: receive update software for the electronic control unit; update the software of the electronic control unit with the update software; determine whether or not there are occupants in the vehicle's cabin; if it is determined that there are occupants in the cabin, notify the occupants to choose whether or not to start updating to the update software before starting the update to the update software; and if it is determined that there are no occupants in the cabin, start updating to the update software without giving the notification. [Effects of the Invention]

[0008] Each of the above technical concepts prevents software updates from starting when the occupants want to use the vehicle. [Brief explanation of the drawing]

[0009] [Figure 1] This is a schematic diagram of the vehicle's configuration. [Figure 2] This is a flowchart illustrating the processing steps for the first process. [Figure 3] This is a flowchart illustrating the processing steps for the second process. [Figure 4] This table shows the patterns of the situation at the start of the second processing stage. [Figure 5] This is a diagram illustrating an example of a video used for re-evaluation. [Figure 6] This is a diagram illustrating an example of a video for selection. [Figure 7] This is a time chart illustrating an example of the execution timing of the first and second processes. [Modes for carrying out the invention]

[0010] Hereinafter, an embodiment of a vehicle software update system, including a vehicle information processing device, will be described with reference to the drawings. <Outline of the vehicle configuration> As shown in Figure 1, the vehicle 100 is equipped with an OTA master 10. The OTA master 10 is equipped with a processing circuit 12. The processing circuit 12 is equipped with a CPU 20, a first memory 21, a second memory 22, and a third memory 23. The first memory 21 is a non-volatile storage medium. The first memory 21 is electrically rewritable. The first memory 21 functions as storage for data received from an external source, for example. The second memory 22 is a non-volatile storage medium. The second memory 22 is electrically rewritable. The second memory 22 stores various software. One of the software is a program W that describes the processing that the CPU 20 should execute. The software includes various data necessary for the CPU 20 to execute program W. The third memory 23 is a volatile storage medium. The OTA master 10 is equipped with a communication module 14. The communication module 14 is a communication circuit for wireless communication with the outside via an external communication network. The OTA master 10 is equipped with a real-time clock 16. The real-time clock 16 is a circuit that generates date and time information. The OTA master 10 is an information processing device installed in the vehicle 100. The OTA master 10 is also an electronic control device installed in the vehicle 100.

[0011] Vehicle 100 is equipped with multiple specific control devices 90. In Figure 1, three of the multiple specific control devices 90 are shown as representative examples. Each specific control device 90 is an electronic control device that controls a specific of the multiple on-board devices. One of the multiple on-board devices is the engine, which is the power source of vehicle 100. Another of the multiple on-board devices is a hydraulic brake system. Therefore, examples of the above specific control devices 90 include the engine ECU and the brake ECU. Other on-board devices include the air conditioning system, meter display device, car navigation system, audio system, and turn signal system. Each specific control device 90 is assigned a unique identification number in advance. Each specific control device 90 can communicate with the OTA master 10 via the bus 95.

[0012] Each specific control device 90 is equipped with a processing circuit similar to that of the OTA master 10. Specifically, the specific control device 90 includes a CPU, a non-volatile first memory, a non-volatile second memory, and a volatile third memory. The second memory stores various software S for controlling the target in-vehicle device. The non-volatile memory used in this embodiment, including the OTA master 10, has a double-bank structure. In this type of double-bank memory, there are two storage areas. When data is being read from one storage area, it is possible to write to the other storage area.

[0013] Vehicle 100 is equipped with multiple pressure sensors 80. In Figure 1, one of the multiple pressure sensors 80 is shown as a representative example. A pressure sensor 80 is provided for each seat in vehicle 100. The pressure sensor 80 is attached to the seat where the occupant sits. The pressure sensor 80 detects the seat pressure Y, which is the pressure acting on the seat. The pressure sensor 80 is connected to the OTA master 10. The pressure sensor 80 outputs the detected seat pressure Y to the OTA master 10. The pressure sensor 80 is the first device for detecting the presence of an occupant in the vehicle interior of vehicle 100.

[0014] Vehicle 100 is equipped with a display 50. The display 50 is located inside the passenger compartment of vehicle 100. The display 50 comprises a drive circuit and a display screen. The display 50 is connected to the OTA master 10. The display 50 displays images on its screen corresponding to command signals output by the CPU 20 of the OTA master 10. The display 50 is a touch panel. That is, when an occupant performs an input operation on the display screen of the display 50, the display 50 outputs a signal corresponding to that input operation to the OTA master 10. In this way, the display 50 is a second device for notifying occupants inside the passenger compartment of information using light. Furthermore, the display 50 is a third device for receiving instructions from occupants inside the passenger compartment.

[0015] Vehicle 100 is equipped with an ignition switch 70. The ignition switch 70 is a switch used by the occupant to start vehicle 100. By operating the ignition switch 70 on or off by the occupant, the system of vehicle 100 is turned on or off. The ignition switch 70 may also be referred to as a start switch or a system start switch.

[0016] Vehicle 100 is equipped with a battery 60. The battery 60 supplies power to the OTA master 10, each specific control device 90, the display 50, each pressure sensor 80, and the ignition switch 70. With this power, each onboard component can operate as follows: The OTA master 10 continues to operate in the background not only when the vehicle 100's system is on, but also when the vehicle 100's system is off. The same applies to each pressure sensor 80. Each specific control device 90 and the display 50 continue to operate when the vehicle 100's system is on, but basically stop operating when the vehicle 100's system is off. However, each specific control device 90 and the display 50 will temporarily start up in response to a command from the CPU 20 of the OTA master 10, even when the vehicle 100's system is off. Thus, the state in which the vehicle 100's system is on is the state in which each specific control device 90 is running. The state in which the vehicle 100's system is on includes the state in which the vehicle 100 is drivable and the so-called accessory-on state. The accessory-on state means that the vehicle 100 is unable to drive, but some onboard components are usable. On the other hand, the system-off state of the vehicle 100 means that each specific control device 90 is not activated. The OTA master 10 receives signals indicating the status of the vehicle 100 in response to the on / off operation of the ignition switch 70. This allows the OTA master 10 to determine whether the system of the vehicle 100 is on or off.

[0017] The plurality of in-vehicle products including the OTA master 10, each specific control device 90, the display 50, each pressure sensor 80, the ignition switch 70, and the battery 60 described above constitute a software update system for a vehicle.

[0018] <OTA server> The OTA server 500 is a management server provided outside the vehicle 100. The OTA server 500 manages software information for a plurality of pre-registered vehicles. The OTA server 500 stores the latest software applicable to each vehicle according to classifications such as vehicle type and model, for example. The OTA server 500 notifies whether there is new update software applicable to a vehicle in response to a request from each vehicle, or transmits the new update software to the target vehicle.

[0019] <Outline of the functions of the OTA master> The CPU 20 of the OTA master 10 can execute the first process and the second process by executing the program W stored in the second memory 22. The first process and the second process are processes for controlling software updates in each specific control device 90. By performing the first process and the second process, the CPU 20 updates the software of each specific control device 90 using wireless communication. Note that the technology of updating software using wireless communication is sometimes referred to as OTA (Over The Air).

[0020] In the first process, the CPU 20 downloads update software for the specific control device 90. That is, the CPU 20 receives the update software from the OTA server 500 and stores the received update software in the first memory 21. Also, in the first process, the CPU 20 installs the update software in the target specific control device 90. That is, the CPU 20 stores the update software in the second memory of the target specific control device 90.

[0021] In the second process, the CPU 20 updates the software of the specific control device 90 to the update software at a predetermined scheduled date and time. The CPU 20 may or may not provide prior notification to the occupants during this update. Prior notification is a notification allowing the occupants to choose whether or not to begin the update to the update software. The CPU 20 uses the presence or absence of occupants in the vehicle as information to determine whether or not to provide prior notification. Specifically, the CPU 20 determines whether or not there are occupants in the vehicle based on the detection results of the pressure sensor 80. If the CPU 20 determines that there are occupants in the vehicle at the scheduled update date and time, it provides prior notification before starting the update to the update software. In this case, after providing prior notification, the CPU 20 begins the update to the update software, provided that it receives a signal from the display 50 indicating that the update to the update software has been authorized in response to the occupants' actions. On the other hand, if the CPU 20 determines that there are no occupants in the vehicle, it begins the update to the update software without providing prior notification. Furthermore, if the CPU 20 receives a signal from the display 50 indicating that the update to the update software has been rejected in response to the occupant's actions after providing prior notification, it will use the display 50 to notify the occupant of a new proposed date and time for the update to the update software. In addition, even if the CPU 20 has not received a signal from the display 50 indicating that the update to the update software has been approved after providing prior notification, it will start the update to the update software if it determines that the occupant has left the vehicle.

[0022] Updating to the update software means activating the update software. In other words, updating to the update software means changing the settings of the specific control device 90 so that it performs processing by referring to the update software. Updating to the update software is sometimes referred to as activating. In this embodiment, the update to the update software is performed while the vehicle 100 system is off. That is, the update to the update software is performed while each specific control device 90, except for the specific control device 90 to be updated, is not running. The specific control device 90 to be updated is set to be temporarily started only when performing the update process itself, even when the vehicle 100 system is off.

[0023] <Method for calculating scheduled date and time> In the first and second processes, CPU 20 may provide information on the scheduled date and time for updating the software. This section explains how CPU 20 calculates the scheduled date and time. As a prerequisite, CPU 20 constantly stores the following necessary data in the first memory 21. The necessary data is the time when the vehicle 100 system was turned on and the time when the vehicle 100 system was turned off, covering a predetermined period from the present time. The predetermined period is, for example, one month. Based on this necessary data, CPU 20 calculates candidate dates for a new scheduled date and time. Specifically, CPU 20 calculates the most frequent time, which is the time when the vehicle 100 system is off within the predetermined period. At this time, CPU 20 divides one day into 24 hourly units and calculates the most frequent time. If there are multiple most frequent times, CPU 20 treats the one closest to midnight as the most frequent time. Once CPU 20 has calculated the most frequent time, it calculates the date on which the most frequent time will arrive as soon as possible, based on the present time. Then, CPU20 selects the most frequent time on this date as a candidate for the scheduled date and time.

[0024] <Specific processing steps for the first process> The CPU 20 starts the first process when the vehicle 100's system switches from off to on. As shown in Figure 2, when the CPU 20 starts the first process, it first executes the process in step S10. In step S10, the CPU 20 determines whether or not there is new update software applicable to the vehicle 100. Specifically, the CPU 20 first uses wireless communication to send a request to the OTA server 500 to check for the existence of new update software. If the CPU 20 receives a notification from the OTA server 500 in response to this request that there is no new update software (step S10: NO), the CPU 20 terminates the first process. On the other hand, if the CPU 20 receives a notification from the OTA server 500 that new update software exists (step S10: YES), it proceeds to step S20.

[0025] In step S20, the CPU 20 determines the scheduled date and time for the software update. The CPU 20 determines the scheduled date and time for the update by announcing it through the display 50 or by accepting the date and time entered by the crew member on the display 50. At this time, the CPU 20 announces the scheduled date and time calculated using the date and time calculation method described above. Once the CPU 20 has determined the scheduled date and time for the update, it stores that date and time in the first memory 21. After this, the CPU 20 proceeds to step S30.

[0026] In step S30, the CPU 20 downloads the update software. Specifically, the CPU 20 requests the OTA server 500 to send the update software. Upon receiving the update software distribution package from the OTA server 500 in response to this request, the CPU 20 stores the received distribution package in the first memory 21. The distribution package contains update software for each of the specific control devices 90 to be updated. Each update software contains the identification number of the specific control device 90 to be updated and information on the data capacity of the update software. The CPU 20 reads this information when it downloads the update software package. The CPU 20 then stores the information read from each update software as a single set of update information in the first memory 21. After performing the above processing, the CPU 20 proceeds to step S40.

[0027] In step S40, the CPU 20 installs the update software downloaded in step S30. Specifically, the CPU 20 identifies the specific control unit 90 to which the update software is to be applied by referring to the update information. The CPU 20 then sends the update software and a command signal to store the update software to the identified specific control unit 90. In response to this command signal, the specific control unit 90 to be updated stores the update software in its second memory. Once the CPU 20 has installed the update software on the specific control unit 90 to be updated in this manner, the first process is completed. The CPU 20 completes the above first process as quickly as possible while the vehicle 100's system is on.

[0028] Furthermore, after downloading and installing the update software in the first process, it is possible that another update software may be downloaded and installed again in the first process before the update software is performed in the second process, which will be described later. In such cases, in step S20 of the first process, the CPU 20 will inform the crew of the scheduled update date and time already stored in the first memory 21. If the crew requests a different date and time at this time, that date and time will be stored in the first memory 21 as the latest scheduled date and time. When the CPU 20 stores a new scheduled date and time in the first memory 21, it deletes the previously stored scheduled date and time. Therefore, the CPU 20 will always keep the latest scheduled date and time information in the first memory 21. Then, in the second process, the CPU 20 will update all the software that has been downloaded and installed but has not yet been updated.

[0029] <Specific processing steps for the second process> If the first memory 21 stores the scheduled date and time for the update, the CPU 20 compares this date and time with the actual date and time information generated by the real-time clock 16. When the CPU 20 finds that the actual date and time match the scheduled date and time, it starts the second process. As shown in Figure 4, there are three possible scenarios at this time: Pattern A is when an occupant is using the vehicle 100 and the vehicle 100's system is turned on. Pattern B is when the vehicle 100's system is turned off and an occupant remains inside the vehicle. Pattern C is when the vehicle 100's system is turned off and there is no occupant inside the vehicle.

[0030] As shown in Figure 3, when the CPU 20 starts the second process, it first executes the process in step S100. In step S100, the CPU 20 determines whether the system of the vehicle 100 is off or not. If the system of the vehicle 100 is on (step S100: NO), the CPU 20 proceeds to step S310. The situation in step S100 where the determination is NO corresponds to pattern A described above.

[0031] In step S310, the CPU 20 notifies the crew of new proposed dates and times for updating the software using the display 50. Specifically, the CPU 20 sends a command signal to the display 50 to display a video R for re-determination. In response to this command signal, the display 50 displays the video R for re-determination. As shown in Figure 5, the video R for re-determination includes the following multiple display contents: The first display content is message R1 indicating that the update at the current scheduled date and time is to be canceled. The second display content is a message R2 showing new proposed dates and times and asking the crew whether they accept the proposed dates and times. The CPU 20 calculates the new scheduled dates and times using the date and time calculation method already described. The third display content is an accept button R3 for the crew to accept the proposed new dates and times. The accept button R3 can accept input from the crew. The fourth display content is a reject button R4 for the crew to reject the proposed new dates and times. The reject button R4 can accept input from the crew. If the reject button R4 is pressed, the crew member can enter a new scheduled date and time themselves. As shown in Figure 3, when the CPU 20 displays the re-determination video R on the display 50, it proceeds to step S320.

[0032] In step S320, the CPU 20 determines a new scheduled date and time. Here, the display 50 is configured to function as follows in response to the occupant's operation on the re-determination video R. Specifically, if the occupant operates the accept button R3, the display 50 outputs a schedule acceptance signal to the OTA master 10 indicating that a candidate for a new scheduled date and time has been accepted. Also, if the occupant operates the reject button R4 and enters a candidate for a new date and time themselves, the display 50 outputs a signal to the OTA master 10 corresponding to the information entered by the occupant. In step S320, if the CPU 20 receives the schedule acceptance signal, it determines the candidate for the date and time announced in step S310 as the new scheduled date and time. On the other hand, if the CPU 20 receives information about a scheduled date and time entered by the occupant themselves, it determines that date and time as the new scheduled date and time. Once the CPU 20 has determined a new scheduled date and time, it stores that scheduled date and time in the first memory 21. At this time, the CPU 20 deletes the previously stored scheduled date and time. The CPU 20 stores the new scheduled date and time in the first memory 21 and then terminates the second process. If the CPU 20 terminates the second process after going through the process in step S320, it will execute the second process again when the actual date and time matches the new scheduled date and time determined in step S320.

[0033] Now, in step S100, if the system of vehicle 100 is off (step S100: YES), the CPU 20 proceeds to step S110. The situations in which step S100 is YES are either pattern B above, where the system of vehicle 100 is off and there are occupants inside the vehicle, or pattern C above, where the system of vehicle 100 is off and there are no occupants inside the vehicle.

[0034] In step S110, the CPU 20 determines whether or not there is an occupant in the vehicle. The CPU 20 determines that there is an occupant in the vehicle if at least one of the latest seat pressures Y detected by the multiple pressure sensors 80 is equal to or greater than a predetermined pressure. On the other hand, the CPU 20 determines that there is no occupant in the vehicle if all of the latest seat pressures Y detected by the multiple pressure sensors 80 are less than a predetermined pressure. The predetermined pressure is a value that allows the system to determine that an occupant is seated in the seat. If the CPU 20 determines in step S110 that there is no occupant in the vehicle (step S110: NO), the system proceeds to step S150.

[0035] In step S150, the CPU 20 performs a software update on the specific control unit 90 that is to be updated. Specifically, the CPU 20 refers to the update information stored in the first memory 21. The CPU 20 then identifies the specific control unit 90 that is to be updated. The CPU 20 then sends a command signal to the specific control unit 90 that is to be updated to start updating to the update software. In response to this command signal, the specific control unit 90 that is to be updated performs the update to the update software. The contents of the update have already been explained. Once the specific control unit 90 that is to be updated has performed the update, the CPU 20 deletes the update information from the first memory 21. At the same time, the CPU 20 deletes the scheduled date and time of the update from the first memory 21. This completes the processing in step S150. After executing the processing in step S150, the CPU 20 terminates the second process.

[0036] On the other hand, in step S110, if the CPU 20 determines that there are occupants inside the vehicle (step S110: YES), it proceeds to step S120. In step S120, the CPU 20 uses the display 50 to provide advance notification to the occupant, allowing them to choose whether or not to start updating to the update software. Specifically, the CPU 20 sends a command signal to the display 50 to display a selection video U. In response to this command signal, the display 50 displays the selection video U. As shown in Figure 6, the selection video U includes the following multiple display contents. The first display content is a message U1 indicating that the scheduled date and time for the update has arrived and asking whether it is OK to start the update. The second display content is an acceptance button U2 for the occupant to choose to start the update. The acceptance button U2 is capable of accepting input from the occupant. The third display content is a rejection button U3 for the occupant to reject starting the update. The rejection button U3 is capable of accepting input from the occupant. The fourth display content is a message U4 indicating the estimated length of time required for the update and that the vehicle 100 cannot be used during the update. The estimated time required for the update can be determined from the data size of the update software in the update information. As shown in Figure 3, once the CPU 20 displays the above selection video U on the display 50, it proceeds to step S130.

[0037] In step S130, the CPU 20 determines whether or not the occupant has made an input operation in response to the prior notification made in step S120. Here, the display 50 is configured to function as follows in response to the occupant's input operation on the selection video U. Specifically, if the occupant operates the accept button U2, the display 50 outputs an update grant signal to the OTA master 10 indicating that the update to the update software has been granted. Also, if the occupant operates the reject button U3, the display 50 outputs an update reject signal to the OTA master 10 indicating that the update to the update software has been rejected. In step S130, the CPU 20 determines whether or not it has received either the update grant signal or the update reject signal. If the CPU 20 has not received either signal (step S130: NO), it returns to the process in step S110.

[0038] The process flow from step S130 back to step S110 is designed to handle the following case. For example, if the CPU 20 starts the second process just before the occupant disembarks from vehicle 100, the occupant may be inside the vehicle at the time of the first execution of step S110, but may be out of the vehicle afterward. This situation can be detected by the judgment in the second and subsequent executions of step S110. If the occupant is not inside the vehicle at the time of the second and subsequent executions of step S110 (step S110: NO), the CPU 20 proceeds to step S150. In other words, even if the CPU 20 has not received an update permission signal from the display 50 after giving prior notification in step S120, it will start updating to the update software if it determines that the occupant has left the vehicle. As described above, the CPU 20 terminates the second process after executing the process in step S150.

[0039] Now, in step S130, if the CPU 20 receives an update permission signal or an update rejection signal from the display 50 (step S130: YES), it proceeds to step S140. There are two possible scenarios for proceeding to step S140. One is that the process returns from step S130 to step S110 and then proceeds to step S120 and then to step S130, repeating this loop, during which the determination in step S130 becomes YES. Another is that the determination in step S130 becomes YES immediately after the initial determination in step S110 and the process proceeds to step S130. The timing of when the determination in step S130 becomes YES depends on when the occupant performs an input operation. Incidentally, the occupant may disembark while the above loop is repeating. In this case, the determination in step S110 becomes NO. The processing flow in this case is as already explained.

[0040] In step S140, the CPU 20 determines whether the signal received from the display 50 is an update permission signal. If the signal received from the display 50 is not an update permission signal, that is, if the signal received from the display 50 is an update rejection signal (step S140: NO), the CPU 20 proceeds to step S310. The CPU 20 then executes the process of step S310 described above. That is, if the CPU 20 receives an update rejection signal after providing prior notification, it uses the display 50 to notify the user of a new scheduled date and time for updating the software. After this, the CPU 20 determines the new scheduled date and time by the process of step S320 described above. After that, the CPU 20 terminates the second process.

[0041] On the other hand, in step S140, if the signal obtained from the display 50 is an update permission signal (step S140: YES), the CPU 20 proceeds to step S150. The CPU 20 then executes the process of step S150 described above. That is, after giving prior notification, the CPU 20 starts updating to the update software, provided that it has obtained an update permission signal. After executing the process of step S150, the CPU 20 terminates the second process.

[0042] <Operation of the Embodiment> As shown in Figure 7, suppose that at time T1 the system of vehicle 100 switches from off to on, and the CPU 20 downloads and installs the update software in the first process. Then, when the scheduled date and time T2 for the software update arrives, suppose that the occupants are using vehicle 100 and the system of vehicle 100 is on, which is the situation in pattern A above (step S100: NO). In this case, when the CPU 20 starts the second process, it proceeds to step S310. That is, the CPU 20 does not perform the update to the update software, but notifies and determines a new candidate date and time (steps S310, step S320). Then, suppose that the occupants have finished using vehicle 100. And suppose that the new scheduled date and time T3 arrives under the situation in pattern B above, where the occupants remain in the vehicle with the system of vehicle 100 turned off (steps S100: YES, step S110: YES). In this case, when the CPU 20 starts the second process, it proceeds to step S120 to give advance notification. If the crew member presses the authorization button U2 in response to this prior notification (step S130: YES, step S140: YES), the CPU 20 will perform the update to the updated software (step S150).

[0043] On a different occasion, at a certain time T4, suppose the system of vehicle 100 switches from off to on, and the CPU 20 downloads and installs the update software through the first process. Then, when the scheduled date and time T5 for the software update arrives, suppose the system of vehicle 100 is off and there are no occupants in the vehicle, which is the situation described in pattern C above (step S100: YES, step S110: NO). In this case, the CPU 20 starts the second process and immediately performs the update to the update software (step S150).

[0044] <Effects of the Embodiment> (1) As described above, if an occupant is inside the vehicle when the scheduled software update date and time arrives, the CPU 20 will first confirm with the occupant whether or not to start the software update before starting the update. This prevents the software update from starting if the occupant wants to use the vehicle 100. On the other hand, if an occupant is not inside the vehicle when the scheduled software update date and time arrives, the CPU 20 will start the software update immediately. Therefore, this prevents the update from being postponed even when an occupant is not inside the vehicle.

[0045] (2) If the crew refuses to update the software in response to prior notification, the CPU 20 temporarily suspends the software update. If the software update is temporarily suspended, for example, suppose a configuration is adopted in which the crew then manually updates the software. In this case, the crew may forget to update the software. In this regard, the CPU 20 of this embodiment, if it suspends the software update (step S140: NO), notifies the crew of a new scheduled date and time (step S310) at that time. If a new scheduled date and time is notified at the time the software update is suspended, a new scheduled date and time can be set at that time. Therefore, even if the software update is temporarily suspended, the software can be reliably updated on another occasion.

[0046] (3) For example, after using the vehicle 100, the scheduled update date and time may arrive just as the occupants are about to disembark. In such cases, since the occupants are still inside the vehicle when the scheduled update date and time arrives (Step S110: YES), the CPU 20 issues a prior notification (Step S120). However, in such cases, because the prior notification is issued just before the occupants disembark, the occupants may disembark without noticing the notification. In this regard, the CPU 20 of this embodiment, after issuing a prior notification, if it determines that the occupants are no longer inside the vehicle (Step S110: NO), promptly executes the update to the update software (Step S150). Therefore, even in cases where the scheduled update date and time arrives just as the occupants are about to disembark, the software can be reliably updated without delaying the software update.

[0047] <Example of changes> The above embodiment can be modified as follows. The above embodiment and the following modifications can be combined with each other to the extent that they do not contradict each other technically.

[0048] The content of the second process is not limited to the examples of the above embodiment. The second process only needs to include the following two items: The first item is to start updating the update software if it is determined that there is an occupant in the vehicle, on the condition that an update permission signal has been obtained in response to the prior notification. The second item is to start updating the update software without prior notification if it is determined that there is no occupant in the vehicle. The content of the second process can be changed from that of the above embodiment as long as these two items are included. For example, the process in step S100 may be abolished. That is, the processes from step S110 onwards may be performed when the system of vehicle 100 is on. In this case, a prior notification will be given in step S120 to the occupant using vehicle 100. If the occupant who has received this prior notification decides that they cannot stop using vehicle 100 immediately and operates the reject button U3 in response to the prior notification (step S140: NO), a new scheduled date and time will be determined (steps S310, steps S320). Furthermore, if the occupant who has received prior notification decides that it is acceptable to discontinue using the vehicle 100 at that point and operates the authorization button U2 (step S140: YES), the following will occur: The system will wait for the occupant to turn off the vehicle 100's system before updating to the update software (step S150).

[0049] Depending on the type of specific control device 90 to be updated, it may be possible to update the software while the vehicle 100's system is turned on. In such cases, the update to the software may be performed while the vehicle 100's system is turned on. Applying this to the above modification example, for example, it would be as follows: After a passenger who has received prior notification operates the authorization button U2 while the vehicle 100 is in use (step S140: YES), the update to the software is performed without waiting for the passenger to turn off the vehicle 100's system.

[0050] • In the second process, the flow of returning to step S110 when the determination in step S130 is NO may be abolished. In this case, if the determination in step S130 is NO, the system should be configured to execute step S130 again. For example, if a notification sound is played when a prior notification is given so that the occupants are sure to know that a prior notification has been given, it is possible to prevent occupants from disembarking without realizing that a prior notification has been given.

[0051] Regarding step S310 of the second process, the method for calculating the scheduled date and time is not limited to the example of the above embodiment. For example, the scheduled date and time may be calculated by adjusting only the date to a predetermined fixed time. The scheduled date and time may be calculated by any method, but it is preferable to use a method that can calculate a date and time when the occupants are not using the vehicle 100 as much as possible. Similar to step S310 of the second process, the method for calculating the scheduled date and time in step S20 of the first process may also be changed from the above embodiment. The method for calculating the scheduled date and time may be different between step S20 of the first process and step S310 of the second process.

[0052] The non-volatile memory provided by the specific control device 90 may be a single-bank structure. Unlike a double-bank structure, this type of memory has only one storage area. Furthermore, it is not possible to write data while reading data from this memory. Therefore, if a single-bank structure non-volatile memory is adopted, the following configuration should be used. That is, the first process ends when the distribution package is downloaded in step S30. Then, the installation is carried out in the second process. Then, in step S150 of the second process, the installation is performed prior to the update.

[0053] As described in the above modification example, the first process is not limited to the example of the above embodiment. In addition to moving the installation to the second process as in the above modification example, the download may be abolished in the first process and moved to the second process. Then, the download, installation, and activation may be performed in step S150 of the second process. In this case, the first process will consist only of steps S10 and S20. These modifications may be made regardless of the type of non-volatile memory, such as single-bank and double-bank. The contents of the first and second processes may be adjusted as appropriate to realize the three processes of download, installation, and activation (update).

[0054] The timing of the execution of the first process is not limited to the examples of the above embodiment. For example, the first process may be performed some time after the system of the vehicle 100 has been turned on. Alternatively, the first process may be performed while the system of the vehicle 100 is turned off.

[0055] Some specific control devices 90 may employ a double-bank structure as the non-volatile memory, while the remaining specific control devices 90 may employ a single-bank structure as the non-volatile memory.

[0056] • In the same specific control device 90, non-volatile memories with different structures may be used for the first memory and the second memory. In the same specific control device 90, the first memory and the second memory may be combined into a single non-volatile memory.

[0057] The above examples of modifications regarding non-volatile memory can also be applied to the OTA master 10. That is, a single-bank structure may be used as the non-volatile memory for the OTA master 10. Non-volatile memories with different structures may be used for the first memory 21 and the second memory 22. The first memory 21 and the second memory 22 may be combined into a single non-volatile memory.

[0058] The OTA master 10 may update its own software using the same method as in the above embodiment. In other words, the electronic control device that the OTA master 10 updates its software for may be the OTA master 10 itself.

[0059] It is not mandatory that the second device for notifying occupants inside the vehicle and the third device for receiving instructions from occupants be composed of the same device. The third device is not limited to the examples of the embodiments described above. For example, the third device may be a mechanically operated push-button switch. The third device only needs to be capable of receiving instructions from the occupant and outputting a signal to the OTA master 10 in response to the occupant's operation.

[0060] The second device is not limited to the examples of the embodiments described above. A speaker may be used as the second device. In addition, sound may be used to provide advance notice to the occupants, such as voice guidance. The second device only needs to be capable of notifying the occupants inside the vehicle in response to commands from the OTA master 10.

[0061] The first device for detecting the presence of an occupant inside the vehicle is not limited to the examples of the above embodiment. The first device may be, for example, a camera that images the interior of the vehicle. The first device may be a courtesy switch that detects the opening and closing of a door. For example, if the door is opened or closed after the vehicle 100's system has switched from on to off, it may be determined that the occupant has exited the vehicle. The first device may also be an electronic key held by the occupant. The electronic key transmits a response signal to a request signal issued by the OTA master 10 only if the electronic key is located within the wireless communication area inside the vehicle. The presence or absence of an occupant inside the vehicle may be determined by using this response function to confirm the location of the electronic key. The first device only needs to be capable of detecting the presence of an occupant inside the vehicle.

[0062] The overall configuration of vehicle 100 is not limited to the examples of the above embodiments. For example, vehicle 100 may be a so-called electric vehicle that does not have an engine as its power source. The OTA master 10 may include a processing circuit that includes one or more processors that perform various processes according to a computer program (software). The OTA master 10 may also include a processing circuit that includes one or more dedicated hardware circuits, such as application-specific integrated circuits (ASICs), that perform at least some of the various processes, or a processing circuit that includes a combination of the above processors and dedicated hardware circuits. The processor includes a CPU and memory such as RAM and ROM. The memory stores program code or instructions configured to cause the CPU to perform the processes. Memory, i.e., computer-readable media, includes any available media that can be accessed by a general-purpose or dedicated computer. This modification example can also be applied to each specific control device 90. [Explanation of Symbols]

[0063] 10…OTA Master 50…Display 80... Pressure sensor 90...Specific control device 100...vehicles

Claims

1. Applicable to a vehicle equipped with multiple electronic control devices, which can switch between an ON state in which each electronic control device is activated, and an OFF state in which each electronic control device is not activated except for temporary activation. Receiving update software for the electronic control unit to be updated, Updating the software of the electronic control device to be updated to the update software, If the vehicle is in the off state at a predetermined scheduled date and time, it is determined whether or not there are occupants inside the vehicle's cabin. To notify the crew whether or not to start the update to the aforementioned update software, It is possible to do this, If it is determined that there is an occupant in the vehicle's cabin while the vehicle is in the off state, the notification will be given before starting the update to the update software, and after the notification has been given, the update to the update software will be started, provided that a signal indicating that the update to the update software has been authorized is obtained. If it is determined that there are no occupants in the vehicle's cabin while the vehicle is in the off state, the update to the update software will be initiated without issuing the notification. After the aforementioned notification is given, the system repeatedly checks whether there are occupants in the vehicle compartment. Even if it has not received a signal indicating that the update to the update software has been authorized, if it is determined that there are no occupants left in the vehicle compartment, the system starts the update to the update software. Information processing device for vehicles.

2. A first device for detecting the presence of occupants inside a vehicle, A second device for notifying occupants inside the vehicle interior of information by light or sound, A third device that receives instructions from the occupants inside the vehicle, Multiple electronic control devices installed in the aforementioned vehicle, An information processing device mounted on the vehicle and controlling the software updates of each of the electronic control devices, Equipped with, The vehicle switches between an ON state where each of the electronic control devices is activated, and an OFF state where each of the electronic control devices is not activated, except for temporary activation. The aforementioned information processing device is Receiving update software for the electronic control unit to be updated, Updating the software of the electronic control device to be updated to the update software, If the vehicle is in the off state at a predetermined scheduled date and time, it is determined whether or not there is an occupant inside the vehicle based on the detection result of the first device, The second device is used to notify the crew whether or not to start updating to the aforementioned update software, It is possible to do this, If it is determined that there is an occupant in the vehicle's interior while the vehicle is in the off state, the notification will be given before starting the update to the update software, and after the notification has been given, the update to the update software will be started, provided that a signal indicating that the update to the update software has been authorized is received from the third device. If it is determined that there are no occupants in the vehicle's interior while the vehicle is in the off state, the update to the update software will be initiated without issuing the notification. After the notification is given, the system repeatedly determines whether or not there is an occupant in the vehicle based on the detection results of the first device. Even if it has not received a signal from the third device indicating that the update to the update software has been authorized, if it is determined that there is no longer an occupant in the vehicle, the system starts the update to the update software. A software update system for vehicles.

3. Applicable to a vehicle equipped with a plurality of electronic control devices and an information processing device for controlling the software updates of each of the electronic control devices, which switches between an ON state in which each of the electronic control devices is activated, and an OFF state in which each of the electronic control devices is not activated except for temporary activation. The aforementioned information processing device, Receiving update software for the electronic control unit to be updated, Updating the software of the electronic control device to be updated to the update software, If the vehicle is in the off state at a predetermined scheduled date and time, it is determined whether or not there are occupants inside the vehicle's cabin. If it is determined that there is an occupant in the vehicle's cabin while the vehicle is in the off state, the system will notify the occupant to choose whether or not to start the update to the update software before starting the update to the update software, and after the notification has been given, the system will start the update to the update software only if it receives a signal indicating that the update to the update software has been authorized. If it is determined that there are no occupants in the vehicle's cabin while the vehicle is in the off state, the update to the update software will be initiated without issuing the notification. After the aforementioned notification is given, the system repeatedly determines whether or not there are occupants in the vehicle compartment, and even if it has not received a signal indicating that the update to the update software has been authorized, if it is determined that there are no occupants left in the vehicle compartment, the system starts updating the software. Make it run A program for vehicles.

Images