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

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

Info

Publication number
JPH0573110A
JPH0573110A JP23773991A JP23773991A JPH0573110A JP H0573110 A JPH0573110 A JP H0573110A JP 23773991 A JP23773991 A JP 23773991A JP 23773991 A JP23773991 A JP 23773991A JP H0573110 A JPH0573110 A JP H0573110A
Authority
JP
Japan
Prior art keywords
block
program
failure
simulation
map
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP23773991A
Other languages
English (en)
Inventor
Toshihiko Hoshino
俊彦 星野
Toshiharu Sakamoto
俊治 坂本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mazda Motor Corp
Original Assignee
Mazda Motor Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mazda Motor Corp filed Critical Mazda Motor Corp
Priority to JP23773991A priority Critical patent/JPH0573110A/ja
Publication of JPH0573110A publication Critical patent/JPH0573110A/ja
Pending legal-status Critical Current

Links

Abstract

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

Description

【発明の詳細な説明】
【0001】
【産業上の利用分野】本発明は、例えばシーケンサ等に
より制御される生産設備を管理するシュミレーションプ
ログラムの生成方法に関し、特に、そのシーケンスプロ
グラムの最適化に関する。
【0002】
【従来の技術】自動車の組立ラインの如くの生産ライン
において、設置された種々の設備に対してコンピユータ
を内蔵したシーケンス制御部を設け、かかるシーケンス
制御部により各設備が順次行なうべき動作についてのシ
ーケンス制御を行なうようにすることが知られている。
かかるシーケンス制御では、シーケンス制御部に内蔵さ
れたコンピユータに制御プログラムがロードされ、その
シーケンス制御部が生産ラインに設置された種々の設備
の夫々に対する動作制御の各段階をシーケンス動作制御
プログラムに従って順次進めていくようになっている。
【0003】かかるシーケンス制御のための制御手法と
して、本出願人は、特願平1−335271号,2−1
10977号、2−30379号、1−253991
号、2−304022号、2−304023号、2−3
04024号、3−67290号、3−67291号、
3−67292号等を出願している。これらの出願にお
ける生産ラインの管理手法は、生産ラインの全設備のシ
ーケンサによる一般的な制御条件を入出力マップとして
記述し、その一方、ラインの具体的な順次動作を動作ブ
ロックと動作ステップという概念で把握し、その上で、
入出力マップ,動作ステップフローマップ,動作ブロッ
クフローマップとに基づいて、ラダープログラムを生成
するというものであった。
【0004】また、上記出願における故障診断において
は、設備が正常に作動している状態におけるシーケンス
制御回路部の構成要素の動作態様を基準動作態様として
予め設定しておき、設備の実際の作動時におけるシーケ
ンス制御回路部の構成要素の動作態様を上記基準動作態
様と順次比較していき、その差に基づいて故障検出を行
うようにしている。
【0005】更に、本出願人は、プログラム作成を効率
化し、且つ容易にできるようにするために、個々の動作
ステツプを記述するルールにおいて、その動作を端的に
表わす名称を付けて上記ルールをデータベース化して、
さらに、生産ラインを管理するシステムを、プログラム
の自動生成サブシステム、故障診断を行なうためのサブ
システム、ユーザインターフェースのためのサブシステ
ム、生成されたプログラムのシュミレーションを行なう
シュミレーションサブシステムの4つのサブシステムに
分け、これらのサブシステムのいずれからも上記データ
ベースを名前によりアクセスできるようにして、プログ
ラムの自動生成、プログラムの実行、故障の解析等のあ
るゆる操作において操作の簡便化、ミスの減少化を計っ
た。
【0006】
【発明が解決しようとする課題】上記出願におけるシュ
ミレーション方法によれば、CRT上で全てのプログラ
ムのシュミレーションが可能になったものの、そのシュ
ミレーションを開始するのに未だ多くの手間が必要とさ
れている。実際の生産ラインのシーケンスプログラムは
膨大な量のステップ数のプログラムからなる。シーケン
スプログラムは一部で並列動作があるものの基本的には
シーケンシャルに実行されていくものである。そのため
に、シーケンスプログラムをシュミレーションする場合
には最初のステップからプログラムを実行していく必要
がある。簡単なプログラムでは、このようなシュミレー
ション方法でもよいが、膨大なシーケンスプログラムで
は本来のシュミレーションを行ないたい目的部分に至る
までに時間がかかる。そこで、上記我々の出願では、シ
ュミレーション対象のプログラム部分を特定し、その部
分のステップの起動条件や環境条件をマニュアルで入力
するという方法を提案している。
【0007】しかしながら、システムが膨大になると、
シュミレーション部分が僅かでも、その部分の起動条件
や環境条件のデータ量は膨大になり、従ってマニュアル
でそれらを入力するといっても、それは極めて効率の悪
いものとなる。また、入力の際の入力ミスの発生も無視
できないであろう。そこで、本発明の目的は、実際の動
作と同じ動作をシュミレートすることができるシュミレ
ーションプログラムを効率良く開発することができるシ
ュミレーションプログラムの生成方法を提案するもので
ある。
【0008】
【課題を達成するための手段及び作用】上記課題を達成
するための本発明の構成は、複数の設備からなる生産ラ
インの動作をシュミレートするシュミレーションプログ
ラムの自動生成する生成方法であって、 a:シュミレーションプログラムによるシュミレート対
象としての、この生産ラインの動作を制御するシーケン
スプログラムを作成する工程と、 b:生成されたシーケンスプログラムを実際の設備に対
して動作させながら、この設備の動作状態を示すデータ
を後にアクセス可能なようにデータベース内に記憶する
工程と、 c:シュミレーション対象部分に対応する動作状態デー
タを前記データベース内に特定する工程と、 d:cにおいて特定された動作状態データを、そのシュ
ミレーション対象部分のシュミレーション条件とする。
【0009】
【実施例】以下、本発明を自動車の生産ラインのシーケ
ンス制御に適用した実施例を説明する。 〈実施例システムの特徴〉本実施例のシステムは、本出
願人の特願平3−67290,3−67291,3−6
7292を更に発展させたものである。ちなみに、上記
3件の特徴は、次のi〜iiiの3点にある。 : 生産ラインにおける管理対象となる設備の全ての
動作は、動作ブロックに分解され、そして、個々の動作
ブロックは更に複数の動作ステップに分解されている。ii : 各動作ブロック,各動作ステップには、それら
をプログラマ若しくは操作者(以下、操作者と略す)が
把握し易いように、その動作ブロック若しくは動作ステ
ップのそのものを、そしてその動作を想起でき易いよう
なユニークな『名称』が付けられている。
【0010】iii: このシステムは、ラダープログ
ラムの自動生成、生成されたラダープログラムのシュミ
レーション、実際の動作中若しくはシュミレーション中
におけるシステム管理、故障診断等の機能を有するが、
これらの機能をプログラム化する過程において、システ
ムと操作者とのユーザインターフェースは、そして、プ
ログラム間のプログラムインターフェースは上記『名
称』により行なわれる。換言すれば、上記機能及びユー
ザインターフェース、そしてプログラムインターフェー
スにより、シーケンス制御プログラムの開発や、システ
ムのメインテナンスに必要な工数の削減が可能となる。
即ち、iii−1 : 本システムでは、後述するように、シス
テム全体の全設備のデバイスや、そのデバイスを使うス
テツプや、それらのステツプからなる動作ブロックに、
換言すれば、このシステムでランされる全てのプログラ
ムにおいて変数となり得る全てのものに名称が付され、
それらの名称がライブラリ化される。従って、本システ
ムでランされる全てのプログラム(特に、シーケンスラ
ダープログラム)の作成過程で、ライブラリ化されたこ
れらの『名称』を使うことができるので、効率的なプロ
グラム開発が可能となる。
【0011】iii−2: 本システムでは、特にシー
ケンス制御プログラム、シュミレーションプログラム、
故障診断プログラム、CRT操作盤の画面制御プログラ
ムなど、生産設備に何等かの関連性のある全てのプログ
ラムは、共通のデータベース(このデータベースの一部
のデータを、『実I/Oマップ』と呼ぶ)をアクセスす
ることができる。このデータベースには、その生産ライ
ンの全デバイスに関する、そのデバイスを制御するのに
必要な一般化された情報(例えば、そのデバイスを駆動
する信号名、その駆動情報を確認する信号名など)を含
む。従って、上記のシーケンス制御プログラム、シュミ
レーションプログラム、故障診断プログラム、CRT操
作盤の画面制御プログラムは、の作成過程においては、
操作者はそのプログラム中でデバイス名、動作名等をプ
ログラム中に使うだけで、そのデバイスや動作に必要な
情報を参照することができる。
【0012】そして、上記システムの特徴i〜iiiに
加えて、これから説明する実施例システムの特徴は、iv : 故障発生時のシステムの状態のみならず、正常
動作時のシステムの状態を記憶してデータベース化して
おく。更に、故障が発生したときに、故障が検出された
動作ステツプの数ステップ前からその故障が検出された
動作ステツプまでのシステムの変化を記録する。これら
のデータを故障診断に役立てる。故障原因箇所の探索で
は、本明細書では、過去における故障原因探索ルート
(バイナリツリーサーチ法)を選択的に用いる手法と、
過去の故障原因を優先的に今回の故障原因と推定すると
いう手法とを提案している。: 故障が発生してか
ら、復旧の工程を記憶しておき、故障原因毎に復旧工程
をデータベース化する。過去の故障原因と同じ原因で故
障が起こったときに、データベースからその復旧工程を
取り出して表示装置に表示する。操作者は、その表示に
従って、復旧を行なうようにする。即ち、過去の復旧シ
ーケンスが今回の復旧のガイドとなる。これにより、復
旧が早く行なえ、且つ、復旧操作が操作者の熟練度に依
らなくなる。
【0013】vi: iii−1で述べたシーケンスプ
ログラムの自動生成では生成されたプログラムが必ずし
も最適なものとは限らない。本実施例システムは、生成
されたプログラムを最適化する方法を提供する。vi−1 : 本機能は、動作ブロックまたは動作ステツ
プを起動させる起動条件が冗長部分を含む場合には、そ
の冗長な部分を検出し、それを除去すると共に、シーケ
ンス制御プログラムの次回の自動生成の際に、そのよう
な冗長部分が再度生成されないように、生成ルールを改
善することにより、シーケンスプログラムを最適化する
ものである。冗長な起動条件を含むプログラムの動作パ
ターンは、その冗長部分に対応するパターン部分が、プ
ログラムが複数回故障もなく実行された場合に、その実
行の度毎に異なる筈である。起動条件の最適化は、この
異なるパターン部分を検出することから始まる。
【0014】vi−2: この特徴は、動作が不安定な
設備を含む場合に、その不安定な動作を行なうプログラ
ム部分を検出し最適化するものである。不安定な動作を
行なう設備をプログラム的に救済するためには、その不
安定な動作を行なった設備を検出する必要がある。そこ
で、疑わしい故障が検出されたときに、過去の原因のは
っきりした故障が発生したときのシステムの動作パター
ンと今回の疑わしい故障の動作パターンとを比較し、異
なるパターンに対応する設備が動作の不安定な設備と判
断する。そして、この設備のためのラダープログラムの
生成ルールを、上記不安定な動作を抑えるようなプログ
ラム要素を含むように最適化する。vii : 本機能はシュミレーションを効率的に行なう
ために、実際の設備で起こった動作パターンを複数の動
作ステツプに亙って記憶しておき、これらの動作パター
ンをシュミレーションプログラムにシュミレーション条
件として自動的に渡すことにより、シュミレーションを
効率良く正確に行なうものである。
【0015】これから説明する実施例は、自動車の生産
ラインのうちの、車体にエンジンやサスペンションをド
ッキングする工程におけるシーケンス制御プログラムの
自動生成等に本発明を適用したものである。従って、先
ず、シーケンス制御プログラム101の制御対象となる
車両組立ラインについて説明する。次に、本実施例のシ
ーケンス制御プログラムの自動生成等に重要な概念であ
る動作ブロックと動作ステップについて言及する。そし
て、その後に、本実施例の特徴部分である制御プログラ
ムの自動生成等にっいて説明する。
【0016】〈組立ラインの一例〉先ず、生成されるべ
きシーケンス制御プログラムの制御対象となる車両組立
ラインの一例について、第1図及び第2図を参照して述
べる。第1図及び第2図に、車両組立ラインの一部が示
されている。このラインは、例示的に、3つのステーシ
ョンST1,ST2,ST3からなる。位置決めステー
ションST1では、車両のボデイ11を受台12上に受
け、受台12の位置を制御することによりボデイ11の
位置決めを行う。ドッキングステーションST2では、
パレット13上の所定の位置に載置されたエンジン14
とフロントサスペンションアッセンブリ(不図示)とリ
アサスペンションアッセンブリ15とボデイ11とを組
み合わせる。締結ステーションST3では、ボデイ11
に対して、ST2にて組み合わされたエンジン14とフ
ロントサスペンション組立15とを、螺子を用いて締結
固定留する。また、位置決めステーションST1とドッ
キングステーションST2との間には、ボデイ11を保
持して搬送するオーバーヘッド式の移載位置16が設け
られている。ドッキングステーションST2と締結ステ
ーションST3との間には、パレット13を搬送するパ
レット搬送位置17が設けられている。
【0017】位置決めステーションST1における受台
12は、レール18に沿って往復走行移動する。位置決
めステーションST1では、受台12をレール18に直
交する方向(車幅方向)に移動させることにより、受台
12上に載置されたボデイ11を、その前部の車幅方向
についての位置決めを行う位置決め手段(BF)並びに
その後部の車幅方向の位置決めを行う位置決め手段(B
R)と、受台12をレール18に沿う方向(前後方向)
に移動させることにより、その前後方向における位置決
めを行う位置決め手段(TL)とが設けられている。さ
らに、ST1には、ボデイ11における前方左右部及び
後方左右部に係合することにより、ボデイ11の、受台
12に対する位置決めを行う昇降基準ピン(FL,F
R,RL,RR)が設けられている。そして、これらの
位置決め手段及び昇降基準ピンによって、位置決めステ
ーションST1における位置決め装置19が構成されて
いる。即ち、これらの位置決め手段及び昇降基準ピン
が、シーケンス制御プログラムの位置決め装置19につ
いての制御対象となる。
【0018】移載装置16は、位置決めステーションS
T1とドッキングステーションST2との上方において
両者間に掛け渡されて配されたガイドレール20と、ガ
イドレール20に沿って移動するキャリア21とから成
る。キャリア21には、昇降ハンガーフレーム22が取
り付けられていて、ボデイ11はこの昇降ハンガーフレ
ーム22により支持される。昇降ハンガーフレーム22
には、第3図に示されるように、左前方支持アーム22
FL,右前方支持アーム22FRが夫々一対の前方アー
ムクランプ部22Aを介して取付けられている共に、左
後方支持アーム22RL,右後方支持アーム22RR
(不図示)が夫々一対の前方アームクランプ部22Bを
介して取付けられている。左前方支持アーム22FL,
右前方支持アーム22FRの夫々は、前方アームアーム
クランプ部22Aを回動中心として回動し、前方アーム
クランプ22Aによるクランプが解除された状態におい
ては、ガイドレール20に沿って伸びる位置を取り、ま
た、前方アームクランプ部22Aによるクランプがなさ
れるときには、第3図に示される如く、ガイドレール2
0に直交する方向に伸びる位置をとる。同様に、左後方
支持アーム22RL,右後方支持アーム22RRの夫々
も、後方アームクランプ部22Bを回動中心として回動
し、後方アームクランプ部22Aによるクランプが解除
された状態においては、ガイド20に沿って伸びる位置
をとり、また、後方アームクランプ部22Bによるクラ
ンプがなされるときには、ガイドレール20に直交する
方向に伸びる位置をとる。
【0019】移載装置16にボデイ11が移載されるに
あたっては、移載装置16が、第1図において一点鎖線
により示されるように、レール18の前端部上方の位置
(原位置)に、左前方支持アーム22FL,右前方支持
アーム22FRの夫々が前方アームクランプ部22Aに
よるクランプが解除されてガイドレール20に沿って伸
びる。また、左後方支持アーム22RL,右後方支持ア
ーム22RRの夫々が後方アームクランプ部22Bによ
るクランプが解除されてガイドレール20に沿って伸び
て、その後、昇降ハンガーフレーム21Bが下降せしめ
られる。かかる状態で、ボデイ11が載置された受台1
2がレール18に沿ってその前端部にまで移動せしめら
れ、降下されていた移載装置16の昇降ハンガーフレー
ム21Bに対応する位置を取るようにされる。そして、
左前方支持アーム22FL,右前方支持アーム22FR
の夫々が回動されて、ボデイ11の前部の下方において
ガイドレール20に直交する方向に伸びる位置をとっ
て、前方アームクランプ部22Aによるクランプがなさ
れた状態となる。また、左後方支持アーム22RL,右
後方支持アーム22RRの夫々が回動されて、ボデイ1
1の後部の下方においてガイドレール20に直交する方
向に伸びる位置をとって、後方アームクランプ部22B
によるクランプがなされた状態となる。その後、昇降ハ
ンガーフレーム21Bが上昇させられて、第3図に示さ
れるように、ボデイ11が、移載装置16の昇降ハンガ
ーフレーム21Bに取付けられた左前方支持アーム22
FL,右前方支持アーム22FRと左後方支持アーム2
2RL,右後方支持アーム22RRとにより支持され
る。
【0020】また、パレット搬送装置17は、夫々、パ
レット13の下面を受ける多数の支持ローラ23が設け
られた一対のガイド部24L及び24Rと、このガイド
部24L及び24Rに夫々並行に延設された一対の搬送
レール25L及び25Rと、各々がパレット13を係止
するパレット係止部26を有し、夫々搬送レール25L
及び25Rに沿って移動するものとされたパレット搬送
台27L及び27Rと、これらのパレット搬送台27L
及び27Rを駆動するリニアモータ機構(図示は省略さ
れている)とを備える。
【0021】ドッキングステーションST2には、フロ
ントサスペンションアセンブリ及びリアサスペンション
アッセンブリ15の夫々の組み付け時において、フロン
トサスペンションアッセンブリのストラット及びリアサ
スペンションアッセンブリ15のストラット15Aを夫
々支持して組付姿勢をとらせる一対の左右前方クランプ
アーム30L及び30Rと、及び、一対の左右後方クラ
ンプアーム31L及び31Rとが設けられている。この
左右前方クランプアーム30L及び30Rは、夫々、搬
送レール25L及び25Rに直交する方向に進退動可能
に、取付板部32L及び32Rに取り付けられるととも
に、左右後方クランプアーム31L及び31Rは、夫
々、取付板部33L及び33Rに、搬送レール25L及
び25Rに直交する方向に進退動可能に取り付けられて
いる。左右前方クランプアーム30L及び30Rの相互
に対向した先端部と、左右後方クランプアーム31L及
び31Rの相互に対向した先端部とは、夫々、フロント
サスペンションアッセンブリのストラットもしくはリア
サスペンションアッセンブリ15のストラット15Aに
係合する係合部を有する。そして、前記取付板部32L
は、アームスライド34Lにより固定基台35Lに対し
て、搬送レール25L及び25Rに沿う方向に移動可能
とされる。取付板部32Rはアームスライド34Rによ
り固定基台35Rに対して、搬送レール25L及び25
Rに沿う方向に移動可能とされる。取付板部33Lは、
アームスライド36Lにより固定基台37Lに対して、
搬送レール25L及び25Rに沿う方向に移動可能とさ
れる。さらに、取付板部33Rは、アームスライド36
Rにより固定基台37Rに対して、搬送レール25L及
び25Rに沿う方向に移動可能とされている。従って、
左右前方クランプアーム30L及び30Rは、それらの
先端部がフロントサスペンションアッセンブリのストラ
ットに係合した状態のもとで、前後左右に移動可能とな
る。また、左右後方クランプアーム31L及び31R
は、それらの先端部がリアサスペンションアッセンブリ
15のストラット15Aに係合した状態のもとで、前後
左右に移動可能となる。また、これらの左右前方クラン
プアーム30L及び30R,アームスライド34L及び
34R,左右後方クランプアーム31L及び31R、及
びアームスライド36L及び36Rが、ドッキング装置
40を構成している。
【0022】さらに、ドッキングステーションST2に
は、搬送レール25L及び25Rに夫々平行に伸びるよ
うに設置された一対のスライドレール41L及び41R
と、このスライドレール41L及び41Rに沿ってスラ
イドするものとされた可動部材42,可動部材42を駆
動するモータ43等から成るスライド装置45とが設け
られている。このスライド装置45における可動部材4
2には、パレット13上に設けられた可動エンジン支持
部材(図示は省略されている)に係合する係合手段46
と、パレット13を所定の位置に位置決めするための2
個の昇降パレット基準ピン47とが設けられている。ス
ライド装置45においては、移載装置16における昇降
ハンガーフレーム22により支持されたボデイ11に、
パレット13上に配されたエンジン14,フロントサス
ペンションアッセンブリ及びリアサスペンションアッセ
ンブリ15とを組み合わせる際に、その係合手段46が
昇降パレット基準ピン47により位置決めされたパレッ
ト13上の可動エンジン支持部材に係合した状態で前後
動せしめられ、それにより、ボデイ11に対してエンジ
ン14を前後動させて、ボデイ11とエンジン14との
干渉を回避するようになっている。
【0023】締結ステーションST3には、ボデイ11
に、これに組み合わされたエンジン14及びフロントサ
スペンションアッセンブリを締結するための螺子締め作
業を行うためのロボット48Aと、ボデイ11に、これ
に組み合わされたリアサスペンションアッセンブリ15
を締結するための螺子締め作業を行うためのロボット4
8Bとが配置されている。さらに、締結ステーションS
T3においては、パレット13を所定の位置に位置決め
するための2個の昇降パレット基準ピン47が設けられ
ている。
【0024】第1図乃至第3図により説明した車両組立
ラインにおいて、位置決めステーションST1における
位置決め装置19,移載装置16、そして、ドッキング
ステーションST2におけるドッキング装置40及びス
ライド装置45,パレット搬送装置17、そして、締結
ステーションST3におけるロボット48A及び48B
は、それらに接続されたシーケンス制御部により、本実
施例のプログラム生成装置によって生成されたシーケン
ス制御プログラムに基づいてシーケンス制御が行われ
る。即ち、これらの上記位置決め装置19,移載装置1
6等は、シーケンス制御対象であるところの“設備”で
ある。
【0025】〈動作ブロックと動作ステップ〉第1図,
第2図の生産ラインにおける組立動作は、即ち、上記の
シーケンス制御対象の“設備”の全てが行う動作は複数
の“動作ブロック”に分解することができる。ここで
“動作ブロック”とは、 :複数の単位動作の集合である と定義することができる。動作ブロックの最も重要な性
質は、 :ある動作ブロックの開始から終了に至るまでの中間
過程で、他の動作ブロックから独立して干渉を受けるこ
となく、動作を完結することができるということであ
る。
【0026】この,の性質のために、動作ブロック
を1つのブロック(かたまり)として表記することが可
能となる。換言すれば、動作ブロックは、動作ブロック
のレベルにおいてのみ、他の動作ブロックと関係する。
動作ブロックが動作を開始できるためには、他の動作ブ
ロックにおける動作の終了が必要となる。この他の動作
ブロックは、1つの場合もあれば、複数の場合もあろ
う。即ち、1つの動作ブロックの動作終了がそれに連結
する別の動作ブロック(1つまたは複数の動作ブロッ
ク)の起動条件になったり、複数の動作ブロックの動作
終了が起動条件になったりするということである。
【0027】また、上記性質によれば、動作ブロックに
おける動作の中間段階で、他の動作ブロックに対して起
動をかけるということはない。また、動作ブロックの中
間段階で、他の動作ブロックからの起動を待つというこ
ともない。上記,の動作ブロックの定義から、次の
付随的な動作ブロックの性質,を導くことができ
る。 :動作ブロックは、上記,の性質を満足する単位
動作の集合のなかで、最大のものであることが望まし
い。このの性質は絶対的に必要なものではない。しか
し、を満足すると、生産ラインを記述する動作ブロッ
クの数が減り、工程全体の記述が単純化され、大変見易
いものとなる。 :動作ブロックは、その動作ブロックにおいて行なわ
れる動作の種類に応じても制限される。即ち、デバイス
の動作は、「繰り返し動作」、「連続動作」、「ロボッ
ト動作」等に大別される。本システムでは、ラダープロ
グラムを、定型的なラダーパターンから自動生成するも
のであるが、このラダーパターンはその動作が異なれば
大きく異なるので、1つの動作ブロック中には同一種類
の動作だけを行なうデバイスを集める。但し、この要請
はプログラムの効率化という観点からのものであるの
で、このの要請を守らないと、ラダープログラムの自
動生成が行なうことができないというものではない。
【0028】第4図は、第1図,第2図の生産ラインに
おける動作の全体的な流れを示すものである。第1図,
第2図に示した生産ラインを、乃至の条件を満足す
る動作ブロックにより記述すると、この第4図に示すよ
うに、a〜sの19個の動作ブロックが得られる。この
ようにして得られたブロック図は第1図乃至第3図の生
産ラインにおける動作を操作者が分析した上で得られた
ものである。図中、横方向の二重線により結合された2
つ(以上)の動作ブロックは並行して動作することを意
味する。また、2つの動作ブロックが実線で上下に結合
されている場合、上方に位置した動作ブロックにおける
動作が終了して始めて下方に位置したブロックの動作が
始まる。また、二重線の四角形は各ブロックの先頭を意
味する。
【0029】動作ブロックaは受台12の前進動作を意
味し『荷受前進』と呼ぶ。この『荷受前進』ブロックが
終了すると、『基準出』という名称のブロックbと『受
具出』という名称のブロックcとが並行して行なわれ
る。『基準出』ブロックbでは、前述の各基準ピン(F
L基準ピン,RR基準ピンが「出」という名の位置に駆
動され、TL位置決め手段等が「戻り」という名の位置
に駆動される。ブロックcでは、受台12がドッキング
位置に移動する。ブロックdの『移載上昇』という名称
のブロックでは、移載装置16がステーションST1に
おいて上昇する。ブロックdの動作が終了すると、この
ブロックdに続いて2つの流れで動作ブロックが処理さ
れていく。即ち、『移載上昇』ブロックに続いて、『基
準戻り』という名称のブロックeと『移載前進』という
名称のブロックhとが並行して動作する。ブロックeで
は、ブロックbにおいて出された基準ピンを「戻り」位
置に戻すという動作が行なわれる。一方、ブロックhで
は、移載装置16がステーション2に前進する。
【0030】ブロックeに続く『荷受後退』という名称
のブロックfにおいて、受台12が後退するという動作
が行なわれる。ブロックhでは移載装置16がステーシ
ョンST2に前進する。一方、ガイド部、ストラットク
ランプ部、パレットスライド部においては、ブロックl
(『ピン上昇』)とブロックm(『リフト上昇』)とブ
ロックn(『パレット前進』)が夫々実行される。ブロ
ックm(『リフト上昇』)とブロックn(『パレット前
進』)との終了はブロックo(『アーム出』)を起動す
る。
【0031】ブロックhとブロックlとブロックoにお
ける動作が終了すると、『移載下降』という名称の動作
ブロックiが実行される。以上の第4図の動作ブロック
の集合からなるフローチャートは、上述の〜の条件
に合致するような動作の集合をブロック化したものであ
り、前述したように、操作者が後述のフローチヤート作
成プログラムで作成したものである。そして、各動作ブ
ロックに付けられた名称は、その動作ブロックにおける
動作(複数)の特徴を短い言葉で表現するものである。
本実施例のシステムの特徴は、前記iiに記したよう
に、各動作ブロックの名称はユニークなものであり、動
作ブロックは、この名称によりソフトウエア的に特定す
ることができる。
【0032】各動作ブロックは複数の動作ステップから
なる。1つの動作ステップにおける動作には原則的には
1つのアクチュエータ(ソレノイド等)による動作が対
応する。第7図は、『基準出』ブロックbにおいて行な
われる複数の動作ステップからなるフローチャートであ
る。同図において、各ステップに付されたラベルは操作
者が付したそのステップの名称である。第7図のフロー
チヤートによると、『RRスライド出』ステツプにおい
ては、リア側の右スライドレール41Rが「出」状態に
され、『FL基準ピンA出』及び『FL基準ピンB出』
ステツプでは、受台12に対して車体12を位置決めす
るための前述の昇降基準ピンA,B(前部左側)を
「出」の状態にする。『RR基準ピン出』ステツプにお
いては、同じく後部右側の昇降基準ピンを「出」状態に
する。また、『TL位置決戻』、『BR位置決戻』、
『BF位置決戻』の夫々のステツプにおいては、位置決
め手段TL,BR,BFが「戻り」位置に戻される。こ
のようにして、第4図の『基準出』ブロックbは、第7
図に示されたステップ動作により表現される。この動作
ステツプフローチヤートも前述のフローチヤート作成プ
ログラムで作成する。
【0033】1つの動作ブロックの動作を表現する例え
ば第7図のような動作ステップフローチャートにおける
各ラベルは、前述したように、その動作ステップで駆動
されるアクチュエータデバイスを特定し、そのアクチュ
エータの動作を端的に表現するものとなっている。例え
ば、RR基準ピンが「出」状態にされる『RR基準ピン
出』というステップに対して、『RR基準ピン出』とい
う名称が付されている。ここで、この名称の前半部分の 『RR基準ピン』 はその動作ステップで駆動されるアクチュエータを特定
し、次の、 『出』 は、そのアクチュエータの駆動状態を意味する。換言す
れば、第4図,第7図のフローチャートの各動作ブロッ
ク及び動作ステップの名称に与えられた意味が理解でき
る人間及び装置にとっては、それらのフローチヤートが
第1図の生産ラインにおける動作を記述するものとなっ
ていると理解することは容易である。本実施例のシーケ
ンス制御プログラムの自動生成システムの目標は、この
ような第4図,第7図のフローチャートから第8図〜第
10図のようなラダープログラムを自動的に生成するこ
とである。尚、第8図〜第10図のラダープログラム
は、第7図に示された動作ブロックbの動作の一部に対
応するラダープログラム要素である。
【0034】〈ラダープログラムのシンボル〉ここで、
ラダープログラムのシンボルについて説明する。第1図
の生産ラインの例えば昇降基準ピン等の設備そのものは
ラダープログラム上では制御の対象とはならず、それを
駆動する例えばソレノイド等が問題となる。従って、生
産ラインの設備は、第11図に示されるようなシリンダ
アクチュエータにより等価され得る。このアクチュエー
タは、シリンダ内を図面上左右に移動するピストンの位
置により、その「出」状態と「戻り」状態が規定され
る。ピストンは、ソレノイドバルブが入力される信号B
により付勢されあるいは消勢されることにより、そ
の「出」状態と「戻り」状態のいずれかを取る。これら
の2つの状態は2つのリミットスイッチにより確認され
る。即ち、第11図の「設備」からの出力として、駆動
された事を確認するためのリミットスイッチからの出力
(「出確認」信号)と、原位置に戻されたことを
確認するためのリミットスイッチからの出力A (戻
り確認信号)とがある。
【0035】第12図は、第11図の素子の出力駆動動
作の論理を説明する図である。ソレノイドがオンするた
めには、インターロック条件ILCが満足されることで
ある。インターロック条件ILCは、一般に、その動作
ステップに特有の種々の起動条件を含む。各動作ステッ
プは、その前段の動作ステップの動作終了が実行条件と
なるから、インターロック条件ILCには、例えば、前
段の動作ステップの出力状態が確認されたことを示す信
号(例えば、第11図のA )が含まれるのが通常で
ある。さらに、このプログラムが生成したのではない外
部からの信号を含む。
【0036】第13図は全体シーケンスを自動生成する
際に用いる定型的な動作回路の一例を示す。第13図に
おいて、条件C は自動モード(生産ラインがシーケ
ンス制御プログラムに従って動作するモードである)で
この動作回路が動作しているときは閉じられる。条件C
は手動モードでこの動作回路が動作しているときに
閉じられる。C は通常閉じられている。従って、通
常の自動モードでは、インターロック条件ILC
が満足されれば、出力B が出力される。一
方、ILC は手動モードにおける動作条件の論理を
記述する。手動モードでは、接点C が開くので、条
件A ,ILC が同時に満足するか、条件A
,A が同時に満足すれば、B は出力され
る。一般に、Aは、手動動作のインターロック条件I
LC を殺すための論理である。
【0037】第13図のラダーパターンは、ある動作ス
テップのラダープログラムを表現するのに用いられる定
型的なパターンである。本システムに用意されている他
のラダーパターンを第14図〜第16図に示す。第14
図は、動作ブロックの開始と停止を定型的に記述するパ
ターンである。第15図は、第13図に関連して説明し
たパターンと同じである。第16図は、第15図のパタ
ーンに更に1つの接点条件を付加したものである。
【0038】第8図のラベル1360,1372は第7
図の『RRスライド出』に対応するラダープログラムで
ある。ラベル1360の論理において、5041番地の
「B4ステップ1出力」は、 (B4ステップOFF*基準ピン戻り*荷受台前進+B
4ステップ1出力) *B4ステップ2出力/*B4ステップ3出力/ =
1 が満足されると、“1”を出力する。ここで、B4は第
4図における『基準出』ブロックbのブロック番号であ
る。また、「/」は論理NOTを表記する。また、「B
4ステップOFF」は、ブロック4の全てのステップが
オフ(即ち、実行されていない)であることを意味す
る。また、1753番地の『基準ピン戻り』,『荷受台
前進』は、ブロック4の『基準出』に先行する『荷受前
進』ブロックにおける動作終了を意味する。また、B4
ステップ2出力/やB4ステップ3出力/についても容
易に推測ができよう。かくして、ラベル1360の動作
は、『基準出』ブロックの最初の動作ステップ『RRス
ライド出』が正しく起動されるべき条件を表わす。従っ
て、ブロックの『荷受前進』の全ての動作ステップが終
了していれば、上記条件式は満足されて、「B4ステッ
プ1出力」は“1”になる。一旦、「B4ステップ1出
力」が“1”になると、ラベル1360のラッチ条件に
より、「B4ステップ1出力」は“1”のままである。
【0039】第8図のラベル1372の出力「B4St
1RRスライド出」が“1”になるのは、 B4ステップ1出力*荷受台前進*B4動作ON*RR
スライド出/ =1 が満足されたときである。ここで、B4St1はブロッ
ク番号4の最初のステップであることを表記する。『R
Rスライド出』なる動作がなされるのは、「B4ステッ
プ1出力」が“1”になって、『RRスライド』なるア
クチュエータがオンされていない状態で『荷受台前進』
ステップが実行されたときである。
【0040】第9図,第10図のラダープログラムは、
第7図の『FL基準ピンA出』,『FL基準ピンB出』
という2つの動作ステップに対応することは容易に理解
される。かくして、第4図のブロックbの『基準出』ブ
ロックが、第7図の動作ステップフローチャートに対応
する形で表わされた場合、その動作ステップフローチャ
ートの『RRスライド出』,『FL基準ピンA出』,
『FL基準ピンB出』という3つのステツプは第8図〜
第10図のラダープログラムに対応することが理解でき
よう。
【0041】〈システムの構成〉 i)〜vii)で述べたように、本システムの大きな目
標は、第1図のような生産ラインの工程管理を如何に効
率良く行なうかである。そして、ラダープログラムの自
動生成、生成されたラダープログラムのシュミレーショ
ン、生成されたラダープログラムの実際の動作中若しく
はシュミレーション中におけるシステム管理、故障診断
等の機能を如何に自動化するかが大きな関心である。第
17図は、ある生産ラインに、工程管理を行なうシステ
ムが導入されるプロセスを、一般化して表わした概念図
である。また、第19図は、実施例システム全体に要求
されるプログラム機能を図示したものであり、第18図
は、本実施例のシステムに要求される機能間の結合関係
をブロック化して表わしたものである。
【0042】第17図に示すように、生産ライン及びそ
の管理システムの導入は、その基本設計から始まって、
更に詳細設計、シーケンスプログラムの作成、そのプロ
グラムのトライアル、そして実稼動という工程で表現さ
れる。第18図に示された本実施例に係るシステムは、
特に第17図における、「シーケンスプログラムの作
成」段階、「トライアル」段階、「稼動」段階で威力を
発揮する。そのためには、実施例システムは、第19図
に示すように、プログラムの自動生成機能、プログラム
実行中の故障の検出機能、故障が検出された場合の故障
箇所の解析機能、故障からの自動復旧機能、故障状態若
しくはトライアルにおけるシュミレーション機能、自動
生成されたプログラムの最適化機能等が要求される。
【0043】第18図に従って、本実施例システムのプ
ログラム構成をブロック的に説明する。第18図におい
て、マスタテーブル101は、対象の生産ラインの全設
備(アクチュエータ等)に関する、デバイス名称、その
動作の種類、そして、それらのデバイスを第11図〜第
13図のようなシンボルで表記した場合の入力信号,出
力信号の名称をテーブル化したもので、その詳細な一例
が第13図に示される。このマスタテーブルは、各デバ
イスの実際の入出力関係を表現するものであるから、以
下、『実I/Oマップ』と呼ぶ。
【0044】データベース100は、この生産ラインに
使われる全設備(アクチュエータ等のデバイス)に付け
られる名称等を記憶する「名称ライブラリ」108を含
む。このライブラリ108は、操作者によるデバイス名
称の付与に恣意性が入り込むのを排除するために設けら
れている。即ち、ある設備に対し、操作者AがAAと名
称を付け、操作者BがBBと名付ければAAの設備とB
Bの設備とは別物になってしまう。「名称ライブラリ」
108により1つの設備には1つの名称を付することに
より、統一を計る。
【0045】データベース100は、「名称ライブラ
リ」108の他に、「ラダーパターン」107,「ブロ
ックフローマップ」109,「ステップフローマップ」
110,「動作状態ファイル」111を含む。ラダーパ
ターン107は、第14図〜第16図に示したような基
本ラダーパターンを記憶する領域である。各設備はその
設備について前もって割り当てられた基本ラダーパター
ンを有する。
【0046】ブロックフローマップ109は第13図の
ようなマップであって、第4図〜第5図に示された人間
の理解の容易さを意図した動作ブロックフローチャート
を第13図のようにマップ化することにより、コンピユ
ータのデータ処理を可能にしたものである。ステップフ
ローマップ110は第7図に示された動作ステップフロ
ーチャートを第13図のようにマップ化することによ
り、コンピユータのデータ処理を可能にしたものであ
る。
【0047】動作状態ファイル111は、実際にシーケ
ンス制御プログラムが動作した時の各設備の各確認デバ
イスの信号(例えば、第11図のA ,A )の変
化を記録する。第11図は動作状態ファイル111の構
造を示す。このファイルは、信号が変化した時点で変化
した信号について記録される。変化しない信号について
の記録は省かれる。このように、変化があったものにつ
いてだけファイル内に記憶するのは、全ての信号を単位
時間毎に記憶するようにすると、膨大な記憶容量を必要
とするからである。第11図において、ファイル111
の1つのレコードは、「発生時刻」は信号の値が変化し
た時刻を、「信号名」は変化のあった信号の名称を、
「値」は変化後の信号の値を、「故障/正常」は、ファ
イル111に記憶されているデータが、最終的に正常動
作として終わった(=1)ものか、故障として終わった
(=0)ものかを示す。第12図は、第11図に示され
た信号A,B,C,Dについての動作状態ファイルから
それらの信号の計時変化をタイミングチヤートとして復
元したものである。尚、第11図の例では、時刻t
初期設定時刻である。
【0048】第18図のシステムは、上記のデータベー
ス100やマスタテーブル101内の『実I/Oマッ
プ』の他に、「データ生成」102、「自動プログラミ
ング」104、「シュミレーション」105、「故障診
断/復旧」106という4つのサブシステムからなる。
「自動プログラミング」サブシステム104はこれらの
データベース100やマスタテーブル101内の『実I
/Oマップ』を元にして、シーケンス制御のためのラダ
ープログラムを自動生成する。データ生成プログラム1
02は、上記のデータベース100やマスタテーブル1
01内の『実I/Oマップ』を作成し、あるいは修正す
る際の操作者とのインターフェースを司どるためのもの
である。このサブシステム102は主に第17図の「シ
ーケンスプログラム作成」過程において使われる。この
「自動プログラミング」サブシステムは、後述するよう
に、「ブロックフローマップ109」や「ステップフロ
ーマップ110」(これらのマップは、これからラダー
プログラムを自動生成しようとする対象となる生産ライ
ンを記述するものである)と、その生産ラインに使われ
るデバイスの入出力関係を一般的に表現する『実I/O
マップ』とを、結合することによりラダープログラムを
作成する。この結合は、「ブロックフローマップ10
9」や「ステップフローマップ110」に使われている
ブロックの名称やステップの名称やデバイスの名称と、
『実I/Oマップ』に記憶されているデバイスの名称と
をリンクすることによりなされる。
【0049】「シュミレーション」サブシステム105
は自動プログラミング104が生成したラダープログラ
ムをシュミレーションするプログラムを自動生成する。
この生成されたシュミレーションプログラムは、第17
図の「トライアル」段階において主に使われる。「故障
診断/復旧」サブシステム106は、第17図の「トラ
イアル」段階や「稼動」段階において、シュミレーショ
ン結果を診断したり、あるいは実際の稼動段階での故障
を診断するもので、それらの診断結果は主にCRT表示
装置に表示される。この表示装置では、操作者の理解が
容易なように、故障箇所の名称等を上記『実I/Oマッ
プ』のデバイス名称から索引するようになっている。
【0050】このように、本システムにおける中心的な
データは、マスタテーブル101内の『実I/Oマッ
プ』(第24図)であり、この『実I/Oマップ』とデ
ータベース100内のブロックフローマップ109やス
テップフローマップ110と、ラダーパターン107と
が有機的にリンクされて、ラダープログラムやシュミレ
ーションプログラム等が自動的に生成されるようになっ
ている。そこで、以下、本システムのハード構成を説明
し、そのあとで、上述の3つのマップを順に説明する。
【0051】〈ハード構成〉第25図は、第18図で説
明した実施例システムを、ハードウエア構成の観点から
改めて書き直したものである。同図に示すように、ハー
ド構成の観点から見た本システムは、制御対象設備50
(第1図の各種の「設備」に対応)とホストコンピュー
タ60と、ユーザインタフェースとしてのCRTを制御
するCRTパネル制御ユニット53と、前述のマップや
データベースを格納するデータファイル56とからな
る。ホストコンピュータ60は3つのサブシステムを含
み、ラダープログラムの自動生成と前述のマップの生成
とを行う自動プログラミング/データ入力サブシステム
104(102)と、故障診断及び復旧を行う故障診断
/復旧サブシステム106と、シュミレーション制御を
行うシュミレーションサブシステム105とから成る。
これらのユニットは通信回線61で接続され、データフ
ァイル56は高速化を図るためにも半導体メモリまたは
高速ハードディスクドライブが適当である。データファ
イル56は、更に、ラダープログラムを自動作成する上
で必要な生成ルール112も記憶する。
【0052】CRTパネル制御部53は、CRT表示装
置58のほかに、その表示画面のうえに装着されたタッ
チパネル57を有する。本システムでは、自動プログラ
ミングの過程、シュミレーションの過程、故障診断の過
程などで操作者とのインターフェースが必要となるが、
制御ユニット53は、周知のマルチウインド表示制御に
より、複数のウインドをCRT58上に表示し、操作者
は表示されたウインド内の複数のアイテムの中からタッ
チパネル57を使って所望のアイテムを選択する。した
がって、タッチパネル57の代わりに、ポインテイング
デバイスを用いてもよいのは言うまでもない。
【0053】〈プログラム構成〉第26図は自動プログ
ラミング/データ入力サブシステム104(102)に
おけるプログラム構成を示す。尚、第53図〜第56図
は、ラダープログラムの実行及び故障検出及び故障診断
のためのプログラム構成を示す。第26図において、最
下層にはいわゆるオペレーテイングシステム120が格
納され、さらに、マルチウインドシステム121と、日
本語を入力するための日本語フロントエンドプロセサ
(FEP)123と、CRT58,タッチパネル57と
のインターフェースを司どるCRTインターフェースプ
ログラム122と、フローチャート作成するための図形
プロセサ124と、ライブラリを作成するプログラム1
25と、実I/Oマップを作成するプログラム126
と、フローマップを作成するプログラム128と、この
フローマップからラダープログラム(第6図)を作成す
るコンパイラ127と、生成された自動シーケンスラダ
ープログラムや生成ルール112を最適化するための最
適化プログラム129とからなる。
【0054】プログラム123〜129が自動プログラ
ミングサブシステム105(102)を構成する。図形
プロセサ124は、第4図や第7図のフローチャートを
作成するためのプロセサで、フローチャートのシンボル
としてのボックスを書く機能と、そのボックスに名称を
付す機能と、そのボックスの中に文章を入力する機能
と、複数のボックス同士を連結する機能とからなる。こ
の図形プロセサ124が作動している最中は、CRT装
置58の画面上には、データファイル56内の前述のラ
イブラリから入力可能なアイテムが、マルチウインドモ
ードで表示される。ここで、アイテムとは、前述した、
デバイス名称、動作ステツプ名称、動作ブロック名称等
のリテラルデータである。操作者はタッチパネル57に
より、特定のアイテムを選択することにより所望の入力
が可能となる。また、ライブラリにない名称について
は、前述の日本語FEP123の助けにより自由な入力
が可能となる。入力可能なアイテムをウインド表示し、
その中から所望のアイテムを選択するようにしたのは、
名称が恣意的なものとならないようにするためである。
なお、このようなマルチウインド制御システムや、図形
プロセサ124、日本語FEP123はすでに周知であ
り、その詳細な説明は不要である。
【0055】第27図はライブラリに格納されたデータ
の一部を示す。同図に示すように、データは、「デバイ
ス名称」フィールドと「動作名称」フィールドとからな
る。これらのフィールドのデータは上記各種マップを作
成するときに、別々にウインド表示される。ライブラリ
中で、このように2つのフィールドに分割したのは、
「デバイス名称」と「動作名称」とが固有の意味を持つ
ように成っているからである。
【0056】ブロックフローマップ 第22図は、本システムで重要な役割を有するブロック
フローマップであり、このマップは第4図の動作ブロッ
クフローチャートをホストコンピュータ60のフローマ
ップ作成プログラム128により変換したものであり、
データファイル56に格納される。このマップは、同図
に示すように、7つのアイテム、即ち、「ブロック番
号」、「ブロック名称」、「FROM」、「TO」、
「ステップフローマップポインタ」、「装置種別」、
「動作時間」からなる。ブロック名称はそのブロックに
つけられた名称である。ブロックはブロック名称により
ユニークに特定できるが、ブロック番号を付すことによ
り、そのブロックを簡単に特定することができる。第6
図のラダープログラムにおいて、信号名に例えば、「B
4」と付されているのは、このブロック番号を参照する
ことにより得たものである。「FROM」は、そのブロ
ックが、他の上位のどのブロックから連結されているか
を示す。「FROM」の部分に、複数のブロック番号が
記されている場合は、それらのブロックに当該ブロック
が接続されていることを示す。「TO」は、そのブロッ
クが、他の下位のどのブロックに連結されているかを示
す。「TO」の部分に、複数のブロック番号が記されて
いる場合は、それらのブロックに当該ブロックが接続さ
れていることを示す。第22図には、第4図のブロック
フローチャートにおけるブロック間の接続関係が示され
ている。前述したように、図形プロセサ124は、第4
図のフローチャートの各ボックスの連結関係をベクトル
データとして表現するから、そのようなデータから、第
22図のブロックフローマップを作成することは容易で
ある。
【0057】ブロックフローマップの「ステップフロー
マップポインタ」は当該ブロックのステップフローマッ
プ(第23図)がどのメモリ番地に作成されたかを示
す。このブロックフローマップは、自動プログラミング
部55が、第28図のステツプS16において、動作ブ
ロックフローチヤートから作成する。
【0058】実I/Oマップ ステップフローマップを説明する前に、実I/Oマップ
を第24図により説明する。この実I/Oマップは、こ
れから設計しようとする生産ラインに設けられた全ての
設備(アクチュエータ)について所定の入出力関係を定
義したものである。図中、「名称」はそのアクチュエー
タデバイスに対してユニークにつけられた「名前」であ
る。このマップを定義する他のアイテムは、「動作」、
「出力B」、「確認A」、「手動A」の4つである。
「出力B」とは、論理値1の信号が「出力B」で規定さ
れるメモリ番地に書き込まれたときに、当該デバイスが
「動作」に規定された動作を行うためのデータである。
この「出力B」は第11図で説明した出力Bに相当す
る。「確認A」とは、当該デバイスが「動作」に規定さ
れた動作を行ったときに、システムがその動作を確認す
る時に参照するメモリ番地を示す。この「確認A」は第
11図で説明した「確認A」に相当する。「手動A」と
は、手動動作を行うようにプログラムを組むときに、
「手動A」に示されたメモリ番地に論理値1を書き込
む。
【0059】第24図により、実I/Oマップについて
具体的に説明すると、「BF位置決め」なるデバイスが
「出」動作を行うためには、「BA0」番地に1が書き
込まれ、その動作の結果は、「AC0」番地に1が書き
込まれたかを確認することにより確認される。また、
「BF位置決め」なるデバイスが「戻り」動作を行うた
めには、「BA1」番地に1が書き込まれ、その動作の
結果は、「AC1」番地に1が書き込まれたかを確認す
ることにより確認される。「BA0」や「ACo」など
の番地は、いわゆる、メモリマップI/Oの番地に対応
する。これらの番地は、第14図のシーケンサ制御部5
1のバックプレーンのピン番号に対応する。このピンは
該当するアクチュエータに接続されている。この制御部
51は、これらのメモリ番地(「出力B」や「手動
A」)の内容をスキャンしており、これらの番地の内容
が1になれば、対応するアクチュエータを駆動する。そ
して、そのアクチュエータの確認スイッチ(第8図を参
照)が変化すれば、その論理値を、例えば、「AC0
番地に書き込む。この実I/Oマップは、日本語FEP
123や実I/Oマップ作成プログラム126を使って
作成され、各「名称」や「動作」フィールドは検索可能
に構成されている。
【0060】ステップフローマップ 第23図のステツプフローマップは、実際の生産ライン
における動作を記述するマップである。このマップのア
イテムは、第23図に示すように、当該ステップが属す
るブロックの番号を示す「ブロック番号」、「ステップ
番号」、当該ステップの「名称」、そのステップにおけ
る「動作」のタイプを表す「動作」、「FROM」、
「TO」、「出力B」、「確認A」「手動A」、「動作
時間」である。「FROM」、「TO」は、ブロックフ
ローマップの場合と同じように、ステップ間の接続関係
を表す。「動作時間」は、当該ステップが動作するのに
要する公称の時間である。
【0061】動作ステツプフローチヤート(第7図)
は、図形プロセツサ124を用いて作成したものであ
り、そのデータはベクトル化されている。ステツプフロ
ーマップの最初の6つのフィールド、即ち「ブロック番
号」、「ステップ番号」、「名称」、「動作」、「FR
OM」、「TO」のためのデータは、フローマップ作成
プログラム128が第28図のステツプS8において、
前記ベクトル化された動作ステツプフローチヤートか
ら、ブロックフローマップの作成と同じ要領で作成す
る。残りのフィールド、即ち「出力B」、「確認A」
「手動A」のためのデータは、自動プログラミング制御
部55のラダープログラムコンパイラ127がラダープ
ログラムを生成する時(第29図の手順が実行される
時)に、これらのフィールドに、前述の「実I/Oマッ
プ」からのデータを埋め込む。
【0062】〈ユーザインターフェース〉第19図にお
いて説明した実施例システムの機能が有効に機能するた
めには、使いやすいユーザインターフェースが必要であ
る。本システムでは、ユーザインターフェースはCRT
58により行われる。本システムのCRT表示装置58
でのユーザインターフェースは2つの意味を有する。第
1の意味は、ラダーパターンの登録時、動作ブロックフ
ローチヤートや動作ステップフローチヤートの作成時、
「実I/Oマップ」の作成時などにおけるマルチウイン
ドを介したユーザインターフェースである。第2は、操
作者がシステムに操作指令を与えるために、タッチパネ
ル57によるインターフェース(以下、所謂「ボタンア
イコン」によるインターフェースと呼ぶ)である。この
場合、操作者は、CRT58に表示された内容によりシ
ステムからのメッセージを知り、そのメッセージに基づ
いて所定の位置を押すことにより、システムに対して指
令を与える。
【0063】かかるタッチパネルによるユーザインター
フェースは、例えば、第32図に示すように、矩形15
0の左上端座標と右下端座標(x,y )(x
,y )で規定される表示領域に、例えば『O
N』と表示し、矩形151の左上端座標と右下端座標
(x ,y )(x ,y )で規定されるタ
ッチ検出領域の内部の任意の領域で操作者がタッチした
ことを検出したことをもって、所定の『ON』動作を行
なうようにプログラム化するというものである。本シス
テムにおけるタッチパネル57を用いたユーザインター
フェースも基本的にはこの手法を用いているが、その特
徴は、むしろ、CRT58に表示されるボタンアイコン
の表示データや機能が、前述の実I/Oマップから与え
られるという点にある。即ち、実I/Oマップやステツ
プフローマップを介して、シュミレーションプログラム
やCRT表示プログラム等が、他のサブシステム(自動
プログラミングサブシステム55)とプログラムインタ
ーフェースするということである。
【0064】本システムにおける1つのボタンアイコン
は、第33図のようなデータ構造により規定される。同
図中、150,151は第32図で説明した表示領域及
びタッチ検出領域を規定する座標である。第34図に示
すように、本システムのボタンアイコンは3行のデータ
表示フィールドを有する。第33図の152,153,
154はこれら3つのフィールドに表示されるテキスト
を表わす。155のS/Lは、このボタンアイコンが単
に表示(L)を行なうに過ぎないのか、スイッチ機能
(S)を有するのかを区別する情報である。156のM
/Aは、当該ボタンにスイッチ機能が与えられている場
合において、Mであればモメンタリスイッチとして機能
し、Aであればオルタネートスイッチとして機能するこ
とを意味する。157は、このボタンに与えられた機能
の結果を表わす出力が“0”若しくは“1”であるとき
に、このボタンの表示色を規定するフィールドである。
【0065】第35図はCRT装置58の画面に設けら
れた複数のボタンアイコンの配置を示す図である。これ
らのボタンアイコンの各々に、第33図のデータがアタ
ッチされる。第35図中の数字は表示位置を指定する番
号である。ユーザは、第37図に示すように、どのボタ
ンアイコン位置に、どのデバイスを表示させるかを個々
のボタン毎に指定することと、そして、個々のボタン毎
にフィールド157の色指定を行ない、スイッチのモー
ド(L/SとM/A)の指定を行なうだけでよい。第3
7図の表示位置番号は第35図の表示位置指定番号に等
しい。従来では、CRT装置に表示するデータは、ユー
ザが独自に設定し、それは面倒な作業であったが、本シ
ステムでは、ユーザは単に、ボタンの表示位置とデバイ
ス名称、そして色指定などを指定するだけでよい。
【0066】第33図は、実I/Oマップの各デバイス
の名称フィールドのデータ構成の一例を示す。『実I/
Oマップ』の名称フィールドの最初のlバイトは(第3
6図の例では『TL』)は、第34図に示すように、表
示データの第1段目(152)にコピーされ、名称フィ
ールドの次のmバイトは(第36図の例では『位置決
め』)は表示データの第2段目(153)にコピーされ
る。表示データの第3段目(154)は、本システムで
は、実I/Oマップの『確認A』フィールドの値が
“0”であるか“1”であるかに応じて、『動作』フィ
ールドのリテラルデータをもってくるようにしている。
即ち、デバイス名称が位置決めタイプのものであり、そ
のデバイスの『確認A』フィールドの値が“1”であれ
ば、第3段目には『出』を、“0”であれば『戻り』を
表示する。
【0067】第37図のボタンアイコンの指定は操作者
がデータ生成プログラム55を起動することにより行な
われる。このデータ生成プログラム55は、第37図の
ようなデータを操作者が作成したならば、実I/Oマッ
プを参照しながら、個々のボタンについて第33図のよ
うなボタン定義データを作成する。ボタン定義データの
フィールド150乃至154の作成については前述した
通りである。第36図の例のような『TL位置決め』な
るデバイスが選択された場合は、そのデバイスが『出』
状態になったか『戻り』状態になったかがそのアイコン
に表示されるべきである。『出』状態になったか否か
は、そのデバイスの実I/Oマップの『確認A』フィー
ルドに示されるメモリ番地のデータを参照することによ
り判断できる。第33図のフィールド158はその参照
番地を格納する。
【0068】かくして、1つの画面毎の全てのボタンア
イコンについての画面制御データ(第30図)が生成さ
れると、CRTパネル制御部53は、これらの画面制御
データを参照しながらCRT表示装置58上に画面表示
を行なう。もし、『0のときの色指定』が赤で、『1の
ときの色指定』が青ならば、『TL位置決め』デバイス
が『出』状態にあれば、青で表示される。
【0069】以下、第19図に示した順序に従って、本
システムの機能を、「プログラムの自動生成」、「故障
の検出」、「故障箇所の解析」、「シュミレーショ
ン」、「プログラムの最適化」という順で説明する。 〈プログラムの自動生成〉第29図,第30図は、ラダ
ープログラムを作成するコンパイラ(第26図の12
7)の制御手順を示すフローチヤートである。第29図
は、このコンパイラの、ステツプフローマップの「出力
B」、「確認A」「手動A」を作成するための制御手順
を示すフローチヤートであり、第30図がラダープログ
ラム要素を作成するためのフローチヤートである。
【0070】第29図において、ステップS10、ステ
ップS12では、夫々、ブロック番号、ステップ番号を
示すカウンタm,nを“0”に初期化する。ステップS
14では、既に(ステツプS6において)作成されてい
るブロックフローマップをサーチして、カウンタmに対
応する名称を有するブロックを探す。そして、そのブロ
ック名称を有するステップフローマップを捜す。対応す
るマップが無ければ、ステップS30に進んで、カウン
タmをインクリメントして、ステップS32を経てステ
ップS14に戻る。対応するマップがあれば、ステップ
S18で、該当するステップフローマップの中の、ブロ
ックmステップn(BmSn)の「名称」を有するデバ
イスを実I/Oマップ中にサーチする。ステップS2
0,ステップS22,ステップS24においては、サー
チして見つかったデバイスに対応する「出力B」、「確
認A」「手動A」「動作時間」フィールドを、ステップ
フローマップ中にコピーする。ステップS26ではカウ
ンタnをインクリメントする。尚、対応するステツプフ
ローマップが見つかれば、そのマップのポインタアドレ
スをブロックフローマップ(第22図)の「ポインタ」
フィールドに書き込む。
【0071】1つのステップフローマップ中では、デバ
イスが動作される順に並んでいるので、そのステップフ
ローマップの全てのステップについての、「出力B」、
「確認A」「手動A」「動作時間」フィールドを埋めた
ならば、ステップS14に戻って、上述の手順を繰り返
す。第30図は、ラダープログラムを自動生成するプロ
グラム(このプログラムは、自動プログラミング制御部
55のプログラムの一部である)の手順を示す。第30
図のステップS40では、レイヤを示すカウンタLを、
最上位を示す値にセットする。
【0072】ここでレイヤとは、ブロックフローチャー
トにおける層のレベルを示す。第4図の例では、ブロッ
クa,cが第1層を、ブロックbを第 2層、ブロック
dを第3層と、ブロックeを第4層と、ブロックfを第
5層と、ブロックgを第6層と呼ぶ。更に、ブロック
l,m,nを第7層と、ブロックoを第8層と、ブロッ
クiを第9層と、ブロックj,p,qを第10層と、ブ
ロックkを第11層と、ブロックr,sを第12層と呼
ぶ。層に分けた理由は、下位層のブロックが起動される
条件は、そのブロックの上位のブロックの動作終了条件
に規定されるからである。従って、階層のつけ方は、左
側に位置する複数のブロックの中で、並列に起動される
関係にあるブロック同士(例えば、ブロックa,c)を
グループ化してそれらを参照し、そのグループの全ての
ブロックに同じ階層番号をつける。次に、これらのブロ
ックに続く「枝」の中で、並列関係が変化する最下位の
ブロック(例えば、ブロックb)を探索する。並列関係
が発生したところから、並列関係が変化するところまで
の複数のブロックに対して、上から下に向けて順に階層
番号を付していく。
【0073】ステップS40によれば、レイヤカウンタ
Lに対して、このように前もって付された階層番号の最
上位の番号がセットされる。第4図の例であれば、カウ
ンタLには1がセットされる。ステップS42では、カ
ウンタLに示される階層に属する1つのブロックをみつ
ける。このブロックの番号をカウンタmにセットする。
ステップ46では、このブロックの上位のブロックを全
てサーチする。カウンタLが3であれば、その層に属す
るブロックは、第4図の例では、ブロックdであり、こ
のブロックdの上位のブロックはb,cとなる。ステッ
プS48では、見つかったこれらの上位ブロックの動作
終了条件の積を生成する。例えば、あるブロックB
の上位のブロックB が4つの動作ステップからな
り、各々の動作ステップの動作終了を確認するスイッチ
出力を、例えば、A ,A ,A ,A とす
れば、ブロックB はブロックB の全ての動作が
終了していなくてはならないから、ブロックB の起
動条件は、 A *A *A *A となる。
【0074】尚、このブロックB の起動条件の作成
において、ブロックB の各動作ステツプにおいて
は、通常、『出』のためのデバイス動作(例えば、『B
F位置決め出』)と『戻り』のためのデバイス動作(例
えば、『BF位置決め戻り』)等のような相補関係の動
作が存在する。かかる動作に対応する論理は互いに消去
し合うので、上記起動条件に含める必要はない。
【0075】また、並列動作を有するブロックを探索す
る手法は上記手法以外にもあり、例えば、下位のブロッ
クから上位のブロックを探索する手法等がある。ステッ
プS48〜ステップS50では、見つかった全ての上位
ブロックについての動作終了条件の積を生成する。ステ
ップS52では、これをカウンタmが示すブロックB
の起動条件としたラダー要素を生成する。第8図の例
では、ラベル1360のラダー要素がこの起動条件を表
わしている。ここで生成されるラダー要素は、データフ
ァイル56(第23図)に前もってデータベース化され
ているラダーパターンのなかから、条件に合致したもの
を探す。ラダーパターンを探す手法は、本出願人によ
り、特願平1−253991、2−30378、2−3
0379、2−231843、2−231845に詳細
に開示されている。
【0076】ステップS54では、システムに固定のラ
ダー要素(第14図のSRTラダーと、STPラダーで
ある)を生成する。尚、ステップS52において自動生
成されたブロックmの起動条件は冗長な部分を含んでい
る場合が多い。冗長部分は最適化プログラム129によ
り最適化される。この最適化プログラムの詳細は後に説
明される。
【0077】ステップS56〜ステップS62は、1つ
のブロック内の全ての動作ステップに対応するラダー要
素を次々と生成していく手順である。先ず、ステップS
56で、ステップ番号を示すカウンタnをゼロに初期化
し、ステップS58では、動作ステップB
対応するラダー要素を生成する。この場合、番号B
のステップフローマップが参照される。そして、そ
のステップの「出力B」、「確認A」「手動A」のメモ
リ番地が参照され、ラダー要素が作成される。第8図の
例でいえば、「確認A」は「0C6」番地の『RRスラ
イド出』であり、「出力B」は「3041」番地の『B
4St1RRスライド出』である。ステップS60で
は、このステップB が起動されるためのイン
ターロック条件を生成する。動作ステップが起動される
ためには、その前までの動作ステップが終了されている
ことが前提である。この場合、動作ステップB
n− の終了条件が、このブロックB のイ
ンターロック条件となる。第8図の例でいえば、『B4
ステップ1出力』『荷受台前進』『B4動作ON』がイ
ンターロック条件となる。こうして生成されたインター
ロック条件は、次のサイクルで、動作ステップB
n+1 のインターロック条件となる。尚、上述の、ラ
ダー要素の生成は、本出願人による、前述の特願平1−
253991、2−30378、2−30379、2−
231843、2−231845に詳細に開示されてい
る。
【0078】ステップS56〜ステップS60の処理
を、同じブロックB 内の全ての動作ステップに対し
て行なうと、ステツプS66に進む。そして、ステップ
S66,ステップS72で、レイヤ番号Lに属する他の
動作ブロックを探して、そのような動作ブロックが見つ
かったならば、ステップS44に戻り、見つかった動作
ブロックについて、ステップS44〜ステップS62の
処理を繰り返す。
【0079】同じ階層に属するブロックに対する処理を
全て行なったならば、カウンタLをステップS68でイ
ンクリメントしてからステップS70で、上述の処理を
全ての階層に対して行なったかを判断する。全ての階層
のブロックに対して上述の処理を行なったのであれば、
ラダープログラムの生成処理は終了する。
【0080】尚、ステップフローマップにおいても、例
えば、第7図の『FL基準ピンA出』と『FL基準ピン
B出』のように、並列動作を行なう動作ステップが存在
する。動作ステップの並列性は、ステップフローマップ
における「FROM」と「TO」フィールドから判断で
きるのは、動作ブロックにおける並列性の判断と同じで
ある。並列関係にある複数の動作ステップ(例えば、
『FL基準ピンA出』と『FL基準ピンB出』)のイン
ターロック条件は、その上位の動作ステップ(「RRス
ライド出」ステップ)の終了条件が共通になっている。
また、この並列関係にある複数の動作ステップの下位の
動作ステップ(例えば、第7図の『RR基準ピン出』)
の起動条件は、その並列関係にある複数の動作ステップ
の終了条件の積であるのは、動作ブロックにおけるラダ
ープログラム要素の生成と同じである。
【0081】第31図は、第25図乃至第30図で説明
した処理を模式化して示した。第28図によれば、シス
テムの一部変更も、簡単に行なうことができる。即ち、
その変更が、デバイスの変更であれば、実I/Oマップ
において、その変更に係わる部分を「データ生成プログ
ラムにより修正すればよい。この場合、メモリ番地に変
更がない限りは、ラダープログラムの再生成は不要であ
ろう。また、変更がシーケンスの変更であれば、その変
更にかかる動作ブロックフローチヤート(第4図)また
は動作ステップフローチヤート(第7図)を修正し、再
度、第29図,第30図のプログラムをランさせて、ラ
ダープログラムを作成すればよい。この点において、本
システムの特徴は、実I/Oマップ(第22図)に全て
のデバイスに関する情報が集中し、このマップをデバイ
ス名称で索引できることにより、シーケンス手順の変
更、デバイスの変更等は、その変更に係る部分だけの修
正を行なうだけで済む。即ち、システムの変更、修正が
極めて簡単である。
【0082】尚、第1図の生産ラインでは、移載装置や
リニア搬送装置やねじ締めロボット等の設備が存在して
いる。これらの装置では、移載装置における動作は繰返
し動作であり、一方、連続搬送装置では連続動作であ
る。そして、繰り返し動作と連続動作とは、それらを表
現するラダーパターンは異なる。そこで、本システムの
データファイル(第23図)中では、あらかじめ準備し
たラダーパターンを移載装置や連続搬送装置やねじ締め
ロボット毎に異なるライブラリとして分離して記憶して
いる。また、この装置間の相違により、1つの動作ブロ
ックのは、移載装置や連続搬送装置やねじ締めロボット
が混在することはないようにしており、各動作ブロック
のブロックフローマップ(第22図)には、その種別を
表わすデータ(「装置種別」)が設けられている。ラダ
ープログラムを生成するときは、この種別を参照して、
対応するラダーパターンをライブラリから取り出すよう
にしている。これにより、ラダー要素の生成が速くな
る。尚、第38図に、連続搬送におけるラダーパターン
の一例を示す。
【0083】〈プログラム実行/故障監視/故障診断〉
以上、本実施例システムにおけるラダープログラムの自
動生成及びユーザインターフェースについて説明した。
またその過程で、ブロックステップ動作ブロックマップ
及び動作ステップがどういうものかが理解できた。第3
9図,第40図,第41図は、シュミレーションサブシ
ステム105,故障診断/復旧サブシステム106の夫
々のプログラム構成を示す。これらのサブシステム10
5,106は、自動プログラミングサブシステム104
と同じく、マルチウインドシステム121とインターフ
ェースするCRTインターフェースプログラムを夫々有
する。換言すれば、CRT58は、3つのサブシステム
104,105,106により共有される。同図はサブ
システム105,106のプログラム構成も示す。特
に、故障診断/復旧サブシステム106は、マップ制御
プログラム201,動作監視プログラム202,故障診
断解析プログラム203,復旧プログラム204等から
なる。故障診断は、故障の発生したことを特定する故障
検出動作と故障の実際に発生した箇所の特定(解析)動
作とからなる。
【0084】故障発生の検出 第40図,第41図を用いて、シーケンス制御及び監視
及び故障診断のためのプログラム構成について説明す
る。第40図,第41図において、ラダープログラム2
20は、個々の動作ステップにおける個々のアクチュエ
ータの具体的な動作を記述するものである。また、マッ
プ制御プログラム201は、動作ブロックマップ(第2
2図)及び動作ステップマップ(第23図)を参照しな
がらラダープログラム220が実行する設備の動作をモ
ニタする。このマップ制御プログラム201の詳細は第
53図に示さのる。また、動作監視プログラム202
は、マップ制御プログラム201とラダープログラム2
20間とのやり取りを監視しながら、故障の発生を検知
するものであり、その詳細は第54図に示される。さら
に、故障診断プログラム203は、監視プログラム20
2の通知により故障が発生したことを知られされると、
故障診断を行なうものである。この故障の発生したアク
チュエータ(即ち、動作ステップ)は、監視プログラム
202とマップ制御プログラム201とが記録している
後述のステップカウンタの内容を診断プログラム203
が調べることにより知れる。アクチュエータ内の具体的
なデバイス若しくは接点は、診断プログラム203が、
入出力マップ(I/Oマップ:第24図)のデータに基
づいて検出することができる。
【0085】故障診断システムを理解するためには、動
作ブロック毎に設定された前述のSC−REG(CSと
略記する)等の理解が必要である。第42図は、ある動
作ブロックi(BL )に設けられた上記CSレジス
タと、タイムレジスタ(TSSi,TSei)と、ブロ
ックタイムレジスタTBを説明するものである。CS
レジスタCS は、ブロックiで最後に実行終了した
動作ステップの番号を格納する。また、ステップタイム
レジスタTSSiは、最後に実行された、あるいは現在
実行中の動作ステップが開始された時刻を格納する。T
eiは最後に実行が終了した動作ステップがその終了
した時刻が格納される。また、ブロックタイムレジスタ
TB は、当該ブロックが起動可能になるまではゼロ
である。起動可能になると、TB には起動可能にな
った時刻が格納される。
【0086】ステップタイムオーバ 第43図は、個々のブロックに夫々のCSレジスタが設
定されている様子を示している。ある動作ステップの実
行が終了した時点では、 TSxi=TSei−TSSi‥‥‥(1) がその動作ステップを実行するのに要した時間となる。
前述したように、カウンタCS は、ブロックiが最
後に実行終了した動作ステップの番号(実際には、その
動作ステップの次の動作ステップ番号を示す)を記憶す
るから、このCS の内容から、最後に終了した動作
ステップの実行に要した時間TSxiを計算することが
できる。本実施例の故障診断システムでは、このTS
xiと第23図の動作ステップマップに記憶されている
個々の動作ステップの実行に要する標準時間τSiとを
比較することにより、 TSxi−τsi>δ ‥‥‥(2) であれば、その動作ステップの実行に障害(『ステップ
タイムオーバ』)があったと判断する。ここでδ
定数である。
【0087】ステップハングアップ また、本故障診断システムでは、定期的に実行が終了し
ていない動作ステップをスキャンし、現在までの経過時
間T −TSSiが、 T −TSSi>δ ‥‥‥(3) であれば、当該動作ステップはループ若しくはハングア
ップしていると判断する。ここで、T は現在の時刻
であり、また、δ は定数である。δ は、通常、
その生産ラインの動作ステップの実行に要する時間のな
かで最大のものにある許容幅をもたせたものである。か
かる故障が『ステップハングアップ』である。
【0088】ブロックハングアップ 第43図,第44図乃至第48図を用いて『ブロックハ
ングアップ』について説明する。第43図若しくは第5
図に示すように、互いに並行動作を行なう複数のブロッ
クが存在する。かかる複数のブロックをグループと考え
ると、ある1つのグループ(第43図の例では、BL1
が1つのグループを形成する)の全ステップ動作が終了
して、そのグループに続く他のグループ(第43図の例
では、BL2,BL3,BL4からなるGR1)が実行
されるまでの時間経過を監視する必要がある。前述のブ
ロックタイムレジスタTB は、上記ブロックグルー
プが起動されるまでの経過時間である。各グループにつ
いて、測定動作時間を基準時間と比較しつつモニタする
ことにより、各グループ毎の異常、換言すれば、ブロッ
クから別のブロック間に遷移する過程で発生した故障を
診断することができるようになっている。このような故
障が『ブロックハングアップ』である。本実施例システ
ムにおいては、ブロックハングアップが発生した場合
は、更に、その原因となった動作ステップを特定するこ
とまでを行なう。
【0089】『ブロックハングアップ』の原因となった
動作ステップを特定する手法について、第44図乃至第
48図を用いて説明する。これらの図は、『ブロックハ
ングアップ』の説明を容易にするために、4つの動作ブ
ロックからなるある生産ラインの動作ブロックマップを
簡略化したものである。第44図の生産ラインは、簡単
に4つの動作ブロックから構成される。これらの動作ブ
ロックに対する動作ブロックマップは、簡略化して第4
5図のように示される。
【0090】第45図では、ブロック1からブロック2
が起動されるまでに要する時間をΓ 12、ブロック1か
らブロック3が起動されるまでに要する時間をΓ13
と表わされている。これらの遷移時間Γは前もって設定
可能だからである。例えば、ブロック4は、並行したブ
ロック2,3の終了により起動される。第43図に関連
して説明したように、ブロックタイムレジスタTB
は、当該ブロックが起動可能になるまではゼロである。
そして、起動可能になると、その時刻が格納される。従
って、レジスタTB の値がゼロでなく、現在までの
経過時間が上記Γよりも十分に大きいときは、ブロック
ハングアップが起こっているものと判断できる。従っ
て、ブロック2,3の終了から、時間Γ24,Γ34
経過してもブロック4が起動されない場合は、ブロック
ハングアップとして故障認識される。
【0091】ブロック4が起動されないためにブロック
ハングアップが検出されたときは、その原因となった動
作ステップはブロック2,3のいずれかにある筈であ
る。第46図は動作ブロック2の動作ステップマップ
を、第47図はブロック3の動作ステップマップを示
す。第46図によれば、ブロック2には4つの動作ステ
ップが設定され、各々のステップにおける出力は、Y
,Y ,…Y であり、それらの出力アクチュエ
ータの確認スイツチはX ,X ,…X であ
る。また、第47図によれば、ブロック3には3つの動
作ステップが設定され、各々のステップにおける出力
は、Y ,Y ,Y であり、それらの出力アク
チュエータの確認スイツチはX ,X ,X
ある。上記確認スイツチX 乃至X の状態は、ブ
ロック2,3を終了する時点では、ブロック毎にユニー
クであり、且つ、事前に知り得るものである。第48図
の起動条件マップは、第44図の例に示された4つの動
作ブロックの夫々が起動されるための条件、即ち、動作
確認スイツチの状態論理を示すものである。図中、ブロ
ック4について言えば、ブロック2では出力Y 乃至
がオンされて、確認スイツチX 乃至X
でがオンされている。また、ブロック3では出力Y
至Y がオンされて、確認スイツチX 乃至X
までがオンされている。従って、ブロック4が正常に起
動されるときは、 X *X * … *X でなくてはならない。ブロック2,3はブロック1の終
了によって起動される。従って、ブロック2,ブロック
3の起動条件はブロック1の全動作ステップの確認スイ
ツチの状態の論理積となる。尚、第48図において、
〈N〉は、確認スイツチが出力Yが“出”状態にあるこ
とを確認する状態にあることを意味し、〈I〉は、確認
スイツチが出力Yが“戻り”状態にあることを確認する
状態にあることを意味する。
【0092】このように、各動作ブロックの起動条件
に、そのブロックの前段のブロックの全動作ステップの
出力を確認するデバイスの状態を論理積として組み合せ
たものをプログラム化すれば、当該動作ブロックの起動
は、前段の動作ブロックの全動作ステップの正常な終了
を確認しない限り行なわれない。換言すれば、起動条件
が満足されなければ、前述のブロックハングアップが起
こって、故障と正しく検知されるのである。しかも、故
障が検知されたブロックが認識されれば、起動条件マッ
プと、実際の確認スイツチの状態とを比較すれば、どの
スイツチが異常であるか、そして、入出力マップ(第2
4図)と動作ステップマップ(第23図)とを参照する
ことにより、どの動作ステップのどの出力アクチュエー
タがおかしかったかを速やかに知ることができる。
【0093】生産ラインにおけるシーケンス制御には、
経験上、動作ステップのアクチュエータが、「出」状態
でもなく、「戻」状態でもない状態で停止したり、ある
いは、「出」状態と「戻」状態の両方を示したりする場
合がある。この原因の1つは、重量の重いアクチュエー
タがバウンドにより「出」状態でもなく、「戻」状態で
もない「中途半端」な状態に陥ってしまうからである。
そして、従来では、このような状態は、見掛け上は、シ
ーケンス制御は正常に進んでいくから、その不良確認ス
イツチの状態によって起動される(別の動作ブロック
の)筈の動作ステップが何時までも起動されないという
理由で故障と認識されるに至るものの、しかしながら、
その停止点は、実際に障害が発生した動作ステップとは
かけ離れた動作ステップである可能性が高い。
【0094】しかしながら、本実施例のブロックハング
アップ検知の手法によれば、前述したように、各動作ブ
ロックの起動条件に、第48図のような、前段ブロック
の全確認デバイスのあるべき論理状態の論理積を設定し
ているので、ある1つの動作ブロックの動作ステップで
上述の中途半端なスイツチ状態に陥って、その動作ステ
ップで故障と認識できなくても、その動作ブロックが終
了して、次に続く動作ブロックが起動される際に、ブロ
ックハングアップとして確認できる。即ち、故障のあっ
た動作ステップと故障認識が行なわれた動作ステップと
が時間的にも空間的に余り離れたものとはならず、故障
診断が正確になるばかりでなく、復旧もより速やかにな
るという効果がある。
【0095】〈故障箇所の解析〉上述したように、ステ
ップタイムオーバ、ステップハングアップ、ブロックハ
ングアップ等により故障が検知されると、故障ステップ
の特定により、動作ステップマップ(第23図)から障
害のあるアクチュエータ(設備)が特定される。第23
図に示すように、1つの動作ステップは設備の1つのア
クチュエータに対応するからである。ここで、故障アク
チュエータから、このアクチュエータがどのような状態
で停止しているか、即ち、このアクチュエータの動作を
定義するLS(出と戻りの2つリミツトスイツチLS)
がどのような状態になっているかを知る必要がある。
【0096】第24図の入出力マップ及び第23図の動
作ステップマップはこのLSの状態を知るのに使われ
る。第23図の動作ステップマップにおいては、アクチ
ュエータ識別番号欄が設けられている。この識別番号
は、それに対応するステップ(例えば、B
で使われるアクチュエータを識別する番号(例えば、A
)である。この識別番号は入出力マップの個々のア
イテムの番号である。第24図の入出力マップは、個々
のアクチュエータの動作タイプや接点名を示すだけでは
なく、出状態を示す接点と戻り状態を示す接点との関係
をも記述する。アクチュエータは往復動作を行なうか
ら、1つのアクチュエータには必ず、出状態と戻り状態
とがペアで存在する。第24図の入出力マップにおい
て、「対応関係」は、そのペア関係を記述している。例
えば、BFというアクチュエータ(このアクチュエータ
は番号A02で識別される)の対応関係の欄には“A0
3”と記されている。即ち、BFアクチュエータが出状
態にあるときを番号A02により特定し、この出状態に
対応する戻り状態は、番号A03にあるということを示
している。
【0097】従って、故障診断システムは、故障ブロッ
ク番号と故障動作ステップ番号とを得たならば、動作ス
テップマップから故障したアクチュエータの識別番号を
知り、この番号から、この故障アクチュエータには、ど
のようなLSが設定されているかを知ることができる。
そして、どのLSが設けられているかを知ることができ
れば、そのLSの状態を読出して、例えば、表示するこ
と等により、操作者に故障状態を伝えることができる。
【0098】第24図の入出力マップは、実際の動作シ
ーケンスを記述する動作ステップマップ(第23図)
や、ラダープログラム(例えば、第49図)とは独立し
ている。即ち、生産ラインが変更されて、動作ステップ
マップ(第23図)やラダープログラム(第49図)が
修正されても、入出力マップを修正する必要はない。即
ち、生産ラインの変更毎に故障診断プログラムを修正す
る労力から解放される。
【0099】尚、上記標準実行時間τは、例えば、正常
作動時における所定回数のサイクルについての測定動作
時間の平均値{TSxi}(ここで、記号{ }は平均
を表わすものとする)と標準偏差値σとで規定される、
例えば、 τ={TSxi}+3σ ‥‥‥(4) と定義することが好ましい。より好ましくはサイクル毎
にデータτが更新される方がよい。何故なら、アクチュ
エータの動作特性は経年変化するからである。また、ブ
ロックハングアップの検出に用いる時間Γ(第22図の
動作ブロックマップを参照)についても、経年変化を考
慮して、実際に要した時間に基づいて更新することが望
ましい。
【0100】〈故障箇所の解析方法の改良〉ある動作ス
テツプや動作ブロックで、ステップタイムオーバ,ステ
ップタイムアウトやブロックタイムアウトが検出された
場合に、実際に故障が発生した箇所を特定する必要があ
る。ある設備のアクチュエータが故障しても、システム
はそのアクチュエータの確認スイツチの状態を読み出し
たときにのみ故障を認知し得る。換言すれば、上述の動
作ステツプについての、ステップタイムオーバ,ステッ
プタイムアウトが検出されるのは、故障したアクチュエ
ータの確認スイツチの出力を用いているラダーステップ
でタイムアウトやタイムオーバが検出されたときのみで
ある。本システムのラダープログラムの生成方法は、生
産ラインにおける動作を複数の動作ブロックに、個々の
動作ブロックにおける動作を更に複数の動作ステツプの
動作に分割し、個々の動作ステツプの動作における各ア
クチュエータの動作を実I/Oマップから引出してラダ
ープログラムを完成していた。上述の故障箇所の検出方
法によれば、個々の動作ステツプ段階で故障を検出でき
るのであるが、1つの動作ステツプが多くのラダープロ
グラム要素からなる場合(実際には、動作ステツプの動
作が1つや2つのラダープログラム要素からできあがっ
ていることは少ない)には、どのラダープログラム要素
で故障が発生したかを解析することは困難である。本出
願人の従来のシステムでは、故障箇所を解析するとき
は、多数の故障と思われる候補の信号から実際の故障箇
所の解析を行なうのに、人間が関与せざるを得ず、その
ために、故障箇所の解析は時間のかかるものであった。
【0101】更に、工程を動作ブロックと動作ステツプ
に分解して記述する手法では、動作ステツプの並列動作
は原則として行なわれないが、プログラムの改良過程
で、複数の動作ステツプを並列して処理ことも行なわれ
得る。このようなラダープログラム要素が1つの動作ス
テツプ内で並列して実行される場合にも、前述の手法で
故障を動作ステツプで検出しても、故障原因のデバイス
(リミツトスイツチ)を特定することはできない。
【0102】そこで、本実施例の故障診断システム10
6は、故障原因の探索(候補の絞り込み)にバイナリ・
ツリー・サーチ(二分木探索)法を採用する。そして、
本実施例の二分木探索法は次のような特徴を有する。即
ち、今回の故障を探索し終えたときに、次回の探索を効
率化するために、今回の探索結果に重み付けを行ない、
次回の探索はその重みに応じて探索ルートを選択するの
である。
【0103】バイナリ・ツリー・サーチ法の概略 バイナリツリーサーチを説明するために、第49図に、
1つの動作ブロック内にS からS までの4つの
動作ステツプからなる生産工程プログラムの例を示す。
第49図中、表記Yはアクチュエータに対する出力信号
を示し、Mはその出力の確認信号を示すものとする。ア
クチュエータY の動作確認を示す信号は第49図の
例ではM となる。更に、Xはその動作ステツプの起
動を規制する各種スイツチの信号を意味する。
【0104】ところで動作ブロック単位で故障検出を行
なう場合、換言すれば、ブロックハングアップのみを検
出するようにした場合に、第49図のS が動作ブロ
ックの最終動作ステツプであるならば、例えば、第49
図のプログラムで、スイツチX が故障した場合で
も、Y が出力されないために、確認スイツチM
故障と検知される。即ち、スイツチX が故障である
ことを解析するためには、スイツチM が正常ではな
いと分っても更に上流にさかのぼって故障解析を行なわ
ねばならない。一方、X のようなスイツチ信号はラ
ダープログラムで生成された信号ではなく、外部から入
力された信号であるから、X が故障と解析されれ
ば、それ以上さかのぼる必要はない。このように見掛け
上の故障部位と、真の故障部位とを故障解析において切
り分けるために、本システムでは、『内部信号』と『外
部信号』という概念を導入する。ここで、ラダープログ
ラム内部で生成された信号そのもの、または、ラダープ
ログラムでオンされるアクチュエータ(例えば第49図
のY )の動作確認信号(例えば、M )は『内部
信号』である。そして、ラダープログラム外から入力さ
れる信号は『外部信号』である。
【0105】第51図は、第49図のラダープログラム
を二分木(バイナリ・ツリー)で表現した図である。第
51図中、より左側に位置したある信号(例えば、M
)は、これにシリーズに接続している右側に位置した
信号(例えば、X ,M)とAND(積)で結ばれ
ている。また、分岐点がある場合に、その分岐点はOR
(和)関係を示し、例えばM (アクチュエータY
の確認スイツチ信号)は(X *M *…)と
(X *X )の両者と積(AND)を作る。第5
1図で、X ,X 〜X13は全て『外部信号』で
あり、M ,M 〜M は『内部信号』である。
【0106】本システムでは、上記3つの故障(ステッ
プハングアップ,ステップタイムアウト,ブロックハン
グアップ)のいずれかが検出されると、その時点の全て
の確認スイツチ及びインターロツク条件を形成する信号
の状態(動作状態ファイル111)を記録するようにし
ている。そして、例えば第49図のラダープログラムの
動作ステツプS で例えばステップタイムアウトが検
出された場合は、故障診断プログラムは、第49図のラ
ダープログラムから第51図の如き二分木チャートを作
成し、そのチャートに示されたルートに沿って各確認ス
イツチの出力信号やインターロツク条件を構成する信号
をチェックしていく。この探索の過程にたいして二分木
探索の手法が使われる。
【0107】二分木チャートを作成することは簡単であ
る。前述したように、本システムにより生成されたラダ
ープログラムは、全て登録された信号名により特定され
る。従って、そのラダープログラムがコンパイルされた
時点で、そのプログラム中で使われている全ての信号の
各々がどの動作ステツプで使われているかを示す第50
図のような所謂「クロスリファレンスリスト」が作成さ
れる。このリストは、第50図に示すように、信号名の
アイウエオ順(または、アルファベット順)に並べられ
ている。このリストの各要素は、参照される信号名と、
その信号が前記の『内部信号』であるか『外部信号』で
あるかの種別と、その信号が出力される動作ステツプ番
号(『動作ステツプ(出力)』)と、その信号が確認信
号として使われる動作ステツプ番号(『動作ステツプ
(入力)』)とからなる。勿論、参照信号が複数の動作
ステツプで参照されれば、リスト中には複数の『動作ス
テツプ(入力)』フィールドが設定される。
【0108】故障が検出され、故障が検出された動作ス
テツプから派生する二分木ツリーを作成するためには、
故障の検出された動作ステツプ番号が分ればよい。そし
て、その動作ステツプのアクチュエータの出力信号を動
作ステツプマップ(第23図)から知り、この出力信号
がアクテイブになるための条件を動作ステツプマップか
ら調べ、この条件中に現われる全ての動作確認信号及び
インターロツク条件中の信号を前記クロスリファレンス
リスト中に探索する。このようにして、次々に、現われ
る信号をクロスリファレンスリスト中に探し、その信号
を出力する動作ステツプを探索していけば、二分木ツリ
ーが作成される。
【0109】二分木探索法の理論そのものは、情報処理
の分野では周知である。探索方法の概略は、第51図の
二分木ツリーの下流から上流に向かって、そのルートに
現われた信号を動作状態ファイル111に探し、探し出
した信号の値を読み出す。その読み出された信号が条件
を満たしていれば、更に上流の信号をツリーに沿って探
していく。ツリー若しくは動作ステツプマップが当該信
号が“1”(あるいは、“0”)であるべきことを示し
ているときに、読み出された信号が“0”(または
“1”)であるときに、条件を満たしていないと判断さ
れる。上流に向かって探索する過程で、分岐点に至れば
(例えば、第51図でX13の上流)、常に例えば右側
の枝に分岐するというルールを設定しておく。1つの枝
の終端に至れば、元のルートを戻って先の分岐点(X
13)に戻り、先にたどらなかった他の分岐(X10
上流)をたどっていく。
【0110】かくして、第51図のツリーをたどってい
けば、いつかは実際の故障原因となった確認スイツチに
到達する。かかる二分木探索の手法は、故障がブロック
ハングアップとして検出されたときに特に有効である。
何故なら、本実施例システムでは、ある設備のアクチュ
エータが故障しても、そのアクチュエータの確認信号を
使用する動作ステツプにおいて、ステップタイムアウト
若しくはステップタイムオーバとして検出されるからで
ある。ところが、ブロックハングアップの場合は、ハン
グアップが検出されたこと自体が、故障がどのブロック
のどの動作ステツプで発生したかを特定しないからであ
る。従って、ブロックハングアップが発生した場合に
は、第48図に関連して説明したブロック起動条件マッ
プから二分木ツリーを作成してサーチを行なえばよい。
【0111】しかし、この二分木探索法は全てのノード
(信号がツリー上で形成するノード)を探索するために
時間がかかる。それは、 :探索が分岐点に至った場合に、どちらの分岐を選択
してよいか分らない。従来では、分岐点でどちらの分岐
を選ぶかは、前述したように右か左の分岐を画一的に選
択するか、あるいはオペレータがどちらかの分岐を選択
指示していたために、効率の悪いものであった。 :内部信号(例えば、M )が故障でないというこ
とを示す場合は、その内部信号を生成した元の信号 X /*(X *X +X *X ) を探索する必要はないのに、単なる二分木探索では、全
ての信号をチェックしている。そこで、本実施例では、 :の問題を解消するために、過去探索されたルート
のうち、実際に故障デバイスが見付かったルートに、故
障デバイスがみつかった毎に“1”の累積的に重み値
(次回の探索時の優先準位)を与えるようにしている。
ある1つのルートで4回故障デバイスが見付かれば、そ
のルートには値“4”が与えられる。値が大きなルート
は故障が過去多く発生したデバイスが存在するルートで
あるから、次回に故障が発生したときは、重み値が大き
なルートに沿って故障デバイスを探索すれば故障デバイ
スの見付かる確率は高まる。 :の問題を解消するために、信号をチェックする毎
に、それが内部信号か外部信号かをチェックして、探索
の遡行を継続するか否かを判断している。
【0112】第D図は、第51図の二分木ツリーのラダ
ープログラムにおいて、過去に故障が、デバイスX
で4回、X で2回発見されたと場合に、各ルートに
どのような重み付けがなされるかを示したものである。
同図から明らかなように、 X13→X10→M →分岐点 には重み“6”が与えられ、 分岐点→X →X には重み“4”が与えられ、 分岐点→X →M →X →M →X/→分
岐点→X には重み“2”が与えられ、 分岐点→X11→X12 には重み“0”が与えられ、 分岐点→X →X には重み“0”が与えられる。このような重みが与えら
れた状態で、次に故障が起こったときには、分岐点で
は、重み値の大きな方の分岐を選び、具体的には、 X13→X10→M →X →X の順で探索が行なわれる。換言すれば、過去故障の起こ
ったところは再度発生する確率が高いので、その箇所を
優先的に解析の対象とすることで故障箇所の発見を効率
的にする。尚、上記の、内部信号か外部信号かの判断
に係る制御は第57図,第58図に関連して後に詳細に
説明する。
【0113】故障監視の制御手順 次に、第53図乃至第56図に従って本実施例システム
における、ラダープログラムの実行/故障監視の制御動
作を説明する。第53図は、動作ブロックマップ,動作
ステップマップに従って、当該生産ラインの各アクチュ
エータをラダープログラム220の動作を監視するマッ
プ制御プログラム201の制御手順である。このプログ
ラムが起動されるとステップS82で、初期化を行な
い、起動可能な最初のブロックグループを検出する。こ
のグループには1つのブロックを含む場合もあれば複数
のブロックを含む場合もある。
【0114】ステップS84では、新たに起動可能とさ
れたブロックの存在を調べる。このステップS84の目
的は、主に、ある1つの動作ブロックの全ステップ動作
が終了して、この動作ブロックに続く実行可能な動作ブ
ロックが存在するかを調べるものである。このようなブ
ロックが存在すれば(ステップS82から起動された場
合は、実行可能な動作ブロックは存在する筈である)、
ステップS86では、そのブロック番号を検出する。か
かるブロック番号をiとし、この番号は、当然、複数の
番号を含み得るものである。グループで実行可能な場合
があるからである。
【0115】ステップS88では、そのような動作ブロ
ックの動作ステップマップを読み込み、ステップS90
でその動作ブロックを実行中とマークする。ステップS
92では、実行可能な動作ステップがあるかを調べる。
動作ステップが実行可能となるのは、CSレジスタに示
されている動作ステップの動作が終了しているときであ
り、監視プログラム202のステップS136(第54
図)で行なわれる。実行可能な動作ステップが当該動作
ブロックにあれば、ステップS110で、当該動作ブロ
ックiのタイマレジスタTSSiに現在時刻を開始時刻
として書込む。ステップS110の動作を実行可能な動
作ステップがある限り行なう。実際には、グループ内に
複数の動作ブロックが存在すれば、その動作ブロックの
各々で1つの動作ステップが実行されることになろう。
【0116】実行可能な動作ステップが全て起動される
と、いずれかの動作ステップの動作が終了するまでは、
ステップS92の判断はNOとなって、ステップS94
に進み、いずれかの動作ステップの実行終了を待つ。い
ずれかの動作ステップの実行が終了したと終了信号がラ
ダープログラム側からシーケンス制御プログラムに伝え
られたら、ステップS94からステップS96に進む。
ここで、終了した動作ブロック番号iと動作ステップ番
号を読む。このiにより終了した動作ステップを含む動
作ブロックが特定できる。ステップS98では、終了時
刻を当該動作ブロックiのタイマレジスタTSeiに書
込み、ステップS99で、当該動作ステツプが終了した
時刻、その動作ステツプに関連する確認スイツチの状態
を動作状態ファイル111に書き込む。終了した動作ス
テツプの状態を書き込むのは、第20図,第21図に関
連して説明したように、後に一連の動作ステツプの動作
を時間を追って復元するためである。ステップS100
では、次に実行すべき動作ステップを示すためにCSレ
ジスタを1つインクリメントする。このような動作を行
なっていけば、アクチュエータ動作を終了した動作ステ
ップから順に、対応するブロックのCSレジスタが更新
されると共にTSeiも更新されていく。
【0117】一方、監視プログラム202は、第54図
のステップS120において、ラダープログラム220
からのステップ終了信号を監視している。いずれかのラ
ダー要素でアクチュエータ動作終了があったときは、ス
テップS122に進み、ラダープログラム側から知らさ
れた当該ブロック番号i、ステップ番号を読取る。そし
て、ステップS124で、このブロック番号iからその
ブロックのタイマ値TSSiとTSei並びに、動作ス
テップマップから当該動作ステップの実行予測時間τを
読取り、(1)式に従って経過時間TSxiを演算す
る。そしてステップS46で、実行に要した時間TS
xiが異常に長かったかを判断する。
【0118】ステップS126の判断がOKであれば、
ステップS134に進んで、当該動作ブロックのタイマ
レジスタの内容をクリアし、ステップS136では、現
在レジスタCS に示されている動作ステップを実行
可能とマークする。このCS で示される動作ステッ
プは、ステップS100で更新したように、終了した次
の動作ステップである。ある動作ブロックの動作ステッ
プが実行可能とマークされると、シーケンス制御プログ
ラムの第53図のステップS92でYESと判断されて
次の動作ステップの実行が行なわれていく。
【0119】このように次々と動作ステップが実行され
ると、ある動作ブロックについて、ステップS102に
おいて、CSレジスタの内容が最終ステップ番号を超え
るとき、即ち、その動作ブロックの全処理を終了したと
なるときがくる。このときはステップS104で、当該
ブロックを終了とマークする。そして、ステップS10
5で、全ての設備の確認スイツチの状態を、動作状態フ
ァイル111に当該動作ブロックの終了時刻と共に書き
込む。この全ての設備の確認スイツチの状態データは、
後述するように、シュミレーションを行なう時に利用さ
れる。
【0120】ステップS106では、現在のブロックの
次に起動されるべきブロックのためのタイマTBij
現在時刻を書込む。ここで、TBijは、ブロックiが
終了して、このブロックiの次に起動されるべきブロッ
クjが存在することを明示するためのタイマであり、第
45図のΓ12等に対応する。尚、タイムレジスタTB
は次に起動されるべき動作ブロックの最初の動作ステッ
プが起動されれば、ステップS108でクリアされる。
ステップS106からステップS84に戻り、新たに実
行可能な動作ブロックを探す。例えば、第5図の例で、
B13の処理が終了してステップS84に戻ったとき
に、まだブロックB17の処理が終了していなければ、
ブロックB13は実行可能とマークされない。
【0121】次に、第54図のステップS126に戻っ
て、ステップタイムオーバ故障の発見の手順について説
明する。ステップS126で、TSxi−τ>δ
判断されたときは、当該動作ステップの実行にかかった
時間が異常に長かったのであるから、ステップS128
で、その動作ステップの属する動作ブロックを故障とマ
ークし、ステップS130で、予想時間τの更新を行な
う。この更新処理は第56図にその処理手順の詳細が示
されている。即ち、動作ステップの処理に実際に要した
時間Txiと予想時間τとの差が小さくて、即ち、 Txi−τ/τ<ε (ここで、ε《1) であって、要した時間Txiがτよりも若干長かった場
合には、それは設備の経年変化によるものと判断して、
ステップS192において、過去のTxiと今回のT
xiとから、次回のためのτを計算して更新する。この
ような更新により経年変化をも考慮した正確な故障検知
が可能となる。
【0122】第54図の制御手順において、ステップS
132で診断プログラム(第55図)を起動してから、
ステップS120に戻る。ステップS120に戻るの
は、他の動作ブロックの動作ステップにおいても故障を
検出するためである。また、故障検出を行なってシーケ
ンス制御プログラムの実行を停止しないのは、1つの動
作ブロックを停止しても、並行動作すべき動作ブロック
があるので、その動作ブロックの動作を停止してはなら
ないからである。他の動作ブロックを停止しなくてもよ
いのは、そもそも、動作ブロックが他の動作ブロックと
独立して動作することを条件に定義されたものだからで
ある。
【0123】ステップS138以下は、ブロックハング
アップ若しくはステップハングアップを検出する手順で
ある。ある動作ステップでラダープログラムがハングア
ップした場合の対処を説明する。かかる場合は終了信号
は発生されない。従って、ステップS120からステッ
プS138に進む。ステップS138では一定時間の経
過を見る。これは、前回ステップS138に来てから現
在時点(時刻T )までの経過時間が一定の値を超え
たかを見るものであり、換言すれば、ブロックハングア
ップ若しくはステップハングアップの有無ははこの一定
時間毎にチェックされるということである。ステップS
140では、実行中とマークされている動作ステップを
サーチする。これは、実行中とマークされている動作ブ
ロックの各CSレジスタの内容が特定の動作ステップを
指し、且つ、TSSiに開始時間が書込まれていなが
ら、TSeiが未だ更新されていないものである。ステ
ップS142では、現在までの経過時間T −TS
Siを計算し、ステップS144では、(3)式に従っ
て、 T −TSSi>δ ‥‥‥(3) を判断する。判断がYESであれば、ステップS64に
進み当該ブロックをステップハングアップ故障とマーク
する。
【0124】ステップS140で、実行中の動作ステッ
プがないと判断された場合について説明する。この場合
は、ステップS150では、ブロックタイムレジスタT
の値がゼロでないブロックjをサーチする。ステ
ップS106に関連して前述したように、TBijがゼ
ロでないものは、ブロックiが終了してもそれに続くブ
ロックjが未だ起動されていないことを示す。ステップ
S152では、そのようなブロックにおける動作ステッ
プが未起動のままの経過時間と前記予想時間Γ ijとの
差、 (T −TBij)−Γij を計算する。そして、その差が定数δ よりも大きい
ならば、ステップS156でブロックハングアップと判
断する。ステップS158では、故障診断プログラム
(第55図)を起動する。
【0125】第55図に従って、故障診断プログラム2
03について説明する。この故障診断プログラムは、故
障がブロックハングアップであるか、あるいは、ステッ
プタイムオーバ,ステップハングアップであるかによ
り、処理を若干異にする。ステップタイムオーバ,ステ
ップハングアップが検出されれば、故障動作ステップが
直接的に知ることができるのに対し、ブロックハングア
ップの場合は、故障動作ステップを遡って追跡する必要
があるからである。
【0126】ステップタイムオーバ,ステップハングア
ップ故障の場合は、ステップS162において、故障と
マークされたブロックをサーチする。このマークはステ
ップS128しくはステップS148でなされたもので
ある。ステップS164では、検出されたブロックのC
Sレジスタの内容を読み、故障が検出された動作ステッ
プを特定する。ステップS166では、動作ステップマ
ップから故障したアクチュエータの識別番号を知る。ス
テップS168では、この識別番号から入出力マップ
(第24図)をサーチし、ステップS170で、この識
別番号を有するアクチュエータの出と戻りのLSの番号
を知る。ステップS170では、これら知り得た、故障
の起こった動作ブロック番号,動作ステップ番号,アク
チュエータ番号,LS番号を表示して、操作者に対処を
うながす。
【0127】ステップS160でブロックハングアップ
が検出された場合について説明する。この場合は、ステ
ップS174で、ブロックハングアップが検出されたブ
ロック番号に対応する起動条件マップ(第48図)を読
み込む。ステップS176では、マップに書かれている
確認スイツチの論理状態と、それらの確認スイツチの実
際状態とを比較して不一致の確認スイツチを探す。この
不一致スイツチデバイスの特定がなされれば、次に、ス
テップS178で、ハングアップが検出されたブロック
の親ブロックをブロックマップ(第22図)からサーチ
する。ステップS180では、検出された親ブロックの
動作ステップマップ(第23図)から、上記不一致スイ
ツチを使用している動作ステップを特定、これからステ
ップS182で、この動作ステップのアクチュエータ番
号やL/S番号を特定してステップS184に進む。ス
テップS184では、これらを表示する。以上のように
してサーチされた故障箇所が、デイスプレイ装置8のモ
ニタ画面上で所定の色で強調表示される。そして、作業
者による故障箇所の復旧作業が行なわれる。
【0128】以上説明した『ステップタイムオーバ』や
『ステップハングアップ』の検出は、基本的には、ステ
ップラダープログラム203とは独立したプログラムに
より行なわれている。このことは次のような効果を奏す
る。即ち、ステップラダープログラムには、上記故障検
出するための所謂、「トラツプ回路」を設ける必要がな
くなるということである。第46図において、M
は、インターロツク条件ILCが満足されたことによる
出力であり、M が出力されると、アクチュエータ出
力Yが出力される。従来では、第46図に示すように、
スイツチM が閉じたら起動されるタイマ回路Tを設
け、このタイマがタイムアウトする前に、出力Yを確認
するスイツチXLSが開かなければ故障(ALMオン)
とするものであった。しかし、本実施例によれば、この
ようなタイマ回路は不要になり、第45図のように、本
来の生産シーケンス制御に必要なステップラダープログ
ラムのみを作成すればよいことになる。
【0129】故障解析のための制御手順 以上が故障診断(故障発生の検出、故障箇所の簡易な診
断)のための制御手順である。次に、故障解析の制御手
順について第58図,第59図,第60図に基づいて説
明する。第58図のプログラムは、第25図のCRT5
8の所定の起動アイコン(例えば、『故障解析アイコ
ン』)を指定することにより起動される。ステップS2
00では、故障診断システム106からフェールした動
作ステツプB の番号を教えてもらう。ステッ
プS202では、B から始まる第51図に示
された如き二分木ツリーを第50図のクロスリファレン
ステーブルに基づいて作成する。動作ステツプB
が複数の出力ラダー要素を有すれば、個々の出力に
対して第51図の二分木ツリーを作成する。本実施例で
は、ツリーの個々の信号は、ノード番号Nで特定され
る。ステップS204ではノード番号Nを保持するカウ
ンタNを“0”に初期化する。第51図の例では、N=
0のノードはX13である。ステップS206では、カ
ウンタNが指定する信号のデータを動作状態ファイル1
11から読み出す。そして、ステップS208でこのデ
ータが正しいかを調べる。
【0130】先ず、故障が『外部信号』X13において
発生した場合を例にして説明する。前述したようにフェ
ール原因が外部信号である場合には、そのノードよりも
更に上流にさかのぼる必要はない。即ち、制御はステッ
プS208→ステップS226→ステップS234に進
み、ステップS234で、当該ノードの番号若しくは信
号をレジスタFDNに格納する。ここで、FDNはフェ
ールと判定された信号名若しくはノード番号を記憶する
レジスタである。ステップS236では、フェールと判
定されたノードまでのルートに“1”ずつ重みを追加す
る。
【0131】次に、フェールが外部信号X11で発生し
た場合を説明する。かかる場合は、N=0(信号
13)のデータは正しいので、ステップS208→ス
テップS210に進む。ステップS210では、当該信
号が外部信号か内部信号かを判断する。第51図の例で
はN=0の信号は外部信号なのでステップS240に進
んで、次のノードが存在するかを調べる。第51図の例
では次のノードはX10又はX11のいずれかである。
ステップS242では探索されていない分岐ルートが存
在するかを調べる。第51図の例では、探索されていな
い分岐ルートはX10に向かうルートとX11に向かう
ルートの2つである。そこで、ステップS242からス
テップS244に進んで、探索されていない分岐ルート
のうちの最大重みを有するルートを選択する。探索され
ていない分岐ルートが1つしか内場合はステップS24
4ではそのルートが選択される。また、探索されていな
い分岐ルートが2つ以上あって、それらが全て同じ値
(“0”も含む)の重みを有する場合は、最右側のルー
トが便宜上選択される。ステップS245では分岐ノー
ドポインタスタックBNPに、この分岐点に戻ってきた
場合に次回に探索されるべき分岐ルートを対比する。そ
してステップS246でその選択されたルート上の現在
のノードに最近の1つのノード(即ち、X11)が指定
される。そして、ステップS206に戻って、そのノー
ド(即ち、X11)に対応する信号データを状態ファイ
ル111から読み出す。X11の信号は正しくないの
で、制御はステップS208からステップS226に進
む。X11はX13と同様に外部信号ノードなので、ス
テップS226→ステップS234→ステップS236
と進んで、X11が故障と記録すると共に、X13→X
11に至るルートに重み“1”を追加する。
【0132】次に、アクチュエータY の確認スイツ
チ信号M がフェールしている場合を例にして説明す
る。この場合は、ノードX13,X11,X10,X
12は正常である。ノードX13,X11のチェックを
終了した時点では、分岐ノードポインタスタックBNP
には、X10のルートが次に探索されるべきことが記憶
されている。次にX12のチェックをステップS208
で行なうところから説明を始める。制御はステップS2
08→ステップS210→ステップS240→ステップ
S242に進む。X12の後には分岐点もノードも存在
しないから制御はステップS248からステップS25
0に進む。ステップS250のフラグFは前の探索でい
ずれかの内部信号にフェールが発見されたことを示すも
のである。前述したように、確認信号Mのような内部信
号はそれがフェールであることを示しているとしても、
その上流の信号がフェールしているためにフェールを示
しているに過ぎない場合がある。フラグFは、以前の探
索で内部信号にフェールしているものがあったことを記
憶し、そのフェールしていることを示す内部信号のノー
ド番号は第60図に示す故障ノードポインタスタックF
NPに格納される。今の場合は、F=0であるから、ス
テップS250からステップS256に進む。ステップ
S254では、ステップS245で退避しておいたリタ
ーン分岐点をスタックBNPから取り出す。ステップS
256では、スタックBNPにリターンポイント(ステ
ップS245で退避したX10のルート)が退避されて
いることを確認してから、ステップS258で次のノー
ドX10を指定し、ステップS206に戻る。外部信号
10は正常であるから、X10に対しては、制御はス
テップS208→ステップS210→ステップS240
→ステップS242→ステップS248→ステップS2
69に進み内部信号であるノードM を指定する。
【0133】フェールしているノードM について
は、制御は、ステップS206→ステップS208→ス
テップS226と進む。M は内部信号であるので、
更にステップS226→ステップS228→ステップS
230と進んで、前述のフラグFをセットする。そし
て、ステップS232で現在のノードカウント値Nをフ
ェールノードポインタスタックFNPに退避する。
【0134】ところで、ステップS228でフラグFが
セットされている場合も、ステップS232でスタック
FNPにノードカウントNを退避している。これは、例
えばノードX がフェールしているときには、ノード
,M もフェールというデータを状態ファイル
111に含んでいるので、X に至るまでに内部信号
が2つあったことを示す必要があるからである。
【0135】ステップS232からステップS240に
進んで、次のノードを探す。第51図の例では、M
の次には分岐点が存在する。そこで、制御はステップS
240→ステップS242→ステップS244→ステッ
プS245→ステップS246と進んで、次のノードX
を指定する。このノードには正常な外部信号X
ある。このノードX については、制御はステップス
テップS246→ステップS206→ステップS208
→ステップS210→ステップS240→ステップS2
42→ステップS248→ステップS269と進んで、
新たにノードMを指定する。
【0136】ノードM については、制御は、ステッ
プS206→ステップS208→ステップS210→ス
テップS212と進んで、フラグFをチェックする。フ
ラグFは、フェールしたノードM を調べる過程でス
テップS228でセットされている。従って、制御はス
テップS212→ステップS222と進み、フェールノ
ードポインタスタックの最新のポインタが示すノード番
号をフェールしたノードとする。前述したように、この
ポインタにはステップS232でノードMがセットさ
れている。ステップS224では、ノードM に至る
ルートに対して重み値を更新する。
【0137】このように、内部信号がフェールしている
ことを示す場合は、そのフェールがその内部信号自体の
フェールによるフェールであるのか、それともその内部
信号の上流の信号によるフェールか直ちには分らないの
で、フラグFとスタックFNPにフェールしたノードの
存在を仮に退避しておく。そして、次に現われた内部信
号がフェールを示していないということは、その上流に
はフェールしたノードが無いことを示しているから、ス
タックFNPに退避されている内部信号ノードが実際に
フェールしているノードであることになる。換言すれ
ば、信号に内部信号と外部信号という区別を付けること
により、不必要なノード探索が省略できる。
【0138】次に、ステップS214以下の手順につい
て、第62図の例を参考にして説明する。第62図で外
部信号ノードX31がフェールしているとする。また、
内部信号M20は第62図に示しているように、多くの
外部信号の積から生成されているので、通常の二分木サ
ーチ法では、M20の他に、X41〜X100 という
多くのノードを調べなければ、フェールノードX31
チェックには入れない。第58図のステップS214以
下の手順はこの非効率を解消するものである。
【0139】ノードX20のチェックを終了してノード
40を探す過程で、スタックBNPにはステップS2
45でリターン分岐点が退避され、ステップS246で
が指定される。X40のチェック過程のステップ
S269で内部信号ノードM 20が指定される。このM
20のデータは正常であるから、制御はステップS20
6→ステップS208→ステップS210→ステップS
212→ステップS214と進む。ステップS214で
は、上記リターン分岐点(X20とM30の間の分岐
点)がスタックBNPから取り出され、ステップS21
6でM30に向かう分岐ルートがあることを確認してか
ら、ステップS218でそのルートを指定する。そし
て、ステップS240→ステップS242→ステップS
248→ステップS269→ステップS206でノード
30のデータを取り出す。M30は内部信号であるの
で、外部信号X31がフェールしている場合は、M30
もフェールしていることを示しているので、制御はステ
ップS206からステップS208→ステップS226
に進む。ノードM30の次にノードX31がフェールし
ていることを発見するために、スタックFNPが使用さ
れることの制御手順は前に行なっているので省略する。
【0140】第62図の例のように、分岐点に複数の分
岐ルート(X40のルートとM30のルート)があり、
その一部のルート(X40ルート)内に内部信号ノード
(M 20)があり、その内部信号ノードが多くの信号
(X41〜X100 )から形成されており、ところが
フェールは他の分岐ルート(M30のルート)にある場
合は、ステップS214以下の制御手順により、内部信
号M20の正常を確認した(この確認で充分である)時
点で、このルートの探索をそれ以上は行なわないで、本
来のフェールノードの存在するルート上の探索を開始す
る。このように、本実施例の探索手法は効率的なものと
なっている。
【0141】〈故障復旧〉以上が、本実施例システムに
用意された故障検出/故障診断/故障解析の手法であ
る。次に、このように検出された故障からシステムを再
起動可能状態(通常は、故障が発見された動作ステツプ
を含む動作ブロックの先頭)に復旧して再起動する手法
について説明する。本実施例システムの復旧方法の特徴
は、再起動可能状態への復帰に、マニュアルモードと自
動モードが用意されていることである。マニュアルモー
ドとは、オペレータが上記可能状態に復帰するように自
分の判断で順に手動スイツチをCRT58からセットし
ていくものである。このマニュアルモードでは、上記状
態に復帰すると、それまでに行なった手動スイツチのセ
ットシーケンスをファイル(第40図の210)に登録
しておく。このファイルは過去に起こった故障の復帰過
程を、故障の発生箇所毎に記録しているもので、後に故
障発生箇所をキーにして検索可能になっている。
【0142】自動復帰モードでは、その故障の発生箇所
に対応する過去記憶された復帰手順をファイル210か
ら呼び出して、その復帰シーケンスをシュミレートして
再起動可能状態に復帰する。同じ故障に対する復帰手順
は大体同じものである。従って、このような復帰手順を
記憶し、自動モードにおいて、そのシーケンスをシュミ
レートすれば、復帰操作が敏速に行なえるのみならず、
その手順が統一化され、例えば、初心者でも簡単に復帰
作業を実行することができる。
【0143】以下、第63図乃至第70図を参照しなが
ら、本実施例の復旧方法を説明する。第63図は、復旧
方法の説明のために例示されたある設備(ワーク把持設
備)におけるワーク把持動作を説明する。この設備で
は、ワークWを3つのシリンダが把持する。把持順序
は、シリンダY →シリンダY →シリンダY
である。これらのシリンダYは、第64図に示すよう
に、出状態と戻り状態が2つのスイツチにより確認され
る。第65図は、第63図の設備に対応する実I/Oマ
ップの例である。このI/Oマップでは、各シリンダに
対して夫々、出動作と戻り動作が定義されている。それ
らのシリンダがアクテイベートされるためには、『出
力』フィールドに記されている番号のメモリに“1”が
書き込まれることが必要である。夫々のシリンダの動作
は、対応する『確認A』『確認B』フィールドの番地の
内容をチェックすることにより確認できる。これら3つ
のシリンダの全部で6つの動作は全て、マニュアルでシ
ュミレートできる。第65図には、マニュアルでシュミ
レートするために“1”をセットすべきメモリ番地が
『手動』フィールドに設定されている。第66図及び第
67図は、夫々、3つのシリンダをシリンダY →シ
リンダY →シリンダY の順序で駆動してワーク
Wを把持し、所定の加工動作を行なってから、シリンダ
→シリンダY→シリンダY の順で把持を解
除するという動作を示すところの、動作ステツプマッ
プ,ラダープログラムである。第67図のラダープログ
ラムをみても分るように、各シリンダは、独立して手動
で出状態に、あるいは戻り状態にセットすることができ
る。ラダープログラムで、MAスイツチは自動実行モー
ドにおいてシステムが閉じる自動モードスイツチであ
り、MSは手動実行モードにおいてシステムが閉じる手
動実行モードスイツチである。
【0144】第63図の例で再起動可能状態は、シリン
ダが全て初期位置に戻った状態であると定義できる。も
し、シリンダY がフェールしているならば、復帰手
順は、先ず、シリンダY を戻し、次にY を戻
し、次にY を戻すことにより、再起動可能状態に復
帰できる。尚、第67図のラダープログラムの各スイツ
チの信号に付された名称は、第66図の動作ステツプに
より、I/Oマップ(第65図)内のメモリ番地と関連
付けられている。
【0145】第68図は、CRT58の表示画面の例を
示す。図中、301はマニュアル復帰を指示するための
アイコンであり、302は自動復帰を指示するためのア
イコンである。300の表示領域にはラダープログラム
が表示される。領域300内の全ての表示要素はアイコ
ンとして機能する。即ち、領域300に手動スイツチが
表示されていれば、オペレータがそのスイツチの表示部
分を選択すると、システムはタッチパネル57を介して
そのスイツチが押されたと認識できる。オペレータがど
のスイツチを領域300内で選択したかをシステムが認
識できれば、システムはそのスイツチにI/Oマップ
(第65図)の該当番地に“1”を書き込むことができ
る。『SI』アイコンは、ラダープログラム要素の1つ
を実行させるアイコンである。
【0146】このようにして、システムはCRT58を
ユーザインターフェースのための入力出力装置として使
うことができる。第68図中、303は、領域300を
上下左右方向にスクロールするためのアイコンである。
また、304はブロック番号を指定するためのアイコ
ン、305はステップ番号を指定するためのアイコン、
307,308は指定されたブロック番号及びステップ
番号を表示する表示領域である。306は、『起動』ア
イコンであり、オペレータがシステムが再起動可能状態
に復帰したと判断してこのアイコンを選択すると、シス
テムはこれを検知して自動実行モードでラダープログラ
ムを再起動する。
【0147】第69図は、故障が上述の故障診断システ
ムで検知された後において、マニュアルモードでの復帰
を制御する手順を示し、第70図は自動モードでの復帰
の制御手順を示す。アイコン301(マニュアル復帰モ
ード)が選択されると、CRT58上に第68図のよう
な画面が現われる。ステップS270では、故障が検出
されたブロック番号ステップ番号B を復帰プ
ログラムに入力する。CRT画面の領域300には入力
されたラダープログラムB が表示される。ス
テップS272では、ラダープログラムの自動実行モー
ドを消勢し、マニュアル実行モードを付勢するためにM
=1,M =0とする。ステップS274ではタ
ッチパネル57からの入力を待つ。オペレータは領域3
00に表示された各スイツチアイコンにタッチしなが
ら、そのスイツチをオンしたりオフしたりする。領域3
00に目的のステップが表示されていない場合は、スク
ロール用のアイコン303を操作し、または、目的のブ
ロック番号,ステップ番号を入力するためにアイコン3
04,306を操作する(ステップS300またはステ
ップS308,310)。
【0148】領域300上のいずれかのスイツチアイコ
ンがタッチされると、ステップS282で、タッチされ
た座標位置がどのスイツチに当るかを検出し、そのスイ
ツチの対応メモリアドレスをI/Oマップ(第65図)
から探し、そのアドレス中に指定された値を書き込む。
この場合、スイツチはモメンタリとなっているので、ス
イツチアイコンがオン状態を示している状態でタッチパ
ネル57にタッチすると、そのスイツチはオフ状態
(“0”が書き込まれる)になり、逆にオフ状態でタッ
チされるとオンになる(“1”が書き込まれる)。CR
Tに表示されているスイツチのインターロツクは前述し
たように、種々制御可能であるが、オン状態では例えば
緑に、オフ状態では赤に設定されている。ステップS2
86では、ステップS282で同定されたスイツチをそ
れが操作されたシーケンスと共に復旧シーケンスファイ
ル210に記憶する。
【0149】このようにスイツチが手動で変更された状
態で、『SI』アイコンが押されるとステップS290
でラダープログラムが1つ実行される。復帰プログラム
のいずれかのラダープログラム要素で、その要素は実行
される。即ち、例えば、シリンダY が戻される条件
が揃っていれば、シリンダY は初期位置に戻され
る。ステップS292では、そのアクチュエータが戻さ
れた(あるいは起動された)後の確認スイツチ信号を入
力し、ステップS294でそれらのスイツチの表示の更
新を行なう。ステップS282〜ステップS286,ス
テップS290〜ステップS294の動作を繰り返すこ
とにより設備は再起動可能状態に戻る。
【0150】操作者が再起動可能状態に戻った事を確認
し『再起動』アイコンを選択すると、ステップS302
で、ステップS286で記憶していたスイツチシーケン
スをファイルとして登録する。即ち、そのシーケンスは
ステップS270で入力された故障の発生したブロック
番号,ステップ番号と関連付けられて登録されて、以降
そのファイルにアクセスすることが可能となる。ステッ
プS304では、手動実行モードを解除し自動実行モー
ドに移るために、M=0,M =1とする。そし
て、ステップS306でラダープログラムをスタートす
る。
【0151】第70図は、前述の手動再起動(第69
図)により蓄積された起動シーケンスに基づいて再起動
をかけるための制御手順を示すフローチヤートである。
故障箇所が特定され、操作者が『自動復帰』アイコンを
選択すると、この自動復旧プログラムが起動される。復
旧プログラムは、ステップS320で故障が検出された
ブロック番号ステップ番号B を入力する。C
RT画面の領域300には入力されたラダープログラム
のラダー図が表示される。ステップS32
2では、復帰シーケンスファイル210から該当するシ
ーケンスをサーチし、ステップS324でそにシーケン
スデータを読み出す。ステップS326では、手動実行
モードに変えるために、M =0,M =1とす
る。ステップS328〜ステップS332は、読み出さ
れたシーケンスに従ってスイツチをセットし、1ステツ
プずつラダープログラムを実行するものである。ステッ
プS334では、操作者が再起動アイコン306を選択
するのを待つ。このアイコンが選択されたなら、ステッ
プS336,ステップS338で、元のシーケンス制御
ラダープログラムに従って生産が再開される。
【0152】かくして、上述の復帰方法によれば、操作
者の経験の多寡によらずに、正確で安定な復旧が可能と
なる。
【0153】〈シュミレーション〉シュミレーション
は、通常、第17図のトライアル段階、または、実稼動
時に発生した故障を再現させることを主な目的とする。
本実施例のシュミレーションとは、実際の設備が動くこ
となくCRT58上でラダープログラムがシュミレート
されるものである。トライアル段階であろうと実稼動段
階であろうと、シュミレーションを行なうためには、そ
の条件を整える必要がある。本実施例のような、生産工
程を複数の動作ブロックに分解し、個々の動作ブロック
を更に複数の動作ステツプに分解して表現した場合に
は、シュミレーションは一般的には動作ブロック単位に
行なわれる。従って、その動作ブロックがシュミレーシ
ョンされるためには、その動作ブロックの起動条件と、
その動作ブロック内の個々の動作ステツプの実行に必要
な種々の入力が必要となる。従来のシュミレーションシ
ステムでは、これらの条件を手動で与えていた。本シュ
ミレーションサブシステムは上記条件を自動的に与える
ものである。
【0154】第53図のフローチヤートに関連して説明
したように、ステップS99では1つのステップの動作
を終了すると、故障の検出の有無にかかわらずに、変化
のあったスイツチの状態を動作状態ファイル111に書
き込む。また、ステップS105では、ブロックの終了
毎に、全確認スイツチの状態を動作状態ファイル111
に書き込む。また、故障が検出されれば、その故障が検
出された時点のスイツチ状態も同ファイル111に書き
込まれる。そして、第20図,第21図に関連して説明
したように、上記状態ファイル111に記憶されたデー
タから任意の時点のスイツチ変化を忠実に復元できる。
【0155】第71図は、動作ステツプB
おいてあるインターロツク条件ILC が満足される
とシリンダY を駆動し、動作ステツプB
でシリンダY がオンされ外部から信号X100
入力されたことを確認(X=1)してシリンダY
を駆動し、動作ステツプB でシリンダY
がオンされ外部信号X101 が入力されたことを確認
(X =1)してシリンダY を駆動するというラ
ダープログラムである。第72図は、第71図のラダー
プログラムをシュミレートするためのシュミレートプロ
グラムである。シリンダ要素Y ,Y は、タイマ
要素TM ,TM に置き換えられている。これら
のタイマ要素のセット時間は、シリンダY ,Y
のI/Oマップに与えられている。例えば、第15図の
I/Oマップでは、この時間は『動作時間τ』フィール
ドに与えられている。従って、第71図のシーケンスラ
ダープログラムから第72図のシュミレーションプログ
ラムを作成することは、動作時間τのデータを有してい
るI/Oマップを前もって作成しておくことにより容易
である。そして、第72図のシュミレーションプログラ
ムは、動作ステツプB においてあるインター
ロツク条件ILC が満足されるとTM を駆動
し、動作ステツプB でタイマTMがタイム
アウトし外部から信号X100 が入力されたことを確
認(TM =1)して、タイマTM を駆動し、動
作ステツプB でTM がタイムアウトし外
部から信号X101 が入力されたことを確認(TM
=1)してTM を駆動するというように、第71
図のプログラムをシュミレーションする。
【0156】このように、シュミレーションプログラム
では、ラダープログラム中の、シリンダのようなアクチ
ュエータのように駆動されると物理的に動いて、その動
作に時間のかかるものがタイマ要素に変換される。そし
て、そのアクチュエータの動作確認スイツチ(例えば、
)は、タイマ要素の内部スイツチ(TM )に
変換される。そして、アクチュエータ以外の出力(例え
ば、第71図のB 信号)等は内部信号であるの
で変更する必要はない。換言すれば、操作者にシュミレ
ーションの過程を可視的に表示させるには、シュミレー
ションプログラム(第72図)の動作の推移状態をCR
T58上に表示するよりも、第71図のラダープログラ
ムのシンボルを表示した方が、操作者に違和感のない現
実感のあるシュミレーション表示を提供できる。その場
合、例えば、タイマTM がタイムアウトしていない
ときは、シリンダY のシンボルの表示は赤色で、タ
イムアウトしていればシリンダY のシンボルの表示
は緑色で表示するようにする。同じ理由により、アクチ
ュエータではない確認スイツチ類でも、オンしているス
イツチは緑色で、オンしていないスイツチは赤色で表示
する。
【0157】前述したように、シュミレーションプログ
ラム(例えば、第72図のプログラム)が起動されるに
は、そのブロックの起動条件が満足されなければならな
い。このブロックの起動条件は、第44図〜第48図に
関連して説明したように、当該動作ブロック(第44図
のブロック4)の前段にある動作ブロック(動作ブロッ
ク2,3)内の全ての確認スイツチの総和である。この
起動条件の論理式は、第72図の例では、ILC
して示されている。シュミレーションの起動時には、こ
のインターロツク条件の論理の実際の論理値は動作状態
ファイル111から得られる。即ち、第72図のブロッ
ク0のシュミレーションラダープログラムの起動は、I
LC にファイル111からデータを与えることによ
り可能となる。シュミレーションプログラムの各動作ス
テツプの起動は、タイマ要素のタイムアウトと外部信号
の入力があれば可能となる。
【0158】第73図は、動作状態ファイル111に記
憶されたデータから復元した信号変化のタイミングチヤ
ートである。第73図の例では、シリンダY は時間
τ’ でオンし、シリンダYはτ ’ でオンし
た。第74図は第72図のシュミレーションプログラム
により再現された動作の遷移を示すタイミングチヤート
である。第73図と第74図とで若干の差異があるの
は、実動作時間τ’ ,τ ’ と、タイマ要素T
,TM の公称時間τ ,τとで差異があ
るからである。そして、外部から入力される信号X
100 ,X 101 が入力された時間(第74図で時
刻t ,t )は動作状態ファイル111に記憶さ
れているので、この時刻t ,t に状態ファイル
111からシュミレーションプログラムに入力される。
【0159】第75図は、シュミレーション用のラダー
プログラムの実行制御を行なうシュミレーション制御プ
ログラム206の動作を示すフローチヤートである。ま
た、第76図はある動作ブロックの動作状態ファイルの
フォーマツトを示す。第76図の例では、この動作ブロ
ックの動作は複数個のレコードにより記憶されている。
最初のレコードは当該ブロックが時刻t に起動され
たことを、2番目のレコードはその後t に変化があ
ったことを、3番目のレコードはt に変化があった
ことを、‥‥‥示している。
【0160】第75図の制御プログラムは所定の『シュ
ミレーション起動』アイコンを操作者が選択することに
より起動される(ステップS402)。ステップS40
4では、シュミレーション対象の動作ブロックの指定を
オペレータに促す。ステップS406では、指定された
ブロック番号に対応するデータファイルをファイル11
1中に探し、ステップS408で、その最初のレコード
のデータ(起動条件)を読み出し、ステップS410で
そのデータをシュミレーションラダープログラム(第7
2図のILC )にセットする。ここで、データをラ
ダープログラム中にセットするとは、ラダープログラム
要素の対応メモリ番地はI/Oマップに保持されている
ので、このI/Oマップを参照することにより、対応す
るメモリ番地にデータを書き込む。ステップS412で
はラダープログラムを起動する。ステップS414で
は、シュミレーションの起動時刻t を記憶する。ス
テップS416〜ステップS426のループでは、ファ
イル111から1つのレコード(n番目のレコード)を
読み出し、シュミレーション開始からの経過時間が、そ
のレコードの記録時刻から求めた経過時間(t −t
)に等しくなった時点で、そのレコードのデータを
ラダープログラム中にセットするものである。即ち、実
際のラダープログラム(第71図)の実際の動作の記録
の開始(時刻t )からの経過時間 (t −t ) が、シュミレーション実行中に経過したということは、
に対応するn番目のレコードに記録された信号状
態の変化をシュミレーションプログラムに与えるべきと
きであることを意味する。そこで、ステップS416で
は、n番目のレコードを読む。そして、制御プログラム
206によるシュミレーションの起動開始(t )か
らの現在時刻tまでの経過時間 (t−t ) が、そのn番目のレコードに記録された信号状態の変化
をシュミレーションプログラムに与えるべき時点に至っ
たかを判断するために、ステップS418で、(t
−t )と(t−t )とを比較する。その比較結
果が等しいならば、ステップS420では、そのn番目
のレコードに記録されている信号データを対応するメモ
リ番地に書き込む。ステップS422では、ファイル1
11の当該ブロックの全てのレコードを読み取っていな
いことを確認してからステップS416に戻って上記動
作を繰り返す。
【0161】ステップS418で、シュミレーション開
始から時間t −t が経過していないと判断され
たときは、ステップS424で全ての確認スイツチの出
力を読み取り、ステップS426で、それらの信号に変
化に応じてCRT58上における表示を更新する。かく
して、本実施例のシュミレーション方法によれば、シュ
ミレーション条件が、実際に動作させたラダープログラ
ムの起動条件を記憶したものに基づいてセットされるの
で、正確且つ効率的なシュミレーションを実現できる。
【0162】〈ラダープログラムの最適化〉前述のシー
ケンスラダープログラムの自動生成サブシステム104
は、例えば、動作ブロックの起動条件の生成は、第44
図〜第48図に関連して説明したように、起動条件の生
成対象となる当該動作ブロックの直前段の全ての動作ブ
ロック内で用いられる確認スイツチの論理積で表わされ
るとした。そして、それらの論理積のなかで、同じ設備
(アクチュエータ)の相補的な2つの確認信号(『出』
確認信号と『戻り』確認信号)が含まれていれば、それ
らをキヤンセルすることにより、ある意味では、ラダー
プログラムを簡素化し、最適化しようとしていた。本シ
ステムの最適化プログラム129は、 :動作ブロックの起動条件の中で、そのブロックの起
動に実際には関係しない条件を除去することにより、ラ
ダープログラムを更に最適化しようとするものである。 :さらに、曖昧な動作をラダープログラムが有してい
るならば、その曖昧な動作のプログラム部分を検出し修
正することにより、ラダープログラムを最適化するもの
である。
【0163】起動条件の最適化 ある動作ブロックの起動条件の中で、そのブロックの起
動に実際には関係しないものの例を第77図を参照して
説明する。第77図において、ワーク402は移載装置
400によりA位置まで移動される。ロボット406は
A位置にあるワークを、そのワークに適したハンドによ
り把持する。複数のハンド404が、回転治具401に
装着されている。回転治具401は、ロボット406が
必要とするハンドをロボット側に供給するために回転
し、所定の回転位置で割り出しロックピン407により
ロックされる。第78図は、第71図の設備の動作を記
述したブロックフローマップ(一部にラダープログラム
が記載されている)であり、このマップは3つのブロッ
クからなる。ブロックB はワーク402をA位置に
移載する動作を記述し、ブロックB は回転治具の動
作を記述し、ブロックB はロボット406によるワ
ーク402の把持動作が起動されるための起動条件を記
述する。ブロックB の動作では、ワークがリミツト
スイツチ『ワーク到着』をアクチエートすると『ブロッ
ク0完了』信号を発生する。一方、ブロックB
は、信号L を受けると『ロックピンアンロック』信
号が生成されて所定のアクチュエータ(不図示)をアク
チベートして治具401をアンロック状態にする。治具
401がアンロック状態になって信号『アンロック』が
発生すると信号『割り出し回転』が生成されて治具40
1が中心403の周りに回転される。治具401のサー
ボが働いて所望のハンドがロボット側に着た時点で『割
り出し回転完』信号が生成されると『ブロック1完了』
信号が生成される。ブロックB の最初のステップは
内部信号『ブロック2起動』を生成するロジツクを記述
する。ブロックB 中の『起動条件』とは第48図に
関連して説明したように、ブロックB とブロックB
の確認信号の論理積となる。従って、この『起動条
件』中には、信号『ロック』や『アンロック』等が含ま
れる。しかしながら、実際には、搬送されてきたワーク
の種類によっては治具401の回転は必要であったり不
要であったりする。何故なら、同じ種類のワークが送ら
れてくる限りは、ハンドの交換は不要となるからであ
る。従って、上記『起動条件』中の、信号『ロック』や
『アンロック』等が起動条件としては必ずしも必要なも
のではなく、除去した方がプログラム構造を簡易にし、
プログラム保守を行ない易くし、且つ不要なロジツクが
無くなることからプログラムも効率的に動作することと
なる。従って、どのようにして不要なロジツクが起動条
件中に含まれていることを検知するかが問題となる。
【0164】最適化プログラム129は、起動条件に不
要な論理が含まれている場合には、実際の生産現場で記
録を取った場合に、その論理を示す信号の発生時期が場
合場合でまちまちであることに着目し、そのようなまち
まちな発生時期を示す信号が起動条件に含まれている場
合にはその信号を起動条件から外すようにしている。プ
ログラム129は、上記発生時期を動作状態ファイル1
11から検出するようにしている。第79図は、第77
図の設備における動作をケースIとケースIIとケース
III について記録した信号のタイミングチヤートで
ある。第79図において、『ロック』信号の発生時期
は、ケースIとケースIIとケースIIIでは全て異な
ったものとなっている。回転治具401が回転する必要
が無い場合(ケースIII )もあれば、回転量が少な
い場合(ケースII)もあるからである。
【0165】第80図は最適化プログラム129の制御
手順を示すフローチヤートである。このプログラム12
9は所定のアイコンを選択することにより起動される。
ステップS450では、操作者が最適化しようと考えて
いる動作ブロックの指定を促す。ステップS452で
は、信号の発生時期をチェックするためにファイル11
1を考慮すべき期間を指定する。但し、この期間は無指
定であってもよい。ステップS454では、この期間内
の状態ファイルデータであって、正常な動作結果となっ
たもののみを入力し、ステップS456で、これらのデ
ータから第20図,第21図に関連して説明したよう
に、タイミングチヤートを再構成する。ステップS45
8では、第79図に関連して説明したように、発生時期
の定まらない信号(第79図の例では『ロック信号』)
を抽出する。ステップS460では、その動作ブロック
の起動条件を含むラダー図をCRT58に表示すると共
に、ステップS458で抽出された信号を起動条件をか
ら削除してよいかのメツセージをCRT58に表示す
る。削除してもよい旨の返答があったならば、ステップ
S464で、起動条件からその信号を削除する。ステッ
プS464では、更に、ブロックの起動条件にこの信号
を含めないとする生成ルールそのものを変更してもよ
い。かくして、ブロックの起動条件が最適化され、プロ
グラムが見易いものとなり、且つ、プログラムの実行速
度そのものが向上する。
【0166】曖昧部分の最適化 あるコントローラから他のコントローラに並列に複数の
信号を伝送する場合には、これらの信号間にスキュウが
発生する場合がある。このスキューは設備の誤動作の原
因となる。本来は、かかる制御の曖昧な部分は厳密に検
討されて対策されてしかるべきものであるが、あらゆる
部分で厳密にタイミングを検討することは不可能であ
る。そこで、最適化プログラム129は、曖昧部分を簡
便に検出し修正して最適化するものである。
【0167】第81図,第82図により、タイミング制
御が曖昧なラダープログラムの例を説明する。第81図
は、ストローブ信号『データ送信』を受けて、X
までをメモリに記憶する動作を記述するラダープロ
グラムである。外部のコントローラから信号『データ送
信』を受けると、内部信号『データ記憶』を発生する。
この『データ記憶』はサンプリングタイミングを形成し
て、データ信号X〜X を受信すると、これらのデ
ータ信号をメモリに記憶すべく、記憶信号『X
憶』『X 記憶』等を発生する。第82図は、データ
信号X 〜X のうち、X が遅く送られてきた
ために、X が誤って記憶された例のタイミングチヤ
ートを示す。本来は、遅れたデータ信号は発生されない
ように、その外部コントローラのラダープログラムが構
成されてしかるべきである。最適化プログラム129
は、発生時期が曖昧な信号は、その信号を記録した場合
に記録ケース毎に異なることに着目する。そこで、故障
が発生した場合に、その故障時の信号のタイミングチヤ
ートと、過去記憶しておいた正常時のその信号のタイミ
ングチヤートとを比べて、異なる部分があれば、その信
号は不安定な動作を起こし易いものと判断して、不安定
動作を起こしたことをチェックするラダープログラム要
素を自動的に発生するように生成ルールを変更する。第
82図はルール変更の原理を説明する。即ち、不安定だ
と疑われる信号のタイミングチヤートを作成し、信号の
交差範囲と考えられるウインド(TMIN〜T
MAX )を設定し、83図のようなラダーロジツクを
作成する。第83図のロジツクは、信号『データ記憶』
が入力されると、2つのタイマTMIN とTMAX
が起動される。タイマTMIN がタイムアウトしてT
MAX がタイムアウトするまでの間にX 〜X
の信号を記憶する。TMIN がタイムアウトする前
に、または、TMAX がタイムアウトしてからX
〜Xのいずれかが入力されるとフェールするというも
のである。
【0168】第84図はこの最適化のためのプログラム
129の制御手順である。この手順は所定のアイコンを
選択することにより起動される。ステップS480で
は、操作者が最適化しようと考えている動作ステップの
指定を促す。ステップS482では、信号の発生時期を
チェックするためにファイル111を考慮すべき期間を
指定する。但し、この期間は無指定であってもよい。ス
テップS484では、この期間内の状態ファイルデータ
であって、故障と判断されたもののみを入力し、ステッ
プS486で、これらのデータから第20図,第21図
に関連して説明したように、タイミングチヤートを再構
成する。ステップS488では、第82図に関連して説
明したように、発生時期の定まらない信号を抽出する。
ステップS490では、それらの信号のタイミングチャ
ートをCRT58上に表示する。そして、ステップS4
92で、ステップS488で抽出された信号についての
生成ルールを変更してもよいかのメツセージをCRT5
8に表示する。変更してもよい旨の返答があったなら
ば、ステップS494で、その信号のラダープログラム
及び生成ルールを変更するために、タイマ要素を第83
図のように追加する。
【0169】尚、ステップS484における過去の状態
ファイルデータの収集は、明白な故障データ、例えば、
信号伝送ラインの断線等の故障データは省くべきであ
る。また、付加すべきロジツクは、上記例では、ウイン
ドを設定するタイマロジツクであった。これは信号伝送
等の場合は、信号が遅れたり、進んだりするからであ
る。信号伝送以外のロジツク、例えば、シリンダの駆動
を最適化する場合には、シリンダの動作時間が早まると
いうことはないから、シリンダの動作をチェックするロ
ジツクのタイマ値を変更するだけでよい。
【0170】〈実施例の効果〉以上、説明した実施例シ
ステムによれば、 :ステツプタイムオーバ検出、ステツプハングアップ
検出、ブロツクハングアップ検出により、簡単で的確な
故障検出ができると共に、二分木サーチの手法により高
速に故障箇所の解析が可能になった。さらに、過去の故
障解析結果がノードの『重み』に反映されるので、故障
箇所の探索が更に高速化された。また、スイツチ信号
を、『外部信号』と『内部信号』に分類し、故障探索対
象の信号がそのどちらに属するかでそれ以上の探索を続
行するか否かを判定しているので、故障箇所の解析が高
速化する。
【0171】更に、前もって故障デバイスと故障の検出
される動作ステツプとを対応付けたデータベースを作成
し、このデータベースのなかを発生頻度順に故障デバイ
スの探索を行なうことにより故障解析が高速化する。 :過去の故障に対する復帰過程を記憶し、同一故障に
対しては、その過程を記憶から呼び戻してそのシーケン
スを再生するという復旧処理手法を採用することによ
り、難解な復旧処理が単純化され、操作の統一化が図れ
る。 :ラダープログラムの実際の稼動状態(または、シュ
ミレーション中の動作状態)を記憶し、故障のシュミレ
ーションあるいはラダープログラムの試行段階でのシュ
ミレーションにたいしては、この状態データをシュミレ
ーション条件として使用することにより、シュミレーシ
ョンが効率的に且つ正確に行なえるようになった。これ
は、状態データを示す信号名が名前によりシステム内で
特定されることによる効果が大きい。 :動作ブロックあるいは動作ステツプの起動条件中に
存在する無駄な論理を、過去に記憶した動作状態を示す
データファイルを調べることにより発見し、その無駄な
論理を含むラダープログラムあるいは生成ルールを変更
することにより、シーケンスラダープログラムが最適化
される。ラダープログラムに存在する不安定な信号を、
過去に記憶した動作状態を示すデータファイルを調べる
ことにより発見し、その不安定な信号を含むラダープロ
グラムあるいは生成ルールを変更することにより、シー
ケンスラダープログラムが最適化される。
【0172】〈変形例〉本発明はその主旨を逸脱しない
範囲で種々変形が可能である。例えば、上記実施例は本
発明を自動車の生産ラインに適用したものであったが、
当然ながら本発明はそのような適用分野に限定されるも
のではない。少なくともシーケンス制御を行なうもので
あれば適用可能である。故障解析探索の変形例 第49図〜第52図,第57図〜第62図に関連して説
明した故障箇所の解析手法はバイナリサーチ(二分木探
索)に基づいたものであった。ここでは、故障解析の変
形手法を提案する。
【0173】この変形手法は、過去に発生した故障(発
生動作ステツプ番号)と、解析して得た故障発生箇所
(故障した確認スイツチデバイスの名称)とを関連付け
てデータベースに記憶し、これらのデータをソートす
る。ソートは、動作ステツプ番号を第1ソートキーと
し、故障デバイス名称を第2ソートキーとする。こうす
ると、第85図に示すと共に、故障した動作ステツプ番
号毎に故障箇所がソートされ、故障データは同一動作ス
テツプについては発生頻度の高いデバイス順に並べられ
る。従って、ある動作ステツプ(B )で故障
が検出されて、故障デバイスを特定する場合には、発生
頻度の高かったデバイスの順にサーチを実行すればよ
い。
【0174】第86図はこの変形手法に係る制御手順を
示すフローチヤートである。ステップS510では、故
障が検出された動作ステツプの番号(B )を
知る。ステップS512では、その番号を有するレコー
ド群を第85図のデータベース中に探索し、さらに、ス
テップS514でそのレコード群のなかから、最大頻度
の故障デバイスを先ず故障している可能性が高いと推定
する。そして、ステップS516では、そのデバイスに
対応する確認信号のデータを記憶するメモリ番地を前述
のI/Oマップ(24図,第65図)から知る。ステッ
プS518ではそのメモリ番地からデバイスデータを読
み出してチェックし、その信号データが故障を示してい
るのであれば、ステップS524でそのデバイスを故障
とマークし、示していなければ、ステップS522で次
の発生頻度のデバイスについて調べる。
【0175】第85図のデータベースをどのように作成
するかが問題である。第87図はその作成手順を示す。
ステップS530では対象とならシーケンスラダープロ
グラムのシュミレーションプログラム(前もって作成し
たもの)を起動する。ステップS532では人為的に故
障を設備中に設定する。ステップS534では、設定し
た故障により発生した故障を検出した動作ステツプ番号
を故障を設定したデバイス名称と関係付け
て記録する。この操作を充分なデータが得られるまで繰
り返す。尚、ステップS540に示すように、過去発生
した故障データをデータベースに組み込んでもよい。
【0176】第88図は、第85図のデータベース中の
データ間の関係を模式化したもので、動作ステツプB
に関連する集合である。同図の500〜504
は、A,,B,Cという3つのデバイスに起因する故障
のケースを集合として示したもので、領域510はデバ
イスAにのみ起因する故障を、領域500はデバイスA
にのみ起因する故障を、領域501はデバイスA,Bに
のみ起因する故障を、領域502はデバイスA,B,C
に共通して起因する故障を、領域503はデバイスB,
Cにのみ起因する故障を、領域504はデバイスCにの
み起因する故障を表示する。同図から明らかなように、
共通部分にある故障の原因となるデバイスほど、実際の
故障の原因である可能性が高い。従って、そのような確
率の高いデバイスを優先してチェックすれば、故障デバ
イスが発見される効率が向上する。尚、第88図中、5
05は常にオンであるデバイスの集合を示し、506は
オフである集合を示し、507は当該動作ステツプに関
係のない信号の集合である。上記データベースの作成過
程であるいはデータベースの探索過程で、集合505,
506,507に関連する集合はサーチ対象から除外す
ることによりサーチが高速化する。
【0177】復旧の他の手法 第70図に示した故障復旧方法は、システムがすべて自
動で復旧シーケンスファイルに従って復旧を行うという
ものである。これから説明する例は、セットされるべき
スイッチをシステムが色を変えて表示して操作者に復旧
シーケンスを提示する。第89図は、そのための制御手
順であって、第70図のステップS328〜S332ま
での手順と置きか得られるべきものである。即ち、シー
ケンスファイルに従って、ステップS560で、1つの
1つのデバイスをマニュアルでセットすべきものとする
意味で黄色で表示する。操作者が対応スイッチをセット
すれば、ステップS564で対応メモリ番地の内容を更
新し、ステップS566でラダープログラムを実行し、
実行の結果、変化があれば、表示をステップS568で
更新する。
【0178】
【発明の効果】以上説明した本発明のシュミレーション
プログラムの生成方法によれば、シュミレーション対象
のラダープログラムを実際に稼動させて得た動作状態デ
ータをシュミレーション条件とすることにより、正確な
シュミレーションプログラムを効率良く作成することが
できる。
【図面の簡単な説明】
【図1】,
【図2】,
【図3】本発明が適用された自動車の生産ラインを説明
する図。
【図4】,
【図5】,
【図6】図1の生産ラインにおける動作をブロック化
し、動作ブロックフローチヤートと呼ばれるフローチヤ
ート図。
【図7】図4の1つのブロックにおける動作を表わし、
動作ステツプフローチヤートと呼ばれるフローチヤート
図。
【図8】,
【図9】,
【図10】図7のステツプの一部動作を表わすラダープ
ログラム図,
【図11】生産ラインにおける設備をシンボル化した
図。
【図12】,
【図13】,
【図14】,
【図15】,
【図16】実施例システムで使われるラダー要素のパタ
ーン図。
【図17】生産ラインを管理するシステムを開発すると
きの手順を一般的に示す図。
【図18】本実施例システムにおけるプログラム及びデ
ータの互いの関連を説明する図。
【図19】本実施例システムの有する特徴的な機能を示
した図。
【図20】,
【図21】動作状態を表わすデータから動作状態の時間
変化を再生する手法を説明する図。
【図22】実施例システムにおいてブロックフローマッ
プと呼ばれるマップの図。
【図23】実施例システムにおいてステツプフローマッ
プと呼ばれるマップの図。
【図24】実施例システムにおいて実I/Oマップと呼
ばれるマップの図。
【図25】実施例システムのハードウエア構成を説明す
る図。
【図26】実施例システムの自動プログラミング/デー
タ入力部の構成を示す図。
【図27】デバイス名称と動作名称のライブラリ構造を
説明する図。
【図28】データ入力プログラムの動作手順を説明する
図。
【図29】,
【図30】ラダープログラムコンパイラの手順を示すフ
ローチヤート図。
【図31】本実施例システムの概略を説明する図。
【図32】タッチパネルと表示との関係を説明する図。
【図33】CRTにおける表示画面を制御するデータ構
造を説明する図。
【図34】CRTにおける表示例を示す図。
【図35】表示画面をセル分割した図。
【図36】デバイス名称の各フィールドが各々意味付け
られていることを説明する図。
【図37】CRTにおける表示を制御するためにユーザ
が入力するデータの構造を説明する図。
【図38】連続搬送動作のためのラダーパターンを説明
する図。
【図39】故障診断サブシステム106とシュミレーシ
ョンサブシステム105との関係を示す図。
【図40】,
【図41】実施例システムにおけるソフトウエア関係の
全体的に示す図。
【図42】,
【図43】,
【図44】,
【図45】,
【図46】,
【図47】,
【図48】ブロックハングアップ等の故障の検出原理を
説明する図。
【図49】,
【図50】故障診断システムにおける二分木サーチの対
象となる設備の例を示すラダープログラム図,クロスリ
ファレンステーブル図。
【図51】,
【図52】故障診断システムにおける二分木サーチアル
ゴリズムにおいて、探索路に重みを付ける過程を説明す
る図。
【図53】マップ制御プログラムの制御手順を示すフロ
ーチヤート。
【図54】動作監視プログラムの制御手順を示すフロー
チヤート。
【図55】,
【図56】故障診断解析プログラムの制御手順を示すフ
ローチヤート。
【図57】,
【図58】故障解析に適用される二分木サーチアルゴリ
ズムの手順を示すフローチヤート。
【図59】,
【図60】,
【図61】二分木サーチの手順で使われる各種データレ
ジスタを説明する図。
【図62】二分木サーチが適用される他の例のラダープ
ログラム図。
【図63】,
【図64】復旧プログラムが適用される設備の一例を示
す図。
【図65】復旧プログラムが適用される図63設備のI
/Oマップを示す図。
【図66】復旧プログラムが適用される図63設備の動
作ステツプフローチヤートマップ図。
【図67】復旧対象の設備のシーケンス動作を示すラダ
ープログラム図。
【図68】復旧プログラムが実行されるときのユーザイ
ンターフェースのための表示画面例を示す図。
【図69】復旧プログラムの手動復帰モードにおける制
御手順を示すフローチヤート。
【図70】復旧プログラムの自動復帰モードにおける制
御手順を示すフローチヤート。
【図71】シュミレーション対象のラダープログラム
図。
【図72】図71のプログラムをシュミレーションする
ためのラダープログラム図。
【図73】,
【図74】シュミレーションのなされる原理を説明する
図。
【図75】シュミレーションプログラム129の制御手
順を示すフローチヤート。
【図76】シュミレーションで使われるシーケンスファ
イルのフォーマツトを説明する図。
【図77】最適化対象の設備の一例を示す図。
【図78】図77設備の動作を記述する動作ブロックフ
ローチヤートマップの図。
【図79】図78設備の動作を記述するプログラムを最
適化するための原理を説明する図。
【図80】最適化制御の制御手順を示すフローチヤー
ト。
【図81】最適化対象の設備の他の例を示す図。
【図82】信号発生が不安定なために最適化が必要な理
由を説明する図。
【図83】最適化を行なった後のラダープログラム図。
【図84】最適化制御の制御手順の他の例を示すフロー
チヤート。
【図85】故障解析の他の手法に使われるデータベース
構造を説明する図。
【図86】故障解析の他の手法を説明するフローチヤー
ト。
【図87】図85データベースを作成する手順を示すフ
ローチヤート。
【図88】図86の故障解析手法の原理を説明する図。
【図89】復旧の他の手法を説明するフローチャート。

Claims (5)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP23773991A JPH0573110A (ja) 1991-09-18 1991-09-18 シユミレーシヨンプログラムの生成方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP23773991A JPH0573110A (ja) 1991-09-18 1991-09-18 シユミレーシヨンプログラムの生成方法

Publications (1)

Publication Number Publication Date
JPH0573110A true JPH0573110A (ja) 1993-03-26

Family

ID=17019759

Family Applications (1)

Application Number Title Priority Date Filing Date
JP23773991A Pending JPH0573110A (ja) 1991-09-18 1991-09-18 シユミレーシヨンプログラムの生成方法

Country Status (1)

Country Link
JP (1) JPH0573110A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0863208A (ja) * 1994-08-24 1996-03-08 Mazda Motor Corp シュミレーションプログラムの作成方法およびその装置
JP2013012088A (ja) * 2011-06-29 2013-01-17 Panasonic Corp 開発支援方法及びプログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0863208A (ja) * 1994-08-24 1996-03-08 Mazda Motor Corp シュミレーションプログラムの作成方法およびその装置
JP2013012088A (ja) * 2011-06-29 2013-01-17 Panasonic Corp 開発支援方法及びプログラム

Similar Documents

Publication Publication Date Title
US7546232B2 (en) Mechanical-electrical template based method and apparatus
US6862553B2 (en) Diagnostics method and apparatus for use with enterprise controls
US6268853B1 (en) Data structure for use in enterprise controls
US6618856B2 (en) Simulation method and apparatus for use in enterprise controls
Benveniste et al. Diagnosis of asynchronous discrete-event systems: a net unfolding approach
US6157864A (en) System, method and article of manufacture for displaying an animated, realtime updated control sequence chart
US6108662A (en) System method and article of manufacture for integrated enterprise-wide control
US7526352B2 (en) Semiconductor production system
US7779053B2 (en) Diagnosis of an automation system
JP5516736B2 (ja) ソフトウェア保守支援装置及びそれにより検証した電子制御装置
US6122752A (en) System and method for characterizing and repairing intelligent systems
CN113515098A (zh) 物流机器人数字孪生系统
Kowal et al. Delta modeling for variant-rich and evolving manufacturing systems
JPH0581009A (ja) 生産設備の故障診断方法
Moormann et al. Supervisory control synthesis for large-scale systems with isomorphisms
KR101566358B1 (ko) 자동화 공정 이상상태 알림 시스템 및 방법
JPH0573110A (ja) シユミレーシヨンプログラムの生成方法
JP3195000B2 (ja) 生産設備の復帰方法およびその装置
JPH0573109A (ja) シーケンスプログラムの生成方法およびその装置
JPH06190692A (ja) 生産設備の復帰装置
JP2918709B2 (ja) シーケンスプログラムの自動生成方法
Maier et al. Automated generation of timing models in distributed production plants
Grimmeisen et al. Case study on automated and continuous reliability assessment of software-defined manufacturing based on digital twins
Yamada et al. Construction of a consulting system from structural description of a mechanical object
Shi et al. Domain modeling for scenario sensing and edge decision-making