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

Abstract

To specify an on-vehicle device using software with vulnerability.SOLUTION: A software information management device comprises: a storage unit that stores on-vehicle specification information specifying an on-vehicle device, and software specification information specifying software used in the on-vehicle device, in association with each other; a receiving unit that receives software specification information of target software; an acquisition unit that acquires, from the storage unit, the on-vehicle device specification information corresponding to the software specification information of the target software received by the receiving unit; and an output unit that outputs the on-vehicle device specification information acquired by the acquisition unit.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The present disclosure relates to a software information management device, a software information management method, and a software information management program.

Background Art

[0002] Vehicles are equipped with various in-vehicle devices such as a control system ECU (Electronic Control Unit) that controls an engine, a transmission, etc., a body system ECU that controls a headlight, a power window, etc., and an information system ECU such as a navigation device and a multimedia device. Each in-vehicle device is connected to an in-vehicle network and can communicate with each other. In these ECUs, various software operates to realize their respective functions.

[0003] Patent Document 1 discloses an IT asset configuration management system in which the dependency relationships between a plurality of software are registered in a database, and when changing, newly developing, or newly introducing existing software in the management of IT assets, the software in dependency relationships with that software is retrieved from the database, and the retrieved software is output as a range that may be affected by the change, new development, or new introduction of the software.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] If a vulnerability is found in the software used in the ECU, it is necessary to stop using or update the software. However, the software dependencies are complex, and it is difficult to find the ECU that uses the vulnerable software. In the system disclosed in Patent Document 1, it is impossible to identify the ECU that uses the vulnerable software.

Means for Solving the Problems

[0006] A software information management device according to an aspect of the present disclosure includes a storage unit that stores in association vehicle-mounted device identification information for identifying a vehicle-mounted device and software identification information for identifying software used in the vehicle-mounted device, a reception unit that receives the software identification information of a target software, an acquisition unit that acquires from the storage unit the vehicle-mounted 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 vehicle-mounted device identification information acquired by the acquisition unit.

Advantages of the Invention

[0007] According to the present disclosure, it is possible to identify a vehicle-mounted device that uses vulnerable software.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6A

Figure 6B

Figure 7

Figure 8

Figure 9

[0009] <Overview of Embodiments of the Present Disclosure> The overview of the embodiments of the present disclosure will be listed and described below.

[0010] (1) The software information management device according to the present embodiment includes a storage unit that stores in association with each other in-vehicle device identification information that identifies an in-vehicle device and software identification information that identifies 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. Thus, by inputting the software identification information of target software with vulnerability into the software information management device, the in-vehicle device identification information of the in-vehicle device that uses the target software is output. Therefore, it is possible to identify the in-vehicle device that uses vulnerable software.

[0011] (2) In the above (1), the storage unit stores the in-vehicle device specific information in association with software specific information of lower-level software used in the upper-level software installed in the in-vehicle device, and the target software may be the lower-level software. Thereby, when a vulnerability is found in the lower-level software that is a library of the upper-level software, the in-vehicle device using the lower-level software can be identified.

[0012] (3) In the above (2), the storage unit stores the in-vehicle device specific information in association with first software specific information for identifying the upper-level software installed in the in-vehicle device and second software specific information for identifying the lower-level software used in the upper-level software. The acquisition unit further acquires the first software specific information corresponding to the second software specific information of the target software received by the reception unit, and the output unit may further output the first software specific information acquired by the acquisition unit. Thereby, not only the in-vehicle device using the vulnerable lower-level software but also the upper-level software using the lower-level software can be identified.

[0013] (4) In the above (2) or (3), the storage unit stores dependency information including the second software specific information for identifying the lower-level software used in the upper-level software. The storage unit stores the in-vehicle device specific information, the first software specific information, and the dependency information in association with each other. The acquisition unit identifies the dependency information including the second software specific information received by the reception unit, and may acquire the in-vehicle device specific information corresponding to the identified dependency information. Thereby, by identifying the dependency information including the second software specific information of the vulnerable lower-level software, the in-vehicle device corresponding to this dependency information can be identified as the in-vehicle device using the vulnerable lower-level software.

[0014] (5) In the above (4), the software information management device further includes an update data acquisition unit that acquires update data for updating the upper-level software, and an update control unit that controls the update of the upper-level software based on the update data acquired by the update data acquisition unit. The update data acquisition unit may acquire new dependency relationship information corresponding to the upper-level software after the update together with the update data. Thereby, when the upper-level software is updated, the dependency relationship information can be updated corresponding to the upper-level software after the update.

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

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

[0017] (8) In any one of the above (1) to (7), the software information management device may be mounted on a vehicle. Thereby, in-vehicle devices using vulnerable software can be identified within the vehicle.

[0018] (9) In the above (8), the software information management device may be a relay device that relays communication between a plurality of in-vehicle devices. Thereby, in-vehicle devices using vulnerable software can be identified in a relay device on the communication path between a plurality of in-vehicle devices.

[0019] (10) The software information management method according to this embodiment includes a step of receiving software identification information of target software, a vehicle-mounted device identification information for identifying a vehicle-mounted device, and a software identification information for identifying software used in the vehicle-mounted device, and obtaining, from a storage unit that stores them in association, vehicle-mounted device identification information corresponding to the received software identification information of the target software, and outputting the obtained vehicle-mounted device identification information. Thereby, by inputting the software identification information of target software with vulnerability into the software information management device, the vehicle-mounted device identification information of the vehicle-mounted device using the target software is output. Therefore, it is possible to identify a vehicle-mounted device using software with vulnerability.

[0020] (11) The software information management program according to this embodiment causes a computer to execute a step of receiving software identification information of target software, a step of obtaining, from a storage unit that stores in association vehicle-mounted device identification information for identifying a vehicle-mounted device and software identification information for identifying software used in the vehicle-mounted device, vehicle-mounted device identification information corresponding to the received software identification information of the target software, and a step of outputting the obtained vehicle-mounted device identification information. Thereby, by inputting the software identification information of target software with vulnerability into the software information management device, the vehicle-mounted device identification information of the vehicle-mounted device using the target software is output. Therefore, it is possible to identify a vehicle-mounted device using software with vulnerability.

[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 realizing part or all of the software information management device.

[0022] <Details of Embodiments of the Present Disclosure> Hereinafter, the details of the embodiments of the present invention will be described with reference to the drawings. Note that at least a part of the embodiments described below may be arbitrarily combined.

[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] A vehicle is equipped with an in-vehicle network 100. The in-vehicle network 100 according to the embodiment is a CAN (Controller Area Network) network capable of communication by CAN. The in-vehicle network 100 includes bus 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] The plurality of ECUs 300A, 300B, 300C, 300D, and 300E are arranged in each part of the vehicle. The ECUs 300A, 300B, 300C, 300D, and 300E individually control the hardware of each part of the vehicle or monitor the state of the hardware of each part of the vehicle. For example, the ECUs 300A, 300B, 300C, 300D, and 300E are ECUs for the control system, body system, and 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 each of the ECUs 300A, 300B, 300C, 300D, and 300E via the buses 400A, 400B, and 400C. Specifically, the ECU 300A and 300B are connected to the bus 400A. The ECU 300C and 300D are connected to the bus 400B. The ECU 300E is connected to the bus 400C. The relay ECU 200 can communicate with each of the ECUs 300A, 300B, 300C, 300D, and 300E. The relay ECU 200, ECUs 300A, 300B, 300C, 300D, and 300E are examples of "in-vehicle devices".

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

[0029] The relay ECU 200 has a function as a gateway for relaying communication between a plurality of ECUs 300. Specifically, the relay ECU 200 relays communication (frames) between the buses 400A, 400B, and 400C. The ECU 300 can transmit a frame. The frame is a message compliant with the communication protocol described above. The relay ECU 200 relays frames between ECUs connected to different buses. For example, the relay ECU 200 can relay a frame between the ECU 300A connected to the bus 400A and the ECU 300C connected to the 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 includes, for example, a wireless communication interface for a mobile communication system such as the 5th generation mobile communication system (5G) or the 4th generation mobile communication system (4G). The external communication device 350 can transmit and receive, for example, TCP / IP (Transmission Control Protocol / Internet Protocol) packets. The external communication device 350 is logically connected to a base station (not shown) of a mobile communication network and can communicate with a device 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 compliant with OBD1 (On-board Diagnostics first generation) or OBD2 (On-board Diagnostics second generation). A diagnostic device 370 for performing vehicle diagnosis 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-described communication protocol. For example, the diagnostic device 370 can collect, from the relay ECU 200 and the ECU 300, abnormalities or warning information, etc. detected by the ECU 300 in the past.

[0032] The diagnostic device 370 according to the embodiment can request (inquire) the relay ECU 200 for information regarding the software (hereinafter also referred to as "SW") used in the ECU. The relay ECU 200 can respond to the inquiry and transmit (output) the information regarding the software to the diagnostic device 370. In a specific example, the diagnostic device 370 can inquire the relay ECU 200 about the information of the ECU using a specific software. The relay ECU 200 searches for the ECU 300 using the software to be inquired, and transmits the search result to the diagnostic device 370. The diagnostic device 370 displays the received search result.

[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. The relay ECU 200 includes a processor 201, a non-volatile memory 202, a volatile memory 203, and communication interfaces (hereinafter also referred to as "communication I / F") 204A, 204B, 204C. Each of the processor 201, the non-volatile memory 202, the volatile memory 203, and the communication I / F 204 is connected to each other by a bus 205 which is a communication line. Each of the processor 201, the non-volatile memory 202, the volatile memory 203, and the communication I / F 204 can transmit data to each other via the bus 205. The relay ECU 200 is an example of a "relay device".

[0034] The volatile memory 203 is a semiconductor memory such as SRAM (Static Random Access Memory) or DRAM (Dynamic Random Access Memory). The non-volatile memory 202 is, for example, a flash memory, a hard disk, a ROM (Read Only Memory), etc. The non-volatile memory 202 stores an update control program 210 and an SW information management program 220 which are computer programs, as well as data used for the execution of these programs 210, 220. The functions of the relay ECU 200 described later are realized by the update control program 210 and the SW information management program 220 being executed by the processor 201.

[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 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 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 the 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, 204C are communication interfaces compliant with the communication protocols for the in-vehicle network described above. That is, the communication I / Fs 204A, 204B, 204C are, for example, CAN interfaces. In other examples, the communication I / Fs 204A, 204B, 204C are Ethernet interfaces.

[0037] Communication I / F204A is connected to bus 400A. Communication I / F204B is connected to bus 400B. Communication I / F204C is connected to bus 400C. Relay ECU200 can communicate with ECUs 300A and 300B via Communication I / F204A. Relay ECU200 can communicate with ECUs 300C and 300D via Communication I / F204B. Relay ECU200 can communicate with ECU300E via Communication I / F204C. Further, Relay ECU200 can communicate with diagnostic device 370 via Communication I / F204C and can communicate with server 500 via external communication device 350.

[0038] Non-volatile memory 202 stores correspondence table 230 and SBOMs (Software Bill Of Materials) 231AA, 231BA, 231AB, 231AC, 231BC, 231AD, 231AE, which are used to search for ECUs 300 that use the software to be queried. In the following description, SBOMs 231AA, 231BA, 231AB, 231AC, 231BC, 231AD, 231AE are also collectively referred to as "SBOM231".

[0039] [3. Software Dependency] Each ECU300 is equipped with application software. The application software is a program for individually controlling the hardware of each part of the vehicle or monitoring the state of the hardware of each part of the vehicle. The application software installed in ECU300 uses one or more software as a library. That is, there is a dependency relationship between the software installed in ECU300.

[0040] The software dependency in each ECU300 will be described using the example of FIG. 1.

[0041] ECU 300A is equipped with application software AA. AA uses software BA and DA as libraries. BA uses software CA as a library. That is, AA is the upper-level software, and BA and DA are the lower-level software. Also, CA is the lower-level software of BA and also the 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 the upper-level software, and BB and DB are the 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. That is, AC is the upper-level software, and BC is the lower-level software. Also, CA is the lower-level software of BC and also the lower-level software of AC.

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

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

[0046] [4. Function of Relay ECU] Figure 3 is a functional block diagram showing an example of the function of the relay ECU according to the embodiment.

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

[0048] For example, when a vulnerability is discovered in a certain software, an inquiry about the ECU using the software is given to the relay ECU 200. The reception unit 221 receives information (hereinafter also referred to as "software identification information" or "SW identification information") for identifying the software that is the subject of the inquiry (hereinafter also referred to as "target software" or "target SW"). For example, when the user inquires about the information of the ECU 300 using the target SW, the user inputs an inquiry including the SW identification information (hereinafter also referred to as "SW usage inquiry") to the diagnostic device 370. The diagnostic device 370 transmits the input SW identification information to the relay ECU 200. The reception unit 221 receives it by receiving the SW identification information.

[0049] The acquisition unit 222 acquires information (hereinafter also referred to as "ECU identification information") for identifying the 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-mounted device identification information". The acquisition unit 222 acquires the ECU identification information from the non-volatile memory 202. The non-volatile 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 corresponding to the SW identification information of the target SW.

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

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

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

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

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

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

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

[0057] The correspondence table 230 further stores the location information of SBOM231. In a specific example, SBOM231 is one file, and the correspondence table 230 stores the file name of SBOM231. An SBOM is a machine-processable list that includes information on software components and their dependencies, and is also called a "software bill of materials". SBOM231 includes SW specific information (second software specific information) that identifies the lower-level software used in the upper-level software. That is, SBOM231 is an example of "dependency information".

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

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

[0060] Figure 5 is a diagram for explaining the relationship of software components in the SBOM scenario. In this scenario, it is assumed that Company A developed software AA installed in ECU300A using software components BA and DA. BA was developed by Company B using a software component CA by Mr. C. DA was developed by community D.

[0061] As shown in Figure 5, the version of AA is 2.3, and it is the top-level software that uses software components BA, CA, and DA. The version of BA is 1.4 and it is used in AA. The version of CA is 4.0 and it is used in BA. The version of DA is 3.1 and it is used in AA.

[0062] Figure 6A is a diagram showing an example of the SBOM of software AA. The SBOM231AA includes the name "AA" of the software targeted by the SBOM231AA, version information "2.3", the supplier name "Company A" of AA, etc. In particular, the SBOM231AA includes "AA@2.3" which is the SW identification information of AA (tagId). Furthermore, the SBOM231AA includes the SW identification information "BA@1.4" and "DA@3.1" of software components BA and DA used in AA (SWID). The SW identification information "BA@1.4" and "DA@3.1" of the software components BA and DA which are libraries are the parts enclosed by broken lines.

[0063] In this example, there is an SBOM231BA of software BA that uses software CA. Figure 6B is a diagram showing an example of the SBOM of software BA. The SBOM231BA includes the name "BA" of the software targeted by the SBOM231BA, version information "1.4", the supplier name "Company B" of BA, etc. In particular, the SBOM231BA includes "BA@1.4" which is the SW identification information of BA (tagId). Furthermore, the SBOM231BA includes the SW identification information "CA@4.0" of software component CA used in BA (SWID). The SW identification information "CA@4.0" of the software component CA which is a library is the part enclosed by broken lines.

[0064] Returning to FIG. 4, in the correspondence table 230, as the location information of the SBOM 231, the file names of the SBOM 231 of the software used in the ECU 300 are stored in association with the ECU identification information of the ECU 300. That is, the SBOM file names "AA_sbom.xml" and "BA_sbom.xml" correspond to the ECU identification information "XY35125". The SBOM file name "AB_sbom.xml" corresponds to the ECU identification information "FD143". The SBOM file names "AC_sbom.xml" and "BC_sbom.xml" correspond to the ECU identification information "YD54F". The SBOM file name "AD_sbom.xml" corresponds to the ECU identification information "CC9624". The SBOM file name "AE_sbom.xml" corresponds to the ECU identification 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 used SW (that is, as the SWID in the above example). For example, when a vulnerability is found in version 4.0 of the software CA, the user inputs the SW identification information "CA@4.0" of CA as the target of the SW usage inquiry in order to identify the ECU 300 using 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, the acquisition unit 222 acquires the SW identification information "BA@1.4" of the target software BA of the SBOM 231BA from the SBOM 231BA in which "CA@4.0" is searched. The acquisition unit 222 refers to the correspondence table 230 and acquires the ECU identification information "XY35125" corresponding to the file name "BA_sbom.xml" of the SBOM 231BA in which the search for the SW identification information "CA@4.0" hits. The acquisition unit 222 checks whether an SBOM corresponding to the ECU identification information "XY35125" exists other than the SBOM 231BA, and identifies the existence of the SBOM 231AA (file name "AA_sbom.xml").

[0067] The acquisition unit 222 refers to the SBOM 231AA, and performs a string search using the software identification information "BA@1.4" of the BA that uses the target SW "CA@4.0" as the search key. The acquisition unit 222 identifies that "BA@1.4" exists in the SWID of the SBOM 231AA. Furthermore, the acquisition unit 222 acquires the software identification information "AA@2.3" of the target software AA from the SBOM 231AA in which "BA@1.4" is searched. Thereby, it is identified that AA uses BA and BA uses CA which is the target SW.

[0068] The acquisition unit 222 refers to the correspondence table 230, and acquires the ECU identification information "XY35125" corresponding to the file name "AA_sbom.xml" of the SBOM 231AA in which the search for the software identification information "BA@1.4" hits.

[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 software identification information "AA@2.3" of the software AA.

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

[0071] Returning to FIG. 4, the output unit 223 outputs the ECU identification information of the ECU 300 that uses the target SW and the software 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 at least the ECU identification information of the ECU 300 that uses the target SW, and the software identification information of the software that uses the target SW is not necessarily output.

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

[0073] The update data acquisition unit 211 acquires update data for updating the application software that is the upper software. For example, when updating the software AA in FIG. 1, the update data acquisition unit 211 acquires the update data for AA. The update data includes, for example, the code of the updated application program.

[0074] For example, the server 500 manages the update of the application software of 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 in 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 the application software installed in the ECU mounted on each vehicle. That is, the server 500 stores the vehicle identification information (hereinafter also referred to as "vehicle ID") and the identification information (or SW identification information) of the application software installed in the ECU mounted on the vehicle in association with each other. The update data acquisition unit 211 transmits the vehicle ID of the vehicle on which the relay ECU 200 is mounted to the server 500, for example, periodically or in response to a request from the server 500. When the server 500 receives the vehicle ID, it identifies the application software corresponding to the vehicle ID and determines whether there is update data. If there is update data, the server 500 transmits the update data to the relay ECU 200 that is the source of the vehicle ID transmission.

[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 update of the application software. The ECU 300 updates the application software using the received update data in response to the update instruction.

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

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

[0079] [5. Operation of Relay ECU] Next, the operation of the relay ECU 200 according to the embodiment will be described. First, in a new (pre-sale) vehicle that is not in use, the SBOM 231 is not introduced into the relay ECU 200. Therefore, the SBOM 231 is introduced into the relay ECU 200 of the vehicle. The server 500 stores the SBOM 231 as part of the information on the application programs used in the vehicle in association with the vehicle ID.

[0080] FIG. 7 is a sequence diagram showing an example of the SBOM introduction process by the relay ECU and the server. The server 500 transmits a request for the vehicle ID, for example, by broadcast (step S101). When the processor 201 of the relay ECU 200 mounted on the new vehicle receives the vehicle ID request, it transmits the vehicle ID of its own vehicle to the server 500 (step S102).

[0081] The server 500 transmits the SBOM 231 corresponding to the received vehicle ID (step S103). All SBOMs are transmitted after being divided into a plurality of frames. Hereinafter, the divided frames of the SBOM are also referred to as "SBOM data".

[0082] The processor 201 writes all the received SBOM data into the non-volatile memory 202. When the writing is completed, the processor 201 transmits a writing completion notification to the server 500. Thus, the SBOM introduction process is completed.

[0083] Next, the update control process of the application software will be described. FIG. 8 is a flowchart showing an example of the update control process of the application software by the relay ECU.

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

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

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

[0087] If SBOM 231 is completed (YES in step S205), the processor 201 determines whether it has received a notification of the end of the update process from the ECU 300 to be updated (step S206). The ECU 300 to be updated executes the update process of the application software with the update data, and when the update process ends, that is, when the update is successful or fails, it notifies the relay ECU 200 of the end of the update process.

[0088] If the update process has not ended, that is, if it has not received a notification of the end of the update process (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 failed. 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), the processor 201 reads out a new SBOM 231 formed by combining SBOM data from the buffer and rewrites the SBOM 231 stored in the non-volatile memory 202 with the new SBOM 231 (step S208). If the update fails (NO in step S207), the processor 201 discards the SBOM 231 stored in the buffer (step S209). Thus, the update control process of the application software ends.

[0091] Next, in response to an inquiry from the diagnostic device 370, an information providing process of searching for the ECU 300 that uses the target SW and providing the search result to the user will be described. FIG. 9 is a sequence diagram showing an example of the information providing process by the relay ECU and the diagnostic device.

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

[0093] The processor 201 searches the SBOM 231 for a string using the software identification information of the target software specified in the SW usage inquiry as a search key. When the search for the software identification information hits in the SBOM 231, the processor 201 obtains the ECU identification information of the ECU 300 corresponding to the SBOM 231 and the software identification information of the application software in the correspondence table 230 (step S302).

[0094] The processor 201 transmits a search result including the searched ECU identification information and software identification information to the diagnostic device 370. The diagnostic device 370 receives the search result (step S303).

[0095] The diagnostic device 370 displays the search result, that is, the ECU identification information of the ECU 300 using the target software and the software identification information of the application software using the target software (step S304). Thus, the information providing process ends.

[0096] [6. Modification Example] In the above-described embodiment, the configuration using the SBOM 231 as the dependency information has been described, but the present invention is not limited to this. The dependency information only needs to include information for specifying the software used at least in the application software, and may not be an SBOM.

[0097] In the above-described embodiment, a configuration has been described in which, in response to an inquiry from the diagnostic device 370, the relay ECU 200 transmits the ECU specific information of the ECU 300 that uses the software being inquired about and the SW specific information of the application software to the diagnostic device 370. However, the present invention is not limited to this. For example, from a terminal (such as a smartphone) outside the vehicle, an SW usage inquiry including the input SW specific information may be transmitted to the relay ECU 200, and the relay ECU 200 may transmit the ECU specific information of the ECU 300 that uses the software being inquired about and the SW specific information of the application software to the terminal. The terminal may display the received ECU specific information and SW specific information. As another example, an ECU 300 connected to a display inside the vehicle may transmit an SW usage inquiry including the input SW specific information to the relay ECU 200, and the relay ECU 200 may transmit the ECU specific information of the ECU 300 that uses the software being inquired about and the SW specific information of the application software to the ECU 300. The ECU 300 may cause the received ECU specific information and SW specific information to be displayed on the display. As yet another example, a device inside or outside the vehicle may transmit an SW usage inquiry including the SW specific information to the relay ECU 200, and the relay ECU 200 may transmit the ECU specific information of the ECU 300 that uses the software being inquired about and the SW specific information of the application software to the device. The device may be used for information processing such as vehicle diagnosis processing without displaying the received ECU specific information and SW specific information.

[0098] In the above-described embodiment, a configuration has been described in which the relay ECU 200 acquires the ECU specific information of the ECU 300 that uses the software being inquired about and the SW specific information of the application software. However, the present invention is not limited to this. For example, an ECU 300 that does not have a frame relay function may acquire (search for) the ECU specific information of the ECU 300 that uses the software being inquired about and the SW specific information of the application software.

[0099] In the above-described embodiment, the SBOM 231 is specified by the file name, but it is not limited thereto. For example, in the case of an OS that does not adopt a file system, the storage location (for example, the start address and data size of the storage location) of each SBOM 231 in the non-volatile memory 202 is stored in a correspondence table, and the SBOM 231 may be specified by the storage location in the non-volatile memory 202.

[0100] [7. Supplementary Note] The embodiments disclosed this time are illustrative in all respects and not restrictive. The scope of the rights of the present invention is shown not by the above-described embodiments but by the scope of claims, and includes all modifications within the meaning equivalent to the scope of claims and within that scope.

Explanation of Reference Numerals

[0101] 10 Vehicle-mounted system 100 Vehicle-mounted 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 (Vehicle-mounted device) 350 External communication device 370 Diagnostic device 400A, 400B, 400C Buses 410 Connector 500 Server

Claims

1. A storage unit that stores in association information for identifying an in-vehicle device and information for identifying software used in the in-vehicle device, A reception desk that receives software identification information for the target software, An acquisition unit that acquires in-vehicle device identification information corresponding to the software identification information of the target software received by the reception unit from the storage unit, An output unit that outputs the vehicle-mounted device identification information acquired by the acquisition unit, Equipped with, Software information management device.

2. The storage unit stores the in-vehicle device identification information and the software identification information of the lower-level software used in the higher-level software installed in the in-vehicle device in association with each other. The aforementioned target software is the subordinate software, The software information management device according to claim 1.

3. The storage unit stores 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 further acquires the first software identification information corresponding to the second software identification information of the target software received by the reception unit, The output unit further outputs the first software-specific information acquired by the acquisition unit. The software information management device according to claim 2.

4. The storage unit stores dependency information including the second software identification information that identifies the lower-level software used in the higher-level software, The storage unit stores the in-vehicle device identification information, the first software identification information, and the dependency information in association with each other. The acquisition unit identifies the dependency 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 information. The software information management device according to claim 3.

5. An update data acquisition unit that acquires update data for updating the aforementioned higher-level software, An update control unit controls the update of the higher-level software based on the update data acquired by the update data acquisition unit, Furthermore, The update data acquisition unit acquires new dependency information corresponding to the updated higher-level software, along with the update data. The software information management device according to claim 4.

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

7. The vehicle-mounted device identification information includes the product number of the vehicle-mounted device. A software information management device according to any one of claims 1 to 5.

8. The aforementioned software information management device is installed in the vehicle. A software information management device according to any one of claims 1 to 5.

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

10. Steps include receiving software identification information for the target software, A step of obtaining vehicle-specific information corresponding to the software identification information of the target software received from a storage unit that stores vehicle-specific information identifying a vehicle-mounted device and software identification information identifying software used in the vehicle-mounted device in association with each other, The steps include outputting the acquired in-vehicle device identification information, including, Software information management methods.

11. On the computer, Steps include receiving software identification information for the target software, A step of obtaining vehicle-specific information corresponding to the software identification information of the target software received from a storage unit that stores vehicle-specific information identifying a vehicle-mounted device and software identification information identifying software used in the vehicle-mounted device in association with each other, The steps include outputting the acquired in-vehicle device identification information, To execute Software information management program.

Images