JP2008165683A - 制御機器、そのコントローラおよび制御方法 - Google Patents

Abstract

【課題】コントローラにおいて、プログラムの書き直しを行わなくても制御機器を制御できるようにする。
【解決手段】コントローラ１は、予め制御機器２に類似する機種に共通なドライバを備え、この制御機器２は、自身に類似する機種同士の差異を吸収するためのプロトコルデータ（２３２〜２３４）を備える。そして、コントローラ１は、接続された制御機器２からこのプロトコルデータを受信する。プロトコルデータは、この制御機器２のＢＵＳＹ値、ＴＩＭＥＯＵＴ値、ＳＴＲＯＢＥ値を含むものである。そして、コントローラ１は、このプロトコルデータと、前記した各機種に共通なドライバとを用いて制御機器２との通信を行う。
【選択図】図１

Description

本発明は、制御機器、そのコントローラおよび制御方法に関する。

汎用のＰＣ（Personal Computer）等に接続機器を接続する場合、ＰＣ等にこの接続機器のドライバをインストールしておき、ＰＣ等が、この接続機器が接続されたことを検知すると、この接続機器のドライバを選択し、起動していた（特許文献１参照）。
特開２００６−８５５４２号公報

しかし、産業機器や家電製品等に用いられる組み込みシステムにおいて、コントローラの備える記憶媒体の記憶容量も限られているため、コントローラ側でいくつかのドライバや通信プロトコルをインストールしておき、その中から制御機器（接続機器）のドライバや通信プロトコルを選択することは困難であった。このため、コントローラに制御機器を接続するときには、コントローラがこの制御機器と通信できるように、作業者がこのコントローラのプログラムを書き直し、コンパイルする必要があった。つまり、接続される制御機器が異なれば、その制御機器の仕様にあわせてコントローラのプログラムを変更する必要があった。

そこで、本発明は、前記した課題を解決し、コントローラにおいて、前記したようなプログラムの書き直しを行わなくても制御機器との通信を実現する手段を提供することを目的とする。

前記した課題を解決するため、本発明のコントローラは、予め制御機器に類似する機種に共通なドライバを備え、制御機器は、自身に類似する機種同士の差異を吸収するためのプロトコルデータを備える構成とした。ここで、機種同士の差異を吸収するために必要な情報として、プロトコルデータに、この制御機器において実行する処理のコマンド番号を示した定義情報に加えて、この制御機器の（１）ＢＵＳＹ値、（２）ＴＩＭＥＯＵＴ値、（３）ＳＴＯＲＯＢＥ値を含めるようにした。そして、コントローラは、このプロトコルデータに基づき、ＢＵＳＹ値に示されるインターバルで、制御機器へ制御信号を送信する。また、このコントローラが制御機器へ制御信号を送信した後、プロトコルデータのＴＩＭＥＯＵＴ値に示される時間以上経過しても、この制御機器から、制御信号の応答を受信しなかったとき、この制御機器の異常を検知する。さらに、コントローラは、このプロトコルデータに基づき、ＳＴＲＯＢＥ値に示される制御信号を連続で制御機器へ送信する。これにより、コントローラは、自身のプログラムの書き直しを行わなくても制御機器を制御することができる。

本発明によれば、コントローラにおいて、前記したようなプログラムの書き直しを行わなくても制御機器を制御することができる。

以下、本発明を実施するための最良の形態（以下、実施の形態という）を、図面を参照しながら説明する。図１は、本実施の形態のコントローラと、このコントローラに接続される制御機器（制御対象機器）の構成を例示した図である。

コントローラ１は、接続媒体３経由で、制御機器２との間で信号のやりとりを行い、制御機器２に所定の処理を実行させる。この制御機器２は、例えば、ＩＣカードリーダ等であり、コントローラ１はこのＩＣカードリーダのコントローラである。この制御機器２は、コントローラ１からの制御信号に基づき、自身が読み取ったＩＣカードの情報（ＩＣタグの情報）をコントローラ１へ送信したり、ＬＥＤ（Light Emitting Diode）ランプを点灯させたり、ブザーを鳴動させたりする。なお、制御機器２は、コントローラ１からの制御を受けて動作する機器であれば、インターホンや宅配ロッカー等であってもよい。また、接続媒体３は、コントローラ１と制御機器２との間で送受信される信号を伝送する媒体であり、ＲＳ４８５等のケーブルが用いられる。なお、コントローラ１には複数の制御機器２が接続されていてもよい。

ここで、コントローラ１および制御機器２の概要に説明する。

コントローラ１は、予め制御機器２に類似する機種に共通なドライバ（機器制御ドライバ部１２２参照）を保持する。また、制御機器２は、この類似する機種同士の差異を吸収するためのプロトコルデータ（プロトコルスタック２３１参照）を備える。ここで、コントローラ１は、この制御機器２に接続されると、この制御機器２から、この制御機器２のプロトコルデータを受信する。そして、コントローラ１は、この受信したプロトコルデータと、自身が備えるドライバとを用いて、制御機器２へ制御信号を送信する。つまり、コントローラ１は、制御機器２を制御する。

＜コントローラ＞
次に、コントローラ１を詳細に説明する。コントローラ１は、図１に示すように、入出力部１１と、制御処理部１２と、記憶部１３とを備える。

入出力部１１は、接続媒体３経由で制御機器２との間で信号の送受信を行うためのインタフェースである。

制御処理部１２は、この入出力部１１経由で、制御機器２へ制御信号を送信し、制御機器２に所定の処理を実行させる。この制御処理部１２は、制御機器２からプロトコルデータを受信するプロトコルデータ交換部１２１と、制御機器２を制御する機器制御ドライバ部１２２とを含んで構成される。なお、この制御処理部１２は、ＣＰＵ（Central Processing Unit）によるプログラム実行処理、あるいは前記処理を実行する専用回路により実現される。つまり、制御処理部１２は、ソフトウェア的に実現してもよいし、ハードウェア的に実現してもよい。

プロトコルデータ交換部１２１は、制御機器２からプロトコルデータ（実際には、後記する通信用データ）を受信すると、このデータをプロトコルスタック１３１（後記）として記憶部１３に格納する。つまり、プロトコルデータ交換部１２１は、制御機器２からプロトコルデータのもととなる通信用データを受信すると、このデータをプロトコル記述方式にデコードし、プロトコルスタック１３１として記憶部１３に格納する。ここで、制御機器２から、コントローラ１へ送信される通信用データの詳細は、図２を用いて後記する。

この機器制御ドライバ部１２２は、記憶部１３に記憶された各制御機器２に共通な汎用ドライバ（図示省略）をロードし、プロトコルスタック１３１（類似する機種同士の差異を吸収するためのプロトコルデータ）を用いて、この機器制御ドライバ部１２２が生成した制御信号を制御機器２へ送信する。つまり、機器制御ドライバ部１２２は、汎用ドライバとプロトコルスタック１３１とを用いて制御機器２を制御する。

記憶部１３は、半導体メモリ等により構成され、所定領域にプロトコルスタック１３１を格納する。このプロトコルスタック１３１は、前記したとおり、プロトコルデータ交換部１２１が、制御機器２からプロトコルデータのもととなる通信用データを受信し、このデータをプロトコル記述方式にデコードしたものである。つまり、プロトコルスタック１３１は、制御機器２のプロトコルスタック２３１と同じものである。このプロトコルスタック１３１は、前記したとおり、機器制御ドライバ部１２２が制御機器２を制御するときに用いられる。ここでのプロトコルスタック１３１に含まれるプロトコルデータは、様々なものが考えられるが、本実施の形態では、制御機器ＩＯ処理プロトコルデータ１３２と、ＩＣタグ処理プロトコルデータ１３３と、制御機器初期化処理プロトコルデータ１３４とを含む場合を例に説明する。つまり、制御機器ＩＯ処理プロトコルデータ１３２は、制御機器２の制御機器ＩＯ処理プロトコルデータ２３２と同じデータであり、ＩＣタグ処理プロトコルデータ１３３は、制御機器２のＩＣタグ処理プロトコルデータ２３３と同じデータであり、制御機器初期化処理プロトコルデータ１３４は、制御機器２の制御機器初期化処理プロトコルデータ２３４と同じデータである。プロトコルスタック１３１に含まれるプロコトルデータの詳細は、プロトコルスタック２３１の説明の項で後記する。なお、図示を省略したが、この記憶部１３には、前記した各制御機器２に共通な汎用ドライバ、プロトコル交換部１２１の機能を実現するためのプログラム等が格納されている。

＜制御機器＞
次に、制御機器２を説明する。制御機器２は、図１に示すように、入出力部２１と、制御処理部２２と、記憶部２３とを備える。なお、この制御機器２は、図示を省略しているが、ＩＣカード等のＩＣタグ情報を読み取るＩＣタグ読み取り部や、ＬＥＤランプや、ブザー等を備える。このＬＥＤランプやブザーは、ＩＣタグの認証結果（認証ＯＫ／認証ＮＧ）を表示するためのものである。このサービス処理部２２２は、このコントローラ１からの制御信号を受信すると、これに基づき、読み取ったＩＣタグ情報を送信したり、ＬＥＤランプを点灯（ＯＮ）したり、ブザーを鳴動（ＯＮ）したりする。

入出力部２１は、接続媒体３経由でコントローラ１との間で信号の送受信を行うためのインタフェースである。

制御処理部２２は、この入出力部２１経由で、コントローラ１へプロトコルデータを送信したり、コントローラ１からの制御信号に基づく処理を行ったりする。このような制御処理部２２は、コントローラ１へプロトコルデータを送信するプロトコルデータ交換部２２１と、コントローラ１からの制御信号に基づき各種処理を実行するサービス処理部２２２とを含んで構成される。なお、ここでサービス処理部２２２が行う処理は、例えば、制御機器２の初期化や、読み取ったＩＣタグのタグＩＤの送信、ＬＥＤのＯＮ／ＯＦＦ、ブザーのＯＮ／ＯＦＦ等である。また、この制御処理部２２も、ＣＰＵによるプログラム実行処理、あるいは前記処理を実行する専用回路により実現される。

プロトコルデータ交換部２２１は、プロトコルスタック２３１における各プロトコルデータを、通信用データに変換してコントローラ１へ送信する。そして、このような通信用データを受信したコントローラ１は、前記したとおり、このデータをプロトコル記述方式にデコードし、このデコードしたプロトコルデータに基づき制御機器２を制御する。

ここで、プロトコルデータ交換部２２１が送信する通信用データを、図２を用いて説明する。図２は、図１の制御機器のプロトコルデータ交換部が送信する通信用データを例示した図である。

図２に例示するように、通信用データは、この通信用データのヘッダ情報である通信ＨＥＡＤ４１と、この通信用データの長さ（具体的には、機器状態記述内容４３から通信ＴＡＩＬ４５までの長さ）を示したＬＥＮ４２と、コントローラ１が制御機器２との間で信号のやりとりをするときの処理手順に関する情報である機器状態記述内容４３と、サービス処理の定義情報（詳細は後記）等、実際に制御機器２をドライブするためのデータである通信内容４４と、データ終了コード等を含む通信ＴＡＩＬ４５とを含んで構成される。この機器状態記述内容４３および通信内容４４の詳細は、各プロトコルデータの説明の項で後記する。

図１の説明に戻る。記憶部２３は、半導体メモリ等により構成され、所定領域にプロトコルスタック２３１を格納する。このプロトコルスタック２３１は、前記したとおり、この制御機器２に類似する機種同士の差異を吸収するためのプロトコルデータであり、ここでは例えば、制御機器ＩＯ処理プロトコルデータ２３２と、ＩＣタグ処理プロトコルデータ（サービス処理プロトコルデータ）２３３と、制御機器初期化処理プロトコルデータ２３４と含む。

この制御機器ＩＯ処理プロトコルデータ２３２は、コントローラ１がこの制御機器２におけるＩＯ処理を制御するためのプロトコルデータである。ここでのＩＯ処理は、例えば、ＬＥＤのＯＮ／ＯＦＦやブザーのＯＮ／ＯＦＦ等である。

また、ＩＣタグ処理プロトコルデータ２３３は、コントローラ１が制御機器２において読み取ったＩＣタグ情報を要求するためのプロトコルデータである。

さらに、制御機器初期化処理プロトコルデータ２３４は、コントローラ１が制御機器２へこの制御機器２の初期化を要求するためのプロトコルデータである。

なお、このプロトコルデータはそれぞれ、コントローラ１が制御機器２との間で信号のやりとりをするとき処理手順に関する情報（機器状態記述内容）と、サービス処理の定義情報とを備える。

＜機器状態記述内容＞
ここで、図２を参照しながら、機器状態記述内容を説明する。この機器状態記述内容４３は、例えば、図２の符号２０１に示すような機器状態情報と、それぞれの状態における値（符号５６に示すＢＵＳＹ値、符号５７に示すＴＩＭＥＯＵＴ値、符号５８に示すＳＴＲＯＢＥ値）とを含む。

まず、図２の符号２０１に示す機器状態情報の示す内容を説明する。図２の符号２０１に示す機器状態情報において、コントローラ１は、ＢＵＳＹ値５６に示されるインターバルを満たしているか否かを判断し、満たしていれば通信用データ（制御信号）を送信する状態になる（Ｓ５１）。つまり、コントローラ１は、制御機器２へ制御信号を送信する。このような通信用データ送信後、コントローラ１は、制御機器２からの応答を受信するまで、ＴＩＭＥＯＵＴ値５７に示される時間が経過するのを待つ（Ｓ５２：ＷＡＩＴ）。次に、ＴＩＭＥＯＵＴ値５７で規定した時間経過しても制御機器２からの応答データが無い場合、ＴＩＭＥＯＵＴ状態と判断する（Ｓ５３：ＴＩＭＥＯＵＴ）。一方、ＴＩＭＥＯＵＴ値５７で規定した時間以内に制御機器２から応答データを受信した場合、そのデータを受け取る（Ｓ５４：ＲＥＣＶ）。そして、コントローラ１は、制御機器２からの応答データを受け取ると、シーケンシャル処理において、ＳＴＲＯＢＥ値５８に示される次の制御信号を送信する状態になる（Ｓ５５：ＳＴＲＯＢＥ）。

なお、前記したＢＵＳＹ値５６は、この制御機器２がコントローラ１から制御信号（処理要求）を受信するときに最低限空けなければならないインターバルを示したものである。また、ＴＩＭＥＯＵＴ値５７は、コントローラ１へ制御信号の応答を出力するとき、コントローラ１側でタイムアウトを判断するときの時間を示したものである。さらに、ＳＴＲＯＢＥ値５８は、この制御機器２においてシーケンシャル処理を行うときにコントローラ１から受信する必要がある制御信号の並びを示したものである。

例えば、各プロトコルデータは、機器状態記述内容として、表１に示すようなＢＵＳＹ（値）、ＴＩＭＥＯＵＴ（値）、ＳＴＲＯＢＥ（値）の定義情報を備える。

表１に示す定義情報において、ＢＵＳＹ値は「２００ｍｓ」であり、ＳＴＲＯＢＥ値は「０（シーケンシャルなし）」であり、ＴＩＭＥＯＵＴ値は「２００ｍｓ」であることを示す。

＜サービス処理の定義情報＞
また、サービス処理の定義情報は、制御機器２が実行するサービス処理ごとのコマンド番号（サービス番号）を示した情報等である。例えば、「ＬＥＤ」に関するコマンド番号は「０ｘ３０」というような情報である。

このサービス処理の定義情報を、表２および表３を用いて説明する。
表２は、制御機器ＩＯ処理プロトコルデータ２３２が備えるサービス要求の定義情報を例示したものであり、表３は、制御機器ＩＯ処理プロトコルデータ２３２が備えるサービス応答の定義情報を例示したものである。

例えば、表２に示す定義情報おいて、サービス処理のサービス番号はカラム（Ｃｈａｒ）１桁を用い、この情報の長さ（ＬＥＮ）に関する情報はカラム２桁を用い、要求するサービスの種類に関する情報はカラム１桁を用い、その付加コードは２桁を用いることを示す（以下、表４および表６に例示する定義情報において同じ）。

また、表２に例示する定義情報において、このＩＯ処理サービス要求を示す番号（サービス番号）は「０ｘ４０」であり、ＬＥＮは「０ｘ３０,０ｘ３３」であり、「ＬＥＤ」を示すコマンド番号は「０ｘ３０」であり、「ブザー」を示すコマンド番号は「０ｘ３１」であることを示す。また、「ＯＮ」を示すコマンド番号は「０ｘ３０,０ｘ３０」であり、「ＯＦＦ」を示すコマンド番号は「０ｘ３０,０ｘ３１」であることを示す。例えば、コントローラ１が制御機器２の「ＬＥＤをＯＮにする」というＩＯ処理の制御信号を送信したいときは、サービス番号「０ｘ４０」、サービスの種類としてコマンド番号「０ｘ３０」、付加コードとしてコマンド番号「０ｘ３０,０ｘ３０」をセットした制御信号を送信すればよいことを示す。

また、表３に例示する定義情報において、サービス処理のサービス番号はカラム１桁を用い、この情報の長さ（ＬＥＮ）に関する情報はカラム２桁を用い、応答コードはカラム１桁を用いることを示す（以下、表５および表７に例示する定義情報において同じ）。このＩＯ処理サービス応答を示す番号（サービス番号）は「０ｘ４１」であり、ＬＥＮは「０ｘ３０,０ｘ３１」であり、「処理成功」を示すコマンド番号は「０ｘ３０」であり、「処理エラー」を示すコマンド番号は「０ｘ３１」であることを示す。例えば、コントローラ１が制御機器２から、サービス番号「０ｘ４１」、応答コードとしてコマンド番号「０ｘ３１」がセットされた信号を受信したとき、この制御機器２において「ＩＯ処理のエラー」が発生したと判断できる。

また、ＩＣタグ処理プロトコルデータ２３３および制御機器初期化処理プロトコルデータ２３４も同様に、サービス処理の定義情報を保持する。

表４は、ＩＣタグ処理プロトコルデータ２３３が備えるサービス要求の定義情報を例示したものであり、表５は、ＩＣタグ処理プロトコルデータ２３３が備えるサービス応答の定義情報を例示したものである。

例えば、表４に例示する定義情報において、このＩＣタグ処理のサービス要求を示す番号（サービス番号）は「０ｘ５０」であり、ＬＥＮは「０ｘ３０,０ｘ３３」であり、「ＩＣタグ処理」を示すコマンド番号は「０ｘ３０」であり、その付加コードは「０ｘ３０」であることを示す。例えば、コントローラ１が制御機器２にＩＣタグの読み取り結果を送信させたいときは、サービス番号「０ｘ５０」、サービスの種類としてコマンド番号「０ｘ３０」、付加コードとしてコマンド番号「０ｘ３０」をセットした制御信号を送信すればよいことを示す。

また、表５に例示する定義情報において、このＩＣタグ処理のサービス応答を示す番号（サービス番号）は「０ｘ５１」であり、ＬＥＮは「０ｘ３０,０ｘ３３」であり、「処理成功」を示すコマンド番号は「０ｘ３０」であり、「処理エラー」を示すコマンド番号は「０ｘ３１」であることを示す。さらに、ＩＣタグ情報はカラム１６桁を用い、そのカラムに記載された値がそのままＩＣタグ情報（タグＩＤ）を表すことを示す。例えば、コントローラ１が制御機器２からサービス番号「０ｘ５１」、応答コードとしてコマンド番号「０ｘ３０」、ＩＣタグとして１６桁の記号がセットされた信号を受信したとき、この制御機器２においてタグＩＤの読み取りに成功し、そのタグＩＤは当該カラム１６桁の記号で示されるＩＤであることを知ることができる。

表６は、制御機器初期化処理プロトコルデータ２３４におけるサービス要求の定義情報を例示したものであり、表７は、制御機器初期化処理プロトコルデータ２３４におけるサービス応答の定義情報を例示したものである。

例えば、表６に例示する定義情報において、この制御機器初期化処理のサービス要求を示す番号（サービス番号）は「０ｘ６０」であり、ＬＥＮは「０ｘ３０,０ｘ３３」であり、「ソフトリセット」を示すコマンド番号は「０ｘ３０」であり、「機器リセット」を示すコマンド番号は「０ｘ３１」であることを示す。また、その付加コードは「０ｘ３０」であることを示す。例えば、コントローラ１が制御機器２のソフトリセットを指示したいときは、サービス番号「０ｘ６０」、サービスの種類としてコマンド番号「０ｘ３０」、付加コードとしてコマンド番号「０ｘ３０」をセットした制御信号を送信すればよいことを示す。

また、表７に例示する定義情報において、この制御機器初期化処理のサービス応答を示す番号（サービス番号）は「０ｘ６１」であり、「処理成功」を示すコマンド番号は「０ｘ３０」であり、「処理エラー」を示すコマンド番号は「０ｘ３１」であることを示す。例えば、コントローラ１が制御機器２からサービス番号「０ｘ６１」、応答コードとしてコマンド番号「０ｘ３０」、付加コードとしてコマンド番号「０ｘ３０」がセットされた信号を受信したとき、この制御機器２におけるソフトリセットが成功したと判断できる。

前記したプロトコルデータ交換部２２１は、このような各プロトコルデータの情報をもとに通信用データ（図２参照）を作成し、コントローラ１へ送信する。このような通信用データを受信したコントローラ１は、この通信用データをプロトコルデータとしてデコードし、このデコードしたプロトコルデータにより、制御機器２との信号の送受信や、この制御機器２に対する制御を実行できるようになる。

＜動作説明＞
次に、図１および図２を参照しつつ、図３を用いて、図１のコントローラ１および制御機器２の動作を説明する。図３（ａ）は、図１のコントローラが制御機器から各プロトコルデータを受信する手順を示したフローチャートであり、（ｂ）は、図１の制御機器がコントローラへプロトコルデータを送信する手順を示したフローチャートである。

まず、コントローラ１は、制御機器２からの接続イベントの受信を待ち（Ｓ３０１）、接続イベントを受信すると（Ｓ３０１のＹｅｓ）、プロトコルデータ交換部１２１は記憶部１３に、この制御機器２のプロトコルスタック１３１があるか否かを判断する（Ｓ３０２）。ここで、既に記憶部１３にプロトコルスタック１３１がある場合（Ｓ３０２のＹｅｓ）、処理を終了する。

一方、記憶部１３にプロトコルスタック１３１がない場合（Ｓ３０２のＮｏ）、プロトコルデータ交換部１２１は、制御機器２へプロトコルスタックがない旨を通知する（Ｓ３０３）。そして、プロトコルデータ交換部１２１は、制御機器２からのプロトコルデータの受信を待ち（Ｓ３０４）、制御機器２からプロトコルデータ（つまり、プロトコルデータの元となる通信用データ）を受信すると（Ｓ３０４のＹｅｓ）、このプロトコルデータを記憶部１３に記憶する。そして、機器制御ドライバ部１２２は、このプロトコルデータに基づき、制御機器２へ制御信号を送信する（Ｓ３０５）。

つまり、各機種に共通なドライバと、制御機器２から受信したプロトコルデータとに基づいて、この制御機器２への制御信号を送信する。例えば、受信したプロトコルデータが制御機器ＩＯ処理プロトコルデータ１３２であれば、機器制御ドライバ部１２２は、制御機器２へＬＥＤをＯＮにさせる制御信号や、ブザーをＯＮにさせる制御信号を送信する。そして、機器制御ドライバ部１２２において、この制御機器２における処理成功の信号（処理成功メッセージ）を受信したとき（Ｓ３０６のＹｅｓ）、この制御機器２からの次のプロトコルデータの受信を待つ（Ｓ３０７）。そして、Ｓ３０４へ戻る。

つまり、コントローラ１は、制御機器２からプロトコルデータを受信すると、このプロトコルデータをもとに制御機器２を正常に制御できるか確認する。そして、制御機器２から処理成功の信号を受信したとき、この制御機器２から次のプロトコルデータが送信されるのを待つ。このようにして、コントローラ１は制御機器２から、制御機器ＩＯ処理プロトコルデータ１３２に続いて、ＩＣタグ処理プロトコルデータ１３３および制御機器初期化処理プロトコルデータ１３４を受信し、プロトコルスタック１３１を形成する。

なお、Ｓ３０４において、プロトコルデータ交換部１２１が所定時間経過しても制御機器２からプロトコルデータを受信できなかったとき（Ｓ３０４のＮｏ）、および、Ｓ３０６において制御機器２から処理成功の信号を受信できなかったとき（Ｓ３０６のＮｏ）、処理を終了する。

このようにすることで、コントローラ１は、制御機器２から受け取った各プロトコルデータの検証を行いながら、プロトコルデータを受信できる。

次に、図３（ｂ）を用いて、制御機器２がコントローラ１へ各プロトコルデータを送信する手順を説明する。

まず、制御機器２がコントローラ１に接続されるのを待ち（Ｓ３０８）、制御機器２がコントローラ１に接続すると（Ｓ３０８のＹｅｓ）、プロトコルデータ交換部２２１は、コントローラ１へ接続イベントを送信する（Ｓ３０９）。ここで送信する接続イベントは、例えば、この制御機器２の識別情報等を含むものである。

そして、制御機器２は、コントローラ１からこの制御機器２のプロトコルスタック１３１がない旨の通知の受信を待ち（Ｓ３１０）、制御機器２がコントローラ１からこの制御機器２のプロトコルスタック１３１がない旨の通知を受信すると（Ｓ３１０のＹｅｓ）、記憶部２３のプロトコルスタック２３１から、プロトコルデータを選択して読み出し、この読み出したプロトコルデータをコントローラ１へ送信する（Ｓ３１１）。

次に、サービス処理部２２２は、Ｓ３１１で送信したプロトコルデータの制御信号の受信を待ち（Ｓ３１２）、Ｓ３１１で送信したプロトコルデータの制御信号を受信すると（Ｓ３１２のＹｅｓ）、この制御信号に基づく処理を行う。そして、サービス処理部２２２は、この制御信号に基づく処理結果である応答信号を送信する（Ｓ３１３）。

例えば、サービス処理部２２２がコントローラ１へ制御機器ＩＯ処理プロトコルデータ２３２を送信した後、コントローラ１から、制御機器２のＬＥＤをＯＮにさせる制御信号や、ブザーをＯＮにさせる制御信号を受信したとき、サービス処理部２２２において、ＬＥＤをＯＮにしたり、ブザーをＯＮにしたりする。そして、サービス処理部２２２は、その処理結果である応答信号をコントローラ１へ送信する。例えば、ＬＥＤや、ブザーをＯＮにした場合、制御機器ＩＯ処理プロトコルデータ２３２に基づき応答信号を送信する。

そして、プロトコルデータ交換部２２１は、プロトコルスタック２３１のすべてのプロトコルデータを送信したか否かを判断し（Ｓ３１４）、すべてのプロトコルデータを送信したとき（Ｓ３１４のＹｅｓ）、処理を終了する。一方、まだ送信していないプロトコルデータがあるときには（Ｓ３１４のＮｏ）、Ｓ３１１へ戻り、残りのプロトコルデータを送信する。

このようにすることで、コントローラ１は、制御機器２のプロトコルスタック２３１のすべてのプロトコルデータを受信し、この制御機器２のプロトコルスタック１３１を作成することができる。

なお、制御機器２がコントローラ１へプロトコルデータを送信する手順は、例えば、まず、制御機器初期化処理プロトコルデータ２３４を送信し、その後、ＩＣタグ処理プロトコルデータ２３３または制御機器ＩＯ処理プロトコルデータ２３２を送信するのが好ましい。このようにするのは、まず、制御機器２の初期化に成功しないと、その他の処理の検証を行うことができないからである。

次に、適宜図１ないし図３を参照しつつ、図４ないし図６を用いて、前記した手順によりプロトコルスタック１３１を作成したコントローラ１が、このプロトコルスタック１３１により制御機器２を制御する手順を説明する。図４ないし図６は、図１のコントローラが制御機器を制御する手順を示したシーケンス図である。

なお、以下の説明において、コントローラ１は、制御機器２の初期化後、この制御機器２から所定時間ごとにこの制御機器２で読み取ったタグＩＤの取得要求を行うものとする。つまり、制御機器２がＩＣカード等からタグＩＤを読み取った後、コントローラ１からタグＩＤの取得要求を受信すると、制御機器２はこれに対する応答として、読み取ったタグＩＤをセットした信号を送信する。なお、制御機器２がコントローラ１からの取得要求を受信したとき、この制御機器２において読み取ったタグＩＤが無い場合（つまり、制御機器２へ未送信のタグＩＤが無い場合）、制御機器２はタグＩＤについて空の状態で信号を送信するものとする。

制御機器２の初期化がまだ終了していない場合（Ｓ４０１のＮｏ）、コントローラ１の機器制御ドライバ部１２２は、制御機器初期化処理プロトコルデータ１３４を参照して、以下の処理を行う。

すなわち、機器制御ドライバ部１２２は、前回の初期化要求送信から所定時間（制御機器初期化処理プロトコルデータ１３４に示されるＢＵＳＹ値）経過しているか否かを判断する（Ｓ４０２）。ここで、所定時間経過した場合（Ｓ４０２のＹｅｓ）、この制御機器の初期化要求（初期化を要求する制御信号）を制御機器へ送信する（Ｓ４０３）。一方、まだ前回の初期化要求送信から所定時間経過していなければ（Ｓ４０２のＮｏ）、所定時間経過するのを待つ。なお、機器制御ドライバ部１２２が送信する初期化要求は、例えば、制御機器２のソフトリセットや機器リセットを指示するサービス番号およびコマンド番号（表６等参照）を含む制御信号である。

一方、既に制御機器２の初期化が終了していれば（Ｓ４０１のＹｅｓ）、図５のＳ５０１へ進む。Ｓ５０１については後記する。

Ｓ４０３においてコントローラ１から送信された初期化要求を受信した制御機器２は、サービス処理部２２２において初期化処理を行う（Ｓ４０４）。そして、その初期化処理が成功したとき（Ｓ４０５のＹｅｓ）、サービス処理部２２２は、この初期化処理の処理成功メッセージをコントローラ１へ送信する（Ｓ４０７）。一方、サービス処理部２２２は初期化処理に失敗したとき（Ｓ４０５のＮｏ）、処理エラーメッセージをコントローラ１へ送信する（Ｓ４０６）。ここで送信するメッセージは、例えば、表７に例示したようなサービス番号やコマンド番号（応答コード）を含む信号である。

コントローラ１の機器制御ドライバ部１２２は、Ｓ４０３の初期化要求送信後、タイムアウト時間（制御機器初期化処理プロトコルデータ１３４に示されるＴＩＭＥＯＵＴ値）内に、この初期化処理の処理成功メッセージを受信したとき（Ｓ４０８のＹｅｓ）、Ｓ５０１へ進む。なお、ここで受信したメッセージ（信号）が、この初期化処理の処理成功メッセージであるか否かは、制御機器初期化処理プロトコルデータ１３４におけるサービス番号や応答コードの定義情報（表７参照）を参照して判断する。

一方、機器制御ドライバ部１２２においてタイムアウト時間内に処理成功メッセージを受信できなかったとき（Ｓ４０８のＮｏ）、制御処理部１２は、この制御機器２の初期化に失敗し、故障している可能性が高いことを示すフラグを立て（Ｓ４０９：故障判断処理）、処理を終了する。

図５の説明に移る。次に、コントローラ１の機器制御ドライバ部１２２は、ＩＣタグ処理プロトコルデータ１３３を参照して、以下の処理を行う。すなわち、機器制御ドライバ部１２２は、前回のＩＣタグ処理要求送信から所定時間（ＩＣタグ処理プロトコルデータ１３３に示されるＢＵＳＹ値）経過しているか否かを判断する（Ｓ５０１）。ここで、所定時間経過していれば（Ｓ５０１のＹｅｓ）、この制御機器のＩＣタグ処理要求（制御機器２で読み取ったＩＣタグのタグＩＤを要求する制御信号）を制御機器へ送信する（Ｓ５０２）。一方、まだ前回のＩＣタグ処理要求送信から所定時間経過していなければ（Ｓ５０１のＮｏ）、所定時間経過するのを待つ。ここで、機器制御ドライバ部１２２が送信するＩＣタグ処理要求は、制御機器２のＩＣタグ処理を指示するサービス番号およびコマンド番号（表４等参照）を含む制御信号である。

このようなＩＣタグ処理要求を受信した制御機器２は、サービス処理部２２２においてＩＣタグ処理を行う（Ｓ５０３）。例えば、読み取ったＩＣタグのタグＩＤをコントローラ１へ送信する処理を行う。そして、そのＩＣタグ処理が成功したとき（Ｓ５０４のＹｅｓ）、サービス処理部２２２は、このＩＣタグ処理の処理成功メッセージと、処理結果データ（読み取ったタグＩＤがあれば、そのタグＩＤ）をコントローラ１へ送信する（Ｓ５０６）。一方、サービス処理部２２２はＩＣタグ処理に失敗したとき（Ｓ５０４のＮｏ）、処理エラーメッセージをコントローラ１へ送信する（Ｓ５０５）。ここで送信するメッセージは、例えば、表５に例示したようなサービス番号やコマンド番号（応答コード）、タグＩＤ等を含む信号である。

コントローラ１の機器制御ドライバ部１２２は、前記した初期化処理の場合と同様、Ｓ５０２におけるＩＣタグ処理要求送信後、タイムアウト時間内にこのＩＣタグ処理の処理成功メッセージを受信したか否かを判断する（Ｓ５０７）。つまり、機器制御ドライバ部１２２は、ＩＣタグ処理プロトコルデータ１３３に示されるＴＩＭＥＯＵＴ値の時間内に、処理成功メッセージを受信したか否かを判断し、処理成功メッセージを受信できたとき（Ｓ５０７のＹｅｓ）、図６のＳ６０１へ進む。なお、ここで受信したメッセージ（信号）が、このＩＣタグ処理の処理成功メッセージであるか否かは、前記した初期化処理の場合と同様、ＩＣタグ処理プロトコルデータ１３３におけるサービス番号や応答コードの定義情報（表５参照）を参照して判断する。また、ここで処理結果データとしてタグＩＤを受信したときは、このタグＩＤを記憶部１３のＲＡＭ等に記憶しておく。一方、制御機器２は、読み取ったタグＩＤが特になければ、タグＩＤのカラムには特に情報をセットせずにコントローラ１へ信号を送信する。

一方、Ｓ５０７において、機器制御ドライバ部１２２は、タイムアウト時間内に、処理成功メッセージを受信できなかったとき（Ｓ５０７のＮｏ）、制御処理部１２は、前記したＳ４０７と同様、この制御機器２においてＩＣタグの読み取り処理ができない状態であり、故障している可能性が高いことを示すフラグを立てる（Ｓ５０８：故障判断処理）。そして、処理を終了する。

Ｓ５０７のＹｅｓの後、コントローラ１の機器制御ドライバ部１２２は、制御機器ＩＯ処理プロトコルデータ１３２を参照して、以下の処理を行う。

なお、以下の説明において、コントローラ１がＳ５０７で受信した処理結果データには、タグＩＤが含まれているものとする。そして、コントローラ１はそのタグＩＤをもとに認証処理を行い、認証ＯＫであれば制御機器２のＬＥＤをＯＮ、ブザーはＯＦＦとし、認証ＮＧであれば制御機器２のＬＥＤをＯＦＦ、ブザーはＯＦＦとする制御信号を送信する場合を例に説明する。

図６のＳ６０１において、コントローラ１の制御処理部１２は、受信した処理結果データ（タグＩＤ）をもとに認証処理を実行する（Ｓ６０１）。ここで、認証ＯＫだった場合（Ｓ６０２のＹｅｓ）、機器制御ドライバ部１２２は、前回のＩＯ処理要求送信から所定時間（制御機器ＩＯ処理プロトコルデータ１３２に示されるＢＵＳＹ値）経過しているか否かを判断する（Ｓ６０５）。ここで、所定時間経過していれば（Ｓ６０５のＹｅｓ）、機器制御ドライバ部１２２は、この制御機器のＩＯ処理要求（ＩＯ処理を要求する制御信号）を制御機器へ送信する（Ｓ６０６）。一方、まだ所定時間経過していなければ（Ｓ６０５のＮｏ）、機器制御ドライバ部１２２はＩＯ処理要求を送信しない。なお、ここで機器制御ドライバ部１２２が送信するＩＯ処理要求は、例えば、制御機器２のＬＥＤのＯＮやブザーのＯＦＦを指示するサービス番号およびコマンド番号（表２等参照）を含む制御信号である。

一方、Ｓ６０２において認証エラーが発生した場合（Ｓ６０２のＮｏ）も、機器制御ドライバ部１２２は、前回のＩＯ処理要求送信から所定時間（制御機器ＩＯ処理プロトコルデータ１３２に示されるＢＵＳＹ値）経過していれば（Ｓ６０３のＹｅｓ）、この制御機器のＩＯ処理要求（ＩＯ処理を要求する制御信号）を制御機器へ送信する（Ｓ６０４）。一方、まだ所定時間経過していなければ（Ｓ６０３のＮｏ）、機器制御ドライバ部１２２はＩＯ処理要求を送信せず、前回のＩＯ処理要求送信から所定時間経過するのを待つ。

ここで、機器制御ドライバ部１２２が送信するＩＯ処理要求は、制御機器２のＬＥＤのＯＦＦやブザーのＯＮを指示するサービス番号およびコマンド番号（表２参照）を含む制御信号である。

このようなＩＯ処理要求を受信した制御機器２は、サービス処理部２２２においてＩＯ処理を行う（Ｓ６０７）。そして、そのＩＯ処理が成功したとき（Ｓ６０８のＹｅｓ）、サービス処理部２２２は、このＩＯ処理の処理成功メッセージをコントローラ１へ送信する（Ｓ６１０）。一方、サービス処理部２２２はＩＯ処理に失敗したとき（Ｓ６０８のＮｏ）、処理エラーメッセージをコントローラ１へ送信する（Ｓ６０９）。ここで送信するメッセージは、例えば、表３に例示したようなサービス番号やコマンド番号（応答コード）を含む信号である。

コントローラ１の機器制御ドライバ部１２２は、Ｓ６０４またはＳ６０６におけるＩＯ処理要求送信後、タイムアウト時間（制御機器ＩＯ処理プロトコルデータ１３２に示されるＴＩＭＥＯＵＴ値）内に、このＩＯ処理成功メッセージを受信したとき（Ｓ６１１のＹｅｓ）、図５のＳ５０１へ戻る。なお、ここで受信したメッセージ（信号）が、このＩＯ処理の処理成功メッセージであるか否かは、前記した初期化やＩＣタグ処理の場合と同様、制御機器ＩＯ処理プロトコルデータ１３２におけるサービス番号や応答コードの定義情報（表２参照）を参照して判断する。

一方、機器制御ドライバ部１２２においてタイムアウト時間内に処理成功メッセージを受信できなかったとき（Ｓ６１１のＮｏ）、制御処理部１２は、この制御機器２は故障している可能性が高いことを示すフラグを立て（Ｓ６１２：故障判断処理）、処理を終了する。

このように、コントローラ１は制御機器２から送信されたプロトコルスタック２３１（つまり、プロトコルスタック１３１）に基づき、制御機器２との間で信号送受信ができるようになる。特に、コントローラ１は、制御機器２のプロトコルデータとして、この制御機器２に固有のＢＵＳＹ値やＴＩＭＥＯＵＴ値等を送信するので、コントローラ１はこの制御機器２へサービス要求（制御信号）を送信するとき、この制御機器２をＢＵＳＹ状態させない送信間隔で送信することができる。また、コントローラ１において、この制御機器２が正常に動作していることの確認（ヘルスチェック）をすることができ、大変便利である。

なお、Ｓ４０９、Ｓ５０８およびＳ６１２において、コントローラ１がこの制御機器２は故障している可能性が高いことを示す判断をしたとき、例えば、コントローラ１は、この制御機器２に故障が発生していることを示す信号を入出力部１１経由で出力する。つまり、コントローラ１による制御機器２のヘルスチェック結果を表示部等に出力する。このようにすることで、コントローラ１へこの制御機器２を接続する作業を行う作業者は、この制御機器２において故障が発生しているか否かをすぐに確認でき、大変便利である。

なお、図４ないし図６において、説明を省略したが、コントローラ１が制御機器２から受信するプロトコルデータにＳＴＲＯＢＥ値が設定されていれば、コントローラ１はこのＳＴＯＲＢＥ値にしたがって制御信号を送信し、制御機器２にシーケンシャル処理を行わせる。

本実施の形態に係るコントローラ１および制御機器２は前記したような処理を実行させるプログラムによって実現することができ、そのプログラムをコンピュータによる読み取り可能な記憶媒体（ＣＤ−ＲＯＭ等）に記憶して提供することが可能である。また、そのプログラムを、インターネット等のネットワークを通して提供することも可能である。

本実施の形態のコントローラと、このコントローラに接続される制御機器の構成を例示した図である。 図１の制御機器のプロトコルデータ交換部が送信する通信用データを例示した図である。 （ａ）は、図１のコントローラが制御機器からプロトコルデータを受信する手順を示したフローチャートであり、（ｂ）は、図１の制御機器がコントローラへプロトコルデータを送信する手順を示したフローチャートである。 図１のコントローラが制御機器を制御する手順を示したシーケンス図である。 図１のコントローラが制御機器を制御する手順を示したシーケンス図である。 図１のコントローラが制御機器を制御する手順を示したシーケンス図である。

符号の説明

１ コントローラ
２ 制御機器
３ 接続媒体
１１,２１ 入出力部
１２,２２ 制御処理部
１３,２３ 記憶部
１２１,２２１ プロトコルデータ交換部
１２２ 機器制御ドライバ部
１３１,２３１ プロトコルスタック
１３２,２３２ 制御機器ＩＯ処理プロトコルデータ
１３３,３３３ ＩＣタグ処理プロトコルデータ
１３４,２３４ 制御機器初期化処理プロトコルデータ
２２２ サービス処理部

Claims (11)

1. 自身の制御機器に類似する機種との差異となるプロトコルデータとして、（１）コントローラからの制御信号を受信するときのインターバルを示したＢＵＳＹ値および（２）前記自身の制御機器において実行する処理のコマンド番号を示した定義情報を記憶する記憶部と、前記コントローラから、前記定義情報に示されるコマンド番号を含む制御信号を受信し、この制御信号に応じて処理を実行し、その処理の実行結果を前記制御信号の応答として送信するサービス処理部とを備える制御機器。
2. 前記プロトコルデータは、
   前記コントローラが、前記制御機器からの制御信号の応答のタイムアウトを検知するための時間を示したＴＩＭＥＯＵＴ値をさらに含むことを特徴とする請求項１に記載の制御機器。
3. 前記プロトコルデータは、
   前記制御機器がシーケンシャル処理を行うために、前記コントローラから受信する必要がある前記制御信号のコマンド番号の並びを示したＳＴＯＲＯＢＥ値をさらに含むことを特徴とする請求項１または請求項２に記載の制御機器。
4. 自身の制御機器に類似する機種との差異となるプロトコルデータとして、（１）コントローラからの制御信号を受信するときのインターバルを示したＢＵＳＹ値および（２）前記自身の制御機器において実行する処理のコマンド番号を示した定義情報を記憶する記憶部と、前記コントローラから、前記コマンド番号を含む制御信号を受信し、この制御信号に応じて処理を実行し、その処理の実行結果を前記制御信号の応答として送信するサービス処理部とを備える制御機器から、前記プロトコルデータを受信するプロトコルデータ交換部と、
   前記制御機器に類似する機種に共通なドライバと、前記受信したプロトコルデータとを記憶する記憶部と、
   前記ドライバと前記プロトコルデータとを用いて、前記制御機器へ前記コマンド番号を含む前記制御信号を送信し、この制御機器に所定の処理を実行させ、前記処理の実行結果を前記制御信号の応答として受信する機器制御ドライバ部とを備え、
   前記機器制御ドライバ部は、
   前記プロトコルデータのＢＵＳＹ値に示されるインターバルで、前記制御機器へ前記制御信号を送信することを特徴とするコントローラ。
5. 前記プロトコルデータは、
   前記コントローラが、前記制御機器からの制御信号の応答のタイムアウトを検知するための時間を示したＴＩＭＥＯＵＴ値をさらに含み、
   前記機器制御ドライバ部は、
   前記制御機器へ前記制御信号を送信した後、前記プロトコルデータのＴＩＭＥＯＵＴ値に示される時間以上経過しても、当該制御機器から、前記制御信号の応答を受信しなかったとき、前記制御機器の異常を検知することを特徴とする請求項４に記載のコントローラ。
6. 前記プロトコルデータは、
   前記制御機器がシーケンシャル処理を行うために、前記コントローラから受信する必要がある前記制御信号のコマンド番号の並びを示したＳＴＯＲＯＢＥ値をさらに含み、
   前記機器制御ドライバ部は、
   前記プロトコルデータに示されるＳＴＯＲＯＢＥ値を参照して、前記シーケンシャルのために必要な前記制御信号を前記制御機器へ送信することを特徴とする請求項４または請求項５に記載のコントローラ。
7. 前記制御信号は、
   前記制御機器における初期化処理、ＩＯ処理およびサービス処理の少なくともいずれか１つの処理に関する制御信号であり、
   前記プロトコルデータは、
   前記制御機器における初期化処理、ＩＯ処理およびサービス処理それぞれに関するＢＵＳＹ値、ＴＩＭＥＯＵＴ値およびＳＴＲＯＢＥ値のうち少なくともいずれか１つの値を含むものであることを特徴とする請求項６に記載のコントローラ。
8. 制御対象となる各制御機器に共通なドライバを備えるコントローラが、
   自身の制御機器に類似する機種との差異となるプロトコルデータとして、（１）前記コントローラからの制御信号を受信するときのインターバルを示したＢＵＳＹ値および（２）前記自身の制御機器において実行する処理のコマンド番号を示した定義情報を含むプロトコルデータを受信するステップと、
   前記受信したプロトコルデータを前記コントローラの記憶部に記憶するステップと、
   前記ドライバと前記記憶されたプロトコルデータとを参照して、このプロトコルデータのＢＵＳＹ値に示されるインターバルで、前記制御機器へ前記定義情報に示されるコマンド番号を含む前記制御信号を送信するステップと、
   前記制御機器における処理の実行結果を前記制御信号の応答として受信するステップとを実行することを特徴とする制御方法。
9. 前記プロトコルデータは、
   前記コントローラが、前記制御機器からの制御信号の応答のタイムアウトを検知するための時間を示したＴＩＭＥＯＵＴ値をさらに含み、
   前記コントローラが、
   前記制御機器へ前記制御信号を送信した後、前記プロトコルデータのＴＩＭＥＯＵＴ値に示される時間以上経過しても、当該制御機器から、前記制御信号の応答を受信しなかったとき、前記制御機器の異常を検知することを特徴とする請求項８に記載の制御方法。
10. 前記プロトコルデータは、
    前記制御機器がシーケンシャル処理を行うために、前記コントローラから受信する必要がある前記制御信号のコマンド番号の並びを示したＳＴＯＲＯＢＥ値をさらに含み、
    前記コントローラが、
    前記プロトコルデータに示されるＳＴＯＲＯＢＥ値を参照して、前記シーケンシャルのために必要な前記制御信号を前記制御機器へ送信することを特徴とする請求項８または請求項９に記載の制御方法。
11. 前記制御信号は、
    前記制御機器における初期化処理、ＩＯ処理およびサービス処理の少なくともいずれか１つの処理に関する制御信号であり、
    前記プロトコルデータは、
    前記制御機器における初期化処理、ＩＯ処理およびサービス処理それぞれに関するＢＵＳＹ値、ＴＩＭＥＯＵＴ値およびＳＴＲＯＢＥ値のうち少なくともいずれか１つの値を含むものであることを特徴とする請求項１０に記載の制御方法。

Images