ホーム > 特許ランキング > 日立Ａｓｔｅｍｏ株式会社
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024041392
(43)【公開日】2024-03-27
(54)【発明の名称】電子制御装置
(51)【国際特許分類】
G06F 21/55 20130101AFI20240319BHJP
H04L 9/32 20060101ALI20240319BHJP
【ＦＩ】
G06F21/55
H04L9/32 200E
【審査請求】未請求
【請求項の数】4
【出願形態】ＯＬ
(21)【出願番号】P 2022146182
(22)【出願日】2022-09-14
(71)【出願人】
【識別番号】509186579
【氏名又は名称】日立Ａｓｔｅｍｏ株式会社
(74)【代理人】
【識別番号】100129425
【弁理士】
【氏名又は名称】小川 護晃
(74)【代理人】
【識別番号】100168642
【弁理士】
【氏名又は名称】関谷 充司
(72)【発明者】
【氏名】小野寺 航平
(57)【要約】
【課題】電子制御装置におけるメッセージ認証処理で認証エラーが発生した際に、認証エラーが生じた異常の原因を判別できるようにする。
【解決手段】他の電子制御装置と通信可能に構成された電子制御装置が、他の電子制御装置から、メッセージ、当該他の電子制御装置においてメッセージが送信されるごとに前回の値と異なる値が所定規則に基づいて格納される送信識別情報、及び、当該他の電子制御装置において当該メッセージに基づいて生成された第１認証情報を含んだ情報を受信する通信部を備える。また、当該電子制御装置は、受信したメッセージに基づいて第２認証情報を生成して、受信した第１認証情報と生成した第２認証情報とを照合し、第１認証情報と第２認証情報との照合結果が不整合であり、且つ、受信した送信識別情報の値が固着状態であるときに、他の電子制御装置に異常が発生していると判別する判別部とを備える。
【選択図】図６
【解決手段】他の電子制御装置と通信可能に構成された電子制御装置が、他の電子制御装置から、メッセージ、当該他の電子制御装置においてメッセージが送信されるごとに前回の値と異なる値が所定規則に基づいて格納される送信識別情報、及び、当該他の電子制御装置において当該メッセージに基づいて生成された第１認証情報を含んだ情報を受信する通信部を備える。また、当該電子制御装置は、受信したメッセージに基づいて第２認証情報を生成して、受信した第１認証情報と生成した第２認証情報とを照合し、第１認証情報と第２認証情報との照合結果が不整合であり、且つ、受信した送信識別情報の値が固着状態であるときに、他の電子制御装置に異常が発生していると判別する判別部とを備える。
【選択図】図６
【特許請求の範囲】
【請求項1】
他の電子制御装置と通信可能に構成された電子制御装置であって、
前記他の電子制御装置から、メッセージ、当該他の電子制御装置においてメッセージが送信されるごとに前回の値と異なる値が所定規則に基づいて格納される送信識別情報、及び、当該他の電子制御装置において当該メッセージに基づいて生成された第１認証情報を含んだ情報を受信する通信部と、
受信した前記メッセージに基づいて第２認証情報を生成して、受信した前記第１認証情報と生成した前記第２認証情報とを照合し、前記第１認証情報と前記第２認証情報との照合結果が不整合であり、且つ、受信した前記送信識別情報の値が固着状態であるときに、前記他の電子制御装置に異常が発生していると判別する判別部と
を備える、電子制御装置。
前記他の電子制御装置から、メッセージ、当該他の電子制御装置においてメッセージが送信されるごとに前回の値と異なる値が所定規則に基づいて格納される送信識別情報、及び、当該他の電子制御装置において当該メッセージに基づいて生成された第１認証情報を含んだ情報を受信する通信部と、
受信した前記メッセージに基づいて第２認証情報を生成して、受信した前記第１認証情報と生成した前記第２認証情報とを照合し、前記第１認証情報と前記第２認証情報との照合結果が不整合であり、且つ、受信した前記送信識別情報の値が固着状態であるときに、前記他の電子制御装置に異常が発生していると判別する判別部と
を備える、電子制御装置。
【請求項2】
前記第１認証情報と前記第２認証情報との照合結果が不整合であることを示す値が所定規則に基づいて格納される認証異常識別情報と、
前記送信識別情報の値が固着状態であることを示す値が所定規則に基づいて格納される固着識別情報と
が記憶される記憶部をさらに備え、
前記判別部が前記他の電子制御装置に異常が発生していると判別するのは、前記認証異常識別情報の値と前記固着識別情報の値とが対応関係にある場合である、請求項１に記載の電子制御装置。
前記送信識別情報の値が固着状態であることを示す値が所定規則に基づいて格納される固着識別情報と
が記憶される記憶部をさらに備え、
前記判別部が前記他の電子制御装置に異常が発生していると判別するのは、前記認証異常識別情報の値と前記固着識別情報の値とが対応関係にある場合である、請求項１に記載の電子制御装置。
【請求項3】
前記判別部は、前記第１認証情報と前記第２認証情報との照合結果が不整合であり、且つ、受信した前記送信識別情報の値が固着状態でないときに、前記他の電子制御装置になりすまして送信された不正メッセージを受信したものと判別する、請求項１に記載の電子制御装置。
【請求項4】
前記第１認証情報と前記第２認証情報との照合結果が不整合であることを示す値が所定規則に基づいて格納される認証異常識別情報と、
前記送信識別情報の値が固着状態であることを示す値が所定規則に基づいて格納される固着識別情報と
が記憶される記憶部をさらに備え、
前記判別部が前記他の電子制御装置になりすまして送信された不正メッセージを受信したものと判別するのは、前記認証異常識別情報の値と前記固着識別情報の値とが対応関係にない場合である、請求項３に記載の電子制御装置。
前記送信識別情報の値が固着状態であることを示す値が所定規則に基づいて格納される固着識別情報と
が記憶される記憶部をさらに備え、
前記判別部が前記他の電子制御装置になりすまして送信された不正メッセージを受信したものと判別するのは、前記認証異常識別情報の値と前記固着識別情報の値とが対応関係にない場合である、請求項３に記載の電子制御装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、車両に搭載される電子制御装置に関する。
【背景技術】
【0002】
近年、車両の電子制御化に伴い、車載ネットワークが不正なサイバー攻撃を受けるリスクが高まっている。サイバー攻撃から車載ネットワークを守る技術として、メッセージ認証がある。この技術では、電子制御装置間において通信されているメッセージにメッセージ認証コード（Message Authentication Code：MAC）を付与して暗号化通信を行い、当該認証コードの整合性に基づいて、メッセージが正常に送信されたものかを認証する。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特開２０１５－１１４９０７号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ここで、車載ネットワークがサイバー攻撃を受けた場合、攻撃を受けた電子制御装置におけるメッセージ認証処理において認証エラーが発生する。しかし、かかるメッセージ認証処理では、通信相手側の電子制御装置の異常が原因で認証エラーが発生する場合もある。この場合、異常の原因がサイバー攻撃によるのか通信相手側の電子制御装置の異常によるのかを判別することが難しい。
【0005】
そこで、本発明の１つの態様では、電子制御装置におけるメッセージ認証処理で認証エラーが発生した際に、認証エラーが生じた異常の原因を判別できるようにすることを目的とする。
【課題を解決するための手段】
【0006】
本発明の１つの態様では、他の電子制御装置と通信可能に構成された電子制御装置が、前記他の電子制御装置から、メッセージ、当該他の電子制御装置においてメッセージが送信されるごとに前回の値と異なる値が所定規則に基づいて格納される送信識別情報、及び、当該他の電子制御装置において当該メッセージに基づいて生成された第１認証情報を含んだ情報を受信する通信部と、受信した前記メッセージに基づいて第２認証情報を生成して、受信した前記第１認証情報と生成した前記第２認証情報とを照合し、前記第１認証情報と前記第２認証情報との照合結果が不整合であり、且つ、受信した前記送信識別情報の値が固着状態であるときに、前記他の電子制御装置に異常が発生していると判別する判別部とを備える。
【発明の効果】
【0007】
本発明の１つの態様によれば、電子制御装置におけるメッセージ認証処理で認証エラーが発生した際に、認証エラーが生じた異常の原因を判別できるようになる。
【図面の簡単な説明】
【0008】
【図1】制御システムの構成の一例を示す図である。
【図2】故障コードの登録及び読み出しの仕組みの一例を示す図である。
【図3】ＣＡＮ通信によりメッセージを受信するソフトウェアプログラムの機能構成の一例を示す図である。
【図4】メッセージ認証コードを用いたメッセージ認証機能の仕組みを示す図である。
【図5】メッセージの構造及びカウンタの一例を示す図である。
【図6】メッセージ認証に基づく異常判別処理の一例を示す図である。
【図7】故障コードが登録される不揮発性メモリの領域の一例を示す図である。
【図8】メッセージの構造及びカウンタの一例を示す図である。
【図9】メッセージのメッセージカウンタ値と固着カウンタの値の対応関係の一例について説明する図である。
【図10】メッセージ認証に基づく異常判別処理の一例を示す図である。
【図11】異常判別処理の具体例のパターンを示す図である。
【図12】メッセージ認証に基づく異常判別処理の一例を示す図である。
【図13】故障コードが登録される不揮発性メモリの領域の一例を示す図である。
【発明を実施するための形態】
【0009】
以下、図面を参照しつつ、本発明の実施形態について説明する。なお、本明細書に記載する実施形態によって本発明が限定されるものではなく、異なる実施形態やその変形例は、適宜組み合わせることも可能である。
【0010】
［第１実施形態］
［システム構成］
図１は、本実施形態に係る制御システム１の一例を示す。制御システム１は、ＥＣＵ（Electronic Control Unit）１０及びＥＣＵ２０を備える。
ＥＣＵ１０及びＥＣＵ２０は、自動車等の車両に搭載され、車両の走行等に関連する各種装置の制御を行う。制御システム１は、例えば、制御対象の車載装置の種類により、エンジン制御等のパワートレイン制御系、電動パワーステアリング、ブレーキ制御等の車両制御系、エアバッグや周辺監視等のボディ制御系、ナビゲーションシステムや衛星測位システム（例えば、ＧＰＳ（Global Positioning System））等の情報系に分類され得る。ＥＣＵ１０及びＥＣＵ２０は、ＣＡＮ（Controller Area Network）プロトコルを用いて信号を送受信するネットワーク５０に接続されている。ネットワーク５０は、２線式通信を構成するＣＡＮ＿Ｈ５０Ａ及びＣＡＮ＿Ｌ５０Ｂのバスで構成されている。なお、通信方式はＣＡＮに限定されるものではなく、例えば、ＬＩＮ（Local Interconnect Network）、Ｅｔｈｅｒｎｅｔ（登録商標）、ＦｌｅｘＲａｙ等の任意の通信方法を用いることが可能である。
［システム構成］
図１は、本実施形態に係る制御システム１の一例を示す。制御システム１は、ＥＣＵ（Electronic Control Unit）１０及びＥＣＵ２０を備える。
ＥＣＵ１０及びＥＣＵ２０は、自動車等の車両に搭載され、車両の走行等に関連する各種装置の制御を行う。制御システム１は、例えば、制御対象の車載装置の種類により、エンジン制御等のパワートレイン制御系、電動パワーステアリング、ブレーキ制御等の車両制御系、エアバッグや周辺監視等のボディ制御系、ナビゲーションシステムや衛星測位システム（例えば、ＧＰＳ（Global Positioning System））等の情報系に分類され得る。ＥＣＵ１０及びＥＣＵ２０は、ＣＡＮ（Controller Area Network）プロトコルを用いて信号を送受信するネットワーク５０に接続されている。ネットワーク５０は、２線式通信を構成するＣＡＮ＿Ｈ５０Ａ及びＣＡＮ＿Ｌ５０Ｂのバスで構成されている。なお、通信方式はＣＡＮに限定されるものではなく、例えば、ＬＩＮ（Local Interconnect Network）、Ｅｔｈｅｒｎｅｔ（登録商標）、ＦｌｅｘＲａｙ等の任意の通信方法を用いることが可能である。
【0011】
本実施形態では、ＥＣＵ１０がメッセージの受信側であり、ＥＣＵ２０がメッセージの送信側（他の電子制御装置）であるものとして説明を行う。なお、本実施形態ではＥＣＵ１０及びＥＣＵ２０のみ例示しているが、制御システム１は、他のＥＣＵをさらに備え得る。また、制御システム１には、制御対象となる車載装置やセンサ等が接続されるが、ここでは図示及び説明を省略する。
また、制御システム１には、車両の外部に設置される故障診断機９０が、ネットワーク５０を介して接続されている。故障診断機９０は、ＥＣＵ１０及びＥＣＵ２０において故障（異常）が発生しているか否かを診断したり、異常の原因を診断したりする機能を有する。
また、制御システム１には、車両の外部に設置される故障診断機９０が、ネットワーク５０を介して接続されている。故障診断機９０は、ＥＣＵ１０及びＥＣＵ２０において故障（異常）が発生しているか否かを診断したり、異常の原因を診断したりする機能を有する。
【0012】
ＥＣＵ１０は、ＭＣＵ（Micro Controller Unit）１１を備える。ＭＣＵ１１は、プロセッサ１２、揮発性メモリ１３、不揮発性メモリ１４及びＣＡＮコントローラ１５を備える。プロセッサ１２は、不揮発性メモリ１４に格納されたソフトウェアプログラムをロードして実行することにより、ＥＣＵ１０が制御対象とする車載装置の制御処理を行う。ＣＡＮコントローラ１５は、送信ポートＴｘ及び受信ポートＲｘを経由し、ＣＡＮ＿Ｈ５１及びＣＡＮ＿Ｌ５２を介して他のＥＣＵ２０とＣＡＮプロトコルによる通信を行うための通信制御処理（ビットスタッフィング、通信調停、エラーハンドリング、ＣＲＣチェック等）を行う。なお、揮発性メモリ１３及び不揮発性メモリ１４が記憶部に相当する。
【0013】
また、ＥＣＵ１０は、通信インタフェースであるＣＡＮトランシーバ１６を備える。ＣＡＮトランシーバ１６は、バスに送信する電圧の発生や調整、動作電流の確保等を行い、ネットワーク５０に接続する機能を提供する。また、ＣＡＮトランシーバ１６は、ＣＡＮ＿Ｈ５１及びＣＡＮ＿Ｌ５２から信号を受信したときには、ＣＡＮ＿Ｈ５１及びＣＡＮ＿Ｌ５２における信号の電圧差に基づき、受信した信号が示すデータの値を識別する。
なお、ＥＣＵ２０もＥＣＵ１０と同様の構成を備えている。ＥＣＵ２０の内部構成の詳細については説明を省略する。
なお、ＥＣＵ２０もＥＣＵ１０と同様の構成を備えている。ＥＣＵ２０の内部構成の詳細については説明を省略する。
【0014】
［故障コードの登録及び送信の仕組み］
図２は、ＥＣＵ１０において異常が検出された場合に、ＥＣＵ１０において実行される故障コードの登録及び読み出しの仕組みについて示す図である。
ＭＣＵ１１のプロセッサ１２（図２では図示省略）は、異常が検知されると、所定の故障コードを、揮発性メモリ１３に一時的に記憶した後に、不揮発性メモリ１４に登録する（図２のＰ１）。プロセッサ１２は、ネットワーク５０に接続された外部の故障診断機９０からＣＡＮ＿Ｌ５０Ｂを介して送信された、故障コードを要求するサービスＩＤを、ＣＡＮトランシーバ１６及びＲｘポートを介して受信する（Ｐ２）。このとき、プロセッサ１２は、不揮発性メモリ１４に登録された故障コードを読み出す（Ｐ３）。そして、プロセッサ１２は、ＣＡＮコントローラ１５により、読み出した故障コードをＴｘポートから出力し、ＣＡＮトランシーバ１６を介してＣＡＮ＿Ｌ３３に送信する（Ｐ４、Ｐ５）。故障診断機９０では、このようにしてＥＣＵ１０から送信された故障コードを受信し、当該故障コードに基づいて異常の原因の診断等を行う。
図２は、ＥＣＵ１０において異常が検出された場合に、ＥＣＵ１０において実行される故障コードの登録及び読み出しの仕組みについて示す図である。
ＭＣＵ１１のプロセッサ１２（図２では図示省略）は、異常が検知されると、所定の故障コードを、揮発性メモリ１３に一時的に記憶した後に、不揮発性メモリ１４に登録する（図２のＰ１）。プロセッサ１２は、ネットワーク５０に接続された外部の故障診断機９０からＣＡＮ＿Ｌ５０Ｂを介して送信された、故障コードを要求するサービスＩＤを、ＣＡＮトランシーバ１６及びＲｘポートを介して受信する（Ｐ２）。このとき、プロセッサ１２は、不揮発性メモリ１４に登録された故障コードを読み出す（Ｐ３）。そして、プロセッサ１２は、ＣＡＮコントローラ１５により、読み出した故障コードをＴｘポートから出力し、ＣＡＮトランシーバ１６を介してＣＡＮ＿Ｌ３３に送信する（Ｐ４、Ｐ５）。故障診断機９０では、このようにしてＥＣＵ１０から送信された故障コードを受信し、当該故障コードに基づいて異常の原因の診断等を行う。
【0015】
［ＣＡＮメッセージ受信ソフトウェアプログラムの機能構成］
図３は、ＥＣＵ１０においてＣＡＮ通信によりメッセージを受信するソフトウェアプログラムの機能構成を示している。当該図３で示される機能構成においては、ＭＣＵ１１のプロセッサ１２でソフトウェアプログラムが実行されることによりその機能が実現される、ＣＡＮドライバ３１、デコード部３２及び判別部３３を含む。
ＣＡＮドライバ３１は、ＭＣＵ１１を直接制御し、Ｒｘポート及びＴｘポート及びＣＡＮコントローラ１５によってＣＡＮメッセージを送受信する機能を実現する。デコード部３２及び判別部３３は、受信したメッセージを加工して、メッセージのデータが正常であるかを認証するアプリケーション機能を有する。具体的には、デコード部３２は、ＣＡＮドライバ３１で取得したメッセージ内の信号を内部変数へ変換して格納するデコード機能を有する。また、判別部３３は、デコードしたメッセージのデータが有する値に異常があるか否かを診断する機能を有する。なお、ＣＡＮドライバ３１及びデコード部３２が通信部に相当する。また、本実施形態で説明するメッセージ認証処理に基づく異常判別処理は、判別部３３で実現される機能である。
図３は、ＥＣＵ１０においてＣＡＮ通信によりメッセージを受信するソフトウェアプログラムの機能構成を示している。当該図３で示される機能構成においては、ＭＣＵ１１のプロセッサ１２でソフトウェアプログラムが実行されることによりその機能が実現される、ＣＡＮドライバ３１、デコード部３２及び判別部３３を含む。
ＣＡＮドライバ３１は、ＭＣＵ１１を直接制御し、Ｒｘポート及びＴｘポート及びＣＡＮコントローラ１５によってＣＡＮメッセージを送受信する機能を実現する。デコード部３２及び判別部３３は、受信したメッセージを加工して、メッセージのデータが正常であるかを認証するアプリケーション機能を有する。具体的には、デコード部３２は、ＣＡＮドライバ３１で取得したメッセージ内の信号を内部変数へ変換して格納するデコード機能を有する。また、判別部３３は、デコードしたメッセージのデータが有する値に異常があるか否かを診断する機能を有する。なお、ＣＡＮドライバ３１及びデコード部３２が通信部に相当する。また、本実施形態で説明するメッセージ認証処理に基づく異常判別処理は、判別部３３で実現される機能である。
【0016】
［メッセージ認証コード（ＭＡＣ）によるメッセージ認証の仕組み］
図４は、メッセージ認証コード（以下、ＭＡＣと表記する）を用いたメッセージ認証機能の仕組みについて説明する図である。
メッセージの送信側であるＥＣＵ２０は、送信するメッセージ４１に基づいて認証情報を生成する。具体的には、ＥＣＵ２０は、メッセージ４１及び共通鍵４２ＡをＭＡＣアルゴリズム（AES：Advanced Encryption Standard）４３Ａに代入して、ＭＡＣ４４（第１認証情報）を生成する。そして、ＥＣＵ２０は、送信するメッセージ４１にＭＡＣ４４を付与して、メッセージの受信側であるＥＣＵ１０に送信する。
図４は、メッセージ認証コード（以下、ＭＡＣと表記する）を用いたメッセージ認証機能の仕組みについて説明する図である。
メッセージの送信側であるＥＣＵ２０は、送信するメッセージ４１に基づいて認証情報を生成する。具体的には、ＥＣＵ２０は、メッセージ４１及び共通鍵４２ＡをＭＡＣアルゴリズム（AES：Advanced Encryption Standard）４３Ａに代入して、ＭＡＣ４４（第１認証情報）を生成する。そして、ＥＣＵ２０は、送信するメッセージ４１にＭＡＣ４４を付与して、メッセージの受信側であるＥＣＵ１０に送信する。
【0017】
一方、メッセージの受信側であるＥＣＵ１０は、受信したメッセージ４１に基づいて認証情報を生成する。具体的には、ＥＣＵ２０から受信したメッセージ４１と、送信側のＥＣＵ２０において保持されている共通鍵４２Ａに対応する共通鍵４２Ｂとを、ＭＡＣアルゴリズム４３Ｂに代入する。これにより、ＥＣＵ１０において認証用ＭＡＣ４５（第２認証情報）が生成される。そして、ＥＣＵ１０は、ＥＣＵ２０から受信したメッセージ４１に付与されたＭＡＣ４４と、生成した認証用ＭＡＣ４５とを照合し、両者の照合結果が整合（一致）していれば、メッセージが正常に送信されたものとして認証する。一方、ＥＣＵ１０は、ＭＡＣ４４と認証用ＭＡＣ４５との照合結果が不整合（不一致）であれば、サイバー攻撃によってＥＣＵ２０になりすまして送信された不正メッセージを受信したものと判別し、受信したメッセージ４１を破棄する。この場合、ＥＣＵ１０は、当該不整合が発生した回数、すなわちＭＡＣ異常が発生した回数をカウントアップする。ＥＣＵ１０は、ＭＡＣ異常が連続発生した回数が所定回数を超えると、メッセージ認証異常であると判別する。なお、当該所定回数は任意に設定することが可能である。
【0018】
［メッセージの構造及びカウンタ］
ここで、送信側であるＥＣＵ２０から送信されるメッセージ４１の構造等について、図５を参照して説明する。
メッセージの送信側であるＥＣＵ２０では、揮発性メモリ（図示省略）においてメッセージカウンタ２０１を備えており、ＥＣＵ２０にメッセージを送信するごとに、メッセージカウンタ２０１をカウントアップする。
そして、ＥＣＵ２０は、メッセージ４１にメッセージカウンタ２０１の値であるメッセージカウンタ値４６を含めてＥＣＵ１０に送信する。すなわち、メッセージカウンタ２０１がカウントアップされているため、メッセージカウンタ値４６は、前回送信されたメッセージ４１のメッセージカウンタ値４６よりもカウントアップされており、前回と異なる値となっている。なお、メッセージカウンタ値４６が送信識別情報の一例であり、当該カウントアップされた値がメッセージカウンタ値４６に格納されることが、前回の値と異なる値が所定規則に基づいて格納されることの一例である。また、このとき、前述したように、ＥＣＵ２０は、メッセージ４１にＭＡＣ４４を付与して送信する。
なお、ＥＣＵ１０では、揮発性メモリ１３において、受信したメッセージのメッセージカウンタ値４６につき、前回のメッセージカウンタ値４６が識別できるように保持しておく。
ここで、送信側であるＥＣＵ２０から送信されるメッセージ４１の構造等について、図５を参照して説明する。
メッセージの送信側であるＥＣＵ２０では、揮発性メモリ（図示省略）においてメッセージカウンタ２０１を備えており、ＥＣＵ２０にメッセージを送信するごとに、メッセージカウンタ２０１をカウントアップする。
そして、ＥＣＵ２０は、メッセージ４１にメッセージカウンタ２０１の値であるメッセージカウンタ値４６を含めてＥＣＵ１０に送信する。すなわち、メッセージカウンタ２０１がカウントアップされているため、メッセージカウンタ値４６は、前回送信されたメッセージ４１のメッセージカウンタ値４６よりもカウントアップされており、前回と異なる値となっている。なお、メッセージカウンタ値４６が送信識別情報の一例であり、当該カウントアップされた値がメッセージカウンタ値４６に格納されることが、前回の値と異なる値が所定規則に基づいて格納されることの一例である。また、このとき、前述したように、ＥＣＵ２０は、メッセージ４１にＭＡＣ４４を付与して送信する。
なお、ＥＣＵ１０では、揮発性メモリ１３において、受信したメッセージのメッセージカウンタ値４６につき、前回のメッセージカウンタ値４６が識別できるように保持しておく。
【0019】
［メッセージ認証に基づく異常判別処理］
以下、図６を参照しながら、メッセージ認証に基づく異常判別処理の詳細について説明する。図６は、メッセージの受信側であるＥＣＵ１０において、ＭＣＵ１１のプロセッサ１２によって実行される処理を示すフローチャートである。当該処理は、ＥＣＵ１０において、ＥＣＵ２０からメッセージを受信したときに実行される。
以下、図６を参照しながら、メッセージ認証に基づく異常判別処理の詳細について説明する。図６は、メッセージの受信側であるＥＣＵ１０において、ＭＣＵ１１のプロセッサ１２によって実行される処理を示すフローチャートである。当該処理は、ＥＣＵ１０において、ＥＣＵ２０からメッセージを受信したときに実行される。
【0020】
ステップ１（図６においてＳ１と表記している。以下同様）で、ＥＣＵ１０は、図４で説明したＭＡＣによるメッセージ認証の仕組みに基づき、受信したメッセージ４１に付与されたＭＡＣ４４に異常が検出されたか否かを判定する。具体的には、ＥＣＵ１０は、ＭＡＣ４４と、受信したメッセージ４１を用いてＭＡＣアルゴリズムにより生成した認証用ＭＡＣ４５との照合結果が不整合であるか否かを判定する。ＭＡＣに異常が検出された場合には、メッセージ認証エラーが発生したものとしてステップ２に進み（Ｙｅｓ）、そうでない場合には、メッセージが正常に送信されたものとして、当該処理を終了する。
【0021】
ステップ２で、ＥＣＵ１０は、受信したメッセージ４１のメッセージカウンタ値４６が固着状態であるか否かを判定する。具体的には、ＥＣＵ１０は、受信したメッセージ４１に含まれる前回のメッセージカウンタ値４６を保持しておき、今回受信したメッセージカウンタ値４６と前回の値とを比較する。そして、前回の値と今回の値とが同じであれば、メッセージカウンタ値４６が固着状態であるものと判定する。メッセージカウンタ値４６が固着状態である場合には、ステップ３に進み（Ｙｅｓ）、固着状態でない場合には、ステップ４に進む（Ｎｏ）。
【0022】
ステップ３で、ＥＣＵ１０は、メッセージの送信側であるＥＣＵ２０において異常が発生していると判別し、ＥＣＵ２０の異常を示す故障コード（DTC：Diagnostic Trouble Code）を登録する。具体的には、ＥＣＵ１０は、図２で説明したように、当該故障コードを、揮発性メモリ１３に一時的に記憶した後に、不揮発性メモリ１４に登録する。
ステップ４で、ＥＣＵ１０は、外部からサイバー攻撃を受けたことにより、ＥＣＵ２０になりすまして送信された不正メッセージを受信したものと判別し、サイバー攻撃を受けたことを示す故障コードを登録する。具体的には、ＥＣＵ１０は、ステップ７と同様に、当該故障コードを、揮発性メモリ１３に一時的に記憶した後に、不揮発性メモリ１４に登録する。
ステップ４で、ＥＣＵ１０は、外部からサイバー攻撃を受けたことにより、ＥＣＵ２０になりすまして送信された不正メッセージを受信したものと判別し、サイバー攻撃を受けたことを示す故障コードを登録する。具体的には、ＥＣＵ１０は、ステップ７と同様に、当該故障コードを、揮発性メモリ１３に一時的に記憶した後に、不揮発性メモリ１４に登録する。
【0023】
なお、図７は、ステップ３及びステップ４で故障コードが登録される不揮発性メモリ１４の領域を示している。不揮発性メモリ１４は、外部に接続された故障診断機９０から故障コードを要求するサービスＩＤを受信したときに故障診断機９０に送信される故障コードが登録される領域１４１を備えている。ＥＣＵ１０では、異常を検出するごとに、当該領域１４１に故障コード（図７では故障コード１４１１として示している）を登録する。
【0024】
［第１実施形態による効果等］
以上説明した本実施形態によれば、メッセージ認証において異常が検出されたときに、その原因がメッセージの送信側のＥＣＵ２０における異常であるのか、外部からのサイバー攻撃が原因であるのかを判別することができる。
以上説明した本実施形態によれば、メッセージ認証において異常が検出されたときに、その原因がメッセージの送信側のＥＣＵ２０における異常であるのか、外部からのサイバー攻撃が原因であるのかを判別することができる。
【0025】
また、ＥＣＵ１０では、これらの原因を区別した故障コードを不揮発性メモリ１４に登録しておき、外部に接続された故障診断機９０から故障コードを要求するサービスＩＤを受信したときに、これらの原因を区別した故障コードを故障診断機９０に対して送信する。これにより、故障診断機９０では、故障原因を故障コードに基づいて特定する際に、サイバー攻撃とメッセージの送信側のＥＣＵ２０の異常とを誤判断するリスクを低減することが可能となる。また、このような異常発生時の原因調査の時間の短縮に繋がり、調査効率の向上の効果を得ることが可能となる。したがって、異常発生の原因に対して速やかに対処することが可能となる。但し、このような故障コードの登録及び送信は、少なくとも本発明の技術的思想を実現するにあたり必須の構成ではない。
【0026】
また、本実施形態では、送信識別情報の一例として、メッセージカウンタ値４６に、ＥＣＵ２０においてメッセージが送信されるごとにカウントアップされるメッセージカウンタ２０１の値が格納されており、これに基づいて固着状態を判別している。しかし、このようなカウントアップされた値に限らず、少なくとも前回の値と異なる値であることが識別できれば、任意のデータとすることができる。
【0027】
［第２実施形態］
次に、第２実施形態について説明する。第２実施形態は、メッセージ認証において異常が検出されたときに、異常の原因がメッセージの送信側のＥＣＵ２０における異常であるのか、外部からのサイバー攻撃が原因であるのかの判別の精度をさらに向上させるものである。以下、主として第１実施形態と異なる点についてのみ説明を行う。
次に、第２実施形態について説明する。第２実施形態は、メッセージ認証において異常が検出されたときに、異常の原因がメッセージの送信側のＥＣＵ２０における異常であるのか、外部からのサイバー攻撃が原因であるのかの判別の精度をさらに向上させるものである。以下、主として第１実施形態と異なる点についてのみ説明を行う。
【0028】
［メッセージの構造とカウンタ］
図８は、第２実施形態において送信側であるＥＣＵ２０から送信されるメッセージ４１の構造、並びに、メッセージの送信側であるＥＣＵ２０及び受信側であるＥＣＵ１０が備えるカウンタについて示している。
メッセージの送信側であるＥＣＵ２０では、第１実施形態と同様に、揮発性メモリ（図示省略）においてメッセージカウンタ２０１を備えており、ＥＣＵ２０にメッセージを送信するごとに、メッセージカウンタ２０１をカウントアップする。
そして、ＥＣＵ２０は、メッセージ４１にメッセージカウンタ２０１の値であるメッセージカウンタ値４６を含めて、ＥＣＵ１０に送信する。このとき、ＥＣＵ２０は、メッセージ４１にＭＡＣ４４を付与して送信する。
図８は、第２実施形態において送信側であるＥＣＵ２０から送信されるメッセージ４１の構造、並びに、メッセージの送信側であるＥＣＵ２０及び受信側であるＥＣＵ１０が備えるカウンタについて示している。
メッセージの送信側であるＥＣＵ２０では、第１実施形態と同様に、揮発性メモリ（図示省略）においてメッセージカウンタ２０１を備えており、ＥＣＵ２０にメッセージを送信するごとに、メッセージカウンタ２０１をカウントアップする。
そして、ＥＣＵ２０は、メッセージ４１にメッセージカウンタ２０１の値であるメッセージカウンタ値４６を含めて、ＥＣＵ１０に送信する。このとき、ＥＣＵ２０は、メッセージ４１にＭＡＣ４４を付与して送信する。
【0029】
一方、メッセージの受信側であるＥＣＵ１０では、揮発性メモリ１３において、ＭＡＣ異常カウンタ１０１を備える。ＭＡＣ異常カウンタ１０１は、ＭＡＣ異常が検出されるごとにカウントアップされるカウンタである。また、ＥＣＵ１０では、さらに固着カウンタ１０２を備える。この固着カウンタ１０２は、受信したメッセージ４１に含まれるメッセージカウンタ値４６の値が固着状態であることが検出されたときにカウントアップされるカウンタである。図９は、受信メッセージのメッセージカウンタ値４６（すなわち、ＥＣＵ２０のメッセージカウンタ２０１のカウンタ値）とＥＣＵ１０の固着カウンタ１０２のカウンタ値の対応関係について示している。図９（Ａ）に示すように、メッセージカウンタ２０１のメッセージカウンタ値４６が正常にカウントアップされているときには、ＥＣＵ１０は、固着カウンタ１０２をカウントアップしない。一方で、図９（Ｂ）に示すように、例えばＥＣＵ２０において何らかの異常が発生しており、メッセージカウンタ値４６が固着状態であるときには、ＥＣＵ１０は、固着状態を検出するごとに、固着カウンタ１０２をカウントアップする。例えば、ＥＣＵ２０において、本来送信されるはずのメッセージが送信されずに同じメッセージを毎回送信してしまう状態に陥った場合に、当該メッセージカウンタ値４６がカウントアップされずに固着した値が送信されることがある。また、ＥＣＵ２０のメモリ領域の固着等により、メッセージカウンタ２０１が正常にカウントアップされない場合等も考え得る。
【0030】
なお、ＭＡＣ異常カウンタ１０１が認証異常識別情報の一例であり、ＭＡＣ異常が検出されるごとにカウントアップされることが、第１認証情報と第２認証情報との照合結果が不整合であることを示す値が所定規則に基づいて格納されることの一例である。また、固着カウンタ１０２が固着識別情報の一例であり、受信したメッセージ４１に含まれるメッセージカウンタ値４６の値が固着状態であることが検出されたときにカウントアップされることが、送信識別情報の値が固着状態であることを示す値が所定規則に基づいて格納されることの一例である。
【0031】
［メッセージ認証に基づく異常判別処理］
以下、図１０を参照しながら、第２実施形態における、メッセージ認証に基づく異常判別処理の詳細について説明する。図１０は、メッセージの受信側であるＥＣＵ１０が備えるＭＣＵ１１のプロセッサ１２で実行される処理を示すフローチャートである。当該処理は、ＥＣＵ１０において、ＥＣＵ２０からメッセージを受信したときに実行される。
以下、図１０を参照しながら、第２実施形態における、メッセージ認証に基づく異常判別処理の詳細について説明する。図１０は、メッセージの受信側であるＥＣＵ１０が備えるＭＣＵ１１のプロセッサ１２で実行される処理を示すフローチャートである。当該処理は、ＥＣＵ１０において、ＥＣＵ２０からメッセージを受信したときに実行される。
【0032】
ステップ１１で、ＥＣＵ１０は、受信したメッセージ４１に付与されたＭＡＣ４４に異常が検出されたか否かを判定する。具体的には、ＥＣＵ１０は、ＭＡＣ４４と、受信したメッセージ４１を用いてＭＡＣアルゴリズムにより生成した認証用ＭＡＣ４５との照合結果が不整合であるか否かを判定する。ＭＡＣに異常が検出された場合には、メッセージ認証エラーが発生したものとしてステップ１２に進み（Ｙｅｓ）、そうでない場合には、メッセージが正常に送信されたものとして、ＭＡＣ異常カウンタ１０１及び固着カウンタ１０２の値をリセットし、当該処理を終了する。
ステップ１２で、ＥＣＵ１０は、ＭＡＣ異常カウンタ１０１のカウンタ値を１インクリメントする。これにより、ＭＡＣ異常カウンタ１０１がカウントアップされる。
ステップ１２で、ＥＣＵ１０は、ＭＡＣ異常カウンタ１０１のカウンタ値を１インクリメントする。これにより、ＭＡＣ異常カウンタ１０１がカウントアップされる。
【0033】
ステップ１３で、ＥＣＵ１０は、受信したメッセージ４１のメッセージカウンタ値４６が固着状態であるか否かを判定する。具体的には、ＥＣＵ１０は、受信したメッセージ４１に含まれる前回のメッセージカウンタ値４６を保持しておき、今回受信したメッセージカウンタ値４６と前回の値とを比較する。そして、前回の値と今回の値とが変化していなければ、メッセージカウンタ値４６が固着状態であるものと判定する。メッセージカウンタ値４６が固着状態である場合には、ステップ１４に進み（Ｙｅｓ）、固着状態でない場合には、ステップ１５に進む（Ｎｏ）。
ステップ４で、ＥＣＵ１０は、固着カウンタ１０２のカウンタ値を１インクリメントする。これにより、固着カウンタ１０２がカウントアップされる。
ステップ４で、ＥＣＵ１０は、固着カウンタ１０２のカウンタ値を１インクリメントする。これにより、固着カウンタ１０２がカウントアップされる。
【0034】
ステップ１５で、ＥＣＵ１０は、ＭＡＣ異常カウンタ１０１のカウンタ値が所定値以上であるか否かを判定する。換言すれば、ＥＣＵ１０は、ＭＡＣ異常が所定回数以上検出されたか否かを判定する。なお、当該処理を行う主たる目的は、ごく一時的な通信障害等に起因するＭＡＣ異常によって故障コードを登録してしまうことを防ぐためであり、少なくとも本実施形態において本発明を実施するにあたり必須ではない。また、当該所定回数は任意に設定することが可能である。ＭＡＣ異常が所定回数以上検出された場合には、ステップ６に進み（Ｙｅｓ）、そうでない場合には、当該処理を終了する。
【0035】
ステップ１６で、ＥＣＵ１０は、ＭＡＣ異常カウンタ１０１のカウンタ値と、固着カウンタ１０２のカウンタ値とが対応関係にあるか否かを判定する。ここでいう対応関係とは、例えば、ＭＡＣ異常カウンタ１０１のカウンタ値と固着カウンタ１０２のカウンタ値が同じ期間にカウントアップされている（同様に推移している）関係である。このとき、例えば、両カウンタ値が一致している場合には対応関係があるものとして判別することができる。また、カウンタ値が一致している場合に限らず、例えば、両カウンタ値が一定の差を維持したまま推移するなど、カウンタ値自体は異なっていても、同じ期間に同様の規則性で推移していれば、対応関係があるものと判別することが可能である。両カウンタ値が対応関係にある場合にはステップ１７に進み（Ｙｅｓ）、対応関係にない場合にはステップ１８に進む（Ｎｏ）。
【0036】
ステップ１７で、ＥＣＵ１０は、メッセージの送信側であるＥＣＵ２０において異常が発生していると判別し、ＥＣＵ２０の異常を示す故障コードを登録する。具体的には、ＥＣＵ１０は、当該故障コードを、揮発性メモリ１３に一時的に記憶した後に、不揮発性メモリ１４に登録する。
ステップ１８で、ＥＣＵ１０は、外部からサイバー攻撃を受けたことにより、ＥＣＵ２０になりすまして送信された不正メッセージを受信したものと判別し、サイバー攻撃を受けたことを示す故障コードを登録する。具体的には、ＥＣＵ１０は、ステップ１７と同様に、当該故障コードを、揮発性メモリ１３に一時的に記憶した後に、不揮発性メモリ１４に登録する。なお、ステップ１７及びステップ１８で故障コードが登録される不揮発性メモリ１４の領域については、図７に示した第１実施形態の領域と同様である。
ステップ１８で、ＥＣＵ１０は、外部からサイバー攻撃を受けたことにより、ＥＣＵ２０になりすまして送信された不正メッセージを受信したものと判別し、サイバー攻撃を受けたことを示す故障コードを登録する。具体的には、ＥＣＵ１０は、ステップ１７と同様に、当該故障コードを、揮発性メモリ１３に一時的に記憶した後に、不揮発性メモリ１４に登録する。なお、ステップ１７及びステップ１８で故障コードが登録される不揮発性メモリ１４の領域については、図７に示した第１実施形態の領域と同様である。
【0037】
ここで、ステップ１６～１８における、異常の原因を判別する処理について、図１１に示す具体例のパターンを参照して説明する。図１１（Ａ）及び図１１（Ｂ）には、それぞれ、ＭＡＣ異常カウンタ１０１、受信したメッセージに含まれるメッセージカウンタ値４６、固着カウンタ１０２の値の推移が示されている。破線で描かれている縦線は、メッセージを受信したタイミング（ｎ回目、ｎ＋１回目、ｎ＋２回目、ｎ＋３回目）を示している。なお、本説明においては、説明の便宜上、ＭＡＣ異常が１回検出されればメッセージ認証異常の原因を判別するものとして説明を行う。
【0038】
図１１（Ａ）に示す具体例では、ｎ＋１回目以降に、ＭＡＣ異常カウンタ１０１の値が１ずつカウントアップされている。すなわち、ＥＣＵ１０においてｎ＋１回目以降に受信したメッセージにおいて、メッセージ認証エラーが発生している状況である。このとき、受信したメッセージ４１に含まれるメッセージカウンタ値４６が、メッセージのｎ＋１回目の受信以降、ｎ回目と同じ１のまま固着している。この場合、固着カウンタ１０２は、ｎ回目とｎ＋１回目におけるメッセージカウンタ値４６が同じであるため、ｎ＋１回目以降、固着カウンタ１０２を１ずつカウントアップする。ここで、ＭＡＣ異常カウンタ１０１と固着カウンタ１０２とを照合すると、ｎ＋１回目以降、同様に１ずつカウントアップされており、そのカウンタ値の推移（変化）に対応関係がある。すなわち、この具体例においては、ＭＡＣ異常とメッセージカウンタ値４６の固着が同時に起きている。この場合、メッセージの送信側であるＥＣＵ２０において何らかの異常が発生している可能性が高い。このため、当該具体例においては、ＥＣＵ１０は、サイバー攻撃ではなくメッセージの送信側であるＥＣＵ２０において異常が発生していると判別し、ＥＣＵ２０の異常を示す故障コードを登録する。
【0039】
一方、図１１（Ｂ）に示す具体例では、ｎ回目以降に、ＭＡＣ異常カウンタ１０１の値が１ずつカウントアップされている。すなわち、ＥＣＵ１０においてｎ回目以降に受信したメッセージにおいて、メッセージ認証エラーが発生している状況である。一方、受信したメッセージ４１に含まれるメッセージカウンタ値４６が、ｎ回目は３であり、ｎ＋１回目では１になり、ｎ＋２回目も同じく１であり、ｎ＋３回目では４となっている。この場合、ＥＣＵ１０は、ｎ回目とｎ＋１回目におけるメッセージカウンタ値４６が異なるため、固着カウンタ１０２をカウントアップしない。一方、ｎ＋１回目とｎ＋２回目におけるメッセージカウンタ値４６が同じであるため、ｎ＋２回目で固着カウンタ１０２を１カウントアップする。そして、ｎ＋２回目とｎ＋３回目ではメッセージカウンタ値４６が異なるため、固着カウンタ１０２をカウントアップしない。ここで、ＭＡＣ異常カウンタ１０１と固着カウンタ１０２とを照合すると、カウント値が増えるタイミングが必ずしも一致しておらず、カウンタ値の推移（変化）に対応関係がない。すなわち、この具体例においては、ＭＡＣ異常が起きているときに、メッセージカウンタ値４６の固着が併せて起きているわけではない。この場合、メッセージカウンタ値４６には、規則性のない値がランダムに入っていると考えられ、メッセージの送信側であるＥＣＵ２０の状態とは無関係に何らかの異常が発生している可能性が高い。このため、当該具体例においては、ＥＣＵ１０は、サイバー攻撃を受けたことにより異常が発生していると判別し、サイバー攻撃を受けたことを示す故障コードを登録する。
【0040】
［第２実施形態による効果等］
以上説明した第２実施形態によれば、まず、第１実施形態と同様に、メッセージ認証において異常が検出されたときに、その原因がメッセージの送信側のＥＣＵ２０における異常であるのか、外部からのサイバー攻撃が原因であるのかを判別することができる。そして、ＭＡＣ異常カウンタ１０１のカウンタ値と固着カウンタ１０２のカウンタ値との対応関係に基づいて原因を判別することにより、少なくとも、メッセージ認証エラーがＥＣＵ２０の異常によるものであることを特定しやすくなり、原因の判別精度がより向上する。
以上説明した第２実施形態によれば、まず、第１実施形態と同様に、メッセージ認証において異常が検出されたときに、その原因がメッセージの送信側のＥＣＵ２０における異常であるのか、外部からのサイバー攻撃が原因であるのかを判別することができる。そして、ＭＡＣ異常カウンタ１０１のカウンタ値と固着カウンタ１０２のカウンタ値との対応関係に基づいて原因を判別することにより、少なくとも、メッセージ認証エラーがＥＣＵ２０の異常によるものであることを特定しやすくなり、原因の判別精度がより向上する。
【0041】
なお、本実施形態では、認証異常識別情報の一例として、ＭＡＣ異常が検出されるごとにカウントアップされるＭＡＣ異常カウンタ１０１を用いている。しかし、このようなカウンタ値に限らず、少なくともＭＡＣ異常が連続して発生している状況が識別できるデータであれば、任意のデータとすることができる。例えば、認証異常識別情報として、ＭＡＣ異常の発生状況を示す履歴情報を格納するようにしてもよい。また、本実施形態では、固着識別情報の一例として固着カウンタ１０２を用いている。しかし、このようなカウンタ値に限らず、少なくとも固着状態が連続して発生している状況が識別できるデータであれば、任意のデータとすることができる。例えば、固着識別情報として、固着状態の発生状況を示す履歴情報を格納するようにしてもよい。これらの履歴情報同士の対応関係によっても、ＭＡＣ異常と固着状態とが同じ期間に発生していることを識別することができる。
【0042】
なお、前述した異常判別処理において、ＭＡＣ異常カウンタ１０１のカウンタ値と、固着カウンタ１０２のカウンタ値とが対応関係にあるか否かを判定する基準とする期間の長さ（すなわち、何回分のカウントで判定するか）は任意である。より長い期間のカウンタ値に基づいて対応関係の有無を判定するほうが、判定の精度は向上すると考えられる。また一方で、短い期間のカウンタ値に基づいて対応関係の有無を判定すれば、精度の面では劣るものの、異常の原因の判別をより速やかに行うことができる。
【0043】
ここで、サイバー攻撃によって送信されたメッセージの場合、受信したメッセージ４１のメッセージカウンタ値４６に該当する範囲に、メッセージカウンタ２０１の値とはなり得ない異常な値が固着して入っている可能性もある。このため、前述した対応関係が存在する場合でも、メッセージカウンタ値４６の値がメッセージカウンタ２０１のカウンタ値となり得る範囲内の値でない場合には、サイバー攻撃を受けていると判別するようにしてもよい。また、このようにメッセージカウンタ値４６に異常な値が固着して入っている場合には、固着カウンタ１０２のカウントアップ自体を行わないようにしてもよい。
【0044】
また、前述した異常判別処理においては、ＭＡＣ異常が所定回数以上検出されたことを条件として、ＭＡＣ異常カウンタ１０１のカウンタ値と、固着カウンタ１０２のカウンタ値とが対応関係にあるか否かを判定している。これに加えて、メッセージカウンタ値４６の値が固着状態である回数が所定回数以上になったことを、当該対応関係の有無を判定するためのさらなる条件としてもよい。なお、当該所定回数は任意に設定することが可能である。これにより、ＭＡＣ異常と同様に、ごく一時的な通信障害等に起因してメッセージカウンタ値４６の値に異常が発生しているときにまで故障コードを登録してしまうことを防ぐことができる。
【0045】
［第３実施形態］
次に、第３実施形態について説明する。第３実施形態では、不揮発性メモリに対する故障コードの格納方法が第１実施形態及び第２実施形態と異なる。第１実施形態の異常判別処理では、図７を参照して説明したように、ＥＣＵ２０の異常を示す故障コードを、異常が発生するごとに不揮発性メモリ１４の領域１４１に登録している。しかし、例えば、当該異常が何度も発生して検出された場合等に、故障コードが多数登録されてしまう可能性がある。一方で、故障診断機９０で読み出せる故障コードの数には限りがある。このため、このように多数の故障コードが登録された場合、故障診断機９０側で読み取れないものが発生し、異常の原因の解析処理に支障が出てしまう可能性がある。第３実施形態では、このような課題を解決するための構成を有する。以下、第１実施形態及び第２実施形態と異なる点についてのみ説明を行う。
次に、第３実施形態について説明する。第３実施形態では、不揮発性メモリに対する故障コードの格納方法が第１実施形態及び第２実施形態と異なる。第１実施形態の異常判別処理では、図７を参照して説明したように、ＥＣＵ２０の異常を示す故障コードを、異常が発生するごとに不揮発性メモリ１４の領域１４１に登録している。しかし、例えば、当該異常が何度も発生して検出された場合等に、故障コードが多数登録されてしまう可能性がある。一方で、故障診断機９０で読み出せる故障コードの数には限りがある。このため、このように多数の故障コードが登録された場合、故障診断機９０側で読み取れないものが発生し、異常の原因の解析処理に支障が出てしまう可能性がある。第３実施形態では、このような課題を解決するための構成を有する。以下、第１実施形態及び第２実施形態と異なる点についてのみ説明を行う。
【0046】
図１２は、第３実施形態における、メッセージ認証に基づく異常判別処理を示すフローチャートである。ステップ２１～ステップ２６は、図１０で示した第２実施形態の異常判別処理におけるステップ２１～２６と同様であるため、説明を省略する。また、図１３は、第２実施形態において故障コードを書き込む不揮発性メモリ１４の領域を示している。
ステップ２７で、ＥＣＵ１０は、メッセージの送信側であるＥＣＵ２０において異常が発生していると判別し、ＥＣＵ２０の異常を示す故障コードを不揮発性メモリ１４の領域１４１に登録する（図１３では故障コード１４１１として示している）。当該領域１４１は、故障診断機９０から故障コードを要求する通常のサービスＩＤを受信したときに、故障診断機９０に対して送信する故障コードを格納する領域である。ここで、ＥＣＵ１０は、故障コードの登録が冗長になり得る場合、例えば、故障コードが前回に登録した故障コードと同じ場合等には、当該故障コードを領域１４１にさらに登録することを回避する。
ステップ２８で、ＥＣＵ１０は、故障コードの詳細情報を、不揮発性メモリ１４のうち、ステップ２７で故障コードを登録した１４１領域と異なる領域１４２に登録する（図１３では故障コード１４２１として示している）。具体的には、ＥＣＵ１０は、ステップ２７と異なり、前回の故障コードと同じ故障コードであった場合にも、当該別領域には毎回故障コードの登録を行う。このときＥＣＵ１０は、単に故障コードを示す情報だけではなく、異常の原因に関するさらに詳細な情報を領域１４２に登録してもよい。
ステップ２７で、ＥＣＵ１０は、メッセージの送信側であるＥＣＵ２０において異常が発生していると判別し、ＥＣＵ２０の異常を示す故障コードを不揮発性メモリ１４の領域１４１に登録する（図１３では故障コード１４１１として示している）。当該領域１４１は、故障診断機９０から故障コードを要求する通常のサービスＩＤを受信したときに、故障診断機９０に対して送信する故障コードを格納する領域である。ここで、ＥＣＵ１０は、故障コードの登録が冗長になり得る場合、例えば、故障コードが前回に登録した故障コードと同じ場合等には、当該故障コードを領域１４１にさらに登録することを回避する。
ステップ２８で、ＥＣＵ１０は、故障コードの詳細情報を、不揮発性メモリ１４のうち、ステップ２７で故障コードを登録した１４１領域と異なる領域１４２に登録する（図１３では故障コード１４２１として示している）。具体的には、ＥＣＵ１０は、ステップ２７と異なり、前回の故障コードと同じ故障コードであった場合にも、当該別領域には毎回故障コードの登録を行う。このときＥＣＵ１０は、単に故障コードを示す情報だけではなく、異常の原因に関するさらに詳細な情報を領域１４２に登録してもよい。
【0047】
ステップ２９で、ＥＣＵ１０は、外部からサイバー攻撃を受けたものと判別し、サイバー攻撃を受けたことを示す故障コードを不揮発性メモリ１４の領域１４１に登録する（図１３では故障コード１４１１として示している）。ここで、ステップ１７と同様に、ＥＣＵ１０は、故障コードの登録が冗長になり得る場合、例えば、故障コードが前回に登録した故障コードと同じ場合には、当該故障コードを領域１４１にさらに登録することを回避する。
ステップ３０で、ＥＣＵ１０は、故障コードの詳細情報を、不揮発性メモリ１４のうち、ステップ１７で故障コードを登録した１４１領域と異なる領域１４２に登録する（図１３では故障コード１４１２として示している）。具体的には、ＥＣＵ１０は、ステップ２８と同様に、前回の故障コードと同じ故障コードであった場合にも、当該別領域には毎回故障コードの登録を行う。このときＥＣＵ１０では、単に故障コードを示す情報だけではなく、異常の原因に関するさらに詳細な情報を領域１４２に登録してもよい。
ステップ３０で、ＥＣＵ１０は、故障コードの詳細情報を、不揮発性メモリ１４のうち、ステップ１７で故障コードを登録した１４１領域と異なる領域１４２に登録する（図１３では故障コード１４１２として示している）。具体的には、ＥＣＵ１０は、ステップ２８と同様に、前回の故障コードと同じ故障コードであった場合にも、当該別領域には毎回故障コードの登録を行う。このときＥＣＵ１０では、単に故障コードを示す情報だけではなく、異常の原因に関するさらに詳細な情報を領域１４２に登録してもよい。
【0048】
［第３実施形態による効果等］
かかる第３実施形態によれば、同じ原因の異常が連続して発生した場合、その原因及びその発生回数に関わらず、不揮発性メモリ１４の領域１４１には、１つの故障コードが登録される。このため、故障診断機９０から故障コードを要求する通常のサービスＩＤを受信したときに、故障診断機９０に対しては、領域１４１に登録された少数の故障コードのみが送信されることとなる。したがって、故障診断機９０側で読み取れない故障コードが発生して原因の解析処理に支障が出てしまうリスクを低減することができる。
また一方で、当該領域１４１と異なる領域１４２においては、詳細情報として、異常が発生するごとに故障コードが登録される。このため、例えば、故障診断機９０からこの詳細情報を要求するサービスＩＤを受信したときには、領域１４２に登録された全ての故障コードを含む詳細情報を送信することができる。したがって、故障診断機９０は、必要に応じて全ての異常について登録された故障コードの情報を読み出すことも可能である。
かかる第３実施形態によれば、同じ原因の異常が連続して発生した場合、その原因及びその発生回数に関わらず、不揮発性メモリ１４の領域１４１には、１つの故障コードが登録される。このため、故障診断機９０から故障コードを要求する通常のサービスＩＤを受信したときに、故障診断機９０に対しては、領域１４１に登録された少数の故障コードのみが送信されることとなる。したがって、故障診断機９０側で読み取れない故障コードが発生して原因の解析処理に支障が出てしまうリスクを低減することができる。
また一方で、当該領域１４１と異なる領域１４２においては、詳細情報として、異常が発生するごとに故障コードが登録される。このため、例えば、故障診断機９０からこの詳細情報を要求するサービスＩＤを受信したときには、領域１４２に登録された全ての故障コードを含む詳細情報を送信することができる。したがって、故障診断機９０は、必要に応じて全ての異常について登録された故障コードの情報を読み出すことも可能である。
【0049】
［その他］
以上に説明した本発明の実施形態は、本発明の技術的範囲で考え得る実施態様の一部に過ぎず、本発明の例示として開示されるものであって、本発明の技術的範囲を制限するものではない。また、各実施形態における機能的構成及び物理的構成は、前述の態様に限定されるものではなく、例えば、各機能や物理的資源を統合して実装したり、逆に、さらに分散して実装したり、さらには、構成の一部について他の構成の追加、削除、置換等をすることも可能である。
以上に説明した本発明の実施形態は、本発明の技術的範囲で考え得る実施態様の一部に過ぎず、本発明の例示として開示されるものであって、本発明の技術的範囲を制限するものではない。また、各実施形態における機能的構成及び物理的構成は、前述の態様に限定されるものではなく、例えば、各機能や物理的資源を統合して実装したり、逆に、さらに分散して実装したり、さらには、構成の一部について他の構成の追加、削除、置換等をすることも可能である。
【符号の説明】
【0050】
１…制御システム、１０…ＥＣＵ、１１…ＭＣＵ、１２…プロセッサ、１３…揮発性メモリ、１４…不揮発性メモリ、１５…ＣＡＮコントローラ、１６…ＣＡＮトランシーバ、１０１…ＭＡＣ異常カウンタ、１０２…固着カウンタ、２０…ＥＣＵ、２０１…メッセージカウンタ、４１…メッセージ、４４…ＭＡＣ、４６…メッセージカウンタ値、９０…故障診断機
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
