JP2024063876A - 優先度判定システム、優先度判定方法及びプログラム - Google Patents

Abstract

【課題】移動体の状況の変化に応じて適切にタスクの優先度を判定できる優先度判定システムを提供する。【解決手段】優先度判定システム１０は、複数の異常データを取得する異常取得部１１と、複数の状況データを取得する状況取得部１２と、リスク値を算出するリスク値算出部１４と、リスク値に基づいてタスク毎の優先度を判定する優先度判定部１５と、判定の結果に基づく出力をする出力部１７と、複数の異常データのそれぞれについて、状況変化通知対象データであるか否かを判定する状況変化通知管理部１６と、を備え、状況変化通知管理部１６は、状況変化通知対象データであると判定した異常データに対応する移動体１００に対して、変化後の状況データを通知することを要求し、リスク値算出部１４は、変化後の状況データに基づいてリスク値を再算出し、優先度判定部１５は、再算出されたリスク値に基づいてタスクの優先度を再判定する。【選択図】図１

Description

本開示は、優先度判定システム、優先度判定方法及びプログラムに関する。

従来、移動体の異常の内容だけでなく、移動体の状況にも基づいて異常のリスク値を算出し、このリスク値に基づいて異常に対処するためのタスクの優先度を判定する優先度判定システムが開示されている（例えば特許文献１）。例えば、複数の移動体に対して同じ攻撃が実施された場合であっても、攻撃された移動体の状況によってはリスク値が異なり、すなわち、リスク値に基づいて判定されるタスクの優先度も異なってくるため、どの移動体の異常についてどのタスクを実行すればよいかを判断しやすくなる。

特開２０２１－１４９２６０号公報

しかしながら、上記特許文献１に開示された優先度判定システムでは、一度移動体の状況データを取得した後、移動体において状況の変化が発生したとしても、リスク値を見直すことは想定されていない。例えば、移動体において異常が発生したときの走行状態が「停止中」であったため、低いリスク値が算出されてこの異常に対処するためのタスクの優先度が低いと判定され、このタスクが分析者への割り当て待ち状態となったとする。その後、移動体の走行状態が「走行中」に変化したとする。この場合、異常のリスクは高くなるが、タスクの優先度は低いままであり、分析者へのタスクの割り当て待ち状態が維持される。

そこで、本開示は、移動体の状況の変化に応じて適切にタスクの優先度を判定することができる優先度判定システム等を提供する。

本開示の一態様に係る優先度判定システムは、それぞれ、複数の移動体のそれぞれの異常を示す複数の異常データを取得する異常取得部と、それぞれ、前記複数の移動体のそれぞれの状況を示す複数の状況データを取得する状況取得部と、前記複数の異常データのそれぞれについて、対応する移動体の状況データに基づいて、異常のリスクを示すリスク値を算出するリスク値算出部と、前記複数の異常データのそれぞれの前記リスク値に基づいて、前記複数の異常データのそれぞれが示す異常に対処するためのタスク毎の優先度を判定する優先度判定部と、前記判定の結果に基づく出力をする出力部と、前記複数の異常データのそれぞれについて、対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知させることを要する状況変化通知対象データであるか否かを判定する状況変化通知管理部と、を備え、前記状況変化通知管理部は、前記状況変化通知対象データであると判定した異常データに対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知することを要求し、前記リスク値算出部は、変化後の状況データが取得された場合、当該変化後の状況データに基づいて、対応する移動体の異常データの前記リスク値を再算出し、前記優先度判定部は、再算出された前記リスク値に基づいて、対応する移動体の異常データが示す異常に対処するためのタスクの優先度を再判定する。

また、本開示の一態様に係る優先度判定方法は、それぞれ、複数の移動体のそれぞれの異常を示す複数の異常データを取得し、それぞれ、前記複数の移動体のそれぞれの状況を示す複数の状況データを取得し、前記複数の異常データのそれぞれについて、対応する移動体の状況データに基づいて、異常のリスクを示すリスク値を算出し、前記複数の異常データのそれぞれの前記リスク値に基づいて、前記複数の異常データのそれぞれが示す異常に対処するためのタスク毎の優先度を判定し、前記判定の結果に基づく出力をし、前記複数の異常データのそれぞれについて、対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知させることを要する状況変化通知対象データであるか否かを判定し、前記状況変化通知対象データであると判定した異常データに対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知することを要求し、変化後の状況データが取得された場合、当該変化後の状況データに基づいて、対応する移動体の異常データの前記リスク値を再算出し、再算出された前記リスク値に基づいて、対応する移動体の異常データが示す異常に対処するためのタスクの優先度を再判定する処理を含む。

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

本開示の一態様に係る優先度判定システム等は、移動体の状況の変化に応じて適切にタスクの優先度を判定することができる。

実施の形態における優先度判定システムの一例を示す構成図である。 移動体毎のインシデント管理テーブルの一例を示す図である。 実施の形態における優先度判定システムと移動体との動作の流れの一例を示すシーケンス図である。 実施の形態における優先度判定システムの動作の一例を示すフローチャートである。 異常データ及び状況データの一例を示す図である。 車種の情報の一例を示す図である。 基礎リスク値を補正するための状況データ毎の倍率の一例を示す図である。 状況変化通知対象データの一例を示す図である。 実施の形態における移動体の、状況変化通知に関する動作の一例を示すフローチャートである。 状況の項目毎の状況の変化の判定方法を説明するための図である。 実施の形態における優先度判定システムの、状況変化通知待ち受け状態時の動作の一例を示すフローチャートである。

（実施の形態）
以下、実施の形態における優先度判定システムについて図面を参照しながら説明する。

図１は、実施の形態における優先度判定システム１０の一例を示す構成図である。なお、図１には、優先度判定システム１０と通信可能に接続される移動体１００（例えば自動車）、及び、異常に対処する分析者等が利用するディスプレイ２０１及びキーボード２０２も示されている。なお、優先度判定システム１０と通信可能に接続される移動体１００は複数存在するが、図１では、１つの移動体１００を示している。

優先度判定システム１０と通信可能に接続される複数の移動体１００のそれぞれは、例えば、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の車載ネットワークが搭載された自動車等の車両であり、優先度判定システム１０等と無線通信が可能なコネクテッドカーである。

移動体１００は、異常通知部１０１及び状況通知部１０２を備える。例えば、異常通知部１０１は、車載ネットワーク又は車載ネットワークに接続されたＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）等において外部からの攻撃若しくは不正又は故障等の異常が発生したときに、当該異常を示す異常データを優先度判定システム１０に送信する。なお、異常通知部１０１は、車載ネットワークにおけるログデータを、異常検知を行う異常検知サーバ等に送信し、異常検知サーバ等から優先度判定システム１０へ、ログデータに基づいて検知された異常を示す異常データが送信されてもよい。また、状況通知部１０２は、自身の状況を示す状況データを優先度判定システム１０に送信する。例えば、状況通知部１０２は、常時又は特定のタイミング毎に状況データを優先度判定システム１０に送信してもよい。また、詳細は後述するが、状況通知部１０２は、自身の状況に変化があったときに、変化後の状況データを優先度判定システム１０に送信する機能を有する。

分析者は、例えば、ＳＯＣ（Ｓｅｃｕｒｉｔｙ Ｏｐｅｒａｔｉｏｎ Ｃｅｎｔｅｒ）等の端末を利用して移動体１００を監視する。例えば、当該端末は、複数（例えば数１００、数１０００等）の移動体１００異常情報の収集を行い、異常検知時に異常の内容を分析し、ＳＩＲＴ（Ｓｅｃｕｒｉｔｙ Ｉｎｃｉｄｅｎｔ Ｒｅｓｐｏｎｓｅ Ｔｅａｍ）等に通知する端末である。例えば、当該端末は、ＳＩＥＭ（Ｓｅｃｕｒｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｅｖｅｎｔ Ｍａｎａｇｅｍｅｎｔ）等のソフトウェアを利用可能となっている。優先度判定システム１０は、ＳＩＥＭ又はＳＯＡＲ（Ｓｅｃｕｒｉｔｙ Ｏｒｃｈｅｓｔｒａｔｉｏｎ Ａｕｔｏｍａｔｉｏｎ ａｎｄ Ｒｅｓｐｏｎｓｅ）とサーバシステムとして連携することが想定される。後述するように、当該端末には優先度判定システム１０から異常に対処するためのタスクの優先度の判定の結果に基づく出力がされ、分析者は、数多くの移動体１００において発生する異常に対処するための数多くのタスクの中から当該出力に応じて効果的にタスクを実行していくことができる。当該端末は、優先度判定システム１０と有線通信又は無線通信が可能となっている。例えば、ディスプレイ２０１及びキーボード２０２は、当該端末と接続されている。

優先度判定システム１０は、分析者が実行するタスクの優先度を判定するためのコンピュータであり、例えば、サーバである。優先度判定システム１０は、プロセッサ、メモリ及び通信インタフェース等を含む。メモリは、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）及びＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等であり、プロセッサにより実行されるプログラムを記憶することができる。優先度判定システム１０は、異常取得部１１、状況取得部１２、インシデント管理部１３、リスク値算出部１４、優先度判定部１５、状況変化通知管理部１６、出力部１７及び入力部１８を備える。異常取得部１１、状況取得部１２、インシデント管理部１３、リスク値算出部１４、優先度判定部１５、状況変化通知管理部１６、出力部１７及び入力部１８は、メモリに格納されたプログラムを実行するプロセッサ等によって実現される。優先度判定システム１０を構成する構成要素は、複数のサーバに分散して配置されていてもよい。

異常取得部１１は、複数の異常データを取得する。複数の異常データのそれぞれは、複数の移動体１００のそれぞれの異常を示す。例えば、異常取得部１１は、優先度判定システム１０が備える通信インタフェース等を介して、複数の移動体１００（若しくは異常検知サーバ等）から複数の異常データを取得する。

状況取得部１２は、複数の状況データを取得する。複数の状況データのそれぞれは、複数の移動体１００のそれぞれの状況を示す。例えば、状況取得部１２は、優先度判定システム１０が備える通信インタフェース等を介して、複数の移動体１００、路側機又はサーバ等から複数の状況データを取得する。例えば、複数の状況データのそれぞれは、移動体１００の種類（例えば車種）を示す種類情報、移動体１００の位置を示す位置情報、位置情報に対応する地点の交通情報、移動体１００の走行状態を示す走行状態情報、移動体１００の運転支援状態を示す運転支援状態情報、及び、移動体１００の充放電状態を示す充放電状態情報の少なくとも１つの情報を含む。例えば、状況取得部１２は、移動体１００から位置情報、走行状態情報、運転支援状態情報及び充放電状態情報を取得してもよく、サーバからサーバが管理している種類情報又は異常の発生状況（例えば流行している攻撃等）等を取得してもよく、路側機から移動体１００の異常が発生した場所の交通情報を取得してもよい。なお、複数の状況データのそれぞれは、これらの情報に対してさらに他のサーバ等からの情報を組み合わせたものであってもよい。

インシデント管理部１３は、異常取得部１１及び状況取得部１２が取得した複数の異常データ及び状況データを管理する。例えば、インシデント管理部１３は、移動体１００毎に異常データ及び状況データを管理する。また、例えば、インシデント管理部１３は、後述するリスク値算出部１４で算出されたリスク値を、対応する異常データに対応付けて管理する。

図２は、移動体１００毎のインシデント管理テーブルの一例を示す図である。

例えば、インシデント管理部１３は、図２に示されるように、インシデント管理テーブルにおいて、移動体１００毎の異常種類、走行状態、位置、運転支援状態、充放電状態、車種及びリスク値を管理する。例えば、インシデント管理部１３は、移動体Ａについて、運転機能障害系の異常が発生しており、走行中であり、都市部に位置し、半自動運転の状態であり、充放電中ではなく、車種Ａであり、現在の移動体Ａの状況における運転機能障害系の異常のリスク値が８００であることを管理している。また、例えば、インシデント管理部１３は、移動体Ｂについて、盗難系の異常が発生しており、停止中であり、都市部に位置し、手動運転の状態であり、充電中であり、車種Ｂであり、現在の移動体Ｂの状況における盗難系の異常のリスク値が４００であることを管理している。

リスク値算出部１４は、複数の異常データのそれぞれについて、対応する移動体１００の状況データに基づいて、異常のリスクを示すリスク値を算出する。例えば、リスク値算出部１４は、インシデント管理部１３において管理されている、図２に示されるようなインシデント管理テーブルにおける異常データ（例えば異常種類）及び状況データ（例えば、走行状態、位置、運転支援状態、充放電状態及び車種）に基づいて、リスク値を算出する。例えば、リスク値算出部１４は、異常データ又は状況データが取得される毎にリスク値を算出する。リスク値算出部１４の詳細については後述する。

優先度判定部１５は、複数の異常データのそれぞれのリスク値に基づいて、複数の異常データのそれぞれが示す異常に対処するためのタスク毎の優先度を判定する。例えば、優先度判定部１５は、複数の異常データのそれぞれのリスク値と、タスク毎の所定の指標値、例えば、タスク毎の実行されることでリスクが軽減される割合及びタスク毎の実行に要する時間の少なくとも一方とに基づいてタスク毎の優先度を判定する。例えば、優先度判定部１５は、複数の異常データのそれぞれのリスク値と、タスク毎の所定の指標値として、タスク毎の実行されることでリスクが軽減される割合と、タスク毎の実行に要する時間とに基づいてタスク毎の優先度を判定する。優先度判定部１５の詳細については後述する。なお、タスク毎の所定の指標値としては、他にもタスク毎の負荷を示す値やリスクに対する影響度合いを示す値等であってもよい。例えば、優先度判定部１５は、上記判定を、定期的に、タスクが実施される毎に、異常が検知される毎に、又は、リスク値が算出される毎に行う。

なお、図示していないが、優先度判定システム１０は、リスク値算出部１４がリスク値の算出を行う際に用いるルール及び優先度判定部１５が優先度の判定を行う際に用いるルールを記憶していてもよい。これらのルールの詳細については後述する。

また、図示していないが、優先度判定システム１０は、複数の異常データのそれぞれが示す異常と、異常に対処するための１以上のタスクとの対応関係を記憶していてもよい。また、優先度判定システム１０は、各タスクについて、タスクを実行することで軽減されるリスクの割合（リスク値の配分率とも呼ぶ）及びタスクを完了するのに要する予想対応時間を記憶していてもよい。これらの詳細については後述する。

状況変化通知管理部１６は、複数の異常データのそれぞれについて、対応する移動体１００に対して、状況の変化があった場合に変化後の状況データを通知させることを要する状況変化通知対象データであるか否かを判定する。状況変化通知管理部１６の詳細については後述する。

出力部１７は、ＳＯＣ等の端末（ディスプレイ２０１等）に対して、優先度判定部１５での優先度の判定の結果に基づく出力をする。出力部１７は、優先度判定システム１０が備える通信インタフェース等を介して、優先度の判定の結果をＳＯＣ等の端末に送信する。出力部１７からの出力の詳細については後述する。

入力部１８には、ＳＯＣ等の端末（キーボード２０２等）を介して、異常の対処が行われたこと（言い換えると異常に対処するためのタスクが実行されたこと）が入力される。入力部１８は、優先度判定システム１０が備える通信インタフェース等を介して、異常の対処が行われたことを取得する。

次に、優先度判定システム１０と移動体１００との動作の流れについて、図３を用いて説明する。

図３は、実施の形態における優先度判定システム１０と移動体１００との動作の流れの一例を示すシーケンス図である。ここでは、移動体１００として、移動体Ａ及びＢを示している。

まず、移動体Ａ及びＢを含む複数の移動体１００は、それぞれ異常データ及び状況データを優先度判定システム１０へ送信する（ステップＳ１０１Ａ、ステップＳ１０１Ｂ）。これにより、優先度判定システム１０は、複数の異常データ及び複数の状況データを取得する。

次に、優先度判定システム１０は、取得した複数の異常データ及び複数の状況データを用いて、リスク値の算出、優先度の判定及び状況変化通知の要否の判定を行う（ステップＳ１０２）。

次に、優先度判定システム１０は、優先度の判定の結果をディスプレイ２０１へ出力する（ステップＳ１０３）。これにより、分析者は、優先度の高いタスクから実行していくことができる。

次に、優先度判定システム１０は、状況変化通知が必要な移動体１００（例えば移動体Ａ）に、状況変化通知を開始させる要求（状況変化通知開始要求とも呼ぶ）を送信する（ステップＳ１０４）。これにより、移動体Ａは、状況の変化を監視する状態（状況変化監視中状態とも呼ぶ）に遷移する。

移動体Ａは、状況の変化の発生を検出した場合（ステップＳ１０５）、状況の変化を優先度判定システム１０に通知する（ステップＳ１０６）。

次に、優先度判定システム１０は、通知された変化後の状況データを用いてリスク値を再計算し、優先度を再判定する（ステップＳ１０７）。

次に、優先度判定システム１０は、再判定された優先度の判定の結果をディスプレイ２０１へ出力する（ステップＳ１０８）。例えば、ステップＳ１０３の時点では、優先度が低かったタスクの優先度が高くなった場合、分析者は、当該タスクを優先的に実行することができる。

優先度判定システム１０は、移動体Ａのインシデント（異常）の対処が完了した場合（ステップＳ１０９）、例えば、入力部１８に移動体Ａのインシデントの対処が完了したことが入力された場合、移動体Ａに状況変化通知を停止させる要求（状況変化通知停止要求とも呼ぶ）を送信する（ステップＳ１１０）。これにより、移動体Ａは、状況変化監視中状態を解除する。

なお、ステップＳ１０９で移動体Ａのインシデントの対処が完了する前に、再度移動体Ａの状況の変化があった場合には、再度ステップＳ１０５からの処理が行われる。

次に、優先度判定システム１０の動作について図４を用いて説明する。

図４は、実施の形態における優先度判定システム１０の動作の一例を示すフローチャートである。

まず、異常取得部１１は、それぞれ、複数の移動体１００のそれぞれの異常を示す複数の異常データを取得する（ステップＳ１１）。例えば、ＳＯＣ等の端末で監視される移動体１００は数多く存在し、それに伴って異常取得部１１は、数多くの異常データを取得することになる。

次に、状況取得部１２は、それぞれ、複数の移動体１００のそれぞれの状況を示す複数の状況データを取得する（ステップＳ１２）。例えば、ＳＯＣ等の端末で監視される移動体１００は数多く存在し、それに伴って状況取得部１２は、数多くの状況データを取得することになる。異常データ及び状況データの具体例について、図５を用いて説明する。

図５は、異常データ及び状況データの一例を示す図である。図５には、複数の移動体１００のうち移動体Ａから取得した異常データ及び状況データの一例が示される。

例えば、図５に示されるように、移動体Ａから取得された異常データは、「ＸＸＸＸ」という「運転機能障害系」の種類の異常を示す情報を含む。また、移動体Ａから取得された状況データは、例えば、異常が発生したときの移動体Ａの走行状態が「走行中」であり、位置が「都市部」であり、運転支援状態が「半自動運転」であり、充放電状態が「非充放電中」であり、種類（車種）が「車種Ａ」であることを示す情報を含む。

図６は、車種の情報の一例を示す図である。図６の（ａ）は、車種Ａの情報の一例を示す図であり、図６の（ｂ）は、車種Ｂの情報の一例を示す図である。

図６の（ａ）に示されるように、「車種Ａ」は、市場台数が５０００台の車種であり、問題発生時の被害想定額が前期利益未満である車種であり、用途が営業車両の車種であることを示す。図６の（ｂ）に示されるように、「車種Ｂ」は、市場台数が２００００台の車種であり、問題発生時の被害想定額が前期利益以上である車種であり、用途が家庭用車両の車種であることを示す。

次に、リスク値算出部１４は、複数の異常データのそれぞれについて、対応する移動体１００の状況データに基づいて、異常のリスク値を算出する（ステップＳ１３）。例えば、リスク値算出部１４は、複数の異常データのそれぞれについて、まずは基礎リスク値を決定する。基礎リスク値は、異常の種類に応じて算出される値であり、例えば、ＳＩＥＭによるスコア値又はＣＴＩ（Ｃｙｂｅｒ Ｔｈｒｅａｔ Ｉｎｔｅｌｌｉｇｅｎｃｅ）によるスコア値等を用いて決定（例えば算出）することができる。リスク値算出部１４によって算出されるリスク値は、例えば、異常の種類に応じて決定される基礎リスク値を、対応する移動体１００の状況データを用いて補正した値である。例えば、基礎リスク値が補正されることで得られるリスク値が大きいほど、その異常のリスクは大きくなる。ここで、基礎リスク値を補正するための倍率について図７を用いて説明する。

図７は、基礎リスク値を補正するための状況データ毎の倍率の一例を示す図である。なお、図７の（ｂ）は、状況変化通知対象項目の状況を示す状況データの倍率を示している。状況変化通知対象項目については後述する。

例えば、優先度判定システム１０には、図７の（ａ）に示されるように、「市場台数１０００台未満」の車種の移動体１００で発生した異常の基礎リスク値を１．０倍に補正するルールが記憶され、「市場台数１０００台以上１００００台未満」の車種の移動体１００で発生した異常の基礎リスク値を１．２倍に補正するルールが記憶され、「市場台数１００００台以上」の車種の移動体１００で発生した異常の基礎リスク値を２．０倍に補正するルールが記憶される。「市場台数１０００台未満」の車種の移動体１００は、市場台数が少なく異常が発生してもその影響力は小さいため、「市場台数１０００台未満」の車種の移動体１００で発生した異常の基礎リスク値は大きく補正されない。一方で、「市場台数１００００台以上」の車種の移動体１００は、市場台数が多く異常が発生するとその影響力は大きいため、「市場台数１００００台以上」の車種の移動体１００で発生した異常の基礎リスク値は大きく補正される。

また、例えば、優先度判定システム１０には、図７の（ａ）に示されるように、「被害想定額前期利益未満」の車種の移動体１００で発生した異常の基礎リスク値を１．０倍に補正するルールが記憶され、「被害想定額前期利益以上」の車種の移動体１００で発生した異常の基礎リスク値を２．０倍に補正するルールが記憶される。「被害想定額前期利益未満」の車種の移動体１００は、被害想定額が小さいため、「被害想定額前期利益未満」の車種の移動体１００で発生した異常の基礎リスク値は大きく補正されない。一方で、「被害想定額前期利益以上」の車種の移動体１００は、被害想定額が大きいため、「被害想定額前期利益以上」の車種の移動体１００で発生した異常の基礎リスク値は大きく補正される。

なお、これらの補正値（倍率）は、車種に紐づいて記憶されていてもよいし、市場台数又は被害想定額等に紐づいて記憶されていてもよい。補正値が市場台数又は被害想定額等に紐づいて記憶されている場合、中間値として車種と車種毎の市場台数又は被害想定額等が優先度判定システム１０において記憶されていてもよいし、優先度判定システム１０から外部のシステムに問い合わせて取得されてもよい。

また、例えば、優先度判定システム１０には、図７の（ａ）に示されるように、「家庭用車両」である移動体１００で発生した異常の基礎リスク値を１．０倍に補正するルールが記憶され、「営業車両」である移動体１００で発生した異常の基礎リスク値を１．２倍に補正するルールが記憶され、「緊急車両」である移動体１００で発生した異常の基礎リスク値を２．０倍に補正するルールが記憶される。「家庭用車両」である移動体１００は、頻繁に使用されにくい分、異常が発生しても問題が発生する確率が低くなるため、「家庭用車両」である移動体１００で発生した異常の基礎リスク値は大きく補正されない。「営業車両」である移動体１００は、頻繁に使用される分、異常が発生すると問題が発生する確率が高くなるため、「営業車両」である移動体１００で発生した異常の基礎リスク値は「家庭用車両」よりも大きく補正される。「緊急車両」である移動体１００は、社会的重要度が高い車両であるため、「緊急車両」である移動体１００で発生した異常の基礎リスク値は大きく補正される。

また、例えば、優先度判定システム１０には、図７の（ｂ）に示されるように、「田園地帯」に位置する移動体１００で発生した異常の基礎リスク値を１．０倍に補正するルールが記憶され、「都市部」に位置する移動体１００で発生した異常の基礎リスク値を２．０倍に補正するルールが記憶される。田園地帯は、人が少なく交通量も少ないため、「田園地帯」に位置する移動体１００で発生した異常の基礎リスク値は大きく補正されない。都市部は、人が多く交通量も多いため、「都市部」に位置する移動体１００で発生した異常の基礎リスク値は大きく補正される。

また、例えば、優先度判定システム１０には、図７の（ｂ）に示されるように、「停止中」の移動体１００で発生した異常の基礎リスク値を１．０倍に補正するルールが記憶され、「走行中」の移動体１００で発生した異常の基礎リスク値を２．０倍に補正するルールが記憶される。「停止中」の移動体１００は、停止しており異常が発生しても危険な状態になりにくいため、「停止中」の移動体１００で発生した異常の基礎リスク値は大きく補正されない。「走行中」の移動体１００は、走行しており異常が発生した場合危険な状態になりやすいため、「走行中」の移動体１００で発生した異常の基礎リスク値は大きく補正される。

また、例えば、優先度判定システム１０には、図７の（ｂ）に示されるように、「手動運転」の移動体１００で発生した異常の基礎リスク値を１．０倍に補正するルールが記憶され、「半自動運転」の移動体１００で発生した異常の基礎リスク値を１．２倍に補正するルールが記憶され、「完全自動運転」の移動体１００で発生した異常の基礎リスク値を１．５倍に補正するルールが記憶される。「手動運転」の移動体１００は、手動で運転されており異常が発生しても危険な状態になりにくいため、「手動運転」の移動体１００で発生した異常の基礎リスク値は大きく補正されない。「半自動運転」又は「完全自動運転」の移動体１００は、自動で運転しており異常が発生した場合危険な状態になりやすいため、「半自動運転」又は「完全自動運転」の移動体１００で発生した異常の基礎リスク値は大きく補正される。

また、例えば、優先度判定システム１０には、図７の（ｂ）に示されるように、「非充放電中」の移動体１００で発生した異常の基礎リスク値を１．０倍に補正するルールが記憶され、「放電中」の移動体１００で発生した異常の基礎リスク値を１．２倍に補正するルールが記憶され、「Ｖ２Ｘ放電中」又は「充電中」の移動体１００で発生した異常の基礎リスク値を１．５倍に補正するルールが記憶される。「非充放電中」の移動体１００は、充放電が行われておらず異常が発生しても危険な状態になりにくいため、「非充放電中」の移動体１００で発生した異常の基礎リスク値は大きく補正されない。「放電中」、「Ｖ２Ｘ放電中」又は「充電中」の移動体１００は、充放電が行われており異常が発生した場合危険な状態になりやすいため、「放電中」、「Ｖ２Ｘ放電中」又は「充電中」の移動体１００で発生した異常の基礎リスク値は大きく補正される。

例えば、異常が発生した移動体１００が、図５に示されるように、走行中であり（倍率２．０）、都市部に位置しており（倍率２．０）、半自動運転が行われており（倍率１．２）、非充放電中であり（倍率１．０）、車種が車種Ａである（すなわち、図６の（ａ）に示されるように、市場台数が５０００台であり（倍率１．２）、被害想定額が前期利益未満であり（倍率１．０）、営業車両である（倍率１．２））場合、リスク値を以下のように算出することができる。

リスク値＝基礎リスク値×２．０×２．０×１．２×１．０×１．２×１．０×１．２
このように、リスク値算出部１４は、複数の異常データのそれぞれについて、対応する移動体１００（異常が発生した移動体１００）の状況データを用いて基礎リスク値を補正することで異常のリスク値を算出する。

次に、優先度判定部１５は、リスク値算出部１４によって算出された複数の異常データのそれぞれのリスク値に基づいて、複数の異常データのそれぞれに対処するためのタスク毎の優先度を判定する（ステップＳ１４）。

例えば、移動体１００で発生した異常が、「ＩＶＩ（Ｉｎ Ｖｉｅｃｌｅ Ｉｎｆｏｔａｉｎｍｅｎｔ）での不正な通信」である場合、当該異常に対処するためのタスクとして、移動体１００のユーザへ異常の発生を通知する「ユーザ通知」、ＩＶＩと車載ネットワークとを遮断する「コネクション遮断」、当該異常の詳細に分析する「詳細分析」、及び、当該異常に対する対策がなされたプログラム等を配信する「恒久パッチ配信」が予め定義付けられている。言い換えると、優先度判定システム１０には、異常と当該異常に対処するためのタスクとの対応関係が記憶されている。また、各タスクには、リスク値の配分率及び予想対応時間が対応付けられている。

「ユーザ通知」を実行することで軽減されるリスクの割合は０．１０（１０％）であり、「ユーザ通知」を完了するのに要する予想対応時間は１秒の場合、１秒かけて「ユーザ通知」を実行することで「ＩＶＩでの不正な通信」のリスク値を１０％軽減できる。

「コネクション遮断」を実行することで軽減されるリスクの割合は０．４０（４０％）であり、「コネクション遮断」を完了するのに要する予想対応時間は１０秒の場合、１０秒かけて「コネクション遮断」を実行することで「ＩＶＩでの不正な通信」のリスク値を４０％軽減できる。

「詳細分析」を実行することで軽減されるリスクの割合は０．１０（１０％）であり、「詳細分析」を完了するのに要する予想対応時間は３６００秒の場合、３６００秒かけて「詳細分析」を実行することで「ＩＶＩでの不正な通信」のリスク値を１０％軽減できる。

「恒久パッチ配信」を実行することで軽減されるリスクの割合は０．４０（４０％）であり、「恒久パッチ配信」を完了するのに要する予想対応時間は６０秒の場合、６０秒かけて「恒久パッチ配信」を実行することで「ＩＶＩでの不正な通信」のリスク値を４０％軽減できる。

例えば、タスク毎の優先度は、実行されることでリスクが軽減される割合が大きいタスクほど高くなるように判定され、実行に要する時間が短いタスクほど高くなるように判定される。つまり、優先度判定部１５は、短い時間で大きくリスクを軽減できるタスクの優先度を高くする。例えば、優先度判定システム１０には、以下のような優先度の計算式で表すことができるルールが記憶され、優先度判定部１５は、当該計算式にリスク値の配分率と予想対応時間とを代入することでタスク毎の優先度を判定する。なお、以下の式１及び式２において、ｒｖ_ｄｅｃはリスク値の軽減量、ｒｖはリスク値、ｒ_{ｒａｔｉｏ}はリスク値の配分率、ｐはタスクの重要度（重要度が大きいタスクほど優先的に実行されることが望まれることから、ｐはタスクの優先度ともいえる）、αはチューニング重み、ｔ_ｅｓｔは予想対応時間である。

なお、上記式では、リスク値の配分率及び予想対応時間が極端に小さい場合や極端に大きい場合に、タスクの優先度が大きく変化してしまうため、優先度の判定には以下の式が用いられてもよい。なお、以下の式３においてαは１以上である。

ただし、例えば、「ＩＶＩでの不正な通信」に対処するためのタスクとして「恒久パッチ配信」は、「詳細分析」が完了した後でないと実行することができないタスクである。このため、優先度判定システム１０には、「恒久パッチ配信」の優先度が「詳細分析」の優先度よりも高くならないようなルールが記憶される。例えば、タスクによってチューニング重みが調整されることで、特定のタスクの優先度を低くしたり高くしたりすることができる。

例えば、優先度判定システム１０には、「ＩＶＩでの不正な通信」の他にも様々な異常と１以上のタスクとの対応関係が記憶されており、優先度判定部１５は、様々な異常について、この対応関係を参照することで、タスク毎の優先度を判定することができる。なお、「ＩＶＩでの不正な通信」には、複数のタスクが対応付けられているが、タスクが１つのみ対応付けられている異常が存在していてもよい。

このように、優先度判定部１５は、リスク値算出部１４によって算出されたリスク値に基づいてタスク毎の優先度を判定する。具体的には、優先度判定部１５は、実行されることでリスクが軽減される割合が大きいタスクほど優先度を高くし（言い換えると実行されることでリスクが軽減される割合が小さいタスクほど優先度を低くし）、また、タスクの実行に要する時間が短いタスクほど優先度を高くする（言い換えるとタスクの実行に要する時間が長いタスクほど優先度を低くする）。

そして、出力部１７は、優先度判定部１５での判定の結果に基づく出力をする（ステップＳ１５）。例えば、出力部１７は、判定の結果に基づく出力として優先度の高いタスクから実行していくことを促すアラートをディスプレイ２０１に出力して、ディスプレイ２０１は、当該アラートを表示する。なお、出力部１７は、当該アラートをスピーカなどに出力して、スピーカなどは、当該アラートを音声出力してもよい。これにより、分析者は、優先度の高いタスクから実行することができる。なお、優先度の判定及び判定の結果に基づく出力は、新たな異常が検知された際に行われてもよいし、定期的に行われてもよいし、優先度が再判定された際に行われてもよいし、それらを組み合わせて行われてもよい。

次に、状況変化通知管理部１６は、複数の異常データのそれぞれについて、対応する移動体１００に対して、状況の変化があった場合に変化後の状況データを通知させることを要する状況変化通知対象データであるか否かを判定する（ステップＳ１６）。例えば、状況変化通知管理部１６は、複数の異常データのうち特定の種類の異常データを状況変化通知対象データであると判定する。

図８は、状況変化通知対象データの一例を示す図である。図８には、状況変化通知対象データとして、運転機能障害系の異常データ、画面ロック系の異常データ及び充放電制御障害系の異常データが示されており、状況変化通知対象データではない異常データとして、情報漏洩系の異常データ及び盗難系の異常データが示されている。また、図８には、状況変化通知対象データ毎の、変化があった場合に通知させる必要のある状況の項目（状況変化通知対象項目とも呼ぶ）も示されている。

例えば、状況変化通知管理部１６は、複数の異常データのうちの特定の種類の異常データとして、運転機能障害系の異常データ、画面ロック系の異常データ及び充放電制御障害系の異常データを状況変化通知対象データであると判定する。特定の種類の異常データは、移動体１００における状況が変化した際に、異常によるリスクが変化し得るデータであり、言い換えると、算出されるリスク値、ひいては判定される優先度が変化し得るデータである。

例えば、安全運転が脅かされるような運転機能に影響を与える運転機能障害系の異常が移動体１００に発生している場合に、移動体１００の位置、走行状態又は運転支援状態が変化したときには、当該異常によるリスクが変わり得る。例えば、当該異常の発生時には移動体１００の位置が「田園地帯」だった場合、当該異常によるリスクは低いが、しばらくして位置が「都市部」に変化した場合、当該異常によるリスクが高くなる。このため、状況変化通知管理部１６は、運転機能障害系の異常データが、対応する移動体１００（具体的には、当該異常データを送信した移動体１００）に対して、状況の変化があった場合に変化後の状況データを通知させることを要する状況変化通知対象データであると判定する。

また、例えば、カーナビゲーションシステム等の車載情報機器の画面がロックされ操作不能となるような画面ロック系の異常が移動体１００に発生している場合に、移動体１００の走行状態が変化したときには、当該異常によるリスクが変わり得る。例えば、当該異常の発生時には移動体１００が「停止中」だった場合、当該異常によるリスクは低いが、しばらくして「走行中」に変化した場合、当該異常によるリスクが高くなる。このため、状況変化通知管理部１６は、画面ロック系の異常データが、対応する移動体１００に対して、状況の変化があった場合に変化後の状況データを通知させることを要する状況変化通知対象データであると判定する。

また、例えば、バッテリーの充放電制御に異常（例えば過電流等）をきたす充放電制御障害系の異常が移動体１００に発生している場合に、移動体１００の充放電状態が変化したときには、当該異常によるリスクが変わり得る。例えば、当該異常の発生時には移動体１００が「非放電中」だった場合、当該異常によるリスクは低いが、しばらくして「充電中」に変化した場合、当該異常によるリスクが高くなる。このため、状況変化通知管理部１６は、充放電制御障害系の異常データが、対応する移動体１００に対して、状況の変化があった場合に変化後の状況データを通知させることを要する状況変化通知対象データであると判定する。

なお、例えば、ロック強制解除等の盗難系の異常が移動体１００に発生している場合には、移動体１００の状況が変化しても当該異常によるリスクは変わりにくい。このため、状況変化通知管理部１６は、充放電制御障害系の異常データが、対応する移動体１００に対して、状況の変化があった場合に変化後の状況データを通知させることを要する状況変化通知対象データでないと判定する。

状況変化通知管理部１６は、複数の異常データのそれぞれが状況変化通知対象データでないと判定した場合（ステップＳ１６でＮｏ）、処理を終了する。

状況変化通知管理部１６は、複数の異常データのいずれかが状況変化通知対象データであると判定した場合（ステップＳ１６でＹｅｓ）、状況変化通知対象データであると判定した異常データに対応する移動体１００に対して、状況の変化があった場合に変化後の状況データを通知することを要求する、言い換えると、状況変化通知開始要求を送信する（ステップＳ１７）。状況変化通知開始要求は、状況の変化があった場合に変化後の状況データを通知させる指示を示す情報である。例えば、状況変化通知管理部１６は、特定の種類の異常データに対応する状況の項目を決定し、状況変化通知対象データであると判定した異常データに対応する移動体１００に対して、当該項目についての状況の変化があった場合に、変化後の状況データを通知することを要求する。

例えば、状況変化通知管理部１６は、図８に示されるような異常の種類と状況の項目（状況変化通知対象項目）との対応関係を参照することで、特定の種類の異常データとして運転機能障害系の異常データに対応する状況の項目を「位置」、「走行状態」及び「運転支援状態」に決定し、当該異常データに対応する移動体１００に対して、「位置」、「走行状態」又は「運転支援状態」についての状況の変化があった場合に、変化後の状況データを通知することを要求する。これにより、当該要求を受けた移動体１００は、移動体１００の「位置」、「走行状態」及び「運転支援状態」を監視し、「位置」、「走行状態」及び「運転支援状態」のいずれかが変化した場合に、変化後の「位置」、「走行状態」又は「運転支援状態」を優先度判定システム１０に通知することができる。

また、例えば、状況変化通知管理部１６は、図８に示されるような異常の種類と状況の項目との対応関係を参照することで、特定の種類の異常データとして画面ロック系の異常データに対応する状況の項目を「走行状態」に決定し、当該異常データに対応する移動体１００に対して、「走行状態」についての状況の変化があった場合に、変化後の状況データを通知することを要求する。これにより、当該要求を受けた移動体１００は、移動体１００の「走行状態」を監視し、「走行状態」が変化した場合に、変化後の「走行状態」を優先度判定システム１０に通知することができる。

また、例えば、状況変化通知管理部１６は、図８に示されるような異常の種類と状況の項目との対応関係を参照することで、特定の種類の異常データとして充放電制御障害系の異常データに対応する状況の項目を「充放電状態」に決定し、当該異常データに対応する移動体１００に対して、「充放電状態」についての状況の変化があった場合に、変化後の状況データを通知することを要求する。これにより、当該要求を受けた移動体１００は、移動体１００の「充放電状態」を監視し、「充放電状態」が変化した場合に、変化後の「充放電状態」を優先度判定システム１０に通知することができる。

そして、優先度判定システム１０は、状況変化通知開始要求を送信した移動体１００からの状況変化通知待ち受け状態に遷移する（ステップＳ１８）。

なお、ステップＳ１１での処理とステップＳ１２での処理とは、順序が逆であってもよいし並行して行われてもよい。また、ステップＳ１６からステップＳ１８までの処理は、ステップＳ１１及びステップＳ１２が行われた後に行われればよく、ステップＳ１３、ステップＳ１４又はステップＳ１５の前に行われてもよい。

また、特定の種類の異常、状況変化通知対象項目及びこれらの組み合わせは、図８に示されるものに限らない。例えば、特定の種類の異常、状況変化通知対象項目及びこれらの組み合わせは、適宜増やしたり、変更したりすることができる。

図９は、実施の形態における移動体１００の、状況変化通知に関する動作の一例を示すフローチャートである。

状況通知部１０２は、状況変化監視中状態であるか否かを判定し（ステップＳ２１）、状況変化監視中状態でない場合（ステップＳ２１でＮｏ）、状況変化通知開始要求を受信したか否かを判定する（ステップＳ２２）。状況通知部１０２は、状況変化通知開始要求を受信した場合（ステップＳ２２でＹｅｓ）、状況変化監視中状態に遷移し（ステップＳ２３）、状況変化通知開始要求を受信していない場合（ステップＳ２２でＮｏ）、ステップＳ２１からの処理を再度行う。

状況通知部１０２は、状況変化監視中状態である場合（ステップＳ２１でＹｅｓ）、状況変化通知停止要求を受信したか否かを判定する（ステップＳ２４）。状況通知部１０２は、状況変化通知停止要求を受信していない場合（ステップＳ２４でＮｏ）、通知が必要な状況の変化が発生したか否かを判定する（ステップＳ２５）。ここで、移動体１００における状況の変化の判定方法について、図１０を用いて説明する。

図１０は、状況の項目毎の状況の変化の判定方法を説明するための図である。

例えば、位置が田園地帯／都市部に変化したか否かは、行政区画情報から得られる人口密度情報に基づいて判定することができる。また、例えば、位置が都市部に変化したか否かは、地図データから得られる信号機密度、交差点数密度、店舗等密度、車線数等に基づいて判定することができる。

例えば、走行状態が停止中／走行中に変化したか否かは、一定時間における移動距離の変化に基づいて判定することができる。

例えば、運転支援状態が手動運転／半自動運転／完全自動運転に変化したか否かは、運転支援機能の動作状況の変化に基づいて判定することができる。

例えば、充放電状態が非充放電中／放電中／Ｖ２Ｘ放電中／充電中に変化したか否かは、移動体の充放電状態の変化に基づいて判定することができる。

状況通知部１０２は、通知が必要な状況の変化が発生していない場合（ステップＳ２５でＮｏ）、ステップＳ２１からの処理を再度行う。状況通知部１０２は、通知が必要な状況の変化が発生している場合（ステップＳ２５でＹｅｓ）、変化後の状況を優先度判定システム１０へ通知し（ステップＳ２６）、ステップＳ２１からの処理を再度行う。

状況通知部１０２は、状況変化通知停止要求を受信した場合（ステップＳ２４でＹｅｓ）、状況変化監視中状態を解除する（ステップＳ２７）。

図１１は、実施の形態における優先度判定システム１０の、状況変化通知待ち受け状態時の動作の一例を示すフローチャートである。

インシデント管理部１３は、イベントを取得したか否かを判定する（ステップＳ３１）。例えば、イベントは、分析者からの対処完了イベント又は移動体１００からの状況変化通知のイベント（具体的には、変化後の状況データを取得したことを示すイベント）である。インシデント管理部１３は、イベントを取得しない場合（ステップＳ３１でＮｏ）、ステップＳ３１からの処理を再度行う。

インシデント管理部１３は、状況変化通知のイベントを取得した場合（ステップＳ３１でＹｅｓ（状況変化通知））、つまり、変化後の状況データが取得された場合、リスク値算出部１４は、変化後の状況データに基づいて、対応する移動体１００の異常データのリスク値を再算出する（ステップＳ３２）。例えば、「停止中」の走行状態の移動体１００の運転機能障害系の異常データのリスク値が「停止中」の倍率１．０に基づいて４００と算出されていた場合に、当該移動体１００から走行状態が「走行中」に変化した状況データが取得された場合、リスク値算出部１４は、当該移動体１００の当該異常データのリスク値を、「走行中」の倍率２．０に基づいて８００と再算出する。

次に、優先度判定部１５は、再算出されたリスク値に基づいて、対応する移動体１００の異常データが示す異常に対処するためのタスクの優先度を再判定する（ステップＳ３３）。例えば、走行状態が「停止中」から「走行中」に変化した状況データを送信した移動体１００の運転機能障害系の異常データが示す異常に対処するためのタスクの優先度を高くする。

そして、出力部１７は、優先度判定部１５での判定の結果に基づく出力をする（ステップＳ３４）。例えば、出力部１７は、前回出力した判定の結果とは異なる判定の結果を出力することができ、移動体１００の状況に応じて優先度が高くなったタスクを実行させることができる。

一方で、インシデント管理部１３は、対処完了イベントを取得した場合（ステップＳ３１でＹｅｓ（対処完了イベント））、具体的には、状況変化通知開始要求を送信した移動体１００における特定の種類の異常データが示す異常の対処が行われた場合、状況変化通知管理部１６は、状況変化通知対象データであると判定した異常データに対応する移動体１００に対して、変化後の状況データを通知することを停止させる、言い換えると、状況変化通知停止要求を送信する（ステップＳ３５）。状況変化通知停止要求は、状況の変化があった場合に変化後の状況データを通知することを停止させる指示を示す情報である。

以上説明した通り、複数の異常データのうち、状況変化通知対象データについては、対応する移動体１００から、状況の変化があった場合に変化後の状況データが通知される。このため、一度移動体１００の状況データが取得された後、移動体１００において状況の変化が発生したとしても、その変化後の状況に応じたリスク値が再算出されて、タスクの優先度が再判定される。したがって、移動体１００の状況の変化に応じて適切にタスクの優先度を判定することができる。

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

例えば、上記実施の形態では、優先度判定システム１０を構成する構成要素がサーバに配置される例について説明したが、これに限らない。例えば、異常取得部１１、状況取得部１２、インシデント管理部１３、リスク値算出部１４及び状況変化通知管理部１６は、移動体１００に配置されていてもよい。この場合、これらの構成要素が配置された移動体１００は、複数の移動体１００のそれぞれの状況データを取りまとめているサーバから状況データを取得してもよいし、複数の移動体１００のそれぞれが複数の移動体１００のそれぞれの状況データを共有していてもよい。また、優先度判定部１５は、移動体１００に配置されていてもよい。例えば、アラートを構成する情報に、判定されたタスクの優先度（タスクの重要度）が追加されて、優先度判定部１５が配置された移動体１００からサーバ等に当該アラートが通知されてもよい。また、優先度判定部１５が配置された移動体１００は、タスクの定義を記憶するサーバに、異常に対処するためのタスク、リスク値の配分率及び予想対応時間等を問い合わせてもよいし、複数の移動体１００のそれぞれがこれらの情報を共有していてもよい。

また、例えば、上記実施の形態では、タスク毎の優先度は、上記式１～式３に示されるように、複数の異常データのそれぞれのリスク値と、タスク毎の実行されることでリスクが軽減される割合及びタスク毎の実行に要する時間の両方とに基づいて判定される例について説明したが、これに限らない。例えば、タスク毎の優先度は、複数の異常データのそれぞれのリスク値と、タスク毎の実行されることでリスクが軽減される割合及びタスク毎の実行に要する時間のいずれか一方とに基づいて判定されてもよい。

また、例えば、優先度判定システム１０は、複数の異常データのうち異常の発生場所が近い異常データを１つの異常データとして処理してもよい。

また、例えば、上記実施の形態では、ＳＯＣ等の端末は、優先度判定システム１０と有線通信又は無線通信が可能となっており、優先度判定システム１０（出力部１７）が当該端末のディスプレイ２０１等に対して、優先度の判定の結果に基づく出力をする例について説明したが、これに限らない。例えば、判定されたタスク毎の優先度がＳＯＡＲ等の自動化ツールに提供され、判定された優先度に基づいて自動でタスクが処理されてもよい。

また、例えば、優先度判定システム１０が有する機能は、ＳＯＡＲ等の自動化ツールに実装されてもよく、優先度の判定の結果に基づく出力が自動化ツールから行われてもよい。

また、例えば、上記実施の形態では、状況変化通知管理部１６は、特定の種類の異常データに対応する状況の項目を決定し、状況変化通知対象データであると判定した異常データに対応する移動体１００に対して、当該項目についての状況の変化があった場合に、変化後の状況データを通知することを要求する例を説明したが、これに限らない。例えば、状況変化通知管理部１６は、特定の種類の異常データに対応する状況の項目を決定しなくてもよく、状況変化通知対象データであると判定した異常データに対応する移動体１００に対して、任意の項目についての状況の変化があった場合に、変化後の状況データを通知することを要求してもよい。

また、例えば、上記実施の形態では、状況変化通知管理部１６は、特定の種類の異常データが示す異常の対処が行われた場合、状況変化通知対象データであると判定した異常データに対応する移動体１００に対して、変化後の状況データを通知することを停止させる例を説明したが、これに限らない。例えば、状況変化通知管理部１６は、特定の種類の異常データが示す異常の対処が行われた場合であっても、状況変化通知対象データであると判定した異常データに対応する移動体１００に対して、変化後の状況データを通知することを停止させなくてもよい。例えば、移動体１００は、時間経過等によって自動的に状況変化監視中状態を解除してもよい。

また、例えば、移動体１００は、車両に限らず、列車、航空機（例えば無人航空機）又は船舶等であってもよい。

なお、本開示は、優先度判定システム１０として実現できるだけでなく、優先度判定システム１０を構成する各構成要素が行うステップ（処理）を含む優先度判定方法として実現できる。

優先度判定方法は、図４及び図１１に示されるように、それぞれ、複数の移動体のそれぞれの異常を示す複数の異常データを取得し（ステップＳ１１）、それぞれ、複数の移動体のそれぞれの状況を示す複数の状況データを取得し（ステップＳ１２）、複数の異常データのそれぞれについて、対応する移動体の状況データに基づいて、異常のリスク値を算出し（ステップＳ１３）、複数の異常データのそれぞれのリスク値に基づいて、複数の異常データのそれぞれが示す異常に対処するためのタスク毎の優先度を判定し（ステップＳ１４）、判定の結果に基づく出力をし（ステップＳ１５）、複数の異常データのそれぞれについて、対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知させることを要する状況変化通知対象データであるか否かを判定し（ステップＳ１６）、状況変化通知対象データであると判定した異常データに対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知することを要求し（ステップＳ１７）、変化後の状況データが取得された場合、当該変化後の状況データに基づいて、対応する移動体の異常データのリスク値を再算出し（ステップＳ３２）、再算出されたリスク値に基づいて、対応する移動体の異常データが示す異常に対処するためのタスクの優先度を再判定する（ステップＳ３３）処理を含む。

例えば、優先度判定方法におけるステップは、コンピュータ（コンピュータシステム）によって実行されてもよい。そして、本開示は、優先度判定方法に含まれるステップを、コンピュータに実行させるためのプログラムとして実現できる。

さらに、本開示は、そのプログラムを記録したＣＤ－ＲＯＭ等である非一時的なコンピュータ読み取り可能な記録媒体として実現できる。

例えば、本開示が、プログラム（ソフトウェア）で実現される場合には、コンピュータのＣＰＵ、メモリ及び入出力回路等のハードウェア資源を利用してプログラムが実行されることによって、各ステップが実行される。つまり、ＣＰＵがデータをメモリ又は入出力回路等から取得して演算したり、演算結果をメモリ又は入出力回路等に出力したりすることによって、各ステップが実行される。

また、上記実施の形態の優先度判定システム１０に含まれる各構成要素は、専用又は汎用の回路として実現されてもよい。

また、上記実施の形態の優先度判定システム１０に含まれる各構成要素は、集積回路（ＩＣ：Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）であるＬＳＩ（Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ）として実現されてもよい。

また、集積回路はＬＳＩに限られず、専用回路又は汎用プロセッサで実現されてもよい。プログラム可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、又は、ＬＳＩ内部の回路セルの接続及び設定が再構成可能なリコンフィギュラブル・プロセッサが、利用されてもよい。

さらに、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて、優先度判定システム１０に含まれる各構成要素の集積回路化が行われてもよい。

その他、実施の形態に対して当業者が思いつく各種変形を施して得られる形態、本開示の趣旨を逸脱しない範囲で各実施の形態における構成要素及び機能を任意に組み合わせることで実現される形態も本開示に含まれる。

（付記）
以上の実施の形態の記載により、下記の技術が開示される。

（技術１）それぞれ、複数の移動体のそれぞれの異常を示す複数の異常データを取得する異常取得部と、それぞれ、前記複数の移動体のそれぞれの状況を示す複数の状況データを取得する状況取得部と、前記複数の異常データのそれぞれについて、対応する移動体の状況データに基づいて、異常のリスクを示すリスク値を算出するリスク値算出部と、前記複数の異常データのそれぞれの前記リスク値に基づいて、前記複数の異常データのそれぞれが示す異常に対処するためのタスク毎の優先度を判定する優先度判定部と、前記判定の結果に基づく出力をする出力部と、前記複数の異常データのそれぞれについて、対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知させることを要する状況変化通知対象データであるか否かを判定する状況変化通知管理部と、を備え、前記状況変化通知管理部は、前記状況変化通知対象データであると判定した異常データに対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知することを要求し、前記リスク値算出部は、変化後の状況データが取得された場合、当該変化後の状況データに基づいて、対応する移動体の異常データの前記リスク値を再算出し、前記優先度判定部は、再算出された前記リスク値に基づいて、対応する移動体の異常データが示す異常に対処するためのタスクの優先度を再判定する優先度判定システム。

これによれば、複数の異常データのうち、状況変化通知対象データについては、対応する移動体から、状況の変化があった場合に変化後の状況データが通知される。このため、一度移動体の状況データが取得された後、移動体において状況の変化が発生したとしても、その変化後の状況に応じたリスク値が再算出されて、タスクの優先度が再判定される。したがって、移動体の状況の変化に応じて適切にタスクの優先度を判定することができる。

（技術２）前記状況変化通知管理部は、前記複数の異常データのうち特定の種類の異常データを前記状況変化通知対象データであると判定する技術１に記載の優先度判定システム。

例えば、異常の種類によっては、移動体における状況に変化があったとしても、リスク値が変わらないものもある。そこで、状況の変化の監視が必要な異常が発生している移動体にのみ、状況の変化があった場合に変化後の状況データを通知させることで、効率的なシステム運用が可能となる。

（技術３）前記状況変化通知管理部は、前記特定の種類の異常データに対応する状況の項目を決定し、前記状況変化通知対象データであると判定した異常データに対応する移動体に対して、前記項目についての状況の変化があった場合に、変化後の状況データを通知することを要求する技術２に記載の優先度判定システム。

例えば、移動体の状況の項目によっては、変化があったとしてもリスク値が変わらないものもある。そこで、必要な状況の項目の変化のみ移動体に監視させることで、効率的なシステム運用が可能となる。

（技術４）前記状況変化通知管理部は、前記特定の種類の異常データが示す異常の対処が行われた場合、前記状況変化通知対象データであると判定した異常データに対応する移動体に対して、変化後の状況データを通知することを停止させる技術２又は３に記載の優先度判定システム。

これによれば、異常の対処が行われた場合、当該異常が発生した移動体からの変化後の状況の通知は不要となるため、当該通知を停止させることができる。

（技術５）前記複数の状況データのそれぞれは、移動体の種類を示す種類情報、移動体の位置を示す位置情報、前記位置情報に対応する地点の交通情報、移動体の走行状態を示す走行状態情報、移動体の運転支援状態を示す運転支援状態情報、及び、移動体の充放電状態を示す充放電状態情報の少なくとも１つの情報を含む技術１～４のいずれかに記載の優先度判定システム。

これによれば、異常のリスクに影響を与え得る種類情報、位置情報、交通情報、走行状態情報、運転支援状態情報及び充放電状態情報の少なくとも１つの情報をリスク値に反映することができる。

（技術６）前記リスク値は、異常の種類に応じて決定される基礎リスク値を、対応する移動体の状況データを用いて補正した値である技術１～５のいずれかに記載の優先度判定システム。

これによれば、異常の種類に応じて容易に決定できる基礎リスク値を、状況データを用いて補正することで、リスク値を容易に算出することができる。

（技術７）前記タスク毎の優先度は、前記複数の異常データのそれぞれの前記リスク値と、前記タスク毎の所定の指標値とに基づいて判定される技術１～６のいずれかに記載の優先度判定システム。

これによれば、複数の異常データのそれぞれのリスク値と、タスク毎の所定の指標値とに基づいてタスク毎の優先度を容易に判定することができる。

（技術８）前記タスク毎の所定の指標値は、前記タスク毎の実行されることでリスクが軽減される割合及び前記タスク毎の実行に要する時間の少なくとも一方である技術７に記載の優先度判定システム。

これによれば、実行されることでリスクが軽減される割合が大きいタスクの優先度を高くすることができ、また、実行に要する時間が短いタスクの優先度を高くすることができる。

（技術９）前記優先度判定部は、前記判定を、定期的に、タスクが実施される毎に、異常が検知される毎に、又は、前記リスク値が算出される毎に行う技術１～８のいずれかに記載の優先度判定システム。

これによれば、これらのタイミングで、優先度の判定を自動的に行うことができる。

（技術１０）それぞれ、複数の移動体のそれぞれの異常を示す複数の異常データを取得し、それぞれ、前記複数の移動体のそれぞれの状況を示す複数の状況データを取得し、前記複数の異常データのそれぞれについて、対応する移動体の状況データに基づいて、異常のリスクを示すリスク値を算出し、前記複数の異常データのそれぞれの前記リスク値に基づいて、前記複数の異常データのそれぞれが示す異常に対処するためのタスク毎の優先度を判定し、前記判定の結果に基づく出力をし、前記複数の異常データのそれぞれについて、対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知させることを要する状況変化通知対象データであるか否かを判定し、前記状況変化通知対象データであると判定した異常データに対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知することを要求し、変化後の状況データが取得された場合、当該変化後の状況データに基づいて、対応する移動体の異常データの前記リスク値を再算出し、再算出された前記リスク値に基づいて、対応する移動体の異常データが示す異常に対処するためのタスクの優先度を再判定する優先度判定方法。

これによれば、移動体の状況の変化に応じて適切にタスクの優先度を判定することができる優先度判定方法を提供できる。

（技術１１）技術１０に記載の優先度判定方法をコンピュータに実行させるためのプログラム。

これによれば、移動体の状況の変化に応じて適切にタスクの優先度を判定することができるプログラムを提供できる。

本開示は、例えば車両を監視するシステムに適用できる。

１０ 優先度判定システム
１１ 異常取得部
１２ 状況取得部
１３ インシデント管理部
１４ リスク値算出部
１５ 優先度判定部
１６ 状況変化通知管理部
１７ 出力部
１８ 入力部
１００ 移動体
１０１ 異常通知部
１０２ 状況通知部
２０１ ディスプレイ
２０２ キーボード

Claims (11)

1. それぞれ、複数の移動体のそれぞれの異常を示す複数の異常データを取得する異常取得部と、
   それぞれ、前記複数の移動体のそれぞれの状況を示す複数の状況データを取得する状況取得部と、
   前記複数の異常データのそれぞれについて、対応する移動体の状況データに基づいて、異常のリスクを示すリスク値を算出するリスク値算出部と、
   前記複数の異常データのそれぞれの前記リスク値に基づいて、前記複数の異常データのそれぞれが示す異常に対処するためのタスク毎の優先度を判定する優先度判定部と、
   前記判定の結果に基づく出力をする出力部と、
   前記複数の異常データのそれぞれについて、対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知させることを要する状況変化通知対象データであるか否かを判定する状況変化通知管理部と、を備え、
   前記状況変化通知管理部は、前記状況変化通知対象データであると判定した異常データに対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知することを要求し、
   前記リスク値算出部は、変化後の状況データが取得された場合、当該変化後の状況データに基づいて、対応する移動体の異常データの前記リスク値を再算出し、
   前記優先度判定部は、再算出された前記リスク値に基づいて、対応する移動体の異常データが示す異常に対処するためのタスクの優先度を再判定する
   優先度判定システム。
2. 前記状況変化通知管理部は、前記複数の異常データのうち特定の種類の異常データを前記状況変化通知対象データであると判定する
   請求項１に記載の優先度判定システム。
3. 前記状況変化通知管理部は、前記特定の種類の異常データに対応する状況の項目を決定し、前記状況変化通知対象データであると判定した異常データに対応する移動体に対して、前記項目についての状況の変化があった場合に、変化後の状況データを通知することを要求する
   請求項２に記載の優先度判定システム。
4. 前記状況変化通知管理部は、前記特定の種類の異常データが示す異常の対処が行われた場合、前記状況変化通知対象データであると判定した異常データに対応する移動体に対して、変化後の状況データを通知することを停止させる
   請求項２又は３に記載の優先度判定システム。
5. 前記複数の状況データのそれぞれは、移動体の種類を示す種類情報、移動体の位置を示す位置情報、前記位置情報に対応する地点の交通情報、移動体の走行状態を示す走行状態情報、移動体の運転支援状態を示す運転支援状態情報、及び、移動体の充放電状態を示す充放電状態情報の少なくとも１つの情報を含む
   請求項１～３のいずれか１項に記載の優先度判定システム。
6. 前記リスク値は、異常の種類に応じて決定される基礎リスク値を、対応する移動体の状況データを用いて補正した値である
   請求項１～３のいずれか１項に記載の優先度判定システム。
7. 前記タスク毎の優先度は、前記複数の異常データのそれぞれの前記リスク値と、前記タスク毎の所定の指標値とに基づいて判定される
   請求項１～３のいずれか１項に記載の優先度判定システム。
8. 前記タスク毎の所定の指標値は、前記タスク毎の実行されることでリスクが軽減される割合及び前記タスク毎の実行に要する時間の少なくとも一方である
   請求項７に記載の優先度判定システム。
9. 前記優先度判定部は、前記判定を、定期的に、タスクが実施される毎に、異常が検知される毎に、又は、前記リスク値が算出される毎に行う
   請求項１～３のいずれか１項に記載の優先度判定システム。
10. それぞれ、複数の移動体のそれぞれの異常を示す複数の異常データを取得し、
    それぞれ、前記複数の移動体のそれぞれの状況を示す複数の状況データを取得し、
    前記複数の異常データのそれぞれについて、対応する移動体の状況データに基づいて、異常のリスクを示すリスク値を算出し、
    前記複数の異常データのそれぞれの前記リスク値に基づいて、前記複数の異常データのそれぞれが示す異常に対処するためのタスク毎の優先度を判定し、
    前記判定の結果に基づく出力をし、
    前記複数の異常データのそれぞれについて、対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知させることを要する状況変化通知対象データであるか否かを判定し、
    前記状況変化通知対象データであると判定した異常データに対応する移動体に対して、状況の変化があった場合に変化後の状況データを通知することを要求し、
    変化後の状況データが取得された場合、当該変化後の状況データに基づいて、対応する移動体の異常データの前記リスク値を再算出し、
    再算出された前記リスク値に基づいて、対応する移動体の異常データが示す異常に対処するためのタスクの優先度を再判定する
    優先度判定方法。
11. 請求項１０に記載の優先度判定方法をコンピュータに実行させるためのプログラム。

Images