Vehicle control device

Abstract

Providing a vehicle control device capable of achieving a function to select a version and variation of an application according to a situation when the application is updated.A vehicle control device comprising: a first memory; an update event generation unit that generates an update event relating to a need to change first software stored in the first memory, which includes a multitude of applications, including a first application; an application version determination unit that identifies an updated version of the first application as a version update target among the multitude 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 an application with the updated version determined by the application version determination unit.

Description

Technical field

[0001] The present disclosure relates to a vehicle control device. State of the art

[0002] An electronic control unit (ECU), a vehicle control device mounted on a vehicle, contains an arithmetic processing device, such as a microcomputer, which includes a central processing unit (CPU) and read-only memory (ROM). A control program (also called a software program or application program) stored in the ROM is read and executed by the CPU, thereby controlling an in-vehicle device mounted on the vehicle. It is important to note that the software program can simply be referred to as software, and the application program can simply be referred to as an application.

[0003] Recently, as seen in a software-defined vehicle (SDV), there is an automobile in which software for controlling a vehicle is updated using a two-way communication function between the vehicle and the outside, and a function of the vehicle can be enhanced or the performance of the vehicle can be improved even after the vehicle has been sold.

[0004] JP 2017-228104 A discloses a control device (management server) that is able to efficiently distribute an update program of a program taking into account a communication state of a communication line. Citation list of patent literature

[0005] PTL 1: JP 2017-228104 A Summary of the invention: Technical problem

[0006] The following aspects were identified through examination of the present disclosure. Specifically, the number of applications integrated into the ECU will increase in the future due to the development of the SDV (Sustainable Data Processing). Furthermore, the application will continue to evolve after its market launch, necessitating more version management than ever before. Moreover, not only the latest version of the application but also earlier versions will be managed on a server, taking into account compatibility with existing applications. Additionally, it is anticipated that the application will exhibit variations depending on the vehicle model and target market, necessitating the selection of an optimal version and variation for each specific situation.

[0007] One objective of the present disclosure is to provide a vehicle control device capable of achieving a function for selecting a version and variation of an application according to a situation when the application is updated.

[0008] Further problems and novel features will become apparent from the description in this document and the accompanying drawings. Solution to the problem

[0009] An outline of representative examples of the present revelation is briefly described below.

[0010] According to one embodiment, a vehicle control device includes: a first storage; an update event generation unit that generates an update event relating to a need to change first software stored in the first memory and encompassing a multitude of applications including a first application; an application version determination unit that identifies an updated version of the initial application as a version update target among the multitude 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 an application with the updated version determined by the application version determination unit. Advantageous effects of the invention

[0011] According to the vehicle control device of the embodiment, it is possible to achieve a function for selecting the version and varying the application according to the situation. Brief description of the drawings [ Fig. 1] Fig. Figure 1 is a configuration diagram to explain a vehicle and an external vehicle network according to a first embodiment. [ Fig. 2] Fig. 2 is a diagram showing a configuration example of a vehicle control device 10 of Fig. 1 represents. [ Fig. 3] Fig. Figure 3 is a diagram illustrating the internal configuration of an electronic control unit. Fig. 2. [ Fig. 4] Fig. Figure 4 is a diagram to explain the use of a Flash ROM. [ Fig. 5] Fig. Figure 5 is a diagram to explain an update program request transmission unit. [ Fig. 6] Fig. Figure 6 is a diagram illustrating a data receiving unit of the update program. [ Fig. 7] Fig. Figure 7 is a diagram to explain update target application information and an application version combination list. [ Fig. 8] Fig. Figure 8 is a diagram to explain the operation of an application update control unit. [ Fig. 9] Fig. Figure 9 is a diagram illustrating an update program request transmission unit according to a second embodiment. [ Fig. 10] Fig. Figure 10 is a diagram illustrating an update program request transmission unit according to a third embodiment. [ Fig. 11] Fig. Figure 11 is a diagram illustrating a search sequence of a downloader trial unit. [ Fig. 12] Fig. Figure 12 is a diagram that shows an example of an application information list maintained by a server and an application version combination list to which server information is added. [ Fig. 13] Fig. Figure 13 is a diagram illustrating a display example of a user interface (UI) that prompts a user to approve an update of an application according to a sixth embodiment. [ Fig. 14] Fig. Figure 14 is a diagram to illustrate an example of the state of an application's processing load. [ Fig. 15] Fig. Figure 15 is a diagram representing a selection sequence of an update application according to a seventh embodiment. [ Fig. 16] Fig. Figure 16 is a diagram illustrating an update target application table and an application information list according to the seventh embodiment. Description of embodiments

[0012] Embodiments are described below with reference to the drawings. However, in the following description, the same components are designated by the same reference numerals, and repeated descriptions may be omitted. It should be noted that, for the sake of clarity, the drawings may be shown schematically in comparison to an actual embodiment, but they are merely examples and do not limit the interpretation of this disclosure. This disclosure may, for example, be configured using a hardware circuit mounted on a silicon single-crystal semiconductor substrate, a software program executed by a CPU, or a combination of a hardware circuit and a software program. First embodiment

[0013] Fig. Figure 1 is a configuration diagram to explain a vehicle and an external vehicle network according to a first embodiment.

[0014] As in Fig. As shown in Figure 1, a vehicle 1 includes a vehicle control device 10 and a communication device 12 connected to the vehicle control device 10. An external vehicle network 1N includes an internet infrastructure 3 as a communication network, a base station 2, and a plurality of servers 4 (41, 42) connected to the internet infrastructure 3. The server 4 (41, 42) can be referred to as an application server or an external vehicle server.

[0015] The vehicle control device 10 incorporates a variety of electronic control units (ECUs), as described later. As a representative configuration example, an electronic control unit includes, for instance, an arithmetic processing device, such as a microcomputer, which contains a central processing unit (CPU) and a read-only memory (ROM) as non-volatile memory. The ROM can be a flash ROM, as described later. A control program (also referred to as a software program or an application program) stored in the ROM is read and executed by the CPU, thereby controlling an in-vehicle device (for example, an engine, a brake, or the like) mounted on the vehicle 1. It should be noted that the software program can simply be referred to as software, and the application program can simply be referred to as an application.

[0016] The communication device 12 is connected to the base station 2 via wireless communication, so that the vehicle control device 10 can be connected to a plurality of servers 4, which are 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.

[0017] The multitude of servers 4 (41, 42) are application servers in which update software for the vehicle control unit 10 of vehicle 1 is stored. That is, the multitude of servers 4 (41, 42) contains a multitude of applications (for example, an application with an updated version or the like) that are to be stored in the ROM. When vehicle 1 needs to update the application stored in the ROM, the multitude of servers 4 (41, 42) is configured to, for example, send an application with an updated version to the To transfer vehicle 1.

[0018] Fig. Figure 2 is a diagram showing a configuration example of the vehicle control unit 10. Fig. Figure 1 represents the vehicle control device 10. The vehicle control device 10 includes the communication device 12, a gateway ECU (GW-ECU) 100, a plurality of integrated ECUs 201 (201-1, 201-2, ..., 201-N), and a plurality of 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 a plurality of subnetworks 301 (301-1, 301-2, ..., 301-N). Each of the Gateway ECU 100, the Integrated ECU 201, the Control ECU 202 and the Subnetwork 301 can be a single unit or a multitude of units.

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

[0020] The integrated ECU 201, for example, is configured to calculate a control command value for the control ECU 202, which directly controls an actuator based on the received control data, and to transmit the calculated control command value to the control ECU 202. For example, the integrated ECU 201 corresponds to an autonomous driving control ECU (Auto Drive: AD ECU), an advanced driver assistance system ECU (ADAS ECU), or the like.

[0021] The control ECU 202 directly controls the actuator and similar components. The control ECU 202 is configured to communicate with the integrated ECU 201 via network 300 or subnetwork 301.

[0022] Network 300 connects the GW-ECU 100 and the integrated ECU 201. Network 300 primarily uses in-vehicle Ethernet (Ethernet is a registered trademark). Network 300 can include a Local Area Network (LIN), a Controller Area Network (CAN), or other network infrastructure.

[0023] Subnetwork 301 connects the integrated ECU 201 and the control ECU 202. Subnetwork 301 primarily uses in-vehicle Ethernet or CAN. However, subnetwork 301 may use a different protocol. Furthermore, the ECUs connected by subnetwork 301 are not limited in this disclosure.

[0024] Fig. Figure 3 is a diagram illustrating an internal configuration of the electronic control unit of Fig. 2. Although Fig. While section 3 presents an example of the internal configuration of the integrated ECU 201 as a representative example, other ECUs, such as the Gateway ECU 100, the Control ECU 202, and the like, have a similar internal configuration. Here, the configuration of the ECU is described broadly without focusing on a specific ECU, using the internal configuration of the integrated ECU 201 as a representative example.

[0025] The integrated ECU 201 includes a communication interface (COMIF) 401 (401-1, ..., 401-N), an analog-to-digital conversion interface (ADIF) 402, an internal bus 405, and a central processing unit (CPU: CPU1, ..., CPUN) 406 (406-1, ..., 406-N). The integrated ECU 201 also includes random-access memory (RAM: RAM1, ..., RAMN) 407 (407-1, ..., 407-N) as volatile memory and a flash ROM (FlashROM1, ..., FlashROMN) 408 (408-1, ..., 408-N) as non-volatile memory. In this example, Fig. Figure 3 shows a configuration example in which each of the communication interface 401, central processing unit 406, random access memory 407 and flash ROM 408 are a multitude of units, but each can of course be a single unit.

[0026] There are a variety of 401 communication interfaces (401-1, ..., 401-N) for each communication channel, such as CAN and in-vehicle Ethernet. The 401 communication interface (401-1, ..., 401-N) is electrically connected to the communication channel, such as CAN or in-vehicle Ethernet.

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

[0028] 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 an analog signal from the analog sensor into a digital signal.

[0029] The sensor 403 can be, for example, various sensors, such as an accelerometer, an angular velocity sensor, a speed sensor, and a heat sensor.

[0030] The actuator 404 can consist primarily of motors. Examples of this type of motor include a large motor for propelling a vehicle and a small motor for electronic control. The connection for a command value to a semiconductor device connected to the actuator 404 to drive the actuator 404 can, for example, be configured to transmit a pulse width modulation (PWM) value as a digital signal via an analog-to-digital conversion interface (ADIF).

[0031] 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 connect the communication interface 401, the central processing unit 406, the flash ROM 408, and the digital-to-analog converter 410.

[0032] 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 working area, executes a control program stored in the flash ROM 408, and controls the operation of the integrated ECU 201.

[0033] In this example, the random access memory 407 is provided as local memory of the central processing unit 406. A random access memory 407-1 is connected as local memory to the central processing unit 406-1, and the random access memory 407-N is connected as local memory to the central processing unit 406-N. It should be noted that the random access memory 407 can be configured to be accessed by another electronic control unit (for example, the GW-ECU 100, the control ECU 202, and the like, which are located in Fig. 2 are shown) to be accessible.

[0034] The Flash ROM 408 can be configured as non-volatile memory capable of electrically rewriting and erasing data. The Flash ROM 408 is a data storage area and stores a control program executed by the Central Processing Unit 406, a control command value, and the like. Although not particularly restricted, the Flash ROM 408-1 can be configured to store a control program, a control command value, and the like for the Central Processing Unit 406-1, and the Flash ROM 408-N can be configured to store a control program, a control command value, and the like for the Central Processing Unit 406-N. It should be noted 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 can, for example, be equal to the number of central processing units 406, less than the number of central processing units 406, or greater than the number of central processing units 406.

[0035] A conceptual diagram of the application update according to the present disclosure is shown at the bottom of Fig. 3 shown. In the present revelation, as for example in the lower part of Fig. As shown in Figure 3, the 408-1 flash ROM stores the first software (1stSOFT) as a first memory, including a variety of applications (APPLS: 1stApplA_A, ApplB_A, ..., ApplN_X), including a first application (1stApplA_A). Then, it is assumed that an update event has been generated, indicating the need to change the first software (1stSOFT).

[0036] In this case, the ECU 201 identifies an updated version of the first application (1stApplA_A) as a version update target among the multitude of applications (APPLS) based on the update event and transmits a download request to server 41 to download a second application (2ndAppl), which is an application with the specified updated version (1stApplA_B). Accordingly, an application (second application) that is an optimal updated version can be downloaded according to the update event.

[0037] The ECU 201 also determines a third application (3rdAppl (ApplB_B)) with a dependency relationship to the second application (2ndAppl), which is an application with the updated version (1stApplA_B), based on version information about the second application with the specified updated version (2ndAppl (1stApplA_B)). The ECU 201 then transmits a download request for the third application to server 42. Accordingly, a different application (third application) with a dependency relationship between versions can be selected, and thus, for example, normal execution between the second application 2ndAppl with the updated version (1stApplA_B) and the application with the pre-updated version (ApplB_A) is not possible.If, on the other hand, normal execution is possible between the second application (2ndAppl) with the updated version (1stApplA_B) and the third application (ApplB_B), then a normal application can be downloaded. This example illustrates a case where the second application (2ndAppl) is stored on server 41 and the third application (ApplB_B) is stored on server 42, which is different from server 41. Of course, the second application (2ndAppl) and the third application (ApplB_B) can also be stored on the same server (41 or 42).

[0038] In the present revelation, as will be explained later with reference to Fig. As described in section 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.

[0039] The Update Event Generation Unit 510 generates event information (hereinafter referred to as an update event) relating to the need to change the initial software.

[0040] The application version determination unit 511 identifies an updated version of a first application as a version update target among a multitude of applications based on the update event.

[0041] The download instruction unit 513 transmits a download request to server 41 to download a second application, which is an application with the updated version determined by the application version determination unit.

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

[0043] Next, the use of the Flash ROM 408 will be described with reference to Fig. 4 described. Fig. Figure 4 is a diagram to explain 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. As an example, version A (VerA) of application A (ApplicationA) 501-A is stored as application 501 in program area 4081. For example, application A (ApplicationA) 501-A can also be stored as 1.ApplA_A in Fig. 3. In backup area 4082, version B (VerB) of application A (ApplicationA) 501-B is stored as application 501. In download area 4083, version C (VerC) of application A (ApplicationA) 501-C is stored as application 501.

[0044] Application A (Version A: VerA) 501-A in program area 4081 is stored in direct access memory 407 and executed by the central processing unit 406, thereby controlling the vehicle 1 via the vehicle control unit 10. Backup area 4082 stores version B (VerB) of application A 501-B, which differs from that of program area 4081. Download area 4083 stores version (VerC) of application A 501-C, which differs from that of program area 4081.

[0045] Each of the program area 4081, backup area 4082, and download area 4083 is a space stored in the Flash ROM 408 and can be stored across multiple Flash ROMs 408-1, ..., and 408-N. The program area 4081, backup area 4082, and download area 4083 can be represented and managed as folders by a file system, depending on the operating system (OS).

[0046] The ECU 201 operates primarily using program data (here an application A501-A) stored in program area 4081.

[0047] Backup area 4082 is used to store program data for backup (in this case, application B501-B). This means that at the time of a program update, if the update fails or there is a problem with the updated program, the application stored in backup area 4082 is returned to program area 4081. For example, if application A501-A is being updated and an update failure occurs due to an error downloading the update program caused by a communication error, or if a problem with the update program arises due to an error in the operation of the downloaded update program, the downloaded update program is deleted or removed from program area 4081.Then the application (here, application A501-B), which is stored in backup area 4082, is saved or returned to program area 4081. Accordingly, the operation of ECU 201 is guaranteed.

[0048] 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 or the like by a verification control program stored or contained in program area 4081 or random access memory 407, and then copied or duplicated into program area 4081. Download area 4083 and backup area 4082 can be backed up in random access memory 407.

[0049] Next, an update program request transmission unit 500, which is provided in a desired ECU of the vehicle control device 10, is used with reference to Fig. 5 described. Fig. Figure 5 is a diagram to explain an update program request transmission unit.

[0050] The update program request transmission unit 500 is provided in a desired ECU (in this example, any ECU of the gateway ECU 100, the integrated ECU 201, or the control ECU 202) of the vehicle control device 10. The update program request transmission unit 500 includes, as functional blocks, the update event generation unit 510, the application version determination unit 511, the application combination determination unit 512, the download instruction unit 513, and a transmission unit 514. The update program request transmission unit 500 can also be configured by an application, with each functional block representing a function of the application. The request transmission unit 500 can be configured as a single application or can be implemented as multiple applications with different functions. Fig. 5 indicates the connection between the function blocks (510 to 514), that there is a data exchange relationship.

[0051] The Update Event Generation Unit 510 generates an update request for the application based on the status of the software and information from an external sensor.

[0052] The application version determination unit 511 receives the update request from the update event generation unit 510 and determines the updated version of the application for which the update request was made. The update version selection means is not limited in the present embodiment.

[0053] The application version determination unit 512 determines a version that works normally for another application with a dependency relationship, based on information regarding the updated version of the application determined by the application version determination unit 511. In a procedure for determining the version that works normally, the determination is made using an application version combination list (APPCL). A configuration example of the application version combination list (APPCL) is given with reference to Fig. 7, which will be described in detail later.

[0054] The application version combination list (APPCL) can be viewed as a dependency relationship information table, and, for example, the application combination determination unit 512 of the vehicle control unit 10 can hold the application version combination list APPCL. Additionally, as described in a second embodiment, the application version combination list APPCL can be stored, for example, on the server 4 (41, 42), which is an external vehicle server. In this case, the vehicle control unit 10 is connected to the server 4 (41, 42) via the communication unit 12, and the vehicle control unit 10 can download the application version combination list APPCL from the server 4 (41, 42) and instruct the application combination determination unit 512 to hold the application version combination list APPCL.It should be noted that the vehicle control unit 10 can be any desired ECU (any ECU of the gateway ECU 100, the integrated ECU 201 or the control ECU 202) of the vehicle control unit 10.

[0055] The download instruction unit 513 generates transmission data to transmit a download request relating to the specific application version to server 4 (41, 42).

[0056] The transmission unit 514 transmits the transmission data generated by the download instruction unit 513, along with destination information, to a network outside the ECU. The destination information is, for example, server 4 (41, 42). The network outside the ECU is, for example, subnetwork 301, network 300, Internet infrastructure 3, or the like.

[0057] Next, a data receiving unit 520 of the update program, which is provided in a desired ECU of the vehicle control device 10, is referenced. Fig. 6 described. Fig. Figure 6 is a diagram illustrating a data receiving unit of the update program.

[0058] The update program's data receiving unit 520 includes, as 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 can be configured as a single application or implemented as multiple applications with different functions. Fig. 6 indicates the connection between the function blocks (516 to 519), showing that there is a data exchange relationship.

[0059] The receiver unit 519 receives data transmitted from a network outside the ECU, reads the data's destination information, and forwards the data to a target application. In this example, the receiver unit 519 stores the application download data in the temporary storage unit 518.

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

[0061] The application update control unit 517 receives a download termination instruction from the temporary storage unit 518. Alternatively, the application update control unit 517 is started periodically and verifies whether all applications in an update application list APPRENL are stored in the download area 4083. After verifying that the corresponding application is stored in the download area 4083, the application update control unit 517 issues a stop instruction to each application.

[0062] Upon receiving a stop command, each application enters either a stop state or an update-ready state. The stop state indicates a condition in which major control actions, such as process termination and sleep, are not performed periodically and an update is permitted.

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

[0064] The backup creation unit 516 copies the target update application, which is deployed in program area 4081, to backup area 4082. After the copy is complete, a completion notification is sent to the application update control unit 517.

[0065] In response to an instruction from the application update control unit 517, the application update unit 515 copies the program data in the update application list APPRENL from download area 4083 to application area 4081. After the copy is complete, a completion notification is sent to the application update control unit 517. Following this, for example, the vehicle control unit 10 or a predetermined ECU within the vehicle control unit 10 is restarted. Accordingly, the program data stored in program area 4081 is loaded into the direct access memory 407 and executed by the central processing unit 406, thereby controlling the vehicle 1 from the vehicle control unit 10.Alternatively, by starting only the updated application, it becomes unnecessary to initialize the existing application, and thus it is possible to update some applications without stopping the vehicle control function, for example while driving.

[0066] Next, update target application information (APPRENI) and the application version combination list (APPCL) are retrieved with reference to Fig. 7 described. Fig. Figure 7 is a diagram to explain update target application information and an application version combination list.

[0067] The update target application information (APPRENI) includes an identification number (ID), an application name (Name), variation information (Variation), and version information (Version). The identification number (ID) is information that uniquely identifies an application. Here, the application name (Name) is described as Application A (Application A) as an example. The variation information (Variation) specifies a country, city, region, state, car size, and similar details.

[0068] The application version combination list (APPCL) contains an identification number (ID), an application name (Name), variation information (Variation), and version information (Version). The APPCL provides a list of application combinations that operate stably, taking into account the variation and version information.

[0069] The combination expressed in this APPCL list is either a combination of past operational data records or a combination certified by a vehicle manufacturer. If an application has no dependency relationship, it is not described in this APPCL list. Furthermore, numerous combination tables are created by different applications. This APPCL list is also created for past versions, and different combination lists are even created for the same application across different versions.

[0070] Next, the operation of the application update control unit 517 will be described with reference to Fig. 8 described. Fig. Figure 8 is a diagram illustrating the operation of an application update control unit. Steps S100 to S110 are described sequentially below.

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

[0072] S101: Subsequently, if the downloaded data is saved (yes), processing continues to the next sequence (S102). If it is not saved (no), processing returns to the initial sequence (S100).

[0073] S102: Next, in this sequence, the application update control unit 517 issues a stop command to all running applications. The stop command is used by an operating system (OS) function, signal communication, or service communication.

[0074] S103: Next, the application update control unit 517 confirms in this sequence whether all applications are in a stopped state. If even one application is not in a stopped state (no), processing returns to the previous sequence (S102). Alternatively, this sequence (S103) is executed again. If the application is forcibly terminated while in an execution state, the state, flag, and other parameters are not initialized, which can lead to a problem after the update. Therefore, the software update can be performed safely using this sequence (S103). In the case of returning to the sequence (S102) or in the case of re-executing this sequence (S103), processing can be performed immediately or after waiting for a specified period of time.

[0075] S104: In this sequence, the application update control unit 517 issues a backup creation instruction to request the backup creation unit 516 to create a copy of the update target application.

[0076] S105: In this sequence, the backup creation unit 516 saves a copy of the target application to backup area 4082. By executing this sequence, even if the application update fails, it is possible to revert to the state before the update by restoring the backup data, thus achieving a safe software update. After all target applications have been copied, the next sequence (S106) is executed.

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

[0078] S107: In this sequence, the application update unit 515 deletes the application for which the update instruction was issued from program space 4081. Examples of a deletion procedure include deleting from the file system and writing an invalid value (zero, 0, or the like) to the memory space (program space 4081), and the like, and an implementation procedure is not limited.

[0079] S108: In this sequence, processing waits until the deletion operation is complete, and if the deletion is not complete (no), processing returns to the previous sequence (S107). Confirmation of deletion completion is performed by checking the file system whether a valid (or invalid) value has been written to the memory space, or similar methods, but no specific implementation procedure is restricted. After confirmation of deletion completion (yes), processing proceeds to the next sequence (S109).

[0080] S109: In this sequence, the application update unit 515 saves the application data stored in download area 4083 to program area 4081. All applications are stored in program area 4081 and the next sequence is executed (S110).

[0081] S110: In the final sequence, the application update unit 515 starts the updated application. As an example of a startup procedure, a restart instruction is given to the updated application. The operating system or application runtime starts the appropriate application based on the restart instruction. In this procedure, starting only the updated application eliminates the need to initialize the existing application, thus making it possible to update several applications without stopping any functionality, for example, while driving. As another example, the restart instruction is given to all applications. By initiating a restart from the initialization process, it is possible to more easily start a new application after the update, while maintaining data consistency between applications.With regard to a restart procedure for an application, a different implementation method than the example above is also conceivable, and the restart procedure is not limited in the present embodiment.

[0082] The Application Update Controller 517, the Application Update Controller 515, and the Backup Creation Unit 516 can be implemented as a single application. In a case where the Application Update Controller 517, the Application Update Controller 515, and the Backup Creation Unit 516 are configured by multiple shared applications, a module (515, 516) that accesses hardware (Hw) and the Application Update Controller 517, which controls an update sequence, can be shared, developed, and updated. In a case where the Application Update Controller 517, the Application Update Controller 515, and the Backup Creation Unit 516 are configured by an integrated application, the memory required for a time-delay interface (IF) due to communication between applications (515, 516, 517) can be reduced, and further resources can be saved. Second embodiment

[0083] Next, another configuration example of the Update Program Request Transfer Unit 500 will be presented with reference to Fig. 9 described. Fig. Figure 9 is a diagram illustrating an update program request transmission unit according to the second embodiment.

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

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

[0086] The application server 41, 42 selects an application with a dependency relationship and an application of a corresponding version based on the application's version information and adds the selected application to the application combo list APPCL.

[0087] The application server 41, 42 transmits the generated application combination list APPCL to the application combination determination unit 512 as a destination.

[0088] The receiving unit 519 receives the application combination list APPCL and forwards data from the application combination list APPCL to the application combination determination unit 512.

[0089] As described in the first embodiment, the application combination determination unit 512 determines a version that works normally for another application with a dependency relationship, based on the application combination list APPCL. In a method for determining the version that works normally, the determination is made using an application version combination list APPCL.

[0090] The download instruction unit 513 generates transmission data to transmit a download request of the specified application version to the server 41, 42.

[0091] The transmission unit 514 transmits the transmission data generated by the download instruction unit 513 together with the destination information to a network (subnetwork 301, network 300, Internet infrastructure 3) outside the ECU via the communication device 12 and executes the download instruction.

[0092] In the present embodiment, since it is not necessary to store an infinite amount of combination information in the vehicle control device 10, storage capacity can be saved. Furthermore, if the number of combinations becomes enormous, the combination information can be generated on a cloud site within a realistic timeframe using the computing power of the server 41, 42, and the download instruction can be initiated. Third embodiment

[0093] Next, another configuration example of the Update Program Request Transfer Unit 500 will be presented with reference to Fig. 10 described. Fig. Figure 10 is a diagram illustrating an update program request transmission unit according to a third embodiment.

[0094] One in Fig. 10. Update program request transmission unit 5002 shown differs from update program request transmission unit 500 of the first embodiment in that a downloader trial unit 5012 and a server selection unit 5013 are added as applications and a downloadable server for an application described in the application combination list APPCL is selected from several servers based on the application combination list APPCL.

[0095] In the present embodiment, the downloader test unit 5012 searches for downloadable server information for each application in order to download the applications described in the application combination list APPCL. The downloader test unit 5012 receives the application combination list APPCL from the application combination determination unit 512. The downloader test unit 5012 confirms the application download feasibility with the application server 41, 42 via the transmission unit 514 and the communication device 12.

[0096] The downloader trial unit 5012 receives the application download feasibility from the application servers 41, 42 via the communication device 12 and the receiving unit 519. Each of the application servers 41, 42 maintains a list of applications stored by itself or a list of applications that it can upload itself (for this list, the application information lists APPLA and APPLB, provided by the server in Fig. 12 are managed, are designated). When the application download feasibility is confirmed by the download trial unit 5012, each of the application servers 41, 42 transmits information regarding download feasibility to the download trial unit 5012 based on the list of applications that it manages.

[0097] The download trial unit 5012 transmits server information (SRVIF) to the server selection unit 5013, specifying from which server a target application can be downloaded. The server selection unit 5013 adds the downloadable server information (SRVIF) for each application to the application combination list APPCL (this list can be supplemented by an application version combination list APPCLS). Fig. 12, to which the server information (SRVIF) is added). That is, 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.

[0098] In the present embodiment, software can be updated by combining a plurality of applications of the application server 41, 42.

[0099] Next, a search sequence of the downloader test unit 5012 is executed with reference to Fig. 11 described. Fig. Figure 11 is a diagram illustrating a search sequence for a downloader trial unit. Steps S200 to S208 are described sequentially below.

[0100] This sequence describes a sequence until a download request is transmitted to server 41, 42.

[0101] S200: First, the update event generation unit 510 detects an update event. The update event indicates a registration notification of a new application version from the server 41, 42, a download instruction from a user, or the like. A specific example of the update event is described in a later embodiment. In other words, the update event is transmitted from the server 41, 42 to the vehicle control unit 10 by communication via the communication device 12.

[0102] S201: In the next sequence, the update event generation unit 510 issues an update instruction to the application version determination unit 511. The update instruction includes an update event and specifies application information depending on the update event.

[0103] S202: In the next sequence, the application version determination unit 511 selects an update target application and its version based on the update instruction information. Specific examples of the selection are described in a later embodiment.

[0104] S203: In the next sequence, the application combination determination unit 512 creates a combination table. If the application information is included in the update instruction, the application combination determination unit 512 determines the application version based on the update instruction content. Additionally, the version selection for a separate application (or another application) is also performed for the application and its version. The application version combination list APPCL is used for the application version combination.

[0105] S204: In the following sequence, the download trial unit 5012 selects an application from the application version combination list APPCL. The selection order, such as the registration order or alphabetical order, is not specifically indicated.

[0106] S205: Then, in the next sequence, the download trial unit 5012 selects server 4 (41, 42) from which the selected application and version information can be downloaded. A selection procedure is described later.

[0107] S206: The next step verifies whether all applications described in the application version combination list (APPCL) are selected. Upon confirmation, a parameter indicating whether the selection was made is added to the APPCL. The selection is performed in order of the ID number (number order), and an evaluation is carried out, such as whether all rows have been selected.

[0108] If the selection is not complete (no), processing returns to the previous sequence (S204), and a selection is made for an unselected application in the application version combination list APPCL.

[0109] Once all selections are complete (yes), a download request is generated for each server (41, 42), and a download instruction is issued. Regarding the granularity of the download request, the download request can be generated for each application, or it can be generated for each server (41, 42), where requests for a multitude of applications can be generated simultaneously, and the download request is described by various other means.

[0110] S207: To transmit the download request to the application server 41, 42, the transmission unit 514 transmits the data frame to the Internet infrastructure 3, which is an external vehicle network, using a protocol such as Ethernet or CAN.

[0111] Fig. Figure 12 is a diagram that shows an example of an application information list maintained by a server and an application version combination list to which server information is added.

[0112] In Fig. Section 12, Application Information List APPLA, is a configuration example of an application information list managed by Server 41 (also referred to as Server A), and Application Information List APPLB is a configuration example of an application information list managed by Server 42 (also referred to as Server B). Each of the Application Information Lists APPLA and APPLB includes an application name (Name), variation information (Variation), and version information (Version). Additional information to identify the application can also be added.

[0113] When the application download feasibility is confirmed by the download test unit 5012 via the transmission unit 514, the server 41, 42 determines the application download feasibility based on the application information lists APPLA and APPLB. The server 41, 42 then transmits information regarding the determined application download feasibility to the download test unit 5012 via the receiving unit 519.

[0114] Different pieces of variation and version information with the same application name can be added to the application information lists APPLA and APPLB. Within the application information list (APPLA, APPLB), a multitude of servers maintain four different combinations of variation and version information. Furthermore, the application information list (APPLA, APPLB) can contain application names, variation information, and version information that overlap across these four servers.

[0115] In Fig. 12. The application version combination list APPCLS, to which the server information is added, is modified by adding information SRVIF that uniquely identifies a downloadable server to which in Fig. The application version combination list APPCL shown in section 5 is obtained. The APPCL list is generated when the server selection unit 5013, which has received information indicating from which server a download target application can be downloaded (transmitted by the download trial unit 5012 to the server selection unit 5013), adds the downloadable server information SRVIF for each application to the application combination list APPCL.

[0116] The Application Version Combination List (APPCLS), to which the server information (SRVIF) is added in this example, is a configuration example that provides a field for adding the server information (SRVIF) and sets a value (A, B) in that field that specifies a downloadable server. Here, A specifies server 41 and B specifies server 42. The value (A, B) can also include information that can uniquely identify the application server, such as an Internet Protocol (IP) address, a Media Access Control (MAC) address, and a server name.

[0117] By using the application version combination list APPCLS, to which the server information SRVIF is added, application version A (variation A, version 1.0) and application version B (variation A, version 1.1) with a dependency relationship are downloaded from server 41(A). Additionally, application version C (variation B, version 2.0) with a dependency relationship is downloaded from server 42(B). That is, the applications in the dependency relationship, which are held by the various external vehicle servers (41, 42), are downloaded from the respective external vehicle servers. Accordingly, software updates can be performed using optimal applications by combining applications stored on a variety of application servers 41, 42.

[0118] It should be noted that in the example of the application version combination list APPCLS in Fig. 7. Both application version A (variation A, version 1.0) and application version B (variation A, version 1.1) are stored in server 41(A), but the present invention is not limited thereto. Application version A (variation A, version 1.0) can be stored in server 41(A), and application version B (variation A, version 1.1) can be stored in server 42(B). Fourth embodiment

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

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

[0121] The connection to the external vehicle network is established via a vehicle network, such as in-vehicle Ethernet or CAN, and via the Gateway ECU 100.

[0122] The Gateway ECU 100 and subsequent devices are connected to a network outside the vehicle, and subsequent communication protocols are not specified.

[0123] The download trial unit 5012 transmits to all accessible application servers 4 (41, 42) the application selected from the application version combination list APPCL and version information.

[0124] Each application server 4 (41, 42) generates available application information regarding the application and version that can be transferred by the application server 4 itself when the application can be downloaded, and notifies the download trial unit 5012 of the generated available application information.

[0125] The receiving unit 519 transmits the available application information to the downloading trial unit 5012.

[0126] The Download Trial Unit 5012 holds and manages the available application information for each server (41, 42).

[0127] The download trial unit 5012 executes the sequence on the application version combination list APPCL.

[0128] In the present embodiment, software updates can also be performed by combining applications held by an unspecified number of application servers under a plurality of application servers. Fifth embodiment

[0129] A fifth embodiment relates to a sequence that enables the saving of CPU resources on the ECU side of the vehicle control device 10. In the sequence according to the fifth embodiment, the downloader test unit 5012 includes, in addition to the third embodiment, a configuration for downloading the server information SRVIF, which was created by the application server 4 (41, 42) as a download server. Therefore, in the sequence of the fifth embodiment, it is possible to save CPU resources on the ECU side of the vehicle control device 10 compared to the fourth embodiment.

[0130] Details of the sequence of the fifth embodiment are described below.

[0131] Similar to the previous example (fourth embodiment), the download test unit 5012 connects the vehicle control device 10 to the external vehicle network (Internet infrastructure 3) via the transmission unit 514.

[0132] The connection to the external vehicle network is established via a vehicle network, such as in-vehicle Ethernet or CAN, and via the Gateway ECU 100.

[0133] The Gateway ECU 100 and subsequent devices are connected to a network outside the vehicle, and subsequent communication protocols are not specified.

[0134] The download trial unit 5012 transfers the entire application version combination list (also called combination list) APPCL to a server (here, for example, 41 is described below) of the accessible application servers (here, for example, 41, 42 and 4X are set).

[0135] Application server 41 updates the application information it can provide itself under the application information in the APPCL combination list (for example, adding the downloadable server information SRVIF (A:41) to the application information it can provide itself). Accordingly, the application version combination list APPCLS is created, to which the downloadable server information SRVIF (A:41) is added.

[0136] Application server 41 queries another application server 42, which it can access itself, regarding an application that it cannot provide itself, using the application information in the combination list APPCL. That is, the application version combination list APPCLS, to which the downloadable server information SRVIF (A:41) is added, is transferred from application server 41 to application server 42.

[0137] The other application server 42, which received the query, updates the application information that it can provide itself under the application information in the combo list APPCL and queries application server 41.

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

[0139] The other application server 42 queries the application server 41 for information about a server 4X that is reachable by the other application server 42.

[0140] In a case where the server information has not been added to the entire application version combination list APPCL, application server 41 makes a query to the notified reachable server 4X.

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

[0142] Next, another configuration example of the update event generation unit 510 according to a sixth embodiment will be described with reference to Fig. 13 described. Fig. Figure 13 is a diagram illustrating an example of a user interface (UI) that prompts the user to approve an update of an application according to the sixth embodiment.

[0143] The sixth embodiment differs from the first embodiment in that one (for example, 201-1) of the vehicle's internal ECUs (201, 202) has a human-machine interface (HMI) function 1301. The update event generation unit 510 receives data from the receiving unit 519, communicates with an ECU (HMI ECU: 201-1) that has the HMI function 1301 via the transmission unit 514, and causes the HMI function 1301 to display a user interface (UI) that requests update approval from the user. The HMI function 1301 can be configured, for example, by causing a display unit 1302, configured by a display field with a touch sensor, to display a graphical user interface (GUI).

[0144] Application server 4 (41, 42) transmits a notification message to update event generation unit 510 that a new software version has been added. Upon receiving the notification message, 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).

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

[0146] The HMI-ECU: 201-1 displays a request for update approval on display unit 1302 as a GUI. In this example, an "Update" button 1303 is displayed on display unit 1302. If the user approves the update, they can send a notification of the update approval by pressing (clicking) the "Update" button 1303 with a finger or similar device.

[0147] When the user approves the update via the GUI, the HMI-ECU: 201-1 transmits an update approval instruction to the update event generation unit 510.

[0148] The update event generation unit 510, which has received the update approval instruction, designates a new version of the application, generates an update event, and performs the software update described in the first embodiment. That is, the update event is generated by an HMI action (here, an action such as clicking the "Update" button 1303) by the user.

[0149] Fig. Figure 13 presents a display example of the UI that requests update approval from the user, as an example of HMI function 1301. The in Fig. The UI shown in Figure 13 is a GUI and includes a screen for displaying various content, such as car navigation, a speedometer, and a video, and functions for operating the screen, such as a touch panel and a button. The "Update" button (Figure 1303) is an interactive image displayed on the touch panel, a physical button, or the like.

[0150] In the present embodiment, it is possible to update software when a new application is released, and by updating under user approval, it is possible to prevent the software from being updated to software that is unintended by the user. Seventh embodiment

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

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

[0153] Fig. Figure 14 presents an example of a case in which the application load exceeds a threshold (VTH) and a software update is required. In the present embodiment, an example is described in which three applications A, B, and C are mounted on a particular CPU (as a representative example, 406-1), which are in Fig. 3 is shown. Fig. Figure 14 is a graph representing a processing load example of the CPU (406-1) when applications A, B, and C become unstable. It is presented as a bar graph. Fig. Figure 14 shows a vertical axis representing the CPU utilization rate (%), a horizontal axis representing time (T), and each of the applications A, B, and C is started at each time interval t. For example, application C reports a utilization rate of approximately 35% at time t-1. Additionally, the vertical axis of this graph shows the sum of the CPU utilization rates at each time interval (t-1, t, t+1, ..., t+n) for application A, application B, and application C. Any value representing the CPU utilization rate is set as the threshold VTH.

[0154] According to Fig. 14. The CPU utilization rate exceeding the threshold VTH is detected at time t+3. The update event generation unit 510 collects the CPU utilization rate, as shown in Fig. Figure 14 shows how to monitor whether the CPU utilization rate exceeds the threshold VTH. Various methods are conceivable as a method for collecting CPU utilization rates, but this method is not limited to OS functions or the like.

[0155] The update event generation unit 510 generates an update event to update the application when the CPU utilization rate exceeds the threshold VTH. 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). Then, in order to improve processing time, the update event selects an update application based on the application's CPU utilization rate when the CPU utilization rate exceeds the threshold VTH and a performance value to be described later, and the corresponding update application is downloaded from server 4 (41, 42).

[0156] Next, the selection sequence of the update application according to the seventh embodiment will be described with reference to Fig. This sequence is described in section 15. It is executed when the application version determination unit 511 receives an update event, which in this embodiment is issued by the update event generation unit 510. Steps S300 to S309 are described sequentially below.

[0157] Step S300: In the first sequence, an application is selected and processing begins. For example, we will first assume that application A is selected.

[0158] Step S301: In the next sequence, the performance value (20) of the performance information described in an application information list APPINFL, which is located in, is determined for the selected application (A). Fig. The value shown in 16 is compared to the detected CPU utilization rate (for example, 35).

[0159] Step S302: In the next sequence, if the CPU utilization rate exceeds the performance value (yes), processing continues to the next sequence (step S303). If the CPU utilization rate does not exceed the performance value (no), processing continues to the next sequence (step S304). For example, since the CPU utilization rate (35) exceeds the performance value (20), processing continues to step S303.

[0160] Step S303: In this sequence, an APPRENT update target table is created by inserting application information from an application with a CPU utilization rate exceeding the performance value into the APPRENT update target application table, which is located in Fig. Figure 16 illustrates this. Application information includes, for example, a number (no), an application name (name), variation information (variation), version information (version), a CPU utilization rate (CPU utilization), and similar data. As an example, the application information for application A is described at entry number 1. The application information for application C is described at entry number 2.

[0161] Step S304: In the next sequence, it is evaluated whether all applications whose CPU utilization rate is related to the excess are selected. If they are not selected (no), processing returns to the first sequence (S300) (at this point, for example, application C is selected). If all applications are selected (yes), processing continues to the next sequence (S305).

[0162] Step S305: In the following sequence, it is evaluated whether information (adding a load or the like) is inserted into the update target application table APPRENT. If it is inserted (yes), processing continues to the next sequence (S306). If it is not inserted (no), the sequence ends.

[0163] Step S306: In the following sequence, an update target application is selected, and the latest alternative version is selected from the update target application.

[0164] Step S307: In the following sequence, a performance value in a performance information field of the selected version is compared with the CPU utilization rate of the target update application.

[0165] Step S308: In the following sequence, it is assessed whether the performance value is below the CPU utilization rate. If it is (yes), processing continues to the next sequence (S309). If it is not (no), processing returns to the previous sequence (S306).

[0166] Step S309: In the last sequence, the application of the selected version is chosen as the application to be downloaded. (Description of the update target application table APPRENT)

[0167] Fig. Figure 16 represents the update target application table APPRENT according to the present embodiment. The application version determination unit 511 creates the update target application table APPRENT.

[0168] This application table APPRENT describes information regarding a number (no), an application name (Name), variation information (Variation), version information (Version), and the CPU utilization rate (CPU Utilization).

[0169] The number (no) is information to uniquely identify an application that is a member of this APPRENT table, and can be any numeric value, any alphabet, or the like.

[0170] The application name is a description that represents the application. The name is expressed using a number, English, a symbol, or similar means.

[0171] The variation information is information used to represent a target or specification difference of an application and represents a unique value between the same applications using a number, English, a symbol, or the like.

[0172] Version information describes a value that is incremented each time an application is updated. Version information is expressed using a number, English text, a symbol, or similar means. Version information is unique within applications that share the same application name and variation information.

[0173] The CPU utilization rate is inserted when the update event generation unit 510 creates this APPRENT table. The CPU utilization rate indicates the CPU utilization rate of each application when it exceeds the VTH threshold. The CPU utilization rate is represented, for example, as a percentage or the actual execution time. (Description of the application information list APPINFL)

[0174] Fig.Figure 16 represents the application information list APPINFL in the present embodiment. The application version determination unit 511 stores the application information list APPINFL.

[0175] The application information list APPINFL describes a performance information field of the application in the present embodiment. This application information list APPINFL describes, for example, information regarding a number (no), an application name (name), variation information (variation), version information (version), and performance information (performance).

[0176] The number (no) is information to uniquely identify an application that is a member of this list APPINFL, and can be any numeric value, any alphabet, or the like.

[0177] The application name is a description that represents the application. The name is expressed using a number, English, a symbol, or similar means.

[0178] The variation information is information used to represent a target or specification difference of an application and represents a unique value between the same applications using a number, English, a symbol, or the like.

[0179] Version information describes a value that is incremented each time an application is updated. Version information is expressed using a number, English text, a symbol, or similar means. Version information is unique within applications that share the same application name and variation information.

[0180] Performance information is described as either the CPU utilization rate itself or rating information that can be calculated for each CPU. If described by rating information, this information is presented using the number of steps and similar metrics, and the processing load can be estimated based on CPU frequency or similar indicators.

[0181] Although the present disclosure has been specifically described above with reference to the embodiments, the present disclosure is not limited to the embodiments above and various modifications may be made. Reference symbol list 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 Receiving unit 5012 Downloader Test Unit 5013 Server Selection Unit QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] JP 2017-228104 A [0004, 0005]

Claims

[1] Vehicle control device comprising: a first storage; an update event generation unit that generates an update event relating to a need to change first software stored in the first memory and encompassing a multitude of applications including a first application; an application version determination unit that identifies an updated version of the initial application as a version update target among the multitude 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 an application with the updated version determined by the application version determination unit. [2] Vehicle control device according to claim 1, further comprising: an application combination determination unit, wherein the application combination determination unit determines a third application with a dependency relationship to the second application, which is an application with the updated version, based on version information that is information regarding the updated version determined by the application version determination unit, and The download instruction unit transmits a download request from the third application to a server. [3] Vehicle control device according to claim 2, wherein a dependency relationship between the second application and the third application is held as a dependency relationship information table. [4] Vehicle control device according to claim 3, further comprising: a communication unit the communication unit is connected to an external vehicle server, and The dependency relationship information table is downloaded and stored from the external vehicle server. [5] Vehicle control device according to claim 2, further comprising: a communication unit the communication unit is connected to a large number of external vehicle servers, and The second application and the third application download a corresponding second application and a corresponding third application, which are stored on the external vehicle servers that differ from each other. [6] Vehicle control device according to claim 5, wherein Each of the second and third applications contains server information that includes information regarding the external vehicle server, which is downloadable, and The second application and the third application will be downloaded using the server information. [7] Vehicle control device according to claim 6, wherein the server information is downloaded and held from outside a vehicle via the communication unit. [8] Vehicle control device according to claim 1, wherein the update event is transmitted from a server side by communication. [9] Vehicle control device according to claim 1, wherein the update event is generated by an HMI actuation by a user. [10] Vehicle control device according to claim 1, wherein the update event is generated according to an operating state of software. [11] Vehicle control device according to claim 10, wherein The operating state of the software means an increase in processing time, and The update event selects and downloads the application to improve processing time.

Images