JPH11327630A - 監視制御装置及び監視制御方法 - Google Patents

Abstract

(57)【要約】 【課題】 ＯＰＳ１とＰＬＣ２がデータ通信を実施する
場合には、ＣＯＭ／ＤＣＯＭという通信プロトコルを用
いて実施するが、ＣＯＭ／ＤＣＯＭはデータ通信のリア
ルタイム性を考慮していないため、ネットワーク３のト
ラフィックが混雑すると、データの転送周期が守られ
ず、データのリアルタイム性が重視されるシステムには
用いることができないという課題があった。 【解決手段】 ミドルウエア１７からネットワーク１３
に出力された転送要求を取得すると、デバイス１４から
取得したデータを周期的にネットワーク１３に出力す
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、例えば、プラン
トの運転状況を監視しながらプラントを制御する監視制
御装置及び監視制御方法に関するものである。

【０００２】

【従来の技術】図２９は従来の監視制御装置を示す構成
図であり、図において、１はプラントに関するデータを
提示するとともに、プラント機器の運転操作指令やデー
タの転送要求等を受け付けるオペレータ・ステーション
（以下、「ＯＰＳ」という）、２はプラントに設置され
ているセンサ等からプラントに関するデータを周期的に
入力して、そのデータをＯＰＳ１に転送するとともに、
ＯＰＳ１の要求に応じてプラント機器を制御するプログ
ラマブル・ロジカル・コントローラ（以下、「ＰＬＣ」
という）、３はＯＰＳ１とＰＬＣ２を接続するネットワ
ークである。

【０００３】図３０はＯＰＳやＰＬＣの内部構成を示す
構成図であり、図において、４はプラントに関するデー
タを提示するとともに、プラント機器の運転操作指令や
データの転送要求等を受け付けるＯＰＣクライアント、
５はデバイス７に対するＯＰＣクライアント４等の要求
を受け付けるサーバアプリケーション（以下、「ＯＰＣ
サーバ」という）、６はＰＬＣ２上のメモリ領域（以
下、「ＣＡＣＨＥ」という）、７はプラントに設置され
たセンサやアクチュエータ等のデバイス、８はデバイス
７上のメモリ領域（以下、「ＤＥＶＩＣＥ」という）で
ある。

【０００４】次に動作について説明するまず、監視制御
装置を構成するＰＬＣ２は、プラントの制御を行うコン
ポーネントであり、ＰＬＣ２はプラントに設置されてい
るデバイス７（例えば、センサやアクチュエータ）と接
続されている。ＰＬＣ２は、センサ等のデバイス７がプ
ラントに関するデータを取得すると、そのデータを読み
取ることにより、そのデータと予め設定された設定値か
ら制御値を計算する処理と、その制御値をアクチュエー
タ等のデバイス７に送信する処理を周期的に行うループ
制御を実行する（一つのＰＬＣ２が、複数のループ制御
を実行する場合もある）。

【０００５】また、ＰＬＣ２は、ネットワーク３に接続
されており、このネットワーク３を介してＯＰＳ１や他
のＰＬＣ２にデータを送信したり、ＯＰＳ１や他のＰＬ
Ｃ２からデータを受信したりすることもできる。一方、
ＯＰＳ１は、ＰＬＣ２からプラントに関するデータを受
信して、プラントの運転に携わるオペレータに対してデ
ータを提供したり、オペレータの運転操作指令を受け付
けて、その運転操作指令をＰＬＣ２に与えるコンポーネ
ントである。

【０００６】そして、ＯＰＣクライアント４とＯＰＣサ
ーバ５がデータの通信を実施する場合は、ＣＯＭ／ＤＣ
ＯＭという通信プロトコルを用いて実施する。なお、Ｃ
ＯＭ／ＤＣＯＭは、アプリケーションをオブジェクトと
してとらえ、そのオブジェクトの機能を利用するという
形でアプリケーション間の通信を実行するものである。

【０００７】そして、ＯＰＣクライアント４が、ＣＯＭ
／ＤＣＯＭに基づいて、デバイス７にアクセスする方法
として、ＯＰＣ仕様と称するものがある。ＯＰＣ仕様
は、従来、デバイス７に対するアクセスを提供するＯＰ
Ｃサーバ５と、デバイス７にアクセスするアプリケーシ
ョン間のインタフェースが統一されておらず、アクセス
するデバイス７ごとにアプリケーションを作成する必要
に鑑み、そのインタフェースを統一するために定められ
たものである。

【０００８】ＯＰＣを監視制御装置に導入する場合、図
３０に示すように、ＯＰＣサーバ５はＰＬＣ２上で動作
し、ＯＰＣサーバ５を利用するＯＰＣクライアント４は
ＯＰＳ１上で動作する。ＯＰＣサーバ５は、アクセスす
るデバイス７に特有のインタフェースを用いてデバイス
７をアクセスし、ＯＰＣサーバ５とＯＰＣクライアント
４間の通信プロトコルはＣＯＭ／ＤＣＯＭが用いられ
る。

【０００９】ＯＰＣではＯＰＣサーバ５ごとにＯＰＣサ
ーバオブジェクトが作られ、ＯＰＣサーバ全体の管理情
報を保持する。そのＯＰＣサーバオブジェクトの中にＯ
ＰＣグループオブジェクト（以下、「Ｇｒｏｕｐ」とい
う）が作られる。Ｇｒｏｕｐは、ＯＰＣアイテムオブジ
ェクト（以下「Ｉｔｅｍ」と呼ぶ）の集合を管理するた
めのオブジェクトであり、Ｉｔｅｍは実際のプラント値
を表わすオブジェクトである。ＧｒｏｕｐとＩｔｅｍは
アクティブ状態とインアクティブ状態があり、インアク
ティブ状態のＧｒｏｕｐに属するＩｔｅｍの値やインア
クティブ状態のＩｔｅｍの値を読むことはできない。

【００１０】ＯＰＣ仕様では、ＯＰＣサーバ５が、ＯＰ
Ｃクライアント４に対してデバイス７へのアクセス機能
を提供することを定めている。提供する機能としては、
同期書き込み、同期読み込み、非同期書き込み、非同期
読み込み、リフレッシュ、Ｓｕｂｓｃｒｉｐｔｉｏｎの
機能がある。

【００１１】・同期読み込み 同期読み込みは、指定されたＩｔｅｍに対応するプロセ
ス値を読み込むものであるが、読み込みが完了するまで
同期読み込みのＡＰＩは返されず、読み込み先として
は、デバイス７上のＤＥＶＩＣＥ８とＰＬＣ２上のＣＡ
ＣＨＥ６の２つがある。

【００１２】・同期書き込み 同期書き込みは、指定されたＩｔｅｍに対応するプロセ
ス値に値を書き込むものであるが、書き込みが完了する
まで同期書き込みのＡＰＩは返されず、書き込み先とし
ては、ＤＥＶＩＣＥ８のみである。

【００１３】・非同期読み込み 非同期読み込みは、指定されたＩｔｅｍに対応するプロ
セス値を読み込むものであるが、ＯＰＣクライアント４
が非同期読み込みのＡＰＩを呼ぶと、ＡＰＩが直ちに返
され、読み込み処理が完了すると、完了通知がＯＰＣク
ライアント４に送信される。読み込み先としては、ＤＥ
ＶＩＣＥ８とＣＡＣＨＥ６の２つがある。

【００１４】・非同期書き込み 非同期書き込みは、指定されたＩｔｅｍに対応するプロ
セス値に値を書き込むものであるが、ＯＰＣクライアン
ト４が非同期書き込みのＡＰＩを呼ぶと、ＡＰＩが直ち
に返され、書き込み処理が完了すると、完了通知がＯＰ
Ｃクライアント４に送信される。書き込み先はとして
は、ＤＥＶＩＣＥ８のみである。

【００１５】・リフレッシュ リフレッシュは、アクティブ状態のＣＡＣＨＥ６の値を
更新する機能であるが、ＯＰＣクライアント４がリフレ
ッシュのＡＰＩを呼ぶと、ＡＰＩが直ちに返され、リフ
レッシュ処理が完了すると、完了通知がＯＰＣクライア
ント４に送信される。

【００１６】・Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｓｕｂｓｃｒｉｐｔｉｏｎは、一定周期ごとにＤＥＶＩ
ＣＥ８の値チェックし、変更があった場合、ＯＰＣクラ
イアント４に通知するものである。

【００１７】なお、ＯＰＣサーバ５を用いる場合には、
パフォーマンス向上のため、デバイス７上のＤＥＶＩＣ
Ｅ８の値が反映されたメモリ領域としてＣＡＣＨＥ６を
設けることがあるが、ＯＰＣクライアント４がデバイス
７にアクセスするときは、ＤＥＶＩＣＥ８に直接アクセ
スするか、ＣＡＣＨＥ６にアクセスするかを選択する。

【００１８】

【発明が解決しようとする課題】従来の監視制御装置は
以上のように構成されているので、ＯＰＳ１とＰＬＣ２
がデータ通信を実施する場合には、ＣＯＭ／ＤＣＯＭと
いう通信プロトコルを用いて実施するが、ＣＯＭ／ＤＣ
ＯＭはデータ通信のリアルタイム性を考慮していないた
め、ネットワーク３のトラフィックが混雑すると、デー
タの転送周期が守られず、データのリアルタイム性が重
視されるシステムには用いることができないなどの課題
があった。

【００１９】この発明は上記のような課題を解決するた
めになされたもので、データをリアルタイムに転送する
ことができる監視制御装置及び監視制御方法を得ること
を目的とする。

【００２０】

【課題を解決するための手段】この発明に係る監視制御
装置は、第１のミドルウエアからネットワークに出力さ
れた転送要求を取得すると、デバイスから取得したデー
タを周期的にネットワークに出力するようにしたもので
ある。

【００２１】この発明に係る監視制御装置は、受付手段
がデータの送信要求を受け付けると、データを周期的に
ネットワークを介して第２のミドルウエアに送信するよ
うにしたものである。

【００２２】この発明に係る監視制御装置は、データを
ネットワークに出力する際、そのデータの情報量に見合
う通信帯域を確保するようにしたものである。

【００２３】この発明に係る監視制御装置は、データの
転送要求又は送信要求を受け付けると、タグビューをア
クセスするようにしたものである。

【００２４】この発明に係る監視制御装置は、タグビュ
ーとキャッシュを同一のメモリ領域に割り当てるように
したものである。

【００２５】この発明に係る監視制御装置は、デバイス
に対する第２のミドルウエアの要求を受け付ける受付手
段を設けたものである。

【００２６】この発明に係る監視制御方法は、他のミド
ルウエアがネットワークからデータの転送要求を取得す
ると、デバイスから取得したデータを周期的にネットワ
ークに出力するようにしたものである。

【００２７】この発明に係る監視制御方法は、サーバア
プリケーションがデータの送信要求を受け付けると、ミ
ドルウエアがデータを周期的にネットワークを介して他
のミドルウエアに送信するようにしたものである。

【００２８】この発明に係る監視制御方法は、ミドルウ
エアがデータをネットワークに出力する際、そのデータ
の情報量に見合う通信帯域を確保するようにしたもので
ある。

【００２９】この発明に係る監視制御方法は、サーバア
プリケーションがデータの転送要求又は送信要求を受け
付けると、タグビューをアクセスするようにしたもので
ある。

【００３０】この発明に係る監視制御方法は、タグビュ
ーとキャッシュを同一のメモリ領域に割り当てるように
したものである。

【００３１】この発明に係る監視制御方法は、デバイス
に対する他のミドルウエアの要求を受け付けるサーバア
プリケーションを設けたものである。

【００３２】

【発明の実施の形態】以下、この発明の実施の一形態を
説明する。 実施の形態１．図１はこの発明の実施の形態１による監
視制御装置を示す構成図であり、図において、１１はプ
ラントに関するデータを提示するとともに、プラント機
器の運転操作指令やデータの転送要求等を受け付けるオ
ペレータ・ステーション（以下、「ＯＰＳ」という）、
１２はプラントに設置されているセンサ等からプラント
に関するデータを周期的に入力して、そのデータをＯＰ
Ｓ１１に転送するとともに、ＯＰＳ１１の要求に応じて
プラント機器を制御するプログラマブル・ロジカル・コ
ントローラ（以下、「ＰＬＣ」という）、１３はＯＰＳ
１１とＰＬＣ１２を接続するネットワーク、１４はプラ
ントに設置されたセンサやアクチュエータ等のデバイス
である。

【００３３】また、１５はプラントに関するデータを提
示するとともに、デバイス１４に対するアクセス要求
（データの転送要求，データの送信要求等）を受け付け
るＯＰＣクライアント（受付手段）、１６はＯＰＣクラ
イアント１５により受け付けられたアクセス要求をミド
ルウエアに伝達するＯＰＣサーバ（受付手段）、１７は
ＯＰＣサーバ１６からデータの転送要求が伝達された場
合には、その転送要求をネットワーク１３を介してミド
ルウエア１８に送信するとともに、その転送要求に伴っ
て転送されたデータをネットワーク１３から取得し、Ｏ
ＰＣサーバ１６からデータの送信要求が伝達された場合
には、データを周期的にネットワーク１３を介してミド
ルウエア１８に送信するミドルウエア（第１のミドルウ
エア）である。

【００３４】また、１８はミドルウエア１７からネット
ワーク１３を介して転送要求を受信すると、デバイス１
４から取得したデータを周期的にネットワーク１３を介
してミドルウエア１７に送信する一方、ミドルウエア１
７がデータを周期的にネットワーク１３に出力する場合
には、そのネットワーク１３からデータを取得するミド
ルウエア（第２のミドルウエア）、１９はプラントに関
するデータを取得して、ＰＬＣ１２のＳｏｕｒｃｅ２２
（メモリ領域）に格納するとともに、プラント機器のル
ープ制御を実行するアプリケーション、２０はＯＰＳ１
１上のメモリ領域に割り当てられたキャッシュ（以下、
「ＣＡＣＨＥ」という）、２１はＯＰＣサーバ１６にプ
ロセス値を提供するタグビュー、２２はＰＬＣ１２上の
メモリ領域（以下、「Ｓｏｕｒｃｅ」という）である。

【００３５】次に動作について説明する。まず、この実
施の形態１では、ＯＰＣサーバ１６をＯＰＳ１１に設置
するとともに、ミドルウェア１７，１８をそれぞれＯＰ
Ｓ１１，ＰＬＣ１２に設置することにより、リアルタイ
ム性を保証するデータ通信を実現するものである。ここ
で、Ｓｏｕｒｃｅ２２は、プラントに関する情報（プロ
セス値）を格納するメモリ領域であり、プロセス値と対
応するメンバと、メンバの集合であるタグを用いて管理
している。

【００３６】タグビュー２１は、ＰＬＣ１２上のミドル
ウェア１８と、ＯＰＳ１１上のミドルウェア１７の働き
によってＳｏｕｒｃｅ２２から送られるプロセス値を格
納するメモリ領域である。なお、Ｓｏｕｒｃｅ２２から
タグビュー２１又はタグビュー２１からＳｏｕｒｃｅ２
２に対するプロセス値の転送周期や転送におけるデッド
ラインを要素とするＱ０Ｓクラスが、タグビュー２１の
各メンバに割り当てられている。

【００３７】また、タグビュー２１は、ＯＰＳ１１上の
メモリ領域に存在し、ＰＬＣ１２のＳｏｕｒｃｅ２２の
内容を反映するプロセス値の集合であり、ＯＰＣサーバ
１６にプロセス値を提供する役割がある。タグビュー２
１は、ＯＰＳ１１上に複数存在し、選択・非選択の２つ
の状態がある。選択・非選択の状態は、ＯＰＣサーバ１
６からの要求により変更される。

【００３８】タグビュー２１が選択状態になると、ＯＰ
Ｓ１１上のミドルウェア１７が、ＰＬＣ１２上のミドル
ウェア１８に対して、タグビュー２１のメンバであるプ
ロセス値の転送要求を伝達し、ＰＬＣ１２上のミドルウ
ェア１８は、その転送要求に応じてプロセス値を送信す
る。一方、非選択状態になると、転送の停止要求をＰＬ
Ｃ１２上のミドルウェア１８に伝達する。タグビュー２
１の各メンバは、Ｑ０Ｓクラスが割り当てられているの
で、そのＱ０Ｓクラスで指定された送信周期でＰＬＣ１
２からＯＰＳ１１への送信が行われる（ミドルウエア１
８は、プロセス値をネットワークに出力する際、そのプ
ロセス値の情報量に見合う通信帯域を確保して、Ｑ０Ｓ
クラスで指定された送信周期を保証している。なお、ミ
ドルウエア１７についても同様である。）。

【００３９】ＰＬＣ１２上のアプリケーション１９は、
プラント機器のループ制御を実行すると同時に、プラン
トに関するデータをＰＬＣ１２上のＳｏｕｒｃｅ２２に
書き込む処理を実行する。ＰＬＣ１２上のミドルウェア
１８は、ＯＰＳ１１上のミドルウェア１７からの要求に
応じて、Ｓｏｕｒｃｅ２２上のプロセス値をＯＰＳ１１
に送信したり、ＯＰＳ１１からのプロセス値の書き換え
や運転操作指令を受け付けて、Ｓｏｕｒｃｅ２２上の該
当するエリアに書き込む処理を実行する。

【００４０】一方、ＯＰＳ１１上のミドルウェア１７
は、ＯＰＣサーバ１６のプロセス値の要求をネットワー
ク１３を介してＰＬＣ１２上のミドルウェア１８に伝達
したり、その要求に伴って、ＰＬＣ１２上のミドルウェ
ア１８から送られてきたデータを受信し、ＯＰＳ１１上
のタグビュー２１に格納する処理を実行する。

【００４１】ＯＰＣサーバ１６は、ＯＰＣクライアント
１５がデバイス１４にアクセスするのためのインタフェ
ースを提供し、ＯＰＣクライアント１５からの要求をミ
ドルウェア１７に伝達する処理を実行する。ＯＰＣクラ
イアント１５は、オペレータにプラントに関するデータ
を提示したり、オペレータから与えられたプラント機器
の運転操作指令をＯＰＣサーバ１６に伝達する処理を実
行する。

【００４２】次に、図２はＯＰＳ１１上のＯＰＣサーバ
１６とミドルウェア１７、ＰＬＣ１２上のミドルウェア
１８の内部構成を示すものであり、以下、ＯＰＳ１１上
のミドルウェア１７とＰＬＣ１２上のミドルウェア１８
間で送受信されるメッセージについて説明する。

【００４３】まず、図３はタグメッセージのデータ構造
を示す構造図であるが、タグメッセージは、送信スレッ
ドから受信スレッドに送信されるメッセージであり、タ
グＩＤ、メンバＩＤ及びそのメンバの値が含まれてい
る。

【００４４】図４はタグ要求メッセージのデータ構造を
示す構造図であるが、タグ要求メッセージは、要求送信
スレッドから要求受信スレッドに送信されるメッセージ
であり、要求を送信するＯＰＳ１１のアドレスと、タグ
要求メッセージ受信後に一度だけ送信するメンバの要求
（初期化時送信要求）と、一定周期ごとに送信するメン
バの要求（定常時送信要求）とが含まれている。初期化
時送信要求には、送信するメンバ数とそれぞれのメンバ
のタグＩＤ、メンバＩＤ、Ｑ０Ｓクラスが含まれてい
る。定常時送信要求には、送信するメンバ数とそれぞれ
のメンバのタグＩＤ、メンバＩＤ、Ｑ０Ｓクラスが含ま
れている。

【００４５】図５は要求処理メッセージのデータ構造を
示す構造図であるが、要求処理メッセージは、ＯＰＳ１
１上の直接アクセススレッドからＰＬＣ１２上の直接ア
クセススレッドに送信されるＳｏｕｒｃｅ２２への書き
込み処理や読み込み処理を要求するためのメッセージで
ある。書き込み処理を行う場合には、書き込みフラグに
真を入れ、ＯＰＳアドレス、書き込み先のタグＩＤ、メ
ンバＩＤ及び書き込む値が含まれる。読み込み処理を行
う場合には、書き込みフラグに偽を入れ、読み込み元の
タグＩＤ、メンバＩＤが含まれる。

【００４６】図６は処理完了メッセージのデータ構造を
示す構造図であるが、処理完了メッセージは、ＰＬＣ１
２上の直接アクセススレッドからＯＰＳ１１上の直接ア
クセススレッドに送信されるＳｏｕｒｃｅ２２への書き
込み処理や読み込み処理の完了を通知するためのメッセ
ージである。書き込み処理を行った場合には、書き込み
フラグに真を入れ、処理結果（正常終了または処理失
敗）、書き込み先のタグＩＤ、メンバＩＤ及び書き込ん
だ値が含まれる。読み込み処理を行った場合には、書き
込みフラグに偽を入れ、処理結果（正常終了または処理
失敗）、読み込み元のタグＩＤ、メンバＩＤ及び読み込
んだ値が含まれる。

【００４７】次に、ＰＬＣ１２上のミドルウェア１８の
具体的構成を説明する。まず、図７はタグ定義ファイル
のデータ構造を示す構造図であるが、タグ定義ファイル
は、ＯＰＳ１１とＰＬＣ１２の両方に存在し、システム
内のタグの数、各タグのＩＤ、そのタグを保持している
ＰＬＣの名前、各タグのメンバの数、各メンバのＩＤ、
メンバのデータタイプ、メンバの転送方向（ＯＰＳから
ＰＬＣへまたはＰＬＣからＯＰＳへ）などの情報が収め
られている。

【００４８】図８はＰＬＣ１２上の送信テーブルのデー
タ構造を示す構造図であるが、送信テーブルは、Ｑ０Ｓ
クラスの数だけ存在し、タグ要求メッセージを受信する
要求受信スレッドによって書き換えられ、同じＱ０Ｓク
ラスを担当している送信スレッドによって参照される。
そして、送信テーブルに登録されているメンバがＳｏｕ
ｒｃｅ２２から読み込まれてＯＰＳ１１に送信される。
送信テーブルにはＱ０Ｓクラスと、初期化時送信のメン
バ数と、それぞれのメンバのタグＩＤ、メンバＩＤ、送
信先のＯＰＳアドレスとが含まれ、また、定常時送信の
メンバ数と、それぞれのメンバのタグＩＤ、メンバＩ
Ｄ、送信先のＯＰＳアドレスとが含まれている。

【００４９】図９はＰＬＣ１２の受信スレッドのフロー
チャートであるが、ＰＬＣ１２の受信スレッドは、Ｑ０
Ｓクラスの数だけ存在し、それぞれのＱ０Ｓクラスを担
当する。受信スレッドは、ＯＰＳ１１の送信スレッドか
らタグメッセージが送信されるまで待機し、タグメッセ
ージが送信されると起動される（ステップＳＴ１）。

【００５０】そして、受信スレッドは起動されると、タ
グメッセージからタグＩＤ、メンバＩＤ、書き込む値を
読み取り（ステップＳＴ２）、タグ定義ファイルを用い
て該当するメンバがあるか否かを判定するとともに（ス
テップＳＴ３）、ＯＰＳ１１から書き込みが可能である
か否かを判定する（ステップＳＴ４）。そして、該当す
るメンバがあり、かつ、書き込み可能であれば、タグメ
ッセージをＳｏｕｒｃｅ２２に書き込み（ステップＳＴ
５）、再びタグメッセージの受信待ちを実施する。該当
するメンバがない場合又は書き込み不可の場合には、タ
グメッセージの書き込み処理を実施せず、次のタグメッ
セージの受信待ちを実施する。

【００５１】図１０はＰＬＣ１２の送信スレッドのフロ
ーチャートであるが、送信スレッドは、Ｑ０Ｓクラスの
数だけ用意されており、該当するＱ０Ｓクラスが要求し
ている送信周期ごとに起動される（ステップＳＴ１
１）。送信スレッドは起動されると、ＰＬＣ１２内にあ
る初期化送信を行ったかどうかを示す初期化フラグをチ
ェックする（ステップＳＴ１２）。初期化フラグが真で
あれば、初期化時送信と定常時送信を実施し、初期化フ
ラグが偽であれば定常時送信のみ実施する。

【００５２】初期化時送信は、送信テーブルより初期化
時送信メンバを読み込むことにより、Ｓｏｕｒｃｅ２２
から該当するメンバを読み込んでＯＰＳ１１に送信し、
初期化フラグを偽にする（ステップＳＴ１３〜ＳＴ１
７）。定常時送信は送信テーブルより定常時送信メンバ
を読み込むことにより、Ｓｏｕｒｃｅ２２から該当する
メンバを読み込んでＯＰＳ１１に送信し、再び起動時刻
まで待機する（ステップＳＴ１８〜ＳＴ２２）。

【００５３】図１１はＰＬＣ１２の要求受信スレッドの
フローチャートであるが、要求受信スレッドは、ＯＰＳ
１１の要求送信スレッドから要求メッセージが送信され
るまで待機し、要求メッセージを受信すると起動される
（ステップＳＴ３１）。そして、要求受信スレッドは起
動されると、タグ要求メッセージからＯＰＳ１１のアド
レスと初期化時送信要求の部分を読み取り（ステップＳ
Ｔ３２，ＳＴ３３）、送信テーブルの初期化時送信部分
を書き換える（ステップＳＴ３４，ＳＴ３５）。次に定
常時送信要求部分を読み取り（ステップＳＴ３６）、送
信テーブルの定常時送信部分を書き換える（ステップＳ
Ｔ３７）。

【００５４】図１２はＰＬＣ１２の直接アクセススレッ
ドのフローチャートであるが、直接アクセススレッド
は、タグビュー２１を介さず、Ｓｏｕｒｃｅ２２のデー
タにアクセスする場合に使用されるスレッドであり、Ｏ
ＰＳ１１側の直接アクセススレッドから処理要求メッセ
ージが、このスレッドに送られてくる。直接アクセスス
レッドは、処理要求メッセージを受け取ると起動される
（ステップＳＴ４１）。直接アクセススレッドは起動さ
れると、処理要求メッセージから書き込みフラグ、タグ
ＩＤ、メンバＩＤを読み取り（ステップＳＴ４２）、該
当するメンバが存在するか否かを判定する（ステップＳ
Ｔ４３）。

【００５５】該当するメンバが存在すれば、書き込みフ
ラグから書き込み処理要求であるか、読み込み処理要求
であるかを判定し（ステップＳＴ４４）、その判定結果
に応じて、書き込み処理又は読み込み処理を実施する
（ステップＳＴ４５〜ＳＴ４８）。直接アクセススレッ
ドは、処理が完了すると、処理完了メッセージに書き込
みフラグ、結果（正常終了か処理の失敗）、タグＩＤ、
メンバＩＤ及び読み込み処理であれば読み込んだ値を代
入し、処理を要求してきたＯＰＳ１１の直接アクセスス
レッドに送信する（ステップＳＴ４９，ＳＴ５０）。

【００５６】次に、ＯＰＳ１１上のミドルウェア１７の
具体的構成を説明する。まず、図１３はタグビュー定義
ファイルのデータ構造を示す構造図であるが、タグビュ
ー定義ファイルは、ＯＰＳ１１内のタグビューの数、各
タグビューのＩＤ、タグビューに含まれるメンバの数、
タグビューに含まれるメンバのタグ定義ファイル（タグ
定義ファイルは、ＰＬＣ１２のタグ定義ファイルと同
一）で定義されているタグＩＤ、メンバＩＤ及び各メン
バのＱ０Ｓクラスなどの情報が含まれる。

【００５７】図１４はＯＰＳ１１上の送信テーブルのデ
ータ構造を示す構造図であるが、送信テーブルは、Ｑ０
Ｓクラスの数だけ存在し、タグ要求送信スレッドによっ
て書き換えられ、同じＱ０Ｓクラスを担当している送信
スレッドによって参照される。送信テーブルに登録され
ているメンバがタグビュー２１から読み込まれてＰＬＣ
１２に送信される。送信テーブルには、担当するＱ０Ｓ
クラス、メンバ数、各メンバのタグビューＩＤ、タグＩ
Ｄ、メンバＩＤ、送信先のＰＬＣアドレスが含まれてい
る。

【００５８】図１５はＯＰＳ１１の受信スレッドのフロ
ーチャートであるが、受信スレッドは、Ｑ０Ｓクラスの
数だけ存在し、ＰＬＣ１２の送信スレッドから送られて
くるタグメッセージを受け取ると起動される（ステップ
ＳＴ６１）。そして、受信スレッドは起動されると、タ
グメッセージからタグＩＤ、メンバＩＤ及びメンバ値を
読み取り（ステップＳＴ６２）、タグビュー定義ファイ
ルを参照して、該当するメンバがタグビューにあるか否
かを判定するとともに（ステップＳＴ６３）、ＰＬＣ１
２から書き込み可能であるか否かを判定し（ステップＳ
Ｔ６４）、該当するタグビュー２１の領域に値を書き込
む処理を実施する（ステップＳＴ６５）。

【００５９】図１６はＯＰＳ１１の送信スレッドのフロ
ーチャートであるが、送信スレッドは、Ｑ０Ｓクラスの
数だけ存在し、該当するＱ０Ｓクラスで要求される送信
周期ごとに起動される（ステップＳＴ７１）。送信スレ
ッドは起動されると、送信テーブルに登録されているデ
ータをタグビュー２１から読み込み（ステップＳＴ７
２）、ＰＬＣ１２の受信スレッドにタグメッセージとし
て送信する（ステップＳＴ７３〜ＳＴ７６）。

【００６０】図１７はＯＰＳ１１の要求送信スレッドの
フローチャートであるが、要求送信スレッドは、ＯＰＣ
サーバ１６から、新たなタグビュー２１を選択する要求
や選択されているタグビュー２１を非選択にする要求が
あると起動される（ステップＳＴ８１）。

【００６１】そして、要求送信スレッドは起動される
と、選択状態のタグビュー２１を読み取り（ステップＳ
Ｔ８２）、そのタグビュー２１のメンバに基づいて送信
テーブルを書き換える（ステップＳＴ８３）。そして、
要求送信スレッドは、タグ要求メッセージを作成して
（ステップＳＴ８４）、関連のあるＰＬＣ１２のアドレ
スを読み取り（ステップＳＴ８５）、ＰＬＣ１２の要求
受信スレッドに送信する（ステップＳＴ８６）。

【００６２】図１８はＯＰＳ１１の直接アクセススレッ
ドのフローチャートであるが、直接アクセススレッド
は、ＯＰＣサーバ１６から直接Ｓｏｕｒｃｅ２２にアク
セスする要求がある場合に起動される（ステップＳＴ９
１）。そして、直接アクセススレッドは起動されると、
書き込み要求の場合には、タグ要求メッセージの書き込
みフラグに真を代入し、タグＩＤ、メンバＩＤと書き込
む値を代入しＰＬＣ１２に送信する（ステップＳＴ９２
〜ＳＴ９５，ＳＴ９９，ＳＴ１００）。

【００６３】読み込み要求の場合には、書き込みフラグ
に偽を代入しタグ要求メッセージにタグＩＤ、メンバＩ
Ｄを代入して送信する（ステップＳＴ９６〜ＳＴ１０
０）。そして、直接アクセススレッドは、送信が完了す
ると、処理完了メッセージの受信待ちを実施し（ステッ
プＳＴ１０１）、受信されると処理の要求元に完了通知
を行う（ステップＳＴ１０２）。

【００６４】次に、ＯＰＣサーバ１６の具体的構成を説
明する。ＯＰＣサーバ１６では、ＯＰＣクライアント１
５からの要求にしたがってＳｅｒｖｅｒオブジェクト、
Ｇｒｏｕｐオブジェクト、Ｉｔｅｍオブジェクトが作ら
れ、Ｉｔｅｍとタグビュー２１のメンバとが対応する。
Ｇｒｏｕｐオブジェクトごとに非同期スレッドと通知ス
レッドが作られる。

【００６５】図１９はＩｔｅｍタグビュー対応テーブル
のデータ構造を示す構造図であるが、Ｉｔｅｍタグビュ
ー対応テーブルは、ＯＰＣクライアント１５からＯＰＣ
サーバ１６にアイテム名でプロセス値へのアクセスが指
定されたときにアイテム名に対応するタグＩＤ、メンバ
ＩＤの情報を得るために用いられ、アイテム名とそれに
対応するタグＩＤ、メンバＩＤからなる。

【００６６】図２０は非同期スレッドのフローチャート
であるが、非同期スレッドは、ＯＰＣクライアント１５
からの非同期読み込み、非同期書き込み、リフレッシュ
の要求に対して動作する（ステップＳＴ１１１〜ＳＴ１
２０）。

【００６７】図２１は通知スレッドのフローチャートで
あるが、通知スレッドは、Ｇｒｏｕｐに要求される送信
周期で起動され（ステップＳＴ１２１）、そのＧｒｏｕ
ｐに属するＩｔｅｍに対応するタグビュー２１のメンバ
を読み込み（ステップＳＴ１２２，ＳＴ１２３）、その
メンバの値が変化していれば（ステップＳＴ１２４）、
Ｉｔｅｍの値を書き換えて（ステップＳＴ１２５）、Ｏ
ＰＣクライアント１５に通知する（ステップＳＴ１２６
〜ＳＴ１２８）。

【００６８】次に、ＯＰＣサーバ１６がＯＰＳ１１内の
アプリケーションに同期読み込み、同期書き込み、非同
期読み込み、非同期書き込み、リフレッシュ、Ｓｕｂｓ
ｃｒｉｐｔｉｏｎの機能を提供するときの動作、ＯＰＳ
１１内のミドルウェア１７、ＰＬＣ１２内のミドルウェ
ア１８の動作について述べる。

【００６９】・同期読み込み ＯＰＣクライアント１５が同期読み込みのＡＰＩを呼ぶ
と、ＣＡＣＨＥ指定の場合は、ＯＰＣサーバ１６のＩｔ
ｅｍの値を返し、ＤＥＶＩＣＥ指定の場合は、ＯＰＳ１
１上のミドルウェア１７の直接アクセススレッドに対し
て、Ｓｏｕｒｃｅ２２からの直接読み込みを要求し、直
接アクセススレッドから要求した値が返ってくるとＯＰ
Ｃクライアント１５に値を返す。

【００７０】・同期書き込み 同期書き込みは、常にＤＥＶＩＣＥ指定で行われ、ＯＰ
Ｃクライアント１５が同期書き込みのＡＰＩと呼ぶと、
ＯＰＳ１１上のミドルウェア１７の直接アクセススレッ
ドにＳｏｕｒｃｅ２２への書き込みを要求し、直接アク
セススレッドからの完了通知があると、ＡＰＩがＯＰＣ
クライアント１５に返される。

【００７１】・非同期読み込み 非同期読み込みは、ＯＰＣクライアント１５が非同期読
み込みのＡＰＩを呼ぶと、ＡＰＩが直ちに返され、残り
の処理をＯＰＣサーバ１６の非同期スレッドが実行す
る。

【００７２】非同期スレッドは、読み込みがＣＡＣＨＥ
指定の場合は、ＯＰＣサーバ１６のＩｔｅｍの値を処理
の完了通知と共にＯＰＣクライアント１５に返送し、Ｄ
ＥＶＩＣＥ指定の場合は、ＯＰＳ１１上のミドルウェア
１７の直接アクセススレッドに対して、Ｓｏｕｒｃｅ２
２からの直接読み込みを要求し、直接アクセススレッド
から要求した値が返ってくると、その値を通知と共にＯ
ＰＣクライアント１５に返送する。

【００７３】・非同期書き込み 非同期書き込みは、常にＤＥＶＩＣＥ指定で行われ、Ｏ
ＰＣクライアント１５が非同期書き込みのＡＰＩと呼ぶ
と、ＡＰＩが直ちに返され、残りの処理をＯＰＣサーバ
１６の非同期スレッドが実行する。非同期スレッドは、
ＯＰＳ１１上のミドルウェア１７の直接アクセススレッ
ドに対し、Ｓｏｕｒｃｅ２２への書き込みを要求し、直
接アクセススレッドから完了通知があると、ＯＰＣクラ
イアント１５にも完了通知を送信する。

【００７４】・リフレッシュ リフレッシュは、ＤＥＶＩＣＥの値をＣＡＣＨＥ２０に
反映させるための機能であり、ＯＰＣクライアント１５
がリフレッシュのＡＰＩを呼ぶとＡＰＩは直ちに返さ
れ、後の処理をＯＰＣサーバ１６の非同期スレッドが実
行する。非同期スレッドは、ＣＡＣＨＥ２０に反映すべ
きプロセス値の読み込みをＯＰＳ１１のミドルウェア１
７の直接アクセススレッドに要求し、その直接アクセス
スレッドに値が返ってくると、その値をＣＡＣＨＥ２０
に書き込むとともに、その値と完了通知をＯＰＣクライ
アント１５に送信する。

【００７５】・Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｓｕｂｓｃｒｉｐｔｉｏｎ機能は、変更されたＤＥＶＩ
ＣＥの値を周期的にＣＡＣＨＥ２０に反映させ、反映さ
れたプロセス値を、ＯＰＣクライアント１５に通知する
機能である。ＯＰＣクライアント１５は、Ｓｕｂｓｃｒ
ｉｐｔｉｏｎ機能を使うＧｒｏｕｐをアクティブにし、
ＯＰＣサーバ１６は、そのＧｒｏｕｐに属するＩｔｅｍ
に対応するメンバの存在するタグビュー２１を選択状態
にする。

【００７６】選択状態のタグビュー２１の値は、ＰＬＣ
１２からの送信によって変更される。ＯＰＣサーバ１６
の通知スレッドは、そのＧｒｏｕｐが要求されている周
期で起動し、タグビュー２１からそのＧｒｏｕｐに該当
する値を読み、その値が変更されていれば、その値をＩ
ｔｅｍにコピーし、その値の変更をＯＰＣクライアント
１５に通知する。

【００７７】・実行優先度 各々のスレッドに対して優先度を指定できるオペレーテ
ィングシステム上でミドルウェアを動作させる場合に
は、デットラインが短いＱ０Ｓクラスを担当している送
信スレッドには、より高い優先度を持たせて動作させ
る。

【００７８】以上で明らかなように、この実施の形態１
によれば、ミドルウエア１７からネットワーク１３に出
力された転送要求を取得すると、デバイス１４から取得
したデータを周期的にネットワーク１３に出力するよう
に構成したので、デバイス１４から取得したデータをＯ
ＰＳ１１に対して、リアルタイムに転送することができ
る効果を奏する。また、ＯＰＣサーバ１６がデータの送
信要求を受け付けると、ミドルウエア１７がデータを周
期的にネットワーク１３を介してミドルウエア１８に送
信するように構成したので、ＯＰＳ１１内のデータをＰ
ＬＣ１２に対して、リアルタイムに転送することができ
る効果を奏する。

【００７９】実施の形態２．上記実施の形態１では、Ｏ
ＰＣサーバ１６がＳｏｕｒｃｅ２２にアクセスする場合
（ＤＥＶＩＣＥ指定の場合）には、タグビュー２１の機
能を使わず、直接アクセススレッドを用いるものについ
て示したが、その場合、処理速度が遅くなるデメリット
がある。そこで、この実施の形態２では、ＤＥＶＩＣＥ
指定の場合でも、高速なデータ処理を可能にするため、
ＯＰＣサーバ１６におけるＤＥＶＩＣＥ指定時のアクセ
ス先をタグビュー２１とすることにより、ＯＰＣサーバ
１６は、常に、ＯＰＳ１１内のデータ（Ｉｔｅｍの値又
はタグビューの値）をアクセスするようにしている。

【００８０】具体的には、実施の形態１では、ＤＥＶＩ
ＣＥ指定の領域がＳｏｕｒｃｅ２２であるのに対し（図
１を参照）、この実施の形態２では、ＤＥＶＩＣＥ指定
の領域がタグビュー２１である点で相違している（図２
２を参照）。また、この実施の形態２では、図２３に示
すように、ＯＰＳ１１とＰＬＣ１２の直接アクセススレ
ッドがなくなっている点で、上記実施の形態１の場合と
相違している。ただし、各スレッドの動作は上記実施の
形態１の場合と同一である。

【００８１】次に、ＯＰＣサーバ１６がＯＰＳ１１内の
アプリケーションに同期読み込み、同期書き込み、非同
期読み込み、非同期書き込み、リフレッシュ、Ｓｕｂｓ
ｃｒｉｐｔｉｏｎの機能を提供するときの動作、ＯＰＳ
１１内のミドルウェア１７、ＰＬＣ１２内のミドルウェ
ア１８の動作について述べる。

【００８２】・同期読み込み 同期読み込みは、ＯＰＣクライアント１５が同期読み込
みのＡＰＩを呼ぶと、ＣＡＣＨＥ指定の場合は、ＯＰＣ
サーバ１６のＩｔｅｍの値が返され、ＤＥＶＩＣＥ指定
の場合は、タグビューの値が返される。

【００８３】・同期書き込み 同期書き込みは、常にＤＥＶＩＣＥ指定で行われ、ＯＰ
Ｃクライアント１５が同期書き込みのＡＰＩを呼ぶと、
タグビュー２１に書き込み可能なメンバであれば、タグ
ビュー２１に書き込まれ、ＯＰＳ１１の送信スレッドに
よってＰＬＣ１２のＳｏｕｒｃｅ２２に送られる。

【００８４】・非同期読み込み 非同期読み込みは、ＯＰＣクライアント１５が非同期読
み込みのＡＰＩを呼ぶと、ＡＰＩは直ちに返され、残り
の処理をＯＰＣサーバ１６の非同期スレッドが実行す
る。非同期スレッドは、読み込みがＣＡＣＨＥ指定の場
合は、ＯＰＣサーバ１６のＩｔｅｍの値を処理の完了通
知と共にＯＰＣクライアント１５に返送し、ＤＥＶＩＣ
Ｅ指定の場合は、タグビュー２１の値を完了通知と共に
ＯＰＣクライアント１５に返送する。

【００８５】・非同期書き込み 非同期書き込みは、常にＤＥＶＩＣＥ指定で行われ、Ｏ
ＰＣクライアント１５が非同期書き込みのＡＰＩを呼ぶ
と、ＡＰＩは直ちに返され、残りの処理をＯＰＣサーバ
１６の非同期スレッドが実行する。非同期スレッドは、
タグビュー２１に書き込み可能なメンバであれば、タグ
ビュー２１に書き込まれ、ＯＰＣクライアント１５に完
了通知を送信する。タグビュー２１に書き込まれた値
は、ＯＰＳ１１上の送信スレッドによってＰＬＣ１２に
送信される。

【００８６】・リフレッシュ リフレッシュは、ＤＥＶＩＣＥの値をＣＡＣＨＥ２０に
反映させるための機能であり、ＯＰＣクライアント１５
がリフレッシュのＡＰＩを呼ぶと、ＡＰＩは直ちに返さ
れ、後の処理をＯＰＣサーバ１６の非同期スレッドが実
行する。非同期スレッドは、ＣＡＣＨＥ２０に反映すべ
きプロセス値をタグビュー２１から読み込むことによ
り、その値をＣＡＣＨＥ２０に書き込んで、その値と完
了通知をＯＰＣクライアント１５に送信する。

【００８７】・Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｓｕｂｓｃｒｉｐｔｉｏｎ機能は、一定周期で、変更の
あったＤＥＶＩＣＥの値をＣＡＣＨＥ２０に反映させ、
反映のあったプロセス値をＯＰＣクライアント１５に通
知する機能である。ＯＰＣクライアント１５は、Ｓｕｂ
ｓｃｒｉｐｔｉｏｎ機能を使うＧｒｏｕｐをアクティブ
にし、ＯＰＣサーバ１６は、そのＧｒｏｕｐに属するＩ
ｔｅｍに対応するメンバの存在するタグビュー２１を選
択状態にする。

【００８８】選択状態のタグビュー２１の値はＰＬＣ１
２からの送信によって変更される。ＯＰＣサーバ１６の
通知スレッドは、そのＧｒｏｕｐが要求されている周期
で起動し、タグビュー２１からそのＧｒｏｕｐに該当す
る値を読み込み、その値が変更されていれば、その値を
Ｉｔｅｍにコピーし、その値の変更をＯＰＣクライアン
ト１５に通知する。

【００８９】以上で明らかなように、この実施の形態２
によれば、データの転送要求又は送信要求を受け付ける
と、タグビュー２１をアクセスするように構成したの
で、ＤＥＶＩＣＥ指定の場合でも、高速なデータ処理を
実現できる効果を奏する。

【００９０】実施の形態３．上記実施の形態２では、タ
グビュー２１のメンバの値が変更されると、そのメンバ
の値を対応するＩｔｅｍの値にもコピーする必要があ
る。そこで、この実施の形態３では、図２４に示すよう
に、タグビュー２１とキャッシュを同一のメモリ領域に
割り当てるようにする（Ｉｔｅｍの値をポインタで対応
するタグビュー２１のメンバのメモリ領域を指す）。

【００９１】これにより、タグビュー２１の値が変更さ
れると、コピーを行わなくてもＩｔｅｍの値が変更され
ることになる。また、ＤＥＶＩＣＥとＣＡＣＨＥの指定
先が同一の領域となるため、ＤＥＶＩＣＥ指定を実行す
る処理とＣＡＣＨＥ指定を実行する処理が同じになり、
同一コードの使用が可能になる。

【００９２】図２５はＯＰＳ１１上のＯＰＣサーバ１６
とミドルウェア１７、ＰＬＣ１２上のミドルウェア１８
の内部構成を示し、図２６はＯＰＳ１１上の通知スレッ
ドのフローチャートであるが、通知スレッドは、Ｇｒｏ
ｕｐに要求される送信周期で起動され（ステップＳＴ１
３１）、このＧｒｏｕｐに属するＩｔｅｍの値を読み込
み、その値が変化していれば、ＯＰＣクライアント１５
に通知する（ステップＳＴ１３２〜ＳＴ１３７）。

【００９３】・受信スレッド 受信スレッドは、Ｑ０Ｓクラスの数だけ存在し、通知ス
レッドが存在する場合には、上記実施の形態１の受信ス
レッドと同様の動作をする（図１５を参照）。即ち、受
信スレッドは、ＰＬＣ１２の送信スレッドから送られて
くるタグメッセージを受け取ると起動される（ステップ
ＳＴ６１）。

【００９４】受信スレッドは起動されると、タグメッセ
ージからタグＩＤ、メンバＩＤ及びメンバ値を読み取る
（ステップＳＴ６２）。そして、タグビュー定義ファイ
ルを参照して、該当するメンバがタグビュー２１にある
か否かを判定するとともに（ステップＳＴ６３）、ＰＬ
Ｃ１２から書き込み可能である否かを判定し（ステップ
ＳＴ６４）、該当するタグビュー２１の領域に値を書き
込む処理を実行する（ステップＳＴ６５）。

【００９５】通知スレッドがない場合には、図２７に示
すように、タグビュー２１に値を書き込んだ後、ＯＰＣ
クライアント１５への通知を実施する（ステップＳＴ１
４１）。

【００９６】次に、ＯＰＣサーバ１６がＯＰＳ１１内の
アプリケーションに同期読み込み、同期書き込み、非同
期読み込み、非同期書き込み、リフレッシュ、Ｓｕｂｓ
ｃｒｉｐｔｉｏｎの機能を提供するときの動作、ＯＰＳ
１１内のミドルウェア１７、ＰＬＣ１２内のミドルウェ
ア１８の動作について述べる。

【００９７】・同期読み込み 同期読み込みは、ＯＰＣクライアント１５が同期読み込
みのＡＰＩを呼ぶと、ＣＡＣＨＥ指定の場合もＤＥＶＩ
ＣＥ指定の場合も、ＯＰＣサーバ１６のＩｔｅｍの値が
返される。

【００９８】・同期書き込み 同期書き込みは、常にＤＥＶＩＣＥ指定で行われ、ＯＰ
Ｃクライアント１５が同期書き込みのＡＰＩを呼ぶと、
タグビュー２１の書き込み可能なメンバであれば、タグ
ビュー２１に書き込まれ、ＯＰＳ１１の送信スレッドに
よってＰＬＣ１２のＳｏｕｒｃｅ２２に送信される。

【００９９】・非同期読み込み 非同期読み込みは、ＯＰＣクライアント１５が非同期読
み込みのＡＰＩを呼ぶと、ＡＰＩは直ちに返され、残り
の処理をＯＰＣサーバ１６の非同期スレッドが実行す
る。非同期スレッドは、読み込みがＣＡＣＨＥ指定の場
合もＤＥＶＩＣＥ指定の場合も、ＯＰＣサーバ１６のＩ
ｔｅｍの値を処理の完了通知と共にＯＰＣクライアント
１５に返送する。

【０１００】・非同期書き込み 非同期書き込みは、常にＤＥＶＩＣＥ指定で行われ、Ｏ
ＰＣクライアント１５が非同期書き込みのＡＰＩを呼ぶ
と、ＡＰＩは直ちに返され、残りの処理をＯＰＣサーバ
１６の非同期スレッドが実行する。非同期スレッドは、
タグビュー２１の書き込み可能なメンバであれば、タグ
ビュー２１に書き込まれ、ＯＰＣクライアント１５に完
了通知を送信する。タグビュー２１に書き込まれた値
は、ＯＰＳ１１上の送信スレッドによってＰＬＣ１２に
送信される。

【０１０１】・リフレッシュ リフレッシュは、ＤＥＶＩＣＥの値をＣＡＣＨＥ２０に
反映させるための機能であるが、ＤＥＶＩＣＥとＣＡＣ
ＨＥ２０が同一であるため、反映の処理は行わなくてよ
い。ＯＰＣクライアント１５がリフレッシュのＡＰＩを
呼ぶと、ＡＰＩは直ちに返され、後の処理をＯＰＣサー
バ１６の非同期スレッドが実行する。非同期スレッドは
変化のあったＩｔｅｍの値を完了通知と共にＯＰＣクラ
イアント１５に送信する。

【０１０２】・Ｓｕｂｓｃｒｉｐｔｉｏｎ Ｓｕｂｓｃｒｉｐｔｉｏｎ機能は一定周期で、変更のあ
ったＤＥＶＩＣＥの値をＣＡＣＨＥ２０に反映させ、反
映のあったプロセス値をＯＰＣクライアント１５に通知
する機能である。ＯＰＣクライアント１５は、Ｓｕｂｓ
ｃｒｉｐｔｉｏｎ機能を使うＧｒｏｕｐをアクティブに
し、ＯＰＣサーバ１６はそのＧｒｏｕｐに属するＩｔｅ
ｍに対応するメンバの存在するタグビュー２１を選択状
態にする。選択状態のタグビュー２１の値はＰＬＣ１２
からの送信によって変更される。

【０１０３】ＯＰＣサーバ１６の通知スレッドは、その
Ｇｒｏｕｐが要求されている周期で起動し、タグビュー
２１からそのＧｒｏｕｐに該当する値を読み込み、その
値が変更されていれば、その値の変更をＯＰＣクライア
ント１５に通知する。通知スレッドがない場合には、Ｏ
ＰＳ１１上の受信スレッドがＰＬＣ１２からのプロセス
値を受信すると、ＯＰＣクライアント１５に変更された
値を通知する。

【０１０４】以上で明らかなように、この実施の形態３
によれば、タグビュー２１とＣＡＣＨＥ２０を同一のメ
モリ領域に割り当てるように構成したので、タグビュー
２１の値を変更すると、自動的にＩｔｅｍの値が変更さ
れる効果を奏する。また、ＤＥＶＩＣＥとＣＡＣＨＥの
指定先が同一の領域となるため、ＤＥＶＩＣＥ指定を実
行する処理とＣＡＣＨＥ指定を実行する処理が同じにな
り、同一コードの使用が可能になる効果を奏する。

【０１０５】実施の形態４．上記実施の形態１から実施
の形態３では、ＯＰＣサーバ１６をＯＰＳ１１に搭載す
るものについて示したが、この場合、ＯＰＣサーバ１６
は、ＰＬＣ１２上のミドルウエア１８やアプリケーショ
ン１９に対して、デバイス１４をアクセスする際の共通
のインタフェースを提供することができないデメリット
がある。そこで、この実施の形態４では、図２８に示す
ように、ＰＬＣ１２上に別のＯＰＣサーバ２３（受付手
段）を搭載することにより、ＰＬＣ１２上のミドルウェ
ア１８やアプリケーション１９に対して、デバイス１４
をアクセスする際の共通のインタフェースを提供するこ
とができる効果を奏する。

【０１０６】

【発明の効果】以上のように、この発明によれば、第１
のミドルウエアからネットワークに出力された転送要求
を取得すると、デバイスから取得したデータを周期的に
ネットワークに出力するように構成したので、デバイス
から取得したデータをＯＰＳに対して、リアルタイムに
転送することができる効果がある。

【０１０７】この発明によれば、受付手段がデータの送
信要求を受け付けると、データを周期的にネットワーク
を介して第２のミドルウエアに送信するように構成した
ので、ＯＰＳ内のデータをＰＬＣに対して、リアルタイ
ムに送信することができる効果がある。

【０１０８】この発明によれば、データをネットワーク
に出力する際、そのデータの情報量に見合う通信帯域を
確保するように構成したので、リアルタイムのデータ通
信を実現することができる効果がある。

【０１０９】この発明によれば、データの転送要求又は
送信要求を受け付けると、タグビューをアクセスするよ
うに構成したので、ＤＥＶＩＣＥ指定の場合でも、高速
なデータ処理を実現できる効果がある。

【０１１０】この発明によれば、タグビューとキャッシ
ュを同一のメモリ領域に割り当てるように構成したの
で、タグビューの値を変更すると、自動的にＩｔｅｍの
値が変更される効果がある。また、ＤＥＶＩＣＥとＣＡ
ＣＨＥの指定先が同一の領域となるため、ＤＥＶＩＣＥ
指定を実行する処理とＣＡＣＨＥ指定を実行する処理が
同じになり、同一コードの使用が可能になる効果があ
る。

【０１１１】この発明によれば、デバイスに対する第２
のミドルウエアの要求を受け付ける受付手段を設けるよ
うに構成したので、ＰＬＣ上のミドルウェアやアプリケ
ーションに対して、デバイスをアクセスする際の共通の
インタフェースを提供することができる効果がある。

【０１１２】この発明によれば、他のミドルウエアがネ
ットワークからデータの転送要求を取得すると、デバイ
スから取得したデータを周期的にネットワークに出力す
るように構成したので、デバイスから取得したデータを
ＯＰＳに対して、リアルタイムに転送することができる
効果がある。

【０１１３】この発明によれば、サーバアプリケーショ
ンがデータの送信要求を受け付けると、ミドルウエアが
データを周期的にネットワークを介して他のミドルウエ
アに送信するように構成したので、ＯＰＳ内のデータを
ＰＬＣに対して、リアルタイムに送信することができる
効果がある。

【０１１４】この発明によれば、ミドルウエアがデータ
をネットワークに出力する際、そのデータの情報量に見
合う通信帯域を確保するように構成したので、リアルタ
イムのデータ通信を実現することができる効果がある。

【０１１５】この発明によれば、サーバアプリケーショ
ンがデータの転送要求又は送信要求を受け付けると、タ
グビューをアクセスするように構成したので、ＤＥＶＩ
ＣＥ指定の場合でも、高速なデータ処理を実現できる効
果がある。

【０１１６】この発明によれば、タグビューとキャッシ
ュを同一のメモリ領域に割り当てるように構成したの
で、タグビューの値を変更すると、自動的にＩｔｅｍの
値が変更される効果がある。また、ＤＥＶＩＣＥとＣＡ
ＣＨＥの指定先が同一の領域となるため、ＤＥＶＩＣＥ
指定を実行する処理とＣＡＣＨＥ指定を実行する処理が
同じになり、同一コードの使用が可能になる効果があ
る。

【０１１７】この発明によれば、デバイスに対する他の
ミドルウエアの要求を受け付けるサーバアプリケーショ
ンを設けるように構成したので、ＰＬＣ上のミドルウェ
アやアプリケーションに対して、デバイスをアクセスす
る際の共通のインタフェースを提供することができる効
果がある。

【図面の簡単な説明】

【図１】 この発明の実施の形態１による監視制御装置
を示す構成図である。

【図２】 ＯＰＳ上のＯＰＣサーバとミドルウェア、Ｐ
ＬＣ上のミドルウェアの内部構成を示す構成図である。

【図３】 タグメッセージのデータ構造を示す構造図で
ある。

【図４】 タグ要求メッセージのデータ構造を示す構造
図である。

【図５】 要求処理メッセージのデータ構造を示す構造
図である。

【図６】 処理完了メッセージのデータ構造を示す構造
図である。

【図７】 タグ定義ファイルのデータ構造を示す構造図
である。

【図８】 ＰＬＣ上の送信テーブルのデータ構造を示す
構造図である。

【図９】 ＰＬＣの受信スレッドのフローチャートであ
る。

【図１０】 ＰＬＣの送信スレッドのフローチャートで
ある。

【図１１】 ＰＬＣの要求受信スレッドのフローチャー
トである。

【図１２】 ＰＬＣの直接アクセススレッドのフローチ
ャートである。

【図１３】 タグビュー定義ファイルのデータ構造を示
す構造図である。

【図１４】 ＯＰＳ上の送信テーブルのデータ構造を示
す構造図である。

【図１５】 ＯＰＳの受信スレッドのフローチャートで
ある。

【図１６】 ＯＰＳの送信スレッドのフローチャートで
ある。

【図１７】 ＯＰＳの要求送信スレッドのフローチャー
トである。

【図１８】 ＯＰＳの直接アクセススレッドのフローチ
ャートである。

【図１９】 Ｉｔｅｍタグビュー対応テーブルのデータ
構造を示す構造図である。

【図２０】 非同期スレッドのフローチャートである。

【図２１】 通知スレッドのフローチャートである。

【図２２】 この発明の実施の形態２による監視制御装
置を示す構成図である。

【図２３】 ＯＰＳ上のＯＰＣサーバとミドルウェア、
ＰＬＣ上のミドルウェアの内部構成を示す構成図であ
る。

【図２４】 この発明の実施の形態３による監視制御装
置を示す構成図である。

【図２５】 ＯＰＳ上のＯＰＣサーバとミドルウェア、
ＰＬＣ上のミドルウェアの内部構成を示す構成図であ
る。

【図２６】 ＯＰＳ上の通知スレッドのフローチャート
である。

【図２７】 ＯＰＳの受信スレッドのフローチャートで
ある。

【図２８】 この発明の実施の形態４による監視制御装
置を示す構成図である。

【図２９】 従来の監視制御装置を示す構成図である。

【図３０】 ＯＰＳやＰＬＣの内部構成を示す構成図で
ある。

【符号の説明】

１３ ネットワーク、１４ デバイス、１５ ＯＰＣク
ライアント（受付手段）、１６，２３ ＯＰＣサーバ
（受付手段）、１７ ミドルウエア（第１のミドルウエ
ア）、１８ ミドルウエア（第２のミドルウエア）、２
０ ＣＡＣＨＥ（キャッシュ）、２１ タグビュー。

Claims (12)

【特許請求の範囲】
1. 【請求項１】 データの転送要求を受け付ける受付手段
   と、上記受付手段が転送要求を受け付けると、その転送
   要求をネットワークに出力するとともに、その転送要求
   に伴って転送されたデータをネットワークから取得する
   第１のミドルウエアと、上記第１のミドルウエアからネ
   ットワークに出力された転送要求を取得すると、デバイ
   スから取得したデータを周期的にネットワークに出力す
   る第２のミドルウエアとを備えた監視制御装置。
2. 【請求項２】 第１のミドルウエアは、受付手段がデー
   タの送信要求を受け付けると、データを周期的にネット
   ワークを介して第２のミドルウエアに送信することを特
   徴とする請求項１記載の監視制御装置。
3. 【請求項３】 第１及び第２のミドルウエアは、データ
   をネットワークに出力する際、そのデータの情報量に見
   合う通信帯域を確保することを特徴とする請求項１また
   は請求項２記載の監視制御装置。
4. 【請求項４】 受付手段は、データの転送要求又は送信
   要求を受け付けるとタグビューをアクセスすることを特
   徴とする請求項１から請求項３のうちのいずれか１項記
   載の監視制御装置。
5. 【請求項５】 タグビューとキャッシュを同一のメモリ
   領域に割り当てることを特徴とする請求項４記載の監視
   制御装置。
6. 【請求項６】 デバイスに対する第２のミドルウエアの
   要求を受け付ける受付手段を設けたことを特徴とする請
   求項１から請求項５のうちのいずれか１項記載の監視制
   御装置。
7. 【請求項７】 サーバアプリケーションがデータの転送
   要求を受け付けると、ミドルウエアがその転送要求をネ
   ットワークに出力するとともに、その転送要求に伴って
   転送されたデータをネットワークから取得する一方、他
   のミドルウエアがネットワークからデータの転送要求を
   取得すると、デバイスから取得したデータを周期的にネ
   ットワークに出力する監視制御方法。
8. 【請求項８】 サーバアプリケーションがデータの送信
   要求を受け付けると、ミドルウエアがデータを周期的に
   ネットワークを介して他のミドルウエアに送信すること
   を特徴とする請求項７記載の監視制御方法。
9. 【請求項９】 ミドルウエアがデータをネットワークに
   出力する際、そのデータの情報量に見合う通信帯域を確
   保することを特徴とする請求項７または請求項８記載の
   監視制御方法。
10. 【請求項１０】 サーバアプリケーションがデータの転
    送要求又は送信要求を受け付けると、タグビューをアク
    セスすることを特徴とする請求項７から請求項９のうち
    のいずれか１項記載の監視制御方法。
11. 【請求項１１】 タグビューとキャッシュを同一のメモ
    リ領域に割り当てることを特徴とする請求項１０記載の
    監視制御方法。
12. 【請求項１２】 デバイスに対する他のミドルウエアの
    要求を受け付けるサーバアプリケーションを設けたこと
    を特徴とする請求項７から請求項１１のうちのいずれか
    １項記載の監視制御方法。