(57)【要約】【課題】プログラムの出力の一義性（同期性）を保ったうえでほぼ最適な負荷配分を行う。【解決手段】最適負荷配分機能部２５は、変数リスト情報生成機能部２６によって生成される変数リスト情報に基づいて、同一の入力変数を有するプログラムは同じコントローラに配分したうえで、残りのプログラムについてはＰＯＵサイズ算出機能部２３と呼出情報生成機能部２４の処理結果に基づいて得られる各プログラムの総実行オブジェクトコードサイズに基づいて、各コントローラの総実行オブジェクトコードサイズ総計が略同一となるように、残りのプログラムをコントローラに配分する。【選択図】  図１
2012118715.tif 000002
【特許請求の範囲】
【請求項１】
開発支援装置と複数の演算処理部を有し、任意のアプリケーションの実行に係わる負荷を該複数の演算処理部に分散させて実行するＰＬＣシステムであって、
前記開発支援装置は、
前記アプリケーションをコンパイルすることで実行オブジェクトコードを生成するコンパイル手段と、
前記アプリケーションを構成する複数の処理単位毎に、その処理単位に係わる前記実行オブジェクトコードのサイズの総数を求める総実行オブジェクトコードサイズ算出手段と、
前記アプリケーションを構成する複数の処理単位毎に、少なくともその処理単位に係わる入力変数が含まれる変数リスト情報を生成する変数リスト情報生成手段と、
前記アプリケーションの負荷を前記複数の演算処理部に配分する手段であって、前記総実行オブジェクトコードサイズ算出手段によって算出される前記各処理単位それぞれの実行オブジェクトコードサイズ総数と、前記変数リスト情報とに基づいて、共通の前記入力変数を有する処理単位は同じ演算処理部に配分することを条件として、この条件を満たしつつ前記複数の演算処理部それぞれの負荷が略均等となるように前記アプリケーションの各処理単位を前記各演算処理部に配分する負荷配分手段を有し、
前記各演算処理部は、自己に割り当てられた全ての処理単位に係る前記入力変数をまとめて入力し、該自己に割り当てられた全ての処理単位を順次実行し、該実行結果をまとめて出力することを特徴とするＰＬＣシステム。
【請求項２】
開発支援装置と複数の演算処理部を有し、プログラム本体と該プログラム本体から呼び出される各種ＰＯＵより成る複数のプログラムより構成される任意のアプリケーションの実行に係わる負荷を、前記複数の演算処理部に分散させて実行するＰＬＣシステムであって、
前記開発支援装置は、
前記アプリケーションをコンパイルすることで実行オブジェクトコードを生成するコンパイル手段と、
前記アプリケーションを構成する前記各プログラム毎に、少なくともそのプログラムに係わる入力変数が含まれる変数リスト情報を生成する変数リスト情報生成手段と、
前記プログラム本体またはＰＯＵそれぞれの前記実行オブジェクトコードのサイズを求めるＰＯＵサイズ算出手段と、
前記コンパイル時に前記ＰＯＵの呼び出し情報を求める呼出情報生成手段と、
前記プログラム本体またはＰＯＵそれぞれの前記実行オブジェクトコードのサイズと、前記ＰＯＵの呼び出し情報とに基づいて、前記アプリケーションを構成する前記各プログラム毎に、そのプログラムに係わるプログラム本体または各ＰＯＵの前記実行オブジェクトコードのサイズと各ＰＯＵの実行回数とに応じた実行オブジェクトコードサイズ総数を算出する総実行オブジェクトコードサイズ算出手段と、
前記各プログラムを前記複数の演算処理部に配分する手段であって、前記総実行オブジェクトコードサイズ算出手段によって算出される前記各プログラムそれぞれの実行オブジェクトコードサイズ総数と、前記変数リスト情報とに基づいて、共通の前記入力変数を有するプログラムは同じ演算処理部に配分することを条件として、この条件を満たしつつ前記複数の演算処理部それぞれの負荷が略均等となるように前記各プログラムを前記各演算処理部に配分する負荷配分手段とを有し、
前記各演算処理部は、自己に割り当てられた全てのプログラムに係る前記入力変数をまとめて入力し、該自己に割り当てられた全てのプログラムを順次実行し、該実行結果をまとめて出力することを特徴とするＰＬＣシステム。
【請求項３】
前記負荷配分手段は、前記共通の入力変数を有するプログラムはグループ化して該グループ単位で前記演算処理部に配分し、その後、グループ化されなかった残りの各プログラムを、該各プログラムの前記実行オブジェクトコードサイズ総数に基づいて、前記各演算処理部に割り当てられた全てのプログラムの実行オブジェクトコードサイズ総数の総和が該複数の演算処理部で略均等となるように、前記演算処理部に配分することを特徴とする請求項２記載のＰＬＣシステム。
【請求項４】
前記負荷配分手段は、前記共通の入力変数を有するプログラムはグループ化すると共に、そのグループに属する全てのプログラムの実行オブジェクトコードサイズ総数の総和を該グループの実行オブジェクトコードサイズ総数として算出し、該算出されたグループ単位の実行オブジェクトコードサイズ総数と、グループ化されなかった各プログラムの前記実行オブジェクトコードサイズ総数とに基づいて、前記グループ化されたプログラムはグループ単位で配分し且つ前記各演算処理部に割り当てられた全てのプログラムの実行オブジェクトコードサイズ総数の総和が該複数の演算処理部で略均等となるように、前記各プログラムを前記演算処理部に配分することを特徴とする請求項２記載のＰＬＣシステム。
【請求項５】
開発支援装置と複数の演算処理部を有し、任意のアプリケーションの実行に係わる負荷を該複数の演算処理部に分散させて実行するＰＬＣシステムにおける該開発支援装置であって、
前記アプリケーションをコンパイルすることで実行オブジェクトコードを生成するコンパイル手段と、
前記アプリケーションを構成する複数の処理単位毎に、その処理単位に係わる前記実行オブジェクトコードのサイズの総数を求める総実行オブジェクトコードサイズ算出手段と、
前記アプリケーションを構成する複数の処理単位毎に、少なくともその処理単位に係わる入力変数が含まれる変数リスト情報を生成する変数リスト情報生成手段と、
前記アプリケーションの処理を前記各処理単位で前記複数の演算処理部に配分する手段であって、前記総実行オブジェクトコードサイズ算出手段によって算出される前記各処理単位それぞれの実行オブジェクトコードサイズ総数と、前記変数リスト情報とに基づいて、共通の前記入力変数を有する処理単位は同じ演算処理部に配分することを条件として、この条件を満たしつつ前記複数の演算処理部それぞれの負荷が略均等となるように前記アプリケーションの各処理単位を前記各演算処理部に配分する負荷配分手段と、
を有することを特徴とするＰＬＣシステムの開発支援装置。
【請求項６】
開発支援装置と複数の演算処理部を有し、プログラム本体と該プログラム本体から呼び出される各種ＰＯＵより成る複数のプログラムより構成される任意のアプリケーションの実行に係わる負荷を、前記複数の演算処理部に分散させて実行するＰＬＣシステムにおける前記開発支援装置であって、
前記アプリケーションをコンパイルすることで実行オブジェクトコードを生成するコンパイル手段と、
前記アプリケーションを構成する前記各プログラム毎に、少なくともそのプログラムに係わる入力変数が含まれる変数リスト情報を生成する変数リスト情報生成手段と、
前記プログラム本体またはＰＯＵそれぞれの前記実行オブジェクトコードのサイズを求めるＰＯＵサイズ算出手段と、
前記コンパイル時に前記ＰＯＵの呼び出し情報を求める呼出情報生成手段と、
前記プログラム本体またはＰＯＵそれぞれの前記実行オブジェクトコードのサイズと、前記ＰＯＵの呼び出し情報とに基づいて、前記アプリケーションを構成する前記各プログラム毎に、そのプログラムに係わるプログラム本体または各ＰＯＵの前記実行オブジェクトコードのサイズと各ＰＯＵの実行回数とに応じた実行オブジェクトコードサイズ総数を算出する総実行オブジェクトコードサイズ算出手段と、
前記各プログラムを前記複数の演算処理部に配分する手段であって、前記総実行オブジェクトコードサイズ算出手段によって算出される前記各プログラムそれぞれの実行オブジェクトコードサイズ総数と、前記変数リスト情報とに基づいて、共通の前記入力変数を有するプログラムは同じ演算処理部に配分することを条件として、この条件を満たしつつ前記複数の演算処理部それぞれの負荷が略均等となるように前記各プログラムを前記各演算処理部に配分する負荷配分手段と、
を有することを特徴とするＰＬＣシステムの開発支援装置。
【請求項７】
開発支援装置と複数の演算処理部を有し、任意のアプリケーションの実行に係わる負荷を該複数の演算処理部に分散させて実行するＰＬＣシステムにおける該開発支援装置のコンピュータを、
前記アプリケーションをコンパイルすることで実行オブジェクトコードを生成するコンパイル手段と、
前記アプリケーションを構成する複数の処理単位毎に、その処理単位に係わる前記実行オブジェクトコードのサイズの総数を求める総実行オブジェクトコードサイズ算出手段と、
前記アプリケーションを構成する複数の処理単位毎に、少なくともその処理単位に係わる入力変数が含まれる変数リスト情報を生成する変数リスト情報生成手段と、
前記アプリケーションの処理を前記各処理単位で前記複数の演算処理部に配分する手段であって、前記総実行オブジェクトコードサイズ算出手段によって算出される前記各処理単位それぞれの実行オブジェクトコードサイズ総数と、前記変数リスト情報とに基づいて、共通の前記入力変数を有する処理単位は同じ演算処理部に配分することを条件として、この条件を満たしつつ前記複数の演算処理部それぞれの負荷が略均等となるように前記アプリケーションの各処理単位を前記各演算処理部に配分する負荷配分手段、
として機能させるためのプログラム。
【請求項８】
開発支援装置と複数の演算処理部を有し、プログラム本体と該プログラム本体から呼び出される各種ＰＯＵより成る複数のプログラムより構成される任意のアプリケーションの実行に係わる負荷を、前記複数の演算処理部に分散させて実行するＰＬＣシステムにおける前記開発支援装置のコンピュータを、
前記アプリケーションをコンパイルすることで実行オブジェクトコードを生成するコンパイル手段と、
前記アプリケーションを構成する前記各プログラム毎に、少なくともそのプログラムに係わる入力変数が含まれる変数リスト情報を生成する変数リスト情報生成手段と、
前記プログラム本体またはＰＯＵそれぞれの前記実行オブジェクトコードのサイズを求めるＰＯＵサイズ算出手段と、
前記コンパイル時に前記ＰＯＵの呼び出し情報を求める呼出情報生成手段と、
前記プログラム本体またはＰＯＵそれぞれの前記実行オブジェクトコードのサイズと、前記ＰＯＵの呼び出し情報とに基づいて、前記アプリケーションを構成する前記各プログラム毎に、そのプログラムに係わるプログラム本体または各ＰＯＵの前記実行オブジェクトコードのサイズと各ＰＯＵの実行回数とに応じた実行オブジェクトコードサイズ総数を算出する総実行オブジェクトコードサイズ算出手段と、
前記各プログラムを前記複数の演算処理部に配分する手段であって、前記総実行オブジェクトコードサイズ算出手段によって算出される前記各プログラムそれぞれの実行オブジェクトコードサイズ総数と、前記変数リスト情報とに基づいて、共通の前記入力変数を有するプログラムは同じ演算処理部に配分することを条件として、この条件を満たしつつ前記複数の演算処理部それぞれの負荷が略均等となるように前記各プログラムを前記各演算処理部に配分する負荷配分手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラマブルコントローラの開発支援装置に関する。
【背景技術】
【０００２】
近年、マイクロコントローラやＬＳＩを使用した組込システムにおいては、ハードウェアでのクロック周波数の向上などによる実行速度の改善は、限界に近づきつつあり、その為、複数のＣＰＵを並列実行することで全体の実行速度を上げるマルチコア方式が用いられるようになってきている。その際、ユーザは複数の演算処理部（ＣＰＵ）から成るシステムを効率的に利用するために、各ＣＰＵに掛かる負荷を調整することが求められる場合がある。
【０００３】
しかしながら、シーケンシャルな処理が多く、且つリアルタイム性能を要求されることが多いＰＬＣにおいては、負荷の調整には、入出力機器等を含めたシステム構成に依存した処理のノウハウが必要で難易度が高く、システム規模の増大に伴い、調整工数も増大傾向にある。この工数を削減するために考案された負荷の自動分散方式については、従来技術文献として以下の特許文献１，２が存在する。
【０００４】
特許文献１；システム稼動時（動的）に負荷分散する方式。システム稼動時、各ＰＬＣが自己の負荷をそれぞれ算出し、算出した負荷に対応して自己の処理の少なくとも一部を他のＰＬＣに依頼することで、負荷の自動配分を実現している。
【０００５】
特許文献２；システムの非稼動時（静的）に負荷分散する方式。ＰＬＣの国際規格化言語（ＩＥＣ61131-3）の１つであるＳＦＣに特化しつつ、その特徴を利用した自動配分方式を実現している。
【０００６】
また、従来のＰＬＣシステムの一例を図１３（ｂ）に示す。
図示のように、ＰＬＣシステムは、開発支援装置１０１、コントローラ１１０、入出力機器１０２等から成る。入出力機器１０２は、コントローラ１１０による各種制御対象機器等（制御対象機器とのＩ／Ｏインタフェース等であってもよい）であり、制御対象機器だけでなく、その状態計測の為の各種センサ類や、表示部等も含まれているものとする。
【０００７】
コントローラ１１０は、入力メモリ１１１、出力メモリ１１２、マイコン１１３等を有する。入力メモリ１１１には各変数（入力変数；図示の例では変数ａ，ｂ，ｃ，ｄ）が記憶されており、入出力機器１０２からの入力処理に応じた各変数の値が更新される。例えば、上記入出力機器１０２の各種センサ類の計測データ等が、入力メモリ１１１上の該当する変数の値となる。出力メモリ１１２にも各変数（出力変数；図示の例では変数ｓ，ｔ，ｕ，ｖ）が記憶されており、この出力メモリ１１２上の各変数の値に基づいて入出力機器１０２への出力（値の表示、制御等）が行われる。
【０００８】
マイコン１１３が各プログラム（図示の例ではプログラムＡ，Ｂ，Ｃ，Ｄ）を実行する毎に、そのプログラムに係わる入力変数の値が入力メモリ１１１から読み込まれ、処理実行され、この処理結果によってそのプログラムに係わる出力変数の値が更新されることになる。
【０００９】
開発者等は、開発支援装置１０１上でラダー言語等のプログラム作成言語を用いて任意のアプリケーションを作成する。コンパイラ、リンカによって、作成されたアプリケーションの各プログラムの実行オブジェクトが生成され、これがコントローラ１１０にダウンロードされてマイコン１１３の内蔵メモリ等に格納される。図示の例では、プログラムＡ，Ｂ，Ｃ，Ｄの４つのプログラムの実行オブジェクトが、開発支援装置１０１からコントローラ１１０にダウンロードされて、マイコン１１３の内蔵メモリ等に格納される。これより、マイコン１１３は、これら４つのプログラムＡ，Ｂ，Ｃ，Ｄを、例えば定周期で実行する。
【００１０】
このように任意のアプリケーションのプログラムＡ，Ｂ，Ｃ，Ｄをコントローラ１１０（そのマイコン１１３）で実行させる場合、マイコン１１３は、各プログラム実行に伴い、入力メモリ１１１から所定の変数記憶領域に格納されている変数データを読み込み、読み込んだ変数データに基づいて所定の演算処理を実行し、この演算処理結果を出力メモリ１１２の所定の変数記憶領域に書き込む。ここで、各プログラムＡ，Ｂ，Ｃ，Ｄが実行する処理、入力メモリ１１１から読み込む変数、出力メモリ１１２に書き込む変数を、図１３（ａ）に一覧で示す。
【００１１】
図１３（ａ）に示す一例では、プログラムＡは、入力メモリ１１１から変数ａと変数ｃの値を読み込み、これに基づいて所定の演算処理（処理Ａ）を実行し、演算処理結果を出力メモリ１１２の変数ｓの記憶領域に書き込むことになる。同様に、プログラムＢは、入力メモリ１１１から変数ｂの値を読み込み、これに基づいて所定の演算処理（処理Ｂ）を実行し、演算処理結果を出力メモリ１１２の変数ｔの記憶領域に書き込む。プログラムＣは、入力メモリ１１１から変数ｃの値を読み込み、これに基づいて所定の演算処理（処理Ｃ）を実行し、演算処理結果を出力メモリ１１２の変数ｕの記憶領域に書き込む。プログラムＤは、入力メモリ１１１から変数ｄの値を読み込み、これに基づいて所定の演算処理（処理Ｄ）を実行し、演算処理結果を出力メモリ１１２の変数ｖの記憶領域に書き込む。
【００１２】
尚、本説明では、入力メモリ１１１に格納される変数を入力変数、出力メモリ１１２に格納される変数を出力変数と呼ぶ場合もあるものとする。
ここで、従来のＰＬＣの動作としては、各プログラム実行毎にそのプログラムに係わる変数値の入力と出力を行う場合もあるが、複数のプログラムに係わる変数値の入力、出力をまとめて行う場合もある。その一例を図１４に示す。
【００１３】
図１４において、図示のPG-A、PG-B、PG-C、PG-Dは、それぞれ、上記プログラムＡ，Ｂ，Ｃ，Ｄの演算処理実行を意味する(つまり、上記処理Ａ、処理Ｂ、処理Ｃ、処理Ｄの実行を意味する)。そして、図示のＩは、入力メモリ１１１からの変数データ読込みを意味するが、これは上記処理Ａ〜処理Ｄの全てに係る変数データをまとめて読み込む処理である。よって、上記の例では図示のＩの処理で変数ａ、ｂ，ｃ，ｄの各変数値を読み込むことになる。同様に、図示のＯは、上記処理Ａ〜処理Ｄの処理結果をまとめて出力メモリ１１２に書き込む処理を意味し、上記の例では、変数ｓ，ｔ，ｕ，ｖの各格納領域に処理結果を書き込む処理となる。
【００１４】
この様に、入出力処理をまとめて行うのは、プログラムの出力の一義性（または同期性）を確保する為である。例えばモーションコントローラ等や、制御対象がサーボアンプやインバータ等であった場合、高速な位置決め制御が必要な場合等には、複数のプログラムのなかに、共通の入力に基づいて各々の処理を行い、更に出力結果に応じた動作が互いに関連するような関係の複数のプログラムが存在する場合がある。この様な場合、上記出力の一義性（または同期性）を確保する必要がある。例えば、位置決め制御の場合、出力の一義性（または同期性）を確保出来ないことは位置決め精度の悪化に直結することになる。
【００１５】
通常、上記各プログラムは、その入力データが変化したならば、その出力データもそれに応じた値に変わることになるが、上記のような関係の複数のプログラムの場合には、入力データの変化に応じた出力データの変化のタイミングが、ほぼ同じであることが要求される。この様な要求を満たすことをここでは「プログラムの出力の一義性（または同期性）を確保する」と言う。
【００１６】
しかしながら、複数の演算処理部（ＣＰＵ）に負荷分散する場合、「プログラムの出力の一義性（または同期性）を確保する」ことが出来なくなる可能性がある。これについて、図１５を参照して説明する。
【００１７】
上記出力動作が互いに関連する関係の複数のプログラムは、上記の通り入力変数が共通である。これより、図１３（ａ）に示す例では、プログラムＡとプログラムＣとがこの様な関係にある（入力変数ｃが共通）。
【００１８】
ここで、仮に、上記４つのプログラムＡ〜Ｄを、２つのコントローラ１１０（基本コントローラ、拡張コントローラと呼ぶものとする）に分けて割りあてるものとし、プログラムＡ、Ｄは基本コントローラに割り当て、プログラムＢ，Ｃは拡張コントローラに割り当てるものとする。
【００１９】
これより、図１５に示すように、基本コントローラにおいては、定周期でプログラムＡ、Ｄが実行されることになる。この場合、入力処理Ｉでは変数ａ，ｃ，ｄの値をまとめて読み込み、出力処理Ｏでは変数ｓ，ｖへの書き込みを行うことになる。一方、拡張コントローラにおいては、定周期でプログラムＢ，Ｃが実行されることになる。この場合、入力処理Ｉでは変数ｂ，ｃの値をまとめて読み込み、出力処理Ｏでは変数ｔ，ｕへの書き込みを行うことになる。
【００２０】
ここで、図１５には入力変数ｃと、出力変数ｓ，ｕの変化タイミングを示している。すなわち、図示の入力変数ｃと、出力変数ｓ，ｕのそれぞれに関して、‘０’（Ｌ）から‘１’（Ｈ）に変化しているタイミングが、これら各変数のデータ変化タイミングを意味するものとする。入力変数ｃの変化に応じて出力変数ｓ，ｕが変化する。尚、これは、変数データが‘０’から‘１’に変化しているとは限らず、任意のデータ内容から他のデータ内容へと変化しているものと考えても良い。また、尚、入力変数ｃは上述した入出力機器１０２からの入力処理によって任意のタイミングで更新されるものとする。
【００２１】
図示のように基本コントローラと拡張コントローラとで処理実行タイミングが異なる場合、図中の任意のサイクルでは、基本コントローラの入力処理Ｉのタイミングでは未だ入力変数ｃは変化していないが、その直後に変化し、その後の拡張コントローラの入力処理Ｉでは変化後の入力変数ｃを入力している。これによって、このサイクルでは、出力変数ｕは変化するが、出力変数ｓは変化しない。出力変数ｓが変化するのは次のサイクルのときであり、この為、図示の通り、出力変数ｕが変化するタイミングと、出力変数ｓが変化するタイミングとに大きなズレが生じることになる。別の言い方をすれば、変化後の入力変数ｃを入力するタイミングが、図示の通り基本と拡張とで大きく異なることになる。つまり、「プログラムの出力の一義性（または同期性）」が損なわれていることになる。
【先行技術文献】
【特許文献】
【００２２】
【特許文献１】特開平９−９１０１１号公報
【特許文献２】特開平７−２８３９０号公報
【発明の概要】
【発明が解決しようとする課題】
【００２３】
プログラマブルコントローラのアプリケーションは、近年、複雑化、大容量化してきており、複数のＣＰＵに負荷を分散して処理効率を向上させようとしても、その配分を決定することが難しい。また、試行錯誤的に負荷の配分を行った場合、多大な時間が掛かる為、ユーザの負担になってきている。
【００２４】
また、試行錯誤的に負荷の配分を行った場合、多大な時間が掛かる為、ユーザの負担となり、アプリケーションプログラムの開発難易度が増大するだけでなく、開発効率が低下する。
【００２５】
また、近年、ＰＬＣのアプリケーションは、従来のラダー言語などによる処理単位で記述された単純構造のプログラムではなく、ＩＥＣ61131-3のような多言語を駆使した機能単位の構造化設計が行われるようになってきており、ユーザが処理全体の流れを把握することが困難になってきている。構造化設計の場合、同一の機能単位、関数等が別々のプログラムから呼び出されることが多く、プログラム作成者が複数にわたる開発も多くなってきている。
【００２６】
このような状況では、複数のＣＰＵリソースを持つシステムであっても、アプリケーションプログラム作成者が自力で負荷配分を行うことは難易度が高く、結果的に処理負荷のアンバランスによるトータルシステム処理性能の低下、またシステム立ち上げ工数の増加が考えられる。
【００２７】
また、上述した「プログラムの出力の一義性（または同期性）」が損なわれないようにする必要がある。「プログラムの出力の一義性（または同期性）」が保てないと、例えば上記のように位置決め精度の悪化を招き、それによって誤動作や何らかの危険な問題が生じる可能性もあるので、こちらの方が最適な負荷配分を行うことよりも優先順位が高い。
【００２８】
本発明の課題は、複数の演算処理部を有し、任意のアプリケーション実行に係わる負荷を複数の演算処理部に分散させるＰＬＣシステムにおいて、プログラムの出力の一義性（同期性）を保ったうえでほぼ最適な負荷配分を行えるＰＬＣシステム、その開発支援装置等を提供することである。
【課題を解決するための手段】
【００２９】
本発明のＰＬＣシステムは、開発支援装置と複数の演算処理部を有し、任意のアプリケーションの実行に係わる負荷を該複数の演算処理部に分散させて実行するＰＬＣシステムであって、前記開発支援装置は、前記アプリケーションをコンパイルすることで実行オブジェクトコードを生成するコンパイル手段と、前記アプリケーションを構成する複数の処理単位毎に、その処理単位に係わる前記実行オブジェクトコードのサイズの総数を求める総実行オブジェクトコードサイズ算出手段と、前記アプリケーションを構成する複数の処理単位毎に、少なくともその処理単位に係わる入力変数が含まれる変数リスト情報を生成する変数リスト情報生成手段と、前記アプリケーションの負荷を前記複数の演算処理部に配分する手段であって、前記総実行オブジェクトコードサイズ算出手段によって算出される前記各処理単位それぞれの実行オブジェクトコードサイズ総数と、前記変数リスト情報とに基づいて、共通の前記入力変数を有する処理単位は同じ演算処理部に配分することを条件として、この条件を満たしつつ前記複数の演算処理部それぞれの負荷が略均等となるように前記アプリケーションの各処理単位を前記各演算処理部に配分する負荷配分手段を有し、前記各演算処理部は、自己に割り当てられた全ての処理単位に係る前記入力変数をまとめて入力し、該自己に割り当てられた全ての処理単位を順次実行し、該実行結果をまとめて出力する。
【００３０】
あるいは、本発明のＰＬＣシステムは、開発支援装置と複数の演算処理部を有し、プログラム本体と該プログラム本体から呼び出される各種ＰＯＵより成る複数のプログラムより構成される任意のアプリケーションの実行に係わる負荷を、前記複数の演算処理部に分散させて実行するＰＬＣシステムであって、前記開発支援装置は、前記アプリケーションをコンパイルすることで実行オブジェクトコードを生成するコンパイル手段と、前記アプリケーションを構成する前記各プログラム毎に、少なくともそのプログラムに係わる入力変数が含まれる変数リスト情報を生成する変数リスト情報生成手段と、前記プログラム本体またはＰＯＵそれぞれの前記実行オブジェクトコードのサイズを求めるＰＯＵサイズ算出手段と、前記コンパイル時に前記ＰＯＵの呼び出し情報を求める呼出情報生成手段と、前記プログラム本体またはＰＯＵそれぞれの前記実行オブジェクトコードのサイズと、前記ＰＯＵの呼び出し情報とに基づいて、前記アプリケーションを構成する前記各プログラム毎に、そのプログラムに係わるプログラム本体または各ＰＯＵの前記実行オブジェクトコードのサイズと各ＰＯＵの実行回数とに応じた実行オブジェクトコードサイズ総数を算出する総実行オブジェクトコードサイズ算出手段と、前記各プログラムを前記複数の演算処理部に配分する手段であって、前記総実行オブジェクトコードサイズ算出手段によって算出される前記各プログラムそれぞれの実行オブジェクトコードサイズ総数と、前記変数リスト情報とに基づいて、共通の前記入力変数を有するプログラムは同じ演算処理部に配分することを条件として、この条件を満たしつつ前記複数の演算処理部それぞれの負荷が略均等となるように前記各プログラムを前記各演算処理部に配分する負荷配分手段とを有し、前記各演算処理部は、自己に割り当てられた全てのプログラムに係る前記入力変数をまとめて入力し、該自己に割り当てられた全てのプログラムを順次実行し、該実行結果をまとめて出力する。
【００３１】
上記演算処理部は、自己に割り当てられた全ての処理単位（またはプログラム）に係る入力変数をまとめて入力し、該自己に割り当てられた全ての処理単位（またはプログラム）を順次実行し、該実行結果をまとめて出力する。各演算処理部がこの様な動作を行う場合には、共通の入力変数を有する「処理単位」（またはプログラム）が、異なる演算処理部に配分されてしまうと、プログラムの出力の一義性（同期性）を保てなくなる。これに対して上記構成のＰＬＣシステム、その開発支援装置によれば、この様な問題が生じないようにでき、そのうえでほぼ最適な負荷配分を行うことが可能となる。
【００３２】
また、上記ＰＬＣシステムにおいて、例えば、前記負荷配分手段は、前記共通の入力変数を有するプログラムはグループ化して該グループ単位で前記演算処理部に配分し、その後、グループ化されなかった残りの各プログラムを、該各プログラムの前記実行オブジェクトコードサイズ総数に基づいて、前記各演算処理部に割り当てられた全てのプログラムの実行オブジェクトコードサイズ総数の総和が該複数の演算処理部で略均等となるように、前記演算処理部に配分するように構成してもよい。
【００３３】
あるいは、上記ＰＬＣシステムにおいて、例えば、前記負荷配分手段は、前記共通の入力変数を有するプログラムはグループ化すると共に、そのグループに属する全てのプログラムの実行オブジェクトコードサイズ総数の総和を該グループの実行オブジェクトコードサイズ総数として算出し、該算出されたグループ単位の実行オブジェクトコードサイズ総数と、グループ化されなかった各プログラムの前記実行オブジェクトコードサイズ総数とに基づいて、前記グループ化されたプログラムはグループ単位で配分し且つ前記各演算処理部に割り当てられた全てのプログラムの実行オブジェクトコードサイズ総数の総和が該複数の演算処理部で略均等となるように、前記各プログラムを前記演算処理部に配分するように構成してもよい。
【発明の効果】
【００３４】
本発明のＰＬＣシステム、その開発支援装置等によれば、複数の演算処理部を有し、任意のアプリケーション実行に係わる負荷を複数の演算処理部に分散させるＰＬＣシステムにおいて、プログラムの出力の一義性（同期性）を保ったうえでほぼ最適な負荷配分を行える。自動的にほぼ最適な負荷配分を行えることに関しては、ＩＥＣ61131-3のような構造化設計の場合に、特に顕著な効果を奏する。また、実行オブジェクトコードサイズを用いるので、ＰＬＣ言語が何であっても関係なく適用可能である。
【図面の簡単な説明】
【００３５】
【図１】（ａ），（ｂ）は、本例のＰＬＣシステムのシステム構成例（その１）、（その２）である。
【図２】開発支援装置の処理フローチャート図である。
【図３】（ａ）、（ｂ）は「ＰＯＵの呼び出し情報」の一例を示す図である。
【図４】（ａ）は実行オブジェクトコードサイズの一例、（ｂ）は総実行オブジェクトコードサイズの一例を一覧で示す図である。
【図５】複数のＣＰＵへの負荷配分結果の一例である。
【図６】（ａ）、（ｂ）はオブジェクトコードのステップ数について説明する為の図である。
【図７】（ａ）、（ｂ）は、従来の図１３の例の場合における実施例１の具体例について説明する為の図である。
【図８】実施例２の開発支援装置とＰＬＣシステムを示す図である。
【図９】（ａ）、（ｂ）は、実施例２のプログラム配分結果とそれに応じた動作を示す図である。
【図１０】変数リスト情報の具体例を示す図である。
【図１１】実施例２の最適負荷配分機能部の処理の一部を示すフローチャート図である。
【図１２】開発支援装置のハードウェア構成例である。
【図１３】（ａ）、（ｂ）は、従来のＰＬＣシステムの動作を説明する為の図である。
【図１４】複数のプログラムに係る入力、出力をまとめて行う動作を説明する為の図である。
【図１５】図１４の動作に係る従来の問題点を説明する為の図である。
【発明を実施するための形態】
【００３６】
以下、図面を参照して、本発明の実施の形態について説明する。
図１（ａ），（ｂ）は、本例のＰＬＣ（プログラマブルコントローラ）システムのシステム構成例（その１）、（その２）である。
【００３７】
図１（ａ）、（ｂ）のＰＬＣシステムは、何れも、複数の演算処理部（ＣＰＵ）と、開発支援装置１０を有する。但し、図１（ａ）ではそれぞれが演算処理部（ＣＰＵ）を有する複数の演算モジュールより成る構成であり、図１（ｂ）は１つの演算モジュール内に複数の演算処理部（ＣＰＵ）がある構成となっている。何れにしても、演算処理部が複数存在するＰＬＣシステムであり、任意のアプリケーションプログラムを実行する場合には、複数の演算処理部（ＣＰＵ）に負荷を分散させて処理効率を向上させる為に、複数のＣＰＵへの負荷配分を行うものであることを前提とする。
【００３８】
本例のＰＬＣシステム（その開発支援装置）は、上記特許文献１のような運用中に動的に負荷配分を行うものではなく、運用前に静的に負荷配分を行うものである。
図１（ａ）のＰＬＣシステムでは、開発支援装置１０（１０Ａ）と複数のＰＬＣモジュール２（演算モジュール）がネットワーク１に接続しており、ネットワーク１を介して相互に通信可能となっている。各ＰＬＣモジュール２がそれぞれ１つのＣＰＵ２ａ、ＣＰＵ２ｂを有することで、複数の演算処理部（ＣＰＵ）がある構成となっている。
【００３９】
一方、図１（ｂ）のＰＬＣシステムは、開発支援装置１０（１０Ｂ）と１つのＰＬＣモジュール４がネットワーク１に接続しており、ネットワーク１を介して相互に通信可能となっている。このＰＬＣモジュール４が複数のＣＰＵ４ａ，４ｂを有することで、複数の演算処理部（ＣＰＵ）がある構成となっている。
【００４０】
上記の通り、図１（ａ）、（ｂ）はどちらも、複数の演算処理部（ＣＰＵ）がある構成となっている点では同じであり、複数の演算処理部（ＣＰＵ）に負荷分散する点でも同じである。
【００４１】
尚、各ＰＬＣモジュール（２ｏｒ４）は、Ｉ／Ｏモジュール３に接続している。
図１（ａ）、（ｂ）の開発支援装置１０（１０Ａ、１０Ｂ）は、ユーザ等に任意のアプリケーションプログラムを作成させ、これをコンパイルして実行オブジェクトコードを生成した後、ネットワーク１を介して実行オブジェクトコードをＰＬＣモジュール２又は４に転送する。この転送処理は、予め登録されるシステム定義に従って行われるが、これについては特に説明しない。
【００４２】
図１（ａ）、（ｂ）の開発支援装置１０（１０Ａ、１０Ｂ）は、上記転送に係わる処理に関しては多少の違いがあるが、本手法に係わる機能は略同一であるので、同一符号を付してあり、以後、特に区別せずに説明するものとする。
【００４３】
図１（ａ）、（ｂ）に示す開発支援装置１０は、コンパイラ１１、リンカ１２、ＰＯＵサイズ算出機能部１３、呼出情報生成機能部１４、最適負荷配分機能部１５を有する。
コンパイラ１１とリンカ１２は、従来の開発支援装置でも備えられている一般的な機能であり、ここでは特に説明しない。また、特に図示・説明しないが、従来の開発支援装置でも備えられている一般的な機能として、更に、ユーザに任意のアプリケーションを作成させる機能を有するものであってもよい。本例の開発支援装置１０は、更に上記ＰＯＵサイズ算出機能部１３、呼出情報生成機能部１４、最適負荷配分機能部１５を有することを特徴としている。
【００４４】
ユーザにより任意のアプリケーションプログラムが作成された後、コンパイラ１１等によりこのアプリケーションが実行オブジェクトコードに変換される。実行オブジェクトコードのサイズは、ＲＩＳＣ型のＣＰＵにおいて、ほぼコードステップ数と同等であると考えられる。これより、本手法では、実行オブジェクトコードのサイズに基づいて、ＣＰＵにおけるプログラムの実行時間を推定し、負荷の大きさを算出する。
【００４５】
呼出情報生成機能部１４は、コンパイラ１１による上記アプリケーションプログラムのコンパイル時に「ＰＯＵの呼び出し情報（相関ツリー）」を生成してメモリ等に保存する。この呼出情報生成機能部１４の機能は、既存技術であるので、ここでは詳細には説明しないが、「ＰＯＵの呼び出し情報（相関ツリー）」の一例を図３（ａ）、（ｂ）に示す。
【００４６】
図３（ａ）は「ＰＯＵの呼び出し情報」を分かり易く示す為のイメージ図であり、実際のデータ格納形式は図３（ｂ）に示す。
ここで、本例では、ＩＥＣ61131-3のような機能単位の構造化設計を例にする。上述してあるように、構造化設計の場合、同一の機能単位、関数等が別々のプログラムから呼び出されることが多い。
【００４７】
ここで、上記ＰＯＵとは、ＩＥＣ61131-3に規定されている、プログラムの最小単位であり、プログラム（ＰＧ）、ファンクション（ＦＣＴ）、ファンクションブロック（ＦＢ）の総称である。そして、本例では、上記アプリケーションプログラムは、複数のプログラム（ＰＧ）より成り、図３（ａ）、（ｂ）に示す一例ではＰＧ１、ＰＧ２、ＰＧ３、ＰＧ４、ＰＧ５の５つのプログラム（ＰＧ）より成るものとする。
【００４８】
そして、通常、図３（ａ）、（ｂ）に示すように、各プログラム（ＰＧ）は、１以上のファンクション（ＦＣＴ）または／及び１以上のファンクションブロック（ＦＢ）を呼び出す構造となっている。また、プログラム（ＰＧ）から呼び出されたファンクションブロック（ＦＢ）が、更に他のファンクションブロック（ＦＢ）を呼び出し、または／及び、１以上のファンクション（ＦＣＴ）を呼び出す場合もある。
【００４９】
何れにしても本例では上記ＰＧ１、ＰＧ２、ＰＧ３、ＰＧ４、ＰＧ５の各プログラム（ＰＧ）を、１つの「処理単位」（１つのまとまった処理）としてアプリケーション処理が実行されるものであり、この様な「処理単位」を更に分割して複数のＣＰＵに分配・実行させることは困難である。従って、上記ＰＧ１〜ＰＧ５のような複数の「処理単位」から成るアプリケーションを、複数のＣＰＵで実行させる場合には、「処理単位」毎にＣＰＵに分配する必要がある（例えば後に図５に示す例の様に分配する）。尚、本例では上記ＰＧ１〜ＰＧ５の各プログラム（ＰＧ）を「処理単位」としたが、この例に限るものではない。
【００５０】
尚、上記「処理単位」とは、広義には例えば後述するようにアプリケーションを任意の複数のグループに分割して、各グループを「処理単位」とするようにしてもよいが、狭義には、上記ＰＧ１〜ＰＧ５の例のようにそれ以上分割することが困難である（ＣＰＵ側で正常に実行できなくなる）ようにグループ分けしたものを「処理単位」と呼んでも良い。
【００５１】
各プログラム（ＰＧ）が、ファンクション（ＦＣＴ）、ファンクションブロック（ＦＢ）等の各種ＰＯＵを呼び出すことで、そのプログラム（ＰＧ）に係わる処理が実行される。これは、別の言い方をすれば、上記プログラム（ＰＧ）をプログラム本体と見做し、このプログラム本体から上記各種ＰＯＵを呼び出すことで、１つのプログラムの処理が実現するものと言うこともできる。よって、上記「処理単位」を、プログラム本体と、当該プログラム本体から呼び出される１以上のＰＯＵとから構成されるものと見做してもよい。
【００５２】
あるいは、上記ＰＧは当該ＰＧから呼び出される１以上のＰＯＵも含むものとし、上記のようにＰＧが上記「処理単位」（１つのプログラム）に相当するものと見做してもよい（但し、この場合でも、後述するサイズ算出に関しては、ＰＧのサイズはプログラム本体部分としてのサイズとなる）。
【００５３】
尚、図３（ｂ）には、図３（ａ）に示す各プログラムＰＧ１〜ＰＧ５のうち一例としてプログラムＰＧ１についてのみ「ＰＯＵの呼び出し情報」のデータ格納例を示す。
これより、図３（ｂ）も参照してプログラムＰＧ１を例にして詳細に説明するならば、プログラムＰＧ１は、ファンクションＦＣＴ１、ファンクションＦＣＴ１、ファンクションＦＣＴ２、ファンクションブロックＦＢ１、ファンクションブロックＦＢ１を順次呼び出す。尚、ファンクションＦＣＴ１が最初に２回連続して呼び出されているように、同一のファンクション／ファンクションブロックが複数回呼び出される場合もある。
【００５４】
図３（ｂ）に示すように、プログラム（ＰＧ）から呼び出されるＰＯＵは、階層１のＰＯＵとして規定される。階層１のＰＯＵから呼び出されるＰＯＵは、階層２のＰＯＵとして規定される。階層２のＰＯＵから呼び出されるＰＯＵは、階層３のＰＯＵとして規定される。
【００５５】
尚、プログラム（ＰＧ）が呼び出されることはないので、“呼び出されるＰＯＵ”とは、ＰＧを除くＰＯＵを意味し、よってＦＢまたはＦＣＴを意味する。これは、換言すれば、上記各階層１〜３のＰＯＵは、全て、ＦＢまたはＦＣＴであることを意味する。尚、ここではＰＧ（プログラム本体）もＰＯＵの一種であると見做しているが、ＰＧはＰＯＵとは区別して扱うようにしてもよい。
【００５６】
図３（ｂ）に示すように、階層１の各ＰＯＵのうち、ファンクションブロックＦＢ１とＦＢ２は、更にＰＯＵを呼び出す。呼び出されるＰＯＵは階層２のＰＯＵと規定されることになる。すなわち、階層１のファンクションブロックＦＢ１は、階層２のファンクションＦＣＴ１，ＦＣＴ２を呼び出し、階層１のファンクションブロックＦＢ２は、階層２のファンクションＦＣＴ１とファンクションブロックＦＢ３を呼び出す。
【００５７】
呼び出された（階層２の）ファンクションブロックＦＢ３は、ファンクションＦＣＴ１，ＦＣＴ２と，ファンクションブロックＦＢ４（何れも階層３）を呼び出す。
上記の例では、例えば、ファンクションＦＣＴ１は全部で５回呼び出されることになり、呼び出される毎にファンクションＦＣＴ１が実行されるので、ファンクションＦＣＴ１の実行時間を仮にｔ１とするならば、プログラムＰＧ１に係わるファンクションＦＣＴ１の全実行時間は「５×ｔ１」となることになる。
【００５８】
ここで、上記ファンクションＦＣＴ１の実行時間ｔ１は、ファンクションＦＣＴ１の実行オブジェクトコードのサイズ（上記の通り、ほぼコードステップ数と同等）によって決まるものと見做してよい。例えば、仮に１ステップ当たりの処理実行に掛かる時間をｔ２とした場合、ＦＣＴ１のステップ数が後述する例の様に‘３’であるならば、ｔ１＝３×ｔ２ということになる。
【００５９】
このように、実行オブジェクトコードのサイズ（ステップ数）と実行時間とは、単純な計算式により相関関係が記述できると考えられることから、実行オブジェクトコード・サイズ（コードステップ数）を算出することにより、ユーザが作成したアプリケーションプログラムの各「処理単位」毎の（例えば各プログラム（ＰＧ）毎の）実行時間を推定することができる。各ＣＰＵの負荷の大きさを、処理時間（割り当てられた全てのＰＧの実行時間）として見積もることができる。
【００６０】
上記ＰＯＵサイズ算出機能部１３は、アプリケーションの各ＰＯＵ（ＰＧ／ＦＢ／ＦＣＴ）それぞれの実行オブジェクトコードのサイズ（≒コードステップ数）を求めて記憶する。図３（ａ）に示すアプリケーションの例の場合、図４（ａ）に示すように、各プログラムＰＧ１〜ＰＧ５それぞれのサイズ、各ファンクションブロックＦＢ１、ＦＢ２，ＦＢ３，ＦＢ４それぞれのサイズ、各ファンクションＦＣＴ１，ＦＣＴ２，ＦＣＴ３それぞれのサイズが、求められることになる。
【００６１】
尚、ＰＯＵサイズ算出機能部１３自体は、一般的なコンパイラに備えられている既存の機能であり、これ以上詳細には説明しないが、
ここで、図２に、開発支援装置１０の処理フローチャート図を示す。
【００６２】
開発支援装置１０は、任意のアプリケーションプログラムが生成された後、任意のときにまず、その実行オブジェクトコード生成処理を実行する（ステップＳ１１）。この実行オブジェクトコード生成時に、上記の通り、ＰＯＵサイズ算出機能部１３が、各ＰＯＵ（ＰＧ／ＦＢ／ＦＣＴ）それぞれの実行オブジェクトコードのサイズ（≒コードステップ数）を求めて記憶し、呼出情報生成機能部１４が、「ＰＯＵの呼び出し情報(相関ツリー)」を生成して保存する。この「ＰＯＵの呼び出し情報(相関ツリー)」の生成機能も、一般的なコンパイラに備えられている既存の機能であり、これ以上詳細には説明しない。
【００６３】
このように、このステップＳ１１の処理（コンパイルによる実行オブジェクトコード生成と実行オブジェクトコードサイズの生成・記憶と「ＰＯＵの呼び出し情報(相関ツリー)」の生成・保存）は、一般的なコンパイラが実行する既存の処理と考えて良い。
【００６４】
本手法の特徴的な機能は、次のステップＳ１２とステップＳ１３の処理にある。上記最適負荷配分機能部１５が、ステップＳ１２、Ｓ１３の処理を実行する。
まず、ステップＳ１２では、各プログラム（ＰＧ）毎に、そのＰＧの総実行オブジェクトコードサイズ（実行オブジェクトコードサイズ総数）を、以下の（１）式によって求める。
【００６５】
【数１】
2012118715.tif 000003
尚、上記（１）式における「呼び出し回数」は、例えば「実行回数」に置き換えてもよい。上記（１）式による総実行オブジェクトコードサイズにはプログラム（ＰＧ）自体のサイズも含まれるが、上記の通りプログラム（ＰＧ）自体は呼び出されるものではないからである。
【００６６】
既に例えばプログラムＰＧ１に係わるファンクションＦＣＴ１の全実行時間は「５×ｔ１」である旨説明したが、上記（１）式ではｔ１の代わりにファンクションＦＣＴ１の実行オブジェクトコードのサイズ（≒コードステップ数）を用いるものと考えてよい。各ＰＯＵの実行オブジェクトコードのサイズ（≒コードステップ数）は、ＰＯＵサイズ算出機能部１３が求めて記憶してあるので（図４（ａ））、これを参照すればよい。
【００６７】
図３（ｂ）に示す例では、プログラムＰＧ１に関して呼び出されるＰＯＵは、ファンクションブロックＦＢ１，ＦＢ２，ＦＢ３、ファンクションＦＣＴ１，ＦＣＴ２，ＦＣＴ４であり、これら各ＰＯＵの呼び出し回数（実行回数）は、ＦＢ１が１回、ＦＢ２が１回、ＦＢ３が１回、ＦＣＴ１が５回、ＦＣＴ２が３回、ＦＣＴ４が１回であり、これにプログラムＰＧ１自体（プログラム本体）の実行回数（１回）が加わる。
【００６８】
ここで、仮に、「＜ＰＯＵ＞；ＰＯＵのオブジェクトコードサイズを表すもの」とする。すなわち、各ＰＯＵの実行オブジェクトコードのサイズ（≒コードステップ数）を、例えばＰＧ１は＜ＰＧ１＞、ＦＢ１は＜ＦＢ１＞、ＦＣＴ１は＜ＦＣＴ１＞等と表記するものとする。そして、各ＰＯＵ（ＰＧ／ＦＢ／ＦＣＴ）それぞれの実行オブジェクトコードのサイズ（≒コードステップ数）が仮に図４（ａ）に示す通りとするならば、上記（１）式による上記プログラムＰＧ１の総実行オブジェクトコードサイズ（実行オブジェクトコードサイズ総数）は、以下のように算出される。
【００６９】
プログラムＰＧ１の総実行オブジェクトコードサイズ
＝＜ＰＧ１＞×１＋＜ＦＢ１＞×１＋＜ＦＢ２＞×１＋＜ＦＢ３＞×１＋＜ＦＢ４＞×１＋＜ＦＣＴ１＞×５＋＜ＦＣＴ２＞×３
＝１０×１＋６×１＋７×１＋８×１＋６×１＋３×５＋１×３
＝５５
他の各プログラムＰＧ２、ＰＧ３、ＰＧ４、ＰＧ５についても、同様にして、図３（ａ）に示す「ＰＯＵの呼び出し情報」と、図４（ａ）に示す各ＰＯＵの実行オブジェクトコードのサイズとを用いて、上記（１）式によって総実行オブジェクトコードサイズを算出すると、その結果は図４（ｂ）に示す通りとなる。
【００７０】
最適負荷配分機能部１５は、図４（ｂ）に示す情報（アプリケーションプログラムを構成する各プログラム（ＰＧ）毎の実行オブジェクトコードサイズ総数）が得られたら、このサイズ総数情報に基づいて複数のＣＰＵに対して処理負荷が略均等になるようにして各プログラム（ＰＧ１〜ＰＧ５）を割り当てる（ステップＳ１３）。割り当て結果の一例を図５に示す。
【００７１】
図５に示す例では、ＣＰＵ１に対してはプログラムＰＧ１とＰＧ５を割り当て、ＣＰＵ２に対してはプログラムＰＧ２とＰＧ３とＰＧ４を割り当てている。各プログラムＰＧ１〜ＰＧ５の総実行オブジェクトコードサイズは図４（ｂ）に示す通りであるので、ＣＰＵ１に割り当てられる実行オブジェクトコードサイズはトータルで５５＋７＝６２となり、ＣＰＵ２に割り当てられる実行オブジェクトコードサイズはトータルで２５＋１８＋１６＝５９となり、ＣＰＵ１の処理負荷とＣＰＵ２の処理負荷は殆ど同じ（略均等）であると見做すことができる。つまり、ほぼ最適な負荷配分が行えたと見做すことができる。
【００７２】
そして、上記ステップＳ１３で決定した各ＣＰＵに対する各プログラム（ＰＧ１〜ＰＧ５）の割り当て結果に応じて、各プログラム（ＰＧ１〜ＰＧ５）のメモリ振分けを行う（ステップＳ１４）。これは例えば、図５の例の場合、プログラムＰＧ１とＰＧ５をＣＰＵ１に送信してそのメモリ等に格納させ、プログラムＰＧ２とＰＧ３とＰＧ４をＣＰＵ２に送信してそのメモリ等に格納させるものである。尚、ステップＳ１４の処理も最適負荷配分機能部１５が実行するものであってもよいし、ステップＳ１４の処理は不図示の他の機能部（各ＣＰＵへのプログラム振分け自体は既存機能であり特に説明しない）が実行するものであってもよい。
【００７３】
尚、ＣＰＵ１とＣＰＵ２は、例えば図１（ａ）に示す例のＣＰＵ２ａとＣＰＵ２ｂに相当すると考えても良い。あるいは、ＣＰＵ１とＣＰＵ２は、例えば図１（ｂ）に示す例のＣＰＵ４ａとＣＰＵ４ｂに相当すると考えても良い。
【００７４】
また、尚、上記各プログラム（ＰＧ１〜ＰＧ５）の実行順番が決まっている場合には、従来より例えば開発支援装置１０側にＰＧ実行順番を示す情報（実行順番テーブルというものとする；不図示）が格納されているので、例えば上記ステップＳ１４の処理の際にこの実行順番テーブルもＣＰＵ１のメモリ、ＣＰＵ２のメモリに記憶させるようにしてもよい。それによって、例えばＣＰＵ１において、ＰＧ５を先に実行して、後にＰＧ１を実行するようなことも起こり得る。
【００７５】
上記各プログラム（ＰＧ）毎の総実行オブジェクトコードサイズに基づく複数のＣＰＵへの各プログラムの割り当て方法は、様々な方法であってよく、一例を以下に説明するが、これらの例に限るものではない。
【００７６】
すなわち、例えば、
（１）負荷（サイズ）が大きいプログラム（ＰＧ）から順に各ＣＰＵへ順次割り当てていく方法。
【００７７】
例えば、図４（ｂ）に示す例では、負荷（サイズ）が大きいプログラム（ＰＧ）から順次割り当てると、ＰＧ１→ＰＧ２→ＰＧ３→ＰＧ４→ＰＧ５の順番で各プログラム（ＰＧ）を順次割り当ることになる。
【００７８】
ここで、例えば一例としては、最初は各ＣＰＵにＰＧを負荷（サイズ）が大きいものから順に１つずつ割り当て、その後は現在の負荷（サイズ）の割り当て総量が最も小さいＣＰＵへ次のＰＧ（残っているなかで最もサイズが大きいＰＧ）を割り当てる方法が考えられる。
【００７９】
この方法によれば、図４（ｂ）に示す例では、最初はＰＧ１をＣＰＵ１に割り当て、ＰＧ２をＣＰＵ２に割り当てることになる。その後は、ＰＧ３はＣＰＵ２に割り当て、続くＰＧ４もＣＰＵ２に割り当てることになる（何れも、その時点の負荷の割り当て総量が、ＣＰＵ１＞ＣＰＵ２であるので）。最後に、ＰＧ５は、ＣＰＵ１に割り当てることになる（その時点の負荷の割り当て総量が、ＣＰＵ１（＝５５）＜ＣＰＵ２（＝２５＋１８＋１６＝５９）であるので）。
【００８０】
この様な割り当て処理によって、図５に示す結果となる。
この様にして、例えば図５に示すように、ＣＰＵ１の処理負荷とＣＰＵ２の処理負荷が殆ど同じ（略均等）となるように、アプリケーションプログラムを構成する各プログラム（ＰＧ）を、複数のＣＰＵに割り当てることが出来る。
【００８１】
（２）割り当て負荷総量の平均値（平均の負荷配分値）を求めて、各ＣＰＵ毎に平均値を越えるまで各プログラム（ＰＧ）を割り当てていく方法。
これは、例えば、まず、各ＣＰＵへ割り当てる負荷総量の平均値を算出する。これは、上記全てのプログラムＰＧ１〜ＰＧ５の総実行オブジェクトコードサイズの総和を求める。図４（ｂ）の例では、総和＝５５＋２５＋１８＋１６＋７＝１２１となる。
【００８２】
この総和をＣＰＵ数で割ることで、各ＣＰＵへ割り当てる負荷総量の平均値を算出する。仮に図５の例と同様にＣＰＵ１、ＣＰＵ２の２つのＣＰＵに割り当てる場合、平均値＝１２１÷２＝６０．５となる。
【００８３】
そして、例えばまずＣＰＵ１に対して、平均値（＝６０．５）を越えるまでプログラム（ＰＧ）を割り当てていく。これは、一例としては、各プログラム（ＰＧ）をランダムに割り当てていく。但し、この例に限らず、例えば以下に説明するようにしてもよい。
【００８４】
すなわち、負荷（サイズ）が大きいプログラム（ＰＧ）から順次割り当てるようにする。但し、上記（１）とは異なり、１つのＣＰＵに対して上記平均値を越えるまで集中的に割り当てる。更に、平均値を越えた時点で完了とせずに、平均値を越えたときに割り当てたプログラム（ＰＧ）を、未だ割り当てていない他のプログラム（ＰＧ）と置き換えて、合計サイズが最も平均値に近いものに決定する。
【００８５】
すなわち、ＣＰＵ１に対してまずＰＧ１を割り当て、次にＰＧ２を割り当てると、合計サイズ＝５５＋２５＝８０なので平均値（＝６０．５）を越えたことになる。ここで、ＰＧ２の代わりに未だ割り当てていない他のプログラムＰＧ３，ＰＧ４，ＰＧ５を順次割り当てると、ＰＧ３の場合の合計サイズ＝５５＋１８＝７３、ＰＧ４の場合の合計サイズ＝５５＋１６＝７１、ＰＧ５の場合の合計サイズ＝５５＋７＝６２となり、ＰＧ５の場合が最も平均値に近いので、ＣＰＵ１に対してはＰＧ１とＰＧ５を割り当てることになる。
【００８６】
（３）組み合せ最適化問題として定義し、最適化手法（経験的手法・メタヒューリスティック等）を用いて解く方法。
この最適化手法自体は、既存の一般的な手法であり、ここでは特に説明しないが、この方法によれば、負荷の大きさにバラツキがあった場合や負荷の数が膨大になるような複雑な場合においても、最適な負荷配分を求めることができる。
【００８７】
また、上記（１）、（２）、（３）の３つの方法を組み合わせて、複数のＣＰＵにプログラム（ＰＧ）を割り当てるようにしてもよい。例えば、図４（ｂ）の例において、まず最初は、（１）の方法により最もサイズが大きいＰＧ１をＣＰＵ１に割り当て、２番目にサイズが大きいＰＧ２をＣＰＵ２に割り当てる。その後は、残りのＰＧ３、ＰＧ４，ＰＧ５を１つ以上、ＰＧ１またはＰＧ２と適宜組み合わせることで、様々な組み合わせを作成すると共に作成した組み合わせによる合計サイズ（例えば、ＰＧ１とＰＧ３の組み合わせでは合計サイズは５５＋１８＝７３となる）を求める。そして、合計サイズと上記平均の負荷配分値（＝６０．５）との差異が最も小さくなるような組み合わせを求める。
【００８８】
尚、負荷の数が膨大となる場合での負荷配分では、１つの負荷が全体の負荷に与える影響が軽減されるため、（１）や（２）の方法を単独で行うことも有効であると考えられる。
【００８９】
尚、本例では「ＰＯＵの呼び出し情報」を用いているが、“どのＰＯＵがどのＰＯＵを呼び出したか”を知る必要はなく、上記のように単に各プログラム（ＰＧ）毎に、そのＰＧに係わる各ＰＯＵの実行回数が分かればよいのである。本例では既存機能である呼出情報生成機能部１４によって生成される「ＰＯＵの呼び出し情報」を利用しているのであるが、この様な例に限らない。何れにしても必ずしも「ＰＯＵの呼び出し情報」である必要はなく、単に各ＰＯＵの実行回数が分かる様な情報であればなんでもよい。
【００９０】
IEC-61131-3では、１つのアプリケーションを実行する処理実行部をリソースと呼んで一元管理する概念を持っている。アプリケーションの負荷を配分する対象が、図１（ａ）のように複数のＣＰＵモジュール２に該当する場合は、一旦１つの実行処理部であると仮定して上記の様に実行オブジェクトコードサイズを算出し、その後、各ＣＰＵモジュール２に実行オブジェクトを割り付ける方法によって負荷配分を行う。
【００９１】
これは、図１（ｂ）のＣＰＵモジュール４のような例えばマルチコアマイクロプロセッサやコプロセッサを備えた演算装置に負荷を配分する場合も、同様の考え方で負荷配分を行うことが出来る。但し、図１（ｂ）の１つのＣＰＵモジュール４内の複数のＣＰＵ４ａ，４ｂは、同一の実行コードを実行する同一性能のマイクロプロセッサもしくは演算ＬＳＩなどであるものとし、コンパイル対象のユーザアプリケーションは、各機能の実行結果を相互に参照しないこと前提とする。
【００９２】
ここで上記オブジェクトコードのステップ数について、具体例を図６に示して説明する。図６において、図６（ａ）はプログラミング画面を示し、任意のプログラム部品（ここではＡＤＤ関数）を示している。このプログラム部品をコンパイルすることで、図６（ｂ）に示す実行オブジェクトコード（点線で囲った部分）が生成される。図示の通り、この実行オブジェクトコードのステップ数は‘９’である（９行；９ステップ）。
【００９３】
また、本例の開発支援装置１０は、ハードウェア的には例えばパソコン等の汎用のコンピュータ装置により実現できる。
以上説明した一実施形態を、実施例１とする。
【００９４】
以下、実施例２について説明する。
但し、実施例２の説明を行う前に、上記従来の図１３の例の場合における実施例１の具体例について、図７を参照して説明する。
【００９５】
まず、図１３（ａ）の例の場合、上記実施例１による負荷配分を行った結果は、例えば図７（ａ）に示す通りとなる。尚、ここでは、図１（ａ）に示す例に適用するものとし、図１（ａ）に示す２つのＰＬＣモジュール２を、ここでは基本コントローラ２、拡張コントローラ２として区別して記述するものとする。
【００９６】
また、図７（ｂ）は図１（ａ）に示すＰＬＣシステムを示すものであって、２つのＰＬＣモジュール２の詳細構成例を示しており、ここでは図１３（ｂ）に示した従来構成と略同様の構成であるものとする。また、図示の２つのＰＬＣモジュール２の詳細構成例には、図７（ａ）に示す負荷配分結果を反映させている。また、図７（ｂ）に示す入出力機器５は、図１３（ｂ）に示した従来構成における入出力機器１０２と略同様の構成であり、あるいは図１に示すＩ／Ｏモジュール３に相当する構成であると考えてもよい。
【００９７】
尚、２つのＰＬＣモジュール２は略同様の構成であるが、ここでは符号は区別して付してある。すなわち、図７（ｂ）に示す通り、基本コントローラ２は、入力メモリ２１ａ、出力メモリ２２ａ、マイコン２３ａを有する。同様に、拡張コントローラ２は、入力メモリ２１ｂ、出力メモリ２２ｂ、マイコン２３ｂを有する。尚、マイコン２３ａは図１におけるＣＰＵ２ａに相当し、マイコン２３ｂはＣＰＵ２ｂに相当する。
【００９８】
上記図７（ａ）に示す例の場合、例えば基本コントローラ２にはプログラムＡとプログラムＤが割り当てられ、拡張コントローラ２にはプログラムＢとプログラムＣとが割り当てられる。これより、基本コントローラ２、拡張コントローラ２の両方とも、トータルのオブジェクトサイズは‘５０’となり、均等に負荷配分が行われることになる。しかしながら、上記図１５で説明した問題が生じる。つまり「プログラムの出力の一義性（または同期性）」が損なわれることになる。
【００９９】
すなわち、この場合、図７（ｂ）に示すように、開発支援装置１０においてコンパイラ１１等によって生成された各プログラムの実行オブジェクトコード（プログラムＡ，Ｂ，Ｃ，Ｄ）は、それぞれ、基本コントローラ２、拡張コントローラ２の何れか一方にダウンロードされる。本例では、図７（ａ）に示す負荷配分に従って、プログラムＡとプログラムＤは基本コントローラ２にダウンロードされ、プログラムＢとプログラムＣは拡張コントローラ２にダウンロードされる。
【０１００】
これによって、その後は、基本コントローラ２においてはマイコン２３ａ（ＣＰＵ２ａ）がプログラムＡとプログラムＤを定周期で実行する毎に、上記図１４で説明した上記入力処理Ｉとして変数ａ、変数ｃ、変数ｄをまとめて入力メモリ２１ａから読込み、各プログラムＡ，Ｄを順次実行し、その処理結果（変数ｓ、変数ｖ）をまとめて出力メモリ２２ａに書き込むことになる（出力処理Ｏを実行する）。
【０１０１】
尚、図では入力メモリ２１ａには変数ａ、変数ｃ、変数ｄを示すが、これは入力メモリ２１ａに格納されている変数のうちプログラムＡ及びプログラムＤによって読み込む変数のみを示している。よって、入力メモリ２１ａには不図示の他の変数も格納されていてよい。これは、出力メモリ２２ａ、入力メモリ２１ｂ、出力メモリ２２ｂに関しても同様である。
【０１０２】
また、図１３（ｂ）で説明した従来例と同様、入力メモリ２１ａ、２１ｂに格納される各変数の値は、入出力機器５からの入力処理に伴って更新される場合がある。同様に、出力メモリ２２ａ、２２ｂに格納される各変数の値は、出力処理によって入出力機器５へ出力される。これら入力処理、出力処理は、入出力機器５側が行っても良いし、マイコン２３ａ，２３ｂが上記プログラムＡ〜Ｄ以外の他のプログラムを実行することによって行っても良い。
【０１０３】
拡張コントローラ２においてはマイコン２３ｂ（ＣＰＵ２ｂ）がプログラムＢとプログラムＣを定周期で実行する毎に、上記図１４で説明した上記入力処理Ｉとして変数ｂ、変数ｃをまとめて入力メモリ２１ｂから読込み、各プログラムＢ，Ｃを順次実行し、その処理結果（変数ｔ、変数ｕ）をまとめて出力メモリ２２ｂに書き込むことになる（出力処理Ｏを実行する）。
【０１０４】
上記の様に、基本コントローラ２、拡張コントローラ２の両方で入力データとして変数ｃを用いており、入力変数ｃの値に応じて出力変数ｓ，ｕの値が決まることになり、よって、入力変数ｃの値が変われば出力変数ｓ，ｕの値も変わることになる。従って図１５で説明した通り、変数ｃが変化するタイミングと、基本コントローラ２、拡張コントローラ２各々の入力処理Ｉのタイミングとによって、場合によっては、出力変数ｓが変化するタイミングと出力変数ｕが変化するタイミングとが大きく異なることになる。つまり、上述した「プログラムの出力の一義性（または同期性）」が保てないことになる。
【０１０５】
この様に、「プログラムの出力の一義性（または同期性）」を損なわないことが条件に加わると、上記実施例１の負荷配分結果は、適切（最適）とは言えないことになる。
これに対して、実施例２では、プログラムの出力の一義性（または同期性）を保ったうえでほぼ最適な（略均等な）負荷配分を行える。
【０１０６】
図８に、実施例２の開発支援装置２０を含むＰＬＣシステムを示す。
開発支援装置２０は、コンパイラ２１、リンカ２２、ＰＯＵサイズ算出機能部２３、呼出情報生成機能部２４、最適負荷配分機能部２５、変数リスト情報生成機能部２６を有する。このうち、コンパイラ２１、リンカ２２、ＰＯＵサイズ算出機能部２３、呼出情報生成機能部２４は、上記実施例１のコンパイラ１１、リンカ１２、ＰＯＵサイズ算出機能部１３、呼出情報生成機能部１４と略同様であってよく、ここでは特に説明しない。
【０１０７】
開発支援装置２０は、プログラムの出力の一義性（または同期性）を保ったうえでほぼ最適な（略均等な）負荷配分を行える。これより、上記図１３（ａ）の例の場合、各プログラムＡ，Ｂ，Ｃ，Ｄの配分結果は、例えば図８の図上下側に示す通りとなるが、これについては、後に図９も参照して説明する。
【０１０８】
変数リスト情報生成機能部２６は、変数リスト情報を生成するものであり、既存のコンパイラの機能の一部と考えてよい。尚、変数リスト情報の具体例は、図１０に示し、後に説明する。
【０１０９】
最適負荷配分機能部２５は、まず、上記最適負荷配分機能部１５と同様に、各プログラム毎に、そのプログラムの総実行オブジェクトコードサイズ（実行オブジェクトコードサイズ総数）を上記（１）式を用いて算出する。上記の例では、各プログラムＡ，Ｂ，Ｃ，Ｄ毎の総実行オブジェクトコードサイズを算出することになる。
【０１１０】
最適負荷配分機能部２５は、続いて、上記変数リスト情報を用いて、複数のプログラムが同じ入力変数を持つ場合には、当該複数のプログラムをひとまとめにして扱う。ひとまとめにした複数のプログラム（ペアやグループ；以下、プログラム・グループという）の総実行オブジェクトコードサイズの総和（以下、グループサイズ総数というものとする）を求めるようにしてもよい。例えば上記プログラムＡ〜Ｄの例では、プログラムＡとプログラムＣをひとまとめにすることになり、プログラム・グループ“Ａ＋Ｃ”のグループサイズ総数は１０＋３０＝４０となる。
【０１１１】
そのうえで、例えばまず、グループ化された複数のプログラムをグループ単位で複数のＣＰＵに対して配分する。上記の例ではプログラム・グループは１つだけなので、このグループすなわち上記プログラム・グループ“Ａ＋Ｃ”を（プログラムＡとプログラムＣとを）、基本コントローラ２、拡張コントローラ２の何れか一方に配分する。図８や図９に示す例では基本コントローラ２に配分しているが、この例に限らない。
【０１１２】
また、複数のグループがある場合にも、グループ単位で複数のＣＰＵに配分するが、この配分方法は任意であってよいが（例えば、基本コントローラ２と拡張コントローラ２とに交互に配分する等）、以下に説明する方法であってもよい。
【０１１３】
すなわち、各グループの上記グループサイズ総数に基づいて、上記実施例１と略同様の配分方法により、各グループを複数のＣＰＵに配分するようにしてもよい。このように、プログラム・グループが複数（特に３つ以上）となった場合には、各グループのグループサイズ総数に基づいて、グループ単位での配分が終了した段階でも出来るだけ処理負荷が略均等となるように配分を行うようにしてもよい。
【０１１４】
その後、残りのプログラム（グループ化されたプログラム以外のプログラム）を、その総実行オブジェクトコードサイズに基づいて配分する。つまり、上記プログラム・グループの配分が確定した状態から、実施例１と略同様の配分方法により配分を行う。
【０１１５】
あるいは、プログラム・グループを１つのプログラムとして扱うことで、プログラムとプログラム・グループとを区別することなく一緒にまとめて配分するようにしてもよい。この場合は、例えば、プログラム・グループをプログラムとして扱うと共にグループサイズ総数を総実行オブジェクトコードサイズとして扱ったうえで、実施例１の方法と略同様にしてプログラム配分を行う。上記の例では、例えば、プログラムＢ、プログラムＤ、プログラム“Ａ＋Ｃ”の３つのプログラムがあり、各プログラムの総実行オブジェクトコードサイズが２０、４０、４０であるものとして、実施例１の手法により例えば２つのＣＰＵ（２ａと２ｂ、もしくは４ａと４ｂ）に対するプログラム配分を行うことになる。
【０１１６】
何れにしても、実施例２では、複数のプログラムを複数のＣＰＵに配分する処理において、以下の優先順位に従って処理を行うことになる。
優先順位１；同一変数を使用しているプログラムは、同一ＣＰＵ（コントローラ）に配置する。
【０１１７】
優先順位２；各ＣＰＵ（コントローラ）の処理負荷が略均等となるようにプログラム配分する。
実施例１では、優先順位２の条件のみに従って配分処理を行ったが、実施例２では優先順位１の条件が加わり、且つこれは優先順位２よりも優先順位が高いものである。
【０１１８】
そして、実施例２では上記一例の場合、プログラム配分結果は例えば図８や図９（ａ）に示す通りとなる。例えば、まず、プログラム・グループの配分を行う。本例ではプログラム・グループは“Ａ＋Ｃ”の１つのみであるので、これを基本コントローラ２、拡張コントローラ２の何れかに配分する。図８や図９（ａ）に示す例では基本コントローラ２に配分している。次に、残りのプログラムＢ，Ｄを配分する。まず、比較的オブジェクトサイズが大きいプログラムＤが配分対象となり、拡張コントローラ２に割り当てることになる。これにより、基本コントローラ２、拡張コントローラ２の両方で負荷が‘４０’になるので、プログラムＢはどちらに割り当ててもよいが、図８や図９（ａ）に示す例では拡張コントローラ２に配分している。
【０１１９】
これより、図８や図９（ａ）に示すように、基本コントローラ２にはプログラムＡとプログラムＣが配分され、拡張コントローラ２にはプログラムＢとプログラムＤが配分される。実施例１の方法を用いる場合には図７（ａ）に示すように、基本コントローラ２の負荷は‘５０’で、拡張コントローラ２の負荷も‘５０’であり、完全に均等に負荷配分できている。一方、本例では図９（ａ）に示すように、基本コントローラ２の負荷は‘４０’で、拡張コントローラ２の負荷は‘６０’であり、完全に均等に負荷配分することはできていない。しかしながら、同じ入力変数ｃを用いるプログラムＡとプログラムＣを同じＣＰＵ２（基本コントローラ２）に割り当てることが出来ているので、「プログラムの出力の一義性（または同期性）」が損なわれないで済む。
【０１２０】
これより、図９（ｂ）に示すように、基本コントローラ２の入力処理ＩにおいてプログラムＡ，Ｃの入力変数ａ，ｃがまとめて入力され、この入力変数ａ，ｃに基づいてプログラムＡ，Ｃが順次実行され、基本コントローラ２の出力処理ＯにおいてプログラムＡの処理結果である出力変数ｓとプログラムＣの処理結果である出力変数ｕがまとめて出力メモリ２２ａに出力される。これより、図示の通り、入力変数ｃが変化すると、これに応じて出力変数ｓ，ｕも略同一のタイミングで変化することになる。つまり、「プログラムの出力の一義性（または同期性）」が保たれていることになる。
【０１２１】
ここで、図１０に上記変数リスト情報の具体例を示す。また、図１１に、実施例２の最適負荷配分機能部２５の処理の一部を示すフローチャート図を示す。以下、図１０、図１１を参照して、実施例２の負荷配分処理の具体例について説明する。
【０１２２】
まず、上述した説明では、配分対象のプログラムは、プログラムＡ〜Ｄの４つとしたが、図１０に示す例では１６個のプログラムがあるものとし、これら各プログラムの変数リスト情報が図１０に示すＰＧ情報０、ＰＧ情報１、・・・ＰＧ情報１５である。尚、これらの変数リスト情報に対応するプログラムを、ＰＧ０、ＰＧ１、・・・ＰＧ１５等と呼ぶものとする。
【０１２３】
上記ＰＧ情報０、ＰＧ情報１、・・・ＰＧ情報１５の各変数リスト情報のデータ構成は略同様であり、図１０ではＰＧ情報０とＰＧ情報１のデータ構成を示すが、図示の通りデータ構成は同じであり、同一符号を付してある。
【０１２４】
よって、特にＰＧ情報０、ＰＧ情報１を区別せずに説明するが、図示の通り変数リスト情報は、プログラム番号４１、サイズ４２、グループ番号４３、コントローラ番号４４、入力変数個数４５、入力変数群４６、出力変数個数４７、出力変数群４８等から成る。
【０１２５】
プログラム番号４１は、各プログラムの識別番号であり、例えば上記ＰＧ０は‘０’、ＰＧ１は‘１’、ＰＧ１５は‘１５’等とする。
サイズ４２は、例えば上記実施例１の図４（ａ）に示す各プログラム（ＰＧ１〜ＰＧ５）毎の実行オブジェクトコードサイズ等に相当する、各プログラム本体のオブジェクトコードのサイズ情報である。
【０１２６】
グループ番号４３は、そのプログラムと同じ入力変数を有する他のプログラムを示すＢｉｔ情報であり、各プログラムに１Ｂｉｔずつ割り当て、よって上記の例ではＰＧ０〜ＰＧ１５の１６個のプログラムに対応して１６Ｂｉｔの情報となる。グループ番号４３は、初期状態では全Ｂｉｔ情報が‘０’となっている。グループ番号４３については、後に図１１を参照して詳しく説明する。
【０１２７】
コントローラ番号４４は、そのプログラムの配分先のＣＰＵ（コントローラ）を示す情報であり、ここでは、基本コントローラは‘０’、拡張コントローラは‘１’であるものとする。この例では、コントローラ番号４４は、後述する図１１の処理によって‘０’または‘１’が設定されるものであり、初期状態では無データとなっている。
【０１２８】
入力変数個数４５は、入力変数群４６に格納される入力変数の個数である。
入力変数群４６は、そのプログラムで用いる各入力変数（変数名、変数の格納アドレス等、その変数を示す情報；本例では各入力変数の格納アドレスであるものとする）である。
【０１２９】
出力変数個数４７は、出力変数群４８等に格納される出力変数の個数である。
出力変数群４８は、そのプログラムで用いる各出力変数（変数名、変数の格納アドレス等、その変数を示す情報；本例では各出力変数の格納アドレスであるものとする）である。
【０１３０】
概略的には、図１０に示すように、任意の２つのＰＧ情報（図ではＰＧ情報０とＰＧ情報１）の入力変数群４６の各入力変数（各変数の格納アドレス）を総当りで比較して、一致するものがあるか否かをチェックする。例えばＰＧ情報０とＰＧ情報１とで一致する格納アドレスが１つ以上ある場合には（同じ入力変数が１つ以上ある場合には）、当該２つのＰＧ情報のプログラムは、同じＣＰＵ（コントローラ）に配分すべきものとする。つまり、１つのグループにまとめる。詳しくは図１１を参照して説明する。
【０１３１】
図１１において、まず、チェック対象プログラムのＰＧ情報の入力変数群４６を読み込み（ステップＳ２１）、比較対象プログラムのＰＧ情報の入力変数群４６を読み込む（ステップＳ２２）。比較対象プログラムは、チェック対象プログラム以外の全てのプログラムが成り得る。例えば、チェック対象プログラムをＰＧ０とした場合、比較対象プログラムと成り得るのはＰＧ１〜ＰＧ１５であり、ステップＳ２６の判定がＮＯとなる毎に比較対象プログラムを順次更新していく（ＰＧ１→ＰＧ２→ＰＧ３→・・・→ＰＧ１４→ＰＧ１５）。そして、チェック対象プログラムと各比較対象プログラムとで同じ入力変数を有するか否かをステップＳ２３，Ｓ２４，Ｓ２５の処理によりチェックする（アドレス比較チェックを行う）。チェック完了したら、ステップＳ２７がＮＯとなる毎にチェック対象プログラムを更新し、次のチェック対象プログラムについても同様にして各比較対象プログラムとのアドレス比較チェックを行う。
【０１３２】
尚、次のチェック対象プログラムがＰＧ１となったならば、比較対象プログラムはＰＧ０とＰＧ２〜ＰＧ１５としてもよいし、既にチェック対象プログラムとなったプログラム（ここではＰＧ０のみ）は除外してＰＧ２〜ＰＧ１５としてもよい。
【０１３３】
ステップＳ２３，Ｓ２４，Ｓ２５の処理では、チェック対象プログラムの入力変数群４６の各入力変数（その格納アドレス）と、比較対象プログラムの入力変数群４６の各入力変数（その格納アドレス）とを総当りで順次比較し、一致する入力変数（同じ格納アドレス）があった場合には（ステップＳ２３，ＹＥＳ）、チェック対象プログラムと比較対象プログラムの両方のＰＧ情報のグループ番号４３の該当ビットを立てる（ビットＯＮする）（ステップＳ２４）。
【０１３４】
該当ビットとは、チェック対象プログラムのＰＧ情報のグループ番号４３においては、比較対象プログラムに対応するビットであり、比較対象プログラムのＰＧ情報のグループ番号４３においては、チェック対象プログラムに対応するビットである。尚、上記の通り、グループ番号４３は、ＰＧ０〜ＰＧ１５の１６個のプログラムに対応した１６Ｂｉｔの情報である。ここでは、ＰＧ０に対応するビットをビット‘０’、ＰＧ１に対応するビットをビット‘１’、・・・ＰＧ１５に対応するビットをビット‘１５’と記すものとする。
【０１３５】
これより、例えば上記のＰＧ０とＰＧ１の例の場合、相互に一致する入力変数（格納アドレス）があった場合には、ＰＧ情報０のグループ番号４３はビット‘１’がＯＮし、ＰＧ情報１のグループ番号４３はビット‘０’がＯＮすることになる。尚、仮にＰＧ０とＰＧ１５とを比較して、相互に一致する入力変数（格納アドレス）があった場合に、ＰＧ情報０のグループ番号４３はビット‘１５’がＯＮし、ＰＧ情報１５のグループ番号４３はビット‘０’がＯＮすることになる。尚、本手法では、どの変数が一致したのかはプログラム配分には関係ないので、一致した変数を示す情報を記録するようなことはない。
【０１３６】
図１１に示す処理例では、チェック対象プログラムの全ての入力変数と、比較対象プログラムの全ての入力変数とを、総当りで比較チェックするまで（ステップＳ２５の判定がＹＥＳとなるまで）上記ステップＳ２３，Ｓ２４の処理を繰り返し実行する。但し、これは一例であり、この例に限らず、例えばステップＳ２４の処理を実行した場合にはステップＳ２６へ移行するようにしてもよい。一致する入力変数が複数ある場合でも上記ステップＳ２４の処理を複数回実行するだけなので、結局、ステップＳ２４の処理を１回だけ実行する場合と比べて処理結果は変わらないからである。但し、本説明は図１１に示す一例に沿って説明する。
【０１３７】
チェック対象プログラムの全ての入力変数と比較対象プログラムの全ての入力変数との総当りの比較チェックが完了したら（ステップＳ２５，ＹＥＳ）、現在のチェック対象プログラムと他の全てのプログラムとの比較チェック処理が実行されたか否かを判定する（ステップＳ２６）。
【０１３８】
未だ現在のチェック対象プログラムとの比較チェック処理が行われていないプログラムが残っているならば（ステップＳ２６、ＹＥＳ）、当該未処理のプログラムを新たな比較対象プログラムにしてステップＳ２２に戻ることで、チェック対象プログラムと当該新たな比較対象プログラムとの比較チェック処理が開始されることになる。
【０１３９】
一方、他の全てのプログラムとの比較チェック処理が実行済みとなったならば（ステップＳ２６，ＮＯ）、未だチェック対象プログラムとなっていないプログラムがあるか否かを確認し（ステップＳ２７）、ある場合には（ステップＳ２７，ＹＥＳ）当該未チェックのプログラムを新たなチェック対象プログラムとしてステップＳ２１に戻る。これによって、当該新たなチェック対象プログラムと他の全てのプログラムとの比較チェック処理が開始されることになる。
【０１４０】
そして、全てのプログラムをチェック対象プログラムにして上記比較チェック処理を実行したならば、全てのプログラムの上記グループ番号４３を参照して、ステップＳ２８，Ｓ２９，Ｓ３０の処理を行うことで、同じ入力変数を有するプログラムは１つのグループにまとめて、当該グループ化されたプログラムはグループ単位でＣＰＵ（コントローラ）に配分する。
【０１４１】
これは、まず、各プログラムの上記グループ番号４３を参照して、そのプログラムがグループ化対象か否かを判定する（ステップＳ２８）。すなわち、上記の例ではグループ番号４３はＰＧ０〜ＰＧ１５の１６個のプログラムに対応した１６Ｂｉｔの情報であるので、１６Ｂｉｔ全てがＯＦＦであるプログラムは、他のプログラムと共有する入力変数が１つも無いプログラムであり、グループ化対象ではないと判定され（ステップＳ２８，ＮＯ）、そのままステップＳ３０へ移行する。ステップＳ３０では全てのプログラムについて上記ステップＳ２８の判定を実行したか否かを判定し、未実行のプログラムがある場合には（ステップＳ３０，ＹＥＳ）、ステップＳ２８に戻る。
【０１４２】
一方、上記１６Ｂｉｔのうちの１ｂｉｔでも立っている（ＯＮしている）ならば、そのプログラムはグループ化対象であると判定され（ステップＳ２８，ＹＥＳ）、ステップＳ２９の処理を実行して、上記ステップＳ３０の処理を実行する。
【０１４３】
ステップＳ２９の処理では、まず当該処理対象プログラムの上記グループ番号４３（ステップＳ２８で参照したもの）を再度参照して、今度は当該処理対象プログラムと同じグループとすべき（共有する入力変数がある）他のプログラムを判別する。上記の通り、１６Ｂｉｔの情報はＰＧ０〜ＰＧ１５の１６個のプログラムに対応しており、例えば‘３’ビットと‘５’ビットがＯＮであったならば、ＰＧ３とＰＧ５が当該処理対象プログラムと同じグループとすべきプログラムであることが分かる。
【０１４４】
そして、当該処理対象プログラムと、当該“同じグループとすべきプログラム”とを、同じＣＰＵ（コントローラ）に割り当てるようにコントローラ番号４４を設定する。図１０に示す例では、コントローラ番号４４は１ｂｉｔの情報であり、‘０’が基本コントローラ、‘１’が拡張コントローラへの割り当てを意味する。よって、この例では、当該処理対象プログラムのコントローラ番号４４と、当該“同じグループとすべきプログラム”のコントローラ番号４４とを同じ値に設定する（両方とも‘０’または両方とも‘１’とする）。
【０１４５】
コントローラ番号４４を‘０’と‘１’のどちらに設定するのかは、任意に決めてよく、例えばステップＳ２９の処理を実行する毎に交互に設定する（‘０’→‘１’→‘０’→‘１’・・・）ようにしてもよいし、既に述べたように実施例１と略同様の手法により配分先を決定してもよい。但し、当該処理対象プログラムのコントローラ番号４４が既に設定済みの場合には、当該設定値を用いるものとする。
【０１４６】
例えば、ここで簡単の為にＰＧ０、ＰＧ１、ＰＧ２の３つのプログラムを例にして以下の具体例を想定する。
ＰＧ０、ＰＧ１、ＰＧ２は全て入力変数個数４５は‘２’であり、つまり、入力変数群４６は「アドレス１」と「アドレス２」のみであるものとする。そして、ＰＧ０に関しては、「アドレス１」は変数ａの格納アドレス、「アドレス２」は変数ｂの格納アドレスとする。同様に、ＰＧ１に関しては、「アドレス１」は変数ｃの格納アドレス、「アドレス２」は変数ａの格納アドレスとする。ＰＧ２に関しては、「アドレス１」は変数ｄの格納アドレス、「アドレス２」は変数ｃの格納アドレスとする。
【０１４７】
この例において、ＰＧ０、ＰＧ１、ＰＧ２の順番で上記ステップＳ２８等の処理を行った場合には、当然、全てがステップＳ２８でＹＥＳとなりステップＳ２９の処理を行うことになる。そして、まず、ＰＧ０についてはＰＧ１が“同じグループとすべきプログラム”であることが分かり、例えばＰＧ０とＰＧ１の両方ともコントローラ番号４４を‘０’に設定したものとする。
【０１４８】
続いて、ＰＧ１を処理対象としたとき、ＰＧ０とＰＧ２を“同じグループとすべきプログラム”であることが分かり、基本的には上記の通り交互に設定するものとした場合には、今度はＰＧ０、ＰＧ１、ＰＧ２の全てのコントローラ番号４４を‘１’に設定することになる。しかしながら、その前に、処理対象のＰＧ１のコントローラ番号４４が設定済みか否かをチェックし、設定済みの場合には当該設定値を用いて未設定のコントローラ番号４４を設定する。すなわち、この場合、ＰＧ１のコントローラ番号４４の設定値‘０’を用いて、ＰＧ２のコントローラ番号４４を‘０’に設定する（ＰＧ０とＰＧ１は既に設定済みなので、そのままとする）。
【０１４９】
尚、上記ステップＳ２９の処理において上記のように（特に複数のグループがある場合において）実施例１と略同様の手法により配分先を決定する場合には、各グループ毎の総実行オブジェクトコードサイズを求めて、このサイズ情報に基づいて上記実施例１と略同様の手法により配分先を決定するようにしてもよい。
【０１５０】
すなわち、この例では例えば一例としては、まず、各グループ毎に、そのグループに属する各プログラムの総実行オブジェクトコードサイズを上記（１）式により算出して、算出結果の総和を求めることで、上記各グループ毎の総実行オブジェクトコードサイズを求める。そして、例えば実施例１の上記（１）の方法を利用する場合には「負荷（総実行オブジェクトコードサイズ）が大きいグループから順に各ＣＰＵへ順次割り当てていく方法」となる。勿論、実施例１の他の方法（上記（２）の方法や（３）の方法、あるいはこれら各方法の組み合わせ等）を利用するようにしてもよい。
【０１５１】
尚、当然ながら、グループを配分する（ＣＰＵへ割り当てる）とは、そのグループに属する全てのプログラムを配分する（ＣＰＵへ割り当てる）ことを意味する。
上記ステップＳ２８〜Ｓ３０の処理が終了したら(ステップＳ３０，ＹＥＳ)、未配分のプログラムの配分先を決定する（ステップＳ３１）。上記ステップＳ２９の処理によって、グループ化されるプログラムの配分は既に済んでいるので、残りの（グループ化されない）プログラムのＣＰＵへの配分を行う。ステップＳ３１の配分処理は、実施例１の配分処理と同じであってよく、ここでは特に説明しない。但し、グループ化されるプログラムの上記配分結果（コントローラ番号４４の設定値）は、変更不可の扱いとし、従ってステップＳ３１の処理で後から変更されることはない。この様な制約が入る為、既に述べた通り、負荷配分の最適化に関しては実施例１の方が優れているかもしれないが、実施例２ではプログラムの出力の一義性（または同期性）を保ったうえでの負荷配分の最適化を図ることができる。
【０１５２】
また、実施例１では説明していなかったが、ステップＳ３１の処理では“残りのプログラム”の配分先を決定したら、それに応じてこれらのプログラムのコントローラ番号４４をセットする処理も行う。
【０１５３】
具体例としては、例えば上記例のようにＰＧ０とＰＧ１とＰＧ２とが１グループとなり、更に仮にＰＧ３とＰＧ４とが１グループとなり、更にＰＧ５とＰＧ６とが１グループとなり、ＰＧ７〜ＰＧ１５はグループ化されないとした場合、上記の例では例えば、ＰＧ０とＰＧ１とＰＧ２とＰＧ５とＰＧ６とが基本コントローラ２に割り当てられ、ＰＧ３とＰＧ４とが拡張コントローラ２に割り当てられ、これらの割り当ては確定済みとした状態で、ＰＧ７〜ＰＧ１５について実施例１と同様の処理によって複数のＣＰＵ（本例では基本コントローラ２と拡張コントローラ２）への割り当てを行うことになる。
【０１５４】
尚、実施例１と同様の処理とは、既に実施例１で述べたが以下にも再度示すように、（１）の方法、（２）の方法、（３）の方法や、これらの方法の組み合わせである。
（１）の方法；負荷（サイズ）が大きいプログラム（ＰＧ）から順に各ＣＰＵへ順次割り当てていく方法。
（２）の方法；割り当て負荷総量の平均値（平均の負荷配分値）を求めて、各ＣＰＵ毎に平均値を越えるまで各プログラム（ＰＧ）を割り当てていく方法。
（３）の方法；組み合せ最適化問題として定義し、最適化手法（経験的手法・メタヒューリスティック等）を用いて解く方法。
【０１５５】
また、本例の開発支援装置２０は、上記開発支援装置１０と同様、ハードウェア的には例えばパソコン等の汎用のコンピュータ装置により実現できる。
図１２は、開発支援装置１０，２０のハードウェア構成の具体例を示す図であり、これはパソコン等の汎用のコンピュータの構成であると考えてよい。
【０１５６】
図１２において、コンピュータ３０は、ＣＰＵ３１、メモリ３２、入力部３３、出力部３４、記憶部３５、記録媒体駆動部３６、及びネットワーク接続部３７を有し、これらがバス３８に接続された構成となっている。
【０１５７】
ＣＰＵ３１は、当該コンピュータ３０全体を制御する中央処理装置である。
メモリ３２は、任意の処理実行の際に、記憶部３５（あるいは可搬型記録媒体３９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ３１は、メモリ３２に読み出したプログラム／データを用いて、上述した各種処理を実行する。
【０１５８】
出力部３４は、例えばディスプレイ等であり、入力部３３は、例えば、キーボード、マウス等である。
ネットワーク接続部３７は、例えば上記ネットワーク１等に接続して、他の情報処理装置（ＣＰＵモジュール２，４等）との通信（コマンド／データ送受信等）を行う為の通信モジュールである。
【０１５９】
記憶部３５は、例えばハードディスク等であり、上述した開発支援装置１０、２０の各種処理機能をＣＰＵ３１により実現させる為のアプリケーションプログラムが格納されている。すなわち、上記コンパイラ１１、リンカ１２、ＰＯＵサイズ算出機能部１３、呼出情報生成機能部１４、最適負荷配分機能部１５の各種処理機能部の処理機能を、ＣＰＵ３１により実現させる為のアプリケーションプログラムが格納されている。あるいは、上記コンパイラ２１、リンカ２２、ＰＯＵサイズ算出機能部２３、呼出情報生成機能部２４、最適負荷配分機能部２５、変数リスト情報生成機能部２６の各種処理機能部の処理機能を、ＣＰＵ３１により実現させる為のアプリケーションプログラムが格納されている。特に、図１１のフローチャートの処理を、ＣＰＵ３１により実現させる為のアプリケーションプログラムが格納されている。
【０１６０】
ＣＰＵ３１は、上記記憶部３５に格納されている各種プログラムを読み出し・実行することにより、上述した各種処理を実現する。
また、上記図３（ｂ）や図４（ａ），（ｂ）や図１０に示す各種情報は、記憶部３５やメモリ３２等に記憶されるものである。
【０１６１】
上記記憶部３５に格納される各種プログラム／データは、可搬型記録媒体３９に記憶されているものであってもよい。この場合、可搬型記録媒体３９に記憶されているプログラム／データは、記録媒体駆動部３６によって読み出される。可搬型記録媒体３９とは、例えば、ＦＤ（フレキシブル・ディスク）３９ａ、ＣＤ−ＲＯＭ３９ｂ、その他、ＤＶＤ、光磁気ディスク等である。
【０１６２】
あるいは、また、上記プログラム／データは、ネットワーク接続部３７により接続しているネットワークを介して、他の装置内に記憶されているものをダウンロードするものであってもよい。あるいは、更に、インターネットを介して、外部の他の装置内に記憶されているものをダウンロードするものであってもよい。
【０１６３】
また、本発明は、上記本発明の各種処理をコンピュータ上で実現するプログラムを記録した可搬型記憶媒体として構成できるだけでなく、当該プログラム自体として構成することもできる。
【０１６４】
尚、上述した説明は一例であり、この例に限らない。ユーザが作成するアプリケーションが、例えばラダー図を用いるプログラムであっても構わない。本手法ではコンパイル後のプログラム（実行オブジェクトコード；機械語）を用いるので、ユーザが使用するＰＬＣ言語が何であっても関係ないからである。そして、実行オブジェクトコードのサイズ（ステップ数）を用いることで、的確に負荷を推定でき、それによってほぼ最適な負荷配分を実現できる。
【０１６５】
ＰＬＣ言語に関係なく本例の開発支援装置１０の機能を概略的に説明するならば、特に図示等しないが本例の開発支援装置１０は以下の各種機能部を有するものと言うことができる。
【０１６６】
まず、複数の演算処理部（ＣＰＵ）で演算させるべき任意のアプリケーションプログラムをコンパイルすることで実行オブジェクトコードを生成するコンパイル機能部（不図示）を備える。
【０１６７】
また、例えば、上記アプリケーションプログラムを複数のグループ（ここでは一例として特に上記「処理単位」）に分割しておく。これは、例えば開発者等が決めて設定しておく。
【０１６８】
そして、開発支援装置１０は、更に、これら複数の「処理単位」毎に、その「処理単位」に係わる実行オブジェクトコードのサイズの総数を求める総実行オブジェクトコードサイズ算出機能部（不図示）を備える。更に、上記アプリケーションプログラムの処理を上記各「処理単位」で複数の演算処理部（ＣＰＵ）に配分する機能部であって、上記各「処理単位」毎の実行オブジェクトコードサイズ総数（全ステップ数など）に基づいて、複数の演算処理部の負荷が略均等となるように上記アプリケーションプログラムの処理を各演算処理部に配分する負荷配分機能部（不図示）を備える。
【０１６９】
この様に、本例の開発支援装置１０は、概略的には上記各種不図示の機能部を備えるものであるということもできる。
上記特許文献１に記載の従来技術は、システムの稼動時に行う動的な負荷配分方式であるため、初期の負荷配分が不適切であった場合には、システム始動時には、ＣＰＵの負荷が偏り、ＰＬＣシステムで要求される定時性を損う可能性がある。その点、静的な負荷配分方式である本手法では、システム始動時から信頼性の高い運用を行うことが出来る。
【０１７０】
また、上記特許文献２記載の従来技術は、システムの非稼動時に行う静的な負荷配分方式でありこの点では本手法と同類であるが、特許文献２ではＳＦＣの特徴を利用しているため、他の言語に関しては適用することができず、特にＰＬＣの分野で最もよく利用されている言語であるラダー言語に対応できないという大きな問題が生じる。
【０１７１】
これに対して、本手法では、ＳＦＣやラダー言語等のプログラマが用いるＰＬＣ言語には関係なく、何らかのＰＬＣ言語で記述されたプログラムをコンパイルすることで生成される実行オブジェクトコード（機械語等）を用いて負荷配分を行うので、ＰＬＣ言語が何であっても関係なく適用可能である。つまり、本手法では、特許文献２記載の従来技術に比べて汎用性が高いことになる。
【０１７２】
このように、本手法によれば、複数のＣＰＵを有するＰＬＣシステムにおいて、システム始動時から最適な負荷配分でアプリケーション実行させることができることや、ＰＬＣ言語に依存せずに適用可能である等の様々なメリットが得られる。
【０１７３】
上記本手法を適用したＰＬＣシステムによれば、複数のＣＰＵに対して自動的に（運用初期から）ほぼ最適な負荷配分を行えることで、システムの大規模化・複雑化による増大する「ユーザのシステム開発時間」を短縮することができる。また、コンパイル時に自動的にほぼ最適な負荷配分を行えることで、ユーザのノウハウに依存しない、安定した運用を可能にし、システムの信頼性を向上させることができる。
【０１７４】
また、既に述べたように、ＰＬＣのアプリケーションは、従来のラダー言語などによる処理単位で記述された単純構造のプログラムではなく、ＩＥＣ61131-3のような多言語を駆使した機能単位の構造化設計が行われるようになってきており、ユーザが処理全体の流れを把握することが困難に成ってきている。構造化設計の場合、同一の機能単位、関数等が別々のプログラムから呼び出されることが多く、プログラム作成者が複数にわたる開発も多くなってきている。
【０１７５】
このような状況では、複数のＣＰＵに対してアプリケーションプログラム作成者等が自力で負荷配分を行うことは難易度が高く、結果的に処理負荷のアンバランスによるトータルシステム処理性能の低下、またシステム立ち上げ時の工数の増加が考えられる。これに対して、本手法では、このような難易度が高いものに対しても、自動的にほぼ最適な負荷配分を行えるので、この様な問題も解決できる。
【０１７６】
尚、「システム立ち上げ時の工数」とは、アプリケーションを複数の演算処理部（ＣＰＵ等）に配分するユーザの手間を意味する。本手法では、この様なシステム立ち上げに掛かる工数を削減することができる。
【０１７７】
また、ＰＬＣ言語に関係なく上記実施例２の開発支援装置２０の機能を概略的に説明するならば、特に図示等しないが本例の開発支援装置２０は以下の各種機能部を有するものと言うことができる。
【０１７８】
まず、複数の演算処理部（ＣＰＵ等）で演算させるべき任意のアプリケーションプログラムをコンパイルすることで実行オブジェクトコードを生成するコンパイル機能部（不図示）を備える。
【０１７９】
また、例えば、上記アプリケーションプログラムを複数のグループ（ここでは一例として特に上記「処理単位」）に分割しておく。これは、例えば開発者等が決めて設定しておく。
【０１８０】
そして、開発支援装置２０は、更に、これら複数の「処理単位」毎に、その「処理単位」に係わる実行オブジェクトコードのサイズの総数を求める総実行オブジェクトコードサイズ算出機能部（不図示）を備える。更に、上記複数の「処理単位」毎に、その「処理単位」に係わる入力変数等から成る変数リスト情報を生成する変数リスト情報生成機能部（不図示）を有する。尚、変数リスト情報生成機能部は、上記コンパイル機能部の機能の一部であってもよい。
【０１８１】
そして、開発支援装置２０は、更に、上記アプリケーションプログラムの処理を上記各「処理単位」で上記複数の演算処理部に配分する機能部であって、上記総実行オブジェクトコードサイズ算出機能部によって算出される上記各「処理単位」それぞれの実行オブジェクトコードサイズ総数（全ステップ数など）と、上記変数リスト情報とに基づいて、共通の入力変数を有する「処理単位」は同じ演算処理部に配分することを条件として、この条件を満たしつつ上記複数の演算処理部それぞれの負荷が略均等となるように上記アプリケーションプログラムの各「処理単位」を上記各演算処理部に配分する負荷配分機能部を有する。尚、上記各演算処理部は、自己に割り当てられた全ての処理単位に係る入力変数をまとめて入力し、自己に割り当てられた全ての処理単位を順次実行し、該実行結果をまとめて出力するものである。
【０１８２】
あるいは、開発支援装置２０は、プログラム本体と該プログラム本体から呼び出される各種ＰＯＵより成る複数のプログラムより構成される任意のアプリケーションの実行に係わる負荷を、複数の演算処理部に分散して配分する機能を有し、以下の各種機能部（何れも不図示）を有するものと見做すこともできる。
【０１８３】
すなわち、まず、複数の演算処理部（ＣＰＵ等）で演算させるべき上記任意のアプリケーションプログラムをコンパイルすることで、その実行オブジェクトコードを生成するコンパイル機能部を備える。これは、例えば、上記プログラム本体／ＰＯＵそれぞれの実行オブジェクトコードを生成するものとなる。
【０１８４】
そして、例えばこのコンパイル処理に伴って、上記アプリケーションを構成する各プログラム毎に少なくともそのプログラムに係わる入力変数が含まれる変数リスト情報を生成する変数リスト情報生成機能部と、上記プログラム本体／ＰＯＵそれぞれの実行オブジェクトコードのサイズを求めるＰＯＵサイズ算出機能部と、ＰＯＵの呼び出し情報を求める呼出情報生成機能部とを有する。これら各種機能部は、既存の構成であると考えてもよい。
【０１８５】
そして、開発支援装置２０は、更に、上記プログラム本体／ＰＯＵそれぞれの実行オブジェクトコードのサイズと、上記ＰＯＵの呼び出し情報とに基づいて、上記アプリケーションを構成する各プログラム毎に、そのプログラムに係わるプログラム本体／各ＰＯＵの実行オブジェクトコードのサイズと各ＰＯＵの実行回数とに応じた実行オブジェクトコードサイズ総数を算出する総実行オブジェクトコードサイズ算出機能部を有する。
【０１８６】
更に、開発支援装置２０は、上記各プログラムを複数の演算処理部に配分する機能部であって、上記総実行オブジェクトコードサイズ算出機能部によって算出される各プログラムそれぞれの実行オブジェクトコードサイズ総数と、上記変数リスト情報とに基づいて、共通の入力変数を有するプログラムは同じ演算処理部に配分することを条件として、この条件を満たしつつ複数の演算処理部それぞれの負荷が略均等となるように各プログラムを各演算処理部に配分する負荷配分機能部を有する。尚、上記“プログラム本体／（各）ＰＯＵ”は、“プログラム本体または（各）ＰＯＵ”の意味である。
【０１８７】
また、上記開発支援装置２０において、一例として例えば、上記負荷配分機能部は、まず、上記共通の入力変数を有するプログラムはグループ化して該グループ単位で演算処理部に配分する。その後、グループ化されなかった残りの各プログラムを、該各プログラムの実行オブジェクトコードサイズ総数に基づいて、各演算処理部に割り当てられた全てのプログラムの実行オブジェクトコードサイズ総数の総和が該複数の演算処理部で略均等となるように、演算処理部に配分するようにしてもよい。
【０１８８】
あるいは、上記開発支援装置２０において、一例として例えば、上記負荷配分機能部は、まず、上記共通の入力変数を有するプログラムはグループ化すると共に、そのグループに属する全てのプログラムの実行オブジェクトコードサイズ総数の総和を該グループの実行オブジェクトコードサイズ総数として算出する。そして、該算出されたグループ単位の実行オブジェクトコードサイズ総数と、グループ化されなかった各プログラムの実行オブジェクトコードサイズ総数とに基づいて、グループ化されたプログラムはグループ単位で配分し且つ各演算処理部に割り当てられた全てのプログラムの実行オブジェクトコードサイズ総数の総和が該複数の演算処理部で略均等となるように、各プログラムを演算処理部に配分するようにしてもよい。
【０１８９】
この様に、実施例２の開発支援装置２０は、概略的には上記各種不図示の機能部を備えるものであるということもできる。
尚、実施例２における上記複数の演算処理部は、それぞれ、自己に割り当てられた全ての処理単位（またはプログラム）に係る入力変数をまとめて入力し、該自己に割り当てられた全ての処理単位（またはプログラム）を順次実行し、該実行結果をまとめて出力する。各演算処理部がこの様な動作を行う場合には、共通の入力変数を有する「処理単位」（またはプログラム）が、異なる演算処理部に配分されてしまうと、プログラムの出力の一義性（同期性）を保てなくなるが、実施例２の開発支援装置２０ではこの様な問題が生じないようにでき、そのうえでほぼ最適な負荷配分を行うことが可能となる。
【符号の説明】
【０１９０】
１  ネットワーク
２  ＰＬＣモジュール
２ａ、２ｂ  ＣＰＵ
３  Ｉ／Ｏモジュール
４  ＰＬＣモジュール
４ａ，４ｂ  ＣＰＵ
５  入出力機器
１０  開発支援装置
１１  コンパイラ
１２  リンカ
１３  ＰＯＵサイズ算出機能部
１４  呼出情報生成機能部
１５  最適負荷配分機能部
２１  コンパイラ
２２  リンカ
２３  ＰＯＵサイズ算出機能部
２４  呼出情報生成機能部
２５  最適負荷配分機能部
２６  変数リスト情報生成部
２１ａ，２１ｂ  入力メモリ
２２ａ、２２ｂ  出力メモリ
２３ａ，２３ｂ  マイコン
３０  コンピュータ
３１  ＣＰＵ
３２  メモリ
３３  入力部
３４  出力部
３５  記憶部
３６  記録媒体駆動部
３７  ネットワーク接続部
３８  バス
３９  可搬型記録媒体
３９ａ  ＦＤ（フレキシブル・ディスク）
３９ｂ  ＣＤ−ＲＯＭ
【図１】
2012118715.tif 000004
【図２】
2012118715.tif 000005
【図４】
2012118715.tif 000006
【図７】
2012118715.tif 000007
【図８】
2012118715.tif 000008
【図９】
2012118715.tif 000009
【図１０】
2012118715.tif 000010
【図１１】
2012118715.tif 000011
【図１２】
2012118715.tif 000012
【図１３】
2012118715.tif 000013
【図１４】
2012118715.tif 000014
【図１５】
2012118715.tif 000015
【図３】
2012118715.tif 000016
【図５】
2012118715.tif 000017
【図６】
2012118715.tif 000018