JP3912378B2 - 安全ネットワークシステム及び安全スレーブ並びに安全コントローラ - Google Patents

Description

技術分野
この発明は、安全ネットワークシステム及び安全スレーブ並びに安全コントローラに関するものである。
背景技術
ファクトリーオートメーション（以下、「ＦＡ」と称する）で用いられるプログラマブルコントローラ（以下、「ＰＬＣ」と称する）は、スイッチやセンサなどの入力機器からＯＮ／ＯＦＦ情報を入力し、ラダー言語などで書かれたシーケンスプログラム（ユーザプログラムとも称する）に沿って論理演算を実行し、求められた演算結果に従い、リレーやバルブ，アクチュエータなどの出力機器にＯＮ／ＯＦＦ情報の信号を出力することで制御が実行される。
ところで、ＰＬＣと、入力機器並びに出力機器との接続形態は、ＰＬＣに直接接続する場合もあれば、ネットワークを介して接続する場合もある。係るネットワークで接続されたネットワークシステムを構築した場合、上記ＯＮ／ＯＦＦ情報の送受をネットワークを経由して行うことになる。このとき、通常、ＰＬＣ側がマスタとなり、機器側がスレーブとなるマスタスレーブ方式で情報の伝送が行われる。
一方、最近ではＰＬＣによる制御においても、フェイルセーフ（安全）システムが導入されつつある。つまり、ＰＬＣや各機器自体はもちろんネットワークも安全機能を組み込まれたもので構成される。ここで安全機能とは、安全であることを確認し、出力を行う機能である。そして、安全システムは、緊急停止スイッチが押下されたり、ライトカーテンなどのセンサが人（身体の一部）の進入を検出した場合等のネットワークシステムが危険状態になった場合に、フェイルセーフが働き、システムが安全側になって、動作が停止するようにするものである。換言すると、上記した安全機能により、安全であることが格納されたときのみ出力し、機械を動かすシステムである。よって、安全が確認できない場合には、機械が停止する。
そして、スレーブの状態は、例えばＰＬＣ（マスタ）からの要求を受けたスレーブが応答として返すことができ、これによりＰＬＣはネットワークに接続されたスレーブの状態を取得することができる。
ところで、安全ネットワークシステムの場合、危険状態になった場合にできるだけ早くシステムを安全側にして、停止させるのが好ましい。しかし、安全ネットワークに接続された安全機器の数が増えると、１回の通信サイクルにおいて係る安全機器の個数分の安全情報が送信されることから、必然的に通信サイクルタイムが長くなる。従って、仮に通信サイクルの最初の方に安全情報（危険）が送信できたとしても、前回送信してから今回までに通信サイクルタイムに相当する時間が経過してしまう。よって、迅速に危険状態になったことを通知しフェイルセーフを実行することができない。ましてや、通信サイクルの最後の方に安全情報（危険）を送信した場合にはなおさら遅くなる。
さらに、安全機器や安全スレーブが正常に動作している場合には、安全情報（危険）を送信することができるが、装置自体が故障したり、ネットワーク異常などがあり安全情報を安全ＰＬＣに伝達することができないこともある。係る場合も異常と判断し、フェイルセーフを実行する必要がある。
この場合、例えば、一斉同報で要求を発した後、予め設定した受信時間を経過しても応答の無かった安全スレーブ（安全機器）があった場合（タイムアウト）には、異常があったと判断することができる。従って、このタイムアウトとなる受信時間は、少なくとも正常状態の時の通信サイクルタイム以上にする必要があり、上記したように通信サイクルタイムが長くなると、係るネットワーク異常の有無を判断するのに要する時間も長くなり、異常時に迅速な処理が行えなくなる。
なお、複数の安全機器を１つの安全スレーブ（ターミナル）に接続する場合には、安全スレーブは、係る複数の安全機器からの安全情報を収集し、接続された全ての安全機器の安全情報を一括して送信することになるので、上記した問題が発生する。
この発明は、安全機器（安全スレーブ）の安全か否かの情報を、迅速にマスタ（安全コントローラ）その他の装置に送信することができ、異常（危険）状態になった場合には、早急にフェイルセーフを実行することができ、さらに、危険箇所の特定やシステムのデバッグ時などは、システム全体の詳細な情報を確認し不具合の特定を早急に確認することのできる安全ネットワークシステム及び安全スレーブ並びに安全コントローラを提供することを目的とする。
発明の開示
この発明による安全スレーブは、安全ネットワークに接続可能であり、前記安全ネットワークを介して送られてきた安全コントローラからの要求に応じて、自己が管理する複数の安全入力情報に基づく情報を送信する安全スレーブであって、前記複数の安全入力情報に基づき安全条件を満足するかの判断を行う安全判断手段と、その安全判断手段により判断された安全判断結果を前記情報として送信する手段を備えて構成した。
安全入力情報とは、安全機器の状態を示す情報、つまり「安全」か「安全でない（異常，危険）」を特定する情報であり、安全情報と称することもある。また、安全スレーブ自体の状態が安全状態か否かの情報も安全情報に含めることもある。もちろん、それ以外の情報を含めても良い。特に、後述するように、安全入力情報をそのまま送る場合にそれ以外の付加情報を設けることにより、受け取った安全コントローラ等の装置側では状態が詳細に理解できるのでよい。
安全判断手段は、実施の形態ではＭＰＵ２３により実現されている。また、安全判断は、実施の形態では、全ての安全入力情報が「安全」の場合に安全判断結果も「安全」となり、１つでも安全でない安全入力情報が存在した場合には、安全判断結果も「安全でない（異常，危険）」とするようにしたが、他の安全条件を設定しても良い。
この発明によれば、安全スレーブに接続された複数の機器（安全機器や他の安全スレーブなど）から安全入力情報を受けた場合、それら全ての安全入力情報をそのまま安全コントローラに対して通知するのではなく、それら複数の安全入力情報に基づいて判断された安全判断結果（安全か否か等）を送るので、安全コントローラに返す安全応答のデータ量が少なくなる。よって、１回の通信サイクルタイムも短くなり、異常（危険）発生時に迅速に安全コントローラへ通知できる。
また、上記した安全判断手段は、例えば論理演算（アンド）をすることにより簡単に判断することができる。さらに、安全判断結果は、複数の安全入力情報の論理演算の結果と見ることもできるし、所定のデータ圧縮処理をした結果とも言える。要は、データ量を少なくしつつ、受け取った安全コントローラその他の装置側でシステムが安全状態にあるか否かの判断が行えるようになっていればよい。
好ましくは、複数の安全入力情報を、データの集合としてそのまま前記情報として通知する機能を備えることである。この機能は、実施の形態では、「詳細情報モード」での送信に対応する。もちろん、係る機能はなくても良いが、設けることにより安全コントローラ側では各安全機器などの個別の状態を認識することができ、危険箇所の特定や不具合の内容などの各種の解析などに役立つ。
また、データの集合とする場合、実施の形態のように入力された全ての安全入力情報をそのまま通知するものはもちろんのこと、一部をデータ圧縮して得られたデータの集合とすることもできる。つまり、仮に８個の安全入力情報を受けた場合に、一部（例えば４個）については、上記と同様の判断を行い、４個全てが安全の場合に安全とし、４個のうちの１つでも安全でないと言う場合には、安全でないとする。そして、係る判断をした結果に、残りの４個の安全入力情報を合わせたデータの集合とすることができる。このように、一部の安全入力情報をそのまま送る場合、その一部の個数は、例示したように半分にする必要はなく、任意の数を取ることができる。
さらに、自己或いは自己が管理する機器の少なくとも一方の危険原因を検出するとともに、その検出した前記危険原因を前記情報に付加して送信する機能を備えることができる。このように危険原因を更に付加することにより、より詳細な解析等が行える。なお、危険原因とともに送る情報としては、前記安全判断結果でも良いし、複数の安全入力情報からなるデータの集合としてもよい。もちろん、それ以外の形態の情報でも良い。
また、本発明における安全スレーブは、安全機器が接続される通常のものに限ることは無く、異種フィールドバスを接続する安全ゲートウェイとしてもよい。この場合に、前記安全入力情報は、前記安全ゲートウェイに接続された複数の他の安全スレーブからの安全入力情報である。従って、安全判断結果としては、複数の他の安全スレーブから取得した各安全入力情報に基づき、安全条件を満足するかの判断を行うことにより求める。
一方、より詳細な詳細情報としては、取得した複数の安全入力情報を、データの集合としてそのまま通知することができる。また、詳細情報の他の形態としては、取得した前記複数の安全入力情報を所定の単位ごとに時分割で送信可能とすることである。所定の単位は、例えば、実施の形態（図９（ｃ））で示すように、ノード単位とすることができる。そして、このように所定の単位とすることにより、各単位ごとに通知する情報の種類（モード）を変更することができる。これにより、例えば、必要な単位のものからは、詳細情報モードで送信を受け、それ以外のものからは安全判断結果を受けることにより、効率良く迅速かつ有用な情報を取得することができる。
また、前記安全スレーブは、少なくとも前記安全判断結果を送る結果通知モードと、前記結果通知モードと異なり、より詳しい情報を送信する詳細情報モードで送信可能とした場合、係る前記送信するモードの切り替えは、前記安全コントローラからの通信コマンドに基づいて選択実行されるようにしてもよいし、送信するモードの切り替えを行う設定スイッチ手段を備え、係る選択スイッチ手段からの指示に従って行うようにしても良い。
この発明に係る安全ネットワークシステムは、安全コントローラと、上記した各種の構成からなる安全スレーブとが安全ネットワークを介して接続されて構築される。そして、前記安全スレーブから出力された前記情報が、前記ネットワークを介して前記安全コントローラへ送信されるようにした。
また、この発明に係る安全コントローラは、安全ネットワークに接続され、上記した安全スレーブとともに安全ネットワークシステムを構築可能な安全コントローラである。そして、前記安全ネットワークシステムの状態が安全状態か否かを記憶保持する状態記憶部と、前記状態記憶部に記憶された現在の状態が安全の場合に、前記安全スレーブに対して前記安全判断結果の送信を要求し、前記状態記憶部に記憶された現在の状態が安全でない場合に、前記安全スレーブに対して前記安全判断結果よりも詳しい詳細情報の送信を要求するように構成することができる。状態記憶部は、実施の形態では、安全フラグを記憶するものに対応する。なお、本発明に係る安全ネットワークシステムを構築する安全コントローラとしては、上記のように、状態記憶部や、状態記憶部に格納された現在の状態に基づいて要求を発する機能はなくても良い。
また、別の安全スレーブとしては、安全ネットワークに接続可能であり、自己が管理する複数の安全入力情報に基づく情報を、前記安全ネットワークに接続された他のノードへ送信する安全スレーブである。そして、前記複数の安全入力情報に基づき安全条件を満足するかの判断を行う安全判断手段と、その安全判断手段により判断された安全判断結果を前記情報として送信する手段を備えて構成することもできる。
この場合の安全スレーブが安全情報を送信するタイミングは、内部トリガ並びに外部トリガのいずれに基づくものでもよい。さらに、この他のノードに送信する安全スレーブにおいても、複数の安全入力情報を、データの集合としてそのまま前記情報として通知する機能を備えるとよい。この機能は、実施の形態では、「詳細情報モード」での送信に対応する。もちろん、係る機能はなくても良いが、設けることにより安全コントローラ側では各安全機器などの個別の状態を認識することができ、危険箇所の特定や不具合の内容などの各種の解析などに役立つ。
さらに、自己或いは自己が管理する機器の少なくとも一方の危険原因を検出するとともに、その検出した前記危険原因を前記情報に付加して送信する機能を備えることができる。このように危険原因を更に付加することにより、より詳細な解析等が行える。なお、危険原因とともに送る情報としては、前記安全判断結果でも良いし、複数の安全入力情報からなるデータの集合としてもよい。もちろん、それ以外の形態の情報でも良い。
さらにまた、本発明における安全スレーブは、安全機器が接続される通常のものに限ることは無く、異種フィールドバスを接続する安全ゲートウェイとしてもよい。この場合に、前記安全入力情報は、前記安全ゲートウェイに接続された複数の他の安全スレーブからの安全入力情報である。従って、安全判断結果としては、複数の他の安全スレーブから取得した各安全入力情報に基づき、安全条件を満足するかの判断を行うことにより求める。
一方、より詳細な詳細情報としては、取得した複数の安全入力情報を、データの集合としてそのまま通知することができる。また、詳細情報の他の形態としては、取得した前記複数の安全入力情報を所定の単位ごとに時分割で送信可能とすることである。
さらにまた、安全スレーブは、少なくとも前記安全判断結果を送る結果通知モードと、前記結果通知モードと異なり、より詳しい情報を送信する詳細情報モードで送信可能とした場合、係る前記送信するモードの切り替えは、前記他のノードからの通信コマンドに基づいて選択実行されるようにしてもよいし、送信するモードの切り替えを行う設定スイッチ手段を備え、係る選択スイッチ手段からの指示に従って行うようにしても良い。
そして、係る安全スレーブを用いた安全ネットワークとしては、前記安全スレーブから出力された前記情報が、前記安全ネットワークを介して他のノードへ送信されるように構成することができる。
発明を実施するための最良の形態
本発明をより詳細に説明するにあたり、添付の図面に従ってこれを説明する。
図１は、本発明が適用される安全ネットワークシステムの一例を示している。同図に示すように、安全ＰＬＣ１（マスタ）と複数の安全スレーブ２が安全ネットワーク（フィールドバス）３を介して接続されている。安全ＰＬＣ１と安全スレーブ２とは、マスタースレーブ方式により情報の送受が行われる。更に、各安全スレーブ２には、安全ドアスイッチ，安全リミットスイッチや非常停止スイッチなどの他、各種の入力機器や出力機器等の安全機器４が接続されている。なお、安全ＰＬＣ１は、例えばＣＰＵユニット，マスタユニット（通信ユニット），Ｉ／Ｏユニットなどの複数のユニットを連結して構成するものが用いられる。この場合に、安全ネットワーク３に対しては、マスタユニットが接続される。
この安全ネットワークシステムを構成する各種装置は、全て安全機能（フェイルセーフ）が組み込まれたものを用いている。この安全機能は、安全であることを確認し、出力（制御）を行う機能である。そして危険状態になった場合にフェイルセーフが働いて、システムが安全側になって動作を停止させる。つまり、安全システムは、緊急停止スイッチが押下されたり、ライトカーテンなどのセンサが人（身体の一部）の進入を検出した場合等のネットワークシステムが危険状態になった場合に、フェイルセーフが働き、システムが安全側になって、動作が停止するようにするものである。換言すると、上記した安全機能により、安全であることが格納されたときのみ出力し、機械を動かすシステムである。よって、安全が確認できない場合には、機械が停止する。
次に、このような安全機能のうち、本発明の要部となる情報の送受について説明する。安全スレーブ２は、複数の端子台２ａを備えており、この端子台２ａに各種の安全機器４を接続する。一方、安全スレーブ２の内部構造は、図２に示すようになっている。同図に示すように、安全ネットワーク３に接続し、安全ＰＬＣ１（マスタ）との間でデータの送受を行う通信部２１と、安全スレーブ２に接続された安全機器４との間でデータの送受を行うための入出力回路２２と、システムＲＯＭ２４に格納されたプログラムを読み出し、所定の処理を実行するＭＰＵ２３を備えている。ＭＰＵ２３は、通信部２１を介して受信した自己宛ての要求に従い、入出力回路２２を介して安全機器４から取得した情報（安全情報等）を、通信部２１，安全ネットワーク３を経由して安全ＰＬＣ１（マスタ）に返す処理を行う。
ＭＰＵ２３は、安全ＰＬＣ１からの要求に基づいて安全応答（安全情報を含んだ送信フレーム）を生成し、安全ＰＬＣ１に向けて返信する。このとき、生成される安全応答（送信フレーム）としては、データ量の少ない結果通知モードと、データ量の多い詳細情報モードの２種類がある。ここで、結果通知モードは、自己に接続された全ての安全機器４からの安全入力情報を収集し、それら全てが安全状態にあるか否かを判断し、その判断結果をデータ部に格納したものである。つまり、全ての安全機器４の安全入力情報が、「安全」の場合には、判断結果は「安全」とし、安全入力情報が「異常（危険）」となった安全機器４が１つでも存在すると、判断結果は「危険」としている。
このように、本実施の形態では、中身の違う２種類のモードがあり、各モードでそれぞれ中身がちがう安全応答が生成される。そして、安全要求があった場合に、係る２つのモードをそれぞれ作成するのではなく（作成しても良いが）、何れか一方のモードの安全応答を生成し、送信する。
本実施の形態では、安全判断結果を２ビット（００：危険，１１：安全）としているが、１ビットで表現することも可能である。そして、結果通知モードの具体的な送信フレームしては、例えば図３（ａ）に示すようになる。
また、上記の例では、安全スレーブ２が管理する複数チャネルの全てを１つとして捉え、その全てが安全の場合に安全とするようにしたが、本発明はこれに限ることはなく、複数チャネルを区分けし、各区分けした単位で安全か否かを判断するようにしても良い。つまり、例えば、８チャネル入力の場合、１〜４チャネルと５〜８チャネルに分けて管理し、１〜４チャネルのどれかが危険というのと、５〜８チャネルのどれかが危険というのとを区別して送信する。
このようにすると、フェイルセーフで設備停止する範囲を少なくできる。具体例としては、設備がＡ〜Ｃ装置に分割され、Ａ装置の危険状態に関与するスイッチ，センサなどが安全スレーブの１〜４チャネルにつながれている。一方、Ｂ装置の非常停止スイッチ２個は５，６チャネルにつながれ、Ｃ装置の非常停止スイッチは７チャネルにつながれている（８チャネルは空き）場合を想定する。このとき、仮に７チャネルのスイッチがＯＮになったとき、Ｃ装置のみ停止させ、他の装置ＡＢはそのまま稼動させることができる。従って、７チャネルが危険入力で装置すべて（設備全体）が停止するよりは、生産性が低下しない。このように複数の区分に世分けたとしても、全ての安全情報を送信する場合に比べると効率的である。
一方、詳細情報モードは、従来と同様に、安全スレーブ２に接続された安全機器４から得られる複数チャネルの安全入力情報を、データの集合としてそのまま通知するものである。そして、この詳細情報モードの具体的な送信フレームとしては、例えば図３（ｂ）に示すようになる。仮に安全スレーブ２が８チャネル入力タイプとすると、送信フレームのデータでには、８チャネル分の安全情報が格納される。
そして、何れのモードで送信するかを決定する安全ＰＬＣ１からの要求は、例えば図３（ｃ）に示すような送信フレームとなる。すなわち、要求先アドレス（安全スレーブのアドレス，同報による全ての安全スレーブを指定可）と、モード指示フラグ（０１：結果モード，１１：詳細モード）等を含むものとなる。
つまり、動作中においては、安全ＰＬＣ１にとっては、ネットワークシステムを構成する各安全機器４のうち、１つでも「危険状態」になった場合には、システムを停止する。一方、全ての安全機器４が安全状態にある場合には、そのまま動作させる。従って、フェイルセーフを実行するにおいては、危険を検知した安全機器が存在するか否かが重要であり、具体的にどの安全機器が危険を検知したかや、検知した危険の原因などはさほど重要ではない。
逆に、非常停止ボタンが押された場合などの危険状態や、メンテナンス時，設備立ち上げ時などは、不具合箇所や内容などを特定する必要から、各安全機器からの安全情報を取得したいという要求がある。
そこで、本実施の形態では、通常は図４（ａ）に示すように安全ＰＬＣ１から結果通知要求コマンドを発し、それを受けて各安全スレーブ２からは、各自が判断して得られた安全判断結果（２ビット）を安全応答として返す。これにより、１回の通信サイクルタイムが短くでき、迅速に安全情報、特に危険状態を示す安全情報を通知することができる。
そして、図４（ｂ）に示すように、危険状態等になり、システムを安全側に移行した後などの所定のタイミングで、安全ＰＬＣ１が詳細情報要求コマンドを発すると、それを受けて各安全スレーブ２からは、詳細情報として自己に接続されている安全機器からの安全情報を安全応答として返す。これにより、１回の通信サイクルタイムは長くなるものの、各安全機器の状態がわかり、不具合箇所などを簡単に特定することができる。よって、本形態によれば、状況に応じて高速応答性と情報の詳細性を使い分けることが可能となる。
具体的には、仮に安全スレーブ２が８チャネル入力タイプとすると、通常の方法では、８チャネル分の安全情報を送るので、送信フレームのデータ部は２バイトの情報量が必要であったが、本形態によれば、チャネル数に関係無く、送信フレームのデータ部は安全判断結果の２ビットで済む。
上記した処理を実現するための安全ＰＬＣ１側のＭＰＵの処理機能は、図５に示すフローチャートのようになる。前提として、現在の状態を示す安全フラグを持つ。安全フラグ＝０の場合には、安全ネットワークシステムが危険状態（少なくとも１つの安全機器が危険状態）となっていることを意味し、安全ＰＬＣ（マスタ）１は、安全出力を強制ＯＦＦする。また、安全フラグ＝１の場合には、安全ネットワークシステムが安全状態（全ての安全機器が安全状態）となっていることを意味し、安全ＰＬＣ（マスタ）１は、Ｉ／Ｏリフレッシュ可能となる。そして、この安全フラグは、安全ＰＬＣ１のＭＰＵが更新する。
上記した前提の基に、ＭＰＵは、以下のように動作する。すなわち、まず安全フラグが「１」であるか否かを判断する（ＳＴ１）。そして、「１」であれば、安全状態にありシステムは正常に動作しているので、異常時（危険）に備えて結果通知要求コマンドを送信する（ＳＴ２）。
その後、安全スレーブ２からの安全応答（レスポンス）の受信を待ち（ＳＴ４）、正常に受信した場合には、受信した安全情報の内容が安全か否かを判断する（ＳＴ５）。そして、安全の場合には、安全フラグを１にセットする（ＳＴ６）。一方、安全応答を正常に受信できない場合（ステップ４でＮｏ）や、受信した安全情報の内容が危険の場合には、安仝フラグを「０」にする（ＳＴ７）。
なお、ステップ４の分岐判断でＮｏとなる「安全応答を正常に受信できない場合」としては、▲１▼ノイズなどで通信エラー，▲２▼送信側か受信側かの通信エラー（復帰可のもの），▲３▼回線が外れたたり切れたりした，▲４▼スレーブの送信機能が故障，▲５▼マスタ（安全ＰＬＣ）の受信機能の故障などがある。そして、上記した▲１▼，▲２▼の場合には、次以降の通信サイクルの際に安全応答を正常に受信し、通信が続行することができるが、▲３▼▲４▼▲５▼の場合は通信自体が不能になるので、安全ＰＬＣは、何れのモードの安全応答も受信できなくなる。
また、ステップ１の分岐判断でＮｏの場合には、既に前回以前の通信サイクルで、異常（危険）になりステップ７を経て安全フラグが「０」に更新されているので、詳細情報コマンドを送信し（ＳＴ３）、各安全機器ごとの安全情報の収集を図る。
一方、安全スレーブ２側のＭＰＵ２３の機能は、図６に示すフローチャートのように、まず受信フレームを待つ（ＳＴ１１）。そして、受信したフレームの送信先アドレスを確認し、自ノードアドレスか否かを判断する（ＳＴ１２）。他のノードアレスの場合には、ステップ１に戻り次の受信フレームを待つ。
また、自ノードアドレスの場合には、要求が結果通知コマンドか否かを判断し（ＳＴ１３）、結果通知コマンドの場合には、安全判断結果、つまり、自己に接続された全ての安全機器が安全か否かの判断をした演算結果を送信バッファにセットし、安全応答として返す（ＳＴ１４，ＳＴ１５）。
一方、受信した要求コマンドが結果通知コマンドでない場合（ステップ１３でＮｏ）は、詳細情報コマンドか否かを判断する（ＳＴ１６）。詳細情報コマンドの場合には、上記演算前、つまり自己に接続された全ての安全機器からの安全Ｉ／Ｏ入力を送信バッファにセットし、安全応答として返す（ＳＴ１７，ＳＴ１５）。なお、詳細情報コマンドでもない場合には、安全要求ではないので、今回の受信に基づいては安全応答はせずに、ステップ１１に戻り、次のフレームの受信を待つ。以後、上記処理を繰り返し実行し、要求に応じた種類の安全応答を返す。
図７は、本発明の第２の実施の形態の要部を示している。すなわち、本実施の形態では、上記した第１の実施の形態を基本とし、詳細情報モードで通知する情報が異なる。つまり、安全ＰＬＣから詳細情報モードの要求があった場合には、図７（ｂ）に示すようなフレーム構成からなる安全応答を返す。具体的には、結果通知モードにおける送信フレーム（図７（ａ））と同様に、複数チャネルの安全入力情報をもとに、その範囲内で、安全スレーブ自身が安全条件を満足するかの判断を行い求めた安全／危険を示すコード（安全判断結果コード）に加えて、危険原因を通知するようにしている。
ここで、危険原因とは、「安全スレーブ自身の自己診断がＮＧ」，「接続された安全機器の診断結果がＮＧ」，「安全機器（非常停止押しボタンなど）の出力が危険を意図している状態にある」などである。特に接続された安全機器に関連した原因の場合には、その安全機器を特定するチャネル情報も含む。
なお、本実施の形態では、安全判断結果と危険原因コードを送信するようにしたが、本発明はこれに限ることはなく、例えば、第１の実施の形態における詳細情報で送信した安全情報に加えて危険原因コードを送信するようにしても良い。さらに、第１の実施の形態における詳細情報モードを詳細情報モード１とし、第２の実施の形態における詳細情報モードを詳細情報モード２とし、これら２つの詳細情報モードと通常時の結果通知モードの３種類を識別するフラグを設定し、安全ＰＬＣからの要求に応じてそれら３つのモードの中から択一的に選択されたものを安全応答として返すようにしても良い。
なお、このように詳細モードで送信する情報が異なるだけで、その他の構成並びに作用効果は上記した第１の実施の形態と同様であるので、その詳細な説明を省略する。
図８は、本発明の第３の実施の形態を示している。本実施の形態は、上記した各実施の形態と相違して、上位ネットワーク３ａに安全ゲートウェイ７を接続し、その安全ゲートウェイ７に下位ネットワーク３ｂを介して複数の安全スレーブ２が接続された構造の異種フィールドバスを接続した多段のネットワークシステムに適用した例を示している。
本実施の形態では、安全ゲートウェイ７が、上記した安全スレーブ２と同様の機能を発揮し、下位ネットワーク３ｂに接続された各安全スレーブ２からの安全情報を複数のモードを択一的に用いて上位のマスタ（安全ＰＬＣ１）に通知するようになっている。つまり、下位ネットワーク３ｂに接続された複数の安全スレーブ２からの安全入力情報をもとに、その下位ネットワーク（フィールドバス）３ｂ内で、安全ゲートウェイ７自身が安全条件を満足するかの判断を行い、その結果として安全／危険を示す安全判断結果コードを上位ネットワーク３ａ（上位フィールドバス）を介して安全ＰＬＣ１に送る（図９（ａ）参照）。
これは、結果通知モードであり、下位ネットワーク３ｂに接続された全ての安全スレーブ２からの安全入力情報が「安全」の場合に、安全判断結果は「安全」となり、少なくとも１つの安全スレーブからの安全情報が「危険」の場合には、安全判断結果は「危険」となる。
また、本実施の形態でも、下位ネットワーク３ｂに接続された複数の安全スレーブ２からの安全入力情報を、データの集合としてそのまま通知する詳細情報モードを備えている（図９（ｂ）参照）。
そして、ゲートウェイ７は、下位に接続された各スレーブ２から、それぞれ安全情報をシリアルデータとして受取り、それに基づく情報（結果通知，詳細情報）を、上位ネットワーク３ａ中に接続されたノードに送信することができる。この場合の送信相手は、安全ＰＬＣ１であったり、スレーブ２であったり、図示省略した上位ネットワーク３ａに接続されたコンフィグレーションツールやモニタ装置など各種のノードとすることかできる。
ところで、上位ネットワーク３ａ並びに下位ネットワーク３ｂに接続された各安全スレーブ２も、同様に結果通知モードと詳細情報モードのように複数のモードで送信可能としている。従って、下位ネットワーク３ｂの各安全スレーブ２が、結果通知モードで安全ゲートウェイ７に安全応答を送信しているとする。この時、安全ゲートウェイ７が、結果通知モードで応答する場合は、４つの安全スレーブ２からの安全応答が全て「安全」のときに安全判断結果が「安全」となり、１つでも「危険」が存在している場合には、安全判断結果は「危険」となる。また、詳細情報モードで応答する場合には、各安全スレーブ２からの安全判断結果の集合として送信することになる。
さらに、別の詳細情報モードとしては、図９（ｃ）に示すように、下位ネットワーク３ｂ上に接続された複数の安全スレーブ２の安全入力情報を、ある単位（たとえばノード単位）ごとに時分割で通知することもできる。この場合に、図示するように、各ノード（安全スレーブ２）ごとで安全応答する際のモードを変えることもできる。つまり、ある安全スレーブ（図示の例ではＮｏ．１）からは安全判断結果を送り、別の安全スレーブ（図示の例ではＮｏ．２など）からは安全情報（全ての安全機器からの安全入力情報）を送るようにすることができる。
そして、係る２種類の詳細情報モードは、予め何れか一方のみ使用できるように組み込んでおいてもよいし、２種類の詳細情報モードを送信可能とし、安全ＰＬＣ１からの要求フラグにより、何れかを選択して返すようにしても良い。
なお、安全ゲートウェイ７のＭＰＵにおけるＩ／Ｏリフレッシュ機能は、図６に示したものと基本的に同様にすることができる。そして、ステップ１４，１６において送信バッファにセットするのが下位ネットワーク３ｂからの安全入力に基づくデータとなる点で相違する。なお、その他の構成並びに作用効果は、上記した実施の形態と同様であるので、その詳細な説明を省略する。
また、このゲートウェイを用いたシステムにおいても、安全判断結果に加えて危険原因コードを付加したものを詳細情報モードとすることができる。そして、危険原因には、例えば「安全ゲートウェイ７自身の自己診断結果がＮＧ」，「下位ネットワーク３ｂのネットワーク異常」，「下位ネットワーク３ｂに接続された安全スレーブ２のネットワークからの離脱」，「下位ネットワーク３ｂに接続された安全スレーブ２の自己診断結果がＮＧ」，「下位ネットワーク３ｂに接続された安全スレーブ２につながる安全機器（非常停止押しボタンなど）の出力が危険を意図している状態にある」などである。特に、下位ネットワーク３ｂに接続された安全スレーブ２やこれに接続された安全機器に関連した原因の場合には、その機器を特定するアドレス情報やチャネル情報も含む。
上記した各実施の形態では、動作モードを決定する手段が、安全ＰＬＣ１からの要求内に組み込まれた通信コマンドとしたが、本発明はこれに限ることは、安全スレーブ２や安全ゲートウェイ７に実装された設定スイッチとしてもよい。
さらにまた、上記した実施の形態で説明したスレーブは、マスタユニットとの間でＩ／Ｏ情報を送受し、そのマスタユニットを経由してコントローラ（ＰＬＣ）と係るＩ／Ｏ情報の送受を行ってシステムの制御を行う例を示し、マスタユニットとスレーブとの間は、マスタからの要求に対して所望のスレーブがレスポンスを返すと行ったマスタースレーブ方式を説明した。しかし、本発明で言うスレーブは、マスタースレーブ間通信を行うものに限られない。つまり、スレーブとは称するものの、通信方式は任意のものを利用できる。その点では、厳密に言うと一般的に定義されているスレーブとは異なる概念を含むものであると言える。つまり、本発明で言う所のスレーブは、制御に必要なＩ／Ｏ情報をコントローラと送受する機能が有れば、実際に送受信する際の通信プロトコルは任意である。特に本発明で送信対象とする安全情報の送信先は、マスタユニットやコントローラに限ることはなく、ネットワークに接続された他のスレーブその他の装置等の自ノード以外のデバイス、つまり他ノードとすることができる。
そして、通信方式も、送信相手に応じて適宜選択できる。もちろん、送信するためのトリガも、上記したマスタからのリクエストのように外部からの要求に応じて行うものに限ることはなく、内部トリガ（内部のタイマ，一定の条件に合致したときに発生するイベントなど）に基づいて送信してもよい。
ここで、「内部トリガ」とは、スレーブ自身の所定の処理実行の結果に基づくもので、スレーブ内部で生成されるものである。そして、内部トリガの一例を示すと、以下のものがある。すなわち、異常状態が発生した時や、スレーブで取得した入出力機器の状態情報がしきい値に達したり、しきい値を越えたかどうかを判断すると、その判断結果が生じる。その判断結果をトリガ信号として利用するものがある。さらに、スレーブ内で時計を持たせておき、その時計により所定時間経過のたびに周期的にトリガ信号を生成したり、所定時刻でトリガ信号を生成するものもある。
また、各安全スレーブは、自己の内部タイマに基づいて送信する場合、既に他の安全スレーブが送信中の場合には、送信を停止し、同時に送信しようとしてネットワーク上で衝突した場合には、優先順位の高い安全スレーブ（ノード番号の小さいもの）側がそのまま通信を継続する。これにより、１回の通信サイクルで、所定の順で各安全スレーブから順次情報を送信することができる。そして、送信タイマを適宜に設定することにより、以後は、その順でスムーズに繰り返し情報の送信が行える。
一方、「外部トリガ」とは、ネットワークを介してスレーブが受けたコマンドに基づくもので、スレーブの外で生成されるものである。そして、外部トリガの一例を示すと、マスタからスレーブへの情報要求コマンド，モニタリング装置からスレーブへの情報要求コマンド，コンフィグレータからの情報要求コマンド，ツール発信で、ＰＬＣ経由やマスタ経由で送られてくるコマンドなどがある。
そして、マスタ以外のノードと通信をする場合の具体例としては、例えば図１０以降に示す第４の実施の形態がある。この実施の形態は、送信相手がスレーブ、つまり、ＩＮスレーブからＯＵＴスレーブに対して安全情報を送信するシステムの一例を示している。
図１０に示すように、安全ＰＬＣ１（マスタ）が接続された安全ネットワーク（フィールドバス）３に、複数の安全スレーブが接続されている。そして、この実施の形態では、安全スレーブとしてＩＮスレーブ２′と、ＯＵＴスレーブ２″が用いられている。ＩＮスレーブ２′の端子台２ａに接続される安全機器４としては、安全リミットスイッチや非常停止スイッチその他の入力機器が接続されている。そして、その安全機器４からの安全入力情報が、安全ネットワーク３を介してマスタ１に送られる。また、ＯＵＴスレーブ２″の端子台２ａに接続される安全機器４は、リレー，モータ，アクチュエータその他の出力機器が接続されている。そして、ＯＵＴスレーブ２″は、マスタ１から送られる出力情報（Ｉ／Ｏ情報）に基づき、出力機器の動作制御を行うようになる。
そして、本実施の形態では、ＩＮスレーブ２′で検出された安全情報を、所定のタイミングで安全ネットワーク３を介してＯＵＴスレーブ２″に送るようにしている。一方、安全スレーブ２の内部構造は、図２に示すようになっている。同図に示すように、安全ネットワーク３に接続し、安全ＰＬＣ１（マスタ）との間でデータの送受を行う通信部２１と、安全スレーブ２に接続された安全機器４との間でデータの送受を行うための入出力回路２２と、システムＲＯＭ２４に格納されたプログラムを読み出し、所定の処理を実行するＭＰＵ２３を備えている。ＭＰＵ２３は、通信部２１を介して受信した自己宛ての要求に従い、入出力回路２２を介して安全機器４から取得した情報（安全情報等）を、通信部２１，安全ネットワーク３を経由して安全ＰＬＣ１（マスタ）に返す処理を行う。これらの基本構成は、上記した各実施の形態と同様である。
そして、本実施の形態では、安全スレーブ同士が直接通信を行うため、送信相手のアドレスや、通信する際の条件などを記憶保持する必要がある。そこで、自ノードのアドレスや、送信相手のノードのアドレスを設定する設定部２６と、その設定部２６で設定されたアドレス情報等を格納する記憶部２７を備えている。設定部２６は、例えばディップスイッチにより構成することができる。また、記憶部２７はＥＥＰＲＯＭにより構成することができる。
記憶部２７は、アドレス情報とともに、安全情報の送信タイミングを決定する送信トリガ条件も保有する。そして、係る送信トリガ条件は、例えば、図省略するフィールドバス３に接続されたコンフィグレーションツールから設定することができる。また、このようにネットワークを介するのではなく、スレーブに直接ツールを接続して設定することもできる。さらには、記憶部２７に格納するアドレス情報も、設定部２６ではなくコンフィグレーションツールから設定しても良い。
そして、送信トリガ条件が、外部トリガ、つまり、ＯＵＴスレーブ２″からの要求コマンドの場合は、例えば、図１２に示すようなタイミングで安全情報を送信すようになる。
すなわち、ＯＵＴスレーブ２″から、ＩＮスレーブ２′に対して入力データ要求コマンドを送る。このとき、モードの種別、つまり、結果通知モードか詳細情報通知モードかも併せて送る。そして、係るコマンドを受信したＩＮスレーブは、指定されたモードでレスポンスを返す。すなわち、入力データ（結果通知）コマンドを受けた場合には、安全情報の結果を２ビットで表した結果通知レスポンスを返す。また、入力データ（詳細情報１）コマンドを受けた場合には、安全情報として８チャネル分（２バイト）の詳細情報１レスポンスを返す。そして、それら各レスポンスを受け取ったＯＵＴスレーブ２″は、ＩＮスレーブ２′に対してＡＣＫを返す。なお、ＯＵＴスレーブ２″がＡＣＫを返してから次の入力データ要求コマンドを発行するまでの間は、他のデバイスがネットワークを使用する。
また、送信トリガ条件が、ＩＮスレーブ２′の内部トリガの場合、例えば図１３に示すようなタイミングで安全情報を送信するようになる。すなわち、ＩＮスレーブ２′が、例えば内部送信タイマにより、所定の時間が経過したことなどに伴いトリガが発生すると、結果通知フレーム（２ビット）或いは詳細情報１フレーム（８チャネル＝２バイト）を、予めアドレスが登録されたＯＵＴスレーブに対して送信する。そして、それら各フレームを受け取ったＯＵＴスレーブ２″は、ＩＮスレーブ２′に対してＡＣＫを返す。なお、この例でも、ＯＵＴスレーブ２″がＡＣＫを返してから、次の安全情報の通知フレームを発行するまでの間は、他のデバイスがネットワークを使用する。
また、この例における結果通知モードと詳細情報モードの切り替えは、ＩＮスレーブ２′側で行う。つまり、どのモードで送るかの条件も予め登録しておき、係る条件に従い現在の状態からどちらのモードで送るかを決定し、その決定したモードに対応する通知フレームを作成し送信することになる。そして、係る条件としては、例えば、通常は結果通知モードとし、結果通知フレームを所定回数送信すると、詳細情報モードで送信するようにすることかできる。また、そのとき抽象した情報に基づいてモードを決定することができる。
また、係るモードの切り替えを、ＯＵＴスレーブ側からの命令に従って行うこともできる。すなわち、図１４に示すように、通常はＩＮスレーブ２′は、トリガ発生に伴い結果通知フレームを生成し、送信する。この結果通知フレームに対して、受信したＯＵＴスレーブ２″がＡＣＫを返すことになるが、ＡＣＫフレームにモード指示フラグを含ませ、そのモード指示フラグが詳細モードへの切り替えを指示するものの場合、それ以降は詳細情報フレームを送信することになる。このモード指示フラグを含むＡＣＫフレームとしては、図１５に示すような構造を採ることができる。この例では、モード指示フラグとして「安全フラグ」を用意し、安全フラグが１の場合は結果通知リクエストを意味し（図１５（ａ）参照）、安全フラグが０の場合は詳細情報通知リクエストを意味する（図１５（ｂ）参照）。
次に、上記した各手続を行うための各スレーブのＭＰＵの具体的な処理機能について説明する。まず、図１２に示した外部トリガに基づく安全情報の送信を行う場合のＯＵＴスレーブ２″のＭＰＵの機能は、図１６に示すフローチャートのようになる。つまり、基本的には、第１の実施の形態におけるマスタ１の処理機能と同様で、さらに、ＡＣＫの送信処理ステップを追加した構成となる。
すなわち、本実施の形態でも、前提として、現在の状態を示す安全フラグを持つ。安全フラグ＝０の場合には、安全ネットワークシステムが危険状態（少なくとも１つの安全機器が危険状態）となっていることを意味し、安全ＰＬＣ（マスタ）１は、安全出力を強制ＯＦＦする。また、安全フラグ＝１の場合には、安全ネットワークシステムが安全状態（全ての安全機器が安全状態）となっていることを意味し、安全ＰＬＣ（マスタ）１は、Ｉ／Ｏリフレッシュ可能となる。そして、この安全フラグは、安仝ＰＬＣ１のＭＰＵが更新する。
上記した前提の基に、ＭＰＵは、以下のように動作する。すなわち、まず安全フラグが「１」であるか否かを判断する（ＳＴ２１）。そして、「１」であれば、安全状態にありシステムは正常に動作しているので、異常時（危険）に備えてＩＮスレーブ２′に対して結果通知要求コマンドを送信する（ＳＴ２２）。
その後、ＩＮスレーブ２′からの安全応答（レスポンス）の受信を待ち（ＳＴ２４）、正常に受信した場合には、受信した安全情報が安全か否かを判断する（ＳＴ２５）。そして、安全の場合には、安全フラグを１にセットする（ＳＴ２６）。一方、安全応答を正常に受信できない場合（ステップ２４でＮｏ）や、受信した安全情報の内容が危険の場合には、ネットワーク以上フラグを１２セットするとともに、安全フラグを「０」にする（ＳＴ２７）。
なお、ステップ２４の分岐判断でＮｏとなる「安全応答を正常に受信できない場合」としては、▲１▼ノイズなどで通信エラー，▲２▼送信側か受信側かの通信エラー（復帰可のもの），▲３▼回線が外れたたり切れたりした，▲４▼スレーブの送信機能が故障，▲５▼マスタ（安全ＰＬＣ）の受信機能の故障などがある。そして、上記した▲１▼，▲２▼の場合には、次以降の通信サイクルの際に安全応答を正常に受信し、通信が続行することができるが、▲３▼▲４▼▲５▼の場合は通信自体が不能になるので、安全ＰＬＣは、何れのモードの安全応答も受信できなくなる。
また、ステップ１の分岐判断でＮｏの場合には、既に前回以前の通信サイクルで、異常（危険）になりステップ７を経て安全フラグが「０」に更新されているので、ＩＮスレーブ２′に対して詳細情報コマンドを送信し（ＳＴ２３）、各安全機器ごとの安全情報の収集を図る。そして、ステップ２６或いはステップ２７の安全フラグの登録を行った後、ＩＮスレーブ２′に対してＡＣＫを返す。そして、上記した処理を繰り返し実行する。
また、図１４に示すようなＩＮスレーブ２′が内部トリガに基づいて安全情報を送信し、モードの切り替えはＯＵＴスレーブが行う場合のＯＵＴスレーブ２″のＭＰＵの処理機能としては、図１７に示すフローチャートのようになる。すなわち、まずＩＮスレーブからの安全情報の通知フレームを正常に受信した可否かを判断する（ＳＴ３１）。そして、正常に受信したならば、送られてきた安全情報の内容が、「安全」である可否かを判断する（ＳＴ３２）。安全の場合には、安全フラグを１にセットし、安全でない場合にはネットワーク以上フラグを１２セットするとともに、安全フラグを０にセットする（ＳＴ３４）。なお、フレームを正常に受信できなかった場合（ステップ３１の分岐判断でＮＯ）にも、このステップ３４の処理を実行する。
そして、ステップ３３或いはステップ３４の安全フラグの登録を行った後、ＡＣＫフレームに安全フラグをセットする。これにより、図１５に示すいずれかのＡＣＫフレームが生成される。次いで、ＩＮスレーブ２′に対して安全フラグ付きのＡＣＫを返す（ＳＴ３６）。そして、上記した処理を繰り返し実行する。
なお、具体的なフローチャートの記載は省略するが、図１３に示すようなＩＮスレーブ２′が内部トリガに基づいて安全情報を送信し、しかも、モードの切り替えもＩＮスレーブが行う場合のＯＵＴスレーブ２″のＭＰＵの処理機能としては、以下のようになる。つまり、まず、ＩＮスレーブからの安全情報の通知フレームの受信処理をする。次いで、正常に受信できたならば、ＩＮスレーブに対してＡＣＫを送信する。そして、上記した処理を繰り返し実行する。
また、上記した各例において、ＯＵＴスレーブ２″はＩＮスレーブ２′から「安全でない（危険）」という安全情報を受信した場合、出力機器を停止するなどの所望のフェイルセーフ処理を行う。このように、マスタを介すことなく、直接ＩＮスレーブから安全情報を入手できるので、安全情報の入手が早期に行える。よって、異常が発生してからフェイルセーフが働くまでの時間を短くすることができる。
一方、ＩＮスレーブ２′側のＭＰＵ２３の機能は、図１８に示すフローチャートを実行するようになっている。このフローチャートは、図１２から図１４に示す何れのタイプにも適用できるものである。
まず、送信条件になった可否かを判断する（ＳＴ４１）。外部トリガの場合には、例えば、ＯＵＴスレーブから入力要求コマンドを受信した場合に送信条件になったと判断される。また、内部トリガの場合、内部タイマがタイムアップした場合や条件イベントが発生した場合などが、送信条件になったと判断できる。
送信条件になるのを待ち、送信条件になったならば、結果通知モードか否かを判断する（ＳＴ４２）。この判断は、例えば、安全フラグが１か否かにより判断することができる。そして、結果通知モードの場合には、安全Ｉ／Ｏ入力の演算結果（２ビット）を送信バッファにセットする（ＳＴ４３）。一方、詳細情報モードの場合には、演算前の安全Ｉ／Ｏ入力（２バイト）を送信バッファにセットする（ＳＴ４５，４６）。なお、何れのモードでもない場合には、ステップ４１に戻り、次の送信条件になるのを待つ。
ステップ４３或いはステップ４６を実行して送信バッファに安全情報をセットした後、係る安全情報をＯＵＴスレーブに向けて送信する（ＳＴ４４）。上記した要にＯＵＴスレーブからは、安全情報が受信されるとＡＣＫが返送されてくるので、係るＡＣＫを受信した可否かを判断する（ＳＴ４７）。そして、ＡＣＫを受信した場合には、ステップ４１に戻り、次の送信条件になるのを待つ。また、ＡＣＫを受信しない場合に、所定の異常処理を行う（ＳＴ４８）。
なお、本実施形態では、ＩＮスレーブからＯＵＴスレーブに安全情報を送信する例を示したが、マスタ以外の他のノードに送る場合の組み合わせはこれに限ることはなく任意である。
さらに、上記した各実施の形態は、単独で実施しても良いし、複数の実施の形態を組み合わせて実施することもできる。一例としては、あるＩＮスレーブは、通常はマスタースレーブで通信を行いながら、イベント的にＯＵＴスレーブへ安全情報を送信することもできる。
産業上の利用可能性
本発明によれば、安全スレーブは、複数の安全入力情報に基づき安全条件を満足するかの判断を行い、その判断して得られた安全判断結果を安全応答として安全コントローラに返すようにしたので、安全機器（安全スレーブ）の安全か否かの情報を、迅速にマスタ（安全コントローラ）その他の装置に送信することができ、異常（危険）状態になった場合には、早急にフェイルセーフを実行することができる。
【図面の簡単な説明】
図１は、本発明に係る安全ネットワークシステムの第１の実施の形態を示す図である。
図２は、本発明に係る第１の実施の形態における安全スレーブを示す図である。
図３は、送信フレームの具体的なデータ構造の一例を示す図である。
図４は、マスタースレーブ間のフレームの送信タイミングの一例を示す図である。
図５は、安全ＰＬＣ側のＭＰＵの機能を示すフローチャートである。
図６は、安全スレーブ側のＭＰＵの機能を示すフローチャートである。
図７は、本発明の第２の実施の形態の要部となる送信フレームの具体的なデータ構造の一例を示す図である。
図８は、本発明に係る安全ネットワークシステムの第３の実施の形態を示す図である。
図９は、マスタースレーブ間のフレームの送信タイミングの一例を示す図である。
図１０は、本発明に係る安全ネットワークシステムの第４の実施の形態を示す図である。
図１１は、本発明に係る第４の実施の形態における安全スレーブを示す図である。
図１２は、ＩＮスレーブ−ＯＵＴスレーブ間のフレームの送信タイミングの一例を示す図である。
図１３は、ＩＮスレーブ−ＯＵＴスレーブ間のフレームの送信タイミングの別の例を示す図である。
図１４は、ＩＮスレーブ−ＯＵＴスレーブ間のフレームの送信タイミングの別の例を示す図である。
図１５は、ＩＮスレーブが内部トリガをかける場合のＯＵＴスレーブから出力されるＡＣＫフレームのデータ構造の一例を示す図である。
図１６は、ＯＵＴスレーブがトリガをかける場合のＯＵＴスレーブの機能を説明するフローチャートである。
図１７は、ＩＮスレーブがトリガをかける場合のＯＵＴスレーブの機能を説明するフローチャートである。
図１８は、ＩＮスレーブの機能を説明するフローチャートである。

Claims (11)

1. 安全ネットワークに接続可能であり、前記安全ネットワークを介して送られてきた安全コントローラからの要求に応じて、自己が管理する複数の安全入力情報に基づく情報を送信する安全スレーブであって、
   前記複数の安全入力情報に基づき安全条件を満足するかの判断を行う安全判断手段と、
   その安全判断手段により判断された安全判断結果を前記情報として送信する手段を備えたことを特徴とする安全スレーブ。
2. 前記複数の安全入力情報を、データの集合としてそのまま前記情報として通知する機能を備えたことを特徴とする請求の範囲第１項に記載のスレーブ。
3. 自己或いは自己が管理する機器の少なくとも一方の危険原因を検出するとともに、その検出した前記危険原因を前記情報に付加して送信する機能を備えたことを特徴とする請求の範囲第１項または第２項に記載の安全スレーブ。
4. 前記安全スレーブは、異種フィールドバスを接続する安全ゲートウェイであることを特徴とする請求の範囲第１項から第３項の何れか１項に記載の安全スレーブ。
5. 前記安全入力情報は、前記安全ゲートウェイに接続された複数の他の安全スレーブからの安全入力情報であり、
   前記安全ゲートウェイは、取得した前記複数の安全入力情報を所定の単位ごとに時分割で送信可能としたことを特徴とする請求の範囲第４項に記載の安全スレーブ。
6. 前記安全スレーブは、少なくとも前記安全判断結果を送る結果通知モードと、
   前記結果通知モードと異なり、より詳しい情報を送信する詳細情報モードで送信可能とし、
   前記送信するモードの切り替えは、前記安全コントローラからの通信コマンドに基づいて選択実行されるようにしたことを特徴とする請求の範囲第２項から第５項の何れか１項に記載の安全スレーブ。
7. 前記安全スレーブは、少なくとも前記安全判断結果を送る結果通知モードと、
   前記結果通知モードと異なり、より詳しい情報を送信する詳細情報モードで送信可能とし、
   前記送信するモードの切り替えを行う設定スイッチ手段を備えたことを特徴とする請求の範囲第２項から第６項の何れか１項に記載の安全スレーブ。
8. 安全コントローラと、請求の範囲第１項から第７項の何れか１項に記載の安全スレーブとが安全ネットワークを介して接続されて構築される安全ネットワークシステムであって、
   前記安全スレーブから出力された前記情報が、前記安全ネットワークを介して前記安全コントローラへ送信されることを特徴とする安全ネットワークシステム。
9. 安全ネットワークに接続され、請求の範囲第２項から第７項の何れか１項に記載の安全スレーブとともに安全ネットワークシステムを構築可能な安全コントローラであって、
   前記安全ネットワークシステムの状態が安全状態か否かを記憶保持する状態記憶部と、
   前記状態記憶部に記憶された現在の状態が安全の場合に、前記安全スレーブに対して前記安全判断結果の送信を要求し、
   前記状態記憶部に記憶された現在の状態が安全でない場合に、前記安全スレーブに対して前記安全判断結果よりも詳しい詳細情報の送信を要求するようにしてなることを特徴する安全コントローラ。
10. 安全ネットワークに接続可能であり、自己が管理する複数の安全入力情報に基づく情報を、前記安全ネットワークに接続された他のノードへ送信する安全スレーブであって、
    前記複数の安全入力情報に基づき安全条件を満足するかの判断を行う安全判断手段と、
    その安全判断手段により判断された安全判断結果を前記情報として送信する手段を備えたことを特徴とする安全スレーブ。
11. 安全ネットワークに接続された請求の範囲第１０項に記載の安全スレーブを含む安全ネットワークシステムであって、
    前記安全スレーブから出力された前記情報が、前記安全ネットワークを介して他のノードへ送信されることを特徴とする安全ネットワークシステム。

Images