Software verification system and software verification method

Abstract

The purpose of the present invention is to improve efficiency in verifying software distributed to an on-vehicle device for controlling a vehicle using a plurality of vehicle control modes. In this software verification system, verification of operations in software distributed to an on-vehicle device for controlling a vehicle using a plurality of vehicle control modes is performed in the on-vehicle device. The software verification system comprises: a specification unit that specifies, for each vehicle control mode, verification system software including verification target software that is a target of operation verification and additional software that operates together with the verification target software during operation of the verification target software; a distribution unit that distributes the verification system software to the on-vehicle device; an execution control unit that executes verification system software corresponding to the vehicle control mode set in the on-vehicle device; and an operation verification unit that verifies the operation of the verification target software included in the executed verification system software.

Description

Software verification system and software verification method

[0001] The present invention relates to a software verification system and a software verification method.

[0002] Various software programs for implementing advanced driver-assistance systems (ADAS) or autonomous driving (AD) are implemented in on-board devices such as ECUs (Electronic Control Units) that control vehicles. This type of software is often distributed from a server device to the on-board devices via OTA (Over The Air) or the like during software updates, etc. Methods for verifying the operation of this type of software include simulation verification, in which operation is verified by a simulation before distribution, and actual vehicle verification.

[0003] In real-vehicle testing, the software to be tested is distributed to an on-board device, the vehicle is actually driven, data obtained during the driving is input into the software, the software is executed, and the output of the software is verified. For real-vehicle testing, it is desirable to prepare a large number of vehicles dedicated to software operation testing in order to cover various cases that occur in real-world environments, but there is a limit to the number of such vehicles that can be prepared. Furthermore, in real-vehicle testing, the operation testing must be performed after fully ensuring the safety of the vehicle's surroundings and the driver. Therefore, one efficient method for real-vehicle testing is to distribute the software to be tested to vehicles actually used by general users, and run the software in the background (shadow mode) so as not to affect vehicle control, thereby verifying the output of the software.

[0004] In order for an in-vehicle device to execute software to be verified in shadow mode, the in-vehicle device must have sufficient free resources to execute the software. Patent Document 1 discloses a technology for distributing software while taking into account the free resources of an in-vehicle device.

[0005] The cloud server disclosed in Patent Literature 1 distributes a requested application to an edge-equipped vehicle that satisfies distribution requirements linked to the requested application. The edge device executes the requested application distributed from the cloud server using resources of the edge-equipped vehicle and notifies the cloud server of resource information related to the usage status of resources involved in executing the requested application. The cloud server generates first compensation information to be charged to the user who provided the requested application and second compensation information to be charged to the owner of the edge-equipped vehicle, in accordance with the resource information notified from the edge device.

[0006] Japanese Patent Application Laid-Open No. 2023-117140

[0007] The software to be verified may be executed in cooperation with vehicle control software implemented in an on-board device. In an ADAS or AD, multiple vehicle control modes are prepared to enable or disable specific functions depending on the situation, and the vehicle control software running in the on-board device is changed depending on the vehicle control mode. Therefore, depending on the vehicle control mode, the vehicle control software that works with the software to be verified may not be operating properly, and the expected output may not be obtained from the vehicle control software, causing the software to not operate normally.

[0008] Patent Document 1 does not take such points into consideration at all. Therefore, even if software to be verified is distributed to an in-vehicle device using the technology of Patent Document 1, it may not be possible to actually verify the operation of the software in the in-vehicle device depending on the vehicle control mode, which may result in a decrease in the efficiency of software verification.

[0009] The present invention has been made in view of the above, and has as its object to improve the efficiency of verifying software that is distributed to an in-vehicle device that controls a vehicle using a plurality of vehicle control modes.

[0010] In order to solve the above problem, the software verification system of the present invention is a software verification system that performs operational verification of software distributed to an on-board device that controls a vehicle using multiple vehicle control modes, and is characterized by comprising: an identification unit that identifies verification system software for each vehicle control mode, the verification system software including verification target software, which is the software for which the operational verification is performed in the on-board device, and additional software that operates together with the verification target software when the verification target software is operating; a distribution unit that distributes the verification system software identified by the identification unit for each vehicle control mode to the on-board device; an execution control unit that executes the verification system software from the verification system software distributed by the distribution unit according to the vehicle control mode set in the on-board device; and an operation verification unit that performs operational verification of the verification target software included in the verification system software executed by the execution control unit.

[0011] According to the present invention, it is possible to improve the efficiency of verifying software distributed to an in-vehicle device that controls a vehicle in multiple vehicle control modes. Other problems, components, and advantages will become clear from the description of the following embodiments.

[0012] 10 is a diagram showing the configuration of a software verification system of a first embodiment. FIG. 11 is a flowchart showing the distribution processing of verification software performed by the processing device of the server device shown in FIG. 1. FIG. 2 is a diagram explaining verification item information used in step S201 of FIG. 2. FIG. 2 is a flowchart showing details of step S202 of FIG. 2. FIG. 2 is a diagram explaining dependency information and operation information used in step S202 of FIG. 2. FIG. 2 is a flowchart showing details of step S203 of FIG. 2. FIG. 2 is a flowchart showing details of step S204 of FIG. 2. FIG. 2 is a flowchart showing details of step S205 of FIG. 2. FIG. 11 is a flowchart showing the execution control processing and operation verification processing of verification software performed by the processing device of the in-vehicle device shown in FIG. 1. FIG. 12 is a diagram showing the configuration of a software verification system of a second embodiment. FIG. 13 is a flowchart showing the aggregation processing of verification software performed by the aggregation unit shown in FIG. 10. FIG. 14 is a diagram showing the configuration of a software verification system of a third embodiment.

[0013] Hereinafter, embodiments of the present invention will be described with reference to the drawings. Note that components with the same reference numerals in each embodiment have similar components in each embodiment unless otherwise specified, and description thereof will be omitted.

[0014] [First Embodiment] A first embodiment of the present invention will be described with reference to Figures 1 to 9. Figure 1 is a diagram showing the configuration of a software verification system 1 according to the first embodiment.

[0015] The software verification system 1 is a system that performs, in the in-vehicle device 105, operation verification of software that is to be distributed to the in-vehicle device 105, which controls a vehicle 104 in a plurality of vehicle control modes. The software that is distributed to the in-vehicle device 105 is not particularly limited. The software that is distributed to the in-vehicle device 105 may be various software for realizing an advanced driver assistance system or autonomous driving.

[0016] The vehicle control mode may be an automated driving mode, an advanced driving assistance mode, or a manual driving mode in which automated driving and driving assistance are not performed. The vehicle control mode may be a highway mode, a general road mode, or the like. The control method of the vehicle 104 by the in-vehicle device 105 differs depending on the vehicle control mode. Vehicle control software running on the in-vehicle device 105 differs depending on the vehicle control mode.

[0017] The software verification system 1 includes a server device 101 that is communicatively connected to an in-vehicle device 105 and stores software to be distributed to the in-vehicle device 105, and the in-vehicle device 105 that performs operational verification of the software distributed from the server device 101.

[0018] The server device 101 is a computer and includes a processing device 102 and a storage device 103. The storage device 103 is configured with storage. The storage device 103 stores software 155 to be distributed to the in-vehicle device 105. The storage device 103 also stores verification item information 151, dependency relationship information 152, operation information 153, and resource requirement information 154.

[0019] The processing device 102 includes a processor such as a CPU and memories such as a ROM and a RAM. The processing device 102 realizes various functions of the processing device 102 by the processor executing programs stored in the memory. The processing device 102 includes, as the various functions, an identification unit 121, a dependency acquisition unit 122, a running software acquisition unit 123, a required resource calculation unit 124, a free resource calculation unit 125, and a distribution unit 126.

[0020] The dependency acquisition unit 122 acquires information indicating additional software on which the software to be verified depends from dependency information 152 that indicates the dependency relationships between multiple pieces of software. The software to be verified is software for which operation verification is performed in the in-vehicle device 105. The additional software is software that operates together with the software to be verified when the software to be verified is operating. In this embodiment, the software to be verified and the additional software are collectively referred to as verification system software.

[0021] The dependency relationship information 152 is stored in advance in the storage device 103. For example, when software A is executed, other software B and C must be executed, and the dependency relationship information 152 stores information indicating that software A depends on software B and C. The dependency relationship information 152 can be realized by known technology.

[0022] The operating software acquisition unit 123 acquires information indicating the vehicle control software operating in the vehicle control mode selected by the identification unit 121 from the operation information 153, which indicates the vehicle control software operating in the in-vehicle device 105 for each vehicle control mode. The vehicle control software operating in the in-vehicle device 105 differs for each vehicle control mode and is determined in advance. The operation information 153 is stored in the storage device 103 in advance.

[0023] The free resource calculation unit 125 calculates the amount of free resources of the in-vehicle device 105 for each vehicle control mode. Even for the same vehicle 104 and in-vehicle device 105, the vehicle control software running differs depending on the vehicle control mode, and therefore the amount of free resources differs depending on the vehicle control mode. When the vehicle control software is executed in the in-vehicle device 105, the in-vehicle device 105 allocates the amount of each resource of the processor core, memory, and storage constituting the in-vehicle device 105 to be used by the vehicle control software. The amount of processor core resources refers to, for example, the computation processing time that can be allocated to the processor core for software execution. The amount of memory resources refers to, for example, the memory capacity that can be allocated to the memory for software execution. The amount of storage resources refers to, for example, the storage capacity that can be allocated to the storage for software execution. The amount of free resources indicates the amount of each resource remaining after the vehicle control software is allocated.

[0024] The required resource calculation unit 124 calculates the amount of resources required by the in-vehicle device 105 to execute the verification software for each vehicle control mode. That is, the amount of resources calculated by the required resource calculation unit 124 indicates the amount of each resource required in the in-vehicle device 105 to execute the verification software. Even for the same vehicle 104 and in-vehicle device 105, the verification software differs depending on the vehicle control mode, and therefore the amount of resources required by the verification software differs depending on the vehicle control mode. The amount of resources required by the verification software is predetermined in resource requirement information 154. The resource requirement information 154 is pre-stored in the storage device 103. The resource requirement information 154 stores the amount of resources (hereinafter also referred to as "resource requirements") required for the processor core, memory, and storage of the in-vehicle device 105 when each piece of software implemented in the in-vehicle device 105, including the verification software and vehicle control software, is executed in the in-vehicle device 105. That is, the resource requirement information 154 stores the processing time, memory capacity, and storage capacity of the processor core required to execute each piece of software implemented in the in-vehicle device 105. Note that the resource items of the processing time, memory capacity, and storage capacity of the processor core are merely examples, and the resource requirement information 154 may include other resource items.

[0025] The identification unit 121 identifies, for each vehicle control mode, software to be distributed to the in-vehicle device 105 in order to perform operation verification in the in-vehicle device 105. Specifically, the identification unit 121 identifies, for each vehicle control mode, verification system software including verification target software, which is software for which operation verification is performed in the in-vehicle device 105, and additional software, which is software that operates together with the verification target software when the verification target software is operating.

[0026] The software to be verified is predetermined in the verification item information 151. The verification item information 151 is stored in advance in the storage device 103. The additional software is predetermined in the dependency relationship information 152.

[0027] The identification unit 121 identifies the verification target software based on the verification item information 151. The identification unit 121 identifies the verification system software based on information indicating additional software on which the verification target software depends, acquired by the dependency acquisition unit 122, and information indicating the vehicle control software, acquired by the operating software acquisition unit 123. Furthermore, the identification unit 121 identifies the verification system software based on the amount of free resources of the in-vehicle device 105 calculated by the free resource calculation unit 125 and the amount of resources required by the verification system software calculated by the required resource calculation unit 124. The identification unit 121 creates a list of additional software included in the identified verification system software (hereinafter also referred to as a "verification system software list").

[0028] The distribution unit 126 distributes the verification software identified for each vehicle control mode by the identification unit 121 to the in-vehicle device 105. Specifically, the distribution unit 126 distributes the verification software for each vehicle control mode identified by the identification unit 121 and the verification software list for each vehicle control mode created by the identification unit 121 to the in-vehicle device 105. Note that if the identified verification software has already been installed as vehicle control software on the in-vehicle device 105 side, the distribution unit 126 may distribute the verification software again, or may distribute only the information on the software to be verified and the verification software list without distributing the verification software itself. If the verification software is not distributed, the in-vehicle device 105 may reference the information on the software to be verified and the verification software list and copy the software installed as vehicle control software.

[0029] The in-vehicle device 105 is a vehicle control device such as an ECU mounted on the vehicle 104 , and includes a processing device 106 and a storage device 107 .

[0030] The processing device 106 includes a processor such as a CPU and memories such as a ROM and a RAM. The processing device 106 realizes various functions of the processing device 106 by the processor executing programs stored in the memory. The processing device 106 includes an execution control unit 128 and an operation verification unit 129 as the various functions.

[0031] The execution control unit 128 executes the verification software distributed by the distribution unit 126, which corresponds to the vehicle control mode set in the in-vehicle device 105. The execution control unit 128 starts the verification software corresponding to the vehicle control mode set in the in-vehicle device 105 while the vehicle control mode is set.

[0032] The operation verification unit 129 performs operation verification of the software to be verified included in the verification system software executed by the execution control unit 128. The operation verification unit 129 can be realized using known technology. For example, the operation verification unit 129 acquires the output (including the execution result) of the software to be verified executed by the execution control unit 128 at a predetermined timing (e.g., when the software to be verified is output) and checks whether there is any problem with the output. For example, the operation verification unit 129 verifies that there is no problem with the output if a predetermined value included in the output of the software to be verified executed by the execution control unit 128 falls within a predetermined range. For example, the operation verification unit 129 verifies that there is no problem with the output if a specific event has not occurred in the output of the software to be verified executed by the execution control unit 128. A specific event is, for example, an event indicating that the execution time of the software to be verified did not end within a predetermined time.

[0033] If the operation verification unit 129 determines that there is no problem with the output of the software to be verified, it transmits a verification result indicating this to the server device 101. If the operation verification unit 129 determines that there is a problem with the output of the software to be verified, it transmits the verification result indicating this to the server device 101, as well as information including the input and output of the software to be verified at that time. This information is used to correct and improve the software to be verified.

[0034] Fig. 2 is a flowchart showing the verification software distribution process performed by the processing device 102 of the server device 101 shown in Fig. 1. Fig. 3 is a diagram for explaining the verification item information 151 used in step S201 of Fig. 2.

[0035] 2 is performed for each vehicle control mode for all vehicle control modes that can be set in the in-vehicle device 105. The process shown in Fig. 2 may be performed individually for each of the multiple vehicles 104 managed by the server device 101, or may be performed simultaneously for multiple vehicles 104 of the same model.

[0036] In step S201, the specifying unit 121 of the processing device 102 selects verification target software based on the verification item information 151. Because the software verification system 1 performs various operational verifications of software, there are multiple verification items that indicate the details of the operational verification, and there are also multiple pieces of verification target software. As shown in FIG. 3 , the verification item information 151 includes a verification item ID 301, verification target software 302, and verification priority 303. The verification item ID 301 indicates an identifier that can uniquely identify each verification. The verification target software 302 indicates the verification target software for each verification item ID 301. In the example of FIG. 3 , the verification target software 302 stores one software name, but multiple software names or software versions may also be stored. The verification priority 303 indicates the priority of verification, which is determined in advance according to a predetermined criterion, such as the release order of the verification target software.

[0037] The identification unit 121 selects the software to be verified, for example, in descending order of verification priority 303. The identification unit 121 may select the software to be verified based on information other than the verification priority 303. For example, the identification unit 121 may select the software to be verified by taking into account the verification item information 151, after adding conditions for the vehicle model or vehicle control mode at the time of each verification.

[0038] Note that step S201 is also performed again if the determination in step S205 is "NO." In this case, the identifying unit 121 selects verification target software that has not yet been selected.

[0039] In step S202, the identifying unit 121 identifies additional software that operates together with the software to be verified selected in step S201, and identifies verification system software that includes the software to be verified. Details of step S202 will be described later with reference to FIGS. 4 and 5.

[0040] In step S203, the free resource calculation unit 125 of the processing device 102 calculates the amount of free resources in the in-vehicle device 105. Details of step S203 will be described later with reference to FIG.

[0041] In step S204, the required resource calculation unit 124 of the processing device 102 calculates the amount of required resources for the verification software identified in step S202. Details of step S204 will be described later with reference to FIG.

[0042] In step S205, the identifying unit 121 determines whether the amount of available resources calculated in step S203 is greater than the amount of required resources calculated in step S204. If the amount of available resources calculated in step S203 is greater than the amount of required resources calculated in step S204, the processing device 102 proceeds to step S206. If the amount of available resources calculated in step S203 is equal to or less than the amount of required resources calculated in step S204, the processing device 102 proceeds to step S201.

[0043] In step S206, the distribution unit 126 of the processing device 102 distributes the verification software identified in step S202 to the in-vehicle device 105. Thereafter, the processing device 102 ends the processing shown in FIG.

[0044] Fig. 4 is a flowchart showing the details of step S202 in Fig. 2. The process shown in Fig. 4 is performed for each vehicle control mode for all vehicle control modes that can be set in the in-vehicle device 105. Fig. 5 is a diagram explaining the dependency relationship information 152 and operation information 153 used in step S202 in Fig. 2.

[0045] In step S411, the identification unit 121 of the processing device 102 instructs the dependency acquisition unit 122 to acquire information indicating the additional software on which the software to be verified selected in step S201 depends. In response to the instruction from the identification unit 121, the dependency acquisition unit 122 acquires information indicating the additional software on which the software to be verified depends from the dependency information 152 stored in the storage device 103, and sends the information to the identification unit 121. The information indicating the additional software on which the software to be verified depends is expressed as information indicating the dependency relationships 401 of the software to be verified, as shown in the upper part of FIG. 5 .

[0046] The dependency relationship 401 shown in FIG. 5 illustrates an example in which "verification item ID 301 = 1" is selected in step S201. The dependency relationship 401 shown in FIG. 5 indicates that software X, which is the software to be verified, depends on software A, B, and C; software A depends on software A-1, A-2, and A-3; and software C depends on software C-1. The dependency relationship 401 is not limited to additional software on which the software to be verified directly depends, but also includes additional software in an indirect dependency relationship (a relationship in which a dependency further depends on another software) as shown in FIG. 5. The dependency relationship acquisition unit 122 can easily acquire information indicating additional software that depends on the software to be verified by searching the dependency relationship information 152 stored in the storage device 103.

[0047] The dependency relationships 401 and the dependency relationship information 152 can be easily realized by known techniques. The dependency relationships 401 shown in Fig. 5 are merely an example, and may include dependency relationships that include software versions, or dependency relationships that depend on one of multiple pieces of software.

[0048] In step S412, the identifying unit 121 creates a list of additional software on which the software to be verified obtained in step S411 depends, as a verification software list. For example, in the case of the dependency relationship 401 shown in Fig. 5, the verification software list for software X, which is the software to be verified, lists software A, A-1, A-2, A-3, B, C, and C-1, which are additional software.

[0049] In step S413, the identification unit 121 instructs the operating software acquisition unit 123 to acquire information indicating the vehicle control software operating in the currently selected vehicle control mode. In response to the instruction from the identification unit 121, the operating software acquisition unit 123 acquires information indicating the vehicle control software operating in the vehicle control mode from the operation information 153 stored in the storage device 103, and sends the information to the identification unit 121. The operation information 153 is represented as a table 402 as shown in the lower part of FIG. 5 .

[0050] The table 402 shown in FIG. 5 includes a vehicle ID 403, a vehicle control mode 404, and operating software 405. The vehicle ID 403 indicates an identifier that can uniquely identify the vehicle 104. The vehicle control mode 404 indicates a vehicle control mode that can be set in the in-vehicle device 105 of the vehicle ID 403. The operating software 405 indicates software that operates in the vehicle control mode 404 of the vehicle 104 corresponding to the vehicle ID 403. In the example of FIG. 5, the operating software 405 stores one software name, but multiple software names or software versions may also be stored. The table 402 shown in FIG. 5 is an example, and the operation information 153 may be expressed in other formats. For example, the operation information 153 may be expressed in a format as the dependency relationship of operating software, similar to the dependency relationship 401. For example, the operation information 153 may be represented as a table in which the column for operating software 405 is listed as an example of software installed on the in-vehicle device 105, and a column indicating the operation status (operating or not operating) of each installed software is added.

[0051] The operating software acquisition unit 123 can easily acquire information indicating the vehicle control software operating in the currently selected vehicle 104 and vehicle control mode by searching the operation information 153 stored in the storage device 103. For example, if the operation information 153 is expressed as in table 402, the operating software acquisition unit 123 can acquire the operating software 405 by searching for the vehicle ID 403 and the vehicle control mode 404. For example, when "vehicle ID 403 = 1" and "vehicle control mode 404 = mode 1" are selected and searched, information indicating software A-2, A-3, B, C, C-1, and D is acquired as the operating vehicle control software.

[0052] In step S414, the identification unit 121 compares the information indicating the vehicle control software acquired in step S413 with the verification software list created in step S412. The identification unit 121 then deletes from the verification software list any additional software included in the verification software list created in step S412 that overlaps with the vehicle control software included in the information acquired in step S413. In the example shown in FIG. 5, software A-2, A-3, B, C, and C-1 overlap, so these are deleted from the verification software list. In step S414, the remaining additional software and the verification target software are identified as verification software to be distributed in the vehicle control mode. The identification unit 121 then terminates the processing shown in FIG. 4.

[0053] Fig. 6 is a flowchart showing the details of step S203 in Fig. 2. The process shown in Fig. 6 is performed for each vehicle control mode that can be set in the in-vehicle device 105.

[0054] In step S501, the free resource calculation unit 125 of the processing device 102 sets the total resource amount (resource amount as hardware) of the in-vehicle device 105 as the remaining resource amount.

[0055] In step S502, the free resource calculation unit 125 selects one piece of vehicle control software that operates in the currently selected vehicle control mode.

[0056] In step S503, the free resource calculation unit 125 acquires the resource requirements of the vehicle control software selected in step S502 from the resource requirement information 154 stored in the storage device 103. The free resource calculation unit 125 can easily acquire the resource requirements of the vehicle control software by searching the resource requirement information 154 for the vehicle control software.

[0057] In step S504, the free resource calculation unit 125 subtracts the resource requirement of the vehicle control software acquired in step S503 from the remaining resource amount set in step S501.

[0058] In step S505, the free resource calculation unit 125 determines whether step S504 has been calculated for all vehicle control software operating in the vehicle control mode. If step S504 has not been calculated for all vehicle control software, the free resource calculation unit 125 proceeds to step S502. If step S504 has been calculated for all vehicle control software, the free resource calculation unit 125 ends the process shown in FIG. 6.

[0059] 6 independently for each resource item, such as the processor core's processing time, memory capacity, and storage capacity. For example, if the resource item is memory capacity, the free resource calculation unit 125 sets the total memory capacity of the in-vehicle device 105 as the remaining resource amount in step S501, and subtracts the memory capacity included in the resource requirements of the vehicle control software in step S504.

[0060] Fig. 7 is a flowchart showing the details of step S204 in Fig. 2. The process shown in Fig. 7 is performed for each vehicle control mode that can be set in the in-vehicle device 105.

[0061] In step S601, the required resource calculation unit 124 of the processing device 102 sets the amount of required resources for the verification software to zero.

[0062] In step S602, the required resource calculation unit 124 selects one software item included in the verification software items identified by the identification unit 121.

[0063] In step S603, the required resource calculation unit 124 acquires the resource requirements of the software selected in step S602 from the resource requirement information 154 stored in the storage device 103. The required resource calculation unit 124 can easily acquire the resource requirements of the software by searching the resource requirement information 154 for the software.

[0064] In step S604, the required resource calculation unit 124 adds the resource requirement of the software acquired in step S603 to the required resource amount set in step S601.

[0065] In step S605, the required resource calculation unit 124 determines whether step S604 has been calculated for all software included in the verification system software. If step S604 has not been calculated for all software, the required resource calculation unit 124 proceeds to step S602. If step S604 has been calculated for all software, the required resource calculation unit 124 ends the process shown in FIG. 7.

[0066] 7 independently for each resource item, such as the processor core's processing time, memory capacity, and storage capacity. For example, if the resource item is memory capacity, the required memory capacity of the verification software is set to zero in step S601, and the memory capacity included in the resource requirements of the software is added in step S604.

[0067] Fig. 8 is a flowchart showing the details of step S205 in Fig. 2. The process shown in Fig. 8 is performed for each vehicle control mode that can be set in the in-vehicle device 105.

[0068] In step S701, the specifying unit 121 of the processing device 102 selects one resource item.

[0069] In step S702, the identifying unit 121 acquires the calculation results of the available resource amount and the required resource amount for the resource item selected in step S701 (the processing results of steps S203 and S204).

[0070] In step S703, the identifying unit 121 determines whether the amount of available resources in the resource item is greater than the amount of required resources. If the amount of available resources is greater than the amount of required resources, the identifying unit 121 proceeds to step S705. If the amount of available resources is equal to or less than the amount of required resources, the identifying unit 121 proceeds to step S704.

[0071] In step S704, the identifying unit 121 sets the determination result to "NO." This is because the verification software cannot be executed if there is a shortage of free resources in at least one resource item. Then, the identifying unit 121 ends the process shown in FIG. 8.

[0072] In step S705, the identifying unit 121 determines whether the determination in step S703 has been completed for all resource items. If the determination in step S703 has not been completed for all resource items, the identifying unit 121 proceeds to step S701. If the determination in step S703 has been completed for all resource items, the identifying unit 121 proceeds to step S706.

[0073] In step S706, the identification unit 121 sets the determination result to "YES." After that, the identification unit 121 ends the processing shown in FIG.

[0074] FIG. 9 is a flowchart showing the execution control process and operation verification process of the verification system software performed by the processing unit 106 of the in-vehicle device 105 shown in FIG.

[0075] In step S801, the execution control unit 128 of the processing device 106 waits until a change in the vehicle control mode set in the in-vehicle device 105 is detected. In principle, the execution state of the vehicle control software changes as the vehicle control mode changes. For example, general road software included in the vehicle control software is executed while the vehicle control mode is set to the general road mode. For example, automatic parking software included in the vehicle control software is executed while the vehicle control mode is set to the parking mode. In this way, since the execution state of the vehicle control software changes as the vehicle control mode changes, the execution control unit 128 waits until a change in the vehicle control mode set in the in-vehicle device 105 is detected. Detection of a change in the vehicle control mode set in the in-vehicle device 105 can be easily achieved using known technology.

[0076] In step S802, the execution control unit 128 checks the verification software that needs to be executed in each vehicle control mode before and after the change, from among the verification software for each vehicle control mode distributed by the distribution unit 126.

[0077] In step S803, the execution control unit 128 terminates the software that does not need to be executed in the changed vehicle control mode, among the multiple software included in the verification software that needs to be executed in the previous vehicle control mode, in order to avoid the execution of unnecessary software due to the limited amount of resources of the in-vehicle device 105.

[0078] In step S804, the execution control unit 128 starts the software that was not started in the previous vehicle control mode among the multiple software included in the verification software that needs to be executed in the changed vehicle control mode, thereby ensuring that the verification software that needs to be executed in the changed vehicle control mode is executed comprehensively and efficiently.

[0079] In step S805, the operation verification unit 129 of the processing device 106 checks the output of the software to be verified included in the verification system software being executed, and performs operation verification of the software to be verified. Operation verification of the software to be verified can be easily achieved using known techniques. Thereafter, the processing device 106 ends the process shown in FIG. 9.

[0080] In step S803, the execution control unit 128 may terminate all software included in the verification software that needs to be executed in the vehicle control mode before the change. Then, in step S804, the execution control unit 128 may start all software included in the verification software that needs to be executed in the vehicle control mode after the change.

[0081] As described above, the software verification system 1 of the first embodiment is a software verification system that performs, in the in-vehicle device 105, operation verification of software distributed to the in-vehicle device 105 that controls the vehicle 104 in multiple vehicle control modes. The software verification system 1 includes an identification unit 121 that identifies, for each vehicle control mode, verification software including verification target software, which is software for which operation verification is performed in the in-vehicle device 105, and additional software that operates together with the verification target software when the verification target software is operating, a distribution unit 126 that distributes the verification software identified for each vehicle control mode by the identification unit 121 to the in-vehicle device 105, an execution control unit 128 that executes, from the verification software distributed by the distribution unit 126, the verification software that corresponds to the vehicle control mode set in the in-vehicle device 105, and an operation verification unit 129 that performs operation verification of the verification target software included in the verification software executed by the execution control unit 128.

[0082] As a result, the software verification system 1 can distribute verification software including not only the software to be verified but also additional software corresponding to each vehicle control mode to the in-vehicle device 105 that controls the vehicle 104 in multiple vehicle control modes. Therefore, even if the vehicle control mode set in the in-vehicle device 105 changes, the software verification system 1 can execute the additional software corresponding to the changed vehicle control mode together with the software to be verified. As a result, the software verification system 1 can prevent a situation in which the software to be verified distributed to the in-vehicle device 105 does not operate normally due to a change in the vehicle control mode set in the in-vehicle device 105. Therefore, the software verification system 1 can improve the efficiency of verifying software distributed to the in-vehicle device 105 that controls the vehicle 104 in multiple vehicle control modes.

[0083] Furthermore, the software verification system 1 of the first embodiment further includes a dependency acquisition unit 122 that acquires information indicating additional software on which the software to be verified depends from dependency information 152 that indicates the dependency relationships between a plurality of software, and an operating software acquisition unit 123 that acquires information indicating vehicle control software that operates in the vehicle control mode selected by the identification unit 121 from operation information 153 that indicates, for each vehicle control mode, vehicle control software that operates in the in-vehicle device 105. The identification unit 121 identifies the verification system software based on the information indicating the additional software acquired by the dependency acquisition unit 122 and the information indicating the vehicle control software acquired by the operating software acquisition unit 123.

[0084] As a result, the software verification system 1 can identify the verification software according to the vehicle control mode even if the required verification software according to the vehicle control mode is not directly provided. Therefore, the software verification system 1 can reliably prevent a situation in which the software to be verified does not operate normally due to a change in the vehicle control mode. Therefore, the software verification system 1 can reliably improve the verification efficiency of software distributed to the in-vehicle device 105 that controls the vehicle 104 in multiple vehicle control modes.

[0085] Furthermore, the software verification system 1 of the first embodiment further includes a free resource calculation unit 125 that calculates the amount of free resources of the in-vehicle device 105 for each vehicle control mode, and a required resource calculation unit 124 that calculates the amount of required resources of the in-vehicle device 105 required for executing the verification software for each vehicle control mode. The identification unit 121 identifies the verification software based on the amount of free resources calculated by the free resource calculation unit 125 and the amount of required resources calculated by the required resource calculation unit 124.

[0086] As a result, even if the amount of free resources in the on-board device 105 changes depending on the vehicle control mode, the software verification system 1 can prevent a situation in which the verification software cannot be executed due to a lack of free resources. Therefore, even if the amount of free resources in the on-board device 105 changes depending on the vehicle control mode, the software verification system 1 can reliably execute the software to be verified. Therefore, the software verification system 1 can reliably improve the verification efficiency of software distributed to the on-board device 105 that controls the vehicle 104 using multiple vehicle control modes.

[0087] Furthermore, in the software verification system 1 of the first embodiment, the execution control unit 128 starts the verification software corresponding to the vehicle control mode set in the in-vehicle device 105 while the vehicle control mode is set.

[0088] This allows the software verification system 1 to reliably execute the required verification software according to the vehicle control mode, thereby reliably executing the software to be verified. Therefore, the software verification system 1 can reliably improve the efficiency of verifying software distributed to the in-vehicle device 105 that controls the vehicle 104 in multiple vehicle control modes.

[0089] Furthermore, the software verification system 1 of the first embodiment includes a server device 101 that is communicatively connected to an in-vehicle device 105 and stores software to be distributed to the in-vehicle device 105, and the in-vehicle device 105 that performs operation verification of the software distributed from the server device 101. The server device 101 includes an identification unit 121 and a distribution unit 126. The in-vehicle device 105 includes an execution control unit 128 and an operation verification unit 129.

[0090] This allows the software verification system 1 to centrally manage processes related to software distribution in the server device 101. Therefore, the software verification system 1 can efficiently manage processes related to software distribution while improving the efficiency of verifying software distributed to the in-vehicle device 105 that controls the vehicle 104 using multiple vehicle control modes.

[0091] The software verification method realized by the software verification system 1 is a software verification method for performing, in the in-vehicle device 105, operation verification of software distributed to the in-vehicle device 105 that controls a vehicle in multiple vehicle control modes. The software verification method includes an identification step (step S202) of identifying, for each vehicle control mode, verification software including verification target software, which is software for which operation verification is performed in the in-vehicle device 105, and additional software that operates together with the verification target software when the verification target software is operating, a distribution step (step S206) of distributing, to the in-vehicle device 105, the verification software identified for each vehicle control mode in the identification step, an execution control step (step S804) of executing, in the in-vehicle device 105, the verification software distributed in the distribution step that corresponds to the vehicle control mode set in the in-vehicle device 105, and an operation verification step (step S805) of verifying the operation of the verification target software included in the verification software executed in the execution control step.

[0092] As a result, the software verification method of this embodiment can prevent the software to be verified from malfunctioning due to a change in the vehicle control mode, thereby improving the efficiency of verifying software distributed to the in-vehicle device 105 that controls the vehicle 104 in multiple vehicle control modes.

[0093] Second Embodiment A second embodiment of the present invention will be described with reference to Figures 10 and 11. In the second embodiment, the description of the same components as those in the first embodiment will be omitted.

[0094] FIG. 10 is a diagram showing the configuration of a software verification system 1 according to the second embodiment.

[0095] When the in-vehicle device 105 has sufficient free resources, it may be preferable to simultaneously execute multiple pieces of software to be verified in the same in-vehicle device 105. When multiple pieces of software to be verified are simultaneously executed in the same in-vehicle device 105, the processing device 102 of the server device 101 can perform the following processing, for example.

[0096] First, the processing device 102 performs the process shown in Fig. 2 for the verification item ID 301 with the first verification priority 303. Next, when the processing device 102 confirms that the in-vehicle device 105 has sufficient free resources, it performs the process shown in Fig. 2 for the verification item ID 301 with the second verification priority 303. At this time, in step S202 shown in Fig. 2, additional software that overlaps with additional software identified as verification software last time (when the process shown in Fig. 2 was performed for the first verification item ID 301) may also be identified as verification software this time (when the process shown in Fig. 2 is performed for the second verification item ID 301). For example, if the software to be verified last time and the software to be verified this time depend on the same additional software, the additional software that overlaps with the software to be verified last time is identified in the current process.

[0097] Then, in step S203, the amount of available resources in the in-vehicle device 105 is calculated taking into account the amount of resources required for the previous execution of the verification software. In step S204, the resource requirements of the overlapping additional software are added together to calculate the amount of resources required by the verification software. If the execution of the overlapping additional software can be shared, there is no need to add up the resource requirements of the overlapping additional software in step S204, and the amount of required resources can be reduced. This makes it easier to make a "YES" determination in step S205, further improving the efficiency of software verification.

[0098] 10, the software verification system 1 of the second embodiment includes a processing device 102 that includes an aggregation unit 127 that aggregates the additional software included in each of multiple verification software programs that have different verification target software. When there is overlapping additional software among the multiple verification software programs, the aggregation unit 127 determines whether it is possible to share the execution of the overlapping additional software. Then, based on the determination result of the aggregation unit 127, the execution control unit 128 shares the execution of the overlapping additional software and executes the verification software.

[0099] Fig. 11 is a flowchart showing the verification software aggregation process performed by the aggregation unit 127 shown in Fig. 10. The process shown in Fig. 11 is performed between step S202 and step S203 shown in Fig. 2.

[0100] In step S901, the aggregating unit 127 acquires a verification software list related to the currently identified verification software.

[0101] In step S902, the aggregating unit 127 acquires a verification software list related to the verification software identified up to the last time.

[0102] In step S903, the aggregation unit 127 searches for additional software included in the verification software list acquired in step S901 that overlaps with software included in the verification software list acquired in step S902.

[0103] In step S904, the aggregation unit 127 determines whether the execution of the overlapping additional software can be standardized among multiple verification software programs. For example, based on the dependency information 152, if the overlapping additional software programs depend on the same software, the aggregation unit 127 may determine that the overlapping additional software programs are standardized because it is inferred that the applications of the overlapping additional software programs are the same. For example, the aggregation unit 127 may separately obtain input / output interface information for the overlapping additional software programs, and if the input / output interface information is the same, it may determine that the overlapping additional software programs are standardized because it is inferred that the same type of data is input and output. If the overlapping additional software programs are standardized, the aggregation unit 127 proceeds to step S905. If the overlapping additional software programs are not standardized, the aggregation unit 127 ends the processing shown in FIG. 11 .

[0104] In step S905, the aggregating unit 127 adds predetermined information to the additional software items in the verification software list related to the currently identified verification software that are determined to be duplicates and shareable. Specifically, the aggregating unit 127 adds a flag to the duplicate additional software items indicating that the additional software will be shared with other software, and adds identification information that identifies the software to be shared (software included in the verification software list obtained in step S902). Thereafter, the aggregating unit 127 ends the process shown in FIG. 11 .

[0105] Since the execution of the additional software to which the specified information has been added is shared, the required resource calculation unit 124 does not add resource requirements in step S604, which is executed within step S204. Furthermore, the verification software list to which the specified information has been added is distributed from the distribution unit 126 to the in-vehicle device 105. By checking the verification software list to which the specified information has been added, the execution control unit 128 can share the execution of additional software that has been determined to be duplicated and shareable, and appropriately control the startup and termination of the additional software.

[0106] As described above, the software verification system 1 of the second embodiment further includes an aggregation unit 127 that aggregates multiple verification software programs. When there is overlapping additional software program among the multiple verification software programs, the aggregation unit 127 determines whether it is possible to share the execution of the overlapping additional software programs. Based on the determination result of the aggregation unit 127, the execution control unit 128 shares the execution of the overlapping additional software programs and executes the verification software programs.

[0107] As a result, the software verification system 1 of the second embodiment can avoid multiple launches of duplicate additional software, thereby preventing excessive resource consumption of the in-vehicle device 105. Therefore, the software verification system 1 can reliably prevent a situation in which the verification software cannot be executed due to a lack of available resources in the in-vehicle device 105, and can reliably execute the software to be verified. Therefore, the software verification system 1 can reliably improve the efficiency of verifying software distributed to the in-vehicle device 105 that controls the vehicle 104 using multiple vehicle control modes.

[0108] Third Embodiment A third embodiment of the present invention will be described with reference to Fig. 12. In the third embodiment, the description of the same components as those in the second embodiment will be omitted.

[0109] FIG. 12 is a diagram showing the configuration of a software verification system 1 according to the third embodiment.

[0110] In the software verification system 1 of the third embodiment, the server device 101 distributes the verification software, but the in-vehicle device 105 identifies the verification software.

[0111] Specifically, the processing device 102 of the server device 101 of the third embodiment includes a distribution unit 126. The storage device 103 of the server device 101 of the third embodiment stores software 155. Meanwhile, the processing device 106 of the in-vehicle device 105 of the third embodiment includes an identification unit 121, a dependency relationship acquisition unit 122, an operating software acquisition unit 123, a required resource calculation unit 124, a free resource calculation unit 125, an aggregation unit 127, an execution control unit 128, and an operation verification unit 129. The storage device 107 of the in-vehicle device 105 of the third embodiment stores verification item information 151, dependency relationship information 152, operation information 153, and resource requirement information 154. The verification item information 151 and the dependency relationship information 152 are downloaded from the server device 101 and stored in the storage device 107. The operation information 153 and the resource requirement information 154 are originally information relating to the in-vehicle device 105 itself, and are therefore stored in the storage device 107 in advance.

[0112] Furthermore, the processing device 106 of the in-vehicle device 105 of the third embodiment includes an information sending unit 140 that sends information indicating the verification system software identified by the identifying unit 121 to the server device 101. The processing device 102 of the server device 101 of the third embodiment includes an information receiving unit 141 that receives the information sent from the information sending unit 140 and outputs the information to the distribution unit 126.

[0113] As a result, the software verification system 1 of the third embodiment can distribute the processing related to identifying verification software among the in-vehicle devices 105, thereby reducing the processing load on the server device 101. Therefore, the software verification system 1 can distribute the processing load while improving the efficiency of verifying software distributed to the in-vehicle devices 105 that control the vehicle 104 using multiple vehicle control modes.

[0114] The present invention is not limited to the above-described embodiments and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and are not necessarily limited to those including all of the described components. Furthermore, some of the components of one embodiment can be replaced with components of another embodiment, and components of another embodiment can be added to components of one embodiment. Furthermore, some of the components of each embodiment can be added, deleted, or replaced with other components.

[0115] Furthermore, the above-described components, functions, processing units, or processing means may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described components or functions may also be implemented in software, with a processor interpreting and executing a program that implements each function. Information such as the program, table, or file that implements each function can be stored in a storage device such as a memory, a hard disk, or an SSD (solid state drive), or in a storage medium such as an IC card, an SD card, or a DVD.

[0116] In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected.

[0117] 1...Software verification system, 101...Server device, 104...Vehicle, 105...In-vehicle device, 121...Identification unit, 122...Dependency acquisition unit, 123...Operating software acquisition unit, 124...Required resource calculation unit, 125...Available resource calculation unit, 126...Distribution unit, 127...Aggregation unit, 128...Execution control unit, 129...Operation verification unit, 140...Information transmission unit, 141...Information reception unit, 152...Dependency information, 153...Operation information, 154...Resource requirement information

Claims

1. A software verification system that performs operational verification of software distributed to an in-vehicle device that controls a vehicle using multiple vehicle control modes, comprising: an identification unit that identifies, for each vehicle control mode, verification software including verification target software, which is the software for which the operational verification is performed in the in-vehicle device, and additional software that operates together with the verification target software when the verification target software is operating; a distribution unit that distributes the verification software identified for each vehicle control mode by the identification unit to the in-vehicle device; an execution control unit that executes the verification software distributed by the distribution unit according to the vehicle control mode set in the in-vehicle device; and an operation verification unit that performs operational verification of the verification target software included in the verification software executed by the execution control unit.

2. The software verification system described in claim 1 further comprises a dependency acquisition unit that acquires information indicating the additional software on which the software to be verified depends from dependency information that indicates the dependency relationships between multiple pieces of software, and an operating software acquisition unit that acquires information indicating the vehicle control software that operates in the vehicle control mode selected by the identification unit from operation information that indicates the vehicle control software operating in the in-vehicle device for each vehicle control mode, wherein the identification unit identifies the verification system software based on the information indicating the additional software acquired by the dependency acquisition unit and the information indicating the vehicle control software acquired by the operating software acquisition unit.

3. The software verification system described in claim 1 further comprises: a free resource calculation unit that calculates the amount of free resources of the on-board device for each vehicle control mode; and a required resource calculation unit that calculates the amount of required resources of the on-board device required for executing the verification software for each vehicle control mode, wherein the identification unit identifies the verification software based on the amount of free resources calculated by the free resource calculation unit and the amount of required resources calculated by the required resource calculation unit.

4. The software verification system described in claim 1, characterized in that the execution control unit starts the verification system software corresponding to the vehicle control mode set in the in-vehicle device while the vehicle control mode is set.

5. The software verification system described in claim 1 further comprises an aggregation unit that aggregates multiple verification system software programs, wherein the aggregation unit determines whether or not it is possible to share the execution of the overlapping additional software programs when there is overlapping additional software programs among the multiple verification system software programs, and the execution control unit executes the verification system software programs by sharing the execution of the overlapping additional software programs based on the determination result of the aggregation unit.

6. The software verification system according to claim 1, further comprising: a server device communicatively connected to the in-vehicle device and storing the software to be distributed to the in-vehicle device; and the in-vehicle device performing the operational verification of the software distributed from the server device, wherein the server device comprises the identification unit and the distribution unit, and the in-vehicle device comprises the execution control unit and the operational verification unit.

7. The software verification system according to claim 1, comprising: a server device communicatively connected to the in-vehicle device and storing the software to be distributed to the in-vehicle device; and the in-vehicle device performing the operational verification of the software distributed from the server device, wherein the in-vehicle device comprises the identification unit, the execution control unit, the operational verification unit, and an information transmission unit that transmits information indicating the verification system software identified by the identification unit to the server device, and the server device comprises the distribution unit and an information receiving unit that receives the information transmitted from the information transmission unit and outputs it to the distribution unit.

8. A software verification method for performing operational verification of software distributed to an in-vehicle device that controls a vehicle using multiple vehicle control modes, comprising: an identification step for identifying, for each vehicle control mode, verification system software including verification target software, which is the software for which the operational verification is performed in the in-vehicle device, and additional software that operates together with the verification target software when the verification target software is operating; a distribution step for distributing the verification system software identified for each vehicle control mode by the identification step to the in-vehicle device; an execution control step for executing, in the in-vehicle device, the verification system software distributed by the distribution step that corresponds to the vehicle control mode set in the in-vehicle device; and an operation verification step for performing the operational verification of the verification target software included in the verification system software executed by the execution control step.

Images