JP2014510345A - プロセス制御または監視環境における無線通信のための方法および装置 - Google Patents

Abstract

汎用無線通信プロトコルに従ってリモート装置と無線で通信するための通信スタックを実装する通信装置における方法であって、そのリモート装置がプロセス制御環境内で動作し、その方法は、そのリモート装置との無線通信リンクを確立するためにソフトウェアモジュールから要求を受信すること、ソフトウェアモジュールと通信スタックとの間に、仲介サービスのない、直接接続を確立すること、および産業オートメーションプロトコルに従い、無線通信リンクを通じて、ソフトウェアモジュールとリモート装置との間でプロセスデータを伝達することを含み、その無線通信リンクが汎用無線通信プロトコルを利用する。
【選択図】図４

Description

本発明は、一般にプロセス制御ネットワークに関し、より詳細には、携帯機器を介してフィールド装置を操作することに関する。

化学プロセスプラントまたは石油処理プラントで使用されるような、自動化プロセス制御システムを構成、監視、およびトラブルシューティングするオペレータは、フィールド内のシステムコンポーネントにアクセスするために、しばしば、携帯型またはそうでなければ可搬式のフィールドメンテナンス装置を使用する。通常、プロセスを制御および／または監視するためのシステムは、少なくとも１つのホストまたはオペレータワークステーション、ならびに、１つまたは複数の、例えば、フィールド装置などのプロセス制御および計装装置に、アナログ、デジタル、またはアナログ／デジタル結合バスを経由して通信的に結合された、１つもしくは複数の集中型または分散型のプロセスコントローラを含む。フィールド装置は、例えば、バルブ、バルブポジショナ、スイッチ、送信機、およびセンサー（例えば、温度、圧力、および流量センサー）であり得るが、プロセスプラント環境内に配置されて、バルブの開閉、プロセスパラメータの測定、流量の増減などの機能をプロセス内で実行する。周知のＦＯＵＮＤＡＴＩＯＮ^ＴＭ Ｆｉｅｌｄｂｕｓ（以下「Ｆｉｅｌｄｂｕｓ」）プロトコル（例えば、ＦＯＵＮＤＡＴＩＯＮ Ｆｉｅｌｄｂｕｓ Ｖｅｒｓｉｏｎ ５．１）または、ＨＡＲＴ（登録商標）プロトコル（例えば、２０１０年４月に国際電気標準会議によってＩＥＣ ６２５９１として承認されたバージョン）に適合するフィールド装置などのスマートフィールド装置は、制御計算、警報機能、および、プロセスコントローラ内で一般に実装されている他の制御機能も実行する。

プロセスコントローラは、通常、プロセスプラント環境内に配置されるが、フィールド装置によって作成されたか、またはフィールド装置に関連したプロセス測定値もしくはプロセス変数を示す信号および／またはフィールド装置に関する他の情報を受信して、コントローラアプリケーションを実行する。コントローラアプリケーションは、例えば、プロセス制御判断を行い、受信した情報に基づいて制御信号を生成し、ＨＡＲＴおよびＦｉｅｌｄｂｕｓフィールド装置などのフィールド装置内で実行されている制御モジュールまたはブロックに合わせる、異なる制御モジュールを実装する。プロセスコントローラ内の制御モジュールは、通信回線または信号経路を通じて制御信号をフィールド装置に送信し、それによってプロセスの操作を制御する。

フィールド装置およびプロセスコントローラからの情報は、オペレータまたは保守要員が、例えば、プロセス制御ルーチンの設定の変更、プロセスコントローラまたはスマートフィールド装置内の制御モジュールの操作の修正、プロセスまたはプロセスプラント内の特定装置の現在の状態の表示、フィールド装置およびプロセスコントローラによって生成された警報の表示、人員の訓練またはプロセス制御ソフトウェアのテストのためのプロセス操作のシミュレーション、プロセスプラント内の問題またはハードウェア障害の診断などの、プロセスに関連した所望の機能を実行するために、通常、例えば、オペレータワークステーション、メンテナンスワークステーション、パーソナルコンピュータ、携帯端末、データヒストリアン（ｄａｔａ ｈｉｓｔｏｒｉａｎ）、レポートジェネレータ、集中型データベースなどの、１つまたは複数の他のハードウェア装置に提供される。

標準的なプロセスプラントは、１つまたは複数のプロセスコントローラに接続された、バルブ、送信機、センサーなどの、多数のプロセス制御および計装装置を有すると同時に、プロセス操作に必要な、またはプロセス操作に関連する多数の他のサポート装置が存在する。これらの追加の装置は、例えば、電力供給装置、発電および配電装置、タービン、モーターなどの回転装置などを含み、それらは、標準的なプラント内の多数の場所に配置される。この追加の装置は、必ずしもプロセス変数を作成または使用せず、多くの場合、制御されないか、またはプロセス操作に影響を及ぼすためにプロセスコントローラに結合さえされていないが、この装置は、それにもかかわらず、プロセスの適切な操作のために重要であり、最終的に必要である。

周知のように、プロセスプラント環境内、特に、多数のフィールド装置およびサポート装置を有するプロセスプラントでは、問題が頻繁に起こる。これらの問題は、故障したかまたは誤動作した装置、不適切なモードであるソフトウェアルーチンなどの論理要素、不適切に調整されているプロセス制御ループ、プロセスプラント内の装置間での通信における１つまたは複数の障害などの形をとり得る。これらおよび他の問題は、本質的に多数であるが、一般に、プロセスプラントの準最適な性能に通常関連する異常な状態（すなわち、異常な状況にあるプロセスプラント）で操作するプロセスという結果となる。

フィールド装置および他の装置は、例えば、Ｅｍｅｒｓｏｎ ４７５ Ｃｏｍｍｕｎｉｃａｔｏｒなどの携帯型フィールドメンテナンス装置を使用するか、または、スマートフォンもしくは携帯情報端末（ＰＤＡ）などの汎用携帯機器上で実行しているソフトウェアアプリケーションを使用して、フィールド内でローカルに分析され得る。例えば、Ｅｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ ＭａｎａｇｅｍｅｎｔからのＶａｌｖｅＬｉｎｋ Ｍｏｂｉｌｅソフトウェアは、携帯機器上で実行でき、セットアップ、較正、およびトラブルシューティング機能を提供する。いくつかの装置は有線および無線通信の両方をサポートしているが、一般に、オペレータは、無線通信がほとんどのアプリケーションに対して便利であることがわかる。

通常、携帯機器は、ある産業オートメーションプロトコル（ＨＡＲＴまたはＦｉｅｌｄｂｕｓなど）に従い、仮想シリアル（「ＣＯＭ」）ポートを使用して、プロセス制御または診断情報をフィールド装置へ、およびフィールド装置から伝送するために、無線接続を確立する。さらに具体的に言うと、携帯機器は、Ｂｌｕｅｔｏｏｔｈ（登録商標）などのある標準に従って無線通信をサポートする無線通信スタックを含む。エミュレーションソフトウェアは、携帯機器上で実行しているアプリケーションと通信スタックとの間のインタフェースとして働く仮想ＣＯＭポート機能をサポートする。その結果、ＣＯＭ通信をサポートするソフトウェアアプリケーションは、エミュレーションソフトウェアを使用して仮想ＣＯＭポートに接続し、通信スタックと直接やりとりすることなく、無線通信リンクを経由してデータを送受信する。

しかし、仮想ＣＯＭポート経由の通信は、著しい設定努力を要する。例えば、ＨＡＲＴメッセージをＢｌｕｅｔｏｏｔｈ経由でフィールド装置と交換するために携帯機器上でアプリケーションを設定するには、ユーザーは、携帯機器のＢｌｕｅｔｏｏｔｈ無線をオンにし、その携帯機器を、フィールド装置に結合されたＨＡＲＴモデムとペアにし、そのペアにしたフィールド装置に関連したアウトバウンド仮想ＣＯＭポートを確立し、アプリケーションに、その仮想ＣＯＭをペアにしたフィールド装置と関連付けるように指示する必要がある。その上、アプリケーションがペアにしたフィールド装置とのメッセージ交換を完了すると、ユーザーは忘れずにＢｌｕｅｔｏｏｔｈ無線をオフにしなければならない。

いくつかの実施形態では、ソフトウェアアプリケーションは、仮想ＣＯＭポートをオープンすることなく、適切な通信スタックにアクセスすることにより、プロセス制御および／または監視データをリモート装置と交換するための無線通信リンクを確立する。ソフトウェアアプリケーションは、スマートフォン、ＰＤＡなどの携帯機器上で実行し得る。通信スタックにこのようにアクセスする（本明細書では、「直接アクセス」と呼ぶ）ため、アプリケーションは、通信スタックの直接操作のための１つまたはいくつかのアプリケーションプログラミングインタフェース関数（ＡＰＩ）（以下、「通信ＡＰＩ」）を呼び出し得る。実施形態に応じて、通信ＡＰＩは、同期または非同期関数呼出しに対応する。例えば、通信ＡＰＩは、呼び出された関数がアプリケーションの呼出しスタック内にあるように、アプリケーションが、通信スタックに関連した関数を直接呼び出せるようにし得る。あるいは、通信ＡＰＩは、アプリケーションが、別個のタスク（例えば、プロセス、スレッド）として実装され、通信スタックをサービスする、サービスとやりとりできるようにする。

通信スタックは、例えば、ＢｌｕｅｔｏｏｔｈまたはＩｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ（ＩｒＤＡ）などの通信標準に従って、短距離用無線通信を提供し得る。実施形態に応じて、通信スタックは、携帯機器のオペレーティングシステムのコンポーネントとして、またはＢｒｏａｄｃｏｍ ＣｏｒｐｏｒａｔｉｏｎによるＷＩＤＣＯＭＭ ＢｌｕｅｔｏｏｔｈスタックまたはＭｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎによるＢｌｕｅｔｏｏｔｈスタックなどの別個に提供されたソフトウェアコンポーネントとして、提供される。通信スタックは、標準ＡＰＩのセットによって提供され得る。

いくつかの実施形態では、ソフトウェアアプリケーションは、通信スタックに関連した関数を、直接に、またはそのアプリケーションのコードに組み込まれた通信ＡＰＩを介して呼び出す。別の実施形態では、通信ＡＰＩは、例えば、ダイナミックリンクライブラリ（ＤＬＬ）などの別個にインストール可能なコンポーネントとして提供される。

いくつかの実施形態では、通信ＡＰＩは、アプリケーションが、例えば、ＨＡＲＴなどの、プロセス制御および／または監視情報を伝達するために特別に定義されたコマンドおよび／または情報要素をサポートする通信プロトコルに従って動作するリモート装置と、無線通信リンクを確立できるようにする。

本開示の技術を実装する携帯型コミュニケータが使用できるプロセス制御システム例を示す。 図１のシステムで動作する携帯型コミュニケータ例のブロック図である。 アプリケーションが、プロセス制御または監視情報を無線通信リンク経由で伝達する、従来技術のソフトウェアシステムのブロック図である。 ユーザーが、それを介してセットアップおよび構成関数を呼び出し得る、携帯機器のインタフェース画面例である。 アプリケーションが、プロセス制御または監視情報を伝達するために無線通信スタックと直接やりとりするソフトウェアシステム例のブロック図である。 携帯機器上の無線通信スタックとの直接接続を確立するための方法例の流れ図である。 携帯機器上の無線通信スタックとの直接接続を構成するための方法例の流れ図である。

図１は、オペレータが、携帯型コミュニケータ１２を使用して、制御および／または監視を行うことができる装置を含むプロセス制御システム１０の例を示す。本明細書に記述する実施形態では、携帯型コミュニケータ１２は、無線通信スタックによってサービスされる双方向の無線モジュールを備えている。携帯型コミュニケータ１２は、専用の携帯型フィールドメンテナンス装置（Ｅｍｅｒｓｏｎ ４７５ Ｃｏｍｍｕｎｉｃａｔｏｒなど）または、ソフトウェアアプリケーションが無線通信スタックに直接アクセスできるようにするソフトウェアコンポーネントを含むスマートフォンまたはＰＤＡなどの汎用携帯機器であるため、アプリケーションは仮想ＣＯＭポートに頼る必要がない。このように、オペレータは、装置に容易かつ迅速にアクセスできる。

プロセス制御システム１０は、１つまたは複数のホストワークステーションまたはコンピュータ１５（任意のタイプのパーソナルコンピュータまたはワークステーションであり得る）に接続され、かつ、入力／出力（Ｉ／Ｏ）装置２０、２２のバンクに接続され、次いで当該入力／出力装置２０、２２の各々が１つまたは複数のフィールド装置２５に接続されている、１つまたは複数のプロセスコントローラ１４を含む。コントローラ１４は、ほんの一例として、Ｆｉｓｈｅｒ−Ｒｏｓｅｍｏｕｎｔ Ｓｙｓｔｅｍｓ，Ｉｎｃ．，によって販売されているＤｅｌｔａＶ^ＴＭコントローラであり得るが、例えば、イーサネット（登録商標）接続４０または他の通信リンクを介して、ホストコンピュータ１５に通信接続されている。同様に、コントローラ１４は、例えば、標準的な４〜２０ｍａ装置および／または、ＦｉｅｌｄｂｕｓもしくはＨＡＲＴプロトコルなどの任意のスマート通信プロトコルに関連した任意の所望のハードウェアおよびソフトウェアを使用して、フィールド装置２５に通信接続される。周知のように、コントローラ１４は、プロセスを任意の所望の方法で制御するために、その中に格納されているか、またはそれに関連したプロセス制御ルーチンを実装または監視（ｏｖｅｒｓｅｅ）し、装置２５〜３６と通信する。

フィールド装置２５は、センサー、バルブ、送信機、ポジショナなどの、任意のタイプの装置であり得るが、バンク２０および２２内の入出力カードは、ＨＡＲＴ、Ｆｉｅｌｄｂｕｓ、Ｐｒｏｆｉｂｕｓなどの任意の所望の通信またはコントローラプロトコルに準拠した任意のタイプの入出力装置であり得る。図１に示す実施形態では、フィールド装置２５ａ〜２５ｃは、アナログ回線を通じて入出力カード２２ａと通信する標準的な４〜２０ｍａ装置である。フィールド装置２５ｄ〜２５ｆは、ＨＡＲＴ互換の入出力カード２０Ａに接続されたＨＡＲＴ装置として示されている。同様に、フィールド装置２５ｊ〜２５ｌは、デジタルバス４２または４４を通じて、例えば、Ｆｉｅｌｄｂｕｓプロトコル通信を使用する入出力カード２０Ｂまたは２２Ｂと通信するＦｉｅｌｄｂｕｓフィールド装置などのスマートデバイスである。言うまでもなく、フィールド装置２５ならびに入出力カード２０および２２のバンクは、将来開発される任意の標準またはプロトコルを含む、４〜２０ｍａ、ＨＡＲＴ、またはＦｉｅｌｄｂｕｓプロトコルに加えて、任意の他の所望の標準またはプロトコルに適合し得る。

一実施形態では、コントローラ１４の各々は、一般に機能ブロックと呼ばれるものを使用して、制御方式を実装するように構成されており、各機能ブロックは、全体的な制御ルーチンの一部（例えば、サブルーチン）であり、プロセス制御システム１０内でプロセス制御ループを実装するために、他の機能ブロックとともに（リンクと呼ばれる通信を介して）動作する。機能ブロックは通常、プロセス制御システム１０内で何らかの物理的機能を実行するために、送信機、センサーまたは他のプロセスパラメータ測定装置に関連するような入力機能、ＰＩＤ、ファジー理論などの制御を実行する制御ルーチンに関連するような制御機能、またはバルブなどの何らかの装置の操作を制御する出力機能のうちの１つを実行する。言うまでもなく、ハイブリッドおよび他のタイプの機能ブロックも存在する。さらに、機能ブロックのグループはモジュールと呼ばれる。機能ブロックおよびモジュールは、コントローラ１４内に格納され、コントローラ１４によって実行され得るか（これは通常、これらの機能ブロックが標準的な４〜２０ｍａ装置およびいくつかのタイプのスマートフィールド装置に対して使用されるか、またはそれらに関連する場合である）、または、フィールド装置自体に格納され、フィールド装置自体によって実装され得る（これは、Ｆｉｅｌｄｂｕｓ装置の場合であり得る）。制御システムの記述が本明細書では機能ブロック制御方式を使用して提供されているが、制御方式は、ラダーロジック、順次流れ図などの他の技法を使用し、かつ任意の所望の独自のまたは独自仕様でないプログラム言語を使用しても実装または設計され得る。

新しい装置を検査もしくはセットアップしている場合、またはフィールド装置を構成もしくはトラブルシューティングしている場合、オペレータは時々、作業中にシステムコンポーネントに物理的に近づいて、これらのコンポーネントを詳しく観察する必要がある（しばしばそうすることを好む）。前述の通り、オペレータは、システム１０の１つまたはいくつかのコンポーネントとの短距離用無線接続を確立するために、携帯型コミュニケータ１２を使用できる。この目的のため、システム１０は、無線モデム６０ａおよび６０ｂなどの無線アクセス用の１つまたはいくつかのアクセスポイントを含み得る。実施形態例では、無線モデム６０ａは、Ｂｌｕｅｔｏｏｔｈ標準に従って動作する無線インタフェース、ＨＡＲＴ通信プロトコルのメッセージをＢｌｕｅｔｏｏｔｈを通じて層（ｌａｙｅｒ）状にするアダプタ、および対応する有線接続経由でＨＡＲＴ装置２５ｆとメッセージを交換するための有線インタフェースを含む。別の例として、無線モデム６０ｂは、Ｂｌｕｅｔｏｏｔｈ標準に従って動作する無線インタフェース、Ｆｉｅｌｄｂｕｓ通信プロトコルのメッセージをＢｌｕｅｔｏｏｔｈを通じて層状にするアダプタ、ならびにデジタルバス４４経由でＦｉｅｌｄｂｕｓ装置２５ｊ、２５ｋ、および２５ｌとメッセージを交換するための有線インタフェースを含む。

ここで図２を参照すると、携帯型コミュニケータ１２は、一実施形態に従って、アンテナ７２、双方向無線周波（ＲＦ）モジュール７４（これは、デジタル信号処理（ＤＳＰ）コンポーネント、エンコーダ、変調器などを含み得る）、データおよびコンピュータプログラムを格納するためのコンピュータ可読メモリ７６、ならびにこれらの命令を実行するための処理装置７８を含む。ＲＦモジュール７４は、Ｂｌｕｅｔｏｏｔｈ（例えば、２００５年に８０２．１５．１プロトコルとして承認されたＢｌｕｅｔｏｏｔｈバージョン１．２）、ＩｒＤＡ（例えば、ＩｒＤＡ Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ ｖ１．４、ＩｒＤＡ Ｌｉｎｋ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ ｖ１．１、ＩｒＤＡ Ｌｉｎｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ ｖ１．１）、または別の通信プロトコルもしくは標準をサポートし得る。いくつかの実施形態では、ＲＦモジュール７４は、例えば、ＩＥＥＥ ８０２．１１（例えば、ＩＥＥＥ ８０２．１１−２００７）または８０２．１５標準の１つとして承認されたプロトコルに従って通信する。処理装置７８は、ユーザー入力および出力をそれぞれ受信および提供するためにシステム８０にも結合される。実施形態に応じて、システム８０は、キーパッド、ポインティング装置、スクリーン、またはタッチスクリーンのうちの１つまたは複数を含む。さらに、携帯型コミュニケータ１２は、例えば、交換可能バッテリーなど、ローカルの電力貯蔵モジュール８２を含み得る。いくつかの実施形態では、携帯型コミュニケータ１２は、例えば、油田掘削装置上または石油精製所内で安全に使用されるための固有の安全要件に従う。

以下でさらに詳細に説明するように、コンピュータ可読メモリ７６上に格納されたプログラムは、携帯型コミュニケータ１２が、ＨＡＲＴ、Ｆｉｅｌｄｂｕｓ、またはＰｒｏｆｉｂｕｓなどの１つまたは複数の産業オートメーションプロトコルに従い、ＲＦモジュール７４によってサポートされる通信プロトコルを通じて、メッセージを送信できるようにするソフトウェアコンポーネントを含み得る。次に、アプリケーションが仮想ＣＯＭポートを使用する無線通信リンクを介して通信する従来技術のソフトウェアシステムが、図３Ａを参照して説明され、続いて、アプリケーションが、例えば、仮想ＣＯＭポートを使用することなく、無線通信スタックに直接アクセスする図４の効率的なシステムが説明される。図３Ａおよび図４に示すソフトウェアシステムは、携帯型コミュニケータ１２などの装置内で実装され得る。

まず図３Ａを参照すると、システム１００は、Ｂｌｕｅｔｏｏｔｈなどの無線通信スタックをサービスする無線スタックサービス１０４、１つまたは複数の仮想ＣＯＭポートをサービスする仮想ＣＯＭポートサービス１０６、ＨＡＲＴなどの産業オートメーションプロトコルを使用するプロセス制御システムのコンポーネントを監視および／または制御するためのアプリケーション１０８、ならびにおそらく他のサービスおよびアプリケーションをサポートする、ソフトウェアフレームワーク１０２を含む。ソフトウェアフレームワーク１０２は、例えば、Ｗｉｎｄｏｗｓ（登録商標） Ｍｏｂｉｌｅ、Ｓｙｍｂｉａｎ、またはＡｎｄｒｏｉｄ（登録商標）などのオペレーティングシステムを含み得る。一般に、ソフトウェアフレームワーク１０２は、携帯型コミュニケータの物理リソースおよび論理リソースならびにファイルシステム操作などの基本サービスへのアクセス、ユーザー入力および出力装置へのアクセスなどを提供する。いくつかの実施形態では、無線スタックサービス１０４は、ソフトウェアフレーム１０２と一体である。対応するハードウェアコンポーネントとともに、ソフトウェアフレーム１０２は、携帯型コミュニケータのプラットフォームを定義する。

無線スタックサービス１０４によってサービスされる無線通信スタックを使用するため、アプリケーション１０８は、仮想ＣＯＭポートサービス１０６がエミュレートする仮想ＣＯＭポートとやりとりするため、１つまたは複数のＣＯＭポートＡＰＩ １１０を呼び出す。しかし、ユーザーは、無線スタックサービス１０４を起動し、仮想ＣＯＭポートサービス１０６（および、いくつかの場合には、無線スタックサービス１０４）を構成し、対象とする装置との無線接続を確立し、アプリケーションに仮想ＣＯＭポートをその対象とする装置と関連付けるように指示する必要がある。ユーザーがこれらの設定ステップを完了した後にのみ、アプリケーション１０２は、監視および／または制御情報を対象とする装置と交換できるようになる。

前述の通り、このセットアップおよび設定手順は、時間がかかり、かつ、間違いを起こしやすい。例えば、図３Ｂに示すタッチスクリーンのインタフェース画面例１２０を参照すると、ユーザーは、コントロール１２２を介して「Ｂｌｕｅｔｏｏｔｈを接続する」ユーティリティを起動し、対応するプラットフォーム上でＢｌｕｅｔｏｏｔｈセットアップ手順に関連したステップに従い、そして、コントロール１２４を操作することにより仮想ＣＯＭポートセットアップ手順を開始する必要がある。例えば、バルブストローク（ｖａｌｖｅ ｓｔｒｏｋｅ）検査を実施するために、ユーザーは次いで、コントロール１２６を操作して、適切なソフトウェアアプリケーションを呼び出し得る。アプリケーションは通常、ユーザーが、コントロール１２４および１２２をそれぞれ使用して構成された仮想ＣＯＭポートおよびＢｌｕｅｔｏｏｔｈリンクを介して無線接続を構成およびセットアップできるようにするダイアログを表示する。

その上、上で概説した設定問題はしばしば、異なるベンダーによる無線通信スタックの実装における相違、およびより詳細には、構成ユーティリティにおける相違によって悪化する。例えば、いくつかのベンダーは、ユーザーが、ポートを利用するアプリケーションを開始する前に仮想ＣＯＭポートをセットアップすることを必要とするが、他のベンダーは、これらのステップが逆の順序で実行されることを必要とする。

一方、図４に示すシステム１５０は、ＡＰＩのセット１２６を介して、無線スタックサービス１２４と直接やりとりするアプリケーション１２２を含み、それ故、仮想ＣＯＭポートに関連した複雑な構成を必要としない。アプリケーション１５２は、無線スタックＡＰＩのセット１５６を使用して、無線スタックサービス１５４と直接やりとりできる。さらに具体的に言うと、アプリケーション１５２は、ＨＡＲＴ、Ｆｉｅｌｄｂｕｓ、Ｐｒｏｆｉｂｕｓなどの産業オートメーションプロトコルに従い、携帯型コミュニケータによってサポートされる無線通信スタックを通じて、メッセージを送信し得る。一実施形態では、アプリケーション１５２は、バルブのリモート制御、監視、および診断を提供する、Ｅｍｅｒｓｏｎ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔによって販売されるＶａｌｖｅＬｉｎｋ Ｍｏｂｉｌｅである。

再度、図２を参照すると、無線スタックサービス１２４は、Ｂｌｕｅｔｏｏｔｈ無線、ＩｒＤＡ通信モジュールなどであり得るＲＦモジュール７４を制御し得る。ソフトウェアコンポーネント１５２、１５４、１５６、および１６２は、メモリ７６に格納可能とされ、ＣＰＵ ７８によって実行され得る。

いくつかの実施形態では、ＡＰＩ １５６は、無線スタックサービス１５４によって公開されている関数のセット、すなわち、データの送受信用に無線スタックサービス１５４の開発者によって提供されている関数である。他の実施形態では、ＡＰＩ １５６は、アプリケーションと無線通信スタックとの間にポーティング層を定義するため、無線スタックサービス１５４によって公開されているＡＰＩの「ラッパー」を含む。一実施形態では、例えば、ＡＰＩ １５６は、複数のアプリケーションによって使用するためのダイナミックリンクライブラリ（ＤＬＬ）など、別個のソフトウェアコンポーネントとして提供される。

システム例１５０では、アプリケーション１５２および無線スタックサービス１５４は、フレームワーク１２８によって提供されるプロセス間通信（ＩＰＣ）機構を使用してやりとりする別個のタスク（例えば、プロセス、スレッド）である。例えば、フレームワーク１２８は、メッセージング、共有メモリ領域を介して情報を交換する機構などを提供し得る。その結果、アプリケーション１５２と無線スタックサービス１５４との間のやりとりは、非同期関数呼び出しを含み得る。しかし、他の実施形態では、無線通信スタック１５４の無線スタック関数１６２は、アプリケーション１５２の呼出しスタック上で実行され得る。言い換えれば、アプリケーション１５２は、関数１６２を直接（またはＡＰＩ １５６を介して）同期した方法で呼び出し得る。これらの実施形態の少なくともいくつかでは、無線スタックサービス１５４は、別個のタスクとして実行されない。

他方、他の実施形態では、無線スタックＡＰＩ １５６は、アプリケーション１５２と無線スタックサービス１５４との間のインタフェースとして機能する別のタスクとやりとりし得る。一般に、アプリケーション１５２と無線スタック関数１６２との間の直接のやりとりは、実装に従って（それは、結果として、フレームワーク１６０の要件に応じ得る）、同じ呼出しスタックまたは別個の呼出しスタック上の関数呼び出しを介し、かつ１つまたはいくつかのタスクを使用して、実装され得ることが理解されるであろう。

無線通信スタックへの直接アクセスを実装するため、アプリケーション１５２および／または無線スタックＡＰＩ １５６は、アプリケーション１５２によって使用される産業オートメーションプロトコルのドライバの機能を提供し得る。例えば、アプリケーション１５２が、フィールド装置を監視または制御するためにＨＡＲＴを使用する場合、無線スタックＡＰＩ １５６は、ＨＡＲＴ接続のタイミング、ブロッキング、および他の属性をエミュレートするため、コマンドごとに定義され得る。従って、無線スタックＡＰＩ １５６は、ＨＡＲＴ通信リンクをアプリケーション１５２に対して提示するために、受信したＨＡＲＴコマンドを認識し、また、これら実施形態のいくつかでは、それを一部実行する（例えば、リターンコード、進捗表示、スケジューリング表示などを提供する）。さらに詳細な例として、無線スタックＡＰＩ １５６のうちの１つは、受信ＨＡＲＴ装置に拡張装置タイプコード、リビジョンレベル、および装置識別番号で応答させる、ＨＡＲＴコマンド０（ゼロ）のフォーマットおよび伝送を実装し得る。ＡＰＩは、コマンドをフォーマットし、そのフォーマットされたコマンドを無線通信スタックを通して転送させ、適切なタイミングおよびブロッキングなどを確実にし得る。一実施形態では、ＡＰＩは、ＨＡＲＴコマンド０に対する応答の処理、エラーの確認などを行う状態機械も実装する。別の実施形態では、ＡＰＩは、ＨＡＲＴコマンドを通信スタックを通して送信した直後に、制御を呼出しアプリケーション１５２に戻し、別のソフトウェアコンポーネント（例えば、スレッド）が、応答が受信されている無線スタックサービス１５４から通知を受信して処理する。次いで、応答（または通知）は、アプリケーション１５２に転送される。

一般に、無線スタックＡＰＩ １５６（および、いくつかの実施形態では、無線スタックサービス１５４によってサービスされる無線通信スタックへのアプリケーション１５２の直接アクセスを容易にするために、フレームワーク１６０内で別個のタスクとして実行しているコンポーネント）は、携帯型コミュニケータの通信スタックによって通常は提供されない産業オートメーションプロトコル（例えば、マスター／スレーブ構成）に関連した通信機構を提供する。例えば、Ｂｌｕｅｔｏｏｔｈ標準は、周知のように、マスター／スレーブ通信プロトコルを提供していない。

さらに、いくつかの実施形態では、アプリケーション１５２および／または無線スタックＡＰＩ １５６は、他のサービスまたはアプリケーションが無線スタック機能を呼び出すことができるようにするために、無線スタック１５４を利用する。例えば、システム１５０がスマートフォン上で実装されていて、無線スタックサービス１５４がＢｌｕｅｔｏｏｔｈ標準に従って動作する場合、アプリケーション１５２は、無線スタックサービス１５４のリソースの一部のみを使用し、無線スタック１５４は、フィールド装置と通信している間に同時に、例えば、音声をユーザーのヘッドフォンに送信できる。

いくつかの実施形態では、無線スタックＡＰＩ １５６は、例えば、ユーザーがアプリケーション１５２を起動した場合に、適切なコマンドを無線スタックサービス１５４に送信することにより、ＲＦモジュール７４（図２を参照）を自動的にオンにするなどの追加の機能を提供し得る。このように、構成がさらに単純化され、オペレータは、アプリケーションを使用する前に、無線リンクを忘れずにアクティブにする必要がない。

さらに、無線スタックＡＰＩ １５６は、無線スタックサービス１５４のタイプ（例えば、製造業者、バージョン）を自動的に判断して、適切な構成オプションを自動的に選択し得る。例えば、ある無線スタックＡＰＩは、Ｂｌｕｅｔｏｏｔｈ通信スタックがＭｉｃｒｏｓｏｆｔ（登録商標）スタックまたはＷｉｄｃｏｍｍスタックを判断するためにフレームワーク１６０に問合せを行うことができ、問合せの結果に応じて、アプリケーション１５２と無線スタックサービス１５４との間の接続を自動的に確立するための適切な順序を選択し得る。

一実施形態では、無線スタックＡＰＩ １５６は、アプリケーション１５２が、ＨＡＲＴ、Ｆｉｅｌｄｂｕｓ、またはアプリケーション１５２によって使用される別の産業オートメーションプロトコルをサポートする装置を自動的に発見できるようにする。例えば、アプリケーション１５２は、携帯型コミュニケータの範囲内で動作するＨＡＲＴ Ｂｌｕｅｔｏｏｔｈモデムを自動的に発見し得る。ユーザーは次いで、ユーザーが接続したい装置を、アプリケーション１５２の起動時に自動的に生成されたリストから選択し得る。さらに、無線スタックＡＰＩ １５６は、既知のフィールド装置との接続を自動的に確立しようとし得る。その上、所望であれば、無線スタックＡＰＩ １５６は、アプリケーションが、失われた接続を自動的に再確立できるようにし得る。

さらに、いくつかの実施形態では、アプリケーション１５２および／または無線スタックＡＰＩ １５６は、ＨＡＲＴ Ｂｌｕｅｔｏｏｔｈモデムではない全ての隣接したＢｌｕｅｔｏｏｔｈ装置を除去する。この目的のため、アプリケーション１５２は、例えば、無線スタックサービス１５４に、全てのＢｌｕｅｔｏｏｔｈ装置を発見させ、ピア装置がＨＡＲＴ装置であるかどうかを判断するために、対応するＢｌｕｅｔｏｏｔｈリンクを通じてコマンドを送信し、そのコマンドに対する応答が受信されない場合、または、受信された応答がその装置がＨＡＲＴ装置ではないことを示している場合、無線スタックサービス１５４に、その装置を発見された装置のリストから削除させる。

一実施形態では、アプリケーション１５２および／または無線スタックＡＰＩ １５６は、ＲＦモジュール７４が電力貯蔵８２（図２を参照）を効率的に使用できるように、自動電力管理を実装する。例えば、アプリケーション１５２が、ＨＡＲＴ Ｂｌｕｅｔｏｏｔｈモデムに結合されたＨＡＲＴセンサーから定期的に最新データを読み取る場合、アプリケーション１５２は、定期的な更新スケジュール（例えば、５０ミリ秒期間に対して２秒に一度）に従って、Ｂｌｕｅｔｏｏｔｈ ＲＦモジュール７４を（例えば、無線スタックサービス１５４を介して）オンにできる。

所望であれば、アプリケーション５２は、いくつかの実施形態では、ユーザーがアプリケーション１５２を終了した後、携帯型コミュニケータ上で実行している他のサービスまたはアプリケーションが無線スタックサービス１５４を使用していなければ、無線スタックサービス１５４に、ＲＦモジュール７４をオフにさせる。従って、ユーザーは、無線リンクが使用されていない場合、ＲＦモジュール７４を忘れずにオフにする必要がない。

図５は、システム１５０または、無線通信スタックへの直接アクセスを提供する携帯型コミュニケータ上で実行している同様のソフトウェアシステムによって実装され得る方法例２００の流れ図である。ブロック２０２で、プロセス制御および／または監視情報を交換するための、リモート装置への無線接続を確立する要求が受信される。例えば、ユーザーが、ＶａｌｖｅＬｉｎｋ Ｍｏｂｉｌｅなどのアプリケーションを起動すると、そのアプリケーションは自動的に要求を生じさせ得る。その要求は、実施形態に応じて、アプリケーションの呼出しスタック上または別個のタスク内で実行している無線スタックＡＰＩの層によって処理され得る。次に、ブロック２０４で、無線リンクが、例えば、無線プロトコルスタックによって公開されているＡＰＩを使用して直接セットアップされる。一実施形態では、アプリケーションは、タイミング、ブロッキング、およびＨＡＲＴなどの産業通信プロトコルに関連し、Ｂｌｕｅｔｏｏｔｈなどの汎用無線リンクを介して確立された、接続の他のパラメータを制御する状態機械を起動する。次に、ブロック２０６で、プロセス制御および／または監視データが無線リンクを介して交換される。従って、アプリケーションは、ＢｌｕｅｔｏｏｔｈスタックＡＰＩを使用してＨＡＲＴ通信リンクをエミュレートし得る。

図６は、例えば、携帯型コミュニケータの構成をさらに単純にするために、アプリケーションが方法２００の一部として実行できる方法例２１０の流れ図である。ブロック２１２で、無線通信スタックのタイプ（例えば、Ｂｌｕｅｔｏｏｔｈ）が判断される。この目的のため、クエリーが無線スタックサービスに送信され得、対応する応答が処理され得る。クエリーは、例えば、無線スタックサービスのソフトウェアの製造業者およびバージョンを報告し得る。次に、ブロック２１４で、適切なＡＰＩが自動的に選択され得る。例えば、無線スタックサービスがそれ自身をＷｉｄｃｏｍｍスタックとして識別する場合、Ｗｉｄｃｏｍｍ固有のＡＰＩ、状態機械、パラメータなどが使用され得る。

前述の本文は、本開示の多数の異なる実施形態の詳細な記述を説明しているが、本発明の範囲は、本特許の終わりに明記する請求項の文言によって定義されることが理解されるはずである。詳細な記述は例示としてのみ解釈され、また、全ての可能な実施形態の記述は、不可能ではないにしても、非実用的であるので、本発明の全ての可能な実施形態は記述しない。多数の代替実施形態は、現在の技術または本特許の出願日後に開発された技術のいずれかを使用して実装され得るが、それらは依然として本発明を定義する特許請求の範囲に含まれる。

従って、多数の修正および変形が、本開示の精神および範囲から逸脱することなく、本明細書に記述および例示されている技術および構造において行われ得る。その結果、本明細書に記述する方法および装置は例示のみであり、本発明の範囲を制限するものではないことが理解されるはずである。

Claims (24)

1. 汎用無線通信プロトコルに従ってリモート装置と無線で通信するための通信スタックを実装する通信装置における方法であって、前記リモート装置がプロセス制御環境で動作し、前記方法が、
   前記リモート装置との無線通信リンクを確立するためにソフトウェアアプリケーションから要求を受信することと、
   前記ソフトウェアコンポーネントと前記通信スタックとの間に、仲介サービスのない、直接接続を確立することと、
   前記ソフトウェアコンポーネントと前記リモート装置との間で、産業オートメーションプロトコルに従い、前記無線通信リンクを通じて、プロセスデータを伝達することとを含み、
   前記無線通信リンクが前記汎用無線通信プロトコルを利用する、方法。
2. 前記直接接続を確立することが、前記通信スタックと通信するために仮想シリアルポートをオープンしないことを含む、請求項１に記載の方法。
3. 前記汎用無線通信プロトコルがＩＥＥＥ ８０２．１１またはＩＥＥＥ ８０２．１５標準に準拠する、請求項１または２に記載の方法。
4. 前記汎用無線通信プロトコルがＢｌｕｅｔｏｏｔｈ（登録商標）である、請求項１から３のいずれかに記載の方法。
5. 前記産業オートメーションプロトコルが、プロセス制御環境内で制御データまたは診断データを交換するために特に定義された複数のコマンドをサポートする、請求項１から４のいずれかに記載の方法。
6. 前記産業オートメーションプロトコルが、ＨＡＲＴまたはＦｉｅｌｄｂｕｓのうちの１つである、請求項１から５のいずれかに記載の方法。
7. 前記ソフトウェアコンポーネントからの前記要求の受信に応答して、前記通信スタックのタイプを自動的に識別することをさらに含み、
   前記ソフトウェアコンポーネントと前記通信スタックとの間に前記直接接続を確立することが、前記識別されたタイプに従って前記直接接続を確立することを含み、
   前記通信スタックのタイプが、前記通信スタックの少なくとも製造業者およびバージョンを識別する、請求項１から６のいずれかに記載の方法。
8. 前記通信スタックが無線通信モジュール上で動作し、
   前記方法が、
   前記ソフトウェアモジュールからの前記要求を受信した場合に、前記無線通信モジュールの電源をオンにすること、および
   前記ソフトウェアモジュールが前記無線通信リンクをもう使用していないことを検出した場合に、前記無線通信モジュールの電源をオフにすること
   のうちの少なくとも１つをさらに含む、請求項１から７のいずれかに記載の方法。
9. 前記直接接続が、前記ソフトウェアモジュールの呼出しスタック内のアプリケーションプログラミングインタフェース（ＡＰＩ）によって確立される、請求項１から８のいずれかに記載の方法。
10. 前記プロセスデータを伝達することが、
    前記産業オートメーションプロトコルに関連した複数のコマンドのうちの１つを受信することと、
    前記産業オートメーションプロトコルに従って動作する物理リンクをエミュレートするために、前記受信した前記複数のコマンドのうちの１つを部分的に実行することとを含む、請求項１から９のいずれかに記載の方法。
11. 通信装置内で使用するためのソフトウェアモジュールであって、前記通信装置がメモリおよびプロセッサを有し、
    前記通信装置が、
    汎用無線通信プロトコルに従ってプロセス制御環境内で動作するリモート装置と無線で通信するための通信スタックを実装し、前記ソフトウェアモジュールがコンピュータ実行可能命令として前記メモリ内に格納され、かつ、
    前記リモート装置との無線通信リンクを確立するために前記通信装置内で実行しているソフトウェアアプリケーションから要求を受信することと、
    前記ソフトウェアアプリケーションと前記通信スタックとの間に、仲介サービスのない、直接接続を確立することと、
    産業オートメーションプロトコルに従い、前記汎用無線通信プロトコルを利用する前記無線通信リンクを通じて、前記ソフトウェアアプリケーションと前記リモート装置との間でプロセスデータを伝達することとを行うために、前記プロセッサによって実行される、ソフトウェアモジュール。
12. ダイナミックリンクライブラリ（ＤＬＬ）として実装された、請求項１１に記載のソフトウェアモジュール。
13. 前記ＤＬＬが前記ソフトウェアアプリケーションの呼出しスタックで実行される、請求項１１または１２に記載のソフトウェアモジュール。
14. 前記ＤＬＬが複数のＡＰＩ関数を実装し、各々が前記産業オートメーションプロトコルの複数のコマンドのそれぞれ１つに対応する、請求項１１から１３のいずれかに記載のソフトウェアモジュール。
15. 前記ソフトウェアモジュールが、前記ソフトウェアアプリケーションとは別個のプロセスとして実行する専用サービスの呼出しスタックで実行される、請求項１１から１４のいずれかに記載のソフトウェアモジュール。
16. 前記直接接続が、前記通信スタックに関連した仮想シリアルポートのない、請求項１１から１５のいずれかに記載のソフトウェアモジュール。
17. 前記汎用無線通信プロトコルがＩＥＥＥ ８０２．１１またはＩＥＥＥ ８０２．１５に準拠し、かつ、
    前記産業オートメーションプロトコルがプロセス制御環境内で制御データまたは診断データを交換するために特に定義された複数のコマンドをサポートする、請求項１１から１６のいずれかに記載のソフトウェアモジュール。
18. プロセッサと、
    通信装置とプロセス制御環境内で動作するリモート装置との間に無線通信リンクを確立するように構成された無線通信モジュールであって、前記無線通信リンクが、汎用無線通信プロトコルに従って動作する、無線通信モジュールと、
    コンピュータ実行可能命令を格納するためのメモリとを備え、
    前記メモリは、
    前記汎用無線通信プロトコルを実装する通信スタックと、
    前記プロセッサによって実行可能であり、（ｉ）前記通信スタックと、ソフトウェアアプリケーションからの要求に応答して前記プロセッサによって実行される前記ソフトウェアアプリケーションとの間に、仲介サービスのない、直接接続を確立し、（ｉｉ）産業オートメーションプロトコルに従い、前記無線通信リンクを使用する前記無線リンクを通じて、前記ソフトウェアアプリケーションと前記リモート装置との間でプロセスデータを伝達するように構成された、ソフトウェアモジュールとを含む、通信装置。
19. 前記ソフトウェアモジュールが、ダイナミックリンクライブラリ（ＤＬＬ）として実装されている、請求項１８に記載の通信装置。
20. 前記ＤＬＬが複数のＡＰＩ関数を実装し、各々が前記産業オートメーションプロトコルの複数のコマンドのそれぞれ１つに対応する、請求項１８または１９に記載の通信装置。
21. 前記ソフトウェアモジュールが、前記ソフトウェアアプリケーションがプロセスデータを送信しているか、または受信しているかに従って、前記無線通信モジュールの電源を選択的にオンにするようにさらに構成されている、請求項１８から２０のいずれかに記載の通信装置。
22. 前記ソフトウェアアプリケーションが、診断データを前記リモート装置から受信するか、制御データを前記リモート装置に送信するか、または両方を行うように構成されている、請求項１８から２１のいずれかに記載の通信装置。
23. 前記ソフトウェアモジュールが前記通信スタックのタイプを自動的に識別するようにさらに構成され、前記スタックのタイプが前記通信スタックの少なくとも製造業者およびバージョンを識別する、請求項１８から２２のいずれかに記載の通信装置。
24. 前記ソフトウェアモジュールが、仮想シリアルポートの構成のない前記直接接続を確立するように構成されている、請求項１８から２３のいずれかに記載の通信装置。

Images