JP2020021381A - ソフトウェア配信システム、ソフトウェア配信サーバ、及びソフトウェア配信方法 - Google Patents

Abstract

【課題】人為的ミスによる誤ったソフトウェアの配信を防止する。【解決手段】ソフトウェア配信システム１は、車両２０の車載機器（ＥＣＵ）に対する機能のアップデートをキャンペーンで管理し、キャンペーンに基づくソフトウェアを遠隔で配信するソフトウェア配信サーバ（テレマティクスセンタ１０）と、入出力を行う端末（端末３０，ナビゲーション端末２３０）と、車両２０に搭載され、配信されたソフトウェアをダウンロードし、対象の車載機器にインストールするソフトウェア更新装置２１０と、を備える。このソフトウェア配信システム１において、キャンペーンの作成が依頼されたとき、依頼キャンペーンの対象車載機器における直近の複数回のキャンペーンによるソフトウェアの更新量の統計情報と、依頼キャンペーンによるソフトウェアの更新量とを比較し、所定の条件を満たした場合には、依頼キャンペーンを作成せず、所定の警告を通知する。【選択図】図１

Description

本発明は、ソフトウェア配信システム、ソフトウェア配信サーバ、及びソフトウェア配信方法に関し、自動車等の車両に搭載される機器に対して遠隔のソフトウェア更新を実現するソフトウェア配信サーバ、ソフトウェア配信システム、及びソフトウェア配信方法に適用して好適なものである。

近年、運転支援機能や自動運転技術の進展により、自動車の車載機器（電子制御装置（ＥＣＵ：Electric Control Unit））に搭載されるソフトウェアの規模が増大している。このＥＣＵソフトウェアに対しては、設計開発段階におけるテストバージョンアップ、ソフトウェア不具合に起因するリコール対応や、量産前後の一斉バージョンアップ等、更新を必要とする場面が増えている。このようなソフトウェアの更新機会の増加に効率的に対応するために、従来携帯電話やテレビに使われていた無線による遠隔ソフト更新技術を自動車に適用することによって、自動車のＥＣＵソフトウェアを遠隔で更新するソフトウェア配信技術、所謂ＯＴＡ（Over The Air）への期待が高まっている。

ここで、例えば特許文献１には、車両に搭載される制御装置のプログラム更新中に、ユーザが車両機器の操作をすることを防止するプログラム提供システムが開示されている。特許文献１に開示されたプログラム提供システムでは、車両のユーザが車両から十分に離れている場合にプログラムの更新を指示することによって、プログラムの更新中に車両機器の操作が行われないようにして、プログラム（ソフトウェア）の更新を有効に完了できるようにしている。

特許第５８２９８３９号公報

しかし、上述の特許文献１に開示されたプログラム提供システムによれば、配信されたソフトウェアを確実に更新できる効果は得られるが、それ以前に、人為的ミス（ヒューマンエラー）によって、配信するソフトウェアが誤って選択されることは防止できなかった。

自動車のＥＣＵに対するＯＴＡにおいて、ソフトウェアが配信されるＥＣＵの種類は増加傾向にあり、また、各ＥＣＵにおいて配信されるソフトウェアのファイル名やバージョン名は類似していることが多い。したがって、配信するソフトウェアを決定する際に、人為的ミスによるソフトウェアの誤選択が発生するおそれがあった。特に、自動車の設計開発工程では、複数のバージョンのソフトを用いてテストが繰り返されることから、ソフトウェアのバージョンの確認ミスや読み違い等がより発生しやすくなり、誤ったソフトウェアを配信してしまった場合には、手戻りのために貴重なテスト時間が失われてしまうおそれがあった。したがって、このような課題に対して有効なソフトウェア配信技術が求められている。

本発明は以上の点を考慮してなされたもので、車載機器に対するソフトウェア更新において、人為的ミスによる誤ったソフトウェアの配信を防止することが可能なソフトウェア配信システム、ソフトウェア配信サーバ、及びソフトウェア配信方法を提案しようとするものである。

かかる課題を解決するため本発明においては、車両の車載機器に対する機能のアップデートを制御する、以下のようなソフトウェア配信システムが提供される。このソフトウェア配信システムは、前記機能のアップデートをキャンペーンで管理し、当該キャンペーンに基づくソフトウェアを当該キャンペーンの対象車両に遠隔で配信するソフトウェア配信サーバと、操作者による操作を受けて前記ソフトウェア配信サーバに対する入出力を行う端末と、前記車両に搭載され、前記ソフトウェア配信サーバから配信された前記ソフトウェアをダウンロードし、対象の車載機器にインストールするソフトウェア更新装置と、を備える。また、前記ソフトウェア配信サーバは、前記ソフトウェアを含む各種の情報を記憶する記憶部と、前記端末から前記キャンペーンのために必要な情報を受信し、前記受信した情報で構成されるキャンペーン情報を前記記憶部に登録することによって当該キャンペーンを作成するキャンペーン管理部と、前記キャンペーン管理部に登録された前記キャンペーン情報に従って、前記キャンペーンに基づく前記ソフトウェアを当該キャンペーンの対象車両に遠隔で配信するソフトウェア配信部と、を有する。そして、本ソフトウェア配信システムでは、前記端末の操作によって前記キャンペーンの作成が依頼されたとき、前記キャンペーン管理部が、前記依頼されたキャンペーンの対象となる前記車両の車載機器における直近の複数回のキャンペーンによる前記ソフトウェアの更新量の統計情報と、前記依頼されたキャンペーンによる前記ソフトウェアの更新量とを比較し、所定の条件を満たした場合には、前記依頼されたキャンペーンを作成せず、所定の警告を準備して前記端末に送信し、前記端末が、前記キャンペーン管理部から受信した前記所定の警告を所定の表示画面に表示することを特徴とする。

また、かかる課題を解決するため本発明においては、車両の車載機器に対する機能のアップデートをキャンペーンで管理し、当該キャンペーンに基づくソフトウェアを当該キャンペーンの対象車両に遠隔で配信する、以下のようなソフトウェア配信サーバが提供される。このソフトウェア配信サーバは、前記ソフトウェアを含む各種の情報を記憶する記憶部と、前記キャンペーンのために必要な情報を端末から受信し、前記受信した情報で構成されるキャンペーン情報を前記記憶部に登録することによって当該キャンペーンを作成するキャンペーン管理部と、前記キャンペーン管理部に登録された前記キャンペーン情報に従って、前記キャンペーンに基づく前記ソフトウェアを当該キャンペーンの対象車両に遠隔で配信するソフトウェア配信部と、を備え、前記端末から前記キャンペーンを作成する依頼を受けたときに、前記キャンペーン管理部が、前記依頼されたキャンペーンの対象となる前記車両の車載機器における直近の複数回のキャンペーンによる前記ソフトウェアの更新量の統計情報と、前記依頼されたキャンペーンによる前記ソフトウェアの更新量とを比較して、所定の条件を満たした場合には、前記依頼されたキャンペーンを作成せず、所定の警告を準備して前記端末に送信することを特徴とする。

また、かかる課題を解決するため本発明においては、車両の車載機器に対する機能のアップデートを制御するソフトウェア配信システムによる以下のようなソフトウェア配信方法が提供される。ここで、前記ソフトウェア配信システムは、前記機能のアップデートをキャンペーンで管理し、当該キャンペーンに基づくソフトウェアを当該キャンペーンの対象車両に遠隔で配信するソフトウェア配信サーバと、操作者による操作を受けて前記ソフトウェア配信サーバに対する入出力を行う端末と、前記車両に搭載され、前記ソフトウェア配信サーバから配信された前記ソフトウェアをダウンロードし、対象の車載機器にインストールするソフトウェア更新装置と、を有する。また、前記ソフトウェア配信サーバは、前記ソフトウェアを含む各種の情報を記憶する記憶部と、前記端末から前記キャンペーンのために必要な情報を受信し、前記受信した情報で構成されるキャンペーン情報を前記記憶部に登録することによって当該キャンペーンを作成するキャンペーン管理部と、前記キャンペーン管理部に登録された前記キャンペーン情報に従って、前記キャンペーンに基づく前記ソフトウェアを当該キャンペーンの対象車両に遠隔で配信するソフトウェア配信部と、を有する。本ソフトウェア配信方法は、上記の構成を有するソフトウェア配信システムにおいて、前記端末の操作によって前記キャンペーンの作成が依頼されたとき、前記キャンペーン管理部が、前記依頼されたキャンペーンの対象となる前記車両の車載機器における直近の複数回のキャンペーンによる前記ソフトウェアの更新量の統計情報と、前記依頼されたキャンペーンによる前記ソフトウェアの更新量とを比較する比較ステップと、前記比較ステップにおいて所定の条件を満たした場合には、前記キャンペーン管理部が、前記依頼されたキャンペーンを作成せず、所定の警告を準備して前記端末に送信するキャンペーン非作成ステップと、前記キャンペーン非作成を受けて、前記端末が、前記キャンペーン管理部から受信した前記所定の警告を所定の表示画面に表示する警告表示ステップと、を備えることを特徴とする。

本発明によれば、車載機器に対するソフトウェア更新において、人為的ミスによる誤ったソフトウェアの配信を防止することができる。本発明は、特に開発工程のテストにおいて有効な効果を奏する。

本発明の一実施の形態に係るソフトウェア配信システムの構成例を示す図である。 車両情報の具体例を示す図である。 車両構成情報の具体例を示す図である。 キャンペーン情報の具体例を示す図である。 更新用ソフトウェア情報の具体例を示す図である。 更新用ソフトウェアの登録処理の処理手順の一例を示すシーケンス図である。 キャンペーンの作成処理の処理手順の一例を示すシーケンス図である。 過誤可能性判定処理の処理手順の一例を示すフローチャートである。 キャンペーン作成画面の一例を説明する図である。 キャンペーンに基づく更新用ソフトウェアの配信処理の処理手順の一例を示すシーケンス図（その１）である。 キャンペーンに基づく更新用ソフトウェアの配信処理の処理手順の一例を示すシーケンス図（その２）である。 テスト計画情報の具体例を示す図である。 テスト計画の作成処理の処理手順の一例を示すシーケンス図である。 テスト計画に基づく更新用ソフトウェアの配信処理の処理手順の一例を示すシーケンス図（その１）である。 テスト計画に基づく更新用ソフトウェアの配信処理の処理手順の一例を示すシーケンス図（その２）である。 テスト計画確認画面の一例を説明する図である。

以下、図面を参照して、本発明の実施の形態を詳述する。

本説明において「キャンペーン」とは、車両に搭載された車載機器（ＥＣＵ）の同一機能を更新するために配信しようとする更新用ソフトウェアに対して、配信先である１以上の車両の情報を紐付けして管理するための情報の単位を意味する。

キャンペーンの用途は様々であるが、多数の車両を対象とする更新用ソフトウェアの全体的な配信に用いられる場合と、テスト（検証）用途に限定された特定の車両（テスト車両）を対象とする更新用ソフトウェアの限定的な配信に用いられる場合とがある。更新用ソフトウェアの全体的な配信としては、量産工程あるいは流通後の複数の車両に対して、機能向上やリコール対応等を目的としてアップデート用の更新用ソフトウェアを配信することがある。例えば、リコールの原因を解消するための更新用ソフトウェアが配信され、対象のＥＣＵにインストールされることにより、機能のアップデートが行われる。また、更新用ソフトウェアの限定的な配信としては、設計開発段階の特定の車両（テスト車両）に対して、機能確認や性能測定等を目的としてテスト用の更新用ソフトウェアを配信することがある。例えば、テスト用の更新用ソフトウェアがテスト車両に配信され、対象のＥＣＵにインストールされることにより、テストコース等で行われる走行テスト用のソフトウェアセッティングが行われる。

キャンペーンによるソフトウェア配信では、更新用ソフトウェアを指定したキャンペーン情報の登録によってキャンペーンを作成しておき、登録されたキャンペーン情報に基づいて対象とする車両２０に更新用ソフトウェアを配信し、ＥＣＵへのインストールを行う。ここで、キャンペーンの作成においては、操作者（エンジニアや管理者等）が更新用ソフトウェアを指定する必要があるが、バージョン情報の見間違いや操作ミスといった人為的なミスによって、誤ったソフトウェアを選択してしまう可能性がある。そこで、本実施の形態に係るソフトウェア配信システム１では、後述する「過誤可能性判定処理」を行うことによって、上記のようなソフトウェアの選択ミスによってキャンペーンが作成されてしまうことを防止することを特徴の１つとしている。

（１）第１の実施の形態
（１−１）ソフトウェア配信システム１の構成
図１は、本発明の一実施の形態に係るソフトウェア配信システムの構成例を示す図である。図１に示すソフトウェア配信システム１は、車両２０にソフトウェアを配信するシステムであって、ソフトウェア配信サーバであるテレマティクスセンタ１０と、ソフトウェア更新装置２１０及びナビゲーション端末２３０が搭載された車両２０と、テレマティクスセンタ１０に対して入出力を行う端末３０とを備える。

図１に示したように、テレマティクスセンタ１０は通信部１３０を介してネットワーク４０に接続され、車両２０のソフトウェア更新装置２１０は車両２０の通信部２２０を介してネットワーク４０に接続され、端末３０は通信部３４０を介してネットワーク４０に接続されている。この結果、テレマティクスセンタ１０、車両２０（ソフトウェア更新装置２１０）、及び端末３０は、ネットワーク４０を介して相互に通信可能に接続される。ネットワーク４０は、例えば、携帯電話網、インターネット網、無線ＬＡＮ（Local Area Network）等の近距離無線通信、あるいはそれらの組合せによって構成することができる。

なお、図１では、車両２０が１台だけ示されているが、本実施の形態における構成はこれに限定されるものではなく、それぞれにソフトウェア更新装置２１０及びナビゲーション端末２３０を搭載した複数台の車両２０が、ネットワーク４０を介してテレマティクスセンタ１０及び端末３０と通信可能に接続される構成であってもよい。また、テレマティクスセンタ１０と端末３０は同一の機器によって実現されてもよい。

（１−１−１）テレマティクスセンタ１０
テレマティクスセンタ１０は、ソフトウェア配信サーバ（例えばクラウド型サーバ）であって、ネットワーク４０を介して、端末３０からソフトウェア配信指示を受信し、車両２０に対してソフトウェアを配信する。テレマティクスセンタ１０は、中央演算処理装置１１０と、記憶装置１２０と、通信部１３０とを備える。

中央演算処理装置１１０は、例えばＣＰＵ（Central Processing Unit）やＲＡＭ（Random Access Memory）等から構成され、所定のプログラムを実行することによって、テレマティクスセンタ１０の各機能を実現する。中央演算処理装置１１０は、これらの機能別の構成として、車両管理部１１１、キャンペーン管理部１１２、更新用ソフトウェア配信部１１３、及びテスト計画管理部１１４を備える。なお、テスト計画管理部１１４は、第２の実施の形態のための構成であり、第１の実施の形態において必ずしも必要な構成ではない。

車両管理部１１１は、記憶装置１２０の車両ＤＢ１２１及び車両構成ＤＢ１２２に格納されている各情報を管理し、必要に応じて各情報の登録、変更、及び削除を行う。

キャンペーン管理部１１２は、記憶装置１２０のキャンペーンＤＢ１２３に格納されているキャンペーン情報を管理し、ソフトウェア配信システム１における処理のなかで各キャンペーン情報の登録、変更、及び削除を行う。

更新用ソフトウェア配信部１１３は、車両２０（更新用ソフトウェア要求部２１３）からの要求に応じて、車両２０にとって適切な更新用ソフトウェアを記憶装置１２０のソフトウェアＤＢ１２４から取り出し、通信部１３０及びネットワーク４０を介して車両２０に配信する。

テスト計画管理部１１４は、記憶装置１２０のテスト計画ＤＢ１２５に格納されているテスト計画情報を管理し、ソフトウェア配信システム１における処理のなかで各テスト計画情報の登録、変更、及び削除を行う。テスト計画情報については、第２の実施の形態で詳述する。

記憶装置１２０は、例えばＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ、またはＲＯＭ（Read Only Memory）等から構成される。記憶装置１２０には、中央演算処理装置１１０が実行するプログラムのほか、当該プログラムの実行に必要なデータ群等が格納される。

図１に示したように、記憶装置１２０に格納されるデータ群として、記憶装置１２０は、車両ＤＢ１２１、車両構成ＤＢ１２２、キャンペーンＤＢ１２３、ソフトウェアＤＢ１２４、及びテスト計画ＤＢ１２５等を備える。なお、テスト計画ＤＢ１２５は、第２の実施の形態のための構成であり、第１の実施の形態において必ずしも必要な構成ではない。

車両ＤＢ１２１は、１以上の車両２０のそれぞれ（各車両２０）について、車種、利用状況、及びソフトウェア配信時の制約条件となり得る情報等から構成される「車両情報」を蓄積する。車両情報の具体例は後述する図２に示される。

車両構成ＤＢ１２２は、各車両２０について、搭載されているＥＣＵの種別、及びインストールされているソフトウェアのバージョンを管理するための情報等から構成される「車両構成情報」を蓄積する。車両構成情報の具体例は後述する図３に示される。

キャンペーンＤＢ１２３は、車両２０に対して行われるキャンペーンのために必要な情報から構成される「キャンペーン情報」を蓄積する。キャンペーン情報は、キャンペーンにおいてソフトウェアのアップデート対象となるＥＣＵの種別、更新用ソフトウェアの配信時における制約条件、及び更新対象となる車両台数を管理するための情報等から構成され、その具体例は後述する図４に示される。

ソフトウェアＤＢ１２４は、キャンペーンで車両２０に配信する更新用ソフトウェアと、その管理情報（更新用ソフトウェア情報）とを蓄積する。なお、本説明では簡略のため、「更新用ソフトウェア情報」を「ソフトウェア情報」と称することがある。

テスト計画ＤＢ１２５は、テスト向けの特定の車両２０（テスト車両）に対して行われるテスト計画のために必要な情報から構成される「テスト計画情報」を蓄積する。

通信部１３０は、ネットワーク４０で用いられる通信規格に準拠したネットワークカード等から構成され、ネットワーク４０を介して、車両２０及び端末３０との間で、各種プロトコルに基づいてデータを送受信する。ネットワークカードは、有線ＬＡＮ等の有線通信や無線ＬＡＮ等の無線通信、あるいはその両方に必要な通信規格に準拠する。

（１−１−２）車両２０
車両２０は、ソフトウェア更新装置２１０と、通信部２２０と、ナビゲーション端末２３０と、各種ＥＣＵ（エンジンＥＣＵ２４１、自動運転ＥＣＵ２４２、…）とを備える。車両２０の各機器は、ＣＡＮ（Controller Area Network）、Ｅｔｈｅｒｎｅｔ（登録商標）等の車内ネットワークで接続される。

ソフトウェア更新装置２１０は、中央演算処理装置２１１と、記憶装置２１５と、位置測位装置２１６とを備える。

中央演算処理装置２１１は、例えばＣＰＵやＲＡＭ等から構成され、所定のプログラムを実行することによって、ソフトウェア更新装置２１０の各機能を実現する。中央演算処理装置２１１は、これらの機能別の構成として、キャンペーン確認部２１２、更新用ソフトウェア要求部２１３、及びＥＣＵソフトウェア更新部２１４を備える。

キャンペーン確認部２１２は、車両２０のエンジン始動をトリガとして、テレマティクスセンタ１０に問い合わせを行い、自車両のＥＣＵにソフトウェアアップデートを実施するキャンペーンがないかを確認する。

更新用ソフトウェア要求部２１３は、キャンペーン確認部２１２による確認の結果、自車両のＥＣＵを対象とするキャンペーンがあった場合に、テレマティクスセンタ１０に対して当該キャンペーンの更新用ソフトウェアを要求し、ダウンロードする。

ＥＣＵソフトウェア更新部２１４は、更新用ソフトウェア要求部２１３がダウンロードした更新用ソフトウェアを用いて、更新対象のＥＣＵをアップデートする。

記憶装置２１５は、例えばＨＤＤ、ＳＳＤ、フラッシュメモリ、またはＲＯＭ等から構成される。記憶装置２１５には、中央演算処理装置２１１が実行するプログラムのほか、当該プログラムの実行に必要なデータ群等が格納される。

位置測位装置２１６は、例えばＧＰＳ（Global Positioning System）センサ等で構成され、車両２０の現在位置を特定する位置情報（緯度情報及び経度情報）を取得する。

通信部２２０は、ネットワーク４０で用いられる通信規格に準拠したネットワークカード等から構成され、ネットワーク４０を介して、テレマティクスセンタ１０及び端末３０との間で、各種プロトコルに基づいてデータを送受信する。ネットワークカードは、例えば無線ＬＡＮ等の無線通信に準拠する。

ナビゲーション端末２３０は、車両２０の走行時に現在位置や目的地への経路案内を行うナビゲーション機能を有する一般的なカーナビゲーション装置やタブレット端末等で構成される。ナビゲーション端末２３０は、中央演算処理装置２３１と、記憶装置２３３と、入出力装置２３４とを備える。

中央演算処理装置２３１は、例えばＣＰＵやＲＡＭ等から構成され、所定の動作プログラムを実行することで、ナビゲーション端末２３０によるナビゲーション機能を実現する。中央演算処理装置２３１は、その機能構成として更新情報表示部２３２備える。更新情報表示部２３２は、ナビゲーション機能に基づく表示画面やテレマティクスセンタ１０から送信された更新用ソフトウェアの情報に基づく表示画面等を、入出力装置２３４に表示する。

記憶装置２３３は、例えばＨＤＤ、ＳＳＤ、フラッシュメモリ、またはＲＯＭ等から構成される。記憶装置２３３には、中央演算処理装置２３１が実行するプログラムのほか、当該プログラムの実行に必要なデータ群等が格納される。

入出力装置２３４は、タッチパネル、キーボード、またはマウス等を組み合わせて構成され、ナビゲーション端末２３０やソフトウェア更新装置２１０に対する入力部及び出力部（表示部）として機能する。

なお、本実施の形態の車両２０において、ソフトウェア更新装置２１０とナビゲーション端末２３０は同一の機器によって実現されても良い。また、ナビゲーション端末２３０が車両２０に搭載された構成に限定されるものではなく、例えば、ナビゲーション端末２３０の代わりに、ナビゲーション端末２３０と同様の機能を発揮するスマートフォンやタブレット等の携帯端末を用いるようにしてもよい。この場合、通信部２２０を携帯端末と通信可能な近傍に配置し、ソフトウェア更新装置２１０が例えばＯＢＤ（On Board Diagnostics）等のコネクタを用いることによって、ソフトウェア更新装置２１０が携帯端末と通信することが考えられる。

エンジンＥＣＵ２４１は、車両２０におけるエンジン動作を管理するＥＣＵである。自動運転ＥＣＵ２４２は、車両２０における自動運転の動作制御を管理するＥＣＵである。図１に示すように、これらのＥＣＵはバス型ＣＡＮネットワークに接続され、ソフトウェア更新装置２１０がこれらのバス型ネットワークのハブ機能を有する。

なお、図１では、ソフトウェア配信システム１において更新用ソフトウェアの配信対象となる車両２０の車載機器の一例として、エンジンＥＣＵ２４１と自動運転ＥＣＵ２４２を示しているが、車両２０に搭載される各種ＥＣＵはこれらに限られるものではない。例えば、サスペンション制御用のＥＣＵや、電子ミラー制御用のＥＣＵ等、車両２０の制御や安全を支援する機能を有するＥＣＵが搭載されていてもよい。なお、これらのＥＣＵには、自身を動作させるためのソフトウェアがそれぞれ内蔵されている。このソフトウェアは、各ＥＣＵが有する記憶装置（不図示）にそれぞれ格納されており、各ＥＣＵが有する中央演算処理装置（不図示）によって実行される。本実施の形態に係るソフトウェア配信サーバ（テレマティクスセンタ１０）は、これらのＥＣＵを更新対象とする更新用ソフトウェアを配信する。

（１−１−３）端末３０
端末３０は、汎用的な計算機や、タブレットやスマートフォン等の携帯端末等であって、中央演算処理装置３１０と、記憶装置３２０と、入出力装置３３０と、通信部３４０とを備える。

中央演算処理装置３１０は、例えばＣＰＵやＲＡＭ等から構成され、所定の動作プログラムを実行することによって、端末３０の機能を実現する。中央演算処理装置３１０は、その機能構成として、キャンペーン情報入出力部３１１を備える。

キャンペーン情報入出力部３１１は、ユーザによる入出力装置３３０の操作に応じて、テレマティクスセンタ１０に、キャンペーン情報に相当する情報等を送信する。また、キャンペーン情報入出力部３１１は、テレマティクスセンタ１０から受信した情報を入出力装置３３０に表示する。

記憶装置３２０は、例えばＨＤＤ、ＳＳＤ、フラッシュメモリ、またはＲＯＭ等から構成される。記憶装置３２０には、中央演算処理装置２１１が実行するプログラムのほか、当該プログラムの実行に必要なデータ群等が格納される。

入出力装置３３０は、タッチパネル、キーボード、またはマウス等を組み合わせて構成され、端末３０やテレマティクスセンタ１０に対する入力部及び出力部（表示部）として機能する。

通信部３４０は、ネットワーク４０で用いられる通信規格に準拠したネットワークカード等から構成され、ネットワーク４０を介して、テレマティクスセンタ１０との間で、各種プロトコルに基づいてデータを送受信する。ネットワークカードは、例えば無線ＬＡＮ等の無線通信に準拠する。

なお、前述したように、端末３０は、テレマティクスセンタ１０と同一の機器によって実現されてもよく、例えばテレマティクスセンタ１０が端末３０の機能を含んで構成される場合、テレマティクスセンタ１０が、端末３０の入出力装置３３０に相当する入出力装置を備え、さらに、中央演算処理装置１１０がキャンペーン情報入出力部３１１を備えるようにすればよい。

（１−２）各種データの構造
以下では、図１に示したテレマティクスセンタ１０の記憶装置１２０においてＤＢに格納される各種データの構造について具体例を挙げて説明する。但し、テスト計画ＤＢ１２５に格納されるテスト計画情報１２５０については、第２の実施の形態で説明する。なお、本具体例では、テーブル形式によるデータ構造を示すが、本実施の形態における各種データの構造はこれに限定されるものではない。

図２は、車両情報の具体例を示す図である。車両情報は、各車両２０についての車両本体のメタ情報であって、車両ＤＢ１２１に格納される。図２に示した車両情報１２１０は、ＶＩＮ１２１１、車種ＩＤ１２１２、位置１２１３、及び更新日時１２１４を備えて構成されるテーブル形式のデータである。

ＶＩＮ１２１１は、車両２０を一意に特定可能な識別子（ＶＩＮ：Vehicle Identification Number）である。車種ＩＤ１２１２は、ＶＩＮ１２１１で特定される車両２０（当該レコードにおける対象車両２０）の車種を一意に特定可能な識別子である。位置１２１３は、対象車両２０が最後にエンジンＯＦＦとなったときの位置情報であって、緯度、経度の順で表記されている。そして更新日時１２１４は、車両情報１２１０の当該レコードが更新された日時を示す情報である。

図３は、車両構成情報の具体例を示す図である。車両構成情報は、各車両２０が有するＥＣＵに関する情報であって、車両構成ＤＢ１２２に格納される。図３に示した車両構成情報１２２０は、ＶＩＮ１２２１、ＥＣＵ−ＩＤ１２２２、シリアルＩＤ１２２３、ソフトウェアバージョン１２２４、及び更新日時１２２５を備えて構成されるテーブル形式のデータである。

ＶＩＮ１２２１は、車両情報１２１０のＶＩＮ１２１１と共通のデータであり、対象車両２０を一意に特定可能な識別子である。

ＥＣＵ−ＩＤ１２２２は、対象車両２０に搭載されるＥＣＵの種別を一意に特定可能な識別子である。また、シリアルＩＤ１２２３は、対象車両２０に搭載されるＥＣＵを一意に特定可能な識別子である。例えば、図３のデータ行の１行目と３行目とを比較すると分かるように、ＥＣＵの種別（ＥＣＵ−ＩＤ１２２２）が同一であっても、それぞれのＥＣＵのシリアルＩＤ１２２３は異なる。

また、ソフトウェアバージョン１２２４は、当該レコードで特定するＥＣＵ（対象車両２０に搭載される特定のＥＣＵ）にインストールされたソフトウェアを一意に特定可能な識別子である。そして更新日時１２２５は、車両構成情報１２２０の当該レコードが更新された日時を示す情報である。

図４は、キャンペーン情報の具体例を示す図である。前述したように、キャンペーン情報はキャンペーンのために必要な情報で構成され、キャンペーンＤＢ１２３に格納される。図４に示したキャンペーン情報１２３０は、キャンペーンＩＤ１２３１、ＶＩＮ１２３２、ＥＣＵ−ＩＤ１２３３、ソフトウェアＩＤ１２３４、ステータス１２３５、及び更新日時１２３６を備えて構成されるテーブル形式のデータである。

キャンペーンＩＤ１２３１は、キャンペーン情報を一意に特定可能な識別子である。

ＶＩＮ１２３２は、車両情報１２１０のＶＩＮ１２１１や車両構成情報１２２０のＶＩＮ１２２１と共通のデータであり、当該レコードのキャンペーン時にソフトウェアを配信する車両２０を特定するための情報である。

ＥＣＵ−ＩＤ１２３３は、車両構成情報１２２０のＥＣＵ−ＩＤ１２２２と共通のデータであり、当該レコードのキャンペーンにおいてソフトウェアの更新対象とされるＥＣＵの種別（ＥＣＵ−ＩＤ）を示す情報である。

ソフトウェアＩＤ１２３４は、当該レコードのキャンペーンで配信される更新用ソフトウェアを識別するための識別子である。ソフトウェアＩＤ１２３４は、図５に例示する更新用ソフトウェア情報１２４０のソフトウェアＩＤ１２４１に対応する。

ステータス１２３５は、当該レコードのキャンペーンについて、ＶＩＮ１２３２で特定される車両２０における処理状況（進捗状況）を表す情報であり、更新日時１２３６は、当該レコードが更新された日時を示す情報である。

具体的には例えば、図４のデータ行の１行目のようにステータス１２３５が「更新完了」である場合は、対象の車両２０（ＶＩＮ「９ＧＪＨ」）の対象ＥＣＵ（ＥＣＵ−ＩＤ「Ｅｎｇｉｎｅ＿ＭＹ１５」）において更新用ソフトウェア（ソフトウェアＩＤ「ＡＰＡ＿ｖｅｒ１３」）のインストールが完了したことを意味する。このとき、更新日時１２３６には、「更新完了」が確認された日時（インストールが完了した日時でもよい）が記録される。

また例えば、図４のデータ行の２行目のようにステータス１２３５が「ダウンロード完了」である場合は、対象の車両２０（ＶＩＮ「７ＲＴＭ」）の対象ＥＣＵ（ＥＣＵ−ＩＤ「Ｓｔｅｅｒ＿１６ＪＰ」）において更新用ソフトウェア（ソフトウェアＩＤ「Ｂ７３Ｈ＿ｖ５」）のダウンロードは完了したが、インストールは完了していないことを意味する。このとき、更新日時１２３６には、「ダウンロード完了」が確認された日時（ダウンロードが完了した日時でもよい）が記録される。

また例えば、図４のデータ行の３行目のようにステータス１２３５が「インストール中」である場合は、対象の車両２０（ＶＩＮ「６ＡＢＣ」）の対象ＥＣＵ（ＥＣＵ−ＩＤ「Ｅｎｇｉｎｅ＿ＭＹ１４ＥＵ」）において更新用ソフトウェア（ソフトウェアＩＤ「ＣＣ８Ｙ＿ｖ２」）のダウンロードが完了してインストールの途中であることを意味する。このとき、更新日時１２３６には、インストール開始が確認された日時（インストールが開始した日時でもよい）が記録される。

図５は、更新用ソフトウェア情報の具体例を示す図である。更新用ソフトウェア情報（ソフトウェア情報）は、車両２０に配信する更新用ソフトウェアの管理情報であって、当該ソフトウェアとともにソフトウェアＤＢ１２４に格納される。図５に示した更新用ソフトウェア情報（ソフトウェア情報）１２４０は、ソフトウェアＩＤ１２４１、ファイル名１２４２、更新タイプ１２４３、前バージョン１２４４、後バージョン１２４５、ファイルサイズ１２４６、及び更新日時１２４７を備えて構成されるテーブル形式のデータである。

ソフトウェアＩＤ１２４１は、更新用ソフトウェアを一意に特定可能な識別子であり、図４に例示したキャンペーン情報１２３０のソフトウェアＩＤ１２３４と共通のデータである。

ファイル名１２４２は、当該レコードで管理する更新用ソフトウェアのファイル名である。また、更新タイプ１２４３は、当該更新用ソフトウェアの更新種別である。例えば、更新タイプ１２４３が「差分」である場合、当該更新用ソフトウェアが前バージョンからの差分ファイルであることを意味する。更新タイプ１２４３が「フル」である場合、当該更新用ソフトウェアは差分ファイルではなく、完全ファイル（フルファイル）であることを意味する。

前バージョン１２４４は、当該レコードで管理する更新用ソフトウェアの１つ前のバージョン名であり、後バージョン１２４５は、１つ後のバージョン名である。前バージョン１２４４または後バージョン１２４５が「ｎｕｌｌ」である場合は、１つ前のバージョンまたは１つ後のバージョンが存在しないことを意味する。ファイルサイズ１２４６は、当該レコードで管理する更新用ソフトウェアのファイルサイズであり、図５では例えばキロバイト（ｋＢ）の単位で記載されている。そして更新日時１２４７は、更新用ソフトウェア情報１２４０の当該レコードが更新された日時を示す情報である。

以上、図１に示したテレマティクスセンタ１０の記憶装置１２０においてＤＢに格納される各種データの構造について具体例を挙げて説明した。これらの具体例は、以降の説明でも適宜用いられる。

（１−３）キャンペーンの処理
次に、本実施の形態に係るソフトウェア配信システム１によるキャンペーンの作成や実行に関する処理について説明する。

（１−３−１）更新用ソフトウェアの登録
図６は、更新用ソフトウェアの登録処理の処理手順の一例を示すシーケンス図である。図６に示す処理は、キャンペーンで配信される更新用ソフトウェアをソフトウェアＤＢ１２４に登録（蓄積）するための処理である。

まず、エンジニアや管理者等によって端末３０の入出力装置３３０が操作され、更新用ソフトウェアの登録を要求する操作が行われる。このとき、登録対象の更新用ソフトウェア及び当該ソフトウェアに関する管理情報（ソフトウェア情報１２４０に相当する情報）が入力される。入力された情報は、例えば記憶装置３２０に記憶されてもよい。

そして、ステップＳ１０１では、端末３０のキャンペーン情報入出力部３１１が、上記操作で指定された更新用ソフトウェアの登録をテレマティクスセンタ１０に依頼する。このとき、当該更新用ソフトウェア及び管理情報も送信される。

ステップＳ１０１の依頼を受信したテレマティクスセンタ１０では、キャンペーン管理部１１２（または車両管理部１１１）が、受信した管理情報を更新用ソフトウェアのソフトウェア情報１２４０としてソフトウェアＤＢ１２４に格納する（ステップＳ１１１）。このとき、受信した更新用ソフトウェアもソフトウェアＤＢ１２４に格納する。なお、ステップＳ１１１において何らかの理由で更新用ソフトウェアの登録を受けられる状況ではないと判定した場合は、更新用ソフトウェア及びソフトウェア情報の登録は行わず、その旨を登録結果とする。そしてステップＳ１１２において、キャンペーン管理部１１２（または車両管理部１１１）は、ステップＳ１１１で実行した更新用ソフトウェア情報１２４０の登録結果を端末３０に送信する。

ステップＳ１１２で送信された登録結果を受信すると、端末３０のキャンペーン情報入出力部３１１は、その登録結果を入出力装置３３０に表示する（ステップＳ１０２）。これにより、エンジニアや管理者等は、更新用ソフトウェアの登録結果を確認することができる。

（１−３−２）キャンペーンの作成
図７は、キャンペーンの作成処理の処理手順の一例を示すシーケンス図である。図７に示す処理は、キャンペーン情報を登録することによって新たなキャンペーン（以後、新キャンペーンとも称する）を作成するための処理である。

なお、図７では、キャンペーンの作成を依頼する端末を車両２０のナビゲーション端末２３０としているが、本実施の形態に係るソフトウェア配信システム１では、端末３０からもキャンペーンの作成を依頼できるように構成されてもよい。この場合、図７に示した更新情報表示部２３２の代わりに、端末３０のキャンペーン情報入出力部３１１が同様の処理を行うようにすればよい。具体的に想定されるケースとしては例えば、車両２０からキャンペーンの作成を依頼するケースの具体例としては、設計開発段階のテストにおいて、特定の車両２０（テスト車両）を対象としてエンジニア等がテスト現場で直接キャンペーンを作成する場合が挙げられる。また、端末３０からキャンペーンの作成を依頼するケースの具体例としては、多数の車両２０を対象として更新用プログラムの全体的な配信を行うキャンペーンを作成する場合が挙げられる。

図７によればまず、ステップＳ２０１において、更新情報表示部２３２は、エンジニアによるナビゲーション端末２３０の入出力装置２３４の操作に応じて、ソフトウェア情報１２４０、キャンペーン情報１２３０、及び過去の更新履歴（ソフトウェアの更新履歴や、キャンペーンによる配信履歴等）について、テレマティクスセンタ１０に問い合わせる。

ステップＳ２０１の問い合わせを受信したテレマティクスセンタ１０では、車両管理部１１１及びキャンペーン管理部１１２が、問い合わせに応じて情報を検索し、抽出する（ステップＳ２１１）。具体的には例えば、車両管理部１１１が問い合わせ元の車両２０に関する情報を検索・抽出したり、キャンペーン管理部１１２がソフトウェアＤＢ１２４やキャンペーンＤＢ１２３からソフトウェア情報１２４０やキャンペーン情報１２３０等を検索・抽出したりする。そして、ステップＳ２１２において、車両管理部１１１及びキャンペーン管理部１１２は、ステップＳ２１１で抽出した検索結果をナビゲーション端末２３０に送信する。

ステップＳ２１２で送信された検索結果を受信すると、更新情報表示部２３２は、その検索結果を入出力装置２３４に表示する（ステップＳ２０２）。この表示を確認することにより、過去のキャンペーン等の履歴を把握することができる。

次いで、エンジニアは、更新情報表示部２３２に表示される所定の画面（キャンペーン作成画面）に対して、新キャンペーンを作成するために必要な所定の情報を入力（指定）する。キャンペーン作成画面は、図９に具体例を示すが、ステップＳ２０２において更新情報表示部２３２に表示された画面を流用するものであってもよい。そして、上記の入力操作を受けて、更新情報表示部２３２は、テレマティクスセンタ１０に新キャンペーンの作成を依頼する（ステップＳ２０３）。

テレマティクスセンタ１０では、ステップＳ２０３の新キャンペーンの作成依頼を受信すると（ステップＳ２１３）、キャンペーン管理部１１２が、新キャンペーンにおいて配信する更新用ソフトウェアについて、ソフトウェアの選択ミスの可能性を判定する「過誤可能性判定処理」を実行する（ステップＳ２１４）。

詳細は図８を参照しながら後述するが、過誤可能性判定処理において、ソフトウェア選択を間違えた可能性があると判定された場合は、新キャンペーンを作成せずに警告メッセージを準備する。一方、ソフトウェア選択を間違えた可能性がないと判定された場合は、新キャンペーンを作成（キャンペーン情報１２３０を作成・登録）する。そして、ステップＳ２１５において、キャンペーン管理部１１２は、ステップＳ２１４の過誤可能性判定処理の判定結果に基づく新キャンペーンの作成結果をナビゲーション端末２３０に送信する（ステップＳ２１５）。

ステップＳ２１５で送信された作成結果を受信すると、更新情報表示部２３２は、その作成結果を入出力装置２３４（キャンペーン作成画面）に表示する（ステップＳ２０４）。詳しくは、過誤可能性判定処理でソフトウェア選択を間違えた可能性があると判定された場合は（ステップＳ２２７経由）、ソフトウェアの選択ミスの可能性を指摘する警告メッセージが表示され、新キャンペーンを本当に作成してよいか再確認させる。一方、過誤可能性判定処理でソフトウェア選択を間違えた可能性はない判定された場合は（ステップＳ２２８経由）、ステップＳ２０３で依頼された新キャンペーンの作成が完了した旨が表示される。新キャンペーンの作成が完了すると、テレマティクスセンタ１０において当該キャンペーンによる更新用ソフトウェアの配信準備が整う。

図８は、過誤可能性判定処理の処理手順の一例を示すフローチャートである。図７のステップＳ２１４で述べたように、過誤可能性判定処理はキャンペーン管理部１１２によって実行される。

図８によればまず、キャンペーン管理部１１２は、更新情報表示部２３２からの作成依頼（図７のステップＳ２０３）で指定されたＶＩＮ及びＥＣＵ−ＩＤと同一の値を持つレコードを、キャンペーンＤＢ１２３に蓄積されているキャンペーン情報１２３０から検索し、該当するレコードを抽出する（ステップＳ２２１）。すなわち、ステップＳ２２１で抽出されるレコードは、新キャンペーンにおいて更新用ソフトウェアの配信対象となる車両のＥＣＵについて、当該ＥＣＵを対象として実行された過去のキャンペーン情報１２３０である。

次に、キャンペーン管理部１１２は、ステップＳ２２１で抽出したレコードを更新日時１２３６に基づいて降順にソートし、直近Ｎ回（Ｎは２以上の任意の整数）のレコードからなるキャンペーン履歴を抽出する（ステップＳ２２２）。

次に、キャンペーン管理部１１２は、ステップＳ２２２で抽出したキャンペーン履歴に含まれる各キャンペーンにおけるソフトウェアの更新量を算出する（ステップＳ２２３）。詳しくは、キャンペーン情報１２３０のソフトウェアＩＤ１２３４に対応するソフトウェア情報１２４０をソフトウェアＤＢ１２４から抽出し、そのファイルサイズ１２４６（差分サイズ）を参照することでソフトウェアの更新量を算出することができる。そして、キャンペーン管理部１１２は、ステップＳ２２３で算出した直近Ｎ回のキャンペーン履歴におけるソフトウェアの更新量に基づいて、その平均値Ａを算出する（ステップＳ２３４）。

次に、キャンペーン管理部１１２は、最後のキャンペーン（最新のキャンペーン履歴）で配信されたソフトウェアを今回指定された新キャンペーンで配信予定の更新用ソフトウェアに更新した場合のソフトウェアの更新量Ｄを算出する（ステップＳ２２５）。

そして、キャンペーン管理部１１２は、ステップＳ２２４で算出した平均値Ａ及びステップＳ２２５で算出した更新量Ｄを用いて、「２Ａ＜Ｄ」の関係が成立しているか否かを判定する（ステップＳ２２６）。ステップＳ２２６において「２Ａ＜Ｄ」であった場合は（ステップＳ２２６のＹＥＳ）、ステップＳ２２７に進み、「２Ａ≧Ｄ」であった場合は（ステップＳ２２６のＮＯ）、ステップＳ２２８に進む。なお、ステップＳ２２６における「２Ａ＜Ｄ」という判定条件は、従来の（直近Ｎ回のキャンペーンにおける）ソフトウェアの平均的な更新量と比較したときに、作成予定の新キャンペーンで指定されたソフトウェアの更新量が際立って異なる更新量になっていないか（乖離していないか）を判定するための指標の一例であって、この趣旨に基づく他の指標を用いてもよい。

ステップＳ２２７では、新キャンペーンで指定されたソフトウェアの更新量が従来のソフトウェアの更新量とは大きく異なっているため、キャンペーン管理部１１２は、ソフトウェア選択を間違えた可能性があると判定し、依頼された新キャンペーンについてのキャンペーン情報１２３０を作成せず、ソフトウェアの選択ミスの可能性を指摘する所定の警告メッセージを準備する。

一方、ステップＳ２２８では、作成予定のキャンペーンで指定されたソフトウェアの更新量が従来のソフトウェアの更新量と比べて特段の差異がないため、キャンペーン管理部１１２は、ソフトウェア選択を間違えた可能性はないと判定し、依頼された新キャンペーンについてのキャンペーン情報１２３０を作成してキャンペーンＤＢ１２３に登録する。

ステップＳ２２７またはＳ２２８の処理をもって過誤可能性判定処理は終了となり、その後は、前述したように図７のステップＳ２１５以降の処理が行われる。

なお、図８に示した過誤可能性判定処理では、ソフトウェアの更新量の算出において、当該ソフトウェアの更新用ファイルのファイルサイズを利用するとしたが、これは一例であって、ファイルサイズ以外の情報を利用してソフトウェアの更新量を算出するようにしてもよい。ファイルサイズ以外の情報を利用したソフトウェアの更新量の算出方法としては例えば、更新用ファイルにおけるソースコードの行数の差分に基づいて算出する方法、更新用ファイルがバイナリ形式で提供される場合の（または、更新用ファイルをバイナリファイルと見なしたとき）の差分ビットに基づいて算出する方法、あるいは、更新用ファイルをＥＣＵに書き込む際に更新されるＲＯＭのブロック数に基づいて算出する方法等が挙げられる。また、これらの複数の情報を組み合わせてソフトウェアの更新量を算出するようにしてもよい。

何れにしても、本実施の形態における過誤可能性判定処理は、過去Ｎ回分のソフトウェア更新量の統計情報と今回のソフトウェア更新量とを比較して、所定の条件を満たした場合に、過誤によるソフトウェアの選択ミスの可能性があると判定するものであればよく、この場合に、今回のソフトウェアの登録（キャンペーンの作成）を留保または拒否し、警告メッセージを準備するものであればよい。またさらに、上記判定に用いる「所定の条件」についても、過去Ｎ回分のソフトウェア更新量の統計情報と今回のソフトウェア更新量との間で大きな乖離があると判断可能な条件や閾値でありさえすれば、特定の条件式等に限定されるものではない。

図９は、キャンペーン作成画面の一例を説明する図である。図９に示したように、キャンペーン作成画面１０００は入出力装置２３４に表示される。

図９に例示したキャンペーン作成画面１０００において、上部の表示領域１００１には、新キャンペーン（キャンペーンＩＤ「Ｔ４５Ｍ０１２」）の詳細な情報がツリー形式で可視化されている。表示領域１００１に表示されたキャンペーンＩＤ、ＥＣＵ−ＩＤ、及びソフトウェアＩＤは、キャンペーン情報１２３０の構成情報に対応する。また、表示領域１００１に表示された「ファイル名」以下の情報は、上記ソフトウェアＩＤ（ソフトウェアＩＤ「ＡＰＡ＿ｖｅｒ１３」）に対応するソフトウェア情報１２４０の構成情報に対応する。

また、キャンペーン作成画面１０００において、表示領域１００１の下方には、操作者（エンジニアや管理者等）が選択可能なボタン１００２が配置されている。ボタン１００２は「キャンペーンを作成する」と表示されている通り、表示領域１００１に表示された情報によるキャンペーンの作成を依頼するときに選択される。

キャンペーン作成画面１０００では、表示領域１００１に新キャンペーン（今回のキャンペーン）に必要な情報が入力され、ボタン１００２の選択によって当該キャンペーンの作成が依頼されると、前述した過誤可能性判定処理（図７のステップＳ２１４）を経て、その作成結果が下部の表示領域１００３に表示される。

表示領域１００３は、作成依頼された新キャンペーン（今回のキャンペーン）で指定されたソフトウェアについて、過去のキャンペーンにおけるソフトウェア更新との比較結果を視覚的に表示する領域である。図９には、過誤可能性判定処理でソフトウェア選択を間違えた可能性があると判定された場合の一表示例として、表示領域１００３において、過去のキャンペーンにおけるソフトウェアの変更量（更新量）、及び今回の新キャンペーンで指定されたソフトウェアによる変更量のイメージが表示されている。

ここで、図８のステップＳ７０６のＮＯ〜ステップＳ２２７で説明したように、今回のキャンペーンで指定されたソフトウェアの更新量（図中の「今回」）について、従来のソフトウェアの更新量（図中の「前回」や「前々回」等）とは大きく異なっていると判定された場合には、表示領域１００３に、ソフトウェアの選択ミスの可能性を指摘する所定の警告メッセージが表示される。図９には具体例として、「＜注意＞今回のソフトウェア更新は、これまでと比べて変更量が多くなっています。本当にキャンペーンを作成して良いですか？」という警告メッセージが表されている。

そして、キャンペーン作成画面１０００において、表示領域１００３の下方には、操作者（エンジニアや管理者等）が選択可能なボタン１００４，１００５が配置されている。ボタン１００４，１００５は、表示領域１００３に警告メッセージが表示された場合に、操作者が対応を決定するために操作される。

より具体的には、ソフトウェアの選択ミスの可能性を指摘する表示領域１００３の警告メッセージに対して、操作者が選択ミスではない（指定した更新用ソフトウェアをキャンペーンで配信する）と判断した場合には、「はい」と表示されたボタン１００４を選択することによって、現在の入力内容でキャンペーンを作成することが最終的に決定される。この場合の処理は、図７には示していないが、例えば、更新情報表示部２３２からテレマティクスセンタ１０に対してキャンペーンの作成が改めて指示され、テレマティクスセンタ１０のキャンペーン管理部１１２は当該キャンペーンのキャンペーン情報１２３０を作成してキャンペーンＤＢ１２３に格納する。このように、意図した更新用ソフトウェアが指定されていた場合であっても、過去の履歴と比べて更新量が大きく乖離しているには警告メッセージを表示してボタン１００４の選択を求めることによって、操作ミスでないことを再確認させることができる。

また、ソフトウェアの選択ミスの可能性を指摘する表示領域１００３の警告メッセージに対して、操作者が選択ミスである（キャンペーンで配信する更新用ソフトウェアではない）と判断した場合には、「いいえ」と表示されたボタン１００４を選択することによって、現在の入力内容ではキャンペーンを作成しないことが最終的に決定される。この場合の処理は、図７には示していないが、例えば、操作者が表示領域１００１に適正な更新用ソフトウェアを入力し直した後にボタン１００２を選択することによって、更新情報表示部２３２からテレマティクスセンタ１０に対して、修正された新キャンペーンの作成依頼が行われる（図７のステップＳ２０３に戻ると考えてよい）。

以上、図７〜図９を参照しながら説明したように、本実施の形態に係るソフトウェア配信システム１では、新キャンペーンの作成依頼に対して、更新用ソフトウェアの選択ミスの可能性がないと判定した場合に限り、キャンペーン情報１２３０が作成・登録され、当該キャンペーンが作成される。一方、更新用ソフトウェアの選択ミスの可能性があると判定した場合には、キャンペーン作成画面１０００で警告メッセージ（表示領域１００３）を示すことにより、指定したソフトウェアが誤っていないか確認・検討させることができる。このようにすることで、人為的な選択ミスに起因してキャンペーンで誤った更新用ソフトウェアが配信されることを防止できる。

（１−３−３）更新用ソフトウェアの配信
図１０及び図１１は、キャンペーンに基づく更新用ソフトウェアの配信処理の処理手順の一例を示すシーケンス図（その１，その２）である。図１０には、車両２０がテレマティクスセンタ１０から更新用ソフトウェアをダウンロードする処理が示され、図１１には、図１０に示したダウンロードの後、車両２０が更新用ソフトウェアを対象ＥＣＵにインストールし、その結果をテレマティクスセンタ１０に通知する処理が示される。

まず、図１０を参照しながら、作成済みのキャンペーンに基づく更新用ソフトウェアのダウンロード処理を説明する。図１０に示した処理は、車両２０に搭載されているソフトウェア更新装置２１０のキャンペーン確認部２１２及び更新用ソフトウェア要求部２１３と、テレマティクスセンタ１０に搭載されている中央演算処理装置１１０のキャンペーン管理部１１２及び更新用ソフトウェア配信部１１３とによって実行される。

図１０によればまず、車両２０のキャンペーン確認部２１２が、エンジンＥＣＵ２４１から得られる情報を用いてエンジン始動（ＯＮ状態）を検知する（ステップＳ３０１）。ステップＳ３０１でエンジン始動を検知すると、キャンペーン確認部２１２は、当該車両２０のＶＩＮ（車両情報１２１０のＶＩＮ１２１１）についてキャンペーンの有無をテレマティクスセンタ１０に問い合わせる（ステップＳ３０２）。

ステップＳ３０２の問い合わせを受けたテレマティクスセンタ１０では、キャンペーン管理部１１２が、キャンペーンＤＢ１２３に格納されたキャンペーン情報１２３０を検索し、ＶＩＮ１２３２が送信元の車両２０のＶＩＮと一致するレコードが存在するか否かを確認することによって、キャンペーンの有無を検索する（ステップＳ３１１）。そして、キャンペーン管理部１１２は、ステップＳ３１１の確認結果（検索結果）を車両２０に送信する（ステップＳ３１２）。詳しくは、ステップＳ３１１で送信元の車両２０のＶＩＮと一致するレコードが存在した場合には、当該レコードのキャンペーン情報１２３０が検索結果として送信され、ステップＳ３１１で一致するレコードが存在しなかった場合には、キャンペーンがない旨の検索結果が送信される。

テレマティクスセンタ１０からの検索結果を受信した車両２０では（ステップＳ３０３）、キャンペーン確認部２１２が、検索結果からキャンペーンの有無を確認する（ステップＳ３０４）。具体的には例えば、検索結果にキャンペーン情報１２３０が含まれているかを確認する。検索結果にキャンペーン情報１２３０が含まれていなかった場合には、キャンペーンがないと判断し（ステップＳ３０４のＮＯ）、このときダウンロードする更新用ソフトウェアも存在しないことから、処理を終了する。一方、検索結果にキャンペーン情報１２３０が含まれていた場合には、キャンペーンがあると判断し（ステップＳ３０４のＹＥＳ）、更新用ソフトウェア要求部２１３は、当該キャンペーン情報１２３０のソフトウェアＩＤ１２３４から特定される更新用ソフトウェアの提供をテレマティクスセンタ１０に要求する（ステップＳ３０５）。なお、以下の説明では、検索結果から見つかったキャンペーンを「実行キャンペーン」と称する。

テレマティクスセンタ１０では、ステップＳ３０５の要求を受信すると（ステップＳ３１３）、更新用ソフトウェア配信部１１３が、指定されたソフトウェアＩＤ１２３４に基づいて、ソフトウェアＤＢ１２４から要求された更新用ソフトウェア（すなわち、実行キャンペーンの更新用ソフトウェア）を抽出し、車両２０に送信する（ステップＳ３１４）。

ステップＳ３１４で送信された更新用ソフトウェアは、車両２０で受信されてダウンロードが開始され（ステップＳ３０６）、ダウンロードデータは記憶装置２１５に蓄積される（ステップＳ３０７）。そして、更新用ソフトウェアのダウンロードが完了すると、キャンペーン確認部２１２は、ダウンロード完了をテレマティクスセンタ１０に通知する（ステップＳ３０８）。

テレマティクスセンタ１０では、ステップＳ３０８のダウンロード完了通知を受信（受領）すると、キャンペーン管理部１１２が、実行キャンペーンのキャンペーン情報１２３０に対してステータス１２３５を「ダウンロード完了」に更新し、キャンペーンＤＢ１２３に上書きする（ステップＳ３１５）。その後、キャンペーン管理部１１２は、ステップＳ３１４で送信した更新用ソフトウェアのインストールの開始命令を車両２０に送信する（ステップＳ３１６）。

そして、ステップＳ３１６のインストール開始命令を受信（受領）すると（ステップＳ３０９）、車両２０のキャンペーン確認部２１２は、エンジンが停止状態（ＯＦＦ状態）になるまで、更新用ソフトウェアのインストール開始を待機する待機状態に移行する。キャンペーン確認部２１２は、エンジンＥＣＵ２４１から得られる情報を用いてエンジン停止を検知することができる。エンジンが停止した後の処理は図１１に示される。

次に、図１１を参照しながら、キャンペーンに基づく更新用ソフトウェアのインストール処理を説明する。図１１に示した処理は、車両２０に搭載されているソフトウェア更新装置２１０のキャンペーン確認部２１２及びＥＣＵソフトウェア更新部２１４と、テレマティクスセンタ１０に搭載されている中央演算処理装置１１０のキャンペーン管理部１１２とによって実行される。

図１１によればまず、車両２０のキャンペーン確認部２１２が、エンジンＥＣＵ２４１から得られる情報を用いてエンジン停止（ＯＦＦ状態）を検知する（ステップＳ４０１）。ステップＳ４０１でエンジン停止を検知すると、キャンペーン確認部２１２は、実行中のキャンペーン（実行キャンペーン）が存在するか否かを確認する（ステップＳ４０２）。具体的には例えば、キャンペーン確認部２１２は、インストール開始命令を受領したが（図１０のステップＳ３０９）、インストールまでは完了していない更新用ソフトウェアの有無を確認すればよい。

ステップＳ４０２の確認で実行キャンペーンが存在しなかった場合には（ステップＳ４０２のＮＯ）、インストールする更新用ソフトウェアも存在しないことから、処理を終了する。一方、ステップＳ４０２の確認で実行キャンペーンが存在した場合には（ステップＳ４０２のＹＥＳ）、キャンペーン確認部２１２は、実行キャンペーンの更新用ソフトウェア（図１０の処理を経てダウンロード済み）の対象ＥＣＵへのインストール開始をテレマティクスセンタ１０に通知する（ステップＳ４０３）。なお、更新用ソフトウェアのインストール先となる対象ＥＣＵは、実行キャンペーンのキャンペーン情報１２３０のＥＣＵ−ＩＤ１２３３から特定することができる。

ステップＳ４０３のインストール開始通知を受けて、テレマティクスセンタ１０では、キャンペーン管理部１１２が、実行キャンペーンのキャンペーン情報１２３０に対してステータス１２３５を「インストール中」に更新し、キャンペーンＤＢ１２３に上書きする（ステップＳ４１１）。

また、インストール開始通知を送信した車両２０では、ＥＣＵソフトウェア更新部２１４が、対象ＥＣＵのソフトウェアインストールを実行し、当該ＥＣＵの記憶装置を上書きする（ステップＳ４０４）。その後、ＥＣＵソフトウェア更新部２１４は、対象ＥＣＵからインストール結果（更新の成否情報）を受け取り、受け取った更新の成否情報をテレマティクスセンタ１０に通知する（ステップＳ４０５）。

そして、ステップＳ４０５の通知を受けて、テレマティクスセンタ１０では、キャンペーン管理部１１２が、実行キャンペーンのキャンペーン情報１２３０に対してステータス１２３５を「更新完了」に更新し、キャンペーンＤＢ１２３に上書きする（ステップＳ４１２）。

以上のように、図１０及び図１１に示した処理が正常に進行することによって、本実施の形態に係るソフトウェア配信システム１では、キャンペーンによる更新用ソフトウェアの配信（ダウンロード及びインストール）が完了し、これをもってキャンペーンの実行が完了する。

（２）第２の実施の形態
前述したように、キャンペーンの用途の１つに、テストにおけるテスト車両を対象とする更新用ソフトウェアの限定的な配信がある。このテストのうち、主に設計開発段階のトライアルフェーズにおけるテストでは、１回のソフトウェアの更新でテストが完了することは少なく、複数回のソフトウェア更新を伴って一連のテストが実行されることが多い。具体的には例えば、テストコースにおいて、テスト車両の同一のＥＣＵに対して異なるバージョンのソフトウェアを順次更新しながらテスト走行を行い、その走行性能の変化を検証したりする。

このような一連のテストを１つのテスト計画としてみると、１つのテスト計画において異なる更新用ソフトウェアの配信が複数回に亘って実行されることになるため、複数のキャンペーンを作成し、テスト計画の進行にあわせてキャンペーンを順次実行する必要がある。また、テストの実行順序（テスト回次）やテストの開始位置等も定められることがあるため、テスト計画を管理するための情報には、第１の実施の形態で説明したキャンペーン情報よりも詳細な情報が必要となる。

以上の背景を鑑みて、第２の実施の形態では、第１の実施の形態と同様にキャンペーン全般について、操作ミスによる誤った更新用ソフトウェアの登録を防止できるだけでなく、キャンペーン情報を派生させたテスト計画情報を用いて、上記テスト計画を管理できるようにする。

なお、第２の実施の形態は、第１の実施の形態と同様に、図１に例示したソフトウェア配信システム１を用いて説明される。また、特段の記載がない限り、各ＤＢに格納される情報の構成やキャンペーンの処理等も、第１の実施の形態と共通とする。そして、第１の実施の形態と共通する部分については、その説明を省略することがある。

（２−１）テスト計画情報の構成
図１２は、テスト計画情報の具体例を示す図である。テスト計画情報は、設計開発段階等のテスト計画に特有の詳細な情報から構成され、テスト計画ＤＢ１２５に格納される。テスト計画情報は、キャンペーン情報の派生と捉えることができるが、第１の実施の形態で図４に例示したキャンペーン情報１２３０よりも詳細な項目を有する。

図１２に例示したテスト計画情報１２５０は、テスト計画ＩＤ１２５１、テスト回次１２５２、ステータス１２５３、テスト開始日時１２５４、テスト終了日時１２５５、テスト車両ＶＩＮ１２５６、ＥＣＵ−ＩＤ１２５７、ソフトウェアＩＤ１２５８、テスト開始位置１２５９、及び更新日時１２６０を備えて構成されるテーブル形式のデータである。

テスト計画ＩＤ１２５１は、テスト計画を一意に特定可能な識別子であり、キャンペーンＩＤが派生したものである。なお、本例では、キャンペーン情報１２３０のキャンペーンＩＤ１２３１と区別できるように、テスト計画ＩＤ１２５１には「Ｔｒｉａｌ」の文字列が含まれるようにしている。例えば、図１２のデータ行の１行目には、テスト計画ＩＤ１２５１として「Ｔ４５Ｍ０１２Ｔｒｉａｌ」が記載されているが、このＩＤは、キャンペーンＩＤ「Ｔ４５Ｍ０１２」で示されるキャンペーン（図４のデータ行の１行目参照）に対応するテスト計画のＩＤであることを意味する。

テスト回次１２５２は、テスト計画（同一のテスト計画ＩＤ）に含まれる個々のテストの実行順序を表す情報である。

ステータス１２５３は、当該レコードに示すテストの処理状況（進捗状況）を表す情報であり、例えば、「完了」または「未配信」で記載される。

テスト開始日時１２５４は、当該レコードに示すテストの実行開始日時を示す情報であり、テスト終了日時１２５５は、その実行終了日時を示す情報である。テスト開始日時１２５４及びテスト終了日時１２５５には予定の情報が記載されてもよい。また、当初は予定の情報を記載し、テストを実行したときに実際の実行日時で更新するようにしてもよい。

テスト車両ＶＩＮ１２５６は、当該レコードに示すテストにおいて更新用ソフトウェアの配信対象となる車両２０を特定するための情報であり、これまで説明してきた各種情報におけるＶＩＮと共通のデータである。なお、本例では、簡便のために、１台のテスト車両（図１２によればテスト車両ＶＩＮ「９ＧＪＨ」）に限定して説明を進めるが、実際には、複数台のテスト車両が記載されてもよい。

ＥＣＵ−ＩＤ１２５７は、当該レコードに示すテストにおいてソフトウェアの更新対象とされるＥＣＵの種別を特定するための情報であり、これまで説明してきた各種情報におけるＥＣＵ−ＩＤと共通のデータである。

ソフトウェアＩＤ１２５８は、当該レコードに示すテストにおいて配信される更新用ソフトウェアを特定するための情報であり、図５のソフトウェア情報１２４０のソフトウェアＩＤ１２４１と共通のデータである。ソフトウェアＩＤ１２５８には、更新用ソフトウェアをバージョン単位まで識別可能な識別子が記載される。

テスト開始位置１２５９は、当該レコードに示すテストにおいて、テストを開始する際の対象車両の位置を示す情報であり、例えば、テストコースのピットの座標等が記載される。テスト開始位置１２５９は、当該テストで配信される更新用ソフトウェアのＥＣＵへのインストールを許可する位置との意味合いも持つ。

そして、更新日時１２６０は、テスト計画情報１２５０の当該レコードが（最後に）更新された日時を示す情報である。

（２−２）テスト計画の処理
次に、本実施の形態に係るソフトウェア配信システム１によるテスト計画の作成や実行に関する処理について説明する。

なお、テスト計画において配信される更新用ソフトウェアは、第１の実施の形態で図６を参照しながら説明した更新用ソフトウェアの登録処理を準用することによって、ソフトウェアＤＢ１２４に登録される。具体的には、図６におけるキャンペーン管理部１１２による処理をテスト計画管理部１１４が実行すればよい。

（２−２−１）テスト計画の作成
図１３は、テスト計画の作成処理の処理手順の一例を示すシーケンス図である。図１３に示す処理は、テスト計画情報を登録することによって新たなテスト計画を作成するための処理である。

なお、図１３では、テスト計画の作成を依頼する端末を端末３０としているが、本実施の形態では、車両２０のナビゲーション端末２３０に置き換えてもよい。その場合、図１３に示したキャンペーン情報入出力部３１１の代わりに、ナビゲーション端末２３０の更新情報表示部２３２が同様の処理を行うようにすればよい。

図１３によればまず、テスト計画を策定するエンジニア等によって端末３０の入出力装置３３０が操作され、登録しようとするテスト計画に必要な詳細情報（テスト計画情報１２５０に相当する情報）が入力される。具体例は省略するが、入出力装置３３０には、第１の実施の形態で説明したキャンペーン作成画面（図９参照）のような所定のテスト計画作成画面が表示されるとよい。

そしてステップＳ５０１では、上記の入力操作を受けて、端末３０のキャンペーン情報入出力部３１１が、テレマティクスセンタ１０に新しいテスト計画の作成を依頼する。このとき、上記入力操作で入力されたテスト計画の詳細情報がテレマティクスセンタ１０に送信される。

ステップＳ５０１の依頼を受信したテレマティクスセンタ１０では、キャンペーン管理部１１２（または車両管理部１１１）が、受信したテスト計画の詳細情報をテスト計画情報１２５０としてテスト計画ＤＢ１２５に格納することにより、依頼されたテスト計画情報を登録する（ステップＳ５１１）。そしてステップＳ５１２において、キャンペーン管理部１１２（または車両管理部１１１）は、ステップＳ５１１で実行したテスト計画情報１２５０の登録結果（すなわち、テスト計画の作成結果）を端末３０に送信する。

なお、上記のステップＳ５１１においては、登録を依頼されたテスト計画情報に不備がないことを確認した上で、テスト計画情報１２５０を登録することが好ましい。具体的には例えば、指定されたテスト車両ＶＩＮ、ＥＣＵ−ＩＤ、ソフトウェアＩＤに対応する情報が、記憶装置１２０のＤＢに格納されているかを確認する。そして、確認の結果、当該情報が格納されていない場合には、ステップＳ５１１においてテスト計画情報１２５０の登録は行わず、ステップＳ５１２においてテスト計画を作成しなかった旨の作成結果を送信する。

また、キャンペーン管理部１１２は、テスト計画情報の登録を依頼されたとき、第１の実施の形態におけるキャンペーン情報の登録依頼時と同様に、過誤可能性判定処理を行い（図７及び図８参照）、今回のテスト計画情報で指定された更新用ソフトウェアの更新量が過去のテスト計画における更新用ソフトウェアの更新量から大きく乖離していないかを判定するようにしてもよい。補足すると、図８における「キャンペーン」を「テスト計画」に読み替えればよい。このとき、過誤可能性判定によって今回のテスト計画で指定された更新用ソフトウェアの更新量が過去履歴と比較して大きく乖離していると判定した場合には（図８のステップＳ２２６のＹＥＳに相当）、テスト計画情報を登録（テスト計画を作成）せずに警告メッセージを準備し、ステップＳ５１２で作成結果として送信する。このように過誤可能性判定処理を行うことによって、テスト計画の作成においても、ソフトウェアの選択ミスの防止効果に期待できる。

そして、ステップＳ５１２で送信されたテスト計画の作成結果を受信すると、端末３０のキャンペーン情報入出力部３１１は、その作成結果を入出力装置３３０に表示する（ステップＳ５０２）。これにより、エンジニア等の操作者は、依頼したテスト計画の作成結果を確認することができる。

（２−２−２）更新用ソフトウェアの配信
図１４及び図１５は、テスト計画に基づく更新用ソフトウェアの配信処理の処理手順の一例を示すシーケンス図（その１，その２）である。図１４には、テストで使用される車両２０（テスト車両）がテレマティクスセンタ１０から更新用ソフトウェアをダウンロードする処理が示され、図１５には、図１４に示したダウンロードの後、車両２０（テスト車両）が更新用ソフトウェアを対象ＥＣＵにインストールし、その結果をテレマティクスセンタ１０に通知する処理が示される。また、図１６は、テスト計画確認画面の一例を説明する図である。

まず、図１４を参照しながら、作成済みのテスト計画による更新用ソフトウェアのダウンロード処理を説明する。図１４に示した処理は、車両２０に搭載されているソフトウェア更新装置２１０のキャンペーン確認部２１２及び更新用ソフトウェア要求部２１３と、テレマティクスセンタ１０に搭載されている中央演算処理装置１１０の更新用ソフトウェア配信部１１３及びテスト計画管理部１１４とによって実行される。

図１４によればまず、車両２０のキャンペーン確認部２１２が、エンジンＥＣＵ２４１から得られる情報を用いてエンジン始動を検知する（ステップＳ６０１）。ステップＳ６０１でエンジン始動を検知すると、キャンペーン確認部２１２は、テレマティクスセンタ１０からテスト計画を受信済みではないかを確認する（ステップＳ６０２）。

ステップＳ６０２においてテスト計画が未受信である場合は（ステップＳ６０２のＹＥＳ）、キャンペーン確認部２１２は、自車両２０を対象とするテスト計画の有無をテレマティクスセンタ１０に問い合わせる（ステップＳ６０３）。一方、ステップＳ６０２においてテスト計画を受信済みである場合は（ステップＳ６０２のＮＯ）、ステップＳ６０３及びＳ６０４の処理をスキップし、ステップＳ６０５に進む。

ステップＳ６０３の問い合わせを受けたテレマティクスセンタ１０では、テスト計画管理部１１４が、テスト計画ＤＢ１２５に格納されたテスト計画情報１２５０を検索し、テスト車両ＶＩＮ１２５６が送信元の車両２０のＶＩＮと一致するレコードが存在するか否かを確認することによって、テスト計画の有無を検索する（ステップＳ６１１）。そして、テスト計画管理部１１４は、ステップＳ６１１の確認結果（検索結果）を車両２０に送信する（ステップＳ６１２）。詳しくは、ステップＳ６１１で送信元の車両２０のＶＩＮと一致するレコードが存在した場合には、当該レコードのテスト計画情報１２５０が検索結果として送信され、ステップＳ６１１で一致するレコードが存在しなかった場合には、テスト計画がない旨の検索結果が送信される。

テレマティクスセンタ１０からの検索結果を受信した車両２０では（ステップＳ６０４）、キャンペーン確認部２１２が、検索結果から次のテスト回次の有無を確認する（ステップＳ６０５）。具体的には、受信済みのテスト計画情報１２５０（ステップＳ６０４で受信したものを含む）のテスト回次１２５２及びステータス１２５３を参照し、ステータス「未配信」となっているテスト回次が存在する場合には、次のテスト回次があると判断し（ステップＳ６０５のＹＥＳ）、ステップＳ６０６に進む。なお、次のテスト回次の判断では、テスト開始日時１２５４に記載された日時が近いか等も判断要素としてよい。一方、ステータス「未配信」となっているテスト回次が存在しない、あるいは、受信済みのテスト計画情報１２５０そのものが存在しない場合には、次のテスト回次がないと判断し（ステップＳ６０５のＮＯ）、このときテスト計画による更新用ソフトウェアの配信は行われないため、処理を終了する。

ステップＳ６０６では、更新用ソフトウェア要求部２１３が、次のテスト回次に対応するテスト計画情報１２５０のレコードにおけるソフトウェアＩＤ１２５８から特定される更新用ソフトウェアの提供をテレマティクスセンタ１０に要求する（ステップＳ６０６）。なお、以下の説明では、上記受信済みのテスト計画を「実行テスト計画」と称する。

テレマティクスセンタ１０では、ステップＳ６０６の要求を受信すると（ステップＳ６１３）、更新用ソフトウェア配信部１１３が、指定されたソフトウェアＩＤ１２５８に基づいて、ソフトウェアＤＢ１２４から要求された更新用ソフトウェア（すなわち、実行テスト計画の更新用ソフトウェア）を抽出し、車両２０に送信する（ステップＳ６１４）。

ステップＳ６１４で送信された更新用ソフトウェアは、車両２０で受信されてダウンロードが開始され（ステップＳ６０７）、ダウンロードデータは記憶装置２１５に蓄積される（ステップＳ６０８）。そして、更新用ソフトウェアのダウンロードが完了すると、キャンペーン確認部２１２は、ダウンロード完了をテレマティクスセンタ１０に通知する（ステップＳ６０９）。

テレマティクスセンタ１０では、ステップＳ６０９のダウンロード完了通知を受信（受領）すると、テスト計画管理部１１４が、実行テスト計画のテスト計画情報１２５０に対してステータス１２５３を「ダウンロード完了」に更新し、テスト計画ＤＢ１２５に上書きする（ステップＳ６１５）。その後、テスト計画管理部１１４は、ステップＳ６１４で送信した更新用ソフトウェアのインストールの開始命令を車両２０に送信する（ステップＳ６１６）。

そして、ステップＳ６１６のインストール開始命令を受信（受領）すると（ステップＳ６１０）、車両２０のキャンペーン確認部２１２は、エンジンが停止状態（ＯＦＦ状態）になるまで、更新用ソフトウェアのインストール開始を待機する待機状態に移行する。キャンペーン確認部２１２は、エンジンＥＣＵ２４１から得られる情報を用いてエンジン停止を検知することができる。エンジンが停止した後の処理は図１５に示される。

なお、上記の説明では、更新用ソフトウェアの配信（ダウンロード）は、各テスト回次の前にそれぞれ行われるとしたが、処理の別例として、テスト計画単位で更新用ソフトウェアの配信（ダウンロード）を実行するようにしてもよい。

その場合、図１４の処理は、ステップＳ６０５において、前述のように次のテスト回次の有無を判断するのではなく、ステップＳ６０４でテスト計画情報１２５０を受信したか否かを判断する。そして、テレマティクスセンタ１０からテスト計画情報１２５０を受信した場合にのみ、ステップＳ６０６に進んで、テスト計画で配信予定の更新用ソフトウェア（同一のテスト計画ＩＤ１２５１を有するレコードで指定されたソフトウェアＩＤ１２５８によって特定される全ての更新用ソフトウェア）の提供をテレマティクスセンタ１０に要求する。

このように、テスト計画単位で複数の更新用ソフトウェアを一括してダウンロードしておけば、その後の各ソフトウェアのインストールタイミングにおいて、速やかにインストールを開始することができ、テストの準備時間を短縮する効果に期待できる。例えば、テスト走行中にダウンロードを行うことによって、ダウンロード完了を待つだけの時間が発生することを抑制でき、テスト車両の停止時（エンジン停止時）には速やかに次のソフトウェアのインストールを開始することができる。

次に、図１５を参照しながら、テスト計画に基づく更新用ソフトウェアのインストール処理を説明する。図１５に示した処理は、車両２０に搭載されているソフトウェア更新装置２１０のキャンペーン確認部２１２及びＥＣＵソフトウェア更新部２１４と、テレマティクスセンタ１０に搭載されている中央演算処理装置１１０のテスト計画管理部１１４とによって実行される。

図１５によればまず、車両２０のキャンペーン確認部２１２が、エンジンＥＣＵ２４１から得られる情報を用いてエンジン停止を検知する（ステップＳ７０１）。

ステップＳ７０１でエンジン停止を検知すると、キャンペーン確認部２１２は、次のテスト回次が存在するか否かを確認する（ステップＳ７０２）。具体的には例えば、現在のテスト計画のテスト計画情報１２５０を参照し、テスト回次１２５２に次回が存在するかを確認する。次のテスト回次が存在しなければ（ステップＳ７０２のＮＯ）、インストールすべき更新用ソフトウェアもないので、処理を終了する。

一方、ステップＳ７０２において次のテスト回次が存在する場合（ステップＳ７０２のＹＥＳ）、キャンペーン確認部２１２は、次回のテストに関する情報を入出力装置２３４に表示する（ステップＳ７０３）。

ここで、入出力装置２３４における表示画面について説明する。ステップＳ７０３において、操作者（例えばドライバ）に対する情報表示等の目的から、入出力装置２３４には、図１６に例示するような画面「テスト計画確認画面」が表示される。

図１６によれば、テスト計画確認画面１１００は入出力装置２３４に表示され、上から順に、表示領域１１０１，１１０２，１１０３，１１０４を有し、さらに表示領域１１０４の下部にボタン１１０５，１１０６を有している。

表示領域１１０１〜１１０３は、テスト計画における次回のテストに関する情報等を表示するために設けられ、主にテスト計画情報１２５０に記載された情報が表示される。

具体的には、表示領域１１０１の表示内容は、テスト車両ＶＩＮ１２５６及びＥＣＵ−ＩＤ１２５７から取得することができる。また、表示領域１１０３の表示内容は、テスト計画ＩＤ１２５１、テスト回次１２５２、テスト開始日時１２５４及びテスト終了日時１２５５（テスト期間）、ソフトウェアＩＤ１２５８等に対応している。なお、表示領域１１０３のソフトウェアＩＤに紐付いて表示された「更新タイプ」及び「後バージョン」は、ソフトウェアＩＤ「ＡＰＡ＿ｖｅｒ１３＿２」に基づいてソフトウェア情報１２４０（ソフトウェアＤＢ１２４）を参照することによって取得できる。

表示領域１１０２には、テストコースにおいて次回のテストが開始される位置（テスト開始位置）と、テスト車両の現在位置（車両位置）とが示される。テスト開始位置は、テスト計画情報１２５０のテスト開始位置１２５９から取得することができる。車両位置は、車両ＤＢ１２１に記憶された車両情報１２１０の位置１２１３から取得することができる。図１６の表示領域１１０２のように、数値データではなく情報を可視化して示すことにより、ドライバ等の操作者は、現在の状況を簡単に把握することができる。

表示領域１１０４には、更新用ソフトウェアのインストールについて、操作者（例えばドライバ）に許諾を求めるメッセージが表示されている。このメッセージへの回答として、ドライバは、ボタン１１０５の「はい」、またはボタン１１０６の「いいえ」を選択することにより、更新用ソフトウェアのインストールに対する許諾／不許可を与える。なお、表示領域１１０４に表示可能なメッセージは、図１６の例に限定されない。他にも例えば、次回のテストで配信予定の更新用ソフトウェアのダウンロードが完了していない場合に、「ダウンロード完了までお待ちください」のようなメッセージを表示する等してもよい。

図１５の説明に戻る。ステップＳ７０３でテスト計画確認画面が表示された後、キャンペーン確認部２１２は、ドライバの許諾が得られたか判断する（ステップＳ７０４）。具体的には、テスト計画確認画面１１００のボタン１１０５が選択された場合に、次回のテスト用の更新用ソフトウェアのインストール開始に対する許諾が得られたと判断し（ステップＳ７０４のＹＥＳ）、このとき、ステップＳ７０５に進む。一方、テスト計画確認画面１１００のボタン１１０６が選択された場合は、ドライバの許諾が得らえなかったと判断し（ステップＳ７０４のＮＯ）、処理を終了する。

次に、ステップＳ７０６では、キャンペーン確認部２１２は、自車両２０（テスト車両）の現在位置がテスト開始位置から距離Ｘ以内であるか確認する。ここでの「距離Ｘ」とは、テスト計画情報１２５０のテスト開始位置１２５９で厳密に指定された開始位置からの所定の許容範囲を規定するものであって、適当な距離が予め設定される。ステップＳ７０６において自車両２０の現在位置がテスト開始位置から距離Ｘを超えて離れていた場合には（ステップＳ７０６のＮＯ）、更新用ソフトウェアのインストールを開始可能な位置にいないことから、処理を終了する。一方、ステップＳ７０６において距離Ｘ以内であった場合は（ステップＳ７０６のＹＥＳ）、ステップＳ７０７に進む。

そして、ステップＳ７０７では、キャンペーン確認部２１２は、更新用ソフトウェアの対象ＥＣＵへのインストール開始をテレマティクスセンタ１０に通知する。ステップＳ７０７のインストール開始通知を受けて、テレマティクスセンタ１０では、テスト計画管理部１１４が、実行テスト計画のテスト計画情報１２５０に対してステータス１２５３を「インストール中」に更新し、テスト計画ＤＢ１２５に上書きする（ステップＳ７１１）。

また、インストール開始通知を送信した車両２０では、ＥＣＵソフトウェア更新部２１４が、対象ＥＣＵのソフトウェアインストールを実行し、当該ＥＣＵの記憶装置を上書きする（ステップＳ７０８）。その後、ＥＣＵソフトウェア更新部２１４は、対象ＥＣＵからインストール結果（更新の成否情報）を受け取り、受け取った更新の成否情報をテレマティクスセンタ１０に通知する（ステップＳ７０９）。

そして、ステップＳ７０９の通知を受けて、テレマティクスセンタ１０では、テスト計画管理部１１４が、実行テスト計画のテスト計画情報１２５０に対してステータス１２５３を「完了」に更新し、テスト計画ＤＢ１２５に上書きする（ステップＳ７１２）。

以上のように、図１４及び図１５に示した処理が正常に進行することによって、本実施の形態に係るソフトウェア配信システム１では、テスト計画による更新用ソフトウェアの配信（ダウンロード及びインストール）が完了し、これをもってテスト計画における次回のテストを実行可能な準備が整う。

以上に説明してきたように、第２の実施の形態に係るソフトウェア配信システム１では、複数回の更新用ソフトウェアの配信を必要とするようなテスト計画について、通常のキャンペーンよりも詳細な情報（テスト計画情報）を用いて、車載機器に対する更新用ソフトウェアの配信を管理することができる。

また、上記のようなテスト計画が実行されるテストコース等では、テスト時間の制約や、ソフトウェアに対する専門知識を持たないテストスタッフ（ドライバ等）が、テスト計画の進行に合わせて更新用ソフトウェアをテスト車両にインストールしなければならないといった難しさがあった。このような課題に対して、第２の実施の形態に係るソフトウェア配信システム１は、以下のような効果を奏する。

まず、第２の実施の形態では、テストの開始前にテスト計画を作成し、テスト計画内で更新されるソフトウェアをまとめて指定して登録できるようにしている（図１３参照）。このテスト計画の作成に関する操作は、テストコースに行く前に、専門知識を有するエンジニア等によって可能であるため、テストスタッフによる操作エラーを防止する効果に期待できる。また、テスト計画を作成において、第１の実施の形態におけるキャンペーンの作成と同様に過誤可能性判定処理を行うことも可能であることから、この場合、エンジニア等によるソフトウェアの選択ミスを防止することにも期待できる。

次に、第２の実施の形態では、テスト計画が作成された後、実際にテストを実施するテストコース等において、簡易な操作で複数の更新用ソフトウェアの配信（ダウンロード及びインストール）を実現できるようにしている（図１４、図１５参照）。

例えば、図１４に示したように、テスト計画における更新用ソフトウェアのダウンロードについては、テスト車両（車両２０）のエンジンの始動を契機として、自動的にテスト計画を検索したり（ステップＳ６０２〜Ｓ６０４、ステップＳ６１１〜Ｓ６１２）、次のテスト回次があった場合には、更新用ソフトウェアのダウンロードを自動的に実行したりすることができる（ステップＳ６０６〜Ｓ６０９、ステップＳ６１３〜Ｓ６１５）。このような処理が行われることによって、テストスタッフ（例えばドライバ）に専門的な判断を求めることなく、テスト走行をしている間に、次のテスト用の更新用ソフトウェアをダウンロードすることができ、人為的ミスの発生を抑制することができる。

また例えば、図１５に示したように、テスト計画における更新用ソフトウェアのインストールについては、テスト車両（車両２０）のエンジンの停止を契機として、テスト計画確認画面（図１６参照）に次回のテストに関する情報が表示され、インストール可能な条件が整った場合には、テストスタッフ（例えばドライバ）が当該画面を確認して「はい」を意味するボタン１１０５を選択すれば、次の更新用ソフトウェアのインストールがすぐに開始される。すなわち、テストコースにおいて、専門知識を有するエンジニアでなくとも、テスト計画の進行に応じて表示されるテスト計画確認画面を見ながら簡単な操作（「はい」または「いいえ」を選択するだけ）で、次のテスト用のソフトウェアの更新を行うことが可能となり、人為的ミスの発生を抑制することができる。

以上のように、第２の実施の形態では、人為的ミスの発生を抑制しつつ、テストコース等において簡易な操作で複数の更新用ソフトウェアの配信を実現することができるため、操作ミス等による再設定の発生を防止し、また、次のテストに向けた準備に要する時間を短縮する効果に期待できる。

また、第２の実施の形態では、テスト計画以外のキャンペーンについては第１の実施の形態と同様の取り扱いがなされることから、第１の実施の形態と同様に、新キャンペーンの作成依頼に対して、更新用ソフトウェアの選択ミスの可能性がないと判定した場合に限り、キャンペーン情報１２３０が作成・登録され、当該キャンペーンが作成される。また、更新用ソフトウェアの選択ミスの可能性があると判定した場合には、キャンペーン作成画面１０００で警告メッセージ（表示領域１００３）を示すことにより、指定したソフトウェアが誤っていないか確認・検討させることができる。かくして、第２の実施の形態に係るソフトウェア配信システム１は、人為的な選択ミスに起因してキャンペーンで誤った更新用ソフトウェアが配信されることを防止できる。

（３）その他
なお、第１及び第２の実施の形態で示した本発明は、設計開発工程といった販売前のフェーズにのみ適用可能ではなく、車両の販売後におけるＯＴＡ（Field Over The Air）にも適用可能である。具体的には例えば、車両のユーザが、機能追加や車両のチューニングを目的としてソフトウェアを選択・購入するような場合に、キャンペーンによって更新用ソフトウェアを配信するケースが想定でき、このようなキャンペーンについて本発明を適用することにより、キャンペーンの作成時に、操作者の本来の意図とは異なる選択による、ソフトウェアの選択ミスを抑制する効果を奏する。

また、本発明は、上記した実施の形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。具体的には例えば、ソフトウェア配信サーバであるテレマティクスセンタ１０が、表示機能を有する入出力装置を備え、端末３０の入出力装置３３０や車両２０（ナビゲーション端末２３０）の入出力装置２３４と同様の表示（キャンペーン作成画面やテスト計画確認画面）を行うようにする等してもよい。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実施には殆ど全ての構成が相互に接続されていると考えてもよい。

１ ソフトウェア配信システム
１０ テレマティクスセンタ
２０ 車両
３０ 端末
４０ ネットワーク
１１０ 中央演算処理装置
１１１ 車両管理部
１１２ キャンペーン管理部
１１３ 更新用ソフトウェア配信部
１１４ テスト計画管理部
１２０ 記憶装置
１２１ 車両ＤＢ
１２２ 車両構成ＤＢ
１２３ キャンペーンＤＢ
１２４ ソフトウェアＤＢ
１２５ テスト計画ＤＢ
１３０ 通信部
２１０ ソフトウェア更新装置
２１１ 中央演算処理装置
２１２ キャンペーン確認部
２１３ 更新用ソフトウェア要求部
２１４ ＥＣＵソフトウェア更新部
２１５ 記憶装置
２１６ 位置測位装置
２２０ 通信部
２３０ ナビゲーション端末
２３１ 中央演算処理装置
２３２ 更新情報表示部
２３３ 記憶装置
２３４ 入出力装置
２４１ エンジンＥＣＵ
２４２ 自動運転ＥＣＵ
３１０ 中央演算処理装置
３１１ キャンペーン情報入出力部
３２０ 記憶装置
３３０ 入出力装置
３４０ 通信部
１０００ キャンペーン作成画面
１１００ テスト計画確認画面
１２１０ 車両情報
１２２０ 車両構成情報
１２３０ キャンペーン情報
１２４０ 更新用ソフトウェア情報（ソフトウェア情報）
１２５０ テスト計画情報

Claims (15)

1. 車両の車載機器に対する機能のアップデートを制御するソフトウェア配信システムであって、
   前記機能のアップデートをキャンペーンで管理し、当該キャンペーンに基づくソフトウェアを当該キャンペーンの対象車両に遠隔で配信するソフトウェア配信サーバと、
   操作者による操作を受けて前記ソフトウェア配信サーバに対する入出力を行う端末と、
   前記車両に搭載され、前記ソフトウェア配信サーバから配信された前記ソフトウェアをダウンロードし、対象の車載機器にインストールするソフトウェア更新装置と、
   を備え、
   前記ソフトウェア配信サーバは、
   前記ソフトウェアを含む各種の情報を記憶する記憶部と、
   前記端末から前記キャンペーンのために必要な情報を受信し、前記受信した情報で構成されるキャンペーン情報を前記記憶部に登録することによって当該キャンペーンを作成するキャンペーン管理部と、
   前記キャンペーン管理部に登録された前記キャンペーン情報に従って、前記キャンペーンに基づく前記ソフトウェアを当該キャンペーンの対象車両に遠隔で配信するソフトウェア配信部と、
   を有し、
   前記端末の操作によって前記キャンペーンの作成が依頼されたとき、
   前記キャンペーン管理部が、前記依頼されたキャンペーンの対象となる前記車両の車載機器における直近の複数回のキャンペーンによる前記ソフトウェアの更新量の統計情報と、前記依頼されたキャンペーンによる前記ソフトウェアの更新量とを比較し、所定の条件を満たした場合には、前記依頼されたキャンペーンを作成せず、所定の警告を準備して前記端末に送信し、
   前記端末が、前記キャンペーン管理部から受信した前記所定の警告を所定の表示画面に表示する
   ことを特徴とするソフトウェア配信システム。
2. 前記端末は、前記所定の警告を表示した前記所定の表示画面において、前記依頼されたキャンペーンを作成するか否かを再度決定するための入力手段を合わせて表示し、
   前記入力手段によって前記依頼されたキャンペーンを作成する決定がなされた場合、前記キャンペーン管理部は当該キャンペーンを作成する
   ことを特徴とする請求項１に記載のソフトウェア配信システム。
3. 前記キャンペーン管理部が前記キャンペーンの作成を依頼されたときに用いる前記所定の条件とは、直近の複数回のキャンペーンによる前記ソフトウェアの更新量の前記統計情報に比べて、前記依頼されたキャンペーンによる前記ソフトウェアの更新量が乖離していることを判定するための条件である
   ことを特徴とする請求項１に記載のソフトウェア配信システム。
4. 前記ソフトウェアの更新量は、更新の前後におけるソフトウェアのファイルサイズまたはソースコードの行数の差分またはバイナリファイルと見なした時の差分ビットの量またはＥＣＵに書き込む際に更新されるＲＯＭのブロック数に基づいて算出される
   ことを特徴とする請求項１に記載のソフトウェア配信システム。
5. 複数の前記キャンペーンを段階的に実行するテスト計画について、
   前記ソフトウェア配信サーバは、
   前記端末から前記テスト計画のために必要な情報を受信し、前記受信した情報で構成されるテスト計画情報を前記記憶部に登録することによって当該テスト計画を作成するテスト計画管理部をさらに有し、
   前記ソフトウェア配信部は、前記テスト計画管理部に登録された前記テスト計画情報に従って、前記テスト計画に含まれる複数のキャンペーンに基づく前記ソフトウェアを当該テスト計画の対象車両に遠隔で配信し、
   前記テスト計画に基づいて前記ソフトウェアを配信された前記対象車両では、当該テスト計画に含まれるそれぞれのキャンペーンの実行前に、前記端末を介して当該キャンペーンに基づく前記ソフトウェアのインストールの実行についての許諾を操作者に求め、許諾が得られた場合に前記ソフトウェア更新装置が当該ソフトウェアのインストールを行う
   ことを特徴とする請求項１に記載のソフトウェア配信システム。
6. 前記テスト計画情報には、前記キャンペーン情報を構成する情報に加えて、前記テスト計画におけるテストの回次及び開始位置を示す情報が少なくとも含まれる
   ことを特徴とする請求項５に記載のソフトウェア配信システム。
7. 前記ソフトウェアのインストールの実行についての許諾を操作者に求める前記端末は、前記ソフトウェアが配信される前記対象車両に配置される
   ことを特徴とする請求項５に記載のソフトウェア配信システム。
8. 前記ソフトウェア配信部は、前記テスト計画の開始前に、当該テスト計画に含まれる複数のキャンペーンに基づく前記ソフトウェアを一括して当該テスト計画の対象車両に遠隔で配信する
   ことを特徴とする請求項５に記載のソフトウェア配信システム。
9. 車両の車載機器に対する機能のアップデートをキャンペーンで管理し、当該キャンペーンに基づくソフトウェアを当該キャンペーンの対象車両に遠隔で配信するソフトウェア配信サーバであって、
   前記ソフトウェアを含む各種の情報を記憶する記憶部と、
   前記キャンペーンのために必要な情報を端末から受信し、前記受信した情報で構成されるキャンペーン情報を前記記憶部に登録することによって当該キャンペーンを作成するキャンペーン管理部と、
   前記キャンペーン管理部に登録された前記キャンペーン情報に従って、前記キャンペーンに基づく前記ソフトウェアを当該キャンペーンの対象車両に遠隔で配信するソフトウェア配信部と、
   を備え、
   前記端末から前記キャンペーンを作成する依頼を受けたときに、
   前記キャンペーン管理部が、前記依頼されたキャンペーンの対象となる前記車両の車載機器における直近の複数回のキャンペーンによる前記ソフトウェアの更新量の統計情報と、前記依頼されたキャンペーンによる前記ソフトウェアの更新量とを比較して、所定の条件を満たした場合には、前記依頼されたキャンペーンを作成せず、所定の警告を準備して前記端末に送信する
   ことを特徴とするソフトウェア配信サーバ。
10. 前記キャンペーン管理部は、
    前記端末から前記キャンペーンを作成する依頼を受けたものの、前記依頼されたキャンペーンを作成せずに前記所定の警告を前記端末に送信した後、
    前記端末から、前記依頼されたキャンペーンを作成する旨の指示を改めて受けた場合には、当該キャンペーンを作成する
    ことを特徴とする請求項９に記載のソフトウェア配信サーバ。
11. 前記キャンペーン管理部が前記キャンペーンの作成を依頼されたときに用いる前記所定の条件とは、直近の複数回のキャンペーンによる前記ソフトウェアの更新量の前記統計情報に比べて、前記依頼されたキャンペーンによる前記ソフトウェアの更新量が乖離していると判定するための条件である
    ことを特徴とする請求項９に記載のソフトウェア配信サーバ。
12. 前記ソフトウェアの更新量は、更新の前後におけるソフトウェアのファイルサイズまたはソースコードの行数の差分またはバイナリファイルと見なした時の差分ビットの量またはＥＣＵに書き込む際に更新されるＲＯＭのブロック数に基づいて算出される
    ことを特徴とする請求項９に記載のソフトウェア配信サーバ。
13. 車両の車載機器に対する機能のアップデートを制御するソフトウェア配信システムによるソフトウェア配信方法であって、
    前記ソフトウェア配信システムは、
    前記機能のアップデートをキャンペーンで管理し、当該キャンペーンに基づくソフトウェアを当該キャンペーンの対象車両に遠隔で配信するソフトウェア配信サーバと、
    操作者による操作を受けて前記ソフトウェア配信サーバに対する入出力を行う端末と、
    前記車両に搭載され、前記ソフトウェア配信サーバから配信された前記ソフトウェアをダウンロードし、対象の車載機器にインストールするソフトウェア更新装置と、
    を有し、
    前記ソフトウェア配信サーバは、
    前記ソフトウェアを含む各種の情報を記憶する記憶部と、
    前記端末から前記キャンペーンのために必要な情報を受信し、前記受信した情報で構成されるキャンペーン情報を前記記憶部に登録することによって当該キャンペーンを作成するキャンペーン管理部と、
    前記キャンペーン管理部に登録された前記キャンペーン情報に従って、前記キャンペーンに基づく前記ソフトウェアを当該キャンペーンの対象車両に遠隔で配信するソフトウェア配信部と、
    を有し、
    前記端末の操作によって前記キャンペーンの作成が依頼されたとき、
    前記キャンペーン管理部が、前記依頼されたキャンペーンの対象となる前記車両の車載機器における直近の複数回のキャンペーンによる前記ソフトウェアの更新量の統計情報と、前記依頼されたキャンペーンによる前記ソフトウェアの更新量とを比較する比較ステップと、
    前記比較ステップにおいて所定の条件を満たした場合には、前記キャンペーン管理部が、前記依頼されたキャンペーンを作成せず、所定の警告を準備して前記端末に送信するキャンペーン非作成ステップと、
    前記キャンペーン非作成ステップを受けて、前記端末が、前記キャンペーン管理部から受信した前記所定の警告を所定の表示画面に表示する警告表示ステップと、
    を備えることを特徴とするソフトウェア配信方法。
14. 前記警告表示ステップにおいて、前記端末は、前記所定の警告を表示した前記所定の表示画面に、前記依頼されたキャンペーンを作成するか否かを再度決定するための入力手段を合わせて表示し、
    前記警告表示ステップの後、前記入力手段によって前記依頼されたキャンペーンを作成する決定がなされた場合に、前記キャンペーン管理部が当該キャンペーンを作成するキャンペーン作成ステップと、をさらに備える
    ことを特徴とする請求項１３に記載のソフトウェア配信方法。
15. 複数の前記キャンペーンを段階的に実行するテスト計画について、
    前記ソフトウェア配信サーバは、
    前記端末から前記テスト計画のために必要な情報を受信し、前記受信した情報で構成されるテスト計画情報を前記記憶部に登録することによって当該テスト計画を作成するテスト計画管理部をさらに有し、
    前記ソフトウェア配信部は、前記テスト計画管理部に登録された前記テスト計画情報に従って、前記テスト計画に含まれる複数のキャンペーンに基づく前記ソフトウェアを当該テスト計画の対象車両に遠隔で配信し、
    前記テスト計画に基づいて前記ソフトウェアを配信された前記対象車両では、当該テスト計画に含まれるそれぞれのキャンペーンの実行前に、前記端末を介して当該キャンペーンに基づく前記ソフトウェアのインストールの実行についての許諾を操作者に求め、許諾が得られた場合に前記ソフトウェア更新装置が当該ソフトウェアのインストールを行う
    ことを特徴とする請求項１３に記載のソフトウェア配信方法。
    
    

Images