特許 7447848 車両用装置、サーバ、及び通信管理方法

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

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

(11)【特許番号】

(24)【登録日】2024-03-04

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

(54)【発明の名称】車両用装置、サーバ、及び通信管理方法

(51)【国際特許分類】

   G06F 11/07 20060101AFI20240305BHJP

   G06F 11/34 20060101ALI20240305BHJP

   B60R 16/023 20060101ALI20240305BHJP

【ＦＩ】

G06F11/07 190

G06F11/07 140R

G06F11/34 176

B60R16/023 P

【請求項の数】 11

(21)【出願番号】P 2021035488

(22)【出願日】2021-03-05

(65)【公開番号】P2022135577

(43)【公開日】2022-09-15

【審査請求日】2023-04-10

(73)【特許権者】

【識別番号】000004260

【氏名又は名称】株式会社デンソー

(74)【代理人】

【識別番号】100106149

【弁理士】

【氏名又は名称】矢作 和行

(74)【代理人】

【識別番号】100121991

【弁理士】

【氏名又は名称】野々部 泰平

(74)【代理人】

【識別番号】100145595

【弁理士】

【氏名又は名称】久保 貴則

(72)【発明者】

【氏名】生島 佳祐

【審査官】▲はま▼中 信行

(56)【参考文献】

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

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

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

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

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

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

Ｇ０６Ｆ １１／０７

Ｇ０６Ｆ １１／３４

Ｂ６０Ｒ １６／０２３

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

【請求項1】

車両で用いることが可能な車両用装置であって、
前記車両に搭載される車載ＥＣＵ（４０）と前記車両の外部のネットワーク上の接続先（１４０）との間での通信確立過程におけるやり取りの状況を把握してそのログを一元管理するとともに、前記通信確立過程での障害を検出する監視部（１６）と、
前記監視部で前記障害を検出した場合に、前記監視部で管理している前記ログのうちのその障害に関連すると推定される前記ログを出力するログ出力部（２６，２７）とを備える車両用装置。

【請求項2】

請求項１に記載の車両用装置であって、
前記監視部で前記障害を検出した場合に、前記監視部で管理している前記ログのうちから、その障害の原因を特定できると推定される前記ログである原因特定用ログを抽出するログ抽出部（２５）を備え、
前記ログ出力部（２６）は、前記障害に関連すると推定される前記ログとして、前記ログ抽出部で抽出した前記原因特定用ログを、出力する車両用装置。

【請求項3】

請求項２に記載の車両用装置であって、
前記通信確立過程での障害の原因別の前記原因特定用ログを指定するための検出ルールを格納しているルール格納部（２３）を備え、
前記監視部は、前記監視部で管理している前記ログに、前記ルール格納部に格納されている前記検出ルールに該当する前記ログが存在した場合に、前記通信確立過程での障害を検出し、
前記ログ抽出部は、その検出ルールで指定される前記ログを前記原因特定用ログとして抽出する車両用装置。

【請求項4】

請求項３に記載の車両用装置であって、
前記車両の外部のネットワークを介して、前記検出ルールを取得し、前記ルール格納部に格納することが可能なルール取得部（２２）を備える車両用装置。

【請求項5】

請求項４に記載の車両用装置であって、
前記監視部は、前記ルール格納部に格納されている前記検出ルールに該当する前記ログが存在しない場合であっても、前記通信確立過程におけるやり取りで、正常時に期待されるやり取りと異なる異常やり取りが発生した場合に、前記通信確立過程での障害を検出するものであり、
前記監視部で管理している前記ログのうちの前記異常やり取りに関する前記ログである異常時ログを、前記車両の外部のネットワーク上の、前記障害の原因を特定するために前記原因特定用ログを収集するサーバである収集サーバに向けて出力する異常時ログ出力部（２７）を備え、
前記ルール取得部は、前記車両の外部のネットワークを介して、前記収集サーバから、前記異常時ログの送付に対する回答として、その異常時ログをもとに設定された前記検出ルールを取得する車両用装置。

【請求項6】

請求項１に記載の車両用装置であって、
前記監視部は、前記通信確立過程におけるやり取りで、正常時に期待されるやり取りと異なる異常やり取りが発生した場合に、前記通信確立過程での障害を検出するものであり、
前記ログ出力部（２７）は、前記障害に関連すると推定される前記ログとして、前記監視部で管理している前記ログのうちの前記異常やり取りに関する前記ログである異常時ログを、出力する車両用装置。

【請求項7】

請求項１～６のいずれか１項に記載の車両用装置であって、
前記車載ＥＣＵと前記接続先との間での通信確立には、前記接続先との間でのやり取り以外にも、前記接続先以外の、前記車両の外部のネットワーク上のサーバである第３者サーバとのやり取りも必要なものであり、
前記監視部は、前記車載ＥＣＵと前記第３者サーバとの間での通信確立過程におけるやり取りも仲介することで、この通信確立過程におけるやり取りの情報であるログも一元管理する車両用装置。

【請求項8】

請求項１～６のいずれか１項に記載の車両用装置であって、
前記ログ出力部は、前記車両の外部のネットワーク上の、前記障害の原因を特定するために前記ログを収集するサーバである収集サーバに向けて前記ログを出力する車両用装置。

【請求項9】

車両の外部のネットワーク上で用いることが可能なサーバであって、
前記車両に搭載される車載ＥＣＵ（４０）と前記車両の外部のネットワーク上の接続先（１４０）との間での通信確立過程におけるやり取りの情報であるログを一元管理することで、一元管理している前記ログのうちの前記通信確立過程での障害に関連すると推定される前記ログを出力する、前記車両で用いられる車両用装置から、出力される前記ログを取得するログ取得部（１０６，１０８）と、
前記車両用装置から前記ログ取得部で取得した前記ログを格納するログ格納部（１０７，１０９）と、
前記通信確立過程での障害の原因別の、その障害の原因を特定できると推定される前記ログである原因特定用ログを指定するための検出ルールを設定するルール設定部（１１０）と、
前記ルール設定部で設定した前記検出ルールを前記車両用装置に送ることで、その検出ルールで指定される前記ログを前記車両用装置において前記原因特定用ログとして抽出して出力させるようにする設定送信部（１１１）とを備えるサーバ。

【請求項10】

少なくとも１つのプロセッサにより実行される通信管理方法であって、
車両に搭載される車載ＥＣＵ（４０）と前記車両の外部のネットワーク上の接続先（１４０）との間での通信確立過程におけるやり取りの情報であるログを一元管理する監視工程と、
前記通信確立過程での障害を検出する障害検出工程と、
前記障害検出工程で前記障害を検出した場合に、前記監視工程で管理している前記ログのうちのその障害に関連すると推定される前記ログを出力するログ出力工程とを含む通信管理方法。

【請求項11】

少なくとも１つのプロセッサにより実行される通信管理方法であって、
車両に搭載される車載ＥＣＵ（４０）と前記車両の外部のネットワーク上の接続先（１４０）との間での通信確立過程におけるやり取りの状況を把握してそのログを一元管理することで、一元管理している前記ログのうちの前記通信確立過程での障害に関連すると推定される前記ログを出力する、前記車両で用いられる車両用装置（１０ａ）から、出力される前記ログを取得するログ取得工程と、
前記車両用装置から前記ログ取得工程で取得した前記ログを格納するログ格納工程と、
前記通信確立過程での障害の原因別の、その障害の原因を特定できると推定される前記ログである原因特定用ログを指定するための検出ルールを設定するルール設定工程と、
前記ルール設定工程で設定した前記検出ルールを前記車両用装置に送ることで、その検出ルールで指定される前記ログを前記車両用装置において前記原因特定用ログとして抽出して出力させるようにする設定送信工程とを含む通信管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、車両用装置、サーバ、及び通信管理方法に関するものである。

【背景技術】

【0002】

特許文献１には、車両に搭載される電子制御装置（以下、車載ＥＣＵ）と車外のネットワークとの通信を行う技術が開示されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１４－１６５６４１号公報

【発明の概要】

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

【0004】

特許文献１には、車載ＥＣＵと車外のネットワークとの通信をプロキシ部が代わって実施することが記載されている。しかしながら、車載電子制御装置と車外のネットワーク上の接続先（以下、車外接続先）との通信が失敗した場合のことについては記載されていない。つまり、車載ＥＣＵと車外接続先との間の通信接続の確立過程における障害を特定する仕組みについて考慮されていない。このような仕組みがない場合、車載ＥＣＵと車外接続先との間の通信接続の確立過程のどこに問題があったかを特定しづらい。その結果、車載ＥＣＵと車外接続先との間の通信接続の確立過程における障害の解消に時間がかかってしまう。

【0005】

この開示のひとつの目的は、車載ＥＣＵと車外接続先との間の通信接続の確立過程における障害の解消をより容易にすることを可能にする車両用装置、サーバ、及び通信管理方法を提供することにある。

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

【0006】

上記目的は独立請求項に記載の特徴の組み合わせにより達成され、また、下位請求項は、開示の更なる有利な具体例を規定する。特許請求の範囲に記載した括弧内の符号は、ひとつの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本開示の技術的範囲を限定するものではない。

【0007】

上記目的を達成するために、本開示の車両用装置は、車両に搭載される車載ＥＣＵ（４０）と車両の外部のネットワーク上の接続先（１４０）との間での通信確立過程におけるやり取りの状況を把握してそのログを一元管理するとともに、通信確立過程での障害を検出する監視部（１６）と、監視部で障害を検出した場合に、監視部で管理しているログのうちのその障害に関連すると推定されるログを出力するログ出力部（２６，２７）とを備える。

【0008】

また、上記目的を達成するために、本開示の第１の通信管理方法は、少なくとも１つのプロセッサにより実行される通信管理方法であって、車両に搭載される車載ＥＣＵ（４０）と車両の外部のネットワーク上の接続先（１４０）との間での通信確立過程におけるやり取りの状況を把握してそのログを一元管理する監視工程と、通信確立過程での障害を検出する障害検出工程と、障害検出工程で障害を検出した場合に、監視工程で管理しているログのうちのその障害に関連すると推定されるログを出力するログ出力工程とを含む。

【0009】

以上の構成によれば、車両に搭載される車載ＥＣＵと車両の外部のネットワーク上の接続先との間での通信確立過程におけるやり取りの情報であるログを一元管理するので、通信確立過程での障害を検出した場合に、このログのうちのその障害に関連すると推定されるログを出力することが可能になる。よって、このログをもとに、通信接続の確立過程における障害を特定し、その障害を解消することが可能になる。その結果、車載ＥＣＵと車外接続先との間の通信接続の確立過程における障害の解消をより容易にすることが可能になる。

【0010】

また、上記目的を達成するために、本開示のサーバは、車両の外部のネットワーク上で用いることが可能なサーバであって、車両に搭載される車載ＥＣＵ（４０）と車両の外部のネットワーク上の接続先（１４０）との間での通信確立過程におけるやり取りの情報であるログを一元管理することで、一元管理しているログのうちの通信確立過程での障害に関連すると推定されるログを出力する、車両で用いられる車両用装置から、出力されるログを取得するログ取得部（１０６，１０８）と、車両用装置からログ取得部で取得したログを格納するログ格納部（１０７，１０９）と、通信確立過程での障害の原因別の、その障害の原因を特定できると推定されるログである原因特定用ログを指定するための検出ルールを設定するルール設定部（１１０）と、ルール設定部で設定した検出ルールを車両用装置に送ることで、その検出ルールで指定されるログを車両用装置において原因特定用ログとして抽出して出力させるようにする設定送信部（１１１）とを備える。

【0011】

また、上記目的を達成するために、本開示の第２の通信管理方法は、少なくとも１つのプロセッサにより実行される通信管理方法であって、車両に搭載される車載ＥＣＵ（４０）と車両の外部のネットワーク上の接続先（１４０）との間での通信確立過程におけるやり取りの状況を把握してそのログを一元管理することで、一元管理しているログのうちの通信確立過程での障害に関連すると推定されるログを出力する、車両で用いられる車両用装置（１０ａ）から、出力されるログを取得するログ取得工程と、車両用装置からログ取得工程で取得したログを格納するログ格納工程と、通信確立過程での障害の原因別の、その障害の原因を特定できると推定されるログである原因特定用ログを指定するための検出ルールを設定するルール設定工程と、ルール設定工程で設定した検出ルールを車両用装置に送ることで、その検出ルールで指定されるログを車両用装置において原因特定用ログとして抽出して出力させるようにする設定送信工程とを含む。

【0012】

以上の構成によれば、車両用装置から出力される、車両に搭載される車載ＥＣＵと車両の外部のネットワーク上の接続先との間での通信確立過程での障害に関連すると推定されるログをサーバ側で格納することが可能になる。また、この車両用装置が搭載された車両すべてから、このようなログをサーバ側で取得可能となる。よって、格納したログをもとに、通信接続の確立過程における障害を特定し、その障害を解消することが可能になる。その結果、車載ＥＣＵと車外接続先との間の通信接続の確立過程における障害の解消をより容易にすることが可能になる。

【図面の簡単な説明】

【0013】

【図1】通信処理システムの概略的な構成の一例を示す図である。

【図2】通信モジュール１０／ＡＣＰエンジン１０ａの概略的な構成の一例を示す図である。

【図3】車載ＥＣＵ４０とアプリサーバ１４０との間での通信確立過程におけるやり取りの一例について説明するための図である。

【図4】クラウドサーバ１００／ＡＣＰクラウド１００ａの概略的な構成の一例を示す図である。

【図5】ＡＣＰエンジン１０ａでの障害検出関連処理の流れの一例を示すフローチャートである。

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

【0014】

図面を参照しながら、開示のための複数の実施形態を説明する。なお、説明の便宜上、複数の実施形態の間において、それまでの説明に用いた図に示した部分と同一の機能を有する部分については、同一の符号を付し、その説明を省略する場合がある。同一の符号を付した部分については、他の実施形態における説明を参照することができる。

【0015】

（実施形態１）
＜通信処理システムの概略構成＞
以下、本実施形態について図面を用いて説明する。まず、図１を用いて、通信処理システムの説明を行う。例えば通信処理システムは、ＡＣＰクラウド１００ａ及びＡＣＰエンジン１０ａを含んでなるオートモーティブ無線通信プラットフォーム１とする。オートモーティブ無線通信プラットフォーム１は、車両Ｖｅ毎の単位で、全ての車載ＥＣＵ４０の車外のサーバとの接続を実現するために必要な機能を提供する。以下、通信処理システムを構成するクラウドシステム及び車載システム等の詳細を順に説明する。

【0016】

クラウドシステムは、通信処理システムのうちで、車両Ｖｅの外部に設けられた構成群である。クラウドシステムには、クラウドサーバ１００を含む。クラウドシステム以外にも、アプリサーバ１４０、及び第３者サーバ１６０が存在する。クラウドサーバ１００、アプリサーバ１４０、及び第３者サーバ１６０は、それぞれ車外の通信ネットワークであるＷＡＮ（Wide Area Network）１５０に接続されている。

【0017】

アプリサーバ１４０は、車載ＥＣＵ４０の実質的な接続先となる。アプリサーバ１４０は、車載ＥＣＵ４０との間でアプリ通信を実施する。アプリサーバ１４０は、ＴＬＳ（Transport Layer Security）サーバ１４１を有している。ＴＬＳサーバ１４１は、車載ＥＣＵ４０の後述するＴＬＳ接続クライアント４４と連携し、ＴＬＳの構築に関連する処理を実行する。ＴＬＳの構築により、車載ＥＣＵ４０及びアプリサーバ１４０間での暗号化されたアプリ通信が可能になる。

【0018】

第３者サーバ１６０は、例えばＮＴＰ（Network Time Protocol）サーバ１６０ａ、ＤＮＳ（Domain Name System）サーバ１６０ｂ、及び証明書検証サーバ１６０ｃ等である。ＮＴＰサーバ１６０ａは、時刻情報を他のノードに配信及び同期するサーバ装置である。ＤＮＳサーバ１６０ｂは、名前解決情報を他のノードに提供するサーバ装置である。ＤＮＳサーバ１６０ｂは、ドメインネームに紐づくＩＰアドレスを、名前解決情報としてドメインネームの送信元に返信する。証明書検証サーバ１６０ｃは、ＴＬＳの構築時に使用する各種証明書の正当性検証及び失効確認等のための証明書検証情報を提供するサーバ装置である。ＮＴＰサーバ１６０ａ、ＤＮＳサーバ１６０ｂ、及び証明書検証サーバ１６０ｃを管理する管理者は、クラウドサーバ１００を管理する管理者とは一般に異なる管理者である場合が多い。

【0019】

クラウドサーバ１００は、車両Ｖｅに搭載された通信モジュール１０との間で、通信網を介した無線通信によって情報をやり取りできる。クラウドサーバ１００では、オートモーティブ無線通信プラットフォーム１のクラウド側の機能を実現するＡＣＰクラウド１００ａが動作する。ＡＣＰクラウド１００ａは、車載ＥＣＵ４０とアプリサーバ１４０との間でのＥ２Ｅ接続の確立過程における障害の情報（以下、Ｅ２Ｅ接続障害情報）を通信モジュール１０から収集する。ここで言うところのＥ２Ｅ接続とは、車載ＥＣＵ４０とアプリサーバ１４０との間でアプリ通信が実施できる接続状態を指す。クラウドサーバ１００については後に詳述する。

【0020】

なお、ＷＡＮ１５０を介してクラウドサーバ１００と接続される通信モジュール１０は、複数であることが好ましい。これによれば、クラウドサーバ１００が複数の車両からＥ２Ｅ接続障害情報を収集することが可能になる。その結果、Ｅ２Ｅ接続の確立過程における障害の傾向，発生率等を特定することが容易になる。

【0021】

車載システムは、通信処理システムのうちで、車両Ｖｅの内部に設けられた構成群である。車載システムには、通信モジュール１０及び複数の車載ＥＣＵ４０が含まれている。なお、車載システムに含まれる車載ＥＣＵ４０が１つである構成としてもよい。また、車載ＥＣＵ４０と通信モジュール１０とが一体となった構成としてもよい。車載ＥＣＵ４０と通信モジュール１０とが一体でない構成を採用する場合、車載システムには、少なくとも１つ以上の車載ＥＣＵ４０が含まれる構成とすればよい。通信モジュール１０及び車載ＥＣＵ４０は、それぞれ車内の通信ネットワークである車内ＬＡＮ（Local Area Network）５０に接続されている。車内ＬＡＮ５０は、Ｅｔｈｅｒｎｅｔ（登録商標）等を主体とするＩＰネットワークである。通信モジュール１０及び車載ＥＣＵ４０の一部は、例えばＵＳＢ等の接続形態で直接的又は間接的に車内ＬＡＮ５０に接続されていてもよい。本実施形態では、車内ＬＡＮ５０及び車外のネットワークであるＷＡＮ１５０もＴＣＰ／ＩＰネットワークであるものとして説明する。

【0022】

通信モジュール１０は、ＴＣＵ（Telematics Control Unit）又はＤＣＭ（Data Communication Module）等と呼称される。通信モジュール１０は、車載システムと外部との無線通信を可能にする。通信モジュール１０は、例えば駐車中等、車両Ｖｅの電源がオフ状態である場合でも、無線通信が可能な状態が継続され、ネットワークに接続されたオンラインの状態を維持する。通信モジュール１０では、オートモーティブ無線通信プラットフォーム１のＡＣＰエンジン１０ａが動作する。ＡＣＰエンジン１０ａは、車載ＥＣＵ４０とアプリサーバ１４０との間でのＥ２Ｅ接続の確立過程におけるやり取りを一元管理する。そして、Ｅ２Ｅ接続の確立過程におけるやり取りの障害を検出する。通信モジュール１０については後に詳述する。

【0023】

車載ＥＣＵ４０は、車両Ｖｅに搭載される制御装置である。車載ＥＣＵ４０は、マイクロコントローラを主体として含む。車載ＥＣＵ４０は、車載システムにおけるエンドＥＣＵに相当する。車載ＥＣＵ４０は、ボディ系のＥＣＵ、車両制御系のＥＣＵ、ＡＤＡＳ系又は自動運転系のＥＣＵ、ＨＭＩ系のＥＣＵのいずれであってもよい。車載ＥＣＵ４０は、１つ又は複数のアプリケーション４０ａを実行可能である。アプリケーション４０ａは、アプリサーバ１４０との間でのアプリ通信の実施により、車両Ｖｅのユーザに種々のサービスを提供する。車載ＥＣＵ４０は、通信モジュール１０とは異なり、車両Ｖｅの電源がオフ状態である場合には、消費電力抑制のため原則的に通信不可状態とされる。

【0024】

なお、複数の車載ＥＣＵ４０のうちの一部には、アプリケーション４０ａが実装されなくてもよい。また、通信モジュール１０は、車載ＥＣＵ４０を兼ねる構成として車載システムに設けられ、アプリケーション４０ａを実行可能であってもよい。

【0025】

車載ＥＣＵ４０は、機能ブロックとして、宛先サーバ設定部４１、鍵管理デバイス４２、及びＴＬＳ接続クライアント４４を備える。宛先サーバ設定部４１は、時刻情報、名前解決情報、及び証明書検証情報の少なくともいずれかの取得先を、ＡＣＰエンジン１０ａのＩＰアドレスに設定する。鍵管理デバイス４２は、ハード的に他の回路部から独立した構成として車載ＥＣＵ４０設けられている。鍵管理デバイス４２は、アプリサーバ１４０の認証に用いる鍵情報を管理する。ＴＬＳ接続クライアント４４は、鍵管理デバイス４２にて管理された鍵情報を用いて、アプリサーバ１４０が正規のアクセス先であるか否かを認証する。つまり、サーバ認証する。アプリサーバ側でも同様にしてクライアント認証が行われる。

【0026】

＜通信モジュール１０の概略構成＞
通信モジュール１０は、例えばプロセッサ、メモリ、Ｉ／Ｏ、これらを接続するバスを備え、メモリに記憶された制御プログラムを実行することで、ＡＣＰエンジン１０ａの機能を実行する。ここで言うところのメモリは、コンピュータによって読み取り可能なプログラム及びデータを非一時的に格納する非遷移的実体的記憶媒体（non-transitory tangible storage medium）である。また、非遷移的実体的記憶媒体は、半導体メモリ等によって実現される。ＡＣＰエンジン１０ａの機能を有する通信モジュール１０が車両用装置に相当する。また、コンピュータによってＡＣＰエンジン１０ａの各機能ブロックの処理が実行されることが、通信管理方法が実行されることに相当する。

【0027】

ここで、図２を用いて、通信モジュール１０の概略的な構成について説明する。図２に示すように、通信モジュール１０は、ＡＣＰエンジン１０ａの機能ブロックとして、車内ＦＷ（Firewall）部１１、車外ＦＷ部１２、時刻取得部１３、名前解決情報取得部１４、検証情報取得部１５、監視部１６、ルール取得部２２、ルール格納部２３、障害通知部２４、ログ抽出部２５、原因特定用ログ出力部２６、異常時ログ出力部２７、及びＷＡＮ接続処理部２８を備える。なお、通信モジュール１０が実行する機能の一部又は全部を、１つ或いは複数のＩＣ等によりハードウェア的に構成してもよい。また、通信モジュール１０が備える機能ブロックの一部又は全部は、プロセッサによるソフトウェアの実行とハードウェア部材の組み合わせによって実現されてもよい。

【0028】

車内ＦＷ部１１は、ＡＣＰエンジン１０ａにおいて、車内ＬＡＮ５０との接続部分に設けられている。ＡＣＰエンジン１０ａと車内ＬＡＮ５０との通信は、必ず車内ＦＷ部１１を通過する。車内ＦＷ部１１は、車内ＬＡＮ５０からＡＣＰエンジン１０ａへの車内通信のうちで、所定の基準に基づき不正と判断した通信を遮断する。

【0029】

車外ＦＷ部１２は、ＡＣＰエンジン１０ａにおいて、ＷＡＮ１５０との接続部分に設けられている。ＡＣＰエンジン１０ａとＷＡＮ１５０との通信は、必ず車外ＦＷ部１２を通過する。車外ＦＷ部１２は、車載システム及びＷＡＮ１５０間の車外通信のうちで、所定の基準に基づき不正と判断した通信を遮断する。

【0030】

時刻取得部１３、名前解決情報取得部１４、及び検証情報取得部１５は、第３者サーバ１６０から各種情報を取得する。つまり、ＡＣＰエンジン１０ａと第３者サーバ１６０との情報共有を実施する。時刻取得部１３は、ＮＴＰサーバ１６０ａから時刻情報を取得する。名前解決情報取得部１４は、ＤＮＳサーバ１６０ｂから名前解決情報を取得する。検証情報取得部１５は、証明書検証サーバ１６０ｃから証明書検証情報を取得する。なお、ＡＣＰクラウド１００ａが、第３者サーバ１６０と同等の情報管理をしている場合には、時刻取得部１３、名前解決情報取得部１４、及び検証情報取得部１５は、ＡＣＰクラウド１００ａからこれらの情報を取得してもよい。

【0031】

監視部１６は、車載ＥＣＵ４０とアプリサーバ１４０との間での通信確立過程におけるやり取りの情報（以下、ログ）を一元管理する。言い換えるとＥ２Ｅ接続の通信確立過程におけるやり取りのログを一元管理する。この通信確立過程におけるやり取りの情報を一元管理する処理が監視工程に相当する。ここで言うところの一元管理とは、Ｅ２Ｅ接続の確立過程におけるやり取りを実施又は仲介し、このやり取りの情報を取得して保持することを指す。

【0032】

ここで、図３を用いて、車載ＥＣＵ４０とアプリサーバ１４０との間での通信確立過程におけるやり取りの一例について説明する。本実施形態の例では、Ｅ２Ｅ接続の確立過程におけるやり取りとして、回線確立、時刻取得、ＤＮＳ名前解決、ＴＬＳネゴシエーション、証明書検証、サーバ／クライアント認証、及びアプリ通信が必要である場合を例に挙げて説明を行う。図３では、ＷＡＮ１５０に接続する車両Ｖｅが１台の場合を示すが、複数の車両ＶｅがＷＡＮ１５０に接続可能であるものとする。

【0033】

まず、Ｐ１で示す回線確立の過程では、車載ＥＣＵ４０とＷＡＮ１５０との間での接続の確立（以下、回線確立）におけるやり取りが行われる。回線確立は、ＷＡＮ接続処理部２８が行う。Ｐ２で示す時刻取得の過程では、車載ＥＣＵ４０が、時刻情報の有無を把握する。そして、時刻情報がない場合に、後述するが、時刻配信代行部１８への車内通信によって時刻情報を取得する。後述するが、時刻配信代行部１８は、ＮＴＰサーバ１６０ａから時刻情報を取得する。

【0034】

Ｐ３で示すＤＮＳ名前解決の過程では、車載ＥＣＵ４０が、後述する名前解決代行部１９への車内通信によって名前解決情報を取得する。後述するが、名前解決代行部１９は、ＤＮＳサーバ１６０ｂから名前解決情報を取得する。Ｐ４で示すＴＬＳネゴシエーションの過程では、車載ＥＣＵ４０が、アプリサーバ１４０への接続要求を実施する。つまり、ＴＬＳネゴシエーションを実施する。

【0035】

Ｐ５で示す証明書検証の過程では、車載ＥＣＵ４０が、各証明書の正当性検証及び失効確認等を実施する。ここで、車載ＥＣＵ４０は、後述する検証代行部２０への車内通信によって証明書検証情報を取得する。後述するが、検証代行部２０は、証明書検証サーバ１６０ｃから証明書検証情報を取得する。Ｐ６で示すサーバ／クライアント認証の過程では、車載ＥＣＵ４０が、鍵管理デバイス４２に管理された鍵情報を用いて、アプリサーバ１４０と車載ＥＣＵ４０との相互認証を実施する。車載ＥＣＵ４０は、後述する認証代行部２１を介して、この相互認証におけるやり取りを代行する。Ｐ７で示すアプリ通信の過程では、ＴＬＳ構築が完了した場合に、車載ＥＣＵ４０が、暗号通信経路でのアプリ通信を実施する。

【0036】

続いて、監視部１６での処理について詳述する。図２に示すように、監視部１６は、ＷＡＮ接続監視部１７、時刻配信代行部１８、名前解決代行部１９、検証代行部２０、及び認証代行部２１を有する。

【0037】

ＷＡＮ接続監視部１７は、ＷＡＮ接続処理部２８での車載ＥＣＵ４０とＷＡＮ１５０との間での接続の確立（つまり、回線確立）におけるやり取り、及び回線確立後の回線状態を監視する。ＷＡＮ１５０との接続の一例としては、Ｗｉｆｉ（登録商標）ネットワークとの接続，セルラーネットワークとの接続が挙げられる。上述した回線確立のやり取りは、Ｅ２Ｅ接続の通信確立過程におけるやり取りの一部である。ＷＡＮ接続監視部１７は、回線確立におけるやり取りのログ、及び回線確立後のやり取りのログを保持する。

【0038】

時刻配信代行部１８は、時刻取得部１３で取得した時刻情報を保持する。時刻配信代行部１８は、車載ＥＣＵ４０からの要求に応じて、ＮＴＰサーバ１６０ａに替わり、時刻取得部１３で取得した時刻情報を車載ＥＣＵ４０に同期させる。つまり、時刻配信代行部１８は、車載ＥＣＵ４０とＮＴＰサーバ１６０ａとの間での時刻情報のやり取りを仲介する。車載ＥＣＵ４０とＮＴＰサーバ１６０ａとの間での時刻情報のやり取りは、Ｅ２Ｅ接続の通信確立過程におけるやり取りの一部である。時刻配信代行部１６２は、仲介したこのやり取りのログを保持する。

【0039】

名前解決代行部１９は、名前解決情報取得部１４で取得した名前解決情報を保持する。名前解決代行部１９は、車載ＥＣＵ４０からの要求に応じて、ＤＮＳサーバ１６０ｂに替わり、名前解決情報取得部１４で取得した名前解決情報を車載ＥＣＵ４０に同期させる。つまり、名前解決代行部１９は、車載ＥＣＵ４０とＤＮＳサーバ１６０ｂとの間での名前解決情報のやり取りを仲介する。車載ＥＣＵ４０とＤＮＳサーバ１６０ｂとの間での名前解決情報のやり取りは、Ｅ２Ｅ接続の通信確立過程におけるやり取りの一部である。名前解決代行部１９は、仲介したこのやり取りのログを保持する。

【0040】

本実施形態では、名前解決情報取得部１４が、ＡＣＰクラウド１００ａを介して間接的に名前解決情報をＤＮＳサーバ１６０ｂから取得する例を挙げている。名前解決代行部１９は、ＡＣＰクラウド１００ａとＤＮＳサーバ１６０ｂとの間でのやり取りのログについては、例えばＡＣＰクラウド１００ａから取得して保持すればよい。本実施形態では、名前解決情報取得部１４が、ＡＣＰクラウド１００ａを介して間接的に名前解決情報をＤＮＳサーバ１６０ｂから取得する例を挙げたが、必ずしもこれに限らない。名前解決情報取得部１４が、ＤＮＳサーバ１６０ｂから直接的に名前解決情報を取得する構成としてもよい。

【0041】

検証代行部２０は、検証情報取得部１５で取得した証明書検証情報を保持する。検証代行部２０は、車載ＥＣＵ４０からの要求に応じて、証明書検証サーバ１６０ｃに替わり、検証情報取得部１５で取得した証明書検証情報を車載ＥＣＵ４０に同期させる。つまり、検証代行部２０は、車載ＥＣＵ４０と証明書検証サーバ１６０ｃとの間での証明書検証情報のやり取りを仲介する。車載ＥＣＵ４０と証明書検証サーバ１６０ｃとの間での名前解決情報のやり取りは、Ｅ２Ｅ接続の通信確立過程におけるやり取りの一部である。検証代行部２０は、仲介したこのやり取りのログを保持する。

【0042】

本実施形態では、検証情報取得部１５が、ＡＣＰクラウド１００ａを介して間接的に証明書検証情報を証明書検証サーバ１６０ｃから取得する例を挙げている。検証代行部２０は、ＡＣＰクラウド１００ａと証明書検証サーバ１６０ｃとの間でのやり取りのログについては、例えばＡＣＰクラウド１００ａから取得して保持すればよい。本実施形態では、検証情報取得部１５が、ＡＣＰクラウド１００ａを介して間接的に証明書検証情報を証明書検証サーバ１６０ｃから取得する例を挙げたが、必ずしもこれに限らない。検証情報取得部１５が、証明書検証サーバ１６０ｃから直接的に証明書検証情報を取得する構成としてもよい。

【0043】

認証代行部２１は、車載ＥＣＵ４０とアプリサーバ１４０との間での前述のサーバ認証及びクライアント認証におけるやり取りを仲介する。このやり取りは、Ｅ２Ｅ接続の通信確立過程におけるやり取りの一部である。認証代行部２１は、仲介したこのやり取りのログを保持する。

【0044】

ルール取得部２２は、ＷＡＮ１５０を介して、クラウドサーバ１００から検出ルールを取得する。ルール取得部２２は、取得した検出ルールをルール格納部２３に格納する。ルール取得部２２は、新たな検出ルールをルール格納部２３に格納することで、ルール格納部２３に格納される検出ルールを更新する。検出ルールとは、車載ＥＣＵ４０とアプリサーバ１４０との間での通信確立過程での障害（以下、通信確立過程障害）の原因別の原因特定用ログを指定するためルールである。検出ルールは、判定条件と出力する障害ログの内容とを指定するルールと言い換えてもよい。原因特定用ログは、通信確立過程障害の原因を特定できると推定されるログである。原因特定用ログは、通信確立過程障害の原因を特定できるログと言い換えてもよい。例えば検出ルールは、どのようなやり取りにおけるログのどの項目がどのような値である場合に、どの部分のログを障害ログとするといった条件を指定する情報とすればよい。指定する部分は、例えばログの文字列及び／又はエラーコードとすればよい。

【0045】

ルール格納部２３は、検出ルールを格納する。ルール格納部２３は、例えば不揮発性メモリによって実現すればよい。ルール格納部２３は、ルール取得部２２で取得した検出ルールを格納する構成に限らない。例えば、既知の障害については、予めルール格納部２３に検出ルールが格納されている構成としてもよい。なお、検出ルールは更新可能であることが好ましい。これは、未知の障害に対しても、検出ルールを更新することで対応可能となるためである。

【0046】

また、監視部１６は、通信確立過程での障害を検出する。この通信確立過程での障害を検出する処理が障害検出工程に相当する。監視部１６は、監視部１６で管理しているログに、ルール格納部２３に格納されている検出ルールに該当するログが存在した場合に、通信確立過程での障害を検出する。監視部１６は、検出ルールに該当するログが存在するか否かを定期的に確認することで、通信確立過程での障害を検出すればよい。監視部１６は、ＷＡＮ接続監視部１７、時刻配信代行部１８、名前解決代行部１９、検証代行部２０、及び認証代行部２１のそれぞれで、それぞれに対応したやり取りでの障害を検出すればよい。監視部１６は、ＷＡＮ接続監視部１７、時刻配信代行部１８、名前解決代行部１９、検証代行部２０、及び認証代行部２１のいずれで保持していたログが検出ルールに該当したかでこれを実現すればよい。

【0047】

監視部１６は、通信確立過程におけるどのやり取りで障害が検出されたかによって、障害要因も検出すればよい。障害要因としては、例えば以下の例が挙げられる。第１の障害要因として、ＷｉＦｉネットワークとの回線確立が成功しないことが挙げられる。これは、ＷＡＮ接続監視部１７で検出される。第２の障害要因として、セルラーネットワークとの回線確立が成功しないことが挙げられる。これも、ＷＡＮ接続監視部１７で検出される。第３の障害要因として、時刻情報の取得が成功しないことが挙げられる。これは、時刻配信代行部１８で検出される。第４の障害要因として、名前解決情報の取得が成功しないことが挙げられる。これは、名前解決代行部１９で検出される。第５の障害要因として、証明書検証情報の取得が成功しないことが挙げられる。これは、検証代行部２０で検出される。第６の障害要因として、サーバ認証若しくはクライアント認証が成功しないことが挙げられる。これは、認証代行部２１で検出される。なお、ここで述べたのはあくまで一例であって、他の障害要因を検出する構成としてもよい。

【0048】

監視部１６は、ルール格納部２３に格納されている検出ルールに該当するログが存在しない場合であっても、通信確立過程におけるやり取りで、正常時に期待されるやり取りと異なる異常やり取りが発生した場合に、通信確立過程での障害を検出する。異常やり取りの例としては、「応答がない」，「応答値が不正」，「エラー応答」等の種々のパターンが挙げられる。ＷＡＮ接続監視部１７、時刻配信代行部１８、名前解決代行部１９、検証代行部２０、及び認証代行部２１は、それぞれのやり取りにおいて異常やり取りが発生した場合に、通信確立過程での障害を検出する。監視部１６は、ＷＡＮ接続監視部１７、時刻配信代行部１８、名前解決代行部１９、検証代行部２０、及び認証代行部２１のどのやり取りでの障害を検出したかによって、障害要因まで特定すればよい。

【0049】

障害通知部２４は、監視部１６で通信確立過程での障害を検出した場合に、障害を検出したことをクラウドサーバ１００に通知する。これによれば、クラウドサーバ１００が、通信確立過程での障害の発生を把握することが可能になる。障害通知部２４は、障害を検出したことを、通信確立過程でのその障害が検出された車載ＥＣＵ４０にも通知すればよい。これによれば、車載ＥＣＵ４０が、通信確立過程での障害の発生を把握することが可能になる。障害通知部２４は、障害を検出したことを、通信確立過程でのその障害が検出されたアプリサーバ１４０にも通知すればよい。この場合、例えばクラウドサーバ１００を経由することで実現すればよい。これによれば、アプリサーバ１４０が、通信確立過程での障害の発生を把握することが可能になる。

【0050】

Ｅ２Ｅ接続の通信確立過程におけるやり取りのログを一元管理していない構成では、車外のサーバでも車載ＥＣＵ４０でも、通信確立過程での障害の発生を把握することが難しかった。これに対して、クラウドサーバ１００，車載ＥＣＵ４０，アプリサーバ１４０で通信確立過程での障害の発生を把握することが可能になると、障害への対処が行いやすくなる。また、障害通知部２４は、障害を検出したことを通知する際に、その障害について特定した障害要因を通知してもよい。これによれば、クラウドサーバ１００，車載ＥＣＵ４０，アプリサーバ１４０において、障害への対処がより行いやすくなる。

【0051】

ログ抽出部２５は、監視部１６で通信確立過程での障害を検出した場合に、監視部１６で管理しているログのうちから、その障害に関連すると推定されるログ（以下、原因特定用ログ）を抽出する。このログ抽出部２５での処理がログ抽出工程に相当する。ログ抽出部２５は、ルール格納部２３に格納されている検出ルールに該当するログが存在した場合には、その検出ルールで指定されるログを原因特定用ログとして抽出すればよい。ログ抽出部２５は、検出ルールで指定されるログだけでなく、そのログの時系列で前後のログ等の一定範囲のログも原因特定用ログとして抽出してもよい。ログ抽出部２５は、ＷＡＮ接続監視部１７、時刻配信代行部１８、名前解決代行部１９、検証代行部２０、及び認証代行部２１のうちに、検出ルールなしに、障害検出時に原因特定用ログを特定できる機能（以下、ログ特定機能）を有する部が存在する場合には、その部で特定できた原因特定用ログを、原因特定用ログとして抽出してもよい。

【0052】

原因特定用ログ出力部２６は、ログ抽出部２５で抽出した原因特定用ログを出力する。この原因特定用ログ出力部２６がログ出力部に相当する。また、この原因特定用ログ出力部での処理がログ出力工程に相当する。原因特定用ログ出力部２６は、ＷＡＮ１５０上のクラウドサーバ１００に向けて原因特定用ログを出力すればよい。クラウドサーバ１００は、車両の外部のネットワーク上の、障害の原因を特定するために原因特定用ログを収集するサーバと言い換えることができる。原因特定用ログ出力部２６は、ログ抽出部２５で抽出した原因特定用ログを、車載の故障診断装置に出力してもよい。車載の故障診断装置としては、ＯＢＤ（On-Board Diagnostics）が知られている。原因特定用ログは、例えばディーラー等でこのＯＢＤからスキャンツールによって読み取られ、読み取った情報をディーラーの端末からクラウドサーバ１００に送られてもよい。

【0053】

異常時ログ出力部２７は、監視部１６で管理しているログのうちの異常やり取りに関するログ（以下、異常時ログ）を出力する。この異常時ログ出力部２７もログ出力部に相当する。また、この異常時ログ出力部２７での処理もログ出力工程に相当する。異常時ログ出力部２７は、ＷＡＮ１５０上のクラウドサーバ１００に向けて異常時ログを出力させればよい。異常時ログ出力部２７は、ログ抽出部２５で原因特定用ログを抽出できないが、監視部１６で通信確立過程での障害を検出した場合に、異常時ログを出力すればよい。異常時ログとしては、障害が発生したやり取りのログを用いればよい。例えば、要求と応答とに関するログとしてもよいし、応答に関するログとしてもよい。異常時ログの範囲は、原因特定用ログの範囲に比べ、範囲が狭く絞られていないものとする。

【0054】

ルール取得部２２は、異常時ログ出力部２７で異常時ログをクラウドサーバ１００に向けて出力した場合に、ＷＡＮ１５０を介して、クラウドサーバ１００から、異常時ログの送付に対する回答として、その異常時ログをもとに設定された検出ルールを取得する。クラウドサーバ１００での、異常時ログをもとにした検出ルールの設定の詳細については後述する。

【0055】

＜クラウドサーバ１００の概略構成＞
クラウドサーバ１００は、例えばプロセッサ、メモリ、Ｉ／Ｏ、これらを接続するバスを備え、メモリに記憶された制御プログラムを実行することで、ＡＣＰクラウド１００ａの機能を実行する。ここで言うところのメモリは、コンピュータによって読み取り可能なプログラム及びデータを非一時的に格納する非遷移的実体的記憶媒体（non-transitory tangible storage medium）である。また、非遷移的実体的記憶媒体は、半導体メモリ等によって実現される。ＡＣＰクラウド１００ａの機能を有するクラウドサーバ１００がサーバ及び収集サーバに相当する。また、コンピュータによってＡＣＰクラウド１００ａの各機能ブロックの処理が実行されることが、通信管理方法が実行されることに相当する。

【0056】

ここで、図４を用いて、クラウドサーバ１００の概略的な構成について説明する。図２に示すように、クラウドサーバ１００は、ＡＣＰエンジン１０ａの機能ブロックとして、名前解決情報取得部１０１、検証情報取得部１０２、名前解決情報提供部１０３、検証情報提供部１０４、障害収集部１０５、原因特定用ログ取得部１０６、原因特定用ログ格納部１０７、異常時ログ取得部１０８、異常時ログ格納部１０９、ルール設定部１１０、及び設定送信部１１１を備える。なお、クラウドサーバ１００が実行する機能の一部又は全部を、１つ或いは複数のＩＣ等によりハードウェア的に構成してもよい。また、クラウドサーバ１００が備える機能ブロックの一部又は全部は、プロセッサによるソフトウェアの実行とハードウェア部材の組み合わせによって実現されてもよい。

【0057】

名前解決情報取得部１０１は、ＤＮＳサーバ１６０ｂから名前解決情報を取得する。検証情報取得部１０２は、証明書検証サーバ１６０ｃから証明書検証情報を取得する。名前解決情報提供部１０３は、名前解決情報取得部１０１によって取得された名前解決情報を、ＡＣＰエンジン１０ａに提供する。検証情報提供部１０４は、検証情報取得部１０２によって取得された証明書検証情報を、ＡＣＰエンジン１０ａに提供する。

【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】

１ オートモーティブ無線通信プラットフォーム、１０ 通信モジュール、１０ａ ＡＣＰエンジン（車両用装置）、１６ 監視部、２２ ルール取得部、２３ ルール格納部、２５ ログ抽出部、２６ 原因特定用ログ出力部（ログ出力部）、２７ 異常時ログ出力部（ログ出力部）、２５ ログ抽出部、４０ 車載ＥＣＵ、１００ クラウドサーバ、１００ａ ＡＣＰクラウド（サーバ）、１０６ 原因特定用ログ取得部（ログ取得部）、１０７ 原因特定用ログ格納部（ログ格納部）、１０８ 異常時ログ取得部（ログ取得部）、１０９ 異常時ログ格納部（ログ格納部）、１１０ ルール設定部、１１１ 設定送信部、１４０ アプリサーバ（接続先）

【図1】

【図2】

【図3】

【図4】

【図5】