JP3770366B2 - 制御プログラムの開発環境装置、制御プログラムを実行する制御装置、並びに、それらを実現するプログラムの記録媒体 - Google Patents
制御プログラムの開発環境装置、制御プログラムを実行する制御装置、並びに、それらを実現するプログラムの記録媒体 Download PDFInfo
- Publication number
- JP3770366B2 JP3770366B2 JP10329099A JP10329099A JP3770366B2 JP 3770366 B2 JP3770366 B2 JP 3770366B2 JP 10329099 A JP10329099 A JP 10329099A JP 10329099 A JP10329099 A JP 10329099A JP 3770366 B2 JP3770366 B2 JP 3770366B2
- Authority
- JP
- Japan
- Prior art keywords
- control
- task
- event
- control group
- program
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、制御グループを単位として異常処理、状態遷移処理を行うことにより、システムの正当性、モジュール性を向上させた制御装置に関する。
【０００２】
【従来の技術】
制御装置の設計において、制御中の異常時にどのように対応するかに関しては、従来より様々な考え方が存在する。
【０００３】
例えば、制御装置とコミュニケーションするデバイスが複数存在するような制御システムにおいては、１つのデバイスで異常が発生した場合に、それとコミュニケーションする制御装置の側を運転停止状態あるいは運転継続状態のいずれにするかに関しては、予めシステムで固定化しておくか、あるいは、プログラム作成時にファイル等でパラメータライズ化可能とする異常時対応方式（１）が採用される。
【０００４】
また、１つの制御装置で複数の制御対象を制御し、複数の制御対象に対するプログラムを１つあるいは複数のタスクで記述しているような制御システムにおいては、あるタスクで０除算等の命令実行異常が発生した場合には、制御装置で実行している全てのタスクを強制的に停止させるか、あるいは構わず運転を継続させると言った二者択一の異常時対応方式（２）が採用されている。
【０００５】
また、制御システムによっては、外部機器からの命令によって運転状態から運転停止状態にする等、制御装置全体の状態を一括して変更する異常時対応方式（３）も採用されている。
【０００６】
また、制御システムによっては、制御装置の起動時、終了時、異常時にそれぞれ特定の処理を実行するようにプログラムしておき、それらの処理の中で複数の制御対象に固有の必要な処理、システム全体に関わる処理をユーザが任意に記述できるようにした異常時対応方式（４）も採用されている。
【０００７】
さらに、制御システムによっては、複数の制御対象を制御する場合、個々の制御対象の異常に容易に対応できるように、複数の制御装置で制御を行う異常対応方式（５）も採用されている。
【０００８】
【発明が解決しようとする課題】
しかしながら、上述の異常時対応方式（１）にあっては、あるデバイスで異常が発生した場合に、制御装置全体を運転停止させるような処理を設定すると、他の制御対象を制御しているデバイスが正常であるにも拘わらず、システム全体が停止してしまう。制御対象間の関係が粗なシステムでは、このような一括停止処理は適さない。逆に、いずれのデバイスで異常が発生しても、制御装置全体の運転が継続されるような処理を設定すると、制御対象間が密なシステムでは、システム全体として整合のとれた制御を行なうことができない。
【０００９】
上述の異常時対応方式（２）にあっては、ある制御対象を制御するためのタスクが複数存在する場合、それらのタスクのうち、ある１つのタスクで命令実行異常が発生した場合に、制御装置の運転を継続させるとその制御対象に対する制御が整合性のとれたものにならない。一方、あるタスクで異常が発生した場合に、システム全体の運転を停止させてしまうと、制御対象間で粗な関係のシステムでは、粗な関係にある制御対象に対する制御まで（正常に動作しているにも拘わらず）停止してしまう。
【００１０】
上述の異常時対応方式（３）にあっては、複数の制御対象を制御するシステムにおいて、システムをデバッグ（シミュレーション）する際に、特定の制御対象に対する処理だけを実行させてデバッグを行い、次に別の制御対象について同様にしてデバッグを行うと言った手順、あるいは、ＡとＢという制御対象に関する処理だけを実行させてデバッグを行うと言った手順でBuild Up式のデバッグができないため、プログラム開発時にどこに不具合が存在するかを特定することが困難である。また、運転中の制御装置においてある制御対象に関して異常が発生した場合に、その制御対象に対する処理だけを停止し、その制御対象だけに終了処理を実行することはできない。
【００１１】
上述の異常時対応方式（４）にあっては、制御装置の起動時、終了時などに１つのタスクにすべての制御対象に関する処理、終了処理を記述していた場合、ある制御対象で異常が発生してその制御対象に対する制御処理を行なう必要がないにも拘わらず、起動処理、終了処理が実行されてしまう。また、１つのタスクにすべての制御対象に対する処理を記述した場合、制御対象に対する処理の順番に依存性がある場合で順番を変更しようとした場合、プログラムの記述を大幅に変更する必要が生じる。
【００１２】
上述の異常時対応方式（５）にあっては、複数の制御装置で複数の制御対象を制御している場合、シミュレーション、デバッグは、各制御装置個々で行っているため、複数の制御装置でシステムの動きが分かるようなシステムの場合、全体の動作検証を１つの環境で行うことが困難である。
【００１３】
この発明は、上述の問題点に着目してなされたものであり、周期タスク、イベントタスク、リフレッシュブロックといった処理の単位を１つの制御グループとして定義すると共に、この複数の制御グループを１つの環境で実行し、制御グループ毎に最適な異常処理、状態遷移時の処理を実現することにより、デバッグ効率の向上、システムカスタマイズ性の向上、プログラミング容易性、制御の独立性を確保することを目的とする。
【００１４】
【課題を解決するための手段】
この出願の請求項１に記載の発明は、タスクプライオリティ、周期、実行開始サイクルをタスクのスケジューリング属性として持つ周期タスクと、周期、実行開始サイクルをタスクのスケジューリング属性として持つリフレッシュブロックと、タスクプライオリティをタスクのスケジューリング属性として持つイベントタスクと、で表現される任意の制御仕様を制御装置に実行させるための制御プログラムを開発するための制御プログラムの開発環境装置であって、
周期タスクとリフレッシュブロックとイベントタスクとで決まる１つの制御仕様の処理を１つの制御グループとして定義するとともに、その制御グループを複数個定義するための手段と、
前記１つの制御グループに対して、１若しくは２以上の周期タスクと、１若しくは２以上のリフレッシュブロックと、１若しくは２以上のイベントタスクとを入力するための手段と、
前記定義するための手段と入力するための手段との操作により、１つの制御グループとなる周期タスクとリフレッシュブロックとイベントタスクとの組を、該当する定義の制御グループに関連づけて記述され、その操作が各制御グループについて行なわれることにより、複数の制御グループを含んでなる制御プログラムを生成する手段と、
を具備することを特徴とする制御プログラムの開発環境装置にある。
【００１５】
この出願の請求項２に記載の発明は、請求項１に記載の開発環境装置の各構成手段をコンピュータにて実現するためのプログラムを記録した記録媒体にある。
【００１６】
この出願の請求項３に記載の発明は、タスクプライオリティ、周期、実行開始サイクルをタスクのスケジューリング属性として持つ周期タスクと、周期、実行開始サイクルをタスクのスケジューリング属性として持つリフレッシュブロックと、タスクプライオリティをタスクのスケジューリング属性として持つイベントタスクと、で表現される任意の制御仕様に対応する制御プログラムを実行する制御装置であって、
１若しくは２以上の周期タスクと、１若しくは２以上のリフレッシュブロックと、１若しくは２以上のイベントタスクとからなる制御グループが複数グループ定義された制御プログラムを格納するための手段と、
前記制御プログラムを構成するすべての制御グループのすべてのリフレッシュブロック並びに全ての周期タスクを、唯一のサイクルタイムに同期して一括に実行する手段と、
を具備することを特徴とする制御プログラムを実行する制御装置にある。
【００１７】
この出願の請求項４に記載の発明は、いずれかの制御グループで致命的な異常が発生した場合には、その制御グループに属する処理のみを停止し、その他の制御グループの処理は継続することを特徴とする請求項３に記載の制御プログラムを実行する制御装置にある。
【００１８】
この出願の請求項５に記載の発明は、制御グループの初期（ initial ）状態、稼働（ run ）状態、停止（ stop ）状態、終了（ settle ）状態の相互間における状態遷移に関して、すべての制御グループの状態を遷移させるモードと、特定の制御グループの状態を遷移させるモードとを併有することを特徴とする請求項１に記載の制御プログラムを実行する制御装置にある。
【００１９】
この出願の請求項６に記載の発明は、請求項１〜３のいずれかに記載の制御装置の各構成手段をコンピュータにて実現するためのプログラムを記録した記録媒体にある。
【００２０】
以上の発明の意図はつぎのように説明される。本発明は、周期タスク、イベントタスク、リフレッシュブロックといった処理の単位を１つの制御部グループとして定義することで、１つの制御装置内に論理的な制御装置を複数定義可能とする。
【００２１】
各制御グループは、お互いに独立して動作するのではない。
【００２２】
すなわち、ＩＮリフレッシュする場合は、全ての制御グループのすべてのＩＮリフレッシュブロックをスケジューリング属性に従い実行する（制御グループに拘わらず、ＩＮリフレッシュは一括で行う）。
【００２３】
周期タスクを実行する場合は、全ての制御グループのすべての周期タスクをスケジューリング属性に従い実行する（制御グループに関わらず周期タスクの実行は一括して行う）。
【００２４】
ＯＵＴリフレッシュする場合は、全ての制御グループのすべてのＯＵＴリフレッシュブロックをスケジューリング属性に従い実行する（制御グループに拘わらずＯＵＴリフレッシュは一括して行う）。
【００２５】
上記の結果、システムの処理は制御グループに拘わらず、ＯＵＴリフレッシュ→周期タスク実行→ＯＵＴリフレッシュの実行手順となる。
【００２６】
なお、周期タスク、リフレッシュブロックの実行は、システムが唯一もつサイクルタイムに同期して動作する。例えば、サイクルタイムが１０msecの場合は、周期タスク、リフレッシュブロックはこのサイクルタイムの整数倍でしか動作しない。これにより制御グループ間のメモリの排他制御が不要となる。
【００２７】
異常処理については、制御グループで致命的な異常が発生した場合、その制御グループに属する処理（周期タスク、リフレッシュブロック、イベントタスク）のみを停止し、その他の制御グループの処理は継続実行する。
【００２８】
制御グループの状態遷移については、制御グループ全体を遷移させる方法と特定の制御グループの状態を遷移させることとの双方が可能である。
【００２９】
【発明の実施の形態】
以下に、本発明の好適な実施の一形態を添付図面並びに表を参照しつつ詳細に説明する。
【００３０】
先ず、図７に従って、本発明が適用されたシステムの概要を説明する。同図において、符号１，２が付されているのは、制御装置で実行されるべきプログラムを作成するための開発環境装置（この例では、パソコンで構成される）である。これらの開発環境装置１，２は、例えばパソコン上で動作するプログラムを主体として構成されている。開発環境装置１，２で作成された制御プログラム（シーケンス制御プログラム等）は、パソコンのメモリ、ＨＤＤ等の記録媒体に記録される。
【００３１】
符号３が付されているのは、本発明の制御装置に相当するシーケンスエンジン稼働装置である。このシーケンスエンジン稼働装置３も、例えばパソコン上で動作するプログラムを主体として構成されている。
【００３２】
開発環境装置１，２と制御装置であるシーケンスエンジン稼働装置３とは、ネットワークで接続されている複数台のパソコンで構成される場合と、１台のパソコン上に、開発環境装置１，２と制御装置であるシーケンスエンジン可動装置とに相当するソフトウェアを組み込むことで構成される場合とがある。
【００３３】
開発環境装置１，２で開発されて記録媒体上に格納された制御プログラムは、制御装置であるシーケンスエンジン稼働装置３に転送されて、同じくメモリ、ＨＤＤ等の記録媒体に格納される。
【００３４】
制御装置であるシーケンスエンジン稼働装置３は、コミュニケーションを介して結ばれた１若しくは２以上のデバイス４に対してプログラムの演算結果を出力する。またデバイス４のデータを獲得してプログラムの演算を行う。
【００３５】
開発環境装置１，２で行なわれる作業の流れが図８のフローチャートに示されている。以下、図８に従って、開発環境装置１，２における作業内容を詳細に説明する。
【００３６】
［制御グループの定義］
プログラム開発時には、図１に示されるように、プログラム開発ツール上で制御グループを定義する（ステップ８０１ＹＥＳ，８０２）。
【００３７】
図から明らかなように、この例では、制御グループ１には、３つのイベントタスク（イベントタスク１，２，３）と、２つの周期タスク（周期タスク１，２）と、３つのリフレッシュブロック（リフレッシュブロック１，２，３）とが定義されている。
【００３８】
また、制御グループに属さないものとしては、３つのイベントタスク（電源イベントタスク１，Ｉ／Ｏ異常タスク２，Initialイベントタスク）と、１つの周期タスク（周期タスク１０）と、１つのリフレッシュブロック（リフレッシュブロック１０）とが定義されている。
【００３９】
なお、後に詳述するが、図１において、符号ａで示される（ ）内の数値はタスクプライオリティ、符号ｂで示される（ ）内の一対の数値は実行開始サイクルと周期、符号ｃで示されるものは同一スケジューリング属性をもつもの同士を結合する直線である。例えば、制御グループ１内の周期タスク１を例に取ると、そのタスクプライオリティは『１０』、実行開始サイクルは『１』、周期は『２』であることが理解される。
【００４０】
開発環境装置１，２において制御グループが定義されると、パソコンのメモリ上あるいはハードディスク等の記録媒体上には、例えば表１に示されるような情報が生成される。表１の例では、各制御グループ毎に、『周期タスク名』、『ＩＮリフレッシュブロック名』、『ＯＵＴリフレッシュブロック名』、『イベントタスク名』が関連づけて記憶されている。
【００４１】
【表１】
［イベント、イベントタスクの定義］
制御グループの定義に続いて、イベント・イベントタスクを定義する（ステップ８０３）。イベントには、制御グループ内で有効な（制御グループが無効状態の場合はイベントを発生しない）ローカルイベントと、制御グループの状態に関係なく発生するグローバルイベントとが存在する。
【００４２】
グローバルイベントには、電断発生イベント、電断解除イベント、デバイス異常イベント、Initialイベント、Runイベント、Pauseイベント、Settleイベント等が存在する。
【００４３】
状態遷移に関わるInitial，Run，Pause，Settleイベント（グローバルイベント）について説明する。Initialイベントとは、全ての制御グループを同時にInitial状態に遷移させた場合に発生するグローバルイベントである。個々の制御グループをInitial状態に遷移させた場合は、本イベントは発生しない。本イベントが発生する場合は、各制御グループに対するInitialイベントが発生する。各制御グループに対するInitialイベントタスクの実行順序、あるいは、制御グループに対するInitialイベントタスクと（グローバルな）Initialイベントタスクの実行順序は、タスクプライオリティによって決定される。
【００４４】
Run，Pause，Settleイベントに対する考え方も上記のInitialイベントと全く同じである（Initialをそれぞれの状態に読み替える）。
【００４５】
イベントタスクでは、イベント、タクスプライオリティ、イベントタスクで実行されるプログラムを定義する。イベントタスクは、図３の一巡実行サイクルのゼネラルフローチャートに示されるプリエンプティブポイントで実行される。
【００４６】
開発環境装置１，２においてイベントタスクが定義されると、パソコンのメモリ上あるいはハードディスク等の記録媒体上には、例えば表２に示されるような情報が生成される。表２の例では、各カテゴリ毎に、『イベント名』、『タスク名』、『制御グループ名』、『タスクプライオリティ』が関連づけて記憶されている。
【００４７】
【表２】
［周期タスクの定義］
イベント・イベントタスクの定義に続いて、周期タスクを定義する（ステップ８０４）。周期タスクには、制御グループ内で有効な（制御グループが無効状態の場合は、実行されない）周期タスクと、制御グループの状態に拘わらず実行される周期タスクが存在する。
【００４８】
周期タスクでは、周期タスクのスケジューリング属性（実行開始サイクル、周期、タスクプライオリティ）と周期タスクで実行されるプログラムを定義する。周期タスクの制御装置内での動作態様は、図５に示されている。
【００４９】
開発環境装置１，２において周期タスクが定義されると、パソコンのメモリ上あるいはハードディスク等の記録媒体上には、例えば表３に示されるような情報が生成される。周期タスクの属性には、周期、実行開始サイクル、タスクプライオリティが存在する。周期と開始サイクルの意味はリフレッシュブロックと同じである。タスクプライオリティは同一周期に実行すべき周期タスクが複数あった場合の実行順序を意味する。表３の例では、各タスク名毎に、『周期』、『実行開始サイクル』、『タスクプライオリティ』、『制御グループ名』が関連づけて記憶されている。
【００５０】
【表３】
［リフレッシュブロックの定義］
周期タスクの定義に続いて、リフレッシュブロックを定義する（ステップ８０５）。リフレッシュブロックには、制御グループ内で有効な（制御グループが無効状態の場合はリフレッシュブロックを実行しない）リフレッシュブロックと、制御グループの状態に関わらず実行されるリフレッシュブロックが存在する。
【００５１】
リフレッシュブロックを定義する際は、図２に示されるように、デバイスタイプ、デバイス名、Ｉ／Ｏ名を定義する。リフレッシュブロックには、以下に示す３つの場合がある。
【００５２】
▲１▼１つのデバイスで１つのリフレッシュブロックを構成する場合
（図２のＩ−１，Ｏ−１の場合）
▲２▼複数のデバイスで１つのリフレッシュブロックを構成する場合
（図２のＩ−２，Ｏ−２の場合）
▲３▼１つのデバイスで複数のリフレッシュブロックを構成する場合
（図２のＩ−３，Ｉ−４，Ｏ−３，Ｏ−４の場合）
リフレッシュブロックの制御装置内の動作態様は、図６に示されている。
【００５３】
開発環境装置１，２においてリフレッシュブロックが定義されると、パソコンのメモリ上あるいはハードディスク等の記録媒体上には、例えば表４，表５に示されるような情報が生成される。リフレッシュブロックの属性には、周期と開始サイクルがある。周期は、制御装置がもつサイクルタイムの倍数を示す（サイクルタイムが１０msecで、周期が５の場合は、１０×５で５０msecの実行周期を持つことを示す）。また、開始サイクルとは、制御装置がサイクル動作を開始した場合に、何サイクル目からリフレッシュブロックの実行を行うかを定義するものである。表４の例では、ＩＮリフレッシュブロック毎に、『デバイス名』が記憶されている。また、表５の例では、各リフレッシュブロック毎に、『周期』、『実行開始サイクル』、『制御グループ名』が関連づけて記憶されている。
【００５４】
【表４】
【表５】
［開発環境から制御装置実行環境へのプロジェクトのダウンロード］
すべての制御グループに関する定義が完了したならば（ステップ８１０ＹＥＳ）、図７に示される開発環境装置１，２で生成し、開発環境装置１，２のメモリ上あるいはハードディスク等の記録媒体に格納されている情報（表１，２，３，４，５に示される）をネットワーク等を通じてシーケンスエンジン稼働環境３にダウンロードする（ステップ８１１ＹＥＳ，８１２）。すると、ダウンロードされた情報は、可動装置３内のメモリあるいはハードディスク等の記録媒体に格納される。
【００５５】
［制御装置の動作］
次に、制御装置であるシーケンスエンジン稼働装置３の動作の概略を、図３のフローチャート、図４の状態遷移図、並びに、図１０のブロック図を参照して説明する。
【００５６】
まず、制御装置であるシーケンスエンジン稼働装置３の状態について説明する。制御装置であるシーケンスエンジン稼働装置３は、開発環境装置１，２から運転の指示を受けると図４の状態遷移図に示すInitial状態に遷移する。Initial状態では、制御装置３のシステムの初期処理、あるいは、制御装置３がInitialイベントを発生させてユーザが定義したInitialイベントタスクを実行する。
【００５７】
Initial状態の処理が終わると制御装置はユーザがあらかじめ定義した情報に従ってRun状態かPause状態に遷移する。このとき、Run状態に遷移する場合には、制御装置はRunイベントを発生させ、ユーザが定義したRunイベントタスクがあればこれを実行する。Pause状態に遷移する場合も同様である。Pause状態は、図３に示されるのＯＵＴリフレッシュ、ＩＮリフレッシュ、命令実行が実行されず周辺処理のみを行っている状態である。
【００５８】
なお、Settle状態は、制御装置のシステム終了処理、あるいは、制御装置がSettleイベントを発生させSettleイベントタスクが定義されていればこれを実行する状態である。
【００５９】
次に、制御装置３の内部処理について説明する。制御装置３内の処理ブロック図を図１０に示す。同図に示されるように、制御装置３の内部処理は、スケジューリング部１０１と、リフレッシュブロック実行部１０２と、周期タスク実行部１０３と、周辺処理実行部１０４と、イベントタスク実行部１０５とから構成されている。
【００６０】
スケジューリング部１０１は、開発環境装置１，２からダウンロードされてきた表３，４に示される情報を基に、実行すべき周期タスクやリフレッシュブロックを決定し、各処理実行部１０２〜１０５に処理を依頼する。周期タスク、ＩＮリフレッシュ、ＯＵＴリフレッシュ、周辺処理をどのような順番で実行するかは、システムで固定である場合、あるいは記憶媒体によりパラメータライズ化されている場合の２通りがある。
【００６１】
リフレッシュブロック処理部１０２は、スケジューリング部１０１から指示されたリフレッシュブロックを実行するものである。
【００６２】
周期タスク実行部１０３は、スケジューリング部１０１から指示された周期タスクを実行するものである。具体的には、制御装置内のメモリに格納された値に対してプログラムに従い演算し、演算結果を制御装置内のメモリに格納する処理を行う。
【００６３】
周辺処理実行部１０４は、開発環境装置１，２等の外部機器とコミュニケーションを行うものである。具体的には、制御装置３内のあるメモリの情報を、制御装置とコミュニケーションするデバイス４へ送信したり、あるいは、デバイス４の値を受信して制御装置３内のあるメモリに格納することを行う。
【００６４】
次に、スケジューリング部１０１の処理をより詳細に説明する。Run状態、Pause状態のスケジューリング部の処理を図１１〜図１３のフローチャートに示す。この例では、処理の順番は、ＩＮリフレッシュ、周期タスク実行、ＯＵＴリフレッシュ実行、周辺処理実行という順番になっている。スケジューラは、サイクルタイムで示される周期で起動し、上記の処理を順番に実行する。以下、各処理について順に説明する。
【００６５】
まず、図１１のフローチャートに示されるＩＮリフレッシュに関する処理（ステップ１１０２〜１１０６）について説明する。
【００６６】
ＩＮリフレッシュ処理を開始するに際しては、それに先だって、現在の制御装置の状態を判定する。もし制御装置がPause状態の場合は、ＩＮリフレッシュは実行しないので、次の処理（図１２の周期タスク実行）に移る。
【００６７】
もし、制御装置がRun状態の場合は、表５に示される内容の情報と現在の制御装置のサイクル（ステップ１１０１でカウントされる）とから、実行すべきリフレッシュブロックとそのリフレッシュブロックが属する制御グループとを獲得する。なお、表５に示される内容の情報は、ＩＮとＯＵＴごとに存在する。次に、上記の処理で獲得した制御グループを実行すべきかどうかを表６に示される内容の情報から獲得する（ステップ１１０２）。
【００６８】
【表６】
表６に示される内容の情報により制御グループが実行すべきであった場合は、リフレッシュブロック実行部（図１０に符号１０２で示す）に実行すべきリフレッシュブロックを指定して実行依頼する（ステップ１１０３）。もし、表６により実行すべきでない制御グループであった場合は、このリフレッシュブロックは実行しない。
【００６９】
スケジューリング部（図１０に符号１０１で示す）は、実行依頼したリフレッシュブロックが正常終了したのをリフレッシュブロック実行部から通知されると（ステップ１１０４ＹＥＳ）、次のリフレッシュブロックに関する処理を行う（ステップ１１０５ＮＯ，１１０１）。もし、異常終了が通知された場合は（ステップ１１０４ＮＯ）、スケジューラは異常処理（ステップＡ１〜Ａ４）を行う。
【００７０】
異常処理では、まず、表４に示される内容の情報より異常が発生したリフレッシュブロックはどのデバイスに対するものなのかを判定する。例として、もし、ＩＮリフレッシュブロック３で異常が発生した場合、デバイス５で異常が発生したことが、表４より判定できる。そして表２を使ってデバイス５に対するリフレッシュブロックを検索する。表４よりＩＮフレッシュブロック４についても実行を停止する必要があることがわかる。
【００７１】
次に、表５を使用して停止すべきリフレッシュブロックが存在する制御グループは、制御グループ１，２であることを判定する（ステップＡ１）。
【００７２】
次に、表６に停止すべき制御グループに対して無効であることを示す値を格納する（ステップＡ２）。
【００７３】
次に、制御装置は、表２を参照して「Ｉ／Ｏ致命的異常」に対するイベントタスクが定義されているかを検索し（ステップＡ３）、定義されていればイベントタスクを実行する（ステップＡ４）。スケジューラはイベントタスクの実行が終了すると、元の処理を行う。
【００７４】
以上が、ＩＮリフレッシュに関するスケジューラの処理である。ＯＵＴリフレッシュについても同一の処理（ステップ１３０１〜１３０５）である。
【００７５】
次に、命令実行部の処理（ステップ１２０１〜１２０５）について説明する。概要はＩＮリフレッシュ部と同じであるので、説明を簡略化する。
【００７６】
先ず、制御装置の状態を判定してPause状態であればＳＫＩＰする。表３を参照して実行すべき周期タスク、制御グループを獲得する（ステップ１２０１）。表６を参照して、実行すべき周期タスクの属する制御グループは実行が許可されているかを判定する。実行すべき周期タスクが複数存在する場合は、タスクプライオリティの高いものから実行する（ステップ１２０２，１２０３，１２０４，１２０５）。周期タスク実行部から異常が返ってきた場合は（ステップ１２０３ＮＯ）、異常処理を行う。異常処理では、異常が発生した制御グループを無効にするために、表６に無効を格納する。表５を参照して「命令実行異常イベント」に対するイベントタスクが定義されているかを判定して、定義されていればこれを実行する（ステップＡ１〜Ａ４）。元の処理を行う。周辺処理は、制御装置の状態に関わらず実行する（ステップ１３０６）。
【００７７】
［制御装置の実行］
制御装置は、開発環境等の外部機器からの指示を受けると、図４に示されるように、Initial状態に遷移する。Initial状態に遷移した場合、グローバルイベントであるInitialイベントと、各制御グループに対するInitialイベントが発行される。もし、説明したイベントに対するイベントタスクが定義されていた場合、タスクのプライオリティに従い実行される。もし、制御グループの初期処理を記述した制御グループに対するInitialイベントタスクの実行をシステム全体の初期処理を記述したグローバルなInitialイベントタスクの実行の後にしたい場合は、制御グループ１に対するInitialイベントタスクのタスクプライオリティをグローバルなInitialイベントタスクのタスクプライオリティより低く設定しておく。
【００７８】
上記の内容を表２および図９のフローチャートを参照して説明する。制御装置は、外部機器やユーザプログラム命令によって制御装置の状態をInitial状態に遷移する指示がきた場合、全ての制御グループをInitial状態に遷移させる命令なのか、特定の制御グループに対するものなのかを判定する（ステップ９０１）。
【００７９】
すべての制御グループの状態を遷移させる指示の場合は（ステップ９０１全ての制御グループ）、表２のInitialイベントに対するイベントタスク１０，１１，１２をタスクプライオリティに従い実行する。この場合、イベントタスク１０，１１，１２の順に実行される（ステップ９０３）。
【００８０】
Initial状態遷移の指示が特定の制御グループ１に対するものである場合（ステップ９０１特定の制御グループ）、表２より実行すべきイベントタスクはイベントタスク１１であることを判定し実行する（ステップ９０２）。
【００８１】
［命令実行異常発生時の処理］
図１０のスケジューリング部１０１の処理が、図１１〜図１３のフローチャートに示されている。
【００８２】
Run状態の制御装置において、周期タスク１において命令実行中に０除算や配列のオーバフロー等の致命的な異常が発生した場合（ステップ１１０２）、スケジューリング部１０１は、表１から周期タスク１が制御グループ１に属することを判定する。その結果、制御グループ１に属する周期タスク２、ＩＮリフレッシュブロック１〜３、ＯＵＴリフレッシュブロック１〜３、イベントタスク１〜３の処理を無効すべきと判定し、以降、制御グループ１に属する処理を行わない。
【００８３】
この場合、命令実行異常イベントが発生され、このイベントは制御グループに依存しないイベントであるため、このイベントに対するイベントタスクが実行される。もし、制御グループ同士に関連が存在して、他の制御グループの処理を停止させたい場合、あるいは制御を終了したい場合等、異常時の処理を定義したい場合は、このイベントタスクに制御グループ停止命令、あるいは制御終了命令を記述する。
【００８４】
なお、制御グループ停止命令とは、指定した（複数可能）制御グループの処理を停止する命令である。制御終了命令は、制御装置をSettle状態に遷移させて制御装置を運転停止状態にする命令である。
【００８５】
［デバイスの異常発生時の処理］
表４の例で、デバイス３で致命的な異常が発生した場合、表４からデバイス３はリフレッシュブロック１に属することがわかる。そしてリフレッシュブロック１は、表１から制御グループ１に属することが判明する。従って、制御装置は、制御グループ１に属する周期タスク２、ＩＮリフレッシュブロック１〜３、ＯＵＴリフレッシュブロック１〜３、イベントタスク１〜３の処理を停止する。
【００８６】
デバイスに対して致命的な異常が発生した場合は、デバイス異常システムイベントが発生する。このイベントは、制御グループに依存しないイベントである。このイベントに対するイベントタスクが定義されている場合は、制御装置はイベントタスクを実行する。
【００８７】
もし、制御グループ同士に関連が存在して、他の制御グループの処理を停止させたい場合、あるいは制御を終了したい場合等、異常時の処理を定義したい場合は、このイベントタスクに制御グループ停止命令、あるいは制御終了命令を記述する。
【００８８】
［デバッグ作業］
制御グループ１〜３がPause状態である場合において、外部機器から制御グループ１をRun状態に遷移させる命令を周辺処理で受信した場合、制御装置は以下の処理を行なう。
【００８９】
・制御グループ１に対するRunイベントを発行し、左記イベントに対するイベントタスクが定義されている場合は、制御装置はイベントタスクを実行する。
【００９０】
・制御グループ１をRun状態にする。すなわち、制御グループ１に属する周期タスク１〜２、ＩＮリフレッシュブロック１〜３、ＯＵＴリフレッシュブロック１〜３、イベントタスク１〜３の処理を実行する。
【００９１】
続いて、外部機器からRun状態にある制御グループ１に対し、以下のような命令を送り、制御グループ１の動作を検証する。
【００９２】
・Ｎサイクル実行命令（出願済み）
・指定イベントタスク実行命令（出願済み）
・データトレース命令（公知）
・強制セット・リセット命令（公知）
外部機器からRun状態にある制御グループ１をPause状態に遷移させる命令を周辺処理で受信した場合、制御装置は以下の処理を行なう。
【００９３】
・制御グループ１に対するPauseイベントを発行し、左記イベントに対するイベントタスクが定義されている場合は、制御装置はイベントタスクを実行する。
【００９４】
・制御グループ１をPause状態にする。
【００９５】
制御グループ１の動作が正常であることが確かめられた場合、次に制御グループ２，３と同様な処理を行ない、各制御グループ単体での動作検証を行なう。例えば制御グループ１と制御グループ２が協調動作している場合は、外部機器から制御グループ１と２をRun状態に遷移させる命令を制御装置に送信する。この命令を制御装置が受信した場合、図３のフローチャートに示される周辺処理でこの命令を認識し、制御グループ１と２をRun状態に遷移させる。それぞれの制御グループの状態遷移時の処理は上の説明と同様である。そして、Run状態にある制御グループ１と２の動作を検証する。
【００９６】
［全ての制御グループを同時に状態遷移させる場合］
例えば、全ての制御グループの動作を検証したい場合、全ての制御グループを同時に運転開始したい場合、全ての制御グループの運転を終了したい場合等がある。制御グループ１〜３がPause状態の場合において、全ての制御グループをInitial状態に遷移させる命令を制御装置が周辺処理で受信した場合、制御装置は、以下の処理を行なう。
【００９７】
・同時に▲１▼Initialイベント（グローバル）、▲２▼制御グループ１に対するInitialイベント（ローカル）、▲３▼制御グループ２に対するInitialイベント（ローカル）、▲４▼制御グループ３に対するInitialイベント（ローカル）を発生する。
【００９８】
・同時に発生したイベントに対するイベントタスクをタスクプライオリティに従い順に処理する。
【００９９】
・制御装置は、Initial状態の処理を実行し、指定された状態（Run/Pause）に遷移する。
【０１００】
上記のInitial以外の全ての制御グループの状態を遷移させる命令（Run，Pause，Settle）については、考え方は上記とまったく同じである（InitialをRun/Pause/Settleに読み替える）。
【０１０１】
［制御グループ内での制御グループの制御］
例えば、制御グループ１と２の間で協調動作をしていて、どちらか一方の制御グループで異常が発生した場合、他の制御グループの実行を無効にする必要が存在する場合がある。これを制御装置のシステムコール形式で実現し、このシステムコールをプログラム中に記述することが可能である。このシステムコールが記述されていた場合は、制御装置はシステムコールで記述されている制御グループの有効・無効制御を行なう。
【０１０２】
例えば、制御グループ１に属するイベントタスクにおいて上記システムコールで制御グループ２を無効にする内容を記述しておくと、左記イベントタスク実行要因（例：ロボット１の故障）が発生した場合、このイベントタスクの実行により、制御グループ２の処理が実行されなくなる。
【０１０３】
また、制御グループ１に属するイベントタスクで制御グループ２を有効にする内容を記述しておくと、左記イベントタスクを実行要因（例：ロボット１の故障復旧）が発生した場合、このイベントタスクの実行により、制御グループ２の処理が実行される。
【０１０４】
上記の例では、制御グループ２の処理を中止、再開する様子を説明したが、中止位置から再開するのではなく、制御グループ２を制御グループの初期処理から実行したい場合がある。この場合、上記と同様にシステムコールという形でユーザプログラムで記述する。
【０１０５】
例えば、制御グループ１に属するイベントタスク１（ロボット１故障）で制御グループ２を無効にするシステムコールを記述しておき、イベントタスク２（ロボット１故障復旧）で制御グループ２をInitial状態から実行するシステムコールを記述しておく。
【０１０６】
これにより、Run状態の制御グループ１，２がRun状態の場合に、ロボット１が故障した場合は、制御グループ２が無効状態となり、ロボット２の故障が復旧した場合、制御グループ１をRun状態にしたまま制御グループ２をInitial状態に遷移させ、初期処理を実行した後再び制御装置がRun状態になる。制御グループ２の状態遷移時は、サイクルタイム−スキャンタイムで計算される時間で処理される。
【０１０７】
［制御グループに属さない処理］
制御グループに共通な処理、あるいは、制御グループ間の制御を行なう処理は、制御グループに属さないようにしておく。たとえば、制御グループ間のインターロック等はこれにあたる。
【０１０８】
［その他］
本実施形態のように１つの装置（パソコン）内で複数の制御グループを実行することも可能であるが、各制御グループを別の制御装置で実行させることも可能である。
【０１０９】
すなわち、複数の制御グループを１つの制御装置で実行していた場合、制御装置自体に致命的な異常（ＭＰＵ故障）が発生した場合、全ての制御グループの実行が不可能となる。そのため、各制御グループをそれぞれ別の制御装置で実行させることが考えられる。この場合、分散した制御装置が全体としてどのような振る舞いをするかをシミュレーションする必要がある。本発明はこのようなケースにおいても有効である。
【０１１０】
この場合、本実施例のように１つの装置で開発環境で複数の制御グループを実行させて、複数の制御グループのデバッグ、シミュレーションを行う。制御グループとコミュニケーションするデバイスは実デバイスでなく、開発環境マシンのメモリで行ってもかまわない。各制御グループのデバッグ、シミュレーションを行った後、各制御グループを別々の制御装置にダウンロードする。これにより１つの制御装置で分散した制御装置上で動作する制御グループの動作をシミュレーション、デバッグすることが可能である。
【０１１１】
【発明の効果】
以上の実施形態の説明でも明らかなように、本発明によれば、制御グループを単位として異常処理、状態遷移処理を行うことにより、システムの正当性、モジュール性を向上させることができる。これによりプログラム作成、保守が容易となる。
【０１１２】
また、全ての制御グループの周期タスクはサイクルタイムの整数倍で動作するため、制御グループ間で同じメモリをアクセスしている場合でも、メモリの排他制御を行う必要がない。したがって、制御装置の性能に悪影響を及ぼさない。また、プログラムを作成する際は、メモリの排他制御を意識する必要がないため容易にプログラムを作成することができる。
【０１１３】
また、制御グループが複数存在する場合でも、ＩＮリフレッシュ、ＯＵＴリフレッシュは制御グループに関わらず一括で行うため、データの同時性に優れる。
【０１１４】
さらに、分散した制御装置の振る舞いを１台の制御装置（開発環境）でシミュレーション、デバッグを行うことが可能となる。
【図面の簡単な説明】
【図１】制御グループ定義内容の説明図である。
【図２】リフレッシュブロック定義内容の説明図である。
【図３】一巡実行サイクルのゼネラルふーちゃーとである。
【図４】制御装置の状態遷移図である。
【図５】周期タスクの動作態様を示す説明図である。
【図６】リフレッシュブロックの動作態様を示す説明図である。
【図７】システム全体の構成図である。
【図８】開発環境装置における作業手順を示すフローチャートである。
【図９】制御装置におけるイベントタスク選択実行処理を示すフローチャートである。
【図１０】制御装置内の処理ブロック図である。
【図１１】ＩＮリフレッシュに関するスケジューラの処理を示すフローチャートである。
【図１２】命令実行に関するスケジューラの処理を示すフローチャートである。
【図１３】ＯＵＴリフレッシュに関するスケジューラの処理を示すフローチャートである。
【図１４】制御ブロックと制御対象ブロックとの関係を示す説明図である。
【符号の説明】
１，２ 開発環境装置
３ シーケンスエンジン稼働装置（制御装置）
４ デバイス
１０１ スケジューリング部
１０２ リフレッシュブロック部
１０３ 周期タスク実行部
１０４ 周辺処理実行部
１０５ イベントタスク実行部
ａ タスクプライオリティ
ｂ 実行開始サイクルと周期
【発明の属する技術分野】
本発明は、制御グループを単位として異常処理、状態遷移処理を行うことにより、システムの正当性、モジュール性を向上させた制御装置に関する。
【０００２】
【従来の技術】
制御装置の設計において、制御中の異常時にどのように対応するかに関しては、従来より様々な考え方が存在する。
【０００３】
例えば、制御装置とコミュニケーションするデバイスが複数存在するような制御システムにおいては、１つのデバイスで異常が発生した場合に、それとコミュニケーションする制御装置の側を運転停止状態あるいは運転継続状態のいずれにするかに関しては、予めシステムで固定化しておくか、あるいは、プログラム作成時にファイル等でパラメータライズ化可能とする異常時対応方式（１）が採用される。
【０００４】
また、１つの制御装置で複数の制御対象を制御し、複数の制御対象に対するプログラムを１つあるいは複数のタスクで記述しているような制御システムにおいては、あるタスクで０除算等の命令実行異常が発生した場合には、制御装置で実行している全てのタスクを強制的に停止させるか、あるいは構わず運転を継続させると言った二者択一の異常時対応方式（２）が採用されている。
【０００５】
また、制御システムによっては、外部機器からの命令によって運転状態から運転停止状態にする等、制御装置全体の状態を一括して変更する異常時対応方式（３）も採用されている。
【０００６】
また、制御システムによっては、制御装置の起動時、終了時、異常時にそれぞれ特定の処理を実行するようにプログラムしておき、それらの処理の中で複数の制御対象に固有の必要な処理、システム全体に関わる処理をユーザが任意に記述できるようにした異常時対応方式（４）も採用されている。
【０００７】
さらに、制御システムによっては、複数の制御対象を制御する場合、個々の制御対象の異常に容易に対応できるように、複数の制御装置で制御を行う異常対応方式（５）も採用されている。
【０００８】
【発明が解決しようとする課題】
しかしながら、上述の異常時対応方式（１）にあっては、あるデバイスで異常が発生した場合に、制御装置全体を運転停止させるような処理を設定すると、他の制御対象を制御しているデバイスが正常であるにも拘わらず、システム全体が停止してしまう。制御対象間の関係が粗なシステムでは、このような一括停止処理は適さない。逆に、いずれのデバイスで異常が発生しても、制御装置全体の運転が継続されるような処理を設定すると、制御対象間が密なシステムでは、システム全体として整合のとれた制御を行なうことができない。
【０００９】
上述の異常時対応方式（２）にあっては、ある制御対象を制御するためのタスクが複数存在する場合、それらのタスクのうち、ある１つのタスクで命令実行異常が発生した場合に、制御装置の運転を継続させるとその制御対象に対する制御が整合性のとれたものにならない。一方、あるタスクで異常が発生した場合に、システム全体の運転を停止させてしまうと、制御対象間で粗な関係のシステムでは、粗な関係にある制御対象に対する制御まで（正常に動作しているにも拘わらず）停止してしまう。
【００１０】
上述の異常時対応方式（３）にあっては、複数の制御対象を制御するシステムにおいて、システムをデバッグ（シミュレーション）する際に、特定の制御対象に対する処理だけを実行させてデバッグを行い、次に別の制御対象について同様にしてデバッグを行うと言った手順、あるいは、ＡとＢという制御対象に関する処理だけを実行させてデバッグを行うと言った手順でBuild Up式のデバッグができないため、プログラム開発時にどこに不具合が存在するかを特定することが困難である。また、運転中の制御装置においてある制御対象に関して異常が発生した場合に、その制御対象に対する処理だけを停止し、その制御対象だけに終了処理を実行することはできない。
【００１１】
上述の異常時対応方式（４）にあっては、制御装置の起動時、終了時などに１つのタスクにすべての制御対象に関する処理、終了処理を記述していた場合、ある制御対象で異常が発生してその制御対象に対する制御処理を行なう必要がないにも拘わらず、起動処理、終了処理が実行されてしまう。また、１つのタスクにすべての制御対象に対する処理を記述した場合、制御対象に対する処理の順番に依存性がある場合で順番を変更しようとした場合、プログラムの記述を大幅に変更する必要が生じる。
【００１２】
上述の異常時対応方式（５）にあっては、複数の制御装置で複数の制御対象を制御している場合、シミュレーション、デバッグは、各制御装置個々で行っているため、複数の制御装置でシステムの動きが分かるようなシステムの場合、全体の動作検証を１つの環境で行うことが困難である。
【００１３】
この発明は、上述の問題点に着目してなされたものであり、周期タスク、イベントタスク、リフレッシュブロックといった処理の単位を１つの制御グループとして定義すると共に、この複数の制御グループを１つの環境で実行し、制御グループ毎に最適な異常処理、状態遷移時の処理を実現することにより、デバッグ効率の向上、システムカスタマイズ性の向上、プログラミング容易性、制御の独立性を確保することを目的とする。
【００１４】
【課題を解決するための手段】
この出願の請求項１に記載の発明は、タスクプライオリティ、周期、実行開始サイクルをタスクのスケジューリング属性として持つ周期タスクと、周期、実行開始サイクルをタスクのスケジューリング属性として持つリフレッシュブロックと、タスクプライオリティをタスクのスケジューリング属性として持つイベントタスクと、で表現される任意の制御仕様を制御装置に実行させるための制御プログラムを開発するための制御プログラムの開発環境装置であって、
周期タスクとリフレッシュブロックとイベントタスクとで決まる１つの制御仕様の処理を１つの制御グループとして定義するとともに、その制御グループを複数個定義するための手段と、
前記１つの制御グループに対して、１若しくは２以上の周期タスクと、１若しくは２以上のリフレッシュブロックと、１若しくは２以上のイベントタスクとを入力するための手段と、
前記定義するための手段と入力するための手段との操作により、１つの制御グループとなる周期タスクとリフレッシュブロックとイベントタスクとの組を、該当する定義の制御グループに関連づけて記述され、その操作が各制御グループについて行なわれることにより、複数の制御グループを含んでなる制御プログラムを生成する手段と、
を具備することを特徴とする制御プログラムの開発環境装置にある。
【００１５】
この出願の請求項２に記載の発明は、請求項１に記載の開発環境装置の各構成手段をコンピュータにて実現するためのプログラムを記録した記録媒体にある。
【００１６】
この出願の請求項３に記載の発明は、タスクプライオリティ、周期、実行開始サイクルをタスクのスケジューリング属性として持つ周期タスクと、周期、実行開始サイクルをタスクのスケジューリング属性として持つリフレッシュブロックと、タスクプライオリティをタスクのスケジューリング属性として持つイベントタスクと、で表現される任意の制御仕様に対応する制御プログラムを実行する制御装置であって、
１若しくは２以上の周期タスクと、１若しくは２以上のリフレッシュブロックと、１若しくは２以上のイベントタスクとからなる制御グループが複数グループ定義された制御プログラムを格納するための手段と、
前記制御プログラムを構成するすべての制御グループのすべてのリフレッシュブロック並びに全ての周期タスクを、唯一のサイクルタイムに同期して一括に実行する手段と、
を具備することを特徴とする制御プログラムを実行する制御装置にある。
【００１７】
この出願の請求項４に記載の発明は、いずれかの制御グループで致命的な異常が発生した場合には、その制御グループに属する処理のみを停止し、その他の制御グループの処理は継続することを特徴とする請求項３に記載の制御プログラムを実行する制御装置にある。
【００１８】
この出願の請求項５に記載の発明は、制御グループの初期（ initial ）状態、稼働（ run ）状態、停止（ stop ）状態、終了（ settle ）状態の相互間における状態遷移に関して、すべての制御グループの状態を遷移させるモードと、特定の制御グループの状態を遷移させるモードとを併有することを特徴とする請求項１に記載の制御プログラムを実行する制御装置にある。
【００１９】
この出願の請求項６に記載の発明は、請求項１〜３のいずれかに記載の制御装置の各構成手段をコンピュータにて実現するためのプログラムを記録した記録媒体にある。
【００２０】
以上の発明の意図はつぎのように説明される。本発明は、周期タスク、イベントタスク、リフレッシュブロックといった処理の単位を１つの制御部グループとして定義することで、１つの制御装置内に論理的な制御装置を複数定義可能とする。
【００２１】
各制御グループは、お互いに独立して動作するのではない。
【００２２】
すなわち、ＩＮリフレッシュする場合は、全ての制御グループのすべてのＩＮリフレッシュブロックをスケジューリング属性に従い実行する（制御グループに拘わらず、ＩＮリフレッシュは一括で行う）。
【００２３】
周期タスクを実行する場合は、全ての制御グループのすべての周期タスクをスケジューリング属性に従い実行する（制御グループに関わらず周期タスクの実行は一括して行う）。
【００２４】
ＯＵＴリフレッシュする場合は、全ての制御グループのすべてのＯＵＴリフレッシュブロックをスケジューリング属性に従い実行する（制御グループに拘わらずＯＵＴリフレッシュは一括して行う）。
【００２５】
上記の結果、システムの処理は制御グループに拘わらず、ＯＵＴリフレッシュ→周期タスク実行→ＯＵＴリフレッシュの実行手順となる。
【００２６】
なお、周期タスク、リフレッシュブロックの実行は、システムが唯一もつサイクルタイムに同期して動作する。例えば、サイクルタイムが１０msecの場合は、周期タスク、リフレッシュブロックはこのサイクルタイムの整数倍でしか動作しない。これにより制御グループ間のメモリの排他制御が不要となる。
【００２７】
異常処理については、制御グループで致命的な異常が発生した場合、その制御グループに属する処理（周期タスク、リフレッシュブロック、イベントタスク）のみを停止し、その他の制御グループの処理は継続実行する。
【００２８】
制御グループの状態遷移については、制御グループ全体を遷移させる方法と特定の制御グループの状態を遷移させることとの双方が可能である。
【００２９】
【発明の実施の形態】
以下に、本発明の好適な実施の一形態を添付図面並びに表を参照しつつ詳細に説明する。
【００３０】
先ず、図７に従って、本発明が適用されたシステムの概要を説明する。同図において、符号１，２が付されているのは、制御装置で実行されるべきプログラムを作成するための開発環境装置（この例では、パソコンで構成される）である。これらの開発環境装置１，２は、例えばパソコン上で動作するプログラムを主体として構成されている。開発環境装置１，２で作成された制御プログラム（シーケンス制御プログラム等）は、パソコンのメモリ、ＨＤＤ等の記録媒体に記録される。
【００３１】
符号３が付されているのは、本発明の制御装置に相当するシーケンスエンジン稼働装置である。このシーケンスエンジン稼働装置３も、例えばパソコン上で動作するプログラムを主体として構成されている。
【００３２】
開発環境装置１，２と制御装置であるシーケンスエンジン稼働装置３とは、ネットワークで接続されている複数台のパソコンで構成される場合と、１台のパソコン上に、開発環境装置１，２と制御装置であるシーケンスエンジン可動装置とに相当するソフトウェアを組み込むことで構成される場合とがある。
【００３３】
開発環境装置１，２で開発されて記録媒体上に格納された制御プログラムは、制御装置であるシーケンスエンジン稼働装置３に転送されて、同じくメモリ、ＨＤＤ等の記録媒体に格納される。
【００３４】
制御装置であるシーケンスエンジン稼働装置３は、コミュニケーションを介して結ばれた１若しくは２以上のデバイス４に対してプログラムの演算結果を出力する。またデバイス４のデータを獲得してプログラムの演算を行う。
【００３５】
開発環境装置１，２で行なわれる作業の流れが図８のフローチャートに示されている。以下、図８に従って、開発環境装置１，２における作業内容を詳細に説明する。
【００３６】
［制御グループの定義］
プログラム開発時には、図１に示されるように、プログラム開発ツール上で制御グループを定義する（ステップ８０１ＹＥＳ，８０２）。
【００３７】
図から明らかなように、この例では、制御グループ１には、３つのイベントタスク（イベントタスク１，２，３）と、２つの周期タスク（周期タスク１，２）と、３つのリフレッシュブロック（リフレッシュブロック１，２，３）とが定義されている。
【００３８】
また、制御グループに属さないものとしては、３つのイベントタスク（電源イベントタスク１，Ｉ／Ｏ異常タスク２，Initialイベントタスク）と、１つの周期タスク（周期タスク１０）と、１つのリフレッシュブロック（リフレッシュブロック１０）とが定義されている。
【００３９】
なお、後に詳述するが、図１において、符号ａで示される（ ）内の数値はタスクプライオリティ、符号ｂで示される（ ）内の一対の数値は実行開始サイクルと周期、符号ｃで示されるものは同一スケジューリング属性をもつもの同士を結合する直線である。例えば、制御グループ１内の周期タスク１を例に取ると、そのタスクプライオリティは『１０』、実行開始サイクルは『１』、周期は『２』であることが理解される。
【００４０】
開発環境装置１，２において制御グループが定義されると、パソコンのメモリ上あるいはハードディスク等の記録媒体上には、例えば表１に示されるような情報が生成される。表１の例では、各制御グループ毎に、『周期タスク名』、『ＩＮリフレッシュブロック名』、『ＯＵＴリフレッシュブロック名』、『イベントタスク名』が関連づけて記憶されている。
【００４１】
【表１】
制御グループの定義に続いて、イベント・イベントタスクを定義する（ステップ８０３）。イベントには、制御グループ内で有効な（制御グループが無効状態の場合はイベントを発生しない）ローカルイベントと、制御グループの状態に関係なく発生するグローバルイベントとが存在する。
【００４２】
グローバルイベントには、電断発生イベント、電断解除イベント、デバイス異常イベント、Initialイベント、Runイベント、Pauseイベント、Settleイベント等が存在する。
【００４３】
状態遷移に関わるInitial，Run，Pause，Settleイベント（グローバルイベント）について説明する。Initialイベントとは、全ての制御グループを同時にInitial状態に遷移させた場合に発生するグローバルイベントである。個々の制御グループをInitial状態に遷移させた場合は、本イベントは発生しない。本イベントが発生する場合は、各制御グループに対するInitialイベントが発生する。各制御グループに対するInitialイベントタスクの実行順序、あるいは、制御グループに対するInitialイベントタスクと（グローバルな）Initialイベントタスクの実行順序は、タスクプライオリティによって決定される。
【００４４】
Run，Pause，Settleイベントに対する考え方も上記のInitialイベントと全く同じである（Initialをそれぞれの状態に読み替える）。
【００４５】
イベントタスクでは、イベント、タクスプライオリティ、イベントタスクで実行されるプログラムを定義する。イベントタスクは、図３の一巡実行サイクルのゼネラルフローチャートに示されるプリエンプティブポイントで実行される。
【００４６】
開発環境装置１，２においてイベントタスクが定義されると、パソコンのメモリ上あるいはハードディスク等の記録媒体上には、例えば表２に示されるような情報が生成される。表２の例では、各カテゴリ毎に、『イベント名』、『タスク名』、『制御グループ名』、『タスクプライオリティ』が関連づけて記憶されている。
【００４７】
【表２】
イベント・イベントタスクの定義に続いて、周期タスクを定義する（ステップ８０４）。周期タスクには、制御グループ内で有効な（制御グループが無効状態の場合は、実行されない）周期タスクと、制御グループの状態に拘わらず実行される周期タスクが存在する。
【００４８】
周期タスクでは、周期タスクのスケジューリング属性（実行開始サイクル、周期、タスクプライオリティ）と周期タスクで実行されるプログラムを定義する。周期タスクの制御装置内での動作態様は、図５に示されている。
【００４９】
開発環境装置１，２において周期タスクが定義されると、パソコンのメモリ上あるいはハードディスク等の記録媒体上には、例えば表３に示されるような情報が生成される。周期タスクの属性には、周期、実行開始サイクル、タスクプライオリティが存在する。周期と開始サイクルの意味はリフレッシュブロックと同じである。タスクプライオリティは同一周期に実行すべき周期タスクが複数あった場合の実行順序を意味する。表３の例では、各タスク名毎に、『周期』、『実行開始サイクル』、『タスクプライオリティ』、『制御グループ名』が関連づけて記憶されている。
【００５０】
【表３】
周期タスクの定義に続いて、リフレッシュブロックを定義する（ステップ８０５）。リフレッシュブロックには、制御グループ内で有効な（制御グループが無効状態の場合はリフレッシュブロックを実行しない）リフレッシュブロックと、制御グループの状態に関わらず実行されるリフレッシュブロックが存在する。
【００５１】
リフレッシュブロックを定義する際は、図２に示されるように、デバイスタイプ、デバイス名、Ｉ／Ｏ名を定義する。リフレッシュブロックには、以下に示す３つの場合がある。
【００５２】
▲１▼１つのデバイスで１つのリフレッシュブロックを構成する場合
（図２のＩ−１，Ｏ−１の場合）
▲２▼複数のデバイスで１つのリフレッシュブロックを構成する場合
（図２のＩ−２，Ｏ−２の場合）
▲３▼１つのデバイスで複数のリフレッシュブロックを構成する場合
（図２のＩ−３，Ｉ−４，Ｏ−３，Ｏ−４の場合）
リフレッシュブロックの制御装置内の動作態様は、図６に示されている。
【００５３】
開発環境装置１，２においてリフレッシュブロックが定義されると、パソコンのメモリ上あるいはハードディスク等の記録媒体上には、例えば表４，表５に示されるような情報が生成される。リフレッシュブロックの属性には、周期と開始サイクルがある。周期は、制御装置がもつサイクルタイムの倍数を示す（サイクルタイムが１０msecで、周期が５の場合は、１０×５で５０msecの実行周期を持つことを示す）。また、開始サイクルとは、制御装置がサイクル動作を開始した場合に、何サイクル目からリフレッシュブロックの実行を行うかを定義するものである。表４の例では、ＩＮリフレッシュブロック毎に、『デバイス名』が記憶されている。また、表５の例では、各リフレッシュブロック毎に、『周期』、『実行開始サイクル』、『制御グループ名』が関連づけて記憶されている。
【００５４】
【表４】
すべての制御グループに関する定義が完了したならば（ステップ８１０ＹＥＳ）、図７に示される開発環境装置１，２で生成し、開発環境装置１，２のメモリ上あるいはハードディスク等の記録媒体に格納されている情報（表１，２，３，４，５に示される）をネットワーク等を通じてシーケンスエンジン稼働環境３にダウンロードする（ステップ８１１ＹＥＳ，８１２）。すると、ダウンロードされた情報は、可動装置３内のメモリあるいはハードディスク等の記録媒体に格納される。
【００５５】
［制御装置の動作］
次に、制御装置であるシーケンスエンジン稼働装置３の動作の概略を、図３のフローチャート、図４の状態遷移図、並びに、図１０のブロック図を参照して説明する。
【００５６】
まず、制御装置であるシーケンスエンジン稼働装置３の状態について説明する。制御装置であるシーケンスエンジン稼働装置３は、開発環境装置１，２から運転の指示を受けると図４の状態遷移図に示すInitial状態に遷移する。Initial状態では、制御装置３のシステムの初期処理、あるいは、制御装置３がInitialイベントを発生させてユーザが定義したInitialイベントタスクを実行する。
【００５７】
Initial状態の処理が終わると制御装置はユーザがあらかじめ定義した情報に従ってRun状態かPause状態に遷移する。このとき、Run状態に遷移する場合には、制御装置はRunイベントを発生させ、ユーザが定義したRunイベントタスクがあればこれを実行する。Pause状態に遷移する場合も同様である。Pause状態は、図３に示されるのＯＵＴリフレッシュ、ＩＮリフレッシュ、命令実行が実行されず周辺処理のみを行っている状態である。
【００５８】
なお、Settle状態は、制御装置のシステム終了処理、あるいは、制御装置がSettleイベントを発生させSettleイベントタスクが定義されていればこれを実行する状態である。
【００５９】
次に、制御装置３の内部処理について説明する。制御装置３内の処理ブロック図を図１０に示す。同図に示されるように、制御装置３の内部処理は、スケジューリング部１０１と、リフレッシュブロック実行部１０２と、周期タスク実行部１０３と、周辺処理実行部１０４と、イベントタスク実行部１０５とから構成されている。
【００６０】
スケジューリング部１０１は、開発環境装置１，２からダウンロードされてきた表３，４に示される情報を基に、実行すべき周期タスクやリフレッシュブロックを決定し、各処理実行部１０２〜１０５に処理を依頼する。周期タスク、ＩＮリフレッシュ、ＯＵＴリフレッシュ、周辺処理をどのような順番で実行するかは、システムで固定である場合、あるいは記憶媒体によりパラメータライズ化されている場合の２通りがある。
【００６１】
リフレッシュブロック処理部１０２は、スケジューリング部１０１から指示されたリフレッシュブロックを実行するものである。
【００６２】
周期タスク実行部１０３は、スケジューリング部１０１から指示された周期タスクを実行するものである。具体的には、制御装置内のメモリに格納された値に対してプログラムに従い演算し、演算結果を制御装置内のメモリに格納する処理を行う。
【００６３】
周辺処理実行部１０４は、開発環境装置１，２等の外部機器とコミュニケーションを行うものである。具体的には、制御装置３内のあるメモリの情報を、制御装置とコミュニケーションするデバイス４へ送信したり、あるいは、デバイス４の値を受信して制御装置３内のあるメモリに格納することを行う。
【００６４】
次に、スケジューリング部１０１の処理をより詳細に説明する。Run状態、Pause状態のスケジューリング部の処理を図１１〜図１３のフローチャートに示す。この例では、処理の順番は、ＩＮリフレッシュ、周期タスク実行、ＯＵＴリフレッシュ実行、周辺処理実行という順番になっている。スケジューラは、サイクルタイムで示される周期で起動し、上記の処理を順番に実行する。以下、各処理について順に説明する。
【００６５】
まず、図１１のフローチャートに示されるＩＮリフレッシュに関する処理（ステップ１１０２〜１１０６）について説明する。
【００６６】
ＩＮリフレッシュ処理を開始するに際しては、それに先だって、現在の制御装置の状態を判定する。もし制御装置がPause状態の場合は、ＩＮリフレッシュは実行しないので、次の処理（図１２の周期タスク実行）に移る。
【００６７】
もし、制御装置がRun状態の場合は、表５に示される内容の情報と現在の制御装置のサイクル（ステップ１１０１でカウントされる）とから、実行すべきリフレッシュブロックとそのリフレッシュブロックが属する制御グループとを獲得する。なお、表５に示される内容の情報は、ＩＮとＯＵＴごとに存在する。次に、上記の処理で獲得した制御グループを実行すべきかどうかを表６に示される内容の情報から獲得する（ステップ１１０２）。
【００６８】
【表６】
【００６９】
スケジューリング部（図１０に符号１０１で示す）は、実行依頼したリフレッシュブロックが正常終了したのをリフレッシュブロック実行部から通知されると（ステップ１１０４ＹＥＳ）、次のリフレッシュブロックに関する処理を行う（ステップ１１０５ＮＯ，１１０１）。もし、異常終了が通知された場合は（ステップ１１０４ＮＯ）、スケジューラは異常処理（ステップＡ１〜Ａ４）を行う。
【００７０】
異常処理では、まず、表４に示される内容の情報より異常が発生したリフレッシュブロックはどのデバイスに対するものなのかを判定する。例として、もし、ＩＮリフレッシュブロック３で異常が発生した場合、デバイス５で異常が発生したことが、表４より判定できる。そして表２を使ってデバイス５に対するリフレッシュブロックを検索する。表４よりＩＮフレッシュブロック４についても実行を停止する必要があることがわかる。
【００７１】
次に、表５を使用して停止すべきリフレッシュブロックが存在する制御グループは、制御グループ１，２であることを判定する（ステップＡ１）。
【００７２】
次に、表６に停止すべき制御グループに対して無効であることを示す値を格納する（ステップＡ２）。
【００７３】
次に、制御装置は、表２を参照して「Ｉ／Ｏ致命的異常」に対するイベントタスクが定義されているかを検索し（ステップＡ３）、定義されていればイベントタスクを実行する（ステップＡ４）。スケジューラはイベントタスクの実行が終了すると、元の処理を行う。
【００７４】
以上が、ＩＮリフレッシュに関するスケジューラの処理である。ＯＵＴリフレッシュについても同一の処理（ステップ１３０１〜１３０５）である。
【００７５】
次に、命令実行部の処理（ステップ１２０１〜１２０５）について説明する。概要はＩＮリフレッシュ部と同じであるので、説明を簡略化する。
【００７６】
先ず、制御装置の状態を判定してPause状態であればＳＫＩＰする。表３を参照して実行すべき周期タスク、制御グループを獲得する（ステップ１２０１）。表６を参照して、実行すべき周期タスクの属する制御グループは実行が許可されているかを判定する。実行すべき周期タスクが複数存在する場合は、タスクプライオリティの高いものから実行する（ステップ１２０２，１２０３，１２０４，１２０５）。周期タスク実行部から異常が返ってきた場合は（ステップ１２０３ＮＯ）、異常処理を行う。異常処理では、異常が発生した制御グループを無効にするために、表６に無効を格納する。表５を参照して「命令実行異常イベント」に対するイベントタスクが定義されているかを判定して、定義されていればこれを実行する（ステップＡ１〜Ａ４）。元の処理を行う。周辺処理は、制御装置の状態に関わらず実行する（ステップ１３０６）。
【００７７】
［制御装置の実行］
制御装置は、開発環境等の外部機器からの指示を受けると、図４に示されるように、Initial状態に遷移する。Initial状態に遷移した場合、グローバルイベントであるInitialイベントと、各制御グループに対するInitialイベントが発行される。もし、説明したイベントに対するイベントタスクが定義されていた場合、タスクのプライオリティに従い実行される。もし、制御グループの初期処理を記述した制御グループに対するInitialイベントタスクの実行をシステム全体の初期処理を記述したグローバルなInitialイベントタスクの実行の後にしたい場合は、制御グループ１に対するInitialイベントタスクのタスクプライオリティをグローバルなInitialイベントタスクのタスクプライオリティより低く設定しておく。
【００７８】
上記の内容を表２および図９のフローチャートを参照して説明する。制御装置は、外部機器やユーザプログラム命令によって制御装置の状態をInitial状態に遷移する指示がきた場合、全ての制御グループをInitial状態に遷移させる命令なのか、特定の制御グループに対するものなのかを判定する（ステップ９０１）。
【００７９】
すべての制御グループの状態を遷移させる指示の場合は（ステップ９０１全ての制御グループ）、表２のInitialイベントに対するイベントタスク１０，１１，１２をタスクプライオリティに従い実行する。この場合、イベントタスク１０，１１，１２の順に実行される（ステップ９０３）。
【００８０】
Initial状態遷移の指示が特定の制御グループ１に対するものである場合（ステップ９０１特定の制御グループ）、表２より実行すべきイベントタスクはイベントタスク１１であることを判定し実行する（ステップ９０２）。
【００８１】
［命令実行異常発生時の処理］
図１０のスケジューリング部１０１の処理が、図１１〜図１３のフローチャートに示されている。
【００８２】
Run状態の制御装置において、周期タスク１において命令実行中に０除算や配列のオーバフロー等の致命的な異常が発生した場合（ステップ１１０２）、スケジューリング部１０１は、表１から周期タスク１が制御グループ１に属することを判定する。その結果、制御グループ１に属する周期タスク２、ＩＮリフレッシュブロック１〜３、ＯＵＴリフレッシュブロック１〜３、イベントタスク１〜３の処理を無効すべきと判定し、以降、制御グループ１に属する処理を行わない。
【００８３】
この場合、命令実行異常イベントが発生され、このイベントは制御グループに依存しないイベントであるため、このイベントに対するイベントタスクが実行される。もし、制御グループ同士に関連が存在して、他の制御グループの処理を停止させたい場合、あるいは制御を終了したい場合等、異常時の処理を定義したい場合は、このイベントタスクに制御グループ停止命令、あるいは制御終了命令を記述する。
【００８４】
なお、制御グループ停止命令とは、指定した（複数可能）制御グループの処理を停止する命令である。制御終了命令は、制御装置をSettle状態に遷移させて制御装置を運転停止状態にする命令である。
【００８５】
［デバイスの異常発生時の処理］
表４の例で、デバイス３で致命的な異常が発生した場合、表４からデバイス３はリフレッシュブロック１に属することがわかる。そしてリフレッシュブロック１は、表１から制御グループ１に属することが判明する。従って、制御装置は、制御グループ１に属する周期タスク２、ＩＮリフレッシュブロック１〜３、ＯＵＴリフレッシュブロック１〜３、イベントタスク１〜３の処理を停止する。
【００８６】
デバイスに対して致命的な異常が発生した場合は、デバイス異常システムイベントが発生する。このイベントは、制御グループに依存しないイベントである。このイベントに対するイベントタスクが定義されている場合は、制御装置はイベントタスクを実行する。
【００８７】
もし、制御グループ同士に関連が存在して、他の制御グループの処理を停止させたい場合、あるいは制御を終了したい場合等、異常時の処理を定義したい場合は、このイベントタスクに制御グループ停止命令、あるいは制御終了命令を記述する。
【００８８】
［デバッグ作業］
制御グループ１〜３がPause状態である場合において、外部機器から制御グループ１をRun状態に遷移させる命令を周辺処理で受信した場合、制御装置は以下の処理を行なう。
【００８９】
・制御グループ１に対するRunイベントを発行し、左記イベントに対するイベントタスクが定義されている場合は、制御装置はイベントタスクを実行する。
【００９０】
・制御グループ１をRun状態にする。すなわち、制御グループ１に属する周期タスク１〜２、ＩＮリフレッシュブロック１〜３、ＯＵＴリフレッシュブロック１〜３、イベントタスク１〜３の処理を実行する。
【００９１】
続いて、外部機器からRun状態にある制御グループ１に対し、以下のような命令を送り、制御グループ１の動作を検証する。
【００９２】
・Ｎサイクル実行命令（出願済み）
・指定イベントタスク実行命令（出願済み）
・データトレース命令（公知）
・強制セット・リセット命令（公知）
外部機器からRun状態にある制御グループ１をPause状態に遷移させる命令を周辺処理で受信した場合、制御装置は以下の処理を行なう。
【００９３】
・制御グループ１に対するPauseイベントを発行し、左記イベントに対するイベントタスクが定義されている場合は、制御装置はイベントタスクを実行する。
【００９４】
・制御グループ１をPause状態にする。
【００９５】
制御グループ１の動作が正常であることが確かめられた場合、次に制御グループ２，３と同様な処理を行ない、各制御グループ単体での動作検証を行なう。例えば制御グループ１と制御グループ２が協調動作している場合は、外部機器から制御グループ１と２をRun状態に遷移させる命令を制御装置に送信する。この命令を制御装置が受信した場合、図３のフローチャートに示される周辺処理でこの命令を認識し、制御グループ１と２をRun状態に遷移させる。それぞれの制御グループの状態遷移時の処理は上の説明と同様である。そして、Run状態にある制御グループ１と２の動作を検証する。
【００９６】
［全ての制御グループを同時に状態遷移させる場合］
例えば、全ての制御グループの動作を検証したい場合、全ての制御グループを同時に運転開始したい場合、全ての制御グループの運転を終了したい場合等がある。制御グループ１〜３がPause状態の場合において、全ての制御グループをInitial状態に遷移させる命令を制御装置が周辺処理で受信した場合、制御装置は、以下の処理を行なう。
【００９７】
・同時に▲１▼Initialイベント（グローバル）、▲２▼制御グループ１に対するInitialイベント（ローカル）、▲３▼制御グループ２に対するInitialイベント（ローカル）、▲４▼制御グループ３に対するInitialイベント（ローカル）を発生する。
【００９８】
・同時に発生したイベントに対するイベントタスクをタスクプライオリティに従い順に処理する。
【００９９】
・制御装置は、Initial状態の処理を実行し、指定された状態（Run/Pause）に遷移する。
【０１００】
上記のInitial以外の全ての制御グループの状態を遷移させる命令（Run，Pause，Settle）については、考え方は上記とまったく同じである（InitialをRun/Pause/Settleに読み替える）。
【０１０１】
［制御グループ内での制御グループの制御］
例えば、制御グループ１と２の間で協調動作をしていて、どちらか一方の制御グループで異常が発生した場合、他の制御グループの実行を無効にする必要が存在する場合がある。これを制御装置のシステムコール形式で実現し、このシステムコールをプログラム中に記述することが可能である。このシステムコールが記述されていた場合は、制御装置はシステムコールで記述されている制御グループの有効・無効制御を行なう。
【０１０２】
例えば、制御グループ１に属するイベントタスクにおいて上記システムコールで制御グループ２を無効にする内容を記述しておくと、左記イベントタスク実行要因（例：ロボット１の故障）が発生した場合、このイベントタスクの実行により、制御グループ２の処理が実行されなくなる。
【０１０３】
また、制御グループ１に属するイベントタスクで制御グループ２を有効にする内容を記述しておくと、左記イベントタスクを実行要因（例：ロボット１の故障復旧）が発生した場合、このイベントタスクの実行により、制御グループ２の処理が実行される。
【０１０４】
上記の例では、制御グループ２の処理を中止、再開する様子を説明したが、中止位置から再開するのではなく、制御グループ２を制御グループの初期処理から実行したい場合がある。この場合、上記と同様にシステムコールという形でユーザプログラムで記述する。
【０１０５】
例えば、制御グループ１に属するイベントタスク１（ロボット１故障）で制御グループ２を無効にするシステムコールを記述しておき、イベントタスク２（ロボット１故障復旧）で制御グループ２をInitial状態から実行するシステムコールを記述しておく。
【０１０６】
これにより、Run状態の制御グループ１，２がRun状態の場合に、ロボット１が故障した場合は、制御グループ２が無効状態となり、ロボット２の故障が復旧した場合、制御グループ１をRun状態にしたまま制御グループ２をInitial状態に遷移させ、初期処理を実行した後再び制御装置がRun状態になる。制御グループ２の状態遷移時は、サイクルタイム−スキャンタイムで計算される時間で処理される。
【０１０７】
［制御グループに属さない処理］
制御グループに共通な処理、あるいは、制御グループ間の制御を行なう処理は、制御グループに属さないようにしておく。たとえば、制御グループ間のインターロック等はこれにあたる。
【０１０８】
［その他］
本実施形態のように１つの装置（パソコン）内で複数の制御グループを実行することも可能であるが、各制御グループを別の制御装置で実行させることも可能である。
【０１０９】
すなわち、複数の制御グループを１つの制御装置で実行していた場合、制御装置自体に致命的な異常（ＭＰＵ故障）が発生した場合、全ての制御グループの実行が不可能となる。そのため、各制御グループをそれぞれ別の制御装置で実行させることが考えられる。この場合、分散した制御装置が全体としてどのような振る舞いをするかをシミュレーションする必要がある。本発明はこのようなケースにおいても有効である。
【０１１０】
この場合、本実施例のように１つの装置で開発環境で複数の制御グループを実行させて、複数の制御グループのデバッグ、シミュレーションを行う。制御グループとコミュニケーションするデバイスは実デバイスでなく、開発環境マシンのメモリで行ってもかまわない。各制御グループのデバッグ、シミュレーションを行った後、各制御グループを別々の制御装置にダウンロードする。これにより１つの制御装置で分散した制御装置上で動作する制御グループの動作をシミュレーション、デバッグすることが可能である。
【０１１１】
【発明の効果】
以上の実施形態の説明でも明らかなように、本発明によれば、制御グループを単位として異常処理、状態遷移処理を行うことにより、システムの正当性、モジュール性を向上させることができる。これによりプログラム作成、保守が容易となる。
【０１１２】
また、全ての制御グループの周期タスクはサイクルタイムの整数倍で動作するため、制御グループ間で同じメモリをアクセスしている場合でも、メモリの排他制御を行う必要がない。したがって、制御装置の性能に悪影響を及ぼさない。また、プログラムを作成する際は、メモリの排他制御を意識する必要がないため容易にプログラムを作成することができる。
【０１１３】
また、制御グループが複数存在する場合でも、ＩＮリフレッシュ、ＯＵＴリフレッシュは制御グループに関わらず一括で行うため、データの同時性に優れる。
【０１１４】
さらに、分散した制御装置の振る舞いを１台の制御装置（開発環境）でシミュレーション、デバッグを行うことが可能となる。
【図面の簡単な説明】
【図１】制御グループ定義内容の説明図である。
【図２】リフレッシュブロック定義内容の説明図である。
【図３】一巡実行サイクルのゼネラルふーちゃーとである。
【図４】制御装置の状態遷移図である。
【図５】周期タスクの動作態様を示す説明図である。
【図６】リフレッシュブロックの動作態様を示す説明図である。
【図７】システム全体の構成図である。
【図８】開発環境装置における作業手順を示すフローチャートである。
【図９】制御装置におけるイベントタスク選択実行処理を示すフローチャートである。
【図１０】制御装置内の処理ブロック図である。
【図１１】ＩＮリフレッシュに関するスケジューラの処理を示すフローチャートである。
【図１２】命令実行に関するスケジューラの処理を示すフローチャートである。
【図１３】ＯＵＴリフレッシュに関するスケジューラの処理を示すフローチャートである。
【図１４】制御ブロックと制御対象ブロックとの関係を示す説明図である。
【符号の説明】
１，２ 開発環境装置
３ シーケンスエンジン稼働装置（制御装置）
４ デバイス
１０１ スケジューリング部
１０２ リフレッシュブロック部
１０３ 周期タスク実行部
１０４ 周辺処理実行部
１０５ イベントタスク実行部
ａ タスクプライオリティ
ｂ 実行開始サイクルと周期
Claims (6)
- タスクプライオリティ、周期、実行開始サイクルをタスクのスケジューリング属性として持つ周期タスクと、周期、実行開始サイクルをタスクのスケジューリング属性として持つリフレッシュブロックと、タスクプライオリティをタスクのスケジューリング属性として持つイベントタスクと、で表現される任意の制御仕様を制御装置に実行させるための制御プログラムを開発するための制御プログラムの開発環境装置であって、
周期タスクとリフレッシュブロックとイベントタスクとで決まる１つの制御仕様の処理を１つの制御グループとして定義するとともに、その制御グループを複数個定義するための手段と、
前記１つの制御グループに対して、１若しくは２以上の周期タスクと、１若しくは２以上のリフレッシュブロックと、１若しくは２以上のイベントタスクとを入力するための手段と、
前記定義するための手段と入力するための手段との操作により、１つの制御グループとなる周期タスクとリフレッシュブロックとイベントタスクとの組を、該当する定義の制御グループに関連づけて記述され、その操作が各制御グループについて行なわれることにより、複数の制御グループを含んでなる制御プログラムを生成する手段と、
を具備することを特徴とする制御プログラムの開発環境装置。 - 請求項１に記載の開発環境装置の各構成手段をコンピュータにて実現するためのプログラムを記録した記録媒体。
- タスクプライオリティ、周期、実行開始サイクルをタスクのスケジューリング属性として持つ周期タスクと、周期、実行開始サイクルをタスクのスケジューリング属性として持つリフレッシュブロックと、タスクプライオリティをタスクのスケジューリング属性として持つイベントタスクと、で表現される任意の制御仕様に対応する制御プログラムを実行する制御装置であって、
１若しくは２以上の周期タスクと、１若しくは２以上のリフレッシュブロックと、１若しくは２以上のイベントタスクとからなる制御グループが複数グループ定義された制御プログラムを格納するための手段と、
前記制御プログラムを構成するすべての制御グループのすべてのリフレッシュブロック並びに全ての周期タスクを、唯一のサイクルタイムに同期して一括に実行する手段と、
を具備することを特徴とする制御プログラムを実行する制御装置。 - いずれかの制御グループで致命的な異常が発生した場合には、その制御グループに属する処理のみを停止し、その他の制御グループの処理は継続することを特徴とする請求項３に記載の制御プログラムを実行する制御装置。
- 制御グループの初期（ initial ）状態、稼働（ run ）状態、停止（ stop ）状態、終了（ settle ）状態の相互間における状態遷移に関して、すべての制御グループの状態を遷移させるモードと、特定の制御グループの状態を遷移させるモードとを併有することを特徴とする請求項３に記載の制御プログラムを実行する制御装置。
- 請求項３〜５のいずれかに記載の制御装置の各構成手段をコンピュータにて実現するためのプログラムを記録した記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10329099A JP3770366B2 (ja) | 1999-04-09 | 1999-04-09 | 制御プログラムの開発環境装置、制御プログラムを実行する制御装置、並びに、それらを実現するプログラムの記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10329099A JP3770366B2 (ja) | 1999-04-09 | 1999-04-09 | 制御プログラムの開発環境装置、制御プログラムを実行する制御装置、並びに、それらを実現するプログラムの記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000293210A JP2000293210A (ja) | 2000-10-20 |
| JP3770366B2 true JP3770366B2 (ja) | 2006-04-26 |
Family
ID=14350175
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP10329099A Expired - Fee Related JP3770366B2 (ja) | 1999-04-09 | 1999-04-09 | 制御プログラムの開発環境装置、制御プログラムを実行する制御装置、並びに、それらを実現するプログラムの記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3770366B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7761171B2 (en) * | 2006-09-29 | 2010-07-20 | Fisher-Rosemount Systems, Inc. | Methods and apparatus to generate schedules to execute functions in a process control system |
| JP4752983B1 (ja) | 2011-03-15 | 2011-08-17 | オムロン株式会社 | Ｐｌｃのｃｐｕユニット、ｐｌｃ用のシステムプログラムおよびｐｌｃ用のシステムプログラムを格納した記録媒体 |
| US8706262B2 (en) | 2011-03-15 | 2014-04-22 | Omron Corporation | CPU unit of PLC, system program for PLC, and recording medium storing system program for PLC |
| JP5845629B2 (ja) * | 2011-05-24 | 2016-01-20 | オムロン株式会社 | Ｐｌｃのｃｐｕユニット、ｐｌｃ用のシステムプログラムおよびｐｌｃ用のシステムプログラムを格納した記録媒体 |
| JP5099251B1 (ja) | 2011-07-15 | 2012-12-19 | オムロン株式会社 | Ｐｌｃのｃｐｕユニット、ｐｌｃ用のシステムプログラム、ｐｌｃ用のシステムプログラムを格納した記録媒体、ｐｌｃシステム、ｐｌｃサポート装置、ｐｌｃサポートプログラム、および、ｐｌｃサポートプログラムを格納した記録媒体 |
| JP2015060377A (ja) * | 2013-09-18 | 2015-03-30 | 株式会社日立産機システム | プログラマブルコントローラの入出力リフレッシュ方式 |
| JP6442843B2 (ja) | 2014-03-14 | 2018-12-26 | オムロン株式会社 | 制御装置 |
| JP2018200731A (ja) * | 2018-10-01 | 2018-12-20 | オムロン株式会社 | サポート装置およびサポートプログラム |
-
1999
- 1999-04-09 JP JP10329099A patent/JP3770366B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000293210A (ja) | 2000-10-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2692609B2 (ja) | マルチタスクのプログラムデバッグ方法とその装置 | |
| JP5791792B2 (ja) | 工作機械の工作プロセスをシミュレーションするシミュレーション方法およびシミュレーションシステム | |
| JP4529063B2 (ja) | システムシミュレータ、シミュレーション方法及びシミュレーションプログラム | |
| JP2006350549A (ja) | 統合シミュレーションシステム | |
| JPH0533423B2 (ja) | ||
| CN104898546B (zh) | 一种基于soc的plc在线调试系统和方法 | |
| JPH04216174A (ja) | ハードウェア・アクセラレータを用いた論理シミユレーション方法および装置 | |
| JPH05224911A (ja) | 動的命令修正制御装置 | |
| JP6945646B2 (ja) | 産業用プログラマブルロジックコントローラの、回復力を有しているフェイルオーバー | |
| US20020069045A1 (en) | Method of logical modeling of operator interaction with programmable logic controller logical verification system | |
| JP3770366B2 (ja) | 制御プログラムの開発環境装置、制御プログラムを実行する制御装置、並びに、それらを実現するプログラムの記録媒体 | |
| US5974346A (en) | Method for controlling technical processes | |
| CN102789206B (zh) | 机床数控中集中式和分布式控制混合的安全逻辑控制系统 | |
| JP6874706B2 (ja) | アプリケーションプログラムを生成する方法、装置、プログラム | |
| JP2861962B2 (ja) | コンピュータプログラムのシミュレーション装置および方法 | |
| WO1995032476A1 (en) | A system and method for creating design configurations and for controlling the execution of multiple design tools | |
| JP3526232B2 (ja) | ステップ実行型プログラマブルコントローラのオンラインエディット機能処理方法 | |
| JP3017352B2 (ja) | 監視制御システム及びそのシーケンス処理方式 | |
| JP2513142B2 (ja) | プログラムのシミュレ―タ装置 | |
| JPS58182709A (ja) | プログラムの編集及び転送機能付ロボツト制御方法 | |
| EP0664509A1 (en) | Method and apparatus for passing control from a first process to a second process | |
| JP4535663B2 (ja) | ステートマシン制御方式およびステートマシン | |
| JP2007249828A (ja) | プログラマブルコントローラシステム、プログラマブルコントローラのデバッグ方法、プログラミング支援プログラム、プログラマブルコントローラのデバッグ制御プログラム | |
| JPH11259107A (ja) | 制御装置 | |
| JP2020107206A (ja) | マイクロコンピュータ、デバッグ情報出力方法、およびデバッグシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051017 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051026 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051226 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060119 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060201 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100217 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110217 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110217 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120217 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120217 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130217 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140217 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |