Network setting estimation device, network setting estimation method, and program

Abstract

A network setting estimation device that estimates setting information of an internal network in a target device, includes a diagnostic communication transmitting / receiving section that transmits a message to an electronic control device on the internal network using a diagnostic communication method supported in a standard manner in the electronic control device, and receives a response to the message, and a setting information estimation section that estimates setting information of the internal network based on the response acquired by the diagnostic communication transmitting / receiving section.

Description

Technical Field

[0001] This invention relates to a technique for estimating configuration information of an internal network in a target device such as a car. Background Technology

[0002] In recent years, with the advent of the connected car society, the threat of cyberattacks on automobiles has also increased. That is, through the connectivity functions installed in cars, cars can connect to the outside world via the network, which in turn increases the threat of cyberattacks from the outside.

[0003] Therefore, it is crucial to detect cyberattacks on vehicles, determine their attack paths and causes, and implement post-attack countermeasures. To correctly identify the attack path and cause, information related to the vehicular network (NW) configuration (topology), information processing devices (IVI, TCU, etc.) on the NW, and electronic control units (ECUs) is necessary.

[0004] In addition, vehicle configuration information is also necessary for various purposes such as asset management and abnormal detection of settings (also known as configuration).

[0005] As a prior art for estimating the settings of an NW, there is, for example, the technology disclosed in Non-Patent Document 1. In the technology disclosed in Non-Patent Document 1, SNMP is used to obtain the MAC address forwarding table of each switch within the target NW, and then the L2 topology of the target NW is estimated by analyzing the obtained information.

[0006] [Cited Documents]

[0007] [Non-patent documents]

[0008] [Non-patent document 1] Jing Jiang, Xiao Xu, Ning Cao, "Research on improved physical topology discovery based on SNMP," In 2017 IEEE International Conference on Computational Science and Engineering (CSE) and IEEE Conference on Embedded and Ubiquitous Computing (EUC), pp. 219-222, (2017) Summary of the Invention

[0009] [Technical problem to be solved]

[0010] To obtain the topology of the vehicle's NW and information about each ECU, the SNMP-based method disclosed in Non-Patent Document 1 can be used. However, to use the SNMP-based method to obtain the topology of the vehicle's NW and information about each ECU, resource enhancement (strengthening / addition) and SNMP support are required so that the SNMP agent's operation can be performed relative to each ECU, thus increasing additional costs.

[0011] The present invention was made in view of the above-mentioned problems, and its object is to provide a technique for estimating the configuration information of an internal network without enhancing the resources of the configuration device of the internal network in the target device and supporting new protocols.

[0012] [Technical Solution]

[0013] According to the disclosed technology, a network configuration estimation apparatus is provided for estimating configuration information of an internal network in a target device, comprising:

[0014] The diagnostic communication transceiver unit uses a diagnostic communication method supported in a standard manner in the electronic control device on the internal network to send messages to the electronic control device on the internal network and receives responses to those messages; and

[0015] The setting information estimation unit estimates the setting information of the internal network based on the response obtained by the diagnostic communication transceiver unit.

[0016] [Beneficial Effects]

[0017] According to the disclosed technology, the configuration information of the internal network can be estimated without enhancing the resources of the configuration device of the internal network in the target device or supporting new protocols. Attached Figure Description

[0018] [ Figure 1 A schematic diagram illustrating an example of vehicle settings information.

[0019] [ Figure 2 [Illustrative diagram of an example of diagnostic communication.]

[0020] [ Figure 3 [Schematic diagram of a configuration example of the setting information estimation system of the first embodiment.]

[0021] [ Figure 4 This is a flowchart illustrating an example of the processing steps for diagnosing the communication transceiver unit.

[0022] [ Figure 5 This is a flowchart illustrating an example of the processing steps for setting up the information estimation unit.

[0023] [ Figure 6 [System configuration diagram of Embodiment 1 of the first implementation]

[0024] [ Figure 7 [System configuration diagram of Embodiment 2 of the first embodiment]

[0025] [ Figure 8 [System configuration diagram of Embodiment 3 of the first embodiment]

[0026] [ Figure 9 [System configuration diagram of Embodiment 4 of the first embodiment]

[0027] [ Figure 10 [System configuration diagram of Embodiment 5 of the first embodiment.]

[0028] [ Figure 11 [System configuration diagram of Embodiment 6 of the first embodiment.]

[0029] [ Figure 12 A diagram illustrating an example of vehicle settings information.

[0030] [ Figure 13 [A schematic diagram of the network of the car as a premise in the second embodiment.]

[0031] [ Figure 14 [Illustrative diagram of the objective of basic technology 1]

[0032] [ Figure 15 [Illustrative diagram of the application objects of basic technology 1]

[0033] [ Figure 16 Diagram illustrating RTT in diagnostic communication.

[0034] [ Figure 17 A diagram illustrating the estimation method of Basic Technique 1.

[0035] [ Figure 18 A diagram illustrating the estimation steps of basic technique 1.

[0036] [ Figure 19 A diagram illustrating the estimation steps of basic technique 1.

[0037] [ Figure 20 A diagram illustrating the estimation steps of basic technique 1.

[0038] [ Figure 21 [Illustrative diagram of the objective of Basic Technology 2]

[0039] [ Figure 22A diagram illustrating the key points and steps of Basic Technique 2.

[0040] [ Figure 23 [Illustrative diagram of the prior art related to basic technology 3]

[0041] [ Figure 24 [Illustrative diagram of the objective of basic technology 3]

[0042] [ Figure 25 [Illustrative diagram of the estimation method for basic technique 3]

[0043] [ Figure 26 [Illustrative diagram of the estimation method for basic technique 3]

[0044] [ Figure 27 [Configuration diagram of Embodiment A1 of the second embodiment.]

[0045] [ Figure 28 The flowchart of the overall process of Embodiment A1 in the second embodiment.

[0046] [ Figure 29 [Flowchart of the S1030 process in Embodiment A1 of the second embodiment.]

[0047] [ Figure 30 [Flowchart of the process of S1031 in Embodiment A1 of the second embodiment.]

[0048] [ Figure 31 [A schematic diagram of Table 3031 of Embodiment A1 of the second embodiment.]

[0049] [ Figure 32 [Flowchart of the processing of S1032 in Embodiment A1 of the second embodiment.]

[0050] [ Figure 33 [Flowchart of the processing of S1033 in Embodiment A1 of the second embodiment.]

[0051] [ Figure 34 [A schematic diagram of Table 3032 of Embodiment A1 of the second embodiment.]

[0052] [ Figure 35 [Flowchart of the processing of S1034 in Embodiment A1 of the second embodiment.]

[0053] [ Figure 36 [A schematic diagram of Table 3033 of Embodiment A1 of the second embodiment.]

[0054] [ Figure 37 [Flowchart of the processing of S1035 in Embodiment A1 of the second embodiment.]

[0055] [ Figure 38[A schematic diagram of Table 3034 of Embodiment A1 of the second embodiment.]

[0056] [ Figure 39 [A schematic diagram of Table 3035 of Embodiment A1 of the second embodiment.]

[0057] [ Figure 40 [A schematic diagram of Table 3036 of Embodiment A1 of the second embodiment.]

[0058] [ Figure 41 [Flowchart of S1036 of Embodiment A1 of the second embodiment.]

[0059] [ Figure 42 [A schematic diagram of Table 3037 of Embodiment A1 of the second embodiment.]

[0060] [ Figure 43 [Flowchart of S1037 of Embodiment A1 of the second embodiment.]

[0061] [ Figure 44 [Flowchart of S1038 of Embodiment A1 of the second embodiment.]

[0062] [ Figure 45 [A schematic diagram of Table 3038 of Embodiment A1 of the second embodiment.]

[0063] [ Figure 46 [Flowchart of S1039 of Embodiment A1 of the second embodiment.]

[0064] [ Figure 47 [A schematic diagram of Table 3039 of Embodiment A1 of the second embodiment.]

[0065] [ Figure 48 [Flowchart of S1040 process in Embodiment A1 of the second embodiment.]

[0066] [ Figure 49 [Flowchart of the processing of S1061 in Embodiment A1 of the second embodiment.]

[0067] [ Figure 50 [A schematic diagram of Table 3081 of Embodiment A1 of the second embodiment.]

[0068] [ Figure 51 [Flowchart of the processing of S1091 in Embodiment A1 of the second embodiment.]

[0069] [ Figure 52 [Flowchart of the S1101 process in Embodiment A1 of the second embodiment.]

[0070] [ Figure 53[Flowchart of the S1111 process in Embodiment A1 of the second embodiment.]

[0071] [ Figure 54 [A schematic diagram of Table 3111 of Embodiment A1 of the second embodiment.]

[0072] [ Figure 55 The table referred to when explaining the sum of support degrees of Embodiment A1 of the second embodiment.

[0073] [ Figure 56 [A schematic diagram of Table 3112 of Embodiment A1 of the second embodiment.]

[0074] [ Figure 57 [A schematic diagram of Table 3113 of Embodiment A1 of the second embodiment.]

[0075] [ Figure 58 [Flowchart of the S1120 process in Embodiment A1 of the second embodiment.]

[0076] [ Figure 59 [Flowchart of the S1121 process in Embodiment A1 of the second embodiment.]

[0077] [ Figure 60 [A schematic diagram of an example of recording (storing / saving) the trace route in Embodiment A1 of the second implementation.]

[0078] [ Figure 61 [Flowchart of the S1122 process in Embodiment A1 of the second embodiment.]

[0079] [ Figure 62 A schematic diagram showing the one-to-one correspondence between the ECU model and the physical ECU in Embodiment A1 of the second implementation.

[0080] [ Figure 63 [A schematic diagram of the network interface configuration in Embodiment A1 of the second embodiment.]

[0081] [ Figure 64 [A schematic diagram of the allocation of ECU information in Embodiment A1 of the second embodiment.]

[0082] [ Figure 65 [A schematic diagram of the connection relationship in Embodiment A1 of the second embodiment.]

[0083] [ Figure 66 [Flowchart of the S1130 process in Embodiment A1 of the second embodiment.]

[0084] [ Figure 67 [Flowchart of the S1141 process in Embodiment A1 of the second embodiment.]

[0085] [ Figure 68 [A schematic diagram of the recording of the sending and receiving times in Embodiment A1 of the second implementation]

[0086] [ Figure 69 [A schematic diagram of Table 3141 of Embodiment A1 of the second embodiment.]

[0087] [ Figure 70 [Flowchart of the S1151 process in Embodiment A1 of the second embodiment.]

[0088] [ Figure 71 [Flowchart of the S1152 process in Embodiment A1 of the second embodiment.]

[0089] [ Figure 72 [A schematic diagram of the recording of the sending and receiving times in Embodiment A1 of the second implementation]

[0090] [ Figure 73 [A schematic diagram of Table 3151 of Embodiment A1 of the second embodiment.]

[0091] [ Figure 74 [Flowchart of the S1161 process in Embodiment A1 of the second embodiment.]

[0092] [ Figure 75 [A schematic diagram of Table 3161 of Embodiment A1 of the second embodiment.]

[0093] [ Figure 76 [A schematic diagram of Table 3162 of Embodiment A1 of the second embodiment.]

[0094] [ Figure 77 [Flowchart of the processing of S1171 in Embodiment A1 of the second embodiment.]

[0095] [ Figure 78 A schematic diagram showing the one-to-one correspondence between the ECU model and the physical ECU in Embodiment A1 of the second implementation.

[0096] [ Figure 79 [A schematic diagram of adding a request NW_A-ID to the ECU in Embodiment A1 of the second embodiment.]

[0097] [ Figure 80 [Flowchart of the S1172 process in Embodiment A1 of the second embodiment.]

[0098] [ Figure 81 [A schematic diagram of the estimation results of the NW_A topology of Embodiment A1 in the second embodiment.]

[0099] [ Figure 82A schematic diagram of Example A1 of the second embodiment, showing the appending of EUC information to the NW_A topology.

[0100] [ Figure 83 [A schematic diagram of the connection between GWs in Embodiment A1 of the second embodiment.]

[0101] [ Figure 84 [Flowchart of the S1180 process in Embodiment A1 of the second embodiment.]

[0102] [ Figure 85 [Flowchart of the S1191 process in Embodiment A1 of the second embodiment.]

[0103] [ Figure 86 [Flowchart of the S1192 process in Embodiment A1 of the second embodiment.]

[0104] [ Figure 87 [A schematic diagram of the recording of the ECUReset transmission time in Embodiment A1 of the second implementation]

[0105] [ Figure 88 [Flowchart of the S1201 process in Embodiment A1 of the second embodiment.]

[0106] [ Figure 89 [A schematic diagram of the recording of the alarm time of NW_A-IDS in Embodiment A1 of the second embodiment.]

[0107] [ Figure 90 [Flowchart of the S1211 process in Embodiment A1 of the second embodiment.]

[0108] [ Figure 91 [A schematic diagram of Table 3211 of Embodiment A1 of the second embodiment.]

[0109] [ Figure 92 [A schematic diagram of the result after the addition of Example A1 in the second embodiment.]

[0110] [ Figure 93 [A schematic diagram of Table 3212 of Embodiment A1 of the second embodiment.]

[0111] [ Figure 94 [Configuration diagram of embodiment A2 of the second embodiment.]

[0112] [ Figure 95 [Configuration diagram of embodiment A3 of the second embodiment.]

[0113] [ Figure 96 [Configuration diagram of embodiment A4 of the second embodiment.]

[0114] [ Figure 97[Configuration diagram of embodiment A5 of the second embodiment.]

[0115] [ Figure 98 [Configuration diagram of embodiment A6 of the second embodiment.]

[0116] [ Figure 99 [Configuration diagram of embodiment A7 of the second embodiment.]

[0117] [ Figure 100 [Configuration diagram of embodiment B1 of the second embodiment.]

[0118] [ Figure 101 [Configuration diagram of embodiment B2 of the second embodiment.]

[0119] [ Figure 102 [Configuration diagram of embodiment B3 of the second embodiment.]

[0120] [ Figure 103 [Configuration diagram of embodiment B4 of the second embodiment.]

[0121] [ Figure 104 [Configuration diagram of embodiment C1 of the second embodiment.]

[0122] [ Figure 105 [Configuration diagram of embodiment C2 of the second embodiment.]

[0123] [ Figure 106 [Configuration diagram of embodiment C3 of the second embodiment.]

[0124] [ Figure 107 [Configuration diagram of embodiment C4 of the second embodiment.]

[0125] [ Figure 108 A schematic diagram of the hardware configuration example of the device. Detailed Implementation

[0126] The embodiments of the present invention (this embodiment) will now be described with reference to the accompanying drawings. It should be noted that the embodiments described below are merely examples, and the embodiments applicable to the present invention are not limited to those described below.

[0127] In the embodiments described below (the first and second embodiments), a car is used as an example of a target device with setting information, namely an internal network. However, the target device to which the technology of the present invention can be applied is not limited to a car. The technology of the present invention can also be applied to target devices that, like cars, have the characteristic of "being able to obtain information from devices on the network through diagnostic communication" (Note: In this text and the accompanying drawings, "" is equivalent to ""). Furthermore, the basic technology described in the second embodiment can be applied to at least objects having the conditions described for its application.

[0128] In this embodiment, the settings (configuration) of the in-vehicle network (NW), information related to the information processing devices (IVI, TCU, etc.) on the NW, and information related to the electronic control unit (ECU) are sometimes collectively referred to as "vehicle setting information". "Vehicle setting information" is an example of "internal network setting information".

[0129] It should be noted that TCU is an abbreviation for Telematics Control Unit, IVI is an abbreviation for In-Vehicle Infotainment, and ECU is an abbreviation for Electronic Control Unit.

[0130] In the following description (and accompanying diagrams), CAN (registered trademark) will be referred to as NW_A (Network A), and Ethernet (registered trademark) will be referred to as NW_B (Network B). It should be noted that CAN (registered trademark) is an abbreviation for Controller Area Network.

[0131] However, NW_A in the following description can also refer to networks other than CAN (registered trademark), and similarly, NW_B can refer to networks other than Ethernet (registered trademark). For example, NW_A can also refer to FlexRay (registered trademark), LIN, K-Line, etc.

[0132] In this embodiment, a method for estimating the network configuration information of a target vehicle will be described. The network configuration information of the target vehicle may be, for example, the information described below.

[0133] • Topology of the target network (vehicle-mounted NW_B and vehicle-mounted NW_A)

[0134] • Information related to devices connected to the network (model, software version, etc.)

[0135] Information related to the function (=name) of each device.

[0136] • Information on normal communications conducted by each device (especially information on normal communications sent by each device)

[0137] The first and second embodiments, which are embodiments of the present invention, will now be described. The first embodiment describes the basic configuration and operation, while the second embodiment describes a more specific configuration and operation. Furthermore, the configuration and processing described in the first embodiment and the configuration and processing described in the second embodiment may be implemented in combination.

[0138] ―――――――――First Implementation――――――――――

[0139] (Example of vehicle settings information)

[0140] In this embodiment, the setting information estimation system estimates the vehicle setting information of the car. Figure 1 An example of vehicle settings information is shown. Figure 1 In this example, the TCU and IVI connected to NW_B are connected to the GW (Gateway-ECU) in a star configuration. Additionally, NW_A is connected to the GW, and the ECU connected to NW_A is connected to NW_A via a bus configuration. Furthermore, Figure 1 Information about each ECU, etc., is also displayed. Figure 1 The OBD-II shown is a self-diagnostic function.

[0141] In the following text, information processing devices (IVI, TCU, etc.) and electronic control devices (ECU) will be collectively referred to as "ECU". The same applies to the second embodiment.

[0142] (Regarding diagnostic communications)

[0143] In this embodiment, the setting information estimation system collects and analyzes information obtained through diagnostic communication to estimate vehicle setting information. This diagnostic communication is supported in a standard manner in devices such as ECUs installed in automobiles. It should be noted that diagnostic communication is implemented on almost all automobile ECUs. This diagnostic communication will be described here.

[0144] Diagnostic communication is used during ECU fault diagnosis and reprogramming. Furthermore, diagnostic communication can also be used to obtain information such as the ECU model and software version. See also Figure 2 An example of the steps for diagnostic communication is provided. Figure 2 An example of diagnostic communication between an external diagnostic device (external diagnostic unit) _A and an ECU _B is shown.

[0145] In step S1, an external diagnostic device A sends a diagnostic request to ECU B. In step S2, ECU B executes the processing corresponding to the diagnostic request. In step S3, ECU B sends a diagnostic response (also called a reply or answer) back to the external diagnostic device A. The diagnostic response includes the results of the processing.

[0146] (System Configuration)

[0147] Figure 3 An example configuration of the setting information estimation system of this embodiment is shown. For example... Figure 3As shown, the configuration information estimation system of this embodiment includes a diagnostic communication transceiver unit 100, a diagnostic system log DB 200, and a configuration information estimation unit 300. The configuration information estimation unit 300 includes an ECU presence check unit 310, a topology estimation unit 320, an ECU information extraction unit 330, and an output unit 340. A summary of each functional unit is described below.

[0148] The diagnostic communication transceiver unit 100 performs diagnostic communication (receiving and sending) according to the flowchart described later, and saves the received response to the diagnostic system log DB 200.

[0149] The diagnostic system log DB 200 is a database that stores logs obtained by the diagnostic communication transceiver unit 100 in a predetermined format.

[0150] Regarding the setting information estimation unit 300, by operating each internal block according to the flowchart described later, vehicle setting information can be estimated using information stored in the diagnostic system log DB 200. It should be noted that the input to the setting information estimation unit 300 can also use information other than the diagnostic system log. For example, publicly known information related to configuration and logs from non-diagnostic systems can also be used.

[0151] It should be noted that, as described in Embodiments 1 to 6 below, the diagnostic communication transceiver 100, the diagnostic system log DB 200, and the setting information estimation unit 300 can be implemented in one or more devices in various ways. A device equipped with the diagnostic communication transceiver 100 and the setting information estimation unit 300 can be referred to as a network setting estimation device. In this network setting estimation device, the diagnostic communication transceiver 100 and the setting information estimation unit 300 can be configured to be located at remote, separate locations and communicate with each other via a network.

[0152] Furthermore, the device equipped with the setting information estimation unit 300 may also be referred to as a network setting estimation device, which estimates the setting information using the response obtained by the diagnostic communication transceiver unit 100.

[0153] (Diagnostic operation of the communication transceiver unit)

[0154] Next, an operational example of the diagnostic communication transceiver unit 100 will be explained. First, UDS, DID, and DoIP, which appear in the process described later, will be explained.

[0155] UDS is an abbreviation for Unified Diagnostic Services, which is the name of a standard specification (such as ISO 14229-1) used to define the form (format) of diagnostic messages in diagnostic communications.

[0156] DID is short for Data ID, which is the ID set in the diagnostic request (request message) of UDS, indicating the object of the diagnostic service. For example, as a DID, after sending a diagnostic request with a DID set to specify the software version number to the ECU, the ECU can return a diagnostic response (response message) with the software version number set.

[0157] In addition, there is a standard specification called ISO 15765-2, which specifies the network layer for implementing UDS on NW-A.

[0158] DoIP is an abbreviation for Diagnostic Communication over Internet Protocol, which is the name of the standard specifications (ISO 13400-1 and ISO 13400-2) that define the network layer specifications for implementing UDS over IP.

[0159] In DoIP, for example, Figure 1 As shown, the following configuration is possible: only the ECUs that require high-speed data forwarding communicate with the gateway ECU, which serves as a diagnostic function (tester), on NW_B. Other ECUs connect to the gateway ECU via the vehicle network such as NW_A and perform diagnostics through the gateway ECU.

[0160] In this embodiment, the diagnostic communication transceiver unit 100 and the ECU perform diagnostic communication at least according to the general standard specifications described above.

[0161] See Figure 4 The flowchart illustrates an operational example of the diagnostic communication transceiver unit 100. It should be noted that, in the reference... Figure 4 The content and order of messages sent and received in the described operational example are merely one example, and the present invention is not limited thereto.

[0162] In S101, the diagnostic communication transceiver unit 100 broadcasts the Vehicle Identification Request of DoIP to the ECUs connected to NW_B and receives responses from each ECU. The Vehicle Identification Request is a message used to request address information from the ECUs connected to NW_B.

[0163] In S102, the diagnostic communication transceiver unit 100 sends a testerPresent message for the UDS to each ECU connected to the NW_A and receives a response. The testerPresent message is used to confirm the presence of the ECU connected to the NW_A and the NW_A-ID (i.e., CAN-ID).

[0164] In S103, the diagnostic communication transceiver unit 100 sends DoIP EntityStatus Requests to each ECU connected to the vehicle NW_B and receives responses. Entity Status Requests are messages used to request node types (e.g., gateways) from the ECUs.

[0165] In S104, the diagnostic communication transceiver 100 sends a ReadDataByIdentifier containing one or more values ​​of DID to each ECU connected to the vehicle NW_B and vehicle NW_A, and receives a response. The ReadDataByIdentifier is a message used to request data specified by the DID from the ECU.

[0166] The DIDs used in S104 are, for example, 0xF181, 0xF183, 0xF184, 0xF188, 0xF189, 0xF18A, 0xF194, 0xF195, 0xF19F, 0xF18B, 0xF18C, 0xF184, 0xF191, 0xF192, 0xF193, and 0xF19F. However, these are merely examples, and the present invention is not limited thereto.

[0167] 0xF181 represents applicationSoftwareIdentificationDataIdentifier. 0xF183 represents bootSoftwareFingerprintDataIdentifier. 0xF184 represents applicationSoftwareFingerprintDataIdentifier. 0xF188 represents vehicleManufacturerECUSoftwareNumberDataIdentifier. 0xF189 represents vehicleManufacturerECUSoftwareVersionNumberDataIdentifier. 0xF18A represents systemSupplierIdentifierDataIdentifier. 0xF194 represents systemSupplierECUSoftwareNumberDataIdentifier. 0xF195 represents systemSupplierECUSoftwareVersionNumberDataIdentifier. 0xF19F represents EntityDataIdentifier. 0xF18B represents ECUManufacturingDateDataIdentifier. 0xF18C represents ECUSerialNumberDataIdentifier. 0xF184 represents applicationSoftwareFingerprintDataIdentifier. 0xF191 represents vehicleManufacturerECUHardwareNumberDataIdentifier. 0xF192 represents systemSupplierECUHardwareNumberDataIdentifier. 0xF193 indicates systemSupplierECUHardwareVersionNumberDataIdentifier. 0xF19F represents EntityDataIdentifier.

[0168] (Example of setting up an information estimation department)

[0169] The responses received to the requests sent to the ECU in S101 to S104 above are stored in the diagnostic system log DB200. The setting information estimation unit 300 estimates the setting information of the target device's internal network by reading data from the diagnostic system log DB200.

[0170] See below Figure 5 The flowchart illustrates an example of the estimation and knowledge (understanding) operations performed by the setting information estimation unit 300. It should be noted that the order and content of the estimation and knowledge described herein are merely one example, and the present invention is not limited to the example described herein.

[0171] <s201>

[0172] In S201, the ECU presence verification unit 310 verifies the presence of the ECU. Specifically, it is described below.

[0173] The ECU presence confirmation unit 310 confirms the presence of the ECU connected to the NW_B and its address information based on the response to the Vehicle Identification Request (DoIP) broadcast to the ECU connected to the NW_B. In other words, if address information is received as a response to the Vehicle Identification Request, it can be estimated that an ECU with that address information exists on the NW_B.

[0174] Furthermore, the ECU presence confirmation unit 310 also confirms the presence of the ECUs connected to the NW_A and their NW_A-IDs based on the response to the testerPresent of the UDS sent to each ECU connected to the NW_A. In other words, if an NW_A-ID is received as a response to the testerPresent, it can be estimated that an ECU with that NW_A-ID exists on the NW_A.

[0175] Furthermore, the ECU presence confirmation unit 310 can also confirm the existence of the Gateway-ECU and its address information based on the response to the Entity Status Request of the DoIP. In other words, if a response of node type Gateway is received as a response to the Entity Status Request, it can be estimated that the Gateway-ECU exists.

[0176] <s202>

[0177] In S202, the topology estimation unit 320 estimates the topology of the internal network of the target device (here, a car). Specifically, it is described below.

[0178] The topology estimation unit 320 estimates the configuration of an ECU connected on NW_B in a star connection to a switch.

[0179] For example, the topology estimation unit 320 can confirm the existence of a Gateway-ECU (which can also function as a Switch) based on the confirmation result of S201, and that an ECU exists on NW_B. Based on this, it can estimate that the internal network has a configuration where the ECU connected to NW_B is connected to a Switch in a star topology. Such an estimation can be performed, for example, according to predefined rules.

[0180] Furthermore, the topology estimation unit 320 estimates that NW_A is connected to the Gateway-ECU. For example, the topology estimation unit 320 can confirm the existence of the Gateway-ECU and the existence of an ECU connected to NW_A based on the confirmation result of S201, and thus estimate that NW_A is connected to the Gateway-ECU. Such estimation can be performed, for example, according to a predefined rule.

[0181] Furthermore, the topology estimation unit 320 also estimates that the ECU connected to NW_A is connected to NW_A under the Gateway-ECU via a bus connection. For example, based on the estimation result that NW_A is connected to the Gateway-ECU and known information about the connection method of the ECU to NW_A (e.g., a bus connection), the topology estimation unit 320 can estimate that the ECU connected to NW_A is connected to NW_A under the Gateway-ECU via a bus connection. Such estimation can be performed, for example, according to predefined rules.

[0182] <s203>

[0183] In S203, the ECU information extraction unit 330 extracts ECU information. Specifically, it is described below.

[0184] The ECU information extraction unit 330 obtains the ECU information (VIN, model, software version, etc.) of each ECU based on the response to the UDS's ReadDataByIdentifier. The DID of the UDS's ReadDataByIdentifier is set to 0xF181, 0xF183, 0xF184, 0xF188, 0xF189, 0xF18A, 0xF194, 0xF195, 0xF19F, 0xF18B, 0xF18C, 0xF184, 0xF191, 0xF192, 0xF193, and 0xF19F (these DIDs are just examples).

[0185] <s204>

[0186] In S204, the output unit 340 outputs the information obtained from S201 to S203. For example, the output unit 340 generates information based on the information obtained from S201 to S203, such as... Figure 1 The output unit 340 can output (display) the graphic image shown. Furthermore, the output unit 340 can also output the information obtained from S201 to S203 in the form of a list and / or natural language. Additionally, it can output natural language audio.

[0187] Figure 3 The setting information estimation system of this embodiment shown can be implemented in various ways. Examples 1 to 6, which are implementation methods of this embodiment, will be described below.

[0188] (Example 1)

[0189] Figure 6 This is a configuration diagram of the setting information estimation system in Embodiment 1. For example... Figure 6 As shown, in Embodiment 1, an external device having all the functions of the setting information estimation system, namely the diagnostic communication transceiver unit 100, the diagnostic system log DB200, and the setting information estimation unit 300, is connected to the vehicle 400.

[0190] Regarding the connection method of connecting an external device to a vehicle 400, it can be a method of physically connecting the external device to the vehicle 400, or a method of implementing the external device on a network such as a cloud and remotely connecting the external device on the network to the vehicle 400.

[0191] (Example 2)

[0192] Figure 7 This is a configuration diagram of the setting information estimation system in Embodiment 2. In Embodiment 2, a diagnostic communication transceiver device having a diagnostic communication transceiver unit 100 and a setting information estimation device having a diagnostic system log DB 200 and a setting information estimation unit 300 are connected to the vehicle 400.

[0193] Figure 7 The example illustrates a configuration where the diagnostic communication transceiver is physically connected to the vehicle 400, and the configuration information estimation device is configured in the cloud and connected to the diagnostic communication transceiver via a network. It should be noted that this connection method is merely one example, and the locations of the diagnostic communication transceiver and the configuration information estimation device are not limited to any specific location.

[0194] (Example 3)

[0195] Figure 8 This is a configuration diagram of the setting information estimation system in Embodiment 3. Embodiment 3 is an example of a diagnostic system log DB 200 within the diagnostic communication transceiver in the configuration of Embodiment 2.

[0196] It should be noted that in Embodiments 2 and 3, the diagnostic system log DB 200 can be configured outside the diagnostic communication transceiver or the setting information estimation device rather than inside these devices.

[0197] (Example 4)

[0198] Figure 9 This is a configuration diagram of the setting information estimation system in Embodiment 4. In Embodiment 4, a processing device for implementing all functions from the diagnostic communication transceiver unit 100 to the setting information estimation unit 300 is configured on the vehicle-mounted NW. That is, as shown... Figure 9 As shown, the interior of the vehicle 400 includes a processing unit with a diagnostic communication transceiver unit 100, a diagnostic system log DB 200, and a setting information estimation unit 300.

[0199] It should be noted that the aforementioned processing device in the vehicle 400 can be physically connected and configured within the vehicle's NW (New Vehicle Wiring System), or it can be implemented on any ECU. In other words, one or more ECUs can have a diagnostic communication transceiver unit 100, a diagnostic system log DB 200, and a setting information estimation unit 300.

[0200] (Example 5)

[0201] Figure 10 This is a configuration diagram of the setting information estimation system in Embodiment 5. In Embodiment 5, the vehicle 400 has a processing unit that performs processing on the on-board computer (NW), and this external device is connected to the vehicle 400. Figure 10 As shown, the processing unit includes a diagnostic communication transceiver unit 100, and the external device includes a diagnostic system log DB 200 and a setting information estimation unit 300.

[0202] It should be noted that, regarding the processing device, it can be physically connected and configured within the vehicle's NW (New Vehicle Wiring System), or it can be implemented on any ECU (Electronic Control Unit). Furthermore, regarding the connection method for external devices, it can be either physically connected to the vehicle 400, or the external device can exist as a network device such as a cloud device and be remotely connected to the vehicle 400.

[0203] (Example 6)

[0204] Figure 11 This is a configuration diagram of the setting information estimation system of Embodiment 6. Embodiment 6 is an example of a processing device in the configuration of Embodiment 5 that includes a diagnostic system log DB 200.

[0205] It should be noted that in Embodiments 5 and 6, the diagnostic system log DB 200 can be configured outside the processing device or external device rather than inside these devices.

[0206] ―――――――――Second Implementation――――――――――

[0207] Next, the second embodiment will be described.

[0208] (Example of vehicle settings information)

[0209] In the second embodiment, the vehicle setting information of the car is also estimated by the setting information estimation system. Figure 12 An example of vehicle settings information is shown. Figure 12 The vehicle network topology, ECU information (two tables), and normal communication (the box enclosed by thick lines in the table on the right) constitute the vehicle's configuration information. It should be noted that this information falls within the scope of basic technologies 1-3 described later.

[0210] The second embodiment also uses diagnostic communication in the same way as the first embodiment. Diagnostic communication is described in [reference needed]. Figure 2 The description is the same.

[0211] (On the internet about cars)

[0212] The vehicle network, as a prerequisite in the second embodiment, is shown below. Figure 13 .like Figure 13 As shown, in this network, one OBD-II port is connected to both the NW_A bus and the vehicle-mounted NW-B. Diagnostic communication (1) and (2) can be performed from one OBD-II port.

[0213] (1) Diagnostic communication with the ECU connected to the NW_A can be performed using only the NW_A (without via SW). Alternatively, the onboard NW_B can be used from OBD-II to GW, and the NW_A can be used after GW for diagnostic communication with the ECU connected to the NW_A.

[0214] (2) For the ECU connected to the vehicle NW_B, diagnostic communication is performed only using the vehicle NW_B (without via SW).

[0215] (Regarding basic techniques)

[0216] Here, the basic technology of the second embodiment will be explained. The basic technology of the second embodiment is (1) to (3) as described below. It should be noted that in (4) and (5), the technology described in the first embodiment is referred to as basic technology 4 and basic technology 5.

[0217] (1) Techniques for estimating the topology of NW_A (Basic Technique 1)

[0218] (2) Technique for determining the normal (non-diagnostic) NW_A-ID (000~6FF) sent by the ECU connected to NW_A (Basic Technique 2)

[0219] (3) Techniques for estimating the functions (=names) of each ECU (Basic Technique 3)

[0220] (4) Technology for acquiring ECU information from each ECU (Basic Technology 4)

[0221] (5) Techniques for estimating the topology of NW_B (Basic Technique 5)

[0222] The basic technologies 1 to 3 of the second embodiment will be described below.

[0223] (Basic Technique 1)

[0224] <Primary technologies and problems related to basic technology 1>

[0225] The prior art related to basic technology 1 is the technology disclosed in Non-Patent Document 1. As described above, in the technology disclosed in Non-Patent Document 1, SNMP is used to obtain the MAC address forwarding table of each switch within the target NW, and the obtained information is analyzed to estimate the L2 topology of the target NW.

[0226] However, in order to obtain the topology of the NW_A bus using the SNMP-based method as described in Non-Patent Document 1, each ECU needs to perform resource enhancements and SNMP support to enable the operation of the SNMP agent, which will increase the additional cost.

[0227] <Key Points and Effects of Basic Technique 1>

[0228] Basic Technique 1 also utilizes diagnostic communication transceivers that are standardly used in most automobiles. Specifically, the topology of the NW_A bus is estimated using the RTT (Real-Time Tolerance) of diagnostic communication when a particular bus's occupancy is forcibly increased (congestion). Details of this technique will be described later.

[0229] The diagnostic communication protocol is a standard protocol supported in each ECU. Therefore, according to this technology, the topology of the NW_A bus can be estimated without incurring additional costs such as resource enhancement and support for new protocols.

[0230] <Target and Application of Basic Technique 1>

[0231] In Basic Technique 1, the objective is to identify ECUs connected to the same NW_A bus. For example, in Figure 14 In the configuration shown, the information described below is estimated.

[0232] ECU-A and ECU-B are connected to the same bus.

[0233] ECU-A and ECU-C are connected to different buses.

[0234] ECU-B and ECU-C are connected to different buses.

[0235] Basic technology 1 is applied to objects that have a bus with a domain architecture, such as... Figure 15 The diagram shows an object with multiple buses under the GW. The GW can route diagnostic communications to the appropriate bus. For example, diagnostic communications with an NW_A-ID corresponding to ECU-A can be sent from the GW only to the bus to which ECU-A is connected.

[0236] Key Points Regarding the Estimation Method for Basic Technique 1

[0237] As described above, in basic technique 1, the topology of NW_A is estimated using the RTT (Round Trip Time) of diagnostic communication when the occupancy of a particular bus is forcibly increased (congestion).

[0238] See Figure 16 The definition of RTT in diagnostic communication is explained. It should be noted that... Figure 16 An example of diagnostic communication from a PC to an ECU-A is shown. The RTT of diagnostic communication refers to the time from when the PC starts sending a diagnostic request (S1) to an ECU until the PC finishes receiving the diagnostic response (S2) from the ECU.

[0239] Here, as Figure 17 As shown, it is assumed that only bus 1 becomes congested. When only bus 1 is congested, the RTT for diagnostic communication with the ECU connected to bus 1 is larger compared to the case where there is no congestion. On the other hand, the RTT for diagnostic communication with the ECU connected to bus 2 remains unchanged compared to the case where there is no congestion. In Basic Technique 1, this phenomenon can be used to estimate the topology.

[0240] <Summary of the estimation steps in Basic Technique 1>

[0241] See Figures 18-20 A summary of the estimation steps for basic technique 1 is provided. First, as... Figure 18 As shown, several diagnostic requests are sent to ECU-B and ECU-C to view (investigate) the average RTT of each ECU-B and ECU-C. Figure 18 (and Figure 19 , Figure 20 The lower left corner shows an image of the average RTT for ECU-B and ECU-C respectively.

[0242] Next, as Figure 19 As shown, diagnostic requests are sent to ECU-A frequently (at high frequency), thereby increasing the occupancy of the bus connected to ECU-A and ECU-B. Figure 19 The example shows that the bus occupancy rate is 99%.

[0243] Next, as Figure 20 As shown, when the bus connected to ECU-A becomes congested, several diagnostic requests are sent to ECU-B and ECU-C to investigate (check) the average RTT of ECU-B and ECU-C.

[0244] like Figure 20 As shown in the lower left, if the average value of the RTT statistics increases compared to the non-congested state (lower left figure), it can be determined that the ECU and ECU-A are connected to the same bus. Figure 20 In the example, it can be determined that "ECU-A and ECU-B are connected to the same bus".

[0245] (Basic Technique 2)

[0246] Next, we will explain basic technology 2.

[0247] <Existing technologies and problems related to basic technology 2>

[0248] As prior art related to basic technology 2, there is "Sekar Kulandaivel, Tushar Goyal, Arnav Kumar Agrawal, and Vyas Sekar, "CANvas: Fast and Inexpensive Automotive Network Mapping," In the Proceedings of the 28th USENIX Security Symposium, pp. 389-405, (2019)."

[0249] In this prior art, the NW_A characteristic of "the ECU stops sending messages (bus disconnects) after a certain number of abnormal collisions in the messages sent by the ECU)" is utilized to determine all NW_A-IDs of the NW_A messages sent by an ECU.

[0250] Specific examples of the method based on this prior art are described below.

[0251] While an ECU-A on the NW_A bus sends an NW_A message with NW_A-ID=0x300, an estimation device connected to the NW_A bus also sends an NW_A message with NW_A-ID=0x300.

[0252] This causes a conflict in the NW_A message, resulting in NW_A-ID = 0x300. By repeating this conflict, ECU-A can be disconnected from the bus (bus offline).

[0253] After ECU-A is disconnected from the bus, all NW_A messages with NW_A-ID sent from ECU-A, including NW_A-ID=0x300 (e.g., other 0x301, 0x302), also stop.

[0254] The NW_A-ID of the NW_A messages sent by ECU-A can be determined by checking the NW_A-ID of the NW_A messages that are no longer being sent by the estimating device. In this example, it is determined that "ECU-A sent NW_A messages with NW_A-ID = 0x300, 0x301, 0x302".

[0255] However, the aforementioned prior art has the following problems.

[0256] In recent years, the OBD-II port, which is used to access the vehicle's NW_A bus, has been configured in most cars to only perform diagnostic communication. On the other hand, in the aforementioned prior art, to prevent NW_A message collisions, it is necessary to be able to send non-diagnostic communication to the vehicle's NW_A bus. Therefore, it is difficult to implement the aforementioned prior art using the common approach of "using the OBD-II port".

[0257] Key Points and Effects of Basic Technique 2

[0258] In basic technique 2, diagnostic communication is used to disrupt the transmission cycle of the NW_A message of the target ECU, and the disruption of the NW_A message transmission cycle is detected by the NW_A-IDS. Then, the detection result is correlated with the information of the target ECU, thereby determining the NW_A-ID of the NW_A message sent by the ECU.

[0259] According to this technology, most cars in recent years can be targeted, and the NW_A-ID of the NW_A message sent by the ECU can be determined by using the OBD-II port.

[0260] <Target and Application of Basic Technique 2>

[0261] In basic technology 2, for example, such as Figure 21 As shown, the normal NW_A-ID (000~6FF) sent by the ECU connected to NW_A is associated with the diagnostic NW_A-ID (700~7FF), and by extension, the goal is to associate it with ECU information.

[0262] In Basic Technology 2, the premise is that an IDS exists on the target NW and monitors normal messages. The IDS issues an alarm when the interval between normal message transmissions is shorter / longer than the design value and / or when the payload undergoes abnormal changes. The IDS alarm contains information about the messages detected as abnormal (NW_A-ID in the automotive example). Furthermore, the vehicle setting estimation device can acquire the IDS alarm in any manner.

[0263] <Key Points and Steps of the Estimation Method for Basic Technique 2>

[0264] See Figure 22 The processing steps for the key points of basic technology 3 are explained.

[0265] (1) Use ECUReset (e.g., by using NW_A-ID=7E0) to disrupt the periodicity and / or payload variation of the normal NW_A-ID (e.g., NW_A-ID=300) message transmission sent by the target ECU.

[0266] (2) Cause NW_A-IDS to issue an alarm. For example, the alarm contains NW_A-ID=300.

[0267] (3) After that, it is determined that "the NW_A-ID contained in the alarm is a normal NW_A-ID sent by the target ECU".

[0268] (Basic Technique 3)

[0269] Next, we will explain basic technology 3.

[0270] <Existing technologies and problems related to basic technology 3>

[0271] As a prior art related to basic technology 3, there is "X. Feng, et al: Acquisitional Rule-based Engine for Discovering Internet-of-Things Devices. USENIX (2018)". In this prior art, information (device category, supplier, model) of IoT devices is specified by using response information collected from IoT devices and web crawling and scraping techniques.

[0272] More specifically, in this existing technology, keyword A extracted from the response of an IoT device can yield multiple web crawling / scraping results B. In the automotive example, suppose an ECU model such as "12345-67890" can be obtained from an ECU. In this case, A = 12345-67890. Furthermore, the crawling / scraping results using A are as follows... Figure 23 As shown.

[0273] In this prior art, the following confidence level is calculated with the multiple results B as the target.

[0274]

[0275] Then, the result with the highest confidence level is extracted as a single result. Figure 23 In the example, A = 12345 - 67890, according to 67 can be used to extract B = Engine Module.

[0276] The aforementioned prior art has the following problems.

[0277] If the entire ECU model is used as a keyword for crawling and scraping, there are many cases where the ECU's function cannot be estimated because the search results do not exist.

[0278] Furthermore, when extracting the results with the highest confidence levels as described in the existing techniques, there are also cases where results with less information are selected. For example, in... Figure 23 In this case, the "Hybrid Engine Module" contains a large amount of information, so it is desirable to extract this result. However, under the aforementioned prior art, when obtaining... Figure 23 When retrieving the results (table), the "EngineModule" that appeared most frequently was selected.

[0279] <Key Points and Effects of Basic Technique 3>

[0280] As a key point of basic technology 3, it has the following key points 1 and 2.

[0281] Key point 1 is that the crawling results, which only use the bits representing the function, are also used according to the naming rules of ECU models. Key point 2 is that the sum of the support of the words contained in each web crawling result is extracted as the result with the highest support.

[0282] This technology avoids situations where the function (name) of an ECU cannot be estimated due to a lack of search results. Furthermore, it outputs highly reliable results with a wealth of information.

[0283] <Target and Application of Basic Technique 3>

[0284] In basic technique 3, the goal is to estimate the function (name) of each ECU (including the NW_B connection). For example, Figure 24 In the example shown, estimations are made for "ECU-X is IVI", "ECU-Y is TCU", and "ECU-A is engine ECU". Furthermore, in Basic Technology 3, information for uniquely identifying the device can be obtained; in the case of a car, for example, the "ECU model" can be obtained.

[0285] <Key Points and Steps of the Estimation Method for Basic Technique 3>

[0286] First, a summary of the estimation method for Basic Technology 3 will be given. In Basic Technology 3, the function (name) is determined using ECU model information obtained through diagnostic communication and web crawling / scraping techniques. Figure 25 The outline is shown below. Points 1 and 2 above will be explained in detail below.

[0287] <Key Point 1>

[0288] In point 1, the web crawling and scraping results, which only use bits related to the function of the ECU model, are also used according to the naming rules of the ECU model.

[0289] Most ECU model numbers use a structure that combines bits representing functional information with bits representing the vehicle model year. When the bits representing functional information are set to ○ and the bits representing the vehicle model year are set to △, an ECU model number structure like the one described below exists.

[0290] ·○○○○○-△△△△△

[0291] ·△△△-○○○○○○-△

[0292] As stated in Point 1, the reasons for reducing the number of instances where no search results are found by using only the function-related bits are as follows.

[0293] Searching using the condition "all bits of the ECU model are identical" means searching for ECUs that are "equipped in vehicles of the specified model year" and have "the specified function". On the other hand, searching using the condition "only the bits indicating the function of the ECU model are identical" means searching for ECUs with "the specified function". In other words, since fewer restrictions are required when searching, the chances of finding no results can be reduced.

[0294] The method for extracting function-related bits is not limited to a specific extraction method; however, for example, any one of the extraction methods 1 to 3 described below can be used.

[0295] Extraction Method 1)

[0296] In extraction method 1, the function-related bits are determined based on the publicly available "ECU model naming rules information". For example, if the naming rules are published on the official website of the car manufacturer, the function-related bits can be determined based on that published information.

[0297] Extraction Method 2)

[0298] In extraction method 2, only ECU models related to a specific function are extracted and analyzed, and the function-related bits are determined based on the analysis results. For example, if only ECU models related to the engine ECU are extracted and analyzed, there are bits whose values ​​do not change regardless of the ECU model. These bits can be identified as function-related bits.

[0299] Extraction method 3)

[0300] In extraction method 3, the ECU model number of the ECU installed in a certain car is extracted and analyzed, and the function-related bits are determined based on the analysis results. For example, if the ECU model number of the ECU installed in a car is extracted and analyzed, there are bits whose values ​​remain unchanged regardless of the ECU model. Since this bit can be considered as a bit indicating the vehicle type rather than a bit indicating the function, the bits other than this bit can be determined as function-related bits.

[0301] <Key Point 2>

[0302] In point 2 of basic technique 3, the result with the highest sum of word support among the web crawling and fetching results is extracted. Specifically, it is described below.

[0303] When estimating the function (name) of the ECU with model number "12345-67890", it is assumed that the following information is obtained: Figure 26 The results of the web crawling / scraping are shown below. Figure 26 For each word X contained in the given word, calculate the support sup(X).

[0304] sup(X) = (Number of results containing X) / (Number of all web crawling / fetching results)

[0305] Next, the sum of the support scores of the words in each line is calculated, and the result with the largest sum is extracted as a single result. Figure 26 In the example, the Hybrid Engine Module was extracted. Here, sup(Engine) = 1, sup(Module) = 1, sup(Hybrid) = 0.3, and sup(Hybrid) = 2.3.

[0306] (Example)

[0307] The specific device configuration and operation of the second embodiment, as an example, will now be described. A summary of each embodiment is as follows.

[0308] A. Examples of embodiments from the perspective of combining basic technologies

[0309] • Example A1: Example of a combination of the most basic technologies (detailed description of the processing flow)

[0310] • Examples A2-A4: Examples using each basic technology alone

[0311] • Examples A5-A7: Examples of partial combinations of basic technologies

[0312] B. Examples of embodiments from the perspective of physical deployment of functions

[0313] • Example B1: An example of deploying the functionality of the present invention on an in-vehicle NW

[0314] • Example B2: Example of directly connecting the functions of the present invention to the OBD-II port

[0315] • Example B3: An embodiment in which the functions of the present invention are performed from the charging port

[0316] It should be noted that, for B1 to B3, the parts other than the vehicle-mounted NW1 and message transceiver unit 23 described later can also be extracted and deployed on the cloud.

[0317] • Example B4: Example C: An example of an embodiment of the invention being estimated by deploying the functionality of the invention on an external network. (Example from the perspective of the objective)

[0318] • Example C1: Example for performing security analysis in a SOC (Security Operation Center), etc.

[0319] • Example C2: Example for Asset Management

[0320] • Example C3: Example for performing anomaly detection

[0321] • Example C4: Example for safety diagnostics

[0322] It should be noted that, in actual implementation, the embodiments of A and B described above can be combined. For example, embodiment A1 can be implemented through the functional deployment of embodiment B1, and then used for the purpose described in C. The embodiments are described below.

[0323] (Example A1)

[0324] Implementation A1 is an embodiment of the most basic combination of core technologies. Here, as an example, the physical deployment of Implementation B2 is assumed and described accordingly.

[0325] <Device Configuration (Block Diagram)>

[0326] Figure 27 This diagram illustrates the configuration of the setting information estimation system in Embodiment A1. Figure 27 As shown, the setting information estimation system includes a setting element estimation unit 2 and a setting information estimation result DB 22. The setting element estimation unit 2 may be referred to as a vehicle setting estimation device or a network setting estimation device. The setting information estimation system may be referred to as a setting information estimation device. The setting element estimation unit 2 is connected to the vehicle-mounted NW1 and the Web site 7 (Web server) and can communicate with them.

[0327] The setting element estimation unit 2 includes an ECU basic information acquisition unit 3, an ECU function estimation unit 4, an NW_B topology estimation unit 12, an NW_A bus topology estimation unit 13, a normal NW_A communication estimation unit 18, a message transceiver unit 23, and a setting information acquisition and registration unit 24.

[0328] The ECU function estimation unit 4 includes a Web search unit 6, a search result database (DB) 8, a complete consistency extraction unit 9, a specific part consistency extraction unit 10, and an estimation unit 11. It should be noted that the "complete consistency extraction unit 9, specific part consistency extraction unit 10, and estimation unit 11" can also be collectively referred to as the estimation unit.

[0329] The NW_A bus topology estimation unit 13 includes a basic RTT calculation unit 14, a congestion RTT calculation unit 15, an RTT comparison unit 16, and an estimation unit 17. It should be noted that the "RTT comparison unit 16 and estimation unit 17" can also be collectively referred to as the estimation unit.

[0330] The normal (usual) NW_A communication estimation unit 18 includes a restart command sending unit 19, a vehicle alarm receiving unit 20, and an estimation unit 21.

[0331] The operation of the device will be explained below with reference to the flowchart. In the following description, it should be noted that the message transceiver unit 23 is used to send and receive messages with the vehicle NW1 and the vehicle ECU.

[0332] <Overall Processing Flow>

[0333] See Figure 28 The overall processing flow of the information estimation system is described. It should be noted that... Figure 28 The processing order shown is only one example.

[0334] In S1030, the ECU basic information acquisition unit 3 acquires the ECU basic information. In S1040, the ECU function estimation unit 4 estimates the ECU function. In S1120, the NW_B topology estimation unit 12 estimates the NW_B topology. In S1130, the NW_A bus topology estimation unit 13 estimates the NW_A bus topology. In S1180, the normal NW_A communication estimation unit 18 estimates normal NW_A communication.

[0335] The following provides a detailed explanation of the processing steps.

[0336] <s1030>

[0337] See Figure 29 S1030 will be explained.

[0338] In S1030-1, the vehicle setting estimation device is connected to the OBD-II port (NW_B) of the vehicle NW1.

[0339] In S1030-2, the ECU basic information acquisition unit 3 executes S1031. In S1030-3, the ECU basic information acquisition unit 3 executes S1032. S1032 also executes S1033 and S1034.

[0340] In S1030-4, the ECU basic information acquisition unit 3 executes S1035. In S1030-5, the ECU basic information acquisition unit 3 disconnects the vehicle setting estimation device from the OBD-II port (NW_B) and connects it to the OBD-II port (NW_A).

[0341] In S1030-6, the ECU basic information acquisition unit 3 executes S1036. In S1030-7, the ECU basic information acquisition unit 3 executes S1037. S1038 is also executed in S1037. In S1030-8, the ECU basic information acquisition unit 3 executes S1039.

[0342] <s1031>

[0343] Next, see Figure 30 The processing of S1031 is explained.

[0344] In S1031-1, the ECU basic information acquisition unit 3 obtains the local IP address on the vehicle NW1 by means of AutoIP or DHCP in accordance with the DoIP specification.

[0345] In S1031-2, if the ECU basic information acquisition unit 3 receives the Vehicle Announcement broadcast by each ECU on the vehicle NW1 in accordance with the DoIP specification, it proceeds to S1031-5; if it does not receive it, it proceeds to S1031-3.

[0346] In S1031-3, the ECU basic information acquisition unit 3 broadcasts a Vehicle Identification Request (as specified by DoIP) on the vehicle-mounted NW1.

[0347] In S1031-4, each ECU on the vehicle-mounted NW1 returns a Vehicle Identification Response to the Vehicle Identification Request according to the DoIP specifications. The ECU basic information acquisition unit 3 receives the Vehicle Identification Response.

[0348] In S1031-5, the ECU basic information acquisition unit 3 saves information such as the sending source IP address contained in the received Vehicle Announcement and / or Vehicle Identification Response to a storage unit such as a memory. The stored information includes... Figure 31 As shown in Table 3031. It should be noted that the stored information is not limited to Table 3031.

[0349] <s1032>

[0350] Next, refer to Figure 32 to describe the processing of S1032. In S1032-1, the ECU basic information acquisition unit 3 declares (announces) the following variables.

[0351] · The list of IP addresses in Table 3031 stored in the previous step (S1031), "IP = [192.168.10.1, 192.168.10.2, 192.168.10.3]"

[0352] · The length of the IP list, "Length(IP)" (in this case, Length(IP) = 3)

[0353] · "DID = [0xF18C, 0xF190, 0xF191, 0xF194, 0xF195, 0xF19F]"

[0354] · The length of DID, "Length(DID)" (in this case, Length(DID) = 6)

[0355] · i = 0

[0356] It should be noted that the variable names can be different from those above. In addition, values other than IP addresses can be used to unify the content of IP. Values other than those above can also be added to DID.

[0357] In S1032-2, the ECU basic information acquisition unit 3 determines whether i < Length(IP). If it is Yes (true), it proceeds to S1032-3. If it is No (false), the processing ends.

[0358] In S1032-3, the ECU basic information acquisition unit 3 executes the processing of S1033. In S1032-4, the ECU basic information acquisition unit 3 executes the processing of S1034. In S1032-5, i = i + 1, and then it returns to S1032-2.

[0359] <s1033>

[0360] Next, see Figure 33 The processing of S1033 will be explained. In S1033-1, the ECU basic information acquisition unit 3 sends a DoIP Entity Status Request to the IP[i] on the vehicle NW1.

[0361] In S1033-2, the ECU with IP[i] on the vehicle-mounted NW1 returns a DoIP Entity Status Response to the DoIP Entity Status Request according to the DoIP specification. The ECU basic information acquisition unit 3 receives the DoIP Entity Status Response.

[0362] In S1033-3, the ECU basic information acquisition unit 3 saves the "Node type" and IP[i] contained in the received DoIP Entity Status Response to the storage unit. An example of the stored information is as follows: Figure 34 As shown in Table 3032.

[0363] <s1034>

[0364] Next, refer to Figure 35 The processing of S1034 will be described. In S1034-1, the ECU basic information acquisition unit 3 declares that the variable j = 0. It should be noted that the variable name can be different from j. In S1034-2, the ECU basic information acquisition unit 3 determines whether j < Length(DID) is satisfied. If it is Yes, it proceeds to S1034-3. If it is No, the processing ends.

[0365] In S1034-3, the ECU basic information acquisition unit 3 sends readDataByIdentifier (specified by UDS) with DID[j] set in DID to IP[i] and receives a response. In S1034-4, the ECU basic information acquisition unit 3 saves the dataRecord of the received response together with IP[i] and DID[j] to the storage unit. An example of the stored information is as Figure 36 (Table 3033) shows. In S1034-5, the ECU basic information acquisition unit 3 sets j = j + 1, and then returns to S1034-2.

[0366] <s1035>

[0367] Next, see Figure 37 S1035 will be explained. In S1035-1, the ECU basic information acquisition unit 3 acquires information according to the UDS specifications. Figure 36 The DID of (Table 3033) is changed to "Description", and the dataRecord is converted from ASCII (hexadecimal) to text (i.e., from ASCII (hexadecimal) to text). Figure 36 The results of the changes and conversions to (Table 3033) are as follows: Figure 38 As shown in Table 3034. It should be noted that the content described and the dataRecord conversion method are not limited to this.

[0368] In S1035-2, the ECU basic information acquisition unit 3 uses "IP address" and "ECU model" as a composite primary key pair. Figure 38 The data in Table 3034 was organized. The organized result is as follows: Figure 39 As shown in Table 3035. It should be noted that the method of summarizing is not limited to this.

[0369] In S1035-3, the ECU basic information acquisition unit 3 uses the "IP address" as a key pair. Figure 39 (Table 3035) Figure 31 (Table 3031) and Figure 34 (Table 3032) were combined. The results are as follows: Figure 40 As shown in Table 3036.

[0370] In S1035-4, the ECU basic information acquisition unit 3 will... Figure 40 The combination result of (Table 3036) is saved to the setting information estimation result DB 22 via the setting information acquisition and registration department 24.

[0371] <s1036>

[0372] Next, see Figure 41 S1036 will be explained. In S1036-1, the ECU basic information acquisition unit 3 sends TesterPresent requests sequentially to all diagnostic NW_A-IDs = 0x700 to 0x7FF and diagnostic extended NW_A-IDs (hereinafter referred to as "NW_A-IDs") in accordance with the DoCAN and UDS specifications.

[0373] In S1036-2, if a response occurs on the vehicle network in response to the TesterPresent request sent in the previous step, the ECU basic information acquisition unit 3 saves the NW_A-ID (request NW_A-ID) it sent to the storage unit. For example, if a response is received when a TesterPresent request with NW_A-ID = 700 is sent, then NW_A-ID = 700 and the NW_A-ID set in the response (response NW_A-ID) are stored. The result is as follows: Figure 42 As shown in Table 3037.

[0374] <s1037>

[0375] Next, refer to Figure 43 Describe S1037. In S1037-1, the ECU basic information acquisition unit 3 declares the following variables.

[0376] · The one stored in the previous step Figure 42 (Table 3037)'s requested NW_A-ID list "NW_A-ID = [0x700, 0x724, 0x750, 0x7E0, 0x7E1]"

[0377] · The length of the list "Length(NW_A-ID)" (in this example, Length(NW_A-ID) = 5)

[0378] · "DID = [0xF18C, 0xF190, 0xF191, 0xF194, 0xF195, 0xF??19F]"

[0379] · The length of DID "Length(DID)" (in this example, Length(DID) = 6)

[0380] · i = 0

[0381] It should be noted that the variable names can be different from the above. In addition, the content of NW_A-ID can also be unified by values other than NW_A-ID. Values other than the above can also be added to DID.

[0382] In S1037-2, confirm whether i < Length(NW_A-ID) is satisfied. If it is Yes, go to S1037-3. If it is No, end the process. In S1037-3, the ECU basic information acquisition unit 3 executes S1038. In S1037-4, set i = i + 1, and then return to S1037-2.

[0383] <s1038>

[0384] Next, refer to Figure 44 for the description of S1038. In S1038-1, the ECU basic information acquisition unit 3 declares that the variable j = 0. It should be noted that the variable name can be a variable name other than j.

[0385] In S1038-2, the ECU basic information acquisition unit 3 determines whether j < Length(DID) is satisfied. If it is Yes, it proceeds to S1038-3; if it is No, the process ends.

[0386] In S1038-3, the ECU basic information acquisition unit 3 sends readDataByIdentifier (specified by UDS) with DID[j] set in DID to NW_A-ID[i] and receives a response.

[0387] In S1038-4, the ECU basic information acquisition unit 3 saves the dataRecord of the received response together with NW_A-ID[i] (request NW_A-ID), the response NW_A-ID, and DID[j] to the storage unit. An example of the stored information is shown in Figure 45 (Table 3038). In S1038-5, j = j + 1 is set, and then it returns to S1038-2.

[0388] <s1039>

[0389] Next, see Figure 46 S1039 will be explained. In S1039-1, the ECU basic information acquisition unit 3 acquires information according to the UDS specifications. Figure 45 The DID of (Table 3038) is changed to "Description", and the dataRecord is converted from ASCII (hexadecimal) to text. It should be noted that the content of the description and the conversion method of the dataRecord are not limited to this.

[0390] In S1039-2, the ECU basic information acquisition unit 3 uses "NW_A-ID" and "ECU model" as composite primary keys to organize the data from the previous step. The organized result is as follows: Figure 47 As shown in Table 3039. It should be noted that the summarization method is not limited to this.

[0391] In S1039-3, the ECU basic information acquisition unit 3 will... Figure 47 The processing results of (Table 3039) are transmitted to the setting information estimation result DB 22 via the setting information acquisition and registration department 24.

[0392] <s1040>

[0393] Next, refer to Figure 48 Describe S1040. In S1040-1, the ECU function estimation unit 4 declares the following variables.

[0394] · A list of ECU models that do not duplicate with Figure 40 (Table 3036) and Figure 47 (Table 3039), obtained from the setting information estimation result DB 22 via the setting information acquisition and registration unit 24

[0395] · "PN = [11111-56789, 22222-56789, 33333-56789, 44444-56789, 55555-56789, 66666-56789, 77777-56789, 88888-56789]"

[0396] · The length of the PN list "Length(PN)" (in this example, Length(PN) = 8)

[0397] · i = 0

[0398] It should be noted that the variable name can be a variable name other than the above. In addition, the content of the IP can also be unified by a value other than the IP address.

[0399] In S1040-2, the ECU function estimation unit 4 determines whether i < Length(PN) is satisfied. If Yes, it proceeds to S1040-3. If No, the process ends. In S1040-3, S1061 is executed for PN[i]. In S1040-4, S1091 is executed for PN[i]. In S1040-5, S1101 is executed for PN[i]. In S1040-6, S1111 is executed for PN[i]. In S1040-7, i = i + 1, and then it returns to S1040-2.

[0400] [[ID=2 Nine]] <s1061>

[0401] Next, see Figure 49 S1061 will be explained. In S1061-1, the Web retrieval unit 6 crawls web pages using the ECU model number obtained from the setting information estimation result DB 22 as the search term. At this time, for the crawled web pages, a website suitable for retrieving the ECU's function (=name) based on the ECU model number is preferred. Furthermore, as search terms, two types can be used: the entire ECU model number and the function-related part of the ECU model number.

[0402] It should be noted that, regarding the function-related bits in the ECU model, the methods described in point 1 of the basic technique 3 above can be used for determination. It should also be noted that the methods used for determination are not limited to these.

[0403] In S1061-2, the Web retrieval unit 6 retrieves the ECU model and matching information of the function corresponding to the ECU model based on the web page crawled in the previous step.

[0404] In S1061-3, the Web retrieval unit 6 stores the matching information in past search results (i.e., historical search results) DB8. It should be noted that past search results DB8 may, for example, have... Figure 50 A DB structure like (Table 3081).

[0405] <s1091>

[0406] Next, see Figure 51 S1091 will be explained. In S1091, the complete match extraction unit 9 obtains matching information of ECU models that are completely identical from the search result DB 8.

[0407] <s1101>

[0408] Next, see Figure 52 S1101 will be explained. In S1101, the specific part consistency extraction unit 10 obtains the matching information of the function-related bits in the ECU model from the search result DB8.

[0409] <s1111>

[0410] Next, see Figure 53 S1111 is performed. In S1111-1, the estimation unit 11 segments the functional information in the pairing information obtained by the above steps according to each word. For example, if pairing information with a function such as "Genuine Engine ControlModule" is obtained, it can be segmented into four words: "Genuine", "Engine", "Control", and "Module".

[0411] In S1111-2, the estimation unit 11 deletes frequently occurring words that are not functionally relevant from the words segmented in the previous step. For example, in the case of the previous step, "Genuine" can be deleted. It should be noted that deletion may also be omitted.

[0412] In S1111-3, the estimation unit 11 calculates the support of each segmented word. Specifically, the support of word x can be calculated using the following formula. An example of the support calculation results is shown in... Figure 54 (Table 3111).

[0413] Support(x) = (Number of pairs containing x) / (Number of all pairs)

[0414] In S1111-4, the estimation unit 11 calculates the sum of the support levels of the words contained in the information of each pair of information. Then, it outputs the pair of information with the largest sum. It should be noted that, in addition to the sum, the average or product can also be selected as the pair of information with the largest sum.

[0415] As an example, regarding the basis Figure 55 The process and results of calculating the support examples shown are as follows.

[0416] 1. Gas Motor Module

[0417] The sum = 0.25 + 0.5 + 1.0 = 1.75

[0418] 2. Engine Motor Control Module

[0419] The sum = 0.75 + 0.5 + 0.75 + 1.0 = 3.0

[0420] 3. Engine Control Module

[0421] The sum = 0.75 + 0.75 + 1.0 = 2.5

[0422] 4. Engine Control Module

[0423] The sum = 0.75 + 0.75 + 1.0 = 2.5

[0424] The information for 2 has a maximum value, so the output should be the pairing information for 2. It should be noted that... Figure 55 The information regarding the pairing information on which the function is based is described below.

[0425] 1. Gas Motor Module

[0426] 2. Engine Motor Control Module

[0427] 3. Engine Control Module

[0428] 4. Engine Control Module

[0429] In S1111-5, the estimation unit 11 adds the labeled results (described below) to the setting information estimation result DB 22 via the setting information acquisition and registration unit 24. Figure 40 (Table 3036) or Figure 47 (Table 3039) contains rows with appropriate ECU models. An example of the results is shown in... Figure 56 (Table 3112) and Figure 57 (Table 3113). Regarding labeling (i.e., assigning labels), see below.

[0430] In this process, if "ECU model matching information that is completely identical" is used from search result DB 8, only the matching information with completely identical ECU models is processed. Then, the output result is labeled "Completely identical". Conversely, if "ECU model matching information that is partially identical" is used from search result DB 8, only the matching information with partially identical ECU models is processed. Then, the output result is labeled "Partially identical".

[0431] <s1120>

[0432] Next, see Figure 58 S1120 will be explained. In S1120-1, the NW_B topology estimation unit 12 executes S1121. In S1120-2, the NW_B topology estimation unit 12 executes S1122.

[0433] <s1121>

[0434] Next, refer to Figure 59 An explanation of S1121 will be given. In S1121-1, the NW_B topology structure estimation unit 12 declares the following variables.

[0435] · Obtained from the setting information estimation result DB 22 via the setting information acquisition and registration unit 24 Figure 54 (Table 3111) List of IP addresses "IP = [192.168.10.1, 192.168.10.2, 192.168.10.3]"

[0436] · Length of the IP list "Length(IP)" (in this example, Length(IP) = 3)

[0437] · i = 0

[0438] It should be noted that the variable names can be different from those above. In addition, values other than IP addresses can be used to unify the content of IP.

[0439] In S1121-2, the NW_B topology structure estimation unit 12 determines whether i < Length(IP) is satisfied. If Yes, it proceeds to S1121-3. If No, the process ends.

[0440] In S1121-3, the NW_B topology structure estimation unit 12 executes ICMP traceroute on IP[i] on the vehicle-mounted NW1 and saves the result in the storage unit. An example of the saved information is shown in Figure 60 In S1121-4, i = i + 1, and then it returns to S1121-2.

[0441] <s1122>

[0442] See Figure 61 S1122 will be explained.

[0443] In S1122-1, the NW_B topology estimation unit 12 obtains the setting information estimation result DB 22 from the setting information acquisition and registration unit 24. Figure 56 (Table 3112) All ECU model numbers are retrieved. Next, the NW_B topology estimation unit 12 removes duplicate ECU model numbers. Afterwards, the ECU model numbers after the duplicate ECU model numbers have been removed are mapped one-to-one with the physical ECUs. An example of the result is shown in... Figure 62 .

[0444] In S1122-2, the NW_B topology estimation unit 12 obtains the estimation result DB 22 from the setting information via the setting information acquisition and registration unit 24. Figure 56 The "ECU Model", "MAC Address", and "IP Address" in Table 3112 will add the network interface to... Figure 62 The information. The results are as follows: Figure 63 As shown.

[0445] In S1122-3, the NW_B topology estimation unit 12 obtains the information from the setting information estimation result DB 22 via the setting information acquisition and registration unit 24. Figure 56 All information in (Table 3112) is appropriately allocated to the ECU and / or the ECU's interface. The result is as follows: Figure 64 As shown.

[0446] In S1122-4, the NW_B topology estimation unit 12 estimates the data based on the traceroute record ( Figure 62 This document summarizes the connection relationships between the OBD-II port via NW_B cable, the ECU's network interface (and by extension, the physical ECU), and the IP router. It should be noted that when multiple ECUs exist under the same IP router, it can be assumed that these ECUs and the IP router are connected through an NW_B switch. Furthermore, when multiple ECUs exist on the vehicle network but no IP router is available, it can also be assumed that these ECUs are connected through an NW_B switch. The results are as follows... Figure 65 As shown. It should be noted that the method for organizing the connection relationships between ECUs is not limited to this.

[0447] In S1122-5, the NW_B topology estimation unit 12 will... Figure 65 The estimation results are saved to the setting information estimation results DB 22 via the setting information acquisition and registration department 24.

[0448] <s1130>

[0449] Next, see Figure 66 S1130, which is performed by the NW_A bus topology estimation unit 13, will be explained.

[0450] In S1130-1, the basic RTT calculation unit 14 executes S1141. In S1130-2, the congestion RTT calculation unit 15 executes S1151. In S1130-3, the congestion RTT calculation unit 15 executes S1152. In S1130-4, the RTT comparison unit 16 executes S1161. In S1130-5, the estimation unit 17 executes S1171. In S1130-6, the estimation unit 17 executes S1172.

[0451] <s1141>

[0452] Next, see Figure 67 S1141 will be explained.

[0453] In S1141-1, the basic RTT calculation unit 14 sends 100 TesterPresent requests, as specified by UDS, to NW_A-ID[i] at 200ms intervals. Then, it receives responses to these requests. Next, it stores these transmission and reception times in a storage unit. An example of the stored information is shown below. Figure 68 It should be noted that the sending interval and the number of sending attempts are not limited to these.

[0454] In S1141-2, the basic RTT calculation unit 14 uses the record from the previous step ( Figure 68 The statistical value of the response time (hereinafter also referred to as the basic response time) is calculated. Then, the calculation result is stored together with NW_A-ID[i] (e.g.: Figure 69 (Table 3141)). It should be noted that this will be achieved by requesting NW_A-ID (in... Figure 68 For example, the TesterPresent was sent at the time of 0x700 and subsequently via the NW_A-ID response (for example, 0x700). Figure 68 The basic response time is the difference between the time when TesterPresent is received (0x708). In addition, the mean, maximum, minimum, and standard deviation of the statistics are calculated. However, other statistical values ​​can also be calculated.

[0455] <s1151>

[0456] Next, refer to Figure 70 to describe S1151.

[0457] In S1151-1, the congestion RTT calculation unit 15 declares the following variables.

[0458] · A list "NW_A-ID = [0x700, 0x724, 0x750, 0x7E0, 0x7E1]" obtained from the setting information estimation result DB 22 via the setting information acquisition / registration unit 24 and sorted in ascending order of the requested NW_A-ID in Figure 57 (Table 3113)

[0459] · The length of the list "Length(NW_A-ID)" (in this example, Length(NW_A-ID) = 5)

[0460] · i = 0

[0461] It should be noted that the variable names can be other than those mentioned above. In addition, the content of NW_A-ID can also be unified by values other than NW_A-ID.

[0462] In S1151-2, the congestion RTT calculation unit 15 determines whether i < Length(NW_A-ID) is satisfied. If Yes, it proceeds to S1151-2; if No, the process ends. In S1151-3, j = i + 1.

[0463] In S1151-4, the congestion RTT calculation unit 15 determines whether j < Length(NW_A-ID) is satisfied. If Yes, it proceeds to S1151-5; if No, the process ends. In S1151-5, the congestion RTT calculation unit 15 executes S1152 and then returns to S1151-2.

[0464] <s1152>

[0465] Next, see Figure 71 S1152 will be explained.

[0466] In S1152-1, the congestion RTT calculation unit 15 continuously sends TesterPresent requests as specified by UDS to NW_A-ID[i] at 0.5ms intervals until the end of S1152, thereby causing congestion on the NW_A bus that sends the NW_A message of NW_A-ID[i]. It should be noted that the sending interval is not limited to this.

[0467] In S1152-2, the congestion RTT calculation unit 15 sends 100 TesterPresent requests, as specified by the UDS, to NW_A-ID[j] at 200ms intervals. Then, it receives the responses to these requests. Next, these transmission and reception times are stored in a storage unit. An example of the stored information is shown below. Figure 72 It should be noted that the sending interval and the number of sending attempts are not limited to these.

[0468] In S1152-3, the congestion RTT calculation unit 15 uses the records from the previous step to calculate the statistical value of the response time (hereinafter also referred to as the congestion response time). Then, the calculation result is compared with NW_A-ID[i]( Figure 73 In (Table 3151), NW_A-ID is referred to as congestion NW_A-ID and NW_A-ID[j]( Figure 73 In Table 3151, the statistical value calculation object (NW_A-ID) is stored together in the storage unit. An example of the stored information is shown below. Figure 73 (Table 3151).

[0469] It should be noted that the response time during congestion is the difference between the time when TesterPresent is sent by requesting NW_A-ID and the time when TesterPresent is received by responding to NW_A-ID. In addition, the average, maximum, minimum, and standard deviation of the statistics are calculated. However, other statistical values ​​can also be calculated.

[0470] <s1162>

[0471] Next, see Figure 74 S1161 will be explained.

[0472] In S1161-1, the RTT comparison unit 16 will, for a certain NW_A-ID = x, Figure 69 The statistical values ​​of NW_A-ID=x in (Table 3141) and Figure 73 The statistical values ​​in (Table 3151) are compared with the statistical values ​​of NW_A-ID = x. Then, from... Figure 73 (Table 3151) Extraction Figure 73 The statistical values ​​on the (Table 3151) side are all higher than those on the other side. Figure 69 (Table 3141) More than 50% more rows have been added. The extraction results are as follows: Figure 75 As shown in Table 3161. It should be noted that... Figure 75 The extraction method for (Table 3161) is not limited to this.

[0473] In S1161-2, there are 16 pairs of RTT comparators. Figure 75 (Table 3161) groups the congestion NW_A-ID and the statistical calculation object NW_A-ID of each row. For example, 0x700 and 0x724 are grouped together, 0x700 and 0x7E0 are grouped together, 0x724 and 0x7E0 are grouped together, and 0x750 and 0x7E1 are grouped together.

[0474] In S1161-3, the RTT comparison unit 16 summarizes the groups generated in the previous step as much as possible. For example, 0x700 and 0x724 are grouped together, 0x700 and 0x7E0 are grouped together, and 0x724 and 0x7E0 are grouped together; therefore, these three can be grouped together. The result is as follows: Figure 76 As shown in Table 3162.

[0475] <s1171>

[0476] Next, see Figure 77 S1171 will be explained.

[0477] In S1171-1, the estimation unit 17 estimates the result DB 22 stored in the setting information, which is equivalent to... Figure 56 Extract all ECU model numbers from the information in Table 3112. Next, delete any duplicate ECU model numbers. Then, ensure that each ECU model number after the duplicate ECU model numbers have been removed corresponds one-to-one with the physical ECU. The result is as follows: Figure 78 As shown.

[0478] In S1171-2, the estimation unit 17 estimates the result DB 22 based on the setting information stored therein. Figure 56 The information in (Table 3112) will be appended to the information requesting the NW_A-ID. Figure 78 The result is as follows: Figure 79 As shown.

[0479] In S1171-3, the estimation part 17 will, for a certain NW_A-ID = x, Figure 69 The statistical values ​​of NW_A-ID=x in (Table 3141) and Figure 73 The statistical values ​​in (Table 3151) are compared with the statistical values ​​of NW_A-ID = x. Then, from... Figure 73 (Table 3151) Extraction Figure 73 The statistical values ​​on the (Table 3151) side are all higher than those on the other side. Figure 69 (Table 3141) More than 50% more rows have been added. The extraction results are as follows: Figure 75 As shown in Table 3161. It should be noted that... Figure 75 The extraction method for (Table 3161) is not limited to this.

[0480] In S1171-4, the estimation part 17 pairs Figure 75 (Table 3161) groups the congestion NW_A-ID and the statistical calculation object NW_A-ID of each row. For example, 0x700 and 0x724 are grouped together, 0x700 and 0x7E0 are grouped together, 0x724 and 0x7E0 are grouped together, and 0x750 and 0x7E1 are grouped together.

[0481] In S1171-5, the estimation unit 17 summarizes the groups generated in the previous step as much as possible. For example, 0x700 and 0x724 are grouped together, 0x700 and 0x7E0 are grouped together, and 0x724 and 0x7E0 are grouped together; therefore, these three can be grouped together. The result is as follows: Figure 76 As shown in Table 3162.

[0482] <s1172>

[0483] Next, see Figure 80 S1172 will be explained.

[0484] In S1172-1, the estimation part 17 determines that, for Figure 76 The ECUs that respond to the NW_A messages grouped together in Table 3162 are connected to the same NW_A bus. Then, the estimation unit 17 determines the appropriate NW_A bus based on this determination result. Figure 79 The information is converted into a topology diagram of the NW_A bus. Figure 81 ).

[0485] In S1172-2, the estimation unit 17 transmits the setting information estimation result DB 22 (setting information processing unit) to the setting information estimation unit. Figure 56 All information in (Table 3112) is appropriately allocated to the ECU. The result is as follows: Figure 82 As shown.

[0486] In S1172-3, the estimation unit 17 transmits the estimation results DB 22 (setting information processing unit) to the setting information storage unit. Figure 65 ECU with NodeType=0x1 and Figure 82 The ECUs whose functions are "completely identical" or "partially identical" include ECUs with GW (gateway).

[0487] In S1172-4, the estimation unit 17 connects to the ECU found in the previous step via the NW_A bus. The result is as follows: Figure 83 As shown.

[0488] In S1172-5, the estimated part 17 will Figure 83 The information shown is saved to the setting information estimation result DB 22 via the setting information acquisition and registration unit 24.

[0489] <s1180>

[0490] Next, see Figure 84 S1180, which is performed by the normal NW_A communication estimation unit 18, will be explained.

[0491] In S1180-1, the restart command sending unit 19 executes S1191. In S1180-2, the restart command sending unit 19 executes S1192. In S1180-3, the vehicle alarm receiving unit 20 executes S1201. In S1180-4, the vehicle alarm receiving unit 20 executes S1211.

[0492] <s1191>

[0493] Next, refer to Figure 85 Describe S1191.

[0494] In S1191-1, the restart command transmission unit 19 declares the following variables.

[0495] · The Figure 56 (Table 3112) request NW_A-ID list "NW_A-ID = [0x700, 0x724, 0x750, 0x7E0, 0x7E1]"

[0496] · The length of the list "Length(NW_A-ID)" (in this example, Length(NW_A-ID) = 5)

[0497] · i = 0

[0498] It should be noted that the variable names can be different from those above. In addition, the content of NW_A-ID can also be unified by values other than NW_A-ID.

[0499] In S1191-2, the restart command transmission unit 19 determines whether i < Length(NW_A-ID) holds. If Yes, it proceeds to S1191-3; if No, the process ends. In S1191-3, the restart command transmission unit 19 executes S1192. In S1191-3, the restart command transmission unit 19 sets i = i + 1, and then returns to S1191-2.

[0500] <s1192>

[0501] Next, see Figure 86 S1192 will be explained.

[0502] In S1192-1, the restart command sending unit 19 sends 10 ECUReset (ResetType = HardReset) requests, as specified by UDS, to NW_A-ID[i] at random intervals of 5 to 10 seconds. It should be noted that the sending interval, the number of sending times, and ResetType are not limited to these.

[0503] In S1192-2, the restart command sending unit 19 stores the time when the ECUReset request was sent in the previous step, along with NW_A-ID[i], in the storage unit. An example of the stored information is shown below. Figure 87 .

[0504] <s1201>

[0505] Next, see Figure 88 S1201 will be explained.

[0506] First, the premise is described. An ECU on vehicle network 1 sends an NW_A message with a specific NW_A-ID at predetermined (design value) time intervals (transmission intervals). Furthermore, the NW_A-IDS on vehicle network 1 issues an alarm when the transmission interval of a specific NW_A-ID's NW_A message deviates significantly from the design value. It should be noted that the alarm is assumed to contain the alarm issuance time and the NW_A-ID of the detected NW_A message.

[0507] Upon receiving an ECUReset, the ECU suspends the transmission of NW_A messages to initiate an ECU restart. Furthermore, after restarting, the transmission of NW_A messages can resume at any time. Therefore, the interval between NW_A message transmissions from the ECU receiving the ECUReset will temporarily increase or decrease. The NW_A-IDS will identify this as an anomaly and issue an alarm.

[0508] In S1201-1, the vehicle alarm receiver 20 stores the alarm of NW_A-IDS along with the time in the storage unit. An example of the stored information is shown below. Figure 89 .

[0509] <s1211>

[0510] Next, see Figure 90 S1211 will be explained.

[0511] In S1211-1, the estimation part 21 will be used as Figure 87 The information shown is stored as NW_A-ID and as Figure 89 The information shown is used to associate the stored NW_A-ID. Association is based on the similarity of the storage time. An example of the result after association is shown below. Figure 91 (Table 3211).

[0512] In S1211-2, the estimation part 21 will Figure 91 The results of (Table 3211) are added to the results of the vehicle composition estimation (e.g., Figure 83 and Figure 56 (Table 3112)). At this point, the condition "NW_A-ID column of ECUReset in Table 3211" will be satisfied = " Figure 83 The row containing the condition "Request NW_A-ID" from Table 3112 is appended to... Figure 83 and Figure 56 (Table 3112).

[0513] It should be noted that when appending, for example, by using the column name "NW_A-ID (constantly sent)". An example of the result is shown below. Figure 92 and Figure 93 As shown in Table 3212.

[0514] (Example A2)

[0515] Next, Example A2 will be described. Figure 94 This is a system configuration diagram for embodiment A2. For example... Figure 94 As shown, Embodiment A2 is configured to include only the ECU function estimation unit 4, which is the estimation unit corresponding to Basic Technology 3. The processing of each unit (functional unit) is the same as that described in Embodiment A1.

[0516] (Example A3)

[0517] Next, Example A3 will be described. Figure 95 This is a configuration diagram of the system in embodiment A3. For example... Figure 95 As shown, Embodiment A3 is configured to include only the NW_A bus topology estimation unit 13, which is the estimation unit corresponding to Basic Technology 1. The processing of each unit (functional unit) is the same as that described in Embodiment A1.

[0518] (Example A4)

[0519] Next, Example A4 will be described. Figure 96 This is a configuration diagram of the system in embodiment A4. For example... Figure 96 As shown, Embodiment A4 is configured to include only the normal NW_A communication estimation unit 18, which corresponds to Basic Technology 2, as an estimation unit. The processing of each unit (functional unit) is the same as that described in Embodiment A1.

[0520] (Example A5)

[0521] Next, Example A5 will be described. Figure 97 This is a configuration diagram of the system in embodiment A5. For example... Figure 97 As shown, the configuration of embodiment A5 is derived from embodiment A1 ( Figure 27 The configuration is the same as the configuration after removing the normal NW_A communication estimation unit 18. The processing of each unit (functional unit) is the same as the processing described in Example A1.

[0522] (Example A6)

[0523] Next, Example A6 will be described. Figure 98 This is a configuration diagram of the system in embodiment A6. For example... Figure 98 As shown, the configuration of Example A6 is derived from Example A1 ( Figure 27 The configuration is the same as the configuration after removing the NW_A bus topology estimation unit 13. The processing of each unit (functional unit) is the same as that described in embodiment A1.

[0524] (Example A7)

[0525] Next, Example A7 will be described. Figure 99 This is a configuration diagram of the system in embodiment A7. For example... Figure 99 As shown, the configuration of embodiment A7 is derived from embodiment A1 ( Figure 27 The configuration is the same as the configuration after removing the ECU function estimation unit 4. The processing of each part (functional unit) is the same as the processing described in Example A1.

[0526] (Example B1)

[0527] Next, Embodiment B1 will be described. Embodiment B1 is an embodiment in which the setting information estimation system of the present invention is deployed on an in-vehicle NW. Figure 100 This is a configuration diagram of the vehicle (on-board NW) in Example B1. Figure 100 As shown, the vehicle setting estimation device 2, which functions as an ECU on the vehicle's NW, and the setting information estimation result DB 22 are shown.

[0528] It should be noted that replacing Figure 100 The method of having the setting information estimation result DB 22 in the ECU can also be a method of having the setting information estimation result DB 22 in the cloud. In addition, one or more functional units of the vehicle setting estimation device 2 other than the message transceiver unit 23 can be included in the cloud. For example, the cloud may only have the ECU function estimation unit 4 of the vehicle setting estimation device 2.

[0529] (Example B2)

[0530] Next, Embodiment B2 will be described. Embodiment B2 is an embodiment in which the setting information estimation system (device) of the present invention is directly connected to the OBD-II port. Figure 101 This is a configuration diagram of the system in Implementation Example B2. For example... Figure 101 As shown, the information estimation system is set to be directly connected to the OBD-II port.

[0531] It should be noted that replacing Figure 101 In the case where the setting information estimation result DB 22 is present on the setting information estimation system (device), the setting information estimation result DB 22 can also be present in the cloud. Furthermore, one or more functional units of the vehicle setting estimation device 2, excluding the message transceiver unit 23, can also be present in the cloud. For example, the cloud may only contain the ECU function estimation unit 4 of the vehicle setting estimation device 2.

[0532] (Example B3)

[0533] Next, Example B3 will be described. Figure 102 The configuration of the system in embodiment B3 is shown. Figure 102 As shown in Embodiment B3, the setting information estimation system of the present invention is installed in the charger and connected to the charging port. The processing of the setting information estimation system can be performed via the charging port.

[0534] It should be noted that replacing Figure 102 The method of having the setting information estimation result DB 22 in the charger can also be a method of having the setting information estimation result DB 22 in the cloud. In addition, one or more functional units of the vehicle setting estimation device 2 other than the message transceiver unit 23 can be included in the cloud. For example, the cloud may only have the ECU function estimation unit 4 of the vehicle setting estimation device 2.

[0535] (Example B4)

[0536] Next, Example B4 will be described. Figure 103 The system configuration of embodiment B4 is shown. Figure 103 As shown in Embodiment B4, the setting information estimation system of the present invention is set on an external network, and the processing of the setting information estimation system can be performed via the external network.

[0537] (Example C1)

[0538] Next, Example C1 will be described. Example C1 is an example of using a configuration information estimation system for security analysis of a System-on-a-Chip (SOC) or similar applications. Figure 104 This is a system configuration diagram for Example C1.

[0539] like Figure 104 As shown, in addition to the vehicle setting estimation device 2 connected to the car and the setting information estimation result DB 22, this system also includes a setting information acquisition unit 30, a safety analysis unit 31, and an analysis result display unit 32. Each unit (functional unit) is connected as shown in the diagram.

[0540] The setting information acquisition unit 30 extracts the required setting information from the setting information estimation result DB 22 and transmits it to the safety analysis unit 31. The safety analysis unit 31 performs a more advanced safety analysis using the vehicle setting information estimated by the vehicle setting estimation device 2. Afterwards, the analysis results are transmitted to the analysis result notification unit 32.

[0541] The analysis results notification unit 32 receives the analysis results, processes them appropriately, and then provides them to the analyst. It should be noted that the analyst is not limited to a person; it can also be a procedure that uses the analysis results to perform other analyses.

[0542] The security analysis performed by the security analysis unit 31 is not limited to a specific security analysis, but, for example, there are examples listed below.

[0543] • Estimation of attack paths that acquire and utilize topology information

[0544] • Estimation of entry points using topology information and / or the software version of each ECU

[0545] • Reasons for using topology information and / or the software version of each ECU

[0546] • Estimation of abnormal communication and / or processes using topology information, software versions of each ECU, and / or information on normal communication.

[0547] • Estimation of the impact of topology information and / or software version of each ECU, information on normal communication, and information on the functionality of each ECU.

[0548] • Estimation of coping strategies using topology information and / or the software version of each ECU

[0549] (Example C2)

[0550] Next, Example C2 will be described. Example C2 is an example of using a setting information estimation system for asset management. Figure 105 This is a system configuration diagram for Example C2.

[0551] like Figure 105 As shown, in addition to the vehicle setting estimation device 2 connected to the car and the setting information estimation result DB 22, this system also includes a setting information acquisition unit 30, an asset management unit 33, and a management information prompt unit 34. The various units (functional units) are connected as shown in the diagram.

[0552] The setting information acquisition unit 30 extracts the required setting information from the setting information estimation result DB 22 and transmits it to the asset management unit 33. The asset management unit 33 maintains the management information and manages whether there are any ECUs not in the management information and / or unsupported ECUs based on the received setting information. At this time, publicly available information such as the software support status of the ECU can also be used.

[0553] The Management Information Notification Unit 34 obtains management information from the Asset Management Unit 33 and processes it appropriately (e.g., extracting and organizing only the device name and / or address information of ECUs not found in the management information), and then notifies the administrator of the results. It should be noted that the administrator is not limited to a person and can also be any program that uses the management information for further analysis.

[0554] (Example C3)

[0555] Next, embodiment C3 will be described. Embodiment C3 is an embodiment in which the setting information estimation system is used for anomaly detection. Figure 106 This is a system configuration diagram for embodiment C3.

[0556] like Figure 106 As shown, in addition to the vehicle setting estimation device 2 connected to the car and the setting information estimation result DB 22, this system also includes a setting information acquisition unit 30 and an anomaly detection unit 35. The various units (functional units) are connected as shown in the diagram.

[0557] The setting information acquisition unit 30 extracts the required setting information from the setting information estimation result DB 22 and transmits it to the anomaly detection unit 35. The anomaly detection unit 35 uses information from the DB containing normal vehicle setting information, anomaly detection rules, and / or publicly available information (e.g., information from the vulnerability DB) to detect abnormal states in the vehicle setting information. Furthermore, the anomaly detection results are notified to the vehicle administrator and / or analysts such as the SOC.

[0558] Anomaly detection methods are not limited to a specific method, however, there are examples such as those listed below.

[0559] • Compare the vehicle setting information stored in the normal vehicle setting information DB with the vehicle setting information stored in the setting information estimation result DB. If there is a difference, it is detected as an anomaly.

[0560] • If the vehicle setting information stored in the setting information estimation result DB 22 meets the anomaly detection rules, and / or if the setting information is defined as an abnormal state, such as publicly available information (weakness DB), an anomaly is detected.

[0561] • Perform machine learning on the vehicle settings information of normal cars, and perform machine learning-based anomaly detection based on the learned model.

[0562] (Example C4)

[0563] Next, Embodiment C4 will be described. Embodiment C4 is an embodiment of using a setting information estimation system for security diagnostics. Figure 107 This is a system configuration diagram of embodiment C4.

[0564] like Figure 107 As shown, in addition to the vehicle setting estimation device 2 connected to the car and the setting information estimation result DB 22, this system also includes a setting information acquisition unit 30, a safety diagnostic unit 36, and a diagnostic result prompting unit 37. Each unit (functional unit) is connected as shown in the diagram.

[0565] The setting information acquisition unit 30 extracts the required setting information from the setting information estimation result DB 22 and transmits it to the safety diagnostic unit 36. The safety diagnostic unit 36 ​​performs diagnostics based on the received setting information to determine whether the vehicle has an ECU or other components with safety issues. At this time, publicly available information such as the software support status of the ECU can be used to confirm whether a problem exists.

[0566] The diagnostic result notification unit 37 obtains the diagnostic results from the safety diagnostic unit 36, processes them appropriately (e.g., scores the diagnostic results), and then notifies the administrator. It should be noted that the administrator is not limited to a person; it can also be a program that uses management information for further analysis.

[0567] For example, the diagnostic rules used by the safety diagnostic unit 36 ​​record the ECU model and / or software version information (blacklist) of ECUs whose weaknesses have been identified. The safety diagnostic unit 36 ​​compares the vehicle setting information (blacklist) stored in the diagnostic rules with the vehicle setting information estimation result DB 22. If the corresponding information exists in the blacklist, the weakness (vulnerability) is pointed out.

[0568] (Hardware configuration example)

[0569] The apparatus comprised of the diagnostic communication transceiver 100, the diagnostic system log DB 200, and the setting information estimation unit 300 described in the first embodiment, as well as the apparatus comprised of the diagnostic communication transceiver 100 and the diagnostic system log DB 200, the apparatus comprised of the diagnostic system log DB 200 and the setting information estimation unit 300, the apparatus comprised of the diagnostic communication transceiver 100 and the setting information estimation unit 300, the apparatus comprised of the diagnostic communication transceiver 100, the apparatus comprised of the diagnostic system log DB 200, and the apparatus comprised of the setting information estimation unit 300, can all be implemented, for example, by executing a program on a computer. This computer can be a physical computer or a virtual machine in the cloud.

[0570] Furthermore, the system, apparatus, and functional units described in the second embodiment can also be implemented, for example, by executing a program on a computer. This computer can be a physical computer or a virtual machine in the cloud.

[0571] The entity that performs the above-described program is called a "device". This device executes a program corresponding to the processing performed by it using hardware resources such as the CPU and memory built into a computer. The program is stored in a computer-readable storage medium (such as a portable storage device), allowing it to be saved or distributed. Furthermore, the program can be provided via networks such as the Internet or email.

[0572] Figure 108 This is a schematic diagram illustrating an example of the hardware configuration of the computer described above. Figure 108 The computer includes a drive unit 1000, an auxiliary storage unit 1002, a storage unit 1003, a CPU 1004, an interface unit 1005, a display unit 1006, an input unit 1007, and an output unit 1008, all interconnected by a bus BS. It should be noted that some of these devices may be omitted. For example, a device that does not perform display may omit the display unit 1006.

[0573] The program used to perform the computer's processing can be provided by a storage medium 1001, such as a CD-ROM or memory card. After the storage medium 1001 storing the program is inserted into the drive device 1000, the program can be installed from the storage medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, program installation does not necessarily have to be performed from the storage medium 1001; it can also be downloaded from another computer via a network. The auxiliary storage device 1002 can store the installed program, as well as necessary files, data, etc.

[0574] Storage device 1003 reads and saves a program from auxiliary storage device 1002 when a program start instruction is present. CPU 1004 can implement the functions of the device based on the program saved in storage device 1003. Interface device 1005 is an interface that can be used to connect to a network and can function as a transmitter and receiver. Display device 1006 can display program-based GUIs (Graphical User Interfaces). Input device 1007 can be composed of a keyboard, mouse, buttons, touch screen, etc., and can be used to input various operation instructions. Output device 1008 can output calculation results.

[0575] (Effects of the implementation method)

[0576] As described above, in embodiments of the present invention, valid information is collected for estimating vehicle setting information by performing diagnostic communication (receiving and sending), and the vehicle setting information is estimated by analyzing the collected information. The diagnostic communication uses diagnostic communication protocols (DoCAN, DoIP, UDS, etc.) that are supported in a standard manner in each ECU. Accordingly, when performing vehicle setting information estimation, no resource enhancement or support for new protocols is required, thereby reducing additional costs.

[0577] (Summary of implementation methods)

[0578] This specification discloses at least the following network setting estimation device, network setting estimation method, and procedure.

[0579] (Item 1)

[0580] A network configuration estimation apparatus for estimating configuration information of an internal network in a target device, comprising:

[0581] The diagnostic communication transceiver unit uses a diagnostic communication method supported in a standard manner in the electronic control device on the internal network to send messages to the electronic control device on the internal network and receive responses to those messages; and

[0582] The setting information estimation unit estimates the setting information of the internal network based on the response obtained by the diagnostic communication transceiver unit.

[0583] (Item 2)

[0584] The network setting estimation apparatus as described in item 1, wherein the setting information estimation unit comprises:

[0585] An existence confirmation unit confirms the presence of the electronic control device on the internal network based on the response.

[0586] The topology estimation unit estimates the topology of the internal network based on the presence confirmation result of the electronic control device confirmed by the presence confirmation unit; and

[0587] The information extraction unit extracts information related to the electronic control device on the internal network based on the response.

[0588] (Item 3)

[0589] The network setting estimation device as described in item 1 or item 2, wherein,

[0590] The diagnostic communication transceiver unit sends messages to the first network and the second network in the internal network, respectively, and receives responses to those messages.

[0591] The setting information estimation unit confirms the presence of an electronic control device connected to the first network by responding to a message sent by the first network, and confirms the presence of an electronic control device connected to the second network by responding to a message sent by the second network.

[0592] (Item 4)

[0593] The network setting estimation device as described in any one of items 1 to 3, wherein,

[0594] The diagnostic communication transceiver unit sends a message with a set data ID and receives a response to that message.

[0595] The setting information estimation unit extracts information corresponding to the data ID from the response to the message with the set data ID.

[0596] (Item 5)

[0597] A network configuration estimation apparatus for estimating configuration information of an internal network in a target device, comprising:

[0598] The setting information estimation unit uses a diagnostic communication method supported in a standard manner in the electronic control device on the internal network to send a message to the electronic control device on the internal network, and estimates the setting information of the internal network based on the response obtained by the device that receives the response to the message.

[0599] (Item 6)

[0600] A network configuration estimation apparatus for estimating configuration information of an internal network in a target device, comprising:

[0601] The basic RTT calculation unit, in a non-congested state, uses a diagnostic communication method supported in a standard manner in the electronic control device on the internal network to calculate the round trip time of the first electronic control device on the internal network.

[0602] The congestion RTT calculation unit calculates the round-trip time of the first electronic control device under congestion conditions where diagnostic requests are sent to the second electronic control device at a high frequency; and

[0603] The estimation unit estimates whether the first electronic control device and the second electronic control device are connected to the same bus by comparing the round-trip time in the non-congested state and the round-trip time in the congested state.

[0604] (Item 7)

[0605] A network configuration estimation apparatus for estimating configuration information of an internal network in a target device, comprising:

[0606] The restart command sending unit sends a restart command to the target electronic control device on the internal network using a diagnostic communication method supported in a standard manner in the electronic control device on the internal network.

[0607] The alarm receiving unit receives an alarm from the internal network caused by the restart command; and

[0608] The estimation unit estimates the ID contained in the alarm as the ID of a normal communication sent by the target electronic control device.

[0609] (Item 8)

[0610] A network configuration estimation apparatus for estimating configuration information of an internal network in a target device, comprising:

[0611] The web search unit searches for the functions of the electronic control device using the complete model number of the target electronic control device and the function-related bits in that model number, obtained by using a diagnostic communication method supported in a standard manner in the electronic control device on the internal network; and

[0612] The estimation unit estimates the function of the target electronic control device as the function whose sum of the support scores of the words contained in the search results obtained by the Web retrieval unit is the one that maximizes the sum of the support scores of the words.

[0613] (Item 9)

[0614] A network configuration estimation method, executed by a network configuration estimation device, for estimating configuration information of an internal network in a target device, comprising:

[0615] The receiving step involves sending a message to the electronic control device on the internal network using a diagnostic communication method supported in a standard manner, and receiving a response to that message; and

[0616] The estimation step involves estimating the configuration information of the internal network based on the response.

[0617] (Item 10)

[0618] A program that enables a computer to function as a functional unit in any of the network setting estimation devices described in items 1 to 8.

[0619] The embodiments of the present invention have been described in detail above, but the present invention is not limited to these specific embodiments. Various modifications and alterations can be made within the scope of the spirit of the present invention as set forth in the claims.

[0620] This patent application claims priority to international patent application PCT / JP2020 / 035621, filed on September 18, 2020, the entire contents of which are incorporated herein by reference.

[0621] [Explanation of reference numerals in the attached figures]

[0622] 1 vehicle-mounted NW

[0623] 2. Setting Element Estimation Department

[0624] 3ECU Basic Information Acquisition Department

[0625] 4ECU Function Estimation Unit

[0626] 6. Web Search Department

[0627] 7Web website

[0628] 8 Search Results DB

[0629] 9 Completely consistent extraction section

[0630] 10 specific parts consistent extraction section

[0631] 11. Estimation Department

[0632] 12NW_B Topology Estimation Unit

[0633] 13NW_A Bus Topology Estimation Unit

[0634] 14 Basic RTT Calculation Unit

[0635] 15 congestion RTT computing unit

[0636] 16RTT Comparison Section

[0637] 17. Estimation Department

[0638] 18 Normal NW_A Communication Estimation Department

[0639] 19 Restart Command Sending Department

[0640] 20 Vehicle Alarm Receiver

[0641] 21. Estimation Department

[0642] 22 Setting Information Estimation Results DB

[0643] 23 Message Receiving and Dispatching Department

[0644] 24. Information Acquisition and Registration Department

[0645] 30. Information Acquisition Department

[0646] 31 Security Analysis Department

[0647] 32 Analysis Results Indication Section

[0648] 33 Asset Management Department

[0649] 34 Management Information Prompt Department

[0650] 35 Anomaly Detection Department

[0651] 36 Safety Diagnostics Department

[0652] 37. Diagnostic Results Suggestion Department

[0653] 500ECU

[0654] 100 Diagnostic Communication Transceiver Unit

[0655] 200 Diagnostic System Log DB

[0656] 300 Setting Information Estimation Department

[0657] 310ECU has a confirmation unit

[0658] 320 Topology Estimation Department

[0659] 330ECU Information Extraction Department

[0660] 340 Output Unit

[0661] 400 cars

[0662] 1000 drive unit

[0663] 1001 storage medium

[0664] 1002 Auxiliary Storage Device

[0665] 1003 storage device

[0666] 1004 CPU

[0667] 1005 Interface Device

[0668] 1006 Display Device

[0669] 1007 Input Device

[0670] 1008 Output device. Note: There seems to be an unclear character "??" in the "DID" value in the original text. I've translated it as "??19F" as it is. You may need to double-check this in the original context.

Claims

1. A network configuration estimation device for estimating configuration information of an internal network in a target device, the network configuration estimation device comprising: A diagnostic communication transceiver unit, using a diagnostic communication method supported in a standard manner in the electronic control device on the internal network, sends messages to the electronic control device on the internal network and receives responses to the messages; and The setting information estimation unit estimates the setting information, including the topology of the internal network, based on the response obtained by the diagnostic communication transceiver unit and known information about the connection method.

2. The network setting estimation device as described in claim 1, wherein, The setting information estimation unit includes: An existence confirmation unit confirms the presence of the electronic control device on the internal network based on the response. The topology estimation unit estimates the topology of the internal network based on the presence confirmation result of the presence confirmation unit for the electronic control device. and The information extraction unit extracts information related to the electronic control device on the internal network based on the response.

3. The network setting estimation device as described in claim 1 or 2, wherein, The diagnostic communication transceiver unit sends messages to the first network and the second network in the internal network, respectively, and receives responses to those messages. The setting information estimation unit uses the response to a message sent to the first network to confirm the existence of an electronic control device connected to the first network, and uses the response to a message sent to the second network to confirm the existence of an electronic control device connected to the second network.

4. The network setting estimation device as described in claim 1 or 2, wherein, The diagnostic communication transceiver unit sends a message with a set data ID and receives a response to that message. The setting information estimation unit extracts information corresponding to the data ID from the response to the message with the set data ID.

5. A network configuration estimation device for estimating configuration information of an internal network in a target device, the network configuration estimation device comprising: The setting information estimation unit uses a diagnostic communication method supported in a standard manner in the electronic control device on the internal network to send a message to the electronic control device on the internal network, and estimates the setting information, including the topology of the internal network, based on the response obtained by a device that receives a response to the message and known information about the connection method.

6. A network configuration estimation device for estimating configuration information of an internal network in a target device, the network configuration estimation device comprising: The basic RTT calculation unit, in a non-congested state, uses a diagnostic communication method supported in a standard manner in the electronic control device on the internal network to calculate the round-trip time of the first electronic control device on the internal network. The congestion RTT calculation unit calculates the round-trip time of the first electronic control unit when congestion occurs and diagnostic requests are frequently sent to the second electronic control unit. and The estimation unit estimates whether the first electronic control device and the second electronic control device are connected to the same bus by comparing the round-trip time in the non-congested state and the round-trip time in the congested state.

7. A network configuration estimation device for estimating configuration information of an internal network in a target device, the network configuration estimation device comprising: The restart command sending unit sends a restart command to the target electronic control device on the internal network using a diagnostic communication method supported in a standard manner in the electronic control device on the internal network. The alarm receiving unit receives alarms generated by the restart command from the internal network; and The estimation unit estimates the ID contained in the alarm as the ID of a normal communication sent by the target electronic control device.

8. A network configuration estimation device for estimating configuration information of an internal network in a target device, the network configuration estimation device comprising: The web search department uses the complete model number of the target electronic control device and the function-related bits within that model number to search for the functions of the electronic control device. The complete model number of the target electronic control device is obtained by using diagnostic communication methods supported in a standard manner in the electronic control device on the internal network; and The estimation unit estimates the function of the target electronic control device as the function whose sum of the support scores of the words contained in the search results obtained by the Web retrieval unit is the one that maximizes the support score of the words.

9. A network configuration estimation method, executed by a network configuration estimation device that estimates configuration information of an internal network in a target device, the network configuration estimation method comprising: The receiving step involves sending a message to the electronic control device on the internal network using a diagnostic communication method supported in a standard manner within the electronic control device on the internal network, and receiving a response to the message; and The estimation step involves estimating the defined information, including the topology of the internal network, based on the response and known information about the connection method.

10. A program product for enabling a computer to function as a functional unit within the network setting estimation apparatus according to any one of claims 1 to 8.

Images