[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2022059503A1 - ネットワーク構成推定装置、ネットワーク構成推定方法、及びプログラム - Google Patents

ネットワーク構成推定装置、ネットワーク構成推定方法、及びプログラム Download PDF

Info

Publication number
WO2022059503A1
WO2022059503A1 PCT/JP2021/032301 JP2021032301W WO2022059503A1 WO 2022059503 A1 WO2022059503 A1 WO 2022059503A1 JP 2021032301 W JP2021032301 W JP 2021032301W WO 2022059503 A1 WO2022059503 A1 WO 2022059503A1
Authority
WO
WIPO (PCT)
Prior art keywords
ecu
unit
network
estimation
configuration information
Prior art date
Application number
PCT/JP2021/032301
Other languages
English (en)
French (fr)
Inventor
勝 松林
卓麻 小山
靖 岡野
政志 田中
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to EP21869190.5A priority Critical patent/EP4216494A4/en
Priority to US18/042,401 priority patent/US20230327956A1/en
Priority to CN202180063068.2A priority patent/CN116114221A/zh
Priority to JP2022550459A priority patent/JPWO2022059503A1/ja
Publication of WO2022059503A1 publication Critical patent/WO2022059503A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/0864—Round trip delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle

Definitions

  • the present invention relates to a technique for estimating the configuration information of an internal network in a target device such as an automobile.
  • vehicle configuration information is necessary to achieve various purposes such as asset management and configuration abnormality detection.
  • Non-Patent Document 1 As a conventional technique for estimating the configuration of NW, for example, there is a technique disclosed in Non-Patent Document 1.
  • the MAC address transfer table of each Switch in the target NW is acquired by using SNMP, and the L2 topology of the target NW is estimated by analyzing the acquired information.
  • Non-Patent Document 1 it is conceivable to use the SNMP-based method disclosed in Non-Patent Document 1 in order to acquire the topology of the in-vehicle NW and the information of each ECU.
  • the SNMP-based method it is necessary to increase resources and support SNMP to enable the operation of the SNMP agent for each ECU. , There is a problem that additional cost is required.
  • the present invention has been made in view of the above points, and estimates the configuration information of the internal network of the target device without increasing resources or supporting a new protocol for the configuration device of the internal network.
  • the purpose is to provide the technology that makes it possible.
  • a network configuration estimation device that estimates the configuration information of the internal network in the target device.
  • a diagnostic communication transmitter / receiver that sends a message to the electronic control device on the internal network and receives a response to the message using a diagnostic communication method that is standardly supported by the electronic control device on the internal network.
  • a network configuration estimation device including a configuration information estimation unit that estimates configuration information of the internal network based on the response obtained by the diagnostic communication transmission / reception unit is provided.
  • the disclosed technology it is possible to estimate the configuration information of the internal network of the target device without increasing resources or supporting a new protocol for the configuration device of the internal network.
  • Example 5 It is a system block diagram in Example 5 in 1st Embodiment. It is a system block diagram in Example 6 in 1st Embodiment. It is a figure which shows an example of the vehicle composition information. It is a figure which shows the network of the automobile which is presupposed in the 2nd Embodiment. It is a figure for demonstrating the goal of element technology 1. It is a figure for demonstrating the application target of element technology 1. It is a figure for demonstrating RTT of a diagnostic communication. It is a figure for demonstrating the estimation method of element technique 1. It is a figure for demonstrating the estimation procedure of element technique 1. It is a figure for demonstrating the estimation procedure of element technique 1. It is a figure for demonstrating the estimation procedure of element technique 1. It is a figure for demonstrating the estimation procedure of element technique 1. It is a figure for demonstrating the estimation procedure of element technique 1.
  • Example A1 in the 2nd Embodiment It is a flowchart which shows the whole processing of Example A1 in 2nd Embodiment. It is a flowchart which shows the process of S1030 of Example A1 in 2nd Embodiment. It is a flowchart which shows the process of S1031 of Example A1 in 2nd Embodiment.
  • Example A1 in 2nd Embodiment It is a figure which shows the connection relation of Example A1 in 2nd Embodiment. It is a flowchart which shows the process of S1130 of Example A1 in 2nd Embodiment. It is a flowchart which shows the process of S1141 of Example A1 in 2nd Embodiment. It is a figure which shows the record of the transmission time and the reception time of Example A1 in the 2nd Embodiment. It is a figure which shows the table 3141 of Example A1 in the 2nd Embodiment. It is a flowchart which shows the process of S1151 of Example A1 in 2nd Embodiment. It is a flowchart which shows the process of S1152 of Example A1 in 2nd Embodiment.
  • Example A7 in the 2nd Embodiment It is a block diagram of Example B1 in the 2nd Embodiment. It is a block diagram of Example B2 in 2nd Embodiment. It is a block diagram of Example B3 in the 2nd Embodiment. It is a block diagram of Example B4 in 2nd Embodiment. It is a block diagram of Example C1 in 2nd Embodiment. It is a block diagram of Example C2 in 2nd Embodiment. It is a block diagram of Example C3 in the 2nd Embodiment. It is a block diagram of Example C4 in 2nd Embodiment. It is a figure which shows the hardware configuration example of the apparatus.
  • an automobile will be described as an example as a target device provided with an internal network for which configuration information is estimated, but the present invention relates to the present invention.
  • the target devices to which the technology can be applied are not limited to automobiles.
  • the technique according to the present invention can be applied to a target device having the characteristic that "information can be acquired from a device on a network by diagnostic communication" as in an automobile.
  • the elemental technology described in the second embodiment can be applied to at least those having the conditions described in the application target.
  • the configuration of the vehicle-mounted network (NW), the information about the information processing device (IVI, TCU, etc.) on the NW, and the information about the electronic control unit (ECU) are collectively referred to as “vehicle configuration information”.
  • vehicle configuration information is an example of "internal network configuration information”.
  • TCU is an abbreviation for Telematics Control Unit
  • IVI is an abbreviation for In-Vehicle Infotainment
  • ECU is an abbreviation for Electronic Control Unit.
  • CAN registered trademark
  • NW_A network A
  • NW_B network B
  • CAN registered trademark
  • NW_A appearing in the following description may be a network other than CAN (registered trademark), and NW_B may be a network other than Ethernet (registered trademark).
  • NW_A may be FlexRay®, LIN, K-Line, or the like.
  • the network configuration information of the target vehicle is, for example, the following information.
  • the configuration information estimation system estimates the vehicle configuration information of the automobile.
  • FIG. 1 shows an example of vehicle configuration information.
  • the TCU and IVI connected to the NW_B are connected to the GW (Gateway-ECU) in a star shape.
  • NW_A is connected to the GW
  • the ECU connected to the NW_A is connected to the NW_A under the GW in a bus type.
  • FIG. 1 also shows information on each ECU and the like.
  • OBD-II shown in FIG. 1 is a self-diagnosis function.
  • ECU electronice control device
  • the configuration information estimation system estimates vehicle configuration information by collecting and analyzing information obtained by diagnostic communication that is standardly supported by devices such as ECUs mounted on automobiles. It is supposed to be. Diagnostic communication is implemented in almost all automobiles and ECUs. Here, the diagnostic communication will be described.
  • Diagnostic communication is communication used when performing ECU failure diagnosis and reprogramming.
  • the model number of the ECU, software version information, and the like can be acquired by diagnostic communication.
  • An example of the procedure for diagnostic communication will be described with reference to FIG. FIG. 2 shows an example in which diagnostic communication is performed between the external diagnostic device_A and the ECU_B.
  • a diagnosis request is transmitted from the external diagnostic machine_A to the ECU_B.
  • ECU_B executes a process corresponding to the diagnosis request.
  • the diagnostic response is transmitted from the ECU_B to the external diagnostic device_A. The result of processing and the like are stored in the diagnostic response.
  • FIG. 3 shows a configuration example of the configuration information estimation system according to the present embodiment.
  • the configuration information estimation system according to the present embodiment includes a diagnostic communication transmission / reception unit 100, a diagnostic system log DB 200, and a configuration information estimation unit 300.
  • the configuration information estimation unit 300 includes an ECU existence confirmation unit 310, a topology estimation unit 320, an ECU information extraction unit 330, and an output unit 340.
  • the outline of each functional part is as follows.
  • the diagnostic communication transmission / reception unit 100 transmits / receives diagnostic communication according to a flow chart described later, and stores the received response in the diagnostic system log DB 200.
  • the diagnostic system log DB 200 is a DB (database) that stores logs acquired by the diagnostic communication transmission / reception unit 100 in a predetermined format.
  • the configuration information estimation unit 300 estimates vehicle configuration information using the information stored in the diagnostic system log DB 200 by operating each internal block according to the flow chart described later.
  • Information other than the diagnostic system log may be used for the input of the configuration information estimation unit 300. For example, known information about the configuration or non-diagnostic logs may be used.
  • the diagnostic communication transmission / reception unit 100, the diagnostic system log DB 200, and the configuration information estimation unit 300 can be mounted on one or more devices in various forms.
  • a device including a diagnostic communication transmission / reception unit 100 and a configuration information estimation unit 300 may be referred to as a network configuration estimation device.
  • the diagnostic communication transmission / reception unit 100 and the configuration information estimation unit 300 may be located at remote locations and communicate with each other via a network.
  • a device including a configuration information estimation unit 300 that estimates configuration information using the response obtained by the diagnostic communication transmission / reception unit 100 may be called a network configuration estimation device.
  • UDS is an abbreviation for Unified Diagnostic Services, and is the name of a standard specification (ISO14229-1 etc.) that defines the format of diagnostic messages in diagnostic communication.
  • DID is an abbreviation for Data ID. It is an ID set in the UDS diagnosis request (request message) and indicates the target of the diagnosis service. For example, when a diagnostic request in which a DID specifying a software version number is set as a DID is transmitted to the ECU, the ECU returns a diagnostic response (response message) in which the software version number is set.
  • DoCAN Diagnostic communication over Controller Area Network
  • DoIP is an abbreviation for Diagnostic communication over Internet Protocol, and is the name of the standard specifications (ISO 13400-1, ISO 13400-2) that specify the specifications of the network layer for implementing UDS on IP.
  • the diagnostic communication transmission / reception unit 100 and the ECU in the present embodiment perform diagnostic communication at least in accordance with the above-mentioned general standard specifications.
  • the diagnostic communication transmission / reception unit 100 broadcasts the Vehicle Identification Request of DoIP to the ECUs connected to NW_B, and receives the response from each ECU.
  • the Vehicle Identification Request is a message requesting address information from the ECU connected to the NW_B.
  • the diagnostic communication transmission / reception unit 100 transmits the UDS tester Present to each ECU connected to NW_A, and receives a response.
  • the testerPresent is a message for confirming the existence of the ECU connected to NW_A and the NW_A-ID (that is, CAN-ID).
  • the diagnostic communication transmission / reception unit 100 transmits a DoIP Entity Status Request to each ECU connected to the vehicle-mounted NW_B, and receives a response.
  • the Entity Status Request is a message requesting the ECU for the node type (example: gateway) and the like.
  • the diagnostic communication transmission / reception unit 100 transmits the UDS ReadDataByIdentifier in which a value of 1 or more is set as the DID to each ECU of the vehicle-mounted NW_B connection and the NW_A connection, and receives a response.
  • ReadDataByIdentifier is a message requesting the ECU for the data specified by the DID.
  • the DIDs used in S104 are, for example, 0xF181, 0xF183, 0xF184, 0xF188, 0xF189, 0xF18A, 0xF194, 0xF195, 0xF19F, 0xF18B, 0xF18C, 0xF184, 0xF191, 0xF192, 0xF193, 0xF19.
  • these are examples and are not limited to these.
  • 0xF181 indicates applicationSoftwareIdentificationDataIdentifier.
  • 0xF183 indicates bootSoftwareFingerprintDataIdentifier.
  • 0xF184 indicates applicationSoftwareFingerprintDataIdentifier.
  • 0xF188 indicates vehicleManufacturerECUSoftwareNumberDataIdentifier.
  • 0xF189 indicates vehicleManufacturerECUSoftwareVersionNumberDataIdentifier.
  • 0xF18A indicates systemSupplierIdentifierDataIdentifier.
  • 0xF194 indicates systemSupplierECUSoftwareNumberDataIdentifier.
  • 0xF195 indicates systemSupplierECUSoftwareVersionNumberDataIdentifier.
  • 0xF19F indicates EntityDataIdentifier.
  • 0xF18B indicates ECUManufacturingDateDataIdentifier.
  • 0xF18C indicates ECU SerialNumberDataIdentifier.
  • 0xF184 indicates applicationSoftwareFingerprintDataIdentifier.
  • 0xF191 indicates vehicleManufacturerECUHardwareNumberDataIdentifier.
  • 0xF192 indicates systemSupplierECUHardwareNumberDataIdentifier.
  • 0xF193 indicates systemSupplierECUHardwareVersionNumberDataIdentifier.
  • 0xF19F indicates EntityDataIdentifier.
  • the configuration information estimation unit 300 estimates the configuration information of the internal network of the target device by reading the data from the diagnostic system log DB 200.
  • the ECU existence confirmation unit 310 confirms the existence of the ECU. Specifically, it is as follows.
  • the ECU existence confirmation unit 310 confirms the existence of the ECU connected to NW_B and the address information of the ECU from the response to the Vehicle Identification Request of DoIP broadcast to the ECU connected to NW_B. That is, if the address information is received as a response to the Vehicle Identification Request, it can be estimated that the ECU of the address information exists on NW_B.
  • the ECU existence confirmation unit 310 confirms the existence of the ECU connected to NW_A and the NW_A-ID from the response to the UDS tester Present transmitted to each ECU connected to NW_A. That is, if the NW_A-ID is received as a response to the testerPresent, it can be estimated that the ECU of the NW_A-ID exists on the NW_A.
  • the ECU existence confirmation unit 310 confirms the existence of the Gateway-ECU and its address information from the response to the Entity Status Request of DoIP. That is, when a response whose node type is Gateway is received as a response to the Entity Status Request, it can be estimated that the Gateway-ECU exists.
  • the topology estimation unit 320 estimates the topology of the internal network of the target device (here, the automobile). Specifically, it is as follows.
  • the topology estimation unit 320 estimates that the ECU connected to NW_B has a configuration in which one switch is connected in a star shape.
  • the topology estimation unit 320 has an internal network based on the confirmation result in S201 that one Gateway-ECU (which also functions as a Switch) exists and the ECU exists on NW_B. Estimates that the NW_B-connected ECU has a configuration in which one switch is connected in a star shape. Such an estimation can be made, for example, based on a predetermined rule.
  • the topology estimation unit 320 estimates that NW_A is connected to the Gateway-ECU. For example, in the topology estimation unit 320, NW_A is connected to the Gateway-ECU based on the confirmation result in S201 that the existence of the Gateway-ECU is confirmed and the existence of the NW_A-connected ECU is confirmed. Presumed to be. Such an estimation can be made, for example, based on a predetermined rule.
  • the topology estimation unit 320 estimates that the ECU connected to NW_A is connected to NW_A under Gateway-ECU in a bus type.
  • the topology estimation unit 320 is NW_A based on the estimation result that the NW_A is connected to the Gateway-ECU and the publicly known information (eg, being connected to the bus type) of the connection method of the ECU to the NW_A. It is presumed that the connected ECU is connected to NW_A under the Gateway-ECU in a bus type.
  • Such an estimation can be made, for example, based on a predetermined rule.
  • the ECU information extraction unit 330 extracts ECU information. Specifically, it is as follows.
  • the ECU information extraction unit 330 has 0xF181, 0xF183, 0xF184, 0xF188, 0xF189, 0xF18A, 0xF194, 0xF195, 0xF19F, 0xF18B, 0xF18C, 0xF184, 0xF191, 0xF192, 0xF193, 0xF19F, respectively. From the response to the ReadDataByIdentifier of UDS in which is set, the ECU information (VIN, model number, software version, etc.) in each ECU is grasped.
  • the output unit 340 outputs the information obtained by S201 to S203.
  • the output unit 340 creates a graphical image as shown in FIG. 1 from the information obtained by S201 to S203, and outputs (displays) the image.
  • the output unit 340 may output the information obtained by S201 to S203 in the form of a list or natural language. Further, the voice of natural language may be output.
  • the configuration information estimation system according to the present embodiment shown in FIG. 3 can be implemented in various forms.
  • Examples 1 to 6 will be described as examples of the mounting method in the present embodiment.
  • FIG. 6 is a configuration diagram of the configuration information estimation system according to the first embodiment. As shown in FIG. 6, in the first embodiment, all the functions of the configuration information estimation system, that is, an external device having a diagnostic communication transmission / reception unit 100, a diagnostic system log DB 200, and a configuration information estimation unit 300 are connected to the automobile 400. Will be done.
  • connection method for connecting the external device to the automobile 400 may be a method of physically connecting the external device to the automobile 400, or the external device may be realized on a network such as a cloud and the external device on the network may be used. It may be a method of connecting to the automobile 400 remotely.
  • FIG. 7 is a configuration diagram of the configuration information estimation system according to the second embodiment.
  • two devices a diagnostic communication transmission / reception device including a diagnostic communication transmission / reception unit 100 and a configuration information estimation device including a diagnostic system log DB 200 and a configuration information estimation unit 300, are connected to the automobile 400.
  • FIG. 7 shows a configuration example in which the diagnostic communication transmission / reception device is physically connected to the automobile 400, the configuration information estimation device is arranged on the cloud, and is connected to the diagnostic communication transmission / reception device via the network. It should be noted that such a connection form is an example, and the location of the diagnostic communication transmission / reception device and the configuration information estimation device is not limited to a specific one.
  • FIG. 8 is a configuration diagram of the configuration information estimation system according to the third embodiment.
  • the third embodiment is an example in which the diagnostic system log DB 200 is provided in the diagnostic communication transmission / reception device in the configuration of the second embodiment.
  • the diagnostic system log DB 200 may be arranged outside the diagnostic communication transmission / reception device or the configuration information estimation device, not inside the device.
  • FIG. 9 is a configuration diagram of the configuration information estimation system according to the fourth embodiment.
  • a processing device that realizes all the functions from the diagnostic communication transmission / reception unit 100 to the configuration information estimation unit 300 is arranged on the vehicle-mounted NW. That is, as shown in FIG. 9, a processing device having a diagnostic communication transmission / reception unit 100, a diagnostic system log DB 200, and a configuration information estimation unit 300 is provided inside the automobile 400.
  • the processing device provided in the automobile 400 may be arranged in a form physically connected in the in-vehicle NW, or may be realized on an arbitrary ECU. That is, one or more ECUs may have a diagnostic communication transmission / reception unit 100, a diagnostic system log DB 200, and a configuration information estimation unit 300.
  • FIG. 10 is a configuration diagram of the configuration information estimation system according to the fifth embodiment.
  • a processing device for performing processing on the vehicle-mounted NW is provided inside the automobile 400, and an external device is connected to the automobile 400.
  • the processing device includes a diagnostic communication transmission / reception unit 100
  • the external device includes a diagnostic system log DB 200 and a configuration information estimation unit 300.
  • the processing device may be arranged in a form of being physically connected to the vehicle-mounted NW, or may be realized on an arbitrary ECU.
  • the method of connecting the external device may be a method of physically connecting the device to the automobile 400, or a method of providing an external device as a device on a network such as a cloud and remotely connecting the device to the automobile 400.
  • FIG. 11 is a configuration diagram of the configuration information estimation system according to the sixth embodiment.
  • Example 6 is an example in which the diagnostic system log DB 200 is provided in the processing device in the configuration of Example 5.
  • the diagnostic system log DB 200 may be arranged outside the processing device or the external device, not inside the processing device or the external device. ⁇ Second embodiment ⁇ Subsequently, the second embodiment will be described.
  • the configuration information estimation system estimates the vehicle configuration information of the automobile.
  • FIG. 12 shows an example of vehicle configuration information.
  • the topology of the vehicle-mounted network, ECU information (two tables), and normal communication (frame surrounded by a thick line in the table on the right side) in FIG. 12 are three pieces of information constituting the vehicle configuration information. It should be noted that these information are information in the range of the elemental technologies 1 to 3 described later.
  • the diagnostic communication is used as in the first embodiment.
  • the diagnostic communication is as described with reference to FIG.
  • FIG. 13 shows an automobile network presupposed in the second embodiment.
  • one OBD-II port connects to both the NW_A bus and the vehicle-mounted NWB.
  • the following diagnostic communications (1) and (2) are possible from one OBD-II port.
  • each ECU needs to increase resources and support SNMP to enable the operation of the SNMP agent. There will be a cost.
  • Element technology 1 also uses the transmission and reception of diagnostic communication, which is standardly available in most automobiles. Specifically, the topology of the NW_A bus is estimated using the RTT of diagnostic communication when the occupancy rate of a specific bus is forcibly increased (congested). Details of this technology will be described later.
  • Element technology 1 aims to identify ECUs connected to the same NW_A bus. For example, in the case of the configuration shown in FIG. 14, the following information is estimated.
  • the target of application of element technology 1 is a bus with a domain architecture. It exists, and as shown in FIG. 15, for example, a plurality of buses exist under the control of the GW.
  • the GW routes the diagnostic communication to the appropriate bus. For example, the diagnostic communication having the NW_A-ID corresponding to the ECU-A is transmitted from the GW only to the bus to which the ECU-A is connected.
  • the topology of NW_A is estimated by using the RTT (Round Trip Time) of the diagnostic communication when the occupancy rate of a specific bus is forcibly increased (congested).
  • FIG. 16 shows an example of performing diagnostic communication from the PC to the ECU-A as an example.
  • the RTT of the diagnostic communication is the time from when the PC starts transmitting the diagnostic request (S1) to one ECU until the PC finishes receiving the diagnostic response (S2) from the ECU.
  • FIG. 18 a diagnosis request is transmitted to the ECU-B and the ECU-C several times, and the average value of the RTTs of the ECU-B and the ECU-C is checked. An image of the average value of the RTTs of ECU-B and ECU-C is shown in the lower left of FIG. 18 (and FIGS. 19 and 20).
  • the occupancy rate of the bus to which the ECU-A and the ECU-B are connected is increased by transmitting the diagnosis request to the ECU-A at high frequency.
  • the occupancy rate of the bus is 99%.
  • the diagnosis request is transmitted to the ECU-B and the ECU-C several times, and the ECU-B and the ECU-B are transmitted. Check the average value of RTT of ECU-C.
  • all the NW_A messages transmitted by one ECU are used by utilizing the characteristic of NW_A that the message transmission of the ECU is stopped (bus off) when the collision of the messages transmitted by the ECU occurs abnormally a certain number of times. Identify the NW_A-ID.
  • NW_A-ID NW_A messages for example, 0x301, 0x302
  • NW_A-ID 0x300
  • the OBD-II port installed for access to the in-vehicle NW_A bus is set so that only diagnostic communication can be sent and received in most automobiles in recent years.
  • the transmission cycle of the NW_A message of the target ECU is deviated by using the diagnostic communication, and the deviation of the transmission cycle of the NW_A message is detected by the NW_A-IDS. Then, by associating the detection result with the information of the target ECU, the NW_A-ID of the NW_A message transmitted by the ECU is specified.
  • NW_A-ID of NW_A message transmitted by ECU in the form of using OBD-II port for most automobiles in recent years ⁇ Goal and application of element technology 2 Target>
  • element technology 2 for example, as shown in FIG. 21, the normal NW_A-ID (000 to 6FF) transmitted by the ECU connected to the NW_A is associated with the diagnostic NW_A-ID (700 to 7FF), and is associated with the ECU information. The goal is to do that.
  • Element technology 2 is based on the premise that an IDS exists on the target NW and normally monitors messages.
  • the IDS normally issues an alert when the message transmission time interval is shorter / longer than the design value or when there is an abnormal change in the payload.
  • the IDS alert contains information on a message detected as abnormal (NW_A-ID in the example of an automobile).
  • the vehicle configuration estimation device can acquire IDS alerts in some way.
  • NW_A-ID included in the alert is a normal NW_A-ID transmitted by the target ECU.
  • a plurality of Web crawling scraping results B can be obtained for the keyword A extracted from the response of a certain IoT device.
  • the ECU model number "12345-67890" can be obtained from a certain ECU.
  • A 12345-67890.
  • the result of crawling scraping using A is as shown in FIG. 23.
  • conf (A ⁇ B) (number of results that include both A and B) / (number of results that include A) Then, the result with the highest degree of certainty is extracted as one result.
  • the above-mentioned conventional technology has the following problems.
  • the result with a small amount of information may be selected.
  • “Hybrid Engine Module” has a larger amount of information, so I would like this result to be extracted.
  • "Engine Module” having a large number of appearances is selected.
  • Point 1 is to use the scraping result using only the digits indicating the function based on the naming rule of the ECU model number.
  • the point 2 is to extract the result in which the sum of the support levels of the words included in each Web crawling scraping result is maximized.
  • Element technology 3 aims to estimate the function (name) of each ECU (including NW_B connection). For example, in the example shown in FIG. 24, "ECU-X is an IVI”, “ECU-Y is a TCU”, “ECU-A is an engine ECU”, and the like are estimated. Further, in the element technology 3, it is possible to acquire information that uniquely identifies the device, and in the case of an automobile, it is possible to acquire an "ECU model number".
  • ECU model numbers have a structure in which a digit indicating functional information and a digit indicating the model year are combined.
  • the ECU model number configuration is as follows. ⁇ ⁇ - ⁇ ⁇ ⁇ - ⁇ - ⁇ - ⁇
  • the reason why the absence of search results is reduced by using only the digits related to the function as in point 1 is as follows.
  • the method for extracting digits related to the function is not limited to a specific extraction method, but for example, any of the following extraction methods 1 to 3 can be used.
  • Extraction method 1 the digits related to the function are determined based on the published "information on the naming convention of the ECU model number". For example, if the naming convention is published on the homepage of an automobile company, the digit related to the function is determined based on the published information.
  • Extraction method 2 In the extraction method 2, only the ECU model number related to a certain function is extracted and analyzed, and the digit related to the function is determined based on the analysis result. For example, when only the ECU model number related to the engine ECU is extracted and analyzed, there is a digit whose value does not change in any ECU model number. Determine that digit as the digit related to the function.
  • Extraction method 3 the ECU model number of the ECU mounted on a certain automobile is extracted and analyzed, and the digit related to the function is determined based on the analysis result. For example, when the ECU model number of the ECU mounted on one automobile is extracted and analyzed, there is a digit whose value does not change in any ECU model number. Since the digit is considered to indicate the vehicle type, not the function, the digit excluding the digit is determined as the digit related to the function.
  • sup (X) (number of results containing X) / (number of all web crawling scraping results) Then, the sum of the support levels of the words included in each line is calculated in each line, and the result with the maximum sum is extracted as one result.
  • the Hybrid Engine Module is extracted.
  • Example A1 Examples of the most basic combination of elemental technologies (explain the details of the processing flow) -Examples A2-A4: Examples in which each elemental technology is used alone-Examples A5-A7: Example in which elemental technologies are partially combined
  • Example B3 Example of performing the function according to the present invention from the charging port B1 to B3 may be deployed on the cloud by cutting out other than the in-vehicle NW1 and the message transmission / reception unit 23 described later.
  • Example B4 Example of performing estimation by the function according to the present invention deployed on an external network C. List of examples from the viewpoint of purpose ⁇
  • Example C1 Example used for security analysis in SOC (Security Operation Center), etc.
  • Example C2 Example used for asset management
  • Example C3 Abnormality detection Example to be implemented-Example C4: Example to be utilized for security diagnosis
  • the embodiment A1 is implemented by the function deployment of the embodiment B1. It is then used for the purposes described in C.
  • each embodiment will be described.
  • Example A1 is an example of the most basic combination of core technologies. Here, as an example, the physical deployment of Example B2 will be described.
  • FIG. 27 shows a configuration diagram of the configuration information estimation system in the embodiment A1.
  • the configuration information estimation system includes a component estimation unit 2 and a configuration information estimation result DB 22.
  • the component estimation unit 2 may be referred to as a vehicle configuration estimation device or a network configuration estimation device.
  • the configuration information estimation system may be called a configuration information estimation device.
  • the component estimation unit 2 is connected to the vehicle-mounted NW1 and the website 7 (Web server), and can communicate with them.
  • the component estimation unit 2 includes the ECU basic information acquisition unit 3, the ECU function estimation unit 4, the NW_B topology estimation unit 12, the NW_A bus topology estimation unit 13, the normal NW_A communication estimation unit 18, the message transmission / reception unit 23, and the configuration information acquisition / registration.
  • a unit 24 is provided.
  • the ECU function estimation unit 4 includes a Web search unit 6, a search result DB 8, an exact match extraction unit 9, a specific partial match extraction unit 10, and an estimation unit 11.
  • "exact match extraction unit 9, specific partial match extraction unit 10, estimation unit 11" may be collectively referred to as an estimation unit.
  • the NW_A bus topology estimation unit 13 includes a base RTT calculation unit 14, a congestion RTT calculation unit 15, an RTT comparison unit 16, and an estimation unit 17.
  • the "RTT comparison unit 16 and estimation unit 17" may be collectively referred to as an estimation unit.
  • the normal NW_A communication estimation unit 18 includes a restart command transmission unit 19, a vehicle alert reception unit 20, and an estimation unit 21.
  • message transmission / reception to the vehicle-mounted NW1 and the vehicle-mounted ECU will be performed via the message transmission / reception unit 23.
  • the ECU basic information acquisition unit 3 acquires ECU basic information.
  • the ECU function estimation unit 4 estimates the ECU function.
  • the NW_B topology estimation unit 12 estimates the topology of NW_B.
  • the NW_A bus topology estimation unit 13 estimates the NW_A bus topology.
  • the normal NW_A communication estimation unit 18 estimates the normal NW_A communication.
  • the ECU basic information acquisition unit 3 executes S1031.
  • the ECU basic information acquisition unit 3 executes S1032.
  • S1033 and S1034 are also executed.
  • the ECU basic information acquisition unit 3 executes S1035.
  • the ECU basic information acquisition unit 3 disconnects the vehicle configuration estimation device from the OBD-II port (NW_B) and connects it to the OBD-II port (NW_A).
  • the ECU basic information acquisition unit 3 executes S1036.
  • the ECU basic information acquisition unit 3 executes S1037.
  • S1038 is also executed.
  • the ECU basic information acquisition unit 3 executes S1039.
  • the ECU basic information acquisition unit 3 acquires a local IP address on the vehicle-mounted NF1 by AutoIP or DHCP in accordance with the DoIP regulations.
  • the ECU basic information acquisition unit 3 broadcasts the Vehicle Identification Request (specified by DoIP) on the vehicle-mounted NW1.
  • each ECU on the vehicle-mounted NW1 responds to the Vehicle Identification Response to the Vehicle Identification Request according to the default of DoIP.
  • the ECU basic information acquisition unit 3 receives the Vehicle Identification Response.
  • the ECU basic information acquisition unit 3 records information such as a source IP address included in the received Vehicle Announcement and Vehicle Identification Response in a storage means such as a memory.
  • the recorded information is shown in FIG. 31 (Table 3031). The information to be recorded is not limited to that in Table 3031.
  • the ECU basic information acquisition unit 3 executes the process of S1033.
  • the ECU basic information acquisition unit 3 executes the process of S1034.
  • set i i + 1 and return to S1032-2.
  • S1033-1 the ECU basic information acquisition unit 3 transmits the DoIP Entry Status Request to the IP [i] on the vehicle-mounted NW1.
  • the ECU having the IP [i] on the vehicle-mounted NW1 responds to the DoIP Entry Status Entity to the DoIP Entry Status Entity according to the default of DoIP.
  • the ECU basic information acquisition unit 3 receives the DoIP Entry Status Response.
  • the ECU basic information acquisition unit 3 records the received "Node type” and IP [i] included in the DoIP Entry Status Response in the storage means.
  • An example of the recorded information is shown in FIG. 34 (Table 3032).
  • the variable name may be other than j.
  • S1034-2 the ECU basic information acquisition unit 3 determines whether or not j ⁇ Length (DID) is satisfied, and if Yes, the process proceeds to S1034-3, and if No, the process ends.
  • the ECU basic information acquisition unit 3 transmits a readDataByIdentifier (specified by UDS) in which DID [j] is set in the DID to the IP [i], and receives a response.
  • the ECU basic information acquisition unit 3 records the dataRecord of the received response in the storage means together with the IP [i] and the DID [j]. An example of the recorded information is shown in FIG. 36 (Table 3033).
  • S1035 will be described with reference to FIG. 37.
  • the ECU basic information acquisition unit 3 changes the DID in FIG. 36 (Table 3033) to "explanation" based on the UDS rule, and converts the dataRecord from ASCII (hexadecimal) to a character string.
  • the results after changing / converting FIG. 36 (Table 3033) are as shown in FIG. 38 (Table 3034).
  • the content of the description and the conversion method of dataRecord are not limited to this.
  • the ECU basic information acquisition unit 3 organizes the data in FIG. 38 (Table 3034) with the "IP address” and the "ECU model number” as the composite primary key. The organized results are as shown in FIG. 39 (Table 3035). The method of summarizing is not limited to this.
  • the ECU basic information acquisition unit 3 combines FIG. 39 (Table 3035), FIG. 31 (Table 3031), and FIG. 34 (Table 3032) with the "IP address" as a key. The results are as shown in FIG. 40 (Table 3036).
  • the ECU basic information acquisition unit 3 stores the coupling result of FIG. 40 (Table 3036) in the configuration information estimation result DB 22 via the configuration information acquisition / registration unit 24.
  • S1037 will be described with reference to FIG. 43.
  • the ECU basic information acquisition unit 3 declares the following variables.
  • DID [0xF18C, 0xF190, 0xF191, 0xF194,0xF195, 0xF19F]”
  • ⁇ I 0
  • the variable name may be other than the above.
  • NW_A-ID may be unified with a value other than NW_A-ID.
  • a value other than the above may be added to the DID.
  • S1037-2 it is confirmed whether i ⁇ Length (NW_A-ID) is satisfied, if Yes, the process proceeds to S1037-3, and if No, the process is performed. finish.
  • the ECU basic information acquisition unit 3 executes S1038.
  • S1038 will be described with reference to FIG. 44.
  • the variable name may be other than j.
  • the ECU basic information acquisition unit 3 determines whether or not j ⁇ Length (DID) is satisfied. If Yes, the process proceeds to S1038-3, and if No, the process ends.
  • the ECU basic information acquisition unit 3 transmits a readDataByIdentifier (specified by UDS) in which the DID [j] is set to the DID to the NW_A-ID [i], and receives a response.
  • a readDataByIdentifier specified by UDS
  • the ECU basic information acquisition unit 3 records the received response dataRecord in the storage means together with the NW_A-ID [i] (request NW_A-ID) and the responses NW_A-ID and DID [j].
  • NW_A-ID i
  • NW_A-ID NW_A-ID
  • DID DID
  • S1039 will be described with reference to FIG. 46.
  • the ECU basic information acquisition unit 3 changes the DID in FIG. 45 (Table 3038) to "explanation" based on the UDS rule, and converts the dataRecord from ASCII (hexadecimal) to a character string.
  • the content of the description and the conversion method of dataRecord are not limited to this.
  • the ECU basic information acquisition unit 3 organizes the data of the previous step by using "NW_A-ID” and "ECU model number” as a composite primary key.
  • the organized results are as shown in FIG. 47 (Table 3039). The method of summarizing is not limited to this.
  • the ECU basic information acquisition unit 3 passes the arrangement result of FIG. 47 (Table 3039) to the configuration information estimation result DB 22 via the configuration information acquisition / registration unit 24.
  • the ECU function estimation unit 4 determines whether or not i ⁇ Length (PN) is satisfied, and if Yes, the process proceeds to S1040-3, and if No, the process ends.
  • S1040-3 S1061 was carried out for PN [i]
  • S1040-4 S1091 was carried out for PN [i]
  • S1040-5 S1101 was carried out for PN [i]
  • S1040-6 S1111 is carried out for PN [i].
  • i i + 1 and the process returns to S1044-2.
  • the Web search unit 6 uses the ECU model number acquired from the configuration information estimation result DB 22 as a search word to crawl the Web page.
  • search words two types are used: the entire ECU model number and the digit related to the function of the ECU model number.
  • the digits related to the function of the ECU model number are specified by the method described in the explanation of point 1 of the element technology 3. The specific method is not limited to that.
  • the Web search unit 6 scrapes the ECU model number and the pair information of the function corresponding to the ECU model number from the Web page crawled in the previous step.
  • the Web search unit 6 stores the pair information in the past search result DB 8.
  • the past search result DB 8 has a DB structure as shown in FIG. 50 (Table 3081), for example, ⁇ S1091>.
  • S1091 will be described with reference to FIG. 51.
  • the perfect match extraction unit 9 acquires the pair information whose ECU model numbers completely match from the search result DB 8.
  • S1101 will be described with reference to FIG. 52.
  • the specific partial match extraction unit 10 acquires pair information in which the digits related to the function of the ECU model number match from the search result DB 8.
  • the estimation unit 11 divides the function information into each word among the pair information acquired by the above step. For example, when pair information having the information of the function "Genuine Engine Control Model” is obtained, it is divided into four "Genuine”, “Engine”, “Control”, and "Module”.
  • the estimation unit 11 deletes frequently-used words that are not related to the function from the words divided in the previous step. For example, in the example of the previous step, "Genuine" is deleted. It is not necessary to delete it.
  • the estimation unit 11 calculates the support level of each divided word. Specifically, the support level of the word x is calculated by the following formula. An example of the calculation result of the support degree is shown in FIG. 54 (Table 3111).
  • Support level (x) (number of pair information including x) / (number of all pair information)
  • the estimation unit 11 calculates the sum of the support levels of the words included in the information of the function of each pair information. Then, the pair information having the largest sum is output. In addition to the sum, the one with the largest average or product may be selected.
  • the estimation unit 11 transmits the labeled result described below via the configuration information acquisition / registration unit 24 in FIG. 40 (Table 3036) or FIG. 47 (Table 3039) of the configuration information estimation result DB 22. Add to the line with the appropriate ECU model number. Examples of the results are shown in FIGS. 56 (3112) and 57 (Table 3113). The labeling is as follows.
  • the process is performed using only the pair information that completely matches the ECU model number. Then, the output result is labeled as "exact match”.
  • the process is performed using only the pair information in which the specific part of the ECU model number matches. Then, the output result is labeled as "partial match”.
  • S1120 will be described with reference to FIG. 58.
  • the NW_B topology estimation unit 12 executes S1121.
  • the NW_B topology estimation unit 12 executes S1122.
  • the NW_B topology estimation unit 12 determines whether or not i ⁇ Length (IP) is satisfied, and if Yes, the process proceeds to S1121-3, and if No, the process ends.
  • the NW_B topology estimation unit 12 executes ICMP traceroute for the IP [i] on the vehicle-mounted NW1 and records the result in the storage means.
  • the NW_B topology estimation unit 12 retrieves all ECU model numbers from FIG. 56 (Table 3112) of the configuration information estimation result DB 22 via the configuration information acquisition / registration unit 24. Next, the NW_B topology estimation unit 12 deletes the duplicated ECU model numbers taken out. Then, the ECU model number from which the duplication has been deleted and the physical ECU have a one-to-one correspondence. An example of the result is shown in FIG.
  • the NW_B topology estimation unit 12 has acquired the "ECU model number”, "MAC address”, and "MAC address” in FIG. 56 (Table 3112) acquired from the configuration information estimation result DB 22 via the configuration information acquisition / registration unit 24. Based on the "IP address", a network interface is added to the information in FIG. The results are shown in FIG.
  • the NW_B topology estimation unit 12 uses all the information in FIG. 56 (Table 3112) acquired from the configuration information estimation result DB 22 via the configuration information acquisition / registration unit 24 to be appropriate for the ECU or the interface of the ECU. Assign to. The result is as shown in FIG. 56 (Table 3112) acquired from the configuration information estimation result DB 22 via the configuration information acquisition / registration unit 24 to be appropriate for the ECU or the interface of the ECU. Assign to. The result is as shown in FIG.
  • the NW_B topology estimation unit 12 has a connection relationship between the OBD-II port and the network interface (and thus the physical ECU) of the OBD-II port and the ECU by the NW_B cable of the IP router based on the traceroute record (FIG. 62). Organize. If there are multiple ECUs under the same IP router, it is estimated that those ECUs and the IP router are connected by one NW_B switch. Further, even when a plurality of ECUs exist in the in-vehicle network but no IP router exists, it is presumed that those ECUs are connected by one NW_B switch. The results are shown in FIG. The method of organizing the connection relationship between ECUs is not limited to this.
  • the NW_B topology estimation unit 12 stores the estimation result of FIG. 65 in the configuration information estimation result DB 22 via the configuration information acquisition / registration unit 24.
  • the base RTT calculation unit 14 executes S1141.
  • the congestion RTT calculation unit 15 executes S1151.
  • the congestion RTT calculation unit 15 executes S1152.
  • the RTT comparison unit 16 executes S1161.
  • the estimation unit 17 executes S1171.
  • the estimation unit 17 executes S1172.
  • the base RTT calculation unit 14 transmits the TesterPresent request specified by UDS to the NW_A-ID [i] 100 times at 200 ms intervals. Then, the response to it is received. Further, the transmission time and the reception time thereof are recorded in the storage means. An example of the recorded information is shown in FIG. The transmission interval and the number of transmissions are not limited to this.
  • the base RTT calculation unit 14 calculates the statistical value of the response time (hereinafter referred to as the pace response time) using the record of the previous step (FIG. 68). Then, the result is recorded together with NW_A-ID [i] (example: FIG. 69 (Table 3141)). The difference between the time when the TesterPresent was transmitted by the request NW_A-ID (0x700 in FIG. 68) and the time when the TesterPresent was received by the response NW_A-ID (0x708 in FIG. 68) immediately after that is defined as the base response time. do. In addition, the average value / maximum value, minimum value, and standard deviation are calculated as statistical values. However, other statistical values may be calculated.
  • the congestion RTT calculation unit 15 declares the following variables.
  • the variable name may be other than the above. Further, the contents of NW_A-ID may be unified with a value other than NW_A-ID.
  • the congestion RTT calculation unit 15 determines whether or not j ⁇ Length (NW_A-ID) is satisfied. If Yes, the process proceeds to S1151-5, and if No, the process ends. In S1151-5, the congestion RTT calculation unit 15 executes S1152 and returns to S1151-2.
  • the congestion RTT calculation unit 15 continues to transmit the TesterPresent request specified by UDS to the NW_A-ID [i] at intervals of 0.5 ms until the end of S1152, and NW_A-ID [i]. Congests the NW_A bus to which the NW_A message is transmitted.
  • the transmission interval is not limited to this.
  • the congestion RTT calculation unit 15 transmits the TesterPresent request specified by UDS to the NW_A-ID [j] 100 times at 200 ms intervals. Then, the response to it is received. Further, the transmission time and the reception time thereof are recorded in the storage means. An example of the recorded information is shown in FIG. The transmission interval and the number of transmissions are not limited to this.
  • the congestion RTT calculation unit 15 calculates the statistical value of the response time (hereinafter referred to as the response time at the time of congestion) using the recording of the previous step.
  • the results are referred to as NW_A-ID [i] (referred to as congestion NW_A-ID in FIG. 73 (Table 3151)) and NW_A-ID [j] (referred to as statistical value calculation target NW_A-ID in FIG. 73 (Table 3151)).
  • NW_A-ID [i] referred to as congestion NW_A-ID in FIG. 73 (Table 3151)
  • NW_A-ID [j] referred to as statistical value calculation target NW_A-ID in FIG. 73 (Table 3151)
  • record it in the storage means An example of the recorded information is shown in FIG. 73 (Table 3151).
  • the difference between the time when the TesterPresent is transmitted by the request NW_A-ID and the time when the TesterPresent is received by the response NW_A-ID immediately after that is defined as the congestion response time.
  • the average value / maximum value, minimum value, and standard deviation are calculated as statistical values. However, other statistical values may be calculated ⁇ S1162>.
  • the RTT comparison unit 16 groups the congestion NW_A-ID of each row in FIG. 75 (Table 3161) and the statistical value calculation target NW_A-ID. For example, 0x700 and 0x724 are one group, 0x700 and 0x7E0 are one group, 0x724 and 0x7E0 are one group, and 0x750 and 0x7E1 are one group.
  • the RTT comparison unit 16 puts together the groups created in the previous step as much as possible. For example, 0x700 and 0x724 are one group, 0x700 and 0x7E0 are one group, and 0x724 and 0x7E0 are one group, so these three are considered to be one group.
  • the results are shown in FIG. 76 (Table 3162).
  • the estimation unit 17 extracts all ECU model numbers from the information corresponding to FIG. 56 (Table 3112) stored in the configuration information estimation result DB 22. Next, the duplicated ECU model number taken out is deleted. Then, the ECU model number from which the duplication has been deleted and the physical ECU have a one-to-one correspondence. The results are as shown in FIG. 78.
  • the estimation unit 17 adds the information of the request NW_A-ID to FIG. 78 based on the information corresponding to FIG. 56 (Table 3112) stored in the configuration information estimation result DB 22. The results are shown in FIG. 79.
  • a row in which any of the statistical values on the side of FIG. 73 (Table 3151) is increased by 50% or more from that of FIG. 69 (Table 3141) is extracted from FIG. 73 (Table 3151).
  • the extraction results are as shown in FIG. 75 (Table 3161).
  • the extraction method in FIG. 75 (Table 3161) is not limited to this.
  • the estimation unit 17 groups the congestion NW_A-ID of each row in FIG. 75 (Table 3161) and the statistical value calculation target NW_A-ID. For example, 0x700 and 0x724 are one group, 0x700 and 0x7E0 are one group, 0x724 and 0x7E0 are one group, and 0x750 and 0x7E1 are one group.
  • the estimation unit 17 puts together the groups created in the previous step as much as possible. For example, 0x700 and 0x724 are one group, 0x700 and 0x7E0 are one group, and 0x724 and 0x7E0 are one group, so these three are considered to be one group.
  • the results are shown in FIG. 76 (Table 3162).
  • the estimation unit 17 determines that the ECU that responds to the NW_A message of the NW_A-ID grouped in one group in FIG. 76 (Table 3162) is connected to the same NW_A bus. .. Then, the estimation unit 17 converts the information in FIG. 79 into a topology diagram (FIG. 81) of the NW_A bus based on the determination result.
  • the estimation unit 17 appropriately allocates all the information in FIG. 56 (Table 3112) passed to the configuration information estimation result DB 22 (configuration information organization unit) to the ECU. The result is as shown in FIG. 82.
  • the estimation unit 17 connects the ECU found in the previous step with the NW_A bus. The result is as shown in FIG.
  • the estimation unit 17 stores the information shown in FIG. 83 in the configuration information estimation result DB 22 via the configuration information acquisition / registration unit 24 ⁇ S1180>.
  • S1180 by the normal NW_A communication estimation unit 18 will be described with reference to FIG. 84.
  • the restart command transmission unit 19 executes S1191. In S1180-2, the restart command transmission unit 19 executes S1192. In S1180-3, the vehicle alert receiving unit 20 executes S1201. In S1180-4, the vehicle alert receiving unit 20 executes S1211.
  • the restart command transmission unit 19 declares the following variables.
  • the variable name may be other than the above. Further, the contents of NW_A-ID may be unified with a value other than NW_A-ID.
  • the transmission interval, the number of transmissions, and the ResetType are not limited to this.
  • the restart command transmission unit 19 records the time when the ECUReset request was transmitted in the previous step in the storage means together with the NW_A-ID [i]. An example of the recorded information is shown in FIG.
  • the ECU on the vehicle-mounted network 1 transmits a NW_A message of a certain NW_A-ID at a constant (design value) time interval (transmission interval). Further, the NW_A-IDS on the vehicle-mounted network 1 issues an alert when the transmission interval of the NW_A message of a certain NW_A-ID greatly deviates from the design value. It is assumed that the alert contains the alarm time and the NW_A-ID of the detected NW_A message.
  • the ECU that has received the ECU Reset temporarily stops the transmission of the NW_A message in order to restart the ECU. Further, after the restart, the transmission of the NW_A message is restarted after an arbitrary time. Therefore, the transmission interval of the NW_A message transmitted by the ECU that has received the ECU Reset is temporarily increased or decreased.
  • the NW_A-IDS determines this as an abnormality and issues an alert.
  • the vehicle alert receiving unit 20 records the alert of the NW_A-IDS in the storage means together with the time. An example of the stored information is shown in FIG.
  • the estimation unit 21 associates the NW_A-ID recorded as the information shown in FIG. 87 with the NW_A-ID recorded as the information shown in FIG. 89. When associating, it is based on the similarity of recorded times. An example of the result of the association is shown in FIG. 91 (Table 3211).
  • FIG. 94 is a block diagram of the system in the A2 embodiment. As shown in FIG. 94, the configuration in the embodiment A2 includes only the ECU function estimation unit 4 corresponding to the element technology 3 as the estimation unit. The processing of each part is the same as the processing described in the first embodiment.
  • FIG. 95 is a configuration diagram of the system in the A3 embodiment. As shown in FIG. 95, the configuration in the embodiment A3 includes only the NW_A bus topology estimation unit 13 corresponding to the element technology 1 as the estimation unit. The processing of each part is the same as the processing described in the first embodiment.
  • FIG. 96 is a block diagram of the system in the A4 embodiment. As shown in FIG. 96, the configuration in the embodiment A4 includes only the normal NW_A communication estimation unit 18 corresponding to the element technology 2 as the estimation unit. The processing of each part is the same as the processing described in the first embodiment.
  • FIG. 97 is a configuration diagram of the system in the A5 embodiment.
  • the configuration in the embodiment A5 is a configuration in which the normal NW_A communication estimation unit 18 is excluded from the configuration of the embodiment A1 (FIG. 27).
  • the processing of each part is the same as the processing described in the first embodiment.
  • FIG. 98 is a block diagram of the system in the A6 embodiment.
  • the configuration in the embodiment A6 is a configuration in which the NW_A bus topology estimation unit 13 is excluded from the configuration of the embodiment A1 (FIG. 27).
  • the processing of each part is the same as the processing described in the first embodiment.
  • FIG. 99 is a block diagram of the system in the A7 embodiment.
  • the configuration in the embodiment A7 is a configuration in which the ECU function estimation unit 4 is excluded from the configuration of the embodiment A1 (FIG. 27).
  • the processing of each part is the same as the processing described in the first embodiment.
  • Example B1 is an example of deploying the configuration information estimation system according to the present invention on an in-vehicle NW.
  • FIG. 100 is a configuration diagram of an automobile (vehicle-mounted NW) in the embodiment B1.
  • the vehicle configuration estimation device 2 and the configuration information estimation result DB 22 are provided as the functions of the ECU on the vehicle-mounted NW.
  • the configuration information estimation result DB 22 may be provided on the cloud.
  • the vehicle configuration estimation device 2 one or a plurality of functional units other than the message transmission / reception unit 23 may be provided on the cloud.
  • the ECU function estimation unit 4 in the vehicle configuration estimation device 2 may be provided on the cloud.
  • Example B2 is an example in which the configuration information estimation system (device) according to the present invention is directly connected to the OBD-II port.
  • FIG. 101 is a configuration diagram of the system in the second embodiment. As shown in FIG. 101, the configuration information estimation system connects directly to the OBD-II port.
  • the configuration information estimation result DB 22 may be provided on the cloud.
  • the vehicle configuration estimation device 2 one or a plurality of functional units other than the message transmission / reception unit 23 may be provided on the cloud.
  • the ECU function estimation unit 4 in the vehicle configuration estimation device 2 may be provided on the cloud.
  • FIG. 102 shows the configuration of the system in Example B3.
  • the configuration information estimation system according to the present invention is provided in the charger and connected to the charging port. The processing of the configuration information estimation system is performed via the charging port.
  • the configuration information estimation result DB 22 may be provided on the cloud.
  • the vehicle configuration estimation device 2 one or a plurality of functional units other than the message transmission / reception unit 23 may be provided on the cloud.
  • the ECU function estimation unit 4 in the vehicle configuration estimation device 2 may be provided on the cloud.
  • FIG. 103 shows the configuration of the system in Example B4.
  • the configuration information estimation system according to the present invention is provided on the external network, and the processing of the configuration information estimation system is executed via the external network.
  • Example C1 is an example in which the configuration information estimation system is utilized for security analysis in SOC or the like.
  • FIG. 104 is a system configuration diagram in Example C1.
  • this system includes a configuration information acquisition unit 30, a security analysis unit 31, and an analysis result presentation unit 32 in addition to the vehicle configuration estimation device 2 connected to the automobile and the configuration information estimation result DB 22. Each part is connected as shown in the figure.
  • the configuration information acquisition unit 30 extracts necessary configuration information from the configuration information estimation result DB 22 and passes it to the security analysis unit 31.
  • the security analysis unit 31 performs more advanced security analysis using the vehicle configuration information estimated by the vehicle configuration estimation device 2. Then, the analysis result is passed to the analysis result presentation unit 32.
  • the analysis result presentation unit 32 receives the analysis result, processes it appropriately, and presents the result to the analyst.
  • the analyst is not limited to humans, and may be a program that uses the analysis results to perform another analysis.
  • the security analysis performed by the security analysis unit 31 is not limited to a specific one, but for example, there are examples listed below.
  • Example C2 is an example of utilizing the configuration information estimation system for asset management.
  • FIG. 105 is a system configuration diagram in Example C2.
  • this system includes a configuration information acquisition unit 30, an asset management unit 33, and a management information presentation unit 34, in addition to the vehicle configuration estimation device 2 connected to the automobile and the configuration information estimation result DB 22. Each part is connected as shown in the figure.
  • the configuration information acquisition unit 30 extracts necessary configuration information from the configuration information estimation result DB 22 and passes it to the asset management unit 33.
  • the asset management unit 33 holds management information, and manages whether or not there is an ECU that is not included in the management information or an ECU that is out of support based on the received configuration information. At this time, public information such as the support status of the ECU software is also used.
  • the management information presentation unit 34 acquires management information from the asset management unit 33, performs appropriate processing (for example, extracts and organizes only the device name and address information of the ECU that is not in the management information), and presents the result to the manager.
  • the administrator is not limited to a person, and may be a program that performs another analysis using the management information.
  • Example C3 is an example of utilizing the configuration information estimation system for abnormality detection.
  • FIG. 106 is a system configuration diagram in Example C3.
  • this system includes a configuration information acquisition unit 30 and an abnormality detection unit 35 in addition to the vehicle configuration estimation device 2 connected to the automobile and the configuration information estimation result DB 22. Each part is connected as shown in the figure.
  • the configuration information acquisition unit 30 extracts necessary configuration information from the configuration information estimation result DB 22 and passes it to the abnormality detection unit 35.
  • the abnormality detection unit 35 detects an abnormal state of the vehicle configuration information by using the information of the DB in which the normal vehicle configuration information is stored, the abnormality detection rule, and the public information (for example, the information of the vulnerability DB). Furthermore, the abnormality detection result is notified to the automobile manager and analysts such as SOC.
  • the anomaly detection method is not limited to a specific method, but for example, there are examples listed below.
  • Machine learning is performed on the vehicle configuration information of a normal car, and machine learning-based abnormality detection is performed based on the learned model.
  • Example C4 is an example of utilizing the configuration information estimation system for security diagnosis.
  • FIG. 107 is a system configuration diagram in Example C4.
  • this system includes a configuration information acquisition unit 30, a security diagnosis unit 36, and a diagnosis result presentation unit 37, in addition to the vehicle configuration estimation device 2 connected to the automobile and the configuration information estimation result DB 22. Each part is connected as shown in the figure.
  • the configuration information acquisition unit 30 extracts necessary configuration information from the configuration information estimation result DB 22 and passes it to the security diagnosis unit 36. Based on the received configuration information, the security diagnosis unit 36 diagnoses whether or not there is an ECU having a security problem in the automobile. At this time, it is confirmed whether or not there is a problem by using public information such as the support status of the ECU software.
  • the diagnosis result presentation unit 37 acquires the diagnosis result from the security diagnosis unit 36, performs appropriate processing (for example, scoring the diagnosis result, etc.), and presents the result to the administrator.
  • the administrator is not limited to a person, and may be a program that performs another analysis using the management information.
  • the security diagnosis unit 36 compares the vehicle configuration information (blacklist) stored in the diagnosis rule with the vehicle configuration information of the configuration information estimation result DB 22, and if there is information corresponding to the blacklist, points out the vulnerability.
  • the device consisting of the information estimation unit 300, the device consisting of the diagnostic communication transmission / reception unit 100 and the configuration information estimation unit 300, the device consisting of the diagnostic communication transmission / reception unit 100, the device consisting of the diagnostic system log DB 200, and the device consisting of the configuration information estimation unit 300 are Both can be realized, for example, by having a computer execute a program. This computer may be a physical computer or a virtual machine in the cloud.
  • system, the device, and the functional unit described in the second embodiment can also be realized by, for example, causing a computer to execute a program.
  • This computer may be a physical computer or a virtual machine in the cloud.
  • the subject on which the above program operates is called a "device".
  • the device can be realized by executing a program corresponding to the processing performed by the device using hardware resources such as a CPU and a memory built in the computer.
  • the above program can be recorded on a computer-readable recording medium (portable memory, etc.), stored, and distributed. It is also possible to provide the above program through a network such as the Internet or e-mail.
  • FIG. 108 is a diagram showing an example of the hardware configuration of the computer.
  • the computer of FIG. 108 has a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, which are connected to each other by a bus BS, respectively.
  • a bus BS bus BS
  • some devices may not be provided.
  • a device that does not display may not be provided with the display device 1006.
  • the program that realizes the processing on the computer is provided by, for example, a recording medium 1001 such as a CD-ROM or a memory card.
  • a recording medium 1001 such as a CD-ROM or a memory card.
  • the program is installed in the auxiliary storage device 1002 from the recording medium 1001 via the drive device 1000.
  • the program does not necessarily have to be installed from the recording medium 1001, and may be downloaded from another computer via the network.
  • the auxiliary storage device 1002 stores the installed program and also stores necessary files, data, and the like.
  • the memory device 1003 reads and stores the program from the auxiliary storage device 1002 when there is an instruction to start the program.
  • the CPU 1004 realizes the function related to the device according to the program stored in the memory device 1003.
  • the interface device 1005 is used as an interface for connecting to a network, and functions as a transmitting unit and a receiving unit.
  • the display device 1006 displays a GUI (Graphical User Interface) or the like by a program.
  • the input device 1007 is composed of a keyboard, a mouse, buttons, a touch panel, and the like, and is used for inputting various operation instructions.
  • the output device 1008 outputs the calculation result.
  • vehicle configuration information is transmitted and received by transmitting and receiving diagnostic communication using a diagnostic communication protocol (DoCAN, DoIP, UDS, etc.) that is supported as standard in each ECU. It was decided to estimate the vehicle configuration information by collecting information useful for estimation and analyzing the collected information. This eliminates the need to increase resources or support new protocols in estimating vehicle configuration information, reducing additional costs.
  • a diagnostic communication protocol DoCAN, DoIP, UDS, etc.
  • This specification discloses at least the network configuration estimation device, the network configuration estimation method, and the program according to the following items.
  • (Section 1) A network configuration estimation device that estimates the configuration information of the internal network in the target device. With a diagnostic communication transmitter / receiver that sends a message to the electronic control device on the internal network and receives a response to the message using a diagnostic communication method that is standardly supported by the electronic control device on the internal network.
  • a network configuration estimation device including a configuration information estimation unit that estimates configuration information of the internal network based on the response obtained by the diagnostic communication transmission / reception unit.
  • the configuration information estimation unit is Based on the response, the existence confirmation unit that confirms the existence of the electronic control device on the internal network, and A topology estimation unit that estimates the topology of the internal network based on the existence confirmation result of the electronic control device by the existence confirmation unit, and a topology estimation unit.
  • the network configuration estimation device according to item 1, further comprising an information extraction unit that extracts information about an electronic control device on the internal network based on the response.
  • the diagnostic communication transmission / reception unit transmits a message to each of the first network and the second network in the internal network, receives the response, and receives the response.
  • the configuration information estimation unit confirms the existence of the electronic control device connected to the first network by the response of the message transmitted to the first network, and the response of the message transmitted to the second network to the second network.
  • the network configuration estimation device according to item 1 or 2, which confirms the existence of the connected electronic control device.
  • the diagnostic communication transmission / reception unit transmits a message in which a data ID is set, receives the response, and receives the response.
  • the network configuration estimation device according to any one of items 1 to 3, wherein the configuration information estimation unit extracts information corresponding to the data ID from a response to a message in which the data ID is set.
  • a network configuration estimation device that estimates the configuration information of the internal network in the target device.
  • a device that sends a message to an electronic control device on the internal network and receives a response to the message using a diagnostic communication method that is standardly supported by the electronic control device on the internal network.
  • a network configuration estimation device including a configuration information estimation unit that estimates configuration information of the internal network based on the response.
  • (Section 6) A network configuration estimation device that estimates the configuration information of the internal network in the target device.
  • a base RTT calculation unit that calculates the round trip time of the first electronic control device on the internal network using a diagnostic communication method that is standardly supported by the electronic control device on the internal network in a non-congested state.
  • a congestion RTT calculation unit that calculates the round trip time of the first electronic control device in a state of congestion when a diagnosis request is frequently transmitted to the second electronic control device. By comparing the round trip time in the non-congested state and the round trip time in the congested state, whether or not the first electronic control device and the second electronic control device are connected to the same bus.
  • a network configuration estimator with an estimator for estimating. (Section 7) A network configuration estimation device that estimates the configuration information of the internal network in the target device.
  • a restart command transmitter that sends a restart command to a target electronic control device on the internal network using a diagnostic communication method that is standardly supported by the electronic control device on the internal network.
  • An alert receiving unit that receives an alert generated by the restart command from the internal network
  • a network configuration estimation device including an estimation unit that estimates the ID included in the alert to be an ID of normal communication transmitted by the target electronic control device.
  • a network configuration estimation device that estimates the configuration information of the internal network in the target device. Using the entire model number of the target electronic control device acquired using the diagnostic communication method standardly supported by the electronic control device on the internal network, and the digits related to the function in the model number, the function of the electronic control device can be obtained.
  • Web search unit to search and A network configuration estimation device including an estimation unit that estimates the function of maximizing the sum of the support levels of words included in the search results obtained by the Web search unit as the function of the target electronic control device.
  • (Section 9) It is a network configuration estimation method executed by the network configuration estimation device that estimates the configuration information of the internal network in the target device.
  • a network configuration estimation method including a step of estimating the configuration information of the internal network based on the response.
  • (Section 10) A program for making a computer function as each part in the network configuration estimation device according to any one of the items 1 to 8.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の電子制御装置に対してメッセージを送信し、当該メッセージに対する応答を受信する診断通信送受信部と、前記診断通信送受信部により得られた前記応答に基づいて、前記内部ネットワークの構成情報を推定する構成情報推定部とを備える。

Description

ネットワーク構成推定装置、ネットワーク構成推定方法、及びプログラム
　本発明は、自動車等の対象装置における内部ネットワークの構成情報を推定する技術に関連するものである。
　近年、コネクテッドカー社会の到来とともに自動車へのサイバー攻撃の脅威が増加している。すなわち、自動車に搭載されるコネクティッド機能により、自動車がネットワークを通して外部と接続できるようになることで、逆に外部からのサイバー攻撃の脅威が増加する。
　そのため、自動車へのサイバー攻撃を検知し、その攻撃の経路・原因を特定し、その攻撃に対処する事後対策の実施が重要となっている。攻撃の経路・原因を正確に特定するには、車載ネットワーク（ＮＷ）の構成（トポロジ）やＮＷ上の情報処理装置（ＩＶＩやＴＣＵ等）や電子制御装置（ＥＣＵ）に関する情報が必要である。
　上記以外にも、アセット管理や構成の異常検知など、様々な目的を達成するためにも車両構成情報は必要である。
　ＮＷの構成等を推定する従来技術として、例えば非特許文献１に開示された技術がある。非特許文献１に開示された技術では、ＳＮＭＰを用いて対象ＮＷ内の各ＳｗｉｔｃｈのＭＡＣアドレス転送テーブルを取得し、取得した情報を解析することで対象ＮＷのＬ２トポロジを推定する。
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).
　車載ＮＷのトポロジや各ＥＣＵの情報を取得するために、非特許文献１に開示されているＳＮＭＰベースの方法を用いることが考えられる。しかし、ＳＮＭＰベースの方法で車載ＮＷのトポロジや各ＥＣＵの情報を取得するためには、各ＥＣＵに対してＳＮＭＰエージェントの動作を可能とするためのリソース増強やＳＮＭＰのサポートをすることが必要となり、追加のコストがかかるという問題がある。
　本発明は上記の点に鑑みてなされたものであり、対象装置における内部ネットワークの構成装置に対してリソースの増強や新たなプロトコルのサポートを行うことなく、当該内部ネットワークの構成情報を推定することを可能とする技術を提供することを目的とする。
　開示の技術によれば、対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
　前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の電子制御装置に対してメッセージを送信し、当該メッセージに対する応答を受信する診断通信送受信部と、
　前記診断通信送受信部により得られた前記応答に基づいて、前記内部ネットワークの構成情報を推定する構成情報推定部と
　を備えるネットワーク構成推定装置が提供される。
　開示の技術によれば、対象装置における内部ネットワークの構成装置に対してリソースの増強や新たなプロトコルのサポートを行うことなく、当該内部ネットワークの構成情報を推定することが可能となる。
車載構成情報の例を示す図である。 診断通信の例を説明するための図である。 第１の実施の形態における構成情報推定システムの構成例を示す図である。 診断通信送受信部の処理手順例を説明するためのフローチャートである。 構成情報推定部の処理手順例を説明するためのフローチャートである。 第１の実施の形態における実施例１におけるシステム構成図である。 第１の実施の形態における実施例２におけるシステム構成図である。 第１の実施の形態における実施例３におけるシステム構成図である。 第１の実施の形態における実施例４におけるシステム構成図である。 第１の実施の形態における実施例５におけるシステム構成図である。 第１の実施の形態における実施例６におけるシステム構成図である。 車両構成情報の一例を示す図である。 第２の実施の形態で前提としている自動車のネットワークを示す図である。 要素技術１の目標を説明するための図である。 要素技術１の適用対象を説明するための図である。 診断通信のＲＴＴを説明するための図である。 要素技術１の推定方法を説明するための図である。 要素技術１の推定手順を説明するための図である。 要素技術１の推定手順を説明するための図である。 要素技術１の推定手順を説明するための図である。 要素技術２の目標を説明するための図である。 要素技術２のポイントと手順を説明するための図である。 要素技術３に関する従来技術を説明するための図である。 要素技術３の目標を説明するための図である。 要素技術３の推定方法を説明するための図である。 要素技術３の推定方法を説明するための図である。 第２の実施の形態における実施例Ａ１の構成図である。 第２の実施の形態における実施例Ａ１の全体の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＳ１０３０の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＳ１０３１の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１の表３０３１を示す図である。 第２の実施の形態における実施例Ａ１のＳ１０３２の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＳ１０３３の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１の表３０３２を示す図である。 第２の実施の形態における実施例Ａ１のＳ１０３４の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１の表３０３３を示す図である。 第２の実施の形態における実施例Ａ１のＳ１０３５の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１の表３０３４を示す図である。 第２の実施の形態における実施例Ａ１の表３０３５を示す図である。 第２の実施の形態における実施例Ａ１の表３０３６を示す図である。 第２の実施の形態における実施例Ａ１のＳ１０３６の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１の表３０３７を示す図である。 第２の実施の形態における実施例Ａ１のＳ１０３７の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＳ１０３８の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１の表３０３８を示す図である。 第２の実施の形態における実施例Ａ１のＳ１０３９の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１の表３０３９を示す図である。 第２の実施の形態における実施例Ａ１のＳ１０４０の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＳ１０６１の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１の表３０８１を示す図である。 第２の実施の形態における実施例Ａ１のＳ１０９１の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＳ１１０１の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＳ１１１１の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１の表３１１１を示す図である。 第２の実施の形態における実施例Ａ１の支持度の和を説明する際に参照する表である。 第２の実施の形態における実施例Ａ１の表３１１２を示す図である。 第２の実施の形態における実施例Ａ１の表３１１３を示す図である。 第２の実施の形態における実施例Ａ１のＳ１１２０の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＳ１１２１の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のトレースルートの記録の例を示す図である。 第２の実施の形態における実施例Ａ１のＳ１１２２の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＥＣＵ型番と物理的なＥＣＵの１対１対応を示す図である。 第２の実施の形態における実施例Ａ１のネットワークインターフェースの設定を示す図である。 第２の実施の形態における実施例Ａ１のＥＣＵ情報の割り当てを示す図である。 第２の実施の形態における実施例Ａ１の接続関係を示す図である。 第２の実施の形態における実施例Ａ１のＳ１１３０の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＳ１１４１の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１の送信時刻と受信時刻の記録を示す図である。 第２の実施の形態における実施例Ａ１の表３１４１を示す図である。 第２の実施の形態における実施例Ａ１のＳ１１５１の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＳ１１５２の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１の送信時刻と受信時刻の記録を示す図である。 第２の実施の形態における実施例Ａ１の表３１５１を示す図である。 第２の実施の形態における実施例Ａ１のＳ１１６１の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１の表３１６１を示す図である。 第２の実施の形態における実施例Ａ１の表３１６２を示す図である。 第２の実施の形態における実施例Ａ１のＳ１１７１の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＥＣＵ型番と物理的なＥＣＵの１対１対応を示す図である。 第２の実施の形態における実施例Ａ１のＥＣＵに要求ＮＷ＿Ａ－ＩＤを追加することを示す図である。 第２の実施の形態における実施例Ａ１のＳ１１７２の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＮＷ＿Ａトポロジの推定結果を示す図である。 第２の実施の形態における実施例Ａ１のＮＷ＿ＡトポロジにＥＵＣ情報を追加したことを示す図である。 第２の実施の形態における実施例Ａ１のＧＷ同士の接続を示す図である。 第２の実施の形態における実施例Ａ１のＳ１１８０の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＳ１１９１の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＳ１１９２の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＥＣＵＲｅｓｅ送信時刻の記録を示す図である。 第２の実施の形態における実施例Ａ１のＳ１２０１の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１のＮＷ＿Ａ－ＩＤＳのアラート発報時刻の記録を示す図である。 第２の実施の形態における実施例Ａ１のＳ１２１１の処理を示すフローチャートである。 第２の実施の形態における実施例Ａ１の表３２１１を示す図である。 第２の実施の形態における実施例Ａ１の追加後の結果を示す図である。 第２の実施の形態における実施例Ａ１の表３２１２を示す図である。 第２の実施の形態における実施例Ａ２の構成図である。 第２の実施の形態における実施例Ａ３の構成図である。 第２の実施の形態における実施例Ａ４の構成図である。 第２の実施の形態における実施例Ａ５の構成図である。 第２の実施の形態における実施例Ａ６の構成図である。 第２の実施の形態における実施例Ａ７の構成図である。 第２の実施の形態における実施例Ｂ１の構成図である。 第２の実施の形態における実施例Ｂ２の構成図である。 第２の実施の形態における実施例Ｂ３の構成図である。 第２の実施の形態における実施例Ｂ４の構成図である。 第２の実施の形態における実施例Ｃ１の構成図である。 第２の実施の形態における実施例Ｃ２の構成図である。 第２の実施の形態における実施例Ｃ３の構成図である。 第２の実施の形態における実施例Ｃ４の構成図である。 装置のハードウェア構成例を示す図である。
　以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。
　以下で説明する本実施の形態（第１及び第２の実施の形態）では、構成情報の推定対象となる内部ネットワークを備える対象装置として、自動車を例に挙げて説明するが、本発明に係る技術を適用可能な対象装置は自動車に限定されるわけではない。本発明に係る技術は、自動車と同様に「診断通信によってネットワーク上の機器から情報を取得可能である」という特性を有する対象装置に対して適用可能である。また、第２の実施の形態で説明する要素技術については、少なくとも、その適用対象に記載の条件を持つものに適用可能である。
　本実施の形態では、車載ネットワーク（ＮＷ）の構成、ＮＷ上の情報処理装置（ＩＶＩやＴＣＵ等）に関する情報、及び電子制御装置（ＥＣＵ）に関する情報を総称して「車両構成情報」と呼称する場合がある。「車両構成情報」は、「内部ネットワークの構成情報」の例である。
　なお、ＴＣＵはTelematics Control Unitの略称であり、ＩＶＩはIn-Vehicle Infotainmentの略称であり、ＥＣＵはElectronic Control Unitの略称である。
　以下の説明（及び図面）において、ＣＡＮ（登録商標）をＮＷ＿Ａ（ネットワークＡ）と呼称し、Ｅｔｈｅｒｎｅｔ（登録商標）をＮＷ＿Ｂ（ネットワークＢ）と呼称する。なお、ＣＡＮ（登録商標）はＣｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋの略称である。
　ただし、以下の説明で登場するＮＷ＿ＡはＣＡＮ（登録商標）以外のネットワークでもよく、ＮＷ＿ＢはＥｔｈｅｒｎｅｔ（登録商標）以外のネットワークであってもよい。例えば、ＮＷ＿Ａは、ＦｌｅｘＲａｙ（登録商標）、ＬＩＮ、Ｋ－Ｌｉｎｅ等であってもよい。
　本実施の形態では、対象車両のネットワークの構成情報の推定を実現する手法について説明する。対象車両のネットワークの構成情報は例えば下記の情報である。
　・対象ネットワーク（車載ＮＷ＿Ｂと車載ＮＷ＿Ａ）のトポロジ
　・ネットワークに接続している装置に関する情報（型番やソフトウェアバージョン等）
　・各装置の機能（＝名称）に関する情報
　・各装置が行う正常通信の情報（特に各装置が送信している正常通信の情報）
　以下、本発明の実施の形態として、第１の実施の形態と第２の実施の形態を説明する。第１の実施の形態において基本的な構成と動作を説明し、第２の実施の形態ではより具体的な構成と動作を説明する。第１の実施の形態において説明する構成及び処理と、第２の実施の形態において説明する構成及び処理は、組み合わせて実施することが可能である。
――――――――――第１の実施の形態――――――――――
　（車両構成情報の例）
　本実施の形態では、構成情報推定システムが自動車の車両構成情報を推定する。図１に車両構成情報の一例を示す。図１の例では、ＮＷ＿Ｂに接続されるＴＣＵとＩＶＩが、ＧＷ（Ｇａｔｅｗａｙ－ＥＣＵ）にスター型に接続されている。また、ＧＷにはＮＷ＿Ａが接続され、ＮＷ＿Ａに接続されたＥＣＵがＧＷ配下のＮＷ＿Ａにバス型に接続されている。また、図１には、各ＥＣＵ等の情報も示されている。図１に示されるＯＢＤ－ＩＩは、自己診断機能である。
　以下では、情報処理装置（ＩＶＩやＴＣＵ等）と電子制御装置（ＥＣＵ）を総称して「ＥＣＵ」と呼称する。第２の実施の形態でも同様である。
　（診断通信について）
　本実施の形態では、構成情報推定システムは、自動車に搭載されているＥＣＵ等の機器において標準的にサポートされている診断通信によって得られる情報を収集・分析することで車両構成情報を推定することとしている。なお、診断通信はほとんどすべての自動車・ＥＣＵに実装されている。ここでは、その診断通信について説明する。
　診断通信は、ＥＣＵの故障診断やリプログラミングを行う際に利用される通信である。また、診断通信により、ＥＣＵの型番やソフトウェアのバージョン情報等も取得できる。診断通信の手順例を、図２を参照して説明する。図２は、外部診断機＿ＡとＥＣＵ＿Ｂとの間で診断通信を行う場合の例を示している。
　Ｓ１において、外部診断機＿ＡからＥＣＵ＿Ｂに対して診断要求を送信する。Ｓ２において、ＥＣＵ＿Ｂが診断要求に対応した処理を実行する。Ｓ３において、ＥＣＵ＿Ｂから外部診断機＿Ａに対して診断応答を送信する。診断応答には、処理の結果等が格納されている。
　（システム構成）
　図３に、本実施の形態における構成情報推定システムの構成例を示す。図３に示すように、本実施の形態における構成情報推定システムは、診断通信送受信部１００、診断系ログＤＢ２００、及び構成情報推定部３００を有する。構成情報推定部３００は、ＥＣＵ存在確認部３１０、トポロジ推定部３２０、ＥＣＵ情報抽出部３３０、出力部３４０を有する。各機能部の概要は下記のとおりである。
　診断通信送受信部１００は、後述するフロー図に従って診断通信の送受信を行い、受信した応答を診断系ログＤＢ２００に格納する。
　診断系ログＤＢ２００は、診断通信送受信部１００により取得したログを予め定めた形式で格納するＤＢ（データベース）である。
　構成情報推定部３００は、後述するフロー図に従って各内部ブロックが動作することで、診断系ログＤＢ２００に格納されている情報を利用して車両構成情報を推定する。なお、構成情報推定部３００の入力には診断系ログ以外の情報を用いてもよい。例えば、構成に関する公知の情報や非診断系のログを用いてもよい。
　なお、後述する実施例１～６で説明するように、診断通信送受信部１００、診断系ログＤＢ２００、及び構成情報推定部３００は種々の形態で１つ又は複数の装置に実装することが可能である。診断通信送受信部１００と構成情報推定部３００を備える装置をネットワーク構成推定装置と呼んでもよい。このネットワーク構成推定装置において、診断通信送受信部１００と構成情報推定部３００が遠隔の離れた場所にあり、互いにネットワークを介して通信する構成であってもよい。
　また、診断通信送受信部１００で得られた応答を利用して構成情報を推定する構成情報推定部３００を備える装置をネットワーク構成推定装置と呼んでもよい。
　（診断通信送受信部の動作）
　続いて、診断通信送受信部１００の動作例について説明する。まず、後述するフローに登場するＵＤＳ、ＤＩＤ、ＤｏＩＰについて説明する。
　ＵＤＳは、Unified Diagnostic Servicesの略称であり、診断通信における診断メッセージの形式等を定める標準仕様（ＩＳＯ１４２２９－１等）の名称である。
　ＤＩＤはＤａｔａ　ＩＤの略称である。ＵＤＳの診断要求（リクエストメッセージ）に設定されるＩＤであり、診断サービスの対象を示す。例えば、ＤＩＤとして、ソフトウェアのバージョン番号を指定するＤＩＤが設定された診断要求がＥＣＵに送信されると、ＥＣＵは、ソフトウェアのバージョン番号を設定した診断応答（レスポンスメッセージ）を返す。
　また、ＵＤＳをＮＷ－Ａ上に実装するためのネットワーク層の仕様を規定した標準仕様として、ＤｏＣＡＮ（Diagnostic communication over Controller Area Network）と呼ばれるＩＳＯ１５７６５－２がある。
　ＤｏＩＰは、Diagnostic communication over Internet Protocolの略称であり、ＵＤＳをＩＰ上に実装するためのネットワーク層の仕様を規定した標準仕様（ＩＳＯ　１３４００－１、ＩＳＯ　１３４００－２）の名称である。
　ＤｏＩＰにおいては、例えば図１に示したように、診断機能（テスター）に対するゲートウェイとなるＥＣＵと、特に高速なデータ転送が求められるＥＣＵのみがＮＷ＿Ｂでの通信を行い、他のＥＣＵはＮＷ＿Ａ等の車載ネットワークでゲートウェイＥＣＵと接続され、このゲートウェイＥＣＵ経由で診断を行う構成がとられる。
　本実施の形態における診断通信送受信部１００及びＥＣＵは、少なくとも上述した一般的な標準仕様に準拠した診断通信を行う。
　図４のフローチャートを参照して、診断通信送受信部１００の動作例について説明する。なお、図４を参照して説明する動作例において送受信するメッセージの内容や順序は一例であり、これに限定されるわけではない。
　Ｓ１０１において、診断通信送受信部１００は、ＤｏＩＰのVehicle Identification RequestをＮＷ＿Ｂ接続のＥＣＵにブロードキャストし、各ＥＣＵからの応答を受信する。Vehicle Identification Requestは、ＮＷ＿Ｂに接続されたＥＣＵに対して、アドレス情報を要求するメッセージである。
　Ｓ１０２において、診断通信送受信部１００は、ＵＤＳのtesterPresentをＮＷ＿Ａ接続の各ＥＣＵに送信し、応答を受信する。testerPresentは、ＮＷ＿Ａ接続のＥＣＵの存在とＮＷ＿Ａ－ＩＤ（すなわち、ＣＡＮ－ＩＤ）を確認するためのメッセージである。
　Ｓ１０３において、診断通信送受信部１００は、ＤｏＩＰのEntity Status Requestを車載ＮＷ＿Ｂ接続の各ＥＣＵに送信し、応答を受信する。Entity Status Requestは、ＥＣＵに対して、ノードタイプ（例：ゲートウェイ）等を要求するメッセージである。
　Ｓ１０４において、診断通信送受信部１００は、ＤＩＤとして１以上の値を設定したＵＤＳのReadDataByIdentifierを、車載ＮＷ＿Ｂ接続とＮＷ＿Ａ接続の各ＥＣＵに送信し、応答を受信する。ReadDataByIdentifierは、ＥＣＵに対してＤＩＤで指定したデータを要求するメッセージである。
　Ｓ１０４で使用されるＤＩＤは、例えば、0xF181、0xF183、0xF184、0xF188、0xF189、0xF18A、0xF194、0xF195、0xF19F、0xF18B、0xF18C、0xF184、0xF191、0xF192、0xF193、0xF19Fである。ただし、これらは例であり、これらに限定されるわけではない。
　0xF181は、applicationSoftwareIdentificationDataIdentifierを示す。0xF183は、bootSoftwareFingerprintDataIdentifierを示す。0xF184は、applicationSoftwareFingerprintDataIdentifierを示す。0xF188は、vehicleManufacturerECUSoftwareNumberDataIdentifierを示す。0xF189は、vehicleManufacturerECUSoftwareVersionNumberDataIdentifierを示す。0xF18Aは、systemSupplierIdentifierDataIdentifierを示す。0xF194は、systemSupplierECUSoftwareNumberDataIdentifierを示す。0xF195は、systemSupplierECUSoftwareVersionNumberDataIdentifierを示す。0xF19Fは、EntityDataIdentifierを示す。0xF18Bは、ECUManufacturingDateDataIdentifier を示す。0xF18Cは、ECUSerialNumberDataIdentifier を示す。0xF184は、applicationSoftwareFingerprintDataIdentifierを示す。0xF191は、vehicleManufacturerECUHardwareNumberDataIdentifierを示す。0xF192は、systemSupplierECUHardwareNumberDataIdentifierを示す。0xF193は、systemSupplierECUHardwareVersionNumberDataIdentifierを示す。0xF19Fは、EntityDataIdentifierを示す。
　（構成情報推定部の動作例）
　上記のＳ１０１～Ｓ１０４においてＥＣＵに送信された要求に対して受信した応答は、診断系ログＤＢ２００に格納される。構成情報推定部３００は、診断系ログＤＢ２００からデータを読み出すことで対象装置の内部ネットワークの構成情報の推定を行う。
　以下、図５のフローチャートを参照して、構成情報推定部３００による推定及び把握の動作の例を説明する。なお、ここで説明する推定・把握の順序や内容は一例であり、ここで説明するものに限定されるわけではない。
　＜Ｓ２０１＞
　Ｓ２０１において、ＥＣＵ存在確認部３１０は、ＥＣＵの存在確認を行う。具体的には下記のとおりである。
　ＥＣＵ存在確認部３１０は、ＮＷ＿Ｂ接続のＥＣＵにブロードキャストされたＤｏＩＰのVehicle Identification Requestに対しての応答から、ＮＷ＿Ｂ接続のＥＣＵの存在とそのＥＣＵのアドレス情報を確認する。つまり、Vehicle Identification Requestに対する応答として、アドレス情報を受信していれば、そのアドレス情報のＥＣＵがＮＷ＿Ｂ上に存在すると推定できる。
　また、ＥＣＵ存在確認部３１０は、ＮＷ＿Ａ接続の各ＥＣＵに送信したＵＤＳのtesterPresentに対しての応答から、ＮＷ＿Ａ接続のＥＣＵの存在とＮＷ＿Ａ－ＩＤを確認する。つまり、testerPresentに対する応答として、ＮＷ＿Ａ－ＩＤを受信していれば、そのＮＷ＿Ａ－ＩＤのＥＣＵがＮＷ＿Ａ上に存在すると推定できる。
　また、ＥＣＵ存在確認部３１０は、ＤｏＩＰのEntity Status Requestに対しての応答からＧａｔｅｗａｙ－ＥＣＵの存在とそのアドレス情報を確認する。つまり、Entity Status Requestに対しての応答として、ノードタイプがＧａｔｅｗａｙである応答を受信した場合、Ｇａｔｅｗａｙ－ＥＣＵが存在すると推定できる。
　＜Ｓ２０２＞
　Ｓ２０２において、トポロジ推定部３２０は、対象装置（ここでは自動車）の内部ネットワークのトポロジの推定を行う。具体的には下記のとおりである。
　トポロジ推定部３２０は、ＮＷ＿Ｂ接続のＥＣＵが１つのＳｗｉｔｃｈにスター型に接続される構成を有すると推定する。
　例えば、トポロジ推定部３２０は、Ｓ２０１での確認結果により、１つのＧａｔｅｗａｙ－ＥＣＵ（Ｓｗｉｔｃｈとしても機能する）が存在し、ＮＷ＿Ｂ上にＥＣＵが存在することが確認されたことに基づいて、内部ネットワークは、ＮＷ＿Ｂ接続のＥＣＵが１つのＳｗｉｔｃｈにスター型に接続される構成を有すると推定する。このような推定は、例えば、予め定めたルールに基づいて行うことができる。
　また、トポロジ推定部３２０は、Ｇａｔｅｗａｙ－ＥＣＵにはＮＷ＿Ａが接続していると推定する。例えば、トポロジ推定部３２０は、Ｓ２０１での確認結果により、Ｇａｔｅｗａｙ－ＥＣＵの存在が確認され、かつ、ＮＷ＿Ａ接続のＥＣＵの存在が確認されたことに基づいて、Ｇａｔｅｗａｙ－ＥＣＵにはＮＷ＿Ａが接続されていると推定する。このような推定は、例えば、予め定めたルールに基づいて行うことができる。
　また、トポロジ推定部３２０は、ＮＷ＿Ａ接続のＥＣＵがＧａｔｅｗａｙ－ＥＣＵ配下のＮＷ＿Ａにバス型に接続されていると推定する。例えば、トポロジ推定部３２０は、Ｇａｔｅｗａｙ－ＥＣＵにはＮＷ＿Ａが接続しているという推定結果と、ＮＷ＿ＡへのＥＣＵの接続方法の公知情報（例：バス型に接続されること）に基づいて、ＮＷ＿Ａ接続のＥＣＵがＧａｔｅｗａｙ－ＥＣＵ配下のＮＷ＿Ａにバス型に接続されていると推定する。このような推定は、例えば、予め定めたルールに基づいて行うことができる。
　＜Ｓ２０３＞
　Ｓ２０３において、ＥＣＵ情報抽出部３３０は、ＥＣＵ情報の抽出を行う。具体的には下記のとおりである。
　ＥＣＵ情報抽出部３３０は、ＤＩＤに0xF181、0xF183、0xF184、0xF188、0xF189、0xF18A、0xF194、0xF195、0xF19F、0xF18B、0xF18C、0xF184、0xF191、0xF192、0xF193、0xF19F（これらのＤＩＤは一例である）それぞれを設定したＵＤＳのReadDataByIdentifierに対しての応答から、各ＥＣＵにおけるＥＣＵ情報（ＶＩＮや型番、ソフトウェアバージョン等）を把握する。
　＜Ｓ２０４＞
　Ｓ２０４において、出力部３４０は、Ｓ２０１～Ｓ２０３により得られた情報を出力する。例えば、出力部３４０は、Ｓ２０１～Ｓ２０３により得られた情報から、図１に示すようなグラフィカルな画像を作成し、当該画像を出力（表示）する。また、出力部３４０は、Ｓ２０１～Ｓ２０３により得られた情報をリストや自然言語の形で出力してもよい。また、自然言語の音声を出力してもよい。
　図３に示す本実施の形態における構成情報推定システムは、種々の形態で実装可能である。以下、本実施の形態における実装方法の例として実施例１～実施例６を説明する。
　（実施例１）
　図６は、実施例１における構成情報推定システムの構成図である。図６に示すように、実施例１では、構成情報推定システムの全ての機能、すなわち、診断通信送受信部１００、診断系ログＤＢ２００、及び構成情報推定部３００を有する外部装置が、自動車４００に接続される。
　外部装置を自動車４００に接続する接続方法については、当該外部装置を自動車４００に物理的に接続する方法でもよいし、当該外部装置をクラウド等のネットワーク上で実現し、当該ネットワーク上の外部装置から遠隔で自動車４００に接続する方法でもよい。
　（実施例２）
　図７は、実施例２における構成情報推定システムの構成図である。実施例２では、診断通信送受信部１００を備える診断通信送受信装置と、診断系ログＤＢ２００と構成情報推定部３００とを備える構成情報推定装置との２つの装置が自動車４００に接続される。
　図７の例では、診断通信送受信装置が自動車４００に物理的に接続され、構成情報推定装置がクラウド上に配置され、ネットワークを介して診断通信送受信装置に接続される構成例を示している。なお、このような接続形態は一例であり、診断通信送受信装置と構成情報推定装置の配置場所は特定のものに限定されない。
　（実施例３）
　図８は、実施例３における構成情報推定システムの構成図である。実施例３は、実施例２の構成において、診断系ログＤＢ２００を診断通信送受信装置に備えた例である。
　なお、実施例２、３において、診断系ログＤＢ２００を診断通信送受信装置あるいは構成情報推定装置の内部ではなく、これらの装置の外部に配置してもよい。
　（実施例４）
　図９は、実施例４における構成情報推定システムの構成図である。実施例４では、診断通信送受信部１００から構成情報推定部３００までの全ての機能を実現する処理装置が車載ＮＷ上に配置される。すなわち、図９に示すように、自動車４００の内部に、診断通信送受信部１００、診断系ログＤＢ２００、及び構成情報推定部３００を有する処理装置が備えられる。
　なお、自動車４００に備えられる上記処理装置は、車載ＮＷ内に物理的に接続する形態で配置されてもよいし、任意のＥＣＵ上で実現されてもよい。つまり、１又は複数のＥＣＵが、診断通信送受信部１００、診断系ログＤＢ２００、及び構成情報推定部３００を有してもよい。
　（実施例５）
　図１０は、実施例５における構成情報推定システムの構成図である。実施例５では、車載ＮＷ上で処理を実施する処理装置を自動車４００内部に備え、外部装置が自動車４００に接続される。図１０に示すように、処理装置は診断通信送受信部１００を備え、外部装置は診断系ログＤＢ２００と構成情報推定部３００を備える。
　なお、処理装置について、当該装置を車載ＮＷ内に物理的に接続する形態で配置してもよいし、任意のＥＣＵ上で実現してもよい。また、外部装置の接続方法については、当該装置を自動車４００に物理的に接続する方法でもよいし、クラウド等のネットワーク上の装置として外部装置を備え、遠隔で自動車４００に接続する方法でもよい。
　（実施例６）
　図１１は、実施例６における構成情報推定システムの構成図である。実施例６は、実施例５の構成において、診断系ログＤＢ２００を処理装置に備えた例である。
　なお、実施例５、６において、診断系ログＤＢ２００を処理装置あるいは外部装置の内部ではなく、これらの装置の外部に配置してもよい。
――――――――――第２の実施の形態――――――――――
　続いて、第２の実施の形態について説明する。
　（車両構成情報の例）
　第２の実施の形態においても、構成情報推定システムが自動車の車両構成情報を推定する。図１２に車両構成情報の一例を示す。図１２における車載ネットワークのトポロジ、ＥＣＵ情報（２つの表）、正常通信（右側の表の太線で囲んだ枠）の３つが車両構成情報を構成する情報である。なお、これらの情報は、後述する要素技術１～３の範囲での情報である。
　第２の実施の形態においても、第１の実施の形態と同様に診断通信を利用する。診断通信については図２を参照して説明したとおりである。
　（自動車のネットワークについて）
　第２の実施の形態で前提としている自動車のネットワークを図１３に示す。図１３に示すように、本ネットワークでは、１つのＯＢＤ－ＩＩポートはＮＷ＿Ａバスと車載ＮＷ－Ｂの双方と接続する。１つのＯＢＤ－ＩＩポートから次の（１）、（２）の診断通信が可能である。
　（１）ＮＷ＿Ａのみを用いて（ＳＷを経由せず）、ＮＷ＿Ａ接続のＥＣＵと診断通信が可能である。また、ＯＢＤ－ＩＩからＧＷまで車載ＮＷ＿Ｂを利用し、ＧＷ以降でＮＷ＿Ａを利用してＮＷ＿Ａ接続のＥＣＵと診断通信を実施することも可能である。
　（２）車載ＮＷ＿Ｂ接続のＥＣＵに対しては、車載ＮＷ＿Ｂのみを用いて（ＳＷを経由して）診断通信を実施する。
　（要素技術について）
　ここで、第２の実施の形態における要素技術について説明する。第２の実施の形態における要素技術は下記の（１）～（３）である。なお、（４）、（５）には第１の実施の形態で説明した技術を要素技術４、要素技術５として示している。
　（１）ＮＷ＿Ａのトポロジを推定する技術（要素技術１）
　（２）ＮＷ＿Ａ接続のＥＣＵが送信する通常（非診断）ＮＷ＿Ａ－ＩＤ（０００～６ＦＦ）を特定する技術（要素技術２）
　（３）各ＥＣＵの機能（＝名称）を推定する技術（要素技術３）
　（４）各ＥＣＵのＥＣＵ情報を取得する技術（要素技術４）
　（５）ＮＷ＿Ｂのトポロジを推定する技術（要素技術５）
　以下、第２の実施の形態における要素技術１～３のそれぞれについて説明する
　（要素技術１）
　＜要素技術１に関する従来技術、課題＞
　要素技術１に関する従来技術は、既に説明した非特許文献１に開示された技術である。前述したように、非特許文献１に開示された技術では、ＳＮＭＰを用いて対象ＮＷ内の各ＳｗｉｔｃｈのＭＡＣアドレス転送テーブルを取得し、取得した情報を解析することで対象ＮＷのＬ２トポロジを推定する。
　しかし、非特許文献１のようなＳＮＭＰベースの手法でＮＷ＿Ａバスのトポロジを取得するためには、ＳＮＭＰエージェントの動作を可能とするためのリソース増強やＳＮＭＰのサポートが各ＥＣＵで必要となり、追加のコストがかかる。
　＜要素技術１のポイント、効果＞
　要素技術１においても、ほとんどの自動車において標準的に利用可能な診断通信の送受信を利用する。具体的には、特定のバスの占有率を強引増加（輻輳）させた際の、診断通信のＲＴＴを利用してＮＷ＿Ａバスのトポロジを推定する。本技術の詳細は後述する。
　診断通信プロトコルは各ＥＣＵにおいて標準的にサポートされているので、本技術により、リソースの増強や新たなプロトコルのサポートといった追加のコストをかけることなくＮＷ＿Ａバスのトポロジを推定できるようになる。
　＜要素技術１の目標、適用対象＞
　要素技術１では、同一のＮＷ＿Ａバスに繋がっているＥＣＵを特定することを目標としている。例えば、図１４に示す構成の場合、下記のような情報を推定する。
　・ＥＣＵ－ＡとＥＣＵ－Ｂは同一バス接続
　・ＥＣＵ－ＡとＥＣＵ－Ｃは異なるバス接続
　・ＥＣＵ－ＢとＥＣＵ－Ｃは異なるバス接続
　要素技術１の適用対象は、ドメインアーキテクチャを持つバスが存在するものであり、例えば図１５に示すように、ＧＷ配下に複数のバスが存在するものである。ＧＷは診断通信を適切なバスにルーティングする。例えば、ＥＣＵ－Ａに対応するＮＷ＿Ａ－ＩＤを持つ診断通信は、ＥＣＵ－Ａが接続しているバスにのみＧＷから送信される
　＜要素技術１の推定方法のポイントについて＞
　前述したとおり、要素技術１では、特定のバスの占有率を強引増加（輻輳）させた際の、診断通信のＲＴＴ（Round Trip Time）を利用することでＮＷ＿Ａのトポロジを推定する。
　診断通信のＲＴＴの定義を、図１６を参照して説明する。なお、図１６は、一例としてＰＣからＥＣＵ－Ａに対して診断通信を行う場合の例を示している。診断通信のＲＴＴは、診断要求（Ｓ１）をＰＣが１つのＥＣＵに送信し始めてから、そのＥＣＵからの診断応答（Ｓ２）をＰＣが受信し終わるまでの時間である。
　ここで、図１７に示すように、バス１のみ輻輳させるとする。バス１のみを輻輳させた場合、バス１に接続しているＥＣＵとの診断通信のＲＴＴは輻輳していない場合と比較して大きくなる。他方、バス２に接続しているＥＣＵとの診断通信のＲＴＴは輻輳していない場合と比較して変化しない。要素技術１では、このような事象を利用してトポロジを推定する。
　＜要素技術１の推定手順の概要＞
　要素技術１の推定手順の概要について、図１８～図２０を参照して説明する。まず、図１８に示すように、ＥＣＵ－ＢとＥＣＵ－Ｃに対して診断要求を数回送信し、ＥＣＵ－ＢとＥＣＵ－ＣそれぞれのＲＴＴの平均値を調べる。図１８（及び図１９，図２０）の左下にＥＣＵ－ＢとＥＣＵ－ＣそれぞれのＲＴＴの平均値のイメージを示している。
　次に、図１９に示すように、ＥＣＵ－Ａに対して診断要求を高頻度で送信することでＥＣＵ－ＡとＥＣＵ－Ｂが接続しているバスの占有率を上げる。図１９の例では、当該バスの占有率が９９％であることが示されている。
　続いて、図２０に示すように、ＥＣＵ－Ａが接続しているバスが輻輳している状況下で、ＥＣＵ－ＢとＥＣＵ－Ｃに対して診断要求を数回送信し、ＥＣＵ－ＢとＥＣＵ－ＣのＲＴＴの平均値を調べる。
　図２０の左下に示すように、ＲＴＴの統計値の平均値が非輻輳時と比較して増加（左下図）していれば、そのＥＣＵはＥＣＵ－Ａと同一バスに接続していると判定する。図２０の例では、「ＥＣＵ－ＡとＢが同一バスに接続」と判定される。
　（要素技術２）
　次に、要素技術２について説明する。
　＜要素技術２に関する従来技術、課題＞
　要素技術２に関する従来技術として、「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).」がある。
　本従来技術では、ＥＣＵが送信したメッセージの衝突が一定回数異常発生すると、そのＥＣＵのメッセージ送信が停止（バスオフ）するというＮＷ＿Ａの特性を利用し、一つのＥＣＵが送信しているＮＷ＿Ａメッセージの全ＮＷ＿Ａ－ＩＤを特定する。
　従来技術による手法の具体例は下記のとおりである。
　ＮＷ＿Ａバス上のあるＥＣＵ－ＡがＮＷ＿Ａ－ＩＤ＝０ｘ３００のＮＷ＿Ａメッセージを送信するタイミングに合わせて、ＮＷ＿Ａバスに接続した推定機器からＮＷ＿Ａ－ＩＤ＝０ｘ３００のＮＷ＿Ａメッセージを送信する。
　これによりＮＷ＿Ａ－ＩＤ＝０ｘ３００のＮＷ＿Ａメッセージの衝突を発生させる。この衝突を繰り返すことで、ＥＣＵ－Ａがバスオフする。
　ＥＣＵ－Ａがバスオフすると、ＮＷ＿Ａ－ＩＤ＝０ｘ３００を含め、ＥＣＵ－Ａが送信している全てのＮＷ＿Ａ－ＩＤのＮＷ＿Ａメッセージ（例えば他に０ｘ３０１，０ｘ３０２）も停止する。
　このとき送信されなくなったＮＷ＿ＡメッセージのＮＷ＿Ａ－ＩＤを推定機器で調べることで、ＥＣＵ－Ａが送信しているＮＷ＿ＡメッセージのＮＷ＿Ａ－ＩＤを特定する。今回の例で言えば「ＥＣＵ－ＡはＮＷ＿Ａ－ＩＤ＝０ｘ３００，０ｘ３０１，０ｘ３０２のＮＷ＿Ａメッセージを送信している」ことを特定する。
　しかし、上記の従来技術には下記のような課題がある。
　車載ＮＷ＿Ａバスへのアクセス用に搭載されているＯＢＤ－ＩＩポートは、近年のほとんどの自動車において診断通信しか送受信できない設定となっている。一方で、上記の従来技術においてＮＷ＿Ａメッセージの衝突を発生させるためには非診断通信を車載ＮＷ＿Ａバスに送信できる必要がある。よって、ＯＢＤ－ＩＩポートを利用するという一般的な形態で従来技術を実施することは困難である。
　＜要素技術２のポイント、効果＞
　要素技術２では、診断通信を利用して対象ＥＣＵのＮＷ＿Ａメッセージの送信周期を狂わせ、そのＮＷ＿Ａメッセージの送信周期の狂いをＮＷ＿Ａ－ＩＤＳで検知する。そして、その検知結果と対象ＥＣＵの情報を関連付けることで、そのＥＣＵが送信しているＮＷ＿ＡメッセージのＮＷ＿Ａ－ＩＤを特定する。
　本技術により、近年のほとんどの自動車を対象に、ＯＢＤ－ＩＩポートを利用する形で「ＥＣＵが送信しているＮＷ＿ＡメッセージのＮＷ＿Ａ－ＩＤ」を特定することができる
　＜要素技術２の目標、適用対象＞
　要素技術２では、例えば図２１に示すように、ＮＷ＿Ａ接続のＥＣＵが送信する通常ＮＷ＿Ａ－ＩＤ（０００～６ＦＦ）を診断用ＮＷ＿Ａ－ＩＤ（７００～７ＦＦ）と関連付け、延いてはＥＣＵ情報と関連付けることを目標としている。
　要素技術２では、対象ＮＷ上にＩＤＳが存在し、通常メッセージを監視していることを前提としている。当該ＩＤＳは、通常メッセージの送信時刻の間隔が設計値よりも短い／長い場合やペイロードに異常変化があった場合にアラートを発報する。ＩＤＳのアラートには、異常と検知されたメッセージの情報（自動車の例ではＮＷ＿Ａ－ＩＤ）が含まれている。また、車両構成推定装置は、ＩＤＳのアラートを何らかの方法で取得できる。
　＜要素技術２の推定方法のポイントと手順について＞
　図２２を参照して、要素技術３のポイントとなる処理手順を説明する。
　（１）ＥＣＵＲｅｓｅｔ（例えばＮＷ＿Ａ－ＩＤ＝７Ｅ０で）を利用して対象ＥＣＵが送信する通常ＮＷ＿Ａ－ＩＤ（例えばＮＷ＿Ａ－ＩＤ＝３００）のメッセージ送信の周期性やペイロード変化を狂わせる。
　（２）ＮＷ＿Ａ－ＩＤＳにアラートを発報させる。例えばアラートには、ＮＷ＿Ａ－ＩＤ＝３００が含まれている。
　（３）そして「そのアラートに含まれるＮＷ＿Ａ－ＩＤは対象ＥＣＵが送信する通常ＮＷ＿Ａ－ＩＤである」と判定する。
　（要素技術３）
　次に、要素技術３について説明する。
　＜要素技術３に関する従来技術、課題＞
　要素技術３に関する従来技術として、「X.Feng, et al : Acquisitional Rule-based Engine for Discovering Internet-of-Things Dvices. USENIX (2018)」がある。本従来技術では、ＩｏＴ機器から収集した応答情報とＷｅｂクローリング・スクレイピング技術を活用してＩｏＴ機器の情報（機器種別・ベンダ・型番）を特定する。
　より具体的には、本従来技術では、あるＩｏＴ機器の応答から抽出したキーワードＡに対して、複数のＷｅｂクローリング・スクレイピング結果Ｂが得られる。自動車の例では、あるＥＣＵから「１２３４５－６７８９０」というＥＣＵ型番を取得できたとする。このとき、Ａ＝１２３４５－６７８９０である。そして、Ａを用いたクローリング・スクレイピング結果が図２３に示す通りであったとする。
　本従来技術では、その複数ある結果Ｂを対象に下記の確信度ｃｏｎｆ（Ａ⇒Ｂ）を算出する。
　ｃｏｎｆ（Ａ⇒Ｂ）＝（ＡとＢの双方が含まれる結果の数）／（Ａが含まれる結果の数）
　そして確信度の最も高い結果を１つの結果として抽出する。図２３の例では、Ａ＝１２３４５－６７８９０、Ｂ＝Ｅｎｇｉｎｅ　Ｍｏｄｕｌｅがｃｏｎｆ（Ａ⇒Ｂ）＝０．６７で抽出される。
　上記の従来技術には下記のような課題がある。
　ＥＣＵ型番全体をキーワードとしてクローリング・スクレイピングをすると、検索結果が不在によりＥＣＵの機能を推定できないことが多い。
　また、上記従来技術のように、最も確信度の高い結果を抽出する場合、情報量の少ない結果が選ばれる場合がある。例えば、図２３の場合は「Ｈｙｂｒｉｄ　Ｅｎｇｉｎｅ　Ｍｏｄｕｌｅ」の方が、情報量が多いため、この結果が抽出されてほしい。しかし、従来技術の場合は、図２３のようなスクレイピング結果（表）が得られた場合には、出現回数の多い「Ｅｎｇｉｎｅ　Ｍｏｄｕｌｅ」が選ばれてしまう。
　＜要素技術３のポイント、効果＞
　要素技術３のポイントとして、下記のポイント１、ポイント２がある。
　ポイント１は、ＥＣＵ型番の命名規則に基づいて、機能を示す桁のみを用いたスクレイピング結果も利用することである。ポイント２は、各Ｗｅｂクローリング・スクレイピング結果に含まれる単語の支持度の和が最大となる結果を抽出することである。
　本技術により、検索結果不在によるＥＣＵの機能（名称）推定不可を回避できる。また、信頼度が高く、かつ、情報量の多い結果を出力できる。
　＜要素技術３の目標、適用対象＞
　要素技術３では、各ＥＣＵ（ＮＷ＿Ｂ接続含む）の機能（名称）を推定することを目標としている。例えば、図２４に示す例において、「ＥＣＵ－ＸはＩＶＩである」、「ＥＣＵ－ＹはＴＣＵである」、「ＥＣＵ－ＡはエンジンＥＣＵである」等を推定する。また、要素技術３では、機器を一意に特定する情報を取得可能であり、自動車の例でいえば「ＥＣＵ型番」を取得可能である。
　＜要素技術３の推定方法のポイントと手順について＞
　まず、要素技術３の推定方法の全体像について説明する。要素技術３では、診断通信で取得した各ＥＣＵ型番とＷｅｂクローリング・スクレイピング技術を活用して機能（名称）を特定する。図２５にそのイメージを示す。以下、前述したポイント１とポイント２をより詳細に説明する。
　　＜ポイント１＞
　ポイント１では、ＥＣＵ型番の命名規則に基づいて、ＥＣＵ型番の機能に関する桁のみを用いたＷｅｂクローリング・スクレイピング結果も利用する。
　ＥＣＵ型番の多くは、機能情報を示す桁と車種年式を示す桁が結合された構成をとる。
機能情報を示す桁を○、車種年式を示す桁を△としたとき、例えば下記のようなＥＣＵ型番構成がある
　・○○○○○－△△△△△
　・△△△－○○○○○○－△
　ポイント１のように機能に関する桁のみを用いることで検索結果不在が減る理由は下記のとおりである。
　「ＥＣＵ型番の全桁が一致」という条件で検索を行うことは、「指定された車種年式の車に搭載」かつ「指定された機能」のＥＣＵを検索することである。一方、「ＥＣＵ型番の機能を示す桁のみが一致」という条件で検索を行うことは、「指定された機能」のＥＣＵを検索することである。つまり、検索時の限定条件を減らすことができるため検索結果不在を減らすことができる。
　機能に関する桁の抽出方法は特定の抽出方法に限定されないが、例えば下記の抽出方法１～３のいずれかを用いることができる。
　抽出方法１）
　抽出方法１では、公開されている「ＥＣＵ型番の命名規則の情報」に基づいて機能に関する桁を決定する。例えば、自動車会社のホームページ等において命名規則が公開されている場合は、その公開情報に基づいて機能に関する桁を決定する。
　抽出方法２）
　抽出方法２では、とある一つの機能に関連するＥＣＵ型番のみを抽出・分析し、その分析結果に基づいて機能に関する桁を決定する。例えば、エンジンＥＣＵに関連するＥＣＵ型番のみを抽出・分析すると、どのＥＣＵ型番においても値が変化しない桁がある。その桁を機能に関する桁として決定する。
　抽出方法３）
　抽出方法３では、とある一台の自動車に搭載されているＥＣＵのＥＣＵ型番を抽出・分析し、その分析結果に基づいて機能に関する桁を決定する。例えば、一台の自動車に搭載されているＥＣＵのＥＣＵ型番を抽出・分析すると、どのＥＣＵ型番においても値が変化しない桁がある。その桁は機能ではなく車種を示す桁であると考えられるため、その桁を除外した桁を機能に関する桁として決定する。
　＜ポイント２＞
　要素技術３のポイント２では、各Ｗｅｂクローリング・スクレイピング結果に含まれる単語の支持度の和が最大となる結果を抽出する。具体的には下記のとおりである。
　ＥＣＵ型番が「１２３４５－６７８９０」であるＥＣＵの機能（名称）を推定する際に、図２６に示すＷｅｂクローリング・スクレイピング結果が得られたとする。図２６に含まれる単語Ｘについて下記の支持度ｓｕｐ（Ｘ）を算出する。
　ｓｕｐ（Ｘ）＝（Ｘが含まれる結果の数）／（全てのＷｅｂクローリング・スクレイピング結果の数）
　そして、各行に含まれる単語の支持度の和を各行で算出し、その和が最大の結果を１つの結果として抽出する。図２６の例では、Ｈｙｂｒｉｄ　Ｅｎｇｉｎｅ　Ｍｏｄｕｌｅが抽出される。ここで、ｓｕｐ（Ｅｎｇｉｎｅ）＝１、ｓｕｐ（Ｍｏｄｕｌｅ）＝１、ｓｕｐ（Ｈｙｂｒｉｄ）＝０．３、和＝２．３である。
　（実施例）
　以下、第２の実施の形態における具体的な装置構成、及び動作を実施例として説明する。各実施例の概要は下記のとおりである。
　Ａ．要素技術の組み合わせの観点での実施例の列挙
　・実施例Ａ１：最も基本的な要素技術の組み合わせでの実施例（処理フローの詳細を説明）
　・実施例Ａ２～Ａ４：各要素技術を単体で利用する実施例
　・実施例Ａ５～Ａ７：要素技術を部分的に組み合わせる実施例
　Ｂ．物理的な機能配備の観点での実施例の列挙
　・実施例Ｂ１：本発明に係る機能を車載ＮＷ上に配備する実施例
　・実施例Ｂ２：本発明に係る機能をＯＢＤ－ＩＩポートに直接接続する実施例
　・実施例Ｂ３：本発明に係る機能を充電ポートから実施する例
　なおＢ１～Ｂ３は、後述する車載ＮＷ１とメッセージ送受信部２３以外を切り出してクラウド上に配備しても良い。
　・実施例Ｂ４：外部ネットワーク上に配備した本発明に係る機能により推定を実施する例
　Ｃ．目的の観点での実施例の列挙
　・実施例Ｃ１：ＳＯＣ（Security Operation Center）等でのセキュリティ分析に活用する実施例
　・実施例Ｃ２：アセット管理に活用する実施例
　・実施例Ｃ３：異常検知を実施する実施例
　・実施例Ｃ４：セキュリティ診断に活用する実施例
　なお、実際に実施する際は上記ＡとＢの実施例を組み合わせる。例えば、実施例Ａ１を実施例Ｂ１の機能配備で実施する等である。そしてそれをＣに記載の目的のために使用する。以下、各実施例を説明する。
　（実施例Ａ１）
　実施例Ａ１は、コア技術の最も基本的な組み合わせでの実施例である。ここでは、一例として、実施例Ｂ２の物理配備を想定して説明する。
　＜装置構成（ブロック図）＞
　図２７に、実施例Ａ１における構成情報推定システムの構成図を示す。図２７に示すように、構成情報推定システムは、構成要素推定部２と構成情報推定結果ＤＢ２２を備える。構成要素推定部２を、車両構成推定装置あるいはネットワーク構成推定装置と呼んでもよい。構成情報推定システムを構成情報推定装置と呼んでもよい。構成要素推定部２は、車載ＮＷ１とＷｅｂサイト７（Ｗｅｂサーバ）に接続され、これらと通信可能である。
　構成要素推定部２は、ＥＣＵ基本情報取得部３、ＥＣＵ機能推定部４、ＮＷ＿Ｂトポロジ推定部１２、ＮＷ＿Ａバストポロジ推定部１３、正常ＮＷ＿Ａ通信推定部１８、メッセージ送受信部２３，構成情報取得・登録部２４を備える。
　ＥＣＵ機能推定部４は、Ｗｅｂ検索部６、検索結果ＤＢ８、完全一致抽出部９、特定部分一致抽出部１０、推定部１１を備える。なお、「完全一致抽出部９、特定部分一致抽出部１０、推定部１１」をまとめて推定部と呼んでもよい。
　ＮＷ＿Ａバストポロジ推定部１３は、ベースＲＴＴ算出部１４，輻輳ＲＴＴ算出部１５、ＲＴＴ比較部１６、推定部１７を備える。なお、「ＲＴＴ比較部１６、推定部１７」をまとめて推定部と呼んでもよい。
　正常ＮＷ＿Ａ通信推定部１８は、再起動命令送信部１９、車両アラート受信部２０、及び推定部２１を備える。
　以下、フローチャートを参照して装置動作を説明する。以下の説明において、なお、車載ＮＷ１や車載ＥＣＵへのメッセージ送受信は、メッセージ送受信部２３を経由して実施する。
　＜全体の処理の流れ＞
　図２８を参照して、構成情報推定システムの全体の処理の流れを説明する。なお、図２８に示す処理の順番は一例である。
　Ｓ１０３０において、ＥＣＵ基本情報取得部３がＥＣＵ基本情報を取得する。Ｓ１０４０において、ＥＣＵ機能推定部４がＥＣＵ機能を推定する。Ｓ１１２０において、ＮＷ＿Ｂトポロジ推定部１２が、ＮＷ＿Ｂのトポロジを推定する。Ｓ１１３０において、ＮＷ＿Ａバストポロジ推定部１３が、ＮＷ＿Ａバストポロジを推定する。Ｓ１１８０において、正常ＮＷ＿Ａ通信推定部１８が、正常ＮＷ＿Ａ通信の推定を行う。
　以下、個々のステップの処理内容を詳細に説明する。
　＜Ｓ１０３０＞
　Ｓ１０３０について、図２９を参照して説明する。
　Ｓ１０３０－１において、車両構成推定装置を車載ＮＷ１のＯＢＤ－ＩＩポート（ＮＷ＿Ｂ）に接続する
　Ｓ１０３０－２において、ＥＣＵ基本情報取得部３は、Ｓ１０３１を実行する。Ｓ１０３０－３において、ＥＣＵ基本情報取得部３は、Ｓ１０３２を実行する。Ｓ１０３２において、Ｓ１０３３とＳ１０３４も実行する。
　Ｓ１０３０－４において、ＥＣＵ基本情報取得部３は、Ｓ１０３５を実行する。Ｓ１０３０－５において、ＥＣＵ基本情報取得部３は、車両構成推定装置をＯＢＤ－ＩＩポート（ＮＷ＿Ｂ）から切断し、ＯＢＤ－ＩＩポート（ＮＷ＿Ａ）に接続する。
　Ｓ１０３０－６において、ＥＣＵ基本情報取得部３は、Ｓ１０３６を実行する。Ｓ１０３０－７において、ＥＣＵ基本情報取得部３は、Ｓ１０３７を実行する。Ｓ１０３７において、Ｓ１０３８も実行する。Ｓ１０３０－８において、ＥＣＵ基本情報取得部３は、Ｓ１０３９を実行する。
　＜Ｓ１０３１＞
　次に、Ｓ１０３１の処理を、図３０を参照して説明する。
　Ｓ１０３１－１において、ＥＣＵ基本情報取得部３は、ＤｏＩＰの規定に従い、ＡｕｔｏＩＰもしくはＤＨＣＰにより車載ＮＷ１上のローカルＩＰアドレスを取得する。
　Ｓ１０３１―２において、ＥＣＵ基本情報取得部３が、ＤｏＩＰの規定に従って車載ＮＷ１上の各ＥＣＵがブロードキャストするＶｅｈｉｃｌｅ　Ａｎｎｏｕｎｃｅｍｅｎｔを受信した場合はＳ１０３１－５に進み、受信しない場合はＳ１０３１－３に進む。
　Ｓ１０３１－３において、ＥＣＵ基本情報取得部３は、車載ＮＷ１上にＶｅｈｉｃｌｅ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ　Ｒｅｑｕｅｓｔ（ＤｏＩＰで規定）をブロードキャストする。
　Ｓ１０３１－４において、車載ＮＷ１上の各ＥＣＵはＤｏＩＰの既定に従い、Ｖｅｈｉｃｌｅ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ　Ｒｅｑｕｅｓｔに対してＶｅｈｉｃｌｅ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ　Ｒｅｓｐｏｎｓｅを応答する。ＥＣＵ基本情報取得部３は、そのＶｅｈｉｃｌｅ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ　Ｒｅｓｐｏｎｓｅを受信する。
　Ｓ１０３１－５において、ＥＣＵ基本情報取得部３は、受信したＶｅｈｉｃｌｅ　ＡｎｎｏｕｎｃｅｍｅｎｔやＶｅｈｉｃｌｅ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ　Ｒｅｓｐｏｎｓｅに含まれる送信元ＩＰアドレスなどの情報をメモリ等の記憶手段に記録する。記録した情報を図３１（表３０３１）に示す。なお、記録する情報は表３０３１のものに限らない。
　＜Ｓ１０３２＞
　次に、図３２を参照してＳ１０３２の処理について説明する。Ｓ１０３２－１において、ＥＣＵ基本情報取得部３は、下記の変数を宣言する。
　・前のステップ（Ｓ１０３１）で記憶した表３０３１のＩＰアドレスのリスト"ＩＰ＝［１９２．１６８．１０．１，１９２．１６８．１０．２，１９２．１６８．１０．３］"
　・ＩＰリストの長さ"Ｌｅｎｇｔｈ（ＩＰ）"（本例の場合、Ｌｅｎｇｔｈ（ＩＰ）＝３）
　・"ＤＩＤ＝［０ｘＦ１８Ｃ，０ｘＦ１９０，０ｘＦ１９１，０ｘＦ１９４，０ｘＦ１９５，０ｘＦ１９Ｆ］"
　・ＤＩＤの長さ"Ｌｅｎｇｔｈ（ＤＩＤ）"（本例の場合Ｌｅｎｇｔｈ（ＤＩＤ）＝６）
　・ｉ＝０
　なお、変数名は上記以外でも良い。また、ＩＰの中身をＩＰアドレス以外の値で統一しても良い。ＤＩＤには上記以外の値を追加しても良い
　Ｓ１０３２―２において、ＥＣＵ基本情報取得部３は、ｉ＜Ｌｅｎｇｔｈ（ＩＰ）であるか否かを判断し、ＹｅｓであればＳ１０３２－３に進み、Ｎｏであれば処理を終了する。
　Ｓ１０３２－３において、ＥＣＵ基本情報取得部３は、Ｓ１０３３の処理を実行する。Ｓ１０３２－４において、ＥＣＵ基本情報取得部３は、Ｓ１０３４の処理を実行する。Ｓ１０３２―５において、ｉ＝ｉ＋１とし、Ｓ１０３２－２に戻る。
　＜Ｓ１０３３＞
　次に、図３３を参照してＳ１０３３の処理について説明する。Ｓ１０３３－１において、ＥＣＵ基本情報取得部３は、車載ＮＷ１上のＩＰ［ｉ］に対してＤｏＩＰ　Ｅｎｔｉｔｙ　Ｓｔａｔｕｓ　Ｒｅｑｕｅｓｔを送信する。
　Ｓ１０３３－２において、車載ＮＷ１上のＩＰ［ｉ］を持つＥＣＵはＤｏＩＰの既定に従い、ＤｏＩＰ　Ｅｎｔｉｔｙ　Ｓｔａｔｕｓ　Ｒｅｑｕｅｓｔに対してＤｏＩＰ　Ｅｎｔｉｔｙ　Ｓｔａｔｕｓ　Ｒｅｓｐｏｎｓｅを応答する。ＥＣＵ基本情報取得部３は、そのＤｏＩＰ　Ｅｎｔｉｔｙ　Ｓｔａｔｕｓ　Ｒｅｓｐｏｎｓｅを受信する。
　Ｓ１０３３－３において、ＥＣＵ基本情報取得部３は、受信したＤｏＩＰ　Ｅｎｔｉｔｙ　Ｓｔａｔｕｓ　Ｒｅｓｐｏｎｓｅに含まれる「Ｎｏｄｅ　ｔｙｐｅ」とＩＰ［ｉ］を記憶手段に記録する。記録した情報の例を図３４（表３０３２）に示す。
　＜Ｓ１０３４＞
　次に、図３５を参照してＳ１０３４の処理について説明する。Ｓ１０３４－１において、ＥＣＵ基本情報取得部３は、変数ｊ＝０を宣言する。なお、変数名はｊ以外でも良い。Ｓ１０３４－２において、ＥＣＵ基本情報取得部３は、ｊ＜Ｌｅｎｇｔｈ（ＤＩＤ）を満たすか否かを判断し、ＹｅｓであればＳ１０３４－３に進み、Ｎｏであれば処理を終了する。
　Ｓ１０３４－３において、ＥＣＵ基本情報取得部３は、ＤＩＤにＤＩＤ［ｊ］を設定したｒｅａｄＤａｔａＢｙＩｄｅｎｔｉｆｉｅｒ（ＵＤＳで規定）をＩＰ［ｉ］に送信し、応答を受信する。Ｓ１０３４－４において、ＥＣＵ基本情報取得部３は、受信した応答のｄａｔａＲｅｃｏｒｄをＩＰ［ｉ］とＤＩＤ［ｊ］とともに記憶手段に記録する。記録した情報の例を図３６（表３０３３）に示す。Ｓ１０３４－５において、ＥＣＵ基本情報取得部３は、ｊ＝ｊ＋１とし、Ｓ１０３４－２に戻る。
　＜Ｓ１０３５＞
　次に、図３７を参照してＳ１０３５を説明する。Ｓ１０３５－１において、ＥＣＵ基本情報取得部３は、図３６（表３０３３）のＤＩＤをＵＤＳの規定に基づいて「説明」に変更し、ｄａｔａＲｅｃｏｒｄをＡＳＣＩＩ（１６進数）→文字列変換する。図３６（表３０３３）を変更・変換後の結果は図３８（表３０３４）の通りである。なお、説明の内容やｄａｔａＲｅｃｏｒｄの変換方法はこれに限らない。
　Ｓ１０３５－２において、ＥＣＵ基本情報取得部３は、図３８（表３０３４）のデータを「ＩＰアドレス」と「ＥＣＵ型番」を複合主キーとして整理する。整理した結果は図３９（表３０３５）に示す通りである。なお、まとめ方はこれに限らない。
　Ｓ１０３５－３において、ＥＣＵ基本情報取得部３は、図３９（表３０３５）と図３１（表３０３１）と図３４（表３０３２）を「ＩＰアドレス」をキーとして結合する。その結果は図４０（表３０３６）に示す通りである。
　Ｓ１０３５－４において、ＥＣＵ基本情報取得部３は、図４０（表３０３６）の結合結果を、構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２に格納する。
　＜Ｓ１０３６＞
　次に、Ｓ１０３６を、図４１を参照して説明する。Ｓ１０３６－１において、ＥＣＵ基本情報取得部３は、ＤｏＣＡＮとＵＤＳの規定に従い、診断用ＮＷ＿Ａ－ＩＤ＝０ｘ７００～０ｘ７ＦＦや診断用の拡張ＮＷ＿Ａ－ＩＤ（以降、これらを単に「ＮＷ＿Ａ－ＩＤ」と総称）のすべてに対して順々にＴｅｓｔｅｒＰｒｅｓｅｎｔ要求を送信する。
　Ｓ１０３６－２において、ＥＣＵ基本情報取得部３は、前のステップでＴｅｓｔｅｒＰｒｅｓｅｎｔ要求を送信した際に対しての応答が車載ネットワーク上で発生すれば、自身が送信したＮＷ＿Ａ－ＩＤ（要求ＮＷ＿Ａ－ＩＤ）などを記憶手段に記録する。例えば、ＮＷ＿Ａ－ＩＤ　＝　７００を設定したＴｅｓｔｅｒＰｒｅｓｅｎｔを送信した際に応答があれば、ＮＷ＿Ａ－ＩＤ＝７００や応答に設定されているＮＷ＿Ａ－ＩＤ（応答ＮＷ＿Ａ－ＩＤ）を記録する。その結果は図４２（表３０３７）に示す通りである。
　＜Ｓ１０３７＞
　次に、Ｓ１０３７を、図４３を参照して説明する。Ｓ１０３７－１において、ＥＣＵ基本情報取得部３は、下記の変数を宣言する。
　・前のステップで記録した図４２（表３０３７）の要求ＮＷ＿Ａ－ＩＤリスト"ＮＷ＿Ａ－ＩＤ＝［０ｘ７００，０ｘ７２４，０ｘ７５０，０ｘ７Ｅ０，０ｘ７Ｅ１］"
　・リストの長さ"Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）"（本例の場合はＬｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）＝５）
　・"ＤＩＤ　＝［０ｘＦ１８Ｃ，０ｘＦ１９０，０ｘＦ１９１，０ｘＦ１９４，０ｘＦ１９５，　０ｘＦ１９Ｆ］"
　・ＤＩＤの長さ"Ｌｅｎｇｔｈ（ＤＩＤ）"（本例の場合はＬｅｎｇｔｈ（ＤＩＤ）＝６）
　・ｉ＝０
　なお、変数名は上記以外でも良い。また、ＮＷ＿Ａ－ＩＤの中身をＮＷ＿Ａ－ＩＤ以外の値で統一しても良い。ＤＩＤには上記以外の値を追加しても良い
　Ｓ１０３７－２において、ｉ＜Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）を満たすかどうかを確認し、ＹｅｓであればＳ１０３７－３に進み、Ｎｏであれば処理を終了する。Ｓ１０３７―３において、ＥＣＵ基本情報取得部３は、Ｓ１０３８を実行する。Ｓ１０３７－４において、ｉ＝ｉ＋１としてＳ１０３７－２に戻る。
　＜Ｓ１０３８＞
　次に、図４４を参照してＳ１０３８について説明する。Ｓ１０３８－１において、ＥＣＵ基本情報取得部３は、変数ｊ＝０を宣言する。なお、変数名はｊ以外でも良い。
　Ｓ１０３８－２において、ＥＣＵ基本情報取得部３は、ｊ＜Ｌｅｎｇｔｈ（ＤＩＤ）を満たすかどうか判断する。ＹｅｓであればＳ１０３８－３に進み、Ｎｏであれば処理を終了する。
　Ｓ１０３８―３において、ＥＣＵ基本情報取得部３は、ＤＩＤにＤＩＤ［ｊ］を設定したｒｅａｄＤａｔａＢｙＩｄｅｎｔｉｆｉｅｒ（ＵＤＳで規定）をＮＷ＿Ａ－ＩＤ［ｉ］に送信し、応答を受信する。
　Ｓ１０３８―４において、ＥＣＵ基本情報取得部３は、受信した応答のｄａｔａＲｅｃｏｒｄをＮＷ＿Ａ－ＩＤ［ｉ］（要求ＮＷ＿Ａ－ＩＤ）と応答ＮＷ＿Ａ－ＩＤ、ＤＩＤ［ｊ］とともに記憶手段に記録する。記録した情報の例を図４５（表３０３８）に示す。Ｓ１０３８－５において、ｊ＝ｊ＋１としてＳ１０３８－２に戻る。
　＜Ｓ１０３９＞
　次に、図４６を参照してＳ１０３９について説明する。Ｓ１０３９－１において、ＥＣＵ基本情報取得部３は、図４５（表３０３８）のＤＩＤをＵＤＳの規定に基づいて「説明」に変更し、ｄａｔａＲｅｃｏｒｄをＡＳＣＩＩ（１６進数）→文字列変換する。なお、説明の内容やｄａｔａＲｅｃｏｒｄの変換方法はこれに限らない。
　Ｓ１０３９－２において、ＥＣＵ基本情報取得部３は、前ステップのデータを「ＮＷ＿Ａ－ＩＤ」と「ＥＣＵ型番」を複合主キーとして整理する。整理した結果は図４７（表３０３９）に示す通りである。なお、まとめ方はこれに限らない。
　Ｓ１０３９－３において、ＥＣＵ基本情報取得部３は、図４７（表３０３９）の整理結果を構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２に渡す。
　＜Ｓ１０４０＞
　次に、図４８を参照してＳ１０４０について説明する。Ｓ１０４０－１において、ＥＣＵ機能推定部４は、下記の変数を宣言する。
　・構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２から取得した、図４０（表３０３６）と図４７（表３０３９）の重複のないＥＣＵ型番のリスト
　・"ＰＮ＝［１１１１１－５６７８９，２２２２２－５６７８９，３３３３３－５６７８９，４４４４４－５６７８９，５５５５５－５６７８９，６６６６６－５６７８９，７７７７７－５６７８９，８８８８８－５６７８９］"
　・ＰＮリストの長さ"Ｌｅｎｇｔｈ（ＰＮ）"（本例の場合はＬｅｎｇｔｈ（ＰＮ）＝８）
　・ｉ＝０
　なお、変数名は上記以外でも良い。また、ＩＰの中身をＩＰアドレス以外の値で統一しても良い。
　Ｓ１０４０－２において、ＥＣＵ機能推定部４は、ｉ＜Ｌｅｎｇｔｈ（ＰＮ）を満たすかどうかを判断し、ＹｅｓであればＳ１０４０－３に進み、Ｎｏであれば処理を終了する。Ｓ１０４０－３において、ＰＮ［ｉ］についてＳ１０６１を実施し、Ｓ１０４０－４において、ＰＮ［ｉ］についてＳ１０９１を実施し、Ｓ１０４０－５において、ＰＮ［ｉ］についてＳ１１０１を実施し、Ｓ１０４０－６において、ＰＮ［ｉ］についてＳ１１１１を実施する。Ｓ１０４０－７においてｉ＝ｉ＋１としてＳ１０４０－２に戻る。
　＜Ｓ１０６１＞
　次に、図４９を参照してＳ１０６１について説明する。Ｓ１０６１－１において、Ｗｅｂ検索部６は、構成情報推定結果ＤＢ２２から取得したＥＣＵ型番を検索ワードとして利用しＷｅｂページをクローリングする。このときクローリングするＷｅｂページは、ＥＣＵの型番からＥＣＵの機能（＝名称）を検索するのにふさわしいＷｅｂサイトが好ましい。また、検索ワードとしてＥＣＵ型番全体と、ＥＣＵ型番の機能に関する桁の２種類を用いる。
　なお、ＥＣＵ型番の機能に関する桁については、要素技術３のポイント１の説明のところで述べた手法などにより特定する。なお、特定手法はそれに限定しない。
　Ｓ１０６１－２において、Ｗｅｂ検索部６は、前のステップでクローリングしたＷｅｂページからＥＣＵ型番とそのＥＣＵ型番に対応する機能のペア情報をスクレイピングする。
　Ｓ１０６１－３において、Ｗｅｂ検索部６は、ペア情報を過去の検索結果ＤＢ８に格納する。なお、過去の検索結果ＤＢ８は、例えば図５０（表３０８１）のようなＤＢ構造を持つ
　＜Ｓ１０９１＞
　次に、図５１を参照してＳ１０９１を説明する。Ｓ１０９１において、完全一致抽出部９は、検索結果ＤＢ８からＥＣＵ型番が完全に一致するペア情報を取得する。
　＜Ｓ１１０１＞
　次に、図５２を参照してＳ１１０１を説明する。Ｓ１１０１において、特定部分一致抽出部１０は、検索結果ＤＢ８からＥＣＵ型番の機能に関する桁が一致するペア情報を取得する。
　＜Ｓ１１１１＞
　次に、図５３を参照してＳ１１１１を説明する。Ｓ１１１１－１において、推定部１１は、上記のステップにより取得したペア情報のうち、機能の情報を単語ごとに分割する。例えば「Ｇｅｎｕｉｎｅ　Ｅｎｇｉｎｅ　Ｃｏｎｔｒｏｌ　Ｍｏｄｕｌｅ」という機能の情報を持つペア情報が得られた場合、これを「Ｇｅｎｕｉｎｅ」「Ｅｎｇｉｎｅ」「Ｃｏｎｔｒｏｌ」「Ｍｏｄｕｌｅ」の４つに分割する。
　Ｓ１１１１－２において、推定部１１は、前のステップで分割した単語のうち、機能に関係ない頻出単語を削除する。例えば、前のステップの例で言うと「Ｇｅｎｕｉｎｅ」を削除する。なお、削除しなくても良い。
　Ｓ１１１１－３において、推定部１１は、分割した各単語の支持度を算出する。具体的には、単語ｘの支持度は下記の式で計算される。支持度の計算結果例を図５４（表３１１１）に示す。
　支持度（ｘ）＝（ｘを含むペア情報の数）／（全ペア情報の数）
　Ｓ１１１１－４において、推定部１１は、各ペア情報の機能の情報に含まれる単語の支持度の和を計算する。そして和が最も大きいペア情報を出力する。なお、和以外に、平均や積が最大の物を選んでも良い。
　一例として、図５５に示す支持度の例に基づく和を算出する過程と結果を以下に示す。
　１．Ｇａｓ　Ｍｏｔｏｒ　Ｍｏｄｕｌｅ
　　和＝０．２５＋０．５＋１．０＝１．７５
　２．Ｅｎｇｉｎｅ　Ｍｏｔｏｒ　Ｃｏｎｔｒｏｌ　Ｍｏｄｕｌｅ
　　和＝０．７５＋０．５＋０．７５＋１．０＝３．０
　３．Ｅｎｇｉｎｅ　Ｃｏｎｔｒｏｌ　Ｍｏｄｕｌｅ
　　和＝０．７５＋０．７５＋１．０＝２．５
　４．Ｅｎｇｉｎｅ　Ｃｏｎｔｒｏｌ　Ｍｏｄｕｌｅ
　　和＝０．７５＋０．７５＋１．０＝２．５
　２の情報が最大値を持つので、２のペア情報を出力する。なお、図５５の基となったペア情報の機能の情報は下記のとおりである。
　１．Ｇａｓ　Ｍｏｔｏｒ　Ｍｏｄｕｌｅ
　２．Ｅｎｇｉｎｅ　Ｍｏｔｏｒ　Ｃｏｎｔｒｏｌ　Ｍｏｄｕｌｅ
　３．Ｅｎｇｉｎｅ　Ｃｏｎｔｒｏｌ　Ｍｏｄｕｌｅ
　４．Ｅｎｇｉｎｅ　Ｃｏｎｔｒｏｌ　Ｍｏｄｕｌｅ
　Ｓ１１１１―５において、推定部１１は、以下で説明するラベル付けした結果を、構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２の図４０（表３０３６）もしくは図４７（表３０３９）の適切なＥＣＵ型番を持つ行に追加する。その結果の例を図５６（表３１１２）と図５７（表３１１３）に示す。ラベル付けに関しては下記のとおりである。
　検索結果ＤＢ８から取得した「ＥＣＵ型番が完全に一致するペア情報」を本処理で利用する場合は、ＥＣＵ型番が完全に一致するペア情報のみを利用して処理を行う。そして、出力結果には「完全一致」というラベルを付ける。一方、検索結果ＤＢ８から取得した「ＥＣＵ型番の特定部分が一致するペア情報」を本処理で利用する場合は、ＥＣＵ型番の特定部分が一致するペア情報のみを利用して処理を行う。そして、出力結果には「部分一致」というラベルを付ける。
　＜Ｓ１１２０＞
　次に、Ｓ１１２０について図５８を参照して説明する。Ｓ１１２０－１において、ＮＷ＿Ｂトポロジ推定部１２は、Ｓ１１２１を実行する。Ｓ１１２０－２において、ＮＷ＿Ｂトポロジ推定部１２は、Ｓ１１２２を実行する。
　＜Ｓ１１２１＞
　次に、図５９を参照してＳ１１２１を説明する。Ｓ１１２１－１において、ＮＷ＿Ｂトポロジ推定部１２は、下記の変数を宣言する。
　・構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２から取得した、図５４（表３１１１）のＩＰアドレスのリスト"ＩＰ＝［１９２．１６８．１０．１，１９２．１６８．１０．２，１９２．１６８．１０．３］"
　・ＩＰリストの長さ"Ｌｅｎｇｔｈ（ＩＰ）"（本例の場合はＬｅｎｇｔｈ（ＩＰ）＝３）
　・ｉ＝０
　なお、変数名は上記以外でも良い。また、ＩＰの中身をＩＰアドレス以外の値で統一しても良い。
　Ｓ１１２１－２において、ＮＷ＿Ｂトポロジ推定部１２は、ｉ＜Ｌｅｎｇｔｈ（ＩＰ）を満たすか否かを判断し、ＹｅｓであればＳ１１２１－３に進み、Ｎｏであれば処理を終了する。
　Ｓ１１２１－３において、ＮＷ＿Ｂトポロジ推定部１２は、車載ＮＷ１上のＩＰ［ｉ］に対してＩＣＭＰのｔｒａｃｅｒｏｕｔｅを実行し、結果を記憶手段に記録する。記録される情報の例を図６０に示す。Ｓ１１２１－４において、ｉ＝ｉ＋１とし、Ｓ１１２１－２に戻る。
　＜Ｓ１１２２＞
　図６１を参照してＳ１１２２について説明する。
　Ｓ１１２２－１において、ＮＷ＿Ｂトポロジ推定部１２は、構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２の図５６（表３１１２）からすべてのＥＣＵ型番を取り出す。次に、ＮＷ＿Ｂトポロジ推定部１２は、取り出したＥＣＵ型番の重複を削除する。そして、重複が削除されたＥＣＵ型番と物理的なＥＣＵを１対１対応させる。結果の例を図６２に示す。
　Ｓ１１２２－２において、ＮＷ＿Ｂトポロジ推定部１２は、構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２から取得した、図５６（表３１１２）の「ＥＣＵ型番」と「ＭＡＣアドレス」と「ＩＰアドレス」に基づいて、ネットワークインターフェースを図６２の情報に追加する。その結果は図６３に示すとおりである。
　Ｓ１１２２－３において、ＮＷ＿Ｂトポロジ推定部１２は、構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２から取得した、図５６（表３１１２）のすべての情報をＥＣＵやＥＣＵのインターフェースに適切に割り当てる。その結果は図６４に示す通りである。
　Ｓ１１２２－４において、ＮＷ＿Ｂトポロジ推定部１２は、ｔｒａｃｅｒｏｕｔｅの記録（図６２）を基に、ＯＢＤ－ＩＩポートとＥＣＵのネットワークインターフェース（延いては物理的なＥＣＵ）とＩＰルータのＮＷ＿Ｂケーブルによる接続関係を整理する。なお、同一ＩＰルータの配下に複数のＥＣＵが存在する場合は、それらのＥＣＵとＩＰルータが一つのＮＷ＿Ｂ　ｓｗｉｔｃｈで接続されていると推定する。また、複数のＥＣＵが車載ネットワークに存在するが、ＩＰルータが存在しない場合も、それらのＥＣＵが一つのＮＷ＿Ｂ　ｓｗｉｔｃｈで接続されていると推定する。その結果は図６５に示すとおりである。なお、ＥＣＵ同士の接続関係の整理方法はこれに限るものではない。
　Ｓ１１２２－５において、ＮＷ＿Ｂトポロジ推定部１２は、図６５の推定結果を構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２に格納する。
　＜Ｓ１１３０＞
　次に、図６６を参照して、ＮＷ＿Ａバストポロジ推定部１３によるＳ１１３０について説明する。
　Ｓ１１３０－１において、ベースＲＴＴ算出部１４がＳ１１４１を実行する。Ｓ１１３０－２において、輻輳ＲＴＴ算出部１５がＳ１１５１を実行する。Ｓ１１３０－３において、輻輳ＲＴＴ算出部１５がＳ１１５２を実行する。Ｓ１１３０－４において、ＲＴＴ比較部１６がＳ１１６１を実行する。Ｓ１１３０－５において、推定部１７がＳ１１７１を実行する。Ｓ１１３０－６において、推定部１７がＳ１１７２を実行する。
　＜Ｓ１１４１＞
　次に、図６７を参照してＳ１１４１について説明する。
　Ｓ１１４１―１において、ベースＲＴＴ算出部１４は、ＮＷ＿Ａ－ＩＤ［ｉ］に対してＵＤＳで規定されるＴｅｓｔｅｒＰｒｅｓｅｎｔ要求を２００ｍｓ間隔で１００回送信する。そして、それに対しての応答を受信する。さらに、それらの送信時刻と受信時刻を記憶手段に記録する。記録した情報の例を図６８に示す。なお、送信間隔や送信回数はこれに限らない。
　Ｓ１１４１―２において、ベースＲＴＴ算出部１４は、前のステップの記録（図６８）を用いて応答時間（以降、ペース応答時間と呼称）の統計値を算出する。そしてその結果をＮＷ＿Ａ－ＩＤ［ｉ］とともに記録する（例：図６９（表３１４１））。なお、要求ＮＷ＿Ａ－ＩＤ（図６８で言えば０ｘ７００）でＴｅｓｔｅｒＰｒｅｓｅｎｔを送信した時刻と、その直後に応答ＮＷ＿Ａ－ＩＤ（図６８で言えば０ｘ７０８）でＴｅｓｔｅｒＰｒｅｓｅｎｔを受信した時刻の差をベース応答時間とする。また、統計値として平均値・最大値、最小値、標準偏差を算出する。ただし、その他の統計値を算出しても良い。
　＜Ｓ１１５１＞
　次に、図７０を参照してＳ１１５１について説明する。
　Ｓ１１５１－１において、輻輳ＲＴＴ算出部１５は、下記の変数を宣言する。
　・構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２から取得した、図５７（表３１１３）の要求ＮＷ＿Ａ－ＩＤを昇順にしたリスト"ＮＷ＿Ａ－ＩＤ＝［０ｘ７００，０ｘ７２４，０ｘ７５０，０ｘ７Ｅ０，０ｘ７Ｅ１］"
　・リストの長さ"Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）"（本例の場合はＬｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）＝５）
　・ｉ＝０
　なお、変数名は上記以外でも良い。また、ＮＷ＿Ａ－ＩＤの中身をＮＷ＿Ａ－ＩＤ以外の値で統一しても良い。
　Ｓ１１５１－２において、輻輳ＲＴＴ算出部１５は、ｉ＜Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）を満たすか否かを判断する。ＹｅｓであればＳ１１５１－２に進み、Ｎｏであれば処理を終了する。Ｓ１１５１－３において、ｊ＝ｉ＋１とする。
　Ｓ１１５１－４において、輻輳ＲＴＴ算出部１５は、ｊ＜Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）を満たすか否かを判断する。ＹｅｓであればＳ１１５１－５に進み、Ｎｏであれば処理を終了する。Ｓ１１５１－５において、輻輳ＲＴＴ算出部１５は、Ｓ１１５２を実行して、Ｓ１１５１－２に戻る。
　＜Ｓ１１５２＞
　次に、図７１を参照してＳ１１５２について説明する。
　Ｓ１１５２－１において、輻輳ＲＴＴ算出部１５は、ＮＷ＿Ａ－ＩＤ［ｉ］に対してＵＤＳで規定されるＴｅｓｔｅｒＰｒｅｓｅｎｔ要求を０．５ｍｓ間隔で、Ｓ１１５２が終了するまで送信し続け、ＮＷ＿Ａ－ＩＤ［ｉ］のＮＷ＿Ａメッセージが送信されるＮＷ＿Ａバスを輻輳させる。なお、送信間隔はこれに限らない。
　Ｓ１１５２－２において、輻輳ＲＴＴ算出部１５は、ＮＷ＿Ａ－ＩＤ［ｊ］に対してＵＤＳで規定されるＴｅｓｔｅｒＰｒｅｓｅｎｔ要求を２００ｍｓ間隔で１００回送信する。そして、それに対しての応答を受信する。さらに、それらの送信時刻と受信時刻を記憶手段に記録する。記録された情報の例を図７２に示す。なお、送信間隔や送信回数はこれに限らない。
　Ｓ１１５２－３において、輻輳ＲＴＴ算出部１５は、前のステップの記録を用いて応答時間（以降、輻輳時応答時間と呼称）の統計値を算出する。そしてその結果をＮＷ＿Ａ－ＩＤ［ｉ］（図７３（表３１５１）では輻輳ＮＷ＿Ａ－ＩＤと呼称）とＮＷ＿Ａ－ＩＤ［ｊ］（図７３（表３１５１）では統計値算出対象ＮＷ＿Ａ－ＩＤと呼称）とともに記憶手段に記録する。記録された情報の例を図７３（表３１５１）に示す。
　なお、要求ＮＷ＿Ａ－ＩＤでＴｅｓｔｅｒＰｒｅｓｅｎｔを送信した時刻と、その直後に応答ＮＷ＿Ａ－ＩＤでＴｅｓｔｅｒＰｒｅｓｅｎｔを受信した時刻の差を輻輳時応答時間とする。また、統計値として平均値・最大値、最小値、標準偏差を算出する。ただし、その他の統計値を算出しても良い
　＜Ｓ１１６２＞
　次に、図７４を参照してＳ１１６１について説明する。
　Ｓ１１６１－１において、ＲＴＴ比較部１６は、とあるＮＷ＿Ａ－ＩＤ＝ｘについて、図６９（表３１４１）のＮＷ＿Ａ－ＩＤ＝ｘの統計値と図７３（表３１５１）の統計値算出用のＮＷ＿Ａ－ＩＤ＝ｘの統計値を比較する。そして、図７３（表３１５１）側の統計値のいずれかの値が図６９（表３１４１）よりも５０％以上増加している行を図７３（表３１５１）から抽出する。抽出結果は図７５（表３１６１）に示す通りである。なお、図７５（表３１６１）の抽出方法はこれに限るものではない。
　Ｓ１１６１－２において、ＲＴＴ比較部１６は、図７５（表３１６１）の各行の輻輳ＮＷ＿Ａ－ＩＤと統計値算出対象ＮＷ＿Ａ－ＩＤをグルーピングする。例えば、０ｘ７００と０ｘ７２４は一つのグループであり、０ｘ７００と０ｘ７Ｅ０は一つのグループであり、０ｘ７２４と０ｘ７Ｅ０は一つのグループであり、０ｘ７５０と０ｘ７Ｅ１は一つのグループである。
　Ｓ１１６１－３において、ＲＴＴ比較部１６は、前のステップで作ったグループを可能な限りまとめる。例えば、０ｘ７００と０ｘ７２４は一つのグループであり、０ｘ７００と０ｘ７Ｅ０は一つのグループであり、０ｘ７２４と０ｘ７Ｅ０は一つのグループでることから、これら３つは一つのグループであるとする。その結果は図７６（表３１６２）の通りである。
　＜Ｓ１１７１＞
　次に、図７７を参照してＳ１１７１を説明する。
　Ｓ１１７１－１において、推定部１７は、構成情報推定結果ＤＢ２２に格納されている図５６（表３１１２）相当の情報からすべてのＥＣＵ型番を取り出す。次に、取り出したＥＣＵ型番の重複を削除する。そして重複が削除されたＥＣＵ型番と物理的なＥＣＵを１対１対応させる。結果は図７８に示す通りである。
　Ｓ１１７１－２において、推定部１７は、構成情報推定結果ＤＢ２２に格納されている図５６（表３１１２）相当の情報に基づいて要求ＮＷ＿Ａ－ＩＤの情報を図７８に追加する。その結果は図７９に示すとおりである。
　Ｓ１１７１－３において、推定部１７は、とあるＮＷ＿Ａ－ＩＤ＝ｘについて、図６９（表３１４１）のＮＷ＿Ａ－ＩＤ＝ｘの統計値と図７３（表３１５１）の統計値算出用のＮＷ＿Ａ－ＩＤ＝ｘの統計値を比較する。そして、図７３（表３１５１）側の統計値のいずれかの値が図６９（表３１４１）よりも５０％以上増加している行を図７３（表３１５１）から抽出する。抽出結果は図７５（表３１６１）に示すとおりである。なお、図７５（表３１６１）の抽出方法はこれに限るものではない。
　Ｓ１１７１－４において、推定部１７は、図７５（表３１６１）の各行の輻輳ＮＷ＿Ａ－ＩＤと統計値算出対象ＮＷ＿Ａ－ＩＤをグルーピングする。例えば、０ｘ７００と０ｘ７２４は一つのグループであり、０ｘ７００と０ｘ７Ｅ０は一つのグループであり、０ｘ７２４と０ｘ７Ｅ０は一つのグループであり、０ｘ７５０と０ｘ７Ｅ１は一つのグループである。
　Ｓ１１７１－５において、推定部１７は、前のステップで作ったグループを可能な限りまとめる。例えば、０ｘ７００と０ｘ７２４は一つのグループであり、０ｘ７００と０ｘ７Ｅ０は一つのグループであり、０ｘ７２４と０ｘ７Ｅ０は一つのグループでることから、これら３つは一つのグループであるとする。その結果は図７６（表３１６２）の通りである。
　＜Ｓ１１７２＞
　次に、図８０を参照してＳ１１７２を説明する。
　Ｓ１１７２－１において、推定部１７は、図７６（表３１６２）で一つのグループにまとめられているＮＷ＿Ａ－ＩＤのＮＷ＿Ａメッセージに対して応答するＥＣＵは同一のＮＷ＿Ａバスに接続されていると判定する。そして推定部１７は、その判定結果を基に、図７９の情報をＮＷ＿Ａバスのトポロジ図（図８１）に変換する。
　Ｓ１１７２－２において、推定部１７は、構成情報推定結果ＤＢ２２（構成情報整理部）に渡された図５６（表３１１２）のすべての情報をＥＣＵに適切に割り当てる。その結果は図８２に示す通りである。
　Ｓ１１７２－３において、推定部１７は、構成情報推定結果ＤＢ２２（構成情報整理部）に渡された図６５のＮｏｄｅＴｙｐｅ＝０ｘ１のＥＣＵと、図８２のＥＣＵの機能の「完全一致」もしくは「部分一致」にＧＷ（ｇａｔｅｗａｙ）が含まれているＥＣＵを探索する。
　Ｓ１１７２－４において、推定部１７は、前のステップで見つけたＥＣＵをＮＷ＿Ａバスで接続する。その結果は図８３に示す通りである。
　Ｓ１１７２－５において、推定部１７は、図８３に示す情報を構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２に格納する
　＜Ｓ１１８０＞
　次に、図８４を参照して正常ＮＷ＿Ａ通信推定部１８によるＳ１１８０を説明する。
　Ｓ１１８０－１において、再起動命令送信部１９は、Ｓ１１９１を実行する。Ｓ１１８０－２において、再起動命令送信部１９は、Ｓ１１９２を実行する。Ｓ１１８０－３において、車両アラート受信部２０は、Ｓ１２０１を実行する。Ｓ１１８０－４において、車両アラート受信部２０は、Ｓ１２１１を実行する。
　＜Ｓ１１９１＞
　次に、図８５を参照してＳ１１９１を説明する。
　Ｓ１１９１－１において、再起動命令送信部１９は、下記の変数を宣言する。
　・構成情報推定結果ＤＢ２２に格納された図５６（表３１１２）の要求ＮＷ＿Ａ－ＩＤリスト"ＮＷ＿Ａ－ＩＤ＝［０ｘ７００，０ｘ７２４，０ｘ７５０，０ｘ７Ｅ０，０ｘ７Ｅ１］"
　・リストの長さ"Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）"（本例の場合はＬｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）＝５）
　・ｉ＝０
　なお、変数名は上記以外でも良い。また、ＮＷ＿Ａ－ＩＤの中身をＮＷ＿Ａ－ＩＤ以外の値で統一しても良い。
　Ｓ１１９１－２において、再起動命令送信部１９は、ｉ＜Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）が成り立つかどうかを判断する。Ｙｅｓの場合はＳ１１９１－３に進み、Ｎｏの場合は処理を終了する。Ｓ１１９１－３において、再起動命令送信部１９は、Ｓ１１９２を実行する。Ｓ１１９１－３において、再起動命令送信部１９は、ｉ＝ｉ＋１として、Ｓ１１９１－２に戻る。
　＜Ｓ１１９２＞
　次に、図８６を参照してＳ１１９２について説明する。
　Ｓ１１９２－１において、再起動命令送信部１９は、ＮＷ＿Ａ－ＩＤ［ｉ］に対してＵＤＳで規定されるＥＣＵＲｅｓｅｔ（ＲｅｓｅｔＴｙｐｅ＝ＨａｒｄＲｅｓｅｔ）要求を５秒から１０秒のランダムな間隔で１０回送信する。なお、送信間隔や送信回数、ＲｅｓｅｔＴｙｐｅはこれに限らない。
　Ｓ１１９２－２において、再起動命令送信部１９は、前のステップでＥＣＵＲｅｓｅｔ要求を送信した時刻をＮＷ＿Ａ－ＩＤ［ｉ］とともに記憶手段に記録する。記録した情報の例を図８７に示す。
　＜Ｓ１２０１＞
　次に、図８８を参照してＳ１２０１について説明する。
　まず、前提を説明する。車載ネットワーク１上のＥＣＵはあるＮＷ＿Ａ－ＩＤのＮＷ＿Ａメッセージを一定（設計値）の時間間隔（送信間隔）で送信している。また、車載ネットワーク１上のＮＷ＿Ａ－ＩＤＳはあるＮＷ＿Ａ－ＩＤのＮＷ＿Ａメッセージの送信間隔が設計値を大きく逸脱している場合にアラートを発報する。なお、アラートには発報時刻と検知されたＮＷ＿ＡメッセージのＮＷ＿Ａ－ＩＤが格納されているとする。
　ＥＣＵＲｅｓｅｔを受信したＥＣＵはＥＣＵの再起動を実行するため、一時的にＮＷ＿Ａメッセージの送信を停止する。また、再起動後は任意の時間を空けてＮＷ＿Ａメッセージの送信を再開する。そのため、ＥＣＵＲｅｓｅｔを受信したＥＣＵが送信するＮＷ＿Ａメッセージの送信間隔は一時的に大きくなる、あるいは小さくなる。ＮＷ＿Ａ－ＩＤＳはこれを異常と判定しアラートを発報する
　Ｓ１２０１－１において、車両アラート受信部２０は、ＮＷ＿Ａ－ＩＤＳのアラートを時刻とともに記憶手段に記録する。記憶した情報の例を図８９に示す。
　＜Ｓ１２１１＞
　次に、図９０を参照してＳ１２１１について説明する。
　Ｓ１２１１－１において、推定部２１は、図８７に示す情報として記録されているＮＷ＿Ａ－ＩＤと図８９に示す情報として記録されているＮＷ＿Ａ－ＩＤを関連付ける。関連付ける際は、記録された時刻の類似性を基に行う。関連付けを行った結果の例を図９１（表３２１１）に示す。
　Ｓ１２１１－２において、推定部２１は、図９１（表３２１１）の結果を車両構成推定の結果（例えば図８３や図５６（表３１１２））に追加する。その際は、「表３２１１のＥＣＵＲｅｓｅｔのＮＷ＿Ａ－ＩＤ列」＝「図８３や表３１１２の要求ＮＷ＿Ａ－ＩＤ」の条件を満たす行を図８３や図５６（表３１１２）に追加する。
　なお、追加する際は例えば「定常送信ＮＷ＿Ａ－ＩＤ」という列名で追加する。その結果例は図９２や図９３（表３２１２）に示す通りである。
　（実施例Ａ２）
　次に、実施例Ａ２について説明する。図９４は、実施例Ａ２におけるシステムの構成図である。図９４に示すように、実施例Ａ２における構成は、推定部として、要素技術３に対応するＥＣＵ機能推定部４のみを備えた構成である。各部の処理については実施例Ａ１において説明した処理と同じである。
　（実施例Ａ３）
　次に、実施例Ａ３について説明する。図９５は、実施例Ａ３におけるシステムの構成図である。図９５に示すように、実施例Ａ３における構成は、推定部として、要素技術１に対応するＮＷ＿Ａバストポロジ推定部１３のみを備えた構成である。各部の処理については実施例Ａ１において説明した処理と同じである。
　（実施例Ａ４）
　次に、実施例Ａ４について説明する。図９６は、実施例Ａ４におけるシステムの構成図である。図９６に示すように、実施例Ａ４における構成は、推定部として、要素技術２に対応する正常ＮＷ＿Ａ通信推定部１８のみを備えた構成である。各部の処理については実施例Ａ１において説明した処理と同じである。
　（実施例Ａ５）
　次に、実施例Ａ５について説明する。図９７は、実施例Ａ５におけるシステムの構成図である。図９７に示すように、実施例Ａ５における構成は、実施例Ａ１（図２７）の構成から、正常ＮＷ＿Ａ通信推定部１８を除いた構成である。各部の処理については実施例Ａ１において説明した処理と同じである。
　（実施例Ａ６）
　次に、実施例Ａ６について説明する。図９８は、実施例Ａ６におけるシステムの構成図である。図９８に示すように、実施例Ａ６における構成は、実施例Ａ１（図２７）の構成から、ＮＷ＿Ａバストポロジ推定部１３を除いた構成である。各部の処理については実施例Ａ１において説明した処理と同じである。
　（実施例Ａ７）
　次に、実施例Ａ７について説明する。図９９は、実施例Ａ７におけるシステムの構成図である。図９９に示すように、実施例Ａ７における構成は、実施例Ａ１（図２７）の構成から、ＥＣＵ機能推定部４を除いた構成である。各部の処理については実施例Ａ１において説明した処理と同じである。
　（実施例Ｂ１）
　次に、実施例Ｂ１について説明する。実施例Ｂ１は、本発明に係る構成情報推定システムを車載ＮＷ上に配備する実施例である。図１００は、実施例Ｂ１における自動車（車載ＮＷ）の構成図である。図１００に示すように、車載ＮＷ上のＥＣＵの機能として車両構成推定装置２及び構成情報推定結果ＤＢ２２が備えられる。
　なお、図１００のように構成情報推定結果ＤＢ２２をＥＣＵに備えることに代えて、構成情報推定結果ＤＢ２２をクラウド上に備えることとしてもよい。また、車両構成推定装置２において、メッセージ送受信部２３以外の１つ又は複数の機能部をクラウド上に備えることとしてもよい。例えば車両構成推定装置２におけるＥＣＵ機能推定部４のみをクラウド上に備えることとしてもよい。
　（実施例Ｂ２）
　次に、実施例Ｂ２について説明する。実施例Ｂ２は、本発明に係る構成情報推定システム（装置）をＯＢＤ－ＩＩポートに直接接続する実施例である。図１０１は、実施例Ｂ２におけるシステムの構成図である。図１０１に示すように、構成情報推定システムがＯＢＤ－ＩＩポートに直接接続する。
　なお、図１０１のように構成情報推定結果ＤＢ２２を構成情報推定システム（装置）上に備えることに代えて、構成情報推定結果ＤＢ２２をクラウド上に備えることとしてもよい。また、車両構成推定装置２において、メッセージ送受信部２３以外の１つ又は複数の機能部をクラウド上に備えることとしてもよい。例えば車両構成推定装置２におけるＥＣＵ機能推定部４のみをクラウド上に備えることとしてもよい。
　（実施例Ｂ３）
　次に、実施例Ｂ３について説明する。図１０２に実施例Ｂ３におけるシステムの構成を示す。図１０２に示すように、実施例Ｂ３では、本発明に係る構成情報推定システムが、充電器に備えられ、充電ポートに接続される。構成情報推定システムの処理は充電ポートを介して実行される。
　なお、図１０２のように構成情報推定結果ＤＢ２２を充電器上に備えることに代えて、構成情報推定結果ＤＢ２２をクラウド上に備えることとしてもよい。また、車両構成推定装置２において、メッセージ送受信部２３以外の１つ又は複数の機能部をクラウド上に備えることとしてもよい。例えば車両構成推定装置２におけるＥＣＵ機能推定部４のみをクラウド上に備えることとしてもよい。
　（実施例Ｂ４）
　次に、実施例Ｂ４について説明する。図１０３に実施例Ｂ４におけるシステムの構成を示す。図１０３に示すように、実施例Ｂ４では、本発明に係る構成情報推定システムが外部ネットワーク上に備えられ、構成情報推定システムの処理は外部ネットワークを経由して実行される。
　（実施例Ｃ１）
　次に、実施例Ｃ１を説明する。実施例Ｃ１は、構成情報推定システムをＳＯＣ等でのセキュリティ分析に活用する実施例である。図１０４は、実施例Ｃ１におけるシステム構成図である。
　図１０４に示すとおり、本システムは、自動車に接続される車両構成推定装置２、及び構成情報推定結果ＤＢ２２に加えて、構成情報取得部３０、セキュリティ分析部３１、分析結果提示部３２を備える。各部は、図示のとおりに接続されている。
　構成情報取得部３０は、構成情報推定結果ＤＢ２２から必要な構成情報を抽出し、セキュリティ分析部３１に渡す。セキュリティ分析部３１は、車両構成推定装置２が推定した車両構成情報を利用してより高度なセキュリティ分析を行う。そして分析結果を分析結果提示部３２に渡す。
　分析結果提示部３２は、分析結果を受け取り、適宜加工を施し分析官に結果を提示する。なお、分析官は人に限らず、分析結果を利用してさらに別の分析を行うプログラムでも良い。
　セキュリティ分析部３１が実行するセキュリティ分析は特定のものに限定されないが、例えば、下記に列挙する例がある。
　・トポロジ情報を取得利用した攻撃経路の推定
　・トポロジ情報や各ＥＣＵのソフトウェアバージョンを利用したエントリーポイントの推定
　・トポロジ情報や各ＥＣＵのソフトウェアバージョンを利用した原因推定
　・トポロジ情報や各ＥＣＵのソフトウェアバージョン、正常通信の情報を利用した異常な通信やプロセスの推定
　・トポロジ情報や各ＥＣＵのソフトウェアバージョンを利用した、正常通信の情報、各ＥＣＵの機能の情報を利用した影響の推定
　・トポロジ情報や各ＥＣＵのソフトウェアバージョンを利用した対処方法の推定
　（実施例Ｃ２）
　次に、実施例Ｃ２を説明する。実施例Ｃ２は、構成情報推定システムをアセット管理に活用する実施例である。図１０５は、実施例Ｃ２におけるシステム構成図である。
　図１０５に示すとおり、本システムは、自動車に接続される車両構成推定装置２、及び構成情報推定結果ＤＢ２２に加えて、構成情報取得部３０、アセット管理部３３、管理情報提示部３４を備える。各部は、図示のとおりに接続されている。
　構成情報取得部３０は、構成情報推定結果ＤＢ２２から必要な構成情報を抽出し、アセット管理部３３に渡す。アセット管理部３３は管理情報を保持しており、受け取った構成情報を基に、管理情報にないＥＣＵやサポート切れのＥＣＵが存在しないか等の管理を行う。このとき、ＥＣＵのソフトウェアのサポート状況等の公開情報も利用する。
　管理情報提示部３４は、アセット管理部３３より管理情報を取得し、適宜加工を施し（例えば管理情報にないＥＣＵの機器名やアドレス情報のみを抽出・整理）管理者に結果を提示する。なお、管理者は人に限らず、管理情報を利用してさらに別の分析を行うプログラムでも良い。
　（実施例Ｃ３）
　次に、実施例Ｃ３を説明する。実施例Ｃ３は、構成情報推定システムを異常検知に活用する実施例である。図１０６は、実施例Ｃ３におけるシステム構成図である。
　図１０６に示すとおり、本システムは、自動車に接続される車両構成推定装置２、及び構成情報推定結果ＤＢ２２に加えて、構成情報取得部３０、異常検知部３５を備える。各部は、図示のとおりに接続されている。
　構成情報取得部３０は、構成情報推定結果ＤＢ２２から必要な構成情報を抽出し、異常検知部３５に渡す。異常検知部３５は、正常な車両構成情報が格納されたＤＢの情報や異常検知ルール、公開情報（例えば脆弱性ＤＢの情報）を利用して、車両構成情報の異常状態を検知する。さらに、異常検知結果を自動車の管理者やＳＯＣ等の分析官に通知する。
　異常検知手法は特定の手法に限定されないが、例えば、下記に列挙する例がある。
　・正常な車両構成情報ＤＢに格納されている車両構成情報と構成情報推定結果ＤＢに格納されている車両構成情報を比較し、そこに差異があれば異常として検知する。
　・構成情報推定結果ＤＢ２２に格納されている車両構成情報が、異常検知ルールを満たす場合や、公開情報（脆弱性ＤＢ）などで異常状態として定義されている構成情報を持つ場合に異常があるとして検知する。
　・正常な自動車の車両構成情報を機械学習し、学習したモデルに基づいて機械学習ベースの異常検知を行う。
　（実施例Ｃ４）
　次に、実施例Ｃ４を説明する。実施例Ｃ４は、構成情報推定システムをセキュリティ診断に活用する実施例である。図１０７は、実施例Ｃ４におけるシステム構成図である。
　図１０７に示すとおり、本システムは、自動車に接続される車両構成推定装置２、及び構成情報推定結果ＤＢ２２に加えて、構成情報取得部３０、セキュリティ診断部３６、診断結果提示部３７を備える。各部は、図示のとおりに接続されている。
　構成情報取得部３０は、構成情報推定結果ＤＢ２２から必要な構成情報を抽出し、セキュリティ診断部３６に渡す。セキュリティ診断部３６は受け取った構成情報を基に、自動車にセキュリティ的に問題のあるＥＣＵが存在しないか等の診断を行う。このとき、ＥＣＵのソフトウェアのサポート状況等の公開情報を利用して問題の有無を確認する。
　診断結果提示部３７は、セキュリティ診断部３６より診断結果を取得し、適宜加工（例えば診断結果を点数化する等）を施し管理者に結果を提示する。なお、管理者は人に限らず、管理情報を利用してさらに別の分析を行うプログラムでも良い。
　例えば、セキュリティ診断部３６が使用する診断ルールには、脆弱性の確認されているＥＣＵのＥＣＵ型番や、ソフトウェアのバージョン情報（ブラックリスト）が記録されている。セキュリティ診断部３６は、診断ルールに格納されている車両構成情報（ブラックリスト）と構成情報推定結果ＤＢ２２の車両構成情報を比較し、ブラックリストに該当する情報があれば、脆弱性を指摘する。
　（ハードウェア構成例）
　第１の実施の形態で説明した診断通信送受信部１００、診断系ログＤＢ２００、及び構成情報推定部３００からなる装置、診断通信送受信部１００と診断系ログＤＢ２００からなる装置、診断系ログＤＢ２００と構成情報推定部３００からなる装置、診断通信送受信部１００と構成情報推定部３００からなる装置、診断通信送受信部１００からなる装置、診断系ログＤＢ２００からなる装置、及び構成情報推定部３００からなる装置はいずれも、例えば、コンピュータにプログラムを実行させることにより実現できる。このコンピュータは、物理的なコンピュータであってもよいし、クラウド上の仮想マシンであってもよい。
　また、第２の実施の形態で説明したシステム、装置、機能部についても、例えば、コンピュータにプログラムを実行させることにより実現できる。このコンピュータは、物理的なコンピュータであってもよいし、クラウド上の仮想マシンであってもよい。
　上記のプログラムが動作する主体を「装置」と呼ぶことにする。当該装置は、コンピュータに内蔵されるＣＰＵやメモリ等のハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。
　図１０８は、上記コンピュータのハードウェア構成例を示す図である。図１０８のコンピュータは、それぞれバスＢＳで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、入力装置１００７、出力装置１００８等を有する。なお、これらのうち、一部の装置を備えないこととしてもよい。例えば、表示を行わない装置は、表示装置１００６を備えなくてもよい。
　当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
　メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、当該装置に係る機能を実現する。インタフェース装置１００５は、ネットワークに接続するためのインタフェースとして用いられ、送信部及び受信部として機能する。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。出力装置１００８は演算結果を出力する。
　（実施の形態の効果）
　以上、説明したとおり、本発明の実施の形態では、各ＥＣＵにおいて標準的にサポートされている診断通信プロトコル（ＤｏＣＡＮ、ＤｏＩＰ、ＵＤＳ等）を用いた診断通信の送受信を行うことで車両構成情報の推定に有効な情報を収集し、収集した情報を分析することで車両構成情報の推定を行うこととした。これにより、車両構成情報の推定において、リソースの増強や新たなプロトコルのサポートを行う必要が無く、追加のコストを削減できる。
　（実施の形態のまとめ）
　本明細書には、少なくとも下記各項のネットワーク構成推定装置、ネットワーク構成推定方法、及びプログラムが開示されている。
（第１項）
　対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
　前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の電子制御装置に対してメッセージを送信し、当該メッセージに対する応答を受信する診断通信送受信部と、
　前記診断通信送受信部により得られた前記応答に基づいて、前記内部ネットワークの構成情報を推定する構成情報推定部と
　を備えるネットワーク構成推定装置。
（第２項）
　前記構成情報推定部は、
　前記応答に基づいて、前記内部ネットワーク上の電子制御装置の存在を確認する存在確認部と、
　前記存在確認部による電子制御装置の存在確認結果に基づいて、前記内部ネットワークのトポロジを推定するトポロジ推定部と、
　前記応答に基づいて、前記内部ネットワーク上の電子制御装置に関する情報を抽出する情報抽出部と
　を備える第１項に記載のネットワーク構成推定装置。
（第３項）
　前記診断通信送受信部は、前記内部ネットワークにおける第１ネットワークと第２ネットワークのそれぞれにメッセージを送信し、その応答を受信し、
　前記構成情報推定部は、前記第１ネットワークに送信したメッセージの応答により前記第１ネットワークに接続した電子制御装置の存在を確認し、前記第２ネットワークに送信したメッセージの応答により前記第２ネットワークに接続した電子制御装置の存在を確認する
　第１項又は第２項に記載のネットワーク構成推定装置。
（第４項）
　前記診断通信送受信部は、データＩＤを設定したメッセージを送信し、その応答を受信し、
　前記構成情報推定部は、前記データＩＤを設定したメッセージに対する応答から、当該データＩＤに対応する情報を抽出する
　第１項ないし第３項のうちいずれか１項に記載のネットワーク構成推定装置。
（第５項）
　対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
　前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の電子制御装置に対してメッセージを送信し、当該メッセージに対する応答を受信する装置により得られた前記応答に基づいて、前記内部ネットワークの構成情報を推定する構成情報推定部
　を備えるネットワーク構成推定装置。
（第６項）
　対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
　非輻輳時の状態において、前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の第１電子制御装置のラウンドトリップタイムを算出するベースＲＴＴ算出部と、
　第２電子制御装置に対して診断要求を高頻度で送信している輻輳時の状態において、前記第１電子制御装置のラウンドトリップタイムを算出する輻輳ＲＴＴ算出部と、
　前記非輻輳時の状態におけるラウンドトリップタイムと、前記輻輳時の状態におけるラウンドトリップタイムとを比較することにより、前記第１電子制御装置と前記第２電子制御装置が同一バスに接続されているか否かを推定する推定部と
　を備えるネットワーク構成推定装置。
（第７項）
　対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
　前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の対象電子制御装置に再起動命令を送信する再起動命令送信部と、
　前記再起動命令に起因して発生したアラートを前記内部ネットワークから受信するアラート受信部と、
　前記アラートに含まれるＩＤを、前記対象電子制御装置が送信する通常通信のＩＤであると推定する推定部と
　を備えるネットワーク構成推定装置。
（第８項）
　対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
　前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて取得した対象電子制御装置の型番の全体、及び、当該型番における機能に関する桁を用いて、電子制御装置の機能を検索するＷｅｂ検索部と、
　前記Ｗｅｂ検索部により得られた検索結果に含まれる単語の支持度の和が最大となる機能を前記対象電子制御装置の機能と推定する推定部と
　を備えるネットワーク構成推定装置。
（第９項）
　対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置が実行するネットワーク構成推定方法であって、
　前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の電子制御装置に対してメッセージを送信し、当該メッセージに対する応答を受信するステップと、
　前記応答に基づいて、前記内部ネットワークの構成情報を推定するステップと
　を備えるネットワーク構成推定方法。
（第１０項）
　コンピュータを、第１項ないし第８項のうちいずれか１項に記載のネットワーク構成推定装置における各部として機能させるためのプログラム。
　以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
　本特許出願は２０２０年９月１８日に出願した国際特許出願ＰＣＴ／ＪＰ２０２０／０３５６２１に基づきその優先権を主張するものであり、国際特許出願ＰＣＴ／ＪＰ２０２０／０３５６２１の全内容を本願に援用する。
１　車載ＮＷ
２　構成要素推定部
３　ＥＣＵ基本情報取得部
４　ＥＣＵ機能推定部
６　Ｗｅｂ検索部
７　Ｗｅｂサイト
８　検索結果ＤＢ
９　完全一致抽出部
１０　特定部分一致抽出部
１１　推定部
１２　ＮＷ＿Ｂトポロジ推定部
１３　ＮＷ＿Ａバストポロジ推定部
１４　ベースＲＴＴ算出部
１５　輻輳ＲＴＴ算出部
１６　ＲＴＴ比較部
１７　推定部
１８　正常ＮＷ＿Ａ通信推定部
１９　再起動命令送信部
２０　車両アラート受信部
２１　推定部
２２　構成情報推定結果ＤＢ
２３　メッセージ送受信部
２４　構成情報取得・登録部
３０　構成情報取得部
３１　セキュリティ分析部
３２　分析結果提示部
３３　アセット管理部
３４　管理情報提示部
３５　異常検知部
３６　セキュリティ診断部
３７　診断結果提示部
５００　ＥＣＵ
１００　診断通信送受信部
２００　診断系ログＤＢ
３００　構成情報推定部
３１０　ＥＣＵ存在確認部
３２０　トポロジ推定部
３３０　ＥＣＵ情報抽出部
３４０　出力部
４００　自動車
１０００　ドライブ装置
１００１　記録媒体
１００２　補助記憶装置
１００３　メモリ装置
１００４　ＣＰＵ
１００５　インタフェース装置
１００６　表示装置
１００７　入力装置
１００８　出力装置

Claims (10)

  1. 　対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
    　前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の電子制御装置に対してメッセージを送信し、当該メッセージに対する応答を受信する診断通信送受信部と、
    　前記診断通信送受信部により得られた前記応答に基づいて、前記内部ネットワークの構成情報を推定する構成情報推定部と
    　を備えるネットワーク構成推定装置。
  2. 　前記構成情報推定部は、
    　前記応答に基づいて、前記内部ネットワーク上の電子制御装置の存在を確認する存在確認部と、
    　前記存在確認部による電子制御装置の存在確認結果に基づいて、前記内部ネットワークのトポロジを推定するトポロジ推定部と、
    　前記応答に基づいて、前記内部ネットワーク上の電子制御装置に関する情報を抽出する情報抽出部と
    　を備える請求項１に記載のネットワーク構成推定装置。
  3. 　前記診断通信送受信部は、前記内部ネットワークにおける第１ネットワークと第２ネットワークのそれぞれにメッセージを送信し、その応答を受信し、
    　前記構成情報推定部は、前記第１ネットワークに送信したメッセージの応答により前記第１ネットワークに接続した電子制御装置の存在を確認し、前記第２ネットワークに送信したメッセージの応答により前記第２ネットワークに接続した電子制御装置の存在を確認する
    　請求項１又は２に記載のネットワーク構成推定装置。
  4. 　前記診断通信送受信部は、データＩＤを設定したメッセージを送信し、その応答を受信し、
    　前記構成情報推定部は、前記データＩＤを設定したメッセージに対する応答から、当該データＩＤに対応する情報を抽出する
    　請求項１ないし３のうちいずれか１項に記載のネットワーク構成推定装置。
  5. 　対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
    　前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の電子制御装置に対してメッセージを送信し、当該メッセージに対する応答を受信する装置により得られた前記応答に基づいて、前記内部ネットワークの構成情報を推定する構成情報推定部
    　を備えるネットワーク構成推定装置。
  6. 　対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
    　非輻輳時の状態において、前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の第１電子制御装置のラウンドトリップタイムを算出するベースＲＴＴ算出部と、
    　第２電子制御装置に対して診断要求を高頻度で送信している輻輳時の状態において、前記第１電子制御装置のラウンドトリップタイムを算出する輻輳ＲＴＴ算出部と、
    　前記非輻輳時の状態におけるラウンドトリップタイムと、前記輻輳時の状態におけるラウンドトリップタイムとを比較することにより、前記第１電子制御装置と前記第２電子制御装置が同一バスに接続されているか否かを推定する推定部と
    　を備えるネットワーク構成推定装置。
  7. 　対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
    　前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の対象電子制御装置に再起動命令を送信する再起動命令送信部と、
    　前記再起動命令に起因して発生したアラートを前記内部ネットワークから受信するアラート受信部と、
    　前記アラートに含まれるＩＤを、前記対象電子制御装置が送信する通常通信のＩＤであると推定する推定部と
    　を備えるネットワーク構成推定装置。
  8. 　対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
    　前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて取得した対象電子制御装置の型番の全体、及び、当該型番における機能に関する桁を用いて、電子制御装置の機能を検索するＷｅｂ検索部と、
    　前記Ｗｅｂ検索部により得られた検索結果に含まれる単語の支持度の和が最大となる機能を前記対象電子制御装置の機能と推定する推定部と
    　を備えるネットワーク構成推定装置。
  9. 　対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置が実行するネットワーク構成推定方法であって、
    　前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の電子制御装置に対してメッセージを送信し、当該メッセージに対する応答を受信するステップと、
    　前記応答に基づいて、前記内部ネットワークの構成情報を推定するステップと
    　を備えるネットワーク構成推定方法。
  10. 　コンピュータを、請求項１ないし８のうちいずれか１項に記載のネットワーク構成推定装置における各部として機能させるためのプログラム。
PCT/JP2021/032301 2020-09-18 2021-09-02 ネットワーク構成推定装置、ネットワーク構成推定方法、及びプログラム WO2022059503A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP21869190.5A EP4216494A4 (en) 2020-09-18 2021-09-02 NETWORK CONFIGURATION ESTIMATION DEVICE, NETWORK CONFIGURATION ESTIMATION METHOD, AND PROGRAM
US18/042,401 US20230327956A1 (en) 2020-09-18 2021-09-02 Network configuration estimation apparatus, network configuration estimation method and program
CN202180063068.2A CN116114221A (zh) 2020-09-18 2021-09-02 网络设定估计装置、网络设定估计方法及程序
JP2022550459A JPWO2022059503A1 (ja) 2020-09-18 2021-09-02

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JPPCT/JP2020/035621 2020-09-18
PCT/JP2020/035621 WO2022059206A1 (ja) 2020-09-18 2020-09-18 ネットワーク構成推定装置、ネットワーク構成推定方法、及びプログラム

Publications (1)

Publication Number Publication Date
WO2022059503A1 true WO2022059503A1 (ja) 2022-03-24

Family

ID=80776752

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/JP2020/035621 WO2022059206A1 (ja) 2020-09-18 2020-09-18 ネットワーク構成推定装置、ネットワーク構成推定方法、及びプログラム
PCT/JP2021/032301 WO2022059503A1 (ja) 2020-09-18 2021-09-02 ネットワーク構成推定装置、ネットワーク構成推定方法、及びプログラム

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/035621 WO2022059206A1 (ja) 2020-09-18 2020-09-18 ネットワーク構成推定装置、ネットワーク構成推定方法、及びプログラム

Country Status (5)

Country Link
US (1) US20230327956A1 (ja)
EP (1) EP4216494A4 (ja)
JP (1) JPWO2022059503A1 (ja)
CN (1) CN116114221A (ja)
WO (2) WO2022059206A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7517223B2 (ja) * 2021-03-29 2024-07-17 株式会社デンソー 攻撃分析装置、攻撃分析方法、及び攻撃分析プログラム
JP2023149712A (ja) * 2022-03-31 2023-10-13 パナソニックＩｐマネジメント株式会社 車載装置およびログ管理方法
KR20240026754A (ko) * 2022-08-22 2024-02-29 현대자동차주식회사 차량 네트워크 내의 통신 채널 상태를 진단하는 방법 및 시스템

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007099145A (ja) * 2005-10-06 2007-04-19 Denso Corp 車載ネットワークの診断システム及び車載制御装置
US20140188330A1 (en) * 2006-03-14 2014-07-03 Snap-On Incorporated Method and system for enhanced scanner user interface
WO2019073932A1 (ja) * 2017-10-12 2019-04-18 日立オートモティブシステムズ株式会社 情報更新装置、情報更新方法
CN110908357A (zh) * 2019-10-23 2020-03-24 深圳开源互联网安全技术有限公司 一种安全漏洞检测方法、装置、存储介质和智能设备
KR20200143961A (ko) * 2019-06-17 2020-12-28 현대자동차주식회사 차량 진단 통신 장치, 그를 포함한 시스템 및 그 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007099145A (ja) * 2005-10-06 2007-04-19 Denso Corp 車載ネットワークの診断システム及び車載制御装置
US20140188330A1 (en) * 2006-03-14 2014-07-03 Snap-On Incorporated Method and system for enhanced scanner user interface
WO2019073932A1 (ja) * 2017-10-12 2019-04-18 日立オートモティブシステムズ株式会社 情報更新装置、情報更新方法
KR20200143961A (ko) * 2019-06-17 2020-12-28 현대자동차주식회사 차량 진단 통신 장치, 그를 포함한 시스템 및 그 방법
CN110908357A (zh) * 2019-10-23 2020-03-24 深圳开源互联网安全技术有限公司 一种安全漏洞检测方法、装置、存储介质和智能设备

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
JING JIANGXIAO XUNING CAO: "Research on improved physical topology discovery based on SNMP", 2017 IEEE INTERNATIONAL CONFERENCE ON COMPUTATIONAL SCIENCE AND ENGINEERING (CSE) AND IEEE CONFERENCE ON EMBEDDED AND UBIQUITOUS COMPUTING (EUC, 2017, pages 219 - 222, XP033139964, DOI: 10.1109/CSE-EUC.2017.224
See also references of EP4216494A4
SEKAR KULANDAIVELTUSHAR GOYALARNAV KUMAR AGRAWALVYAS SEKAR: "CANvas: Fast and Inexpensive Automotive Network Mapping", PROCEEDINGS OF THE 28TH USENIX SECURITY SYMPOSIUM, 2019, pages 389 - 405
X. FENG ET AL.: "Acquisitional Rule-based Engine for Discovering Internet-of-Things Dvices", USENIX, 2018

Also Published As

Publication number Publication date
CN116114221A (zh) 2023-05-12
WO2022059206A1 (ja) 2022-03-24
US20230327956A1 (en) 2023-10-12
EP4216494A1 (en) 2023-07-26
JPWO2022059503A1 (ja) 2022-03-24
EP4216494A4 (en) 2024-10-16

Similar Documents

Publication Publication Date Title
WO2022059503A1 (ja) ネットワーク構成推定装置、ネットワーク構成推定方法、及びプログラム
Krügel et al. Decentralized event correlation for intrusion detection
US8479048B2 (en) Root cause analysis method, apparatus, and program for IT apparatuses from which event information is not obtained
Zheng et al. Distributed QoS evaluation for real-world web services
US6415321B1 (en) Domain mapping method and system
US8549650B2 (en) System and method for three-dimensional visualization of vulnerability and asset data
CN101702660B (zh) 异常域名检测方法及系统
EP1352501B1 (en) Method and apparatus for firewall traversal
US7307962B2 (en) System for inference of presence of network infrastructure devices
JP6782842B2 (ja) 通信ネットワーク用の方法及び電子監視ユニット
Herold et al. Anomaly detection for SOME/IP using complex event processing
JP2003258795A (ja) コンピュータ集合体運用方法及びその実施システム並びにその処理プログラム
JP2003258910A (ja) 不正アクセス経路解析システム及び不正アクセス経路解析方法
CN115664833A (zh) 基于局域网安全设备的网络劫持检测方法
US8149723B2 (en) Systems and methods for discovering machines
CN114070830A (zh) 互联网代理单臂部署架构、及互联网代理异地部署系统
JP2006067279A (ja) 侵入検知システム及び通信装置
CN111510431A (zh) 一种泛终端准入管控平台、客户端及管控方法
CN113542192B (zh) 非法网络设备接入检测方法、装置、计算设备及存储介质
Matsubayashi et al. In-Vehicle Network Inspector Utilizing Diagnostic Communications and Web Scraping for Estimating ECU Functions and CAN Topology
JP3729830B2 (ja) 不正ルーティング監視方法、不正ルーティング監視プログラムおよび不正ルーティング監視装置
CN111786811B (zh) 一种便携式现场电子数据取证终端与装置
JPH09247146A (ja) ネットワーク管理システム
WO2020095684A1 (ja) 検査支援装置、検査支援方法、及び検査支援プログラム
CN117896350A (zh) 地址冲突检测方法、装置、设备与计算机可读存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21869190

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022550459

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021869190

Country of ref document: EP

Effective date: 20230418