知財求人 - 知財ポータルサイト「IP Force」
特開2024-119683電子制御装置、異常原因判定方法、及び異常原因判定プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024119683
(43)【公開日】2024-09-03
(54)【発明の名称】電子制御装置、異常原因判定方法、及び異常原因判定プログラム
(51)【国際特許分類】
G06F 21/55 20130101AFI20240827BHJP
【ＦＩ】
G06F21/55
【審査請求】未請求
【請求項の数】14
【出願形態】ＯＬ
(21)【出願番号】P 2023026759
(22)【出願日】2023-02-22
(71)【出願人】
【識別番号】000004260
【氏名又は名称】株式会社デンソー
(74)【代理人】
【識別番号】230120499
【弁護士】
【氏名又は名称】藤江 和典
(74)【代理人】
【識別番号】100201385
【弁理士】
【氏名又は名称】中安 桂子
(72)【発明者】
【氏名】佐藤 惇
(72)【発明者】
【氏名】淺井 健史
(72)【発明者】
【氏名】福地 直也
(57)【要約】
【課題】
ＥＣＵに発生した異常の原因が故障であるか攻撃であるかを判定する。
【解決手段】
複数の装置に接続された電子制御装置１００であって、前記複数の装置にメッセージをそれぞれ送信する送信部１０１と、前記複数の装置で前記メッセージを用いて行われた認証の結果を示す認証結果情報を受信する受信部１０２と、前記認証結果情報に基づいて前記複数の装置がそれぞれ異常であるか否かを判定し、前記複数の装置の少なくとも１つが異常である場合に、前記複数の装置全てが異常であるか否かに応じて、前記異常の原因が攻撃であるか故障であるかを判定する判定部１０３と、を備える。
【選択図】図２
ＥＣＵに発生した異常の原因が故障であるか攻撃であるかを判定する。
【解決手段】
複数の装置に接続された電子制御装置１００であって、前記複数の装置にメッセージをそれぞれ送信する送信部１０１と、前記複数の装置で前記メッセージを用いて行われた認証の結果を示す認証結果情報を受信する受信部１０２と、前記認証結果情報に基づいて前記複数の装置がそれぞれ異常であるか否かを判定し、前記複数の装置の少なくとも１つが異常である場合に、前記複数の装置全てが異常であるか否かに応じて、前記異常の原因が攻撃であるか故障であるかを判定する判定部１０３と、を備える。
【選択図】図２
【特許請求の範囲】
【請求項1】
複数の装置に接続された電子制御装置（１００）であって、
前記複数の装置にメッセージをそれぞれ送信する送信部（１０１）と、
前記複数の装置で前記メッセージを用いて行われた認証の結果を示す認証結果情報を受信する受信部（１０２）と、
前記認証結果情報に基づいて前記複数の装置がそれぞれ異常であるか否かを判定し、前記複数の装置の少なくとも１つが異常である場合に、前記複数の装置全てが異常であるか否かに応じて、前記異常の原因が攻撃であるか故障であるかを判定する判定部（１０３）と、
を備える、電子制御装置。
前記複数の装置にメッセージをそれぞれ送信する送信部（１０１）と、
前記複数の装置で前記メッセージを用いて行われた認証の結果を示す認証結果情報を受信する受信部（１０２）と、
前記認証結果情報に基づいて前記複数の装置がそれぞれ異常であるか否かを判定し、前記複数の装置の少なくとも１つが異常である場合に、前記複数の装置全てが異常であるか否かに応じて、前記異常の原因が攻撃であるか故障であるかを判定する判定部（１０３）と、
を備える、電子制御装置。
【請求項2】
前記判定部は、前記複数の装置全てが異常である場合に、前記異常の原因が攻撃であると判定する、
請求項１記載の電子制御装置。
請求項１記載の電子制御装置。
【請求項3】
前記判定部は、前記複数の装置のうち一部の装置が異常である場合に、前記異常の原因が故障であると判定する、
請求項１記載の電子制御装置。
請求項１記載の電子制御装置。
【請求項4】
前記受信部はさらに、前記複数の装置のうち故障が検出された装置である故障装置から、前記故障が検出されたことを示す故障情報を受信し、
前記判定部は、前記受信部が前記故障情報を受信した場合に前記故障装置は異常であるとみなし、前記故障装置を含む前記複数の装置全てが異常であるか否かに応じて、前記異常の原因が攻撃であるか故障であるかを判定する、
請求項１記載の電子制御装置。
前記判定部は、前記受信部が前記故障情報を受信した場合に前記故障装置は異常であるとみなし、前記故障装置を含む前記複数の装置全てが異常であるか否かに応じて、前記異常の原因が攻撃であるか故障であるかを判定する、
請求項１記載の電子制御装置。
【請求項5】
前記受信部はさらに、前記複数の装置のうち故障が検出された装置である故障装置から、前記故障が検出されたことを示す故障情報を受信し、
前記判定部は、前記故障装置を除く前記複数の装置全てが異常であるか否かに応じて、前記異常の原因が攻撃であるか故障であるかを判定する、
請求項１記載の電子制御装置。
前記判定部は、前記故障装置を除く前記複数の装置全てが異常であるか否かに応じて、前記異常の原因が攻撃であるか故障であるかを判定する、
請求項１記載の電子制御装置。
【請求項6】
前記判定部が前記複数の装置のうち一の装置が正常であり、他の装置が異常であると判定した場合、前記送信部はさらに、前記一の装置に故障の有無を問い合わせる問い合わせ情報を送信し、
前記受信部は、前記一の装置である前記故障装置から前記故障情報を受信する、
請求項４又は５記載の電子制御装置。
前記受信部は、前記一の装置である前記故障装置から前記故障情報を受信する、
請求項４又は５記載の電子制御装置。
【請求項7】
前記受信部は、前記複数の装置のうち、前記メッセージを用いて行われた前記認証に失敗した装置のみから、前記認証結果情報を受信し、
前記判定部は、前記複数の装置のうち、前記受信部において前記認証結果情報が受信されていない装置は正常であると判定する、
請求項１記載の電子制御装置。
前記判定部は、前記複数の装置のうち、前記受信部において前記認証結果情報が受信されていない装置は正常であると判定する、
請求項１記載の電子制御装置。
【請求項8】
前記判定部は、前記送信部が前記メッセージを送信してから所定の時間が経過した後に判定を行う、
請求項７記載の電子制御装置。
請求項７記載の電子制御装置。
【請求項9】
当該電子制御装置は移動体に搭載されており、
前記送信部はさらに、前記判定部における判定結果を前記移動体の外部に送信する、
請求項１記載の電子制御装置。
前記送信部はさらに、前記判定部における判定結果を前記移動体の外部に送信する、
請求項１記載の電子制御装置。
【請求項10】
電子制御装置で実行される異常原因判定方法であって、
前記電子制御装置に接続された複数の装置にメッセージをそれぞれ送信し（Ｓ１０１）、
前記複数の装置で前記メッセージを用いて行われた認証の結果を示す認証結果情報を受信し（Ｓ１０２）、
前記認証結果情報に基づいて、前記複数の装置がそれぞれ異常であるか否かを判定し（Ｓ１０４）、
前記複数の装置の少なくとも１つが異常である場合に、前記複数の装置全てが異常であるか否かに応じて、前記異常の原因が攻撃であるか故障であるかを判定する（Ｓ１０６）、
異常原因判定方法。
前記電子制御装置に接続された複数の装置にメッセージをそれぞれ送信し（Ｓ１０１）、
前記複数の装置で前記メッセージを用いて行われた認証の結果を示す認証結果情報を受信し（Ｓ１０２）、
前記認証結果情報に基づいて、前記複数の装置がそれぞれ異常であるか否かを判定し（Ｓ１０４）、
前記複数の装置の少なくとも１つが異常である場合に、前記複数の装置全てが異常であるか否かに応じて、前記異常の原因が攻撃であるか故障であるかを判定する（Ｓ１０６）、
異常原因判定方法。
【請求項11】
電子制御装置で実行可能な異常原因判定プログラムであって、
前記電子制御装置に接続された複数の装置にメッセージをそれぞれ送信し（Ｓ１０１）、
前記複数の装置で前記メッセージを用いて行われた認証の結果を示す認証結果情報を受信し（Ｓ１０２）、
前記認証結果情報に基づいて、前記複数の装置がそれぞれ異常であるか否かを判定し（Ｓ１０４）、
前記複数の装置の少なくとも１つが異常である場合に、前記複数の装置全てが異常であるか否かに応じて、前記異常の原因が攻撃であるか故障であるかを判定する（Ｓ１０６）、
異常原因判定プログラム。
前記電子制御装置に接続された複数の装置にメッセージをそれぞれ送信し（Ｓ１０１）、
前記複数の装置で前記メッセージを用いて行われた認証の結果を示す認証結果情報を受信し（Ｓ１０２）、
前記認証結果情報に基づいて、前記複数の装置がそれぞれ異常であるか否かを判定し（Ｓ１０４）、
前記複数の装置の少なくとも１つが異常である場合に、前記複数の装置全てが異常であるか否かに応じて、前記異常の原因が攻撃であるか故障であるかを判定する（Ｓ１０６）、
異常原因判定プログラム。
【請求項12】
電子制御装置に接続された他の装置から、異なる複数のメッセージをそれぞれ受信する受信部（２０１）と、
前記複数のメッセージそれぞれを用いて認証を行う認証部（２０２）と、
前記認証部における認証が失敗した場合に異常を検出する検出部（２０３）と、
前記検出部が前記複数のメッセージの少なくとも１つについて異常を検出した場合に、前記複数のメッセージ全てについて異常を検出したか否かに応じて、前記異常の原因が攻撃であるか当該電子制御装置の故障であるかを判定する判定部（２０４）と、
を備える、電子制御装置（２００、２１０）。
前記複数のメッセージそれぞれを用いて認証を行う認証部（２０２）と、
前記認証部における認証が失敗した場合に異常を検出する検出部（２０３）と、
前記検出部が前記複数のメッセージの少なくとも１つについて異常を検出した場合に、前記複数のメッセージ全てについて異常を検出したか否かに応じて、前記異常の原因が攻撃であるか当該電子制御装置の故障であるかを判定する判定部（２０４）と、
を備える、電子制御装置（２００、２１０）。
【請求項13】
前記判定部は、前記複数のメッセージ全てについて異常を検出した場合に、前記異常の原因が当該電子制御装置の故障であると判定する、
請求項１２記載の電子制御装置。
請求項１２記載の電子制御装置。
【請求項14】
前記判定部は、前記複数のメッセージのうち一部のメッセージについて異常を検出した場合に、前記異常の原因が攻撃であると判定する、
請求項１２記載の電子制御装置。
請求項１２記載の電子制御装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、主として自動車に搭載される電子制御装置であって、電子制御装置で発生した異常の原因が攻撃であるか故障であるかを判定する電子制御装置、当該電子制御装置で実行される方法及びプログラムに関する。
【背景技術】
【0002】
近年、車車間通信や路車間通信のようなＶ２Ｘをはじめ、運転支援や自動運転制御を行う技術が注目されている。これに伴い、車両が通信機能を備えるようになり、いわゆる車両のコネクティッド化が進んでいる。この結果、車両が不正アクセスといったサイバー攻撃を受ける可能性が増加している。そのため、車両に対するサイバー攻撃を受けたことによって生じる車載システム内の異常を検知するとともに、その対応策を講じることが必要とされている。
【0003】
ところが、車載システム内に発生する異常は、サイバー攻撃によって発生する異常だけでなく、車載システムを構成する電子制御装置の故障によって発生するものがある。そのため、サイバー攻撃への対応を効果的に行うためには、車載システム内で発生した異常が攻撃に起因するものであるか、故障に起因するものであるかを見極める必要がある。
【0004】
例えば、特許文献１には、外部からのセキュリティ攻撃に起因するセキュリティ異常、及び車載システム内で生じた断線、ノイズ、故障等に起因するセーフティ異常の両方に対して適切に対処するために、記憶部にセキュリティ異常に関する管理情報及びセーフティ異常に関する管理情報を保存するとともに、演算部が、管理情報を用いてセキュリティ異常及びセーフティ異常のいずれであるかを判定するとともに、それぞれの異常に応じた対処を行うことが開示されている。
【先行技術文献】
【特許文献】
【0005】
特開２０１９－７３１０２
【発明の概要】
【発明が解決しようとする課題】
【0006】
ここで、発明者は詳細な検討の結果、以下の課題を見出した。
特許文献１によれば、セーフティ異常に相当する異常内容を予めセーフティ異常検証情報として保存しておき、車載システム内で発生した異常の内容がセーフティ異常検証情報に含まれるか否かを判定することによって、異常がセキュリティ異常であるかセーフティ異常であるかを判定している。ところが、故障に起因する異常内容が、攻撃に起因する異常内容と類似する場合がある。このような場合、特許文献１の手法では、異常がセキュリティ異常及びセーフティ異常のいずれであるかを判定することはできない。さらに、特許文献１の手法では、セキュリティ異常とセーフティ異常を判定するために、演算部に機能を追加したり、新たな記憶部を設ける必要がある。そのため、処理負荷が増大することに加えて、既存の車載システムの電子制御装置、特に、処理能力が低い電子制御装置に対して新たに特許文献１の手法を導入することは難しい。
特許文献１によれば、セーフティ異常に相当する異常内容を予めセーフティ異常検証情報として保存しておき、車載システム内で発生した異常の内容がセーフティ異常検証情報に含まれるか否かを判定することによって、異常がセキュリティ異常であるかセーフティ異常であるかを判定している。ところが、故障に起因する異常内容が、攻撃に起因する異常内容と類似する場合がある。このような場合、特許文献１の手法では、異常がセキュリティ異常及びセーフティ異常のいずれであるかを判定することはできない。さらに、特許文献１の手法では、セキュリティ異常とセーフティ異常を判定するために、演算部に機能を追加したり、新たな記憶部を設ける必要がある。そのため、処理負荷が増大することに加えて、既存の車載システムの電子制御装置、特に、処理能力が低い電子制御装置に対して新たに特許文献１の手法を導入することは難しい。
【0007】
そこで、本発明の目的は、複雑な演算処理を実行することなく、車載システム内で発生した異常が、サイバー攻撃に起因する異常であるか、故障に起因する故障であるかを判定することができる装置等を提供することになる。
【課題を解決するための手段】
【0008】
本開示の一態様による電子制御装置は、複数の装置に接続された電子制御装置（１００）であって、前記複数の装置にメッセージをそれぞれ送信する送信部（１０１）と、前記複数の装置で前記メッセージを用いて行われた認証の結果を示す認証結果情報を受信する受信部（１０２）と、前記認証結果情報に基づいて前記複数の装置がそれぞれ異常であるか否かを判定し、前記複数の装置の少なくとも１つが異常である場合に、前記複数の装置全てが異常であるか否かに応じて、前記異常の原因が攻撃であるか故障であるかを判定する判定部（１０３）と、を備える。
【0009】
本開示の他の態様による電子制御装置（２００、２１０）は、電子制御装置に接続された他の装置から、異なる複数のメッセージをそれぞれ受信する受信部（２０１）と、前記複数のメッセージそれぞれを用いて認証を行う認証部（２０２）と、前記認証部における認証が失敗した場合に異常を検出する検出部（２０３）と、前記検出部が前記複数のメッセージの少なくとも１つについて異常を検出した場合に、前記複数のメッセージ全てについて異常を検出したか否かに応じて、前記異常の原因が攻撃であるか当該電子制御装置の故障であるかを判定する判定部（２０４）と、を備える。
【0010】
なお、特許請求の範囲、及び本項に記載した発明の構成要件に付した括弧内の番号は、本発明と後述の実施形態との対応関係を示すものであり、本発明を限定する趣旨ではない。
【発明の効果】
【0011】
以上の構成によれば、電子制御装置で異常が発生した場合に、異常の原因が故障であるか攻撃であるかを判定することが可能となる。
【図面の簡単な説明】
【0012】
【図1】実施形態１の電子制御システムを説明する図
【図2】実施形態１の電子制御装置の構成例を説明する図
【図3】実施形態１の判定処理を説明する図
【図4】実施形態１の電子制御装置の処理動作を説明する図
【図5】実施形態１の電子制御システムの処理動作を説明する図
【図6】実施形態１の変形例の電子制御装置の処理動作を説明する図
【図7】実施形態２の電子制御装置の構成例を説明する図
【図8】実施形態２の判定処理を説明する図
【図9】実施形態２の電子制御装置の処理動作を説明する図
【図10】実施形態２の変形例の電子制御装置の構成例を説明する図
【発明を実施するための形態】
【0013】
以下、本発明の実施形態について、図面を参照して説明する。
【0014】
なお、本発明とは、特許請求の範囲又は課題を解決するための手段の項に記載された発明を意味するものであり、以下の実施形態に限定されるものではない。また、少なくともかぎ括弧内の語句は、特許請求の範囲又は課題を解決するための手段の項に記載された語句を意味し、同じく以下の実施形態に限定されるものではない。
【0015】
特許請求の範囲の従属項に記載の構成及び方法は、特許請求の範囲の独立項に記載の発明において任意の構成及び方法である。従属項に記載の構成及び方法に対応する実施形態の構成及び方法、並びに特許請求の範囲に記載がなく実施形態のみに記載の構成及び方法は、本発明において任意の構成及び方法である。特許請求の範囲の記載が実施形態の記載よりも広い場合における実施形態に記載の構成及び方法も、本発明の構成及び方法の例示であるという意味で、本発明において任意の構成及び方法である。いずれの場合も、特許請求の範囲の独立項に記載することで、本発明の必須の構成及び方法となる。
【0016】
実施形態に記載した効果は、本発明の例示としての実施形態の構成を有する場合の効果であり、必ずしも本発明が有する効果ではない。
【0017】
複数の実施形態がある場合、各実施形態に開示の構成は各実施形態のみで閉じるものではなく、実施形態をまたいで組み合わせることが可能である。例えば一の実施形態に開示の構成を、他の実施形態に組み合わせてもよい。また、複数の実施形態それぞれに開示の構成を集めて組み合わせてもよい。
【0018】
発明が解決しようとする課題に記載した課題は公知の課題ではなく、本発明者が独自に知見したものであり、本発明の構成及び方法と共に発明の進歩性を肯定する事実である。
【0019】
１．実施形態１
（１）電子制御システムＳ
図１は、後述する本実施形態の電子制御装置（ＥＣＵ：Electric Control Unit）１００を有する電子制御システムＳを説明する図である。電子制御システムＳは、ＥＣＵ１００を含む複数のＥＣＵから構成されている。
（１）電子制御システムＳ
図１は、後述する本実施形態の電子制御装置（ＥＣＵ：Electric Control Unit）１００を有する電子制御システムＳを説明する図である。電子制御システムＳは、ＥＣＵ１００を含む複数のＥＣＵから構成されている。
【0020】
本実施形態のＥＣＵ１００は「移動体」である車両に「搭載」されるＥＣＵであって、電子制御システムＳは車載システムである場合を例に挙げて説明する。しかしながら、本実施形態は、任意の電子制御システムに適用することが可能であり、車載システムに限定されるものではない。
以上は、他の実施形態のＥＣＵにおいても同様である。
以上は、他の実施形態のＥＣＵにおいても同様である。
【0021】
ここで、「移動体」とは、移動可能な物体をいい、移動速度は任意である。また移動体が停止している場合も当然含む。例えば、自動車、自動二輪車、自転車、歩行者、船舶、航空機、及びこれらに搭載される物を含み、またこれらに限らない。
「搭載」される、とは、移動体に直接固定されている場合の他、移動体に固定されていないが移動体と共に移動する場合も含む。例えば、移動体に乗った人が所持している場合、移動体に載置された積荷に搭載されている場合、が挙げられる。
「搭載」される、とは、移動体に直接固定されている場合の他、移動体に固定されていないが移動体と共に移動する場合も含む。例えば、移動体に乗った人が所持している場合、移動体に載置された積荷に搭載されている場合、が挙げられる。
【0022】
ＥＣＵ１００は、例えば、ＣＡＮ（Controller Area Network）、ＬＩＮ（Local Interconnect Network）といった車載通信ネットワークを介して、複数のＥＣＵ２０（「複数の装置」に相当）及びＥＣＵ３０に接続されている。あるいは、Ｅｔｈｅｒｎｅｔ（登録商標）やＷｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）等、有線無線を問わず任意の通信方式を用いて接続されてもよい。
【0023】
図１に示す電子制御システムＳはドメインＡ及びドメインＢを有しており、それぞれのドメインが、ＥＣＵ１００及びＥＣＵ２０からなる。ドメインは、電子制御システムＳを構成する複数のＥＣＵを機能や役割に応じて分類したものであり、ドメインコントローラと呼ばれるＥＣＵがドメイン毎にＥＣＵを管理する。図１に示す例では、ＥＣＵ１００がドメインコントローラとしての機能を有するマスターＥＣＵであり、スレーブＥＣＵであるＥＣＵ２０を管理している。しかしながら、ＥＣＵ１００とＥＣＵ２０とは並列に設けられてもよい。また、ＥＣＵ１００は、ゲートウェイ又はサブゲートウェイとしての機能を有するＥＣＵであってもよい。
【0024】
図１では、ＥＣＵ１００が３つのＥＣＵ２０（ＥＣＵ２０ａ～ＥＣＵ２０ｃ）に接続されている電子制御システムＳを図示しているが、当然のことながらＥＣＵ１００に接続されるＥＣＵ２０の数は任意である。本実施形態では、ドメインＡに属するＥＣＵについて説明するが、ドメインＢに属するＥＣＵも同様の構成及び機能を有するものである。
【0025】
図１に示すＥＣＵ３０は、車両の外部への無線通信機能を有する通信ＥＣＵ３０を想定している。しかしながら、ＥＣＵ１００自体が車両の外部との通信機能を有するＥＣＵであってもよい。
【0026】
（２）ＥＣＵ２０の構成
本実施形態の前提として、ＥＣＵ１００に接続されるＥＣＵ２０の構成を説明する。図１に示すとおり、ＥＣＵ２０は、認証部２１及び送信部２２をそれぞれ備える。
本実施形態の前提として、ＥＣＵ１００に接続されるＥＣＵ２０の構成を説明する。図１に示すとおり、ＥＣＵ２０は、認証部２１及び送信部２２をそれぞれ備える。
【0027】
認証部２１は、後述するＥＣＵ１００から送信されたメッセージを受信すると、受信したメッセージを用いて認証処理を行う。メッセージの認証処理は任意の手法を用いることができ、例えば、メッセージ認証コードを用いた、いわゆるＭＡＣ（ＭＡＣ：Message Authentication Code）認証の他、デジタル署名を用いた認証が挙げられる。認証部２１は、セキュリティセンサとも称される。なお、本実施形態におけるメッセージとは、車載通信ネットワークを介して送信されるフレームに含まれるデータを指してもよく、あるいは、データのまとまりとしてのフレームを指すものであってもよい。
【0028】
送信部２２は、認証部２１がメッセージを用いた認証処理を行った結果を取得し、認証処理の結果を示す認証結果情報を送信する。後述するとおり、本実施形態では、送信部２２は、認証が失敗した場合に認証結果情報を送信し、認証に成功した場合には認証結果情報を送信しない場合を例に挙げて説明する。しかしながら、送信部２２は、認証に成功した場合に限り認証結果情報を送信し、認証に失敗した場合には認証結果情報を送信しない構成であってもよい。あるいは、送信部２２は、認証の結果によらず、認証が失敗した場合及び認証に成功した場合のいずれも認証結果情報を送信してもよい。
【0029】
認証結果情報は、認証が失敗したことを示すものであればよく、その内容は問わない。例えば、認証結果情報は、認証処理の失敗によって異常を検出したことを通知する情報であってもよい。この場合、送信部２２は、認証結果情報をＥＣＵ１００に送信する送信機能に加えて、認証結果に基づいて異常を検出する異常検出部としての機能も有するといえる。このような送信部２２は、ＡＵＴＯＳＡＲ（AUTomotive Open System ARchitecture）仕様においてＩＤＳＭ（Intrusion Detection Systems Manager）と称される。
【0030】
（３）ＥＣＵ１００の構成
次に、図２を参照して、本実施形態のＥＣＵ１００構成を説明する。ＥＣＵ１００は、送信部１０１、受信部１０２、判定部１０３を備える。判定部１０３は、装置判定部１０４及び異常原因判定部１０５を実現する。
次に、図２を参照して、本実施形態のＥＣＵ１００構成を説明する。ＥＣＵ１００は、送信部１０１、受信部１０２、判定部１０３を備える。判定部１０３は、装置判定部１０４及び異常原因判定部１０５を実現する。
【0031】
ＥＣＵ１００は、汎用のＣＰＵ（Central Processing Unit）、ＲＡＭ等の揮発性メモリ、ＲＯＭ、フラッシュメモリ、又はハードディスク等の不揮発性メモリ、各種インターフェース、及びこれらを接続する内部バスで構成することができる。そして、これらのハードウェア上でソフトウェアを実行することにより、図２に記載の各機能ブロックの機能を発揮させるように構成することができる。
もちろん、ＥＣＵ１００を、ＬＳＩ等の専用のハードウェアで実現してもよい。
以上は、他の実施形態のＥＣＵにおいても同様である。
もちろん、ＥＣＵ１００を、ＬＳＩ等の専用のハードウェアで実現してもよい。
以上は、他の実施形態のＥＣＵにおいても同様である。
【0032】
ＥＣＵ１００は、本実施形態では半完成品としての電子制御装置の形態を想定しているが、これに限らない。例えば、部品の形態としては、半導体回路や半導体モジュール、半完成品の形態としては、電子制御装置、電子制御ユニット、システムボード、完成品の形態としては、サーバ、ワークステーション、パーソナルコンピュータ（ＰＣ）、タブレット、モバイルルータ、スマートフォン、携帯電話、ナビゲーションシステムが挙げられる。
なお、ＥＣＵ１００は、単一のＥＣＵの他、複数のＥＣＵで構成されてもよい。
以上は、他の実施形態のＥＣＵにおいても同様である。
なお、ＥＣＵ１００は、単一のＥＣＵの他、複数のＥＣＵで構成されてもよい。
以上は、他の実施形態のＥＣＵにおいても同様である。
【0033】
送信部１０１は、ＥＣＵ１００に接続された複数のＥＣＵ２０に、メッセージをそれぞれ送信する。ここで、送信部１０１が送信するメッセージは、後述する異常原因を判定するために使用される専用のメッセージであってもよく、車両の走行や操舵といった機能を実現するためにＥＣＵ１００がＥＣＵ２０に送信するメッセージを、本発明のメッセージとして使用してもよい。また、送信部１０１は、定期的にメッセージを送信してもよく、特定のイベントが発生した場合にメッセージを送信してもよい。
【0034】
送信部１０１はさらに、後述する判定部１０３における判定結果を、車外との通信機能を有するＥＣＵ３０に「送信」してもよい。この場合、ＥＣＵ３０は、ＥＣＵ１００から判定結果を受信すると、車両の外部に位置するサーバや、ＳＯＣ（Security Operation Center）等に送信する。あるいは、ＥＣＵ１００自体が外部通信機能を有する場合、ＥＣＵ１００から直接、判定結果を車外に送信してもよい。この場合、車内通信機能及び車外通信機能を有する構成を、まとめて送信部１０１と称する。
【0035】
ここで、「送信」する、とは、指定した他の装置に情報を直接的に伝送することはもちろん、別の装置を介して間接的に伝送する場合も含む。
【0036】
送信部１０１がＥＣＵ３０を介して判定結果を車両の外部に送信する場合、ＥＣＵ３０は、ドメインＡの判定結果だけでなく、他のドメイン（例えば、図１のドメインＢ）の判定結果を集約して送信してもよい。このように、ＥＣＵ３０が複数のＥＣＵ１００の判定結果を集約して外部に送信することで、車両の外部との通信負荷を抑制することができる。
【0037】
受信部１０２は、ＥＣＵ２０から、送信部１０１が送信したメッセージを用いて行われた認証の結果を示す「認証結果情報」を受信する。本実施形態では、受信部１０２は、認証が失敗したことを示す認証結果情報のみを受信する。
【0038】
ここで、「認証結果情報」を受信する、とは、認証が成功した結果のみを受信する場合、失敗した結果のみを受信する場合、並びに、成功した結果及び失敗した結果の両方を受信する場合、のいずれも含む。また、「認証結果情報」とは、認証の結果を直接的に示す情報はもちろん、認証の結果を間接的に示す情報であってもよい。
【0039】
判定部１０３は、装置判定部１０４及び異常原因判定部１０５を実現する。ここで、判定部１０３は、ＡＵＴＯＳＡＲ仕様においてＩＤＳＲ（Intrusion Detection Systems Reporter）と称される。あるいは、判定部１０３、及び、送信部１０１において判定結果を送信する機能をまとめてＩＤＳＲと称してもよい。
【0040】
判定部１０３の装置判定部１０４は、認証結果情報に基づいて、ＥＣＵ２０がそれぞれ異常であるか否かを判定する。具体的には、装置判定部１０４は、受信部１０２において認証結果情報が受信されたＥＣＵ２０は異常であると判定する。これに対し、認証結果情報が受信されていないＥＣＵ２０は正常であると判定する。
【0041】
なお、本実施形態では、認証が失敗したＥＣＵ２０のみから認証結果情報を受信するため、受信部１０２において認証結果情報が受信されていない場合、装置判定部１０４は、ＥＣＵ２０での認証が成功したために認証結果情報が受信されていないのか、ＥＣＵ２０での認証が完了していないために認証結果情報が受信されていないのか、を判断することはできない。そこで、本実施形態の装置判定部１０４は、送信部１０１がメッセージを送信してから所定の時間が経過した後に判定を行う。あるいは、装置判定部１０４は、メッセージを送信してから所定の時間が経過しても認証結果情報が受信されない場合には、ＥＣＵ２０に対して認証結果情報の送信を要求する情報を送信してもよい。なお、これらの構成は、認証に成功したＥＣＵ２０のみから認証結果情報を受信する構成の場合、及び、認証の結果によらず、全てのＥＣＵ２０から認証結果情報を受信する構成の場合にも適用することができる。
【0042】
異常原因判定部１０５は、装置判定部１０４が判定した結果、ＥＣＵ２０の少なくとも１つが異常である場合に、ＥＣＵ２０全てが異常であるか否かに応じて、ＥＣＵ２０の異常の原因が攻撃であるか故障であるかを判定する。具体的には、異常原因判定部１０５は、ＥＣＵ２０全てが異常である場合に、ＥＣＵ２０の異常の原因が攻撃であると判定する。また、異常原因判定部１０５は、ＥＣＵ２０全てではなく、一部のＥＣＵ２０が異常である場合に、ＥＣＵ２０の異常の原因が故障であると判定する。故障には、例えば、断線や摩耗といった装置の破損を伴うものはもちろん、ソフトウェアのエラーといった装置の破損を伴わないもの、ノイズのように一時的に発生する不具合等が挙げられる。
【0043】
また、装置判定部１０４が、認証結果情報に基づいて、ＥＣＵ２０全てに異常がないと判定した場合、ＥＣＵ２０は正常に動作しており故障も攻撃もないと判定することができる。
【0044】
ここで、ＥＣＵ２０全てとは、必ずしもＥＣＵ１００に接続されている全ＥＣＵ２０でなくともよい。例えば、ＥＣＵ１００に接続されている複数のＥＣＵ２０を、予めいくつかのグループに分類しておき、同じグループに属するＥＣＵ２０全てが異常であるか否かに応じて、ＥＣＵ２０の異常の原因が攻撃であるか故障であるかを判定してもよい。グループは、ＥＣＵ２０の機能、ＥＣＵ２０が接続されているバス、といった基準に基づいて設定される。また、ＥＣＵ１００が複数のドメインのドメインコントローラとして機能する場合には、ＥＣＵ２０が属するドメインに基づいてグループを設定してもよい。
【0045】
図３は、判定部１０３（すなわち、装置判定部１０４及び異常原因判定部１０５）による判定を説明する図である。図３における“０”は、装置判定部１０４が認証結果情報に基づいてＥＣＵ２０が正常であると判定した場合を、“１”はＥＣＵ２０が異常であると判定した場合を、それぞれ示している。
【0046】
図３に示すとおり、ＥＣＵ２０ａ～ＥＣＵ２０ｃのいずれも“０”、すなわち正常であると判定した場合、これらのＥＣＵ２０は正常であると判定する。これに対し、ＥＣＵ２０ａ、ＥＣＵ２０ｂ、ＥＣＵ２０ｃのうち、少なくとも１つが“１”、すなわち異常であると判定した場合、ＥＣＵ２０に発生した異常の原因が故障であると判定する。また、ＥＣＵ２０ａ～ＥＣＵ２０ｃの全てが“１”、すなわちＥＣＵ２０全てが異常であると判定した場合、これらのＥＣＵ２０に発生した異常の原因が攻撃であると判定する。
【0047】
ＣＡＮコントローラ、ＨＳＭ（Hardware Security Module）、Secure Data FlashといったＥＣＵ２０のハードウェアが故障した場合、ＥＣＵ２０は受信したメッセージを用いた認証処理を正常に実行することができず、認証処理に失敗してしまう。しかしながら、このようなＥＣＵ２０のハードウェアの故障が、同時に複数のＥＣＵ２０で発生する可能性は極めて低い。そこで、ＥＣＵ２０の一部が異常であると判定した場合には、ＥＣＵ２０の異常の原因が故障であると判定する。これに対し、電子制御システムＳが再送攻撃された場合、ＥＣＵ２０に対して一斉に不正メッセージが送信される可能性がある。そのため、再送攻撃によって不正メッセージを受信した全てのＥＣＵ２０は認証処理に失敗する。そこで、ＥＣＵ２０全てが認証処理に失敗し、ＥＣＵ２０全てが異常であると判定した場合には、ＥＣＵ２０の異常の原因が攻撃であると判定する。
【0048】
上述したように、送信部１０１は、判定部１０３における判定結果を、直接的に又は間接的に、車外に送信する。車外に送信する判定結果は、例えば、異常原因判定部１０５による判定結果、すなわち、異常の原因が故障であるか攻撃であるかを示す判定結果である。あるいは、送信部１０１は、異常原因判定部１０５の判定結果に代えて、又は加えて、いずれのＥＣＵ２０で異常が発生しているか、異常なＥＣＵ２０の数、正常なＥＣＵ２０の数などを送信してもよい。あるいは、送信部１０１は、ＥＣＵ２０が全て正常な場合にも、その判定結果を車外に送信してもよい。
【0049】
（４）ＥＣＵ１００の動作
次に、図４、図５を参照してＥＣＵ１００の動作を説明する。図４はＥＣＵ１００の動作を説明する図であり、図５は電子制御システムＳ全体の動作を説明する図である。図４及び図５で対応する処理は、同じ符号を付している。なお、以下の動作は、ＥＣＵ１００における異常原因判定方法を示すだけでなく、ＥＣＵ１００で実行される異常原因判定プログラムの処理手順を示すものである。そして、これらの処理は、図４で示した順序には限定されない。すなわち、あるステップでその前段のステップの結果を利用する関係にある等の制約がない限り、順序を入れ替えてもよい。
以上、本実施形態だけでなく、他の実施形態及び変形例においても同様である。
次に、図４、図５を参照してＥＣＵ１００の動作を説明する。図４はＥＣＵ１００の動作を説明する図であり、図５は電子制御システムＳ全体の動作を説明する図である。図４及び図５で対応する処理は、同じ符号を付している。なお、以下の動作は、ＥＣＵ１００における異常原因判定方法を示すだけでなく、ＥＣＵ１００で実行される異常原因判定プログラムの処理手順を示すものである。そして、これらの処理は、図４で示した順序には限定されない。すなわち、あるステップでその前段のステップの結果を利用する関係にある等の制約がない限り、順序を入れ替えてもよい。
以上、本実施形態だけでなく、他の実施形態及び変形例においても同様である。
【0050】
ＥＣＵ１００の送信部１０１は、ＥＣＵ２０にメッセージをそれぞれ送信する（Ｓ１０１）。
【0051】
ＥＣＵ２０ａの認証部２１は、ＥＣＵ１００からメッセージを受信すると、メッセージを用いた認証処理を行う（Ｓ１１）。
そして、送信部２２は、Ｓ１１の認証処理を行った結果、認証に失敗した場合に、ＥＣＵ１００に認証結果情報を送信する。
ＥＣＵ２０ｂ、ＥＣＵ２０ｃにおいても同様の処理を行う。
図５の例では、ＥＣＵ２０ａ、ＥＣＵ２０ｂでは認証処理が失敗し、ＥＣＵ２０ｃでは認証処理が成功した場合を例示している。
そして、送信部２２は、Ｓ１１の認証処理を行った結果、認証に失敗した場合に、ＥＣＵ１００に認証結果情報を送信する。
ＥＣＵ２０ｂ、ＥＣＵ２０ｃにおいても同様の処理を行う。
図５の例では、ＥＣＵ２０ａ、ＥＣＵ２０ｂでは認証処理が失敗し、ＥＣＵ２０ｃでは認証処理が成功した場合を例示している。
【0052】
受信部１０２は、ＥＣＵ２０から、Ｓ１０１で送信したメッセージを用いて行われた認証の結果を示す認証結果情報を受信する（Ｓ１０２）。
Ｓ１０１においてメッセージを送信してから所定の期間が経過すると（Ｓ１０３：Ｙ）、判定部１０３の装置判定部１０４は、認証結果情報に基づいて、ＥＣＵ２０がそれぞれ異常であるか否かを判定する（Ｓ１０４）。
ここで、判定部１０３の異常原因判定部１０５は、ＥＣＵ２０の少なくとも１つが異常である場合（Ｓ１０５：Ｙ）、ＥＣＵ２０全てが異常であるか否かに応じて、異常の原因が攻撃であるか故障であるかを判定する（Ｓ１０６）。
そして、送信部１０１は、判定部１０３の判定結果を、車両の外部に位置するサーバ等に送信する（Ｓ１０７）。
Ｓ１０１においてメッセージを送信してから所定の期間が経過すると（Ｓ１０３：Ｙ）、判定部１０３の装置判定部１０４は、認証結果情報に基づいて、ＥＣＵ２０がそれぞれ異常であるか否かを判定する（Ｓ１０４）。
ここで、判定部１０３の異常原因判定部１０５は、ＥＣＵ２０の少なくとも１つが異常である場合（Ｓ１０５：Ｙ）、ＥＣＵ２０全てが異常であるか否かに応じて、異常の原因が攻撃であるか故障であるかを判定する（Ｓ１０６）。
そして、送信部１０１は、判定部１０３の判定結果を、車両の外部に位置するサーバ等に送信する（Ｓ１０７）。
【0053】
（６）小括
以上、本実施形態によれば、複雑な演算を行うことなく、ひいては、ＥＣＵにおける処理負荷を増大させることなく、ＥＣＵ２０全てが異常であるか、ＥＣＵ２０の一部が異常であるかに応じて、異常の原因が攻撃及び故障のいずれであるかを判定することが可能となる。
以上、本実施形態によれば、複雑な演算を行うことなく、ひいては、ＥＣＵにおける処理負荷を増大させることなく、ＥＣＵ２０全てが異常であるか、ＥＣＵ２０の一部が異常であるかに応じて、異常の原因が攻撃及び故障のいずれであるかを判定することが可能となる。
【0054】
さらに、本実施形態によれば、ＥＣＵ１００が認証結果情報に基づいてＥＣＵ２０の異常原因を判定し、その判定結果のみを車両の外部送信することで、各ＥＣＵ２０の認証結果情報全てを車両の外部に送信する場合と比較して、車両の外部に送信する際の通信負荷を大幅に抑制するとともに、通信遅延の発生を防ぐことが可能となる。
【0055】
２．実施形態１の変形例
上述した実施形態では、認証処理に失敗したＥＣＵ２０のみが認証結果情報をＥＣＵ１００に送信する構成を説明した。ところが、ＥＣＵ２０が故障によって認証処理自体を実行することができず、その結果、認証結果情報をＥＣＵ１００に送信できない場合がある。このような場合、ＥＣＵ１００では、認証結果情報が受信されていないＥＣＵ２０を誤って正常であると判定してしまうおそれがある。そこで、本変形例では、ＥＣＵ１００において異常原因を判定する際に、ＥＣＵ２０における故障情報を用いることにより、異常原因の判定精度を高める構成を説明する。
上述した実施形態では、認証処理に失敗したＥＣＵ２０のみが認証結果情報をＥＣＵ１００に送信する構成を説明した。ところが、ＥＣＵ２０が故障によって認証処理自体を実行することができず、その結果、認証結果情報をＥＣＵ１００に送信できない場合がある。このような場合、ＥＣＵ１００では、認証結果情報が受信されていないＥＣＵ２０を誤って正常であると判定してしまうおそれがある。そこで、本変形例では、ＥＣＵ１００において異常原因を判定する際に、ＥＣＵ２０における故障情報を用いることにより、異常原因の判定精度を高める構成を説明する。
【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】
ＣＡＮコントローラ、ＨＳＭ、Secure Data FlashといったＥＣＵ２００のハードウェアが故障した場合、ＥＣＵ２００の認証部２０２は受信したメッセージを用いた認証処理を正常に実行することができない。そのため、認証部２０２で実行した認証処理はいずれも失敗してしまう。そこで、受信部２０１が受信した複数のメッセージ全ての認証処理に失敗し、異常検出部２０３が複数のメッセージ全てについて異常を検出した場合には、異常の原因がＥＣＵ２００の故障であると判定する。これに対し、ＥＣＵ２００が再送攻撃された場合、特定のメッセージ、例えば、特定の識別番号が付与されたメッセージや特定のＥＣＵから送信されたメッセージ等を偽装して不正メッセージが送信される可能性が高い。しかしながら、ＥＣＵ２００が受信する全てのメッセージについて、同時に再送攻撃が行われる可能性は低い。そこで、受信部２０１が受信した複数のメッセージのうち一部のメッセージについて認証処理に失敗し、異常検出部２０３が一部のメッセージについて異常を検出した場合には、異常の原因が攻撃であると判定する。
【0081】
（２）ＥＣＵ２００の動作
次に、図９を参照してＥＣＵ２００の動作を説明する。
ＥＣＵ２００の受信部２０１は、ＥＣＵ２０に接続された他のＥＣＵから、異なる複数のメッセージをそれぞれ受信する（Ｓ２０１）。
認証部２０２は、受信部２０１が受信した複数のメッセージそれぞれを用いて認証を行う（Ｓ２０２）。
異常検出部２０３は、認証部２０２における認証が失敗した場合に異常を検出する（Ｓ２０３）。
ここで、Ｓ２０３において、複数のメッセージの少なくとも１つについて異常を検出した場合（Ｓ２０４：Ｙ）、異常原因判定部２０４は、複数のメッセージ全てについて異常を検出したか否かに応じて、異常の原因が攻撃であるかＥＣＵ２００の故障であるかを判定する（Ｓ２０５）。
そして、送信部２０５は、異常原因判定部２０４における判定結果を、車両の外部に位置するサーバ等に送信する（Ｓ２０６）。
次に、図９を参照してＥＣＵ２００の動作を説明する。
ＥＣＵ２００の受信部２０１は、ＥＣＵ２０に接続された他のＥＣＵから、異なる複数のメッセージをそれぞれ受信する（Ｓ２０１）。
認証部２０２は、受信部２０１が受信した複数のメッセージそれぞれを用いて認証を行う（Ｓ２０２）。
異常検出部２０３は、認証部２０２における認証が失敗した場合に異常を検出する（Ｓ２０３）。
ここで、Ｓ２０３において、複数のメッセージの少なくとも１つについて異常を検出した場合（Ｓ２０４：Ｙ）、異常原因判定部２０４は、複数のメッセージ全てについて異常を検出したか否かに応じて、異常の原因が攻撃であるかＥＣＵ２００の故障であるかを判定する（Ｓ２０５）。
そして、送信部２０５は、異常原因判定部２０４における判定結果を、車両の外部に位置するサーバ等に送信する（Ｓ２０６）。
【0082】
（３）小括
以上、本実施形態によれば、複雑な演算を行うことなく、ひいては、ＥＣＵにおける処理負荷を増大させることなく、複数のメッセージ全てについて異常が検出されたか、又は複数のメッセージの一部について異常が検出されたかに応じて、異常の原因が攻撃及び故障のいずれであるかを判定することが可能となる。
以上、本実施形態によれば、複雑な演算を行うことなく、ひいては、ＥＣＵにおける処理負荷を増大させることなく、複数のメッセージ全てについて異常が検出されたか、又は複数のメッセージの一部について異常が検出されたかに応じて、異常の原因が攻撃及び故障のいずれであるかを判定することが可能となる。
【0083】
さらに、本実施形態によれば、ＥＣＵ２００が異常原因を判定し、その判定結果のみを車両の外部送信することで、各ＥＣＵ２００で行われたメッセージの認証結果をそれぞれ車両の外部に送信する場合と比較して、車両の外部に送信する際の通信負荷を大幅に抑制するとともに、遅延の発生を防ぐことが可能となる。
【0084】
４．実施形態２の変形例
上述した実施形態２では、ＥＣＵ２００がメッセージの認証処理を行い、認証が失敗した場合に異常を検出するとともに、異常の原因が攻撃であるか故障であるかを判定する処理を行う構成を説明した。本変形例では、認証処理及び異常の検出処理を行うＥＣＵと、異常原因の判定を行うＥＣＵとを分けて実行する構成を説明する。
上述した実施形態２では、ＥＣＵ２００がメッセージの認証処理を行い、認証が失敗した場合に異常を検出するとともに、異常の原因が攻撃であるか故障であるかを判定する処理を行う構成を説明した。本変形例では、認証処理及び異常の検出処理を行うＥＣＵと、異常原因の判定を行うＥＣＵとを分けて実行する構成を説明する。
【0085】
図１０は、本変形例のＥＣＵを説明する図である。図７における各構成と同じ機能を有する構成については、同じ符号を付している。本変形例では、本発明を実現するＥＣＵが複数のＥＣＵで構成されている。すなわち、ＥＣＵ２１０（「電子制御装置」に相当）が複数のＥＣＵ（ＥＣＵ２１１、ＥＣＵ２１２）で構成されている。
【0086】
ＥＣＵ２１１は、受信部２０１、認証部２０２、異常検出部２０３、及び送信部２１３を備える。また、ＥＣＵ２１２は、受信部２１４、異常原因判定部２０４、及び送信部２０５を備える。
【0087】
実施形態２と同様、ＥＣＵ２１１の受信部２０１は複数のメッセージをそれぞれ受信し、認証部２０２は受信部２０１が受信したメッセージそれぞれを用いて認証処理を行う。そして、異常検出部２０３は、認証部２０２における認証が失敗した場合に異常を検出する。ここで、上述した実施形態２では、異常検出部２０３における異常検出結果に基づいて異常原因を判定したが、本変形例では、送信部２１３は、異常検出部２０３において複数のメッセージについて異常を検出したかどうかを示す異常検出情報をＥＣＵ２１２に送信する。
【0088】
ＥＣＵ２１２の受信部２１４は、ＥＣＵ２１１から送信された異常検出情報を受信する。そして、異常原因判定部２０４は、受信部２１４で受信した異常検出情報に基づいて、異常原因を判定する。異常原因判定部２０４が異常原因を判定する方法は実施形態２と同じであるため、詳細な説明は省略する。そして、送信部２０５は、異常原因判定部２０４における判定結果を、車両の外部に送信する。
【0089】
なお、図１０では、１つのＥＣＵ２１１のみがＥＣＵ２１２に接続されている構成を例示しているが、ＥＣＵ２１２には、複数のＥＣＵ２１１が接続されてもよい。この場合、ＥＣＵ２１２は、複数のＥＣＵ２１１から異常検出を受信し、それぞれのＥＣＵ２１２について異常原因を判定する。
【0090】
本変形例では、各ＥＣＵ２１１がＥＣＵ２１２に異常検出情報を送信する必要があるため、一のＥＣＵ（実施形態２のＥＣＵ２００）において異常検出及び異常原因判定の両方を行う場合と比較して、車載ネットワークの通信量が増加する。しかしながら、認証処理及び異常の検出処理を行うＥＣＵと、異常原因の判定を行うＥＣＵとを分けることにより、例えば、電子制御システムの下層側に配置されたＥＣＵ（例えば、ＥＣＵ２１１）の処理能力が高くなく、異常原因判定処理を実現することが困難な場合であっても、本開示における異常原因判定を適用することが可能となる。
【0091】
５．実施形態１、２に共通する変形例
上述した実施形態１、２はいずれも、車載システム内で異常原因の判定処理を行い、車両の外部に判定結果を送信する構成を説明した。しかしながら、実施形態１、２における異常原因の判定処理は、車両の外部に配置されたサーバやＳＯＣ等で行ってもよい。この場合、車載システムでは、メッセージの認証結果をサーバやＳＯＣに送信する必要があるため、通信ネットワークの処理負荷を低減することはできない。しかしながら、判定処理をサーバやＳＯＣで行うことにより、車載システム全体の処理負荷を低減することが可能となる。
上述した実施形態１、２はいずれも、車載システム内で異常原因の判定処理を行い、車両の外部に判定結果を送信する構成を説明した。しかしながら、実施形態１、２における異常原因の判定処理は、車両の外部に配置されたサーバやＳＯＣ等で行ってもよい。この場合、車載システムでは、メッセージの認証結果をサーバやＳＯＣに送信する必要があるため、通信ネットワークの処理負荷を低減することはできない。しかしながら、判定処理をサーバやＳＯＣで行うことにより、車載システム全体の処理負荷を低減することが可能となる。
【0092】
６．総括
以上、本発明の各実施形態における電子制御装置等の特徴について説明した。
以上、本発明の各実施形態における電子制御装置等の特徴について説明した。
【0093】
各実施形態で使用した用語は例示であるので、同義の用語、あるいは同義の機能を含む用語に置き換えてもよい。
【0094】
実施形態の説明に用いたブロック図は、装置の構成を機能毎に分類及び整理したものである。それぞれの機能を示すブロックは、ハードウェア又はソフトウェアの任意の組み合わせで実現される。また、機能を示したものであることから、かかるブロック図は方法の発明、及び当該方法を実現するプログラムの発明の開示としても把握できるものである。
【0095】
各実施形態に記載した処理、フロー、及び方法として把握できる機能ブロック、については、一のステップでその前段の他のステップの結果を利用する関係にある等の制約がない限り、順序を入れ替えてもよい。
【0096】
各実施形態、及び特許請求の範囲で使用する、第１、第２、乃至、第Ｎ（Ｎは整数）、の用語は、同種の２以上の構成や方法を区別するために使用しており、順序や優劣を限定するものではない。
【0097】
各実施形態の電子制御装置は、車両に搭載される車載システムを構成する電子制御装置を前提としているが、本開示の電子制御装置は、特許請求の範囲で特に限定する場合を除き、任意の電子制御装置に適用される。
【0098】
また、本発明の装置の形態の例として、以下のものが挙げられる。
部品の形態として、半導体素子、電子回路、モジュール、マイクロコンピュータが挙げられる。
半完成品の形態として、電子制御装置（ＥＣＵ（Electric Control Unit））、システムボードが挙げられる。
完成品の形態として、携帯電話、スマートフォン、タブレット、パーソナルコンピュータ（ＰＣ）、ワークステーション、サーバが挙げられる。
その他、通信機能を有するデバイス等を含み、例えばビデオカメラ、スチルカメラ、カーナビゲーションシステムが挙げられる。
部品の形態として、半導体素子、電子回路、モジュール、マイクロコンピュータが挙げられる。
半完成品の形態として、電子制御装置（ＥＣＵ（Electric Control Unit））、システムボードが挙げられる。
完成品の形態として、携帯電話、スマートフォン、タブレット、パーソナルコンピュータ（ＰＣ）、ワークステーション、サーバが挙げられる。
その他、通信機能を有するデバイス等を含み、例えばビデオカメラ、スチルカメラ、カーナビゲーションシステムが挙げられる。
【0099】
また各装置に、アンテナや通信用インターフェースなど、必要な機能を追加してもよい。
【0100】
加えて、本発明は、各実施形態で説明した構成及び機能を有する専用のハードウェアで実現できるだけでなく、メモリやハードディスク等の記録媒体に記録した本発明を実現するためのプログラム、及びこれを実行可能な専用又は汎用ＣＰＵ及びメモリ等を有する汎用のハードウェアとの組み合わせとしても実現できる。
【0101】
専用や汎用のハードウェアの非遷移的実体的記録媒体（例えば、外部記憶装置（ハードディスク、ＵＳＢメモリ、ＣＤ／ＢＤ等）、又は内部記憶装置（ＲＡＭ、ＲＯＭ等））に格納されるプログラムは、記録媒体を介して、あるいは記録媒体を介さずにサーバから通信回線を経由して、専用又は汎用のハードウェアに提供することもできる。これにより、プログラムのアップグレードを通じて常に最新の機能を提供することができる。
【産業上の利用可能性】
【0102】
本開示は、主として自動車に搭載される車載用電子制御装置、車載用電子制御装置が実行可能なプログラム、及び、車載用電子制御装置で実行されるプログラムのプログラム生成方法を説明したが、自動二輪車、船舶、鉄道、航空機等、移動する移動体全般に適用することが可能である。また、移動体に限らず、マイクロコンピュータを包含する製品全般に適用可能である。
【符号の説明】
【0103】
１００、２００、２１０ 電子制御装置、１０１ 送信部、１０２、２０１ 受信部、１０３、２０４ 判定部、２０２ 認証部、２０３ 検出部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
