(57)【要約】【課題】リアルタイム性を損なわずに且つアプリソフトを停止させないで、アプリソフトの変更作業を可能にする。【解決手段】変更受付部１はアプリソフトの変更時に新機能データを受け取り、コンパイル部４は変更受付部１から新機能データを取得してコンパイルを行う。新機能スレッド管理部３からの要請を受けて現機能スレッド管理部２は動作中の機能スレッドの中で新関数名と一致する関数名を持つ機能スレッドを、旧機能スレッドとして破棄し、機能スレッド生成部７は新機能データに基づいて機能スレッドを生成する。オブジェクトファイル格納部６は、コンパイル部４によりコンパイルされた新たなオブジェクトファイルを格納し、機能スレッド生成部７が機能スレッドを生成すると、新たなオブジェクトファイルから関数を動的にリンクする。【選択図】図１
2015148929.tif 000002
【特許請求の範囲】
【請求項１】
遠方監視制御を実現するための機能スレッドからなる遠方監視制御機能部を備えた遠方監視制御装置において、
アプリソフトの変更時に新機能データを受け取る変更受付部と、
前記新機能データを取得してコンパイルを行うコンパイル部と、
前記遠方監視制御機能部に含まれる機能スレッドの中から、前記新機能データと一致するデータを持つ機能スレッドを検索して、当該機能スレッドを旧機能スレッドとして破棄する現機能スレッド管理部と、
前記現機能スレッド管理部が前記旧機能スレッドを破棄すると、前記新機能データに基づいて機能スレッドを生成する機能スレッド生成部と、
前記コンパイル部によりコンパイルされた新たなオブジェクトファイルを格納し、前記機能スレッド生成部が新機能スレッドを生成すると、新たなオブジェクトファイルから関数を動的にリンクするオブジェクトファイル格納部を有することを特徴とする遠方監視制御装置。
【請求項２】
前記変更受付部、前記コンパイル部、前記現機能スレッド管理部及び前記機能スレッド生成部に、新機能スレッド管理部を接続し、
前記新機能スレッド管理部は、
前記変更受付部から前記新機能データを受け取るとこれを前記コンパイル部に渡し、
前記コンパイル部がコンパイル処理を終了すると前記現機能スレッド管理部に前記旧機能スレッドの破棄を要請し、
前記現機能スレッド管理部が前記旧機能スレッドを破棄すると前記機能スレッド生成部に前記新機能データを渡すことを特徴とする請求項１記載の遠方監視制御装置。
【請求項３】
前記遠方監視制御機能部に含まれる機能スレッドごとのバージョン情報を保存し、前記新機能スレッドのバージョンを確認するバーションチェック部を有することを特徴とする請求項１又は２に記載の遠方監視制御装置。
【請求項４】
前記新機能スレッドの動作確認を行うセルフチェック機能部を有することを特徴とする請求項１〜３のいずれか１項に記載の遠方監視制御装置。
【請求項５】
前記オブジェクトファイルが中間言語である場合、前記新機能スレッドを生成する際の動的なリンク時に前記オブジェクトファイルを逐次解析するインタプリタ部を有することを特徴とする請求項１〜４のいずれか１項に記載の遠方監視制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、遠方監視制御装置に搭載されるアプリケーションソフトウェア（以降アプリソフトと略す）の変更技術に関するものである。
【背景技術】
【０００２】
現場機器を遠方から監視制御する遠方監視制御装置は、遠方監視制御機能を実現するためのアプリソフトを搭載している。このアプリソフトに関しては必要に応じて変更作業を行っている。通常、遠方監視制御装置では、アプリソフトの変更作業に際して動作中のアプリソフトを停止させ、新しいアプリソフトのローディングした後、起動を行うのが一般的である。
【０００３】
つまり、アプリソフトの変更作業は、次の手順で実施している。
（１）ツールにより動作中のアプリソフトを停止。
（２）コンパイル済みの新しいアプリソフトをローディング。
（３）コマンドの実行又は電源活殺により新しいアプリソフトを起動。
【０００４】
以上のように、遠方監視制御装置ではアプリソフトの変更作業時に、動作中のアプリソフトが停止することで、アプリソフトによって実現される遠方監視制御機能が停止する。そのため、アプリソフトの変更作業時には現場機器を遠方から監視制御することができなくなる。
【０００５】
そこで従来から、動作中のアプリソフトを停止させずに、アプリソフトを変更する技術が提案されている。例えば、アプリソフトの機能ごとにプロセスを分割して、変更対象となるプロセスのみを終了させ、新たなプロセスをローディングして起動を行うといった方法が知られている（特許文献１など）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平１０−２８９１５８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、アプリソフトの機能ごとにプロセスを分割してアプリソフトの変更を行う場合、複数のプロセスが動作可能となるように、遠方監視制御装置に大容量のＲＡＭを設けなくてはならない。また、高速で動作するＣＰＵ又は複数のＣＰＵも不可欠となる。
【０００８】
しかし、遠方監視制御装置はリソースが脆弱であり、大容量のＲＡＭや高性能なＣＰＵを設けることは困難であった。また、上記のアプリソフトの変更方法では、大量のプロセス間通信を用いることになるため、オーバーヘッドが増加し、リアルタイム性が損なわれるといった問題がある。
【０００９】
本発明の実施形態は、以上の課題を解決するために提案されたものであり、１プロセス空間内で機能スレッドを生成する際、アプリソフトの変更に伴いコンパイルされたオブジェクトファイルを動的にリンクすることによって、リアルタイム性を損なわずに且つアプリソフトを停止させないで、アプリソフトの変更作業を可能にする遠方監視制御装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記の課題を解決するために、本発明の実施形態は、遠方監視制御を実現するための機能スレッドからなる遠方監視制御機能部を備えた遠方監視制御装置において、次のような構成要素（ａ）〜（ｅ）を有している。
（ａ）アプリソフトの変更時に新機能データを受け取る変更受付部。
（ｂ）前記新機能データを取得してコンパイルを行うコンパイル部。
（ｃ）前記遠方監視制御機能部に含まれる機能スレッドの中から、前記新機能データと一致するデータを持つ機能スレッドを検索し、当該機能スレッドを旧機能スレッドとして破棄する現機能スレッド管理部。
（ｄ）前記現機能スレッド管理部が前記旧機能スレッドを破棄すると、前記新機能データに基づいて機能スレッドを生成する機能スレッド生成部。
（ｅ）前記コンパイル部によりコンパイルされた新たなオブジェクトファイルを格納し、前記機能スレッド生成部が機能スレッドを生成すると、新たなオブジェクトファイルから関数を動的にリンクするオブジェクトファイル格納部。
【図面の簡単な説明】
【００１１】
【図１】第１の実施形態のブロック図。
【図２】第１の実施形態の要部ブロック図。
【図３】第２の実施形態のブロック図。
【図４】第３の実施形態のブロック図。
【図５】第４の実施形態のブロック図。
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態に係る遠方監視制御装置について、図面を参照して具体的に説明する。
（１）第１の実施形態
（構成）
図１に示すように、第１の実施形態は、１プロセス空間であるＲＡＭ領域が、データベース９を格納するデータベースエリアと、実施形態の要部であるアプリソフトエリアとに分けられている。アプリソフトエリアには、データベース９に接続される遠方監視制御機能部８が設けられている。
【００１３】
遠方監視制御機能部８は、遠方監視制御を実現するための機能スレッドから構成されている。一般に、アプリソフトの実行単位であるプロセスは、複数のアプリソフトを並列処理することは可能であるが、同一のアプリソフトを並列処理することはできない。これに対して、プロセスを処理する際の実行単位であるスレッドは、同一のアプリソフトの中でも並列処理を行うことができる。
【００１４】
アプリソフトエリアには、変更受付部１が設けられている。変更受付部１は、運用者からアプリソフトの変更を受け付け、アプリソフトの変更時に、新機能データとなる新機能の関数名を受け取る。この変更受付部１には、遠方監視制御装置にて動作中の機能スレッドを管理する現機能スレッド管理部２と、新機能スレッドの生成時に使用する新機能スレッド管理部３が接続されている。現機能スレッド管理部２は、遠方監視制御機能部８に含まれる機能スレッドの中から、新機能データと一致するデータつまり新機能の関数名と同じ関数名を持つ機能スレッドを検索し、検索された同一関数名の機能スレッドを旧機能スレッドとして破棄する。
【００１５】
新機能スレッド管理部３には、機能スレッド生成部７とコンパイル部４が接続されている。機能スレッド生成部７は現機能スレッド管理部２が旧機能スレッドを破棄すると、新機能の関数名に基づいて機能スレッドを生成する。機能スレッド生成部７および現機能スレッド管理部２は遠方監視制御機能部８に接続されている。
【００１６】
コンパイル部４は変更受付部１に入力されたソースのコンパイルを行う。コンパイル部４にはコンパイル結果を外部に出力表示する表示装置５と、コンパイルされたオブジェクトファイルを格納するオブジェクトファイル格納部６が接続されている。オブジェクトファイル格納部６は、遠方監視制御機能部８に接続しており、機能スレッド生成部７が機能スレッドを生成すると、新たなオブジェクトファイルから関数を動的にリンクする。
【００１７】
（作用）
以上のような構成を有する本実施形態は、次のようにして、アプリソフトの変更作業を行う。変更受付部１が運用者からアプリソフトの変更を受け付けると、アプリソフトに関するデータおよびファイルを入力する。
【００１８】
変更受付部１は、ファイルの名称に基づいて、入力したデータが新機能データか否かを判別し、入力データが新機能データであれば、新機能データが入力されたことを、新機能スレッド管理部３に通知する。変更受付部１から通知を受けた新機能スレッド管理部３は、変更受付部１からの入力データとして新機能データをコンパイル部４に渡す。
【００１９】
コンパイル部４は、入力データより、新機能データとなる新機能の関数名を取得してコンパイルを行い、コンパイル結果を表示装置５に出力する。また、コンパイル部４においてコンパイルが成功すると、コンパイル部４はコンパイル済みのオブジェクトファイルをオブジェクトファイル格納エリア６に保存する。
【００２０】
さらに、コンパイル部４はコンパイル処理が終了したことを新機能スレッド管理部３に通知する。新機能スレッド管理部３は、コンパイル部４からコンパイル処理の終了通知を受けると、現機能スレッド管理部２に対して、動作中の機能スレッドの中で、新機能の関数名と一致する関数名を持つ機能スレッドを、旧機能スレッドとして破棄することを要請する。
【００２１】
新機能スレッド管理部３から旧機能スレッドの破棄を要請された現機能スレッド管理部２は、遠方監視制御機能部８の中から新機能の関数名と一致する関数名を持つ機能スレッドを、検索する。検索の結果、新機能の関数名と一致する関数名を持つ機能スレッドが遠方監視制御機能部８の中から発見された場合、現機能スレッド管理部２は、当該機能スレッドを旧機能スレッドとして停止させ、これを破棄する。
【００２２】
続いて、現機能スレッド管理部２は旧機能スレッドの破棄が完了したことを新機能スレッド管理部３に通知する。この完了通知を受けた新機能スレッド管理部３は、機能スレッド生成部７に新機能の関数名を渡す。機能スレッド生成部７は、渡された新機能の関数名に基づいて、遠方監視制御機能用の機能スレッドを生成する。
【００２３】
機能スレッド生成部７により機能スレッドが生成されると、オブジェクトファイル格納部６にて新たなオブジェクトファイルから関数が動的にリンク、すなわちダイナミックリンク（以下、ＤＬと略す）される。このＤＬの処理の流れについて図２の例を用いて説明する。
【００２４】
図２の『Ａ』では、現機能スレッド管理部２は旧機能スレッド（ここでは上り計測処理）を停止させた後に破棄し、これにより旧機能の関数を遠方監視制御機能部８から解放する。図２の『Ｂ』では、機能スレッド生成部７が新しく機能スレッド（新上り計測処理）を生成する。
【００２５】
図２の『Ｃ』では、ブジェクトファイル格納部６において新しい機能スレッドは旧機能スレッドと同じ関数名であることが宣言され、これにより、新しいオブジェクトファイル（Up_TM Rev2）から関数がＤＬされる。以上のようなＤＬ処理によって、新たな関数の実行が可能となり、アプリソフトを変更することができる。
【００２６】
（効果）
以上の第１の実施形態によれば、遠方監視制御装置のアプリソフト変更作業において、遠方監視制御機能のオブジェクトファイルがＤＬされた機能スレッドを生成し、これを用いることによりスレッド単位でアプリソフトの変更作業を行うことができる。したがって、アプリソフトを停止させる必要がなく、アプリソフトの変更作業中、遠方監視制御装置による現場機器の遠方監視制御を継続することができる。その結果、現場機器の直接運転時間を短縮化することが可能となり、利便性が向上する。
【００２７】
また、プロセスを分割してアプリソフトを変更する場合と異なり、第１の実施形態では大容量のＲＡＭや高速で動作するＣＰＵあるいは複数のＣＰＵが不要である。そのため、本実施形態はリソースが少ない遠方監視制御装置に極めて好適である。さらに本実施形態においては大量のプロセス間通信を用いることがないので、オーバーヘッドは少なくて済み、リアルタイム性を損なう心配がない。
【００２８】
（２）第２の実施形態
（構成）
図３を用いて第２の実施形態を説明する。第２の実施形態は図１に示した第１の実施形態に対して、新機能スレッド管理部３にバージョンチェック部１０を接続した点に特徴がある。
【００２９】
バージョンチェック部１０は遠方監視制御機能部８のスレッドごとのバージョン情報を保存し、新機能スレッドのバージョンを確認する部分である。なお、下記の実施形態において、上記の第１の実施形態と同一の構成要素については同一符号を付して説明は割愛する。
【００３０】
（作用）
上記の構成を有する第２の実施形態において、新機能スレッド管理部３は、変更受付部１に入力されたデータを、バージョンチェック部１０に渡す。バージョンチェック部１０は、変更受付部１に入力されたデータの名称およびファイル名より、現在動作している同機能のスレッドのバージョンと入力データにおけるバージョンとを比較して、機能スレッドのバージョンが変更されているかどうかを判定する。
【００３１】
バージョンチェック部１０はバージョン変更有無の判定結果を、表示装置５へ出力すると共に、新機能スレッド管理部３に通知する。新機能スレッド管理部３は、バージョンチェック部１０から通知されたデータがバージョン変更有りの場合のみ、コンパイル部４に入力データを渡し、第１の実施形態のコンパイル部４からの手順に従って新機能スレッドの生成を行う。
【００３２】
（効果）
上記作用を有する第２の実施形態では、次のような独自の効果がある。すなわち、遠方監視制御機能部８の各機能スレッドのバージョンを、遠方監視制御装置内のバージョンチェック部１０で判定することができる。したがって、誤った入力データによる機能スレッドの生成を防ぐことが可能になり、アプリソフトの変更作業における信頼性が向上する。
【００３３】
（３）第３の実施形態
（構成）
図４を用いて第３の実施形態を説明する。第３の実施形態は図３に示した第２の実施形態に対して、機能スレッドのセルフ機能チェック部１１を追加した点が構成上の特徴である。セルフ機能チェック部１１は新機能スレッド管理部３に接続されている。また、第３の実施形態における現機能スレッド管理部２は、現在使用されているオブジェクトファイルを複製し、バックアップ用ファイルとして保存するようになっている。
【００３４】
（作用）
上記構成を有する第３の実施形態では、現機能スレッド管理部２は、旧機能スレッドを破棄する前に、使用中のオブジェクトファイルをバックアップファイルとして保存する。新機能スレッド管理部３は、機能スレッド生成部７から新たに機能スレッドを生成した通知を受けると、セルフ機能チェック部１１に対して新しい機能スレッドに関する機能チェックを行うように通知する。
【００３５】
新機能スレッド管理部３から通知を受けたセルフ機能チェック部１１は、機能チェック処理用の入力テストデータと、期待される出力データの待ち状態に入り、その旨を新機能スレッド管理部３に通知する。セルフ機能チェック部１１から通知を受けた新機能スレッド管理部３は、変更受付部１に対して、次に入力されるデータがセルフ機能チェック部１１用のテストデータであることを通知する。
【００３６】
以上の状態で、変更受付部１に対して人間系で入力されるテストデータと、期待される出力データの入力を行ったとき、変更受付部１は新機能スレッド管理部３にこれらのデータを渡す。さらに新機能スレッド管理部３はこれらのデータをセルフ機能チェック部１１に渡す。
【００３７】
セルフ機能チェック部１１は、入力テストデータを新たに生成した機能スレッドに渡して、この機能スレッドからの出力結果を取得する。セルフ機能チェック部１１は、この機能スレッドの出力結果と、期待される出力データとを比較し、結果に差異が有る場合は、新たに生成した機能スレッドの削除要請を、新機能スレッド管理部３へ通知し、さらに表示装置５へ出力する。
【００３８】
セルフ機能チェック部１１から削除要請を受けた新機能スレッド管理部３は、現機能スレッド管理部２に対して削除対象となる機能スレッドを通知する。現機能スレッド管理部２は通知された削除対象の機能スレッドを破棄した後、オブジェクトファイルをバックアップ用の旧機能スレッド削除前のファイルと入れ替える。
【００３９】
ファイル入れ替え後、現機能スレッド管理部２は、新機能スレッド管理部３に旧機能スレッド生成要請を通知する。通知を受けた新機能スレッド管理部３は機能スレッド生成部７に旧機能スレッドを生成する旨の通知を出し、機能スレッド生成部７は旧機能スレッドを生成する。
【００４０】
（効果）
上記作用により、第３の実施形態では、上記第２の実施形態が持つ効果に加えて、次のような独自の効果がある。すなわち、セルフ機能チェック部１１が新たに生成した機能スレッドの機能を確かめることができるので、新機能スレッド管理部３が実機で正常に動作することを確認することが可能となる。これにより、遠方監視制御装置の誤動作を防ぐことが可能となる。
【００４１】
（４）第４の実施形態
（構成）
図５を用いて第４の実施形態について説明する。第４の実施形態は図４に示した第３の実施形態に対して、さらにインタプリタ部１２を追加した点に特徴がある。インタプリタ部１２は、オブジェクトファイル格納部６および遠方監視制御機能部８に接続されている。インタプリタ部１２は、コンパイル部４によって生成されたオブジェクトファイルが中間言語である場合、機能スレッドを生成する際のＤＬ時に、オブジェクトファイルを逐次解析するようになっている。
【００４２】
（作用および効果）
第４の実施形態では、上記第３の実施形態が持つ効果に加えて、次のような独自の効果がある。すなわち、オブジェクトファイルが中間言語であっても、アプリソフトを全く停止させることなく、迅速且つスムーズにアプリソフト変更作業を行うことが可能になる。
【００４３】
（５）他の実施形態
なお、上記の実施形態は、本明細書において一例として提示したものであって、発明の範囲を限定することを意図するものではない。すなわち、その他の様々な形態で実施されることが可能であり、発明の範囲を逸脱しない範囲で、種々の省略や置き換え、変更を行うことが可能である。これらの実施形態やその変形例は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【００４４】
１…変更受付部
２…現機能スレッド管理部
３…新機能スレッド管理部
４…コンパイル部
５…表示装置
６…オブジェクトファイル格納部
７…機能スレッド生成部
８…遠方監視制御機能部
９…データベース
１０…バージョンチェック部
１１…セルフ機能チェック部
１２…インタプリタ部
【図１】
2015148929.tif 000003
【図２】
2015148929.tif 000004
【図３】
2015148929.tif 000005
【図４】
2015148929.tif 000006
【図５】
2015148929.tif 000007