知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022158226
(43)【公開日】2022-10-17
(54)【発明の名称】分析装置、分析システム、およびその制御方法
(51)【国際特許分類】
G05B 23/02 20060101AFI20221006BHJP
【ＦＩ】
G05B23/02 T
【審査請求】未請求
【請求項の数】20
【出願形態】ＯＬ
(21)【出願番号】P 2021062982
(22)【出願日】2021-04-01
(71)【出願人】
【識別番号】000129253
【氏名又は名称】株式会社キーエンス
(74)【代理人】
【識別番号】110003281
【氏名又は名称】特許業務法人大塚国際特許事務所
(72)【発明者】
【氏名】宮坂 哲也
(72)【発明者】
【氏名】川上 大樹
【テーマコード（参考）】
3C223
【Ｆターム（参考）】
3C223AA12
3C223BA03
3C223BB08
3C223CC02
3C223CC03
3C223DD03
3C223FF13
3C223FF16
3C223FF35
3C223HH04
3C223HH06
3C223HH08
3C223HH15
(57)【要約】 （修正有）
【課題】運転記録データの分析結果に従って、異常の要因を容易に識別可能なレポートを提供し、煩雑なユーザ操作を必要とすることなく異常の要因を容易に識別可能なレポートを提供する分析装置を提供する。
【解決手段】分析装置であって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎の分析パラメータを含むモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果に基づき、前記分析パラメータに応じた表現を含む分析レポートを生成するレポート生成手段とを備える。
【選択図】図１７
【解決手段】分析装置であって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎の分析パラメータを含むモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果に基づき、前記分析パラメータに応じた表現を含む分析レポートを生成するレポート生成手段とを備える。
【選択図】図１７
【特許請求の範囲】
【請求項1】
分析装置であって、
ユーザプログラムを繰り返し実行する実行エンジンと、
前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、
取得された正常時の前記運転記録データの学習に基づきデバイス毎の分析パラメータを含むモデルを生成するモデル生成手段と、
取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、
前記非正常デバイスとして検知した各デバイスの分析結果に基づき、前記分析パラメータに応じた表現を含む分析レポートを生成するレポート生成手段と
を備えることを特徴とする分析装置。
ユーザプログラムを繰り返し実行する実行エンジンと、
前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、
取得された正常時の前記運転記録データの学習に基づきデバイス毎の分析パラメータを含むモデルを生成するモデル生成手段と、
取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、
前記非正常デバイスとして検知した各デバイスの分析結果に基づき、前記分析パラメータに応じた表現を含む分析レポートを生成するレポート生成手段と
を備えることを特徴とする分析装置。
【請求項2】
前記分析パラメータに応じた表現は、該分析パラメータに応じて分析結果を示す、自然言語での表現および図形での表現の少なくとも１つを含むことを特徴とする請求項１に記載の分析装置。
【請求項3】
前記自然言語での表現および前記図形での表現のそれぞれは、異常内容に応じたフォーマットが予め定義され、
前記レポート生成手段は、デバイス毎の異常内容に応じて前記フォーマットを選択して前記分析パラメータに応じた表現を生成することを特徴とする請求項２に記載の分析装置。
前記レポート生成手段は、デバイス毎の異常内容に応じて前記フォーマットを選択して前記分析パラメータに応じた表現を生成することを特徴とする請求項２に記載の分析装置。
【請求項4】
前記レポート生成手段は、前記異常内容に応じたフォーマットに、前記分析結果に基づく自然言語又は図形を選択して埋め込むことにより前記自然言語の表現を生成することを特徴とする請求項３に記載の分析装置。
【請求項5】
前記図形での表現には、正常時のデバイスの波形と、非正常デバイスとして検知された波形とが対比可能に含まれることを特徴とする請求項２乃至４の何れか１項に記載の分析装置。
【請求項6】
前記非正常デバイスとして検知された波形には、異常箇所が強調表示されることを特徴とする請求項５に記載の分析装置。
【請求項7】
前記モデル生成手段は、
各デバイスの前記時系列の複数のデバイス値から、各デバイスを変化パターンを示す複数の類型の何れかにそれぞれ分類し、
分類された類型に従って前記分析手段で非正常デバイスを検知する際に用いる前記分析パラメータを決定することを特徴とする請求項１乃至６の何れか１項に記載の分析装置。
各デバイスの前記時系列の複数のデバイス値から、各デバイスを変化パターンを示す複数の類型の何れかにそれぞれ分類し、
分類された類型に従って前記分析手段で非正常デバイスを検知する際に用いる前記分析パラメータを決定することを特徴とする請求項１乃至６の何れか１項に記載の分析装置。
【請求項8】
前記分析パラメータには、デバイス値のＯＮの時間、ＯＦＦの時間、立ち上がりのタイミング、立ち下がりのタイミング、ＯＮの回数、ＯＦＦの回数、および定常値の少なくとも１つが含まれることを特徴とする請求項７に記載の分析装置。
【請求項9】
前記レポート生成手段から出力された前記分析レポートの内容を示す結果表示画面の画面情報を外部装置へ送信する送信手段をさらに備え、
前記外部装置では、前記結果表示画面が操作可能に表示部に表示されることを特徴とする請求項１乃至８の何れか１項に記載の分析装置。
前記外部装置では、前記結果表示画面が操作可能に表示部に表示されることを特徴とする請求項１乃至８の何れか１項に記載の分析装置。
【請求項10】
前記結果表示画面には、さらに、前記分析レポートの表示項目を絞るための条件を指定可能なフィルタ設定領域が含まれることを特徴とする請求項９に記載の分析装置。
【請求項11】
前記フィルタ設定領域では、デバイスの制御サイクルの指定、属性情報の指定、および、イベント、エラーの指定の少なくとも１つによってフィルタが指定可能であることを特徴とする請求項１０に記載の分析装置。
【請求項12】
前記ユーザプログラムの編集画面を表示する表示手段をさらに備え、
前記編集画面では、該編集画面の時間軸に同期した前記分析レポートが表示可能であることを特徴とする請求項１０又は１１に記載の分析装置。
前記編集画面では、該編集画面の時間軸に同期した前記分析レポートが表示可能であることを特徴とする請求項１０又は１１に記載の分析装置。
【請求項13】
前記分析レポートの生成要求を受け付ける受付手段と、
前記レポート生成手段によって前記生成要求に応じて前記分析レポートが生成されると、要求元に分析レポートの生成が完了した旨を通知する通知手段と
をさらに備えることを特徴とする請求項１２に記載の分析装置。
前記レポート生成手段によって前記生成要求に応じて前記分析レポートが生成されると、要求元に分析レポートの生成が完了した旨を通知する通知手段と
をさらに備えることを特徴とする請求項１２に記載の分析装置。
【請求項14】
１以上の制御サイクルの定義を設定する設定手段をさらに備え、
前記モデル生成手段は、設定された前記１以上の制御サイクルの定義に基づいて、取得された前記運転記録データの学習を行い、
前記レポート生成手段は、前記非正常デバイスとして検知した各デバイスの分析結果を、設定された前記１以上の制御サイクルの定義に従って各デバイスの分析結果を時間軸上に同期させて表示する分析レポートを生成することを特徴とする請求項１乃至１３の何れか１項に記載の分析装置。
前記モデル生成手段は、設定された前記１以上の制御サイクルの定義に基づいて、取得された前記運転記録データの学習を行い、
前記レポート生成手段は、前記非正常デバイスとして検知した各デバイスの分析結果を、設定された前記１以上の制御サイクルの定義に従って各デバイスの分析結果を時間軸上に同期させて表示する分析レポートを生成することを特徴とする請求項１乃至１３の何れか１項に記載の分析装置。
【請求項15】
前記分析手段は、前記設定手段によって制御サイクルが定義されていない場合において、制御サイクルのサイクルパターンを有していないデバイスを分析対象として、前記運転記録データを分析することを特徴とする請求項１４に記載の分析装置。
【請求項16】
前記レポート生成手段は、制御サイクルのサイクルパターンを有していないデバイスの分析結果を分析レポートとして生成し、
前記分析レポートには、制御サイクルが設定されていない旨と、前記設定手段によって制御サイクルの設定を促すメッセージが含まれることを特徴とする請求項１５に記載の分析装置。
前記分析レポートには、制御サイクルが設定されていない旨と、前記設定手段によって制御サイクルの設定を促すメッセージが含まれることを特徴とする請求項１５に記載の分析装置。
【請求項17】
データ処理装置とプログラマブルロジックコントローラとが通信可能な分析システムであって、
ユーザプログラムを繰り返し実行する実行エンジンと、
前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、
取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、
取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、
前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段と
を備えることを特徴とする分析システム。
ユーザプログラムを繰り返し実行する実行エンジンと、
前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、
取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、
取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、
前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段と
を備えることを特徴とする分析システム。
【請求項18】
前記取得手段、前記モデル生成手段、分析手段、および前記レポート生成手段の少なくとも１つは前記データ処理装置に設けられることを特徴とする請求項１７に記載の分析システム。
【請求項19】
前記プログラマブルロジックコントローラは、
前記実行エンジンを備えるＣＰＵユニットと、
前記取得手段を実現する前記プログラマブルロジックコントローラに設けられるレコーダユニットと
を備え、
前記データ処理装置は、
前記モデル生成手段、分析手段、および前記レポート生成手段を備えることを特徴とする請求項１７に記載の分析システム。
前記実行エンジンを備えるＣＰＵユニットと、
前記取得手段を実現する前記プログラマブルロジックコントローラに設けられるレコーダユニットと
を備え、
前記データ処理装置は、
前記モデル生成手段、分析手段、および前記レポート生成手段を備えることを特徴とする請求項１７に記載の分析システム。
【請求項20】
データ処理装置とプログラマブルロジックコントローラとが通信可能なシステムの制御方法であって、
ユーザプログラムを繰り返し実行する工程と、
前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得工程と、
取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成工程と、
取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析工程と、
前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成工程と
を含むことを特徴とするシステムの制御方法。
ユーザプログラムを繰り返し実行する工程と、
前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得工程と、
取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成工程と、
取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析工程と、
前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成工程と
を含むことを特徴とするシステムの制御方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は分析装置、分析システム、およびその制御方法に関する。
【背景技術】
【0002】
プログラマブル・ロジック・コントローラ（ＰＬＣ）はファクトリーオートメーションにおいて製造機器や搬送装置、検査装置などの産業機械を制御するコントローラである（特許文献１、２）。ＰＬＣはプログラマーによって作成されるラダープログラムなどのユーザプログラムを実行することで様々な拡張ユニットや被制御機器などを制御する。
【先行技術文献】
【特許文献】
【0003】
【特許文献1】特許第５６６１２２２号公報
【特許文献2】特開２０１８－０９７６６２号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
ところで、ＰＬＣの動作やＰＬＣによって制御される産業機械の動作を監視するために、ＰＬＣが保持しているデータを収集して活用することが望まれている。ＰＬＣは、基本ユニット（ＣＰＵユニット）とそれに接続される拡張ユニットとを有している。基本ユニットは、ラダープログラムなどのユーザプログラムを実行することで拡張ユニットを制御する。拡張ユニットは基本ユニットからの命令にしたがって産業機械を制御し、制御結果を基本ユニットに返す。
【0005】
また、これらの制御結果等のデータはトラブル解析や品質管理のために使用される。従って、これらのデータを蓄積して分析し、復旧のために早期に解析結果を得ることが要求されている。しかし、ＰＬＣに関連する全てのデバイスのデータを記録する場合は膨大なデータを記憶することになり、さらに異常デバイスを特定するためにはこれらの膨大なデータ（全デバイス）を解析する必要があるため時間を要する作業となる。また、膨大な分析結果から異常デバイスを特定したり、システムを復旧させるためには、経験や知識も必要となる。従って、十分な専門的な知識や経験を必要とすることなく、各デバイスに関連する膨大なデータの中から効率よく分析を行い、分析結果を表示する仕組みが望まれている。
【0006】
そこで、本発明は上記問題に鑑み、運転記録データの分析結果に従って、異常の要因を容易に識別可能なレポートを提供することを目的とする。また、他の目的として、煩雑なユーザ操作を必要とすることなく異常の要因を容易に識別可能なレポートを提供することを目的とする。
【課題を解決するための手段】
【0007】
本発明は、たとえば、分析装置であって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎の分析パラメータを含むモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果に基づき、前記分析パラメータに応じた表現を含む分析レポートを生成するレポート生成手段とを備えることを特徴とする。
【発明の効果】
【0008】
本発明によれば、いつもと違う挙動をしたデバイスの情報とその要因がユーザに提供される。
【図面の簡単な説明】
【0009】
【図1】ＰＬＣシステムを説明する図
【図2】ＰＣ２ａのハードウエアを説明する図
【図3】ＰＣ２ｂのハードウエアを説明する図
【図4】ＰＬＣのハードウエアを説明する図
【図5】ＰＣのＣＰＵにより実現される機能を説明する図
【図6】ＰＬＣのＣＰＵにより実現される機能を説明する図
【図7】基本フローを示すフローチャート
【図8A】結果表示画面を説明する図
【図8B】結果表示画面を説明する図
【図9】リレーションマップを説明する図
【図10】分析コメントの詳細を説明する図
【図11】モデルの生成フローを示すフローチャート
【図12】サイクルパターンの判別制御を説明する図
【図13】収集データの分類を示す図
【図14】分類の処理手順を示すフローチャート
【図15】分析ユニットの結果表示フローを示すフローチャート
【図16】ＰＣの結果表示フローを示すフローチャート
【図17】自然言語による分析コメント生成フローを示すフローチャート
【図18】図形による分析コメント生成フローを示すフローチャート
【図19】サイクルを定義する設定画面を示す図
【図20】サイクル未設定の場合の警告を説明する図
【図21】モデルの信頼度を説明する図
【図22】ＰＬＣシステムの変形例を説明する図
【図23】サイクルの処理フローを説明する図
【発明を実施するための形態】
【0010】
以下、添付図面を参照して実施形態が詳しく説明される。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態で説明されている特徴の組み合わせの全てが発明に必須のものとは限らない。実施形態で説明されている複数の特徴のうち二つ以上の特徴が任意に組み合わされてもよい。また、同一または同様の構成には同一の参照番号が付され、重複した説明は省略される。複数の構成を区別するために参照符号の末尾に小文字のアルファベットが付与されることがある。複数の構成に共通する事項が説明される際には小文字のアルファベットが省略されることがある。
【0011】
＜システム構成＞
はじめにプログラマブルロジックコントローラ（ＰＬＣ、単にプログラマブルコントローラと呼ばれてもよい）を当業者にとってよりよく理解できるようにするために、一般的なＰＬＣの構成とその動作について説明する。
はじめにプログラマブルロジックコントローラ（ＰＬＣ、単にプログラマブルコントローラと呼ばれてもよい）を当業者にとってよりよく理解できるようにするために、一般的なＰＬＣの構成とその動作について説明する。
【0012】
図１は本発明の実施の形態によるＰＬＣシステムの一構成例を示す概念図である。図１が示すように、ＰＬＣシステムは、ラダープログラムなどのユーザプログラムを編集するＰＣ２ａと、分析結果等を表示するＰＣ２ｂと、工場等に設置される各種の産業機械を統括的に制御するＰＬＣ１と、ＰＬＣ１に接続されるカメラ等のフィールドデバイス１０とを備えている。ＰＣはパーソナルコンピュータの略称である。なお、以下で単にＰＣ２と記載した場合は、ＰＣ２ａおよびＰＣ２ｂの構成や制御について説明しているものである。ユーザプログラムは、ラダー言語やＳＦＣ（シーケンシャルファンクションチャート）などのフローチャート形式のモーションプログラムなどのグラフィカルプログラミング言語を用いて作成されてもよいし、Ｃ言語などの高級プログラミング言語を用いて作成されてもよい。以下では、説明の便宜上、基本ユニット３で実行されるユーザプログラムはラダープログラムと仮定される。ＰＬＣ１は、ＣＰＵが内蔵された基本ユニット３と、１つないし複数の拡張ユニット４を備えている。基本ユニット３に対して１つないし複数の拡張ユニット４が着脱可能となっている。
【0013】
基本ユニット３は、表示部５および操作部６を備えている。表示部５は、基本ユニット３に取り付けられている各拡張ユニット４の動作状況などを表示することができる。操作部６の操作内容に応じて表示部５は表示内容を切り替える。表示部５は、通常、ＰＬＣ１内のデバイスの現在値（デバイス値）やＰＬＣ１内で生じたエラー情報などを表示する。ここでデバイスとは、基本ユニット３や拡張ユニット４に含まれる種々のデバイス（リレー、タイマー、カウンタなど）を含むものであり、デバイス値（デバイスデータ）を格納するために設けられたメモリ上の領域を指すものでもあり、デバイスメモリと呼ばれてもよい。なお、当該デバイスメモリは不揮発性メモリであり、書き換え可能な不揮発性ＲＯＭで構成されてもよく、揮発性ＲＡＭ等をバッテリーバックアップ等により不揮発性を実現してもよい。ＲＯＭはリードオンリーメモリの略称である。ＲＡＭはランダムアクセスメモリの略称である。デバイス値とは、入力機器からの入力状態、出力機器への出力状態およびユーザプログラム上で設定される内部リレー（補助リレー）、タイマー、カウンタ、データメモリ等の状態を示す情報である。デバイス値の型にはビット型とワード型等がある。ビットデバイスは１ビットのデバイス値、たとえば、０／１、ＯＮ／ＯＦＦ、Ｈ／Ｌ等を記憶する。ワードデバイスは１ワードのデバイス値を記憶する。以下で詳細に説明されるデータ活用プログラムの収集対象としては、デバイスとして変数が指定されてもよい。変数も情報を保持する保持手段であり、ユーザプログラムに従って実行エンジンによりアクセスされるものである。したがって、以下の説明においてデバイスは変数も指すものである。なお、デバイスを保持するメモリはデバイスメモリと呼ばれてもよい。また、収集されたデータを保持するメモリはデータメモリと呼ばれてもよい。ＰＬＣ１は、デバイスの他、変数を取り扱うよう構成されてもよく、デバイスや変数のことをシンボルと呼び、シンボルが示す値をシンボル値と呼ぶ。
【0014】
拡張ユニット４はＰＬＣ１の機能を拡張するために用意されている。拡張ユニット４には、その拡張ユニット４の機能に対応するフィールドデバイス（被制御装置）１０が接続されることがあり、これにより、各フィールドデバイス１０が拡張ユニット４を介して基本ユニット３に接続される。フィールドデバイス１０は、センサやカメラなどの入力機器であってもよいし、アクチュエータなどの出力機器であってもよい。また、一つの拡張ユニット４に対して複数のフィールドデバイスが接続されてもよい。
【0015】
たとえば、拡張ユニット４ｂはモータ（フィールドデバイス１０）を駆動してワークの位置決めする位置決めユニットであってもよいし、カウンタユニットであってもよい。カウンタユニットは手動パルサなどのエンコーダ（フィールドデバイス１０）からの信号をカウントする。
【0016】
分析ユニット４ａは、基本ユニット３においてシンボル（デバイス、変数など）からシンボル値を収集し、シンボル値を分析して分析結果を含む分析レポートを作成する。分析ユニット４ａは、分析レポートを外部のＰＣ２ｂへ提供するＷｅｂサーバを有していてもよい。基本ユニット３はＣＰＵユニットと呼ばれることもある。ＰＬＣ１とＰＣ２とを含むシステムはプログラマブルロジックコントローラシステムと呼ばれてもよい。本実施形態では、分析ユニット４ａが各デバイスのデータを収集する例について説明するが、当該収集部については基本ユニット３に設けられてもよく、或いは、他の拡張ユニットに設けられてもよい。また、分析ユニット４ａは、収集したデータを基本ユニット３からの指示や所定のタイミングに従って分析を行う分析装置として機能することも可能である。なお、本実施形態では、分析ユニット４ａが分析装置として動作する例について説明するが、本発明を限定する意図はなく、基本ユニット３が分析装置として機能してもよく、ＰＣ２ａ、２ｂなどの外部装置が分析装置として機能してもよい。以下で説明されるフロー（フロープログラム）はデータ活用プログラムの一例に過ぎない。基本ユニット３はＣＰＵユニットと呼ばれることもある。なお、ＰＬＣ１とＰＣ２とを含むシステムはプログラマブルロジックコントローラシステムと呼ばれてもよい。
【0017】
ＰＣ２ａは主にプログラマーによって操作されるコンピュータである。一方、ＰＣ２ｂは主に現場担当者によって操作されるコンピュータである。ＰＣ２ｂは、ユーザにより画面設定されるプログラマブル表示器であってもよい。この場合、分析結果等を表示する画面はユーザにより画面設定されてもよく、あらかじめＷｅｂブラウザ機能が搭載され、Ｗｅｂブラウザ機能により分析結果等が表示されてもよい。ＰＣ２ａはプログラム作成支援装置（設定装置）と呼ばれてもよい。ＰＣ２は、たとえば、携帯可能なノートタイプやタブレットタイプのパーソナルコンピュータ又はスマートフォンであって、表示部７および操作部８を備えている外部コンピュータである。外部コンピュータとは、ＰＬＣ１の外部にあるコンピュータである。ＰＬＣ１を制御するためのユーザプログラムの一例であるラダープログラムは、ＰＣ２ａを用いて作成される。その作成されたラダープログラムは、ＰＣ２ａ内でニモニックコードに変換される。ＰＣ２は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ケーブルなどの通信ケーブル９を介してＰＬＣ１の基本ユニット３に接続される。たとえば、ＰＣ２ａは、ニモニックコードに変換されたラダープログラムを基本ユニット３に送る。基本ユニット３はラダープログラムをマシンコードに変換し、基本ユニット３に備えられたメモリ内に記憶する。なお、ここではニモニックコードが基本ユニット３に送信されているが、本発明はこれに限られない。たとえば、ＰＣ２ａは、ニモニックコードを中間コードに変換し、中間コードを基本ユニット３に送信してもよい。
【0018】
なお、図１には示していないが、ＰＣ２の操作部８には、ＰＣ２に接続されたマウスなどのポインティングデバイスが含まれていてもよい。また、ＰＣ２は、ＵＳＢケーブル以外の他の通信ケーブル９を介して、ＰＬＣ１の基本ユニット３に対して着脱可能に接続されるような構成であってもよい。また、ＰＣ２は、通信ケーブル９を介さず、ＰＬＣ１の基本ユニット３に対して無線通信によって接続されてもよい。
【0019】
＜プログラム作成支援装置＞
図２はＰＣ２ａの電気的構成について説明するためのブロック図である。図２が示すように、ＰＣ２ａは、ＣＰＵ１１ａ、表示部７ａ、操作部８ａ、記憶装置１２ａおよび通信部１３ａを備えている。表示部７ａ、操作部８ａ、記憶装置１２ａおよび通信部１３ａは、それぞれＣＰＵ１１ａに対して電気的に接続されている。記憶装置１２ａはＲＡＭやＲＯＭ、ＨＤＤ、ＳＳＤを含み、さらに着脱可能なメモリカードを含んでもよい。ＣＰＵは中央演算処理装置の略称である。ＨＤＤはハードディスクドライブの略称である。ＳＳＤはソリッドステートドライブの略称である。
図２はＰＣ２ａの電気的構成について説明するためのブロック図である。図２が示すように、ＰＣ２ａは、ＣＰＵ１１ａ、表示部７ａ、操作部８ａ、記憶装置１２ａおよび通信部１３ａを備えている。表示部７ａ、操作部８ａ、記憶装置１２ａおよび通信部１３ａは、それぞれＣＰＵ１１ａに対して電気的に接続されている。記憶装置１２ａはＲＡＭやＲＯＭ、ＨＤＤ、ＳＳＤを含み、さらに着脱可能なメモリカードを含んでもよい。ＣＰＵは中央演算処理装置の略称である。ＨＤＤはハードディスクドライブの略称である。ＳＳＤはソリッドステートドライブの略称である。
【0020】
ＰＣ２ａのユーザは記憶装置１２ａに記憶されているプロジェクト編集プログラム１４ａをＣＰＵ１１ａに実行させて、操作部８ａを通じてプロジェクトデータ１５を編集する。つまり、ＰＣ２ａはエンジニアリングツールであり、プログラム作成支援装置として機能する。ＣＰＵ１１ａがプロジェクト編集プログラム１４ａを実行することで、プロジェクト作成部１６とプロジェクト転送部１７が実現される。プロジェクト作成部１６はユーザ入力にしたがってプロジェクトデータ１５を作成する。プロジェクト転送部１７はプロジェクトデータ１５をＰＬＣ１に転送する。プロジェクトデータ１５は、一つ以上のユーザプログラム（例：ラダープログラム、制御プログラム、モーションプログラム、データ活用プログラム）と、基本ユニット３や拡張ユニット４の構成情報、ＷｅｂＨＭＩの作画データ、基本ユニット３や拡張ユニット４に備えられた特定機能の設定情報などを含む。構成情報は、基本ユニット３に対する複数の拡張ユニット４の接続位置やデバイスの割り当て情報を含む。基本ユニット３に備えられた機能（例：データ収集機能、通信機能、位置決め機能）を示す情報、拡張ユニット４の機能（例：通信機能、位置決め機能、撮影機能）などを示す情報を含んでいてもよい。作画データは、ＷｅｂＨＭＩを実現するための表示部品群であり、フロントエンドの構造を記述するマークアップデータ、たとえばＨＴＭＬデータ、装飾を記述するスタイルデータ、たとえばＣＳＳデータおよび動的な処理を記述するコード、たとえばＪａｖａＳｃｒｉｐｔ（登録商標）コードなどにより実現される。装飾を記述するスタイルデータは、たとえばファイル形式として提供されてもよく、構造を記述するマークアップデータ内で外部スタイルデータファイルを呼び出す記述により呼び出されてもよい。動的処理を記述するコードは、たとえばファイル形式で提供されてもよく、構造を記述するマークアップデータ内で外部コードファイルを呼び出す記述により呼び出されてもよい。外部スタイルデータファイルや外部コードファイルを呼び出して使用できる形式のフロントエンドは、再利用性やメンテナンス性が高く、たとえば汎用のフロントエンドコンポーネント等を利用することができる。以下で、作画データは、表示部品と表記される。データ活用プログラムは、ＰＬＣ１において制御データ（デバイス値など）を収集したり、データ処理したり、ＷｅｂＨＭＩに渡すためのデータを作成したりするためのプログラムを含む。特定機能の設定情報は、基本ユニット３に備えられた機能（例：データ収集機能、通信機能、位置決め機能）に関する設定情報、たとえば、データ収集機能であれば、データ収集条件やデータ収集対象の設定情報を含み、拡張ユニット４の機能（例：通信機能、位置決め機能、データ活用機能、撮影機能）に関する設定情報等を含む。ここで、プロジェクトデータ１５の編集には、プロジェクトデータ１５の作成および変更（再編集）が含まれる。ユーザは、必要に応じて記憶装置１２ａに記憶されているプロジェクトデータ１５を読み出し、そのプロジェクトデータ１５を、プロジェクト編集プログラム１４ａを用いて変更することができる。通信部１３ａは、通信ケーブル９ａを介して基本ユニット３と通信する。プロジェクト転送部１７は通信部１３ａを介してプロジェクトデータを基本ユニット３に転送する。通信部１３ａは、通信ケーブル９ｂを介して分析ユニット４ａと通信する。
【0021】
＜ダッシュボードの表示に使用されるＰＣ＞
図３はＰＣ２ｂの電気的構成について説明するためのブロック図である。図３が示すように、ＰＣ２ｂは、ＣＰＵ１１ｂ、表示部７ｂ、操作部８ｂ、記憶装置１２ｂおよび通信部１３ｂを備えている。表示部７ｂ、操作部８ｂ、記憶装置１２ｂおよび通信部１３ｂは、それぞれＣＰＵ１１ｂに対して電気的に接続されている。記憶装置１２ｂはＲＡＭやＲＯＭ、ＨＤＤ、ＳＳＤを含み、さらに着脱可能なメモリカードを含んでもよい。
図３はＰＣ２ｂの電気的構成について説明するためのブロック図である。図３が示すように、ＰＣ２ｂは、ＣＰＵ１１ｂ、表示部７ｂ、操作部８ｂ、記憶装置１２ｂおよび通信部１３ｂを備えている。表示部７ｂ、操作部８ｂ、記憶装置１２ｂおよび通信部１３ｂは、それぞれＣＰＵ１１ｂに対して電気的に接続されている。記憶装置１２ｂはＲＡＭやＲＯＭ、ＨＤＤ、ＳＳＤを含み、さらに着脱可能なメモリカードを含んでもよい。
【0022】
ＣＰＵ１１ｂはＷｅｂブラウザプログラム１４ｄを実行することでＷｅｂブラウザ１８を実現する。Ｗｅｂブラウザ１８は、通信部１３ｂを介して、分析ユニット４ａによって提供されるデータ活用アプリケーションの設定ページにアクセスしたり、ダッシュボードのページにアクセスしたりする。またＣＰＵ１１ｂは、分析ユニット４ａから送信された異常発生時の特定結果（判定結果）を示す画面情報に従って、当該特定結果を表示部７ｂに表示する。
【0023】
＜ＰＬＣ＞
図４はＰＬＣ１の電気的構成について説明するためのブロック図である。図４が示すように、基本ユニット３は、ＣＰＵ３１、表示部５、操作部６、メモリ３２および通信部３３を備えている。表示部５、操作部６、メモリ３２、および通信部３３は、それぞれＣＰＵ３１に電気的に接続されている。メモリ３２は、ＲＡＭやＲＯＭ、メモリカードなどを含んでもよい。メモリ３２はデバイス部３４やプロジェクト記憶部３５、リングバッファ３６、運転記録記憶部３７などの複数の記憶領域を有している。
図４はＰＬＣ１の電気的構成について説明するためのブロック図である。図４が示すように、基本ユニット３は、ＣＰＵ３１、表示部５、操作部６、メモリ３２および通信部３３を備えている。表示部５、操作部６、メモリ３２、および通信部３３は、それぞれＣＰＵ３１に電気的に接続されている。メモリ３２は、ＲＡＭやＲＯＭ、メモリカードなどを含んでもよい。メモリ３２はデバイス部３４やプロジェクト記憶部３５、リングバッファ３６、運転記録記憶部３７などの複数の記憶領域を有している。
【0024】
ここで運転記録とはＰＬＣ１の運転状態をスキャンタイムレベルで記録したもので、たとえばＰＬＣ１の運転に関わる全てのシンボルのシンボル値と収集時刻とを、一スキャン毎に時系列に記録したものである。運転に関わる全てのシンボルとは、たとえばラダープログラム等のユーザプログラムに使用される全てのシンボルであってもよく、ユーザにより選択されるプログラム単位やユニット単位に含まれる全てのシンボルであってもよい。この場合、運転記録の対象となるシンボルをプログラム単位やユニット単位のように有意な単位で一括選択でき、さらに個別にシンボルを加除できるようにしてもよい。これにより、たとえば、トラブル発生時に、トラブル発生時刻の前後においてＰＬＣ１の運転に関わる全てのシンボルのシンボル値と収集時刻とを、一スキャン毎に時系列に記録した運転記録を生成し、運転記録に基づきトラブル発生時に何が起きたかを後からでも正確に把握することができる。運転記録には、その時の状況を再現するために多くの情報が含まれるが、情報が多いと運転記録のデータ容量が大きくなり取り回しが難しくなったり、運転記録の収集に負荷がかかったりするため、収集対象となるユーザによりプログラム単位やユニット単位で選択できるようになっている。
【0025】
また、運転記録には、シンボルに加え時系列のカメラ画像が撮像時刻ともに含まれてもよい。これにより、たとえば、トラブル発生時に、トラブル発生時刻の前後に遡って何が起きたかを後からでも正確に把握でき、設備の外観変化を示すカメラ画像も運転記録に含めることでユーザプログラムの時系列と連動してカメラ画像を記録することができる。ＨＭＩ（ヒューマンマシンインタフェース）やＰＣなどの外部機器からの書き込み履歴やＰＬＣからの書き込み履歴を変化点イベントとして運転記録に含めてもよい。これにより、たとえば、トラブル発生前後にどのような変化点イベントがあったかを時系列で確認できる。
【0026】
デバイス部３４はビットデバイスやワードデバイスなどを有し、各デバイスはデバイス値を記憶する。プロジェクト記憶部３５は、ＰＣ２ａから転送されたプロジェクトデータを記憶する。リングバッファ３６は、定期的にデバイス部３４からデバイス値を収集して記憶する。運転記録記憶部３７は、所定のイベントが発生すると、発生時刻の周辺（発生時刻以前、発生時刻以後、または、発生時刻の前後）に収集されたデバイス値とその収集時刻とを含むイベント記録を記憶する。イベントとは、たとえば、デバイスごとに設定された警報条件または注意条件が満たされたことをいう。警報条件とは、たとえば、ＰＬＣ１による製造ラインの制御動作を停止すべきような条件をいう。注意条件は、たとえば、ＰＬＣ１による製造ラインの制御動作について管理者が注意すべきようなデバイス値の条件をいう。ＣＰＵ３１は、ＰＣ２ａからの要求に応答してイベント記録をＰＣ２ａへ送信する。また、ＣＰＵ３１は、リアルタイムでデバイス値をＰＣ２ａに提供してもよい。メモリ３２は基本ユニット３のＣＰＵ３１により実行される制御プログラムも記憶する。図３が示すように基本ユニット３と拡張ユニット４とは拡張バスの一種であるユニット内部バス９０を介して接続されている。なお、ユニット内部バス９０に関する通信機能はＣＰＵ３１に実装されるが、通信部３３の一部として実装されてもよい。通信部３３は、ＵＳＢ規格などに準拠したシリアル通信回路を有してもよい。ＣＰＵ３１は通信部３３を介してプロジェクトデータをＰＣ２ａから受信する。
【0027】
ここで、ユニット内部バス９０について、補足説明する。このユニット内部バス９０は、入出力リフレッシュに使用される通信バスである。入出力リフレッシュとは、基本ユニット３と拡張ユニット４との間でデバイス値を更新する処理である。入出力リフレッシュは、ラダープログラムが一回実行されるごとに（つまり、一スキャンごとに）、実行される。
【0028】
拡張ユニット４はＣＰＵ４１とメモリ４２を備えている。拡張ユニット４ｂのＣＰＵ４１ｂは、デバイスに格納された基本ユニット３からの指示（デバイス値）にしたがってフィールドデバイス１０を制御する。なお、本実施形態において拡張ユニット４ｂは、カメラ制御ユニットとして機能する。また、ＣＰＵ４１ｂは、カメラ等のフィールドデバイス１０の制御結果をバッファメモリとよばれるデバイスに格納する。デバイスに格納された制御結果は入出力リフレッシュによって基本ユニット３に転送される。また、デバイスに格納されている制御結果は、基本ユニット３からの読み出し命令にしたがって、入出力リフレッシュとは異なるタイミングであっても、基本ユニット３に転送されることがある。メモリ４２はＲＡＭやＲＯＭなどを含む。とりわけ、ＲＡＭにはバッファメモリとして使用される記憶領域が確保されている。メモリ４２は、フィールドデバイス１０によって取得されたデータ（例：静止画データや動画データ）を一時的に保持するバッファを有してもよい。
【0029】
データ活用ユニット（分析ユニット）として機能する分析ユニット４ａのＣＰＵ４１ａは、通信部４３と通信ケーブル９ｂを介してＰＣ２ｂと通信する。通信部４３は、ネットワーク通信を実行する通信回路を含む。ＣＰＵ４１ａは、基本ユニット３において収集されたデバイス値を分析することで、分析結果を含む分析レポートを作成する。たとえば、ＣＰＵ４１ａは、データ活用アプリケーションとして運転記録分析アプリケーションを実行することにより、運転記録データに含まれるシンボル値を分析することで、非正常シンボルと当該シンボルが非正常となる時刻とを特定し、非正常シンボルと当該シンボルが非正常となる時刻とを対応づけた分析結果を含む分析レポートを作成する。運転記録データは、運転記録の保存イベント発生時刻周辺の状況を再現するための情報を含んでいるため、分析レポートと紐づけて管理されてもよい。また、運転記録データは、運転記録の保存イベント発生時刻周辺の状況を再現するため、多くのシンボルのシンボル値を含むことからデータサイズが大きくなる。このため、たとえば、ＣＰＵ４１ａは、運転記録データの中から、分析レポートに必要なデータを読み出して、分析レポート用のデータとして運転記録データに追加保存してもよい。分析レポート用のデータは、もともと運転記録データに含まれていた分析レポートに必要なデータを、そのままコピーしたものを分析レポート用のデータとしてタグ付けして運転記録データに追加保存してもよく、分析レポート用にデータ加工して運転記録データに追加保存してもよい。
【0030】
運転記録データにカメラ画像が含まれると、カメラ画像の再生により運転記録の保存イベント発生時刻周辺の状況をより詳細に把握することができる。分析レポートはカメラ画像を再生するＵＩ（ユーザインターフェース）を含んでもよい。カメラ画像はデータサイズが大きいため、カメラ画像を再生するＵＩにおいてクリックやスクロール操作を受け付けた時などに必要なカメラ画像データだけを部分的にダウンロードしてもよい。たとえば、ＣＰＵ４１ａは、分析レポートを作成する際、カメラ画像を分析レポートにおける表示順序に対応して加工したり、時刻とカメラ画像の保存位置の対応関係を示すインデックス情報を生成し、時刻に対応したカメラ画像を高速かつ部分的にダウンロードできるようにしてもよい。
【0031】
狭義には、分析レポートは、分析結果そのものを意味するが、広義には、分析結果を表示するＷｅｂアプリケーションやそのユーザインタフェースを意味することがある。ＣＰＵ４１ａは、たとえば、デバイス値が正常範囲内かどうかや、デバイス値が変化するタイミングが正常範囲内かどうかなどを判定する。デバイス値が変化するタイミングが正常範囲内かどうかは、たとえば、デバイス値が“１”（オン）である期間の長さが正常範囲かどうかであってもよい。また、ある工程またはサイクルにおけるデバイス値の変化回数が正常範囲内かどうかが判定されてもよい。あるデバイスから収集されたデバイス値が正常条件を満たしていない場合、そのデバイスは、いつもと違う振る舞いのデバイスであるため、非正常デバイスと呼ばれてもよい。ＣＰＵ４１ａは、Ｗｅｂ形式の分析レポートを作成し、通信部４３および通信ケーブル９ｂを介して分析レポートをＰＣ２ｂのＷｅｂブラウザに提供してもよい。ＣＰＵ３１がプロトコル変換機能を有している場合、ＣＰＵ４１ａは、ユニット内部バス９０、ＣＰＵ３１、通信部３３および通信ケーブル９ａを介して、分析レポートをＰＣ２ａに送信してもよい。分析レポートは、グラフ表示部品や数値表示部品などを有してもよい。これらの表示部品は、フロントエンドの構造を記述するマークアップデータ、装飾を記述するスタイルデータおよび動的な処理を記述するコード、たとえばＨＴＭＬデータ、ＣＳＳデータおよびＪａｖａＳｃｒｉｐｔ（登録商標）コードなどにより実現される。ＨＴＭＬはハイパーテキストマークアップ言語の略称である。ＣＳＳはカスケーディングスタイルシートの略称である。
【0032】
＜ＰＣ２ｂの機能＞
図５はＰＣ２ｂのＣＰＵ１１ｂによって実現される機能を説明する図である。ＰＣ２ｂのＣＰＵ１１ｂは、Ｗｅｂブラウザプログラム１４ｄを実行することによりＷｅｂブラウザ１８を実行する。Ｗｅｂブラウザ１８はＷｅｂアプリケーション６１を実行して、通信処理部６２、データ取得部６３、描画部６５、受付部６６、および再生部６７の機能を実現する。また、Ｗｅｂブラウザ１８は、後述する分析ユニット４ａのＷｅｂサーバ８２と、ＨＴＴＰ（ハイパーテキストトランスポートプロトコル）にしたがって通信して表示部品を受信する。
図５はＰＣ２ｂのＣＰＵ１１ｂによって実現される機能を説明する図である。ＰＣ２ｂのＣＰＵ１１ｂは、Ｗｅｂブラウザプログラム１４ｄを実行することによりＷｅｂブラウザ１８を実行する。Ｗｅｂブラウザ１８はＷｅｂアプリケーション６１を実行して、通信処理部６２、データ取得部６３、描画部６５、受付部６６、および再生部６７の機能を実現する。また、Ｗｅｂブラウザ１８は、後述する分析ユニット４ａのＷｅｂサーバ８２と、ＨＴＴＰ（ハイパーテキストトランスポートプロトコル）にしたがって通信して表示部品を受信する。
【0033】
Ｗｅｂブラウザ１８は、Ｗｅｂアプリケーション６１を実行することで分析レポートを表示部７ｂに表示する。Ｗｅｂアプリケーション６１は、たとば、ＨＴＭＬデータ、ＣＳＳデータおよびｊａｖａ（Ｒ）スクリプトなどにより構成される。Ｗｅｂアプリケーション６１は、分析ユニット４ａから提供されてもよい。通信処理部６２は、Ｗｅｂサーバ８２との通信を処理する。データ取得部６３は、分析レポートに表示すべき運転記録データを分析ユニット４ａから取得する。運転記録は、ダウンロードして記憶装置１２ｂに記憶される。描画部６５は分析レポートを表示部７ｂに表示する。連携部６４は、分析レポートにおける再生時刻と、運転記録の再生時刻とが同期するように時刻管理を実行する。
【0034】
受付部６６は、分析レポートの結果表示画面に対しての操作などを受け付ける。再生部６７は、たとえば、受付部６６又は連携部６４から入力される再生要求に応じて、運転記録データをダウンロードさせて記憶装置１２ｂに保存させる。再生要求には、たとえば、運転記録を特定可能な識別情報（例：固有の識別情報やＰＬＣ１における保存パス名）などが含まれていてもよい。再生部６７は、記憶装置１２に保存されている運転記録を再生して表示部７に表示する。再生部６７は、ＰＬＣ１からリアルタイムで取得される時系列のデバイス値を波形化して表示したり、運転記録に含まれる時系列のデバイス値を波形化して表示したりしてもよい。
【0035】
＜ＰＬＣ１の機能＞
図６はＰＬＣ１においてＣＰＵ３１とＣＰＵ４１ａとが制御プログラムを実行することで実現する機能を示している。ＣＰＵ３１においてコマンド処理部７１は、ＰＣ２ａ、２ｂから受信されるコマンドを解釈し、解釈結果に対応した処理を実行する。たとえば、ＨＴＴＰリクエストをカプセル化して作成された要求信号が受信されると、コマンド処理部７１は、要求信号をＣＰＵ４１ａに転送する。要求信号に対する応答信号がＣＰＵ４１ａから受信されると、コマンド処理部７１は、応答信号をＰＣ２ａ、２ｂへ転送する。コマンド処理部７１は分析ユニット４ａにも設けられてよい。その場合、ＰＣ２ａからコマンドについてはコマンド処理部７１が処理し、ＰＣ２ｂからのコマンドは分析ユニット４ａに設けられたコマンド処理部が処理する。収集部７２は、基本ユニット３や拡張ユニット４ｂからシンボル値（デバイス値や変数に格納された値）を収集してリングバッファ３６に格納する。収集部７２の収集設定については基本ユニット３および分析ユニット４ａの少なくとも一方から行うことができる。ロギング部７３は、収集されたシンボル値などに基づき、何らかのエラーまたはトラブル（非正常イベント）がＰＬＣ１において生じているかどうかを判定する。たとえば、ロギング部７３は、収集されたシンボル値が記録条件を満たしているかどうかを判定してもよい。収集されたシンボル値が記録条件を満たしている場合に、ロギング部７３は、当該シンボル値を運転記録７４内の稼働ログ７６として保存する。ロギング部７３は、運転記録を作成したときに実行されていたプロジェクトデータ７５も運転記録７４内に保存する。さらに、ロギング部７３は、運転記録７４を作成したことを分析部８３に通知する。設定部７８は、オペレータの入力に従って後述する学習モデルの生成や、分析、分析レポートの生成に利用する制御サイクルを設定する。制御サイクルは、サイクルの基準となるタイミングを指定することで設定され、制御サイクルの設定をサイクル設定と呼ぶ。たとえば、サイクル設定は、サイクルの開始タイミングを規定するシンボル名と、シンボル値の立上り／立下りのエッジ情報とを含む。また、サイクル設定は、サイクルの開始タイミングを規定するシンボル名と、シンボル値の立上り／立下りのエッジ情報とによるサイクルの開始タイミングの設定情報と、サイクルの終了タイミングを規定するシンボル名と、シンボル値の立上り／立下りのエッジ情報とによるサイクルの終了タイミングの設定情報を含んでいてもよい。設定部７８による制御サイクルの設定はＣＳＶ等のファイル形式でＰＬＣ１に提供され、設定部７８がＣＳＶ等のファイルを読み出して制御サイクルを設定してもよい。たとえば、設定部７８によって設定された制御サイクルは、当該サイクルに同期するデバイスを分類して当該分類情報を属性情報としてモデルへ付加したり、分析対象とするデバイスを制御サイクルによって絞ったり、制御サイクルに同期して表示される分析レポートを生成したりするために用いられる。設定される制御サイクルは複数であってもよい。設定方法については後述する。また、制御サイクルは必ずしも設定する必要はなく、たとえば、正常時におけるシンボル値の取り得る値が予め決まっている場合、シンボル値がその予め決まっている取り得る値か否かを判定することで非正常シンボルとして判定することができる。
図６はＰＬＣ１においてＣＰＵ３１とＣＰＵ４１ａとが制御プログラムを実行することで実現する機能を示している。ＣＰＵ３１においてコマンド処理部７１は、ＰＣ２ａ、２ｂから受信されるコマンドを解釈し、解釈結果に対応した処理を実行する。たとえば、ＨＴＴＰリクエストをカプセル化して作成された要求信号が受信されると、コマンド処理部７１は、要求信号をＣＰＵ４１ａに転送する。要求信号に対する応答信号がＣＰＵ４１ａから受信されると、コマンド処理部７１は、応答信号をＰＣ２ａ、２ｂへ転送する。コマンド処理部７１は分析ユニット４ａにも設けられてよい。その場合、ＰＣ２ａからコマンドについてはコマンド処理部７１が処理し、ＰＣ２ｂからのコマンドは分析ユニット４ａに設けられたコマンド処理部が処理する。収集部７２は、基本ユニット３や拡張ユニット４ｂからシンボル値（デバイス値や変数に格納された値）を収集してリングバッファ３６に格納する。収集部７２の収集設定については基本ユニット３および分析ユニット４ａの少なくとも一方から行うことができる。ロギング部７３は、収集されたシンボル値などに基づき、何らかのエラーまたはトラブル（非正常イベント）がＰＬＣ１において生じているかどうかを判定する。たとえば、ロギング部７３は、収集されたシンボル値が記録条件を満たしているかどうかを判定してもよい。収集されたシンボル値が記録条件を満たしている場合に、ロギング部７３は、当該シンボル値を運転記録７４内の稼働ログ７６として保存する。ロギング部７３は、運転記録を作成したときに実行されていたプロジェクトデータ７５も運転記録７４内に保存する。さらに、ロギング部７３は、運転記録７４を作成したことを分析部８３に通知する。設定部７８は、オペレータの入力に従って後述する学習モデルの生成や、分析、分析レポートの生成に利用する制御サイクルを設定する。制御サイクルは、サイクルの基準となるタイミングを指定することで設定され、制御サイクルの設定をサイクル設定と呼ぶ。たとえば、サイクル設定は、サイクルの開始タイミングを規定するシンボル名と、シンボル値の立上り／立下りのエッジ情報とを含む。また、サイクル設定は、サイクルの開始タイミングを規定するシンボル名と、シンボル値の立上り／立下りのエッジ情報とによるサイクルの開始タイミングの設定情報と、サイクルの終了タイミングを規定するシンボル名と、シンボル値の立上り／立下りのエッジ情報とによるサイクルの終了タイミングの設定情報を含んでいてもよい。設定部７８による制御サイクルの設定はＣＳＶ等のファイル形式でＰＬＣ１に提供され、設定部７８がＣＳＶ等のファイルを読み出して制御サイクルを設定してもよい。たとえば、設定部７８によって設定された制御サイクルは、当該サイクルに同期するデバイスを分類して当該分類情報を属性情報としてモデルへ付加したり、分析対象とするデバイスを制御サイクルによって絞ったり、制御サイクルに同期して表示される分析レポートを生成したりするために用いられる。設定される制御サイクルは複数であってもよい。設定方法については後述する。また、制御サイクルは必ずしも設定する必要はなく、たとえば、正常時におけるシンボル値の取り得る値が予め決まっている場合、シンボル値がその予め決まっている取り得る値か否かを判定することで非正常シンボルとして判定することができる。
【0036】
ＣＰＵ４１ａにおいてプロトコル変換部８１は、ＰＣ２ｂからカプセル化されて転送されてきたＨＴＴＰリクエストをプロトコル変換して要求信号からとりだす。プロトコル変換部８１は、ＨＴＴＰリクエストに対してＷｅｂサーバ８２から送信される応答情報をカプセル化してＣＰＵ４１ａに渡す。プロトコル変換部８１は透過的なトンネル（例：ＴＣＰトンネル）を提供してもよい。Ｗｅｂサーバ８２は、分析部８３により作成された分析レポートをＰＣ２ｂへ提供する。分析部８３は、運転記録７４内の稼働ログ７６を後述するモデルを用いて分析し、分析結果７７を作成して、ロギング部７３に渡す。分析部８３が分析結果７７を作成すると、ロギング部７３は、プロジェクトデータ７５および稼働ログ７６に加えて、分析結果７７を含む運転記録７４に追加する。運転記録７４は、運転記録記憶部３７に格納される。或いは、分析結果７７は分析ユニット４ａのメモリ４２ａに記憶されてもよい。通知発行部８４は、分析結果７７が発行されると、通知を発行する。この通知は、ＣＰＵ１１ｂに送信される。
【0037】
たとえば、Ｗｅｂブラウザ１８がＨＴＴＰリクエストにより分析レポートを要求すると、Ｗｅｂサーバ８２はＨＴＴＰリクエストをプロトコル変換部８１に渡す。ＨＴＴＰリクエストには、ＣＰＵ４１ａで実行され、分析レポートを提供する分析ユニット４ａ（Ｗｅｂサーバ）のＵＲＬ（ユニフォームリソースロケータ）が含まれている。プロトコル変換部８１は、ＨＴＴＰリクエストをカプセル化して、所定の通信プロトコルで送信可能な要求信号（コマンド）に変換する。この要求信号は、分析ユニット４ａのＣＰＵ４１ａに渡される。ＣＰＵ４１ａは、ＣＰＵ１１ｂに分析レポートを返信する。ＣＰＵ１１ｂは、分析レポートをＷｅｂブラウザ１８に渡す。これによりＷｅｂブラウザ１８は表示部７ｂに分析レポートを表示する。
【0038】
モデル生成部８６は、後に分析部８３が運転記録データと比較するためのマスタデータとなるモデルを作成する。レポート生成部８５は、分析結果７７をＰＣ２ｂのＷｅｂブラウザ１８で表示するための表示画面である分析レポートを生成する。分析レポートには、複数の分析結果が含まれるが、それらの分析結果は時間軸上で同期して表示される。分析レポートの詳細については図８Ａを用いて後述する。モデル生成部８６は、分類部８７および決定部８８を備える。
【0039】
分類部８７は、収集部７２によって収集された各デバイスの時系列データから、各デバイスが何れの類型に属するかを分類する。分類の手法については、図１３を用いて後述する。なお、分類部８７は、任意のタイミングで分類処理を実行するものであるが、基本的にはシステムの運用が開始されたタイミングやユーザからの指示を受け付けたタイミングで分類処理を実行する。決定部８８は、分類部８７によって分類された時系列データに従って、いつもと異なる状態のデバイスを検知する際の分析パラメータを決定し、メモリ４２ａに格納する。決定部８８は、分類部８７によって分類処理が実行されると、分類パラメータの決定処理を行い、同一のデバイスについて既に分析パラメータが決定されている場合には当該分析パラメータを更新する。更新する際には、上書きにより更新してもよいし、平均値をとるなど２つの分析パラメータから新たな分析パラメータを決定するようにしてもよい。また、デバイスごとに更新時の処理を決定するようにしてもよい。このように、分類部８７および決定部８８は、収集した運転記録データを分析して正常時のデータがどのようなものであるかを学習する学習フェーズにおいて機能する処理部であり、非正常デバイスを推定する際の分析パラメータを決定する。一方、分析部８３は、非正常デバイスを推定する推定フェーズで機能する処理部である。分析部８３は、決定された分析パラメータを用いて、収集部７２によって収集された各デバイスの時系列データから非正常デバイスを検知する。分析パラメータには、たとえばデバイス値のＯＮの時間、ＯＦＦの時間、立ち上がりのタイミング、立ち下がりのタイミング、ＯＮの回数、ＯＦＦの回数、および定常値の少なくとも１つが含まれる。
【0040】
＜基本フロー＞
図７は、本実施形態に係るモデル生成と、運転記録データの分析および結果出力の基本フローを示す。以下で説明する処理は、基本ユニット３のＣＰＵ３１および分析ユニット（拡張ユニット）４ａのＣＰＵ４１ａによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。
図７は、本実施形態に係るモデル生成と、運転記録データの分析および結果出力の基本フローを示す。以下で説明する処理は、基本ユニット３のＣＰＵ３１および分析ユニット（拡張ユニット）４ａのＣＰＵ４１ａによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。
【0041】
Ｓ１で基本ユニット３のＣＰＵ３１は、ＰＣ２ａを介して入力された情報に従って、収集部７２における収集設定や分析設定を設定する。たとえば、ＣＰＵ３１は、収集設定として、収集対象や収集期間、保存先、ファイル名などを設定することができる。分析設定としては、たとえば分析対象となるサイクルの開始および終了の設定が含まれる。ここでは基本ユニット３が収集設定および分析設定を行う例について説明したが、分析ユニット４ａのＣＰＵ４１ａがＰＣ２ｂを介して入力された情報に従って収集設定を行ってもよい。さらにＳ１では、基本ユニット３のＣＰＵ３１が、分析設定として、ＰＣ２ａ、２ｂの表示部７ａ、７ｂに表示された設定画面を介して入力された情報に従って撮影条件等のカメラ設定や画像処理設定、監視項目設定などを設定することができる。なお、これらの分析設定についても分析ユニット４ａのＣＰＵ４１ａによって実行することも可能である。その後、Ｓ２でＣＰＵ３１は、Ｓ１で設定された収集設定に従って運転記録データを、モデル作成用データとして収集し、運転記録記憶部３７へ格納する。より詳細には、収集設定に従って収集された全デバイス値が一旦リングバッファ３６へ格納され、リングバッファ３６から必要なデータが運転記録データとして運転記録記憶部３７へ格納される。
【0042】
次に、Ｓ３で分析ユニット４ａのＣＰＵ４１ａは、収集された運転記録データを利用してモデルを作成する。当該モデルには、各デバイスのパターンを、定数、ビットパターン、アナログ値などの特徴量に基づいて分類したデバイスごとの情報や、デバイス値が変化するタイミングを示す情報が含まれてもよい。つまり、当該モデルは、各デバイスの正常時の変化パターンが学習される。Ｓ３の詳細な処理については図１１を用いて後述する。
【0043】
その後、Ｓ４で基本ユニット３のＣＰＵ３１は運転記録データの分析を行うトリガが発生したか否かを判断する。当該トリガは、基本的には運転中にいつもと違う異常が発生した場合をトリガとするものであり、その成立条件として、たとえばエラービットが設定された場合や、監視アプリケーション等のアプリケーションからの所定のイベントの発生、オペレータからの手動による指示の受け付け等が挙げられる。トリガが発生するとＳ５へ進む。
【0044】
Ｓ５で基本ユニット３のＣＰＵ３１は、各デバイス値を収集して分析を行うための運転記録データを、運転記録記憶部３７に保存する。通常、いつもと違う何らかの変化が発生した後にトリガが発生する。従って、ここでは、そのような変化の原因を特定するためにトリガ前後のデータが取得される。上述したように、運転中における全デバイスのデバイス値はリングバッファ３６へ保持されている。従って、ＣＰＵ３１はトリガが発生したと判断すると、Ｓ１で設定された分析設定に従って、トリガ前後の必要なデバイス値をリングバッファ３６から運転記録記憶部３７へ格納する。また、Ｓ５で分析ユニット４ａのＣＰＵ４１ａは、基本ユニット３から分析用の運転記録データを取得する。ここでは、運転記録データに加えて、更にカメラ画像データやイベントの発生履歴、エラー履歴の情報も合わせて取得してもよい。
【0045】
その後、Ｓ６で分析ユニット４ａのＣＰＵ４１ａは、基本ユニット３で収集された時系列データを取得して、Ｓ２で生成されたモデルと比較して分析処理を実行する。分析処理では、各デバイスについて、Ｓ３で生成されたマスタデータであるモデルデータと、分析対象の運転記録データとを比較して、対象デバイスがいつもと異なる状態であるかどうかを判断する。所定値以上の差分があればいつもとは異なる状態が検知されていると判断する。さらにＣＰＵ４１ａは判断後の分析結果を基本ユニット３の運転記録記憶部３７における分析結果７７の記憶領域に、各デバイスごとの分析結果を格納する。ここで分析結果７７には、いつもと異なる状態が検知されたデバイスの分析結果とその記録データとが時間情報とともに格納されることが望ましい。これにより、オペレータ等からの分析レポートの生成要求を受け付けた場合にそれらの情報を用いて各デバイス値を同期させて表示可能な分析レポートを容易に作成することができる。なお、拡張ユニット４ｂから得られるカメラ映像も紐づけて格納してもよい。さらに、Ｓ７でＣＰＵ４１ａは、分析結果に基づいて、結果を示す表示データ（分析レポート）を生成し、通信部４３を介して生成した表示データをＰＣ２ｂや外部装置へ送信し、処理を終了する。たとえば、ＰＣ２ｂにおいて分析結果がオペレータに対して表示される。分析レポートを表示した結果表示画面の詳細については図８Ａを用いて後述する。
【0046】
監視アプリケーションは、分析ユニット４ａのＣＰＵ４１ａにより実行されるデータ活用アプリケーションの一つである。分析ユニット４ａは、データ活用アプリケーションを実行する拡張ユニットであってもよい。データ活用アプリケーションは、制御データを収集したりデータ処理したりするデータ活用プログラム（例：フロー）と、データ活用プログラムの実行結果を表示するダッシュボードとを含む。データ活用アプリケーションとしては、監視対象であるデバイスや変数をリアルタイムに監視する監視アプリケーションと、ＰＬＣ１の運転状態を再現するための運転記録を分析して分析レポートを生成する運転記録分析アプリケーションなどが存在してもよい。また、データ活用アプリケーションとしては、可動率（べきどうりつ）、良品率、または、サイクルタイムなどのＫＰＩ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ）を算出する算出アプリケーションなどが存在してもよい。監視アプリケーションは、ＰＬＣ１のシンボルのシンボル値に基づく常時監視するためのアプリケーションで、たとえば監視アプリケーションの設定に応じて１又は複数のシンボルのシンボル値をスキャンタイムレベルで常時収集し、収集したシンボル値に基づく情報をリアルタイムに更新しながら常時表示するアプリケーションである。常時監視の対象となる１又は複数のシンボルは、予めユーザにより設定される。監視アプリケーションは、たとえばＷｅｂサーバ機能を有し、通信部４３を介して汎用ブラウザから設定が可能である。汎用ブラウザから設定できることにより、プログラム作成支援装置等の専用ツールを介さずに、ＰＣ、スマホ、タブレットから設定または監視ができる。また、監視アプリケーションは、常時監視の対象となる１又は複数のシンボルについて正常時における複数のサイクルのシンボル値に基づき当該シンボルに対応する閾値を自動で設定する。たとえば、監視アプリケーションは、ユーザ指示を受け付けて、常時監視の対象となる複数のシンボルについて正常時における複数のサイクルのシンボル値のばらつきに基づき、シンボルの状態を監視するための閾値を一括で自動設定する。閾値は、いつもと違う状態、つまり、非正常状態を監視するように設定され、監視アプリケーションは、監視対象のシンボルのシンボル値が閾値を超えた場合はアラームを発報する。このようにして、たとえば、ＰＬＣ１は、設備が止まる前に兆候を捉えることができる。ＰＬＣ１は、監視アプリケーションによる兆候監視の結果、監視対象のシンボルのシンボル値が閾値を超えた場合のアラームを、運転記録の保存条件としてもよい。ＰＬＣ１は、監視アプリケーションによるアラーム発生をイベントトリガとして、トリガ前後の運転記録データを保存する。ＰＬＣ１は、運転記録データの保存が完了すると保存完了デバイスをＯＮする。運転記録分析アプリケーションは、運転記録データの保存が完了したことをうけ、自動的に運転記録データを分析してもよい。たとえば、運転記録分析アプリケーションは、保存完了デバイスをＯＮしたことに応じて運転記録データを分析してもよい。運転記録分析アプリケーションは、分析対象となったシンボルのシンボル値（例、全ビットデバイスのデバイス値）を分析して、アラートが出た要因候補のシンボルを抽出する。このようにして運転記録分析アプリケーションは、監視アプリケーションによるアラーム発生の要因をアラーム発生により保存した運転記録データを自動分析し、運転記録データの中からいつもと違うシンボルを抽出する。これにより、ＣＰＵ４１ａは、監視アプリケーションの兆候監視機能により設備の状態を常時監視し、変化要因でアラートを発報する。さらに、ＣＰＵ４１ａは、アラート要因を自動分析し、いつもと違うシンボルを抽出する。つまり、ＰＬＣ１は、シンボル値を常時監視することで被制御対象設備の兆候監視をして、アラームにより被制御対象設備が止まる前に兆候を報知して、兆候の要因を自動分析する。
【0047】
＜結果表示画面（分析レポート）＞
図８Ａは、本実施形態に係るＷｅｂブラウザ１８がＷｅｂブラウザプログラム１４ｄを実行することで表示部７ｂに表示される結果表示画面を示す。ここでは当該結果表示画面８００がＰＣ２ｂの表示部７ｂに表示される例について説明するが、本発明を限定する意図はなく他の装置の表示部に表示されてもよいし、ＰＬＣの拡張ユニットが有するモニタで表示可能であれば当該モニタに表示されてもよい。たとえば、他の装置としてプログラマブル表示器、タブレット、スマートフォンが含まれてもよい。或いは、以下で説明する結果表示画面の内容を含む分析レポートとして他の装置へ電子メール、ＳＮＳ、ＦＴＰ転送等で送信されてもよい。分析レポートに対して任意のコメントが付されてもよく、たとえば、分析レポートに対して手書き文字や入力文字コメントが付与されてもよい。この場合、任意のコメントが付与された結果表示画面の内容を含む分析レポートが他の装置へ送信されてもよい。これにより、メールの受信者はコメントなどの現場状況と分析レポートとを合わせて閲覧することができる。また、分析レポートが他の装置へ送信する際、分析レポートとともに当該分析レポートの分析対象である運転記録データが対応付けられて送信されてもよい。これにより、メールの受信者は運転記録と分析レポートとを合わせて閲覧することができる。さらに、ＰＣ２ｂがカメラ付きのタブレットやスマートフォン等であれば、装置の写真も一緒に添付できてもよい。
図８Ａは、本実施形態に係るＷｅｂブラウザ１８がＷｅｂブラウザプログラム１４ｄを実行することで表示部７ｂに表示される結果表示画面を示す。ここでは当該結果表示画面８００がＰＣ２ｂの表示部７ｂに表示される例について説明するが、本発明を限定する意図はなく他の装置の表示部に表示されてもよいし、ＰＬＣの拡張ユニットが有するモニタで表示可能であれば当該モニタに表示されてもよい。たとえば、他の装置としてプログラマブル表示器、タブレット、スマートフォンが含まれてもよい。或いは、以下で説明する結果表示画面の内容を含む分析レポートとして他の装置へ電子メール、ＳＮＳ、ＦＴＰ転送等で送信されてもよい。分析レポートに対して任意のコメントが付されてもよく、たとえば、分析レポートに対して手書き文字や入力文字コメントが付与されてもよい。この場合、任意のコメントが付与された結果表示画面の内容を含む分析レポートが他の装置へ送信されてもよい。これにより、メールの受信者はコメントなどの現場状況と分析レポートとを合わせて閲覧することができる。また、分析レポートが他の装置へ送信する際、分析レポートとともに当該分析レポートの分析対象である運転記録データが対応付けられて送信されてもよい。これにより、メールの受信者は運転記録と分析レポートとを合わせて閲覧することができる。さらに、ＰＣ２ｂがカメラ付きのタブレットやスマートフォン等であれば、装置の写真も一緒に添付できてもよい。
【0048】
結果表示画面８００は、結果をフィルタリングして表示するためのフィルタ８０１～８０３と、フィルタ結果８０４と、検知マップ８１０と、検知リスト８２０と、画像表示領域８３０と、分析コメント８４０とを含んで構成される。なお、結果表示としては、８１０、８２０、８３０、８４０のうち少なくとも１つが表示されるものであってよい。フィルタ８０１は制御サイクルを選択して結果表示をフィルタリングすることができる。ここでの制御サイクルとは、デバイス値の周期的な変化を伴う開始タイミングから終了タイミングまでの期間を称する。フィルタ８０１を指定すると、選択された制御サイクルで動作するデバイスの分析結果に絞って結果が表示される。フィルタ８０２は属性情報を選択して結果表示をフィルタリングすることができる。属性情報とは、何れのユニットや通信機器に接続されているかの情報や、入力デバイスであるか否かの情報を示す。
【0049】
フィルタ８０２においてたとえば「ユニット構成情報」を指定するとユニット構成がポップアップ画面等で表示され、表示されたユニットのいずれかを選択することができる。ユニットが選択されると、当該ユニットに接続されているデバイスに絞って結果が表示される。また、属性情報として「入力デバイス」が指定されると、入力デバイスの属性情報が付加されたデバイスに絞って結果が表示される。フィルタ８０２は、属性情報を活用するフィルタリングに限られない。たとえば、分析の結果、同じシンボルが重複して非正常シンボルとして検出されることがある。非正常の原因を探るうえで最先の発生時刻が重要となる可能性が高く、フィルタ８０２は、重複して検出された同じシンボルのうち最先の発生時刻以外をフィルタリングするようにしてもよい。また、フィルタ８０２は、同じシンボルで、分析時の検知アルゴリズムや後述する異常の種類が同一なもののうち、最先の発生時刻以外をフィルタリングするようにしてもよい。さらに、フィルタ８０２は、同じシンボルで、分析時の検知アルゴリズムや後述する異常の種類が同一であって、後述するサイクル設定が同一なもののうち、最先の発生時刻以外をフィルタリングするようにしてもよい。
【0050】
フィルタ８０３はイベントやエラーを選択して結果表示をフィルタリングすることができる。イベントやエラーの種別を指定するとそれに関わりのあるデバイスの分析結果に絞って結果が表示される。たとえば、イベントとして「運転記録保存トリガ」が選択された場合には、その前後の分析結果に絞って結果が表示される。結果表示画面８００は、分析結果とともにイベントやエラーを発生時刻順に表示してもよい。この場合、フィルタ８０３はイベントやエラーをフィルタリングすることができる。これにより分析結果とイベントやエラーの混在表示と、分析結果の表示とを切り換えることができる。ここで、イベントは、たとえば、電源ＯＮ／ＯＦＦ、デバイス値書換、メモリ挿抜などを含み、カテゴリー毎にフィルタリング対象を加除できるようにしてもよい。エラーは、たとえば通信エラー、ＰＬＣ演算エラー、スキャンタイム超過エラーなどを含み、エラーの重度毎にフィルタリング対象を加除できるようにしてもよい。
【0051】
なお、フィルタ８０１～８０３のフィルタ条件は論理積として判断され、該当する分析結果が表示される。従って、フィルタ８０１～８０３は必ずしも選択される必要はなく、オペレータが所望するフィルタが選択された場合に分析結果がフィルタリングされてもよい。或いは、オペレータが指定する前にデフォルトでフィルタを選択して分析結果を表示するようにしてもよい。これらの分析結果として表示されるデバイスは、いつもと異なる状態が検知されたデバイスである。いつもと異なる状態とは、たとえば、デバイス値が正常範囲を逸脱したり、デバイス値が変化するタイミングまたは回数が正常範囲を外れたりすることである。製品の製造工場では、日々、同一の製品が大量生産される。つまり、同一の工程が何度も繰り返し実行される。そのため、いつもと異なる状態を検知して表示することは、ラダープログラムを改良したり、生産設備を見直したりするうえで、非常に役に立つ。いつもと同様の状態（正常状態）を定義する正常範囲（正常条件）は、ユーザにより定義されてもよいし、デバイス値の学習結果により定義されてもよい。
【0052】
検知マップ８１０は、ＰＬＣ１において実行される複数の工程のそれぞれについて開始タイミングと終了タイミングとを含むサイクルを時間軸に沿って表示する。検知マップ８１０において、横方向に延びる矩形は、工程が実行中である期間（制御サイクル）を示している。また、矩形内の丸はサイクル内で発生したいつもと異なる状態が発生した異常発生箇所である異常点を示している。検知マップ８１０の横軸は時間を示し、左端はデータの収集開始時点、右端はデータの収集終了時点を表す。なお、上部の拡大／縮小ボタンを選択することにより、横軸方向の拡大・縮小を行うことができる。その場合の初期表示は、左端がデータ収集開始点、右端はデータの収集終了点であってもよい。或いは、後述するサイクル定義の時間幅で決めてもよい。たとえば、サイクル時間が、１０秒、１０秒、１１秒、９秒、１０秒、１０秒、２０秒である場合に、その中央値の１０秒をとり、３サイクル分が一括で表示できるように、左端から右端を３０秒としてもよい。ここでは、縦軸をデバイス単位としているが、後述するプログラムモジュール単位としてもよい。また、検知マップ８１０には、デバイス値に並べて、カメラ映像の特徴量の値を表示するようにしてもよい。デバイス値と並べて表示することにより、映像の周期的な変化を容易に認識することができる。
【0053】
図８Ａに示すように、制御サイクルは矩形形状で表すことができ、左端が開始タイミングを示し、右端が終了タイミングを示す。これによりデバイス値を波形で示すよりも、その制御サイクルを一見して確認することができ、サイクルの動作中であるか否かを判断することができる。なお、本発明はこれに限定されず、開始タイミングと終了タイミングとが識別可能な形状であればどのような形状で表されてもよい。たとえば、矩形形状ではなく開始タイミングを示す縦線と終了タイミングを示す縦線とを表示し、その内部を背景色と異ならせることによりサイクルを表現してもよい。また、運転記録データの中に開始タイミングや終了タイミングの記録が無い場合には、それらを示す縦線等を検知マップ８１０に描画しなくてもよい。また、図８Ａに示すように、定義された制御サイクル内の異常発生箇所を示す。図８Ａの例では、異常が発生した箇所を異常点として表示している。一方で、異常には異常開始から終了までの区間がある。したがって、異常箇所を区間でプロットしてもよい。これにより、他のデバイスと異常発生区間が重なっている様子を表現することができ、オペレータにとってはデバイス間の関連性を認識することができ、エラーを特定する際に重要な情報となる。このように各デバイスの異常発生箇所については種々の方法で描画することが可能である。
【0054】
検知マップ８１０において、工程を示す矩形は、左が古く右が新しいことを示す。時刻バー８１１は、選択中の時刻を示している。時刻バー８１２は、運転記録データの保存トリガが発生したタイミングを示している。上述したように、運転記録データは保存トリガが発生した前後のデータが記録されているため、時刻バー８１２の前後にデータが示されている。時刻バー８１１、８１２はそれぞれ異なる色で描画したり、実線と破線とで異なるように描画したりすることにより、識別力を向上させてもよい。また、時刻バー８１１を操作することにより、分析結果の表示を更新することができる。時刻バー８１１の操作に従って、検知リスト８２０、画像表示領域８３０、および分析コメント８４０の少なくとも１つの後述する時刻バーについても同様に連動して更新され、対応する分析結果が表示されてもよい。
【0055】
画像表示領域８３０は、ＰＬＣ１において取得されたカメラ画像（以下では、カメラ映像とも称する。）を表示する。図８Ａでは、正常時のデータであるマスタデータのカメラ画像と、今回のカメラ画像とが対比可能に表示されている。カメラ画像も時系列データであるため、シークバー８３１は、カメラ画像の再生時刻を示し、再生時刻の経過にしたがって左から右に移動する。時刻バー８３２は、検知対象デバイスがいつもと異なる状態になったタイミングを示しており、上述した時刻バー８１１と連動している。時刻指定部８３３は、カメラ画像の再生時刻を進めたり、再生時刻を戻したり、再生の開始を指示したり、再生を停止したりすることを指示するためのコントロールオブジェクトである。８３４は制御サイクルを指定することができ、指定されたサイクルを基準サイクルとしてカメラ映像が再生される。たとえば、時刻指定部８３３の早送りのボタンが操作されると、現在の制御サイクルの次の制御サイクルまで映像がスキップするように制御される。また、サイクルの終了時にジャンプするものであってもよい。
【0056】
カメラ映像は、運転記録データとして保持されてもよいが、時刻が関連付けられた、外部機器に保存されているデータであってもよい。たとえば、拡張ユニットの何れかに接続されたＷｅｂカメラに記録されているカメラ映像であってもよいし、画像検査機に記録されている検査画像であってもよい。外部機器に保存されているデータは、画像以外にも測定器の記録データであってもよく、数値であったり、測定波形が表示されるものであってもよい。なお、結果表示画面８００において、検知マップ８１０の再生時刻、カメラ画像の再生時刻、および、検知リスト８２０の再生時刻は同期するように管理され表示されている。また、図８Ａの点線領域に示すように、検知した異常箇所を映像中において強調表示してもよい。これにより、ユーザはさらに容易に正常時の映像と、今回の映像を対比することができる。
【0057】
検知リスト８２０は、いつもと異なる状態になったデバイスと、その状態が発生した時刻（デバイス値の収集時刻）とを示す。検知リスト８２０は、いつもと異なる状態となったデバイスを時刻順に示したリストである。ＣＰＵ１１ｂは、検知リスト８２０に表示されたデバイスに対するクリックを検知すると、クリックされたデバイスの識別情報と、再生時刻情報（デバイス値の収集時刻）とに基づいて、検知マップ８１０、検知リスト８２０、および画像表示領域８３０の表示を同期させることができる。時刻バー８２１は、選択中の時刻を示しており、時刻バー８１１、８３１と連動し、同一のタイミングを示している。時刻バー８２２は、運転記録データの保存トリガが発生したタイミングを示している。
【0058】
分析コメント８４０は、分析結果に含まれるコメントと、検知リスト８２０で選択されたデバイスについての、マスターデータと、今回のデバイス値の時系列データとを表示する。時刻バー８４１は、いつもと異なる状態が発生したタイミングを示し、時刻バー８１１、８２１、８３１と連動し、同一のタイミングを示している。表示されているコメントは、当該デバイスの異常の内容を示している。分析コメントは種々の形態をとりうるが、詳細については図１０を用いて後述する。
【0059】
ＣＰＵ１１ｂは、検知リスト８２０に表示されたデバイスに対するクリックを検知すると、クリックされたデバイスの識別情報と、いつもと異なる状態になったサイクル情報（サイクルの開始時刻と終了時刻、または、サイクルの開始時刻と次のサイクルの開始時刻）とに基づいて、検知マップ８１０、検知リスト８２０、および分析コメント８４０の表示を同期させることができる。図８Ｂは、検知リスト８２０の何れかの項目が選択された場合に、検知マップ８１０、検知リスト８２０、および分析コメント８４０を同期させた様子を示す。分析コメント８４０は、いつもと異なる状態になったサイクルに対応した時間範囲のデバイス値の時系列データを表示する。このとき、検知マップ８１０上には、分析コメント８４０に表示された時系列データの時間範囲８５４に対応する時間範囲８５２が図示される。検知マップ８１０に図示される時間範囲８５２は、複数の工程のうちいつもと異なる状態になった工程に対応して図示される。たとえば、検知リスト８２０に表示されたデバイスのうち、現在と異なるデバイスの項目８５３がクリックされると、クリックされたデバイスについて、いつもと異なる状態になったサイクルに対応した時間範囲のデバイス値の時系列データに切り替わる。その際、検知マップ８１０上では、分析コメント８４０に表示された時系列データの時間範囲８５４に対応する時間範囲８５２を含む範囲に表示が切り替わる。また、矢印８５５で示すように、検知マップ８１０上において、点線や色付きの実線の枠などによって時間範囲８５２が強調表示され、分析コメント８４０における切り出し区間との対応が確認できるように表示される。これにより、分析コメント８４０が検知マップ８１０上のどの区間を切り出した波形かをオペレータに容易に把握させることができる。また、８５４に示すように、分析コメント８４０においても波形の下部に、切り出した区間に対応するサイクルを示す矩形や異常点を表示することにより、サイクルの開始タイミングや、終了タイミングと波形や異常との関係をオペレータに容易に把握させることができる。また、検知マップ８１０は、８５１に示すように、検知リスト８２０で選択されたデバイスに対応する異常点を拡大表示してもよい。また、分析コメント８４０に表示された時系列データの時間範囲が、サイクルの開始時刻と次のサイクルの開始時刻の場合、分析コメント８４０には、時系列データの時間軸に対応して、サイクルの終了時刻を示す位置に図式表示がされてもよい。
【0060】
このように、結果表示画面８００は検知マップ８１０、検知リスト８２０、画像表示領域８３０、および分析コメント８４０など複数の分析結果の表示を含んで構成される。しかし、これらの結果表示は一例であり他の結果表示が追加的に又は代替的に含まれてもよい。たとえば、図９に示すように、分析結果として、デバイス間の依存情報（リレーションマップ）を表示してもよい。基本ユニット３は、ラダープログラムを解析することで、デバイス・変数間の依存関係を把握することができる。たとえば、ある検知されたデバイスを選択されると、それに関係するデバイスも並べて表示するなど、依存関係のあるデバイスをオペレータへ提示することができる。これにより、オペレータに対して異常の把握や特定を支援することができる。
【0061】
＜リレーションマップ＞
図９はリレーションマップ９００を示している。リレーションマップ９００は、ラダープログラム等のユーザプログラムにおいて、特定のシンボルに関連するプログラムモジュールと、そのプログラムモジュールに関連する他のシンボルとの関係を示す図式表示であり、たとえば、特定のシンボルとして、ラダープログラムに使用されるいつもと異なる状態になったデバイス（非正常デバイス）を選択した場合は、当該非正常デバイスに対してラダープログラムにおいてプログラムモジュールを介して関連している他のデバイスを表示するＵＩとなる。このＵＩは結果表示画面８００において不図示の表示ボタンを操作することにより遷移する画面であってもよいし、結果表示画面８００上に追加で表示されてもよい。リレーションマップを表示することにより、ユーザは、非正常デバイスと他のデバイスとの依存関係を容易に理解できる。一般に、ＰＬＣ１において利用されるデバイスの数は数百から数万であるため、ユーザは、いつもと異なる状態になったデバイスから、その原因となったデバイスを特定することは容易ではない。ＣＰＵ１１は、非正常デバイスについてラダープログラム内を検索し、非正常デバイスに関する記述を発見し、当該記述を分析することで、関連デバイスを特定する。この例では、ラダープログラム内の出力部において、非正常デバイス（例：Ｒ０００４）が記述されており、関連デバイスとしてＭＲ０００、ＭＲ００１、ＭＲ００２が存在する。
図９はリレーションマップ９００を示している。リレーションマップ９００は、ラダープログラム等のユーザプログラムにおいて、特定のシンボルに関連するプログラムモジュールと、そのプログラムモジュールに関連する他のシンボルとの関係を示す図式表示であり、たとえば、特定のシンボルとして、ラダープログラムに使用されるいつもと異なる状態になったデバイス（非正常デバイス）を選択した場合は、当該非正常デバイスに対してラダープログラムにおいてプログラムモジュールを介して関連している他のデバイスを表示するＵＩとなる。このＵＩは結果表示画面８００において不図示の表示ボタンを操作することにより遷移する画面であってもよいし、結果表示画面８００上に追加で表示されてもよい。リレーションマップを表示することにより、ユーザは、非正常デバイスと他のデバイスとの依存関係を容易に理解できる。一般に、ＰＬＣ１において利用されるデバイスの数は数百から数万であるため、ユーザは、いつもと異なる状態になったデバイスから、その原因となったデバイスを特定することは容易ではない。ＣＰＵ１１は、非正常デバイスについてラダープログラム内を検索し、非正常デバイスに関する記述を発見し、当該記述を分析することで、関連デバイスを特定する。この例では、ラダープログラム内の出力部において、非正常デバイス（例：Ｒ０００４）が記述されており、関連デバイスとしてＭＲ０００、ＭＲ００１、ＭＲ００２が存在する。
【0062】
ＣＰＵ１１ｂは、ラダープログラムから特定した非正常デバイス、関連デバイスおよびプログラムモジュールをツリーのように表示する。ユーザプログラム（ラダー、Ｃ言語、フロー言語、スクリプトなど）は、可読性やメンテナンス性向上のために、いくつかに分けて記述することが多く、その単位をプログラムモジュールと称する。１つのプログラムモジュールの中では、各デバイスを読み書きするプログラムが記述され、１つのデバイスは複数のモジュールで読み書きされることもあるが、主に使用されるモジュールは１つであることが多い。図９の例では、出力部における演算のために入力されるデバイスが左側に表示され、プログラムモジュールが真ん中に表示され、その右側に非正常デバイスが表示されている。図９が示すように、リレーションマップ９００上のプログラムモジュールが選択されると、ＣＰＵ１１ｂは、該当するプログラムモジュールをプログラム表示領域９１０に表示してもよい。なお、ここではＰＣ２ｂのＣＰＵ１１ｂが表示処理を制御する例で説明しているが、一例でありＰＣ２ａのＣＰＵ１１ａで行われてもよい。また、上述した検知マップ８１０についても、デバイス単位ではなくプログラムモジュール単位で表示するようにしてもよい。
【0063】
ＣＰＵ１１は、シンボルを特定するユーザ指定に応じて、ユーザプログラムからシンボルに関連するプログラムモジュールを特定し、特定したプログラムモジュールに関連する他のシンボルを特定して、リレーションマップ１５００を生成する。ＣＰＵ１１は、分析結果に基づいてリレーションマップ１５００内に含まれる非正常デバイスを強調表示する。分析結果は非正常デバイスがいつもと異なると判断した時刻も含んでおり、ＣＰＵ１１は、再現する時刻よりも前に発生した非正常デバイスのみをリレーションマップ１５００上で強調表示するようにしてもよい。これにより非正常デバイスは、いつもと異なる状態が発生して以降、強調表示が保持されることになる。また、分析結果には、各シンボルのうち、分析対象外のシンボルであることを示す情報が含まれてもよい。この場合、ＣＰＵ１１は、分析結果に基づいてリレーションマップ１５００上で分析対象外のシンボルと他のシンボルと色などを区別して表示する。これにより、分析により非正常でないと判断したのか、未分析のため非正常と判断されなかったのかを区別できる。分析対象外のシンボルとは、たとえば、制御サイクルやサイクル設定により定義されるサイクルに対し、シンボル値の変化パターンが規則性を持たないシンボルであったり、ユーザにより分析対象外として指定されたシンボルを含む。
【0064】
＜分析コメント＞
図１０に分析コメントの種々の形態を示す。図８Ａに示した分析コメント８４０は、分析結果の情報、特に、異常内容に応じて種々の形態をとりうる。なお、分析コメントについては、分析ユニット４ａが自動で生成するものであり、特にオペレータによる操作を必要としない。ここでは、分析コメント１０００、１０１０、１０２０の３つについて例示するが、これらの形態も例示の一部となる。
図１０に分析コメントの種々の形態を示す。図８Ａに示した分析コメント８４０は、分析結果の情報、特に、異常内容に応じて種々の形態をとりうる。なお、分析コメントについては、分析ユニット４ａが自動で生成するものであり、特にオペレータによる操作を必要としない。ここでは、分析コメント１０００、１０１０、１０２０の３つについて例示するが、これらの形態も例示の一部となる。
【0065】
分析コメント１０００は、デバイスの変化数が学習時のマスタデータよりも多い異常内容を示す。１００１には分析コメントが示され、所定のデバイスがマスターよりも多く変化している旨のコメントが自然言語で示される。１００２はマスタデータの波形を示し、１００３は分析対象である今回取得された運転記録データの波形を示す。１００４は多く変化した異常箇所を示しており、たとえば網掛け等により強調表示されている。また、分析コメント１０１０は、デバイスのＯＮ時間の異常内容を示す。また、分析コメント１０００には、モデル信頼度１０３０が示されている。モデル信頼度とは分析に使用した学習モデルの信頼度を示すものであり、詳細については図２１を用いて後述する。１０１１には分析コメントが示され、所定のデバイスがマスターよりも所定時間早くＯＦＦに変化している旨のコメントが自然言語で示される。また、図１０に示すように、所定時間の部分が”２９７．８６ｍｓ”と記載されており、１０１２はマスタデータの波形を示し、１０１３は分析対象である今回取得された運転記録データの波形を示す。また、１０１２、１０１３に示すように、それぞれの波形においてＯＮからＯＦＦへ変化したタイミングを示す箇所に、”変化点ａ１”、”変化点ｂ１”という文字列が示される。これにより、オペレータは変化点を容易に把握することができるとともに、マスターの波形と今回の波形とを対比してその相違を容易に判断することができる。このように、本実施形態に係る分析コメントは、１００１、１０１１に示すように、自然言語による異常内容の説明と、１００２～１００４、１０１２、１０１３に示すように、図形による異常内容の説明とが含まれる。なお、自然言語による異常内容の説明と、図形による異常内容の説明とは何れか一方のみであってもよい。分析レポートを表示する結果表示画面の描画領域のサイズに応じて変更してもよい。
【0066】
このように自然言語による異常内容の表現には、自然言語が人同士の会話と同様の方法であるため、ユーザは新しく覚えることが少なくなり、専門的な知識を必要とすることなく異常内容を容易に解析できるというメリットがある。また、数値や判定結果（ＯＫ／ＮＧ）だけでなく、どのように判定し、どこが異常だったかが文章としてわかりやすいというメリットがある。一方、図形による異常内容の表現には、視覚的に理解でき、どのような異常だったか、タイミングや異常度合いなどの詳細を知ることができる。また、理解が難しいブラックボックス的な判定手法の場合に、その判定結果を信頼できないというユーザの思考があるが、判定結果が図示されて理解しやすくなることで、判定手法の信頼性に対するユーザの評価も変えることができる。
【0067】
また、分析コメント１０００、１０１０についてはビットデバイスについての分析コメントの例を示すが、本実施形態に係るＰＬＣ１はワードデバイスも含まれるものであり、ワードデバイスにおける分析コメントの例を１０２０に示す。ここでは図形による異常内容の説明としてアナログ値のプロットしたグラフを示す。横軸が時間に相当し、縦軸がデバイス値を示す。また１０２１が今回取得した所定デバイスの運転記録データを示し、１０２２が正常時のデータであるマスタデータを示す。マスタデータの代わりに数サイクルの平均値としてもよい。また、１０２３が下限閾値を示し、１０２４が上限閾値を示す。運転記録データがこれらの閾値を超えるとエラーとなる。また、１０２５の矩形はいつもと異なる状態が検知された箇所を示すものであり、今回取得した運転記録データがマスタデータから所定値ほど離れている箇所を示す。なお、このような矩形による強調表示は、下限閾値１０２３や上限閾値１０２４を超えている箇所についてのみ表示するようにしてもよい。
【0068】
＜モデル生成フロー＞
図１１は、上記Ｓ３におけるモデル生成フローの詳細を示す。ここでは、デバイスの属性情報としてデバイスのデバイス値を分類してモデルを生成する制御について説明する。なお、本発明はこれに限らず上述した他の属性情報に基づいてモデルを生成してもよい。以下で説明する処理は、分析ユニット（拡張ユニット）４ａのＣＰＵ４１ａによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。
図１１は、上記Ｓ３におけるモデル生成フローの詳細を示す。ここでは、デバイスの属性情報としてデバイスのデバイス値を分類してモデルを生成する制御について説明する。なお、本発明はこれに限らず上述した他の属性情報に基づいてモデルを生成してもよい。以下で説明する処理は、分析ユニット（拡張ユニット）４ａのＣＰＵ４１ａによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。
【0069】
まずＳ３１で分析ユニット４ａのＣＰＵ４１ａは、基本ユニット３からモデル作成用の正常時の運転記録データを取得する。当該運転記録データは、上記Ｓ２で運転記録記憶部３７に格納されたデータである。続いて、Ｓ３２でＣＰＵ４１ａは、デバイス値以外の情報として、基本ユニット３からサイクル設定の情報を取得する。サイクル設定の情報は、たとえばＰＣ２ａを介してオペレータから設定されたサイクルパターンの情報を示す。たとえば、サイクルの開始タイミングとサイクルの終了タイミングとを示す。また、ここで取得する情報には、拡張ユニット４ｂに接続されたカメラ等のフィールドデバイス１０で取得された情報、たとえばカメラ画像データなども含まれてもよい。これらのデータについては基本ユニット３を介して取得してもよいが、たとえば拡張ユニット４ｂなどから直接取得するようにしてもよい。また、本実施形態においてＳ３２の処理は必須ではなく、サイクル設定の情報は取得できなくてもよい。
【0070】
次に、Ｓ３３でＣＰＵ４１ａは、Ｓ３２で取得したサイクル設定に基づき、各デバイスが何れのサイクルに属するかを判定し、さらに各デバイス値の変化パターンに応じて各デバイスが何れの類型に属するかを分類する。デバイスの分類については図１３を用いて後述する。また、各デバイスのサイクルパターンには種々のパターンが存在するものであり、ここでは各デバイスがサイクル設定で指定された何れのパターンに属するデバイスであるかを判断する。サイクル設定が複数の制御サイクルに対応した設定を含む場合、各制御サイクルに属するデバイスを判定するようにしてもよい。このとき、複数の制御サイクルに属すると判断されるデバイスが存在してもよい。図１２は、各デバイスのサイクルパターンを判別する制御について示す。図１２において、矩形は工程が実行中である期間（サイクル）である開始タイミングから終了タイミングまでを示しており、１つの矩形が１サイクルを示す。サイクルパターンとはこの１サイクルが出現するパターンである。１２０１～１２０３はサイクル設定された工程を示す。１２０４～１２０６はそれぞれデバイスＡ～Ｃの収集データから抽出したサイクルパターンを示す。分析ユニット４ａは各デバイスについて何れのサイクル設定のパターンに属するかを判断し、たとえばデバイスＡがサイクル設定１に属し、デバイスＢがサイクル設定２に属し、デバイスＡが設定された何れのサイクル設定にも該当しないと判断する。具体的には、サイクル開始から終了までの、値と変化回数が一致しているかを判定している。なお、開始タイミングや終了タイミングについては多少ずれても問題ない。このように、分析ユニット４ａは、各サイクル設定のパターンと各デバイスとがどのような対応関係かを判定する。分析ユニット４ａは各サイクル設定のパターンについて何れのデバイスが属するかを判断するようにしてもよい。
【0071】
分析ユニット４ａは、各サイクル設定のパターンと各デバイスとがどのような対応関係か判定する際に、各サイクル設定のサイクル開始からサイクル終了までにおける各デバイス値のパターンに基づいて判定する。これにより、サイクルの終了から次の開始までデバイス値がどのような動作をしても、そのデバイスを当該サイクル設定のパターンに属すると判断することができる。また、分析ユニット４ａは、各サイクル設定のパターンと各デバイスとがどのような対応関係か判定する際に、各サイクルの基準タイミングから次のサイクルの基準タイミングまで、たとえばサイクル開始から次のサイクル開始までのデバイスの値と変化回数が一致しているかで判定してもよい。
【0072】
ＰＬＣ１において実行される複数の工程のそれぞれについて開始タイミングと終了タイミングとを含むサイクル、つまり、工程が実行中である期間を制御サイクルはサイクル設定の対象とされているが、サイクル設定の対象はこれに限られない。図２３は、開始タイミングから終了タイミングの期間以外にも変化するデバイスが存在する場合のサイクルの処理フローを示す。図２３に示すように、作業工程を実行するために、作業工程を実行するための準備として作業開始条件を満足しているかを確認する確認フェーズ２３０１が存在してもよく、また、作業開始フェーズ２３０２、作業フェーズ２３０３、及び作業終了フェーズ２３０４の作業工程の実行後には次の工程の準備をする準備フェーズ２３０５、次の工程まで待機する待機フェーズ２３０６等が存在してもよい。このため、作業工程の実行中以外の期間においても変化するデバイスは存在し、異常要因を突き止めるための手がかりとなり得る。たとえば、確認フェーズにおいて作業開始条件の成立に関連する入力デバイス、準備フェーズにおいて次の準備の制御信号を示すデバイスなどは、開始タイミングから終了タイミングまでの期間以外の期間で動作するため、これらのデバイスの分析結果は、異常要因を突き止めるための手がかりとなり得る。要するに、サイクル設定の対象は、サイクルの基準タイミングから次の基準タイミングまでであってもよく、これにより隙間なく分析することができる。また、サイクル設定では、ユーザにより開始タイミングを規定するデバイスと、終了タイミングを規定するデバイスとが選択されたり、正常時の運転記録データなどを学習することで自動的に設定されたりする。しかし、分析対象の期間が開始タイミングから終了タイミングに限定されると、工程の開始を規定するデバイスや工程の終了を規定するデバイスを正確に把握していない場合、そのようなデバイスを見つけ出すことは困難なことがある。サイクル設定の対象をサイクルの基準タイミングから次の基準タイミングまでとすることで、工程の開始を規定するデバイスや工程の終了を規定するデバイスを厳密に指定しなかったとしても、工程に同期するデバイスを選択するだけで隙間なく分析することができる。
【0073】
図１１の説明に戻る。Ｓ３３でＣＰＵ４１ａは、抽出したサイクルパターンおよび後述する変化パターンの類型を属性情報（分析パラメータ）として各デバイスに付加する。次に、Ｓ３４でＣＰＵ４１ａは、付加された属性情報に基づいてＳ３１で取得した運転記録データからモデルを生成し、処理を終了する。生成したモデルは、分析時に利用するマスタデータであり、少なくとも各デバイスのサイクルパターンの情報や変化パターンの類型情報などを示す分析パラメータが含まれる。分析パラメータには、たとえばデバイス値のＯＮの時間、ＯＦＦの時間、立ち上がりのタイミング、立ち下がりのタイミング、ＯＮの回数、ＯＦＦの回数、および定常値の少なくとも１つを示す閾値が含まれる。これらの分析パラメータを用いて、推定フェーズにおける分析が行われる。
【0074】
＜デバイスの類型＞
図１３は、収集される時系列データの類型の一例を示す。１３０１～１３０６は各類型のデバイス信号（時系列データ）を示す。デバイス信号には外部信号が含まれてもよい。なお、以下で説明する類型は一例であり、本発明を限定する意図はなくその他の類型にも本発明が適用されてもよい。また、本発明においては分類される類型は、分類効果を向上させるべく、これら複数の類型のうちの少なくとも２つの類型を含むことが望ましい。なお、モデル生成時における時系列データの分類は、オペレータが分類のための周期（制御サイクル）を決定するデバイスを選択することで、当該デバイスの繰り返し性に基づいて実行される。
図１３は、収集される時系列データの類型の一例を示す。１３０１～１３０６は各類型のデバイス信号（時系列データ）を示す。デバイス信号には外部信号が含まれてもよい。なお、以下で説明する類型は一例であり、本発明を限定する意図はなくその他の類型にも本発明が適用されてもよい。また、本発明においては分類される類型は、分類効果を向上させるべく、これら複数の類型のうちの少なくとも２つの類型を含むことが望ましい。なお、モデル生成時における時系列データの分類は、オペレータが分類のための周期（制御サイクル）を決定するデバイスを選択することで、当該デバイスの繰り返し性に基づいて実行される。
【0075】
１３０１は、装置の動作サイクルに同期して動作するデバイスのデバイス信号を示す。１３１０は装置の動作サイクルを示す。１３０１の類型は、装置の動作サイクルごとに同様の変化パターン（定常的な変化パターン）が発生する。この類型では、たとえば、正常状態とみなせる期間において取得された時系列データから定常的な変化パターンを特定し、新たに取得された時系列データについて特定した定常的な変化パターンからの乖離に基づいて異常デバイス（いつもと異なる状態のデバイス）を特定するといった検知手法が割り当てられる。具体的には、正常状態とみなせる複数周期の時系列データの変化パターンについて、変化点に関する時間のばらつきを測定し、測定されたばらつきに応じてしきい値を設定する。その後に取得された時系列データの変化点が変化点に対応して設定されたしきい値の範囲を超えるか否かに基づいて異常デバイスを検知する検知アルゴリズムが割り当てられる。たとえば、装置の動作サイクルごとの複数の波形を重ね合わせ、デバイスがＯＦＦからＯＮに変化した点のばらつきに基づき、当該変化点の基準値としきい値とを設定し、これらのパラメータを用いて異常デバイスを特定することができる。また、１３０１の各周期において、１回目の信号の立ち上がりタイミングを示す相対時刻や各周期における位相を評価変数とし、当該評価変数のばらつきに基づいて評価変数に対応するパラメータを決定してもよい。たとえば、各周期における位相を評価変数とした場合は、位相の上限しきい値と下限しきい値をそれぞれパラメータとしてもよい。
【0076】
分析ユニット４ａは各サイクル設定のパターンについて何れのデバイスが属するかを判断する場合、判断基準により１つのデバイスが複数のサイクル設定に属すると判断されることがある。多くのデバイスを何れかのサイクル設定に属するように判断基準を設けると、分析対象のデバイスを増やすことができ要因解明につながりやすいが、デバイスに対して関連度の低いサイクル設定が含まれるおそれがある。そこで、１つのデバイスが複数のサイクル設定に属すると判断されるものについては、属するサイクル設定を絞ってもよい。絞るための指標として、評価変数が小さいほど関連度が高いとし、評価変数が低いほど関連度が低いとしてサイクル設定から外すようにしてもよい。また、サイクルの開始と終了の間でデバイス値が変化するデバイスは関連度が高いと判断し、サイクルの開始と終了の間以外の期間でデバイス値が変化するデバイスは関連度が低いと判断する。さらに、サイクルの開始と終了の間以外の期間でデバイス値が変化するデバイスは、デバイス値が変化する時点がサイクルの開始や終了から乖離するほど関連度が低いとしてもよい。このようにして、１つのデバイスが複数のサイクル設定に属すると判断されるものについては、属するサイクル設定を絞ってもよい。
【0077】
一方、１３０２は、スキャン周期には同期せず、当該装置の動作サイクル以外の周期に同期して動作するデバイスのデバイス信号を示す。この類型についても、たとえば、正常状態とみなせる期間において取得された時系列データから定常的な変化パターンを特定し、新たに取得された時系列データについて特定した定常的な変化パターンからの乖離に基づいて異常デバイス（いつもと異なる状態のデバイス）を特定するといった検知手法が割り当てられる。具体的には、正常状態とみなせる複数周期の時系列データの変化パターンについて、変化点に関する時間のばらつきを測定し、測定されたばらつきに応じてしきい値を設定する。その後に取得された時系列データの変化点が変化点に対応して設定されたしきい値の範囲を超えるか否かに基づいて異常デバイスを検知する検知アルゴリズムが割り当てられる。また、１３０２の各周期において、２回目の信号の立ち上がりタイミングを示す相対時刻や各周期における位相を評価変数とし、当該評価変数のばらつきに基づいて評価変数に対応するパラメータを決定してもよい。たとえば、各周期における相対時刻を評価変数とした場合は、相対時刻の上限しきい値と下限しきい値をそれぞれパラメータとしてもよい。
【0078】
１３０３は、一定した値をとるデバイスのデバイス信号を示す。この類型では、たとえば、正常状態とみなせる期間において取得された時系列データから、正常時の値を特定し、新たに取得された時系列データについて、特定した正常時の値と異なるものを異常デバイス（いつもと異なる状態のデバイス）として特定するといった検知手法が割り当てられる。具体的には、正常状態とみなせる時系列データにおけるデバイスの値を検出基準値として設定し、その後に取得された時系列データの値が、正常時の値に対応して設定された検出基準値と異なるか否かに基づいて異常デバイスを検知する検知アルゴリズムが割り当てられる。つまり、値（一定値）が変化した場合に異常と判断することができる。１３０４は、不定期に動作するデバイスのデバイス信号を示す。この類型については、異常デバイスを特定する際に用いるデータからは除外される。１３０５は、アナログ値をとるデバイスのデバイス信号を示す。アナログ値をとるデバイスでは、後述するように、ビットデバイスのデバイス値ではないので、図１４でＳ９１のＮｏ（図１４のＳ９７）へ進み、図１４で示すように、データの変化方法に応じてそれぞれで推定フェーズにおけるアルゴリズムが異なる。アナログ値を取るデバイスの推定フェーズにおけるアルゴリズムとしては、動的時間伸縮法や自己回帰モデルなど種々の方法を利用することができる。１３０６は、単調増加、単調減少するデバイスのデバイス信号を示す。この類型では、微分値や積算値を用いて異常デバイスを特定する。また、単調増加または単調減少するタイミングを示す相対時刻や各周期における位相を評価変数として用いてもよい。なお、ここで説明した類型は一例であり、他の類型に分類されるデバイスも想定され、たとえば、（階段状のデバイス信号など）複数の状態をとりうるものなどがある。複数の状態をとるものについては、正常時の状態と異なる状態に変化した場合に異常と判断することもできる。
【0079】
ここで、デバイスの型について説明する。各デバイスは０、１のビット型のデバイスと、アナログ値をとる、ワード型のデバイスや浮動小数点数型のデバイスがある。なお、ワードデバイスには、さらに、１ワード符号なし整数（０～６５５３５）、１ワード符号あり整数（－３２７６８～３２７６７）、２ワード符号なし整数（０～４２９４９６７２９５）、および２ワード符号あり整数（－２１４７８３６４８～２１４７８３６４７）がある。このような型を考慮すると、たとえば、スキャン周期あたりの変化率が所定値以上で、型がビット以外であればアナログ値をとるデバイスであると判断することができる。
【0080】
＜分類処理フロー＞
図１４は、収集されたデータの変化パターンを分類する際の処理手順を示すフローチャートである。以下で説明する処理は、拡張ユニット４ａのＣＰＵ４１ａによって実現される。しかし、本発明を限定する意図はなく、それらの処理の一部が基本ユニット３や他の拡張ユニット４ｂで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。
図１４は、収集されたデータの変化パターンを分類する際の処理手順を示すフローチャートである。以下で説明する処理は、拡張ユニット４ａのＣＰＵ４１ａによって実現される。しかし、本発明を限定する意図はなく、それらの処理の一部が基本ユニット３や他の拡張ユニット４ｂで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。
【0081】
Ｓ９１でＣＰＵ４１ａは、分類対象の時系列データがビットデバイスのデバイス値であるか否かを判断する。ビットデバイスのデバイス値であればＳ９２に進み、そうでなければ、Ｓ９７に進む。
【0082】
Ｓ９２でＣＰＵ４１ａは、分類対象の時系列データの値に変化があるか否かを判断する。変化があればＳ９４へ進み、変化がなく一定値をとるものであればＳ９３に進む。Ｓ９３でＣＰＵ４１ａは分類対象の時系列データを一定値をとるデバイス（１３０３）であると分類し、処理を終了する。ここで分類情報として、当該時系列データに紐づく情報、たとえば分類された類型を示すフラグ情報が当該時系列データまたは当該時系列データに対応するデバイスを示す識別情報に紐づけて格納される。このように、学習フェーズの分類時において分類した類型のフラグ情報とデバイスの識別情報とを紐づけて格納しておくことにより、推定フェーズにおいては、検証対象の時系列データが何れのデバイスからのデータであるかに従って、当該デバイスの識別情報に紐づく類型に応じて、異常デバイスの検知アルゴリズムである評価変数やパラメータを容易に選択することができる。つまり、推定フェーズにおいては、検証対象の時系列データが何れの類型に対応するかを特定する処理を省略することができる。なお、分類情報としては、分類された類型を示すフラグ情報を例として示したが、フラグ情報に代えて異常デバイス特定のアルゴリズムを示すアルゴリズム情報であってもよい。また、分類情報として格納される識別情報は、時系列データに対応するデバイスが変数である場合は、当該変数を示す識別情報となることはいうまでもない。
【0083】
Ｓ９４でＣＰＵ４１ａは、時系列データの値に変化がある場合に、当該変化が各周期において定常的な変化パターンであるかを判断する。定常的な変化パターンであると判断した場合にはＳ９５に進み、定常的な変化パターンではないと判断した場合にはＳ９６に進む。ここで、定常的な変化パターンとは、各周期において同様のパターンで変化するものを示す。Ｓ９５でＣＰＵ４１ａは、所定の周期で動作するデバイスと分類し、処理を終了する。なお、所定の周期で動作するデバイスには、上述したように、装置の動作サイクルに同期して動作するデバイス（１３０１）と、装置の動作サイクル以外の周期に同期して動作するデバイス（１３０２）とがあり、ＣＰＵ４１ａは、それぞれへの分類を行う。一方、Ｓ９６でＣＰＵ４１ａは、不定期で動作するデバイス（１３０４）に分類し、処理を終了する。
【0084】
一方、Ｓ９１でビットデバイスでないと判断されると、Ｓ９７に進み、ＣＰＵ４１ａは、分類対象の時系列データにおいて所定値以上の変化があるか否かを判断する。ここでは、変化している信号の極値が所定値以上であるか否かを判断する。変化がある場合はＳ９８に進み、そうでない場合はＳ９１２に進む。
【0085】
Ｓ９８でＣＰＵ４１ａは、所定の周期で変化しているか否かを判断し、所定の周期で変化していなければＳ９９に進み、変化していればＳ９１０に進む。Ｓ９１０でＣＰＵ４１ａは、変化している値が単調増加又は単調減少しているか否かを判断する。単調増加又は単調減少していればＳ９１１に進み、そうでなければＳ９９に進む。
【0086】
Ｓ９９でＣＰＵ４１ａは、アナログ値のデバイス（１３０５）に分類し、処理を終了する。アナログ値のデバイスにおいては種々の類型が存在し、分類対象のデバイスの種別に応じてそれぞれ個別の対応が行われる。一方、Ｓ９１１でＣＰＵ４１ａは、単調増加又は単調減少のデバイス（１３０６）であると分類し、処理を終了する。また、Ｓ９１２でＣＰＵ４１ａは、その他のデバイスであると分類し、処理を終了する。その他のデバイスであると判断した場合には当該分類対象の時系列データの特徴が抽出できないものであり、正常時の特徴のある動作を特定できないため、異常デバイスを特定する際には用いない。
【0087】
＜結果表示フロー＞
図１５は、上記Ｓ７における分析ユニット４ａによる結果表示フローの詳細を示す。以下で説明する処理は、分析ユニット（拡張ユニット）４ａのＣＰＵ４１ａによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。
図１５は、上記Ｓ７における分析ユニット４ａによる結果表示フローの詳細を示す。以下で説明する処理は、分析ユニット（拡張ユニット）４ａのＣＰＵ４１ａによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。
【0088】
まずＳ７１で分析ユニット４ａのＣＰＵ４１ａは、分析レポートの要求を受け付けたか否かを判断する。分析レポートの要求とはオペレータによってＰＣ２ａ、ＰＣ２ｂを介して受信する要求や、定期的な分析レポート生成タイミング、エラー発生時の分析レポートの作成などが含まれる。ＰＬＣ１としては、いつもと異なる状態のデバイスが検知された場合にはオペレータからの要求なしに分析レポートを作成してもよいし、オペレータからの要求があって初めて分析レポートを作成するようにしてもよい。これらの制御は設定で切り替えることができる。分析レポートの要求を受け付けていればＳ７２に進む。
【0089】
Ｓ７２でＣＰＵ４１ａは、基本ユニット３の運転記録記憶部３７に格納された分析結果７７を取得する。続いて、Ｓ７３でＣＰＵ４１ａは、取得した分析結果に従って、ＰＣ２ａやＰＣ２ｂなどのＷｅｂクライアントのＷｅｂブラウザで表示可能な分析レポートを生成する。生成する分析レポートは図８Ａを用いて上述した結果表示画面８００を表示するための画面情報となる。ここでは、各分析結果を同期させて表示するための同期情報も付加される。具体的には、検知マップ８１０、検知リスト８２０、画像表示領域８３０、および分析コメント８４０に表示する画面情報に加えて、各分析結果の表示位置を示唆する情報が含まれる。表示位置を示唆する情報とは、上述したように、定義された制御サイクルのタイミング情報であってもよいし、単なる時刻情報であってもよい。即ち、同期可能な情報であればよい。また、ＣＰＵ４１ａは分析コメント８４０を生成し、分析レポートに埋め込む。分析コメントの生成フローについては、図１７および図１８を用いて後述する。
【0090】
次に、Ｓ７４でＣＰＵ４１ａは、Ｓ７３で生成した分析レポートを要求元のＰＣ２へ送信する。ここで送信する情報は、ＨＴＭＬデータ、ＣＳＳデータおよびＪａｖａＳｃｒｉｐｔ（登録商標）コードなどを含む情報であってもいし、単に分析レポートの生成が完了したことを示す通知であってもよい。通知を行う場合には改めてＰＣ２側から表示要求を受け付けると、ＣＰＵ４１ａは画面情報を送信する。その後、Ｓ７５でＣＰＵ４１ａは、要求元から分析レポートの更新要求が受け付けたか否かを判断する。更新要求とは、たとえば表示部品の変更や、フィルタ８０１～８０３の選択による表示対象の変更、時刻バー８１１などを操作したことにより分析結果の時間的な表示位置の更新などである。なお、時刻バー８１１などを操作したことによる表示内容の更新については、ＰＣ２側に閉じた制御としてもよい。この場合、表示対象となっている表示部品の情報に加えて、当該表示部品上で表示しているデバイスの分析結果についての情報もＰＣ２側へ提供する必要がある。更新要求を受け付けるとＳ７６に進み、そうでない場合はＳ７７に進む。
【0091】
Ｓ７６でＣＰＵ４１ａは、更新要求の指示内容に従って分析レポートを更新し、処理をＳ７４へ戻し更新した分析レポートを要求元へ送信する。一方、Ｓ７７でＣＰＵ４１ａは、分析レポートの表示を終了する終了指示を受け付けたか否かを判断する。終了指示を受け付けていない場合は処理をＳ７５に戻し、終了指示を受け付けたと判断した場合は処理を終了する。
【0092】
図１６は、上記Ｓ７におけるＰＣ２ｂにおける結果表示フローの詳細を示す。以下で説明する処理は、ＰＣ２ｂのＣＰＵ１１ｂによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部がＰＬＣのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された他の外部装置（ＰＣ２ａなど）によって実行されてもよい。ＰＬＣのユニットで実行される場合には当該ユニットにはモニタが設けられる。また、ここで説明する処理は、分析ユニット４ａによって生成された分析レポートをブラウザとして表示する処理である。
【0093】
Ｓ８１でＣＰＵ１１ｂは、操作部８ｂを介して分析レポートの表示要求を受け付けたか否かを判断する。受け付けた場合にはＳ８２に進む。Ｓ８２でＣＰＵ１１ｂは、分析レポートを分析ユニット４ａに対して要求する。その後、Ｓ８３でＣＰＵ１１ｂは、分析ユニット４ａから要求に対応する応答（分析レポート）を受信したか否かを判断する。ここで受信する情報としては、分析レポートを表示させるためのＵＲＬ（ＩＰアドレス）であってもよいし、分析レポートそのものの情報であってもよい。ここではＵＲＬを受信したものとして以下の処理を説明する。
【0094】
応答を受信するとＳ８４でＣＰＵ１１ｂは、Ｗｅｂブラウザ１８に指定して分析レポートを表示させる。続いて、Ｓ８５でＣＰＵ１１ｂは、分析レポートの表示を更新する更新要求を受け付けたか否かを判断する。受け付けた場合はＳ８６へ進み、そうでない場合はＳ８７へ進む。Ｓ８６で、更新要求を受け付けるとＳ８６でＣＰＵ１１ｂは、更新要求をＷｅｂサーバである分析ユニット４ａへ送信し、処理をＳ８３に戻す。一方、更新要求でない場合はＳ８７でＣＰＵ１１ｂは、分析レポートの表示を終了する終了指示を受け付けたか否かを判断する。終了指示を受け付けていないと判断した場合は処理をＳ８５へ戻し、終了指示を受け付けたと判断した場合は処理を終了する。
【0095】
＜分析コメント生成フロー（自然言語表現）＞
図１７は自然言語による分析コメントの生成フローを示す。ここで説明する処理は、分析レポートを生成する上記Ｓ７３の処理の一部（分析コメントの生成に関わる処理）である。以下で説明する処理は、分析ユニット（拡張ユニット）４ａのＣＰＵ４１ａによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。
図１７は自然言語による分析コメントの生成フローを示す。ここで説明する処理は、分析レポートを生成する上記Ｓ７３の処理の一部（分析コメントの生成に関わる処理）である。以下で説明する処理は、分析ユニット（拡張ユニット）４ａのＣＰＵ４１ａによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。
【0096】
まずＳ７３１で分析ユニット４ａのＣＰＵ４１ａは、Ｓ７２で取得された分析結果を取得する。取得される分析結果１７００には、図１７に示すように、各デバイスの異常の種類の情報がそれぞれ含まれ、さらに詳細な情報やデバイス名、デバイスコメント等が含まれる。ここで、デバイスコメントとは、オペレータがユーザプログラムの編集画面等で特定のデバイスに対して入力したコメントを示す。オペレータは全てのデバイスにコメントを付すのではなく、通常、使用するデバイスに対してコメントを付すものである。したがって、デバイスコメントはオペレータにとって有用な情報となる。異常の種類には、１７０１に示す無変化デバイスが変化したパターン、１７０２に示すＯＮ／ＯＦＦの変化回数が異常であるパターン、および１７０３に示すＯＮ／ＯＦＦの時間が異常であるパターンなどが含まれる。それぞれの異常について、詳細情報として、たとえば正常時および異常時の変化パターンや時間間隔、変化回数、閾値、詳細な情報などが含まれる。つまり、詳細情報とは、上述した分析パラメータに相当するものである。
【0097】
次に、Ｓ７３２でＣＰＵ４１ａは、デバイス毎の異常内容に従って、予め保持されているメッセージフォーマットをメモリ４２ａから選択して取得する。予め保持されているメッセージフォーマットを１７２０に示す。メッセージフォーマット１７２０には、異常の種類ごとに、自然言語による分析コメントを生成する際のフォーマットが定義されている。ＣＰＵ４１ａは、デバイスの異常内容に応じて該当するメッセージフォーマットを選択する。１７０４には無変化デバイスが変化したパターンのメッセージフォーマット１７０５が定義されている。１７０６にはＯＮ／ＯＦＦの変化回数が異常であるパターンのメッセージフォーマット１７０７が定義されている。１７０８にはＯＮ／ＯＦＦの時間が異常であるパターンのメッセージフォーマット１７０９が定義されている。
【0098】
次に、Ｓ７３３でＣＰＵ４１ａは、選択したメッセージフォーマットに各デバイスの異常内容（分析結果）に応じた数値や自然言語を選択して埋め込む。より詳細には、メッセージフォーマット１７０５、１７０７、１７０９に示す”｛｝”に、各デバイスの異常内容（分析結果）に応じた値や自然言語が埋め込まれる。さらに、Ｓ７３４でＣＰＵ４１ａは、他の分析結果、たとえば検知マップ８１０、検知リスト８２０、および画像表示領域８３０に加えて、生成した分析コメントを加えた分析レポートを生成し、処理を終了する。
【0099】
＜分析コメント生成フロー（図形表現）＞
図１８は図形による分析コメントの生成フローを示す。ここで説明する処理は、分析レポートを生成する上記Ｓ７３の処理の一部（分析コメントの生成に関わる処理）である。以下で説明する処理は、分析ユニット（拡張ユニット）４ａのＣＰＵ４１ａによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。
図１８は図形による分析コメントの生成フローを示す。ここで説明する処理は、分析レポートを生成する上記Ｓ７３の処理の一部（分析コメントの生成に関わる処理）である。以下で説明する処理は、分析ユニット（拡張ユニット）４ａのＣＰＵ４１ａによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。
【0100】
まずＳ７３６で分析ユニット４ａのＣＰＵ４１ａは、Ｓ７２で取得された分析結果を取得する。取得される分析結果１８００には、図１８に示すように、各デバイスの異常の種類の情報がそれぞれ含まれ、さらに詳細な情報やデバイス名、デバイスコメント等が含まれる。異常の種類には、１８０１に示すＯＮ／ＯＦＦの変化回数が異常であるパターン、および１８０２に示すＯＮ／ＯＦＦの時間が異常であるパターンなどが含まれる。もちろん他の異常内容のパターンが含まれてもよい。それぞれの異常について、詳細情報として、たとえば正常時および異常時の変化パターンや時間間隔、変化回数、閾値、詳細な情報などが含まれる。つまり、詳細情報とは、上述した分析パラメータに相当するものである。
【0101】
次に、Ｓ７３７でＣＰＵ４１ａは、デバイス毎の異常内容に従って、予め保持されている図形フォーマットをメモリ４２ａから選択して取得する。予め保持されている図形フォーマットを１８２０に示す。図形フォーマット１８２０には、異常の種類ごとに、図形による分析コメントを生成する際のフォーマットが定義されている。ＣＰＵ４１ａは、デバイスの異常内容に応じて該当する図形フォーマットを選択する。１８０３にはＯＮ／ＯＦＦの変化回数が異常であるパターンの図形フォーマット１８０４～１８０８が定義されている。１８０９にはＯＮ／ＯＦＦの時間が異常であるパターンの図形フォーマット１８１０～１８１６が定義されている。
【0102】
次に、Ｓ７３８でＣＰＵ４１ａは、選択した図形フォーマットに各デバイスの異常内容（分析結果）に応じた図形（一部文言や数値を含む。）を選択して埋め込む。より詳細には、図形フォーマット１８０４～１８０８、１８１０～１８１６に示す”？”の領域に、各デバイスの異常内容（分析結果）に応じた図形が埋め込まれる。さらに、Ｓ７３９でＣＰＵ４１ａは、他の分析結果、たとえば検知マップ８１０、検知リスト８２０、および画像表示領域８３０に加えて、生成した分析コメントを加えた分析レポートを生成し、処理を終了する。
【0103】
なお、分析コメント８４０に示すように、自然言語による異常内容の表現と、図形による異常内容の表現とが同時に含まれてもよい。この場合、上記図１７のフローチャートと上記図１８のフローチャートを実行するか、或いは、２つのフローチャートを合体したフローチャートとを実行することにより実現される。
【0104】
＜サイクル設定＞
図１９は、サイクルを定義する設定画面１９００を示す。設定画面１９００は、たとえばＰＣ２ａの表示部７ａに表示中のＵＩ１００から所定の操作が行われた場合に表示部７ａに表示される画面である。図１９に示すように、ＵＩ１００上に表示されているプログラムエディタに重畳して表示されてもよいし、ＵＩ１００に表示されているプログラムエディタから遷移する画面として表示されてもよい。なお、設定画面１９００はＰＣ２ｂ上のＷｅｂブラウザ１８上で表示されてもよい。
図１９は、サイクルを定義する設定画面１９００を示す。設定画面１９００は、たとえばＰＣ２ａの表示部７ａに表示中のＵＩ１００から所定の操作が行われた場合に表示部７ａに表示される画面である。図１９に示すように、ＵＩ１００上に表示されているプログラムエディタに重畳して表示されてもよいし、ＵＩ１００に表示されているプログラムエディタから遷移する画面として表示されてもよい。なお、設定画面１９００はＰＣ２ｂ上のＷｅｂブラウザ１８上で表示されてもよい。
【0105】
設定画面１９００には、運転記録分析を行う際のアプリケーションやアプリケーション名を指定する設定領域１９０１、１９０２が含まれる。これらの設定領域１９０１、１９０２は分析対象を設定するためのものである。図１９にはデフォルトの設定が示してあり、オペレータは特に設定しなくてもよい。さらに、設定画面１９００には基本設定の領域が有り、ここで制御サイクルを指定することができる。１９０３は制御サイクルの指定方法を設定し、１９０４はサイクル名を設定し、１９０５は開始トリガを設定し、１９０６は終了トリガを設定することができる。また、デフォルトでは制御サイクルは指定されておらず、追加ボタン１９０７のみが表示されている。
【0106】
図１９に示す例では、Ｎｏ．０，１，２の制御サイクルが既に指定されている状態を示す。本実施形態によれば、このように分析対象となる制御サイクルとして、１以上の制御サイクルを指定することができる。したがって、オペレータは広範囲に分析したい場合においては、複数の制御サイクルを指定することでより意図した分析レポートを確認することができる。指定方法１９０３は制御サイクルの起点となる開始タイミングおよび終点となる終了タイミングを指定する開始・終了指定と、開始タイミングのみを指定する開始指定を選択することができる。したがって、終了トリガ１９０６は開始・終了指定が選択された場合にのみ終了タイミングを指定することができる。ここでは、各サイクル定義毎に、所属するデバイスやデバイスのグループを設定していない。したがって、分析ユニット４ａ等が定義された制御サイクルに対応するデバイスを特定して分析を行うことになる。複数の制御サイクルを指定可能であるため、１つのデバイスが複数の制御サイクルに対応する可能性もある。この場合においては、分析対象として優先度をより高く設定するようにしてもよい。当該優先度が高ければ分析レポートにおいて優先的に表示するようにしてもよい。一方で、特定のデバイスを各サイクル定義に紐づける設定を行えるようにしてもよい。
【0107】
設定画面１９００にはさらに、設定保存１９１１、設定読出１９１２、ＯＫボタン１９１３、およびキャンセルボタン１９１４を含んで構成される。設定保存１９１１は設定画面１９００内で設定された設定内容を保存するためのボタンである。設定読出１９１２は基本ユニット３のメモリ３２のプロジェクト記憶部３５に予め保持されている設定ファイルを読み出すためのボタンである。当該設定ファイルには、１以上の制御サイクルが予め指定されている。当該設定ファイルを読み出した後に、さらに制御サイクルを追加することも可能である。ＯＫボタン１９１３は設定画面１９００上に設定されている内容を有効にして設定処理を終了するためのボタンである。キャンセルボタン１９１４は設定画面１９００上に設定されている内容を適用することなく設定処理を終了するためのボタンである。
【0108】
＜サイクル未設定＞
図２０はサイクル未設定の分析レポートの検知マップ８１０を示す。分析ユニット４ａはサイクル未設定であっても分析は可能であるが、分析可能なデバイスは極端に少ない。つまり、サイクルパターンを有していないデバイスに限られる。サイクルパターンを有していないデバイスとは、たとえばデバイス値が固定値で変化しないデバイスである。たとえば、図２０の２００１に示すように、常時ＯＮや常時ＯＦＦのデバイスはサイクルが未設定であっても分析を行うことができる。一方、所定のサイクルパターンを有するデバイスについてはサイクルが未設定であれば分析を行うことができない。このように、分析可能なデバイスが少ないため、サイクルが未設定の場合も分析自体は可能であるものの、分析結果の有効性は限定的である。したがって、図２０に示すように、分析レポートにおいて、サイクルが未設定である旨と、サイクル設定を促すメッセージ２００２を表示するようにしてもよい。「サイクル設定して分析する」が選択されるとサイクル設定のポップアップ画面が表示され、オペレータはサイクル設定を行うことができる。
図２０はサイクル未設定の分析レポートの検知マップ８１０を示す。分析ユニット４ａはサイクル未設定であっても分析は可能であるが、分析可能なデバイスは極端に少ない。つまり、サイクルパターンを有していないデバイスに限られる。サイクルパターンを有していないデバイスとは、たとえばデバイス値が固定値で変化しないデバイスである。たとえば、図２０の２００１に示すように、常時ＯＮや常時ＯＦＦのデバイスはサイクルが未設定であっても分析を行うことができる。一方、所定のサイクルパターンを有するデバイスについてはサイクルが未設定であれば分析を行うことができない。このように、分析可能なデバイスが少ないため、サイクルが未設定の場合も分析自体は可能であるものの、分析結果の有効性は限定的である。したがって、図２０に示すように、分析レポートにおいて、サイクルが未設定である旨と、サイクル設定を促すメッセージ２００２を表示するようにしてもよい。「サイクル設定して分析する」が選択されるとサイクル設定のポップアップ画面が表示され、オペレータはサイクル設定を行うことができる。
【0109】
＜モデル信頼度＞
図２１はモデル信頼度を説明する図である。ここでは、図１０の１０３０で示したモデル信頼度について詳細に説明する。生成したモデルは生成時に扱ったデータ量に応じてその信頼度が変化するものである。そこで、分析ユニット４ａは、モデル生成時にそのモデルの信頼度を測定して、属性情報としてモデルに付加する。図２１には、１０サイクルの運転記録データを取得した場合に、モデル生成と分析を行う様子が示されている。たとえば、１０サイクルの運転記録データを取得したとしても、シンプルなデバイスではモデル生成に十分なデータであるものの、非同期のデバイスなどでは不十分な可能性もある。従って、サイクル数だけでは生成したモデルの信頼度を推測することは難しい。そこでモデルの信頼度を測定して提示することができれば学習時には、良いモデルができたかどうかをオペレータが判断することができ、異常検知時には検知した内容が信頼できるものかをオペレータが判断することができる。
図２１はモデル信頼度を説明する図である。ここでは、図１０の１０３０で示したモデル信頼度について詳細に説明する。生成したモデルは生成時に扱ったデータ量に応じてその信頼度が変化するものである。そこで、分析ユニット４ａは、モデル生成時にそのモデルの信頼度を測定して、属性情報としてモデルに付加する。図２１には、１０サイクルの運転記録データを取得した場合に、モデル生成と分析を行う様子が示されている。たとえば、１０サイクルの運転記録データを取得したとしても、シンプルなデバイスではモデル生成に十分なデータであるものの、非同期のデバイスなどでは不十分な可能性もある。従って、サイクル数だけでは生成したモデルの信頼度を推測することは難しい。そこでモデルの信頼度を測定して提示することができれば学習時には、良いモデルができたかどうかをオペレータが判断することができ、異常検知時には検知した内容が信頼できるものかをオペレータが判断することができる。
【0110】
２１０１～２１０３は学習時に、正常データを１サイクルずつ学習、追加学習を繰り返し、次のサイクルのデータを分析した様子を示す。２１０１は７サイクルを利用してモデルを生成し、８サイクル目を分析した場合を示す。２１０２は８サイクルを利用してモデルを生成し、９サイクル目を分析した場合を示す。２１０３は９サイクルを利用してモデルを生成し、１０サイクル目を分析した場合を示す。図２１に示す例では、たとえば、それぞれ生成したモデルにおいて、異常の検知数は、２１０１で８つ、２１０２で３つ、２１０３で５つとなる。本来正常データであるため検知数は０になることが望ましい。しかし、正常データの量が不十分である場合には０にならない。これらの異常の検知数をそのまま信頼度としてオペレータに提示してもよいが、検知個数を信頼度に正規化して提示してもよい。たとえば、検知数が０であれば信頼度を最も高い”３”とし、検知数が１～１０であれば信頼度を”２”として、検知数が１１～２０であれば信頼度を”１”とし、検知数が２１以上であれば信頼度を”０”としてもよい。たとえば、図２１に示すように、２１０１の検知数が最も多い測定値を利用して信頼度を取得してもよい。なお、学習が一旦終了したタイミングで学習の完了と生成したモデルの信頼度を提示し、更なる学習を行うかをオペレータに選択させてもよい。或いは、所定の信頼度に到達するまで学習を繰り返すようにしてもよい。
【0111】
＜変形例＞
本発明は上記実施形態に限らず様々な変形が可能である。以下では種々の変形例について図面を参照して説明する。
本発明は上記実施形態に限らず様々な変形が可能である。以下では種々の変形例について図面を参照して説明する。
【0112】
＜システム構成の変形例＞
図２２はＰＬＣシステム構成の変形例を示す。上記実施形態では、ＰＬＣシステムとして、基本ユニット３、分析ユニット４ａ、およびカメラユニットなどの拡張ユニット４ｂで構成されるＰＬＣ１と、基本ユニット３に接続されるＰＣ２ａと、分析ユニット４ａに接続される分析レポートを表示するＰＣ２ｂとを含んで構成される例について説明した。しかし、これらの構成は一例であって、上述した運転記録データの収集、モデルの生成、分析、分析結果の表示については何れの装置やユニットで行われてもよいし、さらに他の外部装置や他の拡張ユニットによって実現されてもよい。ここではそのような構成の変形例について説明する。
図２２はＰＬＣシステム構成の変形例を示す。上記実施形態では、ＰＬＣシステムとして、基本ユニット３、分析ユニット４ａ、およびカメラユニットなどの拡張ユニット４ｂで構成されるＰＬＣ１と、基本ユニット３に接続されるＰＣ２ａと、分析ユニット４ａに接続される分析レポートを表示するＰＣ２ｂとを含んで構成される例について説明した。しかし、これらの構成は一例であって、上述した運転記録データの収集、モデルの生成、分析、分析結果の表示については何れの装置やユニットで行われてもよいし、さらに他の外部装置や他の拡張ユニットによって実現されてもよい。ここではそのような構成の変形例について説明する。
【0113】
たとえば、図２２に示すように、上記実施形態に係る分析ユニット４ａの機能をＰＬＣ１の上位層に配置される分析装置（データ処理装置として機能する）２ｃで実現してもよい。モデルの学習フェーズの処理などは非常に処理負荷が高く、処理時間を要するものであるため、ＰＬＣユニットの処理能力に応じて外部で実現することも想定され得る。また、上位層の装置に分析機能を設けることにより、他のＰＬＣからも情報を吸い上げることもでき、より信頼度の高いモデルを生成することも可能となる。分析装置２ｃは、ＰＬＣ固有情報の解析、モデルの生成、分析、分析レポートの作成などの機能を有する。これらの機能については、分析ユニット４ａと同様の処理であるため説明を省略する。
【0114】
また、上記実施形態では、基本ユニット３が全デバイスの運転記録データを収集していたが、他の拡張ユニット行ってもよい。たとえば、図２２に示すように、拡張ユニットとしてレコーダユニット４ｃを設けてもよい。レコーダユニット４ｃはＣＰＵ４１ｃと、メモリ４２ｃと、通信部４３ｃとを備える。メモリ４２ｃには、上記実施形態で基本ユニット３に設けられていたリングバッファ４４ｃと、運転記録記憶部４５ｃとの記憶領域が設けられる。運転記録の収集については、上記実施形態の基本ユニット３と同様の処理であるため詳細な説明については省略する。
【0115】
このように、本発明によれば、上記実施形態で説明した処理機能を実現する装置又はユニットは可能な範囲で変更することができるものであり、本発明はそれらの変形を包括するものである。上記変形例では、基本ユニット３とは別に運転記録データを収集するレコーダユニット４ｃを設ける例を説明したが、当該ユニットには収集機能および通信機能を設けて、保存先についてはネットワークを介して接続されたデータベースとしてもよい。これにより、より大容量のデータを保存することができ、トリガ発生時よりもかなり遡った解析を行うことができるとともに、他のＰＬＣシステムのデータも利用することが可能となる。
【0116】
また、上記変形例では、処理機能を基本ユニット３とは別のユニットで実現したり、外部装置で実現する例について説明したが、基本ユニット３にそれらの処理機能を一体化する形態であってもよい。このような構成のメリットは、他のユニットや外部装置との通信処理を省略できるため通信による処理負荷を低減でき、ＰＬＣ制御への影響を低減することができる点にある。なお、一体化する場合においての性能は基本ユニット３の性能に依存することになるため、基本ユニット３の高性能化が必要となる。
【0117】
＜まとめ＞
［観点１］
本発明は、分析装置であって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎の分析パラメータを含むモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果に基づき、前記分析パラメータに応じた表現を含む分析レポートを生成するレポート生成手段とを備える。本実施形態によれば、運転記録データの分析結果に従って、異常の要因を容易に識別可能なレポートを提供することができる。また、煩雑なユーザ操作を必要とすることなく異常の要因を容易に識別可能なレポートを提供することができる。
［観点１］
本発明は、分析装置であって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎の分析パラメータを含むモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果に基づき、前記分析パラメータに応じた表現を含む分析レポートを生成するレポート生成手段とを備える。本実施形態によれば、運転記録データの分析結果に従って、異常の要因を容易に識別可能なレポートを提供することができる。また、煩雑なユーザ操作を必要とすることなく異常の要因を容易に識別可能なレポートを提供することができる。
【0118】
［観点２］
上記実施形態において、前記分析パラメータに応じた表現は、該分析パラメータに応じて分析結果を示す、自然言語での表現および図形での表現の少なくとも１つを含む。本実施形態によれば、自然言語による異常内容の表現により、自然言語が人同士の会話と同様の方法であるため、ユーザは新しく覚えることが少なくなり、専門的な知識を必要とすることなく異常内容を容易に解析できる。一方、図形による異常内容の表現により、視覚的に理解でき、どのような異常だったか、タイミングや異常度合いなどの詳細を知ることができる。
上記実施形態において、前記分析パラメータに応じた表現は、該分析パラメータに応じて分析結果を示す、自然言語での表現および図形での表現の少なくとも１つを含む。本実施形態によれば、自然言語による異常内容の表現により、自然言語が人同士の会話と同様の方法であるため、ユーザは新しく覚えることが少なくなり、専門的な知識を必要とすることなく異常内容を容易に解析できる。一方、図形による異常内容の表現により、視覚的に理解でき、どのような異常だったか、タイミングや異常度合いなどの詳細を知ることができる。
【0119】
［観点３］
上記実施形態において、前記自然言語での表現および前記図形での表現のそれぞれは、異常内容に応じたフォーマットが予め定義され、前記レポート生成手段は、デバイス毎の異常内容に応じて前記フォーマットを選択して前記分析パラメータに応じた表現を生成する。本実施形態によれば、分析コメントにおける自然言語による表現や、図形による表現を、予め保持しているデータベースを用いて自動で作成できるため、オペレータによる煩雑な操作を必要とすることなく実現することができる。
上記実施形態において、前記自然言語での表現および前記図形での表現のそれぞれは、異常内容に応じたフォーマットが予め定義され、前記レポート生成手段は、デバイス毎の異常内容に応じて前記フォーマットを選択して前記分析パラメータに応じた表現を生成する。本実施形態によれば、分析コメントにおける自然言語による表現や、図形による表現を、予め保持しているデータベースを用いて自動で作成できるため、オペレータによる煩雑な操作を必要とすることなく実現することができる。
【0120】
［観点４］
上記実施形態において、前記レポート生成手段は、前記異常内容に応じたフォーマットに、前記分析結果に基づく自然言語又は図形を選択して埋め込むことにより前記自然言語の表現を生成する。本実施液体によれば、異常内容に応じたフォーマットに自然言語や図形を埋め込むなどの簡易な処理によって上記実施形態と同様の効果を得ることができる。
上記実施形態において、前記レポート生成手段は、前記異常内容に応じたフォーマットに、前記分析結果に基づく自然言語又は図形を選択して埋め込むことにより前記自然言語の表現を生成する。本実施液体によれば、異常内容に応じたフォーマットに自然言語や図形を埋め込むなどの簡易な処理によって上記実施形態と同様の効果を得ることができる。
【0121】
［観点５］
上記実施形態において、前記図形での表現には、正常時のデバイスの波形と、非正常デバイスとして検知された波形とが対比可能に含まれる。本実施形態によれば、正常時の動作と分析対象の動作とを対比して確認することができ、いつもと違う動作をより容易に把握することができる。
上記実施形態において、前記図形での表現には、正常時のデバイスの波形と、非正常デバイスとして検知された波形とが対比可能に含まれる。本実施形態によれば、正常時の動作と分析対象の動作とを対比して確認することができ、いつもと違う動作をより容易に把握することができる。
【0122】
［観点６］
上記実施形態において、前記非正常デバイスとして検知された波形には、異常箇所が強調表示される。本実施形態によれば、検知された波形の何れの位置で異常が発生しているかを容易に確認することができる。
上記実施形態において、前記非正常デバイスとして検知された波形には、異常箇所が強調表示される。本実施形態によれば、検知された波形の何れの位置で異常が発生しているかを容易に確認することができる。
【0123】
［観点７］
上記実施形態において、前記モデル生成手段は、各デバイスの前記時系列の複数のデバイス値から、各デバイスを変化パターンを示す複数の類型の何れかにそれぞれ分類し、分類された類型に従って前記分析手段で非正常デバイスを検知する際に用いる前記分析パラメータを決定する。本実施形態によれば、デバイスの変化パターンの類型ごとに適切な分析を行うことができ、より正確な分析結果を得ることができる。
上記実施形態において、前記モデル生成手段は、各デバイスの前記時系列の複数のデバイス値から、各デバイスを変化パターンを示す複数の類型の何れかにそれぞれ分類し、分類された類型に従って前記分析手段で非正常デバイスを検知する際に用いる前記分析パラメータを決定する。本実施形態によれば、デバイスの変化パターンの類型ごとに適切な分析を行うことができ、より正確な分析結果を得ることができる。
【0124】
［観点８］
上記実施形態において、前記分析パラメータには、デバイス値のＯＮの時間、ＯＦＦの時間、立ち上がりのタイミング、立ち下がりのタイミング、ＯＮの回数、ＯＦＦの回数、および定常値の少なくとも１つが含まれる。本実施形態によれば、種々の変化パターンに対応して分析することが可能であり、より正確な分析結果を得ることができる。
上記実施形態において、前記分析パラメータには、デバイス値のＯＮの時間、ＯＦＦの時間、立ち上がりのタイミング、立ち下がりのタイミング、ＯＮの回数、ＯＦＦの回数、および定常値の少なくとも１つが含まれる。本実施形態によれば、種々の変化パターンに対応して分析することが可能であり、より正確な分析結果を得ることができる。
【0125】
［観点９］
上記実施形態において、前記レポート生成手段から出力された前記分析レポートの内容を示す結果表示画面の画面情報を外部装置へ送信する送信手段をさらに備え、前記外部装置では、前記結果表示画面が操作可能に表示部に表示される。本実施形態によれば、分析レポートを外部装置へ送信することができ、たとえばより高性能のＰＣ等で分析レポートを解析することができ、より詳細な分析やよりリッチな操作体系を有する結果表示画面の表示を可能とする。
上記実施形態において、前記レポート生成手段から出力された前記分析レポートの内容を示す結果表示画面の画面情報を外部装置へ送信する送信手段をさらに備え、前記外部装置では、前記結果表示画面が操作可能に表示部に表示される。本実施形態によれば、分析レポートを外部装置へ送信することができ、たとえばより高性能のＰＣ等で分析レポートを解析することができ、より詳細な分析やよりリッチな操作体系を有する結果表示画面の表示を可能とする。
【0126】
［観点１０］
上記実施形態において、前記結果表示画面には、さらに、前記分析レポートの表示項目を絞るための条件を指定可能なフィルタ設定領域が含まれる。本実施形態によれば、不要な表示項目を結果表示画面から除外することができ、より容易に異常の解析を行うことができる。
上記実施形態において、前記結果表示画面には、さらに、前記分析レポートの表示項目を絞るための条件を指定可能なフィルタ設定領域が含まれる。本実施形態によれば、不要な表示項目を結果表示画面から除外することができ、より容易に異常の解析を行うことができる。
【0127】
［観点１１］
上記実施形態において、前記フィルタ設定領域では、デバイスの制御サイクルの指定、属性情報の指定、および、イベント、エラーの指定の少なくとも１つによってフィルタが指定可能である。本実施形態によれば、オペレータが表示項目を絞る際に種々の選択肢を提供することができる。
上記実施形態において、前記フィルタ設定領域では、デバイスの制御サイクルの指定、属性情報の指定、および、イベント、エラーの指定の少なくとも１つによってフィルタが指定可能である。本実施形態によれば、オペレータが表示項目を絞る際に種々の選択肢を提供することができる。
【0128】
［観点１２］
上記実施形態において、前記ユーザプログラムの編集画面を表示する表示手段をさらに備え、前記編集画面では、該編集画面の時間軸に同期した前記分析レポートが表示可能である。本実施形態によれば、ユーザプログラムと連携して分析レポートを表示することができ、ユーザプログラムも加味した分析を行うことができる。
上記実施形態において、前記ユーザプログラムの編集画面を表示する表示手段をさらに備え、前記編集画面では、該編集画面の時間軸に同期した前記分析レポートが表示可能である。本実施形態によれば、ユーザプログラムと連携して分析レポートを表示することができ、ユーザプログラムも加味した分析を行うことができる。
【0129】
［観点１３］
上記実施形態において、前記分析レポートの生成要求を受け付ける受付手段と、前記レポート生成手段によって前記生成要求に応じて前記分析レポートが生成されると、要求元に分析レポートの生成が完了した旨を通知する通知手段とをさらに備える。本実施形態によれば、分析レポートの生成が完了した旨をオペレータに通知することができ、よりユーザフレンドリな操作体系を実現することができる。
上記実施形態において、前記分析レポートの生成要求を受け付ける受付手段と、前記レポート生成手段によって前記生成要求に応じて前記分析レポートが生成されると、要求元に分析レポートの生成が完了した旨を通知する通知手段とをさらに備える。本実施形態によれば、分析レポートの生成が完了した旨をオペレータに通知することができ、よりユーザフレンドリな操作体系を実現することができる。
【0130】
［観点１４］
上記実施形態において、１以上の制御サイクルの定義を設定する設定手段をさらに備え、前記モデル生成手段は、設定された前記１以上の制御サイクルの定義に基づいて、取得された前記運転記録データの学習を行い、前記レポート生成手段は、前記非正常デバイスとして検知した各デバイスの分析結果を、設定された前記１以上の制御サイクルの定義に従って各デバイスの分析結果を時間軸上に同期させて表示する分析レポートを生成する。本実施形態によれば、制御サイクルに従って、学習フェーズ及び推定フェーズの処理を行うことができ、処理を簡略することができるとともに、正確な分析や同期を行うことができる。
上記実施形態において、１以上の制御サイクルの定義を設定する設定手段をさらに備え、前記モデル生成手段は、設定された前記１以上の制御サイクルの定義に基づいて、取得された前記運転記録データの学習を行い、前記レポート生成手段は、前記非正常デバイスとして検知した各デバイスの分析結果を、設定された前記１以上の制御サイクルの定義に従って各デバイスの分析結果を時間軸上に同期させて表示する分析レポートを生成する。本実施形態によれば、制御サイクルに従って、学習フェーズ及び推定フェーズの処理を行うことができ、処理を簡略することができるとともに、正確な分析や同期を行うことができる。
【0131】
［観点１５］
上記実施形態において、前記分析手段は、前記設定手段によって制御サイクルが定義されていない場合において、制御サイクルのサイクルパターンを有していないデバイスを分析対象として、前記運転記録データを分析する。本実施形態によれば、オペレータに対してサイクルパターンの設定操作を要求することなく分析レポートを容易に出力することができる。従って、オペレータはサイクルパターンを設定することなく、お試しで分析レポートを生成することもでき、生成された分析レポートを解析してより詳細に分析すべくサイクルパターンを設定するなどの解析手法も行うことができる。
上記実施形態において、前記分析手段は、前記設定手段によって制御サイクルが定義されていない場合において、制御サイクルのサイクルパターンを有していないデバイスを分析対象として、前記運転記録データを分析する。本実施形態によれば、オペレータに対してサイクルパターンの設定操作を要求することなく分析レポートを容易に出力することができる。従って、オペレータはサイクルパターンを設定することなく、お試しで分析レポートを生成することもでき、生成された分析レポートを解析してより詳細に分析すべくサイクルパターンを設定するなどの解析手法も行うことができる。
【0132】
［観点１６］
上記実施形態において、前記レポート生成手段は、制御サイクルのサイクルパターンを有していないデバイスの分析結果を分析レポートとして生成し、
前記分析レポートには、制御サイクルが設定されていない旨と、前記設定手段によって制御サイクルの設定を促すメッセージが含まれる。本実施形態によれば、オペレータがサイクル設定を忘れている場合などに、サイクル設定を促すことができ、よりユーザフレンドリな操作体系を提供することができる。
上記実施形態において、前記レポート生成手段は、制御サイクルのサイクルパターンを有していないデバイスの分析結果を分析レポートとして生成し、
前記分析レポートには、制御サイクルが設定されていない旨と、前記設定手段によって制御サイクルの設定を促すメッセージが含まれる。本実施形態によれば、オペレータがサイクル設定を忘れている場合などに、サイクル設定を促すことができ、よりユーザフレンドリな操作体系を提供することができる。
【0133】
［観点１７］
本発明は、データ処理装置とプログラマブルロジックコントローラとが通信可能な分析システムであって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段とを備える。本実施形態によれば、運転記録データの分析結果に従って、異常の要因を容易に識別可能なレポートを提供することができる。また、煩雑なユーザ操作を必要とすることなく異常の要因を容易に識別可能なレポートを提供することができる。
本発明は、データ処理装置とプログラマブルロジックコントローラとが通信可能な分析システムであって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段とを備える。本実施形態によれば、運転記録データの分析結果に従って、異常の要因を容易に識別可能なレポートを提供することができる。また、煩雑なユーザ操作を必要とすることなく異常の要因を容易に識別可能なレポートを提供することができる。
【0134】
［観点１８］
上記実施形において、前記取得手段、前記モデル生成手段、分析手段、および前記レポート生成手段の少なくとも１つは前記データ処理装置に設けられる。本実施形態によれば、ＰＬＣの開発コストや、データ処理装置の性能等に応じて、本発明を実現するための構成をフレキシブルに適切なコンポーネントへ組み込むことが可能となり、システム設計の自由度を向上することができる。
上記実施形において、前記取得手段、前記モデル生成手段、分析手段、および前記レポート生成手段の少なくとも１つは前記データ処理装置に設けられる。本実施形態によれば、ＰＬＣの開発コストや、データ処理装置の性能等に応じて、本発明を実現するための構成をフレキシブルに適切なコンポーネントへ組み込むことが可能となり、システム設計の自由度を向上することができる。
【0135】
［観点１９］
上記実施形態において、前記プログラマブルロジックコントローラは、
前記実行エンジンを備えるＣＰＵユニットと、前記取得手段を実現する前記プログラマブルロジックコントローラに設けられるレコーダユニットとを備え、前記データ処理装置は、前記モデル生成手段、分析手段、および前記レポート生成手段を備える。本実施形態によれば、ＰＬＣの開発コストや、データ処理装置の性能等に応じて、本発明を実現するための構成をフレキシブルに適切なコンポーネントへ組み込むことが可能となり、システム設計の自由度を向上することができる。
上記実施形態において、前記プログラマブルロジックコントローラは、
前記実行エンジンを備えるＣＰＵユニットと、前記取得手段を実現する前記プログラマブルロジックコントローラに設けられるレコーダユニットとを備え、前記データ処理装置は、前記モデル生成手段、分析手段、および前記レポート生成手段を備える。本実施形態によれば、ＰＬＣの開発コストや、データ処理装置の性能等に応じて、本発明を実現するための構成をフレキシブルに適切なコンポーネントへ組み込むことが可能となり、システム設計の自由度を向上することができる。
【0136】
発明は上記の実施形態に制限されるものではなく、発明の要旨の範囲内で、種々の変形・変更が可能である。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8A】
【図8B】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】