IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社キーエンスの特許一覧

特開2022-158227分析装置、分析システム、およびその制御方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022158227
(43)【公開日】2022-10-17
(54)【発明の名称】分析装置、分析システム、およびその制御方法
(51)【国際特許分類】
   G05B 23/02 20060101AFI20221006BHJP
【FI】
G05B23/02 T
【審査請求】未請求
【請求項の数】19
【出願形態】OL
(21)【出願番号】P 2021062983
(22)【出願日】2021-04-01
(71)【出願人】
【識別番号】000129253
【氏名又は名称】株式会社キーエンス
(74)【代理人】
【識別番号】110003281
【氏名又は名称】特許業務法人大塚国際特許事務所
(72)【発明者】
【氏名】宮坂 哲也
(72)【発明者】
【氏名】川上 大樹
【テーマコード(参考)】
3C223
【Fターム(参考)】
3C223AA12
3C223BA03
3C223BB08
3C223CC02
3C223CC03
3C223DD03
3C223FF13
3C223FF16
3C223FF35
3C223GG01
3C223HH04
3C223HH06
3C223HH08
3C223HH15
(57)【要約】
【課題】本発明は、各デバイスの分析結果を同期させたレポートを提供することを目的とする。また、他の目的として、レポートを表示する画面において、複数の表示項目を時間軸に連動して操作可能とすることを目的とする。
【解決手段】分析装置であって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段とを備える。
【選択図】図11
【特許請求の範囲】
【請求項1】
分析装置であって、
ユーザプログラムを繰り返し実行する実行エンジンと、
前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、
取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、
取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、
前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段と
を備えることを特徴とする分析装置。
【請求項2】
1以上の制御サイクルの定義を設定する設定手段をさらに備え、
前記モデル生成手段は、設定された前記1以上の制御サイクルの定義に基づいて、取得された前記運転記録データの学習を行い、
前記レポート生成手段は、前記非正常デバイスとして検知した各デバイスの分析結果を、設定された前記1以上の制御サイクルの定義に従って各デバイスの分析結果を時間軸上に同期させて表示する分析レポートを生成することを特徴とする請求項1に記載の分析装置。
【請求項3】
前記レポート生成手段から出力された前記分析レポートの内容を示す結果表示画面の画面情報を外部装置へ送信する送信手段をさらに備え、
前記外部装置では、前記結果表示画面が操作可能に表示部に表示されることを特徴とする請求項1又は2に記載の分析装置。
【請求項4】
前記結果表示画面には、前記分析結果として、検知された非正常デバイスのサイクルおよび異常が検知されたタイミングを示す検知マップと、検知された非正常デバイスの工程および発生時刻を示す検知リストと、カメラ映像と、いつもと異なる状態が検知された原因を示す分析コメントとの少なくとも1つが含まれることを特徴とする請求項3に記載の分析装置。
【請求項5】
前記検知マップ、前記検知リスト、前記カメラ映像、および前記分析コメントは、互いに時間軸を連動して操作可能であることを特徴とする請求項4に記載の分析装置。
【請求項6】
前記検知マップでは、
検知された非正常デバイスのサイクルの開始タイミング及び終了タイミングが識別可能な形状で示され、
異常が検知されたタイミングを示す異常点が前記形状の内部に含まれることを特徴とする請求項4又は5に記載の分析装置。
【請求項7】
前記カメラ映像では、分析対象の映像と、該分析対象の映像に対応する正常時の映像とが比較可能に表示されることを特徴とする請求項4乃至6の何れか1項に記載の分析装置。
【請求項8】
前記正常時の映像は、前記分析対象の映像の制御サイクルに同期させて表示されることを特徴とする請求項7に記載の分析装置。
【請求項9】
前記結果表示画面には、前記カメラ映像の再生位置を示すシークバーが含まれることを特徴とする請求項4乃至8の何れか1項に記載の分析装置。
【請求項10】
前記結果表示画面には、さらに、前記分析レポートの表示項目を絞るための条件を指定可能なフィルタ設定領域が含まれることを特徴とする請求項4乃至9の何れか1項に記載の分析装置。
【請求項11】
前記フィルタ設定領域では、デバイスの制御サイクルの指定、属性情報の指定、および、イベント、エラーの指定の少なくとも1つによってフィルタが指定可能であることを特徴とする請求項10に記載の分析装置。
【請求項12】
前記ユーザプログラムの編集画面を表示する表示手段をさらに備え、
前記編集画面では、該編集画面の時間軸に同期した前記分析レポートが表示可能であることを特徴とする請求項1乃至11の何れか1項に記載の分析装置。
【請求項13】
前記分析レポートの生成要求を受け付ける受付手段と、
前記レポート生成手段によって前記生成要求に応じて前記分析レポートが生成されると、要求元に分析レポートの生成が完了した旨を通知する通知手段と
をさらに備えることを特徴とする請求項12に記載の分析装置。
【請求項14】
前記分析手段は、前記設定手段によって制御サイクルが定義されていない場合において、制御サイクルのサイクルパターンを有していないデバイスを分析対象として、前記運転記録データを分析することを特徴とする請求項2に記載の分析装置。
【請求項15】
前記レポート生成手段は、制御サイクルのサイクルパターンを有していないデバイスの分析結果を分析レポートとして生成し、
前記分析レポートには、制御サイクルが設定されていない旨と、前記設定手段によって制御サイクルの設定を促すメッセージが含まれることを特徴とする請求項14に記載の分析装置。
【請求項16】
データ処理装置とプログラマブルロジックコントローラとが通信可能な分析システムであって、
ユーザプログラムを繰り返し実行する実行エンジンと、
前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、
取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、
取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、
前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段と
を備えることを特徴とする分析システム。
【請求項17】
前記取得手段、前記モデル生成手段、分析手段、および前記レポート生成手段の少なくとも1つは前記データ処理装置に設けられることを特徴とする請求項16に記載の分析システム。
【請求項18】
前記プログラマブルロジックコントローラは、
前記実行エンジンを備えるCPUユニットと、
前記取得手段を実現する前記プログラマブルロジックコントローラに設けられるレコーダユニットと
を備え、
前記データ処理装置は、
前記モデル生成手段、分析手段、および前記レポート生成手段を備えることを特徴とする請求項16に記載の分析システム。
【請求項19】
データ処理装置とプログラマブルロジックコントローラとが通信可能なシステムの制御方法であって、
ユーザプログラムを繰り返し実行する工程と、
前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得工程と、
取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成工程と、
取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析工程と、
前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成工程と
を含むことを特徴とするシステムの制御方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は分析装置、分析システム、およびその制御方法に関する。
【背景技術】
【0002】
プログラマブル・ロジック・コントローラ(PLC)はファクトリーオートメーションにおいて製造機器や搬送装置、検査装置などの産業機械を制御するコントローラである(特許文献1、2)。PLCはプログラマーによって作成されるラダープログラムなどのユーザプログラムを実行することで様々な拡張ユニットや被制御機器などを制御する。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特許第5661222号公報
【特許文献2】特開2018-097662号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ところで、PLCの動作やPLCによって制御される産業機械の動作を監視するために、PLCが保持しているデータを収集して活用することが望まれている。PLCは、基本ユニット(CPUユニット)とそれに接続される拡張ユニットとを有している。基本ユニットは、ラダープログラムなどのユーザプログラムを実行することで拡張ユニットを制御する。拡張ユニットは基本ユニットからの命令にしたがって産業機械を制御し、制御結果を基本ユニットに返す。
【0005】
また、これらの制御結果等のデータはトラブル解析や品質管理のために使用される。従って、これらのデータを蓄積して分析し、復旧のために早期に解析結果を得ることが要求されている。しかし、PLCに関連する全てのデバイスのデータを記録する場合は膨大なデータを記憶することになり、さらに異常デバイスを特定するためにはこれらの膨大なデータ(全デバイス)を解析する必要があるため時間を要する作業となる。また、膨大な分析結果から異常デバイスを特定したり、システムを復旧させるためには、経験や知識も必要となる。従って、十分な専門的な知識や経験を必要とすることなく、各デバイスに関連する膨大なデータの中から効率よく分析を行い、分析結果を表示する仕組みが望まれている。
【0006】
そこで、本発明は上記問題に鑑み、各デバイスの分析結果を同期させたレポートを提供することを目的とする。また、他の目的として、レポートを表示する画面において、複数の表示項目を時間軸に連動して操作可能とすることを目的とする。
【課題を解決するための手段】
【0007】
本発明は、たとえば、分析装置であって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段とを備えることを特徴とする。
【発明の効果】
【0008】
本発明によれば、いつもと違う挙動をしたデバイスの情報が同期されてユーザに提供される。
【図面の簡単な説明】
【0009】
図1】PLCシステムを説明する図
図2】PC2aのハードウエアを説明する図
図3】PC2bのハードウエアを説明する図
図4】PLCのハードウエアを説明する図
図5】PCのCPUにより実現される機能を説明する図
図6】PLCのCPUにより実現される機能を説明する図
図7】基本フローを示すフローチャート
図8A】結果表示画面を説明する図
図8B】結果表示画面を説明する図
図9】リレーションマップを説明する図
図10】制御サイクル及び異常点を説明する図
図11】複数の表示項目が時間軸上の操作に応じて連動して更新される様子を示す図
図12】正常時の映像と分析対象の映像との同期を説明する図
図13】モデルの生成フローを示すフローチャート
図14】サイクルパターンの判別制御を説明する図
図15】分析ユニットの結果表示フローを示すフローチャート
図16】PCの結果表示フローを示すフローチャート
図17】ユーザプログラムの編集画面を示す図
図18】サイクルを定義する設定画面を示す図
図19】サイクル未設定の場合の警告を説明する図
図20】PLCシステムの変形例を説明する図
図21】サイクルの処理フローを説明する図
【発明を実施するための形態】
【0010】
以下、添付図面を参照して実施形態が詳しく説明される。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態で説明されている特徴の組み合わせの全てが発明に必須のものとは限らない。実施形態で説明されている複数の特徴のうち二つ以上の特徴が任意に組み合わされてもよい。また、同一または同様の構成には同一の参照番号が付され、重複した説明は省略される。複数の構成を区別するために参照符号の末尾に小文字のアルファベットが付与されることがある。複数の構成に共通する事項が説明される際には小文字のアルファベットが省略されることがある。
【0011】
<システム構成>
はじめにプログラマブルロジックコントローラ(PLC、単にプログラマブルコントローラと呼ばれてもよい)を当業者にとってよりよく理解できるようにするために、一般的なPLCの構成とその動作について説明する。
【0012】
図1は本発明の実施の形態によるPLCシステムの一構成例を示す概念図である。図1が示すように、PLCシステムは、ラダープログラムなどのユーザプログラムを編集するPC2aと、分析結果等を表示するPC2bと、工場等に設置される各種の産業機械を統括的に制御するPLC1と、PLC1に接続されるカメラ等のフィールドデバイス10とを備えている。PCはパーソナルコンピュータの略称である。なお、以下で単にPC2と記載した場合は、PC2aおよびPC2bの構成や制御について説明しているものである。ユーザプログラムは、ラダー言語やSFC(シーケンシャルファンクションチャート)などのフローチャート形式のモーションプログラムなどのグラフィカルプログラミング言語を用いて作成されてもよいし、C言語などの高級プログラミング言語を用いて作成されてもよい。以下では、説明の便宜上、基本ユニット3で実行されるユーザプログラムはラダープログラムと仮定される。PLC1は、CPUが内蔵された基本ユニット3と、1つないし複数の拡張ユニット4を備えている。基本ユニット3に対して1つないし複数の拡張ユニット4が着脱可能となっている。
【0013】
基本ユニット3は、表示部5および操作部6を備えている。表示部5は、基本ユニット3に取り付けられている各拡張ユニット4の動作状況などを表示することができる。操作部6の操作内容に応じて表示部5は表示内容を切り替える。表示部5は、通常、PLC1内のデバイスの現在値(デバイス値)やPLC1内で生じたエラー情報などを表示する。ここでデバイスとは、基本ユニット3や拡張ユニット4に含まれる種々のデバイス(リレー、タイマー、カウンタなど)を含むものであり、デバイス値(デバイスデータ)を格納するために設けられたメモリ上の領域を指すものでもあり、デバイスメモリと呼ばれてもよい。なお、当該デバイスメモリは不揮発性メモリであり、書き換え可能な不揮発性ROMで構成されてもよく、揮発性RAM等をバッテリーバックアップ等により不揮発性を実現してもよい。ROMはリードオンリーメモリの略称である。RAMはランダムアクセスメモリの略称である。デバイス値とは、入力機器からの入力状態、出力機器への出力状態およびユーザプログラム上で設定される内部リレー(補助リレー)、タイマー、カウンタ、データメモリ等の状態を示す情報である。デバイス値の型にはビット型とワード型等がある。ビットデバイスは1ビットのデバイス値、たとえば、0/1、ON/OFF、H/L等を記憶する。ワードデバイスは1ワードのデバイス値を記憶する。以下で詳細に説明されるデータ活用プログラムの収集対象としては、デバイスとして変数が指定されてもよい。変数も情報を保持する保持手段であり、ユーザプログラムに従って実行エンジンによりアクセスされるものである。したがって、以下の説明においてデバイスは変数も指すものである。なお、デバイスを保持するメモリはデバイスメモリと呼ばれてもよい。また、収集されたデータを保持するメモリはデータメモリと呼ばれてもよい。PLC1は、デバイスの他、変数を取り扱うよう構成されてもよく、デバイスや変数のことをシンボルと呼び、シンボルが示す値をシンボル値と呼ぶ。
【0014】
拡張ユニット4はPLC1の機能を拡張するために用意されている。拡張ユニット4には、その拡張ユニット4の機能に対応するフィールドデバイス(被制御装置)10が接続されることがあり、これにより、各フィールドデバイス10が拡張ユニット4を介して基本ユニット3に接続される。フィールドデバイス10は、センサやカメラなどの入力機器であってもよいし、アクチュエータなどの出力機器であってもよい。また、一つの拡張ユニット4に対して複数のフィールドデバイスが接続されてもよい。
【0015】
たとえば、拡張ユニット4bはモータ(フィールドデバイス10)を駆動してワークの位置決めする位置決めユニットであってもよいし、カウンタユニットであってもよい。カウンタユニットは手動パルサなどのエンコーダ(フィールドデバイス10)からの信号をカウントする。
【0016】
分析ユニット4aは、基本ユニット3においてシンボル(デバイス、変数など)からシンボル値を収集し、シンボル値を分析して分析結果を含む分析レポートを作成する。分析ユニット4aは、分析レポートを外部のPC2bへ提供するWebサーバを有していてもよい。基本ユニット3はCPUユニットと呼ばれることもある。PLC1とPC2とを含むシステムはプログラマブルロジックコントローラシステムと呼ばれてもよい。本実施形態では、分析ユニット4aが各デバイスのデータを収集する例について説明するが、当該収集部については基本ユニット3に設けられてもよく、或いは、他の拡張ユニットに設けられてもよい。また、分析ユニット4aは、収集したデータを基本ユニット3からの指示や所定のタイミングに従って分析を行う分析装置として機能することも可能である。なお、本実施形態では、分析ユニット4aが分析装置として動作する例について説明するが、本発明を限定する意図はなく、基本ユニット3が分析装置として機能してもよく、PC2a、2bなどの外部装置が分析装置として機能してもよい。以下で説明されるフロー(フロープログラム)はデータ活用プログラムの一例に過ぎない。基本ユニット3はCPUユニットと呼ばれることもある。なお、PLC1とPC2とを含むシステムはプログラマブルロジックコントローラシステムと呼ばれてもよい。
【0017】
PC2aは主にプログラマーによって操作されるコンピュータである。一方、PC2bは主に現場担当者によって操作されるコンピュータである。PC2bは、ユーザにより画面設定されるプログラマブル表示器であってもよい。この場合、分析結果等を表示する画面はユーザにより画面設定されてもよく、あらかじめWebブラウザ機能が搭載され、Webブラウザ機能により分析結果等が表示されてもよい。PC2aはプログラム作成支援装置(設定装置)と呼ばれてもよい。PC2は、たとえば、携帯可能なノートタイプやタブレットタイプのパーソナルコンピュータ又はスマートフォンであって、表示部7および操作部8を備えている外部コンピュータである。外部コンピュータとは、PLC1の外部にあるコンピュータである。PLC1を制御するためのユーザプログラムの一例であるラダープログラムは、PC2aを用いて作成される。その作成されたラダープログラムは、PC2a内でニモニックコードに変換される。PC2は、USB(Universal Serial Bus)ケーブルなどの通信ケーブル9を介してPLC1の基本ユニット3に接続される。たとえば、PC2aは、ニモニックコードに変換されたラダープログラムを基本ユニット3に送る。基本ユニット3はラダープログラムをマシンコードに変換し、基本ユニット3に備えられたメモリ内に記憶する。なお、ここではニモニックコードが基本ユニット3に送信されているが、本発明はこれに限られない。たとえば、PC2aは、ニモニックコードを中間コードに変換し、中間コードを基本ユニット3に送信してもよい。
【0018】
なお、図1には示していないが、PC2の操作部8には、PC2に接続されたマウスなどのポインティングデバイスが含まれていてもよい。また、PC2は、USBケーブル以外の他の通信ケーブル9を介して、PLC1の基本ユニット3に対して着脱可能に接続されるような構成であってもよい。また、PC2は、通信ケーブル9を介さず、PLC1の基本ユニット3に対して無線通信によって接続されてもよい。
【0019】
<プログラム作成支援装置>
図2はPC2aの電気的構成について説明するためのブロック図である。図2が示すように、PC2aは、CPU11a、表示部7a、操作部8a、記憶装置12aおよび通信部13aを備えている。表示部7a、操作部8a、記憶装置12aおよび通信部13aは、それぞれCPU11aに対して電気的に接続されている。記憶装置12aはRAMやROM、HDD、SSDを含み、さらに着脱可能なメモリカードを含んでもよい。CPUは中央演算処理装置の略称である。HDDはハードディスクドライブの略称である。SSDはソリッドステートドライブの略称である。
【0020】
PC2aのユーザは記憶装置12aに記憶されているプロジェクト編集プログラム14aをCPU11aに実行させて、操作部8aを通じてプロジェクトデータ15を編集する。つまり、PC2aはエンジニアリングツールであり、プログラム作成支援装置として機能する。CPU11aがプロジェクト編集プログラム14aを実行することで、プロジェクト作成部16とプロジェクト転送部17が実現される。プロジェクト作成部16はユーザ入力にしたがってプロジェクトデータ15を作成する。プロジェクト転送部17はプロジェクトデータ15をPLC1に転送する。プロジェクトデータ15は、一つ以上のユーザプログラム(例:ラダープログラム、制御プログラム、モーションプログラム、データ活用プログラム)と、基本ユニット3や拡張ユニット4の構成情報、WebHMIの作画データ、基本ユニット3や拡張ユニット4に備えられた特定機能の設定情報などを含む。構成情報は、基本ユニット3に対する複数の拡張ユニット4の接続位置やデバイスの割り当て情報を含む。基本ユニット3に備えられた機能(例:データ収集機能、通信機能、位置決め機能)を示す情報、拡張ユニット4の機能(例:通信機能、位置決め機能、撮影機能)などを示す情報を含んでいてもよい。作画データは、WebHMIを実現するための表示部品群であり、フロントエンドの構造を記述するマークアップデータ、たとえばHTMLデータ、装飾を記述するスタイルデータ、たとえばCSSデータおよび動的な処理を記述するコード、たとえばJavaScript(登録商標)コードなどにより実現される。装飾を記述するスタイルデータは、たとえばファイル形式として提供されてもよく、構造を記述するマークアップデータ内で外部スタイルデータファイルを呼び出す記述により呼び出されてもよい。動的処理を記述するコードは、たとえばファイル形式で提供されてもよく、構造を記述するマークアップデータ内で外部コードファイルを呼び出す記述により呼び出されてもよい。外部スタイルデータファイルや外部コードファイルを呼び出して使用できる形式のフロントエンドは、再利用性やメンテナンス性が高く、たとえば汎用のフロントエンドコンポーネント等を利用することができる。以下で、作画データは、表示部品と表記される。データ活用プログラムは、PLC1において制御データ(デバイス値など)を収集したり、データ処理したり、WebHMIに渡すためのデータを作成したりするためのプログラムを含む。特定機能の設定情報は、基本ユニット3に備えられた機能(例:データ収集機能、通信機能、位置決め機能)に関する設定情報、たとえば、データ収集機能であれば、データ収集条件やデータ収集対象の設定情報を含み、拡張ユニット4の機能(例:通信機能、位置決め機能、データ活用機能、撮影機能)に関する設定情報等を含む。ここで、プロジェクトデータ15の編集には、プロジェクトデータ15の作成および変更(再編集)が含まれる。ユーザは、必要に応じて記憶装置12aに記憶されているプロジェクトデータ15を読み出し、そのプロジェクトデータ15を、プロジェクト編集プログラム14aを用いて変更することができる。通信部13aは、通信ケーブル9aを介して基本ユニット3と通信する。プロジェクト転送部17は通信部13aを介してプロジェクトデータを基本ユニット3に転送する。通信部13aは、通信ケーブル9bを介して分析ユニット4aと通信する。
【0021】
<ダッシュボードの表示に使用されるPC>
図3はPC2bの電気的構成について説明するためのブロック図である。図3が示すように、PC2bは、CPU11b、表示部7b、操作部8b、記憶装置12bおよび通信部13bを備えている。表示部7b、操作部8b、記憶装置12bおよび通信部13bは、それぞれCPU11bに対して電気的に接続されている。記憶装置12bはRAMやROM、HDD、SSDを含み、さらに着脱可能なメモリカードを含んでもよい。
【0022】
CPU11bはWebブラウザプログラム14dを実行することでWebブラウザ18を実現する。Webブラウザ18は、通信部13bを介して、分析ユニット4aによって提供されるデータ活用アプリケーションの設定ページにアクセスしたり、ダッシュボードのページにアクセスしたりする。またCPU11bは、分析ユニット4aから送信された異常発生時の特定結果(判定結果)を示す画面情報に従って、当該特定結果を表示部7bに表示する。
【0023】
<PLC>
図4はPLC1の電気的構成について説明するためのブロック図である。図4が示すように、基本ユニット3は、CPU31、表示部5、操作部6、メモリ32および通信部33を備えている。表示部5、操作部6、メモリ32、および通信部33は、それぞれCPU31に電気的に接続されている。メモリ32は、RAMやROM、メモリカードなどを含んでもよい。メモリ32はデバイス部34やプロジェクト記憶部35、リングバッファ36、運転記録記憶部37などの複数の記憶領域を有している。
【0024】
ここで運転記録とはPLC1の運転状態をスキャンタイムレベルで記録したものであり、たとえばPLC1の運転に関わる全てのシンボルのシンボル値と収集時刻とを、一スキャン毎に時系列に記録したものである。運転に関わる全てのシンボルとは、たとえばラダープログラム等のユーザプログラムに使用される全てのシンボルであってもよく、ユーザにより選択されるプログラム単位やユニット単位に含まれる全てのシンボルであってもよい。この場合、運転記録の対象となるシンボルをプログラム単位やユニット単位のように有意な単位で一括選択でき、さらに個別にシンボルを加除できるようにしてもよい。これにより、たとえば、トラブル発生時に、トラブル発生時刻の前後においてPLC1の運転に関わる全てのシンボルのシンボル値と収集時刻とを、一スキャン毎に時系列に記録した運転記録を生成し、運転記録に基づきトラブル発生時に何が起きたかを後からでも正確に把握することができる。運転記録には、その時の状況を再現するために多くの情報が含まれるが、情報が多いと運転記録のデータ容量が大きくなり取り回しが難しくなったり、運転記録の収集に負荷がかかったりするため、収集対象となるユーザによりプログラム単位やユニット単位で選択できるようになっている。
【0025】
また、運転記録には、シンボルに加え時系列のカメラ画像が撮像時刻とともに含まれてもよい。これにより、たとえば、トラブル発生時に、トラブル発生時刻の前後に遡って何が起きたかを後からでも正確に把握でき、設備の外観変化を示すカメラ画像も運転記録に含めることでユーザプログラムの時系列と連動してカメラ画像を記録することができる。HMI(ヒューマンマシンインタフェース)やPCなどの外部機器からの書き込み履歴やPLCからの書き込み履歴を変化点イベントとして運転記録に含めてもよい。これにより、たとえば、トラブル発生前後にどのような変化点イベントがあったかを時系列で確認できる。
【0026】
デバイス部34はビットデバイスやワードデバイスなどを有し、各デバイスはデバイス値を記憶する。プロジェクト記憶部35は、PC2aから転送されたプロジェクトデータを記憶する。リングバッファ36は、定期的にデバイス部34からデバイス値を収集して記憶する。運転記録記憶部37は、所定のイベントが発生すると、発生時刻の周辺(発生時刻以前、発生時刻以後、または、発生時刻の前後)に収集されたデバイス値とその収集時刻とを含むイベント記録を記憶する。イベントとは、たとえば、デバイスごとに設定された警報条件または注意条件が満たされたことをいう。警報条件とは、たとえば、PLC1による製造ラインの制御動作を停止すべきような条件をいう。注意条件は、たとえば、PLC1による製造ラインの制御動作について管理者が注意すべきようなデバイス値の条件をいう。CPU31は、PC2aからの要求に応答してイベント記録をPC2aへ送信する。また、CPU31は、リアルタイムでデバイス値をPC2aに提供してもよい。メモリ32は基本ユニット3のCPU31により実行される制御プログラムも記憶する。図3が示すように基本ユニット3と拡張ユニット4とは拡張バスの一種であるユニット内部バス90を介して接続されている。なお、ユニット内部バス90に関する通信機能はCPU31に実装されるが、通信部33の一部として実装されてもよい。通信部33は、USB規格などに準拠したシリアル通信回路を有してもよい。CPU31は通信部33を介してプロジェクトデータをPC2aから受信する。
【0027】
ここで、ユニット内部バス90について、補足説明する。このユニット内部バス90は、入出力リフレッシュに使用される通信バスである。入出力リフレッシュとは、基本ユニット3と拡張ユニット4との間でデバイス値を更新する処理である。入出力リフレッシュは、ラダープログラムが一回実行されるごとに(つまり、一スキャンごとに)、実行される。
【0028】
拡張ユニット4はCPU41とメモリ42を備えている。拡張ユニット4bのCPU41bは、デバイスに格納された基本ユニット3からの指示(デバイス値)にしたがってフィールドデバイス10を制御する。なお、本実施形態において拡張ユニット4bは、カメラ制御ユニットとして機能する。また、CPU41bは、カメラ等のフィールドデバイス10の制御結果をバッファメモリとよばれるデバイスに格納する。デバイスに格納された制御結果は入出力リフレッシュによって基本ユニット3に転送される。また、デバイスに格納されている制御結果は、基本ユニット3からの読み出し命令にしたがって、入出力リフレッシュとは異なるタイミングであっても、基本ユニット3に転送されることがある。メモリ42はRAMやROMなどを含む。とりわけ、RAMにはバッファメモリとして使用される記憶領域が確保されている。メモリ42は、フィールドデバイス10によって取得されたデータ(例:静止画データや動画データ)を一時的に保持するバッファを有してもよい。
【0029】
データ活用ユニット(分析ユニット)として機能する分析ユニット4aのCPU41aは、通信部43と通信ケーブル9bを介してPC2bと通信する。通信部43は、ネットワーク通信を実行する通信回路を含む。CPU41aは、基本ユニット3において収集されたデバイス値を分析することで、分析結果を含む分析レポートを作成する。たとえば、CPU41aは、データ活用アプリケーションとして運転記録分析アプリケーションを実行することにより、運転記録データに含まれるシンボル値を分析することで、非正常シンボルと当該シンボルが非正常となる時刻とを特定し、非正常シンボルと当該シンボルが非正常となる時刻とを対応づけた分析結果を含む分析レポートを作成する。運転記録データは、運転記録の保存イベント発生時刻周辺の状況を再現するための情報を含んでいるため、分析レポートと紐づけて管理されてもよい。また、運転記録データは、運転記録の保存イベント発生時刻周辺の状況を再現するため、多くのシンボルのシンボル値を含むことからデータサイズが大きくなる。このため、たとえば、CPU41aは、運転記録データの中から、分析レポートに必要なデータを読み出して、分析レポート用のデータとして運転記録データに追加保存してもよい。分析レポート用のデータは、もともと運転記録データに含まれていた分析レポートに必要なデータを、そのままコピーしたものを分析レポート用のデータとしてタグ付けして運転記録データに追加保存してもよく、分析レポート用にデータ加工して運転記録データに追加保存してもよい。
【0030】
運転記録データにカメラ画像が含まれると、カメラ画像の再生により運転記録の保存イベント発生時刻周辺の状況をより詳細に把握することができる。分析レポートはカメラ画像を再生するUI(ユーザインターフェース)を含んでもよい。カメラ画像はデータサイズが大きいため、カメラ画像を再生するUIにおいてクリックやスクロール操作を受け付けた時などに必要なカメラ画像データだけを部分的にダウンロードしてもよい。たとえば、CPU41aは、分析レポートを作成する際、カメラ画像を分析レポートにおける表示順序に対応して加工したり、時刻とカメラ画像の保存位置の対応関係を示すインデックス情報を生成し、時刻に対応したカメラ画像を高速かつ部分的にダウンロードできるようにしてもよい。
【0031】
狭義には、分析レポートは、分析結果そのものを意味するが、広義には、分析結果を表示するWebアプリケーションやそのユーザインタフェースを意味することがある。CPU41aは、たとえば、デバイス値が正常範囲内かどうかや、デバイス値が変化するタイミングが正常範囲内かどうかなどを判定する。デバイス値が変化するタイミングが正常範囲内かどうかは、たとえば、デバイス値が“1”(オン)である期間の長さが正常範囲かどうかであってもよい。また、ある工程またはサイクルにおけるデバイス値の変化回数が正常範囲内かどうかが判定されてもよい。あるデバイスから収集されたデバイス値が正常条件を満たしていない場合、そのデバイスは、いつもと違う振る舞いのデバイスであるため、非正常デバイスと呼ばれてもよい。CPU41aは、Web形式の分析レポートを作成し、通信部43および通信ケーブル9bを介して分析レポートをPC2bのWebブラウザに提供してもよい。CPU31がプロトコル変換機能を有している場合、CPU41aは、ユニット内部バス90、CPU31、通信部33および通信ケーブル9aを介して、分析レポートをPC2aに送信してもよい。分析レポートは、グラフ表示部品や数値表示部品などを有してもよい。これらの表示部品は、フロントエンドの構造を記述するマークアップデータ、装飾を記述するスタイルデータおよび動的な処理を記述するコード、たとえばHTMLデータ、CSSデータおよびJavaScript(登録商標)コードなどにより実現される。HTMLはハイパーテキストマークアップ言語の略称である。CSSはカスケーディングスタイルシートの略称である。
【0032】
<PC2bの機能>
図5はPC2bのCPU11bによって実現される機能を説明する図である。PC2bのCPU11bは、Webブラウザプログラム14dを実行することによりWebブラウザ18を実行する。Webブラウザ18はWebアプリケーション61を実行して、通信処理部62、データ取得部63、描画部65、受付部66、および再生部67の機能を実現する。また、Webブラウザ18は、後述する分析ユニット4aのWebサーバ82と、HTTP(ハイパーテキストトランスポートプロトコル)にしたがって通信して表示部品を受信する。
【0033】
Webブラウザ18は、Webアプリケーション61を実行することで分析レポートを表示部7bに表示する。Webアプリケーション61は、たとば、HTMLデータ、CSSデータおよびjava(R)スクリプトなどにより構成される。Webアプリケーション61は、分析ユニット4aから提供されてもよい。通信処理部62は、Webサーバ82との通信を処理する。データ取得部63は、分析レポートに表示すべき運転記録データを分析ユニット4aから取得する。運転記録は、ダウンロードして記憶装置12bに記憶される。描画部65は分析レポートを表示部7bに表示する。連携部64は、分析レポートにおける再生時刻と、運転記録の再生時刻とが同期するように時刻管理を実行する。
【0034】
受付部66は、分析レポートの結果表示画面に対しての操作などを受け付ける。再生部67は、たとえば、受付部66又は連携部64から入力される再生要求に応じて、運転記録データをダウンロードさせて記憶装置12bに保存させる。再生要求には、たとえば、運転記録を特定可能な識別情報(例:固有の識別情報やPLC1における保存パス名)などが含まれていてもよい。再生部67は、記憶装置12に保存されている運転記録を再生して表示部7に表示する。再生部67は、PLC1からリアルタイムで取得される時系列のデバイス値を波形化して表示したり、運転記録に含まれる時系列のデバイス値を波形化して表示したりしてもよい。
【0035】
<PLC1の機能>
図6はPLC1においてCPU31とCPU41aとが制御プログラムを実行することで実現する機能を示している。CPU31においてコマンド処理部71は、PC2a、2bから受信されるコマンドを解釈し、解釈結果に対応した処理を実行する。たとえば、HTTPリクエストをカプセル化して作成された要求信号が受信されると、コマンド処理部71は、要求信号をCPU41aに転送する。要求信号に対する応答信号がCPU41aから受信されると、コマンド処理部71は、応答信号をPC2a、2bへ転送する。コマンド処理部71は分析ユニット4aにも設けられてよい。その場合、PC2aからコマンドについてはコマンド処理部71が処理し、PC2bからのコマンドは分析ユニット4aに設けられたコマンド処理部が処理する。収集部72は、基本ユニット3や拡張ユニット4bからシンボル値(デバイス値や変数に格納された値)を収集してリングバッファ36に格納する。収集部72の収集設定については基本ユニット3および分析ユニット4aの少なくとも一方から行うことができる。ロギング部73は、収集されたシンボル値などに基づき、何らかのエラーまたはトラブル(非正常イベント)がPLC1において生じているかどうかを判定する。たとえば、ロギング部73は、収集されたシンボル値が記録条件を満たしているかどうかを判定してもよい。収集されたシンボル値が記録条件を満たしている場合に、ロギング部73は、当該シンボル値を運転記録74内の稼働ログ76として保存する。ロギング部73は、運転記録を作成したときに実行されていたプロジェクトデータ75も運転記録74内に保存する。さらに、ロギング部73は、運転記録74を作成したことを分析部83に通知する。設定部78は、オペレータの入力に従って後述する学習モデルの生成や、分析、分析レポートの生成に利用する制御サイクルを設定する。制御サイクルは、サイクルの基準となるタイミングを指定することで設定され、制御サイクルの設定をサイクル設定と呼ぶ。たとえば、サイクル設定は、サイクルの開始タイミングを規定するシンボル名と、シンボル値の立上り/立下りのエッジ情報とを含む。また、サイクル設定は、サイクルの開始タイミングを規定するシンボル名と、シンボル値の立上り/立下りのエッジ情報とによるサイクルの開始タイミングの設定情報と、サイクルの終了タイミングを規定するシンボル名と、シンボル値の立上り/立下りのエッジ情報とによるサイクルの終了タイミングの設定情報を含んでいてもよい。設定部78による制御サイクルの設定はCSV等のファイル形式でPLC1に提供され、設定部78がCSV等のファイルを読み出して制御サイクルを設定してもよい。例えば、設定部78によって設定された制御サイクルは、当該サイクルに同期するデバイスを分類して当該分類情報を属性情報としてモデルへ付加したり、分析対象とするデバイスを制御サイクルによって絞ったり、制御サイクルに同期して表示される分析レポートを生成したりするために用いられる。設定される制御サイクルは複数であってもよい。設定方法については後述する。また、制御サイクルは必ずしも設定する必要はなく、たとえば、正常時におけるシンボル値の取り得る値が予め決まっている場合、シンボル値がその予め決まっている取り得る値か否かを判定することで非正常シンボルとして判定することができる。
【0036】
CPU41aにおいてプロトコル変換部81は、PC2bからカプセル化されて転送されてきたHTTPリクエストをプロトコル変換して要求信号からとりだす。プロトコル変換部81は、HTTPリクエストに対してWebサーバ82から送信される応答情報をカプセル化してCPU41aに渡す。プロトコル変換部81は透過的なトンネル(例:TCPトンネル)を提供してもよい。Webサーバ82は、分析部83により作成された分析レポートをPC2bへ提供する。分析部83は、運転記録74内の稼働ログ76を後述するモデルを用いて分析し、分析結果77を作成して、ロギング部73に渡す。分析部83が分析結果77を作成すると、ロギング部73は、プロジェクトデータ75および稼働ログ76に加えて、分析結果77を含む運転記録74に追加する。運転記録74は、運転記録記憶部37に格納される。或いは、分析結果77は分析ユニット4aのメモリ42aに記憶されてもよい。通知発行部84は、分析結果77が発行されると、通知を発行する。この通知は、CPU11bに送信される。
【0037】
たとえば、Webブラウザ18がHTTPリクエストにより分析レポートを要求すると、Webサーバ82はHTTPリクエストをプロトコル変換部81に渡す。HTTPリクエストには、CPU41aで実行され、分析レポートを提供する分析ユニット4a(Webサーバ)のURL(ユニフォームリソースロケータ)が含まれている。プロトコル変換部81は、HTTPリクエストをカプセル化して、所定の通信プロトコルで送信可能な要求信号(コマンド)に変換する。この要求信号は、分析ユニット4aのCPU41aに渡される。CPU41aは、CPU11bに分析レポートを返信する。CPU11bは、分析レポートをWebブラウザ18に渡す。これによりWebブラウザ18は表示部7bに分析レポートを表示する。
【0038】
モデル生成部86は、後に分析部83が運転記録データと比較するためのマスタデータとなるモデルを作成する。レポート生成部85は、分析結果77をPC2bのWebブラウザ18で表示するための表示画面である分析レポートを生成する。分析レポートには、複数の分析結果が含まれるが、それらの分析結果は時間軸上で同期して表示される。分析レポートの詳細については図8Aを用いて後述する。
【0039】
<基本フロー>
図7は、本実施形態に係るモデル生成と、運転記録データの分析および結果出力の基本フローを示す。以下で説明する処理は、基本ユニット3のCPU31および分析ユニット(拡張ユニット)4aのCPU41aによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置(分析装置)によって実行されてもよい。
【0040】
S1で基本ユニット3のCPU31は、PC2aを介して入力された情報に従って、収集部72における収集設定や分析設定を設定する。たとえば、CPU31は、収集設定として、収集対象や収集期間、保存先、ファイル名などを設定することができる。分析設定としては、たとえば分析対象となるサイクルの開始および終了の設定が含まれる。ここでは基本ユニット3が収集設定および分析設定を行う例について説明したが、分析ユニット4aのCPU41aがPC2bを介して入力された情報に従って収集設定を行ってもよい。さらにS1では、基本ユニット3のCPU31が、分析設定として、PC2a、2bの表示部7a、7bに表示された設定画面を介して入力された情報に従って撮影条件等のカメラ設定や画像処理設定、監視項目設定などを設定することができる。なお、これらの分析設定についても分析ユニット4aのCPU41aによって実行することも可能である。その後、S2でCPU31は、S1で設定された収集設定に従って運転記録データを、モデル作成用データとして収集し、運転記録記憶部37へ格納する。より詳細には、収集設定に従って収集された全デバイス値が一旦リングバッファ36へ格納され、リングバッファ36から必要なデータが運転記録データとして運転記録記憶部37へ格納される。
【0041】
次に、S3で分析ユニット4aのCPU41aは、収集された運転記録データを利用してモデルを作成する。当該モデルには、各デバイスのパターンを、定数、ビットパターン、アナログ値などの特徴量に基づいて分類したデバイスごとの情報や、デバイス値が変化するタイミングを示す情報が含まれてもよい。つまり、当該モデルは、各デバイスの正常時の変化パターンが学習される。S3の詳細な処理については図14を用いて後述する。
【0042】
その後、S4で基本ユニット3のCPU31は運転記録データの分析を行うトリガが発生したか否かを判断する。当該トリガは、基本的には運転中にいつもと違う異常が発生した場合をトリガとするものであり、その成立条件として、たとえばエラービットが設定された場合や、監視アプリケーション等のアプリケーションからの所定のイベントの発生、オペレータからの手動による指示の受け付け等が挙げられる。トリガが発生するとS5へ進む。
【0043】
S5で基本ユニット3のCPU31は、各デバイス値を収集して分析を行うための運転記録データを、運転記録記憶部37に保存する。通常、いつもと違う何らかの変化が発生した後にトリガが発生する。従って、ここでは、そのような変化の原因を特定するためにトリガ前後のデータが取得される。上述したように、運転中における全デバイスのデバイス値はリングバッファ36へ保持されている。従って、CPU31はトリガが発生したと判断すると、S1で設定された分析設定に従って、トリガ前後の必要なデバイス値をリングバッファ36から運転記録記憶部37へ格納する。また、S5で分析ユニット4aのCPU41aは、基本ユニット3から分析用の運転記録データを取得する。ここでは、運転記録データに加えて、更にカメラ画像データやイベントの発生履歴、エラー履歴の情報も合わせて取得してもよい。
【0044】
その後、S6で分析ユニット4aのCPU41aは、基本ユニット3で収集された時系列データを取得して、S2で生成されたモデルと比較して分析処理を実行する。分析処理では、各デバイスについて、S3で生成されたマスタデータであるモデルデータと、分析対象の運転記録データとを比較して、対象デバイスがいつもと異なる状態であるかどうかを判断する。所定値以上の差分があればいつもとは異なる状態が検知されていると判断する。さらにCPU41aは判断後の分析結果を基本ユニット3の運転記録記憶部37における分析結果77の記憶領域に、各デバイスごとの分析結果を格納する。ここで分析結果77には、いつもと異なる状態が検知されたデバイスの分析結果とその記録データとが時間情報とともに格納されることが望ましい。これにより、オペレータ等からの分析レポートの生成要求を受け付けた場合にそれらの情報を用いて各デバイス値を同期させて表示可能な分析レポートを容易に作成することができる。なお、拡張ユニット4bから得られるカメラ映像も紐づけて格納してもよい。さらに、S7でCPU41aは、分析結果に基づいて、結果を示す表示データ(分析レポート)を生成し、通信部43を介して生成した表示データをPC2bや外部装置へ送信し、処理を終了する。たとえば、PC2bにおいて分析結果がオペレータに対して表示される。分析レポートを表示した結果表示画面の詳細については図8Aを用いて後述する。
【0045】
監視アプリケーションは、分析ユニット4aのCPU41aにより実行されるデータ活用アプリケーションの一つである。分析ユニット4aは、データ活用アプリケーションを実行する拡張ユニットであってもよい。データ活用アプリケーションは、制御データを収集したりデータ処理したりするデータ活用プログラム(例:フロー)と、データ活用プログラムの実行結果を表示するダッシュボードとを含む。データ活用アプリケーションとしては、監視対象であるデバイスや変数をリアルタイムに監視する監視アプリケーションと、PLC1の運転状態を再現するための運転記録を分析して分析レポートを生成する運転記録分析アプリケーションなどが存在してもよい。また、データ活用アプリケーションとしては、可動率(べきどうりつ)、良品率、または、サイクルタイムなどのKPI(Key Performance Indicator)を算出する算出アプリケーションなどが存在してもよい。監視アプリケーションは、PLC1のシンボルのシンボル値に基づく常時監視するためのアプリケーションで、たとえば監視アプリケーションの設定に応じて1又は複数のシンボルのシンボル値をスキャンタイムレベルで常時収集し、収集したシンボル値に基づく情報をリアルタイムに更新しながら常時表示するアプリケーションである。常時監視の対象となる1又は複数のシンボルは、予めユーザにより設定される。監視アプリケーションは、たとえばWebサーバ機能を有し、通信部43を介して汎用ブラウザから設定が可能である。汎用ブラウザから設定できることにより、プログラム作成支援装置等の専用ツールを介さずに、PC、スマホ、タブレットから設定または監視ができる。また、監視アプリケーションは、常時監視の対象となる1又は複数のシンボルについて正常時における複数のサイクルのシンボル値に基づき当該シンボルに対応する閾値を自動で設定する。たとえば、監視アプリケーションは、ユーザ指示を受け付けて、常時監視の対象となる複数のシンボルについて正常時における複数のサイクルのシンボル値のばらつきに基づき、シンボルの状態を監視するための閾値を一括で自動設定する。閾値は、いつもと違う状態、つまり、非正常状態を監視するように設定され、監視アプリケーションは、監視対象のシンボルのシンボル値が閾値を超えた場合はアラームを発報する。このようにして、たとえば、PLC1は、設備が止まる前に兆候を捉えることができる。PLC1は、監視アプリケーションによる兆候監視の結果、監視対象のシンボルのシンボル値が閾値を超えた場合のアラームを、運転記録の保存条件としてもよい。PLC1は、監視アプリケーションによるアラーム発生をイベントトリガとして、トリガ前後の運転記録データを保存する。PLC1は、運転記録データの保存が完了すると保存完了デバイスをONする。運転記録分析アプリケーションは、運転記録データの保存が完了したことをうけ、自動的に運転記録データを分析してもよい。たとえば、運転記録分析アプリケーションは、保存完了デバイスをONしたことに応じて運転記録データを分析してもよい。運転記録分析アプリケーションは、分析対象となったシンボルのシンボル値(例、全ビットデバイスのデバイス値)を分析して、アラートが出た要因候補のシンボルを抽出する。このようにして運転記録分析アプリケーションは、監視アプリケーションによるアラーム発生の要因をアラーム発生により保存した運転記録データを自動分析し、運転記録データの中からいつもと違うシンボルを抽出する。これにより、CPU41aは、監視アプリケーションの兆候監視機能により設備の状態を常時監視し、変化要因でアラートを発報する。さらに、CPU41aは、アラート要因を自動分析し、いつもと違うシンボルを抽出する。つまり、PLC1は、シンボル値を常時監視することで被制御対象設備の兆候監視をして、アラームにより被制御対象設備が止まる前に兆候を報知して、兆候の要因を自動分析する。
【0046】
<結果表示画面(分析レポート)>
図8Aは、本実施形態に係るWebブラウザ18がWebブラウザプログラム14dを実行することで表示部7bに表示される結果表示画面を示す。ここでは当該結果表示画面800がPC2bの表示部7bに表示される例について説明するが、本発明を限定する意図はなく他の装置の表示部に表示されてもよいし、PLCの拡張ユニットが有するモニタで表示可能であれば当該モニタに表示されてもよい。たとえば、他の装置としてプログラマブル表示器、タブレット、スマートフォンが含まれてもよい。或いは、以下で説明する結果表示画面の内容を含む分析レポートとして他の装置へ電子メール、SNS、FTP転送等で送信されてもよい。分析レポートに対して任意のコメントが付されてもよく、たとえば、分析レポートに対して手書き文字や入力文字コメントが付与されてもよい。この場合、任意のコメントが付与された結果表示画面の内容を含む分析レポートが他の装置へ送信されてもよい。これにより、メールの受信者はコメントなどの現場状況と分析レポートとを合わせて閲覧することができる。また、分析レポートが他の装置へ送信する際、分析レポートとともに当該分析レポートの分析対象である運転記録データが対応付けられて送信されてもよい。これにより、メールの受信者は運転記録と分析レポートとを合わせて閲覧することができる。さらに、PC2bがカメラ付きのタブレットやスマートフォン等であれば、装置の写真も一緒に添付できてもよい。
【0047】
結果表示画面800は、結果をフィルタリングして表示するためのフィルタ801~803と、フィルタ結果804と、検知マップ810と、検知リスト820と、画像表示領域830と、分析コメント840とを含んで構成される。なお、結果表示としては、810、820、830、840のうち少なくとも1つが表示されるものであってよい。フィルタ801は制御サイクルを選択して結果表示をフィルタリングすることができる。ここでの制御サイクルとは、デバイス値の周期的な変化を伴う開始タイミングから終了タイミングまでの期間を称する。フィルタ801を指定すると、選択された制御サイクルで動作するデバイスの分析結果に絞って結果が表示される。フィルタ802は属性情報を選択して結果表示をフィルタリングすることができる。属性情報とは、何れのユニットや通信機器に接続されているかの情報や、入力デバイスであるか否かの情報を示す。
【0048】
フィルタ802においてたとえば「ユニット構成情報」を指定するとユニット構成がポップアップ画面等で表示され、表示されたユニットのいずれかを選択することができる。ユニットが選択されると、当該ユニットに接続されているデバイスに絞って結果が表示される。また、属性情報として「入力デバイス」が指定されると、入力デバイスの属性情報が付加されたデバイスに絞って結果が表示される。フィルタ802は、属性情報を活用するフィルタリングに限られない。たとえば、分析の結果、同じシンボルが重複して非正常シンボルとして検出されることがある。非正常の原因を探るうえで最先の発生時刻が重要となる可能性が高く、フィルタ802は、重複して検出された同じシンボルのうち最先の発生時刻以外をフィルタリングするようにしてもよい。また、フィルタ802は、同じシンボルで、分析時の検知アルゴリズムや後述する異常の種類が同一なもののうち、最先の発生時刻以外をフィルタリングするようにしてもよい。さらに、フィルタ802は、同じシンボルで、分析時の検知アルゴリズムや後述する異常の種類が同一であって、後述するサイクル設定が同一なもののうち、最先の発生時刻以外をフィルタリングするようにしてもよい。
【0049】
フィルタ803はイベントやエラーを選択して結果表示をフィルタリングすることができる。イベントやエラーの種別を指定するとそれに関わりのあるデバイスの分析結果に絞って結果が表示される。たとえば、イベントとして「運転記録保存トリガ」が選択された場合には、その前後の分析結果に絞って結果が表示される。結果表示画面800は、分析結果とともにイベントやエラーを発生時刻順に表示してもよい。この場合、フィルタ803はイベントやエラーをフィルタリングすることができる。これにより分析結果とイベントやエラーの混在表示と、分析結果の表示とを切り換えることができる。ここで、イベントは、たとえば、電源ON/OFF、デバイス値書換、メモリ挿抜などを含み、カテゴリー毎にフィルタリング対象を加除できるようにしてもよい。エラーは、たとえば通信エラー、PLC演算エラー、スキャンタイム超過エラーなどを含み、エラーの重度毎にフィルタリング対象を加除できるようにしてもよい。
【0050】
なお、フィルタ801~803のフィルタ条件は論理積として判断され、該当する分析結果が表示される。従って、フィルタ801~803は必ずしも選択される必要はなく、オペレータが所望するフィルタが選択された場合に分析結果がフィルタリングされてもよい。或いは、オペレータが指定する前にデフォルトでフィルタを選択して分析結果を表示するようにしてもよい。これらの分析結果として表示されるデバイスは、いつもと異なる状態が検知されたデバイスである。いつもと異なる状態とは、たとえば、デバイス値が正常範囲を逸脱したり、デバイス値が変化するタイミングまたは回数が正常範囲を外れたりすることである。製品の製造工場では、日々、同一の製品が大量生産される。つまり、同一の工程が何度も繰り返し実行される。そのため、いつもと異なる状態を検知して表示することは、ラダープログラムを改良したり、生産設備を見直したりするうえで、非常に役に立つ。いつもと同様の状態(正常状態)を定義する正常範囲(正常条件)は、ユーザにより定義されてもよいし、デバイス値の学習結果により定義されてもよい。
【0051】
検知マップ810は、PLC1において実行される複数の工程のそれぞれについて開始タイミングと終了タイミングとを含むサイクルを時間軸に沿って表示する。検知マップ810において、横方向に延びる矩形は、工程が実行中である期間(制御サイクル)を示している。また、矩形内の丸はサイクル内で発生したいつもと異なる状態が発生した異常発生箇所である異常点を示している。検知マップ810の横軸は時間を示し、左端はデータの収集開始時点、右端はデータの収集終了時点を表す。なお、上部の拡大/縮小ボタンを選択することにより、横軸方向の拡大・縮小を行うことができる。その場合の初期表示は、左端がデータ収集開始点、右端はデータの収集終了点であってもよい。或いは、後述するサイクル定義の時間幅で決めてもよい。たとえば、サイクル時間が、10秒、10秒、11秒、9秒、10秒、10秒、20秒である場合に、その中央値の10秒をとり、3サイクル分が一括で表示できるように、左端から右端を30秒としてもよい。ここでは、縦軸をデバイス単位としているが、後述するプログラムモジュール単位としてもよい。また、検知マップ810には、デバイス値に並べて、カメラ映像の特徴量の値を表示するようにしてもよい。デバイス値と並べて表示することにより、映像の周期的な変化を容易に認識することができる。
【0052】
図10に制御サイクル及び異常点の詳細を示す。制御サイクルは、詳細については後述するが開始タイミングと終了タイミングとを設定することで定義することができる。図10には、デバイスMR0と、デバイスMR1とのデバイス値を示す。図10に示すように、制御サイクルを、MR0のOFFからONに変化するタイミングを開始タイミングとし、その後MR1のONからOFFに変化するタイミングを終了タイミングとして設定する。1001に示すように、制御サイクルは矩形形状で表すことができ、左端が開始タイミングを示し、右端が終了タイミングを示す。これによりデバイス値を波形で示すよりも、その制御サイクルを一見して確認することができ、サイクルの動作中であるか否かを判断することができる。なお、本発明はこれに限定されず、開始タイミングと終了タイミングとが識別可能な形状であればどのような形状で表されてもよい。例えば、矩形形状ではなく開始タイミングを示す縦線と終了タイミングを示す縦線とを表示し、その内部を背景色と異ならせることによりサイクルを表現してもよい。また、運転記録データの中に開始タイミングや終了タイミングの記録が無い場合には、それらを示す縦線等を検知マップ810に描画しなくてもよい。1010は定義された制御サイクル内の異常発生箇所を示す。1010の例では、異常が発生した箇所を異常点1011として表示している。一方で、異常には異常開始から終了までの区間がある。1020は異常箇所を区間でプロットした例を示す。1021は異常区間を示す。異常区間1021の表示では、他のデバイスと異常発生区間が重なっている様子を表現することができ、オペレータにとってはデバイス間の関連性を認識することができ、エラーを特定する際に重要な情報となる。このように各デバイスの異常発生箇所については種々の方法で描画することが可能である。
【0053】
検知マップ810において、工程を示す矩形は、左が古く右が新しいことを示す。時刻バー811は、選択中の時刻を示している。時刻バー812は、運転記録データの保存トリガが発生したタイミングを示している。上述したように、運転記録データは保存トリガが発生した前後のデータが記録されているため、時刻バー812の前後にデータが示されている。時刻バー811、812はそれぞれ異なる色で描画したり、実線と破線とで異なるように描画したりすることにより、識別力を向上させてもよい。また、時刻バー811を操作することにより、分析結果の表示を更新することができる。時刻バー811の操作に従って、検知リスト820、画像表示領域830、および分析コメント840の少なくとも1つの後述する時刻バーについても同様に連動して更新され、対応する分析結果が表示されてもよい。
【0054】
図11に複数の表示項目が時間軸上の操作に応じて連動して更新される様子を示す。図11に示すように、例えば検知マップ810上で時刻バー811を点線の位置に操作したとする。当該操作については、例えばPC2bの操作部8bがマウスである場合には、不図示のポインタを時刻バー811に合わせてドラッグし、ドラッグした状態でポインタを点線の位置に移動操作することにより時刻バー811を移動させることができる。移動させると、検知マップ810及び検知リスト820の表示が、検知マップ1110及び検知リスト1120に示すように更新される。例えば、時刻バー1111の位置に連動して、当該位置から発生したいつもと異なる状態のデバイスが検知リスト1120に表示される。このように、何れかの分析結果に表示される時刻バーを操作することにより、それに連動して他の分析結果の表示を更新することにより、オペレータは有用な情報を容易に把握することができる。また、検知リスト上で所定の異常項目を選択すると、検知マップ上においてその異常項目が発生したタイミングに時刻バーが移動するように制御してもよい。検知マップや検知リスト上での選択に応じて、画像表示領域830においてその際のカメラ画像が表示されてもよい。或いは、カメラ映像の再生に合わせて検知マップや検知リストが連動して表示を更新してもよい。なお、一部の分析結果は固定して、他の分析結果のみをオペレータの操作に合わせて連動して表示更新を行うようにしてもよい。この場合、例えば固定したい分析結果の時刻バーをダブルクリックするなどして固定操作可能にしてもよい。
【0055】
画像表示領域830は、PLC1において取得されたカメラ画像(以下では、カメラ映像とも称する。)を表示する。図8Aでは、正常時のデータであるマスタデータのカメラ画像と、今回のカメラ画像とが対比可能に表示されている。カメラ画像も時系列データであるため、シークバー831は、カメラ画像の再生時刻を示し、再生時刻の経過にしたがって左から右に移動する。時刻バー832は、検知対象デバイスがいつもと異なる状態になったタイミングを示しており、上述した時刻バー811と連動している。時刻指定部833は、カメラ画像の再生時刻を進めたり、再生時刻を戻したり、再生の開始を指示したり、再生を停止したりすることを指示するためのコントロールオブジェクトである。834は制御サイクルを指定することができ、指定されたサイクルを基準サイクルとしてカメラ映像が再生される。例えば、時刻指定部833の早送りのボタンが操作されると、現在の制御サイクルの次の制御サイクルまで映像がスキップするように制御される。また、サイクルの終了時にジャンプするものであってもよい。
【0056】
カメラ映像は、運転記録データとして保持されてもよいが、時刻が関連付けられた、外部機器に保存されているデータであってもよい。例えば、拡張ユニットの何れかに接続されたWebカメラに記録されているカメラ映像であってもよいし、画像検査機に記録されている検査画像であってもよい。外部機器に保存されているデータは、画像以外にも測定器の記録データであってもよく、数値であったり、測定波形が表示されるものであってもよい。なお、結果表示画面800において、検知マップ810の再生時刻、カメラ画像の再生時刻、および、検知リスト820の再生時刻は同期するように管理され表示されている。また、図8Aの点線領域に示すように、検知した異常箇所を映像中において強調表示してもよい。これにより、ユーザはさらに容易に正常時の映像と、今回の映像を対比することができる。
【0057】
図12に正常時のマスタデータの映像と分析対象の映像との同期について示す。カメラの映像は、学習時の映像と今回の映像を、選択された基準とするサイクル定義の、サイクル開始タイミングを合わせて表示している。例えば、次のようにすることで同期を実現することができる。まず、カーソルの現在時刻が含まれる制御サイクルを探し、そのサイクル開始時刻からのオフセット時間tを求める。図12の例では今回の映像の実線の矩形領域が取得した運転記録データに対応したデバイスの制御サイクルを示し、点線の矩形領域が定義された基準サイクルを示す。次に、学習時の映像のサイクル開始タイミングを合わせて、並べて、サイクル開始から時間tずらした映像を表示する。基準とするサイクルを変えれば、学習時の映像が変わる。学習時の映像の中に、基準とするサイクル定義のサイクル開始が複数あれば、最初の方を表示してもよいし、選択可能としてもよい。このように、基準サイクルに合わせて今回の映像とマスタデータの映像とを同期することができる。
【0058】
検知リスト820は、いつもと異なる状態になったデバイスと、その状態が発生した時刻(デバイス値の収集時刻)とを示す。検知リスト820は、いつもと異なる状態となったデバイスを時刻順に示したリストである。CPU11bは、検知リスト820に表示されたデバイスに対するクリックを検知すると、クリックされたデバイスの識別情報と、再生時刻情報(デバイス値の収集時刻)とに基づいて、検知マップ810、検知リスト820、および画像表示領域830の表示を同期させることができる。時刻バー821は、選択中の時刻を示しており、時刻バー811、831と連動し、同一のタイミングを示している。時刻バー822は、運転記録データの保存トリガが発生したタイミングを示している。
【0059】
分析コメント840は、分析結果に含まれるコメントと、検知リスト820で選択されたデバイスについての、マスターデータと、今回のデバイス値の時系列データとを表示する。時刻バー841は、いつもと異なる状態が発生したタイミングを示し、時刻バー811、821、831と連動し、同一のタイミングを示している。表示されているコメントは、当該デバイスの異常の内容を示している。
【0060】
CPU11bは、検知リスト820に表示されたデバイスに対するクリックを検知すると、クリックされたデバイスの識別情報と、いつもと異なる状態になったサイクル情報(サイクルの開始時刻と終了時刻、または、サイクルの開始時刻と次のサイクルの開始時刻)とに基づいて、検知マップ810、検知リスト820、および分析コメント840の表示を同期させることができる。図8Bは、検知リスト820の何れかの項目が選択された場合に、検知マップ810、検知リスト820、および分析コメント840を同期させた様子を示す。分析コメント840は、いつもと異なる状態になったサイクルに対応した時間範囲のデバイス値の時系列データを表示する。このとき、検知マップ810上には、分析コメント840に表示された時系列データの時間範囲854に対応する時間範囲852が図示される。検知マップ810に図示される時間範囲852は、複数の工程のうちいつもと異なる状態になった工程に対応して図示される。たとえば、検知リスト820に表示されたデバイスのうち、現在と異なるデバイスの項目853がクリックされると、クリックされたデバイスについて、いつもと異なる状態になったサイクルに対応した時間範囲のデバイス値の時系列データに切り替わる。その際、検知マップ810上では、分析コメント840に表示された時系列データの時間範囲854に対応する時間範囲852を含む範囲に表示が切り替わる。また、矢印855で示すように、検知マップ810上において、点線や色付きの実線の枠などによって時間範囲852が強調表示され、分析コメント840における切り出し区間との対応が確認できるように表示される。これにより、分析コメント840が検知マップ810上のどの区間を切り出した波形かをオペレータに容易に把握させることができる。また、854に示すように、分析コメント840においても波形の下部に、切り出した区間に対応するサイクルを示す矩形や異常点を表示することにより、サイクルの開始タイミングや、終了タイミングと波形や異常との関係をオペレータに容易に把握させることができる。また、検知マップ810は、851に示すように、検知リスト820で選択されたデバイスに対応する異常点を拡大表示してもよい。また、分析コメント840に表示された時系列データの時間範囲が、サイクルの開始時刻と次のサイクルの開始時刻の場合、分析コメント840には、時系列データの時間軸に対応して、サイクルの終了時刻を示す位置に図式表示がされてもよい。
【0061】
このように、結果表示画面800は検知マップ810、検知リスト820、画像表示領域830、および分析コメント840など複数の分析結果の表示を含んで構成される。しかし、これらの結果表示は一例であり他の結果表示が追加的に又は代替的に含まれてもよい。たとえば、図9に示すように、分析結果として、デバイス間の依存情報(リレーションマップ)を表示してもよい。基本ユニット3は、ラダープログラムを解析することで、デバイス・変数間の依存関係を把握することができる。たとえば、ある検知されたデバイスを選択されると、それに関係するデバイスも並べて表示するなど、依存関係のあるデバイスをオペレータへ提示することができる。これにより、オペレータに対して異常の把握や特定を支援することができる。
【0062】
<リレーションマップ>
図9はリレーションマップ900を示している。リレーションマップ900は、ラダープログラム等のユーザプログラムにおいて、特定のシンボルに関連するプログラムモジュールと、そのプログラムモジュールに関連する他のシンボルとの関係を示す図式表示であり、たとえば、特定のシンボルとして、ラダープログラムに使用されるいつもと異なる状態になったデバイス(非正常デバイス)を選択した場合は、当該非正常デバイスに対してラダープログラムにおいてプログラムモジュールを介して関連している他のデバイスを表示するUIとなる。このUIは結果表示画面800において不図示の表示ボタンを操作することにより遷移する画面であってもよいし、結果表示画面800上に追加で表示されてもよい。リレーションマップを表示することにより、ユーザは、非正常デバイスと他のデバイスとの依存関係を容易に理解できる。一般に、PLC1において利用されるデバイスの数は数百から数万であるため、ユーザは、いつもと異なる状態になったデバイスから、その原因となったデバイスを特定することは容易ではない。CPU11は、非正常デバイスについてラダープログラム内を検索し、非正常デバイスに関する記述を発見し、当該記述を分析することで、関連デバイスを特定する。この例では、ラダープログラム内の出力部において、非正常デバイス(例:R0004)が記述されており、関連デバイスとしてMR000、MR001、MR002が存在する。
【0063】
CPU11bは、ラダープログラムから特定した非正常デバイス、関連デバイスおよびプログラムモジュールをツリーのように表示する。ユーザプログラム(ラダー、C言語、フロー言語、スクリプトなど)は、可読性やメンテナンス性向上のために、いくつかに分けて記述することが多く、その単位をプログラムモジュールと称する。1つのプログラムモジュールの中では、各デバイスを読み書きするプログラムが記述され、1つのデバイスは複数のモジュールで読み書きされることもあるが、主に使用されるモジュールは1つであることが多い。図9の例では、出力部における演算のために入力されるデバイスが左側に表示され、プログラムモジュールが真ん中に表示され、その右側に非正常デバイスが表示されている。図9が示すように、リレーションマップ900上のプログラムモジュールが選択されると、CPU11bは、該当するプログラムモジュールをプログラム表示領域910に表示してもよい。なお、ここではPC2bのCPU11bが表示処理を制御する例で説明しているが、一例でありPC2aのCPU11aで行われてもよい。また、上述した検知マップ810についても、デバイス単位ではなくプログラムモジュール単位で表示するようにしてもよい。
【0064】
CPU11は、シンボルを特定するユーザ指定に応じて、ユーザプログラムからシンボルに関連するプログラムモジュールを特定し、特定したプログラムモジュールに関連する他のシンボルを特定して、リレーションマップ1500を生成する。CPU11は、分析結果に基づいてリレーションマップ1500内に含まれる非正常デバイスを強調表示する。分析結果は非正常デバイスがいつもと異なると判断した時刻も含んでおり、CPU11は、再現する時刻よりも前に発生した非正常デバイスのみをリレーションマップ1500上で強調表示するようにしてもよい。これにより非正常デバイスは、いつもと異なる状態が発生して以降、強調表示が保持されることになる。また、分析結果には、各シンボルのうち、分析対象外のシンボルであることを示す情報が含まれてもよい。この場合、CPU11は、分析結果に基づいてリレーションマップ1500上で分析対象外のシンボルと他のシンボルと色などを区別して表示する。これにより、分析により非正常でないと判断したのか、未分析のため非正常と判断されなかったのかを区別できる。分析対象外のシンボルとは、たとえば、制御サイクルやサイクル設定により定義されるサイクルに対し、シンボル値の変化パターンが規則性を持たないシンボルであったり、ユーザにより分析対象外として指定されたシンボルを含む。
【0065】
<モデル生成フロー>
図13は、上記S3におけるモデル生成フローの詳細を示す。ここでは、デバイスの属性情報としてデバイスの制御サイクルを判断してモデルを生成する制御について説明する。なお、本発明はこれに限らず上述した他の属性情報に基づいてモデルを生成してもよい。以下で説明するように、分析ユニット4aは複数の同期しない工程(サイクル)のデータであっても、自動で工程(サイクル)に属するデバイス・変数を抽出する。これにより、オペレータが予め手動で工程(サイクル)とデバイスとの紐づけを行う非常に手間となる作業を省略することができる。以下で説明する処理は、分析ユニット(拡張ユニット)4aのCPU41aによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置(分析装置)によって実行されてもよい。
【0066】
まずS31で分析ユニット4aのCPU41aは、基本ユニット3からモデル作成用の正常時の運転記録データを取得する。当該運転記録データは、上記S2で運転記録記憶部37に格納されたデータである。続いて、S32でCPU41aは、デバイス値以外の情報として、基本ユニット3からサイクル設定の情報を取得する。サイクル設定の情報は、たとえばPC2aを介してオペレータから設定されたサイクルパターンの情報を示す。たとえば、サイクルの開始タイミングとサイクルの終了タイミングとを示す。また、ここで取得する情報には、拡張ユニット4bに接続されたカメラ等のフィールドデバイス10で取得された情報、たとえばカメラ画像データなども含まれてもよい。これらのデータについては基本ユニット3を介して取得してもよいが、たとえば拡張ユニット4bなどから直接取得するようにしてもよい。
【0067】
次に、S33でCPU41aは、S32で取得したサイクル設定に基づき、各デバイスが何れのサイクルに属するかを判定する。各デバイスのサイクルパターンには種々のパターンが存在するものであり、ここでは各デバイスがサイクル設定で指定された何れのパターンに属するデバイスであるかを判断する。サイクル設定が複数の制御サイクルに対応した設定を含む場合、各制御サイクルに属するデバイスを判定するようにしてもよい。このとき、複数の制御サイクルに属すると判断されるデバイスが存在してもよい。図14は、各デバイスのサイクルパターンを判別する制御について示す。図14において、矩形は工程が実行中である期間(サイクル)の開始タイミングから終了タイミングまでを示しており、1つの矩形が1サイクルを示す。サイクルパターンとはこの1サイクルが出現するパターンである。1401~1403はサイクル設定された工程を示す。1404~1406はそれぞれデバイスA~Cの収集データから抽出したサイクルパターンを示す。分析ユニット4aは各デバイスについて何れのサイクル設定のパターンに属するかを判断し、たとえばデバイスAがサイクル設定1に属し、デバイスBがサイクル設定2に属し、デバイスAが設定された何れのサイクル設定にも該当しないと判断する。具体的には、サイクル開始から終了までの、値と変化回数が一致しているかを判定している。なお、開始タイミングや終了タイミングについては多少ずれても問題ない。このように、分析ユニット4aは、各サイクル設定のパターンと各デバイスとがどのような対応関係かを判定する。分析ユニット4aは各サイクル設定のパターンについて何れのデバイスが属するかを判断するようにしてもよい。
【0068】
分析ユニット4aは、各サイクル設定のパターンと各デバイスとがどのような対応関係か判定する際に、各サイクル設定のサイクル開始からサイクル終了までにおける各デバイス値のパターンに基づいて判定する。これにより、サイクルの終了から次の開始までデバイス値がどのような動作をしても、そのデバイスを当該サイクル設定のパターンに属すると判断することができる。また、分析ユニット4aは、各サイクル設定のパターンと各デバイスとがどのような対応関係か判定する際に、各サイクルの基準タイミングから次のサイクルの基準タイミングまで、たとえばサイクル開始から次のサイクル開始までのデバイスの値と変化回数が一致しているかで判定してもよい。
【0069】
PLC1において実行される複数の工程のそれぞれについて開始タイミングと終了タイミングとを含むサイクル、つまり、工程が実行中である期間を制御サイクルはサイクル設定の対象とされているが、サイクル設定の対象はこれに限られない。図21は、開始タイミングから終了タイミングの期間以外にも変化するデバイスが存在する場合のサイクルの処理フローを示す。図21に示すように、作業工程を実行するために、作業工程を実行するための準備として作業開始条件を満足しているかを確認する確認フェーズ2101が存在してもよく、また、作業開始フェーズ2102、作業フェーズ2103、及び作業終了フェーズ2104の作業工程の実行後には次の工程の準備をする準備フェーズ2105、次の工程まで待機する待機フェーズ2106等が存在してもよい。このため、作業工程の実行中以外の期間においても変化するデバイスは存在し、異常要因を突き止めるための手がかりとなり得る。たとえば、確認フェーズにおいて作業開始条件の成立に関連する入力デバイス、準備フェーズにおいて次の準備の制御信号を示すデバイスなどは、開始タイミングから終了タイミングまでの期間以外の期間で動作するため、これらのデバイスの分析結果は、異常要因を突き止めるための手がかりとなり得る。要するに、サイクル設定の対象は、サイクルの基準タイミングから次の基準タイミングまでであってもよく、これにより隙間なく分析することができる。また、サイクル設定では、ユーザにより開始タイミングを規定するデバイスと、終了タイミングを規定するデバイスとが選択されたり、正常時の運転記録データなどを学習することで自動的に設定されたりする。しかし、分析対象の期間が開始タイミングから終了タイミングに限定されると、工程の開始を規定するデバイスや工程の終了を規定するデバイスを正確に把握していない場合、そのようなデバイスを見つけ出すことは困難なことがある。サイクル設定の対象をサイクルの基準タイミングから次の基準タイミングまでとすることで、工程の開始を規定するデバイスや工程の終了を規定するデバイスを厳密に指定しなかったとしても、工程に同期するデバイスを選択するだけで隙間なく分析することができる。
【0070】
図13の説明に戻る。S33でCPU41aは、抽出したサイクルパターンを属性情報として各デバイスに付加する。次に、S34でCPU41aは、付加された属性情報に基づいてS31で取得した運転記録データからモデルを生成し、処理を終了する。生成したモデルは、分析時に利用するマスタデータであり、少なくとも各デバイスのサイクルパターンの情報が含まれる。
【0071】
<結果表示フロー>
図15は、上記S7における分析ユニット4aによる結果表示フローの詳細を示す。以下で説明する処理は、分析ユニット(拡張ユニット)4aのCPU41aによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置(分析装置)によって実行されてもよい。
【0072】
まずS71で分析ユニット4aのCPU41aは、分析レポートの要求を受け付けたか否かを判断する。分析レポートの要求とはオペレータによってPC2a、PC2bを介して受信する要求や、定期的な分析レポート作成タイミング、エラー発生時の分析レポートの作成などが含まれる。PLC1としては、いつもと異なる状態のデバイスが検知された場合にはオペレータからの要求なしに分析レポートを作成してもよいし、オペレータからの要求があって初めて分析レポートを作成するようにしてもよい。これらの制御は設定で切り替えることができる。分析レポートの要求を受け付けていればS72に進む。
【0073】
S72でCPU41aは、基本ユニット3の運転記録記憶部37に格納された分析結果77を取得する。続いて、S73でCPU41aは、取得した分析結果に従って、PC2aやPC2bなどのWebクライアントのWebブラウザで表示可能な分析レポートを生成する。生成する分析レポートは図8Aを用いて上述した結果表示画面800を表示するための画面情報となる。ここでは、各分析結果を同期させて表示するための同期情報も付加される。具体的には、検知マップ810、検知リスト820、画像表示領域830、及び分析コメント840に表示する画面情報に加えて、各分析結果の表示位置を示唆する情報が含まれる。表示位置を示唆する情報とは、上述したように、定義された制御サイクルのタイミング情報であってもよいし、単なる時刻情報であってもよい。即ち、同期可能な情報であればよい。
【0074】
次に、S74でCPU41aは、S73で生成した分析レポートを要求元のPC2へ送信する。ここで送信する情報は、HTMLデータ、CSSデータおよびJavaScript(登録商標)コードなどを含む情報であってもいし、単に分析レポートの生成が完了したことを示す通知であってもよい。通知を行う場合には改めてPC2側から表示要求を受け付けると、CPU41aは画面情報を送信する。その後、S75でCPU41aは、要求元から分析レポートの更新要求が受け付けたか否かを判断する。更新要求とは、例えば表示部品の変更や、フィルタ801~803の選択による表示対象の変更、時刻バー811などを操作したことにより分析結果の時間的な表示位置の更新などである。なお、時刻バー811などを操作したことによる表示内容の更新については、PC2側に閉じた制御としてもよい。この場合、表示対象となっている表示部品の情報に加えて、当該表示部品上で表示しているデバイスの分析結果についての情報もPC2側へ提供する必要がある。更新要求を受け付けるとS76に進み、そうでない場合はS77に進む。
【0075】
S76でCPU41aは、更新要求の指示内容に従って分析レポートを更新し、処理をS74へ戻し更新した分析レポートを要求元へ送信する。一方、S77でCPU41aは、分析レポートの表示を終了する終了指示を受け付けたか否かを判断する。終了指示を受け付けていない場合は処理をS75に戻し、終了指示を受け付けたと判断した場合は処理を終了する。
【0076】
図16は、上記S7におけるPC2bにおける結果表示フローの詳細を示す。以下で説明する処理は、PC2bのCPU11bによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部がPLCのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された他の外部装置(PC2aなど)によって実行されてもよい。PLCのユニットで実行される場合には当該ユニットにはモニタが設けられる。また、ここで説明する処理は、分析ユニット4aによって生成された分析レポートをブラウザとして表示する処理である。
【0077】
S81でCPU11bは、操作部8bを介して分析レポートの表示要求を受け付けたか否かを判断する。受け付けた場合にはS82に進む。S82でCPU11bは、分析レポートを分析ユニット4aに対して要求する。その後、S83でCPU11bは、分析ユニット4aから要求に対応する応答(分析レポート)を受信したか否かを判断する。ここで受信する情報としては、分析レポートを表示させるためのURL(IPアドレス)であってもよいし、分析レポートそのものの情報であってもよい。ここではURLを受信したものとして以下の処理を説明する。
【0078】
応答を受信するとS84でCPU11bは、Webブラウザ18に指定して分析レポートを表示させる。続いて、S85でCPU11bは、分析レポートの表示を更新する更新要求を受け付けたか否かを判断する。受け付けた場合はS86へ進み、そうでない場合はS87へ進む。S86で、更新要求を受け付けるとS86でCPU11bは、更新要求をWebサーバである分析ユニット4aへ送信し、処理をS83に戻す。一方、更新要求でない場合はS87でCPU11bは、分析レポートの表示を終了する終了指示を受け付けたか否かを判断する。終了指示を受け付けていないと判断した場合は処理をS85へ戻し、終了指示を受け付けたと判断した場合は処理を終了する。
【0079】
<プログラムエディタとの連携>
図17はユーザプログラムの編集画面であるプログラムエディタを示す。ここではプログラムエディタからの分析レポートの表示方法について説明する。プロジェクト編集プログラム14aのUI100はPC2aの表示部7aに表示される。したがって、基本ユニット3に接続されたPC2aからも分析レポートを確認することができる。一方、PC2bがPC2aから基本ユニット3及び分析ユニット4aを介して画面情報を取得してプログラムエディタを表示部7bに表示することも可能である。モード選択メニュー101は、プロジェクト編集プログラム14aが備える複数のモードを選択可能に表示する。複数のモードは、編集モード、モニタモード、リプレイモード(デバッグモード)などを含む。
【0080】
編集モードは、プログラム表示領域104に表示されるラダープログラムを編集するモードである。プロジェクト表示領域102は、プロジェクトを構成する情報を表示する。この情報としては、PLC1を構成している基本ユニット3および拡張ユニット4の仕様情報および設定情報、デバイスの割り当て情報、運転記録の設定情報、ラダープログラムなどがある。編集モードにおいて、プログラム表示領域104は、プロジェクト表示領域102において指定されたラダープログラムを編集可能に表示する。モニタモードは、PLC1により発行される通知を待ち受けるモードである。拡張ユニット4aが分析結果を作成したことを示す通知を発行すると、CPU11は、通知を表示するためのダイアログなどを表示部7に表示する。モニタモードのユーザインタフェースは、基本的に、編集モードと同様である。
【0081】
図17が示す画面例ではリプレイモードが選択されている。リプレイモードは、運転記録をラダープログラム上で再現したり、運転記録を波形として表示したりするモードである。図17においては、入力部、出力部および加工部状態と命名されたプログラムモジュールを有するラダープログラムが表示されている。とりわけ、複数のプログラムモジュールはタブ107によって選択可能であり、図17では、入力部に対応するタブ107が選択されている。ポインタ103は、操作部8aに対するユーザ操作に連動して移動し、ボタンなどを押し下げするために使用されたり、オブジェクトを選択したりするために使用される。たとえば、プロジェクト表示領域102において表示された分析レポートがポインタ103によりダブルクリックされると、CPU11aはCPU11bと同様にWebブラウザとして機能し、図8Aを用いて説明した分析レポートを表示させる。
【0082】
リプレイモードでは、プログラム表示領域104に、運転記録に含まれているデバイス値がラダープログラム上に表示される。リレーデバイス(ビットデバイス)の場合、デバイス値が0であるか、1であるかが視覚的に区別可能に表示される。視覚的に区別可能とは、異なる色による表示や異なるアイコンの表示を含む。ワードデバイスの場合、たとえば、デバイス値が10進化されて表示されてもよい。
【0083】
デバイス値は時間とともに変化しうる時系列データであるため、各デバイス値は、収集された時刻を示す時刻情報に紐づけられている。シークバー105aは、デバイス値の再生時刻を示すとともに、再生時刻を指定するためにポインタ103により操作されることがある。運転記録の再現中は、再生時刻の経過に連動して、シークバー105aが左から右へと移動する。時刻指定部106aは、再生時刻を進めたり、再生時刻を戻したり、再生の開始を指示したり、再生を停止したりすることを指示するためのコントロールオブジェクトである。
【0084】
<サイクル設定>
図18は、サイクルを定義する設定画面1800を示す。設定画面1800は、例えばPC2aの表示部7aに表示中のUI100から所定の操作が行われた場合に表示部7aに表示される画面である。図18に示すように、UI100上に表示されているプログラムエディタに重畳して表示されてもよいし、UI100に表示されているプログラムエディタから遷移する画面として表示されてもよい。なお、設定画面1800はPC2b上のWebブラウザ18上で表示されてもよい。
【0085】
設定画面1800には、運転記録分析を行う際のアプリケーションやアプリケーション名を指定する設定領域1801、1802が含まれる。これらの設定領域1801、1802は分析対象を設定するためのものである。図18にはデフォルトの設定が示してあり、オペレータは特に設定しなくてもよい。さらに、設定画面1800には基本設定の領域が有り、ここで制御サイクルを指定することができる。1803は制御サイクルの指定方法を設定し、1804はサイクル名を設定し、1805は開始トリガを設定し、1806は終了トリガを設定することができる。また、デフォルトでは制御サイクルは指定されておらず、追加ボタン1807のみが表示されている。
【0086】
図18に示す例では、No.0,1,2の制御サイクルが既に指定されている状態を示す。本実施形態によれば、このように分析対象となる制御サイクルとして、1以上の制御サイクルを指定することができる。したがって、オペレータは広範囲に分析したい場合においては、複数の制御サイクルを指定することでより意図した分析レポートを確認することができる。指定方法1803は制御サイクルの起点となる開始タイミング及び終点となる終了タイミングを指定する開始・終了指定と、開始タイミングのみを指定する開始指定を選択することができる。したがって、終了トリガ1806は開始・終了指定が選択された場合にのみ終了タイミングを指定することができる。ここでは、各サイクル定義毎に、所属するデバイスやデバイスのグループを設定していない。したがって、分析ユニット4a等が定義された制御サイクルに対応するデバイスを特定して分析を行うことになる。複数の制御サイクルを指定可能であるため、1つのデバイスが複数の制御サイクルに対応する可能性もある。この場合においては、分析対象として前述の信頼度や、サイクルの開始と終了とのバラツキが小さいことを使用して自動的に優先度をより高く設定するようにしてもよい。当該優先度が高ければ分析レポートにおいて優先的に表示または絞って表示するようにしてもよい。一方で、特定のデバイスを各サイクル定義に紐づける設定を行えるようにしてもよい。
【0087】
設定画面1800にはさらに、設定保存1811、設定読出1812、OKボタン1813、及びキャンセルボタン1814を含んで構成される。設定保存1811は設定画面1800内で設定された設定内容を保存するためのボタンである。設定読出1812は基本ユニット3のメモリ32のプロジェクト記憶部35に予め保持されている設定ファイルを読み出すためのボタンである。当該設定ファイルには、1以上の制御サイクルが予め指定されている。当該設定ファイルを読み出した後に、さらに制御サイクルを追加することも可能である。OKボタン1813は設定画面1800上に設定されている内容を有効にして設定処理を終了するためのボタンである。キャンセルボタン1814は設定画面1800上に設定されている内容を適用することなく設定処理を終了するためのボタンである。
【0088】
<サイクル未設定>
図19はサイクル未設定の分析レポートの検知マップ810を示す。分析ユニット4aはサイクル未設定であっても分析は可能であるが、分析可能なデバイスは極端に少ない。つまり、サイクルパターンを有していないデバイスに限られる。サイクルパターンを有していないデバイスとは、たとえばデバイス値が固定値で変化しないデバイスである。たとえば、図19の1901に示すように、常時ONや常時OFFのデバイスはサイクルが未設定であっても分析を行うことができる。一方、所定のサイクルパターンを有するデバイスについてはサイクルが未設定であれば分析を行うことができない。このように、分析可能なデバイスが少ないため、サイクルが未設定の場合も分析自体は可能であるものの、分析結果の有効性は限定的である。したがって、図19に示すように、分析レポートにおいて、サイクルが未設定である旨と、サイクル設定を促すメッセージ1902を表示するようにしてもよい。「サイクル設定して分析する」が選択されるとサイクル設定のポップアップ画面が表示され、オペレータはサイクル設定を行うことができる。
【0089】
<変形例>
本発明は上記実施形態に限らず様々な変形が可能である。以下では種々の変形例について図面を参照して説明する。
【0090】
<システム構成の変形例>
図20はPLCシステム構成の変形例を示す。上記実施形態では、PLCシステムとして、基本ユニット3、分析ユニット4a、およびカメラユニットなどの拡張ユニット4bで構成されるPLC1と、基本ユニット3に接続されるPC2aと、分析ユニット4aに接続される分析レポートを表示するPC2bとを含んで構成される例について説明した。しかし、これらの構成は一例であって、上述した運転記録データの収集、モデルの生成、分析、分析結果の表示については何れの装置やユニットで行われてもよいし、さらに他の外部装置や他の拡張ユニットによって実現されてもよい。ここではそのような構成の変形例について説明する。
【0091】
たとえば、図20に示すように、上記実施形態に係る分析ユニット4aの機能をPLC1の上位層に配置される分析装置(サーバ装置として機能する)2cで実現してもよい。モデルの学習フェーズの処理などは非常に処理負荷が高く、処理時間を要するものであるため、PLCユニットの処理能力に応じて外部で実現することも想定され得る。また、上位層の装置に分析機能を設けることにより、他のPLCからも情報を吸い上げることもでき、より信頼度の高いモデルを生成することも可能となる。分析装置2cは、PLC固有情報の解析、モデルの生成、分析、分析レポートの作成などの機能を有する。これらの機能については、分析ユニット4aと同様の処理であるため説明を省略する。
【0092】
また、上記実施形態では、基本ユニット3が全デバイスの運転記録データを収集していたが、他の拡張ユニットで行ってもよい。たとえば、図20に示すように、拡張ユニットとしてレコーダユニット4cを設けてもよい。レコーダユニット4cはCPU41cと、メモリ42cと、通信部43cとを備える。メモリ42cには、上記実施形態で基本ユニット3に設けられていたリングバッファ44cと、運転記録記憶部45cとの記憶領域が設けられる。運転記録の収集については、上記実施形態の基本ユニット3と同様の処理であるため詳細な説明については省略する。
【0093】
このように、本発明によれば、上記実施形態で説明した処理機能を実現する装置又はユニットは可能な範囲で変更することができるものであり、本発明はそれらの変形を包括するものである。上記変形例では、基本ユニット3とは別に運転記録データを収集するレコーダユニット4cを設ける例を説明したが、当該ユニットには収集機能および通信機能を設けて、保存先についてはネットワークを介して接続されたデータベースとしてもよい。これにより、より大容量のデータを保存することができ、トリガ発生時よりもかなり遡った解析を行うことができるとともに、他のPLCシステムのデータも利用することが可能となる。
【0094】
また、上記変形例では、処理機能を基本ユニット3とは別のユニットで実現したり、外部装置で実現する例について説明したが、基本ユニット3にそれらの処理機能を一体化する形態であってもよい。このような構成のメリットは、他のユニットや外部装置との通信処理を省略できるため通信による処理負荷を低減でき、PLC制御への影響を低減することができる点にある。なお、一体化する場合においての性能は基本ユニット3の性能に依存することになるため、基本ユニット3の高性能化が必要となる。
【0095】
<まとめ>
[観点1]
本発明は、分析装置であって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段とを備える。本実施形態によれば、各デバイスの分析結果を同期させたレポートを提供することできる。
【0096】
[観点2]
上記実施形態において、1以上の制御サイクルの定義を設定する設定手段をさらに備え、前記モデル生成手段は、設定された前記1以上の制御サイクルの定義に基づいて、取得された前記運転記録データの学習を行い、前記レポート生成手段は、前記非正常デバイスとして検知した各デバイスの分析結果を、設定された前記1以上の制御サイクルの定義に従って各デバイスの分析結果を時間軸上に同期させて表示する分析レポートを生成する。本実施形態によれば、定義された制御サイクルに従って運転記録データを分析することができ、各デバイスのサイクルに従って分析結果を同期させることができる。
【0097】
[観点3]
上記実施形態において、分析装置は、前記レポート生成手段から出力された前記分析レポートの内容を示す結果表示画面の画面情報を外部装置へ送信する送信手段をさらに備え、前記外部装置では、前記結果表示画面が操作可能に表示部に表示される。本実施形態によれば、分析レポートを外部装置へ送信することができ、たとえばより高性能のPC等で分析レポートを解析することができ、より詳細な分析やよりリッチな操作体系を有する結果表示画面の表示を可能とする。
【0098】
[観点4]
上記実施形態において、前記結果表示画面には、前記分析結果として、検知された非正常デバイスのサイクルおよび異常が検知されたタイミングを示す検知マップと、検知された非正常デバイスの工程および発生時刻を示す検知リストと、カメラ映像と、いつもと異なる状態が検知された原因を示す分析コメントとの少なくとも1つが含まれる。本実施形態によれば、分析結果を種々の形態で多面的に表示することができ、オペレータによる解析を支援することができる。
【0099】
[観点5]
上記実施形態において、前記検知マップ、前記検知リスト、前記カメラ映像、および前記分析コメントは、互いに時間軸を連動して操作可能である。本実施形態によれば、分析結果の1つの表示形態に対して操作することにより、他の表示形態の分析結果も連動して更新され、オペレータに対してより快適な操作体系を提供することができる。
【0100】
[観点6]
上記実施形態において、前記検知マップでは、検知された非正常デバイスのサイクルの開始タイミング及び終了タイミングが識別可能な形状で示され、 異常が検知されたタイミングを示す異常点が前記形状の内部に含まれる。本実施形態によれば、サイクルの開始タイミング及び終了タイミングを確認しつつ、サイクル内の異常点を把握することができ、より容易に異常の解析を行うことができる。
【0101】
[観点7]
上記実施形態において、前記カメラ映像では、分析対象の映像と、該分析対象の映像に対応する正常時の映像とが比較可能に表示される。本実施形態によれば、異常時の映像を正常時の映像と対比しながら確認することができ、より容易に異常を特定することができる。
【0102】
[観点8]
上記実施形態において、前記正常時の映像は、前記分析対象の映像の制御サイクルに同期させて表示される。本実施形態によれば、対比する2つの映像をより正確に同期させることができる。
【0103】
[観点9]
上記実施形態において、前記結果表示画面には、前記カメラ映像の再生位置を示すシークバーが含まれる。本実施形態によれば、分析対象の映像の再生地を容易に確認することができる。
【0104】
[観点10]
上記実施形態において、前記結果表示画面には、さらに、前記分析レポートの表示項目を絞るための条件を指定可能なフィルタ設定領域が含まれる。本実施形態によれば、不要な表示項目を結果表示画面から除外することができ、より容易に異常の解析を行うことができる。
【0105】
[観点11]
上記実施形態において、前記フィルタ設定領域では、デバイスの制御サイクルの指定、属性情報の指定、および、イベント、エラーの指定の少なくとも1つによってフィルタが指定可能である。本実施形態によれば、オペレータが表示項目を絞る際に種々の選択肢を提供することができる。
【0106】
[観点12]
上記実施形態において、前記ユーザプログラムの編集画面を表示する表示手段をさらに備え、前記編集画面では、該編集画面の時間軸に同期した前記分析レポートが表示可能である。本実施形態によれば、ユーザプログラムと連携して分析レポートを表示することができ、ユーザプログラムも加味した分析を行うことができる。
【0107】
[観点13]
上記実施形態において、前記分析レポートの生成要求を受け付ける受付手段と、前記レポート生成手段によって前記生成要求に応じて前記分析レポートが生成されると、要求元に分析レポートの生成が完了した旨を通知する通知手段とをさらに備える。本実施形態によれば、分析レポートの生成が完了した旨をオペレータに通知することができ、よりユーザフレンドリな操作体系を実現することができる。
【0108】
[観点14]
上記実施形態において、前記分析手段は、前記設定手段によって制御サイクルが定義されていない場合において、制御サイクルのサイクルパターンを有していないデバイスを分析対象として、前記運転記録データを分析する。本実施形態によれば、オペレータに対してサイクルパターンの設定操作を要求することなく分析レポートを容易に出力することができる。従って、オペレータはサイクルパターンを設定することなく、お試しで分析レポートを生成することもでき、生成された分析レポートを解析してより詳細に分析すべくサイクルパターンを設定するなどの解析手法も行うことができる。
【0109】
[観点15]
上記実施形態において、前記レポート生成手段は、制御サイクルのサイクルパターンを有していないデバイスの分析結果を分析レポートとして生成し、 前記分析レポートには、制御サイクルが設定されていない旨と、前記設定手段によって制御サイクルの設定を促すメッセージが含まれる。本実施形態によれば、オペレータがサイクル設定を忘れている場合などに、サイクル設定を促すことができ、よりユーザフレンドリな操作体系を提供することができる。
【0110】
[観点16]
本発明は、データ処理装置とプログラマブルロジックコントローラとが通信可能な分析システムであって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段とを備えることを特徴とする。本実施形態によれば、各デバイスの分析結果を同期させたレポートを提供することできる。
【0111】
[観点17]
上記実施形において、前記取得手段、前記モデル生成手段、分析手段、および前記レポート生成手段の少なくとも1つは前記データ処理装置に設けられる。本実施形態によれば、PLCの開発コストや、データ処理装置の性能等に応じて、本発明を実現するための構成をフレキシブルに適切なコンポーネントへ組み込むことが可能となり、システム設計の自由度を向上することができる。
【0112】
[観点18]
上記実施形態によれば、前記プログラマブルロジックコントローラは、前記実行エンジンを備えるCPUユニットと、前記取得手段を実現する前記プログラマブルロジックコントローラに設けられるレコーダユニットとを備え、前記データ処理装置は、前記モデル生成手段、分析手段、および前記レポート生成手段を備える。本実施形態によれば、PLCの開発コストや、データ処理装置の性能等に応じて、本発明を実現するための構成をフレキシブルに適切なコンポーネントへ組み込むことが可能となり、システム設計の自由度を向上することができる。
【0113】
発明は上記の実施形態に制限されるものではなく、発明の要旨の範囲内で、種々の変形・変更が可能である。
図1
図2
図3
図4
図5
図6
図7
図8A
図8B
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21