(57)【特許請求の範囲】
【請求項１】
アプリケーションソフトを機能別に分離生成してデータ領域に分離して実装し、
前記データ領域には、実装している現行のアプリケーションソフトを現アプリソフトとして展開する領域とは別に、前記現アプリソフトにおける更新用のアプリケーションソフトを新アプリソフトとして展開するための空き領域を設け、
前記空き領域に前記新アプリソフトを展開し、当該新アプリソフトが動作した後、更新前の前記現アプリソフトを旧アプリソフトとして削除するアプリソフトマネージャを備え、
自局である保護リレー装置と相手局である保護リレー装置とのサンプリングタイミングを同期させるためのサンプリング周期を生成するクロックを備え、
前記アプリソフトマネージャは、アプリケーションソフトの実装状態を管理するソフト管理テーブルを備え、前記クロックが生成するサンプリング周期で起床し、前記データ領域に展開されたアプリソフトが全て動作した後に、前記旧アプリソフトを削除して前記ソフト管理テーブルの実装状態の変更を行う保護リレー装置。
【請求項２】
前記データ領域に前記空き領域を複数設け、前記アプリソフトマネージャは、複数の前記空き領域に対して前記新アプリソフトを同時に展開する請求項１に記載の保護リレー装置。
【請求項３】
前記新アプリソフトと、削除の対象となる前記旧アプリソフトとが並列的に動作する時、これら両アプリソフト動作後の実行結果を比較して前記新アプリソフトが適正か否かを診断するデータ診断部を備え、前記データ診断部は、前記新アプリソフトを不適正と診断すれば前記旧アプリソフトの実行結果を継続して採用し、前記新アプリソフトを適正と診断すれば、前記新アプリソフトの実行結果を採用する請求項１又は２に記載の保護リレー装置。
【請求項４】
前記アプリソフトマネージャは、前記データ領域に展開されたアプリソフトの実行順序を設定し、前記各アプリソフト動作後の実行結果を前記各アプリソフトが共有するメモリに上書きする請求項１〜３のいずれか１項に記載の保護リレー装置。
【請求項５】
前記アプリソフトマネージャは、前記旧アプリソフトの削除指定を外部から受けると、前記データ領域に展開されたアプリソフトの動作後、指定された前記旧アプリソフトを削除する請求項１〜４のいずれか１項に記載の保護リレー装置。
【請求項６】
外部から転送される前記新アプリソフトを取り込み、当該新アプリソフトを所定のメモリに保存すると共に、当該新アプリソフトを取り込んだことを前記アプリソフトマネージャに通知するプログラムローダを備えた請求項１〜５のいずれか１項に記載の保護リレー装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、搭載するアプリケーションソフトの更新を行う保護リレー装置に関する。
【背景技術】
【０００２】
一般に、電力系統には、送電線保護システムや、系統安定化制御システムが適用されている。送電線保護システムでは、送電線の事故を検出して事故区間を切り離すことにより、事故波及を防止している。系統安定化制御システムでは、発電変電所の系統事故を検出して周波数脱調等の系統不安定事象を予測し、発電機等を系統から切り離すことで、電力系統の安定化を図っている。
【０００３】
上記のシステムには、電流差動演算や安定度演算などを行う保護リレー装置（以降、単にリレーとも呼ぶ）が多岐の用途にわたって適用されている。リレーは、送電線区間や発変電所の各端子に設置されている。各リレーは、各端子から電流値や電圧値、接点情報等の電気量データを計測入力し、他のリレーや計算機等と通信で電気量データを授受し合い、電流差動演算や安定度演算を行っている。
【０００４】
前記した電流差動演算や安定度演算の機能は、電流差動保護アプリや系統安定化アプリといったアプリケーションソフト（以降、アプリソフトと呼ぶ）により実現される。これらのアプリソフトを実行するためには基本ソフトウェアであるＯＳが必須である。また近年では、外部のＰＣからネット経由で、アプリソフトのプログラムデータを取得することも一般的となっている。そのため、リレーには、演算機能を実現するためのアプリソフトに加えて、通信ソフトや信号入出力ソフトなどのソフトも搭載されている。
【０００５】
これらソフトは、プログラムとしては機能別に個々に分離されて実装されている。通常、分離された複数のソフトは、リンカで１つに組み合わされてロケータで物理アドレスにマッピングされ、実行可能なオブジェクトが生成されて、不揮発メモリであるＲＯＭに書き込まれる。リレー起動後は、ＲＯＭから読み出したソフトを順次実行させる。なお、ＲＯＭではデータ読み出しに必要なWait数が大きく命令実行速度が低下するため、通常は初期化処理で各ソフトをＲＯＭからＲＡＭにデータコピーし、ＲＡＭ上で実行ソフトを展開させている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平９−１６３６３８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、リレーに搭載されるアプリソフトは、処理不備の修正や機能拡張といったバージョンアップ的な変更を行う必要があり、任意のタイミングで、その更新を実施している。アプリソフトを更新する場合、アプリソフトの動作途中で、アプリソフトのプログラムデータを書き換えると、アプリソフトが不正動作する可能性がある。
【０００８】
そこで、アプリソフトの更新に際しては、リレーに実装されている現行のアプリソフトの動作を停止させ、これを旧アプリソフトとして削除し、その後、更新用の新アプリソフトをＲＯＭに書き込んで、アプリソフトのプログラムデータを書き換えている。その後、リセットないし電源切入を行ってリレーの初期化処理を行い、初期化処理により新アプリソフトをＲＡＭに再展開して、新アプリソフトを動作させている。以上の手順では、現行のアプリソフトを旧アプリソフトとして削除してから、新アプリソフトを展開させるので、新旧２つのアプリソフトが同時に存在することはない。したがって、アプリソフトの不正動作を防止することはできる。
【０００９】
しかしながら、旧アプリソフトの削除後、新アプリソフトを動作させるまでの間は、このアプリソフトは非実装状態になり、アプリソフトによる機能は停止することになる。例えば、電流差動保護アプリを更新する場合は、旧アプリソフトを削除してから新アプリソフトの実行が完了するまでの間、電流差動保護機能がロックすることになる。
【００１０】
このように、従来技術では、アプリソフトの更新に際して、更新されるアプリソフトが、いったん実装されていない状態となり、このアプリソフトにより実現される機能が、一時的に停止することがあった。また、アプリソフトの更新作業には初期化処理が不可欠であるため、アプリソフトの更新作業時間が長期化していた。したがって、リレーの稼働率ならびにメンテナンス効率が低下するという不具合が生じた。
【００１１】
本発明の実施形態は、上記の課題を解決するために提案されたものであり、アプリソフトの更新時に、アプリソフトにて実現される機能が停止することがなく、しかも初期化処理の実施を回避することができ、稼働率およびメンテナンス効率の向上を図った保護リレー装置を提供することを目的とする。
【課題を解決するための手段】
【００１２】
上記目的を達成するために、本実施形態に係る監視制御装置は、次の構成要素（１）〜（５）を備える。
（１）アプリケーションソフトを機能別に分離生成してデータ領域に分離して実装する。
（２）前記データ領域には、実装している現行のアプリケーションソフトを現アプリソフトとして展開する領域とは別に、前記現アプリソフトにおける更新用のアプリケーションソフトを新アプリソフトとして展開するための空き領域を設ける。
（３）前記空き領域に前記新アプリソフトを展開し、当該新アプリソフトが動作した後、更新前の前記現アプリソフトを旧アプリソフトとして削除するアプリソフトマネージャを備える。
（４）自局である保護リレー装置と相手局である保護リレー装置とのサンプリングタイミングを同期させるためのサンプリング周期を生成するクロックを備える。
（５）前記アプリソフトマネージャは、アプリケーションソフトの実装状態を管理するソフト管理テーブルを備え、前記クロックが生成するサンプリング周期で起床し、前記データ領域に展開されたアプリソフトが全て動作した後に、前記旧アプリソフトを削除して前記ソフト管理テーブルの実装状態の変更を行う。
【図面の簡単な説明】
【００１３】
【図１】第１の実施形態の構成を示すブロック図。
【図２】電流差動保護用のリレーの通信接続構成を示す構成図。
【図３】データ領域に展開されるソフト群の動作シークエンスを示すブロック図。
【図４】第１の実施形態におけるアプリソフトマネージャのソフト管理テーブル（更新前）。
【図５】第１の実施形態におけるアプリソフトマネージャのソフト管理テーブル（新アプリソフト追加後）。
【図６】第１の実施形態におけるアプリソフトマネージャのソフト管理テーブル（旧アプリソフト削除後）。
【図７】第２の実施形態の構成を示すブロック図。
【図８】第２の実施形態のデータ診断部の構成図。
【図９】第２の実施形態のデータ診断部の管理テーブル（診断時）。
【図１０】第２の実施形態のデータ診断部の管理テーブル（診断解除時）。
【図１１】第３の実施形態におけるアプリソフトマネージャのソフト管理テーブル（実行順序情報付加）。
【発明を実施するための形態】
【００１４】
（１）第１の実施形態
（構成）
以下、本発明の実施形態に係る保護リレー装置について、図１〜図６を参照して具体的に説明する。下記のリレーは、電流差動保護アプリや系統安定化アプリといったアプリソフトを機能別に分離生成してデータ領域に分離して実装している。
【００１５】
（概要）
これらのアプリソフトを搭載するリレーの概要について説明する。例えば、リレーが電流差動保護アプリを実装している場合、このアプリが電流差動演算機能を実現すると、リレーは、送電線を保護する電流差動保護用リレーとなる。電流差動保護とは、送電線の各区間の電流値（交流波形）を入力して流入量を比較し、これにより送電線区間事故を検出するもので、自端電流量と、通信で受信した相手端電流量とを用いている。
【００１６】
電流差動保護用リレーでは、自端電流量のＡＩタイミング（以降、サンプリングタイミング）と、相手端のサンプリングタイミングに誤差があると、電流量の比較で差電流が生じ、正確な保護が行えない。このため、電流差動保護用リレーでは、自局のリレーと相手局のリレーとの局間で同期通信を行い、高精度のサンプリング同期を実施している。したがって、電流差動保護リレーには通常、サンプリング同期制御機構が搭載されており、サンプリング同期を実施したリレー間通信が行われている。
【００１７】
（通信接続構成）
図２では、電流差動保護用のリレーの通信接続構成を示している。送電線２４の各送電線端である端子ａには主局リレーＲ１が配置され、同じく端子ｂには従局リレーＲ２が配置されている。これらリレーＲ１、Ｒ２には通信線２５が接続されている。リレーＲ１、Ｒ２は、配置された送電線端の電気量を入力すると共に、通信線２５にて相手端へ自端電気量を送信し合っている。
【００１８】
このようなＲ１、Ｒ２では、サンプリング同期により同時刻の電流量を得ている。この電流量を用いて、電流差動保護アプリが差動演算を行い、これにより送電線２４に事故が発生したことを検出するようになっている。リレーＲ１、Ｒ２が送電線２４の事故を検出すると、遮断器にトリップ信号を出力して事故区間を切り離すことができる。
【００１９】
（アプリソフトを更新するための構成）
以上のようなリレーにてアプリソフトを更新するための構成について、図１のブロック図を用いて説明する。図１に示すように、リレー１には、既定のサンプリング周期を生成するクロック３と、外部のＰＣ２０とネットワーク２１などを介して接続されるＰＣ通信チャネル４と、局間通信を行うための局通信チャネル６が設けられている。また、リレー１には、フラッシュメモリであるＦＲＯＭ５と、ＡＩ（アナログ入力）およびＤＩ（デジタル入力）するためのＡＩ、ＤＩチャネル７と、ＤＯ（デジタル出力）するためのＤＯチャネル８が設けられている。
【００２０】
（データ領域内の構成要素）
さらに、リレー１には、ＲＡＭからなるデータ領域２が設けられている。データ領域２には、基本ソフトウェアであるＯＳ９をはじめとして、信号入出力ソフト１０と、局通信ソフト１１と、電流差動保護アプリであるアプリソフトＡ１２と、系統安定化アプリであるアプリソフトＢ１３など、各種のソフトが実装されている。また、データ領域２には、アプリソフトマネージャ１５と、入出力データテーブル１６と、出力データ合成部１７と、プログラムローダ１８が設けられている。
【００２１】
（データ領域内のソフト群）
ＯＳ９は、処理プログラムのタスクスケジューリングやメモリ管理や時間管理等、資源の割り当て等を担っている。このＯＳ９以外のソフト１０〜１３（点線で囲む）は、アプリソフトマネージャ１５によって管理されており、入出力データテーブル１６との間でデータの授受を行うように構成されている。
【００２２】
信号入出力ソフト１０は、ＡＩ、ＤＩチャネル７およびＤＯチャネル８に接続されるソフトである。信号入出力ソフト１０は、既定周期で動作し、ＡＩ、ＤＩチャネル７を介してＡＩ（アナログ入力）、ＤＩ（デジタル入力）した入力データを、入出力データテーブル１６に格納する。また、信号入出力ソフト１０は、入出力データテーブル１６から出力データを取り出して、ＤＯチャネル８を通じてＤＯ（デジタル出力）する。ＡＩ（アナログ入力）とは、電流量や電圧量などのアナログ値の入力であり、Ａ／Ｄ変換を含む。以降、Ａ／Ｄ変換したデータを電気量データと呼ぶ。ＤＩ（デジタル入力）は接点状態などであり、ＤＯ（デジタル出力）はトリップ出力などである。
【００２３】
局通信ソフト１１は、局通信チャネル６に接続されたリレー間通信用のソフトであり、入出力データテーブル１６から、自局の電気量情報や接点情報、トリップ情報、動作状態や不良状態などの管理情報を取り出して相手局に送信する。また、局通信ソフト１１は、受信した相手局の同情報つまり電気量情報や接点情報、トリップ情報、管理情報を入出力データテーブル１６に格納する。
【００２４】
アプリソフトＡ１２およびアプリソフトＢ１３は、現行のアプリソフトとして現行領域１４ａ（太い点線にて示す）に展開されている。この現行領域１４ａとは別に、更新した時のアプリソフトＣ、Ｄを展開するための空き領域１４ｂ（一点鎖線にて示す）が設けられている。空き領域１４ｂ内のアプリソフトＣ、Ｄは、更新作業を行う前には、後述するアプリソフトマネージャ１５のソフト管理テーブルでの実装状態が「実装無し」の状態であり、図１では「空き」として示している。
【００２５】
（アプリソフトマネージャ）
アプリソフトマネージャ１５は、アプリソフトを更新するための主要な構成要素である。アプリソフトマネージャ１５は、アプリケーションソフトの実装状態を管理するソフト管理テーブルを備えている。
【００２６】
アプリソフトマネージャ１５は、空き領域１４ｂに、更新用のアプリケーションソフトである新アプリソフトを展開し、この新アプリソフトが動作した後、更新前の現アプリソフトを旧アプリソフトとして削除する。アプリソフトマネージャ１５は、クロック３が生成するサンプリング周期で起床し、データ領域２に展開されている全てのソフト１０〜１３（点線で囲む）を順次実行する。
【００２７】
クロック３が生成するサンプリング周期は、電気角３０度周期としており、クロック３から生成される電気角３０度のサンプリングタイミングを割り込み信号として割り当てている。クロック３から割り込み信号が入ると、ＯＳ９の割り込み処理を介して、アプリソフトマネージャ１５が起床する。
【００２８】
図３はデータ領域２に展開されるソフト群の動作シークエンスを示している。図３に示すように、アプリソフトマネージャ１５が起床すると、信号入出力ソフト１０、局通信ソフト１１、アプリソフトＡ１２、アプリソフトＢ１３が順次起床する。このとき、各ソフト１０〜１３は入出力データテーブル１６との間で、データを授受して、データの更新や参照を行う。さらに、ソフト１０〜１３が順次起床した後、アプリソフトマネージャ１５は、アプリソフトの実装状態を変更するなど、ソフト管理テーブルの情報を書き換える。アプリソフトマネージャ１５は、ソフト管理テーブルにより、indexを立て、index毎に、アプリソフトの実装状態やプログラム実行番地（実行ソフトの先頭アドレス）、ソフトバージョンなどの情報を管理する。
【００２９】
また、アプリソフトマネージャ１５は、プログラムローダ１８によっても起床する。プログラムローダ１８によって起床したアプリソフトマネージャ１５は、ＰＣ２０から転送された新アプリソフトをプログラムローダ１８から受け取る。また、アプリソフトマネージャ１５は、ソフト管理テーブルから空き領域１４ｂを検索して、空き領域１４ｂを見つけ、見つけた空き領域１４ｂに、プログラムローダ１８から受け取った新アプリソフトを展開する。
【００３０】
新アプリソフトを展開したアプリソフトマネージャ１５は、ソフト管理テーブルにおけるアプリソフトの実装状態を、「実装無し」から「実装有り」に変更する。前述したように、アプリソフトマネージャ１５はクロック３が生成するサンプリング周期で起床するが、起床したアプリソフトマネージャ１５は、データ領域２に展開されているアプリソフトを全て実行する。
【００３１】
その後、アプリソフトマネージャ１５は、現アプリソフトの中で、新アプリソフトと対応する更新前のアプリソフトを停止させ、この停止させた現アプリソフトを旧アプリソフトとして削除する。このとき、アプリソフトマネージャ１５は、ソフト管理テーブルを書き換え、アプリソフトの実装状態の有無をソフト管理テーブルに反映させる。
【００３２】
（入出力データテーブルおよび出力データ合成部）
入出力データテーブル１６は、データ領域２に展開されている信号入出力ソフト１０および局通信ソフト１１との間で、種々のデータを入出力する。また、入出力データテーブル１６は、データ領域２に展開しているアプリソフトに対してデータを入力する。出力データ合成部１７は、動作したアプリソフトの実行結果を受け取り、これらを合成して入出力データテーブル１６へ送るようになっている。
【００３３】
（プログラムローダ）
プログラムローダ１８はＰＣ２０から転送されたアプリソフトを、ＰＣ通信チャネル４を介して受け取る。アプリソフトのデータ内にはチェックサム値などの検定コードが格納されているため、プログラムローダ１８は、ＰＣ２０から受領したデータのチェックサム結果と検定コードとが一致するかどうかを確認することで、アプリソフトが破損していないことを判定する。このようにアプリソフトが破損していないか否かを判定した上で、プログラムローダ１８は、転送されたアプリソフトのプログラムデータを取り込み、取り込んだプログラムデータをＦＲＯＭ５へ保存する。また、既に述べたように、プログラムローダ１８はアプリソフトマネージャ１５を起床させるようになっている。
【００３４】
（作用）
以下、本実施形態によるアプリソフトの更新、例えば、電流差動保護の機能を一部変更し、電流差動保護のアプリソフトＡを更新するケースについて述べる。ここでのアプリソフトの更新は、処理不備の修正や機能拡張等のバージョンアップ的なアプリソフトの変更を指しており、基本的なインプットである「参照する入力情報」およびアウトプットである「処理結果に基づく出力情報」には特別な差異は無いものとする。更新作業の前の状態では、アプリソフトマネージャ１５はクロック３により既定周期で起床しており、電流差動保護のアプリソフトＡが動作して、入出力データテーブル１６の内容を元に、保護機能を実行している。
【００３５】
このような状態中に、更新した電流差動保護アプリｂであるアプリソフトＣ１９を、ＰＣ２０からＰＣ通信チャネル４に転送したとする。電流差動保護アプリｂは、電流差動保護アプリであるアプリソフトＡ１２のプログラムを一部修正したものである。ＰＣ通信チャネル４に転送されたアプリソフトＣ１９は、プログラムローダ１８に取り込まれる。
【００３６】
プログラムローダ１８はアプリソフトＣ１９の健全性を判定した上で、その健全性が確認されればアプリソフトＣ１９のプログラムデータをＦＲＯＭ５に保存する。さらに、プログラムローダ１８は、取り込んだアプリソフトＣ１９をアプリソフトマネージャ１５に通知する。
【００３７】
図４は、更新前のアプリソフトマネージャのソフト管理テーブルを示している。図４に示すように、アプリソフトマネージャ１５のソフト管理テーブルでは、index5のブロックが空き領域１４ｂなので、アプリソフトマネージャ１５は、この空き領域１４ｂを見つけて、ここにアプリソフトＣ１９を展開する。図５では、新アプリソフトを追加した後のアプリソフトマネージャ１５のソフト管理テーブルを示している。図５では、index5の実装状態が「実装無し」の状態から「実装有り」の状態に変化しており、ソフトバージョンが「０」から「２.０．1」に変化している。
【００３８】
クロック３により既定周期で起床したアプリソフトマネージャ１５は、ソフト管理テーブルのindexの順にソフトを起床させていく。すなわち、信号入出力ソフト１０、局通信ソフト１１、アプリソフトＡ１２、アプリソフトＢ１３が順次起床する。ソフト管理テーブルのindex5が「実装有り」であることから、アプリソフトＢ１３を起床した後、アプリソフトマネージャ１５はアプリソフトＣ１９を起床する。
【００３９】
前述したように、ここでのアプリソフトの更新はバージョンアップ的な変更であって、入出力情報に特別な差異は無いので、アプリソフトＡ１２とアプリソフトＣ１９は、同機能を発揮し、類似処理を実行することになる。したがって、入力情報が同一である定常時は、アプリソフトＡ１２とアプリソフトＣ１９の実行結果は、基本的に同一となる。
【００４０】
したがって、アプリソフトＡ１２およびアプリソフトＣ１９からは同一値が導かれ、同一値は出力データ合成部１７を介して入出力データテーブル１６に書き込まれる。このとき、アプリソフトＡ１２とアプリソフトＣ１９とは結合性はない。つまり、アプリソフトＡ１２およびアプリソフトＣ１９が同時に存在しても、お互い干渉のない処理が多重化していることと実質的に同意である。また、これらのアプリソフトＡ１２、Ｃ１９は他のソフトとも関連性はない。
【００４１】
しかし、アプリソフトＡ１２に動作不良要因がある場合には、要因成立条件によりアプリソフトＡ１２とアプリソフトＣ１９の演算結果が変化し、両者は不一致を起こす。このような事態を回避するために、アプリソフトマネージャ１５は、新アプリソフトであるアプリソフトＣ１９が動作を開始したら、旧アプリソフトであるアプリソフトＡ１２を削除すべきである。
【００４２】
そこで、本実施形態では、ＰＣ２０が外部からアプリソフトＡ１２の削除をアプリソフトマネージャ１５に通知し、アプリソフトマネージャ１５は、旧アプリソフトとしてアプリソフトＡ１２を削除する。このとき、アプリソフトマネージャ１５は、図６に示すように、index3の実装状態を「実装有り」の状態から「実装無し」の状態に変え、ソフトバージョンは「２.０.０」から「０」に変えて、ソフト管理テーブルを変更する。
【００４３】
アプリソフトマネージャ１５によるソフト管理テーブルの変更タイミングは、アプリソフトマネージャ１５が当該周期における一連のソフト群の実行を完了した後である（図３参照）。これにより、実行中にプログラムコードが書き換えられることで生じるアプリソフトＡ１２の不正動作を、確実に回避することができる。
【００４４】
（効果）
上記のように、本実施形態によれば、アプリソフトの更新に際して、更新用の新アプリソフトをＲＯＭに書き込み、この新アプリソフトと、削除対象となる旧アプリソフトとを共に展開させ、新アプリソフトを動作させてから、旧アプリソフトを削除している。したがって、新アプリソフトの動作が安定してから旧アプリソフトを削除することができ、アプリソフトが実現する機能を停止させることなく、アプリソフトの更新を実施することが可能である。
【００４５】
すなわち、アプリソフトの更新に際して、更新されるアプリソフトが実装されていない状態に陥ることがなく、このアプリソフトにより実現される機能の停止期間は全く無い。しかも、本実施形態では、アプリソフトの更新作業に初期化処理を実施する必要もない。このため、アプリソフトの更新作業に要する時間を短縮化することができる。これにより、リレーの稼働率ならびにメンテナンス効率の向上に寄与することが可能である。
【００４６】
また、アプリソフトマネージャ１５は、クロック３が生成するサンプリング周期で起床するので、アプリソフトの更新作業を、確実に実施することができる。しかも、アプリソフトマネージャ１５はアプリソフトの実装状態を管理するソフト管理テーブルを備えているため、アプリソフトの更新状態を的確に把握することが可能である。さらに、本実施形態では、プログラムローダ１８によって、取り込んだ新アプリソフトの健全性を判定することができるため、アプリソフトの更新時の信頼性がさらに向上する。
【００４７】
（第２の実施形態）
（構成）
第２の実施形態について、図７〜図１０を用いて説明する。図７に示すように、第２の実施形態では、データ領域２内にデータ診断部２２が設けられている。
【００４８】
データ診断部２２は、新アプリソフトと、削除対象となる旧アプリソフトとが並列的に動作する時、これら両アプリソフト動作後の実行結果を比較して新アプリソフトが適正か否か、つまりアプリソフトの動作の健全性を診断する。より詳しくは、データ診断部２２は、定常動作結果が新旧アプリで一致する（例えばデータ診断部の論理回路ＡＮＤをとると、結果１なら健全と判定でき、結果０なら不一致となり不健全と判定できるなど）、あるいは、ソフト変更した機能部位では動作結果が不一致となる、などの判定を行い、その判定結果に基づいてアプリソフトの動作の健全性を診断する。このようなデータ診断部２２は、新アプリソフトを不適正と診断すれば旧アプリソフトの実行結果を継続して採用し、新アプリソフトを適正と診断すれば、新アプリソフトの実行結果を採用するようになっている。
【００４９】
また、アプリソフトマネージャ１５は、新たに追加実装した新アプリソフトと、削除対象となる旧アプリソフトとを関連付けるようになっている。アプリソフトマネージャ１５は、データ診断部２２から判定結果を受け取り、ＰＣ通信チャネル４およびネットワーク２１を介してＰＣ２０に配信するようになっている。第２の実施形態に係るリレーでは、以上の点を除いた構成については上記第１の実施形態と同様であり、同一部分に関しては同一符号を付して説明を省略する。
【００５０】
図８はデータ診断部２２の構成図である。図８に示すように、データ診断部２２は、ＯＲ、ＡＮＤ、ＮＯＲ、ＮＡＮＤなどの論理回路を含んでおり、信号１、信号２を入力して、信号３を出力するようになっている。図９に示したデータ診断部２２の管理テーブルでは、信号１はアプリソフトＡ１２の演算結果、信号２はアプリソフトＣ１９の演算結果、信号３はアプリソフトマネージャ１５へ出力される演算結果、論理回路はＸＯＲ回路となっている。
【００５１】
（作用）
第２の実施形態では、データ診断部２２を採用したことで、新たに追加実装した新アプリソフトの健全動作を診断し、不正演算結果の採用を回避することができる。上記の第１の実施形態では、アプリソフトの更新に際して、アプリソフトＣ１９を追加して即動作する形態としている。しかし、アプリソフトＣ１９の実行ソフト生成ミスや、ＰＣ２０から転送するプログラムデータの選択ミスなどによって、アプリソフトＣ１９が期待した動作を行わないケースも想定される。
【００５２】
この場合に、アプリソフトＡ１２が適正な演算結果を算出していても、後に動作するアプリソフトＣ１９の不正演算結果が上書きされるとなると、健全な保護機能を損なってしまうおそれがある。そこで、第２の実施形態では、データ診断部２２によってアプリソフトＣ１９の健全動作を診断し、不正演算結果の採用を防ぐことができる。
【００５３】
アプリソフトマネージャ１５は、新たに実装したアプリソフトＣ１９を、アプリソフトＡ１２と関連付けており、アプリソフトＡ１２の演算結果とアプリソフトＣ１９の演算結果を、データ診断部２２にて比較判定する。双方のアプリソフト１２、１９が共に適正動作していれば、定常状態では両者の演算結果は一致することになる。
【００５４】
データ診断部２２では、アプリソフトＡ１２とアプリソフトＣ１９の演算結果を入力値としてＸＯＲ演算し、結果の出力先である信号３をアプリソフトマネージャ１５に接続する。両アプリソフト１２、１９の演算結果が同値であれば、信号３は０、不一致があれば信号３は０以外になる。
【００５５】
つまり、アプリソフト１２、１９の演算結果が一致していれば、データ診断部２２は「０」という信号３をアプリソフトマネージャ１５に出力する。これが、アプリソフトＣ１９は適正であるという診断結果である。データ診断部２２の診断結果は、アプリソフトマネージャ１５を介してＰＣ２０に配信される。
【００５６】
このとき、ＰＣ２０はアプリソフトマネージャ１５に対しデータ診断部２２の解除指令を出し、出力データ合成部１７へ信号連結させる。この診断解除時におけるデータ診断部２２の管理テーブルが図１０である。図１０の管理テーブルでは、信号１を０値固定にし、ＯＲ演算によりアプリソフトＣ１９の演算結果が、信号３として出力データ合成部１７に入る。これにより、データ診断部２２がアプリソフトＣ１９を適正と診断した場合は、アプリソフトＣ１９の実行結果を採用することになる。
【００５７】
一方、アプリソフト１２、１９の演算結果に不一致が起きていれば、データ診断部２２は「０」以外の信号３をアプリソフトマネージャ１５に出力する。これが、アプリソフトＣ１９が不適正であるという診断結果である。このデータ診断部２２の診断結果を受けると、旧アプリソフトであるアプリソフト１２の実行結果を採用し続ける。
【００５８】
（効果）
上記の第２の実施形態によれば、次のような独自の効果がある。第２の実施形態では、データ診断部２２によりアプリソフトの演算結果を事前に診断することで、展開した新アプリソフトの適正を判定することができ、信頼性が向上する。
【００５９】
また、第２の実施形態では、処理不備の修正の際には新アプリソフトと旧アプリソフトとの応動比較がデータ診断で実施することができ、効果検証が容易になる。すなわち、更新対象であるアプリソフトＡ１２に不備あり、新たなアプリソフトＣ１９として改修したケースでは、不備を伴う条件成立で、アプリソフトＡとアプリソフトＣの演算結果に不一致が生じる。したがって、改修効果を簡単に確認することができ、メンテナンス効率がいっそう向上する。
【００６０】
（３）第３の実施形態
（構成）
第３の実施形態に係るリレーでは、アプリソフトマネージャ１５が、データ領域２に展開されたアプリソフトの実行順序を設定し、各アプリソフト動作後の実行結果を各アプリソフトが共有するメモリに上書きするようになっている。第３の実施形態は上記の点を除き、基本的な構成については上記第１の実施形態と同様である。
【００６１】
（作用）
例えば、アプリソフトＡ１２とアプリソフトＣ１９とが並列的に連続実行された場合に、入出力データテーブル１６上のデータは、アプリソフトＡ１２が書き込んだ演算結果を、アプリソフトＣ１９の演算結果に書き換えることになる。したがって、アプリソフトＣ１９がアプリソフトＡ１２よりも優先されることになる。
【００６２】
定常状態ではアプリソフトＡ１２とアプリソフトＣ１９は同一演算結果のため、アプリソフトＣ１９がアプリソフトＡ１２よりも優先されたとしても支障ない。しかし、アプリソフトＣ１９の動作が適正であることを確認するまでは、アプリソフトＡ１２の演算結果をアプリソフトＣ１９よりも優先すべきケースもある。
【００６３】
そこで、第３の実施形態では、図１１に示すように、アプリソフトマネージャ１５のソフト管理テーブルに実行順序情報を付加している。図１１ではアプリソフトＡ１２の実行順序を４、アプリソフトＣ１９の実行順序を３としている。つまり、先にアプリソフトＣ１９を実行し、後からアプリソフトＡ１２を実行し、アプリソフトＣ１９の実行結果に、アプリソフトＡ１２の実行結果を上書きすることができる。これにより、アプリソフトＡ１２の演算結果をアプリソフトＣ１９よりも優先することが可能である。
【００６４】
なお、アプリソフトマネージャ１５がアプリソフトＡ１２を削除した以降は、ソフト管理テーブルを変更してindex3を実装無しとしているので、アプリソフトマネージャ１５は信号入出力ソフト１０、局通信ソフト１１と順次起床したら、アプリソフトＢ１３、アプリソフトＣ１９の順に起床する。
【００６５】
（効果）
上記の第３の実施形態によれば、アプリソフトマネージャ１５のソフト管理テーブルに実行順序情報を付加することで、更新後の新アプリソフトと、更新前の旧アプリソフトの実行順序を自由に設定することが可能である。これにより、実行結果を採用するアプリソフトの優先度を決めることができ、例えば、旧アプリソフトの演算結果を新アプリソフトよりも優先すべき場合に対応可能である。
【００６６】
［他の実施形態］
上記の実施形態は、本明細書において一例として提示したものであって、発明の範囲を限定することを意図するものではない。すなわち、その他の様々な形態で実施されることが可能であり、発明の範囲を逸脱しない範囲で、種々の省略や置き換え、変更を行うことが可能である。これらの実施形態やその変形例は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【００６７】
例えば、データ領域に空き領域を複数設け、アプリソフトマネージャが、複数の空き領域に対して新アプリソフトを同時に展開するようにしてもよい。このような実施形態によれば、さらに効率良く、更新作業を実施することができる。
【００６８】
また、分散して配置された複数のリレーにおいて、あるリレーが故障した場合、信号を共有する別のリレーに対し、故障したリレーに搭載されていたアプリソフトを追加するようにしてもよい。例えば、リレーと同じネットワークに接続されたサーバなどを監視装置とし、各この監視装置にてリレーの動作状態を通信で監視し、あるリレーが故障（動作停止）であると判定したら、アプリソフトマネージャにより、該当リレーが持つアプリソフト構成を、同ネットワークに接続される他リレーに展開することが可能である。このような実施形態によれば、任意のリレーが故障した場合でも、他リレー機能を停止させずに機能追加させることで、別のリレーが故障したリレーの役割を果たすことができる。これにより、リレーが分散配置された保護リレーシステムにおいて、稼働率が向上する。
【符号の説明】
【００６９】
１…リレー
２…データ領域
３…クロック
４…ＰＣ通信チャネル
５…ＦＲＯＭ
６…局通信チャネル
７…ＡＩ、ＤＩチャネル
８…ＤＯチャネル
９…ＯＳ
１０…信号入出力ソフト
１１…局通信ソフト
１２…アプリソフトＡ
１３…アプリソフトＢ
１４ａ…現行領域
１４ｂ…空き領域
１５…アプリソフトマネージャ
１６…入出力データテーブル
１７…出力データ合成部
１８…プログラムローダ
１９…アプリソフトＣ
２０…ＰＣ
２１…ネットワーク
２２…データ診断部
２４…送電線
２５…通信線
【図１】
0006546008.tif 000002
【図２】
0006546008.tif 000003
【図３】
0006546008.tif 000004
【図４】
0006546008.tif 000005
【図５】
0006546008.tif 000006
【図６】
0006546008.tif 000007
【図７】
0006546008.tif 000008
【図８】
0006546008.tif 000009
【図９】
0006546008.tif 000010
【図１０】
0006546008.tif 000011
【図１１】
0006546008.tif 000012