JP2019129527A - データ解析装置及びプログラム - Google Patents

Abstract

【課題】高度化した攻撃であってもより高い精度で検知することができるデータ解析装置を提供する。【解決手段】データ解析装置の機能を提供するデータ解析サーバ２００は、１本以上のバスを含む車載ネットワークを搭載する第一車両及び第二車両の異常データを特定する情報をそれぞれ含む複数の異常解析結果を取得するデータ取得部２１０と、第一車両及び第二車両のそれぞれについて、車載ネットワークに接続されるＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）のうち、異常データと関連度の高い一次ＥＣＵを特定し、１本以上のバスのうち、一次ＥＣＵが接続されているバスに接続されているＥＣＵを二次ＥＣＵ群として特定し、第一車両について特定された二次ＥＣＵ群及び第二車両について特定された二次ＥＣＵ群のいずれにも含まれる、所定の条件を満たすＥＣＵを異常関連ＥＣＵとして特定する関連ＥＣＵ特定部２５０とを備える。【選択図】図４

Description

本発明は、車載ネットワークを備える車両へのサイバー攻撃に対するセキュリティ技術に関する。

車載ネットワークを備える車両へのサイバー攻撃に対するセキュリティ技術が提案されている。例えば、通信規格であるＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）に準拠する車載ネットワークを流れるＣＡＮデータを解析することで、ＣＡＮデータに潜む攻撃の不正データを検知する技術が提案されている（特許文献１及び特許文献２参照）。

特開２０１４−１４６８６８号公報 特開２００８−１１４８０６号公報

しかしながら、なりすましの手法等によって高度化した攻撃を検知できない可能性がある。

そこで本発明は、高度化した攻撃であってもより高い精度で検知することができるデータ解析装置を提供する。

本発明の一態様に係るデータ解析装置は、１本以上のバスを含む車載ネットワークを搭載する第一車両及び第二車両のそれぞれの前記車載ネットワークの異常を解析した結果であり、少なくとも異常データを特定する情報をそれぞれ含む複数の異常解析結果を取得するデータ取得部と、前記第一車両及び前記第二車両のそれぞれについて、前記車載ネットワークに接続されるＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）のうち、前記複数の異常解析結果が示す異常データと関連度の高い一次ＥＣＵを特定し、前記１本以上のバスのうち、前記一次ＥＣＵが接続されているバスに接続されている複数のＥＣＵを二次ＥＣＵ群として特定し、前記第一車両について特定された前記二次ＥＣＵ群及び前記第二車両について特定された前記二次ＥＣＵ群のいずれにも含まれる、所定の条件を満たすＥＣＵを異常関連ＥＣＵとして特定し、少なくとも前記異常関連ＥＣＵを示す情報を出力する関連ＥＣＵ特定部とを備える。

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

本発明の一態様に係るデータ解析装置は、高度化した攻撃であってもより高い精度で検知することができる。

図１は、実施の形態１におけるデータ解析装置を含むネットワークセキュリティシステムの概要を説明するための図である。 図２は、図１に記載のネットワークセキュリティシステムにおける、車載ネットワークの構成例を示す図である。 図３は、上記の車載ネットワークの機能構成例を示すブロック図である。 図４は、図１に記載のデータ解析サーバの機能構成例を示すブロック図である。 図５は、図１に記載の車両からデータ解析サーバに提供される車両データのデータ構造の一例を示す図である。 図６は、上記の車両の走行状態を示す車両データのデータ構造の他の例を示す図である。 図７は、図１に記載の交通基盤システムからデータ解析サーバに提供される車外データのデータ構造の一例を示す図である。 図８は、実施の形態１におけるデータ解析サーバによる処理の手順の一例を示すフロー図である。 図９は、実施の形態１において、車両で異常が発生したと判断される場合のシーケンス図である。 図１０は、実施の形態１において、交通基盤システムで異常が発生したと判断される場合のシーケンス図である。 図１１は、実施の形態１における車両データ解析装置による処理の手順の一例を示すフロー図である。 図１２は、実施の形態１における交通基盤システムによる処理の手順の一例を示すフロー図である。 図１３Ａは、実施の形態１におけるデータ解析サーバによる処理の手順の一具体例を示すフロー図である。 図１３Ｂは、実施の形態１におけるデータ解析サーバによる処理の手順の一具体例を示すフロー図である。 図１３Ｃは、実施の形態１におけるデータ解析サーバによる処理の手順の一具体例を示すフロー図である。 図１３Ｄは、実施の形態１におけるデータ解析サーバによる処理の手順の一具体例を示すフロー図である。 図１３Ｅは、実施の形態１におけるデータ解析サーバによる処理の手順の一具体例を示すフロー図である。 図１３Ｆは、実施の形態１におけるデータ解析サーバによる処理の手順の一具体例を示すフロー図である。 図１４は、実施の形態２において各車両が備える車両データ解析装置による処理の手順の一例を示すフロー図である。 図１５は、実施の形態２において異常レベルの判定のために実行される車両データの解析の結果のデータ構造の一例を示す図である。 図１６Ａは、実施の形態２におけるデータ解析サーバによる処理の手順の一例を示すフロー図である。 図１６Ｂは、実施の形態２におけるデータ解析サーバによる処理の手順の他の例を示すフロー図である。 図１７は、実施の形態２におけるネットワークセキュリティシステムのシーケンス図である。 図１８は、実施の形態３において各車両が備える車両データ解析装置による処理の手順の一例を示すフロー図である。 図１９は、実施の形態３におけるデータ解析サーバによる処理の手順の一例を示すフロー図である。 図２０は、実施の形態３において用いられる、車載の情報処理装置（ＥＣＵ）と送信ＣＡＮメッセージとの関連付けを示すデータの例を示す図である。 図２１は、実施の形態３において用いられる、車載ネットワークを構成するバスと各バスに接続されているＥＣＵとの関連付けを示すデータの例を示す図である。 図２２は、実施の形態３におけるネットワークセキュリティシステムのシーケンス図である。 図２３は、実施の形態３におけるネットワークセキュリティシステムのユーザへの情報提示の手順の一例を示すフロー図である。

（本発明の基礎となった知見）
本発明者は、「背景技術」の欄において記載したセキュリティ技術に関し、以下の問題が生じることを見出した。

今日の自動車は、ＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）と呼ばれる情報処理装置を複数備える。これらのＥＣＵは安全性、利便性又は快適性の向上のための様々な機能を発揮し、また、ＣＡＮネットワーク等の車載ネットワークを介してデータをやり取りして連携し、自動運転を含むより高度な機能の実現も可能である。なお、本開示でのＥＣＵの語は、各々の用途に応じてＩＶＩ（Ｉｎ−Ｖｅｈｉｃｌｅ Ｉｎｆｏｔａｉｎｍｅｎｔ）、ＴＣＵ（Ｔｅｌｅｍａｔｉｃｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｔ）、ゲートウェイ等の他の名称で呼ばれる、車載ネットワークに接続されてデータを送信又は受信する各種の機器も含めて指して用いられる。

車両へのサイバー攻撃には、例えば車載ネットワークに接続された不正な機器、又はプログラムが不正に書き換えられたＥＣＵから攻撃データを流すことでその車両の機能を混乱させる手法が従来ある。特許文献１又は２に記載の技術は、そのような攻撃手法への対抗手段として提案されるものである。

しかしながら、従来技術は対象車両の正常データと攻撃データを比べることで攻撃データを検知する技術であり、正常データを高度に模した攻撃データに対しては、検知が困難であるという課題がある。

また従来技術は、送信された不正データを検知して攻撃による悪影響を防ぐことはできても、不正データを送信している機器の特定は対象としておらず、不正データを送信する機器の停止などのより根本的な解決が困難な場合もある。

また、さらに高度な機能を実現するために、他の車両又は交通基盤システム等の外部と、直接、又はインターネット等の通信ネットワークを介してデータを送受信する車載ネットワークを搭載する車両も登場している。このように拡大したデータの流通経路は、不正なデータの伝播経路にもなり得、被害を拡大させかねない。しかしながら従来技術は、被害拡大に繋がる不正データの伝搬を防止することができない。

このような問題を解決するために、本発明の一態様に係るデータ解析装置は、１本以上のバスを含む車載ネットワークを搭載する第一車両及び第二車両のそれぞれの前記車載ネットワークの異常を解析した結果であり、少なくとも異常データを特定する情報をそれぞれ含む複数の異常解析結果を取得するデータ取得部と、前記第一車両及び前記第二車両のそれぞれについて、前記車載ネットワークに接続されるＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）のうち、前記複数の異常解析結果が示す異常データと関連度の高い一次ＥＣＵを特定し、前記１本以上のバスのうち、前記一次ＥＣＵが接続されているバスに接続されている複数のＥＣＵを二次ＥＣＵ群として特定し、前記第一車両について特定された前記二次ＥＣＵ群及び前記第二車両について特定された前記二次ＥＣＵ群のいずれにも含まれる、所定の条件を満たすＥＣＵを異常関連ＥＣＵとして特定し、少なくとも前記異常関連ＥＣＵを示す情報を出力する関連ＥＣＵ特定部とを備える。

例えば、前記第一車両及び前記第二車両は、（１）所定期間内の走行地域が異なること、（２）車種が異なること、（３）メーカーが異なること、（４）前記車載ネットワークの構成が異なること、及び（５）前記データが生成された時間帯が異なることのいずれか一つ又は複数の組み合わせからなる条件を満たしてもよい。

これにより、異常に対して条件の異なる車両同士で比較をすることで、攻撃に関連するＥＣＵの特定がより効率的に行え、早急な対策が可能になる。

例えば、前記関連ＥＣＵ特定部はさらに、前記データ解析装置のユーザに、当該ユーザが持つアクセス権限に応じて、前記一次ＥＣＵ、前記二次ＥＣＵ群及び前記データの少なくとも一部を出力してもよい。

これにより、例えばサイバー攻撃に対する脆弱性等の異常を有するＥＣＵの絞り込みに利用された情報であって、異常の解消などの問題解決に利用されるもののうち、ユーザ間で秘匿されるべき情報の秘匿性を保つことができる。

例えば、前記所定の条件は、（１）機種が同一であること、（２）メーカーが同一であること、（３）搭載するプロセッサの機種が同一であること、（４）前記プロセッサのファームウェアが同一であること、及び（５）前記プロセッサの製造メーカーが同一であることのいずれか一つ又は複数の組み合わせであってもよい。

これにより、サイバー攻撃に対する脆弱性等の問題を共通に抱える可能性の高いＥＣＵが絞り込まれ、早急な対策が可能になる。

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

以下、実施の形態に係るデータ解析装置について、図面を参照しながら説明する。

なお、以下の各実施の形態は、いずれも本発明の包括的又は具体的な例を示すものである。したがって、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ（工程）及びステップの順序等は、一例であって本発明を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。

（実施の形態１）
［１．概要］
図１は、実施の形態１におけるデータ解析装置を含むネットワークセキュリティシステムの概要を説明するための図である。ネットワークセキュリティシステム１は、Ｖ２Ｘ通信をする車両及びその通信相手を攻撃対象とするサイバー攻撃への対策のためのセキュリティシステムである。図１に示されるように、ネットワークセキュリティシステム１では、車両１０Ａ及び車両１０Ｂ（以下、これらをまとめて、又は区別せずに一方を指して車両１０ともいう）、データ解析サーバ２００及び交通基盤システム３００は、インターネットなどの通信回線を用いて構築される通信ネットワーク９００を介してデータをやり取りする。また、車両１０Ａ及び車両１０Ｂは相互に、また交通基盤システム３００と直接データをやり取りする。なお、交通基盤システム３００とは、信号機、ＥＴＣ（Ｅｌｅｃｔｒｏｎｉｃ Ｔｏｌｌ Ｃｏｌｌｅｃｔｉｏｎ）ゲート、交通量計測装置等の、車両１０が走行する道路沿いに設置される各種の交通基盤関連機器（本開示ではこれらの機器を路側機ともいう、図示なし）、及びこれらの路側機と通信し、制御及び管理するためのシステムを指す。

ネットワークセキュリティシステム１では、車両１０又は交通基盤システム３００を対象とするサイバー攻撃が精度よく検知され、被害の拡大を抑えるための措置が図られる。以下、このようなサイバー攻撃の検知を担うデータ解析装置の機能がデータ解析サーバ２００によって提供される場合を例に本実施の形態を説明する。

［２．構成］
［２−１．車両の情報システム構成］
車両１０の情報システム構成について、車両１０Ａを例に説明する。図２は、車両１０Ａが備える車載ネットワーク１００の構成例を示す図である。

車両１０Ａは車載ネットワーク１００を備える。車両１０ＡからＶ２Ｘ通信で車両１０Ｂ、データ解析サーバ２００及び交通基盤システム３００に送信されるデータは、車載ネットワーク１００を流れるデータである。

車載ネットワーク１００は、外部通信装置１１０、ゲートウェイ１２０、車両データ解析装置１３０及び複数のＥＣＵ１５０を含む。この例におけるＥＣＵ１５０は、情報系、制御系等の機能系統ごとに共通のバスに接続されてひとつの機能系統ネットワークを構成している。これらの機能系統は例であり、車載ネットワーク１００には、例えばボディ系統等のさらに別の機能系統が含まれ得る。各ＥＣＵ１５０には、図示しない車載のセンサ、スイッチ又はアクチュエータ等の機器が接続され、ＥＣＵ１５０は、このセンサが計測した結果を示すセンシングデータをバスに送出したり、センサの計測結果を入力として処理したプログラムが出力する制御信号をスイッチ又はアクチュエータに送出したりする。なお、以下の説明では、車載ネットワーク１００がＣＡＮネットワークである例を用いることがあるが、本実施の形態及び後述のその変形例は、ＣＡＮ以外の通信プロトコルに準拠する車載ネットワークにも適用可能である。また、車載ネットワーク１００には、異なるプロトコルに準拠するネットワークが混在してもよい。

外部通信装置１１０及びゲートウェイ１２０もそれぞれＥＣＵを用いて実現され、上記のように用途に応じた呼称を用いて示すものである。外部通信装置１１０は、外部の通信ネットワーク９００又は他の車両１０Ｂと通信するための通信モジュールを備える情報処理装置であり、例えばＴＣＵと呼ばれる。ゲートウェイ１２０は、上記の各機能系統間、及び各機能系統と外部通信装置１１０との間のデータの転送機能を備え、この転送の際に、必要に応じて通信プロトコルの違いに応じたデータの変換を行う情報処理装置である。

車両データ解析装置１３０は、車載ネットワーク１００を流れる車両データを解析し、解析結果をデータ解析サーバ２００に提供する。本実施の形態の説明に用いる構成例では、車載ネットワーク１００は、ゲートウェイ１２０が備えるプロセッサがプログラムを実行することで実現される機能的な構成要素である。図３は、車両データ解析装置１３０の機能構成をさらに詳細に説明するためのブロック図である。

車両データ解析装置１３０は、車両データ取得部１３１、車外データ取得部１３２、走行状態解析部１３３、蓄積部１３５、解析結果送信部１３６及び車両制御データ送信部１３７を備える。

車両データ取得部１３１は、車載ネットワーク１００を流れる、車両１０Ａの走行状態を示す車両データを取得する。この走行状態を示す車両データの例には、上記のＥＣＵ１５０から送出されるセンシングデータが含まれる。

車外データ取得部１３２は、外部通信装置１１０がＶ２Ｘ通信で受信したデータを取得する。このデータには、周辺の車両、この例では車両１０Ｂ、若しくは交通基盤システム３００で取得されたデータが含まれる。より具体的には、車両１０Ａは、車両１０Ｂからは、車両１０Ｂの車載ネットワークを流れる車両データを、交通基盤システム３００からは、路側機が有する測定機能又は通信機能によって得られたデータを車外データとして取得する。

走行状態解析部１３３は、車両データ取得部１３１が取得した車両データを解析し、その結果として車両１０Ａの走行状態の情報を得る。この情報には、例えば、車速、旋回曲率、加速度、ヨーレート、アクセル開度、操舵量、シフトポジション、車両の位置情報等が含まれ得る。

蓄積部１３５は、車両データ取得部１３１が取得した車内データ、車外データ取得部１３２が取得した車外データ、又は走行状態解析部１３３による解析結果のデータを必要に応じて保持する。この例では、蓄積部１３５はゲートウェイ１２０が備える記憶装置を用いて実現される。

解析結果送信部１３６は、走行状態解析部１３３による解析結果のデータを、外部通信装置１１０を介してデータ解析サーバ２００へ送信する。

車両制御データ送信部１３７は、走行状態解析部１３３による解析結果又は車外データ取得部１３２に基づいて、異常の有無又はレベルに応じて実行すべき所定の動作のための指示発する。この指示は、ゲートウェイ１２０に接続されるバスに送出されて関連するＥＣＵ１５０によって受信される。

なお、上記のようにゲートウェイ１２０上にある車両データ解析装置１３０は、車載ネットワーク１００上における車両データ解析装置１３０の実装形態の一例であり、他の形態で実装されてもよい。例えば車載ネットワーク１００に接続される、ゲートウェイ１２０とは別個の一台以上の情報処理装置を用いて実現されてもよい。

また、ネットワークセキュリティシステム１に接続する車両１０にとって上記の構成の情報システムが必須というわけではない。例えば、車両１０Ｂが備える車載ネットワーク１００上の情報システムは、走行状態解析部１３３を備えず、解析結果送信部１３６に代えて、センシングデータ等の未解析の車両データを外部に送信する送信部を備える構成であってもよい。この場合、車両１０Ｂの車両データに基づく走行状態の解析は、車両１０Ｂの外部、例えば車両１０Ｂの車両データを受信するデータ解析サーバ２００で実行されてもよい。あるいは、車両１０Ａ又は交通基盤システム３００で実行されてもよい。車両１０Ｂの走行状態の解析が車両１０Ａ又は交通基盤システム３００で実行された場合、その結果は、通信ネットワーク９００を介してデータ解析サーバ２００に提供される。

［２−２．データ解析サーバの構成］
次に、データ解析サーバ２００の構成について説明する。図４は、データ解析サーバ２００の機能構成例を示すブロック図である。なお、データ解析サーバ２００は、プロセッサ及びメモリを備える一台以上のコンピュータ資源を用いて実現される。データ解析サーバ２００は、通信ネットワーク９００を介して車両１０及び交通基盤システム３００から受信するデータを解析してサイバー攻撃による異常を検知、又はさらに異常レベルの判定を実行し、必要に応じて車両１０又は交通基盤システム３００に情報を提供する。このような機能を、データ解析サーバ２００は所定のプログラムを実行して提供する。また、このプログラムでは、例えば機械学習によって作成された異常検知モデル、又はさらに分類モデルが用いられる。

データ解析サーバ２００は、データ取得部２１０、データ解析部２２０、判定部２３０、蓄積部２４０、関連ＥＣＵ特定部２５０、アクセス権管理部２６０、情報送信部２７０及び情報表示部２８０を備える。これらは機能的な構成要素であり、データ解析サーバ２００で、プロセッサによって上記の所定のプログラムが実行されることで実現される。

データ取得部２１０は、車両１０の走行状態を示す車両データを取得する。ここでの車両１０の走行状態を示す車両データとは、例えば上述の車両１０Ａから送信される、走行状態解析部１３３による解析の結果のデータである。また、データ解析サーバ２００に送信されるデータが上述の車両１０Ｂのように未解析のデータである場合には、データ解析部２２０によってこのデータに対する解析が行われた結果のデータである。つまりデータ解析部２２０は、走行状態解析部１３３と同様の解析を実行する。

図５及び図６は、データ取得部２１０が取得する、車両１０の走行状態を示す車両データのデータ構造の一例を示す図である。

図５に示される例では、一定間隔（図示の例では５秒）の異なる時刻に測定された車両１０の走行状態を示す値が時系列で格納されている。図６に示される例では、車両１０の走行状態を示す値として、一定期間（図示の例では１０分間）にわたる測定値から算出された平均値等が時系列で格納されている。なお、車両データの内容はこれらの例に限定されない。図中の速度、旋回曲率などの各項目は例示の目的で示すものであって必須ではなく、また、さらに他の項目が含まれてもよい。また、各項目の値は、例えば一定期間ごとの最大値と最小値、一定期間内に所定の閾値を超えた又は下回ったか否か、一定期間内に所定の閾値を超えた又は下回った時間長等であってもよい。また、解析結果は、車両１０で発生した事象、例えばユーザ又は自動運転システムによる所定の運転操作（例えば発進、停止、ギヤチェンジ）を契機に取得されてもよい。この場合には、発生した事象を示す項目がさらにあってもよい。また図５及び図６では、位置情報は経緯度で示されているが、これに限定されない。例えば、車両が走行している場所の地名若しくは道路、区間、交差点名、最寄りのランドマークの名称、若しくは郵便番号等、又はこれらを示す識別情報（例えば道路の区間又はさらにその上下方向を示すＩＤ）が用いられてもよい。また、各車両１０から送信されるデータには、送信元である車両を一意に識別する識別情報が付加され、データ解析サーバ２００は車両データの各件と、この識別情報とを関連付けて管理する。

データ取得部２１０はさらに、交通基盤システム３００から、車両１０が走行するエリアにおける車両１０の車外で認識された状況（以下、車外状況という）を示す車外データを取得する。

車外データが示す車外状況とは、より具体的には、例えば道路情報又は交通情報である。

図７は、交通基盤システム３００からデータ解析サーバ２００に提供される車外データのデータ構造の一例を示す図である。

図７に示される例では、車外状況を示すデータとして、路側機による一定期間（図示の例では５分間）にわたる測定値から算出された平均値等が時系列で格納されている。このようなデータは路側機におけるセンシングデータの解析の結果であり、この解析は、路側機又は交通基盤システム３００において実行されてもよいし、データ解析部２２０によって解析されてもよい。なお、車外データの内容はこの例に限定されない。図中の制限速度、規制などの各項目は例示の目的で示すものであって必須ではなく、また、さらに他の項目が含まれてもよい。また、各項目の値は、例えば一定期間ごとの最大値と最小値、一定期間内に所定の閾値を超えた又は下回ったか否か、一定期間内に所定の閾値を超えた又は下回った時間長等であってもよい。また、解析結果は、交通基盤システム３００で発生した事象、例えば制限速度の変更を契機に取得されてもよい。この場合には、発生した事象を示す項目がさらにあってもよい。なお、図７の例では、車外状況を示すデータの送信元である各路側機の位置情報として、当該路側機が設置されている道路の区間を示す識別情報である道路ＩＤが用いられている。また、交通基盤システム３００から送信される車外データには、車外データを生成した路側機を一意に識別する識別情報が付加されてもよい。

判定部２３０は、データ取得部２１０が取得した、車両データが示す車両１０の走行状態と、車外データが示す車外状況とに不整合があるかを判定し、この判定の結果を出力する。

蓄積部２４０は、データ取得部２１０が取得した車両データ及び車外データ、判定部２３０による判定結果のデータ等、データ解析サーバ２００の各機能的構成要素が生成した又は用いるデータを、必要に応じて保持する。この例では、蓄積部２４０はデータ解析サーバ２００が備える記憶装置を用いて実現される。

関連ＥＣＵ特定部２５０は、判定部２３０によって、車両１０で異常の発生があると判定された場合に、この異常に関連するＥＣＵを特定する。

アクセス権管理部２６０は、データ取得部２１０が取得したデータ、データ解析部２２０による解析結果のデータ、又は判定部２３０による判定結果等のデータに対する、データ解析サーバ２００のユーザのアクセス権を管理する。なお、ここでのデータ解析サーバ２００のユーザとは、例えば車両１０又はその部品のメーカーである。

情報送信部２７０は、判定部２３０がした判定の結果に応じた情報を示すデータを、車両１０若しくは交通基盤システム３００、又はその両方に送信する。情報表示部２８０は、判定部２３０がした判定の結果に応じた情報をユーザに表示する。判定の結果に応じた情報については後述する。

［３．動作］
次に、本実施の形態においてデータ解析装置の機能を提供するデータ解析サーバ２００の動作について説明する。図８は、データ解析サーバ２００による処理の手順の一例を示すフロー図である。また、ネットワークセキュリティシステム１におけるデータ（情報）の流れを示す、図９及び図１０のシーケンス図もこの説明の中で適宜参照する。また、車両１０及び交通基盤システム３００において実行される処理の手順を示す図１１及び図１２のフロー図も適宜参照する。

データ解析サーバ２００では、データ取得部２１０が、車両１０から車両データを、交通基盤システム３００から車外データを受信して取得する（ステップＳ１０、Ｓ１１）。この例では、車両データは、車両１０で解析がなされてからデータ解析サーバ２００に提供される。図１１は、車両１０における車両データの取得からデータ解析サーバ２００への送信までの手順を示すフロー図である。また、車外データは、交通基盤システム３００で解析がなされてからデータ解析サーバ２００に提供される。図１２は、交通基盤システム３００における車外データの取得からデータ解析サーバ２００への送信までの手順を示すフロー図である。

次にデータ解析サーバ２００で実行されるステップＳ１２では、車両データと車外データとを比較して、車両１０の走行状態と当該車両１０の車外状況との間に不整合があるか否かを判定される。この車両データ及び車外データは、この比較の手順までに解析がなされて図５から図７に例示されるよう情報が整えられていればよく、その解析の場所（主体）は、各データの提供元であってもよいし、データの提供を受けたデータ解析サーバ２００であってもよい。本開示では、この解析の前後を特に区別せず車両データ又は車外データと呼んでいる。なお、車両１０の走行状態と当該車両１０の車外状況との間の不整合については、例を用いて後述する。

ステップＳ１２は、判定部２３０によって実行される。判定部２３０は、車両データが示す時刻及び位置情報と、車外データが示す時刻及び位置情報とを用いて、判定対象の車両データと比較する車外データを選択する。時刻又は位置情報が車両データと車外データとで異なる形式で表現されている場合には、蓄積部２４０に保持されている対応テーブル（図示なし）を参照したり、換算のための計算を実行したりしてもよい。また、判定部２３０では、時刻情報及び位置情報が必ずしも完全に一致するデータ同士で比較するのではなく、それぞれが部分的に、又は少なくとも一方が重複するデータ同士を比較の対象として選択してもよい。また、重複がなくてもある一件の車両データが含む時刻情報が示す時刻から遡る所定時間内の時刻を示す車外データ、又は遡る所定件数の車外データが比較の対象に選択されてもよい。時間的に近いために現在の交通量、現在の交通規制など現在の車外状況をよりよく反映する可能性の高い車外データを用いることで、より現状に適した異常判定の結果を得ることができる。また、車両データが含む位置情報が示す位置と地理的に近隣（例えば一定の距離若しくは道程範囲内、又は所定のグリッドで画定される領域のうち、同一の領域若しくはさらにその周囲の領域）のエリアの車外状況を示す車外データであれば、車両１０の車外状況を示す車外データとして扱い、当該車両データとの比較の対象に選択されてもよい。

不整合はないと判定部２３０が判定した場合（ステップＳ１３でＮＯ）、車両１０及び交通基盤システム３００のいずれでも、受信した各データから判るサイバー攻撃による異常はないものとして、データ解析サーバ２００での処理は終了する。

不整合があると判定部２３０が判定した場合（ステップＳ１３でＹＥＳ）、判定部２３０は車両１０及び車外データのいずれかに異常が発生しているものと判定する。このように車両データだけでなく、車外データも用いて異常判定することで、車両データ単体で異常判定する場合より高精度に異常を判定することができる。つまり、ある車両Ａがサイバー攻撃により不正制御されたケースにおいて、不正制御による走行状態が、当該車両Ａ単体の走行状態としてあり得る範疇のものである場合、車両単体データにより異常を検知することは困難である。例えば、ある車両Ａが時速３０ｋｍ／ｈで走行中に、サイバー攻撃の結果、時速１００ｋｍ／ｈで走行してしまったとする。このとき、当該車両Ａは時速１００ｋｍ／ｈで走行すること自体はあり得ることであるから、このことだけで異常と判定することはできない。しかしながら、車両データと車外データとを比較することで、このように不正制御の範疇が当該車両単体の走行状態としてあり得る走行状態であった場合でも、異常を検知できるようになる。例えば、先の例において、サイバー攻撃を受けた車両Ａの周辺車両がいずれも時速３０ｋｍ／ｈで走行しているという車外データがあったとする。すると、車両Ａの走行状態は、周辺車両と調和的に走行可能な走行状態から明らかに逸脱していることが分かり、車両Ａに異常が発生していると判定することができる。

また、不整合があると判定部２３０が判定した場合（ステップＳ１３でＹＥＳ）、判定部２３０はさらに、位置情報が示す位置が上記のエリア内にある他の車両１０から提供された車両データについて過去に行われた車外データとの比較による判定結果を、蓄積部２４０から取得する。他の車両１０の車両データと車外データとの比較による判定結果は、上述のように、車両データの各件と関連付けて管理され、送信元である車両の識別情報を参照して選択される。また、このとき判定結果が取得される他の車両データは、例えば示す時刻が時間的に近いものから一定件数取得されてもよいし、示す時刻が一定期間遡る範囲にある全件であってもよい。

そして判定部２３０は、不整合のあることを示す結果であった車両データの件数が所定基準以上であるか否かを判定する（ステップＳ１４）。この判定の基準は、例えば５０％以上のように割合で設定されてもよいし、具体的な件数の値で設定されてもよいし、又はこれらが併用（例えば３０％以上かつ５件以上）されてもよい。

不整合のあることを示す結果であった車両データの件数が所定基準未満である場合（ステップＳ１４でＮＯ）、判定部２３０は、サイバー攻撃による異常が、ステップＳ４３で不整合と判定された車両データの送信元である車両１０で発生していると判定する（ステップＳ１５）。判定部２３０からは、この判定結果が情報送信部２７０に出力される。この判定結果の入力を受けた情報送信部２７０は、少なくとも交通基盤システム３００に当該車両１０を示す情報を送信する（ステップＳ１６）。また、情報送信部２７０は、当該車両１０に、異常発生時の動作を実行させる情報を送信する（ステップＳ１７）。この情報は、単に判定の結果を示す情報であってもよいし、当該車両１０に対する制御信号で示されるものであってもよい。図８では、車両１０に送信されるのは制御信号である例が示されている。

図８に示される一連の手順で、ステップＳ１４でＮＯである場合のネットワークセキュリティシステム１におけるデータ（情報）の流れを示すのが図９である。

ステップＳ１６で情報送信部２７０から送信された、異常な車両１０を示す情報（図中「異常車両情報」）を受信した交通基盤システム３００では、当該車両１０からＶ２Ｉ通信（車両と交通基盤システムとが行う通信）で受信したデータの利用を停止する。サイバー攻撃を受けた車両１０から提供される情報は、虚偽の内容を含んでいる可能性がある。つまり、このような情報を用いた判定が交通基盤システム３００で行われれば、実際の交通状況に合わない動作をする等の悪影響が出るおそれがある。したがって、交通基盤システム３００に、サイバー攻撃を受けて異常が発生している車両１０を示す情報が提供されることで、このようなサイバー攻撃の悪影響の拡大が抑えられる。なお、このような情報は、交通基盤システム３００のみならず、異常が発生している車両１０の周辺を走行する他の車両１０にも提供されてもよい。Ｖ２Ｖ通信（車両と車両とが直接行う通信）を行う車両１０では、他の車両１０からのデータに基づいて動作の判定が行われることがあり、この判定が虚偽の情報に基づいて行われることを防ぐためである。

また、サイバー攻撃を受けている車両１０は、異常な動作をする可能性がある。したがって、情報送信部２７０からこの車両１０に上記の情報又は制御信号を送信して、周辺の車両又はそのドライバーに、異常の発生を報知するための動作等を当該車両１０にさせることで、事故の発生の可能性を抑えることができる。異常の発生を報知するための動作とは、例えばハザードランプによる警告等である。または、当該車両１０が遠隔操作に対応する場合には、退避動作を実行させてもよい。

一方、不整合のあることを示す結果であった車両データの件数が所定基準以上である場合（ステップＳ１４でＹＥＳ）、判定部２３０は、サイバー攻撃による異常が、ステップＳ１３で車両データと不整合と判定された車外データの送信元である交通基盤システム３００又はその一部である路側機で発生していると判定する（ステップＳ１５）。判定部２３０からは、この判定結果が情報送信部２７０に出力される。この判定結果の入力を受けた情報送信部２７０は、少なくとも交通基盤システム３００に、例えば当該異常が発生していると判定された車外データを送信した路側機に関する情報を送信する（ステップＳ１９）。路側機に関する情報とは、例えば、当該車外データを生成した異常な路側機を一意に示す識別情報であってもよいし、また、当該車外データが示す位置情報であってもよい。図８では、交通基盤システム３００に送信されるのは、異常な路側機を示す情報である例が示されている。

また、図８に示される一連の手順で、ステップＳ１４でＹＥＳである場合のネットワークセキュリティシステム１におけるデータ（情報）の流れを示すのが図１０である。

ステップＳ１９で情報送信部２７０から送信された、異常な車両１０を示す情報（図中「異常路側機情報」）を受信した交通基盤システム３００では、当該路側機で計測などにより生成された車外データの利用を停止する。これにより、サイバー攻撃の悪影響の拡大が抑えられる。なお、このような情報は、交通基盤システム３００のみならず、ステップＳ１３での判定の対象となった車両データを送信した車両１０、又は異常な路側機の周辺を走行する他の車両１０にも提供されてもよい。Ｖ２Ｉ通信を行う車両１０では、路側機からのデータに基づいて動作の判定が行われることがあり、この判定が虚偽の情報に基づいて行われることを防ぐためである。

なお、ここまでの説明では、データ解析サーバ２００が車両１０から受信した車両データと比較する車外データは交通基盤システム３００から提供されたものである例を用いたが、車両データと比較されるデータは交通基盤システム３００からのデータに限定されない。例えば、車両１０Ａの周辺を走行する車両１０Ｂから受信したデータが、車両１０Ａから受信した車両データと比較する車外データとして用いられてもよい。例えば車両１０Ｂが搭載する周辺を撮影するためのイメージセンサが生成した画像データが解析されて、データ解析サーバ２００では、この画像データが示す画像に映る車両１０Ａの状況と、車両１０Ａの車載ネットワークから取得された車両データが示す車両１０Ａの走行状態とが不整合であるか否かが判定されてもよい。また、車両１０Ａの車両データが示す車両１０Ａの加減速、操舵等の走行状態と、車両１０Ｂの車両データが示す車両１０Ｂの加減速、操舵等の走行状態とが不整合であるか否かが判定されてもよい。つまり、車両１０Ｂの車両データは、車両１０Ａとの関係で言えば、車両１０Ａの車外で認識された状況を示す車外データであり、データ解析サーバ２００では、ステップＳ１３での車両１０Ａの車両データとの比較対象として用いられ得る。また、車両１０Ａと車両１０Ｂとを入れ替えても同様のことが言える。

以下、このような判定が実行される場合も含めて、不整合の具体的な例を挙げる。

図１３Ａから図１３Ｆは、それぞれ本実施の形態において、データ解析サーバ２００による処理の手順の一具体例を示すフロー図である。ただし、いずれも図８のフロー図との差異はステップＳ１３の不整合に関する判定のステップであるため、他のステップについての説明は省略する。

図１３ＡのステップＳ１３Ａでは、車内データが示す車両１０の走行速度と、車外データが示す、車両１０が走行するエリアの制限速度との間での不整合について判定される。この制限速度の情報は、例えば図７に示されるような交通基盤システム３００からの車外データの「制限速度」の欄に含まれているものが利用される。また別の例として、他の車両からデータ解析サーバ２００に送信された画像データであってもよい。この場合、この画像データの解析結果に含まれる、制限速度を示す道路標識又は道路標示の表示内容が、車内データが示す車両１０の走行速度と比較される。例えばこの走行速度と制限速度との差が所定の大きさ以上である、又は表示内容が示す制限速度について予め定められた所定の速度範囲外である場合に、ステップＳ１３ＡでＹＥＳと判定される。

図１３ＢのステップＳ１３Ｂでは、車内データが示す車両１０の走行速度と、車外データが示す、この車両１０の周辺を走行している他の車両の走行速度との間での不整合について判定される。この、他の車両の走行速度の情報は、例えば図７に示されるような交通基盤システム３００車外データの「平均走行速度」の欄に含まれるものが利用される。また別の例として、他の車両からデータ解析サーバ２００に送信された車内データが示す速度又はその平均であってもよい。このように、ネットワークセキュリティシステム１では、ある車両にとっての車内データは、その他の車両にとっての車外データとして利用される場合もある。例えばこれらの走行速度間との差が所定の大きさ以上である場合に、ステップＳ１３ＢでＹＥＳと判定される。

これらの例に示されるように、データ解析サーバ２００は、ある一台の車両１０の速度が、走行性能に照らせば正常範囲内である場合でも、制限速度又は周囲の車両の走行速度という周囲の状況に照らしても正常であるか又は異常の可能性があるか判定をすることができる。

図１３ＣのステップＳ１３Ｃでは、車内データが示す車両１０の操舵角度と、車外データが示す、車両１０が走行するエリア（道路）の道路曲率との間での不整合について判定される。この道路曲率の情報は、例えば交通基盤システム３００からの車外データに含まれているものが利用される（図示なし）。この場合、車外データに含まれる道路曲率と、車内データが示す車両１０の操舵角度とが比較される。例えばこの道路曲率と操舵角度との差が所定の大きさ以上である場合に、ステップＳ１３ＣでＹＥＳと判定される。

この例に示されるように、データ解析サーバ２００は、ある一台の車両１０の操舵角度が、操舵性能に照らせば正常範囲内である場合でも、道路の形状という周囲の状況に照らして正常であるか又は異常の可能性があるか判定をすることができる。

図１３ＤのステップＳ１３Ｄでは、車内データが示す車両１０の走行速度と、車外データが示す、この車両１０の周辺を走行している他の車両で計測された当該車両１０の走行速度との間での不整合について判定される。この車外データは、他の車両が備えるレーダー等の周囲の物体の相対速度を計測可能な機器のセンシングデータの解析結果として得られる当該車両の速度である。または、上記のような他の車両でのイメージセンサで生成された画像データの解析によって得られてもよい。例えばこれらの走行速度間との差が所定の大きさ以上である場合に、ステップＳ１３ＤでＹＥＳと判定される。

この例に示されるように、データ解析サーバ２００は、ある一台の車両１０の走行速度が、走行性能に照らせば正常範囲内である場合でも、周囲の車両で認識された自車の走行速度という周囲の状況に照らして正常であるか又は異常の可能性があるか判定をすることができる。

図１３ＥのステップＳ１３Ｅでは、車内データが示す車両１０の制動灯の動作状態と、車外データが示す、車両１０の制動灯の動作状態の間での不整合について判定される。この場合の車外データは、例えば、車両１０の後続車からデータ解析サーバ２００に送信された画像データあってもよい。この画像データの解析結果に含まれる、車両１０の制動灯の経時的な動作状態が、車両１０から送信された車内データが示す車両１０の制動灯の経時的な動作状態と比較される。例えばこの動作状態に一定以上の相違がある場合に、ステップＳ１３ＥでＹＥＳと判定される。

この例に示されるように、データ解析サーバ２００は、ある一台の車両１０の制動灯の動作が、仕様上は正常範囲内である場合でも、周囲の車両で認識された自車の制動灯の動作という周囲の状況に照らして正常であるか又は異常の可能性があるか判定をすることができる。

図１３ＦのステップＳ１３Ｆでは、車内データが示す車両１０の走行状態と、車外データが示す、他の車両の走行状態との間での不整合について判定される。この場合の車外データは、例えば、車両１０の先行車からデータ解析サーバ２００に送信された車内データが示す、この先行車の走行状態（速度、操舵角等）の時系列データであってもよい。つまりこの例でも、ある車両にとっての車内データが、その他の車両にとっての車外データとして利用される。この先行車の車内データの解析結果に含まれる走行状態の時系列データが、車両１０の車内データの解析結果に含まれる走行状態の時系列データと比較される。例えばこの走行状態に一定以上の相違がある場合に、ステップＳ１３ＦでＹＥＳと判定される。

この例に示されるように、データ解析サーバ２００は、ある一台の車両１０の走行状態全般が、性能又は仕様に照らせば正常範囲内である場合でも、同じ道路を走る他の車両の走行状態という周囲の状況に照らして正常であるか又は異常の可能性があるか判定をすることができる。

このように、ある車両へのサイバー攻撃の発生についての判定は、当該車両由来のデータ（車両データ）と、交通基盤システム又は他の車両等、判定対象の車両の外部由来のデータであって当該車両が走行する環境又は当該車両の状況を示すデータ（車外データ）とを比較し、その整合性を確認することで、当該車両単体のデータのみで判定するよりも、より高い精度での検知が可能になる。

また、精度よくサイバー攻撃が検知されることで、データ通信が頻繁なＶ２Ｘ通信の普及が進んだ状況においても、不正データの拡散による被害の拡大を抑制することができる。

また、交通基盤システムも情報化が進むことでサイバー攻撃の対象となる可能性がある。本実施の形態におけるネットワークセキュリティシステム１で実行される異常判定の手法は、その交通基盤システムへのサイバー攻撃の検知の手段としても有用である。そして、このような一連の判定により、車両も交通基盤システムも含めて、サイバー攻撃の検出感度がより高く、その被害の拡大を抑えることができる車社会を実現することができる。

なお、上記の説明では、車両へのサイバー攻撃の検知を担うデータ解析装置の機能がデータ解析サーバ２００によって提供される場合を例に用いたが、本実施の形態はこれに限定されない。例えば車両１０に車載の車両データ解析装置１３０によって、上述のデータ解析サーバ２００に相当する機能が提供されてもよい。例えば、車両データ解析装置１３０において、外部通信装置１１０を介するＶ２Ｘ通信で周囲の他の車両又は路側機から取得する車外データが示す状況と、車両データが示す車両１０の走行状態との間に不整合があるか否かが判定される。不整合がある場合には、さらに車両１０の走行しているエリアでの不整合の発生状況についての情報を、蓄積部１３５に蓄積されているデータから取得したり、外部通信装置１１０を介して周辺の車両又は路側機に問い合わせたりして取得してもよい。

（実施の形態２）
［１．概要］
Ｖ２Ｘ通信が実行される状況においてサイバー攻撃の検知の精度を向上させる、別の手法に係る実施の形態を説明する。

Ｖ２Ｘ通信が実行される状況で利用されるネットワークセキュリティシステムでは、データ解析サーバ又は車載の車両データ解析装置で実行された車両データの異常に関する解析で、異常レベル、別の表現をすると、車両におけるサイバー攻撃の発生確度が、中程度という結果になる場合がある。従来の仕組みでは、車両単体のデータからでは、このような車両データは、サイバー攻撃の発生の判定には利用できないか、実用的な確実性をもって利用できるようになるまでに時間がかる。本実施の形態では、このような車両データの解析結果を検証してサイバー攻撃の発生の判定に利用する新たな手法をもって、従来に比べて精度よくかつ迅速な判定を実現する。

より具体的には、本実施の形態におけるネットワークセキュリティシステムでは、複数の車両における異常レベルの判定の結果に応じて、対応が即必要ではない中程度の異常としていた状況を、直ちに対応が必要な異常として扱うようにする。

本実施の形態も、サイバー攻撃の検知を担うデータ解析装置の機能がデータ解析サーバ２００によって提供される場合を例に説明する。構成については、実施の形態１と共通であるため説明を省略し、各構成要素は図１から図４に示す参照符号をもって示す。

以下、本実施の形態におけるデータ解析サーバ２００の動作について説明する。

［２．動作］
本実施の形態におけるネットワークセキュリティシステム１では、複数の車両１０から、各車両１０の車両データ解析装置１３０で実行された車両データの解析結果に基づいて判定される、サイバー攻撃による異常のレベルを示すデータがデータ解析サーバ２００に送信される。

図１４は、本実施の形態において各車両１０が備える車両データ解析装置１３０による処理の手順の一例を示すフロー図である。

車両データ解析装置１３０は、車載ネットワークを流れる車両データを取得すると（ステップＳ４０）、その車両データを解析して異常レベルを判定する（ステップＳ４１）。異常レベルの判定は、例えば正常状態を示す基準との乖離の程度に応じて決定される。例えば正常状態を示す基準の最大速度が時速１００ｋｍである場合に、車両データが示す走行速度が時速１８０ｋｍであれば、異常レベルは高であると判定され、車両データが示す走行速度が時速１４０ｋｍであれば、異常レベルは中であると判定される。別の例を挙げると、正常状態を示す基準の最大ステアリング回転角が７２０度である場合に、車両データが示すステアリング回転角が９００度であれば、異常レベルは高であると判定され、車両データが示すステアリング回転角が７５０度であれば、異常レベルは中であると判定される。このようなサイバー攻撃の発生確度に基づく異常レベルの判定の基準は、車両１０の情報システムの設計時に定められてもよいし、使用履歴から動的に設定されてもよい。

ステップＳ４１での判定の結果が高である場合（ステップＳ４２でＹＥＳ）、車両１０では攻撃対応措置が実行される（ステップＳ４３）。ここでの攻撃対応措置の例としては、ハザードランプの動作による周辺車両への告知、又は車両１０を路側帯など交通の妨げにならない場所に停める強制退避動作である。また、ステップＳ４１で実行された解析結果がデータ解析サーバ２００に送信される（ステップＳ４４）。図１５は、ステップＳ４４においてデータ解析サーバ２００に送信される、異常レベルの判定のための車両データの解析結果のデータ構造の一例を示す図である。この例は、ＣＡＮに準拠する車載ネットワークで高レベルの異常が発生した場合の解析結果のデータである。この例では、車両１０での異常の発生箇所、異常のレベル及び異常があったＣＡＮメッセージの種類を示すＣＡＮメッセージのＩＤといった、異常と判定されたデータに関する情報に加えて、車両１０を一意に識別するための車両ＩＤ、異常が検知された時の車両１０の位置を示す情報が含められている。なお、異常の発生時にデータ解析サーバ２００に送信されるデータに含まれる情報はこれらに限定されない。例えば後述する、グループに関連する情報が含まれていてもよい。

ステップＳ４１での判定の結果が中である場合（ステップＳ４２でＮＯ、ステップＳ４５でＹＥＳ）、ステップＳ４１で実行された解析結果がデータ解析サーバ２００に送信される（ステップＳ４６）。この場合のデータ構造も、図１５に示されるものと同様である。なお、異常レベルが中である場合には、車両１０では攻撃対応措置は実行されない。

ステップＳ４５がＮＯの場合、つまり異常レベルは低（又は正常）である場合、ステップＳ４１で取得された車両データに対する異常レベルの判定の処理はそのまま終了する。

次に、複数の車両１０からステップＳ４４又はステップＳ４６で送信される解析結果のデータを受信するデータ解析サーバ２００の処理の手順について説明する。図１６Ａは、本実施の形態におけるデータ解析サーバ２００による処理の手順の一例を示すフロー図である。

データ解析サーバ２００において、データ取得部２１０は、複数の車両１０のそれぞれから、当該車両１０へのサイバー攻撃の発生確度に基づく異常レベルを示す解析結果のデータを取得する（ステップＳ５０）。なお、この処理の説明では、異常レベルは、高、中、低の三段階であるとの前提を便宜上用いる。

次に、データ解析部２２０が、データ取得部２１０が取得した解析結果に基づいて、蓄積部２４０に保持される解析結果の統計を更新する（ステップＳ５１）。この統計は、解析結果を、所定の条件に基づいて分類されるグループごとに取られる。ここでいう所定の条件とは、解析結果の送信元である車両１０に関して、（１）所定期間内に所定の地域内を走行していること、（２）車種が同一であること、（３）メーカーが同一であること、（４）搭載する車載ネットワークの構成が共通であること、及び（５）解析された車内データの生成の時間帯が共通であることのいずれか一つ又は複数の組み合わせである。このような条件に含まれる共通性がある車載ネットワーク同士では、例えば同じ路側機又は車両からＶ２Ｘ通信で同じ不正メッセージを受信していたり、共通の脆弱性を有していたりする可能性がある。つまり、このような条件で絞られた車両１０のグループは、同じサイバー攻撃を受ける可能性が高い。したがって、このような条件で絞った車両１０のグループ単位で見ることで、異常のレベルについてより高い精度で判定できる可能性が高まる。なお、条件（４）の車載ネットワークの構成とは、準拠する通信規格、接続されているＥＣＵの機種及びそのファームウェアに関する。

なお、このグループの判別は、上記のように各車両１０から送信される解析結果に付加される情報に基づいて実行されてもよいし、蓄積部２４０に保持される、各車両ＩＤに対応付けられたグループを示すデータが参照されて実行されてもよい。

次に、判定部２３０が、異常レベルの検証の対象である解析結果のデータの送信元の車両１０と同グループの統計を蓄積部２４０から取得する（ステップＳ５２）。

次に、判定部２３０は、検証の対象である解析結果が示す異常レベルが高であるか否か確認する（ステップＳ５３）。高である場合（ステップＳ５３でＹＥＳ）、処理は終了する。

ステップＳ５３でＮＯの場合、判定部２３０はさらに、その異常レベルが中であるか否かを確認する（ステップＳ５４）。

異常レベルが中の場合（ステップＳ５４でＹＥＳ）、次に判定部２３０は、ステップＳ５２で取得したグループ内で、異常レベルが高の件数が所定基準以上であるか否かを判定する（ステップＳ５５Ａ）。つまり、サイバー攻撃を受ける可能性に関して共通性のある車両１０のグループ内で高レベルの異常がある程度より多く発生しているか否か判定する。この判定の基準は、例えば５０％以上のように割合で設定されてもよいし、具体的な件数の値で設定されてもよいし、又はこれらが併用（例えば３０％以上かつ５件以上）されてもよい。

ステップＳ５５ＡでＹＥＳの場合、情報送信部２７０から、当該検証の対象である解析結果のデータの送信元の車両１０へ、異常レベルを中から高へ変更する指示が送信される（ステップＳ５６）。なお、ステップＳ５４又はステップＳ５５ＡでＮＯの場合、処理は終了する。

図１６Ｂは、本実施の形態におけるデータ解析サーバ２００による処理の手順の他の例を示すフロー図である。

この他の例における処理は、図１６Ａに示される処理と、受信した異常レベルが中である場合（ステップＳ５４でＹＥＳ）の以降のステップの内容が異なる。図１６Ａに示される処理では、異常レベルが中である解析結果のデータの検証において、そのデータ送信元の車両１０と同一グループの車両１０で異常レベルが高という解析結果の件数が所定基準以上ある場合に、その検証対象の解析結果の異常レベルが高に引き上げられる。つまり、共通性のあるグループの中で、サイバー攻撃を受けている確度が高い又はサイバー攻撃を受けていることが確実であるという事例が多いため、中レベルの異常が発生した車両においても、より慎重な対応を取らせる処理である。

これに対し、図１６Ｂに示される処理では、異常レベルが中である解析結果のデータの検証において、そのデータ送信元の車両１０と同一グループの車両１０で異常レベルが中という解析結果の件数が所定基準（例えば５０％）以上ある場合（Ｓ５５ＢでＹＥＳ）に、その検証対象の解析結果の異常レベルが高に引き上げられる。つまり、共通性のあるグループの中で、サイバー攻撃を受けている確度が高い又はサイバー攻撃を受けていることが確実であるという事例は多くなくても、中レベルの異常が発生している事例が所定基準（例えば７０％）以上ある場合には、中レベルの異常が発生した車両においてより慎重な対応を取らせる処理である。この場合、ステップＳ５６の指示は、検証の対象である解析結果のデータの送信元の車両１０のみへ送られてもよいし、交通のサイバー攻撃に対する安全性を速効的に高めるために、この車両１０と同一グループで中レベルの異常が発生したという解析結果を送信したすべての車両１０にも送信されてもよい。

図１７は、本実施の形態におけるネットワークセキュリティシステム１のシーケンス図である。図１７では便宜的に、解析結果の検証対象であるデータを送信した車両１０を、他の車両１０から独立させて示している。

図１７に示されるように、各車両１０から、解析によって異常レベルが中又は高と判定された結果を示すデータがデータ解析サーバ２００に送信される。データ解析サーバ２００では、受信したデータを用いて統計が更新される。解析結果の検証時には、最新の統計から該当するグループの統計が取得される。検証の対象の解析結果が示す異常レベルが中であり、取得した統計が示す異常レベルが高又は中の件数が所定基準以上の場合、検証の対象の解析結果が示すレベルは高に修正される。この高レベルは、本実施の形態における修正レベルの例である。そして、異常レベルの修正レベルへの変更指示がデータ解析サーバ２００から車両１０に送信される。この変更指示を受信した車両１０では、図１４に示すステップＳ４２でＹＥＳと判定された場合と同様に、ステップＳ４３での攻撃対応措置が実行される。

なお、ステップＳ５６の変更指示を受信した車両１０では、攻撃対応措置に加えて、走行状態解析部１３３による車両データの解析の基準を変更してもよい。つまり、従前は解析によって中レベルの異常と判定していた車両データに対しても、次回以降に車両データ解析装置１３０で取得されたときには、高レベルであると判定するように基準を変更してもよい。これにより、車載ネットワーク１００では、以降の同種の攻撃に対する車両１０の攻撃対応措置は、より速やかに実行される。

また、上記では便宜上、高中低の２段階の異常レベル間での検証、修正で説明をしたが、本実施の形態の発想は、２段階又は４段階以上の異常レベル間での検証、修正にも適用できる。つまり、設定された異常レベルの段階数を問わず、車両での解析によって判定される異常レベルについて、同じサイバー攻撃による影響を受ける可能性の高い他の車両で判定された異常レベルを用いて検証及び修正がなされてもよい。

また、４段階以上の異常レベルが設定されている場合において、同一グループの統計でのより高い異常レベルの判定状況（件数又はその割合）に応じて、引き上げるレベル数が変更されてもよい。つまり、同一グループ内での異常レベルの判定状況に応じてに、異常レベルをいちどに２段階以上引き上げる指示がデータ解析サーバ２００から出されてもよい。例えば、異常レベルが昇順でレベル１〜５まで設定され、レベル２〜４がステップＳ５４で「中」と判定される場合を想定する。この場合の以降のステップでは、例えば「中」の件数は所定以上で、かつその過半数を占めるのがレベル２又は３である場合には、受信した異常レベルがレベル２であればレベル３へ、レベル３であればレベル４へと１段階、過半数を占めるのがレベル４である場合には、受信した異常レベルがレベル２であればレベル４に、レベル３又は４であればレベル５へと、１段階又は２段階引き上げられてもよい。別の例として、「中」の件数は所定以上で、かつその過半数を占めるのがレベル２又は３である場合には、受信した異常レベルがレベル２であってもレベル３であってもレベル４へと１段階又は２段階引き上げられ、過半数を占めるのがレベル４である場合には、受信した異常レベルがレベル２〜４のいずれであってもレベル５へと１から３段階引き上げられてもよい。

また、車両１０では異常レベルの判定が実行されず、車両データをデータ解析サーバ２００に送信し、車両データを受信したデータ解析サーバ２００において、データ解析部２２０が車両データを解析して異常レベルを判定してからステップＳ５１以降の処理が行われてもよい。

（実施の形態３）
［１．概要］
Ｖ２Ｘ通信が実行される状況において、サイバー攻撃の検知の精度を向上させるさらに別の手法に係る実施の形態を説明する。

従来の車両単体の車両データを用いてサイバー攻撃による異常検知をする手法では、不正データの検出は可能であっても、なりすまし等の高度な手法、又は採用されている通信プロトコルの制約によって、その不正データを送出している機器の特定までは不可能な場合がある。例えばＣＡＮでは、送信されるデータ（メッセージ）に送信元を特定する情報は含まれない。メッセージには、メッセージの種類を示すＩＤが含まれており、このＩＤから設計上の送信元を特定することは可能である。しかしながら、不正データを送出する機器がその送信元になりすますことも技術上可能である。本実施の形態では、このような状況でも不正データの発生源である機器を絞り込むことができる。

より具体的には、本実施の形態におけるネットワークセキュリティシステムでは、個別の車両それぞれで発生した異常に関連した機器（ＥＣＵ）から、いずれの異常にも関連した機器を割り出す。

本実施の形態も、サイバー攻撃の検知を担うデータ解析装置の機能がデータ解析サーバ２００によって提供される場合を例に説明する。構成については、実施の形態１と共通であるため説明を省略し、各構成要素は図１から図４に示す参照符号をもって示す。

以下、本実施の形態におけるデータ解析サーバ２００の動作について説明する。

［２．動作］
本実施の形態におけるネットワークセキュリティシステム１では、複数の車両１０から、各車両１０の車両データ解析装置１３０で実行された車両データの解析結果に基づいて判定される、サイバー攻撃による異常の有無を示すデータがデータ解析サーバ２００に送信される。

図１８は、本実施の形態において各車両１０が備える車両データ解析装置１３０による処理の手順の一例を示すフロー図である。

車両データ解析装置１３０は、車載ネットワークを流れる車両データを取得すると（ステップＳ６０）、その車両データを解析して異常レベルを判定する（ステップＳ６１）。このとき、不正な車両データ、この例では攻撃のための不正な内容を含むＣＡＮメッセージ（以下、攻撃ＣＡＮメッセージという）が特定される（ステップＳ６２）。ステップＳ６２で攻撃ＣＡＮメッセージが特定される、つまり攻撃が発生すると（ステップＳ６３でＹＥＳ）、この攻撃ＣＡＮメッセージを特定して示すデータがデータ解析サーバ２００に送信される（ステップＳ６４）。ここで送信されるデータは、例えば実施の形態２の説明で参照した図１５と同様のデータであってもよい。このデータでは、攻撃ＣＡＮメッセージがメッセージＩＤを用いて特定されている（攻撃ＣＡＮメッセージＩＤの欄を参照）。

次に、複数の車両１０のそれぞれからステップＳ６４で送信されるデータを受信するデータ解析サーバ２００の処理の手順について説明する。図１９は、本実施の形態におけるデータ解析サーバ２００による処理の手順の一例を示すフロー図である。

データ解析サーバ２００において、データ取得部２１０は、車両１０から、当該車両１０に異常を発生させた攻撃ＣＡＮメッセージを特定して示す異常解析結果のデータを取得する（ステップＳ７０）。異常解析結果が示す攻撃ＣＡＮメッセージは、本実施の形態における異常データの一例である。

次に、関連ＥＣＵ特定部２５０が、データ取得部２１０が取得した異常解析結果のデータを用いて、攻撃ＣＡＮメッセージのメッセージＩＤを持つＣＡＮメッセージの設計上の本来の送信元であるＥＣＵ（以下、一次ＥＣＵともいう）を特定する（ステップＳ７１、Ｓ７２）。この特定には、蓄積部２４０に保持される、当該車両１０で送信されるＣＡＮメッセージのＩＤと設計上の送信元であるＥＣＵとを関連付けたデータが参照される。図２０は、本実施の形態における、車両１０の車載ネットワーク１００を構成するＥＣＵと各ＥＣＵが送信するＣＡＮメッセージとの関連付けを示すデータの例を示す図である。例えばステップＳ７０で受信された解析結果のデータが図１５に示すものである場合、この解析結果のデータを参照して攻撃ＣＡＮメッセージのＩＤ、ＣＡＮ−００１を取得する（ステップＳ７１）。次に関連ＥＣＵ特定部２５０は図２０のデータを参照し、ＥＣＵ ＩＤが関連付けられた送信メッセージＩＤに攻撃ＣＡＮメッセージＩＤであるＣＡＮ−００１が含まれているＥＣＵ、つまりこの例ではＥＣＵ ＩＤがＥＣＵ−００１のＥＣＵを一次ＥＣＵとして特定する（ステップＳ７２）。

一次ＥＣＵは、攻撃ＣＡＮメッセージと同じメッセージＩＤのＣＡＮメッセージを設計上で送信するＥＣＵであるから、攻撃ＣＡＮメッセージを送信した可能性が高いＥＣＵといえる。例えば、一次ＥＣＵが不正に乗っ取られ、設計上は意図されていない動作をしている場合である。しかしながら、確実に攻撃ＣＡＮメッセージを送信したとは言えない。なぜなら例えば、一次ＥＣＵ以外のＥＣＵが乗っ取られ、設計上は送信することのないメッセージＩＤを持つ攻撃ＣＡＮメッセージを送信している可能性があるからである。

そこで次に、一次ＥＣＵ以外のＥＣＵも含めて、上記のような攻撃ＣＡＮメッセージを送信した可能性のあるＥＣＵを二次ＥＣＵ群として特定する。

関連ＥＣＵ特定部２５０は、車両１０の車載ネットワーク１００において、ステップＳ７２で特定した一次ＥＣＵと同一のバス上にあるＥＣＵを二次ＥＣＵ群として特定する（ステップＳ７３）。この特定には、蓄積部２４０に保持される、当該車両１０の車載ネットワーク１００におけるバスと各バスに接続されるＥＣＵとを関連付けたデータが参照される。図２１は、本実施の形態における、車両１０の車載ネットワーク１００を構成するバスと各バスに接続されるＥＣＵとの関連付けを示すデータの例を示す図である。ステップＳ７２で特定された一次ＥＣＵの例を用いると、ステップＳ７３で特定される二次ＥＣＵ群には、ＥＣＵ−００１、ＥＣＵ−００２、ＥＣＵ−００３、ＥＣＵ−００４及びＥＣＵ−００５が含まれる。ステップＳ７４で特定された二次ＥＣＵ群がある場合（ステップＳ７４でＹＥＳ）、この特定された二次ＥＣＵ群はいったん蓄積部２４０に保持される。

二次ＥＣＵ群は、攻撃ＣＡＮメッセージが送信されたバスと同じバスに接続されたＥＣＵ群であるから、この二次ＥＣＵ群の中のいずれかのＥＣＵが攻撃ＣＡＮメッセージを送信した可能性が非常に高いと言える。しかしながら、二次ＥＣＵ群の中のすべてのＥＣＵについて、攻撃ＣＡＮメッセージを送信したか否か調査するために各ＥＣＵの動作又は送受信データの解析を行うことは、多くの計算資源及び時間を消費する。

そこで次に、この二次ＥＣＵ群の中から攻撃ＣＡＮメッセージを送信した可能性が高いＥＣＵをさらに絞り込むため、関連ＥＣＵ特定部２５０は、この二次ＥＣＵ群と、別のグループに属する車両１０についてステップＳ７０からＳ７３までを実行して特定した二次ＥＣＵ群とを比較して共通のＥＣＵを含むか否か判定する（ステップＳ７５）。ここでいう別グループとは、（１）所定期間内の走行地域が異なること、（２）車種が異なること、（３）メーカーが異なること、（４）搭載する車載ネットワークの構成が異なること、及び（５）車内データが生成された時間帯が異なること、のいずれか一つ又は複数の組み合わせからなる条件を満たすことを指す。なお、（４）の車載ネットワークの構成とは、準拠する通信規格、接続されているＥＣＵの機種及びそのファームウェアに関する。

攻撃を受けた、又は異常が検知された車両１０の二次ＥＣＵ群どうしを比較し、共通するＥＣＵがあれば、その共通ＥＣＵが、攻撃ＣＡＮメッセージを送信した可能性が高いＥＣＵ、又は攻撃者に車載ネットワーク１００への侵入を許す脆弱性を抱える可能性が高いＥＣＵと言える。ここで、上記の条件で分けられる別グループに属する車両１０の二次ＥＣＵ群間では、同グループに属する車両１０の二次ＥＣＵ群間と比べ、共通ＥＣＵの数は少ない可能性が高い。したがって、別グループに属する車両１０の二次ＥＣＵ群どうしを比較することで、攻撃を受けたＥＣＵをより少ない候補に絞り込んで効率的に特定することができる。

なお、各ＥＣＵが共通（メーカー、機種名、型番、搭載するプロセッサ、プロセッサのファームウェアのバージョン、及びプロセッサのメーカーのうち、一つ以上が同じ）であるか否かの判定は、例えば蓄積部２４０にＥＣＵ ＩＤごとのデータベース（図示なし）を保持し、このデータベースを参照して行われる。

ステップＳ７５の比較の結果、１個以上の共通のＥＣＵが存在する場合（ステップＳ７６でＹＥＳ）、関連ＥＣＵ特定部２５０はこの共通ＥＣＵを攻撃関連ＥＣＵとして特定する（ステップＳ７７）。また、情報提示部２８０が、特定された攻撃関連ＥＣＵをデータ解析サーバ２００のユーザに提示する（ステップＳ７８）。ここでいう攻撃関連ＥＣＵとは、例えば攻撃ＣＡＮメッセージの送信元である可能性が高いＥＣＵ、又は攻撃ＣＡＮメッセージの送信元であるか否かに拘わらず、攻撃者に車載ネットワーク１００への侵入を許す脆弱性を抱える可能性が高いＥＣＵである。攻撃関連ＥＣＵは、本実施の形態における異常関連ＥＣＵの一例である。

ステップＳ７４で二次ＥＣＵ群がなかった場合（ステップＳ７４でＮＯ）、又は複数の二次ＥＣＵ群で共通ＥＣＵが存在しなかった若しくは比較対象の二次ＥＣＵ群が存在しなかった場合（ステップＳ７６でＮＯ）には、攻撃関連ＥＣＵの特定がされないで処理が終了する。

このように、本実施の形態におけるデータ解析サーバ２００の処理では、複数の車両１０に対する解析結果を組み合わせることにより、攻撃を受けたＥＣＵを効率的に特定することができる。

図２２は、図１９で示したデータ解析サーバ２００による処理に対応する、ネットワークセキュリティシステム１のシーケンス図である。図２２に示されるように、ユーザへの情報の提示は、ユーザの要求に応じてなされてもよい。また、提示される情報には、ステップＳ７７で特定された攻撃関連ＥＣＵのみならず、脆弱性の解決に資するその他のデータ、例えばＳ７０で車両１０から受信されたデータ、一次ＥＣＵ、二次ＥＣＵ群等の情報も含まれてもよい。ただし、ネットワークセキュリティシステム１の複数のユーザの中には、車両又はＥＣＵその他供給部品の異なるメーカーが含まれる場合もある。このような場合には、データ解析サーバ２００から提示可能な情報には、ユーザによって秘匿すべき情報が含まれることもある。このような場合、データ解析サーバ２００では、ユーザのアクセス権を管理するアクセス権管理部２６０が、各データ（情報）に対するユーザごとのアクセス権を管理し、このアクセス権に応じた情報の提示がなされる。図２３は、本実施の形態における、ネットワークセキュリティシステム１のユーザへの情報提示の手順の一例を示すフロー図である。

データ解析サーバ２００が、図示しないユーザインタフェースを介してユーザからの情報提示要求を受信する（ステップＳ８０）。このユーザは、例えば一意のＩＤとパスワードを用いてデータ解析サーバ２００にログインしている。アクセス権管理部２６０は、ＩＤで特定されるこのユーザのアクセス権の内容を、蓄積部２４０に保持されているアクセス権管理情報（図示なし）を参照して確認する（ステップＳ８１）。そして。アクセス権管理部２６０は、この確認したアクセス権の内容にしたがって、当該ユーザがアクセス可能な情報又はその一覧を、情報提示部２８０を通じてユーザに提示する（ステップＳ８２）。例えばある車両メーカーに属するユーザは、自社の車両の情報のみにアクセスできるようアクセス権が管理されているとする。この場合、ステップＳ８２で当該ユーザに提示されるのは、このユーザの属する会社の製品である車両で発生した攻撃ＣＡＮメッセージ、この攻撃ＣＡＮメッセージと関連付けられた一次ＥＣＵ、その二次ＥＣＵ群及び最終的に攻撃関連ＥＣＵと特定されたＥＣＵの情報のみを取得することができる。

このようなアクセス権管理を併用することで、データ解析サーバ２００には、他社に対して秘匿すべきデータを扱うメーカーを含む多様なユーザによる利用が促される。多様なユーザによる利用が実現すれば、データ解析サーバ２００にはより多く、より多様な車両から車両データが集められ、本実施の形態におけるステップＳ７５で比較対象となる二次ＥＣＵ群がより多く存在する可能性が高まる。その結果、攻撃関連ＥＣＵを特定できる可能性も高まる。

なお、上記の説明ではサイバー攻撃の結果として攻撃ＣＡＮメッセージを送信するようになったＥＣＵ、又は車載ネットワーク１００への侵入に対する脆弱性を抱える可能性が高いＥＣＵが特定の対象であったが、本実施の形態の技術は、サイバー攻撃に限らず、製造不良に起因する機械的な欠陥、バグ、又は使用上の故障等の各種の異常を抱える可能性が高いＥＣＵの特定にも適用することができる。この場合、データ解析サーバ２００では、図１９に示される処理が、攻撃ＣＡＮメッセージに代えて異常なメッセージを用いて実行される。つまり、これらの異常に起因してＥＣＵから送信される異常なメッセージを特定して示す異常解析結果が取得される。この異常なメッセージは、本実施の形態における、異常データの他の例である。また、関連ＥＣＵ特定部２５０は、見出した共通ＥＣＵを、ステップＳ７７で異常関連ＥＣＵとして特定する。

また、本実施の形態においても、データ取得部２１０が取得するのは、各車両１０において解析された攻撃などの異常の結果に限定されない。例えば、異常の有無の解析機能を有さない車両１０から送信されたＣＡＮメッセージがデータ解析部２２０によって解析された結果でもよい。

（他の実施の形態）
以上のように、本発明に係る技術の例示として実施の形態を説明した。しかしながら、本発明に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。

例えば、上記の各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。

このプログラムとは、例えばプロセッサ及びメモリを備えるコンピュータに、１本以上のバスを含む車載ネットワークを搭載する第一車両及び第二車両のそれぞれの前記車載ネットワークの異常を解析した結果であり、少なくとも異常データを特定する情報をそれぞれ含む複数の異常解析結果を取得させ、前記第一車両及び前記第二車両のそれぞれについて、前記車載ネットワークに接続されるＥＣＵのうち、前記複数の異常解析結果が示す異常データと関連度の高い一次ＥＣＵを特定させ、前記１本以上のバスのうち、前記一次ＥＣＵが接続されているバスに接続されている複数のＥＣＵを二次ＥＣＵ群として特定させ、前記第一車両について特定された前記二次ＥＣＵ群及び前記第二車両について特定された前記二次ＥＣＵ群のいずれにも含まれる、所定の条件を満たすＥＣＵを異常関連ＥＣＵとして特定させ、少なくとも前記異常関連ＥＣＵを示す情報を出力させるプログラムである。

また、上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本発明の範囲に含まれる。

本発明は、車載ネットワークを含む車載セキュリティシステムに利用可能である。

１ ネットワークセキュリティシステム
１０、１０Ａ、１０Ｂ 車両
１００ 車載ネットワーク
１１０ 外部通信装置
１２０ ゲートウェイ
１３０ 車両データ解析装置
１３１ 車両データ取得部
１３２ 車外データ取得部
１３３ 走行状態解析部
１３５ 蓄積部
１３６ 解析結果送信部
１３７ 車両制御データ送信部
１５０ ＥＣＵ
２００ データ解析サーバ
２１０ データ取得部
２２０ データ解析部
２３０ 判定部
２４０ 蓄積部
２５０ 関連ＥＣＵ特定部
２６０ アクセス権管理部
２７０ 情報送信部
２８０ 情報提示部
３００ 交通基盤システム
９００ 通信ネットワーク

Claims (5)

1. １本以上のバスを含む車載ネットワークを搭載する第一車両及び第二車両のそれぞれの前記車載ネットワークの異常を解析した結果であり、少なくとも異常データを特定する情報をそれぞれ含む複数の異常解析結果を取得するデータ取得部と、
   前記第一車両及び前記第二車両のそれぞれについて、前記車載ネットワークに接続されるＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）のうち、前記複数の異常解析結果が示す異常データと関連度の高い一次ＥＣＵを特定し、前記１本以上のバスのうち、前記一次ＥＣＵが接続されているバスに接続されている複数のＥＣＵを二次ＥＣＵ群として特定し、前記第一車両について特定された前記二次ＥＣＵ群及び前記第二車両について特定された前記二次ＥＣＵ群のいずれにも含まれる、所定の条件を満たすＥＣＵを異常関連ＥＣＵとして特定し、少なくとも前記異常関連ＥＣＵを示す情報を出力する関連ＥＣＵ特定部と
   を備えるデータ解析装置。
2. 前記第一車両及び前記第二車両は、
   （１）所定期間内の走行地域が異なること、
   （２）車種が異なること、
   （３）メーカーが異なること、
   （４）前記車載ネットワークの構成が異なること、及び
   （５）前記データが生成された時間帯が異なること
   のいずれか一つ又は複数の組み合わせからなる条件を満たす、
   請求項１に記載のデータ解析装置。
3. 前記関連ＥＣＵ特定部はさらに、前記データ解析装置のユーザに、当該ユーザが持つアクセス権限に応じて、前記一次ＥＣＵ、前記二次ＥＣＵ群及び前記データの少なくとも一部を出力する、
   請求項１又は２に記載のデータ解析装置。
4. 前記所定の条件は、
   （１）機種が同一であること、
   （２）メーカーが同一であること、
   （３）搭載するプロセッサの機種が同一であること、
   （４）前記プロセッサのファームウェアが同一であること、及び
   （５）前記プロセッサの製造メーカーが同一であること
   のいずれか一つ又は複数の組み合わせである、
   請求項１に記載のデータ解析装置。
5. プロセッサ及びメモリを備えるコンピュータに、
   １本以上のバスを含む車載ネットワークを搭載する第一車両及び第二車両のそれぞれの前記車載ネットワークの異常を解析した結果であり、少なくとも異常データを特定する情報をそれぞれ含む複数の異常解析結果を取得させ、
   前記第一車両及び前記第二車両のそれぞれについて、前記車載ネットワークに接続されるＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）のうち、前記複数の異常解析結果が示す異常データと関連度の高い一次ＥＣＵを特定させ、
   前記１本以上のバスのうち、前記一次ＥＣＵが接続されているバスに接続されている複数のＥＣＵを二次ＥＣＵ群として特定させ、
   前記第一車両について特定された前記二次ＥＣＵ群及び前記第二車両について特定された前記二次ＥＣＵ群のいずれにも含まれる、所定の条件を満たすＥＣＵを異常関連ＥＣＵとして特定させ、
   少なくとも前記異常関連ＥＣＵを示す情報を出力させる、
   プログラム。

Images