JP2011238094A - フィールド機器 - Google Patents

Abstract

【課題】一般顧客に不用な情報や機器ベンダーが開示したくない情報（パラメータ）は隠し、サービスメンテナンス時や工場調整時等で必要時のみ、それらを表示することを可能とするフィールド機器を実現する。
【解決手段】複数の機能ブロックの夫々が保有するパラメータ値を、パラメータ表示手段によりパラメータ名称と結び付けてユーザに表示する機能を具備する、ＦＦ（Foundation Fieldbus）規格に準拠するフィールド機器において、
前記パラメータの内、サービスメンテナンスや工場調整時用のパラメータをまとめた少なくとも１個のメンテナンスブロックを備え、
前記パラメータ表示手段によるアクセスと共に、前記ＦＦ規格の仕様であるブロックインスタンシェーション機能により、前記メンテナンスブロックの表示操作と非表示操作とを実行する。
【選択図】図１

Description

本発明は、複数の機能ブロックの夫々が保有するパラメータ値をパラメータ表示手段によりパラメータ名称と結び付けてユーザに表示する機能を具備する、ＦＦ（Foundation Fieldbus）規格に準拠するフィールド機器に関するものである。

図８は、一般的なＦＦ通信型フィールド機器の接続例を示す機能ブロック図である。フィールドコントローラ１は、制御バス２を介してホストコンピュータ３と通信すると共に、フィールドバス４１、４２を介して接続されたフィールド機器と通信する。

この接続例では、フィールドバス４１に機種Ａのフィールド機器５１、５２及び機種Ｂのフィールド機器６１が接続され、フィールドバス４２に機種Ｂのフィールド機器６１が接続されている。これらフィールド機器は、ＦＦ規格に準拠するフィールド機器である。ＦＦ通信型フィールド機器を用いた制御システムについては、特許文献１に技術開示がある。

図９は、一般的なＦＦ通信型フィールド機器（機種Ａ）の内部構造の例を示す機能ブロック図であり、管理仮想デバイス１０及び機能ブロック仮想デバイス２０よりなる。管理仮想デバイス１０は、ネットワーク管理部１１及びシステム管理部１２を備える。

機能ブロック仮想デバイス２０は、トランスデューサブロック２１、アナログインプットブロック２２ａ及びＰＩＤ演算ブロック２２ｂ等の機能ブロック群２２、リソースブロック２３並びにビューオブジェクト２４、トレンドオブジェクト２５、アラートオブジェクト２６、リンクオブジェクト２７で構成されている。

ＦＦ通信型フィールド機器は、入出力値や設定値をユーザに見せるため、各機能ブロックに多くのパラメータを保有している。それらパラメータの中には客先で使用する入出力パラメータや設定パラメータの他に、サービス・メンテナンス時の機器状態確認と調整や、工場調整時の機器設定値の調整を行うためのメンテナンスパラメータ（以下、パラメータＳと総称する）も多数存在する。

パラメータＳを使ったフィールド機器の状態確認や調整は、多くのフィールド機器で行われている。しかしながら、パラメータＳは以下のような特徴を持つことが多く、常時表示することは好ましくない。
（１）サービス・メンテナンス時や製品出荷前の工場調整時等でのみ必要な情報
（２）通常、客先では不要な情報
（３）客先での設定変更を禁止している（若しくは、望まない）情報
（４）機器ベンダー独自技術として隠しておきたい情報

そのため、既存技術ではフィールド機器が持つ全てのパラメータ値を、対応するパラメータ名称と結び付けるためのパラメータ表示手段として、ＦＦ規格に準拠するＤＤ（Device Description）ファイルが機種毎に機器ベンダーによって用意されている。このＤＤファイルを、一般顧客用と、サービス・メンテナンスというように複数用意し、夫々のユーザに応じたファイル、通常は一般顧客用を提供することで対応していた。

図１０は、ＤＤファイルの種別を例示する機能ブロック図である。図１０（Ａ）は、機種Ａに対する一般顧客用ＤＤファイル７１、図１０（Ｂ）は、機種Ａに対するサービス・メンテナンス用ＤＤファイル７２を機器ベンダーが用意した例を示す。２個のＤＤファイルを例示したが、２個に限定されるものではない。

ここでは、機器ベンダーが図１０に示すように、一般顧客用ＤＤファイル７１及びサービス・メンテナンス用ＤＤファイル７２の２種類のＤＤファイルを用意する場合を想定する。この場合、２種類のファイルは以下のような特徴を持つ。

（１）一般顧客用ＤＤファイル７１：
パラメータＳを必要としないため、パラメータＳは正式名称を伏せ、別の名称（例えば、TEST_1, TEST_2等）を記述し、書き込み禁止の属性で定義する。それ以外のパラメータは正式なパラメータ名を記述する。
（２）サービス・メンテナンス用ＤＤファイル：７２
パラメータＳを含め、機器に搭載された全てのパラメータの名称を確認することができるよう、全ての正式なパラメータ名称を記述する。

図１１は、一般顧客用ＤＤファイル７１を利用して機種Ａのフィールド機器にアクセスした場合の、パラメータ表示例を示す機能ブロック図である。図１２は、サービスメンテナンス・工場調整用ＤＤファイル７２を利用して機種Ａのフィールド機器にアクセスした場合の、パラメータ表示例を示す機能ブロック図である。

このとき、図１１のように、パラメータＳは正式名称を伏せて別の名称（例えば、TEST_1, TEST_2等）を表示することで、それらが一般顧客ユーザにとって不要な情報であることを示していた。

また、パラメータＳは一般顧客ユーザにとって不要ではあるが、機器として重要な情報を示していることも多い。パラメータＳが必要時以外で設定変更され、容易に調整値が不適切な値へ変更されることを避けるため、サービスメンテナンス・工場調整時等でのみ設定変更が可能とし、それ以外では容易に設定変更できないようにするため、以下のような仕組みを設けることもあった。
（１）設定変更を可能とするため、キーパラメータを設け、キーパラメータに特定の数値や文字列を一時的に設定することでパラメータＳの設定変更を許可する。
（２）一般顧客用のＤＤファイルに書き込み制限を設ける。

特開２００４−０２９９１０号公報

従来技術では次のような問題がある。
（１）ＤＤファイルはユーザに応じて複数用意しなければならない。
（２）パラメータＳの正式名称を伏せることで、そのパラメータが一般顧客用にとっては不要なパラメータであることを明示することはできても、パラメータの存在自体を隠すことはできない。
（３）センサの性能や特性につながるような機器ベンダーとして隠しておきたい情報も、名称を伏せたパラメータとして値は常に開示される。

本発明の目的は、一般顧客に不用な情報や機器ベンダーが開示したくない情報（パラメータ）は隠し、サービスメンテナンス時や工場調整時等で必要時のみ、それらを表示することを可能とするフィールド機器を実現することにある。

このような課題を達成するために、本発明は次の通りの構成になっている。
（１）複数の機能ブロックの夫々が保有するパラメータ値を、パラメータ表示手段によりパラメータ名称と結び付けてユーザに表示する機能を具備する、ＦＦ（Foundation Fieldbus）規格に準拠するフィールド機器において、
前記パラメータの内、サービスメンテナンスや工場調整時用のパラメータをまとめた少なくとも１個のメンテナンスブロックを備え、
前記パラメータ表示手段によるアクセスと共に、前記ＦＦ規格の仕様であるブロックインスタンシェーション機能により、前記メンテナンスブロックの表示操作と非表示操作とを実行することを特徴とするフィールド機器。

（２）前記ブロックインスタンシェーション機能による前記メンテナンスブロックの表示操作に対し、表示を許可するキー情報の設定を可能としたことを特徴とする（１）に記載のフィールド機器。

（３）前記ブロックインスタンシェーション機能による前記メンテナンスブロックの非表示操作を実行する場合に、前記キー情報を自動的にクリアすることを特徴とする（２）に記載のフィールド機器。

（４）前記キー情報設定の有無にかかわらず、前記ブロックインスタンシェーション機能により前記メンテナンスブロックの非表示操作を可能としたことを特徴とする（２）または（３）に記載のフィールド機器。

（５）前記フィールド機器のリスタートまたは電源再起動時に、前記ブロックインスタンシェーション機能は、前記メンテナンスブロックを非表示操作することを特徴とする（１）乃至（４）のいずれかに記載のフィールド機器。

（６）前記パラメータ表示手段は、前記ＦＦ規格に準拠するＤＤ（Device Description）ファイルであることを特徴とする（１）乃（５）のいずれかに記載のフィールド機器。

本発明によれば、次のような効果を期待することができる。
（１）一般顧客は、常に必要な情報（パラメータ）のみが公開された状態のフィールド機器を操作・確認することができる。即ち、フィールド機器は不要な情報を開示しない。
（２）機能ブロックのCreate/Delete自体は、ＦＦ通信の仕様で定められている機能であるため、ＤＤファイルはその機能をサポートしたファイルを１つ用意すればよい。
（３）従来技術のようにユーザに応じて複数のファイルを用意する必要はないため、開発工数削減、ファイル管理が容易になる。

本発明を適用したＦＦ通信型フィールド機器の内部構造の実施例を示す機能ブロック図である。 ＤＤファイルを利用して機種Ａ´のフィールド機器にアクセスした場合の、本発明によるパラメータ表示例を示す機能ブロック図である。 ＤＤファイルを利用して機種Ａ´にアクセスした場合の、本発明によるパラメータ表示の他の例を示す機能ブロック図である。 機能ブロックＭをCreateする手順を示すフローチャートである。 機能ブロックＭをCreateした場合の機器の内部処理流れを示すフローチャートである。 機能ブロックＭをDeleteする手順を示すフローチャートである。 機能ブロックＭをDeleteした場合の機器の内部処理流れを示すフローチャートである。 一般的なＦＦ通信型フィールド機器の接続例を示す機能ブロック図である。 一般的なＦＦ通信型フィールド機器の内部構造の例を示す機能ブロック図である。 ＤＤファイルの種別を例示する機能ブロック図である。 一般顧客用ＤＤファイルを利用して機種Ａのフィールド機器にアクセスした場合の、パラメータ表示例を示す機能ブロック図である。 サービスメンテナンス・工場調整用ＤＤファイルを利用して機種Ａのフィールド機器にアクセスした場合の、パラメータ表示例を示す機能ブロック図である。

以下本発明を、図面を用いて詳細に説明する。図１は、本発明を適用したＦＦ通信型フィールド機器（機種Ａ´）の内部構造の実施例を示す機能ブロック図である。図９で説明した従来構成と同一要素には同一符号を付して説明を省略する。

図９で示した従来の機種Ａの構成要素に対して、本発明が適用された機種Ａ´に追加される要素は、機能ブロック仮想デバイス２０内に生成されたメンテナンスブロック（機能ブロックＭ）１００の構成である。

ＦＦ通信の仕様では、ある機能ブロックを必要時のみ表示させるという、ブロックインスタンシェーション（Block Instantiation、以下ＢＩ）機能が存在する。これは、ユーザが機能ブロックの表示・非表示を決定する専用パラメータを操作し、必要な機能ブロックを必要な時だけCreateしてその機能ブロックに存在するパラメータを表示させ、逆に不要な機能ブロックについてはDeleteしてパラメータを含めたブロックごと非表示するという機能である。

以下、本発明が適用されたフィールド機器の機能を説明する。図１に示すように、サービス・メンテナンス用のパラメータや工場調整用のパラメータを１つあるいは複数のメンテナンスブロック（以下、機能ブロックＭ）１００としてまとめて生成し、保有する。

図２は、ＤＤファイル２００を利用して機種Ａ´のフィールド機器にアクセスした場合の、本発明によるパラメータ表示例を示す機能ブロック図であり、ＢＩ機能はDeleteが指令されている。従って、機能ブロックＭは非表示状態であり、サービス・メンテナンス用のパラメータや工場調整用のパラメータは表示されない。

図３は、ＤＤファイル２００を利用して機種Ａ´のフィールド機器にアクセスした場合の、他の表示例を示す機能ブロック図であり、ＢＩ機能はCreateが指令されている。従って、機能ブロックＭは表示状態であり、サービス・メンテナンス用のパラメータや工場調整用のパラメータは表示されている。

容易にこの機能ブロックＭがCreateされてしまわないように、Createの条件としてあるキー情報の設定が有効である。例えば、キー情報を、サービス・メンテナンス用のパラメータや工場調整用のパラメータ以外のパラメータ（図示の例では、トランスデューサブロックにパラメータKEY_PARAMを追加）に割当てておき、そのパラメータに特定のキー情報（暗証）を設定した場合のみ機能ブロックＭのCreateを許可する構成とする。

尚、このキー情報は、工場調整を行うユーザやサービス・メンテナンスを行うユーザにのみ提示し、一般顧客には提示しないことで、容易にこの機能ブロックＭがCreateされてしまわないよう、セキュリティを確保することができる。

図４は、機能ブロックＭをCreateする手順を示すフローチャートである。ステップＳ１では機能ブロックＭのCreateを許可するためのキー情報を設定（例えばTB.KEY_PARAMにキー情報を設定）し、ステップＳ２でＦＦ仕様に基づくＢＩ機能により機能ブロックＭをCreateする。

図５は、機能ブロックＭをCreateした場合の機器の内部処理流れを示すフローチャートである。ユーザから機能ブロックＭのCreate指令があった時、ステップＳ１でキー情報設定の有無がチェックされる。キー情報が設定されている場合にはステップＳ２で機能ブロックＭをCreateする。従ってユーザは機能ブロックＭを確認できる。

ステップＳ１のチェックでキー情報が設定されていない場合には、ステップＳ３で機能ブロックＭはDeleteのままを維持する。従ってユーザは機能ブロックＭを確認することができない。

図６は、機能ブロックＭをDeleteする手順を示すフローチャートである。ステップＳ１でＦＦ仕様に基づくＢＩ機能により機能ブロックＭをDeleteする。ステップＳ２では機能ブロックＭのCreateを許可するためのキー情報をクリア（例えばTB.KEY_PARAMにキー情報をクリア）する。

図７は、機能ブロックＭをDeleteした場合の機器の内部処理流れを示すフローチャートである。ユーザから機能ブロックＭのDelete指令があった時、ステップＳ１で、無条件で機能ブロックＭをDeleteする。従って、ユーザは以後機能ブロックＭを確認することができない。

図７に示す通り、機能ブロックＭのDeleteはキー情報が設定されていることを条件とはしていない。そのため、事前にキー情報がクリアされていても機能ブロックＭのDeleteは許可してよいものとする。

また、Delete時に機器内部で自動的にキー情報をクリアしてしまい、ユーザのDelete手順としてキー情報のクリアを不要としても良いものとする。更に、他のDelete手段として、機器のリスタートや電源再起動に伴い、自動的に機能ブロックＭをDeleteし、キー情報をクリアしてよいものとする。

以上説明した実施例では、パラメータ表示手段としてＦＦ規格に準拠するＤＤファイルを用いる構成を示したが、パラメータ表示手段はＤＤファイルに限定されるものではなく、
機能ブロックの夫々が保有するパラメータ値をパラメータ名称と結び付けてユーザに表示する機能を具備する表示手段であれば任意の手段を採用することが可能である。

１０ 管理仮想デバイス
１１ ネットワーク管理部
１２ システム管理部
２０ 機能ブロック仮想デバイス
２１ トランスデューサブロック
２２ 機能ブロック群
２２ａ アナログインプットブロック
２２ｂ ＰＩＤ演算ブロック
２３ リソースブロック
２４ ビューオブジェクト
２５ トレンドオブジェクト
２６ アラートオブジェクト
２７ リンクオブジェクト
１００ メンテナンスブロック（機能ブロックＭ）

Claims (6)

1. 複数の機能ブロックの夫々が保有するパラメータ値を、パラメータ表示手段によりパラメータ名称と結び付けてユーザに表示する機能を具備する、ＦＦ（Foundation Fieldbus）規格に準拠するフィールド機器において、
   前記パラメータの内、サービスメンテナンスや工場調整時用のパラメータをまとめた少なくとも１個のメンテナンスブロックを備え、
   前記パラメータ表示手段によるアクセスと共に、前記ＦＦ規格の仕様であるブロックインスタンシェーション機能により、前記メンテナンスブロックの表示操作と非表示操作とを実行することを特徴とするフィールド機器。
2. 前記ブロックインスタンシェーション機能による前記メンテナンスブロックの表示操作に対し、表示を許可するキー情報の設定を可能としたことを特徴とする請求項１に記載のフィールド機器。
3. 前記ブロックインスタンシェーション機能による前記メンテナンスブロックの非表示操作を実行する場合に、前記キー情報を自動的にクリアすることを特徴とする請求項２に記載のフィールド機器。
4. 前記キー情報設定の有無にかかわらず、前記ブロックインスタンシェーション機能により前記メンテナンスブロックの非表示操作を可能としたことを特徴とする請求項２または３に記載のフィールド機器。
5. 前記フィールド機器のリスタートまたは電源再起動時に、前記ブロックインスタンシェーション機能は、前記メンテナンスブロックを非表示操作することを特徴とする請求項１乃４のいずれかに記載のフィールド機器。
6. 前記パラメータ表示手段は、前記ＦＦ規格に準拠するＤＤ（Device Description）ファイルであることを特徴とする請求項１乃５のいずれかに記載のフィールド機器。

Images