JP5655448B2 - Ｐｌｃシステム、その開発支援装置 - Google Patents

Description

本発明は、プログラマブルコントローラの開発支援装置に関する。

近年、マイクロコントローラやＬＳＩを使用した組込システムにおいては、ハードウェアでのクロック周波数の向上などによる実行速度の改善は、限界に近づきつつあり、その為、複数のＣＰＵを並列実行することで全体の実行速度を上げるマルチコア方式が用いられるようになってきている。その際、ユーザは複数の演算処理部（ＣＰＵ）から成るシステムを効率的に利用するために、各ＣＰＵに掛かる負荷を調整することが求められる場合がある。

しかしながら、シーケンシャルな処理が多く、且つリアルタイム性能を要求されることが多いＰＬＣにおいては、負荷の調整には、入出力機器等を含めたシステム構成に依存した処理のノウハウが必要で難易度が高く、システム規模の増大に伴い、調整工数も増大傾向にある。この工数を削減するために考案された負荷の自動分散方式については、従来技術文献として以下の特許文献１，２が存在する。

特許文献１；システム稼動時（動的）に負荷分散する方式。システム稼動時、各ＰＬＣが自己の負荷をそれぞれ算出し、算出した負荷に対応して自己の処理の少なくとも一部を他のＰＬＣに依頼することで、負荷の自動配分を実現している。

特許文献２；システムの非稼動時（静的）に負荷分散する方式。ＰＬＣの国際規格化言語（ＩＥＣ61131-3）の１つであるＳＦＣに特化しつつ、その特徴を利用した自動配分方式を実現している。

特開平９−９１０１１号公報 特開平７−２８３９０号公報

プログラマブルコントローラのアプリケーションは、近年、複雑化、大容量化してきており、複数のＣＰＵに負荷を分散して処理効率を向上させようとしても、その配分を決定することが難しい。また、試行錯誤的に負荷の配分を行った場合、多大な時間が掛かる為、ユーザの負担になってきている。

また、試行錯誤的に負荷の配分を行った場合、多大な時間が掛かる為、ユーザの負担となり、アプリケーションプログラムの開発難易度が増大するだけでなく、開発効率が低下する。

また、近年、ＰＬＣのアプリケーションは、従来のラダー言語などによる処理単位で記述された単純構造のプログラムではなく、ＩＥＣ61131-3のような多言語を駆使した機能単位の構造化設計が行われるようになってきており、ユーザが処理全体の流れを把握することが困難になってきている。構造化設計の場合、同一の機能単位、関数等が別々のプログラムから呼び出されることが多く、プログラム作成者が複数にわたる開発も多くなってきている。

このような状況では、複数のＣＰＵリソースを持つシステムであっても、アプリケーションプログラム作成者が自力で負荷配分を行うことは難易度が高く、結果的に処理負荷のアンバランスによるトータルシステム処理性能の低下、またシステム立ち上げ工数の増加が考えられる。

本発明の課題は、複数の演算処理部を有し、任意のアプリケーション実行に係わる負荷を複数の演算処理部に分散させるＰＬＣシステムにおいて、開発支援装置で自動的にほぼ最適な負荷配分を行え、以ってユーザのシステム開発効率を向上させることができ、システム立ち上げ時の工数削減を図ることができるＰＬＣシステム、その開発支援装置等を提供することである。

本発明のＰＬＣシステムは、開発支援装置と複数の演算処理部を有し、複数のプログラムと該プログラムから呼び出される各種ＰＯＵより構成される任意のアプリケーションの実行に係わる負荷を該複数の演算処理部に分散させ実行するＰＬＣシステムであって、前記開発支援装置は、前記アプリケーションをコンパイルすることで実行オブジェクトコードを生成するコンパイル手段と、前記ＰＯＵそれぞれの前記実行オブジェクトコードのサイズを求めるＰＯＵサイズ算出手段と、前記コンパイル時に前記ＰＯＵの呼び出し情報を求める呼出情報生成手段と、前記ＰＯＵそれぞれの前記実行オブジェクトコードのサイズと、前記ＰＯＵの呼び出し情報とに基づいて、前記アプリケーションを構成するプログラム毎に、そのプログラムに係わる各ＰＯＵの前記実行オブジェクトコードのサイズと実行回数に応じた実行オブジェクトコードサイズ総数を算出する総実行オブジェクトコードサイズ算出手段と、前記各プログラムを前記複数の演算処理部に配分する手段であって、前記総実行オブジェクトコードサイズ算出手段によって算出される前記プログラムそれぞれの実行オブジェクトコードサイズ総数に基づいて、前記複数の演算処理部の負荷が略均等となるように前記各プログラムを前記各演算処理部に配分する負荷配分手段とを有する。

構造化設計の場合、同一の機能単位、関数等が別々のプログラムから呼び出されることが多く、人間が負荷配分を行うには難易度が高いが、上記ＰＬＣシステムでは各ＰＯＵ毎の実行オブジェクトコードのサイズとＰＯＵの呼び出し情報とに基づいて、自動的に適切な負荷配分が行える。

本発明のＰＬＣシステム、その開発支援装置等によれば、開発支援装置で自動的にほぼ最適な負荷配分を行え、以ってユーザのシステム開発効率を向上させることができ、システム立ち上げにかかる工数を削減することができる。これは、ＩＥＣ61131-3のような構造化設計の場合に、特に顕著な効果を奏する。また、実行オブジェクトコードサイズを用いるので、ＰＬＣ言語が何であっても関係なく適用可能である。

（ａ），（ｂ）は、本例のＰＬＣシステムのシステム構成例（その１）、（その２）である。 開発支援装置の処理フローチャート図である。 （ａ）、（ｂ）は「ＰＯＵの呼び出し情報」の一例を示す図である。 （ａ）は実行オブジェクトコードサイズの一例、（ｂ）は総実行オブジェクトコードサイズの一例を一覧で示す図である。 複数のＣＰＵへの負荷配分結果の一例である。 （ａ）、（ｂ）はオブジェクトコードのステップ数について説明する為の図である。 開発支援装置のハードウェア構成例である。

以下、図面を参照して、本発明の実施の形態について説明する。
図１（ａ），（ｂ）は、本例のＰＬＣ（プログラマブルコントローラ）システムのシステム構成例（その１）、（その２）である。

図１（ａ）、（ｂ）のＰＬＣシステムは、何れも、複数の演算処理部（ＣＰＵ）と、開発支援装置１０を有する。但し、図１（ａ）ではそれぞれが演算処理部（ＣＰＵ）を有する複数の演算モジュールより成る構成であり、図１（ｂ）は１つの演算モジュール内に複数の演算処理部（ＣＰＵ）がある構成となっている。何れにしても、演算処理部が複数存在するＰＬＣシステムであり、任意のアプリケーションプログラムを実行する場合には、複数の演算処理部（ＣＰＵ）に負荷を分散させて処理効率を向上させる為に、複数のＣＰＵへの負荷配分を行うものであることを前提とする。

本例のＰＬＣシステム（その開発支援装置）は、上記特許文献１のような運用中に動的に負荷配分を行うものではなく、運用前に静的に負荷配分を行うものである。
図１（ａ）のＰＬＣシステムでは、開発支援装置１０（１０Ａ）と複数のＰＬＣモジュール２（演算モジュール）がネットワーク１に接続しており、ネットワーク１を介して相互に通信可能となっている。各ＰＬＣモジュール２がそれぞれ１つのＣＰＵ２ａ、ＣＰＵ２ｂを有することで、複数の演算処理部（ＣＰＵ）がある構成となっている。

一方、図１（ｂ）のＰＬＣシステムは、開発支援装置１０（１０Ｂ）と１つのＰＬＣモジュール４がネットワーク１に接続しており、ネットワーク１を介して相互に通信可能となっている。このＰＬＣモジュール４が複数のＣＰＵ４ａ，４ｂを有することで、複数の演算処理部（ＣＰＵ）がある構成となっている。

尚、各ＰＬＣモジュール（２ｏｒ４）は、Ｉ／Ｏモジュール３に接続している。
図１（ａ）、（ｂ）の開発支援装置１０（１０Ａ、１０Ｂ）は、ユーザ等に任意のアプリケーションプログラムを作成させ、これをコンパイルして実行オブジェクトコードを生成した後、ネットワーク１を介して実行オブジェクトコードをＰＬＣモジュール２又は４に転送する。この転送処理は、予め登録されるシステム定義に従って行われるが、これについては特に説明しない。

図１（ａ）、（ｂ）の開発支援装置１０（１０Ａ、１０Ｂ）は、上記転送に係わる処理に関しては多少の違いがあるが、本手法に係わる機能は略同一であるので、同一符号を付してあり、以後、特に区別せずに説明するものとする。

図１（ａ）、（ｂ）に示す開発支援装置１０は、コンパイラ１１、リンカ１２、ＰＯＵサイズ算出機能部１３、呼出情報生成機能部１４、最適負荷配分機能部１５を有する。
コンパイラ１１とリンカ１２は、従来の開発支援装置でも備えられている一般的な機能であり、ここでは特に説明しない。また、特に図示・説明しないが、従来の開発支援装置でも備えられている一般的な機能として、更に、ユーザに任意のアプリケーションを作成させる機能を有するものであってもよい。本例の開発支援装置１０は、更に上記ＰＯＵサイズ算出機能部１３、呼出情報生成機能部１４、最適負荷配分機能部１５を有することを特徴としている。

ユーザにより任意のアプリケーションプログラムが作成された後、コンパイラ１１等によりこのアプリケーションが実行オブジェクトコードに変換される。実行オブジェクトコードのサイズは、ＲＩＳＣ型のＣＰＵにおいて、ほぼコードステップ数と同等であると考えられる。これより、本手法では、実行オブジェクトコードのサイズに基づいて、ＣＰＵにおけるプログラムの実行時間を推定し、負荷の大きさを算出する。

呼出情報生成機能部１４は、コンパイラ１１による上記アプリケーションプログラムのコンパイル時に「ＰＯＵの呼び出し情報（相関ツリー）」を生成してメモリ等に保存する。この呼出情報生成機能部１４の機能は、既存技術であるので、ここでは詳細には説明しないが、「ＰＯＵの呼び出し情報（相関ツリー）」の一例を図３（ａ）、（ｂ）に示す。

図３（ａ）は「ＰＯＵの呼び出し情報」を分かり易く示す為のイメージ図であり、実際のデータ格納形式は図３（ｂ）に示す。
ここで、本例では、ＩＥＣ61131-3のような機能単位の構造化設計を例にする。上述してあるように、構造化設計の場合、同一の機能単位、関数等が別々のプログラムから呼び出されることが多い。

ここで、上記ＰＯＵとは、ＩＥＣ61131-3に規定されている、プログラムの最小単位であり、プログラム（ＰＧ）、ファンクション（ＦＣＴ）、ファンクションブロック（ＦＢ）の総称である。そして、本例では、上記アプリケーションプログラムは、複数のプログラム（ＰＧ）より成り、図３（ａ）、（ｂ）に示す一例ではＰＧ１、ＰＧ２、ＰＧ３、ＰＧ４、ＰＧ５の５つのプログラム（ＰＧ）より成るものとする。

そして、通常、図３（ａ）、（ｂ）に示すように、各プログラム（ＰＧ）は、１以上のファンクション（ＦＣＴ）または／及び１以上のファンクションブロック（ＦＢ）を呼び出す構造となっている。また、プログラム（ＰＧ）から呼び出されたファンクションブロック（ＦＢ）が、更に他のファンクションブロック（ＦＢ）を呼び出し、または／及び、１以上のファンクション（ＦＣＴ）を呼び出す場合もある。

何れにしても本例では上記ＰＧ１、ＰＧ２、ＰＧ３、ＰＧ４、ＰＧ５の各プログラム（ＰＧ）を、１つの「処理単位」（１つのまとまった処理）としてアプリケーション処理が実行されるものであり、この様な「処理単位」を更に分割して複数のＣＰＵに分配・実行させることは困難である。従って、上記ＰＧ１〜ＰＧ５のような複数の「処理単位」から成るアプリケーションを、複数のＣＰＵで実行させる場合には、「処理単位」毎にＣＰＵに分配する必要がある（例えば後に図５に示す例の様に分配する）。尚、本例では上記ＰＧ１〜ＰＧ５の各プログラム（ＰＧ）を「処理単位」としたが、この例に限るものではない。

尚、上記「処理単位」とは、広義には例えば後述するようにアプリケーションを任意の複数のグループに分割して、各グループを「処理単位」とするようにしてもよいが、狭義には、上記ＰＧ１〜ＰＧ５の例のようにそれ以上分割することが困難である（ＣＰＵ側で正常に実行できなくなる）ようにグループ分けしたものを「処理単位」と呼んでも良い。

各プログラム（ＰＧ）が、ファンクション（ＦＣＴ）、ファンクションブロック（ＦＢ）等の各種ＰＯＵを呼び出すことで、そのプログラム（ＰＧ）の処理が実行される。
尚、図３（ｂ）には、図３（ａ）に示す各プログラムＰＧ１〜ＰＧ５のうち一例としてプログラムＰＧ１についてのみ「ＰＯＵの呼び出し情報」のデータ格納例を示す。

これより、図３（ｂ）も参照してプログラムＰＧ１を例にして詳細に説明するならば、プログラムＰＧ１は、ファンクションＦＣＴ１、ファンクションＦＣＴ１、ファンクションＦＣＴ２、ファンクションブロックＦＢ１、ファンクションブロックＦＢ１を順次呼び出す。尚、ファンクションＦＣＴ１が最初に２回連続して呼び出されているように、同一のファンクション／ファンクションブロックが複数回呼び出される場合もある。

図３（ｂ）に示すように、プログラム（ＰＧ）から呼び出されるＰＯＵは、階層１のＰＯＵとして規定される。階層１のＰＯＵから呼び出されるＰＯＵは、階層２のＰＯＵとして規定される。階層２のＰＯＵから呼び出されるＰＯＵは、階層３のＰＯＵとして規定される。

尚、プログラム（ＰＧ）が呼び出されることはないので、“呼び出されるＰＯＵ”とは、ＰＧを除くＰＯＵを意味し、よってＦＢまたはＦＣＴを意味する。これは、換言すれば、上記各階層１〜３のＰＯＵは、全て、ＦＢまたはＦＣＴであることを意味する。

図３（ｂ）に示すように、階層１の各ＰＯＵのうち、ファンクションブロックＦＢ１とＦＢ２は、更にＰＯＵを呼び出す。呼び出されるＰＯＵは階層２のＰＯＵと規定されることになる。すなわち、階層１のファンクションブロックＦＢ１は、階層２のファンクションＦＣＴ１，ＦＣＴ２を呼び出し、階層１のファンクションブロックＦＢ２は、階層２のファンクションＦＣＴ１とファンクションブロックＦＢ３を呼び出す。

呼び出された（階層２の）ファンクションブロックＦＢ３は、ファンクションＦＣＴ１，ＦＣＴ２と，ファンクションブロックＦＢ４（何れも階層３）を呼び出す。
上記の例では、例えば、ファンクションＦＣＴ１は全部で５回呼び出されることになり、呼び出される毎にファンクションＦＣＴ１が実行されるので、ファンクションＦＣＴ１の実行時間を仮にｔ１とするならば、プログラムＰＧ１に係わるファンクションＦＣＴ１の全実行時間は「５×ｔ１」となることになる。

ここで、上記ファンクションＦＣＴ１の実行時間ｔ１は、ファンクションＦＣＴ１の実行オブジェクトコードのサイズ（上記の通り、ほぼコードステップ数と同等）によって決まるものと見做してよい。例えば、仮に１ステップ当たりの処理実行に掛かる時間をｔ２とした場合、ＦＣＴ１のステップ数が後述する例の様に‘３’であるならば、ｔ１＝３×ｔ２ということになる。

このように、実行オブジェクトコードのサイズ（ステップ数）と実行時間とは、単純な計算式により相関関係が記述できると考えられることから、実行オブジェクトコード・サイズ（コードステップ数）を算出することにより、ユーザが作成したアプリケーションプログラムの各「処理単位」毎の（例えば各プログラム（ＰＧ）毎の）実行時間を推定することができる。各ＣＰＵの負荷の大きさを、処理時間（割り当てられた全てのＰＧの実行時間）として見積もることができる。

上記ＰＯＵサイズ算出機能部１３は、アプリケーションの各ＰＯＵ（ＰＧ／ＦＢ／ＦＣＴ）それぞれの実行オブジェクトコードのサイズ（≒コードステップ数）を求めて記憶する。図３（ａ）に示すアプリケーションの例の場合、図４（ａ）に示すように、各プログラムＰＧ１〜ＰＧ５それぞれのサイズ、各ファンクションブロックＦＢ１、ＦＢ２，ＦＢ３，ＦＢ４それぞれのサイズ、各ファンクションＦＣＴ１，ＦＣＴ２，ＦＣＴ３それぞれのサイズが、求められることになる。

尚、ＰＯＵサイズ算出機能部１３自体は、一般的なコンパイラに備えられている既存の機能であり、これ以上詳細には説明しないが、
ここで、図２に、開発支援装置１０の処理フローチャート図を示す。

開発支援装置１０は、任意のアプリケーションプログラムが生成された後、任意のときにまず、その実行オブジェクトコード生成処理を実行する（ステップＳ１１）。この実行オブジェクトコード生成時に、上記の通り、ＰＯＵサイズ算出機能部１３が、各ＰＯＵ（ＰＧ／ＦＢ／ＦＣＴ）それぞれの実行オブジェクトコードのサイズ（≒コードステップ数）を求めて記憶し、呼出情報生成機能部１４が、「ＰＯＵの呼び出し情報(相関ツリー)」を生成して保存する。この「ＰＯＵの呼び出し情報(相関ツリー)」の生成機能も、一般的なコンパイラに備えられている既存の機能であり、これ以上詳細には説明しない。

このように、このステップＳ１１の処理（コンパイルによる実行オブジェクトコード生成と実行オブジェクトコードサイズの生成・記憶と「ＰＯＵの呼び出し情報(相関ツリー)」の生成・保存）は、一般的なコンパイラが実行する既存の処理と考えて良い。

本手法の特徴的な機能は、次のステップＳ１２とステップＳ１３の処理にある。上記最適負荷配分機能部１５が、ステップＳ１２、Ｓ１３の処理を実行する。
まず、ステップＳ１２では、各プログラム（ＰＧ）毎に、そのＰＧの総実行オブジェクトコードサイズ（実行オブジェクトコードサイズ総数）を、以下の（１）式によって求める。

尚、上記（１）式における「呼び出し回数」は、例えば「実行回数」に置き換えてもよい。上記（１）式による総実行オブジェクトコードサイズにはプログラム（ＰＧ）自体のサイズも含まれるが、上記の通りプログラム（ＰＧ）自体は呼び出されるものではないからである。

既に例えばプログラムＰＧ１に係わるファンクションＦＣＴ１の全実行時間は「５×ｔ１」である旨説明したが、上記（１）式ではｔ１の代わりにファンクションＦＣＴ１の実行オブジェクトコードのサイズ（≒コードステップ数）を用いるものと考えてよい。各ＰＯＵの実行オブジェクトコードのサイズ（≒コードステップ数）は、ＰＯＵサイズ算出機能部１３が求めて記憶してあるので（図４（ａ））、これを参照すればよい。

図３（ｂ）に示す例では、プログラムＰＧ１に関して呼び出されるＰＯＵは、ファンクションブロックＦＢ１，ＦＢ２，ＦＢ３、ファンクションＦＣＴ１，ＦＣＴ２，ＦＣＴ４であり、これら各ＰＯＵの呼び出し回数（実行回数）は、ＦＢ１が１回、ＦＢ２が１回、ＦＢ３が１回、ＦＣＴ１が５回、ＦＣＴ２が３回、ＦＣＴ４が１回であり、これにプログラムＰＧ１自体の実行回数（１回）が加わる。

ここで、仮に、「＜ＰＯＵ＞；ＰＯＵのオブジェクトコードサイズを表すもの」とする。すなわち、各ＰＯＵの実行オブジェクトコードのサイズ（≒コードステップ数）を、例えばＰＧ１は＜ＰＧ１＞、ＦＢ１は＜ＦＢ１＞、ＦＣＴ１は＜ＦＣＴ１＞等と表記するものとする。そして、各ＰＯＵ（ＰＧ／ＦＢ／ＦＣＴ）それぞれの実行オブジェクトコードのサイズ（≒コードステップ数）が仮に図４（ａ）に示す通りとするならば、上記（１）式による上記プログラムＰＧ１の総実行オブジェクトコードサイズ（実行オブジェクトコードサイズ総数）は、以下のように算出される。

プログラムＰＧ１の総実行オブジェクトコードサイズ
＝＜ＰＧ１＞×１＋＜ＦＢ１＞×１＋＜ＦＢ２＞×１＋＜ＦＢ３＞×１＋＜ＦＢ４＞×１＋＜ＦＣＴ１＞×５＋＜ＦＣＴ２＞×３
＝１０×１＋６×１＋７×１＋８×１＋３×５＋１×３＋６×１
＝５５
他の各プログラムＰＧ２、ＰＧ３、ＰＧ４、ＰＧ５についても、同様にして、図３（ａ）に示す「ＰＯＵの呼び出し情報」と、図４（ａ）に示す各ＰＯＵの実行オブジェクトコードのサイズとを用いて、上記（１）式によって総実行オブジェクトコードサイズを算出すると、その結果は図４（ｂ）に示す通りとなる。

最適負荷配分機能部１５は、図４（ｂ）に示す情報（アプリケーションプログラムを構成する各プログラム（ＰＧ）毎の実行オブジェクトコードサイズ総数）が得られたら、このサイズ総数情報に基づいて複数のＣＰＵに対して処理負荷が略均等になるようにして各プログラム（ＰＧ１〜ＰＧ５）を割り当てる（ステップＳ１３）。割り当て結果の一例を図５に示す。

図５に示す例では、ＣＰＵ１に対してはプログラムＰＧ１とＰＧ５を割り当て、ＣＰＵ２に対してはプログラムＰＧ２とＰＧ３とＰＧ４を割り当てている。各プログラムＰＧ１〜ＰＧ５の総実行オブジェクトコードサイズは図４（ｂ）に示す通りであるので、ＣＰＵ１に割り当てられる実行オブジェクトコードサイズはトータルで５５＋７＝６２となり、ＣＰＵ２に割り当てられる実行オブジェクトコードサイズはトータルで２５＋１８＋１６＝５９となり、ＣＰＵ１の処理負荷とＣＰＵ２の処理負荷は殆ど同じ（略均等）であると見做すことができる。つまり、ほぼ最適な負荷配分が行えたと見做すことができる。

そして、上記ステップＳ１３で決定した各ＣＰＵに対する各プログラム（ＰＧ１〜ＰＧ５）の割り当て結果に応じて、各プログラム（ＰＧ１〜ＰＧ５）のメモリ振分けを行う（ステップＳ１４）。これは例えば、図５の例の場合、プログラムＰＧ１とＰＧ５をＣＰＵ１に送信してそのメモリ等に格納させ、プログラムＰＧ２とＰＧ３とＰＧ４をＣＰＵ２に送信してそのメモリ等に格納させるものである。尚、ステップＳ１４の処理も最適負荷配分機能部１５が実行するものであってもよいし、ステップＳ１４の処理は不図示の他の機能部（各ＣＰＵへのプログラム振分け自体は既存機能であり特に説明しない）が実行するものであってもよい。

尚、ＣＰＵ１とＣＰＵ２は、例えば図１（ａ）に示す例のＣＰＵ２ａとＣＰＵ２ｂに相当すると考えても良い。あるいは、ＣＰＵ１とＣＰＵ２は、例えば図１（ｂ）に示す例のＣＰＵ４ａとＣＰＵ４ｂに相当すると考えても良い。

また、尚、上記各プログラム（ＰＧ１〜ＰＧ５）の実行順番が決まっている場合には、従来より例えば開発支援装置１０側にＰＧ実行順番を示す情報（実行順番テーブルというものとする；不図示）が格納されているので、例えば上記ステップＳ１４の処理の際にこの実行順番テーブルもＣＰＵ１のメモリ、ＣＰＵ２のメモリに記憶させるようにしてもよい。それによって、例えばＣＰＵ１において、ＰＧ５を先に実行して、後にＰＧ１を実行するようなことも起こり得る。

上記各プログラム（ＰＧ）毎の総実行オブジェクトコードサイズに基づく複数のＣＰＵへの各プログラムの割り当て方法は、様々な方法であってよく、一例を以下に説明するが、これらの例に限るものではない。

すなわち、例えば、
（１）負荷（サイズ）が大きいプログラム（ＰＧ）から順に各ＣＰＵへ順次割り当てていく方法。

例えば、図４（ｂ）に示す例では、負荷（サイズ）が大きいプログラム（ＰＧ）から順次割り当てると、ＰＧ１→ＰＧ２→ＰＧ３→ＰＧ４→ＰＧ５の順番で各プログラム（ＰＧ）を順次割り当ることになる。

ここで、例えば一例としては、最初は各ＣＰＵにＰＧを負荷（サイズ）が大きいものから順に１つずつ割り当て、その後は現在の負荷（サイズ）の割り当て総量が最も小さいＣＰＵへ次のＰＧ（残っているなかで最もサイズが大きいＰＧ）を割り当てる方法が考えられる。

この方法によれば、図４（ｂ）に示す例では、最初はＰＧ１をＣＰＵ１に割り当て、ＰＧ２をＣＰＵ２に割り当てることになる。その後は、ＰＧ３はＣＰＵ２に割り当て、続くＰＧ４もＣＰＵ２に割り当てることになる（何れも、その時点の負荷の割り当て総量が、ＣＰＵ１＞ＣＰＵ２であるので）。最後に、ＰＧ５は、ＣＰＵ１に割り当てることになる（その時点の負荷の割り当て総量が、ＣＰＵ１（＝５５）＜ＣＰＵ２（＝２５＋１８＋１６＝５９）であるので）。

この様な割り当て処理によって、図５に示す結果となる。
この様にして、例えば図５に示すように、ＣＰＵ１の処理負荷とＣＰＵ２の処理負荷が殆ど同じ（略均等）となるように、アプリケーションプログラムを構成する各プログラム（ＰＧ）を、複数のＣＰＵに割り当てることが出来る。

（２）割り当て負荷総量の平均値（平均の負荷配分値）を求めて、各ＣＰＵ毎に平均値を越えるまで各プログラム（ＰＧ）を割り当てていく方法。
これは、例えば、まず、各ＣＰＵへ割り当てる負荷総量の平均値を算出する。これは、上記全てのプログラムＰＧ１〜ＰＧ５の総実行オブジェクトコードサイズの総和を求める。図４（ｂ）の例では、総和＝５５＋２５＋１８＋１６＋７＝１２１となる。

この総和をＣＰＵ数で割ることで、各ＣＰＵへ割り当てる負荷総量の平均値を算出する。仮に図５の例と同様にＣＰＵ１、ＣＰＵ２の２つのＣＰＵに割り当てる場合、平均値＝１２１÷２＝６０．５となる。

そして、例えばまずＣＰＵ１に対して、平均値（＝６０．５）を越えるまでプログラム（ＰＧ）を割り当てていく。これは、一例としては、各プログラム（ＰＧ）をランダムに割り当てていく。但し、この例に限らず、例えば以下に説明するようにしてもよい。

すなわち、負荷（サイズ）が大きいプログラム（ＰＧ）から順次割り当てるようにする。但し、上記（１）とは異なり、１つのＣＰＵに対して上記平均値を越えるまで集中的に割り当てる。更に、平均値を越えた時点で完了とせずに、平均値を越えたときに割り当てたプログラム（ＰＧ）を、未だ割り当てていない他のプログラム（ＰＧ）と置き換えて、合計サイズが最も平均値に近いものに決定する。

すなわち、ＣＰＵ１に対してまずＰＧ１を割り当て、次にＰＧ２を割り当てると、合計サイズ＝５５＋２５＝８０なので平均値（＝６０．５）を越えたことになる。ここで、ＰＧ２の代わりに未だ割り当てていない他のプログラムＰＧ３，ＰＧ４，ＰＧ５を順次割り当てると、ＰＧ３の場合の合計サイズ＝５５＋１８＝７３、ＰＧ４の場合の合計サイズ＝５５＋１６＝７１、ＰＧ５の場合の合計サイズ＝５５＋７＝６２となり、ＰＧ５の場合が最も平均値に近いので、ＣＰＵ１に対してはＰＧ１とＰＧ５を割り当てることになる。

（３）組み合せ最適化問題として定義し、最適化手法（経験的手法・メタヒューリスティック等）を用いて解く方法。
この最適化手法自体は、既存の一般的な手法であり、ここでは特に説明しないが、この方法によれば、負荷の大きさにバラツキがあった場合や負荷の数が膨大になるような複雑な場合においても、最適な負荷配分を求めることができる。

また、上記（１）、（２）、（３）の３つの方法を組み合わせて、複数のＣＰＵにプログラム（ＰＧ）を割り当てるようにしてもよい。例えば、図４（ｂ）の例において、まず最初は、（１）の方法により最もサイズが大きいＰＧ１をＣＰＵ１に割り当て、２番目にサイズが大きいＰＧ２をＣＰＵ２に割り当てる。その後は、残りのＰＧ３、ＰＧ４，ＰＧ５を１つ以上、ＰＧ１またはＰＧ２と適宜組み合わせることで、様々な組み合わせを作成すると共に作成した組み合わせによる合計サイズ（例えば、ＰＧ１とＰＧ３の組み合わせでは合計サイズは５５＋１８＝７３となる）を求める。そして、合計サイズと上記平均の負荷配分値（＝６０．５）との差異が最も小さくなるような組み合わせを求める。

尚、負荷の数が膨大となる場合での負荷配分では、１つの負荷が全体の負荷に与える影響が軽減されるため、（１）や（２）の方法を単独で行うことも有効であると考えられる。

尚、本例では「ＰＯＵの呼び出し情報」を用いているが、“どのＰＯＵがどのＰＯＵを呼び出したか”を知る必要はなく、上記のように単に各プログラム（ＰＧ）毎に、そのＰＧに係わる各ＰＯＵの実行回数が分かればよいのである。本例では既存機能である呼出情報生成機能部１４によって生成される「ＰＯＵの呼び出し情報」を利用しているのであるが、この様な例に限らない。何れにしても必ずしも「ＰＯＵの呼び出し情報」である必要はなく、単に各ＰＯＵの実行回数が分かる様な情報であればなんでもよい。

IEC-61131-3では、１つのアプリケーションを実行する処理実行部をリソースと呼んで一元管理する概念を持っている。アプリケーションの負荷を配分する対象が、図１（ａ）のように複数のＣＰＵモジュール２に該当する場合は、一旦１つの実行処理部であると仮定して上記の様に実行オブジェクトコードサイズを算出し、その後、各ＣＰＵモジュール２に実行オブジェクトを割り付ける方法によって負荷配分を行う。

これは、図１（ｂ）のＣＰＵモジュール４のような例えばマルチコアマイクロプロセッサやコプロセッサを備えた演算装置に負荷を配分する場合も、同様の考え方で負荷配分を行うことが出来る。但し、図１（ｂ）の１つのＣＰＵモジュール４内の複数のＣＰＵ４ａ，４ｂは、同一の実行コードを実行する同一性能のマイクロプロセッサもしくは演算ＬＳＩなどであるものとし、コンパイル対象のユーザアプリケーションは、各機能の実行結果を相互に参照しないこと前提とする。

ここで上記オブジェクトコードのステップ数について、具体例を図６に示して説明する。図６において、図６（ａ）はプログラミング画面を示し、任意のプログラム部品（ここではＡＤＤ関数）を示している。このプログラム部品をコンパイルすることで、図６（ｂ）に示す実行オブジェクトコード（点線で囲った部分）が生成される。図示の通り、この実行オブジェクトコードのステップ数は‘９’である（９行；９ステップ）。

また、本例の開発支援装置１０は、ハードウェア的には例えばパソコン等の汎用のコンピュータ装置により実現できる。
図７は、開発支援装置のハードウェア構成の具体例を示す図であり、これはパソコン等の汎用のコンピュータの構成であると考えてよい。

図７において、コンピュータ３０は、ＣＰＵ３１、メモリ３２、入力部３３、出力部３４、記憶部３５、記録媒体駆動部３６、及びネットワーク接続部３７を有し、これらがバス３８に接続された構成となっている。

ＣＰＵ３１は、当該コンピュータ３０全体を制御する中央処理装置である。
メモリ３２は、任意の処理実行の際に、記憶部３５（あるいは可搬型記録媒体３９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ３１は、メモリ３２に読み出したプログラム／データを用いて、上述した各種処理を実行する。

出力部３４は、例えばディスプレイ等であり、入力部３３は、例えば、キーボード、マウス等である。
ネットワーク接続部３７は、例えば上記ネットワーク１等に接続して、他の情報処理装置（ＣＰＵモジュール２，４等）との通信（コマンド／データ送受信等）を行う為の通信モジュールである。

記憶部３５は、例えばハードディスク等であり、上述した開発支援装置１０の各種処理機能をＣＰＵ３１により実現させる為のアプリケーションプログラムが格納されている。すなわち、上記コンパイラ１１、リンカ１２、ＰＯＵサイズ算出機能部１３、呼出情報生成機能部１４、最適負荷配分機能部１５の各種処理機能部の処理機能を、ＣＰＵ３１により実現させる為のアプリケーションプログラムが格納されている。

ＣＰＵ３１は、上記記憶部３５に格納されている各種プログラムを読み出し・実行することにより、上述した各種処理を実現する。
また、上記図３（ｂ）や図４（ａ），（ｂ）に示す各種情報は、記憶部３５やメモリ３２等に記憶されるものである。

上記記憶部３５に格納される各種プログラム／データは、可搬型記録媒体３９に記憶されているものであってもよい。この場合、可搬型記録媒体３９に記憶されているプログラム／データは、記録媒体駆動部３６によって読み出される。可搬型記録媒体３９とは、例えば、ＦＤ（フレキシブル・ディスク）３９ａ、ＣＤ−ＲＯＭ３９ｂ、その他、ＤＶＤ、光磁気ディスク等である。

あるいは、また、上記プログラム／データは、ネットワーク接続部３７により接続しているネットワークを介して、他の装置内に記憶されているものをダウンロードするものであってもよい。あるいは、更に、インターネットを介して、外部の他の装置内に記憶されているものをダウンロードするものであってもよい。

また、本発明は、上記本発明の各種処理をコンピュータ上で実現するプログラムを記録した可搬型記憶媒体として構成できるだけでなく、当該プログラム自体として構成することもできる。

尚、上述した説明は一例であり、この例に限らない。ユーザが作成するアプリケーションが、例えばラダー図を用いるプログラムであっても構わない。本手法ではコンパイル後のプログラム（実行オブジェクトコード；機械語）を用いるので、ユーザが使用するＰＬＣ言語が何であっても関係ないからである。そして、実行オブジェクトコードのサイズ（ステップ数）を用いることで、的確に負荷を推定でき、それによってほぼ最適な負荷配分を実現できる。

ＰＬＣ言語に関係なく本例の開発支援装置１０の機能を概略的に説明するならば、特に図示等しないが本例の開発支援装置１０は以下の各種機能部を有するものと言うことができる。

まず、複数の演算処理部（ＣＰＵ）で演算させるべき任意のアプリケーションプログラムをコンパイルすることで実行オブジェクトコードを生成するコンパイル機能部（不図示）を備える。

また、例えば、上記アプリケーションプログラムを複数のグループ（ここでは一例として特に上記「処理単位」）に分割しておく。これは、例えば開発者等が決めて設定しておく。

そして、開発支援装置１０は、更に、これら複数の「処理単位」毎に、その「処理単位」に係わる実行オブジェクトコードのサイズの総数を求める総実行オブジェクトコードサイズ算出機能部（不図示）を備える。更に、上記アプリケーションプログラムの処理を上記各「処理単位」で複数の演算処理部（ＣＰＵ）に配分する機能部であって、上記各「処理単位」毎の実行オブジェクトコードサイズ総数（全ステップ数など）に基づいて、複数の演算処理部の負荷が略均等となるように上記アプリケーションプログラムの処理を各演算処理部に配分する負荷配分機能部（不図示）を備える。

この様に、本例の開発支援装置１０は、概略的には上記各種不図示の機能部を備えるものであるということもできる。
上記特許文献１に記載の従来技術は、システムの稼動時に行う動的な負荷配分方式であるため、初期の負荷配分が不適切であった場合には、システム始動時には、ＣＰＵの負荷が偏り、ＰＬＣシステムで要求される定時性を損う可能性がある。その点、静的な負荷配分方式である本手法では、システム始動時から信頼性の高い運用を行うことが出来る。

また、上記特許文献２記載の従来技術は、システムの非稼動時に行う静的な負荷配分方式でありこの点では本手法と同類であるが、特許文献２ではＳＦＣの特徴を利用しているため、他の言語に関しては適用することができず、特にＰＬＣの分野で最もよく利用されている言語であるラダー言語に対応できないという大きな問題が生じる。

これに対して、本手法では、ＳＦＣやラダー言語等のプログラマが用いるＰＬＣ言語には関係なく、何らかのＰＬＣ言語で記述されたプログラムをコンパイルすることで生成される実行オブジェクトコード（機械語等）を用いて負荷配分を行うので、ＰＬＣ言語が何であっても関係なく適用可能である。つまり、本手法では、特許文献２記載の従来技術に比べて汎用性が高いことになる。

このように、本手法によれば、複数のＣＰＵを有するＰＬＣシステムにおいて、システム始動時から最適な負荷配分でアプリケーション実行させることができることや、ＰＬＣ言語に依存せずに適用可能である等の様々なメリットが得られる。

上記本手法を適用したＰＬＣシステムによれば、複数のＣＰＵに対して自動的に（運用初期から）ほぼ最適な負荷配分を行えることで、システムの大規模化・複雑化による増大する「ユーザのシステム開発時間」を短縮することができる。また、コンパイル時に自動的にほぼ最適な負荷配分を行えることで、ユーザのノウハウに依存しない、安定した運用を可能にし、システムの信頼性を向上させることができる。

また、既に述べたように、ＰＬＣのアプリケーションは、従来のラダー言語などによる処理単位で記述された単純構造のプログラムではなく、ＩＥＣ61131-3のような多言語を駆使した機能単位の構造化設計が行われるようになってきており、ユーザが処理全体の流れを把握することが困難に成ってきている。構造化設計の場合、同一の機能単位、関数等が別々のプログラムから呼び出されることが多く、プログラム作成者が複数にわたる開発も多くなってきている。

このような状況では、複数のＣＰＵに対してアプリケーションプログラム作成者等が自力で負荷配分を行うことは難易度が高く、結果的に処理負荷のアンバランスによるトータルシステム処理性能の低下、またシステム立ち上げ時の工数の増加が考えられる。これに対して、本手法では、このような難易度が高いものに対しても、自動的にほぼ最適な負荷配分を行えるので、この様な問題も解決できる。

尚、「システム立ち上げ時の工数」とは、アプリケーションを複数の演算処理部（ＣＰＵ等）に配分するユーザの手間を意味する。本手法では、この様なシステム立ち上げに掛かる工数を削減することができる。

１ ネットワーク
２ ＰＬＣモジュール
２ａ、２ｂ ＣＰＵ
３ Ｉ／Ｏモジュール
４ ＰＬＣモジュール
４ａ，４ｂ ＣＰＵ
１０ 開発支援装置
１１ コンパイラ
１２ リンカ
１３ ＰＯＵサイズ算出機能部
１４ 呼出情報生成機能部
１５ 最適負荷配分機能部
３０ コンピュータ
３１ ＣＰＵ
３２ メモリ
３３ 入力部
３４ 出力部
３５ 記憶部
３６ 記録媒体駆動部
３７ ネットワーク接続部
３８ バス
３９ 可搬型記録媒体
３９ａ ＦＤ（フレキシブル・ディスク）
３９ｂ ＣＤ−ＲＯＭ

Claims (3)

1. 開発支援装置と複数の演算処理部を有し、複数のプログラムと該プログラムから呼び出される各種ＰＯＵより構成される任意のアプリケーションの実行に係わる負荷を該複数の演算処理部に分散させ実行するＰＬＣシステムであって、
   前記開発支援装置は、
   前記アプリケーションをコンパイルすることで実行オブジェクトコードを生成するコンパイル手段と、
   前記ＰＯＵそれぞれの前記実行オブジェクトコードのサイズを求めるＰＯＵサイズ算出手段と、
   前記コンパイル時に前記ＰＯＵの呼び出し情報を求める呼出情報生成手段と、
   前記ＰＯＵそれぞれの前記実行オブジェクトコードのサイズと、前記ＰＯＵの呼び出し情報とに基づいて、前記アプリケーションを構成するプログラム毎に、そのプログラムに係わる各ＰＯＵの前記実行オブジェクトコードのサイズと実行回数に応じた実行オブジェクトコードサイズ総数を算出する総実行オブジェクトコードサイズ算出手段と、
   前記各プログラムを前記複数の演算処理部に配分する手段であって、前記総実行オブジェクトコードサイズ算出手段によって算出される前記プログラムそれぞれの実行オブジェクトコードサイズ総数に基づいて、前記複数の演算処理部の負荷が略均等となるように前記各プログラムを前記各演算処理部に配分する負荷配分手段と、
   を有することを特徴とするＰＬＣシステム。
2. 前記実行オブジェクトコードのサイズは、実行オブジェクトコードのステップ数であることを特徴とする請求項１記載の開発支援装置。
3. 開発支援装置と複数の演算処理部を有し、複数のプログラムと該プログラムから呼び出される各種ＰＯＵより構成される任意のアプリケーションの実行に係わる負荷を該複数の演算処理部に分散させるＰＬＣシステムにおける前記開発支援装置であって、
   前記アプリケーションをコンパイルすることで実行オブジェクトコードを生成するコンパイル手段と、
   前記ＰＯＵそれぞれの前記実行オブジェクトコードのサイズを求めるＰＯＵサイズ算出手段と、
   前記コンパイル時に前記ＰＯＵの呼び出し情報を求める呼出情報生成手段と、
   前記ＰＯＵそれぞれの前記実行オブジェクトコードのサイズと、前記ＰＯＵの呼び出し情報とに基づいて、前記アプリケーションを構成するプログラム毎に、そのプログラムに係わる各ＰＯＵの前記実行オブジェクトコードサイズと実行回数に応じた実行オブジェクトコードサイズ総数を算出する総実行オブジェクトコードサイズ算出手段と、
   前記各プログラムを前記複数の演算処理部に配分する手段であって、前記総実行オブジェクトコードサイズ算出手段によって算出される前記プログラムそれぞれの実行オブジェクトコードサイズ総数に基づいて、前記複数の演算処理部の負荷が略均等となるように前記各プログラムを前記各演算処理部に配分する負荷配分手段と、
   を有することを特徴とするＰＬＣシステムにおける開発支援装置。