JP2018041514A - 共有データ定義支援システム、その支援装置、プログラム - Google Patents

Abstract

【課題】任意のプログラミング環境で、部分的・段階的に整合性検査を行うことで全体での共有データ定義の不整合の検査を実現させる。【解決手段】各コントローラ装置４に応じた各プログラミング環境１毎に、そのプログラミング装置２に対応して共有データ定義支援装置３を設ける。各支援装置３は、各々、初期状態では同一内容である共有データ定義管理テーブル３０を有する。各支援装置３は、各々、自装置の管理テーブル３０に基づいて生成される共有データ変数宣言テーブル４０を有する。任意の支援装置３は、自装置及び任意の他の支援装置の前記管理テーブル３０、宣言テーブル４０に基づいて、整合性検査を行う。【選択図】 図１

Description

本発明は、制御システムの制御プログラムの作成作業に係わる、制御システム全体での共有データ定義の不整合の検査方法等に関する。

複数のコントローラがネットワークに接続されて成る制御システムに関する制御プログラムの作成では、複数の作業者が、各々が担当するコントローラ装置を決めて、制御プログラムの作成を分担し、それぞれの作業者のプログラミング装置を用いて、同時並行で作業を進めることが行われる。

このような環境の下で、制御システムにおける通信ネットワークを用いたコモンメモリ型のデータ交換方式に対応して、複数のコントローラ間で共有するデータ（変数）を用いて制御プログラムを作成する場合がある。

ここで、図２２を参照して上記コモンメモリ型のデータ交換方式について説明する。
図２２には、上記“複数のコントローラがネットワークに接続されて成る制御システム”の一例の概略構成を示す。

図示の例の制御システムは、複数のコントローラ（ＰＬＣ）１００（ＰＬＣ１、ＰＬＣ２、・・・、ＰＬＣｎ）が、ネットワーク２００に接続されており、各コントローラ１００がネットワーク２００を介して相互にデータ送受信可能な構成となっている。

各コントローラ１００は、コモンメモリ１０１を有している。コモンメモリ１０１は、上記“複数のコントローラ間で共有するデータ（グローバル変数等；共有データというものとする）”を記憶するメモリである。各コントローラ１００は、例えば、自己のコモンメモリ１０１における自局更新領域の格納データ（共有データ）を、ネットワーク上にブロードキャスト送信する。各コントローラ１００は、例えば、他のコントローラ１００からブロードキャスト送信された上記共有データを受信すると、これを自己のコモンメモリ１０１に上書き格納する。

上記一例に限らないが、基本的には、全てのコントローラ１００のコモンメモリ１０１の格納データ（全共有データ）が同一となるように制御されている。
尚、各コントローラ１００の他の構成については図示・説明は省略するが、ＣＰＵやコモンメモリ以外のメモリ等を有しており、上記ブロードキャスト通信等の各種機能を実現させる。

また、図２２に示すように、各コントローラ１００（ＰＬＣ１、ＰＬＣ２、・・・、ＰＬＣｎ）毎に対応して、各プログラミング装置１１０が接続されている。上記各作業者は、それぞれ、任意のプログラミング装置１１０を用いて、対応するコントローラ１００の制御プログラムを作成する。作成された制御プログラムは、対応するコントローラ１００に転送されて記憶される。尚、制御プログラムには、上記共有データ（グローバル変数等）やローカル変数等の各種変数が用いられる。

また、上記各プログラミング装置１１０は、図２３に示すように、他のネットワーク１２０に接続されている。また、当該他のネットワーク１２０には、サーバ装置１３０も接続されている。これより、当該他のネットワーク１２０を介して、プログラミング装置１１０間やプログラミング装置１１０−サーバ装置１３０間で通信（データ送受信）可能となっている。

ここで、共有データは上述したようなシステム全体で共有するものであるから、各作業者が独自に定義（変数名や割当アドレス等）して上記制御プログラムで使用してよいものではない。この為、予めシステム全体として共有データに関する定義を行って、この定義を各作業者に通知しておく必要がある。

例えば、上記サーバ装置１３０において、共有データに関する定義を行って、この共有データ定義（その一部）を、上記他のネットワーク１２０を介して各プログラミング装置１１０に配信して記憶させること等が行われている。

図２４に、このような共有データの定義や配信に係わる具体例を示す。
図２４（ａ）には、上記サーバ装置１３０で作成／記憶される共有データ定義の具体例（共有データ定義テーブル）を示す。

図示の例の共有データ定義テーブル１４０は、共有データ変数名１４１、データ型１４２、アドレス１４３、書込み局（ライト局）１４４、参照局（リード局）１４５等から成る。

つまり、各共有データ毎に、その識別情報（変数名などの名称など）、ＩＮＴなどのデータ型、上記コモンメモリ１０１における割当アドレス等の定義が、共有データ変数名１４１、データ型１４２、アドレス１４３に登録されている。更に、ここでは、説明の簡略化のため、コモンメモリ１０１における各割当アドレス（各アドレス１４３）へアクセスを行うのは、各共有データ毎に、リードとライトの１対のコントローラ１００のみであるものとする。つまり、アドレス１４３へ書き込みを行うコントローラ１００の識別情報等が書込み局１４４に格納され、アドレス１４３からの読出しを行うコントローラ１００の識別情報等が参照局１４５に格納される。尚、参照局１４５は１つに限らず複数局定義してもよい。

ここで、上記共有データ定義テーブル１４０を各プログラミング装置１１０に配信して記憶させてもよいが、上記のように、各共有データ毎に、それに関係するコントローラ１００は限られている（書込み局１４４と参照局１４５のみ）。

これより、図２４（ｂ）に示すように、各コントローラ１００毎に、上記共有データ定義テーブル１４０から、そのコントローラ１００に関係するデータを抽出することで共有データ変数宣言テーブル１５０（１５０−１、１５０−２、１５０−３）を生成して、これをそのコントローラ１００に対応するプログラミング装置１１０に配信して記憶させる。

ここで、図２４（ａ）には一例として、共有データ変数名１４１がＡ，Ｂ，Ｃの３つの共有データの定義を示している。そして、図示の例の場合、共有データＡに関係するコントローラはＰＬＣ１とＰＬＣ２であり、共有データＢに関係するコントローラはＰＬＣ２とＰＬＣ１であり、共有データＣに関係するコントローラはＰＬＣ１とＰＬＣ３である。

これより、図２４（ｂ）に示すように、ＰＬＣ１用の共有データ変数宣言テーブル１５０−１は、上記３つの共有データ定義全てが抽出されて作成されることになる。一方、ＰＬＣ３用の共有データ変数宣言テーブル１５０−３は、上記３つの共有データ定義のうち共有データＣの定義のみが抽出されて作成されることになる。

この様にして、各プログラミング装置１１０に配信して記憶させる共有データ定義のデータ量を、削減することができる。
上記各コントローラ１００用の各共有データ変数宣言テーブル１５０を、対応するプログラミング装置１１０に配信させて記憶させた後、各プログラミング装置１１０において上記作業者が、記憶された共有データ変数宣言テーブル１５０を参照しつつ制御プログラムの作成作業を行うことになる。

また、特許文献１に開示されている従来技術では、ネットワーク間で同期化されるデータの多重定義をチェックする方法を示している。この例では、プログラミング装置において、複数のコントローラ装置向けの制御プログラムに記述済みの通信用出力シンボルのデータ変数名の重複チェックを行うことについて開示している。

また、特許文献２には、データ型を有する変数のデータ型情報の流用方法について開示されているが、これは、対象となる変数の利用形態を判断材料に用いてデータ型の内部構造の不整合判定を行うものではない。

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

ここで、従来では、上述したように予め共有データを定義して、その情報を元に制御プログラム作成を開始したにも関わらず、一部の作業者同士（作業者グループ）が申し合わせて、新たに必要となった共有データをこれら作業者間でのみ追加定義し、全体の共有データ定義に反映させていない等の状況が生じる場合がある。つまり、制御プログラム作成開始時に定義していた共有データに関する定義が、制御プログラムの作成の進展に伴って一部のプログラミング装置１１０においてのみ改変され（そして、その共有データ変数宣言テーブル１５０にのみ反映される）、全体の共有データ定義（上記共有データ定義テーブル１４０等）や、他のプログラミング装置１１０で使われている共有データ定義（共有データ変数宣言テーブル１５０）には反映されていない等という状況が発生することがある。

この場合、例えば、２つの作業者グループが、別々に申し合わせて共有データ定義を追加した際、別々の意味のデータを同じ名称で重複定義してしまう、といったことが発生し得る。例えば、共有データ変数名は同じであるが、データ型やアドレスが異なる複数の共有データ定義が行われることが有り得る。

このような不整合の発生を避けるには、共有データ定義に何らかの変更を行う場合に、全ての作業者が現在用いている共有データ定義（共有データ変数宣言テーブル１５０；但し初期状態のままとは限らない）を一旦全て上記サーバ装置１３０等に集め、サーバ装置１３０等において管理者等によって不整合が無い様に共有データ定義テーブル１４０に新規定義を追加する等して共有データ定義テーブル１４０を更新する。そして、更新後の共有データ定義テーブル１４０に基づいて再び上記各共有データ変数宣言テーブル１５０を作成して各プログラミング装置１１０に配信して記憶させる方法がある（尚、この配信・記憶が行われるまで、各プログラミング装置１１０における作業は一旦止めることになる）。

しかし、この方法では、サーバ装置１３０等において共有データ定義を変更している間、その変更に関係のない作業者の作業まで止めて、定義変更を行う必要があった。更に、サーバ装置１３０に何らかの不具合が発生した場合、復旧するまでの間、定義変更は困難であった。また、そもそも、各プログラミング装置１１０以外の構成（つまり、サーバ装置１３０）が余計に必要であった。

また、上記特許文献１には、複数の作業者が別々のプログラミング装置を用いて、並行して制御プログラムを作成する際の、共有データの多重定義などの不整合検査方法については、何等開示されていない。

本発明の課題は、後から一部で共有データが追加されることに伴って発生する可能性のある共有データ定義の不整合を、任意のプログラミング環境で検査できるようにし、また、部分的・段階的に整合性検査を行うことで全体での共有データ定義の不整合の検査を実現させる共有データ定義支援システム、その支援装置、プログラム等を提供することである。

本発明の共有データ定義支援システムは、各々がネットワークに接続されると共に１以上の共有データを保持し得る複数のコントローラと、該各コントローラに対応して設けられ、そのコントローラの制御プログラムを前記共有データも用いて任意に作成させるプログラミング装置とを有するシステムであって、前記各プログラミング装置に対応して支援装置が設けられている。

そして、該各支援装置は、前記各プログラミング環境における派生データ型の定義情報に基づいて、名称が同一である派生データ型同士の整合性を判定する派生データ型整合性検査手段、を有する。

本発明の共有データ定義支援システム、その支援装置、プログラム等によれば、後から一部で共有データが追加されることに伴って発生する可能性のある共有データ定義の不整合を、任意のプログラミング環境で検査できるようにし、また、部分的・段階的に整合性検査を行うことで全体での共有データ定義の不整合の検査を実現させることができる。

本例の共有データ定義支援装置における各作業者のプログラミング環境の概略構成図である。 実施例１の共有データ定義支援装置の機能ブロック図である。 （ａ）は共有データ定義管理テーブル、（ｂ）は共有データ変数宣言テーブルの具体例である。 共有データ定義支援装置を用いて共有データ定義の不整合を検出するための作業フローである。 全体における各整合性検査の実施の様子を示す図である。 ステップＳ１５における共有データ定義の不整合検査の詳細処理例を示すフローチャートである。 初期状態における各プログラミング環境の各種テーブルの具体例（１／２）である。 初期状態における各プログラミング環境の各種テーブルの具体例（２／２）である。 図７、図８の例から更新後の各種テーブルの具体例（１／２）である。 図７、図８の例から更新後の各種テーブルの具体例（２／２）である。 実施例２の共有データ定義支援装置の機能ブロック図である。 実施例２における共有データ定義の不整合を検出するための作業フロー（１／２）である。 実施例２における共有データ定義の不整合を検出するための作業フロー（２／２）である。 実施例２における共有データ定義管理テーブルのデータ例である。 派生データ型定義管理テーブルのデータ構造例である。 ステップＳ４３の処理の詳細フローチャート図である。 ステップＳ４７の処理の詳細フローチャート図である。 ステップＳ４３、Ｓ４７の処理イメージを示す図である。 （ａ）、（ｂ）は、派生データ型の定義情報の一例を示す図である。 ステップＳ５０の表示処理の表示画面例（その１）である。 ステップＳ５０の表示処理の表示画面例（その２）である。 コモンメモリ型のデータ交換方式について説明するための図である。 各プログラミング装置に係わるネットワーク構成例である。 共有データの定義や配信に係わる具体例を示す図である。

以下、図面を参照して、本発明の実施の形態について説明する。
図１（ａ）は、本例の共有データ定義支援システムにおける各作業者のプログラミング環境の概略構成図である。つまり、共有データを用いた制御プログラムを作成する環境を表すブロック図である。

上記背景技術で説明したように、前提としては、不図示のネットワークを介して複数のコントローラ装置４で共有されるデータ（上記共有データ）等も用いて、各プログラミング装置２毎に、それが対応するコントローラ装置４用の制御プログラムを作業者が作成するものである。その際、予め各共有データの定義を行い、この共有データ定義（その一部）を各プログラミング装置２に保持させておき、各作業者がそれぞれのプログラミング装置２上で、共有データ定義に従って制御プログラムの作成を行うものである。

そして、本例の共有データ定義支援システムは、主にこの制御プログラム作成途中で、共有データ定義の整合性を任意のプログラミング環境で部分的／段階的に検査することができ、以って全ての作業者の制御プログラミング作業を中断させる必要はないものとできる。

まず、図示のコントローラ装置４は、上記従来のコントローラ１００と同様と見做して構わない。従って、特に図示しないが、コントローラ装置４は複数台存在して不図示のネットワークに接続している共に、各コントローラ装置４は不図示の上記コモンメモリを有している。そして、上記従来と同様に、各コントローラ装置４に対応して各プログラミング装置２が設けられている。尚、コントローラ装置４は、対応するプログラミング装置２と接続されており、このプログラミング装置２で作業者によって作成された任意の制御プログラムが、ダウンロードされて記憶されて動作するものである。

各制御プログラムを作成する各作業者毎のプログラム作成環境（プログラミング環境１）は、当該プログラミング装置２と、本手法による共有データ定義支援装置３から構成されている。尚、共有データ定義支援装置３は、プログラミング装置２の機能の一部と見做してもよい。あるいは、共有データ定義支援装置３は、プログラミング装置２と接続された情報処理装置（パソコン等）であってもよい。何れにしても、共有データ定義支援装置３は、各プログラミング装置２毎に対応して設けられるものであり、複数存在する。

例えば図１（ｂ）に示すように、上記プログラミング環境１は、複数存在すると共にネットワーク５に接続されている。これは、各プログラミング環境１の共有データ定義支援装置３または／及びプログラミング装置２が、ネットワーク５に接続しているものである。これより、例えば後述するように、全ての共有データ定義支援装置３、プログラミング装置２が、ネットワーク５を介して相互にデータ送受信可能となっている。

但し、これは一例であり、この例に限らない。例えば、共有データ定義支援装置３がネットワーク５に接続されていない構成、あるいはそもそもネットワーク５が存在しない構成等であっても構わない。この様な構成の場合、２つの支援装置３の間で転送すべきデータ、あるいは支援装置３−プログラミング装置２間で転送すべきデータは、ＵＳＢメモリ等の可搬型記憶媒体を用いることで、データ転送を実現するようにしてもよい。これは、転送元の装置でデータを可搬型記憶媒体に記憶させ、この可搬型記憶媒体を転送先の装置に接続してデータの読出しを実行させることになる。この様に、可搬型記憶媒体を介して各装置２，３間でデータを受け渡す構成の場合でも、各装置２、３等がネットワーク５に接続されている構成の場合と同様に、不整合検査を実現させることができる。尚、USBはUniversal Serial Busの略である。

また、図１（ａ）、（ｂ）に示すように、本例の場合、上記サーバ装置１３０に相当する構成は、無くてもよい。本手法では、上記共有データ定義テーブル１４０に相当するデータ（共有データ定義管理テーブル３０）は、全ての上記プログラミング環境（その共有データ定義支援装置３等）で記憶されている。

そして、全てのプログラミング環境（その共有データ定義支援装置３等）において、共有データ定義管理テーブル３０などを用いて、上記不整合の検出等を行うことができる。詳しくは後述する。

また、プログラミング環境毎に、その共有データ定義支援装置３等において、上記共有データ定義テーブル等に基づいて、対応するコントローラ装置４に応じた上記共有データ変数宣言テーブル１５０に相当するデータ（図示の共有データ変数宣言テーブル４０）を生成して、これを記憶すると共にプログラミング装置２に記憶させる。

作業者は、プログラミング装置２において、共有データ変数宣言テーブル４０を参照する等して、対応するコントローラ装置４に係わる制御プログラム等を任意に作成する。
図２は、共有データ定義支援装置３の機能ブロック図である。

尚、以下の説明では、共有データ定義支援装置３を簡略化して支援装置３と記す場合もあるものとする。
図示の例では、共有データ定義支援装置３は、システム構成管理部１１、共有データ定義部１２、共有データ定義管理テーブル記憶部１３、共有データ変数宣言テーブル生成部１４、共有データ変数宣言テーブル記憶部１５、共有データ変数宣言テーブル転送部１６、共有データ定義管理テーブル転送部１７、共有データ整合性検査部１８、共有データ整合性検査結果表示部１９等の各種機能部を有する。

尚、共有データ定義支援装置３は、例えば一例としてはパソコンやサーバ装置上で実現されるものであり、パソコン等の一般的なコンピュータのハードウェア構成を有するものである。従って、特に図示しないが、ＣＰＵ等の演算プロセッサ、ハードディスク、メモリ等の記憶部、キーボード、マウス等による入力操作部、液晶ディスプレイ等による表示部、通信機能部等を有している。

そして、例えば上記記憶部には、予め所定のアプリケーションプログラムが記憶されており、上記ＣＰＵ等がこのプログラムを実行することにより、上記各種機能部１１〜１９の機能処理が実現される。

尚、プログラミング装置２やコントローラ装置４も、不図示の記憶部や演算プロセッサ等を有しており、記憶部に記憶されるプログラム等を演算プロセッサが実行することで、所定の処理機能を実現するものであるが、これについての説明は省略する。

システム構成管理部１１は、対象とする制御システム全体の構成を設定させて管理する機能部である。例えば、不図示の通信ネットワークに接続されているコントローラ装置４の数や、各コントローラ装置４の局番号や名称をユーザに設定させる等して（不図示の設定用の画面を表示して任意に入力させる）、対象システム内の全体の局構成を管理する。

共有データ定義部１２は、複数のコントローラ装置４で共有されるデータ（上記共有データ；例えばグローバル変数等）を、任意のユーザに任意に定義させる（その為の不図示の入力画面を表示する）。例えば、通信ネットワークを介して複数のコントローラ装置４で共有したいデータ（共有データ）について、その名称と、書込み局、参照局、ならびに、その共有データに関連付けられる各種データ等を、上記不図示の入力画面上でユーザに入力させる。つまり、共有データ定義管理テーブル３０を任意に作成・更新させる機能部である。

但し、共有データ定義管理テーブル３０の初期状態の作成は、上記複数の共有データ定義支援装置３のうちの任意の１台の支援装置３でのみ行われる。そして、作成された共有データ定義管理テーブル３０のコピーを、他の全ての支援装置３へ送信して記憶させる。つまり、少なくとも初期状態では、全ての支援装置３において同一内容の共有データ定義管理テーブル３０を保持させる。

その後、運用中には、各プログラミング環境の各共有データ定義支援装置３毎に、作業者等は、共有データ定義部１２によって、共有データ定義管理テーブル３０の内容の更新を行うことができる。

共有データ定義管理テーブル記憶部１３は、上記共有データ定義部１２で作成された（あるいは他の支援装置３の共有データ定義部１２で作成されて送信されてきた）上記共有データ定義管理テーブル３０を、記憶する。

共有データ定義管理テーブル３０自体は、従来の上記共有データ定義テーブル１４０と略同様であってよく、例えば通信ネットワークを介して複数のコントローラで共有したいデータについて、その名称（共有データ変数名称）とコモンメモリ上の割当アドレスや、書込み局、参照局、ならびに、その共有データに関連付けられる各種データを、共有データ毎に登録したテーブルである。

ここで、図３（ａ）に、共有データ定義管理テーブル３０の具体例を示す。
図示の例では、共有データ定義管理テーブル３０は、共有データ変数名３１、データ型３２、アドレス３３、書込み局（ライト局）３４、参照局（リード局）３５等から成る。これらは、上述した識共有データ変数名１４１、データ型１４２、アドレス１４３、書込み局（ライト局）１４４、参照局（リード局）１４５等と略同様であってよく、ここでの説明は省略する。また、図示の関連データ３６は、ここでは関係ないので、特に説明しないものとする。

また、図３（ｂ）には、共有データ変数宣言テーブル４０の具体例を示す。
図示の例の共有データ変数宣言テーブル４０は、共有データ変数名４１、データ型４２、アドレス４３等を有する。各プログラミング環境毎に、対応するコントローラ装置４の局番が上記書込み局３４と参照局３５の何れかに格納されているレコードを、上記共有データ定義管理テーブル３０から抽出して、これら抽出レコードの共有データ変数名３１、データ型３２、アドレス３３のデータを、共有データ変数名４１、データ型４２、アドレス４３に格納することで、共有データ変数宣言テーブル４０が生成される。尚、共有データ変数宣言テーブル４０には、関連データ３６を含めてもよい。

共有データ変数宣言テーブル生成部１４は、上記共有データ定義管理テーブル記憶部１３に記憶された共有データ定義管理テーブル３０に基づいて、当該支援装置３が係わるコントローラ装置４に応じた共有データ変数宣言テーブル４０を、生成する。これは、例えば、上記従来の共有データ変数宣言テーブル１５０の生成処理と略同様の処理（例えば上記した処理）によって生成する。

共有データ変数宣言テーブル記憶部１５は、上記生成部１4で生成された上記共有デー
タ変数宣言テーブル４０を記憶する。
共有データ変数宣言テーブル転送部１６は、上記生成・記憶された共有データ変数宣言テーブル４０を、自環境のプログラミング装置２や、他のプログラミング環境（その共有データ定義支援装置３等）へ転送する。尚、自環境のプログラミング装置２に転送した共有データ変数宣言テーブル４０は、当該プログラミング装置２に記憶されるが、これを共有データ変数宣言テーブル４０’と記すものとする。

上記の例の逆に、自環境のプログラミング装置２や、他のプログラミング環境（その共有データ定義支援装置３等）から、そこで記憶されている共有データ変数宣言テーブル４０を取得する。

尚、自環境のプログラミング装置２に転送された共有データ変数宣言テーブル４０は、当該プログラミング装置２内に記憶され、その後、作業者は、従来と略同様にしてプログラミング装置２を用いて、共有データ変数宣言テーブル４０等を参照しつつ、コントローラ装置４の制御プログラムを作成することになる。

共有データ定義管理テーブル転送部１７は、上記記憶された共有データ定義管理テーブル３０を、他のプログラミング環境（その共有データ定義支援装置３等）へ転送する。その逆に、他のプログラミング環境（その共有データ定義支援装置３等）から、そこで記憶されている共有データ定義管理テーブル３０を取得する。

上述したように、初期状態では全てのプログラミング環境の共有データ定義管理テーブル３０は同一の内容となっているが、その後、一部のプログラミング環境で上述したように勝手に共有データが追加されること等に伴って、当該一部のプログラミング環境の共有データ定義支援装置３上で、作業者等が共有データ定義管理テーブル３０を更新する場合が有り得る。

これより、共有データ整合性検査部１８は、自環境の共有データ定義管理テーブル３０と他のプログラミング環境の共有データ定義管理テーブル３０との一致／不一致判定を行うこと等によって、不整合が生じているか否かを判別する。この判別処理は、他のプログラミング環境における共有データ整合性検査部１８で実行させてもよい（その場合には、自環境の共有データ定義管理テーブル３０を渡す）。

あるいは、共有データ整合性検査部１８は、更に、共有データ変数宣言テーブル４０と共有データ定義管理テーブル３０との不整合（内容の不一致）を判別するものであってもよい。すなわち、例えば、共有データの追加等に伴って共有データ定義管理テーブル３０を更新した後に、更新後の管理テーブル３０に基づいて共有データ変数宣言テーブル４０を再作成してプログラミング装置２に渡す必要があるが、作業者等がこの再作成を忘れた場合等に、宣言テーブル４０と管理テーブル３０とで共有データ定義の不整合が生じる。

また、上記共有データの追加等を、プログラミング装置２側で行う場合がある。つまり、上記プログラミング装置２で制御プログラムを作成中に、任意に追加した共有データ（グローバル変数等）を使用している場合がある。この様な場合、プログラミング装置２側で記憶している上記共有データ変数宣言テーブル４０’には、上記追加した共有データの情報が作業者等によって反映される。

これに関して、プログラミング装置２側で記憶している上記共有データ変数宣言テーブル４０’と共有データ変数宣言テーブル記憶部１５に記憶している共有データ変数宣言テーブル４０とが同一になるようにする処理を、自動的に行うことはできる。例えば、プログラミング装置２は、上記宣言テーブル４０’に何らかの変更が行われる毎に、当該変更後の宣言テーブル４０’のコピー等を共有データ定義支援装置３に転送して、これを新たな宣言テーブル４０として記憶させること等ができる。

しかしながら、この様な共有データ変数宣言テーブル４０の更新に応じて、共有データ定義管理テーブル３０も更新させるのは、作業者などが手作業で行うことになる（書込み局、参照局等は宣言テーブル４０には無いので）。

この為、上記の様な共有データ変数宣言テーブル４０の更新内容を、共有データ定義管理テーブル３０に反映する作業を、作業者が忘れる場合が有り得る。この様な場合、当然、宣言テーブル４０と管理テーブル３０との不整合が生じるが、それ以前に、後から勝手に追加された共有データがある状態にも係わらず、上記管理テーブル３０同士の一致／不一致検査では、不整合なしと判定される場合が有り得る。

例えば上述したような理由により、自環境内で宣言テーブル４０と管理テーブル３０とで共有データ定義の不整合が生じる場合が有り得る。共有データ整合性検査部１８は、この様な宣言テーブル４０と管理テーブル３０との共有データ定義の不整合の判別を、更に行うようにしてもよい。詳しくは後述する。

共有データ整合性検査結果表示部１９は、上記共有データ定義の不整合の検査結果を表示する。
図４は、共有データ定義支援装置３を用いて共有データ定義の不整合を検出するための作業フローである。

図示の例では、まず最初に、対象とする制御システムについて、上記システム構成管理部１１によって、通信ネットワークに接続されているコントローラ装置４の数や、それらの局番号や名称等の各種データをユーザにより設定させる。つまり、対象システム内の全体の局構成等を定義させる（ステップＳ１１）。

続いて、上記複数のプログラミング環境のなかの任意の１つのプログラミング環境においては、以下のステップＳ１２、Ｓ１３の作業を実施させる。
すなわち、まず、上記のように任意の共有データ定義支援装置３の上記共有データ定義部１２により、対象とするシステムで使用する共有データの初期データ（共有データ定義管理テーブル３０の初期状態）を、ユーザにより定義させる（例えば上記不図示の入力画面上で入力させる）（ステップＳ１２）。尚、この作業の際、ユーザは、上記ステップＳ１１で定義された局構成を参照することで、例えば書込み局、参照局の各局番号などを認識できる。

そして、上記共有データ定義管理テーブル転送部１７を用いて、並行してプログラミング作業を行う全ての作業者のプログラミング環境向けに、上記初期状態の共有データ定義管理テーブル３０を、ネットワーク５等を介して配信する（ステップＳ１３）。

尚、図示していないが、全てのプログラミング環境において、その共有データ定義支援装置３によって、上記配信された初期状態の共有データ定義管理テーブル３０に基づいて、初期状態の共有データ変数宣言テーブル４０が生成されて記憶されると共にプログラミング装置２にも記憶される。

これより、その後、各プログラミング環境毎に、そのプログラミング装置２において作業者等が、共有データ変数宣言テーブル４０’等を参照しつつ、コントローラ装置４の制御プログラムの作成する作業を、開始することになる（ステップＳ１４）。

そして、基本的には、この作成作業中の任意のときに、任意のプログラミング環境においてユーザが、その共有データ定義支援装置３において所定の指示操作（更に１以上の検査対象とするプログラミング環境の指定）を行うと、図示のステップＳ１５の処理が実行される。すなわち、上記指定された各プログラミング環境の共有データ定義支援装置３から、当該支援装置３で保持されている管理テーブル３０と宣言テーブル４０を取得する。そして、当該取得したテーブル３０，４０と、自装置３で保持している管理テーブル３０と宣言テーブル４０とを処理対象テーブルとして、不整合チェック処理を行う。

この不整合チェック処理については、後に図６を参照して説明するが、不整合検査対象のテーブル同士を比較・照合する等して不整合を検出する。そして、この不整合チェック処理結果を表示する（ステップＳ１６）。

これより、上記チェック処理の結果、不整合が検出された場合には（ステップＳ１７，ＹＥＳ）、上記ステップＳ１６の表示内容を参照して作業者等によってステップＳ１８、Ｓ１９の作業が実行されることになる。尚、図示の例ではステップＳ１７がＮＯの場合には本処理を終了するが、この例に限らず、ステップＳ１５に戻るようにしてもよい。

ここで、上記制御プログラムの作成作業中に、上記従来で説明したように、一部の作業者同士が申し合わせて、新たに必要となった共有データをこれら作業者間でのみ追加定義する事態が起こり得る。この場合、例えば、新たな共有データの定義が共有データ定義管理テーブル３０に追加されると共に、この更新後の管理テーブル３０に基づいて新たな共有データ変数宣言テーブル４０が生成される。しかし、上記の通り、作業者等が例えば宣言テーブル４０を生成し忘れる場合が起こり得る。

あるいは、その逆に、新たな共有データの定義が宣言テーブル４０に追加されると共に、この更新後の宣言テーブル４０に基づいて管理テーブル３０が更新されるケースも有り得る。この場合も、上記のように、作業者等が管理テーブル３０の更新を忘れる場合が起こり得る。この様にして管理テーブル３０と宣言テーブル４０との間で不整合が生じる場合が起こり得る。

あるいは、上記従来で説明したように、２つ以上の作業者グループが、別々に申し合わせて共有データ定義を追加した際、別々の意味のデータを同じ名称（共有データ変数名称）で重複定義してしまう、等の不整合が発生し得る。

上記ステップＳ１５の処理では、例えばこの様な不整合の有無を検査するものであり、詳しい処理例は図６に示し、後に説明するものとする。
そして、これら不整合検査対象同士を比較・照合する等して不整合を検出する。例えば、任意の他のプログラミング環境の共有データ定義支援装置３から取得した共有データ定義管理テーブル３０と、自装置が保持する共有データ定義管理テーブル３０とを照合して、両者が一致するか否かを判定し、不一致の場合には不整合と判定する。但し、この例に限らない。

そして、共有データ定義の不整合を検出した場合には、この不整合の内容（例えば、一方に存在するが他方に存在しない共有データがある；あるいは、任意の変数名の共有データについて定義内容（アドレスなど）が異なっているなど）をディスプレイに表示する（ステップＳ１６）。

作業者は、不整合がある場合には（ステップＳ１７，ＹＥＳ）、上記ステップＳ１６による表示内容を参照して、上記検査対象の共有データ変数宣言テーブル４０や共有データ定義管理テーブル３０の該当箇所を修正する。そして、他のプログラミング環境の共有データ定義支援装置３から取得した宣言テーブル４０や管理テーブル３０については、修正後のこれらテーブル３０、４０を元のプログラミング環境に反映させる（修正後のテーブル３０、４０を取得元の共有データ定義支援装置３へ送信して置き換えさせる）（ステップＳ１８）。

更に、自プログラミング環境に関して、作成中の制御プログラム中に修正した共有データを使用している箇所がある場合には、作業者等は、この該当箇所についても修正を行う。

尚、上記元のプログラミング環境に反映させたり制御プログラムを修正する前に、ステップＳ１５に戻り、修正後のテーブル３０、４０を用いて再検査を行い、再検査で不整合なしとなった場合には、上記元のプログラミング環境に反映させたり制御プログラムを修正するようにしてもよい。

ここで、本手法では、上述したように、任意のプログラミング環境の共有データ定義支援装置３において、任意のときに（制御プログラム作成作業を中断してよい状況のときなどに）整合性検査処理を実行できる。更に、整合性検査対象は、全体ではなく、その都度、一部のプログラミング環境のみとすることができる。

図５に、全体における各整合性検査の実施の様子を示す。
ここでは、プログラミング環境１〜プログラミング環境ＮまでのＮ個のプログラミング環境があるものとする。尚、各プログラミング環境の構成は、図１に示す通りとする。

図示の例では、例えばプログラミング環境１において整合性検査を実施しており、検査対象は当該プログラミング環境１とプログラミング環境２となっている。この場合、プログラミング環境１の共有データ定義支援装置３が、プログラミング環境２の共有データ定義支援装置３が記憶している宣言テーブル４０や管理テーブル３０をネットワーク５を介して取得する。そして、取得した宣言テーブル４０や管理テーブル３０と、自装置で記憶している宣言テーブル４０や管理テーブル３０とを検査対象として、例えば後述する図６に示す整合性検査処理を実行する。

この整合性検査処理中、プログラミング環境１，２以外の他のプログラミング環境では、制御プログラム作成作業を中断する必要は無い。
また、図示の例では、例えばプログラミング環境２において整合性検査を実施しており、検査対象は当該プログラミング環境２とプログラミング環境１とプログラミング環境３となっている。この場合、プログラミング環境２の共有データ定義支援装置３が、プログラミング環境１，３の各共有データ定義支援装置３が記憶している宣言テーブル４０や管理テーブル３０を取得する。そして、取得した宣言テーブル４０や管理テーブル３０と、自装置で記憶している宣言テーブル４０や管理テーブル３０とを検査対象として、例えば後述する図６に示す整合性検査処理を実行する。

この整合性検査処理中、プログラミング環境１〜３以外の他のプログラミング環境では、制御プログラム作成作業を中断する必要は無い。
また、図示の例では、例えばプログラミング環境３において整合性検査を実施しており、検査対象は当該プログラミング環境３とプログラミング環境Ｎとなっている。この場合、プログラミング環境３の共有データ定義支援装置３が、プログラミング環境Ｎの共有データ定義支援装置３が記憶している宣言テーブル４０や管理テーブル３０を取得する。そして、取得した宣言テーブル４０や管理テーブル３０と、自装置で記憶している宣言テーブル４０や管理テーブル３０とを検査対象として、例えば後述する図６に示す整合性検査処理を実行する。

この整合性検査処理中、プログラミング環境３，Ｎ以外の他のプログラミング環境では、制御プログラム作成作業を中断する必要は無い。
このように、本手法では、例えば図５の例のような部分的／段階的な整合性検査処理を実行することができ、全てのプログラミング環境で制御プログラム作成作業を中断する必要は無い。

例えば上記のようにして、部分的に段階的に整合性検査処理を実行していき、全てのプログラミング環境が最低でも１回は検査対象となるようにする（これをサポートする為に、例えば、各処理実行完了毎に、検査対象となったプログラミング環境を全プログラミング環境に通知するようにしてもよい）。これは、例えば、ｍ＝１，２，３、・・・Ｎとし、ｍの初期値を‘１’とし、プログラミング環境ｍとプログラミング環境ｍ＋１とを検査対象とし整合性検査を実行し、各整合性検査実行毎にｍを＋１インクリメントして次の整合性検査を実行するようにしてもよい。この例では、ｍ＝Ｎとなったら、検査終了することになる。勿論、この例に限らない。

ここで、各整合性検査処理を実行するのは、任意のプログラミング環境（その共有データ定義支援装置３）であってよいが、検査対象には既に整合性検査処理を実行済みのプログラミング環境が１つ以上は含まれるようにすることが望ましい（但し、最初の１回は除外する）。

これは、図５の例の場合、上記プログラミング環境３，Ｎに係わる整合性検査処理（３回目の処理となる）を実施する際には、プログラミング環境３は既にプログラミング環境１、２との整合性がとれている状態であるはずである。但し、これは、上記プログラミング環境１，２、３に係わる整合性検査処理（２回目の処理となる）において、もし不整合があった場合には、プログラミング環境３のテーブル３０，４０を、プログラミング環境１，２に合わせるように修正されていることを前提とする。

これより、もしプログラミング環境３、Ｎで不整合が生じていた場合には、プログラミング環境Ｎのテーブル３０，４０をプログラミング環境３に合わせるように修正することが望ましい。これによって、プログラミング環境Ｎは、プログラミング環境３だけでなくプログラミング環境１，２とも整合性がとれている状態となるはずである。

よって、仮にＮ＝４とするならば、図５に示す３回の整合性検査処理を行えば、全体の整合性がとれた状態となっているはずである。
また、図５の例では、図示の例の後にプログラミング環境Ｎで整合性検査処理を実行することになった場合、プログラミング環境３だけでなくプログラミング環境１，２も、検査対象から除外しても構わないと考えることもできる（既に整合が取れているはずであるから）。その意味で、図５に示す２番目の整合性検査（プログラミング環境２で実行する）では、図示の例に限らず、プログラミング環境１は検査対象としなくても構わない。

このように、対象システムの制御プログラムを各作業者が同時並行に作成する過程で、共有データ定義支援装置３を用いて、部分的・段階的に共有データ定義の整合性検査を行っていくことで、例えば全てのプログラミング環境が最低でも１回は検査対象となったときには、全体として共有データ定義の不整合が解消された状態となることが期待でき、以って共有データ定義の不整合が解消された制御プログラムを作成することができる。

尚、図示していないが、全てのプログラミング環境において制御プログラム作成が完了した時点で、最終的な確認の為に、全てのプログラミング環境を検査対象とした整合性検査処理を実行するようにしてもよい（実行するのは任意のプログラミング環境の共有データ定義支援装置３であってよい）。また、整合性検査を行うプログラミング環境は限定されない。

図６は、上記ステップＳ１５における共有データ定義の不整合検査の詳細処理例を示すフローチャートである。
尚、ここでは、既にステップＳ１５で説明した、不整合検査の対象とする他のプログラミング環境から共有データ定義管理テーブル３０と共有データ変数宣言テーブル４０を取得する処理は、実行済みとする。そして、これら取得したテーブル３０、４０と、自装置で記憶していた管理テーブル３０、宣言テーブル４０とを、検査対象として、図示のステップＳ３１，Ｓ３２，Ｓ３３の処理を実行する。そして、この処理結果に基づいて上記ステップＳ１６の処理に相当する図示のステップＳ３４の表示処理を実行する。

上記ステップＳ３１，Ｓ３２，Ｓ３３の不整合検査処理について、以下、説明する。
尚、必ずしもステップＳ３１，Ｓ３２，Ｓ３３の全てを実行しなくても構わない。
尚、ここでは説明を簡単にするために、検査対象となるプログラミング環境は２つとする。よって、２つの共有データ定義管理テーブル３０と２つの共有データ変数宣言テーブル４０が、検査対象となる。

また、ここでは説明を簡単にする為に、検査対象の全プログラミング環境において共有データ定義管理テーブル３０の内容が同一である状態が、正常な状態（不整合はない）と見做すものとするが、この例に限らない。

また、以下のステップＳ３１，Ｓ３２，Ｓ３３の不整合検査処理の説明に際して、図７〜図１０に示す具体例を用いる場合もあるものとする。
ここで、図７、図８には初期状態における各プログラミング環境の共有データ定義管理テーブル３０、共有データ変数宣言テーブル４０の具体例を示す。

図９、図１０には、図７、図８の初期状態から始まって制御プログラム作成途中の状態の一例を示す。ここでは、新たな共有データ（変数Ｄ）が２種類の定義で追加された例を示している。

まず、図７、図８に示す初期状態例について説明する。
尚、ここではプログラミング環境１，２，３、・・ＮのＮ個のプログラミング環境があるものとし、各プログラミング環境１，２，３、・・Ｎに対応するコントローラ装置４の局番は、ＰＬＣ１、ＰＬＣ２、ＰＬＣ３、・・・、ＰＬＣｎとする。

まず最初に、例えばプログラミング環境１の共有データ定義支援装置３において、予め決定された共有データ定義に基づいて、図７の図上左上に示す内容の共有データ定義管理テーブル３０（初期状態）が作成される。そして、作成された共有データ定義管理テーブル３０（初期状態）が、他の全てのプログラミング環境（その共有データ定義支援装置３）に配信されて記憶される。これによって、図７、図８では省略して示すが、全てのプログラミング環境における共有データ定義管理テーブル３０の初期状態の内容は、図７の図上左上に示す内容と同一となっている。

図示のように、共有データ定義管理テーブル３０（初期状態）では、共有データ変数名３１が図示の“Ａ”、“Ｂ”、“Ｃ”の３種類の共有データが登録されている。そして、共有データ“Ａ”は、書込み局３４が“ＰＬＣ１”で参照局３５が“ＰＬＣ２”となっている。共有データ“Ｂ”は、書込み局３４が“ＰＬＣ２”で参照局３５が“ＰＬＣ１”となっている。共有データ“Ｃ”は、書込み局３４が“ＰＬＣ１”で参照局３５が“ＰＬＣ３”となっている。

そして、各プログラミング環境１，２，３、・・Ｎ毎に、その共有データ定義支援装置３において、上記共有データ定義管理テーブル３０（初期状態）に基づいて、共有データ変数宣言テーブル４０が生成される。

例えば、プログラミング環境１においては、管理テーブル３０（初期状態）の全レコードにおいて書込み局３４と参照局３５の何れかに“ＰＬＣ１”があるので、全ての共有データ“Ａ”、“Ｂ”、“Ｃ” に関する定義（変数名、データ型、アドレス等）がある共
有データ変数宣言テーブル４０が生成される。

例えば、プログラミング環境２においては、管理テーブル３０（初期状態）の共有データ“Ａ”、“Ｂ”のレコードにおいて書込み局３４と参照局３５の何れかに“ＰＬＣ２”があるので、図７に示すように共有データ“Ａ”、“Ｂ”に関する定義（変数名、データ型、アドレス等）がある共有データ変数宣言テーブル４０が生成される。

例えば、プログラミング環境３においては、管理テーブル３０（初期状態）の共有データ“Ｃ”のレコードにおいてのみ参照局３５に“ＰＬＣ３”があるので、図８に示すように共有データ“Ｃ”に関する定義（変数名、データ型、アドレス等）のみがある共有データ変数宣言テーブル４０が生成される。

また、上記各プログラミング環境１，２，３、・・Ｎ毎に、図示のように、上記生成された共有データ変数宣言テーブル４０のコピー等を、自己のプログラミング装置２に転送して上記宣言テーブル４０’として記憶させる。これより、例えば、プログラミング環境３においては、作業者は、共有データ“Ｃ”についてのみ認識しつつ制御プログラムを作成することになる。

その後、任意のときに、プログラミング環境２の作業者とプログラミング環境３の作業者とで申し合わせて、新たに必要となった共有データＤをこれら作業者間でのみ追加定義したものとする。更に、プログラミング環境１の作業者とプログラミング環境Ｎの作業者とで申し合わせて、新たに必要となった共有データＤをこれら作業者間でのみ追加定義したものとする。これらは、共有データの名称（変数名）は同じ（＝Ｄ）であるが定義内容が異なるものとする。そして、それぞれの定義内容が各プログラミング環境１，２，３、・・Ｎ毎にその作業者によって管理テーブル３０に反映されたものとする。

これより、例えば図９、図１０に示すように、プログラミング環境１、Ｎでは、それぞれ、図示の定義内容の共有データ“Ｄ”の定義が、例えば作業者によって手作業で管理テーブル３０に追加される。これは図示の例では（但し、プログラミング環境Ｎについては省略して示している）アドレス３３は‘ｘｘｘ１となっており’、書込み局３４は“ＰＬＣ１”、参照局３５は“ＰＬＣｎ”となっている。

また、プログラミング環境２、３では、それぞれ、図示の定義内容の共有データ“Ｄ”の定義が、例えば作業者によって手作業で管理テーブル３０に追加される。これは図では省略しているがアドレス３３は‘ｘｘｘ２’となっており、また図示のように書込み局３４は“ＰＬＣ２”、参照局３５は“ＰＬＣ３”となっている。

この様に、同一の共有データ（＝Ｄ）に対して異なる定義が存在することは問題であり、特にアドレスが異なるのは非常に問題であり、この様な不整合は解消されなければならない。

尚、正常な場合には、更に、上記各プログラミング環境１，２，３、・・Ｎ毎に、作業者等によって、上記更新後の管理テーブル３０に基づいて、図示のように新たな宣言テーブル４０が生成・記憶される。更に、当該新たな宣言テーブル４０のコピー等が、自己のプログラミング装置２に転送して上書き記憶される（旧宣言テーブル４０を削除して記憶する）。但し、作業者が、この様な宣言テーブル４０の更新作業を忘れる場合が有り得る（この様な場合、不整合が生じることになる）。

以下、図７〜図１０に示す具体例も用いて、ステップＳ３１，Ｓ３２，Ｓ３３の処理について説明する。
まず、ステップＳ３１では、不整合検査対象としている２つの共有データ定義管理テーブル３０同士を比較して、同一性を確認する。これは、例えば、共有データ変数名３１をチェックして、一方の管理テーブル３０に登録されている変数名の全てが、他方の管理テーブル３０にも登録されているか否かをチェックする（登録されていないものがある場合には、不整合と判定する）。あるいは、更に、後述する定義内容（特にアドレス）が同一か否かのチェックも行うようにしてもよい。

ここで、図９、図１０の例に関して、仮に不図示のプログラミング環境４における管理テーブル３０は、初期状態のままであったものとする。この場合、仮に、不整合検査対象がプログラミング環境１，４であった場合、プログラミング環境１の管理テーブル３０には共有データ“Ｄ”の定義があるが、プログラミング環境４の管理テーブル３０には共有データ“Ｄ”の定義はないことになる。

よって、この例では、不整合と判断すると共に、例えばステップＳ３４の表示処理においてプログラミング環境４の管理テーブル３０には共有データ“Ｄ”の定義が無い旨の表示を行って、作業者にプログラミング環境４の管理テーブル３０の修正を行わせるようにしてもよい。但し、これは管理テーブル３０に関しては全てのプログラミング環境で同一内容とすることを意図する場合の処理例では、この例に限らない。例えば以下に説明するような「同一の共有データ（変数名）に対して異なる定義（特にアドレス）が成されている場合のみ、不整合と判定するようにしてもよい。

すなわち、例えば、共有データ変数名３１が同一のレコード同士を比較して、定義内容が同一か否かをチェックする（少なくともアドレス３３が同一か否かをチェックするが、この例に限らず、更に書込み局３４と参照局３５も同一か否かをチェックするようにしてもよい）。定義内容が同一ではない場合も、不整合と判定する。

図９、図１０の例の場合、仮に不整合検査対象がプログラミング環境２，３であった場合、共有データ“Ａ”、“Ｂ”、“Ｃ”に関しては、定義内容が同一となる。更に、共有データ“Ｄ”に関しても、アドレス３３は同一（両方とも‘ｘｘｘ２’）であり。書込み局３４と参照局３５も同一である（両方とも“ＰＬＣ２”と“ＰＬＣ３”）。

一方、仮に不整合検査対象がプログラミング環境１，２であった場合、共有データ“Ａ”、“Ｂ”、“Ｃ”に関しては、定義内容が同一となる。しかし、共有データ“Ｄ”に関しては、アドレス３３が異なる（一方が‘ｘｘｘ１’で他方が‘ｘｘｘ２’）。また、書込み局３４と参照局３５も異なる（一方が“ＰＬＣ１”と“ＰＬＣｎ”で他方が“ＰＬＣ２”と“ＰＬＣ３”）。これより、ステップＳ３４の表示処理では、管理テーブル３０における共有データ“Ｄ”の定義が不一致である旨を表示することで、作業者にどちらか一方の管理テーブル３０の定義を修正させる（例えば、共有データ変数名３１を変更させる）。

ここで、この表示に応じて、作業者が、例えば、プログラミング環境２の管理テーブル３０の共有データ変数名３１を“Ｅ”に変更したとする。しかし、この場合、今度は、プログラミング環境２と３とで、管理データ３０の定義内容が不一致となってしまう。この不整合状態は、後にプログラミング環境２，３を検査対象とする本処理によって解消するが、それまでは不整合状態のままとなってしまう。

これより、例えば、作業者が管理テーブル３０の任意のレコードの共有データ変数名３１を変更した場合には、当該レコードの書込み局３４、参照局３５に係るプログラミング環境（その共有データ定義支援装置３）から管理テーブル３０も取得して、これを作業者に修正させるようにしてもよい。勿論、修正後の管理テーブル３０は、元のプログラミング環境に返信して、更新させる。

以上、ステップＳ３１について、具体例を用いながら説明した。
続いて、以下、ステップＳ３２について、具体例を用いながら説明する。
ステップＳ３２や後述するステップＳ３３の処理は、基本的に、管理テーブル３０と宣言テーブル４０との同一性をチェックするものである。両者の違いは、ステップＳ３２が管理テーブル３０をベースとするのに対して、ステップＳ３３では宣言テーブル４０をベースとする点である。つまり、ステップＳ３２は、基本的に、何らかの変数追加等に応じて管理テーブル３０が更新されていることを前提として、この変更を宣言テーブル４０に反映させるのを作業者が忘れるケースを想定している。ステップＳ３３は、その逆に、基本的に、何らかの変数追加等に応じて宣言テーブル４０が更新されていることを前提として、この変更を管理テーブル３０に反映させるのを作業者が忘れるケースを想定している。

ステップＳ３２では、例えば、不整合検査対象の共有データ定義管理テーブル３０の各共有データ変数名３１に対して定義された書込み局３４／参照局３５に、不整合検査対象のプログラミング環境に係わる局が含まれていた場合、この局に係わるプログラミング環境の共有データ変数宣言テーブル４０を参照し、該当する共有データ変数名４１の有無、および、その変数の定義（アドレスやデータ型）の同一性を確認する。この作業を、検査対象の全ての共有データ定義管理テーブル３０について実施する。

尚、局とはコントローラ装置４のことである。
図９、図１０の例の場合、仮に不整合検査対象がプログラミング環境１，２であったとし、まず、プログラミング環境１の管理テーブル３０を用いて上記処理を行うものとする。

この場合、まず、管理テーブル３０の共有データ“Ａ”を対象とすると、その書込み局３４＝ＰＬＣ１、参照局３５＝ＰＬＣ２であるので、書込み局３４と参照局３５とには、不整合検査対象のプログラミング環境１，２に係わる局が含まれていることになる。

よって、まず、プログラミング環境１の宣言テーブル４０の共有データ変数名４１に“Ａ”があるか否か（該当レコードの有無）をチェックする。図示の例では該当レコードがあるので、更に、この該当レコードのデータ型４２とアドレス４３が、上記管理テーブル３０の共有データ“Ａ”のレコードのデータ型３２とアドレス３３と同一か否かを確認することになる（図示していないが、ここでは同一であるものとする）。

更に、プログラミング環境２の宣言テーブル４０の共有データ変数名４１に“Ａ”があるか否か（該当レコードの有無）をチェックする。図示の例では該当レコードがあるので、更に、この該当レコードのデータ型４２とアドレス４３が、上記管理テーブル３０の共有データ“Ａ”のレコードのデータ型３２とアドレス３３と同一か否かを確認することになる（図示していないが、ここでは同一であるものとする）。

次に、管理テーブル３０の共有データ“Ｂ”を対象とすると、その書込み局３４＝ＰＬＣ２、参照局３５＝ＰＬＣ１であるので、書込み局３４と参照局３５とには、不整合検査対象のプログラミング環境１，２に係わる局が含まれていることになる。但し、この場合の処理は、上記共有データ“Ａ”を対象とした場合と同じとなるので、ここでは説明しない。

次に、管理テーブル３０の共有データ“Ｃ”を対象とすると、その書込み局３４＝ＰＬＣ１、参照局３５＝ＰＬＣ３であるので、書込み局３４に関しては、不整合検査対象のプログラミング環境１に係わる局が含まれていることになる。

よって、この場合には、プログラミング環境１の宣言テーブル４０の共有データ変数名４１に“Ｃ”があるか否か（該当レコードの有無）をチェックする。図示の例では該当レコードがあるので、更に、共有データ“Ｃ”に係わる定義内容の同一性チェックを行うことになる（図示していないが、ここでは同一であるものとする）。

次に、管理テーブル３０の共有データ“Ｄ”を対象とすると、その書込み局３４＝ＰＬＣ１、参照局３５＝ＰＬＣｎであるので、書込み局３４に関しては、不整合検査対象のプログラミング環境１に係わる局が含まれていることになる。

よって、この場合には、プログラミング環境１の宣言テーブル４０の共有データ変数名４１に“Ｄ”があるか否か（該当レコードの有無）をチェックする。図示の例では該当レコードがあるので、更に、共有データ“Ｄ”に係わる定義内容の同一性チェックを行うことになる（図示のように、少なくともアドレスに関しては同一（ｘｘｘ１）である）。

尚、上述したように、プログラミング環境１とプログラミング環境２とでは、共有データ“Ｄ”に関する定義が異なるのであるが、上記の通り、プログラミング環境１の管理テーブル３０の共有データ“Ｄ”の書込み局３４＝ＰＬＣ１、参照局３５＝ＰＬＣｎであるので、プログラミング環境２の宣言テーブル４０は上記の通りチェック対象とはならない。

次に、プログラミング環境２の管理テーブル３０を用いて上記処理を行うものとする。
この場合、共有データ“Ａ”、“Ｂ”、“Ｃ”に関しては、上記プログラミング環境１の管理テーブル３０を用いる場合と同じとなるので、説明は省略する。

続いて、プログラミング環境２の管理テーブル３０の共有データ“Ｄ”を処理対象とすると、その書込み局３４＝ＰＬＣ２、参照局３５＝ＰＬＣ３であるので、書込み局３４に関しては、不整合検査対象のプログラミング環境２に係わる局が含まれていることになる。

よって、この場合には、プログラミング環境２の宣言テーブル４０の共有データ変数名４１に“Ｄ”があるか否か（該当レコードの有無）をチェックする。図示の例では該当レコードがあるので、更に、共有データ“Ｄ”に係わる定義内容の同一性チェックを行うことになる（図示のように、少なくともアドレスに関しては同一（ｘｘｘ２）である）。

上述したように、例えばプログラミング環境１，２が検査対象の場合、例えばまずプログラミング環境１の管理テーブル３０に基づいて、その各共有データ毎に、その共有データに係わるプログラミング環境における宣言テーブル４０に、同一の定義が存在するか否かをチェックする（存在しない場合には、不整合ありと判定する）。

図示の例の場合、全ての共有データで定義同一となるので（ここでは、データ型は、不図示であるが、同一の定義となっているものとする）、不整合なしと判定されるものとする。

しかし、例えば、プログラミング環境１において、作業者等が共有データ“Ｄ”の追加に伴って管理テーブル３０は更新したが、これに伴う宣言テーブル４０の再作成を忘れていた場合等には、宣言テーブル４０が例えば図７、図８に示す初期状態のままであったとすると、共有データ“Ｄ”に関してはプログラミング環境１の宣言テーブル４０には該当する共有データ変数名４１は無いことになる。よって、この場合には、例えば、プログラミング環境１における管理テーブル３０と宣言テーブル４０との不整合がある（共有データ“Ｄ”に関する不整合あり）旨、表示されることになる。

この例の場合、続いて更に、プログラミング環境２の管理テーブル３０に基づいて、上記と同様のチェック処理を行うが、これについては説明は省略する。但し、１点だけ説明するならば、プログラミング環境２の管理テーブル３０の共有データ“Ｄ”に関しては、その書込み局３４＝ＰＬＣ２、参照局３５＝ＰＬＣ３であるので、プログラミング環境１の宣言テーブル４０はチェック対象とはならない。

従って、図９、図１０の例の場合には、不整合なしと判定されるものとする（ここでは、データ型は、不図示であるが、同一の定義となっているものとする）。
以上、ステップＳ３２の処理について説明した。

以下、ステップＳ３３の処理について説明する。
ステップＳ３３は、検査対象の各共有データ変数宣言テーブル４０毎に、その宣言テーブル４０に登録された各共有データ変数が、その宣言テーブル４０と同じプログラミング環境における共有データ定義管理テーブル３０に、同一定義で登録されているか否かをチェックする。尚、この例に限らず、検査対象の全ての共有データ定義管理テーブル３０について、上記宣言テーブル４０に登録された各共有データ変数が登録されているか否か等をチェックするようにしてもよい。

ステップＳ３３の処理は、基本的に、上述した「一部の作業者同士が申し合わせて、新たに必要となった共有データをこれら作業者間でのみ追加定義した（本例では上記共有データ“Ｄ”の追加）」ことに伴って、まず、共有データ変数宣言テーブル４０において追加定義を反映させるケースを想定している。尚、これは作業者等が例えば上記宣言テーブル４０’を更新することで、この更新が宣言テーブル４０に反映されるものであるが、この例に限らない。

上記のケースでは、共有データ変数宣言テーブル４０の更新後に、共有データ定義管理テーブル３０を更新（修正）することになるが、作業者が共有データ定義管理テーブル３０の更新（修正）を忘れることが起こり得る。これより、主に共有データ定義管理テーブル３０の更新忘れの有無をチェックする為に、ステップＳ３３の処理を行う。

尚、ここでは上記と同様に、プログラミング環境１，２が検査対象であるものとする。
上記ステップＳ３３の処理について、図９、図１０の例を用いて説明する。但し、結果的には図９、図１０に示す状態になるが、上記の通り、プロセスは異なるものとする。すなわち、プログラミング環境１において、作業者は、まず、そのプログラミング装置２に記憶されている共有データ変数宣言テーブル４０’に対して、上記共有データ“Ｄ”の追加定義を反映させる修正を行う。

そして、本例では、上述したように、プログラミング装置１の共有データ変数宣言テーブル４０’が更新された場合、この更新が自動的にプログラミング環境１の共有データ定義支援装置３の共有データ変数宣言テーブル４０に反映されるものとする。これより、プログラミング環境１の共有データ定義支援装置３の共有データ変数宣言テーブル４０は、図９、図１０に示す状態となるものとする。

更に、この宣言テーブル４０の更新内容を、プログラミング環境１の管理テーブル３０に反映させる必要があるが、宣言テーブル４０の内容からは書込み局３４、参照局３５は分からないので、これらは作業者が手作業で入力することになる。これによって、管理テーブル３０の内容は図９、図１０に示す状態となる。つまり、新たな共有データ“Ｄ”の定義が追加されている。

本例では、まず、プログラミング環境１の宣言テーブル４０について、当該宣言テーブル４０に格納されている各共有データ毎に、それが同環境（プログラミング環境１）の管理テーブル３０にも登録されているか否かを確認する。図９、図１０の例では、この宣言テーブル４０に格納されている共有データ“Ａ”、“Ｂ”、“Ｃ”、“Ｄ”の全てが、プログラミング環境１の管理テーブル３０に格納されている。よって、この例では不整合はないものと判定される。

プログラミング環境２に関しても、同様にして、プログラミング環境２の宣言テーブル４０について、当該宣言テーブル４０に格納されている各共有データ毎に、それが同環境（プログラミング環境２）の管理テーブル３０にも登録されているか否かを確認する。

図９、図１０の例では、プログラミング環境２の宣言テーブル４０には共有データ“Ａ”、“Ｂ”、“Ｄ”に関する定義が登録された状態となっており、共有データ“Ａ”、“Ｂ”、“Ｄ”の全てが、プログラミング環境２の管理テーブル３０に格納されている。よって、この例では不整合はないものと判定される。

尚、プログラミング環境１の管理テーブル３０とプログラミング環境２の管理テーブル３０とでは、共有データ“Ｄ”に関する定義が相互に異なっているが、ステップＳ３３の処理は、この点に関して検出／判別するものではない。この点に関しては、上記ステップＳ３１の処理によって判別している。

最後に、ステップＳ３４によって、上記ステップＳ３１，Ｓ３２，Ｓ３３の３つの整合性検査で確認した内容について、不整合となっている共有データ変数と、その不整合の内容などを表示する。作業者は、この表示内容に応じて、上記のように必要な修正作業を行うことになり、検査対象に関しては整合性がある状態とする。

上述したように、本手法の共有データ定義支援システムによれば、複数の作業者がそれぞれのプログラミング環境（そのプログラミング装置２）で共有データを用いる制御プログラムの作成作業を行っている途中に、一部の作業者が共有データ定義を追加した場合でも、任意のプログラミング環境の共有データ定義支援装置３において、一部の複数のプログラミング環境に関して共有データの定義の整合性を確認することができる。

何れか一つのプログラミング環境（その共有データ定義支援装置３）で整合性チェックを実施できるため、整合性確認を行う場所を限定しなくてもよく、更に、全てのプログラミング環境をチェック対象としなくてよいので、その他のプログラミング環境の作業者の制御プログラミング作業を中断させる必要がない。また、整合性の確認を段階的に行うことができるようになる。

以上説明した実施例を、実施例１とする。
以下、実施例２について説明する。
上述した実施例１の手法では、共有データの定義の変更に伴って発生する可能性のある不整合を、変更に関係する作業者のプログラミング環境で検査できるようにし、また、一部の作業者の環境から段階的に範囲を広げて、対象とする制御システム全体での共有データ定義の不整合の検査を実施可能とする方法を示している。

しかし、この方法では、共有データ定義で用いられているデータ型について、そのデータ型名が同一であるか否かの観点での不整合検査を行っているが、そのデータ型自体が各作業者のプログラミング環境において定義された派生データ型である場合は、考慮していなかった。例えば、複数の作業者のプログラミング環境で定義された派生データ型の名称が、偶然、同一であり、且つ、内部構造が異なる場合、その派生データ型の変数として宣言されている共有データを制御システム内で利用して情報を交換する際、その共有データの内容が、そのＰＬＣ局で期待しているものとは異なった構造であるために、正しく情報を交換することができない、という事態が発生する。

実施例２では、上述した実施例１では検出出来ない不整合を検出できるようにするものである。すなわち、実施例２では、制御システムを作成する複数のプログラミング環境で定義されている派生データ型の内部構造の不整合を、検査できるようにする。また、派生データ型が割り付けられている変数が、制御システム全体で利用される共有データであるか否かで、検査結果を区別することで、派生データ型を修正する際の影響範囲を特定した上で、修正作業を行うことができるようにするものである。

図１１は、実施例２の共有データ定義支援装置３’の機能ブロック図である。
尚、図１１において、上記図２に示す実施例１の構成と略同一の構成については、同一符号を付してあり、その説明は省略または簡略化する。

尚、共有データ定義支援装置３’も、上記共有データ定義支援装置３と同様に、例えば一例としてはパソコンやサーバ装置上で実現されるものであり、パソコン等の一般的なコンピュータのハードウェア構成を有するものである。従って、特に図示しないが、ＣＰＵ等の演算プロセッサ、ハードディスク、メモリ等の記憶部、キーボード、マウス等による入力操作部、液晶ディスプレイ等による表示部、通信機能部等を有している。

そして、例えば上記記憶部には、予め所定のアプリケーションプログラムが記憶されており、上記ＣＰＵ等がこのプログラムを実行することにより、以下に説明する各種機能部５１〜５７の機能処理や、図１２、図１３、図１６、図１７等のフローチャート図の処理等が実現される。

共有データ定義管理テーブル記憶部１３は、共有データ定義管理テーブル３０を記憶する。共有データ定義管理テーブル３０は、基本的には図２で説明した実施例１と略同様のデータ構成であるが、後述する図１４に示すように、そのデータ型３２に派生データ型の任意の名称が格納される場合が有り得る。

尚、上記実施例１では、不整合チェックの為に、例えばデータ型３２とアドレス３３を用いる場合があったが、この例に限らず、少なくともデータ型３２が一致するか否かを判定するようにしてもよい。これは、データ型３２とアドレス３３に限らず、データ型４２とアドレス４３についても同様である。

共有データ定義等転送部５７は、図２における共有データ変数宣言テーブル転送部１６や共有データ定義管理テーブル転送部１７に相当する機能部であり、各プログラミング装置２や他の共有データ定義支援装置３等から、共有データの定義等に係わる情報等を取得する。取得した情報は、上記共有データ定義管理テーブル記憶部１３に記憶される。

上記構成以外にも、図２に示す実施例１の構成があってもよいが、ここでは省略して示し、説明は行わないものとする。そして、実施例２の共有データ定義支援装置３’においては、更に、図示の派生データ型定義転送部５１、派生データ型定義管理テーブル記憶部５２、派生データ型整合性検査部５３、派生データ型内部構造変換部５４、派生データ型割付け変数検査部５５、派生データ型検査結果表示部５６等の各種機能部を有する。

派生データ型定義転送部５１は、複数のプログラミング装置２から派生データ型定義情報を取得して、これに基づいて後述する派生データ型定義管理テーブル６０を作成する。派生データ型の定義情報は、後に図１９に一例を示すように、例えばテキスト形式で記述されている。この様なテキストファイルを各プログラミング装置２から取得して、そこから後述するように派生データ型の名称や、その内部構造の情報等を抽出して、これらを例えば後述する図１５に示すデータ構成の派生データ型定義管理テーブル６０に格納する。詳しくは後述する。

但し、これは一例であり、この例に限らない。例えば、派生データ型の定義情報は、最初から派生データ型定義管理テーブル６０のようなテーブル形式で、各プログラミング装置２に記憶されていてもよい。換言すれば、派生データ型の定義情報のデータ形式は、何でも良い（テキスト形式でもよいし、テーブル形式でもよいし、他の形式でもよい）。

何れの形式であっても、派生データ型の定義情報には、基本的に、各派生データ型毎に、その名称と内部構造情報等が含まれている。そして、本手法では、名称が同一である派生データ型の内部構造情報同士を比較して、該内部構造情報が不一致の場合には不整合と判定する。

派生データ型定義管理テーブル記憶部５２は、上記派生データ型定義転送部５１によって生成された派生データ型定義管理テーブル６０を記憶する。
派生データ型整合性検査部５３は、上記派生データ型定義管理テーブル記憶部５２に記憶された派生データ型定義管理テーブル６０等に基づいて、同一名称の派生データ型がある場合には、その内部構造の整合性を検査する。すなわち、例えば同一名称の２つの派生データ型について、一方の内部構造が他方の内部構造と同じであるか否かをチェックする。つまり、同一名称の２つの派生データ型の内部構造が同じであるか否かをチェックする。

派生データ型内部構造変換部５４は、例えば上記派生データ型整合性検査部５３が上記整合性検査処理中に必要に応じて呼び出す機能部である。
派生データ型内部構造変換部５４は、上記派生データ型の内部構造が所定の条件を満たす場合に、その内容を所定のルールに従って変換し、この変換結果を派生データ型整合性検査部５３に渡す。派生データ型整合性検査部５３は、この変換結果を用いて、上記内部構造の整合性を検査する。上記内部構造としては、例えば配列、構造体等がある。例えば“構造体”を例にすると、複数の構造体メンバ名が同一であっても順番が異なる場合を想定し、所定のルール（例えば、アルファベット順）に従って構造体メンバ名をソートしたうえで、整合性を検査する。

派生データ型割付け変数検査部５５は、派生データ型整合性検査部５３による検査で不整合と判定された派生データ型が、上記共有データのデータ型として使用されているか否かを判定する。システム上の全ての共有データが、上記共有データ定義管理テーブル３０に登録されているはずであるので、この管理テーブル３０の上記データ型３２に、上記不整合と判定された派生データ型の名称が格納されているか否かを判定する。格納されていれば、派生データ型整合性検査部５３による検査で不整合と判定された派生データ型が、上記共有データのデータ型として使用されていることになる。

派生データ型検査結果表示部５６は、上記各種検査結果／判定結果を表示する。
派生データ型検査結果表示部５６は、例えば、上記派生データ型整合性検査部５３による検査で不整合と判定され、更に共有データのデータ型として使用されていると判定された派生データ型と当該共有データについて、その名称、内部構造、定義した局、共有データとして利用している局等を表示する。但し、この例に限らない。例えば、共有データのデータ型としては使用されていない、例えばローカルの変数に関してのみ使用されていると見做してよい派生データ型についても、その名称、内部構造、定義した局等を表示するようにしてもよい。

あるいは、派生データ型検査結果表示部５６は、例えば、上記共有データのデータ型として使用されているか否かは関係なく、上記派生データ型整合性検査部５３による検査で不整合と判定された派生データ型について、上記内部構造情報等に基づく何等かの所定情報を表示するようにしてもよい。例えば、当該派生データ型の名称や定義した局、あるいは当該派生データ型に係わる構造体メンバ名あるいは配列情報（開始インデックス、終了インデックス）等を、表示するようにしてもよい。

派生データ型の場合、その名称や内部構造をユーザが任意に決定・設定できる。この為、実施例１においてデータ型が同一と判定された場合でも、実際には名称は同一であるが内容は同一ではない（内部構造が異なっている）場合が有り得る。実施例２では、この様な場合、データ型が異なるもの（不整合）と判定できる。

更に、不整合と判定された派生データ型が割り付けられている変数が、制御システム全体で利用される変数（共有データ）であるか否かを判別でき、この判別結果によって検査結果を区別することができ、派生データ型を修正する際の影響範囲を特定した上で、修正作業を行うことができる。

図１２、図１３は、実施例２における共有データ定義の不整合を検出するための作業フロー（１／２）、（２／２）である。この不整合検出には、派生データ型の内部構造の整合性を検査する処理も含まれる。尚、図１２、図１３は、１つのフローを２つに分けて示しているのであり、特に区別せずに図１２等と記すものとする。

図１２等に示す例では、各作業は、次のような手順で実施することができる。
並行してプログラミング作業を行う各作業者は、それぞれ、自己のプログラミング環境において、自己が作成する制御プログラムで利用する派生データ型や、共有データ変数の定義を作成する（ステップＳ４１）。その後、任意のときに、ステップＳ４２以降の処理を実行する。尚、作業者は、制御プログラム作成作業を、自己のプログラミング環境におけるプログラミング装置２において行う。

以下、まず、ステップＳ４２の処理について説明する。
任意のときに、共有データ定義支援装置３’は、その共有データ定義等転送部５７によって、各プログラミング装置２や他の各共有データ定義支援装置３等から、それらのプログラミング環境における共有データ変数の定義を取得して、これに基づいて共有データ定義管理テーブル３０に新規データ登録する。また、派生データ型定義転送部５１が、各プログラミング環境（各プログラミング装置２や各共有データ定義支援装置３等）から派生データ型の定義情報等を取得して、これに基づいて派生データ型定義管理テーブル６０に新規データ登録する（ステップＳ４２）。この処理の具体例は後述する。

ここで、図１５に派生データ型定義管理テーブル６０の具体例を示す
図１５に示す例では、派生データ型定義管理テーブル６０のデータ構造は、図示の派生データ型名６１、配列／構造体６２、取得局６３、要素データ型６４、開始Index６５、
終了Index６６、構造体メンバ名６７の各データ項目より成る。

各派生データ型毎に、その名称が派生データ型名６１に格納され、それを定義したＰＬＣ局(プログラミング装置２)を示す情報が、取得局６３に格納される。これら以外のデータ項目は、全て纏めて内部構造の情報と見做してよい。尚、内部構造に係わるデータ項目全てにデータが格納されるわけではない。

つまり、図１５に示すように、その派生データ型の種別（配列／構造体６２）が、“配列”である場合には、開始Index６５、終了Index６６にデータ格納されるが、構造体メンバ名６７にはデータ格納されない。その逆に、その派生データ型の種別が“構造体”である場合には、構造体メンバ名６７にはデータ格納されるが、開始Index６５、終了Index６６にデータ格納されない。

すなわち、配列／構造体６２が上記“配列”である場合には、配列の開始インデックス、終了インデックスが、開始Index６５、終了Index６６に格納されると共に、データ型が要素データ型６４に格納される。尚、「終了Index６６−開始Index６５＋１」によって後述する要素数を算出できる。これより、図１５に示す例では、種別が“配列”である派生データ型は、２つとも要素数が１０個であることになる。

また、配列／構造体６２が上記“構造体”である場合には、その各メンバーの名称が構造体メンバ名６７に格納されると共に、これら各メンバーのデータ型が、要素データ型６４に格納される。尚、後述する不一致判定の際には、全てのメンバーについて、その名称が一致するだけでなくデータ型も一致しなければ、一致するものと見做さないものとする。但し、この例に限らず、名称だけが一致すればよいものとしてもよい。

また、派生データ型定義管理テーブル６０の各レコードは、上記のように各プログラミング装置２から取得した派生データ型定義情報に基づいて生成されるものであり、取得元のプログラミング装置２を示す情報が、取得局６３に格納される。尚、基本的／一般的に、任意の派生データ型が任意のプログラミング装置２において定義された場合、その派生データ型定義情報は、当該定義が行われたプログラミング装置２に格納・管理されているものである。

また、共有データ定義管理テーブル３０に関しても、図１４に具体例を示すが、そのデータ構成自体は図３（ａ）に示す実施例１の構成と同じであってよく、同一符号を付してあり、説明は省略する。但し、図１４に示すように、実施例２の場合、共有データ変数のデータ型３２として、派生データ型が指定される場合がある。

上記ステップＳ４２の処理を実行したら、続いて、以下のステップＳ４３の処理を実行する。
ステップＳ４３では、派生データ型定義管理テーブル６０を検索して、同一名称の派生データ型が存在するか否かをチェックする。これは、例えば、派生データ型定義管理テーブル６０の各レコードを順次チェック対象レコードにして、チェック対象レコードの派生データ型名６１を取得して、この名称と同一名称の派生データ型名６１を有する他のレコードがあるか否かをチェックする。

例えば、図１５に示す例では、“USR_TYP_A”と“USR_TYP_B”に関しては同一名称の派生データ型は存在しないが、“USR_TYP_C”に関しては同一名称の派生データ型が存在す
ることになる。つまり、図示の３番目のレコードと４番目のレコードは、どちらも、派生データ型名６１が“USR_TYP_C”である。

例えば上記一例のように同一名称の派生データ型が存在する場合には、更に、その内部構造について、定義内容が一致しているか否かをチェックする。
（以上、ステップＳ４３）
上記定義内容が一致しているか否かをチェックする処理は、例えば、図１５に示す例における構造体メンバ名６７（あるいは開始Index６５及び終了Index６６）が一致しているか否かをチェックし、不一致の場合には不整合（ステップＳ４４，ＹＥＳ）と判定する処理である。勿論、それ以前に、配列／構造体６２が不一致であれば不整合と判定する（ステップＳ４４，ＹＥＳ）。また、上記構造体メンバ名６７（あるいは開始Index６５及び
終了Index６６）が一致していても、更に要素データ型６４が一致するか否かをチェック
し、不一致の場合には不整合（ステップＳ４４，ＹＥＳ）と判定するようにしてもよい。

同一名称の派生データ型が存在しない場合、または、同一名称の派生データ型が存在するが、それらの内部構造が一致している場合には、不整合は検出されなかったものとして（ステップＳ４４，ＮＯ）、本処理を終了する。

但し、上記ステップＳ４４がＹＥＳの場合でも、以下のステップＳ４５の処理を行って以下のステップＳ４６の判定がＮＯとなった場合には、実質的に不整合は検出されなかったものとして本処理を終了するようにしてもよい。但し、この例に限らず、例えば実質的には不整合ではないが、順番等の修正が必要である」旨のメッセージを表示するようにしてもよい。また、このメッセージは、同一名称の派生データ型に係わる取得局６３（プログラミング装置２等）に通知して表示させるようにしてもよい。図１５の例では、ＰＬＣ１とＰＬＣ２にメッセージ通知して表示させることになる。

以下、ステップＳ４５の処理について説明する。
ステップＳ４５では、上記同一名称の派生データ型に関してその内部構造が不一致のものが存在する場合、これを処理対象として、まず、当該内部構造が、変換対象となるものであるか否かを判定する。

これは、例えば、配列／構造体６２等を参照して、変換対象となるか否かを判定する。一例としては、配列／構造体６２が不一致の場合には、変換対象とはならない。例えば、処理対象の一方が“配列”で他方が“構造体”である場合には、変換しても意味がない（一致する可能性はない）からである。また、処理対象の配列／構造体６２が両方とも“配列”である場合には、その要素数が同一である場合に、変換対象とする。逆に言えば、配列要素数が異なる場合には、変換対象とはならない。

あるいは、処理対象の配列／構造体６２が両方とも“構造体”である場合には、構造体メンバ名６７の数が異なる場合、変換対象とはならない。上記図１５の例の場合、構造体メンバ名６７の数は、３番目のレコードは３つ、４番目のレコードは２つであるので、後述するように順番を変更しても両者が一致する可能性は無いことになるので、変換対象とはならない。

上記処理対象が変換対象であると判定された場合は、所定のルールに従って内部構造の変換を行い、当該変換後の内部構造について整合性をチェックする。このチェックの結果、変換後の内部構造は一致すると判定された場合には（ステップＳ４６，ＮＯ）、上記のように本処理を終了してもよいが、警告対象の派生データ型として記録して、上記メッセージ通知や検査結果表示させるようにしてもよい。

一方、変換後の内部構造も不一致と判定された場合には（ステップＳ４６，ＹＥＳ）、ステップＳ４７以降の処理を実行する。換言すれば、上記変換後も不一致となる派生データ型を含む、上記名称は同一であるが内部構造が不一致となる派生データ型が、１つ以上ある場合には、ステップＳ４７以降の処理を実行する。ステップＳ４７以降の処理については後述する。

ここで、上記ステップＳ４５の処理について、以下、更に具体的に説明する。
ここで、変換対象とする内部構造の例としては、“配列”構造の場合、要素数が同一であり、且つ、開始インデックス、終了インデックスが異なる場合がある。このような場合は、例えば、開始インデックスを‘１’として揃え、終了インデックスを配列要素数に置き換える、等の変換方法が考えられる。例えば、処理対象の一方が開始Index６５＝‘２
’、終了Index６６＝‘１１’であり、他方が開始Index６５＝‘０’、終了Index６６＝‘９’であった場合、両方とも配列要素数は‘１０’であるので、上記変換方法によって両方とも開始インデックス＝‘１’、終了インデックス＝‘１０’となる。従って、この例では、変換後の内部構造は一致するものと判定されることになる（ステップＳ４６，ＮＯ）。

尚、“配列”構造の場合には、上記“変換対象となる”（配列要素数が同一である）と判定した場合には、変換後の内部構造は一致するものと見做しても良い。配列要素数が同一であれば、上記変換手法であれば、変換後の開始インデックス、終了インデックスは、同一となるはずであるからである。

あるいは、構造体の場合、構造体メンバの名称やデータ型（構造体メンバ名６７や要素データ型６４）は同一であっても、それらメンバの定義順序が異なる場合がある。このような場合は、例えば、構造体メンバ名６７における複数の構造体メンバ名の順番を、メンバ名称の昇順や降順（例えばアルファベット順や、５０音順など）、あるいはその要素データ型６４のデータサイズの昇順や降順等といったルールに従って、並べ替える、等の方法が考えられる。内容的に同一であれば（順番が異なるだけであれば）、上記並び替えを行うことで、当該変換後の内部構造は一致するはずである。

尚、上述したような変換条件は、利用しているプログラミング環境における、データ型と変数へのアドレス割付けルールを元に設定してもよい。
上述した処理によって検出された、名称は同一であるが内部構造の定義内容が不一致であった全ての派生データ型について、更にステップＳ４７以降の処理を実行する。換言すれば複数のプログラミング環境で（偶然）同一名称の派生データ型が定義されたが両者の内部構造が異なる場合には、これら派生データ型を処理対象として更にステップＳ４７以降の処理を実行する。

ステップＳ４７の処理では、まず、上記処理対象の各派生データ型が、各々、共有データ変数のデータ型として使用されているか否かを判定する。つまり、上記処理対象の各派生データ型が、それぞれ、共有データ定義管理テーブル３０に登録されている共有データ変数の何れか１つ以上に、データ型３２として割付けられているか否かをチェックする。尚、上記一例における“USR_TYP_C”は、図１４に示す例では共有データ変数名３１が“ＸＸＸ２”の共有データ変数のデータ型３２として割付けられている。

上記共有データ変数が存在する場合、すなわち“同一名称で内部構造が異なる派生データ型”（“該当派生データ型”と呼ぶものとする）が割付けられている共有データ変数が有る場合には（ステップＳ４８．ＹＥＳ）、以下に説明するステップＳ４９の処理を行って後述するステップＳ５１の処理を実行する。一方、上記“該当派生データ型”が割り付けられた共有データ変数が１つも存在しない場合には（ステップＳ４８，ＮＯ）、後述するステップＳ５０の処理を行って後述するステップＳ５１の処理を実行する。

ステップＳ４９の処理では、まず、上記“該当派生データ型”が割り付けられている共有データ変数やこの“該当派生データ型”に係わるＰＬＣ局（プログラミング装置２）を判別する。すなわち、例えば、上記該当派生データ型が、どのＰＬＣ局で定義されたものであるかを、例えば図１５に示す派生データ型定義管理テーブル６０を参照して判別する。つまり、“該当派生データ型”に対応する取得局６３を、この“該当派生データ型”が定義されたＰＬＣ局と見做す。

上記具体例の場合、図１５に示す派生データ型定義管理テーブル６０において、その派生データ型名６１が“USR_TYP_C”であるレコードは、２つあり、一方は取得局６３が“ＰＬＣ１”、他方は取得局６３が“ＰＬＣ２”となっている。これより、上記２つの派生データ型“USR_TYP_C”は、一方が“ＰＬＣ１”で定義され、他方が“ＰＬＣ２”で定義されたものと判別される。勿論、これら２つの派生データ型“USR_TYP_C”は、上記の通り、名称は（偶然）同一となっているが定義内容（内部構造）は相互に異なるものである。

また、ステップＳ４９の処理では、上記”該当派生データ型“が割り付けられている共有データ変数を利用しているＰＬＣ局（変数利用ＰＬＣ局）を、共有データ定義管理テーブル３０を参照して判別する。これは、該当レコードの書込み局３４、参照局３５等を取得する。該当レコードとは、そのデータ型３２が上記”該当派生データ型“であるレコードであり、上記“USR_TYP_C”の例では、該当レコードの書込み局３４は“ＰＬＣ１”、参照局３５は“ＰＬＣ２”となっており、これらが上記“変数利用ＰＬＣ局”であると見做す。

ステップＳ４９の処理では、最後に、上記判別結果等に基づく表示を行う。例えば、上記“該当派生データ型”が割付けられている共有データ変数や、この共有データ変数を利用しているＰＬＣ局等や、この“該当派生データ型”の名称、この“該当派生データ型”が定義されたＰＬＣ局等を、検査結果としてディスプレイ等に表示する。尚、この検査結果を表示する際には、ユーザに必ず修正を行うように要求するエラー表示とすることが望ましい。

この検査結果表示内容が、上記“該当派生データ型”おける「共有データ変数としての制御システム内での影響範囲」となる。例えば上記“USR_TYP_C”の例の場合、制御システム内には仮にＰＬＣ１〜ＰＬＣｎのｎ台のＰＬＣ局があっても、影響範囲は、ＰＬＣ１とＰＬＣ２に限られることになる。よって、この例の場合、例えばＰＬＣ１とＰＬＣ２に対してのみ上記検査結果を通知して表示させるようにしてもよい。これより、この例では、ステップＳ５１の修正作業を行うのは、ＰＬＣ１とＰＬＣ２の各プログラミング装置２の担当者等となる。例えば、これら各担当者が、話し合って、例えば何れか一方の派生データ型の名称を変更する等、何等かの対応を行うことになる。

尚、ステップＳ５１では、上記ステップＳ４９による表示、あるいは後述するステップＳ５０による表示後、該当する各プログラミング装置２の担当者等に、派生データ型の定義内容や、共有データ変数の定義内容を、修正させる。

一方、上記の通り、上記ステップＳ４８の判定がＮＯの場合には、ステップＳ５０の処理による表示を行って、上記ステップＳ５１の修正作業を行わせる。
すなわち、上記“該当派生データ型”が割付けられている共有データ変数が無ければ（ステップＳ４８，ＮＯ）、この“該当派生データ型”を定義したＰＬＣ局の情報や、該当派生データ型の名称等を、検査結果として表示する（ステップＳ５０）。その際、共有データ変数には割り付けられていない旨の表示も行うようにしてもよい。この場合、この表示を見た担当者等は、この“該当派生データ型”は、該当ＰＬＣ局のローカル変数にのみ利用されている等と、影響範囲を判断できる。尚、この検査結果を表示する際には、必ず修正すべきものとしてエラー表示としても良いし、影響範囲がローカルに限定されることから、警告表示としても良い。

尚、「影響範囲を判断する」のは、例えば、複数のプログラミング環境で共通して利用される「共有データ変数」（制御システムの中ではグローバル変数的な意味合いとなる）と、あるプログラミング環境の中だけで利用される変数（ローカル変数的な意味合いとなる）に分けることで、修正対象の範囲の違いを示すことを意図している。但し、この例に限らない。

また、「共有データ変数」の修正は、その変数を利用（読込み・書込み）しているプログラミング装置全てにおいて、その変数定義に修正が必要になる。これより上記のように、共有データ定義管理テーブル３０を参照することで、修正対象の派生データ型を利用している共有データ変数名３１と利用局（書込み局３４、参照局３５）を特定し、ユーザー等に対して表示する。

一方、あるプログラミング装置のみで利用される変数（ローカル変数など）においては、変数定義の修正の影響が及ぶ範囲は、その装置内のみとなる。この場合、プログラミング装置内の変数定義を参照することで、修正対象の派生データ形を利用している変数名を特定し、ユーザー等に対して表示する。

上記修正作業が行われた後、再び上記ステップＳ４２以降の処理を実行し（再検査を実行し）、不一致が検出されなければ（ステップＳ４４等がＮＯ）本処理を終了する。未だ不一致が検出される状態であれば、再び上記エラー表示等を行って、再度、修正作業を行わせるようにしてもよい。

図１６は、上記ステップＳ４３の処理の詳細フローチャート図である。
ステップＳ４３の処理は、上記のように、同一名称で内部構造が不一致となっている派生データ型を、抽出するものである。

図１６に示す処理例では、まず、派生データ型定義管理テーブル６０において任意のレコードを照合元とする（ステップＳ６１）。
そして、この照合元レコードを基準にして、派生データ型定義管理テーブル６０における他の登録データ（他のレコード）を順次比較対象として、同一のデータ型名称（派生データ型名６１）を持つ登録データが存在しないかをチェックする。すなわち、照合元レコードの派生データ型名６１と同一の派生データ型名６１を有するレコードが、存在するか否かを検索する（ステップＳ６２）。

照合元と同一名称の登録データが１つも無い場合には（ステップＳ６３，ＮＯ）、ステップＳ６７へ移行して、ステップＳ６７において新たな照合元を決定してステップＳ６２に戻る。但し、新たな照合元が最後のレコードである場合には（ステップＳ６８，ＹＥＳ）、他のレコードと比較する意味がないので、本処理を終了する。

尚、図１５の例では、先頭レコードから順次、照合元とする場合、最初は照合元の派生データ型名称が“USR_TYP_A”であり、他に派生データ型名６１が“USR_TYP_A”であるレコードは存在しないので、ステップＳ６３はＮＯとなる。そして、次の照合元の名称は“USR_TYP_B”であるので、これも他に派生データ型名６１が“USR_TYP_B”であるレコードは存在しないので、ステップＳ６３はＮＯとなる。そして、次の照合元となる３番目のレコードの派生データ型名６１は“USR_TYP_C”であるので、４番目のレコードの派生データ型名６１も“USR_TYP_C”であることから、ステップＳ６３はＹＥＳとなる。

照合元と同一名称の登録データがある場合には（ステップＳ６３，ＹＥＳ）、照合元レコードの内部構造情報と、これと同一名称を持つ登録データの内部構造情報とを照合して、一致／不一致を判定する（ステップＳ６４）。

ステップＳ６４の処理は、一例としては例えばまず、上記照合対象の２つのレコードの配列／構造体６２が一致するか否かを判定し、不一致である場合には内部構造が不一致と判定する（ステップＳ６５，ＹＥＳ）。配列／構造体６２が一致する場合には、続いて、配列／構造体６２に応じた内部構造情報を照合に用いる。

すなわち、配列／構造体６２が“構造体”である場合には、両レコードの構造体メンバ名６７同士を比較して、完全に一致するか否かを判定する。上記の通り、ここでは、順番が異なるだけであっても不一致と判定する。更に、上記構造体メンバ名６７に対応する要素データ型６４同士も比較して、完全に一致するか否かを判定するようにしてもよい。

上記“USR_TYP_C”の例の場合、上記３番目のレコードと４番目のレコードとでは、構造体メンバ名６７は全く異なるし、要素データ型６４も全く異なるので、内部構造が不一致と判定される（ステップＳ６５，ＹＥＳ）。尚、この例のように、構造体である場合には、基本的には、照合元と、これと同一名称の登録データとで、構造体メンバ名６７が完全に一致し、且つ、要素データ型６４も完全に一致する場合のみ、内部構造が一致すると判定する（ステップＳ６５，ＮＯ）が、この例に限らない。

また、配列／構造体６２が“配列”の場合には、両レコードの開始Index６５と終了Index６６の両方が一致するか否かを判定する。一致する場合には、更に、両レコードの要素データ型６４も一致するか否か判定し、一致する場合には内部構造が一致と判定する（ステップＳ６５，ＮＯ）。但し、これは一例であり、この例に限らず、例えばIndex６５と終了Index６６の両方が一致すれば、内部構造が一致すると判定するようにしてもよい（ステップＳ６５，ＮＯ）。

内部構造が一致すると判定された場合には（ステップＳ６５，ＮＯ）、そのまま上記ステップＳ６７の処理へ移行する。内部構造が不一致と判定された場合には（ステップＳ６５，ＹＥＳ）、以下に説明するステップＳ６６の処理を実行して、上記ステップＳ６７の処理へ移行する。

ステップＳ６６の処理は、例えば、上記照合元レコードと、これと同一名称の登録データから、名称（派生データ型名６１）や、各々が定義されていたＰＬＣ局（取得局６３）等の情報を取得して、所定の記憶領域に記録する。当該記録した情報は、例えば上記ステップＳ４７，Ｓ４９．Ｓ５０等の処理の際に利用される。尚、この例に限らず、例えば上記照合元レコードとこれと同一名称の登録データから、その内部構造情報全てを取得して記録するようにしてもよい。

図１７は、上記ステップＳ４７の処理の詳細フローチャート図である。
上記ステップＳ４７の処理は、派生データ型定義の内部構造不一致検査（上記ステップＳ４３等）の結果、不一致が検出された派生データ型が、共有データ変数のデータ型として割付けられているものであるか否かを、チェックする処理である。

図１７に示す処理例では、まず、例えば上記図１６のステップＳ６６の処理で記憶された情報を参照して、複数のプログラミング環境で定義された、相互に名称は同じだが内部構造が異なる派生データ型（上述した“該当派生データ型”）の情報を、１つ取得して判定対象とする（ステップＳ７１）。この取得情報には、少なくとも“該当派生データ型”の名称が含まれている。

そして、上記判定対象の“該当派生データ型”の名称を用いて、共有データ定義管理テーブル３０を検索することで、該当する登録データがあるか否かを判定する（ステップＳ７２）。これは、例えば、共有データ定義管理テーブル３０の全レコードについて、順次、そのデータ型３２が上記判定対象の該当派生データ型の名称と一致するか否かを判定し、一致するレコードは全て“該当登録データ”として抽出する。

そして、上記“該当登録データ”が１つ以上ある場合には（ステップＳ７３，ＹＥＳ）、この“該当登録データ”の情報（共有データ変数名３１、書込み局３４、参照局３５等）を、上記判定対象の“該当派生データ型”の記録情報等と関連付けて記録する（ステップＳ７４）。ここで記録されたデータは、検査結果表示等に用いられる。

そして、次の判定対象の“該当派生データ型”を決定して、その上記記憶情報を取得して（ステップＳ７５）、上記ステップＳ７２の処理へ戻る。但し、次の判定対象が存在しない場合には（ステップＳ７６、ＹＥＳ）本処理を終了する。

尚、上記“該当登録データ”が１つも無い場合には（ステップＳ７３，ＮＯ）、そのまま上記ステップＳ７５の処理へ移行する。
図１８に、上記図１４、図１５の例における上記ステップＳ４３、Ｓ４７の処理イメージを示す。

上記ステップＳ４３の処理では、派生データ型定義管理テーブル６０から、“相互に名称は同じだが内部構造が異なる派生データ型”（該当派生データ型）を抽出する。図１５の例の場合、図１８に示すように、派生データ型名６１が“USR_TYP_C”である２つのレコードが抽出されることになる。

そして、ステップＳ４７で、共有データ定義管理テーブル３０において、この派生データ型“USR_TYP_C”がデータ型３２となっている共有データ変数を探す。もし、この様な共有データ変数があれば、エラー表示の為に必要なデータを取得して記憶する。例えば、図１８に示すように、共有データ変数“ＸＸＸ２”のデータ型が上記“USR_TYP_C”となっているので、その書込み局３４＝“ＰＬＣ１”、参照局３５＝“ＰＬＣ２”等を取得して記憶する。そして、後にエラー表示等の際にこの記憶データを表示に用いる。

図１９（ａ）、（ｂ）に、上記ステップＳ４２の処理で各プログラミング環境（各プログラミング装置２等）から取得する、派生データ型の定義情報の一例を示す。
尚、ここでは、派生データ型の定義情報は、各プログラミング装置２内の派生データ型定義用のファイルに、テキスト形式で記述されているものとする。これより、上記ステップＳ４２におけるこの定義情報に基づくテーブル６０の作成処理は、配列や構造体の定義書式に基づいて上記テキストファイルの記述内容をファイルの先頭から順に解析し、この解析結果を順にテーブル６０の新規レコードの該当欄に追記することで実現させる。但し、これは一例であり、この例に限らない。

また、ここでは、図１９（ａ）はＰＬＣ１における派生データ型の定義情報、図１９（ｂ）はＰＬＣ２における派生データ型の定義情報の一例であるものとする。
そして、配列、構造体それぞれについて１つずつ例を挙げて、以下に説明するものとする。

まず、配列に関して、ＰＬＣ１，ＰＬＣ２の両方とも、図示のテキストファイルの３行目において、その名称が“ARRAY_A1”である派生データ型（これを、派生データ型“ARRAY_A1”等と記す場合もあるものとする）の定義を行っている。すなわち、派生データ型“ARRAY_A1”について、下記のような定義を行っている。尚、名称が同じであるのは、例えば偶然の一致であるが、この例に限らない。

ＰＬＣ１の場合；
ARRAY_A1 : ARRAY[1..64] OF INT
ＰＬＣ２の場合；
ARRAY_A1 : ARRAY[0..63] OF INT
この様に、図示の例では、配列に係わる派生データ型の定義は、
派生データ型名称 ： ARRAY[開始Index..終了Index] OF データ型
の形式で記述される。

これより、上記の例では、ＰＬＣ１から取得した定義情報に基づいて、テーブル６０には、派生データ型名６１＝“ARRAY_A1”、配列／構造体６２＝“配列”、取得局６３＝“ＰＬＣ１”、要素データ型６４＝“ＩＮＴ”、開始Index６５＝“１”、終了Index６６＝“６４”のレコードが、新規追加されることになる。

同様にして、ＰＬＣ２から取得した定義情報に基づいて、テーブル６０には、派生データ型名６１＝“ARRAY_A1”、配列／構造体６２＝“配列”、取得局６３＝“ＰＬＣ２”、要素データ型６４＝“ＩＮＴ”、開始Index６５＝“０”、終了Index６６＝“６３”のレコードが、新規追加されることになる。

つまり、これら２つの新規追加レコードは、配列要素の定義（開始Index６５＆終了Index６６）が相互に異なるので、ステップＳ４３の処理で不一致と判定されることになる。
但し、上記ステップＳ４５の処理によって、例えば配列要素のインデックス番号を‘１’から開始するルールに従って変換することで、両方とも、開始Index＝“１”、終了Index＝“６４”となるので、ステップＳ４５では両者は一致するものと判定されることになる。

また、構造体に関して、ＰＬＣ１，ＰＬＣ２の両方とも、図示のテキストファイルの７〜１１行目において、派生データ型“STR_S1”の定義を行っている。すなわち、下記のような定義を行っている。
（１）ＰＬＣ１の場合；
STR_S1:
STRUCT
LDATA : DWORD;
UDATA : DWORD;
END_STRUCT;
（２）ＰＬＣ２の場合；
STR_S1:
STRUCT
UDATA : DWORD;
LDATA : DWORD;
END_STRUCT;
この様に、図示の例では、構造体に係わる派生データ型の定義は、
派生データ型名称 ：
SUTRUCT
メンバ名 ： データ型；
〜
メンバ名 ： データ型；
END_STRUCT;
の形式で記述される。

これより、上記の例では、ＰＬＣ１から取得した定義情報に基づいて、テーブル６０には、派生データ型名６１＝“STR_S1”、配列／構造体６２＝“構造体”、取得局６３＝“ＰＬＣ１”の新規レコードであって、構造体メンバ名６７には“LDATA”、“UDATA”がこの順番で格納され、“LDATA”、“UDATA”それぞれに対応する要素データ型６４が両方とも“DWORD”である新規レコードが、追加されることになる。

同様にして、ＰＬＣ２から取得した定義情報に基づいて、テーブル６０には、派生データ型名６１＝“STR_S1”、配列／構造体６２＝“構造体”、取得局６３＝“ＰＬＣ２”の新規レコードであって、構造体メンバ名６７には、“UDATA”、“LDATA”がこの順番で格納され、“LDATA”、“UDATA”それぞれに対応する要素データ型６４が両方とも“DWORD”である新規レコードが、追加されることになる。

従って、この例では、構造体メンバ名６７の名称自体は同じであるが定義順が異なるので、ステップＳ４３の処理で不一致と判定されることになる。
但し、上記ステップＳ４５の処理によって、例えばアルファベット順（且つ、昇順）に変換することで、両方とも構造体メンバ名６７の順番が、“LDATA”、“UDATA”の順となる。これによって、ステップＳ４５では両者は一致するものと判定されることになる。

図２０に、上記ステップＳ５０の表示処理の表示画面例を示す。
これは、図１９に示す例（それに応じて生成されるテーブル６０の例）の場合の表示例であり、特に詳細には説明しないが、例えば上記ステップＳ４３で不一致と判定された派生データ型の名称や、その定義元のプログラミング装置２（取得局６３）等が、表示される。例えば、派生データ型“ARRAY_A1”の場合、上記ＰＬＣ１（局番１）とＰＬＣ２（局番２）とで定義されており、且つ、配列要素の定義が相互に異なっているので、その旨が図２０に示すように表示されることになる。

また、特に説明していないが、例えば図２１に示すような表示を行うようにしてもよい。すなわち、上記テーブル６０を作成後、この作成に用いた上記派生データ型の定義情報を保存しておく。そして、例えば上記ステップＳ４３の処理で不一致と判定された派生データ型に係わるＰＬＣ局の上記定義情報から、この派生データ型に関する記述箇所を抽出して、例えば図２１に示すように表示する。

図２１（ａ）には、上記派生データ型“ARRAY_A1”に関する定義情報における記述箇所を表示しており、図上左側にはＰＬＣ１、図上右側にはＰＬＣ２における定義内容が表示されている。

図２１（ｂ）には、上記派生データ型“STR_S1”に関する定義情報における記述箇所を表示しており、図上左側にはＰＬＣ１、図上右側にはＰＬＣ２における定義内容が表示されている。

尚、本手法は上述した例に限らない。例えば、図１２等の処理において、上記ステップＳ４７，Ｓ４８，Ｓ４９の処理は、実行しないようにしてもよい。つまり、複数のプログラミング環境で同一名称且つ異なる内部構造の派生データ型が定義されていないかを、チェックしてチェック結果を表示する処理だけであってもよい。つまり、必ずしも共有データ変数と関連付けた処理を行わなくてもよい。

また、実施例２を実施例１に利用してもよい。すなわち、上述した実施例２の説明では、ステップＳ４３、Ｓ４５、Ｓ４７等の検査結果の記録を用いて、ステップＳ４９、Ｓ５０等の表示を行う例を示したが、この例に限らない。これら検査結果の記録を、例えば上記ステップＳ３１，Ｓ３２，Ｓ３３の確認処理の際に、参照・利用するようにしてもよい。すなわち、例えばステップＳ３１の処理の「共有データ変数毎に、定義内容の同一性を確認する」処理の際に、データ型３２の一致／不一致を確認する場合に、上記検査結果の記録を利用する。

すなわち、この様な場合、実施例１では、単にデータ型３２が同一であれば（例えば両方ともＩＮＴであれば）、少なくともデータ型に関しては一致と判定していた。これに対して、上記実施例２の手法を利用する例の場合には、比較対象のデータ型３２が同一であっても、更に、このデータ型３２について上記ステップＳ４７の処理（図１７の処理など）と同様の処理を実行する。

ここで、既に説明した通り、上記ステップＳ４７の処理は、派生データ型定義の内部構造不一致検査（上記ステップＳ４３等）の結果、不一致が検出された派生データ型が、共有データ変数のデータ型として割付けられているものであるか否かを、チェックする処理である。これより、例えば上記比較対象のデータ型３２が、上記“不一致が検出された派生データ型”であるか否かを、上記検査結果の記録を参照してチェックする。比較対象のデータ型３２が同一であっても、それが“不一致が検出された派生データ型”である場合には、上記データ型３２の一致／不一致の確認結果は、「不一致」とする。

例えば、上記ステップＳ３１の処理において、比較対象の２つのテーブル３０の両方に同じ共有データ変数“ＸＸＸ２”があり、且つ、そのデータ型３２が両方とも上記“USR_TYP_C”であった場合には、上記図１５の例ではこれは“不一致が検出された派生データ型”であると判定されることになるので、上記データ型３２の一致／不一致の確認結果は「不一致」とする。よって、この共有データ変数“ＸＸＸ２”に関する定義内容の同一性の確認結果も、「同一ではない」ことになる。

あるいは、予め上記ステップＳ４７の処理を行って検査結果を記録しておく例に限らず、例えば上記ステップＳ３１の処理の際に、ステップＳ４７の処理を実行するようにしてもよい。そして、この例の場合、ステップＳ４７の処理の対象は、ステップＳ３１において上記データ型３２の一致／不一致の確認対象となったデータ型３２に限られるようにしてもよい。

また、上記ステップＳ４７の処理の結果を利用する処理は、上記ステップＳ３１に限らず、上記ステップＳ３２、Ｓ３３等に利用しても構わない。
また、ここでは、上記ステップＳ４４がＹＥＳであるがステップＳ４６がＮＯとなる派生データ型の場合には、上記データ型３２の一致／不一致の確認結果は「不一致」としてもよいし、「一致」としてもよいものとする。

勿論、実施例１の処理に利用する例に限らず、実施例１は関係なく上記実施例２単独で実現してもよい。
また、上記実施例２単独の場合において、共有データ変数に関する処理は、必須ではない。つまり、テーブル３０の作成や利用に係わる処理は、必ずしも必要ない。つまり、例えばステップＳ４７の処理は、必ずしも必要ない。これに伴って、例えば表示処理に関しては、ステップＳ４９の処理は削除し、必ずステップＳ５０の処理を実行するようにしてもよい。

以上説明したように、実施例２に関しては、制御システム内の複数のプログラミング環境下で定義されている様々な派生データ型について、同一名称の派生データ型がある場合、その内部構造が同一であるか否かを、上記検査によって確認できるため、制御システム内の局間で内部構造が異なるデータを誤って取り扱うことを防止できる。

また、派生データ型の内部構造の不整合を検出した際に、その派生データ型が割り付けられている変数が、共有データ変数であるか否かを検出して区別できるため、不整合検出時に、該当する派生データ型の修正の影響範囲を特定した上で、修正作業を行うことができる。

尚、本例の共有データ定義支援システムは、例えば下記の構成を有するものと言うこともできる。
すなわち、本例の共有データ定義支援システムは、各々がネットワークに接続されると共に１以上の共有データを保持し得る複数のコントローラ装置４と、該各コントローラ装置４に対応して設けられ、そのコントローラ装置４の制御プログラムを上記共有データも用いて任意に作成させるプログラミング装置２とを有するシステムに対して、上記支援装置３を設けた構成である。各支援装置３は上記ネットワーク５に接続される。

そして、各支援装置３は、各々不図示の下記の処理機能部を有するものと見做すこともできる。
・予め決められた共有データ全ての定義情報が登録される共有データ定義記憶部（一例は管理テーブル３０等）。
・該共有データ定義記憶部に登録された前記各共有データのなかで自装置に係る共有データの定義情報を抽出することで自装置共有データ情報を生成する自装置共有データ情報生成部。
・上記生成された自装置共有データ情報を記憶する自装置共有データ情報記憶部（一例は宣言テーブル４０等）。
・後から当該支援装置３に対応するプログラミング装置２が係わるコントローラ装置１に関して追加された共有データの定義情報を、上記共有データ定義記憶部または上記自装置共有データ情報記憶部に追加登録させる共有データ定義追加部。
・任意のときに、他の支援装置３から、その支援装置３における上記共有データ定義記憶部に記憶されている共有データ定義情報、または／及び、その支援装置における前記自装置共有データ情報記憶部に記憶されている自装置共有データ情報、を取得する他装置情報取得部。
・該他装置情報取得部で取得した他の支援装置３の共有データ定義情報または／及び自装置共有データ情報と、自装置で記憶している共有データ定義情報または／及び自装置共有データ情報とを検査対象として、該検査対象とする各情報間の整合性を検査する整合性検査部。

そして、例えば、任意のときに任意の支援装置３において上記他装置情報取得部と整合性検査部とによる整合性検査が実行されることが繰り返されることによって、システム全体での共有データ定義に係る整合性検査が実現される。

また、例えば、上記他装置情報取得部は、自装置以外の支援装置３のなかの一部の支援装置３を上記他の支援装置とする。つまり、各整合性検査では全てのプログラミング環境が検査対象とならないようにしている。これによって、検査対象外のプログラミング環境では作業中断することはない。

また、上記整合性検査部による整合性検査結果を表示する表示機能部手段を更に備える。この表示機能部の表示内容に基づいて、上記検査対象の共有データ定義情報／自装置共有データ情報の何れか１つ以上を、作業者等に修正させる（特に図示しない設定画面等を表示する等して、作業者に手作業で修正させる）。

また、例えば、上記共有データ定義情報は、各共有データ毎に、その識別情報と各種定義情報とから成る。そして、上記整合性検査部は、上記自装置で記憶している共有データ定義情報と、上記他の支援装置の共有データ定義情報とで、識別情報が同じもの同士で上記各種定義情報が一致するか否かを判定し、不一致の場合には不整合と判定する。各種定義情報には、例えばデータ型などが含まれる。

また、例えば、上記整合性検査部による上記“各種定義情報が一致するか否かの判定”は、少なくともデータ型が一致するか否かを判定するものであり、該データ型が派生データ型である場合には、データ型の名称が一致する場合でもデータ型が不一致と判定する場合がある。

これに関して、例えば、上記派生データ型に係わる定義情報に基づいて、名称が同一である派生データ型同士の整合性を判定する派生データ型整合性検査部を、更に有する構成であっても構わない。そして、例えば、上記整合性検査部は、上記判定対象のデータ型が上記派生データ型整合性検査部で不整合と判定された派生データ型である場合には、データ型の名称が一致する場合でもデータ型が不一致と判定する。

あるいは、本例の共有データ定義支援システムは、複数のプログラミング環境において、それぞれ、共有データを保持し得るコントローラの制御プログラムを前記共有データも用いて任意に作成させるプログラミング装置と、支援装置とが設けられ、該各装置がネットワークに接続されたシステムであって、例えば下記の不図示の構成（機能部）を有するものであっても構わない。すなわち、上記各支援装置は、
・共有データの定義情報を記憶する共有データ定義記憶部；
・上記各プログラミング環境における派生データ型の定義情報に基づいて、名称が同一である派生データ型同士の整合性を判定する派生データ型整合性検査部；
・該派生データ型整合性検査部によって不整合と判定された派生データ型が、そのデータ型として割付けられている上記共有データを、上記共有データ定義記憶部から判別する派生データ型割付け変数検査部；
また、この様な共有データ定義支援システムにおいて、上記支援装置は、更に、例えば下記の不図示の各構成を有するものであっても構わない。

例えば、上記派生データ型の定義情報には、上記各派生データ型毎に、その上記名称と内部構造情報が含まれている。そして、上記派生データ型整合性検査部は、例えば、上記名称が同一である派生データ型の上記内部構造情報同士を比較して、該内部構造情報が不一致の場合には不整合と判定する。

例えば、上記内部構造情報には、１以上の構造体メンバ名が含まれている。そして、上記派生データ型整合性検査部は、例えば、上記名称が同一である派生データ型同士でその上記構造体メンバ名が全て一致する場合、整合すると判定する。あるいは、派生データ型整合性検査部は、例えば、上記名称が同一である派生データ型同士でその上記構造体メンバ名が全て一致し且つ該各構造体メンバ名の要素データ型も全て一致する場合に、整合すると判定する。

また、例えば、上記内部構造情報には、配列に係わる開始、終了情報が含まれている。そして、上記派生データ型整合性検査部は、名称が同一である派生データ型同士でその上記開始、終了情報が一致する場合、あるいは更に上記配列に係わる要素データ型も一致する場合に、整合すると判定する。

あるいは、上記派生データ型整合性検査部が不整合と判定した派生データ型の内部構造情報を、所定のルールに従って変換する内部構造変換部を更に有する構成であってもよい。そして、上記派生データ型整合性検査部は、更に、該変換後の内部構造情報を用いて上記整合性の判定を行うものであってもよい。

また、例えば、上記内部構造変換部による上所定のルールに従った変換は、上記内部構造情報に複数の構造体メンバ名が含まれる場合には、該構造体メンバ名の順番を所定のルールに従って並び替えることである。これは、例えば上記一例のように、五十音順やアルファベット順等に、並び替えるものであるが、この例に限らない。

また、例えば、上記内部構造変換部による上所定のルールに従った変換は、上記内部構造情報に配列の開始、終了が含まれる場合には、開始の値を所定値に揃えることであるが、この例に限らない。

あるいは、上記派生データ型整合性検査部によって不整合と判定された派生データ型に関して、その上記名称と、その上記内部構造情報の一部または全部を記録する記録制御部を、更に有するものであってもよい。

あるいは、例えば、上記記録制御部によって記録された情報に基づいて、上記不整合と判定された派生データ型に関する所定情報の表示を行う表示制御部を、更に有するものであってもよい。

また、例えば、上記表示制御部で表示される上記所定情報は、上記名称が同一である派生データ型に関して、不一致であった構造体メンバ名または配列に関する情報である。
また、例えば、上記記録制御部は、更に、上記不整合と判定された派生データ型に関する記録に関連付けて、該派生データ型が割付けられている共有データに関する所定情報を、その上記定義情報に基づいて記録するものであってもよい。

また、例えば、上記表示制御部は、更に、上記派生データ型が割付けられている共有データに関する所定情報も表示するようにしてもよい。
また、例えば、上記所定情報には、その共有データを利用する上記プログラミング装置を示す識別情報が含まれていてもよい。

あるいは、上述した共有データ定義支援システムにおいて、上記支援装置は、更に、例えば下記の不図示の各構成を有するものであっても構わない。
・任意のときに、他の支援装置から、その支援装置における上記共有データ定義記憶部に記憶されている共有データ定義情報を取得する他装置情報取得部；
・この他装置情報取得部で取得した上記他の支援装置の共有データ定義情報と、自装置で記憶している上記共有データ定義情報との整合性を検査する整合性検査部；
また、この整合性検査部は、例えば、上記整合性の検査の際に、上記派生データ型整合性検査部による判定結果あるいは上記派生データ型割付け変数検査部による判別結果を、用いるものであっても構わない。

また、上記整合性検査部は、例えば、上記自装置で記憶している共有データ定義情報が、上記他の支援装置の共有データ定義情報と一致するか否かを判定して、不一致の場合には不整合と判定する。これは、例えば、名称が同一である共有データ同士のデータ型が不一致の場合には、不整合と判定するものであるが、この例に限らない。

また、上記整合性検査部は、例えば、上記共有データのデータ型が、上記不整合と判定された派生データ型である場合には、データ型の名称が一致する場合でもデータ型が不一致と判定する。

１ コントローラ装置
２ プログラミング装置
３ 共有データ定義支援装置
１１ システム構成管理部
１２ 共有データ定義部
１３ 共有データ定義管理テーブル記憶部
１４ 共有データ変数宣言テーブル生成部
１５ 共有データ変数宣言テーブル記憶部
１６ 共有データ変数宣言テーブル転送部
１７ 共有データ定義管理テーブル転送部
１８ 共有データ整合性検査部
１９ 共有データ整合性検査結果表示部
３０ 共有データ定義管理テーブル
３１ 共有データ変数名
３２ データ型
３３ アドレス
３４ 書込み局（ライト局）
３５ 参照局（リード局）
４０ 共有データ変数宣言テーブル
４１ 共有データ変数名
４２ データ型
４３ アドレス
５１ 派生データ型定義管理テーブル転送部
５２ 派生データ型定義管理テーブル記憶部
５３ 派生データ型整合性検査部
５４ 派生データ型内部構造変換部
５５ 派生データ型割付け変数検査部
５６ 派生データ型検査結果表示部
６０ 派生データ型定義管理テーブル
６１ 派生データ型名
６２ 配列／構造体
６３ 取得局
６４ 要素データ型
６５ 開始Index
６６ 終了Index
６７ 構造体メンバ名

Claims (20)

1. 複数のプログラミング環境において、それぞれ、共有データを保持し得るコントローラの制御プログラムを前記共有データも用いて任意に作成させるプログラミング装置と、支援装置とが設けられたシステムであって、
   前記各支援装置は、
   前記各プログラミング環境における派生データ型の定義情報に基づいて、名称が同一である派生データ型同士の整合性を判定する派生データ型整合性検査手段、
   を有することを特徴とする共有データ定義支援システム。
2. 前記共有データの定義情報を記憶する共有データ定義記憶手段と、
   前記派生データ型整合性検査手段によって不整合と判定された派生データ型が、そのデータ型として割付けられている前記共有データを、前記共有データ定義記憶手段から判別する派生データ型割付け変数検査手段と、
   を更に有することを特徴とする請求項１記載の共有データ定義支援システム。
3. 前記派生データ型の定義情報には、前記各派生データ型毎に、その前記名称と内部構造情報が含まれており、
   前記派生データ型整合性検査手段は、前記名称が同一である派生データ型の前記内部構造情報同士を比較して、該内部構造情報が不一致の場合には不整合と判定することを特徴とする請求項１または２記載の共有データ定義支援システム。
4. 前記内部構造情報には、１以上の構造体メンバ名が含まれており、
   前記派生データ型整合性検査手段は、前記名称が同一である派生データ型同士でその前記構造体メンバ名が全て一致する場合、あるいは前記名称が同一である派生データ型同士でその前記構造体メンバ名が全て一致し且つ該各構造体メンバ名の要素データ型も全て一致する場合に、整合すると判定することを特徴とする請求項３記載の共有データ定義支援システム。
5. 前記内部構造情報には、配列に係わる開始、終了情報が含まれており、
   前記派生データ型整合性検査手段は、前記名称が同一である派生データ型同士でその前記開始、終了情報が一致する場合、あるいは更に前記配列に係わる要素データ型も一致する場合に、整合すると判定することを特徴とする請求項３または４記載の共有データ定義支援システム。
6. 前記派生データ型整合性検査手段が不整合と判定した派生データ型の内部構造情報を、所定のルールに従って変換する内部構造変換手段を更に有し、
   前記派生データ型整合性検査手段は、更に、該変換後の内部構造情報を用いて前記整合性の判定を行うことを特徴とする請求項３〜５の何れかに記載の共有データ定義支援システム。
7. 前記内部構造変換手段による前記所定のルールに従った変換は、前記内部構造情報に複数の構造体メンバ名が含まれる場合には、該構造体メンバ名の順番を所定のルールに従って並び替えることであることを特徴とする請求項３〜６の何れかに記載の共有データ定義支援システム。
8. 前記内部構造変換手段による前記所定のルールに従った変換は、前記内部構造情報に配列の開始、終了が含まれる場合には、開始の値を所定値に揃えることであることを特徴とする請求項３〜７の何れかに記載の共有データ定義支援システム。
9. 前記派生データ型整合性検査手段によって不整合と判定された派生データ型に関して、その前記名称と、その前記内部構造情報の一部または全部を記録する記録手段を更に有することを特徴とする請求項３〜８の何れかに記載の共有データ定義支援システム。
10. 前記記録手段によって記録された情報に基づいて、前記不整合と判定された派生データ型に関する所定情報の表示を行う表示手段を更に有することを特徴とする請求項９記載の共有データ定義支援システム。
11. 前記表示手段で表示される前記所定情報は、前記名称が同一である派生データ型に関して、不一致であった構造体メンバ名または配列に関する情報であることを特徴とする請求項１０記載の共有データ定義支援システム。
12. 前記記録手段は、更に、前記不整合と判定された派生データ型に関する記録に関連付けて、該派生データ型が割付けられている共有データに関する所定情報を、その前記定義情報に基づいて記録することを特徴とする請求項９または１０記載の共有データ定義支援システム。
13. 前記表示手段は、更に、前記派生データ型が割付けられている共有データに関する所定情報も表示することを特徴とする請求項１１記載の共有データ定義支援システム。
14. 前記所定情報には、その共有データを利用する前記プログラミング装置を示す識別情報が含まれることを特徴とする請求項１３記載の共有データ定義支援システム。
15. 任意のときに、他の前記支援装置から、その支援装置における前記共有データ定義記憶手段に記憶されている共有データ定義情報を取得する他装置情報取得手段と、
    該他装置情報取得手段で取得した前記他の支援装置の共有データ定義情報と、自装置で記憶している前記共有データ定義情報との整合性を検査する整合性検査手段とを更に有し、
    該整合性検査手段は、前記整合性の検査の際に、前記派生データ型整合性検査手段による判定結果あるいは前記派生データ型割付け変数検査手段による判別結果を、用いることを特徴とする請求項２記載の共有データ定義支援システム。
16. 前記整合性検査手段は、前記自装置で記憶している共有データ定義情報が、前記他の支援装置の共有データ定義情報と一致するか否かを判定して、不一致の場合には不整合と判定するものであって、名称が同一である共有データ同士のデータ型が不一致の場合には不整合と判定するものであることを特徴とする請求項１５記載の共有データ定義支援システム。
17. 前記整合性検査手段は、前記共有データのデータ型が、前記不整合と判定された派生データ型である場合には、データ型の名称が一致する場合でもデータ型が不一致と判定することを特徴とする請求項１５記載の共有データ定義支援システム。
18. 複数のプログラミング環境において、それぞれ、共有データを保持し得るコントローラの制御プログラムを前記共有データも用いて任意に作成させるプログラミング装置と、支援装置とが設けられたシステムにおける該支援装置であって、
    前記各プログラミング環境における派生データ型の定義情報に基づいて、名称が同一である派生データ型同士の整合性を判定する派生データ型整合性検査手段、
    を有することを特徴とする支援装置。
19. 前記共有データの定義情報を記憶する共有データ定義記憶手段と、
    前記派生データ型整合性検査手段によって不整合と判定された派生データ型が、そのデータ型として割付けられている前記共有データを、前記共有データ定義記憶手段から判別する派生データ型割付け変数検査手段と、
    を更に有することを特徴とする請求項１８記載の支援装置。
20. 複数のプログラミング環境において、それぞれ、共有データを保持し得るコントローラの制御プログラムを前記共有データも用いて任意に作成させるプログラミング装置と、支援装置とが設けられ、該各装置がネットワークに接続されたシステムにおける該支援装置のコンピュータを、
    前記各プログラミング環境における派生データ型の定義情報に基づいて、名称が同一である派生データ型同士の整合性を判定する派生データ型整合性検査手段、
    として機能させる為のプログラム。