JP7081223B2 - マスタ装置、マスタ、ソフトウェアの整合性を確認するための方法及びプログラム、車両 - Google Patents

Description

本発明は、マスタ装置、マスタ、ソフトウェアの整合性を確認するための方法及びプログラム、車両に関する。

特許文献１には、ＥＣＵのプログラムを、サーバから送信されたバージョンアッププログラムで更新するシステムが記載されている。特許文献１のシステムでは、ＥＣＵのプログラム同士のバージョンの不整合に起因する動作不良の発生を防止するため、プログラムの更新前に、プログラム更新対象のＥＣＵのバージョンアッププログラムと他のＥＣＵのプログラムとの依存関係情報を参照して、プログラムの更新可否を決定している。

特開２００９－５３９２０号公報

複数の車載機のプログラムにバージョンの不整合がある場合、予期しない車両制御が行われる可能性がある。特許文献１のシステムでは、プログラムの更新時に他のプログラムとの依存関係を確認しているが、プログラムの更新時に依存関係を確認するだけでは、予期しない車両制御を十分に排除できない可能性がある。

それ故に、本発明は、複数の車載機のソフトウェアのバージョン不整合に起因して予期しない車両制御が行われる可能性をより低減することができるマスタ装置等を提供することを目的とする。

本発明の一実施態様は、複数の車載機に接続されるマスタ装置であって、複数の車載機のソフトウェアのバージョンの許可された組み合わせを含む整合情報を記憶する記憶部と、複数の車載機のソフトウェアの切替指示を行う第１の指示部と、切替指示に応じた複数の車載機の切替後のソフトウェアのバージョン情報を取得する取得部と、取得部により取得されたバージョン情報と整合情報とを照合することにより、複数の車載機の切替後のソフトウェアのバージョンに整合性があるか否かを判定する判定部と、複数の車載機の切替後のソフトウェアのバージョンに整合性がないと判定されたことに基づいて、複数の車載機に対して、切替後のソフトウェアから切替前のソフトウェアに戻すよう指示する第２の指示部と、を備える。

本発明によれば、複数の車載機のソフトウェアのバージョン不整合に起因して予期しない車両制御が行われる可能性をより低減することが可能となる。

第１の実施形態に係る車両制御システムの概略構成を示すブロック図 図１に示した車両制御システムの機能ブロック図 図２に示した整合情報記憶部に記憶される整合テーブルの一例を示す図 第１の実施形態に係る車両制御システムにおいて、代表車載機が実行する整合性確認処理の一例を示すフローチャート 第２の実施形態に係る車両制御システムの機能ブロック図 第２の実施形態に係る車両制御システムにおいて、代表車載機が実行する整合性確認処理の一例を示すフローチャート 第３の実施形態に係る車両制御システムの背景を説明するための模式図 第３の実施形態に係る車両制御システムの機能ブロック図 第３の実施形態に係る車両制御システムにおいて、代表車載機が実行するソフトウェア取得処理の一例を示すフローチャート 第３の実施形態に係る車両制御システムにおいて、代表車載機が実行する整合性確認処理の一例を示すフローチャート

（概要）
本発明に係る車両制御システムでは、車両の電源がオンされるたびに、車両制御システムを構成する複数の車載機の１つがソフトウェアのバージョンの整合性を確認することにより、ソフトウェアのバージョン不整合に起因する予期しない車両制御が行われる可能性を低減する。

（第１の実施形態）
＜構成＞
図１は、第１の実施形態に係る車両制御システムの概略構成を示すブロック図である。

車両制御システム１００は、相互に通信可能な車載機Ａ～Ｄから構成され、車載機Ａ～Ｄのそれぞれの機能を組み合わせることにより、所定の車両制御を実現するシステムである。図１の例では、車両制御システム１００が４つの車載機Ａ～Ｄで構成されているが、車両制御システム１００を構成する車載機の数は４つに限定されない。車両制御システム１００が実現する所定の車両制御としては、例えば自動運転を挙げることができる。車載機Ａ～Ｄは、加速、減速、操舵など車両走行を制御するＥＣＵや、これらの車両走行を制御するＥＣＵを組み合わせて走行支援を行うＥＣＵに相当する。また、車載機Ａ～Ｄは、無線通信機１を介して外部サーバ２と通信可能である。尚、以下の説明においては、車両制御システムを構成する複数の車載機Ａ～Ｄのうちの１つである特定の車載機Ａを「代表車載機Ａ」という。

図２は、図１に示した車両制御システムの機能ブロック図であり、図３は、図２に示した整合情報記憶部に記憶される整合テーブルの一例を示す図である。

［代表車載機Ａ］
代表車載機Ａは、車両制御システム１００の制御機能を提供する車載機の１つであるが、車載機Ａ～Ｄのソフトウェアのバージョンの整合性確認処理においては、マスターデバイスとして機能する。代表車載機Ａは、車両の電源がオンされたことを契機として、車両制御システム１００を構成する全ての車載機Ａ～Ｄのソフトウェアのバージョンの整合性を確認する。代表車載機Ａは、ソフトウェア記憶部１０と、整合情報記憶部１１と、バージョン取得部１２と、判定部１３と、送信部１４と、受信部１５と、整合情報更新部１６と、更新指示部１７とを備える。

ソフトウェア記憶部１０は、代表車載機Ａを動作させるためのソフトウェアを記憶する。代表車載機Ａは、ソフトウェア記憶部１０に記憶されたソフトウェアを実行することにより、車両の動作を制御するための所定の機能を実現する。

整合情報記憶部１１は、車両制御システム１００を構成する全ての車載機Ａ～Ｄのソフトウェアのバージョンの組み合わせを定義した整合テーブルを予め記憶する。整合テーブルに定義される車載機Ａ～Ｄのソフトウェアのバージョンの組み合わせは、車両制御シス
テム１００が正常に動作することが確認されており、同時に実行することが許可されたバージョンの組み合わせである。例えば、整合テーブルは、図３に示すように、車両制御システム１００を特定するシステム番号と、車載機Ａ～Ｄのそれぞれのソフトウェアのバージョンとを含むことができる。システム番号としては、車両制御システム１００を特定するための識別子を用いても良いし、車両制御システム１００のバージョンを用いても良い。また、図３の整合テーブルの例では、各車載機のバージョンとして単一のバージョンが定義されているが、組み合わせ可能な各車載機のバージョンの範囲を定義しても良い。また、整合テーブルには、同時に実行することが許可されるバージョン（またはバージョンの範囲）の組み合わせを複数セット定義しても良い。１つの車載機が複数のソフトウェアを保持している場合、整合テーブルには、複数のソフトウェアのそれぞれの許可されたバージョンが定義される。整合テーブルは、後述する判定部１３が車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを判定するための整合情報（第１の整合情報）として使用される。

バージョン取得部１２は、車両の電源がオンされるたびに、通信により他の車載機Ｂ～Ｄのそれぞれのソフトウェアのバージョンを取得する。車載機Ｂ～Ｄの中に複数のソフトウェアを保持している車載機がある場合、バージョン取得部１２は、車載機が保持する全てのソフトウェアのバージョンを取得する。

判定部１３は、バージョン取得部１２によって他の車載機Ｂ～Ｄからソフトウェアのバージョンが取得されるたびに、車両制御システム１００を構成する全ての車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを判定する。この判定は、判定部１３が、代表車載機Ａのソフトウェア記憶部１０に記憶されソフトウェアのバージョンと、バージョン取得部１２が他の車載機Ｂ～Ｄから取得したソフトウェアのバージョンとを、整合情報記憶部１１に記憶される整合情報と照合することにより行う。判定部１３は、整合情報記憶部１１に記憶される整合テーブルに基づいて、車両制御システム１００を構成する全ての車載機Ａ～Ｄのソフトウェアのバージョンに整合性があると判定した場合は、車載機Ａ～Ｄの機能を組み合わせにより実現される所定の車両制御の実行を許可する。

送信部１４は、判定部１３により車両制御システム１００を構成する全ての車載機Ａ～Ｄのソフトウェアのバージョンに整合性がないと判定された場合に、車載機Ａ～Ｄのソフトウェアのバージョンを含むバージョン情報を外部サーバ２へと送信する。送信部１４によって送信されたバージョン情報は、外部サーバ２において、車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを再度確認するために用いられる。

受信部１５は、外部サーバ２から送信された各種情報を受信する。受信部１５が外部サーバ２から受信する情報の１つとして判定結果情報がある。判定結果情報は、車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを表す情報であり、外部サーバ２が送信部１４から受信したバージョン情報に基づいて判定を行うことにより得ることができる。

尚、送信部１４及び受信部１５は、図１に示した無線通信機１を介して外部サーバ２との通信を行う。

整合情報更新部１６は、受信部１５が受信した判定結果情報が、車載機Ａ～Ｄのソフトウェアのバージョンに整合性があることを示す場合、整合情報記憶部１１に記憶される整合情報を更新する。整合情報の更新は、整合情報更新部１６が、整合情報記憶部１１に記憶される整合テーブル（第１の整合情報）に含まれるソフトウェアのバージョンの組み合わせを、現在の車載機Ａ～Ｄのソフトウェアのバージョンの組み合わせで置き換えたり、整合情報記憶部１１に記憶される整合テーブルに、現在の車載機Ａ～Ｄのソフトウェアの
バージョンの組み合わせを追加したりすることによって行うことができる。整合情報更新部１６は、更新された整合テーブルを外部サーバ２から取得し、整合情報記憶部１１に記憶される整合テーブルを外部サーバ２から取得した整合テーブルで置き換えることによって行っても良い。

更新指示部１７は、受信部１５が受信した判定結果情報が、車載機Ａ～Ｄのソフトウェアのバージョンに整合性がないことを示す場合、許可されたバージョンの組み合わせに整合していないソフトウェアを保持する車載機に対して、ソフトウェアの更新を指示する。

［車載機Ｂ～Ｄ］
車載機Ｂ～Ｄは、ソフトウェア記憶部２０と、送信部２１と、受信部２２とを備える。

ソフトウェア記憶部２０は、車載機Ｂ～Ｄのそれぞれを動作させるためのソフトウェアを記憶する。車載機Ｂ～Ｄは、ソフトウェア記憶部１０に記憶されたソフトウェアを実行することにより、それぞれ、車両の動作を制御するための所定の機能を実現する。

送信部２１は、ソフトウェア記憶部２０に記憶されているソフトウェアのバージョンを代表車載機Ａに送信する。送信部２１は、車両の電源がオンされたことを契機としてソフトウェアのバージョンを代表車載機Ａに送信しても良いし、車両の電源がオンされたことを契機として送信された代表車載機Ａからの要求に応答して、ソフトウェアのバージョンを代表車載機Ａに送信しても良い。

受信部２２は、代表車載機Ａまたは外部サーバ２から送信された各種情報を受信する。

［外部サーバ２］
外部サーバ２は、整合情報記憶部３０と、判定部３１と、送信部３２と、受信部３３とを備える。

整合情報記憶部３０は、車両制御システム１００を構成する全ての車載機Ａ～Ｄのソフトウェアのバージョンの組み合わせを定義した整合テーブルを予め記憶する。整合テーブルに定義される車載機Ａ～Ｄのソフトウェアのバージョンの組み合わせは、車両制御システム１００が正常に動作することが確認されており、同時に実行することが許可された組み合わせである。整合情報記憶部３０に記憶する整合テーブルには、図３に例示したものと同様に、車両制御システム１００を特定するシステム番号と、車載機Ａ～Ｄのそれぞれのソフトウェアのバージョンとを含めることができる。整合テーブルは、後述する判定部３１が車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを判定するための整合情報（第２の整合情報）として使用される。

判定部３１は、車両制御システム１００を構成する全ての車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを判定する。この判定は、判定部３１が、代表車載機Ａから受信したバージョン情報に含まれる車載機Ａ～Ｄのソフトウェアのバージョンを、整合情報記憶部３０に記憶される整合テーブルと照合することにより行う。外部サーバ２では、車載機Ａ～Ｄの全てのバージョンのソフトウェアを管理することができる。したがって、整合情報記憶部３０に記憶される整合テーブルには、代表車載機Ａの整合情報記憶部１１に記憶される整合テーブルと比べて、車載機Ａ～Ｄのソフトウェアのバージョンの許可された組み合わせをより多く定義可能である。したがって、代表車載機Ａにおいてソフトウェアのバージョンの整合性確認ができなかった場合でも、外部サーバ２で再度判定を行うことにより、車載機Ａ～Ｄのソフトウェアのバージョンの整合性を精度良く判定することができる。

送信部３２は、判定部３１の判定結果である、車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを表す判定結果情報を代表車載機Ａに送信する。

受信部３３は、代表車載機Ａから送信された各種情報を受信する

＜制御処理＞
以下、図２及び図４を併せて参照しながら、代表車載機Ａが実行する制御処理を説明する。

図４は、第１の実施形態に係る車両制御システムにおいて、代表車載機が実行する整合性確認処理の一例を示すフローチャートである。図４に示す制御処理は、車両の電源がオンされたことを契機として実行される。

ステップＳ１：バージョン取得部１２は、他の車載機Ｂ～Ｄのソフトウェアのバージョンを取得する。その後、処理はステップＳ２に移る。

ステップＳ２：判定部１３は、代表車載機Ａのソフトウェアのバージョンと、他の車載機Ｂ～Ｄから取得したソフトウェアのバージョンとを、整合情報記憶部１１に記憶される整合テーブルと照合し、車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを判定する。ステップＳ２の判定がＹＥＳの場合、処理はステップＳ３に移り、それ以外の場合、処理はステップＳ４に移る。

ステップＳ３：判定部１３は、車載機Ａ～Ｄを組み合わせて用いた車両制御の実行を許可する。その後、処理を終了する。

ステップＳ４：送信部１４は、代表車載機Ａのソフトウェアのバージョンと、他の車載機Ｂ～Ｄから取得したソフトウェアのバージョンとを含むバージョン情報を外部サーバ２に送信する。その後、処理はステップＳ５に移る。

ステップＳ５：受信部１５は、外部サーバ２から判定結果情報を受信したか否かを判定する。ステップＳ５の判定がＹＥＳの場合、処理はステップＳ６に移り、それ以外の場合、所定時間待機してから再度ステップＳ５の判定を行う。尚、ステップＳ５において、受信部１５が外部サーバ２から判定結果情報を受信できない状態が予め定められた時間（タイムアウト時間）継続した場合、受信部１５は、タイムアウトと判定してステップＳ５の処理を終了し、処理はステップＳ６に進む。

ステップＳ６：判定部１３は、外部サーバ２から受信した判定結果情報に基づき、車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを判定する。ステップＳ６の判定がＹＥＳの場合、処理はステップＳ７に移り、それ以外の場合、処理はステップＳ９に移る。尚、ステップＳ５において、受信部１５がタイムアウトと判定した場合は、ステップＳ６において、車載機Ａ～Ｄのソフトウェアのバージョンに整合性がないと判定する。

ステップＳ７：判定部１３は、車載機Ａ～Ｄを組み合わせて用いた車両制御の実行を許可する。その後、処理はステップＳ８に移る。

ステップＳ８：整合情報更新部１６は、整合情報記憶部１１に記憶される整合テーブルを更新する。上述した通り、整合テーブルは、ステップＳ２の判定に用いたソフトウェアのバージョンを用いて更新しても良いし、受信部１５を介して外部サーバ２から取得した整合テーブルを用いて更新しても良い。その後、処理を終了する。

ステップＳ９：判定部１３は、車載機Ａ～Ｄを組み合わせて用いた車両制御の実行を禁止する。その後、処理はステップＳ１０に移る。

ステップＳ１０：更新指示部１７は、整合情報記憶部１１に記憶される整合テーブルと整合しないバージョンのソフトウェアを保持する車載機に対して、ソフトウェアの更新を指示する。その後、処理を終了する。

尚、更新指示部１７がソフトウェアの更新を指示した場合、更新対象の車載機がサーバ２から更新されたソフトウェアの受信を完了した時点で、実行対象とするソフトウェアを現在のバージョンのソフトウェアから更新されたソフトウェアに切り替えるために、車両の電源を一旦オフした後、再度電源をオンするように、ユーザに促しても良い。

また、ステップＳ１０の更新指示に基づいていずれかの車載機のソフトウェアが更新された場合、整合情報更新部１６は、必要に応じて整合情報記憶部１１に記憶される整合テーブルを更新しても良い。

＜効果等＞
本実施形態に係る車両制御システム１００では、車両の電源がオンされたことを契機として、代表車載機Ａが車載機Ｂ～Ｄのソフトウェアのバージョンを取得し、予め用意された整合テーブルに基づいて、車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを判定する。車両の電源がオンされるたびにソフトウェアのバージョンの整合性が確認されるため、車載機Ａ～Ｄのソフトウェアのバージョンに不整合があることに起因して予期しない車両制御が実行される可能性をより低減することができる。

また、本実施形態に係る車両制御システム１００では、代表車載機Ａによるソフトウェアのバージョンの整合性チェック（一次チェック）で整合性がないと判定された場合には、車載機Ａ～Ｄのソフトウェアのバージョンを外部サーバ２に送信し、外部サーバ２が保持する整合テーブルを用いて、ソフトウェアのバージョンの整合性チェックを再度行う（二次チェック）。代表車載機Ａが保持する情報で整合性を確認できなかった場合でも、外部サーバ２が保持する情報を利用して再度の整合性チェックを行うことにより、車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かをより精度良く判定することができる。

また、本実施形態に係る車両制御システム１００では、車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かの判定を、予め用意された整合テーブルとの照合により行うため、照合の結果、どの車載機のソフトウェアのバージョンが整合テーブルと不整合であるかを特定することができる。整合テーブルと不整合である車載機を特定した情報は、ソフトウェアの更新や車載機の修理等に利用することができるので、ソフトウェアのバージョンに整合性がない状態を早期に改善することが可能となる。

また、本実施形態に係る車両制御システム１００では、代表車載機Ａにより車載機Ａ～Ｄのソフトウェアのバージョンに整合性がないと判定された後、外部サーバ２により車載機Ａ～Ｄのソフトウェアのバージョンに整合性があると判定された場合には、代表車載機Ａの整合性情報記憶部１１に記憶される整合テーブルを更新することが可能である。整合性情報記憶部１１に記憶される整合テーブルを更新しておけば、車載機Ａ～Ｄのソフトウェアが変更されない限り、次に車両の電源がオンされた際に代表車載機Ａだけでソフトウェアのバージョンの整合性を確認することができるので、整合性の確認に要する時間を短縮することができる。

尚、図２に示した代表車載機Ａの機能ブロックのうち、ソフトウェア記憶部１０と、整合情報記憶部１１と、バージョン取得部１２と、判定部１３のみで代表車載機Ａを構成し、車両の電源がオンされたことを契機として、車載機Ａ～Ｄのソフトウェアのバージョンの整合性のみを判定可能なシンプルな車両制御システムを構成することも可能である。この構成に更に、送信部１４及び受信部１５を追加し、代表車載機Ａにおける一次チェックと外部サーバ２における二次チェックが可能な車両制御システムを構成しても良い。また、図２に示した代表車載機Ａの機能ブロックのうち、整合情報更新部１６または更新指示部１７を省略した車両制御システムを構成しても良い。

（第２の実施形態）
＜構成＞
図５は、第２の実施形態に係る車両制御システムの機能ブロック図である。

第２の実施形態に係る車両制御システム２００は、代表車載機Ａによって車載機Ａ～Ｄのソフトウェアのバージョンに整合性がないと判定された後、代表車載機Ａと外部サーバ２とが通信できない状態にある場合でも、車載機Ａ～Ｄのソフトウェアのバージョンの整合性を確保できる点に特徴を有する。以下では、本実施形態と第１の実施形態との相異点を中心に説明する。

［代表車載機Ａ］
代表車載機Ａのソフトウェア記憶部１０には、代表車載機Ａを動作させるためのソフトウェアとして、現在のバージョンのソフトウェアＳａ＿ｃｕｒと、旧バージョンのソフトウェアＳａ＿ｏｌｄとが記憶されている。現在のバージョンのソフトウェアＳａ＿ｃｕｒ及び旧バージョンのソフトウェアＳａ＿ｏｌｄは、ソフトウェア記憶部１０の異なる記憶領域に記憶されており、ソフトウェアの更新時には、旧バージョンのソフトウェアＳａ＿ｏｌｄが削除され、現在のバージョンのソフトウェアが旧バージョンのソフトウェアとして保持され、更新されたソフトウェアが現在のバージョンのソフトウェアとして新たに記憶される。

整合情報記憶部１１には、整合情報として、現在のバージョンの整合テーブルＴ＿ｃｕｒと、旧バージョンの整合テーブルＴ＿ｏｌｄとが記憶されている。整合情報の更新時には、旧バージョンの整合テーブルＴ＿ｏｌｄが削除され、現在のバージョンの整合テーブルが旧バージョンの整合テーブルとして保持され、更新された整合テーブルが現在のバージョンの整合テーブルとして新たに記憶される。

代表車載機Ａは、切替指示部１８とソフトウェア切替部１９とを更に備える。

切替指示部１８は、判定部１３によって車載機Ａ～Ｄのソフトウェアのバージョンに整合性がないと判定され、かつ、代表車載機Ａが外部サーバ２とが通信できない状態にある場合に、車載機Ａ～Ｄのそれぞれに対し、実行対象とするソフトウェアを現在のバージョンのソフトウェアから旧バージョンのソフトウェアに切り替えるよう指示する。切替指示部１８が車載機Ａ～Ｄに対してソフトウェアの切り替えを指示した場合、表示部への表示や音声により、ソフトウェアを旧バージョンのバージョンに切り替える旨をユーザに通知しても良い。

ソフトウェア切替部１９は、切替指示部１８によってソフトウェアの切替指示が行われた場合、実行対象とするソフトウェアを現在のバージョンのソフトウェアＳａ＿ｃｕｒから旧バージョンのソフトウェアＳａ＿ｏｌｄに切り替えると共に、判定部１３が使用する整合情報を現在のバージョンの整合テーブルＴ＿ｃｕｒから旧バージョンの整合テーブルＴ＿ｏｌｄへと切り替える。ソフトウェア切替部１９によるソフトウェアの切り替えは、
次に車両の電源がオンされたことを契機として、車載機Ａ～Ｄのソフトウェアのバージョンの整合性を確認する処理の前に実行する。

尚、切替指示部１８によりソフトウェアの切り替え指示が行われた場合、次に車両の電源がオンされたことを契機として、バージョン取得部１２及び判定部１３により、車載機Ａ～Ｄのソフトウェアのバージョンの整合性が確認される。バージョン取得部１２及び判定部１３が実行する処理は、電源がオンされた場合の通常時の処理と同じであるが、結果として、バージョン取得部１２は、他の車載機Ｂ～Ｄから切り替え後のソフトウェアのバージョンを取得し、判定部１３は、代表車載機Ａの切り替え後のソフトウェアのバージョンと、他の車載機Ｂ～Ｄから取得した切り替え後のソフトウェアのバージョンとを、旧バージョンの整合テーブルと照合することにより、ソフトウェアのバージョンの整合性が確認される。

［車載機Ｂ～Ｄ］
車載機Ｂ、Ｃ及びＤのソフトウェア記憶部２０には、車載機Ｂ、Ｃ及びＤを動作させるためのソフトウェアとして、現在のバージョンのソフトウェアＳｂ＿ｃｕｒ、Ｓｃ＿ｃｕｒ及びＳｄ＿ｃｕｒと、旧バージョンのソフトウェアＳｂ＿ｏｌｄ、Ｓｃ＿ｏｌｄ及びＳｄ＿ｏｌｄとがそれぞれが記憶されている。車載機Ｂ～Ｄにおいても、現在のバージョンのソフトウェア及び旧バージョンのソフトウェアは、ソフトウェア記憶部２０の異なる記憶領域に記憶されており、ソフトウェアの更新時には、旧バージョンのソフトウェアが削除され、更新されたソフトウェアが現在のバージョンのソフトウェアとして新たに記憶され、現在のバージョンのソフトウェアが旧バージョンのソフトウェアとして保持される。旧バージョンのソフトウェアＳａ＿ｏｌｄ～Ｓｄ＿ｏｌｄは、現在のバージョンのソフトウェアＳａ＿ｃｕｒ～Ｓａ＿ｃｕｒの前に使用されていたソフトウェアの組み合わせであって、バージョンの整合性が取れているソフトウェアの組み合わせである。

また、車載機Ｂ～Ｄの各々は、ソフトウェア切替部２３を更に備える。ソフトウェア切替部２３は、切替指示部１８によってソフトウェアの切替指示が行われた場合、実行対象とするソフトウェアを現在のバージョンのソフトウェアＳｂ＿ｃｕｒ、Ｓｃ＿ｃｕｒ及びＳｄ＿ｃｕｒから、旧バージョンのソフトウェアＳｂ＿ｏｌｄ、Ｓｃ＿ｏｌｄ及びＳｄ＿ｏｌｄにそれぞれ切り替える。ソフトウェア切替部２３によるソフトウェアの切り替えも、次に車両の電源がオンされたことを契機として、車載機Ａ～Ｄのソフトウェアのバージョンの整合性を確認する処理の前に実行する。

＜制御処理＞
以下、図５及び図６を併せて参照しながら、代表車載機Ａが実行する制御処理を説明する。

図６は、第２の実施形態に係る車両制御システムにおいて、代表車載機が実行する整合性確認処理の一例を示すフローチャートである。図６に示す制御処理は、車両の電源がオンされたことを契機として実行される。

ステップＳ２１：ソフトウェア切替部１９は、車両の電源がオンされる前に、ソフトウェアの切替指示が行われていたか否かを判定する。このステップＳ２１は、後述するステップＳ２８において、車載機Ａ～Ｄの現在のバージョンのソフトウェアを旧バージョンのソフトウェアに切り替える指示が行われた場合に、当該指示がおこなわれた後の、最初の電源オンを契機としてソフトウェアの切り替えを行うために必要な判定である。車両の電源がオンされる前にソフトウェアの切替指示が行われたことは、不揮発性の記憶領域に立てられたフラグ等により判定することができる。ステップＳ２１の判定がＹＥＳの場合、処理はステップＳ２２に移り、それ以外の場合、処理はステップＳ２３に移る。

ステップＳ２２：ソフトウェア切替部１９は、ステップＳ２１でソフトウェアの切替指示があると判定された場合、実行対象とするソフトウェアを現在のバージョンのソフトウェアＳａ＿ｃｕｒから旧バージョンのソフトウェアＳａ＿ｏｌｄに切り替える。また、ソフトウェア切替部１９は、判定部１３が使用する整合情報を現在の整合テーブルＴ＿ｃｕｒから旧バージョンの整合テーブルＴ＿ｏｌｄへと切り替える。

尚、図示を省略しているが、ソフトウェアの切替を指示された他の車載機においても、代表車載機Ａにおいてソフトウェアが切り替えられるのと同じタイミングで並行して、ソフトウェア切替部２３が実行対象とするソフトウェアを現在のバージョンのソフトウェアから、旧バージョンのソフトウェアに切り替える。

ステップＳ２３：バージョン取得部１２は、他の車載機Ｂ～Ｄのソフトウェアのバージョンを取得する。その後、処理はステップＳ２４に移る。

ステップＳ２４：判定部１３は、代表車載機Ａのソフトウェアのバージョンと、他の車載機Ｂ～Ｄから取得したソフトウェアのバージョンとを、整合情報記憶部１１に記憶される整合テーブルと照合し、車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを判定する。ステップＳ２４の判定がＹＥＳの場合、処理はステップＳ２５に移り、それ以外の場合、処理はステップＳ２６に移る。

ステップＳ２５：判定部１３は、車載機Ａ～Ｄを組み合わせて用いた車両制御の実行を許可する。その後、処理を終了する。

ステップＳ２６：送信部１４は、外部サーバ２と通信可能であるか否かを判定する。外部サーバ２と通信可能であるか否かは、例えば、受信部１５が受信している無線信号の信号強度に基づいて判定することができる。ステップＳ２６の判定がＹＥＳの場合、処理はステップＳ２９に移り、それ以外の場合、処理はステップＳ２７に移る。

ステップＳ２７：判定部１３は、車載機Ａ～Ｄを組み合わせて用いた車両制御の実行を禁止する。その後、処理はステップＳ２８に移る。

ステップＳ２８：切替指示部１８は、現在のバージョンのソフトウェアから旧バージョンのソフトウェアへの切り替えが必要な車載機に対して、現在のバージョンのソフトウェアを旧バージョンのソフトウェアに切り替えるよう指示する。その後、処理を終了する。

尚、切替指示部１８が車載機Ａ～Ｄに対してソフトウェアに切り替えを指示した場合、代表車載機Ａは、ソフトウェアの切り替えを行う旨をユーザに通知しても良い。また、代表車載機Ａは、ソフトウェアの切替処理の準備が完了した時点で、車両の電源を一旦オフした後、再度オンするように、ユーザに促しても良い。

ステップＳ２９：送信部１４は、代表車載機Ａのソフトウェアのバージョンと、他の車載機Ｂ～Ｄから取得したソフトウェアのバージョンとを含むバージョン情報を外部サーバ２に送信する。その後、処理はステップＳ３０に移る。

ステップＳ３０：受信部１５は、外部サーバ２から判定結果情報を受信したか否かを判定する。ステップＳ３０の判定がＹＥＳの場合、処理はステップＳ３１に移り、それ以外の場合、所定時間待機してから再度ステップＳ３０の判定を行う。尚、ステップＳ３０において、受信部１５が外部サーバ２から判定結果情報を受信できない状態が予め定められた時間（タイムアウト時間）継続した場合、受信部１５は、タイムアウトと判定してステ
ップＳ３０の処理を終了し、処理はステップＳ３１に進む。

ステップＳ３１：判定部１３は、外部サーバ２から受信した判定結果情報に基づき、車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを判定する。ステップＳ３１の判定がＹＥＳの場合、処理はステップＳ３２に移り、それ以外の場合、処理はステップＳ３４に移る。尚、ステップＳ３０において、受信部１５がタイムアウトと判定した場合は、ステップＳ３１において、車載機Ａ～Ｄのソフトウェアのバージョンに整合性がないと判定する。

ステップＳ３２：判定部１３は、車載機Ａ～Ｄを組み合わせて用いた車両制御の実行を許可する。その後、処理はステップＳ３３に移る。

ステップＳ３３：整合情報更新部１６は、整合情報記憶部１１に記憶される整合情報を更新する。その後、処理を終了する。

ステップＳ３４：判定部１３は、車載機Ａ～Ｄを組み合わせて用いた車両制御の実行を禁止する。その後、処理はステップＳ３５に移る。

ステップＳ３５：更新指示部１７は、整合情報記憶部１１に記憶される整合テーブルと整合しないバージョンのソフトウェアを保持する車載機に対して、ソフトウェアの更新を指示する。その後、処理を終了する。

尚、更新指示部１７がソフトウェアの更新を指示した場合、更新対象の車載機がサーバ２から更新されたソフトウェアの受信を完了した時点で、実行対象とするソフトウェアを現在のバージョンのソフトウェアから更新されたソフトウェアに切り替えるために、車両の電源を一旦オフした後、再度電源をオンするように、ユーザに促しても良い。

＜効果等＞
本実施形態に係る車両制御システム２００では、第１の実施形態と同様に、車両の電源がオンされたことを契機として車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを判定するため、車載機Ａ～Ｄのソフトウェアのバージョン不整合により、予期しない車両制御が実行される可能性をより低減することができる。

これに加えて、本実施形態に係る車両制御システム２００では、各車載機が旧バージョンのソフトウェアを保持すると共に、代表車載機Ａが旧バージョンの整合テーブルを保持している。したがって、代表車載機Ａによって車載機Ａ～Ｄのソフトウェアのバージョンに整合性がないと判定されたが、代表車載機Ａと外部サーバ２とが通信できない状態にある場合には、旧バージョンのソフトウェアに切り替えることができる。この構成によれば、最新のソフトウェアのバージョンに整合性がなく、代表車載機Ａが外部サーバと通信できない場合でも、車載機Ａ～Ｄのソフトウェアのバージョンに整合性を確保することが可能となる。

尚、図５に示した代表車載機Ａの機能ブロックのうち、整合情報更新部１６または更新指示部１７を省略した車両制御システムを構成しても良い。

（第３の実施形態）
＜構成＞
図７は、第３の実施形態に係る車両制御システムの背景を説明するための模式図である。

車両制御システム３００を構成する車載機Ａ～ＤのソフトウェアのバージョンＳａ～Ｓｄは、車両の出荷時には整合が取れた状態となっている（図７の左欄）。車載機Ａ～Ｄのソフトウェアのバージョンの整合性が崩れる原因として、車載機Ａ～Ｄの交換や、車載機Ａ～Ｄに含まれる基板等の部品の交換によるバージョンずれが考えられる。例えば、車載機Ｃが故障し（図７の中央欄）、故障した車載機Ｃを新しい物と交換した結果、新しい車載機ＣのソフトウェアＳｃ’のバージョンが、交換前のソフトウェアＳｃのバージョンから変わってしまう場合がある（図７の右欄）。この場合、新しい車載機ＣのソフトウェアのバージョンＳｃ’は、必ずしも車載機Ａ、Ｂ及びＤのソフトウェアのバージョンと整合しているとは限らず、また、ソフトウェアＳｃ’のバージョンによっては、代表車載機Ａによる整合性確認処理だけ車載機Ａ～Ｄのソフトウェアの整合性を確認できないことも考えられる。地下や山間部等の無線通信環境が整っていない場所で車両が使用される場合には、外部サーバとの通信により整合性確認を行うことができないため、車載機Ａ～Ｄの組み合わせで実現される車両制御機能が制限されたり、ソフトウェアの更新に時間を要したりすることが想定され、ユーザの利便性が低下する可能性がある。

このような問題を想定し、第３の実施形態に係る車両制御システムでは、車載機Ａ～Ｄの修理や交換が必要となった場合でも速やかに車載機Ａ～Ｄのソフトウェアのバージョンの整合性を確保できる点に特徴を有する。以下、本実施形態と第１の実施形態との相異点を中心に説明する。

図８は、第３の実施形態に係る車両制御システムの機能ブロック図である。

［代表車載機Ａ］
代表車載機Ａは、第１の実施形態で説明したソフトウェア記憶部１０と、整合情報記憶部１１と、バージョン取得部１２と、判定部１３と、送信部１４と、受信部１５とに加えて、ソフトウェア取得部４０と、ソフトウェア更新部４１とを備える。

ソフトウェア取得部４０は、他の車載機Ｂ～Ｄのいずれかが故障して交換または修理が必要となった場合に、外部サーバ２と通信が可能である間に、外部サーバ２から故障した車載機の現在のバージョンのソフトウェアを受信して記憶する。ソフトウェア取得部４０は、車載機Ｂ～Ｄのいずれかに故障が発生したことを、故障した車載機から出力される故障通知により検出することができる。図７及び図８では、車載機Ｃが故障した例を示しているが、ソフトウェア取得部４０は、車載機Ａ、Ｂ及びＤのソフトウェアＳａ、Ｓｂ及びＳｄのバージョンと整合していた、車載機ＣのソフトウェアＳｃを外部サーバ２から取得して記憶している。ソフトウェア取得部４０が外部サーバ２から取得するソフトウェアのバージョンは、故障した車載機Ｃから通信により取得しても良いし、整合情報記憶部１１に記憶されている整合テーブルから取得しても良い。

ソフトウェア更新部４１は、故障した車載機の交換または修理後に、判定部１３によって、車載機Ａ～Ｄのソフトウェアのバージョンに整合性がないと判定され、かつ、整合テーブルに整合していないと判定されたバージョンのソフトウェアを保持する車載機が、交換または修理された車載機であると判定された場合に、交換または修理された車載機のソフトウェア記憶部２０に、ソフトウェア取得部４０によって記憶されるソフトウェアを書き込む。その後、ソフトウェア更新部４１は、交換または修理された車載機に対して、ソフトウェアの切り替えを指示する。

尚、ソフトウェア更新部４１によりソフトウェアの切り替え指示が行われた場合、次に車両の電源がオンされたことを契機として、バージョン取得部１２及び判定部１３により、車載機Ａ～Ｄのソフトウェアのバージョンの整合性が確認される。バージョン取得部１２及び判定部１３が実行する処理は、電源がオンされた場合の通常時の処理と同じである
。

［車載機Ｂ～Ｄ］
また、車載機Ｂ～Ｄの各々は、第２の実施形態で説明したものと同様の、ソフトウェア切替部２３を更に備える。ソフトウェア切替部２３は、ソフトウェア更新部４１によってソフトウェアの切替指示が行われた場合、実行対象とするソフトウェアを現在のバージョンのソフトウェアから、ソフトウェア更新部４１によって書き込まれたソフトウェアに切り替える。ソフトウェア切替部２３によるソフトウェアの切り替えは、次に車両の電源がオンされたことを契機として、車載機Ａ～Ｄのソフトウェアのバージョンの整合性を確認する処理の前に実行する。

＜制御処理＞
以下、図８～図１０を併せて参照しながら、代表車載機Ａが実行する制御処理を説明する。

図９は、第３の実施形態に係る車両制御システムにおいて、代表車載機が実行するソフトウェア取得処理の一例を示すフローチャートである。

ステップＳ４１：受信部１５は、他の車載機Ｂ～Ｄから故障通知を受信したか否かを判定する。ステップＳ４１の判定がＹＥＳの場合、処理はステップＳ４２に移り、それ以外の場合は処理を終了する。

ステップＳ４２：ソフトウェア取得部４０は、故障した車載機の現在のバージョンのソフトウェアを外部サーバ２から取得して記憶する。その後、処理を終了する。

図１０は、第３の実施形態に係る車両制御システムにおいて、代表車載機が実行する整合性確認処理の一例を示すフローチャートである。図１０に示す制御処理は、車両の電源がオンされたことを契機として実行される。

ステップＳ５１：バージョン取得部１２は、他の車載機Ｂ～Ｄのソフトウェアのバージョンを取得する。その後、処理はステップＳ５２に移る。

ステップＳ５２：判定部１３は、代表車載機Ａのソフトウェアのバージョンと、他の車載機Ｂ～Ｄから取得したソフトウェアのバージョンとを、整合情報記憶部１１に記憶される整合テーブルと照合し、車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを判定する。ステップＳ５２の判定がＹＥＳの場合、処理はステップＳ５４に移り、それ以外の場合、処理はステップＳ５３に移る。

ステップＳ５３：判定部１３は、車載機Ａ～Ｄを組み合わせて用いた車両制御の実行を許可する。その後、処理を終了する。

ステップＳ５４：判定部１３は、整合テーブルと整合していないバージョンのソフトウェアを有する車載機が、交換または修理された車載機であるか否かを判定する。車載機が交換または修理されたか否かは、図９のステップＳ４１で受信した故障通知に基づいて特定することができる。ステップＳ５４の判定がＹＥＳの場合、処理はステップＳ５５に移り、それ以外の場合、処理はステップＳ５６に移る。

ステップＳ５５：ソフトウェア更新部４１は、交換または修理された車載機のソフトウェア記憶部２０の所定の領域に、ソフトウェア取得部４０に記憶されるソフトウェアを書き込む。そして、ソフトウェア更新部４１は、交換または修理された車載機に対して、ソ
フトウェアの切り替えを指示する。その後、処理を終了する。

ステップＳ５６：判定部１３は、車載機Ａ～Ｄを組み合わせて用いた車両制御の実行を禁止する。その後、処理を終了する。

尚、ソフトウェア更新部４１がソフトウェアの切り替えを指示した場合、交換または修理された車載機が実行対象とするソフトウェアを現在のバージョンのソフトウェアから更新されたソフトウェアに切り替えるために、車両の電源を一旦オフした後、再度をオンするように、ユーザに促しても良い。また、代表車載機Ａは、ソフトウェア更新部４１がソフトウェアの切り替えを指示した車載機の電源を一旦オフにした後、再度オンしても良い。ソフトウェア更新部４１によって、ソフトウェアの切り替えを指示された車載機は、次に電源がオンされたときに、ソフトウェア切替部２３が、実行対象とするソフトウェアを、ソフトウェア更新部４１によってソフトウェア記憶部２０に書き込まれたソフトウェアに切り替える。

＜効果等＞
本実施形態に係る車両制御システム３００では、第１の実施形態と同様に、車両の電源がオンされたことを契機として車載機Ａ～Ｄのソフトウェアのバージョンに整合性があるか否かを判定するため、車載機Ａ～Ｄのソフトウェアのバージョン不整合により、予期しない車両制御が実行される可能性をより低減することができる。

これに加えて、本実施形態に係る車両制御システム３００では、故障により車載機Ｂ～Ｄの交換または修理が必要となった場合には、事前に整合性が確認されている、故障した車載機のソフトウェアを代表車載機Ａが外部サーバ２から予め取得する。そして、故障した車載機の交換または修理の後に、交換または修理された車載機のソフトウェアのバージョンが整合テーブルと整合しない場合には、代表車載機Ａが外部サーバ２から予め取得しておいたソフトウェアへの切り替えを行う。したがって、車載機の交換や修理に起因して車載機Ａ～Ｄのソフトウェアのバージョンの整合が取れなくなり、かつ、車両の無線通信環境が整っていない場合でも、速やかに車載機Ａ～Ｄの整合性がとれた状態に復帰させることができる。この結果、車載機Ａ～Ｄの組み合わせにより実現される車両制御機能の制限を早期に解消でき、ユーザの利便性を向上できる。

尚、第３の実施形態に係るソフトウェアの整合性確認方法は、第１の実施形態に係る車両制御システム１００または第２の実施形態に係る車両制御システム２００と組み合わせても良い。具体的には、第１の実施形態に係る車両制御システム１００または第２の実施形態に係る車両制御システム２００に、ソフトウェア取得部４０と、ソフトウェア更新部４１を更に設け、図９に示したステップＳ４１及びＳ４２の処理と、図１０に示したステップＳ５４及びＳ５５の処理とを実行可能となるように代表車載機Ａを構成すれば良い。図１０に示したステップＳ５４及びＳ５５の処理は、判定部１３による一次チェックでソフトウェアのバージョンに整合性がないと判定されてから外部サーバ２での二次チェックを実行する前に実行することが好ましい。このように構成すれば、代表車載機Ａが保持する情報を用いた整合性の判定を優先的に実行し、代表車載機Ａだけで判定ができない場合に外部サーバ２での二次チェックを行うため、通信を行うことなく、ソフトウェアの整合性の判定処理を効率的に行うことができる。車両と外部サーバ２との通信可否を判定するステップ（図６のＳ２６）がある場合は、車両が外部サーバ２と通信できない場合に、図１０のステップＳ５４及びＳ５５の処理を実行すれば良い。

（その他の変形例等）
尚、上述した図４、図６、図９及び図１０の制御処理は、専用の回路によって実現しても良いし、例えば、プロセッサ、ＲＯＭ、ＲＡＭ、ハードディスク等を有するＥＣＵ等の
コンピュータに、各ステップの処理を実行させることにより実現しても良い。図４、図６、図９及び図１０の制御処理をＥＣＵ等のコンピュータに実行させる場合、これらの制御処理を実行可能に記述したプログラムを予めＲＯＭやハーディスク等の記憶装置に格納しておき、コンピュータが備えるプロセッサに記憶装置からプログラムを読み出させて実行させれば良い。

また、上記の各実施形態では、車両制御システムの制御機能を提供する車載機の１つが代表車載機としてソフトウェアのバージョンの整合性を確認する例を説明したが、ソフトウェアのバージョンの整合性を確認するための専用の車載機により、上記の制御処理を実行しても良い。

本発明は、複数の車載機の組み合わせにより所定の車両制御機能を実現する車両制御システムに利用できる。

２ 外部サーバ
１０ ソフトウェア記憶部
１１ 整合情報記憶部
１２ バージョン取得部
１３ 判定部
１４ 送信部
１５ 受信部
１６ 整合情報更新部
１７ 更新指示部
１８ 切替指示部
１９ ソフトウェア切替部
２０ ソフトウェア記憶部
３０ 整合情報記憶部
３１ 判定部
３２ 送信部
３３ 受信部
４０ ソフトウェア取得部
４１ ソフトウェア更新部
１００、２００、３００ 車両制御システム
Ａ 代表車載機
Ｂ～Ｄ 車載機

Claims (9)

1. 複数の車載機に接続されるマスタ装置であって、
   前記複数の車載機のソフトウェアのバージョンの許可された組み合わせを含む整合情報を記憶する記憶部と、
   前記複数の車載機のソフトウェアの切替指示を行う第１の指示部と、
   前記切替指示に応じた前記複数の車載機の切替後のソフトウェアのバージョン情報を取得する取得部と、
   前記取得部により取得された前記バージョン情報と前記整合情報とを照合することにより、前記複数の車載機の切替後のソフトウェアのバージョンに整合性があるか否かを判定する判定部と、
   前記複数の車載機の切替後のソフトウェアのバージョンに整合性がないと判定されたことに基づいて、前記複数の車載機に対して、切替後のソフトウェアから切替前のソフトウェアに戻すよう指示する第２の指示部と、
   を備える、マスタ装置。
2. 複数の電子制御ユニットに接続されるマスタであって、
   前記複数の電子制御ユニットのソフトウェアのバージョンの許可された組み合わせを含む整合情報を記憶する記憶部と、
   前記複数の電子制御ユニットのソフトウェアの切替指示を行う第１の指示部と、
   前記切替指示に応じた前記複数の電子制御ユニットの切替後のソフトウェアのバージョン情報を取得する取得部と、
   前記取得部により取得された前記バージョン情報と前記整合情報とを照合することにより、前記複数の電子制御ユニットの切替後のソフトウェアのバージョンに整合性があるか否かを判定する判定部と、
   前記複数の電子制御ユニットの切替後のソフトウェアのバージョンに整合性がないと判定されたことに基づいて、前記複数の電子制御ユニットに対して、切替後のソフトウェアから切替前のソフトウェアに戻すよう指示する第２の指示部と、
   を備える、マスタ。
3. 複数のターゲット電子制御ユニットに接続される装置が有するコンピュータがソフトウェアの整合性を確認するための方法であって、
   前記複数のターゲット電子制御ユニットのソフトウェアのバージョンの許可された組み合わせを含む整合情報を記憶するステップと、
   前記複数のターゲット電子制御ユニットのソフトウェアの切替指示を行うステップと、
   前記切替指示に応じた前記複数のターゲット電子制御ユニットの切替後のソフトウェアのバージョン情報を取得するステップと、
   前記取得された前記バージョン情報と前記整合情報とを照合することにより、前記複数のターゲット電子制御ユニットの切替後のソフトウェアのバージョンに整合性があるか否かを判定するステップと、
   前記複数のターゲット電子制御ユニットの切替後のソフトウェアのバージョンに整合性がないと判定されたことに基づいて、前記複数のターゲット電子制御ユニットに対して、切替後のソフトウェアから切替前のソフトウェアに戻すよう指示するステップと、
   を備える、方法。
4. 複数のターゲット電子制御ユニットに接続される装置が有するコンピュータがソフトウェアの整合性を確認するためのプログラムであって、前記コンピュータに
   前記複数のターゲット電子制御ユニットのソフトウェアのバージョンの許可された組み合わせを含む整合情報を記憶するステップと、
   前記複数のターゲット電子制御ユニットのソフトウェアの切替指示を行うステップと、
   前記切替指示に応じた前記複数のターゲット電子制御ユニットの切替後のソフトウェアのバージョン情報を取得するステップと、
   前記取得された前記バージョン情報と前記整合情報とを照合することにより、前記複数のターゲット電子制御ユニットの切替後のソフトウェアのバージョンに整合性があるか否かを判定するステップと、
   前記複数のターゲット電子制御ユニットの切替後のソフトウェアのバージョンに整合性がないと判定されたことに基づいて、前記複数のターゲット電子制御ユニットに対して、切替後のソフトウェアから切替前のソフトウェアに戻すよう指示するステップと、
   を実行させるためのプログラム。
5. 請求項１に記載のマスタ装置を備える、車両。
6. 前記記憶部は、前記切替前のソフトウェアのバージョンの許可された組み合わせと、前記切替後のソフトウェアのバージョンの許可された組み合わせとを記憶しており、
   前記第２の指示部によるソフトウェアの切り替え指示の後に、
   前記取得部は、前記複数の車載機のソフトウェアのバージョン情報を取得し、
   前記判定部は、前記取得部により取得されたソフトウェアのバージョン情報と、前記切替前のソフトウェアのバージョンの許可された組み合わせとを照合することにより、前記複数の車載機のソフトウェアのバージョンに整合性があるか否かを判定する、請求項１に記載のマスタ装置。
7. 前記取得部によって取得された前記バージョン情報を外部サーバに送信可能な送信部を備え、
   前記複数の車載機の切替後のソフトウェアのバージョンに整合性がないと判定され、更に、前記送信部が前記外部サーバと通信できない場合、前記第２の指示部が、前記複数の車載機に対して、切替後のソフトウェアから切替前のソフトウェアに戻すよう指示する、請求項１または６に記載のマスタ装置。
8. 前記送信部によって送信された前記バージョン情報に基づいて前記外部サーバによって判定された判定結果情報であって、前記複数の車載機のソフトウェアのバージョンに整合性があるか否かを示す判定結果情報を、前記外部サーバから受信可能な受信部を備え、
   前記複数の車載機の切替後のソフトウェアのバージョンに整合性がないと判定され、前記送信部が前記外部サーバと通信可能である場合、
   前記送信部は、前記取得部によって取得された前記バージョン情報を前記外部サーバに送信し、
   前記受信部は、前記外部サーバから前記判定結果情報を受信し、
   前記判定部は、前記受信部により受信された前記判定結果情報に基づいて、前記複数の車載機のソフトウェアのバージョンに整合性があるか否かを判定する、請求項７に記載のマスタ装置。
9. 前記判定部は、前記複数の車載機のソフトウェアのバージョンに整合性があると判定し場合、前記複数の車載機により実現される所定の車両制御の実行を許可する、請求項１及び６～８のいずれかに記載のマスタ装置。

Images