JP7552543B2 - 情報処理システム、情報処理方法、プログラム - Google Patents

Description

本開示は、情報処理システム等に関する。

例えば、外部装置から車両で利用されるソフトウェアの更新データ（例えば、プログラムやプログラムで使用されるパラメータ等の更新データ）を車両に送信し、ソフトウェアの更新を実施させる技術が知られている（特許文献１参照）。

特許文献１では、評価シミュレータを用いて、ソフトウェアの更新前及び更新後の車両の動作評価が行われ、ソフトウェアの更新によって、車両の機能が望ましい方向に修正されることを確認した後に、ソフトウェアの更新が行われる。

特開２００３－ ３４２００号公報

しかしながら、更新データの適用対象の車両ごとに、その特性や使用条件等が異なる場合がある。そのため、車両の特性や使用条件等よっては、実際のソフトウェアの更新によって得られる効果が相対的に小さい可能性があり、その結果、それほど効果が得られないにもかかわらず、ソフトウェアの無駄な更新が実施される可能性がある。

そこで、上記課題に鑑み、車両で利用されるソフトウェアの更新をより適切に実施させることが可能な技術を提供することを目的とする。

上記目的を達成するため、本開示の一実施形態では、
車両の所定の性能に関するデータを含む前記車両に関するデータを取得する取得部と、
前記取得部により取得されるデータに基づき、前記車両に相当する仮想モデルを生成する生成部と、
前記取得部により取得されるデータに基づき、前記仮想モデルを用いて、仮想シミュレーションを行うことにより、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測部と、
前記予測部により予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測部により予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信部と、を備え、
前記予測部は、前記更新データに基づく前記ソフトウェアの更新の内容に応じて、前記効果の予測の際の前記仮想シミュレーションの実施の有無を判断する、
情報処理システムが提供される。

また、本開示の他の実施形態は、
車両の所定の性能に関するデータを含む前記車両に関するデータを取得する取得部と、
前記取得部により取得されるデータに基づき、前記車両に相当する仮想モデルを生成する生成部と、
前記取得部により取得されるデータに基づき、前記仮想モデルを用いて、仮想シミュレーションを行うことにより、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測部と、
前記予測部により予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測部により予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信部と、を備え、
前記取得部は、時間経過に応じて、前記車両の状態に関するデータを繰り返し取得し、
前記生成部は、前記取得部による前記車両の状態に関するデータの取得に合わせて、前記仮想モデルの生成及び更新を行う、
情報処理システムが提供される。
また、本開示の更に他の実施形態では、
車両の所定の性能に関するデータを含む前記車両に関するデータを取得する取得部と、
前記取得部により取得されるデータに基づき、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測部と、
前記予測部により予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測部により予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信部と、を備え、
前記予測部は、ユーザが前記車両を今後利用する期間を考慮して、前記効果を予測する、
情報処理システムが提供される。

また、本開示の更に他の実施形態では、
情報処理装置が実行する情報処理方法であって、
車両の所定の性能に関するデータを含む前記車両に関するデータを取得する取得ステップと、
前記取得ステップで取得されるデータに基づき、前記車両に相当する仮想モデルを生成する生成ステップと、
前記取得ステップで取得されるデータに基づき、前記仮想モデルを用いて、仮想シミュレーションを行うことにより、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測ステップと、
前記予測ステップで予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測ステップで予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信ステップと、を含み、
前記予測ステップでは、前記更新データに基づく前記ソフトウェアの更新の内容に応じて、前記効果の予測の際の前記仮想シミュレーションの実施の有無を判断する、
情報処理方法が提供される。
また、本開示の更に他の実施形態では、
情報処理装置が実行する情報処理方法であって、
車両の所定の性能に関するデータを含む前記車両に関するデータを取得する取得ステップと、
前記取得ステップで取得されるデータに基づき、前記車両に相当する仮想モデルを生成する生成ステップと、
前記取得ステップで取得されるデータに基づき、前記仮想モデルを用いて、仮想シミュレーションを行うことにより、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測ステップと、
前記予測ステップで予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測ステップで予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信ステップと、を含み、
前記取得ステップでは、時間経過に応じて、前記車両の状態に関するデータを繰り返し取得し、
前記生成ステップでは、前記取得ステップでの前記車両の状態に関するデータの取得に合わせて、前記仮想モデルの生成及び更新を行う、
情報処理方法が提供される。
また、本開示の更に他の実施形態では、
情報処理装置が実行する情報処理方法であって、
車両の所定の性能に関するデータを含む前記車両に関するデータを取得する取得ステップと、
前記取得ステップで取得されるデータに基づき、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測ステップと、
前記予測ステップで予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測ステップで予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信ステップと、を含み、
前記予測ステップでは、ユーザが前記車両を今後利用する期間を考慮して、前記効果を予測する、
情報処理方法が提供される。

また、本開示の更に他の実施形態では、
情報処理装置に、
車両の所定の性能に関するデータを含む前記車両の状態に関するデータを取得する取得ステップと、
前記取得ステップで取得されるデータに基づき、前記車両に相当する仮想モデルを生成する生成ステップと、
前記取得ステップで取得されるデータに基づき、前記仮想モデルを用いて、仮想シミュレーションを行うことにより、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測ステップと、
前記予測ステップで予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測ステップで予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信ステップと、を実行させ、
前記予測ステップでは、前記更新データに基づく前記ソフトウェアの更新の内容に応じて、前記効果の予測の際の前記仮想シミュレーションの実施の有無を判断する、
プログラムが提供される。

また、本開示の更に他の実施形態では、
情報処理装置に、
車両の所定の性能に関するデータを含む前記車両の状態に関するデータを取得する取得ステップと、
前記取得ステップで取得されるデータに基づき、前記車両に相当する仮想モデルを生成する生成ステップと、
前記取得ステップで取得されるデータに基づき、前記仮想モデルを用いて、仮想シミュレーションを行うことにより、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測ステップと、
前記予測ステップで予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測ステップで予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信ステップと、を実行させ、
前記取得ステップでは、時間経過に応じて、前記車両の状態に関するデータを繰り返し取得し、
前記生成ステップでは、前記取得ステップでの前記車両の状態に関するデータの取得に合わせて、前記仮想モデルの生成及び更新を行う、
プログラムが提供される。
また、本開示の更に他の実施形態では、
情報処理装置に、
車両の所定の性能に関するデータを含む前記車両の状態に関するデータを取得する取得ステップと、
前記取得ステップで取得されるデータに基づき、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測ステップと、
前記予測ステップで予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測ステップで予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信ステップと、を実行させ、
前記予測ステップでは、ユーザが前記車両を今後利用する期間を考慮して、前記効果を予測する、
プログラムが提供される。

上述の実施形態によれば、車両で利用されるソフトウェアの更新をより適切に実施させることができる。

ソフトウェア更新システムの一例を示す概要図である。 車両のハードウェア構成の一例を示す図である。 配信サーバのハードウェア構成の一例を示す図である。 ソフトウェア更新システムの機能構成の一例を示す機能ブロック図である。 車両の変速機の変速マップの更新の一例を示す図である。 車両の原動機の切替マップの更新の一例を示す図である。 車両の変速機のシフトチェンジ（シフトアップ）に関する制御ロジックの更新前及び更新後のそれぞれについて、変速機のシフトチェンジ時における車両の状態の経時変化の仮想シミュレーションの結果の一例を示す図である。 車両の変速機のシフトチェンジ（シフトアップ）に関する制御ロジックの更新前及び更新後のそれぞれについて、変速機のシフトチェンジ時における車両の状態の経時変化の仮想シミュレーションの結果の他の例を示す図である。 配信サーバによる車両のソフトウェアの更新に関する処理の一例を概略的に示すフローチャートである。 解析サーバによる車両のソフトウェアの更新に関する処理の一例を概略的に示すフローチャートである。 セントラルＥＣＵによる車両のソフトウェアの更新に関する処理の一例を概略的に示すフローチャートである。

以下、図面を参照して実施形態について説明する。

［ソフトウェア更新システムの概要］
図１を参照して、本実施形態に係るソフトウェア更新システム１の概要について説明する。

図１は、ソフトウェア更新システム１の一例を示す概要図である。

図１に示すように、ソフトウェア更新システム１（情報処理システムの一例）は、車両１０と、配信サーバ２０と、解析サーバ３０と、ユーザ端末４０とを含む。

ソフトウェア更新システム１は、車両１０で利用されるソフトウェアの更新データを車両１０に配信し、車両１０のソフトウェアを更新させる。

車両１０のソフトウェアには、例えば、後述のゲートウェイＥＣＵ（Electronic Control Unit）１２やＥＣＵ１３やセントラルＥＣＵ１９等の車両１０に搭載されるコンピュータ（車載コンピュータ）で実行されるプログラムが含まれる。また、車両１０のソフトウェアには、例えば、車載コンピュータで実行されるプログラムによる処理で利用されるパラメータ等の各種データが含まれる。

車両１０は、ソフトウェアの更新対象であり、例えば、エンジンや電動機等の所定の原動機から、変速機、ディファレンシャル、及びドライブシャフト等の駆動系を介して駆動輪に伝達される動力で走行する。

車両１０は、後述の如く、通信装置１１を搭載し、所定の通信回線を通じて、例えば、配信サーバ２０や解析サーバ３０等の外部装置と通信可能に接続される。これにより、車両１０は、配信サーバ２０や解析サーバ３０に情報信号を送信したり、配信サーバ２０や解析サーバ３０から制御信号や情報信号（例えば、ソフトウェアの更新データ）を受信したりすることができる。

所定の通信回線は、例えば、基地局を末端とする移動体通信網、通信衛星を利用する衛星通信網、インターネット網等の広域ネットワーク（ＷＡＮ：Wide Area Network）を含む。また、所定の通信回線は、例えば、配信サーバ２０や解析サーバ３０が設置される施設のローカルネットワーク（ＬＡＮ：Local Area Network）を含んでもよい。また、所定の通信回線は、例えば、ＷｉＦｉやブルートゥース（登録商標）等の無線通信規格に基づく近距離通信回線を含んでもよい。以下、配信サーバ２０と解析サーバ３０との間の通信で利用される通信回線、及び配信サーバ２０とユーザ端末４０との間の通信で利用される通信回線等についても同様であってよい。

尚、ソフトウェア更新システム１に含まれる車両１０は、一台であってもよいし、複数台であってもよい。後者の場合、ソフトウェア更新システム１に含まれる複数の車両１０は、例えば、全て同じ車種であってもよいし、２以上の車種の車両１０を含んでいてもよい。

配信サーバ２０は、車両１０で利用される各種データを車両１０に配信する。具体的には、配信サーバ２０は、車両１０にソフトウェアの更新データを配信する。

配信サーバ２０は、例えば、複数の車両１０の状態等の監視を集中的に行う監視センタ等に設置されるオンプレミスサーバやクラウドサーバである。また、配信サーバ２０は、例えば、車両１０が主に走行する地域（例えば、法規上、車両１０が登録されている地域）に設置されるエッジサーバであってもよい。この場合、配信サーバ２０は、ソフトウェア更新システム１に含まれる全ての車両１０に対して、複数設けられてもよい。以下、解析サーバ３０についても同様であってよい。

配信サーバ２０は、上述の如く、所定の通信回線を通じて、車両１０と通信可能に接続される。これにより、配信サーバ２０は、車両１０から各種の情報信号を受信したり、車両１０に各種の情報信号（例えば、ソフトウェアの更新データ）や制御信号（例えば、ソフトウェアの更新の指令）等を送信したりすることができる。

解析サーバ３０は、例えば、車両１０や車両１０に関連する外部装置から車両１０の状態を表す各種データ（以下、「車両データ」）を取得し、車両１０に関する解析を行う。具体的には、解析サーバ３０は、車両１０のソフトウェアの更新によって得られる所定の性能に関する効果の解析を行う。取得対象の車両データには、ソフトウェアの更新によって向上すると予測される所定の性能に関するデータが含まれる。車両１０に関連する外部装置は、例えば、車両１０の製造時のデータを格納する工場等のサーバ装置を含む。車両１０の製造時のデータには、例えば、車両１０の部品ごとの製造時のばらつきに関するデータや車両１０の部品の組み付け時のばらつきに関するデータ等の車両１０の製造時のばらつきに関するデータが含まれる。

解析サーバ３０は、上述の如く、所定の通信回線を通じて、車両１０と通信可能に接続される。これにより、解析サーバ３０は、車両１０から各種の情報信号（例えば、車両データ）を受信したり、車両１０に各種の情報信号や制御信号を送信したりすることができる。

また、解析サーバ３０は、所定の通信回線を通じて、配信サーバ２０やユーザ端末４０と通信可能に接続される。これにより、解析サーバ３０は、配信サーバ２０やユーザ端末４０に各種の情報信号や制御信号を送信したり、配信サーバ２０やユーザ端末４０から各種の情報信号や制御信号を受信したりすることができる。

尚、配信サーバ２０及び解析サーバ３０の機能は、１つのサーバ、例えば、配信サーバ２０（情報処理装置の一例）に集約して実現されたり、３つ以上のサーバにより分散して実現されたりしてもよい。

ユーザ端末４０は、車両１０のユーザが利用（所持）する端末装置である。車両１０のユーザは、例えば、車両１０の所有者や車両１０の所有者の家族等である。ユーザ端末４０は、例えば、スマートフォン、タブレット端末、ラップトップ型のＰＣ（Personal Computer）等の携帯型（可搬型）の端末装置である。また、ユーザ端末４０は、例えば、デスクトップ型のＰＣ等の定置型の端末装置であってもよい。

ユーザ端末４０は、上述の如く、所定の通信回線を通じて、配信サーバ２０と通信可能に接続される。これにより、ユーザ端末４０は、配信サーバ２０から送信される制御信号や情報信号を受信し、信号に含まれる情報をディスプレイやスピーカ等を通じて車両１０のユーザに把握させることができる。また、ユーザ端末４０は、ユーザからの入力に応じて、その入力内容に応じた制御信号や情報信号を配信サーバに送信し、ユーザからの入力内容に対応するユーザの要求を配信サーバ２０に伝えることができる。

［ソフトウェア更新システムのハードウェア構成］
次に、図１に加え、図２、図３を参照して、ソフトウェア更新システム１のハードウェア構成について説明する。

＜車両のハードウェア構成＞
図２は、車両１０のハードウェア構成の一例を示す図である。

図２に示すように、車両１０は、通信装置１１と、ゲートウェイＥＣＵ１２と、ＥＣＵ１３と、センサ１５と、入力装置１７と、表示装置１８と、セントラルＥＣＵ１９と、を含む。

通信装置１１は、所定の通信回線を通じて、車両１０の外部と通信を行う。通信装置１１は、例えば、基地局を末端とする移動体通信網に接続し、外部と通信を行うことが可能な移動体通信モジュールであり、具体的には、ＤＣＭ（Data Communication Module）であってよい。通信装置１１は、車両１０の内部の通信回線を通じて、ゲートウェイＥＣＵ１２やＥＣＵ１３やセントラルＥＣＵ１９等と通信可能に接続される。車両１０の内部の通信回線は、例えば、一対一の通信線や車載ネットワークである。車載ネットワークは、例えば、ＣＡＮ（Controller Area Network）、ＬＩＮ（Local Interconnect Network）、ＦｌｅｘＲａｙ、車載イーサネット（Ethernet）等である。通信装置１１は、例えば、ゲートウェイＥＣＵ１２から指令（要求）に応じて、所定の信号を外部に送信してよい。また、通信装置１１により外部から受信される信号は、ゲートウェイＥＣＵ１２に取り込まれる。

ゲートウェイＥＣＵ１２は、車両１０の外部の通信回線と、車両１０の内部の通信回線（例えば、車載ネットワーク）との間のゲートウェイとして機能する。

ゲートウェイＥＣＵ１２は、その機能が任意のハードウェア或いは任意のハードウェア及びソフトウェアの組み合わせ等により実現されてよい。例えば、ゲートウェイＥＣＵ１２は、後述のセントラルＥＣＵ１９と同様のハードウェア構成を有し、補助記憶装置にインストールされるプログラムをメモリ装置にロードしＣＰＵ（Central Processing Unit）上で実行することにより、各種機能を実現してよい。以下、ＥＣＵ１３についても同様であってよい。

例えば、ゲートウェイＥＣＵ１２は、既知の方法を用いて、通信装置１１により外部から受信された信号が正規の送信元からの送信された信号であり、且つ、改ざんがされていない信号であることの認証を行う。正規の送信元とは、予め送信元として登録されている送信元（例えば、配信サーバ２０、解析サーバ３０等）や相互通信により予め認証が得られている送信元等を意味する。ゲートウェイＥＣＵ１２は、通信装置１１により受信される信号のうち、認証が成功した信号のデータのみを車両１０の内部の通信回線を通じて、所定の車載機器（例えば、ＥＣＵ１３やセントラルＥＣＵ１９等）に送信する。

また、例えば、ゲートウェイＥＣＵ１２は、車両１０の各種機器からの要求に応じて、所定の情報や指令（要求）等の内容を含む信号を生成し、通信装置１１を通じて、所定の送信先（例えば、配信サーバ２０や解析サーバ３０）に送信する。

ＥＣＵ１３は、車両１０に一又は複数搭載される。ＥＣＵ１３は、車両１０の各種機能に関する制御を行う。例えば、複数のＥＣＵ１３の中には、車両１０の動力源としてのエンジンを制御するＥＣＵ１３、車両１０の動力源としての電動機（ＭＧ：Motor Generator）を制御するＥＣＵ１３、車両１０の変速機のシフトポジションを制御するＥＣＵ１３等が含まれる。

センサ１５は、車両１０に一又は複数搭載される。センサ１５は、車両１０の状態に関する計測データを出力する。センサ１５の出力（計測データ）は、車両１０の内部の通信回線を通じて、セントラルＥＣＵ１９に取り込まれる。例えば、複数のセンサ１５の中には、車両１０の各車輪の車輪速を計測するセンサ１５（車輪速センサ）が含まれる。また、例えば、複数のセンサ１５の中には、車両１０の前後方向や左右方向や上下方向の加速度を計測するセンサ１５（加速度センサ）が含まれる。また、例えば、複数のセンサ１５の中には、車両１０の所定部位の温度を計測するセンサ１５（温度センサ）が含まれる。温度センサには、例えば、車両１０に搭載される駆動用のバッテリや補機用のバッテリの温度を測定する温度センサや各種機器の冷却水の温度を測定する水温センサや各種機器の潤滑油の油温を測定する油温センサ等が含まれる。また、例えば、複数のセンサ１５の中には、車両１０の位置を計測するセンサ１５（ＧＮＳＳ（Global Navigation Satellite System）センサ）を含む。

入力装置１７は、車両１０の室内に設けられ、搭乗者からの各種入力を受け付ける。入力装置１７は、例えば、ボタン、トグル、レバー、タッチパネル、タッチパッド等の搭乗者からの操作入力を受け付ける操作入力装置を含む。また、入力装置１７は、例えば、マイクロフォン等、車両１０の搭乗者の音声入力を受け付ける音声入力装置を含む。また、入力装置１７は、例えば、車両１０の室内の搭乗者の様子を撮像可能なカメラ等、車両１０の搭乗者のジェスチャ入力を受け付けるジェスチャ入力装置を含む。入力装置１７で受け付けられる入力の内容を表す入力信号は、車両１０の内部の通信回線を通じて、セントラルＥＣＵ１９に取り込まれる。

表示装置１８は、車両１０の室内の運転席から視認し易い場所に設けられ、各種情報画面を表示する。表示装置１８は、例えば、液晶ディスプレイや有機ＥＬ（Electroluminescence）ディスプレイ等である。表示装置１８は、車両１０の内部の通信回線を通じて、セントラルＥＣＵ１９と通信可能に接続され、セントラルＥＣＵ１９は、表示装置１８に制御信号を出力し、表示装置１８に所定の情報画面を表示させることができる。

セントラルＥＣＵ１９は、例えば、車両１０に搭載されるゲートウェイＥＣＵ１２及びＥＣＵ１３を含む各種ＥＣＵの上位の制御装置として、各種ＥＣＵの動作を統括制御したり、各種ＥＣＵで利用される各種データの登録先として機能したりする。

セントラルＥＣＵ１９の機能は、任意のハードウェア或いは任意のハードウェア及びソフトウェアの組み合わせ等により実現される。例えば、図２に示すように、セントラルＥＣＵ１９は、バスＢ１で接続される、補助記憶装置１９Ａ、メモリ装置１９Ｂ、ＣＰＵ１９Ｃ、及びインタフェース装置１９Ｄを含む。

補助記憶装置１９Ａは、不揮発性の記憶手段であり、インストールされるプログラムを格納すると共に、必要なファイルやデータ等を格納する。補助記憶装置１９Ａは、例えば、フラッシュメモリ等である。

メモリ装置１９Ｂは、例えば、プログラムの起動指示があった場合に、補助記憶装置１９ＡのプログラムをＣＰＵ１９Ｃが読み込み可能なようにロードする。メモリ装置１９Ｂは、例えば、ＳＲＡＭ（Static Random Access Memory）である。

ＣＰＵ１９Ｃは、例えば、メモリ装置１９Ｂにロードされるプログラムを実行し、プログラムの命令に従って、セントラルＥＣＵ１９の各種機能を実現する。

インタフェース装置１９Ｄは、例えば、車両１０の内部の通信回線に接続するためのインタフェースとして用いられる。インタフェース装置１９Ｄは、接続する通信回線の種類に合わせて、複数の異なる種類のインタフェース装置を含んでよい。

セントラルＥＣＵ１９の各種機能を実現するプログラムは、例えば、可搬型の記録媒体１９Ｅによって提供される。この場合、インタフェース装置１９Ｄは、記録媒体１９Ｅからのデータの読み取りや記録媒体１９Ｅへのデータの書き込みのためのインタフェースとして機能する。記録媒体１９Ｅは、例えば、ＤＬＣ（Data Link Coupler）等の外部接続用のコネクタに着脱可能なケーブルで接続される専用ツールである。また、記録媒体１９Ｅは、例えば、ＳＤメモリカードやＵＳＢ（Universal Serial Bus）メモリ等であってもよい。また、プログラムは、所定の通信回線を通じて、車両１０の外部の他のコンピュータ（例えば、配信サーバ２０）からダウンロードされ、補助記憶装置１９Ａにインストールされてもよい。

＜配信サーバのハードウェア構成＞
図３は、配信サーバ２０のハードウェア構成の一例を示す図である。

配信サーバ２０の機能は、任意のハードウェア或いは任意のハードウェア及びソフトウェアの組み合わせ等により実現される。例えば、図２に示すように、配信サーバ２０は、バスＢ２で接続される、外部インタフェース２１、補助記憶装置２２、メモリ装置２３、ＣＰＵ２４、通信インタフェース２６、入力装置２７、及び表示装置２８を含む。

尚、解析サーバ３０やユーザ端末４０についても配信サーバ２０と同様のハードウェア構成を有してよい。以下、解析サーバ３０やユーザ端末４０のハードウェア構成の図示や説明を省略する。

外部インタフェース２１は、記録媒体２１Ａからデータの読み取りや記録媒体２１Ａへのデータの書き込みのためのインタフェースとして機能する。記録媒体２１Ａには、例えば、フレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu-ray（登録商標） Disc）、ＳＤメモリカード、ＵＳＢ（Universal Serial Bus）メモリ等が含まれる。これにより、配信サーバ２０は、記録媒体２１Ａを通じて、処理で利用する各種データを読み込み、補助記憶装置２２に格納したり、各種機能を実現するプログラムをインストールしたりすることができる。

尚、配信サーバ２０は、通信インタフェース２６を通じて、外部装置から各種データやプログラムを取得してもよい。

補助記憶装置２２は、インストールされた各種プログラムを格納すると共に、各種処理に必要なファイルやデータ等を格納する。補助記憶装置２２は、例えば、ＨＤＤ（Hard Disc Drive）やＳＳＤ（Solid State Drive）やフラッシュメモリ等を含む。

メモリ装置２３は、プログラムの起動指示があった場合に、補助記憶装置２２からプログラムを読み出して格納する。メモリ装置２３は、例えば、ＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）を含む。

ＣＰＵ２４は、補助記憶装置２２からメモリ装置２３にロードされた各種プログラムを実行し、プログラムに従って配信サーバ２０に関する各種機能を実現する。

高速演算装置２５は、ＣＰＵ２４と連動し、相対的に高い速度で演算処理を行う。高速演算装置２５は、例えば、ＧＰＵ（Graphics Processing Unit）やＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field-Programmable Gate Array）等を含む。

尚、高速演算装置２５は、必要な演算処理の速度によっては、省略されてもよい。

通信インタフェース２６は、外部機器と通信可能に接続するためのインタフェースとして用いられる。これにより、配信サーバ２０は、通信インタフェース２６を通じて、例えば、車両１０や解析サーバ３０やユーザ端末４０等の外部機器と通信することができる。また、通信インタフェース２６は、接続される機器との間の通信方式等によって、複数の種類の通信インタフェースを有してよい。

入力装置２７は、ユーザから各種入力を受け付ける。

入力装置２７は、例えば、ユーザからの機械的な操作入力を受け付ける操作入力装置を含む。操作入力装置は、例えば、ボタン、トグル、レバー、マウス、キーボード等を含む。また、操作入力装置は、例えば、表示装置２８に実装されるタッチパネル、表示装置２８とは別に設けられるタッチパッド等を含む。

また、入力装置２７は、例えば、ユーザからの音声入力を受付可能な音声入力装置を含む。音声入力装置は、例えば、ユーザの音声を集音可能なマイクロフォンを含む。

また、入力装置２７は、例えば、ユーザからのジェスチャ入力を受付可能なジェスチャ入力装置を含む。ジェスチャ入力装置は、例えば、ユーザのジェスチャの様子を撮像可能なカメラを含む。

また、入力装置２７は、例えば、ユーザからの生体入力を受付可能な生体入力装置を含む。生体入力装置は、例えば、ユーザの指紋や虹彩に関する情報を内包する画像データを取得可能なカメラを含む。

表示装置２８は、ユーザに向けて、情報画面や操作画面を表示する。表示装置２８は、例えば、液晶ディスプレイや有機ＥＬ（Electroluminescence）ディスプレイ等を含む。

［ソフトウェア更新システムの機能構成］
次に、図１～図３に加えて、図４を参照して、ソフトウェア更新システム１の機能構成について説明する。

図４は、ソフトウェア更新システム１の機能構成の一例を示す機能ブロック図である。

＜車両の機能構成＞
図４に示すように、ゲートウェイＥＣＵ１２は、機能部として、通信部１２１と、記憶部１２２とを含む。通信部１２１の機能は、例えば、ゲートウェイＥＣＵ１２の補助記憶装置にインストールされるプログラムをメモリ装置にロードしＣＰＵ上で実行することにより実現されてよい。また、記憶部１２２の機能は、例えば、ゲートウェイＥＣＵ１２の補助記憶装置等に規定される記憶領域により実現されてよい。

通信部１２１は、通信装置１１を制御し、車両１０の外部から受信される信号をゲートウェイＥＣＵ１２に取り込んだり、車両１０の外部に信号を送信させたりする。

記憶部１２２には、ゲートウェイＥＣＵ１２で利用される各種データが記憶される。記憶部１２２には、例えば、ゲートウェイＥＣＵ１２（補助記憶装置）にインストールされた各種プログラムのデータが登録（記憶）される。また、記憶部１２２には、例えば、ゲートウェイＥＣＵ１２の各種プログラムによる処理で参照されるパラメータのデータ等が登録（記憶）される。

ＥＣＵ１３は、機能部として、記憶部１３１を含む。記憶部１３１の機能は、例えば、ＥＣＵ１３の補助記憶装置に規定される記憶領域により実現される。

記憶部１３１には、ＥＣＵ１３で利用される各種データが記憶される。記憶部１３１には、例えば、ＥＣＵ１３（補助記憶装置）にインストールされた各種プログラムのデータが登録（記憶）される。また、記憶部１３１には、例えば、ＥＣＵ１３の各種プログラムによる処理で参照されるパラメータのデータ等が登録（記憶）される。

セントラルＥＣＵ１９は、機能部として、車両データ取得部１９１と、ダウンロード処理部１９２と、記憶部１９３と、ソフトウェア更新部１９４と、記憶部１９５とを含む。車両データ取得部１９１、ダウンロード処理部１９２、及びソフトウェア更新部１９４の機能は、例えば、補助記憶装置１９Ａにインストールされるプログラムをメモリ装置１９ＢにロードしＣＰＵ１９Ｃ上で実行することにより実現されてよい。記憶部１９３，１９５の機能は、例えば、補助記憶装置１９Ａに規定される記憶領域により実現されてよい。

車両データ取得部１９１は、車両１０の状態を表す車両データを取得し、解析サーバ３０に送信する。

車両データ取得部１９１は、例えば、所定周期ごとに、車両１０の状態を表す車両データを取得し、ゲートウェイＥＣＵ１２（通信装置１１）を通じて、解析サーバ３０に送信（アップロード）する。車両データ取得部１９１は、例えば、取得した車両データをリアルタイムに解析サーバ３０にアップロードしてもよいし、取得した車両データをメモリ装置１９Ｂや補助記憶装置１９Ａに蓄積し、所定のタイミングで蓄積された車両データをまとめて解析サーバ３０に送信してもよい。

また、車両データ取得部１９１は、例えば、ゲートウェイＥＣＵ１２（通信装置１１）を通じて受信される、解析サーバ３０からの要求に応じて、最新の車両データを取得し、ゲートウェイＥＣＵ１２（通信装置１１）を通じて、解析サーバ３０に送信する。

送信対象の車両データは、例えば、センサ１５から出力される計測データを含む。また、送信対象の車両データは、例えば、ゲートウェイＥＣＵ１２、ＥＣＵ１３、及びセントラルＥＣＵ１９等の各種ＥＣＵから出力される指令値や制御処理の過程での演算結果の値等の制御データを含む。

ダウンロード処理部１９２は、配信サーバ２０からのソフトウェアの更新データのダウンロードに関する処理を行う。

記憶部１９３は、配信サーバ２０からダウンロードされたソフトウェアの更新データを記憶する。

ソフトウェア更新部１９４は、記憶部１９３にダウンロード済のソフトウェアの更新データを用いて、ゲートウェイＥＣＵ１２やＥＣＵ１３やセントラルＥＣＵ１９等で利用されるソフトウェアの更新を行う。

記憶部１９５には、セントラルＥＣＵ１９で利用される各種データが記憶される。記憶部１９５には、例えば、セントラルＥＣＵ１９（補助記憶装置）にインストールされた各種プログラムのデータが登録（記憶）される。また、記憶部１９５には、例えば、セントラルＥＣＵ１９の各種プログラムによる処理で参照されるパラメータのデータ等が登録（記憶）される。

＜配信サーバの機能構成＞
図４に示すように、配信サーバ２０は、機能部として、通知部２０１と、配信部２０２とを含む。通知部２０１及び配信部２０２の機能は、例えば、補助記憶装置２２にインストールされるプログラムをメモリ装置２３にロードしＣＰＵ２４上で実行することにより実現される。

通知部２０１は、車両１０で利用されるソフトウェアの更新データがある場合に、その車両１０のユーザにソフトウェアの更新データの存在を通知する。ソフトウェア更新システム１に複数の車両１０が含まれる場合、複数の車両１０のうちの更新データによるソフトウェアの更新の対象の車両１０のユーザだけにソフトウェアの更新データの存在を通知する。例えば、複数の車両１０の中に２以上の車種の車両１０が含まれる場合、車種ごとに、ソフトウェアの更新の有無や更新の内容が異なりうるからである。また、例えば、複数の車両１０が全て同じ車種であっても、グレードによって、ソフトウェアの更新の有無や更新の内容に差異が生じうるからである。また、例えば、車両１０のソフトウェアの更新に関するユーザとサービス提供者との間の契約内容によって、ユーザが受けることのできるサービス、即ち、対価（料金）に応じてユーザに提供されるサービスが異なり、ソフトウェアの更新の内容に差異が生じうるからである。

具体的には、通知部２０１は、更新データの配信対象の車両１０について、ソフトウェアの更新による効果の予測を依頼する信号を解析サーバ３０に送信する。この際、通知部２０１は、更新データの配信対象の車両１０が複数存在するのであれば、複数の車両１０ごとのソフトウェアの更新による効果の予測を解析サーバ３０に依頼する。通知部２０１は、解析サーバ３０からソフトウェアの更新による効果の予測結果のデータが受信されると、対象の車両１０のソフトウェアの更新による効果が、ユーザが実感できると判断可能な所定の基準を満足するか否かを判定する。そして、通知部２０１は、対象の車両１０のソフトウェアの更新による効果が所定の基準を満足する場合、ソフトウェアの更新データの存在を通知する信号をその車両１０に送信する。これにより、車両１０のセントラルＥＣＵ１９（ダウンロード処理部１９２）は、表示装置１８を通じて、ソフトウェアの更新データの存在をユーザに通知することができる。また、この場合、通知部２０１は、車両１０に代えて、或いは、加えて、車両１０のユーザのユーザ端末４０にソフトウェアの更新データの存在を通知する信号を送信してもよい。これにより、ユーザ端末４０（通知部４０１）は、表示装置を通じて、ソフトウェアの更新データの存在を車両１０のユーザに通知することができる。また、この場合、通知部２０１は、ソフトウェアの更新のためにユーザによる対価（料金）の支払いが必要なときに、ソフトウェアの更新のために必要な対価の額を含む、ソフトウェアの更新データの存在を通知する信号を車両１０やユーザ端末４０に送信してもよい。これにより、車両１０のセントラルＥＣＵ１９（ダウンロード処理部１９２）は、表示装置１８を通じて、ソフトウェアの更新に必要な対価の額と共に、ソフトウェアの更新データの存在を車両１０のユーザに通知することができる。また、ユーザ端末４０（通知部４０１）は、表示装置を通じて、ソフトウェアの更新に必要な対価の額と共に、ソフトウェアの更新データの存在を車両１０のユーザに通知することができる。一方、通知部２０１は、対象の車両１０のソフトウェアの更新による効果が所定の基準を満足しない場合、ソフトウェアの更新データの存在を通知する信号を対象の車両１０やそのユーザのユーザ端末４０に送信しない。これにより、配信サーバ２０は、対象の車両１０にとって相対的に効果が低い更新データの存在をユーザに通知しないことで、このような更新データに基づくソフトウェアの更新が実施されてしまうような事態を抑制することができる。そのため、配信サーバ２０は、車両１０で利用されるソフトウェアの更新をより適切に実施させることができる。

配信部２０２は、ソフトウェアの更新データを車両１０に配信する。例えば、通知部２０１は、対象の車両１０のソフトウェアの更新による効果が所定の基準を満足する場合、車両１０或いはユーザ端末４０から更新許可信号が受信されると、配信部２０２に更新データの配信指令を送信し、配信部２０２は、配信指令に応じて、対象の車両１０に更新データを送信する。一方、配信部２０２は、対象の車両１０のソフトウェアの更新による効果が所定の基準を満足しない場合、更新データの配信を見合わせる。これにより、配信サーバ２０は、対象の車両１０にとって相対的に効果が低いソフトウェアの更新を抑制することができ、その結果、車両１０で利用されるソフトウェアの更新をより適切に実施させることができる。

＜解析サーバの機能構成＞
図４に示すように、解析サーバ３０は、機能部として、車両データ取得部３０１と、車両データ記憶部３０２と、仮想車両モデル生成部３０３と、仮想車両モデル記憶部３０４と、シミュレータ部３０５と、効果予測部３０６とを含む。仮想車両モデル生成部３０３、シミュレータ部３０５、及び効果予測部３０６の機能は、例えば、解析サーバ３０の補助記憶装置にインストールされるプログラムをメモリ装置にロードしＣＰＵ上で実行することにより実現される。仮想車両モデル記憶部３０４の機能は、例えば、解析サーバ３０の補助記憶装置に規定される記憶領域によって実現される。

車両データ取得部３０１は、車両１０や車両１０に関連する外部装置から受信される車両データを取得する。

車両データ記憶部３０２は、車両データ取得部３０１により取得される車両データが格納（記憶）される。

仮想車両モデル生成部３０３（生成部の一例）は、車両１０に相当する仮想モデル（以下、「仮想車両モデル」）を生成する。仮想車両モデルは、車両１０の各種特性が仮想空間上で再現されたモデルである。仮想車両モデルは、例えば、車両１０の全体の各種特性が再現されたフルビークルモデルであってもよいし、後述の効果予測の対象となる車両１０の一部の特性（性能）だけが再現されたパーシャルビークルモデルであってもよい。また、仮想車両モデルは、車両１０の一部又は全部の形状が再現された三次元モデルであってもよい。

例えば、仮想車両モデル生成部３０３は、同じ車種や同じ車種且つ同じグレードの車両１０に汎用の仮想モデルに対して、車両データ記憶部３０２に記憶される最新の車両１０の状態を表す車両データを反映させることにより、仮想車両モデルを生成する。汎用の仮想モデルは、例えば、車両１０に相当する車種の開発段階で作成される、車両１０に相当する車種やグレードの最終仕様のフルビークルモデルやパーシャルビークルモデルであってよい。

また、例えば、仮想車両モデル生成部３０３は、車両データ取得部３０１によって時系列で繰り返し取得される車両データに基づき、仮想モデルの生成及び更新を行う。具体的には、仮想車両モデル生成部３０３は、車両１０に汎用の車両モデルをベースにして、車両１０から繰り返しアップロードされる車両データに基づき、仮想車両モデルを生成及び更新してよい。これにより、仮想車両モデル生成部３０３は、車両１０の経時変化、車両１０の使用条件、及び車両１０の構成要素の変化の少なくとも一つに合わせて、仮想車両モデルを生成（更新）することができる。そのため、仮想車両モデルに、車両１０の経時変化や車両１０の使用条件や車両１０の構成要素の変化を反映させることができる。車両１０の使用条件には、例えば、車両１０が使用される環境に関する条件、車両１０が使用されるときの走行条件、車両１０が使用される頻度に関する条件等が含まれてよい。車両１０の構成要素の変化には、例えば、車両１０の部品等のハードウェアの変化、車両１０のソフトウェアの変化、車両１０で使用される冷却水や潤滑油の種類の変化等が含まれてよい。また、仮想車両モデル生成部３０３は、車両データ記憶部３０２に格納される車両１０の製造時のばらつきに関するデータに基づき、仮想車両モデルを生成してもよい。これにより、仮想車両モデル生成部３０３は、車両１０の製造時のばらつきを仮想車両モデルに反映させることができる。また、仮想車両モデル生成部３０３は、車両１０から逐次アップロードされる車両データに基づき、リアルタイムに仮想車両モデルを更新することで、仮想車両モデルとしてのデジタルツインを生成してもよい。

仮想車両モデル記憶部３０４には、仮想車両モデル生成部３０３により生成された仮想車両モデルが記憶される。ソフトウェア更新システム１に含まれる車両１０が複数である場合、複数の車両１０ごとの仮想車両モデルが記憶される。

シミュレータ部３０５は、仮想車両モデル記憶部３０４に登録（記憶）されている車両１０の仮想車両モデルを用いて、車両１０に関する仮想シミュレーションを行う。車両１０に関する仮想シミュレーションには、所定の走行条件下での車両１０の走行シミュレーションが含まれる。

効果予測部３０６（予測部の一例）は、配信サーバ２０からの依頼に応じて、車両１０で利用されるソフトウェアの更新によって得られる効果を予測する。

効果予測部３０６は、例えば、ソフトウェアの更新の内容と、ソフトウェアの更新対象の車両１０の車両データの履歴とに基づき、更新対象のソフトウェアの更新による効果を予測する（例えば、後述の図５、図６参照）。具体的には、効果予測部３０６は、ソフトウェアの更新によって変化する車両１０の走行条件や使用環境に関する条件が、車両１０の車両データに基づき認識される、車両１０の使用実態とどの程度適合しているかを判断することにより、ソフトウェアの更新による効果を予測する。車両１０の使用実態によって、ソフトウェアの更新の影響を受ける走行条件や使用環境に関する条件が成立する頻度が変化するからである。

また、効果予測部３０６は、例えば、シミュレータ部３０５に、車両１０の仮想車両モデルを用いて、車両１０に関する仮想シミュレーションを実施させることにより、ソフトウェアの更新による効果を予測してもよい（例えば、後述の図７、図８参照）。具体的には、仮想車両モデル生成部３０３は、効果予測部３０６からの指示に応じて、車両１０の最新の仮想車両モデルをベースにして、ソフトウェアの更新が実施された場合に相当する仮想車両モデルを生成する。また、シミュレータ部３０５は、効果予測部３０６からの指示に応じて、ソフトウェアの更新後の車両１０に相当する仮想車両モデルを用いて、所定の走行条件下での車両１０の走行に関する仮想シミュレーションを実施する。車両１０の仮想シミュレーションが実施される、所定の走行条件は、当然の如く、ソフトウェアの更新の内容によって可変される。そして、効果予測部３０６は、ソフトウェアの更新後の車両１０に相当する仮想車両モデルを用いた仮想シミュレーションの結果に基づき、ソフトウェアの更新による効果を予測する。例えば、効果予測部３０６は、車両データ記憶部３０２に記憶される、最新の車両データと、ソフトウェアの更新後の車両１０の車両データに相当する仮想シミュレーションの結果のデータとを比較することで、ソフトウェアの更新による効果を予測する。これにより、効果予測部３０６は、車両データ記憶部３０２に格納される、車両１０の既存（最新）の車両データを更新前の車両１０の状態と想定して、比較的簡易な方法で、ソフトウェアの更新による効果を予測することができる。また、例えば、効果予測部３０６は、ソフトウェアの更新前及び更新後のそれぞれの車両１０に相当する仮想車両モデルを用いた仮想シミュレーションの結果を比較することで、ソフトウェアの更新による効果を予測してもよい。この場合、効果予測部３０６は、シミュレータ部３０５に、更新後の車両１０に相当する仮想車両モデルを用いた仮想シミュレーションだけでなく、更新前の車両１０に相当する仮想車両モデルを用いた仮想シミュレーションを同じ条件下で実施させる。これにより、効果予測部３０６は、比較対象のデータの前提となる走行条件等を略一致させることができる。そのため、効果予測部３０６は、より高い精度で効果を予測することができる。

効果予測部３０６は、例えば、ソフトウェアの更新によって改善される指標値が所定の基準を超えているか否かによって、効果の有無を予測してよい。また、効果予測部３０６は、ソフトウェアの更新によって改善される指標値に基づき、効果の度合いを予測してもよい。

また、効果予測部３０６は、例えば、ソフトウェアの更新の内容に応じて、効果の予測の方法を選択してもよい。具体的には、効果予測部３０６は、ソフトウェアの更新の内容に応じて、ソフトウェアの更新による効果の予測の際に、車両１０に相当する仮想車両モデルに基づく仮想シミュレーションを実施するか否かを判断してもよい。仮想シミュレーションを実施するか否かは、例えば、更新データごとに予め規定されており、その規定された内容に応じて、自動的に判断されてもよい。また、仮想シミュレーションを実施するか否かは、例えば、更新データの内容、及びソフトウェアの更新による効果の項目等に基づき、テーブル情報等を用いて、判断されてもよい。

また、効果予測部３０６は、例えば、ユーザが今後車両１０を利用する期間を考慮して、効果の有無や効果の度合いを予測してもよい。効果予測部３０６は、車両データ記憶部３０２に格納される、車両１０の新車登録のタイミング、及び直近の車検タイミング等のデータを参照して、ユーザが今後車両１０を利用する期間を予測してよい。例えば、ユーザが比較的近い時期で現在の車両１０の乗り換え等を予定している場合、ソフトウェアの更新が行われても、その恩恵を受けられる期間が短く、実質的に効果が小さくなる可能性があるからである。具体的には、効果予測部３０６は、ユーザが今後車両１０を利用する期間が短くなるほど、効果ありと判断するための所定の基準や効果の度合いを規定するための基準を相対的に高くなるように設定してよい。また、効果予測部３０６は、ユーザが今後車両１０を利用する期間が所定の基準を下回ると、ソフトウェアの更新による効果なしと予測するようにしてもよい。

＜ユーザ端末の機能構成＞
図４に示すように、ユーザ端末４０は、機能部として、通知部４０１を含む。通知部４０１の機能は、例えば、ユーザ端末４０の補助記憶装置にインストールされるプログラムをメモリ装置にロードしＣＰＵ上で実行することにより実現される。

通知部４０１は、配信サーバ２０から受信される上述の信号に基づき、表示装置を通じて、車両１０のソフトウェアの更新データの存在をユーザに通知する。これにより、車両１０のユーザは、車両１０を利用中以外のタイミングでも、車両１０のソフトウェアの更新データの存在を把握することができる。そのため、例えば、ユーザは、ユーザ端末４０で、ソフトウェアの更新を許可する入力を行い、車両１０の未使用のタイミングでソフトウェアの更新を完了させることができる。

［車両のソフトウェアの更新による効果の予測方法の具体例］
次に、図５～図８を参照して、効果予測部３０６による車両１０のソフトウェアの更新による効果の予測方法の具体例について説明する。

＜第１の具体例＞
図５は、車両１０の変速機の変速マップの更新の一例を示す図である。具体的には、図５は、横軸を車両１０の車速とし、縦軸を車両１０の要求駆動力とする座標系上において、車両１０の変速機の１速と２速との間、２速と３速との間、及び３速と４速との間のそれぞれの切替条件を表す。

尚、車両１０の要求駆動力は、例えば、車両１０の運転者のアクセル開度に応じて決定される。また、図５中で、実線は、シフトアップ時の切替条件（変速線）を表し、点線は、シフトダウン時の切替条件（変速線）を表している。

図５に示すように、本例では、変速機のシフトポジションに関する制御を行うＥＣＵ１３のソフトウェアの更新によって、３速と４速との間の切替条件が変速線５０１から変速線５０２に変更されている。

例えば、車両１０のユーザが動作点５０３を相対的に高い頻度で使用している場合を考える。変速線５０１を前提とすると、動作点５０３の状態では、変速機の３速から４速へのシフトアップが行われずに３速が維持され、その結果、エンジンや電動機等の原動機の回転数が相対的に高く維持される。そのため、車両１０のエネルギ消費が相対的に大きくなる。一方、ソフトウェアの更新が実施され、切替条件が変速線５０２に更新されると、動作点５０３の状態では、変速機の３速から４速へのシフトアップが完了し４速が維持され、その結果、エンジンや電動機等の原動機の回転数が相対的に低く維持される。そのため、車両１０のエネルギ消費が相対的に小さくなり、燃費や電費が改善される。よって、効果予測部３０６は、ソフトウェアの更新によるエネルギ消費改善の効果がある、或いは、効果の度合いが相対的に大きいと予測することができる。

また、例えば、車両１０のユーザが動作点５０３と同じ車速域で且つ動作点５０３より小さい要求駆動力の動作点５０４を相対的に高い頻度で使用している場合を考える。この場合、変速線５０１，５０２に依らず、動作点５０４の状態では、変速機の３速から４速へのシフトアップが完了し４速が維持される。そのため、効果予測部３０６は、ソフトウェアの更新による効果がない、或いは、効果の度合いが相対的に小さいと予測することができる。また、例えば、車両１０のユーザが切替条件の変更の影響を受ける車速域５０５を全く使用しない、或いは、その頻度が非常に少ない場合についても同様であってよい。

このように、本例では、効果予測部３０６は、車両１０から逐次アップロードされる（車両データ記憶部３０２に蓄積される）、要求駆動力及び車速に関する車両データに基づき、ソフトウェア（変速マップ）の更新による効果を予測することができる。

尚、効果予測部３０６は、変速機のシフトチェンジの切替条件に関するソフトウェアの更新について、車両１０の仮想車両モデルに基づく仮想シミュレーションの結果に基づき、ソフトウェアの更新による効果を予測してもよい。例えば、効果予測部３０６は、変速機のシフトチェンジの切替条件に関するソフトウェアの更新について、車両１０の仮想車両モデルに基づく仮想シミュレーションによって、車両１０の所定の走行条件における動力性能に関する効果を予測してもよい。

＜第２の具体例＞
図６は、車両１０の原動機の切替マップの更新の一例を示す図である。本例では、車両１０は、エンジン及び電動機の２つの原動機を切り替えて走行可能な、いわゆるハイブリッド車両である。具体的には、図５は、横軸を車両１０の車速とし、縦軸を車両１０の要求駆動力とする座標系において、エンジンを停止させて電動機（ＭＧ）のみで車両１０を走行させる状態と、エンジンを始動させてエンジンで車両１０を走行させる状態との切替条件を表す。

尚、エンジンで車両１０を走行させる状態には、エンジンのみで車両１０を走行させる状態と、エンジン及び電動機の双方で車両１０を走行させる状態の双方が含まれうる。

図６に示すように、本例では、２つの原動機の動作状態を統合的に制御するＥＣＵ１３のソフトウェアの更新によって、電動機のみで車両１０を走行させる状態とエンジンで車両１０を走行させる状態とを切り替える切替条件が切替線６０１（細い実線）から切替線６０２（太い実線）に更新されている。

例えば、車両１０のユーザが動作点６０３を相対的に高い頻度で使用している場合を考える。切替線６０１を前提とすると、動作点６０３の状態では、エンジンが始動されエンジンの動力で車両１０が走行する。一方、ソフトウェアの更新が実施され、切替条件が切替線６０２に更新されると、動作点６０３の状態では、電動機のみの動力で車両１０を走行させることができ、その結果、車両１０の燃費が改善される。よって、効果予測部３０６は、ソフトウェアの更新による車両１０の燃費改善の効果がある、或いは、効果の度合いが相対的に大きいと予測することができる。

また、例えば、車両１０のユーザが動作点６０３と略同じ車速域で且つ動作点６０３より小さい要求駆動力の動作点６０４を相対的に高い頻度で使用している場合を考える。この場合、切替線６０１，６０２に依らず、動作点６０４の状態では、電動機のみの動力で車両１０が走行する。よって、効果予測部３０６は、ソフトウェアの更新による車両１０の燃費改善の効果がない、或いは、効果の度合いが相対的に小さいと予測することができる。また、例えば、車両１０のユーザが切替条件の変更の影響を受ける動作領域６０５を全く使用しない、或いは、その頻度が非常に少ない場合についても同様であってよい。

このように、本例では、効果予測部３０６は、車両１０から逐次アップロードされる、要求駆動力及び車速に関する車両データに基づき、ソフトウェア（原動機の切替マップ）の更新による効果を予測することができる。

＜第３の具体例＞
図７は、車両１０の変速機のシフトチェンジ（シフトアップ）に関する制御ロジックの更新前及び更新後のそれぞれについて、変速機のシフトチェンジ時における車両１０の状態の経時変化の仮想シミュレーションの結果の一例（タイムチャート７００）を示す図である。具体的には、図７は、ソフトウェア更新システム１に含まれる一の車両１０の仮想車両モデルに基づく仮想シミュレーションの結果を示す図である。タイムチャート７００は、変速機のシフトチェンジ時における解放圧指令値、係合圧指令値、原動機（エンジン）の回転数、及び車両１０の前後加速度のそれぞれの経時変化を表すタイムチャート７０１～７０４を含む。図８は、車両１０の変速機のシフトチェンジ（シフトアップ）に関する制御ロジックの更新前及び更新後のそれぞれについて、変速機のシフトチェンジ時における車両１０の状態の経時変化の仮想シミュレーションの結果の他の例（タイムチャート８００）を示す図である。具体的には、図８は、ソフトウェア更新システム１に含まれる、上述の一の車両１０と同じ仕様の変速機を搭載する他の車両１０の仮想車両モデルに基づく仮想シミュレーションの結果を示す図である。タイムチャート８００は、変速機のシフトチェンジ時における解放圧指令値、係合圧指令値、変速機の出力軸の回転数、及び車両１０の前後加速度のそれぞれの経時変化を表すタイムチャート８０１～８０４を含む。

尚、解放圧指令値は、シフトチェンジによって係合状態から解放状態に移行する変速機の構成要素（例えば、ブレーキやクラッチ等）を作動させるための油圧の指令値を表す。また、係合圧指令値は、シフトチェンジによって解放状態から係合状態に移行する変速機の構成要素を作動させるための油圧の指令値を表す。また、図７、図８において、更新前及び更新後の変速機のシフトチェンジに関する制御ロジックは、同じである。そのため、制御ロジックに相当するタイムチャート７０１，７０２とタイムチャート８０１，８０２とは、同じである。

図７、図８に示すように、本例では、シフトチェンジ（シフトアップ）の開始（解放圧指令値の減少の開始）から終了（係合圧指令値の増大の終了）までの時間（変速時間）が短くなるように、変速機のシフトチェンジの制御ロジックが更新されている。

タイムチャート７０３では、制御ロジックの更新によって、変速機のシフトチェンジに伴う原動機（エンジン）の回転数の変化速度（時間経過に対する変化率）が相対的に大きくなっている。また、タイムチャート７０４では、変速機のシフトチェンジに伴う車両１０の前後加速度の変動も相対的に大きくなっている。そのため、ユーザは、シフトチェンジの速度（変速速度）の向上を明確に実感することができる。よって、図７の一の車両１０の場合、効果予測部３０６は、ソフトウェアの更新による変速速度の向上の効果がある、或いは、効果の度合いが相対的に大きいと予測することができる。

一方、タイムチャート８０３では、制御ロジックの更新の前後で、変速機のシフトチェンジに伴う原動機（エンジン）の回転数の変化速度（時間経過に対する変化率）が略変化していない。また、タイムチャート８０４では、制御ロジックの更新の前後で、変速機のシフトチェンジに伴う車両１０の前後加速度の変動の大きさにほとんど変化がない。そのため、ユーザは、シフトチェンジの速度（変速速度）の向上を実感しにくくなる。よって、図８の他の車両１０の場合、効果予測部３０６は、ソフトウェアの更新による変速速度の向上の効果がない、或いは、効果の度合いが相対的に小さいと予測することができる。

尚、同じ仕様の変速機を搭載する車両１０によって制御ロジックの更新による効果に差異が生じる原因としては、例えば、変速機に使用されている潤滑油の粘度の影響が考えられる。例えば、変速機に工場出荷時に充填される潤滑油よりも高粘度の市販の潤滑油が使用されている場合、ユーザが変速速度の向上を実感しにくくなる可能性がある。また、同じ仕様の変速機を搭載する車両１０によって制御ロジックの更新による効果に差異が生じる原因としては、例えば、変速機のクラッチパックのクリアランスの製造上のばらつきによる影響が考えられる。例えば、変速機のクラッチパックのクリアランスが製造上の許容範囲の中で下限付近にある場合、その上限付近にある場合よりもユーザが変速速度の向上を実感しにくくなる可能性がある。また、同じ仕様の変速機を搭載する車両１０によって制御ロジックの更新による効果に差異が生じる原因としては、例えば、変速機の累積での変速回数による影響が考えられる。例えば、車両１０の工場出荷後或いは変速機の新品への交換後の累積での変速回数が相対的に少ない場合、累積での変速回数が多い場合よりも変速機のクラッチパックのクリアランスが相対的に小さく、ユーザが変速速度の向上を実感しにくくなる可能性がある。また、同じ仕様の変速機を搭載する車両１０によって制御ロジックの更新による効果に差異が生じる原因としては、例えば、変速機のクラッチやブレーキの係合及び解放を実行するソレノイドバルブのエア漏れの影響が考えられる。例えば、変速機のソレノイドバルブのエア漏れが相対的に小さい場合、エア漏れが相対的に大きい場合よりも変速速度が相対的に高くなることから、制御ロジックの更新が実施されても、変速速度の向上をユーザが実感しにくくなる可能性がある。また、同じ仕様の変速機を搭載する車両１０によって制御ロジックの更新による効果に差異が生じる原因としては、例えば、車両１０が使用されている温度環境の影響が考えられる。例えば、車両１０が温度の非常に低い、いわゆる寒冷地で使用されている場合、比較的気温が高い状態で使用されている場合よりも潤滑油の粘度が高くなることから、制御ロジックの更新が実施されても、変速速度の向上をユーザが実感しにくくなる可能性がある。

このように、本例では、効果予測部３０６は、仮想車両モデルに基づく変速機のシフトチェンジに関する仮想シミュレーションの結果に基づき、ソフトウェア（変速機のシフトチェンジの制御ロジック関するプログラム）の更新による効果を予測することができる。

［ソフトウェア更新に関する処理］
次に、図９～図１１を参照して、車両１０のソフトウェアの更新に関する処理について説明する。

図９は、配信サーバ２０による車両１０のソフトウェアの更新に関する処理の一例を概略的に示すフローチャートである。図１０は、解析サーバ３０による車両１０のソフトウェアの更新に関する処理の一例を概略的に示すフローチャートである。図１１は、セントラルＥＣＵ１９による車両１０のソフトウェア更新に関する処理の一例を概略的に示すフローチャートである。

図９のフローチャートは、例えば、所定の時間間隔ごとに、繰り返し実行される。図１０のフローチャートは、配信サーバ２０からソフトウェアの更新による効果予測の依頼が受信されると実行される。図１１のフローチャートは、配信サーバ２０からソフトウェアの更新データありの通知が受信されると実行される。

尚、図９のステップＳ１１０～Ｓ１１８の処理は、更新データの配信対象の車両１０ごとに実施される。

図９に示すように、ステップＳ１０２にて、通知部２０１は、車両１０のソフトウェアの更新データがあるか否か、具体的には、新たな更新データが登録されたか否かを判定する。通知部２０１は、車両１０のソフトウェアの更新データがある場合、ステップＳ１０４に進み、車両１０のソフトウェアの更新データがない場合、今回のフローチャートの処理を終了する。

ステップＳ１０４にて、通知部２０１は、対象の更新データの配信対象の車両１０を確認する。更新データの配信対象の車両１０を表すデータは、例えば、更新データと共に配信サーバ２０に登録される。

配信サーバ２０は、ステップＳ１０４の処理が完了すると、ステップＳ１０６に進む。

ステップＳ１０６にて、通知部２０１は、車両１０のソフトウェアの更新による効果の予測依頼を解析サーバ３０に送信する。送信される予測依頼には、効果の予測対象の車両１０（即ち、更新データの配信対象の車両１０）、更新データの内容、効果の予測対象の特性（性能）等を表すデータが含まれる。

配信サーバ２０は、ステップＳ１０６の処理が完了すると、ステップＳ１０８に進む。

解析サーバ３０は、ステップＳ１０６の処理で送信された予測依頼の信号が受信されると、図１０のフローチャートを開始する。

ステップＳ２０２にて、効果予測部３０６は、配信サーバ２０から受信される予測依頼の信号に含まれるデータに基づき、効果の予測対象の車両１０を確認する。

解析サーバ３０は、ステップＳ２０２の処理が完了すると、ステップＳ２０４に進む。

ステップＳ２０４にて、車両データ取得部３０１は、効果の予測対象の車両１０に対して、最新の車両データの送信を要求する信号を送信する。この際、車両データ取得部３０１は、取得可能（要求可能）な全ての車両データを要求してよい。また、車両データ取得部３０１は、このうちの今回の効果の予測に必要な車両データ、即ち、対象の更新データによるソフトウェアの更新によって向上する車両１０の所定の性能に関する車両データを含む一部のデータのみの送信を要求してもよい。

解析サーバ３０は、ステップＳ２０４の処理が完了すると、ステップＳ２０６に進む。

ステップＳ２０６にて、車両データ取得部３０１は、効果の予測対象の車両１０から受信される車両データを取得し、車両データ記憶部３０２に記憶させる。

解析サーバ３０は、ステップＳ２０６の処理が完了すると、ステップＳ２０８に進む。

尚、通信障害等の何らかの理由で、ある程度の時間が経過しても、効果の予測対象の車両１０から車両データが受信されない場合、解析サーバ３０は、ステップＳ２０４に戻って、処理を繰り返してよい。また、車両１０（車両データ取得部１９１）から比較的高い頻度で車両データが自動でアップロードされ、最新の車両データが車両データ記憶部３０２に既に格納されているような形態では、ステップＳ２０４，Ｓ２０６の処理は省略されてもよい。

ステップＳ２０８にて、効果予測部３０６は、ソフトウェアの更新による効果の予測ために仮想シミュレーションが必要か否かを判定する。効果予測部３０６は、ソフトウェアの更新による効果の予測のために仮想シミュレーションが必要な場合、ステップＳ２１０に進み、仮想シミュレーションが不要な場合、ステップＳ２１４に進む。

ステップＳ２１０にて、仮想車両モデル生成部３０３は、効果の予測対象の車両１０ごとに、最新の車両データを反映した仮想車両モデルを生成する。例えば、仮想車両モデル生成部３０３は、上述の如く、車両１０に相当する汎用の仮想モデルに対して、最新の車両データを反映させることにより、ソフトウェアの更新前の車両１０に相当する仮想車両モデルを生成する。また、例えば、仮想車両モデル生成部３０３は、仮想車両モデル記憶部３０４に登録される直近で生成された仮想車両モデル（例えば、デジタルツイン）に対して、最新の車両データを反映させることにより、ソフトウェア更新前の車両１０に相当する仮想車両モデルを生成する。そして、仮想車両モデル生成部３０３は、ソフトウェアの更新前に相当する仮想車両モデルをベースにして、更新データの内容を反映させることにより、ソフトウェアの更新後の車両１０に相当する仮想車両モデルを生成する。

解析サーバ３０は、ステップＳ２１０の処理が完了すると、ステップＳ２１２に進む。

ステップＳ２１２にて、効果予測部３０６は、効果の予測対象の車両１０ごとに、ソフトウェアの更新に関する仮想シミュレーションをシミュレータ部３０５に実施させる。具体的には、シミュレータ部３０５は、仮想車両モデル生成部３０３により生成された、ソフトウェアの更新後に相当する仮想車両モデルを用いて、ソフトウェアの更新後に相当する車両１０に関する仮想シミュレーションを実施する。また、シミュレータ部３０５は、上述の如く、仮想車両モデル生成部３０３により生成された、ソフトウェアの更新前に相当する仮想車両モデルを用いて、ソフトウェアの更新前に相当する車両１０に関する仮想シミュレーションを実施してもよい。

解析サーバ３０は、ステップＳ２１２の処理が完了すると、ステップＳ２１４に進む。

ステップＳ２１４にて、効果予測部３０６は、予測対象の車両１０ごとに、ソフトウェアの更新による効果を予測する。例えば、ステップＳ２０８からステップＳ２１４に移行する場合、効果予測部３０６は、上述の如く、ソフトウェアの更新の内容と、ソフトウェアの更新対象の車両１０の車両データの履歴とに基づき、更新対象のソフトウェアの更新による効果を予測する（例えば、図５、図６参照）。また、例えば、ステップＳ２１２からステップＳ２１４に移行する場合、効果予測部３０６は、上述の如く、最新の車両データと、ソフトウェアの更新後の車両１０の車両データに相当する仮想シミュレーションの結果のデータとを比較し、ソフトウェアの更新による効果を予測する。また、効果予測部３０６は、上述の如く、ソフトウェアの更新前及び更新後のそれぞれの車両１０に相当する仮想シミュレーションの結果を比較し、ソフトウェアの更新による効果を予測してもよい。

解析サーバ３０は、ステップＳ２１４の処理が完了すると、ステップＳ２１６に進む。

ステップＳ２１６にて、効果予測部３０６は、更新データの配信対象の車両１０のソフトウェアの更新による効果の予測結果を配信サーバ２０に送信する。

解析サーバ３０は、ステップＳ２１６の処理が完了すると、今回のフローチャートの処理を終了する。

図９に戻り、ステップＳ１０８にて、通知部２０１は、解析サーバ３０から受信される、車両１０のソフトウェアの更新による効果の予測結果を取得する。

解析サーバ３０は、ステップＳ１０８の処理が完了すると、ステップＳ１１０に進む。

尚、通信障害等の何らかの理由で、ある程度の時間が経過しても、解析サーバ３０から車両１０のソフトウェアの更新による効果の予測結果が受信されない場合、配信サーバ２０は、ステップＳ１０６に戻って、処理を繰り返してよい。

ステップＳ１１０にて、通知部２０１は、解析サーバ３０から取得される予測結果に基づき、対象の車両１０のソフトウェアの更新による効果が所定の基準を満足するか否かを判定する。例えば、上述の如く、効果予測部３０６によって、車両１０のソフトウェアの更新による効果の有無が予測される場合、予測結果が効果あり場合、所定の基準を満足すると判定される。また、例えば、上述の如く、効果予測部３０６によって、車両１０のソフトウェアの更新による効果の度合いが予測される場合、効果の度合いが所定の基準以上或いは所定の基準を超えている場合、所定の基準を満足すると判定される。通知部２０１は、対象の車両１０のソフトウェアの更新による効果が所定の基準を満足する場合、ステップＳ１１２に進み、所定の基準を満足しない場合、ステップＳ１１８に進む。

ステップＳ１１２にて、通知部２０１は、ソフトウェアの更新データありの通知を車両１０に送信する。

配信サーバ２０は、ステップＳ１１２の処理が完了すると、ステップＳ１１４に進む。

尚、ステップＳ１１２にて、通知部２０１は、上述の如く、車両１０に代えて、或いは加えて、車両１０のユーザのユーザ端末４０に通知の信号を送信してもよい。

車両１０のセントラルＥＣＵ１９は、ステップＳ１１２の処理で送信された信号が受信されると、図１１のフローチャートを開始する。

ステップＳ３０２にて、ダウンロード処理部１９２は、ソフトウェアの更新データの存在を通知する通知画面を表示装置１８に表示させる。これにより、車両１０のユーザは、ソフトウェアの更新データの存在を把握し、ソフトウェアの更新を行うかどうかを判断することができる。

セントラルＥＣＵ１９は、ステップＳ３０２の処理が完了し、入力装置１７を通じてソフトウェアの更新の許否に関する入力が受け付けられると、ステップＳ３０４に進む。

ステップＳ３０４にて、ダウンロード処理部１９２は、ソフトウェアの更新を許可する入力が受け付けられたか否かを判定する。ダウンロード処理部１９２は、ソフトウェアの更新を許可する入力が受け付けられた場合、ステップＳ３０６に進み、ソフトウェアの更新を許可する入力が受け付けられなかった、即ち、ソフトウェアの更新を拒否する入力が受け付けられた場合、ステップＳ３１２に進む。

ステップＳ３０６にて、ダウンロード処理部１９２は、ゲートウェイＥＣＵ１２（通信装置１１）を通じて、ソフトウェアの更新を許可する旨の信号（以下、「更新許可信号」）を配信サーバ２０に送信する。

セントラルＥＣＵ１９は、ステップＳ３０６の処理が完了すると、ステップＳ３０８に進む。

図９に示すように、ステップＳ１１４にて、通知部２０１は、車両１０でソフトウェアの更新を許可する入力が受け付けられたか否かを判定する。具体的には、通知部２０１は、更新データの配信対象の車両１０から更新許可信号が受信されたか否かを判定する。通知部２０１は、車両１０から更新許可信号が受信された場合、ステップＳ１１６に進む。

ステップＳ１１６にて、配信部２０２は、更新データを車両１０に配信し、車両１０（セントラルＥＣＵ１９）にソフトウェアの更新を実施させる。

配信サーバ２０は、ステップＳ１１６の処理が完了すると、ステップＳ１２０に進む。

図１１に示すように、ステップＳ３０８にて、ダウンロード処理部１９２は、ゲートウェイＥＣＵ１２（通信装置１１）を通じて、配信サーバ２０から配信される更新データをダウンロードする。

セントラルＥＣＵ１９は、ステップＳ３０８の処理が完了すると、ステップＳ３１０に進む。

ステップＳ３１０にて、ソフトウェア更新部１９４は、配信サーバ２０から受信される、ソフトウェア更新の指令に応じ、記憶部１９３にダウンロード済の更新データを用いて、ソフトウェアの更新を実施する。

尚、ソフトウェア更新部１９４は、配信サーバ２０からの更新データのダウンロード完了に応じて、自らの判断で、ソフトウェアの更新を実施してもよい。

セントラルＥＣＵ１９は、ステップＳ３１０の処理が完了すると、今回のフローチャートの処理を終了する。

一方、ステップＳ３１２にて、ダウンロード処理部１９２は、ゲートウェイＥＣＵ１２（通信装置１１）を通じて、ソフトウェアの更新を拒否する旨の信号（以下、「更新拒否信号」）を配信サーバ２０に送信する。

セントラルＥＣＵ１９は、ステップＳ３１２の処理が完了すると、今回のフローチャートの処理を終了する。

尚、上述の如く、配信サーバ２０から更新データありの通知の信号がユーザ端末４０に送信される場合、ステップＳ３０８，Ｓ３１０の処理を除く、図１０のフローチャートと同様の処理がユーザ端末４０（通知部４０１）により実行される。また、ユーザ端末４０から配信サーバ２０に更新許可信号が送信された場合、セントラルＥＣＵ１９は、配信サーバ２０からの指令に応じて、図１１のフローチャートのうちのステップＳ３０８，Ｓ３１０の処理のみを実行する。

図９に示すように、ステップＳ１１４にて、通知部２０１は、車両１０から更新許可信号が受信されない場合、即ち、車両１０から更新拒否信号が受信された場合、ステップＳ１２０に進む。

一方、ステップＳ１１８にて、配信部２０２は、ソフトウェアの更新データの配信を見合わせる旨を判断する。これにより、配信サーバ２０は、上述の如く、相対的に効果が低いソフトウェアの更新を抑制することができ、その結果、車両１０で利用されるソフトウェアの更新をより適切に実施させることができる。また、この際、配信部２０２は、対象の更新データの配信が特定の車両１０に対して見合わせられた旨のデータ（例えば、フラグ）等を配信サーバ２０の補助記憶装置２２の所定の記憶領域に記録してよい。これにより、配信サーバ２０は、事後的に、対象の更新データが特定の車両１０に対して見合わせられたことを把握することができ、その結果、誤って、対象の更新データがその特定の車両１０に送信されてしまうような事態を抑制することができる。

配信サーバ２０は、ステップＳ１１８の処理が完了すると、ステップＳ１２０に進む。

ステップＳ１２０にて、配信サーバ２０は、更新データの配信対象の車両１０の全てについて、ステップＳ１１０～Ｓ１１８の処理が完了したか否かを判定する。配信サーバ２０は、更新データの配信対象の車両１０の全てについて、上記の処理が完了していない場合、ステップＳ１１０に戻り、更新データの配信対象の車両１０のうちの処理が未完了の車両１０について、ステップＳ１１０～Ｓ１１８の処理を実施する。一方、配信サーバ２０は、更新データの配信対象の車両１０の全てについて、上記の処理が完了している場合、今回のフローチャートの処理を完了する。

尚、ソフトウェアの更新の許否をユーザに確認する前に、更新データが車両１０に配信されてもよい。この場合、配信サーバ２０は、ステップＳ１１２の処理に代えて、ソフトウェアの更新データを対象の車両１０に配信する処理を実施すると共に、ステップＳ１１６にて、ソフトウェアの更新を実施させる指令の信号を対象の車両１０に送信する。また、この場合、セントラルＥＣＵ１９は、ソフトウェアの更新データのダウンロードが完了すると、図１１のフローチャートを開始し、ステップＳ３０８に代えて、配信サーバ２０からのソフトウェアの更新を実施させる指令の信号を受信する処理を実施する。また、この場合、セントラルＥＣＵ１９が自らの判断でソフトウェアの更新の有無を判断するのであれば、図１１のステップＳ３０６，Ｓ３０８が省略される。

このように、本例では、ソフトウェア更新システム１は、ソフトウェアの更新による効果が所定の基準を満足しない場合、更新データの対象の車両１０への送信を見合わせることで、車両１０で利用されるソフトウェアの更新をより適切に実施させることができる。

［作用］
次に、本実施形態に係るソフトウェア更新システム１の作用について説明する。

本実施形態では、ソフトウェア更新システム１は、車両データ取得部３０１と、効果予測部３０６と、配信部２０２と、を備える。具体的には、車両データ取得部３０１は、車両１０の所定の性能に関するデータを含む車両１０に関するデータを取得する。また、効果予測部３０６は、車両データ取得部３０１により取得されるデータに基づき、所定の性能を向上させるための、車両１０で利用されるソフトウェアの更新データが車両１０に適用されたときに得られる所定の性能に関する効果を予測する。そして、配信部２０２は、効果予測部３０６により予測される効果が所定の基準を満足する場合、車両１０に更新データを配信する一方、効果予測部３０６により予測される効果が所定の基準を満足しない場合、車両１０への更新データの配信を見合わせる。

これにより、ソフトウェア更新システム１は、対象の車両１０にとって相対的に効果が低いソフトウェアの更新が無駄に実施されるような事態を抑制することができる。そのため、ソフトウェア更新システム１は、車両１０で利用されるソフトウェアの更新をより適切に実施させることができる。

また、本実施形態では、ソフトウェア更新システム１は、仮想車両モデル生成部３０３を備えてもよい。具体的には、仮想車両モデル生成部３０３は、車両データ取得部３０１により取得される車両データに基づき、車両１０に相当する仮想車両モデルを生成してもよい。そして、効果予測部３０６は、仮想車両モデル生成部３０３により生成される仮想車両モデルを用いて、仮想シミュレーションを行うことにより、更新データが車両１０に適用されたときに得られる効果を予測してもよい。

これにより、ソフトウェア更新システム１は、ソフトウェアの更新によって得られる効果を具体的に予測することができる。

また、本実施形態では、効果予測部３０６は、車両データ取得部３０１により取得される、所定の性能に関する最新の車両データと、更新データに基づくソフトウェアの更新後の状態の車両１０に相当する仮想車両モデルに基づく仮想シミュレーションにより得られるデータとを比較し、効果を予測してもよい。

これにより、ソフトウェア更新システム１は、車両データ取得部３０１により取得される、既存（最新）の車両データを用いることで、より簡易的に、ソフトウェアの更新による効果を予測することができる。

また、本実施形態では、効果予測部３０６は、更新データに基づくソフトウェアの更新前及び更新後のそれぞれの状態の車両１０に相当する仮想車両モデルに基づく仮想シミュレーションで得られるデータを比較し、効果を予測してもよい。

これにより、ソフトウェア更新システム１は、車両１０のソフトウェアの更新による効果をより精度良く予測することができる。

また、本実施形態では、効果予測部３０６は、更新データに基づくソフトウェアの更新の内容に応じて、効果の予測の際の仮想シミュレーションの実施の有無を判断してもよい。

これにより、ソフトウェア更新システム１は、例えば、ソフトウェアの更新による効果を予測するための処理の簡素化と、ソフトウェアの更新による効果の予測精度の向上とのバランスを図り、その結果、処理の効率化を図ることができる。

また、本実施形態では、効果予測部３０６は、更新データに基づくソフトウェアの更新の内容に応じて、仮想シミュレーションの際の車両１０の走行条件を変化させてもよい。

これにより、ソフトウェア更新システム１は、車両１０のソフトウェアの更新によって影響を受ける走行条件に合わせて、車両１０に関する仮想シミュレーションを実施することができる。そのため、ソフトウェア更新システム１は、車両１０のソフトウェアの更新による効果をより精度良く予測することができる。

また、本実施形態では、車両データ取得部３０１は、最新の車両データを取得してもよい。そして、仮想車両モデル生成部３０３は、車両１０に相当する汎用モデルに対して、車両データ取得部３０１により取得される車両データを反映させることにより仮想車両モデルを生成してもよい。

これにより、ソフトウェア更新システム１は、例えば、同じ車種の複数の車両１０に共通の仮想モデル（汎用モデル）を用いて、ソフトウェアの更新による効果を予測することができる。そのため、ソフトウェア更新システム１は、例えば、ソフトウェアの更新による効果を評価するための仮想車両モデルの準備にかかる労力や時間を軽減し、より効率的にソフトウェアの更新による効果を予測することができる。

また、本実施形態では、車両データ取得部３０１は、時間経過に応じて、車両１０の状態に関するデータを繰り返し取得してもよい。そして、仮想車両モデル生成部３０３は、車両データ取得部３０１による車両１０の状態に関するデータの取得に合わせて、仮想車両モデルの生成及び更新を行ってもよい。

これにより、ソフトウェア更新システム１は、車両１０の使用実態等の車両１０ごとの固有の事情により即した仮想車両モデルを生成することができる。そのため、ソフトウェア更新システム１は、車両１０のソフトウェアの更新による効果をより精度良く予測することができる。

また、本実施形態では、仮想車両モデル生成部３０３は、車両データ取得部３０１により取得される車両データに基づき、車両１０の製造時のばらつきを反映させた仮想車両モデルを生成してもよい。

これにより、ソフトウェア更新システム１は、車両１０に固有の事情としての車両１０の製造時のばらつきを仮想車両モデルに反映させることができる。

また、本実施形態では、仮想車両モデル生成部３０３は、車両データ取得部３０１により取得されるデータに基づき、車両１０の経時変化、車両１０の使用条件、及び車両１０の構成要素の変化の少なくとも一つを反映させた仮想車両モデルを生成してもよい。

これにより、ソフトウェア更新システム１は、車両１０の固有の事情としての車両１０の経時変化や車両１０の使用条件や車両１０の構成要素の変化等を仮想車両モデルに反映させることができる。

また、本実施形態では、仮想車両モデルは、車両１０に相当するデジタルツインであってもよい。

これにより、ソフトウェア更新システム１は、車両１０の最新の状態が常に反映された仮想車両モデル（デジタルツイン）を用いて、ソフトウェアの更新による効果を予測することができる。そのため、ソフトウェア更新システム１は、車両１０のソフトウェアの更新によって得られる効果をより精度良く予測することができる。

また、本実施形態では、効果予測部３０６は、ユーザが車両１０を今後利用する期間を考慮して、効果を予測してもよい。

これにより、ソフトウェア更新システム１は、ユーザにとっての固有の事情を考慮した形で、車両１０のソフトウェアの更新によって得られる効果を予測することができる。

以上、実施形態について詳述したが、本開示はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された要旨の範囲内において、種々の変形・改良が可能である。

１ ソフトウェア更新システム（情報処理システム）
１０ 車両
１１ 通信装置
１２ ゲートウェイＥＣＵ
１３ ＥＣＵ
１５ センサ
１７ 入力装置
１８ 表示装置
１９ セントラルＥＣＵ
１９Ａ 補助記憶装置
１９Ｂ メモリ装置
１９Ｃ ＣＰＵ
１９Ｄ インタフェース装置
１９Ｅ 記録媒体
２０ 配信サーバ（情報処理装置）
２１ 外部インタフェース
２１Ａ 記録媒体
２２ 補助記憶装置
２３ メモリ装置
２４ ＣＰＵ
２５ 高速演算装置
２６ 通信インタフェース
２７ 入力装置
２８ 表示装置
３０ 解析サーバ
４０ ユーザ端末
１２１ 通信部
１２２ 記憶部
１３１ 記憶部
１９１ 車両データ取得部
１９２ ダウンロード処理部
１９３ 記憶部
１９４ ソフトウェア更新部
１９５ 記憶部
２０１ 通知部
２０２ 配信部
３０１ 車両データ取得部（取得部）
３０２ 車両データ記憶部
３０３ 仮想車両モデル生成部（生成部）
３０４ 仮想車両モデル記憶部
３０５ シミュレータ部
３０６ 効果予測部（予測部）

Claims (16)

1. 車両の所定の性能に関するデータを含む前記車両に関するデータを取得する取得部と、
   前記取得部により取得されるデータに基づき、前記車両に相当する仮想モデルを生成する生成部と、
   前記取得部により取得されるデータに基づき、前記仮想モデルを用いて、仮想シミュレーションを行うことにより、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測部と、
   前記予測部により予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測部により予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信部と、を備え、
   前記予測部は、前記更新データに基づく前記ソフトウェアの更新の内容に応じて、前記効果の予測の際の前記仮想シミュレーションの実施の有無を判断する、
   情報処理システム。
2. 前記予測部は、前記取得部により取得される、前記所定の性能に関する前記車両の最新のデータと、前記更新データに基づく前記ソフトウェアの更新後の状態の前記車両に相当する前記仮想モデルに基づく前記仮想シミュレーションにより得られるデータとを比較し、前記効果を予測する、
   請求項１に記載の情報処理システム。
3. 前記予測部は、前記更新データに基づく前記ソフトウェアの更新前及び更新後のそれぞれの状態の前記車両に相当する前記仮想モデルに基づく前記仮想シミュレーションで得られるデータを比較し、前記効果を予測する、
   請求項１に記載の情報処理システム。
4. 前記予測部は、前記更新データに基づく前記ソフトウェアの更新の内容に応じて、前記仮想シミュレーションの際の前記車両の走行条件を変化させる、
   請求項１乃至３の何れか一項に記載の情報処理システム。
5. 前記取得部は、最新の前記車両のデータを取得し、
   前記生成部は、前記車両に相当する汎用モデルに対して、前記取得部により取得されるデータを反映させることにより前記仮想モデルを生成する、
   請求項１乃至４の何れか一項に記載の情報処理システム。
6. 車両の所定の性能に関するデータを含む前記車両に関するデータを取得する取得部と、
   前記取得部により取得されるデータに基づき、前記車両に相当する仮想モデルを生成する生成部と、
   前記取得部により取得されるデータに基づき、前記仮想モデルを用いて、仮想シミュレーションを行うことにより、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測部と、
   前記予測部により予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測部により予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信部と、を備え、
   前記取得部は、時間経過に応じて、前記車両の状態に関するデータを繰り返し取得し、
   前記生成部は、前記取得部による前記車両の状態に関するデータの取得に合わせて、前記仮想モデルの生成及び更新を行う、
   情報処理システム。
7. 前記生成部は、前記取得部により取得されるデータに基づき、前記車両の製造時のばらつきを反映させた前記仮想モデルを生成する、
   請求項６に記載の情報処理システム。
8. 前記生成部は、前記取得部により取得されるデータに基づき、前記車両の経時変化、前記車両の使用条件、及び前記車両の構成要素の変化の少なくとも一つを反映させた前記仮想モデルを生成する、
   請求項６又は７に記載の情報処理システム。
9. 前記仮想モデルは、前記車両に相当するデジタルツインである、
   請求項６乃至８の何れか一項に記載の情報処理システム。
10. 車両の所定の性能に関するデータを含む前記車両に関するデータを取得する取得部と、
    前記取得部により取得されるデータに基づき、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測部と、
    前記予測部により予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測部により予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信部と、を備え、
    前記予測部は、ユーザが前記車両を今後利用する期間を考慮して、前記効果を予測する、
    情報処理システム。
11. 情報処理装置が実行する情報処理方法であって、
    車両の所定の性能に関するデータを含む前記車両に関するデータを取得する取得ステップと、
    前記取得ステップで取得されるデータに基づき、前記車両に相当する仮想モデルを生成する生成ステップと、
    前記取得ステップで取得されるデータに基づき、前記仮想モデルを用いて、仮想シミュレーションを行うことにより、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測ステップと、
    前記予測ステップで予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測ステップで予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信ステップと、を含み、
    前記予測ステップでは、前記更新データに基づく前記ソフトウェアの更新の内容に応じて、前記効果の予測の際の前記仮想シミュレーションの実施の有無を判断する、
    情報処理方法。
12. 情報処理装置が実行する情報処理方法であって、
    車両の所定の性能に関するデータを含む前記車両に関するデータを取得する取得ステップと、
    前記取得ステップで取得されるデータに基づき、前記車両に相当する仮想モデルを生成する生成ステップと、
    前記取得ステップで取得されるデータに基づき、前記仮想モデルを用いて、仮想シミュレーションを行うことにより、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測ステップと、
    前記予測ステップで予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測ステップで予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信ステップと、を含み、
    前記取得ステップでは、時間経過に応じて、前記車両の状態に関するデータを繰り返し取得し、
    前記生成ステップでは、前記取得ステップでの前記車両の状態に関するデータの取得に合わせて、前記仮想モデルの生成及び更新を行う、
    情報処理方法。
13. 情報処理装置が実行する情報処理方法であって、
    車両の所定の性能に関するデータを含む前記車両に関するデータを取得する取得ステップと、
    前記取得ステップで取得されるデータに基づき、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測ステップと、
    前記予測ステップで予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測ステップで予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信ステップと、を含み、
    前記予測ステップでは、ユーザが前記車両を今後利用する期間を考慮して、前記効果を予測する、
    情報処理方法。
14. 情報処理装置に、
    車両の所定の性能に関するデータを含む前記車両の状態に関するデータを取得する取得ステップと、
    前記取得ステップで取得されるデータに基づき、前記車両に相当する仮想モデルを生成する生成ステップと、
    前記取得ステップで取得されるデータに基づき、前記仮想モデルを用いて、仮想シミュレーションを行うことにより、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測ステップと、
    前記予測ステップで予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測ステップで予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信ステップと、を実行させ、
    前記予測ステップでは、前記更新データに基づく前記ソフトウェアの更新の内容に応じて、前記効果の予測の際の前記仮想シミュレーションの実施の有無を判断する、
    プログラム。
15. 情報処理装置に、
    車両の所定の性能に関するデータを含む前記車両の状態に関するデータを取得する取得ステップと、
    前記取得ステップで取得されるデータに基づき、前記車両に相当する仮想モデルを生成する生成ステップと、
    前記取得ステップで取得されるデータに基づき、前記仮想モデルを用いて、仮想シミュレーションを行うことにより、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測ステップと、
    前記予測ステップで予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測ステップで予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信ステップと、を実行させ、
    前記取得ステップでは、時間経過に応じて、前記車両の状態に関するデータを繰り返し取得し、
    前記生成ステップでは、前記取得ステップでの前記車両の状態に関するデータの取得に合わせて、前記仮想モデルの生成及び更新を行う、
    プログラム。
16. 情報処理装置に、
    車両の所定の性能に関するデータを含む前記車両の状態に関するデータを取得する取得ステップと、
    前記取得ステップで取得されるデータに基づき、前記所定の性能を向上させるための、前記車両で利用されるソフトウェアの更新データが前記車両に適用されたときに得られる前記所定の性能に関する効果を予測する予測ステップと、
    前記予測ステップで予測される前記効果が所定の基準を満足する場合、前記車両に前記更新データを配信する一方、前記予測ステップで予測される前記効果が前記所定の基準を満足しない場合、前記車両への前記更新データの配信を見合わせる配信ステップと、を実行させ、
    前記予測ステップでは、ユーザが前記車両を今後利用する期間を考慮して、前記効果を予測する、
    プログラム。

Images