特許 5989577 バージョンアップシステム及びバージョンアップ方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5989577

(24)【登録日】2016年8月19日

(45)【発行日】2016年9月7日

(54)【発明の名称】バージョンアップシステム及びバージョンアップ方法

(51)【国際特許分類】

   G06F 11/00 20060101AFI20160825BHJP

   G06F 9/445 20060101ALI20160825BHJP

【ＦＩ】

   G06F9/06 630A

   G06F9/06 640A

【請求項の数】5

【全頁数】10

(21)【出願番号】特願2013-50358(P2013-50358)

(22)【出願日】2013年3月13日

(65)【公開番号】特開2014-178722(P2014-178722A)

(43)【公開日】2014年9月25日

【審査請求日】2015年3月5日

(73)【特許権者】

【識別番号】000003078

【氏名又は名称】株式会社東芝

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100109830

【弁理士】

【氏名又は名称】福原 淑弘

(74)【代理人】

【識別番号】100088683

【弁理士】

【氏名又は名称】中村 誠

(74)【代理人】

【識別番号】100103034

【弁理士】

【氏名又は名称】野河 信久

(74)【代理人】

【識別番号】100075672

【弁理士】

【氏名又は名称】峰 隆司

(74)【代理人】

【識別番号】100153051

【弁理士】

【氏名又は名称】河野 直樹

(74)【代理人】

【識別番号】100140176

【弁理士】

【氏名又は名称】砂川 克

(74)【代理人】

【識別番号】100158805

【弁理士】

【氏名又は名称】井関 守三

(74)【代理人】

【識別番号】100172580

【弁理士】

【氏名又は名称】赤穂 隆雄

(74)【代理人】

【識別番号】100179062

【弁理士】

【氏名又は名称】井上 正

(74)【代理人】

【識別番号】100124394

【弁理士】

【氏名又は名称】佐藤 立志

(74)【代理人】

【識別番号】100112807

【弁理士】

【氏名又は名称】岡田 貴志

(74)【代理人】

【識別番号】100111073

【弁理士】

【氏名又は名称】堀内 美保子

(72)【発明者】

【氏名】溝口 文寿

(72)【発明者】

【氏名】白鳥 雅史

(72)【発明者】

【氏名】杉山 智昭

【審査官】 長谷川 篤男

(56)【参考文献】

【文献】 特開２００９−１８７４５６（ＪＰ，Ａ）

【文献】 国際公開第２００８／１２０３６３（ＷＯ，Ａ１）

【文献】 特開２００７−０６６０８２（ＪＰ，Ａ）

【文献】 特開２００２−３５４１４２（ＪＰ，Ａ）

【文献】 特開２００３−１４３０９１（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１１／００７２４２３（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １１／００

Ｇ０６Ｆ ９／４４５

(57)【特許請求の範囲】

【請求項1】

互いに異なり少なくとも情報処理に係る機能を実行するためのソフトウェアが設定された複数のユニットと、これら複数のユニットに対し内部バスを介して接続され前記複数のユニットによる処理を統括的に制御する制御部とを備える複数の筐体と、
前記複数の筐体に対し通信ネットワークを介して接続され、前記複数の筐体それぞれのユニットに設定されたソフトウェアをバージョンアップするように遠隔制御する端末とを具備し、
前記端末は、
バージョンアップ指示が入力されるとき、バージョンアップ対象となるユニットの種類を特定するユニットＩＤをパケットのヘッダ部に挿入し、ペイロード部にバージョンアップデータを挿入したバージョンアップ要求を生成するバージョンアップ要求生成手段と、
前記バージョンアップ要求を前記通信ネットワーク上の前記複数の筐体に配信する要求配信手段とを備え、
前記複数の筐体の各々の制御部は、
前記ユニットＩＤと、前記筐体に対するユニットの実装位置を特定するスロットＩＤとを対応付けた構成情報テーブルを記憶する筐体側記憶手段と、
前記端末からのバージョンアップ要求を受信した場合、前記バージョンアップ要求に含まれるユニットＩＤに基づいて前記構成情報テーブルを参照し、この参照結果に基づいて該当するユニットに設定されたソフトウェアを前記バージョンアップ要求に含まれるバージョンアップデータに書き換えるバージョンアップ制御手段とを備えることを特徴とするバージョンアップシステム。

【請求項2】

前記端末は、前記筐体を特定する装置ＩＤと、前記ユニットＩＤとを対応付けたテーブルを記憶する端末側記憶手段をさらに備え、
前記要求配信手段は、前記端末側記憶手段に記憶されるテーブルに基づいて、該当する筐体に前記バージョンアップ要求を配信することを特徴とする請求項１記載のバージョンアップシステム。

【請求項3】

前記複数の筐体の各々の制御部は、前記ユニットのバージョンアップの成功／失敗を示す情報に該当するユニットのスロットＩＤを付加して前記端末に送信する情報送信手段をさらに備え、
前記端末は、各筐体から送信された前記バージョンアップの成功／失敗を示す情報を、前記装置ＩＤと、前記ユニットＩＤと、前記スロットＩＤとに対応付けて前記テーブルに記録する記録手段とをさらに備えることを特徴とする請求項２記載のバージョンアップシステム。

【請求項4】

前記端末は、前記複数の筐体を分割して構成した複数のグループと、これらのグループに属する筐体との対応関係を表すデータを記憶するグループデータ記憶手段をさらに備え、
前記要求配信手段は、所定の条件に基づいて、前記グループデータ記憶手段を参照して、該当するグループに属する筐体へ前記バージョンアップ要求を配信することを特徴とする請求項１記載のバージョンアップシステム。

【請求項5】

互いに異なり少なくとも情報処理に係る機能を実行するためのソフトウェアが設定された複数のユニットと、これら複数のユニットに対し内部バスを介して接続され前記複数のユニットによる処理を統括的に制御する制御部とを備える複数の筐体と、前記複数の筐体に対し通信ネットワークを介して接続され、前記複数の筐体それぞれのユニットに設定されたソフトウェアをバージョンアップするように遠隔制御する端末とを備えるシステムで用いられるバージョンアップ方法であって、
前記端末において、バージョンアップ指示が入力されるとき、バージョンアップ対象となるユニットの種類を特定するユニットＩＤをパケットのヘッダ部に挿入し、ペイロード部にバージョンアップデータを挿入したバージョンアップ要求を生成し、
前記端末において、前記バージョンアップ要求を前記通信ネットワーク上の前記複数の筐体に配信し、
前記複数の筐体の各々の制御部において、前記ユニットＩＤと、前記筐体に対するユニットの実装位置を特定するスロットＩＤとを対応付けた構成情報テーブルを記憶し、
前記制御部において、前記端末からのバージョンアップ要求を受信した場合、前記バージョンアップ要求に含まれるユニットＩＤに基づいて前記構成情報テーブルを参照し、この参照結果に基づいて該当するユニットに設定されたソフトウェアを前記バージョンアップ要求に含まれるバージョンアップデータに書き換えることを特徴とするバージョンアップ方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、例えば放送局内で使用される複数の筐体内のユニットのバージョンアップを行うバージョンアップシステム及びバージョンアップ方法に関する。

【背景技術】

【0002】

周知のように、放送番組送出システムにあっては、分配器、信号切替器、各種ＴＶ方式変換器、効果器等の多数の機器で構成されている。これらの機器は、装置の小型化によりユニット単位で実現可能となり、各機器を同一筐体にユニット単位で実装することが可能となった。同一筐体にシステムで必要とする機能を持つユニットを実装することで、スペースの削減や構成追加が容易に行われるようになった。システム規模に合わせて、筐体の数を増やすことで、システムが必要とする機能実装及び系統毎の分割等、筐体数を増やすことで実施することができるが、同一筐体であっても実装されているユニット構成が違うことになる。

【0003】

また、放送番組送出システムでは、障害発生時に速やかに対応できるように、各機器の状態を監視する必要がある。このような複数の同一筐体で、筐体毎に違う機能を持つユニットで構成される装置では、これらの筐体間をイーサネット（登録商標）等の高速バスで接続して、監視を行う。

【0004】

ところで、各ユニットは、映像品質がハイビジョンからフルハイビジョン(2K×1K)、超ハイビジョン(4K×2K)、スーパーハイビジョン(8K×4K)に向け飛躍的に向上し、これに合わせて既に実装されているユニットも性能や機能向上が求められることが必須となる。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２００２−３５４１４２号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

上記のような装置において、業務内容の変化等に応じてユニットの機能を追加する必要が生じることがある。このような場合、ユニットのバージョンアップが必要となる。

【0007】

ところで、ユニットのバージョンアップ作業を行なう場合、該当ユニットがどの筐体に実装されているかを管理し、尚且つ実装されている筐体毎に作業を行う必要があり作業効率が悪いものとなる。

【0008】

目的は、筐体内のユニットのバージョンアップを人手を要することなく遠隔操作により迅速かつ適切に行えるようにし、これにより各ユニットのバージョンアップの作業効率を向上し得るバージョンアップシステム及びバージョンアップ方法を提供することにある。

【課題を解決するための手段】

【0009】

実施形態によれば、バージョンアップシステムは、複数の筐体と、端末とを備える。複数の筐体は、互いに異なり少なくとも情報処理に係る機能を実行するためのソフトウェアが設定された複数のユニットと、これら複数のユニットに対し内部バスを介して接続され前記複数のユニットによる処理を統括的に制御する制御部とを備える。端末は、複数の筐体に対し通信ネットワークを介して接続され、複数の筐体それぞれのユニットに設定されたソフトウェアをバージョンアップするように遠隔制御する。端末は、バージョンアップ要求生成手段と、要求配信手段とを備える。バージョンアップ要求生成手段は、バージョンアップ指示が入力されるとき、バージョンアップ対象となるユニットの種類を特定するユニットＩＤをパケットのヘッダ部に挿入し、ペイロード部にバージョンアップデータを挿入したバージョンアップ要求を生成する。要求配信手段は、バージョンアップ要求を通信ネットワーク上の複数の筐体に配信する。複数の筐体の各々の制御部は、筐体側記憶手段と、バージョンアップ制御手段とを備える。筐体側記憶手段は、ユニットＩＤと、筐体に対するユニットの実装位置を特定するスロットＩＤとを対応付けた構成情報テーブルを記憶する。バージョンアップ制御手段は、端末からのバージョンアップ要求を受信した場合、バージョンアップ要求に含まれるユニットＩＤに基づいて構成情報テーブルを参照し、この参照結果に基づいて該当するユニットに設定されたソフトウェアをバージョンアップ要求に含まれるバージョンアップデータに書き換える。

【図面の簡単な説明】

【0010】

【図1】第１の実施形態におけるバージョンアップシステムの概略構成図。

【図2】本第１の実施形態で扱うソフトウェアの構成を示す図。

【図3】本第１の実施形態におけるバージョンアップ用端末の記憶部に記憶される管理テーブルの記憶内容の一例を示す図。

【図4】本第１の実施形態におけるバージョンアップ用端末と筐体との間で送受信されるパケット構造を示す図。

【図5】本第１の実施形態におけるバージョンアップ用端末と筐体との間の制御処理手順を示すシーケンス図。

【図6】第２の実施形態におけるバージョンアップシステムの概略構成図。

【図7】本第２の実施形態で扱うグループテーブルの記憶内容の一例を示す図。

【発明を実施するための形態】

【0011】

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

【0012】

（第１の実施形態）
図１は、例えば放送局内で使用されるバージョンアップシステムの第１の実施形態を示す概略構成図であり、ＡＰ１〜ＡＰｉは例えば放送局内のスタジオや編集室等に配置される筐体、ＢＴは例えば制御室に配置されるバージョンアップ用端末をそれぞれ示している。筐体ＡＰ１〜ＡＰｉには、ＩＰアドレスが予め割り当てられる。

【0013】

筐体ＡＰ１には、例えばファイル入出力インタフェース部、映像データ入出力部、映像データ記憶部、映像符号化部、映像復号部といった複数のユニットＵＮ１〜ＵＮｎ（ｎは自然数）が実装され、これらユニットＵＮ１〜ＵＮｎに対し内部バス介して接続され、ユニットＵＮ１〜ＵＮｎによる処理を統括的に制御する制御部ＣＵが実装される。また、ユニットＵＮ１〜ＵＮｎには、図２（ａ）に示すようなソフトウェアがセットされており、このセットされたソフトウェアに基づき、例えば映像の符号化処理、映像の復号処理といった信号処理に係る機能を実行する。
また、筐体ＡＰ２〜ＡＰｉにも、複数のユニット及び制御部が実装される。

【0014】

一方、バージョンアップ用端末ＢＴは、筐体ＡＰ１〜ＡＰｉに対しイーサネット（登録商標）等の通信ネットワークＮＷを介して接続される。また、バージョンアップ用端末ＢＴは、パーソナル・コンピュータにより構成され、通信部１１と、記憶部１２と、制御部１３と、ＣＲＴを用いた表示部１４と、キーボード及びマウスからなる入力部１５とを備えている。このうち、入力部１５は、バージョンアップ用端末ＢＴに対し種々の動作指示を入力するために使用するもので、希望するユニットのバージョンアップの実行指示の入力にも使用される。

【0015】

通信部１１は、通信ネットワークＮＷを介して筐体ＡＰ１〜ＡＰｉとの間で通信を行うもので、入力部１５からのバージョンアップ実行指示に応じて筐体ＡＰ１〜ＡＰｉに対しバージョンアップ要求を送信すると共に、このバージョンアップ要求に応じて筐体ＡＰ１〜ＡＰｉが送信するバージョンアップの成功／失敗を示す情報（ＡＣＫ／ＮＡＣＫ）を受信する。

【0016】

記憶部１２には、図３に示すように、筐体ＡＰ１〜ＡＰｉを特定する装置ＩＤと、ユニットＵＮ１〜ＵＮｎの種類を特定するユニットＩＤと、筐体ＡＰ１〜ＡＰｉに対するユニットの実装位置を特定するスロットＩＤと、ユニットのバージョンアップの成功／失敗を示す情報との対応関係を表す管理テーブル１２１が記憶されている。この管理テーブル１２１は、表示部１４に表示される。

【0017】

制御部１３は、バージョンアップ用端末ＢＴとしての動作を実行するものであり、バージョンアップ要求生成部１３１と、バージョンアップ要求配信部１３２と、バージョンアップ結果記録部１３３とを備えている。

【0018】

バージョンアップ要求生成部１３１は、入力部１５により保守担当者からバージョンアップ指示が入力されるとき、図４（ａ）に示すように、バージョンアップ対象となるユニットの種類を特定するユニットＩＤ（０２）をＩＰパケットのヘッダ部に挿入し、ペイロード部にバージョンアップデータを挿入したバージョンアップ要求を生成する。

【0019】

バージョンアップ要求配信部１３２は、上記管理テーブル１２１を参照して、該当するユニットが実装される例えば筐体ＡＰ１，ＡＰ３，ＡＰ５〜ＡＰｉにバージョンアップ要求を配信する。

【0020】

バージョンアップ結果記録部１３３は、図４（ｂ）に示すように、バージョンアップ要求に応じて筐体ＡＰ１〜ＡＰｉが送信するバージョンアップの成功／失敗を示すＩＰパケット（ＡＣＫ／ＮＡＣＫ）を受信した場合に、ＩＰパケットのヘッダ部に挿入される装置ＩＤ、ユニットＩＤ、スロットＩＤに対応付けて、ＡＣＫ／ＮＡＣＫを管理テーブル１２１に記録する。

【0021】

一方、筐体ＡＰ１の制御部ＣＵには、記憶部２１が接続されており、さらにバージョンアップ制御部２２と、バージョンアップ結果送信部２３とを備えている。記憶部２１には、ユニットＵＮ１〜ＵＮｎの種類を特定するユニットＩＤと、筐体ＡＰ１に対するユニットの実装位置を特定するスロットＩＤとの対応関係を表す構成情報テーブル２２１が記憶されている。

【0022】

バージョンアップ制御部２２は、バージョンアップ用端末ＢＴからバージョンアップ要求を受信した場合、上記バージョンアップ要求に含まれるユニットＩＤに基づいて構成情報テーブル２１１を参照し、この参照結果に基づいて内部バスを通じて該当するユニットＵＮｎに設定されたソフトウェアをバージョンアップ要求に含まれるバージョンアップデータに書き換える。すなわち、図２（ａ）の旧バージョンのソフトウェアが設定されていたユニットＵＮｎには、図２（ｂ）の新バージョンのソフトウェアが書き込まれる。すると、ユニットＵＮｎでは、「機能ｃ」（例えばＳＤＴＶ（standard Definition TV）処理機能）に代わって、新たに「機能ｆ」（例えばＨＤＴＶ(High Definition TV)処理機能）、「機能ｘ」が使用できるようになる。１回目のバージョンアップでは、「機能ｆ」及び「機能ｘ」は「ＯＦＦ」に設定されているが、2回目のバージョンアップでは「機能ｆ」及び「機能ｘ」は「ＯＮ」に設定される。

【0023】

バージョンアップ結果送信部２３は、バージョンアップが終了した場合に、ユニットのバージョンアップの成功／失敗を示す情報に該当するユニットのスロットＩＤ、自筐体ＡＰ１の装置ＩＤを付加してバージョンアップ用端末ＢＴに送信する。

【0024】

次に、上記構成における動作について説明する。
図５は、上記バージョンアップ用端末ＢＴと筐体ＡＰ１との間の制御処理手順を示すシーケンスである。

【0025】

ユニットのバージョンアップを行う際に、保守担当者はバージョンアップ用端末ＢＴにおいて入力部１５を操作することでバージョンアップモードを設定する。バージョンアップ用端末ＢＴの制御部１３は、ステップＳＴ５１ａでバージョンアップモードの設定を検出すると、保守担当者によるバージョンアップデータの入力を受け付ける（ステップＳＴ５１ｂ）。

【0026】

このとき保守担当者は、例えばバージョンアップを希望するユニットＩＤ、追加希望の機能名等の必要事項を入力する。制御部１３は、入力されたユニットＩＤと、入力された機能名を含むバージョンアップデータを表示部１４に表示する。この状態で保守担当者が入力部１５において確定操作を行うと、制御部１３はステップＳＴ５１ｃからステップＳＴ５１ｄに移行し、管理テーブル１２１を参照して該当するユニットを実装した例えば筐体ＡＰ１，ＡＰ３，ＡＰ５〜ＡＰｉにユニットＩＤ及びバージョンアップデータを含めたバージョンアップ要求を通信ネットワークＮＷを介して送信する。

【0027】

一方、筐体ＡＰ１の制御部ＣＵは、バージョンアップ用端末ＢＴから送られてくるバージョンアップ要求を受信し（ステップＳＴ５２ａ）、バージョンアップ要求のヘッダ部に挿入されるユニットＩＤに基づいて構成情報テーブル２１１を参照して該当するユニットをチェックする（ステップＳＴ５２ｂ）。

【0028】

そして、該当するユニットＵＮｎがバージョンアップ対象であることを判定すると、制御部ＣＵはユニットＵＮｎに設定済みのソフトウェアをバージョンアップ要求のペイロード部に挿入されたバージョンアップデータに書き換える処理を実行する（ステップＳＴ５２ｃ）。なお、制御部ＣＵは、非該当ユニットＵＮ１〜ＵＮ（ｎ−１）に対してはバージョンアップデータの書き込みを行なわない。

【0029】

該当ユニットＵＮｎはバージョンアップデータによりバージョンアップを行ない、バージョンアップを終了すると制御部ＣＵにＡＣＫを返す。失敗した場合はＮＡＣＫを返す。

【0030】

筐体ＡＰ１の制御部ＣＵは、バージョンアップが成功するか否かを監視しており（ステップＳＴ５２ｄ）、バージョンアップが成功した場合に（Ｙｅｓ）、ＡＣＫ及びユニットＵＮｎのスロットＩＤ及び装置ＩＤ（装置１）を含めたバージョンアップ結果（ＩＰパケット）をバージョンアップ用端末ＢＴに送信する（ステップＳＴ５２ｅ）。一方、バージョンアップが失敗した場合に（Ｙｅｓ）、制御部ＣＵはＮＡＣＫ及びユニットＵＮｎのスロットＩＤ及び装置ＩＤ（装置１）を含めたバージョンアップ結果（ＩＰパケット）をバージョンアップ用端末ＢＴに送信する（ステップＳＴ５２ｆ）。

【0031】

バージョンアップ用端末ＢＴは、筐体ＡＰ１からバージョンアップ結果を受信し（ステップＳＴ５１ｅ）、このバージョンアップ結果に含まれる装置ＩＤ、スロットＩＤ、バージョンアップの成功／失敗を示す情報を管理テーブル１２１に記録するとともに表示部１４に表示させる（ステップＳＴ５１ｆ）。

【0032】

これにより、バージョンアップを失敗した場合は、バージョンアップ用端末ＢＴに失敗した筐体とスロットとバージョンアップデータの情報を設定することができ、失敗した該当ユニットだけにバージョンアップをすることができる。

【0033】

なお、筐体ＡＰ２の制御部は、バージョンアップ要求を受信した場合に、筐体ＡＰ１と同様に内部バスにより実装ユニットをチェックするが、該当ユニットが無い為、ＮＡＣＫをバージョンアップ用端末ＢＴに送信する。バージョンアップ用端末ＢＴは、筐体ＡＰ２が非該当であることを表示する。

【0034】

以上のシステムを組むことで、実装管理とユニットのバージョンアップ作業が自動化出来る。

【0035】

以上のように上記第１の実施形態では、バージョンアップの要求から各筐体ＡＰ１〜ＡＰｉにおけるユニットのバージョンアップまでの工程が、人手を要することなく全て通信ネットワークＮＷを介して行われることになる。このため、保守担当者によるユニットの実装管理及び手作業によるユニットのバージョンアップ作業が一切不要となる。従って、各筐体ＡＰ１〜ＡＰｉ内の対象となるユニットのバージョンアップを短時間の内に行うことが可能となり、バージョンアップに必要な労力を大幅に低減することが可能となる。また、バージョンアップ用端末ＢＴから各筐体ＡＰ１〜ＡＰｉに送信するバージョンアップ要求に、ヘッダ部にバージョンアップ対象となるユニットＩＤを挿入し、ペイロード部にバージョンアップデータを挿入した既存のＩＰパケットを利用して、該当するユニットのバージョンアップを行うことができるので、バージョンアップ要求を伝送するための専用信号ラインを設ける必要がなくなる。さらにバージョンアップ用端末ＢＴの保守担当者にとってはバージョンアップを希望するユニットの種類を指定するだけでよく、これにより保守担当者のバージョンアップ要求操作を簡略化できる。

【0036】

また、上記第１の実施形態によれば、バージョンアップ用端末ＢＴにおいて管理テーブル１２１に蓄積管理された装置ＩＤとユニットＩＤとの対応関係を用いて、バージョンアップ用端末ＢＴと各筐体ＡＰ１〜ＡＰｉとの間の通信やバージョンアップの可否判定等が行われるので、簡単な手順で適切なバージョンアップ処理を行い得る。

【0037】

さらに上記第１の実施形態によれば、バージョンアップ用端末ＢＴの保守担当者は少なくとも自身が要求したバージョンアップが受け付けられたか否かを確認することができる。また、その際にバージョンアップの成功／失敗を示す情報に加えて、装置ＩＤ及びスロットＩＤをバージョンアップ用端末ＢＴの保守担当者に通知するようにすれば、バージョンアップが失敗した場合に保守担当者は該当する筐体ＡＰ１のどの実装位置のユニットＵＮｎが失敗したのかを把握して適切なやり直し操作等を行うことが可能となる。

【0038】

（第２の実施形態）
第２の実施形態は、複数の筐体ＡＰ１〜ＡＰｉをグループ分けし、グループごとにバージョンアップを行うようにしたものである。

【0039】

図６は、バージョンアップシステムの第２の実施形態を示す概略構成図である。

【0040】

バージョンアップ用端末ＢＴの記憶部１２には、図７に示すように、通信ネットワークＮＷ上の筐体ＡＰ１〜ＡＰｉを分割して構成した複数のグループＧ１，Ｇ２と、これらのグループＧ１，Ｇ２に属する複数の筐体と、バージョンアップの実行時間帯を指定する情報との対応関係を表すグループテーブル１２２が記憶される。

【0041】

バージョンアップ用端末ＢＴは、時間帯によってバージョンアップを行うグループＧ１，Ｇ２を切り替える。

【0042】

この状態で、バージョンアップ用端末ＢＴは、例えば時刻が１７：００になるとグループテーブル１２２を参照してグループＧ２に属する筐体ＡＰ４〜ＡＰｉに対しバージョンアップ要求を送信して該当するユニットのバージョンアップを行い、９：００になるとグループテーブル１２２を参照してグループＧ１に属する筐体ＡＰ１〜ＡＰ３に対しバージョンアップ要求を送信して該当するユニットのバージョンアップを行う。このようにすることで、時間帯によってバージョンアップを行うグループを自動的に変更することが可能となる。なお、上記切替条件としては、日時情報以外に例えば通信トラフィック、障害発生等を用いることが可能である。

【0043】

また、グループＧ１に属する筐体ＡＰ１〜ＡＰ３を現用系とし、グループＧ２に属する筐体ＡＰ４〜ＡＰｉを予備系として、筐体ＡＰ１〜ＡＰ３の障害発生時もしくはメンテナンス時に、予備系となる筐体ＡＰ４〜ＡＰｉに切り替えるようにしてもよい。

【0044】

以上のように上記第２の実施形態によれば、複数の筐体ＡＰ１〜ＡＰｉをグループ化してこのグループＧ１，Ｇ２と筐体ＡＰ１〜ＡＰｉとを対応付けて、例えば日時や通信トラフィック等に応じて最適なグループを選択設定してバージョンアップ処理を効率良く行うことが可能となる。

【0045】

（その他の実施形態）
その他、上記各実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記各実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

【符号の説明】

【0046】

１１…通信部、１２…記憶部、１３…制御部、１４…表示部、１２１…管理テーブル、１２２…グループテーブル、１３１…バージョンアップ要求生成部、１３２…バージョンアップ要求配信部、１３３…バージョンアップ結果記録部、２１…記憶部、２２…バージョンアップ制御部と、２３…バージョンアップ結果送信部、２１１…構成情報テーブル、ＢＴ…バージョンアップ用端末、ＡＰ１〜ＡＰｉ…筐体、ＵＮ１〜ＵＮｎ…ユニット、ＮＷ…通信ネットワーク。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】