JP2007304939A - プログラマブルコントローラおよびモニタ - Google Patents

Abstract

【課題】 ファンクションブロックの異常の有無等の異常情報を外部から容易に知ることができるＰＬＣを提供することにある。
【解決手段】 ユーザプログラムを構成するファンクションブロックについて、識別子（ＦＢ番号：ｎ）の順にステータスが正常か否かを判断する。この判断は、異常なものが検出されるまで繰り返し実行される（Ｓ１−Ｓ４）。異常が検出された場合、ＰＬＣのメモリに設定されたＦＢステータスに異常反映処理（異常ビットをＯＮ）を行ない（Ｓ５）、ステータス異常の識別子と、異常内容を特定するステータスコードを保存する（Ｓ６）。これにより、外部からＰＬＣのメモリにアクセスすることで、ステータス異常の有無や、異常を生じているファンクションブロック並びにその異常要因の特定が簡単にできる。
【選択図】 図６

Description

この発明は、ファンクションブロックで記述されたユーザプログラムを実行するプログラマブルコントローラおよびモニタに関するものである。

ＦＡ（Ｆａｃｔｏｒｙ Ａｕｔｏｍａｔｉｏｎ）におけるネットワークシステムは、生産設備の制御を司るＰＬＣ（プログラマブルコントローラ）と、そのＰＬＣにより動作が制御される機器とが、制御系のネットワークに接続される。それらＰＬＣと機器は、その制御系のネットワークを介してサイクリックに通信を行なうことで、ＩＯデータの送受を行ない、生産設備を制御する。

ＰＬＣは、制御プログラムに基づいて演算実行するＣＰＵユニット、センサやスイッチなどの入力機器を接続してそれらのオン・オフ信号を入力信号として取り込む入力ユニット、アクチュエータやリレーなどの出力機器を接続してそれらに対して出力信号を送り出す出力ユニット、ネットワークに接続された他の装置とデータの送受を行なう通信ユニット、各ユニットに電源を供給する電源ユニット、などの複数のユニットを組み合わせることにより構成されている。また、各機能を１つの筐体内に実装した一体型のＰＬＣもある。

さらに最近ではＰＬＣによる制御においても、フェイルセーフ（安全）システムが導入されつつある。つまり、ＰＬＣや各機器自体はもちろん、それらを接続するネットワークも安全機能を組み込まれたもので構成される。ここで安全機能とは、例えばＣＰＵその他の各処理部等を二重化して、正しい出力をするようにしたり、ネットワーク異常（正常な通信ができない）の場合や、緊急停止スイッチが押下されたり、ライトカーテンなどのセンサが人（身体の一部）の進入を検出した場合等の、ネットワークシステムが危険状態になった場合に、フェイルセーフが働き、システムが安全側になって、動作が停止するものである。

この安全システムは、例えば図１に示すように、ＰＬＣ１と複数のスレーブ２とがネットワーク３に接続されたネットワーク構成をとる。各ＰＬＣ１，スレーブ２，ネットワーク３等のネットワークを構成する機器は二重化されている。図では、左端の入力スレーブから緊急停止スイッチ等の異常状態を検出するスイッチがＯＮになったことをネットワーク３経由でマスタであるＰＬＣ１に伝える。ＰＬＣ１は、論理演算を実行し、右端のスレーブ２に対して動作停止命令を送るべくＩＯデータとしてＯＦＦを送る。これにより、その右端のスレーブ２に接続された外部のＩＯ機器（出力装置）の動作が停止し、フェイルセーフが働くことになる。

この安全システムに対応したＰＬＣ１のユーザプログラムは、例えば、１つのファンクションブロック或いは複数のファンクションブロックの組み合わせで構築されるものがある。このようにファンクションブロックを用いて記述されたユーザプログラムを演算実行するＰＬＣとしては、特許文献１に開示されたものがある。
特開２０００−２７６５０８号公報

しかしながら、制御プログラムを構成する個々のファンクションブロックに異常が発生していると、システム全体としての異常が見られずに本来は動作すべき場合であっても、最終出力（図１の場合、右端のスレーブのＩＯ）がＯＦＦの状態となり、システムが停止する。安全システムの場合、システムのいずれかに故障・異常が発生した場合には、出力がＯＦＦになるように設計されている。このように、システムが停止した場合、その停止した原因を特定する必要があり、特に、ファンクションブロックの異常が原因の場合、原因を特定するのに手間取る。

ファンクションブロックの異常を検出する方法としては、例えば図２に示すように、各ファンクションブロックＦＢの出力として、ステータス異常チェック用端子Ｏ１を設け、複数のファンクションブロックＦＢの異常ステータスをあるポイントに出力するためには、その複数（図では２個）のファンクションブロックＦＢのステータス異常チェック用端子Ｏ１をＡＮＤ回路の入力端子と結線するようなプログラムを新たに組み必要がある。ステータス異常チェック用端子Ｏ１が、正常時はＯＮで内部でステータス異常が発生した場合にＯＦＦになるとすると、いずれかのファンクションブロックＦＢに異常が生じた場合にはＡＮＤ回路の出力端子がＯＦＦになり、エラー出力される。一方、ＡＮＤ回路の出力端子がＯＮの場合、そのＡＮＤ回路に入力されるファンクションブロックＦＢは正常に動作していることが確認できる。

しかし、係る方法をとると、検出のための新たなプログラムを組み必要がある。さらに、１つのＡＮＤ回路で多数のファンクションブロックのエラーチェックを行なうようにした場合、その多数のファンクションブロックの中で実際に問題があるものがどれかを特定するのが煩雑となる。一方の、１つのＡＮＤ回路に接続するファンクションブロックの数を少なくすれば、出力点数が多くなってしまうという問題が生じる。

一方、プログラムを実行させ、その状況をモニタリングツールにて、個々のプログラム回路の入出力をチェックすることで、異常原因を特定することもできる。しかし、この方法では、プログラム規模が大きくなると、原因特定に時間を要することとなる。

この発明の目的は、ファンクションブロックの異常の有無等の異常情報を外部から容易に知ることができるプログラマブルコントローラおよびモニタを提供することにある。

上記の目的を達成するため、本発明に係るプログラマブルコントローラは、ファンクションブロックで記述されたユーザプログラムを実行するプログラマブルコントローラであって、ユーザプログラムを構成するファンクションブロックのうちの少なくとも１つには、自己のステータス異常を定義する定義情報を保持する。そして、演算実行されたファンクションブロックの状態と定義情報とに基づきステータス異常の有無を判断する異常判定手段と、その異常判定手段の判定結果を記憶する記憶手段と、を備えた。

定義情報は、実施形態では「パラメータ情報」に対応する。「ステータス異常を定義する定義情報」は、直接的にステータス異常の条件等を定義しても良いし、正常な状態を定義することでそれ以外はステータス異常と判断できるような間接的（逆説的）なものでもよい。

ユーザプログラムが複数のファンクションブロックで構成されている場合、全てのファンクションブロックが定義情報を持つようになっていても良いし、一部のファンクションブロックのみが定義情報を持つようになっていても良い。さらに、ユーザプログラムは、ファンクションブロックのみから記述されているものでも良いし、プログラムの一部にファンクションブロックを含むものでも良い。

また、記憶手段は、ＲＡＭ１５により実現されており、外部装置からアクセスする（読み出す）ことができる。ファンクションブロックの状態は、入力や出力の値であったり、入力のタイミングなど、定義情報で規定されるステータス異常の判定のために必要な情報を得るものである。判定結果は、ステータス異常の有無である。

プログラマブルコントローラの記憶手段にファンクションブロックのステータス異常があったか否かの情報（判定結果）が記憶されるので、外部からその判定結果を取得することで、ステータス異常の有無を容易に確認できる。つまり、正常な動作をしない場合に、その原因がファンクションブロックのステータス異常に基づくものか否かを簡単に判断できるため、要因分析並びにそれに基づく修正が簡単に行なえる。

さらに本発明は、少なくとも前記定義情報を持つファンクションブロックには、他のファンクションブロックと区別するための識別情報が設定される。そして、異常判定手段で検出されたステータス異常のファンクションブロックの識別子を記憶する記憶手段を備えるとよい。識別情報は、実施形態の識別子（ＦＢ番号）に対応する。ユーザプログラムを構成する全てのファンクションブロックに識別情報を付しても良いし、定義情報もつファンクションブロックにのみ付しても良い。なお、図１０に示すフローチャートを実施する機能を備えたプログラマブルコントローラの場合、全てのファンクションブロックに識別情報を付す必要がある。ステータス異常が生じている場合、識別情報も記憶されるため、どのファンクションブロックが問題であるかが容易に特定できる。

異常判定手段は、異常の有無と共にその異常内容を併せて判断する機能を備え、記憶手段にはその異常内容と識別情報とを関連づけて格納するようにするとよい。異常内容は、実施形態ではステータスコードに対応する。このようにすると、具体的な異常内容まで外部から簡単に確認できる。

異常判定手段は、ユーザプログラムの演算実行中に判断するとよい。この発明は、図１０に示すフローチャートの実施形態により実現されている。ここで演算実行中とは、各ファンションブロックを実行する都度、その実行したファンションブロックのステータス異常の有無等の判定を行なうことを意味する。もちろん、ユーザプログラムの実行後に一括してステータス異常の有無の判断等を行なうようにしても良い。

さらに、判定結果記憶手段に格納された判定結果を含む異常情報を外部装置からアクセスすることができる（読み出すことができる）ようにするとよい。

また、本発明に係るモニタは、請求項１〜４のいずれかに記載のプログラマブルコントローラにアクセスする手段と、プログラマブルコントローラの記憶手段に格納された判定結果を含む異常情報を取得する手段と、取得した異常情報を表示する手段と、を備えるようにした。異常情報は、判定結果の他に異常内容等がある。

本発明では、プログラマブルコントローラの記憶手段をアクセスすることで、ファンクションブロックの異常の有無等の異常情報を外部から容易に知ることができる。

図３は、本発明のＰＬＣを含むネットワークシステムの一例を示している。このネットワークシステムは、フェイルセーフ（安全）システムを構成するためのものである。このネットワークシステムは、ＰＬＣ１０と複数のスレーブ２０とがネットワーク２１に接続されたネットワーク構成をとる。各ＰＬＣ１０，スレーブ２０，ネットワーク２１等のネットワークを構成する機器は二重化されている。図では、左端の入力スレーブから緊急停止スイッチ等の異常状態を検出するスイッチがＯＮになったことをネットワーク２１経由でマスタであるＰＬＣ１０に伝える。ＰＬＣ１０は、論理演算を実行し、右端のスレーブ２０に対して動作停止命令を送るべくＩＯデータとしてＯＦＦを送る。これにより、その右端のスレーブ２に接続された外部のＩＯ機器（出力装置）の動作が停止し、フェイルセーフ（セーフティ）が働くことになる。

この種のセーフティ制御システムは、セーフティコントローラ（セーフティＰＬＣ：本実施形態のＰＬＣ１０等）、セーフティＩ／Ｏターミナル（本実施形態のスレーブ２０等）を含み、切削機械や切断機械やアーム付き製造機ロボット等とともに使用される。セーフティコントローラは、一般的なプログラマブルコントローラ（ＰＬＣ）に類似するロジック演算機能、入出力制御機能に加えて、安全面の自己診断機能を内蔵させることにより、その制御において高度な安全性および信頼性を確保したものである。セーフティコントローラは、自己診断結果により異常を検出した場合には、自己の制御が危険につながらないように、強制的に安全な制御を行なうような機能（フェールセーフ機能）を備えている。セーフティＩ／Ｏターミナルにおいても、自己診断機能を有していて、自己診断結果により異常を検出した場合には自己の制御が危険につながらない制御をするといった、フェイルセーフ機能を備えている。それにより、セーフティ制御システムは、製造機ロボット等の動作が危険につながらないようにしている。

ここに言う安全は、より具体的には、規格化されている安全基準を含む意味である。安全規格には、例えばＩＥＣ６１５０８やＥＮ規格などがある。ＩＥＣ６１５０８（プログラム可能な電子システムの機能安全に関する国際電気標準委員会）では、時間あたりの危険故障確率を（失敗確率：Ｐｒｏｂａｂｉｌｉｔｙ ｏｆ Ｆａｉｌｕｒｅ ｐｅｒ Ｈｏｕｒ）を定義し、この確率によってＳＩＬのレベル（Ｓａｆｅｔｙ Ｉｎｔｅｇｒｉｔｙ Ｌｅｖｅｌ）を４段階に分類している。また、ＥＮ規格では、機械のリスクの大きさを評価し、リスク低減策を講じるように義務づけられていて、ＥＮ９５４−１では５つの安全カテゴリにて規定されている。この明細書でいうセーフティコントローラ、セーフティＩ／Ｏターミナル、セーフティ制御システム等は、このような安全基準のいずれかに対応したものである。

なお、セーフティ制御システムは「安全制御システム」と称されることもあり、セーフティコントローラは「安全コントローラ」や「安全制御装置」と称されることもある。セーフティＩ／Ｏターミナルは「セーフティスレーブ局」や「セーフティスレーブユニット」、単に「セーフティスレーブ」と称されることもあり、セーフティを「安全」と置き換えて称されることもある。

従来より、セーフティコントローラとセーフティＩ／Ｏターミナルとをネットワークで結んでなるセーフティ制御システムが知られている。セーフティコントローラは、セーフティＩ／Ｏターミナルに対してネットワーク通信する通信マスタ機能を備えている。セーフティコントローラが複数のユニット筐体（例えば、電源ユニット、ＣＰＵユニット、ＩＯユニット、通信ユニット等）を結合させてなるビルディングブロックタイプである場合には、通信マスタユニットにその通信マスタ機能が内蔵される。その通信マスタユニットは「セーフティマスタ局」、「セーフティマスタユニット」や「セーフティマスタ」と称されることもあり、セーフティを「安全」と置き換えて称されることもある。

セーフティＩ／Ｏターミナルは、セーフティコントローラの通信マスタ機能との間でネットワーク通信機能、つまり、通信スレーブ機能を備えている。セーフティＩ／Ｏターミナルは接続端子を備えていて、その接続端子に、オン・オフ信号を出すスイッチ等の入力機器と、制御信号の出力先となる出力機器との少なくとも一方が接続されている。入力機器の例は、非常停止スイッチ、ライトカーテン、ドアスイッチ、２ハンドスイッチなどである。出力機器の例は、セーフティリレーやコンタクタである。これらの入力機器または出力機器も安全規格に対応している。セーフティＩ／Ｏターミナルは、接続された安全用途機器から入力した信号に基づいて制御データを生成し、生成した制御データをセーフティコントローラへネットワーク通信する。

セーフティコントローラがビルディングブロックタイプのものであれば、各ユニットは、共通内部バスに接続され、セーフティコントローラ全体の制御を司るＣＰＵユニットとの間でバス通信をし、データをやり取りする。連結されたＩ／Ｏユニットも接続端子を備えていて、その接続端子に、安全用途の入力機器または安全用途の出力機器が接続されている。そして、セーフティコントローラは、通信マスタユニットを介してセーフティＩ／Ｏターミナルからネットワーク通信により入力した入力機器の入力信号、または連結されたＩ／Ｏユニットに接続された入力機器の入力信号を入力し、予め記憶されたロジックプログラムによってその入力信号のオン・オフを論理演算する。その演算結果に基づく出力信号を、通信マスタユニットを介してネットワーク通信によりセーフティＩ／Ｏターミナルへ出力するか、または連結されたＩ／Ｏユニットへ出力をする。Ｉ／Ｏユニット及びセーフティＩ／Ｏターミナルは、その出力信号を出力機器へ出力する。この一連の動作を繰り返し実行することにより、セーフティコントローラにより製造機ロボットを含むシステム全体が制御される。

なお、セーフティコントローラとセーフティＩ／Ｏターミナルとの間の通信サイクルは、セーフティコントローラの繰り返し実行のサイクルと同期していてもよいし、非同期でもよい。また、セーフティコントローラあるいはＣＰＵユニットにおけるロジック演算処理の対象となるロジックプログラムは、プログラマーにより予め作成される。作成する際のプログラミング記述については、例えば、ラダー表記、ニーモニック表記、ファンクションブロック表記であってもよい。プログラミング言語でいうと、インタプリタ型言語、スクリプト言語、アセンブリ言語、高級言語、Ｊａｖａ言語と呼ばれるものであってもよい。このようなプログラミング言語で書かれたソースコードを、アセンブルやコンパイルなどの処理を行ってＣＰＵに実行させる。

また、セーフティＩ／Ｏターミナルに接続された出力機器であるところのセーフティリレーやコンタクタは、製造機ロボットや加工機械、切断機械等につながれていて、リレーやコンタクタの接点がオン中は製造機ロボット等が動作し、接点がオフ中は製造機ロボット等が停止するようになっている。よって、セーフティコントローラは、出力機器をオン・オフ制御することで、最終的な制御対象の操作ロボット等の動作停止に関する制御をする。具体的な例をいうと、セーフティコントローラは、非常停止スイッチが正常に操作されたことをセーフティＩ／Ｏターミナルから通信にて入力されると、制御対象が危険な動作をしないように出力機器（リレーやコンタクタ）をオフするか、安全側の状態に強制制御し、直ちに必要な安全処置を採る。セーフティコントローラは、非常停止スイッチまたは他の入力機器が異常有りの診断結果が入力されると、非常停止スイッチの操作有無または入力機器のオン・オフ状態にかかわらずに、制御対象が危険な動作をしないようにその動作を停止するよう出力機器をオフするか、安全側の状態に強制制御し、直ちに必要な安全処置を採る。

図４は、ＰＬＣ１０の内部構造の一部を示している。このＰＬＣ１０は、ＭＰＵ１２が、システムＲＯＭ１３に格納されたプログラム、さらにはユーザプログラム記憶部１４に格納されたユーザプログラムを読み出し、システムＲＡＭ１５のメモリ領域を適宜使用してそのユーザプログラムを演算実行する。ＭＰＵ１２の演算実行結果は、ＩＯメモリ１６に格納される。このＩＯメモリ１６に格納されたＩＯデータは、図示省略する通信手段により、マスタ−スレーブ間通信が行なわれ、スレーブとの間でデータ交換される。

このＰＬＣ１０は、安全システム用のものであり、ユーザプログラムはファンクションブロックにより記述されている。ファンクションブロックは、所定の機能を実現するプログラムと、パラメータ情報と、を備えている。パラメータ情報は、そのファンクションブロックがステータス異常か否かを判断するための情報であり、例えば、入力値の取り得る組み合わせや、入力値と出力値の取り得る組み合わせや、異なる入力端子に同じ値が一定時間遅れて入力されるような場合にその遅れ時間（ディレイタイム）等がある。

このパラメータ情報と実際のファンクションブロックの動作状況とを比較することで、ステータス異常か否かを判断することができる。例えば、２入力のファンクションブロックにおいて、“２つの入力値が異なる”というパラメータ情報が記憶されている場合に、２つの入力値が“１，１”や“０，０”のように同値をなっている場合にはステータス異常を生じていると判断できる。

また、各ファンクションブロックは、そのプログラム中で一意に特定するための識別情報たる識別子（ＦＢ番号）がそれぞれに設定されている。このＦＢ番号は、本実施形態ではプログラムの実行順に付与している（図５参照）。

図６は、本発明の一実施の形態を示すフローチャートである。ＭＰＵ１２は、図５に示すファンクションブロック異常ステータス生成処理を実行する機能を有する。この処理は、定期的に行なうようにしても良いし、イベントに従って実行するようにしてもよい。

まず、チェック対象のユーザプログラムを構成するファンクションブロックの使用数をＮにセットするとともに、現在のチェック対象のファンクションブロックの識別子（ＦＢ番号）ｎを１にセットする（Ｓ１）。

次いで、ｎがＮよりも大きいか否かを判断し（Ｓ２）、Ｎ以下の場合には処理対象のファンクションブロックが存在するので、処理ステップ３に飛び、ステータスが正常か否かを判断する（Ｓ３）。この判断は、ＦＢ番号＝ｎのファンクションブロックに格納されたパラメータ情報を取得するとともに、ファンクションブロックの状態がそのパラメータ情報で規定されているステータスの通りか否かを判断する。

正常な場合（Ｓ３の分岐判断がＹｅｓ）には、ｎを１インクリメントし（Ｓ４）、処理ステップＳ２に戻り、次のＦＢ番号のファンクションブロックについての判断を行なう。一方、ＦＢ番号＝ｎのファンクションブロックにステータス異常が生じている場合、処理ステップＳ３の分岐判断はＮｏとなるので、ＰＬＣのメモリ（例えばＲＡＭ１５）に割り当てられたＦＢステータスに異常反映処理をする（Ｓ５）。すなわち、デバイスの情報を記憶するＧｅｎｅｒａｌステータスの異常ビットをＯＮにする。

そして、ＲＡＭ１５の所定エリアに、図７に示すようなステータス異常のファンクションブロックの識別子（ＦＢ番号＝ｎ）と、ステータスコードと、を保存する（Ｓ６）。ステータスコードは、ステータス異常の種類を特定するもので、本実施形態では、論理異常と、入力タイミング異常等がある。このＦＢ番号とステータスコードの保存処理の実行後、処理を終了する。つまり、この実施形態によれば、ファンクションブロックをＦＢ番号の順に先頭から１つずつステータス異常の有無のチェックをし、異常があった場合にはその検出したファンクションブロックについてのステータスコードを保存し、そこで処理を終了する。

一方、全てのファンクションブロックのステータスが正常な場合、Ｎ番目のファンクションブロックを実行後にｎがインクリメントされてｎ＝Ｎ＋１となるので、処理ステップＳ２の分岐判断でＹｅｓとなり、処理ステップＳ７に飛び、ＦＢステータスに正常反映処理をする（Ｓ７）。すなわち、デバイスの情報を記憶するＧｅｎｅｒａｌステータスの異常ビットをＯＦＦにする。これにより、今回の一連の処理を終了する。

よって、本実施形態では、ファンクションブロックにステータス異常が発生している場合、ＦＢステータスにＦＢ番号とステータスコードが格納されているため、例えばネットワーク２１に接続された監視モニタ（ＰＴ）２２で確認することで、異常箇所を容易に特定できる。つまり、そのステータスをメッセージ通信やＩ／Ｏ通信にて読み出すことを可能とし、ファンクションブロックに識別子を持たせ、外部からその識別子を読み出すことによって、異常発生中のファンクションブロックを特定することができる。この方法によると、ステータス異常の詳細情報を作り出すためのユーザプログラムを必要としないと言うメリットがある。またファンクションのステータス情報を外部機器から読み出し可能としているので、監視機器からモニタリングすることで、異常検出が容易となる。

なお、本実施形態の場合、仮に複数のファンクションブロックでステータス異常を生じている場合、その複数のファンクションブロックのうち、ＦＢ番号の最も小さいファンクションブロックについての情報（ＦＢ番号とステータスコード）のみが記録される。

図８は、別の実施形態を示している。本実施の形態では、ステータス異常のファンクションブロックを検出しても処理を停止せず、全てのファンクションブロックについてのステータスチェックを行ない、その結果を記録するようにしている。

まず、初期処理として、Ｎ＝ファンクションブロックの使用数，ｎ＝１，ＦＢステータス異常検出フラグ＝ＯＦＦにするとともに、ステータス異常のファンクションブロックの識別子（ＦＢ番号）をクリアする（Ｓ１０）。

次いで、ｎがＮよりも大きいか否かを判断し（Ｓ１１）、Ｎ以下の場合には処理対象のファンクションブロックが存在するので、処理ステップ１２に飛び、ステータスが正常か否かを判断する（Ｓ１２）。正常な場合（Ｓ１２の分岐判断がＹｅｓ）には、ｎを１インクリメントし（Ｓ１８）、処理ステップＳ１１に戻り、次のＦＢ番号のファンクションブロックについての判断を行なう。一方、ＦＢ番号＝ｎのファンクションブロックにステータス異常が生じている場合、処理ステップＳ１２の分岐判断はＮｏとなるので、処理ステップＳ１３に飛び、ＦＢステータス異常検出フラグをＯＮにする（Ｓ１３）。このフラグは、ソフトウェア上のバッファに設定しても良いし、ＲＡＭ１５その他の記憶手段に設定しても良い。そして、ＲＡＭ１５の所定エリアに、ステータス異常のファンクションブロックの識別子（ＦＢ番号＝ｎ）と、ステータスコードと、を保存する（Ｓ１４）。その後、処理ステップＳ１８に進みｎを１インクリメントし、次のＦＢ番号のファンクションブロックに対する処理を行なう。

上記の処理を、ＦＢ番号の１番から順に全てのファンクションブロックについて実行することにより、ステータス異常のファンクションブロックが少なくとも１つ存在すると、ＦＢステータス異常検出フラグはＯＮになる（全てのファンクションブロックが正常の場合には、そのフラグはＯＦＦとなる）。さらに、ステータス異常のファンクションブロックが複数存在する場合には、その全てのファンクションブロックについてのＦＢ番号とステータスコードが保存される。このステータス異常のＦＢ番号とステータスコードを保存する際のデータ構造は、図９（ａ）に示すように、該当するステータス異常のファンクションブロックのＦＢ番号とステータスコードのみを記憶するテーブル形式としても良いし、図９（ｂ）に示すようにＦＢ番号のビットマップイメージ（異常＝１，正常＝０）としても良い。

そして、全てのファンクションブロックについてのステータスのチェック等の処理が終了すると、処理ステップＳ１１の分岐判断でＹｅｓとなり、処理ステップＳ１５に飛び、ＦＢステータス異常検出フラグがＯＮか否かを判断する（Ｓ１５）。そして、ＯＮの場合には、ＦＢステータスに異常反映処理を実行し（Ｓ１６）、フラグがＯＦＦの場合にはＦＢステータスに正常反映処理を実行する（Ｓ１７）。

図１０は、さらに別の実施形態を示している。本実施の形態では、通常のファンクションブロックに基づく演算処理を実行中にステータス異常の判断をし、その結果の反映処理をする。本実施形態では、ＦＢ番号は、プログラムの演算実行順に設定する。

まず、初期処理として、Ｎ＝ファンクションブロックの使用数，n＝１，ＦＢステータス異常検出フラグ＝ＯＦＦにする（Ｓ２１）。次いで、ｎがＮよりも大きいか否かを判断し（Ｓ２２）、Ｎ以下の場合には未処理のファンクションブロックが存在するので、処理ステップ２３に飛び、ＦＢ番号がｎ番のファンクションブロックの演算処理（論理演算）を実行する（Ｓ２３）。この処理ステップＳ２３の演算実行に伴い、入力値や出力値の論理の異常や、入力タイミングの異常の有無を判断する。そして、ＲＡＭ１５に設定されたワークメモリには、図１１（ａ）に示すように、各ファンクションブロックについてのデータが格納されるようになっているので、その判断結果（ステータス異常の有無）を、各ファンクションブロックのデータエリア中の所定アドレス（ＦＢ異常ステータスの記憶領域）に格納（１／０）する。

次いで、上記の所定アドレスをアクセスしてＦＢステータスが正常か否かを判断し（Ｓ２４）、異常の場合にはＦＢステータス異常検出フラグをＯＮにする（Ｓ２５）。この後、或いはＦＢステータスが正常な場合に、ｎを１インクリメントし（Ｓ２６）、処理ステップＳ２２に戻り、次のＦＢ番号のファンクションブロックに対する処理を行なう。

そして、全てのファンクションブロックについての演算実行が終了すると、処理ステップＳ２２の分岐判断でＹｅｓとなり、処理ステップＳ２７に飛び、ＦＢステータス異常検出フラグがＯＮか否かを判断する（Ｓ２７）。そして、ＯＮの場合には、ＦＢステータスに異常反映処理を実行し（Ｓ２８）、フラグがＯＦＦの場合にはＦＢステータスに正常反映処理を実行する（Ｓ２９）。これらの反映処理は、図１１（ｂ）に示すＧｅｎｅｒａｌステータスに設定されたエラー発生ビットをＯＮ／ＯＦＦするものである。

なお、図６，図８のフローチャートにおけるステータス異常の有無のチェックは、そのチェックの処理ステップを実行の際にパラメータ等に基づいて比較するのではなく、上述したようにファンクションの演算実行の際に予めステータス異常の判断も行ない、内部ワークエリアのＦＢ異常ステータスの格納領域にその判断結果を格納しておくようにし、その格納領域にアクセスすることで上記のステータス異常の有無のチェックを行なうようにしてもよい。

図１２は、監視モニタ２２の機能の一例を示すフローチャートである。監視モニタ２２は、ＰＬＣ１０にアクセスし、ＦＢステータス異常があったか否かを判断する（Ｓ３１）。この判断は、Ｇｅｎｅｒａｌステータスの該当ビットのＯＮ／ＯＦＦを確認することで実行できる。異常がない場合（ＯＦＦ）には、処理を終了し、異常がある場合（ＯＮ）にはＲＡＭ１５に格納されたステータス異常を生じているファンクションブロックのＦＢ番号を読み出すとともに（Ｓ３２）、ステータスコードを読み出す（Ｓ３３）。そして、読み出した内容をモニタ画面に表示する（Ｓ３４）。このとき、ＰＬＣが図８のフローチャートを実行するもの場合、異常を生じているファンクションブロックが複数存在することがあるが、係る場合には、全ての情報を取得し、所定の画面レイアウトに従って適宜異常情報を表示する。さらに、好ましくは、該当するファンクションブロックの入力のＯＮ／ＯＦＦの状態を表示する（Ｓ３５）。

ユーザは、係る表示された内容を見て、ステータス異常を生じている原因を探し、その異常要因を除去した後、再度ＰＬＣを動作させてファンクションブロックのステータス異常が無くなる（正常動作する）ことを確認する。

このようにすることで、仮に図６のフローチャートのように、１つのファンクションブロックについての異常情報のみ記憶される場合でも、異常停止した際に、図６，図１２のフローチャートを順次実行することで異常要因を逐次解消でき、最終的に全てのファンクションブロックがステータス異常のない状態にすることがスムーズに行える。

監視モニタ２２は、図示するようにネットワーク２１を介してＰＬＣ１０にアクセスするものに限ることはなく、ＰＬＣに直接接続するようにしても良い。また、単なるモニタではなく、ＰＬＣに対する設定ツールとすることもできる。設定ツールの場合、モニタリングしつつ、異常要因の除去のための処理（プログラムの編集等）を行える。

従来例を示す図である。 従来の問題点を説明する図である。 本発明が適用されるネットワークシステムの一例を示す図である。 ＰＬＣの内部構成を示すブロック図である。 ファンクションブロックにより構成されるユーザプログラムの一例である。 マスタのＦＢ異常ステータス生成処理機能を示すフローチャートである。 異常情報を格納するデータ構造の一例である。 マスタのＦＢ異常ステータス生成処理機能を示すフローチャートである。 異常情報を格納するデータ構造の一例である。 マスタのＦＢ異常ステータス生成処理機能を示すフローチャートである。 異常情報を格納するデータ構造の一例である。 監視モニタの機能を示すフローチャートである。

符号の説明

１０ ＰＬＣ
２０ スレーブ
２１ ネットワーク
２２ 監視モニタ

Claims (6)

1. ファンクションブロックで記述されたユーザプログラムを実行するプログラマブルコントローラであって、
   ユーザプログラムを構成するファンクションブロックのうちの少なくとも１つには、自己のステータス異常を定義する定義情報を保持し、
   演算実行されたファンクションブロックの状態と、前記定義情報と、に基づきステータス異常の有無を判断する異常判定手段と、
   その異常判定手段の判定結果を記憶する判定結果記憶手段と、
   を備えたことを特徴とするプログラマブルコントローラ。
2. 少なくとも前記定義情報を持つファンクションブロックには、他のファンクションブロックと区別するための識別情報が設定されるものであり、
   前記異常判定手段で検出されたステータス異常のファンクションブロックの識別子を記憶する記憶手段を備えたことを特徴とする請求項１に記載のプログラマブルコントローラ。
3. 前記異常判定手段は、異常の有無と共にその異常内容を併せて判断する機能を備え、
   前記記憶手段にはその異常内容と識別情報とを関連づけて格納するようにしたことを特徴とする請求項１または２に記載のプログラマブルコントローラ。
4. 前記異常判定手段は、前記ユーザプログラムの演算実行中に判断するものであることを特徴とする請求項１から３のいずれか１項に記載のプログラマブルコントローラ。
5. 前記判定結果記憶手段に格納された判定結果を含む異常情報を外部装置からアクセスすることができる、請求項１から３のいずれか１項に記載のプログラマブルコントローラ。
6. 請求項１〜４のいずれかに記載のプログラマブルコントローラにアクセスする手段と、
   プログラマブルコントローラの判定結果記憶手段に格納された判定結果を含む異常情報を取得する手段と、
   取得した異常情報を表示する手段と、
   を備えたことを特徴とするモニタ。
   

Images