(57)【要約】  機器において発生するデータごとに、予め設定された１以上のルールに基づいて、前記データの情報処理装置への送信に関する優先度を判定する第１の判定部と、前記データごとに、当該データについて判定された前記優先度に基づいて、前記情報処理装置への送信の要否を判定する第２の判定部と、所定の期間において当該機器において発生したデータのうち、前記第２の判定部によって前記情報処理装置への送信が必要であると判定されたデータを前記情報処理装置へ送信する送信部と、を有することで、機器において発生するデータによる通信負荷を低減する。
2020075826.tif 000002
【特許請求の範囲】
【請求項１】
機器において発生するデータごとに、予め設定された１以上のルールに基づいて、前記データの情報処理装置への送信に関する優先度を判定する第１の判定部と、
前記データごとに、当該データについて判定された前記優先度に基づいて、前記情報処理装置への送信の要否を判定する第２の判定部と、
所定の期間において当該機器において発生したデータのうち、前記第２の判定部によって前記情報処理装置への送信が必要であると判定されたデータを前記情報処理装置へ送信する送信部と、
を有することを特徴とする機器。
【請求項２】
前記第２の判定部によって前記情報処理装置への送信が必要であると判定されたデータを記憶する記憶部を有し、
前記送信部は、前記記憶部に記憶されたデータを前記情報処理装置へ送信する、
ことを特徴とする請求項１記載の機器。
【請求項３】
前記所定の期間において当該機器において発生したデータのうち、前記第２の判定部によって前記情報処理装置への送信が必要であると判定された各データについて、前記優先度に基づいて送信順を決定する決定部を有し、
前記送信部は、前記送信順に従った順番で前記データを送信する、
ことを特徴とする請求項１又は２記載の機器。
【請求項４】
前記第２の判定部は、前記優先度に基づく前記送信の要否の判定基準を、当該機器の状態に応じて変更する、
ことを特徴とする請求項１乃至３いずれか一項記載の機器。
【請求項５】
前記送信部は、当該機器の状態に応じて、前記所定の期間において当該機器において発生したデータのうち前記情報処理装置へ送信するデータを変化させる、
ことを特徴とする請求項１乃至４いずれか一項記載の機器。
【請求項６】
前記情報処理装置からの要求に応じ、前記１以上のルールのうちのいずれかのルールを変更する変更部を有する、
ことを特徴とする請求項１乃至５いずれか一項記載の機器。
【請求項７】
機器が、
当該機器において発生するデータごとに、予め設定された１以上のルールに基づいて、前記データの情報処理装置への送信に関する優先度を判定する第１の判定手順と、
前記データごとに、当該データについて判定された前記優先度に基づいて、前記情報処理装置への送信の要否を判定する第２の判定手順と、
所定の期間において当該機器において発生したデータのうち、前記第２の判定手順において前記情報処理装置への送信が必要であると判定されたデータを前記情報処理装置へ送信する送信手順と、
を実行することを特徴とするデータ送信方法。
【請求項８】
請求項１乃至６いずれか一項記載の各部として機器を機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、機器、データ送信方法及びプログラムに関する。
【背景技術】
【０００２】
今後普及が見込まれるコネクテッドカー（外部ネットワークに接続する車両）においては、従来においてディーラーでの持ち込み作業であったＥＣＵ（Electronic Control Unit）のソフトウェアアップデートが無線で行われるなど、利便性の向上が期待されている。【０００３】
一方で、車両やその制御機器が外部ネットワークに繋がることにより、コネクテッドカーが、従来のＩＴ機器同様、悪意の有る攻撃者からのサイバー攻撃の対象となる懸念が指摘されている。実際に車両に搭載されたＥＣＵを、外部ネットワークからのアクセスによって不正に改竄し、車両制御を乗っ取ることが可能であったとする研究も報告されている。【０００４】
このような脅威に対して、様々な事前の対策技術が検討されているが、サイバー攻撃のリスクを完全に防ぐような対策手段というものは存在しない。したがって、万が一サイバー攻撃が発生した場合に対しても有効な事後の対策を考えておく必要がある。ＥＣＵを改竄することで車両の制御を乗っ取るような攻撃を考えた場合、車両での対策を取るためには、車載ネットワークで発生する通信を継続的に監視し、異常を検出する手法がある。しかしながら、一般に車載機器の計算リソースは潤沢ではない場合が多く、計算負荷の大きな異常検知手法は適用困難である場合が多い。【０００５】
そこで、昨今では、車両だけで対処するのではなく、クラウドと車両の双方を利用することによって、計算負荷の高い処理をクラウドで、計算負荷の低い処理や低遅延性が求められる処理を車載機で行うようなサーバクライアント連携でのサイバー攻撃への対処技術の検討が進んでいる（例えば、非特許文献１）。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】"サイバー攻撃に対抗するオートモーティブ侵入検知防御システムを開発"、［online］、インターネット＜ＵＲＬ：https://news.panasonic.com/jp/press/data/2017/10/jn171010-2/jn171010-2.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、より多くの車載器が電子的に制御されるようになったことに伴い、車内で生成される通信・状態等のログ情報や各種センサ情報の量は増大することが考えられる。これら全てのデータを車載器に保持したり、サーバにアップロードしたりすることは保存や通信コストの観点から困難である。一方で、上記のようなコネクテッドカーに対するサイバー攻撃の可能性に鑑みれば、攻撃を検知するために適切なデータがサーバにアップロードされる必要がある。つまり、潤沢な計算リソースを掛けることで検出可能になる異常や、異常を検出するための検知器を更新するための多様な正常データがアップロードされる必要がある。【０００８】
なお、上記のような問題は、車両に限られず、ネットワークに接続される各種の機器について共通の課題であると考えられる。【０００９】
本発明は、上記の点に鑑みてなされたものであって、機器において発生するデータによる通信負荷を低減することを目的とする。
【課題を解決するための手段】
【００１０】
そこで上記課題を解決するため、機器は、機器において発生するデータごとに、予め設定された１以上のルールに基づいて、前記データの情報処理装置への送信に関する優先度を判定する第１の判定部と、前記データごとに、当該データについて判定された前記優先度に基づいて、前記情報処理装置への送信の要否を判定する第２の判定部と、所定の期間において当該機器において発生したデータのうち、前記第２の判定部によって前記情報処理装置への送信が必要であると判定されたデータを前記情報処理装置へ送信する送信部と、を有する。
【発明の効果】
【００１１】
機器において発生するデータによる通信負荷を低減することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施の形態におけるシステム構成例を示す図である。
【図２】本発明の実施の形態における監視サーバ１０のハードウェア構成例を示す図である。
【図３】本発明の実施の形態における車両２０のハードウェア構成例を示す図である。
【図４】本発明の実施の形態における車両２０及び監視サーバ１０の機能構成例を示す図である。
【図５】ログの発生時における処理手順の一例を説明するためのフローチャートである。
【図６】ログの構成例を示す図である。
【図７】優先度ルールＤＢ２７１の構成例を示す図である。
【図８】制御系ログＤＢ２７３の構成例を示す図である。
【図９】センサログＤＢ２７４の構成例を示す図である。
【図１０】監視サーバ１０へのログの送信時における処理手順の一例を説明するためのフローチャートである。
【図１１】監視サーバ１０からの要求に応じた優先度ルールの変更処理の処理手順の一例を説明するためのフローチャートである。
【発明を実施するための形態】
【００１３】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるシステム構成例を示す図である。図１において、複数の車両２０は、インターネット等のネットワークＮ１を介して各種のサーバ（監視サーバ１０、サービス提供サーバ３０ａ、サービス提供サーバ３０ｂ等）に接続される自動車（コネクテッドカー）である。例えば、各車両２０は、移動体通信網等の無線ネットワークを介してネットワークＮ１に接続し、各種のサーバと通信する。
【００１４】
サービス提供サーバ３０ａ及びサービス提供サーバ３０ｂ等（以下、それぞれを区別しない場合「サービス提供サーバ３０」という。）は、車両２０に対して、又は車両２０から収集される情報に基づいて所定のサービスを提供する１以上のコンピュータである。例えば、サービス提供サーバ３０ａは、テレマティクスサービスを提供してもよい。また、サービス提供サーバ３０ｂは、各車両２０から収集されるデータに基づくサービスを提供してもよい。
【００１５】
監視サーバ１０は、車両２０から送信（アップロード）されるデータに基づいて、車両２０における異常の発生の検知や、異常の内容の解析等を行う１以上のコンピュータである。異常の一例として、車両２０に対するネットワークを介したサイバー攻撃等が挙げられる。
【００１６】
図２は、本発明の実施の形態における監視サーバ１０のハードウェア構成例を示す図である。図２において、監視サーバ１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
【００１７】
監視サーバ１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００１８】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って監視サーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００１９】
図３は、本発明の実施の形態における車両２０のハードウェア構成例を示す図である。図３において、車両２０は、通信装置２１０、情報系サブシステム２２０、制御系サブシステム２３０及び関門器２４０等を含む。
【００２０】
通信装置２１０は、ネットワークＮ１に接続するための通信モジュールや、他の車両２０又は道路上の機器等と通信するための通信モジュールや、スマートフォン等と無線ＬＡＮ又は近距離無線通信を介して接続するための通信モジュール等を含む。
【００２１】
情報系サブシステム２２０は、インストールされたプログラムに応じた情報処理を実行する部分であり、ＣＰＵ２２１、メモリ装置２２２、補助記憶装置２２３、表示装置２２４及び入力装置２２５等を含む。補助記憶装置２２３には、インストールされたプログラムや、当該プログラムによって利用される各種データが記憶される。メモリ装置２２２は、起動対象とされたプログラムを補助記憶装置２２３から読み出して格納する。ＣＰＵ２２１は、メモリ装置２２２に格納されたプログラムに従って情報系サブシステム２２０に係る機能を実行する。表示装置２２４はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置２２５は、ボタン等やタッチパネル等の操作部品であり、様々な操作指示を入力させるために用いられる。なお、例えば、カーナビゲーション、カーオーディオのヘッドユニット等の車載機が情報系サブシステム２２０の一例である。
【００２２】
制御系サブシステム２３０は、車両２０の挙動を制御する部分であり、各種の制御のための複数のマイコン２３１等を含む。例えば、ＥＣＵ（Electronic Control Unit）がマイコン２３１の一例である。
【００２３】
関門器２４０は、情報系サブシステム２２０と制御系サブシステム２３０と接続するためのゲートウェイ（例えば、ＣＧＷ（Central Gateway））である。すなわち、情報系サブシステム２２０において扱われる通信プロトコルは、例えば、ＩＰプロトコルであり、制御系サブシステム２３０においてマイコン２３１間の通信に利用される通信プロトコルは、制御に特化した非ＩＰプロトコル（例えば、ＣＡＮ（Controller Area Network））である。したがって、これらの通信プロトコルの違いを吸収するための関門器２４０が設けられる。
【００２４】
なお、図４に示したハードウェア構成は、一例に過ぎない。後述の機能を実現可能であれば、車両２０のハードウェア構成は特定のものに限定されない。
【００２５】
図４は、本発明の実施の形態における車両２０及び監視サーバ１０の機能構成例を示す図である。図４において、車両２０の情報系サブシステム２２０は、制御系ログ取得部２５１、センサログ生成部２５２、異常判定部２５３、優先度判定部２５４、ログ処理部２５５、送信タイミング検知部２５６、状態確認部２５７、送信順決定部２５８、ログ送信部２５９及びルール受信部２６０等を有する。これら各部は、情報系サブシステム２２０にインストールされた１以上のプログラムが、ＣＰＵ２２１に実行させる処理により実現される。情報系サブシステム２２０は、また、優先度ルールＤＢ２７１、優先度閾値ＤＢ２７２、制御系ログＤＢ２７３及びセンサログＤＢ２７４等のデータベース（記憶部）を有する。これら各データベース（記憶部）は、例えば、メモリ装置２２２又は補助記憶装置２２３等を用いて実現可能である。
【００２６】
制御系ログ取得部２５１は、制御系ログを取得する。制御系ログとは、制御系サブシステム２３０における各マイコン２３１による通信に関するログデータをいう。通信内容のデータ自体が、制御系ログとされてもよい。したがって、制御系ログは、いずれかのマイコン２３１によって通信が行われるたびに発生する。なお、当該通信の内容は、例えば、車両２０の制御、オーディオ、カーナビのようなインフォメント系の情報、車両２０内のインジケータ表示等に関する通信等の内容を示すものである。
【００２７】
センサログ生成部２５２は、センサログを生成する。センサログとは、車両２０の各所に配置されているセンサ（例えば、加速度計やＧＰＳ（Global Positioning System）受信機等）から取得されるデータ（例えば、センサによる計測値等）を含むログデータをいう。各センサからのデータの取得及び、当該データに基づくセンサログの生成は、例えば、一定周期、又は特定のイベントの発生等のタイミングにおいて実行される。センサごとにセンサログの生成周期は異なっていてもよい。また、センサログが生成されるセンサは、車両２０が有する全センサのうちの一部でもよい。
【００２８】
異常判定部２５３は、制御系ログ及びセンサログに基づいて、車両２０の異常の程度（レベル）を判定する。具体的には、異常判定部２５３は、異常の程度を示す指標の値（以下、「異常スコア」という。）を計算する。但し、異常スコアの計算には、制御系ログのみが利用されてもよい。
【００２９】
優先度判定部２５４は、制御系ログ及びセンサログ（以下、それぞれを区別しない場合、単に「ログ」という。）について、監視サーバ１０への送信に関しての優先度を判定する。優先度の判定は、優先度ルールＤＢ２７１に記憶されている優先度の判定用のルール（以下、「優先度ルール」という。）に対して、ログの内容及び当該ログに関して計算された異常スコア等を適用する（当てはめる）ことにより行われる。なお、本実施の形態では、優先度は数値によって表現され、その値が大きいほど、監視サーバ１０への送信の必要性が高いことを示す。
【００３０】
ログ処理部２５５は、ログごとに、当該ログについて判定された優先度と優先度閾値ＤＢ２７２に記憶されている閾値と比較して、ログの保存（及び監視サーバ１０への送信）の要否を判定する。ログ処理部２５５は、ログの保存が必要であると判定すると、当該ログを制御系ログＤＢ２７３又はセンサログＤＢ２７４に保存（記憶）する。
【００３１】
送信タイミング検知部２５６は、制御系ログＤＢ２７３又はセンサログＤＢ２７４に記憶されているログについて、監視サーバ１０への送信（アップロード）のタイミング（以下「送信タイミング」という。）の到来を検知する。
【００３２】
状態確認部２５７は、送信タイミングの到来に応じ、その時の車両２０の状態を確認（チェック）する。例えば、車両２０が走行状態であるか否か（停止状態であるか）や、通信装置２１０による通信状態等が確認される。
【００３３】
送信順決定部２５８は、前回の送信タイミングから今回の送信タイミングの間に制御系ログＤＢ２７３又はセンサログＤＢ２７４に記憶された各ログ（以下、「送信候補ログ」という。）の優先度等に基づいて、当該各ログの送信順を決定する。但し、制御系ログＤＢ２７３及びセンサログＤＢ２７４を経由せずにログの送信が行われてもよい。すなわち、制御系ログＤＢ２７３及びセンサログＤＢ２７４が利用されない形態が採用されてもよい。
【００３４】
ログ送信部２５９は、各送信候補ログを送信順に従った順番で監視サーバ１０へ送信する。
【００３５】
ルール受信部２６０は、監視サーバ１０から配信される優先度ルールの変更要求を受信し、当該変更要求に含まれている優先度ルールによって優先度ルールＤＢ２７１を変更（更新）する。
【００３６】
一方、監視サーバ１０は、ログ受信部１１、監視部１２、ルール変更部１３及びルール送信部１４等を有する。これら各部は、監視サーバ１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。監視サーバ１０は、また、制御系ログＤＢ１５、センサログＤＢ１６及び優先度ルールＤＢ１７等のデータベース（記憶部）を利用する。これら各データベース（記憶部）は、例えば、補助記憶装置１０２、又は監視サーバ１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
【００３７】
ログ受信部１１は、車両２０から送信（アップロード）されるログを受信し、当該ログを制御系ログＤＢ１５又はセンサログＤＢ１６に記憶する。
【００３８】
監視部１２は、制御系ログＤＢ１５又はセンサログＤＢ１６に記憶されたログ等に基づいて、車両２０に対するサイバー攻撃の発生又は発生の可能性等を検知する。監視部１２は、サイバー攻撃の発生又は発生の可能性を検知すると、優先度ルールの変更をルール変更部１３に要求する。
【００３９】
ルール変更部１３は、監視部１２からの要求に応じ、優先度ルールＤＢ１７に記憶されている一部又は全ての優先度ルールを変更する。なお、優先度ルールＤＢ１７には、各車両２０に配信されている全ての優先度ルールが記憶されている。
【００４０】
ルール送信部１４は、ルール変更部１３によって変更された優先度ルールを含む変更要求を各車両２０に配信する。
【００４１】
以下、車両２０の情報系サブシステム２２０が実行する処理手順について説明する。図５は、ログの発生時における処理手順の一例を説明するためのフローチャートである。
【００４２】
制御系ログ取得部２５１による制御系ログの取得、又はセンサログ生成部２５２によるセンサログの生成等によりいずれかのログ（以下「対象ログ」という。）が発生すると（Ｓ１０１でＹｅｓ）、異常判定部２５３は、対象ログについての異常スコアを判定（計算）する（Ｓ１０２）。
【００４３】
図６は、ログの構成例を示す図である。図６において、（１）は、制御系ログの一例を示す。制御系ログは、日時、車両ＩＤ及び要素ＩＤと、Ｄａｔａ［０］、Ｄａｔａ［１］、Ｄａｔａ［２］、Ｄａｔａ［３］、Ｄａｔａ［４］、・・・等（以下、「Ｄａｔａ［］」という。）とを含む。日時は、制御系ログが取得された日時（当該制御系ログに係る通信が行われた日時）である。車両ＩＤは、車両２０の識別情報である。要素ＩＤは、車両２０の構成要素の識別情報である。制御系ログにおける要素ＩＤは、当該制御系ログに係る通信を行ったマイコン２３１の識別情報である。Ｄａｔａ［］は、当該通信に含まれているデータである。例えば、当該通信がエンジンの制御に関する通信であれば、エンジンの制御に関する各パラメータの値が、各Ｄａｔａ［］の値となる。但し、エンジンの制御に関する各パラメータの値のみならず、チェックサムやカウンタ等のデータが、Ｄａｔａ［］に含まれてもよい。
【００４４】
一方、（２）は、センサログの一例を示す。センサログは、日時、車両ＩＤ、及び要素ＩＤと、当該センサログに係るセンサに特有のデータとを含む。日時は、センサログが生成された日時である。車両ＩＤは、車両２０の識別情報である。要素ＩＤは、当該センサログに係るデータの出力元のセンサの識別情報である。また、図６におけるセンサログは、加速度センサから取得されたデータに基づくセンサログであるため、加速度センサに特有のデータとして、Ａｃｃ＿Ｘ、Ａｃｃ＿Ｙ及びＡｃｃ＿Ｚを含む。Ａｃｃ＿Ｘ、Ａｃｃ＿Ｙ及びＡｃｃ＿Ｚは、それぞれ、Ｘ軸方向の加速度、Ｙ軸方向の加速度、Ｚ軸方向の加速度である。
【００４５】
なお、対象ログについての異常スコアの判定（計算）は、公知技術を用いて行うことができる。例えば、ログを入力とし、異常スコアを出力とする学習済みのモデル（例えば、ニューラルネットワーク）に対し、対象ログを入力することで、異常スコアが判定されてもよい。異常スコアは、異常の有無を示す０又は１であってもよいし、異常の程度を最小値（例えば、０）から最大値（例えば、１）の範囲で示す値であってもよい。また、異常スコアの判定は、制御系ログ及びセンサログの双方を用いて行われなくてよい。例えば、制御系ログ及びセンサログのいずれか一方のみが用いられて異常スコアの判定が行われてもよい。
【００４６】
続いて、優先度判定部２５４は、優先度ルールＤＢ２７１を参照して、対象ログの優先度を判定する（Ｓ１０３）。
【００４７】
図７は、優先度ルールＤＢ２７１の構成例を示す図である。図７において、優先度ルールＤＢ２７１には、要素ＩＤごと（すなわち、マイコン２３１ごと及びセンサごと）に、１以上の優先度ルールが記憶されている。すなわち、マイコン２３１ごと及びセンサごとに、ログの特性が異なるため、それぞれの特性に応じた優先度ルールの設定が可能とされている。１つの優先度ルールは、優先度を示す１つの数値を出力するように定義されてもよい。この場合、或る優先度ルールは、ログのいずれかの項目の値を１以上の閾値と比較することで優先度を離散的に決定するものでもよい。また、他の優先度ルールは、ログのいずれかの項目の値を所定の関数に対して代入することによって優先度を計算するものであってもよい。また、車両ＩＤが特定の値である場合にのみ、ステップＳ１０４における閾値以上の優先度とし、そうでない場合には、ステップＳ１０４における閾値未満の優先度とする優先度ルールが定義されてもよい。そうすることで、ログのアップロード元を一部の車両２０に限定することができる。
【００４８】
例えば、通信のタイミングに周期性が有るマイコン２３１については、当該マイコン２３１についてのログ（制御系ログ）の日時の間隔の分散が閾値以上であれば、優先度を上げるという優先度ルールが設定されてもよい。また、当該間隔が当該閾値未満であれば、優先度を上げない、又は優先度を下げるという優先度ルールが設定されてもよい。「優先度を上げる」ことは、正の値の優先度を出力することによって実現され、「優先度を下げる」ことは、負の値の優先度を出力ことによって実現されてもよい。
【００４９】
また、各マイコン２３１又は各センサについて、当該マイコン２３１又は当該センサに関するログのいずれかの項目の値が、正常状態において取りうる値の範囲から外れた場合、又は当該範囲からの外れの度合い（当該範囲からの差分）が閾値以上である場合に、優先度を上げるという優先度ルールが設定されてもよい。
【００５０】
また、各マイコン２３１又は各センサについて、異常スコアが閾値以上である場合に、優先度を上げるという優先度ルールが設定されてもよい。
【００５１】
なお、上記各閾値は、マイコン２３１ごと及びセンサごとに異なっていてもよい。また、優先度判定部２５４は、優先度ルールに基づく優先度の判定基準（例えば、上記各閾値等）を、車両２０の状態等に応じて動的に変更してもよい。
【００５２】
例えば、高速走行状態においては、車両２０の加速度やハンドルの角度、シートベルトのテンション等の機能安全に関わるマイコン２３１のログの優先度ルールに関する閾値が、低速走行状態よりも優先度が上がりやすいように変更されてもよい。具体的には、高速走行状態（速度が一定以上の状態）における第１の閾値と、低速走行状態（速度が一定未満の状態）における第２の閾値とが予め設定され、走行状態に応じて、優先度ルールに適用する閾値が選択されてもよい。又は、速度を入力とし、閾値を出力とする関数が定義されてもよい。
【００５３】
また、マイコン２３１のソフトウェアのアップデート後には、攻撃者による不正な改竄が生じる可能性がある。そこで、各マイコン２３１について、ソフトウェアのアップデート処理の発生後の一定期間は、当該マイコン２３１に関するログの優先度を上げるという優先度ルールが設定されてもよい。又は、当該一定期間は、当該マイコン２３１に関して設定されている優先度ルールの閾値が、優先度が高くなるように動的に変更されてもよい。
【００５４】
いずれにしても、通常の状態に得られるログから乖離又は逸脱した値又は高い異常スコアが得られるログの優先度が高くなるように、優先度ルールが設定されてもよい。
【００５５】
また、図７では、マイコン２３１及びセンサごとに複数の優先度ルールの設定が可能とされているが、複数の優先度ルールの組み合わせ方法を定義する優先度ルールが、マイコン２３１ごと及びセンサごとに設定されてもよい。この場合、当該優先度ルールは、例えば、複数の優先度ルールによって出力される優先度の最大値を選択するというものであってもよいし、合計値、重み付け平均、積和によって優先度を決定するというものであってもよい。又は、各優先度ルールを引数とする関数によって最終的な優先度を計算するというものであってもよい。
【００５６】
続いて、ログ処理部２５５は、ステップＳ１０３において判定された優先度を、対象ログの要素ＩＤに対応付けられて優先度閾値ＤＢ２７２に記憶されている閾値と比較する（Ｓ１０４）。当該優先度が当該閾値未満である場合（Ｓ１０４でＹｅｓ）、ログ処理部２５５は、対象ログを破棄する（Ｓ１０６）。すなわち、この場合、対象ログは、制御系ログＤＢ２７３又はセンサログＤＢ２７４に保存されない。このことは、対象ログが監視サーバ１０へ送信されないことも意味する。なお、上記したように、制御系ログＤＢ２７３及びセンサログＤＢ２７４を経由せずにログの送信が行われてもよい。
【００５７】
一方、当該優先度が当該閾値以上である場合（Ｓ１０４でＮｏ）、ログ処理部２５５は、対象ログを制御系ログＤＢ２７３又はセンサログＤＢ２７４に保存する（Ｓ１０５）。すなわち、対象ログが制御系ログであれば、対象ログは制御系ログＤＢ２７３に保存される。対象ログがセンサログであれば、対象ログはセンサログＤＢ２７４に保存される。この際、対象ログには、ステップＳ１０２において判定された異常スコアと、ステップＳ１０３において判定された優先度とが付与される。
【００５８】
図８は、制御系ログＤＢ２７３の構成例を示す図である。図８に示されるように、制御系ログＤＢ２７３の各レコードは、図６の（１）に示した各項目と、異常スコア、優先度及び送信順とを含む。このうち、ステップＳ１０５の時点において、最後の送信タイミング以降に制御系ログＤＢ２７３に記憶されたログの送信順の値は空である。送信順は、ログの送信時に決定されるからである。
【００５９】
図９は、センサログＤＢ２７４の構成例を示す図である。図９に示されるように、センサログＤＢ２７４の各レコードは、図６の（２）に示した各項目と、異常スコア、優先度及び送信順とを含む。このうち、ステップＳ１０５の時点において、最後の送信タイミング以降に制御系ログＤＢ２７３に記憶されたログの送信順の値は、制御系ログＤＢ２７３と同様の理由で空である。なお、センサログの形式は、センサごとに異なる。例えば、ＧＰＳ受信機のセンサログであれば、緯度及び経度等が含まれる。したがって、センサログＤＢ２７４には、センサごと（要素ＩＤごと）に区別されて異なるテーブルにセンサログが記憶されてもよい。
【００６０】
なお、以下において、ログとは、異常スコア、優先度及び送信順の項目が付加されたデータをいう。但し、車両２０が異常判定部２５３を有さない場合には、異常スコアの値は、０でもよいし、異常スコアの項目が空欄とされてもよい。
【００６１】
図１０は、監視サーバ１０へのログの送信時における処理手順の一例を説明するためのフローチャートである。
【００６２】
送信タイミング検知部２５６が、ログの送信タイミングの到来を検知すると（Ｓ２０１でＹｅｓ）、ステップＳ２０２以降が実行される。例えば、ログの送信は、一定周期で行われてもよい。この場合、送信タイミング検知部２５６は、前回のログの送信時から一定時間の経過時に送信タイミングの到来を検知する。又は、ログの送信は、特定のログの発生に応じて行われてもよい。この場合、送信タイミング検知部２５６は、対象ログが特定のログに該当する場合に送信タイミングの到来を検知する。特定のログとして、異常スコアが非常に高いログが一例として挙げられる。又は、ログの送信は、一定数のログが保存されるごとに行われてもよい。この場合、送信タイミング検知部２５６は、前回のログの送信後に、制御系ログＤＢ２７３又はセンサログＤＢ２７４に保存されたログの合計数が一定数に到達した際に、送信タイミングの到来を検知する。又は、ログの送信は、特定のイベント（例えば、車両２０と監視サーバ１０間との通信方式の変化等）の発生等に応じて行われてもよい。この場合、送信タイミング検知部２５６は、特定のイベントの発生に応じて送信タイミングの到来を検知する。又は、上記の２以上のタイミングにおいてログの送信が行われてもよいし、監視サーバ１０からの送信要求に応じてログの送信が行われてもよい。
【００６３】
ステップＳ２０２において、状態確認部２５７は、車両２０の状態及び車両２０（通信装置２１０）と監視サーバ１０と間の通信状態等を確認する。車両２０の状態とは、例えば、車両２０の走行状態（例えば、走行速度）等である。車両２０と監視サーバ１０と間の通信状態とは、例えば、通信方式、安定性、スループット等である。安定性は、例えば、スループットのばらつきやパケット損失率等によって評価されてもよい。
【００６４】
通信方式とは、通信に利用するネットワークの経路及び当該ネットワークにおける通信の方法をいう。例えば、通信装置２１０は、監視サーバ１０との通信方式に関して冗長性を有していてもよい。具体的には、通信装置２１０は、通常の通信方式（例えば、移動体通信網を利用した通信方式）への接続が困難な場合には、別の通信方式を利用して監視サーバ１０との通信を維持可能であってよい。例えば、通信装置２１０は、車両２０のいずれかの乗員のスマート端末等を介して移動体通信網に接続可能であれば、当該スマート端末経由で監視サーバ１０に接続してもよい。又は、通信装置２１０は、ロードサイドユニット、ＩＴＳインフラ、若しくは他の車両２０と通信可能であってもよい。この場合、通信装置２１０は、路車間通信や車々間通信を用いて、監視サーバ１０に接続してもよい。
【００６５】
このように、通信装置２１０が監視サーバ１０との通信方式について冗長性を有する場合、通信方式の確認では、通信装置２１０と監視サーバ１０との間で採用可能な通信方式の選択肢が確認される。
【００６６】
続いて、送信順決定部２５８は、前回の送信タイミングから今回の送信タイミングまでの間に制御系ログＤＢ２７３又はセンサログＤＢ２７４に保存された各ログ（送信候補ログ）について送信順を決定する（Ｓ２０３）。送信順は、例えば、優先度の降順に決定されてもよい。この場合、優先度が大きい送信候補ログほど、送信順が上位となる。又は、ステップＳ２０２において確認された走行状態等の車両２０の状態に基づいて、送信順が調整されてもよい。例えば、車速が閾値以上であれば、車両２０の挙動に関するマイコン２３１の送信候補ログの送信順が上位にされてもよい。一方、車速が閾値未満（例えば、停車中）であれば、テレメトリー関連のマイコン２３１の送信候補ログの送信順が上位にされてもよい。このように、車両２０の状態に応じて、特定のマイコン２３１又はセンサに関するログの送信順が変更されてもよい。
【００６７】
このような調整（送信順の変更）は、優先度が同じである送信候補ログ群の間で行われてもよいし、優先度が同じである送信候補ログ群の範囲を超えて行われてもよい。優先度が同じである送信候補ログ群の間での調整とは、優先度が同じ送信候補ログ群の中で、車両２０の挙動に関するマイコン２３１の送信候補ログの送信順が上位とされたり、テレメトリー関連のマイコン２３１の送信候補ログの送信順が上位されたりすることをいう。優先度が同じである送信候補ログ群の範囲を超えた調整とは、例えば、車両２０の挙動に関するマイコン２３１の送信候補ログ、又はテレメトリー関連のマイコン２３１の送信候補ログの優先度に所定値を加算した上で、優先度の降順に送信順を決定することをいう。この際、当該所定値は、送信候補ログの中で、最高の優先度以上の値であってもよい。すなわち、車両２０の挙動に関するマイコン２３１の送信候補ログ、又はテレメトリー関連のマイコン２３１の送信候補ログの送信順が、それ以外のログに対して相対的に上位とされてもよい。なお、各送信候補ログが、車両２０の挙動に関するマイコン２３１の送信候補ログ、又はテレメトリー関連のマイコン２３１の送信候補ログであるか否かは、各送信候補ログの要素ＩＤに基づいて判定可能である。例えば、各要素ＩＤに関連付けられて、当該要素ＩＤに係るマイコン２３１又はセンサがどのような機能に関連するマイコン２３１又はセンサであるのかを示す情報が、予め補助記憶装置２２３等に記憶されていてもよい。
【００６８】
続いて、ログ送信部２５９は、ステップＳ２０２において確認された通信方式の選択肢のうちのいずれか一つの選択肢（例えば、通信速度が最高の選択肢）を用いて、通信装置２１０と監視サーバ１０との間の通信を確立する（Ｓ２０４）。
【００６９】
続いて、ログ送信部２５９は、ステップＳ２０３において決定された送信順に従った順番で、各送信候補ログを監視サーバ１０へ送信する（Ｓ２０５）。この際、実際に送信される送信候補ログは、送信順においてＭ番目まで（Ｍ＜送信候補ログ数）までに限定されてもよい。すなわち、送信対象が一部の送信候補ログに限定されてもよい。特に、監視サーバ１０との通信状態において、スループットが低い場合や安定性が低い場合に、送信対象の絞り込みが行われてもよい。また、通信状態に応じて上記のＭの値が変更されてもよい。すなわち、通信状態が良好な場合（例えば、スループットが閾値以上である場合等）には、Ｍの値が大きくされ、そうでない場合には、Ｍの値が小さくされてもよい。なお、Ｍの値が０にされることがあってもよい。すなわち、通信状態に応じて、送信候補ログを１つも送信しないという判定が行われてもよい。この場合、今回の送信タイミングにおける送信候補ログは、次回の送信タイミングの到来時における送信候補ログに含められてもよい。
【００７０】
また、送信対象の絞り込みは、送信対象の数に基づいて行われるのではなく、特定のマイコン２３１又は特定のセンサのログのみが送信対象とされることによって行われてもよい。具体的には、ステップＳ２０３において、車両２０の挙動に関するマイコン２３１の送信候補ログ、又はテレメトリー関連のマイコン２３１の送信候補ログが送信順の上位にされた場合、車両２０の挙動に関するマイコン２３１の送信候補ログ、又はテレメトリー関連のマイコン２３１の送信候補ログのみが、送信対象とされてもよい。
【００７１】
なお、通信速度が高速で、通信の安定性が高い場合には、全ての送信候補ログが送信対象とされてもよい。但し、特定のマイコン２３１又はセンサに関する送信候補ログは、認証された無線ＡＰや基地局に接続されている場合にのみ（すなわち、通信経路の安全性が確保されている場合にのみ）、監視サーバ１０に送信されるようにしてもよい。そうすることで、機密性の高い情報の漏洩の可能性の低下が図られてもよい。
【００７２】
続いて、ログ送信部２５９は、送信対象の送信候補ログの送信が正常に完了したか否かを判定する（Ｓ２０６）。例えば、ＨＴＴＰ（HyperText Transfer Protocol）等のように、通信相手（監視サーバ１０）からの応答が予定されている通信方式を利用して送信候補ログの送信が行われた場合、監視サーバ１０からの正常な応答が受信されれば、送信候補ログの送信が正常に完了したと判定されてもよい。一方、ＵＤＰ（User Datagram Protocol）等のように通信相手（監視サーバ１０）からの応答が予定されていない通信方式を利用して送信候補ログの送信が行われた場合、送信の完了によって送信候補ログの送信が正常に完了したと判定されてもよい。
【００７３】
送信対象の送信候補ログの一部又は全部の送信に失敗した場合（Ｓ２０６でＮｏ）、ステップＳ２０４以降が繰り返される。この場合、ステップＳ２０４では、前回とは異なる通信方式で監視サーバ１０との通信が確立されてもよい。
【００７４】
なお、ログ送信部２５９によって送信されたログは、監視サーバ１０のログ受信部１１によって受信される。ログ受信部１１は、受信したログが制御系ログであれば当該ログを制御系ログＤＢ１５に保存し、当該ログがセンサログであれば当該ログをセンサログＤＢ１６に保存する。なお、制御系ログＤＢ１５の構成は、制御系ログＤＢ２７３（図８）と同様でもよい。また、センサログＤＢ１６の構成は、センサログＤＢ２７４（図９）と同様でもよい。
【００７５】
図１１は、監視サーバ１０からの要求に応じた優先度ルールの変更処理の処理手順の一例を説明するためのフローチャートである。
【００７６】
ルール受信部２６０は、監視サーバ１０からの優先度ルールの変更要求の受信を待機している（Ｓ３０１）。ルール受信部２６０が、当該変更要求を受信すると（Ｓ３０１でＹｅｓ）、ステップＳ３０２以降が実行される。例えば、監視サーバ１０は、優先度ルールの変更要求を以下のようなタイミングで車両２０に対して送信する。
【００７７】
監視サーバ１０の監視部１２は、定期的に、又は新たなログが制御系ログＤＢ１５又はセンサログＤＢ１６に保存されるたびに、制御系ログＤＢ１５又はセンサログＤＢ１６に保存されているログ群を参照して、サイバー攻撃等の大規模な異常（複数の車両２０に跨る異常）の発生の可能性の有無を判定する。斯かる異常の発生の可能性の有無の判定方法は、所定の方法に限定されない。例えば、学習済みのモデル（ニューラルネットワーク等）に基づいて行われてもよいし、他の公知技術を用いて行われてもよい。また、監視部１２は、ログ以外の情報源に基づいて、サイバー攻撃等の異常の発生の可能性を検知してもよい。例えば、監視部１２は、自動車会社のＣＥＲＴ（Computer Emergency Response Team）、別の企業が有するＳＯＣ（Security Operation Center）、セキュリティベンダからの発表等の情報を活用してサイバー攻撃の発生又は当該発生の懸念等を検知してもよい。
【００７８】
例えば、監視部１２は、特定のマイコン２３１に対するサイバー攻撃が発生していることを検知すると、当該マイコン２３１に関するログの優先度が高くなるように優先度ルールを変更することをルール変更部１３に要求する。ルール変更部１３は、当該マイコン２３１に関する優先度ルールを従来より優先度が高くなるように変更する。例えば、ルール変更部１３は、当該マイコン２３１の要素ＩＤに対応付けられて優先度ルールＤＢ１７に記憶されている各優先度ルールについて、従来よりも高い優先度が出力されるように定義内容を変更する。具体的には、優先度ルールに用いられている閾値が変更されてもよい。又は、優先度に対して∞を加算するといった優先度ルールが当該マイコン２３１の要素ＩＤに対して追加されてもよい。そうすることによって、当該マイコン２３１に関する制御系ログの優先度を常に∞とすることができる。ルール送信部１４は、変更された優先度ルールを含む変更要求を、各車両２０に配信する。この際、サイバー攻撃を既に受けている車両２０は、変更要求の配信先から除外されてもよい。サイバー攻撃を既に受けている車両２０は、サーバ攻撃の可能性の検知元となったログの車両ＩＤに基づいて特定可能である。
【００７９】
又は、監視部１２は、特定の車種に対してサイバー攻撃が発生している可能性を検知すると、当該車種に属する車両２０のログの優先度が高くなるように優先度ルールを変更することをルール変更部１３に要求する。例えば、ルール変更部１３は、優先度ルールが車種別に定義されている場合には、当該車種に関する全ての又は一部の優先度ルールについて、従来よりも高い優先度が出力されるように定義内容を変更する。ルール送信部１４は、変更された優先度ルールを含む変更要求を、当該車種に属する各車両２０に配信する。一方、優先度ルールが車種別に定義されていない場合には、全ての又は一部の優先度ルールのコピーを生成し、当該コピーについて、従来よりも高い優先度が出力されるように定義内容を変更する。ルール送信部１４は、変更された優先度ルールのコピーを含む変更要求を、当該車種に属する各車両２０に配信する。なお、この際、サイバー攻撃を既に受けている車両２０は、変更要求の配信先から除外されてもよい。
【００８０】
ステップＳ３０２において、ルール受信部２６０は、受信した変更要求に含まれている優先度ルールによって優先度ルールＤＢ２７１を更新する（Ｓ３０２）。具体的には、優先度ルールＤＢ２７１に記憶されている優先度ルールのうち、受信した優先度ルールと同じ要素ＩＤを含む優先度ルールが、受信した優先度ルールによって上書きされる。
【００８１】
優先度ルールＤＢ２７１の更新に成功すると（Ｓ３０３でＹｅｓ）、ルール受信部２６０は、成功通知を監視サーバ１０に送信する（Ｓ３０４）。優先度ルールＤＢ２７１の更新に失敗すると（Ｓ３０３でＮｏ）、ルール受信部２６０は、失敗通知を監視サーバ１０に送信する（Ｓ３０５）。
【００８２】
このように、本実施の形態では、監視サーバ１０側の都合により各車両２０の優先度ルールを変更することができる。したがって、各車両２０において保存されるログ、又は各車両２０から送信されるログを動的に変更することができる。その結果、例えば、監視サーバ１０の監視部１２が、特定のマイコン２３１のログを、当該マイコン２３１の異常を検知するための学習データとして利用したい場合に、当該マイコン２３１のログが収集される可能性を高めることができる。
【００８３】
なお、監視サーバ１０からの優先度ルールの変更要求には、変更後の優先度ルールが適用されるログの範囲（期間的な範囲）が指定されるようにしてもよい。この場合、当該範囲には過去の期間が含まれてもよい。そうすることで、当該変更要求より過去のログについて、変更後の優先度ルールが適用されてもよい。例えば、監視サーバ１０からのログの送信要求に応じ、変更要求より前のログについて改めて優先度が判定されて、送信対象とするログが変更されてもよい。
【００８４】
なお、本実施の形態では、車両２０を機器の一例として説明したが、通信機能を有する他の機器について本実施の形態が適用されてもよい。例えば、工場におけるロボット、各地に配置されたセンサ、オーディオ機器、家電製品、通信端末（スマートフォン、タブレット端末等）や、一般的にＩｏＴ（Internet of Things）機器と呼ばれる機器について、本実施の形態が適用されてもよい。
【００８５】
上述したように、本実施の形態によれば、車両２０において発生するデータ（ログ）ごとに、優先度ルールに基づいて優先度が判定され、当該優先度に基づいて送信が必要であると判定されたログ（送信候補ログ）が、監視サーバ１０へ送信される。したがって、全てのログが監視サーバ１０へ送信される場合に比べて、送信対象のログの量を削減することができる。その結果、車両２０（機器）において発生するログ（データ）による通信負荷を低減することができる。
【００８６】
また、送信候補ログはデータベースに記憶され、そうでないログは破棄される。したがって、車両２０における記憶領域の消費を抑制することができる。
【００８７】
また、送信候補ログについて、優先度に基づいて送信順が決定され、当該送信順に従って各送信候補ログが送信される。したがって、優先度が高い送信候補ログを優先的に監視サーバ１０へ送信することができる。
【００８８】
また、優先度に基づく送信の要否の判定基準が、車両２０の状態に応じて変更される。したがって、各ログの優先度を（すなわち、データベースの保存するログを）車両２０の状態に応じて動的に変化させることができる。
【００８９】
また、送信候補ログについて、送信対象とする基準は、車両２０の状態に応じて変更される。したがって、監視サーバ１０に送信されるログを車両２０の状態に応じて変化させることができる。
【００９０】
また、監視サーバ１０からの要求に応じて優先度ルールを変更することができる。したがって、監視サーバ１０が必要とするログが送信対象とされる可能性を高めることができる。
【００９１】
なお、本実施の形態において、車両２０は、機器の一例である。監視サーバ１０は、情報処理装置の一例である。優先度判定部２５４は、第１の判定部の一例である。ログ処理部２５５は、第２の判定部の一例である。ログ送信部２５９は、送信部の一例である。制御系ログＤＢ２７３及びセンサログＤＢ２７４は、記憶部の一例である。送信順決定部２５８は、決定部の一例である。ルール受信部２６０は、変更部の一例である。
【００９２】
以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【００９３】
本出願は、２０１８年１０月１１日に出願された日本国特許出願第２０１８−１９２４１４号に基づきその優先権を主張するものであり、同日本国特許出願の全内容を参照することにより本願に援用する。
【符号の説明】
【００９４】
１０          監視サーバ
１１          ログ受信部
１２          監視部
１３          ルール変更部
１４          ルール送信部
１５          制御系ログＤＢ
１６          センサログＤＢ
１７          優先度ルールＤＢ
２０          車両
３０ａ        サービス提供サーバ
３０ｂ        サービス提供サーバ
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
２１０        通信装置
２２１        ＣＰＵ
２２２        メモリ装置
２２３        補助記憶装置
２２４        表示装置
２２５        入力装置
２２０        情報系サブシステム
２３０        制御系サブシステム
２３１        マイコン
２４０        関門器
２５１        制御系ログ取得部
２５２        センサログ生成部
２５３        異常判定部
２５４        優先度判定部
２５５        ログ処理部
２５６        送信タイミング検知部
２５７        状態確認部
２５８        送信順決定部
２５９        ログ送信部
２６０        ルール受信部
２７１        優先度ルールＤＢ
２７２        優先度閾値ＤＢ
２７３        制御系ログＤＢ
２７４        センサログＤＢ
Ｂ            バス
【図１】
2020075826.tif 000003
【図２】
2020075826.tif 000004
【図３】
2020075826.tif 000005
【図４】
2020075826.tif 000006
【図５】
2020075826.tif 000007
【図６】
2020075826.tif 000008
【図７】
2020075826.tif 000009
【図８】
2020075826.tif 000010
【図９】
2020075826.tif 000011
【図１０】
2020075826.tif 000012
【図１１】
2020075826.tif 000013
【国際調査報告】
2020075826.tif 000014
2020075826.tif 000015
2020075826.tif 000016
2020075826.tif 000017