Software information management device, software information management method, and software information management program

Abstract

This software information management device comprises: a storage unit for storing, in association with one another, vehicle-mounted device specification information for specifying a vehicle-mounted device, and software specification information for specifying software to be used in the vehicle-mounted device; an accepting unit for accepting the software specification information of target software; an acquiring unit for acquiring, from the storage unit, the vehicle-mounted device specification information corresponding to the software specification information of the target software accepted by the accepting unit; and an output unit for outputting the vehicle-mounted device specification information acquired by the acquiring unit.

Description

Software information management device, software information management method, and software information management program

[0001] This disclosure relates to a software information management device, a software information management method, and a software information management program. This application claims priority to Japanese Application No. 2024-002825, filed January 11, 2024, and incorporates by reference the entire contents of that Japanese application.

[0002] A vehicle is equipped with a variety of on-board devices, such as control system ECUs (Electronic Control Units) that control the engine, transmission, etc., body system ECUs that control headlights, power windows, etc., and information system ECUs for navigation systems, multimedia devices, etc. Each on-board device is connected to an on-board network and can communicate with each other. Various software programs run in these ECUs to realize their respective functions.

[0003] Patent Document 1 discloses an IT asset configuration management system that registers dependencies between multiple pieces of software in a database, and when attempting to change, develop, or introduce existing software in the management of IT assets, searches the database for software that has dependencies on that software, and outputs the software found as the range of software that may be affected by the change, development, or introduction of the software.

[0004] JP 2010-113392 A

[0005] A software information management device according to one aspect of the present disclosure includes a memory unit that stores in-vehicle device identification information that identifies an in-vehicle device and software identification information that identifies software used in the in-vehicle device in association with each other, a reception unit that receives software identification information for target software, an acquisition unit that acquires in-vehicle device identification information corresponding to the software identification information for the target software received by the reception unit from the memory unit, and an output unit that outputs the in-vehicle device identification information acquired by the acquisition unit.

[0006] FIG. 1 is a diagram illustrating an example of the configuration of an in-vehicle system according to an embodiment. FIG. 2 is a block diagram illustrating an example of the hardware configuration of a relay ECU according to an embodiment. FIG. 3 is a functional block diagram illustrating an example of the functions of the relay ECU according to an embodiment. FIG. 4 is a diagram illustrating an example of a correspondence table. FIG. 5 is a diagram for explaining the relationship between software components in an SBOM scenario. FIG. 6A is a diagram illustrating an example of an SBOM for software AA. FIG. 6B is a diagram illustrating an example of an SBOM for software BA. FIG. 7 is a sequence diagram illustrating an example of an SBOM introduction process performed by a relay ECU and a server. FIG. 8 is a flowchart illustrating an example of an application software update control process performed by the relay ECU. FIG. 9 is a sequence diagram illustrating an example of an information provision process performed by a relay ECU and a diagnostic device.

[0007] <Problem to be Solved by the Present Disclosure> When a vulnerability is found in software used in an ECU, it is necessary to stop using that software or update it. However, software dependencies are complex, making it difficult to find ECUs that use vulnerable software. The system disclosed in Patent Document 1 cannot identify ECUs that use vulnerable software.

[0008] <Effects of the Present Disclosure> According to the present disclosure, it is possible to identify an in-vehicle device that uses vulnerable software.

[0009] <Outline of Embodiments of the Present Disclosure> Below, an outline of embodiments of the present disclosure will be listed and described.

[0010] (1) A software information management device according to this embodiment includes a storage unit that stores in-vehicle device identification information that identifies an in-vehicle device and software identification information that identifies software used in the in-vehicle device in association with each other, a reception unit that receives software identification information for target software, an acquisition unit that acquires from the storage unit in-vehicle device identification information corresponding to the software identification information for the target software received by the reception unit, and an output unit that outputs the in-vehicle device identification information acquired by the acquisition unit. Thus, by inputting the software identification information for vulnerable target software into the software information management device, the in-vehicle device identification information for in-vehicle devices that use the vulnerable software can be output. Therefore, it is possible to identify in-vehicle devices that use vulnerable software.

[0011] (2) In the above (1), the storage unit may store the in-vehicle device identification information and software identification information of lower-level software used in the upper-level software installed in the in-vehicle device in association with each other, and the target software may be the lower-level software. In this way, when a vulnerability is found in the lower-level software, which is a library of the upper-level software, it is possible to identify the in-vehicle device that uses the lower-level software.

[0012] (3) In the above (2), the storage unit may store the in-vehicle device identification information, first software identification information that identifies the higher-level software installed in the in-vehicle device, and second software identification information that identifies the lower-level software used in the higher-level software, in association with each other, the acquisition unit may further acquire the first software identification information corresponding to the second software identification information of the target software accepted by the acceptance unit, and the output unit may further output the first software identification information acquired by the acquisition unit. This makes it possible to identify not only in-vehicle devices that use vulnerable lower-level software, but also higher-level software that uses the lower-level software.

[0013] (4) In the above (2) or (3), the storage unit may store dependency information including the second software identification information that identifies the lower-level software used in the upper level software, the storage unit may store the in-vehicle device identification information, the first software identification information, and the dependency information in association with each other, and the acquisition unit may identify the dependency information including the second software identification information received by the acceptance unit and acquire the in-vehicle device identification information corresponding to the identified dependency information. In this way, by identifying the dependency information including the second software identification information of the vulnerable lower-level software, it is possible to identify the in-vehicle device corresponding to the dependency information as an in-vehicle device that uses the vulnerable lower-level software.

[0014] (5) In the above (4), the software information management device may further include an update data acquisition unit that acquires update data for updating the host software, and an update control unit that controls updating of the host software based on the update data acquired by the update data acquisition unit, and the update data acquisition unit may acquire new dependency information corresponding to the updated host software together with the update data. In this way, when the host software is updated, the dependency information can be updated to correspond to the updated host software.

[0015] (6) In any one of (1) to (5) above, the software identification information may include software name and version information, thereby enabling software to be identified by the software name and version information.

[0016] (7) In any one of (1) to (6) above, the in-vehicle device identification information may include a product number of the in-vehicle device, thereby enabling the in-vehicle device to be identified by the product number.

[0017] (8) In any one of (1) to (7) above, the software information management device may be mounted on a vehicle, thereby making it possible to identify an in-vehicle device in the vehicle that uses vulnerable software.

[0018] (9) In the above (8), the software information management device may be a relay device that relays communications between a plurality of on-board devices, thereby enabling the relay device on the communication path between the plurality of on-board devices to identify on-board devices that use vulnerable software.

[0019] (10) A software information management method according to this embodiment includes the steps of: receiving software identification information for target software; acquiring in-vehicle device identification information corresponding to the received software identification information for the target software from a storage unit that stores in-vehicle device identification information that identifies an in-vehicle device and software identification information that identifies software used in the in-vehicle device in association with each other; and outputting the acquired in-vehicle device identification information. Thus, by inputting the software identification information for vulnerable target software into a software information management device, the in-vehicle device identification information for in-vehicle devices that use the target software can be output. Therefore, it is possible to identify in-vehicle devices that use vulnerable software.

[0020] (11) A software information management program according to this embodiment causes a computer to execute the following steps: receiving software identification information for target software; acquiring in-vehicle device identification information corresponding to the received software identification information for the target software from a storage unit that stores in-vehicle device identification information that identifies an in-vehicle device and software identification information that identifies software used in the in-vehicle device in association with each other; and outputting the acquired in-vehicle device identification information. Thus, by inputting the software identification information for vulnerable target software into the software information management device, the in-vehicle device identification information for in-vehicle devices that use the target software can be output. Therefore, in-vehicle devices that use vulnerable software can be identified.

[0021] The present disclosure can be realized not only as a software information management device having the above-described characteristic configuration, a software information management method including characteristic steps, and a software information management program for causing a software information management device to execute characteristic processing, but also as a system including the software information management device, or as a semiconductor integrated circuit in which part or all of the software information management device is implemented.

[0022] <Details of Embodiments of the Present Disclosure> Hereinafter, details of embodiments of the present disclosure will be described with reference to the drawings. Note that at least some of the embodiments described below may be combined in any manner.

[0023] 1. In-Vehicle System FIG. 1 is a diagram showing an example of the configuration of an in-vehicle system according to an embodiment.

[0024] The vehicle is equipped with an in-vehicle network 100. The in-vehicle network 100 according to the embodiment is a Controller Area Network (CAN) network capable of communication via a CAN. The in-vehicle network 100 includes buses 400A, 400B, and 400C, which are CAN buses.

[0025] The in-vehicle system 10 includes a relay ECU 200 and ECUs 300A, 300B, 300C, 300D, and 300E.

[0026] Multiple ECUs 300A, 300B, 300C, 300D, and 300E are disposed in various parts of the vehicle. The ECUs 300A, 300B, 300C, 300D, and 300E individually control the hardware of each part of the vehicle and monitor the status of the hardware of each part of the vehicle. For example, the ECUs 300A, 300B, 300C, 300D, and 300E are ECUs for a control system, a body system, and an information system. In the following description, the ECUs 300A, 300B, 300C, and 300D are also collectively referred to as "ECU 300."

[0027] The relay ECU 200 is connected to ECUs 300A, 300B, 300C, 300D, and 300E, respectively, via buses 400A, 400B, and 400C. Specifically, ECUs 300A and 300B are connected to bus 400A. ECUs 300C and 300D are connected to bus 400B. ECU 300E is connected to bus 400C. The relay ECU 200 can communicate with each of ECUs 300A, 300B, 300C, 300D, and 300E. The relay ECU 200 and ECUs 300A, 300B, 300C, 300D, and 300E are examples of "on-vehicle devices."

[0028] The relay ECU 200 and the ECU 300 use a communication protocol for periodically or aperiodically transmitting and receiving messages. The communication protocol is, for example, CAN or CAN FD (CAN with Flexible Data Rate). In another example, the communication protocol is Ethernet (registered trademark). When the Ethernet protocol is used, the in-vehicle network becomes an Ethernet network having a star-shaped network topology.

[0029] The relay ECU 200 functions as a gateway that relays communications between multiple ECUs 300. Specifically, the relay ECU 200 relays communications (frames) between buses 400A, 400B, and 400C. The ECUs 300 can transmit frames. The frames are messages that comply with the above-mentioned communication protocol. The relay ECU 200 relays frames between ECUs connected to different buses. For example, the relay ECU 200 can relay frames between the ECU 300A connected to bus 400A and the ECU 300C connected to bus 400B.

[0030] The relay ECU 200 is connected to an external communication device 350 via a bus 400C. The external communication device 350 is, for example, a TCU (Telematics Control Unit) and can communicate with devices outside the vehicle. The external communication device 350 has a wireless communication interface for a mobile communication system, such as a fifth-generation mobile communication system (5G) or a fourth-generation mobile communication system (4G). The external communication device 350 can transmit and receive packets of, for example, TCP / IP (Transmission Control Protocol / Internet Protocol). The external communication device 350 is logically connected to a base station (not shown) of a mobile communication network and can communicate with devices connected to the Internet via the base station. Specifically, the external communication device 350 can communicate with a server 500. The external communication device 350 relays communication between the relay ECU 200 and the server 500. The server 500 and the relay ECU 200 constitute a software information management system.

[0031] A connector 410 is connected to the bus 400C. The connector 410 is, for example, a connector conforming to OBD1 (On-board Diagnostics first generation) or OBD2 (On-board Diagnostics second generation). A diagnostic device 370 for diagnosing the vehicle can be connected to the connector 410. The diagnostic device 370 can communicate with the relay ECU 200 and the ECU 300 using the above-mentioned communication protocol. For example, the diagnostic device 370 can collect, from the relay ECU 200 and the ECU 300, information on abnormalities or warnings previously detected by the ECU 300.

[0032] The diagnostic device 370 according to the embodiment can request (query) information about software (hereinafter also referred to as "SW") used in the ECUs from the relay ECU 200. The relay ECU 200 can respond to the query and transmit (output) information about the software to the diagnostic device 370. In a specific example, the diagnostic device 370 can query the relay ECU 200 for information about ECUs that use specific software. The relay ECU 200 searches for ECUs 300 that use the software that is the subject of the query and transmits the search results to the diagnostic device 370. The diagnostic device 370 displays the received search results.

[0033] 2. Hardware Configuration of Relay ECU Fig. 2 is a block diagram showing an example of the hardware configuration of the relay ECU according to the embodiment. Relay ECU 200 includes a processor 201, a nonvolatile memory 202, a volatile memory 203, and communication interfaces (hereinafter also referred to as "communication I / F") 204A, 204B, and 204C. Processor 201, nonvolatile memory 202, volatile memory 203, and communication I / F 204 are connected to one another by a bus 205, which is a communication line. Processor 201, nonvolatile memory 202, volatile memory 203, and communication I / F 204 can transmit data to one another via bus 205. Relay ECU 200 is an example of a "relay device."

[0034] The volatile memory 203 is a semiconductor memory such as a static random access memory (SRAM) or a dynamic random access memory (DRAM). The non-volatile memory 202 is a flash memory, a hard disk, a read-only memory (ROM), or the like. The non-volatile memory 202 stores an update control program 210 and a SW information management program 220, which are computer programs, as well as data used to execute these programs 210 and 220. The functions of the relay ECU 200, which will be described later, are realized when the processor 201 executes the update control program 210 and the SW information management program 220.

[0035] The processor 201 is, for example, a CPU (Central Processing Unit). However, the processor 201 is not limited to a CPU. The processor 201 may also be a GPU (Graphics Processing Unit). In a specific example, the processor 201 is a multi-core processor. The processor 201 may also be a single-core processor. The processor 201 is configured to be able to execute a computer program. However, the processor 201 may also be, for example, an ASIC (Application Specific Integrated Circuit) or a programmable logic device such as an FPGA (Field Programmable Gate Array). In this case, the ASIC or programmable logic device is configured to be able to execute the same functions as the update control program 210 and the SW information management program 220.

[0036] The communication I / Fs 204A, 204B, and 204C are communication interfaces that comply with the above-described communication protocol for the in-vehicle network. That is, the communication I / Fs 204A, 204B, and 204C are, for example, CAN interfaces. In another example, the communication I / Fs 204A, 204B, and 204C are Ethernet interfaces.

[0037] Communication I / F 204A is connected to bus 400A. Communication I / F 204B is connected to bus 400B. Communication I / F 204C is connected to bus 400C. Relay ECU 200 can communicate with ECUs 300A and 300B via communication I / F 204A. Relay ECU 200 can communicate with ECUs 300C and 300D via communication I / F 204B. Relay ECU 200 can communicate with ECU 300E via communication I / F 204C. Furthermore, relay ECU 200 can communicate with diagnostic device 370 via communication I / F 204C, and can communicate with server 500 via external communication device 350.

[0038] Non-volatile memory 202 stores correspondence table 230 and software bills of materials (SBOMs) 231AA, 231BA, 231AB, 231AC, 231BC, 231AD, and 231AE used to search for ECUs 300 that use the software being queried. In the following description, SBOMs 231AA, 231BA, 231AB, 231AC, 231BC, 231AD, and 231AE are also collectively referred to as "SBOM 231."

[0039] [3. Software Dependency Relationship] Each ECU 300 is equipped with application software. The application software is a program for individually controlling the hardware of each part of the vehicle and monitoring the status of the hardware of each part of the vehicle. The application software equipped in the ECU 300 uses one or more pieces of software as libraries. In other words, there is a dependency relationship between the software equipped in the ECU 300.

[0040] The software dependencies in each ECU 300 will be described using the example of FIG.

[0041] ECU 300A is equipped with application software AA. AA uses software BA and DA as libraries. BA uses software CA as a library. In other words, AA is upper-level software, and BA and DA are lower-level software. CA is lower-level software of BA and also lower-level software of AA.

[0042] ECU 300B is equipped with application software AB. AB uses software BB and DB as libraries. That is, AB is upper-level software, and BB and DB are lower-level software.

[0043] ECU 300C is equipped with application software AC. AC uses software BC as a library. BC uses software CA as a library. In other words, AC is higher-level software, and BC is lower-level software. CA is lower-level software of BC and also lower-level software of AC.

[0044] The ECU 300D is equipped with application software AD. The AD uses software BD, DD, and ED as libraries. That is, the AD is upper-level software, and the BD, DD, and ED are lower-level software.

[0045] The ECU 300E is equipped with application software AE, which uses software BE and CA as libraries. That is, AE is upper-level software, and BE and CA are lower-level software.

[0046] 4. Functions of the Relay ECU FIG. 3 is a functional block diagram showing an example of functions of the relay ECU according to the embodiment.

[0047] The relay ECU 200 is an example of a "software information management device." When the processor 201 of the relay ECU 200 executes the update control program 210, the functions of an update data acquisition unit 211 and an update control unit 212 are realized. When the processor 201 executes the SW information management program 220, the functions of a reception unit 221, an acquisition unit 222, and an output unit 223 are realized.

[0048] For example, if a vulnerability is found in a certain piece of software, an inquiry about ECUs that use the software is sent to relay ECU 200. Reception unit 221 receives information (hereinafter also referred to as "software identification information" or "SW identification information") that identifies the software that is the subject of the inquiry (hereinafter also referred to as "target software" or "target SW"). For example, when a user inquires about information about ECU 300 that uses the target SW, the user inputs an inquiry including the SW identification information (hereinafter also referred to as "SW usage inquiry") to diagnostic device 370. Diagnostic device 370 transmits the input SW identification information to relay ECU 200. Reception unit 221 receives the SW identification information by receiving it.

[0049] The acquisition unit 222 acquires information (hereinafter also referred to as "ECU identification information") that identifies an ECU corresponding to the SW identification information of the target SW received by the reception unit 221. The ECU identification information is an example of "vehicle device identification information." The acquisition unit 222 acquires the ECU identification information from the nonvolatile memory 202. The nonvolatile memory 202 is an example of a "storage unit." In a specific example, the acquisition unit 222 uses the correspondence table 230 and the SBOM 231 to acquire the ECU identification information that corresponds to the SW identification information of the target SW.

[0050] Here, a description will be given of the correspondence table 230 and the SBOM 231. Fig. 4 is a diagram showing a specific example of the correspondence table.

[0051] The correspondence table 230 stores the correspondence between ECU identification information and SW identification information (first software identification information). An example of ECU identification information is the product number of the ECU 300. However, the ECU identification information is not limited to this and may also be the name, identification information, model number, etc. of the ECU 300. The product number (serial number) is a number assigned when the ECU 300 is manufactured, and is composed of a lot number indicating the production base, etc., and a serial number at the time of manufacture, etc., and is a unique number that can uniquely identify the ECU. The model number is a number that identifies the type of on-vehicle ECU 300, such as a part number. The SW identification information is a combination of software name and version information. In the example of FIG. 4, "software name @ version" is the SW identification information. However, the SW identification information is not limited to this and may be only the software name, or software identification information.

[0052] For example, the ECU identification information of ECU 300A is "XY35125." The SW name of application software installed in ECU 300A is "AA," and the version is "2.3." The SW identification information of software AA is "AA@2.3."

[0053] The ECU identification information of ECU 300B is "FD143." The SW name of application software installed in ECU 300B is "AB," and the version is "1.1." The SW identification information of software AB is "AB@1.1."

[0054] The ECU identification information of ECU 300C is "YA54F." The SW name of application software installed in ECU 300C is "AC," and the version is "2.0." The SW identification information of software AC is "AC@2.0."

[0055] The ECU identification information of ECU 300D is “CC9624.” The SW name of application software installed in ECU 300D is “AD,” and the version is “5.1.2.” The SW identification information of software AD is “AD@5.1.2.”

[0056] The ECU identification information of ECU 300E is "SGI565X." The SW name of application software installed in ECU 300E is "AE," and the version is "3.2." The SW identification information of software AC is "AE@3.2."

[0057] Correspondence table 230 further stores location information of SBOM 231. In a specific example, SBOM 231 is a single file, and correspondence table 230 stores the file name of SBOM 231. SBOM is a machine-processable list that includes information on software components and their dependencies, and is also called a "software bill of materials." SBOM 231 includes SW specification information (second software specification information) that specifies lower-level software used in higher-level software. In other words, SBOM 231 is an example of "dependency information."

[0058] There are various formats for SBOM. In this embodiment, SBOM 231 is an SBOM in SWID (Software Identification) tag format and is a file in XML (Extensible Markup Language) format. However, the SBOM is not limited to this and does not have to be in the SWID tag format.

[0059] The SBOM includes information such as the names of components included in the software, version information, developer of the components, etc. Here, an example of the SBOM will be described along one scenario.

[0060] 5 is a diagram illustrating the relationship between software components in an SBOM scenario. In this scenario, it is assumed that company A has developed software AA to be installed in ECU 300A using software components BA and DA. BA was developed by company B using software component CA by Mr. C. DA was developed by community D.

[0061] As shown in Figure 5, AA is version 2.3 and is the highest level software using the software components BA, CA, and DA. BA is version 1.4 and is used in AA. CA is version 4.0 and is used in BA. DA is version 3.1 and is used in AA.

[0062] 6A is a diagram showing an example of an SBOM for software AA. SBOM 231AA includes the name of the software targeted by SBOM 231AA, "AA," version information "2.3," and the name of AA's supplier, "Company A." In particular, SBOM 231AA includes "AA@2.3," which is software specific information for AA (tagId). SBOM 231AA also includes "BA@1.4" and "DA@3.1," which are software specific information for software components BA and DA used in AA (SWID). The "BA@1.4" and "DA@3.1" software specific information for software components BA and DA, which are libraries, are enclosed within the dashed lines.

[0063] In this example, there is an SBOM 231BA for software BA that uses software CA. Figure 6B is a diagram showing an example of an SBOM for software BA. SBOM 231BA includes the name of the software targeted by SBOM 231BA, "BA," version information "1.4," the name of the BA's supplier, "Company B," and so on. In particular, SBOM 231BA includes "BA@1.4," which is the software specific information for BA (tagId). SBOM 231BA also includes "CA@4.0," which is the software specific information for software component CA used in BA (SWID). The "CA@4.0" software specific information for software component CA, which is a library, is enclosed by a dashed line.

[0064] Returning to FIG. 4 , correspondence table 230 stores, as location information for SBOM 231, the file names of SBOM 231 for software used in ECU 300, in association with the ECU identification information of that ECU 300. That is, SBOM file names "AA_sbom.xml" and "BA_sbom.xml" correspond to ECU identification information "XY35125." SBOM file name "AB_sbom.xml" corresponds to ECU identification information "FD143." SBOM file names "AC_sbom.xml" and "BC_sbom.xml" correspond to ECU identification information "YD54F." SBOM file name "AD_sbom.xml" corresponds to ECU identification information "CC9624." The SBOM file name "AE_sbom.xml" corresponds to the ECU specific information "SGI565X."

[0065] The acquisition unit 222 refers to each SBOM 231 and searches for the SW identification information of the target SW as the SW identification information of the SW being used (i.e., as the SWID in the above example). For example, if a vulnerability is discovered in version 4.0 of the software CA, the user inputs the SW identification information of the CA, "CA@4.0," as the target of the SW usage inquiry in order to identify the ECU 300 that uses the software CA. The acquisition unit 222 searches each SBOM 231 using the SW identification information "CA@4.0" as a search key and identifies that "CA@4.0" exists in the SWID of the SBOM 231BA.

[0066] Furthermore, from SBOM 231BA in which "CA@4.0" was searched, acquisition unit 222 acquires SW specification information "BA@1.4" of the software BA targeted by SBOM 231BA. Acquisition unit 222 references correspondence table 230 and acquires ECU specification information "XY35125" corresponding to file name "BA_sbom.xml" of SBOM 231BA, which was found in the search for SW specification information "CA@4.0." Acquisition unit 222 checks whether an SBOM other than SBOM 231BA corresponding to ECU specification information "XY35125" exists, and identifies the existence of SBOM 231AA (file name "AA_sbom.xml").

[0067] The acquisition unit 222 references the SBOM 231AA and performs a string search using the SW specification information "BA@1.4" of the BA that uses the target SW "CA@4.0" as a search key. The acquisition unit 222 determines that "BA@1.4" exists in the SWID of the SBOM 231AA. Furthermore, the acquisition unit 222 obtains the SW specification information "AA@2.3" of the target software AA of the SBOM 231AA from the SBOM 231AA in which "BA@1.4" was searched. This determines that AA uses BA, and that BA uses CA, which is the target SW.

[0068] The acquisition unit 222 refers to the correspondence table 230 and acquires the ECU specific information "XY35125" corresponding to the file name "AA_sbom.xml" of the SBOM 231AA that was found in the search for the SW specific information "BA@1.4."

[0069] As described above, the acquisition unit 222 acquires the ECU identification information "XY35125" of the ECU 300A that uses the target SW "CA@4.0" and the SW identification information "AA@2.3" of the software AA.

[0070] The acquisition unit 222 searches for other SBOMs 231 in the same manner as described above, and acquires the ECU specific information "YA54F" of ECU 300C that uses the target SW "CA@4.0" and the SW specific information "AC@2.0" of software AC, and acquires the ECU specific information "SGI565X" of ECU 300E that uses the target SW "CA@4.0" and the SW specific information "AE@3.2" of software AE.

[0071] 4 , the output unit 223 outputs the ECU identification information of the ECU 300 that uses the target SW and the SW identification information of the software that uses the target SW, which are acquired by the acquisition unit. However, the output unit 223 only needs to output the ECU identification information of the ECU 300 that uses the target SW, and does not necessarily output the SW identification information of the software that uses the target SW.

[0072] In a specific example, the output unit 223 transmits the ECU identification information of the ECU 300 that uses the target SW and the SW identification information of the software that uses the target SW, which are acquired by the acquisition unit. That is, the output unit 223 transmits the ECU identification information of the ECU 300 that uses the target SW and the SW identification information of the software that uses the target SW, as query results, to the query source diagnostic device 370. The diagnostic device 370 can display the received ECU identification information and SW identification information.

[0073] The update data acquisition unit 211 acquires update data for updating application software, which is higher-level software. For example, when updating software AA in Fig. 1, the update data acquisition unit 211 acquires update data for AA. The update data includes, for example, the code of the updated application program.

[0074] For example, the server 500 manages updates of application software for the ECU 300. When update data for the application software of each target vehicle is newly stored in the storage unit of the server 500, the server 500 provides (downloads) the update data to the relay ECU 200 of the vehicle equipped with the ECU 300 on which the application software is installed. The update data acquisition unit 211 acquires the update data by downloading the update data from the server 500.

[0075] For example, the server 500 manages, for each vehicle, application software installed in an ECU mounted in the vehicle. That is, the server 500 stores vehicle identification information (hereinafter also referred to as "vehicle ID") and identification information (or SW specification information) of application software installed in the ECU mounted in the vehicle, in association with each other. The update data acquisition unit 211 transmits the vehicle ID of the vehicle in which the relay ECU 200 is mounted to the server 500, for example, periodically or in response to a request from the server 500. Upon receiving the vehicle ID, the server 500 identifies the application software corresponding to the vehicle ID and determines whether update data exists. If update data exists, the server 500 transmits the update data to the relay ECU 200 that transmitted the vehicle ID.

[0076] The update control unit 212 controls the update of the application software of the target ECU 300 based on the update data received from the server 500. Specifically, the update control unit 212 transmits the received update data to the ECU 300 to be updated, and instructs the ECU 300 to update the application software. In response to the update instruction, the ECU 300 updates the application software using the received update data.

[0077] When an application program is updated, SBOM 231 of that application program is also updated. Therefore, server 500 stores a new (updated) SBOM (hereinafter also referred to as a "new SBOM") together with the update data. Server 500 transmits the update data and also transmits the new SBOM to relay ECU 200. Update data acquisition unit 211 receives the new SBOM corresponding to the updated application software together with the update data.

[0078] Update control unit 212 updates SBOM 231 with the new SBOM. Specifically, update control unit 212 rewrites existing SBOM 231 with the new SBOM.

[0079] 5. Operation of Relay ECU Next, the operation of relay ECU 200 according to the embodiment will be described. First, in a new, unused (unsold) vehicle, SBOM 231 is not installed in relay ECU 200. Therefore, SBOM 231 is installed in relay ECU 200 of the vehicle. Server 500 stores SBOM 231 in association with the vehicle ID as part of information about application programs used in the vehicle.

[0080] 7 is a sequence diagram showing an example of the SBOM introduction process performed by the relay ECU and the server. The server 500 transmits a request for a vehicle ID, for example, by broadcast (step S101). Upon receiving the request, the processor 201 of the relay ECU 200 installed in the new vehicle transmits the vehicle ID of the new vehicle to the server 500 (step S102).

[0081] Server 500 transmits SBOM 231 corresponding to the received vehicle ID (step S103). All SBOMs are divided into multiple frames for transmission. Hereinafter, the divided SBOM frames are also referred to as "SBOM data."

[0082] The processor 201 writes all of the received SBOM data to the non-volatile memory 202. When the writing is complete, the processor 201 transmits a write completion notification to the server 500. This completes the SBOM installation process.

[0083] Next, the update control process of the application software will be described with reference to a flowchart of FIG.

[0084] As described above, when new update data for an application program is stored in server 500 , server 500 transmits the update data or a new SBOM to relay ECU 200 .

[0085] When processor 201 of relay ECU 200 receives data transmitted from server 500 (step S201), it determines whether the received data is SBOM data (step S202). If the received data is not SBOM data, i.e., if the received data is update data (NO in step S202), processor 201 transfers the received data to ECU 300 to be updated (step S203). After the data transfer, processor 201 returns to step S201.

[0086] If the received data is SBOM data (YES in step S202), processor 201 temporarily stores the received SBOM data in a buffer area provided in volatile memory 203 (step S204). Processor 201 determines whether SBOM 231 is complete (step S205). If SBOM 231 is not complete (NO in step S205), processor 201 returns to step S201.

[0087] When SBOM 231 is completed (YES in step S205), processor 201 determines whether or not a notification of completion of the update process has been received from ECU 300 to be updated (step S206). ECU 300 to be updated executes the update process of the application software using the update data, and when the update process is completed, that is, when the update is successful or unsuccessful, notifies relay ECU 200 of the completion of the update process.

[0088] If the update process has not ended, that is, if the update process end notification has not been received (NO in step S206), the processor 201 executes step S206 again.

[0089] When the update process is completed, that is, when an update process completion notification is received (YES in step S206), the processor 201 determines whether the update was successful (step S207). The update process completion notification includes information indicating whether the update was successful or unsuccessful. The processor 201 can determine whether the update was successful by referring to the update process completion notification.

[0090] If the update is successful (YES in step S207), processor 201 reads new SBOM 231, which is formed by combining the SBOM data, from the buffer, and rewrites SBOM 231 stored in non-volatile memory 202 with new SBOM 231 (step S208). If the update is unsuccessful (NO in step S207), processor 201 discards SBOM 231 stored in the buffer (step S209). This completes the application software update control process.

[0091] Next, an information providing process will be described in which ECUs 300 using target SWs are searched for and the search results are provided to the user in response to an inquiry from diagnostic device 370. Fig. 9 is a sequence diagram showing an example of the information providing process performed by the relay ECU and the diagnostic device.

[0092] When a vulnerability is found in a certain piece of software, the user connects diagnostic device 370 to connector 410 and inputs a SW usage inquiry including SW identification information for the software to diagnostic device 370. Diagnostic device 370 transmits the input SW usage inquiry to relay ECU 200. Processor 201 of relay ECU 200 receives the SW usage inquiry (step S301).

[0093] Processor 201 uses the SW identification information of the target SW specified in the SW usage inquiry as a search key to perform a character string search in SBOM 231. When the search for SW identification information is found in SBOM 231, processor 201 obtains, from correspondence table 230, ECU identification information of ECU 300 and SW identification information of application software corresponding to SBOM 231 (step S302).

[0094] Processor 201 transmits the search result including the searched ECU-specific information and SW-specific information to diagnostic device 370. Diagnostic device 370 receives the search result (step S303).

[0095] The diagnostic device 370 displays the search results, that is, the ECU identification information of the ECU 300 that uses the target SW and the SW identification information of the application software that uses the target SW (step S304). This completes the information provision process.

[0096] [6. Modifications] In the above-described embodiment, the SBOM 231 is used as dependency information, but the present invention is not limited to this. The dependency information does not have to be an SBOM as long as it includes at least information for identifying software used in the application software.

[0097] In the above-described embodiment, the relay ECU 200 transmits ECU identification information of the ECU 300 using the queried software and SW identification information of the application software to the diagnostic device 370 in response to a query from the diagnostic device 370. However, the present invention is not limited to this. For example, a SW usage query including input SW identification information may be transmitted to the relay ECU 200 from a terminal (e.g., a smartphone) outside the vehicle, and the relay ECU 200 may transmit the ECU identification information of the ECU 300 using the queried software and the SW identification information of the application software to the terminal. The terminal may display the received ECU identification information and SW identification information. As another example, an ECU 300 connected to an in-vehicle display may transmit a SW usage query including input SW identification information to the relay ECU 200, and the relay ECU 200 may transmit the ECU identification information of the ECU 300 using the queried software and the SW identification information of the application software to the ECU 300. The ECU 300 may display the received ECU identification information and SW identification information on the display. As yet another example, a device inside or outside the vehicle may transmit a SW usage inquiry including SW identification information to the relay ECU 200, and the relay ECU 200 may transmit the ECU identification information of the ECU 300 that uses the software being queried and the SW identification information of the application software to the device. The device may use the received ECU identification information and SW identification information for information processing such as vehicle diagnostic processing, without displaying them.

[0098] In the above-described embodiment, the relay ECU 200 acquires the ECU identification information of the ECU 300 that uses the software that is the subject of the query and the SW identification information of the application software, but this is not limiting. For example, an ECU 300 that does not have a frame relay function may acquire (search) the ECU identification information of the ECU 300 that uses the software that is the subject of the query and the SW identification information of the application software.

[0099] In the above-described embodiment, SBOM 231 is identified by a file name, but this is not limiting. For example, in the case of an OS that does not employ a file system, the storage location of each SBOM 231 in nonvolatile memory 202 (for example, the start address of the storage location and the data size) may be stored in a correspondence table, and SBOM 231 may be identified by its storage location in nonvolatile memory 202.

[0100] [7. Supplementary Note] The embodiments disclosed herein are illustrative in all respects and are not restrictive. The scope of the present disclosure is defined by the claims, not the above-described embodiments, and includes meanings equivalent to the claims and all modifications within the scope thereof.

[0101] 10 In-vehicle system 100 In-vehicle network 200 Relay ECU (relay device, software information management device) 201 Processor 202 Non-volatile memory 203 Volatile memory 204A, 204B, 204C Communication interface (communication I / F) 205 Bus 210 Update control program 211 Update data acquisition unit 212 Update control unit 220 Information management program 221 Reception unit 222 Acquisition unit 223 Output unit 230 Correspondence table 231 SBOM 300 ECU (in-vehicle device) 350 External communication device 370 Diagnostic device 400A, 400B, 400C Bus 410 Connector 500 Server

Claims

1. A software information management device, comprising: a storage unit that stores in association an in-vehicle device identification information for identifying an in-vehicle device and a software identification information for identifying software used in the in-vehicle device; a reception unit that receives the software identification information of target software; an acquisition unit that acquires from the storage unit the in-vehicle device identification information corresponding to the software identification information of the target software received by the reception unit; and an output unit that outputs the in-vehicle device identification information acquired by the acquisition unit.

2. The software information management device according to claim 1, wherein the storage unit stores in association the in-vehicle device identification information and the software identification information of lower-level software used in upper-level software mounted on the in-vehicle device, and the target software is the lower-level software.

3. The software information management device according to claim 2, wherein the storage unit stores in association the in-vehicle device identification information, first software identification information for identifying the upper-level software mounted on the in-vehicle device, and second software identification information for identifying the lower-level software used in the upper-level software; the acquisition unit further acquires the first software identification information corresponding to the second software identification information of the target software received by the reception unit; and the output unit further outputs the first software identification information acquired by the acquisition unit.

4. The software information management device according to claim 2 or claim 3, wherein the storage unit stores dependency relationship information including the second software identification information for identifying the lower-level software used in the upper-level software, the storage unit stores in association the in-vehicle device identification information, the first software identification information, and the dependency relationship information, and the acquisition unit identifies the dependency relationship information including the second software identification information received by the reception unit and acquires the in-vehicle device identification information corresponding to the identified dependency relationship information.

5. An update data acquisition unit that acquires update data for updating the upper software, and an update control unit that controls the update of the upper software based on the update data acquired by the update data acquisition unit, further comprising: the update data acquisition unit acquires new dependency relationship information corresponding to the upper software after the update together with the update data. The software information management device according to claim 4.

6. The software identification information includes a software name and version information. The software information management device according to any one of claims 1 to 5.

7. The in-vehicle device identification information includes a product number of the in-vehicle device. The software information management device according to any one of claims 1 to 6.

8. The software information management device is mounted on a vehicle. The software information management device according to any one of claims 1 to 7.

9. The software information management device is a relay device that relays communication between a plurality of in-vehicle devices. The software information management device according to claim 8.

10. A step of receiving software identification information of target software, a step of acquiring in-vehicle device identification information corresponding to the received software identification information of the target software from a storage unit that stores in association in-vehicle device identification information for identifying an in-vehicle device and software identification information for identifying software used in the in-vehicle device, and a step of outputting the acquired in-vehicle device identification information. A software information management method.

11. A software information management program for causing a computer to execute a step of receiving software identification information of target software, a step of acquiring in-vehicle device identification information corresponding to the received software identification information of the target software from a storage unit that stores in association in-vehicle device identification information for identifying an in-vehicle device and software identification information for identifying software used in the in-vehicle device, and a step of outputting the acquired in-vehicle device identification information.

Images