Vehicle control device

Abstract

Provided is a vehicle control device with which it is possible to achieve the function of selecting the version and the variation of an application according to a situation when updating the application. The vehicle control device includes: a first memory; an update event generation unit that is stored in the first memory and generates an update event related to the necessity of change of first software including a plurality of applications that include a first application; an application version determination unit that determines an update version of the first application to be upgraded among the plurality of applications on the basis of the update event; and a download indication unit that transmits, to a server, a download request for downloading a second application which is an application of the update version determined by the application version determination unit.

Description

Vehicle control device

[0001] The present disclosure relates to a vehicle control device.

[0002] An electronic control unit (ECU) as a vehicle control device mounted on a vehicle is composed of an arithmetic processing device such as a microcomputer including a central processing unit (CPU) and a read-only memory (ROM). The CPU reads and executes a control program (also called a software program or an application program) stored in the ROM to control the on-board devices mounted on the vehicle. Note that a software program may be simply referred to as software, and an application program may be simply referred to as an application.

[0003] Recently, there are cars known as software-defined vehicles (SDVs), which use two-way communication between the vehicle and the outside world to update the software that controls the vehicle, allowing the vehicle's functions to be increased and its performance to be improved even after it has been sold.

[0004] Japanese Patent Application Laid-Open No. 2017-228104 discloses a control device (management server) that can efficiently distribute program update programs while taking into account the communication status of a communication line.

[0005] Japanese Patent Application Laid-Open No. 2017-228104

[0006] The inventors' research has revealed the following: In the future, as SDVs evolve, the number of applications installed in ECUs will increase. Furthermore, applications will continue to evolve even after they are released to the market, making it necessary to manage more versions than ever before. Furthermore, not only will the latest versions of applications be managed on the server, but older versions of applications will also be managed, taking into account compatibility with existing applications. Furthermore, it is expected that variations in applications will emerge for each vehicle model and destination, making it necessary to select the optimal version and variation depending on the situation.

[0007] The present disclosure provides a vehicle control device that can realize a function for selecting the version and variation of an application depending on the situation when updating the application.

[0008] Other objects and novel features will become apparent from the description of this specification and the accompanying drawings.

[0009] A brief summary of representative aspects of this disclosure is as follows.

[0010] According to one embodiment, a vehicle control device has: a first memory; an update event generation unit that generates an update event related to the need to change first software stored in the first memory and having a plurality of applications including a first application; an application version determination unit that determines, based on the update event, an update version of the first application that is to be upgraded from among the plurality of applications; and a download instruction unit that transmits a download request to a server to download a second application that is the application of the update version determined by the application version determination unit.

[0011] According to the vehicle control device according to the above embodiment, it is possible to realize a function of selecting the version and variation of an application depending on the situation.

[0012] FIG. 1 is a configuration diagram illustrating a vehicle and an external network according to a first embodiment. FIG. 2 is a diagram illustrating an example of the configuration of the vehicle control device 10 of FIG. 1. FIG. 3 is a diagram illustrating the internal configuration of the electronic control device of FIG. 2. FIG. 4 is a diagram illustrating the use of a flash ROM. FIG. 5 is a diagram illustrating an update program request transmission unit. FIG. 6 is a diagram illustrating an update program data reception unit. FIG. 7 is a diagram illustrating an update target application information and an application version combination list. FIG. 8 is a diagram illustrating the operation of an application update control unit. FIG. 9 is a diagram illustrating an update program request transmission unit according to a second embodiment. FIG. 10 is a diagram illustrating an update program request transmission unit according to a third embodiment. FIG. 11 is a diagram illustrating a search sequence of a download server search unit. FIG. 12 is a diagram illustrating an example of an application information list managed by a server and an application version combination list to which server information is attached. FIG. 13 is a diagram illustrating an example of a UI (user interface) display that requests a user to grant permission to update an application according to a sixth embodiment. FIG. 14 is a diagram illustrating an example of an application processing load state. FIG. 15 is a diagram illustrating an update application selection sequence according to a seventh embodiment. FIG. 16 is a diagram illustrating an update target application table and an application information list according to the seventh embodiment.

[0013] Hereinafter, embodiments will be described with reference to the drawings. However, in the following description, the same components are designated by the same reference numerals, and repeated description may be omitted. Note that the drawings may be more schematic than the actual embodiment to clarify the description, but they are merely examples and are not intended to limit the interpretation of the present disclosure. The present disclosure can be configured, for example, using a hardware circuit configured on a silicon single crystal semiconductor substrate, or a software program executed by a CPU, or a combination of a hardware circuit and a software program.

[0014] FIG. 1 is a configuration diagram illustrating a vehicle and an external network according to a first embodiment.

[0015] 1, a vehicle 1 includes a vehicle control device 10 and a communication device 12 connected to the vehicle control device 10. An off-vehicle network 1N includes an Internet infrastructure 3 as a communication network, and a base station 2 and multiple servers 4 (41, 42) connected to the Internet infrastructure 3. The servers 4 (41, 42) may be referred to as application servers or off-vehicle servers.

[0016] As described below, the vehicle control device 10 includes multiple electronic control units (ECUs). As a typical configuration example, one electronic control device is configured by an arithmetic processing device such as a microcomputer including a central processing unit (CPU) and a read-only memory (ROM) as a non-volatile memory. As described below, the ROM may be a flash ROM. The CPU reads and executes a control program (also referred to as a software program or an application program) stored in the ROM, thereby realizing control of on-board equipment (e.g., an engine, brakes, etc.) installed in the vehicle 1. Note that a software program may be simply referred to as software, and an application program may be simply referred to as an application.

[0017] The communication device 12 is connected to the base station 2 by wireless communication, and the vehicle control device 10 is configured to be able to connect to a plurality of servers 4 connected to the Internet infrastructure 3 via the communication device 12 and the base station 2. The communication device 12 can be referred to as a communication unit.

[0018] The multiple servers 4 (41, 42) are application servers that store update software for the vehicle control device 10 of the vehicle 1. That is, the multiple servers 4 (41, 42) store multiple applications (e.g., updated versions of applications) to be stored in ROM. When the vehicle 1 needs to update an application stored in ROM, the multiple servers 4 (41, 42) are configured to send, for example, an updated version of the application to the vehicle 1.

[0019] 2 is a diagram showing an example configuration of the vehicle control device 10 of FIG. 1. The vehicle control device 10 includes a communication device 12, a gateway ECU (GW ECU) 100, multiple integrated ECUs 201 (201-1, 201-2, ..., 201-N), and multiple control ECUs 202 (202-11, 202-12, ..., 202-1N, 202-21, 202-22, ..., 202-2N, 202-N1, 202-N2, ..., 202-NN). The vehicle control device 10 further includes a network 300 and multiple sub-networks 301 (301-1, 301-2, ..., 301-N). There may be one or more of each of the gateway ECU 100, the integrated ECU 201, the control ECU 202, and the sub-network 301.

[0020] The gateway ECU 100 receives communication data from the external network 1N of the vehicle 1 via the communication device 12, analyzes the communication data, and creates control data. The gateway ECU 100 sends the created control data to the corresponding integrated ECU 201 or control ECU 202 in the vehicle 1.

[0021] The integrated ECU 201 is configured to, for example, calculate a control command value for a control ECU 202 that directly controls an actuator based on the received control data, and transmit the calculated control command value to the control ECU 202. For example, the integrated ECU 201 corresponds to an ECU for automatic driving control (Auto Drive: AD ECU) or an ECU for an advanced driving assistance system (Advanced Driving Assistant System: ADAS ECU).

[0022] The control ECU 202 directly controls the actuators, etc. The control ECU 202 is configured to be able to communicate with the integrated ECU 201 via a network 300 or a sub-network 301 .

[0023] The network 300 interconnects the GW ECU 100 and the integrated ECU 201. The network 300 is mainly configured by an in-vehicle Ethernet (Ethernet is a registered trademark). The network 300 may be configured by a local interconnect network (LIN), a controller area network (CAN), or other network infrastructure.

[0024] The sub-network 301 interconnects the integrated ECU 201 and the control ECU 202. The sub-network 301 is mainly configured using an in-vehicle Ethernet or a CAN. The sub-network 301 may use other protocols. Furthermore, the present disclosure does not limit the ECUs interconnected by the sub-network 301.

[0025] Fig. 3 is a diagram illustrating the internal configuration of the electronic control device in Fig. 2. Fig. 3 shows an example of the internal configuration of the integrated ECU 201 as a representative example, but other ECUs, such as the gateway ECU 100 and the control ECU 202, also have similar internal configurations. Here, the configuration of ECUs will be broadly described without being limited to a specific ECU, with the internal configuration of the integrated ECU 201 being used as a representative example.

[0026] The integrated ECU 201 includes a communication interface (COMIF) 401 (401-1 to 401-N), an analog-to-digital conversion interface (ADIF) 402, an internal bus 405, and central processing units (CPUs: CPU1 to CPUN) 406 (406-1 to 406-N). The integrated ECU 201 further includes random access memories (RAMs: RAM1 to RAMN) 407 (407-1 to 407-N) as volatile memories, and flash ROMs (FlashROM1 to FlashROMN) 408 (408-1 to 408-N) as nonvolatile memories. In this example, the communication interface 401, the central processing unit 406, the random access memory 407, and the flash ROM 408 are shown as a configuration example in which there are multiple components in FIG. 3, but they may of course be one.

[0027] There are a plurality of communication interfaces 401 (401-1, ..., 401-N) for each communication channel such as CAN, in-vehicle Ethernet, etc. The communication interfaces 401 (401-1, ..., 401-N) are electrically connected to the communication channels such as CAN, in-vehicle Ethernet, etc.

[0028] The analog-digital conversion interface 402 is an interface with devices that are electrically connected by means other than communication, such as a sensor (SEN) 403 and an actuator (ACT) 404. There may be a plurality of analog-digital conversion interfaces 402. As shown in Fig. 3, the actuator (ACT) 404 may be directly connected to an internal bus 405, for example.

[0029] The integrated ECU 201 also includes a digital-to-analog converter (ADC) 410. The digital-to-analog converter 410 is electrically connected to the analog-to-digital conversion interface 402 and converts analog signals from analog sensors into digital signals.

[0030] The sensor 403 can be any of various sensors, such as an acceleration sensor, an angular velocity sensor, a velocity sensor, or a thermal sensor.

[0031] The actuator 404 can be mainly a motor. Examples of this type of motor include a large motor for driving a vehicle and a small motor for electronic control. The connection of a command value to a semiconductor device connected to the actuator 404 for driving the actuator 404 can be configured to transmit a PWM (Pulse Width Modulation) value as a digital signal via an analog-to-digital interface (ADIF), for example.

[0032] The internal bus 405 is electrically connected to the communication interface 401, the central processing unit 406, the flash ROM 408, and the digital-to-analog converter 410. The internal bus 405 is configured to be able to interconnect the communication interface 401, the central processing unit 406, the flash ROM 408, and the digital-to-analog converter 410.

[0033] The central processing unit 406 is provided to control the operation of the integrated ECU 201. The central processing unit 406 uses the random access memory 407 as a temporary work area to execute control programs stored in the flash ROM 408 and control the operation of the integrated ECU 201.

[0034] In this example, the random access memory 407 is provided as a local memory of the central processing unit 406. The random access memory 407-1 is connected to the central processing unit 406-1 as a local memory, and the random access memory 407-N is connected to the central processing unit 406-N as a local memory. The random access memory 407 can also be configured to be accessible from other ECUs (for example, the gateway ECU 100, the control ECU 202, etc. shown in FIG. 2).

[0035] The Flash ROM 408 can be configured with a flash memory, which is a nonvolatile memory that allows data to be electrically rewritten and erased. The Flash ROM 408 is used as a memory area for data storage, and stores control programs, control command values, etc. executed by the central processing unit 406. Although not particularly limited, the Flash ROM 408-1 can be configured to store control programs, control command values, etc. for the central processing unit 406-1, and the Flash ROM 408-N can be configured to store control programs, control command values, etc. for the central processing unit 406-N. Note that the number of central processing units 406 and the number of Flash ROMs 408 are not particularly related. The number of Flash ROMs 408 may be the same as the number of central processing units 406, less than the number of central processing units 406, or more than the number of central processing units 406.

[0036] A conceptual diagram of an application update according to the present disclosure is shown in the lower part of Fig. 3. In the present disclosure, as shown in the lower part of Fig. 3, for example, a first software (1st SOFT) including a plurality of applications (APPLS: 1st Appl A_A, Appl B_A, ..., Appl N_X) including a first application (1st Appl A_A) is stored in a flash ROM 408-1 as a first memory. It is assumed that an update event related to the need to change the first software (1st SOFT) is generated.

[0037] In this case, based on this update event, ECU 201 determines the update version of the first application (1stApplA_A) to be upgraded from among the multiple applications (APPLS), and transmits a download request to server 41 to download the second application (2ndAppl), which is the application (1stApplA_B) of the determined update version. This makes it possible to download the application (second application) that is the optimal update version in response to the update event.

[0038] Based on the version information, which is information about the determined update version of the second application (2ndAppl(1stApplA_B)), the ECU 201 determines a third application (3rdAppl(ApplB_B)) that has a dependency relationship with the second application (2ndAppl), which is the update version of the application (1stApplA_B). The ECU 201 then transmits a download request for the third application to the server 42. This makes it possible to select another application (third application) that has a dependency relationship between versions. For example, the update version of the second application (2ndAppl(1stApplA_B)) cannot be properly executed with the pre-update version of the application (ApplB_A). On the other hand, if the update version of the second application (2ndAppl(1stApplA_B)) can be properly executed with the third application (ApplB_B), the normal application can be downloaded. In this example, a case is shown in which a second application (2ndAppl) is stored in a server 41, and a third application (ApplB_B) is stored in a server 42 different from the server 41. Of course, the second application (2ndAppl) and the third application (ApplB_B) may be stored in the same server (41 or 42).

[0039] In the present disclosure, as will be described later with reference to FIG. 5 , the vehicle control device 10 is configured to include an update event generation unit 510, an application version determination unit 511, a download instruction unit 513, and an application combination determination unit 512.

[0040] The update event generating unit 510 generates event information (hereinafter referred to as an update event) relating to the need to update the first software.

[0041] The application version determination unit 511 determines the update version of a first application to be upgraded from among a plurality of applications based on the update event.

[0042] The download instruction unit 513 transmits to the server 41 a download request for downloading the second application, which is the application of the updated version determined by the application version determination unit.

[0043] The application combination determination unit 512 determines a third application that has a dependency relationship with the second application, which is the application of the updated version, based on the version information, which is information about the updated version, determined by the application version determination unit 511. Then, the download instruction unit 513 transmits a download request for the third application to the server 42.

[0044] Next, the use of the Flash ROM 408 will be described using FIG. 4. FIG. 4 is a diagram illustrating the use of the Flash ROM. The Flash ROM 408 has a program area 4081, a backup area 4082, and a download area 4083. In FIG. 4, as an example, the program area 4081 stores application A (Application A) 501-A of version A (VerA) as the application 501. For example, application A (Application A) 501-A can also be considered as 1stApplA_A in FIG. 3. The backup area 4082 stores application A (Application A) 501-B of version B (VerB) as the application 501. In the download area 4083, application A (Application A) 501-C of version C (VerC) is stored as the application 501.

[0045] Application A (version A: VerA) 501-A in program area 4081 is expanded into random access memory 407 and executed by central processing unit 406, thereby controlling vehicle 1 by vehicle control device 10. Application A 501-B of version B (VerB) different from that in program area 4081 is stored in backup area 4082. Application A 501-C of version (VerC) different from that in program area 4081 is stored in download area 4083.

[0046] The program area 4081, the backup area 4082, and the download area 4083 are areas secured within the flash ROM 408, and may be secured across multiple flash ROMs 408-1, ..., 408-N. Depending on the operating system (OS), the program area 4081, the backup area 4082, and the download area 4083 may be represented and managed as folders by a file system.

[0047] The ECU 201 operates mainly using program data (here, application A 501 -A) stored in the program area 4081 .

[0048] Backup area 4082 is used to store backup program data (here, application B501-B). That is, when a program update fails or there is a problem with the updated program, the application stored in backup area 4082 is restored to program area 4081. For example, when updating application A501-A, if the update fails due to a communication problem that causes a failure to download the update program, or if a problem occurs with the update program due to a malfunction in the operation of the downloaded update program, the downloaded update program is erased or deleted from program area 4081. Then, the application stored in backup area 4082 (here, application A501-B) is stored or restored to program area 4081. This ensures the operation of ECU 201.

[0049] Download area 4083 is used to temporarily store program data and other data. The data (program data and other data) temporarily stored in download area 4083 is verified for validity by a verification control program stored or stored in program area 4081 or random access memory 407, and then copied or duplicated to program area 4081. Download area 4083 and backup area 4082 may be secured in random access memory 407.

[0050] Next, an update program request transmission unit 500 provided in a desired ECU of the vehicle control device 10 will be described with reference to Fig. 5. Fig. 5 is a diagram illustrating the update program request transmission unit.

[0051] The update program request transmission unit 500 is provided in a desired ECU of the vehicle control device 10 (in this example, any one of the gateway ECU 100, the integrated ECU 201, and the control ECU 202). The update program request transmission unit 500 includes, as functional blocks, an update event generation unit 510, an application version determination unit 511, an application combination determination unit 512, a download instruction unit 513, and a transmission unit 514. The update program request transmission unit 500 can also be configured as an application, and each functional block represents a function possessed by the application. The request transmission unit 500 may be configured as a single application, or may be implemented as multiple applications with different functions. In FIG. 5, the connections between the functional blocks (510-514) indicate the existence of a data exchange relationship.

[0052] The update event generation unit 510 generates an update request for an application based on the software status and information from an external sensor.

[0053] The application version determination unit 511 receives an update request from the update event generation unit 510 and determines the update version of the application for which an update request has been made. In this embodiment, any means for selecting the update version is acceptable.

[0054] The application combination determination unit 512 determines a version that will operate normally for another application that has a dependency relationship, based on the information on the update version of the application determined by the application version determination unit 511. The method for determining a version that will operate normally is determined using an application version combination list APPCL. An example of the configuration of the application version combination list APPCL will be described in detail below with reference to FIG. 7.

[0055] The application version combination list APPCL can be regarded as a dependency information table, and for example, the application combination determination unit 512 of the vehicle control device 10 can hold the application version combination list APPCL. Furthermore, as described in the second embodiment, the application version combination list APPCL may be stored, for example, in a server 4 (41, 42) that is an off-vehicle server. In this case, the vehicle control device 10 is connected to the server 4 (41, 42) via the communication unit 12, and the vehicle control device 10 can download the application version combination list APPCL from the server 4 (41, 42) and store it in the application combination determination unit 512. The vehicle control device 10 can be a desired ECU of the vehicle control device 10 (any one of the gateway ECU 100, the integrated ECU 201, and the control ECU 202).

[0056] The download instruction unit 513 creates transmission data for sending a download request for the determined application version to the server 4 (41, 42).

[0057] The transmitting unit 514 sends the transmission data created by the download instruction unit 513 together with destination information to a network external to the ECU. The destination information is, for example, the server 4 (41, 42). The network external to the ECU is, for example, the sub-network 301, the network 300, or the Internet infrastructure 3.

[0058] Next, the data receiving unit 520 for the update program provided in a desired ECU of the vehicle control device 10 will be described with reference to Fig. 6. Fig. 6 is a diagram illustrating the data receiving unit for the update program.

[0059] The data receiving unit 520 for the update program has the following functional blocks: a receiving unit 519, a temporary storage unit 518, an application update control unit 517, a backup creation unit 516, and an application update unit 515. The data receiving unit 520 may be configured as a single application, or may be implemented as multiple applications with different functions. In Figure 6, the connections between the functional blocks (516-519) indicate the existence of a data exchange relationship.

[0060] The receiving unit 519 receives data sent from a network external to the ECU, reads the destination information of the data, and transfers the data to the destination application. In this example, the receiving unit 519 stores the downloaded data of the application in the temporary storage unit 518.

[0061] The temporary storage unit 518 stores the received application data in the download area 4083 .

[0062] The application update control unit 517 receives a download end instruction from the temporary storage unit 518. Alternatively, the application update control unit 517 periodically starts up and checks whether all applications in the update application list APPRENL are stored in the download area 4083. After it is confirmed that the corresponding applications are stored in the download area 4083, the application update control unit 517 issues a stop command to each application.

[0063] After receiving the stop command, each application transitions to a stopped state or an update standby state. In the stopped state, main control such as process termination and sleep is not periodically performed, and updates are permitted.

[0064] After confirming that the target application has stopped, the application update unit 515 issues a backup creation instruction to the backup creation unit 516 .

[0065] The backup creation unit 516 copies the application to be updated that is deployed in the program area 4081 to the backup area 4082. After the copy is complete, a completion notice is output to the application update control unit 517.

[0066] The application update unit 515 receives an instruction from the application update control unit 517 and copies the program data in the update application list APPRENL in the download area 4083 to the application area 4081. After the copy is complete, a completion notification is output to the application update control unit 517. After this, for example, the vehicle control device 10 or a predetermined ECU within the vehicle control device 10 is restarted. As a result, the program data stored in the program area 4081 is expanded into the random access memory 407 and executed by the central processing unit 406, thereby controlling the vehicle 1 by the vehicle control device 10. Alternatively, by starting only the updated applications, there is no need to initialize the existing applications, so that some applications can be updated without stopping the vehicle control functions, such as while driving.

[0067] Next, the application information APPRENI to be updated and the application version combination list APPCL will be described with reference to Fig. 7. Fig. 7 is a diagram for explaining the application information to be updated and the application version combination list.

[0068] The application information APPREN1 to be updated has an identification number ID, an application name (name), variation information (variation), and version information (version). Here, the identification number ID is information that can uniquely identify an application. As an example, the application name (name) is described here as Application A. The variation information (variation) is information that indicates the country, city, region, state, vehicle size, etc.

[0069] The application version combination list APPCL has an identification number ID, an application name (name), variation information (variation), and version information (version). The application version combination list APPCL shows a list of application combinations that operate stably, taking into account the variation information and version information.

[0070] The combinations expressed in this list APPCL are based on past performance or on combinations certified by the vehicle manufacturer. If there are applications that are not dependent on each other, they are not listed in this list APPCL. In addition, multiple combination tables made up of different applications are created. In addition, this list APPCL is also created for past versions, and different combination lists are created for different versions of the same application.

[0071] Next, the operation of the application update control unit 517 will be described with reference to Fig. 8. Fig. 8 is a diagram illustrating the operation of the application update control unit. Steps S100 to S110 will be described below in order.

[0072] S100: First, the application update control unit 517 starts periodically or constantly, and checks whether download data is stored in the download area 4083.

[0073] S101: If the data is stored (yes), proceed to the next sequence (S102). If the data is not stored (no), return to the initial sequence (S100).

[0074] S102: In the next step of this sequence, the application update control unit 517 issues a stop command to all running applications. The stop command is issued by an operating system (OS) function, signal communication, or service communication.

[0075] S103: In the next sequence, the application update control unit 517 checks whether all applications are in a stopped state. If even one application is not in a stopped state (no), the process returns to the previous sequence (S102). Alternatively, the process executes the sequence (S103) again. If an application in a running state is forcibly terminated, the state, flags, etc. are not initialized, which may lead to malfunctions after the update. Therefore, the process executes the sequence (S103) to enable a safe software update. When returning to the sequence (S102) or executing the sequence (S103) again, the process may be executed immediately or after waiting a certain period of time.

[0076] S104: In this sequence, the application update control unit 517 issues a backup creation instruction to request the backup creation unit 516 to make a copy of the application to be updated.

[0077] S105: In this sequence, the backup creation unit 516 stores a copy of the application to be updated in the backup area 4082. By executing this sequence, even if the application update fails, the state before the update can be restored by restoring from the backup data, thereby realizing a safe software update. After copying all target applications, the next sequence (S106) is executed.

[0078] S106: In this sequence, the application update control unit 517 issues an update instruction to the application update unit 515.

[0079] S107: In this sequence, the application update unit 515 deletes the application for which an update instruction has been issued from the program area 4081. The deletion method may be erasing from the file system, writing an invalid value (such as Null or 0) to the storage area (program area 4081), or the like, and any method may be used to achieve this.

[0080] S108: In this sequence, the process waits to see if the deletion is complete, and if it is not (no), the process returns to the previous sequence (S107). The completion of deletion can be confirmed by checking the file system, whether a valid value (or invalid value) has been written in the storage area, or the like, but the method for realizing this is not important. After confirming that the deletion is complete (yes), the process proceeds to the next sequence (S109).

[0081] S109: In this sequence, the application update unit 515 stores the application data stored in the download area 4083 in the program area 4081. Once all applications have been stored in the program area 4081, the next sequence (S110) is executed.

[0082] S110: In the final sequence, the application update unit 515 launches the updated application. As an example of a launch method, a restart instruction is sent to the updated application. The operating system or application runtime launches the application based on the restart instruction. By launching only the updated application, there is no need to initialize existing applications, so this method makes it possible to update some applications without stopping their functions while driving, for example. As another example, a restart instruction is sent to all applications. By restarting from the initialization process, it is possible to launch a new updated application more easily while maintaining data consistency between applications. Regarding the method of restarting an application, methods other than the above example are also possible, and are not limited in this embodiment.

[0083] The application update control unit 517, the application update unit 515, and the backup creation unit 516 may be implemented as a single application. If the application update control unit 517, the application update unit 515, and the backup creation unit 516 are configured as multiple separate applications, the modules (515, 516) that access the hardware (Hw) and the application update control unit 517 that controls the update sequence can be developed and updated separately. If the application update control unit 517, the application update unit 515, and the backup creation unit 516 are configured as a single integrated application, the memory for the time lag interface (IF) due to communication between the applications (515, 516, 517) can be reduced, thereby further conserving resources.

[0084] Next, another example of the configuration of the update program request transmission unit 500 will be described with reference to Fig. 9. Fig. 9 is a diagram illustrating the update program request transmission unit according to the second embodiment.

[0085] The update program request sending unit 5001 shown in FIG. 9 differs from the update program request sending unit 500 of the first embodiment in that the application combination determination unit 512 downloads the application version combination list APPCL via the sending unit 514 and issues a download instruction.

[0086] In the second embodiment, the application combination determination unit 512 notifies the application server 4 (here, one server 41 or 42, or multiple servers 41 and 42) of the version of the corresponding application via the transmission unit 514.

[0087] The application servers 41 and 42 select applications having dependencies and applications of the relevant versions based on the version information of the relevant applications, and insert them into the application combination list APPCL.

[0088] The application servers 41 and 42 send the created application combination list APPCL to the application combination determination unit 512 as a destination.

[0089] The receiving unit 519 receives the application combination list APPCL and transfers the data of the application combination list APPCL to the application combination determining unit 512 .

[0090] The application combination determination unit 512 determines a version that operates normally for another application that has a dependency relationship based on the application combination list APPCL, as described in the first embodiment. The method for determining a version that operates normally is determined using the application version combination list APPCL.

[0091] The download instruction unit 513 creates transmission data for sending a download request for the determined application version to the servers 41 and 42 .

[0092] The transmitting unit 514 sends the transmission data created by the download instruction unit 513 together with destination information via the communication device 12 to a network external to the ECU (sub-network 301, network 300, Internet infrastructure 3) to issue a download instruction.

[0093] In this embodiment, it is possible to save memory capacity because it is not necessary to store an enormous amount of combination information in the vehicle control device 10. Furthermore, when the number of combinations becomes enormous, it is possible to generate combination information in a realistic time and start issuing a download instruction by using the computing capabilities of the servers 41 and 42 on the cloud side.

[0094] Next, another example of the configuration of the update program request transmission unit 500 will be described with reference to Fig. 10. Fig. 10 is a diagram illustrating the update program request transmission unit according to the third embodiment.

[0095] The update program request transmission unit 5002 shown in FIG. 10 differs from the update program request transmission unit 500 of the first embodiment in that a download server search unit 5012 and a server selection unit 5013 are added as applications, and a server that can download the applications listed in the application combination list APPCL is selected from among a plurality of servers based on the application combination list APPCL.

[0096] In this embodiment, the download server search unit 5012 searches for server information from which each application can be downloaded in order to download the applications listed in the application combination list APPCL. The download server search unit 5012 receives the application combination list APPCL from the application combination determination unit 512. The download server search unit 5012 checks with the application servers 41 and 42 via the transmission unit 514 and the communication device 12 whether the application can be downloaded.

[0097] Download server search unit 5012 receives information on whether an application can be downloaded from application servers 41, 42 via communication device 12 and receiver 519. Each of application servers 41, 42 manages a list of applications stored therein or a list of applications that it can upload (for this list, refer to application information lists APPLA, APPLB managed by the server in FIG. 12). When each of application servers 41, 42 is informed by download server search unit 5012 of whether an application can be downloaded, it transmits information on whether the application can be downloaded to download server search unit 5012 based on the list of applications it manages.

[0098] The download server search unit 5012 transmits server information (SRVIF) indicating from which server the application to be downloaded can be downloaded to the server selection unit 5013. The server selection unit 5013 assigns the server information (SRVIF) from which each application can be downloaded to the application combination list APPCL (for this list, refer to the application version combination list APPCLS to which the server information (SRVIF) is assigned in FIG. 12). In other words, the server information (SRVIF) is downloaded from the network 3 outside the vehicle via the communication device 12 and stored in the vehicle control device 10.

[0099] In this embodiment, software updates can be performed by combining applications on a plurality of application servers 41 and 42 .

[0100] Next, the search sequence of the download server search unit 5012 will be described with reference to Fig. 11. Fig. 11 is a diagram illustrating the search sequence of the download server search unit. Steps S200 to S208 will be described below in order.

[0101] In this sequence, the sequence up to sending the download request to the servers 41 and 42 will be described.

[0102] S200: First, the update event generation unit 510 detects an update event. An update event refers to a registration notification of a new application version from the server 41, 42, a download instruction from a user, etc. Specific examples of update events will be described later in the examples. In other words, the update event is transmitted from the server 41, 42 to the vehicle control device 10 by communication via the communication device 12.

[0103] S201: In the next sequence, the update event generating unit 510 issues an update instruction to the application version determining unit 511. The update instruction includes an update event, and depending on the update event, application information may be specified.

[0104] S202: In the next sequence, the application version determination unit 511 selects an application to be updated and its version based on the update instruction information. A specific selection example will be described in the following embodiment.

[0105] S203: In the next sequence, the application combination determination unit 512 creates a combination table. If the update instruction includes application information, the application combination determination unit 512 determines the application version based on the update instruction content. The application combination determination unit 512 also selects a version of another application (or other application) for the application and its version. The application version combination list APPCL is used to combine application versions.

[0106] S204: In the next sequence, the download server search unit 5012 selects one application from the application version combination list APPCL. The selection order may be the order of registration, alphabetical order, or the like, and is not particularly specified.

[0107] S205: In the next sequence, the download server search unit 5012 selects a server 4 (41, 42) from which the selected application and version information can be downloaded. The selection method will be described later.

[0108] S206: In the next sequence, it is confirmed whether all applications listed in the application version combination list APPCL have been selected. To confirm whether they have been selected, a parameter indicating whether they have been confirmed is added to the application version combination list APPCL. The applications are selected in order of ID number (No. order), and an evaluation is made as to whether all rows have been selected, etc.

[0109] If the selection is not complete (no), the process returns to the previous sequence (S204) and an unselected application in the application version combination list APPCL is selected.

[0110] After all selections are completed (yes), a download request is created for each server (41, 42) and a download instruction is issued. The granularity of the download request may be created for each application, or may be created for each server (41, 42) and requests for multiple applications may be created simultaneously, or may be described by various other means.

[0111] S207: In order to send the download request to the application servers 41 and 42, the transmitter 514 sends a data frame to the Internet infrastructure 3, which is an external vehicle network, using a protocol such as Ethernet or CAN.

[0112] FIG. 12 is a diagram showing an example of an application information list managed by a server and an application version combination list to which server information is added.

[0113] 12, application information list APPLA is an example of the configuration of an application information list managed by server 41 (also referred to as server A), and application information list APPLB is an example of the configuration of an application information list managed by server 42 (also referred to as server B). Each of the application information lists APPLA and APPLB is made up of an application name (name), variation information (variation), and version information (version). Other information for identifying the application may also be added.

[0114] When the download server searching unit 5012 confirms whether or not an application can be downloaded via the transmitting unit 514, the servers 41 and 42 determine whether or not the application can be downloaded based on the application information lists APPLA and APPLB. Then, the servers 41 and 42 transmit information on whether or not the application can be downloaded to the download server searching unit 5012 via the receiving unit 519.

[0115] In the application information lists APPLA and APPLB, different variation information and version information may be assigned to the same application name. In the application information lists (APPLA and APPLB), different combinations of variation information and version information are stored on multiple servers 4. Furthermore, in the application information lists (APPLA and APPLB), application names, variation information, and version information may be duplicated across multiple servers 4.

[0116] 12, the application version combination list APPCLS with server information added is the application version combination list APPCL shown in Fig. 5 with information SRVIF added that uniquely indicates a server from which the application can be downloaded. This list APPCLS is created by the server selection unit 5013 receiving information from the download server search unit 5012, which information indicates from which server the application to be downloaded can be downloaded, and adding server information SRVIF from which each application can be downloaded to the application combination list APPCL.

[0117] In this example, the application version combination list APPCLS to which the server information SRVIF is assigned has a column for assigning the server information SRVIF, and this column is configured with values ​​(A, B) indicating the server from which the application can be downloaded. Here, A indicates server 41, and B indicates server 42. The values ​​(A, B) can also be assigned information that can uniquely identify the application server, such as an IP address (Internet Protocol Address), a MAC address (Media Access Control Address), or a server name.

[0118] By using the application version combination list APPCLS with the server information SRVIF, the dependent application version A (variation A, version 1.0) and the dependent application version B (variation A, version 1.1) are downloaded from the server 41(A). Furthermore, the dependent application version C (variation B, version 2.0) is downloaded from the server 42(B). In other words, dependent applications stored on different off-vehicle servers (41, 42) are downloaded. This allows applications stored on multiple application servers 41, 42 to be combined, enabling software updates using the most suitable application.

[0119] 7, both application version A (variation A, version 1.0) and application version B (variation A, version 1.1) are stored on server 41(A), but the present invention is not limited to this. Application version A (variation A, version 1.0) may be stored on server 41(A), and application version B (variation A, version 1.1) may be stored on server 42(B).

[0120] In addition to the third embodiment, the fourth embodiment relates to a sequence that enables a search for a download server and enables selection of the minimum number of application servers required from an unspecified number of application servers. Details of the sequence according to the fourth embodiment are described below.

[0121] The download server search unit 5012 connects the vehicle control device 10 to the external vehicle network (Internet infrastructure 3) via the transmission unit 514.

[0122] The connection to the external network is made via a vehicle network such as an in-vehicle Ethernet or a CAN, and then via the gateway ECU 100.

[0123] The gateway ECU 100 and subsequent ECUs are connected to a network outside the vehicle, and the subsequent communication protocols are not specified.

[0124] The download server search unit 5012 sends the application and version information selected from the application version combination list APPCL to all accessible application servers 4 (41, 42).

[0125] Each application server 4 (41, 42) creates available application information for the applications and versions that it can send, if they are downloadable, and notifies the download server search unit 5012 of this information.

[0126] The receiving unit 519 sends the available application information to the download server searching unit 5012 .

[0127] The download server search unit 5012 holds and manages available application information for each server (41, 42).

[0128] The download server search unit 5012 executes the above sequence for the application version combination list APPCL.

[0129] In this embodiment as well, software updates can be performed by combining applications held by an unspecified number of application servers among a plurality of application servers.

[0130] The fifth embodiment relates to a sequence that enables saving of CPU resources on the ECU side of the vehicle control device 10. In the sequence according to the fifth embodiment, in addition to the third embodiment, the download server search unit 5012 includes a configuration for downloading server information SRVIF created by the application server 4 (41, 42) serving as a download server. Therefore, the sequence according to the fifth embodiment enables saving of CPU resources on the ECU side of the vehicle control device 10 compared to the fourth embodiment.

[0131] The sequence of the fifth embodiment will be described in detail below.

[0132] As in the previous example (Example 4), the download server search unit 5012 connects the vehicle control device 10 to the external vehicle network (Internet infrastructure 3) via the transmission unit 514.

[0133] The connection to the external network is made via a vehicle network such as an in-vehicle Ethernet or a CAN, and then via the gateway ECU 100.

[0134] The gateway ECU 100 and subsequent ECUs are connected to a network outside the vehicle, and the subsequent communication protocols are not specified.

[0135] The download server search unit 5012 sends a list of all application version combinations (also called a combination list) APPCL to one of the accessible application servers (for example, 41, 42, or 4X) (for example, 41 will be used in the following explanation).

[0136] The application server 41 updates the application information that it can provide among the application information in the combination list APPCL (for example, by adding downloadable server information SRVIF(A:41) to the application information that it can provide). As a result, an application version combination list APPCLS is created to which the downloadable server information SRVIF(A:41) is added.

[0137] The application server 41 inquires of another application server 42 that it can access about applications that it cannot provide among the application information in the combination list APPCL. In other words, the application server 41 sends the application version combination list APPCLS, to which the downloadable server information SRVIF (A:41) has been assigned, to the application server 42.

[0138] The other application server 42 that has received the inquiry updates the application information that it can provide from among the application information in the combination list APPCL, and makes an inquiry to the application server 41 in question.

[0139] The other application server 42 adds downloadable server information SRVIF (B: 42) to the application information that it can provide in the combination list APPCL, and notifies the application server 41. As a result, an application version combination list APPCLS is created to which the downloadable server information SRVIF (A: 41, B: 42) is added.

[0140] The other application server 42 also inquires of the application server 41 about information on the server 4X that can be reached from the other application server 42 .

[0141] If the application server 41 has not been able to assign server information to all of the application version combination list APPCL, it makes an inquiry to the notified reachable server 4X.

[0142] In this embodiment, each application server adds downloadable server information SRVIF to the application information that it can provide, so that it is possible to save CPU resources on the ECU side of the vehicle control device 10.

[0143] Next, another configuration example of the update event generating unit 510 according to the sixth embodiment will be described with reference to Fig. 13. Fig. 13 is a diagram showing a display example of a UI (user interface) that requests permission to update an application from a user according to the sixth embodiment.

[0144] The sixth embodiment differs from the first embodiment in that one of the in-vehicle ECUs (201, 202) (e.g., 201-1) has an HMI (human-machine interface) function 1301. The update event generation unit 510 receives data from a receiving unit 519, communicates with an ECU having the HMI function 1301 (hereinafter, HMI ECU: 201-1) via a transmitting unit 514, and causes the HMI function 1301 to display a UI (user interface) that requests the user to approve the update. The HMI function 1301 can be configured, for example, by displaying a GUI (graphical user interface) on a display unit 1302 configured by a display panel with a touch sensor.

[0145] The application server 4 (41, 42) sends a notification message that a new software version has been added to the update event generation unit 510. Upon receiving the notification message, the update event generation unit 510 determines whether the application of the new software version described in the notification message is an application of its own ECU (201, 202).

[0146] If the application of the new software version is an application of the own ECU (201, 202), an update permission request is generated and sent to the HMI ECU: 201-1.

[0147] The HMI ECU 201-1 displays a request for permission to update as a GUI on the display unit 1302. In this example, an "Update" button 1303 is displayed on the display unit 1302. When the user consents to the update, the user can notify the user that the update is permitted by pressing (clicking) the "Update" button 1303 with a finger or the like.

[0148] When the user approves the update via the GUI, the HMI ECU 201-1 sends an update approval instruction to the update event generating unit 510.

[0149] Upon receiving the update permission instruction, the update event generation unit 510 generates an update event by specifying the new version of the application, and performs the software update shown in Example 1. That is, the update event is generated by a user's HMI operation (here, an operation such as clicking the "Update" button 1303).

[0150] Fig. 13 shows an example of a UI display that requests the user to grant permission for an update, as an example of the HMI function 1301. The UI shown in Fig. 13 is a GUI that includes a screen that provides various contents such as car navigation, a speedometer, and video, as well as functions such as a touch panel and buttons for operating the screen. The "Update" button 1303 uses an operable image displayed on a touch panel or a physical button.

[0151] In this embodiment, software updates are possible when a new application is released, and by updating with the user's permission, it is possible to prevent the software from being updated to software that is not intended by the user.

[0152] Next, another example of the configuration of the update event generation unit 510 according to the seventh embodiment will be described with reference to Figs. 14, 15, and 16. Fig. 14 is a diagram illustrating an example of the state of the processing load of an application. Fig. 15 is a diagram illustrating a selection sequence of an update application according to the seventh embodiment. Fig. 16 is a diagram illustrating an update target application table and an application information list according to the seventh embodiment.

[0153] The seventh embodiment differs from the other embodiments described above in that the update event generating unit 510 monitors the processing load of the application.

[0154] FIG. 14 shows an example in which an application load exceeds a threshold (VTH) and a software update is required. In this embodiment, an example will be described in which three applications A, B, and C are installed on a certain CPU (406-1 as a representative example) shown in FIG. 3 . FIG. 14 is a graph showing an example of the processing load on the CPU (406-1) when applications A, B, and C become unstable. The bar graph in FIG. 14 represents CPU utilization (%) on the vertical axis and time (T) on the horizontal axis, with applications A, B, and C launched every t cycles. For example, application C exhibits a utilization rate of approximately 35% at time t-1. The vertical axis of this graph also represents the total CPU utilization rate, calculated by adding up the CPU utilization rates of application A, application B, and application C at each time (t-1, t, t+1, ..., t+n). The threshold VTH is set to an arbitrary value representing the CPU utilization rate.

[0155] 14, a CPU utilization rate exceeding the threshold value VTH is detected at time t+3. The update event generation unit 510 collects CPU utilization rates as shown in FIG. 14 and monitors whether the CPU utilization rate exceeds the threshold value VTH. There are various possible methods for collecting CPU utilization rates, and the method is not limited to an OS function or the like.

[0156] When the CPU utilization rate exceeds the threshold VTH, the update event generation unit 510 generates an update event for updating the corresponding application. That is, the update event is generated according to the operating state of the software including applications A, B, and C. Here, the operating state of the software means an increase in processing time (CPU utilization rate). The update event then selects an update application and downloads the appropriate update application from the server 4 (41, 42) by referring to the CPU utilization rate of the application when the CPU utilization rate exceeds the threshold VTH and a performance value (described later) so as to improve the processing time.

[0157] Next, the update application selection sequence according to the seventh embodiment will be described with reference to Fig. 15. This sequence is executed by the application version determination unit 511 receiving an update event issued by the update event generation unit 510 in this embodiment. Each of steps S300 to S309 will be described below in order.

[0158] Step S300: In the first sequence, an application is selected and processing begins. Here, as an example, the description will be given assuming that application A is selected first.

[0159] Step S301: In the next sequence, for the selected application (A), the performance value (20) of the performance information (Performance) listed in the application information list APPINFL shown in FIG. 16 is compared with the detected CPU utilization rate (e.g., 35).

[0160] Step S302: In the next sequence, if the CPU utilization rate exceeds the performance value (yes), proceed to the next sequence (step S303). If the CPU utilization rate does not exceed the performance value (no), proceed to the next sequence (step S304). In one example, the CPU utilization rate (35) exceeds the performance value (20), so proceed to step S303.

[0161] Step S303: In this sequence, the update target application table APPRENT shown in Fig. 16 is created by inserting application information of applications whose CPU utilization exceeds the performance value into the update target application table APPRENT. The application information includes, for example, a number (No), application name (name), variation information (variation), version information (version), and CPU utilization (CPU usage). Here, as an example, application information for application A is entered in number 1. Furthermore, application information for application C is entered in number 2.

[0162] Step S304: In the next sequence, it is evaluated whether all applications related to the excessive CPU utilization rate have been selected. If they have not been selected (no), the process returns to the first sequence (S300) (for example, application C is selected at this time). If all applications have been selected (yes), the process proceeds to the next sequence (S305).

[0163] Step S305: The next sequence evaluates whether information (addition of load, etc.) has been inserted into the application table APPRENT to be updated. If it has been inserted (yes), proceed to the next sequence (S306). If it has not been inserted (no), end the series of sequences.

[0164] Step S306: In the next sequence, one application to be updated is selected, and the latest version of the application to be updated is selected.

[0165] Step S307: In the next sequence, the performance value in the performance information column of the selected version is compared with the CPU utilization rate of the application to be updated.

[0166] Step S308: In the next sequence, it is evaluated whether the performance value is below the CPU utilization rate. If it is below (yes), proceed to the next sequence (S309). If it is not below (no), return to the previous sequence (S306).

[0167] Step S309: In the final sequence, the selected version of the application is selected as the application to be downloaded.

[0168] (Explanation of the update target application table APPRENT) The update target application table APPRENT in this embodiment is shown in Fig. 16. The application version determination unit 511 creates the update target application table APPRENT.

[0169] In this application table APPRENT, information such as number (No), application name (name), variation information (variation), version information (version), and CPU usage rate (CPU usage) is recorded.

[0170] The number (No) is information for uniquely identifying an application that is a member of this table APPRENT, and may be any number, alphabet, or the like.

[0171] The application name should be a name that represents the application. The name should be expressed using numbers, English letters, symbols, and other characters.

[0172] The variation information is information for indicating the destination and specification differences of the application, and is expressed as a value that is unique among the same applications using numbers, English letters, symbols, or other elements.

[0173] Version information is a value that is incremented each time the application is updated. It can be expressed using numbers, English letters, symbols, or other means. It should be unique within an application that has the same application name and variation information.

[0174] The CPU utilization rate is inserted when the update event creation unit 510 creates this table APPRENT. It represents the CPU utilization rate of each application when the threshold VTH is exceeded. The CPU utilization rate is expressed, for example, as a percentage or actual execution time.

[0175] (Description of Application Information List APPINFL) The application information list APPINFL in this embodiment is shown in Fig. 16. The application version determination unit 511 stores the application information list APPINFL.

[0176] The application information list APPINFL contains a performance information column (Performance) of the application in this embodiment. For example, the application information list APPINFL contains information such as a number (No.), application name (name), variation information (variation), version information (version), and performance information (Performance).

[0177] The number (No) is information for uniquely identifying an application that is a member of this list APPINFL, and may be any number, alphabet, or the like.

[0178] The application name should be a name that represents the application. The name should be expressed using numbers, English letters, symbols, and other characters.

[0179] The variation information is information for indicating the destination and specification differences of the application, and is expressed as a value that is unique among the same applications using numbers, English letters, symbols, or other elements.

[0180] Version information is a value that is incremented each time the application is updated. It can be expressed using numbers, English letters, symbols, or other means. It should be unique within an application that has the same application name and variation information.

[0181] The performance information is recorded as the CPU utilization rate itself or as score information that can be calculated for each CPU. When recorded as score information, it is expressed using the number of steps, etc., and the processing load can be estimated from the CPU frequency, etc.

[0182] Although the present disclosure has been specifically described above based on the examples, it goes without saying that the present disclosure is not limited to the above examples and can be modified in various ways.

[0183] 1: Vehicle, 4, 41, 42: Server, 10: Vehicle control device, 100: Gateway ECU, 201: Integrated ECU, 202: Control ECU, 510: Update event generation unit, 511: Application version determination unit, 512: Application combination determination unit, 513: Download instruction unit, 514: Transmission unit, 517: Application update control unit, 519: Reception unit, 5012: Download server search unit, 5013: Server selection unit.

Claims

1. A vehicle control device comprising: a first memory; an update event generating unit that generates an update event related to the need to change first software stored in the first memory and having a plurality of applications including a first application; an application version determination unit that determines an update version of the first application to be upgraded among the plurality of applications based on the update event; and a download instruction unit that transmits a download request to a server to download a second application, which is the application of the update version determined by the application version determination unit.

2. A vehicle control device as described in claim 1, further comprising an application combination determination unit, which determines a third application having a dependency on the second application, which is an application of the update version, based on version information, which is information relating to the update version determined by the application version determination unit, and the download instruction unit transmits a download request for the third application to a server.

3. A vehicle control device according to claim 2, characterized in that the dependency relationship between the second application and the third application is held as a dependency relationship information table.

4. A vehicle control device as described in claim 3, further comprising a communication unit, the communication unit being connected to an external server, and the dependency information table being downloaded from the external server and stored in the vehicle control device.

5. A vehicle control device as described in claim 2, further comprising a communication unit, the communication unit being connected to a plurality of off-vehicle servers, and the second application and the third application download corresponding second applications and corresponding third applications stored in different off-vehicle servers.

6. A vehicle control device as described in claim 5, characterized in that the vehicle control device has server information having information regarding the second application and the third application, and the external server from which the second application and the third application can be downloaded, and the vehicle control device downloads the second application and the third application using the server information.

7. A vehicle control device according to claim 6, wherein the server information is downloaded from outside the vehicle via the communication unit and stored.

8. A vehicle control device according to claim 1, characterized in that the update event is transmitted from a server side by communication.

9. A vehicle control device according to claim 1, wherein the update event is generated by a user's operation of an HMI.

10. A vehicle control device according to claim 1, wherein the update event is generated in response to an operating state of the software.

11. A vehicle control device according to claim 10, characterized in that the operating state of the software means an increase in processing time, and the update event selects and downloads the application that improves the processing time.

Images