JP2022158228A - 監視装置およびプログラマブルロジックコントローラシステム - Google Patents

Abstract

【課題】いつもと違う挙動をしたデバイスの情報をユーザに提供すること。【解決手段】監視装置は、ユーザプログラムを実行するＰＬＣにより複数のデバイスから収集された複数のデバイス値の分析結果として、正常条件を満たさない非正常デバイスを示す分析レポートを取得して、表示する。監視装置は、分析レポートに対する選択入力を受け付け、非正常デバイスに関する情報であって、ＰＬＣに保持されている当該デバイスに関する情報をグラフィカルに表示する。【選択図】図９

Description

本発明は監視装置およびプログラマブルロジックコントローラシステムに関する。

プログラマブルロジックコントローラ（ＰＬＣ）はファクトリーオートメーションにおいて製造機器や搬送装置、検査装置などの産業機械を制御するコントローラである。ＰＬＣはプログラマーによって作成されるラダープログラムなどのユーザプログラムを実行することで様々な拡張ユニットや被制御機器を制御する。ＰＬＣの動作を監視するために、ＰＬＣが保持しているデータを収集して、ＰＬＣの外部に接続されたコンピュータ（ＰＣ）やＨＭＩ（ヒューマンインタフェース：表示装置）でデータをモニタすることが提案されている（特許文献１）。

特開２０１９－０１６３２５号公報

ところで、ユーザはプログラム作成支援装置でユーザプログラムを作成し、ＰＬＣに転送する。ＰＬＣはユーザプログラムを実際に実行することで、様々な製品を製造したりする。ここで、ユーザプログラムを作成したときには想定していなかったような稀なイベントが発生することで、製造ラインがストップしてしまうことがある。製造ラインがストップしてしまうことはないものの、注意が必要なイベントが発生することもある。その一方で、ＰＬＣは、所定のイベントが発生すると、その発生時刻の前後において収集されたデバイス値をバッファから読み出して記録する。データ活用ユニットが、この記録を分析して分析レポートを作成し、ＰＬＣの外部にあるＷｅｂブラウザに提供してもよいだろう。ここで、ユーザが、分析レポートから得たい情報としては、いつもと違う挙動をしたデバイス（ユーザプログラムに利用されるデバイス値が格納されるメモリ領域）の情報である。このような非正常なデバイスに関する情報がグラフィカルに表示されば、ユーザは、ユーザプログラムや製造ラインを従来よりも容易に改修できるであろう。そこで、本発明は、いつもと違う挙動をしたデバイスの情報をユーザに提供することを目的とする。

本発明は、たとえば、
ユーザプログラムを実行するプログラマブルロジックコントローラにより複数のデバイスから収集された複数のデバイス値の分析結果として、正常条件を満たさない非正常デバイスを示す分析レポートを取得する取得手段と、
前記分析レポートを表示するレポート表示手段と、
前記分析レポートに対する選択入力を受け付ける受付手段と、
前記選択入力により選択された非正常デバイスを特定する特定手段と、
前記特定された非正常デバイスに関する情報であって、前記プログラマブルロジックコントローラに保持されている当該デバイスに関する情報をグラフィカルに表示するグラフィカル表示手段と、
を有することを特徴とする監視装置を提供する。

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

ＰＬＣシステムを説明する図 ＰＣのハードウエアを説明する図 ＰＬＣのハードウエアを説明する図 ＰＣのＣＰＵにより実現される機能を説明する図 ＰＬＣのＣＰＵにより実現される機能を説明する図 ユーザインタフェースを説明する図 ユーザインタフェースを説明する図 通知ダイアログを説明する図 分析レポートを説明する図 分析レポートを説明する図 ユーザインタフェースを説明する図 分析レポートを説明する図 リレーションマップを説明する図 波形表示のユーザインタフェースを説明する図 波形表示のユーザインタフェースを説明する図 事例を説明する図 ラダープログラムを説明する図 リレーションマップを説明する図 リレーションマップにおける強調表示の変化を説明する図 プロジェクト編集方法を示すフローチャート 分析レポートの表示処理を示すフローチャート

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

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

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

基本ユニット３は、表示部５および操作部６を備えている。表示部５は、基本ユニット３に取り付けられている拡張ユニット４の動作状況などを表示することができる。操作部６に対するユーザによる操作内容に応じて表示部５は表示内容を切り替える。表示部５は、通常、ＰＬＣ１内のデバイスに格納されている現在値（デバイス値）やＰＬＣ１内で生じたエラー情報などを表示する。デバイスとは、デバイス値（デバイスデータ）を格納するために設けられたメモリ上の記憶領域を指す名称（シンボル）であり、デバイスメモリと呼ばれてもよい。デバイス値とは、入力機器からの入力状態、出力機器への出力状態およびユーザプログラム上で設定される内部リレー（補助リレー）、タイマー、カウンタ、データメモリ等の状態を示す情報である。デバイス値の型にはビット型とワード型がある。ビットデバイスは１ビットのデバイス値を記憶する。ワードデバイスは１ワードのデバイス値を記憶する。

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

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

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

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

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

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

ＰＣ２のユーザは記憶装置１２に記憶されているプロジェクト編集プログラム１４ａをＣＰＵ１１に実行させて、操作部８を通じてプロジェクトデータを編集する。つまり、ＰＣ２は、エンジニアリングツールであり、プログラム作成支援装置としても機能する。プロジェクトデータは、一つ以上のユーザープログラム（例：ラダープログラム）と、基本ユニット３や拡張ユニット４の構成情報などを含む。構成情報は、基本ユニット３に対する複数の拡張ユニット４の接続位置や、基本ユニット３に備えられた機能（例：通信機能や位置決め機能）を示す情報、拡張ユニット４の機能（例：撮影機能）などを示す情報、およｂ、デバイスの割り当て情報などである。ここで、プロジェクトデータの編集には、プロジェクトデータの作成および変更（再編集）が含まれる。ユーザは、必要に応じて記憶装置１２に記憶されているプロジェクトデータを読み出し、そのプロジェクトデータを、プロジェクト編集プログラム１４ａを用いて変更する。通信部１３ａは、通信ケーブル９ａを介して基本ユニット３と通信する。ＣＰＵ１１は通信部１３ａを介してプロジェクトデータを基本ユニット３に転送する。通信部１３ａは、ＵＳＢ規格に準拠した通信を実行可能な通信回路などを含む。通信部１３ｂは、通信ケーブル９ｂを介して拡張ユニット４ａと通信する。通信部１３ｂは、ネットワーク通信回路を含む。Ｗｅｂサーバプログラム１４ｃはプロジェクト編集プログラム１４ａの一部として実装される。Ｗｅｂブラウザプログラム１４ｄは、通信部１３ａを介して拡張ユニット４ａがＷｅｂ形式で記述された分析レポートを受信して表示部７に表示する。なお、Ｗｅｂブラウザプログラム１４ｄは、Ｗｅｂサーバプログラム１４ｃに対して、分析レポートを提供するよう要求してもよい。Ｗｅｂサーバプログラム１４ｃは、通信部１３ａおよび基本ユニット３を介して拡張ユニット４ａにアクセスし、分析レポートを取得し、Ｗｅｂブラウザプログラム１４ｄへ転送してもよい。

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

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

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

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

別の観点から補足すると、運転記録は、保存トリガ条件の成立に応じて保存された、デバイス、拡張ユニット４のバッファメモリ、変数など、スキャンタイム毎のデータの総称と呼ばれてもよい。運転記録には、保存トリガ条件の成立に応じて保存された、フレームごとに拡張ユニット（カメラユニット）で取得した映像データが含まれてもよい。また、運転記録には、保存トリガ条件の成立に応じて保存された、エラーやデバイス値変更などのイベント履歴が含まれてもよい。さらに、運転記録には、保存トリガ条件の成立時に実行されていたラダープログラム（プロジェクトデータ）が含まれてもよい。運転記録が生成された際のプロジェクトデータを運転記録に含ませることで、プロジェクトデータに複数のバージョンが存在しても、運転記録を生成したときに実際に使用されていたプロジェクトデータにより状況を再現することができる。運転記録には、分析レポートが含まれてもよい。

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

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

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

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

図４はＰＣ２のＣＰＵ１１によって実現される機能を説明する図である。プロジェクト編集部５０は、ＣＰＵ１１がプロジェクト編集プログラム１４ａを実行することで実現される機能である。プロジェクト編集部５０は、操作部８を通じて入力されるユーザ指示にしたがってユーザプログラムを含むプロジェクトデータを作成する。Ｗｅｂサーバ５１は、ＨＴＴＰ（ハイパーテキストトランスファープロトコル）にしたがってＷｅｂブラウザ６０と通信してＷｅｂブラウザ６０に表示部品を提供する。プロトコル変換部５２は、ＨＴＴＰを所定の通信プロトコルに変換する。所定の通信プロトコルとは、通信部１３ａと通信部３３との間の通信で利用される通信プロトコルである。たとえば、Ｗｅｂブラウザ６０がＨＴＴＰリクエストにより分析レポートを要求すると、Ｗｅｂサーバ５１はＨＴＴＰリクエストをプロトコル変換部５２に渡す。ＨＴＴＰリクエストには、ＣＰＵ４１ａで実行され、分析レポートを提供する拡張ユニット４ａ（Ｗｅｂサーバ）のＵＲＬ（ユニフォームリソースロケータ）が含まれている。プロトコル変換部５２は、ＨＴＴＰリクエストをカプセル化して、所定の通信プロトコルで送信可能な要求信号（コマンド）に変換する。この要求信号は、基本ユニット３のＣＰＵ３１に渡され、さらに、拡張ユニット４ａのＣＰＵ４１ａに渡される。ＣＰＵ４１ａは、ＣＰＵ３１を介してＣＰＵ１１に分析レポートを返信する。ＣＰＵ１１のＷｅｂサーバ５１は、分析レポートをＷｅｂブラウザ６０に渡す。これによりＷｅｂブラウザ６０は表示部７に分析レポートを表示する。

ダウンロード部５３は、運転記録などを基本ユニット３からダウンロードして記憶装置１２に格納する。デバッグ部５４は、ユーザプログラムをデバッグし、表示部７にデバッグ結果を表示する。ラダーモニタ部５６は、ユーザプログラムに記述されているシンボルに格納される値を運転記録から取得して、ユーザプログラム中のシンボルに対してその値を強調表示する。たとえば、ラダープログラムのラダー図に描画されるデバイスに対して、運転記録から取得されたデバイス値を関係づけて表示してもよい。リレーションマップ部５５は、分析レポートにおいて表示される非正常デバイスに関連しているデバイスを示すリレーションマップを作成して表示部７に表示する。非正常デバイスとは、そのデバイス値が正常条件を満たしていないか、または、そのデバイス値の変化するタイミングが正常条件を満たしていないデバイスである。リレーションマップは、たとえば、非正常デバイスに対して影響を与えるデバイス（入力デバイス）と非正常デバイスとの関係を視覚的に示すＵＩである。リレーションマップは、非正常デバイスから影響を受けるデバイス（出力デバイス）と非正常デバイスとの関係も表示してもよい。デバッグ部５４は、非正常デバイスとその関連デバイスとをラダープログラムを分析することで取得し、リレーションマップを作成する。

受付部５７は、ユーザプログラムに対する編集操作およびデバッグ処理に対する操作などを受け付ける。通知処理部５８は、ＰＬＣ１において通知が発行されているかどうかをポーリングにより取得し、取得した通知を表示部７に表示する。通知としては、たとえば、分析レポートの作成が完了したことなどである。再生部５９は、たとえば、受付部５７または連携部６４から入力される再生要求に応じて、ダウンロード部５３に運転記録をダウンロードさせて記憶装置１２に保存させる。再生要求には、たとえば、運転記録を特定可能な識別情報（例：固有の識別情報やＰＬＣ１における保存パス名）などが含まれていてもよい。再生部５９は、記憶装置１２に保存されている運転記録を再生して表示部７に表示する。再生部５９は、デバック部５４の代わりに、ラダーモニタ部５６を有していてもよい。あるいは、再生部５９がデバック部５４に含まれていてもよい。再生部５９は、ＰＬＣ１からリアルタイムで取得される時系列のデバイス値を波形化して表示したり、運転記録に含まれる時系列のデバイス値を波形化して表示したりしてもよい。

Ｗｅｂブラウザ６０は、Ｗｅｂアプリケーション６１を実行することで分析レポートを表示部７に表示してもよい。Ｗｅｂアプリケーション６１は、たとば、ＨＴＭＬデータ、ＣＳＳデータおよびｊａｖａ（Ｒ）スクリプトなどにより構成される。Ｗｅｂアプリケーション６１は、拡張ユニット４ａから提供されてもよい。通信処理部６２は、Ｗｅｂサーバ５１との通信を処理する。データ取得部６３は、分析レポートに表示すべき運転記録をプロジェクト編集部５０から取得する。運転記録は、ダウンロード部５３によって記憶装置１２にすでに保存されているものとする。連携部６４は、分析レポートにおいてユーザにより指定または選択されたデバイスなどを示す指定情報をデバッグ部５４などに渡す。これにより、デバッグ部５４は、分析レポートにおいて指定された非正常デバイスのリレーションマップを表示したり、ラダープログラムにおいて非正常デバイスが記述されている部分を表示したりすることができる。ユーザは、非正常デバイスに関してラダープログラムを容易に編集することができる。描画部６５は分析レポートを表示部７に表示する。また、連携部６４は、分析レポートにおける再生時刻（選択時刻）と、プロジェクト編集部５０における運転記録の再生時刻とが同期するように時刻管理を実行する。

図５はＰＬＣ１においてＣＰＵ３１とＣＰＵ４１ａとが制御プログラムを実行することで実現する機能を示している。ＣＰＵ３１においてコマンド処理部７１は、ＰＣ２から受信されるコマンドを解釈し、解釈結果に対応した処理を実行する。たとえば、ＨＴＴＰリクエストをカプセル化して作成された要求信号が受信されると、コマンド処理部７１は、要求信号をＣＰＵ４１ａに転送する。要求信号に対する応答信号がＣＰＵ４１ａから受信されると、コマンド処理部７１は、応答信号をＰＣ２へ転送する。収集部７２は、基本ユニット３や拡張ユニット４ｂからシンボル値（デバイス値や変数に格納された値）を収集してリングバッファ３６に格納する。ロギング部７３は、収集されたシンボル値などに基づき、何らかのエラーまたはトラブル（非正常イベント）がＰＬＣ１において生じているかどうかを判定する。たとえば、ロギング部７３は、収集されたシンボル値が記録条件を満たしているかどうかを判定してもよい。収集されたシンボル値が記録条件を満たしている場合に、ロギング部７３は、当該シンボル値を運転記録７４内の稼働ログ７６として保存する。たとえば、ロギング部７３は、運転記録７４を格納するためのフォルダを作成し、そこに稼働ログ７６を保存する。ロギング部７３は、運転記録を作成したときに実行されていたプロジェクトデータ７５をプロジェクト記憶部３５から読み出して、運転記録７４内に保存する。さらに、ロギング部７３は、運転記録７４を作成したことを分析部８３に通知する。

なお、ＣＰＵ３１またはＣＰＵ４１ａは、オペレータの入力に従って後述される学習モデルの生成や、分析、分析レポートの生成に利用する制御サイクルを設定するための設定部を有していてもよい。制御サイクルは、サイクルの基準となるタイミングを指定することで設定される。制御サイクルの設定はサイクル設定と呼ばれてもよい。たとえば、サイクル設定は、サイクルの開始タイミングを規定するシンボル名と、シンボル値の立上り／立下りのエッジ情報とを含む。サイクル設定は、サイクルの開始タイミングを規定するシンボル名と、シンボル値の立上り／立下りのエッジ情報とによるサイクルの開始タイミングの設定情報と、サイクルの終了タイミングを規定するシンボル名と、シンボル値の立上り／立下りのエッジ情報とによるサイクルの終了タイミングの設定情報を含んでいてもよい。設定部による制御サイクルの設定はＣＳＶ等のファイル形式でＰＬＣ１に提供され、設定部がＣＳＶ等のファイルを読み出して制御サイクルを設定してもよい。たとえば、設定部によって設定された制御サイクルは、当該サイクルに同期するデバイスを分類して当該分類情報を属性情報としてモデルへ付加したり、分析対象とするデバイスを制御サイクルによって絞ったり、制御サイクルに同期して表示される分析レポートを生成したりするために用いられる。設定される制御サイクルは複数であってもよい。また、制御サイクルは必ずしも設定される必要はない。たとえば、正常時におけるシンボル値の取り得る値が予め決まっている場合、シンボル値がその予め決まっている取り得る値か否かを判定することで、非正常シンボルかどうかが判定されてもおい。

ＣＰＵ４１ａにおいてプロトコル変換部８１は、ＰＣ２からＣＰＵ３１を介してカプセル化されて転送されてきたＨＴＴＰリクエストをプロトコル変換して要求信号からとりだす。プロトコル変換部８１は、ＨＴＴＰリクエストに対してＷｅｂサーバ８２から送信される応答情報をカプセル化してＣＰＵ３１に渡す。以下においてもＰＣ２のＷｅｂブラウザ６０と、拡張ユニット４ａのＷｅｂサーバ８２とは、ＰＣ２内のＷｅｂサーバ５１やプロトコル変換部５２、８１、コマンド処理部７１などを介して間接的に通信することができる。プロトコル変換部５２、８１は透過的なトンネル（例：ＴＣＰトンネル）を提供してもよい。Ｗｅｂサーバ８２は、分析部８３により作成された分析レポートをＰＣ２へ提供する。分析部８３は、運転記録７４内の稼働ログ７６を分析し、分析結果７７を作成して、ロギング部７３に渡す。分析部８３が分析結果７７を作成すると、ロギング部７３は、プロジェクトデータ７５および稼働ログ７６に加えて、分析結果７７を含む運転記録７４に追加する。運転記録７４は、運転記録記憶部３７に格納される。このように、運転記録７４は、ＰＬＣ１において異常なイベントが発生したときのプロジェクトデータ７５、稼働ログ７６および分析結果７７が関連付けて記憶されるため、異常なイベントが発生したときのＰＬＣ１の状態を正確に再現しやすくなる。たとえば、ラダー図上でデバイス値の変化を視覚的に再現することで、ユーザは、ラダープログラムをデバッグしやすくなるであろう。とりわけ、ＰＣ２に保存されているプロジェクトデータを用いると、異常なイベントが発生したときのＰＬＣ１の状態を正確に再現することが困難となることがある。ＰＣ２に保存されているプロジェクトデータと、異常なイベントが発生したときにＰＬＣ１で実行されていたプロジェクトデータ７５が一致しないことがあるからである。そこで、異常なイベントが発生したときにＰＬＣ１で実行されていたプロジェクトデータ７５が運転記録７４に保存される。通知発行部８４は、分析結果７７が発行されると、通知を発行する。この通知は、ＣＰＵ１１に送信される。

＜ユーザインタフェース（ＵＩ）＞
図６および図７は表示部７に表示されるプロジェクト編集プログラム１４ａのＵＩ１００を示している（プロジェクト編集プログラム１４ａを実行することによりＵＩ１００が表示部７に表示される）。モード選択メニュー１０１は、プロジェクト編集プログラム１４ａが備える複数のモードを選択可能に表示する。複数のモードは、編集モード、モニタモード、リプレイモード（デバッグモード）などを含む。図６に示された編集モードは、プログラム表示領域１０４に表示されるラダープログラムを編集するモードである。プロジェクト表示領域１０２は、プロジェクトを構成する情報を表示する。この情報としては、ＰＬＣ１を構成している基本ユニット３および拡張ユニット４の仕様情報および設定情報、デバイスの割り当て情報、運転記録の設定情報、ラダープログラムなどがある。編集モードにおいて、プログラム表示領域１０４は、プロジェクト表示領域１０２において指定されたラダープログラムを編集可能に表示する。図６においては、入力部、出力部および加工部状態と命名されたプログラムモジュールを有するラダープログラムが表示されている。とりわけ、複数のプログラムモジュールはタブ１０７によって選択可能であり、図６では、入力部に対応するタブ１０７が選択されている。

モニタモードは、ＰＬＣ１により発行される通知を待ち受けるモードである。拡張ユニット４ａが分析結果を作成したことを示す通知を発行すると、ＣＰＵ１１は、通知を表示するためのダイアログなどを表示部７に表示する。モニタモードのユーザインタフェースは、基本的に、編集モードと同様である。

図８は通知ダイアログ１０８を示している。通知ダイアログ１０８は、通知を発行したアプリケーションまたは機能の名称、通知の内容、通知の発生件数、通知の発生日時などを表示する。通知ダイアログ１０８を表示するための通知情報には、分析レポートのＵＲＬが含まれている。表示ボタン１０９が押し下げられると、ＣＰＵ１１は、分析レポートのＵＲＬをＷｅｂブラウザ６０に渡す。これにより、Ｗｅｂブラウザ６０は、ＵＲＬで指定されたＷｅｂサーバにアクセスして、分析レポートの表示データ（Ｗｅｂアプリケーション６１）を取得して、分析レポートを表示する。

図７が示すように、リプレイモードは、運転記録をラダープログラム上で再現したり、運転記録を波形として表示したりするモードである。ポインタ１０３は、操作部８に対するユーザ操作に連動して移動し、ボタンなどを押し下げするために使用されたり、オブジェクトを選択したりするために使用される。たとえば、プロジェクト表示領域１０２において表示された分析レポートがポインタ１０３によりダブルクリックされると、ＣＰＵ１１はＷｅｂブラウザ６０に分析レポートを表示させる。

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

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

［分析レポート］
図９はＷｅｂブラウザ６０がＷｅｂアプリケーション６１を実行することで表示部７に表示される分析レポート１１０を示す。なお、分析レポート１１０は、プロジェクト編集プログラム１４ａのＵＩ１００と一緒に表示部７に表示される。つまり、ＵＩ１００のウインドウと、分析レポート１１０のウインドウとは異なるウインドウとして表示される。ただし、ＵＩ１００と分析レポート１１０とが単一のウインドウ内に表示されてもよい。また、分析レポート１１０は、表示部７に表示されてもよいし、プログラマブル表示器、タブレット、スマートフォンなどの他の表示装置に表示されてもよい。

検知マップ１１１は、ＰＬＣ１において実行される複数の工程のそれぞれについて開始タイミングと終了タイミングとを表示する。一般に、開始タイミングから終了タイミングまでの期間はサイクルと呼ばれる。図９において、横方向に延びる矩形は、工程が実行中である期間（サイクル）を示している。この矩形は、左が古く、右が新しいことを示す。時刻バー１１２ａは、運転記録データの保存トリガが発生したタイミングを示している。上述したように、運転記録データは、保存トリガが発生したタイミング以前に収集されたデータとこのタイミングより後に収集されたデータとを保持している。そのため、時刻バー１１２ａの前後にデータが示されている。一方で、時刻バー１１２ｅは、選択中の時刻を示しており、ユーザが時刻バーをドラッグ操作所望の時刻（左右）に移動できるようになっている。ドラッグアンドドロップではなく、ユーザが検知マップの所望位置をクリックすると、その所望位置に時刻バー１１２ｅがジャンプするようにしても構わない。このようにして、ユーザは、時刻バー１１２ｅを操作することにより、分析結果の表示を更新することができる。時刻バー１１２ｅの操作に従って、後述する、検知リスト１１４、画像表示領域１１３、および、分析コメント１１６の少なくとも１つまたは全部を連動して更新させ（時刻同期させ）、対応する分析結果が表示されてもよい。なお、時刻バー１１２ａ、１１２ｅは、それぞれ異なる色で描画されてもよいし、実線と破線とで描画されたりしてもよい。これにより、時刻バー１１２ａ、１１２ｅの識別力が向上する。

ここで、検知マップ１１１の工程１の中に丸印が２つ記載されているが、これは、検知対象デバイスがいつもと異なる状態になったタイミングを示している。左側の丸印は、デバイスＲ００１とＭＲ００１がいつもと異なる状態になったタイミング（いずれも１４：５０：４５）を示す。右側の丸印は、デバイスＲ００４がいつもと異なる状態になったタイミング（１４：５９：０１）を示す。図９は、検知リスト１１４においてユーザがＲ００４のデバイス欄を選択した状態を示しており、検知マップ１１１の時刻バー１１２ｅは右側の丸印と重なる位置に表示されている。

検知マップ１１１の時刻バー１１２ｅの表示位置は、検知リスト１１４におけるユーザのデバイス選択に連動している。図９に示す状態において、ＭＲ００１のデバイス欄が選択（クリック）されると、図１０が示すように、ＭＲ００１が強調表示されるとともに、検知マップ１１１の時刻バー１１２ｅが２つの丸印のうち左側の丸印と重なる位置に移動する（Ｒ００１のデバイス欄を選択したときも同様である）。また、時刻バー１１２ｅの移動に応じて、検知リストの時刻バー１１２ｆも１つ上に移動（連動）する。

いつもと異なる状態とは、たとえば、デバイス値が正常範囲を逸脱したり、デバイス値が変化するタイミングまたは回数が正常範囲を外れたりすることである。製品の製造工場では、日々、同一の製品が大量生産される。つまり、同一の工程が何度も繰り返し実行される。そのため、いつもと異なる状態を検知して表示することは、ラダープログラムを改良したり、生産設備を見直したりするうえで、非常に役に立つ。いつもと同様の状態（正常状態）を定義する正常範囲（正常条件）は、マスターデータにより定義されてもよいし、デバイス値の学習結果により定義されてもよい。検知マップ１１１において、工程を示す矩形は、時間の経過にしたがって右から左に移動する（上述したように、時刻は、左が古く、右が新しい）。

画像表示領域１１３は、ＰＬＣ１において取得されたカメラ画像を表示する。カメラ画像も運転記録に含まれていてもよい。図９では、マスターデータのカメラ画像と、今回のカメラ画像とが対比可能に表示されている。カメラ画像も時系列データであるため、シークバー１０５ｂは、カメラ画像の再生時刻を示し、再生時刻の経過にしたがって左から右に移動する。時刻バー１１２ｂは、選択中の時刻を示しており、図９では、検知対象デバイスＲ００４がいつもと異なる状態になったタイミングを示している。時刻指定部１０６ｂは、カメラ画像の再生時刻を進めたり、再生時刻を戻したり、再生の開始を指示したり、再生を停止したりすることを指示するためのコントロールオブジェクトである。なお、連携部６４および再生部５９は、検知マップ１１１の再生時刻、カメラ画像の再生時刻、および、ＵＩ１００における再生時刻が同期するように管理している。これにより、ＵＩ１００における再生時刻と、分析レポート１１０における再生時刻とが一致する。

検知リスト１１４は、いつもと異なる状態になったデバイスと、その状態が発生した時刻（デバイス値の収集時刻）とを示す。ＣＰＵ１１は、検知リスト１１４に表示されたデバイスに対するクリックを検知すると、プロジェクト編集部５０の動作モードをリプレイモードへ切り替えてもよい。ＣＰＵ１１は、クリックされたデバイスの識別情報と、再生時刻情報（デバイス値の収集時刻）と、分析対象となった運転記録を特定する情報（保存パス等）をデバッグ部５４に渡す。これにより、分析対象となった運転記録を用いてリプレイモードに移行し、その際に分析レポート１１０の再生時刻と、プロジェクト編集部５０の再生時刻情報が同期する。その結果、図７が示すように、運転記録７４がラダープログラムと関連して再生される。なお、図７は、図９の検知リスト１１４においてデバイスＲ００４が選択された状態で、ＵＩ１００のリプレイモードを起動したときの表示画面に相当する。図７のシークバー１０５ａは、デバイスＲ００４がいつもと異なる状態になった時刻（１４：５９：０１）を示している。また、プログラム表示領域１０４では、この時刻（１４：５９：０１）における各デバイスの状態が視覚的に区別可能に表示される。なお、分析レポート１１０が表示される前に、すでにプロジェクト編集部５０がリプレイモードで動作していてもよい。この場合、分析レポート１１０において、非正常デバイスが選択されると、ＣＰＵ１１は、非正常状態（いつもと異なるイベント）が発生した時刻をプロジェクト編集部５０に渡し、プロジェクト編集部５０は、当該時刻に同期したデバイス値を記憶装置１２から読み出して、ラダープログラム上でデバイス値を表示してもよい。

図９において、時刻バー１１２ｃは、運転記録データの保存トリガが発生したタイミング（１４：５９：０６）を示している。また、時刻バー１１２ｆは、上述したように、検知マップ１１１の時刻バー１１２ｅが示す時刻と連動している。たとえば、時刻バー１１２ｅを左側の丸印よりも左方に移動させると、検知リスト１１４において時刻バー１１２ｆはＲ００１のデバイス欄の上端線と重なる位置に移動する。

ここで、図１０および図１１は、分析レポート１１０（図９）とプロジェクト編集プログラム１４ａのＵＩ１００（図７）とが連動する様子を説明するための説明図である。上述したように、図７は、図９の検知リスト１１４においてデバイスＲ００４が選択された状態で、ＵＩ１００のリプレイモードを起動したときの表示画面に相当する。

図１０が示すように、ユーザが検知リスト１１４の中でＭＲ００１を選択（クリック）すると、検知マップ１１１において時刻バー１１２ｅが連動して移動する。時刻バー１１２ｅの移動に伴って、時刻バー１１２ｆも１つ上に移動する。また、時刻バー１１２ｅの移動に伴って、画像表示領域１１３における時刻バー１１２ｂも左へ移動（連動表示）する。さらに、後述する分析コメント１１６も、ＭＲ００１の選択に伴って表示が切り替わる。詳細は後述する。

一方、図１１が示すように、時刻バー１０５ａは、図７よりも少し左（時間的に前）に移動する。このとき、時刻バー１０５ａは、デバイスＭＲ００１がいつもと異なる状態になった時刻（１４：５０：４５）を示すようになる。このように、連携部６４によって、分析レポート１１０の時刻バー１１２ｅや時刻バー１１２ｆによって特定される時刻と、運転記録の再生時刻（時刻バー１０５ａによって特定される時刻）とは、同期して表示されることになる。

なお、図１０および図１１では、予めプロジェクト編集プログラム１４ａのＵＩ１００を起動した状態での連動表示について説明されているが、たとえば、先に分析レポート１１０の検知リスト１１４においてＭＲ００１のデバイス欄を選択した状態で、ＵＩ１００を起動した場合には、図１０および図１１に示す変化後の状態でＵＩ１００が起動される。

また、図１０では、ユーザは検知リスト１１４の中からデバイスを１つ選択しているが、複数のデバイスが選択されてもよい。この場合、最上位のデバイス（時間的に一番古いデバイス）を選択したときと同様の処理が行われる。すなわち、たとえばＭＲ００１とＲ００４の両方を選択した状態で、ＵＩ１００のリプレイモードが起動されると、図１１に示す変化後の状態でＵＩ１００が起動される。本明細書でいう時刻の同期再生には、時刻バー１１２ｆによって特定される時刻インデックスと、運転記録の再生時刻インデックスとの同期再生を含む概念である。つまり、時刻そのものでなくても、時刻を表すインデックス同士を同期再生しても構わない。

図１２が示すように、ＣＰＵ１１は、非正常デバイスの名称と、そのデバイスコメント１１５をプロジェクトデータから読み出して検知リスト１１４に表示してもよい。デバイスコメント１１５はデバイスの用途などを示す。よって、ユーザは、非正常デバイスの用途などを容易に理解できるであろう。

分析コメント１１６は、分析結果に含まれるコメントと、検知リスト１１４で選択されたデバイスについての、マスターデータと、今回のデバイス値の時系列データとを表示する。分析コメント１１６に表示されるデータは、１制御サイクル分のデータである。時刻バー１１２ｄは、いつもと異なる状態が発生したタイミングを示す。

図９および図１２では、デバイスＲ００４のデバイスについて、いつもと異なる状態が発生した１制御サイクル分のデータを示している。より具体的には、マスターデータでは、１制御サイクルにおいて、オフ→オン、オン→オフという２回の変化が発生するのに対し、今回のデータでは、変化が全く発生していない。そこで、いつもと異なる状態、すなわち、オフ→オンとなったタイミングに、時刻バー１１２ｄが表示されている。

ここで、図９および図１２が示す分析コメント１１６において、ユーザが検知リスト１１４の中でＭＲ００１を選択（クリック）すると、図１０に示される表示に切り替わる。図１０では、ＭＲ００１のデバイスにおいて、いつもと異なる状態が発生した様子を示している。なお、本実施形態では、時刻バー１１２ｅ、１１２ｂ、１１２ｆの各々は、いずれも同一のタイミングを示している。

図１２が示すように、分析レポート１１０は、リレーションマップの表示を指示するボタン１１７ａと、波形の表示を指示するボタン１１７ｂとを有していてもよい。以下で、リレーションマップと波形の表示が詳細に説明される。

［リレーションマップ］
図１３はリレーションマップ１２０を示している。リレーションマップ１２０は、いつもと異なる状態になったデバイス（非正常デバイス）に対してラダープログラムにおいて関連している他のデバイスを表示するＵＩである。これにより、ユーザは、非正常デバイスと他のデバイスとの関係を容易に理解できる。一般に、ＰＬＣ１において利用されるデバイスの数は数百から数万であるため、ユーザは、いつもと異なる状態になったデバイスから、その原因となったデバイスを特定することは容易ではない。ＣＰＵ１１は、非正常デバイスについてラダープログラム内を検索し、非正常デバイスに関する記述を発見し、当該記述を分析することで、関連デバイスを特定する。この例では、ラダープログラム内の出力部において、非正常デバイス（例：Ｒ００４）が記述されており、関連デバイスとしてＭＲ０００、ＭＲ００１、ＭＲ００２が存在する。ＣＰＵ１１は、ラダープログラムから特定した非正常デバイス、関連デバイスおよびプログラムモジュールをツリーのように表示する。この例では、出力部における演算のために入力されるデバイスが左側に表示され、プログラムモジュールが真ん中に表示され、その右側に非正常デバイスが表示されている。図１３が示すように、ポインタ１０３によりプログラムモジュールがダブルクリックされると、ＣＰＵ１１は、その情報をプロジェクト編集部５０に渡し、該当するプログラムモジュールをプログラム表示領域１０４に表示してもよい。分析レポートは、全デバイスを対象として作成されてもよいし、一部のデバイスに限定して差作成されてもよい。一部のデバイスに限定することで、分析時間が短縮されるであろう。分析精度次第では、分析結果にノイズが多くなることが予想されるが、一部のデバイスに限定することにより、ノイズが削減されるであろう。このような一部のデバイスを対象とした分析レポートの場合、異常の要因となったデバイスは、いつもと違うと判分析されたデバイス、または、分析対象外のデバイスのいずれかに存在する。そのため、リレーションマッピングにおいて、分析対象外になったデバイスが強調表示されてもよい。

［波形表示］
図１４はＣＰＵ１１が波形表示プログラム１４ｂを実行することで表示部７に表示する波形ＵＩ１３０を示している。デバイスリスト１３１は、表示対象となるデバイスのリストを示す。たとえば、ＣＰＵ１１は、検知リスト１１４においてユーザにより選択または指定されたデバイスの名称をデバイスリスト１３１に列挙する。図１４は、図９において、Ｒ００１、ＭＲ００１及びＲ００４を選択した状態で、波形ＵＩ１３０を起動したときの様子を示している。なお、工程の制御サイクル（開始から終了まで）を示すリレーデバイスＭＲ０００は、ユーザの指定がなくても、ＣＰＵ１１によりデバイスリスト１３１に列挙される。すなわち、ＭＲ０００は、上述したサイクル設定により規定されるデバイスであり、ユーザによる指定の有無に拘わらず、波形ＵＩ１３０に自動的に表示される。なお、波形ＵＩ１３０に表示されるデバイス波形を構成するデバイス値の数は、ユーザ設定により予め指定されてもよい。たとえば、分析レポート１１０の検知リスト１１４で選択されたデバイス欄に対応する時刻を基準として（基準の前、基準の後ろ、基準の前後で）所定数のデバイス値が表示されてもよい。他の例としては、波形ＵＩ１３０に表示されるデバイス波形を構成するデバイス値として、運転記録に含まれるデバイス値の全てが表示されるように、波形が縮小表示されてもよい。この場合、拡大表示していくことで、上述した基準となる時刻近傍のデバイス波形を、より明確に視認することができる。

波形表示領域１３２は、選択されたデバイスについてのデバイス値の波形を示す。ＣＰＵ１１は、デバイス値の時系列データを運転記録から読み出して、波形表示領域１３２に表示する。ＣＰＵ１１は、波形に対しても時刻バー１１２ｇを表示してもよい。これにより、ユーザは、波形のどの部分でいつもと異なるイベントが発生したかを把握しやすくなろう。時刻バー１１２ｇが示す時刻は、時刻バー１１２ｅ、１１２ｂ、１１２ｆが示す時刻と一致している。これは、連携部６４が、分析レポート１１０における再生時刻とイベント発生時刻と、再生部５９におけるそれらとが一致するように時刻管理しているからである。

ここで、図１５は、図１４において一点鎖線の領域を拡大した拡大図である。図１５において、デバイスＭＲ００１とＲ００４について破線の波形が示されているが、これは、説明の便宜上記載したものであり、実際の表示画面上には表れない。図１５では、連携部６４によって、分析レポート１１０の検知リスト１１４における選択デバイスによって特定される時刻と、波形ＵＩ１３０の時刻バー１１２ｇとが同期して再生されることを説明する。図１５は、図１４において一点鎖線の領域を拡大した拡大図である。

図１４および図１５は、上から順に、ＭＲ０００、Ｒ００１、ＭＲ００１、Ｒ００４のデバイス波形が示されている。ＭＲ０００は、上述したように制御サイクルを示すデバイスであり、オフ→オンから始まり、オン→オフを経て再びオフ→オンするまでの期間が１制御サイクルに相当する。図１４において、本来であれば、Ｒ００１は常時ＯＦＦしているはずのデバイスである。しかし、何らの異常により、制御サイクルが始まるタイミング（ＭＲ０００がオンするタイミング）で、Ｒ００１がオンしている（異常が発生している）。その結果、図７が示すＲ０００（図１４には図示されていない）がオンしても、ＭＲ００１はオンしない（図１４では、この様子を点線で示す）。さらに、ＭＲ００１がオンしないことによって、図１３が示す出力部のＲ００４もオンしない（図１４では、この様子を点線で示す）。

図１４は、図９の検知リスト１１４においてデバイスＲ００１が選択された状態で波形ＵＩ１３０を起動したときの様子を示す。つまり、Ｒ００１がいつもと違う状態になった時刻に、時刻バー１１２ｇが表示されている。この状態で、図９の検知リスト１１４においてデバイスＭＲ００１が選択されると、時刻バー１１２ｇは、ＭＲ００１がいつもと違う状態になった時刻に表示される（図１５の時刻バー１１２ｇａ参照）。他にも、図９の検知リスト１１４においてデバイスＲ００４が選択されると、時刻バー１１２ｇは、Ｒ００４がいつもと違う状態になった時刻に表示される（図１５の時刻バー１１２ｇｂ参照）。このように、連携部６４により、分析レポート１１０の検知リスト１１４における選択デバイスによって特定される時刻と、波形ＵＩ１３０上の時刻バー１１２ｇが示す時刻とは、同期指定して再生されることになる。

なお、図１５は、予め波形ＵＩ１３０を起動した状態での連動表示について説明しているが、たとえば、先に検知リスト１１４の選択デバイスを変更（たとえばＲ００１からＭＲ００１またはＲ００４に変更）した状態で、波形ＵＩ１３０が起動されてもよい。この場合には、図１５が示す変化後の状態で波形ＵＩ１３０が起動される。また、図１５では、ユーザは検知リスト１１４の中からデバイスを１つ選択しているが、複数のデバイスを選択してもよい。この場合、最上位のデバイス（時間的に一番古いデバイス）を選択したときと同様の処理が行われる。すなわち、たとえばＭＲ００１とＲ００４の両方を選択した状態で波形ＵＩ１３０が起動されると、時刻バー１１２ｇは、図１５が示す時刻バー１１２ｇａの位置に表示（連動表示）される。

図１４では、いずれのデバイスもリレーデバイスであるが、ワードデバイスが選択されてもよい。ＣＰＵ１１は、ワードデバイスのデバイス値を波形化して波形表示領域１３２に表示してもよい。

図１４では、運転記録７４に含まれるデバイス値が表示されているが、これと重ねてマスターデータが表示されてもよい。マスターデータは、いつもと同じデバイス値の時系列データである。そのため、これらを重ねて表示することで、どの時点で、いつもと異なるイベントが発生したかをユーザは理解しやすくなるであろう。

［事例］
図１６はＰＬＣ１により制御されるフィールドデバイス１０の一例を示している。この例では、ベルトコンベヤ１４０ａによりワークＷ１が搬送される。センサ１４１ａは、ワークＷ１が所定位置に到着したことを検知する。ベルトコンベヤ１４０ｂによりワークＷ２が搬送される。センサ１４１ｂは、ワークＷ２が所定位置に到着したことを検知する。ロボット１４３は、ワークＷ１とワークＷ２とを作業台１４２上で組み立ててワークＷ３を製造し、ワークＷ３をベルトコンベヤ１４０ｃに積載する。

図１７は図１６に示された事例を実現するラダープログラムを示している。プログラムモジュール１５０ａは入力部を示している。入力デバイスＲ０００はセンサ１４１ａの検知結果を示すリレーデバイスである。センサ１４１ａがワークＷ１を検知している場合、入力デバイスＲ０００がオンになる。センサ１４１ａがワークＷ１を検知していない場合、入力デバイスＲ０００がオフになる。入力デバイスＲ００１は、ロボット１４３がワークＷ１を受け入れ可能である場合に、オフとなる。入力デバイスＲ００１は、ロボット１４３がワークＷ１を受け入れ可能でない場合に、オンとなる。ＭＲ００１は、ワークＷ１の準備が完了したことを示すリレーデバイスである。プログラムモジュール１５０ａの１行目によれば、入力デバイスＲ０００がオンで、かつ、入力デバイスＲ００１がオンでない場合に、ＭＲ００１がオンになる。

入力デバイスＲ００２はセンサ１４１ｂの検知結果を示すリレーデバイスである。センサ１４１ｂがワークＷ２を検知している場合、入力デバイスＲ００２がオンになる。センサ１４１ｂがワークＷ２を検知していない場合、入力デバイスＲ００２がオフになる。入力デバイスＲ００３は、ロボット１４３がワークＷ２を受け入れ可能である場合に、オフとなる。入力デバイスＲ００３は、ロボット１４３がワークＷ１を受け入れ可能でない場合に、オンとなる。ＭＲ００２は、ワークＷ２の準備が完了したことを示すリレーデバイスである。プログラムモジュール１５０ａの２行目によれば、入力デバイスＲ００２がオンで、かつ、入力デバイスＲ００３がオンでない場合に、ＭＲ００２がオンになる。

プログラムモジュール１５０ｂは出力部を示している。ＭＲ０００は製造ラインが稼働中であることを示すリレーデバイスである。ＭＲ０００がオンで、かつ、ＭＲ００１がオンで、かつ、ＭＲ００２がオンである場合に、リレーデバイスＲ００４がオンになる。リレーデバイスＲ００４は加工開始信号と呼ばれ、ロボット１４３に加工開始（組み立て開始）を指示する。

プログラムモジュール１５０ｃは加工部状態を示している。ＤＭ０はデータメモリと呼ばれるデバイスであり、ワークＷ１に関して０（受け入れ可能）、１（ワークが異常）、２（ワークが詰まっている）、３（材料不足）などを示す。プログラムモジュール１５０ｃの１行目によれば、ＤＭ０が０以外である場合に、Ｒ００１がオンにセットされる。ＤＭ１もデータメモリと呼ばれるデバイスであり、ワークＷ２に関して０（受け入れ可能）、１（ワークが異常）、２（ワークが詰まっている）、３（材料不足）などを示す。プログラムモジュール１５０ｃの２行目によれば、ＤＭ１が０以外である場合に、Ｒ００３がオンにセットされる。

デバッグの一例として、ワークＷ１に異常が発生し、ロボット１４３が加工を開始しなかった例を取り上げる。まず、デバッグを開始した時点では、完成品であるワークＷ３が排出されないというエラーイベントが生じているものと仮定されている。ユーザは、なぜ、ワークＷ３が排出されなかったのか、その原因を探ろうとする。

ユーザは、プロジェクト編集プログラム１４ａを起動し、モニタモードを選択する。ＣＰＵ１１は、通知をＰＬＣ１から受信して、通知ダイアログ１０８を表示する。ＣＰＵ１１は、ユーザにより表示ボタン１０９が押し下げられたことを検知し、分析レポートをＰＬＣ１から取得して表示部７に表示する。

図１２が示すように、分析レポートの検知リスト１１４と分析コメント１１６によれば、加工開始信号であるＲ００４がオンにならなかったために、ワークＷ１，Ｗ２の加工が実行されず、ワークＷ３が排出されなかったことがわかる。Ｒ００１がオンしていることから、ワークＷ１の準備が完了しなかったことがわかるが、ワークＷ１の準備が完了しなかった原因まではわからない。

ＣＰＵ１１は、図９の分析レポート１１０の検知リスト１１４において、ＭＲ００１、Ｒ００１およびＲ００４が選択され、かつ、ボタン１１７ｂが押し下げられたことを検知すると、図１４に示された波形ＵＩ１３０を表示部７に表示する。ＭＲ０００は一つの加工サイクルを示すリレーである。つまり、ＭＲ０００がオンになっている期間において、一つのワークＷ３が製造される。

検知リスト１１４において複数のデバイスが選択された場合、上述したように、ＣＰＵ１１は、検知リストにおいて最も上に表示されているデバイス（先頭デバイス）がいつもと違った状態になった時刻を特定し、特定された時刻に時刻バー１１２ｇを表示する。この例では、Ｒ００１が先頭デバイスであるため、Ｒ００１がいつもと違う状態になったタイミングに時刻バー１１２ｇが設定される。この例によれば、Ｒ００１が正常状態ではオフとなるタイミングでオンとなってしまっていることがわかる。また、正常状態ではオンになるべきＭＲ００１とＲ００４がオフになっていることも視覚的に容易にわかる。図１４では、６サイクルに相当する波形が示されているが、ＣＰＵ１１は、時刻バー１１２ｇが示す時刻を含む１サイクルに相当する波形のみを切り出して拡大表示してもよい。

次に、ユーザは、Ｒ００４がいつもと異なる状態になった原因を探る。図１２において、Ｒ００４が選択され、かつ、ボタン１１７ａが押し下げられたことを検知すると、ＣＰＵ１１は、リレーションマップ１２０を表示部７に表示する。ＣＰＵ１１は、Ｒ００４の記述を含む行をラダープログラムから抽出し、リレーションマップ１２０を作成する。リレーションマップ１２０は、分析レポート１１０やプロジェクト編集プログラム１４ａのＵＩ１００とは異なるウインドウに表示されてもよい。図１３が示すように、リレーションマップ１２０には、出力部（プログラムモジュール１５０ｂ）の１行目において、Ｒ００４に対してＭＲ０００、ＭＲ００１、ＭＲ００２が関連していることが示される。ＣＰＵ１１は、いつもと異なる状態になったデバイスとプログラムモジュールの行番号とを強調表示してもよい。また、リレーションマップ１２０において出力部のブロックがクリックされると、ＣＰＵ１１は、プログラム表示領域１０４に、プログラムモジュール１５０ｂを表示する。ＣＰＵ１１は、プログラムモジュール１５０ｂにおける各デバイスに、いつもと異なる状態になったタイミングで収集されたデバイス値を反映させる。図１３では、ＭＲ００１がオフであり、その結果、Ｒ００４がオフになったことが判明する。プログラムモジュール１５０ｂは、リレーションマップ１２０とともに同一のウインドウ内に表示されてもよい。図１３に示された展開ボタン１２１がクリックされると、ＣＰＵ１１は、ＭＲ００１についてリレーションを展開して表示する。

図１８によれば、ＭＲ００１の展開ボタン１２１ａがクリックされ、さらにＲ００１の展開ボタン１２１ｂがクリックされた状態が示されている。ＣＰＵ１１は、ＭＲ００１の展開ボタン１２１ａがクリックされると、ラダープログラムを検索し、ＭＲ００１が記述されているプログラムモジュール１５０ａの１行目（入力部の１行目）を抽出する。これにより、ＣＰＵ１１は、ＭＲ００１の左側に入力部の１行目を示すブロックを表示し、さらに、入力部の１行目を示すブロックのさらに左側に、Ｒ０００のブロックとＲ００１のブロックとを表示する。分析レポートまたは運転記録によれば、Ｒ００１がいつもと異なる状態にあることがわかる。そのため、ＣＰＵ１１は、Ｒ００１のブロックを強調表示する。

Ｒ００１のブロックのそばに表示される展開ボタン１２１ｂがクリックされると、ＣＰＵ１１はＲ００１について検索を実行し、プログラムモジュール１５０ｃ（加工部状態）の１行目を発見する。ＣＰＵ１１は、Ｒ００１のブロックの左側に加工部状態の１行目を示すブロックを表示し、さらに、そのブロックのさらに左側にＤＭ０のブロックを表示する。ＤＭ０が"０"でなかったために、Ｒ００１がオンとなり、Ｒ００４がオフになったことが、最終的に、判明する。

図１８においてプログラム表示領域１２２は、抽出されたプログラムモジュールを示すとともに、Ｒ００４がいつもと異なる状態になったタイミングにおける各デバイスのデバイス値を示している。空欄はデバイスがオフであることを示し、斜線はデバイスがオンであることを示す。ＣＰＵ１１は、各デバイスのデバイス値を、記憶装置１２に記憶されている運転記録から取得してリレーションマップ１２０に反映する。

図１８には再生時刻を表示したり、再生時刻を指定したりするためのシークバーが示されていないが、シークバーがリレーションマップ１２０に設けられてもよい。これにより、ユーザは、リレーションマップ１２０においても容易にデバイス値の再生時刻を変更することができよう。この場合も、ＣＰＵ１１は、リレーションマップ１２０における再生時刻と他のユーザインタフェースにおけるデバイス値の再生時刻とを同期させる。

リレーションマップ１２０において再生時刻を変更しながら、各デバイスのデバイス値を確認することで、ユーザは、デバイス値の異常状態がどのように連鎖したかを容易に理解できるようになろう。

なお、いつもと異なるイベントが発生したデバイスはラダープログラム上で強調表示されてもよい。図１８が示すように、Ｒ００１の周囲がハッチングまたは強調色で表示されてもよい。また、正常時のデバイス値がオフとなることが、表示されてもよい。これにより、ユーザは、正常なデバイス値を容易に理解できるようになろう。

図１８は、上述したように、デバイスＲ００４が選択された状態でボタン１１７ａが押し下げられたときに表示されるリレーションマップを示しているが、図１８が示すリレーションマップ１２０が表示された状態で、分析レポート１１１の時刻バー１１２ｅを左方に移動させていくと、強調表示されるデバイスが切り替わっていく。このことについて、図１９を用いて説明する。

図１９は、強調表示されるデバイスが切り替わっていく様子を示す説明図である。分析レポート１１１の時刻バー１１２ｅが、デバイスＲ００１およびＭＲ００１についていつもと違うが検出されたタイミング（１４：５０：４５）と、デバイスＲ００４についていつもと違うが検出されたタイミング（１４：５９：０１）との間にあってもよい。この場合、リレーションマップ１２０で強調表示されるのは、デバイスＲ００１およびＭＲ００１のみである（デバイスＲ００４の強調表示は消える）。そして、分析レポート１１１の時刻バー１１２ｅが、デバイスＲ００１およびＭＲ００１についていつもと違うが検出されたタイミング（１４：５０：４５）よりも左方にある場合、リレーションマップ１２０ではいずれのデバイスも強調表示されない。

図１９は、分析レポート１１の時刻バー１１２ｅを左へ移動させると、徐々に強調表示されるデバイスが減っていく様子を示している。これにより、どのデバイスがトラブルの原因になったかを時系列に沿って追跡することが容易になる。なお、分析レポート１１の時刻バー１１２ｅを右へ移動させていくと、徐々に強調表示されるデバイスが増えて行く。時刻バー１１２ｅがデバイスＲ００１およびＭＲ００１についていつもと違うが検出されたタイミング（１４：５０：４５）を過ぎると、デバイスＲ００１、ＭＲ００１およびＲ００４の全てが強調表示される。言い換えると、強調表示されるデバイスは、分析レポート１１の時刻バー１１２ｅが示す時刻には既にいつもと違うが検出されているデバイスが該当する。

なお、図１８が示すリレーションマップ１２０には、分析レポート１１０を作成する際に分析対象外のデバイスが含まれる場合がある。この場合、この分析対象外のデバイスがリレーションマップ１２０上で強調表示されてもよい。なぜなら、いつもと違うと判定されたデバイス以外に、分析対象外のデバイスが、トラブルの要因となるデバイスに該当する可能性もあるからである。識別性を向上させるために、いつもと違うと判定されたデバイスの強調表示と、分析対象外のデバイスの強調表示とは、たとえば、線の種別や色を変える等、異なる強調表示にされることが好ましい。また、図１８が示すリレーションマップ１２０では、分析レポート１１０で選択されたデバイス（Ｒ００４）に影響を与えるデバイス（ＭＲ００１やＲ００１）が、その選択デバイスより左方に表示されている。しかし、これは一例にすぎず、本発明はこれに限られない。たとえば、分析レポート１１０で選択されたデバイスから影響を受けるデバイスが、その選択デバイスより右方に表示されてもよい。

＜フローチャート＞
図２０はＣＰＵ１１により実行される方法を示すフローチャートである。操作部８を通じてプロジェクト編集プログラム１４ａが起動されると、ＣＰＵ１１は、プロジェクト編集プログラム１４ａにしたがって以下の処理を実行する。

ステップＳ１でＣＰＵ１１（プロジェクト編集部５０）はユーザにより指定されたプロジェクトデータを読み込む。これにより、ＣＰＵ１１（プロジェクト編集部５０）はＵＩ１００を表示部７に表示する。プロジェクト表示領域１０２にはプロジェクトデータから読み込まれた情報が反映される。プログラム表示領域１０４にはプロジェクトデータに含まれるラダープログラムが表示される。

ステップＳ２でＣＰＵ１１（プロジェクト編集部５０）は動作モードを編集モードに設定する。これにより、ＣＰＵ１１（受付部５７）は、プログラム表示領域１０４に入力される編集指示を受け付け、編集指示にしたがってラダープログラムを編集する。

ステップＳ３でＣＰＵ１１（プロジェクト編集部５０）は動作モードとしてモニタモードが選択されたかどうかを判定する。モード選択メニュー１０１においてモニタモードが選択されると、ＣＰＵ１１は、Ｓ４に進む。モード選択メニュー１０１においてモニタモードが選択されていない場合、ＣＰＵ１１は、Ｓ１１に進む。

ステップＳ４でＣＰＵ１１（デバッグ部５４）はＰＬＣ１において通知が発行されたかどうかを判定する。通知処理部５８は、ポーリングにより、通知発行部８４から通知を取得する。なお、ステップＳ４はオプションのステップである。通知が存在すれば、ＣＰＵ１１は、ステップＳ５に進む。

ステップＳ５でＣＰＵ１１（デバッグ部５４）はＷｅｂブラウザ６０に分析レポート１１０を表示する。デバッグ部５４は、通知に含まれている分析レポートのＵＲＬをＷｅｂブラウザ６０に渡す。Ｗｅｂブラウザ６０は、ＵＲＬにしたがってＨＴＴＰリクエストを生成して、Ｗｅｂサーバ５１にアクセスする。Ｗｅｂサーバ５１は、ＵＲＬにしたがってプロトコル変換部５２にＨＴＴＰリクエストを渡す。プロトコル変換部５２は、ＨＴＴＰリクエストをカプセル化して基本ユニット３のＣＰＵ３１（コマンド処理部７１）に渡す。コマンド処理部７１は、ヘッダ情報などに基づき、カプセル化されたＨＴＴＰリクエストをＣＰＵ４１ａのプロトコル変換部８１に渡す。プロトコル変換部８１カプセル化されたＨＴＴＰリクエストからＨＴＴＰリクエストを取り出して、Ｗｅｂサーバ８２に渡す。Ｗｅｂサーバ８２は、分析レポート１１０を表示するためのＷｅｂアプリケーション６１をＨＴＴＰレスポンスとしてプロトコル変換部８１に渡す。プロトコル変換部８１は、Ｗｅｂアプリケーション６１をカプセル化して、コマンド処理部７１に渡す。コマンド処理部７１は、カプセル化されたＷｅｂアプリケーション６１をプロトコル変換部５２に渡す。プロトコル変換部５２は、カプセル化されたＷｅｂアプリケーション６１からＷｅｂアプリケーション６１を取り出して、Ｗｅｂサーバ５１に渡す。Ｗｅｂサーバ５１は、Ｗｅｂアプリケーション６１をＷｅｂブラウザ６０に渡す。Ｗｅｂブラウザ６０は、Ｗｅｂアプリケーション６１を実行することで分析レポート１１０を表示部７に表示する。データ取得部６３は、通信処理部６２を介してＷｅｂサーバ５１に運転記録７４を要求する。Ｗｅｂサーバ５１は、ダウンロード部５３に運転記録７４をＰＬＣ１からダウンロードして記憶装置１２に記憶するよう指示する。ダウンロード部５３は、運転記録７４をＰＬＣ１からダウンロードして記憶装置１２に記憶する。Ｗｅｂサーバ５１は、データ取得部６３から要求された運転記録７４をデータ取得部６３に渡す。描画部６５は、運転記録７４に含まれている分析結果７７を分析レポート１１０に表示する。

ステップＳ６でＣＰＵ１１（デバッグ部５４）は分析レポート１１０またはＵＩ１００において動作モードがリプレイモードに切り替えられたかどうかを判定する。操作部８により動作モードがリプレイモードに切り替えられると、ＣＰＵ１１は、ステップＳ７に進む。作モードがリプレイモードに切り替えられていない場合、ＣＰＵ１１は、ステップＳ５に進む。

ステップＳ７でＣＰＵ１１（ラダーモニタ部５６）は記憶装置１２にダウンロードされた運転記録７４を表示部７に再生する。上述されたようにプログラム表示領域１０４にはラダープログラムに記述されているデバイスのデバイス値が運転記録７４から読み出され、各デバイスに反映される。デバイスに反映されるとは、デバイスがオンかオフかが視覚的にわかるように表示されること、または、デバイスに格納されているデバイス値がそのデバイスに関連付けて表示されることをいう。デバイス値がそのデバイスに関連付けて表示されるとは、たとえば、そのデバイスが記述されている行において、そのデバイスの近くにデバイス値を表示することをいう。

ステップＳ３でモニタモードへの切り替えが指示されていない場合、ＣＰＵ１１はＳ１１に進む。ステップＳ１１でＣＰＵ１１はリプレイモードへの切り替えが指示されたかどうかを判定する。リプレイモードへの切り替えが指示されていなければ、ＣＰＵ１１はＳ２に進む。リプレイモードへの切り替えが指示されていれば、ＣＰＵ１１はＳ１２に進む。

ステップＳ１２でＣＰＵ１１は記憶装置１２に保存されている運転記録７４を再生する。なお、記憶装置１２に運転記録７４が保存されていない場合、ＣＰＵ１１はＰＬＣ１から運転記録７４をダウンロードして記憶装置１２に保存し、運転記録７４を再生する。ＣＰＵ１１（再生部５９）は、運転記録７４に含まれる時系列データとしてのデバイス値をラダープログラムに重ねて表示する。また、再生部５９は、時間の経過とともに運転記録７４から次のデバイス値を読み出して、表示する。

ステップＳ１３でＣＰＵ１１は分析レポート１１０を表示するかどうかを判定する。たとえば、操作部８を通じて分析レポート１１０の表示の指示が入力されたかどうかをＣＰＵ１１が判定する。分析レポート１１０を表示しない場合、ＣＰＵ１１は、Ｓ１２に戻る。なお、ここで、他のモードへの切り替えが指示された場合、ＣＰＵ１１は、動作モードを他のモードへ切り替える。分析レポート１１０を表示する場合、ＣＰＵ１１は、Ｓ１４に進む。

ステップＳ１４でＣＰＵ１１は、Ｗｅｂブラウザ６０に分析レポート１１０を表示させる。

［分析レポートの表示処理］
図２１はステップＳ５、Ｓ１４の分析レポートの表示処理の詳細を示している。

ステップＳ２１でＣＰＵ１１は分析レポート１１０を表示させるためのＵＲＬ（ＩＰアドレス）をＷｅｂブラウザ６０に指定する。分析レポート１１０を表示させるためのＵＲＬは、たとえば、運転記録７４の分析結果７７に含まれていてもよい。

ステップＳ２２でＣＰＵ１１（Ｗｅｂブラウザ６０）は、分析レポート１１０を表示させるためのＵＲＬにしたがってＷｅｂサーバ５１にアクセスし、分析レポート１１０を表示するためのＷｅｂアプリケーション６１を受信する。

ステップＳ２３でＣＰＵ１１（Ｗｅｂブラウザ６０）はＷｅｂアプリケーション６１を実行することでＷｅｂブラウザ６０に分析レポート１１０を表示する。

ステップＳ２４でＣＰＵ１１はリレーションマップ１２０を表示するかどうかを判定する。たとえば、ボタン１１７ａがクリックされると、ＣＰＵ１１はリレーションマップ１２０を表示すると判定し、ステップＳ２５に進む。

ステップＳ２５でＣＰＵ１１はリレーションマップ１２０を表示部７に表示する。たとえば、ＣＰＵ１１（連携部６４）は通信処理部６２を介してＷｅｂサーバ５１にリレーションマップ１２０の表示要求（ＨＴＴＰリクエスト）を送信する。この表示要求には、非正常デバイスの指定情報と非正常状態が発生したタイミングを示す時刻情報などが含まれる。Ｗｅｂサーバ５１は、リレーションマップ１２０の表示要求をリレーションマップ部５５に渡し、リレーションマップの表示部品を用意させる。リレーションマップ部５５は、非正常デバイスの指定情報と非正常状態が発生したタイミングを示す時刻情報に基づき、運転記録７４から、非正常状態が発生したタイミングの前後における非正常デバイスのデバイス値を読み出して、リレーションマップ１２０の表示部品を作成し、Ｗｅｂサーバ５１に渡す。Ｗｅｂサーバ５１はリレーションマップ１２０の表示部品をＷｅｂブラウザ６０に渡す。Ｗｅｂブラウザ６０はリレーションマップ１２０の表示部品にしたがってリレーションマップ１２０を表示する。あるいは、リレーションマップ部５５はリレーションマップ１２０をＷｅｂブラウザ６０とは異なるウインドウとして表示部７に表示してもよい。

ステップＳ２４でリレーションマップ１２０を表示しないと判定すると、ＣＰＵ１１は、Ｓ２６に進む。ステップＳ２６でＣＰＵ１１は、指定されたデバイス値の波形を表示するかどうかを判定する。たとえば、いずれかの非正常デバイスが指定され、かつ、図１２に示されたボタン１１７ｂがクリックされると、ＣＰＵ１１は波形を表示すると判定し、ステップＳ２７に進む。

ステップＳ２７でＣＰＵ１１は波形ＵＩ１３０を表示部７に表示する。たとえば、ＣＰＵ１１（連携部６４）は通信処理部６２を介してＷｅｂサーバ５１に波形ＵＩの表示要求（ＨＴＴＰリクエスト）を送信する。この表示要求には、非正常デバイスの指定情報と非正常状態が発生したタイミングを示す時刻情報などが含まれる。Ｗｅｂサーバ５１は、波形ＵＩ１３０の表示要求を再生部５９に渡し、波形ＵＩ１３０の表示部品を用意させる。再生部５９は、非正常デバイスの指定情報と非正常状態が発生したタイミングを示す時刻情報に基づき、運転記録７４から、非正常状態が発生したタイミングの前後における非正常デバイスのデバイス値を読み出して、波形ＵＩ１３０の表示部品を作成し、Ｗｅｂサーバ５１に渡す。Ｗｅｂサーバ５１は波形ＵＩ１３０の表示部品をＷｅｂブラウザ６０に渡す。Ｗｅｂブラウザ６０は波形ＵＩ１３０の表示部品にしたがって波形ＵＩ１３０を表示する。あるいは、再生部５９は、波形表示プログラム１４ｂを起動して、波形ＵＩ１３０をＷｅｂブラウザ６０とは異なるウインドウとして表示部７に表示してもよい。

ここで、ステップＳ２５においてリレーションマップが表示された後、ＣＰＵ１１は、分析レポート１１０の時刻バー１１２ｅが操作されたか否かを判定する（ステップＳ２８）。時刻バー１１２ｅが操作された場合、図１９を用いて上述されたように、ＣＰＵ１１（連携部６４）は時刻バー１１２ｅが示す時刻に基づいて、既にいつもと違うが検出されているデバイスの強調表示を行う（ステップＳ２９）。時刻バー１１２ｅが示す時刻によっては、いずれのデバイスも強調表示されない。

また、ステップＳ２７において波形表示がなされた後、ＣＰＵ１１は、分析レポート１１０の時刻バー１１２ｅが操作されたか否かを判定する（ステップＳ３０）。時刻バー１１２ｅが操作された場合、ＣＰＵ１１（連携部６４）は時刻バー１１２ｅが示す時刻に基づいて、波形表示の時刻バー１１２ｇを連動表示させる（ステップＳ３１）。本実施形態では、図１９を用いて説明されたように、波形表示の時刻バー１１２ｇが連動表示されている。しかしこれは一例にすぎず、本発明はこれに限られない。たとえば、時刻バー１１２ｅが示す時刻に対応するデバイス波形が表示されるように、波形表示の表示範囲が連動してもよい。

＜まとめ＞
［観点１］
ＣＰＵ１１などは、ユーザプログラムを実行するプログラマブルロジックコントローラにより複数のデバイスから収集された複数のデバイス値の分析結果として、正常条件を満たさない非正常デバイスを示す分析レポートを取得する取得手段として機能する。表示部７などは分析レポートを表示するレポート表示手段として機能する。操作部８は、分析レポートに対する選択入力を受け付ける受付手段として機能する。ＣＰＵ１１および連携部６４は選択入力により選択された非正常デバイスを特定する特定手段として機能する。図９などが示すように、ＣＰＵ１１および表示部７は、非正常デバイスに関する情報であって、プログラマブルロジックコントローラに保持されている当該デバイスに関する情報をグラフィカルに表示するグラフィカル表示手段として機能する。これにより、いつもと違う挙動をしたデバイス（非正常デバイス）の情報をユーザに提供することが可能となる。

［観点２］
ＣＰＵ１１および連携部６４は選択入力により選択された非正常デバイスについて正常条件を満たさないというイベントが発生した時点を特定する特定手段として機能してもよい。上述されたように分析レポート１１０に表示される分析結果７７には非正常デバイスのデバイス値と、そのデバイス値が収集された時刻情報とが含まれている。そのため、連携部６４は、ポインタ１０３により選択された非正常デバイスにイベントが発生した時点を分析結果７７から特定できる。なお、デバイス値とその時刻情報は稼働ログ７６から取得されてもよい。図９などが示すように、ＣＰＵ１１および表示部７は、特定された時点の周辺においてデバイス値を収集されたデバイスに関する情報であって、プログラマブルロジックコントローラに保持されている当該デバイスに関する情報をグラフィカルに表示するグラフィカル表示手段として機能してもよい。

［観点３］
図７を参照して説明されたように、グラフィカル表示手段（例：ＵＩ１００）は、ユーザプログラムのデバッグ画面を表示するデバッグ表示手段（例：リプレイモード）を含んでもよい。デバッグ表示手段は、デバッグ画面においてユーザプログラムに関連付けて、デバイスに関する情報として当該デバイスから収集されたデバイス値を表示してもよい。デバイス値は、ＰＬＣ１がプロジェクトを実際に実行している期間においてＰＬＣ１により収集されたものである。ユーザプログラムに関連付けて実際のデバイス値が表示されるため、ユーザは、ユーザプログラムをデバッグまたは改良しやすくなるであろう。

［観点４］
取得手段（例：ＣＰＵ１１、ダウンロード部５３）は、プログラマブルロジックコントローラにおいて収集された時系列の複数のデバイス値を含む運転記録データ（例：運転記録７４）を取得するように構成されてもよい。分析レポート１１０は、当該運転記録データの分析に基づき決定された正常条件を満たさない非正常デバイスを提示する分析レポートであってもよい。図７や図９、図１４などが示すように、ＣＰＵ１１や再生部５９は、ＰＬＣ１に設けられているデバイスに格納されているデバイス値をモニタするためのモニタ画面上に、運転記録データに含まれる時系列の複数のデバイス値に基づき、時間の経過に伴うデバイス値の変化を再現表示する再現表示手段を含んでもよい。再現表示手段（例：再生部５９）は、非正常デバイスから収集された時系列のデバイス値であって、運転記録データに含まれる時系列のデバイス値を時間の経過にしたがって再現表示してもよい。再現表示手段（例：再生部５９）は、イベントが生じた時点の周辺で複数のデバイスから収集された時系列のデバイス値であって、運転記録データに含まれる時系列のデバイス値を時間の経過にしたがって再現表示するように構成されてもよい。

［観点５］
リレーションマップ１２０は、選択された注目デバイスについてユーザプログラムを解析することで得られた解析結果に基づき、当該注目デバイスと、当該ユーザプログラムにおいて当該注目デバイスに関連している他のデバイスとを示すリレーションマップの一例である。リレーションマップ部５５は、リレーションマップ１２０を表示部７に表示するマップ表示手段として機能する。マップ表示手段（例：リレーションマップ部５５）は、イベントが発生した時点に基づいてリレーションマップを強調表示してもよい。たとえば、非正常デバイスや、非正常デバイスを記述しているプログラムモジュールなどが強調表示されてもよい。たとえば、正常デバイスの表示色と非正常デバイスの表示色とがことなってもよい。正常デバイスのアイコン画像と非正常デバイスのアイコン画像とが異なってもよい。非正常デバイスには、非正常なイベントが発生したことを示す文字や記号などが表示されてもよい。また、複数の非正常なイベントが発生した時刻のうち、ユーザが注目している時刻が強調表示されてもよい。このような、注目時刻は、時刻バー１１２により強調して表示されてもよい。とくに、デバイス値が波形化されて表示される場合に、ユーザは時刻バー１１２に着目することで、どのタイミングでいつもと異なるイベントが発生したかを容易に理解できるであろう。

［観点６］
ＣＰＵ１１およびプロジェクト編集部５０は、ＰＬＣ１において収集された時系列の複数のデバイス値を含む運転記録データと、当該運転記録データの分析に基づき決定された正常条件を満たさない非正常デバイスを提示する分析レポートとを取得する取得手段として機能する。ＣＰＵ１１および再生部５９（ラダーモニタ部５６）は、イベントが生じた時点の周辺で複数のデバイスから収集された時系列のデバイス値であって、運転記録データに含まれる時系列のデバイス値を時間の経過にしたがって再現表示してもよい。

［観点７］
ＣＰＵ１１は、ユーザプログラムを実行するＰＬＣ１により複数のデバイスから収集された複数のデバイス値の分析結果として、正常条件を満たさない非正常デバイスを示す分析レポートを取得する取得手段として機能する。ＣＰＵ１１やリレーションマップ部５５は、選択された注目デバイスについてユーザプログラムを解析することで得られた解析結果に基づき、当該注目デバイスと、当該ユーザプログラムにおいて当該注目デバイスに関連している他のデバイスとを示すリレーションマップ１２０を表示するマップ表示手段として機能する。リレーションマップ部５５は、当該イベントが発生した時点に基づいてリレーションマップ１２０を強調表示してもよい。

［観点８］
ＰＬＣ１は、ユーザプログラムを実行して被制御機器を制御するプログラマブルロジックコントローラの一例である。ＰＣ２は、ＰＬＣ１と接続され、ユーザプログラムを編集してＰＬＣ１に転送するプログラム作成支援装置（監視装置）として機能する。通信部３３は、プログラム作成支援装置と通信する第一通信手段の一例である。ＣＰＵ３１は、第一通信手段により受信されるユーザプログラムを実行する実行手段の一例である。ＣＰＵ３１は、複数のプロセッサコアや複数のプロセッサ回路を有してもよい。ＣＰＵ３１、収集部７２およびロギング部７３は、ＰＬＣ１の動作に関する運転記録７４を記録する記録手段として機能する。ＣＰＵ４１ａおよび分析部８３は、運転記録を分析して分析レポート（例：分析結果）を作成する作成手段として機能する。分析レポート１１０を実現するＷｅｂアプリケーション６１は、メモリ４２ａのＲＯＭ領域に記憶されており、Ｗｅｂサーバ８２により読み出されてもよい。ＰＣ２の通信部１３ａは第一通信手段と通信する第二通信手段の一例である。ＣＰＵ１１およびプロジェクト編集部５０は、ユーザプログラムの編集画面を通じて当該ユーザプログラムの編集を受け付けるプログラム編集手段の一例である。ＣＰＵ１１およびＷｅｂブラウザ６０は、プログラム編集手段を介してＰＬＣ１から分析レポートを取得してレポート表示画面（図９）に表示する取得手段として機能する。これにより、いつもと違う挙動をしたデバイス（非正常デバイス）の情報などを含みうる分析サポート１１０をユーザに提供することが可能となる。Ｗｅｂブラウザ６０は、プロジェクト編集部５０に組み込まれたブラウザであってもよい。

［観点９］
Ｗｅｂサーバ５１は、取得手段から分析レポートに関するＨＴＴＰリクエストを受信する第一Ｗｅｂサーバとして機能する。プロトコル変換部５２は、第一ＷｅｂサーバのＨＴＴＰプロトコルを、ＰＬＣ１の第一通信手段とＰＣ２の第二通信手段との間で使用される通信プロトコルに変換する第一変換手段として機能する。第二通信手段（例：通信部１３ａ）は、分析レポートに関するＨＴＴＰリクエストを第一変換手段により変換して生成された要求信号（例：カプセル化されたＨＴＴＰリクエスト）を第一通信手段に送信する。第二通信手段（例：通信部１３ａ）は、当該要求信号に対する応答として分析レポートを第一通信手段から受信して、第一変換手段に渡すように構成されている。取得手段はＷｅｂブラウザ６０であってもよい。レポート表示画面（例：分析レポート１１０）は当該Ｗｅｂブラウザ６０のウインドウであってもよい。

［観点１０］
拡張ユニット４ａのＷｅｂサーバ８２は、分析レポートを提供する第二Ｗｅｂサーバとして機能する。プロトコル変換部８１は、要求信号を分析レポートに関するＨＴＴＰリクエストに変換して第二Ｗｅｂサーバに渡す第二変換手段として機能する。プロトコル変換部８１は、第二Ｗｅｂサーバから分析レポート（Ｗｅｂアプリケーション６１）を受信して第一通信手段に渡す。第一通信手段（例：通信部３３）は分析レポートを第二通信手段（例：通信部１３ａ）に送信する。第二通信手段（例：通信部１３ａ）は、分析レポートを第一変換手段に渡す。第一変換手段（例：プロトコル変換部５２）は分析レポートを第一Ｗｅｂサーバ（例：Ｗｅｂサーバ５１）に渡す。第一Ｗｅｂサーバ（例：Ｗｅｂサーバ５１）は分析レポートをＷｅｂブラウザ（例：Ｗｅｂブラウザ６０）に渡す。このように、拡張ユニット４ａとＰＣ２とが直接的に接続されていない場合であっても、分析レポート１１０を提供することが可能となる。なお、通信ケーブル９ｂを介して拡張ユニット４ａとＰＣ２とが通信可能である場合は、拡張ユニット４ａのＷｅｂサーバ８２は、分析レポートを直接的にＷｅｂブラウザ６０へ渡すことができる。

［観点１１］
プロジェクト編集部５０は、分析レポート１１０に紐づけられた運転記録７４の内容を、ユーザプログラムに対応付けてデバッグ画面（例：プログラム表示領域１０４）に表示してもよい。

［観点１２］
連携部６４またはダウンロード部５３は、分析レポート１１０（分析結果７７）に含まれている情報に基づき分析レポート１１０に紐づけられている運転記録７４を特定してもよい。ダウンロード部５３は、特定された運転記録７４をＰＬＣ１からダウンロードするダウンロード手段として機能してもよい。

［観点１３］
記憶装置１２は、ダウンロード手段によりダウンロードされた運転記録７４を保持する保持手段として機能する。再生部５９やデバッグ部５４は、分析レポート１１０に紐づけられている運転記録７４を保持手段から取得して再生する再生手段として機能してもよい。

［観点１４］
検知マップ１１１は、ＰＬＣ１においてユーザプログラムにしたがって実行される複数の工程の開始タイミングと終了タイミングとを示す工程マップの一例である。検知リスト１１４は、予め想定された正常条件を満たさなかったデバイスのリストの一例である。画像表示領域１１３は、リストにおいて選択されたデバイスに紐づけられている時刻情報に対してさらに紐づけられているカメラ画像を表示する。再生部５９、デバッグ部５４および連携部６４は、これらの表示情報を時刻整合させて再生するように構成されていてもよい。上述したように、連携部６４は、分析レポート１１０における再生時刻情報と、リプレイモードでラダープログラムとともに表示されるデバイス値の再生時刻情報とを、再生部５９およびデバッグ部５４と共有している。たとえば、連携部６４は、分析レポート１１０におけるシークバー１０５ｂや時刻バー１１２ｅ等の操作により再生時刻が変更されると、通信処理部６２を介して再生部５９よびデバッグ部５４に再生時刻の変更を通知する。同様に、再生部５９よびデバッグ部５４がシークバー１０５ａ等により再生時刻が変更されたことを検知すると、連携部６４に再生時刻の変更を通知する。これにより、プロジェクト編集部５０とＷｅｂブラウザ６０との間で運転記録７４の再生時刻が同期する。

［観点１５～１７］
リレーションマップ部５５は、ユーザプログラムに記述されている複数のデバイス間の関係を含むリレーションマップ１２０を表示するマップ表示手段として機能する。これにより、ユーザは非正常なイベントの発生原因となったデバイスを容易に発見できるようになろう。

マップ表示手段（例：リレーションマップ部５５）は、リレーションマップにおいて、注目デバイスおよび他のデバイスのうち、正常条件を満たさなかったデバイスを強調表示してもよい。マップ表示手段（例：リレーションマップ部５５）は、リスト（例：検知リスト１１４）から選択された注目デバイスと、当該注目デバイスの影響を受けるか、当該注目デバイスに影響を与える他のデバイスを含むリレーションマップ１２０を表示してもよい。なお、注目デバイスが影響を与えるデバイスについてはリレーションマップ１２０に含まれてなくてもよい。注目デバイス値が影響を与えるデバイスは、注目デバイスで非正常なイベントが発生した原因とはならないからである。つまり、非正常状態の原因となったイベントは、非正常状態が発生した時刻よりも前に発生しているはずだからである。

マップ表示手段（例：リレーションマップ部５５）は、リレーションマップ１２０において、リストから選択された注目デバイスを強調表示してもよい。注目デバイスのデバイス値は、複数の異なるデバイスのデバイス値の演算結果である。そのため、演算に使用された複数の関連デバイスのうち一部のデバイスが非正常であり、他のデバイスが正常である場合にも、演算結果を格納する注目デバイスは非正常となりうる。そのため、関連デバイスのうち、非正常なデバイスのみが強調されれば、ユーザは非正常状態の原因を探索しやすくなるであろう。

［観点１８］
再生部５９、デバッグ部５４および連携部６４は、運転記録７４を再生する時刻を示すシークバーを表示するともに、当該シークバーに対する操作に応じた時刻のデバイス値を保持手段から読み出してもよい。これにより、ユーザは、再生時刻を容易に変更できるようになろう。さらに、ユーザは、再生時刻を変化しながらデバイス値の変化を確認することで、容易に非正常状態の原因を探索できるようになろう。

［観点１９］
再生部５９および波形ＵＩ１３０は、運転記録７４に含まれるデバイスの値についての時系列データを波形化して表示するように構成されていてもよい。ユーザは、デバイス値の変化を容易に確認できるようになるため、非正常帯の原因を特定しやすくなるであろう。

［観点２０、２１］
ＣＰＵ４１ａおよび分析部８３は所定のイベントが発生すると運転記録７４を分析して分析結果を生成する生成手段として機能する。ＣＰＵ４１ａおよび通知発行部８４は、分析結果が生成されたことをプログラム作成支援装置（例：ＰＣ２）に通知する通知手段として機能する。これにより、ユーザは、注意すべきイベントが発生したことを容易に把握できるようになろう。

なお、所定のイベントとして、例えば、スキャン毎のデバイス値が正常時のばらつき範囲を超えたこと、としてもよい。具体的には、ＣＰＵ４１ａは、ユーザにより予め指定された一又は複数のデバイスのデバイス値が、正常時のばらつき範囲を示す閾値を超えたか否かを、常時監視（いわゆる兆候監視）する。そして、このデバイス値が正常時のばらつき範囲を示す閾値を超えた場合には、ＣＰＵ４１ａはＣＰＵ３１に対し、そのタイミングを基準として運転記録７４を生成するよう指示を行う。ＣＰＵ３１は、ＣＰＵ４１ａからの指示に基づいて自動的に運転記録７４を生成する。運転記録７４の生成が完了したら、ＣＰＵ３１は、ＣＰＵ４１ａに運転記録生成完了の通知を行う。この通知を受けたＣＰＵ４１ａは、ＣＰＵ３１により生成された運転記録７４に基づいて、分析レポートを自動的に生成する。このように、トラブルが発生する前の兆候を監視し、自動的に生成される分析レポートによって兆候の要因を特定できるようになる。

分析結果が生成されたことを示す通知は、ユーザプログラムの編集画面に表示されてもよい。とりわけ、プロジェクト編集のためのＵＩ１００がモニタモードに設定されると、ＣＰＵ１１は、通知をポーリングする。そして、ＣＰＵ１１は、通知を受信すると通知ダイアログ１０８を表示する。これにより、ユーザは、注意すべきイベントが発生したことを容易に認識できるであろう。通知ダイアログ１０８に、分析レポート１１０を表示するための表示ボタン１０９が設けられていてもよい。これにより、ユーザは、分析結果７７の詳細を容易に確認することが可能となる。さらに、分析レポート１１０から運転記録７４の再生を指示することで、ユーザは、注意すべきデバイスのデバイス値を再現して確認することが可能となる。

［観点２２］
分析コメント１１６は、運転記録７４に含まれるデバイス値の時系列データの波形と、当該デバイス値について予め取得されたマスターデータの波形とを対比させて表示する対比表示領域として機能してもよい。これにより、どのような非正常イベントが発生したかを、容易に把握することができるであろう。マスターデータは、複数の稼働ログ７６などに基づき学習された学習結果であってもよいし、ユーザにより指定された過去の稼働ログ７６であってもよい。

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

Claims (22)

1. ユーザプログラムを実行するプログラマブルロジックコントローラにより複数のデバイスから収集された複数のデバイス値の分析結果として、正常条件を満たさない非正常デバイスを示す分析レポートを取得する取得手段と、
   前記分析レポートを表示するレポート表示手段と、
   前記分析レポートに対する選択入力を受け付ける受付手段と、
   前記選択入力により選択された非正常デバイスを特定する特定手段と、
   前記特定された非正常デバイスに関する情報であって、前記プログラマブルロジックコントローラに保持されている当該デバイスに関する情報をグラフィカルに表示するグラフィカル表示手段と、
   を有することを特徴とする監視装置。
2. 前記特定手段は、前記選択入力により選択された非正常デバイスについて前記正常条件を満たさないというイベントが発生した時点を特定し、
   前記グラフィカル表示手段は、前記特定手段により特定された時点に基づいて、前記非正常デバイスに関する情報をグラフィカルに表示することを特徴とする請求項１に記載の監視装置。
3. 前記グラフィカル表示手段は、前記ユーザプログラムのデバッグ画面を表示するデバッグ表示手段を含み、
   前記デバッグ表示手段は、前記デバッグ画面において前記ユーザプログラムに関連付けて、前記デバイスに関する情報として当該デバイスから収集されたデバイス値を表示することを特徴とする請求項１または２に記載の監視装置。
4. 前記取得手段は、前記プログラマブルロジックコントローラにおいて収集された時系列の複数のデバイス値を含む運転記録データを取得するように構成されており、
   前記分析レポートは、当該運転記録データの分析に基づき決定された正常条件を満たさない非正常デバイスを提示する分析レポートであり、
   前記グラフィカル表示手段は、前記プログラマブルロジックコントローラに設けられているデバイスに格納されているデバイス値をモニタするためのモニタ画面上に、前記運転記録データに含まれる時系列の複数のデバイス値に基づき、時間の経過に伴うデバイス値の変化を再現表示する再現表示手段を含み、
   前記再現表示手段は、前記非正常デバイスから収集された時系列のデバイス値であって、前記運転記録データに含まれる時系列のデバイス値を時間の経過にしたがって再現表示するように構成されていることを特徴とする請求項１ないし３のいずれか一項に記載の監視装置。
5. 前記グラフィカル表示手段は、選択された注目デバイスについて前記ユーザプログラムを解析することで得られた解析結果に基づき、当該注目デバイスと、当該ユーザプログラムにおいて当該注目デバイスに関連している他のデバイスとを示すリレーションマップを表示するマップ表示手段を含み、
   前記マップ表示手段は、前記選択入力により選択された非正常デバイスについて前記正常条件を満たさないというイベントが発生した時点に基づいて前記リレーションマップを強調表示することを特徴とする請求項１ないし４のいずれか一項に記載の監視装置。
6. プログラマブルロジックコントローラにおいて収集された時系列の複数のデバイス値を含む運転記録データと、当該運転記録データの分析に基づき決定された正常条件を満たさない非正常デバイスを提示する分析レポートとを取得する取得手段と、
   前記プログラマブルロジックコントローラに設けられているデバイスに格納されているデバイス値をモニタするためのモニタ画面上に、前記運転記録データに含まれる時系列の複数のデバイス値に基づき、時間の経過に伴うデバイス値の変化を再現表示する再現表示手段と、
   前記分析レポートを表示するレポート表示手段と、
   前記分析レポートに対する選択入力を受け付ける受付手段と、
   前記分析レポートに対する選択入力により選択された非正常デバイスについて、当該非正常デバイスが正常条件を満たさなかったというイベントが発生した時点を特定する特定手段と、を有し、
   前記再現表示手段は、前記イベントが生じた時点の周辺で複数のデバイスから収集された時系列のデバイス値であって、前記運転記録データに含まれる時系列のデバイス値を時間の経過にしたがって再現表示することを特徴とする監視装置。
7. ユーザプログラムを実行するプログラマブルロジックコントローラにより複数のデバイスから収集された複数のデバイス値の分析結果として、正常条件を満たさない非正常デバイスを示す分析レポートを取得する取得手段と、
   選択された注目デバイスについて前記ユーザプログラムを解析することで得られた解析結果に基づき、当該注目デバイスと、当該ユーザプログラムにおいて当該注目デバイスに関連している他のデバイスとを示すリレーションマップを表示するマップ表示手段と、
   前記分析レポートを表示するレポート表示手段と、
   前記分析レポートに対する選択入力を受け付ける受付手段と、
   前記選択入力により選択された非正常デバイスについて前記正常条件を満たさないというイベントが発生した時点を特定する特定手段と、を有し、
   前記マップ表示手段は、当該イベントが発生した時点に基づいて前記リレーションマップを強調表示することを特徴とする監視装置。
8. ユーザプログラムを実行して被制御機器を制御するプログラマブルロジックコントローラと、
   前記プログラマブルロジックコントローラと接続され、前記ユーザプログラムを編集して前記プログラマブルロジックコントローラに転送するプログラム作成支援装置と、を有するプログラマブルロジックコントローラシステムであって、
   前記プログラマブルロジックコントローラは、
   前記プログラム作成支援装置と通信する第一通信手段と、
   前記第一通信手段により受信される前記ユーザプログラムを実行する実行手段と、
   前記プログラマブルロジックコントローラの動作に関する運転記録を記録する記録手段と、
   前記運転記録を分析して分析レポートを作成する作成手段と、を有し、
   前記プログラム作成支援装置は、
   前記第一通信手段と通信する第二通信手段と、
   前記ユーザプログラムの編集画面を通じて当該ユーザプログラムの編集を受け付けるプログラム編集手段と、
   前記プログラム編集手段を介して前記プログラマブルロジックコントローラから前記分析レポートを取得してレポート表示画面に表示する取得手段と、を有することを特徴とするプログラマブルロジックコントローラシステム。
9. 前記プログラム作成支援装置は、
   前記取得手段から前記分析レポートに関するＨＴＴＰリクエストを受信する第一Ｗｅｂサーバと、
   前記第一ＷｅｂサーバのＨＴＴＰプロトコルを、前記プログラマブルロジックコントローラの前記第一通信手段と前記第二通信手段との間で使用される通信プロトコルに変換する第一変換手段と、を有し、
   前記第二通信手段は、前記分析レポートに関するＨＴＴＰリクエストを前記第一変換手段により変換して生成された要求信号を前記第一通信手段に送信し、当該要求信号に対する応答として前記分析レポートを前記第一通信手段から受信して、前記第一変換手段に渡すように構成されており、
   前記取得手段はＷｅｂブラウザであり、前記レポート表示画面は当該Ｗｅｂブラウザのウインドウであることを特徴とする請求項８に記載のプログラマブルロジックコントローラシステム。
10. 前記プログラマブルロジックコントローラは、
    前記分析レポートを提供する第二Ｗｅｂサーバと、
    前記要求信号を前記分析レポートに関するＨＴＴＰリクエストに変換して前記第二Ｗｅｂサーバに渡す第二変換手段と、を有し、
    前記第二変換手段は、前記第二Ｗｅｂサーバから前記分析レポートを受信して前記第一通信手段に渡し、前記第一通信手段は前記分析レポートを前記第二通信手段に送信し、前記第二通信手段は、前記分析レポートを前記第一変換手段に渡し、前記第一変換手段は前記分析レポートを前記第一Ｗｅｂサーバに渡し、前記第一Ｗｅｂサーバは前記分析レポートを前記Ｗｅｂブラウザに渡すように構成されていることを特徴とする請求項９に記載のプログラマブルロジックコントローラシステム。
11. 前記プログラム編集手段は、前記分析レポートに紐づけられた運転記録の内容を、前記ユーザプログラムに対応付けてデバッグ画面に表示するように構成されていることを特徴とする請求項８ないし１０のいずれか一項に記載のプログラマブルロジックコントローラシステム。
12. 前記プログラム作成支援装置は、
    前記分析レポートに含まれている情報に基づき前記分析レポートに紐づけられている前記運転記録を特定し、前記特定された運転記録を前記プログラマブルロジックコントローラからダウンロードするダウンロード手段をさらに有することを特徴とする請求項１１に記載のプログラマブルロジックコントローラシステム。
13. 前記プログラム作成支援装置は、
    前記ダウンロード手段によりダウンロードされた前記運転記録を保持する保持手段と、
    前記分析レポートに紐づけられている前記運転記録を前記保持手段から取得して再生する再生手段と、
    をさらに有することを特徴とする請求項１２に記載のプログラマブルロジックコントローラシステム。
14. 前記再生手段は、
    前記プログラマブルロジックコントローラにおいて前記ユーザプログラムにしたがって実行される複数の工程の開始タイミングと終了タイミングとを含む工程マップと、
    予め想定された正常条件を満たさなかったデバイスのリストと、
    前記リストにおいて選択されたデバイスに紐づけられている時刻情報に対してさらに紐づけられているカメラ画像と、を、
    時刻整合させて再生するように構成されていることを特徴とする請求項１３に記載のプログラマブルロジックコントローラシステム。
15. 前記ユーザプログラムに記述されている複数のデバイス間の関係を含むリレーションマップを表示するマップ表示手段をさらに含むことを特徴とする請求項１４に記載のプログラマブルロジックコントローラシステム。
16. 前記マップ表示手段は、前記リストから選択された注目デバイスと、当該注目デバイスに影響を与える他のデバイスを含む前記リレーションマップを表示するように構成されていることを特徴とする請求項１５に記載のプログラマブルロジックコントローラシステム。
17. 前記マップ表示手段は、前記リレーションマップにおいて、前記注目デバイスおよび前記他のデバイスのうち、前記正常条件を満たさなかったデバイスを強調表示するように構成されていることを特徴とする請求項１６に記載のプログラマブルロジックコントローラシステム。
18. 前記再生手段は、前記運転記録を再生する時刻を示すシークバーを表示するともに、当該シークバーに対する操作に応じた時刻のデバイス値を前記保持手段から読み出すことを特徴とする請求項１６に記載のプログラマブルロジックコントローラシステム。
19. 前記再生手段は、前記運転記録に含まれる前記デバイスの値についての時系列データを波形化して表示するように構成されていることを特徴とする請求項１４ないし１８のいずれか一項に記載のプログラマブルロジックコントローラシステム。
20. 前記プログラマブルロジックコントローラは、
    所定のイベントが発生すると前記運転記録を分析して分析結果を生成する生成手段と、
    前記分析結果が生成されたことを前記プログラム作成支援装置に通知する通知手段と
    をさらに有することを特徴とする請求項８ないし１９のいずれか一項に記載のプログラマブルロジックコントローラシステム。
21. 前記分析結果が生成されたことを示す通知は、前記ユーザプログラムの編集画面に表示されることを特徴とする請求項２０に記載のプログラマブルロジックコントローラシステム。
22. 前記運転記録に含まれるデバイス値の時系列データの波形と、当該デバイス値について予め取得されたマスターデータの波形とを対比させて表示する対比表示部をさらに有することを特徴とする請求項１４ないし２１のいずれか一項に記載のプログラマブルロジックコントローラシステム。

Images