知財求人 - 知財ポータルサイト「IP Force」
▶ パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-05-17
(45)【発行日】2024-05-27
(54)【発明の名称】異常検知装置および異常検知方法
(51)【国際特許分類】
G06F 21/55 20130101AFI20240520BHJP
【ＦＩ】
G06F21/55
【請求項の数】
11
(21)【出願番号】P 2021529982
(86)(22)【出願日】2020-06-24
(86)【国際出願番号】 JP2020024841
(87)【国際公開番号】W WO2021002261
(87)【国際公開日】2021-01-07
【審査請求日】2023-04-04
(31)【優先権主張番号】PCT/JP2019/026722
(32)【優先日】2019-07-04
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】100109210
【弁理士】
【氏名又は名称】新居 広守
(74)【代理人】
【識別番号】100137235
【弁理士】
【氏名又は名称】寺谷 英作
(74)【代理人】
【識別番号】100131417
【弁理士】
【氏名又は名称】道坂 伸一
(72)【発明者】
【氏名】平野 亮
(72)【発明者】
【氏名】岸川 剛
(72)【発明者】
【氏名】氏家 良浩
(72)【発明者】
【氏名】芳賀 智之
【審査官】平井 誠
(56)【参考文献】
【文献】国際公開第２０１９／０２１４０２（ＷＯ，Ａ１）
【文献】特開２０１８－１９０４６５（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１６／０１４２３０３（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１８／０２６２４６６（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ２１／５５
(57)【特許請求の範囲】
【請求項1】
イーサネット（登録商標）で構成され、サービス指向型通信が行われる車載ネットワークシステムにおける異常検知装置であって、前記異常検知装置は、サービス指向型通信の通信確立フェーズにおいて前記イーサネットを流れる通信確立フレームを監視し、前記通信確立フレームに記載される通信ＩＤおよびサーバーアドレスまたはクライアントアドレスを含む検知ルールを通信ＩＤごとに生成する検知ルール生成部と、
サービス指向型通信の通信フェーズにおいて前記イーサネットを流れる通信フレームを監視し、前記通信フレームに記載された通信ＩＤを含む検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと異なる場合に、当該通信フレームを異常フレームとして検知する異常検知部と、
前記異常フレームが検知された場合に、異常を通知する異常通知部と、を備える、
異常検知装置。
【請求項2】
前記検知ルール生成部は、それぞれ同一の通信ＩＤおよびそれぞれ異なるサーバーアドレスまたはそれぞれ異なるクライアントアドレスを含む複数の検知ルールを１以上の通信ＩＤについて生成し、前記異常検知部は、前記通信フレームに記載された通信ＩＤを含む複数の検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該複数の検知ルールのそれぞれに含まれるサーバーアドレスまたはクライアントアドレスとすべて異なる場合に、当該通信フレームを異常フレームとして検知する、
請求項１に記載の異常検知装置。
【請求項3】
検知ルールは、検知ルールに含まれるサーバーアドレスに対応するサーバーまたはクライアントアドレスに対応するクライアントが、検知ルールに含まれる通信ＩＤに対応するサービスについての通信を行う状態である場合にはＯＮを示し、行わない状態にある場合にはＯＦＦを示す通信確立状態を含み、前記検知ルール生成部は、
前記通信確立フレームに記載された通信種別を確認し、前記通信種別がサービス提供、サービス購読応答、サービス探索またはサービス購読であれば、当該通信確立フレームに記載された通信ＩＤとサーバーアドレスとの組または、通信ＩＤとクライアントアドレスとの組を含む検知ルールに含まれる通信確立状態をＯＮに変更し、
前記通信種別がサービス提供停止またはサービス購読停止であれば、当該通信確立フレームに記載された通信ＩＤとサーバーアドレスとの組または、通信ＩＤとクライアントアドレスとの組を含む検知ルールに含まれる通信確立状態をＯＦＦに変更し、
前記異常検知部は、前記通信フレームに記載された通信ＩＤを含む検知ルールを参照し、前記通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと一致する場合に、当該検知ルールに含まれる通信確立状態がＯＦＦであれば、当該通信フレームを異常フレームとして検知する、
請求項１または２に記載の異常検知装置。
【請求項4】
前記検知ルール生成部は、前記通信種別がサービス提供停止またはサービス購読停止であれば、所定時間待機した後、前記通信確立フレームに記載された通信ＩＤとサーバーアドレスとの組または、通信ＩＤとクライアントアドレスとの組を含む検知ルールに含まれる通信確立状態をＯＦＦに変更する、請求項３に記載の異常検知装置。
【請求項5】
前記検知ルール生成部は、前記通信確立フレームに記載された通信種別を確認し、前記通信種別がサービス提供停止であれば、前記通信確立フレームに記載された通信ＩＤとサーバーアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に異常と判定し、前記通信種別がサービス購読停止であれば、前記通信確立フレームに記載された通信ＩＤとクライアントアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に異常と判定する、
請求項３または４に記載の異常検知装置。
【請求項6】
前記異常検知装置には、前記車載ネットワークシステムにおいて、通信ＩＤごとに利用されるサーバーの最大数を表す通信ＩＤ別サーバー数と通信ＩＤごとに利用されるクライアントの最大数を表す通信ＩＤ別クライアント数とのうち少なくとも１つが事前に記憶され、前記検知ルール生成部は、
前記通信確立フレームに記載された通信ＩＤとサーバーアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に、当該通信ＩＤを含む検知ルールにおける当該サーバーアドレスの種類数が前記通信ＩＤ別サーバー数よりも大きければ、異常と判定し、同じか小さければ、当該通信確立フレームに記載された通信ＩＤとサーバーアドレスの組を含む検知ルールを追加し、または、
前記通信確立フレームに記載された通信ＩＤとクライアントアドレスの組を含む検知ルールが存在するか否かを確認し、当該検知ルールが存在しない場合に、当該通信ＩＤを含む検知ルールにおける当該クライアントアドレスの種類数が前記通信ＩＤ別クライアント数よりも大きければ、異常と判定し、同じか小さければ、当該通信確立フレームに記載された通信ＩＤとクライアントアドレスの組を含む検知ルールを追加する、
請求項１から５のいずれか１項に記載の異常検知装置。
【請求項7】
前記異常検知装置には、前回起動時に生成した前回検知ルールが記憶され、前記検知ルール生成部は、前記通信確立フレームを監視して検知ルールを生成するときに、異常と判定した場合、当該通信確立フレームに記載された通信ＩＤを含む前回検知ルールを参照し、当該通信ＩＤを含む検知ルールに記載の内容を当該前回検知ルールに記載の内容に書き換える、
請求項６に記載の異常検知装置。
【請求項8】
前記異常検知装置には、通信ＩＤごとに通信許可される車両状態が事前に記憶され、前記検知ルール生成部は、前記通信確立フレームを受信した場合に、現在の車両状態を取得し、当該通信確立フレームに記載された通信ＩＤについて、事前に記憶された通信許可される車両状態と、現在の車両状態とが異なる場合に、異常と判定し、
前記異常検知部は、前記通信フレームを受信した場合に、現在の車両状態を取得し、事前に記憶された、当該通信フレームに記載された通信ＩＤについて通信許可される車両状態と、現在の車両状態とが異なる場合に、当該通信フレームを異常フレームとして検知する、
請求項１から７のいずれか１項に記載の異常検知装置。
【請求項9】
前記車両状態は、イグニションの状態、ネットワーク接続状態、シフト状態、運転支援モードの状態、自動運転の状態、および、人物または物体検知の状態のうち少なくとも１つを含む、請求項８に記載の異常検知装置。
【請求項10】
前記サービス指向型通信における通信フェーズではＳＯＭＥ／ＩＰが用いられ、通信確立フェーズではＳＯＭＥ／ＩＰ―ＳＤが用いられ、通信ＩＤは、Ｓｅｒｖｉｃｅ ＩＤおよびＭｅｔｈｏｄ ＩＤであり、
通信種別におけるサービス提供、サービス購読、サービス探索、サービス購読応答、サービス提供停止およびサービス購読停止は、それぞれＳｅｒｖｉｃｅ Ｏｆｆｅｒ、Ｓｅｒｖｉｃｅ Ｓｕｂｓｃｒｉｂｅ、Ｓｅｒｖｉｃｅ Ｆｉｎｄ、Ｓｅｒｖｉｃｅ ＳｕｂｓｃｒｉｂｅＡｃｋ、Ｓｔｏｐ ＯｆｆｅｒおよびＳｔｏｐ Ｓｕｂｓｃｒｉｂｅである、
請求項１から９のいずれか１項に記載の異常検知装置。
【請求項11】
イーサネットで構成され、サービス指向型通信が行われる車載ネットワークシステムにおける異常検知方法であって、前記異常検知方法は、サービス指向型通信の通信確立フェーズにおいて前記イーサネットを流れる通信確立フレームを監視し、前記通信確立フレームに記載される通信ＩＤおよびサーバーアドレスまたはクライアントアドレスを含む検知ルールを通信ＩＤごとに生成する検知ルール生成ステップと、
サービス指向型通信の通信フェーズにおいて前記イーサネットを流れる通信フレームを監視し、前記通信フレームに記載された通信ＩＤを含む検知ルールを参照し、当該通信フレームに記載されたサーバーアドレスまたはクライアントアドレスが、当該検知ルールに含まれるサーバーアドレスまたはクライアントアドレスと異なる場合に、当該通信フレームを異常フレームとして検知する異常検知ステップと、
前記異常フレームが検知された場合に、異常を通知する異常通知ステップと、を含む、
異常検知方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、車載ネットワークシステムにおいて、異常な通信を検知する異常検知装置および異常検知方法に関する。
【背景技術】
【0002】
近年、自動車の中のシステムには、電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。車載ネットワークの１つに、ＩＥＥＥ ８０２．３で規定されているＥｔｈｅｒｎｅｔ（登録商標）という規格が存在する。先進運転支援システムまたは自動運転においては、カメラもしくはＬＩＤＡＲ（Ｌｉｇｈｔ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｒａｎｇｉｎｇ）などのセンサーにより取得されるセンサー情報またはダイナミックマップなどの膨大な情報を処理する必要があるため、データ伝送速度が高いＥｔｈｅｒｎｅｔの導入が進んでいる。そして、Ｅｔｈｅｒｎｅｔ上の通信プロトコルとして、ＳＯＭＥ／ＩＰ（Ｓｃａｌａｂｌｅ Ｓｅｒｖｉｃｅ－Ｏｒｉｅｎｔｅｄ ＭｉｄｄｌｅｗａｒＥ ｏｖｅｒ ＩＰ）という規格が存在する。ＳＯＭＥ／ＩＰでは、Ｅｔｈｅｒｎｅｔに接続される各ノードが、ヘッダに記載されるサービスＩＤによって通信内容を決定するため、ＳＯＭＥ／ＩＰはサービス指向型通信と呼ばれる。さらに、ＳＯＭＥ／ＩＰでは、ＳＯＭＥ／ＩＰ―ＳＤ（Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ）と呼ばれるＳＯＭＥ／ＩＰ通信を開始する前に行われるノード間の通信確立フェーズが存在し、事前に利用したいサービスのサービスＩＤまたは提供可能なサービスのサービスＩＤを通信確立フェーズにおいて記憶していれば、通信先ノードのＩＰアドレスおよびＭＡＣアドレスを動的に取得できる。そのため、システム環境に依存するＩＰアドレスおよびＭＡＣアドレスなどの情報を事前に設定する必要はなく、可搬性に優れたソフトウェアを容易に設計することが可能であることから次世代の通信方式として利用の拡大が期待されている。
【先行技術文献】
【非特許文献】
【0003】
【文献】“ＳＯＭＥ／ＩＰ，Ｐｕｂｌｉｃａｔｉｏｎｓ，Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ／Ｓｔａｎｄａｒｄｓ”、［ｏｎｌｉｎｅ］、［令和１年０６月１８日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｓｏｍｅ－ｉｐ．ｃｏｍ／ｐａｐｅｒｓ．ｓｈｔｍｌ／＞
【文献】Ｎ．Ｈｅｒｏｌｄ，ｅｔ ａｌ、“Ａｎｏｍａｌｙ Ｄｅｔｅｃｔｉｏｎ ｆｏｒ ＳＯＭＥ／ＩＰｕｓｉｎｇ Ｃｏｍｐｌｅｘ Ｅｖｅｎｔ Ｐｒｏｃｅｓｓｉｎｇ”、ＮＯＭＳ ２０１６，ＩＥＥＥ／ＩＦＩＰ Ｎｅｔｗｏｒｋ Ｏｐｅｒａｔｉｏｎｓ ａｎｄ Ｍａｎａｇｅｍｅｎｔ Ｓｙｍｐｏｓｉｕｍ、２０１６
【発明の概要】
【発明が解決しようとする課題】
【0004】
ＳＯＭＥ／ＩＰ等のサービス指向型通信において、セキュリティ対策が何も施されていない場合、一つのノードが不正に乗っ取られると、乗っ取られたノードが送信するサービスＩＤを含むフレームを不正に送受信できるだけでなく、乗っ取られたノード以外の他のノードが送信するはずのサービスＩＤを含むフレームを送信することで、他のノードになりすまして、不正な通信を成立させることや、通信を停止させることができる脅威がある。
【0005】
特に、車載ネットワークにおいては、車両の「走る、曲がる、止まる」に関わる特に重要なサービスが存在するため、これらのサービスを不正に制御することや、不正に停止することが可能であることは大きな脅威となる。
【0006】
これらの脅威に対して、ＩＰＳｅｃ（Ｓｅｃｕｒｉｔｙ Ａｒｃｈｔｅｃｔｕｒｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）等を用いてＳＯＭＥ／ＩＰ通信を暗号化する対策や、非特許文献２に開示されている対策がある。
【0007】
ＩＰＳｅｃを用いる場合、ノード間で共有された鍵を用いて通信を暗号化することで、通信内容の盗聴を防ぐことができる。
【0008】
しかし、鍵が車両内の各々のＥＣＵで共通であった場合、特定のＥＣＵが不正に乗っ取られると鍵も漏洩し、不正な通信が成立させることができる課題がある。
【0009】
また、ＥＣＵごとに異なる鍵または公開鍵を用いる場合、鍵の管理が煩雑になることに加えて、通信の暗号化処理と復号処理が必要となりオーバヘッドが増加する課題がある。
【0010】
また、セキュリティ対策のために、ＩＰＳｅｃを用いると、ＳＯＭＥ／ＩＰを利用する利点である可搬性が失われる。
【0011】
非特許文献２に開示されている対策では、ＳＯＭＥ／ＩＰの通信フレームに対して、事前にサービスＩＤと対応する送信先ＩＰアドレスおよび送信元ＩＰアドレスを正常ルールとして事前に設定し、通信フレームを監視し、正常ルールに従わない通信フレームを異常なフレームとして検知する。
【0012】
しかしながら、ＩＰアドレス等の情報は車種や車両ごとに異なるため、システム環境に依存する情報を事前に設定することは、ＳＯＭＥ／ＩＰを利用する利点である可搬性を低下させる課題がある。
【0013】
本開示は、従来の課題を解決するもので、サービス指向型通信の可搬性を失わずに、自動車の安全性を向上できる異常検知装置等を提供することを目的とする。
【課題を解決するための手段】
【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】
１０ 車載ネットワークシステム
１１、１２、１３ イーサネット
１４ ＣＡＮ
１５ ＣＡＮ－ＦＤ
１００ ＩＤＳＥＣＵ
１１０ 通信部
１２０ 転送部
１３０ 検知ルール記憶部
１４０ 検知ルール生成部
１５０ 異常検知部
１６０ 異常通知部
１７０ 車両状態抽出部
２００ ＣｅｎｔｒａｌＥＣＵ
３００ａ、３００ｂ、３００ｃ、３００ｄ ＺｏｎｅＥＣＵ
４００ａ カメラＥＣＵ
４００ｂ カーナビＥＣＵ
４００ｃ ステアリングＥＣＵ
４００ｄ ブレ－キＥＣＵ
１１、１２、１３ イーサネット
１４ ＣＡＮ
１５ ＣＡＮ－ＦＤ
１００ ＩＤＳＥＣＵ
１１０ 通信部
１２０ 転送部
１３０ 検知ルール記憶部
１４０ 検知ルール生成部
１５０ 異常検知部
１６０ 異常通知部
１７０ 車両状態抽出部
２００ ＣｅｎｔｒａｌＥＣＵ
３００ａ、３００ｂ、３００ｃ、３００ｄ ＺｏｎｅＥＣＵ
４００ａ カメラＥＣＵ
４００ｂ カーナビＥＣＵ
４００ｃ ステアリングＥＣＵ
４００ｄ ブレ－キＥＣＵ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】