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

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-25

(45)【発行日】2024-12-03

(54)【発明の名称】ネットワーク構成推定装置、ネットワーク構成推定方法、及びプログラム

(51)【国際特許分類】

   H04L 41/0853 20220101AFI20241126BHJP

   H04L 41/12 20220101ALI20241126BHJP

【ＦＩ】

H04L41/0853

H04L41/12

【請求項の数】 10

(21)【出願番号】P 2022550459

(86)(22)【出願日】2021-09-02

(86)【国際出願番号】 JP2021032301

(87)【国際公開番号】W WO2022059503

(87)【国際公開日】2022-03-24

【審査請求日】2023-02-21

(31)【優先権主張番号】PCT/JP2020/035621

(32)【優先日】2020-09-18

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】110004381

【氏名又は名称】弁理士法人ＩＴＯＨ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100124844

【弁理士】

【氏名又は名称】石原 隆治

(72)【発明者】

【氏名】松林 勝

(72)【発明者】

【氏名】小山 卓麻

(72)【発明者】

【氏名】岡野 靖

(72)【発明者】

【氏名】田中 政志

【審査官】速水 雄太

(56)【参考文献】

【文献】国際公開第２０１９／０７３９３２（ＷＯ，Ａ１）

【文献】特開２００７－０９９１４５（ＪＰ，Ａ）

【文献】韓国公開特許第１０－２０２０－０１４３９６１（ＫＲ，Ａ）

【文献】米国特許出願公開第２０１４／０１８８３３０（ＵＳ，Ａ１）

【文献】中国特許出願公開第１１０９０８３５７（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ １２／００－１２／６６

４１／００－１０１／６９５

(57)【特許請求の範囲】

【請求項1】

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

【請求項2】

前記構成情報推定部は、
前記応答に基づいて、前記内部ネットワーク上の電子制御装置の存在を確認する存在確認部と、
前記存在確認部による電子制御装置の存在確認結果に基づいて、前記内部ネットワークのトポロジを推定するトポロジ推定部と、
前記応答に基づいて、前記内部ネットワーク上の電子制御装置に関する情報を抽出する情報抽出部と
を備える請求項１に記載のネットワーク構成推定装置。

【請求項3】

前記診断通信送受信部は、前記内部ネットワークにおける第１ネットワークと第２ネットワークのそれぞれにメッセージを送信し、その応答を受信し、
前記構成情報推定部は、前記第１ネットワークに送信したメッセージの応答により前記第１ネットワークに接続した電子制御装置の存在を確認し、前記第２ネットワークに送信したメッセージの応答により前記第２ネットワークに接続した電子制御装置の存在を確認する
請求項１又は２に記載のネットワーク構成推定装置。

【請求項4】

前記診断通信送受信部は、データＩＤを設定したメッセージを送信し、その応答を受信し、
前記構成情報推定部は、前記データＩＤを設定したメッセージに対する応答から、当該データＩＤに対応する情報を抽出する
請求項１ないし３のうちいずれか１項に記載のネットワーク構成推定装置。

【請求項5】

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

【請求項6】

対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
非輻輳時の状態において、前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の第１電子制御装置のラウンドトリップタイムを算出するベースＲＴＴ算出部と、
第２電子制御装置に対して診断要求を高頻度で送信している輻輳時の状態において、前記第１電子制御装置のラウンドトリップタイムを算出する輻輳ＲＴＴ算出部と、
前記非輻輳時の状態におけるラウンドトリップタイムと、前記輻輳時の状態におけるラウンドトリップタイムとを比較することにより、前記第１電子制御装置と前記第２電子制御装置が同一バスに接続されているか否かを推定する推定部と
を備えるネットワーク構成推定装置。

【請求項7】

対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の対象電子制御装置に再起動命令を送信する再起動命令送信部と、
前記再起動命令に起因して発生したアラートを前記内部ネットワークから受信するアラート受信部と、
前記アラートに含まれるＩＤを、前記対象電子制御装置が送信する通常通信のＩＤであると推定する推定部と
を備えるネットワーク構成推定装置。

【請求項8】

対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて取得した対象電子制御装置の型番の全体、及び、当該型番における機能に関する桁を用いて、電子制御装置の機能を検索するＷｅｂ検索部と、
前記Ｗｅｂ検索部により得られた検索結果に含まれる単語の支持度の和が最大となる機能を前記対象電子制御装置の機能と推定する推定部と
を備えるネットワーク構成推定装置。

【請求項9】

対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置が実行するネットワーク構成推定方法であって、
前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の電子制御装置に対してメッセージを送信し、当該メッセージに対する応答を受信するステップと、
前記応答と接続方法の公知情報とに基づいて、前記内部ネットワークのトポロジを含む前記構成情報を推定するステップと
を備えるネットワーク構成推定方法。

【請求項10】

コンピュータを、請求項１ないし８のうちいずれか１項に記載のネットワーク構成推定装置における各部として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、自動車等の対象装置における内部ネットワークの構成情報を推定する技術に関連するものである。

【背景技術】

【0002】

近年、コネクテッドカー社会の到来とともに自動車へのサイバー攻撃の脅威が増加している。すなわち、自動車に搭載されるコネクティッド機能により、自動車がネットワークを通して外部と接続できるようになることで、逆に外部からのサイバー攻撃の脅威が増加する。

【0003】

そのため、自動車へのサイバー攻撃を検知し、その攻撃の経路・原因を特定し、その攻撃に対処する事後対策の実施が重要となっている。攻撃の経路・原因を正確に特定するには、車載ネットワーク（ＮＷ）の構成（トポロジ）やＮＷ上の情報処理装置（ＩＶＩやＴＣＵ等）や電子制御装置（ＥＣＵ）に関する情報が必要である。

【0004】

上記以外にも、アセット管理や構成の異常検知など、様々な目的を達成するためにも車両構成情報は必要である。

【0005】

ＮＷの構成等を推定する従来技術として、例えば非特許文献１に開示された技術がある。非特許文献１に開示された技術では、ＳＮＭＰを用いて対象ＮＷ内の各ＳｗｉｔｃｈのＭＡＣアドレス転送テーブルを取得し、取得した情報を解析することで対象ＮＷのＬ２トポロジを推定する。

【先行技術文献】

【非特許文献】

【0006】

【文献】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).

【発明の概要】

【発明が解決しようとする課題】

【0007】

車載ＮＷのトポロジや各ＥＣＵの情報を取得するために、非特許文献１に開示されているＳＮＭＰベースの方法を用いることが考えられる。しかし、ＳＮＭＰベースの方法で車載ＮＷのトポロジや各ＥＣＵの情報を取得するためには、各ＥＣＵに対してＳＮＭＰエージェントの動作を可能とするためのリソース増強やＳＮＭＰのサポートをすることが必要となり、追加のコストがかかるという問題がある。

【0008】

本発明は上記の点に鑑みてなされたものであり、対象装置における内部ネットワークの構成装置に対してリソースの増強や新たなプロトコルのサポートを行うことなく、当該内部ネットワークの構成情報を推定することを可能とする技術を提供することを目的とする。

【課題を解決するための手段】

【0009】

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

【発明の効果】

【0010】

開示の技術によれば、対象装置における内部ネットワークの構成装置に対してリソースの増強や新たなプロトコルのサポートを行うことなく、当該内部ネットワークの構成情報を推定することが可能となる。

【図面の簡単な説明】

【0011】

【図1】車載構成情報の例を示す図である。

【図2】診断通信の例を説明するための図である。

【図3】第１の実施の形態における構成情報推定システムの構成例を示す図である。

【図4】診断通信送受信部の処理手順例を説明するためのフローチャートである。

【図5】構成情報推定部の処理手順例を説明するためのフローチャートである。

【図6】第１の実施の形態における実施例１におけるシステム構成図である。

【図7】第１の実施の形態における実施例２におけるシステム構成図である。

【図8】第１の実施の形態における実施例３におけるシステム構成図である。

【図9】第１の実施の形態における実施例４におけるシステム構成図である。

【図10】第１の実施の形態における実施例５におけるシステム構成図である。

【図11】第１の実施の形態における実施例６におけるシステム構成図である。

【図12】車両構成情報の一例を示す図である。

【図13】第２の実施の形態で前提としている自動車のネットワークを示す図である。

【図14】要素技術１の目標を説明するための図である。

【図15】要素技術１の適用対象を説明するための図である。

【図16】診断通信のＲＴＴを説明するための図である。

【図17】要素技術１の推定方法を説明するための図である。

【図18】要素技術１の推定手順を説明するための図である。

【図19】要素技術１の推定手順を説明するための図である。

【図20】要素技術１の推定手順を説明するための図である。

【図21】要素技術２の目標を説明するための図である。

【図22】要素技術２のポイントと手順を説明するための図である。

【図23】要素技術３に関する従来技術を説明するための図である。

【図24】要素技術３の目標を説明するための図である。

【図25】要素技術３の推定方法を説明するための図である。

【図26】要素技術３の推定方法を説明するための図である。

【図27】第２の実施の形態における実施例Ａ１の構成図である。

【図28】第２の実施の形態における実施例Ａ１の全体の処理を示すフローチャートである。

【図29】第２の実施の形態における実施例Ａ１のＳ１０３０の処理を示すフローチャートである。

【図30】第２の実施の形態における実施例Ａ１のＳ１０３１の処理を示すフローチャートである。

【図31】第２の実施の形態における実施例Ａ１の表３０３１を示す図である。

【図32】第２の実施の形態における実施例Ａ１のＳ１０３２の処理を示すフローチャートである。

【図33】第２の実施の形態における実施例Ａ１のＳ１０３３の処理を示すフローチャートである。

【図34】第２の実施の形態における実施例Ａ１の表３０３２を示す図である。

【図35】第２の実施の形態における実施例Ａ１のＳ１０３４の処理を示すフローチャートである。

【図36】第２の実施の形態における実施例Ａ１の表３０３３を示す図である。

【図37】第２の実施の形態における実施例Ａ１のＳ１０３５の処理を示すフローチャートである。

【図38】第２の実施の形態における実施例Ａ１の表３０３４を示す図である。

【図39】第２の実施の形態における実施例Ａ１の表３０３５を示す図である。

【図40】第２の実施の形態における実施例Ａ１の表３０３６を示す図である。

【図41】第２の実施の形態における実施例Ａ１のＳ１０３６の処理を示すフローチャートである。

【図42】第２の実施の形態における実施例Ａ１の表３０３７を示す図である。

【図43】第２の実施の形態における実施例Ａ１のＳ１０３７の処理を示すフローチャートである。

【図44】第２の実施の形態における実施例Ａ１のＳ１０３８の処理を示すフローチャートである。

【図45】第２の実施の形態における実施例Ａ１の表３０３８を示す図である。

【図46】第２の実施の形態における実施例Ａ１のＳ１０３９の処理を示すフローチャートである。

【図47】第２の実施の形態における実施例Ａ１の表３０３９を示す図である。

【図48】第２の実施の形態における実施例Ａ１のＳ１０４０の処理を示すフローチャートである。

【図49】第２の実施の形態における実施例Ａ１のＳ１０６１の処理を示すフローチャートである。

【図50】第２の実施の形態における実施例Ａ１の表３０８１を示す図である。

【図51】第２の実施の形態における実施例Ａ１のＳ１０９１の処理を示すフローチャートである。

【図52】第２の実施の形態における実施例Ａ１のＳ１１０１の処理を示すフローチャートである。

【図53】第２の実施の形態における実施例Ａ１のＳ１１１１の処理を示すフローチャートである。

【図54】第２の実施の形態における実施例Ａ１の表３１１１を示す図である。

【図55】第２の実施の形態における実施例Ａ１の支持度の和を説明する際に参照する表である。

【図56】第２の実施の形態における実施例Ａ１の表３１１２を示す図である。

【図57】第２の実施の形態における実施例Ａ１の表３１１３を示す図である。

【図58】第２の実施の形態における実施例Ａ１のＳ１１２０の処理を示すフローチャートである。

【図59】第２の実施の形態における実施例Ａ１のＳ１１２１の処理を示すフローチャートである。

【図60】第２の実施の形態における実施例Ａ１のトレースルートの記録の例を示す図である。

【図61】第２の実施の形態における実施例Ａ１のＳ１１２２の処理を示すフローチャートである。

【図62】第２の実施の形態における実施例Ａ１のＥＣＵ型番と物理的なＥＣＵの１対１対応を示す図である。

【図63】第２の実施の形態における実施例Ａ１のネットワークインターフェースの設定を示す図である。

【図64】第２の実施の形態における実施例Ａ１のＥＣＵ情報の割り当てを示す図である。

【図65】第２の実施の形態における実施例Ａ１の接続関係を示す図である。

【図66】第２の実施の形態における実施例Ａ１のＳ１１３０の処理を示すフローチャートである。

【図67】第２の実施の形態における実施例Ａ１のＳ１１４１の処理を示すフローチャートである。

【図68】第２の実施の形態における実施例Ａ１の送信時刻と受信時刻の記録を示す図である。

【図69】第２の実施の形態における実施例Ａ１の表３１４１を示す図である。

【図70】第２の実施の形態における実施例Ａ１のＳ１１５１の処理を示すフローチャートである。

【図71】第２の実施の形態における実施例Ａ１のＳ１１５２の処理を示すフローチャートである。

【図72】第２の実施の形態における実施例Ａ１の送信時刻と受信時刻の記録を示す図である。

【図73】第２の実施の形態における実施例Ａ１の表３１５１を示す図である。

【図74】第２の実施の形態における実施例Ａ１のＳ１１６１の処理を示すフローチャートである。

【図75】第２の実施の形態における実施例Ａ１の表３１６１を示す図である。

【図76】第２の実施の形態における実施例Ａ１の表３１６２を示す図である。

【図77】第２の実施の形態における実施例Ａ１のＳ１１７１の処理を示すフローチャートである。

【図78】第２の実施の形態における実施例Ａ１のＥＣＵ型番と物理的なＥＣＵの１対１対応を示す図である。

【図79】第２の実施の形態における実施例Ａ１のＥＣＵに要求ＮＷ＿Ａ－ＩＤを追加することを示す図である。

【図80】第２の実施の形態における実施例Ａ１のＳ１１７２の処理を示すフローチャートである。

【図81】第２の実施の形態における実施例Ａ１のＮＷ＿Ａトポロジの推定結果を示す図である。

【図82】第２の実施の形態における実施例Ａ１のＮＷ＿ＡトポロジにＥＵＣ情報を追加したことを示す図である。

【図83】第２の実施の形態における実施例Ａ１のＧＷ同士の接続を示す図である。

【図84】第２の実施の形態における実施例Ａ１のＳ１１８０の処理を示すフローチャートである。

【図85】第２の実施の形態における実施例Ａ１のＳ１１９１の処理を示すフローチャートである。

【図86】第２の実施の形態における実施例Ａ１のＳ１１９２の処理を示すフローチャートである。

【図87】第２の実施の形態における実施例Ａ１のＥＣＵＲｅｓｅ送信時刻の記録を示す図である。

【図88】第２の実施の形態における実施例Ａ１のＳ１２０１の処理を示すフローチャートである。

【図89】第２の実施の形態における実施例Ａ１のＮＷ＿Ａ－ＩＤＳのアラート発報時刻の記録を示す図である。

【図90】第２の実施の形態における実施例Ａ１のＳ１２１１の処理を示すフローチャートである。

【図91】第２の実施の形態における実施例Ａ１の表３２１１を示す図である。

【図92】第２の実施の形態における実施例Ａ１の追加後の結果を示す図である。

【図93】第２の実施の形態における実施例Ａ１の表３２１２を示す図である。

【図94】第２の実施の形態における実施例Ａ２の構成図である。

【図95】第２の実施の形態における実施例Ａ３の構成図である。

【図96】第２の実施の形態における実施例Ａ４の構成図である。

【図97】第２の実施の形態における実施例Ａ５の構成図である。

【図98】第２の実施の形態における実施例Ａ６の構成図である。

【図99】第２の実施の形態における実施例Ａ７の構成図である。

【図100】第２の実施の形態における実施例Ｂ１の構成図である。

【図101】第２の実施の形態における実施例Ｂ２の構成図である。

【図102】第２の実施の形態における実施例Ｂ３の構成図である。

【図103】第２の実施の形態における実施例Ｂ４の構成図である。

【図104】第２の実施の形態における実施例Ｃ１の構成図である。

【図105】第２の実施の形態における実施例Ｃ２の構成図である。

【図106】第２の実施の形態における実施例Ｃ３の構成図である。

【図107】第２の実施の形態における実施例Ｃ４の構成図である。

【図108】装置のハードウェア構成例を示す図である。

【発明を実施するための形態】

【0012】

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

【0013】

以下で説明する本実施の形態（第１及び第２の実施の形態）では、構成情報の推定対象となる内部ネットワークを備える対象装置として、自動車を例に挙げて説明するが、本発明に係る技術を適用可能な対象装置は自動車に限定されるわけではない。本発明に係る技術は、自動車と同様に「診断通信によってネットワーク上の機器から情報を取得可能である」という特性を有する対象装置に対して適用可能である。また、第２の実施の形態で説明する要素技術については、少なくとも、その適用対象に記載の条件を持つものに適用可能である。

【0014】

本実施の形態では、車載ネットワーク（ＮＷ）の構成、ＮＷ上の情報処理装置（ＩＶＩやＴＣＵ等）に関する情報、及び電子制御装置（ＥＣＵ）に関する情報を総称して「車両構成情報」と呼称する場合がある。「車両構成情報」は、「内部ネットワークの構成情報」の例である。

【0015】

なお、ＴＣＵはTelematics Control Unitの略称であり、ＩＶＩはIn-Vehicle Infotainmentの略称であり、ＥＣＵはElectronic Control Unitの略称である。

【0016】

以下の説明（及び図面）において、ＣＡＮ（登録商標）をＮＷ＿Ａ（ネットワークＡ）と呼称し、Ｅｔｈｅｒｎｅｔ（登録商標）をＮＷ＿Ｂ（ネットワークＢ）と呼称する。なお、ＣＡＮ（登録商標）はＣｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋの略称である。

【0017】

ただし、以下の説明で登場するＮＷ＿ＡはＣＡＮ（登録商標）以外のネットワークでもよく、ＮＷ＿ＢはＥｔｈｅｒｎｅｔ（登録商標）以外のネットワークであってもよい。例えば、ＮＷ＿Ａは、ＦｌｅｘＲａｙ（登録商標）、ＬＩＮ、Ｋ－Ｌｉｎｅ等であってもよい。

【0018】

本実施の形態では、対象車両のネットワークの構成情報の推定を実現する手法について説明する。対象車両のネットワークの構成情報は例えば下記の情報である。

【0019】

・対象ネットワーク（車載ＮＷ＿Ｂと車載ＮＷ＿Ａ）のトポロジ
・ネットワークに接続している装置に関する情報（型番やソフトウェアバージョン等）
・各装置の機能（＝名称）に関する情報
・各装置が行う正常通信の情報（特に各装置が送信している正常通信の情報）
以下、本発明の実施の形態として、第１の実施の形態と第２の実施の形態を説明する。第１の実施の形態において基本的な構成と動作を説明し、第２の実施の形態ではより具体的な構成と動作を説明する。第１の実施の形態において説明する構成及び処理と、第２の実施の形態において説明する構成及び処理は、組み合わせて実施することが可能である。
――――――――――第１の実施の形態――――――――――

【0020】

（車両構成情報の例）
本実施の形態では、構成情報推定システムが自動車の車両構成情報を推定する。図１に車両構成情報の一例を示す。図１の例では、ＮＷ＿Ｂに接続されるＴＣＵとＩＶＩが、ＧＷ（Ｇａｔｅｗａｙ－ＥＣＵ）にスター型に接続されている。また、ＧＷにはＮＷ＿Ａが接続され、ＮＷ＿Ａに接続されたＥＣＵがＧＷ配下のＮＷ＿Ａにバス型に接続されている。また、図１には、各ＥＣＵ等の情報も示されている。図１に示されるＯＢＤ－ＩＩは、自己診断機能である。

【0021】

以下では、情報処理装置（ＩＶＩやＴＣＵ等）と電子制御装置（ＥＣＵ）を総称して「ＥＣＵ」と呼称する。第２の実施の形態でも同様である。

【0022】

（診断通信について）
本実施の形態では、構成情報推定システムは、自動車に搭載されているＥＣＵ等の機器において標準的にサポートされている診断通信によって得られる情報を収集・分析することで車両構成情報を推定することとしている。なお、診断通信はほとんどすべての自動車・ＥＣＵに実装されている。ここでは、その診断通信について説明する。

【0023】

診断通信は、ＥＣＵの故障診断やリプログラミングを行う際に利用される通信である。また、診断通信により、ＥＣＵの型番やソフトウェアのバージョン情報等も取得できる。診断通信の手順例を、図２を参照して説明する。図２は、外部診断機＿ＡとＥＣＵ＿Ｂとの間で診断通信を行う場合の例を示している。

【0024】

Ｓ１において、外部診断機＿ＡからＥＣＵ＿Ｂに対して診断要求を送信する。Ｓ２において、ＥＣＵ＿Ｂが診断要求に対応した処理を実行する。Ｓ３において、ＥＣＵ＿Ｂから外部診断機＿Ａに対して診断応答を送信する。診断応答には、処理の結果等が格納されている。

【0025】

（システム構成）
図３に、本実施の形態における構成情報推定システムの構成例を示す。図３に示すように、本実施の形態における構成情報推定システムは、診断通信送受信部１００、診断系ログＤＢ２００、及び構成情報推定部３００を有する。構成情報推定部３００は、ＥＣＵ存在確認部３１０、トポロジ推定部３２０、ＥＣＵ情報抽出部３３０、出力部３４０を有する。各機能部の概要は下記のとおりである。

【0026】

診断通信送受信部１００は、後述するフロー図に従って診断通信の送受信を行い、受信した応答を診断系ログＤＢ２００に格納する。

【0027】

診断系ログＤＢ２００は、診断通信送受信部１００により取得したログを予め定めた形式で格納するＤＢ（データベース）である。

【0028】

構成情報推定部３００は、後述するフロー図に従って各内部ブロックが動作することで、診断系ログＤＢ２００に格納されている情報を利用して車両構成情報を推定する。なお、構成情報推定部３００の入力には診断系ログ以外の情報を用いてもよい。例えば、構成に関する公知の情報や非診断系のログを用いてもよい。

【0029】

なお、後述する実施例１～６で説明するように、診断通信送受信部１００、診断系ログＤＢ２００、及び構成情報推定部３００は種々の形態で１つ又は複数の装置に実装することが可能である。診断通信送受信部１００と構成情報推定部３００を備える装置をネットワーク構成推定装置と呼んでもよい。このネットワーク構成推定装置において、診断通信送受信部１００と構成情報推定部３００が遠隔の離れた場所にあり、互いにネットワークを介して通信する構成であってもよい。

【0030】

また、診断通信送受信部１００で得られた応答を利用して構成情報を推定する構成情報推定部３００を備える装置をネットワーク構成推定装置と呼んでもよい。

【0031】

（診断通信送受信部の動作）
続いて、診断通信送受信部１００の動作例について説明する。まず、後述するフローに登場するＵＤＳ、ＤＩＤ、ＤｏＩＰについて説明する。

【0032】

ＵＤＳは、Unified Diagnostic Servicesの略称であり、診断通信における診断メッセージの形式等を定める標準仕様（ＩＳＯ１４２２９－１等）の名称である。

【0033】

ＤＩＤはＤａｔａ ＩＤの略称である。ＵＤＳの診断要求（リクエストメッセージ）に設定されるＩＤであり、診断サービスの対象を示す。例えば、ＤＩＤとして、ソフトウェアのバージョン番号を指定するＤＩＤが設定された診断要求がＥＣＵに送信されると、ＥＣＵは、ソフトウェアのバージョン番号を設定した診断応答（レスポンスメッセージ）を返す。

【0034】

また、ＵＤＳをＮＷ－Ａ上に実装するためのネットワーク層の仕様を規定した標準仕様として、ＤｏＣＡＮ（Diagnostic communication over Controller Area Network）と呼ばれるＩＳＯ１５７６５－２がある。

【0035】

ＤｏＩＰは、Diagnostic communication over Internet Protocolの略称であり、ＵＤＳをＩＰ上に実装するためのネットワーク層の仕様を規定した標準仕様（ＩＳＯ １３４００－１、ＩＳＯ １３４００－２）の名称である。

【0036】

ＤｏＩＰにおいては、例えば図１に示したように、診断機能（テスター）に対するゲートウェイとなるＥＣＵと、特に高速なデータ転送が求められるＥＣＵのみがＮＷ＿Ｂでの通信を行い、他のＥＣＵはＮＷ＿Ａ等の車載ネットワークでゲートウェイＥＣＵと接続され、このゲートウェイＥＣＵ経由で診断を行う構成がとられる。

【0037】

本実施の形態における診断通信送受信部１００及びＥＣＵは、少なくとも上述した一般的な標準仕様に準拠した診断通信を行う。

【0038】

図４のフローチャートを参照して、診断通信送受信部１００の動作例について説明する。なお、図４を参照して説明する動作例において送受信するメッセージの内容や順序は一例であり、これに限定されるわけではない。

【0039】

Ｓ１０１において、診断通信送受信部１００は、ＤｏＩＰのVehicle Identification RequestをＮＷ＿Ｂ接続のＥＣＵにブロードキャストし、各ＥＣＵからの応答を受信する。Vehicle Identification Requestは、ＮＷ＿Ｂに接続されたＥＣＵに対して、アドレス情報を要求するメッセージである。

【0040】

Ｓ１０２において、診断通信送受信部１００は、ＵＤＳのtesterPresentをＮＷ＿Ａ接続の各ＥＣＵに送信し、応答を受信する。testerPresentは、ＮＷ＿Ａ接続のＥＣＵの存在とＮＷ＿Ａ－ＩＤ（すなわち、ＣＡＮ－ＩＤ）を確認するためのメッセージである。

【0041】

Ｓ１０３において、診断通信送受信部１００は、ＤｏＩＰのEntity Status Requestを車載ＮＷ＿Ｂ接続の各ＥＣＵに送信し、応答を受信する。Entity Status Requestは、ＥＣＵに対して、ノードタイプ（例：ゲートウェイ）等を要求するメッセージである。

【0042】

Ｓ１０４において、診断通信送受信部１００は、ＤＩＤとして１以上の値を設定したＵＤＳのReadDataByIdentifierを、車載ＮＷ＿Ｂ接続とＮＷ＿Ａ接続の各ＥＣＵに送信し、応答を受信する。ReadDataByIdentifierは、ＥＣＵに対してＤＩＤで指定したデータを要求するメッセージである。

【0043】

Ｓ１０４で使用されるＤＩＤは、例えば、0xF181、0xF183、0xF184、0xF188、0xF189、0xF18A、0xF194、0xF195、0xF19F、0xF18B、0xF18C、0xF184、0xF191、0xF192、0xF193、0xF19Fである。ただし、これらは例であり、これらに限定されるわけではない。

【0044】

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を示す。

【0045】

（構成情報推定部の動作例）
上記のＳ１０１～Ｓ１０４においてＥＣＵに送信された要求に対して受信した応答は、診断系ログＤＢ２００に格納される。構成情報推定部３００は、診断系ログＤＢ２００からデータを読み出すことで対象装置の内部ネットワークの構成情報の推定を行う。

【0046】

以下、図５のフローチャートを参照して、構成情報推定部３００による推定及び把握の動作の例を説明する。なお、ここで説明する推定・把握の順序や内容は一例であり、ここで説明するものに限定されるわけではない。

【0047】

＜Ｓ２０１＞
Ｓ２０１において、ＥＣＵ存在確認部３１０は、ＥＣＵの存在確認を行う。具体的には下記のとおりである。

【0048】

ＥＣＵ存在確認部３１０は、ＮＷ＿Ｂ接続のＥＣＵにブロードキャストされたＤｏＩＰのVehicle Identification Requestに対しての応答から、ＮＷ＿Ｂ接続のＥＣＵの存在とそのＥＣＵのアドレス情報を確認する。つまり、Vehicle Identification Requestに対する応答として、アドレス情報を受信していれば、そのアドレス情報のＥＣＵがＮＷ＿Ｂ上に存在すると推定できる。

【0049】

また、ＥＣＵ存在確認部３１０は、ＮＷ＿Ａ接続の各ＥＣＵに送信したＵＤＳのtesterPresentに対しての応答から、ＮＷ＿Ａ接続のＥＣＵの存在とＮＷ＿Ａ－ＩＤを確認する。つまり、testerPresentに対する応答として、ＮＷ＿Ａ－ＩＤを受信していれば、そのＮＷ＿Ａ－ＩＤのＥＣＵがＮＷ＿Ａ上に存在すると推定できる。

【0050】

また、ＥＣＵ存在確認部３１０は、ＤｏＩＰのEntity Status Requestに対しての応答からＧａｔｅｗａｙ－ＥＣＵの存在とそのアドレス情報を確認する。つまり、Entity Status Requestに対しての応答として、ノードタイプがＧａｔｅｗａｙである応答を受信した場合、Ｇａｔｅｗａｙ－ＥＣＵが存在すると推定できる。

【0051】

＜Ｓ２０２＞
Ｓ２０２において、トポロジ推定部３２０は、対象装置（ここでは自動車）の内部ネットワークのトポロジの推定を行う。具体的には下記のとおりである。

【0052】

トポロジ推定部３２０は、ＮＷ＿Ｂ接続のＥＣＵが１つのＳｗｉｔｃｈにスター型に接続される構成を有すると推定する。

【0053】

例えば、トポロジ推定部３２０は、Ｓ２０１での確認結果により、１つのＧａｔｅｗａｙ－ＥＣＵ（Ｓｗｉｔｃｈとしても機能する）が存在し、ＮＷ＿Ｂ上にＥＣＵが存在することが確認されたことに基づいて、内部ネットワークは、ＮＷ＿Ｂ接続のＥＣＵが１つのＳｗｉｔｃｈにスター型に接続される構成を有すると推定する。このような推定は、例えば、予め定めたルールに基づいて行うことができる。

【0054】

また、トポロジ推定部３２０は、Ｇａｔｅｗａｙ－ＥＣＵにはＮＷ＿Ａが接続していると推定する。例えば、トポロジ推定部３２０は、Ｓ２０１での確認結果により、Ｇａｔｅｗａｙ－ＥＣＵの存在が確認され、かつ、ＮＷ＿Ａ接続のＥＣＵの存在が確認されたことに基づいて、Ｇａｔｅｗａｙ－ＥＣＵにはＮＷ＿Ａが接続されていると推定する。このような推定は、例えば、予め定めたルールに基づいて行うことができる。

【0055】

また、トポロジ推定部３２０は、ＮＷ＿Ａ接続のＥＣＵがＧａｔｅｗａｙ－ＥＣＵ配下のＮＷ＿Ａにバス型に接続されていると推定する。例えば、トポロジ推定部３２０は、Ｇａｔｅｗａｙ－ＥＣＵにはＮＷ＿Ａが接続しているという推定結果と、ＮＷ＿ＡへのＥＣＵの接続方法の公知情報（例：バス型に接続されること）に基づいて、ＮＷ＿Ａ接続のＥＣＵがＧａｔｅｗａｙ－ＥＣＵ配下のＮＷ＿Ａにバス型に接続されていると推定する。このような推定は、例えば、予め定めたルールに基づいて行うことができる。

【0056】

＜Ｓ２０３＞
Ｓ２０３において、ＥＣＵ情報抽出部３３０は、ＥＣＵ情報の抽出を行う。具体的には下記のとおりである。

【0057】

ＥＣＵ情報抽出部３３０は、ＤＩＤに0xF181、0xF183、0xF184、0xF188、0xF189、0xF18A、0xF194、0xF195、0xF19F、0xF18B、0xF18C、0xF184、0xF191、0xF192、0xF193、0xF19F（これらのＤＩＤは一例である）それぞれを設定したＵＤＳのReadDataByIdentifierに対しての応答から、各ＥＣＵにおけるＥＣＵ情報（ＶＩＮや型番、ソフトウェアバージョン等）を把握する。

【0058】

＜Ｓ２０４＞
Ｓ２０４において、出力部３４０は、Ｓ２０１～Ｓ２０３により得られた情報を出力する。例えば、出力部３４０は、Ｓ２０１～Ｓ２０３により得られた情報から、図１に示すようなグラフィカルな画像を作成し、当該画像を出力（表示）する。また、出力部３４０は、Ｓ２０１～Ｓ２０３により得られた情報をリストや自然言語の形で出力してもよい。また、自然言語の音声を出力してもよい。

【0059】

図３に示す本実施の形態における構成情報推定システムは、種々の形態で実装可能である。以下、本実施の形態における実装方法の例として実施例１～実施例６を説明する。

【0060】

（実施例１）
図６は、実施例１における構成情報推定システムの構成図である。図６に示すように、実施例１では、構成情報推定システムの全ての機能、すなわち、診断通信送受信部１００、診断系ログＤＢ２００、及び構成情報推定部３００を有する外部装置が、自動車４００に接続される。

【0061】

外部装置を自動車４００に接続する接続方法については、当該外部装置を自動車４００に物理的に接続する方法でもよいし、当該外部装置をクラウド等のネットワーク上で実現し、当該ネットワーク上の外部装置から遠隔で自動車４００に接続する方法でもよい。

【0062】

（実施例２）
図７は、実施例２における構成情報推定システムの構成図である。実施例２では、診断通信送受信部１００を備える診断通信送受信装置と、診断系ログＤＢ２００と構成情報推定部３００とを備える構成情報推定装置との２つの装置が自動車４００に接続される。

【0063】

図７の例では、診断通信送受信装置が自動車４００に物理的に接続され、構成情報推定装置がクラウド上に配置され、ネットワークを介して診断通信送受信装置に接続される構成例を示している。なお、このような接続形態は一例であり、診断通信送受信装置と構成情報推定装置の配置場所は特定のものに限定されない。

【0064】

（実施例３）
図８は、実施例３における構成情報推定システムの構成図である。実施例３は、実施例２の構成において、診断系ログＤＢ２００を診断通信送受信装置に備えた例である。

【0065】

なお、実施例２、３において、診断系ログＤＢ２００を診断通信送受信装置あるいは構成情報推定装置の内部ではなく、これらの装置の外部に配置してもよい。

【0066】

（実施例４）
図９は、実施例４における構成情報推定システムの構成図である。実施例４では、診断通信送受信部１００から構成情報推定部３００までの全ての機能を実現する処理装置が車載ＮＷ上に配置される。すなわち、図９に示すように、自動車４００の内部に、診断通信送受信部１００、診断系ログＤＢ２００、及び構成情報推定部３００を有する処理装置が備えられる。

【0067】

なお、自動車４００に備えられる上記処理装置は、車載ＮＷ内に物理的に接続する形態で配置されてもよいし、任意のＥＣＵ上で実現されてもよい。つまり、１又は複数のＥＣＵが、診断通信送受信部１００、診断系ログＤＢ２００、及び構成情報推定部３００を有してもよい。

【0068】

（実施例５）
図１０は、実施例５における構成情報推定システムの構成図である。実施例５では、車載ＮＷ上で処理を実施する処理装置を自動車４００内部に備え、外部装置が自動車４００に接続される。図１０に示すように、処理装置は診断通信送受信部１００を備え、外部装置は診断系ログＤＢ２００と構成情報推定部３００を備える。

【0069】

なお、処理装置について、当該装置を車載ＮＷ内に物理的に接続する形態で配置してもよいし、任意のＥＣＵ上で実現してもよい。また、外部装置の接続方法については、当該装置を自動車４００に物理的に接続する方法でもよいし、クラウド等のネットワーク上の装置として外部装置を備え、遠隔で自動車４００に接続する方法でもよい。

【0070】

（実施例６）
図１１は、実施例６における構成情報推定システムの構成図である。実施例６は、実施例５の構成において、診断系ログＤＢ２００を処理装置に備えた例である。

【0071】

なお、実施例５、６において、診断系ログＤＢ２００を処理装置あるいは外部装置の内部ではなく、これらの装置の外部に配置してもよい。
――――――――――第２の実施の形態――――――――――
続いて、第２の実施の形態について説明する。

【0072】

（車両構成情報の例）
第２の実施の形態においても、構成情報推定システムが自動車の車両構成情報を推定する。図１２に車両構成情報の一例を示す。図１２における車載ネットワークのトポロジ、ＥＣＵ情報（２つの表）、正常通信（右側の表の太線で囲んだ枠）の３つが車両構成情報を構成する情報である。なお、これらの情報は、後述する要素技術１～３の範囲での情報である。

【0073】

第２の実施の形態においても、第１の実施の形態と同様に診断通信を利用する。診断通信については図２を参照して説明したとおりである。

【0074】

（自動車のネットワークについて）
第２の実施の形態で前提としている自動車のネットワークを図１３に示す。図１３に示すように、本ネットワークでは、１つのＯＢＤ－ＩＩポートはＮＷ＿Ａバスと車載ＮＷ－Ｂの双方と接続する。１つのＯＢＤ－ＩＩポートから次の（１）、（２）の診断通信が可能である。

【0075】

（１）ＮＷ＿Ａのみを用いて（ＳＷを経由せず）、ＮＷ＿Ａ接続のＥＣＵと診断通信が可能である。また、ＯＢＤ－ＩＩからＧＷまで車載ＮＷ＿Ｂを利用し、ＧＷ以降でＮＷ＿Ａを利用してＮＷ＿Ａ接続のＥＣＵと診断通信を実施することも可能である。

【0076】

（２）車載ＮＷ＿Ｂ接続のＥＣＵに対しては、車載ＮＷ＿Ｂのみを用いて（ＳＷを経由して）診断通信を実施する。

【0077】

（要素技術について）
ここで、第２の実施の形態における要素技術について説明する。第２の実施の形態における要素技術は下記の（１）～（３）である。なお、（４）、（５）には第１の実施の形態で説明した技術を要素技術４、要素技術５として示している。

【0078】

（１）ＮＷ＿Ａのトポロジを推定する技術（要素技術１）
（２）ＮＷ＿Ａ接続のＥＣＵが送信する通常（非診断）ＮＷ＿Ａ－ＩＤ（０００～６ＦＦ）を特定する技術（要素技術２）
（３）各ＥＣＵの機能（＝名称）を推定する技術（要素技術３）
（４）各ＥＣＵのＥＣＵ情報を取得する技術（要素技術４）
（５）ＮＷ＿Ｂのトポロジを推定する技術（要素技術５）
以下、第２の実施の形態における要素技術１～３のそれぞれについて説明する
（要素技術１）
＜要素技術１に関する従来技術、課題＞
要素技術１に関する従来技術は、既に説明した非特許文献１に開示された技術である。前述したように、非特許文献１に開示された技術では、ＳＮＭＰを用いて対象ＮＷ内の各ＳｗｉｔｃｈのＭＡＣアドレス転送テーブルを取得し、取得した情報を解析することで対象ＮＷのＬ２トポロジを推定する。

【0079】

しかし、非特許文献１のようなＳＮＭＰベースの手法でＮＷ＿Ａバスのトポロジを取得するためには、ＳＮＭＰエージェントの動作を可能とするためのリソース増強やＳＮＭＰのサポートが各ＥＣＵで必要となり、追加のコストがかかる。

【0080】

＜要素技術１のポイント、効果＞
要素技術１においても、ほとんどの自動車において標準的に利用可能な診断通信の送受信を利用する。具体的には、特定のバスの占有率を強引増加（輻輳）させた際の、診断通信のＲＴＴを利用してＮＷ＿Ａバスのトポロジを推定する。本技術の詳細は後述する。

【0081】

診断通信プロトコルは各ＥＣＵにおいて標準的にサポートされているので、本技術により、リソースの増強や新たなプロトコルのサポートといった追加のコストをかけることなくＮＷ＿Ａバスのトポロジを推定できるようになる。

【0082】

＜要素技術１の目標、適用対象＞
要素技術１では、同一のＮＷ＿Ａバスに繋がっているＥＣＵを特定することを目標としている。例えば、図１４に示す構成の場合、下記のような情報を推定する。

【0083】

・ＥＣＵ－ＡとＥＣＵ－Ｂは同一バス接続
・ＥＣＵ－ＡとＥＣＵ－Ｃは異なるバス接続
・ＥＣＵ－ＢとＥＣＵ－Ｃは異なるバス接続
要素技術１の適用対象は、ドメインアーキテクチャを持つバスが存在するものであり、例えば図１５に示すように、ＧＷ配下に複数のバスが存在するものである。ＧＷは診断通信を適切なバスにルーティングする。例えば、ＥＣＵ－Ａに対応するＮＷ＿Ａ－ＩＤを持つ診断通信は、ＥＣＵ－Ａが接続しているバスにのみＧＷから送信される
＜要素技術１の推定方法のポイントについて＞
前述したとおり、要素技術１では、特定のバスの占有率を強引増加（輻輳）させた際の、診断通信のＲＴＴ（Round Trip Time）を利用することでＮＷ＿Ａのトポロジを推定する。

【0084】

診断通信のＲＴＴの定義を、図１６を参照して説明する。なお、図１６は、一例としてＰＣからＥＣＵ－Ａに対して診断通信を行う場合の例を示している。診断通信のＲＴＴは、診断要求（Ｓ１）をＰＣが１つのＥＣＵに送信し始めてから、そのＥＣＵからの診断応答（Ｓ２）をＰＣが受信し終わるまでの時間である。

【0085】

ここで、図１７に示すように、バス１のみ輻輳させるとする。バス１のみを輻輳させた場合、バス１に接続しているＥＣＵとの診断通信のＲＴＴは輻輳していない場合と比較して大きくなる。他方、バス２に接続しているＥＣＵとの診断通信のＲＴＴは輻輳していない場合と比較して変化しない。要素技術１では、このような事象を利用してトポロジを推定する。

【0086】

＜要素技術１の推定手順の概要＞
要素技術１の推定手順の概要について、図１８～図２０を参照して説明する。まず、図１８に示すように、ＥＣＵ－ＢとＥＣＵ－Ｃに対して診断要求を数回送信し、ＥＣＵ－ＢとＥＣＵ－ＣそれぞれのＲＴＴの平均値を調べる。図１８（及び図１９，図２０）の左下にＥＣＵ－ＢとＥＣＵ－ＣそれぞれのＲＴＴの平均値のイメージを示している。

【0087】

次に、図１９に示すように、ＥＣＵ－Ａに対して診断要求を高頻度で送信することでＥＣＵ－ＡとＥＣＵ－Ｂが接続しているバスの占有率を上げる。図１９の例では、当該バスの占有率が９９％であることが示されている。

【0088】

続いて、図２０に示すように、ＥＣＵ－Ａが接続しているバスが輻輳している状況下で、ＥＣＵ－ＢとＥＣＵ－Ｃに対して診断要求を数回送信し、ＥＣＵ－ＢとＥＣＵ－ＣのＲＴＴの平均値を調べる。

【0089】

図２０の左下に示すように、ＲＴＴの統計値の平均値が非輻輳時と比較して増加（左下図）していれば、そのＥＣＵはＥＣＵ－Ａと同一バスに接続していると判定する。図２０の例では、「ＥＣＵ－ＡとＢが同一バスに接続」と判定される。

【0090】

（要素技術２）
次に、要素技術２について説明する。

【0091】

＜要素技術２に関する従来技術、課題＞
要素技術２に関する従来技術として、「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).」がある。

【0092】

本従来技術では、ＥＣＵが送信したメッセージの衝突が一定回数異常発生すると、そのＥＣＵのメッセージ送信が停止（バスオフ）するというＮＷ＿Ａの特性を利用し、一つのＥＣＵが送信しているＮＷ＿Ａメッセージの全ＮＷ＿Ａ－ＩＤを特定する。

【0093】

従来技術による手法の具体例は下記のとおりである。

【0094】

ＮＷ＿Ａバス上のあるＥＣＵ－ＡがＮＷ＿Ａ－ＩＤ＝０ｘ３００のＮＷ＿Ａメッセージを送信するタイミングに合わせて、ＮＷ＿Ａバスに接続した推定機器からＮＷ＿Ａ－ＩＤ＝０ｘ３００のＮＷ＿Ａメッセージを送信する。

【0095】

これによりＮＷ＿Ａ－ＩＤ＝０ｘ３００のＮＷ＿Ａメッセージの衝突を発生させる。この衝突を繰り返すことで、ＥＣＵ－Ａがバスオフする。

【0096】

ＥＣＵ－Ａがバスオフすると、ＮＷ＿Ａ－ＩＤ＝０ｘ３００を含め、ＥＣＵ－Ａが送信している全てのＮＷ＿Ａ－ＩＤのＮＷ＿Ａメッセージ（例えば他に０ｘ３０１，０ｘ３０２）も停止する。

【0097】

このとき送信されなくなったＮＷ＿ＡメッセージのＮＷ＿Ａ－ＩＤを推定機器で調べることで、ＥＣＵ－Ａが送信しているＮＷ＿ＡメッセージのＮＷ＿Ａ－ＩＤを特定する。今回の例で言えば「ＥＣＵ－ＡはＮＷ＿Ａ－ＩＤ＝０ｘ３００，０ｘ３０１，０ｘ３０２のＮＷ＿Ａメッセージを送信している」ことを特定する。

【0098】

しかし、上記の従来技術には下記のような課題がある。

【0099】

車載ＮＷ＿Ａバスへのアクセス用に搭載されているＯＢＤ－ＩＩポートは、近年のほとんどの自動車において診断通信しか送受信できない設定となっている。一方で、上記の従来技術においてＮＷ＿Ａメッセージの衝突を発生させるためには非診断通信を車載ＮＷ＿Ａバスに送信できる必要がある。よって、ＯＢＤ－ＩＩポートを利用するという一般的な形態で従来技術を実施することは困難である。

【0100】

＜要素技術２のポイント、効果＞
要素技術２では、診断通信を利用して対象ＥＣＵのＮＷ＿Ａメッセージの送信周期を狂わせ、そのＮＷ＿Ａメッセージの送信周期の狂いをＮＷ＿Ａ－ＩＤＳで検知する。そして、その検知結果と対象ＥＣＵの情報を関連付けることで、そのＥＣＵが送信しているＮＷ＿ＡメッセージのＮＷ＿Ａ－ＩＤを特定する。

【0101】

本技術により、近年のほとんどの自動車を対象に、ＯＢＤ－ＩＩポートを利用する形で「ＥＣＵが送信しているＮＷ＿ＡメッセージのＮＷ＿Ａ－ＩＤ」を特定することができる
＜要素技術２の目標、適用対象＞
要素技術２では、例えば図２１に示すように、ＮＷ＿Ａ接続のＥＣＵが送信する通常ＮＷ＿Ａ－ＩＤ（０００～６ＦＦ）を診断用ＮＷ＿Ａ－ＩＤ（７００～７ＦＦ）と関連付け、延いてはＥＣＵ情報と関連付けることを目標としている。

【0102】

要素技術２では、対象ＮＷ上にＩＤＳが存在し、通常メッセージを監視していることを前提としている。当該ＩＤＳは、通常メッセージの送信時刻の間隔が設計値よりも短い／長い場合やペイロードに異常変化があった場合にアラートを発報する。ＩＤＳのアラートには、異常と検知されたメッセージの情報（自動車の例ではＮＷ＿Ａ－ＩＤ）が含まれている。また、車両構成推定装置は、ＩＤＳのアラートを何らかの方法で取得できる。

【0103】

＜要素技術２の推定方法のポイントと手順について＞
図２２を参照して、要素技術３のポイントとなる処理手順を説明する。

【0104】

（１）ＥＣＵＲｅｓｅｔ（例えばＮＷ＿Ａ－ＩＤ＝７Ｅ０で）を利用して対象ＥＣＵが送信する通常ＮＷ＿Ａ－ＩＤ（例えばＮＷ＿Ａ－ＩＤ＝３００）のメッセージ送信の周期性やペイロード変化を狂わせる。

【0105】

（２）ＮＷ＿Ａ－ＩＤＳにアラートを発報させる。例えばアラートには、ＮＷ＿Ａ－ＩＤ＝３００が含まれている。

【0106】

（３）そして「そのアラートに含まれるＮＷ＿Ａ－ＩＤは対象ＥＣＵが送信する通常ＮＷ＿Ａ－ＩＤである」と判定する。

【0107】

（要素技術３）
次に、要素技術３について説明する。

【0108】

＜要素技術３に関する従来技術、課題＞
要素技術３に関する従来技術として、「X.Feng, et al : Acquisitional Rule-based Engine for Discovering Internet-of-Things Dvices. USENIX (2018)」がある。本従来技術では、ＩｏＴ機器から収集した応答情報とＷｅｂクローリング・スクレイピング技術を活用してＩｏＴ機器の情報（機器種別・ベンダ・型番）を特定する。

【0109】

より具体的には、本従来技術では、あるＩｏＴ機器の応答から抽出したキーワードＡに対して、複数のＷｅｂクローリング・スクレイピング結果Ｂが得られる。自動車の例では、あるＥＣＵから「１２３４５－６７８９０」というＥＣＵ型番を取得できたとする。このとき、Ａ＝１２３４５－６７８９０である。そして、Ａを用いたクローリング・スクレイピング結果が図２３に示す通りであったとする。

【0110】

本従来技術では、その複数ある結果Ｂを対象に下記の確信度ｃｏｎｆ（Ａ⇒Ｂ）を算出する。

【0111】

ｃｏｎｆ（Ａ⇒Ｂ）＝（ＡとＢの双方が含まれる結果の数）／（Ａが含まれる結果の数）
そして確信度の最も高い結果を１つの結果として抽出する。図２３の例では、Ａ＝１２３４５－６７８９０、Ｂ＝Ｅｎｇｉｎｅ Ｍｏｄｕｌｅがｃｏｎｆ（Ａ⇒Ｂ）＝０．６７で抽出される。

【0112】

上記の従来技術には下記のような課題がある。

【0113】

ＥＣＵ型番全体をキーワードとしてクローリング・スクレイピングをすると、検索結果が不在によりＥＣＵの機能を推定できないことが多い。

【0114】

また、上記従来技術のように、最も確信度の高い結果を抽出する場合、情報量の少ない結果が選ばれる場合がある。例えば、図２３の場合は「Ｈｙｂｒｉｄ Ｅｎｇｉｎｅ Ｍｏｄｕｌｅ」の方が、情報量が多いため、この結果が抽出されてほしい。しかし、従来技術の場合は、図２３のようなスクレイピング結果（表）が得られた場合には、出現回数の多い「Ｅｎｇｉｎｅ Ｍｏｄｕｌｅ」が選ばれてしまう。

【0115】

＜要素技術３のポイント、効果＞
要素技術３のポイントとして、下記のポイント１、ポイント２がある。

【0116】

ポイント１は、ＥＣＵ型番の命名規則に基づいて、機能を示す桁のみを用いたスクレイピング結果も利用することである。ポイント２は、各Ｗｅｂクローリング・スクレイピング結果に含まれる単語の支持度の和が最大となる結果を抽出することである。

【0117】

本技術により、検索結果不在によるＥＣＵの機能（名称）推定不可を回避できる。また、信頼度が高く、かつ、情報量の多い結果を出力できる。

【0118】

＜要素技術３の目標、適用対象＞
要素技術３では、各ＥＣＵ（ＮＷ＿Ｂ接続含む）の機能（名称）を推定することを目標としている。例えば、図２４に示す例において、「ＥＣＵ－ＸはＩＶＩである」、「ＥＣＵ－ＹはＴＣＵである」、「ＥＣＵ－ＡはエンジンＥＣＵである」等を推定する。また、要素技術３では、機器を一意に特定する情報を取得可能であり、自動車の例でいえば「ＥＣＵ型番」を取得可能である。

【0119】

＜要素技術３の推定方法のポイントと手順について＞
まず、要素技術３の推定方法の全体像について説明する。要素技術３では、診断通信で取得した各ＥＣＵ型番とＷｅｂクローリング・スクレイピング技術を活用して機能（名称）を特定する。図２５にそのイメージを示す。以下、前述したポイント１とポイント２をより詳細に説明する。

【0120】

＜ポイント１＞
ポイント１では、ＥＣＵ型番の命名規則に基づいて、ＥＣＵ型番の機能に関する桁のみを用いたＷｅｂクローリング・スクレイピング結果も利用する。

【0121】

ＥＣＵ型番の多くは、機能情報を示す桁と車種年式を示す桁が結合された構成をとる。
機能情報を示す桁を○、車種年式を示す桁を△としたとき、例えば下記のようなＥＣＵ型番構成がある
・○○○○○－△△△△△
・△△△－○○○○○○－△
ポイント１のように機能に関する桁のみを用いることで検索結果不在が減る理由は下記のとおりである。

【0122】

「ＥＣＵ型番の全桁が一致」という条件で検索を行うことは、「指定された車種年式の車に搭載」かつ「指定された機能」のＥＣＵを検索することである。一方、「ＥＣＵ型番の機能を示す桁のみが一致」という条件で検索を行うことは、「指定された機能」のＥＣＵを検索することである。つまり、検索時の限定条件を減らすことができるため検索結果不在を減らすことができる。

【0123】

機能に関する桁の抽出方法は特定の抽出方法に限定されないが、例えば下記の抽出方法１～３のいずれかを用いることができる。

【0124】

抽出方法１）
抽出方法１では、公開されている「ＥＣＵ型番の命名規則の情報」に基づいて機能に関する桁を決定する。例えば、自動車会社のホームページ等において命名規則が公開されている場合は、その公開情報に基づいて機能に関する桁を決定する。

【0125】

抽出方法２）
抽出方法２では、とある一つの機能に関連するＥＣＵ型番のみを抽出・分析し、その分析結果に基づいて機能に関する桁を決定する。例えば、エンジンＥＣＵに関連するＥＣＵ型番のみを抽出・分析すると、どのＥＣＵ型番においても値が変化しない桁がある。その桁を機能に関する桁として決定する。

【0126】

抽出方法３）
抽出方法３では、とある一台の自動車に搭載されているＥＣＵのＥＣＵ型番を抽出・分析し、その分析結果に基づいて機能に関する桁を決定する。例えば、一台の自動車に搭載されているＥＣＵのＥＣＵ型番を抽出・分析すると、どのＥＣＵ型番においても値が変化しない桁がある。その桁は機能ではなく車種を示す桁であると考えられるため、その桁を除外した桁を機能に関する桁として決定する。

【0127】

＜ポイント２＞
要素技術３のポイント２では、各Ｗｅｂクローリング・スクレイピング結果に含まれる単語の支持度の和が最大となる結果を抽出する。具体的には下記のとおりである。

【0128】

ＥＣＵ型番が「１２３４５－６７８９０」であるＥＣＵの機能（名称）を推定する際に、図２６に示すＷｅｂクローリング・スクレイピング結果が得られたとする。図２６に含まれる単語Ｘについて下記の支持度ｓｕｐ（Ｘ）を算出する。

【0129】

ｓｕｐ（Ｘ）＝（Ｘが含まれる結果の数）／（全てのＷｅｂクローリング・スクレイピング結果の数）
そして、各行に含まれる単語の支持度の和を各行で算出し、その和が最大の結果を１つの結果として抽出する。図２６の例では、Ｈｙｂｒｉｄ Ｅｎｇｉｎｅ Ｍｏｄｕｌｅが抽出される。ここで、ｓｕｐ（Ｅｎｇｉｎｅ）＝１、ｓｕｐ（Ｍｏｄｕｌｅ）＝１、ｓｕｐ（Ｈｙｂｒｉｄ）＝０．３、和＝２．３である。

【0130】

（実施例）
以下、第２の実施の形態における具体的な装置構成、及び動作を実施例として説明する。各実施例の概要は下記のとおりである。

【0131】

Ａ．要素技術の組み合わせの観点での実施例の列挙
・実施例Ａ１：最も基本的な要素技術の組み合わせでの実施例（処理フローの詳細を説明）
・実施例Ａ２～Ａ４：各要素技術を単体で利用する実施例
・実施例Ａ５～Ａ７：要素技術を部分的に組み合わせる実施例
Ｂ．物理的な機能配備の観点での実施例の列挙
・実施例Ｂ１：本発明に係る機能を車載ＮＷ上に配備する実施例
・実施例Ｂ２：本発明に係る機能をＯＢＤ－ＩＩポートに直接接続する実施例
・実施例Ｂ３：本発明に係る機能を充電ポートから実施する例
なおＢ１～Ｂ３は、後述する車載ＮＷ１とメッセージ送受信部２３以外を切り出してクラウド上に配備しても良い。

【0132】

・実施例Ｂ４：外部ネットワーク上に配備した本発明に係る機能により推定を実施する例
Ｃ．目的の観点での実施例の列挙
・実施例Ｃ１：ＳＯＣ（Security Operation Center）等でのセキュリティ分析に活用する実施例
・実施例Ｃ２：アセット管理に活用する実施例
・実施例Ｃ３：異常検知を実施する実施例
・実施例Ｃ４：セキュリティ診断に活用する実施例
なお、実際に実施する際は上記ＡとＢの実施例を組み合わせる。例えば、実施例Ａ１を実施例Ｂ１の機能配備で実施する等である。そしてそれをＣに記載の目的のために使用する。以下、各実施例を説明する。

【0133】

（実施例Ａ１）
実施例Ａ１は、コア技術の最も基本的な組み合わせでの実施例である。ここでは、一例として、実施例Ｂ２の物理配備を想定して説明する。

【0134】

＜装置構成（ブロック図）＞
図２７に、実施例Ａ１における構成情報推定システムの構成図を示す。図２７に示すように、構成情報推定システムは、構成要素推定部２と構成情報推定結果ＤＢ２２を備える。構成要素推定部２を、車両構成推定装置あるいはネットワーク構成推定装置と呼んでもよい。構成情報推定システムを構成情報推定装置と呼んでもよい。構成要素推定部２は、車載ＮＷ１とＷｅｂサイト７（Ｗｅｂサーバ）に接続され、これらと通信可能である。

【0135】

構成要素推定部２は、ＥＣＵ基本情報取得部３、ＥＣＵ機能推定部４、ＮＷ＿Ｂトポロジ推定部１２、ＮＷ＿Ａバストポロジ推定部１３、正常ＮＷ＿Ａ通信推定部１８、メッセージ送受信部２３，構成情報取得・登録部２４を備える。

【0136】

ＥＣＵ機能推定部４は、Ｗｅｂ検索部６、検索結果ＤＢ８、完全一致抽出部９、特定部分一致抽出部１０、推定部１１を備える。なお、「完全一致抽出部９、特定部分一致抽出部１０、推定部１１」をまとめて推定部と呼んでもよい。

【0137】

ＮＷ＿Ａバストポロジ推定部１３は、ベースＲＴＴ算出部１４，輻輳ＲＴＴ算出部１５、ＲＴＴ比較部１６、推定部１７を備える。なお、「ＲＴＴ比較部１６、推定部１７」をまとめて推定部と呼んでもよい。

【0138】

正常ＮＷ＿Ａ通信推定部１８は、再起動命令送信部１９、車両アラート受信部２０、及び推定部２１を備える。

【0139】

以下、フローチャートを参照して装置動作を説明する。以下の説明において、なお、車載ＮＷ１や車載ＥＣＵへのメッセージ送受信は、メッセージ送受信部２３を経由して実施する。

【0140】

＜全体の処理の流れ＞
図２８を参照して、構成情報推定システムの全体の処理の流れを説明する。なお、図２８に示す処理の順番は一例である。

【0141】

Ｓ１０３０において、ＥＣＵ基本情報取得部３がＥＣＵ基本情報を取得する。Ｓ１０４０において、ＥＣＵ機能推定部４がＥＣＵ機能を推定する。Ｓ１１２０において、ＮＷ＿Ｂトポロジ推定部１２が、ＮＷ＿Ｂのトポロジを推定する。Ｓ１１３０において、ＮＷ＿Ａバストポロジ推定部１３が、ＮＷ＿Ａバストポロジを推定する。Ｓ１１８０において、正常ＮＷ＿Ａ通信推定部１８が、正常ＮＷ＿Ａ通信の推定を行う。

【0142】

以下、個々のステップの処理内容を詳細に説明する。

【0143】

＜Ｓ１０３０＞
Ｓ１０３０について、図２９を参照して説明する。

【0144】

Ｓ１０３０－１において、車両構成推定装置を車載ＮＷ１のＯＢＤ－ＩＩポート（ＮＷ＿Ｂ）に接続する
Ｓ１０３０－２において、ＥＣＵ基本情報取得部３は、Ｓ１０３１を実行する。Ｓ１０３０－３において、ＥＣＵ基本情報取得部３は、Ｓ１０３２を実行する。Ｓ１０３２において、Ｓ１０３３とＳ１０３４も実行する。

【0145】

Ｓ１０３０－４において、ＥＣＵ基本情報取得部３は、Ｓ１０３５を実行する。Ｓ１０３０－５において、ＥＣＵ基本情報取得部３は、車両構成推定装置をＯＢＤ－ＩＩポート（ＮＷ＿Ｂ）から切断し、ＯＢＤ－ＩＩポート（ＮＷ＿Ａ）に接続する。

【0146】

Ｓ１０３０－６において、ＥＣＵ基本情報取得部３は、Ｓ１０３６を実行する。Ｓ１０３０－７において、ＥＣＵ基本情報取得部３は、Ｓ１０３７を実行する。Ｓ１０３７において、Ｓ１０３８も実行する。Ｓ１０３０－８において、ＥＣＵ基本情報取得部３は、Ｓ１０３９を実行する。

【0147】

＜Ｓ１０３１＞
次に、Ｓ１０３１の処理を、図３０を参照して説明する。

【0148】

Ｓ１０３１－１において、ＥＣＵ基本情報取得部３は、ＤｏＩＰの規定に従い、ＡｕｔｏＩＰもしくはＤＨＣＰにより車載ＮＷ１上のローカルＩＰアドレスを取得する。

【0149】

Ｓ１０３１―２において、ＥＣＵ基本情報取得部３が、ＤｏＩＰの規定に従って車載ＮＷ１上の各ＥＣＵがブロードキャストするＶｅｈｉｃｌｅ Ａｎｎｏｕｎｃｅｍｅｎｔを受信した場合はＳ１０３１－５に進み、受信しない場合はＳ１０３１－３に進む。

【0150】

Ｓ１０３１－３において、ＥＣＵ基本情報取得部３は、車載ＮＷ１上にＶｅｈｉｃｌｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ（ＤｏＩＰで規定）をブロードキャストする。

【0151】

Ｓ１０３１－４において、車載ＮＷ１上の各ＥＣＵはＤｏＩＰの既定に従い、Ｖｅｈｉｃｌｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔに対してＶｅｈｉｃｌｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅを応答する。ＥＣＵ基本情報取得部３は、そのＶｅｈｉｃｌｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅを受信する。

【0152】

Ｓ１０３１－５において、ＥＣＵ基本情報取得部３は、受信したＶｅｈｉｃｌｅ ＡｎｎｏｕｎｃｅｍｅｎｔやＶｅｈｉｃｌｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅに含まれる送信元ＩＰアドレスなどの情報をメモリ等の記憶手段に記録する。記録した情報を図３１（表３０３１）に示す。なお、記録する情報は表３０３１のものに限らない。

【0153】

＜Ｓ１０３２＞
次に、図３２を参照してＳ１０３２の処理について説明する。Ｓ１０３２－１において、ＥＣＵ基本情報取得部３は、下記の変数を宣言する。

【0154】

・前のステップ（Ｓ１０３１）で記憶した表３０３１のＩＰアドレスのリスト"ＩＰ＝［１９２．１６８．１０．１，１９２．１６８．１０．２，１９２．１６８．１０．３］"
・ＩＰリストの長さ"Ｌｅｎｇｔｈ（ＩＰ）"（本例の場合、Ｌｅｎｇｔｈ（ＩＰ）＝３）
・"ＤＩＤ＝［０ｘＦ１８Ｃ，０ｘＦ１９０，０ｘＦ１９１，０ｘＦ１９４，０ｘＦ１９５，０ｘＦ１９Ｆ］"
・ＤＩＤの長さ"Ｌｅｎｇｔｈ（ＤＩＤ）"（本例の場合Ｌｅｎｇｔｈ（ＤＩＤ）＝６）
・ｉ＝０
なお、変数名は上記以外でも良い。また、ＩＰの中身をＩＰアドレス以外の値で統一しても良い。ＤＩＤには上記以外の値を追加しても良い
Ｓ１０３２―２において、ＥＣＵ基本情報取得部３は、ｉ＜Ｌｅｎｇｔｈ（ＩＰ）であるか否かを判断し、ＹｅｓであればＳ１０３２－３に進み、Ｎｏであれば処理を終了する。

【0155】

Ｓ１０３２－３において、ＥＣＵ基本情報取得部３は、Ｓ１０３３の処理を実行する。Ｓ１０３２－４において、ＥＣＵ基本情報取得部３は、Ｓ１０３４の処理を実行する。Ｓ１０３２―５において、ｉ＝ｉ＋１とし、Ｓ１０３２－２に戻る。

【0156】

＜Ｓ１０３３＞
次に、図３３を参照してＳ１０３３の処理について説明する。Ｓ１０３３－１において、ＥＣＵ基本情報取得部３は、車載ＮＷ１上のＩＰ［ｉ］に対してＤｏＩＰ Ｅｎｔｉｔｙ Ｓｔａｔｕｓ Ｒｅｑｕｅｓｔを送信する。

【0157】

Ｓ１０３３－２において、車載ＮＷ１上のＩＰ［ｉ］を持つＥＣＵはＤｏＩＰの既定に従い、ＤｏＩＰ Ｅｎｔｉｔｙ Ｓｔａｔｕｓ Ｒｅｑｕｅｓｔに対してＤｏＩＰ Ｅｎｔｉｔｙ Ｓｔａｔｕｓ Ｒｅｓｐｏｎｓｅを応答する。ＥＣＵ基本情報取得部３は、そのＤｏＩＰ Ｅｎｔｉｔｙ Ｓｔａｔｕｓ Ｒｅｓｐｏｎｓｅを受信する。

【0158】

Ｓ１０３３－３において、ＥＣＵ基本情報取得部３は、受信したＤｏＩＰ Ｅｎｔｉｔｙ Ｓｔａｔｕｓ Ｒｅｓｐｏｎｓｅに含まれる「Ｎｏｄｅ ｔｙｐｅ」とＩＰ［ｉ］を記憶手段に記録する。記録した情報の例を図３４（表３０３２）に示す。

【0159】

＜Ｓ１０３４＞
次に、図３５を参照してＳ１０３４の処理について説明する。Ｓ１０３４－１において、ＥＣＵ基本情報取得部３は、変数ｊ＝０を宣言する。なお、変数名はｊ以外でも良い。Ｓ１０３４－２において、ＥＣＵ基本情報取得部３は、ｊ＜Ｌｅｎｇｔｈ（ＤＩＤ）を満たすか否かを判断し、ＹｅｓであればＳ１０３４－３に進み、Ｎｏであれば処理を終了する。

【0160】

Ｓ１０３４－３において、ＥＣＵ基本情報取得部３は、ＤＩＤにＤＩＤ［ｊ］を設定したｒｅａｄＤａｔａＢｙＩｄｅｎｔｉｆｉｅｒ（ＵＤＳで規定）をＩＰ［ｉ］に送信し、応答を受信する。Ｓ１０３４－４において、ＥＣＵ基本情報取得部３は、受信した応答のｄａｔａＲｅｃｏｒｄをＩＰ［ｉ］とＤＩＤ［ｊ］とともに記憶手段に記録する。記録した情報の例を図３６（表３０３３）に示す。Ｓ１０３４－５において、ＥＣＵ基本情報取得部３は、ｊ＝ｊ＋１とし、Ｓ１０３４－２に戻る。

【0161】

＜Ｓ１０３５＞
次に、図３７を参照してＳ１０３５を説明する。Ｓ１０３５－１において、ＥＣＵ基本情報取得部３は、図３６（表３０３３）のＤＩＤをＵＤＳの規定に基づいて「説明」に変更し、ｄａｔａＲｅｃｏｒｄをＡＳＣＩＩ（１６進数）→文字列変換する。図３６（表３０３３）を変更・変換後の結果は図３８（表３０３４）の通りである。なお、説明の内容やｄａｔａＲｅｃｏｒｄの変換方法はこれに限らない。

【0162】

Ｓ１０３５－２において、ＥＣＵ基本情報取得部３は、図３８（表３０３４）のデータを「ＩＰアドレス」と「ＥＣＵ型番」を複合主キーとして整理する。整理した結果は図３９（表３０３５）に示す通りである。なお、まとめ方はこれに限らない。

【0163】

Ｓ１０３５－３において、ＥＣＵ基本情報取得部３は、図３９（表３０３５）と図３１（表３０３１）と図３４（表３０３２）を「ＩＰアドレス」をキーとして結合する。その結果は図４０（表３０３６）に示す通りである。

【0164】

Ｓ１０３５－４において、ＥＣＵ基本情報取得部３は、図４０（表３０３６）の結合結果を、構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２に格納する。

【0165】

＜Ｓ１０３６＞
次に、Ｓ１０３６を、図４１を参照して説明する。Ｓ１０３６－１において、ＥＣＵ基本情報取得部３は、ＤｏＣＡＮとＵＤＳの規定に従い、診断用ＮＷ＿Ａ－ＩＤ＝０ｘ７００～０ｘ７ＦＦや診断用の拡張ＮＷ＿Ａ－ＩＤ（以降、これらを単に「ＮＷ＿Ａ－ＩＤ」と総称）のすべてに対して順々にＴｅｓｔｅｒＰｒｅｓｅｎｔ要求を送信する。

【0166】

Ｓ１０３６－２において、ＥＣＵ基本情報取得部３は、前のステップでＴｅｓｔｅｒＰｒｅｓｅｎｔ要求を送信した際に対しての応答が車載ネットワーク上で発生すれば、自身が送信したＮＷ＿Ａ－ＩＤ（要求ＮＷ＿Ａ－ＩＤ）などを記憶手段に記録する。例えば、ＮＷ＿Ａ－ＩＤ ＝ ７００を設定したＴｅｓｔｅｒＰｒｅｓｅｎｔを送信した際に応答があれば、ＮＷ＿Ａ－ＩＤ＝７００や応答に設定されているＮＷ＿Ａ－ＩＤ（応答ＮＷ＿Ａ－ＩＤ）を記録する。その結果は図４２（表３０３７）に示す通りである。

【0167】

＜Ｓ１０３７＞
次に、Ｓ１０３７を、図４３を参照して説明する。Ｓ１０３７－１において、ＥＣＵ基本情報取得部３は、下記の変数を宣言する。

【0168】

・前のステップで記録した図４２（表３０３７）の要求ＮＷ＿Ａ－ＩＤリスト"ＮＷ＿Ａ－ＩＤ＝［０ｘ７００，０ｘ７２４，０ｘ７５０，０ｘ７Ｅ０，０ｘ７Ｅ１］"
・リストの長さ"Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）"（本例の場合はＬｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）＝５）
・"ＤＩＤ ＝［０ｘＦ１８Ｃ，０ｘＦ１９０，０ｘＦ１９１，０ｘＦ１９４，０ｘＦ１９５， ０ｘＦ１９Ｆ］"
・ＤＩＤの長さ"Ｌｅｎｇｔｈ（ＤＩＤ）"（本例の場合はＬｅｎｇｔｈ（ＤＩＤ）＝６）
・ｉ＝０
なお、変数名は上記以外でも良い。また、ＮＷ＿Ａ－ＩＤの中身をＮＷ＿Ａ－ＩＤ以外の値で統一しても良い。ＤＩＤには上記以外の値を追加しても良い
Ｓ１０３７－２において、ｉ＜Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）を満たすかどうかを確認し、ＹｅｓであればＳ１０３７－３に進み、Ｎｏであれば処理を終了する。Ｓ１０３７―３において、ＥＣＵ基本情報取得部３は、Ｓ１０３８を実行する。Ｓ１０３７－４において、ｉ＝ｉ＋１としてＳ１０３７－２に戻る。

【0169】

＜Ｓ１０３８＞
次に、図４４を参照してＳ１０３８について説明する。Ｓ１０３８－１において、ＥＣＵ基本情報取得部３は、変数ｊ＝０を宣言する。なお、変数名はｊ以外でも良い。

【0170】

Ｓ１０３８－２において、ＥＣＵ基本情報取得部３は、ｊ＜Ｌｅｎｇｔｈ（ＤＩＤ）を満たすかどうか判断する。ＹｅｓであればＳ１０３８－３に進み、Ｎｏであれば処理を終了する。

【0171】

Ｓ１０３８―３において、ＥＣＵ基本情報取得部３は、ＤＩＤにＤＩＤ［ｊ］を設定したｒｅａｄＤａｔａＢｙＩｄｅｎｔｉｆｉｅｒ（ＵＤＳで規定）をＮＷ＿Ａ－ＩＤ［ｉ］に送信し、応答を受信する。

【0172】

Ｓ１０３８―４において、ＥＣＵ基本情報取得部３は、受信した応答のｄａｔａＲｅｃｏｒｄをＮＷ＿Ａ－ＩＤ［ｉ］（要求ＮＷ＿Ａ－ＩＤ）と応答ＮＷ＿Ａ－ＩＤ、ＤＩＤ［ｊ］とともに記憶手段に記録する。記録した情報の例を図４５（表３０３８）に示す。Ｓ１０３８－５において、ｊ＝ｊ＋１としてＳ１０３８－２に戻る。

【0173】

＜Ｓ１０３９＞
次に、図４６を参照してＳ１０３９について説明する。Ｓ１０３９－１において、ＥＣＵ基本情報取得部３は、図４５（表３０３８）のＤＩＤをＵＤＳの規定に基づいて「説明」に変更し、ｄａｔａＲｅｃｏｒｄをＡＳＣＩＩ（１６進数）→文字列変換する。なお、説明の内容やｄａｔａＲｅｃｏｒｄの変換方法はこれに限らない。

【0174】

Ｓ１０３９－２において、ＥＣＵ基本情報取得部３は、前ステップのデータを「ＮＷ＿Ａ－ＩＤ」と「ＥＣＵ型番」を複合主キーとして整理する。整理した結果は図４７（表３０３９）に示す通りである。なお、まとめ方はこれに限らない。

【0175】

Ｓ１０３９－３において、ＥＣＵ基本情報取得部３は、図４７（表３０３９）の整理結果を構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２に渡す。

【0176】

＜Ｓ１０４０＞
次に、図４８を参照してＳ１０４０について説明する。Ｓ１０４０－１において、ＥＣＵ機能推定部４は、下記の変数を宣言する。

【0177】

・構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２から取得した、図４０（表３０３６）と図４７（表３０３９）の重複のないＥＣＵ型番のリスト
・"ＰＮ＝［１１１１１－５６７８９，２２２２２－５６７８９，３３３３３－５６７８９，４４４４４－５６７８９，５５５５５－５６７８９，６６６６６－５６７８９，７７７７７－５６７８９，８８８８８－５６７８９］"
・ＰＮリストの長さ"Ｌｅｎｇｔｈ（ＰＮ）"（本例の場合はＬｅｎｇｔｈ（ＰＮ）＝８）
・ｉ＝０
なお、変数名は上記以外でも良い。また、ＩＰの中身をＩＰアドレス以外の値で統一しても良い。

【0178】

Ｓ１０４０－２において、ＥＣＵ機能推定部４は、ｉ＜Ｌｅｎｇｔｈ（ＰＮ）を満たすかどうかを判断し、ＹｅｓであればＳ１０４０－３に進み、Ｎｏであれば処理を終了する。Ｓ１０４０－３において、ＰＮ［ｉ］についてＳ１０６１を実施し、Ｓ１０４０－４において、ＰＮ［ｉ］についてＳ１０９１を実施し、Ｓ１０４０－５において、ＰＮ［ｉ］についてＳ１１０１を実施し、Ｓ１０４０－６において、ＰＮ［ｉ］についてＳ１１１１を実施する。Ｓ１０４０－７においてｉ＝ｉ＋１としてＳ１０４０－２に戻る。

【0179】

＜Ｓ１０６１＞
次に、図４９を参照してＳ１０６１について説明する。Ｓ１０６１－１において、Ｗｅｂ検索部６は、構成情報推定結果ＤＢ２２から取得したＥＣＵ型番を検索ワードとして利用しＷｅｂページをクローリングする。このときクローリングするＷｅｂページは、ＥＣＵの型番からＥＣＵの機能（＝名称）を検索するのにふさわしいＷｅｂサイトが好ましい。また、検索ワードとしてＥＣＵ型番全体と、ＥＣＵ型番の機能に関する桁の２種類を用いる。

【0180】

なお、ＥＣＵ型番の機能に関する桁については、要素技術３のポイント１の説明のところで述べた手法などにより特定する。なお、特定手法はそれに限定しない。

【0181】

Ｓ１０６１－２において、Ｗｅｂ検索部６は、前のステップでクローリングしたＷｅｂページからＥＣＵ型番とそのＥＣＵ型番に対応する機能のペア情報をスクレイピングする。

【0182】

Ｓ１０６１－３において、Ｗｅｂ検索部６は、ペア情報を過去の検索結果ＤＢ８に格納する。なお、過去の検索結果ＤＢ８は、例えば図５０（表３０８１）のようなＤＢ構造を持つ
＜Ｓ１０９１＞
次に、図５１を参照してＳ１０９１を説明する。Ｓ１０９１において、完全一致抽出部９は、検索結果ＤＢ８からＥＣＵ型番が完全に一致するペア情報を取得する。

【0183】

＜Ｓ１１０１＞
次に、図５２を参照してＳ１１０１を説明する。Ｓ１１０１において、特定部分一致抽出部１０は、検索結果ＤＢ８からＥＣＵ型番の機能に関する桁が一致するペア情報を取得する。

【0184】

＜Ｓ１１１１＞
次に、図５３を参照してＳ１１１１を説明する。Ｓ１１１１－１において、推定部１１は、上記のステップにより取得したペア情報のうち、機能の情報を単語ごとに分割する。例えば「Ｇｅｎｕｉｎｅ Ｅｎｇｉｎｅ Ｃｏｎｔｒｏｌ Ｍｏｄｕｌｅ」という機能の情報を持つペア情報が得られた場合、これを「Ｇｅｎｕｉｎｅ」「Ｅｎｇｉｎｅ」「Ｃｏｎｔｒｏｌ」「Ｍｏｄｕｌｅ」の４つに分割する。

【0185】

Ｓ１１１１－２において、推定部１１は、前のステップで分割した単語のうち、機能に関係ない頻出単語を削除する。例えば、前のステップの例で言うと「Ｇｅｎｕｉｎｅ」を削除する。なお、削除しなくても良い。

【0186】

Ｓ１１１１－３において、推定部１１は、分割した各単語の支持度を算出する。具体的には、単語ｘの支持度は下記の式で計算される。支持度の計算結果例を図５４（表３１１１）に示す。

【0187】

支持度（ｘ）＝（ｘを含むペア情報の数）／（全ペア情報の数）
Ｓ１１１１－４において、推定部１１は、各ペア情報の機能の情報に含まれる単語の支持度の和を計算する。そして和が最も大きいペア情報を出力する。なお、和以外に、平均や積が最大の物を選んでも良い。

【0188】

一例として、図５５に示す支持度の例に基づく和を算出する過程と結果を以下に示す。

【0189】

１．Ｇａｓ Ｍｏｔｏｒ Ｍｏｄｕｌｅ
和＝０．２５＋０．５＋１．０＝１．７５
２．Ｅｎｇｉｎｅ Ｍｏｔｏｒ Ｃｏｎｔｒｏｌ Ｍｏｄｕｌｅ
和＝０．７５＋０．５＋０．７５＋１．０＝３．０
３．Ｅｎｇｉｎｅ Ｃｏｎｔｒｏｌ Ｍｏｄｕｌｅ
和＝０．７５＋０．７５＋１．０＝２．５
４．Ｅｎｇｉｎｅ Ｃｏｎｔｒｏｌ Ｍｏｄｕｌｅ
和＝０．７５＋０．７５＋１．０＝２．５
２の情報が最大値を持つので、２のペア情報を出力する。なお、図５５の基となったペア情報の機能の情報は下記のとおりである。

【0190】

１．Ｇａｓ Ｍｏｔｏｒ Ｍｏｄｕｌｅ
２．Ｅｎｇｉｎｅ Ｍｏｔｏｒ Ｃｏｎｔｒｏｌ Ｍｏｄｕｌｅ
３．Ｅｎｇｉｎｅ Ｃｏｎｔｒｏｌ Ｍｏｄｕｌｅ
４．Ｅｎｇｉｎｅ Ｃｏｎｔｒｏｌ Ｍｏｄｕｌｅ
Ｓ１１１１―５において、推定部１１は、以下で説明するラベル付けした結果を、構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２の図４０（表３０３６）もしくは図４７（表３０３９）の適切なＥＣＵ型番を持つ行に追加する。その結果の例を図５６（表３１１２）と図５７（表３１１３）に示す。ラベル付けに関しては下記のとおりである。

【0191】

検索結果ＤＢ８から取得した「ＥＣＵ型番が完全に一致するペア情報」を本処理で利用する場合は、ＥＣＵ型番が完全に一致するペア情報のみを利用して処理を行う。そして、出力結果には「完全一致」というラベルを付ける。一方、検索結果ＤＢ８から取得した「ＥＣＵ型番の特定部分が一致するペア情報」を本処理で利用する場合は、ＥＣＵ型番の特定部分が一致するペア情報のみを利用して処理を行う。そして、出力結果には「部分一致」というラベルを付ける。

【0192】

＜Ｓ１１２０＞
次に、Ｓ１１２０について図５８を参照して説明する。Ｓ１１２０－１において、ＮＷ＿Ｂトポロジ推定部１２は、Ｓ１１２１を実行する。Ｓ１１２０－２において、ＮＷ＿Ｂトポロジ推定部１２は、Ｓ１１２２を実行する。

【0193】

＜Ｓ１１２１＞
次に、図５９を参照してＳ１１２１を説明する。Ｓ１１２１－１において、ＮＷ＿Ｂトポロジ推定部１２は、下記の変数を宣言する。

【0194】

・構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２から取得した、図５４（表３１１１）のＩＰアドレスのリスト"ＩＰ＝［１９２．１６８．１０．１，１９２．１６８．１０．２，１９２．１６８．１０．３］"
・ＩＰリストの長さ"Ｌｅｎｇｔｈ（ＩＰ）"（本例の場合はＬｅｎｇｔｈ（ＩＰ）＝３）
・ｉ＝０
なお、変数名は上記以外でも良い。また、ＩＰの中身をＩＰアドレス以外の値で統一しても良い。

【0195】

Ｓ１１２１－２において、ＮＷ＿Ｂトポロジ推定部１２は、ｉ＜Ｌｅｎｇｔｈ（ＩＰ）を満たすか否かを判断し、ＹｅｓであればＳ１１２１－３に進み、Ｎｏであれば処理を終了する。

【0196】

Ｓ１１２１－３において、ＮＷ＿Ｂトポロジ推定部１２は、車載ＮＷ１上のＩＰ［ｉ］に対してＩＣＭＰのｔｒａｃｅｒｏｕｔｅを実行し、結果を記憶手段に記録する。記録される情報の例を図６０に示す。Ｓ１１２１－４において、ｉ＝ｉ＋１とし、Ｓ１１２１－２に戻る。

【0197】

＜Ｓ１１２２＞
図６１を参照してＳ１１２２について説明する。

【0198】

Ｓ１１２２－１において、ＮＷ＿Ｂトポロジ推定部１２は、構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２の図５６（表３１１２）からすべてのＥＣＵ型番を取り出す。次に、ＮＷ＿Ｂトポロジ推定部１２は、取り出したＥＣＵ型番の重複を削除する。そして、重複が削除されたＥＣＵ型番と物理的なＥＣＵを１対１対応させる。結果の例を図６２に示す。

【0199】

Ｓ１１２２－２において、ＮＷ＿Ｂトポロジ推定部１２は、構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２から取得した、図５６（表３１１２）の「ＥＣＵ型番」と「ＭＡＣアドレス」と「ＩＰアドレス」に基づいて、ネットワークインターフェースを図６２の情報に追加する。その結果は図６３に示すとおりである。

【0200】

Ｓ１１２２－３において、ＮＷ＿Ｂトポロジ推定部１２は、構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２から取得した、図５６（表３１１２）のすべての情報をＥＣＵやＥＣＵのインターフェースに適切に割り当てる。その結果は図６４に示す通りである。

【0201】

Ｓ１１２２－４において、ＮＷ＿Ｂトポロジ推定部１２は、ｔｒａｃｅｒｏｕｔｅの記録（図６２）を基に、ＯＢＤ－ＩＩポートとＥＣＵのネットワークインターフェース（延いては物理的なＥＣＵ）とＩＰルータのＮＷ＿Ｂケーブルによる接続関係を整理する。なお、同一ＩＰルータの配下に複数のＥＣＵが存在する場合は、それらのＥＣＵとＩＰルータが一つのＮＷ＿Ｂ ｓｗｉｔｃｈで接続されていると推定する。また、複数のＥＣＵが車載ネットワークに存在するが、ＩＰルータが存在しない場合も、それらのＥＣＵが一つのＮＷ＿Ｂ ｓｗｉｔｃｈで接続されていると推定する。その結果は図６５に示すとおりである。なお、ＥＣＵ同士の接続関係の整理方法はこれに限るものではない。

【0202】

Ｓ１１２２－５において、ＮＷ＿Ｂトポロジ推定部１２は、図６５の推定結果を構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２に格納する。

【0203】

＜Ｓ１１３０＞
次に、図６６を参照して、ＮＷ＿Ａバストポロジ推定部１３によるＳ１１３０について説明する。

【0204】

Ｓ１１３０－１において、ベースＲＴＴ算出部１４がＳ１１４１を実行する。Ｓ１１３０－２において、輻輳ＲＴＴ算出部１５がＳ１１５１を実行する。Ｓ１１３０－３において、輻輳ＲＴＴ算出部１５がＳ１１５２を実行する。Ｓ１１３０－４において、ＲＴＴ比較部１６がＳ１１６１を実行する。Ｓ１１３０－５において、推定部１７がＳ１１７１を実行する。Ｓ１１３０－６において、推定部１７がＳ１１７２を実行する。

【0205】

＜Ｓ１１４１＞
次に、図６７を参照してＳ１１４１について説明する。

【0206】

Ｓ１１４１―１において、ベースＲＴＴ算出部１４は、ＮＷ＿Ａ－ＩＤ［ｉ］に対してＵＤＳで規定されるＴｅｓｔｅｒＰｒｅｓｅｎｔ要求を２００ｍｓ間隔で１００回送信する。そして、それに対しての応答を受信する。さらに、それらの送信時刻と受信時刻を記憶手段に記録する。記録した情報の例を図６８に示す。なお、送信間隔や送信回数はこれに限らない。

【0207】

Ｓ１１４１―２において、ベースＲＴＴ算出部１４は、前のステップの記録（図６８）を用いて応答時間（以降、ペース応答時間と呼称）の統計値を算出する。そしてその結果をＮＷ＿Ａ－ＩＤ［ｉ］とともに記録する（例：図６９（表３１４１））。なお、要求ＮＷ＿Ａ－ＩＤ（図６８で言えば０ｘ７００）でＴｅｓｔｅｒＰｒｅｓｅｎｔを送信した時刻と、その直後に応答ＮＷ＿Ａ－ＩＤ（図６８で言えば０ｘ７０８）でＴｅｓｔｅｒＰｒｅｓｅｎｔを受信した時刻の差をベース応答時間とする。また、統計値として平均値・最大値、最小値、標準偏差を算出する。ただし、その他の統計値を算出しても良い。

【0208】

＜Ｓ１１５１＞
次に、図７０を参照してＳ１１５１について説明する。

【0209】

Ｓ１１５１－１において、輻輳ＲＴＴ算出部１５は、下記の変数を宣言する。

【0210】

・構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２から取得した、図５７（表３１１３）の要求ＮＷ＿Ａ－ＩＤを昇順にしたリスト"ＮＷ＿Ａ－ＩＤ＝［０ｘ７００，０ｘ７２４，０ｘ７５０，０ｘ７Ｅ０，０ｘ７Ｅ１］"
・リストの長さ"Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）"（本例の場合はＬｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）＝５）
・ｉ＝０
なお、変数名は上記以外でも良い。また、ＮＷ＿Ａ－ＩＤの中身をＮＷ＿Ａ－ＩＤ以外の値で統一しても良い。

【0211】

Ｓ１１５１－２において、輻輳ＲＴＴ算出部１５は、ｉ＜Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）を満たすか否かを判断する。ＹｅｓであればＳ１１５１－２に進み、Ｎｏであれば処理を終了する。Ｓ１１５１－３において、ｊ＝ｉ＋１とする。

【0212】

Ｓ１１５１－４において、輻輳ＲＴＴ算出部１５は、ｊ＜Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）を満たすか否かを判断する。ＹｅｓであればＳ１１５１－５に進み、Ｎｏであれば処理を終了する。Ｓ１１５１－５において、輻輳ＲＴＴ算出部１５は、Ｓ１１５２を実行して、Ｓ１１５１－２に戻る。

【0213】

＜Ｓ１１５２＞
次に、図７１を参照してＳ１１５２について説明する。

【0214】

Ｓ１１５２－１において、輻輳ＲＴＴ算出部１５は、ＮＷ＿Ａ－ＩＤ［ｉ］に対してＵＤＳで規定されるＴｅｓｔｅｒＰｒｅｓｅｎｔ要求を０．５ｍｓ間隔で、Ｓ１１５２が終了するまで送信し続け、ＮＷ＿Ａ－ＩＤ［ｉ］のＮＷ＿Ａメッセージが送信されるＮＷ＿Ａバスを輻輳させる。なお、送信間隔はこれに限らない。

【0215】

Ｓ１１５２－２において、輻輳ＲＴＴ算出部１５は、ＮＷ＿Ａ－ＩＤ［ｊ］に対してＵＤＳで規定されるＴｅｓｔｅｒＰｒｅｓｅｎｔ要求を２００ｍｓ間隔で１００回送信する。そして、それに対しての応答を受信する。さらに、それらの送信時刻と受信時刻を記憶手段に記録する。記録された情報の例を図７２に示す。なお、送信間隔や送信回数はこれに限らない。

【0216】

Ｓ１１５２－３において、輻輳ＲＴＴ算出部１５は、前のステップの記録を用いて応答時間（以降、輻輳時応答時間と呼称）の統計値を算出する。そしてその結果をＮＷ＿Ａ－ＩＤ［ｉ］（図７３（表３１５１）では輻輳ＮＷ＿Ａ－ＩＤと呼称）とＮＷ＿Ａ－ＩＤ［ｊ］（図７３（表３１５１）では統計値算出対象ＮＷ＿Ａ－ＩＤと呼称）とともに記憶手段に記録する。記録された情報の例を図７３（表３１５１）に示す。

【0217】

なお、要求ＮＷ＿Ａ－ＩＤでＴｅｓｔｅｒＰｒｅｓｅｎｔを送信した時刻と、その直後に応答ＮＷ＿Ａ－ＩＤでＴｅｓｔｅｒＰｒｅｓｅｎｔを受信した時刻の差を輻輳時応答時間とする。また、統計値として平均値・最大値、最小値、標準偏差を算出する。ただし、その他の統計値を算出しても良い
＜Ｓ１１６２＞
次に、図７４を参照してＳ１１６１について説明する。

【0218】

Ｓ１１６１－１において、ＲＴＴ比較部１６は、とあるＮＷ＿Ａ－ＩＤ＝ｘについて、図６９（表３１４１）のＮＷ＿Ａ－ＩＤ＝ｘの統計値と図７３（表３１５１）の統計値算出用のＮＷ＿Ａ－ＩＤ＝ｘの統計値を比較する。そして、図７３（表３１５１）側の統計値のいずれかの値が図６９（表３１４１）よりも５０％以上増加している行を図７３（表３１５１）から抽出する。抽出結果は図７５（表３１６１）に示す通りである。なお、図７５（表３１６１）の抽出方法はこれに限るものではない。

【0219】

Ｓ１１６１－２において、ＲＴＴ比較部１６は、図７５（表３１６１）の各行の輻輳ＮＷ＿Ａ－ＩＤと統計値算出対象ＮＷ＿Ａ－ＩＤをグルーピングする。例えば、０ｘ７００と０ｘ７２４は一つのグループであり、０ｘ７００と０ｘ７Ｅ０は一つのグループであり、０ｘ７２４と０ｘ７Ｅ０は一つのグループであり、０ｘ７５０と０ｘ７Ｅ１は一つのグループである。

【0220】

Ｓ１１６１－３において、ＲＴＴ比較部１６は、前のステップで作ったグループを可能な限りまとめる。例えば、０ｘ７００と０ｘ７２４は一つのグループであり、０ｘ７００と０ｘ７Ｅ０は一つのグループであり、０ｘ７２４と０ｘ７Ｅ０は一つのグループでることから、これら３つは一つのグループであるとする。その結果は図７６（表３１６２）の通りである。

【0221】

＜Ｓ１１７１＞
次に、図７７を参照してＳ１１７１を説明する。

【0222】

Ｓ１１７１－１において、推定部１７は、構成情報推定結果ＤＢ２２に格納されている図５６（表３１１２）相当の情報からすべてのＥＣＵ型番を取り出す。次に、取り出したＥＣＵ型番の重複を削除する。そして重複が削除されたＥＣＵ型番と物理的なＥＣＵを１対１対応させる。結果は図７８に示す通りである。

【0223】

Ｓ１１７１－２において、推定部１７は、構成情報推定結果ＤＢ２２に格納されている図５６（表３１１２）相当の情報に基づいて要求ＮＷ＿Ａ－ＩＤの情報を図７８に追加する。その結果は図７９に示すとおりである。

【0224】

Ｓ１１７１－３において、推定部１７は、とあるＮＷ＿Ａ－ＩＤ＝ｘについて、図６９（表３１４１）のＮＷ＿Ａ－ＩＤ＝ｘの統計値と図７３（表３１５１）の統計値算出用のＮＷ＿Ａ－ＩＤ＝ｘの統計値を比較する。そして、図７３（表３１５１）側の統計値のいずれかの値が図６９（表３１４１）よりも５０％以上増加している行を図７３（表３１５１）から抽出する。抽出結果は図７５（表３１６１）に示すとおりである。なお、図７５（表３１６１）の抽出方法はこれに限るものではない。

【0225】

Ｓ１１７１－４において、推定部１７は、図７５（表３１６１）の各行の輻輳ＮＷ＿Ａ－ＩＤと統計値算出対象ＮＷ＿Ａ－ＩＤをグルーピングする。例えば、０ｘ７００と０ｘ７２４は一つのグループであり、０ｘ７００と０ｘ７Ｅ０は一つのグループであり、０ｘ７２４と０ｘ７Ｅ０は一つのグループであり、０ｘ７５０と０ｘ７Ｅ１は一つのグループである。

【0226】

Ｓ１１７１－５において、推定部１７は、前のステップで作ったグループを可能な限りまとめる。例えば、０ｘ７００と０ｘ７２４は一つのグループであり、０ｘ７００と０ｘ７Ｅ０は一つのグループであり、０ｘ７２４と０ｘ７Ｅ０は一つのグループでることから、これら３つは一つのグループであるとする。その結果は図７６（表３１６２）の通りである。

【0227】

＜Ｓ１１７２＞
次に、図８０を参照してＳ１１７２を説明する。

【0228】

Ｓ１１７２－１において、推定部１７は、図７６（表３１６２）で一つのグループにまとめられているＮＷ＿Ａ－ＩＤのＮＷ＿Ａメッセージに対して応答するＥＣＵは同一のＮＷ＿Ａバスに接続されていると判定する。そして推定部１７は、その判定結果を基に、図７９の情報をＮＷ＿Ａバスのトポロジ図（図８１）に変換する。

【0229】

Ｓ１１７２－２において、推定部１７は、構成情報推定結果ＤＢ２２（構成情報整理部）に渡された図５６（表３１１２）のすべての情報をＥＣＵに適切に割り当てる。その結果は図８２に示す通りである。

【0230】

Ｓ１１７２－３において、推定部１７は、構成情報推定結果ＤＢ２２（構成情報整理部）に渡された図６５のＮｏｄｅＴｙｐｅ＝０ｘ１のＥＣＵと、図８２のＥＣＵの機能の「完全一致」もしくは「部分一致」にＧＷ（ｇａｔｅｗａｙ）が含まれているＥＣＵを探索する。

【0231】

Ｓ１１７２－４において、推定部１７は、前のステップで見つけたＥＣＵをＮＷ＿Ａバスで接続する。その結果は図８３に示す通りである。

【0232】

Ｓ１１７２－５において、推定部１７は、図８３に示す情報を構成情報取得・登録部２４を経由して構成情報推定結果ＤＢ２２に格納する
＜Ｓ１１８０＞
次に、図８４を参照して正常ＮＷ＿Ａ通信推定部１８によるＳ１１８０を説明する。

【0233】

Ｓ１１８０－１において、再起動命令送信部１９は、Ｓ１１９１を実行する。Ｓ１１８０－２において、再起動命令送信部１９は、Ｓ１１９２を実行する。Ｓ１１８０－３において、車両アラート受信部２０は、Ｓ１２０１を実行する。Ｓ１１８０－４において、車両アラート受信部２０は、Ｓ１２１１を実行する。

【0234】

＜Ｓ１１９１＞
次に、図８５を参照してＳ１１９１を説明する。

【0235】

Ｓ１１９１－１において、再起動命令送信部１９は、下記の変数を宣言する。

【0236】

・構成情報推定結果ＤＢ２２に格納された図５６（表３１１２）の要求ＮＷ＿Ａ－ＩＤリスト"ＮＷ＿Ａ－ＩＤ＝［０ｘ７００，０ｘ７２４，０ｘ７５０，０ｘ７Ｅ０，０ｘ７Ｅ１］"
・リストの長さ"Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）"（本例の場合はＬｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）＝５）
・ｉ＝０
なお、変数名は上記以外でも良い。また、ＮＷ＿Ａ－ＩＤの中身をＮＷ＿Ａ－ＩＤ以外の値で統一しても良い。

【0237】

Ｓ１１９１－２において、再起動命令送信部１９は、ｉ＜Ｌｅｎｇｔｈ（ＮＷ＿Ａ－ＩＤ）が成り立つかどうかを判断する。Ｙｅｓの場合はＳ１１９１－３に進み、Ｎｏの場合は処理を終了する。Ｓ１１９１－３において、再起動命令送信部１９は、Ｓ１１９２を実行する。Ｓ１１９１－３において、再起動命令送信部１９は、ｉ＝ｉ＋１として、Ｓ１１９１－２に戻る。

【0238】

＜Ｓ１１９２＞
次に、図８６を参照してＳ１１９２について説明する。

【0239】

Ｓ１１９２－１において、再起動命令送信部１９は、ＮＷ＿Ａ－ＩＤ［ｉ］に対してＵＤＳで規定されるＥＣＵＲｅｓｅｔ（ＲｅｓｅｔＴｙｐｅ＝ＨａｒｄＲｅｓｅｔ）要求を５秒から１０秒のランダムな間隔で１０回送信する。なお、送信間隔や送信回数、ＲｅｓｅｔＴｙｐｅはこれに限らない。

【0240】

Ｓ１１９２－２において、再起動命令送信部１９は、前のステップでＥＣＵＲｅｓｅｔ要求を送信した時刻をＮＷ＿Ａ－ＩＤ［ｉ］とともに記憶手段に記録する。記録した情報の例を図８７に示す。

【0241】

＜Ｓ１２０１＞
次に、図８８を参照してＳ１２０１について説明する。

【0242】

まず、前提を説明する。車載ネットワーク１上のＥＣＵはあるＮＷ＿Ａ－ＩＤのＮＷ＿Ａメッセージを一定（設計値）の時間間隔（送信間隔）で送信している。また、車載ネットワーク１上のＮＷ＿Ａ－ＩＤＳはあるＮＷ＿Ａ－ＩＤのＮＷ＿Ａメッセージの送信間隔が設計値を大きく逸脱している場合にアラートを発報する。なお、アラートには発報時刻と検知されたＮＷ＿ＡメッセージのＮＷ＿Ａ－ＩＤが格納されているとする。

【0243】

ＥＣＵＲｅｓｅｔを受信したＥＣＵはＥＣＵの再起動を実行するため、一時的にＮＷ＿Ａメッセージの送信を停止する。また、再起動後は任意の時間を空けてＮＷ＿Ａメッセージの送信を再開する。そのため、ＥＣＵＲｅｓｅｔを受信したＥＣＵが送信するＮＷ＿Ａメッセージの送信間隔は一時的に大きくなる、あるいは小さくなる。ＮＷ＿Ａ－ＩＤＳはこれを異常と判定しアラートを発報する
Ｓ１２０１－１において、車両アラート受信部２０は、ＮＷ＿Ａ－ＩＤＳのアラートを時刻とともに記憶手段に記録する。記憶した情報の例を図８９に示す。

【0244】

＜Ｓ１２１１＞
次に、図９０を参照してＳ１２１１について説明する。

【0245】

Ｓ１２１１－１において、推定部２１は、図８７に示す情報として記録されているＮＷ＿Ａ－ＩＤと図８９に示す情報として記録されているＮＷ＿Ａ－ＩＤを関連付ける。関連付ける際は、記録された時刻の類似性を基に行う。関連付けを行った結果の例を図９１（表３２１１）に示す。

【0246】

Ｓ１２１１－２において、推定部２１は、図９１（表３２１１）の結果を車両構成推定の結果（例えば図８３や図５６（表３１１２））に追加する。その際は、「表３２１１のＥＣＵＲｅｓｅｔのＮＷ＿Ａ－ＩＤ列」＝「図８３や表３１１２の要求ＮＷ＿Ａ－ＩＤ」の条件を満たす行を図８３や図５６（表３１１２）に追加する。

【0247】

なお、追加する際は例えば「定常送信ＮＷ＿Ａ－ＩＤ」という列名で追加する。その結果例は図９２や図９３（表３２１２）に示す通りである。

【0248】

（実施例Ａ２）
次に、実施例Ａ２について説明する。図９４は、実施例Ａ２におけるシステムの構成図である。図９４に示すように、実施例Ａ２における構成は、推定部として、要素技術３に対応するＥＣＵ機能推定部４のみを備えた構成である。各部の処理については実施例Ａ１において説明した処理と同じである。

【0249】

（実施例Ａ３）
次に、実施例Ａ３について説明する。図９５は、実施例Ａ３におけるシステムの構成図である。図９５に示すように、実施例Ａ３における構成は、推定部として、要素技術１に対応するＮＷ＿Ａバストポロジ推定部１３のみを備えた構成である。各部の処理については実施例Ａ１において説明した処理と同じである。

【0250】

（実施例Ａ４）
次に、実施例Ａ４について説明する。図９６は、実施例Ａ４におけるシステムの構成図である。図９６に示すように、実施例Ａ４における構成は、推定部として、要素技術２に対応する正常ＮＷ＿Ａ通信推定部１８のみを備えた構成である。各部の処理については実施例Ａ１において説明した処理と同じである。

【0251】

（実施例Ａ５）
次に、実施例Ａ５について説明する。図９７は、実施例Ａ５におけるシステムの構成図である。図９７に示すように、実施例Ａ５における構成は、実施例Ａ１（図２７）の構成から、正常ＮＷ＿Ａ通信推定部１８を除いた構成である。各部の処理については実施例Ａ１において説明した処理と同じである。

【0252】

（実施例Ａ６）
次に、実施例Ａ６について説明する。図９８は、実施例Ａ６におけるシステムの構成図である。図９８に示すように、実施例Ａ６における構成は、実施例Ａ１（図２７）の構成から、ＮＷ＿Ａバストポロジ推定部１３を除いた構成である。各部の処理については実施例Ａ１において説明した処理と同じである。

【0253】

（実施例Ａ７）
次に、実施例Ａ７について説明する。図９９は、実施例Ａ７におけるシステムの構成図である。図９９に示すように、実施例Ａ７における構成は、実施例Ａ１（図２７）の構成から、ＥＣＵ機能推定部４を除いた構成である。各部の処理については実施例Ａ１において説明した処理と同じである。

【0254】

（実施例Ｂ１）
次に、実施例Ｂ１について説明する。実施例Ｂ１は、本発明に係る構成情報推定システムを車載ＮＷ上に配備する実施例である。図１００は、実施例Ｂ１における自動車（車載ＮＷ）の構成図である。図１００に示すように、車載ＮＷ上のＥＣＵの機能として車両構成推定装置２及び構成情報推定結果ＤＢ２２が備えられる。

【0255】

なお、図１００のように構成情報推定結果ＤＢ２２をＥＣＵに備えることに代えて、構成情報推定結果ＤＢ２２をクラウド上に備えることとしてもよい。また、車両構成推定装置２において、メッセージ送受信部２３以外の１つ又は複数の機能部をクラウド上に備えることとしてもよい。例えば車両構成推定装置２におけるＥＣＵ機能推定部４のみをクラウド上に備えることとしてもよい。

【0256】

（実施例Ｂ２）
次に、実施例Ｂ２について説明する。実施例Ｂ２は、本発明に係る構成情報推定システム（装置）をＯＢＤ－ＩＩポートに直接接続する実施例である。図１０１は、実施例Ｂ２におけるシステムの構成図である。図１０１に示すように、構成情報推定システムがＯＢＤ－ＩＩポートに直接接続する。

【0257】

なお、図１０１のように構成情報推定結果ＤＢ２２を構成情報推定システム（装置）上に備えることに代えて、構成情報推定結果ＤＢ２２をクラウド上に備えることとしてもよい。また、車両構成推定装置２において、メッセージ送受信部２３以外の１つ又は複数の機能部をクラウド上に備えることとしてもよい。例えば車両構成推定装置２におけるＥＣＵ機能推定部４のみをクラウド上に備えることとしてもよい。

【0258】

（実施例Ｂ３）
次に、実施例Ｂ３について説明する。図１０２に実施例Ｂ３におけるシステムの構成を示す。図１０２に示すように、実施例Ｂ３では、本発明に係る構成情報推定システムが、充電器に備えられ、充電ポートに接続される。構成情報推定システムの処理は充電ポートを介して実行される。

【0259】

なお、図１０２のように構成情報推定結果ＤＢ２２を充電器上に備えることに代えて、構成情報推定結果ＤＢ２２をクラウド上に備えることとしてもよい。また、車両構成推定装置２において、メッセージ送受信部２３以外の１つ又は複数の機能部をクラウド上に備えることとしてもよい。例えば車両構成推定装置２におけるＥＣＵ機能推定部４のみをクラウド上に備えることとしてもよい。

【0260】

（実施例Ｂ４）
次に、実施例Ｂ４について説明する。図１０３に実施例Ｂ４におけるシステムの構成を示す。図１０３に示すように、実施例Ｂ４では、本発明に係る構成情報推定システムが外部ネットワーク上に備えられ、構成情報推定システムの処理は外部ネットワークを経由して実行される。

【0261】

（実施例Ｃ１）
次に、実施例Ｃ１を説明する。実施例Ｃ１は、構成情報推定システムをＳＯＣ等でのセキュリティ分析に活用する実施例である。図１０４は、実施例Ｃ１におけるシステム構成図である。

【0262】

図１０４に示すとおり、本システムは、自動車に接続される車両構成推定装置２、及び構成情報推定結果ＤＢ２２に加えて、構成情報取得部３０、セキュリティ分析部３１、分析結果提示部３２を備える。各部は、図示のとおりに接続されている。

【0263】

構成情報取得部３０は、構成情報推定結果ＤＢ２２から必要な構成情報を抽出し、セキュリティ分析部３１に渡す。セキュリティ分析部３１は、車両構成推定装置２が推定した車両構成情報を利用してより高度なセキュリティ分析を行う。そして分析結果を分析結果提示部３２に渡す。

【0264】

分析結果提示部３２は、分析結果を受け取り、適宜加工を施し分析官に結果を提示する。なお、分析官は人に限らず、分析結果を利用してさらに別の分析を行うプログラムでも良い。

【0265】

セキュリティ分析部３１が実行するセキュリティ分析は特定のものに限定されないが、例えば、下記に列挙する例がある。

【0266】

・トポロジ情報を取得利用した攻撃経路の推定
・トポロジ情報や各ＥＣＵのソフトウェアバージョンを利用したエントリーポイントの推定
・トポロジ情報や各ＥＣＵのソフトウェアバージョンを利用した原因推定
・トポロジ情報や各ＥＣＵのソフトウェアバージョン、正常通信の情報を利用した異常な通信やプロセスの推定
・トポロジ情報や各ＥＣＵのソフトウェアバージョンを利用した、正常通信の情報、各ＥＣＵの機能の情報を利用した影響の推定
・トポロジ情報や各ＥＣＵのソフトウェアバージョンを利用した対処方法の推定
（実施例Ｃ２）
次に、実施例Ｃ２を説明する。実施例Ｃ２は、構成情報推定システムをアセット管理に活用する実施例である。図１０５は、実施例Ｃ２におけるシステム構成図である。

【0267】

図１０５に示すとおり、本システムは、自動車に接続される車両構成推定装置２、及び構成情報推定結果ＤＢ２２に加えて、構成情報取得部３０、アセット管理部３３、管理情報提示部３４を備える。各部は、図示のとおりに接続されている。

【0268】

構成情報取得部３０は、構成情報推定結果ＤＢ２２から必要な構成情報を抽出し、アセット管理部３３に渡す。アセット管理部３３は管理情報を保持しており、受け取った構成情報を基に、管理情報にないＥＣＵやサポート切れのＥＣＵが存在しないか等の管理を行う。このとき、ＥＣＵのソフトウェアのサポート状況等の公開情報も利用する。

【0269】

管理情報提示部３４は、アセット管理部３３より管理情報を取得し、適宜加工を施し（例えば管理情報にないＥＣＵの機器名やアドレス情報のみを抽出・整理）管理者に結果を提示する。なお、管理者は人に限らず、管理情報を利用してさらに別の分析を行うプログラムでも良い。

【0270】

（実施例Ｃ３）
次に、実施例Ｃ３を説明する。実施例Ｃ３は、構成情報推定システムを異常検知に活用する実施例である。図１０６は、実施例Ｃ３におけるシステム構成図である。

【0271】

図１０６に示すとおり、本システムは、自動車に接続される車両構成推定装置２、及び構成情報推定結果ＤＢ２２に加えて、構成情報取得部３０、異常検知部３５を備える。各部は、図示のとおりに接続されている。

【0272】

構成情報取得部３０は、構成情報推定結果ＤＢ２２から必要な構成情報を抽出し、異常検知部３５に渡す。異常検知部３５は、正常な車両構成情報が格納されたＤＢの情報や異常検知ルール、公開情報（例えば脆弱性ＤＢの情報）を利用して、車両構成情報の異常状態を検知する。さらに、異常検知結果を自動車の管理者やＳＯＣ等の分析官に通知する。

【0273】

異常検知手法は特定の手法に限定されないが、例えば、下記に列挙する例がある。

【0274】

・正常な車両構成情報ＤＢに格納されている車両構成情報と構成情報推定結果ＤＢに格納されている車両構成情報を比較し、そこに差異があれば異常として検知する。

【0275】

・構成情報推定結果ＤＢ２２に格納されている車両構成情報が、異常検知ルールを満たす場合や、公開情報（脆弱性ＤＢ）などで異常状態として定義されている構成情報を持つ場合に異常があるとして検知する。

【0276】

・正常な自動車の車両構成情報を機械学習し、学習したモデルに基づいて機械学習ベースの異常検知を行う。

【0277】

（実施例Ｃ４）
次に、実施例Ｃ４を説明する。実施例Ｃ４は、構成情報推定システムをセキュリティ診断に活用する実施例である。図１０７は、実施例Ｃ４におけるシステム構成図である。

【0278】

図１０７に示すとおり、本システムは、自動車に接続される車両構成推定装置２、及び構成情報推定結果ＤＢ２２に加えて、構成情報取得部３０、セキュリティ診断部３６、診断結果提示部３７を備える。各部は、図示のとおりに接続されている。

【0279】

構成情報取得部３０は、構成情報推定結果ＤＢ２２から必要な構成情報を抽出し、セキュリティ診断部３６に渡す。セキュリティ診断部３６は受け取った構成情報を基に、自動車にセキュリティ的に問題のあるＥＣＵが存在しないか等の診断を行う。このとき、ＥＣＵのソフトウェアのサポート状況等の公開情報を利用して問題の有無を確認する。

【0280】

診断結果提示部３７は、セキュリティ診断部３６より診断結果を取得し、適宜加工（例えば診断結果を点数化する等）を施し管理者に結果を提示する。なお、管理者は人に限らず、管理情報を利用してさらに別の分析を行うプログラムでも良い。

【0281】

例えば、セキュリティ診断部３６が使用する診断ルールには、脆弱性の確認されているＥＣＵのＥＣＵ型番や、ソフトウェアのバージョン情報（ブラックリスト）が記録されている。セキュリティ診断部３６は、診断ルールに格納されている車両構成情報（ブラックリスト）と構成情報推定結果ＤＢ２２の車両構成情報を比較し、ブラックリストに該当する情報があれば、脆弱性を指摘する。

【0282】

（ハードウェア構成例）
第１の実施の形態で説明した診断通信送受信部１００、診断系ログＤＢ２００、及び構成情報推定部３００からなる装置、診断通信送受信部１００と診断系ログＤＢ２００からなる装置、診断系ログＤＢ２００と構成情報推定部３００からなる装置、診断通信送受信部１００と構成情報推定部３００からなる装置、診断通信送受信部１００からなる装置、診断系ログＤＢ２００からなる装置、及び構成情報推定部３００からなる装置はいずれも、例えば、コンピュータにプログラムを実行させることにより実現できる。このコンピュータは、物理的なコンピュータであってもよいし、クラウド上の仮想マシンであってもよい。

【0283】

また、第２の実施の形態で説明したシステム、装置、機能部についても、例えば、コンピュータにプログラムを実行させることにより実現できる。このコンピュータは、物理的なコンピュータであってもよいし、クラウド上の仮想マシンであってもよい。

【0284】

上記のプログラムが動作する主体を「装置」と呼ぶことにする。当該装置は、コンピュータに内蔵されるＣＰＵやメモリ等のハードウェア資源を用いて、当該装置で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。

【0285】

図１０８は、上記コンピュータのハードウェア構成例を示す図である。図１０８のコンピュータは、それぞれバスＢＳで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、入力装置１００７、出力装置１００８等を有する。なお、これらのうち、一部の装置を備えないこととしてもよい。例えば、表示を行わない装置は、表示装置１００６を備えなくてもよい。

【0286】

当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ－ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

【0287】

メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、当該装置に係る機能を実現する。インタフェース装置１００５は、ネットワークに接続するためのインタフェースとして用いられ、送信部及び受信部として機能する。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１００７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。出力装置１００８は演算結果を出力する。

【0288】

（実施の形態の効果）
以上、説明したとおり、本発明の実施の形態では、各ＥＣＵにおいて標準的にサポートされている診断通信プロトコル（ＤｏＣＡＮ、ＤｏＩＰ、ＵＤＳ等）を用いた診断通信の送受信を行うことで車両構成情報の推定に有効な情報を収集し、収集した情報を分析することで車両構成情報の推定を行うこととした。これにより、車両構成情報の推定において、リソースの増強や新たなプロトコルのサポートを行う必要が無く、追加のコストを削減できる。

【0289】

（実施の形態のまとめ）
本明細書には、少なくとも下記各項のネットワーク構成推定装置、ネットワーク構成推定方法、及びプログラムが開示されている。
（第１項）
対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の電子制御装置に対してメッセージを送信し、当該メッセージに対する応答を受信する診断通信送受信部と、
前記診断通信送受信部により得られた前記応答に基づいて、前記内部ネットワークの構成情報を推定する構成情報推定部と
を備えるネットワーク構成推定装置。
（第２項）
前記構成情報推定部は、
前記応答に基づいて、前記内部ネットワーク上の電子制御装置の存在を確認する存在確認部と、
前記存在確認部による電子制御装置の存在確認結果に基づいて、前記内部ネットワークのトポロジを推定するトポロジ推定部と、
前記応答に基づいて、前記内部ネットワーク上の電子制御装置に関する情報を抽出する情報抽出部と
を備える第１項に記載のネットワーク構成推定装置。
（第３項）
前記診断通信送受信部は、前記内部ネットワークにおける第１ネットワークと第２ネットワークのそれぞれにメッセージを送信し、その応答を受信し、
前記構成情報推定部は、前記第１ネットワークに送信したメッセージの応答により前記第１ネットワークに接続した電子制御装置の存在を確認し、前記第２ネットワークに送信したメッセージの応答により前記第２ネットワークに接続した電子制御装置の存在を確認する
第１項又は第２項に記載のネットワーク構成推定装置。
（第４項）
前記診断通信送受信部は、データＩＤを設定したメッセージを送信し、その応答を受信し、
前記構成情報推定部は、前記データＩＤを設定したメッセージに対する応答から、当該データＩＤに対応する情報を抽出する
第１項ないし第３項のうちいずれか１項に記載のネットワーク構成推定装置。
（第５項）
対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の電子制御装置に対してメッセージを送信し、当該メッセージに対する応答を受信する装置により得られた前記応答に基づいて、前記内部ネットワークの構成情報を推定する構成情報推定部
を備えるネットワーク構成推定装置。
（第６項）
対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
非輻輳時の状態において、前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の第１電子制御装置のラウンドトリップタイムを算出するベースＲＴＴ算出部と、
第２電子制御装置に対して診断要求を高頻度で送信している輻輳時の状態において、前記第１電子制御装置のラウンドトリップタイムを算出する輻輳ＲＴＴ算出部と、
前記非輻輳時の状態におけるラウンドトリップタイムと、前記輻輳時の状態におけるラウンドトリップタイムとを比較することにより、前記第１電子制御装置と前記第２電子制御装置が同一バスに接続されているか否かを推定する推定部と
を備えるネットワーク構成推定装置。
（第７項）
対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の対象電子制御装置に再起動命令を送信する再起動命令送信部と、
前記再起動命令に起因して発生したアラートを前記内部ネットワークから受信するアラート受信部と、
前記アラートに含まれるＩＤを、前記対象電子制御装置が送信する通常通信のＩＤであると推定する推定部と
を備えるネットワーク構成推定装置。
（第８項）
対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置であって、
前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて取得した対象電子制御装置の型番の全体、及び、当該型番における機能に関する桁を用いて、電子制御装置の機能を検索するＷｅｂ検索部と、
前記Ｗｅｂ検索部により得られた検索結果に含まれる単語の支持度の和が最大となる機能を前記対象電子制御装置の機能と推定する推定部と
を備えるネットワーク構成推定装置。
（第９項）
対象装置における内部ネットワークの構成情報を推定するネットワーク構成推定装置が実行するネットワーク構成推定方法であって、
前記内部ネットワーク上の電子制御装置において標準的にサポートされる診断通信方法を用いて、前記内部ネットワーク上の電子制御装置に対してメッセージを送信し、当該メッセージに対する応答を受信するステップと、
前記応答に基づいて、前記内部ネットワークの構成情報を推定するステップと
を備えるネットワーク構成推定方法。
（第１０項）
コンピュータを、第１項ないし第８項のうちいずれか１項に記載のネットワーク構成推定装置における各部として機能させるためのプログラム。

【0290】

以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【0291】

本特許出願は２０２０年９月１８日に出願した国際特許出願ＰＣＴ／ＪＰ２０２０／０３５６２１に基づきその優先権を主張するものであり、国際特許出願ＰＣＴ／ＪＰ２０２０／０３５６２１の全内容を本願に援用する。

【符号の説明】

【0292】

１ 車載ＮＷ
２ 構成要素推定部
３ ＥＣＵ基本情報取得部
４ ＥＣＵ機能推定部
６ Ｗｅｂ検索部
７ Ｗｅｂサイト
８ 検索結果ＤＢ
９ 完全一致抽出部
１０ 特定部分一致抽出部
１１ 推定部
１２ ＮＷ＿Ｂトポロジ推定部
１３ ＮＷ＿Ａバストポロジ推定部
１４ ベースＲＴＴ算出部
１５ 輻輳ＲＴＴ算出部
１６ ＲＴＴ比較部
１７ 推定部
１８ 正常ＮＷ＿Ａ通信推定部
１９ 再起動命令送信部
２０ 車両アラート受信部
２１ 推定部
２２ 構成情報推定結果ＤＢ
２３ メッセージ送受信部
２４ 構成情報取得・登録部
３０ 構成情報取得部
３１ セキュリティ分析部
３２ 分析結果提示部
３３ アセット管理部
３４ 管理情報提示部
３５ 異常検知部
３６ セキュリティ診断部
３７ 診断結果提示部
５００ ＥＣＵ
１００ 診断通信送受信部
２００ 診断系ログＤＢ
３００ 構成情報推定部
３１０ ＥＣＵ存在確認部
３２０ トポロジ推定部
３３０ ＥＣＵ情報抽出部
３４０ 出力部
４００ 自動車
１０００ ドライブ装置
１００１ 記録媒体
１００２ 補助記憶装置
１００３ メモリ装置
１００４ ＣＰＵ
１００５ インタフェース装置
１００６ 表示装置
１００７ 入力装置
１００８ 出力装置

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33】

【図34】

【図35】

【図36】

【図37】

【図38】

【図39】

【図40】

【図41】

【図42】

【図43】

【図44】

【図45】

【図46】

【図47】

【図48】

【図49】

【図50】

【図51】

【図52】

【図53】

【図54】

【図55】

【図56】

【図57】

【図58】

【図59】

【図60】

【図61】

【図62】

【図63】

【図64】

【図65】

【図66】

【図67】

【図68】

【図69】

【図70】

【図71】

【図72】

【図73】

【図74】

【図75】

【図76】

【図77】

【図78】

【図79】

【図80】

【図81】

【図82】

【図83】

【図84】

【図85】

【図86】

【図87】

【図88】

【図89】

【図90】

【図91】

【図92】

【図93】

【図94】

【図95】

【図96】

【図97】

【図98】

【図99】

【図100】

【図101】

【図102】

【図103】

【図104】

【図105】

【図106】

【図107】

【図108】