JPH0573110A - シユミレーシヨンプログラムの生成方法 - Google Patents

Abstract

(57)【要約】 【目的】 実際の動作と同じ動作をシュミレートするこ
とができるシュミレーションプログラムを効率良く開発
することができるシュミレーションプログラムの生成方
法を提案する。 【構成】 シュミレーションプログラムによるシュミレ
ート対象としての、この生産ラインの動作を制御するシ
ーケンスプログラムを作成する工程と、生成されたシー
ケンスプログラムを実際の設備に対して動作させなが
ら、この設備の動作状態を示すデータを後にアクセス可
能なようにデータベース内に記憶する工程と、シュミレ
ーション対象部分に対応する動作状態データを前記デー
タベース内に特定する工程と、特定された動作状態デー
タを、そのシュミレーション対象部分のシュミレーショ
ン条件とする。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、例えばシーケンサ等に
より制御される生産設備を管理するシュミレーションプ
ログラムの生成方法に関し、特に、そのシーケンスプロ
グラムの最適化に関する。

【０００２】

【従来の技術】自動車の組立ラインの如くの生産ライン
において、設置された種々の設備に対してコンピユータ
を内蔵したシーケンス制御部を設け、かかるシーケンス
制御部により各設備が順次行なうべき動作についてのシ
ーケンス制御を行なうようにすることが知られている。
かかるシーケンス制御では、シーケンス制御部に内蔵さ
れたコンピユータに制御プログラムがロードされ、その
シーケンス制御部が生産ラインに設置された種々の設備
の夫々に対する動作制御の各段階をシーケンス動作制御
プログラムに従って順次進めていくようになっている。

【０００３】かかるシーケンス制御のための制御手法と
して、本出願人は、特願平１−３３５２７１号，２−１
１０９７７号、２−３０３７９号、１−２５３９９１
号、２−３０４０２２号、２−３０４０２３号、２−３
０４０２４号、３−６７２９０号、３−６７２９１号、
３−６７２９２号等を出願している。これらの出願にお
ける生産ラインの管理手法は、生産ラインの全設備のシ
ーケンサによる一般的な制御条件を入出力マップとして
記述し、その一方、ラインの具体的な順次動作を動作ブ
ロックと動作ステップという概念で把握し、その上で、
入出力マップ，動作ステップフローマップ，動作ブロッ
クフローマップとに基づいて、ラダープログラムを生成
するというものであった。

【０００４】また、上記出願における故障診断において
は、設備が正常に作動している状態におけるシーケンス
制御回路部の構成要素の動作態様を基準動作態様として
予め設定しておき、設備の実際の作動時におけるシーケ
ンス制御回路部の構成要素の動作態様を上記基準動作態
様と順次比較していき、その差に基づいて故障検出を行
うようにしている。

【０００５】更に、本出願人は、プログラム作成を効率
化し、且つ容易にできるようにするために、個々の動作
ステツプを記述するルールにおいて、その動作を端的に
表わす名称を付けて上記ルールをデータベース化して、
さらに、生産ラインを管理するシステムを、プログラム
の自動生成サブシステム、故障診断を行なうためのサブ
システム、ユーザインターフェースのためのサブシステ
ム、生成されたプログラムのシュミレーションを行なう
シュミレーションサブシステムの４つのサブシステムに
分け、これらのサブシステムのいずれからも上記データ
ベースを名前によりアクセスできるようにして、プログ
ラムの自動生成、プログラムの実行、故障の解析等のあ
るゆる操作において操作の簡便化、ミスの減少化を計っ
た。

【０００６】

【発明が解決しようとする課題】上記出願におけるシュ
ミレーション方法によれば、ＣＲＴ上で全てのプログラ
ムのシュミレーションが可能になったものの、そのシュ
ミレーションを開始するのに未だ多くの手間が必要とさ
れている。実際の生産ラインのシーケンスプログラムは
膨大な量のステップ数のプログラムからなる。シーケン
スプログラムは一部で並列動作があるものの基本的には
シーケンシャルに実行されていくものである。そのため
に、シーケンスプログラムをシュミレーションする場合
には最初のステップからプログラムを実行していく必要
がある。簡単なプログラムでは、このようなシュミレー
ション方法でもよいが、膨大なシーケンスプログラムで
は本来のシュミレーションを行ないたい目的部分に至る
までに時間がかかる。そこで、上記我々の出願では、シ
ュミレーション対象のプログラム部分を特定し、その部
分のステップの起動条件や環境条件をマニュアルで入力
するという方法を提案している。

【０００７】しかしながら、システムが膨大になると、
シュミレーション部分が僅かでも、その部分の起動条件
や環境条件のデータ量は膨大になり、従ってマニュアル
でそれらを入力するといっても、それは極めて効率の悪
いものとなる。また、入力の際の入力ミスの発生も無視
できないであろう。そこで、本発明の目的は、実際の動
作と同じ動作をシュミレートすることができるシュミレ
ーションプログラムを効率良く開発することができるシ
ュミレーションプログラムの生成方法を提案するもので
ある。

【０００８】

【課題を達成するための手段及び作用】上記課題を達成
するための本発明の構成は、複数の設備からなる生産ラ
インの動作をシュミレートするシュミレーションプログ
ラムの自動生成する生成方法であって、 ａ：シュミレーションプログラムによるシュミレート対
象としての、この生産ラインの動作を制御するシーケン
スプログラムを作成する工程と、 ｂ：生成されたシーケンスプログラムを実際の設備に対
して動作させながら、この設備の動作状態を示すデータ
を後にアクセス可能なようにデータベース内に記憶する
工程と、 ｃ：シュミレーション対象部分に対応する動作状態デー
タを前記データベース内に特定する工程と、 ｄ：ｃにおいて特定された動作状態データを、そのシュ
ミレーション対象部分のシュミレーション条件とする。

【０００９】

【実施例】以下、本発明を自動車の生産ラインのシーケ
ンス制御に適用した実施例を説明する。 〈実施例システムの特徴〉本実施例のシステムは、本出
願人の特願平３−６７２９０，３−６７２９１，３−６
７２９２を更に発展させたものである。ちなみに、上記
３件の特徴は、次のｉ〜ｉｉｉの３点にある。ｉ ： 生産ラインにおける管理対象となる設備の全ての
動作は、動作ブロックに分解され、そして、個々の動作
ブロックは更に複数の動作ステップに分解されている。ｉｉ ： 各動作ブロック，各動作ステップには、それら
をプログラマ若しくは操作者（以下、操作者と略す）が
把握し易いように、その動作ブロック若しくは動作ステ
ップのそのものを、そしてその動作を想起でき易いよう
なユニークな『名称』が付けられている。

【００１０】ｉｉｉ： このシステムは、ラダープログ
ラムの自動生成、生成されたラダープログラムのシュミ
レーション、実際の動作中若しくはシュミレーション中
におけるシステム管理、故障診断等の機能を有するが、
これらの機能をプログラム化する過程において、システ
ムと操作者とのユーザインターフェースは、そして、プ
ログラム間のプログラムインターフェースは上記『名
称』により行なわれる。換言すれば、上記機能及びユー
ザインターフェース、そしてプログラムインターフェー
スにより、シーケンス制御プログラムの開発や、システ
ムのメインテナンスに必要な工数の削減が可能となる。
即ち、ｉｉｉ−１ ： 本システムでは、後述するように、シス
テム全体の全設備のデバイスや、そのデバイスを使うス
テツプや、それらのステツプからなる動作ブロックに、
換言すれば、このシステムでランされる全てのプログラ
ムにおいて変数となり得る全てのものに名称が付され、
それらの名称がライブラリ化される。従って、本システ
ムでランされる全てのプログラム（特に、シーケンスラ
ダープログラム）の作成過程で、ライブラリ化されたこ
れらの『名称』を使うことができるので、効率的なプロ
グラム開発が可能となる。

【００１１】ｉｉｉ−２： 本システムでは、特にシー
ケンス制御プログラム、シュミレーションプログラム、
故障診断プログラム、ＣＲＴ操作盤の画面制御プログラ
ムなど、生産設備に何等かの関連性のある全てのプログ
ラムは、共通のデータベース（このデータベースの一部
のデータを、『実Ｉ／Ｏマップ』と呼ぶ）をアクセスす
ることができる。このデータベースには、その生産ライ
ンの全デバイスに関する、そのデバイスを制御するのに
必要な一般化された情報（例えば、そのデバイスを駆動
する信号名、その駆動情報を確認する信号名など）を含
む。従って、上記のシーケンス制御プログラム、シュミ
レーションプログラム、故障診断プログラム、ＣＲＴ操
作盤の画面制御プログラムは、の作成過程においては、
操作者はそのプログラム中でデバイス名、動作名等をプ
ログラム中に使うだけで、そのデバイスや動作に必要な
情報を参照することができる。

【００１２】そして、上記システムの特徴ｉ〜ｉｉｉに
加えて、これから説明する実施例システムの特徴は、ｉｖ ： 故障発生時のシステムの状態のみならず、正常
動作時のシステムの状態を記憶してデータベース化して
おく。更に、故障が発生したときに、故障が検出された
動作ステツプの数ステップ前からその故障が検出された
動作ステツプまでのシステムの変化を記録する。これら
のデータを故障診断に役立てる。故障原因箇所の探索で
は、本明細書では、過去における故障原因探索ルート
（バイナリツリーサーチ法）を選択的に用いる手法と、
過去の故障原因を優先的に今回の故障原因と推定すると
いう手法とを提案している。ｖ： 故障が発生してか
ら、復旧の工程を記憶しておき、故障原因毎に復旧工程
をデータベース化する。過去の故障原因と同じ原因で故
障が起こったときに、データベースからその復旧工程を
取り出して表示装置に表示する。操作者は、その表示に
従って、復旧を行なうようにする。即ち、過去の復旧シ
ーケンスが今回の復旧のガイドとなる。これにより、復
旧が早く行なえ、且つ、復旧操作が操作者の熟練度に依
らなくなる。

【００１３】ｖｉ： ｉｉｉ−１で述べたシーケンスプ
ログラムの自動生成では生成されたプログラムが必ずし
も最適なものとは限らない。本実施例システムは、生成
されたプログラムを最適化する方法を提供する。ｖｉ−１ ： 本機能は、動作ブロックまたは動作ステツ
プを起動させる起動条件が冗長部分を含む場合には、そ
の冗長な部分を検出し、それを除去すると共に、シーケ
ンス制御プログラムの次回の自動生成の際に、そのよう
な冗長部分が再度生成されないように、生成ルールを改
善することにより、シーケンスプログラムを最適化する
ものである。冗長な起動条件を含むプログラムの動作パ
ターンは、その冗長部分に対応するパターン部分が、プ
ログラムが複数回故障もなく実行された場合に、その実
行の度毎に異なる筈である。起動条件の最適化は、この
異なるパターン部分を検出することから始まる。

【００１４】ｖｉ−２： この特徴は、動作が不安定な
設備を含む場合に、その不安定な動作を行なうプログラ
ム部分を検出し最適化するものである。不安定な動作を
行なう設備をプログラム的に救済するためには、その不
安定な動作を行なった設備を検出する必要がある。そこ
で、疑わしい故障が検出されたときに、過去の原因のは
っきりした故障が発生したときのシステムの動作パター
ンと今回の疑わしい故障の動作パターンとを比較し、異
なるパターンに対応する設備が動作の不安定な設備と判
断する。そして、この設備のためのラダープログラムの
生成ルールを、上記不安定な動作を抑えるようなプログ
ラム要素を含むように最適化する。ｖｉｉ ： 本機能はシュミレーションを効率的に行なう
ために、実際の設備で起こった動作パターンを複数の動
作ステツプに亙って記憶しておき、これらの動作パター
ンをシュミレーションプログラムにシュミレーション条
件として自動的に渡すことにより、シュミレーションを
効率良く正確に行なうものである。

【００１５】これから説明する実施例は、自動車の生産
ラインのうちの、車体にエンジンやサスペンションをド
ッキングする工程におけるシーケンス制御プログラムの
自動生成等に本発明を適用したものである。従って、先
ず、シーケンス制御プログラム１０１の制御対象となる
車両組立ラインについて説明する。次に、本実施例のシ
ーケンス制御プログラムの自動生成等に重要な概念であ
る動作ブロックと動作ステップについて言及する。そし
て、その後に、本実施例の特徴部分である制御プログラ
ムの自動生成等にっいて説明する。

【００１６】〈組立ラインの一例〉先ず、生成されるべ
きシーケンス制御プログラムの制御対象となる車両組立
ラインの一例について、第１図及び第２図を参照して述
べる。第１図及び第２図に、車両組立ラインの一部が示
されている。このラインは、例示的に、３つのステーシ
ョンＳＴ１，ＳＴ２，ＳＴ３からなる。位置決めステー
ションＳＴ１では、車両のボデイ１１を受台１２上に受
け、受台１２の位置を制御することによりボデイ１１の
位置決めを行う。ドッキングステーションＳＴ２では、
パレット１３上の所定の位置に載置されたエンジン１４
とフロントサスペンションアッセンブリ（不図示）とリ
アサスペンションアッセンブリ１５とボデイ１１とを組
み合わせる。締結ステーションＳＴ３では、ボデイ１１
に対して、ＳＴ２にて組み合わされたエンジン１４とフ
ロントサスペンション組立１５とを、螺子を用いて締結
固定留する。また、位置決めステーションＳＴ１とドッ
キングステーションＳＴ２との間には、ボデイ１１を保
持して搬送するオーバーヘッド式の移載位置１６が設け
られている。ドッキングステーションＳＴ２と締結ステ
ーションＳＴ３との間には、パレット１３を搬送するパ
レット搬送位置１７が設けられている。

【００１７】位置決めステーションＳＴ１における受台
１２は、レール１８に沿って往復走行移動する。位置決
めステーションＳＴ１では、受台１２をレール１８に直
交する方向（車幅方向）に移動させることにより、受台
１２上に載置されたボデイ１１を、その前部の車幅方向
についての位置決めを行う位置決め手段（ＢＦ）並びに
その後部の車幅方向の位置決めを行う位置決め手段（Ｂ
Ｒ）と、受台１２をレール１８に沿う方向（前後方向）
に移動させることにより、その前後方向における位置決
めを行う位置決め手段（ＴＬ）とが設けられている。さ
らに、ＳＴ１には、ボデイ１１における前方左右部及び
後方左右部に係合することにより、ボデイ１１の、受台
１２に対する位置決めを行う昇降基準ピン（ＦＬ，Ｆ
Ｒ，ＲＬ，ＲＲ）が設けられている。そして、これらの
位置決め手段及び昇降基準ピンによって、位置決めステ
ーションＳＴ１における位置決め装置１９が構成されて
いる。即ち、これらの位置決め手段及び昇降基準ピン
が、シーケンス制御プログラムの位置決め装置１９につ
いての制御対象となる。

【００１８】移載装置１６は、位置決めステーションＳ
Ｔ１とドッキングステーションＳＴ２との上方において
両者間に掛け渡されて配されたガイドレール２０と、ガ
イドレール２０に沿って移動するキャリア２１とから成
る。キャリア２１には、昇降ハンガーフレーム２２が取
り付けられていて、ボデイ１１はこの昇降ハンガーフレ
ーム２２により支持される。昇降ハンガーフレーム２２
には、第３図に示されるように、左前方支持アーム２２
ＦＬ，右前方支持アーム２２ＦＲが夫々一対の前方アー
ムクランプ部２２Ａを介して取付けられている共に、左
後方支持アーム２２ＲＬ，右後方支持アーム２２ＲＲ
（不図示）が夫々一対の前方アームクランプ部２２Ｂを
介して取付けられている。左前方支持アーム２２ＦＬ，
右前方支持アーム２２ＦＲの夫々は、前方アームアーム
クランプ部２２Ａを回動中心として回動し、前方アーム
クランプ２２Ａによるクランプが解除された状態におい
ては、ガイドレール２０に沿って伸びる位置を取り、ま
た、前方アームクランプ部２２Ａによるクランプがなさ
れるときには、第３図に示される如く、ガイドレール２
０に直交する方向に伸びる位置をとる。同様に、左後方
支持アーム２２ＲＬ，右後方支持アーム２２ＲＲの夫々
も、後方アームクランプ部２２Ｂを回動中心として回動
し、後方アームクランプ部２２Ａによるクランプが解除
された状態においては、ガイド２０に沿って伸びる位置
をとり、また、後方アームクランプ部２２Ｂによるクラ
ンプがなされるときには、ガイドレール２０に直交する
方向に伸びる位置をとる。

【００１９】移載装置１６にボデイ１１が移載されるに
あたっては、移載装置１６が、第１図において一点鎖線
により示されるように、レール１８の前端部上方の位置
（原位置）に、左前方支持アーム２２ＦＬ，右前方支持
アーム２２ＦＲの夫々が前方アームクランプ部２２Ａに
よるクランプが解除されてガイドレール２０に沿って伸
びる。また、左後方支持アーム２２ＲＬ，右後方支持ア
ーム２２ＲＲの夫々が後方アームクランプ部２２Ｂによ
るクランプが解除されてガイドレール２０に沿って伸び
て、その後、昇降ハンガーフレーム２１Ｂが下降せしめ
られる。かかる状態で、ボデイ１１が載置された受台１
２がレール１８に沿ってその前端部にまで移動せしめら
れ、降下されていた移載装置１６の昇降ハンガーフレー
ム２１Ｂに対応する位置を取るようにされる。そして、
左前方支持アーム２２ＦＬ，右前方支持アーム２２ＦＲ
の夫々が回動されて、ボデイ１１の前部の下方において
ガイドレール２０に直交する方向に伸びる位置をとっ
て、前方アームクランプ部２２Ａによるクランプがなさ
れた状態となる。また、左後方支持アーム２２ＲＬ，右
後方支持アーム２２ＲＲの夫々が回動されて、ボデイ１
１の後部の下方においてガイドレール２０に直交する方
向に伸びる位置をとって、後方アームクランプ部２２Ｂ
によるクランプがなされた状態となる。その後、昇降ハ
ンガーフレーム２１Ｂが上昇させられて、第３図に示さ
れるように、ボデイ１１が、移載装置１６の昇降ハンガ
ーフレーム２１Ｂに取付けられた左前方支持アーム２２
ＦＬ，右前方支持アーム２２ＦＲと左後方支持アーム２
２ＲＬ，右後方支持アーム２２ＲＲとにより支持され
る。

【００２０】また、パレット搬送装置１７は、夫々、パ
レット１３の下面を受ける多数の支持ローラ２３が設け
られた一対のガイド部２４Ｌ及び２４Ｒと、このガイド
部２４Ｌ及び２４Ｒに夫々並行に延設された一対の搬送
レール２５Ｌ及び２５Ｒと、各々がパレット１３を係止
するパレット係止部２６を有し、夫々搬送レール２５Ｌ
及び２５Ｒに沿って移動するものとされたパレット搬送
台２７Ｌ及び２７Ｒと、これらのパレット搬送台２７Ｌ
及び２７Ｒを駆動するリニアモータ機構（図示は省略さ
れている）とを備える。

【００２１】ドッキングステーションＳＴ２には、フロ
ントサスペンションアセンブリ及びリアサスペンション
アッセンブリ１５の夫々の組み付け時において、フロン
トサスペンションアッセンブリのストラット及びリアサ
スペンションアッセンブリ１５のストラット１５Ａを夫
々支持して組付姿勢をとらせる一対の左右前方クランプ
アーム３０Ｌ及び３０Ｒと、及び、一対の左右後方クラ
ンプアーム３１Ｌ及び３１Ｒとが設けられている。この
左右前方クランプアーム３０Ｌ及び３０Ｒは、夫々、搬
送レール２５Ｌ及び２５Ｒに直交する方向に進退動可能
に、取付板部３２Ｌ及び３２Ｒに取り付けられるととも
に、左右後方クランプアーム３１Ｌ及び３１Ｒは、夫
々、取付板部３３Ｌ及び３３Ｒに、搬送レール２５Ｌ及
び２５Ｒに直交する方向に進退動可能に取り付けられて
いる。左右前方クランプアーム３０Ｌ及び３０Ｒの相互
に対向した先端部と、左右後方クランプアーム３１Ｌ及
び３１Ｒの相互に対向した先端部とは、夫々、フロント
サスペンションアッセンブリのストラットもしくはリア
サスペンションアッセンブリ１５のストラット１５Ａに
係合する係合部を有する。そして、前記取付板部３２Ｌ
は、アームスライド３４Ｌにより固定基台３５Ｌに対し
て、搬送レール２５Ｌ及び２５Ｒに沿う方向に移動可能
とされる。取付板部３２Ｒはアームスライド３４Ｒによ
り固定基台３５Ｒに対して、搬送レール２５Ｌ及び２５
Ｒに沿う方向に移動可能とされる。取付板部３３Ｌは、
アームスライド３６Ｌにより固定基台３７Ｌに対して、
搬送レール２５Ｌ及び２５Ｒに沿う方向に移動可能とさ
れる。さらに、取付板部３３Ｒは、アームスライド３６
Ｒにより固定基台３７Ｒに対して、搬送レール２５Ｌ及
び２５Ｒに沿う方向に移動可能とされている。従って、
左右前方クランプアーム３０Ｌ及び３０Ｒは、それらの
先端部がフロントサスペンションアッセンブリのストラ
ットに係合した状態のもとで、前後左右に移動可能とな
る。また、左右後方クランプアーム３１Ｌ及び３１Ｒ
は、それらの先端部がリアサスペンションアッセンブリ
１５のストラット１５Ａに係合した状態のもとで、前後
左右に移動可能となる。また、これらの左右前方クラン
プアーム３０Ｌ及び３０Ｒ，アームスライド３４Ｌ及び
３４Ｒ，左右後方クランプアーム３１Ｌ及び３１Ｒ、及
びアームスライド３６Ｌ及び３６Ｒが、ドッキング装置
４０を構成している。

【００２２】さらに、ドッキングステーションＳＴ２に
は、搬送レール２５Ｌ及び２５Ｒに夫々平行に伸びるよ
うに設置された一対のスライドレール４１Ｌ及び４１Ｒ
と、このスライドレール４１Ｌ及び４１Ｒに沿ってスラ
イドするものとされた可動部材４２，可動部材４２を駆
動するモータ４３等から成るスライド装置４５とが設け
られている。このスライド装置４５における可動部材４
２には、パレット１３上に設けられた可動エンジン支持
部材（図示は省略されている）に係合する係合手段４６
と、パレット１３を所定の位置に位置決めするための２
個の昇降パレット基準ピン４７とが設けられている。ス
ライド装置４５においては、移載装置１６における昇降
ハンガーフレーム２２により支持されたボデイ１１に、
パレット１３上に配されたエンジン１４，フロントサス
ペンションアッセンブリ及びリアサスペンションアッセ
ンブリ１５とを組み合わせる際に、その係合手段４６が
昇降パレット基準ピン４７により位置決めされたパレッ
ト１３上の可動エンジン支持部材に係合した状態で前後
動せしめられ、それにより、ボデイ１１に対してエンジ
ン１４を前後動させて、ボデイ１１とエンジン１４との
干渉を回避するようになっている。

【００２３】締結ステーションＳＴ３には、ボデイ１１
に、これに組み合わされたエンジン１４及びフロントサ
スペンションアッセンブリを締結するための螺子締め作
業を行うためのロボット４８Ａと、ボデイ１１に、これ
に組み合わされたリアサスペンションアッセンブリ１５
を締結するための螺子締め作業を行うためのロボット４
８Ｂとが配置されている。さらに、締結ステーションＳ
Ｔ３においては、パレット１３を所定の位置に位置決め
するための２個の昇降パレット基準ピン４７が設けられ
ている。

【００２４】第１図乃至第３図により説明した車両組立
ラインにおいて、位置決めステーションＳＴ１における
位置決め装置１９，移載装置１６、そして、ドッキング
ステーションＳＴ２におけるドッキング装置４０及びス
ライド装置４５，パレット搬送装置１７、そして、締結
ステーションＳＴ３におけるロボット４８Ａ及び４８Ｂ
は、それらに接続されたシーケンス制御部により、本実
施例のプログラム生成装置によって生成されたシーケン
ス制御プログラムに基づいてシーケンス制御が行われ
る。即ち、これらの上記位置決め装置１９，移載装置１
６等は、シーケンス制御対象であるところの“設備”で
ある。

【００２５】〈動作ブロックと動作ステップ〉第１図，
第２図の生産ラインにおける組立動作は、即ち、上記の
シーケンス制御対象の“設備”の全てが行う動作は複数
の“動作ブロック”に分解することができる。ここで
“動作ブロック”とは、 ：複数の単位動作の集合である と定義することができる。動作ブロックの最も重要な性
質は、 ：ある動作ブロックの開始から終了に至るまでの中間
過程で、他の動作ブロックから独立して干渉を受けるこ
となく、動作を完結することができるということであ
る。

【００２６】この，の性質のために、動作ブロック
を１つのブロック（かたまり）として表記することが可
能となる。換言すれば、動作ブロックは、動作ブロック
のレベルにおいてのみ、他の動作ブロックと関係する。
動作ブロックが動作を開始できるためには、他の動作ブ
ロックにおける動作の終了が必要となる。この他の動作
ブロックは、１つの場合もあれば、複数の場合もあろ
う。即ち、１つの動作ブロックの動作終了がそれに連結
する別の動作ブロック（１つまたは複数の動作ブロッ
ク）の起動条件になったり、複数の動作ブロックの動作
終了が起動条件になったりするということである。

【００２７】また、上記性質によれば、動作ブロックに
おける動作の中間段階で、他の動作ブロックに対して起
動をかけるということはない。また、動作ブロックの中
間段階で、他の動作ブロックからの起動を待つというこ
ともない。上記，の動作ブロックの定義から、次の
付随的な動作ブロックの性質，を導くことができ
る。 ：動作ブロックは、上記，の性質を満足する単位
動作の集合のなかで、最大のものであることが望まし
い。このの性質は絶対的に必要なものではない。しか
し、を満足すると、生産ラインを記述する動作ブロッ
クの数が減り、工程全体の記述が単純化され、大変見易
いものとなる。 ：動作ブロックは、その動作ブロックにおいて行なわ
れる動作の種類に応じても制限される。即ち、デバイス
の動作は、「繰り返し動作」、「連続動作」、「ロボッ
ト動作」等に大別される。本システムでは、ラダープロ
グラムを、定型的なラダーパターンから自動生成するも
のであるが、このラダーパターンはその動作が異なれば
大きく異なるので、１つの動作ブロック中には同一種類
の動作だけを行なうデバイスを集める。但し、この要請
はプログラムの効率化という観点からのものであるの
で、このの要請を守らないと、ラダープログラムの自
動生成が行なうことができないというものではない。

【００２８】第４図は、第１図，第２図の生産ラインに
おける動作の全体的な流れを示すものである。第１図，
第２図に示した生産ラインを、乃至の条件を満足す
る動作ブロックにより記述すると、この第４図に示すよ
うに、ａ〜ｓの１９個の動作ブロックが得られる。この
ようにして得られたブロック図は第１図乃至第３図の生
産ラインにおける動作を操作者が分析した上で得られた
ものである。図中、横方向の二重線により結合された２
つ（以上）の動作ブロックは並行して動作することを意
味する。また、２つの動作ブロックが実線で上下に結合
されている場合、上方に位置した動作ブロックにおける
動作が終了して始めて下方に位置したブロックの動作が
始まる。また、二重線の四角形は各ブロックの先頭を意
味する。

【００２９】動作ブロックａは受台１２の前進動作を意
味し『荷受前進』と呼ぶ。この『荷受前進』ブロックが
終了すると、『基準出』という名称のブロックｂと『受
具出』という名称のブロックｃとが並行して行なわれ
る。『基準出』ブロックｂでは、前述の各基準ピン（Ｆ
Ｌ基準ピン，ＲＲ基準ピンが「出」という名の位置に駆
動され、ＴＬ位置決め手段等が「戻り」という名の位置
に駆動される。ブロックｃでは、受台１２がドッキング
位置に移動する。ブロックｄの『移載上昇』という名称
のブロックでは、移載装置１６がステーションＳＴ１に
おいて上昇する。ブロックｄの動作が終了すると、この
ブロックｄに続いて２つの流れで動作ブロックが処理さ
れていく。即ち、『移載上昇』ブロックに続いて、『基
準戻り』という名称のブロックｅと『移載前進』という
名称のブロックｈとが並行して動作する。ブロックｅで
は、ブロックｂにおいて出された基準ピンを「戻り」位
置に戻すという動作が行なわれる。一方、ブロックｈで
は、移載装置１６がステーション２に前進する。

【００３０】ブロックｅに続く『荷受後退』という名称
のブロックｆにおいて、受台１２が後退するという動作
が行なわれる。ブロックｈでは移載装置１６がステーシ
ョンＳＴ２に前進する。一方、ガイド部、ストラットク
ランプ部、パレットスライド部においては、ブロックｌ
（『ピン上昇』）とブロックｍ（『リフト上昇』）とブ
ロックｎ（『パレット前進』）が夫々実行される。ブロ
ックｍ（『リフト上昇』）とブロックｎ（『パレット前
進』）との終了はブロックｏ（『アーム出』）を起動す
る。

【００３１】ブロックｈとブロックｌとブロックｏにお
ける動作が終了すると、『移載下降』という名称の動作
ブロックｉが実行される。以上の第４図の動作ブロック
の集合からなるフローチャートは、上述の〜の条件
に合致するような動作の集合をブロック化したものであ
り、前述したように、操作者が後述のフローチヤート作
成プログラムで作成したものである。そして、各動作ブ
ロックに付けられた名称は、その動作ブロックにおける
動作（複数）の特徴を短い言葉で表現するものである。
本実施例のシステムの特徴は、前記ｉｉに記したよう
に、各動作ブロックの名称はユニークなものであり、動
作ブロックは、この名称によりソフトウエア的に特定す
ることができる。

【００３２】各動作ブロックは複数の動作ステップから
なる。１つの動作ステップにおける動作には原則的には
１つのアクチュエータ（ソレノイド等）による動作が対
応する。第７図は、『基準出』ブロックｂにおいて行な
われる複数の動作ステップからなるフローチャートであ
る。同図において、各ステップに付されたラベルは操作
者が付したそのステップの名称である。第７図のフロー
チヤートによると、『ＲＲスライド出』ステツプにおい
ては、リア側の右スライドレール４１Ｒが「出」状態に
され、『ＦＬ基準ピンＡ出』及び『ＦＬ基準ピンＢ出』
ステツプでは、受台１２に対して車体１２を位置決めす
るための前述の昇降基準ピンＡ，Ｂ（前部左側）を
「出」の状態にする。『ＲＲ基準ピン出』ステツプにお
いては、同じく後部右側の昇降基準ピンを「出」状態に
する。また、『ＴＬ位置決戻』、『ＢＲ位置決戻』、
『ＢＦ位置決戻』の夫々のステツプにおいては、位置決
め手段ＴＬ，ＢＲ，ＢＦが「戻り」位置に戻される。こ
のようにして、第４図の『基準出』ブロックｂは、第７
図に示されたステップ動作により表現される。この動作
ステツプフローチヤートも前述のフローチヤート作成プ
ログラムで作成する。

【００３３】１つの動作ブロックの動作を表現する例え
ば第７図のような動作ステップフローチャートにおける
各ラベルは、前述したように、その動作ステップで駆動
されるアクチュエータデバイスを特定し、そのアクチュ
エータの動作を端的に表現するものとなっている。例え
ば、ＲＲ基準ピンが「出」状態にされる『ＲＲ基準ピン
出』というステップに対して、『ＲＲ基準ピン出』とい
う名称が付されている。ここで、この名称の前半部分の 『ＲＲ基準ピン』 はその動作ステップで駆動されるアクチュエータを特定
し、次の、 『出』 は、そのアクチュエータの駆動状態を意味する。換言す
れば、第４図，第７図のフローチャートの各動作ブロッ
ク及び動作ステップの名称に与えられた意味が理解でき
る人間及び装置にとっては、それらのフローチヤートが
第１図の生産ラインにおける動作を記述するものとなっ
ていると理解することは容易である。本実施例のシーケ
ンス制御プログラムの自動生成システムの目標は、この
ような第４図，第７図のフローチャートから第８図〜第
１０図のようなラダープログラムを自動的に生成するこ
とである。尚、第８図〜第１０図のラダープログラム
は、第７図に示された動作ブロックｂの動作の一部に対
応するラダープログラム要素である。

【００３４】〈ラダープログラムのシンボル〉ここで、
ラダープログラムのシンボルについて説明する。第１図
の生産ラインの例えば昇降基準ピン等の設備そのものは
ラダープログラム上では制御の対象とはならず、それを
駆動する例えばソレノイド等が問題となる。従って、生
産ラインの設備は、第１１図に示されるようなシリンダ
アクチュエータにより等価され得る。このアクチュエー
タは、シリンダ内を図面上左右に移動するピストンの位
置により、その「出」状態と「戻り」状態が規定され
る。ピストンは、ソレノイドバルブが入力される信号Ｂ
_０ により付勢されあるいは消勢されることにより、そ
の「出」状態と「戻り」状態のいずれかを取る。これら
の２つの状態は２つのリミットスイッチにより確認され
る。即ち、第１１図の「設備」からの出力として、駆動
された事を確認するためのリミットスイッチからの出力
Ａ_Ｏ （「出確認」信号）と、原位置に戻されたことを
確認するためのリミットスイッチからの出力Ａ_ｉ （戻
り確認信号）とがある。

【００３５】第１２図は、第１１図の素子の出力駆動動
作の論理を説明する図である。ソレノイドがオンするた
めには、インターロック条件ＩＬＣが満足されることで
ある。インターロック条件ＩＬＣは、一般に、その動作
ステップに特有の種々の起動条件を含む。各動作ステッ
プは、その前段の動作ステップの動作終了が実行条件と
なるから、インターロック条件ＩＬＣには、例えば、前
段の動作ステップの出力状態が確認されたことを示す信
号（例えば、第１１図のＡ_Ｏ ）が含まれるのが通常で
ある。さらに、このプログラムが生成したのではない外
部からの信号を含む。

【００３６】第１３図は全体シーケンスを自動生成する
際に用いる定型的な動作回路の一例を示す。第１３図に
おいて、条件Ｃ_Ａ は自動モード（生産ラインがシーケ
ンス制御プログラムに従って動作するモードである）で
この動作回路が動作しているときは閉じられる。条件Ｃ
_Ｓ は手動モードでこの動作回路が動作しているときに
閉じられる。Ｃ_Ｓ は通常閉じられている。従って、通
常の自動モードでは、インターロック条件ＩＬＣ_０ と
Ａ_ｌ が満足されれば、出力Ｂ_Ｏ が出力される。一
方、ＩＬＣ_１ は手動モードにおける動作条件の論理を
記述する。手動モードでは、接点Ｃ_Ｓ が開くので、条
件Ａ_ｋ ，ＩＬＣ_１ が同時に満足するか、条件Ａ
_ｋ ，Ａ_Ｉ が同時に満足すれば、Ｂ_Ｏ は出力され
る。一般に、Ａ_Ｉは、手動動作のインターロック条件Ｉ
ＬＣ_１ を殺すための論理である。

【００３７】第１３図のラダーパターンは、ある動作ス
テップのラダープログラムを表現するのに用いられる定
型的なパターンである。本システムに用意されている他
のラダーパターンを第１４図〜第１６図に示す。第１４
図は、動作ブロックの開始と停止を定型的に記述するパ
ターンである。第１５図は、第１３図に関連して説明し
たパターンと同じである。第１６図は、第１５図のパタ
ーンに更に１つの接点条件を付加したものである。

【００３８】第８図のラベル１３６０，１３７２は第７
図の『ＲＲスライド出』に対応するラダープログラムで
ある。ラベル１３６０の論理において、５０４１番地の
「Ｂ４ステップ１出力」は、 （Ｂ４ステップＯＦＦ＊基準ピン戻り＊荷受台前進＋Ｂ
４ステップ１出力） ＊Ｂ４ステップ２出力／＊Ｂ４ステップ３出力／ ＝
１ が満足されると、“１”を出力する。ここで、Ｂ４は第
４図における『基準出』ブロックｂのブロック番号であ
る。また、「／」は論理ＮＯＴを表記する。また、「Ｂ
４ステップＯＦＦ」は、ブロック４の全てのステップが
オフ（即ち、実行されていない）であることを意味す
る。また、１７５３番地の『基準ピン戻り』，『荷受台
前進』は、ブロック４の『基準出』に先行する『荷受前
進』ブロックにおける動作終了を意味する。また、Ｂ４
ステップ２出力／やＢ４ステップ３出力／についても容
易に推測ができよう。かくして、ラベル１３６０の動作
は、『基準出』ブロックの最初の動作ステップ『ＲＲス
ライド出』が正しく起動されるべき条件を表わす。従っ
て、ブロックの『荷受前進』の全ての動作ステップが終
了していれば、上記条件式は満足されて、「Ｂ４ステッ
プ１出力」は“１”になる。一旦、「Ｂ４ステップ１出
力」が“１”になると、ラベル１３６０のラッチ条件に
より、「Ｂ４ステップ１出力」は“１”のままである。

【００３９】第８図のラベル１３７２の出力「Ｂ４Ｓｔ
１ＲＲスライド出」が“１”になるのは、 Ｂ４ステップ１出力＊荷受台前進＊Ｂ４動作ＯＮ＊ＲＲ
スライド出／ ＝１ が満足されたときである。ここで、Ｂ４Ｓｔ１はブロッ
ク番号４の最初のステップであることを表記する。『Ｒ
Ｒスライド出』なる動作がなされるのは、「Ｂ４ステッ
プ１出力」が“１”になって、『ＲＲスライド』なるア
クチュエータがオンされていない状態で『荷受台前進』
ステップが実行されたときである。

【００４０】第９図，第１０図のラダープログラムは、
第７図の『ＦＬ基準ピンＡ出』，『ＦＬ基準ピンＢ出』
という２つの動作ステップに対応することは容易に理解
される。かくして、第４図のブロックｂの『基準出』ブ
ロックが、第７図の動作ステップフローチャートに対応
する形で表わされた場合、その動作ステップフローチャ
ートの『ＲＲスライド出』，『ＦＬ基準ピンＡ出』，
『ＦＬ基準ピンＢ出』という３つのステツプは第８図〜
第１０図のラダープログラムに対応することが理解でき
よう。

【００４１】〈システムの構成〉 ｉ）〜ｖｉｉ）で述べたように、本システムの大きな目
標は、第１図のような生産ラインの工程管理を如何に効
率良く行なうかである。そして、ラダープログラムの自
動生成、生成されたラダープログラムのシュミレーショ
ン、生成されたラダープログラムの実際の動作中若しく
はシュミレーション中におけるシステム管理、故障診断
等の機能を如何に自動化するかが大きな関心である。第
１７図は、ある生産ラインに、工程管理を行なうシステ
ムが導入されるプロセスを、一般化して表わした概念図
である。また、第１９図は、実施例システム全体に要求
されるプログラム機能を図示したものであり、第１８図
は、本実施例のシステムに要求される機能間の結合関係
をブロック化して表わしたものである。

【００４２】第１７図に示すように、生産ライン及びそ
の管理システムの導入は、その基本設計から始まって、
更に詳細設計、シーケンスプログラムの作成、そのプロ
グラムのトライアル、そして実稼動という工程で表現さ
れる。第１８図に示された本実施例に係るシステムは、
特に第１７図における、「シーケンスプログラムの作
成」段階、「トライアル」段階、「稼動」段階で威力を
発揮する。そのためには、実施例システムは、第１９図
に示すように、プログラムの自動生成機能、プログラム
実行中の故障の検出機能、故障が検出された場合の故障
箇所の解析機能、故障からの自動復旧機能、故障状態若
しくはトライアルにおけるシュミレーション機能、自動
生成されたプログラムの最適化機能等が要求される。

【００４３】第１８図に従って、本実施例システムのプ
ログラム構成をブロック的に説明する。第１８図におい
て、マスタテーブル１０１は、対象の生産ラインの全設
備（アクチュエータ等）に関する、デバイス名称、その
動作の種類、そして、それらのデバイスを第１１図〜第
１３図のようなシンボルで表記した場合の入力信号，出
力信号の名称をテーブル化したもので、その詳細な一例
が第１３図に示される。このマスタテーブルは、各デバ
イスの実際の入出力関係を表現するものであるから、以
下、『実Ｉ／Ｏマップ』と呼ぶ。

【００４４】データベース１００は、この生産ラインに
使われる全設備（アクチュエータ等のデバイス）に付け
られる名称等を記憶する「名称ライブラリ」１０８を含
む。このライブラリ１０８は、操作者によるデバイス名
称の付与に恣意性が入り込むのを排除するために設けら
れている。即ち、ある設備に対し、操作者ＡがＡＡと名
称を付け、操作者ＢがＢＢと名付ければＡＡの設備とＢ
Ｂの設備とは別物になってしまう。「名称ライブラリ」
１０８により１つの設備には１つの名称を付することに
より、統一を計る。

【００４５】データベース１００は、「名称ライブラ
リ」１０８の他に、「ラダーパターン」１０７，「ブロ
ックフローマップ」１０９，「ステップフローマップ」
１１０，「動作状態ファイル」１１１を含む。ラダーパ
ターン１０７は、第１４図〜第１６図に示したような基
本ラダーパターンを記憶する領域である。各設備はその
設備について前もって割り当てられた基本ラダーパター
ンを有する。

【００４６】ブロックフローマップ１０９は第１３図の
ようなマップであって、第４図〜第５図に示された人間
の理解の容易さを意図した動作ブロックフローチャート
を第１３図のようにマップ化することにより、コンピユ
ータのデータ処理を可能にしたものである。ステップフ
ローマップ１１０は第７図に示された動作ステップフロ
ーチャートを第１３図のようにマップ化することによ
り、コンピユータのデータ処理を可能にしたものであ
る。

【００４７】動作状態ファイル１１１は、実際にシーケ
ンス制御プログラムが動作した時の各設備の各確認デバ
イスの信号（例えば、第１１図のＡ_０ ，Ａ_１ ）の変
化を記録する。第１１図は動作状態ファイル１１１の構
造を示す。このファイルは、信号が変化した時点で変化
した信号について記録される。変化しない信号について
の記録は省かれる。このように、変化があったものにつ
いてだけファイル内に記憶するのは、全ての信号を単位
時間毎に記憶するようにすると、膨大な記憶容量を必要
とするからである。第１１図において、ファイル１１１
の１つのレコードは、「発生時刻」は信号の値が変化し
た時刻を、「信号名」は変化のあった信号の名称を、
「値」は変化後の信号の値を、「故障／正常」は、ファ
イル１１１に記憶されているデータが、最終的に正常動
作として終わった（＝１）ものか、故障として終わった
（＝０）ものかを示す。第１２図は、第１１図に示され
た信号Ａ，Ｂ，Ｃ，Ｄについての動作状態ファイルから
それらの信号の計時変化をタイミングチヤートとして復
元したものである。尚、第１１図の例では、時刻ｔ_０は
初期設定時刻である。

【００４８】第１８図のシステムは、上記のデータベー
ス１００やマスタテーブル１０１内の『実Ｉ／Ｏマッ
プ』の他に、「データ生成」１０２、「自動プログラミ
ング」１０４、「シュミレーション」１０５、「故障診
断／復旧」１０６という４つのサブシステムからなる。
「自動プログラミング」サブシステム１０４はこれらの
データベース１００やマスタテーブル１０１内の『実Ｉ
／Ｏマップ』を元にして、シーケンス制御のためのラダ
ープログラムを自動生成する。データ生成プログラム１
０２は、上記のデータベース１００やマスタテーブル１
０１内の『実Ｉ／Ｏマップ』を作成し、あるいは修正す
る際の操作者とのインターフェースを司どるためのもの
である。このサブシステム１０２は主に第１７図の「シ
ーケンスプログラム作成」過程において使われる。この
「自動プログラミング」サブシステムは、後述するよう
に、「ブロックフローマップ１０９」や「ステップフロ
ーマップ１１０」（これらのマップは、これからラダー
プログラムを自動生成しようとする対象となる生産ライ
ンを記述するものである）と、その生産ラインに使われ
るデバイスの入出力関係を一般的に表現する『実Ｉ／Ｏ
マップ』とを、結合することによりラダープログラムを
作成する。この結合は、「ブロックフローマップ１０
９」や「ステップフローマップ１１０」に使われている
ブロックの名称やステップの名称やデバイスの名称と、
『実Ｉ／Ｏマップ』に記憶されているデバイスの名称と
をリンクすることによりなされる。

【００４９】「シュミレーション」サブシステム１０５
は自動プログラミング１０４が生成したラダープログラ
ムをシュミレーションするプログラムを自動生成する。
この生成されたシュミレーションプログラムは、第１７
図の「トライアル」段階において主に使われる。「故障
診断／復旧」サブシステム１０６は、第１７図の「トラ
イアル」段階や「稼動」段階において、シュミレーショ
ン結果を診断したり、あるいは実際の稼動段階での故障
を診断するもので、それらの診断結果は主にＣＲＴ表示
装置に表示される。この表示装置では、操作者の理解が
容易なように、故障箇所の名称等を上記『実Ｉ／Ｏマッ
プ』のデバイス名称から索引するようになっている。

【００５０】このように、本システムにおける中心的な
データは、マスタテーブル１０１内の『実Ｉ／Ｏマッ
プ』（第２４図）であり、この『実Ｉ／Ｏマップ』とデ
ータベース１００内のブロックフローマップ１０９やス
テップフローマップ１１０と、ラダーパターン１０７と
が有機的にリンクされて、ラダープログラムやシュミレ
ーションプログラム等が自動的に生成されるようになっ
ている。そこで、以下、本システムのハード構成を説明
し、そのあとで、上述の３つのマップを順に説明する。

【００５１】〈ハード構成〉第２５図は、第１８図で説
明した実施例システムを、ハードウエア構成の観点から
改めて書き直したものである。同図に示すように、ハー
ド構成の観点から見た本システムは、制御対象設備５０
（第１図の各種の「設備」に対応）とホストコンピュー
タ６０と、ユーザインタフェースとしてのＣＲＴを制御
するＣＲＴパネル制御ユニット５３と、前述のマップや
データベースを格納するデータファイル５６とからな
る。ホストコンピュータ６０は３つのサブシステムを含
み、ラダープログラムの自動生成と前述のマップの生成
とを行う自動プログラミング／データ入力サブシステム
１０４（１０２）と、故障診断及び復旧を行う故障診断
／復旧サブシステム１０６と、シュミレーション制御を
行うシュミレーションサブシステム１０５とから成る。
これらのユニットは通信回線６１で接続され、データフ
ァイル５６は高速化を図るためにも半導体メモリまたは
高速ハードディスクドライブが適当である。データファ
イル５６は、更に、ラダープログラムを自動作成する上
で必要な生成ルール１１２も記憶する。

【００５２】ＣＲＴパネル制御部５３は、ＣＲＴ表示装
置５８のほかに、その表示画面のうえに装着されたタッ
チパネル５７を有する。本システムでは、自動プログラ
ミングの過程、シュミレーションの過程、故障診断の過
程などで操作者とのインターフェースが必要となるが、
制御ユニット５３は、周知のマルチウインド表示制御に
より、複数のウインドをＣＲＴ５８上に表示し、操作者
は表示されたウインド内の複数のアイテムの中からタッ
チパネル５７を使って所望のアイテムを選択する。した
がって、タッチパネル５７の代わりに、ポインテイング
デバイスを用いてもよいのは言うまでもない。

【００５３】〈プログラム構成〉第２６図は自動プログ
ラミング／データ入力サブシステム１０４（１０２）に
おけるプログラム構成を示す。尚、第５３図〜第５６図
は、ラダープログラムの実行及び故障検出及び故障診断
のためのプログラム構成を示す。第２６図において、最
下層にはいわゆるオペレーテイングシステム１２０が格
納され、さらに、マルチウインドシステム１２１と、日
本語を入力するための日本語フロントエンドプロセサ
（ＦＥＰ）１２３と、ＣＲＴ５８，タッチパネル５７と
のインターフェースを司どるＣＲＴインターフェースプ
ログラム１２２と、フローチャート作成するための図形
プロセサ１２４と、ライブラリを作成するプログラム１
２５と、実Ｉ／Ｏマップを作成するプログラム１２６
と、フローマップを作成するプログラム１２８と、この
フローマップからラダープログラム（第６図）を作成す
るコンパイラ１２７と、生成された自動シーケンスラダ
ープログラムや生成ルール１１２を最適化するための最
適化プログラム１２９とからなる。

【００５４】プログラム１２３〜１２９が自動プログラ
ミングサブシステム１０５（１０２）を構成する。図形
プロセサ１２４は、第４図や第７図のフローチャートを
作成するためのプロセサで、フローチャートのシンボル
としてのボックスを書く機能と、そのボックスに名称を
付す機能と、そのボックスの中に文章を入力する機能
と、複数のボックス同士を連結する機能とからなる。こ
の図形プロセサ１２４が作動している最中は、ＣＲＴ装
置５８の画面上には、データファイル５６内の前述のラ
イブラリから入力可能なアイテムが、マルチウインドモ
ードで表示される。ここで、アイテムとは、前述した、
デバイス名称、動作ステツプ名称、動作ブロック名称等
のリテラルデータである。操作者はタッチパネル５７に
より、特定のアイテムを選択することにより所望の入力
が可能となる。また、ライブラリにない名称について
は、前述の日本語ＦＥＰ１２３の助けにより自由な入力
が可能となる。入力可能なアイテムをウインド表示し、
その中から所望のアイテムを選択するようにしたのは、
名称が恣意的なものとならないようにするためである。
なお、このようなマルチウインド制御システムや、図形
プロセサ１２４、日本語ＦＥＰ１２３はすでに周知であ
り、その詳細な説明は不要である。

【００５５】第２７図はライブラリに格納されたデータ
の一部を示す。同図に示すように、データは、「デバイ
ス名称」フィールドと「動作名称」フィールドとからな
る。これらのフィールドのデータは上記各種マップを作
成するときに、別々にウインド表示される。ライブラリ
中で、このように２つのフィールドに分割したのは、
「デバイス名称」と「動作名称」とが固有の意味を持つ
ように成っているからである。

【００５６】ブロックフローマップ 第２２図は、本システムで重要な役割を有するブロック
フローマップであり、このマップは第４図の動作ブロッ
クフローチャートをホストコンピュータ６０のフローマ
ップ作成プログラム１２８により変換したものであり、
データファイル５６に格納される。このマップは、同図
に示すように、７つのアイテム、即ち、「ブロック番
号」、「ブロック名称」、「ＦＲＯＭ」、「ＴＯ」、
「ステップフローマップポインタ」、「装置種別」、
「動作時間」からなる。ブロック名称はそのブロックに
つけられた名称である。ブロックはブロック名称により
ユニークに特定できるが、ブロック番号を付すことによ
り、そのブロックを簡単に特定することができる。第６
図のラダープログラムにおいて、信号名に例えば、「Ｂ
４」と付されているのは、このブロック番号を参照する
ことにより得たものである。「ＦＲＯＭ」は、そのブロ
ックが、他の上位のどのブロックから連結されているか
を示す。「ＦＲＯＭ」の部分に、複数のブロック番号が
記されている場合は、それらのブロックに当該ブロック
が接続されていることを示す。「ＴＯ」は、そのブロッ
クが、他の下位のどのブロックに連結されているかを示
す。「ＴＯ」の部分に、複数のブロック番号が記されて
いる場合は、それらのブロックに当該ブロックが接続さ
れていることを示す。第２２図には、第４図のブロック
フローチャートにおけるブロック間の接続関係が示され
ている。前述したように、図形プロセサ１２４は、第４
図のフローチャートの各ボックスの連結関係をベクトル
データとして表現するから、そのようなデータから、第
２２図のブロックフローマップを作成することは容易で
ある。

【００５７】ブロックフローマップの「ステップフロー
マップポインタ」は当該ブロックのステップフローマッ
プ（第２３図）がどのメモリ番地に作成されたかを示
す。このブロックフローマップは、自動プログラミング
部５５が、第２８図のステツプＳ１６において、動作ブ
ロックフローチヤートから作成する。

【００５８】実Ｉ／Ｏマップ ステップフローマップを説明する前に、実Ｉ／Ｏマップ
を第２４図により説明する。この実Ｉ／Ｏマップは、こ
れから設計しようとする生産ラインに設けられた全ての
設備（アクチュエータ）について所定の入出力関係を定
義したものである。図中、「名称」はそのアクチュエー
タデバイスに対してユニークにつけられた「名前」であ
る。このマップを定義する他のアイテムは、「動作」、
「出力Ｂ」、「確認Ａ」、「手動Ａ」の４つである。
「出力Ｂ」とは、論理値１の信号が「出力Ｂ」で規定さ
れるメモリ番地に書き込まれたときに、当該デバイスが
「動作」に規定された動作を行うためのデータである。
この「出力Ｂ」は第１１図で説明した出力Ｂに相当す
る。「確認Ａ」とは、当該デバイスが「動作」に規定さ
れた動作を行ったときに、システムがその動作を確認す
る時に参照するメモリ番地を示す。この「確認Ａ」は第
１１図で説明した「確認Ａ」に相当する。「手動Ａ」と
は、手動動作を行うようにプログラムを組むときに、
「手動Ａ」に示されたメモリ番地に論理値１を書き込
む。

【００５９】第２４図により、実Ｉ／Ｏマップについて
具体的に説明すると、「ＢＦ位置決め」なるデバイスが
「出」動作を行うためには、「Ｂ_Ａ０」番地に１が書き
込まれ、その動作の結果は、「Ａ_Ｃ０」番地に１が書き
込まれたかを確認することにより確認される。また、
「ＢＦ位置決め」なるデバイスが「戻り」動作を行うた
めには、「Ｂ_Ａ１」番地に１が書き込まれ、その動作の
結果は、「Ａ_Ｃ１」番地に１が書き込まれたかを確認す
ることにより確認される。「Ｂ_Ａ０」や「Ａ_Ｃｏ」など
の番地は、いわゆる、メモリマップＩ／Ｏの番地に対応
する。これらの番地は、第１４図のシーケンサ制御部５
１のバックプレーンのピン番号に対応する。このピンは
該当するアクチュエータに接続されている。この制御部
５１は、これらのメモリ番地（「出力Ｂ」や「手動
Ａ」）の内容をスキャンしており、これらの番地の内容
が１になれば、対応するアクチュエータを駆動する。そ
して、そのアクチュエータの確認スイッチ（第８図を参
照）が変化すれば、その論理値を、例えば、「Ａ_Ｃ０」
番地に書き込む。この実Ｉ／Ｏマップは、日本語ＦＥＰ
１２３や実Ｉ／Ｏマップ作成プログラム１２６を使って
作成され、各「名称」や「動作」フィールドは検索可能
に構成されている。

【００６０】ステップフローマップ 第２３図のステツプフローマップは、実際の生産ライン
における動作を記述するマップである。このマップのア
イテムは、第２３図に示すように、当該ステップが属す
るブロックの番号を示す「ブロック番号」、「ステップ
番号」、当該ステップの「名称」、そのステップにおけ
る「動作」のタイプを表す「動作」、「ＦＲＯＭ」、
「ＴＯ」、「出力Ｂ」、「確認Ａ」「手動Ａ」、「動作
時間」である。「ＦＲＯＭ」、「ＴＯ」は、ブロックフ
ローマップの場合と同じように、ステップ間の接続関係
を表す。「動作時間」は、当該ステップが動作するのに
要する公称の時間である。

【００６１】動作ステツプフローチヤート（第７図）
は、図形プロセツサ１２４を用いて作成したものであ
り、そのデータはベクトル化されている。ステツプフロ
ーマップの最初の６つのフィールド、即ち「ブロック番
号」、「ステップ番号」、「名称」、「動作」、「ＦＲ
ＯＭ」、「ＴＯ」のためのデータは、フローマップ作成
プログラム１２８が第２８図のステツプＳ８において、
前記ベクトル化された動作ステツプフローチヤートか
ら、ブロックフローマップの作成と同じ要領で作成す
る。残りのフィールド、即ち「出力Ｂ」、「確認Ａ」
「手動Ａ」のためのデータは、自動プログラミング制御
部５５のラダープログラムコンパイラ１２７がラダープ
ログラムを生成する時（第２９図の手順が実行される
時）に、これらのフィールドに、前述の「実Ｉ／Ｏマッ
プ」からのデータを埋め込む。

【００６２】〈ユーザインターフェース〉第１９図にお
いて説明した実施例システムの機能が有効に機能するた
めには、使いやすいユーザインターフェースが必要であ
る。本システムでは、ユーザインターフェースはＣＲＴ
５８により行われる。本システムのＣＲＴ表示装置５８
でのユーザインターフェースは２つの意味を有する。第
１の意味は、ラダーパターンの登録時、動作ブロックフ
ローチヤートや動作ステップフローチヤートの作成時、
「実Ｉ／Ｏマップ」の作成時などにおけるマルチウイン
ドを介したユーザインターフェースである。第２は、操
作者がシステムに操作指令を与えるために、タッチパネ
ル５７によるインターフェース（以下、所謂「ボタンア
イコン」によるインターフェースと呼ぶ）である。この
場合、操作者は、ＣＲＴ５８に表示された内容によりシ
ステムからのメッセージを知り、そのメッセージに基づ
いて所定の位置を押すことにより、システムに対して指
令を与える。

【００６３】かかるタッチパネルによるユーザインター
フェースは、例えば、第３２図に示すように、矩形１５
０の左上端座標と右下端座標（ｘ_１，ｙ_１ ）（ｘ
_２ ，ｙ_２ ）で規定される表示領域に、例えば『Ｏ
Ｎ』と表示し、矩形１５１の左上端座標と右下端座標
（ｘ_３ ，ｙ_３ ）（ｘ_４ ，ｙ_４ ）で規定されるタ
ッチ検出領域の内部の任意の領域で操作者がタッチした
ことを検出したことをもって、所定の『ＯＮ』動作を行
なうようにプログラム化するというものである。本シス
テムにおけるタッチパネル５７を用いたユーザインター
フェースも基本的にはこの手法を用いているが、その特
徴は、むしろ、ＣＲＴ５８に表示されるボタンアイコン
の表示データや機能が、前述の実Ｉ／Ｏマップから与え
られるという点にある。即ち、実Ｉ／Ｏマップやステツ
プフローマップを介して、シュミレーションプログラム
やＣＲＴ表示プログラム等が、他のサブシステム（自動
プログラミングサブシステム５５）とプログラムインタ
ーフェースするということである。

【００６４】本システムにおける１つのボタンアイコン
は、第３３図のようなデータ構造により規定される。同
図中、１５０，１５１は第３２図で説明した表示領域及
びタッチ検出領域を規定する座標である。第３４図に示
すように、本システムのボタンアイコンは３行のデータ
表示フィールドを有する。第３３図の１５２，１５３，
１５４はこれら３つのフィールドに表示されるテキスト
を表わす。１５５のＳ／Ｌは、このボタンアイコンが単
に表示（Ｌ）を行なうに過ぎないのか、スイッチ機能
（Ｓ）を有するのかを区別する情報である。１５６のＭ
／Ａは、当該ボタンにスイッチ機能が与えられている場
合において、Ｍであればモメンタリスイッチとして機能
し、Ａであればオルタネートスイッチとして機能するこ
とを意味する。１５７は、このボタンに与えられた機能
の結果を表わす出力が“０”若しくは“１”であるとき
に、このボタンの表示色を規定するフィールドである。

【００６５】第３５図はＣＲＴ装置５８の画面に設けら
れた複数のボタンアイコンの配置を示す図である。これ
らのボタンアイコンの各々に、第３３図のデータがアタ
ッチされる。第３５図中の数字は表示位置を指定する番
号である。ユーザは、第３７図に示すように、どのボタ
ンアイコン位置に、どのデバイスを表示させるかを個々
のボタン毎に指定することと、そして、個々のボタン毎
にフィールド１５７の色指定を行ない、スイッチのモー
ド（Ｌ／ＳとＭ／Ａ）の指定を行なうだけでよい。第３
７図の表示位置番号は第３５図の表示位置指定番号に等
しい。従来では、ＣＲＴ装置に表示するデータは、ユー
ザが独自に設定し、それは面倒な作業であったが、本シ
ステムでは、ユーザは単に、ボタンの表示位置とデバイ
ス名称、そして色指定などを指定するだけでよい。

【００６６】第３３図は、実Ｉ／Ｏマップの各デバイス
の名称フィールドのデータ構成の一例を示す。『実Ｉ／
Ｏマップ』の名称フィールドの最初のｌバイトは（第３
６図の例では『ＴＬ』）は、第３４図に示すように、表
示データの第１段目（１５２）にコピーされ、名称フィ
ールドの次のｍバイトは（第３６図の例では『位置決
め』）は表示データの第２段目（１５３）にコピーされ
る。表示データの第３段目（１５４）は、本システムで
は、実Ｉ／Ｏマップの『確認Ａ』フィールドの値が
“０”であるか“１”であるかに応じて、『動作』フィ
ールドのリテラルデータをもってくるようにしている。
即ち、デバイス名称が位置決めタイプのものであり、そ
のデバイスの『確認Ａ』フィールドの値が“１”であれ
ば、第３段目には『出』を、“０”であれば『戻り』を
表示する。

【００６７】第３７図のボタンアイコンの指定は操作者
がデータ生成プログラム５５を起動することにより行な
われる。このデータ生成プログラム５５は、第３７図の
ようなデータを操作者が作成したならば、実Ｉ／Ｏマッ
プを参照しながら、個々のボタンについて第３３図のよ
うなボタン定義データを作成する。ボタン定義データの
フィールド１５０乃至１５４の作成については前述した
通りである。第３６図の例のような『ＴＬ位置決め』な
るデバイスが選択された場合は、そのデバイスが『出』
状態になったか『戻り』状態になったかがそのアイコン
に表示されるべきである。『出』状態になったか否か
は、そのデバイスの実Ｉ／Ｏマップの『確認Ａ』フィー
ルドに示されるメモリ番地のデータを参照することによ
り判断できる。第３３図のフィールド１５８はその参照
番地を格納する。

【００６８】かくして、１つの画面毎の全てのボタンア
イコンについての画面制御データ（第３０図）が生成さ
れると、ＣＲＴパネル制御部５３は、これらの画面制御
データを参照しながらＣＲＴ表示装置５８上に画面表示
を行なう。もし、『０のときの色指定』が赤で、『１の
ときの色指定』が青ならば、『ＴＬ位置決め』デバイス
が『出』状態にあれば、青で表示される。

【００６９】以下、第１９図に示した順序に従って、本
システムの機能を、「プログラムの自動生成」、「故障
の検出」、「故障箇所の解析」、「シュミレーショ
ン」、「プログラムの最適化」という順で説明する。 〈プログラムの自動生成〉第２９図，第３０図は、ラダ
ープログラムを作成するコンパイラ（第２６図の１２
７）の制御手順を示すフローチヤートである。第２９図
は、このコンパイラの、ステツプフローマップの「出力
Ｂ」、「確認Ａ」「手動Ａ」を作成するための制御手順
を示すフローチヤートであり、第３０図がラダープログ
ラム要素を作成するためのフローチヤートである。

【００７０】第２９図において、ステップＳ１０、ステ
ップＳ１２では、夫々、ブロック番号、ステップ番号を
示すカウンタｍ，ｎを“０”に初期化する。ステップＳ
１４では、既に（ステツプＳ６において）作成されてい
るブロックフローマップをサーチして、カウンタｍに対
応する名称を有するブロックを探す。そして、そのブロ
ック名称を有するステップフローマップを捜す。対応す
るマップが無ければ、ステップＳ３０に進んで、カウン
タｍをインクリメントして、ステップＳ３２を経てステ
ップＳ１４に戻る。対応するマップがあれば、ステップ
Ｓ１８で、該当するステップフローマップの中の、ブロ
ックｍステップｎ（ＢｍＳｎ）の「名称」を有するデバ
イスを実Ｉ／Ｏマップ中にサーチする。ステップＳ２
０，ステップＳ２２，ステップＳ２４においては、サー
チして見つかったデバイスに対応する「出力Ｂ」、「確
認Ａ」「手動Ａ」「動作時間」フィールドを、ステップ
フローマップ中にコピーする。ステップＳ２６ではカウ
ンタｎをインクリメントする。尚、対応するステツプフ
ローマップが見つかれば、そのマップのポインタアドレ
スをブロックフローマップ（第２２図）の「ポインタ」
フィールドに書き込む。

【００７１】１つのステップフローマップ中では、デバ
イスが動作される順に並んでいるので、そのステップフ
ローマップの全てのステップについての、「出力Ｂ」、
「確認Ａ」「手動Ａ」「動作時間」フィールドを埋めた
ならば、ステップＳ１４に戻って、上述の手順を繰り返
す。第３０図は、ラダープログラムを自動生成するプロ
グラム（このプログラムは、自動プログラミング制御部
５５のプログラムの一部である）の手順を示す。第３０
図のステップＳ４０では、レイヤを示すカウンタＬを、
最上位を示す値にセットする。

【００７２】ここでレイヤとは、ブロックフローチャー
トにおける層のレベルを示す。第４図の例では、ブロッ
クａ，ｃが第１層を、ブロックｂを第 ２層、ブロック
ｄを第３層と、ブロックｅを第４層と、ブロックｆを第
５層と、ブロックｇを第６層と呼ぶ。更に、ブロック
ｌ，ｍ，ｎを第７層と、ブロックｏを第８層と、ブロッ
クｉを第９層と、ブロックｊ，ｐ，ｑを第１０層と、ブ
ロックｋを第１１層と、ブロックｒ，ｓを第１２層と呼
ぶ。層に分けた理由は、下位層のブロックが起動される
条件は、そのブロックの上位のブロックの動作終了条件
に規定されるからである。従って、階層のつけ方は、左
側に位置する複数のブロックの中で、並列に起動される
関係にあるブロック同士（例えば、ブロックａ，ｃ）を
グループ化してそれらを参照し、そのグループの全ての
ブロックに同じ階層番号をつける。次に、これらのブロ
ックに続く「枝」の中で、並列関係が変化する最下位の
ブロック（例えば、ブロックｂ）を探索する。並列関係
が発生したところから、並列関係が変化するところまで
の複数のブロックに対して、上から下に向けて順に階層
番号を付していく。

【００７３】ステップＳ４０によれば、レイヤカウンタ
Ｌに対して、このように前もって付された階層番号の最
上位の番号がセットされる。第４図の例であれば、カウ
ンタＬには１がセットされる。ステップＳ４２では、カ
ウンタＬに示される階層に属する１つのブロックをみつ
ける。このブロックの番号をカウンタｍにセットする。
ステップ４６では、このブロックの上位のブロックを全
てサーチする。カウンタＬが３であれば、その層に属す
るブロックは、第４図の例では、ブロックｄであり、こ
のブロックｄの上位のブロックはｂ，ｃとなる。ステッ
プＳ４８では、見つかったこれらの上位ブロックの動作
終了条件の積を生成する。例えば、あるブロックＢ_２
の上位のブロックＢ_１ が４つの動作ステップからな
り、各々の動作ステップの動作終了を確認するスイッチ
出力を、例えば、Ａ_０ ，Ａ_１ ，Ａ_２ ，Ａ_３ とす
れば、ブロックＢ_２ はブロックＢ_１ の全ての動作が
終了していなくてはならないから、ブロックＢ_２ の起
動条件は、 Ａ_０ ＊Ａ_１ ＊Ａ_２ ＊Ａ_３ となる。

【００７４】尚、このブロックＢ_２ の起動条件の作成
において、ブロックＢ_１ の各動作ステツプにおいて
は、通常、『出』のためのデバイス動作（例えば、『Ｂ
Ｆ位置決め出』）と『戻り』のためのデバイス動作（例
えば、『ＢＦ位置決め戻り』）等のような相補関係の動
作が存在する。かかる動作に対応する論理は互いに消去
し合うので、上記起動条件に含める必要はない。

【００７５】また、並列動作を有するブロックを探索す
る手法は上記手法以外にもあり、例えば、下位のブロッ
クから上位のブロックを探索する手法等がある。ステッ
プＳ４８〜ステップＳ５０では、見つかった全ての上位
ブロックについての動作終了条件の積を生成する。ステ
ップＳ５２では、これをカウンタｍが示すブロックＢ_ｍ
の起動条件としたラダー要素を生成する。第８図の例
では、ラベル１３６０のラダー要素がこの起動条件を表
わしている。ここで生成されるラダー要素は、データフ
ァイル５６（第２３図）に前もってデータベース化され
ているラダーパターンのなかから、条件に合致したもの
を探す。ラダーパターンを探す手法は、本出願人によ
り、特願平１−２５３９９１、２−３０３７８、２−３
０３７９、２−２３１８４３、２−２３１８４５に詳細
に開示されている。

【００７６】ステップＳ５４では、システムに固定のラ
ダー要素（第１４図のＳＲＴラダーと、ＳＴＰラダーで
ある）を生成する。尚、ステップＳ５２において自動生
成されたブロックｍの起動条件は冗長な部分を含んでい
る場合が多い。冗長部分は最適化プログラム１２９によ
り最適化される。この最適化プログラムの詳細は後に説
明される。

【００７７】ステップＳ５６〜ステップＳ６２は、１つ
のブロック内の全ての動作ステップに対応するラダー要
素を次々と生成していく手順である。先ず、ステップＳ
５６で、ステップ番号を示すカウンタｎをゼロに初期化
し、ステップＳ５８では、動作ステップＢ_ｍ Ｓ_ｎ に
対応するラダー要素を生成する。この場合、番号Ｂ_ｍＳ
_ｎ のステップフローマップが参照される。そして、そ
のステップの「出力Ｂ」、「確認Ａ」「手動Ａ」のメモ
リ番地が参照され、ラダー要素が作成される。第８図の
例でいえば、「確認Ａ」は「０Ｃ６」番地の『ＲＲスラ
イド出』であり、「出力Ｂ」は「３０４１」番地の『Ｂ
４Ｓｔ１ＲＲスライド出』である。ステップＳ６０で
は、このステップＢ_ｍ Ｓ_ｎ が起動されるためのイン
ターロック条件を生成する。動作ステップが起動される
ためには、その前までの動作ステップが終了されている
ことが前提である。この場合、動作ステップＢ_ｍ Ｓ
_{ｎ− １} の終了条件が、このブロックＢ_ｍ Ｓ_ｎ のイ
ンターロック条件となる。第８図の例でいえば、『Ｂ４
ステップ１出力』『荷受台前進』『Ｂ４動作ＯＮ』がイ
ンターロック条件となる。こうして生成されたインター
ロック条件は、次のサイクルで、動作ステップＢ_ｍ Ｓ
_ｎ＋１ のインターロック条件となる。尚、上述の、ラ
ダー要素の生成は、本出願人による、前述の特願平１−
２５３９９１、２−３０３７８、２−３０３７９、２−
２３１８４３、２−２３１８４５に詳細に開示されてい
る。

【００７８】ステップＳ５６〜ステップＳ６０の処理
を、同じブロックＢ_ｍ 内の全ての動作ステップに対し
て行なうと、ステツプＳ６６に進む。そして、ステップ
Ｓ６６，ステップＳ７２で、レイヤ番号Ｌに属する他の
動作ブロックを探して、そのような動作ブロックが見つ
かったならば、ステップＳ４４に戻り、見つかった動作
ブロックについて、ステップＳ４４〜ステップＳ６２の
処理を繰り返す。

【００７９】同じ階層に属するブロックに対する処理を
全て行なったならば、カウンタＬをステップＳ６８でイ
ンクリメントしてからステップＳ７０で、上述の処理を
全ての階層に対して行なったかを判断する。全ての階層
のブロックに対して上述の処理を行なったのであれば、
ラダープログラムの生成処理は終了する。

【００８０】尚、ステップフローマップにおいても、例
えば、第７図の『ＦＬ基準ピンＡ出』と『ＦＬ基準ピン
Ｂ出』のように、並列動作を行なう動作ステップが存在
する。動作ステップの並列性は、ステップフローマップ
における「ＦＲＯＭ」と「ＴＯ」フィールドから判断で
きるのは、動作ブロックにおける並列性の判断と同じで
ある。並列関係にある複数の動作ステップ（例えば、
『ＦＬ基準ピンＡ出』と『ＦＬ基準ピンＢ出』）のイン
ターロック条件は、その上位の動作ステップ（「ＲＲス
ライド出」ステップ）の終了条件が共通になっている。
また、この並列関係にある複数の動作ステップの下位の
動作ステップ（例えば、第７図の『ＲＲ基準ピン出』）
の起動条件は、その並列関係にある複数の動作ステップ
の終了条件の積であるのは、動作ブロックにおけるラダ
ープログラム要素の生成と同じである。

【００８１】第３１図は、第２５図乃至第３０図で説明
した処理を模式化して示した。第２８図によれば、シス
テムの一部変更も、簡単に行なうことができる。即ち、
その変更が、デバイスの変更であれば、実Ｉ／Ｏマップ
において、その変更に係わる部分を「データ生成プログ
ラムにより修正すればよい。この場合、メモリ番地に変
更がない限りは、ラダープログラムの再生成は不要であ
ろう。また、変更がシーケンスの変更であれば、その変
更にかかる動作ブロックフローチヤート（第４図）また
は動作ステップフローチヤート（第７図）を修正し、再
度、第２９図，第３０図のプログラムをランさせて、ラ
ダープログラムを作成すればよい。この点において、本
システムの特徴は、実Ｉ／Ｏマップ（第２２図）に全て
のデバイスに関する情報が集中し、このマップをデバイ
ス名称で索引できることにより、シーケンス手順の変
更、デバイスの変更等は、その変更に係る部分だけの修
正を行なうだけで済む。即ち、システムの変更、修正が
極めて簡単である。

【００８２】尚、第１図の生産ラインでは、移載装置や
リニア搬送装置やねじ締めロボット等の設備が存在して
いる。これらの装置では、移載装置における動作は繰返
し動作であり、一方、連続搬送装置では連続動作であ
る。そして、繰り返し動作と連続動作とは、それらを表
現するラダーパターンは異なる。そこで、本システムの
データファイル（第２３図）中では、あらかじめ準備し
たラダーパターンを移載装置や連続搬送装置やねじ締め
ロボット毎に異なるライブラリとして分離して記憶して
いる。また、この装置間の相違により、１つの動作ブロ
ックのは、移載装置や連続搬送装置やねじ締めロボット
が混在することはないようにしており、各動作ブロック
のブロックフローマップ（第２２図）には、その種別を
表わすデータ（「装置種別」）が設けられている。ラダ
ープログラムを生成するときは、この種別を参照して、
対応するラダーパターンをライブラリから取り出すよう
にしている。これにより、ラダー要素の生成が速くな
る。尚、第３８図に、連続搬送におけるラダーパターン
の一例を示す。

【００８３】〈プログラム実行／故障監視／故障診断〉
以上、本実施例システムにおけるラダープログラムの自
動生成及びユーザインターフェースについて説明した。
またその過程で、ブロックステップ動作ブロックマップ
及び動作ステップがどういうものかが理解できた。第３
９図，第４０図，第４１図は、シュミレーションサブシ
ステム１０５，故障診断／復旧サブシステム１０６の夫
々のプログラム構成を示す。これらのサブシステム１０
５，１０６は、自動プログラミングサブシステム１０４
と同じく、マルチウインドシステム１２１とインターフ
ェースするＣＲＴインターフェースプログラムを夫々有
する。換言すれば、ＣＲＴ５８は、３つのサブシステム
１０４，１０５，１０６により共有される。同図はサブ
システム１０５，１０６のプログラム構成も示す。特
に、故障診断／復旧サブシステム１０６は、マップ制御
プログラム２０１，動作監視プログラム２０２，故障診
断解析プログラム２０３，復旧プログラム２０４等から
なる。故障診断は、故障の発生したことを特定する故障
検出動作と故障の実際に発生した箇所の特定（解析）動
作とからなる。

【００８４】故障発生の検出 第４０図，第４１図を用いて、シーケンス制御及び監視
及び故障診断のためのプログラム構成について説明す
る。第４０図，第４１図において、ラダープログラム２
２０は、個々の動作ステップにおける個々のアクチュエ
ータの具体的な動作を記述するものである。また、マッ
プ制御プログラム２０１は、動作ブロックマップ（第２
２図）及び動作ステップマップ（第２３図）を参照しな
がらラダープログラム２２０が実行する設備の動作をモ
ニタする。このマップ制御プログラム２０１の詳細は第
５３図に示さのる。また、動作監視プログラム２０２
は、マップ制御プログラム２０１とラダープログラム２
２０間とのやり取りを監視しながら、故障の発生を検知
するものであり、その詳細は第５４図に示される。さら
に、故障診断プログラム２０３は、監視プログラム２０
２の通知により故障が発生したことを知られされると、
故障診断を行なうものである。この故障の発生したアク
チュエータ（即ち、動作ステップ）は、監視プログラム
２０２とマップ制御プログラム２０１とが記録している
後述のステップカウンタの内容を診断プログラム２０３
が調べることにより知れる。アクチュエータ内の具体的
なデバイス若しくは接点は、診断プログラム２０３が、
入出力マップ（Ｉ／Ｏマップ：第２４図）のデータに基
づいて検出することができる。

【００８５】故障診断システムを理解するためには、動
作ブロック毎に設定された前述のＳＣ−ＲＥＧ（ＣＳと
略記する）等の理解が必要である。第４２図は、ある動
作ブロックｉ（ＢＬ_ｉ ）に設けられた上記ＣＳレジス
タと、タイムレジスタ（ＴＳ_Ｓｉ，ＴＳ_ｅｉ）と、ブロ
ックタイムレジスタＴＢ_Ｓを説明するものである。ＣＳ
レジスタＣＳ_ｉ は、ブロックｉで最後に実行終了した
動作ステップの番号を格納する。また、ステップタイム
レジスタＴＳ_Ｓｉは、最後に実行された、あるいは現在
実行中の動作ステップが開始された時刻を格納する。Ｔ
Ｓ_ｅｉは最後に実行が終了した動作ステップがその終了
した時刻が格納される。また、ブロックタイムレジスタ
ＴＢ_ｉ は、当該ブロックが起動可能になるまではゼロ
である。起動可能になると、ＴＢ_ｉ には起動可能にな
った時刻が格納される。

【００８６】ステップタイムオーバ 第４３図は、個々のブロックに夫々のＣＳレジスタが設
定されている様子を示している。ある動作ステップの実
行が終了した時点では、 ＴＳ_ｘｉ＝ＴＳ_ｅｉ−ＴＳ_Ｓｉ‥‥‥（１） がその動作ステップを実行するのに要した時間となる。
前述したように、カウンタＣＳ_ｉ は、ブロックｉが最
後に実行終了した動作ステップの番号（実際には、その
動作ステップの次の動作ステップ番号を示す）を記憶す
るから、このＣＳ _ｉ の内容から、最後に終了した動作
ステップの実行に要した時間ＴＳ_ｘｉを計算することが
できる。本実施例の故障診断システムでは、このＴＳ
_ｘｉと第２３図の動作ステップマップに記憶されている
個々の動作ステップの実行に要する標準時間τ_Ｓｉとを
比較することにより、 ＴＳ_ｘｉ−τ_ｓｉ＞δ_０ ‥‥‥（２） であれば、その動作ステップの実行に障害（『ステップ
タイムオーバ』）があったと判断する。ここでδ_０ は
定数である。

【００８７】ステップハングアップ また、本故障診断システムでは、定期的に実行が終了し
ていない動作ステップをスキャンし、現在までの経過時
間Ｔ_Ｐ −ＴＳ_Ｓｉが、 Ｔ_Ｐ −ＴＳ_Ｓｉ＞δ_１ ‥‥‥（３） であれば、当該動作ステップはループ若しくはハングア
ップしていると判断する。ここで、Ｔ_Ｐ は現在の時刻
であり、また、δ_１ は定数である。δ_１ は、通常、
その生産ラインの動作ステップの実行に要する時間のな
かで最大のものにある許容幅をもたせたものである。か
かる故障が『ステップハングアップ』である。

【００８８】ブロックハングアップ 第４３図，第４４図乃至第４８図を用いて『ブロックハ
ングアップ』について説明する。第４３図若しくは第５
図に示すように、互いに並行動作を行なう複数のブロッ
クが存在する。かかる複数のブロックをグループと考え
ると、ある１つのグループ（第４３図の例では、ＢＬ１
が１つのグループを形成する）の全ステップ動作が終了
して、そのグループに続く他のグループ（第４３図の例
では、ＢＬ２，ＢＬ３，ＢＬ４からなるＧＲ１）が実行
されるまでの時間経過を監視する必要がある。前述のブ
ロックタイムレジスタＴＢ_ｉ は、上記ブロックグルー
プが起動されるまでの経過時間である。各グループにつ
いて、測定動作時間を基準時間と比較しつつモニタする
ことにより、各グループ毎の異常、換言すれば、ブロッ
クから別のブロック間に遷移する過程で発生した故障を
診断することができるようになっている。このような故
障が『ブロックハングアップ』である。本実施例システ
ムにおいては、ブロックハングアップが発生した場合
は、更に、その原因となった動作ステップを特定するこ
とまでを行なう。

【００８９】『ブロックハングアップ』の原因となった
動作ステップを特定する手法について、第４４図乃至第
４８図を用いて説明する。これらの図は、『ブロックハ
ングアップ』の説明を容易にするために、４つの動作ブ
ロックからなるある生産ラインの動作ブロックマップを
簡略化したものである。第４４図の生産ラインは、簡単
に４つの動作ブロックから構成される。これらの動作ブ
ロックに対する動作ブロックマップは、簡略化して第４
５図のように示される。

【００９０】第４５図では、ブロック１からブロック２
が起動されるまでに要する時間をΓ _１２、ブロック１か
らブロック３が起動されるまでに要する時間をΓ_１３等
と表わされている。これらの遷移時間Γは前もって設定
可能だからである。例えば、ブロック４は、並行したブ
ロック２，３の終了により起動される。第４３図に関連
して説明したように、ブロックタイムレジスタＴＢ_ｉ
は、当該ブロックが起動可能になるまではゼロである。
そして、起動可能になると、その時刻が格納される。従
って、レジスタＴＢ_ｉ の値がゼロでなく、現在までの
経過時間が上記Γよりも十分に大きいときは、ブロック
ハングアップが起こっているものと判断できる。従っ
て、ブロック２，３の終了から、時間Γ_２４，Γ_３４が
経過してもブロック４が起動されない場合は、ブロック
ハングアップとして故障認識される。

【００９１】ブロック４が起動されないためにブロック
ハングアップが検出されたときは、その原因となった動
作ステップはブロック２，３のいずれかにある筈であ
る。第４６図は動作ブロック２の動作ステップマップ
を、第４７図はブロック３の動作ステップマップを示
す。第４６図によれば、ブロック２には４つの動作ステ
ップが設定され、各々のステップにおける出力は、Ｙ_１
，Ｙ_２ ，…Ｙ_４ であり、それらの出力アクチュエ
ータの確認スイツチはＸ_１ ，Ｘ_２ ，…Ｘ_４ であ
る。また、第４７図によれば、ブロック３には３つの動
作ステップが設定され、各々のステップにおける出力
は、Ｙ_５ ，Ｙ_６ ，Ｙ_７ であり、それらの出力アク
チュエータの確認スイツチはＸ_５ ，Ｘ_６ ，Ｘ_７ で
ある。上記確認スイツチＸ_１ 乃至Ｘ_７ の状態は、ブ
ロック２，３を終了する時点では、ブロック毎にユニー
クであり、且つ、事前に知り得るものである。第４８図
の起動条件マップは、第４４図の例に示された４つの動
作ブロックの夫々が起動されるための条件、即ち、動作
確認スイツチの状態論理を示すものである。図中、ブロ
ック４について言えば、ブロック２では出力Ｙ_１ 乃至
Ｙ_４ がオンされて、確認スイツチＸ_１ 乃至Ｘ_４ ま
でがオンされている。また、ブロック３では出力Ｙ_４乃
至Ｙ_７ がオンされて、確認スイツチＸ_４ 乃至Ｘ_７
までがオンされている。従って、ブロック４が正常に起
動されるときは、 Ｘ_１ ＊Ｘ_２ ＊ … ＊Ｘ_７ でなくてはならない。ブロック２，３はブロック１の終
了によって起動される。従って、ブロック２，ブロック
３の起動条件はブロック１の全動作ステップの確認スイ
ツチの状態の論理積となる。尚、第４８図において、
〈Ｎ〉は、確認スイツチが出力Ｙが“出”状態にあるこ
とを確認する状態にあることを意味し、〈Ｉ〉は、確認
スイツチが出力Ｙが“戻り”状態にあることを確認する
状態にあることを意味する。

【００９２】このように、各動作ブロックの起動条件
に、そのブロックの前段のブロックの全動作ステップの
出力を確認するデバイスの状態を論理積として組み合せ
たものをプログラム化すれば、当該動作ブロックの起動
は、前段の動作ブロックの全動作ステップの正常な終了
を確認しない限り行なわれない。換言すれば、起動条件
が満足されなければ、前述のブロックハングアップが起
こって、故障と正しく検知されるのである。しかも、故
障が検知されたブロックが認識されれば、起動条件マッ
プと、実際の確認スイツチの状態とを比較すれば、どの
スイツチが異常であるか、そして、入出力マップ（第２
４図）と動作ステップマップ（第２３図）とを参照する
ことにより、どの動作ステップのどの出力アクチュエー
タがおかしかったかを速やかに知ることができる。

【００９３】生産ラインにおけるシーケンス制御には、
経験上、動作ステップのアクチュエータが、「出」状態
でもなく、「戻」状態でもない状態で停止したり、ある
いは、「出」状態と「戻」状態の両方を示したりする場
合がある。この原因の１つは、重量の重いアクチュエー
タがバウンドにより「出」状態でもなく、「戻」状態で
もない「中途半端」な状態に陥ってしまうからである。
そして、従来では、このような状態は、見掛け上は、シ
ーケンス制御は正常に進んでいくから、その不良確認ス
イツチの状態によって起動される（別の動作ブロック
の）筈の動作ステップが何時までも起動されないという
理由で故障と認識されるに至るものの、しかしながら、
その停止点は、実際に障害が発生した動作ステップとは
かけ離れた動作ステップである可能性が高い。

【００９４】しかしながら、本実施例のブロックハング
アップ検知の手法によれば、前述したように、各動作ブ
ロックの起動条件に、第４８図のような、前段ブロック
の全確認デバイスのあるべき論理状態の論理積を設定し
ているので、ある１つの動作ブロックの動作ステップで
上述の中途半端なスイツチ状態に陥って、その動作ステ
ップで故障と認識できなくても、その動作ブロックが終
了して、次に続く動作ブロックが起動される際に、ブロ
ックハングアップとして確認できる。即ち、故障のあっ
た動作ステップと故障認識が行なわれた動作ステップと
が時間的にも空間的に余り離れたものとはならず、故障
診断が正確になるばかりでなく、復旧もより速やかにな
るという効果がある。

【００９５】〈故障箇所の解析〉上述したように、ステ
ップタイムオーバ、ステップハングアップ、ブロックハ
ングアップ等により故障が検知されると、故障ステップ
の特定により、動作ステップマップ（第２３図）から障
害のあるアクチュエータ（設備）が特定される。第２３
図に示すように、１つの動作ステップは設備の１つのア
クチュエータに対応するからである。ここで、故障アク
チュエータから、このアクチュエータがどのような状態
で停止しているか、即ち、このアクチュエータの動作を
定義するＬＳ（出と戻りの２つリミツトスイツチＬＳ）
がどのような状態になっているかを知る必要がある。

【００９６】第２４図の入出力マップ及び第２３図の動
作ステップマップはこのＬＳの状態を知るのに使われ
る。第２３図の動作ステップマップにおいては、アクチ
ュエータ識別番号欄が設けられている。この識別番号
は、それに対応するステップ（例えば、Ｂ_０ Ｓ_０ ）
で使われるアクチュエータを識別する番号（例えば、Ａ
_{０ １}）である。この識別番号は入出力マップの個々のア
イテムの番号である。第２４図の入出力マップは、個々
のアクチュエータの動作タイプや接点名を示すだけでは
なく、出状態を示す接点と戻り状態を示す接点との関係
をも記述する。アクチュエータは往復動作を行なうか
ら、１つのアクチュエータには必ず、出状態と戻り状態
とがペアで存在する。第２４図の入出力マップにおい
て、「対応関係」は、そのペア関係を記述している。例
えば、ＢＦというアクチュエータ（このアクチュエータ
は番号Ａ０２で識別される）の対応関係の欄には“Ａ０
３”と記されている。即ち、ＢＦアクチュエータが出状
態にあるときを番号Ａ_０２により特定し、この出状態に
対応する戻り状態は、番号Ａ_０３にあるということを示
している。

【００９７】従って、故障診断システムは、故障ブロッ
ク番号と故障動作ステップ番号とを得たならば、動作ス
テップマップから故障したアクチュエータの識別番号を
知り、この番号から、この故障アクチュエータには、ど
のようなＬＳが設定されているかを知ることができる。
そして、どのＬＳが設けられているかを知ることができ
れば、そのＬＳの状態を読出して、例えば、表示するこ
と等により、操作者に故障状態を伝えることができる。

【００９８】第２４図の入出力マップは、実際の動作シ
ーケンスを記述する動作ステップマップ（第２３図）
や、ラダープログラム（例えば、第４９図）とは独立し
ている。即ち、生産ラインが変更されて、動作ステップ
マップ（第２３図）やラダープログラム（第４９図）が
修正されても、入出力マップを修正する必要はない。即
ち、生産ラインの変更毎に故障診断プログラムを修正す
る労力から解放される。

【００９９】尚、上記標準実行時間τは、例えば、正常
作動時における所定回数のサイクルについての測定動作
時間の平均値｛ＴＳ_ｘｉ｝（ここで、記号｛ ｝は平均
を表わすものとする）と標準偏差値σとで規定される、
例えば、 τ＝｛ＴＳ_ｘｉ｝＋３σ ‥‥‥（４） と定義することが好ましい。より好ましくはサイクル毎
にデータτが更新される方がよい。何故なら、アクチュ
エータの動作特性は経年変化するからである。また、ブ
ロックハングアップの検出に用いる時間Γ（第２２図の
動作ブロックマップを参照）についても、経年変化を考
慮して、実際に要した時間に基づいて更新することが望
ましい。

【０１００】〈故障箇所の解析方法の改良〉ある動作ス
テツプや動作ブロックで、ステップタイムオーバ，ステ
ップタイムアウトやブロックタイムアウトが検出された
場合に、実際に故障が発生した箇所を特定する必要があ
る。ある設備のアクチュエータが故障しても、システム
はそのアクチュエータの確認スイツチの状態を読み出し
たときにのみ故障を認知し得る。換言すれば、上述の動
作ステツプについての、ステップタイムオーバ，ステッ
プタイムアウトが検出されるのは、故障したアクチュエ
ータの確認スイツチの出力を用いているラダーステップ
でタイムアウトやタイムオーバが検出されたときのみで
ある。本システムのラダープログラムの生成方法は、生
産ラインにおける動作を複数の動作ブロックに、個々の
動作ブロックにおける動作を更に複数の動作ステツプの
動作に分割し、個々の動作ステツプの動作における各ア
クチュエータの動作を実Ｉ／Ｏマップから引出してラダ
ープログラムを完成していた。上述の故障箇所の検出方
法によれば、個々の動作ステツプ段階で故障を検出でき
るのであるが、１つの動作ステツプが多くのラダープロ
グラム要素からなる場合（実際には、動作ステツプの動
作が１つや２つのラダープログラム要素からできあがっ
ていることは少ない）には、どのラダープログラム要素
で故障が発生したかを解析することは困難である。本出
願人の従来のシステムでは、故障箇所を解析するとき
は、多数の故障と思われる候補の信号から実際の故障箇
所の解析を行なうのに、人間が関与せざるを得ず、その
ために、故障箇所の解析は時間のかかるものであった。

【０１０１】更に、工程を動作ブロックと動作ステツプ
に分解して記述する手法では、動作ステツプの並列動作
は原則として行なわれないが、プログラムの改良過程
で、複数の動作ステツプを並列して処理ことも行なわれ
得る。このようなラダープログラム要素が１つの動作ス
テツプ内で並列して実行される場合にも、前述の手法で
故障を動作ステツプで検出しても、故障原因のデバイス
（リミツトスイツチ）を特定することはできない。

【０１０２】そこで、本実施例の故障診断システム１０
６は、故障原因の探索（候補の絞り込み）にバイナリ・
ツリー・サーチ（二分木探索）法を採用する。そして、
本実施例の二分木探索法は次のような特徴を有する。即
ち、今回の故障を探索し終えたときに、次回の探索を効
率化するために、今回の探索結果に重み付けを行ない、
次回の探索はその重みに応じて探索ルートを選択するの
である。

【０１０３】バイナリ・ツリー・サーチ法の概略 バイナリツリーサーチを説明するために、第４９図に、
１つの動作ブロック内にＳ_１ からＳ_４ までの４つの
動作ステツプからなる生産工程プログラムの例を示す。
第４９図中、表記Ｙはアクチュエータに対する出力信号
を示し、Ｍはその出力の確認信号を示すものとする。ア
クチュエータＹ_０ の動作確認を示す信号は第４９図の
例ではＭ_０ となる。更に、Ｘはその動作ステツプの起
動を規制する各種スイツチの信号を意味する。

【０１０４】ところで動作ブロック単位で故障検出を行
なう場合、換言すれば、ブロックハングアップのみを検
出するようにした場合に、第４９図のＳ_４ が動作ブロ
ックの最終動作ステツプであるならば、例えば、第４９
図のプログラムで、スイツチＸ_８ が故障した場合で
も、Ｙ_２ が出力されないために、確認スイツチＭ_２の
故障と検知される。即ち、スイツチＸ_８ が故障である
ことを解析するためには、スイツチＭ_２ が正常ではな
いと分っても更に上流にさかのぼって故障解析を行なわ
ねばならない。一方、Ｘ_８ のようなスイツチ信号はラ
ダープログラムで生成された信号ではなく、外部から入
力された信号であるから、Ｘ_８ が故障と解析されれ
ば、それ以上さかのぼる必要はない。このように見掛け
上の故障部位と、真の故障部位とを故障解析において切
り分けるために、本システムでは、『内部信号』と『外
部信号』という概念を導入する。ここで、ラダープログ
ラム内部で生成された信号そのもの、または、ラダープ
ログラムでオンされるアクチュエータ（例えば第４９図
のＹ_０ ）の動作確認信号（例えば、Ｍ_０ ）は『内部
信号』である。そして、ラダープログラム外から入力さ
れる信号は『外部信号』である。

【０１０５】第５１図は、第４９図のラダープログラム
を二分木（バイナリ・ツリー）で表現した図である。第
５１図中、より左側に位置したある信号（例えば、Ｍ_２
）は、これにシリーズに接続している右側に位置した
信号（例えば、Ｘ_７ ，Ｍ_１）とＡＮＤ（積）で結ばれ
ている。また、分岐点がある場合に、その分岐点はＯＲ
（和）関係を示し、例えばＭ_２ （アクチュエータＹ_２
の確認スイツチ信号）は（Ｘ_７ ＊Ｍ_１ ＊…）と
（Ｘ_９ ＊Ｘ_８ ）の両者と積（ＡＮＤ）を作る。第５
１図で、Ｘ_１ ，Ｘ_２ 〜Ｘ_１３は全て『外部信号』で
あり、Ｍ_０ ，Ｍ_１ 〜Ｍ_３ は『内部信号』である。

【０１０６】本システムでは、上記３つの故障（ステッ
プハングアップ，ステップタイムアウト，ブロックハン
グアップ）のいずれかが検出されると、その時点の全て
の確認スイツチ及びインターロツク条件を形成する信号
の状態（動作状態ファイル１１１）を記録するようにし
ている。そして、例えば第４９図のラダープログラムの
動作ステツプＳ_４ で例えばステップタイムアウトが検
出された場合は、故障診断プログラムは、第４９図のラ
ダープログラムから第５１図の如き二分木チャートを作
成し、そのチャートに示されたルートに沿って各確認ス
イツチの出力信号やインターロツク条件を構成する信号
をチェックしていく。この探索の過程にたいして二分木
探索の手法が使われる。

【０１０７】二分木チャートを作成することは簡単であ
る。前述したように、本システムにより生成されたラダ
ープログラムは、全て登録された信号名により特定され
る。従って、そのラダープログラムがコンパイルされた
時点で、そのプログラム中で使われている全ての信号の
各々がどの動作ステツプで使われているかを示す第５０
図のような所謂「クロスリファレンスリスト」が作成さ
れる。このリストは、第５０図に示すように、信号名の
アイウエオ順（または、アルファベット順）に並べられ
ている。このリストの各要素は、参照される信号名と、
その信号が前記の『内部信号』であるか『外部信号』で
あるかの種別と、その信号が出力される動作ステツプ番
号（『動作ステツプ（出力）』）と、その信号が確認信
号として使われる動作ステツプ番号（『動作ステツプ
（入力）』）とからなる。勿論、参照信号が複数の動作
ステツプで参照されれば、リスト中には複数の『動作ス
テツプ（入力）』フィールドが設定される。

【０１０８】故障が検出され、故障が検出された動作ス
テツプから派生する二分木ツリーを作成するためには、
故障の検出された動作ステツプ番号が分ればよい。そし
て、その動作ステツプのアクチュエータの出力信号を動
作ステツプマップ（第２３図）から知り、この出力信号
がアクテイブになるための条件を動作ステツプマップか
ら調べ、この条件中に現われる全ての動作確認信号及び
インターロツク条件中の信号を前記クロスリファレンス
リスト中に探索する。このようにして、次々に、現われ
る信号をクロスリファレンスリスト中に探し、その信号
を出力する動作ステツプを探索していけば、二分木ツリ
ーが作成される。

【０１０９】二分木探索法の理論そのものは、情報処理
の分野では周知である。探索方法の概略は、第５１図の
二分木ツリーの下流から上流に向かって、そのルートに
現われた信号を動作状態ファイル１１１に探し、探し出
した信号の値を読み出す。その読み出された信号が条件
を満たしていれば、更に上流の信号をツリーに沿って探
していく。ツリー若しくは動作ステツプマップが当該信
号が“１”（あるいは、“０”）であるべきことを示し
ているときに、読み出された信号が“０”（または
“１”）であるときに、条件を満たしていないと判断さ
れる。上流に向かって探索する過程で、分岐点に至れば
（例えば、第５１図でＸ_１３の上流）、常に例えば右側
の枝に分岐するというルールを設定しておく。１つの枝
の終端に至れば、元のルートを戻って先の分岐点（Ｘ
_１３）に戻り、先にたどらなかった他の分岐（Ｘ_１０の
上流）をたどっていく。

【０１１０】かくして、第５１図のツリーをたどってい
けば、いつかは実際の故障原因となった確認スイツチに
到達する。かかる二分木探索の手法は、故障がブロック
ハングアップとして検出されたときに特に有効である。
何故なら、本実施例システムでは、ある設備のアクチュ
エータが故障しても、そのアクチュエータの確認信号を
使用する動作ステツプにおいて、ステップタイムアウト
若しくはステップタイムオーバとして検出されるからで
ある。ところが、ブロックハングアップの場合は、ハン
グアップが検出されたこと自体が、故障がどのブロック
のどの動作ステツプで発生したかを特定しないからであ
る。従って、ブロックハングアップが発生した場合に
は、第４８図に関連して説明したブロック起動条件マッ
プから二分木ツリーを作成してサーチを行なえばよい。

【０１１１】しかし、この二分木探索法は全てのノード
（信号がツリー上で形成するノード）を探索するために
時間がかかる。それは、 ：探索が分岐点に至った場合に、どちらの分岐を選択
してよいか分らない。従来では、分岐点でどちらの分岐
を選ぶかは、前述したように右か左の分岐を画一的に選
択するか、あるいはオペレータがどちらかの分岐を選択
指示していたために、効率の悪いものであった。 ：内部信号（例えば、Ｍ_Ｏ ）が故障でないというこ
とを示す場合は、その内部信号を生成した元の信号 Ｘ_５ ／＊（Ｘ_１ ＊Ｘ_２ ＋Ｘ_３ ＊Ｘ_４ ） を探索する必要はないのに、単なる二分木探索では、全
ての信号をチェックしている。そこで、本実施例では、 ：の問題を解消するために、過去探索されたルート
のうち、実際に故障デバイスが見付かったルートに、故
障デバイスがみつかった毎に“１”の累積的に重み値
（次回の探索時の優先準位）を与えるようにしている。
ある１つのルートで４回故障デバイスが見付かれば、そ
のルートには値“４”が与えられる。値が大きなルート
は故障が過去多く発生したデバイスが存在するルートで
あるから、次回に故障が発生したときは、重み値が大き
なルートに沿って故障デバイスを探索すれば故障デバイ
スの見付かる確率は高まる。 ：の問題を解消するために、信号をチェックする毎
に、それが内部信号か外部信号かをチェックして、探索
の遡行を継続するか否かを判断している。

【０１１２】第Ｄ図は、第５１図の二分木ツリーのラダ
ープログラムにおいて、過去に故障が、デバイスＸ_８
で４回、Ｘ_３ で２回発見されたと場合に、各ルートに
どのような重み付けがなされるかを示したものである。
同図から明らかなように、 Ｘ_１３→Ｘ_１０→Ｍ_２ →分岐点 には重み“６”が与えられ、 分岐点→Ｘ_９ →Ｘ_８ には重み“４”が与えられ、 分岐点→Ｘ_７ →Ｍ_１ →Ｘ_６ →Ｍ_０ →Ｘ_５／→分
岐点→Ｘ _３ には重み“２”が与えられ、 分岐点→Ｘ_１１→Ｘ_１２ には重み“０”が与えられ、 分岐点→Ｘ_２ →Ｘ_１ には重み“０”が与えられる。このような重みが与えら
れた状態で、次に故障が起こったときには、分岐点で
は、重み値の大きな方の分岐を選び、具体的には、 Ｘ_１３→Ｘ_１０→Ｍ_２ →Ｘ_９ →Ｘ_８ の順で探索が行なわれる。換言すれば、過去故障の起こ
ったところは再度発生する確率が高いので、その箇所を
優先的に解析の対象とすることで故障箇所の発見を効率
的にする。尚、上記の、内部信号か外部信号かの判断
に係る制御は第５７図，第５８図に関連して後に詳細に
説明する。

【０１１３】故障監視の制御手順 次に、第５３図乃至第５６図に従って本実施例システム
における、ラダープログラムの実行／故障監視の制御動
作を説明する。第５３図は、動作ブロックマップ，動作
ステップマップに従って、当該生産ラインの各アクチュ
エータをラダープログラム２２０の動作を監視するマッ
プ制御プログラム２０１の制御手順である。このプログ
ラムが起動されるとステップＳ８２で、初期化を行な
い、起動可能な最初のブロックグループを検出する。こ
のグループには１つのブロックを含む場合もあれば複数
のブロックを含む場合もある。

【０１１４】ステップＳ８４では、新たに起動可能とさ
れたブロックの存在を調べる。このステップＳ８４の目
的は、主に、ある１つの動作ブロックの全ステップ動作
が終了して、この動作ブロックに続く実行可能な動作ブ
ロックが存在するかを調べるものである。このようなブ
ロックが存在すれば（ステップＳ８２から起動された場
合は、実行可能な動作ブロックは存在する筈である）、
ステップＳ８６では、そのブロック番号を検出する。か
かるブロック番号をｉとし、この番号は、当然、複数の
番号を含み得るものである。グループで実行可能な場合
があるからである。

【０１１５】ステップＳ８８では、そのような動作ブロ
ックの動作ステップマップを読み込み、ステップＳ９０
でその動作ブロックを実行中とマークする。ステップＳ
９２では、実行可能な動作ステップがあるかを調べる。
動作ステップが実行可能となるのは、ＣＳレジスタに示
されている動作ステップの動作が終了しているときであ
り、監視プログラム２０２のステップＳ１３６（第５４
図）で行なわれる。実行可能な動作ステップが当該動作
ブロックにあれば、ステップＳ１１０で、当該動作ブロ
ックｉのタイマレジスタＴＳ_Ｓｉに現在時刻を開始時刻
として書込む。ステップＳ１１０の動作を実行可能な動
作ステップがある限り行なう。実際には、グループ内に
複数の動作ブロックが存在すれば、その動作ブロックの
各々で１つの動作ステップが実行されることになろう。

【０１１６】実行可能な動作ステップが全て起動される
と、いずれかの動作ステップの動作が終了するまでは、
ステップＳ９２の判断はＮＯとなって、ステップＳ９４
に進み、いずれかの動作ステップの実行終了を待つ。い
ずれかの動作ステップの実行が終了したと終了信号がラ
ダープログラム側からシーケンス制御プログラムに伝え
られたら、ステップＳ９４からステップＳ９６に進む。
ここで、終了した動作ブロック番号ｉと動作ステップ番
号を読む。このｉにより終了した動作ステップを含む動
作ブロックが特定できる。ステップＳ９８では、終了時
刻を当該動作ブロックｉのタイマレジスタＴＳ_ｅｉに書
込み、ステップＳ９９で、当該動作ステツプが終了した
時刻、その動作ステツプに関連する確認スイツチの状態
を動作状態ファイル１１１に書き込む。終了した動作ス
テツプの状態を書き込むのは、第２０図，第２１図に関
連して説明したように、後に一連の動作ステツプの動作
を時間を追って復元するためである。ステップＳ１００
では、次に実行すべき動作ステップを示すためにＣＳレ
ジスタを１つインクリメントする。このような動作を行
なっていけば、アクチュエータ動作を終了した動作ステ
ップから順に、対応するブロックのＣＳレジスタが更新
されると共にＴＳ_ｅｉも更新されていく。

【０１１７】一方、監視プログラム２０２は、第５４図
のステップＳ１２０において、ラダープログラム２２０
からのステップ終了信号を監視している。いずれかのラ
ダー要素でアクチュエータ動作終了があったときは、ス
テップＳ１２２に進み、ラダープログラム側から知らさ
れた当該ブロック番号ｉ、ステップ番号を読取る。そし
て、ステップＳ１２４で、このブロック番号ｉからその
ブロックのタイマ値ＴＳ_ＳｉとＴＳ_ｅｉ並びに、動作ス
テップマップから当該動作ステップの実行予測時間τを
読取り、（１）式に従って経過時間ＴＳ_ｘｉを演算す
る。そしてステップＳ４６で、実行に要した時間ＴＳ
_ｘｉが異常に長かったかを判断する。

【０１１８】ステップＳ１２６の判断がＯＫであれば、
ステップＳ１３４に進んで、当該動作ブロックのタイマ
レジスタの内容をクリアし、ステップＳ１３６では、現
在レジスタＣＳ_ｉ に示されている動作ステップを実行
可能とマークする。このＣＳ _ｉ で示される動作ステッ
プは、ステップＳ１００で更新したように、終了した次
の動作ステップである。ある動作ブロックの動作ステッ
プが実行可能とマークされると、シーケンス制御プログ
ラムの第５３図のステップＳ９２でＹＥＳと判断されて
次の動作ステップの実行が行なわれていく。

【０１１９】このように次々と動作ステップが実行され
ると、ある動作ブロックについて、ステップＳ１０２に
おいて、ＣＳレジスタの内容が最終ステップ番号を超え
るとき、即ち、その動作ブロックの全処理を終了したと
なるときがくる。このときはステップＳ１０４で、当該
ブロックを終了とマークする。そして、ステップＳ１０
５で、全ての設備の確認スイツチの状態を、動作状態フ
ァイル１１１に当該動作ブロックの終了時刻と共に書き
込む。この全ての設備の確認スイツチの状態データは、
後述するように、シュミレーションを行なう時に利用さ
れる。

【０１２０】ステップＳ１０６では、現在のブロックの
次に起動されるべきブロックのためのタイマＴＢ_ｉｊに
現在時刻を書込む。ここで、ＴＢ_ｉｊは、ブロックｉが
終了して、このブロックｉの次に起動されるべきブロッ
クｊが存在することを明示するためのタイマであり、第
４５図のΓ_１２等に対応する。尚、タイムレジスタＴＢ
は次に起動されるべき動作ブロックの最初の動作ステッ
プが起動されれば、ステップＳ１０８でクリアされる。
ステップＳ１０６からステップＳ８４に戻り、新たに実
行可能な動作ブロックを探す。例えば、第５図の例で、
Ｂ１３の処理が終了してステップＳ８４に戻ったとき
に、まだブロックＢ１７の処理が終了していなければ、
ブロックＢ１３は実行可能とマークされない。

【０１２１】次に、第５４図のステップＳ１２６に戻っ
て、ステップタイムオーバ故障の発見の手順について説
明する。ステップＳ１２６で、ＴＳ_ｘｉ−τ＞δ_０ と
判断されたときは、当該動作ステップの実行にかかった
時間が異常に長かったのであるから、ステップＳ１２８
で、その動作ステップの属する動作ブロックを故障とマ
ークし、ステップＳ１３０で、予想時間τの更新を行な
う。この更新処理は第５６図にその処理手順の詳細が示
されている。即ち、動作ステップの処理に実際に要した
時間Ｔ_ｘｉと予想時間τとの差が小さくて、即ち、 Ｔ_ｘｉ−τ／τ＜ε （ここで、ε《１） であって、要した時間Ｔ_ｘｉがτよりも若干長かった場
合には、それは設備の経年変化によるものと判断して、
ステップＳ１９２において、過去のＴ_ｘｉと今回のＴ
_ｘｉとから、次回のためのτを計算して更新する。この
ような更新により経年変化をも考慮した正確な故障検知
が可能となる。

【０１２２】第５４図の制御手順において、ステップＳ
１３２で診断プログラム（第５５図）を起動してから、
ステップＳ１２０に戻る。ステップＳ１２０に戻るの
は、他の動作ブロックの動作ステップにおいても故障を
検出するためである。また、故障検出を行なってシーケ
ンス制御プログラムの実行を停止しないのは、１つの動
作ブロックを停止しても、並行動作すべき動作ブロック
があるので、その動作ブロックの動作を停止してはなら
ないからである。他の動作ブロックを停止しなくてもよ
いのは、そもそも、動作ブロックが他の動作ブロックと
独立して動作することを条件に定義されたものだからで
ある。

【０１２３】ステップＳ１３８以下は、ブロックハング
アップ若しくはステップハングアップを検出する手順で
ある。ある動作ステップでラダープログラムがハングア
ップした場合の対処を説明する。かかる場合は終了信号
は発生されない。従って、ステップＳ１２０からステッ
プＳ１３８に進む。ステップＳ１３８では一定時間の経
過を見る。これは、前回ステップＳ１３８に来てから現
在時点（時刻Ｔ_Ｐ ）までの経過時間が一定の値を超え
たかを見るものであり、換言すれば、ブロックハングア
ップ若しくはステップハングアップの有無ははこの一定
時間毎にチェックされるということである。ステップＳ
１４０では、実行中とマークされている動作ステップを
サーチする。これは、実行中とマークされている動作ブ
ロックの各ＣＳレジスタの内容が特定の動作ステップを
指し、且つ、ＴＳ_Ｓｉに開始時間が書込まれていなが
ら、ＴＳ_ｅｉが未だ更新されていないものである。ステ
ップＳ１４２では、現在までの経過時間Ｔ_Ｐ −ＴＳ
_Ｓｉを計算し、ステップＳ１４４では、（３）式に従っ
て、 Ｔ_Ｐ −ＴＳ_Ｓｉ＞δ_１ ‥‥‥（３） を判断する。判断がＹＥＳであれば、ステップＳ６４に
進み当該ブロックをステップハングアップ故障とマーク
する。

【０１２４】ステップＳ１４０で、実行中の動作ステッ
プがないと判断された場合について説明する。この場合
は、ステップＳ１５０では、ブロックタイムレジスタＴ
Ｂ_{ｉ ｊ}の値がゼロでないブロックｊをサーチする。ステ
ップＳ１０６に関連して前述したように、ＴＢ_ｉｊがゼ
ロでないものは、ブロックｉが終了してもそれに続くブ
ロックｊが未だ起動されていないことを示す。ステップ
Ｓ１５２では、そのようなブロックにおける動作ステッ
プが未起動のままの経過時間と前記予想時間Γ _ｉｊとの
差、 （Ｔ_Ｐ −ＴＢ_ｉｊ）−Γ_ｉｊ を計算する。そして、その差が定数δ_２ よりも大きい
ならば、ステップＳ１５６でブロックハングアップと判
断する。ステップＳ１５８では、故障診断プログラム
（第５５図）を起動する。

【０１２５】第５５図に従って、故障診断プログラム２
０３について説明する。この故障診断プログラムは、故
障がブロックハングアップであるか、あるいは、ステッ
プタイムオーバ，ステップハングアップであるかによ
り、処理を若干異にする。ステップタイムオーバ，ステ
ップハングアップが検出されれば、故障動作ステップが
直接的に知ることができるのに対し、ブロックハングア
ップの場合は、故障動作ステップを遡って追跡する必要
があるからである。

【０１２６】ステップタイムオーバ，ステップハングア
ップ故障の場合は、ステップＳ１６２において、故障と
マークされたブロックをサーチする。このマークはステ
ップＳ１２８しくはステップＳ１４８でなされたもので
ある。ステップＳ１６４では、検出されたブロックのＣ
Ｓレジスタの内容を読み、故障が検出された動作ステッ
プを特定する。ステップＳ１６６では、動作ステップマ
ップから故障したアクチュエータの識別番号を知る。ス
テップＳ１６８では、この識別番号から入出力マップ
（第２４図）をサーチし、ステップＳ１７０で、この識
別番号を有するアクチュエータの出と戻りのＬＳの番号
を知る。ステップＳ１７０では、これら知り得た、故障
の起こった動作ブロック番号，動作ステップ番号，アク
チュエータ番号，ＬＳ番号を表示して、操作者に対処を
うながす。

【０１２７】ステップＳ１６０でブロックハングアップ
が検出された場合について説明する。この場合は、ステ
ップＳ１７４で、ブロックハングアップが検出されたブ
ロック番号に対応する起動条件マップ（第４８図）を読
み込む。ステップＳ１７６では、マップに書かれている
確認スイツチの論理状態と、それらの確認スイツチの実
際状態とを比較して不一致の確認スイツチを探す。この
不一致スイツチデバイスの特定がなされれば、次に、ス
テップＳ１７８で、ハングアップが検出されたブロック
の親ブロックをブロックマップ（第２２図）からサーチ
する。ステップＳ１８０では、検出された親ブロックの
動作ステップマップ（第２３図）から、上記不一致スイ
ツチを使用している動作ステップを特定、これからステ
ップＳ１８２で、この動作ステップのアクチュエータ番
号やＬ／Ｓ番号を特定してステップＳ１８４に進む。ス
テップＳ１８４では、これらを表示する。以上のように
してサーチされた故障箇所が、デイスプレイ装置８のモ
ニタ画面上で所定の色で強調表示される。そして、作業
者による故障箇所の復旧作業が行なわれる。

【０１２８】以上説明した『ステップタイムオーバ』や
『ステップハングアップ』の検出は、基本的には、ステ
ップラダープログラム２０３とは独立したプログラムに
より行なわれている。このことは次のような効果を奏す
る。即ち、ステップラダープログラムには、上記故障検
出するための所謂、「トラツプ回路」を設ける必要がな
くなるということである。第４６図において、Ｍ_Ｙ
は、インターロツク条件ＩＬＣが満足されたことによる
出力であり、Ｍ_Ｙ が出力されると、アクチュエータ出
力Ｙが出力される。従来では、第４６図に示すように、
スイツチＭ_Ｙ が閉じたら起動されるタイマ回路Ｔを設
け、このタイマがタイムアウトする前に、出力Ｙを確認
するスイツチＸ_ＬＳが開かなければ故障（ＡＬＭオン）
とするものであった。しかし、本実施例によれば、この
ようなタイマ回路は不要になり、第４５図のように、本
来の生産シーケンス制御に必要なステップラダープログ
ラムのみを作成すればよいことになる。

【０１２９】故障解析のための制御手順 以上が故障診断（故障発生の検出、故障箇所の簡易な診
断）のための制御手順である。次に、故障解析の制御手
順について第５８図，第５９図，第６０図に基づいて説
明する。第５８図のプログラムは、第２５図のＣＲＴ５
８の所定の起動アイコン（例えば、『故障解析アイコ
ン』）を指定することにより起動される。ステップＳ２
００では、故障診断システム１０６からフェールした動
作ステツプＢ_ｘ Ｓ_Ｙ の番号を教えてもらう。ステッ
プＳ２０２では、Ｂ_ｘ Ｓ_Ｙ から始まる第５１図に示
された如き二分木ツリーを第５０図のクロスリファレン
ステーブルに基づいて作成する。動作ステツプＢ_ｘ Ｓ
_Ｙ が複数の出力ラダー要素を有すれば、個々の出力に
対して第５１図の二分木ツリーを作成する。本実施例で
は、ツリーの個々の信号は、ノード番号Ｎで特定され
る。ステップＳ２０４ではノード番号Ｎを保持するカウ
ンタＮを“０”に初期化する。第５１図の例では、Ｎ＝
０のノードはＸ_１３である。ステップＳ２０６では、カ
ウンタＮが指定する信号のデータを動作状態ファイル１
１１から読み出す。そして、ステップＳ２０８でこのデ
ータが正しいかを調べる。

【０１３０】先ず、故障が『外部信号』Ｘ_１３において
発生した場合を例にして説明する。前述したようにフェ
ール原因が外部信号である場合には、そのノードよりも
更に上流にさかのぼる必要はない。即ち、制御はステッ
プＳ２０８→ステップＳ２２６→ステップＳ２３４に進
み、ステップＳ２３４で、当該ノードの番号若しくは信
号をレジスタＦＤＮに格納する。ここで、ＦＤＮはフェ
ールと判定された信号名若しくはノード番号を記憶する
レジスタである。ステップＳ２３６では、フェールと判
定されたノードまでのルートに“１”ずつ重みを追加す
る。

【０１３１】次に、フェールが外部信号Ｘ_１１で発生し
た場合を説明する。かかる場合は、Ｎ＝０（信号
Ｘ_１３）のデータは正しいので、ステップＳ２０８→ス
テップＳ２１０に進む。ステップＳ２１０では、当該信
号が外部信号か内部信号かを判断する。第５１図の例で
はＮ＝０の信号は外部信号なのでステップＳ２４０に進
んで、次のノードが存在するかを調べる。第５１図の例
では次のノードはＸ_１０又はＸ_１１のいずれかである。
ステップＳ２４２では探索されていない分岐ルートが存
在するかを調べる。第５１図の例では、探索されていな
い分岐ルートはＸ_１０に向かうルートとＸ_１１に向かう
ルートの２つである。そこで、ステップＳ２４２からス
テップＳ２４４に進んで、探索されていない分岐ルート
のうちの最大重みを有するルートを選択する。探索され
ていない分岐ルートが１つしか内場合はステップＳ２４
４ではそのルートが選択される。また、探索されていな
い分岐ルートが２つ以上あって、それらが全て同じ値
（“０”も含む）の重みを有する場合は、最右側のルー
トが便宜上選択される。ステップＳ２４５では分岐ノー
ドポインタスタックＢＮＰに、この分岐点に戻ってきた
場合に次回に探索されるべき分岐ルートを対比する。そ
してステップＳ２４６でその選択されたルート上の現在
のノードに最近の１つのノード（即ち、Ｘ_１１）が指定
される。そして、ステップＳ２０６に戻って、そのノー
ド（即ち、Ｘ_１１）に対応する信号データを状態ファイ
ル１１１から読み出す。Ｘ_１１の信号は正しくないの
で、制御はステップＳ２０８からステップＳ２２６に進
む。Ｘ_１１はＸ_１３と同様に外部信号ノードなので、ス
テップＳ２２６→ステップＳ２３４→ステップＳ２３６
と進んで、Ｘ_１１が故障と記録すると共に、Ｘ_１３→Ｘ
_１１に至るルートに重み“１”を追加する。

【０１３２】次に、アクチュエータＹ_２ の確認スイツ
チ信号Ｍ_２ がフェールしている場合を例にして説明す
る。この場合は、ノードＸ_１３，Ｘ_１１，Ｘ_１０，Ｘ
_１２は正常である。ノードＸ_１３，Ｘ_１１のチェックを
終了した時点では、分岐ノードポインタスタックＢＮＰ
には、Ｘ_１０のルートが次に探索されるべきことが記憶
されている。次にＸ_１２のチェックをステップＳ２０８
で行なうところから説明を始める。制御はステップＳ２
０８→ステップＳ２１０→ステップＳ２４０→ステップ
Ｓ２４２に進む。Ｘ_１２の後には分岐点もノードも存在
しないから制御はステップＳ２４８からステップＳ２５
０に進む。ステップＳ２５０のフラグＦは前の探索でい
ずれかの内部信号にフェールが発見されたことを示すも
のである。前述したように、確認信号Ｍのような内部信
号はそれがフェールであることを示しているとしても、
その上流の信号がフェールしているためにフェールを示
しているに過ぎない場合がある。フラグＦは、以前の探
索で内部信号にフェールしているものがあったことを記
憶し、そのフェールしていることを示す内部信号のノー
ド番号は第６０図に示す故障ノードポインタスタックＦ
ＮＰに格納される。今の場合は、Ｆ＝０であるから、ス
テップＳ２５０からステップＳ２５６に進む。ステップ
Ｓ２５４では、ステップＳ２４５で退避しておいたリタ
ーン分岐点をスタックＢＮＰから取り出す。ステップＳ
２５６では、スタックＢＮＰにリターンポイント（ステ
ップＳ２４５で退避したＸ_１０のルート）が退避されて
いることを確認してから、ステップＳ２５８で次のノー
ドＸ_１０を指定し、ステップＳ２０６に戻る。外部信号
Ｘ_１０は正常であるから、Ｘ_１０に対しては、制御はス
テップＳ２０８→ステップＳ２１０→ステップＳ２４０
→ステップＳ２４２→ステップＳ２４８→ステップＳ２
６９に進み内部信号であるノードＭ_２ を指定する。

【０１３３】フェールしているノードＭ_２ について
は、制御は、ステップＳ２０６→ステップＳ２０８→ス
テップＳ２２６と進む。Ｍ_２ は内部信号であるので、
更にステップＳ２２６→ステップＳ２２８→ステップＳ
２３０と進んで、前述のフラグＦをセットする。そし
て、ステップＳ２３２で現在のノードカウント値Ｎをフ
ェールノードポインタスタックＦＮＰに退避する。

【０１３４】ところで、ステップＳ２２８でフラグＦが
セットされている場合も、ステップＳ２３２でスタック
ＦＮＰにノードカウントＮを退避している。これは、例
えばノードＸ_６ がフェールしているときには、ノード
Ｍ_１ ，Ｍ_０ もフェールというデータを状態ファイル
１１１に含んでいるので、Ｘ_６ に至るまでに内部信号
が２つあったことを示す必要があるからである。

【０１３５】ステップＳ２３２からステップＳ２４０に
進んで、次のノードを探す。第５１図の例では、Ｍ_２
の次には分岐点が存在する。そこで、制御はステップＳ
２４０→ステップＳ２４２→ステップＳ２４４→ステッ
プＳ２４５→ステップＳ２４６と進んで、次のノードＸ
_７ を指定する。このノードには正常な外部信号Ｘ_７が
ある。このノードＸ_７ については、制御はステップス
テップＳ２４６→ステップＳ２０６→ステップＳ２０８
→ステップＳ２１０→ステップＳ２４０→ステップＳ２
４２→ステップＳ２４８→ステップＳ２６９と進んで、
新たにノードＭ_１を指定する。

【０１３６】ノードＭ_２ については、制御は、ステッ
プＳ２０６→ステップＳ２０８→ステップＳ２１０→ス
テップＳ２１２と進んで、フラグＦをチェックする。フ
ラグＦは、フェールしたノードＭ_２ を調べる過程でス
テップＳ２２８でセットされている。従って、制御はス
テップＳ２１２→ステップＳ２２２と進み、フェールノ
ードポインタスタックの最新のポインタが示すノード番
号をフェールしたノードとする。前述したように、この
ポインタにはステップＳ２３２でノードＭ_２がセットさ
れている。ステップＳ２２４では、ノードＭ_２ に至る
ルートに対して重み値を更新する。

【０１３７】このように、内部信号がフェールしている
ことを示す場合は、そのフェールがその内部信号自体の
フェールによるフェールであるのか、それともその内部
信号の上流の信号によるフェールか直ちには分らないの
で、フラグＦとスタックＦＮＰにフェールしたノードの
存在を仮に退避しておく。そして、次に現われた内部信
号がフェールを示していないということは、その上流に
はフェールしたノードが無いことを示しているから、ス
タックＦＮＰに退避されている内部信号ノードが実際に
フェールしているノードであることになる。換言すれ
ば、信号に内部信号と外部信号という区別を付けること
により、不必要なノード探索が省略できる。

【０１３８】次に、ステップＳ２１４以下の手順につい
て、第６２図の例を参考にして説明する。第６２図で外
部信号ノードＸ_３１がフェールしているとする。また、
内部信号Ｍ_２０は第６２図に示しているように、多くの
外部信号の積から生成されているので、通常の二分木サ
ーチ法では、Ｍ_２０の他に、Ｘ_４１〜Ｘ_１００ という
多くのノードを調べなければ、フェールノードＸ_３１の
チェックには入れない。第５８図のステップＳ２１４以
下の手順はこの非効率を解消するものである。

【０１３９】ノードＸ_２０のチェックを終了してノード
Ｘ_４０を探す過程で、スタックＢＮＰにはステップＳ２
４５でリターン分岐点が退避され、ステップＳ２４６で
Ｘ_{４ ０}が指定される。Ｘ_４０のチェック過程のステップ
Ｓ２６９で内部信号ノードＭ _２０が指定される。このＭ
_２０のデータは正常であるから、制御はステップＳ２０
６→ステップＳ２０８→ステップＳ２１０→ステップＳ
２１２→ステップＳ２１４と進む。ステップＳ２１４で
は、上記リターン分岐点（Ｘ_２０とＭ_３０の間の分岐
点）がスタックＢＮＰから取り出され、ステップＳ２１
６でＭ_３０に向かう分岐ルートがあることを確認してか
ら、ステップＳ２１８でそのルートを指定する。そし
て、ステップＳ２４０→ステップＳ２４２→ステップＳ
２４８→ステップＳ２６９→ステップＳ２０６でノード
Ｍ_３０のデータを取り出す。Ｍ_３０は内部信号であるの
で、外部信号Ｘ_３１がフェールしている場合は、Ｍ_３０
もフェールしていることを示しているので、制御はステ
ップＳ２０６からステップＳ２０８→ステップＳ２２６
に進む。ノードＭ_３０の次にノードＸ_３１がフェールし
ていることを発見するために、スタックＦＮＰが使用さ
れることの制御手順は前に行なっているので省略する。

【０１４０】第６２図の例のように、分岐点に複数の分
岐ルート（Ｘ_４０のルートとＭ_３０のルート）があり、
その一部のルート（Ｘ_４０ルート）内に内部信号ノード
（Ｍ _２０）があり、その内部信号ノードが多くの信号
（Ｘ_４１〜Ｘ_１００ ）から形成されており、ところが
フェールは他の分岐ルート（Ｍ_３０のルート）にある場
合は、ステップＳ２１４以下の制御手順により、内部信
号Ｍ_２０の正常を確認した（この確認で充分である）時
点で、このルートの探索をそれ以上は行なわないで、本
来のフェールノードの存在するルート上の探索を開始す
る。このように、本実施例の探索手法は効率的なものと
なっている。

【０１４１】〈故障復旧〉以上が、本実施例システムに
用意された故障検出／故障診断／故障解析の手法であ
る。次に、このように検出された故障からシステムを再
起動可能状態（通常は、故障が発見された動作ステツプ
を含む動作ブロックの先頭）に復旧して再起動する手法
について説明する。本実施例システムの復旧方法の特徴
は、再起動可能状態への復帰に、マニュアルモードと自
動モードが用意されていることである。マニュアルモー
ドとは、オペレータが上記可能状態に復帰するように自
分の判断で順に手動スイツチをＣＲＴ５８からセットし
ていくものである。このマニュアルモードでは、上記状
態に復帰すると、それまでに行なった手動スイツチのセ
ットシーケンスをファイル（第４０図の２１０）に登録
しておく。このファイルは過去に起こった故障の復帰過
程を、故障の発生箇所毎に記録しているもので、後に故
障発生箇所をキーにして検索可能になっている。

【０１４２】自動復帰モードでは、その故障の発生箇所
に対応する過去記憶された復帰手順をファイル２１０か
ら呼び出して、その復帰シーケンスをシュミレートして
再起動可能状態に復帰する。同じ故障に対する復帰手順
は大体同じものである。従って、このような復帰手順を
記憶し、自動モードにおいて、そのシーケンスをシュミ
レートすれば、復帰操作が敏速に行なえるのみならず、
その手順が統一化され、例えば、初心者でも簡単に復帰
作業を実行することができる。

【０１４３】以下、第６３図乃至第７０図を参照しなが
ら、本実施例の復旧方法を説明する。第６３図は、復旧
方法の説明のために例示されたある設備（ワーク把持設
備）におけるワーク把持動作を説明する。この設備で
は、ワークＷを３つのシリンダが把持する。把持順序
は、シリンダＹ_０ →シリンダＹ_１ →シリンダＹ_２
である。これらのシリンダＹは、第６４図に示すよう
に、出状態と戻り状態が２つのスイツチにより確認され
る。第６５図は、第６３図の設備に対応する実Ｉ／Ｏマ
ップの例である。このＩ／Ｏマップでは、各シリンダに
対して夫々、出動作と戻り動作が定義されている。それ
らのシリンダがアクテイベートされるためには、『出
力』フィールドに記されている番号のメモリに“１”が
書き込まれることが必要である。夫々のシリンダの動作
は、対応する『確認Ａ』『確認Ｂ』フィールドの番地の
内容をチェックすることにより確認できる。これら３つ
のシリンダの全部で６つの動作は全て、マニュアルでシ
ュミレートできる。第６５図には、マニュアルでシュミ
レートするために“１”をセットすべきメモリ番地が
『手動』フィールドに設定されている。第６６図及び第
６７図は、夫々、３つのシリンダをシリンダＹ_０ →シ
リンダＹ_１ →シリンダＹ_２ の順序で駆動してワーク
Ｗを把持し、所定の加工動作を行なってから、シリンダ
Ｙ_２ →シリンダＹ_１→シリンダＹ_０ の順で把持を解
除するという動作を示すところの、動作ステツプマッ
プ，ラダープログラムである。第６７図のラダープログ
ラムをみても分るように、各シリンダは、独立して手動
で出状態に、あるいは戻り状態にセットすることができ
る。ラダープログラムで、ＭＡスイツチは自動実行モー
ドにおいてシステムが閉じる自動モードスイツチであ
り、ＭＳは手動実行モードにおいてシステムが閉じる手
動実行モードスイツチである。

【０１４４】第６３図の例で再起動可能状態は、シリン
ダが全て初期位置に戻った状態であると定義できる。も
し、シリンダＹ_２ がフェールしているならば、復帰手
順は、先ず、シリンダＹ_２ を戻し、次にＹ_１ を戻
し、次にＹ_０ を戻すことにより、再起動可能状態に復
帰できる。尚、第６７図のラダープログラムの各スイツ
チの信号に付された名称は、第６６図の動作ステツプに
より、Ｉ／Ｏマップ（第６５図）内のメモリ番地と関連
付けられている。

【０１４５】第６８図は、ＣＲＴ５８の表示画面の例を
示す。図中、３０１はマニュアル復帰を指示するための
アイコンであり、３０２は自動復帰を指示するためのア
イコンである。３００の表示領域にはラダープログラム
が表示される。領域３００内の全ての表示要素はアイコ
ンとして機能する。即ち、領域３００に手動スイツチが
表示されていれば、オペレータがそのスイツチの表示部
分を選択すると、システムはタッチパネル５７を介して
そのスイツチが押されたと認識できる。オペレータがど
のスイツチを領域３００内で選択したかをシステムが認
識できれば、システムはそのスイツチにＩ／Ｏマップ
（第６５図）の該当番地に“１”を書き込むことができ
る。『ＳＩ』アイコンは、ラダープログラム要素の１つ
を実行させるアイコンである。

【０１４６】このようにして、システムはＣＲＴ５８を
ユーザインターフェースのための入力出力装置として使
うことができる。第６８図中、３０３は、領域３００を
上下左右方向にスクロールするためのアイコンである。
また、３０４はブロック番号を指定するためのアイコ
ン、３０５はステップ番号を指定するためのアイコン、
３０７，３０８は指定されたブロック番号及びステップ
番号を表示する表示領域である。３０６は、『起動』ア
イコンであり、オペレータがシステムが再起動可能状態
に復帰したと判断してこのアイコンを選択すると、シス
テムはこれを検知して自動実行モードでラダープログラ
ムを再起動する。

【０１４７】第６９図は、故障が上述の故障診断システ
ムで検知された後において、マニュアルモードでの復帰
を制御する手順を示し、第７０図は自動モードでの復帰
の制御手順を示す。アイコン３０１（マニュアル復帰モ
ード）が選択されると、ＣＲＴ５８上に第６８図のよう
な画面が現われる。ステップＳ２７０では、故障が検出
されたブロック番号ステップ番号Ｂ_ｘ Ｓ_Ｙ を復帰プ
ログラムに入力する。ＣＲＴ画面の領域３００には入力
されたラダープログラムＢ_ｘ Ｓ_Ｙ が表示される。ス
テップＳ２７２では、ラダープログラムの自動実行モー
ドを消勢し、マニュアル実行モードを付勢するためにＭ
_Ｓ ＝１，Ｍ_Ａ ＝０とする。ステップＳ２７４ではタ
ッチパネル５７からの入力を待つ。オペレータは領域３
００に表示された各スイツチアイコンにタッチしなが
ら、そのスイツチをオンしたりオフしたりする。領域３
００に目的のステップが表示されていない場合は、スク
ロール用のアイコン３０３を操作し、または、目的のブ
ロック番号，ステップ番号を入力するためにアイコン３
０４，３０６を操作する（ステップＳ３００またはステ
ップＳ３０８，３１０）。

【０１４８】領域３００上のいずれかのスイツチアイコ
ンがタッチされると、ステップＳ２８２で、タッチされ
た座標位置がどのスイツチに当るかを検出し、そのスイ
ツチの対応メモリアドレスをＩ／Ｏマップ（第６５図）
から探し、そのアドレス中に指定された値を書き込む。
この場合、スイツチはモメンタリとなっているので、ス
イツチアイコンがオン状態を示している状態でタッチパ
ネル５７にタッチすると、そのスイツチはオフ状態
（“０”が書き込まれる）になり、逆にオフ状態でタッ
チされるとオンになる（“１”が書き込まれる）。ＣＲ
Ｔに表示されているスイツチのインターロツクは前述し
たように、種々制御可能であるが、オン状態では例えば
緑に、オフ状態では赤に設定されている。ステップＳ２
８６では、ステップＳ２８２で同定されたスイツチをそ
れが操作されたシーケンスと共に復旧シーケンスファイ
ル２１０に記憶する。

【０１４９】このようにスイツチが手動で変更された状
態で、『ＳＩ』アイコンが押されるとステップＳ２９０
でラダープログラムが１つ実行される。復帰プログラム
のいずれかのラダープログラム要素で、その要素は実行
される。即ち、例えば、シリンダＹ_１ が戻される条件
が揃っていれば、シリンダＹ_１ は初期位置に戻され
る。ステップＳ２９２では、そのアクチュエータが戻さ
れた（あるいは起動された）後の確認スイツチ信号を入
力し、ステップＳ２９４でそれらのスイツチの表示の更
新を行なう。ステップＳ２８２〜ステップＳ２８６，ス
テップＳ２９０〜ステップＳ２９４の動作を繰り返すこ
とにより設備は再起動可能状態に戻る。

【０１５０】操作者が再起動可能状態に戻った事を確認
し『再起動』アイコンを選択すると、ステップＳ３０２
で、ステップＳ２８６で記憶していたスイツチシーケン
スをファイルとして登録する。即ち、そのシーケンスは
ステップＳ２７０で入力された故障の発生したブロック
番号，ステップ番号と関連付けられて登録されて、以降
そのファイルにアクセスすることが可能となる。ステッ
プＳ３０４では、手動実行モードを解除し自動実行モー
ドに移るために、Ｍ_Ｓ＝０，Ｍ_Ａ ＝１とする。そし
て、ステップＳ３０６でラダープログラムをスタートす
る。

【０１５１】第７０図は、前述の手動再起動（第６９
図）により蓄積された起動シーケンスに基づいて再起動
をかけるための制御手順を示すフローチヤートである。
故障箇所が特定され、操作者が『自動復帰』アイコンを
選択すると、この自動復旧プログラムが起動される。復
旧プログラムは、ステップＳ３２０で故障が検出された
ブロック番号ステップ番号Ｂ_ｘ Ｓ_Ｙ を入力する。Ｃ
ＲＴ画面の領域３００には入力されたラダープログラム
Ｂ_ｘ Ｓ_Ｙ のラダー図が表示される。ステップＳ３２
２では、復帰シーケンスファイル２１０から該当するシ
ーケンスをサーチし、ステップＳ３２４でそにシーケン
スデータを読み出す。ステップＳ３２６では、手動実行
モードに変えるために、Ｍ_Ａ ＝０，Ｍ_Ｓ ＝１とす
る。ステップＳ３２８〜ステップＳ３３２は、読み出さ
れたシーケンスに従ってスイツチをセットし、１ステツ
プずつラダープログラムを実行するものである。ステッ
プＳ３３４では、操作者が再起動アイコン３０６を選択
するのを待つ。このアイコンが選択されたなら、ステッ
プＳ３３６，ステップＳ３３８で、元のシーケンス制御
ラダープログラムに従って生産が再開される。

【０１５２】かくして、上述の復帰方法によれば、操作
者の経験の多寡によらずに、正確で安定な復旧が可能と
なる。

【０１５３】〈シュミレーション〉シュミレーション
は、通常、第１７図のトライアル段階、または、実稼動
時に発生した故障を再現させることを主な目的とする。
本実施例のシュミレーションとは、実際の設備が動くこ
となくＣＲＴ５８上でラダープログラムがシュミレート
されるものである。トライアル段階であろうと実稼動段
階であろうと、シュミレーションを行なうためには、そ
の条件を整える必要がある。本実施例のような、生産工
程を複数の動作ブロックに分解し、個々の動作ブロック
を更に複数の動作ステツプに分解して表現した場合に
は、シュミレーションは一般的には動作ブロック単位に
行なわれる。従って、その動作ブロックがシュミレーシ
ョンされるためには、その動作ブロックの起動条件と、
その動作ブロック内の個々の動作ステツプの実行に必要
な種々の入力が必要となる。従来のシュミレーションシ
ステムでは、これらの条件を手動で与えていた。本シュ
ミレーションサブシステムは上記条件を自動的に与える
ものである。

【０１５４】第５３図のフローチヤートに関連して説明
したように、ステップＳ９９では１つのステップの動作
を終了すると、故障の検出の有無にかかわらずに、変化
のあったスイツチの状態を動作状態ファイル１１１に書
き込む。また、ステップＳ１０５では、ブロックの終了
毎に、全確認スイツチの状態を動作状態ファイル１１１
に書き込む。また、故障が検出されれば、その故障が検
出された時点のスイツチ状態も同ファイル１１１に書き
込まれる。そして、第２０図，第２１図に関連して説明
したように、上記状態ファイル１１１に記憶されたデー
タから任意の時点のスイツチ変化を忠実に復元できる。

【０１５５】第７１図は、動作ステツプＢ_０ Ｓ_０ に
おいてあるインターロツク条件ＩＬＣ_０ が満足される
とシリンダＹ_０ を駆動し、動作ステツプＢ_０ Ｓ_１
でシリンダＹ_０ がオンされ外部から信号Ｘ_１００ が
入力されたことを確認（Ｘ_０＝１）してシリンダＹ_１
を駆動し、動作ステツプＢ_０ Ｓ_２ でシリンダＹ _１
がオンされ外部信号Ｘ_１０１ が入力されたことを確認
（Ｘ_１ ＝１）してシリンダＹ_２ を駆動するというラ
ダープログラムである。第７２図は、第７１図のラダー
プログラムをシュミレートするためのシュミレートプロ
グラムである。シリンダ要素Ｙ_０ ，Ｙ_１ は、タイマ
要素ＴＭ_０ ，ＴＭ_１ に置き換えられている。これら
のタイマ要素のセット時間は、シリンダＹ_０ ，Ｙ_１
のＩ／Ｏマップに与えられている。例えば、第１５図の
Ｉ／Ｏマップでは、この時間は『動作時間τ』フィール
ドに与えられている。従って、第７１図のシーケンスラ
ダープログラムから第７２図のシュミレーションプログ
ラムを作成することは、動作時間τのデータを有してい
るＩ／Ｏマップを前もって作成しておくことにより容易
である。そして、第７２図のシュミレーションプログラ
ムは、動作ステツプＢ_０ Ｓ_０ においてあるインター
ロツク条件ＩＬＣ_０ が満足されるとＴＭ _０ を駆動
し、動作ステツプＢ_０ Ｓ_１ でタイマＴＭ_０がタイム
アウトし外部から信号Ｘ_１００ が入力されたことを確
認（ＴＭ_０ ＝１）して、タイマＴＭ_１ を駆動し、動
作ステツプＢ_０ Ｓ_２ でＴＭ_１ がタイムアウトし外
部から信号Ｘ_１０１ が入力されたことを確認（ＴＭ_１
＝１）してＴＭ_２ を駆動するというように、第７１
図のプログラムをシュミレーションする。

【０１５６】このように、シュミレーションプログラム
では、ラダープログラム中の、シリンダのようなアクチ
ュエータのように駆動されると物理的に動いて、その動
作に時間のかかるものがタイマ要素に変換される。そし
て、そのアクチュエータの動作確認スイツチ（例えば、
Ｘ_０ ）は、タイマ要素の内部スイツチ（ＴＭ_０ ）に
変換される。そして、アクチュエータ以外の出力（例え
ば、第７１図のＢ_０Ｓ_１ 信号）等は内部信号であるの
で変更する必要はない。換言すれば、操作者にシュミレ
ーションの過程を可視的に表示させるには、シュミレー
ションプログラム（第７２図）の動作の推移状態をＣＲ
Ｔ５８上に表示するよりも、第７１図のラダープログラ
ムのシンボルを表示した方が、操作者に違和感のない現
実感のあるシュミレーション表示を提供できる。その場
合、例えば、タイマＴＭ_０ がタイムアウトしていない
ときは、シリンダＹ_０ のシンボルの表示は赤色で、タ
イムアウトしていればシリンダＹ_０ のシンボルの表示
は緑色で表示するようにする。同じ理由により、アクチ
ュエータではない確認スイツチ類でも、オンしているス
イツチは緑色で、オンしていないスイツチは赤色で表示
する。

【０１５７】前述したように、シュミレーションプログ
ラム（例えば、第７２図のプログラム）が起動されるに
は、そのブロックの起動条件が満足されなければならな
い。このブロックの起動条件は、第４４図〜第４８図に
関連して説明したように、当該動作ブロック（第４４図
のブロック４）の前段にある動作ブロック（動作ブロッ
ク２，３）内の全ての確認スイツチの総和である。この
起動条件の論理式は、第７２図の例では、ＩＬＣ_０ と
して示されている。シュミレーションの起動時には、こ
のインターロツク条件の論理の実際の論理値は動作状態
ファイル１１１から得られる。即ち、第７２図のブロッ
ク０のシュミレーションラダープログラムの起動は、Ｉ
ＬＣ_０ にファイル１１１からデータを与えることによ
り可能となる。シュミレーションプログラムの各動作ス
テツプの起動は、タイマ要素のタイムアウトと外部信号
の入力があれば可能となる。

【０１５８】第７３図は、動作状態ファイル１１１に記
憶されたデータから復元した信号変化のタイミングチヤ
ートである。第７３図の例では、シリンダＹ_０ は時間
τ_０’ でオンし、シリンダＹ_１はτ_１ ’ でオンし
た。第７４図は第７２図のシュミレーションプログラム
により再現された動作の遷移を示すタイミングチヤート
である。第７３図と第７４図とで若干の差異があるの
は、実動作時間τ_０’ ，τ_１ ’ と、タイマ要素Ｔ
Ｍ_０ ，ＴＭ_１ の公称時間τ_０ ，τ_１とで差異があ
るからである。そして、外部から入力される信号Ｘ
_１００ ，Ｘ _１０１ が入力された時間（第７４図で時
刻ｔ_１ ，ｔ_２ ）は動作状態ファイル１１１に記憶さ
れているので、この時刻ｔ_１ ，ｔ_２ に状態ファイル
１１１からシュミレーションプログラムに入力される。

【０１５９】第７５図は、シュミレーション用のラダー
プログラムの実行制御を行なうシュミレーション制御プ
ログラム２０６の動作を示すフローチヤートである。ま
た、第７６図はある動作ブロックの動作状態ファイルの
フォーマツトを示す。第７６図の例では、この動作ブロ
ックの動作は複数個のレコードにより記憶されている。
最初のレコードは当該ブロックが時刻ｔ_Ｉ に起動され
たことを、２番目のレコードはその後ｔ_１ に変化があ
ったことを、３番目のレコードはｔ_２ に変化があった
ことを、‥‥‥示している。

【０１６０】第７５図の制御プログラムは所定の『シュ
ミレーション起動』アイコンを操作者が選択することに
より起動される（ステップＳ４０２）。ステップＳ４０
４では、シュミレーション対象の動作ブロックの指定を
オペレータに促す。ステップＳ４０６では、指定された
ブロック番号に対応するデータファイルをファイル１１
１中に探し、ステップＳ４０８で、その最初のレコード
のデータ（起動条件）を読み出し、ステップＳ４１０で
そのデータをシュミレーションラダープログラム（第７
２図のＩＬＣ_０ ）にセットする。ここで、データをラ
ダープログラム中にセットするとは、ラダープログラム
要素の対応メモリ番地はＩ／Ｏマップに保持されている
ので、このＩ／Ｏマップを参照することにより、対応す
るメモリ番地にデータを書き込む。ステップＳ４１２で
はラダープログラムを起動する。ステップＳ４１４で
は、シュミレーションの起動時刻ｔ_０ を記憶する。ス
テップＳ４１６〜ステップＳ４２６のループでは、ファ
イル１１１から１つのレコード（ｎ番目のレコード）を
読み出し、シュミレーション開始からの経過時間が、そ
のレコードの記録時刻から求めた経過時間（ｔ_ｎ −ｔ
_Ｉ ）に等しくなった時点で、そのレコードのデータを
ラダープログラム中にセットするものである。即ち、実
際のラダープログラム（第７１図）の実際の動作の記録
の開始（時刻ｔ _Ｉ ）からの経過時間 （ｔ_ｎ −ｔ_Ｉ ） が、シュミレーション実行中に経過したということは、
ｔ_ｎ に対応するｎ番目のレコードに記録された信号状
態の変化をシュミレーションプログラムに与えるべきと
きであることを意味する。そこで、ステップＳ４１６で
は、ｎ番目のレコードを読む。そして、制御プログラム
２０６によるシュミレーションの起動開始（ｔ_０ ）か
らの現在時刻ｔまでの経過時間 （ｔ−ｔ_０ ） が、そのｎ番目のレコードに記録された信号状態の変化
をシュミレーションプログラムに与えるべき時点に至っ
たかを判断するために、ステップＳ４１８で、（ｔ_ｎ
−ｔ_Ｉ ）と（ｔ−ｔ_０ ）とを比較する。その比較結
果が等しいならば、ステップＳ４２０では、そのｎ番目
のレコードに記録されている信号データを対応するメモ
リ番地に書き込む。ステップＳ４２２では、ファイル１
１１の当該ブロックの全てのレコードを読み取っていな
いことを確認してからステップＳ４１６に戻って上記動
作を繰り返す。

【０１６１】ステップＳ４１８で、シュミレーション開
始から時間ｔ_ｎ −ｔ_Ｉ が経過していないと判断され
たときは、ステップＳ４２４で全ての確認スイツチの出
力を読み取り、ステップＳ４２６で、それらの信号に変
化に応じてＣＲＴ５８上における表示を更新する。かく
して、本実施例のシュミレーション方法によれば、シュ
ミレーション条件が、実際に動作させたラダープログラ
ムの起動条件を記憶したものに基づいてセットされるの
で、正確且つ効率的なシュミレーションを実現できる。

【０１６２】〈ラダープログラムの最適化〉前述のシー
ケンスラダープログラムの自動生成サブシステム１０４
は、例えば、動作ブロックの起動条件の生成は、第４４
図〜第４８図に関連して説明したように、起動条件の生
成対象となる当該動作ブロックの直前段の全ての動作ブ
ロック内で用いられる確認スイツチの論理積で表わされ
るとした。そして、それらの論理積のなかで、同じ設備
（アクチュエータ）の相補的な２つの確認信号（『出』
確認信号と『戻り』確認信号）が含まれていれば、それ
らをキヤンセルすることにより、ある意味では、ラダー
プログラムを簡素化し、最適化しようとしていた。本シ
ステムの最適化プログラム１２９は、 ：動作ブロックの起動条件の中で、そのブロックの起
動に実際には関係しない条件を除去することにより、ラ
ダープログラムを更に最適化しようとするものである。 ：さらに、曖昧な動作をラダープログラムが有してい
るならば、その曖昧な動作のプログラム部分を検出し修
正することにより、ラダープログラムを最適化するもの
である。

【０１６３】起動条件の最適化 ある動作ブロックの起動条件の中で、そのブロックの起
動に実際には関係しないものの例を第７７図を参照して
説明する。第７７図において、ワーク４０２は移載装置
４００によりＡ位置まで移動される。ロボット４０６は
Ａ位置にあるワークを、そのワークに適したハンドによ
り把持する。複数のハンド４０４が、回転治具４０１に
装着されている。回転治具４０１は、ロボット４０６が
必要とするハンドをロボット側に供給するために回転
し、所定の回転位置で割り出しロックピン４０７により
ロックされる。第７８図は、第７１図の設備の動作を記
述したブロックフローマップ（一部にラダープログラム
が記載されている）であり、このマップは３つのブロッ
クからなる。ブロックＢ_０ はワーク４０２をＡ位置に
移載する動作を記述し、ブロックＢ_１ は回転治具の動
作を記述し、ブロックＢ_２ はロボット４０６によるワ
ーク４０２の把持動作が起動されるための起動条件を記
述する。ブロックＢ_０ の動作では、ワークがリミツト
スイツチ『ワーク到着』をアクチエートすると『ブロッ
ク０完了』信号を発生する。一方、ブロックＢ_１ で
は、信号Ｌ_１ を受けると『ロックピンアンロック』信
号が生成されて所定のアクチュエータ（不図示）をアク
チベートして治具４０１をアンロック状態にする。治具
４０１がアンロック状態になって信号『アンロック』が
発生すると信号『割り出し回転』が生成されて治具４０
１が中心４０３の周りに回転される。治具４０１のサー
ボが働いて所望のハンドがロボット側に着た時点で『割
り出し回転完』信号が生成されると『ブロック１完了』
信号が生成される。ブロックＢ_２ の最初のステップは
内部信号『ブロック２起動』を生成するロジツクを記述
する。ブロックＢ_２ 中の『起動条件』とは第４８図に
関連して説明したように、ブロックＢ_０ とブロックＢ
_１ の確認信号の論理積となる。従って、この『起動条
件』中には、信号『ロック』や『アンロック』等が含ま
れる。しかしながら、実際には、搬送されてきたワーク
の種類によっては治具４０１の回転は必要であったり不
要であったりする。何故なら、同じ種類のワークが送ら
れてくる限りは、ハンドの交換は不要となるからであ
る。従って、上記『起動条件』中の、信号『ロック』や
『アンロック』等が起動条件としては必ずしも必要なも
のではなく、除去した方がプログラム構造を簡易にし、
プログラム保守を行ない易くし、且つ不要なロジツクが
無くなることからプログラムも効率的に動作することと
なる。従って、どのようにして不要なロジツクが起動条
件中に含まれていることを検知するかが問題となる。

【０１６４】最適化プログラム１２９は、起動条件に不
要な論理が含まれている場合には、実際の生産現場で記
録を取った場合に、その論理を示す信号の発生時期が場
合場合でまちまちであることに着目し、そのようなまち
まちな発生時期を示す信号が起動条件に含まれている場
合にはその信号を起動条件から外すようにしている。プ
ログラム１２９は、上記発生時期を動作状態ファイル１
１１から検出するようにしている。第７９図は、第７７
図の設備における動作をケースＩとケースＩＩとケース
ＩＩＩ について記録した信号のタイミングチヤートで
ある。第７９図において、『ロック』信号の発生時期
は、ケースＩとケースＩＩとケースＩＩＩでは全て異な
ったものとなっている。回転治具４０１が回転する必要
が無い場合（ケースＩＩＩ ）もあれば、回転量が少な
い場合（ケースＩＩ）もあるからである。

【０１６５】第８０図は最適化プログラム１２９の制御
手順を示すフローチヤートである。このプログラム１２
９は所定のアイコンを選択することにより起動される。
ステップＳ４５０では、操作者が最適化しようと考えて
いる動作ブロックの指定を促す。ステップＳ４５２で
は、信号の発生時期をチェックするためにファイル１１
１を考慮すべき期間を指定する。但し、この期間は無指
定であってもよい。ステップＳ４５４では、この期間内
の状態ファイルデータであって、正常な動作結果となっ
たもののみを入力し、ステップＳ４５６で、これらのデ
ータから第２０図，第２１図に関連して説明したよう
に、タイミングチヤートを再構成する。ステップＳ４５
８では、第７９図に関連して説明したように、発生時期
の定まらない信号（第７９図の例では『ロック信号』）
を抽出する。ステップＳ４６０では、その動作ブロック
の起動条件を含むラダー図をＣＲＴ５８に表示すると共
に、ステップＳ４５８で抽出された信号を起動条件をか
ら削除してよいかのメツセージをＣＲＴ５８に表示す
る。削除してもよい旨の返答があったならば、ステップ
Ｓ４６４で、起動条件からその信号を削除する。ステッ
プＳ４６４では、更に、ブロックの起動条件にこの信号
を含めないとする生成ルールそのものを変更してもよ
い。かくして、ブロックの起動条件が最適化され、プロ
グラムが見易いものとなり、且つ、プログラムの実行速
度そのものが向上する。

【０１６６】曖昧部分の最適化 あるコントローラから他のコントローラに並列に複数の
信号を伝送する場合には、これらの信号間にスキュウが
発生する場合がある。このスキューは設備の誤動作の原
因となる。本来は、かかる制御の曖昧な部分は厳密に検
討されて対策されてしかるべきものであるが、あらゆる
部分で厳密にタイミングを検討することは不可能であ
る。そこで、最適化プログラム１２９は、曖昧部分を簡
便に検出し修正して最適化するものである。

【０１６７】第８１図，第８２図により、タイミング制
御が曖昧なラダープログラムの例を説明する。第８１図
は、ストローブ信号『データ送信』を受けて、Ｘ_１ 〜
Ｘ_４までをメモリに記憶する動作を記述するラダープロ
グラムである。外部のコントローラから信号『データ送
信』を受けると、内部信号『データ記憶』を発生する。
この『データ記憶』はサンプリングタイミングを形成し
て、データ信号Ｘ_１〜Ｘ_４ を受信すると、これらのデ
ータ信号をメモリに記憶すべく、記憶信号『Ｘ_１ 記
憶』『Ｘ_２ 記憶』等を発生する。第８２図は、データ
信号Ｘ_１ 〜Ｘ_４ のうち、Ｘ_４ が遅く送られてきた
ために、Ｘ_４ が誤って記憶された例のタイミングチヤ
ートを示す。本来は、遅れたデータ信号は発生されない
ように、その外部コントローラのラダープログラムが構
成されてしかるべきである。最適化プログラム１２９
は、発生時期が曖昧な信号は、その信号を記録した場合
に記録ケース毎に異なることに着目する。そこで、故障
が発生した場合に、その故障時の信号のタイミングチヤ
ートと、過去記憶しておいた正常時のその信号のタイミ
ングチヤートとを比べて、異なる部分があれば、その信
号は不安定な動作を起こし易いものと判断して、不安定
動作を起こしたことをチェックするラダープログラム要
素を自動的に発生するように生成ルールを変更する。第
８２図はルール変更の原理を説明する。即ち、不安定だ
と疑われる信号のタイミングチヤートを作成し、信号の
交差範囲と考えられるウインド（Ｔ_ＭＩＮ〜Ｔ
_ＭＡＸ ）を設定し、８３図のようなラダーロジツクを
作成する。第８３図のロジツクは、信号『データ記憶』
が入力されると、２つのタイマＴ_ＭＩＮ とＴ_ＭＡＸ
が起動される。タイマＴ_ＭＩＮ がタイムアウトしてＴ
_ＭＡＸ がタイムアウトするまでの間にＸ_１ 〜Ｘ_４
の信号を記憶する。Ｔ_ＭＩＮ がタイムアウトする前
に、または、Ｔ_ＭＡＸ がタイムアウトしてからＸ_１
〜Ｘ_４のいずれかが入力されるとフェールするというも
のである。

【０１６８】第８４図はこの最適化のためのプログラム
１２９の制御手順である。この手順は所定のアイコンを
選択することにより起動される。ステップＳ４８０で
は、操作者が最適化しようと考えている動作ステップの
指定を促す。ステップＳ４８２では、信号の発生時期を
チェックするためにファイル１１１を考慮すべき期間を
指定する。但し、この期間は無指定であってもよい。ス
テップＳ４８４では、この期間内の状態ファイルデータ
であって、故障と判断されたもののみを入力し、ステッ
プＳ４８６で、これらのデータから第２０図，第２１図
に関連して説明したように、タイミングチヤートを再構
成する。ステップＳ４８８では、第８２図に関連して説
明したように、発生時期の定まらない信号を抽出する。
ステップＳ４９０では、それらの信号のタイミングチャ
ートをＣＲＴ５８上に表示する。そして、ステップＳ４
９２で、ステップＳ４８８で抽出された信号についての
生成ルールを変更してもよいかのメツセージをＣＲＴ５
８に表示する。変更してもよい旨の返答があったなら
ば、ステップＳ４９４で、その信号のラダープログラム
及び生成ルールを変更するために、タイマ要素を第８３
図のように追加する。

【０１６９】尚、ステップＳ４８４における過去の状態
ファイルデータの収集は、明白な故障データ、例えば、
信号伝送ラインの断線等の故障データは省くべきであ
る。また、付加すべきロジツクは、上記例では、ウイン
ドを設定するタイマロジツクであった。これは信号伝送
等の場合は、信号が遅れたり、進んだりするからであ
る。信号伝送以外のロジツク、例えば、シリンダの駆動
を最適化する場合には、シリンダの動作時間が早まると
いうことはないから、シリンダの動作をチェックするロ
ジツクのタイマ値を変更するだけでよい。

【０１７０】〈実施例の効果〉以上、説明した実施例シ
ステムによれば、 ：ステツプタイムオーバ検出、ステツプハングアップ
検出、ブロツクハングアップ検出により、簡単で的確な
故障検出ができると共に、二分木サーチの手法により高
速に故障箇所の解析が可能になった。さらに、過去の故
障解析結果がノードの『重み』に反映されるので、故障
箇所の探索が更に高速化された。また、スイツチ信号
を、『外部信号』と『内部信号』に分類し、故障探索対
象の信号がそのどちらに属するかでそれ以上の探索を続
行するか否かを判定しているので、故障箇所の解析が高
速化する。

【０１７１】更に、前もって故障デバイスと故障の検出
される動作ステツプとを対応付けたデータベースを作成
し、このデータベースのなかを発生頻度順に故障デバイ
スの探索を行なうことにより故障解析が高速化する。 ：過去の故障に対する復帰過程を記憶し、同一故障に
対しては、その過程を記憶から呼び戻してそのシーケン
スを再生するという復旧処理手法を採用することによ
り、難解な復旧処理が単純化され、操作の統一化が図れ
る。 ：ラダープログラムの実際の稼動状態（または、シュ
ミレーション中の動作状態）を記憶し、故障のシュミレ
ーションあるいはラダープログラムの試行段階でのシュ
ミレーションにたいしては、この状態データをシュミレ
ーション条件として使用することにより、シュミレーシ
ョンが効率的に且つ正確に行なえるようになった。これ
は、状態データを示す信号名が名前によりシステム内で
特定されることによる効果が大きい。 ：動作ブロックあるいは動作ステツプの起動条件中に
存在する無駄な論理を、過去に記憶した動作状態を示す
データファイルを調べることにより発見し、その無駄な
論理を含むラダープログラムあるいは生成ルールを変更
することにより、シーケンスラダープログラムが最適化
される。ラダープログラムに存在する不安定な信号を、
過去に記憶した動作状態を示すデータファイルを調べる
ことにより発見し、その不安定な信号を含むラダープロ
グラムあるいは生成ルールを変更することにより、シー
ケンスラダープログラムが最適化される。

【０１７２】〈変形例〉本発明はその主旨を逸脱しない
範囲で種々変形が可能である。例えば、上記実施例は本
発明を自動車の生産ラインに適用したものであったが、
当然ながら本発明はそのような適用分野に限定されるも
のではない。少なくともシーケンス制御を行なうもので
あれば適用可能である。故障解析探索の変形例 第４９図〜第５２図，第５７図〜第６２図に関連して説
明した故障箇所の解析手法はバイナリサーチ（二分木探
索）に基づいたものであった。ここでは、故障解析の変
形手法を提案する。

【０１７３】この変形手法は、過去に発生した故障（発
生動作ステツプ番号）と、解析して得た故障発生箇所
（故障した確認スイツチデバイスの名称）とを関連付け
てデータベースに記憶し、これらのデータをソートす
る。ソートは、動作ステツプ番号を第１ソートキーと
し、故障デバイス名称を第２ソートキーとする。こうす
ると、第８５図に示すと共に、故障した動作ステツプ番
号毎に故障箇所がソートされ、故障データは同一動作ス
テツプについては発生頻度の高いデバイス順に並べられ
る。従って、ある動作ステツプ（Ｂ_ｘ Ｓ_Ｙ ）で故障
が検出されて、故障デバイスを特定する場合には、発生
頻度の高かったデバイスの順にサーチを実行すればよ
い。

【０１７４】第８６図はこの変形手法に係る制御手順を
示すフローチヤートである。ステップＳ５１０では、故
障が検出された動作ステツプの番号（Ｂ_ｘ Ｓ_Ｙ ）を
知る。ステップＳ５１２では、その番号を有するレコー
ド群を第８５図のデータベース中に探索し、さらに、ス
テップＳ５１４でそのレコード群のなかから、最大頻度
の故障デバイスを先ず故障している可能性が高いと推定
する。そして、ステップＳ５１６では、そのデバイスに
対応する確認信号のデータを記憶するメモリ番地を前述
のＩ／Ｏマップ（２４図，第６５図）から知る。ステッ
プＳ５１８ではそのメモリ番地からデバイスデータを読
み出してチェックし、その信号データが故障を示してい
るのであれば、ステップＳ５２４でそのデバイスを故障
とマークし、示していなければ、ステップＳ５２２で次
の発生頻度のデバイスについて調べる。

【０１７５】第８５図のデータベースをどのように作成
するかが問題である。第８７図はその作成手順を示す。
ステップＳ５３０では対象とならシーケンスラダープロ
グラムのシュミレーションプログラム（前もって作成し
たもの）を起動する。ステップＳ５３２では人為的に故
障を設備中に設定する。ステップＳ５３４では、設定し
た故障により発生した故障を検出した動作ステツプ番号
Ｂ_ｘ Ｓ_Ｙ を故障を設定したデバイス名称と関係付け
て記録する。この操作を充分なデータが得られるまで繰
り返す。尚、ステップＳ５４０に示すように、過去発生
した故障データをデータベースに組み込んでもよい。

【０１７６】第８８図は、第８５図のデータベース中の
データ間の関係を模式化したもので、動作ステツプＢ_ｘ
Ｓ_Ｙ に関連する集合である。同図の５００〜５０４
は、Ａ，，Ｂ，Ｃという３つのデバイスに起因する故障
のケースを集合として示したもので、領域５１０はデバ
イスＡにのみ起因する故障を、領域５００はデバイスＡ
にのみ起因する故障を、領域５０１はデバイスＡ，Ｂに
のみ起因する故障を、領域５０２はデバイスＡ，Ｂ，Ｃ
に共通して起因する故障を、領域５０３はデバイスＢ，
Ｃにのみ起因する故障を、領域５０４はデバイスＣにの
み起因する故障を表示する。同図から明らかなように、
共通部分にある故障の原因となるデバイスほど、実際の
故障の原因である可能性が高い。従って、そのような確
率の高いデバイスを優先してチェックすれば、故障デバ
イスが発見される効率が向上する。尚、第８８図中、５
０５は常にオンであるデバイスの集合を示し、５０６は
オフである集合を示し、５０７は当該動作ステツプに関
係のない信号の集合である。上記データベースの作成過
程であるいはデータベースの探索過程で、集合５０５，
５０６，５０７に関連する集合はサーチ対象から除外す
ることによりサーチが高速化する。

【０１７７】復旧の他の手法 第７０図に示した故障復旧方法は、システムがすべて自
動で復旧シーケンスファイルに従って復旧を行うという
ものである。これから説明する例は、セットされるべき
スイッチをシステムが色を変えて表示して操作者に復旧
シーケンスを提示する。第８９図は、そのための制御手
順であって、第７０図のステップＳ３２８〜Ｓ３３２ま
での手順と置きか得られるべきものである。即ち、シー
ケンスファイルに従って、ステップＳ５６０で、１つの
１つのデバイスをマニュアルでセットすべきものとする
意味で黄色で表示する。操作者が対応スイッチをセット
すれば、ステップＳ５６４で対応メモリ番地の内容を更
新し、ステップＳ５６６でラダープログラムを実行し、
実行の結果、変化があれば、表示をステップＳ５６８で
更新する。

【０１７８】

【発明の効果】以上説明した本発明のシュミレーション
プログラムの生成方法によれば、シュミレーション対象
のラダープログラムを実際に稼動させて得た動作状態デ
ータをシュミレーション条件とすることにより、正確な
シュミレーションプログラムを効率良く作成することが
できる。

【図面の簡単な説明】

【図１】，

【図２】，

【図３】本発明が適用された自動車の生産ラインを説明
する図。

【図４】，

【図５】，

【図６】図１の生産ラインにおける動作をブロック化
し、動作ブロックフローチヤートと呼ばれるフローチヤ
ート図。

【図７】図４の１つのブロックにおける動作を表わし、
動作ステツプフローチヤートと呼ばれるフローチヤート
図。

【図８】，

【図９】，

【図１０】図７のステツプの一部動作を表わすラダープ
ログラム図，

【図１１】生産ラインにおける設備をシンボル化した
図。

【図１２】，

【図１３】，

【図１４】，

【図１５】，

【図１６】実施例システムで使われるラダー要素のパタ
ーン図。

【図１７】生産ラインを管理するシステムを開発すると
きの手順を一般的に示す図。

【図１８】本実施例システムにおけるプログラム及びデ
ータの互いの関連を説明する図。

【図１９】本実施例システムの有する特徴的な機能を示
した図。

【図２０】，

【図２１】動作状態を表わすデータから動作状態の時間
変化を再生する手法を説明する図。

【図２２】実施例システムにおいてブロックフローマッ
プと呼ばれるマップの図。

【図２３】実施例システムにおいてステツプフローマッ
プと呼ばれるマップの図。

【図２４】実施例システムにおいて実Ｉ／Ｏマップと呼
ばれるマップの図。

【図２５】実施例システムのハードウエア構成を説明す
る図。

【図２６】実施例システムの自動プログラミング／デー
タ入力部の構成を示す図。

【図２７】デバイス名称と動作名称のライブラリ構造を
説明する図。

【図２８】データ入力プログラムの動作手順を説明する
図。

【図２９】，

【図３０】ラダープログラムコンパイラの手順を示すフ
ローチヤート図。

【図３１】本実施例システムの概略を説明する図。

【図３２】タッチパネルと表示との関係を説明する図。

【図３３】ＣＲＴにおける表示画面を制御するデータ構
造を説明する図。

【図３４】ＣＲＴにおける表示例を示す図。

【図３５】表示画面をセル分割した図。

【図３６】デバイス名称の各フィールドが各々意味付け
られていることを説明する図。

【図３７】ＣＲＴにおける表示を制御するためにユーザ
が入力するデータの構造を説明する図。

【図３８】連続搬送動作のためのラダーパターンを説明
する図。

【図３９】故障診断サブシステム１０６とシュミレーシ
ョンサブシステム１０５との関係を示す図。

【図４０】，

【図４１】実施例システムにおけるソフトウエア関係の
全体的に示す図。

【図４２】，

【図４３】，

【図４４】，

【図４５】，

【図４６】，

【図４７】，

【図４８】ブロックハングアップ等の故障の検出原理を
説明する図。

【図４９】，

【図５０】故障診断システムにおける二分木サーチの対
象となる設備の例を示すラダープログラム図，クロスリ
ファレンステーブル図。

【図５１】，

【図５２】故障診断システムにおける二分木サーチアル
ゴリズムにおいて、探索路に重みを付ける過程を説明す
る図。

【図５３】マップ制御プログラムの制御手順を示すフロ
ーチヤート。

【図５４】動作監視プログラムの制御手順を示すフロー
チヤート。

【図５５】，

【図５６】故障診断解析プログラムの制御手順を示すフ
ローチヤート。

【図５７】，

【図５８】故障解析に適用される二分木サーチアルゴリ
ズムの手順を示すフローチヤート。

【図５９】，

【図６０】，

【図６１】二分木サーチの手順で使われる各種データレ
ジスタを説明する図。

【図６２】二分木サーチが適用される他の例のラダープ
ログラム図。

【図６３】，

【図６４】復旧プログラムが適用される設備の一例を示
す図。

【図６５】復旧プログラムが適用される図６３設備のＩ
／Ｏマップを示す図。

【図６６】復旧プログラムが適用される図６３設備の動
作ステツプフローチヤートマップ図。

【図６７】復旧対象の設備のシーケンス動作を示すラダ
ープログラム図。

【図６８】復旧プログラムが実行されるときのユーザイ
ンターフェースのための表示画面例を示す図。

【図６９】復旧プログラムの手動復帰モードにおける制
御手順を示すフローチヤート。

【図７０】復旧プログラムの自動復帰モードにおける制
御手順を示すフローチヤート。

【図７１】シュミレーション対象のラダープログラム
図。

【図７２】図７１のプログラムをシュミレーションする
ためのラダープログラム図。

【図７３】，

【図７４】シュミレーションのなされる原理を説明する
図。

【図７５】シュミレーションプログラム１２９の制御手
順を示すフローチヤート。

【図７６】シュミレーションで使われるシーケンスファ
イルのフォーマツトを説明する図。

【図７７】最適化対象の設備の一例を示す図。

【図７８】図７７設備の動作を記述する動作ブロックフ
ローチヤートマップの図。

【図７９】図７８設備の動作を記述するプログラムを最
適化するための原理を説明する図。

【図８０】最適化制御の制御手順を示すフローチヤー
ト。

【図８１】最適化対象の設備の他の例を示す図。

【図８２】信号発生が不安定なために最適化が必要な理
由を説明する図。

【図８３】最適化を行なった後のラダープログラム図。

【図８４】最適化制御の制御手順の他の例を示すフロー
チヤート。

【図８５】故障解析の他の手法に使われるデータベース
構造を説明する図。

【図８６】故障解析の他の手法を説明するフローチヤー
ト。

【図８７】図８５データベースを作成する手順を示すフ
ローチヤート。

【図８８】図８６の故障解析手法の原理を説明する図。

【図８９】復旧の他の手法を説明するフローチャート。

Claims (5)

【特許請求の範囲】
1. 【請求項１】 複数の設備からなる生産ラインの動作を
   シュミレートするシュミレーションプログラムの自動生
   成する生成方法であって、 ａ：シュミレーションプログラムによるシュミレート対
   象としての、この生産ラインの動作を制御するシーケン
   スプログラムを作成する工程と、 ｂ：生成されたシーケンスプログラムを実際の設備に対
   して動作させながら、この設備の動作状態を示すデータ
   を後にアクセス可能なようにデータベース内に記憶する
   工程と、 ｃ：シュミレーション対象部分に対応する動作状態デー
   タを前記データベース内に特定する工程と、 ｄ：ｃにおいて特定された動作状態データを、そのシュ
   ミレーション対象部分のシュミレーション条件とするこ
   とを特徴とするシュミレーションプログラムの生成方
   法。
2. 【請求項２】 請求項１のシュミレーションプログラム
   の生成方法において、シュミレーションプログラムは個
   々の設備の夫々の出力動作に置き換えたタイマ要素とこ
   のタイマ要素を起動を規制するインターロツク条件とに
   より置き換えられたラダープログラムからなり、ｄ工程
   における前記シュミレーション条件は前記シュミレーシ
   ョン対象部分の動作時間データを含む。
3. 【請求項３】 請求項１のシュミレーションプログラム
   の生成方法において、シュミレーションプログラムは設
   備の動作をタイマ要素とこのタイマ要素を起動を規制す
   るインターロツク条件とにより置き換えられたラダープ
   ログラムからなり、前記シュミレーション条件は前記シ
   ュミレーション対象部分の前記インターロツク条件を含
   む。
4. 【請求項４】 請求項３のシュミレーションプログラム
   の生成方法において、このシーケンスプログラムが適用
   される全体の設備の動作が、１つの前記設備の動作を含
   む１つの動作ステップを１単位とし、複数の動作ステツ
   プからなる動作ブロックであって、他の動作ブロックの
   いかなる設備の動作とも干渉しない動作ステツプのみを
   集めた動作ブロックの集合により表現され、 前記起動条件は、１つの前記動作ブロックあるいは１つ
   の前記動作ステツプが実行開始されるための起動条件で
   ある。
5. 【請求項５】 請求項４のシュミレーションプログラム
   の生成方法において、 前記ｂ工程では、更に故障検知を行なう工程をｂ工程と
   併せて作動することにより、故障が検知された動作ステ
   ツプ並びにここに至るまでの複数の動作ステツプの動作
   状態データを前記データベースに記憶し、 前記ｃ工程は、前記データベースを介して、前記故障が
   検知された動作ステツプ並びにここに至るまでの複数の
   動作ステツプの動作状態データを読み出す。