JP2000293210A - 制御プログラムの開発環境装置、制御プログラムを実行する制御装置、並びに、それらを実現するプログラムの記録媒体 - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】複数の制御グループを制御するに当り、デバッ
グ効率の向上、システムカスタマイズ性の向上、プログ
ラミング容易性、制御の独立性を確保すること。 【解決手段】タスクのスケジューリング属性として、タ
スクプライオリティを持つイベントタスクと、周期、実
行開始サイクルを持つリフレッシュブロックと、これら
３者を持つ周期タスクと、で表現される任意の制御仕様
に対応する制御プログラムを実行する制御装置であっ
て、１若しくは２以上の周期タスク１０，１２と、１若
しくは２以上のリフレッシュブロック１，２，３と、１
若しくは２以上のイベントタスク５，６，７とからなる
制御グループが複数グループ定義された制御プログラム
を格納するための手段と、前記制御プログラムを構成す
るすべての制御グループのすべてのリフレッシュブロッ
ク並びに全ての周期タスクを、唯一のサイクルタイムに
同期して一括に実行する手段と、を具備する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、制御グループを単
位として異常処理、状態遷移処理を行うことにより、シ
ステムの正当性、モジュール性を向上させた制御装置に
関する。

【０００２】

【従来の技術】制御装置の設計において、制御中の異常
時にどのように対応するかに関しては、従来より様々な
考え方が存在する。

【０００３】例えば、制御装置とコミュニケーションす
るデバイスが複数存在するような制御システムにおいて
は、１つのデバイスで異常が発生した場合に、それとコ
ミュニケーションする制御装置の側を運転停止状態ある
いは運転継続状態のいずれにするかに関しては、予めシ
ステムで固定化しておくか、あるいは、プログラム作成
時にファイル等でパラメータライズ化可能とする異常時
対応方式（１）が採用される。

【０００４】また、１つの制御装置で複数の制御対象を
制御し、複数の制御対象に対するプログラムを１つある
いは複数のタスクで記述しているような制御システムに
おいては、あるタスクで０除算等の命令実行異常が発生
した場合には、制御装置で実行している全てのタスクを
強制的に停止させるか、あるいは構わず運転を継続させ
ると言った二者択一の異常時対応方式（２）が採用され
ている。

【０００５】また、制御システムによっては、外部機器
からの命令によって運転状態から運転停止状態にする
等、制御装置全体の状態を一括して変更する異常時対応
方式（３）も採用されている。

【０００６】また、制御システムによっては、制御装置
の起動時、終了時、異常時にそれぞれ特定の処理を実行
するようにプログラムしておき、それらの処理の中で複
数の制御対象に固有の必要な処理、システム全体に関わ
る処理をユーザが任意に記述できるようにした異常時対
応方式（４）も採用されている。

【０００７】さらに、制御システムによっては、複数の
制御対象を制御する場合、個々の制御対象の異常に容易
に対応できるように、複数の制御装置で制御を行う異常
対応方式（５）も採用されている。

【０００８】

【発明が解決しようとする課題】しかしながら、上述の
異常時対応方式（１）にあっては、あるデバイスで異常
が発生した場合に、制御装置全体を運転停止させるよう
な処理を設定すると、他の制御対象を制御しているデバ
イスが正常であるにも拘わらず、システム全体が停止し
てしまう。制御対象間の関係が粗なシステムでは、この
ような一括停止処理は適さない。逆に、いずれのデバイ
スで異常が発生しても、制御装置全体の運転が継続され
るような処理を設定すると、制御対象間が密なシステム
では、システム全体として整合のとれた制御を行なうこ
とができない。

【０００９】上述の異常時対応方式（２）にあっては、
ある制御対象を制御するためのタスクが複数存在する場
合、それらのタスクのうち、ある１つのタスクで命令実
行異常が発生した場合に、制御装置の運転を継続させる
とその制御対象に対する制御が整合性のとれたものにな
らない。一方、あるタスクで異常が発生した場合に、シ
ステム全体の運転を停止させてしまうと、制御対象間で
粗な関係のシステムでは、粗な関係にある制御対象に対
する制御まで（正常に動作しているにも拘わらず）停止
してしまう。

【００１０】上述の異常時対応方式（３）にあっては、
複数の制御対象を制御するシステムにおいて、システム
をデバッグ（シミュレーション）する際に、特定の制御
対象に対する処理だけを実行させてデバッグを行い、次
に別の制御対象について同様にしてデバッグを行うと言
った手順、あるいは、ＡとＢという制御対象に関する処
理だけを実行させてデバッグを行うと言った手順でBuil
d Up式のデバッグができないため、プログラム開発時に
どこに不具合が存在するかを特定することが困難であ
る。また、運転中の制御装置においてある制御対象に関
して異常が発生した場合に、その制御対象に対する処理
だけを停止し、その制御対象だけに終了処理を実行する
ことはできない。

【００１１】上述の異常時対応方式（４）にあっては、
制御装置の起動時、終了時などに１つのタスクにすべて
の制御対象に関する処理、終了処理を記述していた場
合、ある制御対象で異常が発生してその制御対象に対す
る制御処理を行なう必要がないにも拘わらず、起動処
理、終了処理が実行されてしまう。また、１つのタスク
にすべての制御対象に対する処理を記述した場合、制御
対象に対する処理の順番に依存性がある場合で順番を変
更しようとした場合、プログラムの記述を大幅に変更す
る必要が生じる。

【００１２】上述の異常時対応方式（５）にあっては、
複数の制御装置で複数の制御対象を制御している場合、
シミュレーション、デバッグは、各制御装置個々で行っ
ているため、複数の制御装置でシステムの動きが分かる
ようなシステムの場合、全体の動作検証を１つの環境で
行うことが困難である。

【００１３】この発明は、上述の問題点に着目してなさ
れたものであり、周期タスク、イベントタスク、リフレ
ッシュブロックといった処理の単位を１つの制御グルー
プとして定義すると共に、この複数の制御グループを１
つの環境で実行し、制御グループ毎に最適な異常処理、
状態遷移時の処理を実現することにより、デバッグ効率
の向上、システムカスタマイズ性の向上、プログラミン
グ容易性、制御の独立性を確保することを目的とする。

【００１４】

【課題を解決するための手段】この出願の請求項１に記
載の発明は、タスクプライオリティ、周期、実行開始サ
イクルをタスクのスケジューリング属性として持つ周期
タスクと、周期、実行開始サイクルをタスクのスケジュ
ーリング属性として持つリフレッシュブロックと、タス
クプライオリティをタスクのスケジューリング属性とし
て持つイベントタスクと、で表現される任意の制御仕様
に基づいて、制御プログラムを開発するための制御プロ
グラムの開発環境装置であって、１若しくは２以上の周
期タスクと、１若しくは２以上のリフレッシュブロック
と、１若しくは２以上のイベントタスクとを１つの制御
グループとして入力するための手段と、前記１つの制御
グループとして入力される周期タスクと、リフレッシュ
ブロックと、イベントタスクとの組を該当する制御グル
ープと関連づけて記述する操作を、各制御グループにつ
いて繰り返すことにより、目的とする制御プログラムを
生成する手段と、を具備することを特徴とする制御プロ
グラムの開発環境装置にある。

【００１５】この出願の請求項２に記載の発明は、請求
項１に記載の開発環境装置の各構成手段の全部若しくは
一部をコンピュータにて実現するためのプログラムを記
録した記録媒体にある。

【００１６】この出願の請求項３に記載の発明は、タス
クプライオリティ、周期、実行開始サイクルをタスクの
スケジューリング属性として持つ周期タスクと、周期、
実行開始サイクルをタスクのスケジューリング属性とし
て持つリフレッシュブロックと、タスクプライオリティ
をタスクのスケジューリング属性として持つイベントタ
スクと、で表現される任意の制御仕様に対応する制御プ
ログラムを実行する制御装置であって、１若しくは２以
上の周期タスクと、１若しくは２以上のリフレッシュブ
ロックと、１若しくは２以上のイベントタスクとからな
る制御グループが複数グループ定義された制御プログラ
ムを格納するための手段と、前記制御プログラムを構成
するすべての制御グループのすべてのリフレッシュブロ
ック並びに全ての周期タスクを、唯一のサイクルタイム
に同期して一括に実行する手段と、を具備することを特
徴とする制御プログラムを実行する制御装置にある。

【００１７】この出願の請求項４に記載の発明は、いず
れかの制御グループで致命的な異常が発生した場合に
は、その制御グループに属する処理のみを停止し、その
他の制御グループの処理は継続することを特徴とする請
求項３に記載の制御プログラムを実行する制御装置にあ
る。

【００１８】この出願の請求項５に記載の発明は、制御
グループの状態遷移に関して、すべての制御グループの
状態を遷移させるモードと、特定の制御グループの状態
を遷移させるモードとを併有することを特徴とする請求
項３に記載の制御プログラムを実行する制御装置にあ
る。

【００１９】この出願の請求項６に記載の発明は、請求
項３〜５のいずれかに記載の制御装置の各構成手段の全
部若しくは一部をコンピュータにて実現するためのプロ
グラムを記録した記録媒体にある。

【００２０】以上の発明の意図はつぎのように説明され
る。本発明は、周期タスク、イベントタスク、リフレッ
シュブロックといった処理の単位を１つの制御部グルー
プとして定義することで、１つの制御装置内に論理的な
制御装置を複数定義可能とする。

【００２１】各制御グループは、お互いに独立して動作
するのではない。

【００２２】すなわち、ＩＮリフレッシュする場合は、
全ての制御グループのすべてのＩＮリフレッシュブロッ
クをスケジューリング属性に従い実行する（制御グルー
プに拘わらず、ＩＮリフレッシュは一括で行う）。

【００２３】周期タスクを実行する場合は、全ての制御
グループのすべての周期タスクをスケジューリング属性
に従い実行する（制御グループに関わらず周期タスクの
実行は一括して行う）。

【００２４】ＯＵＴリフレッシュする場合は、全ての制
御グループのすべてのＯＵＴリフレッシュブロックをス
ケジューリング属性に従い実行する（制御グループに拘
わらずＯＵＴリフレッシュは一括して行う）。

【００２５】上記の結果、システムの処理は制御グルー
プに拘わらず、ＯＵＴリフレッシュ→周期タスク実行→
ＯＵＴリフレッシュの実行手順となる。

【００２６】なお、周期タスク、リフレッシュブロック
の実行は、システムが唯一もつサイクルタイムに同期し
て動作する。例えば、サイクルタイムが１０msecの場合
は、周期タスク、リフレッシュブロックはこのサイクル
タイムの整数倍でしか動作しない。これにより制御グル
ープ間のメモリの排他制御が不要となる。

【００２７】異常処理については、制御グループで致命
的な異常が発生した場合、その制御グループに属する処
理（周期タスク、リフレッシュブロック、イベントタス
ク）のみを停止し、その他の制御グループの処理は継続
実行する。

【００２８】制御グループの状態遷移については、制御
グループ全体を遷移させる方法と特定の制御グループの
状態を遷移させることとの双方が可能である。

【００２９】

【発明の実施の形態】以下に、本発明の好適な実施の一
形態を添付図面並びに表を参照しつつ詳細に説明する。

【００３０】先ず、図７に従って、本発明が適用された
システムの概要を説明する。同図において、符号１，２
が付されているのは、制御装置で実行されるべきプログ
ラムを作成するための開発環境装置（この例では、パソ
コンで構成される）である。これらの開発環境装置１，
２は、例えばパソコン上で動作するプログラムを主体と
して構成されている。開発環境装置１，２で作成された
制御プログラム（シーケンス制御プログラム等）は、パ
ソコンのメモリ、ＨＤＤ等の記録媒体に記録される。

【００３１】符号３が付されているのは、本発明の制御
装置に相当するシーケンスエンジン稼働装置である。こ
のシーケンスエンジン稼働装置３も、例えばパソコン上
で動作するプログラムを主体として構成されている。

【００３２】開発環境装置１，２と制御装置であるシー
ケンスエンジン稼働装置３とは、ネットワークで接続さ
れている複数台のパソコンで構成される場合と、１台の
パソコン上に、開発環境装置１，２と制御装置であるシ
ーケンスエンジン可動装置とに相当するソフトウェアを
組み込むことで構成される場合とがある。

【００３３】開発環境装置１，２で開発されて記録媒体
上に格納された制御プログラムは、制御装置であるシー
ケンスエンジン稼働装置３に転送されて、同じくメモ
リ、ＨＤＤ等の記録媒体に格納される。

【００３４】制御装置であるシーケンスエンジン稼働装
置３は、コミュニケーションを介して結ばれた１若しく
は２以上のデバイス４に対してプログラムの演算結果を
出力する。またデバイス４のデータを獲得してプログラ
ムの演算を行う。

【００３５】開発環境装置１，２で行なわれる作業の流
れが図８のフローチャートに示されている。以下、図８
に従って、開発環境装置１，２における作業内容を詳細
に説明する。

【００３６】［制御グループの定義］プログラム開発時
には、図１に示されるように、プログラム開発ツール上
で制御グループを定義する（ステップ８０１ＹＥＳ，８
０２）。

【００３７】図から明らかなように、この例では、制御
グループ１には、３つのイベントタスク（イベントタス
ク１，２，３）と、２つの周期タスク（周期タスク１，
２）と、３つのリフレッシュブロック（リフレッシュブ
ロック１，２，３）とが定義されている。

【００３８】また、制御グループに属さないものとして
は、３つのイベントタスク（電源イベントタスク１，Ｉ
／Ｏ異常タスク２，Initialイベントタスク）と、１つ
の周期タスク（周期タスク１０）と、１つのリフレッシ
ュブロック（リフレッシュブロック１０）とが定義され
ている。

【００３９】なお、後に詳述するが、図１において、符
号ａで示される（ ）内の数値はタスクプライオリテ
ィ、符号ｂで示される（ ）内の一対の数値は実行開始
サイクルと周期、符号ｃで示されるものは同一スケジュ
ーリング属性をもつもの同士を結合する直線である。例
えば、制御グループ１内の周期タスク１を例に取ると、
そのタスクプライオリティは『１０』、実行開始サイク
ルは『１』、周期は『２』であることが理解される。

【００４０】開発環境装置１，２において制御グループ
が定義されると、パソコンのメモリ上あるいはハードデ
ィスク等の記録媒体上には、例えば表１に示されるよう
な情報が生成される。表１の例では、各制御グループ毎
に、『周期タスク名』、『ＩＮリフレッシュブロック
名』、『ＯＵＴリフレッシュブロック名』、『イベント
タスク名』が関連づけて記憶されている。

【００４１】

【表１】 ［イベント、イベントタスクの定義］制御グループの定
義に続いて、イベント・イベントタスクを定義する（ス
テップ８０３）。イベントには、制御グループ内で有効
な（制御グループが無効状態の場合はイベントを発生し
ない）ローカルイベントと、制御グループの状態に関係
なく発生するグローバルイベントとが存在する。

【００４２】グローバルイベントには、電断発生イベン
ト、電断解除イベント、デバイス異常イベント、Initia
lイベント、Runイベント、Pauseイベント、Settleイベ
ント等が存在する。

【００４３】状態遷移に関わるInitial，Run，Pause，S
ettleイベント（グローバルイベント）について説明す
る。Initialイベントとは、全ての制御グループを同時
にInitial状態に遷移させた場合に発生するグローバル
イベントである。個々の制御グループをInitial状態に
遷移させた場合は、本イベントは発生しない。本イベン
トが発生する場合は、各制御グループに対するInitial
イベントが発生する。各制御グループに対するInitial
イベントタスクの実行順序、あるいは、制御グループに
対するInitialイベントタスクと（グローバルな）Initi
alイベントタスクの実行順序は、タスクプライオリティ
によって決定される。

【００４４】Run，Pause，Settleイベントに対する考え
方も上記のInitialイベントと全く同じである（Initial
をそれぞれの状態に読み替える）。

【００４５】イベントタスクでは、イベント、タクスプ
ライオリティ、イベントタスクで実行されるプログラム
を定義する。イベントタスクは、図３の一巡実行サイク
ルのゼネラルフローチャートに示されるプリエンプティ
ブポイントで実行される。

【００４６】開発環境装置１，２においてイベントタス
クが定義されると、パソコンのメモリ上あるいはハード
ディスク等の記録媒体上には、例えば表２に示されるよ
うな情報が生成される。表２の例では、各カテゴリ毎
に、『イベント名』、『タスク名』、『制御グループ
名』、『タスクプライオリティ』が関連づけて記憶され
ている。

【００４７】

【表２】 ［周期タスクの定義］イベント・イベントタスクの定義
に続いて、周期タスクを定義する（ステップ８０４）。
周期タスクには、制御グループ内で有効な（制御グルー
プが無効状態の場合は、実行されない）周期タスクと、
制御グループの状態に拘わらず実行される周期タスクが
存在する。

【００４８】周期タスクでは、周期タスクのスケジュー
リング属性（実行開始サイクル、周期、タスクプライオ
リティ）と周期タスクで実行されるプログラムを定義す
る。周期タスクの制御装置内での動作態様は、図５に示
されている。

【００４９】開発環境装置１，２において周期タスクが
定義されると、パソコンのメモリ上あるいはハードディ
スク等の記録媒体上には、例えば表３に示されるような
情報が生成される。周期タスクの属性には、周期、実行
開始サイクル、タスクプライオリティが存在する。周期
と開始サイクルの意味はリフレッシュブロックと同じで
ある。タスクプライオリティは同一周期に実行すべき周
期タスクが複数あった場合の実行順序を意味する。表３
の例では、各タスク名毎に、『周期』、『実行開始サイ
クル』、『タスクプライオリティ』、『制御グループ
名』が関連づけて記憶されている。

【００５０】

【表３】 ［リフレッシュブロックの定義］周期タスクの定義に続
いて、リフレッシュブロックを定義する（ステップ８０
５）。リフレッシュブロックには、制御グループ内で有
効な（制御グループが無効状態の場合はリフレッシュブ
ロックを実行しない）リフレッシュブロックと、制御グ
ループの状態に関わらず実行されるリフレッシュブロッ
クが存在する。

【００５１】リフレッシュブロックを定義する際は、図
２に示されるように、デバイスタイプ、デバイス名、Ｉ
／Ｏ名を定義する。リフレッシュブロックには、以下に
示す３つの場合がある。

【００５２】１つのデバイスで１つのリフレッシュブ
ロックを構成する場合（図２のＩ−１，Ｏ−１の場合） 複数のデバイスで１つのリフレッシュブロックを構成
する場合（図２のＩ−２，Ｏ−２の場合） １つのデバイスで複数のリフレッシュブロックを構成
する場合（図２のＩ−３，Ｉ−４，Ｏ−３，Ｏ−４の場
合） リフレッシュブロックの制御装置内の動作態様は、図６
に示されている。

【００５３】開発環境装置１，２においてリフレッシュ
ブロックが定義されると、パソコンのメモリ上あるいは
ハードディスク等の記録媒体上には、例えば表４，表５
に示されるような情報が生成される。リフレッシュブロ
ックの属性には、周期と開始サイクルがある。周期は、
制御装置がもつサイクルタイムの倍数を示す（サイクル
タイムが１０msecで、周期が５の場合は、１０×５で５
０msecの実行周期を持つことを示す）。また、開始サイ
クルとは、制御装置がサイクル動作を開始した場合に、
何サイクル目からリフレッシュブロックの実行を行うか
を定義するものである。表４の例では、ＩＮリフレッシ
ュブロック毎に、『デバイス名』が記憶されている。ま
た、表５の例では、各リフレッシュブロック毎に、『周
期』、『実行開始サイクル』、『制御グループ名』が関
連づけて記憶されている。

【００５４】

【表４】

【表５】 ［開発環境から制御装置実行環境へのプロジェクトのダ
ウンロード］すべての制御グループに関する定義が完了
したならば（ステップ８１０ＹＥＳ）、図７に示される
開発環境装置１，２で生成し、開発環境装置１，２のメ
モリ上あるいはハードディスク等の記録媒体に格納され
ている情報（表１，２，３，４，５に示される）をネッ
トワーク等を通じてシーケンスエンジン稼働環境３にダ
ウンロードする（ステップ８１１ＹＥＳ，８１２）。す
ると、ダウンロードされた情報は、可動装置３内のメモ
リあるいはハードディスク等の記録媒体に格納される。

【００５５】［制御装置の動作］次に、制御装置である
シーケンスエンジン稼働装置３の動作の概略を、図３の
フローチャート、図４の状態遷移図、並びに、図１０の
ブロック図を参照して説明する。

【００５６】まず、制御装置であるシーケンスエンジン
稼働装置３の状態について説明する。制御装置であるシ
ーケンスエンジン稼働装置３は、開発環境装置１，２か
ら運転の指示を受けると図４の状態遷移図に示すInitia
l状態に遷移する。Initial状態では、制御装置３のシス
テムの初期処理、あるいは、制御装置３がInitialイベ
ントを発生させてユーザが定義したInitialイベントタ
スクを実行する。

【００５７】Initial状態の処理が終わると制御装置は
ユーザがあらかじめ定義した情報に従ってRun状態かPau
se状態に遷移する。このとき、Run状態に遷移する場合
には、制御装置はRunイベントを発生させ、ユーザが定
義したRunイベントタスクがあればこれを実行する。Pau
se状態に遷移する場合も同様である。Pause状態は、図
３に示されるのＯＵＴリフレッシュ、ＩＮリフレッシ
ュ、命令実行が実行されず周辺処理のみを行っている状
態である。

【００５８】なお、Settle状態は、制御装置のシステム
終了処理、あるいは、制御装置がSettleイベントを発生
させSettleイベントタスクが定義されていればこれを実
行する状態である。

【００５９】次に、制御装置３の内部処理について説明
する。制御装置３内の処理ブロック図を図１０に示す。
同図に示されるように、制御装置３の内部処理は、スケ
ジューリング部１０１と、リフレッシュブロック実行部
１０２と、周期タスク実行部１０３と、周辺処理実行部
１０４と、イベントタスク実行部１０５とから構成され
ている。

【００６０】スケジューリング部１０１は、開発環境装
置１，２からダウンロードされてきた表３，４に示され
る情報を基に、実行すべき周期タスクやリフレッシュブ
ロックを決定し、各処理実行部１０２〜１０５に処理を
依頼する。周期タスク、ＩＮリフレッシュ、ＯＵＴリフ
レッシュ、周辺処理をどのような順番で実行するかは、
システムで固定である場合、あるいは記憶媒体によりパ
ラメータライズ化されている場合の２通りがある。

【００６１】リフレッシュブロック処理部１０２は、ス
ケジューリング部１０１から指示されたリフレッシュブ
ロックを実行するものである。

【００６２】周期タスク実行部１０３は、スケジューリ
ング部１０１から指示された周期タスクを実行するもの
である。具体的には、制御装置内のメモリに格納された
値に対してプログラムに従い演算し、演算結果を制御装
置内のメモリに格納する処理を行う。

【００６３】周辺処理実行部１０４は、開発環境装置
１，２等の外部機器とコミュニケーションを行うもので
ある。具体的には、制御装置３内のあるメモリの情報
を、制御装置とコミュニケーションするデバイス４へ送
信したり、あるいは、デバイス４の値を受信して制御装
置３内のあるメモリに格納することを行う。

【００６４】次に、スケジューリング部１０１の処理を
より詳細に説明する。Run状態、Pause状態のスケジュー
リング部の処理を図１１〜図１３のフローチャートに示
す。この例では、処理の順番は、ＩＮリフレッシュ、周
期タスク実行、ＯＵＴリフレッシュ実行、周辺処理実行
という順番になっている。スケジューラは、サイクルタ
イムで示される周期で起動し、上記の処理を順番に実行
する。以下、各処理について順に説明する。

【００６５】まず、図１１のフローチャートに示される
ＩＮリフレッシュに関する処理（ステップ１１０２〜１
１０６）について説明する。

【００６６】ＩＮリフレッシュ処理を開始するに際して
は、それに先だって、現在の制御装置の状態を判定す
る。もし制御装置がPause状態の場合は、ＩＮリフレッ
シュは実行しないので、次の処理（図１２の周期タスク
実行）に移る。

【００６７】もし、制御装置がRun状態の場合は、表５
に示される内容の情報と現在の制御装置のサイクル（ス
テップ１１０１でカウントされる）とから、実行すべき
リフレッシュブロックとそのリフレッシュブロックが属
する制御グループとを獲得する。なお、表５に示される
内容の情報は、ＩＮとＯＵＴごとに存在する。次に、上
記の処理で獲得した制御グループを実行すべきかどうか
を表６に示される内容の情報から獲得する（ステップ１
１０２）。

【００６８】

【表６】 表６に示される内容の情報により制御グループが実行す
べきであった場合は、リフレッシュブロック実行部（図
１０に符号１０２で示す）に実行すべきリフレッシュブ
ロックを指定して実行依頼する（ステップ１１０３）。
もし、表６により実行すべきでない制御グループであっ
た場合は、このリフレッシュブロックは実行しない。

【００６９】スケジューリング部（図１０に符号１０１
で示す）は、実行依頼したリフレッシュブロックが正常
終了したのをリフレッシュブロック実行部から通知され
ると（ステップ１１０４ＹＥＳ）、次のリフレッシュブ
ロックに関する処理を行う（ステップ１１０５ＮＯ，１
１０１）。もし、異常終了が通知された場合は（ステッ
プ１１０４ＮＯ）、スケジューラは異常処理（ステップ
Ａ１〜Ａ４）を行う。

【００７０】異常処理では、まず、表４に示される内容
の情報より異常が発生したリフレッシュブロックはどの
デバイスに対するものなのかを判定する。例として、も
し、ＩＮリフレッシュブロック３で異常が発生した場
合、デバイス５で異常が発生したことが、表４より判定
できる。そして表２を使ってデバイス５に対するリフレ
ッシュブロックを検索する。表４よりＩＮフレッシュブ
ロック４についても実行を停止する必要があることがわ
かる。

【００７１】次に、表５を使用して停止すべきリフレッ
シュブロックが存在する制御グループは、制御グループ
１，２であることを判定する（ステップＡ１）。

【００７２】次に、表６に停止すべき制御グループに対
して無効であることを示す値を格納する（ステップＡ
２）。

【００７３】次に、制御装置は、表２を参照して「Ｉ／
Ｏ致命的異常」に対するイベントタスクが定義されてい
るかを検索し（ステップＡ３）、定義されていればイベ
ントタスクを実行する（ステップＡ４）。スケジューラ
はイベントタスクの実行が終了すると、元の処理を行
う。

【００７４】以上が、ＩＮリフレッシュに関するスケジ
ューラの処理である。ＯＵＴリフレッシュについても同
一の処理（ステップ１３０１〜１３０５）である。

【００７５】次に、命令実行部の処理（ステップ１２０
１〜１２０５）について説明する。概要はＩＮリフレッ
シュ部と同じであるので、説明を簡略化する。

【００７６】先ず、制御装置の状態を判定してPause状
態であればＳＫＩＰする。表３を参照して実行すべき周
期タスク、制御グループを獲得する（ステップ１２０
１）。表６を参照して、実行すべき周期タスクの属する
制御グループは実行が許可されているかを判定する。実
行すべき周期タスクが複数存在する場合は、タスクプラ
イオリティの高いものから実行する（ステップ１２０
２，１２０３，１２０４，１２０５）。周期タスク実行
部から異常が返ってきた場合は（ステップ１２０３Ｎ
Ｏ）、異常処理を行う。異常処理では、異常が発生した
制御グループを無効にするために、表６に無効を格納す
る。表５を参照して「命令実行異常イベント」に対する
イベントタスクが定義されているかを判定して、定義さ
れていればこれを実行する（ステップＡ１〜Ａ４）。元
の処理を行う。周辺処理は、制御装置の状態に関わらず
実行する（ステップ１３０６）。

【００７７】［制御装置の実行］制御装置は、開発環境
等の外部機器からの指示を受けると、図４に示されるよ
うに、Initial状態に遷移する。Initial状態に遷移した
場合、グローバルイベントであるInitialイベントと、
各制御グループに対するInitialイベントが発行され
る。もし、説明したイベントに対するイベントタスクが
定義されていた場合、タスクのプライオリティに従い実
行される。もし、制御グループの初期処理を記述した制
御グループに対するInitialイベントタスクの実行をシ
ステム全体の初期処理を記述したグローバルなInitial
イベントタスクの実行の後にしたい場合は、制御グルー
プ１に対するInitialイベントタスクのタスクプライオ
リティをグローバルなInitialイベントタスクのタスク
プライオリティより低く設定しておく。

【００７８】上記の内容を表２および図９のフローチャ
ートを参照して説明する。制御装置は、外部機器やユー
ザプログラム命令によって制御装置の状態をInitial状
態に遷移する指示がきた場合、全ての制御グループをIn
itial状態に遷移させる命令なのか、特定の制御グルー
プに対するものなのかを判定する（ステップ９０１）。

【００７９】すべての制御グループの状態を遷移させる
指示の場合は（ステップ９０１全ての制御グループ）、
表２のInitialイベントに対するイベントタスク１０，
１１，１２をタスクプライオリティに従い実行する。こ
の場合、イベントタスク１０，１１，１２の順に実行さ
れる（ステップ９０３）。

【００８０】Initial状態遷移の指示が特定の制御グル
ープ１に対するものである場合（ステップ９０１特定の
制御グループ）、表２より実行すべきイベントタスクは
イベントタスク１１であることを判定し実行する（ステ
ップ９０２）。

【００８１】［命令実行異常発生時の処理］図１０のス
ケジューリング部１０１の処理が、図１１〜図１３のフ
ローチャートに示されている。

【００８２】Run状態の制御装置において、周期タスク
１において命令実行中に０除算や配列のオーバフロー等
の致命的な異常が発生した場合（ステップ１１０２）、
スケジューリング部１０１は、表１から周期タスク１が
制御グループ１に属することを判定する。その結果、制
御グループ１に属する周期タスク２、ＩＮリフレッシュ
ブロック１〜３、ＯＵＴリフレッシュブロック１〜３、
イベントタスク１〜３の処理を無効すべきと判定し、以
降、制御グループ１に属する処理を行わない。

【００８３】この場合、命令実行異常イベントが発生さ
れ、このイベントは制御グループに依存しないイベント
であるため、このイベントに対するイベントタスクが実
行される。もし、制御グループ同士に関連が存在して、
他の制御グループの処理を停止させたい場合、あるいは
制御を終了したい場合等、異常時の処理を定義したい場
合は、このイベントタスクに制御グループ停止命令、あ
るいは制御終了命令を記述する。

【００８４】なお、制御グループ停止命令とは、指定し
た（複数可能）制御グループの処理を停止する命令であ
る。制御終了命令は、制御装置をSettle状態に遷移させ
て制御装置を運転停止状態にする命令である。

【００８５】［デバイスの異常発生時の処理］表４の例
で、デバイス３で致命的な異常が発生した場合、表４か
らデバイス３はリフレッシュブロック１に属することが
わかる。そしてリフレッシュブロック１は、表１から制
御グループ１に属することが判明する。従って、制御装
置は、制御グループ１に属する周期タスク２、ＩＮリフ
レッシュブロック１〜３、ＯＵＴリフレッシュブロック
１〜３、イベントタスク１〜３の処理を停止する。

【００８６】デバイスに対して致命的な異常が発生した
場合は、デバイス異常システムイベントが発生する。こ
のイベントは、制御グループに依存しないイベントであ
る。このイベントに対するイベントタスクが定義されて
いる場合は、制御装置はイベントタスクを実行する。

【００８７】もし、制御グループ同士に関連が存在し
て、他の制御グループの処理を停止させたい場合、ある
いは制御を終了したい場合等、異常時の処理を定義した
い場合は、このイベントタスクに制御グループ停止命
令、あるいは制御終了命令を記述する。

【００８８】［デバッグ作業］制御グループ１〜３がPa
use状態である場合において、外部機器から制御グルー
プ１をRun状態に遷移させる命令を周辺処理で受信した
場合、制御装置は以下の処理を行なう。

【００８９】・制御グループ１に対するRunイベントを
発行し、左記イベントに対するイベントタスクが定義さ
れている場合は、制御装置はイベントタスクを実行す
る。

【００９０】・制御グループ１をRun状態にする。すな
わち、制御グループ１に属する周期タスク１〜２、ＩＮ
リフレッシュブロック１〜３、ＯＵＴリフレッシュブロ
ック１〜３、イベントタスク１〜３の処理を実行する。

【００９１】続いて、外部機器からRun状態にある制御
グループ１に対し、以下のような命令を送り、制御グル
ープ１の動作を検証する。

【００９２】 ・Ｎサイクル実行命令（出願済み） ・指定イベントタスク実行命令（出願済み） ・データトレース命令（公知） ・強制セット・リセット命令（公知） 外部機器からRun状態にある制御グループ１をPause状態
に遷移させる命令を周辺処理で受信した場合、制御装置
は以下の処理を行なう。

【００９３】・制御グループ１に対するPauseイベント
を発行し、左記イベントに対するイベントタスクが定義
されている場合は、制御装置はイベントタスクを実行す
る。

【００９４】・制御グループ１をPause状態にする。

【００９５】制御グループ１の動作が正常であることが
確かめられた場合、次に制御グループ２，３と同様な処
理を行ない、各制御グループ単体での動作検証を行な
う。例えば制御グループ１と制御グループ２が協調動作
している場合は、外部機器から制御グループ１と２をRu
n状態に遷移させる命令を制御装置に送信する。この命
令を制御装置が受信した場合、図３のフローチャートに
示される周辺処理でこの命令を認識し、制御グループ１
と２をRun状態に遷移させる。それぞれの制御グループ
の状態遷移時の処理は上の説明と同様である。そして、
Run状態にある制御グループ１と２の動作を検証する。

【００９６】［全ての制御グループを同時に状態遷移さ
せる場合］例えば、全ての制御グループの動作を検証し
たい場合、全ての制御グループを同時に運転開始したい
場合、全ての制御グループの運転を終了したい場合等が
ある。制御グループ１〜３がPause状態の場合におい
て、全ての制御グループをInitial状態に遷移させる命
令を制御装置が周辺処理で受信した場合、制御装置は、
以下の処理を行なう。

【００９７】・同時にInitialイベント（グローバ
ル）、制御グループ１に対するInitialイベント（ロ
ーカル）、制御グループ２に対するInitialイベント
（ローカル）、制御グループ３に対するInitialイベ
ント（ローカル）を発生する。

【００９８】・同時に発生したイベントに対するイベン
トタスクをタスクプライオリティに従い順に処理する。

【００９９】・制御装置は、Initial状態の処理を実行
し、指定された状態（Run/Pause）に遷移する。

【０１００】上記のInitial以外の全ての制御グループ
の状態を遷移させる命令（Run，Pause，Settle）につい
ては、考え方は上記とまったく同じである（InitialをR
un/Pause/Settleに読み替える）。

【０１０１】［制御グループ内での制御グループの制
御］例えば、制御グループ１と２の間で協調動作をして
いて、どちらか一方の制御グループで異常が発生した場
合、他の制御グループの実行を無効にする必要が存在す
る場合がある。これを制御装置のシステムコール形式で
実現し、このシステムコールをプログラム中に記述する
ことが可能である。このシステムコールが記述されてい
た場合は、制御装置はシステムコールで記述されている
制御グループの有効・無効制御を行なう。

【０１０２】例えば、制御グループ１に属するイベント
タスクにおいて上記システムコールで制御グループ２を
無効にする内容を記述しておくと、左記イベントタスク
実行要因（例：ロボット１の故障）が発生した場合、こ
のイベントタスクの実行により、制御グループ２の処理
が実行されなくなる。

【０１０３】また、制御グループ１に属するイベントタ
スクで制御グループ２を有効にする内容を記述しておく
と、左記イベントタスクを実行要因（例：ロボット１の
故障復旧）が発生した場合、このイベントタスクの実行
により、制御グループ２の処理が実行される。

【０１０４】上記の例では、制御グループ２の処理を中
止、再開する様子を説明したが、中止位置から再開する
のではなく、制御グループ２を制御グループの初期処理
から実行したい場合がある。この場合、上記と同様にシ
ステムコールという形でユーザプログラムで記述する。

【０１０５】例えば、制御グループ１に属するイベント
タスク１（ロボット１故障）で制御グループ２を無効に
するシステムコールを記述しておき、イベントタスク２
（ロボット１故障復旧）で制御グループ２をInitial状
態から実行するシステムコールを記述しておく。

【０１０６】これにより、Run状態の制御グループ１，
２がRun状態の場合に、ロボット１が故障した場合は、
制御グループ２が無効状態となり、ロボット２の故障が
復旧した場合、制御グループ１をRun状態にしたまま制
御グループ２をInitial状態に遷移させ、初期処理を実
行した後再び制御装置がRun状態になる。制御グループ
２の状態遷移時は、サイクルタイム−スキャンタイムで
計算される時間で処理される。

【０１０７】［制御グループに属さない処理］制御グル
ープに共通な処理、あるいは、制御グループ間の制御を
行なう処理は、制御グループに属さないようにしてお
く。たとえば、制御グループ間のインターロック等はこ
れにあたる。

【０１０８】［その他］本実施形態のように１つの装置
（パソコン）内で複数の制御グループを実行することも
可能であるが、各制御グループを別の制御装置で実行さ
せることも可能である。

【０１０９】すなわち、複数の制御グループを１つの制
御装置で実行していた場合、制御装置自体に致命的な異
常（ＭＰＵ故障）が発生した場合、全ての制御グループ
の実行が不可能となる。そのため、各制御グループをそ
れぞれ別の制御装置で実行させることが考えられる。こ
の場合、分散した制御装置が全体としてどのような振る
舞いをするかをシミュレーションする必要がある。本発
明はこのようなケースにおいても有効である。

【０１１０】この場合、本実施例のように１つの装置で
開発環境で複数の制御グループを実行させて、複数の制
御グループのデバッグ、シミュレーションを行う。制御
グループとコミュニケーションするデバイスは実デバイ
スでなく、開発環境マシンのメモリで行ってもかまわな
い。各制御グループのデバッグ、シミュレーションを行
った後、各制御グループを別々の制御装置にダウンロー
ドする。これにより１つの制御装置で分散した制御装置
上で動作する制御グループの動作をシミュレーション、
デバッグすることが可能である。

【０１１１】

【発明の効果】以上の実施形態の説明でも明らかなよう
に、本発明によれば、制御グループを単位として異常処
理、状態遷移処理を行うことにより、システムの正当
性、モジュール性を向上させることができる。これによ
りプログラム作成、保守が容易となる。

【０１１２】また、全ての制御グループの周期タスクは
サイクルタイムの整数倍で動作するため、制御グループ
間で同じメモリをアクセスしている場合でも、メモリの
排他制御を行う必要がない。したがって、制御装置の性
能に悪影響を及ぼさない。また、プログラムを作成する
際は、メモリの排他制御を意識する必要がないため容易
にプログラムを作成することができる。

【０１１３】また、制御グループが複数存在する場合で
も、ＩＮリフレッシュ、ＯＵＴリフレッシュは制御グル
ープに関わらず一括で行うため、データの同時性に優れ
る。

【０１１４】さらに、分散した制御装置の振る舞いを１
台の制御装置（開発環境）でシミュレーション、デバッ
グを行うことが可能となる。

【図面の簡単な説明】

【図１】制御グループ定義内容の説明図である。

【図２】リフレッシュブロック定義内容の説明図であ
る。

【図３】一巡実行サイクルのゼネラルふーちゃーとであ
る。

【図４】制御装置の状態遷移図である。

【図５】周期タスクの動作態様を示す説明図である。

【図６】リフレッシュブロックの動作態様を示す説明図
である。

【図７】システム全体の構成図である。

【図８】開発環境装置における作業手順を示すフローチ
ャートである。

【図９】制御装置におけるイベントタスク選択実行処理
を示すフローチャートである。

【図１０】制御装置内の処理ブロック図である。

【図１１】ＩＮリフレッシュに関するスケジューラの処
理を示すフローチャートである。

【図１２】命令実行に関するスケジューラの処理を示す
フローチャートである。

【図１３】ＯＵＴリフレッシュに関するスケジューラの
処理を示すフローチャートである。

【図１４】制御ブロックと制御対象ブロックとの関係を
示す説明図である。

【符号の説明】

１，２ 開発環境装置 ３ シーケンスエンジン稼働装置（制御装置） ４ デバイス １０１ スケジューリング部 １０２ リフレッシュブロック部 １０３ 周期タスク実行部 １０４ 周辺処理実行部 １０５ イベントタスク実行部 ａ タスクプライオリティ ｂ 実行開始サイクルと周期

───────────────────────────────────────────────────── フロントページの続き (72)発明者 吉田 耕士 京都府京都市右京区花園土堂町10番地 オ ムロン株式会社内 (72)発明者 長尾 嘉祐 京都府京都市右京区花園土堂町10番地 オ ムロン株式会社内 Ｆターム(参考） 5H220 BB12 CC05 CC09 CX01 CX09 JJ12 JJ16 JJ26 JJ34 JJ51 KK06 MM06 9A001 DD01 HZ19 HZ32 JZ49 KK54 LL05

Claims (6)

【特許請求の範囲】
1. 【請求項１】 タスクプライオリティ、周期、実行開始
   サイクルをタスクのスケジューリング属性として持つ周
   期タスクと、周期、実行開始サイクルをタスクのスケジ
   ューリング属性として持つリフレッシュブロックと、タ
   スクプライオリティをタスクのスケジューリング属性と
   して持つイベントタスクと、で表現される任意の制御仕
   様に基づいて、制御プログラムを開発するための制御プ
   ログラムの開発環境装置であって、 １若しくは２以上の周期タスクと、１若しくは２以上の
   リフレッシュブロックと、１若しくは２以上のイベント
   タスクとを１つの制御グループとして入力するための手
   段と、 前記１つの制御グループとして入力される周期タスク
   と、リフレッシュブロックと、イベントタスクとの組を
   該当する制御グループと関連づけて記述する操作を、各
   制御グループについて繰り返すことにより、目的とする
   制御プログラムを生成する手段と、 を具備することを特徴とする制御プログラムの開発環境
   装置。
2. 【請求項２】 請求項１に記載の開発環境装置の各構成
   手段の全部若しくは一部をコンピュータにて実現するた
   めのプログラムを記録した記録媒体。
3. 【請求項３】 タスクプライオリティ、周期、実行開始
   サイクルをタスクのスケジューリング属性として持つ周
   期タスクと、周期、実行開始サイクルをタスクのスケジ
   ューリング属性として持つリフレッシュブロックと、タ
   スクプライオリティをタスクのスケジューリング属性と
   して持つイベントタスクと、で表現される任意の制御仕
   様に対応する制御プログラムを実行する制御装置であっ
   て、 １若しくは２以上の周期タスクと、１若しくは２以上の
   リフレッシュブロックと、１若しくは２以上のイベント
   タスクとからなる制御グループが複数グループ定義され
   た制御プログラムを格納するための手段と、 前記制御プログラムを構成するすべての制御グループの
   すべてのリフレッシュブロック並びに全ての周期タスク
   を、唯一のサイクルタイムに同期して一括に実行する手
   段と、 を具備することを特徴とする制御プログラムを実行する
   制御装置。
4. 【請求項４】 いずれかの制御グループで致命的な異常
   が発生した場合には、その制御グループに属する処理の
   みを停止し、その他の制御グループの処理は継続するこ
   とを特徴とする請求項３に記載の制御プログラムを実行
   する制御装置。
5. 【請求項５】 制御グループの状態遷移に関して、すべ
   ての制御グループの状態を遷移させるモードと、特定の
   制御グループの状態を遷移させるモードとを併有するこ
   とを特徴とする請求項３に記載の制御プログラムを実行
   する制御装置。
6. 【請求項６】 請求項３〜５のいずれかに記載の制御装
   置の各構成手段の全部若しくは一部をコンピュータにて
   実現するためのプログラムを記録した記録媒体。