(57)【要約】【課題】設備群の管理に柔軟性を持たせ、一括管理を容易にする。【解決手段】複数のコンピュータシステム１、２、３によって運転・管理・保全される設備・部品群４、５を設備タグ名によって管理する。設備群は、ドメイン・ネーム・サーバ６Ｂによって名前を割り当てる。設備タグ名はバイナリ・コードによる設備の識別コードと、設備群がもつ階層構造の下位から順にドットで区切った可読性の文字列ＯＲＬを組み合わせたリソースレコード構造とする。識別コードと文字列を対応付けたテーブル６Ａを設け、設備群の呼び出しにその文字列または識別コードからテーブルで他方の名を引き出す。  タグ名は、同じバイナリ識別コードに複数の名前付けを許容する。アドレス指定時にアプリケーション種別を指定することで、複数の設備データベースを指定可能とすることを含む。【選択図】  図１
2005141516.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンピュータシステムによって運転・管理・保全される設備群を設備タグ名によって管理する名前管理方法であって、
設備群は、ドメイン・ネーム・サーバによって名前を割り当て、
前記設備タグ名は、バイナリ・コードによる設備の識別コードと、設備群がもつ階層構造の下位から順にドットで区切った可読性の文字列を組み合わせたリソースレコード構造とし、
前記識別コードと前記文字列を対応付けたテーブルを設け、
設備群の呼び出しにその文字列または識別コードから前記テーブルで他方の名を引き出すことを特徴とする設備群の名前管理方法。
【請求項２】
前記タグ名は、同じバイナリ識別コードに複数の名前付けを許容するリソースレコード構造としたことを特徴とする請求項１に記載の設備群の名前管理方法。
【請求項３】
前記リソースレコードは、アドレス指定時にアプリケーション種別を指定することで、複数の設備データベースを指定できるようにしたことを特徴とする請求項１または２に記載の設備群の名前管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プラントの設備群を複数のコンピュータシステムによって運転・管理・保全する方法に係り、特に名前タグにより設備群を管理するための名前管理方法に関する。
【背景技術】
【０００２】
変電所や石油精製所などのプラントは、健全で効率よい稼働・運転状態を維持するためには種々のコンピュータシステムが導入されている。例えば、図３にシステム構成例を示すように、分散制御システム層にはプラント運転のための監視制御システムが、業務管理層には基幹業務との連携や業務の運行を支援するための業務管理システム、フィールド管理層の各設備・機器の保守を支援する設備維持管理システムや保守保全支援システムが導入されている。
【０００３】
これら各コンピュータシステムは、互いにネットワーク接続されているが、独立して別々に機能しており、物理的に同じプラント設備や機器に対しての情報管理を行っているという共通項があるにもかかわらず、共通のデータベースを利用したり、インタフェースを共有化することができないでいる。
【０００４】
一方、流通分野では、全ての物（オブジェクト）に識別可能なＩＤコードを割り振り、そのＩＤコードとデータベースを、インターネットのＤＮＳ（ドメインネームサーバ）と同じ仕組みで、動的に連結するメカニズム（ＯＮＳ：オブジェクト・ネーミング・サービス・システム）が提案されてきている（例えば、非特許文献１参照）。
【非特許文献１】The Object Naming Service(ONS),summary from the MIT Auto-ID Laboratory，ＵＲＬ（http://auto-id.mit.edu/research/naming.html）：検索日２００３年１０月１日
【発明の開示】
【発明が解決しようとする課題】
【０００５】
前記のように、独立して別々に機能する複数のコンピュータシステムが導入されたプラントでは、物理的に同じ設備や機器に対しての情報管理を行っているという共通項があるにもかかわらず、共通のデータベースを利用したり、インタフェースを共有化することができないでいる。
【０００６】
これは、導入するコンピュータシステムの機能の違いにより、対象設備・機器そのものやその集合の境界が異なるため、同一の構造で捉えることが出来ないことが原因となっている。
【０００７】
プラントを運転する立場での、設備のカテゴリーが、保全や運用や経費の枠組みで見ると違ったものに分類しなければならないことがよくあるが、こういった複雑さを現状のデータベースの枠組みでは自由に対応が出来ない。
【０００８】
また、監視制御システムではあまり問題にならないが、その他のシステムでは、組織や運用の変更で、始終データベースの枠組みを変更せねばならず、これがシステム導入の障害、システム維持の障害となっている。
【０００９】
また、単純に、前記の非特許文献１で挙げられるＯＮＳを適用し、対象となる設備に物理的にユニークな識別コードをふり、そのコードと設備の情報が格納されているデータベースの位置を連結する仕組みを導入しても、次のような２点の問題がある。
【００１０】
・ＯＮＳの識別コードは４８ビットまたは９６ビットのバイナリコードで、利用者にとって可読性がない（コードから識別コードの意味が読み取れない）ため、人間による識別子の入力が必要な場面や、検索場面で利用できない。
【００１１】
・ＯＮＳでは情報が格納されているデータベースを１つしか指定できない（複数の指定は出来てもデータベースの冗長性を高めるために用いられる）。前記の各システムが搭載するアプリケーション群は、それぞれの機能目的により構造が大きく異なるため、１つに集約するのは殆どできない。
【００１２】
本発明の目的は、上記までの課題を解決した設備群の名前管理方法を提供することにある。
【課題を解決するための手段】
【００１３】
本発明は、前記の課題を解決するため、以下の名前管理方法とする。
【００１４】
・従来のバイナリ・コードによる設備の識別コードとは別に、インターネットのＵＲＬ（ユニフォーム・リソース・ロケータ）に似た名前の付け方を、設備の識別コード（タグ名）に採用する。名前の付け方は、管理対象となる設備の名前をＵＲＬのように下位から順にドット（ピリオド）で区切り表現する。
【００１５】
・バイナリ識別コードとタグ名の対応を取るために、物理ＩＤネームサーバを設ける。物理ＩＤネームサーバは内部にバイナリの物理ＩＤコードを１６進標記でテキスト化したものとタグ名との対応テーブルを持ち、バイナリ識別コードとタグ名の逆引き機能も持つようにする。
【００１６】
・同じバイナリ識別コードに複数のタグ名をつけることを可能とする。
【００１７】
・アドレス指定時のリソースレコード（ＲＲ）の書式は、アプリケーション種別を指定することで、複数の設備データベースを指定できるようにする。
【００１８】
以上のことから、本発明は以下の方法を特徴とする。
【００１９】
（１）複数のコンピュータシステムによって運転・管理・保全される設備群を設備タグ名によって管理する名前管理方法であって、
設備群は、ドメイン・ネーム・サーバによって名前を割り当て、
前記設備タグ名は、バイナリ・コードによる設備の識別コードと、設備群がもつ階層構造の下位から順にドットで区切った可読性の文字列を組み合わせたリソースレコード構造とし、
前記識別コードと前記文字列を対応付けたテーブルを設け、
設備群の呼び出しにその文字列または識別コードから前記テーブルで他方の名を引き出すことを特徴とする。
【００２０】
（２）前記タグ名は、同じバイナリ識別コードに複数の名前付けを許容するリソースレコード構造としたことを特徴とする。
【００２１】
（３）前記リソースレコードは、アドレス指定時にアプリケーション種別を指定することで、複数の設備データベースを指定できるようにしたことを特徴とする。
【発明の効果】
【００２２】
以上のとおり、本発明によれば、以下の効果がある。
【００２３】
・階層的なタグ名（ＯＲＬ）から設備の置かれている環境が連想できる。
【００２４】
・用途に応じて複数の名前付けを許すため、運用や組織の変更や移動に柔軟に対応ができる。
【００２５】
・情報が格納されているシステムやアプリケーションの場所をＥＮＳサーバで管理すれば、格納場所の移動が簡単に情報が移動するシステムでもシステムメンテナンス時などに一時切替をすることが容易となる。
【００２６】
・同じ名前に複数のシステムやアプリケーションを設定できるため、データベースの冗長化が容易になる。つまり、システムダウン時の代替や過負荷対応が容易に実現できる。
【００２７】
・システム間のデータ共有が容易になる。
【００２８】
・ＥＮＳサーバはＤＮＳと同じ仕組みを使うことで、既存のプログラムの利用が可能となる。
【発明を実施するための最良の形態】
【００２９】
図１は、本実施形態になる設備群の名前管理方法の模式図である。同図に示すシステムは、コンピュータシステム１、２、３がネットワーク接続されたものを示し、各システム内では多数の設備４がネットワーク接続され、各設備４には多数の部品群５で構成されているとする。
【００３０】
このようなシステムにおいて、システム、設備、部品群を個々に特定するための設備タグは、従来のバイナリ・コードによる設備の識別コードとは別に、インターネットのＵＲＬ（ユニフォーム・リソース・ロケータ）に似た名前の付け方を、設備の識別コードに採用する。
【００３１】
一般的に、設備はサイト→システム→設備→構成部品というような階層構造をもつ。そこで、管理対象となる設備の名前をＵＲＬのように下位から順にドット（ピリオド）で区切り表現する。これを、ＯＲＬ（オブジェクト・リソース・ロケータ）と呼ぶ。
【００３２】
例えば、設備の名前として「油温計Ａ．エンジン．自家発電１号機．管理棟地階．〇×制御所．△◇営業地区」を定める。
【００３３】
次に、バイナリ識別コードとの対応を取るためにＰＮＳ（物理ＩＤネームサーバと仮称する）６を設ける。ＰＮＳ６は内部にバイナリの物理ＩＤコードを１６進標記でテキスト化したものと、上記ＯＲＬとの対応テーブル６Ａを持つ。書式は、例えば、＜ＯＲＬ＞＜ａｐｐｌｉｃａｔｉｏｎ＞＜物理ＩＤ＞とする。
【００３４】
ＰＮＳ６は、上記の対応テーブル６Ａをもつことで、逆引きの機能も持たせ、物理ＩＤ→ＯＲＬ、またはＯＲＬ→物理ＩＤのどちらにも変換が可能とする。なお、同じ物理ＩＤに複数のＯＲＬをつけても構わない。また、ＰＮＳ６は、物理ＩＤコードを利用しないシステムでない場合にも適用できる。
【００３５】
次に、ＰＮＳ６は、設備タグの名前を決定するＤＮＳ（ドメイン・ネーム・サーバ）６Ｂを設ける。このＤＮＳ６Ｂは、インターネットで採用されるＤＮＳと同じ仕組みを用いることができる（同じサービスプログラムを用いることができる。）。ただし、ルートは、各ドメインのトップドメインとする。
【００３６】
ＤＮＳ６Ｂは、サーバに各ゾーンでの名前解決用のデータベースを持ち、それは次のようなリソースレコード（ＲＲ）で構成する。
【００３７】
<name><ttl><class><type><data>
name：ドメイン名
ttl：キャッシュの有効期限（秒単位）
class：ＩＮ（インターネットドメイン）
type：レコードの種類（Ａ，ＮＳ，ＭＸ，ＰＴＲ，ＳＯＡなど）、ちなみにＡはアドレス
data:class、type依存の値（例：Ａレコードの場合はＩＰｖ４アドレス、複数のフィールドからなる場合もある）
このＲＲの記述は、例えば、「www.meiden.co.jp 3000 IN A 205.177.140.199」となる。
【００３８】
さらに、目的に応じて複数の設備データベースが指定できるように、アドレス指定時のＲＲの書式を以下のように拡張する。
【００３９】
<name><ttl><IN><A><data><application>
applicationはアプリケーション種別を記述する。アプリケーション種別の指定により、使用するデータベースを振り分けることができる。
【００４０】
アプリケーション種別には、measurment、historical、event、message、maintenance、cost、managementなど任意に定義が可能である。複数の項目を組み合わせて設定することも可能とする。名前解決はＥＮＳサーバ（設備ネームサーバと仮称する）７で対応する。この名前決定の方法はＤＮＳ６Ｂと全く同じ方法を利用する（プログラムも同じ物でよい）。
【００４１】
以上の名前管理方法により、目的に応じて別々に用意したデータベースの所在を簡単な方法で管理することが可能となる。アプリケーションは、他のアプリケーションのデータベースの情報を知りたいときは、この名前サービスから、相手アプリでの対照設備の名称を知り、それを手がかりに、データベースの場所と検索キーを知ることができる。
【００４２】
図２は、本実施形態の実施例を示す。同図では、業務支援システム１０から油温計１１の設備ＩＤ「1D69CB1007」の保全データを保守保全支援システム１２から呼び出して使いたい場合の例を示す。業務支援システム１０は、まず、ＯＮＳ１３に「maintenance.1D69CB1007」を問い合わせ、ＯＮＳ１２から、「油温計．エンジン．自家発電１号機．…」を得る。次いで、業務支援システム１０は、ＥＮＳ（ＰＮＳ）１４に「油温計．エンジン．自家発電１号機．…」を問い合わせ、当該油温計１１の保守保全管理をする保守保全支援システム１２のＩＰアドレス「205.177.140.199」を得、このＩＰアドレスを基に保守保全支援システム１２に油温計１１の保全データを問い合わせる。
【図面の簡単な説明】
【００４３】
【図１】本発明の実施形態を示す名前管理方式の模式図。
【図２】本発明の実施例を示す図。
【図３】システム構成例。
【符号の説明】
【００４４】
１〜３  システム
４  設備
５  部品群
６  ＰＮＳ（物理ＩＤネームサーバ）
７  ＥＮＳ（設備ネームサーバ）
【図１】
2005141516.tif 000003
【図２】
2005141516.tif 000004
【図３】
2005141516.tif 000005