CN116114221A - 网络设定估计装置、网络设定估计方法及程序 - Google Patents

Abstract

一种对目标装置中的内部网络的设定信息进行估计的网络设定估计装置，具备：诊断通信收发部，使用在所述内部网络上的电子控制装置中以标准方式支持的诊断通信方法，向所述内部网络上的电子控制装置发送消息，并接收对该消息的响应；及设定信息估计部，根据由所述诊断通信收发部获取的所述响应，对所述内部网络的设定信息进行估计。

Description

网络设定估计装置、网络设定估计方法及程序

技术领域

本发明涉及一种对汽车等的目标装置(target device)中的内部网络的设定信息(configuration information)进行估计的技术。

背景技术

近年来，随着车联网社会的到来，对汽车的网络攻击的威胁也越来越大。即，藉由汽车中搭载的互联功能，汽车可经由网络与外部连接，这反而会增加来自外部的网络攻击的威胁。

为此，检测对汽车的网络攻击，确定其攻击路径·原因，并实施对该攻击的事后应对措施非常重要。为了正确识别攻击的路径·原因，与车载网络(NW)的设定(拓扑结构(topology))、NW上的信息处理装置(IVI、TCU等)及电子控制装置(ECU)相关的信息是必需的。

除此之外，车辆设定信息也是实现资产管理、设定(也称配置)的异常检测等多种目的所必需的。

作为对NW的设定等进行估计的现有技术，例如存在非专利文件1公开的技术。非专利文件1公开的技术中，使用SNMP获取目标NW内的各Switch的MAC地址转发表，然后通过分析获得的信息来对目标NW的L2拓扑结构进行估计。

[引证文件]

[非专利文件]

[非专利文件1]Jing Jiang，Xiao Xu，Ning Cao，“Research on improvedphysical topology discovery based on SNMP，”In 2017IEEE InternationalConference on Computational Science and Engineering(CSE)and IEEE Conferenceon Embedded and Ubiquitous Computing(EUC)，pp.219-222，(2017)

发明内容

[要解决的技术问题]

为了获取车载NW的拓扑结构和各ECU的信息，可想到使用非专利文件1公开的基于SNMP的方法。但是，为了使用基于SNMP的方法来获取车载NW的拓扑结构和各ECU的信息，需要进行资源的增强(强化/增加)和SNMP的支持以使得SNMP代理的操作(operation)能够相对于各ECU而执行，故而存在会增加额外成本的问题。

本发明是鉴于上述问题而提出的，其目的在于，提供一种无需对目标装置中的内部网络的设定装置进行资源的增强和新协议的支持即可估计该内部网络的设定信息的技术。

[技术方案]

根据公开的技术，提供一种对目标装置中的内部网络的设定信息进行估计的网络设定估计装置，具备：

诊断通信收发部，使用所述内部网络上的电子控制装置中的以标准方式支持(supported in a standard manner)的诊断通信方法，向所述内部网络上的电子控制装置发送消息(message)，并接收对该消息的响应；及

设定信息估计部，根据由所述诊断通信收发部获得的所述响应，对所述内部网络的设定信息进行估计。

[有益效果]

根据公开的技术，无需对目标装置中的内部网络的设定装置进行资源的增强和新协议的支持即可估计该内部网络的设定信息。

附图说明

[图1]车载设定信息的一例的示意图。

[图2]诊断通信的一例的说明图。

[图3]第1实施方式的设定信息估计系统的配置例的示意图。

[图4]用于说明诊断通信收发部的处理步骤示例的流程图。

[图5]用于说明设定信息估计部的处理步骤示例的流程图。

[图6]第1实施方式的实施例1的系统配置图。

[图7]第1实施方式的实施例2的系统配置图。

[图8]第1实施方式的实施例3的系统配置图。

[图9]第1实施方式的实施例4的系统配置图。

[图10]第1实施方式的实施例5的系统配置图。

[图11]第1实施方式的实施例6的系统配置图。

[图12]车辆设定信息的一例的示意图。

[图13]第2实施方式中作为前提的汽车的网络的示意图。

[图14]基本技术1的目标的说明图。

[图15]基本技术1的应用对象的说明图。

[图16]诊断通信的RTT的说明图。

[图17]基本技术1的估计方法的说明图。

[图18]基本技术1的估计步骤的说明图。

[图19]基本技术1的估计步骤的说明图。

[图20]基本技术1的估计步骤的说明图。

[图21]基本技术2的目标的说明图。

[图22]基本技术2的要点和步骤的说明图。

[图23]与基本技术3相关的现有技术的说明图。

[图24]基本技术3的目标的说明图。

[图25]基本技术3的估计方法的说明图。

[图26]基本技术3的估计方法的说明图。

[图27]第2实施方式的实施例A1的配置图。

[图28]第2实施方式的实施例A1的整体处理的流程图。

[图29]第2实施方式的实施例A1的S1030的处理的流程图。

[图30]第2实施方式的实施例A1的S1031的处理的流程图。

[图31]第2实施方式的实施例A1的表3031的示意图。

[图32]第2实施方式的实施例A1的S1032的处理的流程图。

[图33]第2实施方式的实施例A1的S1033的处理的流程图。

[图34]第2实施方式的实施例A1的表3032的示意图。

[图35]第2实施方式的实施例A1的S1034的处理的流程图。

[图36]第2实施方式的实施例A1的表3033的示意图。

[图37]第2实施方式的实施例A1的S1035的处理的流程图。

[图38]第2实施方式的实施例A1的表3034的示意图。

[图39]第2实施方式的实施例A1的表3035的示意图。

[图40]第2实施方式的实施例A1的表3036的示意图。

[图41]第2实施方式的实施例A1的S1036的处理的流程图。

[图42]第2实施方式的实施例A1的表3037的示意图。

[图43]第2实施方式的实施例A1的S1037的处理的流程图。

[图44]第2实施方式的实施例A1的S1038的处理的流程图。

[图45]第2实施方式的实施例A1的表3038的示意图。

[图46]第2实施方式的实施例A1的S1039的处理的流程图。

[图47]第2实施方式的实施例A1的表3039的示意图。

[图48]第2实施方式的实施例A1的S1040的处理的流程图。

[图49]第2实施方式的实施例A1的S1061的处理的流程图。

[图50]第2实施方式的实施例A1的表3081的示意图。

[图51]第2实施方式的实施例A1的S1091的处理的流程图。

[图52]第2实施方式的实施例A1的S1101的处理的流程图。

[图53]第2实施方式的实施例A1的S1111的处理的流程图。

[图54]第2实施方式的实施例A1的表3111的示意图。

[图55]对第2实施方式的实施例A1的支持度(support degree)之和进行说明时所参照的表。

[图56]第2实施方式的实施例A1的表3112的示意图。

[图57]第2实施方式的实施例A1的表3113的示意图。

[图58]第2实施方式的实施例A1的S1120的处理的流程图。

[图59]第2实施方式的实施例A1的S1121的处理的流程图。

[图60]第2实施方式的实施例A1的追踪路径(trace route)的记录(存储/保存)示例的示意图。

[图61]第2实施方式的实施例A1的S1122的处理的流程图。

[图62]第2实施方式的实施例A1的ECU型号和物理ECU的一对一对应的示意图。

[图63]第2实施方式的实施例A1的网络接口的设定的示意图。

[图64]第2实施方式的实施例A1的ECU信息的分配的示意图。

[图65]第2实施方式的实施例A1的连接关系的示意图。

[图66]第2实施方式的实施例A1的S1130的处理的流程图。

[图67]第2实施方式的实施例A1的S1141的处理的流程图。

[图68]第2实施方式的实施例A1的发送时刻和接收时刻的记录的示意图。

[图69]第2实施方式的实施例A1的表3141的示意图。

[图70]第2实施方式的实施例A1的S1151的处理的流程图。

[图71]第2实施方式的实施例A1的S1152的处理的流程图。

[图72]第2实施方式的实施例A1的发送时刻和接收时刻的记录的示意图。

[图73]第2实施方式的实施例A1的表3151的示意图。

[图74]第2实施方式的实施例A1的S1161的处理的流程图。

[图75]第2实施方式的实施例A1的表3161的示意图。

[图76]第2实施方式的实施例A1的表3162的示意图。

[图77]第2实施方式的实施例A1的S1171的处理的流程图。

[图78]第2实施方式的实施例A1的ECU型号和物理ECU的一对一对应的示意图。

[图79]第2实施方式的实施例A1的向ECU追加请求NW_A-ID的示意图。

[图80]第2实施方式的实施例A1的S1172的处理的流程图。

[图81]第2实施方式的实施例A1的NW_A拓扑结构的估计结果的示意图。

[图82]第2实施方式的实施例A1的将EUC信息追加至NW_A拓扑结构的示意图。

[图83]第2实施方式的实施例A1的GW之间的连接的示意图。

[图84]第2实施方式的实施例A1的S1180的处理的流程图。

[图85]第2实施方式的实施例A1的S1191的处理的流程图。

[图86]第2实施方式的实施例A1的S1192的处理的流程图。

[图87]第2实施方式的实施例A1的ECUReset发送时刻的记录的示意图。

[图88]第2实施方式的实施例A1的S1201的处理的流程图。

[图89]第2实施方式的实施例A1的NW_A-IDS的警报(alert)发出时刻的记录的示意图。

[图90]第2实施方式的实施例A1的S1211的处理的流程图。

[图91]第2实施方式的实施例A1的表3211的示意图。

[图92]第2实施方式的实施例A1的追加后的结果的示意图。

[图93]第2实施方式的实施例A1的表3212的示意图。

[图94]第2实施方式的实施例A2的配置图。

[图95]第2实施方式的实施例A3的配置图。

[图96]第2实施方式的实施例A4的配置图。

[图97]第2实施方式的实施例A5的配置图。

[图98]第2实施方式的实施例A6的配置图。

[图99]第2实施方式的实施例A7的配置图。

[图100]第2实施方式的实施例B1的配置图。

[图101]第2实施方式的实施例B2的配置图。

[图102]第2实施方式的实施例B3的配置图。

[图103]第2实施方式的实施例B4的配置图。

[图104]第2实施方式的实施例C1的配置图。

[图105]第2实施方式的实施例C2的配置图。

[图106]第2实施方式的实施例C3的配置图。

[图107]第2实施方式的实施例C4的配置图。

[图108]装置的硬件配置例的示意图。

具体实施方式

下面参加附图对本发明的实施方式(本实施方式)进行说明。需要说明的是，下文中描述的实施方式仅为一例，可应用本发明的实施方式并不限定于下面所述的实施方式。

下文所述的本实施方式(第1和第2实施方式)中，作为具有设定信息的估计对象即内部网络的目标装置，以汽车为例进行了说明，但是，可应用本发明的技术的目标装置并不限定于汽车。本发明的技术也可应用于与汽车同样具有「通过诊断通信可从网络上的设备获取信息」(注：本文和附图中，「」等同于“”)之特性的目标装置。此外，就第2实施方式中描述的基本技术而言，至少可应用于具有其应用对象所述的条件的对象。

本实施方式中，有时将车载网络(NW)的设定(配置)、与NW上的信息处理装置(IVI、TCU等)相关的信息、及与电子控制装置(ECU)相关的信息统称为「车辆设定信息」。「车辆设定信息」是「内部网络的设定信息」的一例。

需要说明的是，TCU是Telematics Control Unit的缩写，IVI是In-VehicleInfotainment的缩写，ECU是Electronic Control Unit的缩写。

下面的说明(和附图)中，将CAN(注册商标)称为NW_A(网络A)，将Ethernet(注册商标)称为NW_B(网络B)。需要说明的是，CAN(注册商标)是Controller Area Network的缩写。

但是，下面的描述中出现的NW_A也可为CAN(注册商标)之外的网络，同样，NW_B也可为Ethernet(注册商标)之外的网络。例如，NW_A还可为FlexRay(注册商标)、LIN、K-Line等。

本实施方式中，对目标车辆的网络设定信息的估计的实现方法进行说明。目标车辆的网络设定信息例如为如下所述的信息。

·目标网络(车载NW_B和车载NW_A)的拓扑结构

·与连接于网络的装置相关的信息(型号、软件版本等)

·与各装置的功能(＝名称)相关的信息

·各装置进行的正常通信的信息(尤其是各装置发送的正常通信的信息)

下面，对作为本发明的实施方式的第1实施方式和第2实施方式进行说明。第1实施方式中对基本构成和操作进行说明，第2实施方式中对更具体的构成和操作进行说明。另外，也可组合实施第1实施方式中说明的构成和处理以及第2实施方式中说明的构成和处理。

――――――――――第1实施方式――――――――――

(车辆设定信息的示例)

本实施方式中，设定信息估计系统对汽车的车辆设定信息进行估计。图1示出了车辆设定信息的一例。图1的例子中，连接于NW_B的TCU和IVI以星型连接方式与GW(Gateway-ECU)进行了连接。此外，GW上连接有NW_A，连接于NW_A的ECU以总线连接方式与GW下的NW_A进行了连接。另外，图1还示出了各ECU等的信息。图1所示的OBD-II是一种自诊断功能。

下文中，将信息处理装置(IVI、TCU等)和电子控制装置(ECU)统称为「ECU」。第2实施方式中也一样。

(关于诊断通信)

本实施方式中，设定信息估计系统对藉由诊断通信而获得的信息进行收集·分析，由此估计车辆设定信息，该诊断通信在安装于汽车的ECU等的设备中以标准方式被支持。需要说明的是，几乎所有的汽车·ECU上都实装有诊断通信。这里对该诊断通信进行说明。

诊断通信是在进行ECU的故障诊断和重新编程时所使用的通信。此外，藉由诊断通信还可获取ECU型号、软件版本信息等。参见图2对诊断通信的步骤示例进行说明。图2示出了在外部诊断设备(外部诊断机)_A和ECU_B之间进行诊断通信时的例子。

S1中，从外部诊断设备_A向ECU_B发送诊断请求。S2中，ECU_B执行与诊断请求对应的处理。S3中，从ECU_B向外部诊断设备_A发送诊断响应(response(也称回应或应答))。诊断响应中具有处理的结果等。

(系统配置)

图3示出了本实施方式的设定信息估计系统的配置例。如图3所示，本实施方式的设定信息估计系统具有诊断通信收发部100、诊断系统日志DB 200及设定信息估计部300。设定信息估计部300具有ECU存在确认(presence check)部310、拓扑结构估计部320、ECU信息提取部330及输出部340。各功能部的概要如下所述。

诊断通信收发部100按照后述的流程图进行诊断通信的收发(接收和发送)，并将接收到的响应保存至诊断系统日志DB 200。

诊断系统日志DB 200是按照预先确定的形式对由诊断通信收发部100获得的日志进行保存的DB(数据库)。

就设定信息估计部300而言，藉由每个内部块按照后述的流程图进行操作，可利用诊断系统日志DB 200中保存的信息来估计车辆设定信息。需要说明的是，设定信息估计部300的输入也可使用诊断系统日志之外的信息。例如，也可使用与配置相关的公知信息和非诊断系统的日志。

需要说明的是，如后述的实施例1～6所述，诊断通信收发部100、诊断系统日志DB200及设定信息估计部300能以多种方式实装于一个或多个装置。可将具备诊断通信收发部100和设定信息估计部300的装置称为网络设定估计装置。该网络设定估计装置中，诊断通信收发部100和设定信息估计部300可为位于彼此分离的远程位置且经由网络互相进行通信的配置。

此外，也可将具备设定信息估计部300的装置称为网络设定估计装置，该设定信息估计部300利用由诊断通信收发部100获取的响应对设定信息进行估计。

(诊断通信收发部的操作)

接着，对诊断通信收发部100的操作示例进行说明。首先，对后述的流程中出现的UDS、DID及DoIP进行描述。

UDS为Unified Diagnostic Services的缩写，是用于规定(定义)诊断通信中的诊断消息的形式(格式)等的标准规范(ISO14229-1等)的名称。

DID为Data ID的缩写，是UDS的诊断请求(请求消息)中设定的ID，表示诊断服务的对象。例如，作为DID，将设定有用于指定软件的版本号的DID的诊断请求发送给ECU后，ECU可返回设定有软件的版本号的诊断响应(响应消息)。

此外，作为对用于将UDS实装在NW-A上的网络层的规范进行了规定的标准规范，存在被称为DoCAN(Diagnostic communication over Controller Area Network)的ISO15765-2。

DoIP为Diagnostic communication over Internet Protocol的缩写，是对用于将UDS实装在IP上的网络层的规范进行了规定的标准规范(ISO 13400-1和ISO 13400-2)的名称。

DoIP中，例如，如图1所示，可进行如下配置，即，仅是特别需要进行高速数据转发的ECU与作为诊断功能(测试器)的网关的ECU在NW_B上进行通信，其它ECU则经由NW_A等的车载网络与网关ECU连接，并经由该网关ECU进行诊断。

本实施方式的诊断通信收发部100和ECU至少进行依据上述一般标准规范的诊断通信。

参见图4的流程图对诊断通信收发部100的操作示例进行说明。需要说明的是，在参见图4所描述的操作示例中进行收发的消息的内容和顺序仅为一例，本发明并不限定于此。

S101中，诊断通信收发部100向NW_B上连接的ECU广播(broadcast)DoIP的VehicleIdentification Request，并接收来自每个ECU的响应。Vehicle Identification Request是用于向与NW_B上连接的ECU进行地址信息的请求的消息。

S102中，诊断通信收发部100向NW_A上连接的各ECU发送UDS的testerPresent，并接收响应。testerPresent是用于对NW_A上连接的ECU的存在和NW_A-ID(即，CAN-ID)进行确认的消息。

S103中，诊断通信收发部100向车载NW_B上连接的各ECU发送DoIP的EntityStatus Request，并接收响应。Entity Status Request是用于向ECU进行节点类型(例：网关)等的请求的消息。

S104中，诊断通信收发部100向与车载NW_B和车载NW_A连接的各ECU发送设定有作为DID的一个以上的值的UDS的ReadDataByIdentifier，并接收响应。ReadDataByIdentifier是用于向ECU进行由DID指定的数据的请求的消息。

S104中使用的DID例如为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。

(设定信息估计部的操作示例)

上述S101～S104中对发送给ECU的请求所接收的响应保存于诊断系统日志DB200。设定信息估计部300通过从诊断系统日志DB 200读取数据进行目标装置的内部网络的设定信息的估计。

下面，参见图5的流程图对设定信息估计部300所执行的估计和获知(把握)的操作的例子进行说明。需要说明的是，这里描述的估计·获知的顺序和内容仅为一例，本发明并不限定于这里说明的例子。

<S201>

S201中，ECU存在确认部310进行ECU的存在确认。具体而言，如下所述。

ECU存在确认部310根据对向NW_B上连接的ECU所广播的DoIP的VehicleIdentification Request的响应，对NW_B上连接的ECU的存在和该ECU的地址信息进行确认。换言之，如果接收到了作为对Vehicle Identification Request的响应的地址信息，则可估计为NW_B上存在该地址信息的ECU。

此外，ECU存在确认部310还根据对向NW_A上连接的各ECU所发送的UDS的testerPresent的响应，对NW_A上连接的ECU的存在和NW_A-ID进行确认。换言之，如果接收到了作为对testerPresent的响应的NW_A-ID，则可估计为NW_A上存在该NW_A-ID的ECU。

另外，ECU存在确认部310也可根据对DoIP的Entity Status Request的响应来对Gateway-ECU的存在和其地址信息进行确认。换言之，在接收到了作为对Entity StatusRequest的响应的、节点类型为Gateway的响应的情况下，可估计为存在Gateway-ECU。

<S202>

S202中，拓扑结构估计部320进行目标装置(这里为汽车)的内部网络的拓扑结构的估计。具体而言，如下所述。

拓扑结构估计部320估计具有NW_B上连接的ECU以星型连接方式与一个Switch连接的配置。

例如，拓扑结构估计部320藉由S201的确认结果可确认为存在一个Gateway-ECU(也可作为Switch而发挥功能)，并且NW_B上存在ECU，据此可估计为内部网络具有NW_B上连接的ECU以星型连接方式与一个Switch连接的配置。这样的估计例如可根据预先规定的规则来进行。

此外，拓扑结构估计部320估计为Gateway-ECU上连接有NW_A。例如，拓扑结构估计部320藉由S201的确认结果可确认为存在Gateway-ECU，并且存在NW_A上连接的ECU，据此可估计为Gateway-ECU上连接有NW_A。这样的估计例如可根据预先规定的规则来进行。

此外，拓扑结构估计部320还估计为NW_A上连接的ECU以总线连接方式与Gateway-ECU下的NW_A进行了连接。例如，拓扑结构估计部320根据Gateway-ECU上连接有NW_A这样的估计结果和ECU连接至NW_A的连接方法的公知信息(例：以总线连接方式进行连接)，可估计为NW_A上连接的ECU以总线连接方式与Gateway-ECU下的NW_A进行了连接。这样的估计例如可根据预先规定的规则来进行。

<S203>

S203中，ECU信息提取部330进行ECU信息的提取。具体而言，如下所述。

ECU信息提取部330根据对UDS的ReadDataByIdentifier的响应，获知各ECU中的ECU信息(VIN、型号、软件版本等)，该UDS的ReadDataByIdentifier的DID分别被设定为0xF181、0xF183、0xF184、0xF188、0xF189、0xF18A、0xF194、0xF195、0xF19F、0xF18B、0xF18C、0xF184、0xF191、0xF192、0xF193、0xF19F(这些DID仅为一例)。

<S204>

S204中，输出部340输出由S201～S203获得的信息。例如，输出部340根据由S201～S203获得的信息生成如图1所示的图形图像(graphical image)，并对该画像进行输出(显示)。此外，输出部340也可采用列表和/或自然语言的形式来输出由S201～S203获得的信息。另外，还可输出自然语言的声音。

图3所示的本实施方式的设定信息估计系统可具有多种实现(实装)方式。下面对作为本实施方式的实现方法的例子的实施例1～实施例6进行说明。

(实施例1)

图6是实施例1的设定信息估计系统的配置图。如图6所示，实施例1中，具有设定信息估计系统的所有功能、即、诊断通信收发部100、诊断系统日志DB200及设定信息估计部300的外部装置与汽车400连接。

就将外部装置连接于汽车400的连接方法而言，可为将该外部装置物理连接至汽车400的方法，也可为在诸如云(cloud)的网络上实现该外部装置并从该网络上的该外部装置远程连接至汽车400的连接方法。

(实施例2)

图7是实施例2的设定信息估计系统的配置图。实施例2中，具备诊断通信收发部100的诊断通信收发装置以及具备诊断系统日志DB 200和设定信息估计部300的设定信息估计装置这两个装置与汽车400连接。

图7的例子中示出了如下配置例，即，诊断通信收发装置与汽车400物理连接，设定信息估计装置配置在云上并经由网络与诊断通信收发装置连接。需要说明的是，这样的连接方式仅为一例，诊断通信收发装置和设定信息估计装置的配置场所并不限定于特定的场所。

(实施例3)

图8是实施例3的设定信息估计系统的配置图。实施例3是在实施例2的配置中的诊断通信收发装置内具有诊断系统日志DB 200的例子。

需要说明的是，实施例2和实施例3中，诊断系统日志DB 200可配置在诊断通信收发装置或设定信息估计装置的外部而不是这些装置的内部。

(实施例4)

图9是实施例4的设定信息估计系统的配置图。实施例4中，用于实现从诊断通信收发部100至设定信息估计部300的所有功能的处理装置配置在车载NW上。即，如图9所示，汽车400的内部具备具有诊断通信收发部100、诊断系统日志DB 200及设定信息估计部300的处理装置。

需要说明的是，就汽车400所具备的上述处理装置而言，可采用物理连接的方式配置在车载NW内，也可在任意的ECU上来进行实现。换言之，一个或多个ECU可具有诊断通信收发部100、诊断系统日志DB 200及设定信息估计部300。

(实施例5)

图10是实施例5的设定信息估计系统的配置图。实施例5中，汽车400内部具备在车载NW上执行处理的处理装置，该外部装置与汽车400连接。如图10所示，处理装置具备诊断通信收发部100，外部装置具备诊断系统日志DB 200和设定信息估计部300。

需要说明的是，就处理装置而言，可采用物理连接方式将该装置配置在车载NW内，也可在任意的ECU上来进行实现。此外，就外部装置的连接方法而言，可为将该装置物理连接至汽车400的方法，也可为将外部装置作为云等的网络上的装置而存在并使其远程连接至汽车400的方法。

(实施例6)

图11是实施例6的设定信息估计系统的配置图。实施例6是在实施例5的构成中的处理装置内具有诊断系统日志DB 200的例子。

需要说明的是，实施例5和实施例6中，可将诊断系统日志DB 200配置在处理装置或外部装置的外部而不是这些装置的内部。

――――――――――第2实施方式――――――――――

接着，对第2实施方式进行说明。

(车辆设定信息的示例)

第2实施方式中也是由设定信息估计系统对汽车的车辆设定信息进行估计。图12示出了车辆设定信息的一例。图12中的车载网络的拓扑结构、ECU信息(两个表)及正常通信(右侧的表的由粗线围成的框)这三者是构成车辆设定信息的信息。需要说明的是，这些信息是后述的基本技术1～3的范围内的信息。

第2实施方式中也与第1实施方式同样地使用诊断通信。诊断通信与参见图2所描述的相同。

(关于汽车的网络)

第2实施方式中作为前提的汽车的网络示于图13。如图13所示，本网络中，一个OBD-II端口与NW_A总线和车载NW-B这两者连接。从一个OBD-II端口可进行下面的(1)和(2)的诊断通信。

(1)可仅使用NW_A(不经由SW)进行与NW_A上连接的ECU的诊断通信。此外还可为，从OBD-II至GW使用车载NW_B，GW之后使用NW_A来进行与NW_A上连接的ECU的诊断通信。

(2)对于车载NW_B上连接的ECU，仅使用车载NW_B(不经由SW)与其进行诊断通信。

(关于基本技术)

这里，对第2实施方式的基本技术进行说明。第2实施方式的基本技术为下述的(1)～(3)。需要说明的是，(4)和(5)中将第1实施方式所述的技术表示为基本技术4和基本技术5。

(1)对NW_A的拓扑结构进行估计的技术(基本技术1)

(2)对由NW_A上连接的ECU发送的正常(非诊断)NW_A-ID(000～6FF)进行确定的技术(基本技术2)

(3)对各ECU的功能(＝名称)进行估计的技术(基本技术3)

(4)获取各ECU的ECU信息的技术(基本技术4)

(5)对NW_B的拓扑结构进行估计的技术(基本技术5)

下面，分别对第2实施方式的基本技术1～3进行描述。

(基本技术1)

<与基本技术1相关的现有技术和问题>

与基本技术1相关的现有技术为上述非专利文件1公开的技术。如上所述，非专利文件1公开的技术中，使用SNMP获取目标NW内的各Switch的MAC地址转发表，并分析获得的信息，由此对目标NW的L2拓扑结构进行估计。

但是，为了采用非专利文件1那样的基于SNMP的方法来获取NW_A总线的拓扑结构，各ECU需要进行为了使SNMP代理的操作可执行的资源增强和SNMP的支持，这样就会增加额外成本。

<基本技术1的要点和效果>

基本技术1中也使用大多数汽车中能以标准方式使用的诊断通信的收发。具体而言，使用当使特定总线的占有率强制增加(拥塞)时的诊断通信的RTT来对NW_A总线的拓扑结构进行估计。稍后将描述本技术的细节。

诊断通信协议是各ECU中以标准方式支持的协议，为此，根据本技术，无需花费资源的增强和新协议的支持这样的额外的成本即可对NW_A总线的拓扑结构进行估计。

<基本技术1的目标和应用对象>

基本技术1中，以对与相同NW_A总线相连的ECU进行确定为目标。例如，在图14所示的配置的情况下，对如下所述的信息进行估计。

·ECU-A和ECU-B为与相同总线连接

·ECU-A和ECU-C为与不同总线连接

·ECU-B和ECU-C为与不同总线连接

基本技术1的应用对象为存在具有域架构(domain architecture)的总线的对象，例如，如图15所示，为GW下存在多个总线的对象。GW可将诊断通信路由到适当的总线。例如，具有与ECU-A对应的NW_A-ID的诊断通信可仅从GW发送至ECU-A所连接的总线。

<关于基本技术1的估计方法的要点>

如上所述，基本技术1中，使用当使特定总线的占有率强制增加(拥塞)时的诊断通信的RTT(Round Trip Time)来对NW_A的拓扑结构进行估计。

参见图16对诊断通信的RTT的定义进行说明。需要说明的是，图16示出了作为一例的从PC向ECU-A进行诊断通信的情形的例子。诊断通信的RTT是指从PC向一个ECU开始发送诊断请求(S1)时至该PC接收完来自该ECU的诊断响应(S2)时的时间。

这里，如图17所示，假设仅使总线1发生拥塞。在仅使总线1发生拥塞的情况下，与没有发生拥塞的情况相比，与连接于总线1的ECU之间的诊断通信的RTT较大。另一方面，与没有发生拥塞的情况相比，与连接于总线2的ECU之间的诊断通信的RTT没有变化。基本技术1中，可利用这样的现象对拓扑结构进行估计。

<基本技术1的估计步骤的概要>

参见图18～图20对基本技术1的估计步骤的概要进行说明。首先，如图18所示，向ECU-B和ECU-C发送数次诊断请求，藉此查看(调查)ECU-B和ECU-C各自的RTT的平均值。图18(及图19、图20)的左下方示出了ECU-B和ECU-C各自的RTT的平均值的图像。

接着，如图19所示，频繁(高频度地)向ECU-A发送诊断请求，由此提高(增加)ECU-A和ECU-B所连接的总线的占有率。图19的例子中示出了该总线的占有率为99％。

接着，如图20所示，在ECU-A所连接的总线发生了拥塞的状况下，向ECU-B和ECU-C发送数次诊断请求，据此对ECU-B和ECU-C的RTT的平均值进行调查(检查)。

如图20的左下方所示，如果RTT的统计值的平均值与非拥塞时相比增加了(左下图)，则可判定为该ECU和ECU-A与相同总线连接。图20的例子中，可判定为「ECU-A和ECU-B与相同总线连接」。

(基本技术2)

接着，对基本技术2进行说明。

<与基本技术2相关的现有技术和问题>

作为与基本技术2相关的现有技术，存在「Sekar Kulandaivel，Tushar Goyal，Arnav Kumar Agrawal，and Vyas Sekar，“CANvas：Fast and Inexpensive AutomotiveNetwork Mapping，”In the Proceedings of the 28th USENIX Security Symposium，pp.389-405，(2019).」。

该现有技术中，通过利用“ECU发送的消息的冲突发生了一定次数的异常后则使该ECU的消息发送停止(总线断开(off))”之NW_A的特性，对一个ECU发送的NW_A消息的所有NW_A-ID进行确定。

基于该现有技术的方法的具体示例如下所述。

在NW_A总线上的某ECU-A发送NW_A-ID＝0x300的NW_A消息的同时，从与NW_A总线连接的估计设备发送NW_A-ID＝0x300的NW_A消息。

据此，使NW_A-ID＝0x300的NW_A消息发生冲突。通过重复这种冲突，ECU-A可从总线断开(总线下线)。

ECU-A从总线断开后，包括NW_A-ID＝0x300在内的从ECU-A发送的所有NW_A-ID的NW_A消息(例如，其它的0x301、0x302)也都停止。

通过由估计设备对此时不再发送的NW_A消息的NW_A-ID进行检查，可对ECU-A发送的NW_A消息的NW_A-ID进行确定。就该示例而言，确定为「ECU-A发送了NW_A-ID＝0x300、0x301、0x302的NW_A消息」。

但是，上述现有技术中存在如下所述的问题。

近年来，用于访问车载NW_A总线而设置的OBD-II端口在大多数汽车中被设定(配置)为仅可进行诊断通信的收发。另一方面，上述现有技术中，为了使NW_A消息发生冲突，需要能将非诊断通信发送至车载NW_A总线。为此，采用“使用OBD-II端口”这样的一般的方式难以实施上述现有技术。

<基本技术2的要点和效果>

基本技术2中，利用诊断通信打乱目标ECU的NW_A消息的发送周期，并由NW_A-IDS对该NW_A消息的发送周期的紊乱进行检测。然后，将该检测结果与目标ECU的信息相关联，由此对该ECU发送的NW_A消息的NW_A-ID进行确定。

根据本技术，能将近年来的大多数汽车作为目标，并可采用“使用OBD-II端口”这样的方式来对「ECU发送的NW_A消息的NW_A-ID」进行确定。

<基本技术2的目标和应用对象>

基本技术2中，例如，如图21所示，将NW_A上连接的ECU所发送的正常NW_A-ID(000～6FF)与诊断用NW_A-ID(700～7FF)相关联，引申而言，将与ECU信息相关联作为目标。

基本技术2中，以目标NW上存在IDS且其对正常消息进行监视为前提。在正常消息的发送时刻的间隔比设计值短/长的情况和/或有效载荷(payload)发生异常变化的情况下，该IDS发出警报。IDS的警报包含被检测为异常的消息的信息(汽车的例子中为NW_A-ID)。此外，车辆设定估计装置还可通过任意的方式来获取IDS的警报。

<关于基本技术2的估计方法的要点和步骤>

参见图22对作为基本技术3的要点的处理步骤进行说明。

(1)利用ECUReset(例如，藉由NW_A-ID＝7E0)打乱目标ECU所发送的正常NW_A-ID(例如，NW_A-ID＝300)的消息发送的周期性和/或有效载荷变化。

(2)使NW_A-IDS发出警报。例如，警报中包含有NW_A-ID＝300。

(3)之后，判定为「该警报中包含的NW_A-ID为目标ECU所发送的正常NW_A-ID」。

(基本技术3)

接着，对基本技术3进行说明。

<与基本技术3相关的现有技术和问题>

作为与基本技术3相关的现有技术，存在「X.Feng，et al：Acquisitional Rule-based Engine for Discovering Internet-of-Things Dvices.USENIX(2018)」。该现有技术中，通过使用从IoT设备收集的响应信息和Web爬取·抓取(crawling&scraping)技术，对IoT设备的信息(设备类别·供应商·型号)进行特定。

更具体而言，该现有技术中，对从某IoT设备的响应中提取出的关键字(keyword)A，可获得多个Web爬取·抓取结果B。汽车的例子中，假设可从某ECU获取「12345-67890」这样的ECU型号。此时，A＝12345-67890。另外，使用了A的爬取·抓取结果如图23所示。

该现有技术中，以该多个结果B为目标，计算下述置信度

之后，将置信度最高的结果提取为一个结果。图23的例子中，A＝12345-67890，按照

67可提取出B＝Engine Module。

上述现有技术中存在如下所述的问题。

如果将整个ECU型号作为关键字来进行爬取·抓取，则检索结果不存在所导致的无法估计ECU的功能的情形较多。

此外，当如上述现有技术那样提取置信度最高的结果时，也存在信息量较少的结果会被选中的情况。例如，在图23的情况下，「Hybrid Engine Module(混合引擎模块)」的信息量较多，故希望提取该结果。但是，在上述现有技术的情况下，当获得了图23那样的抓取结果(表)时，却选中了出现次数较多的「EngineModule(引擎模块)」。

<基本技术3的要点和效果>

作为基本技术3的要点，具有下述的要点1和要点2。

要点1为，还根据ECU型号的命名规则利用仅使用了表示功能的位的抓取结果。要点2为，提取各Web爬取·抓取结果中包含的单词的支持度之和为最大的结果。

根据本技术，可避免因没有检索结果而导致的无法估计ECU的功能(名称)的情形。此外，还可输出可靠性较高且信息量较多的结果。

<基本技术3的目标和应用对象>

基本技术3中，以估计各ECU(包括NW_B连接)的功能(名称)为目标。例如，图24所示的例子中，对「ECU-X为IVI」、「ECU-Y为TCU」、「ECU-A为引擎ECU」等进行估计。此外，基本技术3中，还可获取用于唯一确定设备的信息，就汽车的例子而言，例如可获取「ECU型号」。

<关于基本技术3的估计方法的要点和步骤>

首先，对基本技术3的估计方法的概要进行说明。基本技术3中，使用藉由诊断通信而获取的各ECU型号和Web爬取·抓取技术来对功能(名称)进行确定。图25中示出了其概要。下面对上述要点1和要点2进行详细说明。

<要点1>

要点1中，还根据ECU型号的命名规则利用仅使用了与ECU型号的功能相关的位的Web爬取·抓取结果。

ECU型号大多采用表示功能信息的位和表示车型年份的位相结合的结构。当使表示功能信息的位为○，并使表示车型年份的位为△时，例如存在如下所述的ECU型号结构。

·○○○○○-△△△△△

·△△△-○○○○○○-△

如要点1那样，通过仅使用与功能相关的位可减少没有检索结果的情形的理由如下所述。

以「ECU型号的所有位都一致」之条件进行检索是指，对「搭载于所指定的车型年份的车」且「所指定的功能」的ECU进行检索。另一方面，以「ECU型号的仅表示功能的位一致」之条件进行检索是指，对「所指定的功能」的ECU进行检索。换言之，由于可较少检索时的限定条件，故可减少检索结果不存在的情形。

与功能相关的位的提取方法并不限定于特定的提取方法，但是，例如可使用下述提取方法1～3中的任一种。

提取方法1)

提取方法1中，根据所公开的「ECU型号的命名规则的信息」来确定与功能相关的位。例如，在汽车公式的主页等中公开了命名规则的情况下，可根据该公开信息对与功能相关的位进行确定。

提取方法2)

提取方法2中，仅对与某一个功能相关的ECU型号进行提取·分析，并根据该分析结果来确定与功能相关的位。例如，如果仅对与引擎ECU相关的ECU型号进行提取·分析，则存在无论在哪个ECU型号中其值都不改变的位。可将该位确定为与功能相关的位。

提取方法3)

提取方法3中，对搭载于某台汽车的ECU的ECU型号进行提取·分析，并根据该分析结果来确定与功能相关的位。例如，如果对搭载在一台汽车上的ECU的ECU型号进行提取·分析，则存在不管在哪个ECU型号中其值都不变的位。由于该位可被认为是表示车辆种类而不是表示功能的位，所以可将除了该位之外的位确定为与功能相关的位。

<要点2>

基本技术3的要点2中，对各Web爬取·抓取结果中包含的单词的支持度之和为最大的结果进行提取。具体而言，如下所述。

当对ECU型号为「12345-67890」的ECU的功能(名称)进行估计时，假设获得了图26所示的Web爬取·抓取结果。对图26中包含的单词X，计算下述支持度sup(X)。

sup(X)＝(包含X的结果的数量)/(所有的Web爬取·抓取结果的数量)

之后，按照每行来计算各行中包含的单词的支持度之和，并将该和为最大的结果提取为一个结果。图26的例子中，Hybrid Engine Module(混合引擎模块)被进行了提取。这里，sup(Engine)＝1，sup(Module)＝1，sup(Hybrid)＝0.3，和＝2.3。

(实施例)

下面，对作为实施例的第2实施方式的具体的装置配置和操作进行说明。各实施例的概要如下所述。

A.基本技术的组合的观点下的实施例的列举

·实施例A1：最基本的基本技术的组合下的实施例(处理流程的详细说明)

·实施例A2～A4：单独使用各基本技术的实施例

·实施例A5～A7：对基本技术进行部分组合的实施例

B.功能的物理部署的观点下的实施例的列举

·实施例B1：将本发明的功能部署在车载NW上的实施例

·实施例B2：将本发明的功能直接连接至OBD-II端口的实施例

·实施例B3：从充电端口执行本发明的功能的实施例

需要说明的是，就B1～B3而言，也可抽出后述的车载NW1和消息收发部23之外的部分，并将其部署在云(cloud)上。

·实施例B4：通过部署在外部网络上的本发明的功能来进行估计的实施例C.目的之观点下的实施例的列举

·实施例C1：用于在SOC(Security Operation Center)等进行安全分析的实施例

·实施例C2：用于资产管理的实施例

·实施例C3：用于执行异常检测的实施例

·实施例C4：用于安全诊断的实施例

需要说明的是，实际实现时可对上述A和B的实施例进行组合。例如，可通过实施例B1的功能部署等实现实施例A1，然后，再将其使用于C中记载的目的。下面对各实施例进行说明。

(实施例A1)

实施例A1是核心技术的最基本的组合下的实施例。这里，作为一例，假设了实施例B2的物理部署，并据此来进行描述。

<装置配置(框图)>

图27表示实施例A1的设定信息估计系统的配置图。如图27所示，设定信息估计系统具备设定要素估计部2和设定信息估计结果DB 22。设定要素估计部2可被称为车辆设定估计装置或网络设定估计装置。设定信息估计系统可被称为设定信息估计装置。设定要素估计部2与车载NW1和Web网站7(Web服务器)连接，并可与它们进行通信。

设定要素估计部2具备ECU基本信息获取部3、ECU功能估计部4、NW_B拓扑结构估计部12、NW_A总线拓扑结构估计部13、正常NW_A通信估计部18、消息收发部23及设定信息获取·登记部24。

ECU功能估计部4具备Web检索部6、检索结果DB 8、完全一致提取部9、特定部分一致提取部10及估计部11。需要说明的是，也可将「完全一致提取部9、特定部分一致提取部10及估计部11」统称为估计部。

NW_A总线拓扑结构估计部13具备基本RTT计算部14、拥塞RTT计算部15、RTT比较部16及估计部17。需要说明的是，也可将「RTT比较部16和估计部17」统称为估计部。

正常(通常)NW_A通信估计部18具备再启动命令发送部19、车辆警报接收部20及估计部21。

下面参见流程图对装置操作进行说明。下文的描述中，需要说明的是，经由消息收发部23来进行与车载NW1和车载ECU之间消息的收发。

<整体处理的流程>

参见图28对设定信息估计系统的整体处理的流程进行说明。需要说明的是，图28所示的处理的顺序仅为一例。

S1030中，ECU基本信息获取部3获取ECU基本信息。S1040中，ECU功能估计部4对ECU功能进行估计。S1120中，NW_B拓扑结构估计部12对NW_B的拓扑结构进行估计。S1130中，NW_A总线拓扑结构估计部13对NW_A总线拓扑结构进行估计。S1180中，正常NW_A通信估计部18进行正常NW_A通信的估计。

下面对各步骤的处理内容进行详细说明。

<S1030>

参见图29对S1030进行说明。

S1030-1中，将车辆设定估计装置连接至车载NW1的OBD-II端口(NW_B)。

S1030-2中，ECU基本信息获取部3执行S1031。S1030-3中，ECU基本信息获取部3执行S1032。S1032中也执行S1033和S1034。

S1030-4中，ECU基本信息获取部3执行S1035。S1030-5中，ECU基本信息获取部3将车辆设定估计装置从OBD-II端口(NW_B)切断，并将其连接至OBD-II端口(NW_A)。

S1030-6中，ECU基本信息获取部3执行S1036。S1030-7中，ECU基本信息获取部3执行S1037。S1037中也执行S1038。S1030-8中，ECU基本信息获取部3执行S1039。

<S1031>

接着，参见图30对S1031的处理进行说明。

S1031-1中，ECU基本信息获取部3按照DoIP的规定藉由AutoIP或DHCP来获取车载NW1上的本地(local)IP地址。

S1031―2中，在ECU基本信息获取部3按照DoIP的规定接收到车载NW1上的各ECU所广播的Vehicle Announcement的情况下，进入S1031-5，在没有接收到的情况下，进入S1031-3。

S1031-3中，ECU基本信息获取部3在车载NW1上进行Vehicle IdentificationRequest(由DoIP规定)的广播。

S1031-4中，车载NW1上的各ECU按照DoIP的规定对Vehicle IdentificationRequest返回Vehicle Identification Response。ECU基本信息获取部3接收该VehicleIdentification Response。

S1031-5中，ECU基本信息获取部3将接收到的Vehicle Announcement和/或Vehicle Identification Response中包含的发送源IP地址等的信息保存至存储器等的存储单元。存储的信息如图31(表3031)所示。需要说明的是，存储的信息并不限定于表3031。

<S1032>

接着，参见图32对S1032的处理进行说明。S1032-1中，ECU基本信息获取部3对下述变量进行声明(宣告)。

·上一步骤(S1031)中存储的表3031的IP地址的列表“IP＝[192.168.10.1，192.168.10.2，192.168.10.3]”

·IP列表的长度“Length(IP)”(本例的情况下，Length(IP)＝3)

·“DID＝[0xF18C，0xF190，0xF191，0xF194，0xF195，0xF19F]”

·DID的长度“Length(DID)”(本例的情况下，Length(DID)＝6)

·i＝0

需要说明的是，变量名可与上述不同。此外，也可采用IP地址之外的值来对IP的内容进行统一。DID中还可追加上述之外的值。

S1032―2中，ECU基本信息获取部3对是否为i<Length(IP)进行判断，如果为Yes(是)，则进入S1032-3，如果为No(否)，则结束处理。

S1032-3中，ECU基本信息获取部3执行S1033的处理。S1032-4中，ECU基本信息获取部3执行S1034的处理。S1032―5中，使i＝i+1，然后返回S1032-2。

<S1033>

接着，参见图33对S1033的处理进行说明。S1033-1中，ECU基本信息获取部3向车载NW1上的IP[i]发送DoIP Entity Status Request。

S1033-2中，车载NW1上的具有IP[i]的ECU按照DoIP的规定对DoIP Entity StatusRequest返回DoIP Entity Status Response。ECU基本信息获取部3接收该DoIP EntityStatus Response。

S1033-3中，ECU基本信息获取部3将接收到的DoIP Entity Status Response中包含的「Node type」和IP[i]保存至存储单元。存储的信息的例子如图34(表3032)所示。

<S1034>

接着，参见图35对S1034的处理进行说明。S1034-1中，ECU基本信息获取部3对变量j＝0进行声明。需要说明的是，变量名可与j不同。S1034-2中，ECU基本信息获取部3对是否满足j<Length(DID)进行判断，如果为Yes，则进入S1034-3，如果为No，则结束处理。

S1034-3中，ECU基本信息获取部3向IP[i]发送DID中设定有DID[j]的readDataByIdentifier(由UDS规定)，并接收响应。S1034-4中，ECU基本信息获取部3将接收到的响应的dataRecord与IP[i]和DID[j]一起保存至存储单元。存储的信息的例子如图36(表3033)所示。S1034-5中，ECU基本信息获取部3使j＝j+1，然后返回S1034-2。

<S1035>

接着，参见图37对S1035进行说明。S1035-1中，ECU基本信息获取部3根据UDS的规定将图36(表3033)的DID变更为「说明」，并对dataRecord进行ASCII(16进制)→文字列(即，ASCII(16进制)至文字列)的转换。图36(表3033)的变更·转换后的结果如图38(表3034)所示。需要说明的是，说明的内容和dataRecord的转换方法并不限定于此。

S1035-2中，ECU基本信息获取部3将「IP地址」和「ECU型号」作为复合主键对图38(表3034)的数据进行整理。整理后的结果如图39(表3035)所示。需要说明的是，汇总的方法并不限定于此。

S1035-3中，ECU基本信息获取部3将「IP地址」作为键对图39(表3035)、图31(表3031)及图34(表3032)进行结合。其结果如图40(表3036)所示。

S1035-4中，ECU基本信息获取部3将图40(表3036)的结合结果经由设定信息获取·登记部24保存至设定信息估计结果DB 22。

<S1036>

接下来，参见图41对S1036进行说明。S1036-1中，ECU基本信息获取部3按照DoCAN和UDS的规定向所有诊断用NW_A-ID＝0x700～0x7FF和诊断用的扩张NW_A-ID(下面，将这些简称为「NW_A-ID」)依次发送TesterPresent请求。

S1036-2中，如果车载网络上发生了对上一步骤中发送TesterPresent请求时的响应，则ECU基本信息获取部3将自身发送的NW_A-ID(请求NW_A-ID)等保存至存储单元。例如，如果在发送设定有NW_A-ID＝700的TesterPresent时有响应，则对NW_A-ID＝700和响应中设定的NW_A-ID(响应NW_A-ID)进行存储。其结果如图42(表3037)所示。

<S1037>

接着，参见图43对S1037进行说明。S1037-1中，ECU基本信息获取部3对下述变量进行声明。

·上一步骤中存储的图42(表3037)的请求NW_A-ID列表“NW_A-ID＝[0x700，0x724，0x750，0x7E0，0x7E1]”

·列表的长度“Length(NW_A-ID)”(本例的情况下，Length(NW_A-ID)＝5)

·“DID＝[0xF18C，0xF190，0xF191，0xF194，0xF195，0xF19F]”

·DID的长度“Length(DID)”(本例的情况下，Length(DID)＝6)

·i＝0

需要说明的是，变量名可与上述不同。此外，也可藉由NW_A-ID之外的值对NW_A-ID的内容进行统一。DID中还可追加上述之外的值。

S1037-2中，对是否满足i<Length(NW_A-ID)进行确认，如果为Yes，则进入S1037-3，如果为No，则结束处理。S1037―3中，ECU基本信息获取部3执行S1038。S1037-4中，使i＝i+1，然后返回S1037-2。

<S1038>

接下来，参见图44对S1038进行说明。S1038-1中，ECU基本信息获取部3对变量j＝0进行声明。需要说明的是，变量名可为j之外的变量名。

S1038-2中，ECU基本信息获取部3对是否满足j<Length(DID)进行判断。如果为Yes，则进入S1038-3，如果为No，则结束处理。

S1038―3中，ECU基本信息获取部3向NW_A-ID[i]发送DID中设定有DID[j]的readDataByIdentifier(由UDS规定)，并接收响应。

S1038―4中，ECU基本信息获取部3将接收到的响应的dataRecord与NW_A-ID[i](请求NW_A-ID)及响应NW_A-ID、DID[j]一起保存至存储单元。存储的信息的例子示于图45(表3038)。S1038-5中，使j＝j+1，然后返回S1038-2。

<S1039>

接着，参见图46对S1039进行说明。S1039-1中，ECU基本信息获取部3根据UDS的规定将图45(表3038)的DID变更为「说明」，并对dataRecord进行ASCII(16进制)→文字列的转换。需要说明的是，说明的内容和dataRecord的转换方法并不限定于此。

S1039-2中，ECU基本信息获取部3将「NW_A-ID」和「ECU型号」作为复合主键对前一步骤的数据进行整理。整理后的结果如图47(表3039)所示。需要说明的是，汇总方法并不限定于此。

S1039-3中，ECU基本信息获取部3将图47(表3039)的整理结果经由设定信息获取·登记部24传递给设定信息估计结果DB 22。

<S1040>

接着，参见图48对S1040进行说明。S1040-1中，ECU功能估计部4对下述变量进行声明。

·经由设定信息获取·登记部24从设定信息估计结果DB 22获得的与图40(表3036)和图47(表3039)不重复的ECU型号的列表

·“PN＝[11111-56789，22222-56789，33333-56789，44444-56789，55555-56789，66666-56789，77777-56789，88888-56789]”

·PN列表的长度“Length(PN)”(本例的情况下，Length(PN)＝8)

·i＝0

需要说明的是，变量名可为上述之外的变量名。此外，也可藉由IP地址之外的值对IP的内容进行统一。

S1040-2中，ECU功能估计部4对是否满足i<Length(PN)进行判断，如果为Yes，则进入S1040-3，如果为No，则结束处理。S1040-3中，对PN[i]执行S1061，S1040-4中，对PN[i]执行S1091，S1040-5中，对PN[i]执行S1101，S1040-6中，对PN[i]执行S1111。S1040-7中，使i＝i+1，然后返回S1040-2。

<S1061>

接着，参见图49对S1061进行说明。S1061-1中，Web检索部6将从设定信息估计结果DB 22获得的ECU型号作为检索词对Web网页进行爬取(crawling)。此时，就爬取的Web网页而言，适合基于ECU的型号对ECU的功能(＝名称)进行检索的Web网站为优选。此外，作为检索词，可使用整个ECU型号和ECU型号中的与功能相关的位这两个种类。

需要说明的是，就ECU型号中的与功能相关的位而言，可采用上述基本技术3的要点1的说明中描述的方法等来进行确定。需要说明的是，用于确定的方法并不限定于此。

S1061-2中，Web检索部6根据上一步骤中爬取到的Web网页来抓取ECU型号和与该ECU型号对应的功能的配对信息。

S1061-3中，Web检索部6将配对信息保存在过去的检索结果(即，历史检索结果)DB8中。需要说明的是，过去的检索结果DB 8例如可具有图50(表3081)那样的DB结构。

<S1091>

接下来，参见图51对S1091进行说明。S1091中，完全一致提取部9从检索结果DB 8获取ECU型号完全一致的配对信息。

<S1101>

接着，参见图52对S1101进行说明。S1101中，特定部分一致提取部10从检索结果DB8获取ECU型号中的与功能相关的位一致的配对信息。

<S1111>

接着，参见图53对S1111进行。S1111-1中，估计部11按照每个单词对由上述步骤获得的配对信息中的功能的信息进行分割。例如，在获得了具有「Genuine Engine ControlModule」这样的功能的信息的配对信息的情况下，可将其分割为「Genuine」「Engine」「Control」「Module」的4个单词。

S1111-2中，估计部11对藉由上一步骤分割后的单词中的与功能无关的频出单词进行删除。例如，就上一步骤的例子而言，可删除「Genuine」。需要说明的是，也可不进行删除。

S1111-3中，估计部11对分割后的各单词的支持度进行计算。具体而言，单词x的支持度可由下述公式计算。支持度的计算结果的例子示于图54(表3111)。

支持度(x)＝(包含x的配对信息的数量)/(所有配对信息的数量)

S1111-4中，估计部11对各配对信息的功能的信息中包含的单词的支持度之和进行计算。然后，输出和为最大的配对信息。需要说明的是，除了和之外，也可选择平均值或积为最大的配对信息。

作为一例，对基于图55所示的支持度的例子的和进行计算的过程和结果如下所示。

1.Gas Motor Module

和＝0.25+0.5+1.0＝1,75

2.Engine Motor Control Module

和＝0.75+0.5+0.75+1.0＝3.0

3.Engine Control Module

和＝0.75+0.75+1.0＝2.5

4.Engine Control Module

和＝0.75+0.75+1.0＝2.5

2的信息具有最大值，故输出2的配对信息。需要说明的是，图55所基于的配对信息的功能的信息如下所述。

1.Gas Motor Module

2.Engine Motor Control Module

3.Engine Control Module

4.Engine Control Module

S1111―5中，估计部11将下文中描述的进行了标注(labeling)的结果经由设定信息获取·登记部24追加至设定信息估计结果DB 22的图40(表3036)或图47(表3039)的具有适当的ECU型号的行。其结果的例子示于图56(表3112)和图57(表3113)。关于标注(即，赋予标签)，如下所述。

在本处理中使用从检索结果DB 8获得的「ECU型号完全一致的配对信息」的情况下，仅使用ECU型号完全一致的配对信息进行处理。之后，向输出结果赋予「完全一致」之标签。另一方面，在本处理中使用从检索结果DB 8获得的「ECU型号的特定部分一致的配对信息」的情况下，仅使用ECU型号的特定部分一致的配对信息进行处理。之后，向输出结果赋予「部分一致」之标签。

<S1120>

接下来，参见图58对S1120进行说明。S1120-1中，NW_B拓扑结构估计部12执行S1121。S1120-2中，NW_B拓扑结构估计部12执行S1122。

<S1121>

接着，参见图59对S1121进行说明。S1121-1中，NW_B拓扑结构估计部12对下述变量进行声明。

·经由设定信息获取·登记部24从设定信息估计结果DB 22获得的图54(表3111)的IP地址的列表“IP＝[192.168.10.1，192.168.10.2，192.168.10.3]”

·IP列表的长度“Length(IP)”(本例的情况下，Length(IP)＝3)

·i＝0

需要说明的是，变量名可与上述不同。此外，也可使用IP地址之外的值对IP的内容进行统一。

S1121-2中，NW_B拓扑结构估计部12对是否满足i<Length(IP)进行判断，如果为Yes，则进入S1121-3，如果为No，则结束处理。

S1121-3中，NW_B拓扑结构估计部12对车载NW1上的IP[i]执行ICMP的traceroute，并将结果保存在存储单元中。保存的信息的例子示于图60。S1121-4中，使i＝i+1，然后返回S1121-2。

<S1122>

参见图61对S1122进行说明。

S1122-1中，NW_B拓扑结构估计部12经由设定信息获取·登记部24从设定信息估计结果DB 22的图56(表3112)取出所有ECU型号。接着，NW_B拓扑结构估计部12对所取出的重复的ECU型号进行删除。之后，使重复的ECU型号被删除后的ECU型号与物理ECU一一对应。结果的例子示于图62。

S1122-2中，NW_B拓扑结构估计部12根据经由设定信息获取·登记部24从设定信息估计结果DB 22获得的图56(表3112)的「ECU型号」、「MAC地址」及「IP地址」将网络接口追加至图62的信息。其结果如图63所示。

S1122-3中，NW_B拓扑结构估计部12将经由设定信息获取·登记部24从设定信息估计结果DB 22获得的图56(表3112)的所有信息适当分配给ECU和/或ECU的接口。其结果如图64所示。

S1122-4中，NW_B拓扑结构估计部12根据traceroute的记录(图62)对基于NW_B线缆的OBD-II端口、ECU的网络接口(引申而言，物理ECU)及IP路由器的连接关系进行整理。需要说明的是，在相同IP路由器下存在多个ECU的情况下，可估计为这些ECU和IP路由器通过一个NW_B switch进行了连接。此外，在车载网络上存在多个ECU但不存在IP路由器的情况下，也可估计为这些ECU通过一个NW_B switch进行了连接。其结果如图65所示。需要说明的是，ECU之间的连接关系的整理方法并不限定于此。

S1122-5中，NW_B拓扑结构估计部12将图65的估计结果经由设定信息获取·登记部24保存至设定信息估计结果DB 22。

<S1130>

接着，参见图66对NW_A总线拓扑结构估计部13所执行的S1130进行说明。

S1130-1中，基本RTT计算部14执行S1141。S1130-2中，拥塞RTT计算部15执行S1151。S1130-3中，拥塞RTT计算部15执行S1152。S1130-4中，RTT比较部16执行S1161。S1130-5中，估计部17执行S1171。S1130-6中，估计部17执行S1172。

<S1141>

接下来，参见图67对S1141进行说明。

S1141-1中，基本RTT计算部14以200ms的间隔向NW_A-ID[i]发送100次由UDS规定的TesterPresent请求。然后，接收对该请求的响应。接者，将这些发送时刻和接收时刻存储在存储单元中。存储的信息的例子示于图68。需要说明的是，发送间隔和发送次数并不限定于此。

S1141-2中，基本RTT计算部14使用上一步骤的记录(图68)对响应时间(下面也称基本响应时间)的统计值进行计算。然后，将计算结果与NW_A-ID[i]一起进行存储(例：图69(表3141))。需要说明的是，将藉由请求NW_A-ID(就图68而言，为0x700)而发送了TesterPresent的时刻与随后藉由响应NW_A-ID(就图68而言，为0x708)而接收到TesterPresent的时刻之差作为基本响应时间。此外，还计算作为统计值的平均值·最大值、最小值及标准偏差。但是，也可对其它统计值进行计算。

<S1151>

接着，参见图70对S1151进行说明。

S1151-1中，拥塞RTT计算部15对下述变量进行声明。

·对经由设定信息获取·登记部24从设定信息估计结果DB 22获得的图57(表3113)的请求NW_A-ID进行了升顺排序的列表“NW_A-ID＝[0x700，0x724，0x750，0x7E0，0x7E1]”

·列表的长度“Length(NW_A-ID)”(本例的情况下，Length(NW_A-ID)＝5)

·i＝0

需要说明的是，变量名可为上述之外的变量名。此外，NW_A-ID的内容也可通过NW_A-ID之外的值来进行统一。

S1151-2中，拥塞RTT计算部15对是否满足i<Length(NW_A-ID)进行判断。如果为Yes，则进入S1151-2，如果为No，则结束处理。S1151-3中，使j＝i+1。

S1151-4中，拥塞RTT计算部15对是否满足j<Length(NW_A-ID)进行判断。如果为Yes，则进入S1151-5，如果为No，则结束处理。S1151-5中，拥塞RTT计算部15执行S1152，然后返回S1151-2。

<S1152>

接着，参见图71对S1152进行说明。

S1152-1中，拥塞RTT计算部15以0.5ms的间隔至S1152结束为止连续向NW_A-ID[i]发送由UDS规定的TesterPresent请求，由此使发送NW_A-ID[i]的NW_A消息的NW_A总线发生拥塞。需要说明的是，发送间隔并不限定于此。

S1152-2中，拥塞RTT计算部15以200ms的间隔向NW_A-ID[j]发送100次由UDS规定的TesterPresent请求。然后，接收对该请求的响应。接下来，将这些发送时刻和接收时刻存储在存储单元中。存储的信息的例子示于图72。需要说明的是，发送间隔和发送次数并不限定于此。

S1152-3中，拥塞RTT计算部15使用前一步骤的记录对响应时间(下面也称拥塞时响应时间)的统计值进行计算。之后，将计算结果与NW_A-ID[i](图73(表3151)中，称为拥塞NW_A-ID)和NW_A-ID[j](图73(表3151)中，称为统计值计算对象NW_A-ID)一起保存在存储单元中。保存的信息的例子示于图73(表3151)。

需要说明的是，将藉由请求NW_A-ID而发送TesterPresent的时刻与随后藉由响应NW_A-ID而接收TesterPresent的时刻之差作为拥塞时响应时间。此外，还计算作为统计值的平均值·最大值、最小值及标准偏差。但是，也可对其它统计值进行计算。

<S1162>

接着，参见图74对S1161进行说明。

S1161-1中，RTT比较部16针对某NW_A-ID＝x将图69(表3141)的NW_A-ID＝x的统计值与图73(表3151)的统计值计算用的NW_A-ID＝x的统计值进行比较。之后，从图73(表3151)提取图73(表3151)侧的统计值均比图69(表3141)增加了50％以上的行。提取结果如图75(表3161)所示。需要说明的是，图75(表3161)的提取方法并不限定于此。

S1161-2中，RTT比较部16对图75(表3161)的各行的拥塞NW_A-ID和统计值计算对象NW_A-ID进行分组。例如，0x700和0x724为一组，0x700和0x7E0为一组，0x724和0x7E0为一组，0x750和0x7E1为一组。

S1161-3中，RTT比较部16将上一步骤中生成的组尽可能地进行汇总。例如，0x700和0x724为一组，0x700和0x7E0为一组，0x724和0x7E0为一组，为此可将这3个作为一组。其结果如图76(表3162)所示。

<S1171>

接着，参见图77对S1171进行说明。

S1171-1中，估计部17从保存于设定信息估计结果DB 22的相当于图56(表3112)的信息中取出所有ECU型号。接下来，对所取出的重复的ECU型号进行删除。之后，使重复的ECU型号被删除后的ECU型号和物理ECU一一对应。结果如图78所示。

S1171-2中，估计部17根据保存于设定信息估计结果DB 22的相当于图56(表3112)的信息将请求NW_A-ID的信息追加至图78。其结果如图79所示。

S1171-3中，估计部17针对某NW_A-ID＝x将图69(表3141)的NW_A-ID＝x的统计值与图73(表3151)的统计值计算用的NW_A-ID＝x的统计值进行比较。之后，从图73(表3151)提取图73(表3151)侧的统计值均比图69(表3141)增加了50％以上的行。提取结果如图75(表3161)所示。需要说明的是，图75(表3161)的提取方法并不限定于此。

S1171-4中，估计部17对图75(表3161)的各行的拥塞NW_A-ID和统计值计算对象NW_A-ID进行分组。例如，0x700和0x724为一组，0x700和0x7E0为一组，0x724和0x7E0为一组，0x750和0x7E1为一组。

S1171-5中，估计部17将上一步骤中生成的组尽可能地进行汇总。例如，0x700和0x724为一组，0x700和0x7E0为一组，0x724和0x7E0为一组，故而可将这3个作为一组。其结果如图76(表3162)所示。

<S1172>

接着，参见图80对S1172进行说明。

S1172-1中，估计部17判定为，对图76(表3162)中汇总为一组的NW_A-ID的NW_A消息进行响应的ECU与相同NW_A总线连接。之后，估计部17根据该判定结果将图79的信息转换为NW_A总线的拓扑结构图(图81)。

S1172-2中，估计部17将传送至设定信息估计结果DB 22(设定信息整理部)的图56(表3112)的所有信息适当分配给ECU。其结果如图82所示。

S1172-3中，估计部17对传送至设定信息估计结果DB 22(设定信息整理部)的图65的NodeType＝0x1的ECU和图82的ECU的功能的「完全一致」或「部分一致」中包含有GW(gateway)的ECU进行探索。

S1172-4中，估计部17通过NW_A总线对上一步骤中找到的ECU进行连接。其结果如图83所示。

S1172-5中，估计部17将图83所示的信息经由设定信息获取·登记部24保存至设定信息估计结果DB 22。

<S1180>

接着，参见图84对正常NW_A通信估计部18所执行的S1180进行说明。

S1180-1中，再启动命令发送部19执行S1191。S1180-2中，再启动命令发送部19执行S1192。S1180-3中，车辆警报接收部20执行S1201。S1180-4中，车辆警报接收部20执行S1211。

<S1191>

接着，参见图85对S1191进行说明。

S1191-1中，再启动命令发送部19对下述变量进行声明。

·设定信息估计结果DB 22中保存的图56(表3112)的请求NW_A-ID列表“NW_A-ID＝[0x700，0x724，0x750，0x7E0，0x7E1]”

·列表的长度“Length(NW_A-ID)”(本例的情况下，Length(NW_A-ID)＝5)

·i＝0

需要说明的是，变量名可与上述不同。此外，还可通过NW_A-ID之外的值对NW_A-ID的内容进行统一。

S1191-2中，再启动命令发送部19对i<Length(NW_A-ID)是否成立进行判断。Yes的情况下，进入S1191-3，No的情况下，结束处理。S1191-3中，再启动命令发送部19执行S1192。S1191-3中，再启动命令发送部19使i＝i+1，然后返回S1191-2。

<S1192>

接下来，参见图86对S1192进行说明。

S1192-1中，再启动命令发送部19以5秒至10秒的随机间隔向NW_A-ID[i]发送10次由UDS规定的ECUReset(ResetType＝HardReset)请求。需要说明的是，发送间隔、发送次数及ResetType并不限定于此。

S1192-2中，再启动命令发送部19将前一步骤中发送了ECUReset请求的时刻与NW_A-ID[i]一起存储在存储单元内。存储的信息的例子示于图87。

<S1201>

接着，参见图88对S1201进行说明。

首先，对前提进行描述。车载网络1上的ECU按预定(设计值)的时间间隔(发送间隔)发送了某个NW_A-ID的NW_A消息。此外，车载网络1上的NW_A-IDS在某个NW_A-ID的NW_A消息的发送间隔与设计值偏离较大的情况下发出警报。需要说明的是，假设警报中包含有警报发出时刻和检测到的NW_A消息的NW_A-ID。

接收到ECUReset的ECU暂停NW_A消息的发送，以执行ECU的再启动。此外，再启动后，可在任意时间后恢复NW_A消息的发送。为此，接收到ECUReset的ECU所发送的NW_A消息的发送间隔会临时增大或减小。NW_A-IDS将此判定为异常，并发出警报。

S1201-1中，车辆警报接收部20将NW_A-IDS的警报与时刻一起存储至存储单元。存储的信息的例子示于图89。

<S1211>

接着，参见图90对S1211进行说明。

S1211-1中，估计部21将作为图87所示的信息而存储了的NW_A-ID和作为图89所示的信息而存储了的NW_A-ID进行关联。关联时，根据存储的时刻的相似性来进行。进行了关联后的结果的例子示于图91(表3211)。

S1211-2中，估计部21将图91(表3211)的结果追加至车辆构成估计的结果(例如，图83和图56(表3112))。此时，将满足「表3211的ECUReset的NW_A-ID列」＝「图83和表3112的请求NW_A-ID」之条件的行追加至图83和图56(表3112)。

需要说明的是，追加时，例如以「定常发送NW_A-ID」之列名进行追加。其的结果的例子如图92和图93(表3212)所示。

(实施例A2)

接下来，对实施例A2进行说明。图94是实施例A2的系统的配置图。如图94所示，实施例A2的构成为仅具备作为估计部的与基本技术3对应的ECU功能估计部4的构成。各部(功能部)的处理与实施例A1中描述的处理相同。

(实施例A3)

接着，对实施例A3进行说明。图95是实施例A3的系统的配置图。如图95所示，实施例A3的构成为仅具备作为估计部的与基本技术1对应的NW_A总线拓扑结构估计部13的构成。各部(功能部)的处理与实施例A1中说明的处理相同。

(实施例A4)

接着，对实施例A4进行说明。图96是实施例A4的系统的配置图。如图96所示，实施例A4的构成为仅具备作为估计部的与基本技术2对应的正常NW_A通信估计部18的构成。各部(功能部)的处理与实施例A1中描述的处理相同。

(实施例A5)

接下来，对实施例A5进行说明。图97是实施例A5的系统的配置图。如图97所示，实施例A5的构成为从实施例A1(图27)的构成中除去了正常NW_A通信估计部18之后的构成。各部(功能部)的处理与实施例A1中说明的处理相同。

(实施例A6)

接着，对实施例A6进行说明。图98是实施例A6的系统的配置图。如图98所示，实施例A6的构成是从实施例A1(图27)的构成中除去了NW_A总线拓扑结构估计部13之后的构成。各部(功能部)的处理与实施例A1中说明的处理相同。

(实施例A7)

接着，对实施例A7进行说明。图99是实施例A7的系统的配置图。如图99所示，实施例A7的构成是从实施例A1(图27)的构成中除去了ECU功能估计部4之后的构成。各部(功能部)的处理与实施例A1中说明的处理相同。

(实施例B1)

接着，对实施例B1进行说明。实施例B1是将本发明的设定信息估计系统部署在车载NW上的实施例。图100是实施例B1的汽车(车载NW)的配置图。如图100所示，具有作为车载NW上的ECU的功能的车辆设定估计装置2和设定信息估计结果DB 22。

需要说明的是，取代图100那样在ECU中具备设定信息估计结果DB 22的方式，还可为在云(cloud)上具备设定信息估计结果DB 22的方式。此外，也可在云上具备车辆设定估计装置2中除了消息收发部23之外的一个或多个功能部。例如，云上可仅具备车辆设定估计装置2的ECU功能估计部4。

(实施例B2)

接着，对实施例B2进行说明。实施例B2是将本发明的设定信息估计系统(装置)直接连接至OBD-II端口的实施例。图101是实施例B2的系统的配置图。如图101所示，设定信息估计系统与OBD-II端口直接连接。

需要说明的是，取代图101那样在设定信息估计系统(装置)上具备设定信息估计结果DB 22的情形，还可在云上具备设定信息估计结果DB 22。此外，也可在云上具备车辆设定估计装置2中除了消息收发部23之外的一个或多个功能部。例如，云上可仅具备车辆设定估计装置2的ECU功能估计部4。

(实施例B3)

接着，对实施例B3进行说明。图102示出了实施例B3的系统的构成。如图102所示，实施例B3中，本发明的设定信息估计系统设置在充电器中并与充电端口相连。可经由充电端口执行设定信息估计系统的处理。

需要说明的是，取代图102那样在充电器中具备设定信息估计结果DB 22的方式，还可为在云上具备设定信息估计结果DB 22的方式。此外，也可在云上具备车辆设定估计装置2中除了消息收发部23之外的一个或多个功能部。例如，云上可仅具备车辆设定估计装置2的ECU功能估计部4。

(实施例B4)

接着，对实施例B4进行说明。图103示出了实施例B4的系统的配置。如图103所示，实施例B4中，本发明的设定信息估计系统设置在外部网络上，可经由外部网络来执行设定信息估计系统的处理。

(实施例C1)

接下来，对实施例C1进行说明。实施例C1是将设定信息估计系统用于SOC等的安全分析的实施例。图104为实施例C1的系统配置图。

如图104所示，本系统除了与汽车连接的车辆设定估计装置2和设定信息估计结果DB 22之外还具备设定信息获取部30、安全分析部31及分析结果提示部32。各部(功能部)如图示那样进行了连接。

设定信息获取部30从设定信息估计结果DB 22提取所需的设定信息，并将其传递给安全分析部31。安全分析部31利用由车辆设定估计装置2估计的车辆设定信息进行更高端的安全分析。之后，将分析结果传递给分析结果提示部32。

分析结果提示部32接收分析结果并对其进行适当的加工，然后将其提示给分析员。需要说明的是，分析员并不限定于人，也可为利用分析结果再进行其它分析的程序。

安全分析部31所执行的安全分析并不限定于特定的安全分析，但是，例如存在以下所列举的示例。

·获取并利用拓扑结构信息的攻击路径的估计

·利用拓扑结构信息和/或各ECU的软件版本的入口点(entry point)的估计

·利用拓扑结构信息和/或各ECU的软件版本的原因估计

·利用拓扑结构信息、各ECU的软件版本及/或正常通信的信息的异常通信和/或进程(process)的估计

·利用拓扑结构信息和/或各ECU的软件版本的、使用了正常通信的信息和各ECU的功能的信息的影响的估计

·利用拓扑结构信息和/或各ECU的软件版本的应对方法的估计

(实施例C2)

接下来，对实施例C2进行说明。实施例C2是将设定信息估计系统用于资产管理的实施例。图105为实施例C2的系统配置图。

如图105所示，本系统除了与汽车连接的车辆设定估计装置2和设定信息估计结果DB 22之外还具备设定信息获取部30、资产管理部33及管理信息提示部34。各部(功能部)如图示那样进行了连接。

设定信息获取部30从设定信息估计结果DB 22提取所需的设定信息，并将其传递给资产管理部33。资产管理部33保持管理信息，并根据接收到的设定信息来进行是否存在管理信息中没有的ECU和/或不支持的ECU等的管理。此时，也可利用ECU的软件的支持状况等的公开信息。

管理信息提示部34从资产管理部33获取管理信息并对其进行适当的加工(例如，仅对管理信息中没有的ECU的设备名和/或地址信息进行提取·整理)，然后将结果提示给管理员。需要说明的是，管理员并不限定于人，也可为使用管理信息再进行其它分析的程序。

(实施例C3)

接着，对实施例C3进行说明。实施例C3是将设定信息估计系统用于异常检测的实施例。图106为实施例C3的系统配置图。

如图106所示，本系统除了与汽车连接的车辆设定估计装置2和设定信息估计结果DB 22之外还具备设定信息获取部30和异常检测部35。各部(功能部)如图示那样进行了连接。

设定信息获取部30从设定信息估计结果DB 22提取所需的设定信息，并将其传递给异常检测部35。异常检测部35利用保存有正常的车辆设定信息的DB的信息、异常检测规则及/或公开信息(例如，弱点(vulnerability)DB的信息)对车辆设定信息的异常状态进行检测。另外，还将异常检测结果通知给汽车的管理员和/或SOC等的分析员。

异常检测方法并不限定于特定的方法，但是，例如存在下面所列举的示例。

·对正常的车辆设定信息DB中保存的车辆设定信息和设定信息估计结果DB中保存的车辆设定信息进行比较，如果存在差异，则检测为异常。

·在设定信息估计结果DB 22中保存的车辆设定信息满足异常检测规则的情况下、和/或、在具有被公开信息(弱点DB)等定义为异常状态的设定信息的情况下，检测为存在异常。

·对正常的汽车的车辆设定信息进行机器学习，并根据学习到的模型进行基于机器学习的异常检测。

(实施例C4)

接着，对实施例C4进行说明。实施例C4是将设定信息估计系统用于安全诊断的实施例。图107是实施例C4的系统配置图。

如图107所示，本系统除了与汽车连接的车辆设定估计装置2和设定信息估计结果DB 22之外还具备设定信息获取部30、安全诊断部36及诊断结果提示部37。各部(功能部)如图示那样进行了连接。

设定信息获取部30从设定信息估计结果DB 22提取所需的设定信息，并将其传递给安全诊断部36。安全诊断部36根据所接收到的设定信息进行汽车中是否具有存在安全问题的ECU等的诊断。此时，可利用ECU的软件的支持状况等的公开信息来确认是否存在问题。

诊断结果提示部37从安全诊断部36获取诊断结果并对其进行适当的加工(例如，对诊断结果进行评分等)，然后将其提示给管理员。需要说明的是，管理员并不限定于人，也可为利用管理信息再进行其它分析的程序。

例如，安全诊断部36所使用的诊断规则中记录有弱点被确认了的ECU的ECU型号和/或软件的版本信息(黑名单)。安全诊断部36对诊断规则中保存的车辆设定信息(黑名单)和设定信息估计结果DB 22的车辆设定信息进行比较，如果黑名单中存在相应的信息，则指出弱点(漏洞)。

(硬件配置例)

由第1实施方式中说明的诊断通信收发部100、诊断系统日志DB 200及设定信息估计部300构成的装置、由诊断通信收发部100和诊断系统日志DB 200构成的装置、由诊断系统日志DB 200和设定信息估计部300构成的装置、由诊断通信收发部100和设定信息估计部300构成的装置、由诊断通信收发部100构成的装置、由诊断系统日志DB 200构成的装置、以及由设定信息估计部300构成的装置例如均可藉由使计算机执行程序而实现。该计算机可为物理计算机，也可为云上的虚拟机。

此外，就第2实施方式中描述的系统、装置及功能部而言，例如也可通过使计算机执行程序而实现。该计算机可为物理计算机，也可为云上的虚拟机。

将上述程序进行操作的主体称为「装置」。该装置可通过使用计算机中内置的CPU、存储器等的硬件资源来执行与由该装置所执行的处理相对应的程序而实现。该程序存储在计算机可读取存储介质(便携式存储器等)中，由此可进行保存，或者也可进行分发。此外，还可通过互联网、电子邮件等网络来提供上述程序。

图108为上述计算机的硬件配置例的示意图。图108的计算机具有分别由总线BS进行了相互连接的驱动装置1000、辅助存储装置1002、存储装置1003、CPU1004、接口装置1005、显示装置1006、输入装置1007、输出装置1008等。需要说明的是，也可不具备这些中的一部分装置。例如，不进行显示的装置可不具备显示装置1006。

用于实现该计算机的处理的程序例如可由CD-ROM、存储卡等的存储介质1001提供。存储了程序的存储介质1001被放入(set)驱动装置1000后，程序可从存储介质1001经由驱动装置1000被安装至辅助存储装置1002。但是，程序的安装并非一定要从存储介质1001来进行，也可经由网络从其它计算机来下载程序。辅助存储装置1002可对所安装的程序进行保存，还可对所需的文件、数据等进行保存。

存储装置1003在存在程序的启动指示的情况下从辅助存储装置1002读出程序并对其进行保存。CPU1004可依据存储装置1003中保存的程序来实现该装置的功能。接口装置1005是可用于与网络进行连接的接口，并可作为发送部和接收部而发挥功能。显示装置1006可对基于程序的GUI(Graphical UserInterface)等进行显示。输入装置1007可由键盘、鼠标、按钮、触屏等构成，并可用于输入各种操作指示。输出装置1008可输出计算结果。

(实施方式的效果)

如上所述，在本发明的实施方式中，藉由进行诊断通信的收发(接收和发送)为车辆设定信息的估计收集有效信息，并藉由对所收集的信息进行分析来估计车辆设定信息，其中，所述诊断通信使用了在各ECU中以标准方式支持的诊断通信协议(DoCAN、DoIP、UDS等)。据此，当对车辆设定信息进行时，并不需需进行资源的增强和新协议的支持，由此可降低额外的成本。

(实施方式的汇总)

本说明书中至少公开了下述各项的网络设定估计装置、网络设定估计方法及程序。

(第1项)

一种对目标装置中的内部网络的设定信息进行估计的网络设定估计装置，具备：

诊断通信收发部，使用在所述内部网络上的电子控制装置中以标准方式支持的诊断通信方法，向所述内部网络上的电子控制装置发送消息，并接收对该消息的响应；及

设定信息估计部，根据由所述诊断通信收发部获得的所述响应，对所述内部网络的设定信息进行估计。

(第2项)

如第1项所述的网络设定估计装置，其中，所述设定信息估计部具备：

存在确认部，根据所述响应，对所述内部网络上的电子控制装置的存在进行确认；

拓扑结构估计部，根据由所述存在确认部确认的电子控制装置的存在确认结果，对所述内部网络的拓扑结构进行估计；及

信息提取部，根据所述响应，对与所述内部网络上的电子控制装置相关的信息进行提取。

(第3项)

如第1项或第2项所述的网络设定估计装置，其中，

所述诊断通信收发部分别向所述内部网络中的第1网络和第2网络发送消息，并接收该消息的响应，

所述设定信息估计部藉由对所述第1网络所发送的消息的响应来进行与所述第1网络连接的电子控制装置的存在确认，并藉由对所述第2网络所发送的消息的响应来进行与所述第2网络连接的电子控制装置的存在确认。

(第4项)

如第1项至第3项中的任一项所述的网络设定估计装置，其中，

所述诊断通信收发部发送设定有数据ID的消息，并接收该消息的响应，

所述设定信息估计部从对设定有所述数据ID的消息的响应中提取与该数据ID对应的信息。

(第5项)

一种对目标装置中的内部网络的设定信息进行估计的网络设定估计装置，具备：

设定信息估计部，使用在所述内部网络上的电子控制装置中以标准方式支持的诊断通信方法，向所述内部网络上的电子控制装置发送消息，并根据由接收对该消息的响应的装置所获得的所述响应，对所述内部网络的设定信息进行估计。

(第6项)

一种对目标装置中的内部网络的设定信息进行估计的网络设定估计装置，具备：

基本RTT计算部，在非拥塞时的状态下，使用在所述内部网络上的电子控制装置中以标准方式支持的诊断通信方法，对所述内部网络上的第1电子控制装置的往返时间(round trip time)进行计算；

拥塞RTT计算部，在以高频度(频繁)向第2电子控制装置发送诊断请求的拥塞时的状态下，对所述第1电子控制装置的往返时间进行计算；及

估计部，通过对所述非拥塞时的状态下的往返时间和所述拥塞时的状态下的往返时间进行比较，估计所述第1电子控制装置和所述第2电子控制装置是否与相同总线连接。

(第7项)

一种对目标装置中的内部网络的设定信息进行估计的网络设定估计装置，具备：

再启动命令发送部，使用在所述内部网络上的电子控制装置中以标准方式支持的诊断通信方法，向所述内部网络上的目标电子控制装置发送再启动命令；

警报接收部，从所述内部网络接收因所述再启动命令而发生的警报；及

估计部，将所述警报中包含的ID估计为所述目标电子控制装置所发送的正常通信的ID。

(第8项)

一种对目标装置中的内部网络的设定信息进行估计的网络设定估计装置，具备：

Web检索部，利用藉由使用在所述内部网络上的电子控制装置中以标准方式支持的诊断通信方法而获取的目标电子控制装置的完整的型号和该型号中的与功能相关的位，对电子控制装置的功能进行检索；及

估计部，将由所述Web检索部获得的检索结果中包含的单词的支持度之和为最大的功能估计为所述目标电子控制装置的功能。

(第9项)

一种由网络设定估计装置执行的对目标装置中的内部网络的设定信息进行估计的网络设定估计方法，具有：

接收步骤，使用在所述内部网络上的电子控制装置中以标准方式支持的诊断通信方法，向所述内部网络上的电子控制装置发送消息，并接收对该消息的响应；及

估计步骤，根据所述响应，对所述内部网络的设定信息进行估计。

(第10项)

一种使计算机作为第1项至第8项中的任一项所述的网络设定估计装置中的各功能部而发挥功能的程序。

以上对本发明的实施方式进行了详述，但本发明并不限定于这些特定的实施方式，在权利要求书记载的本发明的主旨的范围内还可进行各种各样的变形和变更。

本专利申请主张基于2020年9月18日申请的国际专利申请PCT/JP2020/035621的优先权，并将该国际专利申请PCT/JP2020/035621的内容全部援引于本申请。

[附图标记说明]

1车载NW

2设定要素估计部

3ECU基本信息获取部

4ECU功能估计部

6Web检索部

7Web网站

8检索结果DB

9完全一致提取部

10特定部分一致提取部

11估计部

12NW_B拓扑结构估计部

13NW_A总线拓扑结构估计部

14基本RTT计算部

15拥塞RTT计算部

16RTT比较部

17估计部

18正常NW_A通信估计部

19再启动命令发送部

20车辆警报接收部

21估计部

22设定信息估计结果DB

23消息收发部

24设定信息获取·登记部

30设定信息获取部

31安全分析部

32分析结果提示部

33资产管理部

34管理信息提示部

35异常检测部

36安全诊断部

37诊断结果提示部

500ECU

100诊断通信收发部

200诊断系统日志DB

300设定信息估计部

310ECU存在确认部

320拓扑结构估计部

330ECU信息提取部

340输出部

400汽车

1000驱动装置

1001存储介质

1002辅助存储装置

1003存储装置

1004  CPU

1005  接口装置

1006  显示装置

1007  输入装置

1008  输出装置。

Claims (10)

1.一种网络设定估计装置，对目标装置中的内部网络的设定信息进行估计，所述网络设定估计装置具备：

诊断通信收发部，使用在所述内部网络上的电子控制装置中以标准方式支持的诊断通信方法，向所述内部网络上的电子控制装置发送消息，并接收对所述消息的响应；及

设定信息估计部，根据由所述诊断通信收发部获取的所述响应，对所述内部网络的设定信息进行估计。

2.如权利要求1所述的网络设定估计装置，其中，

所述设定信息估计部具备：

存在确认部，根据所述响应，对所述内部网络上的电子控制装置的存在进行确认；

拓扑结构估计部，根据所述存在确认部对电子控制装置的存在确认结果，估计所述内部网络的拓扑结构；及

信息提取部，根据所述响应，提取与所述内部网络上的电子控制装置相关的信息。

3.如权利要求1或2所述的网络设定估计装置，其中，

所述诊断通信收发部分别向所述内部网络中的第1网络和第2网络发送消息，并接收对该消息的响应，

所述设定信息估计部使用对发送至所述第1网络的消息的响应来确认与所述第1网络连接的电子控制装置的存在，并使用对发送至所述第2网络的消息的响应来确认与所述第2网络连接的电子控制装置的存在。

4.如权利要求1至3中的任一项所述的网络设定估计装置，其中，

所述诊断通信收发部发送设定有数据ID的消息，并接收对该消息的响应，

所述设定信息估计部从对设定有所述数据ID的消息的响应中提取与所述数据ID对应的信息。

5.一种网络设定估计装置，对目标装置中的内部网络的设定信息进行估计，所述网络设定估计装置具备：

设定信息估计部，使用在所述内部网络上的电子控制装置中以标准方式支持的诊断通信方法，向所述内部网络上的电子控制装置发送消息，并根据藉由接收对所述消息的响应的装置而获取的所述响应，对所述内部网络的设定信息进行估计。

6.一种网络设定估计装置，对目标装置中的内部网络的设定信息进行估计，所述网络设定估计装置具备：

基本RTT计算部，在非拥塞时的状态下，使用在所述内部网络上的电子控制装置中以标准方式支持的诊断通信方法，计算所述内部网络上的第1电子控制装置的往返时间；

拥塞RTT计算部，在频繁向第2电子控制装置发送诊断请求的拥塞时的状态下，计算所述第1电子控制装置的往返时间；及

估计部，通过对所述非拥塞时的状态下的往返时间和所述拥塞时的状态下的往返时间进行比较，估计所述第1电子控制装置和所述第2电子控制装置是否与相同总线连接。

7.一种网络设定估计装置，对目标装置中的内部网络的设定信息进行估计，所述网络设定估计装置具备：

再启动命令发送部，使用在所述内部网络上的电子控制装置中以标准方式支持的诊断通信方法，向所述内部网络上的目标电子控制装置发送再启动命令；

警报接收部，从所述内部网络接收因所述再启动命令而发生的警报；及

估计部，将所述警报中包含的ID估计为所述目标电子控制装置发送的正常通信的ID。

8.一种网络设定估计装置，对目标装置中的内部网络的设定信息进行估计，所述网络设定估计装置具备：

Web检索部，使用目标电子控制装置的完整的型号和该型号中的与功能相关的位，对电子控制装置的功能进行检索，其中，所述目标电子控制装置的完整的型号是藉由使用在所述内部网络上的电子控制装置中以标准方式支持的诊断通信方法而获取的；及

估计部，将由所述Web检索部获取的检索结果中包含的单词的支持度之和为最大的功能估计为所述目标电子控制装置的功能。

9.一种网络设定估计方法，由对目标装置中的内部网络的设定信息进行估计的网络设定估计装置执行，所述网络设定估计方法具有：

接收步骤，使用在所述内部网络上的电子控制装置中以标准方式支持的诊断通信方法，向所述内部网络上的电子控制装置发送消息，并接收对所述消息的响应；及

估计步骤，根据所述响应，对所述内部网络的设定信息进行估计。

10.一种程序，用于使计算机作为权利要求1至8中的任一项所述的网络设定估计装置内的各功能部而发挥功能。

Images