特許 7606983 決定方法、決定システム及びプログラム

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

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

(11)【特許番号】

(24)【登録日】2024-12-18

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

(54)【発明の名称】決定方法、決定システム及びプログラム

(51)【国際特許分類】

   H04L 12/28 20060101AFI20241219BHJP

   B60R 16/023 20060101ALI20241219BHJP

【ＦＩ】

H04L12/28 100A

B60R16/023 P

【請求項の数】 10

(21)【出願番号】P 2021567259

(86)(22)【出願日】2020-12-11

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

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

(87)【国際公開日】2021-07-01

【審査請求日】2023-09-13

(31)【優先権主張番号】P 2019231730

(32)【優先日】2019-12-23

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

(73)【特許権者】

【識別番号】514136668

【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ

【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】100109210

【弁理士】

【氏名又は名称】新居 広守

(74)【代理人】

【識別番号】100137235

【弁理士】

【氏名又は名称】寺谷 英作

(74)【代理人】

【識別番号】100131417

【弁理士】

【氏名又は名称】道坂 伸一

(72)【発明者】

【氏名】前田 学

(72)【発明者】

【氏名】国宗 大介

【審査官】速水 雄太

(56)【参考文献】

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

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

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

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

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

Ｂ６０Ｒ １６／０２３

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

【請求項1】

ネットワーク及び前記ネットワークに接続される１以上の電子制御ユニットを含む車載ネットワークシステムにおける不正通信の検知に用いられる基準メッセージの決定方法であって、
前記基準メッセージは、前記ネットワークに送出されるメッセージが異常メッセージであるか否かの判定の基準に用いられるメッセージであり、
前記決定方法は、
前記基準メッセージの候補である１以上の基準メッセージ候補に関する候補情報を保存する保存ステップと、
前記保存ステップで保存された前記候補情報に含まれる前記１以上の基準メッセージ候補に基づいて、複数のルールの中から前記基準メッセージを決定するためのルールを決定する第１決定ステップと、
前記第１決定ステップで決定された前記ルールを用いて、前記１以上の基準メッセージ候補から前記基準メッセージを決定する第２決定ステップとを含み、
前記第１決定ステップでは、前記複数のルールのそれぞれについて前記１以上の基準メッセージ候補の中から前記基準メッセージを決定することの適切度合いを示す適切度を算出し、前記複数のルールのそれぞれについて算出された前記適切度に基づいて、前記基準メッセージを決定するためのルールを決定し、
前記適切度は、前記ネットワークに送出されるメッセージに対する予測値と、前記１以上の基準メッセージ候補が示す値それぞれとの第１の差を算出し、算出された２以上の前記第１の差同士の差である第２の差として算出される、
決定方法。

【請求項2】

前記第１決定ステップでは、前記複数のルールの中で、前記適切度が最も高いルールを、前記１以上の基準メッセージ候補から前記基準メッセージを決定するためのルールに決定する、
請求項１に記載の決定方法。

【請求項3】

前記第１決定ステップにおいて、前記１以上の基準メッセージ候補が示す値が３つ以上ある場合、前記予測値に近い２つの前記値を抽出し、抽出した２つの前記値と前記予測値とに基づいて２つの前記第１の差を算出する、
請求項１又は２に記載の決定方法。

【請求項4】

前記予測値は、過去に決定された前記基準メッセージが示す値に基づいて算出される、
請求項１～３のいずれか１項に記載の決定方法。

【請求項5】

前記予測値は、予め作成された予測モデルに同一ＩＤの前記１以上の基準メッセージ候補を入力することで取得される、
請求項１～３のいずれか１項に記載の決定方法。

【請求項6】

前記複数のルールは、前記ネットワークに送出されるメッセージが送信される周期に基づいて前記基準メッセージを決定するための周期判定ルール、及び、前記ネットワークに送出されるメッセージに含まれるデータの値に基づいて前記基準メッセージを決定するためのデータ判定ルールの少なくとも一つを含む、
請求項１～５のいずれか１項に記載の決定方法。

【請求項7】

さらに、前記ネットワークに送出されるメッセージが異常メッセージであるか否かを判定する判定ステップを含み、
前記１以上の基準メッセージ候補には、前記判定ステップにおいて異常であると判定された前記異常メッセージを含み、
前記第２決定ステップでは、前記１以上の基準メッセージ候補のうち前記異常メッセージ以外のメッセージが前記基準メッセージに決定される、
請求項１～６のいずれか１項に記載の決定方法。

【請求項8】

さらに、前記ネットワークに送出されるメッセージが異常メッセージであるか否かを判定する判定ステップを含み、
前記第２決定ステップでは、現在の受信周期において正常と判定された１以上のメッセージを基準メッセージ候補として、次の受信周期における基準メッセージを、前記次の受信周期の前に決定する、
請求項１～６のいずれか１項に記載の決定方法。

【請求項9】

ネットワーク及び前記ネットワークに接続される１以上の電子制御ユニットを含む車載ネットワークシステムにおける不正通信の検知に用いられる基準メッセージの決定システムであって、
１以上のプロセッサと、
記憶部とを備え、
前記基準メッセージは、前記ネットワークに送出されるメッセージが異常メッセージであるか否かの判定の基準に用いられるメッセージであり、
前記１以上のプロセッサは、前記記憶部を用いて、
前記基準メッセージの候補である１以上の基準メッセージ候補に関する候補情報を保存し、
保存された前記候補情報に含まれる前記１以上の基準メッセージ候補に基づいて、複数のルールの中から前記基準メッセージを決定するためのルールを決定し、
決定されたルールを用いて、前記１以上の基準メッセージ候補から前記基準メッセージを決定し、
前記基準メッセージを決定するためのルールの決定において、前記複数のルールのそれぞれについて前記１以上の基準メッセージ候補の中から前記基準メッセージを決定することの適切度合いを示す適切度を算出し、前記複数のルールのそれぞれについて算出された前記適切度に基づいて、前記基準メッセージを決定するためのルールを決定し、
前記適切度は、前記ネットワークに送出されるメッセージに対する予測値と、前記１以上の基準メッセージ候補が示す値それぞれとの第１の差を算出し、算出された２以上の前記第１の差同士の差である第２の差として算出される、
決定システム。

【請求項10】

請求項１～８のいずれか１項に記載の決定方法をコンピュータに実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、ネットワークシステムにおける不正通信の検知に用いられる基準メッセージの決定方法等に関する。

【背景技術】

【0002】

近年、自動車の中のシステムには、電子制御ユニット（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ、以下、ＥＣＵとも表記する）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の通信規格が存在する。その中でも最も主流な車載ネットワークの規格の一つに、Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ（以下、ＣＡＮとも表記する）がある。

【0003】

ＣＡＮの規格によるネットワーク（以下、ＣＡＮネットワークとも表記する）では、通信路（バス）は２本のケーブルで構成され、バスに接続されているＥＣＵはノードとも呼ばれる。バスに接続されている各ノードは、フレーム又はメッセージと呼ばれる単位でデータを送受信する。またＣＡＮでは、データの送信先又は送信元を示す識別子は用いられない。フレームを送信するノード（以下、送信ノードとも表記するう）は、メッセージ毎にメッセージの種類を示すメッセージＩＤと呼ばれるＩＤを付けて送信、つまりバスに信号を送出する。メッセージを受信するノード（以下、受信ノードとも表記する）は、あらかじめ決められたメッセージＩＤを含むメッセージのみ受信、つまりバスから信号を読み取る。同一ＩＤのメッセージは、所定の一定の周期で送信される。

【0004】

上述の通り、自動車の中のシステムに多数配置されているＥＣＵは、それぞれがＣＡＮネットワークに接続され、様々なメッセージを互いにやりとりしながら動作している。ここで、ＣＡＮネットワークの外部と通信機能を持つＥＣＵが外部から攻撃される等して乗っ取られ、ＣＡＮネットワークに対して不正なメッセージ（以降、異常メッセージとも表記する）を送信するようになることが起こり得る。このような乗っ取られたＥＣＵ（以下、不正ＥＣＵとも表記する）は、例えば他のＥＣＵになりすまして異常メッセージを送信することで、自動車を不正に制御することが可能となる。このような、いわゆるなりすまし攻撃を検知するための方法として、例えば、特許文献１に記載の方法がある。

【先行技術文献】

【特許文献】

【0005】

【文献】国際公開第２０１４／１１５４５５号

【発明の概要】

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

【0006】

しかしながら、特許文献１に記載の方法では、発生しているなりすまし攻撃を検知できるだけであり、どのメッセージが異常メッセージであるかを判断できないという課題がある。当該課題の解決として、異常メッセージであるか否かを判断するための基準メッセージを決定し、決定された基準メッセージに基づいてメッセージが異常メッセージであるか否かを個別に判断する方法が考えられる。この場合、基準メッセージは適切に設定されることが望まれる。

【0007】

そこで、本開示は、上記課題を解決するもので、ネットワークに送出された個別のメッセージが異常メッセージであるか否かを判定するための基準メッセージを適切に決定する基準メッセージの決定方法等を提供する。

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

【0008】

上記の課題を解決するために、本開示の一態様に係る決定方法は、ネットワーク及び前記ネットワークに接続される１以上の電子制御ユニットを含む車載ネットワークシステムにおける不正通信の検知に用いられる基準メッセージの決定方法であって、前記基準メッセージは、前記ネットワークに送出されるメッセージが異常メッセージであるか否かの判定の基準に用いられるメッセージであり、前記決定方法は、前記基準メッセージの候補である１以上の基準メッセージ候補に関する候補情報を保存する保存ステップと、前記保存ステップで保存された前記候補情報に含まれる前記１以上の基準メッセージ候補から前記基準メッセージを決定するための前記決定方法を、前記１以上の基準メッセージ候補に基づいて決定する第１決定ステップと、前記第１決定ステップで決定された前記決定方法を用いて、前記１以上の基準メッセージ候補から前記基準メッセージを決定する第２決定ステップとを含む。

【0009】

また、本開示の一態様に係る決定システムは、ネットワーク及び前記ネットワークに接続される１以上の電子制御ユニットを含む車載ネットワークシステムにおける不正通信の検知に用いられる基準メッセージの決定システムであって、１以上のプロセッサと、記憶部とを備え、前記基準メッセージは、前記ネットワークに送出されるメッセージが異常メッセージであるか否かの判定の基準に用いられるメッセージであり、前記１以上のプロセッサは、前記記憶部を用いて、前記基準メッセージの候補である１以上の基準メッセージ候補に関する候補情報を保存し、保存された前記候補情報に含まれる前記１以上の基準メッセージ候補から前記基準メッセージを決定するための決定方法を、前記１以上の基準メッセージ候補に基づいて決定し、前記１以上の基準メッセージ候補から、前記決定方法を用いて前記基準メッセージを決定する。

【0010】

また、本開示の一態様に係るプログラムは、上記の決定方法をコンピュータに実行させるためのプログラムである。

【0011】

なお、これらの包括的又は具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム又はコンピュータ読み取り可能なＣＤ－ＲＯＭなどの非一時的な記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。

【発明の効果】

【0012】

本開示の一態様に係る決定方法等によれば、ネットワークに送出された個別のメッセージが異常メッセージであるか否かを判定するための基準メッセージを適切に決定することができる。

【図面の簡単な説明】

【0013】

【図1】図１は、実施の形態１における車載ネットワークシステムの全体構成を示すブロック図である。

【図2】図２は、ＣＡＮプロトコトルのデータフレームフォーマットを示す図である。

【図3】図３は、実施の形態１における車載ネットワークシステムに含まれるゲートウェイの機能構成の一例を示すブロック図である。

【図4】図４は、実施の形態１における受信ＩＤリストのデータ構成の一例を示す図である。

【図5】図５は、実施の形態１におけるゲートウェイで保持される転送ルールのデータ構成の一例を示す図である。

【図6】図６は、実施の形態１における不正検知処理機能群の機能構成の一例を示すブロック図である。

【図7】図７は、実施の形態１における不正検知部の機能構成の一例を示すブロック図である。

【図8】図８は、実施の形態１におけるメッセージの受信パターンを示す図である。

【図9】図９は、実施の形態１における車載ネットワークシステムに含まれるＥＣＵの機能構成の一例を示すブロック図である。

【図10】図１０は、実施の形態１における不正検知処理の一例を示すフロー図である。

【図11】図１１は、実施の形態１における基準メッセージ決定処理の一例を示すフロー図である。

【図12】図１２は、実施の形態２における車載ネットワークシステムの全体構成を示すブロック図である。

【図13】図１３は、実施の形態２における車載ネットワークシステムに含まれるゲートウェイの機能構成の一例を示すブロック図である。

【図14】図１４は、実施の形態２における不正検知処理機能群の機能構成の一例を示すブロック図である。

【図15】図１５は、実施の形態２におけるサーバの機能構成の一例を示すブロック図である。

【図16】図１６は、その他の変形例における不正検知処理機能群の機能構成の第１例を示すブロック図である。

【図17】図１７は、その他の変形例における不正検知処理の一例を示すフロー図である。

【図18】図１８は、その他の変形例における不正検知処理機能群の機能構成の第２例を示すブロック図である。

【図19】図１９は、その他の変形例における不正検知処理機能群の機能構成の第３例を示すブロック図である。

【図20】図２０は、その他の変形例におけるＥＣＵの機能構成の第１例を示すブロック図である。

【図21】図２１は、その他の変形例におけるＥＣＵの機能構成の第２例を示すブロック図である。

【図22】図２２は、その他の変形例におけるＥＣＵの機能構成の第３例を示すブロック図である。

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

【0014】

（本開示の基礎になった知見）
不正ＥＣＵから異常メッセージが送信され始めると、ＣＡＮネットワークでは同じＩＤのメッセージに正常メッセージと異常メッセージとが混在するようになる。このような状況では、正常メッセージの送信のタイミングと異常メッセージの送信のタイミングとがごく近くなる、又は攻撃者によって意図的に近づけられた結果、異常メッセージの送信のタイミングも許容差内（正常メッセージが送信されると予測されるタイミングとの差が許容差内）に収まる場合がある。このような場合には、正常メッセージと異常メッセージとの区別が難しくなり、誤検知の発生の可能性が高まる。同様のことは、メッセージの送信のタイミングのみならず、メッセージが含むデータ値についても起こり得る。このような許容差内の正常メッセージ及び異常メッセージに基づいて異常メッセージであるか否かを判断するための基準メッセージが決定される場合、基準メッセージは適切に設定されることが望まれる。例えば、正常メッセージ及び異常メッセージのうち正常メッセージが基準メッセージに設定されることが望まれる。

【0015】

そこで、本開示の一態様に係る決定方法は、ネットワーク及び前記ネットワークに接続される１以上の電子制御ユニットを含む車載ネットワークシステムにおける不正通信の検知に用いられる基準メッセージの決定方法であって、前記基準メッセージは、前記ネットワークに送出されるメッセージが異常メッセージであるか否かの判定の基準に用いられるメッセージであり、前記決定方法は、前記基準メッセージの候補である１以上の基準メッセージ候補に関する候補情報を保存する保存ステップと、前記保存ステップで保存された前記候補情報に含まれる前記１以上の基準メッセージ候補から前記基準メッセージを決定するための前記決定方法を、前記１以上の基準メッセージ候補に基づいて決定する第１決定ステップと、前記第１決定ステップで決定された前記決定方法を用いて、前記１以上の基準メッセージ候補から前記基準メッセージを決定する第２決定ステップとを含む。

【0016】

これにより、１以上の基準メッセージ候補に応じた決定方法が決定されるので、例えば、１以上の基準メッセージ候補に異常メッセージが含まれる場合、当該異常メッセージが基準メッセージに設定されることを抑制することができる。よって、より適切な基準メッセージを決定することができる。また、例えば、基準メッセージの決定方法が固定されている場合に比べて、より適切な基準メッセージを決定することができる。

【0017】

また、前記第１決定ステップでは、前記基準メッセージを決定するための複数の決定方法のそれぞれにおいて、前記１以上の基準メッセージ候補の中から当該決定方法により前記基準メッセージを決定することの適切度合いを示す適切度を算出し、算出された前記適切度に基づいて前記決定方法を決定してもよい。

【0018】

これにより、適切度に基づいて、基準メッセージを決定するための決定方法を適切に決定することができる。

【0019】

また、前記第１決定ステップでは、前記複数の決定方法の中で、前記適切度が最も高い決定方法を、前記１以上の基準メッセージ候補から前記基準メッセージを決定するための決定方法に決定してもよい。

【0020】

これにより、適切度に基づいて、基準メッセージを決定するための決定方法をさらに適切に決定することができる。

【0021】

また、前記適切度は、前記ネットワークに送出されるメッセージに対する予測値と、前記１以上の基準メッセージ候補が示す値それぞれとの第１の差を算出し、算出された２以上の前記第１の差同士の差である第２の差として算出されてもよい。

【0022】

基準メッセージ候補に正常メッセージ及び異常メッセージが含まれる場合、正常メッセージにおける第１の差と、異常メッセージにおける第１の差とは、離れた値となり得る。つまり、基準メッセージ候補に異常メッセージが含まれると、第２の差が大きくなり得る。

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

ＲＴＲとは、フレームがメッセージ（データフレーム）であることを示す１ｂｉｔのドミナントである。

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

不正検知部３７１は、フレーム処理部３５０から受け取ったメッセージが異常メッセージであるか否かを判定する。

【0081】

不正検知部３７１は、複数種類の判定機能を持つ。各判定機能では、あらかじめ設定されて記憶部に保存（格納）されている、各判定機能で互いに異なるルール（図示なし）を参照し、参照したルールを用いて受信したメッセージのチェック、つまり、各メッセージがこのルールに適合するか否かの判定を行う。そして、不正検知部３７１は、各判定機能の判定結果に基づいて、受信したメッセージが異常メッセージであるか否かを判定する。受信したメッセージが異常メッセージであれば、不正検知部３７１は不正の発生を検知する。

【0082】

図７は、本実施の形態における不正検知部３７１の機能構成の一例を示すブロック図である。この例では、不正検知部３７１は、メッセージの所定のポイントをチェックする６種類の判定機能を持つ。具体的には、６種類の判定機能は、メッセージのＩＤフィールドをチェックする機能（ＩＤ判定機能）と、メッセージのデータ長をチェックする機能（データ長判定機能）と、メッセージが送信される周期（時間間隔）をチェックする機能（送信周期判定機能）と、メッセージが送信される頻度をチェックする機能（送信頻度判定機能）と、メッセージのデータフィールドの値（データ値）をチェックする機能（データ値判定機能）と、これらの判定機能の判定結果、送信周期、頻度、データ値、又はデータ値の変化量などに基づいて車両の状態を認識し、車両状態をチェックする機能（例えば、車両状態判定機能）とを含む。さらに不正検知部３７１は、受信したメッセージが異常メッセージであるか否かを、これらの判定機能による判定結果から総合的に判定する最終結果判定機能を持つ。最終結果判定機能の結果が、不正検知部３７１による不正の検知の結果となる。

【0083】

なお、これらの機能構成要素も、ゲートウェイ３００において記憶部に保持されるプログラムの処理部による読み出し及び実行、記憶部による所定のデータの保持、若しくは入出力部を介してのデータの送受信、又はこれらの組み合わせで実現される。

【0084】

上記の各判定機能においてメッセージの所定のポイントをチェックする際に、過去に受信した同一ＩＤのメッセージの情報、又は関連するメッセージの情報を基準としてチェックする場合がある。各判定機能は、基準メッセージ情報保持部３７２から、基準となるメッセージの情報を取得する。

【0085】

図６の説明に戻って、不正検知部３７１は、受信したメッセージから、基準メッセージの候補となるメッセージに関する情報を、基準メッセージ情報保持部３７２へ通知する。不正検知部３７１は、受信したメッセージのうち、最終結果判定機能が「正常メッセージ」と判定したメッセージを基準メッセージの候補となるメッセージ（基準メッセージ候補）として基準メッセージ情報保持部３７２へ通知する。基準メッセージ候補は、ネットワークに送出されるメッセージが異常メッセージであるか否かの判定の基準に用いる基準メッセージの候補である。

【0086】

不正検知部３７１は、最終結果判定機能が「正常メッセージ」と判定したメッセージをメッセージ保存処理部３７３へも通知する。

【0087】

基準メッセージ情報保持部３７２は、不正検知部３７１が利用する基準メッセージに関する情報と、基準メッセージの候補に関する情報とを保持する。例えば、周期的に送信されるメッセージの場合、１周期分古い同一ＩＤのメッセージが基準メッセージになる。一方で、今の周期に受信したメッセージは、１周期後のメッセージに対して基準メッセージとなる可能性があるメッセージ（基準メッセージ候補）であるため、今の周期では基準メッセージ候補として保持しておく。

【0088】

なお、基準メッセージに関する情報は、例えば、基準メッセージ決定部３７５により決定された基準メッセージを示す情報である。また、基準メッセージの候補に関する情報は、候補情報の一例であり、例えば、１以上の基準メッセージ候補を示す情報である。基準メッセージに関する情報は、例えば、候補情報に含まれる１以上の基準メッセージ候補のうちの１つの基準メッセージ候補を示す情報である。

【0089】

なお、基準メッセージ情報保持部３７２は、さらに、基準メッセージ候補が保存されていない場合に基準メッセージとして用いられ得るメッセージを保持していてもよい。基準メッセージ情報保持部３７２は、予め当該メッセージを保持していてもよい。

【0090】

基準メッセージ情報保持部３７２は、不正検知部３７１から通知された基準メッセージの候補となるメッセージに関する情報を保持する。また、基準メッセージ情報保持部３７２は、基準メッセージ決定部３７５からの要求に応じて、基準メッセージの候補となるメッセージに関する情報を基準メッセージ決定部３７５に通知する。さらに、基準メッセージ情報保持部３７２は、基準メッセージ決定部３７５が決定した基準メッセージに関する情報も保持し、不正検知部３７１からの要求に応じて、不正検知部３７１へ基準メッセージに関する情報を通知する。基準メッセージ情報保持部３７２は、基準メッセージ決定部３７５が、基準メッセージ候補から基準メッセージを決定すると、その際に利用された基準メッセージ候補を削除する。

【0091】

メッセージ保存処理部３７３は、不正検知部３７１から通知されたメッセージに関する情報を、正常メッセージ情報保持部３７４へ保存する処理を行う。また、メッセージ保存処理部３７３は、ある周期に複数の同一ＩＤのメッセージを正常メッセージとして保存したときに、基準メッセージ決定部３７５により、それら複数の同一ＩＤのメッセージから、１つのメッセージが基準として選択されると、その基準メッセージとして選択されたメッセージのみを残し、他のメッセージを削除する、又は、どのメッセージが基準メッセージとして選択されたかを示す情報を一緒に保存する。

【0092】

正常メッセージ情報保持部３７４は、不正検知部３７１が正常メッセージと判定したメッセージに関する情報を保持する。この情報は、周期判定部３７７又はデータ判定部３７８が過去に受信したメッセージから今受信したメッセージの受信時刻又はデータの値の予測値を算出する際に利用する。

【0093】

基準メッセージ決定部３７５は、不正検知部３７１の送信周期判定機能での１周期分古い同一ＩＤのメッセージからの送信時間の差、及びデータ値判定機能での１周期分古い同一ＩＤのメッセージからの変化量の算出に基づいて、基準として用いられる基準メッセージを決定する。

【0094】

例えば、周期的に送信されるメッセージについて、受信予定時刻（例えば、図８に示す受信想定時刻Ｔ１を参照）の前後に時間長α（図８を参照）のマージンが考慮され、データの変化量の前後にデータ値のマージンが考慮されている場合、どちらのマージンからも外れない複数のメッセージが送信される場合がある。このとき、基準メッセージ決定部３７５は、これらの複数のメッセージを基準メッセージ候補として、１周期後の同一ＩＤのメッセージのための基準メッセージとして用いるメッセージを決定する。

【0095】

基準メッセージ決定部３７５は、基準メッセージ情報保持部３７２から基準メッセージの候補となるメッセージ（基準メッセージ候補）に関する情報を取得し、判定種別決定部３７６が決定した決定方法を用いてその候補から基準メッセージとして用いるメッセージを決定する。

【0096】

基準メッセージ決定部３７５は、基準メッセージを決定するときに、判定種別決定部３７６へ基準メッセージの候補を通知し、判定種別決定部３７６が決定した結果に応じた判定種別を用いて、基準メッセージ候補から、基準メッセージを決定する。

【0097】

判定種別決定部３７６は、１以上の基準メッセージ候補から基準メッセージを決定するための決定方法を、１以上の基準メッセージ候補に基づいて決定する。決定方法は、２以上の判定方法を含み、ネットワークに送出されるメッセージが送信される周期に基づいて基準メッセージを決定するための判定を行う周期判定方法、及び、ネットワークに送出されるメッセージに含まれるデータの値に基づいて基準メッセージを決定するための判定を行うデータ判定方法の少なくとも一つを含む。本実施の形態では、決定方法は、周期判定方法及びデータ判定方法を含む。

【0098】

判定種別決定部３７６は、例えば、基準メッセージ決定部３７５から通知された基準メッセージ候補と、不正検知部３７１が保持するルールの値とを取得し、周期判定部３７７とデータ判定部３７８とに判定を依頼する。判定種別決定部３７６は、周期判定部３７７の判定結果として得られる明確度とデータ判定部３７８の判定結果として得られる明確度とから、周期判定とデータ値判定とのどちらの判定種別を使用して１以上の基準メッセージ候補から基準メッセージを決定すれば良いかを決定して基準メッセージ決定部３７５へ通知する。

【0099】

なお、明確度の算出方法は後述するが、明確度は、１以上の基準メッセージ候補の中から基準メッセージを明確に決定できるかどうかの度合いを示す。明確度は、１以上の基準メッセージ候補のうち当該基準メッセージ候補が基準メッセージであることの適切度合いを示すとも言える。また、明確度は、複数の決定方法のそれぞれにおいて、１以上の基準メッセージ候補の中から当該決定方法により基準メッセージを決定することの適切度合いを示すとも言える。明確度は、適切度の一例である。

【0100】

例えば、基準メッセージ候補としてメッセージＭ１（図８を参照）とメッセージＭ２（図８を参照）とがあり、現在の基準メッセージと比較した際に、明確度は、メッセージＭ１もメッセージＭ２も基準メッセージからの差が同じような場合には低く、メッセージＭ１とメッセージＭ２とで基準メッセージからの差が大きく違う場合には高くなる。そして、判定種別決定部３７６は、周期判定とデータ値判定とで明確度の高い判定種別を選択する。例えば、判定種別決定部３７６は、周期判定とデータ値判定とで最も高い（１番高い）明確度の判定種別を選択する。判定種別決定部３７６は、例えば、複数の決定方法のそれぞれにおいて明確度を算出し、複数の決定方法の中で、明確度が最も高い決定方法を、１以上の基準メッセージ候補から基準メッセージを決定するための決定方法に決定するとも言える。

【0101】

これにより、基準メッセージとの差が基準メッセージ候補のメッセージ間で似たような差でありどちらとも判定が難しい判定種別ではなく、基準メッセージとの差が基準メッセージ候補のメッセージ間で大きく異なり明らかに判定可能な判定種別を用いて基準メッセージを選択することができるため、基準メッセージ決定部３７５による基準メッセージの選択がより確実なものとなる。

【0102】

判定種別決定部３７６は、周期判定部３７７から得られた明確度と、データ判定部３７８から得られた明確度とを比較する際に、例えば、それぞれの明確度の大きさをそろえるために、それぞれのルールにおけるマージンで正規化する。例えば、判定種別決定部３７６は、受信時刻に対するマージンが想定値Ｔ１±αの幅（図８を参照）の場合、周期判定部３７７から得られた明確度を２αで割った値を用いて判定種別を決定する。なお、後述する図８では、想定値Ｔ１は時刻の想定値Ｔ１を示しており、受信想定時刻Ｔ１とも記載する。

【0103】

なお、明確度の正規化方法としては、ルールにおけるマージンで正規化したが、これに限定されない。例えば、マージンが想定値Ｔ１±αの幅の場合は、明確度を２αで割るのではなく、αで割ってもよいし、想定値Ｔ１（予測値）で割ることで正規化してもよい。また、あらかじめ、テストデータなどを用いて想定値Ｔ１と実際の受信時刻又はデータ値とのずれ量を計測し、ずれ量の分散値σを算出し、その分散値（σ、２σ、３σなど）で正規化してもよい。これに限らず、異なる単位の値を正規化できる手法であればよい。また、事前に周期判定とデータ判定とで、判定結果の明確さ（明確度）に差があることが分かっていれば、それを加味して正規化してもよい。例えば、周期判定の明確度の方がデータ判定の明確度より高いとすれば、正規化した周期判定の明確度にさらに係数を掛ける、又は、定数を足すなどしてもよい。

【0104】

周期判定部３７７は、現在の基準メッセージの受信時刻と、不正検知部３７１の送信周期判定機能が参照するルールに含まれる周期の情報とから、今の周期における受信想定時刻（Ｔ１）を受信時刻の予測値として算出する。周期判定部３７７は、判定種別決定部３７６から通知された複数の基準メッセージ候補の受信時刻と、予測値である受信想定時刻（Ｔ１）とを比較することで複数の基準メッセージ候補の中から基準メッセージを選択する。

【0105】

図８は、本実施の形態におけるメッセージの受信パターンを示す図である。例えば、図８に示すように、メッセージＭ１の受信時刻がＴ１１で、メッセージＭ２の受信時刻がＴ１２であった場合、Ｔ１１もＴ１２も、ルールのマージンの範囲であるＴ１－αとＴ１＋αとの間にあるため、不正検知部３７１はどちらも正常メッセージであると判定する。しかし、基準メッセージとしてはどちらかを選択する必要がある。そこで、周期判定部３７７は、メッセージＭ１の受信時刻（Ｔ１１）とメッセージＭ２の受信時刻（Ｔ１２）とで、予測値である受信想定時刻（Ｔ１）に近いメッセージを、基準メッセージとして選択する。図８においては、周期判定部３７７は、メッセージＭ１の方がメッセージＭ２よりも受信想定時刻（Ｔ１）に近いため、メッセージＭ１を基準メッセージとして選択する。

【0106】

周期判定部３７７は、複数の基準メッセージ候補の受信時刻と予測値である受信想定時刻との差から、明確度を算出する。例えば、図８においては、メッセージＭ１の受信時刻Ｔ１１と受信想定時刻Ｔ１との差（Ｔ１１－Ｔ１）と、メッセージＭ２の受信時刻Ｔ１２と受信想定時刻Ｔ１との差（Ｔ１－Ｔ１２）の差（｜（Ｔ１１－Ｔ１）－（Ｔ１－Ｔ１２）｜、又は、｜｜Ｔ１１－Ｔ１｜－｜Ｔ１２－Ｔ１｜｜）を明確度と定義する。ここで“｜Ａ｜”はＡの絶対値を示す。例えば、受信想定時刻Ｔ１を中心として、メッセージＭ１とメッセージＭ２とが同程度離れている場合、つまり、｜Ｔ１１－Ｔ１｜と｜Ｔ１２－Ｔ１｜との値が同じような値になる場合、明確度が低くなる。一方、図８のように、メッセージＭ１の受信時刻Ｔ１１がメッセージＭ２の受信時刻Ｔ１２より受信想定時刻Ｔ１に近い場合、つまり｜Ｔ１１－Ｔ１｜の方が｜Ｔ１２－Ｔ１｜よりも十分小さい場合、明確度が高くなる。

【0107】

なお、差（Ｔ１１－Ｔ１）、及び、差（Ｔ１－Ｔ１２）は、第１の差の一例であり、差（｜（Ｔ１１－Ｔ１）－（Ｔ１－Ｔ１２）｜、又は、差（｜Ｔ１１－Ｔ１｜－｜Ｔ１２－Ｔ１｜｜）は第２の差の一例である。明確度は、例えば、正の値（例えば絶対値）である。本実施の形態では、第２の差は、明確度を意味する。また、明確度は、１以上の基準メッセージ候補の中に異常メッセージが含まれている度合いを示すとも言える。

【0108】

なお、周期判定部３７７は、正常メッセージ情報保持部３７４が保持する同一ＩＤの複数のメッセージの受信時刻の情報から、受信するメッセージの受信想定時刻としての予測値を算出してもよいし、受信時刻に相関のある異なるＩＤの１以上のメッセージの受信時刻の情報から、受信するメッセージの受信想定時刻としての予測値を算出してもよい。

【0109】

図６の説明に戻って、データ判定部３７８は、現在の基準メッセージのデータ値と、不正検知部３７１のデータ値判定機能が参照するルールに含まれるデータ値との変化量の情報から、今の周期における想定データ値（Ｄ１）をデータ値の予測値として算出する。データ判定部３７８は、判定種別決定部３７６から通知された複数の基準メッセージ候補のデータ値と、予測値である想定データ値（Ｄ１）とを比較することで複数の基準メッセージ候補の中から基準メッセージを選択する。

【0110】

また、データ判定部３７８は、複数の基準メッセージ候補のデータ値と予測値である想定データ値との差から、明確度を算出する。例えば、周期判定部３７７の場合と同様に、メッセージＭ１のデータ値Ｄ１１と想定データ値Ｄ１との差（Ｄ１１－Ｄ１）と、メッセージＭ２のデータ値Ｄ１２と想定データ値Ｄ１との差（Ｄ１－Ｄ１２）の差（｜（Ｄ１１－Ｄ１）－（Ｄ１－Ｄ１２）｜、又は、｜｜Ｄ１１－Ｄ１｜－｜Ｄ１２－Ｄ１｜｜）を明確度と定義する。なお、差（Ｄ１１－Ｄ１）、及び、差（Ｄ１－Ｄ１２）は、第１の差の一例であり、差（｜（Ｄ１１－Ｄ１）－（Ｄ１－Ｄ１２）｜、又は、｜｜Ｄ１１－Ｄ１｜－｜Ｄ１２－Ｄ１｜｜）は第２の差の一例である。本実施の形態では、第２の差は、明確度を意味する。また、明確度は、１以上の基準メッセージ候補の中に異常メッセージが含まれている度合いを示すとも言える。

【0111】

上記のように、判定方法は、ネットワークに送出されるメッセージに対する予測値と、基準メッセージ候補に関する情報の値それぞれとの差を算出し、それぞれの差（第１の差）の差（第２の差）を明確度とする。これにより、基準メッセージの候補として保存されたメッセージに応じて、明確度を算出することが可能となる。

【0112】

なお、データ判定部３７８は、正常メッセージ情報保持部３７４が保持する同一ＩＤの複数のメッセージのデータ値から、受信するメッセージの想定データ値としての予測値を算出しても良いし、データ値に相関のある異なるＩＤの１以上のメッセージのデータ値の情報から、受信するメッセージの想定データ値としての予測値を算出しても良い。

【0113】

周期判定部３７７、又はデータ判定部３７８は、予め作成され、予測値を算出可能な予測モデルに基づいて予測値を予測してもよい。周期判定部３７７又はデータ判定部３７８は、例えば、同一ＩＤの複数のメッセージのデータ値又は同一ＩＤの複数のメッセージの受信時刻を入力データとして予測モデルに入力して得られる出力データ（データ値又は受信時刻の予測値）を予測値として取得してもよい。例えば、周期判定部３７７、又はデータ判定部３７８は、機械学習、統計的処理、又は確率理論を用いて、正常メッセージに関する情報からＡＲ（ＡｕｔｏＲｅｇｒｅｓｓｉｖｅ）モデル、ＡＲＭＡ（ＡｕｔｏＲｅｇｒｅｓｓｉｖｅ Ｍｏｖｉｎｇ Ａｖｅｒａｇｅ）モデル、ＨＭＭ（Ｈｉｄｄｅｎ Ｍａｒｋｏｖ Ｍｏｄｅｌ）、ベイジアンモデル（Ｂａｙｅｓｉａｎ Ｍｏｄｅｌ）、ＳＶＭ（Ｓｕｐｐｏｒｔ Ｖｅｃｔｏｒ Ｍａｃｈｉｎｅ）、ニューラルネットワーク、又はＤｅｅｐ Ｌｅａｒｎｉｎｇなどのモデルを生成し、そのモデルを用いて、受信するメッセージの受信想定時刻、又は、想定データ値に関する予測値を算出してもよい。

【0114】

また、周期判定部３７７、又はデータ判定部３７８は、現在（現フレーム）又は過去（過去のフレーム）の基準メッセージが示す値を次の受信周期の基準メッセージを決定するための予測値としてもよい。データ判定部３７８は、例えば、現在又は過去の基準メッセージが示す値（データ値）を次の受信周期の基準メッセージを決定するための予測値としもよい。例えば、予測値は、過去の基準メッセージが示す値に基づいて算出されてもよい。例えば、予測値は、過去の基準メッセージが示す値の平均値、中央値、最頻値であってもよいし、直近の基準メッセージが示す値と同じ値であってもよい。なお、本実施の形態では、基準メッセージが示す値は、例えば、受信時刻又はデータ値である。

【0115】

なお、周期判定部３７７、又はデータ判定部３７８は、３つ以上の基準メッセージ候補のメッセージがある場合、全ての基準メッセージ候補のメッセージから１つのメッセージＭ１を基準メッセージと判定した後に、基準メッセージと判定されなかった残りのメッセージから、次に基準メッセージの候補となり得るメッセージＭ２を判定し、最初に基準メッセージと判定されたメッセージＭ１と次に基準メッセージと判定されたメッセージＭ２との２つのメッセージから明確度を算出してもよい。例えば、周期判定部３７７、又はデータ判定部３７８は、３つ以上の基準メッセージ候補がある場合（例えば、１以上の基準メッセージ候補が示す値が３つ以上ある場合）、予測値に近い２つの基準メッセージ候補（例えば、２つの値）を抽出し、抽出した２つの基準メッセージ候補が示す値と予測値とに基づいて明確度を算出してもよい。

【0116】

なお、周期判定部３７７、又はデータ判定部３７８では、予測値との単純な値の差が小さいメッセージを基準メッセージと判定したが、これに限定されない。周期判定部３７７、又はデータ判定部３７８は、複数の基準メッセージ候補から、１つのメッセージを基準メッセージとして判定できる方法であればよく、例えば、実際の正常メッセージの受信時刻やデータ値などを真値としたときに、テストデータなどを用いて、事前に、真値と予測値のずれ量を学習し、そのずれ量の分布を加味して、基準メッセージを判定してもよい。例えば、周期判定部３７７、又はデータ判定部３７８は、実際の受信時刻が予測値から遅れる方向にずれることが少なければ、少しの遅れでも予測値から大きな差になるようにし、予測値より早い場合は、大きな差があっても少しの差になるようにしてもよい。また、周期判定部３７７、又はデータ判定部３７８は、ずれ量以外の指標を用いてもよいし、事前に学習するのではなく、受信したメッセージをリアルタイムに学習してもよい。この時、明確度の算出においても、分布を加味して算出する。

【0117】

なお、周期判定部３７７、又はデータ判定部３７８は、複数の基準メッセージ候補の情報と予測値との差から、明確度を算出するとしたが、これに限定されない。周期判定部３７７、又はデータ判定部３７８は、事前に、判定種別ごとに明確度を算出してもよい。この時、判定種別決定部３７６は、不正検知部３７１が保持している受信したメッセージに関連するルールの中で、一番明確度の高い判定種別を、基準メッセージを決定するために利用する判定種別として決定してもよい。

【0118】

なお、基準メッセージ情報保持部３７２が保持する基準メッセージの候補に関する情報としては、例えば、メッセージＩＤ、ＤＬＣ、データ値、受信時刻などの情報を保持する。また、基準メッセージ情報保持部３７２は、基準メッセージを決定する際に必要となるメッセージＩＤごとのルールの情報を保持してもよい。また、データ値は、受信した全てのデータ値を保持していてもよいし、受信したデータ値のうちの特定の領域のデータ値のみを保存してもよいし、データ値をそのまま保存してもよいし、データ値に対して何らか演算した結果を保存してもよい。

【0119】

なお、不正検知部３７１は、受信したメッセージのうち、最終結果判定機能が「正常メッセージ」と判定したメッセージを基準メッセージの候補となるメッセージとして基準メッセージ情報保持部３７２へ通知するとしたが、これに限定されない。例えば、正常メッセージであるかどうかを判定するルールとは別に、基準メッセージであるかどうかを判定するルールを持ち、そのルールを満たすメッセージを基準メッセージ候補として、基準メッセージ情報保持部３７２へ通知してもよい。これにより、不正検知部３７１は、正常メッセージの中でもより基準メッセージにふさわしいメッセージのみを基準メッセージ候補とすることができる。また、逆に、不正検知部３７１は、正常メッセージから少し外れる異常メッセージを基準メッセージ候補とすることもでき、より広い範囲のメッセージから基準メッセージを決定することが出来る。

【0120】

［１．７ ＥＣＵの構成］
図９は、本実施の形態における車載ネットワークシステム１０に含まれるＥＣＵ１００の機能構成の一例を示すブロック図である。ＥＣＵ１００は、フレーム送受信部１１０と、フレーム解釈部１２０と、受信ＩＤ判断部１３０と、受信ＩＤリスト保持部１４０と、フレーム処理部１５０と、データ取得部１７０と、フレーム生成部１８０とを有する。

【0121】

なお、これらの構成要素は機能構成要素であり、ＥＣＵ１００は、例えばプロセッサで実現される処理部、半導体メモリ等で実現される記憶部、入出力ポートで実現される入出力部等を備える情報処理装置として提供される。上記に挙げた各機能構成要素は、記憶部に保持されるプログラムの処理部による読み出し及び実行、記憶部による所定のデータの保持、若しくは入出力部を介してのデータの送受信、又はこれらの組み合わせで実現される。

【0122】

フレーム送受信部１１０は、バス２００に対して、ＣＡＮのプロトコルに従ったメッセージを送受信する。より具体的には、フレーム送受信部１１０は、バス２００に送出されたメッセージを１ｂｉｔずつ読み出し、読み出したメッセージをフレーム解釈部１２０に転送する。また、フレーム送受信部１１０は、フレーム生成部１８０より通知を受けたメッセージをバス２００に送出する。

【0123】

フレーム解釈部１２０は、フレーム送受信部１１０よりメッセージの値を受け取り、ＣＡＮプロトコルにおける各フィールドにマッピングするようにしてフレーム（メッセージ）の解釈を行う。この解釈においてＩＤフィールドと判断した一連の値を、フレーム解釈部１２０は受信ＩＤ判断部１３０へ転送する。

【0124】

フレーム解釈部１２０はさらに、受信ＩＤ判断部１３０から通知される判定結果に応じて、メッセージのＩＤフィールドの値及びＩＤフィールド以降に現れるデータフィールドをフレーム処理部１５０へ転送するか、メッセージの受信を中止するかを決定する。

【0125】

またフレーム解釈部１２０は、ＣＡＮプロトコルに則っていないメッセージと判断した場合は、エラーフレームを送信するようにフレーム生成部１８０へ要求する。

【0126】

またフレーム解釈部１２０は、他のノードが送信したエラーフレームを受信したと判断した場合、読取中のメッセージを破棄する。

【0127】

受信ＩＤ判断部１３０は、フレーム解釈部１２０からＩＤフィールドの値を受け取り、受信ＩＤリスト保持部１４０が保持しているメッセージＩＤのリストに従い、読み出したメッセージを受信するか否かの判定を行う。受信ＩＤ判断部１３０は、この判定の結果をフレーム解釈部１２０へ通知する。

【0128】

受信ＩＤリスト保持部１４０は、ＥＣＵ１００が受信するメッセージＩＤのリストである受信ＩＤリストを保持する。受信ＩＤリストは、図４と同様であり、ここでは説明を省略する。

【0129】

フレーム処理部１５０は、受信したメッセージのデータに応じた処理を行う。処理の内容は、各ＥＣＵ１００によって異なる。例えば、ＥＣＵ１００ａでは、時速が３０ｋｍを超えているときに、ドアが開いていることを示すメッセージを受信すると、アラーム音を鳴らすための処理を実行する。ＥＣＵ１００ｃは、ブレーキがかかっていないことを示すメッセージを受信しているときにドアが開くと、アラーム音を鳴らすための処理を実行する。これらの処理は説明を目的として挙げる例であり、ＥＣＵ１００は上記以外の処理を実行してもよい。このような処理を実行するために送出するフレームを、フレーム処理部１５０はフレーム生成部１８０に生成させる。

【0130】

データ取得部１７０は、各ＥＣＵ１００に接続されている機器状態又はセンサによる計測値等を示す出力データを取得し、フレーム生成部１８０に転送する。

【0131】

フレーム生成部１８０は、フレーム解釈部１２０から通知されたエラーフレーム送信の要求に従い、エラーフレームを構成してフレーム送受信部１１０へ送る。

【0132】

またフレーム生成部１８０は、データ取得部１７０より受け取ったデータの値に対してあらかじめ定められたメッセージＩＤを付けてメッセージフレームを構成し、フレーム送受信部１１０へ送る。

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

１ 車両
１０、１０ａ 車載ネットワークシステム
１００、１００ａ、１００ｂ、１００ｃ、１００ｄ、１００ｅ、１００ｆ、１００ｇ ＥＣＵ
１０１ エンジン
１０２ ブレーキ
１０３ ドア開閉センサ
１０４ ウィンドウ開閉センサ
１１０、３１０ フレーム送受信部
１２０、３２０ フレーム解釈部
１３０、３３０ 受信ＩＤ判断部
１４０、３４０ 受信ＩＤリスト保持部
１５０、３５０ フレーム処理部
１７０ データ取得部
１７１ 送信データ取得部
１８０、３８０ フレーム生成部
２００、２００ａ、２００ｂ バス
３００、３００ｂ ゲートウェイ
３６０ 転送ルール保持部
３７０、３７０ｂ、３７０ｃ、３７０ｄ、３７０ｅ 不正検知処理機能群
３７１ 不正検知部
３７２ 基準メッセージ情報保持部
３７３、３７３ｂ メッセージ保存処理部
３７４、３７４ｂ 正常メッセージ情報保持部
３７５ 基準メッセージ決定部
３７６ 判定種別決定部
３７７、３７７ｂ 周期判定部
３７８、３７８ｂ データ判定部
３７９ 予測モデル生成部
３９０ 外部通信部
４００ 外部ネットワーク
５００ サーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】