JP2018088177A - 情報処理装置、情報処理システム、情報処理方法、および情報処理プログラム - Google Patents

Abstract

【課題】故障後の修理対応時にアクセスされたメモリの参照先を記憶することがすることができる情報処理装置を提供する。
【解決手段】情報処理装置の一例であるプログラマブル表示器１００は、外部の記憶装置４２０内の情報にアクセスすることが可能なアクセス部１５０と、生産装置に生じた事象を示すイベントを検知するための検知部１５１と、検知部１５１によって所定のイベントが検知された後にアクセス部１５０によって参照される記憶装置４２０内のアクセス先を監視し、当該アクセス先を上記所定のイベントに関連付けて記憶装置１２０に格納するための監視部１５２とを備える。
【選択図】図４

Description

本開示は、制御装置によって参照される記憶装置内のアクセス先を記憶するための技術に関する。

近年、ＦＡ（Factory Automation）分野では、生産装置の構成が複雑になっており、生産装置の故障の原因を突き止めることが困難になっている。そのため、故障原因、故障箇所、対処方法などを自動的に診断するための自己診断技術が開発されている。

当該技術に関し、特開２００８−０１５５６８号公報（特許文献１）は、自己診断機能を有する管理機器から得られた自己診断結果をデーターベースとして蓄積し、当該データーベースの分析結果をサービスマンに報知するメンテナンスシステムが開示されている。当該メンテナンスシステムは、当該分析結果として、故障箇所、対処方法などを報知する。

特開２００８−０１５５６８号公報

生産装置の構成が複雑化しているため、修理担当者は、自己診断機能による診断結果を確認するだけでは、故障に対処できないことが多い。特に、修理担当者の経験が浅い場合には、この問題が顕著に表れる。また、自己診断機能を有する装置は高価であるので、自己診断機能が搭載されていない装置も多い。このような場合、修理担当者は、自身の経験やノウハウに基づいて、生産装置の故障の原因を突き止める。

修理態様の一例として、修理担当者は、メモリウォッチ機能を有する修理ツールを用いる。修理担当者は、このような修理ツールにおいてメモリの参照先を追加し、当該参照先のメモリの値を確認することで生産装置内の各構成が正常に動作しているか否かを判断する。このとき、修理担当者が追加するメモリの参照先は、自身の経験やノウハウに依存する。このような故障時における修理過程が修理担当者間で共有されれば、経験が浅い修理担当者であっても、様々な故障に対応することが可能になる。したがって、故障後の修理対応時にアクセスされたメモリの参照先を記憶することが望まれている。

ある局面に従うと、情報処理装置は、外部の第１記憶装置内の情報にアクセスすることが可能なアクセス部と、生産装置に生じた事象を示すイベントを検知するための検知部と、上記検知部によって所定のイベントが検知された後に上記アクセス部によって参照される上記第１記憶装置内のアクセス先を監視し、上記アクセス先を上記所定のイベントに関連付けて内部または外部の第２記憶装置に格納するための監視部とを備える。

好ましくは、上記情報処理装置は、上記所定のイベントに対するトラブルシュートが実行された場合に、上記所定のイベントに関連付けられている上記アクセス先を上記トラブルシュートとして表示するための表示部をさらに備える。

好ましくは、上記情報処理装置は、上記トラブルシュートに対する評価を受け付けるための評価受付部をさらに備える。上記表示部は、上記トラブルシュートに対する上記評価をさらに表示する。

好ましくは、上記表示部は、上記所定のイベントに対するトラブルシュートが複数存在する場合には、当該複数のトラブルシュートを上記評価の順に表示する。

好ましくは、上記表示部は、上記トラブルシュートの参照回数をさらに表示する。
好ましくは、上記表示部は、上記所定のイベントに対するトラブルシュートが複数存在する場合には、当該複数のトラブルシュートを上記参照回数の順に表示する。

好ましくは、上記情報処理装置は、上記所定のイベントが検知された後に上記第１記憶装置にアクセスしたユーザのスキルの入力を受け付けるためのスキル受付部をさらに備える。上記監視部は、上記所定のイベントと上記アクセス先とに関連付けて上記受け付けたスキルを上記第２記憶装置にさらに格納する。

他の局面に従うと、情報処理システムは、複数の第１情報処理装置と、上記複数の第１情報処理装置のそれぞれと通信可能に構成されている第２情報処理装置とを備える。上記複数の第１情報処理装置の各々は、外部の第１記憶装置内の情報にアクセスすることが可能なアクセス部と、生産装置に生じた事象を示すイベントを検知するための検知部と、上記検知部によって所定のイベントが検知された後に上記アクセス部によって参照される上記第１記憶装置内のアクセス先を監視するための監視部と、上記所定のイベントに関連付けて上記アクセス先を上記第１情報処理装置に送信するための通信部とを含む。上記第２情報処理装置は、上記複数の第１情報処理装置の各々から受信した上記アクセス先と上記所定のイベントとを格納するための第２記憶装置を含む。

他の局面に従うと、情報処理装置における情報処理方法は、生産装置に生じた事象を示すイベントを検知するステップと、上記情報処理装置の外部の第１記憶装置内の情報にアクセスするステップと、上記検知するステップにおいて所定のイベントが検知された後に、上記アクセスするステップでアクセスされる第１記憶装置内のアクセス先を監視するステップと、上記所定のイベントに関連付けて上記アクセス先を上記情報処理装置の内部または外部の第２記憶装置に格納するステップとを備える。

他の局面に従うと、情報処理装置に実行される情報処理プログラムは、上記情報処理装置に、生産装置に生じた事象を示すイベントを検知するステップと、上記情報処理装置の外部の第１記憶装置内の情報にアクセスするステップと、上記検知するステップにおいて所定のイベントが検知された後に、上記アクセスするステップでアクセスされる第１記憶装置内のアクセス先を監視するステップと、上記所定のイベントに関連付けて上記アクセス先を上記情報処理装置の内部または外部の第２記憶装置に格納するステップとを実行させる。

ある局面において、故障後の修理対応時にアクセスされたメモリの参照先を記憶することができる。

本開示の上記および他の目的、特徴、局面および利点は、添付の図面と関連して理解される本発明に関する次の詳細な説明から明らかとなるであろう。

第１の実施の形態に従う情報処理システムの基本構成を示す模式図である。 第１の実施の形態に従うプログラマブル表示器の表示画面の一例を示す図である。 デバイスモニタ画面の一例を示す図である。 第１の実施の形態に従うプログラマブル表示器の機能構成の一例を示す図である。 アクセス履歴のデータ構造の一例を示す図である。 修理時におけるプログラマブル表示器の画面例を示す図である。 修理時におけるプログラマブル表示器の画面例を示す図である。 修理時におけるプログラマブル表示器の画面例を示す図である。 修理時におけるプログラマブル表示器の画面例を示す図である。 プログラムモニタ画面の一例を示す図である。 トラブルシュートの記録処理を表わすフローチャートである。 記録されたトラブルシュートの実行処理を表わすフローチャートである。 第１の実施の形態に従うプログラマブル表示器の主要なハードウェア構成を示すブロック図である。 第２の実施の形態に従う情報処理システムの基本構成を示す模式図である。

以下、図面を参照しつつ、本発明に従う各実施の形態について説明する。以下の説明では、同一の部品および構成要素には同一の符号を付してある。それらの名称および機能も同じである。したがって、これらについての詳細な説明は繰り返さない。

＜第１の実施の形態＞
［Ａ．情報処理システム１］
図１を参照して、本実施の形態に従う情報処理システム１の基本構成について説明する。図１は、本実施の形態に従う情報処理システム１の基本構成を示す模式図である。

図１に示されるように、情報処理システム１は、たとえば、生産装置１０と、携帯通信端末３００Ａ〜３００Ｃとで構成されている。

図１には、情報処理システム１が１つの生産装置１０で構成されている例が示されているが、情報処理システム１は、複数の生産装置１０で構成されてもよい。この場合、情報処理システム１は、複数の生産装置１０と通信することが可能なサーバーをさらに含んでもよい。

以下では、携帯通信端末３００Ａ〜３００Ｃの少なくとも１つを代表して「携帯通信端末３００」ともいう。図１には、スマートフォンとしての携帯通信端末３００が示されているが、携帯通信端末３００は、スマートフォンに限定されない。一例として、携帯通信端末３００は、タブレット端末であってもよいし、通信機能を備えるその他の携帯機器であってもよい。

生産装置１０は、工場などに設置されており、種々の製品を生産する。生産装置１０は、情報処理装置としてのプログラマブル表示器１００を含む。プログラマブル表示器１００は、生産装置１０と一体的に構成されてもよいし、生産装置１０と別個に構成されてもよい。

プログラマブル表示器１００は、ＨＭＩ（Human Machine Interface）環境におけるＧＵＩ（Graphical User Interface）としての役割を果たす。プログラマブル表示器１００は、タッチパネルなどの操作部と、液晶ディスプレイなどの表示部と、他の通信端末と通信するための通信部とを備える。プログラマブル表示器１００の通信部は、たとえば、生産装置１０を制御するためのＰＬＣ（Programmable Logic Controller）や修理担当者３３０Ａ〜３３０Ｃの携帯通信端末３００Ａ〜３００Ｃとの通信を実現する。

図２は、プログラマブル表示器１００の表示画面の一例を示す図である。プログラマブル表示器１００のディスプレイ１０５には、生産装置１０の各構成の状態を表わす監視画面２９が表示されている。監視画面２９は、複数のパーツ画像で構成されている。パーツ画像の各々は、生産装置１０５内の対応する構成（たとえば、電源、スイッチ、センサなど）の状態を表わす。一例として、パーツ画像２９Ａは、電源の状態を表わす。電源がＯＮの状態であるときにはパーツ画像２９Ａが点灯し、電源がＯＦＦの状態であるときにはパーツ画像２９Ａが消灯する。作業者は、監視画面２９を確認することで、生産装置１０内の各構成の状態を確認することができる。

また、作業者は、監視画面２９内の各パーツ画像を操作することで、生産装置１０の各構成を操作することができる。一例として、作業者は、パーツ画像２９Ａをタッチすることで、生産装置１０の電源のＯＮ／ＯＦＦを切り替えることができる。

［Ｂ．メモリウォッチ機能］
プログラマブル表示器１００は、監視対象である生産装置１０に生じるイベントを監視することで、生産装置１０に生じる事象（たとえば、故障など）を監視する。通知対象のイベントが生産装置１０に発生した場合には、プログラマブル表示器１００は、イベントの発生を修理担当者に通知する。当該通知を受けた修理担当者は、生産装置１０の修理を行う。

修理態様の一例として、修理担当者は、プログラマブル表示器１００に搭載されているメモリウォッチ機能を使用する。メモリウォッチ機能が実行されると、プログラマブル表示器１００は、デバイスモニタ画面を表示する。修理担当者は、デバイスモニタ画面に対してメモリの参照先を指定し、当該参照先のメモリの値を確認することで生産装置内の各部品（たとえば、センサやスイッチなど）が正常に動作しているか否かを判断する。

図３は、デバイスモニタ画面の一例を示す図である。プログラマブル表示器１００のディスプレイ１０５は、メモリウォッチ画面３０を表示している。

メモリウォッチ画面３０は、たとえば、項目３１Ａ〜３１Ｅと、ボタン３１Ｆとで構成されている。項目３１Ａにおいて、修理担当者は、監視対象のコントローラ（たとえば、ＰＬＣ）を指定することができる。コントローラは、生産装置１０を制御するための装置である。項目３１Ｂにおいて、修理担当者は、項目３１Ｃで指定された部品ごとにウォッチ機能の有効／無効を切り替えることができる。項目３１Ｃにおいて、修理担当者は、メモリのアクセス先を入力することができ、監視対象の部品を指定することができる。メモリのアクセス先は、監視対象の部品の名前を示す変数名や、当該部品の状態を示すアドレスで表わされる。項目３１Ｄにおいて、監視対象の部品の状態を表わす変数のデータタイプが表示される。項目３１Ｅにおいて、監視対象の部品の状態を表わす変数の値が表示される。修理担当者は、ボタン３１Ｆを押下することで、項目３１Ａ〜３１Ｃにおける入力値を変更することができる。

修理担当者は、生産装置１０を動作させた状態で、項目３１Ｅに示される値を確認することで、項目３１Ｃで指定された部品の状態を確認することができる。修理担当者が項目３１Ｃに追加するアクセス先は、当該修理担当者の自身の経験やノウハウに依存する。この修理過程が修理担当者間で共有されれば、知識がない修理担当者であっても、様々な故障に対応することが可能になる。

そこで、プログラマブル表示器１００は、故障を示す所定のイベントが検知された後にコントローラ内の記憶装置（第１記憶装置）において参照されたアクセス先を監視し、当該アクセス先を発生したイベントに関連付けて記憶する。当該アクセス先は、プログラマブル表示器１００の内部記憶装置（第２記憶装置）に記憶されてもよいし、「第２の実施の形態」で説明するようにサーバーなどの外部記憶装置（第２記憶装置）に記憶されてもよい。プログラマブル表示器１００は、たとえば、メモリウォッチ画面３０に設定された設定情報を記憶する。これにより、故障時に参照されたコントローラ内の記憶装置のアクセス先が記憶される。プログラマブル表示器１００は、同様のイベント（故障）が新たに発生したときには、当該イベントに関連付けられている設定情報をメモリウォッチ画面３０に反映する。修理担当者は、前回の修理時に参照されたメモリのアクセス先を参考にすることができる。

［Ｃ．プログラマブル表示器１００の機能構成］
図４および図５を参照して、プログラマブル表示器１００の機能構成について説明する。図４は、プログラマブル表示器１００の機能構成の一例を示す図である。プログラマブル表示器１００は、生産装置１０を制御するためのコントローラ４００と通信可能に構成されている。

プログラマブル表示器１００は、主なハードウェア構成として、制御装置１０１と、記憶装置１２０とを含む。制御装置１０１は、機能構成として、アクセス部１５０と、検知部１５１と、監視部１５２と、表示制御部１５３と、評価受付部１５４と、スキル受付部１５６とを含む。

アクセス部１５０は、外部の記憶装置であるコントローラ４００の記憶装置４２０（第１記憶装置）内の情報にアクセスすることができる。一例として、アクセス部１５０は、上述のメモリウォッチ画面３０（図３参照）などを介して記憶装置４２０内の情報にアクセスする。アクセス部１５０によるアクセス先は、監視部１５２に出力される。当該アクセス先は、たとえば、記憶装置４２０内のアドレスとして表される。

検知部１５１は、生産装置１０に生じるイベントを監視し、所定のイベントを検知する。検知対象のイベントは、予め登録されていてもよいし、ユーザによって任意に設定されてもよい。検知対象のイベントは、生産装置１０の故障を明示的に示す事象だけでなく、生産装置１０の故障を示唆する事象であってもよい。検知部１５１は、検知対象である所定のイベントを検知すると、当該イベントを検知したことを監視部１５２に出力する。

監視部１５２は、検知部１５１によって検知対象のイベントが検知された後に、アクセス部１５０によってアクセスされる記憶装置４２０内のアクセス先を監視する。好ましくは、当該監視処理は、検知対象のイベントが検知された後の所定のタイミングに開始される。一例として、当該監視処理の開始タイミングは、メモリウォッチ機能が起動されたタイミングや、監視処理の開始操作を受け付けたタイミングを含む。監視部１５２は、監視結果として得られたアクセス先を、検知されたイベントに関連付けた上でアクセス履歴１２４に書き込む。

図５は、アクセス履歴１２４のデータ構造の一例を示す図である。図５に示されるように、アクセス履歴１２４は、アクセス情報１２５Ａ〜１２５Ｃを含む。以下では、アクセス情報１２５Ａ〜１２５Ｃの１つを代表して、アクセス情報１２５ともいう。アクセス情報１２５において、トラブルシュートナンバー１２６Ａと、イベントの種類を示すイベントナンバー１２６Ｂと、メモリのアクセス先１２６Ｃとが少なくとも関連付けられる。好ましくは、アクセス情報１２５において、アクセス情報の評価１２６Ｄと、アクセス情報の参照回数１２６Ｅと、イベントの対応者１２６Ｆとがさらに関連付けられる。

再び図４を参照して、表示制御部１５３は、検知部１５１によって検知されたイベントに対するトラブルシュートが実行された場合に、アクセス履歴１２４を参照して、当該イベントに関連付けられているアクセス情報１２５を特定し、当該アクセス情報１２５に含まれるアクセス先をディスプレイ１０５に表示する。これにより、修理担当者は、過去のトラブルシュート時に参照されたメモリのアクセス先を参考にすることができる。

評価受付部１５４は、参照されたトラブルシュートに対しての評価を受け付ける。評価の入力は、マウス操作やタッチパネルに対するタッチ操作で実現される。典型的には、修理担当者は、参考にしたトラブルシュートが役に立った場合には高評価（たとえば、「Ｇｏｏｄ」や「いいね」など）を入力し、参考にしたトラブルシュートが役に立たなかった場合には低評価（たとえば、「Ｂａｄ」など）を入力する。入力された評価は、アクセス履歴１２４の評価１２６Ｄに書き込まれる。

スキル受付部１５６は、故障を示す所定のイベントが検知された後にメモリにアクセスしたユーザの経験値を示すスキルの入力を受け付ける。すなわち、スキル受付部１５６は、トラブルシュートを生成したユーザのスキルの入力を受け付ける。スキルは、たとえば、数値で表わされ、数値が大きいほどスキルが高いことを示す。

スキルの入力を受け付けるタイミングは、任意である。たとえば、スキル受付部１５６は、トラブルシュートの生成時にスキルの入力を受け付ける。あるいは、ユーザごとのスキルを規定したスキル情報が予めデーターベース化されており、スキル受付部１５６は、現在のログインユーザに関連付けられているスキルをイベントの発生時などに取得してもよい。スキル受付部１５６が受け付けられたスキルは、イベントナンバー１２６Ｂやアクセス先１２６Ｃなどに関連付けられた上でアクセス履歴１２４のスキル１２６Ｇに書き込まれる。

なお、上述では、図４に示される各機能構成がプログラマブル表示器１００に実装されている例について説明を行ったが、図４に示される各機能構成の少なくとも一部は、生産装置１０に実装されてもよいし、生産装置１０を制御するコントローラ（たとえば、ＰＬＣなど）に実装されてもよいし、情報処理システム１を構成するサーバー（図示しない）に実装されてもよいし、その他の情報処理装置に実装されてもよい。

［Ｄ．プログラマブル表示器１００の表示画面］
図６〜図９を参照して、修理時におけるプログラマブル表示器１００の画面遷移について説明する。図６〜図９は、修理時におけるプログラマブル表示器１００の画面例を示す図である。

図６には、生産装置１０において発生しているイベントの確認画面４０が示されている。確認画面４０は、イベントの一覧４１を含む。一覧４１には、発生しているイベントが発生日時の順に表示される。修理担当者は、一覧４１に含まれるイベントのいずれかを選択した状態で詳細確認ボタン４２を押下することで、各イベントの詳細を確認することができる。詳細確認ボタン４２が押下された結果、図７に示される詳細確認画面５０が表示される。

詳細確認画面５０は、確認画面４０で選択されたイベントの名前、当該イベントのコード番号、当該イベントの発生日時、当該イベントの警戒レベル、当該イベントに対する対処方法などを表示する。修理担当者は、トラブルシュートボタン５１を押下することで、確認画面４０で選択されたイベントに対処するためのトラブルシュートを確認することができる。トラブルシュートボタン５１が押下された結果、図８に示される詳細確認画面５０が表示される。

履歴画面６０は、履歴欄６１と、コメント欄６２と、ボタン６３と、評価入力欄６４と、ボタン６５，６６とを含む。履歴欄６１は、上述の確認画面４０で選択されたイベントに対するトラブルシュートの一覧を含む。

履歴欄６１には、各トラブルシュートについて、評価、参照回数（再現回数）、作成者、作成日時、当該作成者の経験値を示すスキルなどが表示される。トラブルシュートに対する評価や参照回数が表示されることで、修理担当者は、トラブルシュートのそれぞれの有効性を一見して理解することができる。また、各トラブルシュートの作成者のスキル（たとえば、経験年数や資格など）が表示されることで、修理担当者は、トラブルシュートの信頼性を一見して区別することができる。

好ましくは、確認画面４０で選択されたイベントに対するトラブルシュートが複数存在する場合には、当該複数のトラブルシュートを評価または参照回数の順に表示する。これにより、修理担当者は、トラブルシュートのそれぞれの有効性をより早く把握することができる。

修理担当者は、履歴欄６１に表示されているトラブルシュートのいずれかを選択することができる。コメント欄６２には、トラブルシュートの作成者によって入力されたコメントが表示される。

修理担当者が、履歴欄６１に表示されているトラブルシュートのいずれかを選択した状態でボタン６３を押下すると、プログラマブル表示器１００は、アクセス履歴１２４（図５参照）を参照して、選択されたトラブルシュートに関連付けられているアクセス情報１２５（図５参照）を特定する。特定されたアクセス情報１２５は、図９に示されるメモリウォッチ画面７０に表示される。このように、過去のトラブルシュート時に参照されたメモリのアクセス先（変数名やアドレスなど）がメモリウォッチ画面７０に自動的に反映されることで、選択されたトラブルシュートが再現される。

再び図８を参照して、修理担当者は、評価入力欄６４において各トラブルシュートの評価を入力することができる。より具体的には、修理担当者は、まず、履歴欄６１に表示されているトラブルシュートの中から、評価対象のトラブルシュートを選択する。当該選択されたトラブルシュートが役に立った場合には、修理担当者は、高評価を入力するためのボタン６４Ａを押下する。当該選択されたトラブルシュートが役に立たなかった場合には、修理担当者は、低評価を入力するためのボタン６４Ｂを押下する。入力された評価は、上述のアクセス履歴１２４に反映される。

修理担当者は、ボタン６５を押下することで、新たなトラブルシュートを作成することができる。一例として、修理担当者は、メモリウォッチ画面７０に対して追加されたメモリのアクセス先を新たに記憶させることができる。また、修理担当者は、新たに作成したトラブルシュートに対するコメントを入力することができる。トラブルシュートが新たに作成されると、プログラマブル表示器１００は、トラブルシュートナンバーを新たに発行し、当該トラブルシュートナンバーに関連付けて、イベントの種類を表わすイベントナンバーと新たに作成されたトラブルシュートとをアクセス履歴１２４に書き込む。

修理担当者は、ボタン６６を押下することで、履歴欄６１において選択されているトラブルシュートの内容を編集することができる。一例として、修理担当者は、トラブルシュートの実行時に表示されるメモリのアクセス先の編集や、トラブルシュートに対するコメントの編集を行うことができる。トラブルシュートの編集が完了すると、プログラマブル表示器１００は、編集後のトラブルシュートを、対応するイベントナンバーに関連付けた上でアクセス履歴１２４に書き込む。

［Ｅ．変形例］
修理態様の他の例として、修理担当者は、プログラマブル表示器１００に搭載されているプログラムモニタ機能を使用する。プログラムモニタ機能が実行されると、プログラマブル表示器１００は、プログラムモニタ画面を表示する。図１０は、プログラムモニタ画面８０の一例を示す図である。

修理担当者は、プログラムモニタ画面８０に表示されるプログラム（たとえば、ラダープログラム）を確認することで生産装置１０の故障個所などを特定する。プログラムの参照先は、修理担当者の自身の経験やノウハウに依存する。そのため、プログラムのデバッグ過程が修理担当者間で共有されれば、知識がない修理担当者であっても、様々な故障に対応することが可能になる。

そこで、プログラマブル表示器１００は、故障を示す所定のイベントが検知された後に参照されたＰＬＣ上のメモリのアクセス先を監視することで、コントローラに実装されているプログラムのアクセス先を特定し、当該アクセス先を発生したイベントに関連付けて記憶する。このように、プログラマブル表示器１００が監視するメモリのアクセス先は、内部のメモリだけでなく、ＰＬＣなどの外部メモリも含む。

典型的には、プログラマブル表示器１００は、プログラムモニタ画面８０に設定された設定情報を記憶する。これにより、故障時に参照されたプログラムのアクセス先が記憶される。すなわち、故障時に参照されたプログラムのアクセス先が記憶される。プログラマブル表示器１００は、同様のイベント（故障）が新たに発生したときには、当該イベントに関連付けられている設定情報をプログラムモニタ画面８０に反映する。これにより、修理担当者は、前回の修理時に参照されたプログラムのアクセス先を参考にすることができる。

より具体的には、修理担当者が、上述の履歴画面６０（図８参照）の履歴欄６１に表示されているトラブルシュートのいずれかを選択した状態でボタン６３を押下すると、プログラマブル表示器１００は、アクセス履歴１２４（図５参照）を参照して、選択されたトラブルシュートに関連付けられているアクセス情報１２５（図５参照）を特定する。特定されたアクセス情報１２５は、図１０に示されるプログラムモニタ画面８０に表示される。このように、過去のトラブルシュート時に参照されたプログラムのアクセス先がプログラムモニタ画面８０に自動的に反映されることで、選択されたトラブルシュートが再現される。

一例として、トラブルシュートの実行時に反映される設定情報は、プログラムの識別情報８１（たとえば、ファイル名）、プログラムのセクション情報８２、プログラムのスクロール位置８３などが反映される。これにより、トラブルシュート時にモニタされていたプログラムの該当箇所がプログラムモニタ画面８０に表示される。

なお、図１０には、プログラムモニタ画面８０においてラダープログラムが示されているが、生産装置１０のコントローラで使用可能なその他のプログラムが表示されてもよい。

また、上述では、イベント発生時の監視対象がＰＬＣ上に実装されているプログラムである例について説明を行ったが、プログラマブル表示器１００の画面操作履歴などが監視対象であってもよい。より具体的には、プログラマブル表示器１００は、故障を示す所定のイベントが検知された後に参照された内部メモリのアクセス先を監視することで、プログラマブル表示器１００に対する画面操作を監視する。プログラマブル表示器１００は、当該画面操作を発生したイベントに関連付けて記憶する。これにより、プログラマブル表示器１００に対する画面操作がトラブルシュートとして記憶される。

［Ｆ．プログラマブル表示器１００の制御構造］
図１１および図１２を参照して、トラブルシュートの記録処理と、記録したトラブルシュートの実行処理とについて説明する。図１１は、トラブルシュートの記録処理を表わすフローチャートである。図１２は、記録されたトラブルシュートの実行処理を表わすフローチャートである。図１１および図１２に示される処理は、プログラマブル表示器１００の制御装置１０１（図４参照）がプログラムを実行することにより実現される。他の局面において、処理の一部または全部が、回路素子またはその他のハードウェアによって実行されてもよい。

以下では、図１１に示されるトラブルシュートの記録処理と、図１２に示されるトラブルシュートの実行処理とについて順に説明する。

（Ｆ１．トラブルシュートの記録処理）
まず、図１１を参照して、トラブルシュートの記録処理について説明する。

ステップＳ１１０において、制御装置１０１は、上述の検知部１５１（図４参照）として、検知対象の所定のイベントが検知されたか否かを判断する。検知対象のイベントは、予め登録されていてもよいし、ユーザによって任意に設定されてもよい。制御装置１０１は、検知対象の所定のイベントが検知されたと判断した場合（ステップＳ１１０においてＹＥＳ）、制御をステップＳ１２０に切り替える。そうでない場合には（ステップＳ１１０においてＮＯ）、制御装置１０１は、ステップＳ１１０の処理を再び実行する。

ステップＳ１２０において、制御装置１０１は、トラブルシュートの記録指示を受け付けたか否かを判断する。一例として、制御装置１０１は、上述の履歴画面６０（図８参照）のボタン６５に対する押下を検知したことに基づいて、トラブルシュートの記録指示を受け付けたと判断する。ステップＳ１２０において、制御装置１０１は、トラブルシュートの記録指示を受け付けたと判断した場合（ステップＳ１２０においてＹＥＳ）、制御をステップＳ１２２に切り替える。そうでない場合には（ステップＳ１２０においてＮＯ）、制御装置１０１は、制御装置１０１は、ステップＳ１２０の処理を再び実行する。

ステップＳ１２２において、制御装置１０１は、上述の監視部１５２（図４参照）として、コントローラ４００の記憶装置４２０内のアクセス先を監視する。典型的には、制御装置１０１は、メモリウォッチ画面３０（図３参照）やプログラムモニタ画面８０（図１０参照）に設定されるメモリのアクセス先を監視する。

ステップＳ１３０において、制御装置１０１は、トラブルシュートの記録の終了指示を受け付けたか否かを判断する。一例として、制御装置１０１は、トラブルシュートの記録を終了する操作を受け付けたことに基づいて、トラブルシュートの記録の終了指示を受け付けたと判断する。制御装置１０１は、トラブルシュートの記録の終了指示を受け付けたと判断した場合（ステップＳ１３０においてＹＥＳ）、制御をステップＳ１３２に切り替える。そうでない場合には（ステップＳ１３０においてＮＯ）、制御装置１０１は、制御をステップＳ１２２に戻す。

ステップＳ１３２において、制御装置１０１は、検知対象の所定のイベントに関連付けて、ステップＳ１２２で取得されたメモリのアクセス先を記憶する。当該アクセス先は、上述のアクセス履歴１２４（図５参照）に書き込まれる。アクセス履歴１２４は、プログラマブル表示器１００の内部の記憶装置１２０（第２記憶装置）に記憶されてもよいし、「第２の実施の形態」で説明するようにサーバーなどの外部の記憶装置（第２記憶装置）に記憶されてもよい。

（Ｆ２．トラブルシュートの実行処理）
次に、図１２を参照して、記録されたトラブルシュートの実行処理について説明する。

ステップＳ１４０において、制御装置１０１は、トラブルシュートの履歴画面６０（図８参照）の表示指示を受け付けたか否かを判断する。制御装置１０１は、トラブルシュートの履歴画面６０の表示指示を受け付けたと判断した場合（ステップＳ１４０においてＹＥＳ）、制御をステップＳ１５０に切り替える。そうでない場合には（ステップＳ１４０においてＮＯ）、制御装置１０１は、制御をステップＳ１４０の処理を再び実行する。

ステップＳ１５０において、制御装置１０１は、上述の表示制御部１５３（図４参照）として、生産装置１０において発生しているイベントに対するトラブルシュートの履歴画面６０を表示する。このとき、各トラブルシュートは、評価の順に表示される。あるいは、各トラブルシュートは、参照回数の順に表示される。

ステップＳ１６０において、制御装置１０１は、履歴画面６０において表示されているトラブルシュートのいずれかが選択されたか否かを判断する。一例として、制御装置１０１は、履歴画面６０において表示されているトラブルシュートのいずれかが選択されたと判断した場合（ステップＳ１６０においてＹＥＳ）、制御をステップＳ１６２に切り替える。そうでない場合には（ステップＳ１６０においてＮＯ）、制御装置１０１は、ステップＳ１６０の処理を再び実行する。

ステップＳ１６２において、制御装置１０１は、上述のアクセス履歴１２４（図５参照）を参照して、ステップＳ１６０で選択されたトラブルシュートに関連付けられているメモリのアクセス先を特定する。

ステップＳ１６４において、制御装置１０１は、上述の表示制御部１５３として、ステップＳ１６２で特定されたメモリのアクセス先をプログラマブル表示器１００のディスプレイ１０５に表示する。これにより、修理担当者は、前回のトラブルシュート時に参照されたメモリのアクセス先を参考にすることができる。

［Ｇ．プログラマブル表示器１００のハードウェア構造］
図１３を参照して、プログラマブル表示器１００のハードウェア構成の一例について説明する。図１３は、プログラマブル表示器１００の主要なハードウェア構成を示すブロック図である。

図１３に示されるように、プログラマブル表示器１００は、制御装置１０１と、ＲＯＭ（Read Only Memory）１０２と、ＲＡＭ（Random Access Memory）１０３と、通信インターフェイス１０４と、ディスプレイ１０５と、記憶装置１２０とを備える。

制御装置１０１は、プログラマブル表示器１００を制御する。制御装置１０１は、たとえば、少なくとも１つの集積回路によって構成される。集積回路は、たとえば、少なくとも１つのＣＰＵ（Central Processing Unit）、少なくとも１つのＡＳＩＣ（Application Specific Integrated Circuit）、少なくとも１つのＦＰＧＡ（Field Programmable Gate Array）、またはそれらの組み合わせなどによって構成される。

制御装置１０１は、本実施の形態に従う情報処理プログラム１２２などの各種プログラムを実行することでプログラマブル表示器１００の動作を制御する。制御装置１０１は、情報処理プログラム１２２の実行命令を受け付けたことに基づいて、記憶装置１２０からＲＯＭ１０２に情報処理プログラム１２２を読み出す。ＲＡＭ１０３は、ワーキングメモリとして機能し、情報処理プログラム１２２の実行に必要な各種データを一時的に格納する。

通信インターフェイス１０４には、アンテナ（図示しない）などが接続される。プログラマブル表示器１００は、当該アンテナを介して、外部の通信機器との間でデータをやり取りする。外部の通信機器は、たとえば、携帯通信端末３００やサーバーなどを含む。プログラマブル表示器１００は、サーバーなどから情報処理プログラム１２２をダウンロードできるように構成されてもよい。

ディスプレイ１０５は、たとえば、液晶ディスプレイ、有機ＥＬ（Electro Luminescence）ディスプレイ、またはその他の表示機器である。ディスプレイ１０５は、タッチパネルに重ねられており、プログラマブル表示器１００が搭載される生産装置１０に対する各種操作をタッチ操作で受け付ける。

記憶装置１２０は、たとえば、ハードディスク、フラッシュメモリ、外付けの記憶装置などの記憶媒体である。記憶装置１２０は、本実施の形態に従う情報処理プログラム１２２、上述のアクセス履歴１２４（図５参照）などを格納する。情報処理プログラム１２２およびアクセス履歴１２４の格納場所は、記憶装置１２０に限定されず、制御装置１０１の記憶領域（たとえば、キャッシュメモリなど）、ＲＯＭ１０２、ＲＡＭ１０３、外部機器（たとえば、携帯通信端末３００）などに格納されていてもよい。

なお、情報処理プログラム１２２は、単体のプログラムとしてではなく、任意のプログラムの一部に組み込まれて提供されてもよい。この場合、本実施の形態に従う処理は、任意のプログラムと協働して実現される。このような一部のモジュールを含まないプログラムであっても、本実施の形態に従う情報処理プログラム１２２の趣旨を逸脱するものではない。さらに、情報処理プログラム１２２によって提供される機能の一部または全部は、専用のハードウェアによって実現されてもよい。さらに、プログラマブル表示器１００と携帯通信端末３００とが協働して、情報処理プログラム１２２を実行するように構成されてもよい。さらに、少なくとも１つのサーバーが情報処理プログラム１２２の処理の一部を実行する所謂クラウドサービスのような形態でプログラマブル表示器１００が構成されてもよい。

［Ｈ．第１の実施の形態のまとめ］
以上のようにして、プログラマブル表示器１００は、故障を示す所定のイベントが検知された後に参照されたメモリのアクセス先を監視し、当該アクセス先を発生したイベントに関連付けて記憶する。プログラマブル表示器１００は、同様のイベント（故障）が新たに発生したときには、当該イベントに関連付けられているメモリのアクセス先をトラブルシュートとして表示する。これにより、修理担当者は、前回のトラブルシュート時に参照されたメモリのアクセス先を参考にすることができる。

このようなトラブルシュートは、特に、故障が明示的ではない場合に効果的である。明示的ではない故障の一例として、生産装置１０は正常であるが生産動作が異常であるケースが想定される。たとえば、品質が悪い生産品を正常と検知するケースや、検査者が目視で不良品を見つけるケースなどが挙げられる。これは、センサの取り付け角度がずれていたり、汚れが付着しているなどで安定して性能が発揮できないことに起因する。このような異常を、自動的にかつ確実に検出するためには、センサなどの部品のあらゆる状態を監視するセンサ類が新たに必要となる。しかしながら、本実施の形態に従うプログラマブル表示器１００は、修理担当者間で過去のトラブルシュートを共有するだけであるので、このようなセンサ類の追加を必要とせずに生産装置１０の様々な異常に対応することができる。結果として、コストを削減することができる。

また、近年では、労働人口の減少や、ノウハウが十分に伝承されていないことが社会的問題になっており、経験の浅い修理担当が生産装置１０の修理を担当するケースが増えている。本実施の形態に従うプログラマブル表示器１００は、生産装置１０の修理の経験やノウハウを共有することができるので、このような問題を解決することができる。

＜第２の実施の形態＞
［Ａ．概要］
第１の実施の形態に従うプログラマブル表示器１００は、故障を示す所定のイベントが検知された後に参照されたメモリのアクセス先を監視し、当該アクセス先をトラブルシュートとして内部メモリに記憶していた。これに対して、第２の実施の形態に従うプログラマブル表示器１００は、当該アクセス先を外部のサーバー上に記憶する。これにより、様々なプログラマブル表示器１００で生成されたトラブルシュートがサーバー上に収集され、トラブルシュートのデーターベースが生成される。

その他の点については第１の実施の形態に従うプログラマブル表示器１００と同じであるので、以下では、それらの説明については繰り返さない。

［Ｂ．情報処理システム１］
図１４を参照して、第２の実施の形態に従う情報処理システム１について説明する。図１４は、第２の実施の形態に従う情報処理システム１の基本構成を示す模式図である。

図１４に示されるように、情報処理システム１は、たとえば、複数のプログラマブル表示器１００（第１情報処理装置）と、サーバー２００（第２情報処理装置）とで構成されている。プログラマブル表示器１００およびサーバー２００は、互いに通信可能に構成されている。なお、図１４には、情報処理システム１が１つのサーバー２００で構成されている例が示されているが、情報処理システム１は、複数のサーバー２００で構成されてもよい。

上述と同様に、プログラマブル表示器１００の各々は、故障を示す所定のイベントが検知された後に参照されたメモリのアクセス先を監視することで上述のアクセス履歴１２４（図５参照）を生成する。プログラマブル表示器１００の各々は、アクセス履歴１２４をサーバー２００に送信する。サーバー２００は、プログラマブル表示器１００から受信したアクセス履歴１２４をデーターベース２２４に格納する。データーベース２２４は、たとえば、サーバー２００の記憶装置２２０に格納されている。記憶装置２２０は、たとえば、ハードディスク、フラッシュメモリ、外付けの記憶装置などの記憶媒体である。

プログラマブル表示器１００は、故障を示す所定のイベントが新たに検知された場合に、当該イベントに対処するためのトラブルシュートの取得要求をサーバー２００に送信する。サーバー２００は、当該取得要求を受信すると、データーベース２２４を参照して、対応するトラブルシュートを特定し、当該トラブルシュートをプログラマブル表示器１００に送信する。プログラマブル表示器１００は、サーバー２００からトラブルシュートを受信すると、当該トラブルシュートを表示する。

［Ｃ．第２の実施の形態のまとめ］
以上のようにして、第２の実施の形態に従うプログラマブル表示器１００は、故障を示す所定のイベントが検知された後に参照されたメモリのアクセス先を監視し、当該所定のイベントと当該アクセス先とをサーバー２００に送信する。サーバー２００は、プログラマブル表示器１００から受信したアクセス履歴１２４をデーターベース２２４に書き込む。これにより、トラブルシュートがデーターベースとして蓄積され、プログラマブル表示器１００間でトラブルシュートを共有することができる。

今回開示された実施の形態は全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内での全ての変更が含まれることが意図される。

１ 情報処理システム、１０ 生産装置、２９ 監視画面、２９Ａ パーツ画像、３０，７０ メモリウォッチ画面、３１Ａ〜３１Ｅ 項目、３１Ｆ，６３，６４Ａ，６４Ｂ，６５，６６ ボタン、４０ 確認画面、４１ 一覧、４２ 詳細確認ボタン、５０ 詳細確認画面、５１ トラブルシュートボタン、６０ 履歴画面、６１ 履歴欄、６２ コメント欄、６４ 評価入力欄、８０ プログラムモニタ画面、８１ 識別情報、８２ セクション情報、８３ スクロール位置、１００ プログラマブル表示器、１０１ 制御装置、１０２ ＲＯＭ、１０３ ＲＡＭ、１０４ 通信インターフェイス、１０５ ディスプレイ、１２０，２２０，４２０ 記憶装置、１２２ 情報処理プログラム、１２４ アクセス履歴、１２５Ａ〜１２５Ｃ アクセス情報、１２６Ａ トラブルシュートナンバー、１２６Ｂ イベントナンバー、１２６Ｃ アクセス先、１２６Ｄ 評価、１２６Ｅ 参照回数、１２６Ｆ 対応者、１５０ アクセス部、１５１ 検知部、１５２ 監視部、１５３ 表示制御部、１５４ 評価受付部、２００ サーバー、２２４ データーベース、３００Ａ〜３００Ｃ 携帯通信端末、３３０Ａ〜３３０Ｃ 修理担当者、４００ コントローラ。

Claims (10)

1. 情報処理装置であって、
   外部の第１記憶装置内の情報にアクセスすることが可能なアクセス部と、
   生産装置に生じた事象を示すイベントを検知するための検知部と、
   前記検知部によって所定のイベントが検知された後に前記アクセス部によって参照される前記第１記憶装置内のアクセス先を監視し、前記アクセス先を前記所定のイベントに関連付けて内部または外部の第２記憶装置に格納するための監視部とを備える、情報処理装置。
2. 前記情報処理装置は、前記所定のイベントに対するトラブルシュートが実行された場合に、前記所定のイベントに関連付けられている前記アクセス先を前記トラブルシュートとして表示するための表示部をさらに備える、請求項１に記載の情報処理装置。
3. 前記情報処理装置は、前記トラブルシュートに対する評価を受け付けるための評価受付部をさらに備え、
   前記表示部は、前記トラブルシュートに対する前記評価をさらに表示する、請求項２に記載の情報処理装置。
4. 前記表示部は、前記所定のイベントに対するトラブルシュートが複数存在する場合には、当該複数のトラブルシュートを前記評価の順に表示する、請求項３に記載の情報処理装置。
5. 前記表示部は、前記トラブルシュートの参照回数をさらに表示する、請求項２〜４のいずれか１項に記載の情報処理装置。
6. 前記表示部は、前記所定のイベントに対するトラブルシュートが複数存在する場合には、当該複数のトラブルシュートを前記参照回数の順に表示する、請求項５に記載の情報処理装置。
7. 前記情報処理装置は、前記所定のイベントが検知された後に前記第１記憶装置にアクセスしたユーザのスキルの入力を受け付けるためのスキル受付部をさらに備え、
   前記監視部は、前記所定のイベントと前記アクセス先とに関連付けて前記受け付けたスキルを前記第２記憶装置にさらに格納する、請求項１〜６のいずれか１項に記載の情報処理装置。
8. 情報処理システムであって、
   複数の第１情報処理装置と、
   前記複数の第１情報処理装置のそれぞれと通信可能に構成されている第２情報処理装置とを備え、
   前記複数の第１情報処理装置の各々は、
   外部の第１記憶装置内の情報にアクセスすることが可能なアクセス部と、
   生産装置に生じた事象を示すイベントを検知するための検知部と、
   前記検知部によって所定のイベントが検知された後に前記アクセス部によって参照される前記第１記憶装置内のアクセス先を監視するための監視部と、
   前記所定のイベントに関連付けて前記アクセス先を前記第１情報処理装置に送信するための通信部とを含み、
   前記第２情報処理装置は、前記複数の第１情報処理装置の各々から受信した前記アクセス先と前記所定のイベントとを格納するための第２記憶装置を含む、情報処理システム。
9. 情報処理装置における情報処理方法であって、
   生産装置に生じた事象を示すイベントを検知するステップと、
   前記情報処理装置の外部の第１記憶装置内の情報にアクセスするステップと、
   前記検知するステップにおいて所定のイベントが検知された後に、前記アクセスするステップでアクセスされる第１記憶装置内のアクセス先を監視するステップと、
   前記所定のイベントに関連付けて前記アクセス先を前記情報処理装置の内部または外部の第２記憶装置に格納するステップとを備える、情報処理方法。
10. 情報処理装置に実行される情報処理プログラムであって、
    前記情報処理プログラムは、前記情報処理装置に、
    生産装置に生じた事象を示すイベントを検知するステップと、
    前記情報処理装置の外部の第１記憶装置内の情報にアクセスするステップと、
    前記検知するステップにおいて所定のイベントが検知された後に、前記アクセスするステップでアクセスされる第１記憶装置内のアクセス先を監視するステップと、
    前記所定のイベントに関連付けて前記アクセス先を前記情報処理装置の内部または外部の第２記憶装置に格納するステップとを実行させる、情報処理プログラム。