(57)【特許請求の範囲】
【請求項１】
機能のアップグレードが可能な複数の個別パッケージと、前記複数の個別パッケージを監視制御する共通パッケージとを有する機能追加型制御装置において、
前記複数の個別パッケージと前記共通パッケージとの間に、前記複数の個別パッケージの監視制御を行うための信号と、パッケージの制御を行うために前記共通パッケージにより実行される制御プログラムおよび制御コマンドの少なくとも一方を転送するための信号とを送受信するバスを設け、
前記個別パッケージは、
自パッケージ用の前記制御プログラムおよび前記制御コマンドの少なくとも一方を格納する個別パッケージ側メモリと、
自パッケージの実装時に前記個別パッケージ側メモリに格納された前記制御プログラムおよび前記制御コマンドの少なくとも一方を前記バスを介して前記共通パッケージに転送する制御部と
を有し、
前記共通パッケージは、
前記個別パッケージの制御を行うための制御プログラムおよび制御コマンドを格納するプログラムメモリおよびコマンドメモリを別々に有する共通パッケージ側メモリと、
前記個別パッケージから転送される前記制御プログラムおよび前記制御コマンドの少なくとも一方を前記共通パッケージ側メモリに展開し、前記共通パッケージ側メモリの前記制御プログラムおよび前記制御コマンドを用いて前記複数の個別パッケージの監視制御を行う監視制御部と
を有し、
さらに、前記プログラムメモリは、
複数のサブプログラムが記憶されるサブプログラムメモリと、
メインプログラムと、前記メインプログラムから前記サブプログラムメモリに記憶されている前記サブプログラムへのジャンプ先アドレスと、を記憶するメインプログラムメモリと
を独立して有する
ことを特徴とする機能追加型制御装置。
【請求項２】
請求項１に記載の機能追加型制御装置において、
前記監視制御部は、前記個別パッケージから転送される前記制御プログラムまたは前記制御コマンドが前記プログラムメモリまたは前記コマンドメモリに保持されていない場合に、前記プログラムメモリまたは前記コマンドメモリに記憶する
ことを特徴とする機能追加型制御装置。
【請求項３】
請求項２に記載の機能追加型制御装置において、
前記監視制御部は、前記個別パッケージから転送される前記制御プログラムまたは前記制御コマンドのバージョンが前記プログラムメモリまたは前記コマンドメモリに保持されている前記制御プログラムまたは前記制御コマンドのバージョンより新しい場合に、前記プログラムメモリまたは前記コマンドメモリに保持されている前記制御プログラムまたは前記制御コマンドを更新する
ことを特徴とする機能追加型制御装置。
【請求項４】
請求項１から３のいずれか一項に記載の機能追加型制御装置において、
前記プログラムメモリは、異なる２つのプログラムを格納する実行用プログラムメモリと予備用プログラムメモリとを有し、
前記コマンドメモリは、異なる２つのコマンドを格納する実行用コマンドメモリと予備用コマンドメモリとを有し、
前記監視制御部は、前記実行用プログラムメモリと前記実行用コマンドメモリに保持されている前記制御プログラムおよび前記制御コマンドを用いて前記複数の個別パッケージの監視制御を前記バスを介して行い、前記個別パッケージから前記バスを介して転送される前記制御プログラムおよび前記制御コマンドを前記予備用プログラムメモリおよび前記予備用コマンドメモリにそれぞれ格納した後、前記予備用プログラムメモリおよび前記予備用コマンドメモリと前記実行用プログラムメモリおよび前記実行用コマンドメモリとを切り替える
ことを特徴とする機能追加型制御装置。
【請求項５】
請求項２に記載の機能追加型制御装置において、
前記監視制御部は、前記個別パッケージから転送される前記制御プログラムまたは前記制御コマンドのバージョンが前記プログラムメモリまたは前記コマンドメモリに保持されている前記制御プログラムまたは前記制御コマンドのバージョンより古い場合に、前記プログラムメモリまたは前記コマンドメモリに保持されている前記制御プログラムまたは前記制御コマンドを前記バスを介して前記個別パッケージの前記個別パッケージ側メモリに転送する
ことを特徴とする機能追加型制御装置。
【請求項６】
請求項１から５のいずれか一項に記載の機能追加型制御装置において、
前記共通パッケージに回路記述プログラムによる回路の書き換えが可能なハードウェアデバイスが搭載されている場合に、
前記個別パッケージ側メモリは、前記ハードウェアデバイスの回路記述プログラムを格納し、
前記監視制御部は、前記個別パッケージから転送される前記回路記述プログラムのバージョンが前記ハードウェアデバイスに搭載されている回路記述プログラムのバージョンより新しい場合に、前記個別パッケージから転送される前記回路記述プログラムを新たに前記ハードウェアデバイスに搭載する
ことを特徴とする機能追加型制御装置。
【請求項７】
請求項１から６のいずれか一項に記載の機能追加型制御装置と、オペレーションシステムによって前記機能追加型制御装置を管理する上位の監視制御装置とを用いる機能追加型制御システムにおいて、
前記監視制御部は、前記監視制御装置に対して制御を受け付けないモードへの移行を知らせる非制御通知を送信後、前記プログラムメモリまたは前記コマンドメモリに保持されている前記制御プログラムまたは前記制御コマンドを更新し、全ての更新を完了した時に前記監視制御装置に対して実装完了通知を送信し、
前記監視制御装置は、前記機能追加型制御装置の前記監視制御部から前記非制御通知を受信してから前記実装完了通知を受信するまで前記機能追加型制御装置に対する制御を行わない
ことを特徴とする機能追加型制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、新たな機能の追加が可能な制御装置に関する。
【背景技術】
【０００２】
通信装置など技術開発のスピードが速い分野で使用される装置では、常に様々な機能の追加が求められる。特にこのような装置やシステムの開発は非常に短い期間で行い、顧客に納入しなければならず、設計期間や評価期間の短縮が求められる。設計期間は過去に蓄積された技術を流用することにより短縮を図ることができるが、ソフトウェアやハードウェアを全て組み合わせた最終的なシステムでバグの有無や動作検証を行う評価期間を短くすることは難しい。
【０００３】
従来のシステムは、ハードウェア部と、そのハードウェアを監視制御するソフトウェア部（図５）とに分かれており、それぞれの開発は個別に行われている。そして、システムのバージョンアップを行う場合、先ずバージョンアップ対象のハードウェア開発を行い、その後、今までのソフトウェアにそのバージョンアップ対象のハードウェアを制御する機能を付け加える手順が取られる。例えば、制御用システムで保守作業や仕様変更作業を容易にし、現状のソフトウェア資産を有効利用する技術が検討されている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特願２０００−０６６９０６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところが、このような従来のシステムでバージョンアップ時の評価を行う場合、ハードウェアの評価はバージョンアップ対象となる部分の評価を行えばよいが、ソフトウェア部の評価は今までの機能についてもデグレードがないかチェックする必要があるため、バージョンアップを行うごとに評価項目が増えていく。このため、バージョンアップの度に評価期間が増大していき、少人数で短期にシステム開発を行うのが難しくなり、評価期間が長くなることによってコストも高くなるという問題が生じる。
【０００６】
ここで、従来の課題について詳しく説明する。一般的なシステム装置は、様々な機能を実現するために機能毎に設けられた複数の個別部分（個別パッケージ）と、複数の個別パッケージの監視および制御などを行うための共通部分（共通パッケージ）に分けて考えることができる。例えば通信装置の場合は、上位側のネットワークや下位側のネットワーク或いは端末などを接続するための複数のＩＦ（インターフェース）盤、装置全体の動作状態を監視したり、設定変更などの制御を行うためのＣＰＵ盤（制御盤）、クロックを供給するクロック盤、パケットの宛先に応じて経路を選択するＳＷ（スイッチ）盤、温度管理を行うためのＦＡＮ盤などで構成される。ここで、本明細書では、個別の機能を実現する部分を個別パッケージ、装置全体で共通に必要な機能を有する共通部分を共通パッケージと定義し、例えば通信装置の場合は、個別パッケージとして通信速度や機能が異なる複数のＩＦ盤を想定し、共通パッケージとして装置全体の制御や監視を行うＣＰＵ盤を想定して説明を行うものとする。
【０００７】
以下、従来の課題について順番に説明する。
（１）多大なシステム検証期間が必要
上記のように、個別パッケージと共通パッケージで構成される装置のバージョンアップ開発を行う場合、要求された機能を有する個別パッケージのハードウェアの変更と、そのハードウェアの制御や監視などを行うための共通パッケージのプログラムのバージョンアップとを行う必要がある。特に、初期開発時に、今後のバージョンアップで要求されるであろうハードウェアを予測して、そのハードウェアを監視・制御するための共通パッケージのプログラムを最初から盛り込んでおくことが一般に行われている。そして、その部分は当初は使用しない機能であっても、後のバージョンアップで使用する機能も含めてすべて評価済みにしておかなければならず、初期のシステムの検証に多大な時間を費やしてしまうため、短期間でのバージョンアップ開発を阻む要因になってしまう。逆に、初期出荷時に必要な機能のみを開発し、後で追加する機能のハードウェアおよびバージョンアップすべき共通部分のプログラムの開発を行う場合は、共通部分は今までの持っていた機能を含めた改良が必要になってしまうため、例えば、今まであった機能のデグレードがないか否かを確認する必要が生じ、評価項目がバージョンアップを重ねる度に増加してしまうため、これもまた短期間でのバージョンアップ開発を阻む要因になってしまう。
（２）システムの共通部分のプログラムのバージョンアップ作業および費用が必要
一般に、システムのバージョンアップを行うためには、バージョンアップ対象となる個別パッケージのハードウェアと、監視制御等を行う共通パッケージのプログラムとの両方のバージョンアップが必要である。従来のシステム構成では、新たにバージョンアップしたハードウェアを組み込めば、そのバージョンアップした機能を使うための共通パッケージのプログラムもバージョンアップしなければならない。従って、バージョンアップした機能を使うために、プログラム部分のバージョン管理をシステムを使用する側で管理しなければならず管理費用が発生する。さらに、顧客とベンダーのどちらがバージョンアップ費用を負担するかは別として、仮に現地作業ではなく遠隔操作でバージョンアップを行う場合でも、オペレータなどの人的な作業が必要であるため、必ずバージョンアップに要する費用が発生する。
（３）共通部分のプログラムをバージョンアップせずにコマンド追加の対応困難
個別パッケージのハードウェアの機能を使用するためのインターフェースとして、共通パッケージから個別パッケージに対して使用する機能に対応したコマンドを用いる。ところが、個別パッケージのハードウェアをバージョンアップして機能を追加する場合、バージョンアップした機能が使用できるように、開発当初は使用しない機能に対応するコマンドについても時間をかけて正常に動作するか否かの評価を行わなければならない。さらに、実際にハードウェアのバージョンアップ開発を行うと、共通パッケージと個別パッケージとの間のコマンド（インタフェース）の見直しを行いたいような事態が生じる場合が多い。このような場合、従来のシステム構成ではコマンドがプログラムに組み込まれているため、共通部分のプログラムをバージョンアップせずに対応することはできない。
【０００８】
上記課題に鑑み、本発明の目的は、システムの評価期間、共通部分のプログラムのバージョンアップ作業および費用を大幅に削減でき、共通部分のプログラムをバージョンアップせずに新たなコマンドの追加が可能な機能追加型制御装置および機能追加型制御システムを提供することである。
【課題を解決するための手段】
【０００９】
請求項１に係る発明は、機能のアップグレードが可能な複数の個別パッケージと、前記複数の個別パッケージを監視制御する共通パッケージとを有する機能追加型制御装置において、前記複数の個別パッケージと前記共通パッケージとの間に、前記複数の個別パッケージの監視制御を行うための信号と、パッケージの制御を行うために前記共通パッケージにより実行される制御プログラムおよび制御コマンドの少なくとも一方を転送するための信号とを送受信するバスを設け、前記個別パッケージは、自パッケージ用の前記制御プログラムおよび前記制御コマンドの少なくとも一方を格納する個別パッケージ側メモリと、自パッケージの実装時に前記個別パッケージ側メモリに格納された前記制御プログラムおよび前記制御コマンドの少なくとも一方を前記バスを介して前記共通パッケージに転送する制御部とを有し、前記共通パッケージは、前記個別パッケージの制御を行うための制御プログラムおよび制御コマンドを格納するプログラムメモリおよびコマンドメモリを別々に有する共通パッケージ側メモリと、前記個別パッケージから転送される前記制御プログラムおよび前記制御コマンドの少なくとも一方を前記共通パッケージ側メモリに展開し、前記共通パッケージ側メモリの前記制御プログラムおよび前記制御コマンドを用いて前記複数の個別パッケージの監視制御を行う監視制御部とを有し、さらに、前記プログラムメモリは、複数のサブプログラムが記憶されるサブプログラムメモリと、メインプログラムと、前記メインプログラムから前記サブプログラムメモリに記憶されている前記サブプログラムへのジャンプ先アドレスと、を記憶するメインプログラムメモリとを独立して有することを特徴とする。
【００１０】
請求項２に係る発明は、請求項１に記載の機能追加型制御装置において、前記監視制御部は、前記個別パッケージから転送される前記制御プログラムまたは前記制御コマンドが前記プログラムメモリまたは前記コマンドメモリに保持されていない場合に、前記プログラムメモリまたは前記コマンドメモリに記憶することを特徴とする。
【００１１】
請求項３に係る発明は、請求項２に記載の機能追加型制御装置において、前記監視制御部は、前記個別パッケージから転送される前記制御プログラムまたは前記制御コマンドのバージョンが前記プログラムメモリまたは前記コマンドメモリに保持されている前記制御プログラムまたは前記制御コマンドのバージョンより新しい場合に、前記プログラムメモリまたは前記コマンドメモリに保持されている前記制御プログラムまたは前記制御コマンドを更新することを特徴とする。
【００１２】
請求項４に係る発明は、請求項１から３のいずれか一項に記載の機能追加型制御装置において、前記プログラムメモリは、異なる２つのプログラムを格納する実行用プログラムメモリと予備用プログラムメモリとを有し、前記コマンドメモリは、異なる２つのコマンドを格納する実行用コマンドメモリと予備用コマンドメモリとを有し、前記監視制御部は、前記実行用プログラムメモリと前記実行用コマンドメモリに保持されている前記制御プログラムおよび前記制御コマンドを用いて前記複数の個別パッケージの監視制御を前記バスを介して行い、前記個別パッケージから前記バスを介して転送される前記制御プログラムおよび前記制御コマンドを前記予備用プログラムメモリおよび前記予備用コマンドメモリにそれぞれ格納した後、前記予備用プログラムメモリおよび前記予備用コマンドメモリと前記実行用プログラムメモリおよび前記実行用コマンドメモリとを切り替えることを特徴とする。
【００１３】
請求項５に係る発明は、請求項２に記載の機能追加型制御装置において、前記監視制御部は、前記個別パッケージから転送される前記制御プログラムまたは前記制御コマンドのバージョンが前記プログラムメモリまたは前記コマンドメモリに保持されている前記制御プログラムまたは前記制御コマンドのバージョンより古い場合に、前記プログラムメモリまたは前記コマンドメモリに保持されている前記制御プログラムまたは前記制御コマンドを前記バスを介して前記個別パッケージの前記個別パッケージ側メモリに転送することを特徴とする。
【００１４】
請求項６に係る発明は、請求項１から５のいずれか一項に記載の機能追加型制御装置において、前記共通パッケージに回路記述プログラムによる回路の書き換えが可能なハードウェアデバイスが搭載されている場合に、前記個別パッケージ側メモリは、前記ハードウェアデバイスの回路記述プログラムを格納し、前記監視制御部は、前記個別パッケージから転送される前記回路記述プログラムのバージョンが前記ハードウェアデバイスに搭載されている回路記述プログラムのバージョンより新しい場合に、前記個別パッケージから転送される前記回路記述プログラムを新たに前記ハードウェアデバイスに搭載することを特徴とする。
【００１５】
請求項７に係る発明は、請求項１から６のいずれか一項に記載の機能追加型制御装置と、オペレーションシステムによって前記機能追加型制御装置を管理する上位の監視制御装置とを用いる機能追加型制御システムにおいて、前記監視制御部は、前記監視制御装置に対して制御を受け付けないモードへの移行を知らせる非制御通知を送信後、前記プログラムメモリまたは前記コマンドメモリに保持されている前記制御プログラムまたは前記制御コマンドを更新し、全ての更新を完了した時に前記監視制御装置に対して実装完了通知を送信し、前記監視制御装置は、前記機能追加型制御装置の前記監視制御部から前記非制御通知を受信してから前記実装完了通知を受信するまで前記機能追加型制御装置に対する制御を行わないことを特徴とする。
【発明の効果】
【００１７】
本発明に係る機能追加型制御装置および機能追加型制御システムは、バージョンアップ開発時における評価期間の短縮を図ることができ、短納入を実現することができる。また、システムの利用者や開発者はバージョンの管理を行う必要がなくなり、管理の手間や費用を大幅に削減することができ、バージョンアップに掛かる人件費などの費用を削減できる。
【００１８】
特に、本発明に係る機能追加型制御装置および機能追加型制御システムでは、監視制御を行う共通パッケージを独立した装置（いわゆる箱物）として開発し、共通パッケージが監視制御する個別パッケージ側にアップグレードするハードウェアと、そのハードウェアを監視制御するための共通パッケージ用のプログラムとを搭載させておくので、装置の出荷時には共通パッケージ側の機能のみを検証するだけでよく、個別パッケージをアップグレードするための評価期間を大幅に短縮することができる。
【００１９】
また、各バージョンアップ時には、バージョンアップ対象のハードウェア検証が必要であるが、共通パッケージのプログラムのメイン部分には個別パッケージ毎のジャンプ先アドレスが記されているだけなので、メインプログラムと個別パッケージ用のプログラムとを切り離して考えることができる。これにより、バージョンアップされる個別パッケージのハードウェアを動かすための個別パッケージ用のプログラムのみを切り離して検証することができ、メインプログラムの検証は不要になり、機能のデグレードなどの検証も少なく済むので全体の評価期間を短縮することができる。
【００２０】
さらに、バージョンアップ用のプログラムは、バージョンアップされるハードウェアの個別パッケージ側が持っており、そのプログラムを自動的に共通パッケージ側にアップロードするので、プログラムのバージョンアップを行う際の特別な人的作業や費用が発生しない。尚、従来のシステムでも、本発明を適用したシステムでもハードウェアを追加するための作業は必ず人が行わなければいけないが、本発明ではプログラムのバージョンアップに掛かる費用を削減できるという効果がある。
【００２１】
また、バージョンアップされるハードウェアの個別パッケージ側に自分自身を制御するためのコマンドと、そのコマンドに対応する共通パッケージ側の動作に関するデータとを持っており、それを自動的に共通パッケージ側にアップロードするので、新たに共通パッケージ側のプログラムのバージョンアップを行う必要がなく、開発のやり直しなどバージョンアップに要する余計な費用の発生を少なくすることができる。
【図面の簡単な説明】
【００２２】
【図１】第１実施形態に係る通信システム１００および通信装置１０１の構成を示す図である。
【図２】バージョンアップ処理を示すフローチャートである。
【図３】制御コマンド格納メモリ２０５の一例を示す図である。
【図４】メインプログラム格納メモリ２０３およびサブプログラム格納メモリ２０４の一例を示す図である。
【図５】第２実施形態に係る通信装置１５１の構成を示す図である。
【図６】従来の通信システム６００および通信装置６０１の構成を示すブロック図である。
【発明を実施するための形態】
【００２３】
以下、本発明に係る「機能追加型制御装置および機能追加型制御システム」の実施形態について図面を用いて詳しく説明する。尚、以下の実施形態では、本発明に係る機能追加型制御装置および機能追加型制御システムとして、通信装置および複数の通信装置を監視制御する監視制御装置を設けた通信システムに適用する場合の例について説明するが、様々な機能の追加を行う必要がある制御装置や制御システムであれば同様に適用可能である。
【００２４】
（第１実施形態）
図１は、第１実施形態に係る通信装置１０１と、監視制御装置１０２とで構成される通信システム１００のシステム全体を示す図である。尚、通信装置１０１ａおよび通信装置１０１ｂは、通信装置１０１と同様の装置である。
【００２５】
ここで、通信装置１０１は、様々な機能を実現するために機能毎に設けられた複数の個別部分（個別パッケージ）と、複数の個別パッケージの監視および制御などを行うための共通部分（共通パッケージ）とで構成される。例えば通信装置１０１は、上位側のネットワークや下位側のネットワーク或いは端末などを接続するための複数のＩＦ（インターフェース）盤、装置全体の動作状態を監視したり、設定変更などの制御を行うためのＣＰＵ盤（制御盤）、クロックを供給するクロック盤、パケットの宛先に応じて経路を選択するＳＷ（スイッチ）盤、温度管理を行うためのＦＡＮ盤などで構成される。ここで、従来の技術でも説明したように、本実施形態では、個別の機能を実現する部分を個別パッケージ、装置全体で共通に必要な機能を有する共通部分を共通パッケージと定義し、例えば通信装置１０１の場合は、個別パッケージ１０４として通信速度や機能が異なる複数のＩＦ盤を想定し、共通パッケージ１０３として装置全体の制御や監視を行うＣＰＵ盤を想定して説明を行うものとする。そして、通信装置１０１全体で共通に使用するクロック盤、ＳＷ盤、ＦＡＮ盤などのパッケージについては、図１では共通機能部４０１としてまとめて記載してある。
【００２６】
図１において、通信装置１０１は、ＣＰＵ盤に相当する共通パッケージ１０３と、様々な機能を有するＩＦ盤に相当する個別パッケージ１０４ａ、個別パッケージ１０４ｂ、個別パッケージ１０４ｃの３つの個別パッケージとを有する。ここで、以降の説明において、個別パッケージ１０４ａ、個別パッケージ１０４ｂ、個別パッケージ１０４ｃに共通の事項を説明する場合は、個別パッケージ１０４と称する。
【００２７】
本実施形態に係る通信装置１０１および通信システム１００は、個別パッケージ１０４のＩＦ盤をバージョンアップする場合に、通信システム１００および通信装置１０１の評価期間や共通パッケージ１０３のプログラムのバージョンアップ作業および費用を大幅に削減でき、共通パッケージ１０３のメインプログラムをバージョンアップすることなく、新たなコマンドの追加ができるようになっている。例えば、個別パッケージ１０４ａが１ＧｂｐｓのＩＦ盤として運用している場合に、新たに１０ＧｂｐｓのＩＦを追加するようなバージョンアップを行う場合、個別パッケージ１０４ａのＩＦ盤のハードウェアの変更と、そのハードウェアを制御するためのプログラムやコマンドを共通パッケージ１０３に追加しなければならないが、本実施形態に係る通信装置１０１では、バージョンアップ用のプログラムやコマンドが個別パッケージ１０４ａ自身が保持しており、個別パッケージ１０４ａの実装時に共通パッケージ１０３側に自動的にアップロードするようになっている。これにより、評価期間やバージョンアップ作業および費用を大幅に削減でき、新たなコマンドの追加も容易に実現することができる。
【００２８】
［通信装置１０１の構成］
図１において、通信装置１０１は、共通パッケージ１０３と、個別パッケージ１０４と、監視制御用バス１０５と、プログラム転送バス１０６とで構成される。尚、図１は、通信装置１０１の監視制御処理に必要なブロックのみを記載してあり、通信装置１０１本来の動作を行うブロック、例えば各個別パッケージ１０４にユーザーネットワークやユーザー端末などを接続するためのポートやスイッチなどは、本実施形態で説明する監視制御には直接関係しないので省略してある。
【００２９】
また、本発明の特徴がわかり易いように、監視制御用バス１０５と、プログラム転送バス１０６とを個別に配置する構成にしたが、帯域の広いバスを利用できる場合は、監視制御用の信号とプログラム転送用の信号とを多重して、物理的に１本のバスで送受信するようにしても構わない。
・共通パッケージ１０３の構成
図１において、ＣＰＵ盤に相当する共通パッケージ１０３は、通信装置１０１全体の制御を行うためのＣＰＵやＤＳＰなどで構成される共通ＰＫＧ制御部２０１と、プログラムを実行する際に用いるワークメモリ（実行メモリ）２０２と、共通ＰＫＧ制御部２０１で通信装置１０１全体の基本動作を実行するためのプログラムが格納されているメインプログラム格納メモリ２０３と、アップロードされた個別パッケージ１０４のプログラムを格納するサブプログラム格納メモリ２０４と、監視制御ＩＦ２０６を介して接続される監視制御装置１０２のＯＳ２６１から個別パッケージ１０４を監視制御する際の操作インターフェースを提供する制御コマンドが格納された制御コマンド格納メモリ２０５とで構成される。ここで、メインプログラム格納メモリ２０３、サブプログラム格納メモリ２０４、制御コマンド格納メモリ２０５は、それぞれ２面の記憶領域を持っており、片方の面の記憶領域は共通ＰＫＧ制御部２０１が使用中のメインプログラム、サブプログラム、コマンドデータベースが格納され、別の面の記憶領域には個別パッケージ１０４側からアップロードされるサブプログラムやコマンドデータベース、或いは監視制御装置１０２のＯＳ２６１側から転送されるメインプログラムなどが格納される。
【００３０】
このように、２面構成にすることにより、仮にバージョンが古いサブプログラムで他の個別パッケージ１０４が監視制御されていた場合でも、バージョンアップ中の動作を中断せずに監視制御を続けることができる。また、バージョン変更される予定のメインプログラム、サブプログラム、コマンドなどに不具合が生じた場合に、各メモリの記憶面を切り替えるだけで、直ぐに前の正常な動作状態に戻すことができる。
【００３１】
尚、ワークメモリ２０２は、メインプログラム格納メモリ２０３やサブプログラム格納メモリ２０４に記憶されたプログラムを実行する際にパラメータやデータを一時的に記憶するためのメモリである。また、共通ＰＫＧ制御部２０１は、通信装置１０１全体の制御を行うブロックであるが、本実施形態では個別パッケージ１０４の監視制御処理について説明するので、図１の共通ＰＫＧ制御部２０１には、個別パッケージ１０４の監視制御処理を行う監視制御処理部２５１のみを記載し、通信装置１０１全体の制御を行う処理ブロックは省略してある。
【００３２】
また、本実施形態に係る通信装置１０１では、一般的な通信装置と同様に、通信装置１０１の共通パッケージ１０３と個別パッケージ１０４との間は、監視制御を行う際の制御データを送受信するための監視制御用バス１０５で接続されている。さらに、本実施形態に係る通信装置１０１では、監視制御用バス１０５とは別に、共通パッケージ１０３と個別パッケージ１０４との間は、個別パッケージ１０４から共通パッケージ１０３にバージョンアップのためのプログラムやコマンドをアップロードするためのプログラム転送バス１０６で接続されている。
【００３３】
ここで、一般に用いられてる監視制御用バス１０５は、共通パッケージ１０３と個別パッケージ１０４との間で監視制御用の制御コマンドや応答メッセージを送受信するだけなので、低速のデータ伝送バス１本で十分であったが、本実施形態に係る通信装置１０１では、バージョンアップに必要なプログラムやコマンドリストなどの多くの情報を個別パッケージ１０４から共通パッケージ１０３にアップロードする必要があり、監視制御用バス１０５を共用した場合に、従来の監視制御用のデータ転送に支障をきたしてしまう可能性がある。このため、本実施形態に係る通信装置１０１では、監視制御用バス１０５とプログラム転送バス１０６の２種類のデータバスを配置して、バージョンアップ情報をアップロード中でも監視制御を行うことができ、監視制御のパフォーマンスが低下しないようにしている。
・個別パッケージ１０４の構成
図１において、ＩＦ盤に相当する個別パッケージ１０４ａは、自分自身の機能を実現するハードウェアと共通パッケージ１０３との間で監視制御処理に伴う情報の入出力を行う個別ＰＫＧ制御部３０１ａと、自分自身を監視制御するためのサブプログラムや自分自身を制御するためのコマンドを搭載したサブプログラム・コマンド格納メモリ３０２ａとを有する。同様に、個別パッケージ１０４ｂおよび個別パッケージ１０４ｃにおいても、それぞれ個別ＰＫＧ制御部３０１ｂおよび個別ＰＫＧ制御部３０１ｃ、サブプログラム・コマンド格納メモリ３０２ｂおよびサブプログラム・コマンド格納メモリ３０２ｃが搭載されている。ここで、以降の説明において、個別ＰＫＧ制御部３０１ａ、個別ＰＫＧ制御部３０１ｂ、個別ＰＫＧ制御部３０１ｃに共通の事項を説明する場合は、個別ＰＫＧ制御部３０１と称する。同様に、サブプログラム・コマンド格納メモリ３０２ａ、サブプログラム・コマンド格納メモリ３０２ｂ、サブプログラム・コマンド格納メモリ３０２ｃに共通の事項を説明する場合は、サブプログラム・コマンド格納メモリ３０２と称する。
【００３４】
個別ＰＫＧ制御部３０１は、サブプログラム・コマンド格納メモリ３０２に記憶されている自分自身のハードウェアを制御するためのプログラム（共通パッケージ１０３の共通ＰＫＧ制御部２０１で実行するプログラム）と、自分自身を制御するためのコマンド（監視制御装置１０２のＯＳ２６１および共通パッケージ１０３の共通ＰＫＧ制御部２０１から発行されるコマンド）とを共通パッケージ１０３側にプログラム転送バス１０６を介してアップロードする処理を実行する。また、共通パッケージ１０３側からの要求に応じて、サブプログラム・コマンド格納メモリ３０２に保持しているプログラムやコマンドのバージョンを監視制御用バス１０５を介して共通パッケージ１０３に応答する処理を行う。尚、個別ＰＫＧ制御部３０１は、個別パッケージ１０４が通信装置１０１に実装されて電源の供給が開始されると、自身の個別パッケージ１０４を動作可能な状態に起動し、通電により実装されたことを検知して、監視制御用バス１０５を介して共通パッケージ１０３側に実装通知を行う。
【００３５】
ここで、本実施形態に係る通信システム１００および通信装置１０１の特徴がわかり易いように、従来の通信システム６００および通信装置６０１の構成を図６に示す。尚、図６の６＊＊の符号のブロック、７＊＊の符号のブロック、８＊＊の符号のブロック、９＊＊の符号のブロックは、それぞれ図１の１＊＊の符号のブロック、２＊＊の符号のブロック、３＊＊の符号のブロック、４＊＊の符号のブロックに対応し、同様の目的に使用されるブロックなので詳細な説明は省略する。ここでは、大きく異なる部分についてのみ説明する。
（１）共通パッケージ１０３と共通パッケージ６０３との違い
図６において、共通パッケージ６０３は、共通パッケージ１０３のように、メインプログラム格納メモリ２０３、サブプログラム格納メモリ２０４、制御コマンド格納メモリ２０５が設けられておらず、プログラムメモリ７０３にまとめられている。つまり、プログラムメモリ７０３の中に、メインプログラムやサブプログラムおよび制御コマンドなどが直接書き込まれている。このため、初期開発時に、今後のバージョンアップで要求されるであろう個別パッケージ６０４のハードウェアを予測して、そのハードウェアを監視・制御するための共通パッケージ６０３のプログラムを最初からプログラムメモリ７０３に盛り込んでおく必要があり、多大なシステム検証期間が必要となる。
【００３６】
また、個別パッケージ６０４のハードウェアをバージョンアップして機能を追加する場合、バージョンアップした機能が使用できるように、開発当初は使用しない機能に対応するコマンドについても時間をかけて正常に動作するか否かの評価を行わなければならない。さらに、実際にハードウェアのバージョンアップ開発を行うと、共通パッケージ６０３と個別パッケージ６０４との間の制御コマンドの見直しを行う必要が生じる場合が多い。このような場合、共通パッケージ６０３のプログラムメモリ７０３のメインプログラムの中に制御コマンドが組み込まれているため、プログラムメモリ７０３のメインプログラムを含めてバージョンアップしなければならず、共通部分のプログラムをバージョンアップせずにコマンド追加の対応が困難である。
【００３７】
このように、バージョンアップ対象となる個別パッケージ６０４のハードウェアと、監視制御等を行う共通パッケージ６０３のプログラムとの両方について煩雑なバージョンアップを行わなければならず、バージョンアップ作業および費用が高くなる。さらに、プログラムや制御コマンドなどのバージョン管理も行わなければならず、管理費用も発生する。
【００３８】
これに対して、本実施形態に係る通信装置１０１では、個別パッケージ１０４側に自身を監視制御するための共通パッケージ１０３側のサブプログラムと、制御コマンドとを保持しておき、実装時に共通パッケージ１０３側に自動的にアップロードするので、共通部分のプログラムのバージョンアップ作業および費用を大幅に削減でき、共通部分のプログラムをバージョンアップせずに新たなコマンドの追加が可能となる。さらに、本実施形態に係る通信装置１０１では、メインプログラム格納メモリ２０３と、サブプログラム格納メモリ２０４と、制御コマンド格納メモリ２０５とを独立して設け、個別パッケージ１０４を制御するためのサブプログラムをメインプログラムから分離して、メインプログラム格納メモリ２０３にはサブプログラムのジャンプアドレステーブルのみを記載しているので、新たな機能の個別パッケージ１０４が実装された場合でも、メインプログラムの検証を削減できる。また、制御コマンドについても、制御コマンド格納メモリ２０５で管理することによって、同じ機能の個別パッケージ１０４に対する制御コマンドのバージョン管理を自動的に行うことができる。さらに、古いバージョンのサブプログラムや制御コマンドがサブプログラム・コマンド格納メモリ３０２に保持された個別パッケージ１０４に対しては、共通パッケージ１０３側が保持している同じ機能の新しいバージョンのサブプログラムや制御コマンドをダウンロードして、当該個別パッケージ１０４が他の装置に転用された場合でも新しいバージョンの個別パッケージ１０４として利用することができるという効果も得られる。
【００３９】
このように、本実施形態に係る通信システム１００および通信装置１０１は、システムの評価期間、共通部分のプログラムのバージョンアップ作業および費用を大幅に削減でき、共通部分のプログラムをバージョンアップせずに新たなコマンドの追加を行うことができる。
【００４０】
［バージョンアップ処理］
次に、本実施形態に係る通信装置１０１におけるバージョンアップ処理について、図２のフローチャートを用いて説明する。図２のフローチャートは、通信装置１０１側の共通パッケージ１０３と個別パッケージ１０４との間で監視制御用バス１０５またはプログラム転送バス１０６を介して送受信される情報の流れと、通信装置１０１と監視制御装置１０２のＯＳ２６１との間で物理ライン１０７を介して送受信される情報の流れを示した図である。以下、本フローチャートに従って、各個別パッケージ１０４が通信装置１０１に実装されたときに各個別パッケージ１０４のサブプログラム・コマンド格納メモリ３０２に保持されているサブプログラムおよびコマンドデータベースを共通パッケージ１０３側に転送する処理と、共通パッケージ１０３側のプログラムおよびコマンドの更新処理のシーケンスについて、順番に説明する。尚、個別パッケージ１０４が通信装置１０１に実装された時点から処理を開始する。
【００４１】
（ステップＳ１０１）個別パッケージ１０４は、通信装置１０１側から電源が供給されると、個別ＰＫＧ制御部３０１が起動され、自パッケージ内のレジスタリセット等のハードウェア的な処理（処理Ａ）を完了する。
【００４２】
（ステップＳ１０２）個別パッケージ１０４の個別ＰＫＧ制御部３０１は、共通パッケージ１０３側の共通ＰＫＧ制御部２０１に対して監視制御用バス１０５を介して実装通知メッセージを送信する。尚、実装通知メッセージには、自身の個別パッケージ１０４のパッケージの種類に関する情報が含まれている。例えばパッケージの種類として１ＧｂｐｓＩＦ盤や１０ＧｂｐｓＩＦ盤、或いはさらに詳細に機能ａと機能ｂとを有するＩＦ盤などの情報が含まれる。また、製造番号などの情報を実装通知メッセージに含めてもよい。
【００４３】
（ステップＳ１０３）共通パッケージ１０３の共通ＰＫＧ制御部２０１は、実装通知を受信した個別パッケージ１０４に対して監視制御用バス１０５を介してサブプログラムのバージョン要求を送信する。
【００４４】
（ステップＳ１０４）個別パッケージ１０４の個別ＰＫＧ制御部３０１は、サブプログラム・コマンド格納メモリ３０２に保持しているサブプログラムのバージョンを監視制御用バス１０５を介して共通パッケージ１０３側に送信する。
【００４５】
（ステップＳ１０５）共通パッケージ１０３の共通ＰＫＧ制御部２０１は、個別パッケージ１０４側から受信したサブプログラムのバージョンが新バージョンであるか否かを判別し、新バージョンである場合は次のステップＳ１０６に進み、新バージョンではない場合はステップＳ１０９に進む。ここで、共通ＰＫＧ制御部２０１は、サブプログラム格納メモリ２０４に格納されている同じ機能の個別パッケージ１０４のサブプログラムのバージョンと比較して、新バージョンであるか否かを判別する。尚、同じ機能の個別パッケージ１０４であるか否かの判別は、ステップＳ１０２で受信する個別パッケージ１０４のパッケージの種類に関する情報から知ることができる。
【００４６】
（ステップＳ１０６）共通パッケージ１０３の共通ＰＫＧ制御部２０１は、実装通知を受信した個別パッケージ１０４に対して監視制御用バス１０５を介してサブプログラムのアップロード要求を自動的に送信する。
【００４７】
（ステップＳ１０７）個別パッケージ１０４の個別ＰＫＧ制御部３０１は、サブプログラムデータ転送モードになり、サブプログラム・コマンド格納メモリ３０２に保持している自身のハードウェアの機能を利用するためのサブプログラムのアップロードをプログラム転送バス１０６を介して共通パッケージ１０３側に送信する。
【００４８】
一方、個別パッケージ１０４側から受信するサブプログラムは、共通パッケージ１０３の共通ＰＫＧ制御部２０１によってワークメモリ２０２に一時的に取り込まれる。
【００４９】
（ステップＳ１０８）個別パッケージ１０４の個別ＰＫＧ制御部３０１は、サブプログラム・コマンド格納メモリ３０２に保持している自身を制御するためのコマンドデータベースのアップロードをプログラム転送バス１０６を介して共通パッケージ１０３側に送信する。
【００５０】
一方、個別パッケージ１０４側から受信するコマンドデータベースは、共通パッケージ１０３の共通ＰＫＧ制御部２０１によってワークメモリ２０２に一時的に取り込まれる。
【００５１】
（ステップＳ１０９）共通パッケージ１０３の共通ＰＫＧ制御部２０１は、次のような処理Ｂを実行する。
【００５２】
処理Ｂは、個別パッケージ１０４から受信したサブプログラムおよびコマンドデータベースに転送エラーがなかったどうかを個別パッケージ１０４からこれらの情報が送信される際に付加されたＣＲＣエラーチェックやチェックサムを用いて確認する。そして、転送エラーが有った場合は再びステップＳ１０６に戻って再送処理を行い、転送エラーが無かった場合は、ワークメモリ２０２に一時的に保持されているサブプログラムをサブプログラム格納メモリ２０４に展開する。この時、サブプログラム格納メモリ２０４は、先に説明したように２面の記憶領域を持っており、共通ＰＫＧ制御部２０１が使用中のサブプログラムが格納されていない方の記憶領域にワークメモリ２０２に一時的に保持されているサブプログラムを格納する。同様に、制御コマンド格納メモリ２０５は、先に説明したように２面の記憶領域を持っており、共通ＰＫＧ制御部２０１が使用中の制御コマンドが格納されていない方の記憶領域にワークメモリ２０２に一時的に保持されているコマンドデータベースを格納する。これにより、仮にバージョンが古いサブプログラムで他の個別パッケージ１０４が監視制御されていた場合でも、バージョンアップ中の動作を中断せずに監視制御を続けることができる。
【００５３】
尚、共通ＰＫＧ制御部２０１は、コマンドデータベースの展開処理を行う場合に、既に制御コマンド格納メモリ２０５に記憶されているコマンドからの更新かそれとも新規追加かを判別し、新規追加ならそのまま追加し、更新なら今までのものを削除した上で、今回アップロードされた新たなコマンドに更新する処理を自動的に判断して行う。これは、図３に示すように、各コマンドにバージョンを記すことにより、共通ＰＫＧ制御部２０１がコマンドのバージョンを確認することができ、上記のような判断が可能である。図３は、制御コマンド格納メモリ２０５に格納されるコマンドデータベースの一例を示す図である。コマンドデータベースは機能毎にコマンドがまとめられており、同じ機能を有する個別パッケージ１０４に共通に用いられる。図３の例では、機能Ａ用のコマンドＤＢ（データベース）、機能Ｂ用のコマンドＤＢおよび機能Ｃ用のコマンドＤＢにそれぞれの機能に共通するコマンドについて、コマンド名、コマンドの動作などがデータベースとしてまとめられている。例えば機能Ａ用コマンドＤＢ２０５ａのバージョンはＶｅｒ１．０で、○○機能ブロックのリセットを行うためのコマンドＡ１、××機能ブロックの制御を開始するためのコマンドＡ２などがあることがわかる。尚、コマンドデータベースのバージョンは機能毎に管理され、例えば、機能Ｂ用コマンドＤＢ２０５ｂのバージョンは１．２、機能Ｃ用コマンドＤＢ２０５ｃのバージョンは２．０であることがわかる。
【００５４】
ここで、図３では、共通パッケージ１０３の制御コマンド格納メモリ２０５に格納されている各機能毎のコマンドデータベースの例を示したが、個別パッケージ１０４側のサブプログラム・コマンド格納メモリ３０２に格納されているコマンドデータベースも同様の情報が記憶されており、例えば個別パッケージ１０４ａのサブプログラム・コマンド格納メモリ３０２ａには、図３の機能Ａ用のコマンドＤＢ２０５ａと同様のコマンドデータベースが記憶されている。これにより、個別パッケージ１０４側から受信したコマンドデータベースのバージョンと、共通パッケージ１０３側の制御コマンド格納メモリ２０５で保持している同じ機能のコマンドデータベースのバージョンが同じであるか否かを共通ＰＫＧ制御部２０１が確認することができる。
【００５５】
以上説明したように、ステップＳ１０１からステップＳ１０９までの処理が、バージョンアップ時に行われる一連の転送処理である。次に転送されたプログラムの更新処理について説明する。
【００５６】
（ステップＳ１１０）共通パッケージ１０３の共通ＰＫＧ制御部２０１は、監視制御装置１０２のＯＳ２６１に対して制御を受け付けないモードへ移行することを通知する。これは、共通パッケージ１０３がプログラムを更新処理中にＯＳ２６１から制御コマンドが発行され、これを実行するために何らかの処理ルーチンに入っている途中で、プログラムの更新処理が行われてしまい、コマンドの処理が中途半端な状態で終わってしまうのを防ぐためのガード機能である。
【００５７】
ここで、図４を用いて、本実施形態に係る通信装置１０１のプログラムの構成について説明する。図４は、メインプログラム格納メモリ２０３（２面の記憶領域の内の片面）と、サブプログラム格納メモリ２０４（２面の記憶領域の内の片面）との構成例を示す図である。メインプログラム格納メモリ２０３は、メインプログラム２０３ａの部分と、サブプログラムのジャンプアドレス２０３ｂの部分とで構成される。メインプログラム２０３ａは、監視制御装置１０２のＯＳ２６１との間の通信処理、バージョン管理や実装管理など各個別パッケージ１０４に共通の処理、各個別パッケージ１０４に対応する処理（サブプログラムのジャンプアドレスを介する独立した処理）、その他の装置異常の検出やアラーム出力など通信装置１０１全体の処理などを実行する。また、サブプログラム格納メモリ２０４には、サブプログラムジャンプアドレス２０３ｂに対応する各アドレス毎にサブプログラムが記載されており、各サブプログラムを実行すると、メインプログラム２０３ａに処理が戻される（ＲＥＴＵＲＮ）。
【００５８】
特に本実施形態に係る通信装置１０１は、メイン処理のプログラムコードを格納するメインプログラム２０３ａ部分から各個別パッケージ１０４のハードウェアを利用するためのサブプログラムへのジャンプアドレスだけを参照する構成になっている。例えば図４のサブプログラムジャンプアドレス２０３ｂには、個別パッケージ１０４ａに対するサブプログラムのジャンプアドレスとして、制御用のサブプログラムＡ１へのジャンプアドレス２０３ｂ１、監視用のサブプログラムＡ２へのジャンプアドレス２０３ｂ２が記載されている。同様に、個別パッケージ１０４ｂに対するサブプログラムのジャンプアドレスとして、制御用のサブプログラムＢ１へのジャンプアドレス２０３ｂ３、監視用のサブプログラムＢ２へのジャンプアドレス２０３ｂ４が記載されている。個別パッケージ１０４ｃについても同様に、制御用のサブプログラムＣ１へのジャンプアドレス２０３ｂ５、監視用のサブプログラムＣ２へのジャンプアドレス２０３ｂ６が記載されている。
【００５９】
尚、サブプログラムへのジャンプアドレスは、サブプログラム格納メモリ２０４（２面の記憶領域の内の片面）上のアドレスを示しており、サブプログラム格納メモリ２０４に格納されたサブプログラムを実行後、サブプログラム上でリターンが実行されるとメインプログラム２０３ａに処理が戻されるようになっており、メインプログラム格納メモリ２０３上のサブプログラムジャンプアドレスを参照するサブルーチンとして各サブプログラムが実行される。例えば、図４において、メインプログラム２０３ａの中で、個別パッケージ１０４ａを制御する場合は、サブプログラムジャンプアドレス２０３ｂの個別パッケージ１０４ａを制御するためのサブプログラムＡ１へのジャンプアドレス２０３ｂ１を参照して、サブプログラム格納メモリ２０４のサブプログラムＡ１にジャンプする。そして、サブプログラムＡ１を実行後に例えばＲＥＴＵＲＮ（リターン）を実行すると、メインプログラム２０３ａに処理が戻される。尚、サブプログラムＡ２へのジャンプアドレス２０３ｂ２、サブプログラムＢ１へのジャンプアドレス２０３ｂ３などについても同様に実行される。
【００６０】
（ステップＳ１１１）共通パッケージ１０３の共通ＰＫＧ制御部２０１は、処理Ｃを実行する。処理Ｃは、メインプログラム２０３ａから新たに追加された個別パッケージ１０４を制御できるように、個別パッケージ１０４からアップロードされてサブプログラム格納メモリ２０４に格納されているサブプログラムを呼び出すためのサブプログラムジャンプアドレス２０３ｂを書き換える処理である。
【００６１】
ここで、ステップＳ１１０で監視制御を受け付けないモードへ移行することにより、メインプログラム２０３ａからサブプログラムへのジャンプ処理が実行されないので、メインプログラム格納メモリ２０３に記述されているサブプログラムジャンプアドレス２０３ｂを書き換えても支障は生じない。また、プログラムのジャンプアドレスのみ書き換えればよいので、短時間で処理が完了する。尚、このジャンプアドレスが参照するサブプログラムのジャンプ先は、サブプログラム格納メモリ２０４に新たに展開された面のサブプログラムに対応する。
【００６２】
（ステップＳ１１２）共通パッケージ１０３の共通ＰＫＧ制御部２０１は、監視制御装置１０２のＯＳ２６１に新たに追加された個別パッケージ１０４の実装完了通知を送信する。この実装完了通知を受信した監視制御装置１０２のＯＳ２６１は、ステップＳ１１０で受信した監視制御を受け付けないモードへ移行通知を解除して監視制御を再開する。
【００６３】
このようにして、一連のバージョンアップ処理を終了し、共通パッケージ１０３の共通ＰＫＧ制御部２０１は通常動作に戻り、監視制御装置１０２のＯＳ２６１からの制御コマンドを受け付け、通常通りに個別パッケージ１０４の監視制御を行うことができる。
【００６４】
ここで、上記の説明では、プログラムおよびコマンドデータベースのアップロード以外のメッセージの送受信を監視制御用バス１０５を介して行うようにしたが、バージョンアップに関する全ての情報の送受信をプログラム転送バス１０６を介して行うようにしても構わない。
【００６５】
尚、ある個別パッケージ１０４のバージョンアップ処理中に、他の個別パッケージ１０４が新たに通信装置１０１に実装された場合、新たに実装された個別パッケージ１０４が送信する実装通知を受信した共通ＰＫＧ制御部２０１部は、新たに実装された個別パッケージ１０４に対するバージョンアップ処理を保留にして、バージョンアップ中の処理を完了後に、保留していた個別パッケージ１０４に対するバージョンアップ処理を実行する。
【００６６】
また、バージョンアップされた個別パッケージ１０４と同じ機能を有する他の個別パッケージ１０４が既に通信装置１０１に実装されている場合、共通ＰＫＧ制御部２０１は、既に実装されている個別パッケージ１０４のバージョンと新たにバージョンアップされた個別パッケージ１０４のバージョンとを比較する。そして、既に実装されている個別パッケージ１０４のバージョンが新たにバージョンアップされた個別パッケージ１０４のバージョンよりも古い場合、共通ＰＫＧ制御部２０１部は、バージョンアップされた同じ機能のサブプログラムを既に実装されている個別パッケージ１０４のサブプログラム・コマンド格納メモリ３０２にダウンロードする。これにより、同じ機能の個別パッケージ１０４のバージョンを最新バージョンに自動的に統一することができる。尚、ステップＳ１０５で新たに実装された個別パッケージ１０４のサブプログラムのバージョンが同じであった場合は、ダウンロードやアップロードを行う必要はない。
【００６７】
このように、新たに実装された個別パッケージ１０４に搭載されているサブプログラムのバージョンが古い場合、その後のバージョン管理で混乱をきたす可能性があるため、共通パッケージ１０３側の新しいバージョンのサブプログラムを古いバージョンのサブプログラムを有する個別パッケージ１０４のサブプログラム・コマンド格納メモリ３０２にダウンロードしておく。ダウンロードの方法は、例えば監視制御装置１０２のＯＳ２６１から指示が行われ、アップロードとは逆のルーチンで、サブプログラム格納メモリ２０４から該当するサブプログラムをワークメモリ２０２に一旦転送し、ワークメモリ２０２からバージョンが古い個別パッケージ１０４のサブプログラム・コマンド格納メモリ３０２にプログラム転送バス１０６を介して転送する。尚、ダウンロードの場合、個別パッケージ１０４のサブプログラム・コマンド格納メモリ３０２は、通常運用中の各個別パッケージ１０４の動作とは切り離されているので、記憶領域を２面持つ必要はない。
【００６８】
また、図２のフローチャートでは、サブプログラムが最初から共通パッケージ１０３側に保持されていることを前提として説明したが、個別パッケージ１０４側に新たに実装された個別パッケージ１０４の機能に対応するサブプログラムが全く保持されていない場合は、ステップＳ１０５のバージョン確認処理は、同じ機能のサブプログラムの有無の確認をする処理に読み替えればよい。
【００６９】
このように、本実施形態に係る通信システム１００および通信装置１０１は、システムの評価期間、共通部分のプログラムのバージョンアップ作業および費用を大幅に削減でき、共通部分のプログラムをバージョンアップせずに新たなコマンドの追加を行うことができる。
【００７０】
（第２実施形態）
次に、第２実施形態に係る通信装置１５１について図５を用いて説明する。通信装置１５１は、図１の第１実施形態で説明した通信装置１０１と基本的な構成は同じである。ここで、図５において、図１と同符号のものは同じものを示す。
【００７１】
図５において、共通パッケージ１５３、個別パッケージ１５４および個別ＰＫＧ制御部３５１は、図１の共通パッケージ１０３、個別パッケージ１０４および個別ＰＫＧ制御部３０１にそれぞれ対応する。尚、個別パッケージ１５４には、図１のサブプログラム・コマンド格納メモリ３０２の代わりにＦＰＧＡプログラム格納メモリ３５２が搭載されている。尚、図５において、個別パッケージ１５４ａ、個別パッケージ１５４ｂ、個別パッケージ１５４ｃに共通の事項を説明する場合は、個別パッケージ１５４と称する。同様に、個別ＰＫＧ制御部３５１ａ、個別ＰＫＧ制御部３５１ｂ、個別ＰＫＧ制御部３５１ｃに共通の事項を説明する場合は、個別ＰＫＧ制御部３５１と称する。ＦＰＧＡプログラム格納メモリ３５２ａ、ＦＰＧＡプログラム格納メモリ３５２ｂ、ＦＰＧＡプログラム格納メモリ３５２ｃについても同様に、ＦＰＧＡプログラム格納メモリ３５２と称する。
【００７２】
本実施形態に係る通信装置１５１は、共通機能部４０１のハードウェア回路を構成するＦＰＧＡ４０２をバージョンアップすることができる。尚、ＦＰＧＡ４０２は、回路記述言語を書き換えることによって、ハード的な回路をソフトウェアのように変更できるデバイスである。
【００７３】
例えば、共通機能部４０１のハードウェアが個々の個別パッケージ１５４に応じて変更するのが非常に都合がよい場合、例えば信号のフォーマットが個別パッケージ１５４によって異なるような場合、動作する個別パッケージ１５４に応じて共通機能部４０１のハードウェアを変更する。特に、新たに実装された個別パッケージ１５４に共通機能部４０１の新たなハードウェアが必要になった場合などに使用する。
【００７４】
図５において、共通機能部４０１は、個別パッケージ１５４と同様に、監視制御用バス１０５とプログラム転送バス１０６とが接続されている。そして、書き換え可能なＦＰＧＡ４０２が搭載され、このＦＰＧＡ４０２の監視制御を監視制御用バス１０５を介して行う。また、共通パッケージ１５３の共通ＰＫＧ制御部２０１には、ワークメモリ２０２と、共通プログラム格納メモリ４０３と、ＦＰＧＡプログラム格納メモリ４０４とが配備されている。尚、共通プログラム格納メモリ４０３の代わりに、第１実施形態の図１で説明したように、メインプログラム格納メモリ２０３と、サブプログラム格納メモリ２０４と、制御コマンド格納メモリ２０５とを配備してもよい。
【００７５】
ここで、個別パッケージ１５４ａを通信装置１５１内に新たに実装する場合、第１実施形態で説明したように、監視制御用バス１０５を介して共通ＰＫＧ制御部２０１に実装通知を出力する（図２のステップＳ１０２の処理に相当）。共通ＰＫＧ制御部２０１は、実装通知を受けて、個別パッケージ１５４ａのＦＰＧＡ３５２ａに保持されているＦＰＧＡプログラムのバージョンを要求する（図２のステップＳ１０３からステップＳ１０４の処理に相当）。共通パッケージ１５３のＦＰＧＡプログラム格納メモリ４０４に格納されているＦＰＧＡのデータのバージョン（共通機能部４０１のＦＰＧＡ４０２に実装されているバージョンに相当）に比べて新しいか古いかを判別する（図２のステップＳ１０５の処理に相当）。ここで、バージョンが古かったり、同じバージョンのものが既に共通パッケージ１５３内に存在していた場合は、ＦＰＧＡプログラムのバージョンアップ処理は行わずに、監視制御装置１０２のＯＳ２６１に対して新たに実装された個別パッケージ１５４ａの制御が可能になったことを通知するだけでよい（図２のステップＳ１１２の処理に相当）。反対に、新たに実装された個別パッケージ１５４ａに搭載されているＦＰＧＡプログラムのバージョンが共通パッケージ１５３内に存在するものより新しかったり、全くなかった場合は、共通ＰＫＧ制御部２０１が個別パッケージ１５４ａに対してＦＰＧＡプログラムの転送要求を行い、要求を受けた個別パッケージ１５４ａは、プログラム転送バス１０６を介してＦＰＧＡプログラムの転送を開始する。転送処理が完了すると、共通ＰＫＧ制御部２０１は転送されたＦＰＧＡプログラムのデータにエラーがないか否かチェックし、ＦＰＧＡプログラム格納メモリ４０４のスタンバイ面（２面あるメモリの現在使っていない方のメモリ）にデータの展開を開始し、データの展開完了後、プログラム転送バス１０６を介して共通機能部４０１のＦＰＧＡ４０２のプログラムの書き換えを行う。ここで、一連の動作は、すべて自動的に行われるため、保守担当者がＦＰＧＡプログラムのバージョンを管理する必要がなくなり、顧客は維持管理コストを削減することができる。
【００７６】
このように、本実施形態に係る通信装置１５１は、新たに実装された個別パッケージ１５４に対応するように、共通機能部４０１のハードウェアを構成するＦＰＧＡ４０２のプログラムのバージョンアップを自動的に行うことができるので、バージョンアップ作業および費用を大幅に削減できる。
【００７７】
以上、本発明に係る機能追加型制御装置および機能追加型制御システムについて、実施例を挙げて説明してきたが、その精神またはその主要な特徴から逸脱することなく他の多様な形で実施することができる。そのため、上述した実施例はあらゆる点で単なる例示に過ぎず、限定的に解釈してはならない。本発明は、特許請求の範囲によって示されるものであって、本発明は明細書本文にはなんら拘束されない。さらに、特許請求の範囲の均等範囲に属する変形や変更は、全て本発明の範囲内である。
【符号の説明】
【００７８】
１００・・・通信システム
１０１、１５１・・・通信装置
１０２・・・監視制御装置
１０４、１０４ａ、１０４ｂ、１０４ｃ、１５４、１５４ａ、１５４ｂ、１５４ｃ・・・個別パッケージ
１０３、１５３・・・共通パッケージ
１０５・・・監視制御用バス
１０６・・・プログラム転送バス
２０１・・・共通ＰＫＧ制御部
２０３・・・メインプログラム格納メモリ
２０３ａ・・・メインプログラム
２０３ｂ・・・サブプログラムジャンプアドレス
２０４・・・サブプログラム格納メモリ
２０５・・・制御コマンド格納メモリ
２０６・・・監視制御ＩＦ
２６１・・・ＯＳ
３０１、３０１ａ、３０１ｂ、３０１ｃ、３５１、３５１ａ、３５１ｂ、３５１ｃ・・・個別ＰＫＧ制御部
３０２、３０２ａ、３０２ｂ、３０２ｃ・・・サブプログラム・コマンド格納メモリ
３５２、３５２ａ、３５２ｂ、３５２ｃ・・・ＦＰＧＡプログラム格納メモリ
【図１】
0005545759.tif 000002
【図２】
0005545759.tif 000003
【図３】
0005545759.tif 000004
【図４】
0005545759.tif 000005
【図５】
0005545759.tif 000006
【図６】
0005545759.tif 000007