JP2022158227A - 分析装置、分析システム、およびその制御方法 - Google Patents

Abstract

【課題】本発明は、各デバイスの分析結果を同期させたレポートを提供することを目的とする。また、他の目的として、レポートを表示する画面において、複数の表示項目を時間軸に連動して操作可能とすることを目的とする。【解決手段】分析装置であって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段とを備える。【選択図】図１１

Description

本発明は分析装置、分析システム、およびその制御方法に関する。

プログラマブル・ロジック・コントローラ（ＰＬＣ）はファクトリーオートメーションにおいて製造機器や搬送装置、検査装置などの産業機械を制御するコントローラである（特許文献１、２）。ＰＬＣはプログラマーによって作成されるラダープログラムなどのユーザプログラムを実行することで様々な拡張ユニットや被制御機器などを制御する。

特許第５６６１２２２号公報 特開２０１８－０９７６６２号公報

ところで、ＰＬＣの動作やＰＬＣによって制御される産業機械の動作を監視するために、ＰＬＣが保持しているデータを収集して活用することが望まれている。ＰＬＣは、基本ユニット（ＣＰＵユニット）とそれに接続される拡張ユニットとを有している。基本ユニットは、ラダープログラムなどのユーザプログラムを実行することで拡張ユニットを制御する。拡張ユニットは基本ユニットからの命令にしたがって産業機械を制御し、制御結果を基本ユニットに返す。

また、これらの制御結果等のデータはトラブル解析や品質管理のために使用される。従って、これらのデータを蓄積して分析し、復旧のために早期に解析結果を得ることが要求されている。しかし、ＰＬＣに関連する全てのデバイスのデータを記録する場合は膨大なデータを記憶することになり、さらに異常デバイスを特定するためにはこれらの膨大なデータ（全デバイス）を解析する必要があるため時間を要する作業となる。また、膨大な分析結果から異常デバイスを特定したり、システムを復旧させるためには、経験や知識も必要となる。従って、十分な専門的な知識や経験を必要とすることなく、各デバイスに関連する膨大なデータの中から効率よく分析を行い、分析結果を表示する仕組みが望まれている。

そこで、本発明は上記問題に鑑み、各デバイスの分析結果を同期させたレポートを提供することを目的とする。また、他の目的として、レポートを表示する画面において、複数の表示項目を時間軸に連動して操作可能とすることを目的とする。

本発明は、たとえば、分析装置であって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段とを備えることを特徴とする。

本発明によれば、いつもと違う挙動をしたデバイスの情報が同期されてユーザに提供される。

ＰＬＣシステムを説明する図 ＰＣ２ａのハードウエアを説明する図 ＰＣ２ｂのハードウエアを説明する図 ＰＬＣのハードウエアを説明する図 ＰＣのＣＰＵにより実現される機能を説明する図 ＰＬＣのＣＰＵにより実現される機能を説明する図 基本フローを示すフローチャート 結果表示画面を説明する図 結果表示画面を説明する図 リレーションマップを説明する図 制御サイクル及び異常点を説明する図 複数の表示項目が時間軸上の操作に応じて連動して更新される様子を示す図 正常時の映像と分析対象の映像との同期を説明する図 モデルの生成フローを示すフローチャート サイクルパターンの判別制御を説明する図 分析ユニットの結果表示フローを示すフローチャート ＰＣの結果表示フローを示すフローチャート ユーザプログラムの編集画面を示す図 サイクルを定義する設定画面を示す図 サイクル未設定の場合の警告を説明する図 ＰＬＣシステムの変形例を説明する図 サイクルの処理フローを説明する図

以下、添付図面を参照して実施形態が詳しく説明される。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態で説明されている特徴の組み合わせの全てが発明に必須のものとは限らない。実施形態で説明されている複数の特徴のうち二つ以上の特徴が任意に組み合わされてもよい。また、同一または同様の構成には同一の参照番号が付され、重複した説明は省略される。複数の構成を区別するために参照符号の末尾に小文字のアルファベットが付与されることがある。複数の構成に共通する事項が説明される際には小文字のアルファベットが省略されることがある。

＜システム構成＞
はじめにプログラマブルロジックコントローラ（ＰＬＣ、単にプログラマブルコントローラと呼ばれてもよい）を当業者にとってよりよく理解できるようにするために、一般的なＰＬＣの構成とその動作について説明する。

図１は本発明の実施の形態によるＰＬＣシステムの一構成例を示す概念図である。図１が示すように、ＰＬＣシステムは、ラダープログラムなどのユーザプログラムを編集するＰＣ２ａと、分析結果等を表示するＰＣ２ｂと、工場等に設置される各種の産業機械を統括的に制御するＰＬＣ１と、ＰＬＣ１に接続されるカメラ等のフィールドデバイス１０とを備えている。ＰＣはパーソナルコンピュータの略称である。なお、以下で単にＰＣ２と記載した場合は、ＰＣ２ａおよびＰＣ２ｂの構成や制御について説明しているものである。ユーザプログラムは、ラダー言語やＳＦＣ（シーケンシャルファンクションチャート）などのフローチャート形式のモーションプログラムなどのグラフィカルプログラミング言語を用いて作成されてもよいし、Ｃ言語などの高級プログラミング言語を用いて作成されてもよい。以下では、説明の便宜上、基本ユニット３で実行されるユーザプログラムはラダープログラムと仮定される。ＰＬＣ１は、ＣＰＵが内蔵された基本ユニット３と、１つないし複数の拡張ユニット４を備えている。基本ユニット３に対して１つないし複数の拡張ユニット４が着脱可能となっている。

基本ユニット３は、表示部５および操作部６を備えている。表示部５は、基本ユニット３に取り付けられている各拡張ユニット４の動作状況などを表示することができる。操作部６の操作内容に応じて表示部５は表示内容を切り替える。表示部５は、通常、ＰＬＣ１内のデバイスの現在値（デバイス値）やＰＬＣ１内で生じたエラー情報などを表示する。ここでデバイスとは、基本ユニット３や拡張ユニット４に含まれる種々のデバイス（リレー、タイマー、カウンタなど）を含むものであり、デバイス値（デバイスデータ）を格納するために設けられたメモリ上の領域を指すものでもあり、デバイスメモリと呼ばれてもよい。なお、当該デバイスメモリは不揮発性メモリであり、書き換え可能な不揮発性ＲＯＭで構成されてもよく、揮発性ＲＡＭ等をバッテリーバックアップ等により不揮発性を実現してもよい。ＲＯＭはリードオンリーメモリの略称である。ＲＡＭはランダムアクセスメモリの略称である。デバイス値とは、入力機器からの入力状態、出力機器への出力状態およびユーザプログラム上で設定される内部リレー（補助リレー）、タイマー、カウンタ、データメモリ等の状態を示す情報である。デバイス値の型にはビット型とワード型等がある。ビットデバイスは１ビットのデバイス値、たとえば、０／１、ＯＮ／ＯＦＦ、Ｈ／Ｌ等を記憶する。ワードデバイスは１ワードのデバイス値を記憶する。以下で詳細に説明されるデータ活用プログラムの収集対象としては、デバイスとして変数が指定されてもよい。変数も情報を保持する保持手段であり、ユーザプログラムに従って実行エンジンによりアクセスされるものである。したがって、以下の説明においてデバイスは変数も指すものである。なお、デバイスを保持するメモリはデバイスメモリと呼ばれてもよい。また、収集されたデータを保持するメモリはデータメモリと呼ばれてもよい。ＰＬＣ１は、デバイスの他、変数を取り扱うよう構成されてもよく、デバイスや変数のことをシンボルと呼び、シンボルが示す値をシンボル値と呼ぶ。

拡張ユニット４はＰＬＣ１の機能を拡張するために用意されている。拡張ユニット４には、その拡張ユニット４の機能に対応するフィールドデバイス（被制御装置）１０が接続されることがあり、これにより、各フィールドデバイス１０が拡張ユニット４を介して基本ユニット３に接続される。フィールドデバイス１０は、センサやカメラなどの入力機器であってもよいし、アクチュエータなどの出力機器であってもよい。また、一つの拡張ユニット４に対して複数のフィールドデバイスが接続されてもよい。

たとえば、拡張ユニット４ｂはモータ（フィールドデバイス１０）を駆動してワークの位置決めする位置決めユニットであってもよいし、カウンタユニットであってもよい。カウンタユニットは手動パルサなどのエンコーダ（フィールドデバイス１０）からの信号をカウントする。

分析ユニット４ａは、基本ユニット３においてシンボル（デバイス、変数など）からシンボル値を収集し、シンボル値を分析して分析結果を含む分析レポートを作成する。分析ユニット４ａは、分析レポートを外部のＰＣ２ｂへ提供するＷｅｂサーバを有していてもよい。基本ユニット３はＣＰＵユニットと呼ばれることもある。ＰＬＣ１とＰＣ２とを含むシステムはプログラマブルロジックコントローラシステムと呼ばれてもよい。本実施形態では、分析ユニット４ａが各デバイスのデータを収集する例について説明するが、当該収集部については基本ユニット３に設けられてもよく、或いは、他の拡張ユニットに設けられてもよい。また、分析ユニット４ａは、収集したデータを基本ユニット３からの指示や所定のタイミングに従って分析を行う分析装置として機能することも可能である。なお、本実施形態では、分析ユニット４ａが分析装置として動作する例について説明するが、本発明を限定する意図はなく、基本ユニット３が分析装置として機能してもよく、ＰＣ２ａ、２ｂなどの外部装置が分析装置として機能してもよい。以下で説明されるフロー（フロープログラム）はデータ活用プログラムの一例に過ぎない。基本ユニット３はＣＰＵユニットと呼ばれることもある。なお、ＰＬＣ１とＰＣ２とを含むシステムはプログラマブルロジックコントローラシステムと呼ばれてもよい。

ＰＣ２ａは主にプログラマーによって操作されるコンピュータである。一方、ＰＣ２ｂは主に現場担当者によって操作されるコンピュータである。ＰＣ２ｂは、ユーザにより画面設定されるプログラマブル表示器であってもよい。この場合、分析結果等を表示する画面はユーザにより画面設定されてもよく、あらかじめＷｅｂブラウザ機能が搭載され、Ｗｅｂブラウザ機能により分析結果等が表示されてもよい。ＰＣ２ａはプログラム作成支援装置（設定装置）と呼ばれてもよい。ＰＣ２は、たとえば、携帯可能なノートタイプやタブレットタイプのパーソナルコンピュータ又はスマートフォンであって、表示部７および操作部８を備えている外部コンピュータである。外部コンピュータとは、ＰＬＣ１の外部にあるコンピュータである。ＰＬＣ１を制御するためのユーザプログラムの一例であるラダープログラムは、ＰＣ２ａを用いて作成される。その作成されたラダープログラムは、ＰＣ２ａ内でニモニックコードに変換される。ＰＣ２は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ケーブルなどの通信ケーブル９を介してＰＬＣ１の基本ユニット３に接続される。たとえば、ＰＣ２ａは、ニモニックコードに変換されたラダープログラムを基本ユニット３に送る。基本ユニット３はラダープログラムをマシンコードに変換し、基本ユニット３に備えられたメモリ内に記憶する。なお、ここではニモニックコードが基本ユニット３に送信されているが、本発明はこれに限られない。たとえば、ＰＣ２ａは、ニモニックコードを中間コードに変換し、中間コードを基本ユニット３に送信してもよい。

なお、図１には示していないが、ＰＣ２の操作部８には、ＰＣ２に接続されたマウスなどのポインティングデバイスが含まれていてもよい。また、ＰＣ２は、ＵＳＢケーブル以外の他の通信ケーブル９を介して、ＰＬＣ１の基本ユニット３に対して着脱可能に接続されるような構成であってもよい。また、ＰＣ２は、通信ケーブル９を介さず、ＰＬＣ１の基本ユニット３に対して無線通信によって接続されてもよい。

＜プログラム作成支援装置＞
図２はＰＣ２ａの電気的構成について説明するためのブロック図である。図２が示すように、ＰＣ２ａは、ＣＰＵ１１ａ、表示部７ａ、操作部８ａ、記憶装置１２ａおよび通信部１３ａを備えている。表示部７ａ、操作部８ａ、記憶装置１２ａおよび通信部１３ａは、それぞれＣＰＵ１１ａに対して電気的に接続されている。記憶装置１２ａはＲＡＭやＲＯＭ、ＨＤＤ、ＳＳＤを含み、さらに着脱可能なメモリカードを含んでもよい。ＣＰＵは中央演算処理装置の略称である。ＨＤＤはハードディスクドライブの略称である。ＳＳＤはソリッドステートドライブの略称である。

ＰＣ２ａのユーザは記憶装置１２ａに記憶されているプロジェクト編集プログラム１４ａをＣＰＵ１１ａに実行させて、操作部８ａを通じてプロジェクトデータ１５を編集する。つまり、ＰＣ２ａはエンジニアリングツールであり、プログラム作成支援装置として機能する。ＣＰＵ１１ａがプロジェクト編集プログラム１４ａを実行することで、プロジェクト作成部１６とプロジェクト転送部１７が実現される。プロジェクト作成部１６はユーザ入力にしたがってプロジェクトデータ１５を作成する。プロジェクト転送部１７はプロジェクトデータ１５をＰＬＣ１に転送する。プロジェクトデータ１５は、一つ以上のユーザプログラム（例：ラダープログラム、制御プログラム、モーションプログラム、データ活用プログラム）と、基本ユニット３や拡張ユニット４の構成情報、ＷｅｂＨＭＩの作画データ、基本ユニット３や拡張ユニット４に備えられた特定機能の設定情報などを含む。構成情報は、基本ユニット３に対する複数の拡張ユニット４の接続位置やデバイスの割り当て情報を含む。基本ユニット３に備えられた機能（例：データ収集機能、通信機能、位置決め機能）を示す情報、拡張ユニット４の機能（例：通信機能、位置決め機能、撮影機能）などを示す情報を含んでいてもよい。作画データは、ＷｅｂＨＭＩを実現するための表示部品群であり、フロントエンドの構造を記述するマークアップデータ、たとえばＨＴＭＬデータ、装飾を記述するスタイルデータ、たとえばＣＳＳデータおよび動的な処理を記述するコード、たとえばＪａｖａＳｃｒｉｐｔ（登録商標）コードなどにより実現される。装飾を記述するスタイルデータは、たとえばファイル形式として提供されてもよく、構造を記述するマークアップデータ内で外部スタイルデータファイルを呼び出す記述により呼び出されてもよい。動的処理を記述するコードは、たとえばファイル形式で提供されてもよく、構造を記述するマークアップデータ内で外部コードファイルを呼び出す記述により呼び出されてもよい。外部スタイルデータファイルや外部コードファイルを呼び出して使用できる形式のフロントエンドは、再利用性やメンテナンス性が高く、たとえば汎用のフロントエンドコンポーネント等を利用することができる。以下で、作画データは、表示部品と表記される。データ活用プログラムは、ＰＬＣ１において制御データ（デバイス値など）を収集したり、データ処理したり、ＷｅｂＨＭＩに渡すためのデータを作成したりするためのプログラムを含む。特定機能の設定情報は、基本ユニット３に備えられた機能（例：データ収集機能、通信機能、位置決め機能）に関する設定情報、たとえば、データ収集機能であれば、データ収集条件やデータ収集対象の設定情報を含み、拡張ユニット４の機能（例：通信機能、位置決め機能、データ活用機能、撮影機能）に関する設定情報等を含む。ここで、プロジェクトデータ１５の編集には、プロジェクトデータ１５の作成および変更（再編集）が含まれる。ユーザは、必要に応じて記憶装置１２ａに記憶されているプロジェクトデータ１５を読み出し、そのプロジェクトデータ１５を、プロジェクト編集プログラム１４ａを用いて変更することができる。通信部１３ａは、通信ケーブル９ａを介して基本ユニット３と通信する。プロジェクト転送部１７は通信部１３ａを介してプロジェクトデータを基本ユニット３に転送する。通信部１３ａは、通信ケーブル９ｂを介して分析ユニット４ａと通信する。

＜ダッシュボードの表示に使用されるＰＣ＞
図３はＰＣ２ｂの電気的構成について説明するためのブロック図である。図３が示すように、ＰＣ２ｂは、ＣＰＵ１１ｂ、表示部７ｂ、操作部８ｂ、記憶装置１２ｂおよび通信部１３ｂを備えている。表示部７ｂ、操作部８ｂ、記憶装置１２ｂおよび通信部１３ｂは、それぞれＣＰＵ１１ｂに対して電気的に接続されている。記憶装置１２ｂはＲＡＭやＲＯＭ、ＨＤＤ、ＳＳＤを含み、さらに着脱可能なメモリカードを含んでもよい。

ＣＰＵ１１ｂはＷｅｂブラウザプログラム１４ｄを実行することでＷｅｂブラウザ１８を実現する。Ｗｅｂブラウザ１８は、通信部１３ｂを介して、分析ユニット４ａによって提供されるデータ活用アプリケーションの設定ページにアクセスしたり、ダッシュボードのページにアクセスしたりする。またＣＰＵ１１ｂは、分析ユニット４ａから送信された異常発生時の特定結果（判定結果）を示す画面情報に従って、当該特定結果を表示部７ｂに表示する。

＜ＰＬＣ＞
図４はＰＬＣ１の電気的構成について説明するためのブロック図である。図４が示すように、基本ユニット３は、ＣＰＵ３１、表示部５、操作部６、メモリ３２および通信部３３を備えている。表示部５、操作部６、メモリ３２、および通信部３３は、それぞれＣＰＵ３１に電気的に接続されている。メモリ３２は、ＲＡＭやＲＯＭ、メモリカードなどを含んでもよい。メモリ３２はデバイス部３４やプロジェクト記憶部３５、リングバッファ３６、運転記録記憶部３７などの複数の記憶領域を有している。

ここで運転記録とはＰＬＣ１の運転状態をスキャンタイムレベルで記録したものであり、たとえばＰＬＣ１の運転に関わる全てのシンボルのシンボル値と収集時刻とを、一スキャン毎に時系列に記録したものである。運転に関わる全てのシンボルとは、たとえばラダープログラム等のユーザプログラムに使用される全てのシンボルであってもよく、ユーザにより選択されるプログラム単位やユニット単位に含まれる全てのシンボルであってもよい。この場合、運転記録の対象となるシンボルをプログラム単位やユニット単位のように有意な単位で一括選択でき、さらに個別にシンボルを加除できるようにしてもよい。これにより、たとえば、トラブル発生時に、トラブル発生時刻の前後においてＰＬＣ１の運転に関わる全てのシンボルのシンボル値と収集時刻とを、一スキャン毎に時系列に記録した運転記録を生成し、運転記録に基づきトラブル発生時に何が起きたかを後からでも正確に把握することができる。運転記録には、その時の状況を再現するために多くの情報が含まれるが、情報が多いと運転記録のデータ容量が大きくなり取り回しが難しくなったり、運転記録の収集に負荷がかかったりするため、収集対象となるユーザによりプログラム単位やユニット単位で選択できるようになっている。

また、運転記録には、シンボルに加え時系列のカメラ画像が撮像時刻とともに含まれてもよい。これにより、たとえば、トラブル発生時に、トラブル発生時刻の前後に遡って何が起きたかを後からでも正確に把握でき、設備の外観変化を示すカメラ画像も運転記録に含めることでユーザプログラムの時系列と連動してカメラ画像を記録することができる。ＨＭＩ（ヒューマンマシンインタフェース）やＰＣなどの外部機器からの書き込み履歴やＰＬＣからの書き込み履歴を変化点イベントとして運転記録に含めてもよい。これにより、たとえば、トラブル発生前後にどのような変化点イベントがあったかを時系列で確認できる。

デバイス部３４はビットデバイスやワードデバイスなどを有し、各デバイスはデバイス値を記憶する。プロジェクト記憶部３５は、ＰＣ２ａから転送されたプロジェクトデータを記憶する。リングバッファ３６は、定期的にデバイス部３４からデバイス値を収集して記憶する。運転記録記憶部３７は、所定のイベントが発生すると、発生時刻の周辺（発生時刻以前、発生時刻以後、または、発生時刻の前後）に収集されたデバイス値とその収集時刻とを含むイベント記録を記憶する。イベントとは、たとえば、デバイスごとに設定された警報条件または注意条件が満たされたことをいう。警報条件とは、たとえば、ＰＬＣ１による製造ラインの制御動作を停止すべきような条件をいう。注意条件は、たとえば、ＰＬＣ１による製造ラインの制御動作について管理者が注意すべきようなデバイス値の条件をいう。ＣＰＵ３１は、ＰＣ２ａからの要求に応答してイベント記録をＰＣ２ａへ送信する。また、ＣＰＵ３１は、リアルタイムでデバイス値をＰＣ２ａに提供してもよい。メモリ３２は基本ユニット３のＣＰＵ３１により実行される制御プログラムも記憶する。図３が示すように基本ユニット３と拡張ユニット４とは拡張バスの一種であるユニット内部バス９０を介して接続されている。なお、ユニット内部バス９０に関する通信機能はＣＰＵ３１に実装されるが、通信部３３の一部として実装されてもよい。通信部３３は、ＵＳＢ規格などに準拠したシリアル通信回路を有してもよい。ＣＰＵ３１は通信部３３を介してプロジェクトデータをＰＣ２ａから受信する。

ここで、ユニット内部バス９０について、補足説明する。このユニット内部バス９０は、入出力リフレッシュに使用される通信バスである。入出力リフレッシュとは、基本ユニット３と拡張ユニット４との間でデバイス値を更新する処理である。入出力リフレッシュは、ラダープログラムが一回実行されるごとに（つまり、一スキャンごとに）、実行される。

拡張ユニット４はＣＰＵ４１とメモリ４２を備えている。拡張ユニット４ｂのＣＰＵ４１ｂは、デバイスに格納された基本ユニット３からの指示（デバイス値）にしたがってフィールドデバイス１０を制御する。なお、本実施形態において拡張ユニット４ｂは、カメラ制御ユニットとして機能する。また、ＣＰＵ４１ｂは、カメラ等のフィールドデバイス１０の制御結果をバッファメモリとよばれるデバイスに格納する。デバイスに格納された制御結果は入出力リフレッシュによって基本ユニット３に転送される。また、デバイスに格納されている制御結果は、基本ユニット３からの読み出し命令にしたがって、入出力リフレッシュとは異なるタイミングであっても、基本ユニット３に転送されることがある。メモリ４２はＲＡＭやＲＯＭなどを含む。とりわけ、ＲＡＭにはバッファメモリとして使用される記憶領域が確保されている。メモリ４２は、フィールドデバイス１０によって取得されたデータ（例：静止画データや動画データ）を一時的に保持するバッファを有してもよい。

データ活用ユニット（分析ユニット）として機能する分析ユニット４ａのＣＰＵ４１ａは、通信部４３と通信ケーブル９ｂを介してＰＣ２ｂと通信する。通信部４３は、ネットワーク通信を実行する通信回路を含む。ＣＰＵ４１ａは、基本ユニット３において収集されたデバイス値を分析することで、分析結果を含む分析レポートを作成する。たとえば、ＣＰＵ４１ａは、データ活用アプリケーションとして運転記録分析アプリケーションを実行することにより、運転記録データに含まれるシンボル値を分析することで、非正常シンボルと当該シンボルが非正常となる時刻とを特定し、非正常シンボルと当該シンボルが非正常となる時刻とを対応づけた分析結果を含む分析レポートを作成する。運転記録データは、運転記録の保存イベント発生時刻周辺の状況を再現するための情報を含んでいるため、分析レポートと紐づけて管理されてもよい。また、運転記録データは、運転記録の保存イベント発生時刻周辺の状況を再現するため、多くのシンボルのシンボル値を含むことからデータサイズが大きくなる。このため、たとえば、ＣＰＵ４１ａは、運転記録データの中から、分析レポートに必要なデータを読み出して、分析レポート用のデータとして運転記録データに追加保存してもよい。分析レポート用のデータは、もともと運転記録データに含まれていた分析レポートに必要なデータを、そのままコピーしたものを分析レポート用のデータとしてタグ付けして運転記録データに追加保存してもよく、分析レポート用にデータ加工して運転記録データに追加保存してもよい。

運転記録データにカメラ画像が含まれると、カメラ画像の再生により運転記録の保存イベント発生時刻周辺の状況をより詳細に把握することができる。分析レポートはカメラ画像を再生するＵＩ（ユーザインターフェース）を含んでもよい。カメラ画像はデータサイズが大きいため、カメラ画像を再生するＵＩにおいてクリックやスクロール操作を受け付けた時などに必要なカメラ画像データだけを部分的にダウンロードしてもよい。たとえば、ＣＰＵ４１ａは、分析レポートを作成する際、カメラ画像を分析レポートにおける表示順序に対応して加工したり、時刻とカメラ画像の保存位置の対応関係を示すインデックス情報を生成し、時刻に対応したカメラ画像を高速かつ部分的にダウンロードできるようにしてもよい。

狭義には、分析レポートは、分析結果そのものを意味するが、広義には、分析結果を表示するＷｅｂアプリケーションやそのユーザインタフェースを意味することがある。ＣＰＵ４１ａは、たとえば、デバイス値が正常範囲内かどうかや、デバイス値が変化するタイミングが正常範囲内かどうかなどを判定する。デバイス値が変化するタイミングが正常範囲内かどうかは、たとえば、デバイス値が“１”（オン）である期間の長さが正常範囲かどうかであってもよい。また、ある工程またはサイクルにおけるデバイス値の変化回数が正常範囲内かどうかが判定されてもよい。あるデバイスから収集されたデバイス値が正常条件を満たしていない場合、そのデバイスは、いつもと違う振る舞いのデバイスであるため、非正常デバイスと呼ばれてもよい。ＣＰＵ４１ａは、Ｗｅｂ形式の分析レポートを作成し、通信部４３および通信ケーブル９ｂを介して分析レポートをＰＣ２ｂのＷｅｂブラウザに提供してもよい。ＣＰＵ３１がプロトコル変換機能を有している場合、ＣＰＵ４１ａは、ユニット内部バス９０、ＣＰＵ３１、通信部３３および通信ケーブル９ａを介して、分析レポートをＰＣ２ａに送信してもよい。分析レポートは、グラフ表示部品や数値表示部品などを有してもよい。これらの表示部品は、フロントエンドの構造を記述するマークアップデータ、装飾を記述するスタイルデータおよび動的な処理を記述するコード、たとえばＨＴＭＬデータ、ＣＳＳデータおよびＪａｖａＳｃｒｉｐｔ（登録商標）コードなどにより実現される。ＨＴＭＬはハイパーテキストマークアップ言語の略称である。ＣＳＳはカスケーディングスタイルシートの略称である。

＜ＰＣ２ｂの機能＞
図５はＰＣ２ｂのＣＰＵ１１ｂによって実現される機能を説明する図である。ＰＣ２ｂのＣＰＵ１１ｂは、Ｗｅｂブラウザプログラム１４ｄを実行することによりＷｅｂブラウザ１８を実行する。Ｗｅｂブラウザ１８はＷｅｂアプリケーション６１を実行して、通信処理部６２、データ取得部６３、描画部６５、受付部６６、および再生部６７の機能を実現する。また、Ｗｅｂブラウザ１８は、後述する分析ユニット４ａのＷｅｂサーバ８２と、ＨＴＴＰ（ハイパーテキストトランスポートプロトコル）にしたがって通信して表示部品を受信する。

Ｗｅｂブラウザ１８は、Ｗｅｂアプリケーション６１を実行することで分析レポートを表示部７ｂに表示する。Ｗｅｂアプリケーション６１は、たとば、ＨＴＭＬデータ、ＣＳＳデータおよびｊａｖａ（Ｒ）スクリプトなどにより構成される。Ｗｅｂアプリケーション６１は、分析ユニット４ａから提供されてもよい。通信処理部６２は、Ｗｅｂサーバ８２との通信を処理する。データ取得部６３は、分析レポートに表示すべき運転記録データを分析ユニット４ａから取得する。運転記録は、ダウンロードして記憶装置１２ｂに記憶される。描画部６５は分析レポートを表示部７ｂに表示する。連携部６４は、分析レポートにおける再生時刻と、運転記録の再生時刻とが同期するように時刻管理を実行する。

受付部６６は、分析レポートの結果表示画面に対しての操作などを受け付ける。再生部６７は、たとえば、受付部６６又は連携部６４から入力される再生要求に応じて、運転記録データをダウンロードさせて記憶装置１２ｂに保存させる。再生要求には、たとえば、運転記録を特定可能な識別情報（例：固有の識別情報やＰＬＣ１における保存パス名）などが含まれていてもよい。再生部６７は、記憶装置１２に保存されている運転記録を再生して表示部７に表示する。再生部６７は、ＰＬＣ１からリアルタイムで取得される時系列のデバイス値を波形化して表示したり、運転記録に含まれる時系列のデバイス値を波形化して表示したりしてもよい。

＜ＰＬＣ１の機能＞
図６はＰＬＣ１においてＣＰＵ３１とＣＰＵ４１ａとが制御プログラムを実行することで実現する機能を示している。ＣＰＵ３１においてコマンド処理部７１は、ＰＣ２ａ、２ｂから受信されるコマンドを解釈し、解釈結果に対応した処理を実行する。たとえば、ＨＴＴＰリクエストをカプセル化して作成された要求信号が受信されると、コマンド処理部７１は、要求信号をＣＰＵ４１ａに転送する。要求信号に対する応答信号がＣＰＵ４１ａから受信されると、コマンド処理部７１は、応答信号をＰＣ２ａ、２ｂへ転送する。コマンド処理部７１は分析ユニット４ａにも設けられてよい。その場合、ＰＣ２ａからコマンドについてはコマンド処理部７１が処理し、ＰＣ２ｂからのコマンドは分析ユニット４ａに設けられたコマンド処理部が処理する。収集部７２は、基本ユニット３や拡張ユニット４ｂからシンボル値（デバイス値や変数に格納された値）を収集してリングバッファ３６に格納する。収集部７２の収集設定については基本ユニット３および分析ユニット４ａの少なくとも一方から行うことができる。ロギング部７３は、収集されたシンボル値などに基づき、何らかのエラーまたはトラブル（非正常イベント）がＰＬＣ１において生じているかどうかを判定する。たとえば、ロギング部７３は、収集されたシンボル値が記録条件を満たしているかどうかを判定してもよい。収集されたシンボル値が記録条件を満たしている場合に、ロギング部７３は、当該シンボル値を運転記録７４内の稼働ログ７６として保存する。ロギング部７３は、運転記録を作成したときに実行されていたプロジェクトデータ７５も運転記録７４内に保存する。さらに、ロギング部７３は、運転記録７４を作成したことを分析部８３に通知する。設定部７８は、オペレータの入力に従って後述する学習モデルの生成や、分析、分析レポートの生成に利用する制御サイクルを設定する。制御サイクルは、サイクルの基準となるタイミングを指定することで設定され、制御サイクルの設定をサイクル設定と呼ぶ。たとえば、サイクル設定は、サイクルの開始タイミングを規定するシンボル名と、シンボル値の立上り／立下りのエッジ情報とを含む。また、サイクル設定は、サイクルの開始タイミングを規定するシンボル名と、シンボル値の立上り／立下りのエッジ情報とによるサイクルの開始タイミングの設定情報と、サイクルの終了タイミングを規定するシンボル名と、シンボル値の立上り／立下りのエッジ情報とによるサイクルの終了タイミングの設定情報を含んでいてもよい。設定部７８による制御サイクルの設定はＣＳＶ等のファイル形式でＰＬＣ１に提供され、設定部７８がＣＳＶ等のファイルを読み出して制御サイクルを設定してもよい。例えば、設定部７８によって設定された制御サイクルは、当該サイクルに同期するデバイスを分類して当該分類情報を属性情報としてモデルへ付加したり、分析対象とするデバイスを制御サイクルによって絞ったり、制御サイクルに同期して表示される分析レポートを生成したりするために用いられる。設定される制御サイクルは複数であってもよい。設定方法については後述する。また、制御サイクルは必ずしも設定する必要はなく、たとえば、正常時におけるシンボル値の取り得る値が予め決まっている場合、シンボル値がその予め決まっている取り得る値か否かを判定することで非正常シンボルとして判定することができる。

ＣＰＵ４１ａにおいてプロトコル変換部８１は、ＰＣ２ｂからカプセル化されて転送されてきたＨＴＴＰリクエストをプロトコル変換して要求信号からとりだす。プロトコル変換部８１は、ＨＴＴＰリクエストに対してＷｅｂサーバ８２から送信される応答情報をカプセル化してＣＰＵ４１ａに渡す。プロトコル変換部８１は透過的なトンネル（例：ＴＣＰトンネル）を提供してもよい。Ｗｅｂサーバ８２は、分析部８３により作成された分析レポートをＰＣ２ｂへ提供する。分析部８３は、運転記録７４内の稼働ログ７６を後述するモデルを用いて分析し、分析結果７７を作成して、ロギング部７３に渡す。分析部８３が分析結果７７を作成すると、ロギング部７３は、プロジェクトデータ７５および稼働ログ７６に加えて、分析結果７７を含む運転記録７４に追加する。運転記録７４は、運転記録記憶部３７に格納される。或いは、分析結果７７は分析ユニット４ａのメモリ４２ａに記憶されてもよい。通知発行部８４は、分析結果７７が発行されると、通知を発行する。この通知は、ＣＰＵ１１ｂに送信される。

たとえば、Ｗｅｂブラウザ１８がＨＴＴＰリクエストにより分析レポートを要求すると、Ｗｅｂサーバ８２はＨＴＴＰリクエストをプロトコル変換部８１に渡す。ＨＴＴＰリクエストには、ＣＰＵ４１ａで実行され、分析レポートを提供する分析ユニット４ａ（Ｗｅｂサーバ）のＵＲＬ（ユニフォームリソースロケータ）が含まれている。プロトコル変換部８１は、ＨＴＴＰリクエストをカプセル化して、所定の通信プロトコルで送信可能な要求信号（コマンド）に変換する。この要求信号は、分析ユニット４ａのＣＰＵ４１ａに渡される。ＣＰＵ４１ａは、ＣＰＵ１１ｂに分析レポートを返信する。ＣＰＵ１１ｂは、分析レポートをＷｅｂブラウザ１８に渡す。これによりＷｅｂブラウザ１８は表示部７ｂに分析レポートを表示する。

モデル生成部８６は、後に分析部８３が運転記録データと比較するためのマスタデータとなるモデルを作成する。レポート生成部８５は、分析結果７７をＰＣ２ｂのＷｅｂブラウザ１８で表示するための表示画面である分析レポートを生成する。分析レポートには、複数の分析結果が含まれるが、それらの分析結果は時間軸上で同期して表示される。分析レポートの詳細については図８Ａを用いて後述する。

＜基本フロー＞
図７は、本実施形態に係るモデル生成と、運転記録データの分析および結果出力の基本フローを示す。以下で説明する処理は、基本ユニット３のＣＰＵ３１および分析ユニット（拡張ユニット）４ａのＣＰＵ４１ａによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。

Ｓ１で基本ユニット３のＣＰＵ３１は、ＰＣ２ａを介して入力された情報に従って、収集部７２における収集設定や分析設定を設定する。たとえば、ＣＰＵ３１は、収集設定として、収集対象や収集期間、保存先、ファイル名などを設定することができる。分析設定としては、たとえば分析対象となるサイクルの開始および終了の設定が含まれる。ここでは基本ユニット３が収集設定および分析設定を行う例について説明したが、分析ユニット４ａのＣＰＵ４１ａがＰＣ２ｂを介して入力された情報に従って収集設定を行ってもよい。さらにＳ１では、基本ユニット３のＣＰＵ３１が、分析設定として、ＰＣ２ａ、２ｂの表示部７ａ、７ｂに表示された設定画面を介して入力された情報に従って撮影条件等のカメラ設定や画像処理設定、監視項目設定などを設定することができる。なお、これらの分析設定についても分析ユニット４ａのＣＰＵ４１ａによって実行することも可能である。その後、Ｓ２でＣＰＵ３１は、Ｓ１で設定された収集設定に従って運転記録データを、モデル作成用データとして収集し、運転記録記憶部３７へ格納する。より詳細には、収集設定に従って収集された全デバイス値が一旦リングバッファ３６へ格納され、リングバッファ３６から必要なデータが運転記録データとして運転記録記憶部３７へ格納される。

次に、Ｓ３で分析ユニット４ａのＣＰＵ４１ａは、収集された運転記録データを利用してモデルを作成する。当該モデルには、各デバイスのパターンを、定数、ビットパターン、アナログ値などの特徴量に基づいて分類したデバイスごとの情報や、デバイス値が変化するタイミングを示す情報が含まれてもよい。つまり、当該モデルは、各デバイスの正常時の変化パターンが学習される。Ｓ３の詳細な処理については図１４を用いて後述する。

その後、Ｓ４で基本ユニット３のＣＰＵ３１は運転記録データの分析を行うトリガが発生したか否かを判断する。当該トリガは、基本的には運転中にいつもと違う異常が発生した場合をトリガとするものであり、その成立条件として、たとえばエラービットが設定された場合や、監視アプリケーション等のアプリケーションからの所定のイベントの発生、オペレータからの手動による指示の受け付け等が挙げられる。トリガが発生するとＳ５へ進む。

Ｓ５で基本ユニット３のＣＰＵ３１は、各デバイス値を収集して分析を行うための運転記録データを、運転記録記憶部３７に保存する。通常、いつもと違う何らかの変化が発生した後にトリガが発生する。従って、ここでは、そのような変化の原因を特定するためにトリガ前後のデータが取得される。上述したように、運転中における全デバイスのデバイス値はリングバッファ３６へ保持されている。従って、ＣＰＵ３１はトリガが発生したと判断すると、Ｓ１で設定された分析設定に従って、トリガ前後の必要なデバイス値をリングバッファ３６から運転記録記憶部３７へ格納する。また、Ｓ５で分析ユニット４ａのＣＰＵ４１ａは、基本ユニット３から分析用の運転記録データを取得する。ここでは、運転記録データに加えて、更にカメラ画像データやイベントの発生履歴、エラー履歴の情報も合わせて取得してもよい。

その後、Ｓ６で分析ユニット４ａのＣＰＵ４１ａは、基本ユニット３で収集された時系列データを取得して、Ｓ２で生成されたモデルと比較して分析処理を実行する。分析処理では、各デバイスについて、Ｓ３で生成されたマスタデータであるモデルデータと、分析対象の運転記録データとを比較して、対象デバイスがいつもと異なる状態であるかどうかを判断する。所定値以上の差分があればいつもとは異なる状態が検知されていると判断する。さらにＣＰＵ４１ａは判断後の分析結果を基本ユニット３の運転記録記憶部３７における分析結果７７の記憶領域に、各デバイスごとの分析結果を格納する。ここで分析結果７７には、いつもと異なる状態が検知されたデバイスの分析結果とその記録データとが時間情報とともに格納されることが望ましい。これにより、オペレータ等からの分析レポートの生成要求を受け付けた場合にそれらの情報を用いて各デバイス値を同期させて表示可能な分析レポートを容易に作成することができる。なお、拡張ユニット４ｂから得られるカメラ映像も紐づけて格納してもよい。さらに、Ｓ７でＣＰＵ４１ａは、分析結果に基づいて、結果を示す表示データ（分析レポート）を生成し、通信部４３を介して生成した表示データをＰＣ２ｂや外部装置へ送信し、処理を終了する。たとえば、ＰＣ２ｂにおいて分析結果がオペレータに対して表示される。分析レポートを表示した結果表示画面の詳細については図８Ａを用いて後述する。

監視アプリケーションは、分析ユニット４ａのＣＰＵ４１ａにより実行されるデータ活用アプリケーションの一つである。分析ユニット４ａは、データ活用アプリケーションを実行する拡張ユニットであってもよい。データ活用アプリケーションは、制御データを収集したりデータ処理したりするデータ活用プログラム（例：フロー）と、データ活用プログラムの実行結果を表示するダッシュボードとを含む。データ活用アプリケーションとしては、監視対象であるデバイスや変数をリアルタイムに監視する監視アプリケーションと、ＰＬＣ１の運転状態を再現するための運転記録を分析して分析レポートを生成する運転記録分析アプリケーションなどが存在してもよい。また、データ活用アプリケーションとしては、可動率（べきどうりつ）、良品率、または、サイクルタイムなどのＫＰＩ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ）を算出する算出アプリケーションなどが存在してもよい。監視アプリケーションは、ＰＬＣ１のシンボルのシンボル値に基づく常時監視するためのアプリケーションで、たとえば監視アプリケーションの設定に応じて１又は複数のシンボルのシンボル値をスキャンタイムレベルで常時収集し、収集したシンボル値に基づく情報をリアルタイムに更新しながら常時表示するアプリケーションである。常時監視の対象となる１又は複数のシンボルは、予めユーザにより設定される。監視アプリケーションは、たとえばＷｅｂサーバ機能を有し、通信部４３を介して汎用ブラウザから設定が可能である。汎用ブラウザから設定できることにより、プログラム作成支援装置等の専用ツールを介さずに、ＰＣ、スマホ、タブレットから設定または監視ができる。また、監視アプリケーションは、常時監視の対象となる１又は複数のシンボルについて正常時における複数のサイクルのシンボル値に基づき当該シンボルに対応する閾値を自動で設定する。たとえば、監視アプリケーションは、ユーザ指示を受け付けて、常時監視の対象となる複数のシンボルについて正常時における複数のサイクルのシンボル値のばらつきに基づき、シンボルの状態を監視するための閾値を一括で自動設定する。閾値は、いつもと違う状態、つまり、非正常状態を監視するように設定され、監視アプリケーションは、監視対象のシンボルのシンボル値が閾値を超えた場合はアラームを発報する。このようにして、たとえば、ＰＬＣ１は、設備が止まる前に兆候を捉えることができる。ＰＬＣ１は、監視アプリケーションによる兆候監視の結果、監視対象のシンボルのシンボル値が閾値を超えた場合のアラームを、運転記録の保存条件としてもよい。ＰＬＣ１は、監視アプリケーションによるアラーム発生をイベントトリガとして、トリガ前後の運転記録データを保存する。ＰＬＣ１は、運転記録データの保存が完了すると保存完了デバイスをＯＮする。運転記録分析アプリケーションは、運転記録データの保存が完了したことをうけ、自動的に運転記録データを分析してもよい。たとえば、運転記録分析アプリケーションは、保存完了デバイスをＯＮしたことに応じて運転記録データを分析してもよい。運転記録分析アプリケーションは、分析対象となったシンボルのシンボル値（例、全ビットデバイスのデバイス値）を分析して、アラートが出た要因候補のシンボルを抽出する。このようにして運転記録分析アプリケーションは、監視アプリケーションによるアラーム発生の要因をアラーム発生により保存した運転記録データを自動分析し、運転記録データの中からいつもと違うシンボルを抽出する。これにより、ＣＰＵ４１ａは、監視アプリケーションの兆候監視機能により設備の状態を常時監視し、変化要因でアラートを発報する。さらに、ＣＰＵ４１ａは、アラート要因を自動分析し、いつもと違うシンボルを抽出する。つまり、ＰＬＣ１は、シンボル値を常時監視することで被制御対象設備の兆候監視をして、アラームにより被制御対象設備が止まる前に兆候を報知して、兆候の要因を自動分析する。

＜結果表示画面（分析レポート）＞
図８Ａは、本実施形態に係るＷｅｂブラウザ１８がＷｅｂブラウザプログラム１４ｄを実行することで表示部７ｂに表示される結果表示画面を示す。ここでは当該結果表示画面８００がＰＣ２ｂの表示部７ｂに表示される例について説明するが、本発明を限定する意図はなく他の装置の表示部に表示されてもよいし、ＰＬＣの拡張ユニットが有するモニタで表示可能であれば当該モニタに表示されてもよい。たとえば、他の装置としてプログラマブル表示器、タブレット、スマートフォンが含まれてもよい。或いは、以下で説明する結果表示画面の内容を含む分析レポートとして他の装置へ電子メール、ＳＮＳ、ＦＴＰ転送等で送信されてもよい。分析レポートに対して任意のコメントが付されてもよく、たとえば、分析レポートに対して手書き文字や入力文字コメントが付与されてもよい。この場合、任意のコメントが付与された結果表示画面の内容を含む分析レポートが他の装置へ送信されてもよい。これにより、メールの受信者はコメントなどの現場状況と分析レポートとを合わせて閲覧することができる。また、分析レポートが他の装置へ送信する際、分析レポートとともに当該分析レポートの分析対象である運転記録データが対応付けられて送信されてもよい。これにより、メールの受信者は運転記録と分析レポートとを合わせて閲覧することができる。さらに、ＰＣ２ｂがカメラ付きのタブレットやスマートフォン等であれば、装置の写真も一緒に添付できてもよい。

結果表示画面８００は、結果をフィルタリングして表示するためのフィルタ８０１～８０３と、フィルタ結果８０４と、検知マップ８１０と、検知リスト８２０と、画像表示領域８３０と、分析コメント８４０とを含んで構成される。なお、結果表示としては、８１０、８２０、８３０、８４０のうち少なくとも１つが表示されるものであってよい。フィルタ８０１は制御サイクルを選択して結果表示をフィルタリングすることができる。ここでの制御サイクルとは、デバイス値の周期的な変化を伴う開始タイミングから終了タイミングまでの期間を称する。フィルタ８０１を指定すると、選択された制御サイクルで動作するデバイスの分析結果に絞って結果が表示される。フィルタ８０２は属性情報を選択して結果表示をフィルタリングすることができる。属性情報とは、何れのユニットや通信機器に接続されているかの情報や、入力デバイスであるか否かの情報を示す。

フィルタ８０２においてたとえば「ユニット構成情報」を指定するとユニット構成がポップアップ画面等で表示され、表示されたユニットのいずれかを選択することができる。ユニットが選択されると、当該ユニットに接続されているデバイスに絞って結果が表示される。また、属性情報として「入力デバイス」が指定されると、入力デバイスの属性情報が付加されたデバイスに絞って結果が表示される。フィルタ８０２は、属性情報を活用するフィルタリングに限られない。たとえば、分析の結果、同じシンボルが重複して非正常シンボルとして検出されることがある。非正常の原因を探るうえで最先の発生時刻が重要となる可能性が高く、フィルタ８０２は、重複して検出された同じシンボルのうち最先の発生時刻以外をフィルタリングするようにしてもよい。また、フィルタ８０２は、同じシンボルで、分析時の検知アルゴリズムや後述する異常の種類が同一なもののうち、最先の発生時刻以外をフィルタリングするようにしてもよい。さらに、フィルタ８０２は、同じシンボルで、分析時の検知アルゴリズムや後述する異常の種類が同一であって、後述するサイクル設定が同一なもののうち、最先の発生時刻以外をフィルタリングするようにしてもよい。

フィルタ８０３はイベントやエラーを選択して結果表示をフィルタリングすることができる。イベントやエラーの種別を指定するとそれに関わりのあるデバイスの分析結果に絞って結果が表示される。たとえば、イベントとして「運転記録保存トリガ」が選択された場合には、その前後の分析結果に絞って結果が表示される。結果表示画面８００は、分析結果とともにイベントやエラーを発生時刻順に表示してもよい。この場合、フィルタ８０３はイベントやエラーをフィルタリングすることができる。これにより分析結果とイベントやエラーの混在表示と、分析結果の表示とを切り換えることができる。ここで、イベントは、たとえば、電源ＯＮ／ＯＦＦ、デバイス値書換、メモリ挿抜などを含み、カテゴリー毎にフィルタリング対象を加除できるようにしてもよい。エラーは、たとえば通信エラー、ＰＬＣ演算エラー、スキャンタイム超過エラーなどを含み、エラーの重度毎にフィルタリング対象を加除できるようにしてもよい。

なお、フィルタ８０１～８０３のフィルタ条件は論理積として判断され、該当する分析結果が表示される。従って、フィルタ８０１～８０３は必ずしも選択される必要はなく、オペレータが所望するフィルタが選択された場合に分析結果がフィルタリングされてもよい。或いは、オペレータが指定する前にデフォルトでフィルタを選択して分析結果を表示するようにしてもよい。これらの分析結果として表示されるデバイスは、いつもと異なる状態が検知されたデバイスである。いつもと異なる状態とは、たとえば、デバイス値が正常範囲を逸脱したり、デバイス値が変化するタイミングまたは回数が正常範囲を外れたりすることである。製品の製造工場では、日々、同一の製品が大量生産される。つまり、同一の工程が何度も繰り返し実行される。そのため、いつもと異なる状態を検知して表示することは、ラダープログラムを改良したり、生産設備を見直したりするうえで、非常に役に立つ。いつもと同様の状態（正常状態）を定義する正常範囲（正常条件）は、ユーザにより定義されてもよいし、デバイス値の学習結果により定義されてもよい。

検知マップ８１０は、ＰＬＣ１において実行される複数の工程のそれぞれについて開始タイミングと終了タイミングとを含むサイクルを時間軸に沿って表示する。検知マップ８１０において、横方向に延びる矩形は、工程が実行中である期間（制御サイクル）を示している。また、矩形内の丸はサイクル内で発生したいつもと異なる状態が発生した異常発生箇所である異常点を示している。検知マップ８１０の横軸は時間を示し、左端はデータの収集開始時点、右端はデータの収集終了時点を表す。なお、上部の拡大／縮小ボタンを選択することにより、横軸方向の拡大・縮小を行うことができる。その場合の初期表示は、左端がデータ収集開始点、右端はデータの収集終了点であってもよい。或いは、後述するサイクル定義の時間幅で決めてもよい。たとえば、サイクル時間が、１０秒、１０秒、１１秒、９秒、１０秒、１０秒、２０秒である場合に、その中央値の１０秒をとり、３サイクル分が一括で表示できるように、左端から右端を３０秒としてもよい。ここでは、縦軸をデバイス単位としているが、後述するプログラムモジュール単位としてもよい。また、検知マップ８１０には、デバイス値に並べて、カメラ映像の特徴量の値を表示するようにしてもよい。デバイス値と並べて表示することにより、映像の周期的な変化を容易に認識することができる。

図１０に制御サイクル及び異常点の詳細を示す。制御サイクルは、詳細については後述するが開始タイミングと終了タイミングとを設定することで定義することができる。図１０には、デバイスＭＲ０と、デバイスＭＲ１とのデバイス値を示す。図１０に示すように、制御サイクルを、ＭＲ０のＯＦＦからＯＮに変化するタイミングを開始タイミングとし、その後ＭＲ１のＯＮからＯＦＦに変化するタイミングを終了タイミングとして設定する。１００１に示すように、制御サイクルは矩形形状で表すことができ、左端が開始タイミングを示し、右端が終了タイミングを示す。これによりデバイス値を波形で示すよりも、その制御サイクルを一見して確認することができ、サイクルの動作中であるか否かを判断することができる。なお、本発明はこれに限定されず、開始タイミングと終了タイミングとが識別可能な形状であればどのような形状で表されてもよい。例えば、矩形形状ではなく開始タイミングを示す縦線と終了タイミングを示す縦線とを表示し、その内部を背景色と異ならせることによりサイクルを表現してもよい。また、運転記録データの中に開始タイミングや終了タイミングの記録が無い場合には、それらを示す縦線等を検知マップ８１０に描画しなくてもよい。１０１０は定義された制御サイクル内の異常発生箇所を示す。１０１０の例では、異常が発生した箇所を異常点１０１１として表示している。一方で、異常には異常開始から終了までの区間がある。１０２０は異常箇所を区間でプロットした例を示す。１０２１は異常区間を示す。異常区間１０２１の表示では、他のデバイスと異常発生区間が重なっている様子を表現することができ、オペレータにとってはデバイス間の関連性を認識することができ、エラーを特定する際に重要な情報となる。このように各デバイスの異常発生箇所については種々の方法で描画することが可能である。

検知マップ８１０において、工程を示す矩形は、左が古く右が新しいことを示す。時刻バー８１１は、選択中の時刻を示している。時刻バー８１２は、運転記録データの保存トリガが発生したタイミングを示している。上述したように、運転記録データは保存トリガが発生した前後のデータが記録されているため、時刻バー８１２の前後にデータが示されている。時刻バー８１１、８１２はそれぞれ異なる色で描画したり、実線と破線とで異なるように描画したりすることにより、識別力を向上させてもよい。また、時刻バー８１１を操作することにより、分析結果の表示を更新することができる。時刻バー８１１の操作に従って、検知リスト８２０、画像表示領域８３０、および分析コメント８４０の少なくとも１つの後述する時刻バーについても同様に連動して更新され、対応する分析結果が表示されてもよい。

図１１に複数の表示項目が時間軸上の操作に応じて連動して更新される様子を示す。図１１に示すように、例えば検知マップ８１０上で時刻バー８１１を点線の位置に操作したとする。当該操作については、例えばＰＣ２ｂの操作部８ｂがマウスである場合には、不図示のポインタを時刻バー８１１に合わせてドラッグし、ドラッグした状態でポインタを点線の位置に移動操作することにより時刻バー８１１を移動させることができる。移動させると、検知マップ８１０及び検知リスト８２０の表示が、検知マップ１１１０及び検知リスト１１２０に示すように更新される。例えば、時刻バー１１１１の位置に連動して、当該位置から発生したいつもと異なる状態のデバイスが検知リスト１１２０に表示される。このように、何れかの分析結果に表示される時刻バーを操作することにより、それに連動して他の分析結果の表示を更新することにより、オペレータは有用な情報を容易に把握することができる。また、検知リスト上で所定の異常項目を選択すると、検知マップ上においてその異常項目が発生したタイミングに時刻バーが移動するように制御してもよい。検知マップや検知リスト上での選択に応じて、画像表示領域８３０においてその際のカメラ画像が表示されてもよい。或いは、カメラ映像の再生に合わせて検知マップや検知リストが連動して表示を更新してもよい。なお、一部の分析結果は固定して、他の分析結果のみをオペレータの操作に合わせて連動して表示更新を行うようにしてもよい。この場合、例えば固定したい分析結果の時刻バーをダブルクリックするなどして固定操作可能にしてもよい。

画像表示領域８３０は、ＰＬＣ１において取得されたカメラ画像（以下では、カメラ映像とも称する。）を表示する。図８Ａでは、正常時のデータであるマスタデータのカメラ画像と、今回のカメラ画像とが対比可能に表示されている。カメラ画像も時系列データであるため、シークバー８３１は、カメラ画像の再生時刻を示し、再生時刻の経過にしたがって左から右に移動する。時刻バー８３２は、検知対象デバイスがいつもと異なる状態になったタイミングを示しており、上述した時刻バー８１１と連動している。時刻指定部８３３は、カメラ画像の再生時刻を進めたり、再生時刻を戻したり、再生の開始を指示したり、再生を停止したりすることを指示するためのコントロールオブジェクトである。８３４は制御サイクルを指定することができ、指定されたサイクルを基準サイクルとしてカメラ映像が再生される。例えば、時刻指定部８３３の早送りのボタンが操作されると、現在の制御サイクルの次の制御サイクルまで映像がスキップするように制御される。また、サイクルの終了時にジャンプするものであってもよい。

カメラ映像は、運転記録データとして保持されてもよいが、時刻が関連付けられた、外部機器に保存されているデータであってもよい。例えば、拡張ユニットの何れかに接続されたＷｅｂカメラに記録されているカメラ映像であってもよいし、画像検査機に記録されている検査画像であってもよい。外部機器に保存されているデータは、画像以外にも測定器の記録データであってもよく、数値であったり、測定波形が表示されるものであってもよい。なお、結果表示画面８００において、検知マップ８１０の再生時刻、カメラ画像の再生時刻、および、検知リスト８２０の再生時刻は同期するように管理され表示されている。また、図８Ａの点線領域に示すように、検知した異常箇所を映像中において強調表示してもよい。これにより、ユーザはさらに容易に正常時の映像と、今回の映像を対比することができる。

図１２に正常時のマスタデータの映像と分析対象の映像との同期について示す。カメラの映像は、学習時の映像と今回の映像を、選択された基準とするサイクル定義の、サイクル開始タイミングを合わせて表示している。例えば、次のようにすることで同期を実現することができる。まず、カーソルの現在時刻が含まれる制御サイクルを探し、そのサイクル開始時刻からのオフセット時間ｔを求める。図１２の例では今回の映像の実線の矩形領域が取得した運転記録データに対応したデバイスの制御サイクルを示し、点線の矩形領域が定義された基準サイクルを示す。次に、学習時の映像のサイクル開始タイミングを合わせて、並べて、サイクル開始から時間ｔずらした映像を表示する。基準とするサイクルを変えれば、学習時の映像が変わる。学習時の映像の中に、基準とするサイクル定義のサイクル開始が複数あれば、最初の方を表示してもよいし、選択可能としてもよい。このように、基準サイクルに合わせて今回の映像とマスタデータの映像とを同期することができる。

検知リスト８２０は、いつもと異なる状態になったデバイスと、その状態が発生した時刻（デバイス値の収集時刻）とを示す。検知リスト８２０は、いつもと異なる状態となったデバイスを時刻順に示したリストである。ＣＰＵ１１ｂは、検知リスト８２０に表示されたデバイスに対するクリックを検知すると、クリックされたデバイスの識別情報と、再生時刻情報（デバイス値の収集時刻）とに基づいて、検知マップ８１０、検知リスト８２０、および画像表示領域８３０の表示を同期させることができる。時刻バー８２１は、選択中の時刻を示しており、時刻バー８１１、８３１と連動し、同一のタイミングを示している。時刻バー８２２は、運転記録データの保存トリガが発生したタイミングを示している。

分析コメント８４０は、分析結果に含まれるコメントと、検知リスト８２０で選択されたデバイスについての、マスターデータと、今回のデバイス値の時系列データとを表示する。時刻バー８４１は、いつもと異なる状態が発生したタイミングを示し、時刻バー８１１、８２１、８３１と連動し、同一のタイミングを示している。表示されているコメントは、当該デバイスの異常の内容を示している。

ＣＰＵ１１ｂは、検知リスト８２０に表示されたデバイスに対するクリックを検知すると、クリックされたデバイスの識別情報と、いつもと異なる状態になったサイクル情報（サイクルの開始時刻と終了時刻、または、サイクルの開始時刻と次のサイクルの開始時刻）とに基づいて、検知マップ８１０、検知リスト８２０、および分析コメント８４０の表示を同期させることができる。図８Ｂは、検知リスト８２０の何れかの項目が選択された場合に、検知マップ８１０、検知リスト８２０、および分析コメント８４０を同期させた様子を示す。分析コメント８４０は、いつもと異なる状態になったサイクルに対応した時間範囲のデバイス値の時系列データを表示する。このとき、検知マップ８１０上には、分析コメント８４０に表示された時系列データの時間範囲８５４に対応する時間範囲８５２が図示される。検知マップ８１０に図示される時間範囲８５２は、複数の工程のうちいつもと異なる状態になった工程に対応して図示される。たとえば、検知リスト８２０に表示されたデバイスのうち、現在と異なるデバイスの項目８５３がクリックされると、クリックされたデバイスについて、いつもと異なる状態になったサイクルに対応した時間範囲のデバイス値の時系列データに切り替わる。その際、検知マップ８１０上では、分析コメント８４０に表示された時系列データの時間範囲８５４に対応する時間範囲８５２を含む範囲に表示が切り替わる。また、矢印８５５で示すように、検知マップ８１０上において、点線や色付きの実線の枠などによって時間範囲８５２が強調表示され、分析コメント８４０における切り出し区間との対応が確認できるように表示される。これにより、分析コメント８４０が検知マップ８１０上のどの区間を切り出した波形かをオペレータに容易に把握させることができる。また、８５４に示すように、分析コメント８４０においても波形の下部に、切り出した区間に対応するサイクルを示す矩形や異常点を表示することにより、サイクルの開始タイミングや、終了タイミングと波形や異常との関係をオペレータに容易に把握させることができる。また、検知マップ８１０は、８５１に示すように、検知リスト８２０で選択されたデバイスに対応する異常点を拡大表示してもよい。また、分析コメント８４０に表示された時系列データの時間範囲が、サイクルの開始時刻と次のサイクルの開始時刻の場合、分析コメント８４０には、時系列データの時間軸に対応して、サイクルの終了時刻を示す位置に図式表示がされてもよい。

このように、結果表示画面８００は検知マップ８１０、検知リスト８２０、画像表示領域８３０、および分析コメント８４０など複数の分析結果の表示を含んで構成される。しかし、これらの結果表示は一例であり他の結果表示が追加的に又は代替的に含まれてもよい。たとえば、図９に示すように、分析結果として、デバイス間の依存情報（リレーションマップ）を表示してもよい。基本ユニット３は、ラダープログラムを解析することで、デバイス・変数間の依存関係を把握することができる。たとえば、ある検知されたデバイスを選択されると、それに関係するデバイスも並べて表示するなど、依存関係のあるデバイスをオペレータへ提示することができる。これにより、オペレータに対して異常の把握や特定を支援することができる。

＜リレーションマップ＞
図９はリレーションマップ９００を示している。リレーションマップ９００は、ラダープログラム等のユーザプログラムにおいて、特定のシンボルに関連するプログラムモジュールと、そのプログラムモジュールに関連する他のシンボルとの関係を示す図式表示であり、たとえば、特定のシンボルとして、ラダープログラムに使用されるいつもと異なる状態になったデバイス（非正常デバイス）を選択した場合は、当該非正常デバイスに対してラダープログラムにおいてプログラムモジュールを介して関連している他のデバイスを表示するＵＩとなる。このＵＩは結果表示画面８００において不図示の表示ボタンを操作することにより遷移する画面であってもよいし、結果表示画面８００上に追加で表示されてもよい。リレーションマップを表示することにより、ユーザは、非正常デバイスと他のデバイスとの依存関係を容易に理解できる。一般に、ＰＬＣ１において利用されるデバイスの数は数百から数万であるため、ユーザは、いつもと異なる状態になったデバイスから、その原因となったデバイスを特定することは容易ではない。ＣＰＵ１１は、非正常デバイスについてラダープログラム内を検索し、非正常デバイスに関する記述を発見し、当該記述を分析することで、関連デバイスを特定する。この例では、ラダープログラム内の出力部において、非正常デバイス（例：Ｒ０００４）が記述されており、関連デバイスとしてＭＲ０００、ＭＲ００１、ＭＲ００２が存在する。

ＣＰＵ１１ｂは、ラダープログラムから特定した非正常デバイス、関連デバイスおよびプログラムモジュールをツリーのように表示する。ユーザプログラム（ラダー、Ｃ言語、フロー言語、スクリプトなど）は、可読性やメンテナンス性向上のために、いくつかに分けて記述することが多く、その単位をプログラムモジュールと称する。１つのプログラムモジュールの中では、各デバイスを読み書きするプログラムが記述され、１つのデバイスは複数のモジュールで読み書きされることもあるが、主に使用されるモジュールは１つであることが多い。図９の例では、出力部における演算のために入力されるデバイスが左側に表示され、プログラムモジュールが真ん中に表示され、その右側に非正常デバイスが表示されている。図９が示すように、リレーションマップ９００上のプログラムモジュールが選択されると、ＣＰＵ１１ｂは、該当するプログラムモジュールをプログラム表示領域９１０に表示してもよい。なお、ここではＰＣ２ｂのＣＰＵ１１ｂが表示処理を制御する例で説明しているが、一例でありＰＣ２ａのＣＰＵ１１ａで行われてもよい。また、上述した検知マップ８１０についても、デバイス単位ではなくプログラムモジュール単位で表示するようにしてもよい。

ＣＰＵ１１は、シンボルを特定するユーザ指定に応じて、ユーザプログラムからシンボルに関連するプログラムモジュールを特定し、特定したプログラムモジュールに関連する他のシンボルを特定して、リレーションマップ１５００を生成する。ＣＰＵ１１は、分析結果に基づいてリレーションマップ１５００内に含まれる非正常デバイスを強調表示する。分析結果は非正常デバイスがいつもと異なると判断した時刻も含んでおり、ＣＰＵ１１は、再現する時刻よりも前に発生した非正常デバイスのみをリレーションマップ１５００上で強調表示するようにしてもよい。これにより非正常デバイスは、いつもと異なる状態が発生して以降、強調表示が保持されることになる。また、分析結果には、各シンボルのうち、分析対象外のシンボルであることを示す情報が含まれてもよい。この場合、ＣＰＵ１１は、分析結果に基づいてリレーションマップ１５００上で分析対象外のシンボルと他のシンボルと色などを区別して表示する。これにより、分析により非正常でないと判断したのか、未分析のため非正常と判断されなかったのかを区別できる。分析対象外のシンボルとは、たとえば、制御サイクルやサイクル設定により定義されるサイクルに対し、シンボル値の変化パターンが規則性を持たないシンボルであったり、ユーザにより分析対象外として指定されたシンボルを含む。

＜モデル生成フロー＞
図１３は、上記Ｓ３におけるモデル生成フローの詳細を示す。ここでは、デバイスの属性情報としてデバイスの制御サイクルを判断してモデルを生成する制御について説明する。なお、本発明はこれに限らず上述した他の属性情報に基づいてモデルを生成してもよい。以下で説明するように、分析ユニット４ａは複数の同期しない工程（サイクル）のデータであっても、自動で工程（サイクル）に属するデバイス・変数を抽出する。これにより、オペレータが予め手動で工程（サイクル）とデバイスとの紐づけを行う非常に手間となる作業を省略することができる。以下で説明する処理は、分析ユニット（拡張ユニット）４ａのＣＰＵ４１ａによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。

まずＳ３１で分析ユニット４ａのＣＰＵ４１ａは、基本ユニット３からモデル作成用の正常時の運転記録データを取得する。当該運転記録データは、上記Ｓ２で運転記録記憶部３７に格納されたデータである。続いて、Ｓ３２でＣＰＵ４１ａは、デバイス値以外の情報として、基本ユニット３からサイクル設定の情報を取得する。サイクル設定の情報は、たとえばＰＣ２ａを介してオペレータから設定されたサイクルパターンの情報を示す。たとえば、サイクルの開始タイミングとサイクルの終了タイミングとを示す。また、ここで取得する情報には、拡張ユニット４ｂに接続されたカメラ等のフィールドデバイス１０で取得された情報、たとえばカメラ画像データなども含まれてもよい。これらのデータについては基本ユニット３を介して取得してもよいが、たとえば拡張ユニット４ｂなどから直接取得するようにしてもよい。

次に、Ｓ３３でＣＰＵ４１ａは、Ｓ３２で取得したサイクル設定に基づき、各デバイスが何れのサイクルに属するかを判定する。各デバイスのサイクルパターンには種々のパターンが存在するものであり、ここでは各デバイスがサイクル設定で指定された何れのパターンに属するデバイスであるかを判断する。サイクル設定が複数の制御サイクルに対応した設定を含む場合、各制御サイクルに属するデバイスを判定するようにしてもよい。このとき、複数の制御サイクルに属すると判断されるデバイスが存在してもよい。図１４は、各デバイスのサイクルパターンを判別する制御について示す。図１４において、矩形は工程が実行中である期間（サイクル）の開始タイミングから終了タイミングまでを示しており、１つの矩形が１サイクルを示す。サイクルパターンとはこの１サイクルが出現するパターンである。１４０１～１４０３はサイクル設定された工程を示す。１４０４～１４０６はそれぞれデバイスＡ～Ｃの収集データから抽出したサイクルパターンを示す。分析ユニット４ａは各デバイスについて何れのサイクル設定のパターンに属するかを判断し、たとえばデバイスＡがサイクル設定１に属し、デバイスＢがサイクル設定２に属し、デバイスＡが設定された何れのサイクル設定にも該当しないと判断する。具体的には、サイクル開始から終了までの、値と変化回数が一致しているかを判定している。なお、開始タイミングや終了タイミングについては多少ずれても問題ない。このように、分析ユニット４ａは、各サイクル設定のパターンと各デバイスとがどのような対応関係かを判定する。分析ユニット４ａは各サイクル設定のパターンについて何れのデバイスが属するかを判断するようにしてもよい。

分析ユニット４ａは、各サイクル設定のパターンと各デバイスとがどのような対応関係か判定する際に、各サイクル設定のサイクル開始からサイクル終了までにおける各デバイス値のパターンに基づいて判定する。これにより、サイクルの終了から次の開始までデバイス値がどのような動作をしても、そのデバイスを当該サイクル設定のパターンに属すると判断することができる。また、分析ユニット４ａは、各サイクル設定のパターンと各デバイスとがどのような対応関係か判定する際に、各サイクルの基準タイミングから次のサイクルの基準タイミングまで、たとえばサイクル開始から次のサイクル開始までのデバイスの値と変化回数が一致しているかで判定してもよい。

ＰＬＣ１において実行される複数の工程のそれぞれについて開始タイミングと終了タイミングとを含むサイクル、つまり、工程が実行中である期間を制御サイクルはサイクル設定の対象とされているが、サイクル設定の対象はこれに限られない。図２１は、開始タイミングから終了タイミングの期間以外にも変化するデバイスが存在する場合のサイクルの処理フローを示す。図２１に示すように、作業工程を実行するために、作業工程を実行するための準備として作業開始条件を満足しているかを確認する確認フェーズ２１０１が存在してもよく、また、作業開始フェーズ２１０２、作業フェーズ２１０３、及び作業終了フェーズ２１０４の作業工程の実行後には次の工程の準備をする準備フェーズ２１０５、次の工程まで待機する待機フェーズ２１０６等が存在してもよい。このため、作業工程の実行中以外の期間においても変化するデバイスは存在し、異常要因を突き止めるための手がかりとなり得る。たとえば、確認フェーズにおいて作業開始条件の成立に関連する入力デバイス、準備フェーズにおいて次の準備の制御信号を示すデバイスなどは、開始タイミングから終了タイミングまでの期間以外の期間で動作するため、これらのデバイスの分析結果は、異常要因を突き止めるための手がかりとなり得る。要するに、サイクル設定の対象は、サイクルの基準タイミングから次の基準タイミングまでであってもよく、これにより隙間なく分析することができる。また、サイクル設定では、ユーザにより開始タイミングを規定するデバイスと、終了タイミングを規定するデバイスとが選択されたり、正常時の運転記録データなどを学習することで自動的に設定されたりする。しかし、分析対象の期間が開始タイミングから終了タイミングに限定されると、工程の開始を規定するデバイスや工程の終了を規定するデバイスを正確に把握していない場合、そのようなデバイスを見つけ出すことは困難なことがある。サイクル設定の対象をサイクルの基準タイミングから次の基準タイミングまでとすることで、工程の開始を規定するデバイスや工程の終了を規定するデバイスを厳密に指定しなかったとしても、工程に同期するデバイスを選択するだけで隙間なく分析することができる。

図１３の説明に戻る。Ｓ３３でＣＰＵ４１ａは、抽出したサイクルパターンを属性情報として各デバイスに付加する。次に、Ｓ３４でＣＰＵ４１ａは、付加された属性情報に基づいてＳ３１で取得した運転記録データからモデルを生成し、処理を終了する。生成したモデルは、分析時に利用するマスタデータであり、少なくとも各デバイスのサイクルパターンの情報が含まれる。

＜結果表示フロー＞
図１５は、上記Ｓ７における分析ユニット４ａによる結果表示フローの詳細を示す。以下で説明する処理は、分析ユニット（拡張ユニット）４ａのＣＰＵ４１ａによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部が他のユニットで実行されてもよいし、それらの処理の全てが一つのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された外部装置（分析装置）によって実行されてもよい。

まずＳ７１で分析ユニット４ａのＣＰＵ４１ａは、分析レポートの要求を受け付けたか否かを判断する。分析レポートの要求とはオペレータによってＰＣ２ａ、ＰＣ２ｂを介して受信する要求や、定期的な分析レポート作成タイミング、エラー発生時の分析レポートの作成などが含まれる。ＰＬＣ１としては、いつもと異なる状態のデバイスが検知された場合にはオペレータからの要求なしに分析レポートを作成してもよいし、オペレータからの要求があって初めて分析レポートを作成するようにしてもよい。これらの制御は設定で切り替えることができる。分析レポートの要求を受け付けていればＳ７２に進む。

Ｓ７２でＣＰＵ４１ａは、基本ユニット３の運転記録記憶部３７に格納された分析結果７７を取得する。続いて、Ｓ７３でＣＰＵ４１ａは、取得した分析結果に従って、ＰＣ２ａやＰＣ２ｂなどのＷｅｂクライアントのＷｅｂブラウザで表示可能な分析レポートを生成する。生成する分析レポートは図８Ａを用いて上述した結果表示画面８００を表示するための画面情報となる。ここでは、各分析結果を同期させて表示するための同期情報も付加される。具体的には、検知マップ８１０、検知リスト８２０、画像表示領域８３０、及び分析コメント８４０に表示する画面情報に加えて、各分析結果の表示位置を示唆する情報が含まれる。表示位置を示唆する情報とは、上述したように、定義された制御サイクルのタイミング情報であってもよいし、単なる時刻情報であってもよい。即ち、同期可能な情報であればよい。

次に、Ｓ７４でＣＰＵ４１ａは、Ｓ７３で生成した分析レポートを要求元のＰＣ２へ送信する。ここで送信する情報は、ＨＴＭＬデータ、ＣＳＳデータおよびＪａｖａＳｃｒｉｐｔ（登録商標）コードなどを含む情報であってもいし、単に分析レポートの生成が完了したことを示す通知であってもよい。通知を行う場合には改めてＰＣ２側から表示要求を受け付けると、ＣＰＵ４１ａは画面情報を送信する。その後、Ｓ７５でＣＰＵ４１ａは、要求元から分析レポートの更新要求が受け付けたか否かを判断する。更新要求とは、例えば表示部品の変更や、フィルタ８０１～８０３の選択による表示対象の変更、時刻バー８１１などを操作したことにより分析結果の時間的な表示位置の更新などである。なお、時刻バー８１１などを操作したことによる表示内容の更新については、ＰＣ２側に閉じた制御としてもよい。この場合、表示対象となっている表示部品の情報に加えて、当該表示部品上で表示しているデバイスの分析結果についての情報もＰＣ２側へ提供する必要がある。更新要求を受け付けるとＳ７６に進み、そうでない場合はＳ７７に進む。

Ｓ７６でＣＰＵ４１ａは、更新要求の指示内容に従って分析レポートを更新し、処理をＳ７４へ戻し更新した分析レポートを要求元へ送信する。一方、Ｓ７７でＣＰＵ４１ａは、分析レポートの表示を終了する終了指示を受け付けたか否かを判断する。終了指示を受け付けていない場合は処理をＳ７５に戻し、終了指示を受け付けたと判断した場合は処理を終了する。

図１６は、上記Ｓ７におけるＰＣ２ｂにおける結果表示フローの詳細を示す。以下で説明する処理は、ＰＣ２ｂのＣＰＵ１１ｂによって実行される処理として説明する。しかし、本発明を限定する意図はなく、それらの処理の一部がＰＬＣのユニットで実行されてもよいし、或いはプログラマブルロジックコントローラに通信可能に接続された他の外部装置（ＰＣ２ａなど）によって実行されてもよい。ＰＬＣのユニットで実行される場合には当該ユニットにはモニタが設けられる。また、ここで説明する処理は、分析ユニット４ａによって生成された分析レポートをブラウザとして表示する処理である。

Ｓ８１でＣＰＵ１１ｂは、操作部８ｂを介して分析レポートの表示要求を受け付けたか否かを判断する。受け付けた場合にはＳ８２に進む。Ｓ８２でＣＰＵ１１ｂは、分析レポートを分析ユニット４ａに対して要求する。その後、Ｓ８３でＣＰＵ１１ｂは、分析ユニット４ａから要求に対応する応答（分析レポート）を受信したか否かを判断する。ここで受信する情報としては、分析レポートを表示させるためのＵＲＬ（ＩＰアドレス）であってもよいし、分析レポートそのものの情報であってもよい。ここではＵＲＬを受信したものとして以下の処理を説明する。

応答を受信するとＳ８４でＣＰＵ１１ｂは、Ｗｅｂブラウザ１８に指定して分析レポートを表示させる。続いて、Ｓ８５でＣＰＵ１１ｂは、分析レポートの表示を更新する更新要求を受け付けたか否かを判断する。受け付けた場合はＳ８６へ進み、そうでない場合はＳ８７へ進む。Ｓ８６で、更新要求を受け付けるとＳ８６でＣＰＵ１１ｂは、更新要求をＷｅｂサーバである分析ユニット４ａへ送信し、処理をＳ８３に戻す。一方、更新要求でない場合はＳ８７でＣＰＵ１１ｂは、分析レポートの表示を終了する終了指示を受け付けたか否かを判断する。終了指示を受け付けていないと判断した場合は処理をＳ８５へ戻し、終了指示を受け付けたと判断した場合は処理を終了する。

＜プログラムエディタとの連携＞
図１７はユーザプログラムの編集画面であるプログラムエディタを示す。ここではプログラムエディタからの分析レポートの表示方法について説明する。プロジェクト編集プログラム１４ａのＵＩ１００はＰＣ２ａの表示部７ａに表示される。したがって、基本ユニット３に接続されたＰＣ２ａからも分析レポートを確認することができる。一方、ＰＣ２ｂがＰＣ２ａから基本ユニット３及び分析ユニット４ａを介して画面情報を取得してプログラムエディタを表示部７ｂに表示することも可能である。モード選択メニュー１０１は、プロジェクト編集プログラム１４ａが備える複数のモードを選択可能に表示する。複数のモードは、編集モード、モニタモード、リプレイモード（デバッグモード）などを含む。

編集モードは、プログラム表示領域１０４に表示されるラダープログラムを編集するモードである。プロジェクト表示領域１０２は、プロジェクトを構成する情報を表示する。この情報としては、ＰＬＣ１を構成している基本ユニット３および拡張ユニット４の仕様情報および設定情報、デバイスの割り当て情報、運転記録の設定情報、ラダープログラムなどがある。編集モードにおいて、プログラム表示領域１０４は、プロジェクト表示領域１０２において指定されたラダープログラムを編集可能に表示する。モニタモードは、ＰＬＣ１により発行される通知を待ち受けるモードである。拡張ユニット４ａが分析結果を作成したことを示す通知を発行すると、ＣＰＵ１１は、通知を表示するためのダイアログなどを表示部７に表示する。モニタモードのユーザインタフェースは、基本的に、編集モードと同様である。

図１７が示す画面例ではリプレイモードが選択されている。リプレイモードは、運転記録をラダープログラム上で再現したり、運転記録を波形として表示したりするモードである。図１７においては、入力部、出力部および加工部状態と命名されたプログラムモジュールを有するラダープログラムが表示されている。とりわけ、複数のプログラムモジュールはタブ１０７によって選択可能であり、図１７では、入力部に対応するタブ１０７が選択されている。ポインタ１０３は、操作部８ａに対するユーザ操作に連動して移動し、ボタンなどを押し下げするために使用されたり、オブジェクトを選択したりするために使用される。たとえば、プロジェクト表示領域１０２において表示された分析レポートがポインタ１０３によりダブルクリックされると、ＣＰＵ１１ａはＣＰＵ１１ｂと同様にＷｅｂブラウザとして機能し、図８Ａを用いて説明した分析レポートを表示させる。

リプレイモードでは、プログラム表示領域１０４に、運転記録に含まれているデバイス値がラダープログラム上に表示される。リレーデバイス（ビットデバイス）の場合、デバイス値が０であるか、１であるかが視覚的に区別可能に表示される。視覚的に区別可能とは、異なる色による表示や異なるアイコンの表示を含む。ワードデバイスの場合、たとえば、デバイス値が１０進化されて表示されてもよい。

デバイス値は時間とともに変化しうる時系列データであるため、各デバイス値は、収集された時刻を示す時刻情報に紐づけられている。シークバー１０５ａは、デバイス値の再生時刻を示すとともに、再生時刻を指定するためにポインタ１０３により操作されることがある。運転記録の再現中は、再生時刻の経過に連動して、シークバー１０５ａが左から右へと移動する。時刻指定部１０６ａは、再生時刻を進めたり、再生時刻を戻したり、再生の開始を指示したり、再生を停止したりすることを指示するためのコントロールオブジェクトである。

＜サイクル設定＞
図１８は、サイクルを定義する設定画面１８００を示す。設定画面１８００は、例えばＰＣ２ａの表示部７ａに表示中のＵＩ１００から所定の操作が行われた場合に表示部７ａに表示される画面である。図１８に示すように、ＵＩ１００上に表示されているプログラムエディタに重畳して表示されてもよいし、ＵＩ１００に表示されているプログラムエディタから遷移する画面として表示されてもよい。なお、設定画面１８００はＰＣ２ｂ上のＷｅｂブラウザ１８上で表示されてもよい。

設定画面１８００には、運転記録分析を行う際のアプリケーションやアプリケーション名を指定する設定領域１８０１、１８０２が含まれる。これらの設定領域１８０１、１８０２は分析対象を設定するためのものである。図１８にはデフォルトの設定が示してあり、オペレータは特に設定しなくてもよい。さらに、設定画面１８００には基本設定の領域が有り、ここで制御サイクルを指定することができる。１８０３は制御サイクルの指定方法を設定し、１８０４はサイクル名を設定し、１８０５は開始トリガを設定し、１８０６は終了トリガを設定することができる。また、デフォルトでは制御サイクルは指定されておらず、追加ボタン１８０７のみが表示されている。

図１８に示す例では、Ｎｏ．０，１，２の制御サイクルが既に指定されている状態を示す。本実施形態によれば、このように分析対象となる制御サイクルとして、１以上の制御サイクルを指定することができる。したがって、オペレータは広範囲に分析したい場合においては、複数の制御サイクルを指定することでより意図した分析レポートを確認することができる。指定方法１８０３は制御サイクルの起点となる開始タイミング及び終点となる終了タイミングを指定する開始・終了指定と、開始タイミングのみを指定する開始指定を選択することができる。したがって、終了トリガ１８０６は開始・終了指定が選択された場合にのみ終了タイミングを指定することができる。ここでは、各サイクル定義毎に、所属するデバイスやデバイスのグループを設定していない。したがって、分析ユニット４ａ等が定義された制御サイクルに対応するデバイスを特定して分析を行うことになる。複数の制御サイクルを指定可能であるため、１つのデバイスが複数の制御サイクルに対応する可能性もある。この場合においては、分析対象として前述の信頼度や、サイクルの開始と終了とのバラツキが小さいことを使用して自動的に優先度をより高く設定するようにしてもよい。当該優先度が高ければ分析レポートにおいて優先的に表示または絞って表示するようにしてもよい。一方で、特定のデバイスを各サイクル定義に紐づける設定を行えるようにしてもよい。

設定画面１８００にはさらに、設定保存１８１１、設定読出１８１２、ＯＫボタン１８１３、及びキャンセルボタン１８１４を含んで構成される。設定保存１８１１は設定画面１８００内で設定された設定内容を保存するためのボタンである。設定読出１８１２は基本ユニット３のメモリ３２のプロジェクト記憶部３５に予め保持されている設定ファイルを読み出すためのボタンである。当該設定ファイルには、１以上の制御サイクルが予め指定されている。当該設定ファイルを読み出した後に、さらに制御サイクルを追加することも可能である。ＯＫボタン１８１３は設定画面１８００上に設定されている内容を有効にして設定処理を終了するためのボタンである。キャンセルボタン１８１４は設定画面１８００上に設定されている内容を適用することなく設定処理を終了するためのボタンである。

＜サイクル未設定＞
図１９はサイクル未設定の分析レポートの検知マップ８１０を示す。分析ユニット４ａはサイクル未設定であっても分析は可能であるが、分析可能なデバイスは極端に少ない。つまり、サイクルパターンを有していないデバイスに限られる。サイクルパターンを有していないデバイスとは、たとえばデバイス値が固定値で変化しないデバイスである。たとえば、図１９の１９０１に示すように、常時ＯＮや常時ＯＦＦのデバイスはサイクルが未設定であっても分析を行うことができる。一方、所定のサイクルパターンを有するデバイスについてはサイクルが未設定であれば分析を行うことができない。このように、分析可能なデバイスが少ないため、サイクルが未設定の場合も分析自体は可能であるものの、分析結果の有効性は限定的である。したがって、図１９に示すように、分析レポートにおいて、サイクルが未設定である旨と、サイクル設定を促すメッセージ１９０２を表示するようにしてもよい。「サイクル設定して分析する」が選択されるとサイクル設定のポップアップ画面が表示され、オペレータはサイクル設定を行うことができる。

＜変形例＞
本発明は上記実施形態に限らず様々な変形が可能である。以下では種々の変形例について図面を参照して説明する。

＜システム構成の変形例＞
図２０はＰＬＣシステム構成の変形例を示す。上記実施形態では、ＰＬＣシステムとして、基本ユニット３、分析ユニット４ａ、およびカメラユニットなどの拡張ユニット４ｂで構成されるＰＬＣ１と、基本ユニット３に接続されるＰＣ２ａと、分析ユニット４ａに接続される分析レポートを表示するＰＣ２ｂとを含んで構成される例について説明した。しかし、これらの構成は一例であって、上述した運転記録データの収集、モデルの生成、分析、分析結果の表示については何れの装置やユニットで行われてもよいし、さらに他の外部装置や他の拡張ユニットによって実現されてもよい。ここではそのような構成の変形例について説明する。

たとえば、図２０に示すように、上記実施形態に係る分析ユニット４ａの機能をＰＬＣ１の上位層に配置される分析装置（サーバ装置として機能する）２ｃで実現してもよい。モデルの学習フェーズの処理などは非常に処理負荷が高く、処理時間を要するものであるため、ＰＬＣユニットの処理能力に応じて外部で実現することも想定され得る。また、上位層の装置に分析機能を設けることにより、他のＰＬＣからも情報を吸い上げることもでき、より信頼度の高いモデルを生成することも可能となる。分析装置２ｃは、ＰＬＣ固有情報の解析、モデルの生成、分析、分析レポートの作成などの機能を有する。これらの機能については、分析ユニット４ａと同様の処理であるため説明を省略する。

また、上記実施形態では、基本ユニット３が全デバイスの運転記録データを収集していたが、他の拡張ユニットで行ってもよい。たとえば、図２０に示すように、拡張ユニットとしてレコーダユニット４ｃを設けてもよい。レコーダユニット４ｃはＣＰＵ４１ｃと、メモリ４２ｃと、通信部４３ｃとを備える。メモリ４２ｃには、上記実施形態で基本ユニット３に設けられていたリングバッファ４４ｃと、運転記録記憶部４５ｃとの記憶領域が設けられる。運転記録の収集については、上記実施形態の基本ユニット３と同様の処理であるため詳細な説明については省略する。

このように、本発明によれば、上記実施形態で説明した処理機能を実現する装置又はユニットは可能な範囲で変更することができるものであり、本発明はそれらの変形を包括するものである。上記変形例では、基本ユニット３とは別に運転記録データを収集するレコーダユニット４ｃを設ける例を説明したが、当該ユニットには収集機能および通信機能を設けて、保存先についてはネットワークを介して接続されたデータベースとしてもよい。これにより、より大容量のデータを保存することができ、トリガ発生時よりもかなり遡った解析を行うことができるとともに、他のＰＬＣシステムのデータも利用することが可能となる。

また、上記変形例では、処理機能を基本ユニット３とは別のユニットで実現したり、外部装置で実現する例について説明したが、基本ユニット３にそれらの処理機能を一体化する形態であってもよい。このような構成のメリットは、他のユニットや外部装置との通信処理を省略できるため通信による処理負荷を低減でき、ＰＬＣ制御への影響を低減することができる点にある。なお、一体化する場合においての性能は基本ユニット３の性能に依存することになるため、基本ユニット３の高性能化が必要となる。

＜まとめ＞
［観点１］
本発明は、分析装置であって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段とを備える。本実施形態によれば、各デバイスの分析結果を同期させたレポートを提供することできる。

［観点２］
上記実施形態において、１以上の制御サイクルの定義を設定する設定手段をさらに備え、前記モデル生成手段は、設定された前記１以上の制御サイクルの定義に基づいて、取得された前記運転記録データの学習を行い、前記レポート生成手段は、前記非正常デバイスとして検知した各デバイスの分析結果を、設定された前記１以上の制御サイクルの定義に従って各デバイスの分析結果を時間軸上に同期させて表示する分析レポートを生成する。本実施形態によれば、定義された制御サイクルに従って運転記録データを分析することができ、各デバイスのサイクルに従って分析結果を同期させることができる。

［観点３］
上記実施形態において、分析装置は、前記レポート生成手段から出力された前記分析レポートの内容を示す結果表示画面の画面情報を外部装置へ送信する送信手段をさらに備え、前記外部装置では、前記結果表示画面が操作可能に表示部に表示される。本実施形態によれば、分析レポートを外部装置へ送信することができ、たとえばより高性能のＰＣ等で分析レポートを解析することができ、より詳細な分析やよりリッチな操作体系を有する結果表示画面の表示を可能とする。

［観点４］
上記実施形態において、前記結果表示画面には、前記分析結果として、検知された非正常デバイスのサイクルおよび異常が検知されたタイミングを示す検知マップと、検知された非正常デバイスの工程および発生時刻を示す検知リストと、カメラ映像と、いつもと異なる状態が検知された原因を示す分析コメントとの少なくとも１つが含まれる。本実施形態によれば、分析結果を種々の形態で多面的に表示することができ、オペレータによる解析を支援することができる。

［観点５］
上記実施形態において、前記検知マップ、前記検知リスト、前記カメラ映像、および前記分析コメントは、互いに時間軸を連動して操作可能である。本実施形態によれば、分析結果の１つの表示形態に対して操作することにより、他の表示形態の分析結果も連動して更新され、オペレータに対してより快適な操作体系を提供することができる。

［観点６］
上記実施形態において、前記検知マップでは、検知された非正常デバイスのサイクルの開始タイミング及び終了タイミングが識別可能な形状で示され、 異常が検知されたタイミングを示す異常点が前記形状の内部に含まれる。本実施形態によれば、サイクルの開始タイミング及び終了タイミングを確認しつつ、サイクル内の異常点を把握することができ、より容易に異常の解析を行うことができる。

［観点７］
上記実施形態において、前記カメラ映像では、分析対象の映像と、該分析対象の映像に対応する正常時の映像とが比較可能に表示される。本実施形態によれば、異常時の映像を正常時の映像と対比しながら確認することができ、より容易に異常を特定することができる。

［観点８］
上記実施形態において、前記正常時の映像は、前記分析対象の映像の制御サイクルに同期させて表示される。本実施形態によれば、対比する２つの映像をより正確に同期させることができる。

［観点９］
上記実施形態において、前記結果表示画面には、前記カメラ映像の再生位置を示すシークバーが含まれる。本実施形態によれば、分析対象の映像の再生地を容易に確認することができる。

［観点１０］
上記実施形態において、前記結果表示画面には、さらに、前記分析レポートの表示項目を絞るための条件を指定可能なフィルタ設定領域が含まれる。本実施形態によれば、不要な表示項目を結果表示画面から除外することができ、より容易に異常の解析を行うことができる。

［観点１１］
上記実施形態において、前記フィルタ設定領域では、デバイスの制御サイクルの指定、属性情報の指定、および、イベント、エラーの指定の少なくとも１つによってフィルタが指定可能である。本実施形態によれば、オペレータが表示項目を絞る際に種々の選択肢を提供することができる。

［観点１２］
上記実施形態において、前記ユーザプログラムの編集画面を表示する表示手段をさらに備え、前記編集画面では、該編集画面の時間軸に同期した前記分析レポートが表示可能である。本実施形態によれば、ユーザプログラムと連携して分析レポートを表示することができ、ユーザプログラムも加味した分析を行うことができる。

［観点１３］
上記実施形態において、前記分析レポートの生成要求を受け付ける受付手段と、前記レポート生成手段によって前記生成要求に応じて前記分析レポートが生成されると、要求元に分析レポートの生成が完了した旨を通知する通知手段とをさらに備える。本実施形態によれば、分析レポートの生成が完了した旨をオペレータに通知することができ、よりユーザフレンドリな操作体系を実現することができる。

［観点１４］
上記実施形態において、前記分析手段は、前記設定手段によって制御サイクルが定義されていない場合において、制御サイクルのサイクルパターンを有していないデバイスを分析対象として、前記運転記録データを分析する。本実施形態によれば、オペレータに対してサイクルパターンの設定操作を要求することなく分析レポートを容易に出力することができる。従って、オペレータはサイクルパターンを設定することなく、お試しで分析レポートを生成することもでき、生成された分析レポートを解析してより詳細に分析すべくサイクルパターンを設定するなどの解析手法も行うことができる。

［観点１５］
上記実施形態において、前記レポート生成手段は、制御サイクルのサイクルパターンを有していないデバイスの分析結果を分析レポートとして生成し、 前記分析レポートには、制御サイクルが設定されていない旨と、前記設定手段によって制御サイクルの設定を促すメッセージが含まれる。本実施形態によれば、オペレータがサイクル設定を忘れている場合などに、サイクル設定を促すことができ、よりユーザフレンドリな操作体系を提供することができる。

［観点１６］
本発明は、データ処理装置とプログラマブルロジックコントローラとが通信可能な分析システムであって、ユーザプログラムを繰り返し実行する実行エンジンと、前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段とを備えることを特徴とする。本実施形態によれば、各デバイスの分析結果を同期させたレポートを提供することできる。

［観点１７］
上記実施形において、前記取得手段、前記モデル生成手段、分析手段、および前記レポート生成手段の少なくとも１つは前記データ処理装置に設けられる。本実施形態によれば、ＰＬＣの開発コストや、データ処理装置の性能等に応じて、本発明を実現するための構成をフレキシブルに適切なコンポーネントへ組み込むことが可能となり、システム設計の自由度を向上することができる。

［観点１８］
上記実施形態によれば、前記プログラマブルロジックコントローラは、前記実行エンジンを備えるＣＰＵユニットと、前記取得手段を実現する前記プログラマブルロジックコントローラに設けられるレコーダユニットとを備え、前記データ処理装置は、前記モデル生成手段、分析手段、および前記レポート生成手段を備える。本実施形態によれば、ＰＬＣの開発コストや、データ処理装置の性能等に応じて、本発明を実現するための構成をフレキシブルに適切なコンポーネントへ組み込むことが可能となり、システム設計の自由度を向上することができる。

発明は上記の実施形態に制限されるものではなく、発明の要旨の範囲内で、種々の変形・変更が可能である。

Claims (19)

1. 分析装置であって、
   ユーザプログラムを繰り返し実行する実行エンジンと、
   前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、
   取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、
   取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、
   前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段と
   を備えることを特徴とする分析装置。
2. １以上の制御サイクルの定義を設定する設定手段をさらに備え、
   前記モデル生成手段は、設定された前記１以上の制御サイクルの定義に基づいて、取得された前記運転記録データの学習を行い、
   前記レポート生成手段は、前記非正常デバイスとして検知した各デバイスの分析結果を、設定された前記１以上の制御サイクルの定義に従って各デバイスの分析結果を時間軸上に同期させて表示する分析レポートを生成することを特徴とする請求項１に記載の分析装置。
3. 前記レポート生成手段から出力された前記分析レポートの内容を示す結果表示画面の画面情報を外部装置へ送信する送信手段をさらに備え、
   前記外部装置では、前記結果表示画面が操作可能に表示部に表示されることを特徴とする請求項１又は２に記載の分析装置。
4. 前記結果表示画面には、前記分析結果として、検知された非正常デバイスのサイクルおよび異常が検知されたタイミングを示す検知マップと、検知された非正常デバイスの工程および発生時刻を示す検知リストと、カメラ映像と、いつもと異なる状態が検知された原因を示す分析コメントとの少なくとも１つが含まれることを特徴とする請求項３に記載の分析装置。
5. 前記検知マップ、前記検知リスト、前記カメラ映像、および前記分析コメントは、互いに時間軸を連動して操作可能であることを特徴とする請求項４に記載の分析装置。
6. 前記検知マップでは、
   検知された非正常デバイスのサイクルの開始タイミング及び終了タイミングが識別可能な形状で示され、
   異常が検知されたタイミングを示す異常点が前記形状の内部に含まれることを特徴とする請求項４又は５に記載の分析装置。
7. 前記カメラ映像では、分析対象の映像と、該分析対象の映像に対応する正常時の映像とが比較可能に表示されることを特徴とする請求項４乃至６の何れか１項に記載の分析装置。
8. 前記正常時の映像は、前記分析対象の映像の制御サイクルに同期させて表示されることを特徴とする請求項７に記載の分析装置。
9. 前記結果表示画面には、前記カメラ映像の再生位置を示すシークバーが含まれることを特徴とする請求項４乃至８の何れか１項に記載の分析装置。
10. 前記結果表示画面には、さらに、前記分析レポートの表示項目を絞るための条件を指定可能なフィルタ設定領域が含まれることを特徴とする請求項４乃至９の何れか１項に記載の分析装置。
11. 前記フィルタ設定領域では、デバイスの制御サイクルの指定、属性情報の指定、および、イベント、エラーの指定の少なくとも１つによってフィルタが指定可能であることを特徴とする請求項１０に記載の分析装置。
12. 前記ユーザプログラムの編集画面を表示する表示手段をさらに備え、
    前記編集画面では、該編集画面の時間軸に同期した前記分析レポートが表示可能であることを特徴とする請求項１乃至１１の何れか１項に記載の分析装置。
13. 前記分析レポートの生成要求を受け付ける受付手段と、
    前記レポート生成手段によって前記生成要求に応じて前記分析レポートが生成されると、要求元に分析レポートの生成が完了した旨を通知する通知手段と
    をさらに備えることを特徴とする請求項１２に記載の分析装置。
14. 前記分析手段は、前記設定手段によって制御サイクルが定義されていない場合において、制御サイクルのサイクルパターンを有していないデバイスを分析対象として、前記運転記録データを分析することを特徴とする請求項２に記載の分析装置。
15. 前記レポート生成手段は、制御サイクルのサイクルパターンを有していないデバイスの分析結果を分析レポートとして生成し、
    前記分析レポートには、制御サイクルが設定されていない旨と、前記設定手段によって制御サイクルの設定を促すメッセージが含まれることを特徴とする請求項１４に記載の分析装置。
16. データ処理装置とプログラマブルロジックコントローラとが通信可能な分析システムであって、
    ユーザプログラムを繰り返し実行する実行エンジンと、
    前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得手段と、
    取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成手段と、
    取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析手段と、
    前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成手段と
    を備えることを特徴とする分析システム。
17. 前記取得手段、前記モデル生成手段、分析手段、および前記レポート生成手段の少なくとも１つは前記データ処理装置に設けられることを特徴とする請求項１６に記載の分析システム。
18. 前記プログラマブルロジックコントローラは、
    前記実行エンジンを備えるＣＰＵユニットと、
    前記取得手段を実現する前記プログラマブルロジックコントローラに設けられるレコーダユニットと
    を備え、
    前記データ処理装置は、
    前記モデル生成手段、分析手段、および前記レポート生成手段を備えることを特徴とする請求項１６に記載の分析システム。
19. データ処理装置とプログラマブルロジックコントローラとが通信可能なシステムの制御方法であって、
    ユーザプログラムを繰り返し実行する工程と、
    前記ユーザプログラムの実行によって収集される、時系列の複数のデバイス値を含む運転記録データを取得する取得工程と、
    取得された正常時の前記運転記録データの学習に基づきデバイス毎のモデルを生成するモデル生成工程と、
    取得された分析対象の前記運転記録データについて、前記モデルに従って正常条件を満たさない非正常デバイスを分析する分析工程と、
    前記非正常デバイスとして検知した各デバイスの分析結果を、時間軸上で同期させて表示する分析レポートを生成するレポート生成工程と
    を含むことを特徴とするシステムの制御方法。

Images