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

Abstract

The software information management device includes: a storage unit that stores vehicle device determination information and software determination information of software used in the vehicle device in a corresponding manner; a receiving unit that receives the software determination information of the target software; an acquisition unit that acquires the vehicle device determination information corresponding to the software determination information of the target software received by the receiving unit from the storage unit; and an output unit that outputs the vehicle device determination information acquired by the acquisition unit.

Description

Technical Field

[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 based on Japanese Application No. 2024-002825, filed on January 11, 2024, and incorporates the entire contents of the aforementioned Japanese application. Background Technology

[0002] Vehicles are equipped with various in-vehicle devices, including Electronic Control Units (ECUs) that control the engine, transmission, and other systems; body system ECUs that control headlights, power windows, and other systems; and information system ECUs for navigation and multimedia equipment. These in-vehicle devices are connected to the vehicle network and can communicate with each other. Various software programs run within these ECUs to perform their respective functions.

[0003] Patent document 1 discloses an IT asset structure management system that registers the dependencies between multiple software programs in a database. In the management of IT assets, when it is necessary to change, develop, or import existing software, the system retrieves the software that is dependent on the existing software from the database and outputs the retrieved software as the scope that may be affected by the software change, development, or import.

[0004] Existing technical documents

[0005] Patent documents

[0006] Patent Document 1: Japanese Patent Application Publication No. 2010-113392 Summary of the Invention

[0007] A software information management device according to one aspect of this disclosure includes: a storage unit for storing vehicle device determination information and software determination information for determining software used in the vehicle device in a corresponding manner; a receiving unit for receiving software determination information of target software; an acquisition unit for acquiring vehicle device determination information corresponding to the software determination information of the target software received by the receiving unit from the storage unit; and an output unit for outputting the vehicle device determination information acquired by the acquisition unit. Attached Figure Description

[0008] Figure 1 This is a diagram illustrating an example of the structure of an onboard system according to an implementation method.

[0009] Figure 2 This is a block diagram illustrating an example of the hardware structure of a relay ECU in an implementation method.

[0010] Figure 3 This is a functional block diagram illustrating an example of the function of the relay ECU in an implementation method.

[0011] Figure 4 This is a diagram representing an example of a corresponding table.

[0012] Figure 5 This is a diagram used to illustrate the relationships between software components in a SBOM scenario.

[0013] Figure 6A This is a diagram representing an example of the SBOM of software AA.

[0014] Figure 6B This is a diagram representing an example of the SBOM of software BA.

[0015] Figure 7 This is a timing diagram illustrating an example of SBOM import processing performed by a relay ECU and a server.

[0016] Figure 8 This is a flowchart illustrating an example of application software update control processing performed by a relay ECU.

[0017] Figure 9 This is a timing diagram illustrating an example of information provision processing performed by the relay ECU and diagnostic device. Detailed Implementation

[0018] <The problem this disclosure aims to solve>

[0019] If a vulnerability is found in the software used by the ECU, its use needs to be stopped or updated. However, software dependencies are complex, making it difficult to identify the ECU using the vulnerable software. In the system disclosed in Patent Document 1, it is impossible to determine which ECU is using the vulnerable software.

[0020] <Effects of this disclosure>

[0021] According to this disclosure, it is possible to identify vehicle-mounted devices that use vulnerable software.

[0022] <Summary of embodiments of this disclosure>

[0023] Hereinafter, a summary of the embodiments of this disclosure will be described.

[0024] (1) The software information management device of this embodiment includes: a storage unit that stores vehicle device determination information and software determination information of software used in the vehicle device in a corresponding manner; a receiving unit that receives software determination information of target software; an acquisition unit that acquires vehicle device determination information corresponding to the software determination information of the target software received by the receiving unit from the storage unit; and an output unit that outputs the vehicle device determination information acquired by the acquisition unit. Thus, by inputting software determination information of target software with vulnerabilities into the software information management device, vehicle device determination information of the vehicle device using the target software is output. Therefore, it is possible to determine vehicle devices using software with vulnerabilities.

[0025] (2) In (1) above, the storage unit may also establish a corresponding storage of the vehicle device determination information and the software determination information of the lower-level software used in the upper-level software mounted on the vehicle device, wherein the target software is the lower-level software. Therefore, if a vulnerability is discovered in the lower-level software, which serves as the library of the upper-level software, the vehicle device using the lower-level software can be determined.

[0026] (3) In (2) above, the storage unit may also establish and store the vehicle device determination information, the first software determination information, and the second software determination information in a corresponding manner. The first software determination information determines the upper-level software mounted on the vehicle device, and the second software determination information determines the lower-level software used in the upper-level software. The acquisition unit also acquires the first software determination information corresponding to the second software determination information of the target software accepted by the acceptance unit, and the output unit also outputs the first software determination information acquired by the acquisition unit. Thus, it is possible not only to determine vehicle devices using vulnerable lower-level software, but also to determine upper-level software using lower-level software.

[0027] (4) In (2) or (3) above, the storage unit may store dependency information, which includes second software determination information for the lower-level software used in the upper-level software. The storage unit stores the vehicle device determination information, the first software determination information, and the dependency information in a corresponding manner. The acquisition unit determines the dependency information containing the second software determination information received by the acceptance unit and acquires the vehicle device determination information corresponding to the determined dependency information. Thus, by determining the dependency information containing second software determination information of the lower-level software with vulnerabilities, the vehicle device corresponding to the dependency information can be determined as a vehicle device using the lower-level software with vulnerabilities.

[0028] (5) In (4) above, the software information management device may also include: an update data acquisition unit that acquires update data for updating the host software; and an update control unit that controls the update of the host software based on the update data acquired by the update data acquisition unit, wherein the update data acquisition unit acquires new dependency information corresponding to the updated host software along with the update data. Thus, when the host software is updated, the dependency information can be updated accordingly to the updated host software.

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

[0030] (7) In any of (1) to (6) above, the vehicle device identification information may include the product number of the vehicle device. Thus, the vehicle device can be identified by the product number.

[0031] (8) In any of (1) to (7) above, the software information management device may also be mounted on a vehicle. Thus, it is possible to identify an in-vehicle device using vulnerable software within the vehicle.

[0032] (9) In (8) above, the software information management device may also be a relay device that relays communication between multiple vehicle-mounted devices. Thus, among the relay devices on the communication path between multiple vehicle-mounted devices, it is possible to identify the vehicle-mounted device using the vulnerable software.

[0033] (10) The software information management method of this embodiment includes the following steps: accepting software determination information of target software; obtaining vehicle device determination information corresponding to the software determination information of the accepted target software from a storage unit, wherein the storage unit establishes a corresponding storage of the vehicle device determination information determining the vehicle device and the software determination information determining the software used in the vehicle device; and outputting the obtained vehicle device determination information. Thus, by inputting the software determination information of the vulnerable target software into the software information management device, vehicle device determination information of the vehicle device using the target software is output. Therefore, it is possible to determine the vehicle device using the vulnerable software.

[0034] (11) The software information management program of this embodiment causes a computer to perform the following steps: accepting software determination information of target software; obtaining vehicle device determination information corresponding to the accepted software determination information of the target software from a storage unit, wherein the storage unit establishes a corresponding storage of the vehicle device determination information determining the vehicle device and the software determination information determining the software used in the vehicle device; and outputting the obtained vehicle device determination information. Thus, by inputting the software determination information of the vulnerable target software into the software information management device, vehicle device determination information of the vehicle device using the target software is output. Therefore, it is possible to determine vehicle devices using vulnerable software.

[0035] This disclosure can be implemented not only as a software information management device having the characteristic structure described above, a software information management method including characteristic steps, and a software information management program for causing the software information management device to perform characteristic processing, but also as a system including the software information management device, or as a part or all of the software information management device as a semiconductor integrated circuit.

[0036] <Detailed description of the embodiments of this disclosure>

[0037] Hereinafter, detailed descriptions of embodiments of the present disclosure will be provided with reference to the accompanying drawings. Furthermore, at least a portion of the embodiments described below may be combined in any manner.

[0038] [1. In-vehicle system]

[0039] Figure 1 This is a diagram illustrating an example of the structure of an onboard system according to an implementation method.

[0040] The vehicle is equipped with an in-vehicle network 100. The in-vehicle network 100 in this embodiment is a CAN network capable of CAN (Controller Area Network) based communication. The in-vehicle network 100 includes buses 400A, 400B, and 400C, which serve as CAN buses.

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

[0042] Multiple ECUs 300A, 300B, 300C, 300D, and 300E are configured in various parts of the vehicle. ECUs 300A, 300B, 300C, 300D, and 300E individually control or monitor the hardware status of various parts of the vehicle. For example, ECUs 300A, 300B, 300C, 300D, and 300E are ECUs for control systems, body systems, and information systems. Furthermore, in the following description, ECUs 300A, 300B, 300C, and 300D will be collectively referred to as "ECU300".

[0043] Relay ECU 200 is connected to ECUs 300A, 300B, 300C, 300D, and 300E via buses 400A, 400B, and 400C, respectively. 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. Relay ECU 200 can communicate with ECUs 300A, 300B, 300C, 300D, and 300E. Relay ECUs 200, 300A, 300B, 300C, 300D, and 300E are examples of "on-board units".

[0044] The relay ECU200 and ECU300 use communication protocols for periodically or non-periodically sending and receiving messages. Communication protocols such as CAN or CAN FD (CAN with Flexible Data Rate) are examples. In another example, the communication protocol is Ethernet (registered trademark). When using the Ethernet protocol, the in-vehicle network becomes an Ethernet network with a star network topology.

[0045] The relay ECU 200 functions as a gateway to relay communication between multiple ECUs 300. Specifically, the relay ECU 200 relays communication (frames) between buses 400A, 400B, and 400C. ECUs 300 can send frames. A frame is a message according to the aforementioned communication protocol. The relay ECU 200 relays frames between ECUs connected to different buses. For example, the relay ECU 200 can relay frames between ECU 300A connected to bus 400A and ECU 300C connected to bus 400B.

[0046] The relay ECU 200 is connected to the external communication device 350 via bus 400C. The external communication device 350 is, for example, a TCU (Telematics Control Unit), capable of communicating with devices outside the vehicle. The external communication device 350 may have a wireless communication interface for mobile communication systems such as 5G or 4G. The external communication device 350 may be capable of sending and receiving TCP / IP (Transmission Control Protocol / Internet Protocol) data packets. The external communication device 350 is logically connected to a base station (not shown) of a mobile communication network, enabling communication with devices connected to the Internet via the base station. Specifically, the external communication device 350 can communicate with the server 500. The external communication device 350 relays the communication between the relay ECU 200 and the server 500. The server 500 and the relay ECU 200 constitute a software information management system.

[0047] Connector 410 is connected to bus 400C. Connector 410 is, for example, a connector conforming to OBD1 (On-board Diagnostics first generation) or OBD2 (On-board Diagnostics second generation) connectors. A diagnostic device 370 for performing vehicle diagnostics can be connected to connector 410. The diagnostic device 370 can communicate with relay ECU 200 and ECU 300 using the aforementioned communication protocol. For example, the diagnostic device 370 can collect abnormal or warning information previously detected by ECU 300 from relay ECU 200 and ECU 300.

[0048] The diagnostic device 370 of this embodiment can request (inquire) information related to the software (hereinafter also referred to as "SW") used in the relay ECU 200. The relay ECU 200 can respond to the inquiry and send (output) software-related information to the diagnostic device 370. In a specific example, the diagnostic device 370 can inquire with the relay ECU 200 about ECUs using specific software. The relay ECU 200 retrieves information about ECUs 300 using the software inquired about and sends the retrieval results to the diagnostic device 370. The diagnostic device 370 displays the received retrieval results.

[0049] [2. Hardware structure of relay ECU]

[0050] Figure 2This is a block diagram illustrating an example of the hardware structure of a relay ECU according to an 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, and 204C. The processor 201, non-volatile memory 202, volatile memory 203, and communication I / F 204 are interconnected via a bus 205, which serves as a communication line. The processor 201, non-volatile memory 202, volatile memory 203, and communication I / F 204 are capable of transmitting data to each other via the bus 205. The relay ECU 200 is an example of a "relay device".

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

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

[0053] Communication I / F204A, 204B, and 204C are communication interfaces that conform to the communication protocol used in the aforementioned vehicle network. Specifically, communication I / F204A, 204B, and 204C are, for example, CAN interfaces. In other examples, communication I / F204A, 204B, and 204C are Ethernet interfaces.

[0054] 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 ECU 200 can communicate with ECUs 300A and 300B via communication I / F204A. Relay ECU 200 can communicate with ECUs 300C and 300D via communication I / F204B. Relay ECU 200 can communicate with ECU 300E via communication I / F204C. Furthermore, relay ECU 200 can communicate with diagnostic device 370 via communication I / F204C and with server 500 via external communication device 350.

[0055] The non-volatile memory 202 stores the correspondence table 230 used for searching the software of the ECU 300 that is being searched, and SBOMs (Software Bill of Materials) 231AA, 231BA, 231AB, 231AC, 231BC, 231AD, and 231AE. Furthermore, in the following description, SBOMs 231AA, 231BA, 231AB, 231AC, 231BC, 231AD, and 231AE will also be collectively referred to as "SBOM 231".

[0056] [3. Software Dependencies]

[0057] Each ECU 300 contains application software. Application software is a program used to individually control or monitor the status of various hardware components of the vehicle. The application software in the ECU 300 uses one or more software libraries. That is, there are dependencies between the software installed in the ECU 300.

[0058] use Figure 1 The examples illustrate the software dependencies in each ECU300.

[0059] The ECU300A 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 higher-level software, and BA and DA are lower-level software. In addition, CA is a lower-level software of BA, and also a lower-level software of AA.

[0060] The ECU300B is equipped with application software AB. AB uses software BB and DB as libraries. That is, AB is the host software, and BB and DB are the slave software.

[0061] The ECU300C 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 higher-level software, and BC is the lower-level software. In addition, CA is a lower-level software of BC, and also a lower-level software of AC.

[0062] The ECU300D is equipped with the application software AD. AD uses the software BD, DD, and ED as libraries. That is, AD is the host software, and BD, DD, and ED are the slave software.

[0063] The ECU300E is equipped with the application software AE. AE uses BE and CA software as libraries. That is, AE is the higher-level software, and BE and CA are the lower-level software.

[0064] [4. Functions of the relay ECU]

[0065] Figure 3 This is a functional block diagram illustrating an example of the function of the relay ECU in an implementation method.

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

[0067] For example, if a vulnerability is discovered in a software application, an inquiry from the ECU using that software is provided to the relay ECU 200. The receiving unit 221 receives information identifying the software to be inquired about (hereinafter also referred to as "target software" or "target SW") (hereinafter also referred to as "software determination information" or "SW determination information"). For example, if a user inquires about information regarding an ECU 300 using the target SW, they input an inquiry containing SW determination information (hereinafter also referred to as "SW usage inquiry") into the diagnostic device 370. The diagnostic device 370 sends the input SW determination information to the relay ECU 200. The receiving unit 221 processes the inquiry by receiving the SW determination information.

[0068] The acquisition unit 222 acquires information (hereinafter also referred to as "ECU determination information") corresponding to the SW determination information of the object SW received by the acceptance unit 221. The ECU determination information is an example of "on-board unit determination information". The acquisition unit 222 acquires the ECU determination 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 SBOM 231 to acquire the ECU determination information corresponding to the SW determination information of the object SW.

[0069] Here, we will explain the corresponding Table 230 and SBOM 231. Figure 4 This is a diagram representing a specific example of the corresponding table.

[0070] 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 ECU 300. However, ECU identification information is not limited to this; it can also include the name, identification information, model number, etc., of ECU 300. The product number (serial number) is a number assigned during the manufacturing of ECU 300, consisting of a batch number indicating the production location and a sequential number during manufacturing, and is a unique number that can uniquely identify the ECU. The model number is a number that identifies the type of vehicle ECU 300, such as a part number. SW identification information is a combination of software name and version information. Figure 4 In the example, "software name@version" is the SW (Software Service) identifier. However, the SW identifier is not limited to this; it can be just the software name or it can be the software's identification information.

[0071] For example, the ECU identification information for ECU300A is "XY35125". The application software installed on ECU300A has a service switch name of "AA" and a version of "2.3". The service switch identification information for software AA is "AA@2.3".

[0072] The ECU identification information for ECU300B is "FD143". The application software installed on ECU300B has a service switch name of "AB" and a version of "1.1". The service switch identification information for software AB is "AB@1.1".

[0073] The ECU identification information for ECU300C is "YA54F". The application software installed on ECU300C has a service switch name of "AC" and a version of "2.0". The service switch identification information for software AC is "AC@2.0".

[0074] The ECU identifier for ECU300D is "CC9624". The application software installed on ECU300D is named "AD" and its version is "5.1.2". The software identifier for AD is "AD@5.1.2".

[0075] The ECU identification information for ECU300E is "SGI565X". The application software SW installed on ECU300E is named "AE" and the version is "3.2". The software AC SW identification information is "AE@3.2".

[0076] Table 230 also stores the location information of SBOM 231. In a specific example, SBOM 231 is a file, and Table 230 stores the filename of SBOM 231. SBOM is a machine-processable list that also includes information about software components and their dependencies; it is also known as a "software bill of materials." SBOM 231 contains SW determination information (second software determination information) that identifies the subordinate software used in the higher-level software. That is, SBOM 231 is an example of "dependency information."

[0077] SBOMs exist in various formats. In this embodiment, SBOM231 is a SWID (Software Identification) tag format SBOM, which is an XML (Extensible Markup Language) format file. However, SBOMs are not limited to these formats and may not be in SWID tag format.

[0078] SBOM includes information such as the names, version information, and developers of the components contained in the software. Here, we will illustrate an example of SBOM using a specific scenario.

[0079] Figure 5 This diagram illustrates the relationships between software components in a SBOM scenario. In this scenario, Company A uses software components such as BA and DA to develop software AA integrated into the ECU300A. BA is developed by Company B using software component CA from Company C. DA is developed through community D.

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

[0081] Figure 6AThis is a diagram representing an example of an SBOM (Site Module Name) for software AA. SBOM 231AA contains the name of the software "AA", version information "2.3", and the vendor name of AA, "Company A", etc., of the object in SBOM 231AA. In particular, SBOM 231AA includes "AA@2.3" (tagId) as the SW (SW ID) determination information for AA. Furthermore, SBOM 231AA includes "BA@1.4" and "DA@3.1" (SWID) as the SW determination information for software components BA and DA used in AA. The SW determination information "BA@1.4" and "DA@3.1" for the software components BA and DA, which are libraries, is represented by the dashed lines.

[0082] In this example, there is an SBOM231BA that uses software BA with software CA. Figure 6B This is a diagram representing an example of an SBOM (Site Module Name) for software BA. SBOM 231BA contains the name of the software object "BA", version information "1.4", and the vendor name of BA, "Company B", etc. Specifically, SBOM 231BA contains "BA@1.4" (tagId), which is the SW (SWid) determination information for BA. Furthermore, SBOM 231BA contains the SW determination information "CA@4.0" (SWID) for the software component CA used in BA. The SW determination information "CA@4.0" for the software component CA, which is a library, is the portion enclosed by dashed lines.

[0083] return Figure 4 In the correspondence table 230, as the location information of SBOM231, the filenames of the SBOM231 used in the software of ECU300 are stored in a corresponding manner with the ECU determination information of ECU300. That is, the SBOM filenames "AA_sbom.xml" and "BA_sbom.xml" correspond to the ECU determination information "XY35125". The SBOM filename "AB_sbom.xml" corresponds to the ECU determination information "FD143". The SBOM filenames "AC_sbom.xml" and "BC_sbom.xml" correspond to the ECU determination information "YD54F". The SBOM filename "AD_sbom.xml" corresponds to the ECU determination information "CC9624". The SBOM filename "AE_sbom.xml" corresponds to the ECU determination information "SGI565X".

[0084] The acquisition unit 222 refers to each SBOM 231 and retrieves the SW determination information of the target SW as the SW determination information of the SW currently in use (i.e., as the SWID in the example above). For example, if a vulnerability is found in version 4.0 of software CA, the user, in order to determine whether the ECU 300 is using software CA, enters the SW determination information "CA@4.0" as the object of the SW usage query. The acquisition unit 222 uses the SW determination information "CA@4.0" as the search keyword to search each SBOM 231 and determines that "CA@4.0" exists in the SWID of SBOM 231BA.

[0085] Next, the acquisition unit 222 obtains the SW determination information "BA@1.4" of the software BA of the SBOM231BA that was retrieved with "CA@4.0". The acquisition unit 222 refers to the correspondence table 230 and obtains the ECU determination information "XY35125" corresponding to the file name "BA_sbom.xml" of the SBOM231BA that was matched by the SW determination information "CA@4.0". The acquisition unit 222 confirms whether the SBOM corresponding to the ECU determination information "XY35125" exists outside of SBOM231BA and determines the existence of SBOM231AA (file name "AA_sbom.xml").

[0086] The acquisition unit 222, referring to SBOM 231AA, performs a string search using the SW determination information "BA@1.4" of the BA that uses the object SW "CA@4.0" as the search keyword. The acquisition unit 222 determines that "BA@1.4" exists in the SWID of SBOM 231AA. Furthermore, the acquisition unit 222 obtains the SW determination information "AA@2.3" of the software AA that is the object of SBOM 231AA from the SBOM 231AA that retrieved "BA@1.4". Thus, it is determined that AA uses BA, and BA uses CA as the object SW.

[0087] The acquisition unit 222 refers to the corresponding table 230 and obtains the ECU determination information "XY35125" corresponding to the file name "AA_sbom.xml" of SBOM231AA that was matched by the SW determination information "BA@1.4".

[0088] As described above, the acquisition unit 222 acquires the ECU determination information "XY35125" of the ECU 300A with the user SW "CA@4.0" and the SW determination information "AA@2.3" of the software AA.

[0089] The acquisition unit 222 searches for other SBOMs 231 in the same manner as described above, and obtains the ECU determination information "YA54F" of the ECU 300C with the user SW "CA@4.0" and the SW determination information "AC@2.0" of the software AC, and obtains the ECU determination information "SGI565X" of the ECU 300E with the user SW "CA@4.0" and the SW determination information "AE@3.2" of the software AE.

[0090] return Figure 4 The output unit 223 outputs the ECU determination information of the ECU 300 of the target SW and the SW determination information of the software of the target SW, which are obtained by the acquisition unit. However, the output unit 223 only needs to output the ECU determination information of the ECU 300 of the target SW, and does not necessarily need to output the SW determination information of the software of the target SW.

[0091] In a specific example, the output unit 223 sends the ECU determination information of the ECU 300 using the target SW and the SW determination information of the software using the target SW, which are obtained by the acquisition unit. That is, the output unit 223 sends the ECU determination information of the ECU 300 using the target SW and the SW determination information of the software using the target SW as an inquiry result to the diagnostic device 370, which is the inquiry source. The diagnostic device 370 is able to display the received ECU determination information and SW determination information.

[0092] The update data acquisition unit 211 acquires update data for updating application software, which is the host software. For example, during the update... Figure 1 In the case of software AA, the update data acquisition unit 211 acquires update data for AA. The update data may include, for example, the code of the updated application.

[0093] For example, server 500 manages the updates of application software for ECU 300. When server 500 stores new update data for the application software of each vehicle in its storage unit, it provides (downloads) the update data to the relay ECU 200 of the vehicle equipped with the ECU 300 that has the application software installed. Update data acquisition unit 211 obtains the update data by downloading it from server 500.

[0094] For example, server 500 manages the application software installed in the ECU of each vehicle. That is, server 500 stores a correspondence between the vehicle's identification information (hereinafter also referred to as "vehicle ID") and the identification information (or SW determination information) of the application software installed in the ECU of that vehicle. Update data acquisition unit 211, for example, periodically or upon request from server 500, sends the vehicle ID of the vehicle equipped with relay ECU 200 to server 500. Upon receiving the vehicle ID, server 500 determines the application software corresponding to that vehicle ID and checks whether update data exists. If update data exists, server 500 sends the update data to the relay ECU 200 that sent the vehicle ID.

[0095] 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 sends the received update data to the target ECU 300, instructing it to update the application software. The ECU 300 updates its application software using the received update data according to the update instruction.

[0096] When the application is updated, its SBOM 231 is also updated. Therefore, server 500 stores the new (updated) SBOM (hereinafter also referred to as the "new SBOM") along with the update data. Server 500 sends the update data and sends the new SBOM to relay ECU 200. Update data acquisition unit 211 receives the new SBOM corresponding to the updated application software along with the update data.

[0097] The update control unit 212 updates the SBOM 231 using a new SBOM. Specifically, the update control unit 212 rewrites the existing SBOM 231 into a new SBOM.

[0098] [5. Operation of the relay ECU]

[0099] Next, the operation of the relay ECU 200 in the embodiment will be described. First, in a new, unused vehicle (before sale), the SBOM 231 is not imported into the relay ECU 200. Therefore, the SBOM 231 is imported into the vehicle's relay ECU 200. The server 500 stores the SBOM 231 in correspondence with the vehicle ID as part of the information of the application used in that vehicle.

[0100] Figure 7This is a timing diagram illustrating an example of SBOM import processing performed by a relay ECU and a server. The server 500, for example, sends a request for a vehicle ID via broadcast (step S101). If the processor 201 of the relay ECU 200 installed in the new vehicle receives the vehicle ID request, it sends the vehicle ID of its own vehicle to the server 500 (step S102).

[0101] Server 500 sends SBOM 231 corresponding to the received vehicle ID (step S103). The entire SBOM is divided into multiple frames and sent. Hereinafter, the frames of the divided SBOM will also be referred to as "SBOM data".

[0102] Processor 201 writes all received SBOM data into non-volatile memory 202. Upon completion of the write operation, processor 201 sends a write completion notification to server 500. This concludes the SBOM import process.

[0103] Next, the update control process for the application software will be explained. Figure 8 This is a flowchart illustrating an example of application software update control processing performed by a relay ECU.

[0104] As described above, when the application's new update data is stored on server 500, server 500 will send the update data or new SBOM to relay ECU 200.

[0105] When the processor 201 of the relay ECU 200 receives data sent 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 transmits the received data to the ECU 300 to which the update is intended (step S203). After the data transmission, the processor 201 returns to step S201.

[0106] If the received data is SBOM data (yes in step S202), the processor 201 temporarily stores the received SBOM data in a buffer area set in the volatile memory 203 (step S204). The processor 201 determines whether SBOM 231 is complete (step S205). If SBOM 231 is not complete (no in step S205), the processor 201 returns to step S201.

[0107] If SBOM231 is completed (yes in step S205), processor 201 determines whether it has received a notification that the update process is complete from the ECU 300 to be updated (step S206). The ECU 300 to be updated executes the application software update process according to the update data. If the update process is complete, i.e., if the update is successful or fails, it notifies the relay ECU 200 that the update process is complete.

[0108] If the update process is not completed, that is, if no notification of the end of the update process is received (no in step S206), the processor 201 executes step S206 again.

[0109] Upon completion of the update process, i.e., upon receiving an update process completion notification (Yes in step S206), the processor 201 determines whether the update was successful (step S207). The update process completion notification contains 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.

[0110] If the update is successful (Yes in step S207), the processor 201 reads the new SBOM 231 formed by combining the 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). The application software update control process ends here.

[0111] Next, the information provision process will be explained, which retrieves the ECU 300 of the target SW based on the query from the diagnostic device 370 and provides the retrieval results to the user. Figure 9 This is a timing diagram illustrating an example of information provision processing performed by the relay ECU and diagnostic device.

[0112] If a vulnerability is found in a certain software, the user connects the diagnostic device 370 to the connector 410 and inputs a SW usage query containing SW determination information of the software into the diagnostic device 370. The diagnostic device 370 sends the input SW usage query to the relay ECU 200. The processor 201 of the relay ECU 200 receives the SW usage query (step S301).

[0113] The processor 201 uses the SW determination information of the object SW specified in the SW usage query as the search keyword to perform a string search on the SBOM 231. When the SW determination information is found in the SBOM 231, the processor 201 obtains the ECU determination information of the ECU 300 corresponding to the SBOM 231 and the SW determination information of the application software from the correspondence table 230 (step S302).

[0114] The processor 201 sends the search results, which include the retrieved ECU determination information and SW determination information, to the diagnostic device 370. The diagnostic device 370 receives the search results (step S303).

[0115] The diagnostic device 370 displays the search results, namely the ECU determination information of the ECU 300 of the target SW and the SW determination information of the application software of the target SW (step S304). The information provision process is now complete.

[0116] [6. Variations]

[0117] In the above embodiments, the use of SBOM231 as the structure for dependency information is described, but it is not limited to this. The dependency information only needs to contain information for determining the software used in the application software, and it does not have to be an SBOM.

[0118] In the above embodiment, a structure is described in which the relay ECU 200 sends ECU determination information of the ECU 300 using the software to be questioned and SW determination information of the application software to the diagnostic device 370 based on an inquiry from the diagnostic device 370, but it is not limited to this. For example, a SW usage inquiry containing the input SW determination information may be sent from an external terminal (such as a smartphone) to the relay ECU 200, and the relay ECU 200 sends the ECU determination information of the ECU 300 using the software to be questioned and SW determination information of the application software to the terminal. The terminal may also display the received ECU determination information and SW determination information. As another example, the ECU 300 connected to an in-vehicle display may send a SW usage inquiry containing the input SW determination information to the relay ECU 200, and the relay ECU 200 sends the ECU determination information of the ECU 300 using the software to be questioned and SW determination information of the application software to that ECU 300. The ECU 300 may also cause the display to show the received ECU determination information and SW determination information. As another example, an in-vehicle or external device may send a SW usage query containing SW determination information to the relay ECU 200. The relay ECU 200 then sends the ECU determination information of the ECU 300 whose software is being queried, as well as the SW determination information of the application software, to the device. Alternatively, the device may not display the received ECU determination information and SW determination information, but instead use them for information processing such as vehicle diagnostics.

[0119] In the above embodiments, the structure by which the relay ECU 200 obtains ECU determination information of the ECU 300 using the software of the inquiry target and SW determination information of the application software is described, but it is not limited to this. For example, an ECU 300 that does not have frame relay function can also obtain (retrieve) ECU determination information of the ECU 300 using the software of the inquiry target and SW determination information of the application software.

[0120] In the above embodiments, SBOM231 is determined by the filename, but it is not limited to this. For example, in the absence of an OS that uses a file system, the storage location of each SBOM231 in the non-volatile memory 202 (e.g., the starting address of the storage location and the data size) can be stored in a corresponding table, and SBOM231 can be determined according to the storage location in the non-volatile memory 202.

[0121] [7. Postscript]

[0122] The embodiments disclosed herein are illustrative in all respects and are not restrictive. The scope of this disclosure is defined not by the above-described embodiments but by the claims, and includes all modifications within the scope and equivalent meaning of the claims.

[0123] Label Explanation

[0124] 10. Vehicle-mounted systems

[0125] 100 vehicle network

[0126] 200 Relay ECU (Relay Device, Software Information Management Device)

[0127] 201 processor

[0128] 202 Non-volatile memory

[0129] 203 Volatile Memory

[0130] 204A, 204B, 204C Communication Interfaces (Communication I / F)

[0131] 205 bus

[0132] 210 Update control program

[0133] 211 Update Data Acquisition Department

[0134] 212 Update Control Department

[0135] 220 Information Management Procedure

[0136] 221 Reception Department

[0137] 222 Acquisition Department

[0138] 223 Output Section

[0139] 230 Correspondence Table

[0140] 231 SBOM

[0141] 300 ECU (On-board Unit)

[0142] 350 External communication device

[0143] 370 Diagnostic Device

[0144] 400A, 400B, 400C bus

[0145] 410 connector

[0146] 500 server.

Claims

1. A software information management device, wherein, The software information management device includes: The storage unit establishes a corresponding storage of vehicle device determination information and software determination information for the software used in the vehicle device. The receiving department provides information on the software identification of the recipient. The acquisition unit acquires vehicle device determination information from the storage unit that corresponds to the software determination information of the object software received by the acceptance unit; and The output unit outputs the vehicle-mounted device determination information obtained by the acquisition unit.

2. The software information management device according to claim 1, wherein, The storage unit establishes a correspondence between the vehicle-mounted device determination information and the software determination information of the lower-level software used in the upper-level software mounted on the vehicle-mounted device. The object software is the lower-level software.

3. The software information management device according to claim 2, wherein, The storage unit establishes corresponding storage for the vehicle-mounted device determination information, the first software determination information, and the second software determination information. The first software determination information determines the upper-level software installed on the vehicle-mounted device, and the second software determination information determines the lower-level software used in the upper-level software. The acquiring unit also acquires the first software determination information corresponding to the second software determination information of the target software accepted by the receiving unit. The output unit also outputs the first software determination information obtained by the acquisition unit.

4. The software information management device according to claim 2 or claim 3, wherein, The storage unit stores dependency information, which includes second software determination information for determining the lower-level software used in the upper-level software. The storage unit establishes and stores the vehicle device determination information, the first software determination information, and the dependency relationship information in a corresponding manner. The acquiring unit determines the dependency information, which includes the second software determination information received by the receiving unit, and acquires the vehicle device determination information corresponding to the determined dependency information.

5. The software information management device according to claim 4, wherein, The software information management device also includes: The update data acquisition unit acquires update data for updating the host software; and The update control unit controls the update of the host software based on the update data obtained by the update data acquisition unit. The update data acquisition unit acquires the new dependency information corresponding to the updated host software along with the update data.

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

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

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

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

10. A software information management method, wherein, The software information management method includes the following steps: Software identification information for the software being accepted; The storage unit obtains vehicle device determination information corresponding to the software determination information of the accepted object software from the storage unit, and the storage unit establishes a correspondence between the vehicle device determination information determining the vehicle device and the software determination information determining the software used in the vehicle device; and Output the obtained vehicle-mounted device determination information.

11. A software information management program, wherein, The software information management program is used to enable the computer to perform the following steps: Software identification information for the software being accepted; The storage unit obtains vehicle device determination information corresponding to the software determination information of the accepted object software, and stores the vehicle device determination information that determines the vehicle device and the software determination information that determines the software used in the vehicle device in a corresponding manner. and Output the obtained vehicle-mounted device determination information.

Images