JP2012256178A - 情報処理装置及び情報処理方法及びプログラム - Google Patents

Abstract

【課題】制御プログラムで定義されている制御アルゴリズムを理解しやすい形式で可視化する。
【解決手段】デバイス抽出部１０２は、複数のデバイスが記述されるとともにデバイス間の依存関係が記述され、複数のデバイスの記述とデバイス間の依存関係の記述により複数のデバイスに対する制御アルゴリズムが定義される制御プログラムから、各デバイスの記述を抽出する。依存関係抽出部１０３は、制御プログラムから、デバイス間の依存関係の記述を抽出する。グラフ生成部１１２は、デバイス抽出部１０２により抽出されたデバイスの記述と依存関係抽出部１０３により抽出されたデバイス間の依存関係の記述とに基づき、ノードがデバイスを表し、有向エッジがデバイス間の依存関係を表し、制御プログラムで定義されている制御アルゴリズムをノードと有向エッジとの接続で表す有閉路有向グラフを生成する。
【選択図】図１

Description

本発明は、制御プログラムのデバッグ作業を容易化させる技術に関する。

≪対象とする領域について≫
今日、ＦＡ（ファクトリーオートメーション）システムやＰＡ（プロセスオートメーション）システムではシーケンス制御を行う機器としてプログラミング可能なＣＰＵ機器、すなわち、プログラマブルコントローラ（ＰＬＣ、シーケンサ機器）が用いられている。
ＦＡシステムの制御プログラマ（システムインテグレータや、ＦＡシステムを構成するコンポーネントの装置メーカなど）は、パソコンで動作するＦＡ専用のエンジニアリング環境ソフトウェア上にてシーケンサ機器用の制御プログラムを作成（クロス開発）するのが一般的である。
エンジニアリング環境ソフトウェアは、プログラマが作成した制御プログラムを、シーケンサ機器内で解釈可能な中間言語プログラムにコンパイルし、シーケンサ機器へダウンロードする。
中間言語プログラムがダウンロードされたシーケンサ機器は、その制御プログラムに従って、様々な入出力ユニットやネットワークを介してセンサやモータを制御して、ＦＡ・ＰＡシステムを動作させる。
ＦＡ・ＰＡシステム用の制御プログラムが通常の組込みシステムと異なる点は、プログラミングを行うのがシーケンサ機器のメーカではなく一般エンドユーザであることと、制御プログラムの制御対象がユーザのＦＡシステム内の比較的マクロな要素であること、つまり制御対象は、ＦＡ・ＰＡシステム全体の中で意味のある単位となりうること、が挙げられる。
この意味のある制御対象（変数、デバイス）の単位は、ラベルやシステムラベルと呼ばれることもある。

≪制御プログラムの運用について≫
プログラマが作成する制御プログラムは、国際規格ＩＥＣ６１１３１−３で定義された５言語、インストラクションリスト（ＩＬ）、ラダー（ＬＤ）、ストラクチャードテキスト（ＳＴ）、ファンクションブロックダイアグラム（ＦＢＤ）、シーケンシャルファンクションチャート（ＳＦＣ）などで記述されることが多い。
また、ＣやＣ＋＋などの汎用プログラミング言語で記述されることもある。
ＦＡ・ＰＡシステムは組み込みシステムであり、通常、制御対象は物理的な機械である。
このため、机上で制御プログラムをデバッグするだけでなく、プログラム作成の最終段階、あるいは工場等においてラインを立ち上げる段階において、制御プログラムと制御対象である実機システムとを組み合わせて、動作タイミング等の確認や微調整を行う必要がある。
また、ＦＡ・ＰＡシステムはその性質上、数十年にわたって稼動するものも珍しくない。
しかし、その長期間にわたって制御プログラムが変更されないわけではない。
例えば工場の製造ラインなどの場合は、製造する製品の仕様などの変化に伴って、制御プログラムに少しずつ修正が加えられることがある。
これらの修正過程では、ラインの運用中にシーケンサ機器へエンジニアリング端末を接続して、その場で変更などを行うことも多い。
この調整や変更は、ラダー（ＬＤ）やインストラクションリスト（ＩＬ）という、中間言語とほぼ一対一に対応した、機械語レベルの低級言語により行われることがある。
なぜならば、この作業を行うのは制御プログラマ（装置メーカ）ではなく、機械や製造ラインの専門家（エンドユーザ）であることが多く一般的に高級言語に不慣れなことや、微調整や少しの修正のために上流の設計（高級言語）を変更するのは時間がかかることを理由に、この手順が省略されるためである。
このため、計画的なバックアップ作業を行っていない限り、稼働中の実機システムを動作させている制御プログラムと整合性の取れている「マスタプログラム」が事務所などに保管されていないことがある。
そもそも、稼働中の実機システムのシーケンサ機器内に格納されている中間言語プログラムを「マスタプログラム」と考えているユーザも少なくない。
したがって、ＦＡ・ＰＡシステムにおいて、特に保守時に対象とする制御プログラムは、ＩＬやＬＤなどの機械語レベルの言語で記述されたものを前提として考える必要がある。

≪デバッグ・保守作業の困難性について≫
ＦＡ・ＰＡシステムでは「制御プログラム設計段階における構造化支援」と「制御プログラム試験段階におけるデバッグ効率の向上」と「実機システム運用段階における障害発生時の早急な復旧」が大きな課題となっている。
ＩＥＣ６１１３１−３でも定義されているファンクションブロック（ＦＢ）などを用い、制御プログラムの標準化と構造化を支援しているエンジニアリング環境も数多くあるが、ＦＢを有効に使用できているユーザ（特にエンドユーザ）は多くはないのが実情である。
ＦＢなどを用いた構造化プログラミングを阻害しているのは、制御プログラムのどの部分を切り出して構造化し、再利用可能なプログラム部品として定義すべきかを、プログラミング前にあらかじめ設計しにくいことが原因の一つと考えられる。
実機システムの運用中に発生する、工場の製造ラインを停止してしまうような障害については、復旧に費やされる時間がそのままラインの停止時間になり、エンドユーザの損失に直結するために、早急な復旧が必要である。障害の原因究明に費やされる時間を短縮するため、可読性の高い制御プログラムが必要である。
しかしＦＡ・ＰＡシステムの制御プログラムをＬＤやＩＬにて作成する場合、何千何万行となる「巻物」プログラムを記述することになる。ＬＤやＩＬで記述されたプログラムは構造を持たせにくく、これらは言語仕様上コメント等が入れにくいことなどもあり、他人が見たときに分かりづらいプログラムとなりがちである。ＬＤやＩＬで記述されたプログラムを短時間で正しく解釈するためには、ＬＤやＩＬ言語、制御プログラムに熟練している必要がある。
例えば実機システムの保守時に障害が顕在化したデバイスに注目し、制御プログラムに対して、このデバイスがコイル（出力）となっているラング（ＬＤ言語の回路ブロック）を検索し、そのラングで条件として使用されている接点（入力条件）のデバイス（通常は複数）を特定し、それがコイルとなっているラングを検索し．．．と順を追って検索を行うことで、障害が顕在化したデバイスに影響を与えているデバイスおよび処理を網羅してチェックすることが可能となる。
しかしながら、この方法では、コイル→接点と遡るたびに、探索木の分岐が行われるため、ユーザが途中の状態を記憶しておく必要がある。
また接点とコイルが循環していないか（探索木に繰返しが存在しないか）を随時チェックする必要がある。
なお、制御プログラマは通常、コイルに登場するデバイスを基準に処理を記述する。
つまり、２重コイル（プログラム中の複数個所で同一コイル出力が登場すること）は好まれないことが多い。
しかし、ラダー言語の接点−コイルの関係には、接点デバイスの条件によってコイルに書かれたデバイスのＯＮ／ＯＦＦが同時に定義されており、Ｃ言語などの汎用プログラミング言語に慣れているユーザにとっては分かりづらいところがある。
このため、ＳＥＴ命令やＲＥＳＥＴ命令によって明示的にデバイスのＯＮ／ＯＦＦを記すプログラマも増えてきている。
つまり、この場合は、コイル→接点デバイス検索における毎回の分岐の幅が増えることになり、ユーザに対して更なる負担を強いることになる。

≪先行技術について≫
制御プログラムのデバッグ時の容易化技術として、制御プログラムの解析結果やモニタ結果をＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を用いて可視的にユーザへ提供する技術については、これまでに幾つか開示されている。
例えば、特許文献１では、デバッグを行うための制御プログラムのモニタ方法として、制御プログラムのＳＦＣ言語表現などのフロー図を画面上に表示して、この上に制御プログラムのブロックの活性／非活性状態を表示することなどによって、可視的にモニタ結果が表現される方法が開示されている。
また特許文献２では、ＦＢ言語などによって構造化された制御プログラムを対象として、その制御ブロックの呼出関係をツリー構造に変換し、元の制御プログラムと対応する形で表示する方法が開示されている。
特許文献３では、制御プログラムを走査して出力命令部分について抽出し、利用デバイスの出力が、制御プログラム全体のどの位置で実行されているのかを示すアウトラインを作成することで、デバッグの容易化を実現する方法について開示している。
特許文献４では、障害発生時に原因となるデバイスの特定のために、１画面中に表示可能なＬＤ言語形式の情報量を増やすため、ＬＤ言語表示には簡略形式で制御プログラムを表示して、別の詳細画面内に、関連する詳細情報を表示する方法について開示している。
以上のようにいずれも、制御プログラム自体や、制御プログラム内でのデバイス検索結果を、ＳＦＣ言語やＬＤ言語の形式もしくはそれに類似したアウトライン形式で表示することによって、制御プログラムのデバッグ作業を容易化させる技術である。

また、一般的なプログラムの解析技術として「フローグラフ」がある。
これはプログラムスライシング技術（非特許文献１）等で使用されるプログラム内の処理（制御）間の依存関係を有向グラフにて表したものである。

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

「プログラムスライシング技術と応用」、ＩＳＢＮ４−３２０−０２７４３−４、下村隆夫、共立出版、１９９５

上述したように、制御プログラムはその性質上、実機システム内で稼働中の機械語レベルのコードをマスタプログラムと考えることが多い。またそれらの機械語レベルの中間コードと整合性のとれた、より可読性の高い上級言語プログラムや内部仕様書がユーザの元に存在するとは限らない。
このことからＦＡ・ＰＡシステムを対象とする場合、その制御プログラムはＬＤやＩＬ言語で記述されていることを前提とする必要がある。
しかし一方で、ＬＤやＩＬなどの機械語レベルのコードをプログラミングすることや、これらのコードのみを使用してデバッグや障害発生時の原因究明を短時間で行うには、熟練した技術が必要である。
つまり、ＦＡ・ＰＡシステムの課題として「ＬＤやＩＬ言語などの機械語レベルの言語をターゲットとしながら、それを熟練者でないユーザでも短時間でデバッグや障害要因の究明を行えるようにする」という課題がある。

本発明は、このような課題を解決することを主な目的としており、制御プログラムで定義されている制御アルゴリズムを理解しやすい形式で可視化するグラフを生成することを主な目的とする。

本発明に係る情報処理装置は、
複数のデバイスが記述されるとともにデバイス間の依存関係が記述され、前記複数のデバイスの記述とデバイス間の依存関係の記述により前記複数のデバイスに対する制御アルゴリズムが定義される制御プログラムから、各デバイスの記述を抽出するデバイス抽出部と、
前記制御プログラムから、デバイス間の依存関係の記述を抽出する依存関係抽出部と、
前記デバイス抽出部により抽出されたデバイスの記述と前記依存関係抽出部により抽出されたデバイス間の依存関係の記述とに基づき、ノードがデバイスを表し、有向エッジがデバイス間の依存関係を表し、前記制御プログラムで定義されている制御アルゴリズムをノードと有向エッジとの接続で表す有閉路有向グラフを生成するグラフ生成部とを有することを特徴とする。

本発明によれば、制御プログラムで定義されている制御アルゴリズムをノードと有向エッジとの接続で表す有閉路有向グラフを生成する。
このため、制御プログラムで定義されている制御アルゴリズムを理解しやすい形式で可視化することができ、制御プログラムのデバッグ作業等を容易にすることができる。

実施の形態１〜３に係る情報処理装置の構成例を示す図。 実施の形態１に係る情報処理装置のグラフ表示動作のフローチャート図。 実施の形態１に係る情報処理装置の対応制御部分プログラム表示動作のフローチャート図。 実施の形態１に係る情報処理装置の特定デバイス仕様出力動作のフローチャート図。 実施の形態１に係る情報処理装置の影響範囲図示動作のフローチャート図。 実施の形態１に係る情報処理装置の未使用箇所検出動作のフローチャート図。 実施の形態１に係る情報処理装置の循環定義検出動作のフローチャート図。 実施の形態１に係る情報処理装置のデバイス値モニタ動作のフローチャート図。 実施の形態１に係る情報処理装置の障害可能性要因図示動作のフローチャート図。 実施の形態２に係るＬＤ言語による制御プログラムの例を示す図。 実施の形態２に係る制御プログラムのグラフ表示例１（模式図）を示す図。 実施の形態２に係るノード構造体の例を示す図。 実施の形態２に係るエッジ構造体の例を示す図。 実施の形態２に係る接続情報の例を示す図。 実施の形態３に係る制御プログラムのグラフ表示例２（模式図）を示す図。 実施の形態３に係る影響範囲図示のグラフ表示例（模式図）を示す図。 実施の形態３に係る循環定義検出のグラフ表示例（模式図）を示す図。 実施の形態２に係る制御プログラム例のＩＬ言語表現を示す図。 実施の形態１〜３に係る情報処理装置のハードウェア構成例を示す図。

実施の形態１．
≪概要≫
まず、本実施の形態に係る情報処理装置の動作の概要を説明し、その後、構成例及び動作手順の詳細を説明する。

本実施の形態に係る情報処理装置は、制御プログラムで制御される変数（デバイス）を抽出してノードとし、デバイス間の相互作用を依存関係として抽出してエッジとすることで、制御プログラムを有閉路有向グラフとしてみて、その構造を保持することで、制御プログラム設計時あるいは保守時に、ユーザ作業の効率化、作業の時間短縮を支援する。
また、本実施の形態に係る情報処理装置は、例えば、制御プログラム設計時に制御プログラム内で使用されているデバイス間の関係を、ＧＵＩにて可視的に表示することや、制御プログラム保守時にＧＵＩにて可視的に表示された依存関係グラフ上にて、デバイス値をモニタする、などの機能を持つ。

ここでは、本実施の形態に係る情報処理装置が対象とする言語の１つとして、ラダー（ＬＤ）言語を説明するとともに、ＬＤ言語で記述された制御プログラムから有閉路有向グラフを生成する例を説明する。

ラダー（ＬＤ）言語は電気回路をモデル化した言語である。
ＬＤ言語では、左右の母線間をラング（回路ブロック）の単位で通常一つの意味のある処理が記述される。
回路ブロックにはその処理に必要な変数（デバイス）が接点やコイルの形で登場する。
したがって、ＬＤ言語はデバイス間の処理を列挙した「処理志向型言語」と考えることができる。
なお、インストラクションリスト（ＩＬ）言語についても、構成する命令は基本的にＬＤ言語の要素と一対一に対応可能である。
しかしながら、制御プログラムの目的は、物理的な機械の駆動や電子デバイスへの電圧付加など、実際の物理的なデバイスへの指示が基本である。
例えば、ある生産ラインにおいて以下の仕様にて制御を行う必要があるとする。
１）センサＡがＯＮで、押しボタンＢ１押下時に、ベルトコンベアＣのモータが正転する
２）センサＡがＯＮで、押しボタンＢ２押下時に、ベルトコンベアＣのモータが逆転する
この制御プログラムを考えた場合、上記の１）の文と２）の文をそれぞれ記述するのがラダー言語（処理指向型言語）である。
ＬＤ言語において１）及び２）の文（処理）が、それぞれラングで表現され、それぞれのラングには、以下のように、Ａ、Ｂ１、Ｃ（正転）およびＡ、Ｂ２、Ｃ（逆転）の３つのデバイス間の関係が記述されることになる。
・センサＡ：ベルトコンベアＣの正転・逆転に影響を与える
・押しボタンＢ１：ベルトコンベアＣの正転に影響を与える
・押しボタンＢ２：ベルトコンベアＣの逆転に影響を与える
・ベルトコンベアＣ（正転）：センサＡ、押しボタンＢ１に影響を受ける
・ベルトコンベアＣ（逆転）：センサＡ、押しボタンＢ２に影響を受ける

上記のように、制御対象であるデバイス間の関係を表現するのが本実施の形態に係る表示形式の考え方であり、本実施の形態では、それを有閉路有向グラフ構造として保持する方法をとる。
前述のとおり、ＦＡ・ＰＡシステムの制御プログラムはその目的が、具体的な「デバイス」を制御することである。
ＬＤ言語やＩＬ言語で記述される制御プログラムのほとんどは「接点→コイル」の組合せで記述され、その単位処理自体は単純なものである。
またＦＡ・ＰＡシステムの制御プログラムは、デバイスに対する操作として間接アドレシング（ポインタ）などを使用することは少ない特徴もある。
基本的に、物理的に実在する機器に対応するものとして各デバイスが定義されるため、デバイスをポインタやインデクスとして使用する例は多くない。

本実施の形態の手法と類似した、一般的なプログラムの解析技術として「フローグラフ」がある。
これは、前述したように、プログラムスライシング技術（非特許文献１）等で使用されるプログラム内の処理（制御）間の依存関係を有向グラフにて表したものである。
フローグラフは一般的なプログラム全てに適用可能であり、本実施の形態に係る情報処理装置が対象とするＦＡ・ＰＡシステムの制御プログラムに対しても定義可能である。
しかし、フローグラフはプログラムの構造を抽象的に表現したものであって、個々のグラフ要素（ノード、エッジ）が具体的な何かに対応するものではない。
またフローグラフのノードは、それ自体が何らかの処理を内包しており、その処理自体の依存関係がエッジとして表現される。
しかしＦＡ・ＰＡシステムの制御プログラムは、通常プログラムの制御の構造が浅い。
つまりＩＦ文やループ文などの構造を持つことがほとんど無い。
これはサイクリック演算によって繰返し実行されることにも起因している。
本実施の形態では、処理間の依存関係を表現する理由が少なく、むしろ変数（デバイス）と処理を明確に分離した方が可視化の際にユーザに理解されやすいと考える。
このように、フローグラフのようなノードとエッジの定義による可視化は、少なくともＦＡ・ＰＡシステムの制御プログラムを対象とする場合には適していない。
そもそも一般的なプログラムの場合は、使用される変数自体が抽象的なものであり、ポインタや配列などを頻繁に使用するため、その変数の実体（メモリ領域）が固定していないことが多い。
このため、本実施の形態で開示するようなグラフ構造を構築するのは困難である。
しかし、対象をＦＡ・ＰＡシステムの制御プログラムに限定した場合は、より詳細なデバイス単位でのグラフ構築が可能になる。
つまり、デバイスをノードとして表現することでそのイメージが固定され、表示される有閉路有向グラフは、実機システムを構成する要素群のイメージに近いものとなる。
本実施の形態は、ＦＡ・ＰＡシステムの制御プログラムのこの特徴を拠りどころとしている。
グラフ表示による可視化は、ユーザに対して制御プログラムの直感的な理解の手助けになると考える。

本実施の形態は、制御プログラム内のデバイス間の関係を一度すべて解析し、有向グラフという形式で、直感的に分かりやすい形で可視化することを特徴としている。
例えばＬＤやＩＬ言語で使われる接点とコイルの関係「Ａ⇒Ｂ」（条件Ａならば結果Ｂ）は、接点とコイルをノードとしたときに、有向エッジによって表す方法が最も簡単であり、これ以上簡略また有効な可視化方法はない。
本実施の形態で開示する有閉路有向グラフは、ＦＡ・ＰＡシステムの制御プログラムの設計フェーズおよび保守フェーズにて有用である。
前者については、対象となる制御プログラムの解析を行うことより、プログラムの構造化・再利用化の支援となる。また後者については、グラフ上でモニタを行うことで、視覚的にデバッグ作業を実施することが可能となるほか、制御プログラム全体に対して問題箇所（バグ）を最小の手順で見つけ出すことを容易にするため、障害発生時の早急な原因究明の支援となる。

≪構成の説明≫
以降に、図１を用いて、本実施の形態に係る情報処理装置１００の構成例を説明する。

図１において、制御プログラム中間コード記憶部１０１は、ＦＡ・ＰＡシステムの制御プログラムが格納されているメモリである。
制御プログラム中間コード記憶部１０１で記憶されている制御プログラムのソースコードはどのような言語で記述されていても良い。
なお、制御プログラム中間コード記憶部１０１で記憶されている制御プログラムの中間コードは、制御プログラム中間コード１０１０と表記する。
この制御プログラム中間コード１０１０は、ＦＡ・ＰＡシステムのエンジニアリング開発環境により、ユーザのプログラミングによって作成されたソースコードをコンパイルした結果である。
後述するように、この制御プログラムは作成中である場合と全て完成されている場合がある。
通常この制御プログラム中間コード１０１０はエンジニアリング環境のコンパイル生成物であり、シーケンサ機器にダウンロードされる対象でもある。
前述したように、制御プログラム中間コード１０１０には、複数のデバイスが記述されるとともにデバイス間の依存関係が記述され、複数のデバイスの記述とデバイス間の依存関係の記述により複数のデバイスに対する制御アルゴリズムが定義される。

デバイス抽出部１０２は、制御プログラムの中で使用されているデバイスの記述を抽出する。
抽出されるデバイスは、制御プログラムがＬＤ言語の場合は接点デバイスやコイルデバイスであり、ＩＬ言語である場合はオペランドとして指定するソースデバイスやデスティネーションデバイスである。
デバイス抽出部１０２で抽出されたデバイスは、ノード情報としてノード構造体記憶部１０４に格納される。
デバイスの抽出は、例えば制御プログラムの設計段階においては、ユーザが制御プログラムを作成し、意味のある単位（ＬＤ言語では例えばラング）を作成するたびに抽出処理をおこなってもよいし、例えば実機システムの保守段階においては、障害が発生した段階で、稼働中の制御プログラム全体に対して一括して行ってもよい。

依存関係抽出部１０３は、制御プログラムの中のデバイス間の依存関係の記述を抽出する。
抽出される依存関係は、制御プログラムがＬＤ言語の場合は、例えば接点で指定されたデバイスＡとコイルで指定されたデバイスＢの間の依存関係や、比較条件Ｃと演算対象Ｄの間の依存関係である。
依存関係抽出部１０３で抽出された依存関係は、エッジ情報としてエッジ構造体記憶部１０５に格納される。
依存関係の抽出は、例えば制御プログラムの設計段階においては、ユーザが制御プログラムを作成し、意味のある単位（ＬＤ言語では例えばラング）を作成するたびに抽出処理をおこなってもよいし、例えば実機システムの保守段階においては、障害が発生した段階で、稼働中の制御プログラム全体に対して一括して行ってもよい。

ノード構造体記憶部１０４は、デバイス抽出部１０２によって抽出されたデバイスの情報を記憶しておく領域である。
ノード構造体記憶部１０４で記憶される情報は、ノード構造体１０４０と表記する。
ノード構造体１０４０では、デバイスに対して、デバイス名あるいは、ユーザによって命名されたラベル名が格納される。
また、ノード構造体１０４０にはモニタを行うためのデバイスの現在値の格納エリアも設けてある。

エッジ構造体記憶部１０５は、依存関係抽出部１０３によって抽出されたデバイス間の依存関係を記憶しておく領域である。
デバイス間の依存関係はいくつか種別がある。
ＬＤ言語を例に取ると例えば、Ａ接点−コイルの関係（Ｄ１⇒Ｄ２）、Ｂ接点−コイルの関係（Ｄ１⇒Ｄ２）、演算式の関係（Ｄ２＝Ｄ１＋１）、条件式の関係（ＩＦ Ｄ１＞０ＴＨＥＮ Ｄ２＝１）などである。
これらの例では全てデバイスＤ２はデバイスＤ１に依存している。
依存関係抽出部１０３では、これらの依存関係の種別と、対象となる２つ以上のデバイスの組合せを抽出する。
依存関係の種別はエッジ構造体１０５０として格納する。
対象デバイスの組合せは、エッジ構造体１０５０もしくは、後述する接続情報１０６０として保存する。

接続情報記憶部１０６は、デバイスを記憶しているノード構造体１０４０と、デバイス間の依存関係を記憶しているエッジ構造体１０５０の間の接続関係を保持しておく記憶領域である。
接続情報記憶部１０６で記憶されている情報を接続情報１０６０と表記する。
接続情報１０６０は、ノード構造体１０４０とエッジ構造体１０５０、つまり、デバイス抽出部１０２で抽出されたデバイスと依存関係抽出部１０３で抽出された依存関係を対応付ける情報である。

グラフ生成部１１２は、デバイス抽出部１０２により抽出されたデバイスの記述と依存関係抽出部１０３により抽出されたデバイス間の依存関係の記述とに基づき、有閉路有向グラフを生成する。
より具体的には、グラフ生成部１１２は、ノード構造体１０４０とエッジ構造体１０５０と接続情報１０６０を用い、接続情報１０６０に示されている対応付けに従って、ノード構造体１０４０のデバイスとエッジ構造体１０５０の依存関係を組み合わせて、有閉路有向グラフを生成する。
有閉路有向グラフは、ノードがデバイスを表し、有向エッジがデバイス間の依存関係を表し、制御プログラムで定義されている制御アルゴリズムをノードと有向エッジとの接続で表すグラフである。
有閉路有向グラフの例は、後述する。

条件入力部１０７は、グラフ生成部１１２で生成された有閉路有向グラフに対して、グラフ内の要素を検索するための条件やフィルタリングするための条件をユーザがＧＵＩを通して入力する手段である。
例えばＧＵＩによって表示されたグラフに対して、その任意のノードを指定することでノードが特定される。
またはグラフに対して、任意の領域を選択することで、そのデバイス群が選択される。

グラフ解析部１０８は、用途に応じて有閉路有向グラフをグラフ解析するエンジン部分である。
例えば、条件入力部１０７で選択されたデバイス群「が」影響を与え得る範囲（当該デバイス群から有向エッジを介して到達可能なノード全て）を抽出することや、逆に条件入力部１０７で指定されたデバイス「に」影響を与え得る範囲（当該デバイスから有向エッジを逆向きに介して到達可能なノード）を段階的に抽出するなどを行う。
また、グラフ全体のクラスタ性について計測を行い、制御プログラムのデバイス間の結合度合いを算出する、などを行う。
グラフ解析部１０８は、一般的なグラフ解析ロジックを用いることもできる。

結果出力部１０９は、グラフ全体や、グラフ解析部１０８によってフィルタリングされた部分グラフをＧＵＩを通してユーザに表示する手段である。
ＦＡ・ＰＡシステムの制御プログラムで用いられるデバイスの数や処理の数は膨大なものになりうるため、本実施の形態で開示している有閉路有向グラフも大規模なものになる可能性がある。
このため、この結果出力部１０９にはグラフの拡大縮小表示機能や、選択デバイス／依存関係のみを表示する機能、あるいは選択されたデバイス群を縮約して、単一な仮想デバイスとして表示する機能などを持つことができる。
結果出力部１０９の一部機能は、一般的な複雑グラフ表示技術やツールを用いることもできる。
結果出力部１０９は表示部の例である。

リンク管理部１１０は、制御プログラムのコードと、それを変換した有閉路有向グラフの要素（ノード：デバイス、エッジ：ラング（ＬＤの場合））を対応付ける手段である。
リンク管理部１１０は、ＧＵＩを通してユーザに表示されるグラフと、元の制御プログラムコードを対応付けるために用いられる。
例えばグラフのノードを選択すると、それに対応するデバイスが、元の制御プログラムコードの中から検索され、当該デバイスが使用されている全てのラング（ＬＤの場合）が一覧表示される。またエッジを選択すると、それに対応するラング（ＬＤの場合）が表示される。
リンク管理部１１０は、これらの機能を実現するために使用される。
リンク管理部１１０はプログラムコード抽出部の例である。

オンラインモニタ部１１１は、実際のシーケンサ機器と通信を行って、デバイスの現在値を取得する手段である。
ここで取得されたデバイス値は、グラフ表示を用いて現在値モニタを行う際に結果出力部１０９を介してＧＵＩ表示される。
一般的なＦＡ・ＰＡシステムのエンジニアリング開発環境は、既存のプログラミング言語エディタ上にてデバイスのオンラインモニタ機能を実現しているものが多い。
したがって、オンラインモニタ部１１１は、このオンラインモニタ機能で使用しているデバイス値取得機能部分を流用してもよい。
オンラインモニタ部１１１は計測値入力部の例である。

≪動作の説明≫
≪１．グラフの表示≫
制御プログラム内で使用されているデバイス間の関係をＧＵＩにて可視的に表示する手順について図２をもとに以下に述べる。

まず、処理２０２にて、ユーザが制御プログラムを入力する。
続いて、処理２０３にて、コンパイルを実行する。
しかし、コンパイル可能な単位の入力が完了していない場合は、再び処理２０２に戻って、制御プログラムの入力を待つ。
コンパイル可能な単位での入力が完了したら、コンパイル操作によって制御プログラム中間コード１０１０を作成する。
ここまでの処理は一般的なＦＡ・ＰＡシステムのエンジニアリング環境が持つ機能を流用することもできる。

続いて、処理２０４にて、デバイス抽出部１０２が制御プログラム中間コード１０１０からデバイスの抽出を行う。
これにより対象とする制御プログラムの全体あるいは部分で使用されるデバイスの一覧が取得できる。
これらのデバイス情報はノード構造体１０４０としてノード構造体記憶部１０４に格納される。
この際、デバイスに関する種々の情報（例えばデバイス種別やラベル名など）も格納する。
同様に、処理２０５にて、依存関係抽出部１０３が制御プログラム中間コード１０１０から依存関係の抽出を行う。
これにより対象とする制御プログラムの全体あるいは部分で処理されているデバイス間の依存関係が抽出される。
これらの情報はエッジ構造体１０５０としてエッジ構造体記憶部１０５に格納される。
エッジ構造体１０５０には後述するように、グラフ解析に利用するための、正論理／負論理の情報なども格納する。
ここでもエッジに関する種々の情報（例えばエッジのタイプなど）も格納する。
同様に、処理２０６にて、依存関係抽出部１０３が制御プログラム中間コード１０１０とエッジ構造体１０５０から、接続情報１０６０を構築する。
次に、処理２０７にて、ノード構造体１０４０とエッジ構造体１０５０の間の接続関係を表す接続情報１０６０およびそれにリンクしたノード構造体１０４０とエッジ構造体１０５０から、グラフ生成部１１２が有閉路有向グラフを生成し、結果出力部１０９が表示する。
これらの処理を処理２０１と処理２０８間で繰り返す。
このループは制御プログラムの作成が完了するまで繰り返される。

上記の流れ以外にも、制御プログラムのコンパイルが完了したことをトリガとして、デバイスの抽出処理２０４を開始する方法を取ることもできる。
また制御プログラムを保存したタイミング、シーケンサ機器へダウンロードしたタイミングをトリガとする方法もとることができる。
また、処理２０３のコンパイル時に、前回のコンパイル結果との照合を行い、修正のあった箇所についてのみ処理２０４以降の処理を行うことで、差分描画処理を行うこともできる。

≪２．対応制御部分プログラム表示≫
ＧＵＩにて可視化されたグラフの要素（ノード／エッジ）を選択することで、対応する元の制御プログラムの要素の検索結果を表示する手順について、図３をもとに以下に述べる。

まず、処理３０１にて、グラフを構築する（接続情報１０６０構築）段階で、デバイス抽出部１０２及び依存関係抽出部１０３が、元の制御プログラムの各要素とグラフの要素（ノード／エッジ）とのリンクを作成する。
グラフのノードと元の制御プログラムのデバイス間のリンク情報はノード構造体１０４０に、構造体の要素として格納される。
また、グラフのエッジと元の制御プログラムの処理（ＬＤ言語であればラング）間のリンク情報はエッジ構造体１０５０に、構造体の要素として格納される。
これにより、表示されるグラフの各要素が元の制御プログラムの要素と関連づいた状態となる。
処理３０２により、ユーザがＧＵＩに表示されたグラフの要素を選択する。
すると処理３０３において、グラフ解析部１０８により、そのグラフ要素がノードであるかエッジであるかが判別される。
ノードである場合は処理３０４にて、リンク管理部１１０により、ノード構造体１０４０とそこからリンクを辿った先の制御プログラム中間コード１０１０から、該当ノードが表すデバイスを使用した全ての処理（ＬＤ言語であればラング）が検索される。
エッジである場合は処理３０５にて、リンク管理部１１０により、エッジ構造体１０５０とそこからリンクを辿った先の制御プログラム中間コード１０１０から、該当エッジが表す処理（ＬＤ言語であればラング）が抽出される。
最後に、処理３０６にて、結果出力部１０９により、処理３０４もしくは処理３０５で抽出した制御プログラム中間コード１０１０が表示される。
この表示は、例えば、グラフと制御プログラム中間コード１０１０とを並べて表示することが考えられる。

処理３０４および処理３０５によりグラフ上の対応要素が特定され、制御プログラム中間コード１０１０内の対応要素が特定された後は、一般的なエンジニアリング環境で実現されている検索結果表示機能を用いて、対応する制御プログラム検索結果表示処理３０６を行うこともできる。

≪３．特定デバイス仕様出力≫
ＧＵＩにて可視化されたグラフの特定ノードを選択することで、当該ノードの仕様を日本語（自然言語の一例）にて表示する手順について、図４をもとに以下に述べる。

まず、処理４０１にて、ユーザによってＧＵＩに表示されたグラフから、対象となるノードが選択される。
次に、処理４０２にて、グラフ解析部１０８によるグラフ解析により、指定されたノードに至る全てのパスを構成するノード、エッジを含む部分グラフを抽出する。
つまり、グラフ解析部１０８は、指定されたノードに影響を与える可能性のあるノードとエッジを全て抽出する。
この処理は対象ノードから全ての有向エッジを逆向きに辿り、見つかったノードとエッジを部分グラフに追加していき、新しいノードが見つからなくなるまで続けることで実行可能である。
これは一般的なグラフ解析ロジックを用いてもよい。
処理４０３にて、グラフ解析部１０８は、作成した部分グラフ内で入出力デバイスを表現しているノードのみを抽出する。
これは特定デバイスの仕様を出力する際に、実機システムとのインタフェースとしてユーザに分かりやすいデバイスを表示する意味がある。
しかし、入出力デバイスに限定する必要はなく、内部デバイスに対しても実行してもよい。
また、この処理を行うため、ノード構造体１０４０にはあらかじめ対応するデバイスの種別情報を格納しておく必要がある。
入出力デバイスそれぞれについて処理を行うため、処理４０４から処理４０７でループ処理を行う。
この内部では、処理４０５にて、グラフ解析部１０８は、対象となる入出力デバイスから出ている有向エッジについて日本語へ変換する。
例えば、特定デバイスが「モータＣ（正転）」であり、対象となった入力デバイスのラベル名が「センサＡ」であり、そこから出る有向エッジのタイプが「Ａ接点−コイル」だとすると、「モータＣ（正転）はセンサＡに依存する」という説明文が作成される。
また、もう一つの入力デバイスのラベルが「非常停止ボタンＢ」であり、エッジのタイプが「Ｂ接点−コイル」だとすると、「モータＣ（正転）は非常停止ボタンＢに依存する」という説明文が作成される。
処理４０６にてこれらの説明文が、結果出力部１０９により、一文ずつユーザに提示される。
処理４０５にて、入出力デバイスに隣接するエッジのみを考慮に入れているが、これは出力される仕様の文章を単純化するためである。
より厳密に、入出力デバイスから特定デバイスに至るパスを有向エッジに沿った形で連ね、全て日本語化することも可能である。
また、逆に、４０５の処理は割愛し、入出力デバイスのみを持って、簡単な仕様として表示する方法もある。
この場合は入出力デバイスに隣接するエッジの情報は使用されず、一様に「［入出力デバイス］に依存する」という記述になる。

≪４．影響範囲図示≫
ＧＵＩにて可視化されたグラフの特定領域を選択することで、それらの範囲に変更を行った場合の、制御プログラムに与える影響範囲を図示する手順について、図５をもとに以下に述べる。

まず、処理５０１にて、ユーザによってＧＵＩに表示されたグラフから、対象となる領域（部分グラフ）が選択される。
次に、処理５０２にて、グラフ解析部１０８が、グラフ解析により、指定された領域に至る全てのパスを構成するノード、エッジを含む部分グラフを抽出する。
この処理は対象領域内にある全てのノードについて、そのノードに隣接する有向エッジを逆向きに辿って、見つかったノードとエッジを部分グラフに追加していき、新しいノードが見つからなくなるまで続けることで実行可能である。
この処理により、グラフ解析部１０８は、ユーザによって指定された対象領域内の要素（指定要素）に変更があった場合に当該変更の影響を受ける影響範囲を抽出することができる。
なお、この影響範囲の抽出処理は、一般的なグラフ解析ロジックを用いてもよい。
処理５０３にて、結果出力部１０９が、既に表示されている全体グラフの中で、作成した部分グラフについて強調表示等を行って、影響範囲が分かるようにする。

なお、ここでは、結果をグラフ上に図示する例のみを載せているが、制御プログラム中間コード内の処理（ＬＤ言語ではラング）を表示する方法も取ることができる。

≪５．未使用箇所検出≫
ＧＵＩにて可視化されたグラフ上で、制御プログラム内のどの出力デバイスにも影響を与えないデバイス群（未使用デバイス群）を図示する手順について、図６をもとに以下に述べる。

まず処理６０１から処理６０３にて、全ての出力デバイスについて繰り返す。
処理６０２にて、グラフ解析部１０８が、グラフ解析により、出力デバイスへ至る全てのパスを構成するノード、エッジを含む部分グラフを抽出する。
この処理は出力デバイスを表すノードについて、そのノードに隣接する有向エッジを逆向きに辿って、見つかったノードとエッジを部分グラフに追加していき、新しいノードが見つからなくなるまで続けることで実行可能である。
これは一般的なグラフ解析ロジックを用いてもよい。
また、この部分は前述した影響範囲図示と同じアルゴリズムを流用することもできる。
また出力デバイス以外にも外部システムとのインタフェースとなるデバイスが存在する可能性がある。
これらについて、ユーザが任意にデバイス群を指定する、あるいはデバイス種別を選択することができても良い。
処理６０４にて、グラフ解析部１０８は、既に表示されている全体グラフの中から、処理６０３にて抽出した部分グラフに含まれない、全てのノード（未使用デバイス）とエッジを抜き出す。
また未使用デバイスのみを一覧表示するため、ここで抜き出す要素をノードのみに限っても良い。
そして、処理６０５にて、結果出力部１０９が、これらの部分グラフ群を強調表示する。

なお、ここでは、結果をグラフ上に図示する例のみを載せているが、制御プログラム中間コード内の処理（ＬＤ言語ではラング）を表示する方法も取ることができる。

≪６．循環定義検出≫
ＧＵＩにて可視化されたグラフ上で、制御プログラム内でソフトウェアによるチャタリング（特定のデバイスがサイクリック時間（の定数倍）ごとにＯＮとＯＦＦを繰り返す現象）を起こす危険性のあるデバイスの組合せを検出する手順について、図７をもとに以下に述べる。
この現象は通常、本実施の形態で開示している有向グラフ表現において、循環（エッジの向きを考慮した閉路）があり、その循環のパス上で奇数回の負論理回路が存在するときに発生する可能性がある。
ただし、タイマデバイスやカウンタデバイスなど、条件が満たされてからコイルがＯＮとなるまでに遅延があるものは対象外とする。

まず、処理７０１にて、グラフ解析部１０８は、任意のビットデバイスを開始地点として対象ノードとする。
上記したように、対象ノードにはタイマやカウンタなど、状態を持つことで条件ＯＮからコイルＯＮまでに時間的遅延が発生するものは対象としない。
次にグラフ内のノードを探索するため、処理７０２および処理７０３から処理７０８にて、グラフ解析部１０８はグラフ内の探索を行う。
ここでの目的は、タイマやカウンタを含まず、負論理が奇数回登場する循環定義を検出するため、処理７０４にて負論理に相当するエッジ（処理）の数をカウントする。
この時に必要となるそのエッジが負論理であるかどうかの情報は、先に述べた「依存関係の抽出」処理２０５にて、エッジ構造体１０５０内に格納しておく。
次に、グラフ解析部１０８は、探索中に経由するノードについて、処理７０５にて、カウンタやタイマにたどり着いたかどうかチェックを行う。
カウンタやタイマを経由する場合は、循環定義として抽出しない（サイクリック時間とは異なったユーザ定義値を基準にしてデバイスのＯＮ／ＯＦＦが切り替わるため、正常な動作と考えられるため）。
しかし、実装する機能としては、ユーザへ循環定義抽出結果にカウンタやタイマを含むことを知らせた上で、条件分岐処理７０５を除くこともできる。
次に処理７０６にて、グラフ解析部１０８は、循環を形成するかどうかチェックを行う。
現時点までの探索経路内に訪れたノードに至った場合は循環（閉路）が存在することになるため、処理７０７にてその循環パスを記録する。
最後に、グラフ解析部１０８は、処理７０９にて、記録した循環パスの負論理の数が奇数のものについて、循環定義によってソフトウェアによるチャタリングが発生する危険性がある循環定義として抽出する。
そして、処理７１０において、結果出力部１０９が、該当するパスを図示する。

図７は対象とする制御プログラムおよびそれを表現しているグラフが連結していることを前提としている。
制御プログラムがいくつかの独立した部分グラフから構成される場合は、それぞれ独立した部分グラフ内で、処理７０１によって一つの開始ノードを選択する必要がある。
なお、処理７０２から処理７０８までに記述したグラフ内の探索手順は一例であり、その他のグラフ解析アルゴリズムを用いてもよい。

≪７．デバイス値モニタ≫
ＧＵＩにて可視化されたグラフ上で、ユーザが現在値モニタを行いたいデバイス群を指定し、シーケンサ機器、あるいは制御プログラムシミュレータと接続時に、それらのデバイスの現在値をモニタする手順について、図８をもとに以下に述べる。

まず、処理８０１にて、ＧＵＩにて可視化されたグラフ上で、ユーザがモニタを行いたい任意のデバイス群を選択する。
ただし、制御プログラム内の全てのデバイス、あるいは画面表示された全てのデバイスを対象とする場合は、ユーザからの指定は不要である。
次に、選択されたデバイスについて、処理８０２から処理８０５までを繰り返す。
処理８０３では、オンラインモニタ部１１１が、対象デバイスそれぞれについて、シーケンサ機器または制御プログラムシミュレータから、対応するデバイスの現在値を取得してノード構造体１０４０へ格納する。
続いて処理８０４にて、結果出力部１０９が、グラフのノード上にテキストとして、あるいはノードの形状変更、あるいはノードの色変更等によって、ノードが表現するデバイスの現在値を表示する。

なお、モニタを定期的に行う場合は、例えば１秒毎に処理８０２から処理８０５までの処理を繰り返すことで実現が可能である。
また、シーケンサ機器や制御プログラムシミュレータから、デバイスの現在値だけでなく、制御プログラム内のどの処理が実行されたのかが取得可能であれば、オンラインモニタ部１１１が、エッジ構造体１０５０に処理実行中フラグを設定／解除することによりグラフ上に表示することもできる。

≪８．障害要因の図示≫
実機システムあるいは制御プログラムシミュレータ上にて、障害が発生した場合、その要因となる制御プログラム上のバグを特定するため、ＧＵＩにて可視化されたグラフ上で、ユーザにより障害が顕在化しているデバイス、また完全に正常に動作しているデバイスを特定することで、障害の要因となるデバイスあるいは処理を図示する手順について、図９をもとに以下に述べる。

まず、処理９０１にて、グラフ解析部１０８が、初期処理として要因領域を空に設定する。
要因領域は、障害の要因の候補としてグラフ上に示す要素を格納する領域である。
以降処理９０２から処理９０９までは、ユーザが障害要因を特定するまで繰返し実行する。
処理９０３にて、ユーザは障害が発生した時に、その現象が直接現れたデバイス、あるいは確実に異常な振舞いをしているデバイスを指定し、それが「異常」デバイスであることを入力する。
グラフ解析部１０８は、処理９０４にて、全体グラフから、ユーザが指定したデバイスのノード（異常発生デバイスノード）に至るパス全てをマージした部分グラフを抽出する。
つまり、グラフ解析部１０８は、異常発生デバイスノードと接続している有向エッジを有閉路有向グラフから抽出するとともに、抽出した有向エッジと接続しているノード（デバイス）を抽出する。
この処理は前述した５０２の処理と同じである。
次に、処理９０５にて、グラフ解析部１０８は、抽出したデバイスの正常／異常をチェックする。
デバイスごとの正常／異常は、ユーザが指定する。
ユーザから「正常」と指定されたデバイスについては、処理９０６にて、現時点の要因領域から、抽出した部分グラフを削除する（「正常」と指定されたデバイスのノードと当該ノードに接続しているエッジを要因領域に含めない）。
これは障害要因が含まれる可能性がある要因領域のうち、全ての条件において完全に正常であると判断されたデバイスに影響を与える領域については、要因領域から除くことができるためである。
反対に、ユーザから「異常」と指定されたデバイスについては、処理９０７にて、現時点の要因領域に抽出した部分グラフを追加する（「異常」と指定されたデバイスのノードと当該ノードに接続しているエッジを要因領域に含める）。
これは障害要因が含まれる可能性がある要因領域が拡大するためである。
ここでは障害要因が１つであるとは限らないため、９０７の処理において抽出した部分グラフとその時点の要因領域のＡＮＤを取ることはしていない。
次に、処理９０８にて、結果出力部１０９が、その時点での要因領域をグラフ上に強調表示する。
これにより障害の要因と考えられるデバイスおよび処理を絞り込むことが可能となる。

また、処理９０７にて部分グラフとその時点の要因領域のＡＮＤ領域に相当する部分について、色変更や形状変更などにより要因領域全体と区別して表示することも可能である。
これにより、より要因が存在する可能性が高い領域を絞り込むことが可能である。

実施の形態２．
≪グラフ表示の例≫
ここでは、ＬＤ言語で記述されたＦＡシステム用の制御プログラムがどのように有閉路有向グラフへ変換され、それが表示されるのかについて、具体例をもって説明する。

図１０は、ＦＡシステム用の制御プログラムの例であり、ＬＤ言語により記述されている。
この制御プログラムは次のような仕様で動作する。
なお、図１８は、図１０の制御プログラムをＩＬ言語で記述したものである。
ａ）入力（開始ボタン）を押下すると出力（ランプ）が点灯する。
ｂ）出力（ランプ）は３秒間点灯する。
ｃ）３回実行すると、入力（開始ボタン）には反応しなくなる。
ｄ）入力（リセットボタン）を押下するとデバイス値をリセットして最初の状態へ戻る。
ｅ）入力（開始ボタン）は押し続ける必要はなく、内部デバイスは自己保持する。

以下にＬＤプログラムを示した図１０について説明する。
１０００は上記した１）から５）の仕様を満たす制御プログラムの例である。

まず、最初のラング（回路ブロック）にて内部デバイスのコイル１００４の定義を行っている。
内部デバイス１００４は、出力（ランプ）を直接定義するための中間的なデバイスである。
上記仕様のａ）にあるように、内部デバイス１００４は、入力（開始ボタン）の押下によってＯＮするため、入力（開始ボタン）のＡ接点１００１が条件となる。
次に、仕様ｃ）にあるように、ボタン押下を３回行って３回実行が完了したとき、またｄ）にあるように入力（リセットボタン）押下されたときは、内部デバイスのコイル１００４がＯＦＦとなることを実現するため、カウンタ１００２のＢ接点１００２と、入力（リセットボタン）のＢ接点１００３をそれぞれＡＮＤ条件とする。
ｅ）にあるように、内部デバイスは自己保持するため、入力（開始ボタン）とＯＲ条件で内部デバイスのＡ接点１００５を付け、ただしこの自己保持はｂ）の仕様から３秒間のみ継続するため、タイマのＢ接点１００６をＡＮＤ条件として付ける。
次に、タイマのコイル１００８と出力（ランプ）コイル１００９の定義を行っている。
これらのコイルは何れも内部デバイスから直接定義されるため、内部デバイスのＡ接点１００７のみを条件とする。
タイマのコイル１００８は、内部デバイス１００７がＯＮになった状態で３秒間経過するとＯＮする。つまり３秒経過した時点でタイマのＢ接点１００６がＯＦＦとなる。
次にカウンタのコイル１０１２の定義を行う。
仕様ｃ）より、カウンタは入力（開始ボタン）を３回押下し、処理が完了したときにカウントアップする必要がある。このため、タイマのタイムアップタイミング（つまりタイマのＡ接点１０１１）をカウンタの条件としている。カウンタ１０１２は、タイマのＡ接点１０１１が３回ＯＦＦからＯＮになったタイミングでＯＮする。
最後のラングでは入力（リセットボタン）１０１３を実現している。
仕様ｄ）を実現するため、入力（リセットボタン）のＡ接点１０１３がＯＮしたタイミングで、カウントアップしているカウンタを０にリセットするため、ＲＥＳＥＴ命令１０１４を使用している。

以上のような制御プログラム１０００がシステム内の制御プログラム中間コード１０１０として格納されている場合の、グラフ表示が行われる流れについて、グラフ表示のフロー２００の中の処理２０４から具体的に説明する。

まず、デバイス抽出部１０２が、デバイスの抽出処理２０４を行う。
これは制御プログラムをスキャンして、使用しているデバイスを抽出することで実現する。
制御プログラム１０００の例では、ノード構造体１０４０として、デバイス一覧１２００（図１２）が抽出される。
ノード構造体例１２００のデバイス（ラベル）名欄には制御プログラムで通常そのデバイスを特定する名称が登録されるが、ここにはデバイスＩＤやラベルＩＤや変数名など、デバイスを一意に特定できるものであればなにを登録しても良い。
また、デバイス種別欄には対象とするシーケンサ機器や制御プログラムで使用できるデバイス種別が格納される。

次に、依存関係抽出部１０３が、依存関係の抽出処理２０５を行う。
これは制御プログラムをスキャンして、各ラングの「条件⇒コイル」の関係を抽出することで実現する。
制御プログラム１０００の例では、エッジ構造体１０５０として、依存関係一覧１３００（図１３）が抽出される。
エッジ構造体例１３００のエッジタイプには、そのエッジが表している制御プログラムの処理のタイプが登録される。
例えば制御プログラム１０００の最後のラングに注目する。
このラングでは入力（リセットボタン）のＡ接点１０１３と、カウンタのＲＥＳＥＴ１０１４との間に依存関係が存在している。
この部分をＩＬ言語で表現すると以下のようになる。
なお制御プログラム１０００をＩＬ言語で表現した例を図１８に載せる。
前述のとおり、一般的にＬＤ言語のプログラム要素とＩＬ言語のプログラム要素は一対一に対応させることができる。
ＬＯＡＤ 入力（リセットボタン） ――― １０１３
ＲＥＳＥＴ カウンタ ―――――――――― １０１４
エッジ構造体１３００の例では、このＩＬ言語の命令を組み合わせてエッジタイプとしている。
上記の例はエッジ構造体１３００の番号９に表されている「ＬＯＡＤ−ＲＥＳＥＴ」がエッジタイプとなる。
このエッジタイプにより、２デバイス間の依存関係の概略を表現することが可能となる。
次に論理の欄は、エッジによって接続される２デバイス間の論理（正論理／負論理）を登録する。
ここでいう論理とは、有向エッジによって表現される処理が、デバイスのＯＮ／ＯＦＦを逆転させるかどうかを表している。このためデバイス種別がビットでない場合（ワードである場合）は無効となる。

次に、依存関係抽出部１０３が、接続情報の構築処理２０６を行う。
これは処理２０４と処理２０５で作成したノード構造体１２００とエッジ構造体１３００の間をリンク付けする処理である。
制御プログラム１０００の例では、接続情報１４００（図１４）が構築される。
接続情報１４００のエッジ欄は接続関係を表現しているエッジ構造体１３００内のエッジの番号を示している。
同様に元ノード欄と先ノード欄は、ノード構造体１２００内のノードの番号を示している。
接続情報で表現されているエッジは必ず有向グラフであるため、元ノード欄と先ノード欄に分けて設定される。
なお、通常エッジ構造体１３００の番号欄と接続情報１４００のエッジ欄は一対一に対応するため、エッジ構造体１３００と接続情報１４００は同一の表として実現してもよい。

最後に、グラフ生成部１１２が有閉路有向グラフの生成・描画処理２０７を行う。
上述した処理２０５までの処理によってグラフ描画のための情報であるノード構造体１２００、エッジ構造体１３００、接続情報１４００は全て作成されている。
このため、グラフ生成部１１２は、接続情報１４００に示されている対応付けに従って、ノード構造体１２００のデバイスとエッジ構造体１３００の依存関係を組み合わせて、有閉路有向グラフの生成・描画を行う。

図１１は、制御プログラム１０００を、本実施の形態に係るグラフ表示方法によって表示した例を模式的に表したものである。
入力デバイスと出力デバイスは矩形、内部のデバイスは円で示している。
また、正論理の処理は実線、負論理の処理は破線で示している。
また、図１１のノード内の（１）〜（６）は、ノード構造体１２００（図１２）に示されている番号を表し、エッジ近傍の（１）〜（９）は、エッジ構造体１３００（図１３）に示されている番号を表している。

ここでは、グラフを構成する要素であるノードとエッジを描画する手順について説明する。
例えばノード（デバイス）の種別毎に画面上で分類をして表示を行いたければ、ノード構造体１２００内のデバイス種別の同じものを集めて画面上へノードを表示する。
ノード構造体１２００のデバイス種別から、入力のデバイスを取得すると、「ビット入力」であるものは入力（開始ボタン）１１０１と入力（リセットボタン）１１０２となる。
同様にノード構造体１２００のデバイス種別から、内部のデバイスを取得すると、「タイマ」「カウンタ」「ビット内部」であるものは、内部デバイス１１０３とタイマ１１０４とカウンタ１１０５となる。
次に、ノード構造体１２００のデバイス種別から、出力のデバイスを取得すると、「ビット出力」であるものは、出力（ランプ）１１０６となる。
次に、接続情報１４００の表の元ノード欄と先ノード欄をチェックして、エッジ番号およびエッジ構造体１３００のエッジタイプや論理を取得する。
これにより、グラフとして表示されるノード間がどのようなエッジで接続されているのかを知り、そのエッジタイプや論理によってエッジの線種などを変更する。
前述のように図１１の例では、エッジ構造体１３００の論理欄から、その処理（エッジ）が正論理の場合は実線、負論理の場合は破線で示している。
接続情報１４００の一行目を見ると、元ノード番号が１、先ノード番号が２でエッジ番号が１であるため、入力（開始ボタン）１１０１と内部デバイス１１０３の間にエッジが存在し、そのエッジはエッジタイプが「ＬＯＡＤ−ＯＵＴ」であり、正論理であることが分かる。
したがって、画面にはグラフとして入力（開始ボタン）１１０１と内部デバイス１１０３の間に、有向エッジとして実線のエッジ１１１０を描画する。
さらに、例えば接続情報１４００の２行目にあるように、自分自身のノードへのエッジの場合は、ループの形でエッジ１１１３を表示する。
このように、エッジ構造体１３００および接続情報１４００内の、エッジ番号１は実線エッジ１１１０、番号２は実線ループエッジ１１１３、番号３は破線エッジ１１１６、番号４は破線エッジ１１１８、番号５は破線エッジ１１１１、番号６は実線エッジ１１１５、番号７は実線エッジ１１１４、番号８は実線エッジ１１１７、番号９は破線エッジ１１１２、にそれぞれ対応する。
このようにして、制御プログラム１０００は、図１１に示すようなグラフ表示が可能となる。

制御プログラム１０００から自動的に図１１のグラフ表示を行うため、図１１のグラフのノードの配置アルゴリズムについては、さまざまな方法をとることができる。
上述したように、ノードの同一な種別を同一領域にまとめて配置する方法や、ノードとして表されたデバイスの番号順や名称順に並べる方法、さらにノードの次数（ノードから出入りするエッジの数）の多い順などが考えられる。
また、エッジによって接続された２つのノードをより近くに表示させる方法などもある。
これらのノードおよびエッジの配置方法については一般的な複雑グラフ表示アルゴリズムを用いることもできる。
また、グラフは２次元平面上だけでなく、３次元空間上に表示させることもできる。
さらに一度表示されたノードおよびエッジはその位置をユーザが自由に変更させることができる。
この場合、一般的なグラフ描画ツールに搭載される機能と同じように、ノードやエッジをマウスによるドラッグ＆ドロップなどの方法で、ユーザの好みの配置へ変更することができる。

実施の形態３．
≪影響範囲図示の例≫
図１５は、ある制御プログラムをグラフ表示した例である。
この制御プログラムは入力ビットデバイスが１５０１、１５０２の２つ、内部ビットデバイスが１５０３、１５０４、１５０５の３つ、出力ビットデバイスが１５０６、１５０７、１５０８の３つから成っている。
実線のエッジは、エッジが表す処理が正論理であることを示し、破線のエッジはエッジが表す処理が負論理であることを示している。

このグラフを使用して、影響範囲図示の例について以下に説明する。

影響範囲図示のフローを示した図５を参照すると、まずユーザによって対象領域の選択処理５０１が行われる。
ここでの例では、ユーザによって出力１のノード１５０６が選択されたとする。
次の５０２の処理にて、グラフ解析部１０８が、対象領域に至る全てのノードを列挙する。
図１５の例の場合、まず対象領域であるノード１５０６に至る隣り合った有向エッジは、エッジ１５１５のみであるため、まずパスとしてこれを加える。
次に、エッジ１５１５の元ノード１５０３に注目する。
このノードへ至る隣り合った有向エッジは、エッジ１５１４とエッジ１５１０であるため、パスとしてこれを加える。
このときエッジ１５１４はノード１５０３へ戻るループであるため、こちらのパスはここで探索を終える。
もう片方のエッジ１５１０の元ノード１５０１に注目する。
このノード１５０１については、このノードへ至る隣り合った有向エッジが存在しないため、ここで探索を終える。
この結果、５０３の処理において強調表示される部分は、図１６に示す領域となる。
つまり出力１のノード１６０６を対象とした場合、このノードに影響を与える範囲としては、図１６内の黒塗り及び太線で示した部分、つまり処理１６１５と、内部１デバイス１６０３と、処理１６１４と、処理１６１０と、入力デバイス１６０１となる。

このように、影響範囲図示のフローの５０２の処理は、グラフについて、有向エッジを逆向きに辿る探索を行うことで全てのパスを抽出することができる。
この際の探索方法は、一般的なグラフ探索アルゴリズムを用いることができる。
探索方法は深さ優先探索でも幅優先探索でもかまわない。
ただし、グラフが有閉路グラフであるため、既に訪れたノードを記憶しておくこと、また有向グラフであるため、エッジの向きを逆向きに探索するという制約がある。

≪循環定義検出の例≫
同様に図１５のグラフを使用して、循環定義検出の例について以下に説明する。

循環定義検出のフローを示した図７を参照すると、まず処理７０１にて、任意のビットデバイスを対象ノードとする。
ここでは例として、入力１のノード１５０１を選択する。
次に、処理７０２にて、グラフ解析部１０８が、対象ノードから出ているエッジを選択する。
図１５の例では、エッジ１５１０とエッジ１５１１が対象となる。
ここから処理７０３にてグラフ内探索を開始する。
ループ内では処理７０４によりエッジの論理をチェックする。
エッジ１５１０とエッジ１５１１は両方とも正論理であるため、カウントアップは行わない。
そして、処理７０５により、グラフ解析部１０８は、次に至るノードがカウンタやタイマであるかどうかを判断する。
エッジ１５１０によって至るノードである内部１ノード１５０３と、エッジ１５１１によって至るノードである内部２ノード１５０４は、両方ともカウンタやタイマではないため、そのまま処理７０６の処理に移る。
次の処理７０６において、この時点で「既に経由したノード」として記憶されているのは、最初に選択した入力１ノードのみであるため、ここで至った内部１ノード１５０３と内部２ノード１５０４と異なり、条件７０６には合致しない。
このため、処理７０４へ戻る。
次に、内部１ノード１５０３に注目し、このノードから出ているエッジ１５１４とエッジ１５１５について判断する。
エッジ１５１４は正論理であるため、処理７０５にてカウントアップは行わないが、エッジ１５１４はループエッジであるため、条件７０６に合致する。
そして、処理７０７にて、循環定義としてそのパスと負論理のカウント値の組「内部１ノード１５０３、エッジ１５１４、カウント０」が保存される。
内部１ノード１５０３から出ているエッジ１５１５の方は、そのまま出力１ノード１５０６へ至り、ノード１５０６から出ているエッジは存在しないため、ここでこの枝の探索は終了する。
次に、内部２ノード１５０４を対象として、同様にグラフ探索を続ける。
すると「内部２ノード１５０４、エッジ１５１７、内部３ノード１５０５、エッジ１５１８、出力３ノード１５０８、エッジ１５１９、カウント１」と、閉路が存在することが分かる。
なおかつこの閉路を構成する３つのエッジのうち、エッジ１５１９のみが負論理の処理を表している。
この結果、処理７０９において、この閉路は循環定義パスのうち負論理が奇数のものに該当する。
なお、先に抽出した「内部１ノード１５０３、エッジ１５１４、カウント０」はカウントが偶数であるため、対象からは外れる。
したがって、処理７１０にて、図１７に示すように循環定義「内部２ノード１７０４、エッジ１７１７、内部３ノード１７０５、エッジ１７１８、出力３ノード１７０８、エッジ１７１９、カウント１」が抽出できる。
よって、この図１５または図１７で表される制御プログラムにおいて、３つのデバイス、内部１、内部２および出力３は、ソフトウェアによるチャタリングを起こす危険性があるということが分かる。

≪実施の形態における効果≫
実施の形態１〜３で開示する方法によれば、制御プログラムで制御される変数（デバイス）を抽出してノードとし、デバイス間の相互作用を依存関係として抽出してエッジとすることで、制御プログラムを有閉路有向グラフとして制御プログラム内で使用されているデバイス間の関係を、ＧＵＩにて可視的に表示することが可能となる。
グラフ表示内の特定のノード、つまりデバイスに注目した場合には、制御プログラムによって、そのデバイスによって引き起こされる全ての操作が、そのノードから出ているエッジとして表現されており、またそのデバイスへ影響を与える全ての操作が、そのノードへ入っているエッジとして表現されることになる。
このため、制御プログラムのグラフ表示を確認させることで、ＬＤ言語やＩＬ言語の熟練者でない作業者に対しても、デバイスを中心とした制御プログラムの理解支援が可能となる。
また、制御プログラムを有閉路有向グラフとして表示し、可視化された表示の一部分を指定することで、指定するデバイス群に対して変更を行った場合の影響範囲について図示することが可能となる。
この結果、例えば制御プログラムが動作するＦＡ・ＰＡシステムにおける障害発生時に、ＬＤ言語やＩＬ言語のみを用いて障害の原因究明を行うよりも短時間で、その要因発見を支援することができる。
また、制御プログラムを有閉路有向グラフとしてデータ構造に保持することにより、ソフトウェアによるチャタリングなどのプログラム上の潜在バグについて確認することが可能となるため、制御プログラムの設計時に、シミュレータや実際のＦＡ・ＰＡシステムと接続して判明するような潜在バグや不安定な動作の危険性を、プログラムの静的チェックで知ることが可能となる。
この結果、制御プログラムの設計フェーズにおける手戻り工数の削減を助けることが可能となる。

以上の実施の形態１〜３では、
制御プログラムで制御される変数（デバイス）を抽出してノードとし、デバイス間の相互作用を依存関係として抽出してエッジとすることで、制御プログラムを有閉路有向グラフとしてデータ構造に保持することで、制御プログラム設計時に以下の支援を行うシステムを説明した。
１）制御プログラム内で使用されているデバイス間の関係を、ＧＵＩにて可視的に表示する
２）可視化された表示の部分を指定することで、対応する元の制御プログラムの部分を表示する
３）特定のデバイスについて、他デバイスとの関係を表す仕様を文章で表示する
４）指定するデバイス群に対して変更を行った場合の影響範囲について図示する
５）制御プログラム内に登場する、未使用デバイスについて指摘する
６）ソフトウェアによるチャタリングなどのプログラム上の潜在バグについて指摘する
７）複数箇所で登場する同一構造を可視化することで、ソフトウェア部品の再利用を支援する
８）デバイス群の疎結合部分を見つけ出すことで、制御プログラムの分割について支援する
９）有閉路有向グラフを解析し、制御プログラムのデバイス間の結合度合いの指標を示す。

また、実施の形態１〜３では、
制御プログラムで制御される変数（デバイス）を抽出してノードとし、デバイス間の相互作用を依存関係として抽出してエッジとすることで、制御プログラムを有閉路有向グラフとしてデータ構造に保持することで、制御プログラム保守時に以下の支援を行うシステムを説明した。
１０）ＧＵＩにて可視的に表示された依存関係上にて、デバイス値をモニタする
１１）障害が現れたデバイス群を指定することで、その要因となりうる箇所を図示する。

また、上記を実現するための以下の構成も説明した。
１）制御プログラムで使用されているデバイスをノードとして抽出する「デバイス抽出部」
２）記述されたデバイス間の依存関係（処理）をエッジとして抽出する「依存関係抽出部」
３）解析条件および障害状況を入力する「条件入力部」
４）有閉路有向グラフの構造を解析する「グラフ解析部」
５）解析結果を出力する「結果出力部」
６）制御プログラムと有閉路有向グラフの部分の対応関係を管理する「リンク管理部」
７）実機器との通信によって、デバイスの現在値を取得する「オンラインモニタ部」。

更に、上記のグラフ構築部にて構築される有閉路有向グラフをシステム内のメモリに保持するための以下の特徴を持つデータ構造を説明した。
１）デバイス（ラベル）をノード構造体として表現
２）処理を、元の制御プログラムの処理位置へのリンク情報を持つエッジ構造体として表現
３）ノード構造体とエッジ構造体を接続するトポロジ情報。

また、ネットワーク上の制御機器上などに格納された、複数に分割された制御プログラムについて、その制御プログラム間の共通デバイス設定を参照することで、複数の制御プログラムをシームレスに一つの有閉路有向グラフとして扱うシステムと構成と手順についても説明した。

≪ハードウェア構成例≫
最後に、実施の形態１〜３に示した情報処理装置１００のハードウェア構成例について説明する。
図１９は、実施の形態１〜３に示す情報処理装置１００のハードウェア資源の一例を示す図である。
なお、図１９の構成は、あくまでも情報処理装置１００のハードウェア構成の一例を示すものであり、情報処理装置１００のハードウェア構成は図１９に記載の構成に限らず、他の構成であってもよい。

図１９において、情報処理装置１００は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態１〜３で説明した「〜記憶部」は、ＲＡＭ９１４、磁気ディスク装置９２０等により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。

通信ボード９１５は、ネットワークに接続されている。
例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）、インターネット、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）などに接続される。

磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。

また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。

また、ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
情報処理装置１００の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。

上記プログラム群９２３には、実施の形態１〜３の説明において「〜部」（「〜記憶部」以外、以下同様）として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。

ファイル群９２４には、実施の形態１〜３の説明において、「〜の抽出」、「〜の生成」、「〜の構築」、「〜の選択」、「〜の変換」、「〜の設定」、「〜の登録」、「〜の取得」、「〜の入力」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。
ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出される。
そして、読み出された情報やデータや信号値や変数値やパラメータは、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１〜３で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示す。
データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。
また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。

また、実施の形態１〜３の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
すなわち、実施の形態１〜３で説明したフローチャートに示すステップ、手順、処理により、本発明に係る「情報処理方法」を実現することができる。
また、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。
或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。
ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。
プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。
すなわち、プログラムは、実施の形態１〜３の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１〜３の「〜部」の手順や方法をコンピュータに実行させるものである。

このように、実施の形態１〜３に示す情報処理装置１００は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータである。
そして、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。

１００ 情報処理装置、１０１ 制御プログラム中間コード記憶部、１０２ デバイス抽出部、１０３ 依存関係抽出部、１０４ ノード構造体記憶部、１０５ エッジ構造体記憶部、１０６ 接続情報記憶部、１０７ 条件入力部、１０８ グラフ解析部、１０９ 結果出力部、１１０ リンク管理部、１１１ オンラインモニタ部、１１２ グラフ生成部。

Claims (15)

1. 複数のデバイスが記述されるとともにデバイス間の依存関係が記述され、前記複数のデバイスの記述とデバイス間の依存関係の記述により前記複数のデバイスに対する制御アルゴリズムが定義される制御プログラムから、各デバイスの記述を抽出するデバイス抽出部と、
   前記制御プログラムから、デバイス間の依存関係の記述を抽出する依存関係抽出部と、
   前記デバイス抽出部により抽出されたデバイスの記述と前記依存関係抽出部により抽出されたデバイス間の依存関係の記述とに基づき、ノードがデバイスを表し、有向エッジがデバイス間の依存関係を表し、前記制御プログラムで定義されている制御アルゴリズムをノードと有向エッジとの接続で表す有閉路有向グラフを生成するグラフ生成部とを有することを特徴とする情報処理装置。
2. 前記依存関係抽出部は、
   前記デバイス抽出部により抽出されたデバイスの記述と、抽出した依存関係の記述とを対応付ける接続情報を生成し、
   前記グラフ生成部は、
   前記デバイス抽出部により抽出されたデバイスの記述と、前記依存関係抽出部により抽出されたデバイス間の依存関係の記述と、前記依存関係抽出部により生成された接続情報とを用いて、前記有閉路有向グラフを生成することを特徴とする請求項１に記載の情報処理装置。
3. 前記デバイス抽出部は、
   ＩＥＣ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｌｅｃｔｒｏｔｅｃｈｎｉｃａｌ Ｃｏｍｍｉｓｓｉｏｎ）６１１３１−３規格で定義されている言語で作成された制御プログラムから、各デバイスの記述を抽出し、
   前記依存関係抽出部は、
   ＩＥＣ６１１３１−３規格で定義されている言語で作成された前記制御プログラムから、デバイス間の依存関係の記述を抽出することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記情報処理装置は、更に、
   前記グラフ生成部により生成された有閉路有向グラフをＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）方式にて表示する表示部を有することを特徴とする請求項１〜３のいずれかに記載の情報処理装置。
5. 前記依存関係抽出部は、
   デバイス間の依存関係として、１つの動作手順において起点となる起点デバイスと起点デバイスの動作に動作状態が依存する依存デバイスとが記述されている制御プログラムから、デバイス間の依存関係の記述を抽出し、
   前記グラフ生成部は、
   前記制御プログラムで定義されている制御アルゴリズムを、起点デバイスから依存デバイスに向かう有向エッジを用いて表す有閉路有向グラフを生成することを特徴とする請求項１〜４のいずれかに記載の情報処理装置。
6. 前記依存関係抽出部は、
   デバイス間の依存関係として、正論理の依存関係及び負論理の依存関係のいずれであるかが記述されている制御プログラムから、デバイス間の依存関係の記述を抽出し、
   前記グラフ生成部は、
   正論理の依存関係を表す有向エッジと、負論理の依存関係を表す有向エッジとが区別される有閉路有向グラフを生成することを特徴とする請求項１〜５のいずれかに記載の情報処理装置。
7. 前記情報処理装置は、更に、
   前記制御プログラムに記述されている特定のデバイス及び特定の依存関係の少なくともいずれかを指定要素として指定する指定要素情報を入力する情報入力部と、
   前記有閉路有向グラフを解析し、前記指定要素情報で指定されている指定要素に変更があった場合に当該変更の影響を受ける影響範囲を前記有閉路有向グラフから抽出するグラフ解析部と、
   前記グラフ解析部により抽出された影響範囲を前記有閉路有向グラフにおいて表示する表示部とを有することを特徴とする請求項１〜６のいずれかに記載の情報処理装置。
8. 前記情報処理装置は、更に、
   前記制御プログラムに記述されている特定のデバイス及び特定の依存関係の少なくともいずれかを指定要素として指定する指定要素情報を入力する情報入力部と、
   前記指定要素情報で指定されている指定要素が記述されているプログラムコードを前記制御プログラムから抽出するプログラムコード抽出部と、
   前記グラフ生成部により生成された有閉路有向グラフと、前記プログラムコード抽出部により抽出されたプログラムコードとを表示する表示部とを有することを特徴とする請求項１〜７のいずれかに記載の情報処理装置。
9. 前記情報処理装置は、更に、
   前記有閉路有向グラフを解析し、チャタリングを発生させる可能性のある循環を前記有閉路有向グラフから抽出するグラフ解析部と、
   前記グラフ解析部により抽出された循環を前記有閉路有向グラフにおいて表示する表示部とを有することを特徴とする請求項１〜８のいずれかに記載の情報処理装置。
10. 前記情報処理装置は、更に、
    前記制御プログラムに記述されている特定のデバイスを指定要素として指定する指定要素情報を入力する情報入力部と、
    前記有閉路有向グラフを解析し、前記指定要素情報で指定要素として指定されているデバイスを表すノードと接続している有向エッジを前記有閉路有向グラフから抽出するとともに、抽出した有向エッジと接続しているノードを前記有閉路有向グラフから抽出し、抽出した有向エッジとノードとに基づき、前記指定要素情報で指定要素として指定されているデバイスと抽出したノードが表しているデバイスとの間の依存関係を自然言語にて説明する説明文を生成するグラフ解析部と、
    前記グラフ生成部により生成された有閉路有向グラフと、前記グラフ解析部により生成された説明文とを表示する表示部とを有することを特徴とする請求項１〜９のいずれかに記載の情報処理装置。
11. 前記情報処理装置は、更に、
    前記有閉路有向グラフを解析し、いずれのデバイスとも依存関係にないデバイスを表すノードを未使用デバイスノードとして前記有閉路有向グラフから抽出するグラフ解析部と、
    前記グラフ解析部により抽出された未使用デバイスノードを、他のノードと区別して前記有閉路有向グラフにおいて表示する表示部とを有することを特徴とする請求項１〜１０のいずれかに記載の情報処理装置。
12. 前記情報処理装置は、更に、
    前記複数のデバイスに対して前記制御プログラムを用いた制御が行われている場合に、所定のデバイスで計測された計測値を入力する計測値入力部と、
    前記有閉路有向グラフ内の該当するデバイスのノードに対して前記計測値入力部により入力された計測値を表示する表示部とを有することを特徴とする請求項１〜１１のいずれかに記載の情報処理装置。
13. 前記情報処理装置は、更に、
    いずれかのデバイスで障害が発生した場合に、前記有閉路有向グラフを解析し、障害が発生したデバイスを表す障害発生デバイスノードと接続している有向エッジを前記有閉路有向グラフから抽出するとともに、抽出した有向エッジと接続しているノードを抽出し、抽出したノードが表しているデバイスに異常が発生していると判定された場合に、抽出したノードと接続している有向エッジの抽出及び抽出した有向エッジと接続しているノードの抽出を行い、抽出したノードが表しているデバイスに異常が発生していると判定された場合に、更に、抽出したノードと接続している有向エッジの抽出及び抽出した有向エッジと接続しているノードの抽出を繰り返すグラフ解析部と、
    前記障害発生デバイスノードと、異常が発生していると判定されたデバイスを表すノードとを、他のノードから区別して前記有閉路有向グラフにおいて表示する表示部とを有することを特徴とする請求項１〜１２のいずれかに記載の情報処理装置。
14. コンピュータが、複数のデバイスが記述されるとともにデバイス間の依存関係が記述され、前記複数のデバイスの記述とデバイス間の依存関係の記述により前記複数のデバイスに対する制御アルゴリズムが定義される制御プログラムから、各デバイスの記述を抽出するデバイス抽出ステップと、
    前記コンピュータが、前記制御プログラムから、デバイス間の依存関係の記述を抽出する依存関係抽出ステップと、
    前記コンピュータが、前記デバイス抽出ステップにより抽出されたデバイスの記述と前記依存関係抽出ステップにより抽出されたデバイス間の依存関係の記述とに基づき、ノードがデバイスを表し、有向エッジがデバイス間の依存関係を表し、前記制御プログラムで定義されている制御アルゴリズムをノードと有向エッジとの接続で表す有閉路有向グラフを生成するグラフ生成ステップとを有することを特徴とする情報処理方法。
15. 複数のデバイスが記述されるとともにデバイス間の依存関係が記述され、前記複数のデバイスの記述とデバイス間の依存関係の記述により前記複数のデバイスに対する制御アルゴリズムが定義される制御プログラムから、各デバイスの記述を抽出するデバイス抽出ステップと、
    前記制御プログラムから、デバイス間の依存関係の記述を抽出する依存関係抽出ステップと、
    前記デバイス抽出ステップにより抽出されたデバイスの記述と前記依存関係抽出ステップにより抽出されたデバイス間の依存関係の記述とに基づき、ノードがデバイスを表し、有向エッジがデバイス間の依存関係を表し、前記制御プログラムで定義されている制御アルゴリズムをノードと有向エッジとの接続で表す有閉路有向グラフを生成するグラフ生成ステップとをコンピュータに実行させることを特徴とするプログラム。

Images